linux-kernel - Re: [PATCH v2] usb: typec: fusb302: Fix masking of comparator and bc

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] [day] [month] [year] [list]

Message-ID: <YZImm0UIy3os5H6Q@kuha.fi.intel.com>
Date:   Mon, 15 Nov 2021 11:21:31 +0200
From:   Heikki Krogerus <heikki.krogerus@...ux.intel.com>
To:     Ondřej Jirman <megous@...ous.com>,
        Guenter Roeck <linux@...ck-us.net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Badhri Jagan Sridharan <badhri@...gle.com>,
        Hans de Goede <hdegoede@...hat.com>,
        "open list:USB TYPEC PORT CONTROLLER DRIVERS" 
        <linux-usb@...r.kernel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] usb: typec: fusb302: Fix masking of comparator and
 bc_lvl interrupts

On Mon, Nov 15, 2021 at 09:55:32AM +0100, Ondřej Jirman wrote:
> On Mon, Nov 15, 2021 at 09:11:42AM +0200, Heikki Krogerus wrote:
> > On Mon, Nov 08, 2021 at 11:28:32AM +0100, Ondrej Jirman wrote:
> > > The code that enables either BC_LVL or COMP_CHNG interrupt in tcpm_set_cc
> > > wrongly assumes that the interrupt is unmasked by writing 1 to the apropriate
> > > bit in the mask register. In fact, interrupts are enabled when the mask
> > > is 0, so the tcpm_set_cc enables interrupt for COMP_CHNG when it expects
> > > BC_LVL interrupt to be enabled.
> > > 
> > > This causes inability of the driver to recognize cable unplug events
> > > in host mode (unplug is recognized only via a COMP_CHNG interrupt).
> > > 
> > > In device mode this bug was masked by simultaneous triggering of the VBUS
> > > change interrupt, because of loss of VBUS when the port peer is providing
> > > power.
> > > 
> > > Fixes: 48242e30532b ("usb: typec: fusb302: Revert "Resolve fixed power role contract setup"")
> > > Signed-off-by: Ondrej Jirman <megous@...ous.com>
> > > Cc: Hans de Goede <hdegoede@...hat.com>
> > 
> > Should this go to stable?
> 
> Without this patch, VBUS is not turned off when I disconnect a hub from the
> Type-C port (because fusb302 will not notice the disconnect), and it stays on
> until next plugin of some device, say a normal non PD charger.
> 
> So I guess for a brief period you can have both sides provide VBUS (until
> fusb302/tcpm processes the next plugin). It may be a problem if VBUS was more
> than 5V (not very likely for devices running this driver, I guess).

OK. So this should find it's way to the stable kernel releases as
well, and it should have the appropriate "Cc: stable@...r.kernel.org"
tag:

https://www.kernel.org/doc/html/latest/process/submitting-patches.html#select-the-recipients-for-your-patch

thanks,

-- 
heikki