Re: Second Attempt: Driver model usage on embedded processors

On Dec 7, 2004, at 08:53, Dan Malek wrote:

quoted

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