From: Dan Carpenter <dan.carpenter@linaro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: linux-usb@vger.kernel.org
Subject: Re: [bug report] usb: typec: ucsi: extract code to read PD caps
Date: Sun, 14 Apr 2024 14:52:30 +0300 [thread overview]
Message-ID: <b00b229b-5191-4157-814a-8f9e57c36def@moroto.mountain> (raw)
In-Reply-To: <7zonsyhzhpxthhaty7dwhdnm6jniwl4ia46fde63zbq4c4kw3x@jl4w2zn7a5fx>
On Thu, Apr 11, 2024 at 11:25:50PM +0300, Dmitry Baryshkov wrote:
> Hello Dan,
>
> On Thu, Apr 11, 2024 at 04:20:22PM +0300, Dan Carpenter wrote:
> > Hello Dmitry Baryshkov,
> >
> > Commit ad4bc68bef3e ("usb: typec: ucsi: extract code to read PD
> > caps") from Mar 29, 2024 (linux-next), leads to the following Smatch
> > static checker warning:
> >
> > drivers/usb/typec/ucsi/ucsi.c:689 ucsi_get_pd_caps()
> > warn: passing zero to 'ERR_PTR'
> >
> > drivers/usb/typec/ucsi/ucsi.c
> > 680 static struct usb_power_delivery_capabilities *ucsi_get_pd_caps(struct ucsi_connector *con,
> > 681 enum typec_role role,
> > 682 bool is_partner)
> > 683 {
> > 684 struct usb_power_delivery_capabilities_desc pd_caps;
> > 685 int ret;
> > 686
> > 687 ret = ucsi_get_pdos(con, role, is_partner, pd_caps.pdo);
> > 688 if (ret <= 0)
> > --> 689 return ERR_PTR(ret);
> >
> > This is returns NULL if ucsi_get_pdos() returns zero. It's really hard
> > to say if this is intentional or not... Originally, we treated error
> > codes and zero the same but we didn't report errors back to the user,
> > the code just continued silently. Now it's reporting errors but just
> > continuing along if ucsi_get_pdos() returns zero.
>
> The code is correct. The calling function checks that the result of
> ucsi_get_pd_caps() is an ERR code and if that's not the case, assigns
> PD capabilites to the storage at the connector. If ucsi_get_pdos()
> returns 0, there are no PD objects, nothing to create capabilites for.
> Thus the function correctly returns NULL.
>
> If you think it is better to be explicit, I can send either an explicit
> fixup `if (!ret) return NULL;` or just a comment that we should return
> NULL if there are no PDOs.
>
Just add a comment. This static checker rule is going to have false
positives, and I did think it might be a false positive, but it just
wasn't totally obvious.
regards,
dan carpenter
prev parent reply other threads:[~2024-04-14 11:52 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 13:20 [bug report] usb: typec: ucsi: extract code to read PD caps Dan Carpenter
2024-04-11 20:25 ` Dmitry Baryshkov
2024-04-14 11:52 ` Dan Carpenter [this message]
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=b00b229b-5191-4157-814a-8f9e57c36def@moroto.mountain \
--to=dan.carpenter@linaro.org \
--cc=dmitry.baryshkov@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.