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 4A0C1C4321E for ; Tue, 18 Jan 2022 09:37:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344566AbiARJhn convert rfc822-to-8bit (ORCPT ); Tue, 18 Jan 2022 04:37:43 -0500 Received: from mail-ua1-f44.google.com ([209.85.222.44]:44993 "EHLO mail-ua1-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230172AbiARJhl (ORCPT ); Tue, 18 Jan 2022 04:37:41 -0500 Received: by mail-ua1-f44.google.com with SMTP id f24so1463520uab.11; Tue, 18 Jan 2022 01:37:40 -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=94RJUajJnozufTpAr/gV3w0KHJpzlohNQuBpMs4wyR0=; b=MaJCYAKIZUUHoKESEVDo6QEMbUS0vkztkUHhvTyDRPuvl53gzl04ILCRAu0GnOtVRK Fvsqi1dRCWirqq9t3YmOGL8oXLmj/c+ZZFTIODGLKPlzxX8Ns6wHkpRTbSPaEfsZ36u4 ORN6JM3Oeh3Dc1cjY/4ZEg13C7N7mPArKcEq7Xunw/e8ZvQsNOVSECVOCe87pXr4nh9N 126uQq6/jbqxCCxq2ZjYt3NQ0u+z0wbgBsZz9KBMihq0jkIt+i5HgIS0vNkewXXXDrgQ OYktUJ7DOibltni3K4josLd5pAQEJihshjDkFlMyhvPPj/QLZQ+doQm3IWaMf8wZ+eqx yM4w== X-Gm-Message-State: AOAM533+LPFA5XuBfxDmKTi3x58EAS+txDXKAUOxEGQc+6FNPhMYt6Ro qt8Ud413mJQN8fsYU8zZH1yhJ+BVx0cQyYCj X-Google-Smtp-Source: ABdhPJyw+oic6AsAShUu1MGqZLa67XXZj9G+hQqL+tvjzZ6gUStjqN2CB20oVkNecThrkl9ruBrXVg== X-Received: by 2002:a9f:2424:: with SMTP id 33mr9064060uaq.67.1642498659372; Tue, 18 Jan 2022 01:37:39 -0800 (PST) Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com. [209.85.222.53]) by smtp.gmail.com with ESMTPSA id s47sm3681740uad.17.2022.01.18.01.37.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Jan 2022 01:37:37 -0800 (PST) Received: by mail-ua1-f53.google.com with SMTP id c36so35282332uae.13; Tue, 18 Jan 2022 01:37:37 -0800 (PST) X-Received: by 2002:a67:bc17:: with SMTP id t23mr5014894vsn.57.1642498657061; Tue, 18 Jan 2022 01:37:37 -0800 (PST) MIME-Version: 1.0 References: <61b80939-357d-14f5-df99-b8d102a4e1a1@omp.ru> <20220114202226.ugzklxv4wzr6egwj@pengutronix.de> <20220117092444.opoedfcf5k5u6otq@pengutronix.de> <20220117114923.d5vajgitxneec7j7@pengutronix.de> <20220117170609.yxaamvqdkivs56ju@pengutronix.de> <20220118090913.pjumkq4zf4iqtlha@pengutronix.de> In-Reply-To: <20220118090913.pjumkq4zf4iqtlha@pengutronix.de> From: Geert Uytterhoeven Date: Tue, 18 Jan 2022 10:37:25 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] platform: make platform_get_irq_optional() optional To: =?UTF-8?Q?Uwe_Kleine=2DK=C3=B6nig?= 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, netdev , Jiri Slaby , openipmi-developer@lists.sourceforge.net, Khuong Dinh , Florian Fainelli , Matthias Schiffer , Joakim Zhang , Kamal Dasu , Lee Jones , Bartosz Golaszewski , Daniel Lezcano , Kishon Vijay Abraham I , bcm-kernel-feedback-list , "open list:SERIAL DRIVERS" , Jakub Kicinski , Zhang Rui , Linux PWM List , Robert Richter , Saravanan Sekar , Corey Minyard , Linux PM list , Linux Kernel Mailing List , Mauro Carvalho Chehab , John Garry , Peter Korsgaard , William Breathitt Gray , Mark Gross , Hans de Goede , Alex Williamson , Mark Brown , Borislav Petkov , Sebastian Reichel , Eric Auger , Matthias Brugger , Takashi Iwai , platform-driver-x86@vger.kernel.org, Benson Leung , Linux ARM , linux-edac@vger.kernel.org, Tony Luck , Mun Yew Tham , "open list:GPIO SUBSYSTEM" , Greg Kroah-Hartman , Yoshihiro Shimoda , Cornelia Huck , Linux MMC List , Liam Girdwood , linux-spi , Linux-Renesas , Sergey Shtylyov , 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 , "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 Tue, Jan 18, 2022 at 10:09 AM Uwe Kleine-König wrote: > On Tue, Jan 18, 2022 at 09:25:01AM +0100, Geert Uytterhoeven wrote: > > On Mon, Jan 17, 2022 at 6:06 PM Uwe Kleine-König > > wrote: > > > On Mon, Jan 17, 2022 at 02:08:19PM +0100, Geert Uytterhoeven wrote: > > > > On Mon, Jan 17, 2022 at 12:49 PM Uwe Kleine-König > > > > wrote: > > > > > > So there are three reasons: because the absence of an optional IRQ > > > > > > is not an error, and thus that should not cause (a) an error code > > > > > > to be returned, and (b) an error message to be printed, and (c) > > > > > > because it can simplify the logic in device drivers. > > > > > > > > > > I don't agree to (a). If the value signaling not-found is -ENXIO or 0 > > > > > (or -ENODEV) doesn't matter much. I wouldn't deviate from the return > > > > > code semantics of platform_get_irq() just for having to check against 0 > > > > > instead of -ENXIO. Zero is then just another magic value. > > > > > > > > Zero is a natural magic value (also for pointers). > > > > Errors are always negative. > > > > Positive values are cookies (or pointers) associated with success. > > > > > > Yeah, the issue where we don't agree is if "not-found" is special enough > > > to deserve the natural magic value. For me -ENXIO is magic enough to > > > handle the absence of an irq line. I consider it even the better magic > > > value. > > > > It differs from other subsystems (clk, gpio, reset), which do return > > zero on not found. > > IMHO it doesn't matter at all that the return value is zero, relevant is > the semantic of the returned value. For clk, gpio, reset and regulator > NULL is a usable dummy, for irqs it's not. So what you do with the value > returned by platform_get_irq_whatever() is: you compare it with the > (magic?) not-found value, and if it matches, you enter a suitable > if-block. > > For the (clk|gpiod|regulator)_get_optional() you don't have to check > against the magic not-found value (so no implementation detail magic > leaks into the caller code) and just pass it to the next API function. > (And my expectation would be that if you chose to represent not-found by > (void *)66 instead of NULL, you won't have to adapt any user, just the > framework internal checks. This is a good thing!) Ah, there is the wrong assumption: drivers sometimes do need to know if the resource was found, and thus do need to know about (void *)66, -ENODEV, or -ENXIO. I already gave examples for IRQ and clk before. I can imagine these exist for gpiod and regulator, too, as soon as you go beyond the trivial "enable" and "disable" use-cases. And 0/NULL vs. > 0 is the natural check here: missing, but not an error. Even for IRQ this was envisioned before, when it was decided that vIRQ zero does not exist. (Inconsistent) Error codes are not, as missing optional resources are not error conditions. 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