On Tuesday, February 17, 2009 2:19:39 am Yuji Shimada wrote:
> > If resource_alignment is a per-device attribute, doesn't it make
> > sense to put the file in /sys/bus/pci/devices/resource_alignment ?
>
> I don't think it is easy to add "/sys/bus/pci/devices/resource_alignment".
>
> In case of "/sys/bus/pci/resource_alignment", we can use BUS_ATTR.
> In case of "/sys/bus/pci/devices/SSSS:BB:DD.F/resource_alignment", we
> can use DEVICE_ATTR.
>
> But in case of "/sys/bus/pci/devices/resource_alignment", what can we
> use?
Yeah, might be a little trickier. Really it's a property of the bus scan &
resource allocation, so another option would be (with Alex's new stuff) to
make it part of the actual rescan command somehow.
> > > +config RESOURCE_ALIGNMENT_PARAM
> > > + bool
> > > + depends on PCI_QUIRKS
> > > + default y
> >
> > No Kconfig help?
>
> I will write the help.
>
> > And you really want to default y?
>
> Yes. This does not cause the issue, I think.
How much bigger does it make the code? I'm not even sure it's worth having a
config option for it; it shouldn't affect default behavior at all and doesn't
add a whole bunch of new stuff, so just adding it unconditionally should be
ok.
> > > + if (sscanf(p, "%x:%x.%x%n",
> > > + &bus, &slot, &func, &count) != 3) {
> > > + /* Invalid format */
> > > + printk(KERN_ERR "PCI: Can't parse "
> > > + "resource_alignment parameter: %s\n",
> >
> > I personally prefer all printk text to be on one line to improve
> > greppability. I think it's one of the valid reasons to break
> > 80-column rule.
>
> CordingStyle in the kernel tree says "Long strings are as well broken
> into shorter strings". I would not like to break this.
I won't argue too much about CodingStyle, but printk strings are an exception
to the 80 column rule, since as Alex says splitting them makes grepping for
error messages an exercise in frustration.
--
Jesse Barnes, Intel Open Source Technology Center
--
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
