Hi Alex, On 17 January 2018 at 14:37, Alexander Graf <ag...@suse.de> wrote: > > > On 17.01.18 23:11, Simon Glass wrote: >> Hi Alex, >> >> On 17 January 2018 at 15:03, Alexander Graf <ag...@suse.de> wrote: >>> >>> >>> On 17.01.18 20:39, Simon Glass wrote: >>>> Hi Alex, >>>> >>>> On 17 January 2018 at 00:54, Alexander Graf <ag...@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 <ag...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
