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;
Date:   Wed, 2 Sep 2020 11:07:43 -0700
From:   Matthias Kaehlcke <mka@chromium.org>
To:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc:     linux-kernel@vger.kernel.org,
        Ravi Chandra Sadineni <ravisadineni@chromium.org>,
        Douglas Anderson <dianders@chromium.org>,
        Bastien Nocera <hadess@hadess.net>,
        Krzysztof Kozlowski <krzk@kernel.org>,
        Stephen Boyd <swboyd@chromium.org>, linux-usb@vger.kernel.org,
        Alan Stern <stern@rowland.harvard.edu>,
        "Alexander A. Klimov" <grandmaster@al2klimov.de>,
        Masahiro Yamada <masahiroy@kernel.org>
Subject: Re: [RFC PATCH] USB: misc: Add usb_hub_pwr driver
Message-ID: <20200902180743.GF3419728@google.com>
References: <20200901132005.RFC.1.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid>
 <20200902060744.GA142357@kroah.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20200902060744.GA142357@kroah.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Greg,

On Wed, Sep 02, 2020 at 08:07:44AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Sep 01, 2020 at 01:21:43PM -0700, Matthias Kaehlcke wrote:
> > diff --git a/drivers/usb/misc/Makefile b/drivers/usb/misc/Makefile
> > index da39bddb0604..2bd02388ca62 100644
> > --- a/drivers/usb/misc/Makefile
> > +++ b/drivers/usb/misc/Makefile
> > @@ -31,3 +31,4 @@ obj-$(CONFIG_USB_CHAOSKEY)		+= chaoskey.o
> >  
> >  obj-$(CONFIG_USB_SISUSBVGA)		+= sisusbvga/
> >  obj-$(CONFIG_USB_LINK_LAYER_TEST)	+= lvstest.o
> > +obj-$(CONFIG_USB_HUB_PWR)		+= usb_hub_pwr.o usb_hub_psupply.o
> 
> Why is this 2 files?  Why can't it just be one?

It's effectively two drivers that work together, it seemed cleaner to me
to have a file for every driver.

The 'usb_hub_psupply' driver (which probably should be named
'onboard_usb_hub' or similar) would even be useful on its own (taking
care of powering the hub on and potentially other setup actions)
with a bit of rework.

> And isn't this much the same thing as many of the other "misc" hub
> controller drivers we have?

There are some commonalities, however most of these drivers seem to
target USB hubs with an I2C bus, using custom 'commands' for initialization
and putting the hub in/out of standby.

The drivers in this patch have two goals:

- provide a generic (configurable) solution for powering up/initializing
  a USB hub
- enable support for powering down a USB hub during system suspend

> And to make it easier to review, can you split out the device tree
> descriptions so that the DT maintainers can review that?

Sure, I wasn't sure if this is the right approach, hence I only sent
an RFC without formal bindings to get initial feedback. As of now it
seems that you are at least not frontally opposed it ;-)