On 08/11/2021 19:22, Rob Herring wrote:
On Mon, Nov 8, 2021 at 12:58 PM Bryan O'Donoghue
<bryan.odonoghue@xxxxxxxxxx> wrote:
On 08/11/2021 17:13, Rob Herring wrote:
Looks like the h/w is all part of a
PMIC, so it should be part of the PMIC binding and probably merged with
one of the nodes these phandles point to.
Not sure I really follow you here.
The existing PMIC dts arch/arm64/boot/dts/qcom/pm8150b.dtsi has:
pm8150b_gpios: gpio@c000 {
compatible = "qcom,pm8150b-gpio";
}
Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml
and
pm8150b_adc_tm: adc-tm@3500 {
compatible = "qcom,spmi-adc-tm5";
};
Documentation/devicetree/bindings/thermal/qcom-spmi-adc-tm5.yaml
to which I'm adding :
pm8150b_typec: typec@1500 {
compatible = "qcom,pm8150b-typec";
};
Documentation/devicetree/bindings/usb/qcom,pmic-typec.yaml
pm8150b_pdphy: pdphy@1700 {
compatible = "qcom,pm8150b-pdphy";
};
Documentation/devicetree/bindings/usb/qcom,pmic-pdphy.yaml
From what I gather, there is not a 3rd h/w device this binding
describes, but it is just a collection of all the data you happen to
want for your driver.
The TCPM "virtual" driver presents as a device to the TCPM API and then
uses phandle to talk to the PDPHY and typec devices yes.
That's assuming a specific structure for a
specific OS. Why can't most of this binding be part of
"qcom,pm8150b-typec" instead of making up some virtual device?
I thought it was a better model to have the TCPM be a separate device
with the pdphy and typec blocks as their own devices.
#1 Because the address space spans over more than just the pdphy and
typec device, there's a charger block in between
#2 Because the pdphy and typec have separate IRQ lines and register spaces
---
bod
