Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3697074imm; Tue, 29 May 2018 11:50:11 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpBLoNpf/rgizKgjGgaxUtKicY9jeWclxyXoK9LjAkoYJqnew3HXYqihcXVrX2n1Ymt9ENB X-Received: by 2002:a17:902:3343:: with SMTP id a61-v6mr18503284plc.241.1527619811612; Tue, 29 May 2018 11:50:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527619811; cv=none; d=google.com; s=arc-20160816; b=KyF4eKoV60iTZcHqdWMm1QmaiAgatCCoKNg0A7G1Q6dZXUhZYL/+9EoNo7UYWAaYHg jXIeuz09ARE9pjOW8ofOhceBSC4WEqHzt0Jfx7BDn0yjFVH6vXIk7aX19zdfM19/yamK j6e6SHNLPBXf25SuFl4nD2Y6/mMFU4VkMG32bwJ0owcAhV7VELNtXCLvhdTJttvjSysi MWz6sdUHOCm3dsE//xWOlIja1tKqAoFZCdcvyQegFOOUwFHEIGOvKbT0OTmP1eo05sQ+ SjZ+zuEEgUS8llyHcaY/sIEEN2XHKvKJKagRpaVF79o/u1SCBqqmY6Ud0xQElOwKaWOG Fxkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to :subject:cc:to:from:date:arc-authentication-results; bh=2AisVST+/Kz5A2HKzx758pCeqYYBzbz6x5iDbbvPABU=; b=fz+PEF72FvJbaUxiHKWESJince29+Lc54ecmmyXCHu0YsrmMHUztGhpYWIdtZOb8wH 0NKX/OMb7rP/JztfpCaDUgwnl+8KYzK2w0GpiuzdxNjBWKQnUOLskfidcH+jwEDQ1OO7 GMpDUUfAgBJ+4mVrRBNwLo3PGNEcqA3w9PT12Rf99uyYyN7YIIV++xQ+jG3BlceF605d 5nTidOLf5/T1dAGF/Ugcc7XaQYfnVNJLB5zulc4qLzRoCzLla+ti1Y7t3aRvWm1TnJK+ 84s21wq+Hbc+r3KemeiTXf6hMG9EGtPPLKr3xQkkMpDRZDWpsF6F7lORfi4RWBZi1CQf V98w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x15-v6si21804704pge.686.2018.05.29.11.49.57; Tue, 29 May 2018 11:50:11 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965954AbeE2StK (ORCPT + 99 others); Tue, 29 May 2018 14:49:10 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:46568 "HELO iolanthe.rowland.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S965610AbeE2StH (ORCPT ); Tue, 29 May 2018 14:49:07 -0400 Received: (qmail 4553 invoked by uid 2102); 29 May 2018 14:49:06 -0400 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 May 2018 14:49:06 -0400 Date: Tue, 29 May 2018 14:49:06 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Martin Liu cc: gregkh@linuxfoundation.org, , , , , , Subject: Re: [RFC PATCH v3] driver core: hold dev's parent lock when needed In-Reply-To: <20180529163428.234106-1-liumartin@google.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 30 May 2018, Martin Liu wrote: > SOC have internal I/O buses that can't be proved for devices. The > devices on the buses can be accessed directly without additinal > configuration required. This type of bus is represented as > "simple-bus". In some platforms, we name "soc" with "simple-bus" > attribute and many devices are hooked under it desribed in DT > (device tree). > > In commit 'bf74ad5bc417 introduce ("[PATCH] Hold the device's > parent's lock during probe and remove")' to solve USB subsystem > lock sequence since usb device's characteristic. Thus "soc" > needs to be locked whenever a device and driver's probing > happen under "soc" bus. During this period, an async driver > tries to probe a device which is under the "soc" bus would be > blocked until previous driver finish the probing and release "soc" > lock. And the next probing under the "soc" bus need to wait for > async finish. Because of that, driver's async probe for init > time improvement will be shadowed. > > Since many devices don't have USB devices' characteristic, they > actually don't need parent's lock. Thus, we introduce a lock flag > in bus_type struct and driver core would lock the parent lock base > on the flag. For usbsystem, we set this flag in usb relatvie > bus_type struct to keep original lock behavior in driver core. > > Async probe could have more benefit after this patch. > > Signed-off-by: Martin Liu > --- > Changes in v3: > -move lock flag to bus_type struct and set the flag in usb > relative bus_type struct to keep original lock behavior. > -fix sign name. > > [v2]: https://lkml.org/lkml/2018/5/29/108 > [v1]: https://lkml.org/lkml/2018/5/22/545 > > Currently, I have the flag set in USB relatvie bus_type struct. > Since I'm not familar with USB part, need some feedback to know > if they cover all the cases that original case driver core > protects. Thanks. As far as I know, only usb_bus_type needs the flag. Not ulpi_bus or usb_serial_bus_type. However, you should check with the maintainers to make sure. > diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c > index 9a2ab6751a23..073954a1a1c5 100644 > --- a/drivers/usb/common/ulpi.c > +++ b/drivers/usb/common/ulpi.c > @@ -94,6 +94,7 @@ static struct bus_type ulpi_bus = { > .uevent = ulpi_uevent, > .probe = ulpi_probe, > .remove = ulpi_remove, > + .need_parent_lock = 1, > }; > > /* -------------------------------------------------------------------------- */ > diff --git a/drivers/usb/core/driver.c b/drivers/usb/core/driver.c > index 9792cedfc351..209ee5d8a92d 100644 > --- a/drivers/usb/core/driver.c > +++ b/drivers/usb/core/driver.c > @@ -1922,4 +1922,5 @@ struct bus_type usb_bus_type = { > .name = "usb", > .match = usb_device_match, > .uevent = usb_uevent, > + .need_parent_lock = 1, > }; > diff --git a/drivers/usb/serial/bus.c b/drivers/usb/serial/bus.c > index 9e265eb92611..55b2636b2804 100644 > --- a/drivers/usb/serial/bus.c > +++ b/drivers/usb/serial/bus.c > @@ -166,6 +166,7 @@ struct bus_type usb_serial_bus_type = { > .probe = usb_serial_device_probe, > .remove = usb_serial_device_remove, > .drv_groups = usb_serial_drv_groups, > + .need_parent_lock = 1, > }; > > int usb_serial_bus_register(struct usb_serial_driver *driver) > diff --git a/include/linux/device.h b/include/linux/device.h > index 477956990f5e..019b193aeb24 100644 > --- a/include/linux/device.h > +++ b/include/linux/device.h > @@ -98,6 +98,8 @@ extern void bus_remove_file(struct bus_type *, struct bus_attribute *); > * @lock_key: Lock class key for use by the lock validator > * @force_dma: Assume devices on this bus should be set up by dma_configure() > * even if DMA capability is not explicitly described by firmware. > + * @need_parent_lock: Assume devices on this bus should hold its' parent's > + * lock during probe and remove. Currently, USB needs it. This comment is not written very well. Suggested improvement: * @need_parent_lock: When probing or removing a device on this bus, the device core should lock the device's parent. If you want, you can say that usb_bus_type sets the flag. I don't think it's really necessary to mention this. Alan Stern