Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1659353imm; Thu, 14 Jun 2018 01:31:52 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLhYCYH6RlaMk0VSmx78eyGe+rScpCHKZk9Pvma7Sc/qrkSpSmOPrmjW7uLezRGwLhphkui X-Received: by 2002:a63:41c1:: with SMTP id o184-v6mr1473109pga.323.1528965112472; Thu, 14 Jun 2018 01:31:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528965112; cv=none; d=google.com; s=arc-20160816; b=ZoPiE7fw+o0nP6KF6YQ+Kxq6PgxX25n56oJz14ciP+ISLxJg6PMX7FESZP7fj6y+QF reS9Hd3G2a2f7l27D88XoiqkB40EnikjyK24a4ACJ8IdIKRsySCay15GRPDeJOm9QaBm ppdg558qEL8uEm556fLmFG7O+OYkSVIhOxHUWjO56o3YMmalW46QuLZdPlF8Xb2lr99B 5DyLiX7sUipkN63R0tS8g+EphCh4o5h7hQS6Bat7hPyph8Ip/SUW9UPafArYcOZehOUn v91vQsnLFv46CV94mzQpaTl/zPQ5K7iQukARUn2mgpHneEOgLHqS6GTH7sHYrqdPdi8S BaWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=sSkB6eHlnfRTqgG3qod8aVkLv6C/REtyOOMcv4uT6t0=; b=N0Sc/t2asBgejbm3BnztC9pYrBo+qybGvoc5LZxHUS09nJ4QDJ4Lb2I9b4ACaYvEMI DuY0u/EtgZwnuthVExsgRD+4NtpCYIz3OB12KyI5ZT7EYxbqmr59B1wN8xMDJaO8uMqW 1zx2088mepif2v7lmHyQ4U3zW8V142qyKECcQ0lPdeBQOKojnIXh/E3RUMpA9qogelGo etPzfDYIExLMJhGr1/t+iwgYFiYhEHPt+odjYQ8Hv62M+Q+3swayUVcsp0AJpvnzYgsl qi3xsu5QAXpT3FcFPKC5OJ2KgFRyZvmsvthaZYuWiWbfMAGyKPnV8SrP6zvW1uStlPdx NAzg== 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 o3-v6si4054560pgc.381.2018.06.14.01.31.38; Thu, 14 Jun 2018 01:31:52 -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 S1754685AbeFNIbI convert rfc822-to-8bit (ORCPT + 99 others); Thu, 14 Jun 2018 04:31:08 -0400 Received: from gloria.sntech.de ([95.129.55.99]:51846 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752887AbeFNIbG (ORCPT ); Thu, 14 Jun 2018 04:31:06 -0400 Received: from ip5f5a8448.dynamic.kabel-deutschland.de ([95.90.132.72] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1fTNej-0003Ma-EU; Thu, 14 Jun 2018 10:30:57 +0200 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: David Wu Cc: davem@davemloft.net, robh+dt@kernel.org, mark.rutland@arm.com, huangtao@rock-chips.com, netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] net: ethernet: stmmac: dwmac-rk: Add GMAC support for PX30 Date: Thu, 14 Jun 2018 10:30:56 +0200 Message-ID: <2582999.2hZx6CH9S6@diego> In-Reply-To: <3aa2445f-ab2a-93b6-3a49-36be6c98d327@rock-chips.com> References: <1528956927-32440-1-git-send-email-david.wu@rock-chips.com> <1961033.25ax7s0Z5i@diego> <3aa2445f-ab2a-93b6-3a49-36be6c98d327@rock-chips.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8BIT 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 Am Donnerstag, 14. Juni 2018, 10:14:31 CEST schrieb David Wu: > Hi Heiko, > > 在 2018年06月14日 15:54, Heiko Stübner 写道: > > I don't see that new clock documented in the dt-binding. > > Also, which clock from the clock-controller does this connect to? > > The clock is the "SCLK_GMAC_RMII" at the clock-controller, which could > be set rate by the link speed. Hmm, while these huge number of clocks are somewhat strange, shouldn't it be named something with _rmii instead of _speed then? Also, I don't see any clk_enable action for that new clock, so you could end up with being off? And someone could convert the driver to use the new clk-bulk APIs [0], so the large number of clk_prepare_enable calls would be a bit trimmed down. Heiko [0] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/clk-bulk.c