Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AD9ADC433F5 for ; Wed, 12 Jan 2022 16:27:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1355185AbiALQ1Y (ORCPT ); Wed, 12 Jan 2022 11:27:24 -0500 Received: from mga07.intel.com ([134.134.136.100]:23755 "EHLO mga07.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349786AbiALQ1U (ORCPT ); Wed, 12 Jan 2022 11:27:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1642004839; x=1673540839; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=cNBpfFoHqPuz0zcd6tz8l/vAk1K6ivBaRN+f33DpqwQ=; b=ASct3LNplB69yAqS+n1IhiWag76WsMOuPxygSUcyUwyJpgSym3zReXbK IBi1cj4vKrtniZeoru8N6GtDHdpUNoMra1bqMU2He/qi2kTIGemjxHv9y 2jx+WLNvb6r/krRsA1ycLuy1IijnWM7MfEVP7f5JwsysgCyB2WwXyus/z 2ZWsWWKCO9J4Jdzwnqv+/bjIxJrRx3HTPETtmgUcPj1JgDwa3+1agDZoL HzfRl/xMMMLvpNLlrGnL6kPZ4FtfKUUupkoI7ykGeZP90a778xYDq+KEj MN+MOpsOjQBFgSVWS4hyAogwg6HUS8q0ZR87emtfiVDIQLgbH7yMcPj/7 w==; X-IronPort-AV: E=McAfee;i="6200,9189,10224"; a="307120901" X-IronPort-AV: E=Sophos;i="5.88,282,1635231600"; d="scan'208";a="307120901" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2022 08:22:59 -0800 X-IronPort-AV: E=Sophos;i="5.88,282,1635231600"; d="scan'208";a="529239592" Received: from smile.fi.intel.com ([10.237.72.61]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2022 08:22:42 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.95) (envelope-from ) id 1n7gNK-009l6p-Ao; Wed, 12 Jan 2022 18:21:26 +0200 Date: Wed, 12 Jan 2022 18:21:26 +0200 From: Andy Shevchenko To: "Rafael J. Wysocki" Cc: Geert Uytterhoeven , Andrew Lunn , Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= , Ulf Hansson , Vignesh Raghavendra , KVM list , linux-iio@vger.kernel.org, Linus Walleij , Amit Kucheria , ALSA Development Mailing List , Liam Girdwood , Guenter Roeck , Thierry Reding , MTD Maling List , Linux I2C , Miquel Raynal , linux-phy@lists.infradead.org, Jiri Slaby , "David S. Miller" , Khuong Dinh , Florian Fainelli , Matthias Schiffer , Joakim Zhang , Kamal Dasu , Lee Jones , Bartosz Golaszewski , Daniel Lezcano , Tony Luck , Kishon Vijay Abraham I , bcm-kernel-feedback-list , "open list:SERIAL DRIVERS" , Jakub Kicinski , Zhang Rui , Matthias Brugger , Platform Driver , Linux PWM List , Robert Richter , Saravanan Sekar , Corey Minyard , Linux PM list , Mauro Carvalho Chehab , John Garry , Peter Korsgaard , William Breathitt Gray , Mark Gross , "open list:GPIO SUBSYSTEM" , Alex Williamson , Mark Brown , Borislav Petkov , Eric Auger , Takashi Iwai , Jaroslav Kysela , openipmi-developer@lists.sourceforge.net, Benson Leung , Pengutronix Kernel Team , Linux ARM , "open list:EDAC-CORE" , Sergey Shtylyov , Richard Weinberger , Mun Yew Tham , Hans de Goede , Greg Kroah-Hartman , Yoshihiro Shimoda , Cornelia Huck , Linux MMC List , Linux Kernel Mailing List , linux-spi , Linux-Renesas , Vinod Koul , James Morse , Zha Qipeng , Sebastian Reichel , Niklas =?iso-8859-1?Q?S=F6derlund?= , "moderated list:ARM/Mediatek SoC..." , Brian Norris , netdev Subject: Re: [PATCH 1/2] platform: make platform_get_irq_optional() optional Message-ID: References: <20220110195449.12448-1-s.shtylyov@omp.ru> <20220110195449.12448-2-s.shtylyov@omp.ru> <20220110201014.mtajyrfcfznfhyqm@pengutronix.de> <20220112085009.dbasceh3obfok5dc@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 12, 2022 at 03:41:38PM +0100, Rafael J. Wysocki wrote: > On Wed, Jan 12, 2022 at 2:55 PM Geert Uytterhoeven wrote: > > > > Hi Andrew, > > > > On Wed, Jan 12, 2022 at 2:38 PM Andrew Lunn wrote: > > > > If an optional IRQ is not present, drivers either just ignore it (e.g. > > > > for devices that can have multiple interrupts or a single muxed IRQ), > > > > or they have to resort to polling. For the latter, fall-back handling > > > > is needed elsewhere in the driver. > > > > 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. > > > > > > The *_optional() functions return an error code if there has been a > > > real error which should be reported up the call stack. This excludes > > > whatever error code indicates the requested resource does not exist, > > > which can be -ENODEV etc. If the device does not exist, a magic cookie > > > is returned which appears to be a valid resources but in fact is > > > not. So the users of these functions just need to check for an error > > > code, and fail the probe if present. > > > > Agreed. > > > > Note that in most (all?) other cases, the return type is a pointer > > (e.g. to struct clk), and NULL is the magic cookie. > > > > > You seems to be suggesting in binary return value: non-zero > > > (available) or zero (not available) > > > > Only in case of success. In case of a real failure, an error code > > must be returned. > > > > > This discards the error code when something goes wrong. That is useful > > > information to have, so we should not be discarding it. > > > > No, the error code must be retained in case of failure. > > > > > IRQ don't currently have a magic cookie value. One option would be to > > > add such a magic cookie to the subsystem. Otherwise, since 0 is > > > invalid, return 0 to indicate the IRQ does not exist. > > > > Exactly. And using 0 means the similar code can be used as for other > > subsystems, where NULL would be returned. > > > > The only remaining difference is the "dummy cookie can be passed > > to other functions" behavior. Which is IMHO a valid difference, > > as unlike with e.g. clk_prepare_enable(), you do pass extra data to > > request_irq(), and sometimes you do need to handle the absence of > > the interrupt using e.g. polling. > > > > > The request for a script checking this then makes sense. However, i > > > don't know how well coccinelle/sparse can track values across function > > > calls. They probably can check for: > > > > > > ret = irq_get_optional() > > > if (ret < 0) > > > return ret; > > > > > > A missing if < 0 statement somewhere later is very likely to be an > > > error. A comparison of <= 0 is also likely to be an error. A check for > > > > 0 before calling any other IRQ functions would be good. I'm > > > surprised such a check does not already existing in the IRQ API, but > > > there are probably historical reasons for that. > > > > There are still a few platforms where IRQ 0 does exist. > > Not just a few even. This happens on a reasonably recent x86 PC: Yes, but the timer doesn't use platform_get_irq*() and friends. > rafael@gratch:~/work/linux-pm> head -2 /proc/interrupts > CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 > 0: 10 0 0 0 0 0 > IR-IO-APIC 2-edge > timer -- With Best Regards, Andy Shevchenko