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 ED76FC28B2B for ; Thu, 18 Aug 2022 12:25:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244667AbiHRMZ4 (ORCPT ); Thu, 18 Aug 2022 08:25:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50312 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244660AbiHRMZy (ORCPT ); Thu, 18 Aug 2022 08:25:54 -0400 Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 739EB51A1F for ; Thu, 18 Aug 2022 05:25:52 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id uj29so3003018ejc.0 for ; Thu, 18 Aug 2022 05:25:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=x0RShv55l/W/hrmKR8OYqxZUhnouhDYQRtTeXp8f/Qw=; b=lZ9fW+MCVefOON5qJ+e2DPSKF5jc/FVhapsMLSbW36/Aoxpf8P3q9JjAR4x9BkyWSW GIzQsuap3wNpnXkMbS0c61U4Q/4lvGcjQSRSvQSul/sbVOBgqxVgnLjsM2D0milhZDfK WKAfAduMVIfUfT7NaGekeIAmtsyC/bceHS5BtOwWxyVzXFOUyux0GBc/wDUrg2tU5ExF TLTP06xtOrnGtd5cWuoaC1nYPN1Z6vrIapM4EVLtlowPno7Y14WaBSv1PPgl7aydcjOq HfVY38U0TB+sCZLNzPBX3BFEMqj/p25Cx+p2PDpcEvaGWU2tgJGBExICeiPPRzWtT/P4 SfAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=x0RShv55l/W/hrmKR8OYqxZUhnouhDYQRtTeXp8f/Qw=; b=M8sgtfyynHzpZwH2TNsWVd/7UJuBUQSX5gNn/vxk6nXF1DJOvAqRnAUMitHl/DGBR/ zdb8mAKLO23OOhlu+TgC6jv0qtnVXSPKxBQYXUSgL089n367UvkrIqtXskl6BbiZixAc X6exWIALQFaxFGb564tygg0eNivrAJf4vzYkRRE+RW9RyykY2omq+Lxaae73GW+bR0+f j/fJSHM5n0bC6f9n4rRmjCt6QSDK/WCJkw5bTKkV3glc/6ND2IocqjZgqUwStcfBKK5S AEadjjy9uwuc6kNDQzXAdVskp2Q6nv+9HM+6mJrEhd8Hk5yywQz8u/9HPs6+CQIaIOUl 1p/A== X-Gm-Message-State: ACgBeo3YAXVk4+dWZZwYx9Oh40zGUAU+qL0WIQn+zNPLaXeSj0/QiF5K omVvcoTNcLt0id2kPEkPJvdSCU0bvuQivmxXick3rA== X-Google-Smtp-Source: AA6agR5CE0C/0zXbtuj+66ciKdo9mpd1YPbVFePdX1QU77PTiyuZXegpfkZn+8D69HVLOBrXNL00Nz+vaZxgIKdqlxE= X-Received: by 2002:a17:906:58c8:b0:6fe:91d5:18d2 with SMTP id e8-20020a17090658c800b006fe91d518d2mr1801717ejs.190.1660825551004; Thu, 18 Aug 2022 05:25:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Linus Walleij Date: Thu, 18 Aug 2022 14:25:39 +0200 Message-ID: Subject: Re: [PATCH] gpio: Allow user to customise maximum number of GPIOs To: Arnd Bergmann , Alexandre Courbot , Alexandre Courbot , Bartosz Golaszewski Cc: Christophe Leroy , Jonathan Corbet , Russell King , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , "H. Peter Anvin" , "open list:GPIO SUBSYSTEM" , "open list:DOCUMENTATION" , open list , "moderated list:ARM PORT" , "open list:GENERIC INCLUDE/ASM HEADER FILES" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Aug 18, 2022 at 1:33 PM Arnd Bergmann wrote: > On Thu, Aug 18, 2022 at 1:13 PM Linus Walleij wrote: > > static inline bool gpio_is_valid(int number) > > { > > return number >= 0 && number < ARCH_NR_GPIOS; > > } > > > > ? > > > > If using GPIO descriptors, any descriptor != NULL is valid, > > this one is just used with legacy GPIOs. Maybe we should just > > delete gpio_is_valid() everywhere and then drop the cap? > > I think it makes sense to keep gpio_is_valid() for as long as we > support the numbers. Hmmm.... > > I think there may be systems and users that still depend on GPIO base > > numbers being assigned from ARCH_NR_GPIOS and > > downwards (userspace GPIO numbers in sysfs will also change...) > > otherwise we could assign from 0 and up. > > Is it possible to find in-kernel users that depend on well-known > numbers for dynamically assigned gpios? I would argue > that those are always broken. Most in-kernel users hard-code the base to something like 0 etc it's only the ones that code -1 into .base that are in trouble because that will activate dynamic assignment for the base. git grep 'base = -1' yields these suspects: arch/arm/common/sa1111.c: sachip->gc.base = -1; arch/arm/common/scoop.c: devptr->gpio.base = -1; arch/powerpc/platforms/52xx/mpc52xx_gpt.c: gpt->gc.base = -1; arch/powerpc/platforms/83xx/mcu_mpc8349emitx.c: gc->base = -1; That's all! We could just calculate these to 512-ngpios and hardcode that instead. > Even for the sysfs interface, it is questionable to rely on > specific numbers because at least in an arm multiplatform > kernel the top number changes based on kernel configuration. Yeah :/ still these users tend to angrily report any breakage due to expected (fragile) behaviour. > > Right now the safest would be: > > Assign from 512 and downwards until we hit 0 then assign > > from something high, like U32_MAX and downward. > > > > That requires dropping gpio_is_valid() everywhere. > > > > If we wanna be bold, just delete gpio_is_valid() and assign > > bases from 0 and see what happens. But I think that will > > lead to regressions. > > I'm still unsure how removing gpio_is_valid() would help. If we allow GPIO base all the way to U32_MAX this function becomes: static inline bool gpio_is_valid(int number) { return number >= 0 && number < U32_MAX; } and we can then just #define gpio_is_valid true and in that case it is better to delete the use of this function altogether since it can not fail. > What I could imagine as a next step would be to mark all > consumer drivers and the sysfs interface that use gpio > numbers as 'depends on GPIO_LEGACY' and then only > provide the corresponding drivers if that option is set. Hm I wonder what Bartosz and Alexandre Courbot and thinks about a GPIO_LEGACY symbol to phase out the global GPIO numberspace. I kind of like the idea. I made the sysfs depend on CONFIG_EXPERT to at least make it less accessible and not provide users with guns to shoot themselves in the foot. Yours, Linus Walleij