lkml.org 
[lkml]   [2004]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Second Attempt: Driver model usage on embedded processors
Date

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.053 / U:0.044 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site