On Saturday 24 May 2008 12:55:20 pm Thomas Jaeger wrote: > Bjorn Helgaas wrote: > > [This fixes a long-standing parport PNPACPI bug, and it would > > nice to have it in 2.6.26.] > > > I agree, especially since the ground work has already been laid in > 1d5b285da1893b90507b081664ac27f1a8a3dc5b. > > @@ -799,11 +802,14 @@ static void pnpacpi_encode_irq(struct pn > > irq->sharable = ACPI_SHARED; > > irq->interrupt_count = 1; > > irq->interrupts[0] = p->start; > > + irq->descriptor_length = resource->data.irq.descriptor_length; > > > I don't understand the point of this line. Aren't > irq->descriptor_length and resource->data.irq.descriptor_length the same > thing? You're right, I don't know what I was thinking there. I'm sorry I cast aspersions on your patch, which should be correct and sufficient. I will still post an updated version, if you don't mind, to add a little debug output. And I think I'll still skip the "start dependent function" piece, since we don't encode those. (I don't see anything in the spec that says you can't have a "start DPF" descriptor in a _CRS or _SRS buffer, but I have no idea what it would mean.) Later, I'm going to take another look at this template/encode business. It looks like we currently allocate a new buffer sized to hold only the descriptors we know about. I think it would be better if we just evaluated _CRS, kept the buffer it returned, then encoded our new resources directly into the same buffer, ignoring things we don't know about. That way we wouldn't be quite so susceptible to issues like this. > Bjorn, while we're on the subject, could you have a look at > http://bugzilla.kernel.org/show_bug.cgi?id=9487#c32 ? I've noticed that > you've already fixed the third point there; the other two points may > well be irrelevant or never occur in practice, but then they could be > the sort of thing that costs somebody hours of debugging time. I agree, that should be cleaned up. I'll take a look at that, too. Thanks, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
