Remove excessive numbers of (un)likely()s in the backlight core.

There are no hot paths in this code so rely on compiler to do
the right thing.
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>

Fix error handling when registering new device
Signed-off-by: NDmitry Torokhov <dtor@mail.ru>
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>

This patch set adds generic abstract layer support for acpi video driver to
have generic user interface to control backlight and output switch control by
leveraging the existing backlight sysfs class driver, and by adding a new
video output sysfs class driver.

This patch:

Add dev argument for backlight_device_register to link the class device to
real device object.  The platform specific driver should find a way to get the
real device object for their video device.

[akpm@osdl.org: build fix]
[akpm@osdl.org: fix msi-laptop.c]
Signed-off-by: NLuming Yu <Luming.yu@intel.com>
Cc: "Antonino A. Daplas" <adaplas@pol.net>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLen Brown <len.brown@intel.com>

ACPI drivers like ibm-acpi are moving to the backlight sysfs
infrastructure.  During ibm-acpi testing, I have noticed that
backlight_device_unregister() sets the display brightness and power to
zero.

This causes the display to be dimmed on ibm-acpi module removal.  It will
affect all other ACPI drivers that are being converted to use the backlight
class, as well.  It also affects a number of framebuffer devices that are
used on desktops and laptops which might also not want such behaviour.

Since working around this behaviour requires undesireable hacks, Richard
Purdie decided that we would be better off reverting the changes in the
sysfs class, and adding the code to dim and power off the backlight device
to the drivers that want it.  This patch is my attempt to do so.

Patch against latest linux-2.6.git.  Changes untested, as I lack the
required hardware.  Still, they are trivial enough that, apart from typos,
there is little chance of getting them wrong.
Signed-off-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
Acked-by: NRichard Purdie <rpurdie@rpsys.net>
Acked-by: NPavel Machek <pavel@ucw.cz>
Acked-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The backlight layer should be independent from the framebuffer layer.  It
can use the services offered by the framebuffer, but its absence should not
prevent the backlight/lcd layer from functioning.

[akpm@osdl.org: cleanups]
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

- move some structs and arrays to the read-only (.rodata) section

[akpm@osdl.org: build fix]
Signed-off-by: NHelge Deller <deller@gmx.de>
Acked-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The backlight and LCD class _store functions currently accept values like "34
some random strings" without error.  This corrects them to return -EINVAL if
the value is not numeric with an optional byte of trailing whitespace.
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Backlight class attributes are currently easy to implement incorrectly.
Moving certain handling into the backlight core prevents this whilst at the
same time makes the drivers simpler and consistent.  The following changes are
included:

The brightness attribute only sets and reads the brightness variable in the
backlight_properties structure.

The power attribute only sets and reads the power variable in the
backlight_properties structure.

Any framebuffer blanking events change a variable fb_blank in the
backlight_properties structure.

The backlight driver has only two functions to implement.  One function is
called when any of the above properties change (to update the backlight
brightness), the second is called to return the current backlight brightness
value.  A new attribute "actual_brightness" is added to return this brightness
as determined by the driver having combined all the above factors (and any
driver/device specific factors).

Additionally, the backlight core takes care of checking the maximum brightness
is not exceeded and of turning off the backlight before device removal.

The corgi backlight driver is updated to reflect these changes.
Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

ERR_PTR() is supposed to be passed a negative value.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

A bunch of asm/bug.h includes are both not needed (since it will get
pulled anyway) and bogus (since they are done too early).  Removed.
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This patch removes almost all inclusions of linux/version.h.  The 3
#defines are unused in most of the touched files.

A few drivers use the simple KERNEL_VERSION(a,b,c) macro, which is
unfortunatly in linux/version.h.

There are also lots of #ifdef for long obsolete kernels, this was not
touched.  In a few places, the linux/version.h include was move to where
the LINUX_VERSION_CODE was used.

quilt vi `find * -type f -name "*.[ch]"|xargs grep -El '(UTS_RELEASE|LINUX_VERSION_CODE|KERNEL_VERSION|linux/version.h)'|grep -Ev '(/(boot|coda|drm)/|~$)'`

search pattern:
/UTS_RELEASE\|LINUX_VERSION_CODE\|KERNEL_VERSION\|linux\/\(utsname\|version\).h
Signed-off-by: NOlaf Hering <olh@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!