On Thu, Sep 23, 2021 at 06:06:21PM +0200, Ulrich Huber wrote:
> Hi,
>
> Am 23.09.21 um 16:38 schrieb Benjamin Berg:
> > Hi,
> >
> > On Mon, 2021-09-20 at 17:24 +0300, Heikki Krogerus wrote:
> > > The goal of this series was to improve the alt mode handling in the
> > > driver, but now it seems that we can use the "poll worker" that was
> > > introduced for that to handle other tasks better as well.
> > >
> > > Ulrich reported some problems that are caused by the second
> > > GET_CONNECTOR_STATUS right after the first one that was introduced in
> > > 217504a05532 ("usb: typec: ucsi: Work around PPM losing change
> > > information"). In the last patch I try to improve that workaround by
> > > extracting it out of the generic event handler into its own task and
> > > executing it only when it's really needed. That seems to improve the
> > > situation.
> > >
> > > These patches definitely improve the quality of the driver by making
> > > it a bit more readable, but they also appear to make the behaviour a
> > > bit more predictably and uniform on different platforms.
> > >
> > > Benjamin, can you test these?
> > I just gave this a spin on a X1 Carbon Gen 8 with a Lenovo TB 3 Dock.
> > Unfortunately, I can still reproduce the issue occasionally. My take is
> > that the rate is much lower than it was before my patch was introduced.
> > However, unfortunately the patchset does appear to cause a regression
> > on the machine I tested.
> >
> > As before. The "online" status of the UCSI power supply is reported as
> > "1" occasionally even after the cable was unplugged. And the issue
> > seems to only happens with a dock, not if I use a USB-C charger.
> >
> > Benjamin
>
> From my point of view the patch set is still a huge improvement to the
> current state of the driver. Before it, the status of the UCSI power supply
> was unpredictable when using an USB-C charger with my Lenovo Yoga 9i.
This is the problem with these workarounds that attempt to fix
firmware issues. It's difficult to find a solution that works on every
board. That's why it's important to attempt to isolate them, and use
them only when needed.
Right now the driver does behave quite unpredictable on several boards
because of commit 217504a05532. The way that it solves a single issue
is not isolated enough like it should be, which means every single
connector change event is affected by it even when there is no need
for that, but the solution itself - duplicated command execution - is
also simply too heavy for many EC firmwares.
I do admit that my series still leaves problems, it does not solve
everything, and I'm not claiming that it's actually fixing anything
(it's not tagged as a fix), but it does improve the behaviour of the
driver so much that I still think that we should use it as the new
"baseline" for future improvements.
> I do still get error messages in the kernel log right after waking from
> suspend occasionally, but I have not yet found reproducible steps. Most
> likely it has something to do with the controller being in an invalid state
> after waking from suspension. Though even then the status of the UCSI power
> supply is correct when this happens.
This is most likely separate issue that needs its own fix.
thanks,
--
heikki
