Second Attempt: Driver model usage on embedded processors

[Andy Fleming]

On Dec 7, 2004, at 08:53, Dan Malek wrote:
>> The issue I've got with #2 is that some of these devices (and 
>> therefor drivers) will end up existing on various parts from 
>> Freescale that might have an ARM core or PPC core.
>
> If the configuration options are truly static, we can do just like we 
> do today
> with processor cores that share similar peripherals.  Just #define 
> those things
> that are constants and compile them into the driver.  These could be 
> address
> offsets, functional support (like RMON), and so on.  There are examples
> of these drivers that work fine today and could work even better with 
> minor
> touch ups of the configuration options.  You have already #define'd 
> this
> stuff in the board/processor configuration files.  Why put them into a 
> static
> data structure and then find some complex method to access it?  These
> are embedded systems, after all, that want to minimize overhead.

The issue here is that the driver supports devices which can vary in 
features on the same processor.  An example is the gianfar driver for 
the 8540.  The driver supports the two TSEC devices, as well as the 
FEC.  In order to make the driver applicable to different processors 
with different device configurations, the driver needs to be agnostic 
about how many devices there are, and what features they have.  As 
such, defining constants does not solve the problem.

These things could be assigned statically at compile time, in the 
driver, but this means that every new processor will require adding 
#ifdefs to the driver, which will become progressively more difficult 
to maintain.

Anyway, I like the idea of using feature_call.  Are we sure, though, 
that it's not using a hammer for a screw?  I'm not very familiar with 
the function's intent.


Andy Fleming
Open Source Team
Freescale Semiconductor, Inc