From: Marc Zyngier <maz@kernel.org>
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
asahi@lists.linux.dev, alyssa@rosenzweig.io, j@jannau.net,
marcan@marcan.st, sven@svenpeter.dev, bhelgaas@google.com,
lpieralisi@kernel.org, kw@linux.com,
manivannan.sadhasivam@linaro.org, robh@kernel.org,
krzk+dt@kernel.org
Subject: Re: [PATCH v2 01/13] dt-bindings: pci: apple,pcie: Add t6020 compatible string
Date: Tue, 25 Mar 2025 16:48:53 +0000 [thread overview]
Message-ID: <87a599qcne.wl-maz@kernel.org> (raw)
In-Reply-To: <87ecyl6rtw.fsf@bloch.sibelius.xs4all.nl>
On Tue, 25 Mar 2025 15:41:15 +0000,
Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > Date: Tue, 25 Mar 2025 11:02:30 +0000
> > From: Marc Zyngier <maz@kernel.org>
>
> Hi Marc,
>
> > Hi Mark,
> >
> > On Tue, 25 Mar 2025 10:50:18 +0000,
> > Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > >
> > > > From: Marc Zyngier <maz@kernel.org>
> > > > Date: Tue, 25 Mar 2025 10:25:58 +0000
> > >
> > > > @@ -50,6 +55,10 @@ properties:
> > > > - const: port1
> > > > - const: port2
> > > > - const: port3
> > > > + - const: phy0
> > > > + - const: phy1
> > > > + - const: phy2
> > > > + - const: phy3
> >
> > Do we need to make this t6020 specific?
> >
> > Obviously, separate PHY registers do not make much sense before t6020,
> > but I couldn't find a way to describe that. I don't even know if
> > that's a desirable outcome.
>
> I don't think there is a way to do that other than creating a separate
> binding for t6020. But I'm far from a dt-schema expert. Maybe robh
> has some advice here.
Huh, I'd rather not create another binding. The only thing this would
buy us is a stricter checking of the register ranges. But it isn't
like this block is going to find its way in random HW, and this is
only described in a handful of core dtsi files anyway.
Unless someone screams (and provides a reasonable alternative), I will
leave it as is.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-03-25 16:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-25 10:25 [PATCH v2 00/13] PCI: apple: Add support for t6020 Marc Zyngier
2025-03-25 10:25 ` [PATCH v2 01/13] dt-bindings: pci: apple,pcie: Add t6020 compatible string Marc Zyngier
2025-03-25 10:50 ` Mark Kettenis
2025-03-25 11:02 ` Marc Zyngier
2025-03-25 15:41 ` Mark Kettenis
2025-03-25 16:48 ` Marc Zyngier [this message]
2025-03-26 19:51 ` Rob Herring
2025-03-25 10:25 ` [PATCH v2 02/13] PCI: host-generic: Extract an ecam bridge creation helper from pci_host_common_probe() Marc Zyngier
2025-03-25 10:26 ` [PATCH v2 03/13] PCI: ecam: Allow cfg->priv to be pre-populated from the root port device Marc Zyngier
2025-03-25 10:26 ` [PATCH v2 04/13] PCI: apple: Move over to standalone probing Marc Zyngier
2025-03-25 10:26 ` [PATCH v2 05/13] PCI: apple: Dynamically allocate RID-to_SID bitmap Marc Zyngier
2025-03-25 10:26 ` [PATCH v2 06/13] PCI: apple: Move away from INTMSK{SET,CLR} for INTx and private interrupts Marc Zyngier
2025-03-25 10:26 ` [PATCH v2 07/13] PCI: apple: Fix missing OF node reference in apple_pcie_setup_port Marc Zyngier
2025-03-25 10:26 ` [PATCH v2 08/13] PCI: apple: Set only available ports up Marc Zyngier
2025-03-25 13:25 ` Rob Herring
2025-03-25 10:26 ` [PATCH v2 09/13] PCI: apple: Move port PHY registers to their own reg items Marc Zyngier
2025-03-25 10:26 ` [PATCH v2 10/13] PCI: apple: Drop poll for CORE_RC_PHYIF_STAT_REFCLK Marc Zyngier
2025-03-25 10:26 ` [PATCH v2 11/13] PCI: apple: Use gpiod_set_value_cansleep in probe flow Marc Zyngier
2025-03-25 10:26 ` [PATCH v2 12/13] PCI: apple: Abstract register offsets via a SoC-specific structure Marc Zyngier
2025-03-25 10:26 ` [PATCH v2 13/13] PCI: apple: Add T602x PCIe support Marc Zyngier
2025-03-25 13:31 ` [PATCH v2 00/13] PCI: apple: Add support for t6020 Rob Herring
2025-03-25 14:50 ` Alyssa Rosenzweig
2025-03-31 11:28 ` Janne Grunau
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=87a599qcne.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=alyssa@rosenzweig.io \
--cc=asahi@lists.linux.dev \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=j@jannau.net \
--cc=krzk+dt@kernel.org \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=manivannan.sadhasivam@linaro.org \
--cc=marcan@marcan.st \
--cc=mark.kettenis@xs4all.nl \
--cc=robh@kernel.org \
--cc=sven@svenpeter.dev \
/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).