Greg KH | 1 Jul 2009 01:03
Gravatar

Re: [stable] [PATCH] PNPACPI: Enable PNPACPI _PSx Support, v3

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
(Continue reading)

Bjorn Helgaas | 1 Jul 2009 01:11
Picon
Favicon

Re: [PATCH 1/2] ACPI: reintroduce acpi_device_ops .shutdown method

On Tuesday 30 June 2009 3:10:47 pm Andrew Morton wrote:
> On Sat, 27 Jun 2009 07:18:31 +0200
> David H__rdeman <david <at> hardeman.nu> wrote:
> 
> > This reintroduces the .shutdown method which is used by the
> > winbond-cir driver. A normal revert wasn't possible since there
> > had been other changes to include/acpi/acpi_bus.h since.
> > 
> > Signed-off-by: David H__rdeman <david <at> hardeman.nu>
> > ---
> >  drivers/acpi/scan.c     |   12 ++++++++++++
> >  include/acpi/acpi_bus.h |    2 ++
> >  2 files changed, 14 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> > index 781435d..c94ab13 100644
> > --- a/drivers/acpi/scan.c
> > +++ b/drivers/acpi/scan.c
> >  <at>  <at>  -464,10 +464,22  <at>  <at>  static int acpi_device_remove(struct device * dev)
> >  	return 0;
> >  }
> >  
> > +static void acpi_device_shutdown(struct device *dev)
> > +{
> > +	struct acpi_device *acpi_dev = to_acpi_device(dev);
> > +	struct acpi_driver *acpi_drv = acpi_dev->driver;
> > +
> > +	if (acpi_drv && acpi_drv->ops.shutdown)
> > +		acpi_drv->ops.shutdown(acpi_dev);
> > +
(Continue reading)

Lin Ming | 1 Jul 2009 04:29
Picon
Favicon

[PATCH] ACPICA: Revert "ACPICA: Remove obsolete acpi_os_validate_address interface"

    Revert "ACPICA: Remove obsolete acpi_os_validate_address interface"

    This reverts commit f9ca058430333c9a24c5ca926aa445125f88df18.

    The quick fix of bug 13620 would be to revert the change.
    http://bugzilla.kernel.org/show_bug.cgi?id=13620

    Also, see the commit df92e695998e1bc6e426a840eb86d6d1ee87e2a5
    "ACPI: track opregion names to avoid driver resource conflicts."

    But there are problems we need to address:

    1. We need to enhance the mechanism of avoiding driver resource conflicts
       to base a "resource" on Field definitions instead of Operation Region definitions.

    2. For dynamic region, we need an interface to call when an operation region (field) is deleted,
       in order to delete it from the resource list.

    3. If the same region is created and added to resource list over and over again,
       this is have the potential to be a memory leak by growing the list every time

    CC: Thomas Renninger <trenn <at> suse.de>
    Signed-off-by: Lin Ming <ming.m.lin <at> intel.com>
    Signed-off-by: Zhao Yakui <yakui.zhao <at> intel.com>
---
 drivers/acpi/acpica/acobject.h |    1 +
 drivers/acpi/acpica/dsopcode.c |   24 ++++++++++++++++++++++++
 drivers/acpi/acpica/exfldio.c  |    6 ++++++
 include/acpi/acpiosxf.h        |    4 ++++
 4 files changed, 35 insertions(+), 0 deletions(-)
(Continue reading)

David Härdeman | 1 Jul 2009 09:47
Picon

Re: [PATCH 2/2] Add a driver for the Winbond WPCD376I IR functionality.

On Tue, June 30, 2009 23:23, Andrew Morton wrote:
> On Sat, 27 Jun 2009 07:18:32 +0200
> David Härdeman <david <at> hardeman.nu> wrote:
>> +static void
>> +wbcir_set_bits(unsigned long addr, u8 bits, u8 mask)
>> +{
>> +	u8 val;
>> +
>> +	val = inb(addr);
>> +	val = ((val & ~mask) | (bits & mask));
>> +	outb(val, addr);
>> +}
>
> What locking prevents the races which could occur here?
>
> Whatever it is, it would be good to document that here in a code
> comment.

I should probably clarify the comment in "struct wbcir_data" to mention
that wbcir_lock is supposed to protect registers against race conditions.

>>
>> ...
>>
>> +static u8
>> +wbcir_revbyte(u8 byte)
>> +{
>> +	byte = ((byte >> 1) & 0x55) | ((byte << 1) & 0xAA);
>> +	byte = ((byte >> 2) & 0x33) | ((byte << 2) & 0xCC);
>> +	return (byte >> 4) | (byte<<4);
(Continue reading)

David Härdeman | 1 Jul 2009 10:20
Picon

Re: [PATCH 1/2] ACPI: reintroduce acpi_device_ops .shutdown method

On Wed, July 1, 2009 01:11, Bjorn Helgaas wrote:
> On Tuesday 30 June 2009 3:10:47 pm Andrew Morton wrote:
>> On Sat, 27 Jun 2009 07:18:31 +0200
>> David Härdeman <david <at> hardeman.nu> wrote:
>>>
>>> This reintroduces the .shutdown method which is used by the
>>> winbond-cir driver. A normal revert wasn't possible since there
>>> had been other changes to include/acpi/acpi_bus.h since.
>>
>> Len, Bjorn: is this OK?  Or is there some other mechanism which the
>> driver should have used?
>
> I'm on vacation and don't have time to read the new winbond driver
> right now, but maybe it could be changed so that wbcir_shutdown()
> is an internal function called by wbcir_suspend() (as it is already)
> and wbcir_remove().

I didn't want to call wbcir_shutdown from wbcir_remove since wbcir_remove
is called on rmmod and the wbcir_shutdown method programs the chip so that
wake-on-a-specific-ir-command is enabled (and I imagine that people would
expect rmmod to disable the hardware completely). I will clarify the
function names a bit in the next version of the patch...

As far as I could understand from my testing, the acpi .suspend method is
not called during shutdown which is why I needed to hook into both
.suspend and .shutdown separately.

> I hate to re-introduce .shutdown when it's only used by a single
> driver.  That makes me think either we have a bunch of drivers that
> are buggy because they *should* have .shutdown methods but don't,
(Continue reading)

Thomas Renninger | 1 Jul 2009 10:56
Picon

Re: [PATCH] ACPICA: Revert "ACPICA: Remove obsolete acpi_os_validate_address interface"

Hi Lin,

thanks for adding me.
This is not "that" sever, but IMO this one should also be submitted
to 2.6.30 stable kernels as it is a riskless revert of a patch
fixing a regression.

On Wednesday 01 July 2009 04:29:51 Lin Ming wrote:
>     Revert "ACPICA: Remove obsolete acpi_os_validate_address interface"
>     
>     This reverts commit f9ca058430333c9a24c5ca926aa445125f88df18.
>     
>     The quick fix of bug 13620 would be to revert the change.
>     http://bugzilla.kernel.org/show_bug.cgi?id=13620
>     
>     Also, see the commit df92e695998e1bc6e426a840eb86d6d1ee87e2a5
>     "ACPI: track opregion names to avoid driver resource conflicts."
>     
>     But there are problems we need to address:
>     
>     1. We need to enhance the mechanism of avoiding driver resource
>     conflicts
>        to base a "resource" on Field definitions instead of Operation Region
>        definitions.
Good idea, this could avoid some false positive detected region conflicts.
>     
>     2. For dynamic region, we need an interface to call when an operation
>     region (field) is deleted,
>        in order to delete it from the resource list.
>     
(Continue reading)

Lin Ming | 1 Jul 2009 11:23
Picon
Favicon

Re: [PATCH] ACPICA: Revert "ACPICA: Remove obsolete acpi_os_validate_address interface"

On Wed, 2009-07-01 at 16:56 +0800, Thomas Renninger wrote:
> Hi Lin,
> 
> thanks for adding me.
> This is not "that" sever, but IMO this one should also be submitted
> to 2.6.30 stable kernels as it is a riskless revert of a patch
> fixing a regression.
> 
> On Wednesday 01 July 2009 04:29:51 Lin Ming wrote:
> >     Revert "ACPICA: Remove obsolete acpi_os_validate_address interface"
> >     
> >     This reverts commit f9ca058430333c9a24c5ca926aa445125f88df18.
> >     
> >     The quick fix of bug 13620 would be to revert the change.
> >     http://bugzilla.kernel.org/show_bug.cgi?id=13620
> >     
> >     Also, see the commit df92e695998e1bc6e426a840eb86d6d1ee87e2a5
> >     "ACPI: track opregion names to avoid driver resource conflicts."
> >     
> >     But there are problems we need to address:
> >     
> >     1. We need to enhance the mechanism of avoiding driver resource
> >     conflicts
> >        to base a "resource" on Field definitions instead of Operation Region
> >        definitions.
> Good idea, this could avoid some false positive detected region conflicts.
> >     
> >     2. For dynamic region, we need an interface to call when an operation
> >     region (field) is deleted,
> >        in order to delete it from the resource list.
(Continue reading)

Thomas Renninger | 1 Jul 2009 11:35
Picon

Re: [PATCH] ACPICA: Revert "ACPICA: Remove obsolete acpi_os_validate_address interface"

On Wednesday 01 July 2009 11:23:38 Lin Ming wrote:
> On Wed, 2009-07-01 at 16:56 +0800, Thomas Renninger wrote:
> > Hi Lin,
> > 
> > thanks for adding me.
> > This is not "that" sever, but IMO this one should also be submitted
> > to 2.6.30 stable kernels as it is a riskless revert of a patch
> > fixing a regression.
> > 
> > On Wednesday 01 July 2009 04:29:51 Lin Ming wrote:
> > >     Revert "ACPICA: Remove obsolete acpi_os_validate_address interface"
> > >     
> > >     This reverts commit f9ca058430333c9a24c5ca926aa445125f88df18.
> > >     
> > >     The quick fix of bug 13620 would be to revert the change.
> > >     http://bugzilla.kernel.org/show_bug.cgi?id=13620
> > >     
> > >     Also, see the commit df92e695998e1bc6e426a840eb86d6d1ee87e2a5
> > >     "ACPI: track opregion names to avoid driver resource conflicts."
> > >     
> > >     But there are problems we need to address:
> > >     
> > >     1. We need to enhance the mechanism of avoiding driver resource
> > >     conflicts
> > >        to base a "resource" on Field definitions instead of Operation 
Region
> > >        definitions.
> > Good idea, this could avoid some false positive detected region conflicts.
> > >     
> > >     2. For dynamic region, we need an interface to call when an 
(Continue reading)

Moore, Robert | 1 Jul 2009 17:29
Picon
Favicon
Gravatar

RE: [PATCH] ACPICA: Revert "ACPICA: Remove obsolete acpi_os_validate_address interface"


>-----Original Message-----
>From: Thomas Renninger [mailto:trenn <at> suse.de]
>Sent: Wednesday, July 01, 2009 2:35 AM
>To: Lin, Ming M
>Cc: Len Brown; Moore, Robert; Zhao, Yakui; linux-acpi
>Subject: Re: [PATCH] ACPICA: Revert "ACPICA: Remove obsolete
>acpi_os_validate_address interface"
>
>On Wednesday 01 July 2009 11:23:38 Lin Ming wrote:
>> On Wed, 2009-07-01 at 16:56 +0800, Thomas Renninger wrote:
>> > Hi Lin,
>> >
>> > thanks for adding me.
>> > This is not "that" sever, but IMO this one should also be submitted
>> > to 2.6.30 stable kernels as it is a riskless revert of a patch
>> > fixing a regression.
>> >
>> > On Wednesday 01 July 2009 04:29:51 Lin Ming wrote:
>> > >     Revert "ACPICA: Remove obsolete acpi_os_validate_address
>interface"
>> > >
>> > >     This reverts commit f9ca058430333c9a24c5ca926aa445125f88df18.
>> > >
>> > >     The quick fix of bug 13620 would be to revert the change.
>> > >     http://bugzilla.kernel.org/show_bug.cgi?id=13620
>> > >
>> > >     Also, see the commit df92e695998e1bc6e426a840eb86d6d1ee87e2a5
>> > >     "ACPI: track opregion names to avoid driver resource conflicts."
>> > >
(Continue reading)

Alan Stern | 1 Jul 2009 17:35
Picon
Favicon

Re: [RFC] Run-time PM framework (was: Re: [patch update] PM: Introduce core framework for run-time PM of I/O devices (rev. 6))

On Wed, 1 Jul 2009, Rafael J. Wysocki wrote:

> On Tuesday 30 June 2009, Alan Stern wrote:
> ... 
> > That's enough to give you the general idea.  I think this design is 
> > a lot cleaner than the current one.
> 
> Well, I'm not really happy with starting over, but if you think we should do
> that, then let's do it.

It's not a complete restart.  Much of the existing interface and quite
a bit of code would remain the same.

> I think we both agree that the callbacks, ->runtime_idle(), ->runtime_suspend()
> and ->runtime_resume() make sense.  Now, the role of the framework, IMO, is to
> provide a mechanism by which it is possible:
> (1) to schedule a delayed execution of ->runtime_suspend(), possibly from
>     interrupt context,
> (2) to schedule execution of ->runtime_resume() or ->runtime_idle(), possibly
>     from interrupt context,
> (3) to execute ->runtime_suspend() or ->runtime_resume() directly in a
>     synchronous way (I'm not sure about ->runtime_idle())

Yes, runtime_idle also, for drivers that require minimal overhead.

> _and_ to ensure that these callbacks will be executed when it makes sense.

Thus if the situation changes before the callback can be made, so that
it no longer makes sense, the framework should cancel the callback.

(Continue reading)


Gmane