linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	linux-acpi@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/4] x86/pci: Re-use new dmi_get_bios_year() helper
Date: Mon, 26 Feb 2018 17:28:32 +0100	[thread overview]
Message-ID: <20180226172832.7bf82336@endymion> (raw)
In-Reply-To: <20180222125923.57385-2-andriy.shevchenko@linux.intel.com>

Hi Andy,

On Thu, 22 Feb 2018 14:59:21 +0200, Andy Shevchenko wrote:
> ...instead of open coding its functionality.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  arch/x86/pci/acpi.c            | 8 ++------
>  arch/x86/pci/direct.c          | 5 ++---
>  arch/x86/pci/mmconfig-shared.c | 9 ++-------
>  3 files changed, 6 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 7df49c40665e..00e60de30328 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -140,12 +140,8 @@ static const struct dmi_system_id pci_crs_quirks[] __initconst = {
>  
>  void __init pci_acpi_crs_quirks(void)
>  {
> -	int year;
> -
> -	if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) && year < 2008) {
> -		if (iomem_resource.end <= 0xffffffff)
> -			pci_use_crs = false;
> -	}
> +	if ((dmi_get_bios_year() < 2008) && (iomem_resource.end <= 0xffffffff))
> +		pci_use_crs = false;

You are changing the behavior here, when DMI does not provide a BIOS
date. Beforehand, the test would fail and pci_use_crs would be left
alone. After your change, dmi_get_bios_year() will return 0, and
"0 < 2008" is true, so pci_use_crs is set to false.

I have no opinion on what this driver should do in such case, but I
certainly wouldn't expect a change of behavior from a "use a helper
instead of open-coding" kind of patch.

I don't think you can safely assume that the code calling
dmi_get_bios_year() will always do the right thing when 0 is being
returned. It's up to the calling code to decide what the default
behavior should be.

Also there are more parentheses than needed.

>  
>  	dmi_check_system(pci_crs_quirks);
>  
> diff --git a/arch/x86/pci/direct.c b/arch/x86/pci/direct.c
> index 2d9503323d10..a51074c55982 100644
> --- a/arch/x86/pci/direct.c
> +++ b/arch/x86/pci/direct.c
> @@ -195,14 +195,13 @@ static const struct pci_raw_ops pci_direct_conf2 = {
>  static int __init pci_sanity_check(const struct pci_raw_ops *o)
>  {
>  	u32 x = 0;
> -	int year, devfn;
> +	int devfn;
>  
>  	if (pci_probe & PCI_NO_CHECKS)
>  		return 1;
>  	/* Assume Type 1 works for newer systems.
>  	   This handles machines that don't have anything on PCI Bus 0. */
> -	dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL);
> -	if (year >= 2001)
> +	if (dmi_get_bios_year() >= 2001)
>  		return 1;
>  
>  	for (devfn = 0; devfn < 0x100; devfn++) {
> diff --git a/arch/x86/pci/mmconfig-shared.c b/arch/x86/pci/mmconfig-shared.c
> index 96684d0adcf9..0b40482578b8 100644
> --- a/arch/x86/pci/mmconfig-shared.c
> +++ b/arch/x86/pci/mmconfig-shared.c
> @@ -547,19 +547,14 @@ static void __init pci_mmcfg_reject_broken(int early)
>  static int __init acpi_mcfg_check_entry(struct acpi_table_mcfg *mcfg,
>  					struct acpi_mcfg_allocation *cfg)
>  {
> -	int year;
> -
>  	if (cfg->address < 0xFFFFFFFF)
>  		return 0;
>  
>  	if (!strncmp(mcfg->header.oem_id, "SGI", 3))
>  		return 0;
>  
> -	if (mcfg->header.revision >= 1) {
> -		if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) &&
> -		    year >= 2010)
> -			return 0;
> -	}
> +	if ((mcfg->header.revision >= 1) && (dmi_get_bios_year() >= 2010))
> +		return 0;

Here too some parentheses are not needed.

>  
>  	pr_err(PREFIX "MCFG region for %04x [bus %02x-%02x] at %#llx "
>  	       "is above 4GB, ignored\n", cfg->pci_segment,


-- 
Jean Delvare
SUSE L3 Support

  parent reply	other threads:[~2018-02-26 16:28 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-22 12:59 [PATCH v1 1/4] dmi: Introduce dmi_get_bios_year() helper Andy Shevchenko
2018-02-22 12:59 ` [PATCH v1 2/4] x86/pci: Re-use new " Andy Shevchenko
2018-02-23 21:39   ` Bjorn Helgaas
2018-02-26 16:28   ` Jean Delvare [this message]
2018-02-28 10:29     ` Andy Shevchenko
2018-02-28 10:33       ` Rafael J. Wysocki
2018-02-28 19:21         ` Jean Delvare
2018-02-28 19:34           ` Andy Shevchenko
2018-02-22 12:59 ` [PATCH v1 3/4] ACPI / sleep: " Andy Shevchenko
2018-02-26 16:31   ` Jean Delvare
2018-02-22 12:59 ` [PATCH v1 4/4] pci: " Andy Shevchenko
2018-02-23 21:40   ` Bjorn Helgaas
2018-02-25 13:27     ` Andy Shevchenko
2018-02-26 18:19       ` Bjorn Helgaas
2018-02-28 10:12         ` Andy Shevchenko
2018-02-28 15:17           ` Bjorn Helgaas
2018-02-26 20:40   ` Jean Delvare
2018-02-23 21:35 ` [PATCH v1 1/4] dmi: Introduce " Bjorn Helgaas
2018-02-25 13:23   ` Andy Shevchenko
2018-02-26  9:29     ` Rafael J. Wysocki
2018-02-28 10:14       ` Andy Shevchenko
2018-02-27  9:14 ` Jean Delvare
2018-02-28 10:33   ` Andy Shevchenko

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=20180226172832.7bf82336@endymion \
    --to=jdelvare@suse.de \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=hpa@zytor.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=x86@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;
as well as URLs for NNTP newsgroup(s).