linux-kernel - Re: [PATCH 2/5] dt-bindings: soc: hpe: hpe,gxp-srom.yaml

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 16 Jan 2023 16:18:59 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Clay Chang" <clayc@....com>
Cc:     "Krzysztof Kozlowski" <krzysztof.kozlowski@...aro.org>,
        linux-kernel@...r.kernel.org, soc@...nel.org,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        "Verdun, Jean-Marie" <verdun@....com>,
        "Hawkins, Nick" <nick.hawkins@....com>,
        "Rob Herring" <robh+dt@...nel.org>,
        krzysztof.kozlowski+dt@...aro.org,
        "Russell King" <linux@...linux.org.uk>,
        "Olof Johansson" <olof@...om.net>
Subject: Re: [PATCH 2/5] dt-bindings: soc: hpe: hpe,gxp-srom.yaml

On Mon, Jan 16, 2023, at 14:42, Clay Chang wrote:
> On Thu, Jan 12, 2023 at 02:37:53PM +0100, Arnd Bergmann wrote:
>> On Thu, Jan 12, 2023, at 14:16, Clay Chang wrote:
>> For the user interface side, I don't really like the idea of
>> having a hardware register directly exposed as driver in
>> drivers/soc, this generally makes it impossible to have portable
>> userspace that works across implementations of multiple SoC
>> vendors, and it makes it too easy to come up with an ad-hoc
>> interface to make a chip work for a particular use case when
>> a more general solution would be better.
>> 
>
> I agree with you. I have one question though: if we create a 'hpe'
> directory under drivers/soc, and put all HPE BMC specific drivers there,
> do you think this proper?

It certainly wouldn't be right to put "all HPE BMC specific drivers"
in there. Most drivers will fit into some existing subsystem, and
should be moved there instead. drivers/soc is used primarily for
drivers using soc_device_register() to provide information about the
soc, and we also use it as a place for drivers that just export
soc-specific helper functions that can be used by other drivers.

>> Again, it's hard for me to tell why this even needs to be runtime
>> configurable, please try to describe what type of application
>> would access the sysfs interface here, and why this can't just
>> be set to a fixed value by bootloader or kernel without user
>> interaction.
>
> The register is used for communication and synchronization between the
> BMC and the host. During runtime, user-space daemons configures the
> value of the register for interactions.

That does not sound very specific. What is the subsystem on the
host that this communicates with? Can you put the driver into the
same subsystem?

    Arnd