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. Maciej
