On Mon, 2005-08-08 at 10:36 -0600, Bjorn Helgaas wrote:
> On Friday 05 August 2005 5:51 pm, Kristen Accardi wrote:
> > On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
> > driver and SHPC driver in MSI mode are used together. This patch will
> > prevent MSI from being enabled
> You can hide the "complexity" of the second line behind
> macros. And this is what is done in most places.
oh, I agree. My only point is that if the *only* argument against
bitfields is that they're inefficient (insert vague hand-waving) then
people will happily decide to live with that ineff
From: Zach Brown <[EMAIL PROTECTED]>
Date: Mon, 08 Aug 2005 10:42:37 -0700
> if (!foo->enabled)
> if (!(foo->flags & FOO_FLAG_ENABLED)
You can hide the "complexity" of the second line behind
macros. And this is what is done in most places.
Alternatively, you can use the existing bit
Jeff Garzik wrote:
>
>
> FWIW, compilers generate AWFUL code for bitfields. Bitfields are
> really tough to do optimally, whereas bit flags ["unsigned int flags &
> bitmask"] are the familiar ints and longs that the compiler is well
> tuned to optimize.
I wouldn't have chosen the micro-optimiz
On Friday 05 August 2005 5:51 pm, Kristen Accardi wrote:
> On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
> driver and SHPC driver in MSI mode are used together. This patch will
> prevent MSI from being enabled for the SHPC as part of an early pci
> quirk, as well as on any
On Saturday 06 August 2005 18:57, Jeff Garzik wrote:
> On Sat, Aug 06, 2005 at 09:50:13AM +0100, Matthew Wilcox wrote:
> > On Fri, Aug 05, 2005 at 11:34:55PM -0400, Jeff Garzik wrote:
> > > FWIW, compilers generate AWFUL code for bitfields. Bitfields are
> > > really tough to do optimally, whereas
On Sat, Aug 06, 2005 at 09:50:13AM +0100, Matthew Wilcox wrote:
> On Fri, Aug 05, 2005 at 11:34:55PM -0400, Jeff Garzik wrote:
> > FWIW, compilers generate AWFUL code for bitfields. Bitfields are
> > really tough to do optimally, whereas bit flags ["unsigned int flags &
> > bitmask"] are the famil
On Fri, Aug 05, 2005 at 11:34:55PM -0400, Jeff Garzik wrote:
> FWIW, compilers generate AWFUL code for bitfields. Bitfields are
> really tough to do optimally, whereas bit flags ["unsigned int flags &
> bitmask"] are the familiar ints and longs that the compiler is well
> tuned to optimize.
I'm s
On Fri, Aug 05, 2005 at 03:57:12PM -0700, Greg KH wrote:
> Anyway, Jeff is right, add another bit field.
The updated patch, which adds a new bitfield, looks OK to me.
However...
FWIW, compilers generate AWFUL code for bitfields. Bitfields are
really tough to do optimally, whereas bit flags [
On Fri, 2005-08-05 at 18:50 -0400, Jeff Garzik wrote:
>
> AFAICS we don't need a new list, simply consisting of PCI devs.
>
> Just invent, and set, a bit somewhere in struct pci_dev.
>
> Jeff
>
>
>
Great! I like that much better. How about this:
On the 6700/6702 PXH part, a MSI may g
On Fri, Aug 05, 2005 at 03:05:13PM -0700, Kristen Accardi wrote:
> +int msi_add_quirk(struct pci_dev *dev)
> +{
> + struct msi_quirk *quirk;
> +
> + quirk = (struct msi_quirk *) kmalloc(sizeof(*quirk), GFP_KERNEL);
> + if (!quirk)
> + return -ENOMEM;
> +
> + INIT_LI
Kristen Accardi <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2005-08-05 at 15:26 -0700, Andrew Morton wrote:
> > Kristen Accardi <[EMAIL PROTECTED]> wrote:
>
> > > + if (!quirk)
> > > + return -ENOMEM;
> > > +
> > > + INIT_LIST_HEAD(&quirk->list);
> > > + quirk->dev = dev;
> > > + list_add(&qui
AFAICS we don't need a new list, simply consisting of PCI devs.
Just invent, and set, a bit somewhere in struct pci_dev.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.ke
On Fri, 2005-08-05 at 15:26 -0700, Andrew Morton wrote:
> Kristen Accardi <[EMAIL PROTECTED]> wrote:
> > + if (!quirk)
> > + return -ENOMEM;
> > +
> > + INIT_LIST_HEAD(&quirk->list);
> > + quirk->dev = dev;
> > + list_add(&quirk->list, &msi_quirk_list);
> > + return 0;
> > +
Kristen Accardi <[EMAIL PROTECTED]> wrote:
>
> ...
> On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
> driver and SHPC driver in MSI mode are used together. This patch will
> prevent MSI from being enabled for the SHPC.
>
> I made this patch more generic than just shpc bec
On Fri, 2005-08-05 at 11:35 -0700, Greg KH wrote:
> On Fri, Aug 05, 2005 at 09:27:42AM -0700, Kristen Accardi wrote:
> > @@ -1127,3 +1159,5 @@ EXPORT_SYMBOL(pci_enable_msi);
> > EXPORT_SYMBOL(pci_disable_msi);
> > EXPORT_SYMBOL(pci_enable_msix);
> > EXPORT_SYMBOL(pci_disable_msix);
> > +EXPORT_S
On Fri, 2005-08-05 at 11:35 -0700, Greg KH wrote:
> On Fri, Aug 05, 2005 at 09:27:42AM -0700, Kristen Accardi wrote:
> > @@ -1127,3 +1159,5 @@ EXPORT_SYMBOL(pci_enable_msi);
> > EXPORT_SYMBOL(pci_disable_msi);
> > EXPORT_SYMBOL(pci_enable_msix);
> > EXPORT_SYMBOL(pci_disable_msix);
> > +EXPORT_S
On Fri, Aug 05, 2005 at 09:27:42AM -0700, Kristen Accardi wrote:
> @@ -1127,3 +1159,5 @@ EXPORT_SYMBOL(pci_enable_msi);
> EXPORT_SYMBOL(pci_disable_msi);
> EXPORT_SYMBOL(pci_enable_msix);
> EXPORT_SYMBOL(pci_disable_msix);
> +EXPORT_SYMBOL(disable_msi_mode);
> +EXPORT_SYMBOL(msi_add_quirk);
Why
On Friday 05 August 2005 10:27 am, Kristen Accardi wrote:
> On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
> driver and SHPC driver in MSI mode are used together. This patch will
> prevent MSI from being enabled for the SHPC.
Can you outline the scenario that causes the c
On Fri, 2005-08-05 at 11:12 -0600, Bjorn Helgaas wrote:
> On Friday 05 August 2005 10:27 am, Kristen Accardi wrote:
> > On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
> > driver and SHPC driver in MSI mode are used together. This patch will
> > prevent MSI from being enabled
On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
driver and SHPC driver in MSI mode are used together. This patch will
prevent MSI from being enabled for the SHPC.
I made this patch more generic than just shpc because I thought it was
possible that other devices in the syst
21 matches
Mail list logo