[PATCH] ramips: add support for Notion R281 (mtd5)

[Ian Pangilinan]

> On 2022-07-24 19:53, Arınç ÜNAL wrote:
> On 24.07.2022 14:48, Ian Pangilinan wrote:
>>> On 2022-07-24 18:32, Arınç ÜNAL wrote:
>>> On 24.07.2022 12:38, Ian Pangilinan wrote:
>>>> +	keys {
>>>> +		compatible = "gpio-keys";
>>>> +
>>>> +		/* use wps as wifi button */
>>>> +		key-wifi {
>>>> +			label = "wifi";
>>>> +			gpios = <&gpio 10 GPIO_ACTIVE_LOW>;
>>>> +			linux,code = <KEY_RFKILL>;
>>>> +		};
>>>> +
>>>> +		key-reset {
>>>> +			label = "reset";
>>>> +			gpios = <&gpio 7 GPIO_ACTIVE_LOW>;
>>>> +			linux,code = <KEY_RESTART>;
>>>> +		};
>>>> +	};
>>>> +};
>>>> +
>>>> +&state_default {
>>>> +	gpio {
>>>> +		groups = "jtag", "rgmii2", "uart3";
>>>> +		function = "gpio";
>>>> +	};
>>>> +};
>>> 
>>> Please remove this node. It is unnecessary and claiming the rgmii2
>>> group here will break gmac1 configuration.
>> 
>> I have removed rgmii2 from the group. But I could not remove the
>> state_default node, as I have not fully applied the patch series yet
>> to my locally cloned OpenWrt git repo, which will involve changes to
>> mt7621.dtsi and a hundred other device-tree files, which will render
>> this patch unable to be applied to master as your pull request is
>> still pending.
> 
> You can either revert your gmac1 configuration (because that requires
> my PR as well) or remove this node and put a disclaimer to require my
> PR to be applied for this patch to be applied.
> 

This is my first time to submit a patch on this mailing list, so forgive
me for being a little hard on the head. ;) But, I don't see why I can't
use the relevant part of your patch series, which is not dependent on 
the
other changes made, to make the change as intended by your PR.

Of course I don't wan't to take away credit where credit is due, that's
why I referenced your PR here.

>> 
>> BTW, thank you for your patch, I hope it gets merged soon. For
>> those devices that do need GPIOs 22-33, which is shared with rgmii2,
>> would this not break gmac1 configuration?
>> 
>> &rgmii2_pins {
>> 	rgmii2 {
>> 		function = "gpio";
>> 	};
>> };
> 
> This is exactly why there is no phy muxing to gmac1 for devices that
> use the pins 22-33 as GPIO.
> 

Understood. It is unfortunate for those devices that can't take
advantage of this improvement if those pins are used for something else.

>> 
>> Is this not the same as above? Also, I have noticed this in dmesg
>> after applying the changes:
>> 
>> [    5.279629] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module
>> [    5.469566] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module
>> [    5.499862] mt7530 mdio-bus:1f lan2 (uninitialized): PHY
>> [mt7530-0:01] driver [MediaTek MT7530 PHY] (irq=27)
>> [    5.521957] mt7530 mdio-bus:1f lan3 (uninitialized): PHY
>> [mt7530-0:02] driver [MediaTek MT7530 PHY] (irq=28)
>> [    5.543995] mt7530 mdio-bus:1f lan4 (uninitialized): PHY
>> [mt7530-0:03] driver [MediaTek MT7530 PHY] (irq=29)
>> [    5.566898] mt7530 mdio-bus:1f: configuring for fixed/rgmii link 
>> mode
>> [    6.841401] mt7530 mdio-bus:1f: Link is Up - 1Gbps/Full - flow
>> control rx/tx
>> [   14.228062] mt7530 mdio-bus:1f lan2: configuring for phy/gmii link
>> mode
>> [   16.997212] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow
>> control rx/tx
>> [   17.277909] mt7530 mdio-bus:1f lan2: Link is Down
>> [   35.288001] mt7530 mdio-bus:1f lan2: configuring for phy/gmii link
>> mode
>> [   35.431097] mt7530 mdio-bus:1f lan3: configuring for phy/gmii link
>> mode
>> [   35.508752] mt7530 mdio-bus:1f lan4: configuring for phy/gmii link
>> mode
>> [   35.590215] mtk_soc_eth 1e100000.ethernet wan: PHY [mdio-bus:00]
>> driver
>> [MediaTek MT7530 PHY] (irq=POLL)
>> [   39.186967] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow
>> control rx/tx
>> [  170.691572] mt7530 mdio-bus:1f lan2: Link is Down
>> [  173.311930] mt7530 mdio-bus:1f lan2: Link is Up - 1Gbps/Full - flow
>> control rx/tx
>> 
>> Is the irq=POLL for the ethernet-phy0, which is the wan/lan1 port 
>> where
>> the change is made, normal?
> 
> Good question. The phy was controlled under the DSA switch node which
> had interrupts defined. Interrupts aren't defined on the mdio node
> where we define the phy now. Therefore polling is used instead.
> Anyway, this does not break anything.
> 
> Arınç
> 

Copy. This is good to know.

-ianp