Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp1575179ybx; Thu, 7 Nov 2019 13:54:37 -0800 (PST) X-Google-Smtp-Source: APXvYqz66jZD+dlJHaGHq4ClakxCe5LCZ984MwR+n/6aKRYUKM3AUjSo9Zsporx+2HYslXPQF0bR X-Received: by 2002:aa7:d64e:: with SMTP id v14mr6379019edr.88.1573163677558; Thu, 07 Nov 2019 13:54:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573163677; cv=none; d=google.com; s=arc-20160816; b=UIEGdYTJ2MSp36nK2oVR9eGmiGqcP+bgUNc9MkpS0h8eNLSt7U0zZh6xF3KyGZmC58 q5uCYXcQhGAiv5NjWW0ktiTszzkRq2RHZB4wam3SnSxVToND+eJP/V3XtRjWxP4SdeMq CK4NacBPN7p3bto/8DZDUXysJf+s89Ger24JPtB6RY0iNYa2K4IoDsobWVtLPhqFJ09+ op1u1X4mGKb4ypB79b4XYa8nrsCkB7e+qY1kx5JHaYzg3hJTbphDwhNr6te3I0pi8YoQ o1EIfFxABf/xhK/afr23LoxI8vYaLspMhPIkPQ9sP5gStyeKHXVNVmmrlcur8OJB1P6w 9ptw== 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 :in-reply-to:references:mime-version:dkim-signature; bh=3FodfHTXP/afJoQvu2nyZP20CZjICy2YQPi90S3msRU=; b=WXtaOiFjocoHAiJvYf9MysqyZ2x0MGLwCOeHQufOuR7xRO7grrtnWx4jl6X/S+bDV2 arPErnzezmnmD3BYEo9XMsuH3nzAK7PzCphyw4WMuQI782HUdgfBlw6/1kEsz9hcCO80 m2ROz9e0k/C4Bajd0eUBV/BKvv3Dx4WjNyI9lKXGW9MzhgAT5XGAjmMixZR9CcmdASBb A8yRZqRFLfNIWV5xwIirnfytKiRkz0mDomHY9Pr4l9GO6eSq3hnl3rV+geTscDrfSoA/ lGkPZIAzoyT4EqLprL+cQWDMMfghoafPF07bOj3N5boxAMHRD5R9yZJ1w7ONcZhsqO+U FdLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=IEYJ+z+M; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ce3si2853883edb.441.2019.11.07.13.54.13; Thu, 07 Nov 2019 13:54:37 -0800 (PST) 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=@kernel.org header.s=default header.b=IEYJ+z+M; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726219AbfKGVxa (ORCPT + 99 others); Thu, 7 Nov 2019 16:53:30 -0500 Received: from mail.kernel.org ([198.145.29.99]:33440 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725870AbfKGVx3 (ORCPT ); Thu, 7 Nov 2019 16:53:29 -0500 Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9828E222C5; Thu, 7 Nov 2019 21:53:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1573163608; bh=q6SKsLHXv+qLDAv/Si1jE9FsC4EPM3DgeowAA3ZAaX8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=IEYJ+z+Mor70QcV2yPq7FiaLWy/3ZTvRV6Xh2eM7/xHDjOvmKWGtDoe1mQSYfMdBc yeyqQm0HIVYRAEhXqnY1mPoCdIIFufty6Fcs/zHKqQVlXu+OQ3CPzOonJTvYYTHxvR 6+J+ri0oYQD/oIRQ4Np94MW11oMSPnBmp1gvonaA= Received: by mail-qk1-f176.google.com with SMTP id 205so3485224qkk.1; Thu, 07 Nov 2019 13:53:28 -0800 (PST) X-Gm-Message-State: APjAAAWcvbBtKAc+5M4yugkY6w24c6HpVtt4uKEEepHwO5/hnbyBk6na LCRPS8J1HHk5lLGEshtd4zK306COH0eRDjEdGg== X-Received: by 2002:a05:620a:205d:: with SMTP id d29mr5534809qka.152.1573163607663; Thu, 07 Nov 2019 13:53:27 -0800 (PST) MIME-Version: 1.0 References: <20191028215919.83697-1-john.stultz@linaro.org> <20191028215919.83697-6-john.stultz@linaro.org> <87k18nj4mj.fsf@gmail.com> In-Reply-To: <87k18nj4mj.fsf@gmail.com> From: Rob Herring Date: Thu, 7 Nov 2019 15:53:16 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 5/9] usb: dwc3: Rework clock initialization to be more flexible To: Felipe Balbi Cc: John Stultz , lkml , Greg Kroah-Hartman , Mark Rutland , ShuFan Lee , Heikki Krogerus , Suzuki K Poulose , Chunfeng Yun , Yu Chen , Hans de Goede , Andy Shevchenko , Jun Li , Valentin Schneider , Jack Pham , Linux USB List , devicetree@vger.kernel.org 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, Oct 29, 2019 at 4:14 AM Felipe Balbi wrote: > > > Hi, > > John Stultz writes: > > > The dwc3 core binding specifies three clocks: > > ref, bus_early, and suspend > > > > which are all controlled in the driver together. > > > > However some variants of the hardware my not have all three clks > ^^ > may > > In fact *all* platforms have all three clocks. It's just that in some > cases clock pins are shorted together (or take input from same clock). > > > So this patch reworks the reading of the clks from the dts to > > use devm_clk_bulk_get_all() will will fetch all the clocks > ^^^^ > which? > > > specified in the dts together. > > > > This patch was reccomended by Rob Herring > > as an alternative to creating multiple bindings for each variant > > of hardware when the only unique bits were clocks and resets. > > > > Cc: Greg Kroah-Hartman > > Cc: Rob Herring > > Cc: Mark Rutland > > CC: ShuFan Lee > > Cc: Heikki Krogerus > > Cc: Suzuki K Poulose > > Cc: Chunfeng Yun > > Cc: Yu Chen > > Cc: Felipe Balbi > > Cc: Hans de Goede > > Cc: Andy Shevchenko > > Cc: Jun Li > > Cc: Valentin Schneider > > Cc: Jack Pham > > Cc: linux-usb@vger.kernel.org > > Cc: devicetree@vger.kernel.org > > Suggested-by: Rob Herring > > Signed-off-by: John Stultz > > --- > > v3: Rework dwc3 core rather then adding another dwc-of-simple > > binding. > > --- > > drivers/usb/dwc3/core.c | 20 +++++--------------- > > 1 file changed, 5 insertions(+), 15 deletions(-) > > > > diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c > > index a039e35ec7ad..4d4f1836b62c 100644 > > --- a/drivers/usb/dwc3/core.c > > +++ b/drivers/usb/dwc3/core.c > > @@ -305,12 +305,6 @@ static int dwc3_core_soft_reset(struct dwc3 *dwc) > > return 0; > > } > > > > -static const struct clk_bulk_data dwc3_core_clks[] = { > > - { .id = "ref" }, > > - { .id = "bus_early" }, > > - { .id = "suspend" }, > > -}; > > another option would be to pass three clocks with the same phandle. That > would even make sure that clock usage counts are correct, no? If you have the datasheet for the block, then perhaps some suggestion of which clocks code be the same. My guess would be ref and suspend. Maybe suspend is a fixed clock which is unmanaged on HiSilicon platforms. If we allow for no clocks on some platforms, then why does it have to be all or none? Rob