All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Cc: andrew.murray@arm.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, wangkefeng.wang@huawei.com,
	huawei.libin@huawei.com, guohanjun@huawei.com
Subject: Re: [PATCH v2] PCI: Add quirk for HiSilicon NP 5896 devices
Date: Fri, 6 Dec 2019 12:10:51 -0600	[thread overview]
Message-ID: <20191206181051.GA121021@google.com> (raw)
In-Reply-To: <1575615705-30716-1-git-send-email-wangxiongfeng2@huawei.com>

On Fri, Dec 06, 2019 at 03:01:45PM +0800, Xiongfeng Wang wrote:
> HiSilicon PCI Network Processor 5896 devices misreport the class type as
> 'NOT_DEFINED', but it is actually a network device. Also the size of
> BAR3 is reported as 265T, but this BAR is actually unused.
> This patch modify the class type to 'CLASS_NETWORK' and disable the
> unused BAR3.

"NOT_DEFINED" is not the value in the Class Code register.  The commit
message should include the actual value.

> Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
> ---
>  drivers/pci/quirks.c    | 29 +++++++++++++++++++++++++++++
>  include/linux/pci_ids.h |  1 +
>  2 files changed, 30 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 4937a08..b9adebb 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -5431,3 +5431,32 @@ static void quirk_reset_lenovo_thinkpad_p50_nvgpu(struct pci_dev *pdev)
>  DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, 0x13b1,
>  			      PCI_CLASS_DISPLAY_VGA, 8,
>  			      quirk_reset_lenovo_thinkpad_p50_nvgpu);
> +
> +static void quirk_hisi_fixup_np_class(struct pci_dev *pdev)
> +{
> +	u32 class = pdev->class;
> +
> +	pdev->class = PCI_BASE_CLASS_NETWORK << 8;
> +	pci_info(pdev, "PCI class overriden (%#08x -> %#08x)\n",
> +		 class, pdev->class);
> +}
> +DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HISI_5896,
> +			quirk_hisi_fixup_np_class);
> +
> +/*
> + * HiSilicon NP 5896 devices BAR3 size is reported as 256T and causes problem
> + * when assigning the resources. But this BAR is actually unused by the driver,
> + * so let's disable it.

The question is not whether the BAR is used by the driver; the
question is whether the device responds to accesses to the region
described by the BAR when PCI_COMMAND_MEMORY is turned on.

> + */
> +static void quirk_hisi_fixup_np_bar(struct pci_dev *pdev)
> +{
> +	struct resource *r = &pdev->resource[3];
> +
> +	r->start = 0;
> +	r->end = 0;
> +	r->flags = 0;
> +
> +	pci_info(pdev, "Disabling invalid BAR 3\n");

This quirk clears the Linux *resource* related to the BAR, but it
does nothing with the hardware register itself.  There is no way to
disable an individual BAR; all we have is PCI_COMMAND_MEMORY, which
enables/disables all memory BARs as a group.

If this is a device defect, where the config register at 0x1c *looks*
like a BAR, but it actually isn't a BAR and doesn't cause the device
to decode any address space, a quirk like this might be OK.  But if
the device does decode address space described by that BAR, we need
more than this.

Can you provide "sudo lspci -vvxxx" output for this device?

> +}
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HISI_5896,
> +			 quirk_hisi_fixup_np_bar);
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 2302d133..f21cd8b 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -2558,6 +2558,7 @@
>  #define PCI_DEVICE_ID_KORENIX_JETCARDF3	0x17ff
>  
>  #define PCI_VENDOR_ID_HUAWEI		0x19e5
> +#define PCI_DEVICE_ID_HISI_5896        0x5896 /* HiSilicon NP 5896 devices */
>  
>  #define PCI_VENDOR_ID_NETRONOME		0x19ee
>  #define PCI_DEVICE_ID_NETRONOME_NFP4000	0x4000
> -- 
> 1.7.12.4
> 

  reply	other threads:[~2019-12-06 18:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-06  7:01 [PATCH v2] PCI: Add quirk for HiSilicon NP 5896 devices Xiongfeng Wang
2019-12-06 18:10 ` Bjorn Helgaas [this message]
2019-12-11  3:27   ` Xiongfeng Wang
2019-12-11  4:10     ` Bjorn Helgaas
2019-12-18  9:16       ` Xiongfeng Wang
2019-12-18 14:28         ` Bjorn Helgaas
2019-12-19  8:51           ` Xiongfeng Wang
2019-12-30  8:11           ` Xiongfeng Wang
2019-12-30 14:19             ` Bjorn Helgaas
2019-12-18  8:41 ` Xiongfeng Wang

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=20191206181051.GA121021@google.com \
    --to=helgaas@kernel.org \
    --cc=andrew.murray@arm.com \
    --cc=guohanjun@huawei.com \
    --cc=huawei.libin@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=wangkefeng.wang@huawei.com \
    --cc=wangxiongfeng2@huawei.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 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.