linux-kernel - Re: [v2] musb: omap2430: do not assume balanced enable()/disable()

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:   Fri, 9 Sep 2016 13:55:01 -0700
From:   Tony Lindgren <tony@...mide.com>
To:     Andreas Kemnade <andreas@...nade.info>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Bin Liu <b-liu@...com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-usb@...r.kernel.org, linux-omap@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [v2] musb: omap2430: do not assume balanced enable()/disable()

* Andreas Kemnade <andreas@...nade.info> [160909 13:40]:
> On Fri, 09 Sep 2016 23:21:50 +0300
> Laurent Pinchart <laurent.pinchart@...asonboard.com> wrote:
> > 
> > How exactly is it worse breaking runtime PM than breaking USB gadget 
> > completely ? :-)
> > 
> Does it still break with my phy-twl4030 fixes? At least on gta04,
> they fix real problems and hide the musb problem I tried to fix with
> this patch.
> https://patchwork.kernel.org/patch/9292097/
> https://patchwork.kernel.org/patch/9298447/

Andreas, it's a different USB PHY on pandaboard, that's using
phy-twl6030-usb.c. Probably similar issue.

> > The issue here is that the .disable() platform operation is called by
> > musb with the PHY already powered off, leading to the PHY power
> > reference count becoming negative. The next call to the .enable()
> > operation restores the reference count to 0 without enabling the PHY.
> > 
> > Feel free to send me a better fix and I will test it.
> > 
> The patch has to be reworked on top of the patch series:
> Implement PM runtime for musb-core based on session bit

Yeah that leaves out all most of the trickery with the glue
specific PM runtime tinkering so tracking down any remaining
unbalanced calls should be easier :)

But that's for v4.9, let's see what's the minimal fix for v4.8.

Regards,

Tony