It would make your patch easier to review if you didn't intermingle
style changes with content changes.
>Anyways, I started off
>with the simple observation that it didn't work. Watching
>/sbin/hotplug (diethotplug with debugging enabled) closely during
>add events showed me the following:
[...]
>Here we can see it is looking at aic7xxx twice, once for vendor
>0x9004, where it notices that the vendor matches, but then fails
>to match due to the 0xFFFF00 class_mask filter, and once for
>vendor 9005 which of course doesn't match. After changing the
>class_mask to ~0 I now see:
[...]
Changing the mask may have the desired effect, but it doesn't
show where the true bug is.
>So let me turn the question back to you: What is the intended
>purpose of masking out part of the class space?
I'm only trying to match on the base and sub class fields. In
the kernel (see drivers/pci/pci.c), the pci device field is
three bytes wide with the programming interface stored in the
lowest byte and class information in bytes 1 and 2. Since I only
place the expected class values in my table, not the value for
the programming interface, the low byte needs to be masked away prior
to doing the comparison. The logic in the kernel handles the
mask correctly:
((ids->class ^ dev->class) & ids->class_mask) == 0
My guess is that diethotplug is not handling the mask correctly
and thus doesn't work with a partial mask.
-- Justin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/