[U-Boot] FDT driver initialization function declaration

[Simon Glass]

Hi Michal,

On Tue, Jul 10, 2012 at 3:49 PM, Michal Simek <monstr at 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 <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.

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