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 1FF0EC4167D for ; Fri, 14 Jan 2022 09:59:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240162AbiANJ7I convert rfc822-to-8bit (ORCPT ); Fri, 14 Jan 2022 04:59:08 -0500 Received: from mail-ua1-f54.google.com ([209.85.222.54]:35506 "EHLO mail-ua1-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240090AbiANJ7F (ORCPT ); Fri, 14 Jan 2022 04:59:05 -0500 Received: by mail-ua1-f54.google.com with SMTP id m90so16094884uam.2; Fri, 14 Jan 2022 01:59:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=LMpobQFf1iaA0D70o2w2ggZn7pjngkhXQg858+CLGTw=; b=iNuRv7X+axQkS087/SEyVRfO807oDY8shZhs/RwbIOXrSJwDV4ivcCA8aQXWl04XYX 0xvRFdm45/m3AH4F6sxbOGY18vGQ2l6/oslhdN25IV2CEKO714zW5bsExRdX3RfwolLx JOZ8Q2zCT/ZbmuUmFJtoLtKwr5MtpKkiuujFgB9cwtyyMz7kjl4E+gjXU6RAH9G6s8g1 LtcYRGzW3Y5fNoXLxX4i3HiicVj9EHd2ZOyNcOZfA87BCQYltk85FuYKaCBSzHDZ4OeQ e9xAelfLcLlrvyDQHKJNjblWo5Nf89OJdMHR4liKWiRYvo+IGKjZbjYzvvyoO5COMZ6w Q9wg== X-Gm-Message-State: AOAM532sLVmq0HXIdflqmaOJLCYgtWMac8I4GsATtNywZZTwzimhwn5A /VD3wdy52bHeuAx5iNkeZdGttDvg1uOEqEhH X-Google-Smtp-Source: ABdhPJxHh8EdXSh3VBEjuVDDfqaR9RmxXk44chjxPH7GeQ/Gjo5pr5JcrJn3S8edkLsVjYbwAobZ+w== X-Received: by 2002:a67:e905:: with SMTP id c5mr3767905vso.68.1642154343755; Fri, 14 Jan 2022 01:59:03 -0800 (PST) Received: from mail-ua1-f48.google.com (mail-ua1-f48.google.com. [209.85.222.48]) by smtp.gmail.com with ESMTPSA id u33sm2226584uau.7.2022.01.14.01.59.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Jan 2022 01:59:03 -0800 (PST) Received: by mail-ua1-f48.google.com with SMTP id p1so16004267uap.9; Fri, 14 Jan 2022 01:59:02 -0800 (PST) X-Received: by 2002:a67:e905:: with SMTP id c5mr3767888vso.68.1642154342466; Fri, 14 Jan 2022 01:59:02 -0800 (PST) MIME-Version: 1.0 References: <20220112085009.dbasceh3obfok5dc@pengutronix.de> <20220112213121.5ruae5mxwj6t3qiy@pengutronix.de> <20220113110831.wvwbm75hbfysbn2d@pengutronix.de> <20220113194358.xnnbhsoyetihterb@pengutronix.de> <1df04d74-8aa2-11f1-54e9-34d0e8f4e58b@omp.ru> <20220113224319.akljsjtu7ps75vun@pengutronix.de> In-Reply-To: <20220113224319.akljsjtu7ps75vun@pengutronix.de> From: Geert Uytterhoeven Date: Fri, 14 Jan 2022 10:58:51 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] driver core: platform: Rename platform_get_irq_optional() to platform_get_irq_silent() To: =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= Cc: Sergey Shtylyov , Mark Brown , Andrew Lunn , Ulf Hansson , Vignesh Raghavendra , KVM list , "Rafael J. Wysocki" , linux-iio@vger.kernel.org, Linus Walleij , Amit Kucheria , ALSA Development Mailing List , Jaroslav Kysela , Guenter Roeck , Thierry Reding , MTD Maling List , Linux I2C , "open list:GPIO SUBSYSTEM" , Miquel Raynal , linux-phy@lists.infradead.org, netdev , linux-spi , Jiri Slaby , Khuong Dinh , Florian Fainelli , Matthias Schiffer , Kamal Dasu , Lee Jones , Bartosz Golaszewski , Daniel Lezcano , Kishon Vijay Abraham I , "open list:SERIAL DRIVERS" , bcm-kernel-feedback-list , Zhang Rui , platform-driver-x86@vger.kernel.org, Linux PWM List , Robert Richter , Saravanan Sekar , Corey Minyard , Linux PM list , Liam Girdwood , Mauro Carvalho Chehab , John Garry , Takashi Iwai , Peter Korsgaard , William Breathitt Gray , Mark Gross , Hans de Goede , Alex Williamson , Borislav Petkov , Jakub Kicinski , Matthias Brugger , openipmi-developer@lists.sourceforge.net, Andy Shevchenko , Benson Leung , Pengutronix Kernel Team , Linux ARM , linux-edac@vger.kernel.org, Tony Luck , Richard Weinberger , Mun Yew Tham , Eric Auger , Greg Kroah-Hartman , Yoshihiro Shimoda , Cornelia Huck , Linux MMC List , Joakim Zhang , Linux Kernel Mailing List , Linux-Renesas , Vinod Koul , James Morse , Zha Qipeng , Sebastian Reichel , =?UTF-8?Q?Niklas_S=C3=B6derlund?= , linux-mediatek@lists.infradead.org, Brian Norris , "David S. Miller" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Uwe, On Thu, Jan 13, 2022 at 11:43 PM Uwe Kleine-König wrote: > On Thu, Jan 13, 2022 at 11:57:43PM +0300, Sergey Shtylyov wrote: > > On 1/13/22 11:17 PM, Mark Brown wrote: > > >> The subsystems regulator, clk and gpio have the concept of a dummy > > >> resource. For regulator, clk and gpio there is a semantic difference > > >> between the regular _get() function and the _get_optional() variant. > > >> (One might return the dummy resource, the other won't. Unfortunately > > >> which one implements which isn't the same for these three.) The > > >> difference between platform_get_irq() and platform_get_irq_optional() is > > >> only that the former might emit an error message and the later won't. > > > > This is only a current difference but I'm still going to return 0 ISO > > -ENXIO from latform_get_irq_optional(), no way I'd leave that -ENXIO there > > alone... :-) > > This would address a bit of the critic in my commit log. But as 0 isn't > a dummy value like the dummy values that exist for clk, gpiod and > regulator I still think that the naming is a bad idea because it's not > in the spirit of the other *_get_optional functions. > > Seeing you say that -ENXIO is a bad return value for > platform_get_irq_optional() and 0 should be used instead, I wonder why > not changing platform_get_irq() to return 0 instead of -ENXIO, too. > This question is for now only about a sensible semantic. That actually > changing platform_get_irq() is probably harder than changing > platform_get_irq_optional() is a different story. > > If only platform_get_irq_optional() is changed and given that the > callers have to do something like: > > if (this_irq_exists()): > ... (e.g. request_irq) > else: > ... (e.g. setup polling) > > I really think it's a bad idea that this_irq_exists() has to be > different for platform_get_irq() vs. platform_get_irq_optional(). For platform_get_irq(), the IRQ being absent is an error condition, hence it should return an error code. For platform_get_irq_optional(), the IRQ being absent is not an error condition, hence it should not return an error code, and 0 is OK. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds