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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EBC22C433F5 for ; Tue, 16 Nov 2021 02:47:15 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id BAF6B61BF8 for ; Tue, 16 Nov 2021 02:47:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org BAF6B61BF8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=jms.id.au Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=P0icb5284cRhOsrBLAL0dUEE3qq6NIlN7qWmWyDUMVE=; b=yTJ8JYAaPMEdpQ XhbauiOWOHX8xyAy+z6+KoOPaATY3ru0HDL4UxEZi0Ln3QgC7h9gs0F2p5ykqVCT0+DU+9pvvG3HN Eg/BnWcAxWVPuRiUni4A2DInDtgApmtvcc4SAqvbN722qH3yEdt5YCAATfNTzQKrs0JjmQQxSIy9M o1gMPzofiISz+k0CnnIPGJPo2avtLjz6iFj5b0AN/W/j8I8GSL6URyIRq5UMEL4yc1I7GchqlOidk ls/Z3kKGMd4a8EH4MzyOrrN8U0NFsdgN3pbhajjjBT6deAwzW23rPihQi4RjwGFNkfXh9zpGp9umY kSjdMCj1zfiNw2gqAq2Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mmoTn-0006wa-E9; Tue, 16 Nov 2021 02:45:52 +0000 Received: from mail-qk1-x72a.google.com ([2607:f8b0:4864:20::72a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mmoSF-0005zm-AY for linux-arm-kernel@lists.infradead.org; Tue, 16 Nov 2021 02:44:16 +0000 Received: by mail-qk1-x72a.google.com with SMTP id g28so14663937qkk.9 for ; Mon, 15 Nov 2021 18:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jms.id.au; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+IsQBHoFAXBIkB1Kw8WNji5f2haXZUreOBVyURuDYXY=; b=l72T4yHHjmckvxjl/bthixU/FwFfghPSs3EadNJjMWX37Etlj/vn2pNjYgjl+dEV+4 YQKDwq6Hl/65E3gKuGjHyRmWm6bE9SYztKS+bGWD5trEp4yVqmVWGia7jT1x2rSCG9Va bAsV/ONCMORPfMlrW4T9/C4ya+OhPhV3+JRxQ= 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; bh=+IsQBHoFAXBIkB1Kw8WNji5f2haXZUreOBVyURuDYXY=; b=lVNdYARBomfqoMgl/C1E13JFUFGHYcnCo57oWDkB1KcAY5ayshF/B9UknryfRK88n2 KhiOQj77+gR5LCUYQOl/c7wznWKu2rXhfSyNoCZX4zzO5n/sDKfMsztC1wnjdjlK2JZF HofrYt85/EdN7Y7em2gVTC8ZiMdJxCZDvcGYJqqHtHZM2uqK9nvOSMcT9bdnHm+cv/m/ T59lvMtNBwocGwiBgUhxt3Ut9kZrnBp26UTR6uP9BK6sw+KyEWKUcHvlckrBSBQUP/8x LlYPKHv0ZYYyMFxRcOEOnJk5jP3mVu0Z7UVTprnMGM/mJSKpZyZAWOFjvK5sFnDoLWFj WH6w== X-Gm-Message-State: AOAM5318WT7de+jfExo87Ic0XyeJmfxWZr0fOjU0SsE/c79aXcO9b5cT jCjjNpowr0kJGHTvjYuWKRyuLUHmStSY7LJ7YBE= X-Google-Smtp-Source: ABdhPJwFg2x8AJ1R5syQ8XsYLcOycKjHQkw7M4LD3hkby3taUtS6CF+5GtXIucrImQ59MMWh5GgdKa+ymtIJF4dYXg8= X-Received: by 2002:a05:620a:38f:: with SMTP id q15mr3429838qkm.291.1637030653516; Mon, 15 Nov 2021 18:44:13 -0800 (PST) MIME-Version: 1.0 References: <20210921043936.468001-1-andrew@aj.id.au> <20210921043936.468001-2-andrew@aj.id.au> In-Reply-To: From: Joel Stanley Date: Tue, 16 Nov 2021 02:44:00 +0000 Message-ID: Subject: Re: [PATCH 1/2] leds: pca955x: Make the gpiochip always expose all pins To: Linus Walleij , Arnd Bergmann , Pavel Machek Cc: Andrew Jeffery , linux-leds@vger.kernel.org, "open list:GPIO SUBSYSTEM" , =?UTF-8?Q?C=C3=A9dric_Le_Goater?= , Rob Herring , devicetree , Linux ARM , linux-aspeed , Linux Kernel Mailing List , Andy Shevchenko X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211115_184415_448727_663FAA36 X-CRM114-Status: GOOD ( 32.53 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hello Pavel and Arnd, This one has slipped through the cracks. Andrew asked for a follow up and Linus sent a review, but we haven't heard from Pavel at all. We've merged device tree changes through the soc tree in v5.16 that depend on this patch. Ideally I would like to see it applied to fix those device trees, instead of sending reverts for the device trees. Additionally, I'm now reviewing changes for v5.17 and want to decide which direction we should take. Pavel, are you happy with the change? If so, would you consider merging it as a fix for v5.16? Cheers, Joel On Tue, 9 Nov 2021 at 11:03, Linus Walleij wrote: > > On Tue, Sep 21, 2021 at 6:40 AM Andrew Jeffery wrote: > > > The devicetree binding allows specifying which pins are GPIO vs LED. > > Limiting the instantiated gpiochip to just these pins as the driver > > currently does requires an arbitrary mapping between pins and GPIOs, but > > such a mapping is not implemented by the driver. As a result, > > specifying GPIOs in such a way that they don't map 1-to-1 to pin indexes > > does not function as expected. > > > > Establishing such a mapping is more complex than not and even if we did, > > doing so leads to a slightly hairy userspace experience as the behaviour > > of the PCA955x gpiochip would depend on how the pins are assigned in the > > devicetree. Instead, always expose all pins via the gpiochip to provide > > a stable interface and track which pins are in use. > > > > Specifying a pin as `type = ;` in the devicetree > > becomes a no-op. > > > > I've assessed the impact of this change by looking through all of the > > affected devicetrees as of the tag leds-5.15-rc1: > > > > ``` > > $ git grep -l 'pca955[0123]' $(find . -name dts -type d) > > arch/arm/boot/dts/aspeed-bmc-ibm-everest.dts > > arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts > > arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts > > arch/arm/boot/dts/aspeed-bmc-opp-mowgli.dts > > arch/arm/boot/dts/aspeed-bmc-opp-swift.dts > > arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts > > arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts > > ``` > > > > These are all IBM-associated platforms. I've analysed both the > > devicetrees and schematics where necessary to determine whether any > > systems hit the hazard of the current broken behaviour. For the most > > part, the systems specify the pins as either all LEDs or all GPIOs, or > > at least do so in a way such that the broken behaviour isn't exposed. > > > > The main counter-point to this observation is the Everest system whose > > devicetree describes a large number of PCA955x devices and in some cases > > has pin assignments that hit the hazard. However, there does not seem to > > be any use of the affected GPIOs in the userspace associated with > > Everest. > > > > Regardless, any use of the hazardous GPIOs in Everest is already broken, > > so let's fix the interface and then fix any already broken userspace > > with it. > > > > Signed-off-by: Andrew Jeffery > > Acked-by: Linus Walleij > > Yours, > Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel