linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Marek Vasut <marek.vasut@gmail.com>
Cc: linux-pci@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Wolfram Sang <wsa@the-dreams.de>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH V4] PCI: rcar: Add L1 link state fix into data abort hook
Date: Tue, 8 Dec 2020 12:46:27 -0600	[thread overview]
Message-ID: <20201208184627.GA2393103@bjorn-Precision-5520> (raw)
In-Reply-To: <a65139b9-3b06-0562-7b6e-9a438aecff66@gmail.com>

On Tue, Dec 08, 2020 at 07:05:09PM +0100, Marek Vasut wrote:
> On 12/8/20 5:40 PM, Bjorn Helgaas wrote:

> > > +static const struct of_device_id rcar_pcie_abort_handler_of_match[] __initconst = {
> > > +	{ .compatible = "renesas,pcie-r8a7779" },
> > > +	{ .compatible = "renesas,pcie-r8a7790" },
> > > +	{ .compatible = "renesas,pcie-r8a7791" },
> > > +	{ .compatible = "renesas,pcie-rcar-gen2" },
> > > +	{},
> > > +};
> > 
> > Why do we need another copy of these, as opposed to doing something
> > with of_device_get_match_data(), e.g., like brcm_pcie_probe() does?
> 
> This is not a copy, but as subset of SoCs which are affected by this
> problem.

I know it's not a complete copy.  Many systems include flags like
"broken_l1" in their match_data.  Something like this:

  struct rcar_pcie_drvdata {
    int            (*phy_init_fn)(struct rcar_pcie_host *host);
    unsigned int   broken_l1:1;
  };

  static const struct rcar_pcie_drvdata rcar_init_h1_drvdata = {
    .phy_init_fn = rcar_pcie_phy_init_h1,
    .broken_l1 = 1,
  };

  static const struct rcar_pcie_drvdata rcar_init_gen2_drvdata = {
    .phy_init_fn = rcar_pcie_phy_init_gen2,
    .broken_l1 = 1,
  };

  static const struct rcar_pcie_drvdata rcar_init_gen3_drvdata = {
    .phy_init_fn = rcar_pcie_phy_init_gen3,
  };

  static const struct of_device_id rcar_pcie_of_match[] = {
    { .compatible = "renesas,pcie-r8a7779", .data = rcar_init_h1_drvdata },
    { .compatible = "renesas,pcie-r8a7790", .data = rcar_init_gen2_drvdata },
    { .compatible = "renesas,pcie-r8a7791", .data = rcar_init_gen2_drvdata },
    ...

> > > +static int __init rcar_pcie_init(void)
> > > +{
> > > +	if (of_find_matching_node(NULL, rcar_pcie_abort_handler_of_match)) {
> > > +#ifdef CONFIG_ARM_LPAE
> > > +		hook_fault_code(17, rcar_pcie_aarch32_abort_handler, SIGBUS, 0,
> > > +				"asynchronous external abort");
> > > +#else
> > > +		hook_fault_code(22, rcar_pcie_aarch32_abort_handler, SIGBUS, 0,
> > > +				"imprecise external abort");
> > > +#endif
> > > +	}
> > > +
> > > +	return platform_driver_register(&rcar_pcie_driver);
> > > +}
> > > +device_initcall(rcar_pcie_init);
> > > +#else
> > >   builtin_platform_driver(rcar_pcie_driver);
> > > +#endif
> > 
> > Is the device_initcall() vs builtin_platform_driver() something
> > related to the hook_fault_code()?  What would break if this were
> > always builtin_platform_driver()?
> 
> rcar_pcie_init() would not be called before probe.

Sorry to be slow, but why does it need to be called before probe?
Obviously software isn't putting the controller in D3 or enabling ASPM
before probe.

Bjorn

  reply	other threads:[~2020-12-08 20:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-16 12:04 [PATCH V4] PCI: rcar: Add L1 link state fix into data abort hook marek.vasut
2020-10-17 14:03 ` Geert Uytterhoeven
2020-11-19 17:35 ` Lorenzo Pieralisi
2020-11-29 13:05   ` Marek Vasut
2020-12-08 10:18     ` Lorenzo Pieralisi
2020-12-08 17:45       ` Marek Vasut
2020-12-08 17:52         ` Geert Uytterhoeven
2020-12-08 16:40 ` Bjorn Helgaas
2020-12-08 18:05   ` Marek Vasut
2020-12-08 18:46     ` Bjorn Helgaas [this message]
2020-12-10 12:12       ` Lorenzo Pieralisi
2020-12-12 19:12         ` Marek Vasut
2020-12-14 17:13           ` Lorenzo Pieralisi
2020-12-16 17:52             ` Marek Vasut
2020-12-12 19:10       ` Marek Vasut
2020-12-14 20:38     ` Bjorn Helgaas
2020-12-16 17:56       ` Marek Vasut
2020-12-16 18:20         ` Bjorn Helgaas

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=20201208184627.GA2393103@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=geert+renesas@glider.be \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=marek.vasut@gmail.com \
    --cc=wsa@the-dreams.de \
    --cc=yoshihiro.shimoda.uh@renesas.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).