[PATCH 1/2] ARM: dts: aspeed: catalina: update pdb board cpld ioexp linename
Andrew Jeffery
andrew at codeconstruct.com.au
Thu Nov 7 15:37:31 PST 2024
On Thu, 2024-11-07 at 19:22 +0800, Potin Lai wrote:
> On Thu, Nov 7, 2024 at 7:41 AM Andrew Jeffery
> <andrew at codeconstruct.com.au> wrote:
> >
> > On Wed, 2024-11-06 at 16:58 +0800, Potin Lai wrote:
> > > Update the GPIO linename of each PDB CPLD IO expander based on
> > > latest
> > > CPLD firmware.
> >
> > What version is the latest CPLD firmware? What was the previous
> > version
> > with the old pin assignments?
>
> Because the hardware changes from EVT to DVT, the CPLD firmware
> reallocated the IOEXP pin mapping in DVT version.
> I will add more description into the commit message in the next
> version.
If you have different revisions of the board, it would seem sensible to
have separate devicetrees, one for each, rather than constantly
evolving one devicetree? Tack on an `-evt`/`-dvt` suffix as required?
>From there you can always have a suffix-less dts file that #includes
the most recent board revision. See some of the Aspeed EVB devicetrees
for an example.
>
> >
> > I'm also interested in some discussion of the coordination between
> > CPLD
> > firmware, the devicetree and the BMC userspace configuration. This
> > change feels pretty painful.
>
> I am not from the CPLD firmware team,
I don't see why you need to be? This is a cross-component concern, and
you need to make all the pieces of the puzzle line up.
> I only know our CPLD team was
> redesigning the entire struct which causes the huge changes of IOEXP
> pins.
>
> This is probably a different topic, I am curious about is it possible
> to assign the linename in userspace?
> In OpenBMC, there are many services that depend on GPIO linename, it
> will be more flexible if I can assign the linename before service
> starts.
Not that I'm aware, and to determine otherwise I'd probably need to
read the implementation as much as you :)
However, separating the devicetrees would go a long way here if the
CPLD firmware is tied to the board revision...
Andrew
More information about the linux-arm-kernel
mailing list