[PATCH 3/3] ramips: mt7621-dts: add pinctrl properties for ethernet
Arınç ÜNAL
arinc.unal at arinc9.com
Tue Feb 8 22:23:54 PST 2022
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.
Arınç
(Resent to the mailing list because of too many recipients.)
More information about the openwrt-devel
mailing list