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
