Re: [PATCH net-next 1/3] dt-bindings: net: fsl, fec: add "fsl, wakeup-irq" property

On 8/8/2021 10:08 PM, Joakim Zhang wrote:

Hi Florian,

quoted

-----Original Message-----
From: Florian Fainelli <f.fainelli@gmail.com>
Sent: 2021年8月5日 17:18
To: Joakim Zhang <redacted>; davem@davemloft.net;
kuba@kernel.org; robh+dt@kernel.org; shawnguo@kernel.org;
s.hauer@pengutronix.de; festevam@gmail.com; andrew@lunn.ch
Cc: kernel@pengutronix.de; dl-linux-imx <redacted>;
netdev@vger.kernel.org; devicetree@vger.kernel.org;
linux-kernel@vger.kernel.org; linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH net-next 1/3] dt-bindings: net: fsl, fec: add "fsl,
wakeup-irq" property



On 8/5/2021 12:46 AM, Joakim Zhang wrote:

quoted

Add "fsl,wakeup-irq" property for FEC controller to select wakeup irq
source.

Signed-off-by: Fugang Duan <redacted>
Signed-off-by: Joakim Zhang <redacted>

Why are not you making use of the standard interrupts-extended property
which allows different interrupt lines to be originating from different interrupt
controllers, e.g.:

interrupts-extended = <&gic GIC_SPI 112 4>, <&wakeup_intc 0>;

Thanks.

AFAIK, interrupts-extended should be used instead of interrupts when a device is connected to multiple interrupt controllers
as it encodes a parent phandle with each interrupt specifier. However, for FEC controller, all interrupt lines are originating from
the same interrupt controllers.

OK, so why this custom property then?

1) FEC controller has up to 4 interrupt lines and all of these are routed to GIC interrupt controller.
2) FEC has a wakeup interrupt signal and always are mixed with other interrupt signals, and then output to one interrupt line.
3) For legacy SoCs, wakeup interrupt are mixed to int0 line, but for i.MX8M serials, are mixed to int2 line.
4) Now driver treat int0 as the wakeup source by default, it is broken for i.MX8M.

I don't really know what to make of your response, it seems to me that 
you are carrying some legacy Device Tree properties that were invented 
when interrupts-extended did not exist and we did not know any better.
-- 
Florian

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel