mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Travis <travis@sgi.com>, Ingo Molnar <mingo@redhat.com>,
	Rusty Russell <rusty@rustcorp.com.au>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jack Steiner <steiner@sgi.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 03/11] cpumask: update pci_bus_show_cpuaffinity to use new cpumask API
Date: Mon, 5 Jan 2009 11:49:49 -0800	[thread overview]
Message-ID: <200901051149.50337.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <alpine.LFD.2.00.0901051139410.3057@localhost.localdomain>

On Monday, January 5, 2009 11:44 am Linus Torvalds wrote:
> On Mon, 5 Jan 2009, Jesse Barnes wrote:
> > Can you resend these two against my linux-next branch?
>
> Btw, Jesse, what's the schedule for merging the pci thing.

Just pulling together some more patches today; was planning on sending a pull 
request tomorrow.

> I'm currently planning on -rc1 next weekend, which gives us time to do at
> least a shortened -rc2 before people are at LCA. And the suspend/resume
> changes are some of the more "exciting" (aka scary) parts of the whole
> merge window, so I'd rather get them merged with a few days to go, rather
> than just before -rc1.
>
> In fact, they are probably more scary than the cpumask changes, since at
> least the cpumask issues are likely to not be a big deal with any normal
> sane config (ie you really do have to enable MAXSMP to hit the stack usage
> issues). So if you end up waiting for those, I'd rather prefer to first
> merge the rest of the PCI code.

Yeah, they're no big deal, just wanted to get them (the cpumask changes) 
queued up...

> Or did the PCI late-suspend/early-resume patches go in somebody elses
> tree and I'm barking up the wrong tree entirely?

No they're coming through my tree; just need to ping Rafael again and get the 
latest set.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center


  reply	other threads:[~2009-01-05 19:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-04 13:17 [PATCH 00/11] x86: cpumask: some more cpumask cleanups Mike Travis
2009-01-04 13:18 ` [PATCH 01/11] [PATCH] ia64: cpumask fix for is_affinity_mask_valid() Mike Travis
2009-01-04 13:18 ` [PATCH 02/11] cpumask: update local_cpus_show to use new cpumask API Mike Travis
2009-01-04 13:18 ` [PATCH 03/11] cpumask: update pci_bus_show_cpuaffinity " Mike Travis
2009-01-05 19:27   ` Jesse Barnes
2009-01-05 19:31     ` Mike Travis
2009-01-05 19:59       ` Jesse Barnes
2009-01-07 15:19         ` Ingo Molnar
2009-01-07 16:59           ` Jesse Barnes
2009-01-05 19:44     ` Linus Torvalds
2009-01-05 19:49       ` Jesse Barnes [this message]
2009-01-04 13:18 ` [PATCH 04/11] x86: cleanup remaining cpumask_t ops in smpboot code Mike Travis
2009-01-04 13:18 ` [PATCH 05/11] x86: clean up speedstep-centrino and reduce cpumask_t usage From: Rusty Russell <rusty@rustcorp.com.au> Mike Travis
2009-01-04 13:18 ` [PATCH 06/11] cpumask: Replace CPUMASK_ALLOC etc with cpumask_var_t. " Mike Travis
2009-01-04 13:18 ` [PATCH 07/11] cpumask: convert struct cpufreq_policy to " Mike Travis
2009-01-04 13:18 ` [PATCH 08/11] cpumask: use work_on_cpu in acpi/cstate.c Mike Travis
2009-01-04 13:18 ` [PATCH 09/11] cpumask: use cpumask_var_t in acpi-cpufreq.c Mike Travis
2009-01-04 13:18 ` [PATCH 10/11] cpumask: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_write Mike Travis
2009-01-04 13:18 ` [PATCH 11/11] cpumask: use work_on_cpu in acpi-cpufreq.c for read_measured_perf_ctrs Mike Travis
2009-01-04 14:44 ` [PATCH 00/11] x86: cpumask: some more cpumask cleanups Ingo Molnar
2009-01-05 18:28   ` Mike Travis
2009-01-06  3:49   ` [PATCH 00/11] x86: cpumask: some more cpumask cleanups - flush_tlb_* Mike Travis
2009-01-07  2:12     ` Rusty Russell
2009-01-07  2:50       ` Mike Travis

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=200901051149.50337.jbarnes@virtuousgeek.org \
    --to=jbarnes@virtuousgeek.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=steiner@sgi.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=travis@sgi.com \
    /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

Powered by JetHome