On Thu, Apr 02, 2009 at 03:10:36PM +0200, Thomas Renninger wrote:
> Hi,
>
> I remember a bug (serial device not working)
> related to serial and docking on Lenovo.
> I wonder whether this could be related to this fix.
>
> This one also looks worth adding to stable kernel, at least
> after 2.6.30 does not show regressions for a while.
>
> On Monday 30 March 2009 19:31:06 Witold Szczeponik wrote:
> > Subject: Enable PNPACPI _PSx Support, v3
> >
> >
> > (This is an update to the patch presented earlier in
> > http://lkml.org/lkml/2008/12/8/284, with new error handling.)
> >
> > This patch sets the power of PnP ACPI devices to D0 when they
> > are activated and to D3 when they are disabled. The latter is
> > in correspondence with the ACPI 3.0 specification, whereas the
> > former is added in order to be able to power up a device after
> > it has been previously disabled (or when booting up a system).
> > (As a consequence, the patch makes the PnP ACPI code more ACPI
> > compliant.)
> >
> > Section 6.2.2 of the ACPI Specification (at least versions 1.0b
> > and 3.0a) states: "Prior to running this control method [_DIS],
> > the OS[PM] will have already put the device in the D3 state."
> > Unfortunately, there is no clear statement as to when to put
> > a device in the D0 state. :-( Therefore, the patch executes the
> > method calls as _PS3/_DIS and _SRS/_PS0. What is clear: "If the
> > device is disabled, _SRS enables the device at the specified
> > resources." (From the ACPI 3.0a Specification.)
> >
> > The patch fixes a problem with some IBM ThinkPads (at least the
> > 600E and the 600X) where the serial ports have a dedicated
> > power source that needs to be brought up before the serial port
> > can be used. Without this patch, the serial port is enabled
> > but has no power. (In the past, the tpctl utility had to be
> > utilized to turn on the power, but support for this feature
> > stopped with version 5.9 as it did not support the more recent
> > kernel versions.)
> >
> > The error handlers that handle any errors that can occur during
> > the power up/power down phases return the error codes to the
> > caller directly. Comments welcome! :-)
> >
> > No regressions were observed on hardware that does not require
> > this patch.
> >
> > The patch is applied against 2.6.27.x.
> >
> >
> > Signed-off-by: Witold Szczeponik <[email protected]>
> CC: [email protected]
> ...
What specific git commit id in Linus's tree is this?
thanks,
greg k-h
Greg KH wrote:
[snip]
>
> What specific git commit id in Linus's tree is this?
>
> thanks,
>
> greg k-h
>
Hi Greg,
the git commit id of this patch would be
6328a57401dc5f5cf9931738eb7268fcd8058c49, but the patch triggered a
regression which is described in
http://bugzilla.kernel.org/show_bug.cgi?id=13243 and which was fixed in
19bde778c1fd2574cc020a618d7d576f260271ca.
Hope this helps.
--- Witold
On Tue, Jul 07, 2009 at 10:06:41PM +0200, Witold Szczeponik wrote:
> Greg KH wrote:
>
> [snip]
>
> >
> > What specific git commit id in Linus's tree is this?
> >
> > thanks,
> >
> > greg k-h
> >
>
> Hi Greg,
>
> the git commit id of this patch would be
> 6328a57401dc5f5cf9931738eb7268fcd8058c49, but the patch triggered a
> regression which is described in
> http://bugzilla.kernel.org/show_bug.cgi?id=13243 and which was fixed in
> 19bde778c1fd2574cc020a618d7d576f260271ca.
Ok, I've queued up both of these for the next .27 stable release.
thanks,
greg k-h