aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2012-03-27mmc: omap_hsmmc: convert all pr_* to dev_*Rajendra Nayak1-4/+4
Convert all instances of pr_* prints within the driver to instead use dev_* prints. Reported-by: Russell King <[email protected]> Signed-off-by: Rajendra Nayak <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: sh_mmcif: fix MMC_GEN_CMD settingShimoda, Yoshihiro1-2/+0
The MMC_GEN_CMD (CMD56) doesn't need to check busy signal. So, the patch fixes the setting. Signed-off-by: Yoshihiro Shimoda <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: core: hs200 fixesSubhash Jadavani1-17/+21
This patch fixes following issues when HS200 is enabled: 1. If executing_tuning() host ops is called without mmc_host_clk_hold(), card clocks might get turned off (if MMC_CLK_GATING is enabled) while execute_tuning() is in progress. So this patch makes sure that execute_tuning() is called with mmc_host_clk_hold(). 2. If host timing mode is set to HS200 mode, there should not be any communication with the card until execute_tuning() is completed. But there is a chance that CMD6 might be sent to enable set HPI_EN (of HPI_MGMT field in EXT_CSD) before execute_tuning() is called. So this patch moves this operation after execute_tuning() is completed. Signed-off-by: Subhash Jadavani <[email protected]> Reviewed-by: [email protected] Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: omap_hsmmc: Fix "Unbalanced pm_runtime_enable!" warningTony Lindgren1-0/+1
Otherwise we can get following warning when re-loading the omap_hsmmc driver module when gpio_twl4030 module is not loaded: omap_hsmmc omap_hsmmc.0: Unbalanced pm_runtime_enable! omap_hsmmc omap_hsmmc.0: Unable to grab MMC CD IRQ omap_hsmmc: probe of omap_hsmmc.0 failed with error -22 Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: core: Clean up after mmc_pre_req if card was removedUlf Hansson1-20/+15
Make sure mmc_start_req cancels the prepared job, if the request was prevented to be started due to the card has been removed. This bug was introduced in commit: mmc: allow upper layers to know immediately if card has been removed Signed-off-by: Ulf Hansson <[email protected]> Reviewed-by: Per Forlin <[email protected]> Tested-by: Jaehoon Chung <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: start removing enable / disable APIAdrian Hunter9-242/+27
Most parts of the enable / disable API are no longer used and can be removed. Signed-off-by: Adrian Hunter <[email protected]> Tested-by: Venkatraman S <[email protected]> Tested-by: Jaehoon Chung <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: sdhci-spear: add pm callbacks to support hibernationShiraz Hashim1-7/+2
Signed-off-by: Shiraz Hashim <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: tmio_mmc: do not enable card hotplug interrupts, if unusedGuennadi Liakhovetski1-1/+6
If TMIO MMC is used in polling mode, or the card is non-removable, or card-detection is performed, using an external interrupt, there is no need to enable controller native card hotplug interrupts. Signed-off-by: Guennadi Liakhovetski <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: omap_hsmmc: Don't expect MMC1 to always have vmmc supplyRajendra Nayak1-29/+2
MMC1 is not the only instance that can be used/wired for SD. So remove this assumption from the driver. Now that all the mmc id based usage is removed, get rid of all the DEVID defines and also the 'id' field from the omap_hsmmc_host structure. Signed-off-by: Rajendra Nayak <[email protected]> Tested-by: Venkatraman S <[email protected]> Tested-by: Balaji T K <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: omap_hsmmc: Get rid of omap_hsmmc_4_set_power functionRajendra Nayak1-20/+1
Now that omap_hsmmc_set_power() already has a check to return 0 if !host->vcc, it seems like it can be used even on MMC4 instead of the dummy omap_hsmmc_4_set_power(). This also helps get rid of all the host->id based check to populate the right function for on-chip/external level shifting and use omap_hsmmc_set_power() for all MMC modules. Signed-off-by: Rajendra Nayak <[email protected]> Tested-by: Venkatraman S <[email protected]> Tested-by: Balaji T K <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: omap_hsmmc: Get rid of omap_hsmmc_1_set_power functionRajendra Nayak1-27/+3
Use omap_hsmmc_235_set_poweri() (now renamed as omap_hsmmc_set_power()) for MMC1 instance as well and get rid of omap_hsmmc_1_set_power() completely. omap_hsmmc_235_set_power() seems to be implemented as a superset of omap_hsmmc_1_set_power() with additional functionality implemented based on additional checks and hence should just work for MMC1 as well. Signed-off-by: Rajendra Nayak <[email protected]> Tested-by: Venkatraman S <[email protected]> Tested-by: Balaji T K <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: omap_hsmmc: Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag to remove host->id ↵Balaji T K1-1/+1
based hardcoding Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag instead of host->id for identifying SD bus voltage capabilities. Signed-off-by: Balaji T K <[email protected]> Signed-off-by: Rajendra Nayak <[email protected]> Tested-by: Venkatraman S <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: omap_hsmmc: remove unused .set_sleep functionBalaji T K2-62/+0
set_sleep seems to be unused in omap_hsmmc driver. so get rid of it. Signed-off-by: Balaji T K <[email protected]> Signed-off-by: Rajendra Nayak <[email protected]> Tested-by: Venkatraman S <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: omap_hsmmc: use platform_get_resource_byname for tx/rx DMA channelsBalaji T K1-24/+11
Git rid of hardcoded tx/rx DMA channels based on pdev->id and use platform_get_resource_byname() to retrieve them instead. Signed-off-by: Balaji T K <[email protected]> Signed-off-by: Rajendra Nayak <[email protected]> Tested-by: Venkatraman S <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: core: Detect card removal on I/O errorUlf Hansson2-3/+22
To prevent I/O as soon as possible at card removal, a new detect work is re-scheduled without a delay to let a rescan remove the card device as soon as possible. Additionally, MMC_CAP2_DETECT_ON_ERR can now be used to handle "slowly" removed cards that a scheduled detect work did not detect as removed. To prevent further I/O requests for these lingering removed cards, check if card has been removed and then schedule a detect work to properly remove it. Signed-off-by: Ulf Hansson <[email protected]> Reviewed-by: Namjae Jeon <[email protected]> Acked-by: Linus Walleij <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: dw_mmc: Regression fix for non-IDMAC DMASeungwon Jeon1-16/+9
3ec7699d3bb1b0ee7 ("mmc: dw_mmc: Add support for pre_req and post_req") broke non-IDMAC DMA, because dw_mci_pre_dma_transfer() is valid only if using internal DMA. In case of using other DMA it returns -ENOSYS. It prevents the DMA operations. This patch makes dw_mci_pre_dma_transfer() effective in all DMA cases again. Reported-by: James Hogan <[email protected]> Signed-off-by: Seungwon Jeon <[email protected]> Reviewed-by: Namjae Jeon <[email protected]> Acked-by: James Hogan <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: dw_mmc: fix compile error when CONFIG_MMC_DW_IDMAC is disabledJaehoon Chung1-1/+1
When disable CONFIG_MMC_DW_IDMAC, can see the compiler error. Because in dw_mci_post_req(), called the dw_mci_get_dma_dir(). But that function is in #ifdef CONFIG_MMC_DW_IDMAC. I think that function is generic function. Not need the CONFIG_MMC_DW_IDMAC. Signed-off-by: Jaehoon Chung <[email protected]> Signed-off-by: Kyungmin Park <[email protected]> Acked-by: Seungwon Jeon <[email protected]> Acked-by: James Hogan <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27ARM: OMAP: hsmmc: add max_freq fieldDaniel Mack3-2/+9
External circuitry like level shifters may limit the maximum operation speed of the hsmmc controller. Add a field to struct omap2_hsmmc_info so boards can adjust the setting on demand. Signed-off-by: Daniel Mack <[email protected]> Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27mmc: atmel-mci: fix typoLudovic Desroches1-1/+1
Signed-off-by: Ludovic Desroches <[email protected]> Signed-off-by: Nicolas Ferre <[email protected]> Signed-off-by: Chris Ball <[email protected]>
2012-03-27dmaengine: imx: fix the build failure on x86_64Vinod Koul1-0/+1
commit 6bd081277ea0 "dmaengine: imx-dma: merge old dma-v1.c with imx-dma.c" removed the dependency in config for the imx dma driver, whereas it should depend on ARCH_MXS Signed-off-by: Vinod Koul <[email protected]>
2012-03-28apparmor: Fix change_onexec when called from a confined taskJohn Johansen2-1/+4
Fix failure in aa_change_onexec api when the request is made from a confined task. This failure was caused by two problems The AA_MAY_ONEXEC perm was not being mapped correctly for this case. The executable name was being checked as second time instead of using the requested onexec profile name, which may not be the same as the exec profile name. This mistake can not be exploited to grant extra permission because of the above flaw where the ONEXEC permission was not being mapped so it will not be granted. BugLink: http://bugs.launchpad.net/bugs/963756 Signed-off-by: John Johansen <[email protected]> Signed-off-by: James Morris <[email protected]>
2012-03-27ia64: vsyscall: Add missing paranthesisThomas Gleixner1-1/+1
commit 74a622b (ia64: vsyscall: Use seqcount instead of seqlock) broke the ia64 build. Reported-by: Tony Luck <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]>
2012-03-27sched/rt: Improve pick_next_highest_task_rt()Michael J Wang1-1/+1
Avoid extra work by continuing on to the next rt_rq if the highest prio task in current rt_rq is the same priority as our candidate task. More detailed explanation: if next is not NULL, then we have found a candidate task, and its priority is next->prio. Now we are looking for an even higher priority task in the other rt_rq's. idx is the highest priority in the current candidate rt_rq. In the current 3.3 code, if idx is equal to next->prio, we would start scanning the tasks in that rt_rq and replace the current candidate task with a task from that rt_rq. But the new task would only have a priority that is equal to our previous candidate task, so we have not advanced our goal of finding a higher prio task. So we should avoid the extra work by continuing on to the next rt_rq if idx is equal to next->prio. Signed-off-by: Michael J Wang <[email protected]> Acked-by: Steven Rostedt <[email protected]> Reviewed-by: Yong Zhang <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/r/2EF88150C0EF2C43A218742ED384C1BC0FC83D6B@IRVEXCHMB08.corp.ad.broadcom.com Signed-off-by: Ingo Molnar <[email protected]>
2012-03-27sched: Fix select_fallback_rq() vs cpu_active/cpu_onlinePeter Zijlstra3-36/+52
Commit 5fbd036b55 ("sched: Cleanup cpu_active madness"), which was supposed to finally sort the cpu_active mess, instead uncovered more. Since CPU_STARTING is ran before setting the cpu online, there's a (small) window where the cpu has active,!online. If during this time there's a wakeup of a task that used to reside on that cpu select_task_rq() will use select_fallback_rq() to compute an alternative cpu to run on since we find !online. select_fallback_rq() however will compute the new cpu against cpu_active, this means that it can return the same cpu it started out with, the !online one, since that cpu is in fact marked active. This results in us trying to scheduling a task on an offline cpu and triggering a WARN in the IPI code. The solution proposed by Chuansheng Liu of setting cpu_active in set_cpu_online() is buggy, firstly not all archs actually use set_cpu_online(), secondly, not all archs call set_cpu_online() with IRQs disabled, this means we would introduce either the same race or the race from fd8a7de17 ("x86: cpu-hotplug: Prevent softirq wakeup on wrong CPU") -- albeit much narrower. [ By setting online first and active later we have a window of online,!active, fresh and bound kthreads have task_cpu() of 0 and since cpu0 isn't in tsk_cpus_allowed() we end up in select_fallback_rq() which excludes !active, resulting in a reset of ->cpus_allowed and the thread running all over the place. ] The solution is to re-work select_fallback_rq() to require active _and_ online. This makes the active,!online case work as expected, OTOH archs running CPU_STARTING after setting online are now vulnerable to the issue from fd8a7de17 -- these are alpha and blackfin. Reported-by: Chuansheng Liu <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Cc: Mike Frysinger <[email protected]> Cc: [email protected] Link: http://lkml.kernel.org/n/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-03-27sched/x86/smp: Do not enable IRQs over calibrate_delay()Peter Zijlstra1-5/+0
We should not ever enable IRQs until we're fully set up. This opens up a window where interrupts can hit the cpu and interrupts can do wakeups, wakeups need state that isn't set-up yet, in particular this cpu isn't elegible to run tasks, so if any cpu-affine task that got created in CPU_UP_PREPARE manages to get a wakeup, its affinity mask will get broken and we'll run into lots of 'interesting' problems. Signed-off-by: Peter Zijlstra <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/n/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2012-03-27Merge branch 'devel-stable' into for-linusRussell King235-2451/+1068
Conflicts: arch/arm/Kconfig.debug arch/arm/plat-versatile/Kconfig Merge fixes: arch/arm/mach-integrator/Kconfig drivers/clocksource/Kconfig
2012-03-27Merge branches 'l2', 'pgt2' and 'misc' into for-linusRussell King80-473/+2168
2012-03-27ARM: fix Kconfig warning for HAVE_BPF_JITRussell King1-1/+1
Last night's randconfig and the allnoconfig builds spat out the following warning while building: warning: (ARM) selects HAVE_BPF_JIT which has unmet direct dependencies (NET) Acked-by: Mircea Gherzan <[email protected]> Signed-off-by: Russell King <[email protected]>
2012-03-27Merge branch 'next' into for-linusDmitry Torokhov12-202/+694
Conflicts: drivers/input/tablet/wacom_sys.c
2012-03-27Input: tegra-kbc - allocate pdata before using itViresh Kumar1-0/+1
Following commit broke DT support for tegra-kbc by removing pdata allocation completely: commit 023cea0ecfa2df034096c3f4afa796a0b2d1188a Author: Shridhar Rasal <[email protected]> Date: Fri Feb 3 00:27:30 2012 -0800 Input: tegra-kbc - allow skipping setting up some of GPIO pins This patch restores it. Signed-off-by: Viresh Kumar <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2012-03-26xfs: Account log unmount transaction correctlyDave Chinner1-1/+2
There have been a few reports of this warning appearing recently: XFS (dm-4): xlog_space_left: head behind tail tail_cycle = 129, tail_bytes = 20163072 GH cycle = 129, GH bytes = 20162880 The common cause appears to be lots of freeze and unfreeze cycles, and the output from the warnings indicates that we are leaking around 8 bytes of log space per freeze/unfreeze cycle. When we freeze the filesystem, we write an unmount record and that uses xlog_write directly - a special type of transaction, effectively. What it doesn't do, however, is correctly account for the log space it uses. The unmount record writes an 8 byte structure with a special magic number into the log, and the space this consumes is not accounted for in the log ticket tracking the operation. Hence we leak 8 bytes every unmount record that is written. Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Ben Myers <[email protected]>
2012-03-26xfs: don't cache inodes read through bulkstatDave Chinner4-4/+28
When we read inodes via bulkstat, we generally only read them once and then throw them away - they never get used again. If we retain them in cache, then it simply causes the working set of inodes and other cached items to be reclaimed just so the inode cache can grow. Avoid this problem by marking inodes read by bulkstat not to be cached and check this flag in .drop_inode to determine whether the inode should be added to the VFS LRU or not. If the inode lookup hits an already cached inode, then don't set the flag. If the inode lookup hits an inode marked with no cache flag, remove the flag and allow it to be cached once the current reference goes away. Inodes marked as not cached will get cleaned up by the background inode reclaim or via memory pressure, so they will still generate some short term cache pressure. They will, however, be reclaimed much sooner and in preference to cache hot inodes. Signed-off-by: Dave Chinner <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Ben Myers <[email protected]>
2012-03-26acer-wmi: add quirk table for video backlight vendor modeLee, Chun-Yi2-2/+31
There have some acer laptop have broken _BCM implemenation, the AML code wrote value to EC register but firmware didn't change brighenss. Fortunately, the brightness control works on those machines with vendor mode. So, add quirk table for video backlight vendor mode and unregister acpi video interface on those machines. Tested on Acer TravelMate 4750 Cc: Carlos Corbacho <[email protected]> Cc: Matthew Garrett <[email protected]> Cc: Dmitry Torokhov <[email protected]> Cc: Corentin Chary <[email protected]> Cc: Thomas Renninger <[email protected]> Signed-off-by: Lee, Chun-Yi <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2012-03-26i2c-algo-bit: Don't resched on clock stretchingJean Delvare1-1/+1
Clock stretching is not supposed to last long, so asking to be rescheduled while waiting for the clock line to be released by a slave makes little sense. Odds are that the clock line will long have been released when we run again, so we will have lost time and may even get an SMBus timeout because of this. So just busy-wait in that case. This also participates in the effort to make i2c-algo-bit usable in contexts that can't sleep. Signed-off-by: Jean Delvare <[email protected]> Cc: Ben Skeggs <[email protected]>
2012-03-26i2c: Update the FSF addressJean Delvare15-15/+30
Signed-off-by: Jean Delvare <[email protected]>
2012-03-26i2c: Convert drivers/i2c/muxes/* to use module_i2c_driver()Axel Lin2-24/+2
This patch converts the drivers in drivers/i2c/muxes/* to use the module_i2c_driver() macro which makes the code smaller and a bit simpler. Signed-off-by: Axel Lin <[email protected]> Acked-by: Wolfram Sang <[email protected]> Cc: Guenter Roeck <[email protected]> Cc: Michael Lawnick <[email protected]> Cc: Ben Dooks <[email protected]> Signed-off-by: Jean Delvare <[email protected]>
2012-03-26i2c-i801: Use usleep_range to wait for command completionJean Delvare1-12/+12
Use usleep_range instead of msleep when waiting for command completion. Most SMBus commands complete in less than 2 jiffies so this brings a pleasant performance boost. Strongly inspired from a similar change by Olivier Sobrie to the i2c-isch driver. Signed-off-by: Jean Delvare <[email protected]> Cc: Olivier Sobrie <[email protected]>
2012-03-26i2c-i801: Add device IDs for Intel Lynx PointSeth Heasley3-0/+5
Add the SMBus controller device IDs for the Intel Lynx Point PCH. Signed-off-by: Seth Heasley <[email protected]> Signed-off-by: Jean Delvare <[email protected]>
2012-03-26i2c-isch: Decrease delay in command completion check loopOlivier Sobrie1-5/+5
Generally it is not needed to wait for 1 msec, the SMBus get often ready in less than 200 usecs. msleep(1) can wait up to 20 msecs... It has a significant impact when there is a burst of transactions on the bus. Signed-off-by: Olivier Sobrie <[email protected]> Signed-off-by: Jean Delvare <[email protected]>
2012-03-26i2c-gpio: Use linux/gpio.h rather than asm/gpio.hMark Brown1-2/+1
Direct inclusion of asm/gpio.h has been deprecated for a while now due to the cross platform gpiolib. Signed-off-by: Mark Brown <[email protected]> Signed-off-by: Jean Delvare <[email protected]>
2012-03-26drivers/platform/x86/amilo-rfkill.c::amilo_rfkill_probe() avoid NULL derefJesper Juhl1-1/+4
In drivers/platform/x86/amilo-rfkill.c::amilo_rfkill_probe() the call to dmi_first_match() may fail and return NULL. If it does return NULL, then we'll be dereferencing a NULL pointer in the rfkill_alloc() call where we do 'system_id->driver_data' --> KABOOM! Avoid that problem by testing for a NULL return value from dmi_first_match() and bailing out if it fails. I was a bit uncertain about what to return in the failure case. In the end I settled for -ENXIO as the most logical error to return. Signed-off-by: Jesper Juhl <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2012-03-26samsung-laptop: unregister ACPI video module for some well known laptopsCorentin Chary1-4/+76
On these laptops, the ACPI video is not functional, and very unlikely to be fixed by the vendor. Note that intel_backlight works for some of these laptops, and the backlight from samsung-laptop always work. The good news is that newer laptops have functional ACPI video device and won't end up growing this list. Signed-off-by: Corentin Chary <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2012-03-26acer-wmi: No wifi rfkill on Sony machinesLee, Chun-Yi1-0/+1
The wireless rfkill should charged by sony-laptop but not acer-wmi. So, add Sony's SNY5001 acpi device to blacklist in acer-wmi. Tested on Sony Vaio Cc: Carlos Corbacho <[email protected]> Cc: Matthew Garrett <[email protected]> Cc: Mattia Dongili <[email protected]> Cc: Dimitris N <[email protected]> Tested-by: Dimitris N <[email protected]> Signed-off-by: Lee, Chun-Yi <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2012-03-26thinkpad-acpi: recognize Lenovo as version string in newer V-series BIOSManoj Iyer1-1/+1
The newer V series bios reports product version as 'Lenovo' instead of 'ThinkPad'. Recoginze this new string so that the module can load. Signed-off-by: Manoj Iyer <[email protected]> Signed-off-by: Matthew Garrett <[email protected]> Tested-by: James Ferguson <[email protected]> Tested-by: Dennis Chua <[email protected]> Tested-by: Ike Pan <[email protected]> Acked-by: Henrique de Moraes Holschuh <[email protected]>
2012-03-26asus-wmi: don't update power and brightness when using scalarCorentin Chary1-7/+13
But we can still do it on other boards, as this might happen if the backlight driver change when update_bl is called. Signed-off-by: Corentin Chary <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2012-03-26eeepc-wmi: split et2012 specific hacksCorentin Chary1-14/+20
Signed-off-by: Corentin Chary <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2012-03-26eeepc-wmi: refine quirks handlingCorentin Chary1-5/+8
Signed-off-by: Corentin Chary <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2012-03-26asus-nb-wmi: set panel_power correctlyCorentin Chary1-0/+2
Even if it's currently unused. Signed-off-by: Corentin Chary <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2012-03-26asus-wmi: move WAPF variable into quirks_entryCorentin Chary4-5/+9
Some models work better with different values of wapf, so move the variable into quriks_entry to make it more easy to give a specific value to different models. Based on original patch from AceLan Kao <[email protected]> Cc: AceLan Kao <[email protected]> Signed-off-by: Corentin Chary <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
2012-03-26asus-wmi: store backlight power status for AIO machineAceLan Kao3-16/+34
Due to some implementation reasons, ASUS ET2012 All-in-One machines can't report the correct backlight power status, it will always return 1. To track the backlight power status correctly, we have to store the status by ourselves. BTW, by the BIOS design, the backlight power will be turn on/off sequently, no matter what the value of the parameter will be. More over, the brightness adjustment command will turn on the backlight power. Those behaviors will make us fail to track the backlight power status. For example, While we are trying to turn on the backlight power, we will send out the brightness adjustment command and then trying to figure out if we have to turn on the backlight power, then send out the command. But, the real case is that, the backlight power turns on while sending the brightness adjustment command, and then we send out the command to turn on the backlight power, it actually will turn off the backlight power and the backlight power status we recorded becomes wrong. So, we have to seperate these two commands by a if statement. Signed-off-by: AceLan Kao <[email protected]> Signed-off-by: Corentin Chary <[email protected]> Signed-off-by: Matthew Garrett <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.