lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <F4CC6FACFEB3C54C9141D49AD221F7F93B7A26E1@FRAEML521-MBX.china.huawei.com>
Date:   Tue, 13 Jun 2017 23:01:44 +0000
From:   Salil Mehta <salil.mehta@...wei.com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Florian Fainelli <f.fainelli@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "Zhuangyuzeng (Yisen)" <yisen.zhuang@...wei.com>,
        huangdaode <huangdaode@...ilicon.com>,
        "lipeng (Y)" <lipeng321@...wei.com>,
        "mehta.salil.lnk@...il.com" <mehta.salil.lnk@...il.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linuxarm <linuxarm@...wei.com>
Subject: RE: [PATCH net-next 6/9] net: hns3: Add MDIO support to HNS3
 Ethernet driver for hip08 SoC

Hi Andrew,

> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@...n.ch]
> Sent: Tuesday, June 13, 2017 11:41 PM
> To: Salil Mehta
> Cc: Florian Fainelli; davem@...emloft.net; Zhuangyuzeng (Yisen);
> huangdaode; lipeng (Y); mehta.salil.lnk@...il.com;
> netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Linuxarm
> Subject: Re: [PATCH net-next 6/9] net: hns3: Add MDIO support to HNS3
> Ethernet driver for hip08 SoC
> 
> > > Hum why do you do this? mdiobus_register() will scan through your
> bus
> > > provided that you set an appropriate phy_mask value (here you tell
> it
> > > not to) and you already provide the PHY address to scan for
> > >
> > I know this looks weird but the reason why it appears as it is in
> code is:
> >
> > mdiobus_register() calls mdiobus_scan(). If you see below code leg
> function
> > get_phy_device() assumes to be having supporting Clause 22 so its
> input
> > parameter 'is_c45' is always 'false'.
> >
> > struct phy_device *mdiobus_scan(struct mii_bus *bus, int addr)
> > {
> > 	struct phy_device *phydev;
> > 	int err;
> >
> > 	phydev = get_phy_device(bus, addr, false);
> > 	if (IS_ERR(phydev))                ^^^^^
> > 		return phydev;
> > 	[...]
> > }
> >
> > Therefore, to support C45 device we did below:
> >
> > * disabled the autoscan/mdiobus_scan() Of the PHY devices using the
> >   phy_mask(= ~0)
> > * Now, did almost the same thing what mdiobus_scan does i.e.
> >     * get_phy_device but with is_c45 (=true/false)
> >     * register the above phy device with phy_device_register()
> >
> > There could be some gap in my understanding, please help to correct
> this?
> 
> So this is the question i was asking Florian
> 
> Rather than hack around limitations of the core, you should fix the
> core. I think we should make the core first try probing using c45. If
> that comes back with an error, or does not find a device, try the
> probe using c22.
I can take this activity but please allow me to do this as a separate activity
and not part of this driver Up-streaming activity.

Since I would be touching the core, lots of drivers will get impacted and will
have to wait till everyone gives clean signal. This will impact our internal
deadlines. But as I said I am eager to cooperate & contribute :)

Thanks
Salil
> 
>       Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ