Re: fix u32 vs. pm_message_t in usb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday 05 April 2005 2:38 pm, Pavel Machek wrote:
> It seems to me that USB stack still needs some u32-vs-pm_message_t
> changes (in rc2-mm1):
> 
> Could you apply them?

I see someone changed the requirements for platform_device too ... :)

This patch is mostly NOPs, but many of them tromp on other patches I have
in the works.  So I'd rather hold off for now, using the rest of the
2.6.12-rc series for only real honest-to-gosh bugfixes.  (Isn't that
supposed to be the current goal, in any case?)

Something that's not exactly a NOP:

> --- clean-mm/drivers/usb/host/ohci-omap.c	2005-04-05 10:55:21.000000000 +0200
> +++ linux-mm/drivers/usb/host/ohci-omap.c	2005-04-05 12:13:38.000000000 +0200
> @@ -458,9 +458,11 @@
>  
>  /* states match PCI usage, always suspending the root hub except that
>   * 4 ~= D3cold (ACPI D3) with clock off (resume sees reset).
> + *
> + * FIXME: above comment is not right, and code is wrong, too :-(.

The comment is exactly right, and matches the code.  Has done so for
most of a year now, in fact.

What's wrong is the way that the pm_message_t changes have discarded
functionality ... including, as a specific example, the ability for
drivers to do the right thing based on what kind of suspend state
they're entering.  (Because pm_message_t is effectively a boolean,
rather than a something that's multi-valued.)

I'll repeat myself again, at the risk of being redundant:  we need
to actually fix this pm_message_t thing to _work_ rather than paper
over its botches by discarding functionality.

- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux