On Thu, 4 Oct 2007, Ralf Baechle wrote:
> I think historically we had something like chkslot() first in the code
> for the Galileo/Marvell bridges where it's needed due the brainddead
> abuse of device 31 - any access to that will crash the system. From that
> point on chkslot checking spread across the PCI code like the measles in
> a kindergarden.
Does the Galileo/Marvell do anything else with the device #31 than what
is recommended by the PCI spec as a way to issue special cycles? We need
to be careful about the device #31 in general; it is seldom used anyway as
there are only 20 IDSEL lines defined by the standard and they are usually
mapped starting from the device #0.
> Another stylistic comment is about the return statement in the macro.
> That sort of construct should be avoided, it's quite unobvious to the
> reader who isn't familiar with the macro definition.
[etc... about macros]
Very true indeed -- I sort of slipped over the issue unconsciously as it
is outside the scope of the fix itself. It is usually a good idea to
separate clean-ups from changes to the semantics.
> Ah, one final formality - when sending a patch please add a
> Signed-off-by: line. See Documentation/SubmittingPatches in the kernel
> tree for what this means.
Well, there was one actually in the submission. :-) And `checkpatch.pl'
would remind about it otherwise.