linux-kernel - Re: [RFC PATCH 0/7] usb: typec: ucsi: Polling the alt modes and PDOs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 9 Jun 2021 15:18:04 +0300
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Benjamin Berg <bberg@...hat.com>
Cc:     linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/7] usb: typec: ucsi: Polling the alt modes and PDOs

On Wed, Jun 09, 2021 at 02:26:00PM +0300, Heikki Krogerus wrote:
> On Tue, Jun 08, 2021 at 09:32:01PM +0200, Benjamin Berg wrote:
> > On Tue, 2021-06-08 at 09:54 +0300, Heikki Krogerus wrote:
> > > On Tue, Jun 08, 2021 at 09:42:09AM +0300, Heikki Krogerus wrote:
> > > > Please check does the partner device get removed. What do you have
> > > > under /sys/class/typec after that happens?
> > > 
> > > Oh yes. Could you also share the trace output when that happens?
> > > 
> > >         cd /sys/kernel/debug/tracing
> > >         echo 1 > events/ucsi/enable
> > >         # now reproduce the issue
> > >         cat trace > ucsi.trace
> > 
> > So, the partner device is still there when this happens (see below). I
> > also only see a single event in the trace for the fast plug/unplug
> > case:
> >    kworker/u16:8-1771    [003] .... 18848.872145: ucsi_connector_change: port1 status: change=4a04, opmode=5, connected=1, sourcing=0, partner_flags=1, partner_type=1, request_data_obj=1304b12c, BC status=1
> 
> OK. Sorry I had to double check because you were only talking about
> the psy online state.
> 
> Can you now try this HACK on top of these patches:
> 
> diff --git a/drivers/usb/typec/ucsi/ucsi.c b/drivers/usb/typec/ucsi/ucsi.c
> index bd39fe2cb1d0b..99f072700ce7f 100644
> --- a/drivers/usb/typec/ucsi/ucsi.c
> +++ b/drivers/usb/typec/ucsi/ucsi.c
> @@ -843,7 +843,8 @@ static void ucsi_handle_connector_change(struct work_struct *work)
>  
>         if (!status.change) {
>                 dev_dbg(con->ucsi->dev, "con%d: spurious event\n", con->num);
> -               goto out_ack;
> +               /* XXX Force connection check. */
> +               status.change = UCSI_CONSTAT_CONNECT_CHANGE;
>         }
>  
>         event = kzalloc(sizeof(*event), GFP_KERNEL);

No, that's not enough. Sorry.

I'm trying to get a confirmation on my suspecion that we do always
actually get an event from the EC firmware, but we just end up
filtering it out in this case because we are too slow in the driver. I
have an idea what could be done about that, but I need to test if that
really is the case.

I'll prepare a new version out of this entire series.

thanks,

-- 
heikki