Hi Bjorn. Andrew earlier commented that pci_resourec_flags() returns an unsigned long. Had this hanging around a local branch. Useful? Rene.
-int pnp_resource_type(struct resource *res)
+unsigned long pnp_resource_type(struct resource *res)
{
return res->flags & (IORESOURCE_IO | IORESOURCE_MEM |
IORESOURCE_IRQ | IORESOURCE_DMA);
}
Seems a bit pointless ... either one of those flags is >= 32 bits, in
which case we need u64, or it's not, in which case there is no reason to
burden the output with bits we don't need.
-hpa
--
Yes, it's a not a functional patch -- only a type-consistency one. Right now we're mixing ints (signed ones even) and unsigned longs and while in this case that's not a functional problem it's messy and inconsistent. I agree (as Andrew said earlier as well) that the struct resource flags member should probably just be a u32 but it's not. Changing that would be a bigger change than just a simple conistency thing. Rene. --
You're going in the wrong direction for consistency. long is different on 32 and 64 bits, and really should be avoided unless that is intended. -hpa --
I know and fair enough but changing struct resource is just a bit too central for my tastes. <shrug> Rene. --
I see hpa's point that it makes no functional difference, but I do think it's worthwhile to make the types match. I don't want to debug the problem that happens when somebody adds an IORESOURCE_* flag in the upper bits. You probably want to send this (and the next one, which is really a pci_resource_flags() usage despite being in drivers/pnp/quirks.c) to Andi Kleen. Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com> --
Then half the platforms break anyway. We should change this to an explicit type. -hpa --
Are you suggesting a change to the "unsigned long flags" in struct resource, or a different change to pnp_resource_type()? The struct resource change sounds reasonable, but I think neither Rene nor I want to sign up to do that right now. Whatever we have in struct resource, I think it makes sense to use the same type everywhere we reference the "flags" element. I think you're saying "it doesn't matter in this case that we use different types." But I, as a code reader, would rather not have to spend the mental energy to convince myself that you're right. Bjorn --
Okay, thanks. I see that Andrew picked these up with Andi in CC so I'll assume things will find their way from there. Rene. --
