Re: [PATCH v4 09/18] dt-bindings: usb: Add Qualcomm PMIC TCPM YAML schema

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

 



On 19/03/2023 16:44, Bryan O'Donoghue wrote:
> On 19/03/2023 15:10, Krzysztof Kozlowski wrote:
>> On 19/03/2023 15:59, Bryan O'Donoghue wrote:
>>> On 19/03/2023 11:58, Krzysztof Kozlowski wrote:
>>>>> +
>>>>> +maintainers:
>>>>> +  - Bryan O'Donoghue<bryan.odonoghue@xxxxxxxxxx>
>>>>> +
>>>>> +description: |
>>>>> +  Qualcomm PMIC Virtual Type-C Port Manager Driver
>>>>> +  A virtual device which manages Qualcomm PMIC provided Type-C port and
>>>>> +  Power Delivery in one place.
>>>> OK, so it looks like bindings for driver, so a no-go. Unless there is
>>>> such device as "manager", this does not look like hardware description.
>>>>
>>>>> +
>>>>> +properties:
>>>>> +  compatible:
>>>>> +    const: qcom,pmic-virt-tcpm
>>>>> +
>>>>> +  connector:
>>>>> +    type: object
>>>>> +    $ref: /schemas/connector/usb-connector.yaml#
>>>>> +    unevaluatedProperties: false
>>>>> +
>>>>> +  port:
>>>>> +    $ref: /schemas/graph.yaml#/properties/port
>>>>> +    description:
>>>>> +      Contains a port which consumes data-role switching messages.
>>>>> +
>>>>> +  qcom,pmic-typec:
>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>>> +    description:
>>>>> +      A phandle to the typec port hardware driver.
>>>>> +
>>>>> +  qcom,pmic-pdphy:
>>>>> +    $ref: /schemas/types.yaml#/definitions/phandle
>>>> Having typec and phy as phandles - not children - also suggests this is
>>>> some software construct, not hardware description.
>>>
>>> So probably I didn't interpret Rob's comment correctly here.
>>
>> He proposed to merge it with other node:
>> "probably merged with
>> one of the nodes these phandles point to."
>>
>> "Why can't most of this binding be part of"
>>
>> I don't see how you implemented his comments. Actually, nothing improved
>> here in this regard - you still have these phandles.
> 
> So this comment from Rob is what I was aiming for
> 
> "Your other option is instantiate your own device from the virtual
> driver's initcall based on presence of the 2 nodes above. "
> 
> rather than two mush the pdphy and typec into one device, which they are 
> not.

Sure, but you did not instantiate anything based on these two or one
nodes. You added virtual device node.


> I guess what I'm trying to understand is how you guys would suggest that 
> is actually done.

You have there already node for the PMIC USB Type-C, so this should be
part of it. I really do not understand why this is separate device lying
around in parallel like:

pmic {
	usb {
	};
};

virtual- pmic-tcpm {
};

What hardware piece does such description represent?

> 
> Could I trouble you for an example ?
> 
> ---
> bod

Best regards,
Krzysztof




[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