All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Alex Elder <elder@riscstar.com>
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
	arnd@arndb.de, gregkh@linuxfoundation.org, bhelgaas@google.com,
	andersson@kernel.org, konradybcio@kernel.org,
	abelvesa@kernel.org, daniel@riscstar.com,
	mohd.anwar@oss.qualcomm.com, lorenzo.bianconi@oss.qualcomm.com,
	devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andrea della Porta <andrea.porta@suse.com>,
	Herve Codina <herve.codina@bootlin.com>,
	Lizhi Hou <lizhi.hou@amd.com>
Subject: Re: [PATCH v4 2/3] misc: tc9564: introduce base PCI driver
Date: Fri, 18 Sep 2026 12:30:03 -0500	[thread overview]
Message-ID: <20260918173003.GA1166280@bhelgaas> (raw)
In-Reply-To: <20260918152659.413268-3-elder@riscstar.com>

[+cc Andrea, Herve, Lizhi for of_pci_make_dev_node() quirks]

On Fri, Sep 18, 2026 at 10:26:57AM -0500, Alex Elder wrote:
> The Toshiba TC9564 is small and highly-specialized SoC that implements
> a PCIe switch as well as an Ethernet AVB/TSN bridge.  In addition to
> these, the SoC implements other functions, including a reset and clock
> controller, an address translation unit, and a few other devices.  PCIe
> BARs provide access to registers that manage these IP blocks, and the
> SoC is modeled using a PCI endpoint bus in devicetree.  This allows the
> IP blocks to be bound to platform drivers that do MMIO via the PCI BARs.
> 
> Create a new PCI driver under drivers/misc that binds with the embedded
> PCI endpoint functions within the TC9564 SoC.  Because these functions
> will use devicetree pci-ep-bus to provide access to other IP blocks
> within the TC9564 chip, the main purpose of this driver is to do basic
> PCI initialization, then call of_platform_default_populate() to scan for
> the any endpoint bus children, and probe all devices defined therein.
> 
> Because we're using pci-ep-bus, we need to use the PCI quirks mechanism
> to have of_pci_make_dev_node() be called for each endpoint device in
> pci_bus_add_device() (via pci_fixup_device(pci_fixup_final, dev)).
> 
> Co-developed-by: Daniel Thompson <daniel@riscstar.com>
> Signed-off-by: Daniel Thompson <daniel@riscstar.com>
> Signed-off-by: Alex Elder <elder@riscstar.com>

Acked-by: Bjorn Helgaas <bhelgaas@google.com>	# quirks.c

Not an issue for this patch, but I'm not sure the quirk mechanism is
the best mechanism for doing this.  It's not working around a device
defect like most quirks do.

I wonder if pci_bus_add_device() should unconditionally call a wrapper 
that calls of_pci_make_dev_node() for bridges and any device that
appears in an allow-list.  I guess it sort of amounts to the same
thing in the end, but it might be a little more explicit and not
subject to CONFIG_PCI_QUIRKS.

> +++ b/drivers/pci/quirks.c
> @@ -6391,6 +6391,7 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_XILINX, 0x5020, of_pci_make_dev_node);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_XILINX, 0x5021, of_pci_make_dev_node);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_REDHAT, 0x0005, of_pci_make_dev_node);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_EFAR, 0x9660, of_pci_make_dev_node);
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_TOSHIBA, 0x0220, of_pci_make_dev_node);
>  
>  /*
>   * Devices known to require a longer delay before first config space access
> -- 
> 2.53.0
> 

  parent reply	other threads:[~2026-09-18 17:30 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-18 15:26 [PATCH v4 0/3] PCI: introduce TC9564 misc driver Alex Elder
2026-09-18 15:26 ` [PATCH v4 1/3] dt-bindings: misc: introduce pci1179,0220.yaml Alex Elder
2026-09-18 15:31   ` sashiko-bot
2026-09-28 19:40   ` Rob Herring (Arm)
2026-09-18 15:26 ` [PATCH v4 2/3] misc: tc9564: introduce base PCI driver Alex Elder
2026-09-18 15:42   ` sashiko-bot
2026-09-18 16:02     ` Alex Elder
2026-09-18 17:30   ` Bjorn Helgaas [this message]
2026-09-18 17:49     ` Alex Elder
2026-09-24 15:56       ` Herve Codina
2026-09-25  2:15         ` Alex Elder
2026-09-18 15:26 ` [PATCH v4 3/3] arm64: dts: qcom: qcs6490-rb3gen2: add endpoint buses Alex Elder
2026-09-18 15:39   ` sashiko-bot
2026-09-18 16:02     ` Alex Elder
2026-10-01 12:06   ` Greg KH
2026-10-01 19:19     ` Alex Elder
2026-10-02  6:16       ` Greg KH

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=20260918173003.GA1166280@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=abelvesa@kernel.org \
    --cc=andersson@kernel.org \
    --cc=andrea.porta@suse.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel@riscstar.com \
    --cc=devicetree@vger.kernel.org \
    --cc=elder@riscstar.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=herve.codina@bootlin.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lizhi.hou@amd.com \
    --cc=lorenzo.bianconi@oss.qualcomm.com \
    --cc=mohd.anwar@oss.qualcomm.com \
    --cc=robh@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.