[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM5PR0402MB2691DAD9404B336D92F42ED9EC730@AM5PR0402MB2691.eurprd04.prod.outlook.com>
Date: Wed, 4 Oct 2017 09:59:58 +0000
From: Madalin-cristian Bucur <madalin.bucur@....com>
To: Andrew Lunn <andrew@...n.ch>
CC: David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"f.fainelli@...il.com" <f.fainelli@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] fsl/fman: remove of_node
> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@...n.ch]
> Sent: Tuesday, October 03, 2017 4:01 PM
> To: Madalin-cristian Bucur <madalin.bucur@....com>
> Cc: David Miller <davem@...emloft.net>; netdev@...r.kernel.org;
> f.fainelli@...il.com; linux-kernel@...r.kernel.org
> Subject: Re: [PATCH] fsl/fman: remove of_node
>
> On Tue, Oct 03, 2017 at 08:49:31AM +0000, Madalin-cristian Bucur wrote:
> > > -----Original Message-----
> > > From: David Miller [mailto:davem@...emloft.net]
> > > Sent: Tuesday, October 03, 2017 2:05 AM
> > > To: Madalin-cristian Bucur <madalin.bucur@....com>
> > > Subject: Re: [PATCH] fsl/fman: remove of_node
> > >
> > > From: Madalin Bucur <madalin.bucur@....com>
> > > Date: Mon, 2 Oct 2017 13:31:37 +0300
> > >
> > > > The FMan MAC driver allocates a platform device for the Ethernet
> > > > driver to probe on. Setting pdev->dev.of_node with the MAC node
> > > > triggers the MAC driver probing of the new platform device. While
> > > > this fails quickly and does not affect the functionality of the
> > > > drivers, it is incorrect and must be removed. This was added to
> > > > address a report that DSA code using of_find_net_device_by_node()
> > > > is unable to use the DPAA interfaces. Error message seen before
> > > > this fix:
> > > >
> > > > fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed
> > > > fsl_mac: probe of dpaa-ethernet.0 failed with error -16
> > > >
> > > > Signed-off-by: Madalin Bucur <madalin.bucur@....com>
> > >
> > > Is the DSA issue no longer something we need to be concerned
> > > about? If not, why? You have to explain this.
> >
> > My patch removes the of_node that was set to a device that was not an
> > of_device, preventing duplicated probing of both the real of_device
> > and the "fake" one created through this assignment.
> >
> > I understand that the DSA issue that triggered the initial change
> > was related to DSA finding the network devices using
> > of_find_net_device_by_node(), something that will not work for the
> > DPAA case where the netdevice does not have an of_node. I do not know
> > enough about DSA to come up with a solution for this problem now.
> > Andrew, Florian, can you please comment on this?
> >
> > Thanks,
>
> Hi Madalin
>
> I guess the real fix is to throw away the platform device. But that is
> a big change.
>
> I've not looked at the code in detail. Why is the platform device
> needed?
>
> Andrew
There are multiple components that are aggregated by the DPAA Ethernet
netdevice, the FMan MAC is one of them. There is no entry in the device
tree for the Ethernet device as this is just a software construct that
binds together multiple pieces from the DPAA FMan, QMan, BMan. The probing
of the Ethernet driver is performed against a platform device that is created
in the FMan MAC. Setting the of_node in the new platform device makes it
look like an of_device without being one, thus the errors at the MAC driver
probing against the platform device.
Does DSA work for systems that do not use a device tree to boot, i.e. ACPI?
Madalin
Powered by blists - more mailing lists