aboutsummaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-05-12drm/i915/overlay: Fix active retire callback alignmentTvrtko Ursulin1-1/+1
__i915_active_call annotation is required on the retire callback to ensure correct function alignment. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: a21ce8ad12d2 ("drm/i915/overlay: Switch to using i915_active tracking") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210429083530.849546-1-tvrtko.ursulin@linux.intel.com (cherry picked from commit d8e44e4dd221ee283ea60a6fb87bca08807aa0ab) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-05-12drm/i915: Fix crash in auto_retireStéphane Marchesin1-1/+2
The retire logic uses the 2 lower bits of the pointer to the retire function to store flags. However, the auto_retire function is not guaranteed to be aligned to a multiple of 4, which causes crashes as we jump to the wrong address, for example like this: 2021-04-24T18:03:53.804300Z WARNING kernel: [ 516.876901] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI 2021-04-24T18:03:53.804310Z WARNING kernel: [ 516.876906] CPU: 7 PID: 146 Comm: kworker/u16:6 Tainted: G U 5.4.105-13595-g3cd84167b2df #1 2021-04-24T18:03:53.804311Z WARNING kernel: [ 516.876907] Hardware name: Google Volteer2/Volteer2, BIOS Google_Volteer2.13672.76.0 02/22/2021 2021-04-24T18:03:53.804312Z WARNING kernel: [ 516.876911] Workqueue: events_unbound active_work 2021-04-24T18:03:53.804313Z WARNING kernel: [ 516.876914] RIP: 0010:auto_retire+0x1/0x20 2021-04-24T18:03:53.804314Z WARNING kernel: [ 516.876916] Code: e8 01 f2 ff ff eb 02 31 db 48 89 d8 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 f0 ff 87 c8 00 00 00 0f 88 ab 47 4a 00 31 c0 5d c3 0f <1f> 44 00 00 55 48 89 e5 f0 ff 8f c8 00 00 00 0f 88 9a 47 4a 00 74 2021-04-24T18:03:53.804319Z WARNING kernel: [ 516.876918] RSP: 0018:ffff9b4d809fbe38 EFLAGS: 00010286 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876919] RAX: 0000000000000007 RBX: ffff927915079600 RCX: 0000000000000007 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876921] RDX: ffff9b4d809fbe40 RSI: 0000000000000286 RDI: ffff927915079600 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876922] RBP: ffff9b4d809fbe68 R08: 8080808080808080 R09: fefefefefefefeff 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876924] R10: 0000000000000010 R11: ffffffff92e44bd8 R12: ffff9279150796a0 2021-04-24T18:03:53.804322Z WARNING kernel: [ 516.876925] R13: ffff92791c368180 R14: ffff927915079640 R15: 000000001c867605 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876926] FS: 0000000000000000(0000) GS:ffff92791ffc0000(0000) knlGS:0000000000000000 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876928] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2021-04-24T18:03:53.804324Z WARNING kernel: [ 516.876929] CR2: 0000239514955000 CR3: 00000007f82da001 CR4: 0000000000760ee0 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876930] PKRU: 55555554 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876931] Call Trace: 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876935] __active_retire+0x77/0xcf 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876939] process_one_work+0x1da/0x394 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876941] worker_thread+0x216/0x375 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876944] kthread+0x147/0x156 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876946] ? pr_cont_work+0x58/0x58 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876948] ? kthread_blkcg+0x2e/0x2e 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876950] ret_from_fork+0x1f/0x40 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876952] Modules linked in: cdc_mbim cdc_ncm cdc_wdm xt_cgroup rfcomm cmac algif_hash algif_skcipher af_alg xt_MASQUERADE uinput snd_soc_rt5682_sdw snd_soc_rt5682 snd_soc_max98373_sdw snd_soc_max98373 snd_soc_rl6231 regmap_sdw snd_soc_sof_sdw snd_soc_hdac_hdmi snd_soc_dmic snd_hda_codec_hdmi snd_sof_pci snd_sof_intel_hda_common intel_ipu6_psys snd_sof_xtensa_dsp soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof snd_soc_hdac_hda snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core soundwire_bus snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core intel_ipu6_isys videobuf2_dma_contig videobuf2_v4l2 videobuf2_common videobuf2_memops mei_hdcp intel_ipu6 ov2740 ov8856 at24 sx9310 dw9768 v4l2_fwnode cros_ec_typec intel_pmc_mux roles acpi_als typec fuse iio_trig_sysfs cros_ec_light_prox cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core industrialio_triggered_buffer cros_ec_sensors_ring kfifo_buf industrialio cros_ec_sensorhub 2021-04-24T18:03:53.804337Z WARNING kernel: [ 516.876972] cdc_ether usbnet iwlmvm lzo_rle lzo_compress iwl7000_mac80211 iwlwifi zram cfg80211 r8152 mii btusb btrtl btintel btbcm bluetooth ecdh_generic ecc joydev 2021-04-24T18:03:53.804337Z EMERG kernel: [ 516.879169] gsmi: Log Shutdown Reason 0x03 This change fixes this by aligning the function. Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Fixes: 229007e02d69 ("drm/i915: Wrap i915_active in a simple kreffed struct") Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210429031021.1218091-1-marcheu@chromium.org (cherry picked from commit ca419f407b43cc89942ebc297c7a63d94abbcae4) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-05-12drm/i915/gt: Fix a double free in gen8_preallocate_top_level_pdpLv Yunlong1-1/+0
Our code analyzer reported a double free bug. In gen8_preallocate_top_level_pdp, pde and pde->pt.base are allocated via alloc_pd(vm) with one reference. If pin_pt_dma() failed, pde->pt.base is freed by i915_gem_object_put() with a reference dropped. Then free_pd calls free_px() defined in intel_ppgtt.c, which calls i915_gem_object_put() to put pde->pt.base again. As pde->pt.base is protected by refcount, so the second put will not free pde->pt.base actually. But, maybe it is better to remove the first put? Fixes: 82adf901138cc ("drm/i915/gt: Shrink i915_page_directory's slab bucket") Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210426124340.4238-1-lyl2019@mail.ustc.edu.cn (cherry picked from commit ac69496fe65cca0611d5917b7d232730ff605bc7) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-05-12drm/i915: Read C0DRB3/C1DRB3 as 16 bits againVille Syrjälä1-2/+2
We've defined C0DRB3/C1DRB3 as 16 bit registers, so access them as such. Fixes: 1c8242c3a4b2 ("drm/i915: Use unchecked writes for setting up the fences") Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210421153401.13847-3-ville.syrjala@linux.intel.com (cherry picked from commit f765a5b48c667bdada5e49d5e0f23f8c0687b21b) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-05-12drm/i915: Avoid div-by-zero on gen2Ville Syrjälä1-1/+1
Gen2 tiles are 2KiB in size so i915_gem_object_get_tile_row_size() can in fact return <4KiB, which leads to div-by-zero here. Avoid that. Not sure i915_gem_object_get_tile_row_size() is entirely sane anyway since it doesn't account for the different tile layouts on i8xx/i915... I'm not able to hit this before commit 6846895fde05 ("drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT") and it looks like I also need to run recent version of Mesa. With those in place xonotic trips on this quite easily on my 85x. Cc: stable@vger.kernel.org Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210421153401.13847-2-ville.syrjala@linux.intel.com (cherry picked from commit ed52c62d386f764194e0184fdb905d5f24194cae) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-05-12nvmet: seset ns->file when open failsDaniel Wagner1-3/+5
Reset the ns->file value to NULL also in the error case in nvmet_file_ns_enable(). The ns->file variable points either to file object or contains the error code after the filp_open() call. This can lead to following problem: When the user first setups an invalid file backend and tries to enable the ns, it will fail. Then the user switches over to a bdev backend and enables successfully the ns. The first received I/O will crash the system because the IO backend is chosen based on the ns->file value: static u16 nvmet_parse_io_cmd(struct nvmet_req *req) { [...] if (req->ns->file) return nvmet_file_parse_io_cmd(req); return nvmet_bdev_parse_io_cmd(req); } Reported-by: Enzo Matsumiya <ematsumiya@suse.com> Signed-off-by: Daniel Wagner <dwagner@suse.de> Signed-off-by: Christoph Hellwig <hch@lst.de>
2021-05-12Merge branch 'for-5.13' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator into regulator-5.14Mark Brown1-1/+2
2021-05-12soc: mediatek: add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Link: https://lore.kernel.org/r/1620705350-104687-1-git-send-email-zou_wei@huawei.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2021-05-12drm/panfrost: Remove redundant error printing in panfrost_device_init()Zhen Lei1-1/+0
When devm_ioremap_resource() fails, a clear enough error message will be printed by its subfunction __devm_ioremap_resource(). The error information contains the device name, failure cause, and possibly resource information. Therefore, remove the error printing here to simplify code and reduce the binary size. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511090433.4396-1-thunder.leizhen@huawei.com
2021-05-12regulator: fan53555: fix tcs4525 function namesPeter Geis1-9/+9
The tcs4525 is based off the fan53526. Rename the tcs4525 functions to align with this. Signed-off-by: Peter Geis <pgwipeout@gmail.com> Link: https://lore.kernel.org/r/20210511211335.2935163-4-pgwipeout@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-12regulator: fan53555: only bind tcs4525 to correct chip idPeter Geis1-7/+18
The tcs4525 regulator has a chip id of <12>. Only allow the driver to bind to the correct chip id for safety, in accordance with the other supported devices. Signed-off-by: Peter Geis <pgwipeout@gmail.com> Link: https://lore.kernel.org/r/20210511211335.2935163-3-pgwipeout@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-12regulator: fan53555: fix TCS4525 voltage calulationPeter Geis1-2/+1
The TCS4525 has 128 voltage steps. With the calculation set to 127 the most significant bit is disregarded which leads to a miscalculation of the voltage by about 200mv. Fix the calculation to end deadlock on the rk3566-quartz64 which uses this as the cpu regulator. Fixes: 914df8faa7d6 ("regulator: fan53555: Add TCS4525 DCDC support") Signed-off-by: Peter Geis <pgwipeout@gmail.com> Link: https://lore.kernel.org/r/20210511211335.2935163-2-pgwipeout@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-12Merge series "regulator: fan53555: tcs4525 fix and cleanup" from Peter Geis <pgwipeout@gmail.com>:Mark Brown1-2/+1
The tcs4525 voltage calculation is incorrect, which leads to a deadlock on the rk3566-quartz64 board when loading cpufreq. Fix the voltage calculation to correct the deadlock. While we are at it, add a safety check and clean up the function names to be more accurate. Peter Geis (3): regulator: fan53555: fix TCS4525 voltage calulation regulator: fan53555: only bind tcs4525 to correct chip id regulator: fan53555: fix tcs4525 function names drivers/regulator/fan53555.c | 44 ++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 17 deletions(-) -- 2.25.1
2021-05-12regulator: fan53555: fix TCS4525 voltage calulationPeter Geis1-2/+1
The TCS4525 has 128 voltage steps. With the calculation set to 127 the most significant bit is disregarded which leads to a miscalculation of the voltage by about 200mv. Fix the calculation to end deadlock on the rk3566-quartz64 which uses this as the cpu regulator. Fixes: 914df8faa7d6 ("regulator: fan53555: Add TCS4525 DCDC support") Signed-off-by: Peter Geis <pgwipeout@gmail.com> Link: https://lore.kernel.org/r/20210511211335.2935163-2-pgwipeout@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-12nbd: share nbd_put and return by goto put_nbdSun Ke1-4/+3
Replace the following two statements by the statement “goto put_nbd;” nbd_put(nbd); return 0; Signed-off-by: Sun Ke <sunke32@huawei.com> Suggested-by: Markus Elfring <Markus.Elfring@web.de> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Link: https://lore.kernel.org/r/20210512114331.1233964-3-sunke32@huawei.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-05-12nbd: Fix NULL pointer in flush_workqueueSun Ke1-1/+2
Open /dev/nbdX first, the config_refs will be 1 and the pointers in nbd_device are still null. Disconnect /dev/nbdX, then reference a null recv_workq. The protection by config_refs in nbd_genl_disconnect is useless. [ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 656.368943] #PF: supervisor write access in kernel mode [ 656.369844] #PF: error_code(0x0002) - not-present page [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [ 656.371693] Oops: 0002 [#1] SMP [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1 [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 <f0> 48 0f b1 55 d [ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318 [ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Call Trace: [ 656.385111] flush_workqueue+0x92/0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656.386422] genl_rcv_msg+0xfc/0x2b0 [ 656.386685] ? nbd_ioctl+0x490/0x490 [ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0 [ 656.387354] netlink_rcv_skb+0x62/0x180 [ 656.387638] genl_rcv+0x34/0x60 [ 656.387874] netlink_unicast+0x26d/0x590 [ 656.388162] netlink_sendmsg+0x398/0x6c0 [ 656.388451] ? netlink_rcv_skb+0x180/0x180 [ 656.388750] ____sys_sendmsg+0x1da/0x320 [ 656.389038] ? ____sys_recvmsg+0x130/0x220 [ 656.389334] ___sys_sendmsg+0x8e/0xf0 [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0 [ 656.389889] ? handle_mm_fault+0x1671/0x21d0 [ 656.390201] __sys_sendmsg+0x6d/0xe0 [ 656.390464] __x64_sys_sendmsg+0x23/0x30 [ 656.390751] do_syscall_64+0x45/0x70 [ 656.391017] entry_SYSCALL_64_after_hwframe+0x44/0xa9 To fix it, just add if (nbd->recv_workq) to nbd_disconnect_and_put(). Fixes: e9e006f5fcf2 ("nbd: fix max number of supported devs") Signed-off-by: Sun Ke <sunke32@huawei.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Link: https://lore.kernel.org/r/20210512114331.1233964-2-sunke32@huawei.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-05-12ACPI: DPTF: Add battery participant for Intel SoCsSumeet Pawnikar1-0/+2
Add ACPI Device ID for DPTF battery participant for the Intel Jasper Lake (INT3532) and Tiger Lake (INTC1050) SoC based platforms. Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-12ACPI: PM: Add ACPI ID of Alder Lake FanSumeet Pawnikar1-0/+1
Add a new unique fan ACPI device ID for Alder Lake to support it in acpi_dev_pm_attach() function. Fixes: 38748bcb940e ("ACPI: DPTF: Support Alder Lake") Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com> Acked-by: Zhang Rui <rui.zhang@intel.com> Cc: 5.10+ <stable@vger.kernel.org> # 5.10+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-05-12spi: Assume GPIO CS active high in ACPI caseAndy Shevchenko1-4/+18
Currently GPIO CS handling, when descriptors are in use, doesn't take into consideration that in ACPI case the default polarity is Active High and can't be altered. Instead we have to use the per-chip definition provided by SPISerialBus() resource. Fixes: 766c6b63aa04 ("spi: fix client driver breakages when using GPIO descriptors") Cc: Liguang Zhang <zhangliguang@linux.alibaba.com> Cc: Jay Fang <f.fangjian@huawei.com> Cc: Sven Van Asbroeck <thesven73@gmail.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Xin Hao <xhao@linux.alibaba.com> Link: https://lore.kernel.org/r/20210511140912.30757-1-andriy.shevchenko@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-12spi: sprd: Add missing MODULE_DEVICE_TABLEChunyan Zhang1-0/+1
MODULE_DEVICE_TABLE is used to extract the device information out of the driver and builds a table when being compiled. If using this macro, kernel can find the driver if available when the device is plugged in, and then loads that driver and initializes the device. Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Link: https://lore.kernel.org/r/20210512093534.243040-1-zhang.lyra@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-12regulator: cros-ec: Fix error code in dev_err messageAxel Lin1-1/+2
Show proper error code instead of 0. Signed-off-by: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/20210512075824.620580-1-axel.lin@ingics.com Signed-off-by: Mark Brown <broonie@kernel.org>
2021-05-12gpio: tegra186: Don't set parent IRQ affinityJon Hunter1-11/+0
When hotplugging CPUs on Tegra186 and Tegra194 errors such as the following are seen ... IRQ63: set affinity failed(-22). IRQ65: set affinity failed(-22). IRQ66: set affinity failed(-22). IRQ67: set affinity failed(-22). Looking at the /proc/interrupts the above are all interrupts associated with GPIOs. The reason why these error messages occur is because there is no 'parent_data' associated with any of the GPIO interrupts and so tegra186_irq_set_affinity() simply returns -EINVAL. To understand why there is no 'parent_data' it is first necessary to understand that in addition to the GPIO interrupts being routed to the interrupt controller (GIC), the interrupts for some GPIOs are also routed to the Tegra Power Management Controller (PMC) to wake up the system from low power states. In order to configure GPIO events as wake events in the PMC, the PMC is configured as IRQ parent domain for the GPIO IRQ domain. Originally the GIC was the IRQ parent domain of the PMC and although this was working, this started causing issues once commit 64a267e9a41c ("irqchip/gic: Configure SGIs as standard interrupts") was added, because technically, the GIC is not a parent of the PMC. Commit c351ab7bf2a5 ("soc/tegra: pmc: Don't create fake interrupt hierarchy levels") fixed this by severing the IRQ domain hierarchy for the Tegra GPIOs and hence, there may be no IRQ parent domain for the GPIOs. The GPIO controllers on Tegra186 and Tegra194 have either one or six interrupt lines to the interrupt controller. For GPIO controllers with six interrupts, the mapping of the GPIO interrupt to the controller interrupt is configurable within the GPIO controller. Currently a default mapping is used, however, it could be possible to use the set affinity callback for the Tegra186 GPIO driver to do something a bit more interesting. Currently, because interrupts for all GPIOs are have the same mapping and any attempts to configure the affinity for a given GPIO can conflict with another that shares the same IRQ, for now it is simpler to just remove set affinity support and this avoids the above warnings being seen. Cc: <stable@vger.kernel.org> Fixes: c4e1f7d92cd6 ("gpio: tegra186: Set affinity callback to parent") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpio: xilinx: Correct kernel doc for xgpio_probe()Andy Shevchenko1-1/+1
Kernel doc validator complains: .../gpio-xilinx.c:556: warning: expecting prototype for xgpio_of_probe(). Prototype was for xgpio_probe() instead Correct as suggested by changing the name of the function in the doc.. Fixes: 749564ffd52d ("gpio/xilinx: Convert the driver to platform device interface") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Neeli Srinivas <sneeli@xilinx.com> Reviewed-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpio: xilinx: No need to disable IRQs in the handlerAndy Shevchenko1-3/+2
In IRQ handler interrupts are already disabled, hence no need to repeat it. Even in the threaded case, it is not a problem because IRQ framework keeps interrupt disabled there as well. Remove disabling IRQ part in the handler. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Neeli Srinivas <sneeli@xilinx.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpio: xilinx: Switch to use bitmap APIsAndy Shevchenko1-173/+173
It seems that Xilinx GPIO driver operates with bit arrays longer than 32 and thus can leverage bitmap APIs for that. It makes code better to understand. The ->probe() function is modified to try read properties for both channels since is_dual check makes only sense for the amount of pins used for the second channel. On top of that kzalloc() guarantees zero initial values for the fields in the private data structure, hence drop unneeded conditionals and assignments. The change is inspired by Syed Nayyar Waris' ideas about bitmap API extension. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Neeli Srinivas <sneeli@xilinx.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpio: xilinx: Introduce xgpio_read_chan() / xgpio_write_chan()Andy Shevchenko1-31/+37
With the new helpers, i.e. xgpio_read_chan() / xgpio_write_chan(), the code is easier to read and maintain. No functional changes intended. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Neeli Srinivas <sneeli@xilinx.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpiolib: Drop duplicate offset check in gpiochip_is_requested()Andy Shevchenko1-3/+0
gpiochip_get_desc() already does the check, drop a duplicate in gpiochip_is_requested(). Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpio: mockup: Switch to use gpiochip_get_desc()Andy Shevchenko1-6/+3
Switch to use gpiochip_get_desc() helper. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpio: logicvc: Remove redundant error printing in logicvc_gpio_probe()Zhen Lei1-3/+1
When devm_ioremap_resource() fails, a clear enough error message will be printed by its subfunction __devm_ioremap_resource(). The error information contains the device name, failure cause, and possibly resource information. Therefore, remove the error printing here to simplify code and reduce the binary size. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12gpio: cadence: Add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
2021-05-12vfio-ccw: Serialize FSM IDLE state with I/O completionEric Farman1-2/+10
Today, the stacked call to vfio_ccw_sch_io_todo() does three things: 1) Update a solicited IRB with CP information, and release the CP if the interrupt was the end of a START operation. 2) Copy the IRB data into the io_region, under the protection of the io_mutex 3) Reset the vfio-ccw FSM state to IDLE to acknowledge that vfio-ccw can accept more work. The trouble is that step 3 is (A) invoked for both solicited and unsolicited interrupts, and (B) sitting after the mutex for step 2. This second piece becomes a problem if it processes an interrupt for a CLEAR SUBCHANNEL while another thread initiates a START, thus allowing the CP and FSM states to get out of sync. That is: CPU 1 CPU 2 fsm_do_clear() fsm_irq() fsm_io_request() vfio_ccw_sch_io_todo() fsm_io_helper() Since the FSM state and CP should be kept in sync, let's make a note when the CP is released, and rely on that as an indication that the FSM should also be reset at the end of this routine and open up the device for more work. Signed-off-by: Eric Farman <farman@linux.ibm.com> Acked-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Message-Id: <20210511195631.3995081-4-farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-05-12vfio-ccw: Reset FSM state to IDLE inside FSMEric Farman2-2/+1
When an I/O request is made, the fsm_io_request() routine moves the FSM state from IDLE to CP_PROCESSING, and then fsm_io_helper() moves it to CP_PENDING if the START SUBCHANNEL received a cc0. Yet, the error case to go from CP_PROCESSING back to IDLE is done after the FSM call returns. Let's move this up into the FSM proper, to provide some better symmetry when unwinding in this case. Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-Id: <20210511195631.3995081-3-farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-05-12vfio-ccw: Check initialized flag in cp_init()Eric Farman1-0/+4
We have a really nice flag in the channel_program struct that indicates if it had been initialized by cp_init(), and use it as a guard in the other cp accessor routines, but not for a duplicate call into cp_init(). The possibility of this occurring is low, because that flow is protected by the private->io_mutex and FSM CP_PROCESSING state. But then why bother checking it in (for example) cp_prefetch() then? Let's just be consistent and check for that in cp_init() too. Fixes: 71189f263f8a3 ("vfio-ccw: make it safe to access channel programs") Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Acked-by: Matthew Rosato <mjrosato@linux.ibm.com> Message-Id: <20210511195631.3995081-2-farman@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2021-05-12drm/qxl: balance dumb_shadow_bo pinGerd Hoffmann1-0/+1
The shadow bo is created in pinned state, so we have to unpin it when dropping the reference. Otherwise ttm is unhappy and throws a WARN() on release. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: http://patchwork.freedesktop.org/patch/msgid/20210511104522.2694803-3-kraxel@redhat.com
2021-05-12drm/qxl: drop redundant codeGerd Hoffmann1-3/+1
Not needed, qxl_io_destroy_primary() does that for us. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: http://patchwork.freedesktop.org/patch/msgid/20210511104522.2694803-2-kraxel@redhat.com
2021-05-12drm/modifiers: Enforce consistency between the cap an IN_FORMATSDaniel Vetter1-1/+17
It's very confusing for userspace to have to deal with inconsistencies here, and some drivers screwed this up a bit. Most just ommitted the format list when they meant to say that only linear modifier is allowed, but some also meant that only implied modifiers are acceptable (because actually none of the planes registered supported modifiers). Now that this is all done consistently across all drivers, document the rules and enforce it in the drm core. v2: - Make the capability a link (Simon) - Note that all is lost before 5.1. v3: - Use drm_WARN_ON (Lyude) Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Emil Velikov <emil.velikov@collabora.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Acked-by: Maxime Ripard <maxime@cerno.tech> Cc: Simon Ser <contact@emersion.fr> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210506132343.2873699-1-daniel.vetter@ffwll.ch
2021-05-12drm: fix semicolon.cocci warningskernel test robot1-5/+5
drivers/gpu/drm/kmb/kmb_dsi.c:284:3-4: Unneeded semicolon drivers/gpu/drm/kmb/kmb_dsi.c:304:3-4: Unneeded semicolon drivers/gpu/drm/kmb/kmb_dsi.c:321:3-4: Unneeded semicolon drivers/gpu/drm/kmb/kmb_dsi.c:340:3-4: Unneeded semicolon drivers/gpu/drm/kmb/kmb_dsi.c:364:2-3: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Fixes: ade896460e4a ("drm: DRM_KMB_DISPLAY should depend on ARCH_KEEMBAY") CC: Geert Uytterhoeven <geert+renesas@glider.be> Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: kernel test robot <lkp@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210511161123.GA21597@90a0f0cadc2d
2021-05-12drm/i915: Use correct downstream caps for check Src-Ctl mode for PCONAnkit Nautiyal1-1/+1
Fix the typo in DPCD caps used for checking SRC CTL mode of HDMI2.1 PCON v2: Corrected Fixes tag (Jani Nikula). v3: Rebased. Fixes: 04b6603d13be ("drm/i915/display: Configure HDMI2.1 Pcon for FRL only if Src-Ctl mode is available") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: "Ville Syrj_l_" <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Swati Sharma <swati2.sharma@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210511120930.12218-1-ankit.k.nautiyal@intel.com
2021-05-12reset: brcmstb: Add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Fixes: 77750bc089e4 ("reset: Add Broadcom STB SW_INIT reset controller driver") Signed-off-by: Zou Wei <zou_wei@huawei.com> Link: https://lore.kernel.org/r/1620789283-15048-1-git-send-email-zou_wei@huawei.com Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2021-05-11drm/amdgpu/display: fix build when CONFIG_DRM_AMD_DC_DCN is not definedAlex Deucher1-0/+2
Fixes: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function ‘amdgpu_dm_initialize_drm_device’: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:3726:7: error: implicit declaration of function ‘register_outbox_irq_handlers’; did you mean ‘register_hpd_handlers’? [-Werror=implicit-function-declaration] 3726 | if (register_outbox_irq_handlers(dm->adev)) { | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ | register_hpd_handlers Fixes: 81927e2808be ("drm/amd/display: Support for DMUB AUX") Reviewed-by: Jude Shih <shenshih@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Jude Shish <Jude.Shih@amd.com>
2021-05-11drm/amdgpu/display: fix warning when CONFIG_DRM_AMD_DC_DCN is not definedAlex Deucher1-1/+1
Fixes: At top level: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:633:13: warning: ‘dm_dmub_outbox1_low_irq’ defined but not used [-Wunused-function] 633 | static void dm_dmub_outbox1_low_irq(void *interrupt_params) | ^~~~~~~~~~~~~~~~~~~~~~~ Fixes: 81927e2808be ("drm/amd/display: Support for DMUB AUX") Reviewed-by: Jude Shih <shenshih@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Jude Shih <Jude.Shih@amd.com>
2021-05-11net: ipa: memory region array is variable sizeAlex Elder2-1/+4
IPA configuration data includes an array of memory region descriptors. That was a fixed-size array at one time, but at some point we started defining it such that it was only as big as required for a given platform. The actual number of entries in the array is recorded in the configuration data along with the array. A loop in ipa_mem_config() still assumes the array has entries for all defined memory region IDs. As a result, this loop can go past the end of the actual array and attempt to write "canary" values based on nonsensical data. Fix this, by stashing the number of entries in the array, and using that rather than IPA_MEM_COUNT in the initialization loop found in ipa_mem_config(). The only remaining use of IPA_MEM_COUNT is in a validation check to ensure configuration data doesn't have too many entries. That's fine for now. Fixes: 3128aae8c439a ("net: ipa: redefine struct ipa_mem_data") Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-11ionic: fix ptp support config breakageShannon Nelson1-0/+1
When IONIC=y and PTP_1588_CLOCK=m were set in the .config file the driver link failed with undefined references. We add the dependancy depends on PTP_1588_CLOCK || !PTP_1588_CLOCK to clear this up. If PTP_1588_CLOCK=m, the depends limits IONIC to =m (or disabled). If PTP_1588_CLOCK is disabled, IONIC can be any of y/m/n. Fixes: 61db421da31b ("ionic: link in the new hw timestamp code") Reported-by: kernel test robot <lkp@intel.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Allen Hubbe <allenbh@pensando.io> Signed-off-by: Shannon Nelson <snelson@pensando.io> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-11usb: class: cdc-wdm: WWAN framework integrationLoic Poulain4-5/+180
The WWAN framework provides a unified way to handle WWAN/modems and its control port(s). It has initially been introduced to support MHI/PCI modems, offering the same control protocols as the USB variants such as MBIM, QMI, AT... The WWAN framework exposes these control protocols as character devices, similarly to cdc-wdm, but in a bus agnostic fashion. This change adds registration of the USB modem cdc-wdm control endpoints to the WWAN framework as standard control ports (wwanXpY...). Exposing cdc-wdm through WWAN framework normally maintains backward compatibility, e.g: $ qmicli --device-open-qmi -d /dev/wwan0p1QMI --dms-get-ids instead of $ qmicli --device-open-qmi -d /dev/cdc-wdm0 --dms-get-ids However, some tools may rely on cdc-wdm driver/device name for device detection. It is then safer to keep the 'legacy' cdc-wdm character device to prevent any breakage. This is handled in this change by API mutual exclusion, only one access method can be used at a time, either cdc-wdm chardev or WWAN API. Note that unknown channel types (other than MBIM, AT or MBIM) are not registered to the WWAN framework. Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-11mISDN: fix possible use-after-free in HFC_cleanup()Zou Wei1-1/+1
This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-11atm: iphase: fix possible use-after-free in ia_module_exit()Zou Wei1-1/+1
This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-11Merge tag 'mac80211-for-net-2021-05-11' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211David S. Miller6-11/+246
Johannes Berg says: ==================== pull-request: mac80211 2021-05-11 So exciting times, for the first pull request for fixes I have a bunch of security things that have been under embargo for a while - see more details in the tag below, and at the patch posting message I linked to. I organized with Kalle to just have a single set of fixes for mac80211 and ath10k/ath11k, we don't know about any of the other vendors (the mac80211 + already released firmware is sufficient to fix iwlwifi.) Please pull and let me know if there's any problem. Several security issues in the 802.11 implementations were found by Mathy Vanhoef (New York University Abu Dhabi), and this contains the fixes developed for mac80211 and specifically Qualcomm drivers, I'm sending this together (as agreed with Kalle) to have just a single set of patches for now. We don't know about other vendors though. More details in the patch posting: https://lore.kernel.org/r/20210511180259.159598-1-johannes@sipsolutions.net ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-11net: stmmac: Fix MAC WoL not working if PHY does not support WoLJoakim Zhang1-3/+6
Both get and set WoL will check device_can_wakeup(), if MAC supports PMT, it will set device wakeup capability. After commit 1d8e5b0f3f2c ("net: stmmac: Support WOL with phy"), device wakeup capability will be overwrite in stmmac_init_phy() according to phy's Wol feature. If phy doesn't support WoL, then MAC will lose wakeup capability. To fix this issue, only overwrite device wakeup capability when MAC doesn't support PMT. For STMMAC now driver checks MAC's WoL capability if MAC supports PMT, if not support, driver will check PHY's WoL capability. Fixes: 1d8e5b0f3f2c ("net: stmmac: Support WOL with phy") Reviewed-by: Jisheng Zhang <Jisheng.Zhang@synaptics.com> Signed-off-by: Joakim Zhang <qiangqing.zhang@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2021-05-11RDMA/rxe: Clear all QP fields if creation failedLeon Romanovsky1-0/+7
rxe_qp_do_cleanup() relies on valid pointer values in QP for the properly created ones, but in case rxe_qp_from_init() failed it was filled with garbage and caused tot the following error. refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 12560 at lib/refcount.c:28 refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Modules linked in: CPU: 1 PID: 12560 Comm: syz-executor.4 Not tainted 5.12.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Code: e9 db fe ff ff 48 89 df e8 2c c2 ea fd e9 8a fe ff ff e8 72 6a a7 fd 48 c7 c7 e0 b2 c1 89 c6 05 dc 3a e6 09 01 e8 ee 74 fb 04 <0f> 0b e9 af fe ff ff 0f 1f 84 00 00 00 00 00 41 56 41 55 41 54 55 RSP: 0018:ffffc900097ceba8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815bb075 RDI: fffff520012f9d67 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815b4eae R11: 0000000000000000 R12: ffff8880322a4800 R13: ffff8880322a4940 R14: ffff888033044e00 R15: 0000000000000000 FS: 00007f6eb2be3700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdbe5d41000 CR3: 000000001d181000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] kref_put include/linux/kref.h:64 [inline] rxe_qp_do_cleanup+0x96f/0xaf0 drivers/infiniband/sw/rxe/rxe_qp.c:805 execute_in_process_context+0x37/0x150 kernel/workqueue.c:3327 rxe_elem_release+0x9f/0x180 drivers/infiniband/sw/rxe/rxe_pool.c:391 kref_put include/linux/kref.h:65 [inline] rxe_create_qp+0x2cd/0x310 drivers/infiniband/sw/rxe/rxe_verbs.c:425 _ib_create_qp drivers/infiniband/core/core_priv.h:331 [inline] ib_create_named_qp+0x2ad/0x1370 drivers/infiniband/core/verbs.c:1231 ib_create_qp include/rdma/ib_verbs.h:3644 [inline] create_mad_qp+0x177/0x2d0 drivers/infiniband/core/mad.c:2920 ib_mad_port_open drivers/infiniband/core/mad.c:3001 [inline] ib_mad_init_device+0xd6f/0x1400 drivers/infiniband/core/mad.c:3092 add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:717 enable_device_and_get+0x1cd/0x3b0 drivers/infiniband/core/device.c:1331 ib_register_device drivers/infiniband/core/device.c:1413 [inline] ib_register_device+0x7c7/0xa50 drivers/infiniband/core/device.c:1365 rxe_register_device+0x3d5/0x4a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1147 rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247 rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:503 rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline] rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250 nldev_newlink+0x30e/0x550 drivers/infiniband/core/nldev.c:1555 rdma_nl_rcv_msg+0x36d/0x690 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x2ee/0x430 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 8700e3e7c485 ("Soft RoCE driver") Link: https://lore.kernel.org/r/7bf8d548764d406dbbbaf4b574960ebfd5af8387.1620717918.git.leonro@nvidia.com Reported-by: syzbot+36a7f280de4e11c6f04e@syzkaller.appspotmail.com Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Reviewed-by: Zhu Yanjun <zyjzyj2000@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2021-05-11IB/hfi1: Delete an unneeded bool conversionZhen Lei1-1/+1
The result of an expression consisting of a single relational operator is already of the bool type and does not need to be evaluated explicitly. No functional change. Link: https://lore.kernel.org/r/20210510120635.3636-1-thunder.leizhen@huawei.com Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.