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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 24 Apr 2022 22:57:16 +1000 From: Nathan Rossi <nathan@...hanrossi.com> To: Andrew Lunn <andrew@...n.ch> Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Vivien Didelot <vivien.didelot@...il.com>, Florian Fainelli <f.fainelli@...il.com>, Vladimir Oltean <olteanv@...il.com>, "David S. Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com> Subject: Re: [PATCH 2/2] net: dsa: mv88e6xxx: Handle single-chip-address OF property On Sun, 24 Apr 2022 at 01:41, Andrew Lunn <andrew@...n.ch> wrote: > > On Sun, Apr 24, 2022 at 12:41:22AM +1000, Nathan Rossi wrote: > > On Sun, 24 Apr 2022 at 00:07, Andrew Lunn <andrew@...n.ch> wrote: > > > > > > On Sat, Apr 23, 2022 at 01:14:27PM +0000, Nathan Rossi wrote: > > > > Handle the parsing and use of single chip addressing when the switch has > > > > the single-chip-address property defined. This allows for specifying the > > > > switch as using single chip addressing even when mdio address 0 is used > > > > by another device on the bus. This is a feature of some switches (e.g. > > > > the MV88E6341/MV88E6141) where the switch shares the bus only responding > > > > to the higher 16 addresses. > > > > > > Hi Nathan > > > > > > I think i'm missing something in this explanation: > > > > > > smi.c says: > > > > > > /* The switch ADDR[4:1] configuration pins define the chip SMI device address > > > * (ADDR[0] is always zero, thus only even SMI addresses can be strapped). > > > * > > > * When ADDR is all zero, the chip uses Single-chip Addressing Mode, assuming it > > > * is the only device connected to the SMI master. In this mode it responds to > > > * all 32 possible SMI addresses, and thus maps directly the internal devices. > > > * > > > * When ADDR is non-zero, the chip uses Multi-chip Addressing Mode, allowing > > > * multiple devices to share the SMI interface. In this mode it responds to only > > > * 2 registers, used to indirectly access the internal SMI devices. > > > * > > > * Some chips use a different scheme: Only the ADDR4 pin is used for > > > * configuration, and the device responds to 16 of the 32 SMI > > > * addresses, allowing two to coexist on the same SMI interface. > > > */ > > > > > > So if ADDR = 0, it takes up the whole bus. And in this case reg = 0. > > > If ADDR != 0, it is in multi chip mode, and DT reg = ADDR. > > > > > > int mv88e6xxx_smi_init(struct mv88e6xxx_chip *chip, > > > struct mii_bus *bus, int sw_addr) > > > { > > > if (chip->info->dual_chip) > > > chip->smi_ops = &mv88e6xxx_smi_dual_direct_ops; > > > else if (sw_addr == 0) > > > chip->smi_ops = &mv88e6xxx_smi_direct_ops; > > > else if (chip->info->multi_chip) > > > chip->smi_ops = &mv88e6xxx_smi_indirect_ops; > > > else > > > return -EINVAL; > > > > > > This seems to implement what is above. smi_direct_ops == whole bus, > > > smi_indirect_ops == multi-chip mode. > > > > > > In what situation do you see this not working? What device are you > > > using, what does you DT look like, and what at the ADDR value? > > > > The device I am using is the MV88E6141, it follows the second scheme > > such that it only responds to the upper 16 of the 32 SMI addresses in > > single chip addressing mode. I am able to define the switch at address > > 0, and everything works. However in the device I am using (Netgate > > SG-3100) the ethernet phys for the non switch ethernet interfaces are > > also on the same mdio bus as the switch. One of those phys is > > configured with address 0. Defining both the ethernet-phy and switch > > as address 0 does not work. > > > > The device tree I have looks like: > > > > &mdio { > > status = "okay"; > > pinctrl-0 = <&mdio_pins>; > > pinctrl-names = "default"; > > > > phy0: ethernet-phy@0 { > > status = "okay"; > > reg = <0>; > > }; > > > > phy1: ethernet-phy@1 { > > status = "okay"; > > reg = <1>; > > }; > > So normally, we would have > > > switch0: switch0@16 { > compatible = "marvell,mv88e6141", "marvell,mv88e6085"; > single-chip-address; > reg = <0>; > dsa,member = <0 0>; > status = "okay"; > > and then i guess you are seeing mdiobus_register_device() returning > -EBUSY because the PHY is also at address 0? Correct, that is the issue I am trying to solve here. > > This is what is missing from your explanation. It is always better to > have more than less in the commit message. > > So the chip is using addresses 0x10-0x1f, but in order to probe, you > need to put reg = 0, taking up slot 0, clashing with the PHY. Ideally > we want to take up one of the slots in the range 0x10-0x1f. reg=16 on > its own indicates multi-chip mode and the device is using address 16. > > O.K, a bit more digging into the datasheet: > > For multi-chip mode, for the 6341 family, > > The SMI address that is used is determined by the ADDR[3:0] > configuration pins. ADDR[4] must be zero to select the device. > > So it can only take the address range 0-f, since ADDR[4] == 0. So 16 > is not even a valid multi-chip address. But it is valid for some other > chips. > > So your DT property is says, ignore reg, i really am in single chip > mode. > > This appears to be a general problem for any device with > .port_base_addr = 0x10. I had initially thought of using the port_base_addr along with setting up an of_match for the 6141 to provide compat_info which smi init could use. > > I'm wondering if a better solution to this is special case > reg=16. First try mv88e6xxx_detect() in single chip mode. That will > read register 3. A read should be safe. If we get back a valid ID for > a switch, keep with single chip mode. Otherwise swap to multi-chip > mode. A multi-chip mv88e6xxx_detect() is more dangerous, because that > involves writes. I tested this idea and have sent out a patch for it (https://lore.kernel.org/netdev/20220424125451.295435-1-nathan@nathanrossi.com/). It works correctly for the single chip detection case and safely falls through on other multi-chip addresses. It would be great if you could test this on the armada 370 rd board with reg=16. However just a side note, I had to move the reset gpio setup to occur before the smi init. Interestingly I am not sure if there was a reason for the reset to be unconfigured before setting up smi, it seems that might cause issues with the multi-chip smi init ops? Thanks, Nathan > > Looking at the existing DTs, there are only two using multi-chip mode > with reg=16: > > arm/boot/dts/armada-370-rd.dts- reg = <0x10>; > arm/boot/dts/kirkwood-linksys-viper.dts- reg = <16>; > > And i happen to have an armada-370-rd :-) > > Andrew
Powered by blists - more mailing lists