linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Matthias Kaehlcke <mka@chromium.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-usb@vger.kernel.org, Bastien Nocera <hadess@hadess.net>,
	Stephen Boyd <swboyd@chromium.org>,
	Alan Stern <stern@rowland.harvard.edu>,
	Ravi Chandra Sadineni <ravisadineni@chromium.org>,
	Krzysztof Kozlowski <krzk@kernel.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>, Peter Chen <peter.chen@nxp.com>,
	"Alexander A. Klimov" <grandmaster@al2klimov.de>,
	"David S. Miller" <davem@davemloft.net>,
	Johan Hovold <johan@kernel.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
	Rob Herring <robh@kernel.org>
Subject: Re: [PATCH v4 2/2] USB: misc: Add onboard_usb_hub driver
Date: Mon, 28 Sep 2020 15:03:20 -0700	[thread overview]
Message-ID: <CAD=FV=V+jnBkjT-heZ1h10pQPHsbuoY5+or0Kx7Oa4dAGTNW2w@mail.gmail.com> (raw)
In-Reply-To: <20200928101326.v4.2.I7c9a1f1d6ced41dd8310e8a03da666a32364e790@changeid>

Hi,

On Mon, Sep 28, 2020 at 10:14 AM Matthias Kaehlcke <mka@chromium.org> wrote:
>
> +static ssize_t power_off_in_suspend_show(struct device *dev, struct device_attribute *attr,
> +                          char *buf)
> +{
> +       struct onboard_hub *hub = dev_get_drvdata(dev);
> +
> +       return sprintf(buf, "%d\n", hub->power_off_in_suspend);
> +}
> +
> +static ssize_t power_off_in_suspend_store(struct device *dev, struct device_attribute *attr,
> +                           const char *buf, size_t count)
> +{
> +       struct onboard_hub *hub = dev_get_drvdata(dev);
> +       bool val;
> +       int ret;
> +
> +       ret = kstrtobool(buf, &val);
> +       if (ret < 0)
> +               return ret;
> +
> +       hub->power_off_in_suspend = val;
> +
> +       return count;
> +}
> +static DEVICE_ATTR_RW(power_off_in_suspend);

I wish there was a short name that meant "try to power off in suspend
unless there's an active wakeup source underneath you".  The name here
is a bit misleading since we might keep this powered if there's an
active wakeup source even if "power_off_in_suspend" is true...  I
wonder if it's easier to describe the opposite, like
"always_power_in_suspend".  Then, if that's false, it'll be in
"automatic" mode and if it's true it'll always keep powered.

I guess you can also argue about what the default should be.  I guess
if you just left it as zero-initted then we'd (by default) power off
in suspend.  To me that seems like a saner default, but I'm probably
biased.


> +static int onboard_hub_remove(struct platform_device *pdev)
> +{
> +       struct onboard_hub *hub = dev_get_drvdata(&pdev->dev);
> +       struct udev_node *node;
> +       struct usb_device *udev;
> +
> +       hub->going_away = true;
> +
> +       mutex_lock(&hub->lock);
> +
> +       /* unbind the USB devices to avoid dangling references to this device */
> +       while (!list_empty(&hub->udev_list)) {
> +               node = list_first_entry(&hub->udev_list, struct udev_node, list);
> +               udev = node->udev;
> +
> +               /*
> +                * Unbinding the driver will call onboard_hub_remove_usbdev(),
> +                * which acquires hub->lock.  We must release the lock first.
> +                */
> +               get_device(&udev->dev);
> +               mutex_unlock(&hub->lock);
> +               device_release_driver(&udev->dev);
> +               put_device(&udev->dev);
> +               mutex_lock(&hub->lock);

I didn't try to grok all the removal corner cases since it seems like
you and Alan have been going over that.  If you feel like this needs
extra attention then yell and I'll look closer.


> +static const struct of_device_id onboard_hub_match[] = {
> +       { .compatible = "onboard-usb-hub" },
> +       { .compatible = "realtek,rts5411" },

You only need "onboard-usb-hub" here.  The bindings still have
"realtek,rts5411" in them in case we later have to do something
different/special on that device, but the whole idea of including the
generic is that we don't need to add every specific instance to this
table.

The above is pretty much nits, though, so:

Reviewed-by: Douglas Anderson <dianders@chromium.org>

  parent reply	other threads:[~2020-09-28 23:28 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-28 17:13 [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs Matthias Kaehlcke
2020-09-28 17:13 ` [PATCH v4 2/2] USB: misc: Add onboard_usb_hub driver Matthias Kaehlcke
2020-09-28 18:47   ` Alan Stern
2020-09-29  1:43     ` Matthias Kaehlcke
2020-09-29 16:00       ` Alan Stern
2020-09-29 16:50         ` Matthias Kaehlcke
2020-09-28 22:03   ` Doug Anderson [this message]
2020-09-29  1:59     ` Matthias Kaehlcke
2020-09-28 22:13 ` [PATCH v4 1/2] dt-bindings: usb: Add binding for discrete onboard USB hubs Doug Anderson
2020-09-29  2:14   ` Matthias Kaehlcke
2020-09-29 20:17 ` Rob Herring
2020-09-29 22:09   ` Matthias Kaehlcke
2020-09-30  1:32     ` Alan Stern
2020-09-30 12:49       ` Matthias Kaehlcke
2020-09-30 14:44         ` Rob Herring
2020-09-30 15:28           ` Doug Anderson
2020-09-30 18:00             ` Doug Anderson
2020-09-30 19:19               ` Rob Herring
2020-10-01 21:39                 ` Matthias Kaehlcke
2020-09-30 19:19             ` Alan Stern
2020-09-30 20:20             ` Rob Herring
2020-10-01  1:24               ` Alan Stern
2020-10-01 21:54                 ` Matthias Kaehlcke
2020-10-02  1:21                   ` Alan Stern
2020-10-02 16:08                     ` Matthias Kaehlcke
2020-10-02 18:48                       ` Alan Stern
2020-10-02 17:08               ` Doug Anderson
2020-10-02 18:36                 ` Alan Stern
2020-10-02 22:58                   ` Rob Herring
2020-10-03 12:41                     ` Alan Stern
2020-10-05 16:06                       ` Matthias Kaehlcke
2020-10-05 16:15                         ` Alan Stern
2020-10-05 19:18                           ` Matthias Kaehlcke
2020-10-05 19:36                             ` Alan Stern
2020-10-05 19:59                               ` Rob Herring
2020-10-05 23:29                                 ` Matthias Kaehlcke
2020-10-05 19:36                             ` Rob Herring
2020-10-05 19:20                         ` Rob Herring
2020-10-02 22:28                 ` Rob Herring
2020-10-02 23:09                   ` Doug Anderson
2020-10-06  0:45                     ` Matthias Kaehlcke
2020-10-06 14:18                       ` Alan Stern
2020-10-06 16:59                         ` Matthias Kaehlcke
2020-10-06 17:15                           ` Alan Stern
2020-10-06 19:25                             ` Matthias Kaehlcke
2020-10-07  1:00                               ` Alan Stern
2020-10-07 16:03                                 ` Matthias Kaehlcke
2020-10-07 16:38                                   ` Alan Stern
2020-10-07 17:28                                     ` Matthias Kaehlcke
2020-10-07 19:25                                       ` Alan Stern
2020-10-07 19:42                                         ` Matthias Kaehlcke
2020-10-07 20:17                                           ` Alan Stern
2020-10-07 21:42                                             ` Matthias Kaehlcke
2020-10-08 14:09                                               ` Alan Stern
2020-10-09 23:13                                                 ` Matthias Kaehlcke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD=FV=V+jnBkjT-heZ1h10pQPHsbuoY5+or0Kx7Oa4dAGTNW2w@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=grandmaster@al2klimov.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=hadess@hadess.net \
    --cc=johan@kernel.org \
    --cc=krzk@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mchehab+huawei@kernel.org \
    --cc=mka@chromium.org \
    --cc=peter.chen@nxp.com \
    --cc=ravisadineni@chromium.org \
    --cc=robh+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=swboyd@chromium.org \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).