From: Conor Dooley <conor@kernel.org>
To: Christian Bruel <christian.bruel@foss.st.com>
Cc: vkoul@kernel.org, kishon@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org,
mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
p.zabel@pengutronix.de, linux-phy@lists.infradead.org,
devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, fabrice.gasnier@foss.st.com
Subject: Re: [PATCH v4 1/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings
Date: Fri, 30 Aug 2024 15:55:06 +0100 [thread overview]
Message-ID: <20240830-jumbo-wriggly-39c84108371b@spud> (raw)
In-Reply-To: <777a92d9-ed52-4fa1-b235-e3a4a6321634@foss.st.com>
[-- Attachment #1: Type: text/plain, Size: 2694 bytes --]
On Fri, Aug 30, 2024 at 02:53:15PM +0200, Christian Bruel wrote:
>
> On 8/29/24 18:44, Conor Dooley wrote:
> > On Thu, Aug 29, 2024 at 01:06:53PM +0200, Christian Bruel wrote:
> > > On 8/28/24 18:11, Conor Dooley wrote:
> > > > On Wed, Aug 28, 2024 at 04:34:48PM +0200, Christian Bruel wrote:
> > > > > + st,syscfg:
> > > > > + $ref: /schemas/types.yaml#/definitions/phandle
> > > > > + description: Phandle to the SYSCON entry required for configuring PCIe
> > > > > + or USB3.
> > > > Why is a phandle required for this lookup, rather than doing it by
> > > > compatible?
> > > the phandle is used to select the sysconf SoC configuration register
> > > depending on the PCIe/USB3 mode (selected by xlate function), so it's not
> > > like a lookup here.
> > If "syscon_regmap_lookup_by_phandle()" is not a lookup, then I do not
> > know what is. An example justification for it would be that there are
> > multiple combophys on the same soc, each using a different sysconf
> > region. Your dts suggests that is not the case though, since you have
> > st,syscfg = <&syscfg>; in it, rather than st,syscfg = <&syscfg0>;.
>
> I didn't get your suggestion earlier to use "syscon_regmap_lookup_by_compatible()".
>
> We have several other syscon in the other. That's why we choose a direct syscfg phandle
In the other what? SoCs?
Way I see it, if you're going to support different socs in the same
driver, it's almost a certainty that the offsets within a syscon that
particular features lie at are going to change between socs, so even if
you have a phandle you're going to need to have the offsets in your
match data. And if you're going to have offsets in match data, you may
as well have the compatibles for the syscon in match data too.
If the layout of the syscon hasn't changed between devices, then you
should have a fallback compatible for the syscon too, making
syscon_regmap_lookup_by_compatible() function without changes to the
driver.
If you do have multiple syscons, but they do different things, they
should have different compatibles, so having multiple syscons doesn't
justify using a property for this either in and of itself. If you have
multiple syscons with the same layout (and therefore the same
compatible) then a phandle makes sense, but if that's the case then you
almost certainly have multiple combophys too! Otherwise, if you have one
syscon, but the controls for more than one combophy are in it, then
having a phandle _with an offset_ makes sense.
If you know there are other SoCs with more than one combo phy, do they
use different syscons, or is the same syscon used for more than one
combophy?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-08-30 14:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-28 14:34 [PATCH v4 0/5] Add STM32MP25 USB3/PCIE COMBOPHY driver Christian Bruel
2024-08-28 14:34 ` [PATCH v4 1/5] dt-bindings: phy: Add STM32MP25 COMBOPHY bindings Christian Bruel
2024-08-28 16:11 ` Conor Dooley
2024-08-29 11:06 ` Christian Bruel
2024-08-29 16:44 ` Conor Dooley
2024-08-30 12:53 ` Christian Bruel
2024-08-30 14:55 ` Conor Dooley [this message]
2024-08-30 17:11 ` Christian Bruel
2024-08-28 14:34 ` [PATCH v4 2/5] phy: stm32: Add support for STM32MP25 COMBOPHY Christian Bruel
2024-08-29 17:39 ` Vinod Koul
2024-09-03 13:02 ` Christian Bruel
2024-08-28 14:34 ` [PATCH v4 3/5] MAINTAINERS: add entry for ST STM32MP25 COMBOPHY driver Christian Bruel
2024-08-28 14:34 ` [PATCH v4 4/5] arm64: dts: st: Add combophy node on stm32mp251 Christian Bruel
2024-08-28 14:34 ` [PATCH v4 5/5] arm64: dts: st: Enable COMBOPHY on the stm32mp257f-ev1 board Christian Bruel
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=20240830-jumbo-wriggly-39c84108371b@spud \
--to=conor@kernel.org \
--cc=alexandre.torgue@foss.st.com \
--cc=christian.bruel@foss.st.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=fabrice.gasnier@foss.st.com \
--cc=kishon@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=vkoul@kernel.org \
/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