mmc: sh_mmcif: Fix timeout value for command request
commit bad4371d87d1d1ed1aecd9c9cc21c41ac3f289c8 upstream.
f9fd54f22e ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout")
changed the timeout value from 1000 jiffies to 1s. In the case where
HZ is 1000 the values are the same. However, for smaller HZ values the
timeout is now smaller, 1s instead of 10s in the case of HZ=100.
Since the timeout occurs in spite of a normal data transfer a timeout of
10s seems more appropriate. This restores the previous timeout in the
case where HZ=100 and results in an increase over the previous timeout
for larger values of HZ.
Fixes: f9fd54f22e ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout")
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[horms: rewrote changelog to refer to HZ]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bad4371d87d1d1ed1aecd9c9cc21c41ac3f289c8 upstream.
f9fd54f22e ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout")
changed the timeout value from 1000 jiffies to 1s. In the case where
HZ is 1000 the values are the same. However, for smaller HZ values the
timeout is now smaller, 1s instead of 10s in the case of HZ=100.
Since the timeout occurs in spite of a normal data transfer a timeout of
10s seems more appropriate. This restores the previous timeout in the
case where HZ=100 and results in an increase over the previous timeout
for larger values of HZ.
Fixes: f9fd54f22e ("mmc: sh_mmcif: Use msecs_to_jiffies() for host->timeout")
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[horms: rewrote changelog to refer to HZ]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: core: add missing pm event in mmc_pm_notify to fix hib restore
commit 184af16b09360d6273fd6160e6ff7f8e2482ef23 upstream.
The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late hibernation restore stages when MMC device is suspended
already - which, in turn, will lead to system crash on TI dra7-evm board:
WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374()
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access
Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().
Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card...)
Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 184af16b09360d6273fd6160e6ff7f8e2482ef23 upstream.
The PM_RESTORE_PREPARE is not handled now in mmc_pm_notify(),
as result mmc_rescan() could be scheduled and executed at
late hibernation restore stages when MMC device is suspended
already - which, in turn, will lead to system crash on TI dra7-evm board:
WARNING: CPU: 0 PID: 3188 at drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x258/0x374()
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access
Hence, add missed PM_RESTORE_PREPARE PM event in mmc_pm_notify().
Fixes: 4c2ef25fe0b8 (mmc: fix all hangs related to mmc/sd card...)
Signed-off-by: Grygorii Strashko <Grygorii.Strashko@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: card: Don't access RPMB partitions for normal read/write
commit 4e93b9a6abc0d028daf3c8a00cb77b679d8a4df4 upstream.
During kernel boot, it will try to read some logical sectors
of each block device node for the possible partition table.
But since RPMB partition is special and can not be accessed
by normal eMMC read / write CMDs, it will cause below error
messages during kernel boot:
...
mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00
mmcblk0rpmb: retrying using single block read
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
end_request: I/O error, dev mmcblk0rpmb, sector 0
Buffer I/O error on device mmcblk0rpmb, logical block 0
end_request: I/O error, dev mmcblk0rpmb, sector 8
Buffer I/O error on device mmcblk0rpmb, logical block 1
end_request: I/O error, dev mmcblk0rpmb, sector 16
Buffer I/O error on device mmcblk0rpmb, logical block 2
end_request: I/O error, dev mmcblk0rpmb, sector 24
Buffer I/O error on device mmcblk0rpmb, logical block 3
...
This patch will discard the access request in eMMC queue if
it is RPMB partition access request. By this way, it avoids
trigger above error messages.
Fixes: 090d25fe224c ("mmc: core: Expose access to RPMB partition")
Signed-off-by: Yunpeng Gao <yunpeng.gao@intel.com>
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Tested-by: Michael Shigorin <mike@altlinux.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4e93b9a6abc0d028daf3c8a00cb77b679d8a4df4 upstream.
During kernel boot, it will try to read some logical sectors
of each block device node for the possible partition table.
But since RPMB partition is special and can not be accessed
by normal eMMC read / write CMDs, it will cause below error
messages during kernel boot:
...
mmc0: Got data interrupt 0x00000002 even though no data operation was in progress.
mmcblk0rpmb: error -110 transferring data, sector 0, nr 32, cmd response 0x900, card status 0xb00
mmcblk0rpmb: retrying using single block read
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
mmcblk0rpmb: timed out sending r/w cmd command, card status 0x400900
end_request: I/O error, dev mmcblk0rpmb, sector 0
Buffer I/O error on device mmcblk0rpmb, logical block 0
end_request: I/O error, dev mmcblk0rpmb, sector 8
Buffer I/O error on device mmcblk0rpmb, logical block 1
end_request: I/O error, dev mmcblk0rpmb, sector 16
Buffer I/O error on device mmcblk0rpmb, logical block 2
end_request: I/O error, dev mmcblk0rpmb, sector 24
Buffer I/O error on device mmcblk0rpmb, logical block 3
...
This patch will discard the access request in eMMC queue if
it is RPMB partition access request. By this way, it avoids
trigger above error messages.
Fixes: 090d25fe224c ("mmc: core: Expose access to RPMB partition")
Signed-off-by: Yunpeng Gao <yunpeng.gao@intel.com>
Signed-off-by: Chuanxiao Dong <chuanxiao.dong@intel.com>
Tested-by: Michael Shigorin <mike@altlinux.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pinctrl: Don't just pretend to protect pinctrl_maps, do it for real
commit c5272a28566b00cce79127ad382406e0a8650690 upstream.
Way back, when the world was a simpler place and there was no war, no
evil, and no kernel bugs, there was just a single pinctrl lock. That
was how the world was when (57291ce pinctrl: core device tree mapping
table parsing support) was written. In that case, there were
instances where the pinctrl mutex was already held when
pinctrl_register_map() was called, hence a "locked" parameter was
passed to the function to indicate that the mutex was already locked
(so we shouldn't lock it again).
A few years ago in (42fed7b pinctrl: move subsystem mutex to
pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex.
...but (oops) we forgot to re-think about the whole "locked" parameter
for pinctrl_register_map(). Basically the "locked" parameter appears
to still refer to whether the bigger pinctrl_dev mutex is locked, but
we're using it to skip locks of our (now separate) pinctrl_maps_mutex.
That's kind of a bad thing(TM). Probably nobody noticed because most
of the calls to pinctrl_register_map happen at boot time and we've got
synchronous device probing. ...and even cases where we're
asynchronous don't end up actually hitting the race too often. ...but
after banging my head against the wall for a bug that reproduced 1 out
of 1000 reboots and lots of looking through kgdb, I finally noticed
this.
Anyway, we can now safely remove the "locked" parameter and go back to
a war-free, evil-free, and kernel-bug-free world.
Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct")
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c5272a28566b00cce79127ad382406e0a8650690 upstream.
Way back, when the world was a simpler place and there was no war, no
evil, and no kernel bugs, there was just a single pinctrl lock. That
was how the world was when (57291ce pinctrl: core device tree mapping
table parsing support) was written. In that case, there were
instances where the pinctrl mutex was already held when
pinctrl_register_map() was called, hence a "locked" parameter was
passed to the function to indicate that the mutex was already locked
(so we shouldn't lock it again).
A few years ago in (42fed7b pinctrl: move subsystem mutex to
pinctrl_dev struct), we switched to a separate pinctrl_maps_mutex.
...but (oops) we forgot to re-think about the whole "locked" parameter
for pinctrl_register_map(). Basically the "locked" parameter appears
to still refer to whether the bigger pinctrl_dev mutex is locked, but
we're using it to skip locks of our (now separate) pinctrl_maps_mutex.
That's kind of a bad thing(TM). Probably nobody noticed because most
of the calls to pinctrl_register_map happen at boot time and we've got
synchronous device probing. ...and even cases where we're
asynchronous don't end up actually hitting the race too often. ...but
after banging my head against the wall for a bug that reproduced 1 out
of 1000 reboots and lots of looking through kgdb, I finally noticed
this.
Anyway, we can now safely remove the "locked" parameter and go back to
a war-free, evil-free, and kernel-bug-free world.
Fixes: 42fed7ba44e4 ("pinctrl: move subsystem mutex to pinctrl_dev struct")
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: more strictly validate the UVD codec
commit d52cdfa4a0c6406bbfb33206341eaf1fb1555994 upstream.
MPEG 2/4 are only supported since UVD3.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d52cdfa4a0c6406bbfb33206341eaf1fb1555994 upstream.
MPEG 2/4 are only supported since UVD3.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: make UVD handle checking more strict
commit a1b403da70e038ca6c6c6fe434d1d873546873a3 upstream.
Invalid messages can crash the hw otherwise.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a1b403da70e038ca6c6c6fe434d1d873546873a3 upstream.
Invalid messages can crash the hw otherwise.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: disable semaphores for UVD V1 (v2)
commit 013ead48a843442e63b9426e3bd5df18ca5d054a upstream.
Hardware doesn't seem to work correctly, just block userspace in this case.
v2: add missing defines
Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=85320
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 013ead48a843442e63b9426e3bd5df18ca5d054a upstream.
Hardware doesn't seem to work correctly, just block userspace in this case.
v2: add missing defines
Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=85320
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/i915: Add missing MacBook Pro models with dual channel LVDS
commit 3916e3fd81021fb795bfbdb17f375b6b3685bced upstream.
Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models
shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz)
as a BTO option, both versions used dual channel LVDS even though
the smaller one would have fit into a single channel.
Notes:
Bug report showing that the MacBookPro8,2 with 1440x900 uses dual
channel LVDS (this lead to it being hardcoded in intel_lvds.c by
Daniel Vetter with commit 618563e3945b9d0864154bab3c607865b557cecc):
https://bugzilla.kernel.org/show_bug.cgi?id=42842
If i915.lvds_channel_mode=2 is missing even though the machine needs
it, every other vertical line is white and consequently, only the left
half of the screen is visible (verified by myself on a MacBookPro9,1).
Forum posting concerning a MacBookPro6,2 with 1440x900, author is
using i915.lvds_channel_mode=2 on the kernel command line, proving
that the machine uses dual channels:
https://bbs.archlinux.org/viewtopic.php?id=185770
Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all
MacBook Pro "A1286" models, and that model number encompasses the
MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's
driven with dual channel LVDS:
http://www.ebay.com/itm/-/400690878560
http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286
http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf
Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones
with i915 graphics and dual channel LVDS, so that list should be
complete. And the 8,2 is already in intel_lvds.c.
Possible motivation to use dual channel LVDS even on the 1440x900
models: Reduce the number of different parts, i.e. use identical logic
boards and display cabling on both versions and the only differing
component is the panel.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Jani Nikula <jani.nikula@intel.com>
[Jani: included notes in the commit message for posterity]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3916e3fd81021fb795bfbdb17f375b6b3685bced upstream.
Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models
shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz)
as a BTO option, both versions used dual channel LVDS even though
the smaller one would have fit into a single channel.
Notes:
Bug report showing that the MacBookPro8,2 with 1440x900 uses dual
channel LVDS (this lead to it being hardcoded in intel_lvds.c by
Daniel Vetter with commit 618563e3945b9d0864154bab3c607865b557cecc):
https://bugzilla.kernel.org/show_bug.cgi?id=42842
If i915.lvds_channel_mode=2 is missing even though the machine needs
it, every other vertical line is white and consequently, only the left
half of the screen is visible (verified by myself on a MacBookPro9,1).
Forum posting concerning a MacBookPro6,2 with 1440x900, author is
using i915.lvds_channel_mode=2 on the kernel command line, proving
that the machine uses dual channels:
https://bbs.archlinux.org/viewtopic.php?id=185770
Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all
MacBook Pro "A1286" models, and that model number encompasses the
MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's
driven with dual channel LVDS:
http://www.ebay.com/itm/-/400690878560
http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286
http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf
Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones
with i915 graphics and dual channel LVDS, so that list should be
complete. And the 8,2 is already in intel_lvds.c.
Possible motivation to use dual channel LVDS even on the 1440x900
models: Reduce the number of different parts, i.e. use identical logic
boards and display cabling on both versions and the only differing
component is the panel.
Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Jani Nikula <jani.nikula@intel.com>
[Jani: included notes in the commit message for posterity]
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: ux500: Enable GPIO regulator for SD-card for snowball
commit 11133db7a836b0cb411faa048f07a38e994d1382 upstream.
Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 11133db7a836b0cb411faa048f07a38e994d1382 upstream.
Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: ux500: Enable GPIO regulator for SD-card for HREF boards
commit f9a8c3914ba85f19c3360b19612d77c47adb8942 upstream.
Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f9a8c3914ba85f19c3360b19612d77c47adb8942 upstream.
Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: ux500: Move GPIO regulator for SD-card into board DTSs
commit 53d2669844263fd5fdc70f0eb6a2eb8a21086d8e upstream.
The GPIO regulator for the SD-card isn't a ux500 SOC configuration, but
instead it's specific to the board. Move the definition of it, into the
board DTSs.
Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 53d2669844263fd5fdc70f0eb6a2eb8a21086d8e upstream.
The GPIO regulator for the SD-card isn't a ux500 SOC configuration, but
instead it's specific to the board. Move the definition of it, into the
board DTSs.
Fixes: c94a4ab7af3f ("ARM: ux500: Disable the MMCI gpio-regulator by default")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: net fix emit_udiv() for BPF_ALU | BPF_DIV | BPF_K intruction.
commit 19fc99d0c6ba7d9b65456496b5bb2169d5f74cd0 upstream.
In that case, emit_udiv() will be called with rn == ARM_R0 (r_scratch)
and loading rm first into ARM_R0 will result in jit_udiv() function
being called the same dividend and divisor. Fix that by loading rn
first into ARM_R1 and then rm into ARM_R0.
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Fixes: aee636c4809f (bpf: do not use reciprocal divide)
Acked-by: Mircea Gherzan <mgherzan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 19fc99d0c6ba7d9b65456496b5bb2169d5f74cd0 upstream.
In that case, emit_udiv() will be called with rn == ARM_R0 (r_scratch)
and loading rm first into ARM_R0 will result in jit_udiv() function
being called the same dividend and divisor. Fix that by loading rn
first into ARM_R1 and then rm into ARM_R0.
Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Fixes: aee636c4809f (bpf: do not use reciprocal divide)
Acked-by: Mircea Gherzan <mgherzan@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: mvebu: armada-xp-openblocks-ax3-4: Disable internal RTC
commit 750e30d4076ae5e02ad13a376e96c95a2627742c upstream.
There is no crystal connected to the internal RTC on the Open Block
AX3. So let's disable it in order to prevent the kernel probing the
driver uselessly. Eventually this patches removes the following
warning message from the boot log:
"rtc-mv d0010300.rtc: internal RTC not ticking"
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 750e30d4076ae5e02ad13a376e96c95a2627742c upstream.
There is no crystal connected to the internal RTC on the Open Block
AX3. So let's disable it in order to prevent the kernel probing the
driver uselessly. Eventually this patches removes the following
warning message from the boot log:
"rtc-mv d0010300.rtc: internal RTC not ticking"
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: dts: imx23-olinuxino: Fix polarity of LED GPIO
commit cfe8c59762244251fd9a5e281d48808095ff4090 upstream.
On imx23-olinuxino the LED turns on when level logic high is aplied to
GPIO2_1.
Fix the gpios property accordingly.
Fixes: b34aa1850244 ("ARM: dts: imx23-olinuxino: Remove unneeded "default-on"")
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cfe8c59762244251fd9a5e281d48808095ff4090 upstream.
On imx23-olinuxino the LED turns on when level logic high is aplied to
GPIO2_1.
Fix the gpios property accordingly.
Fixes: b34aa1850244 ("ARM: dts: imx23-olinuxino: Remove unneeded "default-on"")
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: dts: imx23-olinuxino: Fix dr_mode of usb0
commit 0fdebe1a2f4d3a8fc03754022fabf8ba95e131a3 upstream.
The dr_mode of usb0 on imx233-olinuxino is left to default "otg".
Since the green LED (GPIO2_1) on imx233-olinuxino is connected to the
same pin as USB_OTG_ID it's possible to disable USB host by LED toggling:
echo 0 > /sys/class/leds/green/brightness
[ 1068.890000] ci_hdrc ci_hdrc.0: remove, state 1
[ 1068.890000] usb usb1: USB disconnect, device number 1
[ 1068.920000] usb 1-1: USB disconnect, device number 2
[ 1068.920000] usb 1-1.1: USB disconnect, device number 3
[ 1069.070000] usb 1-1.2: USB disconnect, device number 4
[ 1069.450000] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
[ 1074.460000] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in 11
This patch fixes the issue by setting dr_mode to "host" in the dts file.
Reported-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Peter Chen <peter.chen@freescale.com>
Fixes: b49312948285 ("ARM: dts: imx23-olinuxino: Add USB host support")
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0fdebe1a2f4d3a8fc03754022fabf8ba95e131a3 upstream.
The dr_mode of usb0 on imx233-olinuxino is left to default "otg".
Since the green LED (GPIO2_1) on imx233-olinuxino is connected to the
same pin as USB_OTG_ID it's possible to disable USB host by LED toggling:
echo 0 > /sys/class/leds/green/brightness
[ 1068.890000] ci_hdrc ci_hdrc.0: remove, state 1
[ 1068.890000] usb usb1: USB disconnect, device number 1
[ 1068.920000] usb 1-1: USB disconnect, device number 2
[ 1068.920000] usb 1-1.1: USB disconnect, device number 3
[ 1069.070000] usb 1-1.2: USB disconnect, device number 4
[ 1069.450000] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
[ 1074.460000] ci_hdrc ci_hdrc.0: timeout waiting for 00000800 in 11
This patch fixes the issue by setting dr_mode to "host" in the dts file.
Reported-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Reviewed-by: Marek Vasut <marex@denx.de>
Acked-by: Peter Chen <peter.chen@freescale.com>
Fixes: b49312948285 ("ARM: dts: imx23-olinuxino: Add USB host support")
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: dts: imx28: Fix AUART4 TX-DMA interrupt name
commit 4ada77e37a773168fea484899201e272ab44ba8b upstream.
Fix a typo in the TX DMA interrupt name for AUART4.
This patch makes AUART4 operational again.
Signed-off-by: Marek Vasut <marex@denx.de>
Fixes: f30fb03d4d3a ("ARM: dts: add generic DMA device tree binding for mxs-dma")
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4ada77e37a773168fea484899201e272ab44ba8b upstream.
Fix a typo in the TX DMA interrupt name for AUART4.
This patch makes AUART4 operational again.
Signed-off-by: Marek Vasut <marex@denx.de>
Fixes: f30fb03d4d3a ("ARM: dts: add generic DMA device tree binding for mxs-dma")
Acked-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ARM: dts: imx25: Add #pwm-cells to pwm4
commit f90d3f0d0a11fa77918fd5497cb616dd2faa8431 upstream.
The property '#pwm-cells' is currently missing. It is not possible to
use pwm4 without this property.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Fixes: 5658a68fb578 ("ARM i.MX25: Add devicetree")
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f90d3f0d0a11fa77918fd5497cb616dd2faa8431 upstream.
The property '#pwm-cells' is currently missing. It is not possible to
use pwm4 without this property.
Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Fixes: 5658a68fb578 ("ARM i.MX25: Add devicetree")
Reviewed-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "dm crypt: fix deadlock when async crypto algorithm returns -EBUSY"
commit c0403ec0bb5a8c5b267fb7e16021bec0b17e4964 upstream.
This reverts Linux 4.1-rc1 commit 0618764cb25f6fa9fb31152995de42a8a0496475.
The problem which that commit attempts to fix actually lies in the
Freescale CAAM crypto driver not dm-crypt.
dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto
driver should internally backlog requests which arrive when the queue is
full and process them later. Until the crypto hw's queue becomes full,
the driver returns -EINPROGRESS. When the crypto hw's queue if full,
the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is
expected to backlog the request and process it when the hardware has
queue space. At the point when the driver takes the request from the
backlog and starts processing it, it calls the completion function with
a status of -EINPROGRESS. The completion function is called (for a
second time, in the case of backlogged requests) with a status/err of 0
when a request is done.
Crypto drivers for hardware without hardware queueing use the helpers,
crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request()
and crypto_get_backlog() helpers to implement this behaviour correctly,
while others implement this behaviour without these helpers (ccp, for
example).
dm-crypt (before the patch that needs reverting) uses this API
correctly. It queues up as many requests as the hw queues will allow
(i.e. as long as it gets back -EINPROGRESS from the request function).
Then, when it sees at least one backlogged request (gets -EBUSY), it
waits till that backlogged request is handled (completion gets called
with -EINPROGRESS), and then continues. The references to
af_alg_wait_for_completion() and af_alg_complete() in that commit's
commit message are irrelevant because those functions only handle one
request at a time, unlink dm-crypt.
The problem is that the Freescale CAAM driver, which that commit
describes as having being tested with, fails to implement the
backlogging behaviour correctly. In cam_jr_enqueue(), if the hardware
queue is full, it simply returns -EBUSY without backlogging the request.
What the observed deadlock was is not described in the commit message
but it is obviously the wait_for_completion() in crypto_convert() where
dm-crypto would wait for the completion being called with -EINPROGRESS
in the case of backlogged requests. This completion will never be
completed due to the bug in the CAAM driver.
Commit 0618764cb25 incorrectly made dm-crypt wait for every request,
even when the driver/hardware queues are not full, which means that
dm-crypt will never see -EBUSY. This means that that commit will cause
a performance regression on all crypto drivers which implement the API
correctly.
Revert it. Correct backlog handling should be implemented in the CAAM
driver instead.
Cc'ing stable purely because commit 0618764cb25 did. If for some reason
a stable@ kernel did pick up commit 0618764cb25 it should get reverted.
Signed-off-by: Rabin Vincent <rabin.vincent@axis.com>
Reviewed-by: Horia Geanta <horia.geanta@freescale.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c0403ec0bb5a8c5b267fb7e16021bec0b17e4964 upstream.
This reverts Linux 4.1-rc1 commit 0618764cb25f6fa9fb31152995de42a8a0496475.
The problem which that commit attempts to fix actually lies in the
Freescale CAAM crypto driver not dm-crypt.
dm-crypt uses CRYPTO_TFM_REQ_MAY_BACKLOG. This means the the crypto
driver should internally backlog requests which arrive when the queue is
full and process them later. Until the crypto hw's queue becomes full,
the driver returns -EINPROGRESS. When the crypto hw's queue if full,
the driver returns -EBUSY, and if CRYPTO_TFM_REQ_MAY_BACKLOG is set, is
expected to backlog the request and process it when the hardware has
queue space. At the point when the driver takes the request from the
backlog and starts processing it, it calls the completion function with
a status of -EINPROGRESS. The completion function is called (for a
second time, in the case of backlogged requests) with a status/err of 0
when a request is done.
Crypto drivers for hardware without hardware queueing use the helpers,
crypto_init_queue(), crypto_enqueue_request(), crypto_dequeue_request()
and crypto_get_backlog() helpers to implement this behaviour correctly,
while others implement this behaviour without these helpers (ccp, for
example).
dm-crypt (before the patch that needs reverting) uses this API
correctly. It queues up as many requests as the hw queues will allow
(i.e. as long as it gets back -EINPROGRESS from the request function).
Then, when it sees at least one backlogged request (gets -EBUSY), it
waits till that backlogged request is handled (completion gets called
with -EINPROGRESS), and then continues. The references to
af_alg_wait_for_completion() and af_alg_complete() in that commit's
commit message are irrelevant because those functions only handle one
request at a time, unlink dm-crypt.
The problem is that the Freescale CAAM driver, which that commit
describes as having being tested with, fails to implement the
backlogging behaviour correctly. In cam_jr_enqueue(), if the hardware
queue is full, it simply returns -EBUSY without backlogging the request.
What the observed deadlock was is not described in the commit message
but it is obviously the wait_for_completion() in crypto_convert() where
dm-crypto would wait for the completion being called with -EINPROGRESS
in the case of backlogged requests. This completion will never be
completed due to the bug in the CAAM driver.
Commit 0618764cb25 incorrectly made dm-crypt wait for every request,
even when the driver/hardware queues are not full, which means that
dm-crypt will never see -EBUSY. This means that that commit will cause
a performance regression on all crypto drivers which implement the API
correctly.
Revert it. Correct backlog handling should be implemented in the CAAM
driver instead.
Cc'ing stable purely because commit 0618764cb25 did. If for some reason
a stable@ kernel did pick up commit 0618764cb25 it should get reverted.
Signed-off-by: Rabin Vincent <rabin.vincent@axis.com>
Reviewed-by: Horia Geanta <horia.geanta@freescale.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xen/events: Set irq_info->evtchn before binding the channel to CPU in __startup_pirq()
commit 16e6bd5970c88a2ac018b84a5f1dd5c2ff1fdf2c upstream.
.. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: Annie Li <annie.li@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 16e6bd5970c88a2ac018b84a5f1dd5c2ff1fdf2c upstream.
.. because bind_evtchn_to_cpu(evtchn, cpu) will map evtchn to
'info' and pass 'info' down to xen_evtchn_port_bind_to_cpu().
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Tested-by: Annie Li <annie.li@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xen/console: Update console event channel on resume
commit b9d934f27c91b878c4b2e64299d6e419a4022f8d upstream.
After a resume the hypervisor/tools may change console event
channel number. We should re-query it.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b9d934f27c91b878c4b2e64299d6e419a4022f8d upstream.
After a resume the hypervisor/tools may change console event
channel number. We should re-query it.
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xen/events: Clear cpu_evtchn_mask before resuming
commit 5cec98834989a014a9560b1841649eaca95cf00e upstream.
When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt to be claimed by wrong VCPU since
cpu_evtchn_mask bits may be stale. This can happen even though
evtchn_2l_bind_to_cpu() attempts to clear old bits: irq_info that
is passed in is not necessarily the original one (from pre-migration
times) but instead is freshly allocated during resume and so any
information about which CPU the channel was bound to is lost.
Thus we should clear the mask during resume.
We also need to make sure that bits for xenstore and console channels
are set when these two subsystems are resumed. While rebind_evtchn_irq()
(which is invoked for both of them on a resume) calls irq_set_affinity(),
the latter will in fact postpone setting affinity until handling the
interrupt. But because cpu_evtchn_mask will have bits for these two
cleared we won't be able to take the interrupt.
With that in mind, we need to bind those two channels explicitly in
rebind_evtchn_irq(). We will keep irq_set_affinity() so that we have a
pass through generic irq affinity code later, in case something needs
to be updated there as well.
(Also replace cpumask_of(0) with cpumask_of(info->cpu) in
rebind_evtchn_irq(): it should be set to zero in preceding
xen_irq_info_evtchn_setup().)
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reported-by: Annie Li <annie.li@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5cec98834989a014a9560b1841649eaca95cf00e upstream.
When a guest is resumed, the hypervisor may change event channel
assignments. If this happens and the guest uses 2-level events it
is possible for the interrupt to be claimed by wrong VCPU since
cpu_evtchn_mask bits may be stale. This can happen even though
evtchn_2l_bind_to_cpu() attempts to clear old bits: irq_info that
is passed in is not necessarily the original one (from pre-migration
times) but instead is freshly allocated during resume and so any
information about which CPU the channel was bound to is lost.
Thus we should clear the mask during resume.
We also need to make sure that bits for xenstore and console channels
are set when these two subsystems are resumed. While rebind_evtchn_irq()
(which is invoked for both of them on a resume) calls irq_set_affinity(),
the latter will in fact postpone setting affinity until handling the
interrupt. But because cpu_evtchn_mask will have bits for these two
cleared we won't be able to take the interrupt.
With that in mind, we need to bind those two channels explicitly in
rebind_evtchn_irq(). We will keep irq_set_affinity() so that we have a
pass through generic irq affinity code later, in case something needs
to be updated there as well.
(Also replace cpumask_of(0) with cpumask_of(info->cpu) in
rebind_evtchn_irq(): it should be set to zero in preceding
xen_irq_info_evtchn_setup().)
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reported-by: Annie Li <annie.li@oracle.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mm: soft-offline: fix num_poisoned_pages counting on concurrent events
commit 602498f9aa43d4951eece3fd6ad95a6d0a78d537 upstream.
If multiple soft offline events hit one free page/hugepage concurrently,
soft_offline_page() can handle the free page/hugepage multiple times,
which makes num_poisoned_pages counter increased more than once. This
patch fixes this wrong counting by checking TestSetPageHWPoison for normal
papes and by checking the return value of dequeue_hwpoisoned_huge_page()
for hugepages.
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Acked-by: Dean Nelson <dnelson@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 602498f9aa43d4951eece3fd6ad95a6d0a78d537 upstream.
If multiple soft offline events hit one free page/hugepage concurrently,
soft_offline_page() can handle the free page/hugepage multiple times,
which makes num_poisoned_pages counter increased more than once. This
patch fixes this wrong counting by checking TestSetPageHWPoison for normal
papes and by checking the return value of dequeue_hwpoisoned_huge_page()
for hugepages.
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Acked-by: Dean Nelson <dnelson@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
writeback: use |1 instead of +1 to protect against div by zero
commit 464d1387acb94dc43ba772b35242345e3d2ead1b upstream.
mm/page-writeback.c has several places where 1 is added to the divisor
to prevent division by zero exceptions; however, if the original
divisor is equivalent to -1, adding 1 leads to division by zero.
There are three places where +1 is used for this purpose - one in
pos_ratio_polynom() and two in bdi_position_ratio(). The second one
in bdi_position_ratio() actually triggered div-by-zero oops on a
machine running a 3.10 kernel. The divisor is
x_intercept - bdi_setpoint + 1 == span + 1
span is confirmed to be (u32)-1. It isn't clear how it ended up that
but it could be from write bandwidth calculation underflow fixed by
c72efb658f7c ("writeback: fix possible underflow in write bandwidth
calculation").
At any rate, +1 isn't a proper protection against div-by-zero. This
patch converts all +1 protections to |1. Note that
bdi_update_dirty_ratelimit() was already using |1 before this patch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 464d1387acb94dc43ba772b35242345e3d2ead1b upstream.
mm/page-writeback.c has several places where 1 is added to the divisor
to prevent division by zero exceptions; however, if the original
divisor is equivalent to -1, adding 1 leads to division by zero.
There are three places where +1 is used for this purpose - one in
pos_ratio_polynom() and two in bdi_position_ratio(). The second one
in bdi_position_ratio() actually triggered div-by-zero oops on a
machine running a 3.10 kernel. The divisor is
x_intercept - bdi_setpoint + 1 == span + 1
span is confirmed to be (u32)-1. It isn't clear how it ended up that
but it could be from write bandwidth calculation underflow fixed by
c72efb658f7c ("writeback: fix possible underflow in write bandwidth
calculation").
At any rate, +1 isn't a proper protection against div-by-zero. This
patch converts all +1 protections to |1. Note that
bdi_update_dirty_ratelimit() was already using |1 before this patch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mm/memory-failure: call shake_page() when error hits thp tail page
commit 09789e5de18e4e442870b2d700831f5cb802eb05 upstream.
Currently memory_failure() calls shake_page() to sweep pages out from
pcplists only when the victim page is 4kB LRU page or thp head page.
But we should do this for a thp tail page too.
Consider that a memory error hits a thp tail page whose head page is on
a pcplist when memory_failure() runs. Then, the current kernel skips
shake_pages() part, so hwpoison_user_mappings() returns without calling
split_huge_page() nor try_to_unmap() because PageLRU of the thp head is
still cleared due to the skip of shake_page().
As a result, me_huge_page() runs for the thp, which is broken behavior.
One effect is a leak of the thp. And another is to fail to isolate the
memory error, so later access to the error address causes another MCE,
which kills the processes which used the thp.
This patch fixes this problem by calling shake_page() for thp tail case.
Fixes: 385de35722c9 ("thp: allow a hwpoisoned head page to be put back to LRU")
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Dean Nelson <dnelson@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Jin Dongming <jin.dongming@np.css.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 09789e5de18e4e442870b2d700831f5cb802eb05 upstream.
Currently memory_failure() calls shake_page() to sweep pages out from
pcplists only when the victim page is 4kB LRU page or thp head page.
But we should do this for a thp tail page too.
Consider that a memory error hits a thp tail page whose head page is on
a pcplist when memory_failure() runs. Then, the current kernel skips
shake_pages() part, so hwpoison_user_mappings() returns without calling
split_huge_page() nor try_to_unmap() because PageLRU of the thp head is
still cleared due to the skip of shake_page().
As a result, me_huge_page() runs for the thp, which is broken behavior.
One effect is a leak of the thp. And another is to fail to isolate the
memory error, so later access to the error address causes another MCE,
which kills the processes which used the thp.
This patch fixes this problem by calling shake_page() for thp tail case.
Fixes: 385de35722c9 ("thp: allow a hwpoisoned head page to be put back to LRU")
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Acked-by: Dean Nelson <dnelson@redhat.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
Cc: Jin Dongming <jin.dongming@np.css.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mnt: Fix fs_fully_visible to verify the root directory is visible
commit 7e96c1b0e0f495c5a7450dc4aa7c9a24ba4305bd upstream.
This fixes a dumb bug in fs_fully_visible that allows proc or sys to
be mounted if there is a bind mount of part of /proc/ or /sys/ visible.
Reported-by: Eric Windisch <ewindisch@docker.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7e96c1b0e0f495c5a7450dc4aa7c9a24ba4305bd upstream.
This fixes a dumb bug in fs_fully_visible that allows proc or sys to
be mounted if there is a bind mount of part of /proc/ or /sys/ visible.
Reported-by: Eric Windisch <ewindisch@docker.com>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
gpio: sysfs: fix memory leaks and device hotplug
commit 483d821108791092798f5d230686868112927044 upstream.
Unregister GPIOs requested through sysfs at chip remove to avoid leaking
the associated memory and sysfs entries.
The stale sysfs entries prevented the gpio numbers from being exported
when the gpio range was later reused (e.g. at device reconnect).
This also fixes the related module-reference leak.
Note that kernfs makes sure that any on-going sysfs operations finish
before the class devices are unregistered and that further accesses
fail.
The chip exported flag is used to prevent gpiod exports during removal.
This also makes it harder to trigger, but does not fix, the related race
between gpiochip_remove and export_store, which is really a race with
gpiod_request that needs to be addressed separately.
Also note that this would prevent the crashes (e.g. NULL-dereferences)
at reconnect that affects pre-3.18 kernels, as well as use-after-free on
operations on open attribute files on pre-3.14 kernels (prior to
kernfs).
Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 483d821108791092798f5d230686868112927044 upstream.
Unregister GPIOs requested through sysfs at chip remove to avoid leaking
the associated memory and sysfs entries.
The stale sysfs entries prevented the gpio numbers from being exported
when the gpio range was later reused (e.g. at device reconnect).
This also fixes the related module-reference leak.
Note that kernfs makes sure that any on-going sysfs operations finish
before the class devices are unregistered and that further accesses
fail.
The chip exported flag is used to prevent gpiod exports during removal.
This also makes it harder to trigger, but does not fix, the related race
between gpiochip_remove and export_store, which is really a race with
gpiod_request that needs to be addressed separately.
Also note that this would prevent the crashes (e.g. NULL-dereferences)
at reconnect that affects pre-3.18 kernels, as well as use-after-free on
operations on open attribute files on pre-3.14 kernels (prior to
kernfs).
Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
gpio: unregister gpiochip device before removing it
commit 01cca93a9491ed95992523ff7e79dd9bfcdea8e0 upstream.
Unregister gpiochip device (used to export information through sysfs)
before removing it internally. This way removal will reverse addition.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 01cca93a9491ed95992523ff7e79dd9bfcdea8e0 upstream.
Unregister gpiochip device (used to export information through sysfs)
before removing it internally. This way removal will reverse addition.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
RDMA/CMA: Canonize IPv4 on IPV6 sockets properly
commit 285214409a9e5fceba2215461b4682b6069d8e77 upstream.
When accepting a new IPv4 connect to an IPv6 socket, the CMA tries to
canonize the address family to IPv4, but does not properly process
the listening sockaddr to get the listening port, and does not properly
set the address family of the canonized sockaddr.
Fixes: e51060f08a61 ("IB: IP address based RDMA connection manager")
Reported-By: Yotam Kenneth <yotamke@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Tested-by: Haggai Eran <haggaie@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 285214409a9e5fceba2215461b4682b6069d8e77 upstream.
When accepting a new IPv4 connect to an IPv6 socket, the CMA tries to
canonize the address family to IPv4, but does not properly process
the listening sockaddr to get the listening port, and does not properly
set the address family of the canonized sockaddr.
Fixes: e51060f08a61 ("IB: IP address based RDMA connection manager")
Reported-By: Yotam Kenneth <yotamke@mellanox.com>
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Tested-by: Haggai Eran <haggaie@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nilfs2: fix sanity check of btree level in nilfs_btree_root_broken()
commit d8fd150fe3935e1692bf57c66691e17409ebb9c1 upstream.
The range check for b-tree level parameter in nilfs_btree_root_broken()
is wrong; it accepts the case of "level == NILFS_BTREE_LEVEL_MAX" even
though the level is limited to values in the range of 0 to
(NILFS_BTREE_LEVEL_MAX - 1).
Since the level parameter is read from storage device and used to index
nilfs_btree_path array whose element count is NILFS_BTREE_LEVEL_MAX, it
can cause memory overrun during btree operations if the boundary value
is set to the level parameter on device.
This fixes the broken sanity check and adds a comment to clarify that
the upper bound NILFS_BTREE_LEVEL_MAX is exclusive.
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d8fd150fe3935e1692bf57c66691e17409ebb9c1 upstream.
The range check for b-tree level parameter in nilfs_btree_root_broken()
is wrong; it accepts the case of "level == NILFS_BTREE_LEVEL_MAX" even
though the level is limited to values in the range of 0 to
(NILFS_BTREE_LEVEL_MAX - 1).
Since the level parameter is read from storage device and used to index
nilfs_btree_path array whose element count is NILFS_BTREE_LEVEL_MAX, it
can cause memory overrun during btree operations if the boundary value
is set to the level parameter on device.
This fixes the broken sanity check and adds a comment to clarify that
the upper bound NILFS_BTREE_LEVEL_MAX is exclusive.
Signed-off-by: Ryusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ocfs2: dlm: fix race between purge and get lock resource
commit b1432a2a35565f538586774a03bf277c27fc267d upstream.
There is a race window in dlm_get_lock_resource(), which may return a
lock resource which has been purged. This will cause the process to
hang forever in dlmlock() as the ast msg can't be handled due to its
lock resource not existing.
dlm_get_lock_resource {
...
spin_lock(&dlm->spinlock);
tmpres = __dlm_lookup_lockres_full(dlm, lockid, namelen, hash);
if (tmpres) {
spin_unlock(&dlm->spinlock);
>>>>>>>> race window, dlm_run_purge_list() may run and purge
the lock resource
spin_lock(&tmpres->spinlock);
...
spin_unlock(&tmpres->spinlock);
}
}
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Joseph Qi <joseph.qi@huawei.com>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b1432a2a35565f538586774a03bf277c27fc267d upstream.
There is a race window in dlm_get_lock_resource(), which may return a
lock resource which has been purged. This will cause the process to
hang forever in dlmlock() as the ast msg can't be handled due to its
lock resource not existing.
dlm_get_lock_resource {
...
spin_lock(&dlm->spinlock);
tmpres = __dlm_lookup_lockres_full(dlm, lockid, namelen, hash);
if (tmpres) {
spin_unlock(&dlm->spinlock);
>>>>>>>> race window, dlm_run_purge_list() may run and purge
the lock resource
spin_lock(&tmpres->spinlock);
...
spin_unlock(&tmpres->spinlock);
}
}
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Joseph Qi <joseph.qi@huawei.com>
Cc: Mark Fasheh <mfasheh@suse.com>
Cc: Joel Becker <jlbec@evilplan.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mailbox/omap: check for any unread messages during suspend
The OMAP mailbox driver is used by clients to communicate with remote
processors in general. The mailbox clients are expected to have stopped
communicating with these remote processors during a system suspend. The
OMAP mailbox fifos are expected to not have any messages as such. Add a
check for any pending unprocessed messages in the suspend callback, to
detect any communication protocol issues of the mailbox clients. The
system suspend is aborted if any messsages are found.
Signed-off-by: Suman Anna <s-anna@ti.com>
The OMAP mailbox driver is used by clients to communicate with remote
processors in general. The mailbox clients are expected to have stopped
communicating with these remote processors during a system suspend. The
OMAP mailbox fifos are expected to not have any messages as such. Add a
check for any pending unprocessed messages in the suspend callback, to
detect any communication protocol issues of the mailbox clients. The
system suspend is aborted if any messsages are found.
Signed-off-by: Suman Anna <s-anna@ti.com>
mailbox/omap: add support for suspend/resume
Support has been added to the OMAP mailbox driver to allow it
to work across a system suspend/resume. The OMAP mailbox driver
requires only the interrupt configuration registers to be saved
and restored, and this is done in the suspend/resume callbacks.
The registers need to be saved only if there are active clients
at the time of suspend. The enabling and disabling of the mailbox
clocks is done automatically by the omap_device layer.
Signed-off-by: Suman Anna <s-anna@ti.com>
Support has been added to the OMAP mailbox driver to allow it
to work across a system suspend/resume. The OMAP mailbox driver
requires only the interrupt configuration registers to be saved
and restored, and this is done in the suspend/resume callbacks.
The registers need to be saved only if there are active clients
at the time of suspend. The enabling and disabling of the mailbox
clocks is done automatically by the omap_device layer.
Signed-off-by: Suman Anna <s-anna@ti.com>
mailbox/omap: store mailbox interrupt type in omap_mbox_device
The interrupt type used for identifying the layout of the interrupt
configuration registers between OMAP4+ SoCs and older SoCs is stored
only in the sub-mailbox structures for easier access. Store this type
in the the omap_mbox_device structure as well long with the other
global variables. This is being done to facilitate the context save
and restore of appropriate registers during system suspend/resume.
Signed-off-by: Suman Anna <s-anna@ti.com>
The interrupt type used for identifying the layout of the interrupt
configuration registers between OMAP4+ SoCs and older SoCs is stored
only in the sub-mailbox structures for easier access. Store this type
in the the omap_mbox_device structure as well long with the other
global variables. This is being done to facilitate the context save
and restore of appropriate registers during system suspend/resume.
Signed-off-by: Suman Anna <s-anna@ti.com>
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
* p-ti-linux-3.14.y-common: (23 commits)
arm: dra7: dts: move 7 inch touchscreen dt node to lcd7.dtsi
ARM: dts: dra72-evm: Add CAL DT node
ARM: dts: DRA7: Add ports node to CAL dtsi entry
media: v4l: ti-vpe: Document CAL driver
media: v4l: ti-vpe: Add CAL v4l2 camera capture driver
v4l: of: Read lane-polarities endpoint property
dt: bindings: Add lane-polarity property to endpoint nodes
media: ti-vpe: sc: Fix incorrect optimization
media: ti-vpe: vip: Different IRQ naming for each slice IRQ
arm: dts: am57xx-evm: Use falling edge for mt9t11x video capture
arm: dts: dra72-evm: Use falling edge for OVcamera video capture
arm: dts: dra7-evm: Use falling edge for OVcamera video capture
media: vip: Fix pixel clock polarity setting
media: ti-vpe: VPDMA RGB data type yield inverted data
media: ti-vpe: VIP/VPE/VPDMA: YUV422 data is not interpreted correctly
media: i2c: ov1063x: Fix OV1063x supported YUV 422 formats
media: i2c: mt9t111: Sensor only support UYVY
ARM: OMAP2+: pm33xx: Fix RTC wakeup src handling
ARM: OMAP2+: sleep43xx: Enable EXT_WAKEUP in RTC_PMIC register
ARM: OMAP2+: sleep33xx: Move RTC mode failure EMIF reenable to abort path
...
Change-Id: Iaa61a525c9e74c7be2404227bfc0edf415546b7d
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* p-ti-linux-3.14.y-common: (23 commits)
arm: dra7: dts: move 7 inch touchscreen dt node to lcd7.dtsi
ARM: dts: dra72-evm: Add CAL DT node
ARM: dts: DRA7: Add ports node to CAL dtsi entry
media: v4l: ti-vpe: Document CAL driver
media: v4l: ti-vpe: Add CAL v4l2 camera capture driver
v4l: of: Read lane-polarities endpoint property
dt: bindings: Add lane-polarity property to endpoint nodes
media: ti-vpe: sc: Fix incorrect optimization
media: ti-vpe: vip: Different IRQ naming for each slice IRQ
arm: dts: am57xx-evm: Use falling edge for mt9t11x video capture
arm: dts: dra72-evm: Use falling edge for OVcamera video capture
arm: dts: dra7-evm: Use falling edge for OVcamera video capture
media: vip: Fix pixel clock polarity setting
media: ti-vpe: VPDMA RGB data type yield inverted data
media: ti-vpe: VIP/VPE/VPDMA: YUV422 data is not interpreted correctly
media: i2c: ov1063x: Fix OV1063x supported YUV 422 formats
media: i2c: mt9t111: Sensor only support UYVY
ARM: OMAP2+: pm33xx: Fix RTC wakeup src handling
ARM: OMAP2+: sleep43xx: Enable EXT_WAKEUP in RTC_PMIC register
ARM: OMAP2+: sleep33xx: Move RTC mode failure EMIF reenable to abort path
...
Change-Id: Iaa61a525c9e74c7be2404227bfc0edf415546b7d
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
arm: dra7: dts: move 7 inch touchscreen dt node to lcd7.dtsi
The dt node for the 7" touchscreen controller should be part of
the 7" dtsi include and not part of the base dra7 dts file. Move that
node to the dtsi file.
Change-Id: Ic1f91c4963a45fecab03a7c78185689bea07da30
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
The dt node for the 7" touchscreen controller should be part of
the 7" dtsi include and not part of the base dra7 dts file. Move that
node to the dtsi file.
Change-Id: Ic1f91c4963a45fecab03a7c78185689bea07da30
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
Merge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel into p-ti-linux-3.14.y-common
* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel: (22 commits)
ARM: dts: dra72-evm: Add CAL DT node
ARM: dts: DRA7: Add ports node to CAL dtsi entry
media: v4l: ti-vpe: Document CAL driver
media: v4l: ti-vpe: Add CAL v4l2 camera capture driver
v4l: of: Read lane-polarities endpoint property
dt: bindings: Add lane-polarity property to endpoint nodes
media: ti-vpe: sc: Fix incorrect optimization
media: ti-vpe: vip: Different IRQ naming for each slice IRQ
arm: dts: am57xx-evm: Use falling edge for mt9t11x video capture
arm: dts: dra72-evm: Use falling edge for OVcamera video capture
arm: dts: dra7-evm: Use falling edge for OVcamera video capture
media: vip: Fix pixel clock polarity setting
media: ti-vpe: VPDMA RGB data type yield inverted data
media: ti-vpe: VIP/VPE/VPDMA: YUV422 data is not interpreted correctly
media: i2c: ov1063x: Fix OV1063x supported YUV 422 formats
media: i2c: mt9t111: Sensor only support UYVY
ARM: OMAP2+: pm33xx: Fix RTC wakeup src handling
ARM: OMAP2+: sleep43xx: Enable EXT_WAKEUP in RTC_PMIC register
ARM: OMAP2+: sleep33xx: Move RTC mode failure EMIF reenable to abort path
ARM: OMAP2+: sleep33xx: Enable EXT_WAKEUP in RTC_PMIC register
...
Conflicts:
arch/arm/boot/dts/dra72-evm.dts
Change-Id: I4a4fa832e2125e8bdddbfb79247c710c0cb0e8f9
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel: (22 commits)
ARM: dts: dra72-evm: Add CAL DT node
ARM: dts: DRA7: Add ports node to CAL dtsi entry
media: v4l: ti-vpe: Document CAL driver
media: v4l: ti-vpe: Add CAL v4l2 camera capture driver
v4l: of: Read lane-polarities endpoint property
dt: bindings: Add lane-polarity property to endpoint nodes
media: ti-vpe: sc: Fix incorrect optimization
media: ti-vpe: vip: Different IRQ naming for each slice IRQ
arm: dts: am57xx-evm: Use falling edge for mt9t11x video capture
arm: dts: dra72-evm: Use falling edge for OVcamera video capture
arm: dts: dra7-evm: Use falling edge for OVcamera video capture
media: vip: Fix pixel clock polarity setting
media: ti-vpe: VPDMA RGB data type yield inverted data
media: ti-vpe: VIP/VPE/VPDMA: YUV422 data is not interpreted correctly
media: i2c: ov1063x: Fix OV1063x supported YUV 422 formats
media: i2c: mt9t111: Sensor only support UYVY
ARM: OMAP2+: pm33xx: Fix RTC wakeup src handling
ARM: OMAP2+: sleep43xx: Enable EXT_WAKEUP in RTC_PMIC register
ARM: OMAP2+: sleep33xx: Move RTC mode failure EMIF reenable to abort path
ARM: OMAP2+: sleep33xx: Enable EXT_WAKEUP in RTC_PMIC register
...
Conflicts:
arch/arm/boot/dts/dra72-evm.dts
Change-Id: I4a4fa832e2125e8bdddbfb79247c710c0cb0e8f9
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
ARM: dts: dra72-evm: Add CAL DT node
ARM: dts: DRA7: Add ports node to CAL dtsi entry
media: v4l: ti-vpe: Document CAL driver
media: v4l: ti-vpe: Add CAL v4l2 camera capture driver
v4l: of: Read lane-polarities endpoint property
dt: bindings: Add lane-polarity property to endpoint nodes
Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
ARM: dts: dra72-evm: Add CAL DT node
ARM: dts: DRA7: Add ports node to CAL dtsi entry
media: v4l: ti-vpe: Document CAL driver
media: v4l: ti-vpe: Add CAL v4l2 camera capture driver
v4l: of: Read lane-polarities endpoint property
dt: bindings: Add lane-polarity property to endpoint nodes
Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
ARM: dts: dra72-evm: Add CAL DT node
Add CAL node to enable module probing.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Add CAL node to enable module probing.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
ARM: dts: DRA7: Add ports node to CAL dtsi entry
Added cal modules port nodes to support endpoint registration.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Added cal modules port nodes to support endpoint registration.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
media: v4l: ti-vpe: Document CAL driver
Device Tree bindings for the Camera Adaptation Layer (CAL) driver
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Device Tree bindings for the Camera Adaptation Layer (CAL) driver
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
media: v4l: ti-vpe: Add CAL v4l2 camera capture driver
The Camera Adaptation Layer (CAL) is a block which consists of a dual
port CSI2/MIPI camera capture engine.
Port #0 can handle CSI2 camera connected to up to 4 data lanes.
Port #1 can handle CSI2 camera connected to up to 2 data lanes.
The driver implements the required API/ioctls to be V4L2 compliant.
Driver supports the following:
- V4L2 API using DMABUF/MMAP buffer access based on videobuf2 api
- Asynchronous sensor sub device registration
- DT support
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
The Camera Adaptation Layer (CAL) is a block which consists of a dual
port CSI2/MIPI camera capture engine.
Port #0 can handle CSI2 camera connected to up to 4 data lanes.
Port #1 can handle CSI2 camera connected to up to 2 data lanes.
The driver implements the required API/ioctls to be V4L2 compliant.
Driver supports the following:
- V4L2 API using DMABUF/MMAP buffer access based on videobuf2 api
- Asynchronous sensor sub device registration
- DT support
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
v4l: of: Read lane-polarities endpoint property
Add lane_polarities field to struct v4l2_of_bus_mipi_csi2 and write the
contents of the lane-polarities property to it. The field tells the polarity
of the physical lanes starting from the first one. Any unused lanes are
ignored, i.e. only the polarity of the used lanes is specified.
Also rework reading the "data-lanes" property a little.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Add lane_polarities field to struct v4l2_of_bus_mipi_csi2 and write the
contents of the lane-polarities property to it. The field tells the polarity
of the physical lanes starting from the first one. Any unused lanes are
ignored, i.e. only the polarity of the used lanes is specified.
Also rework reading the "data-lanes" property a little.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
dt: bindings: Add lane-polarity property to endpoint nodes
Add lane-polarity property to endpoint nodes. This essentially tells that
the order of the differential signal wires is inverted.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Add lane-polarity property to endpoint nodes. This essentially tells that
the order of the differential signal wires is inverted.
Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
media: ti-vpe: sc: Fix incorrect optimization
media: ti-vpe: vip: Different IRQ naming for each slice IRQ
arm: dts: am57xx-evm: Use falling edge for mt9t11x video capture
arm: dts: dra72-evm: Use falling edge for OVcamera video capture
arm: dts: dra7-evm: Use falling edge for OVcamera video capture
media: vip: Fix pixel clock polarity setting
media: ti-vpe: VPDMA RGB data type yield inverted data
media: ti-vpe: VIP/VPE/VPDMA: YUV422 data is not interpreted correctly
media: i2c: ov1063x: Fix OV1063x supported YUV 422 formats
media: i2c: mt9t111: Sensor only support UYVY
Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
media: ti-vpe: sc: Fix incorrect optimization
media: ti-vpe: vip: Different IRQ naming for each slice IRQ
arm: dts: am57xx-evm: Use falling edge for mt9t11x video capture
arm: dts: dra72-evm: Use falling edge for OVcamera video capture
arm: dts: dra7-evm: Use falling edge for OVcamera video capture
media: vip: Fix pixel clock polarity setting
media: ti-vpe: VPDMA RGB data type yield inverted data
media: ti-vpe: VIP/VPE/VPDMA: YUV422 data is not interpreted correctly
media: i2c: ov1063x: Fix OV1063x supported YUV 422 formats
media: i2c: mt9t111: Sensor only support UYVY
Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
Merge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree into ti-linux-3.14.y
TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y
* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
ARM: OMAP2+: pm33xx: Fix RTC wakeup src handling
ARM: OMAP2+: sleep43xx: Enable EXT_WAKEUP in RTC_PMIC register
ARM: OMAP2+: sleep33xx: Move RTC mode failure EMIF reenable to abort path
ARM: OMAP2+: sleep33xx: Enable EXT_WAKEUP in RTC_PMIC register
drivers/rtc/rtc-omap.c: Enable power button wake after poweroff event
ARM: OMAP2+: pm33xx: Move rtc_write_scratch earlier suspend path
Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y
* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
ARM: OMAP2+: pm33xx: Fix RTC wakeup src handling
ARM: OMAP2+: sleep43xx: Enable EXT_WAKEUP in RTC_PMIC register
ARM: OMAP2+: sleep33xx: Move RTC mode failure EMIF reenable to abort path
ARM: OMAP2+: sleep33xx: Enable EXT_WAKEUP in RTC_PMIC register
drivers/rtc/rtc-omap.c: Enable power button wake after poweroff event
ARM: OMAP2+: pm33xx: Move rtc_write_scratch earlier suspend path
Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
media: ti-vpe: sc: Fix incorrect optimization
Current scaler library implementation of sc_set_hs_coeffs and
sc_set_vs_coeffs tries to return immediately if the calculated
coefficient index is already being used.
As the same scaler block is going to be used for all the VPE contexts,
even if the calculated index is same, the parameters have to be
reconfigured for each of the context.
Because of this, when multiple contexts use the same coefficients,
all other contexts would have zero scaling coeffients.
Fix this and also remove the unnecessary hs_index and vs_index fields.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Current scaler library implementation of sc_set_hs_coeffs and
sc_set_vs_coeffs tries to return immediately if the calculated
coefficient index is already being used.
As the same scaler block is going to be used for all the VPE contexts,
even if the calculated index is same, the parameters have to be
reconfigured for each of the context.
Because of this, when multiple contexts use the same coefficients,
all other contexts would have zero scaling coeffients.
Fix this and also remove the unnecessary hs_index and vs_index fields.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
media: ti-vpe: vip: Different IRQ naming for each slice IRQ
VIP device has two interrupts and the driver uses one for each slice.
It's easier to differentiate IRQs from each of the slice if they are
named differently.
Use the V4L2 device name for naming the interrupts so that interrupts
from different slices can be differentiated when accessed from procfs.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
VIP device has two interrupts and the driver uses one for each slice.
It's easier to differentiate IRQs from each of the slice if they are
named differently.
Use the V4L2 device name for naming the interrupts so that interrupts
from different slices can be differentiated when accessed from procfs.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
arm: dts: am57xx-evm: Use falling edge for mt9t11x video capture
Pixel clock polarity of the mt9t11x camera is such that the data
is valid at the falling edge of the clock.
Currently, it is configured for the rising edge, fix this.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Pixel clock polarity of the mt9t11x camera is such that the data
is valid at the falling edge of the clock.
Currently, it is configured for the rising edge, fix this.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
arm: dts: dra72-evm: Use falling edge for OVcamera video capture
Pixel clock polarity of the OV10633 camera is such that the data
is valid at the falling edge of the clock.
Currently, it is configured for the rising edge, fix this.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Pixel clock polarity of the OV10633 camera is such that the data
is valid at the falling edge of the clock.
Currently, it is configured for the rising edge, fix this.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
arm: dts: dra7-evm: Use falling edge for OVcamera video capture
Pixel clock polarity of the OV10633 camera is such that the data
is valid at the falling edge of the clock.
Currently, it is configured for the rising edge, fix this.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Pixel clock polarity of the OV10633 camera is such that the data
is valid at the falling edge of the clock.
Currently, it is configured for the rising edge, fix this.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
media: vip: Fix pixel clock polarity setting
Clock polarity binding used by the driver is reverse.
Setting the pclk polarity bit in parser config reg[10:10] indicates
FALLING edge parsing. (Data is valid at falling edge of clock).
Also, the pclk setting can be done for PARALLEL as well as BT656 data.
Set it for all the bus types.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Clock polarity binding used by the driver is reverse.
Setting the pclk polarity bit in parser config reg[10:10] indicates
FALLING edge parsing. (Data is valid at falling edge of clock).
Also, the pclk setting can be done for PARALLEL as well as BT656 data.
Set it for all the bus types.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
media: ti-vpe: VPDMA RGB data type yield inverted data
The VPDMA RGB data type definition have been updated
to match with Errata i819.
The updated initial values were taken from:
VPDMA_data_type_mapping_v0.2vayu_c.pdf
But some of the ARGB definition appeared to be wrong
in the document also. As they would yield RGBA instead.
They have been corrected based on experimentation.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
The VPDMA RGB data type definition have been updated
to match with Errata i819.
The updated initial values were taken from:
VPDMA_data_type_mapping_v0.2vayu_c.pdf
But some of the ARGB definition appeared to be wrong
in the document also. As they would yield RGBA instead.
They have been corrected based on experimentation.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
media: ti-vpe: VIP/VPE/VPDMA: YUV422 data is not interpreted correctly
The YUV 422 VPDMA data type were not labeled properly and two of the
variants definition were missing.
Also VIP bridged driver appears to receive the YUV 422 16 bits data
in the reverse bytes order from what is expected.
In the same process we added the missing YUV 422 variant so VIP
can handle all 4: UYVY, YUYV, VYUY and YVYU.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
The YUV 422 VPDMA data type were not labeled properly and two of the
variants definition were missing.
Also VIP bridged driver appears to receive the YUV 422 16 bits data
in the reverse bytes order from what is expected.
In the same process we added the missing YUV 422 variant so VIP
can handle all 4: UYVY, YUYV, VYUY and YVYU.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
media: i2c: ov1063x: Fix OV1063x supported YUV 422 formats
The sensor was only listing YUYV as the only supported format but
it was setting the sensor to generate UYVY instead.
This inversion was set incorrectly because the bridge driver
is grabbing the bus data out of order. This needs to be fixed in the
bridge driver instead. So the sensor should advertise and generate
consistent pixel format.
In addition it was found that the sensor was able to support all 4
variants of YUV 422 interleaved formats.
So the driver will know correctly advertised and support:
UYVY, YUYV, VYUY and YVYU.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
The sensor was only listing YUYV as the only supported format but
it was setting the sensor to generate UYVY instead.
This inversion was set incorrectly because the bridge driver
is grabbing the bus data out of order. This needs to be fixed in the
bridge driver instead. So the sensor should advertise and generate
consistent pixel format.
In addition it was found that the sensor was able to support all 4
variants of YUV 422 interleaved formats.
So the driver will know correctly advertised and support:
UYVY, YUYV, VYUY and YVYU.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
media: i2c: mt9t111: Sensor only support UYVY
The MT9T111 sensor contrary to its data sheet appears to only
support UYVY format. So update the list of supported formats
to correctly reflects this.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
The MT9T111 sensor contrary to its data sheet appears to only
support UYVY format. So update the list of supported formats
to correctly reflects this.
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
ARM: OMAP2+: pm33xx: Fix RTC wakeup src handling
Once we enable EXT_WAKEUP in the RTC_PMIC register all wakeup events
report as EXT_WAKEUP because the RTC_WAKEUP line on the SOC is connected
to the nWAKEUP signal of the PMIC which generates an event on any PMIC
power on event, whether it is a pushbutton wake or PMIC_PWR_EN change
from RTC alarm event.
Previously we check the RTC_PMIC register to determine the wakeup source
but now we can just check the RTC_STATUS register to see if RTC_ALARM1
status bit is set, and if it is report RTC_ALARM as wake source,
otherwise report another EXT_WAKEUP.
This is important not only for reporting the correct wake source but
also making sure that the RTC IRQ is set for retrigger_irq in
am33xx_pm_end, otherwise the ALARM1 status does not get cleared and if
an RTC mode transition is made with out using rtcwake (with the
intention of using PB to wake) the board will immediately wake due to
ALARM1 status and fail to enter RTC mode.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Once we enable EXT_WAKEUP in the RTC_PMIC register all wakeup events
report as EXT_WAKEUP because the RTC_WAKEUP line on the SOC is connected
to the nWAKEUP signal of the PMIC which generates an event on any PMIC
power on event, whether it is a pushbutton wake or PMIC_PWR_EN change
from RTC alarm event.
Previously we check the RTC_PMIC register to determine the wakeup source
but now we can just check the RTC_STATUS register to see if RTC_ALARM1
status bit is set, and if it is report RTC_ALARM as wake source,
otherwise report another EXT_WAKEUP.
This is important not only for reporting the correct wake source but
also making sure that the RTC IRQ is set for retrigger_irq in
am33xx_pm_end, otherwise the ALARM1 status does not get cleared and if
an RTC mode transition is made with out using rtcwake (with the
intention of using PB to wake) the board will immediately wake due to
ALARM1 status and fail to enter RTC mode.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: sleep43xx: Enable EXT_WAKEUP in RTC_PMIC register
We must set the EXT_WAKEUP_EN and EXT_WAKEUP_POL bits in the RTC_PMIC
register in order for pushbutton wake to work from RTC modes, otherwise
the PMIC will never see the PMIC_PWR_EN signal go high again and enter
off-mode after 20 seconds on boards that support RTC sleep modes.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
We must set the EXT_WAKEUP_EN and EXT_WAKEUP_POL bits in the RTC_PMIC
register in order for pushbutton wake to work from RTC modes, otherwise
the PMIC will never see the PMIC_PWR_EN signal go high again and enter
off-mode after 20 seconds on boards that support RTC sleep modes.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: sleep33xx: Move RTC mode failure EMIF reenable to abort path
Previously, on an RTC mode abort, the EMIF reenable path followed the
DeepSleep EMIF restore path which assumes no MMU is active which will
not work, so we must use the abort path, which knows that the MMU is
still enabled and just reenables the EMIF rather than trying to restore
context which isn't needed in an abort.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Previously, on an RTC mode abort, the EMIF reenable path followed the
DeepSleep EMIF restore path which assumes no MMU is active which will
not work, so we must use the abort path, which knows that the MMU is
still enabled and just reenables the EMIF rather than trying to restore
context which isn't needed in an abort.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: sleep33xx: Enable EXT_WAKEUP in RTC_PMIC register
We must set the EXT_WAKEUP_EN and EXT_WAKEUP_POL bits in the RTC_PMIC
register in order for pushbutton wake to work from RTC modes, otherwise
the PMIC will never see the PMIC_PWR_EN signal go high again and enter
off-mode after 20 seconds on boards that support RTC sleep modes.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
We must set the EXT_WAKEUP_EN and EXT_WAKEUP_POL bits in the RTC_PMIC
register in order for pushbutton wake to work from RTC modes, otherwise
the PMIC will never see the PMIC_PWR_EN signal go high again and enter
off-mode after 20 seconds on boards that support RTC sleep modes.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
drivers/rtc/rtc-omap.c: Enable power button wake after poweroff event
In order for the rtc to properly reassert PMIC_PWR_EN signal after
a power button event that occurs after the board has been shut off
with a poweroff command we must make sure we set the EXT_WAKEUP_EN
and EXT_WAKEUP_POL bits in the RTC_PMIC register. Otherwise the pmic
will never see the PMIC_PWR_EN signal go low again and enter off-mode
again after 20 seconds, causing the board to power off and remain off.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
In order for the rtc to properly reassert PMIC_PWR_EN signal after
a power button event that occurs after the board has been shut off
with a poweroff command we must make sure we set the EXT_WAKEUP_EN
and EXT_WAKEUP_POL bits in the RTC_PMIC register. Otherwise the pmic
will never see the PMIC_PWR_EN signal go low again and enter off-mode
again after 20 seconds, causing the board to power off and remain off.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
ARM: OMAP2+: pm33xx: Move rtc_write_scratch earlier suspend path
We should not use mutex protected rtc_write_scratch deep in the suspend
path so move the write to earlier during am33xx_pm_begin for rtc-only
path.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Felipe Balbi <balbi@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
We should not use mutex protected rtc_write_scratch deep in the suspend
path so move the write to earlier during am33xx_pm_begin for rtc-only
path.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Reported-by: Felipe Balbi <balbi@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Acked-by: Nishanth Menon <nm@ti.com>
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
* p-ti-linux-3.14.y-common:
HACK: ti_config_fragments/connectivity.cfg: Disable UART 8250 DMA
extcon: usb-gpio: handle EPROBE_DEFER for gpio requests
mmc: host: omap_hsmmc: Fix hangs due to software/hardware timer races
phy: ti-pipe3: fix SATA when AHCI_PLATFORM is m and SATA enabled in u-boot
ARM: dts: dra7-evm: correct compatible field for pcf i2c client
mmc: host: omap_hsmmc: delete timer on suspend and remove
mmc: host: omap_hsmmc: switch over to setup_timer()/mod_timer()
Change-Id: I7ab20c3a1acfe8fd5a59d65b55d737dabd0b50d3
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* p-ti-linux-3.14.y-common:
HACK: ti_config_fragments/connectivity.cfg: Disable UART 8250 DMA
extcon: usb-gpio: handle EPROBE_DEFER for gpio requests
mmc: host: omap_hsmmc: Fix hangs due to software/hardware timer races
phy: ti-pipe3: fix SATA when AHCI_PLATFORM is m and SATA enabled in u-boot
ARM: dts: dra7-evm: correct compatible field for pcf i2c client
mmc: host: omap_hsmmc: delete timer on suspend and remove
mmc: host: omap_hsmmc: switch over to setup_timer()/mod_timer()
Change-Id: I7ab20c3a1acfe8fd5a59d65b55d737dabd0b50d3
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel into p-ti-linux-3.14.y-common
* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel:
HACK: ti_config_fragments/connectivity.cfg: Disable UART 8250 DMA
extcon: usb-gpio: handle EPROBE_DEFER for gpio requests
mmc: host: omap_hsmmc: Fix hangs due to software/hardware timer races
phy: ti-pipe3: fix SATA when AHCI_PLATFORM is m and SATA enabled in u-boot
ARM: dts: dra7-evm: correct compatible field for pcf i2c client
mmc: host: omap_hsmmc: delete timer on suspend and remove
mmc: host: omap_hsmmc: switch over to setup_timer()/mod_timer()
Change-Id: I4177a7c52c5d44e5556070d7952f21439dd1b6ea
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel:
HACK: ti_config_fragments/connectivity.cfg: Disable UART 8250 DMA
extcon: usb-gpio: handle EPROBE_DEFER for gpio requests
mmc: host: omap_hsmmc: Fix hangs due to software/hardware timer races
phy: ti-pipe3: fix SATA when AHCI_PLATFORM is m and SATA enabled in u-boot
ARM: dts: dra7-evm: correct compatible field for pcf i2c client
mmc: host: omap_hsmmc: delete timer on suspend and remove
mmc: host: omap_hsmmc: switch over to setup_timer()/mod_timer()
Change-Id: I4177a7c52c5d44e5556070d7952f21439dd1b6ea
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y
* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
HACK: ti_config_fragments/connectivity.cfg: Disable UART 8250 DMA
extcon: usb-gpio: handle EPROBE_DEFER for gpio requests
mmc: host: omap_hsmmc: Fix hangs due to software/hardware timer races
phy: ti-pipe3: fix SATA when AHCI_PLATFORM is m and SATA enabled in u-boot
ARM: dts: dra7-evm: correct compatible field for pcf i2c client
mmc: host: omap_hsmmc: delete timer on suspend and remove
mmc: host: omap_hsmmc: switch over to setup_timer()/mod_timer()
Signed-off-by: Dan Murphy <dmurphy@ti.com>
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y
* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
HACK: ti_config_fragments/connectivity.cfg: Disable UART 8250 DMA
extcon: usb-gpio: handle EPROBE_DEFER for gpio requests
mmc: host: omap_hsmmc: Fix hangs due to software/hardware timer races
phy: ti-pipe3: fix SATA when AHCI_PLATFORM is m and SATA enabled in u-boot
ARM: dts: dra7-evm: correct compatible field for pcf i2c client
mmc: host: omap_hsmmc: delete timer on suspend and remove
mmc: host: omap_hsmmc: switch over to setup_timer()/mod_timer()
Signed-off-by: Dan Murphy <dmurphy@ti.com>
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
* p-ti-linux-3.14.y-common:
usb: dwc3: usb role switch through debugfs entries
ti_config_fragments: auto: Enable camera drivers
Change-Id: Ied106ea416bd16039f51672509f2ed416d875dcc
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* p-ti-linux-3.14.y-common:
usb: dwc3: usb role switch through debugfs entries
ti_config_fragments: auto: Enable camera drivers
Change-Id: Ied106ea416bd16039f51672509f2ed416d875dcc
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
usb: dwc3: usb role switch through debugfs entries
Adding support to dual role switch through debugfs entries
usage:
1) mount debugfs
# mount -t debugfs debugfs /mnt
2) To switch usb1 to device/host mode
# echo "device" > /mnt/4889000.dwc3/mode
# echo "host" > /mnt/4889000.dwc3/mode
3) To switch usb2 to device/host mode
# echo "device" > /mnt/488d000.dwc3/mode
# echo "host" > /mnt/488d000.dwc3/mode
To switch to device mode: make sure previous mode is host.
To switch to host mode: make sure previous mode is device.
Change-Id: Iec0515b338bde6fda52c81ec754c5e8248688130
Signed-off-by: Ravi Babu <ravibabu@ti.com>
Adding support to dual role switch through debugfs entries
usage:
1) mount debugfs
# mount -t debugfs debugfs /mnt
2) To switch usb1 to device/host mode
# echo "device" > /mnt/4889000.dwc3/mode
# echo "host" > /mnt/4889000.dwc3/mode
3) To switch usb2 to device/host mode
# echo "device" > /mnt/488d000.dwc3/mode
# echo "host" > /mnt/488d000.dwc3/mode
To switch to device mode: make sure previous mode is host.
To switch to host mode: make sure previous mode is device.
Change-Id: Iec0515b338bde6fda52c81ec754c5e8248688130
Signed-off-by: Ravi Babu <ravibabu@ti.com>
ti_config_fragments: auto: Enable camera drivers
Enable camera drivers for OV10633/OV10635 and
the serializer/deserializer drivers required for the
LVDS cameras and FPDlink display
Also enable the gpio expander driver used to drive deserializers
Change-Id: I90fe14f5f519569dc7ddd8714dd7df5d8a30410c
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Enable camera drivers for OV10633/OV10635 and
the serializer/deserializer drivers required for the
LVDS cameras and FPDlink display
Also enable the gpio expander driver used to drive deserializers
Change-Id: I90fe14f5f519569dc7ddd8714dd7df5d8a30410c
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Merge branch 'p-android-3.14' into p-ti-linux-3.14.y-android
* p-android-3.14:
Revert "Revert "nf: IDLETIMER: Adds the uid field in the msg""
proc: uid_cputime: fix show_uid_stat permission
nf: IDLETIMER: Fix broken uid field in the msg
Change-Id: I24a55ff1aa43506cc1298e285e8be34bf91e3b44
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* p-android-3.14:
Revert "Revert "nf: IDLETIMER: Adds the uid field in the msg""
proc: uid_cputime: fix show_uid_stat permission
nf: IDLETIMER: Fix broken uid field in the msg
Change-Id: I24a55ff1aa43506cc1298e285e8be34bf91e3b44
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'android-3.14' of https://android.googlesource.com/kernel/common into p-android-3.14
* 'android-3.14' of https://android.googlesource.com/kernel/common:
proc: uid_cputime: fix show_uid_stat permission
nf: IDLETIMER: Fix broken uid field in the msg
Change-Id: I0ba40d2419877e1869100ba4aaac0b65c762e1b3
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* 'android-3.14' of https://android.googlesource.com/kernel/common:
proc: uid_cputime: fix show_uid_stat permission
nf: IDLETIMER: Fix broken uid field in the msg
Change-Id: I0ba40d2419877e1869100ba4aaac0b65c762e1b3
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Revert "Revert "nf: IDLETIMER: Adds the uid field in the msg""
This reverts commit e143c5b2448a701fe149d3b2c64b6c1a90ff3a9e.
Correct fix in google-common-3.14 branch now.
Change-Id: Ie227d209fbf3e5926f2278cc3c3bcb39f3637328
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
This reverts commit e143c5b2448a701fe149d3b2c64b6c1a90ff3a9e.
Correct fix in google-common-3.14 branch now.
Change-Id: Ie227d209fbf3e5926f2278cc3c3bcb39f3637328
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'p-ti-linux-3.14.y-common' into p-ti-linux-3.14.y-android
* p-ti-linux-3.14.y-common: (45 commits)
Linux 3.14.42
ARC: signal handling robustify
UBI: fix soft lockup in ubi_check_volume()
compal-laptop: Fix leaking hwmon device
Drivers: hv: vmbus: Don't wait after requesting offers
staging: panel: fix lcd type
usb: gadget: printer: enqueue printer's response for setup request
usb: host: ehci: use new USB_RESUME_TIMEOUT
usb: host: oxu210hp: use new USB_RESUME_TIMEOUT
usb: musb: use new USB_RESUME_TIMEOUT
drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5
3w-sas: fix command completion race
3w-9xxx: fix command completion race
3w-xxxx: fix command completion race
ext4: fix data corruption caused by unwritten and delayed extents
rbd: end I/O the entire obj_request on error
tty/serial: at91: maxburst was missing for dma transfers
ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE
serial: of-serial: Remove device_type = "serial" registration
ALSA: hda - Add mute-LED mode control to Thinkpad
...
Change-Id: Ia8b5f98c3fddb203119fc832b453bf4319b20883
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* p-ti-linux-3.14.y-common: (45 commits)
Linux 3.14.42
ARC: signal handling robustify
UBI: fix soft lockup in ubi_check_volume()
compal-laptop: Fix leaking hwmon device
Drivers: hv: vmbus: Don't wait after requesting offers
staging: panel: fix lcd type
usb: gadget: printer: enqueue printer's response for setup request
usb: host: ehci: use new USB_RESUME_TIMEOUT
usb: host: oxu210hp: use new USB_RESUME_TIMEOUT
usb: musb: use new USB_RESUME_TIMEOUT
drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5
3w-sas: fix command completion race
3w-9xxx: fix command completion race
3w-xxxx: fix command completion race
ext4: fix data corruption caused by unwritten and delayed extents
rbd: end I/O the entire obj_request on error
tty/serial: at91: maxburst was missing for dma transfers
ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE
serial: of-serial: Remove device_type = "serial" registration
ALSA: hda - Add mute-LED mode control to Thinkpad
...
Change-Id: Ia8b5f98c3fddb203119fc832b453bf4319b20883
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel into p-ti-linux-3.14.y-common
* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel: (26 commits)
Linux 3.14.42
ARC: signal handling robustify
UBI: fix soft lockup in ubi_check_volume()
compal-laptop: Fix leaking hwmon device
Drivers: hv: vmbus: Don't wait after requesting offers
staging: panel: fix lcd type
usb: gadget: printer: enqueue printer's response for setup request
usb: host: ehci: use new USB_RESUME_TIMEOUT
usb: host: oxu210hp: use new USB_RESUME_TIMEOUT
usb: musb: use new USB_RESUME_TIMEOUT
drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5
3w-sas: fix command completion race
3w-9xxx: fix command completion race
3w-xxxx: fix command completion race
ext4: fix data corruption caused by unwritten and delayed extents
rbd: end I/O the entire obj_request on error
tty/serial: at91: maxburst was missing for dma transfers
ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE
serial: of-serial: Remove device_type = "serial" registration
ALSA: hda - Add mute-LED mode control to Thinkpad
...
Change-Id: I1e1de49f0734aa5140f25978e4a3e295dc83fa42
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel: (26 commits)
Linux 3.14.42
ARC: signal handling robustify
UBI: fix soft lockup in ubi_check_volume()
compal-laptop: Fix leaking hwmon device
Drivers: hv: vmbus: Don't wait after requesting offers
staging: panel: fix lcd type
usb: gadget: printer: enqueue printer's response for setup request
usb: host: ehci: use new USB_RESUME_TIMEOUT
usb: host: oxu210hp: use new USB_RESUME_TIMEOUT
usb: musb: use new USB_RESUME_TIMEOUT
drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5
3w-sas: fix command completion race
3w-9xxx: fix command completion race
3w-xxxx: fix command completion race
ext4: fix data corruption caused by unwritten and delayed extents
rbd: end I/O the entire obj_request on error
tty/serial: at91: maxburst was missing for dma transfers
ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE
serial: of-serial: Remove device_type = "serial" registration
ALSA: hda - Add mute-LED mode control to Thinkpad
...
Change-Id: I1e1de49f0734aa5140f25978e4a3e295dc83fa42
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel into p-ti-linux-3.14.y-common
* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel:
OMAPDSS: sii9022-audio: Make reference clock inaccuracy message less alarming
OMAPDSS: sii9022: retry edid read
OMAPDSS: sii9022: split sii9022_read_edid function
OMAPDSS: sii9022: fix audio locking
OMAPDSS: sii9022: rename irq handler
ARM: OMAP: Check for clocks which do not have parents
phy: ti-pipe3: remove left over debug print
ARM: dts: am57xx-evm: drive gpio2_8 low in order to reset PCIe cards
pci: host: dra7xx: Add support to make gpio drive PERST# line
ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
ARM: dts: DRA7: Add DT node for AES2 IP
ARM: DRA7: hwmod: Add data for AES2 IP
crypto: omap-aes - Add support for multiple cores
crypto: omap-aes - Fix registration of Algos
crypto: omap-aes - Fix enabling clocks
crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
crypto: omap-aes - Add support for GCM mode
crypto: omap-aes - Fix configuring of AES mode
crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
Change-Id: Ib917f406ada5822358258234ba136d46e9f97590
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel:
OMAPDSS: sii9022-audio: Make reference clock inaccuracy message less alarming
OMAPDSS: sii9022: retry edid read
OMAPDSS: sii9022: split sii9022_read_edid function
OMAPDSS: sii9022: fix audio locking
OMAPDSS: sii9022: rename irq handler
ARM: OMAP: Check for clocks which do not have parents
phy: ti-pipe3: remove left over debug print
ARM: dts: am57xx-evm: drive gpio2_8 low in order to reset PCIe cards
pci: host: dra7xx: Add support to make gpio drive PERST# line
ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
ARM: dts: DRA7: Add DT node for AES2 IP
ARM: DRA7: hwmod: Add data for AES2 IP
crypto: omap-aes - Add support for multiple cores
crypto: omap-aes - Fix registration of Algos
crypto: omap-aes - Fix enabling clocks
crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
crypto: omap-aes - Add support for GCM mode
crypto: omap-aes - Fix configuring of AES mode
crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
Change-Id: Ib917f406ada5822358258234ba136d46e9f97590
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
Merge tag 'v3.14.42' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-3.14.y
This is the 3.14.42 stable release
* tag 'v3.14.42' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (26 commits)
Linux 3.14.42
ARC: signal handling robustify
UBI: fix soft lockup in ubi_check_volume()
compal-laptop: Fix leaking hwmon device
Drivers: hv: vmbus: Don't wait after requesting offers
staging: panel: fix lcd type
usb: gadget: printer: enqueue printer's response for setup request
usb: host: ehci: use new USB_RESUME_TIMEOUT
usb: host: oxu210hp: use new USB_RESUME_TIMEOUT
usb: musb: use new USB_RESUME_TIMEOUT
drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5
3w-sas: fix command completion race
3w-9xxx: fix command completion race
3w-xxxx: fix command completion race
ext4: fix data corruption caused by unwritten and delayed extents
rbd: end I/O the entire obj_request on error
tty/serial: at91: maxburst was missing for dma transfers
ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE
serial: of-serial: Remove device_type = "serial" registration
ALSA: hda - Add mute-LED mode control to Thinkpad
...
Conflicts:
drivers/usb/musb/musb_core.c
Signed-off-by: Dan Murphy <dmurphy@ti.com>
This is the 3.14.42 stable release
* tag 'v3.14.42' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (26 commits)
Linux 3.14.42
ARC: signal handling robustify
UBI: fix soft lockup in ubi_check_volume()
compal-laptop: Fix leaking hwmon device
Drivers: hv: vmbus: Don't wait after requesting offers
staging: panel: fix lcd type
usb: gadget: printer: enqueue printer's response for setup request
usb: host: ehci: use new USB_RESUME_TIMEOUT
usb: host: oxu210hp: use new USB_RESUME_TIMEOUT
usb: musb: use new USB_RESUME_TIMEOUT
drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5
3w-sas: fix command completion race
3w-9xxx: fix command completion race
3w-xxxx: fix command completion race
ext4: fix data corruption caused by unwritten and delayed extents
rbd: end I/O the entire obj_request on error
tty/serial: at91: maxburst was missing for dma transfers
ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE
serial: of-serial: Remove device_type = "serial" registration
ALSA: hda - Add mute-LED mode control to Thinkpad
...
Conflicts:
drivers/usb/musb/musb_core.c
Signed-off-by: Dan Murphy <dmurphy@ti.com>
HACK: ti_config_fragments/connectivity.cfg: Disable UART 8250 DMA
Multiple failures are seemed to be caused by 8250 DMA:
* board crash due to dma errors if it is suspended while crypto
operations are in progress
* edma unmanaged events errors caused nand write failures during
suspend
* board aborts suspend sequence due to late interrupt generated by
presumably uart dma
So disable it to have a more stable system.
Signed-off-by: Carlos Hernandez <ceh@ti.com>
Multiple failures are seemed to be caused by 8250 DMA:
* board crash due to dma errors if it is suspended while crypto
operations are in progress
* edma unmanaged events errors caused nand write failures during
suspend
* board aborts suspend sequence due to late interrupt generated by
presumably uart dma
So disable it to have a more stable system.
Signed-off-by: Carlos Hernandez <ceh@ti.com>
extcon: usb-gpio: handle EPROBE_DEFER for gpio requests
The extcon us gpio driver requests id and vbus gpios during
probe. This could fail with -EPROBE_DEFER in case the gpiochip
that has the specific gpio pin is not initialised. For eg: the
gpiochip could be an i2c client and is not probed at the time that
the extcon driver gets probed.
Propagating the EPROBE_DEFER error lets the extcon driver probe
function to be called again until it succeeds or error out with
something other than EPROBE_DEFER.
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
[nsekhar@ti.com: move EPROBE_DEFER check inside IS_ERR() check]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
The extcon us gpio driver requests id and vbus gpios during
probe. This could fail with -EPROBE_DEFER in case the gpiochip
that has the specific gpio pin is not initialised. For eg: the
gpiochip could be an i2c client and is not probed at the time that
the extcon driver gets probed.
Propagating the EPROBE_DEFER error lets the extcon driver probe
function to be called again until it succeeds or error out with
something other than EPROBE_DEFER.
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
[nsekhar@ti.com: move EPROBE_DEFER check inside IS_ERR() check]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
OMAPDSS: sii9022-audio: Make reference clock inaccuracy message less alarming
OMAPDSS: sii9022: retry edid read
OMAPDSS: sii9022: split sii9022_read_edid function
OMAPDSS: sii9022: fix audio locking
OMAPDSS: sii9022: rename irq handler
Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y
* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
OMAPDSS: sii9022-audio: Make reference clock inaccuracy message less alarming
OMAPDSS: sii9022: retry edid read
OMAPDSS: sii9022: split sii9022_read_edid function
OMAPDSS: sii9022: fix audio locking
OMAPDSS: sii9022: rename irq handler
Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
Linux 3.14.42
ARC: signal handling robustify
commit e4140819dadc3624accac8294881bca8a3cba4ed upstream.
A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....
Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.
Reproducer signal handler:
void handle_sig(int signo, siginfo_t *info, void *context)
{
ucontext_t *uc = context;
struct user_regs_struct *regs = &(uc->uc_mcontext.regs);
regs->scratch.status32 = 0;
}
Before the fix, kernel would go off to weeds like below:
--------->8-----------
[ARCLinux]$ ./signal-test
Path: /signal-test
CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000
[ECR ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
[EFA ]: 0x00000010
[BLINK ]: 0x2007c1ee
[ERET ]: 0x10698
[STAT32]: 0x00000000 : <--------
BTA: 0x00010680 SP: 0x5ffe7e48 FP: 0x00000000
LPS: 0x20003c6c LPE: 0x20003c70 LPC: 0x00000000
...
--------->8-----------
Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e4140819dadc3624accac8294881bca8a3cba4ed upstream.
A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....
Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.
Reproducer signal handler:
void handle_sig(int signo, siginfo_t *info, void *context)
{
ucontext_t *uc = context;
struct user_regs_struct *regs = &(uc->uc_mcontext.regs);
regs->scratch.status32 = 0;
}
Before the fix, kernel would go off to weeds like below:
--------->8-----------
[ARCLinux]$ ./signal-test
Path: /signal-test
CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000
[ECR ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
[EFA ]: 0x00000010
[BLINK ]: 0x2007c1ee
[ERET ]: 0x10698
[STAT32]: 0x00000000 : <--------
BTA: 0x00010680 SP: 0x5ffe7e48 FP: 0x00000000
LPS: 0x20003c6c LPE: 0x20003c70 LPC: 0x00000000
...
--------->8-----------
Reported-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
UBI: fix soft lockup in ubi_check_volume()
commit 9aa272b492e7551a9ee0e2c83c720ea013698485 upstream.
Running mtd-utils/tests/ubi-tests/io_basic.c could cause
soft lockup or watchdog reset. It is because *updatevol*
will perform ubi_check_volume() after updating finish
and this function will full scan the updated lebs if the
volume is initialized as STATIC_VOLUME.
This patch adds *cond_resched()* in the loop of lebs scan
to avoid soft lockup.
Helped by Richard Weinberger <richard@nod.at>
[ 2158.067096] INFO: rcu_sched self-detected stall on CPU { 1} (t=2101 jiffies g=1606 c=1605 q=56)
[ 2158.172867] CPU: 1 PID: 2073 Comm: io_basic Tainted: G O 3.10.53 #21
[ 2158.172898] [<c000f624>] (unwind_backtrace+0x0/0x120) from [<c000c294>] (show_stack+0x10/0x14)
[ 2158.172918] [<c000c294>] (show_stack+0x10/0x14) from [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660)
[ 2158.172936] [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660) from [<c002b480>] (update_process_times+0x38/0x64)
[ 2158.172953] [<c002b480>] (update_process_times+0x38/0x64) from [<c005ff38>] (tick_sched_handle+0x54/0x60)
[ 2158.172966] [<c005ff38>] (tick_sched_handle+0x54/0x60) from [<c00601ac>] (tick_sched_timer+0x44/0x74)
[ 2158.172978] [<c00601ac>] (tick_sched_timer+0x44/0x74) from [<c003f348>] (__run_hrtimer+0xc8/0x1b8)
[ 2158.172992] [<c003f348>] (__run_hrtimer+0xc8/0x1b8) from [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4)
[ 2158.173007] [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4) from [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30)
[ 2158.173022] [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30) from [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124)
[ 2158.173036] [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124) from [<c0082bd8>] (generic_handle_irq+0x20/0x30)
[ 2158.173049] [<c0082bd8>] (generic_handle_irq+0x20/0x30) from [<c000969c>] (handle_IRQ+0x64/0x8c)
[ 2158.173060] [<c000969c>] (handle_IRQ+0x64/0x8c) from [<c0008544>] (gic_handle_irq+0x3c/0x60)
[ 2158.173074] [<c0008544>] (gic_handle_irq+0x3c/0x60) from [<c02f0f80>] (__irq_svc+0x40/0x50)
[ 2158.173083] Exception stack(0xc4043c98 to 0xc4043ce0)
[ 2158.173092] 3c80: c4043ce4 00000019
[ 2158.173102] 3ca0: 1f8a865f c050ad10 1f8a864c 00000031 c04b5970 0003ebce 00000000 f3550000
[ 2158.173113] 3cc0: bf00bc68 00000800 0003ebce c4043ce0 c0186d14 c0186cb8 80000013 ffffffff
[ 2158.173130] [<c02f0f80>] (__irq_svc+0x40/0x50) from [<c0186cb8>] (read_current_timer+0x4/0x38)
[ 2158.173145] [<c0186cb8>] (read_current_timer+0x4/0x38) from [<1f8a865f>] (0x1f8a865f)
[ 2183.927097] BUG: soft lockup - CPU#1 stuck for 22s! [io_basic:2073]
[ 2184.002229] Modules linked in: nandflash(O) [last unloaded: nandflash]
Signed-off-by: Wang Kai <morgan.wang@huawei.com>
Signed-off-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9aa272b492e7551a9ee0e2c83c720ea013698485 upstream.
Running mtd-utils/tests/ubi-tests/io_basic.c could cause
soft lockup or watchdog reset. It is because *updatevol*
will perform ubi_check_volume() after updating finish
and this function will full scan the updated lebs if the
volume is initialized as STATIC_VOLUME.
This patch adds *cond_resched()* in the loop of lebs scan
to avoid soft lockup.
Helped by Richard Weinberger <richard@nod.at>
[ 2158.067096] INFO: rcu_sched self-detected stall on CPU { 1} (t=2101 jiffies g=1606 c=1605 q=56)
[ 2158.172867] CPU: 1 PID: 2073 Comm: io_basic Tainted: G O 3.10.53 #21
[ 2158.172898] [<c000f624>] (unwind_backtrace+0x0/0x120) from [<c000c294>] (show_stack+0x10/0x14)
[ 2158.172918] [<c000c294>] (show_stack+0x10/0x14) from [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660)
[ 2158.172936] [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660) from [<c002b480>] (update_process_times+0x38/0x64)
[ 2158.172953] [<c002b480>] (update_process_times+0x38/0x64) from [<c005ff38>] (tick_sched_handle+0x54/0x60)
[ 2158.172966] [<c005ff38>] (tick_sched_handle+0x54/0x60) from [<c00601ac>] (tick_sched_timer+0x44/0x74)
[ 2158.172978] [<c00601ac>] (tick_sched_timer+0x44/0x74) from [<c003f348>] (__run_hrtimer+0xc8/0x1b8)
[ 2158.172992] [<c003f348>] (__run_hrtimer+0xc8/0x1b8) from [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4)
[ 2158.173007] [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4) from [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30)
[ 2158.173022] [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30) from [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124)
[ 2158.173036] [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124) from [<c0082bd8>] (generic_handle_irq+0x20/0x30)
[ 2158.173049] [<c0082bd8>] (generic_handle_irq+0x20/0x30) from [<c000969c>] (handle_IRQ+0x64/0x8c)
[ 2158.173060] [<c000969c>] (handle_IRQ+0x64/0x8c) from [<c0008544>] (gic_handle_irq+0x3c/0x60)
[ 2158.173074] [<c0008544>] (gic_handle_irq+0x3c/0x60) from [<c02f0f80>] (__irq_svc+0x40/0x50)
[ 2158.173083] Exception stack(0xc4043c98 to 0xc4043ce0)
[ 2158.173092] 3c80: c4043ce4 00000019
[ 2158.173102] 3ca0: 1f8a865f c050ad10 1f8a864c 00000031 c04b5970 0003ebce 00000000 f3550000
[ 2158.173113] 3cc0: bf00bc68 00000800 0003ebce c4043ce0 c0186d14 c0186cb8 80000013 ffffffff
[ 2158.173130] [<c02f0f80>] (__irq_svc+0x40/0x50) from [<c0186cb8>] (read_current_timer+0x4/0x38)
[ 2158.173145] [<c0186cb8>] (read_current_timer+0x4/0x38) from [<1f8a865f>] (0x1f8a865f)
[ 2183.927097] BUG: soft lockup - CPU#1 stuck for 22s! [io_basic:2073]
[ 2184.002229] Modules linked in: nandflash(O) [last unloaded: nandflash]
Signed-off-by: Wang Kai <morgan.wang@huawei.com>
Signed-off-by: hujianyang <hujianyang@huawei.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
compal-laptop: Fix leaking hwmon device
commit ad774702f1705c04e5fa492b793d8d477a504fa6 upstream.
The commit c2be45f09bb0 ("compal-laptop: Use
devm_hwmon_device_register_with_groups") wanted to change the
registering of hwmon device to resource-managed version. It mostly did
it except the main thing - it forgot to use devm-like function so the
hwmon device leaked after device removal or probe failure.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes: c2be45f09bb0 ("compal-laptop: Use devm_hwmon_device_register_with_groups")
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ad774702f1705c04e5fa492b793d8d477a504fa6 upstream.
The commit c2be45f09bb0 ("compal-laptop: Use
devm_hwmon_device_register_with_groups") wanted to change the
registering of hwmon device to resource-managed version. It mostly did
it except the main thing - it forgot to use devm-like function so the
hwmon device leaked after device removal or probe failure.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Fixes: c2be45f09bb0 ("compal-laptop: Use devm_hwmon_device_register_with_groups")
Acked-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Drivers: hv: vmbus: Don't wait after requesting offers
commit 73cffdb65e679b98893f484063462c045adcf212 upstream.
Don't wait after sending request for offers to the host. This wait is
unnecessary and simply adds 5 seconds to the boot time.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 73cffdb65e679b98893f484063462c045adcf212 upstream.
Don't wait after sending request for offers to the host. This wait is
unnecessary and simply adds 5 seconds to the boot time.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: panel: fix lcd type
commit 2c20d92dad5db6440cfa88d811b69fd605240ce4 upstream.
the lcd type as defined in the Kconfig is not matching in the code.
as a result the rs, rw and en pins were getting interchanged.
Kconfig defines the value of PANEL_LCD to be 1 if we select custom
configuration but in the code LCD_TYPE_CUSTOM is defined as 5.
my hardware is LCD_TYPE_CUSTOM, but the pins were assigned to it
as pins of LCD_TYPE_OLD, and it was not working.
Now values are corrected with referenece to the values defined in
Kconfig and it is working.
checked on JHD204A lcd with LCD_TYPE_CUSTOM configuration.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Acked-by: Willy Tarreau <w@1wt.eu>
[wt: backport to 3.10 and 3.14]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2c20d92dad5db6440cfa88d811b69fd605240ce4 upstream.
the lcd type as defined in the Kconfig is not matching in the code.
as a result the rs, rw and en pins were getting interchanged.
Kconfig defines the value of PANEL_LCD to be 1 if we select custom
configuration but in the code LCD_TYPE_CUSTOM is defined as 5.
my hardware is LCD_TYPE_CUSTOM, but the pins were assigned to it
as pins of LCD_TYPE_OLD, and it was not working.
Now values are corrected with referenece to the values defined in
Kconfig and it is working.
checked on JHD204A lcd with LCD_TYPE_CUSTOM configuration.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Acked-by: Willy Tarreau <w@1wt.eu>
[wt: backport to 3.10 and 3.14]
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: gadget: printer: enqueue printer's response for setup request
commit eb132ccbdec5df46e29c9814adf76075ce83576b upstream.
Function-specific setup requests should be handled in such a way, that
apart from filling in the data buffer, the requests are also actually
enqueued: if function-specific setup is called from composte_setup(),
the "usb_ep_queue()" block of code in composite_setup() is skipped.
The printer function lacks this part and it results in e.g. get device id
requests failing: the host expects some response, the device prepares it
but does not equeue it for sending to the host, so the host finally asserts
timeout.
This patch adds enqueueing the prepared responses.
Fixes: 2e87edf49227: "usb: gadget: make g_printer use composite"
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
[ported to stable 3.10 and 3.14]
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eb132ccbdec5df46e29c9814adf76075ce83576b upstream.
Function-specific setup requests should be handled in such a way, that
apart from filling in the data buffer, the requests are also actually
enqueued: if function-specific setup is called from composte_setup(),
the "usb_ep_queue()" block of code in composite_setup() is skipped.
The printer function lacks this part and it results in e.g. get device id
requests failing: the host expects some response, the device prepares it
but does not equeue it for sending to the host, so the host finally asserts
timeout.
This patch adds enqueueing the prepared responses.
Fixes: 2e87edf49227: "usb: gadget: make g_printer use composite"
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
[ported to stable 3.10 and 3.14]
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: host: ehci: use new USB_RESUME_TIMEOUT
commit ea16328f80ca8d74434352157f37ef60e2f55ce2 upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ea16328f80ca8d74434352157f37ef60e2f55ce2 upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: host: oxu210hp: use new USB_RESUME_TIMEOUT
commit 84c0d178eb9f3a3ae4d63dc97a440266cf17f7f5 upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 84c0d178eb9f3a3ae4d63dc97a440266cf17f7f5 upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: musb: use new USB_RESUME_TIMEOUT
commit 309be239369609929d5d3833ee043f7c5afc95d1 upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Based on original work by Bin Liu <Bin Liu <b-liu@ti.com>>
Cc: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 309be239369609929d5d3833ee043f7c5afc95d1 upstream.
Make sure we're using the new macro, so our
resume signaling will always pass certification.
Based on original work by Bin Liu <Bin Liu <b-liu@ti.com>>
Cc: Bin Liu <b-liu@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5
commit cd17e02ff4db58ec32d35cf331c705d295779930 upstream.
Seems to have problems with high mclks.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76490
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cd17e02ff4db58ec32d35cf331c705d295779930 upstream.
Seems to have problems with high mclks.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76490
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3w-sas: fix command completion race
commit 579d69bc1fd56d5af5761969aa529d1d1c188300 upstream.
The 3w-sas driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point. Also remove the dma mapping helpers
which have another inherent race due to the request_id index.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Torsten Luettgert <ml-lkml@enda.eu>
Tested-by: Bernd Kardatzki <Bernd.Kardatzki@med.uni-tuebingen.de>
Acked-by: Adam Radford <aradford@gmail.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 579d69bc1fd56d5af5761969aa529d1d1c188300 upstream.
The 3w-sas driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point. Also remove the dma mapping helpers
which have another inherent race due to the request_id index.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Torsten Luettgert <ml-lkml@enda.eu>
Tested-by: Bernd Kardatzki <Bernd.Kardatzki@med.uni-tuebingen.de>
Acked-by: Adam Radford <aradford@gmail.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3w-9xxx: fix command completion race
commit 118c855b5623f3e2e6204f02623d88c09e0c34de upstream.
The 3w-9xxx driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point. Also remove the dma mapping helpers
which have another inherent race due to the request_id index.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Adam Radford <aradford@gmail.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 118c855b5623f3e2e6204f02623d88c09e0c34de upstream.
The 3w-9xxx driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point. Also remove the dma mapping helpers
which have another inherent race due to the request_id index.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Adam Radford <aradford@gmail.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
3w-xxxx: fix command completion race
commit 9cd9554615cba14f0877cc9972a6537ad2bdde61 upstream.
The 3w-xxxx driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point. Also remove the dma mapping helpers
which have another inherent race due to the request_id index.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Adam Radford <aradford@gmail.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9cd9554615cba14f0877cc9972a6537ad2bdde61 upstream.
The 3w-xxxx driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point. Also remove the dma mapping helpers
which have another inherent race due to the request_id index.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Adam Radford <aradford@gmail.com>
Signed-off-by: James Bottomley <JBottomley@Odin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ext4: fix data corruption caused by unwritten and delayed extents
commit d2dc317d564a46dfc683978a2e5a4f91434e9711 upstream.
Currently it is possible to lose whole file system block worth of data
when we hit the specific interaction with unwritten and delayed extents
in status extent tree.
The problem is that when we insert delayed extent into extent status
tree the only way to get rid of it is when we write out delayed buffer.
However there is a limitation in the extent status tree implementation
so that when inserting unwritten extent should there be even a single
delayed block the whole unwritten extent would be marked as delayed.
At this point, there is no way to get rid of the delayed extents,
because there are no delayed buffers to write out. So when a we write
into said unwritten extent we will convert it to written, but it still
remains delayed.
When we try to write into that block later ext4_da_map_blocks() will set
the buffer new and delayed and map it to invalid block which causes
the rest of the block to be zeroed loosing already written data.
For now we can fix this by simply not allowing to set delayed status on
written extent in the extent status tree. Also add WARN_ON() to make
sure that we notice if this happens in the future.
This problem can be easily reproduced by running the following xfs_io.
xfs_io -f -c "pwrite -S 0xaa 4096 2048" \
-c "falloc 0 131072" \
-c "pwrite -S 0xbb 65536 2048" \
-c "fsync" /mnt/test/fff
echo 3 > /proc/sys/vm/drop_caches
xfs_io -c "pwrite -S 0xdd 67584 2048" /mnt/test/fff
This can be theoretically also reproduced by at random by running fsx,
but it's not very reliable, though on machines with bigger page size
(like ppc) this can be seen more often (especially xfstest generic/127)
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d2dc317d564a46dfc683978a2e5a4f91434e9711 upstream.
Currently it is possible to lose whole file system block worth of data
when we hit the specific interaction with unwritten and delayed extents
in status extent tree.
The problem is that when we insert delayed extent into extent status
tree the only way to get rid of it is when we write out delayed buffer.
However there is a limitation in the extent status tree implementation
so that when inserting unwritten extent should there be even a single
delayed block the whole unwritten extent would be marked as delayed.
At this point, there is no way to get rid of the delayed extents,
because there are no delayed buffers to write out. So when a we write
into said unwritten extent we will convert it to written, but it still
remains delayed.
When we try to write into that block later ext4_da_map_blocks() will set
the buffer new and delayed and map it to invalid block which causes
the rest of the block to be zeroed loosing already written data.
For now we can fix this by simply not allowing to set delayed status on
written extent in the extent status tree. Also add WARN_ON() to make
sure that we notice if this happens in the future.
This problem can be easily reproduced by running the following xfs_io.
xfs_io -f -c "pwrite -S 0xaa 4096 2048" \
-c "falloc 0 131072" \
-c "pwrite -S 0xbb 65536 2048" \
-c "fsync" /mnt/test/fff
echo 3 > /proc/sys/vm/drop_caches
xfs_io -c "pwrite -S 0xdd 67584 2048" /mnt/test/fff
This can be theoretically also reproduced by at random by running fsx,
but it's not very reliable, though on machines with bigger page size
(like ppc) this can be seen more often (especially xfstest generic/127)
Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rbd: end I/O the entire obj_request on error
commit 082a75dad84d79d1c15ea9e50f31cb4bb4fa7fd6 upstream.
When we end I/O struct request with error, we need to pass
obj_request->length as @nr_bytes so that the entire obj_request worth
of bytes is completed. Otherwise block layer ends up confused and we
trip on
rbd_assert(more ^ (which == img_request->obj_request_count));
in rbd_img_obj_callback() due to more being true no matter what. We
already do it in most cases but we are missing some, in particular
those where we don't even get a chance to submit any obj_requests, due
to an early -ENOMEM for example.
A number of obj_request->xferred assignments seem to be redundant but
I haven't touched any of obj_request->xferred stuff to keep this small
and isolated.
Cc: Alex Elder <elder@linaro.org>
Reported-by: Shawn Edwards <lesser.evil@gmail.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 082a75dad84d79d1c15ea9e50f31cb4bb4fa7fd6 upstream.
When we end I/O struct request with error, we need to pass
obj_request->length as @nr_bytes so that the entire obj_request worth
of bytes is completed. Otherwise block layer ends up confused and we
trip on
rbd_assert(more ^ (which == img_request->obj_request_count));
in rbd_img_obj_callback() due to more being true no matter what. We
already do it in most cases but we are missing some, in particular
those where we don't even get a chance to submit any obj_requests, due
to an early -ENOMEM for example.
A number of obj_request->xferred assignments seem to be redundant but
I haven't touched any of obj_request->xferred stuff to keep this small
and isolated.
Cc: Alex Elder <elder@linaro.org>
Reported-by: Shawn Edwards <lesser.evil@gmail.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tty/serial: at91: maxburst was missing for dma transfers
commit a8d4e01637902311c5643b69a5c80e2805f04054 upstream.
Maxburst was not set when doing the dma slave configuration. This value
is checked by the recently introduced xdmac. It causes an error when
doing the slave configuration and so prevents from using dma.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a8d4e01637902311c5643b69a5c80e2805f04054 upstream.
Maxburst was not set when doing the dma slave configuration. This value
is checked by the recently introduced xdmac. It causes an error when
doing the slave configuration and so prevents from using dma.
Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE
commit a2d97723cb3a7741af81868427b36bba274b681b upstream.
Correct small copy and paste error where autodisable was not being
enabled for the SOC_DAPM_SINGLE_TLV_AUTODISABLE control.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a2d97723cb3a7741af81868427b36bba274b681b upstream.
Correct small copy and paste error where autodisable was not being
enabled for the SOC_DAPM_SINGLE_TLV_AUTODISABLE control.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
serial: of-serial: Remove device_type = "serial" registration
commit 6befa9d883385c580369a2cc9e53fbf329771f6d upstream.
Do not probe all serial drivers by of_serial.c which are using
device_type = "serial"; property. Only drivers which have valid
compatible strings listed in the driver should be probed.
When PORT_UNKNOWN is setup probe will fail anyway.
Arnd quotation about driver historical background:
"when I wrote that driver initially, the idea was that it would
get used as a stub to hook up all other serial drivers but after
that, the common code learned to create platform devices from DT"
This patch fix the problem with on the system with xilinx_uartps and
16550a where of_serial failed to register for xilinx_uartps and because
of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking
for irq with request_irq() EINVAL is returned.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6befa9d883385c580369a2cc9e53fbf329771f6d upstream.
Do not probe all serial drivers by of_serial.c which are using
device_type = "serial"; property. Only drivers which have valid
compatible strings listed in the driver should be probed.
When PORT_UNKNOWN is setup probe will fail anyway.
Arnd quotation about driver historical background:
"when I wrote that driver initially, the idea was that it would
get used as a stub to hook up all other serial drivers but after
that, the common code learned to create platform devices from DT"
This patch fix the problem with on the system with xilinx_uartps and
16550a where of_serial failed to register for xilinx_uartps and because
of irq_dispose_mapping() removed irq_desc. Then when xilinx_uartps was asking
for irq with request_irq() EINVAL is returned.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda - Add mute-LED mode control to Thinkpad
commit 7290006d8c0900c56d8c58428134f02c35109d17 upstream.
This patch adds the missing flag to enable "Mute-LED Mode" mixer enum
ctl for Thinkpads that have also the software mute-LED control.
Reported-and-tested-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7290006d8c0900c56d8c58428134f02c35109d17 upstream.
This patch adds the missing flag to enable "Mute-LED Mode" mixer enum
ctl for Thinkpads that have also the software mute-LED control.
Reported-and-tested-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda - Fix mute-LED fixed mode
commit ee52e56e7b12834476cd0031c5986254ba1b6317 upstream.
The mute-LED mode control has the fixed on/off states that are
supposed to remain on/off regardless of the master switch. However,
this doesn't work actually because the vmaster hook is called in the
vmaster code itself.
This patch fixes it by calling the hook indirectly after checking the
mute LED mode.
Reported-and-tested-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ee52e56e7b12834476cd0031c5986254ba1b6317 upstream.
The mute-LED mode control has the fixed on/off states that are
supposed to remain on/off regardless of the master switch. However,
this doesn't work actually because the vmaster hook is called in the
vmaster code itself.
This patch fixes it by calling the hook indirectly after checking the
mute LED mode.
Reported-and-tested-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: emu10k1: Emu10k2 32 bit DMA mode
commit 7241ea558c6715501e777396b5fc312c372e11d9 upstream.
Looks like audigy emu10k2 (probably emu10k1 - sb live too) support two
modes for DMA. Second mode is useful for 64 bit os with more then 2 GB
of ram (fixes problems with big soundfont loading)
1) 32MB from 2 GB address space using 8192 pages (used now as default)
2) 16MB from 4 GB address space using 4096 pages
Mode is set using HCFG_EXPANDED_MEM flag in HCFG register.
Also format of emu10k2 page table is then different.
Signed-off-by: Peter Zubaj <pzubaj@marticonet.sk>
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7241ea558c6715501e777396b5fc312c372e11d9 upstream.
Looks like audigy emu10k2 (probably emu10k1 - sb live too) support two
modes for DMA. Second mode is useful for 64 bit os with more then 2 GB
of ram (fixes problems with big soundfont loading)
1) 32MB from 2 GB address space using 8192 pages (used now as default)
2) 16MB from 4 GB address space using 4096 pages
Mode is set using HCFG_EXPANDED_MEM flag in HCFG register.
Also format of emu10k2 page table is then different.
Signed-off-by: Peter Zubaj <pzubaj@marticonet.sk>
Tested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: emu10k1: Fix card shortname string buffer overflow
commit d02260824e2cad626fb2a9d62e27006d34b6dedc upstream.
Some models provide too long string for the shortname that has 32bytes
including the terminator, and it results in a non-terminated string
exposed to the user-space. This isn't too critical, though, as the
string is stopped at the succeeding longname string.
This patch fixes such entries by dropping "SB" prefix (it's enough to
fit within 32 bytes, so far). Meanwhile, it also changes strcpy()
with strlcpy() to make sure that this kind of problem won't happen in
future, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d02260824e2cad626fb2a9d62e27006d34b6dedc upstream.
Some models provide too long string for the shortname that has 32bytes
including the terminator, and it results in a non-terminated string
exposed to the user-space. This isn't too critical, though, as the
string is stopped at the succeeding longname string.
This patch fixes such entries by dropping "SB" prefix (it's enough to
fit within 32 bytes, so far). Meanwhile, it also changes strcpy()
with strlcpy() to make sure that this kind of problem won't happen in
future, too.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>