[U-Boot] [PATCH 0/7] [RFC] Driver model, take 1

[Marek Vasut]

Dear Graeme Russ,

> Hi DM Team,
> 
> On Thu, Aug 23, 2012 at 4:28 AM, Marek Vasut <marek.vasut at gmail.com> wrote:
> > Dear Marek Vasut,
> > 
> >> I'm submitting hereby the initial code for the driver model. This is a
> >> RFC patch, please give it a spin and scream :-)
> 
> I haven't had a really deep play with this yet, but a couple of things
> do come to mind...
> 
> I've been thinking of a scenario of a simple LED module with both a
> Serial (RS-232) and USB interface (or maybe an I2C connection). I can
> think of two options:
>  a) Write a separate driver for each interface
>  b) Write a single driver that can handle all supported interfaces

c) Write a muxing driver, basically you'd have two drivers -- "led-module-uart" 
and "led-module-usb" -- which would share common logic. The upcall towards the 
bus can also be pretty much covered by some local wrappers.

But I'm fairy sleepy now, had a hacknight tonight, so ...

> If going with option b, the LED driver is going to need to know what
> type of interface it is attached on in order for it to issue the
> correct commands to the upstream driver. I can't see a way in the
> current model to determine the type of the upstream driver

You can have a shared part and separate part of the probe() function. Also, the 
probe function knows the name of the driver, it can decide based on that.

> Another thought is naming if instances (this was in particular
> relation to stdio) - If you have two UARTS onboard, it would make
> sense to name them in U-Boot according to how they are named on the
> board (UART1 / UART2, Port 1 / Port 2, Console / Diagnostics, etc.)
> and when directing stdio, using the name of the port.

Basically aliases ... I'd postpone this. But it's good it's here, green on white 
with monospace font. I'll mark this as important.

> Regards,
> 
> Graeme

Best regards,
Marek Vasut