Just a trivial pr_warning to pr_warn conversion
while adding a few missing newlines.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
The ACPI notification we get from rfkill events on these machines gives
us all the information we need to identify the port that's changed. Do
so rather than assuming that it's always bus 1.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
There may be multiple ways of controlling the backlight on a given
machine. Allow drivers to expose the type of interface they are
providing, making it possible for userspace to make appropriate policy
decisions.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Airlie <airlied@linux.ie>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Allow te get the current led state in a more accurate way.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
backlight_device_register has been expecting a const "ops" argument, and using
it as such, since 9905a43b2d. Let's make the
remaining backlight_ops instances const.
Inspired by hunks of the grsecurity patch, updated for newer kernels.
Signed-off-by: Lionel Debroux <lionel_debroux@yahoo.fr>
Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Makes asus-laptop and eeepc-laptop _init/_exit functions
looks exactly the same as they do the same thing.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
The hotplug_disabled module parameter is determinated at the module load
time. Change the value after the module is loaded does not make sense and
has no effect at all, thus set the permissions to 0444 instead of 0644.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Matthew Garrett <mjg@redhat.com>
Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Matthew Garrett <mjg@redhat.com>
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
Values such as max_brightness should be set before backlights are
registered, but the current API doesn't allow that. Add a parameter to
backlight_device_register and update drivers to ensure that they
set this correctly.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Before we mark the wireless device as unplugged, check PCI config space
to see whether the wireless device is really disabled (and vice versa).
This works around newer models which don't want the hotplug code, where
we end up disabling the wired network device.
My old 701 still works correctly with this. I can also simulate an
afflicted model by changing the hardcoded PCI bus/slot number in the
driver, and it seems to work nicely (although it is a bit noisy).
In future this type of hotplug support will be implemented by the PCI
core. The existing blacklist and the new warning message will be
removed at that point.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Some new models need to disable wireless hotplug.
For the moment, we don't know excactly what models need that,
except 1005HA.
Users will be able to use that param as a workaround.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
This is a short term workaround for Eeepc 1005HA.
refs: <http://bugzilla.kernel.org/show_bug.cgi?id=14570>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
The EeePC 4G ("701") implements CFVS, but it is not supported by the
pre-installed OS, and the original option to change it in the BIOS
setup screen was removed in later versions. Judging by the lack of
"Super Hybrid Engine" on Asus product pages, this applies to all "701"
models (4G/4G Surf/2G Surf).
So Asus made a deliberate decision not to support it on this model.
We have several reports that using it can cause the system to hang [1].
That said, it does not happen all the time. Some users do not
experience it at all (and apparently wish to continue "right-clocking").
Check for the EeePC 701 using DMI. If met, then disable writes to the
"cpufv" sysfs attribute and log an explanatory message.
Add a "cpufv_disabled" attribute which allow users to override this
policy. Writing to this attribute will log a second message.
The sysfs attribute is more useful than a module option, because it
makes it easier for userspace scripts to provide consistent behaviour
(according to user configuration), regardless of whether the kernel
includes this change.
[1] <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559578>
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
As Corentin points out, we do not create a backlight device if the ACPI
video driver is able to provide equivalent functionality. So we do need
to check before we try to update the backlight device.
We now ignore brightness events completely if we have not created a
backlight device. This is slightly more cautious than the original
check.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
fix styles problems introduced by commit
e86bda235a08b6a8e64c1e8bb9d175f6961554e3
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
Callback methods should not refer to a variable like "eeepc" (formally
"ehotk"). Instead, they should extract the data they need either from
a "driver data" parameter, or the "driver data" field of the object
which they operate on. The "eeepc" variable can then be removed.
In practice, drivers under "drivers/platform" can get away without using
driver data, because it doesn't make sense to have more than one
instance of them. However this makes it harder to review them for
correctness. This is especially true for core ACPI developers who have
not previously been exposed to this anti-pattern :-).
This will serve as an example of best practice for new driver writers
(whether they find it themselves, or have it pointed out during review
:-).
The hwmon sub-device is a special case. It uses ec_{read,write} which
are defined to communicate with the (first) EC, so it does not require
any driver data. It should still only be instantiated in the context of
an ASUS010 device because we don't have a safe way to probe for it.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
CC: Bjorn Helgaas <bjorn.helgaas@hp.com>
Signed-off-by: Len Brown <len.brown@intel.com>
eeepc-laptop now does a lot more than just hotkeys. Replace the "hotk"
names used throughout the driver with some slightly more appropriate
names. The actual strings used in kernel messages and sysfs are left
unchanged.
e.g.
EEEPC_HOTK_FILE -> EEEPC_LAPTOP_FILE
EEEPC_HOTK_HID -> EEEPC_ACPI_HID
eeepc_hotk_notify -> eeepc_acpi_notify
struct eeepc_hotk -> struct eeepc_laptop
ehotk -> eeepc
I'm about to refactor the entire driver to remove the global "ehotk"
variable, and I don't wish to add "struct eeepc_hotk *ehotk" to
functions which have nothing to do with hotkeys.
Also
- fix the name of "eepc_get_entry_by_keycode()"
- remove the unused definition of NOTIFY_WLAN_ON.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
Move e.g. backlight_init() and backlight_exit() together along with the
other backlight functions, instead of grouping init() and exit()
functions. Move e.g. backlight_ops to follow the functions it refers
to, and remove the forward declarations. The code itself should remain
unchanged.
The eeepc-laptop driver implements a number of interfaces like the
backlight class driver. This change makes it easier to examine the
implementation of one interface at at a time, without having to search
through the file to find init() and exit() functions etc.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
This moves the sysfs_create_group() call just after the declaration of
the platform device attributes. It should make it easier to examine
the implementation of the platform device attributes in isolation
from the rest of the code. (The next commit will apply this pattern
to all of the sub-devices as well).
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk
Signed-off-by: Len Brown <len.brown@intel.com>
Strictly speaking we should register the platform driver exactly once,
whether there are zero, one, or multiple matching acpi devices.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
Separate out input_notify(), in a similar way to how notify_brn()
is already separated. This will allow all the functions which refer to
the input device to be grouped together.
This includes a small behaviour change - we now synthesize brightness
up/down key events even if the brightness is already at the
maximum/minimum value. This is consistent with the new uevent
interface.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
The hwmon device uses ec_write() to write values to the EC. So for
consistency it should use ec_read() to read values. The extra layers
of indirection used did not add any value.
This may mean we no longer take the ACPI global lock for such reads
(if the EC operation region requires the lock and the EC does not).
But there is no point locking each one-byte read individually, when
write operations do not use the lock at all.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
We don't need to store init_flags after using them. And we don't use
the result of INIT, so we don't need to allocate a buffer for it.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
We already tell the backlight class our maximum brightness value; it
will validate the user requested values for us.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
eeepc_hotk_notify() cannot be called with ehotk == NULL or bd == NULL.
We check both variables for allocation failure and would bail out before
the notifier is registered.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
If the control method does not exist, return -ENODEV for consistency
with get_acpi()
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
If we bail out because we can't create the led class device, we need to
ensure the led workqueue is cleaned up.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
Create the workqueue thread used by tpd_led_set() *before* we register
the led device. (And vice versa for unregistration).
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
Documentation/hwmon/sysfs-interface tells us that automatic fan speed
control should be represented by a value of 2 or above for pwm1_enable.
Fix eeepc_get_fan_ctrl() to return 2 for automatic fan control.
Setting "1" for manual control is already consistent with the
documentation, so this remains unchanged.
Let's preserve the ABI for this specific driver, so that writing "0"
will still invoke automatic control.
(The documentation says setting "0" should leave the fan at full speed
all the time. This mode is not directly supported by our hardware. Full
speed is rather noisy on my 701 and the automatic control has never used
it. If you really want this e.g. to prolong the life of an EeePC used
as a server, you can always use manual mode. hwmon has always been
fairly machine-specific, and you're in a tiny minority (or elite :-).
I'm sure you're smart enough to notice that the fan doesn't turn on to
full speed when you try this mode, either by ear or checking
fan_input1.
We could even claim to be honouring the spirit of the documentation.
"0" really means "safe mode". EeePCs default to automatic mode, ie that
is what Asus will actually test. Since we do not provide any way to
tamper with the temperature threshold, automatic mode _is_ the safe
option).
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
The owner field provides the link between drivers and modules in sysfs,
but no ACPI driver was setting it.
After setting the owner field, we can see which module provides which
driver and vice versa by looking at /sys/bus/acpi/driver/*/module and
/sys/module/*/drivers/acpi:*.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
acpi_bus_register_driver() already checks acpi_disabled, so acpi bus
drivers don't need to.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
The acpi device callbacks add, start, remove, suspend and resume can
never be called with a NULL acpi_device. Each callsite in acpi/scan.c
has to dereference the device in order to get the ops structure, e.g.
struct acpi_device *acpi_dev = to_acpi_device(dev);
struct acpi_driver *acpi_drv = acpi_dev->driver;
if (acpi_drv && acpi_drv->ops.suspend)
return acpi_drv->ops.suspend(acpi_dev, state);
Remove all checks for acpi_dev == NULL within these callbacks.
Also remove the checks for acpi_driver_data(acpi_dev) == NULL. None of
these checks could fail unless the driver does something strange
(which none of them do), the acpi core did something terribly wrong,
or we have a memory corruption issue. If this does happen then it's
best to dereference the pointer and crash noisily.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
Currently, reading from the disp attribute fails with "No such device",
which is misleading. According to CMSG table on acpi4asus project site,
no models have a getter method corresponding to SDSP. Change the file
permission to disallow reads.
If some joker changes the permission to permit reads, then return -EIO
to be consistent with sysfs' behaviour when no show() method is
provided.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
Switching the camera takes 500ms, checking if it's on is almost free...
The BIOS remembers the setting through reboots, so there's good chance the
camera is already enabled.
Signed-off-by: Luca Niccoli <lultimouomo@gmail.com>
Cc: Corentin Chary <corentincj@iksaif.net>
Cc: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Cc: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
rt2860sta is fine with the patch as is, but iwl3945 isn't
(eeepc_rfkill_set() needs to call eeepc_rfkill_hotplug(true) – which means
that we're back to causing the rt2860sta panic
This reverts commit b56ab33d68.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
This works around what I think is actually a bug in rt2860sta which is
triggered when the hardware "disappears" from beneath the driver, i.e. when
wireless is toggled off via ACPI. It does so by ensuring that the rfkill
soft-block flag is set before the hardware is disabled.
I do not know whether this patch is required if rt2800pci is in use instead
of rt2860sta; at the time of submission of this patch, I've not been able to
test this.
(Ref. http://bugzilla.kernel.org/show_bug.cgi?id=13390)
Signed-off-by: Darren Salt <linux@youmustbejoking.demon.co.uk>
Signed-off-by: Len Brown <len.brown@intel.com>
Currently the annotation for function eeepc_enable_camera() is
__init, and refers to a
function eeepc_hotk_add() which is non-init. Use __devinit for both
functions which is
more appropriate and fixes a section mismatch warning.
We were warned by the following warning:
LD drivers/platform/x86/built-in.o
WARNING: drivers/platform/x86/built-in.o(.text+0x12e1): Section
mismatch in reference from the function eeepc_hotk_add() to the
function .init.text:eeepc_enable_camera()
The function eeepc_hotk_add() references
the function __init eeepc_enable_camera().
This is often because eeepc_hotk_add lacks a __init
annotation or the annotation of eeepc_enable_camera is wrong.
Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
* 'for-linus' of git://git.o-hand.com/linux-rpurdie-backlight:
backlight: new driver for ADP5520/ADP5501 MFD PMICs
backlight: extend event support to also support poll()
backlight/eeepc-laptop: Update the backlight state when we change brightness
backlight/acpi: Update the backlight state when we change brightness
backlight: Allow drivers to update the core, and generate events on changes
backlight: switch to da903x driver to dev_pm_ops
backlight: Add support for the Avionic Design Xanthos backlight device.
backlight: spi driver for LMS283GF05 LCD
backlight: move hp680-bl's probe function to .devinit.text
backlight: Add support for new Apple machines.
backlight: mbp_nvidia_bl: add support for MacBookAir 1,1
backlight: Add WM831x backlight driver
Trivial conflicts due to '#ifdef CONFIG_PM' differences in
drivers/video/backlight/da903x_bl.c
Trigger a status update when the user hits a brightness key, allowing
userspace to present appropriate UI.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
The 900A provides hotplug notifications on a different ACPI object to
other models.
Reported-by: Trevor <trevor.chart@gmail.com>
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Len Brown <len.brown@intel.com>
Joe Perches