From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: "RaghuramChary.Jallipalli@microchip.com"
<RaghuramChary.Jallipalli@microchip.com>,
Marc Zyngier <marc.zyngier@arm.com>
Cc: "Woojung.Huh@microchip.com" <Woojung.Huh@microchip.com>,
"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: net: lan78xx: fix "enabled interrupts" warninig
Date: Mon, 8 Apr 2019 08:07:43 +0000 [thread overview]
Message-ID: <20190408155947.3efcb1eb@xhacker.debian> (raw)
On Mon, 8 Apr 2019 07:46:03 +0000 wrote:
>
>
> >
> > Per my understanding, the proper handling of PHY irq is to make use of
> > PHY_IGNORE_INTERRUPT then call phy_mac_interrupt when
> > INT_ENP_PHY_INT is triggered.
> >
>
> Hi Jisheng,
Hi
> Thanks for the changes.
> Is this warning specific to any linux version?
In theory, no. I only tested 5.0, 4.20, both can reproduce this warning.
> Why do you think PHY irq domain handling is not proper?
+ Marc
The warning comes from calling generic_handle_irq() in usb tasklet context.
This is not correct.
Per my understanding, if there's chained irq, we could introduce extra
irqdomain. E.g
GIC <--> another irqchip controller <--> HW device
But in lan78xx, this is not the case. There's no chained irq at all.
In fact, there's a bit INT_ENP_PHY_INT in MAC's Interrupt Endpoint status
word to indicate this is PHY interrupt. So this is the case
PHY_IGNORE_INTERRUPT/phy_mac_interrupt intend for.
irq experts knows irqdomain etc better, maybe they can provide more inputs
> Maybe we can fix that rather removing complete IRQ domain code changes.
> Also, Can you pls let us know how this changes fixed your warning.
The patch removes the generic_handle_irq() calling from invalid context.
Thanks
WARNING: multiple messages have this Message-ID (diff)
From: Jisheng Zhang <Jisheng.Zhang@synaptics.com>
To: "RaghuramChary.Jallipalli@microchip.com"
<RaghuramChary.Jallipalli@microchip.com>,
Marc Zyngier <marc.zyngier@arm.com>
Cc: "Woojung.Huh@microchip.com" <Woojung.Huh@microchip.com>,
"UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>,
"davem@davemloft.net" <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] net: lan78xx: fix "enabled interrupts" warninig
Date: Mon, 8 Apr 2019 08:07:43 +0000 [thread overview]
Message-ID: <20190408155947.3efcb1eb@xhacker.debian> (raw)
Message-ID: <20190408080743.IEymZuP5HkYF7PD4mM5m8UbxjA3VRCmYjRrFH_hr-Fw@z> (raw)
In-Reply-To: <BL0PR11MB33292EC33542F7D4FE5208469F2C0@BL0PR11MB3329.namprd11.prod.outlook.com>
On Mon, 8 Apr 2019 07:46:03 +0000 wrote:
>
>
> >
> > Per my understanding, the proper handling of PHY irq is to make use of
> > PHY_IGNORE_INTERRUPT then call phy_mac_interrupt when
> > INT_ENP_PHY_INT is triggered.
> >
>
> Hi Jisheng,
Hi
> Thanks for the changes.
> Is this warning specific to any linux version?
In theory, no. I only tested 5.0, 4.20, both can reproduce this warning.
> Why do you think PHY irq domain handling is not proper?
+ Marc
The warning comes from calling generic_handle_irq() in usb tasklet context.
This is not correct.
Per my understanding, if there's chained irq, we could introduce extra
irqdomain. E.g
GIC <--> another irqchip controller <--> HW device
But in lan78xx, this is not the case. There's no chained irq at all.
In fact, there's a bit INT_ENP_PHY_INT in MAC's Interrupt Endpoint status
word to indicate this is PHY interrupt. So this is the case
PHY_IGNORE_INTERRUPT/phy_mac_interrupt intend for.
irq experts knows irqdomain etc better, maybe they can provide more inputs
> Maybe we can fix that rather removing complete IRQ domain code changes.
> Also, Can you pls let us know how this changes fixed your warning.
The patch removes the generic_handle_irq() calling from invalid context.
Thanks
next reply other threads:[~2019-04-08 8:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-08 8:07 Jisheng Zhang [this message]
2019-04-08 8:07 ` [PATCH] net: lan78xx: fix "enabled interrupts" warninig Jisheng Zhang
-- strict thread matches above, loose matches on Subject: below --
2019-04-22 5:32 Raghuram Chary J
2019-04-22 5:32 ` [PATCH] " RaghuramChary.Jallipalli
2019-04-17 8:22 Jisheng Zhang
2019-04-17 8:22 ` [PATCH] " Jisheng Zhang
2019-04-17 3:49 Raghuram Chary J
2019-04-17 3:49 ` [PATCH] " RaghuramChary.Jallipalli
2019-04-10 10:27 Marc Zyngier
2019-04-10 10:27 ` [PATCH] " Marc Zyngier
2019-04-10 9:53 Jisheng Zhang
2019-04-10 9:53 ` [PATCH] " Jisheng Zhang
2019-04-10 9:20 Raghuram Chary J
2019-04-10 9:20 ` [PATCH] " RaghuramChary.Jallipalli
2019-04-09 5:26 Raghuram Chary J
2019-04-09 5:26 ` [PATCH] " RaghuramChary.Jallipalli
2019-04-09 1:36 Jisheng Zhang
2019-04-09 1:36 ` [PATCH] " Jisheng Zhang
2019-04-08 10:46 Raghuram Chary J
2019-04-08 10:46 ` [PATCH] " RaghuramChary.Jallipalli
2019-04-08 7:46 Raghuram Chary J
2019-04-08 7:46 ` [PATCH] " RaghuramChary.Jallipalli
2019-04-08 6:10 Jisheng Zhang
2019-04-08 6:10 ` [PATCH] " Jisheng Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190408155947.3efcb1eb@xhacker.debian \
--to=jisheng.zhang@synaptics.com \
--cc=RaghuramChary.Jallipalli@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=Woojung.Huh@microchip.com \
--cc=davem@davemloft.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.