[U-Boot] [PATCH v2 2/7] serial: Allow boards to determine whether a serial device is usable

[Simon Glass]

Hi Alex,

On 17 January 2018 at 14:37, Alexander Graf <agraf at suse.de> wrote:
>
>
> On 17.01.18 23:11, Simon Glass wrote:
>> Hi Alex,
>>
>> On 17 January 2018 at 15:03, Alexander Graf <agraf at suse.de> wrote:
>>>
>>>
>>> On 17.01.18 20:39, Simon Glass wrote:
>>>> Hi Alex,
>>>>
>>>> On 17 January 2018 at 00:54, Alexander Graf <agraf at suse.de> wrote:
>>>>> On some boards, serial devices may or may not be muxed properly to actual
>>>>> pins, depending on firmware configuration. To determine whether we should
>>>>> use a serial device for U-Boot in-/output, we need to check whether it
>>>>> is muxed properly.
>>>>>
>>>>> This is something only the board file can do, so let's expose a weak
>>>>> function that a board can override to explicitly allow or disallow
>>>>> usage of certain serial devices.
>>>>>
>>>>> Signed-off-by: Alexander Graf <agraf at suse.de>
>>>>> ---
>>>>>  drivers/serial/serial-uclass.c | 11 +++++++++++
>>>>>  include/serial.h               | 11 +++++++++++
>>>>>  2 files changed, 22 insertions(+)
>>>>>
>>>>
>>>> Can we please figure out how handle this in the serial driver / driver
>>>> model itself? I want to avoid weak functions with driver model.
>>>
>>> I'm very happy to see suggestions :). The reason I went with the weak
>>> function is really because I couldn't think of anything better.
>>
>> The serial driver is proprietary so you should be able to put a call
>> into the pinctrl driver from that. The pinctrl driver can return the
>> state of a pin - maybe get_gpio_mux() or a new pinmux_get()?
>
> The SoC has 2 serial drivers: a proprietary one and a pl011. Would you
> think it's ok to put an architecture specific hack into the generic
> pl011 code with an #ifdef?

Normally in this situation we create an outer driver which uses the
other one - see serial_rockchip.c for example. That way the base
driver doesn't have to know about arch-specific things.

Regards,
Simon