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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AEAB7C7EE2C for ; Tue, 30 May 2023 14:40:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231768AbjE3OkR convert rfc822-to-8bit (ORCPT ); Tue, 30 May 2023 10:40:17 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49500 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230351AbjE3OkQ (ORCPT ); Tue, 30 May 2023 10:40:16 -0400 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 17B11B0; Tue, 30 May 2023 07:40:11 -0700 (PDT) Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4QVw0f3CQsz6J7bl; Tue, 30 May 2023 22:35:14 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Tue, 30 May 2023 15:40:08 +0100 Date: Tue, 30 May 2023 15:40:08 +0100 From: Jonathan Cameron To: Andy Shevchenko CC: , Wolfram Sang , Niyas Sait , Klaus Jensen , Andy Shevchenko , , Jeremy Kerr , Matt Johnston , Shesha Bhushan Sreenivasamurthy , , , "Viacheslav A . Dubeyko" Subject: Re: [RFC PATCH 5/6] HACK: i2c: aspeed: Comment the clock and reset out. Message-ID: <20230530154008.0000444b@Huawei.com> In-Reply-To: References: <20230525152203.32190-1-Jonathan.Cameron@huawei.com> <20230525152203.32190-6-Jonathan.Cameron@huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8BIT X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml100003.china.huawei.com (7.191.160.210) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Sat, 27 May 2023 00:16:36 +0300 Andy Shevchenko wrote: > On Thu, May 25, 2023 at 6:24 PM Jonathan Cameron > wrote: > > > > Needs tidying up - hopefully can do clock right > > using on going work from Niyas > > https://linaro.atlassian.net/wiki/spaces/CLIENTPC/pages/28832333867/ACPI+Clock+Management > > For the current code base the easiest way is to switch to _optional > for clock, or request them based on the type of the fwnode. (Personal > preference is the _optional() API to call). Absolutely agree that would the way to go if people want to support my crazy. However, that will leave the input clock frequency unknown which means we'll program a garbage value into one of the device registers. Doesn't matter to me, but not good in general. This is avoiding for now the questions of: 1) Why devm for a clock we hold for 2 lines of code, none of which have an error return path... 2) clk_get_rate() is documented as not guaranteed to do anything for a clk until enabled, so this is relying on it being enabled by someone else or a quirk of the the chip. > For the reset isn't it > transparent already so we got a dummy control (as for regulator)? I don't think so, but maybe I'm missing something. There is a devm_reset_control_get_optional() though, similar to the clock one that returns a NULL if not present. I'll use that here to make this a slightly less ugly hack. If I can handle clocks nicely using Niyas' work then can revisit whether the i2c and aspeed maintainers would accept making the reset optional. Jonathan > >