All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: Linux 5.15-rc1
Date: Tue, 14 Sep 2021 16:55:43 -0500	[thread overview]
Message-ID: <20210914215543.GA1437800@bjorn-Precision-5520> (raw)
In-Reply-To: <54bd54b9-3774-92a5-4193-5ccccd235572@gmail.com>

On Tue, Sep 14, 2021 at 07:07:40PM +0200, Heiner Kallweit wrote:
> On 14.09.2021 13:26, Bjorn Helgaas wrote:
> > On Tue, Sep 14, 2021 at 08:21:46AM +0200, Heiner Kallweit wrote:
> >> On 14.09.2021 01:46, Bjorn Helgaas wrote:
> > 
> >>> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, quirk_blacklist_vpd);
> >>>  /*
> >>
> >> Leaving the quirks in FIXUP_HEADER stage would have the advantage that for
> >> blacklisted devices the vpd sysfs attribute isn't visibale. The needed
> >> changes to the patch are minimal.
> > 
> > What do you have in mind?  The only thing I can think of would be to
> > add a "pci_dev.no_vpd" bit.  "vpd.cap == 0" means the device has no
> > VPD, and "vpd.len == 0" means we haven't determined the size yet.  All
> > devices start off with vpd.cap == 0 and vpd.len == 0, so a
> > FIXUP_HEADER quirk would have to set a sentinel value or some other
> > bit.
> 
> Why not leave vpd.len == PCI_VPD_SZ_INVALID as sentinel?

Sentinel values aren't really my favorite thing, but it certainly does
have the advantage of hiding the sysfs attribute.

> And one more question: Why do you move the "if (!vpd->cap)" check from
> pci_vpd_read() to pci_read_vpd()? At a first glance I see no benefit.

I'm pretty sure I *had* a reason, but I can't remember right now :(
Moving it sure does uglify pci_read_vpd() and pci_write_vpd(), though.

What do you think of the following?  (This is a diff from v5.15-rc1.)

diff --git a/drivers/pci/vpd.c b/drivers/pci/vpd.c
index 25557b272a4f..4be24890132e 100644
--- a/drivers/pci/vpd.c
+++ b/drivers/pci/vpd.c
@@ -99,6 +99,24 @@ static size_t pci_vpd_size(struct pci_dev *dev)
 	return off ?: PCI_VPD_SZ_INVALID;
 }
 
+static bool pci_vpd_available(struct pci_dev *dev)
+{
+	struct pci_vpd *vpd = &dev->vpd;
+
+	if (!vpd->cap)
+		return false;
+
+	if (vpd->len == 0) {
+		vpd->len = pci_vpd_size(dev);
+		if (vpd->len == PCI_VPD_SZ_INVALID) {
+			vpd->cap = 0;
+			return false;
+		}
+	}
+
+	return true;
+}
+
 /*
  * Wait for last operation to complete.
  * This code has to spin since there is no other notification from the PCI
@@ -145,7 +163,7 @@ static ssize_t pci_vpd_read(struct pci_dev *dev, loff_t pos, size_t count,
 	loff_t end = pos + count;
 	u8 *buf = arg;
 
-	if (!vpd->cap)
+	if (!pci_vpd_available(dev))
 		return -ENODEV;
 
 	if (pos < 0)
@@ -206,7 +224,7 @@ static ssize_t pci_vpd_write(struct pci_dev *dev, loff_t pos, size_t count,
 	loff_t end = pos + count;
 	int ret = 0;
 
-	if (!vpd->cap)
+	if (!pci_vpd_available(dev))
 		return -ENODEV;
 
 	if (pos < 0 || (pos & 3) || (count & 3))
@@ -242,14 +260,11 @@ static ssize_t pci_vpd_write(struct pci_dev *dev, loff_t pos, size_t count,
 
 void pci_vpd_init(struct pci_dev *dev)
 {
+	if (dev->vpd.len == PCI_VPD_SZ_INVALID)
+		return;
+
 	dev->vpd.cap = pci_find_capability(dev, PCI_CAP_ID_VPD);
 	mutex_init(&dev->vpd.lock);
-
-	if (!dev->vpd.len)
-		dev->vpd.len = pci_vpd_size(dev);
-
-	if (dev->vpd.len == PCI_VPD_SZ_INVALID)
-		dev->vpd.cap = 0;
 }
 
 static ssize_t vpd_read(struct file *filp, struct kobject *kobj,
@@ -294,13 +309,14 @@ const struct attribute_group pci_dev_vpd_attr_group = {
 
 void *pci_vpd_alloc(struct pci_dev *dev, unsigned int *size)
 {
-	unsigned int len = dev->vpd.len;
+	unsigned int len;
 	void *buf;
 	int cnt;
 
-	if (!dev->vpd.cap)
+	if (!pci_vpd_available(dev))
 		return ERR_PTR(-ENODEV);
 
+	len = dev->vpd.len;
 	buf = kmalloc(len, GFP_KERNEL);
 	if (!buf)
 		return ERR_PTR(-ENOMEM);

  reply	other threads:[~2021-09-14 21:55 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-12 23:58 Linux 5.15-rc1 Linus Torvalds
2021-09-13  3:57 ` Guenter Roeck
2021-09-28 23:18   ` Michael S. Tsirkin
2021-09-30 13:44     ` Guenter Roeck
2021-09-13 14:18 ` Dave Jones
2021-09-13 18:59   ` Heiner Kallweit
2021-09-13 19:51     ` Linus Torvalds
2021-09-13 20:09       ` Bjorn Helgaas
2021-09-13 20:11       ` Heiner Kallweit
2021-09-13 20:15         ` Linus Torvalds
2021-09-13 20:15     ` Dave Jones
2021-09-13 20:22       ` Heiner Kallweit
2021-09-13 20:32         ` Dave Jones
2021-09-13 20:44           ` Linux 5.15-rc1 - 82599ES VPD access isue Heiner Kallweit
2021-09-13 20:44             ` [Intel-wired-lan] " Heiner Kallweit
2021-09-13 23:32             ` Hisashi T Fujinaka
2021-09-13 23:32               ` Hisashi T Fujinaka
2021-09-14  5:51               ` Heiner Kallweit
2021-09-14  5:51                 ` Heiner Kallweit
2021-09-14 14:24                 ` Dave Jones
2021-09-14 14:24                   ` Dave Jones
2021-09-14 18:28                   ` Fujinaka, Todd
2021-09-14 18:28                     ` Fujinaka, Todd
2021-09-14 20:00                   ` Hisashi T Fujinaka
2021-09-14 20:00                     ` Hisashi T Fujinaka
2021-09-14 21:51                     ` Heiner Kallweit
2021-09-14 21:51                       ` Heiner Kallweit
2021-09-15 14:18                       ` Hisashi T Fujinaka
2021-09-15 14:18                         ` Hisashi T Fujinaka
2021-09-15 16:05                         ` Heiner Kallweit
2021-09-15 16:05                           ` Heiner Kallweit
2021-09-15 16:16                           ` Hisashi T Fujinaka
2021-09-15 16:16                             ` Hisashi T Fujinaka
2021-09-15 22:32                             ` Bjorn Helgaas
2021-09-15 22:32                               ` Bjorn Helgaas
2021-09-15 23:46                               ` Hisashi T Fujinaka
2021-09-15 23:46                                 ` Hisashi T Fujinaka
2021-09-17 15:09                                 ` Bjorn Helgaas
2021-09-17 15:09                                   ` Bjorn Helgaas
2021-09-13 20:59           ` Linux 5.15-rc1 Heiner Kallweit
2021-09-13 23:35             ` Bjorn Helgaas
2021-09-13 20:32       ` Heiner Kallweit
2021-09-13 20:36         ` Linus Torvalds
2021-09-13 20:41         ` Dave Jones
2021-09-13 23:46   ` Bjorn Helgaas
2021-09-14  0:39     ` Dave Jones
2021-09-14  6:21     ` Heiner Kallweit
2021-09-14 11:26       ` Bjorn Helgaas
2021-09-14 17:07         ` Heiner Kallweit
2021-09-14 21:55           ` Bjorn Helgaas [this message]
2021-09-14 22:06             ` Heiner Kallweit
2021-09-14 22:33               ` Dave Jones
2021-09-15 21:31                 ` 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=20210914215543.GA1437800@bjorn-Precision-5520 \
    --to=helgaas@kernel.org \
    --cc=davej@codemonkey.org.uk \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.