RE: [PATCH 2/2 v7] typec: tcpm: Only request matching pdos

[Adam Thomson]

On 28 November 2017 02:07, Guenter Roeck wrote:

> On 11/27/2017 05:38 PM, Badhri Jagan Sridharan wrote:
> > On Thu, Nov 23, 2017 at 3:10 AM, Adam Thomson
> > <Adam.Thomson.Opensource@xxxxxxxxxxx> wrote:
> >> On 16 November 2017 01:02, Badhri Jagan Sridharan wrote:
> >>
> >>> At present, TCPM code assumes that local device supports
> >>> variable/batt pdos and always selects the pdo with highest
> >>> possible power within the board limit. This assumption
> >>> might not hold good for all devices. To overcome this,
> >>> this patch makes TCPM only accept a source_pdo when there is
> >>> a matching sink pdo.
> >>>
> >>> For Fixed pdos: The voltage should match between the
> >>> incoming source_cap and the registered snk_pdo
> >>> For Variable/Batt pdos: The incoming source_cap voltage
> >>> range should fall within the registered snk_pdo's voltage
> >>> range.
> >>>
> >>> Also, when the cap_mismatch bit is set, the max_power/current
> >>> should be set to the max_current/power of the sink_pdo.
> >>> This is according to:
> >>>
> >>> "If the Capability Mismatch bit is set to one
> >>> The Maximum Operating Current/Power field may contain a value
> >>> larger than the maximum current/power offered in the Source
> >>> Capabilities messageâs PDO as referenced by the Object position field.
> >>> This enables the Sink to indicate that it requires more current/power
> >>> than is being offered. If the Sink requires a different voltage this
> >>> will be indicated by its Sink Capabilities message.
> >>
> >> Hi Badhri,
> >>
> >> I have some queries on this change. At the moment the src/snk PDOs are hard
> >> coded in the relevant PD controller driver (e.g. fusb302.c), and the only way
> >> to update these is to call the tcpm_update_source_capabilities() or
> >> tcpm_update_sink_capabilities() functions. However there are no real world
> >
> > Good point ! But I dont see any code which calls this either. I believe
> > Guenter added this. Guenter do you know ?
> >
> 
> A source might change its power capabilities dynamically. Practical example is
> a system with two USB-C ports. If one is in use, it may support 3A output power.
> If two are in use, it may support 1.5A each. This isn't currently used in the
> kernel, but some of our devices have this behavior, so I thought it would be
> prudent to have support for it. The same is true for a sink, which may change
> its power requirements at runtime (same situation - a device is inserted at
> the second USB port) and ask for more or less power.
> 
> Is that a problem ? I won't object if you want to take it out because there is
> no current user, but you should keep in mind that those are valid use cases,
> and that the code should at least be extensible (ie the patch taking it away
> should be revertible) to support those use cases.

No, I have no desire to remove it and definitely see the valid use-cases. I was
curious though as to where these functions might be called from within the
kernel as wherever that is it will need to have the ability to retrieve the port
instance to be able to call these functions.