linux-kernel - Re: [PATCH 0/5] ARM: Add GXP SROM Support

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] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 02 Feb 2023 11:42:49 +1030
From:   "Andrew Jeffery" <andrew@...id.au>
To:     clayc <clayc@....com>
Cc:     linux-kernel@...r.kernel.org, soc@...nel.org,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        verdun@....com, nick.hawkins@....com,
        "Arnd Bergmann" <arnd@...db.de>,
        "Rob Herring" <robh+dt@...nel.org>,
        "Krzysztof Kozlowski" <krzysztof.kozlowski+dt@...aro.org>,
        "Russell King" <linux@...linux.org.uk>,
        "Olof Johansson" <olof@...om.net>
Subject: Re: [PATCH 0/5] ARM: Add GXP SROM Support



On Wed, 1 Feb 2023, at 23:58, Clay Chang wrote:
> Hi Andrew,
>
> On Tue, Jan 31, 2023 at 09:46:42PM +0800, Clay Chang wrote:
>> > I'm trying to understand whether we can find some common ground with
>> > controlling e.g. Aspeed's BMCs LPC peripherals based on Arnd's query[1],
>> > but the description is a bit too vague right now for me to be able to do
>> > that.
>> > 
>> > [1] https://lore.kernel.org/all/66ef9643-b47e-428d-892d-7c1cbd358a5d@app.fastmail.com/
>> > 
>> > Andrew
>
> I briefly studied driver/soc/aspeed/aspeed-lpc-ctrl.c, and IMO the
> similarity between HPE GXP driver and Aspeed's could be that we both
> expose the LPC memory addresses or registers for configuration purposes.
> However, the functions to be configured could vary. There are a few sets
> of registers that HPE wants to expose for configuration in the future.

The talk of "exposing registers" feels concerning - we're trying not to 
do that directly. Instead we want to lift out an API that constrains 
the behaviour a bit but works for both of us if there's overlap in 
functionality.

Can you point to any documentation of the behaviour of your hardware? 
It's still a little vague to me.

Andrew