From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: "Verdun, Jean-Marie" <verdun@hpe.com>,
"Hawkins, Nick" <nick.hawkins@hpe.com>
Cc: "krzysztof.kozlowski+dt@linaro.org"
<krzysztof.kozlowski+dt@linaro.org>,
"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH v1 2/5] dt-bindings: soc: hpe: Add hpe,gxp-plreg
Date: Tue, 25 Oct 2022 15:48:35 -0400 [thread overview]
Message-ID: <8a4048d4-2675-96ed-89f1-db77084d18ba@linaro.org> (raw)
In-Reply-To: <DM4PR84MB197662C12018090C312AF72DD6319@DM4PR84MB1976.NAMPRD84.PROD.OUTLOOK.COM>
On 25/10/2022 15:39, Verdun, Jean-Marie wrote:
> Hi Krzysztof,
>
Use mailing list style of replying. I can bear the lack of wrapping (one
huge sentence), but top-post is a no.
> I think what we try to do is to introduce an abstraction layer between the interfaces and the drivers, as our CPLD interfaces are platform dependents. I mean the Power On control could be at address 0x09 on one platform or 0x119 on another one. We would like to find a way to avoid to have to change the driver code, but just feeding the driver with relevant datas, which could be into a platform dependent include file or through the proposed solution that Nick is promoting.
I think this was already said. Repeating it, with very similar words
will not help us...
Let me be then clear: I care little about your goal of abstracting some
driver code. I care about proper Devicetree bindings and proper
representation of hardware in Devicetree sources.
Looks like you want to hack around Devicetree to match your needs. This
does not work. I gave you the proposed solution based on my feeling and
limited understanding of what you have there. If this does not work for
you, then life - you need to find other solution.
>
> If the CPLD memory address space was consistent between platform and generation that would be great but unfortunately that is not the case that is why we try to break down the dependency into the driver code and retrieve the data from another place.
I don't see how this argument is relevant to my questions. I did not
propose anything which would require some "memory address space
consistency".
Best regards,
Krzysztof
_______________________________________________
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:[~2022-10-25 19:49 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-11 18:55 [PATCH v1 0/5] Add PLREG and SPI Driver GXP Support nick.hawkins
2022-10-11 18:55 ` [PATCH v1 1/5] soc: hpe: add support for HPE GXP Programmable Register Driver nick.hawkins
2022-10-11 20:05 ` Krzysztof Kozlowski
2022-10-12 20:25 ` Hawkins, Nick
2022-10-13 12:27 ` Krzysztof Kozlowski
2022-10-11 18:55 ` [PATCH v1 2/5] dt-bindings: soc: hpe: Add hpe,gxp-plreg nick.hawkins
2022-10-11 19:51 ` Krzysztof Kozlowski
2022-10-11 20:27 ` Rob Herring
2022-10-12 19:56 ` Hawkins, Nick
2022-10-22 15:52 ` Krzysztof Kozlowski
2022-10-25 0:03 ` Hawkins, Nick
2022-10-25 0:15 ` Krzysztof Kozlowski
2022-10-25 18:44 ` Hawkins, Nick
2022-10-25 18:55 ` Krzysztof Kozlowski
2022-10-25 19:26 ` Hawkins, Nick
2022-10-25 19:33 ` Krzysztof Kozlowski
[not found] ` <DM4PR84MB197662C12018090C312AF72DD6319@DM4PR84MB1976.NAMPRD84.PROD.OUTLOOK.COM>
2022-10-25 19:48 ` Krzysztof Kozlowski [this message]
2022-10-25 19:49 ` Krzysztof Kozlowski
2022-10-11 18:55 ` [PATCH v1 3/5] ARM: dts: hpe: Add PLREG/SPI Support nick.hawkins
2022-10-11 19:53 ` Krzysztof Kozlowski
2022-10-11 18:55 ` [PATCH v1 4/5] ARM: multi_v7_defconfig: Enable GXP SPI and PLREG Drivers nick.hawkins
2022-10-11 19:54 ` Krzysztof Kozlowski
2022-10-11 18:55 ` [PATCH v1 5/5] MAINTAINERS: Add HPE SOC Drivers nick.hawkins
2022-10-11 20:06 ` Krzysztof Kozlowski
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=8a4048d4-2675-96ed-89f1-db77084d18ba@linaro.org \
--to=krzysztof.kozlowski@linaro.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@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=robh+dt@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).