Revert "wl18xx/wlcore : time sync demo [TMP]"
This reverts commit 4a10364537b4798fde51afc7f28026d58a017e71.
This reverts commit 4a10364537b4798fde51afc7f28026d58a017e71.
Revert "mmc: Wait for card_busy before starting sdio requests"
This reverts commit 5d3f6ef04d65dda92a3573841a7215fb05c347de.
This reverts commit 5d3f6ef04d65dda92a3573841a7215fb05c347de.
Arp Filtering: Add protection against null ip address
When configuring the arp filter command to FW,
make sure that we do not configure and enable
an invalid (0.0.0.0) ip address.
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
Acked-by: Maital Hahn <maitalm@ti.com>
When configuring the arp filter command to FW,
make sure that we do not configure and enable
an invalid (0.0.0.0) ip address.
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
Acked-by: Maital Hahn <maitalm@ti.com>
AP-WoW: Fix ap stop warn on [SQUASH]
Squash with previous AP WoW commit:
6594a720bd4283
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
Acked-by: Maital Hahn <maitalm@ti.com>
Squash with previous AP WoW commit:
6594a720bd4283
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
Acked-by: Maital Hahn <maitalm@ti.com>
wlcore/wl18xx: add radar_debug_mode handling
Add debugfs key (under CFG80211_CERTIFICATION_ONUS
configuration) to set/clear radar_debug_mode.
In this mode, the driver simply ignores radar
events (but prints them).
The fw is notified about this mode through
a special generic_cfg_feature command.
This mode is relevant only for ap mode. look for
it when initializing ap vif.
upstream : 8cf77e176f921d20a1e61d288
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Add debugfs key (under CFG80211_CERTIFICATION_ONUS
configuration) to set/clear radar_debug_mode.
In this mode, the driver simply ignores radar
events (but prints them).
The fw is notified about this mode through
a special generic_cfg_feature command.
This mode is relevant only for ap mode. look for
it when initializing ap vif.
upstream : 8cf77e176f921d20a1e61d288
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
mac80211: Add support for aborting an ongoing scan
This commit adds implementation for abort scan in mac80211.
Reviewed-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Vidyullatha Kanchanapally <vkanchan@qti.qualcomm.com>
Signed-off-by: Sunil Dutt <usdutt@qti.qualcomm.com>
[adjust to wdev change in previous patch and clean up code a bit]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This commit adds implementation for abort scan in mac80211.
Reviewed-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Vidyullatha Kanchanapally <vkanchan@qti.qualcomm.com>
Signed-off-by: Sunil Dutt <usdutt@qti.qualcomm.com>
[adjust to wdev change in previous patch and clean up code a bit]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
cfg80211: Add support for aborting an ongoing scan
Implement new functionality for aborting an ongoing scan.
Add NL80211_CMD_ABORT_SCAN to the nl80211 interface. After
aborting the scan, driver shall provide the scan status by
calling cfg80211_scan_done().
Reviewed-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Vidyullatha Kanchanapally <vkanchan@qti.qualcomm.com>
Signed-off-by: Sunil Dutt <usdutt@qti.qualcomm.com>
[change command to take wdev instead of netdev so that it
can be used on p2p-device scans]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Implement new functionality for aborting an ongoing scan.
Add NL80211_CMD_ABORT_SCAN to the nl80211 interface. After
aborting the scan, driver shall provide the scan status by
calling cfg80211_scan_done().
Reviewed-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Vidyullatha Kanchanapally <vkanchan@qti.qualcomm.com>
Signed-off-by: Sunil Dutt <usdutt@qti.qualcomm.com>
[change command to take wdev instead of netdev so that it
can be used on p2p-device scans]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
AP WoW: Fix bug where we configure wrong IP
after recovery.
Fixes: #WILINK8_SW_DEV-552
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
after recovery.
Fixes: #WILINK8_SW_DEV-552
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
mesh: max_peers reached falsely
Issue happened when receiving delete_sta command without
changing plink_state from ESTAB to HOLDING before.
When receiving delete_sta command for mesh interface
verify plink_state is not ESTAB and if so, decrease
plink count and update beacon.
Signed-off-by: Meirav Kama <meiravk@ti.com>
Issue happened when receiving delete_sta command without
changing plink_state from ESTAB to HOLDING before.
When receiving delete_sta command for mesh interface
verify plink_state is not ESTAB and if so, decrease
plink count and update beacon.
Signed-off-by: Meirav Kama <meiravk@ti.com>
wlcore/wl12xx: Fix fw logger over sdio
The commit fb724ed5c617 ("wlcore: Fix regression in
wlcore_set_partition()") fixed wl12xx functionality.
However, it reverted the support in fw logger
over sdio in wl18xx.
This patch reverts the changes made and also fixes
the original functionality issue introduced in wl12xx.
Fixes: fb724ed5c617
("wlcore: Fix regression in wlcore_set_partition()")
Signed-off-by: Guy Mishol <guym@ti.com>
The commit fb724ed5c617 ("wlcore: Fix regression in
wlcore_set_partition()") fixed wl12xx functionality.
However, it reverted the support in fw logger
over sdio in wl18xx.
This patch reverts the changes made and also fixes
the original functionality issue introduced in wl12xx.
Fixes: fb724ed5c617
("wlcore: Fix regression in wlcore_set_partition()")
Signed-off-by: Guy Mishol <guym@ti.com>
Revert "Revert "wlcore: Fix regression in wlcore_set_partition()""
This reverts commit 1459e7865b75733dd2f042fa58910a354f138f04.
This reverts commit 1459e7865b75733dd2f042fa58910a354f138f04.
Revert "wlcore: Fix regression in wlcore_set_partition()"
This patch removed the fw logger over SDIO support.
Revert it until the original wl12xx issue will be fixed.
This reverts commit cf508bbc9ebf568aa4d815f754c848a0a1c5d335.
This patch removed the fw logger over SDIO support.
Revert it until the original wl12xx issue will be fixed.
This reverts commit cf508bbc9ebf568aa4d815f754c848a0a1c5d335.
wlcore: remove timestamp strings prints
Due to compatability issues of 4.9 toolchain with __TIMESTAMP__ macro,
it was removed from the version related files and Makefile.
Signed-off-by: Yaniv Machani <yanivma@ti.com>
Due to compatability issues of 4.9 toolchain with __TIMESTAMP__ macro,
it was removed from the version related files and Makefile.
Signed-off-by: Yaniv Machani <yanivma@ti.com>
wlcore: add version and timestamp strings (INTERNAL)
In order to allow better version control, add version
and timestamp strings into wlcore module.
These strings will be printed on driver load, and when
reading the driver_state.
If the tree was changed and unstaged or if a new tag was added, we
were not regenerating the version.h file, so it would contain outdated
information.
To fix this, force the version.h file to be rechecked during make and
use __TIMESTAMP__ instead of using the shell's date command, so that
we don't regenerate it everytime.
Additionally, use --dirty in git describe to mark dirty trees as such.
With compat-wireless, we shouldn't force the version.h file checks,
otherwise it will overwrite what we generated in compat-wireless
itself. This was only needed for dirty trees anyway. The side-effect
is that the version will not be regenerated when the tree becomes
dirty.
In environments without .git folder, use release_version.h instead.
There are some reports of compilation errors due
to missing version.h.
This probably means that version.h wasn't recognized
as a dependency, and wasn't generated.
Declare this dependency explicitly in order to make
sure version.h will be generated.
if we use backports to compile our driver, the compilation
is done on the target kernel, but we want to generate the
version tag from the driver git.
check for the existence of KLIB_BUILD and GIT_TREE params,
and generate version.h from the GIT_TREE if they both
exist.
(note that backports doesn't require GIT_TREE to be
defined, so it has to be part of the build script)
When checking for git existence in wlcore's Makefile,
use $(PWD), as the built-in wildcard function returns
unexpected results when working against remote
makefile (e.g. when using backports).
git describe --dirty doesn't work well when specfiying
git-dir and work-tree parameters (git diff-index doesn't
run against the work-tree, resulting in -dirty always
being set).
workaround it by changing the current directory to the
git directory before running the command.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
In order to allow better version control, add version
and timestamp strings into wlcore module.
These strings will be printed on driver load, and when
reading the driver_state.
If the tree was changed and unstaged or if a new tag was added, we
were not regenerating the version.h file, so it would contain outdated
information.
To fix this, force the version.h file to be rechecked during make and
use __TIMESTAMP__ instead of using the shell's date command, so that
we don't regenerate it everytime.
Additionally, use --dirty in git describe to mark dirty trees as such.
With compat-wireless, we shouldn't force the version.h file checks,
otherwise it will overwrite what we generated in compat-wireless
itself. This was only needed for dirty trees anyway. The side-effect
is that the version will not be regenerated when the tree becomes
dirty.
In environments without .git folder, use release_version.h instead.
There are some reports of compilation errors due
to missing version.h.
This probably means that version.h wasn't recognized
as a dependency, and wasn't generated.
Declare this dependency explicitly in order to make
sure version.h will be generated.
if we use backports to compile our driver, the compilation
is done on the target kernel, but we want to generate the
version tag from the driver git.
check for the existence of KLIB_BUILD and GIT_TREE params,
and generate version.h from the GIT_TREE if they both
exist.
(note that backports doesn't require GIT_TREE to be
defined, so it has to be part of the build script)
When checking for git existence in wlcore's Makefile,
use $(PWD), as the built-in wildcard function returns
unexpected results when working against remote
makefile (e.g. when using backports).
git describe --dirty doesn't work well when specfiying
git-dir and work-tree parameters (git diff-index doesn't
run against the work-tree, resulting in -dirty always
being set).
workaround it by changing the current directory to the
git directory before running the command.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Signed-off-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Arik Nemtsov <arik@wizery.com>
Revert "tcp: refine pacing rate determination" [WORAROUND]
this patch seems to have bad performance impact on the first seconds
as we test ~60 seconds, this shows poor results.
This reverts commit 43e122b014c955a33220fabbd09c4b5e4f422c3c.
this patch seems to have bad performance impact on the first seconds
as we test ~60 seconds, this shows poor results.
This reverts commit 43e122b014c955a33220fabbd09c4b5e4f422c3c.
wlcore: Fix regression in wlcore_set_partition()
The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") introduced a
regression causing the wlcore to time out and go into recovery. Reverting the
changes regarding write of the last partition size brings the module back to
it's functional state.
Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio")
Reported-by: Ross Green <rgkernel@gmail.com>
Signed-off-by: Emil Goode <emil.fsw@goode.io>
[kvalo@codeaurora.org: improved commit log]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The commit 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio") introduced a
regression causing the wlcore to time out and go into recovery. Reverting the
changes regarding write of the last partition size brings the module back to
it's functional state.
Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio")
Reported-by: Ross Green <rgkernel@gmail.com>
Signed-off-by: Emil Goode <emil.fsw@goode.io>
[kvalo@codeaurora.org: improved commit log]
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
wlcore: fix error handling in wlcore_event_fw_logger
wlcore_read/wlcore_write can return negative values so it should
be assigned to signed variable.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2120705
Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio")
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
wlcore_read/wlcore_write can return negative values so it should
be assigned to signed variable.
The problem has been detected using proposed semantic patch
scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
[1]: http://permalink.gmane.org/gmane.linux.kernel/2120705
Fixes: 3719c17e1816 ("wlcore/wl18xx: fw logger over sdio")
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
wlcore/wl18xx: fw logger over sdio
Enable the FW Logger to work over the SDIO interface in addition to over UART
interface. In the new design we use fw internal memory instead of packet ram
that was used in older (wl12xx) design. This change reduces the impact on TP
and stability.
A new event was added to notify fw logger is ready for reading. Dynamic
configuration to debugfs was added as well.
Signed-off-by: Shahar Patury <shaharp@ti.com>
Signed-off-by: Guy Mishol <guym@ti.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Enable the FW Logger to work over the SDIO interface in addition to over UART
interface. In the new design we use fw internal memory instead of packet ram
that was used in older (wl12xx) design. This change reduces the impact on TP
and stability.
A new event was added to notify fw logger is ready for reading. Dynamic
configuration to debugfs was added as well.
Signed-off-by: Shahar Patury <shaharp@ti.com>
Signed-off-by: Guy Mishol <guym@ti.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
WoW: Add WoW when acting as AP.
fixes #WILINK8_SW_DEV-506
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
Acked-by: Maital Hahn <maitalm@ti.com>
fixes #WILINK8_SW_DEV-506
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
Acked-by: Maital Hahn <maitalm@ti.com>
bbb:dts: update wilink8 capes to the latest version
update baseline dtb to match kerenl changes
Signed-off-by: Yaniv Machani <yanivma@ti.com>
update baseline dtb to match kerenl changes
Signed-off-by: Yaniv Machani <yanivma@ti.com>
dts:am335x-evm-wow : update dtb with latest changes
updated base dtb to support the latest changes and WoW
Signed-off-by: Yaniv Machani <yanivma@ti.com>
updated base dtb to support the latest changes and WoW
Signed-off-by: Yaniv Machani <yanivma@ti.com>
dts :am335x-evm-wow: update dts file with latest changes
Update the am335x-evm-wow with changes taken from 4.4.6 kernel
Signed-off-by: Yaniv Machani <yanivma@ti.com>
Update the am335x-evm-wow with changes taken from 4.4.6 kernel
Signed-off-by: Yaniv Machani <yanivma@ti.com>
wl18xx: multi-role AP & GO doesn't work
Added support for multi-role AP & GO, by adding this combination
to the supported combinations in the wilink driver.
Signed-off-by: Maital Hahn <maitalm@ti.com>
Added support for multi-role AP & GO, by adding this combination
to the supported combinations in the wilink driver.
Signed-off-by: Maital Hahn <maitalm@ti.com>
mesh: mesh is not connected properly after recovery
In the reconfigure process for mesh interface, moved the reconfiguration
of the mesh peers to be done only after restarting the beacons,
the same as it is done for AP.
Signed-off-by: Maital Hahn <maitalm@ti.com>
In the reconfigure process for mesh interface, moved the reconfiguration
of the mesh peers to be done only after restarting the beacons,
the same as it is done for AP.
Signed-off-by: Maital Hahn <maitalm@ti.com>
mesh: frames received out of order
MP received data frames from another MP. Frames are forwarded
from Rx to Tx to be transmitted to a third MP.
Upon cloning the skb, the tx_info was zeroed, and the
hw_queue wasn't set correctly, causing frames to be
inserted to queue 0 (VOICE). If requeue occured for some
reason, frame will be inserted to correct queue 2 (BE).
In this case frames are now dequeued from 2 different queues and
sent out of order.
Signed-off-by: Meirav Kama <meiravk@ti.com>
MP received data frames from another MP. Frames are forwarded
from Rx to Tx to be transmitted to a third MP.
Upon cloning the skb, the tx_info was zeroed, and the
hw_queue wasn't set correctly, causing frames to be
inserted to queue 0 (VOICE). If requeue occured for some
reason, frame will be inserted to correct queue 2 (BE).
In this case frames are now dequeued from 2 different queues and
sent out of order.
Signed-off-by: Meirav Kama <meiravk@ti.com>
mesh: path selection improvements
Added vendor specific info element to path req/rep that contains
the previous mesh point from which sender received the frame and
the metric between them.
When action received with this ie, the included info is taken into
account when deciding best path.
Signed-off-by: Meirav Kama <meiravk@ti.com>
Signed-off-by: Victor Asovsky <victora@ti.com>
Added vendor specific info element to path req/rep that contains
the previous mesh point from which sender received the frame and
the metric between them.
When action received with this ie, the included info is taken into
account when deciding best path.
Signed-off-by: Meirav Kama <meiravk@ti.com>
Signed-off-by: Victor Asovsky <victora@ti.com>
mesh: TO is always enabled. Only targets responmd to Originator
TO Flag will always be set to '1'.
Prevent MPs in the middle to send PREP to the originator
in case that the originator re-sends PREQ with a newer orig_sn,
but the same target_sn and those MPs have an updated info.
Only a destination will respond to originator's request.
Prevents sequence numbers' rase between an intermediate MPs
Signed-off-by: Victor Asovsky <victora@ti.com>
TO Flag will always be set to '1'.
Prevent MPs in the middle to send PREP to the originator
in case that the originator re-sends PREQ with a newer orig_sn,
but the same target_sn and those MPs have an updated info.
Only a destination will respond to originator's request.
Prevents sequence numbers' rase between an intermediate MPs
Signed-off-by: Victor Asovsky <victora@ti.com>
mesh: PREQs will be forwarded by a Destination MP
Destination MP will also forward PREQs and not block them.
Permits a proper mesh path table update/construction at the
next MP in case that the nexp MP has also an alternative path from
the target's precede MP.
Signed-off-by: Victor Asovsky <victora@ti.com>
Destination MP will also forward PREQs and not block them.
Permits a proper mesh path table update/construction at the
next MP in case that the nexp MP has also an alternative path from
the target's precede MP.
Signed-off-by: Victor Asovsky <victora@ti.com>
mac80211: Unify mesh and mpp path removal function
mpp_path_del() and mesh_path_del() are mostly the same function.
Move common code into a new static function.
Acked-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mpp_path_del() and mesh_path_del() are mostly the same function.
Move common code into a new static function.
Acked-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: let unused MPP table entries timeout
Remember the last time when a mpp table entry is used for
rx or tx and remove them after MESH_PATH_EXPIRE time.
Acked-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remember the last time when a mpp table entry is used for
rx or tx and remove them after MESH_PATH_EXPIRE time.
Acked-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: Remove MPP table entries with MPath
Make the mesh_path_del() function remove all mpp table entries
that are proxied by the removed mesh path.
Acked-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Make the mesh_path_del() function remove all mpp table entries
that are proxied by the removed mesh path.
Acked-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Henning Rogge <henning.rogge@fkie.fraunhofer.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: mesh: drop constant field mean_chain_len
The mean_chain_len field in struct mesh_table is copied whenever a
new mesh table is allocated, but only ever has the value 2 and is
never otherwise updated, so just remove it and use the related
define instead.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The mean_chain_len field in struct mesh_table is copied whenever a
new mesh table is allocated, but only ever has the value 2 and is
never otherwise updated, so just remove it and use the related
define instead.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mac80211: mesh_plink: remove redundant sta_info check
Remove unnecessory "if" statement and club it with previos "if" block.
Signed-off-by: Sunil Shahu <shshahu@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Remove unnecessory "if" statement and club it with previos "if" block.
Signed-off-by: Sunil Shahu <shshahu@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
mesh : proactive path selection improvements
- Added delay of 50ms for PREP transmissions that responds to broadcast PREQ.
this is to reduce the number of replies, and have a single best reply transmitted.
- Send proactive PREQ (broadcast target) twice to improve reliability.
Signed-off-by: Victor Asovsky <victora@ti.com>
- Added delay of 50ms for PREP transmissions that responds to broadcast PREQ.
this is to reduce the number of replies, and have a single best reply transmitted.
- Send proactive PREQ (broadcast target) twice to improve reliability.
Signed-off-by: Victor Asovsky <victora@ti.com>
mesh: update path table only with better PREQ path to next hop
When the TA of the PREQ already appears in the table as the destination,
but the current next hop to it is a different node we should compare
the metric before we replace the next hop for this destination in the table.
If this PREQs' metric is worst, we will ignore it despite the newer sequence number that it conatains.
Check that the "next hop" is not NULL
Mesh path table's entry, including its next hop update will be updated on a regular
basis in case when originator's SN advances by more then one.
Improves cases of fast healing and very congested air at the intermediate MP.
This will prevent a case of momentarily switching to the worst path.
Mesh path table's entry, including its next hop update will be updated on a regular
basis in case when originator's SN advances by more then two.
Improves cases of fast healing and very congested air at the intermediate MP.
Signed-off-by: Victor Asovsky <victora@ti.com>
When the TA of the PREQ already appears in the table as the destination,
but the current next hop to it is a different node we should compare
the metric before we replace the next hop for this destination in the table.
If this PREQs' metric is worst, we will ignore it despite the newer sequence number that it conatains.
Check that the "next hop" is not NULL
Mesh path table's entry, including its next hop update will be updated on a regular
basis in case when originator's SN advances by more then one.
Improves cases of fast healing and very congested air at the intermediate MP.
This will prevent a case of momentarily switching to the worst path.
Mesh path table's entry, including its next hop update will be updated on a regular
basis in case when originator's SN advances by more then two.
Improves cases of fast healing and very congested air at the intermediate MP.
Signed-off-by: Victor Asovsky <victora@ti.com>
mesh : PREQ: increase the PREQ lifetime to imporve performance
All MPs in the mesh, except the initiator MP, after reception of PREQ or PREP,
will update a relevant entry in the mesh path table,
and set the new entry's counter to the lifetime advertised in the PREQ/PREP plus some extra time
This extra time will avoid the intermediate MPs' path expiry prior to the expiry at the path initiator MP;
This extra time will avoid the target MP path expiry,
prior to the expiry at the path initiator MP.
Ttarget MP will not start its own new path selection,
which will lead to an instant path switching, of the "main" data initiator, to a shortest path;
The extra time is set to a twice of "path_refresh_time" that by default is 1 second
The mesh path entry's lifetime will not be increased only if MP is an originator of
the path selection and if the table's entry is equal to the destination address.
For all other entries of the originator's MP the lifetime will be increase, as for
non initiator MPs.
Signed-off-by: Victor Asovsky <victora@ti.com>
All MPs in the mesh, except the initiator MP, after reception of PREQ or PREP,
will update a relevant entry in the mesh path table,
and set the new entry's counter to the lifetime advertised in the PREQ/PREP plus some extra time
This extra time will avoid the intermediate MPs' path expiry prior to the expiry at the path initiator MP;
This extra time will avoid the target MP path expiry,
prior to the expiry at the path initiator MP.
Ttarget MP will not start its own new path selection,
which will lead to an instant path switching, of the "main" data initiator, to a shortest path;
The extra time is set to a twice of "path_refresh_time" that by default is 1 second
The mesh path entry's lifetime will not be increased only if MP is an originator of
the path selection and if the table's entry is equal to the destination address.
For all other entries of the originator's MP the lifetime will be increase, as for
non initiator MPs.
Signed-off-by: Victor Asovsky <victora@ti.com>
mesh: increase PREQ/PRES action frames reliability
Although PRES action frame is sent as unicast, it might not arrive to
it's destination.
To reduce the probability of losing this frame this fix:
- Increase the number of retries for management frames.
- Set 6Mbps rate as basic rate for management frames.
PREQ is sent as broadcast, and might collide in the air.
To reduce the probability of missing that frame, sent it twice.
SN and PDID will not be changed for PREQs of the same transmition, i.e.,
two bcast PREQs a single path selection instance will be identical
The frame will be sent twice only at the originator side,
once the second frame is received in one of the peers, it will be ignore
as the sequence number remains the same.
(This prevents a broadcast storms in the generic case)
mesh: PREQ reliability. 3 transmissions per path selection cycle [SQUASH]
Signed-off-by: Victor Asovsky <victora@ti.com>
Signed-off-by: Yaniv Machani <yanivma@ti.com>
Although PRES action frame is sent as unicast, it might not arrive to
it's destination.
To reduce the probability of losing this frame this fix:
- Increase the number of retries for management frames.
- Set 6Mbps rate as basic rate for management frames.
PREQ is sent as broadcast, and might collide in the air.
To reduce the probability of missing that frame, sent it twice.
SN and PDID will not be changed for PREQs of the same transmition, i.e.,
two bcast PREQs a single path selection instance will be identical
The frame will be sent twice only at the originator side,
once the second frame is received in one of the peers, it will be ignore
as the sequence number remains the same.
(This prevents a broadcast storms in the generic case)
mesh: PREQ reliability. 3 transmissions per path selection cycle [SQUASH]
Signed-off-by: Victor Asovsky <victora@ti.com>
Signed-off-by: Yaniv Machani <yanivma@ti.com>
Mesh: bypass blockack encryption [WORKAROUND]
Currently didn't implement the blockack encryption mechanism
in the meanwhile we bypass in the driver MFP check (robust mgmt frames check)
in order to support blockack session
BYPASSES: WILINK8_SW_DEV-407
Signed-off-by: Chen Loewy <c-loewy@ti.com>
Currently didn't implement the blockack encryption mechanism
in the meanwhile we bypass in the driver MFP check (robust mgmt frames check)
in order to support blockack session
BYPASSES: WILINK8_SW_DEV-407
Signed-off-by: Chen Loewy <c-loewy@ti.com>
mac80211: mesh: fixed HT ies in beacon template
There are several values in HT info elements of mesh beacon (built by the
mac80211) that are incorrect.
To fix them:
1. mac80211 will check configuration from cfg and will build accordingly.
2. changes made in mesh default values.
fixes #WILINK8_SW_DEV-412
Signed-off-by: Meirav Kama <meiravk@ti.com>
There are several values in HT info elements of mesh beacon (built by the
mac80211) that are incorrect.
To fix them:
1. mac80211 will check configuration from cfg and will build accordingly.
2. changes made in mesh default values.
fixes #WILINK8_SW_DEV-412
Signed-off-by: Meirav Kama <meiravk@ti.com>
mac80211: mesh: fix call_rcu() usage
When using call_rcu(), the called function may be delayed quite
significantly, and without a matching rcu_barrier() there's no
way to be sure it has finished.
Therefore, global state that could be gone/freed/reused should
never be touched in the callback.
Fix this in mesh by moving the atomic_dec() into the caller;
that's not really a problem since we already unlinked the path
and it will be destroyed anyway.
This fixes a crash Jouni observed when running certain tests in
a certain order, in which the mesh interface was torn down, the
memory reused for a function pointer (work struct) and running
that then crashed since the pointer had been decremented by 1,
resulting in an invalid instruction byte stream.
Cc: stable@vger.kernel.org
Fixes: eb2b9311fd00 ("mac80211: mesh path table implementation")
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Conflicts:
net/mac80211/mesh_pathtbl.c
When using call_rcu(), the called function may be delayed quite
significantly, and without a matching rcu_barrier() there's no
way to be sure it has finished.
Therefore, global state that could be gone/freed/reused should
never be touched in the callback.
Fix this in mesh by moving the atomic_dec() into the caller;
that's not really a problem since we already unlinked the path
and it will be destroyed anyway.
This fixes a crash Jouni observed when running certain tests in
a certain order, in which the mesh interface was torn down, the
memory reused for a function pointer (work struct) and running
that then crashed since the pointer had been decremented by 1,
resulting in an invalid instruction byte stream.
Cc: stable@vger.kernel.org
Fixes: eb2b9311fd00 ("mac80211: mesh path table implementation")
Reported-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Conflicts:
net/mac80211/mesh_pathtbl.c
mesh: delayed path reply
Add mechanism to delay the sending of the path reply.
Once a decision is made to respond to a PREQ with a PREP,
(meaning SN received is greater than what we had or a better
metric is received), instead of sending the path reply immediately,
we save the PREP information and start a timer (only for the first PREP).
This will allow more PREQ with same SN, but from other paths,
to be processed. Once the timer is expired, the PREP will be sent
through the best path found.
Signed-off-by: Maital Hahn <maitalm@ti.com>
Add mechanism to delay the sending of the path reply.
Once a decision is made to respond to a PREQ with a PREP,
(meaning SN received is greater than what we had or a better
metric is received), instead of sending the path reply immediately,
we save the PREP information and start a timer (only for the first PREP).
This will allow more PREQ with same SN, but from other paths,
to be processed. Once the timer is expired, the PREP will be sent
through the best path found.
Signed-off-by: Maital Hahn <maitalm@ti.com>
mesh: Fix healing time when a mesh peer is disconnecting
Once receiving a CLOSE action frame from the disconnecting peer,
flush all entries in the path table which has this peer as the
next hop.
In addition, upon receiving a packet, if next hop is not found,
trigger PERQ immidiatly, instead of just putting it in the queue.
fixes #WILINK8_SW_DEV-403
Signed-off-by: Maital Hahn <maitalm@ti.com>
Once receiving a CLOSE action frame from the disconnecting peer,
flush all entries in the path table which has this peer as the
next hop.
In addition, upon receiving a packet, if next hop is not found,
trigger PERQ immidiatly, instead of just putting it in the queue.
fixes #WILINK8_SW_DEV-403
Signed-off-by: Maital Hahn <maitalm@ti.com>
mesh: implement mac80211 op: get_rate_info
Driver will now implement the opcode.
This allows the driver to directly send FW reported
rates to mesh_hwmp module and calculate correct metrics.
Still need to add trace to new op.
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
Driver will now implement the opcode.
This allows the driver to directly send FW reported
rates to mesh_hwmp module and calculate correct metrics.
Still need to add trace to new op.
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
mesh: support mesh metric calculation
FW will provide a TX rate per link for each FW status
This will allow mesh_hwmp module to calculate metric
per peer using information gathered from TX packets.
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
FW will provide a TX rate per link for each FW status
This will allow mesh_hwmp module to calculate metric
per peer using information gathered from TX packets.
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
mesh: mac80211 opcode, get rate for metric from driver
Add a new opcode to allow a vendor report a rate directly
from driver, to be used during metric calculation.
A vendor that implements the opcode will have the ability
to report rates directly to the mesh_hwmp module.
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
Add a new opcode to allow a vendor report a rate directly
from driver, to be used during metric calculation.
A vendor that implements the opcode will have the ability
to report rates directly to the mesh_hwmp module.
Signed-off-by: Maxim Altshul <maxim.altshul@ti.com>
ieee80211: mesh: handle secured PREQ frames
Add handling of encrypted broadcast action frames (Group addressed privacy)
Up until now all broadcast action frames and management were not encrypted.
When we send Mesh path selection action frames we need to send a broadcast
action frame which is encrypted.
Change applied to tx.c file adding a case where we handle these specific cases
which are defined in the spec in Table 8-38 Category values (Group addressed privacy)
Code: 13 - Mesh
Code: 14 - Multihop
Signed-off-by: Chen Loewy <c-loewy@ti.com>
Signed-off-by: Maital Hahn <maitalm@ti.com>
Add handling of encrypted broadcast action frames (Group addressed privacy)
Up until now all broadcast action frames and management were not encrypted.
When we send Mesh path selection action frames we need to send a broadcast
action frame which is encrypted.
Change applied to tx.c file adding a case where we handle these specific cases
which are defined in the spec in Table 8-38 Category values (Group addressed privacy)
Code: 13 - Mesh
Code: 14 - Multihop
Signed-off-by: Chen Loewy <c-loewy@ti.com>
Signed-off-by: Maital Hahn <maitalm@ti.com>
wlcore: mesh: Add support for RX Boradcast Key
In order to support authentication of equals peers,
need to save RX Broadcast key per peer (on top of 1 TX broadcast key
and unicast key per peer).
fixes #WILINK8_SW_DEV-68
Signed-off-by: Maital Hahn <maitalm@ti.com>
Acked-by: Guy Mishol <guym@ti.com>
In order to support authentication of equals peers,
need to save RX Broadcast key per peer (on top of 1 TX broadcast key
and unicast key per peer).
fixes #WILINK8_SW_DEV-68
Signed-off-by: Maital Hahn <maitalm@ti.com>
Acked-by: Guy Mishol <guym@ti.com>
mac80211: mesh: flush stations before beacons are stopped
Some drivers (e.g. wl18xx) expect that the last stage in the
de-initialization process will be stopping the beacons, similarly to ap.
Update ieee80211_stop_mesh() flow accordingly.
fixes #WILINK8_SW_DEV-84
Signed-off-by: Maital Hahn <maitalm@ti.com>
Acked-by: Yaniv Machani <yanivma@ti.com>
Some drivers (e.g. wl18xx) expect that the last stage in the
de-initialization process will be stopping the beacons, similarly to ap.
Update ieee80211_stop_mesh() flow accordingly.
fixes #WILINK8_SW_DEV-84
Signed-off-by: Maital Hahn <maitalm@ti.com>
Acked-by: Yaniv Machani <yanivma@ti.com>
wl18xx: firmware minor version update
Driver requires updated firmware in order to enable new feature.
Link to the firmware repository was updated as well.
Signed-off-by: Yaniv Machani <yanivma@ti.com>
Driver requires updated firmware in order to enable new feature.
Link to the firmware repository was updated as well.
Signed-off-by: Yaniv Machani <yanivma@ti.com>
mesh: added initial mesh support for wl8
1. Added support for interface and role of mesh type.
2. Enabled enable/start of mesh-point role,
and opening and closing a connection with a mesh peer.
3. Added multirole combination of mesh and ap
under the same limits of dual ap mode.
4. Add support for 'sta_rc_update' opcode for mesh IF.
The 'sta_rc_update' opcode is being used in mesh_plink.c.
Add support in wlcore to handle this opcode correctly for mesh
(as opposed to current implementation that handles STA only).
fixes #WILINK8_SW_DEV-84
fixes #WILINK8_SW_DEV-76
fixes #WILINK8_SW_DEV-83
fixes #WILINK8_SW_DEV-411
Signed-off-by: Maital Hahn <maitalm@ti.com>
Acked-by: Yaniv Machani <yanivma@ti.com>
1. Added support for interface and role of mesh type.
2. Enabled enable/start of mesh-point role,
and opening and closing a connection with a mesh peer.
3. Added multirole combination of mesh and ap
under the same limits of dual ap mode.
4. Add support for 'sta_rc_update' opcode for mesh IF.
The 'sta_rc_update' opcode is being used in mesh_plink.c.
Add support in wlcore to handle this opcode correctly for mesh
(as opposed to current implementation that handles STA only).
fixes #WILINK8_SW_DEV-84
fixes #WILINK8_SW_DEV-76
fixes #WILINK8_SW_DEV-83
fixes #WILINK8_SW_DEV-411
Signed-off-by: Maital Hahn <maitalm@ti.com>
Acked-by: Yaniv Machani <yanivma@ti.com>
wl18xx/wlcore : time sync demo [TMP]
Driver demo level of the time sync feature
triggering the GPIO using hr timers
DT/HW changes are required.
Signed-off-by: Yaniv Machani <yanivma@ti.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
Driver demo level of the time sync feature
triggering the GPIO using hr timers
DT/HW changes are required.
Signed-off-by: Yaniv Machani <yanivma@ti.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
wlcore: mesh: add zone time sync support
add time sync support for mesh role
Signed-off-by: Guy Mishol <guym@ti.com>
Acked-by: Yaniv Machani <yanivma@ti.com>
add time sync support for mesh role
Signed-off-by: Guy Mishol <guym@ti.com>
Acked-by: Yaniv Machani <yanivma@ti.com>
am335x-evm : add support Wake on Wlan for EVM
Added support for Wake on Wlan on AM335x-EVM
Signed-off-by: Yaniv Machani <yanivma@ti.com>
Added support for Wake on Wlan on AM335x-EVM
Signed-off-by: Yaniv Machani <yanivma@ti.com>
am335x-bone : add support for different wilink8 capes for BBB
added support for new cape types
-wl1825 (fade out)
-e14-wl1837
-su-audio
Signed-off-by: Yaniv Machani <yanivma@ti.com>
added support for new cape types
-wl1825 (fade out)
-e14-wl1837
-su-audio
Signed-off-by: Yaniv Machani <yanivma@ti.com>
Merge branch 'platform-ti-linux-4.4.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-4.4.y
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.4.y
* 'platform-ti-linux-4.4.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
ti_config_fragments: add k2g-only fragment
ARM: dts: dra7: Add ti,secure-ram node to ocmcram1 node
ARM: dts: dra7: Add ocmcram nodes
gpio: omap: fix irq triggering in smart-idle wakeup mode
ARM: dts: AM57xx/DRA7: Update SoC voltage rail limits to match data sheet
Signed-off-by: Dan Murphy <DMurphy@ti.com>
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.4.y
* 'platform-ti-linux-4.4.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
ti_config_fragments: add k2g-only fragment
ARM: dts: dra7: Add ti,secure-ram node to ocmcram1 node
ARM: dts: dra7: Add ocmcram nodes
gpio: omap: fix irq triggering in smart-idle wakeup mode
ARM: dts: AM57xx/DRA7: Update SoC voltage rail limits to match data sheet
Signed-off-by: Dan Murphy <DMurphy@ti.com>
Merge branch 'connectivity-ti-linux-4.4.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-4.4.y
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.4.y
* 'connectivity-ti-linux-4.4.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
tty: serial: 8250: omap: Switch to the new dmaengine_terminate_sync
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-4.4.y
* 'connectivity-ti-linux-4.4.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
tty: serial: 8250: omap: Switch to the new dmaengine_terminate_sync
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
ti_config_fragments: add k2g-only fragment
The K2G SoC is UP and disabling of SMP related options allows to
reduce max rt latency ~20%. This also will improve non-RT cases,
because a lot of code will be romoved from scheduler's hot path.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
[t-kristo@ti.com: dropped unnecessary CONFIG_ARCH_KEYSTONE=y from frag]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
The K2G SoC is UP and disabling of SMP related options allows to
reduce max rt latency ~20%. This also will improve non-RT cases,
because a lot of code will be romoved from scheduler's hot path.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
[t-kristo@ti.com: dropped unnecessary CONFIG_ARCH_KEYSTONE=y from frag]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
tty: serial: 8250: omap: Switch to the new dmaengine_terminate_sync
Using dmaengine_terminate_all() is deprecated per documentation in
include/linux/dmaengine.h
By using the new dmaengine_terminate_sync() we can avoid dma completion
callback after the channel has been terminated.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
[nsekhar@ti.com: rebase to v4.4]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Using dmaengine_terminate_all() is deprecated per documentation in
include/linux/dmaengine.h
By using the new dmaengine_terminate_sync() we can avoid dma completion
callback after the channel has been terminated.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
[nsekhar@ti.com: rebase to v4.4]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ARM: dts: dra7: Add ti,secure-ram node to ocmcram1 node
Secure variants of DRA7xx and AM57xx SoCs may need to reserve a region
of the SRAM for use by secure software. To account for this, add a child
node to the ocmcram1 node that will act as a placeholder at the start
of the SRAM for the reserved region of memory that may be required
by secure services. The node is added with size 0 so that by default
parts will have the full space available but the bootloader or board dts
file is able to resize the node as needed depending on how much reserved
space is needed, if any, so end users of the ocmcram1 region on HS parts
must be aware that a smaller amount of SRAM than expected may be available.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Acked-by: Andreas Dannenberg <dannenberg@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
Secure variants of DRA7xx and AM57xx SoCs may need to reserve a region
of the SRAM for use by secure software. To account for this, add a child
node to the ocmcram1 node that will act as a placeholder at the start
of the SRAM for the reserved region of memory that may be required
by secure services. The node is added with size 0 so that by default
parts will have the full space available but the bootloader or board dts
file is able to resize the node as needed depending on how much reserved
space is needed, if any, so end users of the ocmcram1 region on HS parts
must be aware that a smaller amount of SRAM than expected may be available.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Acked-by: Andreas Dannenberg <dannenberg@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
ARM: dts: dra7: Add ocmcram nodes
Add all ocmcram nodes to dra7.dtsi using the generic mmio-sram driver.
DRA7xx and AM57xx families of SoCs can contain three ocmcram regions of
SRAM, one of 512kb and also an optional two additional of 1Mb each. Mark
the two additional 1MB regions of SRAM as disabled as only ocmcmram1 is
on all variants of the SoCs, then depending on which specific variant
is in use the ocmcram2 and ocmcram3 nodes can be enabled in the board
dts file if the data manual for that part number indicates the ocmcram
region is available.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
Acked-by: Andreas Dannenberg <dannenberg@ti.com>
Add all ocmcram nodes to dra7.dtsi using the generic mmio-sram driver.
DRA7xx and AM57xx families of SoCs can contain three ocmcram regions of
SRAM, one of 512kb and also an optional two additional of 1Mb each. Mark
the two additional 1MB regions of SRAM as disabled as only ocmcmram1 is
on all variants of the SoCs, then depending on which specific variant
is in use the ocmcram2 and ocmcram3 nodes can be enabled in the board
dts file if the data manual for that part number indicates the ocmcram
region is available.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Acked-by: Suman Anna <s-anna@ti.com>
Acked-by: Andreas Dannenberg <dannenberg@ti.com>
gpio: omap: fix irq triggering in smart-idle wakeup mode
Now GPIO IRQ loss is observed on dra7-evm after suspend/resume cycle
in the following case:
extcon_usb1(id_irq) -> pcf8575.gpio1 -> omapgpio6.gpio11 -> gic
the extcon_usb1 is wake up source and it enables IRQ wake up for
id_irq by calling enable/disable_irq_wake() during suspend/resume
which, in turn, causes execution of omap_gpio_wake_enable(). And
omap_gpio_wake_enable() will set/clear corresponding bit in
GPIO_IRQWAKEN_x register.
omapgpio6 configuration after boot - wakeup is enabled for GPIO IRQs
by default from omap_gpio_irq_type:
GPIO_IRQSTATUS_SET_0 | 0x00000400
GPIO_IRQSTATUS_CLR_0 | 0x00000400
GPIO_IRQWAKEN_0 | 0x00000400
GPIO_RISINGDETECT | 0x00000000
GPIO_FALLINGDETECT | 0x00000400
omapgpio6 configuration after after suspend/resume cycle:
GPIO_IRQSTATUS_SET_0 | 0x00000400
GPIO_IRQSTATUS_CLR_0 | 0x00000400
GPIO_IRQWAKEN_0 | 0x00000000 <---
GPIO_RISINGDETECT | 0x00000000
GPIO_FALLINGDETECT | 0x00000400
As result, system will start to lose interrupts from pcf8575 GPIO
expander, because when OMAP GPIO IP is in smart-idle wakeup mode there
are no guarantee that transition(s) on input non wake up GPIO pin will
trigger asynchronous wake-up request to PRCM and then IRQ generation.
IRQ will be generated when GPIO is in active mode - for example, some
time after accessing GPIO bank registers IRQs will be generated
normally, but issue will happen again once PRCM will put GPIO in low
power smart-idle wakeup mode.
Note 1. Issue is not reproduced if debounce clk is enabled for GPIO
bank.
Note 2. Issue hardly reproducible if GPIO pins group contains both
wakeup/non-wakeup gpios - for example, it will be hard to reproduce
issue with pin2 if GPIO_IRQWAKEN_0=0x1 GPIO_IRQSTATUS_SET_0=0x3
GPIO_FALLINGDETECT = 0x3 (TRM "Power Saving by Grouping the Edge/Level
Detection").
Note 3. There nothing common bitween System wake up and OMAP GPIO bank
IP wake up logic - last one defines how the GPIO bank ON-IDLE-ON
transition will happen inside SoC under control of PRCM.
Hence, fix the problem by removing omap_set_gpio_wakeup() function
completely and so keeping always in sync GPIO IRQ mask/unmask
(IRQSTATUS_SET) and wake up enable bits (GPIO_IRQWAKEN); and adding
IRQCHIP_MASK_ON_SUSPEND flag in OMAP GPIO irqchip. That way non wakeup
GPIO IRQs will be properly masked/unmask by IRQ PM core during
suspend/resume cycle.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Tested-by: Roger Quadros <rogerq@ti.com>
Now GPIO IRQ loss is observed on dra7-evm after suspend/resume cycle
in the following case:
extcon_usb1(id_irq) -> pcf8575.gpio1 -> omapgpio6.gpio11 -> gic
the extcon_usb1 is wake up source and it enables IRQ wake up for
id_irq by calling enable/disable_irq_wake() during suspend/resume
which, in turn, causes execution of omap_gpio_wake_enable(). And
omap_gpio_wake_enable() will set/clear corresponding bit in
GPIO_IRQWAKEN_x register.
omapgpio6 configuration after boot - wakeup is enabled for GPIO IRQs
by default from omap_gpio_irq_type:
GPIO_IRQSTATUS_SET_0 | 0x00000400
GPIO_IRQSTATUS_CLR_0 | 0x00000400
GPIO_IRQWAKEN_0 | 0x00000400
GPIO_RISINGDETECT | 0x00000000
GPIO_FALLINGDETECT | 0x00000400
omapgpio6 configuration after after suspend/resume cycle:
GPIO_IRQSTATUS_SET_0 | 0x00000400
GPIO_IRQSTATUS_CLR_0 | 0x00000400
GPIO_IRQWAKEN_0 | 0x00000000 <---
GPIO_RISINGDETECT | 0x00000000
GPIO_FALLINGDETECT | 0x00000400
As result, system will start to lose interrupts from pcf8575 GPIO
expander, because when OMAP GPIO IP is in smart-idle wakeup mode there
are no guarantee that transition(s) on input non wake up GPIO pin will
trigger asynchronous wake-up request to PRCM and then IRQ generation.
IRQ will be generated when GPIO is in active mode - for example, some
time after accessing GPIO bank registers IRQs will be generated
normally, but issue will happen again once PRCM will put GPIO in low
power smart-idle wakeup mode.
Note 1. Issue is not reproduced if debounce clk is enabled for GPIO
bank.
Note 2. Issue hardly reproducible if GPIO pins group contains both
wakeup/non-wakeup gpios - for example, it will be hard to reproduce
issue with pin2 if GPIO_IRQWAKEN_0=0x1 GPIO_IRQSTATUS_SET_0=0x3
GPIO_FALLINGDETECT = 0x3 (TRM "Power Saving by Grouping the Edge/Level
Detection").
Note 3. There nothing common bitween System wake up and OMAP GPIO bank
IP wake up logic - last one defines how the GPIO bank ON-IDLE-ON
transition will happen inside SoC under control of PRCM.
Hence, fix the problem by removing omap_set_gpio_wakeup() function
completely and so keeping always in sync GPIO IRQ mask/unmask
(IRQSTATUS_SET) and wake up enable bits (GPIO_IRQWAKEN); and adding
IRQCHIP_MASK_ON_SUSPEND flag in OMAP GPIO irqchip. That way non wakeup
GPIO IRQs will be properly masked/unmask by IRQ PM core during
suspend/resume cycle.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Tested-by: Roger Quadros <rogerq@ti.com>
ARM: dts: AM57xx/DRA7: Update SoC voltage rail limits to match data sheet
Upstream posted: https://patchwork.kernel.org/patch/8886851/
As per the data sheet starting from SPRUHQ0H (Nov 2015 - Latest[1]),
VDD_CORE can vary from 0.85v to 1.15v for AVS class0. VDD GPU/DSP
et.al. can range from 0.85v to 1.25V with AVS class0
Since dynamic voltage scaling is disabled for DRA7/AM57xx SoCs for
all SoC rails other than MPU, the bootloader is responsible for
setting up the AVS class0 voltage, however, with wrong voltage machine
constraints in dtb, regulator framework will lower the voltage below
the required voltage levels for certain samples in production flow.
This can cause catastrophic failures which can be pretty hard to
identify.
Update board files which don't match required specification.
[1] http://www.ti.com/product/AM5728/datasheet/specifications#SPRT637-7340
Signed-off-by: Nishanth Menon <nm@ti.com>
Upstream posted: https://patchwork.kernel.org/patch/8886851/
As per the data sheet starting from SPRUHQ0H (Nov 2015 - Latest[1]),
VDD_CORE can vary from 0.85v to 1.15v for AVS class0. VDD GPU/DSP
et.al. can range from 0.85v to 1.25V with AVS class0
Since dynamic voltage scaling is disabled for DRA7/AM57xx SoCs for
all SoC rails other than MPU, the bootloader is responsible for
setting up the AVS class0 voltage, however, with wrong voltage machine
constraints in dtb, regulator framework will lower the voltage below
the required voltage levels for certain samples in production flow.
This can cause catastrophic failures which can be pretty hard to
identify.
Update board files which don't match required specification.
[1] http://www.ti.com/product/AM5728/datasheet/specifications#SPRT637-7340
Signed-off-by: Nishanth Menon <nm@ti.com>
Merge branch 'platform-ti-linux-4.4.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-4.4.y
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.4.y
* 'platform-ti-linux-4.4.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
regulator: core: remove lockdep assert from suspend_prepare
ARM: configs: keystone: Add CPU Hotplug related options
keystone: dts: add psci command definition
PM / wakeirq: fix wakeirq setting after wakup re-configuration from sysfs
pinctrl: pinctrl-single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs
ARM: dts: keystone-k2l: Add pinctrl node
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-4.4.y
* 'platform-ti-linux-4.4.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
regulator: core: remove lockdep assert from suspend_prepare
ARM: configs: keystone: Add CPU Hotplug related options
keystone: dts: add psci command definition
PM / wakeirq: fix wakeirq setting after wakup re-configuration from sysfs
pinctrl: pinctrl-single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs
ARM: dts: keystone-k2l: Add pinctrl node
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
regulator: core: remove lockdep assert from suspend_prepare
suspend_prepare can be called during regulator init time also, where
the mutex is not locked yet. This causes a false lockdep warning.
To avoid the problem, remove the lockdep assertion from the function
causing the issue. An alternative would be to lock the mutex during
init, but this would cause other problems (some APIs used during init
will attempt to lock the mutex also, causing deadlock.)
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
suspend_prepare can be called during regulator init time also, where
the mutex is not locked yet. This causes a false lockdep warning.
To avoid the problem, remove the lockdep assertion from the function
causing the issue. An alternative would be to lock the mutex during
init, but this would cause other problems (some APIs used during init
will attempt to lock the mutex also, causing deadlock.)
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Merge tag 'v4.4.8' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-4.4.y
This is the 4.4.8 stable release
* tag 'v4.4.8' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (137 commits)
Linux 4.4.8
Revert "usb: hub: do not clear BOS field during reset device"
usbvision: fix crash on detecting device with invalid configuration
staging: android: ion: Set the length of the DMA sg entries in buffer
Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"
Revert "PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"
Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"
HID: usbhid: fix inconsistent reset/resume/reset-resume behavior
HID: wacom: fix Bamboo ONE oops
ALSA: usb-audio: Skip volume controls triggers hangup on Dell USB Dock
ALSA: usb-audio: Add a quirk for Plantronics BT300
ALSA: usb-audio: Add a sample rate quirk for Phoenix Audio TMX320
ALSA: hda/realtek - Enable the ALC292 dock fixup on the Thinkpad T460s
ALSA: hda - fix front mic problem for a HP desktop
ALSA: hda - Fix headset support and noise on HP EliteBook 755 G2
ALSA: hda - Fixup speaker pass-through control for nid 0x14 on ALC225
mmc: sdhci-pci: Add support and PCI IDs for more Broxton host controllers
perf: Cure event->pending_disable race
perf: Do not double free
arm64: replace read_lock to rcu lock in call_step_hook
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
This is the 4.4.8 stable release
* tag 'v4.4.8' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (137 commits)
Linux 4.4.8
Revert "usb: hub: do not clear BOS field during reset device"
usbvision: fix crash on detecting device with invalid configuration
staging: android: ion: Set the length of the DMA sg entries in buffer
Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"
Revert "PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"
Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"
HID: usbhid: fix inconsistent reset/resume/reset-resume behavior
HID: wacom: fix Bamboo ONE oops
ALSA: usb-audio: Skip volume controls triggers hangup on Dell USB Dock
ALSA: usb-audio: Add a quirk for Plantronics BT300
ALSA: usb-audio: Add a sample rate quirk for Phoenix Audio TMX320
ALSA: hda/realtek - Enable the ALC292 dock fixup on the Thinkpad T460s
ALSA: hda - fix front mic problem for a HP desktop
ALSA: hda - Fix headset support and noise on HP EliteBook 755 G2
ALSA: hda - Fixup speaker pass-through control for nid 0x14 on ALC225
mmc: sdhci-pci: Add support and PCI IDs for more Broxton host controllers
perf: Cure event->pending_disable race
perf: Do not double free
arm64: replace read_lock to rcu lock in call_step_hook
...
Signed-off-by: LCPD Auto Merger <lcpd_integration@list.ti.com>
Linux 4.4.8
Revert "usb: hub: do not clear BOS field during reset device"
commit e5bdfd50d6f76077bf8441d130c606229e100d40 upstream.
This reverts commit d8f00cd685f5c8e0def8593e520a7fef12c22407.
Tony writes:
This upstream commit is causing an oops:
d8f00cd685f5 ("usb: hub: do not clear BOS field during reset device")
This patch has already been included in several -stable kernels. Here
are the affected kernels:
4.5.0-rc4 (current git)
4.4.2
4.3.6 (currently in review)
4.1.18
3.18.27
3.14.61
How to reproduce the problem:
Boot kernel with slub debugging enabled (otherwise memory corruption
will cause random oopses later instead of immediately)
Plug in USB 3.0 disk to xhci USB 3.0 port
dd if=/dev/sdc of=/dev/null bs=65536
(where /dev/sdc is the USB 3.0 disk)
Unplug USB cable while dd is still going
Oops is immediate:
Reported-by: Tony Battersby <tonyb@cybernetics.com>
Cc: Du, Changbin <changbin.du@intel.com>
Cc: Roger Quadros <rogerq@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e5bdfd50d6f76077bf8441d130c606229e100d40 upstream.
This reverts commit d8f00cd685f5c8e0def8593e520a7fef12c22407.
Tony writes:
This upstream commit is causing an oops:
d8f00cd685f5 ("usb: hub: do not clear BOS field during reset device")
This patch has already been included in several -stable kernels. Here
are the affected kernels:
4.5.0-rc4 (current git)
4.4.2
4.3.6 (currently in review)
4.1.18
3.18.27
3.14.61
How to reproduce the problem:
Boot kernel with slub debugging enabled (otherwise memory corruption
will cause random oopses later instead of immediately)
Plug in USB 3.0 disk to xhci USB 3.0 port
dd if=/dev/sdc of=/dev/null bs=65536
(where /dev/sdc is the USB 3.0 disk)
Unplug USB cable while dd is still going
Oops is immediate:
Reported-by: Tony Battersby <tonyb@cybernetics.com>
Cc: Du, Changbin <changbin.du@intel.com>
Cc: Roger Quadros <rogerq@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usbvision: fix crash on detecting device with invalid configuration
commit fa52bd506f274b7619955917abfde355e3d19ffe upstream.
The usbvision driver crashes when a specially crafted usb device with invalid
number of interfaces or endpoints is detected. This fix adds checks that the
device has proper configuration expected by the driver.
Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fa52bd506f274b7619955917abfde355e3d19ffe upstream.
The usbvision driver crashes when a specially crafted usb device with invalid
number of interfaces or endpoints is detected. This fix adds checks that the
device has proper configuration expected by the driver.
Reported-by: Ralf Spenneberg <ralf@spenneberg.net>
Signed-off-by: Vladis Dronov <vdronov@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
staging: android: ion: Set the length of the DMA sg entries in buffer
commit 70bc916b2c80913753fb188d4daee50a64d21ba0 upstream.
ion_buffer_create() will allocate a buffer and then create a DMA
mapping for it, but it forgot to set the length of the page entries.
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Laura Abbott <labbott@redhat.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 70bc916b2c80913753fb188d4daee50a64d21ba0 upstream.
ion_buffer_create() will allocate a buffer and then create a DMA
mapping for it, but it forgot to set the length of the page entries.
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
Acked-by: Laura Abbott <labbott@redhat.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()"
commit 6c777e8799a93e3bdb67bec622429e1b48dc90fb upstream.
991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") appeared in v4.3 and helps support IOAPIC hotplug.
Олег reported that the Elcus-1553 TA1-PCI driver worked in v4.2 but not
v4.3 and bisected it to 991de2e59090. Sunjin reported that the RocketRAID
272x driver worked in v4.2 but not v4.3. In both cases booting with
"pci=routirq" is a workaround.
I think the problem is that after 991de2e59090, we no longer call
pcibios_enable_irq() for upstream bridges. Prior to 991de2e59090, when a
driver called pci_enable_device(), we recursively called
pcibios_enable_irq() for upstream bridges via pci_enable_bridge().
After 991de2e59090, we call pcibios_enable_irq() from pci_device_probe()
instead of the pci_enable_device() path, which does *not* call
pcibios_enable_irq() for upstream bridges.
Revert 991de2e59090 to fix these driver regressions.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()")
Reported-and-tested-by: Олег Мороз <oleg.moroz@mcc.vniiem.ru>
Reported-by: Sunjin Yang <fan4326@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
CC: Jiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6c777e8799a93e3bdb67bec622429e1b48dc90fb upstream.
991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and
pcibios_free_irq()") appeared in v4.3 and helps support IOAPIC hotplug.
Олег reported that the Elcus-1553 TA1-PCI driver worked in v4.2 but not
v4.3 and bisected it to 991de2e59090. Sunjin reported that the RocketRAID
272x driver worked in v4.2 but not v4.3. In both cases booting with
"pci=routirq" is a workaround.
I think the problem is that after 991de2e59090, we no longer call
pcibios_enable_irq() for upstream bridges. Prior to 991de2e59090, when a
driver called pci_enable_device(), we recursively called
pcibios_enable_irq() for upstream bridges via pci_enable_bridge().
After 991de2e59090, we call pcibios_enable_irq() from pci_device_probe()
instead of the pci_enable_device() path, which does *not* call
pcibios_enable_irq() for upstream bridges.
Revert 991de2e59090 to fix these driver regressions.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()")
Reported-and-tested-by: Олег Мороз <oleg.moroz@mcc.vniiem.ru>
Reported-by: Sunjin Yang <fan4326@gmail.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
CC: Jiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "PCI: Add helpers to manage pci_dev->irq and pci_dev->irq_managed"
commit 67b4eab91caf2ad574cab1b17ae09180ea2e116e upstream.
Revert 811a4e6fce09 ("PCI: Add helpers to manage pci_dev->irq and
pci_dev->irq_managed").
This is part of reverting 991de2e59090 ("PCI, x86: Implement
pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it
introduced.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
CC: Jiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 67b4eab91caf2ad574cab1b17ae09180ea2e116e upstream.
Revert 811a4e6fce09 ("PCI: Add helpers to manage pci_dev->irq and
pci_dev->irq_managed").
This is part of reverting 991de2e59090 ("PCI, x86: Implement
pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it
introduced.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
CC: Jiang Liu <jiang.liu@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Revert "x86/PCI: Don't alloc pcibios-irq when MSI is enabled"
commit fe25d078874f2c29c38f4160467d74f5756537c9 upstream.
Revert 8affb487d4a4 ("x86/PCI: Don't alloc pcibios-irq when MSI is
enabled").
This is part of reverting 991de2e59090 ("PCI, x86: Implement
pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it
introduced.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
CC: Jiang Liu <jiang.liu@linux.intel.com>
CC: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fe25d078874f2c29c38f4160467d74f5756537c9 upstream.
Revert 8affb487d4a4 ("x86/PCI: Don't alloc pcibios-irq when MSI is
enabled").
This is part of reverting 991de2e59090 ("PCI, x86: Implement
pcibios_alloc_irq() and pcibios_free_irq()") to fix regressions it
introduced.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=111211
Fixes: 991de2e59090 ("PCI, x86: Implement pcibios_alloc_irq() and pcibios_free_irq()")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
CC: Jiang Liu <jiang.liu@linux.intel.com>
CC: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
HID: usbhid: fix inconsistent reset/resume/reset-resume behavior
commit 972e6a993f278b416a8ee3ec65475724fc36feb2 upstream.
The usbhid driver has inconsistently duplicated code in its post-reset,
resume, and reset-resume pathways.
reset-resume doesn't check HID_STARTED before trying to
restart the I/O queues.
resume fails to clear the HID_SUSPENDED flag if HID_STARTED
isn't set.
resume calls usbhid_restart_queues() with usbhid->lock held
and the others call it without holding the lock.
The first item in particular causes a problem following a reset-resume
if the driver hasn't started up its I/O. URB submission fails because
usbhid->urbin is NULL, and this triggers an unending reset-retry loop.
This patch fixes the problem by creating a new subroutine,
hid_restart_io(), to carry out all the common activities. It also
adds some checks that were missing in the original code:
After a reset, there's no need to clear any halted endpoints.
After a resume, if a reset is pending there's no need to
restart any I/O until the reset is finished.
After a resume, if the interrupt-IN endpoint is halted there's
no need to submit the input URB until the halt has been
cleared.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Daniel Fraga <fragabr@gmail.com>
Tested-by: Daniel Fraga <fragabr@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 972e6a993f278b416a8ee3ec65475724fc36feb2 upstream.
The usbhid driver has inconsistently duplicated code in its post-reset,
resume, and reset-resume pathways.
reset-resume doesn't check HID_STARTED before trying to
restart the I/O queues.
resume fails to clear the HID_SUSPENDED flag if HID_STARTED
isn't set.
resume calls usbhid_restart_queues() with usbhid->lock held
and the others call it without holding the lock.
The first item in particular causes a problem following a reset-resume
if the driver hasn't started up its I/O. URB submission fails because
usbhid->urbin is NULL, and this triggers an unending reset-retry loop.
This patch fixes the problem by creating a new subroutine,
hid_restart_io(), to carry out all the common activities. It also
adds some checks that were missing in the original code:
After a reset, there's no need to clear any halted endpoints.
After a resume, if a reset is pending there's no need to
restart any I/O until the reset is finished.
After a resume, if the interrupt-IN endpoint is halted there's
no need to submit the input URB until the halt has been
cleared.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-by: Daniel Fraga <fragabr@gmail.com>
Tested-by: Daniel Fraga <fragabr@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
HID: wacom: fix Bamboo ONE oops
commit 580549ef6b3e3fb3b958de490ca99f43a089a2cf upstream.
Looks like recent changes in the Wacom driver made the Bamboo ONE crashes.
The tablet behaves as if it was a regular Bamboo device with pen, touch
and pad, but there is no physical pad connected to it.
The weird part is that the pad is still sending events and given that
there is no input node connected to it, we get anull pointer exception.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317116
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 580549ef6b3e3fb3b958de490ca99f43a089a2cf upstream.
Looks like recent changes in the Wacom driver made the Bamboo ONE crashes.
The tablet behaves as if it was a regular Bamboo device with pen, touch
and pad, but there is no physical pad connected to it.
The weird part is that the pad is still sending events and given that
there is no input node connected to it, we get anull pointer exception.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1317116
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Acked-by: Ping Cheng <pingc@wacom.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: usb-audio: Skip volume controls triggers hangup on Dell USB Dock
commit adcdd0d5a1cb779f6d455ae70882c19c527627a8 upstream.
This is Dell usb dock audio workaround.
It was fixed the master volume keep lower.
[Some background: the patch essentially skips the controls of a couple
of FU volumes. Although the firmware exposes the dB and the value
information via the usb descriptor, changing the values (we set the
min volume as default) screws up the device. Although this has been
fixed in the newer firmware, the devices are shipped with the old
firmware, thus we need the workaround in the driver side. -- tiwai]
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit adcdd0d5a1cb779f6d455ae70882c19c527627a8 upstream.
This is Dell usb dock audio workaround.
It was fixed the master volume keep lower.
[Some background: the patch essentially skips the controls of a couple
of FU volumes. Although the firmware exposes the dB and the value
information via the usb descriptor, changing the values (we set the
min volume as default) screws up the device. Although this has been
fixed in the newer firmware, the devices are shipped with the old
firmware, thus we need the workaround in the driver side. -- tiwai]
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: usb-audio: Add a quirk for Plantronics BT300
commit b4203ff5464da00b7812e7b480192745b0d66bbf upstream.
Plantronics BT300 does not support reading the sample rate which leads
to many lines of "cannot get freq at ep 0x1". This patch adds the USB
ID of the BT300 to quirks.c and avoids those error messages.
Signed-off-by: Dennis Kadioglu <denk@post.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b4203ff5464da00b7812e7b480192745b0d66bbf upstream.
Plantronics BT300 does not support reading the sample rate which leads
to many lines of "cannot get freq at ep 0x1". This patch adds the USB
ID of the BT300 to quirks.c and avoids those error messages.
Signed-off-by: Dennis Kadioglu <denk@post.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: usb-audio: Add a sample rate quirk for Phoenix Audio TMX320
commit f03b24a851d32ca85dacab01785b24a7ee717d37 upstream.
Phoenix Audio TMX320 gives the similar error when the sample rate is
asked:
usb 2-1.3: 2:1: cannot get freq at ep 0x85
usb 2-1.3: 1:1: cannot get freq at ep 0x2
....
Add the corresponding USB-device ID (1de7:0014) to
snd_usb_get_sample_rate_quirk() list.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110221
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f03b24a851d32ca85dacab01785b24a7ee717d37 upstream.
Phoenix Audio TMX320 gives the similar error when the sample rate is
asked:
usb 2-1.3: 2:1: cannot get freq at ep 0x85
usb 2-1.3: 1:1: cannot get freq at ep 0x2
....
Add the corresponding USB-device ID (1de7:0014) to
snd_usb_get_sample_rate_quirk() list.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=110221
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda/realtek - Enable the ALC292 dock fixup on the Thinkpad T460s
commit c636b95ec5980345674ad7960a3c67135a84b687 upstream.
The Lenovo Thinkpad T460s requires the alc_fixup_tpt440_dock as well in
order to get working sound output on the docking stations headphone jack.
Patch tested on a Thinkpad T460s (20F9CT01WW) using a ThinkPad Ultradock
on kernel 4.4.6.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c636b95ec5980345674ad7960a3c67135a84b687 upstream.
The Lenovo Thinkpad T460s requires the alc_fixup_tpt440_dock as well in
order to get working sound output on the docking stations headphone jack.
Patch tested on a Thinkpad T460s (20F9CT01WW) using a ThinkPad Ultradock
on kernel 4.4.6.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda - fix front mic problem for a HP desktop
commit e549d190f7b5f94e9ab36bd965028112914d010d upstream.
The front mic jack (pink color) can't detect any plug or unplug. After
applying this fix, both detecting function and recording function
work well.
BugLink: https://bugs.launchpad.net/bugs/1564712
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e549d190f7b5f94e9ab36bd965028112914d010d upstream.
The front mic jack (pink color) can't detect any plug or unplug. After
applying this fix, both detecting function and recording function
work well.
BugLink: https://bugs.launchpad.net/bugs/1564712
Signed-off-by: Hui Wang <hui.wang@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda - Fix headset support and noise on HP EliteBook 755 G2
commit f883982dc1b117f04579f0896821cd9f2e397f94 upstream.
HP EliteBook 755 G2 with ALC3228 (ALC280) codec [103c:221c] requires
the known fixup (ALC269_FIXUP_HEADSET_MIC) for making the headset mic
working. Also, it suffers from the loopback noise problem, so we
should disable aamix path as well.
Reported-by: Derick Eddington <derick.eddington@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f883982dc1b117f04579f0896821cd9f2e397f94 upstream.
HP EliteBook 755 G2 with ALC3228 (ALC280) codec [103c:221c] requires
the known fixup (ALC269_FIXUP_HEADSET_MIC) for making the headset mic
working. Also, it suffers from the loopback noise problem, so we
should disable aamix path as well.
Reported-by: Derick Eddington <derick.eddington@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ALSA: hda - Fixup speaker pass-through control for nid 0x14 on ALC225
commit 2ae955774f29bbd7d16149cb0ae8d0319bf2ecc4 upstream.
On one of the machines we enable, we found that the actual speaker volume
did not always correspond to the volume set in alsamixer. This patch
fixes that problem.
This patch was orginally written by Kailang @ Realtek, I've rebased it
to fit sound git master.
BugLink: https://bugs.launchpad.net/bugs/1549660
Co-Authored-By: Kailang <kailang@realtek.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2ae955774f29bbd7d16149cb0ae8d0319bf2ecc4 upstream.
On one of the machines we enable, we found that the actual speaker volume
did not always correspond to the volume set in alsamixer. This patch
fixes that problem.
This patch was orginally written by Kailang @ Realtek, I've rebased it
to fit sound git master.
BugLink: https://bugs.launchpad.net/bugs/1549660
Co-Authored-By: Kailang <kailang@realtek.com>
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mmc: sdhci-pci: Add support and PCI IDs for more Broxton host controllers
commit 01d6b2a40a0fa73c90e05b1033f181a51fec9292 upstream.
Add support and PCI IDs for more Broxton host controllers
Other BXT IDs were added in v4.4 so cc'ing stable. This patch
is dependent on commit 163cbe31e516 ("mmc: sdhci-pci: Fix card
detect race for Intel BXT/APL") but that is already in stable
since v4.4.4.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 01d6b2a40a0fa73c90e05b1033f181a51fec9292 upstream.
Add support and PCI IDs for more Broxton host controllers
Other BXT IDs were added in v4.4 so cc'ing stable. This patch
is dependent on commit 163cbe31e516 ("mmc: sdhci-pci: Fix card
detect race for Intel BXT/APL") but that is already in stable
since v4.4.4.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
perf: Cure event->pending_disable race
commit 28a967c3a2f99fa3b5f762f25cb2a319d933571b upstream.
Because event_sched_out() checks event->pending_disable _before_
actually disabling the event, it can happen that the event fires after
it checks but before it gets disabled.
This would leave event->pending_disable set and the queued irq_work
will try and process it.
However, if the event trigger was during schedule(), the event might
have been de-scheduled by the time the irq_work runs, and
perf_event_disable_local() will fail.
Fix this by checking event->pending_disable _after_ we call
event->pmu->del(). This depends on the latter being a compiler
barrier, such that the compiler does not lift the load and re-creates
the problem.
Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dvyukov@google.com
Cc: eranian@google.com
Cc: oleg@redhat.com
Cc: panand@redhat.com
Cc: sasha.levin@oracle.com
Cc: vince@deater.net
Link: http://lkml.kernel.org/r/20160224174948.040469884@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 28a967c3a2f99fa3b5f762f25cb2a319d933571b upstream.
Because event_sched_out() checks event->pending_disable _before_
actually disabling the event, it can happen that the event fires after
it checks but before it gets disabled.
This would leave event->pending_disable set and the queued irq_work
will try and process it.
However, if the event trigger was during schedule(), the event might
have been de-scheduled by the time the irq_work runs, and
perf_event_disable_local() will fail.
Fix this by checking event->pending_disable _after_ we call
event->pmu->del(). This depends on the latter being a compiler
barrier, such that the compiler does not lift the load and re-creates
the problem.
Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dvyukov@google.com
Cc: eranian@google.com
Cc: oleg@redhat.com
Cc: panand@redhat.com
Cc: sasha.levin@oracle.com
Cc: vince@deater.net
Link: http://lkml.kernel.org/r/20160224174948.040469884@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
perf: Do not double free
commit 130056275ade730e7a79c110212c8815202773ee upstream.
In case of: err_file: fput(event_file), we'll end up calling
perf_release() which in turn will free the event.
Do not then free the event _again_.
Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dvyukov@google.com
Cc: eranian@google.com
Cc: oleg@redhat.com
Cc: panand@redhat.com
Cc: sasha.levin@oracle.com
Cc: vince@deater.net
Link: http://lkml.kernel.org/r/20160224174947.697350349@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 130056275ade730e7a79c110212c8815202773ee upstream.
In case of: err_file: fput(event_file), we'll end up calling
perf_release() which in turn will free the event.
Do not then free the event _again_.
Tested-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: dvyukov@google.com
Cc: eranian@google.com
Cc: oleg@redhat.com
Cc: panand@redhat.com
Cc: sasha.levin@oracle.com
Cc: vince@deater.net
Link: http://lkml.kernel.org/r/20160224174947.697350349@infradead.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
arm64: replace read_lock to rcu lock in call_step_hook
commit cf0a25436f05753aca5151891aea4fd130556e2a upstream.
BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
in_atomic(): 1, irqs_disabled(): 128, pid: 383, name: sh
Preemption disabled at:[<ffff800000124c18>] kgdb_cpu_enter+0x158/0x6b8
CPU: 3 PID: 383 Comm: sh Tainted: G W 4.1.13-rt13 #2
Hardware name: Freescale Layerscape 2085a RDB Board (DT)
Call trace:
[<ffff8000000885e8>] dump_backtrace+0x0/0x128
[<ffff800000088734>] show_stack+0x24/0x30
[<ffff80000079a7c4>] dump_stack+0x80/0xa0
[<ffff8000000bd324>] ___might_sleep+0x18c/0x1a0
[<ffff8000007a20ac>] __rt_spin_lock+0x2c/0x40
[<ffff8000007a2268>] rt_read_lock+0x40/0x58
[<ffff800000085328>] single_step_handler+0x38/0xd8
[<ffff800000082368>] do_debug_exception+0x58/0xb8
Exception stack(0xffff80834a1e7c80 to 0xffff80834a1e7da0)
7c80: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7e40 ffff8083 001bfcc4 ffff8000
7ca0: f2000400 00000000 00000000 00000000 4a1e7d80 ffff8083 0049501c ffff8000
7cc0: 00005402 00000000 00aaa210 ffff8000 4a1e7ea0 ffff8083 000833f4 ffff8000
7ce0: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7ea0 ffff8083 001bfcc0 ffff8000
7d00: 4a0fc400 ffff8083 00005402 00000000 4a1e7d40 ffff8083 00490324 ffff8000
7d20: ffffff9c 00000000 92c23ba0 0000ffff 000a0000 00000000 00000000 00000000
7d40: 00000008 00000000 00080000 00000000 92c23b8b 0000ffff 92c23b8e 0000ffff
7d60: 00000038 00000000 00001cb2 00000000 00000005 00000000 92d7b498 0000ffff
7d80: 01010101 01010101 92be9000 0000ffff 00000000 00000000 00000030 00000000
[<ffff8000000833f4>] el1_dbg+0x18/0x6c
This issue is similar with 62c6c61("arm64: replace read_lock to rcu lock in
call_break_hook"), but comes to single_step_handler.
This also solves kgdbts boot test silent hang issue on 4.4 -rt kernel.
Signed-off-by: Yang Shi <yang.shi@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cf0a25436f05753aca5151891aea4fd130556e2a upstream.
BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:917
in_atomic(): 1, irqs_disabled(): 128, pid: 383, name: sh
Preemption disabled at:[<ffff800000124c18>] kgdb_cpu_enter+0x158/0x6b8
CPU: 3 PID: 383 Comm: sh Tainted: G W 4.1.13-rt13 #2
Hardware name: Freescale Layerscape 2085a RDB Board (DT)
Call trace:
[<ffff8000000885e8>] dump_backtrace+0x0/0x128
[<ffff800000088734>] show_stack+0x24/0x30
[<ffff80000079a7c4>] dump_stack+0x80/0xa0
[<ffff8000000bd324>] ___might_sleep+0x18c/0x1a0
[<ffff8000007a20ac>] __rt_spin_lock+0x2c/0x40
[<ffff8000007a2268>] rt_read_lock+0x40/0x58
[<ffff800000085328>] single_step_handler+0x38/0xd8
[<ffff800000082368>] do_debug_exception+0x58/0xb8
Exception stack(0xffff80834a1e7c80 to 0xffff80834a1e7da0)
7c80: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7e40 ffff8083 001bfcc4 ffff8000
7ca0: f2000400 00000000 00000000 00000000 4a1e7d80 ffff8083 0049501c ffff8000
7cc0: 00005402 00000000 00aaa210 ffff8000 4a1e7ea0 ffff8083 000833f4 ffff8000
7ce0: ffffff9c ffffffff 92c23ba0 0000ffff 4a1e7ea0 ffff8083 001bfcc0 ffff8000
7d00: 4a0fc400 ffff8083 00005402 00000000 4a1e7d40 ffff8083 00490324 ffff8000
7d20: ffffff9c 00000000 92c23ba0 0000ffff 000a0000 00000000 00000000 00000000
7d40: 00000008 00000000 00080000 00000000 92c23b8b 0000ffff 92c23b8e 0000ffff
7d60: 00000038 00000000 00001cb2 00000000 00000005 00000000 92d7b498 0000ffff
7d80: 01010101 01010101 92be9000 0000ffff 00000000 00000000 00000030 00000000
[<ffff8000000833f4>] el1_dbg+0x18/0x6c
This issue is similar with 62c6c61("arm64: replace read_lock to rcu lock in
call_break_hook"), but comes to single_step_handler.
This also solves kgdbts boot test silent hang issue on 4.4 -rt kernel.
Signed-off-by: Yang Shi <yang.shi@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Btrfs: fix file/data loss caused by fsync after rename and new inode
commit 56f23fdbb600e6087db7b009775b95ce07cc3195 upstream.
If we rename an inode A (be it a file or a directory), create a new
inode B with the old name of inode A and under the same parent directory,
fsync inode B and then power fail, at log tree replay time we end up
removing inode A completely. If inode A is a directory then all its files
are gone too.
Example scenarios where this happens:
This is reproducible with the following steps, taken from a couple of
test cases written for fstests which are going to be submitted upstream
soon:
# Scenario 1
mkfs.btrfs -f /dev/sdc
mount /dev/sdc /mnt
mkdir -p /mnt/a/x
echo "hello" > /mnt/a/x/foo
echo "world" > /mnt/a/x/bar
sync
mv /mnt/a/x /mnt/a/y
mkdir /mnt/a/x
xfs_io -c fsync /mnt/a/x
<power failure happens>
The next time the fs is mounted, log tree replay happens and
the directory "y" does not exist nor do the files "foo" and
"bar" exist anywhere (neither in "y" nor in "x", nor the root
nor anywhere).
# Scenario 2
mkfs.btrfs -f /dev/sdc
mount /dev/sdc /mnt
mkdir /mnt/a
echo "hello" > /mnt/a/foo
sync
mv /mnt/a/foo /mnt/a/bar
echo "world" > /mnt/a/foo
xfs_io -c fsync /mnt/a/foo
<power failure happens>
The next time the fs is mounted, log tree replay happens and the
file "bar" does not exists anymore. A file with the name "foo"
exists and it matches the second file we created.
Another related problem that does not involve file/data loss is when a
new inode is created with the name of a deleted snapshot and we fsync it:
mkfs.btrfs -f /dev/sdc
mount /dev/sdc /mnt
mkdir /mnt/testdir
btrfs subvolume snapshot /mnt /mnt/testdir/snap
btrfs subvolume delete /mnt/testdir/snap
rmdir /mnt/testdir
mkdir /mnt/testdir
xfs_io -c fsync /mnt/testdir # or fsync some file inside /mnt/testdir
<power failure>
The next time the fs is mounted the log replay procedure fails because
it attempts to delete the snapshot entry (which has dir item key type
of BTRFS_ROOT_ITEM_KEY) as if it were a regular (non-root) entry,
resulting in the following error that causes mount to fail:
[52174.510532] BTRFS info (device dm-0): failed to delete reference to snap, inode 257 parent 257
[52174.512570] ------------[ cut here ]------------
[52174.513278] WARNING: CPU: 12 PID: 28024 at fs/btrfs/inode.c:3986 __btrfs_unlink_inode+0x178/0x351 [btrfs]()
[52174.514681] BTRFS: Transaction aborted (error -2)
[52174.515630] Modules linked in: btrfs dm_flakey dm_mod overlay crc32c_generic ppdev xor raid6_pq acpi_cpufreq parport_pc tpm_tis sg parport tpm evdev i2c_piix4 proc
[52174.521568] CPU: 12 PID: 28024 Comm: mount Tainted: G W 4.5.0-rc6-btrfs-next-27+ #1
[52174.522805] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
[52174.524053] 0000000000000000 ffff8801df2a7710 ffffffff81264e93 ffff8801df2a7758
[52174.524053] 0000000000000009 ffff8801df2a7748 ffffffff81051618 ffffffffa03591cd
[52174.524053] 00000000fffffffe ffff88015e6e5000 ffff88016dbc3c88 ffff88016dbc3c88
[52174.524053] Call Trace:
[52174.524053] [<ffffffff81264e93>] dump_stack+0x67/0x90
[52174.524053] [<ffffffff81051618>] warn_slowpath_common+0x99/0xb2
[52174.524053] [<ffffffffa03591cd>] ? __btrfs_unlink_inode+0x178/0x351 [btrfs]
[52174.524053] [<ffffffff81051679>] warn_slowpath_fmt+0x48/0x50
[52174.524053] [<ffffffffa03591cd>] __btrfs_unlink_inode+0x178/0x351 [btrfs]
[52174.524053] [<ffffffff8118f5e9>] ? iput+0xb0/0x284
[52174.524053] [<ffffffffa0359fe8>] btrfs_unlink_inode+0x1c/0x3d [btrfs]
[52174.524053] [<ffffffffa038631e>] check_item_in_log+0x1fe/0x29b [btrfs]
[52174.524053] [<ffffffffa0386522>] replay_dir_deletes+0x167/0x1cf [btrfs]
[52174.524053] [<ffffffffa038739e>] fixup_inode_link_count+0x289/0x2aa [btrfs]
[52174.524053] [<ffffffffa038748a>] fixup_inode_link_counts+0xcb/0x105 [btrfs]
[52174.524053] [<ffffffffa038a5ec>] btrfs_recover_log_trees+0x258/0x32c [btrfs]
[52174.524053] [<ffffffffa03885b2>] ? replay_one_extent+0x511/0x511 [btrfs]
[52174.524053] [<ffffffffa034f288>] open_ctree+0x1dd4/0x21b9 [btrfs]
[52174.524053] [<ffffffffa032b753>] btrfs_mount+0x97e/0xaed [btrfs]
[52174.524053] [<ffffffff8108e1b7>] ? trace_hardirqs_on+0xd/0xf
[52174.524053] [<ffffffff8117bafa>] mount_fs+0x67/0x131
[52174.524053] [<ffffffff81193003>] vfs_kern_mount+0x6c/0xde
[52174.524053] [<ffffffffa032af81>] btrfs_mount+0x1ac/0xaed [btrfs]
[52174.524053] [<ffffffff8108e1b7>] ? trace_hardirqs_on+0xd/0xf
[52174.524053] [<ffffffff8108c262>] ? lockdep_init_map+0xb9/0x1b3
[52174.524053] [<ffffffff8117bafa>] mount_fs+0x67/0x131
[52174.524053] [<ffffffff81193003>] vfs_kern_mount+0x6c/0xde
[52174.524053] [<ffffffff8119590f>] do_mount+0x8a6/0x9e8
[52174.524053] [<ffffffff811358dd>] ? strndup_user+0x3f/0x59
[52174.524053] [<ffffffff81195c65>] SyS_mount+0x77/0x9f
[52174.524053] [<ffffffff814935d7>] entry_SYSCALL_64_fastpath+0x12/0x6b
[52174.561288] ---[ end trace 6b53049efb1a3ea6 ]---
Fix this by forcing a transaction commit when such cases happen.
This means we check in the commit root of the subvolume tree if there
was any other inode with the same reference when the inode we are
fsync'ing is a new inode (created in the current transaction).
Test cases for fstests, covering all the scenarios given above, were
submitted upstream for fstests:
* fstests: generic test for fsync after renaming directory
https://patchwork.kernel.org/patch/8694281/
* fstests: generic test for fsync after renaming file
https://patchwork.kernel.org/patch/8694301/
* fstests: add btrfs test for fsync after snapshot deletion
https://patchwork.kernel.org/patch/8670671/
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 56f23fdbb600e6087db7b009775b95ce07cc3195 upstream.
If we rename an inode A (be it a file or a directory), create a new
inode B with the old name of inode A and under the same parent directory,
fsync inode B and then power fail, at log tree replay time we end up
removing inode A completely. If inode A is a directory then all its files
are gone too.
Example scenarios where this happens:
This is reproducible with the following steps, taken from a couple of
test cases written for fstests which are going to be submitted upstream
soon:
# Scenario 1
mkfs.btrfs -f /dev/sdc
mount /dev/sdc /mnt
mkdir -p /mnt/a/x
echo "hello" > /mnt/a/x/foo
echo "world" > /mnt/a/x/bar
sync
mv /mnt/a/x /mnt/a/y
mkdir /mnt/a/x
xfs_io -c fsync /mnt/a/x
<power failure happens>
The next time the fs is mounted, log tree replay happens and
the directory "y" does not exist nor do the files "foo" and
"bar" exist anywhere (neither in "y" nor in "x", nor the root
nor anywhere).
# Scenario 2
mkfs.btrfs -f /dev/sdc
mount /dev/sdc /mnt
mkdir /mnt/a
echo "hello" > /mnt/a/foo
sync
mv /mnt/a/foo /mnt/a/bar
echo "world" > /mnt/a/foo
xfs_io -c fsync /mnt/a/foo
<power failure happens>
The next time the fs is mounted, log tree replay happens and the
file "bar" does not exists anymore. A file with the name "foo"
exists and it matches the second file we created.
Another related problem that does not involve file/data loss is when a
new inode is created with the name of a deleted snapshot and we fsync it:
mkfs.btrfs -f /dev/sdc
mount /dev/sdc /mnt
mkdir /mnt/testdir
btrfs subvolume snapshot /mnt /mnt/testdir/snap
btrfs subvolume delete /mnt/testdir/snap
rmdir /mnt/testdir
mkdir /mnt/testdir
xfs_io -c fsync /mnt/testdir # or fsync some file inside /mnt/testdir
<power failure>
The next time the fs is mounted the log replay procedure fails because
it attempts to delete the snapshot entry (which has dir item key type
of BTRFS_ROOT_ITEM_KEY) as if it were a regular (non-root) entry,
resulting in the following error that causes mount to fail:
[52174.510532] BTRFS info (device dm-0): failed to delete reference to snap, inode 257 parent 257
[52174.512570] ------------[ cut here ]------------
[52174.513278] WARNING: CPU: 12 PID: 28024 at fs/btrfs/inode.c:3986 __btrfs_unlink_inode+0x178/0x351 [btrfs]()
[52174.514681] BTRFS: Transaction aborted (error -2)
[52174.515630] Modules linked in: btrfs dm_flakey dm_mod overlay crc32c_generic ppdev xor raid6_pq acpi_cpufreq parport_pc tpm_tis sg parport tpm evdev i2c_piix4 proc
[52174.521568] CPU: 12 PID: 28024 Comm: mount Tainted: G W 4.5.0-rc6-btrfs-next-27+ #1
[52174.522805] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
[52174.524053] 0000000000000000 ffff8801df2a7710 ffffffff81264e93 ffff8801df2a7758
[52174.524053] 0000000000000009 ffff8801df2a7748 ffffffff81051618 ffffffffa03591cd
[52174.524053] 00000000fffffffe ffff88015e6e5000 ffff88016dbc3c88 ffff88016dbc3c88
[52174.524053] Call Trace:
[52174.524053] [<ffffffff81264e93>] dump_stack+0x67/0x90
[52174.524053] [<ffffffff81051618>] warn_slowpath_common+0x99/0xb2
[52174.524053] [<ffffffffa03591cd>] ? __btrfs_unlink_inode+0x178/0x351 [btrfs]
[52174.524053] [<ffffffff81051679>] warn_slowpath_fmt+0x48/0x50
[52174.524053] [<ffffffffa03591cd>] __btrfs_unlink_inode+0x178/0x351 [btrfs]
[52174.524053] [<ffffffff8118f5e9>] ? iput+0xb0/0x284
[52174.524053] [<ffffffffa0359fe8>] btrfs_unlink_inode+0x1c/0x3d [btrfs]
[52174.524053] [<ffffffffa038631e>] check_item_in_log+0x1fe/0x29b [btrfs]
[52174.524053] [<ffffffffa0386522>] replay_dir_deletes+0x167/0x1cf [btrfs]
[52174.524053] [<ffffffffa038739e>] fixup_inode_link_count+0x289/0x2aa [btrfs]
[52174.524053] [<ffffffffa038748a>] fixup_inode_link_counts+0xcb/0x105 [btrfs]
[52174.524053] [<ffffffffa038a5ec>] btrfs_recover_log_trees+0x258/0x32c [btrfs]
[52174.524053] [<ffffffffa03885b2>] ? replay_one_extent+0x511/0x511 [btrfs]
[52174.524053] [<ffffffffa034f288>] open_ctree+0x1dd4/0x21b9 [btrfs]
[52174.524053] [<ffffffffa032b753>] btrfs_mount+0x97e/0xaed [btrfs]
[52174.524053] [<ffffffff8108e1b7>] ? trace_hardirqs_on+0xd/0xf
[52174.524053] [<ffffffff8117bafa>] mount_fs+0x67/0x131
[52174.524053] [<ffffffff81193003>] vfs_kern_mount+0x6c/0xde
[52174.524053] [<ffffffffa032af81>] btrfs_mount+0x1ac/0xaed [btrfs]
[52174.524053] [<ffffffff8108e1b7>] ? trace_hardirqs_on+0xd/0xf
[52174.524053] [<ffffffff8108c262>] ? lockdep_init_map+0xb9/0x1b3
[52174.524053] [<ffffffff8117bafa>] mount_fs+0x67/0x131
[52174.524053] [<ffffffff81193003>] vfs_kern_mount+0x6c/0xde
[52174.524053] [<ffffffff8119590f>] do_mount+0x8a6/0x9e8
[52174.524053] [<ffffffff811358dd>] ? strndup_user+0x3f/0x59
[52174.524053] [<ffffffff81195c65>] SyS_mount+0x77/0x9f
[52174.524053] [<ffffffff814935d7>] entry_SYSCALL_64_fastpath+0x12/0x6b
[52174.561288] ---[ end trace 6b53049efb1a3ea6 ]---
Fix this by forcing a transaction commit when such cases happen.
This means we check in the commit root of the subvolume tree if there
was any other inode with the same reference when the inode we are
fsync'ing is a new inode (created in the current transaction).
Test cases for fstests, covering all the scenarios given above, were
submitted upstream for fstests:
* fstests: generic test for fsync after renaming directory
https://patchwork.kernel.org/patch/8694281/
* fstests: generic test for fsync after renaming file
https://patchwork.kernel.org/patch/8694301/
* fstests: add btrfs test for fsync after snapshot deletion
https://patchwork.kernel.org/patch/8670671/
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iommu: Don't overwrite domain pointer when there is no default_domain
commit eebb8034a5be8c2177cbf07ca2ecd2ff8a058958 upstream.
IOMMU drivers that do not support default domains, but make
use of the the group->domain pointer can get that pointer
overwritten with NULL on device add/remove.
Make sure this can't happen by only overwriting the domain
pointer when it is NULL.
Fixes: 1228236de5f9 ('iommu: Move default domain allocation to iommu_group_get_for_dev()')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit eebb8034a5be8c2177cbf07ca2ecd2ff8a058958 upstream.
IOMMU drivers that do not support default domains, but make
use of the the group->domain pointer can get that pointer
overwritten with NULL on device add/remove.
Make sure this can't happen by only overwriting the domain
pointer when it is NULL.
Fixes: 1228236de5f9 ('iommu: Move default domain allocation to iommu_group_get_for_dev()')
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ext4: ignore quota mount options if the quota feature is enabled
commit c325a67c72903e1cc30e990a15ce745bda0dbfde upstream.
Previously, ext4 would fail the mount if the file system had the quota
feature enabled and quota mount options (used for the older quota
setups) were present. This broke xfstests, since xfs silently ignores
the usrquote and grpquota mount options if they are specified. This
commit changes things so that we are consistent with xfs; having the
mount options specified is harmless, so no sense break users by
forbidding them.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c325a67c72903e1cc30e990a15ce745bda0dbfde upstream.
Previously, ext4 would fail the mount if the file system had the quota
feature enabled and quota mount options (used for the older quota
setups) were present. This broke xfstests, since xfs silently ignores
the usrquote and grpquota mount options if they are specified. This
commit changes things so that we are consistent with xfs; having the
mount options specified is harmless, so no sense break users by
forbidding them.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ext4: add lockdep annotations for i_data_sem
commit daf647d2dd58cec59570d7698a45b98e580f2076 upstream.
With the internal Quota feature, mke2fs creates empty quota inodes and
quota usage tracking is enabled as soon as the file system is mounted.
Since quotacheck is no longer preallocating all of the blocks in the
quota inode that are likely needed to be written to, we are now seeing
a lockdep false positive caused by needing to allocate a quota block
from inside ext4_map_blocks(), while holding i_data_sem for a data
inode. This results in this complaint:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ei->i_data_sem);
lock(&s->s_dquot.dqio_mutex);
lock(&ei->i_data_sem);
lock(&s->s_dquot.dqio_mutex);
Google-Bug-Id: 27907753
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit daf647d2dd58cec59570d7698a45b98e580f2076 upstream.
With the internal Quota feature, mke2fs creates empty quota inodes and
quota usage tracking is enabled as soon as the file system is mounted.
Since quotacheck is no longer preallocating all of the blocks in the
quota inode that are likely needed to be written to, we are now seeing
a lockdep false positive caused by needing to allocate a quota block
from inside ext4_map_blocks(), while holding i_data_sem for a data
inode. This results in this complaint:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ei->i_data_sem);
lock(&s->s_dquot.dqio_mutex);
lock(&ei->i_data_sem);
lock(&s->s_dquot.dqio_mutex);
Google-Bug-Id: 27907753
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
btrfs: fix crash/invalid memory access on fsync when using overlayfs
commit de17e793b104d690e1d007dfc5cb6b4f649598ca upstream.
If the lower or upper directory of an overlayfs mount belong to a btrfs
file system and we fsync the file through the overlayfs' merged directory
we ended up accessing an inode that didn't belong to btrfs as if it were
a btrfs inode at btrfs_sync_file() resulting in a crash like the following:
[ 7782.588845] BUG: unable to handle kernel NULL pointer dereference at 0000000000000544
[ 7782.590624] IP: [<ffffffffa030b7ab>] btrfs_sync_file+0x11b/0x3e9 [btrfs]
[ 7782.591931] PGD 4d954067 PUD 1e878067 PMD 0
[ 7782.592016] Oops: 0002 [#6] PREEMPT SMP DEBUG_PAGEALLOC
[ 7782.592016] Modules linked in: btrfs overlay ppdev crc32c_generic evdev xor raid6_pq psmouse pcspkr sg serio_raw acpi_cpufreq parport_pc parport tpm_tis i2c_piix4 tpm i2c_core processor button loop autofs4 ext4 crc16 mbcache jbd2 sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix virtio_pci libata virtio_ring virtio scsi_mod e1000 floppy [last unloaded: btrfs]
[ 7782.592016] CPU: 10 PID: 16437 Comm: xfs_io Tainted: G D 4.5.0-rc6-btrfs-next-26+ #1
[ 7782.592016] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
[ 7782.592016] task: ffff88001b8d40c0 ti: ffff880137488000 task.ti: ffff880137488000
[ 7782.592016] RIP: 0010:[<ffffffffa030b7ab>] [<ffffffffa030b7ab>] btrfs_sync_file+0x11b/0x3e9 [btrfs]
[ 7782.592016] RSP: 0018:ffff88013748be40 EFLAGS: 00010286
[ 7782.592016] RAX: 0000000080000000 RBX: ffff880133b30c88 RCX: 0000000000000001
[ 7782.592016] RDX: 0000000000000001 RSI: ffffffff8148fec0 RDI: 00000000ffffffff
[ 7782.592016] RBP: ffff88013748bec0 R08: 0000000000000001 R09: 0000000000000000
[ 7782.624248] R10: ffff88013748be40 R11: 0000000000000246 R12: 0000000000000000
[ 7782.624248] R13: 0000000000000000 R14: 00000000009305a0 R15: ffff880015e3be40
[ 7782.624248] FS: 00007fa83b9cb700(0000) GS:ffff88023ed40000(0000) knlGS:0000000000000000
[ 7782.624248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7782.624248] CR2: 0000000000000544 CR3: 00000001fa652000 CR4: 00000000000006e0
[ 7782.624248] Stack:
[ 7782.624248] ffffffff8108b5cc ffff88013748bec0 0000000000000246 ffff8800b005ded0
[ 7782.624248] ffff880133b30d60 8000000000000000 7fffffffffffffff 0000000000000246
[ 7782.624248] 0000000000000246 ffffffff81074f9b ffffffff8104357c ffff880015e3be40
[ 7782.624248] Call Trace:
[ 7782.624248] [<ffffffff8108b5cc>] ? arch_local_irq_save+0x9/0xc
[ 7782.624248] [<ffffffff81074f9b>] ? ___might_sleep+0xce/0x217
[ 7782.624248] [<ffffffff8104357c>] ? __do_page_fault+0x3c0/0x43a
[ 7782.624248] [<ffffffff811a2351>] vfs_fsync_range+0x8c/0x9e
[ 7782.624248] [<ffffffff811a237f>] vfs_fsync+0x1c/0x1e
[ 7782.624248] [<ffffffff811a24d6>] do_fsync+0x31/0x4a
[ 7782.624248] [<ffffffff811a2700>] SyS_fsync+0x10/0x14
[ 7782.624248] [<ffffffff81493617>] entry_SYSCALL_64_fastpath+0x12/0x6b
[ 7782.624248] Code: 85 c0 0f 85 e2 02 00 00 48 8b 45 b0 31 f6 4c 29 e8 48 ff c0 48 89 45 a8 48 8d 83 d8 00 00 00 48 89 c7 48 89 45 a0 e8 fc 43 18 e1 <f0> 41 ff 84 24 44 05 00 00 48 8b 83 58 ff ff ff 48 c1 e8 07 83
[ 7782.624248] RIP [<ffffffffa030b7ab>] btrfs_sync_file+0x11b/0x3e9 [btrfs]
[ 7782.624248] RSP <ffff88013748be40>
[ 7782.624248] CR2: 0000000000000544
[ 7782.661994] ---[ end trace 721e14960eb939bc ]---
This started happening since commit 4bacc9c9234 (overlayfs: Make f_path
always point to the overlay and f_inode to the underlay) and even though
after this change we could still access the btrfs inode through
struct file->f_mapping->host or struct file->f_inode, we would end up
resulting in more similar issues later on at check_parent_dirs_for_sync()
because the dentry we got (from struct file->f_path.dentry) was from
overlayfs and not from btrfs, that is, we had no way of getting the dentry
that belonged to btrfs (we always got the dentry that belonged to
overlayfs).
The new patch from Miklos Szeredi, titled "vfs: add file_dentry()" and
recently submitted to linux-fsdevel, adds a file_dentry() API that allows
us to get the btrfs dentry from the input file and therefore being able
to fsync when the upper and lower directories belong to btrfs filesystems.
This issue has been reported several times by users in the mailing list
and bugzilla. A test case for xfstests is being submitted as well.
Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101951
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109791
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit de17e793b104d690e1d007dfc5cb6b4f649598ca upstream.
If the lower or upper directory of an overlayfs mount belong to a btrfs
file system and we fsync the file through the overlayfs' merged directory
we ended up accessing an inode that didn't belong to btrfs as if it were
a btrfs inode at btrfs_sync_file() resulting in a crash like the following:
[ 7782.588845] BUG: unable to handle kernel NULL pointer dereference at 0000000000000544
[ 7782.590624] IP: [<ffffffffa030b7ab>] btrfs_sync_file+0x11b/0x3e9 [btrfs]
[ 7782.591931] PGD 4d954067 PUD 1e878067 PMD 0
[ 7782.592016] Oops: 0002 [#6] PREEMPT SMP DEBUG_PAGEALLOC
[ 7782.592016] Modules linked in: btrfs overlay ppdev crc32c_generic evdev xor raid6_pq psmouse pcspkr sg serio_raw acpi_cpufreq parport_pc parport tpm_tis i2c_piix4 tpm i2c_core processor button loop autofs4 ext4 crc16 mbcache jbd2 sr_mod cdrom sd_mod ata_generic virtio_scsi ata_piix virtio_pci libata virtio_ring virtio scsi_mod e1000 floppy [last unloaded: btrfs]
[ 7782.592016] CPU: 10 PID: 16437 Comm: xfs_io Tainted: G D 4.5.0-rc6-btrfs-next-26+ #1
[ 7782.592016] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS by qemu-project.org 04/01/2014
[ 7782.592016] task: ffff88001b8d40c0 ti: ffff880137488000 task.ti: ffff880137488000
[ 7782.592016] RIP: 0010:[<ffffffffa030b7ab>] [<ffffffffa030b7ab>] btrfs_sync_file+0x11b/0x3e9 [btrfs]
[ 7782.592016] RSP: 0018:ffff88013748be40 EFLAGS: 00010286
[ 7782.592016] RAX: 0000000080000000 RBX: ffff880133b30c88 RCX: 0000000000000001
[ 7782.592016] RDX: 0000000000000001 RSI: ffffffff8148fec0 RDI: 00000000ffffffff
[ 7782.592016] RBP: ffff88013748bec0 R08: 0000000000000001 R09: 0000000000000000
[ 7782.624248] R10: ffff88013748be40 R11: 0000000000000246 R12: 0000000000000000
[ 7782.624248] R13: 0000000000000000 R14: 00000000009305a0 R15: ffff880015e3be40
[ 7782.624248] FS: 00007fa83b9cb700(0000) GS:ffff88023ed40000(0000) knlGS:0000000000000000
[ 7782.624248] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7782.624248] CR2: 0000000000000544 CR3: 00000001fa652000 CR4: 00000000000006e0
[ 7782.624248] Stack:
[ 7782.624248] ffffffff8108b5cc ffff88013748bec0 0000000000000246 ffff8800b005ded0
[ 7782.624248] ffff880133b30d60 8000000000000000 7fffffffffffffff 0000000000000246
[ 7782.624248] 0000000000000246 ffffffff81074f9b ffffffff8104357c ffff880015e3be40
[ 7782.624248] Call Trace:
[ 7782.624248] [<ffffffff8108b5cc>] ? arch_local_irq_save+0x9/0xc
[ 7782.624248] [<ffffffff81074f9b>] ? ___might_sleep+0xce/0x217
[ 7782.624248] [<ffffffff8104357c>] ? __do_page_fault+0x3c0/0x43a
[ 7782.624248] [<ffffffff811a2351>] vfs_fsync_range+0x8c/0x9e
[ 7782.624248] [<ffffffff811a237f>] vfs_fsync+0x1c/0x1e
[ 7782.624248] [<ffffffff811a24d6>] do_fsync+0x31/0x4a
[ 7782.624248] [<ffffffff811a2700>] SyS_fsync+0x10/0x14
[ 7782.624248] [<ffffffff81493617>] entry_SYSCALL_64_fastpath+0x12/0x6b
[ 7782.624248] Code: 85 c0 0f 85 e2 02 00 00 48 8b 45 b0 31 f6 4c 29 e8 48 ff c0 48 89 45 a8 48 8d 83 d8 00 00 00 48 89 c7 48 89 45 a0 e8 fc 43 18 e1 <f0> 41 ff 84 24 44 05 00 00 48 8b 83 58 ff ff ff 48 c1 e8 07 83
[ 7782.624248] RIP [<ffffffffa030b7ab>] btrfs_sync_file+0x11b/0x3e9 [btrfs]
[ 7782.624248] RSP <ffff88013748be40>
[ 7782.624248] CR2: 0000000000000544
[ 7782.661994] ---[ end trace 721e14960eb939bc ]---
This started happening since commit 4bacc9c9234 (overlayfs: Make f_path
always point to the overlay and f_inode to the underlay) and even though
after this change we could still access the btrfs inode through
struct file->f_mapping->host or struct file->f_inode, we would end up
resulting in more similar issues later on at check_parent_dirs_for_sync()
because the dentry we got (from struct file->f_path.dentry) was from
overlayfs and not from btrfs, that is, we had no way of getting the dentry
that belonged to btrfs (we always got the dentry that belonged to
overlayfs).
The new patch from Miklos Szeredi, titled "vfs: add file_dentry()" and
recently submitted to linux-fsdevel, adds a file_dentry() API that allows
us to get the btrfs dentry from the input file and therefore being able
to fsync when the upper and lower directories belong to btrfs filesystems.
This issue has been reported several times by users in the mailing list
and bugzilla. A test case for xfstests is being submitted as well.
Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101951
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=109791
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
nfs: use file_dentry()
commit be62a1a8fd116f5cd9e53726601f970e16e17558 upstream.
NFS may be used as lower layer of overlayfs and accessing f_path.dentry can
lead to a crash.
Fix by replacing direct access of file->f_path.dentry with the
file_dentry() accessor, which will always return a native object.
Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Tested-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Acked-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: David Howells <dhowells@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit be62a1a8fd116f5cd9e53726601f970e16e17558 upstream.
NFS may be used as lower layer of overlayfs and accessing f_path.dentry can
lead to a crash.
Fix by replacing direct access of file->f_path.dentry with the
file_dentry() accessor, which will always return a native object.
Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Tested-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Acked-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: David Howells <dhowells@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs: add file_dentry()
commit d101a125954eae1d397adda94ca6319485a50493 upstream.
This series fixes bugs in nfs and ext4 due to 4bacc9c9234c ("overlayfs:
Make f_path always point to the overlay and f_inode to the underlay").
Regular files opened on overlayfs will result in the file being opened on
the underlying filesystem, while f_path points to the overlayfs
mount/dentry.
This confuses filesystems which get the dentry from struct file and assume
it's theirs.
Add a new helper, file_dentry() [*], to get the filesystem's own dentry
from the file. This checks file->f_path.dentry->d_flags against
DCACHE_OP_REAL, and returns file->f_path.dentry if DCACHE_OP_REAL is not
set (this is the common, non-overlayfs case).
In the uncommon case it will call into overlayfs's ->d_real() to get the
underlying dentry, matching file_inode(file).
The reason we need to check against the inode is that if the file is copied
up while being open, d_real() would return the upper dentry, while the open
file comes from the lower dentry.
[*] If possible, it's better simply to use file_inode() instead.
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Tested-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Reviewed-by: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Daniel Axtens <dja@axtens.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d101a125954eae1d397adda94ca6319485a50493 upstream.
This series fixes bugs in nfs and ext4 due to 4bacc9c9234c ("overlayfs:
Make f_path always point to the overlay and f_inode to the underlay").
Regular files opened on overlayfs will result in the file being opened on
the underlying filesystem, while f_path points to the overlayfs
mount/dentry.
This confuses filesystems which get the dentry from struct file and assume
it's theirs.
Add a new helper, file_dentry() [*], to get the filesystem's own dentry
from the file. This checks file->f_path.dentry->d_flags against
DCACHE_OP_REAL, and returns file->f_path.dentry if DCACHE_OP_REAL is not
set (this is the common, non-overlayfs case).
In the uncommon case it will call into overlayfs's ->d_real() to get the
underlying dentry, matching file_inode(file).
The reason we need to check against the inode is that if the file is copied
up while being open, d_real() would return the upper dentry, while the open
file comes from the lower dentry.
[*] If possible, it's better simply to use file_inode() instead.
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Tested-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
Reviewed-by: Trond Myklebust <trond.myklebust@primarydata.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Daniel Axtens <dja@axtens.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
sd: Fix excessive capacity printing on devices with blocks bigger than 512 bytes
commit f08bb1e0dbdd0297258d0b8cd4dbfcc057e57b2a upstream.
During revalidate we check whether device capacity has changed before we
decide whether to output disk information or not.
The check for old capacity failed to take into account that we scaled
sdkp->capacity based on the reported logical block size. And therefore
the capacity test would always fail for devices with sectors bigger than
512 bytes and we would print several copies of the same discovery
information.
Avoid scaling sdkp->capacity and instead adjust the value on the fly
when setting the block device capacity and generating fake C/H/S
geometry.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reported-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Hannes Reinicke <hare@suse.de>
Reviewed-by: Ewan Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f08bb1e0dbdd0297258d0b8cd4dbfcc057e57b2a upstream.
During revalidate we check whether device capacity has changed before we
decide whether to output disk information or not.
The check for old capacity failed to take into account that we scaled
sdkp->capacity based on the reported logical block size. And therefore
the capacity test would always fail for devices with sectors bigger than
512 bytes and we would print several copies of the same discovery
information.
Avoid scaling sdkp->capacity and instead adjust the value on the fly
when setting the block device capacity and generating fake C/H/S
geometry.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reported-by: Hannes Reinecke <hare@suse.de>
Reviewed-by: Hannes Reinicke <hare@suse.de>
Reviewed-by: Ewan Milne <emilne@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iio: gyro: bmg160: fix endianness when reading axes
commit 95e7ff034175db7d8aefabe7716c4d42bea24fde upstream.
For big endian platforms, reading the axes will return
invalid values.
The device stores each axis value in a 16 bit little
endian register. The driver uses regmap_read_bulk to get
the axis value, resulting in a 16 bit little endian value.
This needs to be converted to cpu endianness to work
on big endian platforms.
Fix endianness for big endian platforms by converting
the values for the axes read from little endian to
cpu.
This is also partially fixed in commit 82d8e5da1a33 ("iio:
accel: bmg160: optimize transfers in trigger handler").
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 95e7ff034175db7d8aefabe7716c4d42bea24fde upstream.
For big endian platforms, reading the axes will return
invalid values.
The device stores each axis value in a 16 bit little
endian register. The driver uses regmap_read_bulk to get
the axis value, resulting in a 16 bit little endian value.
This needs to be converted to cpu endianness to work
on big endian platforms.
Fix endianness for big endian platforms by converting
the values for the axes read from little endian to
cpu.
This is also partially fixed in commit 82d8e5da1a33 ("iio:
accel: bmg160: optimize transfers in trigger handler").
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iio: gyro: bmg160: fix buffer read values
commit b475c59b113db1e66eb9527ffdec3c5241c847e5 upstream.
When reading gyroscope axes using iio buffers, the values
returned are always 0. In the interrupt handler, the return
value of the read operation is returned to the user instead
of the value read. Return the value read to the user.
This is also fixed in commit 82d8e5da1a33 ("iio:
accel: bmg160: optimize transfers in trigger handler").
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b475c59b113db1e66eb9527ffdec3c5241c847e5 upstream.
When reading gyroscope axes using iio buffers, the values
returned are always 0. In the interrupt handler, the return
value of the read operation is returned to the user instead
of the value read. Return the value read to the user.
This is also fixed in commit 82d8e5da1a33 ("iio:
accel: bmg160: optimize transfers in trigger handler").
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iio: accel: bmc150: fix endianness when reading axes
commit 2215f31dc6f88634c1916362e922b1ecdce0a6b3 upstream.
For big endian platforms, reading the axes will return
invalid values.
The device stores each axis value in a 16 bit little
endian register. The driver uses regmap_read_bulk to get
the axis value, resulting in a 16 bit little endian value.
This needs to be converted to cpu endianness to work
on big endian platforms.
Fix endianness for big endian platforms by converting
the values for the axes read from little endian to
cpu.
This is also partially fixed in commit b6fb9b6d6552 ("iio:
accel: bmc150: optimize transfers in trigger handler").
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2215f31dc6f88634c1916362e922b1ecdce0a6b3 upstream.
For big endian platforms, reading the axes will return
invalid values.
The device stores each axis value in a 16 bit little
endian register. The driver uses regmap_read_bulk to get
the axis value, resulting in a 16 bit little endian value.
This needs to be converted to cpu endianness to work
on big endian platforms.
Fix endianness for big endian platforms by converting
the values for the axes read from little endian to
cpu.
This is also partially fixed in commit b6fb9b6d6552 ("iio:
accel: bmc150: optimize transfers in trigger handler").
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
iio: st_magn: always define ST_MAGN_TRIGGER_SET_STATE
commit 9b090a98e95c2530ef0ce474e3b6218621b8ae25 upstream.
When CONFIG_IIO_TRIGGER is enabled but CONFIG_IIO_BUFFER is
not, we get a build error in the st_magn driver:
drivers/iio/magnetometer/st_magn_core.c:573:23: error: 'ST_MAGN_TRIGGER_SET_STATE' undeclared here (not in a function)
.set_trigger_state = ST_MAGN_TRIGGER_SET_STATE,
^~~~~~~~~~~~~~~~~~~~~~~~~
Apparently, this ST_MAGN_TRIGGER_SET_STATE macro was meant to
be set to NULL when the definition is not available because
st_magn_buffer.c is not compiled, but the alternative definition
was not included in the original patch. This adds it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 74f5683f35fe ("iio: st_magn: Add irq trigger handling")
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9b090a98e95c2530ef0ce474e3b6218621b8ae25 upstream.
When CONFIG_IIO_TRIGGER is enabled but CONFIG_IIO_BUFFER is
not, we get a build error in the st_magn driver:
drivers/iio/magnetometer/st_magn_core.c:573:23: error: 'ST_MAGN_TRIGGER_SET_STATE' undeclared here (not in a function)
.set_trigger_state = ST_MAGN_TRIGGER_SET_STATE,
^~~~~~~~~~~~~~~~~~~~~~~~~
Apparently, this ST_MAGN_TRIGGER_SET_STATE macro was meant to
be set to NULL when the definition is not available because
st_magn_buffer.c is not compiled, but the alternative definition
was not included in the original patch. This adds it.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 74f5683f35fe ("iio: st_magn: Add irq trigger handling")
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: renesas_usbhs: fix to avoid using a disabled ep in usbhsg_queue_done()
commit 4fccb0767fdbdb781a9c5b5c15ee7b219443c89d upstream.
This patch fixes an issue that usbhsg_queue_done() may cause kernel
panic when dma callback is running and usb_ep_disable() is called
by interrupt handler. (Especially, we can reproduce this issue using
g_audio with usb-dmac driver.)
For example of a flow:
usbhsf_dma_complete (on tasklet)
--> usbhsf_pkt_handler (on tasklet)
--> usbhsg_queue_done (on tasklet)
*** interrupt happened and usb_ep_disable() is called ***
--> usbhsg_queue_pop (on tasklet)
Then, oops happened.
Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4fccb0767fdbdb781a9c5b5c15ee7b219443c89d upstream.
This patch fixes an issue that usbhsg_queue_done() may cause kernel
panic when dma callback is running and usb_ep_disable() is called
by interrupt handler. (Especially, we can reproduce this issue using
g_audio with usb-dmac driver.)
For example of a flow:
usbhsf_dma_complete (on tasklet)
--> usbhsf_pkt_handler (on tasklet)
--> usbhsg_queue_done (on tasklet)
*** interrupt happened and usb_ep_disable() is called ***
--> usbhsg_queue_pop (on tasklet)
Then, oops happened.
Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer
commit 6490865c67825277b29638e839850882600b48ec upstream.
This patch adds a code to surely disable TX IRQ of the pipe before
starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs
may happen in rare cases when DMAC is used.
Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6490865c67825277b29638e839850882600b48ec upstream.
This patch adds a code to surely disable TX IRQ of the pipe before
starting TX DMAC transfer. Otherwise, a lot of unnecessary TX IRQs
may happen in rare cases when DMAC is used.
Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler()
commit 894f2fc44f2f3f48c36c973b1123f6ab298be160 upstream.
When unexpected situation happened (e.g. tx/rx irq happened while
DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL
pointer dereference like the followings:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 80000007 [#1] SMP ARM
Modules linked in: usb_f_acm u_serial g_serial libcomposite
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63
Hardware name: Generic R8A7790 (Flattened Device Tree)
task: c0729c00 ti: c0724000 task.ti: c0724000
PC is at 0x0
LR is at usbhsf_pkt_handler+0xac/0x118
pc : [<00000000>] lr : [<c03257e0>] psr: 60000193
sp : c0725db8 ip : 00000000 fp : c0725df4
r10: 00000001 r9 : 00000193 r8 : ef3ccab4
r7 : ef3cca10 r6 : eea4586c r5 : 00000000 r4 : ef19ceb4
r3 : 00000000 r2 : 0000009c r1 : c0725dc4 r0 : ef19ceb4
This patch adds a condition to avoid the dereference.
Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 894f2fc44f2f3f48c36c973b1123f6ab298be160 upstream.
When unexpected situation happened (e.g. tx/rx irq happened while
DMAC is used), the usbhsf_pkt_handler() was possible to cause NULL
pointer dereference like the followings:
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 80000007 [#1] SMP ARM
Modules linked in: usb_f_acm u_serial g_serial libcomposite
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.5.0-rc6-00842-gac57066-dirty #63
Hardware name: Generic R8A7790 (Flattened Device Tree)
task: c0729c00 ti: c0724000 task.ti: c0724000
PC is at 0x0
LR is at usbhsf_pkt_handler+0xac/0x118
pc : [<00000000>] lr : [<c03257e0>] psr: 60000193
sp : c0725db8 ip : 00000000 fp : c0725df4
r10: 00000001 r9 : 00000193 r8 : ef3ccab4
r7 : ef3cca10 r6 : eea4586c r5 : 00000000 r4 : ef19ceb4
r3 : 00000000 r2 : 0000009c r1 : c0725dc4 r0 : ef19ceb4
This patch adds a condition to avoid the dereference.
Fixes: e73a989 ("usb: renesas_usbhs: add DMAEngine support")
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>