Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2407224pxb; Mon, 20 Sep 2021 21:40:54 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzq12hgklF3ObHhCzPjlxvhjhbd9MKQwl0Jyxf2nhE07Az/nujAu93K6dnJdEKWH80083wV X-Received: by 2002:a05:6638:d03:: with SMTP id q3mr22408019jaj.64.1632199254255; Mon, 20 Sep 2021 21:40:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632199254; cv=none; d=google.com; s=arc-20160816; b=ZuELgSBP9I34x8BEjsSr8eMztBLeh5zTYvDzqAaPAWa5/2qAVE4Tt9SVyhwPi4hDgb unZy3g+2ZPFoEuq8VlkHv3X4s85gWyLsN+7978NYkIHHnxKvZNK3iugzX3yZX67JCPvQ /+1DNFOabrLweiWf3ohFdQyTF5uPrdfKqdCAYP7VOdlhfpuR25aIfBfmXAVZcuAgRP4l itpFsXDKfxDMwJ9KsV3VJfaFr8VZAhAdRS7eXr/XfVA+IC6LqklDK2bUscZo955X0xaF THO38mbL1Fe4WxbGt1apgu3yy9Z224YgG2lHds5JRXkwnaUoan5uBJzq0tFjWIHXA2fO 68Cg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature:dkim-signature; bh=I4ve/cgxK4c8BY7+UtD8bEL+nkZo9i2k6Rhodknqgww=; b=Ic+GjEpIa5iBG36aeFH/2t+m8AJ7CHCRBET7RUBT0gyqeftRZBpgER7hQkanYe2UfP 3wrOOgP/Ax9DezkvFGg+rmzBXGYEL0wLhrkN1WEzPiowdnjce6VqbL4jYi4D+QBtYrU4 TY/4rgeWfuIGy9kCBjLXOWdx+j8XN5Cl9pZK8m3ji+HsEwqDFRzD7fe71IH9qPcOMe4f MM+RWlZqyrkKOAwCyuTPFLInrUph68j4y087H3LCcgEzjM3NUSVJKettgAAkGES83GYq coTckLgWayJeFLtH3+eKOXbriSooOdPuaZ4fcI2F/wMA7idhMbcvcF9E7Id2GI6umD8S N/xg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@aj.id.au header.s=fm3 header.b=E61X9XFX; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=QY39RzHw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id m47si13131553jaf.133.2021.09.20.21.40.42; Mon, 20 Sep 2021 21:40:54 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@aj.id.au header.s=fm3 header.b=E61X9XFX; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=QY39RzHw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229615AbhIUElX (ORCPT + 99 others); Tue, 21 Sep 2021 00:41:23 -0400 Received: from wnew4-smtp.messagingengine.com ([64.147.123.18]:59391 "EHLO wnew4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229498AbhIUElU (ORCPT ); Tue, 21 Sep 2021 00:41:20 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailnew.west.internal (Postfix) with ESMTP id 01FA52B01422; Tue, 21 Sep 2021 00:39:51 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Tue, 21 Sep 2021 00:39:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aj.id.au; h=from :to:cc:subject:date:message-id:mime-version :content-transfer-encoding; s=fm3; bh=I4ve/cgxK4c8BY7+UtD8bEL+nk Zo9i2k6Rhodknqgww=; b=E61X9XFXPJOOQayHDvUcuo+rTPfjF/ky5zk3Mi4hS2 rVVK7HKI5BQweODHKuu2SNklSikLEnAOIzatUf1x7kuwKzatQtG8tUPknIs5tEwC WeIgCgSwgZnqaYJajBac1iUb5AEU7Crh7uNRm4PudjOuvyrWKcwmt9GooSEqsKH9 CYmYdY9A5VMxgX62Qu87Jsm9OC9KHz5PIv8rCwVpdF8khFJoT9I/55qqnn1HRQT8 GQPGdPZRlM4kemArr9OEUtxrC47/24fL2tFGdsL4y9rYZ8UUsMYUxWenQrbWKH/w GMqT7P2AKDB/oK7+vfBqLNGXOajv2TfAVNMWd2Ap72gA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:from :message-id:mime-version:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=I4ve/cgxK4c8BY7+U tD8bEL+nkZo9i2k6Rhodknqgww=; b=QY39RzHwtcUTsQe560mXBFfewJazNxmHD kwLUpf7ulzx9P9K3cbWHYtxi73rS8UXVYnkpWgoNnUWYVwmBe5MIKYeoPJqwYS7p 8vdPnFh/xwbXc/Y0lcfECT9cswW4rB3WpfzGetDElmk99o6KkJywz3cZZ/0q/QdQ TOT14YNDOEY4N5PeZ6qzRHueeixC8eUkNUKd/Gg8yDHzkXjBgdahpO2UkJFXDtKV bhpxE91z17KsYiSiBa9KZrXRv1b30oKbhiFR4j9MdF/lrOkveu8Po4QdJY5VRFur Q/jpmVZwhK+fYOmEguV54k4krU1zeC/MYZDeXMEY0Yw1zCpbTogsw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudeifedgkeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhvffufffkofgggfestdekredtre dttdenucfhrhhomheptehnughrvgifucflvghffhgvrhihuceorghnughrvgifsegrjhdr ihgurdgruheqnecuggftrfgrthhtvghrnhepieetheduveelhfdvvdejleeuhfelteevhe ffgfeitdefgeekjeefieevgfehhefgnecuffhomhgrihhnpehkvghrnhgvlhdrohhrghen ucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrnhgurh gvfiesrghjrdhiugdrrghu X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 21 Sep 2021 00:39:45 -0400 (EDT) From: Andrew Jeffery To: linux-leds@vger.kernel.org, linux-gpio@vger.kernel.org Cc: clg@kaod.org, robh+dt@kernel.org, joel@jms.id.au, pavel@ucw.cz, linus.walleij@linaro.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org, andy.shevchenko@gmail.com Subject: [PATCH 0/2] leds: pca955x: Expose GPIOs for all pins Date: Tue, 21 Sep 2021 14:09:34 +0930 Message-Id: <20210921043936.468001-1-andrew@aj.id.au> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, This is a rework of a Rube Goldberg-inspired RFC I posted previously: https://lore.kernel.org/lkml/20210723075858.376378-1-andrew@aj.id.au/ This time around there's a lot less Rube - the series: 1. Contains no (ab)use of pinctrl 2. Always exposes all pins as GPIOs 3. Internally tracks the active pins Without these patches the driver limits the number of pins exposed on the gpiochip to the number of pins specified as GPIO in the devicetree, but doesn't map between the GPIO and pin number spaces. The result is that specifying offset or interleaved GPIOs in the devicetree gives unexpected behaviour in userspace. By always exposing all pins as GPIOs the patches resolve the lack of mapping between GPIO offsets and pins on the package in the driver by ensuring we always have a 1-to-1 mapping. The issue is primarily addressed by patch 1/2. Patch 2/2 makes it possible to not expose any pins as LEDs (and therefore make them all accessible as GPIOs). This has a follow-on effect of allowing the driver to bind to a device instantiated at runtime without requiring a description in the devicetree. I've tested the series under qemu to inspect the various interactions between LEDs vs GPIOs as well as conflicting GPIO requests. Please review! Andrew Andrew Jeffery (2): leds: pca955x: Make the gpiochip always expose all pins leds: pca955x: Allow zero LEDs to be specified drivers/leds/leds-pca955x.c | 65 +++++++++++++++++++------------------ 1 file changed, 34 insertions(+), 31 deletions(-) base-commit: 239f32b4f161c1584cd4b386d6ab8766432a6ede -- 2.30.2