[PATCH 3/3] ramips: mt7621-dts: add pinctrl properties for ethernet

Arınç ÜNAL arinc.unal at arinc9.com
Thu Feb 10 11:16:02 PST 2022


On 09/02/2022 09:18, Arınç ÜNAL wrote:
> On 09/02/2022 01:29, Rosen Penev wrote:
>> On Tue, Feb 8, 2022 at 1:02 PM Arınç ÜNAL <arinc.unal at arinc9.com> wrote:
>>>
>>>
>>>
>>> On 08/02/2022 18:02, Arınç ÜNAL wrote:
>>>> Hey Chuanhong,
>>>>
>>>> On 08/02/2022 17:20, Chuanhong Guo wrote:
>>>>> Hi!
>>>>>
>>>>> On Tue, Feb 8, 2022 at 3:38 AM Arınç ÜNAL <arinc.unal at arinc9.com> 
>>>>> wrote:
>>>>>> diff --git a/target/linux/ramips/dts/mt7621.dtsi
>>>>>> b/target/linux/ramips/dts/mt7621.dtsi
>>>>>> index 9256e118e4..95113d4e11 100644
>>>>>> --- a/target/linux/ramips/dts/mt7621.dtsi
>>>>>> +++ b/target/linux/ramips/dts/mt7621.dtsi
>>>>>> @@ -456,6 +456,9 @@
>>>>>>
>>>>>>                   mediatek,ethsys = <&sysc>;
>>>>>>
>>>>>> +               pinctrl-names = "default";
>>>>>> +               pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>;
>>>>>> +
>>>>>
>>>>> There are devices using rgmii2 pins as GPIO. (e.g. PBR-M1)
>>>>> rgmii2_pins should be excluded from pinctrl-0 in dts of these routers
>>>>> if you enable it by default here.
>>>>
>>>> Thanks for pointing this out. These are the devicetrees which use 
>>>> any of
>>>> the GPIOs for rgmii2 (GPIO 22 - 33).
>>>>
>>>> mt7621_xzwifi_creativebox-v1.dts
>>>> mt7621_tplink_rexx0-v1.dtsi
>>>> mt7621_firefly_firewrt.dts
>>>> mt7621_alfa-network_quad-e4g.dts
>>>> mt7621_winstars_ws-wn583a6.dts
>>>> mt7621_mikrotik_routerboard-m11g.dts
>>>> mt7621_sercomm_na502.dts
>>>> mt7621_mtc_wr1201.dts
>>>> mt7621_tplink_re350-v1.dts
>>>> mt7621_d-team_pbr-m1.dts
>>>> mt7621_telco-electronics_x1.dts
>>>> mt7621_wavlink_wl-wn531a6.dts
>>>> mt7621_zbtlink_zbt-wg3526.dtsi
>>>> mt7621_zbtlink_zbt-wg2626.dts
>>>> mt7621_gnubee_gb-pc2.dts
>>>> mt7621_gnubee_gb-pc1.dts
>>>> mt7621_wevo_w2914ns-v2.dtsi
>>>> mt7621_tplink_archer-x6-v3.dtsi
>>>> mt7621_netgear_ex6150.dts
>>>>
>>>> I will send v2 where the pinctrl-0 property for ethernet is overwritten
>>>> with only the rgmii1_pins and mdio_pins values for these devices.
>>>
>>> On a second note, I see that the devicetrees of these devices set rgmii2
>>> pins to function as gpio. Even with this, do we still need to prevent
>>> calling rgmii2_pins on the ethernet node for these devices?
>> Note that the GnuBee PC2 has an ethernet interface connected to
>> RGMII2. dts probably needs updating.
> 
> Honestly, I don't think the ethernet interface (external phy) on the 
> RGMII2 bus on GB-PC2 ever worked. The device already uses two of the 
> RGMII2 GPIOs for lan1 and lan2 LEDs. The external phy is not defined on 
> the OpenWrt dts and it mustn't have worked until my patch here and 
> upstream:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-next&id=0a93c0d75809582893e82039143591b9265b520e 
> 
> 
> I'm still not convinced as I believe it's sufficient to tell pinctrl to 
> initialise the rgmii2 group to function as GPIO which is already the 
> case on these devices' devicetrees.
> 
> Because of this uncertainty, this patch is a no go until someone with 
> any of these devices confirm that the RGMII2 GPIOs work as intended on 
> their device with this patch applied.

I bought a TP-Link RE650 v1 just to test this. You are right Chuanhong, 
we indeed need to remove rgmii2_pins from ethernet node for devices that 
use rgmii2 pins as GPIO. With the current patch, this is what I get:

[    1.177349] rt2880-pinmux pinctrl: pin io22 already requested by 
pinctrl; cannot claim for 1e100000.ethernet
[    1.196966] rt2880-pinmux pinctrl: pin-22 (1e100000.ethernet) status -22
[    1.210312] rt2880-pinmux pinctrl: could not request pin 22 (io22) 
from group rgmii2  on device rt2880-pinmux
[    1.230058] mtk_soc_eth 1e100000.ethernet: Error applying setting, 
reverse things back
[    1.245853] mtk_soc_eth: probe of 1e100000.ethernet failed with error -22

I've made sure overwriting the pinctrl-0 property on the device specific 
devicetree works. I will send v2 to address this.

Cheers.
Arınç



More information about the openwrt-devel mailing list