[U-Boot] FDT driver initialization function declaration

[Michal Simek]

On 07/10/2012 03:18 PM, Simon Glass wrote:
> Hi Michal,
>
> On Tue, Jul 10, 2012 at 12:23 PM, Michal Simek <monstr at monstr.eu <mailto:monstr at monstr.eu>> wrote:
>
>     Hi Simon, Wolfgang and others,
>
>     just want to open new topic about FDT driver initialization function
>     declaration.
>
>     There are some drivers which can be simple move to fdt initialization.
>     I have in my mind ethernet drivers and then systemace (I have ported it).
>
>     Ethernet drivers use include/netdev.h file where all initialization
>     functions are declared.
>
>     For example:
>
>     diff --git a/include/netdev.h b/include/netdev.h
>     index 4724717..96e62ee 100644
>     --- a/include/netdev.h
>     +++ b/include/netdev.h
>     @@ -105,6 +105,10 @@ int xilinx_emaclite_initialize(bd___t *bis, unsigned long base_addr,
>       int xilinx_ll_temac_eth_init(bd_t *bis, unsigned long base_addr, int flags,
>                                                      unsigned long ctrl_addr);
>
>     +#ifdef CONFIG_OF_CONTROL
>     +int xilinx_emaclite_init(bd_t *bis);
>     +#endif
>
>
> I don't think you need the #ifdef here.

Probably not but why not to protect it.


>
>     +
>       /*
>        * As long as the Xilinx xps_ll_temac ethernet driver has not its own interface
>        * exported by a public hader file, we need a global definition at this point.
>
>
>     But where is the right place for systemace FDT initialization?
>     include/fdtdec.h?
>
>
>     or create new header and include it to fdtdec.h?
>
>
> Yes, but don't include it in fdtdec.h. Why do you need to?

I am not saying that I want to do, just saying that there should be one file which
cover all of these. Or of course if new device model will be used this will
be probably solved there.

>
>
>     In this case it makes sense to add all FDT driven configuration to one header file
>     to see what drivers can be used. Even for network drivers.
>     Also listing all required parameters can be capture there.
>
>     What do you think?
>
>
> That's the idea of the list of compatible strings in fdtdec.c / h.
>
> I would suggest for now, just doing ad-hoc init using a special function call,
  or whatever else makes things easy. Yes fdt can potential clean all that stuff up,
  but not without the device model. I think once we have the device model we can revisit
  this (and I look forward to it). For now, just think of fdt as a way of enabling a driver,
  or specifying the number of ports the driver controls, rather than a way of deciding which
  driver inits get called.

Going to delay this FDT stuff till I get some more information about new device-model.

Thanks for your comments,
Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian