The MDIO address of the MT7530 and MT7531 switch ICs can be configured
using bootstrap pins. However, there are only 4 possible options for the
switch itself: 7, 15, 23 and 31. As in MediaTek's SDK the address of the
switch is wrongly stated in the device tree as 0 (while in reality it is
31), warn the user about such broken device tree and make a good guess
what was actually intended.
This is imporant also to not break compatibility with older device trees
as with commit 868ff5f4944a ("net: dsa: mt7530-mdio: read PHY address of
switch from device tree") the address in device tree will be taken into
account.
Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
Signed-off-by: Daniel Golle <[email protected]>
---
Changes since v1:
- use FW_WARN as suggested.
- fix build on net tree which doesn't have 'mdiodev' as member of the
priv struct. Imho including this patch as fix makes sense to warn
users about broken firmware, even if the change introducing the
actual breakage is only present in net-next for now.
drivers/net/dsa/mt7530-mdio.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/net/dsa/mt7530-mdio.c b/drivers/net/dsa/mt7530-mdio.c
index fa3ee85a99c1..3c21c8d074c7 100644
--- a/drivers/net/dsa/mt7530-mdio.c
+++ b/drivers/net/dsa/mt7530-mdio.c
@@ -193,6 +193,19 @@ mt7530_probe(struct mdio_device *mdiodev)
return PTR_ERR(priv->io_pwr);
}
+ /* Only MDIO bus address 7, 15, 23 and 31 are valid options */
+ if (~(mdiodev->addr & 0x7) & 0x7) {
+ /* If the address in DT must be wrong, make a good guess about
+ * the most likely intention, and issue a warning.
+ */
+ int correct_addr = ((((mdiodev->addr - 7) & ~0x7) % 0x20) + 7) & 0x1f;
+
+ dev_warn(&mdiodev->dev, FW_WARN
+ "impossible switch MDIO address in device tree: %d, assuming %d\n",
+ mdiodev->addr, correct_addr);
+ mdiodev->addr = correct_addr;
+ }
+
regmap_config = devm_kzalloc(&mdiodev->dev, sizeof(*regmap_config),
GFP_KERNEL);
if (!regmap_config)
--
2.44.0
On 4/30/24 15:01, Daniel Golle wrote:
> The MDIO address of the MT7530 and MT7531 switch ICs can be configured
> using bootstrap pins. However, there are only 4 possible options for the
> switch itself: 7, 15, 23 and 31. As in MediaTek's SDK the address of the
> switch is wrongly stated in the device tree as 0 (while in reality it is
> 31), warn the user about such broken device tree and make a good guess
> what was actually intended.
>
> This is imporant also to not break compatibility with older device trees
> as with commit 868ff5f4944a ("net: dsa: mt7530-mdio: read PHY address of
> switch from device tree") the address in device tree will be taken into
> account.
>
> Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch")
> Signed-off-by: Daniel Golle <[email protected]>
> ---
> Changes since v1:
> - use FW_WARN as suggested.
> - fix build on net tree which doesn't have 'mdiodev' as member of the
> priv struct. Imho including this patch as fix makes sense to warn
> users about broken firmware, even if the change introducing the
> actual breakage is only present in net-next for now.
>
> drivers/net/dsa/mt7530-mdio.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/net/dsa/mt7530-mdio.c b/drivers/net/dsa/mt7530-mdio.c
> index fa3ee85a99c1..3c21c8d074c7 100644
> --- a/drivers/net/dsa/mt7530-mdio.c
> +++ b/drivers/net/dsa/mt7530-mdio.c
> @@ -193,6 +193,19 @@ mt7530_probe(struct mdio_device *mdiodev)
> return PTR_ERR(priv->io_pwr);
> }
>
> + /* Only MDIO bus address 7, 15, 23 and 31 are valid options */
> + if (~(mdiodev->addr & 0x7) & 0x7) {
> + /* If the address in DT must be wrong, make a good guess about
> + * the most likely intention, and issue a warning.
> + */
> + int correct_addr = ((((mdiodev->addr - 7) & ~0x7) % 0x20) + 7) & 0x1f;
0x20 -> PHY_MAX_ADDR
0x1F -> PHY_MAX_ADDR - 1
> +
> + dev_warn(&mdiodev->dev, FW_WARN
> + "impossible switch MDIO address in device tree: %d, assuming %d\n",
> + mdiodev->addr, correct_addr);
> + mdiodev->addr = correct_addr;
Sorry for not jumping on this earlier on, there is a mixture of
hexadecimal and decimal numbers being used which IMHO just makes this
more difficult to read than needed. It seems like the requirement is for
the switch's MDIO device address to have the lower 3 bits set, so can we
give it a name like MT7530_MDIO_ADDR_VALID_MASK?
--
Florian
On Tue, Apr 30, 2024 at 11:01:17PM +0100, Daniel Golle wrote:
> + /* Only MDIO bus address 7, 15, 23 and 31 are valid options */
> + if (~(mdiodev->addr & 0x7) & 0x7) {
So the common thing about the three addresses you mention are that they
all have the least significant three bits set. So I'd suggest to spell
that out in the comment:
/* Only MDIO bus addresses 7, 15, 23, and 31 are valid options,
* which all have the least significant three bits set. Check
* for this.
*/
The test here is also not obvious, so I would suggest:
if ((mdiodev->addr & 7) != 7) {
which is much easier to read and ties up with the above comment.
> + /* If the address in DT must be wrong, make a good guess about
> + * the most likely intention, and issue a warning.
> + */
> + int correct_addr = ((((mdiodev->addr - 7) & ~0x7) % 0x20) + 7) & 0x1f;
Huh? Again, not obvious what this is doing. So, I threw this into a C
program that wraps the thing in a for() loop from 0..31 to see what it
produces.
addr range result
0-6 31
7-14 7
15-22 15
23-30 23
31 31
Is it really sane to be suggesting "31" for values 0-6 ?
> +
> + dev_warn(&mdiodev->dev, FW_WARN
> + "impossible switch MDIO address in device tree: %d, assuming %d\n",
> + mdiodev->addr, correct_addr);
> + mdiodev->addr = correct_addr;
Sorry, but no. You must not change the mdiodev address. The address
member is used to index arrays in the MDIO bus, and changing it will
end up corrupting those arrays.
For example, when a MDIO device is registered:
mdiodev->bus->mdio_map[mdiodev->addr] = mdiodev;
when it is unregistered:
if (mdiodev->bus->mdio_map[mdiodev->addr] != mdiodev)
return -EINVAL;
will fail, and a dangling pointer will be left at the original
address. Moreover, the reset control (if any) will not be put.
If the MDIO device address is wrong, then you can either fail or
maybe create a new mdio device with the correct address - but the
latter may get quite icky from a coding point of view. You would
have to tear down this other device when the original incorrect
one is unbound from the driver.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!