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
