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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux