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 2305DC433EF for ; Fri, 20 May 2022 09:08:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1347571AbiETJIq (ORCPT ); Fri, 20 May 2022 05:08:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1347452AbiETJIo (ORCPT ); Fri, 20 May 2022 05:08:44 -0400 Received: from mailgw01.mediatek.com (unknown [60.244.123.138]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3C37C13C1D5; Fri, 20 May 2022 02:08:43 -0700 (PDT) X-UUID: fa57006af4d64a719e7146ce2c2c3ca2-20220520 X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.5,REQID:4add1bdb-e9bd-4862-baff-fa1712f6496c,OB:0,LO B:0,IP:0,URL:0,TC:0,Content:0,EDM:0,RT:0,SF:0,FILE:0,RULE:Release_Ham,ACTI ON:release,TS:0 X-CID-META: VersionHash:2a19b09,CLOUDID:6946ff79-5ef6-470b-96c9-bdb8ced32786,C OID:IGNORED,Recheck:0,SF:nil,TC:nil,Content:-5,EDM:-3,IP:nil,URL:0,File:ni l,QS:0,BEC:nil X-UUID: fa57006af4d64a719e7146ce2c2c3ca2-20220520 Received: from mtkmbs11n1.mediatek.inc [(172.21.101.185)] by mailgw01.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 1345200159; Fri, 20 May 2022 17:08:35 +0800 Received: from mtkmbs11n1.mediatek.inc (172.21.101.186) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 20 May 2022 17:08:34 +0800 Received: from mtksdccf07.mediatek.inc (172.21.84.99) by mtkmbs11n1.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.3 via Frontend Transport; Fri, 20 May 2022 17:08:34 +0800 From: Miles Chen To: CC: , , , , , , , , , , , , , , , <~postmarketos/upstreaming@lists.sr.ht> Subject: Re: [PATCH 3/6] clk: mediatek: reset: Return reset data pointer on register Date: Fri, 20 May 2022 17:08:34 +0800 Message-ID: <20220520090834.28515-1-miles.chen@mediatek.com> X-Mailer: git-send-email 2.18.0 In-Reply-To: <5b5f6656-8694-dc78-ef42-7ce301849aa4@collabora.com> References: <5b5f6656-8694-dc78-ef42-7ce301849aa4@collabora.com> MIME-Version: 1.0 Content-Type: text/plain X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org > Il 19/05/22 15:47, Yassine Oudjana ha scritto: > > From: Yassine Oudjana > > > > Return a struct mtk_clk_rst_data * when registering a reset > > controller in preparation for adding an unregister helper > > that will take it as an argument. Make the necessary changes > > in drivers that do not currently discard the return value > > of register functions. > > > > Signed-off-by: Yassine Oudjana > > Hello Yassine, > > Thanks for your efforts on helping to make the MediaTek clocks better - I agree > (and I'm not the only one..) that there's a lot of work to do on this side. > > Though... I don't think that this is the right direction: you're right about > properly unregistering (in patch 4/6) the reset controllers on rmmod/failure > but I'm not sure that this kind of noise brings any benefit. > > Explaining: > You definitely saw that there's a new register _with_dev, which uses devm ops > and that's going to automatically cleanup in case of removal/failure. > This is what we should do. > > Hence, my proposal is to drop patch 3/6, 4/6, 5/6 and (slowly, steadily) migrate > all of the MediaTek clocks from CLK_OF_DECLARE() to platform drivers (which also > means that we can eventually change them to tristate!), so that we slowly remove > all users of all functions that are not "_with_dev", and that we finally remove > all of these then-unused functions as well. > > Making sure that I don't get misunderstood: > I'm not implying that this huge migration work is on your shoulders! > > P.S.: Chen-Yu, Miles: do you also agree? :-) Agreed. 3/6, 4/6, 5/6 introduce mtk_simple_clk_controller, but we just got ChenYu's patch merged to clk-next to switch to clk_hw_onecell_data, and hoplefully we can test them in v5.18 or v5.19. So I think we should wait for ChenYu's cleanup. - struct clk_hw_onecell_data *clk_data; + struct mtk_simple_clk_controller *clk_ctrl; thanks, Miles > > Cheers, > Angelo > >