Hi Alex,
On 17 January 2018 at 14:37, Alexander Graf agraf@suse.de wrote:
On 17.01.18 23:11, Simon Glass wrote:
Hi Alex,
On 17 January 2018 at 15:03, Alexander Graf agraf@suse.de wrote:
On 17.01.18 20:39, Simon Glass wrote:
Hi Alex,
On 17 January 2018 at 00:54, Alexander Graf agraf@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@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