21 Feb, 2012
25 commits
-
commit 02a237b24d57e2e2d5402c92549e9e792aa24359 upstream.
Since 3.2 kernel, the driver starts trying to assign the multi-io DACs
before the speaker, thus it assigns DAC2/3 for multi-io and DAC4 for
the speaker for a standard laptop setup like a HP, a speaker, a mic-in
and a line-in. However, on Acer Aspire 6935, it seems that the
speaker pin 0x14 must be connected with either DAC1 or 2; otherwise it
results in silence by some reason, although the codec itself allows
the routing to DAC3/4.As a workaround, the connection list of each pin is reduced to be
mapped to either only DAC1/2 or DAC3/4, so that the compatible
assignment as in kernel 3.1 is achieved.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42740
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit fc1156c0b0f7ad45ec03d919866349eeca2bf18c upstream.
VT1705 codec has two ADCs where the secondary ADC has no MUX but only
a fixed connection to the mic pin. This confused the driver and it
tries always overriding the input-source selection by assumption of
the existing MUX for the secondary ADC, resulted in resetting the
input-source at each time PM (including power-saving) occurs.The fix is simply to check the existence of MUX for secondary ADCs in
the initialization code.Tested-by: Anisse Astier
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 27c3afe6e1cf129faac90405121203962da08ff4 upstream.
BugLink: https://bugs.launchpad.net/bugs/930842
The reporter states that audio is inaudible by default without muting
'External Amplifier'. Add a quirk to handle his SSID so that changing
the control is not necessary.Reported-and-tested-by: Benjamin Carlson
Signed-off-by: Daniel T Chen
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 2673b4cf5d59c3ee5e0c12f6d734d38770324dc4 upstream.
While 7a401a972df8e18 ("backing-dev: ensure wakeup_timer is deleted")
addressed the problem of the bdi being freed with a queued wakeup
timer, there are other races that could happen if the wakeup timer
expires after/during bdi_unregister(), before bdi_destroy() is called.wakeup_timer_fn() could attempt to wakeup a task which has already has
been freed, or could access a NULL bdi->dev via the wake_forker_thread
tracepoint.Cc: Jens Axboe
Reported-by: Chanho Min
Reviewed-by: Namjae Jeon
Signed-off-by: Rabin Vincent
Signed-off-by: Wu Fengguang
Signed-off-by: Greg Kroah-Hartman -
commit 3a92d687c8015860a19213e3c102cad6b722f83c upstream.
Unfortunately in reducing W from 80 to 16 we ended up unrolling
the loop twice. As gcc has issues dealing with 64-bit ops on
i386 this means that we end up using even more stack space (>1K).This patch solves the W reduction by moving LOAD_OP/BLEND_OP
into the loop itself, thus avoiding the need to duplicate it.While the stack space still isn't great (>0.5K) it is at least
in the same ball park as the amount of stack used for our C sha1
implementation.Note that this patch basically reverts to the original code so
the diff looks bigger than it really is.Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 58d7d18b5268febb8b1391c6dffc8e2aaa751fcd upstream.
The previous patch used the modulus operator over a power of 2
unnecessarily which may produce suboptimal binary code. This
patch changes changes them to binary ands instead.Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit ff4fa4a25a33f92b5653bb43add0c63bea98d464 upstream.
standard_receive3 will check the validity of the response from the
server (via checkSMB). It'll pass the result of that check to handle_mid
which will dequeue it and mark it with a status of
MID_RESPONSE_MALFORMED if checkSMB returned an error. At that point,
standard_receive3 will also return an error, which will make the
demultiplex thread skip doing the callback for the mid.This is wrong -- if we were able to identify the request and the
response is marked malformed, then we want the demultiplex thread to do
the callback. Fix this by making standard_receive3 return 0 in this
situation.Reported-and-Tested-by: Mark Moseley
Signed-off-by: Jeff Layton
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 8b0192a5f478da1c1ae906bf3ffff53f26204f56 upstream.
Currently, it's always set to 0 (no oplock requested).
Signed-off-by: Jeff Layton
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 09e87e5c4f9af656af2a8a3afc03487c5d9287c3 upstream.
In order to enable temperature mode aka automatic mode for the F75373 and
F75375 chips, the two FANx_MODE bits in the fan configuration register
need be set to 01, not 10.Signed-off-by: Nikolaus Schulz
Signed-off-by: Greg Kroah-Hartman -
commit 977b7e3a52a7421ad33a393a38ece59f3d41c2fa upstream.
When a SD card is hot removed without umount, del_gendisk() will call
bdi_unregister() without destroying/freeing it. This leaves the bdi in
the bdi->dev = NULL, bdi->wb.task = NULL, bdi->bdi_list removed state.When sync(2) gets the bdi before bdi_unregister() and calls
bdi_queue_work() after the unregister, trace_writeback_queue will be
dereferencing the NULL bdi->dev. Fix it with a simple test for NULL.LKML-reference: http://lkml.org/lkml/2012/1/18/346
Reported-by: Rabin Vincent
Tested-by: Namjae Jeon
Signed-off-by: Wu Fengguang
Signed-off-by: Greg Kroah-Hartman -
commit 15eb77a07c714ac80201abd0a9568888bcee6276 upstream.
bdi_prune_sb() resets sb->s_bdi to default_backing_dev_info when the
tearing down the original bdi. Fix trace_writeback_single_inode to
use sb->s_bdi=default_backing_dev_info rather than bdi->dev=NULL for a
teared down bdi.Reported-by: Rabin Vincent
Tested-by: Rabin Vincent
Signed-off-by: Wu Fengguang
Signed-off-by: Greg Kroah-Hartman -
commit 07ae2dfcf4f7143ce191c6436da1c33f179af0d6 upstream.
The current code checks for stored_mpdu_num > 1, causing
the reorder_timer to be triggered indefinitely, but the
frame is never timed-out (until the next packet is received)Signed-off-by: Eliad Peller
Acked-by: Johannes Berg
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit f6302f1bcd75a042df69866d98b8d775a668f8f1 upstream.
"subbuf_size" and "n_subbufs" come from the user and they need to be
capped to prevent an integer overflow.Signed-off-by: Dan Carpenter
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 3310225dfc71a35a2cc9340c15c0e08b14b3c754 upstream.
PROP_MAX_SHIFT should be set to 32.
2) overflow: (bdi_dirty * numerator) could easily overflow if numerator
used up to 48 bits, leaving only 16 bits to bdi_dirtyCc: Peter Zijlstra
Reported-by: Ilya Tumaykin
Tested-by: Ilya Tumaykin
Signed-off-by: Wu Fengguang
Signed-off-by: Greg Kroah-Hartman -
commit a1728800bed3b93b231d99e97c756f622b9991c2 upstream.
8
Date: Wed, 16 Nov 2011 09:33:50 +0100
Subject: net: enable TC35815 for MIPS againTX493[8,9] MIPS SoCs support 2 Ethernet channels of type TC35815
which are connected to the internal PCI controller.
And JMR3927 MIPS board has a TC35815 chip on board.
These dependencies were lost on movement to drivers/net/ethernet/toshiba.Signed-off-by: Ralf Roesch
Signed-off-by: Atsushi Nemoto
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit eb2f255b2d360df3f500042a2258dcf2fcbe89a2 upstream.
In order to extract the high byte of the 16-bit word, shift the word to
the right, not to the left.Signed-off-by: Nikolaus Schulz
Signed-off-by: Guenter Roeck
Signed-off-by: Greg Kroah-Hartman -
commit 55a2bb4a6d5e8c7b324d003e130fd9aaf33be4e6 upstream.
commit adb5066 "ath9k_hw: do not apply the 2.4 ghz ack timeout
workaround to cts" reduced the hardware CTS timeout to the normal
values specified by the standard, but it turns out while it doesn't
need the same extra time that it needs for the ACK timeout, it
does need more than the value specified in the standard, but only
for 2.4 GHz.This patch brings the CTS timeout value in sync with the initialization
values, while still allowing adjustment for bigger distances.Signed-off-by: Felix Fietkau
Reported-by: Seth Forshee
Reported-by: Marek Lindner
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit f88373fa47f3ce6590fdfaa742d0ddacc2ae017f upstream.
commit b4a82a0 "ath9k_hw: fix interpretation of the rx KeyMiss flag"
fixed the interpretation of the KeyMiss flag for keycache based lookups,
however WEP encryption uses a static index, so KeyMiss is always asserted
for it, even though frames are decrypted properly.
Fix this by clearing the ATH9K_RXERR_KEYMISS flag if no keycache based
lookup was performed.Signed-off-by: Felix Fietkau
Reported-by: Laurent Bonnans
Reported-by: Jurica Vukadin
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 07445f688218a48bde72316aed9de4fdcc173131 upstream.
all works need to be initialized before ieee80211_register_hw
to prevent mac80211 call backs such as drv_start, drv_config
getting started. otherwise we would queue/cancel works before
initializing them and it leads to kernel panic.
this issue can be recreated with the following script
in Chrome laptops with AR928X cards, with background scan
running (or) Network manager is runningwhile true
do
sudo modprobe -v ath9k
sleep 3
sudo modprobe -r ath9k
sleep 3
doneEIP: [] __cancel_work_timer+0xb8/0xe1 SS:ESP 0068:f6be9d70
---[ end trace 4f86d6139a9900ef ]---
Registered led device: ath9k-phy0
ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xf88a0000,
irq=16
Kernel panic - not syncing: Fatal exception
Pid: 456, comm: wpa_supplicant Tainted: G D
3.0.13 #1
Call Trace:
[] panic+0x53/0x14a
[] oops_end+0x73/0x81
[] die+0x4c/0x55
[] do_trap+0x7c/0x83
[] ? do_bounds+0x58/0x58
[] do_invalid_op+0x77/0x81
[] ? __cancel_work_timer+0xb8/0xe1
[] ? sched_clock_cpu+0x81/0x11f
[] ? wait_on_work+0xe2/0xf7
[] error_code+0x67/0x6c
[] ? wait_consider_task+0x4ba/0x84c
[] ? __cancel_work_timer+0xb8/0xe1
[] ? try_to_del_timer_sync+0x5f/0x67
[] cancel_work_sync+0xf/0x11
[] ath_set_channel+0x62/0x25c [ath9k]
[] ? ath9k_tx_last_beacon+0x26a/0x85c [ath9k]
[] ath_radio_disable+0x3f1/0x68e [ath9k]
[] ieee80211_hw_config+0x111/0x116 [mac80211]
[] __ieee80211_recalc_idle+0x919/0xa37 [mac80211]
[] __ieee80211_recalc_idle+0xa33/0xa37 [mac80211]
[] __dev_open+0x82/0xabCc: Gary Morain
Cc: Paul Stewart
Cc: Vasanthakumar Thiagarajan
Tested-by: Mohammed Shafi Shajakhan
Signed-off-by: Rajkumar Manoharan
Signed-off-by: Mohammed Shafi Shajakhan
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit e57b6886f555ab57f40a01713304e2053efe51ec upstream.
According to a bug report, it doesn't have one.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44263
Acked-by: Chris Wilson
Signed-Off-by: Daniel Vetter
Signed-off-by: Keith Packard
Signed-off-by: Greg Kroah-Hartman -
commit c898261c0dad617f0f1080bedc02d507a2fcfb92 upstream.
It is never correct to use intel_crtc->bpp in intel_dp_link_required,
so instead pass an explicit bpp in to this function. This patch
only supports 18bpp and 24bpp modes, which means that 10bpc modes will
be computed incorrectly. Fixing that will require more extensive
changes, and so must be addressed separately from this bugfix.intel_dp_link_required is called from intel_dp_mode_valid and
intel_dp_mode_fixup.* intel_dp_mode_valid is called to list supported modes; in this case,
the current crtc values cannot be relevant as the modes in question
may never be selected. Thus, using intel_crtc->bpp is never right.* intel_dp_mode_fixup is called during mode setting, but it is run
well before ironlake_crtc_mode_set is called to set intel_crtc->bpp,
so using intel_crtc-bpp in this path can only ever get a stale
value.Cc: Lubos Kolouch
Cc: Adam Jackson
Reviewed-by: Daniel Vetter
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42263
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44881
Tested-by: Dave Airlie
Tested-by: camalot@picnicpark.org (Dell Latitude 6510)
Tested-by: Roland Dreier
Signed-off-by: Keith Packard
Signed-off-by: Greg Kroah-Hartman -
commit 7a0153ee15575a4d07b5da8c96b79e0b0fd41a12 upstream.
By adding following objects:
bench/mem-memcpy-x86-64-asm.o
the x86_64 perf binary ended up with executable stack.The reason was that above object are assembler sourced and is missing the
GNU-stack note section. In such case the linker assumes that the final binary
should not be restricted at all and mark the stack as RWX.Adding section ".note.GNU-stack" definition to mentioned object, with all
flags disabled, thus omiting this object from linker stack flags decision.Problem introduced in:
$ git describe ea7872b
v2.6.37-rc2-19-gea7872bReported-at: https://bugzilla.redhat.com/show_bug.cgi?id=783570
Reported-by: Clark Williams
Acked-by: Eric Dumazet
Cc: Corey Ashford
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/1328100848-5630-1-git-send-email-jolsa@redhat.com
Signed-off-by: Jiri Olsa
[ committer note: Backported fix to perf/urgent (3.3-rc2+) ]
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman -
commit a4a03fc7ef89020baca4f19174e6a43767c6d78a upstream.
This patch fixes an issue where perf report shows nan% for certain
perf.data files. The below is from a report for a do_fork probe:-nan% sshd [kernel.kallsyms] [k] do_fork
-nan% packagekitd [kernel.kallsyms] [k] do_fork
-nan% dbus-daemon [kernel.kallsyms] [k] do_fork
-nan% bash [kernel.kallsyms] [k] do_forkA git bisect shows commit f3bda2c as the cause. However, looking back
through the git history, I saw commit 640c03c which seems to have
removed the required initialization for perf_sample->period. The problem
only started showing after commit f3bda2c. The below patch re-introduces
the initialization and it fixes the problem for me.With the below patch, for the same perf.data:
73.08% bash [kernel.kallsyms] [k] do_fork
8.97% 11-dhclient [kernel.kallsyms] [k] do_fork
6.41% sshd [kernel.kallsyms] [k] do_fork
3.85% 20-chrony [kernel.kallsyms] [k] do_fork
2.56% sendmail [kernel.kallsyms] [k] do_forkThis patch applies over current linux-tip commit 9949284.
Problem introduced in:
$ git describe 640c03c
v2.6.37-rc3-83-g640c03cCc: Ananth N Mavinakayanahalli
Cc: Ingo Molnar
Cc: Robert Richter
Cc: Srikar Dronamraju
Link: http://lkml.kernel.org/r/20120203170113.5190.25558.stgit@localhost6.localdomain6
Signed-off-by: Naveen N. Rao
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman -
commit 0629292117572a60465f38cdedde2f8164c3df0b upstream.
Recent addition of code to find already allocated VFs failed to take
account that systems with 2 or more multi-port SR-IOV capable controllers
might have already enabled VFs. Make sure that the VFs the function is
finding are actually subordinate to the particular instance of the adapter
that is looking for them and not subordinate to some device that has
previously enabled SR-IOV.This is applicable to 3.2+ kernels.
Reported-by: David Ahern
Signed-off-by: Greg Rose
Tested-by: Robert E Garrett
Signed-off-by: Jeff Kirsher
Signed-off-by: Greg Kroah-Hartman -
commit a4b08329c74985e5cc3a44b6d2b2c59444ed8079 upstream.
Recent addition of code to find already allocated VFs failed to take
account that systems with 2 or more multi-port SR-IOV capable controllers
might have already enabled VFs. Make sure that the VFs the function is
finding are actually subordinate to the particular instance of the adapter
that is looking for them and not subordinate to some device that has
previously enabled SR-IOV.This bug exists in 3.2 stable as well as 3.3 release candidates.
Reported-by: David Ahern
Signed-off-by: Greg Rose
Tested-by: Robert E Garrett
Signed-off-by: Jeff Kirsher
Signed-off-by: Greg Kroah-Hartman
14 Feb, 2012
15 commits
-
commit a8eb28480e9b637cc78b9aa5e08612ba97e1317a upstream.
The driver uses the pstate number from the status register as index in
its table of ACPI pstates (powernow_table). This is wrong as this is
not a 1-to-1 mapping.For example we can have _PSS information to just utilize Pstate 0 and
Pstate 4, ie.powernow-k8: Core Performance Boosting: on.
powernow-k8: 0 : pstate 0 (2200 MHz)
powernow-k8: 1 : pstate 4 (1400 MHz)In this example the driver's powernow_table has just 2 entries. Using
the pstate number (4) as index into this table is just plain wrong.Signed-off-by: Andreas Herrmann
Signed-off-by: Dave Jones
Signed-off-by: Greg Kroah-Hartman -
commit 201bf0f129e1715a33568d1563d9a75b840ab4d3 upstream.
Due to CPB we can't directly map SW Pstates to Pstate MSRs. Get rid of
the paranoia check. (assuming that the ACPI Pstate information is
correct.)Signed-off-by: Andreas Herrmann
Signed-off-by: Dave Jones
Signed-off-by: Greg Kroah-Hartman -
commit b5266ea675c5a041e2852c7ccec4cf2d4f5e0cf4 upstream.
Signed-off-by: Axel Lin
Acked-by: Michał Mirosław
Signed-off-by: Greg Kroah-Hartman -
commit 9256a4789be3dae37d00924c03546ba7958ea5a3 upstream.
I discovered this deadlock condition awhile ago working on RAMster
but it affects zcache as well. The list spinlock must be
locked prior to the page spinlock and released after. As
a result, the page copy must also be done while the locks are held.Applies to 3.2. Konrad, please push (via GregKH?)...
this is definitely a bug fix so need not be pushed during
a -rc0 window.Signed-off-by: Dan Magenheimer
Acked-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman -
commit e8b4553457e78bcff90f70a31212a40a8fd4f0db upstream.
SWIZ_BITS > 8 results in a much larger number of "tmem_obj"
allocations, likely one per page-placed-in-frontswap. The
tmem_obj is not huge (roughly 100 bytes), but it is large
enough to add a not-insignificant memory overhead to zcache.The SWIZ_BITS=8 will get roughly the same lock contention
without the space wastage.The effect of SWIZ_BITS can be thought of as "2^SWIZ_BITS is
the number of unique oids that be generated" (This concept is
limited to frontswap's use of tmem).Acked-by: Seth Jennings
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman -
commit 1608ea5f4b5d6262cd6e808839491cfb2a67405a upstream.
As ZTE have and will use more pid for new products this year,
so we need to add some new zte 3g-dongle's pid on option.c ,
and delete one pid 0x0154 because it use for mass-storage port.Signed-off-by: Rui li
Signed-off-by: Greg Kroah-Hartman -
commit 90451e6973a5da155c6f315a409ca0a8d3ce6b76 upstream.
Signed-off-by: Milan Kocian
Signed-off-by: Greg Kroah-Hartman -
commit e4436a7c17ac2b5e138f93f83a541cba9b311685 upstream.
The Netlogic XLP SoC's on-chip USB controller appears as a PCI
USB device, but does not need the EHCI/OHCI handoff done in
usb/host/pci-quirks.c.The pci-quirks.c is enabled for all vendors and devices, and is
enabled if USB and PCI are configured.If we do not skip the qurik handling on XLP, the readb() call in
ehci_bios_handoff() will cause a crash since byte access is not
supported for EHCI registers in XLP.Signed-off-by: Jayachandran C
Acked-by: Alan Stern
Signed-off-by: Greg Kroah-Hartman -
commit 683da59d7b8ae04891636d4b59893cd4e9b0b7e5 upstream.
ab943a2e125b (USB: gadget: gadget zero uses new suspend/resume hooks)
introduced a copy-paste error where f_loopback.c writes to a variable
declared in f_sourcesink.c. This prevents one from creating gadgets
that only have a loopback function.Signed-off-by: Timo Juhani Lindfors
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit 9c0a835a9d9aed41bcf9c287f5069133a6e2a87b upstream.
The usb/ch9.h will be installed to /usr/include/linux,
and be used from user space.
But le16_to_cpu() is only defined for kernel code.
Without this patch, user space compile will be broken.
Special thanks to Stefan BeckerReported-by: Stefan Becker
Signed-off-by: Kuninori Morimoto
Signed-off-by: Felipe Balbi
Signed-off-by: Greg Kroah-Hartman -
commit 8c213fa59199f9673d66970d6940fa093186642f upstream.
In https://bugs.archlinux.org/task/27996, failure of driver r8712u is
reported, with a timeout during module loading due to synchronous loading
of the firmware. The code now uses request_firmware_nowait().Signed-off-by: Larry Finger
Signed-off-by: Greg Kroah-Hartman -
commit 1793bf1deddc8ce25dc41925d5dbe64536c841b6 upstream.
Add USB ID for SITECOM WLA-1000 V1 001 WLAN
Reported-and-tested-by: Roland Gruber
Reported-and-tested-by: Dario Lucia
Signed-off-by: Larry Finger
Signed-off-by: Greg Kroah-Hartman -
commit 3589e74595a4332ebf77b5ed006f3c6686071ecd upstream.
Asus_oled triggers the following bug on module unloading:
usbcore: deregistering interface driver asus-oled
BUG: unable to handle kernel NULL pointer dereference at 0000000000000038
IP: [] sysfs_delete_link+0x30/0x66Call Trace:
[] device_remove_class_symlinks+0x6b/0x70
[] device_del+0x9f/0x1ab
[] device_unregister+0x11/0x1e
[] asus_oled_disconnect+0x4f/0x9e [asus_oled]
[] usb_unbind_interface+0x54/0x103
[] __device_release_driver+0xa2/0xeb
[] driver_detach+0x87/0xad
[] bus_remove_driver+0x91/0xc1
[] driver_unregister+0x66/0x6e
[] usb_deregister+0xbb/0xc4
[] asus_oled_exit+0x2f/0x31 [asus_oled]
[] sys_delete_module+0x1b8/0x21b
[] ? do_munmap+0x2ef/0x313
[] system_call_fastpath+0x16/0x1bThis is due to an incorrect destruction sequence in asus_oled_exit().
Fix the order, fixes the bug. Tested on an Asus G50V laptop only.
Cc: Jakub Schmidtke
Signed-off-by: Pekka Paalanen
Signed-off-by: Greg Kroah-Hartman -
commit 635032cb397b396241372fa0ff36ae758e658b23 upstream.
Programming an image was broken, because odev->buf_offs was not advanced
for val == 0 in append_values(). This regression was introduced in:commit 1ff12a4aa354bed093a0240d5e6347b1e27601bc
Author: Kevin A. Granade
Date: Sat Sep 5 01:03:39 2009 -0500Staging: asus_oled: Cleaned up checkpatch issues.
Fix the image processing by special-casing val == 0.
I have tested this change on an Asus G50V laptop only.
Cc: Jakub Schmidtke
Cc: Kevin A. Granade
Signed-off-by: Pekka Paalanen
Signed-off-by: Greg Kroah-Hartman
