mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Linux Kernel List <linux-kernel@vger.kernel.org>,
	Linux PCI mailing list <linux-pci@atrey.karlin.mff.cuni.cz>,
	Greg KH <greg@kroah.com>
Subject: /sys/bus/pci/drivers/<driver>/new_id
Date: Wed, 29 Nov 2006 21:18:04 +0000	[thread overview]
Message-ID: <20061129211803.GB15186@flint.arm.linux.org.uk> (raw)

Unfortunately, the .../new_id feature does not work with the 8250_pci
driver.

The reason for this comes down to the way .../new_id is implemented.
When PCI tries to match a driver to a device, it checks the modules
static device ID tables _before_ checking the dynamic new_id tables.

When a driver is capable of matching by ID, and falls back to matching
by class (as 8250_pci does), this makes it absolutely impossible to
specify a board by ID, and as such the correct driver_data value to
use with it.

Let's say you have a serial board with vendor 0x1234 and device 0x5678.
It's class is set to PCI_CLASS_COMMUNICATION_SERIAL.

On boot, this card is matched to the 8250_pci driver, which tries to
probe it because it matched using the class entry.  The driver finds
that it is unable to automatically detect the correct settings to use,
so it returns -ENODEV.

You know that the information the driver needs is to match this card
using a device_data value of '7'.  So you echo 1234 5678 0 0 0 0 7
into new_id.

The kernel attempts to re-bind 8250_pci to this device.  However,
because it scans the PCI driver tables, it _again_ matches the class
entry which has the wrong device_data.  It fails.

End of story.  You can't support the card without rebuilding the
kernel (or writing a specific PCI probe module to support it.)

So, can we make new_id override the driver-internal PCI ID tables?
IOW, like this:

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 194f1d2..dc0bca9 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -165,10 +165,6 @@ const struct pci_device_id *pci_match_de
 	const struct pci_device_id *id;
 	struct pci_dynid *dynid;
 
-	id = pci_match_id(drv->id_table, dev);
-	if (id)
-		return id;
-
 	/* static ids didn't match, lets look at the dynamic ones */
 	spin_lock(&drv->dynids.lock);
 	list_for_each_entry(dynid, &drv->dynids.list, node) {
@@ -178,7 +174,8 @@ const struct pci_device_id *pci_match_de
 		}
 	}
 	spin_unlock(&drv->dynids.lock);
-	return NULL;
+
+	return pci_match_id(drv->id_table, dev);
 }
 
 static int pci_call_probe(struct pci_driver *drv, struct pci_dev *dev,


-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

             reply	other threads:[~2006-11-29 21:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-29 21:18 Russell King [this message]
2006-12-04 22:58 ` /sys/bus/pci/drivers/<driver>/new_id Greg KH

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=20061129211803.GB15186@flint.arm.linux.org.uk \
    --to=rmk+lkml@arm.linux.org.uk \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    /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

all inboxes | Powered by JetHome®