From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756705AbYGGSJ4 (ORCPT ); Mon, 7 Jul 2008 14:09:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754571AbYGGSJt (ORCPT ); Mon, 7 Jul 2008 14:09:49 -0400 Received: from mx1.redhat.com ([66.187.233.31]:36347 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754421AbYGGSJs (ORCPT ); Mon, 7 Jul 2008 14:09:48 -0400 Message-ID: <48725BEA.3090203@redhat.com> Date: Mon, 07 Jul 2008 14:09:46 -0400 From: Tony Camuso Reply-To: tcamuso@redhat.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Jesse Barnes CC: linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, "Schoeller, Patrick (Linux - Houston, TX)" , Ingo Molnar , Thomas Gleixner Subject: Re: bfsort whitelist patch apparently applied twice References: <48722996.4050601@redhat.com> <200807070959.51789.jbarnes@virtuousgeek.org> In-Reply-To: <200807070959.51789.jbarnes@virtuousgeek.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > 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 > Signed-off-by: Jesse Barnes > --- > 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"), > }, > }, > {}