On Friday 03 October 2008 12:13:14 pm Vincent Legoll wrote:
> On Fri, Oct 3, 2008 at 11:14 AM, Vincent Legoll
> <vincent.legoll@xxxxxxxxx> wrote:
> > On Thu, Oct 2, 2008 at 8:59 PM, Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote:
> >> On Thursday 02 October 2008 12:46:28 pm Jesse Barnes wrote:
> >>> Bjorn, how does this jive with the various other debug harmonization patches
> >>> you've been putting together & reviewing?
> >>
> >> I think it's great. The only nit I would change is to use
> >> "[%#llx-%#llx]" as we do in pci_request_region().
> >>
> >> Bjorn
> >
> > Thanks for the review, I'll post an updated version this evening.
>
> Here is the updated version, with an extra case from drivers/pci/pcie/aspm.c,
> please review for the slight wording change in the message. It's currently
> running, so is partly tested (It didn't ran through all cases on my HW)
It'll be easier for Jesse if you include the proper changelog again
with just a 1-2 line sample of the changed messages. BTW, the "--"
before your sig confused my mailer into not quoting the patch itself,
hence the screwed up formatting below.
> - printk("Pre-1.1 PCIe device detected, "
> - "disable ASPM for %s. It can be
> enabled forcedly" - " with
> 'pcie_aspm=force'\n", pci_name(pdev));
> + dev_printk(KERN_INFO, &child_dev->dev,
> "disabling ASPM" + " on pre-1.1 PCIe
> device. It can be enabled" + "
> forcedly with 'pcie_aspm=force'\n");
dev_info() is exactly equivalent to dev_printk(KERN_INFO). I usually
use dev_info(), though I'm a bit ambivalent because it's nice to be
able to grep for "printk". Anyway, maybe you can correct the grammar
of "enabled forcedly" to something like "you can enable with ..." when
you re-post with the changelog.
(Note that dev_dbg() is NOT exactly equivalent to dev_printk(KERN_DEBUG),
so you can't change all of them. dev_printk(KERN_DEBUG) is always
compiled in, while dev_dbg() is only compiled in when "DEBUG" is defined.)
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
