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  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:   Tue, 08 Nov 2016 07:36:32 +1100
From:   NeilBrown <>
To:     Baolin Wang <>
Cc:     Felipe Balbi <>,
        Greg KH <>,
        Sebastian Reichel <>,
        Dmitry Eremin-Solenikov <>,
        David Woodhouse <>,,
        Jun Li <>,
        Marek Szyprowski <>,
        Ruslan Bilovol <>,
        Peter Chen <>,
        Alan Stern <>,,
        Yoshihiro Shimoda <>,
        Lee Jones <>,
        Mark Brown <>,
        John Stultz <>,
        Charles Keepax <>,,
        Linux PM list <>,
        USB <>,,
        LKML <>
Subject: Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On Mon, Nov 07 2016, Baolin Wang wrote:

> On 3 November 2016 at 09:25, NeilBrown <> wrote:
>> On Tue, Nov 01 2016, Baolin Wang wrote:
> I agree with your most opinions, but these are optimization. 

I see them as bug fixes, not optimizations.

>                                                              Firstly I
> think we should upstream the USB charger driver.

I think you missed the point.  The point is that we don't *need* your
"USB charger driver" because all the infrastructure we need is *already*
present in the kernel.  It is buggy and not used uniformly, and could
usefully be polished and improved.  But the structure is already

If everyone just added new infrastructure when they didn't like, or
didn't understand, what was already present, the kernel would become
like the Mad Hatter's tea party, full of dirty dishes.

>                                                  What I want to ask is
> how can we notify power driver if we don't set the
> usb_register_notifier(), then I think you give the answer is: power
> driver can register by 'struct usb_phy->notifier'. But why usb phy
> should notify the power driver how much current should be drawn, and I
> still think we should notify the current in usb charger driver which
> is better, and do not need to notify current for power driver in usb
> phy driver.

I accept that it isn't clear that the phy *should* be involved in
communicating the negotiated power availability, but nor is it clear
that it shouldn't.  The power does travel through the physical
interface, so physically it plays a role.

But more importantly, it already *does* get told (in some cases).
There is an interface "usb_phy_set_power()" which exists explicitly to
tell the phy what power has been negotiated.  Given that infrastructure
exists and works, it make sense to use it.

If you think it is a broken design and should be removed, then fine:
make a case for that.  Examine the history.  Make sure you know why it
is there (or make sure that information cannot be found), and then
present a case as to why it should be removed and replaced with
something else.  But don't just leave it there and pretend it doesn't
exist and create something similar-but-different and hope people will
know why yours is better.  That way lies madness.


Download attachment "signature.asc" of type "application/pgp-signature" (801 bytes)

Powered by blists - more mailing lists