Second Attempt: Driver model usage on embedded processors

[Sylvain Munaut]

Dan Malek wrote:

> Why don't you just use the feature_call() model like we currently
> use for PowerPC on the PMac?  Isolate those places in the driver
> that need that information and call the function with a 
> selector/information
> request (and varargs) to get it. 


> For example,
> a driver could:
>
> feature_call(SOC_FTR, Fast_Ethernet1, INIT_IO_PINS);
>
> to configure the IO pins associated with the device, then it could:
>
> feature_call(SOC_FTR, Fast_Ethernet1, GET_CLKS, &txclk, &rxclk);
>
> to get the routing for the transmit and receive clocks, and finally:
>
> feature_call(SOC_FTR, Fast_Ethernet1, GET_PHY_IRQ, &phy_irq);
>
> to get the external interrupt number associated with the PHY.
>

FWIW, I really like this model.

Just as another example, for the I2C driver i2c-mpc, almost the only
variation between model is the clock selection and that forced to put
some processor specific stuff into the driver. With that model, you could
easly avoid theses platform/cpu specific stuff and isolate them.

USB with some really alike bus glues comes to mind too ...

Being able to do "action" in plus of just passing parameters is really nice
IMHO.


    Sylvain