linux-kernel - Re: [PATCH v5 4/4] ARM: dts: stm32: add initial support for stm32mp157-ultra-fly-sbc board

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] [day] [month] [year] [list]

Message-ID: <66fb604a-ce90-41c4-9ce9-26fa1d81e0d2@foss.st.com>
Date: Mon, 12 May 2025 11:45:17 +0200
From: Alexandre TORGUE <alexandre.torgue@...s.st.com>
To: Goran Radenovic <goran.radni@...il.com>, Andrew Lunn <andrew@...n.ch>
CC: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Börge Strümpfel
	<boerge.struempfel@...il.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-stm32@...md-mailman.stormreply.com>,
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v5 4/4] ARM: dts: stm32: add initial support for
 stm32mp157-ultra-fly-sbc board

Hi Goran

On 5/8/25 15:10, Goran Radenovic wrote:
> Hi Andrew,
> 
> thank You once again for helpful hint.
> 
> Andrew Lunn wrote:
>>>>> +    phy-handle = <&phy1>;
>>>>> +
>>>>> +    mdio {
>>>>> +        #address-cells = <1>;
>>>>> +        #size-cells = <0>;
>>>>> +        compatible = "snps,dwmac-mdio";
>>>>> +        phy1: ethernet-phy@1 {
>>>>> +            reg = <1>;
>>>>> +            interrupt-parent = <&gpiod>;
>>>>> +            interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
>>>> PHY interrupts are 99% time level, not edge.
>>> That is correct, but I am facing strange behavior, when I set
>>> IRQ_TYPE_LEVEL_LOW.
>>> My board stops booting at:
>>>
>>> [    2.343233] Waiting for root device /dev/mmcblk0p4...
>>> [   12.638818] platform 5a006000.usbphyc: deferred probe pending
>>> [   12.643192] platform 49000000.usb-otg: deferred probe pending
>>> [   12.649029] platform 48003000.adc: deferred probe pending
>>> [   12.654277] platform 5800d000.usb: deferred probe pending
>>> [   12.659744] platform 5800c000.usb: deferred probe pending
>>> [   12.665089] amba 58005000.mmc: deferred probe pending
>>> [   12.670239] amba 58007000.mmc: deferred probe pending
>>> [   12.675185] platform 50025000.vrefbuf: deferred probe pending
>>>
>>> I must investigate this. If You have any idea, You are welcome to 
>>> share it.
>> Could be an interrupt storm. The interrupt is not getting cleared
>> because of something missing in the PHY driver, so it just fires again
>> and again.
> 
> After a brief investigation, I tend to agree with your assessment that 
> the issue lies in the driver—likely the stmmac driver — which is outside 
> the scope of my changes.

No, the mdio node is driven by stmmac driver. The issue was maybe more 
linked between pinctrl driver / exti driver where the level trigger is 
probably not well managed (gpio is level but exti driver manage edge 
interrupt). When saw those defering probes, EXTI drivers and pinctrl 
drivers were well probed ?

> 
> Therefore, I would suggest keeping IRQ_TYPE_EDGE_FALLING for now, or 
> alternatively not using a hardware IRQ at all and falling back to 
> polling, as done in stm32mp15xx-dkx.dtsi.
> 
> Best regards,
> Goran