Received: by 2002:a25:31c3:0:0:0:0:0 with SMTP id x186csp610357ybx; Wed, 30 Oct 2019 02:04:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqzLbBc4+ARhh/uiGuW6b3e8kuvav8zmU/P5ncWjd4LnNiM+nwpY1dXX/mg9kVetnitVykiq X-Received: by 2002:a17:906:494e:: with SMTP id f14mr8020555ejt.42.1572426277483; Wed, 30 Oct 2019 02:04:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572426277; cv=none; d=google.com; s=arc-20160816; b=EU0397dD+XJ9a59Qvimj/QejTPyR1umuFI0GuRKZo5JnZIFmzibIgzb8TDldbjesrd uZvzEqWYkYUUeEVVwWgwm0XlNRWsL40oD5Uiyz0J4OzWsc5y7M3H7KwIrYDga9b+slot 1ue4BW50Dr3Xkv/29pDZbIkHdarwRY2u5YYGUiyWHPZX9KBQjOhgleo51HWU9Vh3I0tu 2F41JRdGZIEOo8Tt65jEOjnE487w2KXt6SN+AbBnGZSnRaeDg2poIM9sesbKUqGOuo0X KhOCYMsPxffB5Iehy/Y7NY8Wj2ZODO7a1mLGfesIv/NAA9pyKlLxu9Geez/t0w9WguJP Z3BQ== 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:date:references :in-reply-to:subject:cc:to:from; bh=4P4Co2PEUV4haTjefohEApAJ7Q1hIextJ1uGbIBUwug=; b=iGj2zAxCI+EK8n2IH82y9FhjJaDjfvQTbtN71kWNPqlhYL6Xv8E676sn/T7F3iTGZj NCRpfTdaX17/at8ZouZpPwMkv0lFAvYgMtnbecw3hDPOVlxXW2SeBDceMSk2ktVu/fTH Zbsd8Wi1jx/s3UF2Y9PK65V8l0pL4c4n4384/8jhXGZxrJZohdZwfeoPNib/t23oMmZO JRwfZr05wIEmnhrzxGqRiBmYLR7qqZLr6vf21DZ88DE53b8UYW7LBSmMd6Q9zw7s1Adg eIJjbmtvrJ2hd1sLB6YA7YJ2MaGGJJ596iR28XSdMZalPUR7WHaRU/3xgdVnOsEeEfJl Xctw== 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; dmarc=fail (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 q25si834532ejb.340.2019.10.30.02.04.13; Wed, 30 Oct 2019 02:04:37 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726722AbfJ3JC4 (ORCPT + 99 others); Wed, 30 Oct 2019 05:02:56 -0400 Received: from mga17.intel.com ([192.55.52.151]:7949 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726184AbfJ3JC4 (ORCPT ); Wed, 30 Oct 2019 05:02:56 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Oct 2019 02:02:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.68,246,1569308400"; d="scan'208";a="225264093" Received: from pipin.fi.intel.com (HELO pipin) ([10.237.72.175]) by fmsmga004.fm.intel.com with ESMTP; 30 Oct 2019 02:02:51 -0700 From: Felipe Balbi To: John Stultz Cc: lkml , Greg Kroah-Hartman , Rob Herring , 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 , "open list\:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" Subject: Re: [PATCH v4 5/9] usb: dwc3: Rework clock initialization to be more flexible In-Reply-To: References: <20191028215919.83697-1-john.stultz@linaro.org> <20191028215919.83697-6-john.stultz@linaro.org> <87k18nj4mj.fsf@gmail.com> Date: Wed, 30 Oct 2019 11:02:51 +0200 Message-ID: <87h83qhah0.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, John Stultz writes: > On Tue, Oct 29, 2019 at 2:14 AM Felipe Balbi wrote: >> 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). >> > ... >> another option would be to pass three clocks with the same phandle. That >> would even make sure that clock usage counts are correct, no? > > Hey Felipe! > > So I actually had done that initially (and it seemed to work), but Rob > suggested this way instead. > I'm fine with either, as long as having multiple references to the > same clk in the enable/disable paths doesn't cause trouble. > > Thanks so much for the review here! same as the other patch, if we're supposed to describe the HW, then we should describe what's actually happening. -- balbi