netdev - Re: MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <acf98ec3-1120-bcc0-2a2f-85d97c48febd@gmail.com>
Date:   Mon, 24 Jan 2022 09:13:38 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>,
        Arınç ÜNAL <arinc.unal@...nc9.com>
Cc:     DENG Qingfang <dqfext@...il.com>,
        Luiz Angelo Daros de Luca <luizluca@...il.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        John Crispin <john@...ozen.org>,
        Siddhant Gupta <siddhantgupta416@...il.com>,
        Ilya Lipnitskiy <ilya.lipnitskiy@...il.com>,
        Sergio Paracuellos <sergio.paracuellos@...il.com>,
        Felix Fietkau <nbd@....name>,
        Sean Wang <sean.wang@...iatek.com>,
        Mark Lee <Mark-MC.Lee@...iatek.com>,
        Russell King <linux@...linux.org.uk>,
        Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>,
        René van Dorst <opensource@...rst.com>,
        "moderated list:ARM/Mediatek SoC support" 
        <linux-mediatek@...ts.infradead.org>,
        netdev <netdev@...r.kernel.org>, linux-mips@...r.kernel.org,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, openwrt-devel@...ts.openwrt.org,
        erkin.bozoglu@...ont.com
Subject: Re: MT7621 SoC Traffic Won't Flow on RGMII2 Bus/2nd GMAC



On 1/23/2022 7:26 AM, Andrew Lunn wrote:
> On Sun, Jan 23, 2022 at 11:33:04AM +0300, Arınç ÜNAL wrote:
>> Hey Deng,
>>
>> On 23/01/2022 09:51, DENG Qingfang wrote:
>>> Hi,
>>>
>>> Do you set the ethernet pinmux correctly?
>>>
>>> &ethernet {
>>>       pinctrl-names = "default";
>>>       pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>;
>>> };
>>
>> This fixed it! We did have &rgmii2_pins on the gmac1 node (it was originally
>> on external_phy) so we never thought to investigate the pinctrl
>> configuration further! Turns out &rgmii2_pins needs to be defined on the
>> ethernet node instead.
> 
> PHYs are generally external, so pinmux on them makes no sense. PHYs in
> DT are not devices in the usual sense, so i don't think the driver
> core will handle pinmux for them, even if you did list them.

Not sure I understand your comment here, this is configuring the pinmux 
on the SoC side in order for the second RGMII interface's data path to work.

It is not uncommon for the same set of I/O pads to be used by different 
functions within the chip. For instance the chips I work with happily 
offer RGMII, MTSIF, PDM (I2S), TSIO on the same pads via different 
pinmuxing options.

Also, this is declaring a pinmuxing function for the Ethernet MAC, which 
is a perfectly valid use case and typically how pinmuxing is declared 
for a given SoC.
-- 
Florian