May 2025 - Linux-stable-mirror

[PATCH] mmc: core: sd: Apply BROKEN_SD_DISCARD quirk earlier

by Avri Altman

Move the BROKEN_SD_DISCARD quirk for certain SanDisk SD cards from the `mmc_blk_fixups[]` to `mmc_sd_fixups[]`. This ensures the quirk is applied earlier in the device initialization process, aligning with the reasoning in [1]. Applying the quirk sooner prevents the kernel from incorrectly enabling discard support on affected cards during initial setup. [1] https://lore.kernel.org/all/20240820230631.GA436523@sony.com Fixes: 07d2872bf4c8 ("mmc: core: Add SD card quirk for broken discard") Signed-off-by: Avri Altman <avri.altman(a)sandisk.com> Cc: stable(a)vger.kernel.org --- drivers/mmc/core/quirks.h | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/mmc/core/quirks.h b/drivers/mmc/core/quirks.h index 7f893bafaa60..c417ed34c057 100644 --- a/drivers/mmc/core/quirks.h +++ b/drivers/mmc/core/quirks.h @@ -44,6 +44,12 @@ static const struct mmc_fixup __maybe_unused mmc_sd_fixups[] = { 0, -1ull, SDIO_ANY_ID, SDIO_ANY_ID, add_quirk_sd, MMC_QUIRK_NO_UHS_DDR50_TUNING, EXT_CSD_REV_ANY), + /* + * Some SD cards reports discard support while they don't + */ + MMC_FIXUP(CID_NAME_ANY, CID_MANFID_SANDISK_SD, 0x5344, add_quirk_sd, + MMC_QUIRK_BROKEN_SD_DISCARD), + END_FIXUP }; @@ -147,12 +153,6 @@ static const struct mmc_fixup __maybe_unused mmc_blk_fixups[] = { MMC_FIXUP("M62704", CID_MANFID_KINGSTON, 0x0100, add_quirk_mmc, MMC_QUIRK_TRIM_BROKEN), - /* - * Some SD cards reports discard support while they don't - */ - MMC_FIXUP(CID_NAME_ANY, CID_MANFID_SANDISK_SD, 0x5344, add_quirk_sd, - MMC_QUIRK_BROKEN_SD_DISCARD), - END_FIXUP }; -- 2.25.1

3 months, 4 weeks

3
2
0 0

[PATCH 5.15 0/1] Oopses on module unload seen on 5.15-rc

by Fedor Pchelkin

A followup to the similar patch sent to 6.1.y: https://lore.kernel.org/stable/20250521165909.834545-1-pchelkin@ispras.ru/ commit 959cadf09dbae7b304f03e039b8d8e13c529e2dd Author: Peter Zijlstra <peterz(a)infradead.org> Date: Mon Oct 14 10:05:48 2024 -0700 x86/its: Use dynamic thunks for indirect branches commit 872df34d7c51a79523820ea6a14860398c639b87 upstream. being ported to 5.15.y would lead to kernel crashes there after module unload operations. As mentioned in the blamed patch comment describing the backport adaptations: [ pawan: CONFIG_EXECMEM and CONFIG_EXECMEM_ROX are not supported on backport kernel, made changes to use module_alloc() and set_memory_*() for dynamic thunks. ] module_alloc/module_memfree in conjunction with memory protection routines were used. The allocated memory is vmalloc-based, and it ends up being ROX upon release inside its_free_mod(). Freeing of special permissioned memory in vmalloc requires its own handling. VM_FLUSH_RESET_PERMS flag was introduced for these purposes. In-kernel users dealing with the stuff had to care about this explicitly before commit 4c4eb3ecc91f ("x86/modules: Set VM_FLUSH_RESET_PERMS in module_alloc()"). It fixes the current problem. More recent kernels starting from 6.2 have the commit and are not affected. Found by Linux Verification Center (linuxtesting.org). Thomas Gleixner (1): x86/modules: Set VM_FLUSH_RESET_PERMS in module_alloc() arch/x86/kernel/ftrace.c | 2 -- arch/x86/kernel/kprobes/core.c | 1 - arch/x86/kernel/module.c | 9 +++++---- 3 files changed, 5 insertions(+), 7 deletions(-) -- 2.49.0

3 months, 4 weeks

1
1
0 0

Re: [PATCH v1] virtio_blk: Fix disk deletion hang on device surprise removal

by Michael S. Tsirkin

On Wed, May 21, 2025 at 06:37:41AM +0000, Parav Pandit wrote: > When the PCI device is surprise removed, requests may not complete > the device as the VQ is marked as broken. Due to this, the disk > deletion hangs. > > Fix it by aborting the requests when the VQ is broken. > > With this fix now fio completes swiftly. > An alternative of IO timeout has been considered, however > when the driver knows about unresponsive block device, swiftly clearing > them enables users and upper layers to react quickly. > > Verified with multiple device unplug iterations with pending requests in > virtio used ring and some pending with the device. > > Fixes: 43bb40c5b926 ("virtio_pci: Support surprise removal of virtio pci device") > Cc: stable(a)vger.kernel.org > Reported-by: lirongqing(a)baidu.com > Closes: https://lore.kernel.org/virtualization/c45dd68698cd47238c55fb73ca9b4741@bai… > Reviewed-by: Max Gurtovoy <mgurtovoy(a)nvidia.com> > Reviewed-by: Israel Rukshin <israelr(a)nvidia.com> > Signed-off-by: Parav Pandit <parav(a)nvidia.com> > --- > changelog: > v0->v1: > - Fixed comments from Stefan to rename a cleanup function > - Improved logic for handling any outstanding requests > in bio layer > - improved cancel callback to sync with ongoing done() thanks for the patch! questions: > --- > drivers/block/virtio_blk.c | 95 ++++++++++++++++++++++++++++++++++++++ > 1 file changed, 95 insertions(+) > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > index 7cffea01d868..5212afdbd3c7 100644 > --- a/drivers/block/virtio_blk.c > +++ b/drivers/block/virtio_blk.c > @@ -435,6 +435,13 @@ static blk_status_t virtio_queue_rq(struct blk_mq_hw_ctx *hctx, > blk_status_t status; > int err; > > + /* Immediately fail all incoming requests if the vq is broken. > + * Once the queue is unquiesced, upper block layer flushes any pending > + * queued requests; fail them right away. > + */ > + if (unlikely(virtqueue_is_broken(vblk->vqs[qid].vq))) > + return BLK_STS_IOERR; > + > status = virtblk_prep_rq(hctx, vblk, req, vbr); > if (unlikely(status)) > return status; just below this: spin_lock_irqsave(&vblk->vqs[qid].lock, flags); err = virtblk_add_req(vblk->vqs[qid].vq, vbr); if (err) { and virtblk_add_req calls virtqueue_add_sgs, so it will fail on a broken vq. Why do we need to check it one extra time here? > @@ -508,6 +515,11 @@ static void virtio_queue_rqs(struct rq_list *rqlist) > while ((req = rq_list_pop(rqlist))) { > struct virtio_blk_vq *this_vq = get_virtio_blk_vq(req->mq_hctx); > > + if (unlikely(virtqueue_is_broken(this_vq->vq))) { > + rq_list_add_tail(&requeue_list, req); > + continue; > + } > + > if (vq && vq != this_vq) > virtblk_add_req_batch(vq, &submit_list); > vq = this_vq; similarly > @@ -1554,6 +1566,87 @@ static int virtblk_probe(struct virtio_device *vdev) > return err; > } > > +static bool virtblk_request_cancel(struct request *rq, void *data) > +{ > + struct virtblk_req *vbr = blk_mq_rq_to_pdu(rq); > + struct virtio_blk *vblk = data; > + struct virtio_blk_vq *vq; > + unsigned long flags; > + > + vq = &vblk->vqs[rq->mq_hctx->queue_num]; > + > + spin_lock_irqsave(&vq->lock, flags); > + > + vbr->in_hdr.status = VIRTIO_BLK_S_IOERR; > + if (blk_mq_request_started(rq) && !blk_mq_request_completed(rq)) > + blk_mq_complete_request(rq); > + > + spin_unlock_irqrestore(&vq->lock, flags); > + return true; > +} > + > +static void virtblk_broken_device_cleanup(struct virtio_blk *vblk) > +{ > + struct request_queue *q = vblk->disk->queue; > + > + if (!virtqueue_is_broken(vblk->vqs[0].vq)) > + return; > + > + /* Start freezing the queue, so that new requests keeps waitng at the > + * door of bio_queue_enter(). We cannot fully freeze the queue because > + * freezed queue is an empty queue and there are pending requests, so > + * only start freezing it. > + */ > + blk_freeze_queue_start(q); > + > + /* When quiescing completes, all ongoing dispatches have completed > + * and no new dispatch will happen towards the driver. > + * This ensures that later when cancel is attempted, then are not > + * getting processed by the queue_rq() or queue_rqs() handlers. > + */ > + blk_mq_quiesce_queue(q); > + > + /* > + * Synchronize with any ongoing VQ callbacks, effectively quiescing > + * the device and preventing it from completing further requests > + * to the block layer. Any outstanding, incomplete requests will be > + * completed by virtblk_request_cancel(). > + */ > + virtio_synchronize_cbs(vblk->vdev); > + > + /* At this point, no new requests can enter the queue_rq() and > + * completion routine will not complete any new requests either for the > + * broken vq. Hence, it is safe to cancel all requests which are > + * started. > + */ > + blk_mq_tagset_busy_iter(&vblk->tag_set, virtblk_request_cancel, vblk); > + blk_mq_tagset_wait_completed_request(&vblk->tag_set); > + > + /* All pending requests are cleaned up. Time to resume so that disk > + * deletion can be smooth. Start the HW queues so that when queue is > + * unquiesced requests can again enter the driver. > + */ > + blk_mq_start_stopped_hw_queues(q, true); > + > + /* Unquiescing will trigger dispatching any pending requests to the > + * driver which has crossed bio_queue_enter() to the driver. > + */ > + blk_mq_unquiesce_queue(q); > + > + /* Wait for all pending dispatches to terminate which may have been > + * initiated after unquiescing. > + */ > + blk_mq_freeze_queue_wait(q); > + > + /* Mark the disk dead so that once queue unfreeze, the requests > + * waiting at the door of bio_queue_enter() can be aborted right away. > + */ > + blk_mark_disk_dead(vblk->disk); > + > + /* Unfreeze the queue so that any waiting requests will be aborted. */ > + blk_mq_unfreeze_queue_nomemrestore(q); > +} > + > static void virtblk_remove(struct virtio_device *vdev) > { > struct virtio_blk *vblk = vdev->priv; > @@ -1561,6 +1654,8 @@ static void virtblk_remove(struct virtio_device *vdev) > /* Make sure no work handler is accessing the device. */ > flush_work(&vblk->config_work); > > + virtblk_broken_device_cleanup(vblk); > + > del_gendisk(vblk->disk); > blk_mq_free_tag_set(&vblk->tag_set); > > -- > 2.34.1

3 months, 4 weeks

2
8
0 0

FAILED: patch "[PATCH] drm/amdgpu: read back register after written for VCN v4.0.5" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x ee7360fc27d6045510f8fe459b5649b2af27811a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025052140-handsaw-train-2343@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ee7360fc27d6045510f8fe459b5649b2af27811a Mon Sep 17 00:00:00 2001 From: "David (Ming Qiang) Wu" <David.Wu3(a)amd.com> Date: Mon, 12 May 2025 15:14:43 -0400 Subject: [PATCH] drm/amdgpu: read back register after written for VCN v4.0.5 On VCN v4.0.5 there is a race condition where the WPTR is not updated after starting from idle when doorbell is used. Adding register read-back after written at function end is to ensure all register writes are done before they can be used. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12528 Signed-off-by: David (Ming Qiang) Wu <David.Wu3(a)amd.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Tested-by: Mario Limonciello <mario.limonciello(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Ruijing Dong <ruijing.dong(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 07c9db090b86e5211188e1b351303fbc673378cf) Cc: stable(a)vger.kernel.org diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c index a1171e6152ed..f11df9c2ec13 100644 --- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c @@ -1023,6 +1023,10 @@ static int vcn_v4_0_5_start_dpg_mode(struct amdgpu_vcn_inst *vinst, ring->doorbell_index << VCN_RB1_DB_CTRL__OFFSET__SHIFT | VCN_RB1_DB_CTRL__EN_MASK); + /* Keeping one read-back to ensure all register writes are done, otherwise + * it may introduce race conditions */ + RREG32_SOC15(VCN, inst_idx, regVCN_RB1_DB_CTRL); + return 0; } @@ -1205,6 +1209,10 @@ static int vcn_v4_0_5_start(struct amdgpu_vcn_inst *vinst) WREG32_SOC15(VCN, i, regVCN_RB_ENABLE, tmp); fw_shared->sq.queue_mode &= ~(FW_QUEUE_RING_RESET | FW_QUEUE_DPG_HOLD_OFF); + /* Keeping one read-back to ensure all register writes are done, otherwise + * it may introduce race conditions */ + RREG32_SOC15(VCN, i, regVCN_RB_ENABLE); + return 0; }

3 months, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] drm/amdgpu: read back register after written for VCN v4.0.5" failed to apply to 6.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.14.y git checkout FETCH_HEAD git cherry-pick -x ee7360fc27d6045510f8fe459b5649b2af27811a # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025052139-turkey-gumminess-1680@gregkh' --subject-prefix 'PATCH 6.14.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From ee7360fc27d6045510f8fe459b5649b2af27811a Mon Sep 17 00:00:00 2001 From: "David (Ming Qiang) Wu" <David.Wu3(a)amd.com> Date: Mon, 12 May 2025 15:14:43 -0400 Subject: [PATCH] drm/amdgpu: read back register after written for VCN v4.0.5 On VCN v4.0.5 there is a race condition where the WPTR is not updated after starting from idle when doorbell is used. Adding register read-back after written at function end is to ensure all register writes are done before they can be used. Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12528 Signed-off-by: David (Ming Qiang) Wu <David.Wu3(a)amd.com> Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> Tested-by: Mario Limonciello <mario.limonciello(a)amd.com> Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Ruijing Dong <ruijing.dong(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 07c9db090b86e5211188e1b351303fbc673378cf) Cc: stable(a)vger.kernel.org diff --git a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c index a1171e6152ed..f11df9c2ec13 100644 --- a/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c +++ b/drivers/gpu/drm/amd/amdgpu/vcn_v4_0_5.c @@ -1023,6 +1023,10 @@ static int vcn_v4_0_5_start_dpg_mode(struct amdgpu_vcn_inst *vinst, ring->doorbell_index << VCN_RB1_DB_CTRL__OFFSET__SHIFT | VCN_RB1_DB_CTRL__EN_MASK); + /* Keeping one read-back to ensure all register writes are done, otherwise + * it may introduce race conditions */ + RREG32_SOC15(VCN, inst_idx, regVCN_RB1_DB_CTRL); + return 0; } @@ -1205,6 +1209,10 @@ static int vcn_v4_0_5_start(struct amdgpu_vcn_inst *vinst) WREG32_SOC15(VCN, i, regVCN_RB_ENABLE, tmp); fw_shared->sq.queue_mode &= ~(FW_QUEUE_RING_RESET | FW_QUEUE_DPG_HOLD_OFF); + /* Keeping one read-back to ensure all register writes are done, otherwise + * it may introduce race conditions */ + RREG32_SOC15(VCN, i, regVCN_RB_ENABLE); + return 0; }

3 months, 4 weeks

1
0
0 0

FAILED: patch "[PATCH] drm/amd/display: Defer BW-optimization-blocked DRR" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 874697e127931bf50a37ce9d96ee80f3a08a0c38 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025051956-disdain-foyer-a53c@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 874697e127931bf50a37ce9d96ee80f3a08a0c38 Mon Sep 17 00:00:00 2001 From: John Olender <john.olender(a)gmail.com> Date: Wed, 16 Apr 2025 02:54:26 -0400 Subject: [PATCH] drm/amd/display: Defer BW-optimization-blocked DRR adjustments [Why & How] Instead of dropping DRR updates, defer them. This fixes issues where monitor continues to see incorrect refresh rate after VRR was turned off by userspace. Fixes: 32953485c558 ("drm/amd/display: Do not update DRR while BW optimizations pending") Link: https://gitlab.freedesktop.org/drm/amd/-/issues/3546 Reviewed-by: Sun peng Li <sunpeng.li(a)amd.com> Signed-off-by: John Olender <john.olender(a)gmail.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai(a)amd.com> Signed-off-by: Ray Wu <ray.wu(a)amd.com> Tested-by: Daniel Wheeler <daniel.wheeler(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 53761b7ecd83e6fbb9f2206f8c980a6aa308c844) Cc: stable(a)vger.kernel.org diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 1525c408d452..cc01b9c68b47 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -372,6 +372,8 @@ get_crtc_by_otg_inst(struct amdgpu_device *adev, static inline bool is_dc_timing_adjust_needed(struct dm_crtc_state *old_state, struct dm_crtc_state *new_state) { + if (new_state->stream->adjust.timing_adjust_pending) + return true; if (new_state->freesync_config.state == VRR_STATE_ACTIVE_FIXED) return true; else if (amdgpu_dm_crtc_vrr_active(old_state) != amdgpu_dm_crtc_vrr_active(new_state)) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c index 28d1353f403d..ba4ce8a63158 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c @@ -439,9 +439,12 @@ bool dc_stream_adjust_vmin_vmax(struct dc *dc, * Don't adjust DRR while there's bandwidth optimizations pending to * avoid conflicting with firmware updates. */ - if (dc->ctx->dce_version > DCE_VERSION_MAX) - if (dc->optimized_required || dc->wm_optimized_required) + if (dc->ctx->dce_version > DCE_VERSION_MAX) { + if (dc->optimized_required || dc->wm_optimized_required) { + stream->adjust.timing_adjust_pending = true; return false; + } + } dc_exit_ips_for_hw_access(dc); @@ -3168,7 +3171,8 @@ static void copy_stream_update_to_stream(struct dc *dc, if (update->crtc_timing_adjust) { if (stream->adjust.v_total_min != update->crtc_timing_adjust->v_total_min || - stream->adjust.v_total_max != update->crtc_timing_adjust->v_total_max) + stream->adjust.v_total_max != update->crtc_timing_adjust->v_total_max || + stream->adjust.timing_adjust_pending) update->crtc_timing_adjust->timing_adjust_pending = true; stream->adjust = *update->crtc_timing_adjust; update->crtc_timing_adjust->timing_adjust_pending = false;

3 months, 4 weeks

2
1
0 0

Random Crashes in Linux Kernel 6.1.139 on Intel Cascadelake/Icelake Due to ITS Mitigation

by Jinpu Wang

Hi Folks, Bug Description: When running Linux kernel version 6.1.139 on Intel Cascadelake/Icelake processors, systems experience random crashes related to mitigation. These crashes do not occur when booted with indirect_target_selection=off or when using kernel version 6.12.29. The crashes manifest as page faults leading to a kernel panic. System Details: Kernel Version: 6.1.139 or 6.1.118 with the ITS migration patches from 6.1.139 Hardware: Intel Cascadelake/Icelake Steps to Reproduce: Boot a system with Intel Cascadelake/Icelake processors using Linux kernel 6.1.139. Allow the system to run standard operations; crashes appear randomly. Notice that crashes do not occur when booted with indirect_target_selection=off. also works fine on Intel servers with Broadwell or Skylake CPU linux kernel 6.1.139 crash due to its mitigation on Intel Cascadelake/Icelake, the crash seems random, eg I've seen crashing like below: May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.207823] BUG: unable to handle page fault for address: ff1ac0d89d45f8c0 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.212762] #PF: supervisor write access in kernel mode May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.217741] #PF: error_code(0x0003) - permissions violation May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.222708] PGD 5341c01067 P4D 5341c02067 PUD 211835063 PMD 21d44f063 PTE 800000021d45f161 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.227831] Oops: 0003 [#1] PREEMPT SMP May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.233002] CPU: 12 PID: 0 Comm: swapper/12 Kdump: loaded Tainted: G O 6.1.139-pserver #6.1.139-1+feature+linux+6.1.y+20250521.1015+45a526cf~deb12 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.244731] Hardware name: Dell Inc. PowerEdge R650/0PYXKY, BIOS 1.9.2 11/17/2022 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.250583] RIP: 0010:__build_skb_around+0x79/0xc0 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.256492] Code: 00 00 00 00 89 85 bc 00 00 00 66 89 95 b6 00 00 00 66 89 8d b2 00 00 00 65 8b 15 c2 5b 90 48 48 8d 34 03 66 89 95 a0 00 00 00 <48> c7 06 00 00 00 00 48 c7 46 08 00 00 00 00 48 c7 46 10 00 00 00 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.269200] RSP: 0018:ff409de44cdf4d28 EFLAGS: 00010206 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.275492] RAX: 00000000000006c0 RBX: ff1ac0d89d45f200 RCX: 00000000ffffffff May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.281987] RDX: 000000000000000c RSI: ff1ac0d89d45f8c0 RDI: ff1ac0d7886a8000 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.288943] RBP: ff1ac0d7886a8000 R08: 0000000000000006 R09: ff1ac11708ffc0b8 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.295838] R10: ffffffffb86060c0 R11: ff1ac0d8c02d7000 R12: ff1ac0d89d45f200 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.302796] R13: ff1ac0d839a20000 R14: ff1ac0d89d1241d0 R15: 0000000000000000 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.309496] FS: 0000000000000000(0000) GS:ff1ac116fef80000(0000) knlGS:0000000000000000 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.315978] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.322411] CR2: ff1ac0d89d45f8c0 CR3: 000000534060a005 CR4: 0000000000771ee0 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.329030] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.336289] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.343624] PKRU: 55555554 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.350175] Call Trace: May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.356777] <IRQ> May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.363585] build_skb+0x41/0xe0 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.370198] mlx5e_skb_from_cqe_nonlinear+0x20a/0x3b0 [mlx5_core] May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.377107] mlx5i_handle_rx_cqe+0x311/0x450 [mlx5_core] May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.384273] mlx5e_poll_rx_cq+0x437/0x450 [mlx5_core] May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.392409] mlx5e_napi_poll+0xe4/0x710 [mlx5_core] May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.399293] __napi_poll+0x28/0x160 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.406107] net_rx_action+0x29c/0x2f0 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.412790] handle_softirqs+0xcf/0x270 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.419895] irq_exit_rcu+0x85/0xb0 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.427245] common_interrupt+0x82/0xa0 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.434181] </IRQ> May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.442032] <TASK> May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.448577] asm_common_interrupt+0x22/0x40 May 21 13:03:00 ps404a-62.stg.profitbricks.net >>> [ 241.455431] RIP: 0010:cpuidle_enter_state+0xd8/0x420 and below: kern.alert: May 21 05:59:31 ps404a-1 kernel: [ 35.775609] #PF: error_code(0x0003) - permissions violation kern.info: May 21 05:59:31 ps404a-1 kernel: [ 35.775740] PGD 251ac01067 P4D 251ac01067 PUD 1b17dd063 PMD 6098b1f063 PTE 8000000153faf161 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.775910] Oops: 0003 [#1] PREEMPT SMP kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.776036] CPU: 54 PID: 3109 Comm: (spawn) Tainted: G O 6.1.118-pserver #6.1.118-9+develop+20250520.1233+48c89f78~deb 12 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.776218] Hardware name: RAUSCH CoreVPS-Gen2-STG/X11DDW-NT, BIOS 3.3 02/21/2020 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.776382] RIP: 0010:__tlb_remove_page_size+0x64/0x90 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.776515] Code: c3 cc cc cc cc 83 7f 1c 13 74 39 31 f6 bf 00 28 00 00 e8 3f 27 01 00 48 85 c0 74 28 48 b9 00 00 00 00 fe 01 00 00 83 43 1c 01 <48> c7 00 00 00 00 00 48 89 48 08 48 8b 53 20 48 89 02 48 89 43 20 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.776746] RSP: 0018:ffffb15a5d563a70 EFLAGS: 00010202 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.776876] RAX: ffff8ad4d3faf000 RBX: ffffb15a5d563c88 RCX: 000001fe00000000 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.777013] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b3240b317c0 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.777149] RBP: 000055a0e8f5f000 R08: 0000000000000100 R09: 000055a0e9011fff kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.777285] R10: ffffb15a5d563a08 R11: 0000000000000025 R12: ffffeff344443300 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.777421] R13: ffffb15a5d563b90 R14: ffff8ad50c2faaf8 R15: 00000001110cc025 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.777557] FS: 0000000000000000(0000) GS:ffff8b3240b00000(0000) knlGS:0000000000000000 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.777724] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.777855] CR2: ffff8ad4d3faf000 CR3: 000000018c2f8002 CR4: 00000000007706e0 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.777991] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.778126] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.778262] PKRU: 55555554 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.778382] Call Trace: kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.778502] <TASK> kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.778621] ? __die_body.cold+0x1a/0x1f kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.778749] ? page_fault_oops+0x15a/0x2b0 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.778875] ? search_module_extables+0x15/0x60 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.779004] ? search_bpf_extables+0x5b/0x80 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.779150] ? exc_page_fault+0x8d/0x120 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.779277] ? asm_exc_page_fault+0x22/0x30 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.779536] unmap_page_range+0x8f0/0x1370 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.779667] unmap_vmas+0xea/0x180 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.779794] exit_mmap+0xcb/0x2e0 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.779919] __mmput+0x3d/0x110 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.780045] begin_new_exec+0x46f/0xaf0 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.780173] ? load_elf_phdrs+0x6c/0xc0 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.780312] load_elf_binary+0x2c2/0x1750 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.780438] ? __kernel_read+0x195/0x290 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.780564] bprm_execve+0x27f/0x650 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.780689] do_execveat_common.isra.0+0x1ad/0x220 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.780818] __x64_sys_execve+0x32/0x40 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.780944] do_syscall_64+0x34/0x80 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.781070] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.781200] RIP: 0033:0x7f1d66e70ad7 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.781325] Code: Unable to access opcode bytes at 0x7f1d66e70aad. kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.789385] RSP: 002b:00007ffceeb31338 EFLAGS: 00000206 ORIG_RAX: 000000000000003b kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.789552] RAX: ffffffffffffffda RBX: 000055a11a55e4b0 RCX: 00007f1d66e70ad7 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.789688] RDX: 000055a11a50f200 RSI: 000055a11a6c2d60 RDI: 000055a11a5748c0 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.789825] RBP: 00007ffceeb31570 R08: 0000000000000007 R09: 000055a11a6b1fa0 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.789962] R10: 0000000000000000 R11: 0000000000000206 R12: 00007ffceeb35570 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.790098] R13: 000000000aba9500 R14: 00007ffceeb313b0 R15: 000055a11a6c2d60 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.790237] </TASK> kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.790367] Modules linked in: mei watchdog led_class pcc_cpufreq(-) dca acpi_pad button andbd_shared(O+) 8021q garp stp mrp llc dm_mod dax fuse ip_tables x_tables autofs4 loop raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 linear md_mod mlx5_core i2c_i801 crc32c_intel xhci_pci mlxfw i2c_smbus i40e lpc_ich i2c_core mfd_core xhci_hcd kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.790742] CR2: ffff8ad4d3faf000 kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 35.790864] ---[ end trace 0000000000000000 ]--- kern.warning: May 21 05:59:31 ps404a-1 kernel: [ 36.457953] RIP: 0010:__tlb_remove_page_size+0x64/0x90 Any idea what went wrong and how to fix it? Thanks! Jinpu Wang

3 months, 4 weeks

1
0
0 0

[PATCH 0/2] usb: usbtmc: Fix read/get_stb and timeout in get_stb

by Dave Penkler

Patch 1: Fixes a regression introduced by a previous commit where the changed return value of usbtmc_get_stb caused usbtmc488_ioctl_read_stb and the USBTMC_IOCTL_GET_STB ioctl to fail. Patch 2: Fixes the units of the timeout value passed to wait_event_interruptible_timeout in usbtmc_get_stb. Dave Penkler (2): usb: usbtmc: Fix read_stb function and get_stb ioctl usb: usbtmc: Fix timeout value in get_stb drivers/usb/class/usbtmc.c | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-) -- 2.49.0

3 months, 4 weeks

1
3
0 0

patch "iio: adc: ad7944: mask high bits on direct read" added to char-misc-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: ad7944: mask high bits on direct read to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. From 7cdfbc0113d087348b8e65dd79276d0f57b89a10 Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Mon, 5 May 2025 13:28:40 -0500 Subject: iio: adc: ad7944: mask high bits on direct read MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Apply a mask to the raw value received over the SPI bus for unsigned direct reads. As we found recently, SPI controllers may not set unused bits to 0 when reading with bits_per_word != {8,16,32}. The ad7944 uses bits_per_word of 14 and 18, so we need to mask the value to be sure we returning the correct value to userspace during a direct read. Fixes: d1efcf8871db ("iio: adc: ad7944: add driver for AD7944/AD7985/AD7986") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Reviewed-by: Nuno Sá <nuno.sa(a)analog.com> Link: https://patch.msgid.link/20250505-iio-adc-ad7944-max-high-bits-on-direct-re… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7944.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iio/adc/ad7944.c b/drivers/iio/adc/ad7944.c index 2f949fe55873..37a137bd8357 100644 --- a/drivers/iio/adc/ad7944.c +++ b/drivers/iio/adc/ad7944.c @@ -377,6 +377,8 @@ static int ad7944_single_conversion(struct ad7944_adc *adc, if (chan->scan_type.sign == 's') *val = sign_extend32(*val, chan->scan_type.realbits - 1); + else + *val &= GENMASK(chan->scan_type.realbits - 1, 0); return IIO_VAL_INT; } -- 2.49.0

3 months, 4 weeks

1
0
0 0

patch "iio: imu: inv_icm42600: Fix temperature calculation" added to char-misc-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: imu: inv_icm42600: Fix temperature calculation to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. From e2f820014239df9360064079ae93f838ff3b7f8c Mon Sep 17 00:00:00 2001 From: Sean Nyekjaer <sean(a)geanix.com> Date: Fri, 2 May 2025 11:37:26 +0200 Subject: iio: imu: inv_icm42600: Fix temperature calculation >From the documentation: "offset to be added to <type>[Y]_raw prior toscaling by <type>[Y]_scale" Offset should be applied before multiplying scale, so divide offset by scale to make this correct. Fixes: bc3eb0207fb5 ("iio: imu: inv_icm42600: add temperature sensor support") Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> Link: https://patch.msgid.link/20250502-imu-v1-1-129b8391a4e3@geanix.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c index 213cce1c3111..91f0f381082b 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c @@ -67,16 +67,18 @@ int inv_icm42600_temp_read_raw(struct iio_dev *indio_dev, return IIO_VAL_INT; /* * T°C = (temp / 132.48) + 25 - * Tm°C = 1000 * ((temp * 100 / 13248) + 25) + * Tm°C = 1000 * ((temp / 132.48) + 25) + * Tm°C = 7.548309 * temp + 25000 + * Tm°C = (temp + 3312) * 7.548309 * scale: 100000 / 13248 ~= 7.548309 - * offset: 25000 + * offset: 3312 */ case IIO_CHAN_INFO_SCALE: *val = 7; *val2 = 548309; return IIO_VAL_INT_PLUS_MICRO; case IIO_CHAN_INFO_OFFSET: - *val = 25000; + *val = 3312; return IIO_VAL_INT; default: return -EINVAL; -- 2.49.0

3 months, 4 weeks

1
0
0 0

patch "iio: adc: ad7606_spi: fix reg write value mask" added to char-misc-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: ad7606_spi: fix reg write value mask to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. From 89944d88f8795c6c89b9514cb365998145511cd4 Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Mon, 28 Apr 2025 20:55:34 -0500 Subject: iio: adc: ad7606_spi: fix reg write value mask Fix incorrect value mask for register write. Register values are 8-bit, not 9. If this function was called with a value > 0xFF and an even addr, it would cause writing to the next register. Fixes: f2a22e1e172f ("iio: adc: ad7606: Add support for software mode for ad7616") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Reviewed-by: Angelo Dureghello <adureghello(a)baylibre.com> Link: https://patch.msgid.link/20250428-iio-adc-ad7606_spi-fix-write-value-mask-v… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7606_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/ad7606_spi.c b/drivers/iio/adc/ad7606_spi.c index 179115e90988..b37458ce3c70 100644 --- a/drivers/iio/adc/ad7606_spi.c +++ b/drivers/iio/adc/ad7606_spi.c @@ -155,7 +155,7 @@ static int ad7606_spi_reg_write(struct ad7606_state *st, struct spi_device *spi = to_spi_device(st->dev); st->d16[0] = cpu_to_be16((st->bops->rd_wr_cmd(addr, 1) << 8) | - (val & 0x1FF)); + (val & 0xFF)); return spi_write(spi, &st->d16[0], sizeof(st->d16[0])); } -- 2.49.0

3 months, 4 weeks

1
0
0 0

patch "iio: adc: ad7173: fix compiling without gpiolib" added to char-misc-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: ad7173: fix compiling without gpiolib to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. From c553aa1b03719400a30d9387477190d4743fc1de Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Tue, 22 Apr 2025 15:12:27 -0500 Subject: iio: adc: ad7173: fix compiling without gpiolib Fix compiling the ad7173 driver when CONFIG_GPIOLIB is not set by selecting GPIOLIB to be always enabled and remove the #if. Commit 031bdc8aee01 ("iio: adc: ad7173: add calibration support") placed unrelated code in the middle of the #if IS_ENABLED(CONFIG_GPIOLIB) block which caused the reported compile error. However, later commit 7530ed2aaa3f ("iio: adc: ad7173: add openwire detection support for single conversions") makes use of the gpio regmap even when we aren't providing gpio controller support. So it makes more sense to always enable GPIOLIB rather than trying to make it optional. Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202504220824.HVrTVov1-lkp@intel.com/ Fixes: 031bdc8aee01 ("iio: adc: ad7173: add calibration support") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250422-iio-adc-ad7173-fix-compile-without-gpioli… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/Kconfig | 5 +++-- drivers/iio/adc/ad7173.c | 15 +-------------- 2 files changed, 4 insertions(+), 16 deletions(-) diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 6529df1a498c..ba746754a816 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -129,8 +129,9 @@ config AD7173 tristate "Analog Devices AD7173 driver" depends on SPI_MASTER select AD_SIGMA_DELTA - select GPIO_REGMAP if GPIOLIB - select REGMAP_SPI if GPIOLIB + select GPIOLIB + select GPIO_REGMAP + select REGMAP_SPI help Say yes here to build support for Analog Devices AD7173 and similar ADC Currently supported models: diff --git a/drivers/iio/adc/ad7173.c b/drivers/iio/adc/ad7173.c index 69de5886474c..b3e6bd2a55d7 100644 --- a/drivers/iio/adc/ad7173.c +++ b/drivers/iio/adc/ad7173.c @@ -230,10 +230,8 @@ struct ad7173_state { unsigned long long *config_cnts; struct clk *ext_clk; struct clk_hw int_clk_hw; -#if IS_ENABLED(CONFIG_GPIOLIB) struct regmap *reg_gpiocon_regmap; struct gpio_regmap *gpio_regmap; -#endif }; static unsigned int ad4115_sinc5_data_rates[] = { @@ -288,8 +286,6 @@ static const char *const ad7173_clk_sel[] = { "ext-clk", "xtal" }; -#if IS_ENABLED(CONFIG_GPIOLIB) - static const struct regmap_range ad7173_range_gpio[] = { regmap_reg_range(AD7173_REG_GPIO, AD7173_REG_GPIO), }; @@ -543,12 +539,6 @@ static int ad7173_gpio_init(struct ad7173_state *st) return 0; } -#else -static int ad7173_gpio_init(struct ad7173_state *st) -{ - return 0; -} -#endif /* CONFIG_GPIOLIB */ static struct ad7173_state *ad_sigma_delta_to_ad7173(struct ad_sigma_delta *sd) { @@ -1797,10 +1787,7 @@ static int ad7173_probe(struct spi_device *spi) if (ret) return ret; - if (IS_ENABLED(CONFIG_GPIOLIB)) - return ad7173_gpio_init(st); - - return 0; + return ad7173_gpio_init(st); } static const struct of_device_id ad7173_of_match[] = { -- 2.49.0

3 months, 4 weeks

1
0
0 0

patch "iio: adc: ad7606: fix raw read for 18-bit chips" added to char-misc-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: ad7606: fix raw read for 18-bit chips to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. From 3f5fd1717ae9497215f22aa748fc2c09df88b0e3 Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Fri, 2 May 2025 10:04:30 -0500 Subject: iio: adc: ad7606: fix raw read for 18-bit chips Fix 18-bit raw read for 18-bit chips by applying a mask to the value we receive from the SPI controller. SPI controllers either return 1, 2 or 4 bytes per word depending on the bits_per_word. For 16-bit chips, there was no problem since they raw data fit exactly in the 2 bytes received from the SPI controller. But now that we have 18-bit chips and we are using bits_per_word = 18, we cannot assume that the extra bits in the 32-bit word are always zero. In fact, with the AXI SPI Engine controller, these bits are not always zero which caused the raw values to read 10s of 1000s of volts instead of the correct value. Therefore, we need to mask the value we receive from the SPI controller to ensure that only the 18 bits of real data are used. Fixes: f3838e934dff ("iio: adc: ad7606: add support for AD7606C-{16,18} parts") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250502-iio-adc-ad7606-fix-raw-read-for-18-bit-ch… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7606.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c index 703556eb7257..8ed65a35b486 100644 --- a/drivers/iio/adc/ad7606.c +++ b/drivers/iio/adc/ad7606.c @@ -727,17 +727,16 @@ static int ad7606_scan_direct(struct iio_dev *indio_dev, unsigned int ch, goto error_ret; chan = &indio_dev->channels[ch + 1]; - if (chan->scan_type.sign == 'u') { - if (realbits > 16) - *val = st->data.buf32[ch]; - else - *val = st->data.buf16[ch]; - } else { - if (realbits > 16) - *val = sign_extend32(st->data.buf32[ch], realbits - 1); - else - *val = sign_extend32(st->data.buf16[ch], realbits - 1); - } + + if (realbits > 16) + *val = st->data.buf32[ch]; + else + *val = st->data.buf16[ch]; + + *val &= GENMASK(realbits - 1, 0); + + if (chan->scan_type.sign == 's') + *val = sign_extend32(*val, realbits - 1); error_ret: if (!st->gpio_convst) { -- 2.49.0

3 months, 4 weeks

1
0
0 0

patch "iio: adc: ad7944: mask high bits on direct read" added to char-misc-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: ad7944: mask high bits on direct read to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the char-misc-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 7cdfbc0113d087348b8e65dd79276d0f57b89a10 Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Mon, 5 May 2025 13:28:40 -0500 Subject: iio: adc: ad7944: mask high bits on direct read MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Apply a mask to the raw value received over the SPI bus for unsigned direct reads. As we found recently, SPI controllers may not set unused bits to 0 when reading with bits_per_word != {8,16,32}. The ad7944 uses bits_per_word of 14 and 18, so we need to mask the value to be sure we returning the correct value to userspace during a direct read. Fixes: d1efcf8871db ("iio: adc: ad7944: add driver for AD7944/AD7985/AD7986") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Reviewed-by: Nuno Sá <nuno.sa(a)analog.com> Link: https://patch.msgid.link/20250505-iio-adc-ad7944-max-high-bits-on-direct-re… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7944.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/iio/adc/ad7944.c b/drivers/iio/adc/ad7944.c index 2f949fe55873..37a137bd8357 100644 --- a/drivers/iio/adc/ad7944.c +++ b/drivers/iio/adc/ad7944.c @@ -377,6 +377,8 @@ static int ad7944_single_conversion(struct ad7944_adc *adc, if (chan->scan_type.sign == 's') *val = sign_extend32(*val, chan->scan_type.realbits - 1); + else + *val &= GENMASK(chan->scan_type.realbits - 1, 0); return IIO_VAL_INT; } -- 2.49.0

3 months, 4 weeks

1
0
0 0

patch "iio: imu: inv_icm42600: Fix temperature calculation" added to char-misc-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: imu: inv_icm42600: Fix temperature calculation to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the char-misc-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From e2f820014239df9360064079ae93f838ff3b7f8c Mon Sep 17 00:00:00 2001 From: Sean Nyekjaer <sean(a)geanix.com> Date: Fri, 2 May 2025 11:37:26 +0200 Subject: iio: imu: inv_icm42600: Fix temperature calculation >From the documentation: "offset to be added to <type>[Y]_raw prior toscaling by <type>[Y]_scale" Offset should be applied before multiplying scale, so divide offset by scale to make this correct. Fixes: bc3eb0207fb5 ("iio: imu: inv_icm42600: add temperature sensor support") Signed-off-by: Sean Nyekjaer <sean(a)geanix.com> Acked-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> Link: https://patch.msgid.link/20250502-imu-v1-1-129b8391a4e3@geanix.com Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c index 213cce1c3111..91f0f381082b 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c @@ -67,16 +67,18 @@ int inv_icm42600_temp_read_raw(struct iio_dev *indio_dev, return IIO_VAL_INT; /* * T°C = (temp / 132.48) + 25 - * Tm°C = 1000 * ((temp * 100 / 13248) + 25) + * Tm°C = 1000 * ((temp / 132.48) + 25) + * Tm°C = 7.548309 * temp + 25000 + * Tm°C = (temp + 3312) * 7.548309 * scale: 100000 / 13248 ~= 7.548309 - * offset: 25000 + * offset: 3312 */ case IIO_CHAN_INFO_SCALE: *val = 7; *val2 = 548309; return IIO_VAL_INT_PLUS_MICRO; case IIO_CHAN_INFO_OFFSET: - *val = 25000; + *val = 3312; return IIO_VAL_INT; default: return -EINVAL; -- 2.49.0

3 months, 4 weeks

1
0
0 0

patch "iio: adc: ad7606_spi: fix reg write value mask" added to char-misc-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: ad7606_spi: fix reg write value mask to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the char-misc-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 89944d88f8795c6c89b9514cb365998145511cd4 Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Mon, 28 Apr 2025 20:55:34 -0500 Subject: iio: adc: ad7606_spi: fix reg write value mask Fix incorrect value mask for register write. Register values are 8-bit, not 9. If this function was called with a value > 0xFF and an even addr, it would cause writing to the next register. Fixes: f2a22e1e172f ("iio: adc: ad7606: Add support for software mode for ad7616") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Reviewed-by: Angelo Dureghello <adureghello(a)baylibre.com> Link: https://patch.msgid.link/20250428-iio-adc-ad7606_spi-fix-write-value-mask-v… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7606_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iio/adc/ad7606_spi.c b/drivers/iio/adc/ad7606_spi.c index 179115e90988..b37458ce3c70 100644 --- a/drivers/iio/adc/ad7606_spi.c +++ b/drivers/iio/adc/ad7606_spi.c @@ -155,7 +155,7 @@ static int ad7606_spi_reg_write(struct ad7606_state *st, struct spi_device *spi = to_spi_device(st->dev); st->d16[0] = cpu_to_be16((st->bops->rd_wr_cmd(addr, 1) << 8) | - (val & 0x1FF)); + (val & 0xFF)); return spi_write(spi, &st->d16[0], sizeof(st->d16[0])); } -- 2.49.0

3 months, 4 weeks

1
0
0 0

patch "iio: adc: ad7606: fix raw read for 18-bit chips" added to char-misc-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: ad7606: fix raw read for 18-bit chips to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the char-misc-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 3f5fd1717ae9497215f22aa748fc2c09df88b0e3 Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Fri, 2 May 2025 10:04:30 -0500 Subject: iio: adc: ad7606: fix raw read for 18-bit chips Fix 18-bit raw read for 18-bit chips by applying a mask to the value we receive from the SPI controller. SPI controllers either return 1, 2 or 4 bytes per word depending on the bits_per_word. For 16-bit chips, there was no problem since they raw data fit exactly in the 2 bytes received from the SPI controller. But now that we have 18-bit chips and we are using bits_per_word = 18, we cannot assume that the extra bits in the 32-bit word are always zero. In fact, with the AXI SPI Engine controller, these bits are not always zero which caused the raw values to read 10s of 1000s of volts instead of the correct value. Therefore, we need to mask the value we receive from the SPI controller to ensure that only the 18 bits of real data are used. Fixes: f3838e934dff ("iio: adc: ad7606: add support for AD7606C-{16,18} parts") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250502-iio-adc-ad7606-fix-raw-read-for-18-bit-ch… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/ad7606.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/drivers/iio/adc/ad7606.c b/drivers/iio/adc/ad7606.c index 703556eb7257..8ed65a35b486 100644 --- a/drivers/iio/adc/ad7606.c +++ b/drivers/iio/adc/ad7606.c @@ -727,17 +727,16 @@ static int ad7606_scan_direct(struct iio_dev *indio_dev, unsigned int ch, goto error_ret; chan = &indio_dev->channels[ch + 1]; - if (chan->scan_type.sign == 'u') { - if (realbits > 16) - *val = st->data.buf32[ch]; - else - *val = st->data.buf16[ch]; - } else { - if (realbits > 16) - *val = sign_extend32(st->data.buf32[ch], realbits - 1); - else - *val = sign_extend32(st->data.buf16[ch], realbits - 1); - } + + if (realbits > 16) + *val = st->data.buf32[ch]; + else + *val = st->data.buf16[ch]; + + *val &= GENMASK(realbits - 1, 0); + + if (chan->scan_type.sign == 's') + *val = sign_extend32(*val, realbits - 1); error_ret: if (!st->gpio_convst) { -- 2.49.0

3 months, 4 weeks

1
0
0 0

patch "iio: adc: ad7173: fix compiling without gpiolib" added to char-misc-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: ad7173: fix compiling without gpiolib to my char-misc git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git in the char-misc-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the char-misc-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From c553aa1b03719400a30d9387477190d4743fc1de Mon Sep 17 00:00:00 2001 From: David Lechner <dlechner(a)baylibre.com> Date: Tue, 22 Apr 2025 15:12:27 -0500 Subject: iio: adc: ad7173: fix compiling without gpiolib Fix compiling the ad7173 driver when CONFIG_GPIOLIB is not set by selecting GPIOLIB to be always enabled and remove the #if. Commit 031bdc8aee01 ("iio: adc: ad7173: add calibration support") placed unrelated code in the middle of the #if IS_ENABLED(CONFIG_GPIOLIB) block which caused the reported compile error. However, later commit 7530ed2aaa3f ("iio: adc: ad7173: add openwire detection support for single conversions") makes use of the gpio regmap even when we aren't providing gpio controller support. So it makes more sense to always enable GPIOLIB rather than trying to make it optional. Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202504220824.HVrTVov1-lkp@intel.com/ Fixes: 031bdc8aee01 ("iio: adc: ad7173: add calibration support") Signed-off-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250422-iio-adc-ad7173-fix-compile-without-gpioli… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/Kconfig | 5 +++-- drivers/iio/adc/ad7173.c | 15 +-------------- 2 files changed, 4 insertions(+), 16 deletions(-) diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index 6529df1a498c..ba746754a816 100644 --- a/drivers/iio/adc/Kconfig +++ b/drivers/iio/adc/Kconfig @@ -129,8 +129,9 @@ config AD7173 tristate "Analog Devices AD7173 driver" depends on SPI_MASTER select AD_SIGMA_DELTA - select GPIO_REGMAP if GPIOLIB - select REGMAP_SPI if GPIOLIB + select GPIOLIB + select GPIO_REGMAP + select REGMAP_SPI help Say yes here to build support for Analog Devices AD7173 and similar ADC Currently supported models: diff --git a/drivers/iio/adc/ad7173.c b/drivers/iio/adc/ad7173.c index 69de5886474c..b3e6bd2a55d7 100644 --- a/drivers/iio/adc/ad7173.c +++ b/drivers/iio/adc/ad7173.c @@ -230,10 +230,8 @@ struct ad7173_state { unsigned long long *config_cnts; struct clk *ext_clk; struct clk_hw int_clk_hw; -#if IS_ENABLED(CONFIG_GPIOLIB) struct regmap *reg_gpiocon_regmap; struct gpio_regmap *gpio_regmap; -#endif }; static unsigned int ad4115_sinc5_data_rates[] = { @@ -288,8 +286,6 @@ static const char *const ad7173_clk_sel[] = { "ext-clk", "xtal" }; -#if IS_ENABLED(CONFIG_GPIOLIB) - static const struct regmap_range ad7173_range_gpio[] = { regmap_reg_range(AD7173_REG_GPIO, AD7173_REG_GPIO), }; @@ -543,12 +539,6 @@ static int ad7173_gpio_init(struct ad7173_state *st) return 0; } -#else -static int ad7173_gpio_init(struct ad7173_state *st) -{ - return 0; -} -#endif /* CONFIG_GPIOLIB */ static struct ad7173_state *ad_sigma_delta_to_ad7173(struct ad_sigma_delta *sd) { @@ -1797,10 +1787,7 @@ static int ad7173_probe(struct spi_device *spi) if (ret) return ret; - if (IS_ENABLED(CONFIG_GPIOLIB)) - return ad7173_gpio_init(st); - - return 0; + return ad7173_gpio_init(st); } static const struct of_device_id ad7173_of_match[] = { -- 2.49.0

3 months, 4 weeks

1
0
0 0

[PATCH v 3] usb: dwc2: gadget: Fix enter to hibernation for UTMI+ PHY

by Minas Harutyunyan

For UTMI+ PHY, according to programming guide, first should be set PMUACTV bit then STOPPCLK bit. Otherwise, when the device issues Remote Wakeup, then host notices disconnect instead. For ULPI PHY, above mentioned bits must be set in reversed order: STOPPCLK then PMUACTV. Fixes: 4483ef3c1685 ("usb: dwc2: Add hibernation updates for ULPI PHY") Cc: stable(a)vger.kernel.org Reported-by: Tomasz Mon <tomasz.mon(a)nordicsemi.no> Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com> --- Changes in v3: - Rebased on top of 6.15-rc4 Changes in v2: - Added Cc: stable(a)vger.kernel.org drivers/usb/dwc2/gadget.c | 37 +++++++++++++++++++++++++------------ 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c index 300ea4969f0c..b817002bdee0 100644 --- a/drivers/usb/dwc2/gadget.c +++ b/drivers/usb/dwc2/gadget.c @@ -5383,20 +5383,33 @@ int dwc2_gadget_enter_hibernation(struct dwc2_hsotg *hsotg) if (gusbcfg & GUSBCFG_ULPI_UTMI_SEL) { /* ULPI interface */ gpwrdn |= GPWRDN_ULPI_LATCH_EN_DURING_HIB_ENTRY; - } - dwc2_writel(hsotg, gpwrdn, GPWRDN); - udelay(10); + dwc2_writel(hsotg, gpwrdn, GPWRDN); + udelay(10); - /* Suspend the Phy Clock */ - pcgcctl = dwc2_readl(hsotg, PCGCTL); - pcgcctl |= PCGCTL_STOPPCLK; - dwc2_writel(hsotg, pcgcctl, PCGCTL); - udelay(10); + pcgcctl = dwc2_readl(hsotg, PCGCTL); + pcgcctl |= PCGCTL_STOPPCLK; + dwc2_writel(hsotg, pcgcctl, PCGCTL); + udelay(10); - gpwrdn = dwc2_readl(hsotg, GPWRDN); - gpwrdn |= GPWRDN_PMUACTV; - dwc2_writel(hsotg, gpwrdn, GPWRDN); - udelay(10); + gpwrdn = dwc2_readl(hsotg, GPWRDN); + gpwrdn |= GPWRDN_PMUACTV; + dwc2_writel(hsotg, gpwrdn, GPWRDN); + udelay(10); + } else { + /* UTMI+ Interface */ + dwc2_writel(hsotg, gpwrdn, GPWRDN); + udelay(10); + + gpwrdn = dwc2_readl(hsotg, GPWRDN); + gpwrdn |= GPWRDN_PMUACTV; + dwc2_writel(hsotg, gpwrdn, GPWRDN); + udelay(10); + + pcgcctl = dwc2_readl(hsotg, PCGCTL); + pcgcctl |= PCGCTL_STOPPCLK; + dwc2_writel(hsotg, pcgcctl, PCGCTL); + udelay(10); + } /* Set flag to indicate that we are in hibernation */ hsotg->hibernated = 1; base-commit: b4432656b36e5cc1d50a1f2dc15357543add530e -- 2.41.0

3 months, 4 weeks

2
1
0 0

[PATCH v2] usb: typec: tcpm: apply vbus before data bringup in tcpm_src_attach

by RD Babiera

This patch fixes Type-C compliance test TD 4.7.6 - Try.SNK DRP Connect SNKAS. tVbusON has a limit of 275ms when entering SRC_ATTACHED. Compliance testers can interpret the TryWait.Src to Attached.Src transition after Try.Snk as being in Attached.Src the entire time, so ~170ms is lost to the debounce timer. Setting the data role can be a costly operation in host mode, and when completed after 100ms can cause Type-C compliance test check TD 4.7.5.V.4 to fail. Turn VBUS on before tcpm_set_roles to meet timing requirement. Fixes: f0690a25a140 ("staging: typec: USB Type-C Port Manager (tcpm)") Cc: stable(a)vger.kernel.org Signed-off-by: RD Babiera <rdbabiera(a)google.com> Reviewed-by: Badhri Jagan Sridharan <badhri(a)google.com> Reviewed-by: Heikki Krogerus <heikki.krogerus(a)linux.intel.com> --- Changes since v1: * Rebased on top of usb-linus for v6.15 --- drivers/usb/typec/tcpm/tcpm.c | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c index 8adf6f954633..05c62a1673af 100644 --- a/drivers/usb/typec/tcpm/tcpm.c +++ b/drivers/usb/typec/tcpm/tcpm.c @@ -4353,16 +4353,6 @@ static int tcpm_src_attach(struct tcpm_port *port) tcpm_enable_auto_vbus_discharge(port, true); - ret = tcpm_set_roles(port, true, TYPEC_SOURCE, tcpm_data_role_for_source(port)); - if (ret < 0) - return ret; - - if (port->pd_supported) { - ret = port->tcpc->set_pd_rx(port->tcpc, true); - if (ret < 0) - goto out_disable_mux; - } - /* * USB Type-C specification, version 1.2, * chapter 4.5.2.2.8.1 (Attached.SRC Requirements) @@ -4372,12 +4362,22 @@ static int tcpm_src_attach(struct tcpm_port *port) (polarity == TYPEC_POLARITY_CC2 && port->cc1 == TYPEC_CC_RA)) { ret = tcpm_set_vconn(port, true); if (ret < 0) - goto out_disable_pd; + return ret; } ret = tcpm_set_vbus(port, true); if (ret < 0) goto out_disable_vconn; + + ret = tcpm_set_roles(port, true, TYPEC_SOURCE, tcpm_data_role_for_source(port)); + if (ret < 0) + goto out_disable_vbus; + + if (port->pd_supported) { + ret = port->tcpc->set_pd_rx(port->tcpc, true); + if (ret < 0) + goto out_disable_mux; + } port->pd_capable = false; @@ -4389,14 +4389,14 @@ static int tcpm_src_attach(struct tcpm_port *port) return 0; -out_disable_vconn: - tcpm_set_vconn(port, false); -out_disable_pd: - if (port->pd_supported) - port->tcpc->set_pd_rx(port->tcpc, false); out_disable_mux: tcpm_mux_set(port, TYPEC_STATE_SAFE, USB_ROLE_NONE, TYPEC_ORIENTATION_NONE); +out_disable_vbus: + tcpm_set_vbus(port, false); +out_disable_vconn: + tcpm_set_vconn(port, false); + return ret; } base-commit: 82f2b0b97b36ee3fcddf0f0780a9a0825d52fec3 -- 2.49.0.1045.g170613ef41-goog

3 months, 4 weeks

2
1
0 0

[PATCH] usb: gadget: udc: renesas_usb3: Add null pointer check in usb3_irq_epc_pipe0_setup()

by Wentao Liang

The function usb3_irq_epc_pipe0_setup() calls the function usb3_get_request(), but does not check its return value which is a null pointer if the function fails. This can result in a null pointer dereference. Add a null pointer check for usb3_get_request() to avoid null pointer dereference when the function fails. Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Cc: stable(a)vger.kernel.org # v4.5 Signed-off-by: Wentao Liang <vulab(a)iscas.ac.cn> --- drivers/usb/gadget/udc/renesas_usb3.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/renesas_usb3.c b/drivers/usb/gadget/udc/renesas_usb3.c index fce5c41d9f29..51f2dd8cbf91 100644 --- a/drivers/usb/gadget/udc/renesas_usb3.c +++ b/drivers/usb/gadget/udc/renesas_usb3.c @@ -1920,11 +1920,13 @@ static void usb3_irq_epc_pipe0_setup(struct renesas_usb3 *usb3) { struct usb_ctrlrequest ctrl; struct renesas_usb3_ep *usb3_ep = usb3_get_ep(usb3, 0); + struct renesas_usb3_request *usb3_req = usb3_get_request(usb3_ep); /* Call giveback function if previous transfer is not completed */ + if (!usb3_req) + return; if (usb3_ep->started) - usb3_request_done(usb3_ep, usb3_get_request(usb3_ep), - -ECONNRESET); + usb3_request_done(usb3_ep, usb3_req, -ECONNRESET); usb3_p0_con_clear_buffer(usb3); usb3_get_setup_data(usb3, &ctrl); -- 2.42.0.windows.2

3 months, 4 weeks

2
1
0 0

[PATCH 4/4 v3] crypto: octeontx2: Fix address alignment on CN10KB and CN10KA-B0

by Bharat Bhushan

octeontx2 crypto driver allocates memory using kmalloc/kzalloc, and uses this memory for dma (does dma_map_single()). It assumes that kmalloc/kzalloc will return 128-byte aligned address. But kmalloc/kzalloc returns 8-byte aligned address after below changes: "9382bc44b5f5 arm64: allow kmalloc() caches aligned to the smaller cache_line_size() Memory allocated are used for following purpose: - Input data or scatter list address - 8-Byte alignment - Output data or gather list address - 8-Byte alignment - Completion address - 32-Byte alignment. This patch ensures all addresses are aligned as mentioned above. Signed-off-by: Bharat Bhushan <bbhushan2(a)marvell.com> Cc: <stable(a)vger.kernel.org> #v6.8+ --- v2->v3: - Align DMA memory to ARCH_DMA_MINALIGN as that is mapped as bidirectional v1->v2: - Fixed memory padding size calculation as per review comment .../marvell/octeontx2/otx2_cpt_reqmgr.h | 58 ++++++++++++++----- 1 file changed, 43 insertions(+), 15 deletions(-) diff --git a/drivers/crypto/marvell/octeontx2/otx2_cpt_reqmgr.h b/drivers/crypto/marvell/octeontx2/otx2_cpt_reqmgr.h index 204a31755710..8e95036e91d9 100644 --- a/drivers/crypto/marvell/octeontx2/otx2_cpt_reqmgr.h +++ b/drivers/crypto/marvell/octeontx2/otx2_cpt_reqmgr.h @@ -350,22 +350,47 @@ static inline struct otx2_cpt_inst_info * cn10k_sgv2_info_create(struct pci_dev *pdev, struct otx2_cpt_req_info *req, gfp_t gfp) { - u32 dlen = 0, g_len, sg_len, info_len; - int align = OTX2_CPT_DMA_MINALIGN; + u32 dlen = 0, g_len, s_len, sg_len, info_len; struct otx2_cpt_inst_info *info; - u16 g_sz_bytes, s_sz_bytes; u32 total_mem_len; int i; - g_sz_bytes = ((req->in_cnt + 2) / 3) * - sizeof(struct cn10kb_cpt_sglist_component); - s_sz_bytes = ((req->out_cnt + 2) / 3) * - sizeof(struct cn10kb_cpt_sglist_component); + /* Allocate memory to meet below alignment requirement: + * ---------------------------------- + * | struct otx2_cpt_inst_info | + * | (No alignment required) | + * | -----------------------------| + * | | padding for 8B alignment | + * |----------------------------------| + * | SG List Gather/Input memory | + * | Length = multiple of 32Bytes | + * | Alignment = 8Byte | + * |----------------------------------| + * | SG List Scatter/Output memory | + * | Length = multiple of 32Bytes | + * | Alignment = 8Byte | + * | (padding for below alignment) | + * | -----------------------------| + * | | padding for 32B alignment | + * |----------------------------------| + * | Result response memory | + * ---------------------------------- + */ + + info_len = sizeof(*info); + + g_len = ((req->in_cnt + 2) / 3) * + sizeof(struct cn10kb_cpt_sglist_component); + s_len = ((req->out_cnt + 2) / 3) * + sizeof(struct cn10kb_cpt_sglist_component); + sg_len = g_len + s_len; - g_len = ALIGN(g_sz_bytes, align); - sg_len = ALIGN(g_len + s_sz_bytes, align); - info_len = ALIGN(sizeof(*info), align); - total_mem_len = sg_len + info_len + sizeof(union otx2_cpt_res_s); + /* Allocate extra memory for SG and response address alignment */ + total_mem_len = ALIGN(info_len, ARCH_DMA_MINALIGN) + sg_len; + total_mem_len = ALIGN(total_mem_len, OTX2_CPT_DPTR_RPTR_ALIGN); + total_mem_len += (OTX2_CPT_RES_ADDR_ALIGN - 1) & + ~(OTX2_CPT_DPTR_RPTR_ALIGN - 1); + total_mem_len += sizeof(union otx2_cpt_res_s); info = kzalloc(total_mem_len, gfp); if (unlikely(!info)) @@ -375,7 +400,8 @@ cn10k_sgv2_info_create(struct pci_dev *pdev, struct otx2_cpt_req_info *req, dlen += req->in[i].size; info->dlen = dlen; - info->in_buffer = (u8 *)info + info_len; + info->in_buffer = PTR_ALIGN((u8 *)info + info_len, ARCH_DMA_MINALIGN); + info->out_buffer = info->in_buffer + g_len; info->gthr_sz = req->in_cnt; info->sctr_sz = req->out_cnt; @@ -387,7 +413,7 @@ cn10k_sgv2_info_create(struct pci_dev *pdev, struct otx2_cpt_req_info *req, } if (sgv2io_components_setup(pdev, req->out, req->out_cnt, - &info->in_buffer[g_len])) { + info->out_buffer)) { dev_err(&pdev->dev, "Failed to setup scatter list\n"); goto destroy_info; } @@ -404,8 +430,10 @@ cn10k_sgv2_info_create(struct pci_dev *pdev, struct otx2_cpt_req_info *req, * Get buffer for union otx2_cpt_res_s response * structure and its physical address */ - info->completion_addr = info->in_buffer + sg_len; - info->comp_baddr = info->dptr_baddr + sg_len; + info->completion_addr = PTR_ALIGN((info->in_buffer + sg_len), + OTX2_CPT_RES_ADDR_ALIGN); + info->comp_baddr = ALIGN((info->dptr_baddr + sg_len), + OTX2_CPT_RES_ADDR_ALIGN); return info; -- 2.34.1

3 months, 4 weeks

1
0
0 0

Panic with a lis2dw12 accelerometer

by Maud Spierings

I've just experienced an Issue that I think may be a regression. I'm enabling a device which incorporates a lis2dw12 accelerometer, currently I am running 6.12 lts, so 6.12.29 as of typing this message. My first issue is a Panic: [ 0.281814] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0 [ 0.290626] Mem abort info: [ 0.293465] ESR = 0x0000000096000004 [ 0.297230] EC = 0x25: DABT (current EL), IL = 32 bits [ 0.302558] SET = 0, FnV = 0 [ 0.305619] EA = 0, S1PTW = 0 [ 0.308766] FSC = 0x04: level 0 translation fault [ 0.313649] Data abort info: [ 0.316534] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 0.322032] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 0.327093] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 0.332413] [00000000000000c0] user address but active_mm is swapper [ 0.338774] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 0.345044] Modules linked in: [ 0.348106] CPU: 2 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.12.28-00054-gf24728d836e5 #13 [ 0.356983] Hardware name: GOcontroll Moduline Mini (DT) [ 0.362297] Workqueue: events_unbound deferred_probe_work_func [ 0.368143] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 0.375109] pc : device_set_deferred_probe_reason+0x58/0x84 [ 0.380686] lr : device_set_deferred_probe_reason+0x50/0x84 [ 0.386262] sp : ffff8000816d34d0 [ 0.389577] x29: ffff8000816d34d0 x28: ffff000004099d08 x27: ffff0000040998f0 [ 0.396724] x26: 0000000030a40000 x25: ffff000004099be4 x24: ffff00003fdf2758 [ 0.403870] x23: 000000000000000f x22: ffff8000816d3508 x21: ffff000000260a20 [ 0.411017] x20: ffff00000409a808 x19: ffff800081299db8 x18: ffffffffffffffff [ 0.418163] x17: 00007fff7e57efff x16: ffff8000815ad000 x15: ffff0000002617da [ 0.425309] x14: 0000000000000001 x13: 0a7365696c707075 x12: 7320656c62616e65 [ 0.432454] x11: 0000000669b8cb4b x10: 0000000000000020 x9 : ffff8000816d3590 [ 0.439599] x8 : ffff8000816d3590 x7 : 0000000000000000 x6 : ffff800080fe16a6 [ 0.446745] x5 : ffff000000260a3f x4 : ffff800080fc3912 x3 : 0000000000000000 [ 0.453890] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000000260a20 [ 0.461037] Call trace: [ 0.463485] device_set_deferred_probe_reason+0x58/0x84 [ 0.468715] dev_err_probe+0xa0/0xec [ 0.472296] st_sensors_power_enable+0x50/0x60 [ 0.476748] st_accel_i2c_probe+0x70/0xe0 [ 0.480763] i2c_device_probe+0xfc/0x2d8 [ 0.484692] really_probe+0xc0/0x394 [ 0.488271] __driver_probe_device+0x7c/0x14c [ 0.492631] driver_probe_device+0x3c/0x120 [ 0.496818] __device_attach_driver+0xbc/0x160 [ 0.501265] bus_for_each_drv+0x88/0xe8 [ 0.505108] __device_attach+0xa0/0x1b4 [ 0.508949] device_initial_probe+0x14/0x20 [ 0.513135] bus_probe_device+0xb0/0xbc [ 0.516974] device_add+0x594/0x7a4 [ 0.520469] device_register+0x20/0x3c [ 0.524224] i2c_new_client_device+0x19c/0x3d0 [ 0.528671] of_i2c_register_device+0xd4/0xfc [ 0.533033] of_i2c_register_devices+0x6c/0x140 [ 0.537568] i2c_register_adapter+0x1f4/0x728 [ 0.541929] __i2c_add_numbered_adapter+0x58/0xa8 [ 0.546637] i2c_add_adapter+0xa0/0xd0 [ 0.550389] i2c_add_numbered_adapter+0x2c/0x38 [ 0.554924] i2c_imx_probe+0x2b0/0x6d4 [ 0.558679] platform_probe+0x68/0xdc [ 0.562347] really_probe+0xc0/0x394 [ 0.565926] __driver_probe_device+0x7c/0x14c [ 0.570286] driver_probe_device+0x3c/0x120 [ 0.574473] __device_attach_driver+0xbc/0x160 [ 0.578920] bus_for_each_drv+0x88/0xe8 [ 0.582763] __device_attach+0xa0/0x1b4 [ 0.586602] device_initial_probe+0x14/0x20 [ 0.590790] bus_probe_device+0xb0/0xbc [ 0.594628] deferred_probe_work_func+0xb8/0x11c [ 0.599250] process_one_work+0x180/0x2dc [ 0.603265] worker_thread+0x2c0/0x3e0 [ 0.607017] kthread+0x110/0x120 [ 0.610252] ret_from_fork+0x10/0x20 [ 0.613836] Code: 911a8021 97f9326d f9402681 aa0003f5 (f9406020) [ 0.619931] ---[ end trace 0000000000000000 ]--- [ 0.624551] Kernel panic - not syncing: Oops: Fatal exception [ 0.630299] SMP: stopping secondary CPUs [ 0.634543] Kernel Offset: disabled [ 0.638032] CPU features: 0x00,00000080,00200000,4200420b [ 0.643433] Memory Limit: none It seems that indio_dev->dev is not initialized in st_sensors_power_enable(), this causes an issue when devm_regulator_bulk_get_enable() fails and then calls dev_err_probe with an uninitialized device. To fix this I added: indio_dev->dev = client->dev; just before the call to st_sensors_power_enable() in drivers/iio/accel/st_accel_i2c.c This fixed the kernel panic but showed another issue: 0.440413] sysfs: cannot create duplicate filename '/devices/platform/soc(a)0/30800000.bus/30a40000.i2c/i2c-2/2-0018' [ 0.440422] CPU: 0 UID: 0 PID: 43 Comm: kworker/u16:1 Not tainted 6.12.29+ #6 [ 0.440430] Hardware name: GOcontroll Moduline Mini (DT) [ 0.440435] Workqueue: events_unbound deferred_probe_work_func [ 0.440449] Call trace: [ 0.440452] dump_backtrace+0xd0/0x120 [ 0.440462] show_stack+0x18/0x24 [ 0.440469] dump_stack_lvl+0x60/0x80 [ 0.440478] dump_stack+0x18/0x24 [ 0.440483] sysfs_warn_dup+0x64/0x80 [ 0.440491] sysfs_create_dir_ns+0xf4/0x120 [ 0.440496] kobject_add_internal+0xb4/0x2d0 [ 0.440504] kobject_add+0x9c/0x108 [ 0.440511] device_add+0xb0/0x7a4 [ 0.440519] cdev_device_add+0x50/0xbc [ 0.440525] __iio_device_register+0x718/0x924 [ 0.440535] __devm_iio_device_register+0x28/0x8c [ 0.440542] st_accel_common_probe+0xd4/0xf0 [ 0.440550] st_accel_i2c_probe+0xa0/0xe0 [ 0.440556] i2c_device_probe+0xfc/0x2d8 [ 0.440563] really_probe+0xc0/0x394 [ 0.440568] __driver_probe_device+0x7c/0x14c [ 0.440573] driver_probe_device+0x3c/0x120 [ 0.440578] __device_attach_driver+0xbc/0x160 [ 0.440583] bus_for_each_drv+0x88/0xe8 [ 0.440590] __device_attach+0xa0/0x1b4 [ 0.440595] device_initial_probe+0x14/0x20 [ 0.440601] bus_probe_device+0xb0/0xbc [ 0.440605] deferred_probe_work_func+0xb8/0x11c [ 0.440610] process_one_work+0x180/0x2dc [ 0.440616] worker_thread+0x2c0/0x3e0 [ 0.440621] kthread+0x110/0x120 [ 0.440628] ret_from_fork+0x10/0x20 [ 0.440636] kobject: kobject_add_internal failed for 2-0018 with -EEXIST, don't try to register things with the same name in the same directory. [ 0.453688] st-accel-i2c 2-0018: probe with driver st-accel-i2c failed with error -17 In /sys/bus/i2c/devices I can indeed see 2-0018 present, but it doesn't show up on the iio bus (/sys/bus/iio/devices), so I am guessing somewhere in the driver it registers it before it should, and then again when it should. This is where my ability to fix thing fizzles out and so here I am asking for assistance. Kind regards, Maud

3 months, 4 weeks

2
2
0 0

[PATCH] drm/xe/svm: Fix regression disallowing 64K SVM migration

by Maarten Lankhorst

When changing the condition from >= SZ_64K, it was changed to <= SZ_64K. This disallows migration of 64K, which is the exact minimum allowed. Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/issues/5057 Fixes: a9ac0fa455b0 ("drm/xe: Strict migration policy for atomic SVM faults") Cc: stable(a)vger.kernel.org Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray(a)intel.com> Signed-off-by: Maarten Lankhorst <dev(a)lankhorst.se> --- drivers/gpu/drm/xe/xe_svm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_svm.c b/drivers/gpu/drm/xe/xe_svm.c index 4432685936ed4..a7386334d48c4 100644 --- a/drivers/gpu/drm/xe/xe_svm.c +++ b/drivers/gpu/drm/xe/xe_svm.c @@ -820,7 +820,7 @@ bool xe_svm_range_needs_migrate_to_vram(struct xe_svm_range *range, struct xe_vm return false; } - if (preferred_region_is_vram && range_size <= SZ_64K && !supports_4K_migration(vm->xe)) { + if (preferred_region_is_vram && range_size < SZ_64K && !supports_4K_migration(vm->xe)) { drm_warn(&vm->xe->drm, "Platform doesn't support SZ_4K range migration\n"); return false; } -- 2.45.2

3 months, 4 weeks

2
1
0 0

[PATCH net] hv_netvsc: fix potential deadlock in netvsc_vf_setxdp()

by Saurabh Sengar

The MANA driver's probe registers netdevice via the following call chain: mana_probe() register_netdev() register_netdevice() register_netdevice() calls notifier callback for netvsc driver, holding the netdev mutex via netdev_lock_ops(). Further this netvsc notifier callback end up attempting to acquire the same lock again in dev_xdp_propagate() leading to deadlock. netvsc_netdev_event() netvsc_vf_setxdp() dev_xdp_propagate() This deadlock was not observed so far because net_shaper_ops was never set and this lock in noop in this case. Fix this by using netif_xdp_propagate instead of dev_xdp_propagate to avoid recursive locking in this path. This issue has not observed so far because net_shaper_ops was unset, making the lock path effectively a no-op. To prevent recursive locking and avoid this deadlock, replace dev_xdp_propagate() with netif_xdp_propagate(), which does not acquire the lock again. Also, clean up the unregistration path by removing unnecessary call to netvsc_vf_setxdp(), since unregister_netdevice_many_notify() already performs this cleanup via dev_xdp_uninstall. Fixes: 97246d6d21c2 ("net: hold netdev instance lock during ndo_bpf") Cc: stable(a)vger.kernel.org Signed-off-by: Saurabh Sengar <ssengar(a)linux.microsoft.com> --- drivers/net/hyperv/netvsc_bpf.c | 2 +- drivers/net/hyperv/netvsc_drv.c | 2 -- net/core/dev.c | 1 + 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/hyperv/netvsc_bpf.c b/drivers/net/hyperv/netvsc_bpf.c index e01c5997a551..1dd3755d9e6d 100644 --- a/drivers/net/hyperv/netvsc_bpf.c +++ b/drivers/net/hyperv/netvsc_bpf.c @@ -183,7 +183,7 @@ int netvsc_vf_setxdp(struct net_device *vf_netdev, struct bpf_prog *prog) xdp.command = XDP_SETUP_PROG; xdp.prog = prog; - ret = dev_xdp_propagate(vf_netdev, &xdp); + ret = netif_xdp_propagate(vf_netdev, &xdp); if (ret && prog) bpf_prog_put(prog); diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c index d8b169ac0343..ee3aaf9c10e6 100644 --- a/drivers/net/hyperv/netvsc_drv.c +++ b/drivers/net/hyperv/netvsc_drv.c @@ -2462,8 +2462,6 @@ static int netvsc_unregister_vf(struct net_device *vf_netdev) netdev_info(ndev, "VF unregistering: %s\n", vf_netdev->name); - netvsc_vf_setxdp(vf_netdev, NULL); - reinit_completion(&net_device_ctx->vf_add); netdev_rx_handler_unregister(vf_netdev); netdev_upper_dev_unlink(vf_netdev, ndev); diff --git a/net/core/dev.c b/net/core/dev.c index fccf2167b235..8c6c9d7fba26 100644 --- a/net/core/dev.c +++ b/net/core/dev.c @@ -9953,6 +9953,7 @@ int netif_xdp_propagate(struct net_device *dev, struct netdev_bpf *bpf) return dev->netdev_ops->ndo_bpf(dev, bpf); } +EXPORT_SYMBOL_GPL(netif_xdp_propagate); u32 dev_xdp_prog_id(struct net_device *dev, enum bpf_xdp_mode mode) { -- 2.43.0

3 months, 4 weeks

4
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2025