From: "Mark M. Hoffman" <mhoffman@lightlink.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Adrian Bunk <bunk@stusta.de>,
greg@kroah.com, linux-pci@atrey.karlin.mff.cuni.cz,
linux-kernel@vger.kernel.org
Subject: Re: [-mm patch] drivers/pci/quirks.c: cleanup
Date: Tue, 9 Jan 2007 22:58:20 -0500 [thread overview]
Message-ID: <20070110035820.GB27550@jupiter.solarsys.private> (raw)
In-Reply-To: <20070109141721.b823187c.khali@linux-fr.org>
Hi Jean:
> On Mon, 8 Jan 2007 22:02:26 -0500, Mark M. Hoffman wrote:
> > 3) I've just confirmed that this quirk is still broken on recent FC6 kernels.
> > Perhaps they should have picked my patch out of their bugzilla, but they didn't.
* Jean Delvare <khali@linux-fr.org> [2007-01-09 14:17:21 +0100]:
> I am worried about the Intel/Asus SMBus quirk then, which affects many
> more users than the SiS SMBus one, and would suffer from a reordering as
> well.
Intel/Asus users on FC[456] would surely have screamed if that was true. But I
was curious so I looked deeper. There is a fundamental difference between the
Intel SMBus quirks and the SiS SMBus quirk...
Intel:
1) The first quirk keys off the host bridge, setting a flag.
2) The second quirk keys off the LPC, enabling the SMBus if the flag was set.
SiS:
1) The first quirk keys off the *old* LPC ID... this causes the ID to change.[1]
2) The second quirk keys off the *new* LPC ID; this one enables the SMBus.
In the SiS case, both quirks key off the *same* *device*, but with potentially
different IDs. The quirk list ordering matters there because the list is
scanned only once per device.
For the Intel case, the only ordering that matters is that the host bridge
device is added [pci_device_add()] before the LPC; AFAICT, that is reliable,
perhaps even by definition.
So I don't think you have to worry about the Intel SMBus quirks.
[1] That's right, the first quirk actually changes the PCI device ID of the
LPC. Unless it actually *is* older hardware... in which case the quirk just
tickles a reserved bit that is ignored. Thank you SiS, that's just beautiful.
Regards,
--
Mark M. Hoffman
mhoffman@lightlink.com
next prev parent reply other threads:[~2007-01-10 4:02 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-19 4:13 Adrian Bunk
2006-12-19 8:52 ` Matthew Wilcox
2006-12-19 9:57 ` Adrian Bunk
2007-01-05 8:52 ` Jean Delvare
2007-01-05 23:29 ` Adrian Bunk
2007-01-07 11:30 ` Jean Delvare
2007-01-07 15:40 ` Mark M. Hoffman
2007-01-14 13:46 ` [-mm patch] remove quirk_sis_96x_compatible() Adrian Bunk
2007-01-14 15:22 ` Mark M. Hoffman
2007-01-07 15:44 ` [-mm patch] drivers/pci/quirks.c: cleanup Mark M. Hoffman
2007-01-08 11:10 ` Jean Delvare
2007-01-09 3:02 ` Mark M. Hoffman
2007-01-09 3:11 ` [PATCH 2.6.20-rc4] i2c/pci: fix sis96x smbus quirk once and for all Mark M. Hoffman
2007-01-09 13:17 ` [-mm patch] drivers/pci/quirks.c: cleanup Jean Delvare
2007-01-10 3:58 ` Mark M. Hoffman [this message]
2007-01-10 9:35 ` Jean Delvare
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=20070110035820.GB27550@jupiter.solarsys.private \
--to=mhoffman@lightlink.com \
--cc=bunk@stusta.de \
--cc=greg@kroah.com \
--cc=khali@linux-fr.org \
--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®