On Sun, Aug 15, 2010 at 1:30 PM, Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> I'd be suspecting that we have two patches both of which worked
> separately but which broke when combined. Is there some other patch in
> that tree which adds a new reference to `ref' in acpi_power_seq_show()?
The offending patch isn't about acpi_power_seq_show(), it's about
acpi_power_off_device().
But that may well explain the breakage: there does seem to be an
unused ref in acpi_power_seq_show() (around line 556). It's just that
the patch in question doesn't remove that one, it removes the
very-much-used one in acpi_power_off_device() (line 256 or so).
And the contexts don't even match. Well, they do match to 2 lines. But
they're not very close. However, Len's tree does have a patch to just
remove all the procfs crap, so acpi_power_seq_show() has gone away,
which I guess explains how the subsequent patch was then applied to
something it should never have been applied to. Probably with GNU
patch that doesn't mind the fact that it doesn't match exactly (or
somebody used git and explicitly said "apply it with fuzz").
So that seems to explain how the patch got corrupted.
But nothing explains the fact that clearly _zero_ testing was done.
The tree was clearly never even compiled. Len apparently did a blind
patch application (or rebase, or whatever), and never bothered to
compile the end result afterwards, just sent it to me sight-unseen.
What does that say about the _rest_ of the patches? What does that say
about (lack of) -next testing?
Linus
--
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
