Hi Florian, all,
On Fri, 2017-02-03 at 10:34 -0800, Florian Fainelli wrote:
> On 02/03/2017 09:30 AM, Alexey Brodkin wrote:
> >
> > Hi Andrew,
> >
> > On Fri, 2017-02-03 at 18:10 +0100, Andrew Lunn wrote:
> > >
> > > On Fri, Feb 03, 2017 at 07:52:37PM +0300, Alexey Brodkin wrote:
> > > >
> >
On 02/03/2017 09:30 AM, Alexey Brodkin wrote:
> Hi Andrew,
>
> On Fri, 2017-02-03 at 18:10 +0100, Andrew Lunn wrote:
>> On Fri, Feb 03, 2017 at 07:52:37PM +0300, Alexey Brodkin wrote:
>>>
>>> Current implemntation returns ENODEV if device tree node for
>>> phy is absent. But in reality there're
> This is especially nice because we may change the base-board and use
> there another PHY and as long we have drivers for all possible PHY built
> in the kernel (or available via modules) proper driver will be instantiated
> based on PHY ID read from MDIO. I.e. having no PHY node in DT adds
>
Hi Andrew,
On Fri, 2017-02-03 at 18:10 +0100, Andrew Lunn wrote:
> On Fri, Feb 03, 2017 at 07:52:37PM +0300, Alexey Brodkin wrote:
> >
> > Current implemntation returns ENODEV if device tree node for
> > phy is absent. But in reality there're many boards with the one
> > and only PHY on board
On Fri, Feb 03, 2017 at 07:52:37PM +0300, Alexey Brodkin wrote:
> Current implemntation returns ENODEV if device tree node for
> phy is absent. But in reality there're many boards with the one
> and only PHY on board and MACs that may find a PHY by querying
> MDIO bus. One good example is STMMAC.
Current implemntation returns ENODEV if device tree node for
phy is absent. But in reality there're many boards with the one
and only PHY on board and MACs that may find a PHY by querying
MDIO bus. One good example is STMMAC.
So that's what I saw:
--- Booing
