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
| ||
|
Date: Sun, 16 Jan 2022 21:15:20 +0300 From: Sergey Shtylyov <s.shtylyov@....ru> To: Uwe Kleine-König <u.kleine-koenig@...gutronix.de> CC: Andrew Lunn <andrew@...n.ch>, Ulf Hansson <ulf.hansson@...aro.org>, Vignesh Raghavendra <vigneshr@...com>, KVM list <kvm@...r.kernel.org>, "Rafael J. Wysocki" <rafael@...nel.org>, <linux-iio@...r.kernel.org>, "Linus Walleij" <linus.walleij@...aro.org>, Amit Kucheria <amitk@...nel.org>, "ALSA Development Mailing List" <alsa-devel@...a-project.org>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Jaroslav Kysela <perex@...ex.cz>, Guenter Roeck <groeck@...omium.org>, Thierry Reding <thierry.reding@...il.com>, MTD Maling List <linux-mtd@...ts.infradead.org>, Linux I2C <linux-i2c@...r.kernel.org>, Miquel Raynal <miquel.raynal@...tlin.com>, <linux-phy@...ts.infradead.org>, Jiri Slaby <jirislaby@...nel.org>, <openipmi-developer@...ts.sourceforge.net>, "David S. Miller" <davem@...emloft.net>, Khuong Dinh <khuong@...amperecomputing.com>, Florian Fainelli <f.fainelli@...il.com>, Matthias Schiffer <matthias.schiffer@...tq-group.com>, Joakim Zhang <qiangqing.zhang@....com>, Kamal Dasu <kdasu.kdev@...il.com>, Lee Jones <lee.jones@...aro.org>, "Bartosz Golaszewski" <brgl@...ev.pl>, Daniel Lezcano <daniel.lezcano@...aro.org>, Kishon Vijay Abraham I <kishon@...com>, Geert Uytterhoeven <geert@...ux-m68k.org>, "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>, Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>, bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>, Zhang Rui <rui.zhang@...el.com>, Linux PWM List <linux-pwm@...r.kernel.org>, Robert Richter <rric@...nel.org>, Saravanan Sekar <sravanhome@...il.com>, Corey Minyard <minyard@....org>, Linux PM list <linux-pm@...r.kernel.org>, Liam Girdwood <lgirdwood@...il.com>, Mauro Carvalho Chehab <mchehab@...nel.org>, John Garry <john.garry@...wei.com>, Peter Korsgaard <peter@...sgaard.com>, "William Breathitt Gray" <vilhelm.gray@...il.com>, Mark Gross <markgross@...nel.org>, Hans de Goede <hdegoede@...hat.com>, Alex Williamson <alex.williamson@...hat.com>, Mark Brown <broonie@...nel.org>, "Borislav Petkov" <bp@...en8.de>, Sebastian Reichel <sre@...nel.org>, Jakub Kicinski <kuba@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>, Takashi Iwai <tiwai@...e.com>, <platform-driver-x86@...r.kernel.org>, Benson Leung <bleung@...omium.org>, Linux ARM <linux-arm-kernel@...ts.infradead.org>, <linux-edac@...r.kernel.org>, Tony Luck <tony.luck@...el.com>, Mun Yew Tham <mun.yew.tham@...el.com>, Eric Auger <eric.auger@...hat.com>, "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>, Cornelia Huck <cohuck@...hat.com>, "Linux MMC List" <linux-mmc@...r.kernel.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, linux-spi <linux-spi@...r.kernel.org>, Linux-Renesas <linux-renesas-soc@...r.kernel.org>, Vinod Koul <vkoul@...nel.org>, James Morse <james.morse@....com>, Zha Qipeng <qipeng.zha@...el.com>, Pengutronix Kernel Team <kernel@...gutronix.de>, Richard Weinberger <richard@....at>, Niklas Söderlund <niklas.soderlund@...natech.se>, <linux-mediatek@...ts.infradead.org>, "Brian Norris" <computersforpeace@...il.com>, <netdev@...r.kernel.org> Subject: Re: [PATCH 1/2] platform: make platform_get_irq_optional() optional Hello! On 1/14/22 11:22 PM, Uwe Kleine-König wrote: >>>>>>> To me it sounds much more logical for the driver to check if an >>>>>>> optional irq is non-zero (available) or zero (not available), than to >>>>>>> sprinkle around checks for -ENXIO. In addition, you have to remember >>>>>>> that this one returns -ENXIO, while other APIs use -ENOENT or -ENOSYS >>>>>>> (or some other error code) to indicate absence. I thought not having >>>>>>> to care about the actual error code was the main reason behind the >>>>>>> introduction of the *_optional() APIs. >>>>> >>>>>> No, the main benefit of gpiod_get_optional() (and clk_get_optional()) is >>>>>> that you can handle an absent GPIO (or clk) as if it were available. >>>> >>>> Hm, I've just looked at these and must note that they match 1:1 with >>>> platform_get_irq_optional(). Unfortunately, we can't however behave the >>>> same way in request_irq() -- because it has to support IRQ0 for the sake >>>> of i8253 drivers in arch/... >>> >>> Let me reformulate your statement to the IMHO equivalent: >>> >>> If you set aside the differences between >>> platform_get_irq_optional() and gpiod_get_optional(), >> >> Sorry, I should make it clear this is actually the diff between a would-be >> platform_get_irq_optional() after my patch, not the current code... > > The similarity is that with your patch both gpiod_get_optional() and > platform_get_irq_optional() return NULL and 0 on not-found. The relevant > difference however is that for a gpiod NULL is a dummy value, while for > irqs it's not. So the similarity is only syntactically, but not > semantically. I have noting to say here, rather than optional IRQ could well have a different meaning than for clk/gpio/etc. [...] >>> However for an interupt this cannot work. You will always have to check >>> if the irq is actually there or not because if it's not you cannot just >>> ignore that. So there is no benefit of an optional irq. >>> >>> Leaving error message reporting aside, the introduction of >>> platform_get_irq_optional() allows to change >>> >>> irq = platform_get_irq(...); >>> if (irq < 0 && irq != -ENXIO) { >>> return irq; >>> } else if (irq >= 0) { >> >> Rather (irq > 0) actually, IRQ0 is considered invalid (but still returned). > > This is a topic I don't feel strong for, so I'm sloppy here. If changing > this is all that is needed to convince you of my point ... Note that we should absolutely (and first of all) stop returning 0 from platform_get_irq() on a "real" IRQ0. Handling that "still good" zero absolutely doesn't scale e.g. for the subsystems (like libata) which take 0 as an indication that the polling mode should be used... We can't afford to be sloppy here. ;-) [...] > Best regards > Uwe MBR, Sergey
Powered by blists - more mailing lists