Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220311093800.18778-1-singh.kuldeep87k@gmail.com>
 <20220311093800.18778-4-singh.kuldeep87k@gmail.com> <4aae560d-d266-d0d0-136f-32891b15bc01@mleia.com>
 <CAK8P3a3a_WXbDKN-jJUt_Wuvop0rfaUs4ytwyhogOxdtJAPx0w@mail.gmail.com>
 <4f39f086-1932-1729-8761-d5c533356812@mleia.com> <dc599cae-7245-73dc-8050-14ec6c1336b8@arm.com>
 <f497fb65-3568-cda2-f086-2275b50daf4b@mleia.com> <faea4c0c-e20b-c043-6f74-95af8177e8bd@arm.com>
In-Reply-To: <faea4c0c-e20b-c043-6f74-95af8177e8bd@arm.com>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Mon, 14 Mar 2022 13:32:24 +0100
Message-ID: <CAK8P3a1KLHwABtXwu-8Kg-GyKbETz1uRhdCz5edELOGG7JdaMg@mail.gmail.com>
Subject: Re: [PATCH v2 3/3] ARM: dts: lpc32xx: Update spi clock properties
To:     Robin Murphy <robin.murphy@arm.com>
Cc:     Vladimir Zapolskiy <vz@mleia.com>, Arnd Bergmann <arnd@arndb.de>,
        Kuldeep Singh <singh.kuldeep87k@gmail.com>,
        Olof Johansson <olof@lixom.net>, SoC Team <soc@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        DTML <devicetree@vger.kernel.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Mon, Mar 14, 2022 at 1:20 PM Robin Murphy <robin.murphy@arm.com> 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.

       Arnd