All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Shtylyov <s.shtylyov@omp.ru>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <linux-usb@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-samsung-soc@vger.kernel.org>
Subject: Re: [PATCH v2 01/22] usb: host: ehci-exynos: deny IRQ0
Date: Tue, 2 Nov 2021 23:45:13 +0300	[thread overview]
Message-ID: <c2b708d6-174b-65d6-7e41-c1d12f606110@omp.ru> (raw)
In-Reply-To: <YYFDZb35RK+lWdgi@kroah.com>

HEllo!

On 11/2/21 4:55 PM, Greg Kroah-Hartman wrote:

[...]
>>>> If platform_get_irq() returns IRQ0 (considered invalid according to Linus)
>>>> the driver blithely passes it to usb_add_hcd() that treats IRQ0 as no IRQ
>>>> at all. Deny IRQ0 right away, returning -EINVAL from the probe() method...
>>>>
>>>> Fixes: 44ed240d6273 ("usb: host: ehci-exynos: Fix error check in exynos_ehci_probe()")
>>>> Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
>>>> Acked-by: Alan Stern <stern@rowland.harvard.edu>
[...]

>>> Otherwise you
>>> will have to fix ALL callers, and people will always get it wrong.
>>> Fix the root cause here, don't paper it over.
>>
>>    As I have already told you, I won't have to do it as filtering out is only needed iff 0 is
>> used as an indication for something special. IRQ0 is still perfectly valid for request_irq()
>> and is even called by arch/{aplha|mips|x86}...

   "And the latter is called with 0 by", I meant to type... :-/
   The arguments I've heard for this ambiguity to continue were that IRQ0 is requested only with
setup_irq() (no longer true) and that these calls are confined to the arch code (still true).

> If it is valid, then why can it not be a valid irq for all of these
> drivers that you are changing here?  What is preventing them from  
> running on the platforms where 0 is a valid irq value?

   These drivers call usb_add_hcd() that only calls request_irq() (via usb_hcd_request_irqs())
if IRQ # is non-zero -- otherwise the driver is supposed to handle the interrupt itself (if it
needs one?) --thus calling usb_add_hcd() with IRQ0 results in non-working HCD without IRQs...
   (For libata, ata_host_activate() (called in the end of the driver's probe() methods) checks
if the 'irq' parameter is 0 early and in this case warns about the 'irq_handler' parameter being
non-NULL and calls ata_host_register() without registering the IRQ handler and expects the driver
to set the polling flag, thus if IRQ0 is passed from an (unsuspecting) ATA driver, one gets not
fully functional host driver).)

> thanks,
> 
> greg k-h

MBR, Sergey

WARNING: multiple messages have this Message-ID (diff)
From: Sergey Shtylyov <s.shtylyov@omp.ru>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <linux-usb@vger.kernel.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-samsung-soc@vger.kernel.org>
Subject: Re: [PATCH v2 01/22] usb: host: ehci-exynos: deny IRQ0
Date: Tue, 2 Nov 2021 23:45:13 +0300	[thread overview]
Message-ID: <c2b708d6-174b-65d6-7e41-c1d12f606110@omp.ru> (raw)
In-Reply-To: <YYFDZb35RK+lWdgi@kroah.com>

HEllo!

On 11/2/21 4:55 PM, Greg Kroah-Hartman wrote:

[...]
>>>> If platform_get_irq() returns IRQ0 (considered invalid according to Linus)
>>>> the driver blithely passes it to usb_add_hcd() that treats IRQ0 as no IRQ
>>>> at all. Deny IRQ0 right away, returning -EINVAL from the probe() method...
>>>>
>>>> Fixes: 44ed240d6273 ("usb: host: ehci-exynos: Fix error check in exynos_ehci_probe()")
>>>> Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
>>>> Acked-by: Alan Stern <stern@rowland.harvard.edu>
[...]

>>> Otherwise you
>>> will have to fix ALL callers, and people will always get it wrong.
>>> Fix the root cause here, don't paper it over.
>>
>>    As I have already told you, I won't have to do it as filtering out is only needed iff 0 is
>> used as an indication for something special. IRQ0 is still perfectly valid for request_irq()
>> and is even called by arch/{aplha|mips|x86}...

   "And the latter is called with 0 by", I meant to type... :-/
   The arguments I've heard for this ambiguity to continue were that IRQ0 is requested only with
setup_irq() (no longer true) and that these calls are confined to the arch code (still true).

> If it is valid, then why can it not be a valid irq for all of these
> drivers that you are changing here?  What is preventing them from  
> running on the platforms where 0 is a valid irq value?

   These drivers call usb_add_hcd() that only calls request_irq() (via usb_hcd_request_irqs())
if IRQ # is non-zero -- otherwise the driver is supposed to handle the interrupt itself (if it
needs one?) --thus calling usb_add_hcd() with IRQ0 results in non-working HCD without IRQs...
   (For libata, ata_host_activate() (called in the end of the driver's probe() methods) checks
if the 'irq' parameter is 0 early and in this case warns about the 'irq_handler' parameter being
non-NULL and calls ata_host_register() without registering the IRQ handler and expects the driver
to set the polling flag, thus if IRQ0 is passed from an (unsuspecting) ATA driver, one gets not
fully functional host driver).)

> thanks,
> 
> greg k-h

MBR, Sergey

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

  reply	other threads:[~2021-11-02 20:45 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-26 17:39 [PATCH v2 00/22] Explicitly deny IRQ0 in the USB host drivers Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 01/22] usb: host: ehci-exynos: deny IRQ0 Sergey Shtylyov
2021-10-26 17:39   ` Sergey Shtylyov
2021-10-30  8:54   ` Greg Kroah-Hartman
2021-10-30  8:54     ` Greg Kroah-Hartman
2021-11-01 20:39     ` Sergey Shtylyov
2021-11-01 20:39       ` Sergey Shtylyov
2021-11-02 13:55       ` Greg Kroah-Hartman
2021-11-02 13:55         ` Greg Kroah-Hartman
2021-11-02 20:45         ` Sergey Shtylyov [this message]
2021-11-02 20:45           ` Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 02/22] usb: host: ehci-mv: " Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 03/22] usb: host: ehci-npcm7xx: " Sergey Shtylyov
2021-10-26 17:39   ` Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 04/22] usb: host: ehci-omap: " Sergey Shtylyov
2021-10-30 19:49   ` kernel test robot
2021-10-30 19:49     ` kernel test robot
2021-10-26 17:39 ` [PATCH v2 05/22] usb: host: ehci-platform: " Sergey Shtylyov
2021-10-26 17:39   ` Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 06/22] usb: host: ehci-spear: " Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 07/22] usb: host: ehci-st: " Sergey Shtylyov
2021-10-26 17:39   ` Sergey Shtylyov
2021-10-27  6:08   ` Patrice CHOTARD
2021-10-27  6:08     ` Patrice CHOTARD
2021-10-26 17:39 ` [PATCH v2 08/22] usb: host: ohci-at91: " Sergey Shtylyov
2021-10-26 17:39   ` Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 09/22] usb: host: ohci-da8xx: " Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 10/22] usb: host: ohci-exynos: " Sergey Shtylyov
2021-10-26 17:39   ` Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 11/22] usb: host: ohci-nxp: " Sergey Shtylyov
2021-10-26 17:39   ` Sergey Shtylyov
2021-10-26 18:25   ` Vladimir Zapolskiy
2021-10-26 18:25     ` Vladimir Zapolskiy
2021-10-26 17:39 ` [PATCH v2 12/22] usb: host: ohci-omap: " Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 13/22] usb: host: ohci-platform: " Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 14/22] usb: host: ohci-pxa27x: " Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 15/22] usb: host: ohci-sm501: " Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 16/22] usb: host: ohci-spear: " Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 17/22] usb: host: ohci-st: " Sergey Shtylyov
2021-10-26 17:39   ` Sergey Shtylyov
2021-10-27  6:08   ` Patrice CHOTARD
2021-10-27  6:08     ` Patrice CHOTARD
2021-10-26 17:39 ` [PATCH v2 18/22] usb: host: ohci-tmio: " Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 19/22] usb: host: xhci-histb: " Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 20/22] usb: host: xhci-mtk: " Sergey Shtylyov
2021-10-26 17:39   ` Sergey Shtylyov
2021-10-26 17:39   ` Sergey Shtylyov
2021-10-27  8:54   ` Chunfeng Yun
2021-10-27  8:54     ` Chunfeng Yun
2021-10-27  8:54     ` Chunfeng Yun
2021-10-27  9:18   ` Chunfeng Yun
2021-10-27  9:18     ` Chunfeng Yun
2021-10-27  9:18     ` Chunfeng Yun
2021-10-27  9:25     ` Sergey Shtylyov
2021-10-27  9:25       ` Sergey Shtylyov
2021-10-27  9:25       ` Sergey Shtylyov
2021-10-27  9:35       ` Chunfeng Yun
2021-10-27  9:35         ` Chunfeng Yun
2021-10-27  9:35         ` Chunfeng Yun
2021-10-26 17:39 ` [PATCH v2 21/22] usb: host: xhci-plat: " Sergey Shtylyov
2021-10-26 17:39 ` [PATCH v2 22/22] usb: host: xhci-tegra: " Sergey Shtylyov
2021-10-30 22:08   ` kernel test robot
2021-10-30 22:08     ` kernel test robot

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=c2b708d6-174b-65d6-7e41-c1d12f606110@omp.ru \
    --to=s.shtylyov@omp.ru \
    --cc=gregkh@linuxfoundation.org \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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.