Re: [PATCH] mmc: sdhci-pci: Remove D3 delays for Intel BYT-related host controllers

From: Bjorn Helgaas <helgaas@kernel.org>
To: Alan Cox <alan@linux.intel.com>
Cc: "Hunter, Adrian" <adrian.hunter@intel.com>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	linux-pci <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <bhelgaas@google.com>,
	linux-acpi <linux-acpi@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>
Subject: Re: [PATCH] mmc: sdhci-pci: Remove D3 delays for Intel BYT-related host controllers
Date: Tue, 10 Oct 2017 06:03:51 -0500	[thread overview]
Message-ID: <20171010110351.GU25517@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <1507626095.26339.5.camel@linux.intel.com>

On Tue, Oct 10, 2017 at 10:01:35AM +0100, Alan Cox wrote:
> > Your concern was that a quirk would require a long list of device IDs
> > and we'd have to add new ones.  I share that concern,
> 
> I'm not sure I do. The bus topology tells you what is on die, and the
> id of the root bridge tells you if it's one of the parts you can do
> this.

Your a49d25364dfb ("staging/atomisp: Add support for the Intel IPU
v2") added the most generic version (pci_d3_delay_fixup() uses

  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_d3_delay_fixup);

so there's no list of device IDs.  If this is really a property of the
family (BYT/CHT/etc), it makes sense to me to do it that way, but if
you think it's better to have a list, that's OK too.

The more interesting question to me is whether the quirk should be in
an optional driver or in the always-present arch code.  My assumption
is that putting it in the driver means that if the driver isn't
enabled, we're doing unnecessary delays.

Bjorn