Hi Michal, On Tue, Jul 10, 2012 at 3:49 PM, Michal Simek <mon...@monstr.eu> wrote: > On 07/10/2012 03:18 PM, Simon Glass wrote: >> >> Hi Michal, >> >> >> On Tue, Jul 10, 2012 at 12:23 PM, Michal Simek <mon...@monstr.eu >> <mailto:mon...@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.
Just an unnecessary #ifdef IMO. > > > >> >> + >> /* >> * 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. Normally if there is driver code that must be called elsewhere we add it to a header in include/. Yes the device model will change/improve this at some point. > > >> >> >> 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. FDT certainly fits very nicely with device model, but it doesn't require it. You can just have: some_device_probe(const void *blob) and call that from somewhere to make it look in the FDT for its info and initialize if it finds it. > > 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 Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
