| Message ID | 20180125110556.76352-2-agraf@suse.de |
|---|---|
| State | Accepted |
| Commit | 608b0c4ad4e5ec0c5d2c60276f19c3651d3d3cab |
| Headers | show |
| Series | RPi: Properly handle dynamic serial configuration | expand |
On Thu, Jan 25, 2018 at 12:05:42PM +0100, 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> > Reviewed-by: Simon Glass <sjg@chromium.org> Applied to u-boot/master, thanks! -- Tom
On Sun, Jan 28, 2018 at 01:54:50PM -0500, Tom Rini wrote: > On Thu, Jan 25, 2018 at 12:05:42PM +0100, 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> > > Reviewed-by: Simon Glass <sjg@chromium.org> > > Applied to u-boot/master, thanks! > > -- > Tom Is there something, at the board level, that needs to be coded to support this patch? The omap3_evm fails to boot with this patch applied. Reverting it allows omap3_evm to boot again. I am testing with the base default config for omap3_evm. Derald
On 29.01.18 04:27, Derald D. Woods wrote: > On Sun, Jan 28, 2018 at 01:54:50PM -0500, Tom Rini wrote: >> On Thu, Jan 25, 2018 at 12:05:42PM +0100, 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> >>> Reviewed-by: Simon Glass <sjg@chromium.org> >> >> Applied to u-boot/master, thanks! >> >> -- >> Tom > > Is there something, at the board level, that needs to be coded to > support this patch? The omap3_evm fails to boot with this patch applied. > Reverting it allows omap3_evm to boot again. I am testing with the base > default config for omap3_evm. No, this should really be a nop for everyone who does not fail probe() in serial devices. I'll see if I can figure out what's causing the issue in the next hours. If I don't get down to the root cause by tonight, I'll send a small patch that simply conditionalizes the new/old code based on a config variable and turn it on only for the Rpis, so we have a working -rc1. Alex
On 29.01.18 04:27, Derald D. Woods wrote: > On Sun, Jan 28, 2018 at 01:54:50PM -0500, Tom Rini wrote: >> On Thu, Jan 25, 2018 at 12:05:42PM +0100, 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> >>> Reviewed-by: Simon Glass <sjg@chromium.org> >> >> Applied to u-boot/master, thanks! >> >> -- >> Tom > > Is there something, at the board level, that needs to be coded to > support this patch? The omap3_evm fails to boot with this patch applied. > Reverting it allows omap3_evm to boot again. I am testing with the base > default config for omap3_evm. I've tried to reproduce the failure on a beagleboard xM, but was unable to see it fail. Even with the beagleboard configured basically using the same mechanisms (SPL_DM, manually defining CONFIG_SYS_NS16550_COM1, etc) I don't see it fail with CONFIG_SERIAL_SEARCH_ALL=y. Unfortunately I don't have an omap3 evm to test it on directly :(. Can you maybe share a bit more of the failure details? What exactly fails? When does it fail? I assume you're not seeing serial output? Does it boot nevertheless, albeit without serial output? 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 }