Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   <RaghuramChary.Jallipalli@microchip.com>
To:     <Jisheng.Zhang@synaptics.com>
CC:     <marc.zyngier@arm.com>, <Woojung.Huh@microchip.com>,
        <UNGLinuxDriver@microchip.com>, <davem@davemloft.net>,
        <netdev@vger.kernel.org>, <linux-usb@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] net: lan78xx: fix "enabled interrupts" warninig
Thread-Topic: [PATCH] net: lan78xx: fix "enabled interrupts" warninig
Thread-Index: AQHU7dHV0yp6Fa7I5USr12hPuITf3qYx3ZMggAALEoCAACApYIABBMYAgAIM3VA=
Date:   Wed, 10 Apr 2019 09:20:38 +0000
Message-ID: <BL0PR11MB3329C59EEA6073D8073D23ED9F2E0@BL0PR11MB3329.namprd11.prod.outlook.com>
References: <20190408140301.3dcbccdd@xhacker.debian>
        <BL0PR11MB33292EC33542F7D4FE5208469F2C0@BL0PR11MB3329.namprd11.prod.outlook.com>
        <20190408155947.3efcb1eb@xhacker.debian>
        <BL0PR11MB3329824981AAA87127C157C69F2C0@BL0PR11MB3329.namprd11.prod.outlook.com>
 <20190409092753.39961390@xhacker.debian>
In-Reply-To: <20190409092753.39961390@xhacker.debian>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: microchip.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 96ec3074-88b6-4301-6666-08d6bd95cb97
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 09:20:38.0916
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3249
X-OriginatorOrg: microchip.com
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

> > >
> > > 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
> > >
> > Correct, IRQ domain is generally used in chained irq controllers.
> > Yes, We need to check why irq domain is used in the current driver.
> >
>=20
> It's introduced in the commit cc89c323a30e
>=20
Hi Jisheng,
I had spent some time to look into the history of commit. The reason for ha=
ving irq domain in driver is because of the unavailability of real hardware=
 interrupt, here we have USB interrupt pipe which is not actual interrupt.
So changes were proposed to have pseudo phy interrupt and handlers in phy l=
ib. But later it was suggested to implement linux interrupt controller in d=
river itself.
You can see the archive here https://patchwork.ozlabs.org/patch/564511/
I want to understand if there is any functionality impact with this warning=
? Because I'm afraid if the current changes are removed we might hit some o=
ther issues (or older ones). We have to go through rigorous testing before =
going ahead.

Thanks.