On Thu, Nov 25, 2021 at 1:04 AM Rafał Miłecki <zajec5@xxxxxxxxx> wrote: > > From: Rafał Miłecki <rafal@xxxxxxxxxx> > > 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@xxxxxxxxx/ > > 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
