From mboxrd@z Thu Jan 1 00:00:00 1970 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 29C10C433F5 for ; Thu, 13 Jan 2022 21:43:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236112AbiAMVnJ (ORCPT ); Thu, 13 Jan 2022 16:43:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49974 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235254AbiAMVnE (ORCPT ); Thu, 13 Jan 2022 16:43:04 -0500 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C5F8CC06161C; Thu, 13 Jan 2022 13:43:03 -0800 (PST) Received: by mail-pj1-x1030.google.com with SMTP id o3so11765216pjs.1; Thu, 13 Jan 2022 13:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=chMleOaZP5LLYybKEvqzaEnOntGIKeyxzv8RxEMS/pU=; b=oOc3d8quuL+d364W7KNWQtMdgtUPWTOWcsp8cMWNvHDxrhgRW2/iqLsZTnFsASrpLY 68f6X/M1x+sO4IK/5z8GRukqDLM7CHf4rk2qB/zOlWi9G1eAn8tq+zp6RKqI0IPYCVAa hUGAgdHmZB/tYYdmRvOmZ4JNl+7KaTpFtgGI83AIVn9odjlTyVtSNxGjna9I3MmeJxnP LOezyDSKBJbwulklkuNOKWH9DWBVEMZVRl505lf6yiD2x6vDvZWbGecOdmYT0deqt9nE 7oj6Lo5rPX0mYmnixNE6GUUU70z4K2CwYIE2HI3Z8c69J6dTeJP+r1nvFkXQlYsjlWb9 Puog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=chMleOaZP5LLYybKEvqzaEnOntGIKeyxzv8RxEMS/pU=; b=QHOYRG/nrfl4koWEJiDfqsnGR7cx6gwQoWB3GZrWGV5Jm+mGhgU2oJBOVGs1d91qFs YKEalHAq/WhDO3wKhvAAiS8zdXatfsHpJGeNM11Yknr/paokwUvDUHQMS1EqVMpXSTpQ 8JCyWBHqGUEw0SsWI1aDjNvTNarBcn8bW0URJoDmK3TttnoZYva4YHb5nvGBAhftrWiV oN8MSxY/igu+98YFqlmUpz+jxUppzDTy73SFLux8bq9KheaibR+lrzuir7LrZGEGQvmf +gxLyfQcrmZV2rSPj7BhsihZT4GMwq0Il/WkiIqdgS8bHoO+pCI2mOqy3naSVNeCkFCm Yo/A== X-Gm-Message-State: AOAM531lftljLgVSLheaLb+KOHwuzjHS5UQVSYczmzkfm72T5DlB4KDo pPFmwv0thZJf359F6AMOKl0= X-Google-Smtp-Source: ABdhPJza7nTyxaYu7zMa+CS3ya6yZ7jUqwYQkOFFet8Qv/maBjKZ7v19D4TMGEeuYYibqr5z1N9W+A== X-Received: by 2002:a17:902:e790:b0:149:7a3f:826a with SMTP id cp16-20020a170902e79000b001497a3f826amr6595655plb.76.1642110183142; Thu, 13 Jan 2022 13:43:03 -0800 (PST) Received: from ?IPV6:2600:8802:b00:4a48:c1d3:c1c0:b78e:9e36? ([2600:8802:b00:4a48:c1d3:c1c0:b78e:9e36]) by smtp.gmail.com with ESMTPSA id r26sm2983811pgu.65.2022.01.13.13.42.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Jan 2022 13:43:02 -0800 (PST) Message-ID: <745c601f-c782-0904-f786-c9bfced8f11c@gmail.com> Date: Thu, 13 Jan 2022 13:42:57 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: [PATCH] driver core: platform: Rename platform_get_irq_optional() to platform_get_irq_silent() Content-Language: en-US To: =?UTF-8?Q?Uwe_Kleine-K=c3=b6nig?= , Mark Brown Cc: Andrew Lunn , Ulf Hansson , Vignesh Raghavendra , KVM list , "Rafael J. Wysocki" , linux-iio@vger.kernel.org, Linus Walleij , Amit Kucheria , ALSA Development Mailing List , Andy Shevchenko , Jaroslav Kysela , Guenter Roeck , Thierry Reding , MTD Maling List , Linux I2C , Miquel Raynal , linux-phy@lists.infradead.org, Jiri Slaby , openipmi-developer@lists.sourceforge.net, "David S. Miller" , Khuong Dinh , Florian Fainelli , Matthias Schiffer , Joakim Zhang , Kamal Dasu , Lee Jones , Bartosz Golaszewski , Daniel Lezcano , Kishon Vijay Abraham I , Geert Uytterhoeven , "open list:SERIAL DRIVERS" , Yoshihiro Shimoda , bcm-kernel-feedback-list , Zhang Rui , Linux PWM List , Robert Richter , Saravanan Sekar , Corey Minyard , Linux PM list , Liam Girdwood , Mauro Carvalho Chehab , John Garry , Peter Korsgaard , William Breathitt Gray , Mark Gross , Hans de Goede , Alex Williamson , Tony Luck , Borislav Petkov , Sebastian Reichel , Jakub Kicinski , Matthias Brugger , Takashi Iwai , platform-driver-x86@vger.kernel.org, Benson Leung , Linux ARM , linux-edac@vger.kernel.org, Sergey Shtylyov , Mun Yew Tham , Eric Auger , Greg Kroah-Hartman , "open list:GPIO SUBSYSTEM" , Cornelia Huck , Linux MMC List , Linux Kernel Mailing List , linux-spi , Linux-Renesas , Vinod Koul , James Morse , Zha Qipeng , Pengutronix Kernel Team , Richard Weinberger , =?UTF-8?Q?Niklas_S=c3=b6derlund?= , linux-mediatek@lists.infradead.org, Brian Norris , netdev@vger.kernel.org References: <20220110195449.12448-2-s.shtylyov@omp.ru> <20220110201014.mtajyrfcfznfhyqm@pengutronix.de> <20220112085009.dbasceh3obfok5dc@pengutronix.de> <20220112213121.5ruae5mxwj6t3qiy@pengutronix.de> <20220113110831.wvwbm75hbfysbn2d@pengutronix.de> <20220113194358.xnnbhsoyetihterb@pengutronix.de> From: Florian Fainelli In-Reply-To: <20220113194358.xnnbhsoyetihterb@pengutronix.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-serial@vger.kernel.org On 1/13/2022 11:43 AM, Uwe Kleine-König 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. > > To prevent people's expectations that there is a semantic difference > between these too, rename platform_get_irq_optional() to > platform_get_irq_silent() to make the actual difference more obvious. > > The #define for the old name can and should be removed once all patches > currently in flux still relying on platform_get_irq_optional() are > fixed. > > Signed-off-by: Uwe Kleine-König > --- > Hello, > > On Thu, Jan 13, 2022 at 02:45:30PM +0000, Mark Brown wrote: >> On Thu, Jan 13, 2022 at 12:08:31PM +0100, Uwe Kleine-König wrote: >> >>> This is all very unfortunate. In my eyes b) is the most sensible >>> sense, but the past showed that we don't agree here. (The most annoying >>> part of regulator_get is the warning that is emitted that regularily >>> makes customers ask what happens here and if this is fixable.) >> >> Fortunately it can be fixed, and it's safer to clearly specify things. >> The prints are there because when the description is wrong enough to >> cause things to blow up we can fail to boot or run messily and >> forgetting to describe some supplies (or typoing so they haven't done >> that) and people were having a hard time figuring out what might've >> happened. > > Yes, that's right. I sent a patch for such a warning in 2019 and pinged > occationally. Still waiting for it to be merged :-\ > (https://lore.kernel.org/r/20190625100412.11815-1-u.kleine-koenig@pengutronix.de) > >>> I think at least c) is easy to resolve because >>> platform_get_irq_optional() isn't that old yet and mechanically >>> replacing it by platform_get_irq_silent() should be easy and safe. >>> And this is orthogonal to the discussion if -ENOXIO is a sensible return >>> value and if it's as easy as it could be to work with errors on irq >>> lookups. >> >> It'd certainly be good to name anything that doesn't correspond to one >> of the existing semantics for the API (!) something different rather >> than adding yet another potentially overloaded meaning. > > It seems we're (at least) three who agree about this. Here is a patch > fixing the name. From an API naming perspective this does not make much sense anymore with the name chosen, it is understood that whent he function is called platform_get_irq_optional(), optional applies to the IRQ. An optional IRQ is something people can reason about because it makes sense. What is a a "silent" IRQ however? It does not apply to the object it is trying to fetch to anymore, but to the message that may not be printed in case the resource failed to be obtained, because said resource is optional. Woah, that's quite a stretch. Following the discussion and original 2 patches set from Sergey, it is not entirely clear to me anymore what is it that we are trying to fix. I nearly forgot, I would paint it blue, sky blue, not navy blue, not light blue ;) -- Florian