Re: [PATCH 1/9] libata: separate out ata_dev_reread_id()
Tejun Heo wrote: Separate out ata_dev_reread_id() from ata_dev_revalidate(). ata_dev_reread_id() reads IDENTIFY page and determines whether the same device is still there. ata_dev_revalidate() reconfigures after reread completes. This will be used by ACPI update. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/libata-core.c | 47 drivers/ata/libata.h |3 +- 2 files changed, 36 insertions(+), 14 deletions(-) applied 1-3 to #upstream-fixes - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Re: Linux 2.6.22-rc1
On Tue, May 15, 2007 at 10:46:21AM -0700, Randy Dunlap wrote: > On Wed, 16 May 2007 00:42:08 +0900 Mattia Dongili wrote: ... > > Given the drivers/acpi/Kconfig portion > > > > if ACPI > > ... > > config ACPI_EC > > bool > > default y > > help > > ... > > > > config ACPI_POWER > > bool > > default y > > > > config ACPI_SYSTEM > > bool > > default y > > help > > ... > > ... > > endif > > > > I'd expect the 3 symbols to be all set when CONFIG_ACPI=y. > > What am I overseeing? > > I think that this is just 'make randconfig' throwing a curve ball. > ACPI depends on PM, but PM=n. In my experience, randconfig is a > good tool for testing oddball configs, but the results are not > always something that is fixable or needs to be fixed. It looks like Kconfig does the right thing on i386 though. Not the same on x84_64. -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ACPI: Remove possible recursion from thermal driver
Please read the spec 11.1.2 and 11.1.2.3. Trip points change _only_ to create a hysteresis loop, not by themselves. This means that we will get 0x81 type _only_ in response to us changing active state, the moment then we have temperature and just decided to move away from this trip point, not closer to it. If the temperature change, we get another event, 0x80, and _then_ we do thermal_check()... Regards, Alex. On 5/16/07, Len Brown <[EMAIL PROTECTED]> wrote: > --- a/drivers/acpi/thermal.c > +++ b/drivers/acpi/thermal.c > @@ -1106,7 +1106,6 @@ static void acpi_thermal_notify(acpi_handle handle, u32 event, void *data) > break; > case ACPI_THERMAL_NOTIFY_THRESHOLDS: > acpi_thermal_get_trip_points(tz); >- acpi_thermal_check(tz); > acpi_bus_generate_event(device, event, 0); > break; > case ACPI_THERMAL_NOTIFY_DEVICES: I don't think we can do this. When the thresholds change, there must be a check to compare the temperature with the thresholds -- otherwise what good was it to change the thresholds? -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ACPI: Remove possible recursion from thermal driver
> --- a/drivers/acpi/thermal.c > +++ b/drivers/acpi/thermal.c > @@ -1106,7 +1106,6 @@ static void acpi_thermal_notify(acpi_handle handle, u32 > event, void *data) > break; > case ACPI_THERMAL_NOTIFY_THRESHOLDS: > acpi_thermal_get_trip_points(tz); >- acpi_thermal_check(tz); > acpi_bus_generate_event(device, event, 0); > break; > case ACPI_THERMAL_NOTIFY_DEVICES: I don't think we can do this. When the thresholds change, there must be a check to compare the temperature with the thresholds -- otherwise what good was it to change the thresholds? -Len - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[solved] 2.6.21 -- polling /proc/acpi/battery/*/state breaks ibm_acpi
On Tue, May 15, 2007 at 12:04:25AM -0300, Henrique de Moraes Holschuh wrote: > On Mon, 14 May 2007, Andreas Messer wrote: > > Up to Kernel 2.6.20 ibm_acpi was working fine on my TP X21. > > At least all Fn + Keys worked. Now, since 2.6.21 it generally > > works but: When some Application is polling /proc/acpi/battery/*/state, > > the Fn - Keys (and perhaps the Lid-Button) became disfunctional until > > the next reboot. (Terminating the App didn't help) > > Are you using the latest BIOS and EC firmware for the X21? > Thanks, that was the solution. Now everything working fine. greetings Andreas -- gnuPG keyid: 8C2BAF51 fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51 signature.asc Description: Digital signature
Fix section conflict of acpi_rs_match_vendor_resource
Building with GCC 4.2, I get the following error:
CC drivers/acpi/resources/rsxface.o
drivers/acpi/resources/rsxface.c:479: error:
__ksymtab_acpi_rs_match_vendor_resource causes a section type conflict
This is because acpi_rs_match_vendor_resource is both declared static
and exported.
Signed-off-by: Martin Michlmayr <[EMAIL PROTECTED]>
--- a/drivers/acpi/resources/rsxface.c
+++ b/drivers/acpi/resources/rsxface.c
@@ -64,7 +64,7 @@ ACPI_MODULE_NAME("rsxface")
ACPI_COPY_FIELD(out, in, address_length);\
ACPI_COPY_FIELD(out, in, resource_source);
/* Local prototypes */
-static acpi_status
+acpi_status
acpi_rs_match_vendor_resource(struct acpi_resource *resource, void *context);
static acpi_status
@@ -428,7 +428,7 @@ ACPI_EXPORT_SYMBOL(acpi_get_vendor_resource)
* DESCRIPTION: Match a vendor resource via the ACPI 3.0 UUID
*
**/
-static acpi_status
+acpi_status
acpi_rs_match_vendor_resource(struct acpi_resource *resource, void *context)
{
struct acpi_vendor_walk_info *info = context;
--
Martin Michlmayr
http://www.cyrius.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Re: Linux 2.6.22-rc1
On Wed, 16 May 2007 00:42:08 +0900 Mattia Dongili wrote: > On Mon, May 14, 2007 at 10:45:46AM -0700, Randy Dunlap wrote: > > On Mon, 14 May 2007 07:49:31 +0200 (MEST) Jan Engelhardt wrote: > > > > > > > > On May 14 2007 10:55, Mattia Dongili wrote: > > > >On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote: > > > >> On May 12 2007 20:20, Linus Torvalds wrote: > > > >> > > > > >> >Ok, the merge window has closed, and 2.6.22-rc1 is out there. > > > >> > > > >> I have hit a randconfig compile failure. .config attached. > > > >> > > > >> LD .tmp_vmlinux1 > > > >> drivers/built-in.o: In function `acpi_bus_generate_event': > > > >> (.text+0x233f7): undefined reference to `event_is_open' > > > >> drivers/built-in.o: In function `acpi_bus_get_power': > > > >> (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state' > > > >> drivers/built-in.o: In function `acpi_bus_set_power': > > > >> (.text+0x237c3): undefined reference to `acpi_power_transition' > > > >> drivers/built-in.o: In function `acpi_bus_set_power': > > > >> (.text+0x23835): undefined reference to `acpi_power_transition' > > > >> drivers/built-in.o: In function `sony_pic_fanspeed_store': > > > >> sony-laptop.c:(.text+0x91930): undefined reference to `ec_write' > > > >> drivers/built-in.o: In function `sony_pic_fanspeed_show': > > > >> sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read' > > > >> make: *** [.tmp_vmlinux1] Error 1 > > > > > > > >I actually can't reproduce it with your .config. > > > > > > But I can. Did you try it on x86_64? From 2.6.22-rc1 [ > > > commit 39403865d2e4590802553370a56c9ab93131e4ee in /linux-2.6.git] ? > > > > > > bzip2 -cd randconfig-1.bz2 >.config > > > make -j8 > > > > Yes, build easily fails for me also. > > ok, as far as sony-laptop is concerned a dependency on ACPI_EC suffices > to fix the link failure, but I guess that would just hide the real > issue. > IOW: why does ACPI_EC, ACPI_SYSTEM and ACPI_POWER are not set when the > ACPI symbol is? > > Given the drivers/acpi/Kconfig portion > > if ACPI > ... > config ACPI_EC > bool > default y > help > ... > > config ACPI_POWER > bool > default y > > config ACPI_SYSTEM > bool > default y > help > ... > ... > endif > > I'd expect the 3 symbols to be all set when CONFIG_ACPI=y. > What am I overseeing? I think that this is just 'make randconfig' throwing a curve ball. ACPI depends on PM, but PM=n. In my experience, randconfig is a good tool for testing oddball configs, but the results are not always something that is fixable or needs to be fixed. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Re: Linux 2.6.22-rc1
On Mon, May 14, 2007 at 10:45:46AM -0700, Randy Dunlap wrote: > On Mon, 14 May 2007 07:49:31 +0200 (MEST) Jan Engelhardt wrote: > > > > > On May 14 2007 10:55, Mattia Dongili wrote: > > >On Sun, May 13, 2007 at 11:27:31AM +0200, Jan Engelhardt wrote: > > >> On May 12 2007 20:20, Linus Torvalds wrote: > > >> > > > >> >Ok, the merge window has closed, and 2.6.22-rc1 is out there. > > >> > > >> I have hit a randconfig compile failure. .config attached. > > >> > > >> LD .tmp_vmlinux1 > > >> drivers/built-in.o: In function `acpi_bus_generate_event': > > >> (.text+0x233f7): undefined reference to `event_is_open' > > >> drivers/built-in.o: In function `acpi_bus_get_power': > > >> (.text+0x236ad): undefined reference to `acpi_power_get_inferred_state' > > >> drivers/built-in.o: In function `acpi_bus_set_power': > > >> (.text+0x237c3): undefined reference to `acpi_power_transition' > > >> drivers/built-in.o: In function `acpi_bus_set_power': > > >> (.text+0x23835): undefined reference to `acpi_power_transition' > > >> drivers/built-in.o: In function `sony_pic_fanspeed_store': > > >> sony-laptop.c:(.text+0x91930): undefined reference to `ec_write' > > >> drivers/built-in.o: In function `sony_pic_fanspeed_show': > > >> sony-laptop.c:(.text+0x9195d): undefined reference to `ec_read' > > >> make: *** [.tmp_vmlinux1] Error 1 > > > > > >I actually can't reproduce it with your .config. > > > > But I can. Did you try it on x86_64? From 2.6.22-rc1 [ > > commit 39403865d2e4590802553370a56c9ab93131e4ee in /linux-2.6.git] ? > > > > bzip2 -cd randconfig-1.bz2 >.config > > make -j8 > > Yes, build easily fails for me also. ok, as far as sony-laptop is concerned a dependency on ACPI_EC suffices to fix the link failure, but I guess that would just hide the real issue. IOW: why does ACPI_EC, ACPI_SYSTEM and ACPI_POWER are not set when the ACPI symbol is? Given the drivers/acpi/Kconfig portion if ACPI ... config ACPI_EC bool default y help ... config ACPI_POWER bool default y config ACPI_SYSTEM bool default y help ... ... endif I'd expect the 3 symbols to be all set when CONFIG_ACPI=y. What am I overseeing? -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
