From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1A637C47247 for ; Tue, 5 May 2020 08:18:01 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E1FDC206CC for ; Tue, 5 May 2020 08:18:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Lc4xDFzZ"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="lizeE891" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E1FDC206CC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=mSafn7+DAFAL7sToJ/efxwe9H2uE6CfnmOuJh91HU7Q=; b=Lc4xDFzZgHNUed 6gQM0bfawOlXwo4QQ7JJBWGTDKUhj8EacV5uUb1oFr7iJaEzGhZC4BRDDuIvRx0BPxkSvuMXbPYts tVtFVGB6gc7ZDIw6OXRTmNpg/IyYk4m8YR7rXMC0Zm9aFLIAjg8gNeLk0iWpkkvYukTTgPaupXqwu CADFT88Gx4fm4QQYRstfpTet78Rg8Vg+I4SpTu9Z+GEo7ZHWgIZWOdgM6R6WDQWvGDi2paGop9r9d BaiFZPV6w3icO7RpMpQCuaAwlTH17uaghXdSrbOI5nQaKoO2gP31RtjEQhUYrsVFP+oEGiG0J7l0J d/OiqXSNTsU92hOyTWVA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jVsm7-0003sX-2t; Tue, 05 May 2020 08:17:59 +0000 Received: from mail-vk1-xa43.google.com ([2607:f8b0:4864:20::a43]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jVsm1-0003oK-Bi for linux-arm-kernel@lists.infradead.org; Tue, 05 May 2020 08:17:56 +0000 Received: by mail-vk1-xa43.google.com with SMTP id i185so263931vki.12 for ; Tue, 05 May 2020 01:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TbQ/NUsTl64Wiv4a1ipzIuD3CBdf0yc6n6AHT0AzX6s=; b=lizeE8913OsCMHce51oPvAyEnSr00jzla8Wj9ZJX8Yj4J1Psb7aJ12HDbUuxzEASuV CJOcUf/1RPpJ18db073V2gTXAgZrhjOiqKsFQTtxkRjpOYi7p+8iPI6IgM2MLiGzaKLy cLIvq0bhk4yEFz1lkPgzduKThkyI9/FNNBUECjt00MMWx/SmSy1QyuQ90mKXKVovzmJ9 4fKGh0hJnh1TGnDmYd/ZhNdLxC+6X+tPCtAfmgDvTlLfG9iZKYS2tw377gR8NwBlvma+ N8uaPL/HAJq4slF/CQIAr93/bDUWK4Xy5o9CeYh1dInheigK6z+mx2xsFNL4I2ItVIiH Sw4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TbQ/NUsTl64Wiv4a1ipzIuD3CBdf0yc6n6AHT0AzX6s=; b=ZPFA9ws5TmuY+WT3M0cB0yyol2zLb+gg17hSo6eYVWbPRlz+z0BEcos9ec9zvSdqfW XLDiZnJaZ9znMYf6QEioaMaAG3/jjG52xMvbWcyekNpD0DP94COi3kvbPEmxbwaCq7BX PJjPzJfIA2IcWplsVJGYQrfNAtVw9xiSPyXEWTU9/2BlnRcbJht47AwhManXjurEdq37 5x2zBq+L4dETe4RgAR9ZJvXws6+ZEsE6Tmcwrrr+p4mZHAUQ8uRxlFc02wbaHGAEpveS Is4ij1AIFRmeuunGAQ2dbRyxhDyVnY+NCZHP7ewyZAMTg0Wsl4IgfwlyPxLt40XiwfeK iONw== X-Gm-Message-State: AGi0PubqvTnPw9x1a63/acFbq7aNkzxHv+6FyL0vhztPX4zVHuUL8ZKF FULoysDTdIr0BnJSDNwGdytj23keAA22vBNsqUtYRw== X-Google-Smtp-Source: APiQypJn4YPdoD6blL7gFwU0ijM52tdeLzBf7tlSaUAOwu8rfRRQ9Nd8hu+SfYhQA6qyrUO32C4i1Xcp+YT+RFkLY84= X-Received: by 2002:a1f:a60b:: with SMTP id p11mr1325157vke.43.1588666671822; Tue, 05 May 2020 01:17:51 -0700 (PDT) MIME-Version: 1.0 References: <20200428210229.703309-1-martin.blumenstingl@googlemail.com> <20200428210229.703309-3-martin.blumenstingl@googlemail.com> <1jlfmdi9uw.fsf@starbuckisacylon.baylibre.com> <1jh7x1i3hj.fsf@starbuckisacylon.baylibre.com> In-Reply-To: <1jh7x1i3hj.fsf@starbuckisacylon.baylibre.com> From: Ulf Hansson Date: Tue, 5 May 2020 10:17:15 +0200 Message-ID: Subject: Re: [PATCH v6 2/2] mmc: host: meson-mx-sdhc: new driver for the Amlogic Meson SDHC host To: Jerome Brunet , Martin Blumenstingl X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200505_011753_403029_214BFEE8 X-CRM114-Status: GOOD ( 18.98 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: DTML , Jianxin Pan , Stephen Boyd , "linux-mmc@vger.kernel.org" , Linux Kernel Mailing List , yinxin_1989@aliyun.com, Anand Moon , Rob Herring , "open list:ARM/Amlogic Meson..." , Linux ARM , lnykww@gmail.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org [...] > >> > + > >> > + return devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get, > >> > + onecell_data); > >> > >> I think registering a provider for a module that does not provide clocks > >> to any other device is a bit overkill. > >> > >> I understand the matter is getting the per-user clk* pointer. > >> Since this is the module registering the clock, you can use clk_hw->clk > >> to get it. > >> > >> Once you have the clk* of the leaf clocks, you don't even need to keep > >> track of the clk_hw* since you are using devm_ > >> > >> Afterward, we should propably discuss with Stephen if something should > >> be added in CCF to get a struct clk* from struct clk_hw*. > >> > > > > [...] > > > > Hmm. > > > > I am not sure the above is a good idea, at all. Unless, I am > > misunderstanding your point, which may be the case. > > > > I think above "shortcuts" could lead to abuse of the clock framework > > and its internal data structures. When going forward, this could make > > it unnecessary harder to maintain the clock framework. > > > > I know, it's not my responsibility, but from my experience with MMC > > and SDIO interfaces, is that those have been too easy abuse - since > > most of the data structures and interfaces have been exported. Now, > > it's hard to roll back that, if you see what I mean. > > Indeed, it worth clarifying this first. > > With clk_register deprecated in favor of clk_hw_register, we are likely > to see that case rise elsewhere. > So, according to the separate discussion [1], I think we can let Martin decide what option to implement at this point. 1. Implement the "clk_hw_get_clk()" approach. The preferred option, but requires wider changes of the clock subsystem as well. 2. Keep the existing approach, with devm_clk_get(). I am fine with this as well, we can always switch to 1) later on. [...] Kind regards Uffe [1] https://www.spinics.net/lists/linux-clk/msg48373.html _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel