* bfsort whitelist patch apparently applied twice
@ 2008-07-07 14:35 Tony Camuso
2008-07-07 16:59 ` Jesse Barnes
0 siblings, 1 reply; 4+ messages in thread
From: Tony Camuso @ 2008-07-07 14:35 UTC (permalink / raw)
To: Jesse Barnes, linux-kernel, linux-pci
Cc: Schoeller, Patrick (Linux - Houston, TX)
In the most recent pull from Linus' tree, I see that the patch
I submitted on 14-May-2008 was merged twice in the git log.
commits: a16b4bcd31a73a81b6d2b8ffa6b5f6ed01cf6d64
and: a1676072558854b95336c8f7db76b0504e909a0a
The result is that now the DL360 and DL380 are whitelisted twice
and the DL385 G2 and DL585 G2 are not whitelisted at all!
Can one of these redundant commits be backed out?
Thanks and regards,
Tony
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: bfsort whitelist patch apparently applied twice 2008-07-07 14:35 bfsort whitelist patch apparently applied twice Tony Camuso @ 2008-07-07 16:59 ` Jesse Barnes 2008-07-07 18:09 ` Tony Camuso 0 siblings, 1 reply; 4+ messages in thread From: Jesse Barnes @ 2008-07-07 16:59 UTC (permalink / raw) To: tcamuso Cc: linux-kernel, linux-pci, Schoeller, Patrick (Linux - Houston, TX), Ingo Molnar, Thomas Gleixner On Monday, July 07, 2008 7:35 am Tony Camuso wrote: > In the most recent pull from Linus' tree, I see that the patch > I submitted on 14-May-2008 was merged twice in the git log. > > commits: a16b4bcd31a73a81b6d2b8ffa6b5f6ed01cf6d64 > and: a1676072558854b95336c8f7db76b0504e909a0a > > The result is that now the DL360 and DL380 are whitelisted twice > and the DL385 G2 and DL585 G2 are not whitelisted at all! > > Can one of these redundant commits be backed out? Hm, seems like this should have created a conflict since there was some actual context (#ifdef __i386__) in the patch? Ah I see, it looks like the one that came in through Ingo & Thomas, a1676072558854b95336c8f7db76b0504e909a0a, modified the end of the list, while the one that I sent upstream, 8d64c781f0c5fbfdf8016bd1634506ff2ad1376a, modified the entry above #ifdef __i386__. That's unfortunate. Here's what I've got, look ok? Thanks, Jesse >From a86744c1d60b2bc2a575de48672f6f6c15c0411f Mon Sep 17 00:00:00 2001 From: Jesse Barnes <jbarnes@hobbes.(none)> Date: Mon, 7 Jul 2008 09:55:26 -0700 Subject: [PATCH] Revert "PCI: Correct last two HP entries in the bfsort whitelist" This reverts commit a1676072558854b95336c8f7db76b0504e909a0a. It duplicates the change from 8d64c781f0c5fbfdf8016bd1634506ff2ad1376a and only one should be applied, otherwise some of the Dell quirks are lost. Thanks to Tony Camuso for catching this. Acked-by: Tony Camuso <tcamuso@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> --- arch/x86/pci/common.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c index 940185e..6e64aaf 100644 --- a/arch/x86/pci/common.c +++ b/arch/x86/pci/common.c @@ -328,18 +328,18 @@ static struct dmi_system_id __devinitdata pciprobe_dmi_table[] = { #endif { .callback = set_bf_sort, - .ident = "HP ProLiant DL360", + .ident = "HP ProLiant DL385 G2", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "HP"), - DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL360"), + DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL385 G2"), }, }, { .callback = set_bf_sort, - .ident = "HP ProLiant DL380", + .ident = "HP ProLiant DL585 G2", .matches = { DMI_MATCH(DMI_SYS_VENDOR, "HP"), - DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL380"), + DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL585 G2"), }, }, {} -- 1.5.4.1 ^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: bfsort whitelist patch apparently applied twice 2008-07-07 16:59 ` Jesse Barnes @ 2008-07-07 18:09 ` Tony Camuso 2008-07-07 22:36 ` Jesse Barnes 0 siblings, 1 reply; 4+ messages in thread From: Tony Camuso @ 2008-07-07 18:09 UTC (permalink / raw) To: Jesse Barnes Cc: linux-kernel, linux-pci, Schoeller, Patrick (Linux - Houston, TX), Ingo Molnar, Thomas Gleixner Yes, that fixes it. Thanks, Jesse. Regards, Tony Jesse Barnes wrote: > On Monday, July 07, 2008 7:35 am Tony Camuso wrote: >> In the most recent pull from Linus' tree, I see that the patch >> I submitted on 14-May-2008 was merged twice in the git log. >> >> commits: a16b4bcd31a73a81b6d2b8ffa6b5f6ed01cf6d64 >> and: a1676072558854b95336c8f7db76b0504e909a0a >> >> The result is that now the DL360 and DL380 are whitelisted twice >> and the DL385 G2 and DL585 G2 are not whitelisted at all! >> >> Can one of these redundant commits be backed out? > > Hm, seems like this should have created a conflict since there was some actual > context (#ifdef __i386__) in the patch? Ah I see, it looks like the one that > came in through Ingo & Thomas, a1676072558854b95336c8f7db76b0504e909a0a, > modified the end of the list, while the one that I sent upstream, > 8d64c781f0c5fbfdf8016bd1634506ff2ad1376a, modified the entry above #ifdef > __i386__. That's unfortunate. > > Here's what I've got, look ok? > > Thanks, > Jesse > > From a86744c1d60b2bc2a575de48672f6f6c15c0411f Mon Sep 17 00:00:00 2001 > From: Jesse Barnes <jbarnes@hobbes.(none)> > Date: Mon, 7 Jul 2008 09:55:26 -0700 > Subject: [PATCH] Revert "PCI: Correct last two HP entries in the bfsort whitelist" > > This reverts commit a1676072558854b95336c8f7db76b0504e909a0a. It duplicates > the change from 8d64c781f0c5fbfdf8016bd1634506ff2ad1376a and only one should be > applied, otherwise some of the Dell quirks are lost. > > Thanks to Tony Camuso for catching this. > > Acked-by: Tony Camuso <tcamuso@redhat.com> > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> > --- > arch/x86/pci/common.c | 8 ++++---- > 1 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c > index 940185e..6e64aaf 100644 > --- a/arch/x86/pci/common.c > +++ b/arch/x86/pci/common.c > @@ -328,18 +328,18 @@ static struct dmi_system_id __devinitdata pciprobe_dmi_table[] = { > #endif > { > .callback = set_bf_sort, > - .ident = "HP ProLiant DL360", > + .ident = "HP ProLiant DL385 G2", > .matches = { > DMI_MATCH(DMI_SYS_VENDOR, "HP"), > - DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL360"), > + DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL385 G2"), > }, > }, > { > .callback = set_bf_sort, > - .ident = "HP ProLiant DL380", > + .ident = "HP ProLiant DL585 G2", > .matches = { > DMI_MATCH(DMI_SYS_VENDOR, "HP"), > - DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL380"), > + DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL585 G2"), > }, > }, > {} ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: bfsort whitelist patch apparently applied twice 2008-07-07 18:09 ` Tony Camuso @ 2008-07-07 22:36 ` Jesse Barnes 0 siblings, 0 replies; 4+ messages in thread From: Jesse Barnes @ 2008-07-07 22:36 UTC (permalink / raw) To: tcamuso Cc: linux-kernel, linux-pci, Schoeller, Patrick (Linux - Houston, TX), Ingo Molnar, Thomas Gleixner Ok, I sent off the pull request to Linus; we'll have to be careful about having multiple versions of the same fix floating around in the future. Thanks, Jesse On Monday, July 07, 2008 11:09 am Tony Camuso wrote: > Yes, that fixes it. > > Thanks, Jesse. > > Regards, > Tony > > Jesse Barnes wrote: > > On Monday, July 07, 2008 7:35 am Tony Camuso wrote: > >> In the most recent pull from Linus' tree, I see that the patch > >> I submitted on 14-May-2008 was merged twice in the git log. > >> > >> commits: a16b4bcd31a73a81b6d2b8ffa6b5f6ed01cf6d64 > >> and: a1676072558854b95336c8f7db76b0504e909a0a > >> > >> The result is that now the DL360 and DL380 are whitelisted twice > >> and the DL385 G2 and DL585 G2 are not whitelisted at all! > >> > >> Can one of these redundant commits be backed out? > > > > Hm, seems like this should have created a conflict since there was some > > actual context (#ifdef __i386__) in the patch? Ah I see, it looks like > > the one that came in through Ingo & Thomas, > > a1676072558854b95336c8f7db76b0504e909a0a, modified the end of the list, > > while the one that I sent upstream, > > 8d64c781f0c5fbfdf8016bd1634506ff2ad1376a, modified the entry above #ifdef > > __i386__. That's unfortunate. > > > > Here's what I've got, look ok? > > > > Thanks, > > Jesse > > > > From a86744c1d60b2bc2a575de48672f6f6c15c0411f Mon Sep 17 00:00:00 2001 > > From: Jesse Barnes <jbarnes@hobbes.(none)> > > Date: Mon, 7 Jul 2008 09:55:26 -0700 > > Subject: [PATCH] Revert "PCI: Correct last two HP entries in the bfsort > > whitelist" > > > > This reverts commit a1676072558854b95336c8f7db76b0504e909a0a. It > > duplicates the change from 8d64c781f0c5fbfdf8016bd1634506ff2ad1376a and > > only one should be applied, otherwise some of the Dell quirks are lost. > > > > Thanks to Tony Camuso for catching this. > > > > Acked-by: Tony Camuso <tcamuso@redhat.com> > > Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> > > --- > > arch/x86/pci/common.c | 8 ++++---- > > 1 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c > > index 940185e..6e64aaf 100644 > > --- a/arch/x86/pci/common.c > > +++ b/arch/x86/pci/common.c > > @@ -328,18 +328,18 @@ static struct dmi_system_id __devinitdata > > pciprobe_dmi_table[] = { #endif > > { > > .callback = set_bf_sort, > > - .ident = "HP ProLiant DL360", > > + .ident = "HP ProLiant DL385 G2", > > .matches = { > > DMI_MATCH(DMI_SYS_VENDOR, "HP"), > > - DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL360"), > > + DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL385 G2"), > > }, > > }, > > { > > .callback = set_bf_sort, > > - .ident = "HP ProLiant DL380", > > + .ident = "HP ProLiant DL585 G2", > > .matches = { > > DMI_MATCH(DMI_SYS_VENDOR, "HP"), > > - DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL380"), > > + DMI_MATCH(DMI_PRODUCT_NAME, "ProLiant DL585 G2"), > > }, > > }, > > {} ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-07-07 22:36 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2008-07-07 14:35 bfsort whitelist patch apparently applied twice Tony Camuso 2008-07-07 16:59 ` Jesse Barnes 2008-07-07 18:09 ` Tony Camuso 2008-07-07 22:36 ` Jesse Barnes
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox