[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220223151556.45a45c39@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
Date: Wed, 23 Feb 2022 15:15:56 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Florian Fainelli <f.fainelli@...il.com>
Cc: Peter Robinson <pbrobinson@...il.com>,
Doug Berger <opendmb@...il.com>,
"David S. Miller" <davem@...emloft.net>,
bcm-kernel-feedback-list@...adcom.com, netdev@...r.kernel.org,
Javier Martinez Canillas <javierm@...hat.com>
Subject: Re: [PATCH] net: bcmgenet: Return not supported if we don't have a
WoL IRQ
On Wed, 23 Feb 2022 14:58:13 -0800 Florian Fainelli wrote:
> Yes, this looks more elegant and is certainly more correct.
>
> However there must have been something else going on with Peter's
> provided information.
>
> We clearly did not have an interrupt registered for the Wake-on-LAN
> interrupt line as witnessed by the outputs of /proc/interrupts, however
> if we managed to go past the device_can_wakeup() check in
> bcmgenet_set_wol(), then we must have had devm_request_irq() return
> success on an invalid interrupt number
My thinking was we never called devm_request_irq().
> or worse, botch the interrupt number in priv->irq1 to the point where
> the handler got re-installed maybe and we only end-up calling
> bcmgenet_wol_isr but no longer bcmgenet_isr1.. Hummm.
You're right, my thinking was maybe some IRQ code casts the IRQ
number to u8, but irq_to_desc() contains no such silliness and
should be exercised on every path :S
Powered by blists - more mailing lists