On Thu, Sep 23, 2021 at 06:06:21PM +0200, Ulrich Huber wrote:

Hi,

Am 23.09.21 um 16:38 schrieb Benjamin Berg:

quoted

Hi,

On Mon, 2021-09-20 at 17:24 +0300, Heikki Krogerus wrote:

quoted

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