On Fri, Apr 4, 2025 at 8:18 AM Rob Herring <robh@xxxxxxxxxx> wrote:
>
> On Fri, Apr 4, 2025 at 7:04 AM Stephan Gerhold
> <stephan.gerhold@xxxxxxxxxx> wrote:
> >
> > On Thu, Apr 03, 2025 at 09:59:27PM -0500, Rob Herring (Arm) wrote:
> > > The "qcom,acc" and "qcom,saw" properties aren't valid with "spin-table"
> > > enable-method nor are they used on 64-bit kernels, so they can be
> > > dropped.
> > >
> >
> > The bootloader we currently use on these devices reads these properties
> > to set up the spin-table, so removing these will break booting secondary
> > CPU cores.
> >
> > The motivation for implementing it that way was that 32-bit vs 64-bit
> > kernel shouldn't be relevant for the describing the hardware blocks in
> > the device tree. The code in the bootloader is generic and handles
> > different SoCs (e.g. msm8916 with 4 cores and msm8939 with 8 cores, the
> > enable sequences are identical).
> >
> > Can we keep this in somehow? To be fair, I'm not sure what property we
> > could match on to check if these properties are allowed ...
>
> Yes, we can keep them. We'll have to allow them with "spin-table" and
> "psci" I guess.
I came up with something like this instead:
- if:
# 2 Qualcomm platforms bootloaders need qcom,acc and qcom,saw yet use
# "spin-table" or "psci" enable-methods. Disallowing the properties for
# all other CPUs is the best we can do as there's not any way to
# distinguish these Qualcomm platforms.
properties:
compatible:
not:
const: arm,cortex-a53
then:
properties:
qcom,acc: false
qcom,saw: false
Not ideal as there are lots of A53s, but better than enabling for
every 64-bit platform.
Also, is adding the cpu-release-addr fine? It could trip up a
bootloader tests if the property is already present and doesn't update
it in that case.
Rob
