Linux USB
 help / color / mirror / Atom feed
From: "Mark Pearson" <mpearson-lenovo@squebb.ca>
To: "Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>
Cc: "Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
	"Greg KH" <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	"Diogo Ivo" <diogo.ivo@siemens.com>
Subject: Re: [PATCH] usb: typec: ucsi: treat get_pdos not supported condition as info instead of error
Date: Wed, 05 Jun 2024 13:09:01 -0400	[thread overview]
Message-ID: <a517bb13-9772-49f9-b75c-8fa4d98b2ae9@app.fastmail.com> (raw)
In-Reply-To: <2midmmssv2i3plvtc2hajar6alfvggpnbvgpmldspelxsnjvcl@qiblhwat6n3p>

Thanks Dmitry (& Diogo from the other thread)

On Tue, Jun 4, 2024, at 7:45 PM, Dmitry Baryshkov wrote:
> On Tue, Jun 04, 2024 at 03:40:44PM -0400, Mark Pearson wrote:
>> On systems where the UCSI PDOs are not supported, the UCSI driver is
>> giving an error message. This can cause users to believe there is a HW
>> issue with their system when in fact it is working as designed.
>> 
>> Downgrade message to dev_info for EOPNOTSUPP condition.
>> 
>> Tested on Lenovo L14 G5 AMD and confirmed with Lenovo FW team that PDOs
>> are not supported on this platform.
>> 
>> Signed-off-by: Mark Pearson <mpearson-lenovo@squebb.ca>
>> ---
>>  drivers/usb/typec/ucsi/ucsi.c | 8 ++++++--
>>  1 file changed, 6 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
>> index cb52e7b0a2c5..090be87d5485 100644
>> --- a/drivers/usb/typec/ucsi/ucsi.c
>> +++ b/drivers/usb/typec/ucsi/ucsi.c
>> @@ -632,8 +632,12 @@ static int ucsi_read_pdos(struct ucsi_connector *con,
>>  	command |= is_source(role) ? UCSI_GET_PDOS_SRC_PDOS : 0;
>>  	ret = ucsi_send_command(ucsi, command, pdos + offset,
>>  				num_pdos * sizeof(u32));
>> -	if (ret < 0 && ret != -ETIMEDOUT)
>> -		dev_err(ucsi->dev, "UCSI_GET_PDOS failed (%d)\n", ret);
>> +	if (ret < 0 && ret != -ETIMEDOUT) {
>> +		if (ret == -EOPNOTSUPP)
>> +			dev_info(ucsi->dev, "UCSI_GET_PDOS not supported on this hardware\n");
>
> Maybe it would be enough to guard GET_PDOS commands with the
> UCSI_CAP_PDO_DETAILS check? Is it cleared on affected platforms?
>

I checked on the system I have and the features are 0x84, so the CAP_PDO_DETAILS aren't set.
I can do a formal patch if the approach is better, I ended up doing:

@@ -645,9 +645,13 @@ static int ucsi_read_pdos(struct ucsi_connector *con,
 static int ucsi_get_pdos(struct ucsi_connector *con, enum typec_role role,
                         int is_partner, u32 *pdos)
 {
+       struct ucsi *ucsi = con->ucsi;
        u8 num_pdos;
        int ret;
 
+       if (!(ucsi->cap.features & UCSI_CAP_PDO_DETAILS))
+               return 0;
+
        /* UCSI max payload means only getting at most 4 PDOs at a time */
        ret = ucsi_read_pdos(con, role, is_partner, pdos, 0, UCSI_MAX_PDOS);

And this did indeed squelch the 'error' message.

Couple of notes:
 - I don't know this area very well, so don't know if there are risks of any regressions in other circumstances. I think it's pretty safe, but if any experts have an opinion that would be appreciated.
 - It means that there isn't a log message saying that PDO capabilities are not available. Are there going to be power related tooling that won't work and it would be useful to have that message available?

Thanks
Mark

  reply	other threads:[~2024-06-05 17:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-04 19:40 [PATCH] usb: typec: ucsi: treat get_pdos not supported condition as info instead of error Mark Pearson
2024-06-04 23:45 ` Dmitry Baryshkov
2024-06-05 17:09   ` Mark Pearson [this message]
2024-06-05 23:26     ` Dmitry Baryshkov
2024-06-06  2:12       ` Mark Pearson
2024-06-06 15:47     ` Diogo Ivo
2024-06-05 10:10 ` Diogo Ivo
2024-06-05 15:29 ` Diogo Ivo
2024-06-05 16:24   ` Mark Pearson

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=a517bb13-9772-49f9-b75c-8fa4d98b2ae9@app.fastmail.com \
    --to=mpearson-lenovo@squebb.ca \
    --cc=diogo.ivo@siemens.com \
    --cc=dmitry.baryshkov@linaro.org \
    --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