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

[Alexandre TORGUE]

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 at 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