This interface is mainly intended (and implemented) for ACPI _PPC BIOS
frequency limitations, but other cpufreq drivers can also use it for
similar use-cases.
Why is this needed:
Currently it's not obvious why cpufreq got limited.
People see cpufreq/scaling_max_freq reduced, but this could have
happened by:
- any userspace prog writing to scaling_max_freq
- thermal limitations
- hardware (_PPC in ACPI case) limitiations
Therefore export bios_limit (in kHz) to:
- Point the user that it's the BIOS (broken or intended) which limits
frequency
- Export it as a sysfs interface for userspace progs.
While this was a rarely used feature on laptops, there will appear
more and more server implemenations providing "Green IT" features like
allowing the service processor to limit the frequency. People want
to know about HW/BIOS frequency limitations.
All ACPI P-state driven cpufreq drivers are covered with this patch:
- powernow-k8
- powernow-k7
- acpi-cpufreq
Tested with a patched DSDT which limits the first two cores (_PPC returns 1)
via _PPC, exposed by bios_limit:
# echo 2200000 >cpu2/cpufreq/scaling_max_freq
# cat cpu*/cpufreq/scaling_max_freq
2600000
2600000
2200000
2200000
# #scaling_max_freq shows general user/thermal/BIOS limitations
# cat cpu*/cpufreq/bios_limit
2600000
2600000
2800000
2800000
# #bios_limit only shows the HW/BIOS limitation
CC: Pallipadi Venkatesh <venkatesh.pallipadi@intel.com>
CC: Len Brown <lenb@kernel.org>
CC: davej@codemonkey.org.uk
CC: linux@dominikbrodowski.net
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Dave Jones <davej@redhat.com>
No need to export these symbols; make them static.
cpufreq_add_dev_policy
cpufreq_add_dev_symlink
cpufreq_add_dev_interface
Signed-off-by: Alex Chiang <achiang@hp.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Same adustments that have been added to the ondemand recently.
Signed-off-by: Thomas Renninger <trenn@suse.de>
Signed-off-by: Dave Jones <davej@redhat.com>
Added missing mach/i2c.h and linux/io.h header file includes
Signed-off-by: Kevin Wells <kevin.wells@nxp.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Limit minimum jiffie timeout to 2 to prevent early timeout on systems
with low tick rates
Signed-off-by: Kevin Wells <kevin.wells@nxp.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
As this struct is exposed to user space and the API was added for this
release it's a bit of a pain for the C++ world and we still have time to
fix it. Rename the fields before we end up with that pain in an actual
release.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Reported-by: Olivier Goffart
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 86cf898e1d ("intel-iommu: Check for
'DMAR at zero' BIOS error earlier.") was supposed to work by pretending
not to detect an IOMMU if it was actually being reported by the BIOS at
physical address zero.
However, the intel_iommu_init() function is called unconditionally, as
are the corresponding functions for other IOMMU hardware.
So the patch only worked if you have RAM above the 4GiB boundary. It
caused swiotlb to be initialised when no IOMMU was detected during early
boot, and thus the later IOMMU init would refuse to run.
But if you have less RAM than that, swiotlb wouldn't get set up and the
IOMMU _would_ still end up being initialised, even though we never
claimed to detect it.
This patch also sets the dmar_disabled flag when the error is detected
during the initial detection phase -- so that the later call to
intel_iommu_init() will return without doing anything, regardless of
whether swiotlb is used or not.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq:
[CPUFREQ] Fix stale cpufreq_cpu_governor pointer
[CPUFREQ] Resolve time unit thinko in ondemand/conservative govs
[CPUFREQ] speedstep-ich: fix error caused by 394122ab14
[CPUFREQ] Fix use after free on governor restore
[CPUFREQ] acpi-cpufreq: blacklist Intel 0f68: Fix HT detection and put in notification message
[CPUFREQ] powernow-k8: Fix test in get_transition_latency()
[CPUFREQ] longhaul: select Longhaul version 2 for capable CPUs
* 'agp-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/agp-2.6:
agp/intel-agp: Set dma_mask for capable chipsets before agp_add_bridge()
We should set this before calling agp_add_bridge() so that it's done
before we map the scratch page too.
This should probably fix the regression reported as k.o. bug #14627.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (42 commits)
cxgb3: fix premature page unmap
ibm_newemac: Fix EMACx_TRTR[TRT] bit shifts
vlan: Fix register_vlan_dev() error path
gro: Fix illegal merging of trailer trash
sungem: Fix Serdes detection.
net: fix mdio section mismatch warning
ppp: fix BUG on non-linear SKB (multilink receive)
ixgbe: Fixing EEH handler to handle more than one error
net: Fix the rollback test in dev_change_name()
Revert "isdn: isdn_ppp: Use SKB list facilities instead of home-grown implementation."
TI Davinci EMAC : Fix Console Hang when bringing the interface down
smsc911x: Fix Console Hang when bringing the interface down.
mISDN: fix error return in HFCmulti_init()
forcedeth: mac address fix
r6040: fix version printing
Bluetooth: Fix regression with L2CAP configuration in Basic Mode
Bluetooth: Select Basic Mode as default for SOCK_SEQPACKET
Bluetooth: Set general bonding security for ACL by default
r8169: Fix receive buffer length when MTU is between 1515 and 1536
can: add the missing netlink get_xstats_size callback
...
* 'sh/for-2.6.32' of git://git.kernel.org/pub/scm/linux/kernel/git/lethal/sh-2.6:
sh: Fixup last users of irq_chip->typename
uio: pm_runtime_disable is needed if failed
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6:
tty: cp210x: Fix carrier handling
tty_port: If we are opened non blocking we still need to raise the carrier
unmap Rx page only when guaranteed that this page won't be
used anymore to allocate rx page chunks.
Signed-off-by: Divy Le Ray <divy@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The TRT bit shifts were reversed for EMAC4 and non-EMAC4 during the
port from ibm_emac to ibm_newemac. This patch corrects that error.
Signed-off-by: Dave Mitchell <dmitchell@appliedmicro.com>
Acked-by: Feng Kan <fkan@appliedmicro.com>
Acked-by: Prodyut Hazarika <phazarika@appliedmicro.com>
Acked-by: Stefan Roese <sr@denx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Dave,
Attached is an update of my patch against the cpufreq fixes branch.
Before applying the patch I compiled and booted the tree to see if the panic
was still there -- to my surprise it was not. This is because of the conversion
of cpufreq_cpu_governor to a char[].
While the panic is kaput, the problem of stale data continues and my patch is
still valid. It is possible to end up with the wrong governor after hotplug
events because CPUFREQ_DEFAULT_GOVERNOR is statically linked to a default,
while the cpu siblings may have had a different governor assigned by a user.
ie) the patch is still needed in order to keep the governors assigned
properly when hotplugging devices
Signed-off-by: Prarit Bhargava <prarit@redhat.com>
Signed-off-by: Dave Jones <davej@redhat.com>
ondemand and conservative governors are messing up time units in the
code path where NO_HZ is not enabled and ignore_nice is set. The walltime
idletime stored is in jiffies and nice time calculation is happening in
microseconds.
The problem was reported and diagnosed by Alexander here.
http://marc.info/?l=linux-kernel&m=125752550404513&w=2
The patch below fixes this thinko.
Reported-by: Alexander Miller <Miller@fmi.uni-stuttgart.de>
Tested-by: Alexander Miller <Miller@fmi.uni-stuttgart.de>
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Currently on governer backup/restore path we storing governor's pointer.
This is wrong because one may unload governor's module after cpu goes
offline. As result use-after-free will take place on restored cpu.
It is not easy to exploit this bug, but still we have to close this
issue ASAP. Issue was introduced by following commit
084f349394
##TESTCASE##
#!/bin/sh -x
modprobe acpi_cpufreq
# Any non default governor, in may case it is "ondemand"
modprobe cpufreq_ondemand
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
rmmod acpi_cpufreq
rmmod cpufreq_ondemand
modprobe acpi_cpufreq # << use-after-free here.
Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org>
Signed-off-by: Dave Jones <davej@redhat.com>
The return should be negative on errors
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Sudhakar Rajashekhara <sudhakar.raj@ti.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Return a negative error value instead of a positive
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: dmitry pervushin <dpervushin@embeddedalley.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Add D-Link DWM-162-U5 device id 1e0e:ce16 into option driver. The device
has 4 interfaces, of which 1 is handled by storage and the other 3 by
option driver.
The device appears first as CD-only 05c6:2100 device and must be
switched to 1e0e:ce16 mode either by using "eject CD" or usb_modeswitch.
The MessageContent for usb_modeswitch.conf is:
"55534243e0c26a85000000000000061b000000020000000000000000000000"
Signed-off-by: Zhang Le <r0bertz@gentoo.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch (as1299b) fixes a bug in an error-handling path of usbmon's
binary interface. The storage area for URB data is divided into
fixed-size blocks. If an URB's data can't be copied, the area
reserved for it should be decreased to the size of the truncated
information (rounded up to a block boundary). Rounding up the amount
to be removed and subtracting it from the reserved size is definitely
the wrong thing to do.
Also, when the data for an isochronous URB can't be copied, we can
still copy the isoc packet descriptors. In fact the current code does
copy the descriptors, but then sets the capture length to 0 so they
remain inaccessible. The capture length should be reduced to the
length of the descriptors, not set to 0.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Pete Zaitcev <zaitcev@redhat.com>
CC: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The scratchpad_free() function uses xhci->page_size to free some memory
with pci_free_consistent(). However, the page_size is set to zero before
the call, causing kernel oopses on driver unload. Call scratchpad_free()
before setting xhci->page_size to zero.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Acked-by: John Youn <John.Youn@synopsys.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The trb_in_td() function in the xHCI driver is supposed to translate a
physical transfer buffer request (TRB) into a virtual pointer to the ring
segment that TRB is in.
Unfortunately, a mistake in this function may cause endless loops as the
driver searches through the linked list of ring segments over and over
again. Fix a couple bugs that may lead to loops or bad output:
1. Bail out if we get a NULL pointer when translating the segment's
private structure and the starting DMA address of the segment chunk. If
this happens, we've been handed a starting TRB pointer from a different
ring.
2. Make sure the function works when there's multiple segments in the
ring. In the while loop to search through the ring segments, use the
current segment variable (cur_seg), rather than the starting segment
variable (start_seg) that is passed in.
3. Stop searching the ring if we've run through all the segments in the
ring.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If the xHCI driver fails during the memory initialization, xhci->ir_set
may not be a valid pointer. Check that it points to valid DMA'able memory
before writing to that address during the memory freeing process.
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Am Donnerstag, 10. September 2009 15:43:53 schrieb Dietmar Hilbrich:
> Hello,
>
> i have the following problem with the cdc-acm - driver:
>
> I'm using the driver with an "Ericsson F3507G" on a Thinkpad T400.
>
> If a disable the device (with the RFKill-Switch) while it is used by a
> programm like ppp, the driver doesn't seem to correctly clean up the tty,
> even after the program has been closed)
>
> The tty is still active (e.g. there still exists an entry in
> /sys/dev/char/166:0 if ttyACM0 was used) and if a reacticate the device,
> this device entry will be skipped and the Device-Nodes ttyACM1, ttyACM2
> and ttyACM3 will be used.
>
> This problem was introduced with the commit
> 10077d4a66 (before 2.6.31-rc1) and still
> exists in 2.6.31.
>
> I was able the fix this problem with the following patch:
>
> diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
> index 2bfc41e..0970d2f 100644
> --- a/drivers/usb/class/cdc-acm.c
> +++ b/drivers/usb/class/cdc-acm.c
> @@ -676,6 +676,7 @@ static void acm_tty_hangup(struct tty_struct *tty)
> struct acm *acm = tty->driver_data;
> tty_port_hangup(&acm->port);
> acm_port_down(acm, 0);
> + acm_tty_unregister(acm);
> }
I have the same problem with cdc-acm (I'm using a Samsung SGH-U900): when I
unplug it from the USB port during a PPP connection, the ppp daemon gets the
hangup correctly (and closes the device), but the struct acm corresponding to
the device disconnected is not freed. Hence reconnecting the device results in
creation of /dev/ttyACM(x+1). The same happens when the system is hibernated
during a PPP connection.
This memory leak is due to the fact that when the tty is hung up,
tty_port_close_start() returns always zero, and acm_tty_close() never reaches
the point where acm_tty_unregister() is called.
Here is a fix for this.
Signed-off-by: Francesco Lavra <francescolavra@interfree.it>
Acked-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If acm_rx_tasklet() gets called before tty_port_block_til_ready()
returns, then bulk IN urbs may not be sent. This fixes it.
Signed-off-by: Henry Gebhardt <gebhardt@astro.uni-tuebingen.de>
Acked-by: Oliver Neukum <oliver@neukum.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
The following patch in the driver is required to avoid USB 1.1 device
failures that may occur due to requests from USB OHCI controllers may
be overwritten if the latency for any pending request by the USB
controller is very long (in the range of milliseconds).
Signed-off-by: Libin Yang <libin.yang@amd.com>
Cc: David Brownell <dbrownell@users.sourceforge.net>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Original discussion:
http://thread.gmane.org/gmane.linux.usb.general/23217/focus=23248
or
http://marc.info/?l=linux-usb&m=125553790714133&w=29a68e39d4a broke carrier handling so that a
cp210x setup which needed the carrier lines set up (non CLOCAL) which did
not make a call which set the termios bits left the lines down even if
CLOCAL was not asserted.
Fix this not by reverting but by adding the proper dtr_rts and
carrier_raised methods. This both sets the modem lines properly and also
implements the correct blocking semantics for the port as required by
POSIX.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Reported-by: Karl Hiramoto <karl@hiramoto.org>
Tested-by: Karl Hiramoto <karl@hiramoto.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Original discussion:
http://thread.gmane.org/gmane.linux.usb.general/23217/focus=23248
or
http://marc.info/?l=linux-usb&m=125553790714133&w=2
The tty_port code inherited a bug common to various drivers it was based
upon. If the tty is opened O_NONBLOCK we do not wait for the carrier to be
raised but we must still raise our modem lines if appropriate.
(There is a second question here about whether we should do so if CLOCAL is
set but that can wait)
Signed-off-by: Alan Cox <alan@linux.intel.com>
Reported-by: Karl Hiramoto <karl@hiramoto.org>
Tested-by: Karl Hiramoto <karl@hiramoto.org>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6:
[SCSI] bfa: declare MODULE_FIRMWARE
[SCSI] gdth: Prevent negative offsets in ioctl CVE-2009-3080
[SCSI] libsas: do not set res = 0 in sas_ex_discover_dev()
[SCSI] Fix incorrect reporting of host protection capabilities
[SCSI] pmcraid: Fix ppc64 driver build for using cpu_to_le32 on U8 data type
[SCSI] ipr: add workaround for MSI interrupts on P7
[SCSI] scsi_transport_fc: Fix WARN message for FC passthru failure paths
[SCSI] bfa: fix test in bfad_os_fc_host_init()
* master.kernel.org:/home/rmk/linux-2.6-arm:
[ARM] pxa: ensure mfp is in correct range in mfp_{read,write}
[ARM] pxa/hx4700: fix hx4700 touchscreen pressure values
ARM: 5787/1: U300 COH 901 331 fixes
ARM: Fix warning in sa1100-flash.c
[ARM] Kirkwood: disable propagation of mbus error to the CPU local bus
[ARM] pxa: fix incorrect mfp_to_gpio() conversion
[ARM] pxa/colibri: fix AC97 ifdefs and add missing include
[ARM] pxa: fix missing underscores in mfp-pxa910.h
[ARM] pxa: fix interrupts number calculation when CONFIG_PXA_HAVE_ISA_IRQS=y
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lrg/voltage-2.6:
dereferencing freed memory regulator_fixed_voltage_remove()
regulator: Fix check of unsigned return value and transmit errors in wm831x_gp_ldo_get_mode()
regulator: Handle missing constraints in _regulator_disable()
* 'for-linus' of git://git.o-hand.com/linux-rpurdie-leds:
leds-gpio: fix possible crash on OF device unbinding
backlight: Fix backlight limiting on spitz/corgi devices
backlight: lcd - Fix wrong sizeof
* 'hostprogs-wmissing-prototypes' of git://git.kernel.org/pub/scm/linux/kernel/git/josh/linux-misc:
Makefile: Add -Wmising-prototypes to HOSTCFLAGS
oss: Mark loadhex static in hex2hex.c
dtc: Mark various internal functions static
dtc: Set "noinput" in the lexer to avoid an unused function
drm: radeon: Mark several functions static in mkregtable
arch/sparc/boot/*.c: Mark various internal functions static
arch/powerpc/boot/addRamDisk.c: Mark several internal functions static
arch/alpha/boot/tools/objstrip.c: Mark "usage" static
Documentation/vm/page-types.c: Declare checked_open static
genksyms: Mark is_reserved_word static
kconfig: Mark various internal functions static
kconfig: Make zconf.y work with current bison
We need to look for the 'shared-pins' property to get
this right.
Based upon a patch by Hermann Lauer.
Signed-off-by: David S. Miller <davem@davemloft.net>
This fixes the following warning:
WARNING: drivers/net/phy/built-in.o(.devexit.text+0x70): Section mismatch in reference from the function .mdio_gpio_bus_destroy() to the function .devinit.text:.mdio_gpio_bus_deinit()
The function __devexit .mdio_gpio_bus_destroy() references
a function __devinit .mdio_gpio_bus_deinit().
This is often seen when error handling in the exit function
uses functionality in the init path.
The fix is often to remove the __devinit annotation of
.mdio_gpio_bus_deinit() so it may be used outside an init section.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
PPP does not correctly call pskb_may_pull() on all necessary receive paths
before reading the PPP protocol, thus causing PPP to report seemingly
random 'unsupported protocols' and eventually trigger BUG_ON(skb->len <
skb->data_len) in skb_pull_rcsum() when receiving multilink protocol in
non-linear skbs.
ppp_receive_nonmp_frame() does not call pskb_may_pull() before reading the
protocol number. For the non-mp receive path this is not a problem, as
this check is done in ppp_receive_frame(). For the mp receive path,
ppp_mp_reconstruct() usually copies the data into a new linear skb.
However, in the case where the frame is made up of a single mp fragment,
the mp header is pulled and the existing skb used. This skb was then
passed to ppp_receive_nonmp_frame() without checking if the encapsulated
protocol header could safely be read.
Signed-off-by: Ben McKeegan <ben@netservers.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
After commmit 4b77b0a2ba EEH breaks
after the second error, since it calls pci_restore_state()
but it returns 0, since pci->state_saved is false.
So, this patch just call pci_save_state() after pci_restore_state().
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Panasonic CF-72 uses 6-byte protocol and does not need to be tied
to a particular port.
Signed-off-by: Abner Holsinger <9zabner@gmail.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Commit b7802c5c1e ("Input: psmouse - use boolean type") caused the
synaptics_hardware variable to be completely useless, as it is
constantly set to 'true' throughout the whole psmouse_extensions().
This was caused by the following hunk in the commit in question
- int synaptics_hardware = 0;
+ bool synaptics_hardware = true;
which is wrong and causes driver to issue extra reset when falling
back to bare PS/2 protocol.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This will fix some small issues with the COH 901 331 RTC driver:
- Interrupt is disabled after alarm so that we don't fire
multiple interrupts.
- We return 0 from the coh901331_alarm_irq_enable() ridding
a compile warning.
- We alter the name in the U300 device registry to match that
of the driver so they sucessfully resolve.
Signed-off-by: Linus Walleij <linus.walleij@stericsson.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
drivers/mtd/maps/sa1100-flash.c: In function 'sa1100_probe_subdev':
drivers/mtd/maps/sa1100-flash.c:214: warning: format '%d' expects type 'int', but argument 3 has type 'uint64_t'
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Don't dereference drvdata after it has been freed.
regards,
dan carpenter
Signed-off-by: Dan Carpenter <error27@gmail.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Liam Girdwood <lrg@slimlogic.co.uk>
If there are leds present in the OF tree, but the GPIOs for (some) of
them are unavailable, led_data doesn't get populated with correct
devices. Then, on device unbinding, one can crash the kernel.
Workaround this by setting led->gpio to invalid value early.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
On spitz (& similar) machines, if battery is running low, backlight
needs
to be limited to lower step. Unfortunately, current code uses &= for
limiting, turning backlight off completely for some backlight settings.
Fix that.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>
Thomas Renninger
Alex Chiang
Kevin Wells
Alan Cox
David Woodhouse
Linus Torvalds
Divy Le Ray
Dave Mitchell
Prarit Bhargava
Pallipadi, Venkatesh
Dmitry Monakhov
Roel Kluin
Zhang Le
Alan Stern
Sarah Sharp
Francesco Lavra
Henry Gebhardt
Libin Yang
David S. Miller
Stephen Rothwell
Ben McKeegan
Breno Leitao
Abner Holsinger
Jiri Kosina
Linus Walleij
Russell King
Dan Carpenter
Dmitry Eremin-Solenikov
Pavel Machek