linux-kernel - Re: [PATCH] ARM: dts: aspeed: Add ASRock ROMED8HM3 BMC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACPK8XfGdTvznj90C7XFJ04QVU96NdwfXQX_Rj+bkCnov1Urpg@mail.gmail.com>
Date:   Mon, 28 Feb 2022 05:00:17 +0000
From:   Joel Stanley <joel@....id.au>
To:     Zev Weiss <zev@...ilderbeest.net>
Cc:     Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        linux-aspeed <linux-aspeed@...ts.ozlabs.org>,
        OpenBMC Maillist <openbmc@...ts.ozlabs.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        devicetree <devicetree@...r.kernel.org>,
        Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
        Rob Herring <robh+dt@...nel.org>,
        Andrew Jeffery <andrew@...id.au>,
        Neil Horman <neil.horman@...vafy.com>,
        Anthony Jenkins <anthony.jenkins@...vafy.com>
Subject: Re: [PATCH] ARM: dts: aspeed: Add ASRock ROMED8HM3 BMC

On Wed, 12 Jan 2022 at 01:14, Zev Weiss <zev@...ilderbeest.net> wrote:
>
> On Tue, Jan 11, 2022 at 02:59:28AM PST, Joel Stanley wrote:
> >On Wed, 5 Jan 2022 at 23:10, Zev Weiss <zev@...ilderbeest.net> wrote:
> >>
> >> This is a half-width, single-socket Epyc server board with an AST2500
> >> BMC.  This device tree is sufficient for basic OpenBMC functionality,
> >> but we'll need to add a few more devices (as driver support becomes
> >> available) before it's fully usable.
> >>
> >> Signed-off-by: Zev Weiss <zev@...ilderbeest.net>
> >
> >Reviewed-by: Joel Stanley <joel@....id.au>
> >
>
> Thanks!

I've merged this for v5.18.

>
> >Have you considered using the openbmc gpio naming scheme for the
> >gpio-line-names?
> >
>
> I looked at it, but decided not to for a few reasons:
>
>   - For systems that are in the early stages of a porting effort (like
>     this one currently is), I'm still referring to hardware schematics
>     fairly often, and using the same identifiers in software that are
>     used in the schematics simplifies things by avoiding an extra
>     translation step between the two.
>
>   - Most of the GPIO-related userspace components (that I'm dealing with
>     anyway, e.g. x86-power-control and host-error-monitor) already have
>     their own GPIO line-name configuration/remapping mechanisms that need
>     to be set up anyway.
>
>   - There's a solid mix of GPIOs that would be covered by the naming
>     guidelines and others that aren't; having a mix of the two styles
>     seems a bit awkward to me.
>
> That said, I sympathize with the motivation behind it and I'm not
> vehemently opposed on the whole, so if there's a strong preference to
> follow that scheme I could probably be talked into changing it.
>
>
> Zev
>