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;
Date:   Mon, 13 Jun 2022 12:17:29 +0100
From:   Andre Przywara <andre.przywara@arm.com>
To:     Samuel Holland <samuel@sholland.org>
Cc:     Jernej =?UTF-8?B?xaBrcmFiZWM=?= <jernej.skrabec@gmail.com>,
        Chen-Yu Tsai <wens@csie.org>,
        Russell King <linux@armlinux.org.uk>,
        Bartosz Dudziak <bartosz.dudziak@snejp.pl>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
        Luca Weiss <luca@z3ntu.xyz>, Maxime Ripard <maxime@cerno.tech>,
        Rob Herring <robh+dt@kernel.org>,
        Robin Murphy <robin.murphy@arm.com>,
        Stephan Gerhold <stephan@gerhold.net>,
        Thierry Reding <treding@nvidia.com>,
        Vinod Koul <vkoul@kernel.org>, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-sunxi@lists.linux.dev
Subject: Re: [PATCH 0/3] ARM: sunxi: Remove A31 and A23/A33 platform SMP
 code
Message-ID: <20220613121729.46233a75@donnerap.cambridge.arm.com>
In-Reply-To: <2833034.e9J7NaK4W3@kista>
References: <20220531045038.42230-1-samuel@sholland.org>
        <2833034.e9J7NaK4W3@kista>
Organization: ARM
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Sun, 12 Jun 2022 23:09:07 +0200
Jernej Škrabec <jernej.skrabec@gmail.com> wrote:

Hi Samuel,

> Dne torek, 31. maj 2022 ob 06:50:35 CEST je Samuel Holland napisal(a):
> > This series is preparation for converting the PRCM MFD and legacy clock
> > drivers to a CCU clock driver.

May I ask what the purpose of this exercise is? So if I understand
correctly, then it's about to convert the sun8i-a23-prcm MFD driver and
its children to a single "modern style" CCU clock driver, with its opaque
DT node?
If that changes the compatible strings or the references to the clock
providers (and I guess it would need to?), then this would mean an
incompatible change. Which also means we would need to keep the old code
around, to maintain compatibility with "old" DTs? So what is the win then?
Now we have *two* clock drivers, for the same device, which need
maintenance and testing.

So can you confirm that this will be a breaking change?

> The platform SMP code references the PRCM
> > node to map its MMIO space, which will break when the PRCM node is
> > removed/replaced.  
> 
> Why can't we just leave old platform code? If older dtb file is used, it would 
> still work. Actually, isn't trivial to support new CCU binding too, just by 
> including new CCU compatible string? IIUC new CCU node will have same address 
> as current PRCM node.

This aims for a similar direction, though in this case the alternative
(PSCI) predates the sunxi specific method in the kernel support. Can we
just deprecate this code, maybe issue a warning, with the hint to update
the bootloader (which might not be possible for some devices)?

Cheers,
Andre

> Best regards,
> Jernej
> 
> > 
> > Since PSCI has been available for 7+ years, instead of trying to deal
> > with the migration, I think it's safe to just delete this code.
> > 
> > 
> > Samuel Holland (3):
> >   ARM: sunxi: Remove A31 and A23/A33 platform SMP code
> >   ARM: dts: sunxi: Remove obsolete CPU enable methods
> >   dt-bindings: arm: Remove obsolete CPU enable methods
> > 
> >  .../devicetree/bindings/arm/cpus.yaml         |   2 -
> >  arch/arm/boot/dts/sun6i-a31.dtsi              |   1 -
> >  arch/arm/boot/dts/sun8i-a23-a33.dtsi          |   1 -
> >  arch/arm/mach-sunxi/Makefile                  |   1 -
> >  arch/arm/mach-sunxi/platsmp.c                 | 194 ------------------
> >  5 files changed, 199 deletions(-)
> >  delete mode 100644 arch/arm/mach-sunxi/platsmp.c
> > 
> > -- 
> > 2.35.1
> > 
> >   
> 
> 
>