void devm_backlight_device_unregister(struct
> device *dev,
> struct backlight_device *bd);
> extern void backlight_force_update(struct backlight_device *bd,
> enum backlight_update_reason reason);
> +extern bool back
return false;
If I'm not mistaken, this will introduce a regression for the people who have
problems with the native i915 backlight on Win8-compatible systems. I'd prefer
to avoid that at this point.
> + return acpi_video_backlight_support();
> +}
> +EXPORT_SYMBOL(
On Thursday, October 10, 2013 08:54:29 AM Aaron Lu wrote:
> On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
> > On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
> >> Introduce a new API for modules to query if a specific type of backlight
> >> device has been
On Thursday, October 10, 2013 09:02:55 AM Aaron Lu wrote:
> On 10/10/2013 08:29 AM, Rafael J. Wysocki wrote:
> > On Tuesday, October 08, 2013 02:40:00 PM Aaron Lu wrote:
> >> According to Matthew Garrett, "Windows 8 leaves backlight control up
> >> to individual gra
On Saturday, October 12, 2013 07:54:06 AM Yves-Alexis Perez wrote:
> On sam., 2013-10-12 at 01:27 +0200, Rafael J. Wysocki wrote:
> > If we are to use a Kconfig option, why don't we use one instead of rather
> > than
> > in addition to a command
oblems causing
video.use_native_backlight=1 to fail of the systems where it fails and then
we'll be able to make that the default behavior and drop the option altogether.
Thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wednesday, December 04, 2013 02:54:07 AM Matthew Garrett wrote:
> On Tue, Dec 03, 2013 at 06:44:52PM -0800, David E. Box wrote:
> > On Wed, Dec 04, 2013 at 02:21:30AM +, Matthew Garrett wrote:
> > > Well sure, but why do you need to be a platform device at all? This
> > > functionality was
#define IOSF_MBI_PCIE_WRITE 0x01
> +
> +/**
> + * iosf_mbi_read() - IOSF MailBox Interface read command
> + * @port:port indicating subunit being accessed
> + * @opcode: port specific read or write opcode
> + * @offset: register address offset
> + *
> + * Locking is han
s driver is disallowed to avoid conflicts.
>
> Signed-off-by: David E. Box
Matthew, if you're going to take this:
Acked-by: Rafael J. Wysocki
Or if you prefer me to take it, please let me know (unless you have objections
against the patch, of course).
Thanks!
> ---
> v4: Defi
On Thursday, December 19, 2013 02:37:46 PM David E. Box wrote:
> From: "David E. Box"
>
> Current Intel SOC cores use a MailBox Interface (MBI) to provide access to
> unit
> devices connected to the system fabric. This driver implements access to this
> interface on BayTrail platforms. This is a
dresses and r/w opcodes are defined in
> >
> > Think of users reading this. At least change "r/w" to read/write.
> > What is IOSF? does it matter here?
> > PUNIT? RAPL?
> >
>
> If you don't know what the IOSF Sideband is you probably sh
On Tuesday, January 07, 2014 01:43:00 PM David E. Box wrote:
> On Tue, Jan 07, 2014 at 09:46:57PM +0100, Rafael J. Wysocki wrote:
> > On Tuesday, January 07, 2014 10:48:05 AM David E. Box wrote:
> > > On Tue, Jan 07, 2014 at 10:15:03AM -0800, Randy Dunlap wrote:
> > > &
On Tuesday, January 07, 2014 09:27:17 PM David E. Box wrote:
> On Wed, Jan 08, 2014 at 01:11:22AM +0100, Rafael J. Wysocki wrote:
> > Well, I personally think that this code should go into arch/x86/ as library
> > code
> > needed to access IOSF Sideband on some platforms.
On Tuesday, February 18, 2014 02:31:46 PM Takashi Iwai wrote:
> At Tue, 18 Feb 2014 12:34:42 +0200,
> Mika Westerberg wrote:
> >
> > On Tue, Feb 18, 2014 at 01:54:20PM +0800, Aaron Lu wrote:
> > > + {
> > > + .callback = video_set_use_native_backlight,
> > > + .ident = "HP EliteBook 2013 models",
On Tuesday, February 18, 2014 11:28:29 PM Igor Gnatenko wrote:
> On Tue, 2014-02-18 at 16:22 +0100, Rafael J. Wysocki wrote:
> > On Tuesday, February 18, 2014 02:31:46 PM Takashi Iwai wrote:
> > > At Tue, 18 Feb 2014 12:34:42 +0200,
> > > Mika Westerberg wrote:
>
t;.)
> So it's about time to remove the Kconfig dependency between these two
> options.
>
> Signed-off-by: Jean Delvare
> Cc: Zhang Rui
> Cc: Len Brown
> Cc: "Rafael J. Wysocki"
Do you want me to take this series?
> ---
> It would be great if this patc
On Wednesday, March 19, 2014 07:51:45 AM Jean Delvare wrote:
> Hi Rafael,
>
> On Wed, 19 Mar 2014 02:26:52 +0100, Rafael J. Wysocki wrote:
> > On Monday, March 17, 2014 03:46:44 PM Jean Delvare wrote:
> > > From: Jean Delvare
> > > Subject:
45958 +0100
> @@ -66,7 +66,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #if defined(CONFIG_LEDS_CLASS) || defined(CONFIG_LEDS_CLASS_MODULE)
>
>
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Cen
f-by: Hans de Goede
>
> Reviewed-by: Aaron Lu
Queued up for 3.16, thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to m
On Friday, September 05, 2014 07:17:57 PM Darren Hart wrote:
> On Thu, Sep 04, 2014 at 09:08:08AM +0200, Paul Bolle wrote:
> > On Thu, 2014-09-04 at 00:53 +0200, Frans Klaver wrote:
> > > In store_sys_acpi, if count equals zero, or parse_arg()s sscanf call
> > > fails, 'value' remains possibly unin
reported_key = (int)buffer_entry[2];
> > - else
> > + else if (buffer_size >= 2)
> > reported_key = (int)buffer_entry[1] & 0x;
> > + else {
> > + pr_info("Received unknown WMI event\n");
>
ink it's significant to warrant asking Azael to go the other way and
> check for them specifically and add errorcodes to the interface rather than
> cleanup the functionality as it stands today and simplifiy the code as he does
> here.
>
> Any objection?
Nope.
--
I speak on
ic int hpwl_add(struct acpi_device *device)
> > {
> > - int err;
> > -
> > - err = hp_wireless_input_setup();
> > - return err;
> > + return hp_wireless_input_setup();
>
> Since acpi_device_probe() does not print a warning if add() fails, it migh
On Wednesday, January 14, 2015 04:38:49 PM Muller, Francois-nicolas wrote:
> From 54d2ff5e13c1b35d5019b82376dabb903ebe30d6 Mon Sep 17 00:00:00 2001
> From: Francois-Nicolas Muller
> Date: Wed, 14 Jan 2015 14:27:43 +0100
> Subject: [PATCH] Adding TCO watchdog warning interrupt handling.
>
> This f
> [for compal-laptop.c]
> Acked-by: Darren Hart
>
> [for the mfd part]
> Acked-by: Lee Jones
> ---
> arch/x86/platform/olpc/olpc-xo1-sci.c | 4 +-
> arch/x86/platform/olpc/olpc-xo15-sci.c| 4 +-
> drivers/acpi/ac.c | 3
},
> +};
> +#endif
> +
> static int __init iTCO_wdt_init_module(void)
> {
> int err;
> @@ -638,12 +704,26 @@ static int __init iTCO_wdt_init_module(void)
> if (err)
> return err;
>
> +#ifdef CONFIG_ACPI
> + if (warn_irq) {
> +
top of 4.1-rc5 makes any difference?
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
; >> passing
> >> an option to disable something which is normally enabled.
> >
> > Fair enough.
> >
> >>
> >> As for the (!disabled) argument, the code in question here actually is:
> >>
> >> if (disabled)
> >>return 0;
> >>
> >> :)
> >>
> >> Still if people want me to change the option to a default-on
> >> enable_backlight_sysfs_if option I can do a v3...
> >
> > I'm not insisting.
>
> Great, thanks :)
>
> So I'm going to assume this v2 patch is ready for merging then, if anyone
> wants me to make any changes please let me know.
The v2 queued up for 4.2, thanks!
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86"
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
tch [06/32] didn't apply for me,
so I decided to apply another patch I've got recently instead and which is now
in my linux-next branch.
Can you please rebase the series on top of linux-pm.git/linux-next and resend
it?
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Sou
On Wed, Jun 17, 2015 at 5:39 AM, Darren Hart wrote:
> On Tue, Jun 16, 2015 at 01:22:40AM +0200, Rafael Wysocki wrote:
>> On Friday, June 12, 2015 01:23:19 PM Hans de Goede wrote:
>> > Hi All,
>> >
>> > Here is v2 of my rewrite / cleanup of the acpi-video (and platform/x86)
>> > backlight interface
On Thursday, October 22, 2015 05:43:07 PM Darren Hart wrote:
> On Thu, Oct 22, 2015 at 03:18:16PM +, Zha, Qipeng wrote:
> > >Is the ASL fragment you provided collected from a running Linux system
> > >using
> > >acpidump? If so, then the resources ACPI advertises to the OS are not
> > >actuall
On Monday, November 23, 2015 03:34:55 PM Lukas Wunner wrote:
> There are 7 drivers which call acpi_get_devices to check for the
> presence of a particular ACPI HID, each defining its own copy of
> a mostly identical callback.
>
> Add acpi_dev_present, the ACPI equivalent to pci_dev_present,
> allo
On Monday, November 23, 2015 11:04:13 AM Darren Hart wrote:
> On Mon, Nov 23, 2015 at 03:34:55PM +0100, Lukas Wunner wrote:
> > Use shiny new acpi_dev_present and remove all the boilerplate to search
> > for a particular ACPI device. No functional change.
>
> You did add a pr_warn, which is techni
On Tuesday, November 24, 2015 12:40:51 PM Hanjun Guo wrote:
> On 2015/11/24 7:32, Lukas Wunner wrote:
> > Hi Robert,
> >
> > On Mon, Nov 23, 2015 at 10:22:27PM +, Moore, Robert wrote:
> acpi_dev_present
> >> Do you really want to be walking the ACPICA namespace for every call?
> > That's w
On Wednesday, November 25, 2015 05:28:54 PM Andy Lutomirski wrote:
> On Mon, Nov 23, 2015 at 11:37 AM, Darren Hart wrote:
> > On Mon, Nov 23, 2015 at 11:25:30AM -0800, Andy Lutomirski wrote:
> >> Without this patch, wmi devices are in /sys/virtual/wmi. They're
> >> logically children of the ACPI
On Thursday, November 26, 2015 07:53:20 AM Andy Lutomirski wrote:
> On Thu, Nov 26, 2015 at 6:09 AM, Rafael J. Wysocki wrote:
> > On Wednesday, November 25, 2015 05:28:54 PM Andy Lutomirski wrote:
> >> On Mon, Nov 23, 2015 at 11:37 AM, Darren Hart wrote:
> >> > On M
On Friday, December 18, 2015 04:12:08 PM Darren Hart wrote:
> On Fri, Nov 20, 2015 at 03:44:25PM +0100, Pali Rohár wrote:
> > On Friday 23 October 2015 20:03:19 Gabriele Mazzotta wrote:
> > > On 23/10/2015 13:14, Pali Rohár wrote:
> > > >On Friday 23 October 2015 11:47:25 Gabriele Mazzotta wrote:
>
On Monday, December 21, 2015 04:34:58 PM Gabriele Mazzotta wrote:
> 2015-12-20 17:21 GMT+01:00 Rafael J. Wysocki :
> > On Friday, December 18, 2015 04:12:08 PM Darren Hart wrote:
> >> On Fri, Nov 20, 2015 at 03:44:25PM +0100, Pali Rohár wrote:
> >> > On Friday 23
On Tuesday, December 29, 2015 04:59:10 PM Darren Hart wrote:
> On Wed, Dec 23, 2015 at 04:14:41PM +0530, Souvik Kumar Chakravarty wrote:
> > Makefile, Kconfig & MAINTAINERS changes for compiling Telemetry.
> > It depends on PUNIT and PMC IPC drivers.
>
> ...
>
> > +config INTEL_TELEMETRY
> > +
On Tuesday, December 29, 2015 04:50:05 PM Darren Hart wrote:
> On Wed, Dec 23, 2015 at 04:14:16PM +0530, Souvik Kumar Chakravarty wrote:
> > This implements debugfs interfaces for reading the telemetry
> > samples from SSRAM and configuring firmware trace verbosity.
> > Interface created under /sys
On Tuesday, December 22, 2015 07:09:47 PM Hans de Goede wrote:
> Hi All,
>
> This patch-set is the result of the discussion surrounding the
> backlight issues on the Dell Vostro V131. The first 3 patches
> cleanup how some platform/x86 drivers detect if acpi-video
> is handling brightness key pres
On Thursday, September 23, 2010, Jesse Barnes wrote:
> On Thu, 23 Sep 2010 23:49:28 +0200
> Jesse Barnes wrote:
>
> > If the CPU doesn't support turbo, don't try to enable/disable it.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drivers/platform/x86/intel_ips.c | 14 +-
> > 1
On Saturday, January 22, 2011, Jeff Chua wrote:
> 2011/1/22 Rafael J. Wysocki :
> > On Friday, January 21, 2011, Jeff Chua wrote:
> >> 2011/1/21 Rafael J. Wysocki :
> >> > Thanks, but unfortunately this wasn't conclusive. Please apply the
> >> > pat
On Sunday, January 23, 2011, Henrique de Moraes Holschuh wrote:
> On Sat, 22 Jan 2011, Rafael J. Wysocki wrote:
> > > I discovered CONFIG_THINKPAD_ACPI caused suspend-to-disk to hang. I
> > > need the Thinkpad ACPI to control the fan and bluetooth. It looks like
> > &g
On Monday, January 24, 2011, Henrique de Moraes Holschuh wrote:
> On Sun, 23 Jan 2011, Rafael J. Wysocki wrote:
> > On Sunday, January 23, 2011, Henrique de Moraes Holschuh wrote:
> > > On Sat, 22 Jan 2011, Rafael J. Wysocki wrote:
> > > > > I discovered CONFIG_THI
On Tuesday, January 25, 2011, Ozan Çağlayan wrote:
> Pazartesi 24 Ocak 2011 günü (saat 22:14:28) Lionel Debroux şunları yazmıştı:
> > On 24.01.2011 10:47, Lionel Debroux wrote:
>
> > None of nolapic, acpi=off, nolapic acpi=off enables 2.6.35.8 to boot
> > on my ASUS F3Jv-AS022P.
> > The kernel lin
On Tuesday, January 25, 2011, Ozan Çağlayan wrote:
> On 25.01.2011 21:38, Rafael J. Wysocki wrote:
>
> > Does
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ec30f343d61391ab23705e50a525da1d55395780
> > generally help?
>
> Well I can
On Sunday, January 30, 2011, Ozan Çağlayan wrote:
> On 29.01.2011 19:49, Ozan Çağlayan wrote:
>
> > intel_idle enabled and the patch above applied. Got 1 feedback for now
> > which tells that 1 out of 2 shutdown attempts failed. This is on Asus
> > N61JQ (https://bugzilla.kernel.org/show_bug.cgi?i
On Monday, January 31, 2011, Ozan Çağlayan wrote:
> On 31.01.2011 00:48, Rafael J. Wysocki wrote:
>
> > Does booting with "nolapic" help on all of the affected systems?
> >
> > Also, does disabling the CPUidle during boot help?
> >
> > Finally, is th
On Monday, January 31, 2011, Ozan Çağlayan wrote:
> On 31.01.2011 11:50, Rafael J. Wysocki wrote:
> > On Monday, January 31, 2011, Ozan Çağlayan wrote:
> >> On 31.01.2011 00:48, Rafael J. Wysocki wrote:
> >>
> >>> Does booting with "nolapic" help
On Monday, January 31, 2011, Richard Schütz wrote:
> >> I'll compile a kernel with CONFIG_NO_HZ to see what happens but how do I
> >> disable cpuidle during boot? I've checked the kernel-parameters.txt but
> >> there's no cpuidle related boot parameter there.
> >
> > Booting with intel_idle.max_cst
On Monday, January 31, 2011, Richard Schütz wrote:
> I'll compile a kernel with CONFIG_NO_HZ to see what happens but how do I
> disable cpuidle during boot? I've checked the kernel-parameters.txt but
> there's no cpuidle related boot parameter there.
> >>>
> >>> Booting with intel_id
On Monday, January 31, 2011, Ozan Çağlayan wrote:
> On 31.01.2011 20:24, Rafael J. Wysocki wrote:
>
> >>
> >> Or just use the processor.max_cstate parameter then.
> >
> > As I wrote a couple of messages ago, https://lkml.org/lkml/2011/1/31/52 .
>
> The
On Monday, January 31, 2011, Ozan Çağlayan wrote:
> On 31.01.2011 20:33, Rafael J. Wysocki wrote:
>
> >
> > Would it be possible to check if running the kernel in uniprocessor mode
> > makes the problem go away?
>
> If that's the equivalent of booting with ma
On Monday, January 31, 2011, Ozan Çağlayan wrote:
> On 31.01.2011 21:12, Rafael J. Wysocki wrote:
>
> > Booting with maxcpus=0 also disables the I/O APIC, which probably is a bit
> > too
> > much, but let's see what happens in that case.
>
> Well the only-bo
On Monday, January 31, 2011, Ozan Çağlayan wrote:
> On 31.01.2011 22:42, Ozan Çağlayan wrote:
>
> > Well I've actually a screenshot of the boot hang with tons of debugging
> > parameters passed to kernel. Maybe it will give you a clue. It hangs
> > right after printing e820 system memory map.
> >
On Thursday, February 03, 2011, Ozan Çağlayan wrote:
>
> >
> > Hmm. Perhaps it's possible to test this patch on the affected boxes:
> > https://bugzilla.kernel.org/attachment.cgi?id=45192
>
>
> Still no change with the patch..
I guess we see a few different problems here.
Can you remind me, p
On Thursday, February 03, 2011, Ozan Çağlayan wrote:
> On 04.02.2011 00:04, Rafael J. Wysocki wrote:
>
> >
> > I guess we see a few different problems here.
> >
> > Can you remind me, please, what the known workarounds are?
>
> OK in summary:
>
> ASUS
On Friday, February 04, 2011, Ozan Çağlayan wrote:
> Cuma 04 Şubat 2011 günü (saat 00:51:31) Rafael J. Wysocki şunları yazmıştı:
>
> > Hmm. Are those boxes uniprocessor running SMP kernels?
>
> The kernel is SMP.
>
> ASUS X61S is
> CPU0: Intel(R) Core(TM)2 D
On Saturday, February 05, 2011, Ozan Çağlayan wrote:
> On 04.02.2011 22:36, Rafael J. Wysocki wrote:
>
> >
> > At this point I guess it's best to open a bug entry in the kernel Bugzilla,
> > against ACPI (although ACPI may be a red herring), and put some system
>
From: Rafael J. Wysocki
Make the acer-wmi driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct platform_driver.
Signed-off-by: Rafael J. Wysocki
---
drivers/platform/x86/acer-wmi.c | 10 +-
1 file changed, 5 insertions
Hi all,
The following series of patches converts a few drivers under platform/x86
to using struct dev_pm_ops objects for power management istead of legacy
callbacks in struct platform_driver.
The ultimate goal of this will be to get rid of PM callbacks from the
platform bus type, which are only n
From: Rafael J. Wysocki
Make the thinkpad_acpi driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct platform_driver.
Signed-off-by: Rafael J. Wysocki
---
drivers/platform/x86/thinkpad_acpi.c | 11 ++-
1 file changed, 6
From: Rafael J. Wysocki
The legacy PM callbacks provided by the Intel IPS driver are
empty routines returning 0, so they can be safely dropped.
Signed-off-by: Rafael J. Wysocki
---
drivers/platform/x86/intel_ips.c | 17 -
1 file changed, 17 deletions(-)
Index: linux/drivers
From: Rafael J. Wysocki
Make the intel_mid_thermal driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct platform_driver.
Signed-off-by: Rafael J. Wysocki
---
drivers/platform/x86/intel_mid_thermal.c | 16 +---
1 file
From: Rafael J. Wysocki
Multiple suspend routines in drivers/platform/x86/thinkpad_acpi.c
use take pm_message_t arguments that aren't used by any of them.
Make those routines take no arguments as that's what they should do.
Signed-off-by: Rafael J. Wysocki
---
drivers/pl
Hi all,
The following patchset converts the ACPI bus type and all of the ACPI drivers
to the power management handling based on struct dev_pm_ops. It does that in
the following way:
(1) The (unused) pm_message_t argument is dropped from the ACPI driver suspend
callback throughout the tree (p
From: Rafael J. Wysocki
Make the ACPI processor driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/processor_driver.c |6 --
drivers/acpi/processor_idle.c
From: Rafael J. Wysocki
Make the ACPI Smart Battery System driver define its PM callbacks
through a struct dev_pm_ops object rather than by using legacy PM
hooks in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/sbs.c | 10 ++
1 file changed, 6 insertions
From: Rafael J. Wysocki
Since the ACPI bus type's PM callbacks only execute the driver ones
without doing anything else, they can be dropped, because the driver
callbacks will be executed by the PM core directly if bus type
(or other subsystem) callbacks are not present.
Signed-off-by: Raf
From: Rafael J. Wysocki
Since the legacy ACPI driver PM callbacks included into
struct acpi_device_ops are not used any more, drop them.
Signed-off-by: Rafael J. Wysocki
---
include/acpi/acpi_bus.h |4
1 file changed, 4 deletions(-)
Index: linux/include/acpi/acpi_bus.h
From: Rafael J. Wysocki
Make the xo15-ebook driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/platform/x86/xo15-ebook.c |8 +---
1 file changed, 5 insertions
From: Rafael J. Wysocki
Since all ACPI drivers in the tree should have been switched
to power management handling based on struct dev_pm_ops,
modify the ACPI bus type driver so that is doesn't execute
legacy driver power management callbacks from the functions
pointed to by the members o
From: Rafael J. Wysocki
Make the ACPI power meter driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/hwmon/acpi_power_meter.c | 13 +
1 file changed, 9
From: Rafael J. Wysocki
None of the drivers implementing the ACPI device suspend callback
uses the pm_message_t argument of it, so this argument may be dropped
entirely from that callback. This will simplify switching the ACPI
bus type to PM handling based on struct dev_pm_ops.
Signed-off-by
From: Rafael J. Wysocki
Make the acpi_bus_type bus type define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct bus_type.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/scan.c |9 +
1 file changed, 5 insertions(+), 4 deletions
From: Rafael J. Wysocki
Make the ACPI fan driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/fan.c | 21 +++--
1 file changed, 11 insertions
From: Rafael J. Wysocki
Make the ACPI thermal driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/thermal.c | 17 ++---
1 file changed, 10 insertions
From: Rafael J. Wysocki
Make the toshiba_acpi driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/platform/x86/toshiba_acpi.c | 14 --
1 file changed, 8
From: Rafael J. Wysocki
Make the ACPI button driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/button.c |9 ++---
1 file changed, 6 insertions(+), 3
From: Rafael J. Wysocki
Make the ACPI battery driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/battery.c | 15 +++
1 file changed, 11 insertions
From: Rafael J. Wysocki
Make the ACPI AC adapter driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/ac.c | 17 -
1 file changed, 12 insertions
From: Rafael J. Wysocki
Make the sony-laptop driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/platform/x86/sony-laptop.c | 20
1 file changed
From: Rafael J. Wysocki
Make the ACPI power resource driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/acpi/power.c | 12
1 file changed, 8 insertions
From: Rafael J. Wysocki
Make the panasonic-laptop driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/platform/x86/panasonic-laptop.c | 16 +++-
1 file
From: Rafael J. Wysocki
Make the toshiba_bluetooth driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/platform/x86/toshiba_bluetooth.c | 10 ++
1 file changed
From: Rafael J. Wysocki
Modify acpi_bus_type so that it executes PM callbacks provided
by drivers through their struct dev_pm_ops objects, if present,
while still allowing the legacy ACPI PM callbacks to take precedence.
This will make it possible to convert ACPI drivers one by one to
handling
From: Rafael J. Wysocki
Make the hp_accel driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
drivers/platform/x86/hp_accel.c | 15 ---
1 file changed, 8 insertions
From: Rafael J. Wysocki
Make the sonypi driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct platform_driver.
Signed-off-by: Rafael J. Wysocki
---
Hi,
If there are no objections, I'd like to push this patch for 3.6 through
the
On Sunday, June 24, 2012, Vikram Dhillon wrote:
> On Sat, Jun 23, 2012 at 5:18 PM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Make the toshiba_bluetooth driver define its PM callbacks through
> > a struct dev_pm_ops object rather than by using le
On Sunday, June 24, 2012, Henrique de Moraes Holschuh wrote:
> On Sun, 17 Jun 2012, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Make the thinkpad_acpi driver define its PM callbacks through
> > a struct dev_pm_ops object rather than by using le
On Sunday, June 24, 2012, Éric Piel wrote:
> On 23-06-12 23:16, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Make the hp_accel driver define its PM callbacks through
> > a struct dev_pm_ops object rather than by using legacy PM hooks
> > in struc
From: Rafael J. Wysocki
Make the classmate-laptop driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
Hi all,
I overlooked the classmate-laptop driver in the ACPI conversion to
From: Rafael J. Wysocki
Make the fujitsu-tablet driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct acpi_device_ops.
Signed-off-by: Rafael J. Wysocki
---
Hi all,
Another driver overlooked during the ACPI conversion to PM handling
On Friday, June 29, 2012, Thadeu Cascardo wrote:
> - Original message -
> > From: Rafael J. Wysocki
> >
> > Make the classmate-laptop driver define its PM callbacks through
> > a struct dev_pm_ops object rather than by using legacy PM hooks
> > in struct
From: Rafael J. Wysocki
Make the HDAPS driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct platform_driver.
Signed-off-by: Rafael J. Wysocki
---
drivers/platform/x86/hdaps.c |6 --
1 file changed, 4 insertions(+), 2
From: Rafael J. Wysocki
Make the msi-laptop driver define its PM callbacks through
a struct dev_pm_ops object rather than by using legacy PM hooks
in struct platform_driver.
Signed-off-by: Rafael J. Wysocki
---
drivers/platform/x86/msi-laptop.c |7 ---
1 file changed, 4 insertions
Hi all,
After the changes I've sent recently there are two more drivers still using
legacy power management callbacks, so convert them too:
[1/2] hdaps: Use struct dev_pm_ops for power management
[2/2] msi-laptop: Use struct dev_pm_ops for power management
Thanks,
Rafael
--
To unsubscribe from
On Thursday, July 19, 2012, Len Brown wrote:
>
> > The patchset has been tested on Toshiba Portege R500 and more testing is in
> > the works. If there are no objections, I'd like to push if for 3.6 through
> > the linux-pm tree.
>
> Good plan. Would need to merge w/ my tree only if we run into
Hi all,
The recent conversion to the PM handling based on struct dev_pm_ops
uncovered some code that is not used for CONFIG_PM_SLEEP unset, which
results in a number of new copiler warning.
Admittedly, I should have spotted those places before, but anyway
patches fixing those for ACPI, platform/x
1 - 100 of 118 matches
Mail list logo
