From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 70228C48BD1 for ; Wed, 9 Jun 2021 12:18:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 5758C60E0C for ; Wed, 9 Jun 2021 12:18:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234936AbhFIMUF (ORCPT ); Wed, 9 Jun 2021 08:20:05 -0400 Received: from mga01.intel.com ([192.55.52.88]:23373 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235243AbhFIMUC (ORCPT ); Wed, 9 Jun 2021 08:20:02 -0400 IronPort-SDR: bNdQ8RVx4TAm3LjgvNy+PxHUTVUlMUoKLPJxLrjhHXoc2KaFtTNiKRNjoy9QgdW2PXjZMKceVS qSf2Go4+GN8w== X-IronPort-AV: E=McAfee;i="6200,9189,10009"; a="226428813" X-IronPort-AV: E=Sophos;i="5.83,260,1616482800"; d="scan'208";a="226428813" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Jun 2021 05:18:07 -0700 IronPort-SDR: EH4gy6QgomgDypw9L4jlR3zQpF1n7SFvtt13NqIYJebiMLwNT8yhyRXg6ohE4s+0VxZlSYP3dg MUvhzMyzAXaA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,260,1616482800"; d="scan'208";a="552657263" Received: from kuha.fi.intel.com ([10.237.72.162]) by fmsmga001.fm.intel.com with SMTP; 09 Jun 2021 05:18:05 -0700 Received: by kuha.fi.intel.com (sSMTP sendmail emulation); Wed, 09 Jun 2021 15:18:04 +0300 Date: Wed, 9 Jun 2021 15:18:04 +0300 From: Heikki Krogerus To: Benjamin Berg 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: References: <20210607131442.20121-1-heikki.krogerus@linux.intel.com> <4a76d2152f016b58298bec16aa2003a6ec55f8a8.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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