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 17:50, Krzysztof Kozlowski wrote:
> 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:

The pdphy is fairly well encapsulated (3 tcpm callbacks go to it, that's
all?), I think the tcpm part could be merged in with the typec driver
and it could just have a phandle to the pdphy node to represent the
dependency.

Then in the typec driver you can get the device with
spmi_device_from_of() and call into it that way for the few tcpm
callbacks that it needs to handle and to pass in the tcpm_port.


> 
> pmic {
> 	usb {
> 	};
> };
> 
> virtual- pmic-tcpm {
> };
> 
> What hardware piece does such description represent?
> 
>>
>> Could I trouble you for an example ?
>>
>> ---
>> bod
> 
> Best regards,
> Krzysztof
> 

-- 
Kind Regards,
Caleb (they/them)



[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