From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Frank Wang <frank.wang@rock-chips.com>
Cc: linux@roeck-us.net, gregkh@linuxfoundation.org, heiko@sntech.de,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rockchip@lists.infradead.org, huangtao@rock-chips.com,
william.wu@rock-chips.com, jianwei.zheng@rock-chips.com,
yubing.zhang@rock-chips.com, wmc@rock-chips.com
Subject: Re: [PATCH v2] usb: typec: tcpm: fix multiple times discover svids error
Date: Fri, 17 Mar 2023 13:27:13 +0200 [thread overview]
Message-ID: <ZBROkdOFAP4GPPU6@kuha.fi.intel.com> (raw)
In-Reply-To: <20230316081149.24519-1-frank.wang@rock-chips.com>
On Thu, Mar 16, 2023 at 04:11:49PM +0800, Frank Wang wrote:
> PD3.0 Spec 6.4.4.3.2 say that only Responder supports 12 or more SVIDs,
> the Discover SVIDs Command Shall be executed multiple times until a
> Discover SVIDs VDO is returned ending either with a SVID value of
> 0x0000 in the last part of the last VDO or with a VDO containing two
> SVIDs with values of 0x0000.
>
> In the current implementation, if the last VDO does not find that the
> Discover SVIDs Command would be executed multiple times even if the
> Responder SVIDs are less than 12, and we found some odd dockers just
> meet this case. So fix it.
>
> Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
> ---
> drivers/usb/typec/tcpm/tcpm.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 66de02a56f512..a3ae2c79f3540 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -1515,7 +1515,21 @@ static bool svdm_consume_svids(struct tcpm_port *port, const u32 *p, int cnt)
> pmdata->svids[pmdata->nsvids++] = svid;
> tcpm_log(port, "SVID %d: 0x%x", pmdata->nsvids, svid);
> }
> - return true;
> +
> + /*
> + * PD3.0 Spec 6.4.4.3.2: The SVIDs are returned 2 per VDO (see Table
> + * 6-43), and can be returned maximum 6 VDOs per response (see Figure
> + * 6-19). If the Respondersupports 12 or more SVID then the Discover
> + * SVIDs Command Shall be executed multiple times until a Discover
> + * SVIDs VDO is returned ending either with a SVID value of 0x0000 in
> + * the last part of the last VDO or with a VDO containing two SVIDs
> + * with values of 0x0000.
> + *
> + * However, some odd dockers support SVIDs less than 12 but without
> + * 0x0000 in the last VDO, so we need to break the Discover SVIDs
> + * request and return false here.
> + */
> + return cnt == 7;
> abort:
> tcpm_log(port, "SVID_DISCOVERY_MAX(%d) too low!", SVID_DISCOVERY_MAX);
> return false;
This is OK by men, but let's wait for Guenter.
thanks,
--
heikki
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
WARNING: multiple messages have this Message-ID (diff)
From: Heikki Krogerus <heikki.krogerus@linux.intel.com>
To: Frank Wang <frank.wang@rock-chips.com>
Cc: linux@roeck-us.net, gregkh@linuxfoundation.org, heiko@sntech.de,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-rockchip@lists.infradead.org, huangtao@rock-chips.com,
william.wu@rock-chips.com, jianwei.zheng@rock-chips.com,
yubing.zhang@rock-chips.com, wmc@rock-chips.com
Subject: Re: [PATCH v2] usb: typec: tcpm: fix multiple times discover svids error
Date: Fri, 17 Mar 2023 13:27:13 +0200 [thread overview]
Message-ID: <ZBROkdOFAP4GPPU6@kuha.fi.intel.com> (raw)
In-Reply-To: <20230316081149.24519-1-frank.wang@rock-chips.com>
On Thu, Mar 16, 2023 at 04:11:49PM +0800, Frank Wang wrote:
> PD3.0 Spec 6.4.4.3.2 say that only Responder supports 12 or more SVIDs,
> the Discover SVIDs Command Shall be executed multiple times until a
> Discover SVIDs VDO is returned ending either with a SVID value of
> 0x0000 in the last part of the last VDO or with a VDO containing two
> SVIDs with values of 0x0000.
>
> In the current implementation, if the last VDO does not find that the
> Discover SVIDs Command would be executed multiple times even if the
> Responder SVIDs are less than 12, and we found some odd dockers just
> meet this case. So fix it.
>
> Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
> ---
> drivers/usb/typec/tcpm/tcpm.c | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 66de02a56f512..a3ae2c79f3540 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -1515,7 +1515,21 @@ static bool svdm_consume_svids(struct tcpm_port *port, const u32 *p, int cnt)
> pmdata->svids[pmdata->nsvids++] = svid;
> tcpm_log(port, "SVID %d: 0x%x", pmdata->nsvids, svid);
> }
> - return true;
> +
> + /*
> + * PD3.0 Spec 6.4.4.3.2: The SVIDs are returned 2 per VDO (see Table
> + * 6-43), and can be returned maximum 6 VDOs per response (see Figure
> + * 6-19). If the Respondersupports 12 or more SVID then the Discover
> + * SVIDs Command Shall be executed multiple times until a Discover
> + * SVIDs VDO is returned ending either with a SVID value of 0x0000 in
> + * the last part of the last VDO or with a VDO containing two SVIDs
> + * with values of 0x0000.
> + *
> + * However, some odd dockers support SVIDs less than 12 but without
> + * 0x0000 in the last VDO, so we need to break the Discover SVIDs
> + * request and return false here.
> + */
> + return cnt == 7;
> abort:
> tcpm_log(port, "SVID_DISCOVERY_MAX(%d) too low!", SVID_DISCOVERY_MAX);
> return false;
This is OK by men, but let's wait for Guenter.
thanks,
--
heikki
next prev parent reply other threads:[~2023-03-17 11:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-16 8:11 [PATCH v2] usb: typec: tcpm: fix multiple times discover svids error Frank Wang
2023-03-16 8:11 ` Frank Wang
2023-03-17 11:27 ` Heikki Krogerus [this message]
2023-03-17 11:27 ` Heikki Krogerus
2023-04-20 8:08 ` Greg KH
2023-04-20 8:08 ` Greg KH
2023-04-20 8:20 ` Heikki Krogerus
2023-04-20 8:20 ` Heikki Krogerus
2023-04-20 13:49 ` Guenter Roeck
2023-04-20 13:49 ` Guenter Roeck
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=ZBROkdOFAP4GPPU6@kuha.fi.intel.com \
--to=heikki.krogerus@linux.intel.com \
--cc=frank.wang@rock-chips.com \
--cc=gregkh@linuxfoundation.org \
--cc=heiko@sntech.de \
--cc=huangtao@rock-chips.com \
--cc=jianwei.zheng@rock-chips.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=william.wu@rock-chips.com \
--cc=wmc@rock-chips.com \
--cc=yubing.zhang@rock-chips.com \
/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.