[PATCH 4/9] powerpc: BestComm core support for Freescale MPC5200

[Sylvain Munaut]

>> However, you could totally implement a "DMA devices" that would just
>> use a simple "copy from there to there" task using this BestComm driver.
>> So other part of the kernel (like network) could use that interface to
>> use the dma engine ...
>>     
>
> Can it also do the advanced operations like XOR on DMA that the
> Intel ioat has? That would be even more interesting, I guess.
>   
Actually yes it can.
It just need someone motivated enough to write it ;)


>>>> +static int __init
>>>> +mpc52xx_bcom_init(void)
>>>> +{
>>>> +	struct device_node *ofn_bcom, *ofn_sram;
>>>> +	struct resource res_bcom;
>>>> +
>>>> +	int rv;
>>>> +
>>>> +	/* Find the bestcomm node. If none, fails 'silently' since
>>>> +	 * we may just be on another platform */
>>>> +	ofn_bcom = of_find_compatible_node(
>>>> +			NULL, "dma-controller", "mpc5200-bestcomm");
>>>> +	if (!ofn_bcom)
>>>> +		return -ENODEV;
>>>>         
>>> I know, my usual rant is getting old, but why is this one not an
>>> of_platform_driver? It's not shared with arch/ppc or with arch/mips,
>>> and it's not needed before module_init() time.
>>>       
>> It needs to be initialized before _any_ other driver that uses bestcomm.
>> When compiled as module that could be an of_platform_driver but when
>> built-in there is apparently no way to ensure it's going to be probed
>> first. (At least no clean way ... )
>>     
>
> Initialization order is always a little tricky, but if you use a 
> subsys_initcall, it should at least come before any regular driver
> like network or disk, and arch/ drivers come before any code in drivers/,
> so I don't see much of a problem here.
>   
Mmm ... Silly of me but I didn't think of that.
I'll give it a shot.

(Actually before the transition to arch/powerpc, this was a
platform_driver ...
but there I could control the probe order with ppc_sys ).

>>> Why don't you use EXPORT_SYMBOL_GPL?
>>>       
>> Why would I ? Is it mandatory now ?
>> I don't really have an objection to non-gpl modules to use the exported
>> functions ...
>>     
>
> It's your choice, but there is a strong recommendation to use _GPL for
> all new interfaces nowadays. If you don't, people might suspect that
> you have a hidden agenda and actually plan to do non-gpl modules
> yourself.
>   
Well if it's recommended ... And since Dale is in favor of it, so be it,
I don't have any hidden agenda ;)


    Sylvain