public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Andy Gross <agross@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Rob Herring <robh@kernel.org>,
	linux-usb@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH v2 0/2] usb: typec: ucsi: add workaround for several Qualcomm platforms
Date: Fri, 8 Dec 2023 12:48:17 +0100	[thread overview]
Message-ID: <ZXMCgVWNCfwmY8oS@hovoldconsulting.com> (raw)
In-Reply-To: <CAA8EJpoG-qg24wV953Xd9KQ957gpJVHc20Te2cYQWfs9imC63w@mail.gmail.com>

On Fri, Dec 08, 2023 at 01:10:59PM +0200, Dmitry Baryshkov wrote:
> On Fri, 8 Dec 2023 at 13:09, Johan Hovold <johan@kernel.org> wrote:
> > On Fri, Dec 08, 2023 at 12:58:29PM +0200, Dmitry Baryshkov wrote:
> > > On Fri, 8 Dec 2023 at 10:39, Johan Hovold <johan@kernel.org> wrote:
> > > > On Wed, Oct 25, 2023 at 02:49:28PM +0300, Dmitry Baryshkov wrote:
> > > > > The UCSI firmware on Qualcomm SC8180X, SC8280XP and SM8350 are buggy.
> > > > > Submitting UCSI_GET_PDOS command for partners which do not actually
> > > > > support PD and do not have PDOs causes firmware to crash, preventing
> > > > > further UCSI activity. Firmware on newer platforms have fixed this
> > > > > issue. In order to still be able to use UCSI functionality on the
> > > > > mentioned platforms (e.g. to be able to handle USB role switching),
> > > > > apply a workaround that completely shortcuts UCSI_GET_PDOS command for
> > > > > the USB-C partner.
> > > > >
> > > > > This has been tested on sm8350 only, but should apply to other
> > > > > platforms. I did not enable UCSI for sc8180x yet, it has slightly
> > > > > different implementation, which I'd like to get tested first.
> > > >
> > > > Has no one tested this on sc8280xp/x13s before merging?
> > > >
> > > > I see a bunch of errors with this series applied to 6.7-rc4:
> > > >
> > > > [   11.999960] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: timeout waiting for UCSI sync write response
> > > > [   12.000430] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: ucsi_handle_connector_change: GET_CONNECTOR_STATUS failed (-110)
> > > > [   17.120515] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: timeout waiting for UCSI sync write response
> > > > [   17.124204] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: GET_CONNECTOR_STATUS failed (-110)
> > > > [   23.264792] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: timeout waiting for UCSI sync write response
> > > > [   23.264953] ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: GET_CONNECTOR_STATUS failed (-110)
> > >
> > > Can you please post previous messages or is the first timeout the
> > > first error from ucsi?
> >
> > These are all the ucsi messages in the log (dmesg | grep ucsi).
> >
> > The first error is sometimes GET_CONNECTOR_STATUS failed (-95) instead:
> 
> Ack, thank you. This is pending on my side together with the UCSI
> glink / altmode rework. I hope to have patches for that closer to the
> NY.

What does that mean? That we shall revert these patches until that work
is finished? I don't want to have these errors littering the logs,
scaring users and possibly slowing down boot (those are five second
timeouts).

Also, if this was known issue, why wasn't it mentioned the cover letter
or commit messages?

Johan

  reply	other threads:[~2023-12-08 11:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-25 11:49 [PATCH v2 0/2] usb: typec: ucsi: add workaround for several Qualcomm platforms Dmitry Baryshkov
2023-10-25 11:49 ` [PATCH v2 1/2] usb: typec: ucsi: fix UCSI on buggy Qualcomm devices Dmitry Baryshkov
2023-10-25 12:03   ` Neil Armstrong
2023-10-30  9:06   ` Heikki Krogerus
2023-10-25 11:49 ` [PATCH v2 2/2] soc: qcom: pmic_glink: enable UCSI by default Dmitry Baryshkov
2023-10-25 12:03   ` Neil Armstrong
2023-12-08  8:40 ` [PATCH v2 0/2] usb: typec: ucsi: add workaround for several Qualcomm platforms Johan Hovold
2023-12-08 10:58   ` Dmitry Baryshkov
2023-12-08 11:10     ` Johan Hovold
2023-12-08 11:10       ` Dmitry Baryshkov
2023-12-08 11:48         ` Johan Hovold [this message]
2023-12-08 12:16           ` Dmitry Baryshkov
2023-12-08 12:26             ` Johan Hovold
2023-12-08 12:27               ` Dmitry Baryshkov
2023-12-08 14:55 ` Bjorn Andersson

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=ZXMCgVWNCfwmY8oS@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=robh@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