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
| ||
|
Message-ID: <54D7EA58.40706@gmail.com> Date: Sun, 08 Feb 2015 14:59:36 -0800 From: Florian Fainelli <f.fainelli@...il.com> To: Andrew Lunn <andrew@...n.ch> CC: netdev@...r.kernel.org Subject: Re: DSA: Attaching phy twice? Hi Andrew, Le 08/02/2015 12:32, Andrew Lunn a écrit : > Hi Florian > > Have you seen messages like this before? Yes :) > > [ 2.495126] Distributed Switch Architecture driver version 0.1 > [ 2.501358] mvneta f1070000.ethernet eth0: [0]: detected a Marvell 88E6172 switch > [ 2.556441] libphy: dsa slave smi: probed > [ 2.638292] net lan4: PHY already attached > [ 2.733285] net lan3: PHY already attached > [ 2.820749] net lan2: PHY already attached > [ 2.910749] net lan1: PHY already attached > [ 3.000772] net internet: PHY already attached > > What appears to be happening is that dsa_slave_phy_setup() is finding > the phy for the port via device tree and using of_phy_connect(), or it > uses the fall back of taking a phy from the switch internal mdio bus > and calling phy_connect_direct(). So if a phy is found, > phy_attach_direct() gets called to attach the phy to the device. > > Then in dsa_slave_create(), a second call to phy_attach() is > made. This is when we get the warning "PHY already attached", and it > returns EBUSY, which is ignored. > > Is this code at the end of dsa_slave_create() doing anything useful? > > if (p->phy != NULL) { > if (ds->drv->get_phy_flags) > p->phy->dev_flags |= ds->drv->get_phy_flags(ds, port); > > phy_attach(slave_dev, dev_name(&p->phy->dev), > PHY_INTERFACE_MODE_GMII); > > p->phy->autoneg = AUTONEG_ENABLE; > p->phy->speed = 0; > p->phy->duplex = 0; > p->phy->advertising = p->phy->supported | ADVERTISED_Autoneg; > } > > My quick testing suggests its not useful, so if you agree, i will > submit a patch removing it. Or am i missing something? Right, now that we have a call to phy_connect_direct() for the built-in MDIO bus of the switch, we can remove that code, as it is indeed redundant (note that it was not before, especially for !OF setups). I would be happy to ack such a patch and give it a try here as well (with bcm_sf2). Thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists