linux-kernel - Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

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:   Fri, 2 Mar 2018 12:59:07 +0000
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Wolfram Sang <wsa@...-dreams.de>
Cc:     Krzysztof Kozlowski <krzk@...nel.org>,
        Kukjin Kim <kgene@...nel.org>,
        linux-arm-kernel@...ts.infradead.org,
        linux-samsung-soc@...r.kernel.org, linux-i2c@...r.kernel.org,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Ben Dooks <ben-linux@...ff.org>,
        Dan Carpenter <dan.carpenter@...cle.com>
Subject: Re: [PATCH] i2c: s3c2410: Properly handle interrupts of number 0

On Fri, Mar 02, 2018 at 01:46:47PM +0100, Wolfram Sang wrote:
> 
> So, maybe some words why I accepted this patch.
> 
> On Fri, Mar 02, 2018 at 11:19:31AM +0000, Russell King - ARM Linux wrote:
> > Note that there have been patches proposed to make platform_get_irq()
> > return an error rather than returning a value of zero, so changing
> > the driver in this way is not a good idea.
> 
> I'd much agree to such an approach, yet I didn't see it coming along so
> far for years(?) now.

It needs platform maintainers to be motivated to fix it, and one way to
provide that motivation is for subsystem maintainers to say no to patches
like this.  If patches like this get accepted, then the "problem" gets
solved, and there is very little motivation to fix the platform itself.

If you look back at the history of this, the times when platforms have
been fixed is when they have a problem exactly like this, and they're
told to fix their platforms IRQ numbering instead of the patch to "fix"
the driver being accepted.

Why fix the interrupt numbering if patches to "fix" drivers get
accepted?

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up