From: Ingo Molnar <mingo@elte.hu>
To: Jeff Garzik <jeff@garzik.org>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
davem@davemloft.net
Subject: Re: [RESEND PATCH 1/3] e1000e: set CONFIG_E1000E=y in x86 defconfigs
Date: Thu, 26 Jun 2008 14:39:50 +0200 [thread overview]
Message-ID: <20080626123950.GR29619@elte.hu> (raw)
In-Reply-To: <48602FA8.7090508@garzik.org>
* Jeff Garzik <jeff@garzik.org> wrote:
> Ingo Molnar wrote:
>> * Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
>>
>>> From: Auke Kok <auke-jan.h.kok@intel.com>
>>>
>>> This adds to the already default CONFIG_E1000=y in these files.
>>>
>>> Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
>>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>> ---
>>>
>>> arch/x86/configs/i386_defconfig | 1 +
>>> arch/x86/configs/x86_64_defconfig | 1 +
>>
>> that is not an e1000 patch but an arch/x86 defconfig patch. NAK on this
>> route of patch propagation.
>
> But it's dependent on an e1000 patch. Maybe we could follow the lead
> of ppc and other arch maintainers, and work together?
>
> Typically if there are arch dependencies and little drivers/net
> changes, I'll ACK the drivers/net change and then let it go through
> the arch tree.
>
> In this case, there is far more drivers/net code, so it would make the
> most sense to work with you to change the defconfigs to your liking,
> and then merge them via netdev when the other E1000 changes go in.
the normal flow for defconfig changes is to first do the driver changes,
then later on propagate anything that is needed into the defconfig, once
the driver change is upstream.
for example we've already got this queued up in tip/x86:
| commit b5d958ea66ac11b1190c24f042f517adf9229a98
| Author: Auke Kok <auke-jan.h.kok@intel.com>
| Date: Wed Apr 9 13:17:39 2008 -0700
|
| e1000e: set CONFIG_E1000E=y in x86 defconfigs
|
| This adds to the already default CONFIG_E1000=y in these files.
and there's a fair number of other changes as well to the defconfigs for
v2.6.27 which might collide. So it would be nice to keep it separate
please.
Ingo
prev parent reply other threads:[~2008-06-26 12:40 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-22 22:20 [RESEND PATCH 1/3] e1000e: set CONFIG_E1000E=y in x86 defconfigs Jeff Kirsher
2008-06-22 22:21 ` [RESEND PATCH 2/3] e1000: remove PCI Express device IDs Jeff Kirsher
2008-06-27 6:08 ` Jeff Garzik
2008-06-22 22:22 ` [RESEND PATCH 3/3] e1000: enable NAPI by default in defconfig Jeff Kirsher
2008-06-23 11:26 ` [RESEND PATCH 1/3] e1000e: set CONFIG_E1000E=y in x86 defconfigs Ingo Molnar
2008-06-23 23:14 ` Jeff Kirsher
2008-06-23 23:20 ` Jeff Garzik
2008-06-26 12:39 ` Ingo Molnar [this message]
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=20080626123950.GR29619@elte.hu \
--to=mingo@elte.hu \
--cc=davem@davemloft.net \
--cc=jeff@garzik.org \
--cc=jeffrey.t.kirsher@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).