Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: bNdQ8RVx4TAm3LjgvNy+PxHUTVUlMUoKLPJxLrjhHXoc2KaFtTNiKRNjoy9QgdW2PXjZMKceVS
 qSf2Go4+GN8w==
IronPort-SDR: EH4gy6QgomgDypw9L4jlR3zQpF1n7SFvtt13NqIYJebiMLwNT8yhyRXg6ohE4s+0VxZlSYP3dg
 MUvhzMyzAXaA==
Date:   Wed, 9 Jun 2021 15:18:04 +0300
From:   Heikki Krogerus <heikki.krogerus@linux.intel.com>
To:     Benjamin Berg <bberg@redhat.com>
Cc:     linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/7] usb: typec: ucsi: Polling the alt modes and PDOs
Message-ID: <YMCxfC+S9EJNEiwq@kuha.fi.intel.com>
References: <20210607131442.20121-1-heikki.krogerus@linux.intel.com>
 <4a76d2152f016b58298bec16aa2003a6ec55f8a8.camel@redhat.com>
 <YL8RPiVsEFOM9PBo@kuha.fi.intel.com>
 <YL8UD+nlBSSQGIMO@kuha.fi.intel.com>
 <f9e1640d4d1a2acbaacf83dee021cd4aa55f233f.camel@redhat.com>
 <YMClRTC8wW82IrDT@kuha.fi.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <YMClRTC8wW82IrDT@kuha.fi.intel.com>
Precedence: bulk

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