Re: [PATCH net-next 6/8] net: dsa: Add support for platform data

[Florian Fainelli]

On 01/10/2017 12:41 PM, Andrew Lunn wrote:
>> @@ -452,11 +455,14 @@ static int dsa_cpu_parse(struct dsa_port *port, u32 index,
>>  	struct net_device *ethernet_dev;
>>  	struct device_node *ethernet;
>>  
>> -	ethernet = of_parse_phandle(port->dn, "ethernet", 0);
>> -	if (!ethernet)
>> -		return -EINVAL;
>> +	if (port->dn) {
>> +		ethernet = of_parse_phandle(port->dn, "ethernet", 0);
>> +		if (!ethernet)
>> +			return -EINVAL;
>> +		ethernet_dev = of_find_net_device_by_node(ethernet);
>> +	} else
>> +		ethernet_dev = dev_to_net_device(dst->pd->netdev);

Bonjour Andrew,

> 
> Hi Florian
> 
> This is not going to work with John's rework of my multi CPU ports
> code. I think you are going to have to modify the platform_data
> structure to support multi-CPU ports.

Last time we discussed this, I had a super complex dsa2_platform_data
that allowed you to do exactly the same thing we currently do with
Device Tree, except that this was with platform_data. It took a lot of
effort to get there, but I essentially had the ZII vf160 board example
re-implemented and verified with a mockup driver (still have it in a
branch that's not too far from net-next/master).

Your reply then AFAIR was that we should aim for something simpler and
here is the result, we end-up re-using the existing dsa_platform_data
with its limitations.

If we have legacy platforms with complex setups, I really don't think we
have those in tree, we should use dsa2_platform_data (still have the
patches somewhere for that) although I was hoping to not have to use it
since it is way more intrusive into net/dsa/dsa2.c.

All platforms that I know that will benefit from this patch series: x86
SCU from ZII (out of tree), BCM47xx, BCM63xx, Orion5x have the same
properties: single switch attached to a SPI/MDIO/MMAP with built-in
PHYs. If we have more complex setups than that, we should try to collect
the requirements.

> 
> I put higher priority on cleanly integrating multi-CPU ports using
> device tree, than supporting legacy platforms. I'm O.K. with
> preparatory patches, but i think we should wait for actually platform
> data changes until after Johns code has landed and we can design the
> platform_data to work with it.

I would very much like to see the patches and then make a decision based
on the submission rather than project a decision on code that has not
been submitted yet.

Do we agree that patches 1 through 5 and 7 could go in then?
-- 
Florian