aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-07-20Subject: pinctrl: imx1-core: Fix debug output in .pin_config_set callbackUwe Kleine-König1-2/+1
imx1_pinconf_set assumes that the array of pins in struct imx1_pinctrl_soc_info can be indexed by pin id to get the pinctrl_pin_desc for a pin. This used to be correct up to commit 607af165c047 which removed some entries from the array and so made it wrong to access the array by pin id. The result of this bug is a wrong pin name in the output for small pin ids and an oops for the bigger ones. This patch is the result of a discussion that includes patches by Markus Pargmann and Chris Ruehl. Fixes: 607af165c047 ("pinctrl: i.MX27: Remove nonexistent pad definitions") Cc: [email protected] Reported-by: Chris Ruehl <[email protected]> Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Markus Pargmann <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-07-20pinctrl: bcm2835: Clear the event latch register when disabling interruptsJonathan Bell1-0/+2
It's possible to hit a race condition if interrupts are generated on a GPIO pin when the IRQ line in question is being disabled. If the interrupt is freed, bcm2835_gpio_irq_disable() is called which disables the event generation sources (edge, level). If an event occurred between the last disabling of hard IRQs and the write to the event source registers, a bit would be set in the GPIO event detect register (GPEDSn) which goes unacknowledged by bcm2835_gpio_irq_handler() so Linux complains loudly. There is no per-GPIO mask register, so when disabling GPIO interrupts write 1 to the relevant bit in GPEDSn to clear out any stale events. Signed-off-by: Jonathan Bell <[email protected]> Acked-by: Stephen Warren <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-07-20pinctrl: single: ensure pcs irq will not be forced threadedGrygorii Strashko1-1/+2
The PSC IRQ is requested using request_irq() API and as result it can be forced to be threaded IRQ in RT-Kernel if PCS_QUIRK_HAS_SHARED_IRQ is enabled for pinctrl domain. As result, following 'possible irq lock inversion dependency' report can be seen: ========================================================= [ INFO: possible irq lock inversion dependency detected ] 3.14.43-rt42-00360-g96ff499-dirty #24 Not tainted --------------------------------------------------------- irq/369-pinctrl/927 just changed the state of lock: (&pcs->lock){+.....}, at: [<c0375b54>] pcs_irq_handle+0x48/0x9c but this lock was taken by another, HARDIRQ-safe lock in the past: (&irq_desc_lock_class){-.....} and interrupts could create inverse lock ordering between them. other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&pcs->lock); local_irq_disable(); lock(&irq_desc_lock_class); lock(&pcs->lock); <Interrupt> lock(&irq_desc_lock_class); *** DEADLOCK *** no locks held by irq/369-pinctrl/927. the shortest dependencies between 2nd lock and 1st lock: -> (&irq_desc_lock_class){-.....} ops: 58724 { IN-HARDIRQ-W at: [<c0090040>] lock_acquire+0x9c/0x158 [<c07065c8>] _raw_spin_lock+0x48/0x58 [<c009edac>] handle_fasteoi_irq+0x24/0x15c [<c009abb0>] generic_handle_irq+0x3c/0x4c [<c000f83c>] handle_IRQ+0x50/0xa0 [<c0008674>] gic_handle_irq+0x3c/0x6c [<c0707a04>] __irq_svc+0x44/0x8c [<c000fc44>] arch_cpu_idle+0x40/0x4c [<c009aadc>] cpu_startup_entry+0x270/0x2e0 [<c06fcbf8>] rest_init+0xd4/0xe4 [<c0a44bfc>] start_kernel+0x3d0/0x3dc [<80008084>] 0x80008084 INITIAL USE at: [<c0090040>] lock_acquire+0x9c/0x158 [<c070674c>] _raw_spin_lock_irqsave+0x54/0x68 [<c009aff8>] __irq_get_desc_lock+0x64/0xa4 [<c009e38c>] irq_set_chip+0x30/0x78 [<c009ec30>] irq_set_chip_and_handler_name+0x24/0x3c [<c036ca10>] gic_irq_domain_map+0x48/0xb4 [<c00a0a80>] irq_domain_associate+0x84/0x1d4 [<c00a1154>] irq_create_mapping+0x80/0x11c [<c00a1270>] irq_create_of_mapping+0x80/0x120 [<c05cdaa8>] irq_of_parse_and_map+0x34/0x3c [<c0a4ea24>] omap_dm_timer_init_one+0x90/0x30c [<c0a4eef0>] omap5_realtime_timer_init+0x8c/0x48c [<c0a486b0>] time_init+0x28/0x38 [<c0a44a6c>] start_kernel+0x240/0x3dc [<80008084>] 0x80008084 } ... key at: [<c1049ce0>] irq_desc_lock_class+0x0/0x8 ... acquired at: [<c07065c8>] _raw_spin_lock+0x48/0x58 [<c0375a90>] pcs_irq_unmask+0x58/0xa0 [<c009ea48>] irq_enable+0x38/0x48 [<c009ead0>] irq_startup+0x78/0x7c [<c009d440>] __setup_irq+0x4a8/0x4f4 [<c009d5dc>] request_threaded_irq+0xb8/0x138 [<c0415a5c>] omap_8250_startup+0x4c/0x148 [<c041276c>] serial8250_startup+0x24/0x30 [<c040d0ec>] uart_startup.part.9+0x5c/0x1b4 [<c040dbcc>] uart_open+0xf4/0x16c [<c03f0540>] tty_open+0x170/0x61c [<c0157028>] chrdev_open+0xbc/0x1b4 [<c0150494>] do_dentry_open+0x1e8/0x2bc [<c0150a84>] finish_open+0x44/0x5c [<c0160d50>] do_last.isra.47+0x710/0xca0 [<c01613a4>] path_openat+0xc4/0x640 [<c0162904>] do_filp_open+0x3c/0x98 [<c0151bdc>] do_sys_open+0x114/0x1d8 [<c0151cc8>] SyS_open+0x28/0x2c [<c0a44d70>] kernel_init_freeable+0x168/0x1e4 [<c06fcc24>] kernel_init+0x1c/0xf8 [<c000eee8>] ret_from_fork+0x14/0x20 -> (&pcs->lock){+.....} ops: 65 { HARDIRQ-ON-W at: [<c0090040>] lock_acquire+0x9c/0x158 [<c07065c8>] _raw_spin_lock+0x48/0x58 [<c0375b54>] pcs_irq_handle+0x48/0x9c [<c0375c5c>] pcs_irq_handler+0x1c/0x28 [<c009c458>] irq_forced_thread_fn+0x30/0x74 [<c009c784>] irq_thread+0x158/0x1c4 [<c0063fc4>] kthread+0xd4/0xe8 [<c000eee8>] ret_from_fork+0x14/0x20 INITIAL USE at: [<c0090040>] lock_acquire+0x9c/0x158 [<c070674c>] _raw_spin_lock_irqsave+0x54/0x68 [<c0375344>] pcs_enable+0x7c/0xe8 [<c0372a44>] pinmux_enable_setting+0x178/0x220 [<c036fecc>] pinctrl_select_state+0x110/0x194 [<c04732dc>] pinctrl_bind_pins+0x7c/0x108 [<c045853c>] driver_probe_device+0x70/0x254 [<c0458810>] __driver_attach+0x9c/0xa0 [<c045674c>] bus_for_each_dev+0x78/0xac [<c0458030>] driver_attach+0x2c/0x30 [<c0457c78>] bus_add_driver+0x15c/0x204 [<c0458ee0>] driver_register+0x88/0x108 [<c045a168>] __platform_driver_register+0x64/0x6c [<c0a8170c>] omap_hsmmc_driver_init+0x1c/0x20 [<c0008a94>] do_one_initcall+0x110/0x170 [<c0a44d48>] kernel_init_freeable+0x140/0x1e4 [<c06fcc24>] kernel_init+0x1c/0xf8 [<c000eee8>] ret_from_fork+0x14/0x20 } ... key at: [<c1088a8c>] __key.18572+0x0/0x8 ... acquired at: [<c008cdd4>] mark_lock+0x388/0x76c [<c008df40>] __lock_acquire+0x6d0/0x1f98 [<c0090040>] lock_acquire+0x9c/0x158 [<c07065c8>] _raw_spin_lock+0x48/0x58 [<c0375b54>] pcs_irq_handle+0x48/0x9c [<c0375c5c>] pcs_irq_handler+0x1c/0x28 [<c009c458>] irq_forced_thread_fn+0x30/0x74 [<c009c784>] irq_thread+0x158/0x1c4 [<c0063fc4>] kthread+0xd4/0xe8 [<c000eee8>] ret_from_fork+0x14/0x20 stack backtrace: CPU: 1 PID: 927 Comm: irq/369-pinctrl Not tainted 3.14.43-rt42-00360-g96ff499-dirty #24 [<c00177e0>] (unwind_backtrace) from [<c00130b0>] (show_stack+0x20/0x24) [<c00130b0>] (show_stack) from [<c0702958>] (dump_stack+0x84/0xd0) [<c0702958>] (dump_stack) from [<c008bcfc>] (print_irq_inversion_bug+0x1d0/0x21c) [<c008bcfc>] (print_irq_inversion_bug) from [<c008bf18>] (check_usage_backwards+0xb4/0x11c) [<c008bf18>] (check_usage_backwards) from [<c008cdd4>] (mark_lock+0x388/0x76c) [<c008cdd4>] (mark_lock) from [<c008df40>] (__lock_acquire+0x6d0/0x1f98) [<c008df40>] (__lock_acquire) from [<c0090040>] (lock_acquire+0x9c/0x158) [<c0090040>] (lock_acquire) from [<c07065c8>] (_raw_spin_lock+0x48/0x58) [<c07065c8>] (_raw_spin_lock) from [<c0375b54>] (pcs_irq_handle+0x48/0x9c) [<c0375b54>] (pcs_irq_handle) from [<c0375c5c>] (pcs_irq_handler+0x1c/0x28) [<c0375c5c>] (pcs_irq_handler) from [<c009c458>] (irq_forced_thread_fn+0x30/0x74) [<c009c458>] (irq_forced_thread_fn) from [<c009c784>] (irq_thread+0x158/0x1c4) [<c009c784>] (irq_thread) from [<c0063fc4>] (kthread+0xd4/0xe8) [<c0063fc4>] (kthread) from [<c000eee8>] (ret_from_fork+0x14/0x20) To fix it use IRQF_NO_THREAD to ensure that pcs irq will not be forced threaded. Cc: Tony Lindgren <[email protected]> Cc: Sebastian Andrzej Siewior <[email protected]> Signed-off-by: Grygorii Strashko <[email protected]> Acked-by: Tony Lindgren <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-07-20sh-pfc: fix sparse GPIOs for R-Car SoCsSergei Shtylyov1-1/+1
The PFC driver causes the kernel to hang on the R-Car gen2 SoC based boards when the CPU_ALL_PORT() macro is fixed to reflect the reality, i.e. when the GPIO space becomes actually sparse. This happens because the _GP_GPIO() macro includes an indexed initializer which causes the "holes" (array entries filled with all 0s) between the groups of the existing GPIOs; and the driver can't cope with that. There seems to be no reason to use the indexed initializer, so we can remove the index specifier and so avoid the "holes". Signed-off-by: Sergei Shtylyov <[email protected]> Acked-by: Laurent Pinchart <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Linus Walleij <[email protected]>
2015-07-20pinctrl: abx500: remove strict modeLinus Walleij1-1/+0
Commit a21763a0b1e5a5ab8310f581886d04beadc16616 "pinctrl: nomadik: activate strict mux mode" put all Nomadik pin controllers to strict mode. This was not good on the Snowball platform: the muxing of GPIOs to different pins is done with hogs in the DTS file, and then these GPIOs are used by offset, relying on hogs to mux the pins. Since that means the pin controller "owns" the pins and at the same time we have a GPIO user, this pin controller is by definition not strict. Signed-off-by: Linus Walleij <[email protected]>
2015-07-20ALSA: hda - Fix Skylake codec timeoutDavid Henningsson2-9/+14
When the controller is powered up but the HDMI codec is powered down on Skylake, the power well is turned off. When the codec is then powered up again, we need to poke the codec a little extra to make sure it wakes up. Otherwise we'll get sad "no response from codec" messages and broken audio. This also changes azx_runtime_resume to actually call snd_hdac_set_codec_wakeup for Skylake (before STATETS read). (Otherwise it would only have been called for Haswell and Broadwell, which both do not need it, so this probably was not the author's intention.) Signed-off-by: David Henningsson <[email protected]> Reviewed-by: Libin Yang <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2015-07-19Linux 4.2-rc3Linus Torvalds1-1/+1
2015-07-19Merge tag 'scsi-fixes' of ↵Linus Torvalds2-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Pull SCSI fixes from James Bottomley: "Two fairly simple fixes: one is a change that causes us to have a very low queue depth leading to performance issues and the other is a null deref occasionally in tapes thanks to use after put" * tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: scsi: fix host max depth checking for the 'queue_depth' sysfs interface st: null pointer dereference panic caused by use after kref_put by st_open
2015-07-19Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linusLinus Torvalds10-38/+7
Pull MIPS fixes from Ralf Baechle: "Another round of MIPS fixes for 4.2. Things are looking quite decent at this stage but the recent work on the FPU support took its toll: - fix an incorrect overly restrictive ifdef - select O32 64-bit FP support for O32 binary compatibility - remove workarounds for Sibyte SB1250 Pass1 parts. There are rare fixing the workarounds is not worth the effort. - patch up an outdated and now incorrect comment" * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: MIPS: fpu.h: Allow 64-bit FPU on a 64-bit MIPS R6 CPU MIPS: SB1: Remove support for Pass 1 parts. MIPS: Require O32 FP64 support for MIPS64 with O32 compat MIPS: asm-offset.c: Patch up various comments refering to the old filename.
2015-07-19Merge branch 'parisc-4.2-2' of ↵Linus Torvalds1-1/+2
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux Pull parisc fix from Helge Deller: "A memory leak fix from Christophe Jaillet which was introduced with kernel 4.0 and which leads to kernel crashes on parisc after 1-3 days" * 'parisc-4.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc: mm: Fix a memory leak related to pmd not attached to the pgd
2015-07-19Merge tag 'armsoc-fixes' of ↵Linus Torvalds35-57/+179
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "By far most of the fixes here are updates to DTS files to deal with some mostly minor bugs. There's also a fix to deal with non-PM kernel configs on i.MX, a regression fix for ethernet on PXA platforms and a dependency fix for OMAP" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: ARM: keystone: dts: rename pcie nodes to help override status ARM: keystone: dts: fix dt bindings for PCIe ARM: pxa: fix dm9000 platform data regression ARM: dts: Correct audio input route & set mic bias for am335x-pepper ARM: OMAP2+: Add HAVE_ARM_SCU for AM43XX MAINTAINERS: digicolor: add dts files ARM: ux500: fix MMC/SD card regression ARM: ux500: define serial port aliases ARM: dts: OMAP5: Add #iommu-cells property to IOMMUs ARM: dts: OMAP4: Add #iommu-cells property to IOMMUs ARM: dts: Fix frequency scaling on Gumstix Pepper ARM: dts: configure regulators for Gumstix Pepper ARM: dts: omap3: overo: Update LCD panel names ARM: dts: cros-ec-keyboard: Add support for some Japanese keys ARM: imx6: gpc: always enable PU domain if CONFIG_PM is not set ARM: dts: imx53-qsb: fix TVE entry ARM: dts: mx23: fix iio-hwmon support ARM: dts: imx27: Adjust the GPT compatible string ARM: socfpga: dts: Fix entries order ARM: socfpga: dts: Fix adxl34x formating and compatible string
2015-07-19ALSA: hda - Add headset mic support for Acer Aspire V5-573GMateusz Sylwestrzak1-1/+1
Acer Aspire V5 with the ALC282 codec is given the wrong value for the 0x19 PIN by the laptop's BIOS. Overriding it with the correct value adds support for the headset microphone which would not otherwise be visible in the system. The fix is based on commit 7819717b1134 with a similar quirk for Acer Aspire with the ALC269 codec. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96201 Cc: <[email protected]> Signed-off-by: Mateusz Sylwestrzak <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2015-07-19iio:light:stk3310: make endianness independent of hostHartmut Knaack1-6/+6
Data is stored in the device in be16 format. Make use of be16_to_cpu and cpu_to_be16 to have correct endianness on any host architecture. Signed-off-by: Hartmut Knaack <[email protected]> Reviewed-by: Tiberiu Breana <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio:light:stk3310: move device register to end of probeHartmut Knaack1-7/+7
iio_device_register should be the last operation during probe. Therefor move up interrupt setup code and while at it, change the check for invalid values of client->irq to be smaller than zero. Fixes: 3dd477acbdd1 ("iio: light: Add threshold interrupt support for STK3310") As the device_register makes the userspace interfaces of the device available it is possible for requests to come in before the probe sequence has finished. This can lead to unhandled interrupts and similar. Signed-off-by: Hartmut Knaack <[email protected]> Reviewed-by: Tiberiu Breana <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: mma8452: use iio event type IIO_EV_TYPE_MAGMartin Kepplinger1-4/+4
IIO_EV_TYPE_THRESH in rising direction describes an event where the threshold is crossed in rising direction, positive or negative values being possible. This is not the case here. Since the threshold is no signed value and only the magnitude is compared, IIO_EV_TYPE_MAG is what describes the behaviour of these devices, see the sysfs-bus-iio ABI Documentation. Signed-off-by: Martin Kepplinger <[email protected]> Signed-off-by: Christoph Muellner <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: mcp320x: Fix NULL pointer dereferenceManfred Schlaegl1-0/+2
On reading in_voltage_scale of we got an NULL pointer dereference Oops. The reason for this is, that mcp320x_read_raw tries to access chip_info->resolution from struct mcp320x, but chip_info is never set. chip_info was never set since the driver was added, but there was no acute problem, because it was not referenced. The acute problem exists since b12206e917ac34bec41b9ff93d37d8bd53a2b3bc iio: adc: mcp320x. Add support for more ADCs This patch fixes the issue by setting chip_info in mcp320x_probe. Signed-off-by: Manfred Schlaegl <[email protected]> Reviewed-by: Michael Welling <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: adc: vf610: fix the adc register read fail issueFugang Duan1-1/+1
Read the register only when the adc register address is 4 byte aligned. (rather than the other way around). Signed-off-by: Haibo Chen <[email protected]> Signed-off-by: Fugang Duan <[email protected]> Cc: <Stable.vger.kernel.org> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: mlx96014: Replace offset signCrt Mori1-1/+1
Changed the offset to negative as usual equation is: (raw + offset)*scale and in this case offset should be negative (as we deduct 273.15 Kelvin to get temperature in Celsius). Signed-off-by: Crt Mori <[email protected]> Acked-by: Peter Meerwald <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: magnetometer: mmc35240: fix SET/RESET sequenceViorel Suman1-3/+4
The RESET operation invoked in the last instance will align in the natural way all 3 axis and the chip top view. Without this, north and south are swapped. Signed-off-by: Viorel Suman <[email protected]> Signed-off-by: Daniel Baluta <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: magnetometer: mmc35240: Fix SET/RESET maskDaniel Baluta1-2/+2
This fixes setting the SET/RESET bit in the REG_CTRL0 register. Signed-off-by: Daniel Baluta <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: magnetometer: mmc35240: Fix crash in pm suspendDaniel Baluta1-0/+1
We must set i2c client private data at probe in order to correctly retrieve it in pm suspend/resume, preventing the following crash: [ 321.790582] PM: Syncing filesystems ... done. [ 322.364440] PM: Preparing system for mem sleep [ 322.400047] PM: Entering mem sleep [ 322.462178] BUG: unable to handle kernel NULL pointer dereference at 0000036c [ 322.469119] IP: [<80e0b3d2>] mmc35240_suspend+0x12/0x30 [ 322.474291] *pdpt = 000000002fd6f001 *pde = 0000000000000000 [ 322.479967] Oops: 0000 1 PREEMPT SMP [ 322.496516] task: a86d0df0 ti: a8766000 task.ti: a8766000 [ 322.570744] Call Trace: [ 322.573217] [<80c0d2d1>] pm_generic_suspend+0x21/0x30 [ 322.578284] [<80d042ab>] i2c_device_pm_suspend+0x1b/0x30 Signed-off-by: Daniel Baluta <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio:magnetometer:bmc150_magn: output intended variableHartmut Knaack1-2/+2
According to the debug/error string, the content of chip_id is supposed to be output, rather than the return value of the previous operation. Fixes: c91746a2361d ("iio: magn: Add support for BMC150 magnetometer") Signed-off-by: Hartmut Knaack <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio:magnetometer:bmc150_magn: add regmap dependencyHartmut Knaack1-0/+1
bmc150_magn makes use of REGMAP_I2C, so select it to build always without errors. Fixes: c91746a2361d ("iio: magn: Add support for BMC150 magnetometer") Signed-off-by: Hartmut Knaack <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19staging: vt6656: check ieee80211_bss_conf bssid not NULLMalcolm Priestley1-1/+1
Sometimes bssid can go null on failed association. Signed-off-by: Malcolm Priestley <[email protected]> Cc: <[email protected]> # v3.17+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-19staging: vt6655: check ieee80211_bss_conf bssid not NULLMalcolm Priestley1-1/+1
Sometimes bssid can go null on failed association. Signed-off-by: Malcolm Priestley <[email protected]> Cc: <[email protected]> # v3.19+ Signed-off-by: Greg Kroah-Hartman <[email protected]>
2015-07-19iio: tmp006: Check channel info on writePeter Meerwald1-0/+3
only SAMP_FREQ is writable Will lead to SAMP_FREQ being written by any attempt to write to the other exported attributes and hence a rather unexpected result! Signed-off-by: Peter Meerwald <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: sx9500: Add missing init in sx9500_buffer_pre{en,dis}able()Geert Uytterhoeven1-2/+2
drivers/iio/proximity/sx9500.c: In function ‘sx9500_buffer_preenable’: drivers/iio/proximity/sx9500.c:682: warning: ‘ret’ may be used uninitialized in this function drivers/iio/proximity/sx9500.c: In function ‘sx9500_buffer_predisable’: drivers/iio/proximity/sx9500.c:706: warning: ‘ret’ may be used uninitialized in this function If active_scan_mask is empty, it will loop once more over all channels, doing nothing. Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Vlad Dogaru <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio:light:ltr501: fix regmap dependencyHartmut Knaack1-0/+1
The use of regmap in commit 2f2c96338afc requires REGMAP_I2C to be selected, in order to meet all dependencies. Fixes: 2f2c96338afc ("iio: ltr501: Add regmap support.") Signed-off-by: Hartmut Knaack <[email protected]> Acked-by: Daniel Baluta <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio:light:ltr501: fix variable in ltr501_initHartmut Knaack1-1/+1
When filling data->als_contr, the register content read into status needs to be used, instead of the return status value of regmap_read. Fixes: 8592a7eefa540 ("iio: ltr501: Add support for ltr559 chip") Signed-off-by: Hartmut Knaack <[email protected]> Acked-by: Daniel Baluta <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: sx9500: fix bug in compensation codeVlad Dogaru1-3/+3
The initial compensation was mistakingly toggling an extra bit in the control register. Fix this and make sure it's less likely to happen by introducing an additional macro. Reported-by: Hartmut Knaack <[email protected]> Signed-off-by: Vlad Dogaru <[email protected]> Acked-by: Hartmut Knaack <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: sx9500: rework error handling of raw readingsVlad Dogaru1-7/+9
Fix error handling so that we can power the chip down even if a raw read fails. Reported-by: Hartmut Knaack <[email protected]> Signed-off-by: Vlad Dogaru <[email protected]> Acked-by: Hartmut Knaack <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: magnetometer: mmc35240: fix available sampling frequenciesTeodora Baluta1-14/+21
Fix the sampling frequencies according to the datasheet (page 8). The datasheet specifies the following available frequencies for continuous mode: 1.5 Hz, 13 Hz, 25 Hz, and 50 Hz. Also fix comments about the ODR to comply with datasheet. Signed-off-by: Teodora Baluta <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio:light:stk3310: Fix REGMAP_I2C dependencyHartmut Knaack1-0/+1
The stk3310 driver makes use of regmap_i2c, so this dependency needs to be reflected in Kconfig. Signed-off-by: Hartmut Knaack <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: light: STK3310: un-invert proximity valuesTiberiu Breana1-36/+17
In accordance with the recent proximity ABI changes, STK3310's proximity readings should be un-inversed in order to return low values for far-away objects and high values for close ones. As consequences of this change, iio event directions have been switched and maximum proximity sensor reference values have also been adjusted in accordance with the real readings. Signed-off-by: Tiberiu Breana <[email protected]> Acked-by: Hartmut Knaack <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio:adc:cc10001_adc: fix Kconfig dependencyHartmut Knaack1-2/+1
The Cosmic Circuits 10001 ADC driver depends on HAS_IOMEM, HAVE_CLK and REGULATOR together, not just any of these. Signed-off-by: Hartmut Knaack <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: light: tcs3414: Fix bug preventing to set integration timePeter Meerwald1-1/+1
the millisecond values in tcs3414_times should be checked against val2, not val, which is always zero. Signed-off-by: Peter Meerwald <[email protected]> Reported-by: Stephan Kleisinger <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio:accel:bmc150-accel: fix counting directionHartmut Knaack1-1/+1
In bmc150_accel_unregister_triggers() triggers should be unregistered in reverse order of registration. Trigger registration starts with number 0, counting up. In consequence, trigger number needs to be count down here. Signed-off-by: Hartmut Knaack <[email protected]> Reviewed-by: Octavian Purdila <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio:light:cm3323: clear bitmask before setHartmut Knaack1-1/+1
When setting the bits for integration time, the appropriate bitmask needs to be cleared first. Signed-off-by: Hartmut Knaack <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: adc: at91_adc: allow to use full range of startup timeJan Leupold1-4/+4
The DT-Property "atmel,adc-startup-time" is stored in an u8 for a microsecond value. When trying to increase the value of STARTUP in Register AT91_ADC_MR some higher values can't be reached. Change the type in function parameter and private structure field from u8 to u32. Signed-off-by: Jan Leupold <[email protected]> [[email protected]: change commit message, increase u16 to u32 for startup time] Signed-off-by: Nicolas Ferre <[email protected]> Acked-by: Alexandre Belloni <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: DAC: ad5624r_spi: fix bit shift of output data valueJM Friedt1-2/+2
The value sent on the SPI bus is shifted by an erroneous number of bits. The shift value was already computed in the iio_chan_spec structure and hence subtracting this argument to 16 yields an erroneous data position in the SPI stream. Signed-off-by: JM Friedt <[email protected]> Acked-by: Lars-Peter Clausen <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: proximity: sx9500: Fix proximity valueDaniel Baluta1-1/+1
Because of the ABI confusion proximity value exposed by SX9500 was inverted. Signed-off-by: Daniel Baluta <[email protected]> Reviewed-by: Vlad Dogaru <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: ABI: Clarify proximity output valueDaniel Baluta1-4/+2
Current description for proximity measurement is ambiguous. While the first part says that proximity is measured by observing reflectivity, the second part incorrectly infers that reported values should behave like a distance. This is because of AS3935 lightning sensor which uses the proximity API, while not being a true proximity sensor. Note this is marked for stable as it accompanies a fix in ABI usage to the sx9500 driver which would otherwise appear to be correct. Fixes: 614e8842ddf ("iio: ABI: add clarification for proximity") Signed-off-by: Daniel Baluta <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: inv-mpu: Specify the expected format/precision for write channelsAdriana Reus1-0/+18
The gyroscope needs IIO_VAL_INT_PLUS_NANO for the scale channel and unless specified write returns MICRO by default. This needs to be properly specified so that write operations into scale have the expected behaviour. Signed-off-by: Adriana Reus <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: twl4030-madc: Pass the IRQF_ONESHOT flagFabio Estevam1-1/+2
Since commit 1c6c69525b40 ("genirq: Reject bogus threaded irq requests") threaded IRQs without a primary handler need to be requested with IRQF_ONESHOT, otherwise the request will fail. So pass the IRQF_ONESHOT flag in this case. The semantic patch that makes this change is available in scripts/coccinelle/misc/irqf_oneshot.cocci. Signed-off-by: Fabio Estevam <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19iio: adc: rockchip_saradc: add missing MODULE_* dataHeiko Stuebner1-0/+4
The module-data is currently missing. This includes the license-information which makes the driver taint the kernel and miss symbols when compiled as module. Fixes: 44d6f2ef94f9 ("iio: adc: add driver for Rockchip saradc") Signed-off-by: Heiko Stuebner <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19hid-sensor: Fix suspend/resume delaySrinivas Pandruvada2-1/+11
By default all the sensors are runtime suspended state (lowest power state). During Linux suspend process, all the run time suspended devices are resumed and then suspended. This caused all sensors to power up and introduced delay in suspend time, when we introduced runtime PM for HID sensors. The opposite process happens during resume process. To fix this, we do powerup process of the sensors only when the request is issued from user (raw or tiggerred). In this way when runtime, resume calls for powerup it will simply return as this will not match user requested state. Note this is a regression fix as the increase in suspend / resume times can be substantial (report of 8 seconds on Len's laptop!) Signed-off-by: Srinivas Pandruvada <[email protected]> Tested-by: Len Brown <[email protected]> Cc: <[email protected]> Signed-off-by: Jonathan Cameron <[email protected]>
2015-07-19MIPS: fpu.h: Allow 64-bit FPU on a 64-bit MIPS R6 CPUMarkos Chandras1-1/+1
Commit 6134d94923d0 ("MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6") added support for 64-bit FPU on a 32-bit MIPS R6 processor but it missed the 64-bit CPU case leading to FPU failures when requesting FR=1 mode (which is always the case for MIPS R6 userland) when running a 32-bit kernel on a 64-bit CPU. We also fix the MIPS R2 case. Signed-off-by: Markos Chandras <[email protected]> Fixes: 6134d94923d0 ("MIPS: asm: fpu: Allow 64-bit FPU on MIPS32 R6") Reviewed-by: Paul Burton <[email protected]> Cc: <[email protected]> # 4.0+ Cc: [email protected] Patchwork: https://patchwork.linux-mips.org/patch/10734/ Signed-off-by: Ralf Baechle <[email protected]>
2015-07-19parisc: mm: Fix a memory leak related to pmd not attached to the pgdChristophe Jaillet1-1/+2
Commit 0e0da48dee8d ("parisc: mm: don't count preallocated pmds") introduced a memory leak. After this commit, the 'return' statement in pmd_free is executed in all cases. Even for pmd that are not attached to the pgd. So 'free_pages' can never be called anymore, leading to a memory leak. Signed-off-by: Christophe JAILLET <[email protected]> Acked-by: Kirill A. Shutemov <[email protected]> Acked-by: Mikulas Patocka <[email protected]> Acked-by: Helge Deller <[email protected]> Cc: [email protected] # v4.0+ Signed-off-by: Helge Deller <[email protected]>
2015-07-18Merge tag 'pxa-fixes-v4.2-rc2' of https://github.com/rjarzmik/linux into fixesDOlof Johansson9-0/+24
Merge "pxa fixes for v4.2" from Robert Jarzmik: ARM: pxa: fixes for v4.2-rc2 This single fix reenables ethernet cards for several pxa boards, broken by regulator addition to dm9000 driver. * tag 'pxa-fixes-v4.2-rc2' of https://github.com/rjarzmik/linux: ARM: pxa: fix dm9000 platform data regression
2015-07-18Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-armLinus Torvalds5-9/+14
Pull ARM fixes from Russell King: "A small set of ARM fixes for -rc3, most of them not far off one-liners, with the exception of fixing the V7 cache invalidation for incoming SMP processors which was causing problems for SoCFPGA devices" * 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: ARM: fix __virt_to_idmap build error on !MMU ARM: invalidate L1 before enabling coherency ARM: 8404/1: dma-mapping: fix off-by-one error in bitmap size check ARM: 8402/1: perf: Don't use of_node after putting it ARM: 8400/1: use virt_to_idmap to get phys_reset address
Powered by cgit, Gruvboxed by Blaster4385.