| Message ID | 20180117085458.27293-2-agraf@suse.de |
|---|---|
| State | Superseded |
| Headers | show |
| Series | RPi: Properly handle dynamic serial configuration | expand |
On 01/17/2018 09:54 AM, Alexander Graf wrote: > Currently our serial device search chokes on the fact that the serial > probe function could fail. If it does, instead of searching for the next > usable serial device, it just quits. > > This patch changes the fallback logic so that even when a serial device > was not probed correctly, we just try the next ones until we find one that > works. > > Signed-off-by: Alexander Graf <agraf@suse.de> > > --- > > v1 -> v2: > > - Make search logic easier to follow Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
On 17 January 2018 at 00:54, Alexander Graf <agraf@suse.de> wrote: > Currently our serial device search chokes on the fact that the serial > probe function could fail. If it does, instead of searching for the next > usable serial device, it just quits. > > This patch changes the fallback logic so that even when a serial device > was not probed correctly, we just try the next ones until we find one that > works. > > Signed-off-by: Alexander Graf <agraf@suse.de> > > --- > > v1 -> v2: > > - Make search logic easier to follow > --- > drivers/serial/serial-uclass.c | 25 +++++++++++++++++++------ > 1 file changed, 19 insertions(+), 6 deletions(-) Reviewed-by: Simon Glass <sjg@chromium.org> The fallback logic is getting more complicated. How come the DT does not specify the correct console? Regards, Simon
On 17.01.18 20:34, Simon Glass wrote: > On 17 January 2018 at 00:54, Alexander Graf <agraf@suse.de> wrote: >> Currently our serial device search chokes on the fact that the serial >> probe function could fail. If it does, instead of searching for the next >> usable serial device, it just quits. >> >> This patch changes the fallback logic so that even when a serial device >> was not probed correctly, we just try the next ones until we find one that >> works. >> >> Signed-off-by: Alexander Graf <agraf@suse.de> >> >> --- >> >> v1 -> v2: >> >> - Make search logic easier to follow >> --- >> drivers/serial/serial-uclass.c | 25 +++++++++++++++++++------ >> 1 file changed, 19 insertions(+), 6 deletions(-) > > Reviewed-by: Simon Glass <sjg@chromium.org> > > The fallback logic is getting more complicated. How come the DT does > not specify the correct console? By default the DT on the RPi does not specify any serial console. However, users have grown accustomed to the fact that there is indeed one :). I guess it all boils down to the fact that Linux is terrible when it comes to console selection. 99.9% of users that want a serial console and have a graphical screen want to have *both* available as first class citizen consoles. But Linux just can't do that, so we have a lot of crude hacks all over the place. Alex
diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c index 2e5116f7ce..68ca2d09d1 100644 --- a/drivers/serial/serial-uclass.c +++ b/drivers/serial/serial-uclass.c @@ -74,6 +74,7 @@ static void serial_find_console_or_panic(void) { const void *blob = gd->fdt_blob; struct udevice *dev; + int ret; if (CONFIG_IS_ENABLED(OF_PLATDATA)) { uclass_first_device(UCLASS_SERIAL, &dev); @@ -104,8 +105,8 @@ static void serial_find_console_or_panic(void) * from 1!). * * Failing that, get the device with sequence number 0, or in - * extremis just the first serial device we can find. But we - * insist on having a console (even if it is silent). + * extremis just the first working serial device we can find. + * But we insist on having a console (even if it is silent). */ #ifdef CONFIG_CONS_INDEX #define INDEX (CONFIG_CONS_INDEX - 1) @@ -113,10 +114,22 @@ static void serial_find_console_or_panic(void) #define INDEX 0 #endif if (!uclass_get_device_by_seq(UCLASS_SERIAL, INDEX, &dev) || - !uclass_get_device(UCLASS_SERIAL, INDEX, &dev) || - (!uclass_first_device(UCLASS_SERIAL, &dev) && dev)) { - gd->cur_serial_dev = dev; - return; + !uclass_get_device(UCLASS_SERIAL, INDEX, &dev)) { + if (dev->flags & DM_FLAG_ACTIVATED) { + gd->cur_serial_dev = dev; + return; + } + } + + /* Search for any working device */ + for (ret = uclass_first_device_check(UCLASS_SERIAL, &dev); + dev; + ret = uclass_next_device_check(&dev)) { + if (!ret) { + /* Device did succeed probing */ + gd->cur_serial_dev = dev; + return; + } } #undef INDEX }
Currently our serial device search chokes on the fact that the serial probe function could fail. If it does, instead of searching for the next usable serial device, it just quits. This patch changes the fallback logic so that even when a serial device was not probed correctly, we just try the next ones until we find one that works. Signed-off-by: Alexander Graf <agraf@suse.de> --- v1 -> v2: - Make search logic easier to follow --- drivers/serial/serial-uclass.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-)