aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2023-03-06scsi: mpi3mr: NVMe command size greater than 8K failsRanjan Kumar1-2/+2
A wrong variable is checked while populating PRP entries in the PRP page and this results in failure. No PRP entries in the PRP page were successfully created and any NVMe Encapsulated commands with PRP of size greater than 8K failed. Signed-off-by: Ranjan Kumar <[email protected]> Signed-off-by: Sreekanth Reddy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06scsi: mpi3mr: Return proper values for failures in firmware init pathRanjan Kumar1-2/+9
Return proper non-zero return values for all the cases when the controller initialization and re-initialization fails. Signed-off-by: Ranjan Kumar <[email protected]> Signed-off-by: Sreekanth Reddy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06scsi: mpi3mr: Wait for diagnostic save during controller initRanjan Kumar1-1/+18
If a controller reset operation is triggered to recover the controller from a fault state, then wait for the snapdump to be saved in the firmware region before proceeding to reset the controller. Signed-off-by: Ranjan Kumar <[email protected]> Signed-off-by: Sreekanth Reddy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06scsi: mpi3mr: Driver unload crashes host when enhanced logging is enabledRanjan Kumar1-1/+2
Prevent driver from trying to dereference a NULL pointer in a debug print while removing a device during driver unload. Signed-off-by: Ranjan Kumar <[email protected]> Signed-off-by: Sreekanth Reddy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06scsi: mpi3mr: ioctl timeout when disabling/enabling interruptRanjan Kumar3-2/+14
As part of Task Management handling, the driver will disable and enable the MSIx index zero which belongs to the Admin reply queue. During this transition the driver loses some interrupts and this leads to Admin request and ioctl timeouts. After enabling the interrupts, poll the Admin reply queue to avoid timeouts. Signed-off-by: Ranjan Kumar <[email protected]> Signed-off-by: Sreekanth Reddy <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06scsi: lpfc: Avoid usage of list iterator variable after loopJakob Koschel1-4/+4
If the &epd_pool->list is empty when executing lpfc_get_io_buf_from_expedite_pool() the function would return an invalid pointer. Even in the case if the list is guaranteed to be populated, the iterator variable should not be used after the loop to be more robust for future changes. Linus proposed to avoid any use of the list iterator variable after the loop, in the attempt to move the list iterator variable declaration into the macro to avoid any potential misuse after the loop [1]. Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1] Signed-off-by: Jakob Koschel <[email protected]> Link: https://lore.kernel.org/r/20230301-scsi-lpfc-avoid-list-iterator-after-loop-v1-1-325578ae7561@gmail.com Reviewed-by: Justin Tee <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06scsi: lpfc: Check kzalloc() in lpfc_sli4_cgn_params_read()Justin Tee2-4/+2
If kzalloc() fails in lpfc_sli4_cgn_params_read(), then we rely on lpfc_read_object()'s routine to NULL check pdata. Currently, an early return error is thrown from lpfc_read_object() to protect us from NULL ptr dereference, but the errno code is -ENODEV. Change the errno code to a more appropriate -ENOMEM. Reported-by: Kang Chen <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Justin Tee <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06scsi: ufs: mcq: qcom: Clean the return path of ufs_qcom_mcq_config_resource()Asutosh Das1-4/+2
Smatch static checker reported: drivers/ufs/host/ufs-qcom.c:1469 ufs_qcom_mcq_config_resource() info: returning a literal zero is cleaner Fix the above warning by returning in place instead of a jump to a label. Also remove the usage of devm_kfree() as it's unnecessary in this function. Fixes: c263b4ef737e ("scsi: ufs: core: mcq: Configure resource regions") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Asutosh Das <[email protected]> Link: https://lore.kernel.org/r/3ebd2582af74b81ef7b57149f57c6a3bf0963953.1677721229.git.quic_asutoshd@quicinc.com Reviewed-by: Bjorn Andersson <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06scsi: ufs: mcq: qcom: Fix passing zero to PTR_ERRAsutosh Das1-1/+1
Fix an error case in ufs_qcom_mcq_config_resource(), where the return value is set to 0 before passing it to PTR_ERR. This led to Smatch warning: drivers/ufs/host/ufs-qcom.c:1455 ufs_qcom_mcq_config_resource() warn: passing zero to 'PTR_ERR' Fixes: c263b4ef737e ("scsi: ufs: core: mcq: Configure resource regions") Reported-by: Dan Carpenter <[email protected]> Signed-off-by: Asutosh Das <[email protected]> Link: https://lore.kernel.org/r/94ca99b327af634799ce5f25d0112c28cd00970d.1677721072.git.quic_asutoshd@quicinc.com Reviewed-by: Bjorn Andersson <[email protected]> Reviewed-by: Manivannan Sadhasivam <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06scsi: ufs: ufs-qcom: Remove impossible checkDan Carpenter1-1/+1
The "dev_req_params" pointer points to inside the middle of a struct so it can't be NULL. Removing this impossible condition is nice because now we don't need to consider the correct error code for that situation. Link: https://lore.kernel.org/r/Y/yA3niWUcGYgBU8@kili Fixes: f06fcc7155dc ("scsi: ufs-qcom: add QUniPro hardware support and power optimizations") Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06scsi: ufs: core: Add soft dependency on governor_simpleondemandAdrien Thierry1-0/+1
The ufshcd driver uses simpleondemand governor for devfreq. Add it to the list of ufshcd softdeps to allow userspace initramfs tools like dracut to automatically pull the governor module into the initramfs together with UFS drivers. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Adrien Thierry <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06scsi: hisi_sas: Check devm_add_action() return valueKang Chen1-2/+1
In case devm_add_action() fails, check it in the caller of interrupt_preinit_v3_hw(). Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Kang Chen <[email protected]> Acked-by: Xiang Chen <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06clk: k210: remove an implicit 64-bit divisionConor Dooley1-1/+1
The K210 clock driver depends on SOC_CANAAN, which is only selectable when !MMU on RISC-V. !MMU is not possible on 32-bit yet, but patches have been sent for its enabling. The kernel test robot reported this implicit 64-bit division there. Replace the implicit division with an explicit one. Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/linux-riscv/[email protected]/ Signed-off-by: Conor Dooley <[email protected]> Signed-off-by: Jesse Taube <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Damien Le Moal <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2023-03-06scsi: qla2xxx: Add option to disable FC2 Target supportDaniel Wagner3-2/+12
Commit 44c57f205876 ("scsi: qla2xxx: Changes to support FCP2 Target") added support for FC2 Targets. Unfortunately, there are older setups which break with this new feature enabled. Allow to disable it via module option. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Daniel Wagner <[email protected]> Reviewed-by: Himanshu Madhani <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06scsi: target: iscsi: Fix an error message in iscsi_check_key()Maurizio Lombardi1-5/+7
The first half of the error message is printed by pr_err(), the second half is printed by pr_debug(). The user will therefore see only the first part of the message and will miss some useful information. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maurizio Lombardi <[email protected]> Reviewed-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]>
2023-03-06dm crypt: add cond_resched() to dmcrypt_write()Mikulas Patocka1-0/+1
The loop in dmcrypt_write may be running for unbounded amount of time, thus we need cond_resched() in it. This commit fixes the following warning: [ 3391.153255][ C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897] ... [ 3391.387210][ C12] Call trace: [ 3391.390338][ C12] blk_attempt_bio_merge.part.6+0x38/0x158 [ 3391.395970][ C12] blk_attempt_plug_merge+0xc0/0x1b0 [ 3391.401085][ C12] blk_mq_submit_bio+0x398/0x550 [ 3391.405856][ C12] submit_bio_noacct+0x308/0x380 [ 3391.410630][ C12] dmcrypt_write+0x1e4/0x208 [dm_crypt] [ 3391.416005][ C12] kthread+0x130/0x138 [ 3391.419911][ C12] ret_from_fork+0x10/0x18 Reported-by: yangerkun <[email protected]> Fixes: dc2676210c42 ("dm crypt: offload writes to thread") Cc: [email protected] Signed-off-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2023-03-06dm thin: fix deadlock when swapping to thin deviceColy Li1-0/+2
This is an already known issue that dm-thin volume cannot be used as swap, otherwise a deadlock may happen when dm-thin internal memory demand triggers swap I/O on the dm-thin volume itself. But thanks to commit a666e5c05e7c ("dm: fix deadlock when swapping to encrypted device"), the limit_swap_bios target flag can also be used for dm-thin to avoid the recursive I/O when it is used as swap. Fix is to simply set ti->limit_swap_bios to true in both pool_ctr() and thin_ctr(). In my test, I create a dm-thin volume /dev/vg/swap and use it as swap device. Then I run fio on another dm-thin volume /dev/vg/main and use large --blocksize to trigger swap I/O onto /dev/vg/swap. The following fio command line is used in my test, fio --name recursive-swap-io --lockmem 1 --iodepth 128 \ --ioengine libaio --filename /dev/vg/main --rw randrw \ --blocksize 1M --numjobs 32 --time_based --runtime=12h Without this fix, the whole system can be locked up within 15 seconds. With this fix, there is no any deadlock or hung task observed after 2 hours of running fio. Furthermore, if blocksize is changed from 1M to 128M, after around 30 seconds fio has no visible I/O, and the out-of-memory killer message shows up in kernel message. After around 20 minutes all fio processes are killed and the whole system is back to being alive. This is exactly what is expected when recursive I/O happens on dm-thin volume when it is used as swap. Depends-on: a666e5c05e7c ("dm: fix deadlock when swapping to encrypted device") Cc: [email protected] Signed-off-by: Coly Li <[email protected]> Acked-by: Mikulas Patocka <[email protected]> Signed-off-by: Mike Snitzer <[email protected]>
2023-03-06net: ethernet: mtk_eth_soc: fix RX data corruption issueDaniel Golle2-1/+3
Fix data corruption issue with SerDes connected PHYs operating at 1.25 Gbps speed where we could previously observe about 30% packet loss while the bad packet counter was increasing. As almost all boards with MediaTek MT7622 or MT7986 use either the MT7531 switch IC operating at 3.125Gbps SerDes rate or single-port PHYs using rate-adaptation to 2500Base-X mode, this issue only got exposed now when we started trying to use SFP modules operating with 1.25 Gbps with the BananaPi R3 board. The fix is to set bit 12 which disables the RX FIFO clear function when setting up MAC MCR, MediaTek SDK did the same change stating: "If without this patch, kernel might receive invalid packets that are corrupted by GMAC."[1] [1]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/d8a2975939a12686c4a95c40db21efdc3f821f63 Fixes: 42c03844e93d ("net-next: mediatek: add support for MediaTek MT7622 SoC") Tested-by: Bjørn Mork <[email protected]> Signed-off-by: Daniel Golle <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Reviewed-by: Florian Fainelli <[email protected]> Link: https://lore.kernel.org/r/138da2735f92c8b6f8578ec2e5a794ee515b665f.1677937317.git.daniel@makrotopia.org Signed-off-by: Jakub Kicinski <[email protected]>
2023-03-06net: phy: smsc: fix link up detection in forced irq modeHeiner Kallweit1-11/+3
Currently link up can't be detected in forced mode if polling isn't used. Only link up interrupt source we have is aneg complete which isn't applicable in forced mode. Therefore we have to use energy-on as link up indicator. Fixes: 7365494550f6 ("net: phy: smsc: skip ENERGYON interrupt if disabled") Signed-off-by: Heiner Kallweit <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-06interconnect: qcom: qcm2290: Fix MASTER_SNOC_BIMC_NRTKonrad Dybcio1-2/+2
Due to what seems to be a copy-paste error, the _NRT master was identical to the _RT master, which should not be the case.. Fix it using the values available from the downstream kernel [1]. [1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/scuba-bus.dtsi#127 Fixes: 1a14b1ac3935 ("interconnect: qcom: Add QCM2290 driver support") Signed-off-by: Konrad Dybcio <[email protected]> Acked-by: Shawn Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-03-06cpumask: fix incorrect cpumask scanning result checksLinus Torvalds3-9/+9
It turns out that commit 596ff4a09b89 ("cpumask: re-introduce constant-sized cpumask optimizations") exposed a number of cases of drivers not checking the result of "cpumask_next()" and friends correctly. The documented correct check for "no more cpus in the cpumask" is to check for the result being equal or larger than the number of possible CPU ids, exactly _because_ we've always done those constant-sized cpumask scans using a widened type before. So the return value of a cpumask scan should be checked with if (cpu >= nr_cpu_ids) ... because the cpumask scan did not necessarily stop exactly *at* that maximum CPU id. But a few cases ended up instead using checks like if (cpu == nr_cpumask_bits) ... which used that internal "widened" number of bits. And that used to work pretty much by accident (ok, in this case "by accident" is simply because it matched the historical internal implementation of the cpumask scanning, so it was more of a "intentionally using implementation details rather than an accident"). But the extended constant-sized optimizations then did that internal implementation differently, and now that code that did things wrong but matched the old implementation no longer worked at all. Which then causes subsequent odd problems due to using what ends up being an invalid CPU ID. Most of these cases require either unusual hardware or special uses to hit, but the random.c one triggers quite easily. All you really need is to have a sufficiently small CONFIG_NR_CPUS value for the bit scanning optimization to be triggered, but not enough CPUs to then actually fill that widened cpumask. At that point, the cpumask scanning will return the NR_CPUS constant, which is _not_ the same as nr_cpumask_bits. This just does the mindless fix with sed -i 's/== nr_cpumask_bits/>= nr_cpu_ids/' to fix the incorrect uses. The ones in the SCSI lpfc driver in particular could probably be fixed more cleanly by just removing that repeated pattern entirely, but I am not emptionally invested enough in that driver to care. Reported-and-tested-by: Guenter Roeck <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Reported-and-tested-by: Geert Uytterhoeven <[email protected]> Link: https://lore.kernel.org/lkml/CAMuHMdUKo_Sf7TjKzcNDa8Ve+6QrK+P8nSQrSQ=6LTRmcBKNww@mail.gmail.com/ Reported-by: Vernon Yang <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Cc: Yury Norov <[email protected]> Cc: Jason A. Donenfeld <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
2023-03-07Merge tag 'drm-misc-fixes-2023-02-23' of ↵Dave Airlie10-53/+40
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes A fix for nouveau preventing the system shutdown and one for a build warning, and NULL pointer dereference fix for cirrus. Signed-off-by: Dave Airlie <[email protected]> From: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230223083839.5gtmu6i42bnj7pfh@houat
2023-03-06clk: HI655X: select REGMAP instead of depending on itRandy Dunlap1-1/+1
REGMAP is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it. Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues. Therefore, change the use of "depends on REGMAP" to "select REGMAP". Fixes: 3a49afb84ca0 ("clk: enable hi655x common clk automatically") Signed-off-by: Randy Dunlap <[email protected]> Cc: Riku Voipio <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: Michael Turquette <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]>
2023-03-06kbuild, clk: remove MODULE_LICENSE in non-modulesNick Alcock4-4/+0
Since commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message. So remove it in the files in this commit, none of which can be built as modules. Signed-off-by: Nick Alcock <[email protected]> Suggested-by: Luis Chamberlain <[email protected]> Cc: Luis Chamberlain <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Hitomi Hasegawa <[email protected]> Cc: Michael Turquette <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Acked-by: Conor Dooley <[email protected]> Reviewed-by: Conor Dooley <[email protected]> Signed-off-by: Stephen Boyd <[email protected]>
2023-03-06kbuild, clk: bcm2835: remove MODULE_LICENSE in non-modulesNick Alcock2-2/+0
Since commit 8b41fc4454e ("kbuild: create modules.builtin without Makefile.modbuiltin or tristate.conf"), MODULE_LICENSE declarations are used to identify modules. As a consequence, uses of the macro in non-modules will cause modprobe to misidentify their containing object file as a module when it is not (false positives), and modprobe might succeed rather than failing with a suitable error message. So remove it in the files in this commit, none of which can be built as modules. Signed-off-by: Nick Alcock <[email protected]> Suggested-by: Luis Chamberlain <[email protected]> Cc: Luis Chamberlain <[email protected]> Cc: [email protected] Cc: [email protected] Cc: Hitomi Hasegawa <[email protected]> Cc: Michael Turquette <[email protected]> Cc: Stephen Boyd <[email protected]> Cc: Florian Fainelli <[email protected]> Cc: Ray Jui <[email protected]> Cc: Scott Branden <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Stephen Boyd <[email protected]>
2023-03-06mtd: nand: mxic-ecc: Fix mxic_ecc_data_xfer_wait_for_completion() when irq ↵Christophe JAILLET1-0/+1
is used wait_for_completion_timeout() and readl_poll_timeout() don't handle their return value the same way. wait_for_completion_timeout() returns 0 on time out (and >0 in all other cases) readl_poll_timeout() returns 0 on success and -ETIMEDOUT upon a timeout. In order for the error handling path to work in both cases, the logic against wait_for_completion_timeout() needs to be inverted. Fixes: 48e6633a9fa2 ("mtd: nand: mxic-ecc: Add Macronix external ECC engine support") Signed-off-by: Christophe JAILLET <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/beddbc374557e44ceec897e68c4a5d12764ddbb9.1676459308.git.christophe.jaillet@wanadoo.fr
2023-03-06mtd: rawnand: meson: initialize struct with zeroesArseniy Krasnov1-1/+1
This structure must be zeroed, because it's field 'hw->core' is used as 'parent' in 'clk_core_fill_parent_index()', but it will be uninitialized. This happens, because when this struct is not zeroed, pointer 'hw' is "initialized" by garbage, which is valid pointer, but points to some garbage. So 'hw' will be dereferenced, but 'core' contains some random data which will be interpreted as a pointer. The following backtrace is result of dereference of such pointer: [ 1.081319] __clk_register+0x414/0x820 [ 1.085113] devm_clk_register+0x64/0xd0 [ 1.088995] meson_nfc_probe+0x258/0x6ec [ 1.092875] platform_probe+0x70/0xf0 [ 1.096498] really_probe+0xc8/0x3e0 [ 1.100034] __driver_probe_device+0x84/0x190 [ 1.104346] driver_probe_device+0x44/0x120 [ 1.108487] __driver_attach+0xb4/0x220 [ 1.112282] bus_for_each_dev+0x78/0xd0 [ 1.116077] driver_attach+0x2c/0x40 [ 1.119613] bus_add_driver+0x184/0x240 [ 1.123408] driver_register+0x80/0x140 [ 1.127203] __platform_driver_register+0x30/0x40 [ 1.131860] meson_nfc_driver_init+0x24/0x30 Fixes: 1e4d3ba66888 ("mtd: rawnand: meson: fix the clock") Signed-off-by: Arseniy Krasnov <[email protected]> Acked-by: Martin Blumenstingl <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/linux-mtd/[email protected]
2023-03-06interconnect: qcom: sm8550: switch to qcom_icc_rpmh_* functionDmitry Baryshkov1-97/+2
Change sm8550 interconnect driver to use generic qcom_icc_rpmh_* functions rather than embedding a copy of thema. This also fixes an overallocation of memory for icc_onecell_data structure. Fixes: e6f0d6a30f73 ("interconnect: qcom: Add SM8550 interconnect provider driver") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-03-06interconnect: qcom: sm8450: switch to qcom_icc_rpmh_* functionDmitry Baryshkov1-96/+2
Change sm8450 interconnect driver to use generic qcom_icc_rpmh_* functions rather than embedding a copy of thema. This also fixes an overallocation of memory for icc_onecell_data structure. Fixes: fafc114a468e ("interconnect: qcom: Add SM8450 interconnect provider driver") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-03-06interconnect: qcom: osm-l3: fix icc_onecell_data allocationDmitry Baryshkov1-1/+1
This is a struct with a trailing zero-length array of icc_node pointers but it's allocated as if it were a single array of icc_nodes instead. Fortunately this overallocates memory rather then allocating less memory than required. Fix by replacing devm_kcalloc() with devm_kzalloc() and struct_size() macro. Fixes: 5bc9900addaf ("interconnect: qcom: Add OSM L3 interconnect provider support") Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Georgi Djakov <[email protected]>
2023-03-06thunderbolt: Add quirk to disable CLxSanjay R Mehta2-3/+21
Add QUIRK_NO_CLX to disable the CLx state for hardware which doesn't supports it. AMD Yellow Carp and Pink Sardine don't support CLx state, hence disabling it using QUIRK_NO_CLX. Cc: [email protected] Signed-off-by: Sanjay R Mehta <[email protected]> Signed-off-by: Basavaraj Natikar <[email protected]> [mw: added debug log when the quirk is run] Signed-off-by: Mika Westerberg <[email protected]>
2023-03-06bnxt_en: Fix the double free during device removalSelvin Xavier2-2/+2
Following warning reported by KASAN during driver unload ================================================================== BUG: KASAN: double-free in bnxt_remove_one+0x103/0x200 [bnxt_en] Free of addr ffff88814e8dd4c0 by task rmmod/17469 CPU: 47 PID: 17469 Comm: rmmod Kdump: loaded Tainted: G S 6.2.0-rc7+ #2 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.3.10 08/15/2019 Call Trace: <TASK> dump_stack_lvl+0x33/0x46 print_report+0x17b/0x4b3 ? __call_rcu_common.constprop.79+0x27e/0x8c0 ? __pfx_free_object_rcu+0x10/0x10 ? __virt_addr_valid+0xe3/0x160 ? bnxt_remove_one+0x103/0x200 [bnxt_en] kasan_report_invalid_free+0x64/0xd0 ? bnxt_remove_one+0x103/0x200 [bnxt_en] ? bnxt_remove_one+0x103/0x200 [bnxt_en] __kasan_slab_free+0x179/0x1c0 ? bnxt_remove_one+0x103/0x200 [bnxt_en] __kmem_cache_free+0x194/0x350 bnxt_remove_one+0x103/0x200 [bnxt_en] pci_device_remove+0x62/0x110 device_release_driver_internal+0xf6/0x1c0 driver_detach+0x76/0xe0 bus_remove_driver+0x89/0x160 pci_unregister_driver+0x26/0x110 ? strncpy_from_user+0x188/0x1c0 bnxt_exit+0xc/0x24 [bnxt_en] __x64_sys_delete_module+0x21f/0x390 ? __pfx___x64_sys_delete_module+0x10/0x10 ? __pfx_mem_cgroup_handle_over_high+0x10/0x10 ? _raw_spin_lock+0x87/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ? __audit_syscall_entry+0x185/0x210 ? ktime_get_coarse_real_ts64+0x51/0x80 ? syscall_trace_enter.isra.18+0x126/0x1a0 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7effcb6fd71b Code: 73 01 c3 48 8b 0d 6d 17 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 17 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffeada270b8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 00005623660e0750 RCX: 00007effcb6fd71b RDX: 000000000000000a RSI: 0000000000000800 RDI: 00005623660e07b8 RBP: 0000000000000000 R08: 00007ffeada26031 R09: 0000000000000000 R10: 00007effcb771280 R11: 0000000000000206 R12: 00007ffeada272e0 R13: 00007ffeada28bc4 R14: 00005623660e02a0 R15: 00005623660e0750 </TASK> Auxiliary device structures are freed in bnxt_aux_dev_release. So avoid calling kfree from bnxt_remove_one. Also, set bp->edev to NULL before freeing the auxilary private structure. Fixes: d80d88b0dfff ("bnxt_en: Add auxiliary driver support") Reviewed-by: Ajit Khaparde <[email protected]> Reviewed-by: Andy Gospodarek <[email protected]> Signed-off-by: Selvin Xavier <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-06bnxt_en: Avoid order-5 memory allocation for TPA dataMichael Chan1-11/+12
The driver needs to keep track of all the possible concurrent TPA (GRO/LRO) completions on the aggregation ring. On P5 chips, the maximum number of concurrent TPA is 256 and the amount of memory we allocate is order-5 on systems using 4K pages. Memory allocation failure has been reported: NetworkManager: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null),cpuset=/,mems_allowed=0-1 CPU: 15 PID: 2995 Comm: NetworkManager Kdump: loaded Not tainted 5.10.156 #1 Hardware name: Dell Inc. PowerEdge R660/0M1CC5, BIOS 0.2.25 08/12/2022 Call Trace: dump_stack+0x57/0x6e warn_alloc.cold.120+0x7b/0xdd ? _cond_resched+0x15/0x30 ? __alloc_pages_direct_compact+0x15f/0x170 __alloc_pages_slowpath.constprop.108+0xc58/0xc70 __alloc_pages_nodemask+0x2d0/0x300 kmalloc_order+0x24/0xe0 kmalloc_order_trace+0x19/0x80 bnxt_alloc_mem+0x1150/0x15c0 [bnxt_en] ? bnxt_get_func_stat_ctxs+0x13/0x60 [bnxt_en] __bnxt_open_nic+0x12e/0x780 [bnxt_en] bnxt_open+0x10b/0x240 [bnxt_en] __dev_open+0xe9/0x180 __dev_change_flags+0x1af/0x220 dev_change_flags+0x21/0x60 do_setlink+0x35c/0x1100 Instead of allocating this big chunk of memory and dividing it up for the concurrent TPA instances, allocate each small chunk separately for each TPA instance. This will reduce it to order-0 allocations. Fixes: 79632e9ba386 ("bnxt_en: Expand bnxt_tpa_info struct to support 57500 chips.") Reviewed-by: Somnath Kotur <[email protected]> Reviewed-by: Damodharam Ammepalli <[email protected]> Reviewed-by: Pavan Chebbi <[email protected]> Signed-off-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-06net: phylib: get rid of unnecessary lockingRussell King (Oracle)1-7/+1
The locking in phy_probe() and phy_remove() does very little to prevent any races with e.g. phy_attach_direct(), but instead causes lockdep ABBA warnings. Remove it. ====================================================== WARNING: possible circular locking dependency detected 6.2.0-dirty #1108 Tainted: G W E ------------------------------------------------------ ip/415 is trying to acquire lock: ffff5c268f81ef50 (&dev->lock){+.+.}-{3:3}, at: phy_attach_direct+0x17c/0x3a0 [libphy] but task is already holding lock: ffffaef6496cb518 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x154/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (rtnl_mutex){+.+.}-{3:3}: __lock_acquire+0x35c/0x6c0 lock_acquire.part.0+0xcc/0x220 lock_acquire+0x68/0x84 __mutex_lock+0x8c/0x414 mutex_lock_nested+0x34/0x40 rtnl_lock+0x24/0x30 sfp_bus_add_upstream+0x34/0x150 phy_sfp_probe+0x4c/0x94 [libphy] mv3310_probe+0x148/0x184 [marvell10g] phy_probe+0x8c/0x200 [libphy] call_driver_probe+0xbc/0x15c really_probe+0xc0/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __device_attach_driver+0xc4/0x160 bus_for_each_drv+0x80/0xe0 __device_attach+0xb0/0x1f0 device_initial_probe+0x1c/0x2c bus_probe_device+0xa4/0xb0 device_add+0x360/0x53c phy_device_register+0x60/0xa4 [libphy] fwnode_mdiobus_phy_device_register+0xc0/0x190 [fwnode_mdio] fwnode_mdiobus_register_phy+0x160/0xd80 [fwnode_mdio] of_mdiobus_register+0x140/0x340 [of_mdio] orion_mdio_probe+0x298/0x3c0 [mvmdio] platform_probe+0x70/0xe0 call_driver_probe+0x34/0x15c really_probe+0xc0/0x320 __driver_probe_device+0x84/0x120 driver_probe_device+0x44/0x120 __driver_attach+0x104/0x210 bus_for_each_dev+0x78/0xdc driver_attach+0x2c/0x3c bus_add_driver+0x184/0x240 driver_register+0x80/0x13c __platform_driver_register+0x30/0x3c xt_compat_calc_jump+0x28/0xa4 [x_tables] do_one_initcall+0x50/0x1b0 do_init_module+0x50/0x1fc load_module+0x684/0x744 __do_sys_finit_module+0xc4/0x140 __arm64_sys_finit_module+0x28/0x34 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x6c/0x1b0 do_el0_svc+0x34/0x44 el0_svc+0x48/0xf0 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a0/0x1a4 -> #0 (&dev->lock){+.+.}-{3:3}: check_prev_add+0xb4/0xc80 validate_chain+0x414/0x47c __lock_acquire+0x35c/0x6c0 lock_acquire.part.0+0xcc/0x220 lock_acquire+0x68/0x84 __mutex_lock+0x8c/0x414 mutex_lock_nested+0x34/0x40 phy_attach_direct+0x17c/0x3a0 [libphy] phylink_fwnode_phy_connect.part.0+0x70/0xe4 [phylink] phylink_fwnode_phy_connect+0x48/0x60 [phylink] mvpp2_open+0xec/0x2e0 [mvpp2] __dev_open+0x104/0x214 __dev_change_flags+0x1d4/0x254 dev_change_flags+0x2c/0x7c do_setlink+0x254/0xa50 __rtnl_newlink+0x430/0x514 rtnl_newlink+0x58/0x8c rtnetlink_rcv_msg+0x17c/0x560 netlink_rcv_skb+0x64/0x150 rtnetlink_rcv+0x20/0x30 netlink_unicast+0x1d4/0x2b4 netlink_sendmsg+0x1a4/0x400 ____sys_sendmsg+0x228/0x290 ___sys_sendmsg+0x88/0xec __sys_sendmsg+0x70/0xd0 __arm64_sys_sendmsg+0x2c/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x6c/0x1b0 do_el0_svc+0x34/0x44 el0_svc+0x48/0xf0 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a0/0x1a4 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(rtnl_mutex); lock(&dev->lock); lock(rtnl_mutex); lock(&dev->lock); *** DEADLOCK *** Fixes: 298e54fa810e ("net: phy: add core phylib sfp support") Reported-by: Marc Zyngier <[email protected]> Signed-off-by: Russell King (Oracle) <[email protected]> Reviewed-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-06firmware: arm_scmi: Fix raw coexistence mode behaviour on failure pathCristian Marussi1-3/+3
When SCMI raw coexistence mode is enabled make the core stack probe successfully even when the initial base protocol exchanges with the platform/server failed. This behaviour enables the system to boot with a broken regular SCMI stack but with a fully functional and accessible SCMI raw debugfs interface that can be used to further debug the issue. Signed-off-by: Cristian Marussi <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sudeep Holla <[email protected]>
2023-03-06firmware: arm_scmi: Remove duplicate include header inclusionYe Xingchen1-1/+0
linux/of.h is included more than once, just remove the duplicate include header inclusion. Signed-off-by: Ye Xingchen <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Sudeep Holla <[email protected]>
2023-03-06firmware: arm_scmi: Return a literal instead of a variableDan Carpenter1-1/+1
In this context "return scmi_dev;" and "return NULL;" are equivalent but it is more readable to return a literal. Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Cristian Marussi <[email protected]> Link: https://lore.kernel.org/r/Y/Yx8pOdf8rNhPVe@kili Signed-off-by: Sudeep Holla <[email protected]>
2023-03-06firmware: arm_scmi: Clean up a return statement in scmi_probeDan Carpenter1-2/+2
The comments say "enabled" where "disabled" is intended. Also it's cleaner to return zero explicitly instead of ret. Signed-off-by: Dan Carpenter <[email protected]> Link: https://lore.kernel.org/r/Y86im5M49p3ePGxj@kili Signed-off-by: Sudeep Holla <[email protected]>
2023-03-06drm/meson: fix 1px pink line on GXM when scaling video overlayChristian Hewitt1-0/+2
Playing media with a resolution smaller than the crtc size requires the video overlay to be scaled for output and GXM boards display a 1px pink line on the bottom of the scaled overlay. Comparing with the downstream vendor driver revealed VPP_DUMMY_DATA not being set [0]. Setting VPP_DUMMY_DATA prevents the 1px pink line from being seen. [0] https://github.com/endlessm/linux-s905x/blob/master/drivers/amlogic/amports/video.c#L7869 Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Suggested-by: Martin Blumenstingl <[email protected]> Signed-off-by: Christian Hewitt <[email protected]> Acked-by: Martin Blumenstingl <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-03-06net: stmmac: add to set device wake up flag when stmmac init phyRongguang Wei1-0/+1
When MAC is not support PMT, driver will check PHY's WoL capability and set device wakeup capability in stmmac_init_phy(). We can enable the WoL through ethtool, the driver would enable the device wake up flag. Now the device_may_wakeup() return true. But if there is a way which enable the PHY's WoL capability derectly, like in BIOS. The driver would not know the enable thing and would not set the device wake up flag. The phy_suspend may failed like this: [ 32.409063] PM: dpm_run_callback(): mdio_bus_phy_suspend+0x0/0x50 returns -16 [ 32.409065] PM: Device stmmac-1:00 failed to suspend: error -16 [ 32.409067] PM: Some devices failed to suspend, or early wake event detected Add to set the device wakeup enable flag according to the get_wol function result in PHY can fix the error in this scene. v2: add a Fixes tag. Fixes: 1d8e5b0f3f2c ("net: stmmac: Support WOL with phy") Signed-off-by: Rongguang Wei <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-03-05hwmon: (adt7475) Fix masking of hysteresis registersTony O'Brien1-2/+2
The wrong bits are masked in the hysteresis register; indices 0 and 2 should zero bits [7:4] and preserve bits [3:0], and index 1 should zero bits [3:0] and preserve bits [7:4]. Fixes: 1c301fc5394f ("hwmon: Add a driver for the ADT7475 hardware monitoring chip") Signed-off-by: Tony O'Brien <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2023-03-05hwmon: (adt7475) Display smoothing attributes in correct orderTony O'Brien1-2/+2
Throughout the ADT7475 driver, attributes relating to the temperature sensors are displayed in the order Remote 1, Local, Remote 2. Make temp_st_show() conform to this expectation so that values set by temp_st_store() can be displayed using the correct attribute. Fixes: 8f05bcc33e74 ("hwmon: (adt7475) temperature smoothing") Signed-off-by: Tony O'Brien <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Guenter Roeck <[email protected]>
2023-03-05Merge tag 'v6.3-p2' of ↵Linus Torvalds3-23/+53
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto fix from Herbert Xu: "Fix a regression in the caam driver" * tag 'v6.3-p2' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: caam - Fix edesc/iv ordering mixup
2023-03-05Merge tag 'x86-urgent-2023-03-05' of ↵Linus Torvalds1-3/+17
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 updates from Thomas Gleixner: "A small set of updates for x86: - Return -EIO instead of success when the certificate buffer for SEV guests is not large enough - Allow STIPB to be enabled with legacy IBSR. Legacy IBRS is cleared on return to userspace for performance reasons, but the leaves user space vulnerable to cross-thread attacks which STIBP prevents. Update the documentation accordingly" * tag 'x86-urgent-2023-03-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: virt/sev-guest: Return -EIO if certificate buffer is not large enough Documentation/hw-vuln: Document the interaction between IBRS and STIBP x86/speculation: Allow enabling STIBP with legacy IBRS
2023-03-05Merge tag 'irq-urgent-2023-03-05' of ↵Linus Torvalds2-2/+3
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull irq updates from Thomas Gleixner: "A set of updates for the interrupt susbsystem: - Prevent possible NULL pointer derefences in irq_data_get_affinity_mask() and irq_domain_create_hierarchy() - Take the per device MSI lock before invoking code which relies on it being hold - Make sure that MSI descriptors are unreferenced before freeing them. This was overlooked when the platform MSI code was converted to use core infrastructure and results in a fals positive warning - Remove dead code in the MSI subsystem - Clarify the documentation for pci_msix_free_irq() - More kobj_type constification" * tag 'irq-urgent-2023-03-05' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: genirq/msi, platform-msi: Ensure that MSI descriptors are unreferenced genirq/msi: Drop dead domain name assignment irqdomain: Add missing NULL pointer check in irq_domain_create_hierarchy() genirq/irqdesc: Make kobj_type structures constant PCI/MSI: Clarify usage of pci_msix_free_irq() genirq/msi: Take the per-device MSI lock before validating the control structure genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask()
2023-03-04Merge tag 'i2c-for-6.3-rc1-part2' of ↵Linus Torvalds2-15/+7
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux Pull more i2c updates from Wolfram Sang: "Some improvements/fixes for the newly added GXP driver and a Kconfig dependency fix" * tag 'i2c-for-6.3-rc1-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: i2c: gxp: fix an error code in probe i2c: gxp: return proper error on address NACK i2c: gxp: remove "empty" switch statement i2c: Disable I2C_APPLE when I2C_PASEMI is a builtin
2023-03-03Merge tag 'for-v6.3-part2' of ↵Linus Torvalds1-3/+3
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply Pull more power supply updates from Sebastian Reichel: - Fix DT binding for Richtek RT9467 - Fix a NULL pointer check in the power-supply core - Document meaning of absent "present" property * tag 'for-v6.3-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply: dt-bindings: power: supply: Revise Richtek RT9467 compatible name ABI: testing: sysfs-class-power: Document absence of "present" property power: supply: fix null pointer check order in __power_supply_register
2023-03-03Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds32-244/+285
Pull more SCSI updates from James Bottomley: "Updates that missed the first pull, mostly because of needing more soak time. Driver updates (zfcp, ufs, mpi3mr, plus two ipr bug fixes), an enclosure services (ses) update (mostly bug fixes) and other minor bug fixes and changes" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (32 commits) scsi: zfcp: Trace when request remove fails after qdio send fails scsi: zfcp: Change the type of all fsf request id fields and variables to u64 scsi: zfcp: Make the type for accessing request hashtable buckets size_t scsi: ufs: core: Simplify ufshcd_execute_start_stop() scsi: ufs: core: Rely on the block layer for setting RQF_PM scsi: core: Extend struct scsi_exec_args scsi: lpfc: Fix double word in comments scsi: core: Remove the /proc/scsi/${proc_name} directory earlier scsi: core: Fix a source code comment scsi: cxgbi: Remove unneeded version.h include scsi: qedi: Remove unneeded version.h include scsi: mpi3mr: Remove unneeded version.h include scsi: mpi3mr: Fix missing mrioc->evtack_cmds initialization scsi: mpi3mr: Use number of bits to manage bitmap sizes scsi: mpi3mr: Remove unnecessary memcpy() to alltgt_info->dmi scsi: mpi3mr: Fix issues in mpi3mr_get_all_tgt_info() scsi: mpi3mr: Fix an issue found by KASAN scsi: mpi3mr: Replace 1-element array with flex-array scsi: ipr: Work around fortify-string warning scsi: ipr: Make ipr_probe_ioa_part2() return void ...
2023-03-03i2c: gxp: fix an error code in probeDan Carpenter1-1/+1
This is passing IS_ERR() instead of PTR_ERR() so instead of an error code it prints and returns the number 1. Fixes: 4a55ed6f89f5 ("i2c: Add GXP SoC I2C Controller") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Nick Hawkins <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2023-03-03i2c: gxp: return proper error on address NACKWolfram Sang1-2/+4
According to Documentation/i2c/fault-codes.rst, NACK after sending an address should be -ENXIO. Signed-off-by: Wolfram Sang <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.