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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <081b9cb6-f5c6-434a-bd14-c043db752cda@genexis.eu>
Date: Mon, 8 Sep 2025 14:12:08 +0200
From: Benjamin Larsson <benjamin.larsson@...exis.eu>
To: Christian Marangi <ansuelsmth@...il.com>,
 Lorenzo Bianconi <lorenzo@...nel.org>, Sean Wang <sean.wang@...nel.org>,
 Linus Walleij <linus.walleij@...aro.org>,
 Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 linux-mediatek@...ts.infradead.org, linux-gpio@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Cc: stable@...r.kernel.org
Subject: Re: [PATCH] pinctrl: airoha: fix wrong MDIO function bitmaks

On 2025-09-08 13:37, Christian Marangi wrote:
> With further testing with an attached Aeonsemi it was discovered that
> the pinctrl MDIO function applied the wrong bitmask. The error was
> probably caused by the confusing documentation related to these bits.
>
> Inspecting what the bootloader actually configure, the SGMII_MDIO_MODE
> is never actually set but instead it's set force enable to the 2 GPIO
> (gpio 1-2) for MDC and MDIO pin.
>
> Applying this configuration permits correct functionality of any
> externally attached PHY.


Hi, the hardware design guide mentions that gpio1 and gpio2 has some 
limitations when the mdio function is used and there is a chip errata 
for the 7581 that also mentions mdio. This indicates that the SoC has 
issues with mdio function to pin routing.

During my testing it seemed like the gpio1 and gpio2 pins where bridged 
to the mdc/mdio pins (they are not the same). When setting force enable 
on gpio1/gpio2 the bridging stopped and the pins seemed to return to the 
gpio1/2 function. Without the force enable set my guess is that the 
bridged gpio pins pull-up or pull-down is enough to interfere with mdio 
bus signal integrity causing the external phy issues.

Thus ACK from me to this change.

MvH

Benjamin Larsson


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ