From: "Arnd Bergmann" <arnd@arndb.de>
To: "Clay Chang" <clayc@hpe.com>
Cc: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>,
linux-kernel@vger.kernel.org, soc@kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
"Verdun, Jean-Marie" <verdun@hpe.com>,
"Hawkins, Nick" <nick.hawkins@hpe.com>,
"Rob Herring" <robh+dt@kernel.org>,
krzysztof.kozlowski+dt@linaro.org,
"Russell King" <linux@armlinux.org.uk>,
"Olof Johansson" <olof@lixom.net>
Subject: Re: [PATCH 2/5] dt-bindings: soc: hpe: hpe,gxp-srom.yaml
Date: Mon, 16 Jan 2023 16:18:59 +0100 [thread overview]
Message-ID: <55f09599-b553-4429-aa79-ca99ccf95cda@app.fastmail.com> (raw)
In-Reply-To: <Y8VUOENIhe72sqMO@enigma.ccjz.io>
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-01-16 15:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-10 4:25 [PATCH 0/5] ARM: Add GXP SROM Support clayc
2023-01-10 4:25 ` [PATCH 1/5] soc: hpe: Add GXP SROM Control Register Driver clayc
2023-01-10 9:46 ` Krzysztof Kozlowski
2023-01-12 12:46 ` Clay Chang
2023-01-10 4:25 ` [PATCH 2/5] dt-bindings: soc: hpe: hpe,gxp-srom.yaml clayc
2023-01-10 9:49 ` Krzysztof Kozlowski
2023-01-12 13:16 ` Clay Chang
2023-01-12 13:37 ` Arnd Bergmann
2023-01-16 13:42 ` Clay Chang
2023-01-16 15:18 ` Arnd Bergmann [this message]
2023-01-19 7:39 ` Clay Chang
2023-01-19 7:56 ` Arnd Bergmann
2023-01-10 4:25 ` [PATCH 3/5] ARM: dts: hpe: Add SROM Driver clayc
2023-01-10 4:25 ` [PATCH 4/5] ARM: multi_v7_defconfig: Add GXP " clayc
2023-01-10 9:50 ` Krzysztof Kozlowski
2023-01-12 13:17 ` Clay Chang
2023-01-10 4:25 ` [PATCH 5/5] MAINTAINERS: Add maintainer of GXP SROM support clayc
2023-01-10 9:51 ` Krzysztof Kozlowski
2023-01-12 13:18 ` Clay Chang
2023-01-20 2:21 ` [PATCH 0/5] ARM: Add GXP SROM Support Andrew Jeffery
2023-01-31 13:46 ` Clay Chang
2023-02-01 13:28 ` Clay Chang
2023-02-02 1:12 ` Andrew Jeffery
2023-02-02 15:25 ` Clay Chang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55f09599-b553-4429-aa79-ca99ccf95cda@app.fastmail.com \
--to=arnd@arndb.de \
--cc=clayc@hpe.com \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=nick.hawkins@hpe.com \
--cc=olof@lixom.net \
--cc=robh+dt@kernel.org \
--cc=soc@kernel.org \
--cc=verdun@hpe.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).