From: Amit Sunil Dhamne <amitsd@google.com>
To: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Cosmo Chou <chou.cosmo@gmail.com>
Cc: badhri@google.com, gregkh@linuxfoundation.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
cosmo.chou@quantatw.com
Subject: Re: [PATCH v2] usb: typec: tcpm: Use configured PD revision for negotiation
Date: Thu, 15 May 2025 00:15:29 -0700 [thread overview]
Message-ID: <4245c9da-cb81-4494-93c6-224883057410@google.com> (raw)
In-Reply-To: <aCRQbRCHFdFOCNw2@kuha.fi.intel.com>
Hi Heikki,
On 5/14/25 1:12 AM, Heikki Krogerus wrote:
> On Tue, May 13, 2025 at 10:14:32PM +0800, Cosmo Chou wrote:
>> On Tue, May 13, 2025 at 04:50:49PM +0300, Heikki Krogerus wrote:
>>> On Tue, May 13, 2025 at 04:39:09PM +0300, Heikki Krogerus wrote:
>>>> On Tue, May 13, 2025 at 09:08:34PM +0800, Cosmo Chou wrote:
>>>>> Initialize negotiated_rev and negotiated_rev_prime based on the port's
>>>>> configured PD revision (rev_major) rather than always defaulting to
>>>>> PD_MAX_REV. This ensures ports start PD communication using their
>>>>> appropriate revision level.
>>>>>
>>>>> This allows proper communication with devices that require specific
>>>>> PD revision levels, especially for the hardware designed for PD 1.0
>>>>> or 2.0 specifications.
>>>>>
>>>>> Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com>
>>>>> ---
>>>>> Change log:
>>>>>
>>>>> v2:
>>>>> - Add PD_CAP_REVXX macros and use switch-case for better readability.
>>>>>
>>>>> ---
>>>>> drivers/usb/typec/tcpm/tcpm.c | 29 +++++++++++++++++++++++++----
>>>>> 1 file changed, 25 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
>>>>> index 8adf6f954633..48e9cfc2b49a 100644
>>>>> --- a/drivers/usb/typec/tcpm/tcpm.c
>>>>> +++ b/drivers/usb/typec/tcpm/tcpm.c
>>>>> @@ -313,6 +313,10 @@ struct pd_data {
>>>>> unsigned int operating_snk_mw;
>>>>> };
>>>>>
>>>>> +#define PD_CAP_REV10 0x1
>>>>> +#define PD_CAP_REV20 0x2
>>>>> +#define PD_CAP_REV30 0x3
>>>>> +
>>>>> struct pd_revision_info {
>>>>> u8 rev_major;
>>>>> u8 rev_minor;
>>>>> @@ -4665,6 +4669,25 @@ static void tcpm_set_initial_svdm_version(struct tcpm_port *port)
>>>>> }
>>>>> }
>>>>>
>>>>> +static void tcpm_set_initial_negotiated_rev(struct tcpm_port *port)
>>>>> +{
>>>>> + switch (port->pd_rev.rev_major) {
>>>>> + case PD_CAP_REV10:
>>>>> + port->negotiated_rev = PD_REV10;
>>>>> + break;
>>>>> + case PD_CAP_REV20:
>>>>> + port->negotiated_rev = PD_REV20;
>>>>> + break;
>>>>> + case PD_CAP_REV30:
>>>>> + port->negotiated_rev = PD_REV30;
>>>>> + break;
>>>>> + default:
>>>>> + port->negotiated_rev = PD_MAX_REV;
>>>>> + break;
>>>>> + }
>>>>> + port->negotiated_rev_prime = port->negotiated_rev;
>>>>> +}
>>>> Do we need this? Couldn't you just add one to rev_major?
>>>>
>>>> port->negotiated_rev = port->pd_rev.rev_major + 1;
>>>> port->negotiated_rev_prime = port->pd_rev.rev_major + 1;
>>>>
>>>> Or am I missing something?
>>> Sorry, I mean minus one :-)
>>>
>>> port->negotiated_rev = port->pd_rev.rev_major - 1;
>>> port->negotiated_rev_prime = port->pd_rev.rev_major - 1;
The only reason I asked for macros is that in the case of Spec Revision
for header, the value for PD 3.0 is 0x2, PD 2.0 is 0x1 & so on. While
for PD max revisions, it's the exact values. Having a clear distinction
may be easier to follow. If you want to go with the +/- approach you can
add a comment stating the above.
I don't have a hard opinion on either approach :).
Thanks,
Amit
>>>
>>> --
>>> heikki
>> It seems to be the PATCH v1:
>> https://lore.kernel.org/all/20250508174756.1300942-1-chou.cosmo@gmail.com/
>>
>> if (port->pd_rev.rev_major > 0 && port->pd_rev.rev_major <= PD_MAX_REV + 1) {
>> port->negotiated_rev = port->pd_rev.rev_major - 1;
>> port->negotiated_rev_prime = port->pd_rev.rev_major - 1;
>> } else {
>> port->negotiated_rev = PD_MAX_REV;
>> port->negotiated_rev_prime = PD_MAX_REV;
>> }
> Okay, sorry I missed that. I still don't like the extra definitions,
> but I don't have any better idea (I guess macro is not an option?).
> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>
> thanks,
>
next prev parent reply other threads:[~2025-05-15 7:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-13 13:08 Cosmo Chou
2025-05-13 13:39 ` Heikki Krogerus
2025-05-13 13:50 ` Heikki Krogerus
2025-05-13 14:14 ` Cosmo Chou
2025-05-14 8:12 ` Heikki Krogerus
2025-05-15 7:15 ` Amit Sunil Dhamne [this message]
2025-05-16 5:10 ` Badhri Jagan Sridharan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4245c9da-cb81-4494-93c6-224883057410@google.com \
--to=amitsd@google.com \
--cc=badhri@google.com \
--cc=chou.cosmo@gmail.com \
--cc=cosmo.chou@quantatw.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®