[PW_SID:1053567] driver core: Make deferred_probe_timeout default a Kconfig option#3305
Open
BluezTestBot wants to merge 11 commits intoworkflowfrom
Open
[PW_SID:1053567] driver core: Make deferred_probe_timeout default a Kconfig option#3305BluezTestBot wants to merge 11 commits intoworkflowfrom
BluezTestBot wants to merge 11 commits intoworkflowfrom
Conversation
Add a check for the user-provided length in mgmt_mesh_add() against the size of the param buffer. This prevents a heap buffer overflow if the user provides a length larger than the destination buffer. Fixes: b338d91 ("Bluetooth: Implement support for Mesh") Cc: stable@vger.kernel.org Signed-off-by: Maiquel Paiva <maiquelpaiva@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
…short Test L2CAP/ECFC/BV-26-C expect the response to L2CAP_ECRED_CONN_REQ with and MTU value < L2CAP_ECRED_MIN_MTU (64) to be L2CAP_CR_LE_INVALID_PARAMS rather than L2CAP_CR_LE_UNACCEPT_PARAMS. Also fix not including the correct number of CIDs in the response since the spec requires all CIDs being rejected to be included in the response. Link: bluez/bluez#1868 Fixes: 15f02b9 ("Bluetooth: L2CAP: Add initial code for Enhanced Credit Based Mode") Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
There is no point in having the label since all it does is return the value in the 'err' variable. Instead make every goto return directly and remove the label. Signed-off-by: Dongyang Jin <jindongyang@kylinos.cn> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
When TX timestamping is enabled via SO_TIMESTAMPING, SKBs may be queued into sk_error_queue and will stay there until consumed. If userspace never gets to read the timestamps, or if the controller is removed unexpectedly, these SKBs will leak. Fix by adding skb_queue_purge() calls for sk_error_queue in affected bluetooth destructors. RFCOMM does not currently use sk_error_queue. Fixes: 134f4b3 ("Bluetooth: add support for skb TX SND/COMPLETION timestamping") Reported-by: syzbot+7ff4013eabad1407b70a@syzkaller.appspotmail.com Closes: https://syzbot.org/bug?extid=7ff4013eabad1407b70a Cc: stable@vger.kernel.org Signed-off-by: Heitor Alves de Siqueira <halves@igalia.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
If retries are exhausted, driver should not do futher operation. During mt79xx firmware download process, if the retry count reaches0, driver will return an -EIO error and release the firmware resources. Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
To prevent abnormal controller states, it is necessary to check status in another part of the mt79xx firmware setup. During this process, receiving the 'BTMTK_WMT_PATCH_PROGRESS' status is unexpected. If this occurs, it should be treated as an error, and driver must be prevented from continuing execution. Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Add a new flag 'BTMTK_FIRMWARE_DL_RETRY'. If an error occurs during mt79xx firmware download process, this flag will be set and cleared after a reset. If the flag is already set and firmware still cannot be loaded successfully after a reset, no further reset attempts will be made. In other words, if there is a problem during firmware download, only one reset will be attempted. Signed-off-by: Chris Lu <chris.lu@mediatek.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The setup process previously combined error handling and retry gating under one condition. As a result, the final failed attempt exited without performing cleanup. Update the failure path to always perform power and port cleanup on setup failure, and reopen the port only when retrying. Fixes: 9e80587 ("Bluetooth: hci_qca: Enhance retry logic in qca_setup") Signed-off-by: Jinwang Li <jinwang.li@oss.qualcomm.com> Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Whenever new chipset support is added to the driver code, we ended up adding chipset name to the last of the switch case arising code readability issue because of improper sorting of the chipset names in various places of the code. Refactor code such a way that new chipset can be added easily in the code without compromising code readability. Signed-off-by: Vivek Sahu <vivek.sahu@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This patch adds workflow files for ci: [sync.yml] - The workflow file for scheduled work - Sync the repo with upstream repo and rebase the workflow branch - Review the patches in the patchwork and creates the PR if needed [ci.yml] - The workflow file for CI tasks - Run CI tests when PR is created Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Code using driver_deferred_probe_check_state() differs from most EPROBE_DEFER handling in the kernel. Where other EPROBE_DEFER handling (e.g. clks, gpios and regulators) waits indefinitely for suppliers to show up, code using driver_deferred_probe_check_state() will fail after the deferred_probe_timeout. This is a problem for generic distro kernels which want to support many boards using a single kernel build. These kernels want as much drivers to be modular as possible. The initrd also should be as small as possible, so the initrd will *not* have drivers not needing to get the rootfs. Combine this with waiting for a full-disk encryption password in the initrd and it is pretty much guaranteed that the default 10s timeout will be hit, causing probe() failures when drivers on the rootfs happen to get modprobe-d before other rootfs modules providing their suppliers. Make the default timeout configurable from Kconfig to allow distro kernel configs where many of the supplier drivers are modules to set the default through Kconfig and allow using a value of -1 to disable the timeout (wait indefinitely). Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
|
CheckPatch |
|
GitLint |
|
SubjectPrefix |
|
BuildKernel |
|
CheckAllWarning |
|
CheckSparse |
|
BuildKernel32 |
|
TestRunnerSetup |
|
TestRunner_l2cap-tester |
|
TestRunner_iso-tester |
|
TestRunner_bnep-tester |
|
TestRunner_mgmt-tester |
|
TestRunner_rfcomm-tester |
|
TestRunner_sco-tester |
|
TestRunner_ioctl-tester |
|
TestRunner_mesh-tester |
|
TestRunner_smp-tester |
|
TestRunner_userchan-tester |
|
IncrementalBuild |
github-actions
bot
force-pushed
the
workflow
branch
3 times, most recently
from
208468a to
49a9961
Compare
github-actions
bot
force-pushed
the
workflow
branch
5 times, most recently
from
620c8d9 to
07fb4f1
Compare
github-actions
bot
force-pushed
the
workflow
branch
6 times, most recently
from
0bcc21a to
40558a3
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Code using driver_deferred_probe_check_state() differs from most
EPROBE_DEFER handling in the kernel. Where other EPROBE_DEFER handling
(e.g. clks, gpios and regulators) waits indefinitely for suppliers to
show up, code using driver_deferred_probe_check_state() will fail
after the deferred_probe_timeout.
This is a problem for generic distro kernels which want to support many
boards using a single kernel build. These kernels want as much drivers to
be modular as possible. The initrd also should be as small as possible,
so the initrd will not have drivers not needing to get the rootfs.
Combine this with waiting for a full-disk encryption password in
the initrd and it is pretty much guaranteed that the default 10s timeout
will be hit, causing probe() failures when drivers on the rootfs happen
to get modprobe-d before other rootfs modules providing their suppliers.
Make the default timeout configurable from Kconfig to allow distro kernel
configs where many of the supplier drivers are modules to set the default
through Kconfig and allow using a value of -1 to disable the timeout
(wait indefinitely).
Signed-off-by: Hans de Goede johannes.goede@oss.qualcomm.com
Documentation/admin-guide/kernel-parameters.txt | 2 +-
drivers/base/Kconfig | 9 +++++++++
drivers/base/dd.c | 9 ++++-----
3 files changed, 14 insertions(+), 6 deletions(-)