http://patchwork.kernel.org/patch/711/
CommentsOn Sunday, January 4, 2009 5:18 am Mike Travis wrote: > Impact: cleanup, reduce stack usage, use new cpumask API. > > Replace the local cpumask_t variable with a pointer to the > const cpumask that needs to be printed. > > Signed-off-by: Mike Travis <[email protected]> > Cc: Jesse Barnes <[email protected]> Can you resend these two against my linux-next branch? Thanks, Jesse Barnes wrote: > On Sunday, January 4, 2009 5:18 am Mike Travis wrote: >> Impact: cleanup, reduce stack usage, use new cpumask API. >> >> Replace the local cpumask_t variable with a pointer to the >> const cpumask that needs to be printed. >> >> Signed-off-by: Mike Travis <[email protected]> >> Cc: Jesse Barnes <[email protected]> > > Can you resend these two against my linux-next branch? > > Thanks, Sure thing. Would this be the latest .../sfr/linux-next.git master tree or would I need to select some other branch? Thanks, Mike -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ 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. 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. Or did the PCI late-suspend/early-resume patches go in somebody elses tree and I'm barking up the wrong tree entirely? Linus -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ 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, On Monday, January 5, 2009 11:31 am Mike Travis wrote: > Jesse Barnes wrote: > > On Sunday, January 4, 2009 5:18 am Mike Travis wrote: > >> Impact: cleanup, reduce stack usage, use new cpumask API. > >> > >> Replace the local cpumask_t variable with a pointer to the > >> const cpumask that needs to be printed. > >> > >> Signed-off-by: Mike Travis <[email protected]> > >> Cc: Jesse Barnes <[email protected]> > > > > Can you resend these two against my linux-next branch? > > > > Thanks, > > Sure thing. Would this be the latest .../sfr/linux-next.git master > tree or would I need to select some other branch? That would probably work, but my actual tree is at git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6.git; the linux- next branch is the one that I'll be sending to Linus soon. Thanks, * Jesse Barnes <[email protected]> wrote: > On Monday, January 5, 2009 11:31 am Mike Travis wrote: > > Jesse Barnes wrote: > > > On Sunday, January 4, 2009 5:18 am Mike Travis wrote: > > >> Impact: cleanup, reduce stack usage, use new cpumask API. > > >> > > >> Replace the local cpumask_t variable with a pointer to the > > >> const cpumask that needs to be printed. > > >> > > >> Signed-off-by: Mike Travis <[email protected]> > > >> Cc: Jesse Barnes <[email protected]> > > > > > > Can you resend these two against my linux-next branch? > > > > > > Thanks, > > > > Sure thing. Would this be the latest .../sfr/linux-next.git master > > tree or would I need to select some other branch? > > That would probably work, but my actual tree is at > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6.git; the linux- > next branch is the one that I'll be sending to Linus soon. hm, i already have it queued up in tip/cpus4096: 588235b: cpumask: update pci_bus_show_cpuaffinity to use new cpumask API as you said that it would be fine to do it there. I guess it's not a problem to have it duplicate - the code changes one narrow area of code. Ingo -- 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.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ On Wednesday, January 7, 2009 7:19 am Ingo Molnar wrote: > * Jesse Barnes <[email protected]> wrote: > > On Monday, January 5, 2009 11:31 am Mike Travis wrote: > > > Jesse Barnes wrote: > > > > On Sunday, January 4, 2009 5:18 am Mike Travis wrote: > > > >> Impact: cleanup, reduce stack usage, use new cpumask API. > > > >> > > > >> Replace the local cpumask_t variable with a pointer to the > > > >> const cpumask that needs to be printed. > > > >> > > > >> Signed-off-by: Mike Travis <[email protected]> > > > >> Cc: Jesse Barnes <[email protected]> > > > > > > > > Can you resend these two against my linux-next branch? > > > > > > > > Thanks, > > > > > > Sure thing. Would this be the latest .../sfr/linux-next.git master > > > tree or would I need to select some other branch? > > > > That would probably work, but my actual tree is at > > git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6.git; the > > linux- next branch is the one that I'll be sending to Linus soon. > > hm, i already have it queued up in tip/cpus4096: > > 588235b: cpumask: update pci_bus_show_cpuaffinity to use new cpumask API > > as you said that it would be fine to do it there. I guess it's not a > problem to have it duplicate - the code changes one narrow area of code. I don't have it queued in my tree; it depends on other changes in Linus' tree I haven't rebased to yet (will do today when I pull in Rafael's PCI suspend/resume fixes), but I'll let this stuff come through your tree alone. Thanks, Patch--- linux-2.6-for-ingo.orig/drivers/pci/probe.c +++ linux-2.6-for-ingo/drivers/pci/probe.c @@ -51,12 +51,12 @@ static ssize_t pci_bus_show_cpuaffinity( char *buf) { int ret; - cpumask_t cpumask; + const struct cpumask *cpumask; - cpumask = pcibus_to_cpumask(to_pci_bus(dev)); + cpumask = cpumask_of_pcibus(to_pci_bus(dev)); ret = type? - cpulist_scnprintf(buf, PAGE_SIZE-2, &cpumask) : - cpumask_scnprintf(buf, PAGE_SIZE-2, &cpumask); + cpulist_scnprintf(buf, PAGE_SIZE-2, cpumask) : + cpumask_scnprintf(buf, PAGE_SIZE-2, cpumask); buf[ret++] = '\n'; buf[ret] = '\0'; return ret; |
