On Mon, Mar 7, 2022 at 8:21 PM Henning Schild
<henning.schild@xxxxxxxxxxx> wrote:
Please, do not top-post.
> Can this patch not be proposed separately? Maybe i am wrong but it
> seems unrelated to the p2sb story.
The entire story happens to begin from this very change. The author
(you may see that's not me) proposed the change a long time ago and
AFAIU this is the requirement to have it upstreamed.
> The whole p2sb base and size discovery is easy and switching the
> simatic drivers is also. It is an interface change, where the old open
> coding remains working.
>
> But having to switch to GPIO in the same series is kind of weird. That
> is a functional change which even might deserve its own cover letter. I
> bet there are tons of out-of-tree modules which will stop working on
> apl after that gets merged.
Upstream rarely, if at all, cares about 3rd party modules. From the
upstream point of view the thing (whatever the 3rd party module
supports) wasn't working ("no driver" in upstream) and won't work
(still "no driver" in upstream) after the change, so there may not be
any regression.
> I still did not understand why apl is special and other boards do not
> get their pinctrl brought up without ACPI/p2sb-visible.
The platform is being heavily used by one of our departments in such
configuration with firmwares that may not be fully compatible with
UEFI.They want to support that along with the case when BIOS has no
GPIO device being provided.
> I have patches floating around, but still would be happy if we could do
> one thing at a time.
Either way any new changes must use a pin control driver and the
previous work was accepted only on this basis.
> Or maybe it is strongly coupled and I do not understand why.
That's the initial requirement by our peer departament.
--
With Best Regards,
Andy Shevchenko
