Re: [PATCH 3/3] [v6] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002

Timur Tabi
2017-12-21T01:06:56Z

On 12/20/17 6:39 PM, Stephen Boyd wrote:
> I don't see how it hurts to treat it generically. Presumably
> that's the way it will be done on ACPI platforms going forward?
> No need to tie it to some ACPI HID.

But it is tied to a HID. The "num-gpios" and "gpios" properties belong
to a specific HID. Someone could create a new HID with different
properties, and then what? That's why I want all the ACPI stuff in the
client driver.

At this point I don't really care any more about what the patches look
like, but I really do think that putting the ACPI code in pinctrl-msm is
a bad idea.

We're debating adding support for multiple TLMMs, and we may create a
new HID for that, so that we can define all pins on all TLMMs in one
device. We would need to create a new HID and new DSDs to go with it.

> I'm trying to resolve everything at once: gpios, pinctrl pins,
> and irqs exposed by the TLMM hardware. The value is that we solve
> it all, once, now.

Keep in mind that I am now in vacation, and so I won't be able to submit
any more patches for a while.

> The DT binding can also be resolved at the
> same time, so when we need to express this in DT it's already
> done.

Ok.

> Otherwise, something can request irqs from the irqdomain
> even if the irq can't be enabled, or it can try to mux the pin to
> some other function, even if the function selection can't be
> configured.

Is it possible to request an IRQ for a pin if the pin itself can't be
requested?

> Boiling everything down into the irq valid mask should cover all
> these cases, and not require us to strip const from all the data
> in the non-ACPI pinctrl drivers to replace the value in the npins
> field at runtime.

Ok.