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. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
