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

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]

Date:   Wed, 11 Aug 2021 07:57:46 +0000
From:   Joakim Zhang <qiangqing.zhang@....com>
To:     Andrew Lunn <andrew@...n.ch>
CC:     Florian Fainelli <f.fainelli@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "festevam@...il.com" <festevam@...il.com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        dl-linux-imx <linux-imx@....com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH net-next 1/3] dt-bindings: net: fsl, fec: add "fsl,
 wakeup-irq" property


Hi Andrew,

> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: 2021年8月10日 22:33
> To: Joakim Zhang <qiangqing.zhang@....com>
> Cc: Florian Fainelli <f.fainelli@...il.com>; davem@...emloft.net;
> kuba@...nel.org; robh+dt@...nel.org; shawnguo@...nel.org;
> s.hauer@...gutronix.de; festevam@...il.com; kernel@...gutronix.de;
> dl-linux-imx <linux-imx@....com>; netdev@...r.kernel.org;
> devicetree@...r.kernel.org; linux-kernel@...r.kernel.org;
> linux-arm-kernel@...ts.infradead.org
> Subject: Re: [PATCH net-next 1/3] dt-bindings: net: fsl, fec: add "fsl,
> wakeup-irq" property
> 
> > > > 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.
> 
> So you need to know which of the interrupts listed is the wake up interrupt.
> 
> I can see a few ways to do this:
> 
> The FEC driver already has quirks. Add a quirk to fec_imx8mq_info and
> fec_imx8qm_info to indicate these should use int2.
> 
> or
> 
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> 
>   b) two cells
>   ------------
>   The #interrupt-cells property is set to 2 and the first cell defines the
>   index of the interrupt within the controller, while the second cell is used
>   to specify any of the following flags:
>     - bits[3:0] trigger type and level flags
>         1 = low-to-high edge triggered
>         2 = high-to-low edge triggered
>         4 = active high level-sensitive
>         8 = active low level-sensitive
> 
> You could add
> 
>        18 = wakeup source
> 
> and extend to core to either do all the work for you, or tell you this interrupt is
> flagged as being a wakeup source. This solution has the advantage of it should
> be usable in other drivers.

Thanks a lot for your comments first!

I just look into the irq code, if we extend bit[5] to carry wakeup info ( due to bit[4] is used for IRQ_TYPE_PROBE), 
then configure it in the TYPE field of 'interrupts' property, so that interrupt controller would know which interrupt
is wakeup capable. 
I think there is no much work core would do, may just set this interrupt wakup capable. Another functionality is
driver side get this info to identify which mixed interrupt has wakeup capability, we can export symbol from kernel/irq/irqdomain.c.

The intention is to let driver know which interrupt is wakeup capable, I would choose to provider this in specific driver,
instead of interrupt controller, it seems to me that others may all choose this solution for wakeup mixed interrupt.

So I would prefer solution 1, it's easier and under-control. I can have a try if you strongly recommend solution 2.

Best Regards,
Joakim Zhang
> 	  Andrew