Access to MT7531's registers with MDIO or other way

Banana Pi Router design
1

Hello. I have installed Openwrt on board, but it doesn’t matter in my question seems. I have connected MT7531 to the MT7981 CPU through MDIO. All works well. Once I decided to redefine LED’s behavior. I found that it’s possible to configure some GPIO registers described at:

On page 6 I see the list of registers groups that in theory I can read/write… But how?? I have installed two mdio tools (generic and custom), mii tools. But… what directly I should do to be able read a defined register?? I tried mdio <bus> phy 1 raw <reg> But [reg] in generic tools can be belongs only to range from 0 to 31. I am really confused. How can I read/write registers? Thanks.

2

The LED registers of the MT7531 are in MMD registers, in order to access them using the mdio userland tool you need to

mdio mt7530-0 mmd 0:31 0x21 0

Note that on the MT7531 IC all PHYs share their MMD registers, ie. it is not possible to control LED settings individual for each PHY/port, but the settings made for one PHY (0~4) always affect all of them.

In order to control the LEDs individually in software the GPIO controller of the MT7531 IC can be used instead.

3

Thanks. Yes, I am interested in GPIO controller. I know how to control Leds via GPHY registers (0x1f - 0x27 range for Led’s related). But I still don’t have idea how can I access Top memory register (GPIO controller), so to the GPIO’s at 0x00007c00. My question was related this.

image
image1023×311 68.1 KB
How can I access them via MDIO? Thanks.

4

MT7531 registers themselves cannot easily be accessed from userland – MediaTek invented a special access method to access the 32-bit switch registers over the 16-bit MDIO bus of the SoC and there isn’t a standard way to write to those registers from userland. The best way to achieve what you probably want to do is to add gpio-controller; to the switch node in device-tree which will tell the switch driver to simply expose all LEDs are GPIOs to Linux – you can then drive them in software, eg. using the /sys/class/gpio/ interface or using libgpio.

diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
index ed79ad1ae871..7ff14f5b5721 100644
--- a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts
@@ -203,6 +203,7 @@ &mdio {
        switch: switch@31 {
                compatible = "mediatek,mt7531";
                reg = <31>;
+               gpio-controller;
                interrupt-controller;
                #interrupt-cells = <1>;
                interrupts-extended = <&pio 66 IRQ_TYPE_LEVEL_HIGH>;
5

Thanks. Ok, If I cannot access from userland, how could I do this from kernel space? I am planning to implement all in loadable kernel module. I used mdio-tools only just as some kind of ‘fast’ test, as easiest way to probe functionality. So I need a kernel module to try to access top memory map of MT7531, but still searching how to do this. Thanks.

6

Thanks again. I found the solution. I will write this here, if someone will face the same task. The kernel uses DSA (Distributed Switch Architecture) kernel module for mt7531 switch initialization. To access the main registers the developer can write own kernel module. The _init function will looks like:

static int __init mdio_module_init(void)
{
	uint32_t val = 0;
	struct mt7530_priv *priv;
	struct dsa_switch *dds = dsa_switch_find(0, 0);
	if(!dds) 
	{
		printk(KERN_INFO "MT7531: Switch not found\n");
               return -1;
	}
	priv = dev_get_drvdata(dds->dev);
	ret = regmap_read(priv->regmap, 0x0000781C, &val);
	printk(KERN_INFO "MT7531: CREV %08x\n", val);
	return 0;
}

So this will print the revision of chip from CREV register:

image
image997×310 55.8 KB

And in console we have: image

We can sure we got valid chip revision from CREV register. Thanks for help.

7

This looks like a confused answer from ChatGPT or similar AI which tries to sound plausible, but it won’t work like that in reality.

I mean, of course, you can modify the existing DSA driver, but if you write another module that module doesn’t have the definition of struct mt7530_priv and “stealing” the drvdata from another driver is a very bad idea (there is no locking, nothing to prevent congruent access, …)

8

I didn’t say that I change existing DSA driver. I wrote own loadable (*.ko) driver that find already registered MT7531-switch via function:

dsa_switch_find()

And using the handler of dsa_switch I can access to registers via regmap_write or regmap_read easily. I didn’t change default openwrt source or drivers.

9

Yes. This will work sometimes, but it depends on the timing… If it works for you because you load the module long after mt7530_mdio driver has initialized, that’s lucky…

10

Of course, I load this module in service only after main DSA is loaded. In result I have full access to register map of MT7531.

11

… and it works as long there are no complex congruent access from the DSA driver while you do this, because there is no locking to make sure the order of access is kept…