<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/acpi, branch v3.13.4</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ACPI / init: Flag use of ACPI and ACPI idioms for power supplies to regulator API</title>
<updated>2014-02-13T21:55:31+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@linaro.org</email>
</author>
<published>2014-01-27T00:32:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d779e5b35cc3ace2b149a6f03acdb5c6efa5a841'/>
<id>d779e5b35cc3ace2b149a6f03acdb5c6efa5a841</id>
<content type='text'>
commit 49a12877d2777cadcb838981c3c4f5a424aef310 upstream.

There is currently no facility in ACPI to express the hookup of voltage
regulators, the expectation is that the regulators that exist in the
system will be handled transparently by firmware if they need software
control at all. This means that if for some reason the regulator API is
enabled on such a system it should assume that any supplies that devices
need are provided by the system at all relevant times without any software
intervention.

Tell the regulator core to make this assumption by calling
regulator_has_full_constraints(). Do this as soon as we know we are using
ACPI so that the information is available to the regulator core as early
as possible. This will cause the regulator core to pretend that there is
an always on regulator supplying any supply that is requested but that has
not otherwise been mapped which is the behaviour expected on a system with
ACPI.

Should the ability to specify regulators be added in future revisions of
ACPI then once we have support for ACPI mappings in the kernel the same
assumptions will apply. It is also likely that systems will default to a
mode of operation which does not require any interpretation of these
mappings in order to be compatible with existing operating system releases
so it should remain safe to make these assumptions even if the mappings
exist but are not supported by the kernel.

Signed-off-by: Mark Brown &lt;broonie@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 49a12877d2777cadcb838981c3c4f5a424aef310 upstream.

There is currently no facility in ACPI to express the hookup of voltage
regulators, the expectation is that the regulators that exist in the
system will be handled transparently by firmware if they need software
control at all. This means that if for some reason the regulator API is
enabled on such a system it should assume that any supplies that devices
need are provided by the system at all relevant times without any software
intervention.

Tell the regulator core to make this assumption by calling
regulator_has_full_constraints(). Do this as soon as we know we are using
ACPI so that the information is available to the regulator core as early
as possible. This will cause the regulator core to pretend that there is
an always on regulator supplying any supply that is requested but that has
not otherwise been mapped which is the behaviour expected on a system with
ACPI.

Should the ability to specify regulators be added in future revisions of
ACPI then once we have support for ACPI mappings in the kernel the same
assumptions will apply. It is also likely that systems will default to a
mode of operation which does not require any interpretation of these
mappings in order to be compatible with existing operating system releases
so it should remain safe to make these assumptions even if the mappings
exist but are not supported by the kernel.

Signed-off-by: Mark Brown &lt;broonie@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs"</title>
<updated>2014-01-18T13:04:58+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2014-01-17T13:23:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2b844ba79f4a114bd228ad6fee040ffd99a0963d'/>
<id>2b844ba79f4a114bd228ad6fee040ffd99a0963d</id>
<content type='text'>
This reverts commit f6308b36c411 (ACPI: Add BayTrail SoC GPIO and LPSS
ACPI IDs), because it causes the Alan Cox' ASUS T100TA to "crash and
burn" during boot if the Baytrail pinctrl driver is compiled in.

Fixes: f6308b36c411 (ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs)
Reported-by: One Thousand Gnomes &lt;gnomes@lxorguk.ukuu.org.uk&gt;
Requested-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit f6308b36c411 (ACPI: Add BayTrail SoC GPIO and LPSS
ACPI IDs), because it causes the Alan Cox' ASUS T100TA to "crash and
burn" during boot if the Baytrail pinctrl driver is compiled in.

Fixes: f6308b36c411 (ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs)
Reported-by: One Thousand Gnomes &lt;gnomes@lxorguk.ukuu.org.uk&gt;
Requested-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branches 'acpi-battery' and 'pm-cpufreq'</title>
<updated>2014-01-06T21:49:08+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2014-01-06T21:49:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=77410baf453e271680e919145b8b377a42a54e91'/>
<id>77410baf453e271680e919145b8b377a42a54e91</id>
<content type='text'>
* acpi-battery:
  ACPI / Battery: Add a _BIX quirk for NEC LZ750/LS

* pm-cpufreq:
  intel_pstate: Add X86_FEATURE_APERFMPERF to cpu match parameters.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* acpi-battery:
  ACPI / Battery: Add a _BIX quirk for NEC LZ750/LS

* pm-cpufreq:
  intel_pstate: Add X86_FEATURE_APERFMPERF to cpu match parameters.
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / Battery: Add a _BIX quirk for NEC LZ750/LS</title>
<updated>2014-01-06T21:28:57+00:00</updated>
<author>
<name>Lan Tianyu</name>
<email>tianyu.lan@intel.com</email>
</author>
<published>2014-01-06T14:50:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a90b40385735af0d3031f98e97b439e8944a31b3'/>
<id>a90b40385735af0d3031f98e97b439e8944a31b3</id>
<content type='text'>
The AML method _BIX of NEC LZ750/LS returns a broken package which
skips the first member "Revision" (ACPI 5.0, Table 10-234).

Add a quirk for this machine to skip member "Revision" during parsing
the package returned by _BIX.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=67351
Reported-and-tested-by: Francisco Castro &lt;fcr@adinet.com.uy&gt;
Cc: 3.8+ &lt;stable@vger.kernel.org&gt; " 3.8+
Signed-off-by: Lan Tianyu &lt;tianyu.lan@intel.com&gt;
Reviewed-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The AML method _BIX of NEC LZ750/LS returns a broken package which
skips the first member "Revision" (ACPI 5.0, Table 10-234).

Add a quirk for this machine to skip member "Revision" during parsing
the package returned by _BIX.

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=67351
Reported-and-tested-by: Francisco Castro &lt;fcr@adinet.com.uy&gt;
Cc: 3.8+ &lt;stable@vger.kernel.org&gt; " 3.8+
Signed-off-by: Lan Tianyu &lt;tianyu.lan@intel.com&gt;
Reviewed-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPI / AC: change notification handler type to ACPI_ALL_NOTIFY</title>
<updated>2014-01-05T14:42:42+00:00</updated>
<author>
<name>Alexander Mezin</name>
<email>mezin.alexander@gmail.com</email>
</author>
<published>2014-01-04T02:07:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=50a2bc5429f07ec4d53df2d287b03bdbceb281bb'/>
<id>50a2bc5429f07ec4d53df2d287b03bdbceb281bb</id>
<content type='text'>
With kernel 3.13rc5 there are no AC adapter notifications on my laptop.

Commit cc8ef5270734 "ACPI / AC: convert ACPI ac driver to platform bus"
changed the driver to listen to device notifications only. However, AML
code on my laptop notifies the driver with zero event.

This patch changes the driver to listen to all events again.

Fixes: cc8ef5270734 (ACPI / AC: convert ACPI ac driver to platform bus)
References: https://bugzilla.kernel.org/show_bug.cgi?id=67821
Signed-off-by: Alexander Mezin &lt;mezin.alexander@gmail.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With kernel 3.13rc5 there are no AC adapter notifications on my laptop.

Commit cc8ef5270734 "ACPI / AC: convert ACPI ac driver to platform bus"
changed the driver to listen to device notifications only. However, AML
code on my laptop notifies the driver with zero event.

This patch changes the driver to listen to all events again.

Fixes: cc8ef5270734 (ACPI / AC: convert ACPI ac driver to platform bus)
References: https://bugzilla.kernel.org/show_bug.cgi?id=67821
Signed-off-by: Alexander Mezin &lt;mezin.alexander@gmail.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branches 'acpi-pci-pm' and 'acpi-pci-hotplug'</title>
<updated>2013-12-31T21:03:37+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2013-12-31T21:03:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4706515a9284d8bcef4dab53e4568c38a02a09c7'/>
<id>4706515a9284d8bcef4dab53e4568c38a02a09c7</id>
<content type='text'>
* acpi-pci-pm:
  PCI / ACPI: Install wakeup notify handlers for all PCI devs with ACPI

* acpi-pci-hotplug:
  ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug
  ACPI / PCI / hotplug: Avoid warning when _ADR not present
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* acpi-pci-pm:
  PCI / ACPI: Install wakeup notify handlers for all PCI devs with ACPI

* acpi-pci-hotplug:
  ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug
  ACPI / PCI / hotplug: Avoid warning when _ADR not present
</pre>
</div>
</content>
</entry>
<entry>
<title>ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug</title>
<updated>2013-12-31T12:39:42+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2013-12-31T12:39:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f244d8b623dae7a7bc695b0336f67729b95a9736'/>
<id>f244d8b623dae7a7bc695b0336f67729b95a9736</id>
<content type='text'>
The changes in the ACPI-based PCI hotplug (ACPIPHP) subsystem made
during the 3.12 development cycle uncovered a problem with VGA
switcheroo that on some systems, when the device-specific method
(ATPX in the radeon case, _DSM in the nouveau case) is used to turn
off the discrete graphics, the BIOS generates ACPI hotplug events for
that device and those events cause ACPIPHP to attempt to remove the
device from the system (they are events for a device that was present
previously and is not present any more, so that's what should be done
according to the spec).  Then, the system stops functioning correctly.

Since the hotplug events in question were simply silently ignored
previously, the least intrusive way to address that problem is to
make ACPIPHP ignore them again.  For this purpose, introduce a new
ACPI device flag, no_hotplug, and modify ACPIPHP to ignore hotplug
events for PCI devices whose ACPI companions have that flag set.
Next, make the radeon and nouveau switcheroo detection code set the
no_hotplug flag for the discrete graphics' ACPI companion.

Fixes: bbd34fcdd1b2 (ACPI / hotplug / PCI: Register all devices under the given bridge)
References: https://bugzilla.kernel.org/show_bug.cgi?id=61891
References: https://bugzilla.kernel.org/show_bug.cgi?id=64891
Reported-and-tested-by: Mike Lothian &lt;mike@fireburn.co.uk&gt;
Reported-and-tested-by: &lt;madcatx@atlas.cz&gt;
Reported-and-tested-by: Joaquín Aramendía &lt;samsagax@gmail.com&gt;
Cc: Alex Deucher &lt;alexdeucher@gmail.com&gt;
Cc: Dave Airlie &lt;airlied@linux.ie&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Cc: 3.12+ &lt;stable@vger.kernel.org&gt; # 3.12+
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The changes in the ACPI-based PCI hotplug (ACPIPHP) subsystem made
during the 3.12 development cycle uncovered a problem with VGA
switcheroo that on some systems, when the device-specific method
(ATPX in the radeon case, _DSM in the nouveau case) is used to turn
off the discrete graphics, the BIOS generates ACPI hotplug events for
that device and those events cause ACPIPHP to attempt to remove the
device from the system (they are events for a device that was present
previously and is not present any more, so that's what should be done
according to the spec).  Then, the system stops functioning correctly.

Since the hotplug events in question were simply silently ignored
previously, the least intrusive way to address that problem is to
make ACPIPHP ignore them again.  For this purpose, introduce a new
ACPI device flag, no_hotplug, and modify ACPIPHP to ignore hotplug
events for PCI devices whose ACPI companions have that flag set.
Next, make the radeon and nouveau switcheroo detection code set the
no_hotplug flag for the discrete graphics' ACPI companion.

Fixes: bbd34fcdd1b2 (ACPI / hotplug / PCI: Register all devices under the given bridge)
References: https://bugzilla.kernel.org/show_bug.cgi?id=61891
References: https://bugzilla.kernel.org/show_bug.cgi?id=64891
Reported-and-tested-by: Mike Lothian &lt;mike@fireburn.co.uk&gt;
Reported-and-tested-by: &lt;madcatx@atlas.cz&gt;
Reported-and-tested-by: Joaquín Aramendía &lt;samsagax@gmail.com&gt;
Cc: Alex Deucher &lt;alexdeucher@gmail.com&gt;
Cc: Dave Airlie &lt;airlied@linux.ie&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Cc: 3.12+ &lt;stable@vger.kernel.org&gt; # 3.12+
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2013-12-29T21:35:04+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2013-12-29T21:35:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8cf126d92791381632818df862fdbc89ab6f7572'/>
<id>8cf126d92791381632818df862fdbc89ab6f7572</id>
<content type='text'>
Pull x86 fixes from Peter Anvin:
 "There is a small EFI fix and a big power regression fix in this batch.

  My queue also had a fix for downing a CPU when there are insufficient
  number of IRQ vectors available, but I'm holding that one for now due
  to recent bug reports"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/efi: Don't select EFI from certain special ACPI drivers
  x86 idle: Repair large-server 50-watt idle-power regression
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull x86 fixes from Peter Anvin:
 "There is a small EFI fix and a big power regression fix in this batch.

  My queue also had a fix for downing a CPU when there are insufficient
  number of IRQ vectors available, but I'm holding that one for now due
  to recent bug reports"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/efi: Don't select EFI from certain special ACPI drivers
  x86 idle: Repair large-server 50-watt idle-power regression
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branches 'powercap' and 'acpi-lpss' with new device IDs</title>
<updated>2013-12-26T23:43:24+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2013-12-26T23:43:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bfde19c4c2467cbcb5c11ec0fdaa771b8c16cbce'/>
<id>bfde19c4c2467cbcb5c11ec0fdaa771b8c16cbce</id>
<content type='text'>
* powercap:
  powercap / RAPL: add support for ValleyView Soc

* acpi-lpss:
  ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* powercap:
  powercap / RAPL: add support for ValleyView Soc

* acpi-lpss:
  ACPI: Add BayTrail SoC GPIO and LPSS ACPI IDs
</pre>
</div>
</content>
</entry>
<entry>
<title>pstore: Don't allow high traffic options on fragile devices</title>
<updated>2013-12-20T21:12:01+00:00</updated>
<author>
<name>Luck, Tony</name>
<email>tony.luck@intel.com</email>
</author>
<published>2013-12-18T23:17:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=df36ac1bc2a166eef90785d584e4cfed6f52bd32'/>
<id>df36ac1bc2a166eef90785d584e4cfed6f52bd32</id>
<content type='text'>
Some pstore backing devices use on board flash as persistent
storage. These have limited numbers of write cycles so it
is a poor idea to use them from high frequency operations.

Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some pstore backing devices use on board flash as persistent
storage. These have limited numbers of write cycles so it
is a poor idea to use them from high frequency operations.

Signed-off-by: Tony Luck &lt;tony.luck@intel.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
