Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp3234797pxk; Mon, 28 Sep 2020 11:49:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwZaf2yS3OvNDakp+nLckESnZMwFHndK8BlHwYkZi8ADvERAYHxECbJyXtDSWdNnonis5Cb X-Received: by 2002:a50:ba88:: with SMTP id x8mr3461777ede.234.1601318996525; Mon, 28 Sep 2020 11:49:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1601318996; cv=none; d=google.com; s=arc-20160816; b=NImyHGGwXRzUPTFPBd4w96aM1jO9AXbba1MsyueZn0SPQYJh26uttJOGJVzBlXbmfJ SQzPQEs5BtvCDpw/eeMVMDLh4+P75CHdUoo/q5VuGNYMuBukWwgIWP/hmpVJjL2Be2fb SAc15NEoKNUsl2IyDzF5jtWSCrmrkfGUxDRWRy2pn5J7gXAvxU6UX9M2eoBZ/JukgoTS jQl624pWSqSAkgso4QPZmocB12eWt8dJSwU9V1YnuTNSvqcgnU4F4zPZ06vwM3oaP2vO 9Kv3Ogn8xxF/HX2RejfXr6RAGxaWt1N4F0q4BgIsintbYjwiSXLj2sU3k5I0rlO2qYOD UHtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=F0aSQHlsLkxYSoxZfX3/C7kGzwtjN4SKyvEe74v009c=; b=cxF5KOI14RaKSySe58ibFeY3RQ4FRvBGXGUgKqVGl2+yUPn4LQFl/u2H63DwKe4Z7s qaBP5kxNUQoue3INRjqirfqaTq6hNn416oz7aeLyfAsurDv91Z/4xkK0oU3wbSaAW82L 3c7DT26m4Z17x8Jy13QoERu62TFqkHG3GXyReUtbzJtdGXv1PbVEAJRuB4FmT3cvR52t DykgkZ3frJXtex7uQuXQ8JV6sHhHa2ALwHTPqtGxyt4wcimV9h5Tgq3Tgg6I0zMzZ2hN RIgb2jVOad76MbW14MR1W+XAMTbHoc/NNOBcJl1C/sqLEeMwwLFk3LRk11m1ahkHlhyI UHMA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y2si1023117ejc.669.2020.09.28.11.49.33; Mon, 28 Sep 2020 11:49:56 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726701AbgI1SsB (ORCPT + 99 others); Mon, 28 Sep 2020 14:48:01 -0400 Received: from netrider.rowland.org ([192.131.102.5]:54975 "HELO netrider.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1726697AbgI1SsA (ORCPT ); Mon, 28 Sep 2020 14:48:00 -0400 Received: (qmail 145380 invoked by uid 1000); 28 Sep 2020 14:47:59 -0400 Date: Mon, 28 Sep 2020 14:47:59 -0400 From: Alan Stern To: Matthias Kaehlcke Cc: Greg Kroah-Hartman , Rob Herring , Frank Rowand , linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org, Bastien Nocera , Stephen Boyd , Douglas Anderson , Ravi Chandra Sadineni , Krzysztof Kozlowski , devicetree@vger.kernel.org, Peter Chen , "Alexander A. Klimov" , "David S. Miller" , Johan Hovold , Masahiro Yamada , Mauro Carvalho Chehab , Rob Herring Subject: Re: [PATCH v4 2/2] USB: misc: Add onboard_usb_hub driver Message-ID: <20200928184759.GB142254@rowland.harvard.edu> References: <20200928101326.v4.1.I248292623d3d0f6a4f0c5bc58478ca3c0062b49a@changeid> <20200928101326.v4.2.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200928101326.v4.2.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 28, 2020 at 10:13:55AM -0700, Matthias Kaehlcke wrote: > The main issue this driver addresses is that a USB hub needs to be > powered before it can be discovered. For discrete onboard hubs (an > example for such a hub is the Realtek RTS5411) this is often solved > by supplying the hub with an 'always-on' regulator, which is kind > of a hack. Some onboard hubs may require further initialization > steps, like changing the state of a GPIO or enabling a clock, which > requires even more hacks. This driver creates a platform device > representing the hub which performs the necessary initialization. > Currently it only supports switching on a single regulator, support > for multiple regulators or other actions can be added as needed. > Different initialization sequences can be supported based on the > compatible string. > > Besides performing the initialization the driver can be configured > to power the hub off during system suspend. This can help to extend > battery life on battery powered devices which have no requirements > to keep the hub powered during suspend. The driver can also be > configured to leave the hub powered when a wakeup capable USB device > is connected when suspending, and power it off otherwise. > > Technically the driver consists of two drivers, the platform driver > described above and a very thin USB driver that subclasses the > generic driver. The purpose of this driver is to provide the platform > driver with the USB devices corresponding to the hub(s) (a hub > controller may provide multiple 'logical' hubs, e.g. one to support > USB 2.0 and another for USB 3.x). > > Co-developed-by: Ravi Chandra Sadineni > Signed-off-by: Ravi Chandra Sadineni > Signed-off-by: Matthias Kaehlcke > --- Minor cut & paste error: > +static int onboard_hub_power_off(struct onboard_hub *hub) > +{ > + int err; > + > + err = regulator_disable(hub->vdd); > + if (err) { > + dev_err(hub->dev, "failed to enable regulator: %d\n", err); s/enable/disable/ Have you tried manually unbinding and rebinding the two drivers a few times to make sure they will still work? I'm a little concerned about all the devm_* stuff in here; does that get released when the driver is unbound from the device or when the device is unregistered? And if the latter, what happens if you have multiple sysfs attribute groups going at the same time? Apart from those worries and the typo, this looks pretty good to me. Acked-by: Alan Stern Alan Stern