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 8244BC433F5 for ; Mon, 14 Mar 2022 17:56:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243533AbiCNR5T (ORCPT ); Mon, 14 Mar 2022 13:57:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53236 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240191AbiCNR5R (ORCPT ); Mon, 14 Mar 2022 13:57:17 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A6E0A3EF05; Mon, 14 Mar 2022 10:56:06 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 11997ED1; Mon, 14 Mar 2022 10:56:06 -0700 (PDT) Received: from [10.57.42.204] (unknown [10.57.42.204]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A2C333F66F; Mon, 14 Mar 2022 10:56:04 -0700 (PDT) Message-ID: <5107aba4-a03d-a0c9-dc89-0e8472be1bd8@arm.com> Date: Mon, 14 Mar 2022 17:55:59 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH v2 3/3] ARM: dts: lpc32xx: Update spi clock properties Content-Language: en-GB To: Arnd Bergmann Cc: Vladimir Zapolskiy , Kuldeep Singh , Olof Johansson , SoC Team , Rob Herring , DTML , Linux ARM , Linux Kernel Mailing List References: <20220311093800.18778-1-singh.kuldeep87k@gmail.com> <20220311093800.18778-4-singh.kuldeep87k@gmail.com> <4aae560d-d266-d0d0-136f-32891b15bc01@mleia.com> <4f39f086-1932-1729-8761-d5c533356812@mleia.com> From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022-03-14 12:32, Arnd Bergmann wrote: > On Mon, Mar 14, 2022 at 1:20 PM Robin Murphy wrote: >> On 2022-03-14 11:50, Vladimir Zapolskiy wrote: >>> On 3/14/22 1:43 PM, Robin Murphy wrote: > >>> >>> Thank you, it explains, why "apb_pclk" is required for all PrimeCell >>> controllers on the SoC. Nevertheless, in commit 93898eb775e5 it was >>> misidentified with the sspclk clock, the latter one is the only clock >>> explicitly utilized by the driver in 2015 and till today. Fixes in dts >>> files should be preceded by a fix in the driver. >> >> There's nothing to fix in the driver, though. In fact it can only be >> working today because the Linux driver isn't very strict and simply >> assumes that the first clock entry is SSPCLK *without* considering its >> name (other consumers of the binding might be stricter; I don't know), >> and because presumably the HCLK happens to be enabled already anyway. >> Changing the driver behaviour would only stand to cause functional >> regressions. > > We can change the driver to look for an sspclk by name first, and > then fall back to the first clk if none is found. This would be backwards > compatible and allow new dts files to have an arbitrary order, though > we still need to be careful about changing the existing dts files after > that, to avoid breaking older kernels. Yeah, I discounted that since schema is strict about the order of entries even when they're named, so we'd have nothing to gain except the potential to break compatibility in one direction and annoy users in the other. There's little point in having code to look up a clock by name when we know that for compatibility reasons it has to be the first clock, so it would be functionally identical to the fallback code that we also still have to have. All it could offer is additionally printing a message about it, and experience says that that achieves little except the aforementioned annoyance of users - I look as far as my Rockchip boards that have all been screaming an error at me every boot for nearly 4 years now, where the ethernet driver fails to get a clock that only exists on some SoCs *other* than the ones I have :( Robin. 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 C2FBAC433EF for ; Mon, 14 Mar 2022 17:57:20 +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-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:From:References:Cc:To:Subject: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8ao0g0Puy6YLBFJ/EA9SsAbxmQhlxKH4/3qSkzQs4PY=; b=KfmApr9E23YBd7 ZtXkMDlmVb9eahRXtugxphBcG6+HKVycZTKStvh0B7g6se5JBuj9v6SGmvLHKWIhWQi+0tqWWhOAT nVnf7xxrtx1LbvX4QkRWzZgYEK0zm1d7GRjW2KILkEp6pWEBPzroKMajdwyF753Gko6rEy0+vkmQU gUWgD4r3VA63CLLjMJwT7aM3STPioJtHOf1eR0OmSXr9xqYyf855nPVVqC1pGBkenJ8P34rOxFTr1 8YxmNdG5vJxrYOefSiX6Wf9mNJ/skc5GQHm1Nm75PPZA+Q44C7huh7VpMByH2pBpiVn/vzkPso5GS m1Nb+iqwfFiTUKfnioCA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nTovR-006Qsl-T4; Mon, 14 Mar 2022 17:56:10 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nTovO-006Qs2-VP for linux-arm-kernel@lists.infradead.org; Mon, 14 Mar 2022 17:56:08 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 11997ED1; Mon, 14 Mar 2022 10:56:06 -0700 (PDT) Received: from [10.57.42.204] (unknown [10.57.42.204]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id A2C333F66F; Mon, 14 Mar 2022 10:56:04 -0700 (PDT) Message-ID: <5107aba4-a03d-a0c9-dc89-0e8472be1bd8@arm.com> Date: Mon, 14 Mar 2022 17:55:59 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.6.2 Subject: Re: [PATCH v2 3/3] ARM: dts: lpc32xx: Update spi clock properties Content-Language: en-GB To: Arnd Bergmann Cc: Vladimir Zapolskiy , Kuldeep Singh , Olof Johansson , SoC Team , Rob Herring , DTML , Linux ARM , Linux Kernel Mailing List References: <20220311093800.18778-1-singh.kuldeep87k@gmail.com> <20220311093800.18778-4-singh.kuldeep87k@gmail.com> <4aae560d-d266-d0d0-136f-32891b15bc01@mleia.com> <4f39f086-1932-1729-8761-d5c533356812@mleia.com> From: Robin Murphy In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220314_105607_104494_80A2A8BA X-CRM114-Status: GOOD ( 22.13 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2022-03-14 12:32, Arnd Bergmann wrote: > On Mon, Mar 14, 2022 at 1:20 PM Robin Murphy wrote: >> On 2022-03-14 11:50, Vladimir Zapolskiy wrote: >>> On 3/14/22 1:43 PM, Robin Murphy wrote: > >>> >>> Thank you, it explains, why "apb_pclk" is required for all PrimeCell >>> controllers on the SoC. Nevertheless, in commit 93898eb775e5 it was >>> misidentified with the sspclk clock, the latter one is the only clock >>> explicitly utilized by the driver in 2015 and till today. Fixes in dts >>> files should be preceded by a fix in the driver. >> >> There's nothing to fix in the driver, though. In fact it can only be >> working today because the Linux driver isn't very strict and simply >> assumes that the first clock entry is SSPCLK *without* considering its >> name (other consumers of the binding might be stricter; I don't know), >> and because presumably the HCLK happens to be enabled already anyway. >> Changing the driver behaviour would only stand to cause functional >> regressions. > > We can change the driver to look for an sspclk by name first, and > then fall back to the first clk if none is found. This would be backwards > compatible and allow new dts files to have an arbitrary order, though > we still need to be careful about changing the existing dts files after > that, to avoid breaking older kernels. Yeah, I discounted that since schema is strict about the order of entries even when they're named, so we'd have nothing to gain except the potential to break compatibility in one direction and annoy users in the other. There's little point in having code to look up a clock by name when we know that for compatibility reasons it has to be the first clock, so it would be functionally identical to the fallback code that we also still have to have. All it could offer is additionally printing a message about it, and experience says that that achieves little except the aforementioned annoyance of users - I look as far as my Rockchip boards that have all been screaming an error at me every boot for nearly 4 years now, where the ethernet driver fails to get a clock that only exists on some SoCs *other* than the ones I have :( Robin. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel