Hi Marek, On 10 July 2014 17:26, Marek Vasut <ma...@denx.de> wrote: > On Wednesday, July 09, 2014 at 05:37:54 AM, Simon Glass wrote: >> At present stdio device functions do not get any clue as to which stdio >> device is being acted on. Some implementations go to great lengths to work >> around this, such as defining a whole separate set of functions for each >> possible device. >> >> For driver model we need to associate a stdio_dev with a device. It doesn't >> seem possible to continue with this work-around approach. >> >> Instead, add a stdio_dev pointer to each of the stdio member functions. >> >> Note: The serial drivers have the same problem, but it is not strictly >> necessary to fix that to get driver model running. Also, if we convert >> serial over to driver model the problem will go away. >> >> Code size increases by 244 bytes for Thumb2 and 428 for PowerPC. >> >> 22: stdio: Pass device pointer to stdio methods >> arm: (for 2/2 boards) all +244.0 bss -4.0 text +248.0 >> powerpc: (for 1/1 boards) all +428.0 text +428.0 >> >> Signed-off-by: Simon Glass <s...@chromium.org> >> Acked-by: Marek Vasut <ma...@denx.de> > > [...] > >> diff --git a/drivers/serial/serial.c b/drivers/serial/serial.c >> index fd61a5e..803d850 100644 >> --- a/drivers/serial/serial.c >> +++ b/drivers/serial/serial.c >> @@ -254,6 +254,48 @@ void serial_initialize(void) >> serial_assign(default_serial_console()->name); >> } >> >> +int serial_stub_start(struct stdio_dev *sdev) >> +{ >> + struct serial_device *dev = sdev->priv; > > Are you sure this pointer derefference won't blow if $sdev is ever NULL? Can > $sdev be NULL (in some early stage for example) ?
Not that I can think of. It should never be NULL. > >> + return dev->start(); >> +} > > Reviewed-by: Marek Vasut <ma...@denx.de> > > I really like where this is going. > > Best regards, > Marek Vasut Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot