[PATCH V2 0/6] pinctrl: support platform (e.g. DT) stored pins, groups & functions

[Andy Shevchenko]

On Thu, Nov 25, 2021 at 1:04 AM Rafał Miłecki <zajec5 at gmail.com> wrote:
>
> From: Rafał Miłecki <rafal at milecki.pl>
>
> Two weeks ago I sent
> [PATCH RFC] dt-bindings: pinctrl: support specifying pins
> https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20211110231436.8866-1-zajec5@gmail.com/
>
> and week ago I sent
> [PATCH 0/5] pinctrl: allow storing pins, groups & functions in DT
> https://patchwork.ozlabs.org/project/linux-gpio/list/?series=272685
>
> Initially I planned to allow putting some pinctrl hw details in DT and
> later that evolved into a slightly more generic API.
>
> Again:
> Please note it's about describing hardware elements and not actual
> programming way. It may be used with pinctrl-single.c one day but it's
> designed as a generic solution for data.
>
> Patches 1-5 are for linux-pinctrl.git. Patch 6 I found worth including
> as DT big example. It can go through Linus with Florian's Ack or I can
> send it to Florian later.

Thank you for an update! What I would like to see in the cover letter
and esp. in the updated documentation of the pin control subsystem is
the architectural (design) point of view. There is no sense to discuss
the following patches without a big picture. For example, should we
allow some of the DT information to be passed on ACPI based platforms
(due to OF related enumeration of the devices in ACPI environment, see
PRP0001 for the details)? Or i.o.w. Do all these properties make sense
only in the realm of the provider? I believe it's true for pin
controller devices and false for consumer devices, so, the question
is, does pin controller device support any type of hogs or it's only
property of GPIO? It's all not clear to me with this cover letter and
absence of the documentation.

Besides that, consider test cases to be added (OF has its unittest
built-in into the kernel).

-- 
With Best Regards,
Andy Shevchenko