Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3512916imm; Tue, 29 May 2018 08:29:17 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoyb2qIvG1xlnm89d/rjra+KqbiTiBp9nCVKPMTsDvIV+fLbSKDYH5LHlw/ffAVd/LQkwqb X-Received: by 2002:a17:902:7841:: with SMTP id e1-v6mr18423436pln.197.1527607757285; Tue, 29 May 2018 08:29:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527607757; cv=none; d=google.com; s=arc-20160816; b=A5uyaUkIWJlO0aQoQuh7fEn8RYFVobkp1/LtP0NU76W8wx79Cd0lTuVIItCLlJM7hc QRW3EWfvfLMLCkYfyy8kFxTEFRLhJ2uOEyl4Pw185Qyhw5zSSV8b8OTYA1r1G89Nz/sw ZGpzY0NzQaEKWBnIlO5uX0Qpw3/5quf6PJU8xkZRMNiJHXDlTaFm3CJDxIzq7On9AKJh +to/sp0EsShhS+5kdQ3WtggGDzGIBEFym2cx094zrZb8Xb1/V9FHow1weWLT/xaPo80R 0hQXwT5glLMnrmsBksY8pe1c5w0yu+aXSmqQh4mX30njgjJ3aBOXVTGp4kUytgm3cP8W tmcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=tADDuCUgyGPMV8FDATWlJXe087OQvPzXFDWs0UOeFEs=; b=B00zvD1nzXffluPhp1VtI599FAUD+49EsjZ+CPBqeMTiHbsHYtILxg5pCEUwEjm702 NgdxbCwTFFVBHSs0WLiHdC4rnbDzL1Al34TVYMEwH88qOqQEFJVVTZqPPba1y9CID3tS MzTY+hlXfuGvpxdsb0vo70P8nKxPNc9Bw/7+EIV4gYHqbqPtFJoIVZgtXOeNQw71VaQJ f4AB8aGzur9tdvz6GlOTQfbxQYgKtWU1+WVL7bWoHSvjPOsTf2QYa9KFoEz+v0OSRyqn /Cm3YzLyKaeJP7Y5fyLEP20bIj6LYZ0DtebQHCbEcUKRv91Q3Vm90/R8IaPVaslA5bLf KFQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cMYDQKqX; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t1-v6si5512337pge.439.2018.05.29.08.29.03; Tue, 29 May 2018 08:29:17 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cMYDQKqX; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936500AbeE2P2e (ORCPT + 99 others); Tue, 29 May 2018 11:28:34 -0400 Received: from mail-qk0-f195.google.com ([209.85.220.195]:45342 "EHLO mail-qk0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935040AbeE2P21 (ORCPT ); Tue, 29 May 2018 11:28:27 -0400 Received: by mail-qk0-f195.google.com with SMTP id c198-v6so11785179qkg.12; Tue, 29 May 2018 08:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tADDuCUgyGPMV8FDATWlJXe087OQvPzXFDWs0UOeFEs=; b=cMYDQKqXNx5jIPswn9CyF8CSVyasfS6hp+ntp+twyzjtfadiOAeykaugjRIgiOVTJD YhCbDSG9B4CwNRCdbgfFoxZ5Q6ft7Z7kevMQ80mhZNTfr8C2v7cueXacBxwNWR15MWif OLnKR7AROCRoZ2XAwl24WdJSBkMZ5p6SAwP7Tc01oZOUnllk7zgNyubbgevYhw/J1Z41 oDias+T5uLyuv2jEtZ3R5eQpR7JtLVR4gkby3aCH7znAJOmr5EGPm21mzJg8q8mQY/EX tG393W1rg970KOmx5MfGIG7EpGCdkGKNHgVY0F52qhoJjjmru4P9s9nen+IR33aXnI5Y 33tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tADDuCUgyGPMV8FDATWlJXe087OQvPzXFDWs0UOeFEs=; b=i0eUiVWdO1FQ58FAaz0UaxkYkQ5Ozj6TU8qAWkbui+QpZeqjLKmjXVsoVZAmHGv3OB /uCWJyjwpomnpvbYJ62kg8j6W8PFLEcHlVEkx8OdUOVjrvgL7feMYz/Uj22hOya31a78 2HK80k7X6QoJM3gdZeMW92MbI1Rn/NeXW0wwyJRWIghm61maZ7HCcnCgKXHD0cgx5Tn1 33JZGk649KK4qHGDuGgNcK4hOs067XVrYjxR4T7wmY41zplJ6V4jLvY4U8tjEQzzVfHZ wxkDjtBLfyVykXdConCGMph8x7afIuTjwxt4xRZOnqulecjoVlpOkvOycGOBNExMesrc Hz9Q== X-Gm-Message-State: ALKqPwf2rcVwX7QlE5mFCzKMwDWbQWP96vslTfeH+o8/IVgbjTU4iOsk Hrg5Me6TvmtXhoGOETPlCxk/Jth/bDEf3Tov8pI= X-Received: by 2002:a37:7742:: with SMTP id s63-v6mr8325690qkc.97.1527607706337; Tue, 29 May 2018 08:28:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0c:9896:0:0:0:0:0 with HTTP; Tue, 29 May 2018 08:28:25 -0700 (PDT) In-Reply-To: <20180529070719.164626-1-liumartin@google.com> References: <20180529070719.164626-1-liumartin@google.com> From: Andy Shevchenko Date: Tue, 29 May 2018 18:28:25 +0300 Message-ID: Subject: Re: [RFC PATCH v2] driver core: hold dev's parent lock when needed To: martin_liu Cc: Alan Stern , "Krogerus, Heikki" , Johan Hovold , Greg Kroah-Hartman , Linux Kernel Mailing List , USB , jenhaochen@google.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 29, 2018 at 10:07 AM, 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 device struct and driver core would lock the parent lock base > on the flag. For usbsystem, we set this flag when its device and > driver is matched and to keep original lock behavior in driver > core. > > Async probe could have more benefit after this patch. > Signed-off-by: martin_liu Strange Firstname Lastname format... > Suggested-by: Alan Stern I guess your SoB should go last (at least this is how -s works in git commit) > /* Some ULPI devices don't have a vendor id so rely on OF match */ > - if (ulpi->id.vendor == 0) > - return of_driver_match_device(dev, driver); > + if (ulpi->id.vendor == 0) { > + if (of_driver_match_device(dev, driver)) { > + dev->need_parent_lock = 1; > + return 1; > + } > + return o; Return what? > + } -- With Best Regards, Andy Shevchenko