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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id C36C4C54E94 for ; Wed, 25 Jan 2023 13:42:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=D/I1D8YBO/2eGSkiu1GJx/EiwHB98gqwAde1YXiV0Pk=; b=U9ogsjer5r3jRW khPC9CgwJSDyoZF/BxxRx74zm/X8Nzn+fnRMWW1CwjlNYwxizCkbbUJSsDpoIQKqVxpfpH0pAuRj1 SIN0LSl8em5R1v8Rxh5J/qx8LAe1NG0k2PtiphkN87vO+VBOdkKDtsD1VQlhVVL5CjnZNsc/PexEU D+LidBe0Mg7Lhtqp3mUnRUimkn/hSWz//o7GyJxlN+nfsSRG45TVPT7Coxf0bb6k8PB/Oh0oD4k83 UO17pGQF/NtbyoC+avURljZvPxuZ7jxMK9zu9bq60WqeVh/Ee3keDoEPKH1emevw+OwtvJ9QIVp+q vhvp4obBWXqmhLLJsUog==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pKg1g-007Ppt-34; Wed, 25 Jan 2023 13:41:20 +0000 Received: from sender4-op-o14.zoho.com ([136.143.188.14]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pKg1c-007PpJ-Ic for linux-arm-kernel@lists.infradead.org; Wed, 25 Jan 2023 13:41:17 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1674654069; cv=none; d=zohomail.com; s=zohoarc; b=FYqS8pXHLDpygW1IQ0GkOLw8TvGh1suuGXX5dcgCR4kviESto6QkhbL2B1aKAjJcVLtj64bpmUFmVLyJee/hjbzg3iBRRLVyYHMaTuvdGnmeD67dbRz0qBIGS10mLNy5guVjQKa71+EkKrU5GRIpTlRBB2VnJO9AI0pF36/5x04= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1674654069; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=Buta/IEuOcOmRkcva2fQ1tSXMH4qcUYXjavj7E1aFaM=; b=H7IVh18j4spC50AvmeauW2WLpWCchVRxizHNYlQ/YU7KE9A+qshM/gQT6He53N66Js84Nxx2wOuhUQZ4pe95HdfB9mevYsDE0MLziSQWgKI1x3XlKBExmj6CHvPULCJdthLFPk+AP1qYRVv7ZRKI/sFTgUWmzzbq0EQNwEWa9vo= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=linux.beauty; spf=pass smtp.mailfrom=me@linux.beauty; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1674654069; s=zmail; d=linux.beauty; i=me@linux.beauty; h=Date:Date:Message-ID:From:From:To:To:Cc:Cc:Subject:Subject:In-Reply-To:References:MIME-Version:Content-Type:Message-Id:Reply-To; bh=Buta/IEuOcOmRkcva2fQ1tSXMH4qcUYXjavj7E1aFaM=; b=iR9fvJXN2YOKwZ4jTdPNlcIB5azaqsL4YvIVUxl0D5Zo71alnZNa/IG9H0+LSOsV ZXkQB0JslpTamZJLId+oKVVSlpJOgBeqdpPkh35hEhCICdGkqPWmc7OALFmtd83sXBu SPKBg05RPZcvndMXv3yrN/aKI+OAkELiekFM2DZw= Received: from lchen-xiaoxin.linux.beauty (221.225.241.248 [221.225.241.248]) by mx.zohomail.com with SMTPS id 1674654067964288.69962327378846; Wed, 25 Jan 2023 05:41:07 -0800 (PST) Date: Wed, 25 Jan 2023 21:40:19 +0800 Message-ID: <87sffyhgvw.wl-me@linux.beauty> From: Li Chen To: Krzysztof Kozlowski Cc: Li Chen , Michael Turquette , Stephen Boyd , Rob Herring , Krzysztof Kozlowski , "moderated list:ARM/Ambarella SoC support" , "open list:COMMON CLK FRAMEWORK" , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , open list , Arnd Bergmann Subject: Re: [PATCH 07/15] dt-bindings: clock: Add Ambarella clock bindings In-Reply-To: References: <20230123073305.149940-1-lchen@ambarella.com> <20230123073305.149940-8-lchen@ambarella.com> <0c19efb4-3bca-f500-ca24-14b9d24369ef@linaro.org> <87y1prgdyu.wl-me@linux.beauty> <87tu0ehl88.wl-me@linux.beauty> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-ZohoMailClient: External X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230125_054116_661960_2B9B62F2 X-CRM114-Status: GOOD ( 29.58 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 25 Jan 2023 20:14:16 +0800, Hi Krzysztof, Krzysztof Kozlowski wrote: > > On 25/01/2023 13:06, Li Chen wrote: > >>> Feel free to correct me if you think this > >>> is not a good idea. > >> > >> This is bad idea. Compatibles should be specific. Devices should not use > >> syscons to poke other registers, unless strictly necessary, but have > >> strictly defined MMIO address space and use it. > > > > Ok, I will convert syscon-based regmaps to SoC-specific compatibles and of_device_id->data. > > > > But I have three questions: > > > > 0. why syscon + offsets is a bad idea copared to specific compatibles? > > Specific compatibles are a requirement. They are needed to match device > in exact way, not some generic and unspecific. The same with every other > interface, it must be specific to allow only correct usage. > > It's of course different with generic fallbacks, but we do not talk > about them here... > > > 1. when would it be a good idea to use syscon in device tree? > > When your device needs to poke one or few registers from some > system-controller block. > > > 2. syscon VS reg, which is preferred in device tree? > > There is no such choice. Your DTS *must* describe the hardware. The > hardware description is for example clock controller which has its own > address space. If you now do not add clock controller's address space to > the clock controller, it is not a proper hardware description. The same > with every other property. If your device has interrupts, but you do not > add them, it is not correct description. Got it. But Ambarella hardware design is kind of strange. I want to add mroe expalaination about why Ambarella's downstream kernel use so much syscon in device trees: For most SoCs from other vendors, they have seperate address space regions for different peripherals, like axi address space A: ENET axi address space B: PCIe axi address space B: USB ... Ambarella is somewhat **different**, its SoCs have two system controllers regions: RCT and scratchpad, take RCT for example: "The S6LM system software interacts with PLLs, PHYs and several other low-level hardware blocks using APB reset clock and test (RCT) registers with a system-layer application programming interface (API). This includes the setting of clock frequencies." There are so many peripherals registers located inside RCT and scratchpad (like usb/phy, gpio, sd, dac, enet, rng), and some peripherals even have no their own modules for register definitions. So most time(for a peripheral driver), the only differences between different Ambarella SoCs are just the syscon(rct or scratchpad) offsets get changed. I don't think such lazy hardware design is common in vendors other than ambarella. If I switch to SoC-specific compatibles, and remove these syscon from device tree, of_device_id->data may only contain system controller(rct or scratchpad) offset for many Ambarella drivers, and ioremap/devm_ioremap carefully. The question is: can upstream kernel accept such codes? If yes, I will switch to SoC-specific compatibles and remove syscon without hesitation. Regards, Li _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel