On 31/01/2024 10:50, Krzysztof Kozlowski wrote: > On 31/01/2024 09:57, Linus Walleij wrote: >> Hi Krzysztof, >> >> something is odd with the addresses on this patch, because neither GPIO > > Nothing is odd - I use get_maintainers.pl which just don't print your > names. I can add your addresses manually, no problem, but don't blame > the contributor that get_maintainers.pl has a missing content-regex. If > you want to be Cced on usage of GPIOs, you need to be sure that > MAINTAINERS file has appropriate pattern. > > >> maintainer is on CC nor linux-gpio@vger, and it's such a GPIO-related >> patch. We only saw it through side effects making <linux/gpio/driver.h> >> optional, as required by this patch. >> >> Please also CC Geert Uytterhoeven, the author of the GPIO aggregator. > > >> >> i.e. this: >>> 2. !GPIOLIB stub: >>> https://lore.kernel.org/all/20240125081601.118051-3-krzysztof.kozlowski@xxxxxxxxxx/ >> >> On Mon, Jan 29, 2024 at 12:53 PM Krzysztof Kozlowski >> <krzysztof.kozlowski@xxxxxxxxxx> wrote: >> >>> Devices sharing a reset GPIO could use the reset framework for >>> coordinated handling of that shared GPIO line. We have several cases of >>> such needs, at least for Devicetree-based platforms. >>> >>> If Devicetree-based device requests a reset line, while "resets" >>> Devicetree property is missing but there is a "reset-gpios" one, >>> instantiate a new "reset-gpio" platform device which will handle such >>> reset line. This allows seamless handling of such shared reset-gpios >>> without need of changing Devicetree binding [1]. >>> >>> To avoid creating multiple "reset-gpio" platform devices, store the >>> Devicetree "reset-gpios" GPIO specifiers used for new devices on a >>> linked list. Later such Devicetree GPIO specifier (phandle to GPIO >>> controller, GPIO number and GPIO flags) is used to check if reset >>> controller for given GPIO was already registered. >>> >>> If two devices have conflicting "reset-gpios" property, e.g. with >>> different ACTIVE_xxx flags, this would allow to spawn two separate >>> "reset-gpio" devices, where the second would fail probing on busy GPIO >>> request. >>> >>> Link: https://lore.kernel.org/all/YXi5CUCEi7YmNxXM@xxxxxxxxxxxxxxxxxx/ [1] >>> Cc: Bartosz Golaszewski <brgl@xxxxxxxx> >>> Cc: Chris Packham <chris.packham@xxxxxxxxxxxxxxxxxxx> >>> Cc: Sean Anderson <sean.anderson@xxxxxxxx> >>> Reviewed-by: Philipp Zabel <p.zabel@xxxxxxxxxxxxxx> >>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx> >> (...) >> >> In my naive view, this implements the following: >> >> reset -> virtual "gpio" -> many physical gpios[0..n] > > It does not, there is no single GPIO here. There is a single reset > controller, though, but still multiple GPIOs in DTS. > >> >> So if there was already a way in the kernel to map one GPIO to >> many GPIOs, the framework could just use that with a simple >> single GPIO? >> >> See the bindings in: >> Documentation/devicetree/bindings/gpio/gpio-delay.yaml >> >> This is handled by drivers/gpio/gpio-aggregator.c. >> >> This supports a 1-to-1 map: one GPIO in, one GPIO out, same offset. >> So if that is extended to support 1-to-many, this problem is solved. > > It does not match the hardware thus I don't know how to implement it in > DTS while keeping the requirement that we are describing hardware, not > OS abstractions. > >> >> Proposed solution: add a single boolean property such as >> aggregate-all-gpios; to the gpio-delay node, making it provide >> one single gpio at offset 0 on the consumer side, and refuse any >> more consumers. > > And how do you solve the reset requirements? The problem is not just to > share GPIO. The problem is to share in a way that devices operate > properly when they assert/deassert reset. > >> >> This will also solve the problem with induced delays on >> some GPIO lines as I can see was discussed in the bindings, >> the gpio aggregator already supports that, but it would work >> fine with a delay being zero as well. >> >> This avoids all the hackery with driver stubs etc as well. > > > So none of these ideas were posted in previous threads, just because you > were not CCed (except one thread)? > > https://lore.kernel.org/lkml/20191030120440.3699-1-peter.ujfalusi@xxxxxx/ > https://lore.kernel.org/all/9eebec9b-e6fd-4a22-89ea-b434f446e061@xxxxxxxxxx/ > https://lore.kernel.org/all/20231018100055.140847-1-krzysztof.kozlowski@xxxxxxxxxx/ > https://social.treehouse.systems/@marcan/111268780311634160 > And here: https://lore.kernel.org/all/CAL_JsqL3oZXJJ5_i4BRGpvWu1X8QFB7OGG=D+zLvvWb=UR1mWg@xxxxxxxxxxxxxx/ which the place where this idea of using resets appeared. I agree that you were not CCed there, but that only means you miss lei filters or pattern in MAINTAINERS. Best regards, Krzysztof
