From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 97AEE14A8B; Sun, 24 Mar 2024 22:34:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319699; cv=none; b=S6bDbWqZPgdaO+FQu7zsAldyC3NeWKO6eub2jXjvKro4uN5S8c7AZCRATneKEe49tEeAmq2vmMQ4K83Vjx2pcd7vfdT0p5tBRw4zbNbiGJ+U78wyVQvKweTSPxTcwPDkWoH11Z1oQHPauZqv7KyO1jTMapIBsscTt6wcBAummsw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319699; c=relaxed/simple; bh=cjoyQ1faXxRarwNjQiwL0MuY+lSCvlUxadrZlLQ452M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LOkdK4e28PrDmmCeEpj3cq/3DLnLk5bvq5qhsiyiBBwqDsOKqI3AZjvvfEC72zfMLRKBxRaAVmGt1wZZUujx+BD9VF/k4XnPUjFuUtuoacYZKEo9lrVb/KzK3wvE7k8EhuXcaBlyEUr9NPgTVeVW1xtwpa219xlsG15Xp+HbV8g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=B4APUedv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="B4APUedv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 419C5C43390; Sun, 24 Mar 2024 22:34:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319699; bh=cjoyQ1faXxRarwNjQiwL0MuY+lSCvlUxadrZlLQ452M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=B4APUedvHZX3hC0xherGQISjWD6U90vZ5tA8OI7OZhS16Jaio/ZK5yxC7m5pMxiJ8 U2aCkTs6R6Gahyyio3qq/OVroibSNPioFKY+wOkpT395wbUOQTXxSh9Xw6q7UmpMTr vps/KCEYCcZQ54aUD7BYOkxUPdyl4xTmIqbfc4aqENw8Lu8kYrKoI+o3S2CJE7V3RJ sKX35E8doMN3IEPxqA71F887f/0dBY4UWXB8lq3xMqbIMYaPpYWH2xJI4BqwTaD/W1 8nR7zewzAC4vEM93A3nrn8GnV9nY9nrfIp1l7qOxiauz7kSDpCLTWfN4c7RzJzOGlw 3xn14kxmLXOTg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nikita Zhandarovich , Chuck Lever III , syzbot+09b349b3066c2e0b1e96@syzkaller.appspotmail.com, Jan Kara , Christian Brauner , Sasha Levin Subject: [PATCH 6.8 001/715] do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak Date: Sun, 24 Mar 2024 18:23:00 -0400 Message-ID: <20240324223455.1342824-2-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nikita Zhandarovich [ Upstream commit 3948abaa4e2be938ccdfc289385a27342fb13d43 ] syzbot identified a kernel information leak vulnerability in do_sys_name_to_handle() and issued the following report [1]. [1] "BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instr= umented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ... Bytes 18-19 of 20 are uninitialized Memory access of size 20 starts at ffff888128a46380 Data copied to user address 0000000020000240" Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to solve the problem. Fixes: 990d6c2d7aee ("vfs: Add name to file handle conversion support") Suggested-by: Chuck Lever III Reported-and-tested-by: Signed-off-by: Nikita Zhandarovich Link: https://lore.kernel.org/r/20240119153906.4367-1-n.zhandarovich@fintec= h.ru Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- fs/fhandle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/fhandle.c b/fs/fhandle.c index 18b3ba8dc8ead..57a12614addfd 100644 --- a/fs/fhandle.c +++ b/fs/fhandle.c @@ -36,7 +36,7 @@ static long do_sys_name_to_handle(const struct path *path, if (f_handle.handle_bytes > MAX_HANDLE_SZ) return -EINVAL; =20 - handle =3D kmalloc(sizeof(struct file_handle) + f_handle.handle_bytes, + handle =3D kzalloc(sizeof(struct file_handle) + f_handle.handle_bytes, GFP_KERNEL); if (!handle) return -ENOMEM; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 41D6E3A8D0; Sun, 24 Mar 2024 22:35:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319700; cv=none; b=SRdHSX3JVdSJFqxEE+ODxSrvndFtljLw2CBefzdYTV/nTQxge+QYjSWyAEUH0oIrOk1A+wVPZs/NEVmEDXHbK+tszCEEDXPcEdFxlrB0+6TY3T/HlBr8pbezmN2Ki9fCAdrA1E/XjKwoiaHdw4vbsQZ3ZxFylYZPgiC6X2JTW64= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319700; c=relaxed/simple; bh=AxbecBUzgHvzbWy2ha2okK9NoJE92B4IW4YBsUFXS1s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pvcDrcawN2Z+nTClyEmdZK5Ig0GUQPUXxg1ZAJ6OIi04BTwFwdutsjFO700QaE5tl627n9s1l9xfyM0jlZuGsGpC+3kDu5WdSl2luH7UkBEDduttOZZQwcmkympFrld/iIPhKSrg634QNLOWmP3BnMxcSpja4vUl6ccnQV77gX8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=B+fv2vo5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="B+fv2vo5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6D200C433B2; Sun, 24 Mar 2024 22:34:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319700; bh=AxbecBUzgHvzbWy2ha2okK9NoJE92B4IW4YBsUFXS1s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=B+fv2vo5Ny3emiQ3AfxrnqgSWwFhfAT0LgUKG7QDHFTAoaeGSQR18ZP3+gz44tEEe ihYGPaTMwX+x2M4G7RpD6Dv2gmog3fq+CzQafJUkv7oJWrIB3PvSue5+sOP2S9fgw/ dk+m9rJ2TR5/rIBTxKhXmRdLQlZoYra+VyQs8vqI5vepaIFsxUiMbHmsTIuiqK233D YoMNCObEJhz8//FsxICUpc8y+0h2tuZ7n9gxgDpk4SXsSiS9yOIGbpv0cK6TZ9nQXt bWPA6p910matlKH1BSwmwIWrYdlVTEZwkaiY6Oo8JKtbfzqzRfhq3pxY0eSgGycMKF b/lg7zEOm52XA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Audra Mitchell , Tejun Heo , Sasha Levin Subject: [PATCH 6.8 002/715] workqueue.c: Increase workqueue name length Date: Sun, 24 Mar 2024 18:23:01 -0400 Message-ID: <20240324223455.1342824-3-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Audra Mitchell [ Upstream commit 31c89007285d365aa36f71d8fb0701581c770a27 ] Currently we limit the size of the workqueue name to 24 characters due to commit ecf6881ff349 ("workqueue: make workqueue->name[] fixed len") Increase the size to 32 characters and print a warning in the event the requested name is larger than the limit of 32 characters. Signed-off-by: Audra Mitchell Signed-off-by: Tejun Heo Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active en= forcement for unbound workqueues") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/workqueue.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 7b482a26d7419..8a06fddb23e66 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -108,7 +108,7 @@ enum { RESCUER_NICE_LEVEL =3D MIN_NICE, HIGHPRI_NICE_LEVEL =3D MIN_NICE, =20 - WQ_NAME_LEN =3D 24, + WQ_NAME_LEN =3D 32, }; =20 /* @@ -4666,6 +4666,7 @@ struct workqueue_struct *alloc_workqueue(const char *= fmt, va_list args; struct workqueue_struct *wq; struct pool_workqueue *pwq; + int len; =20 /* * Unbound && max_active =3D=3D 1 used to imply ordered, which is no long= er @@ -4692,9 +4693,12 @@ struct workqueue_struct *alloc_workqueue(const char = *fmt, } =20 va_start(args, max_active); - vsnprintf(wq->name, sizeof(wq->name), fmt, args); + len =3D vsnprintf(wq->name, sizeof(wq->name), fmt, args); va_end(args); =20 + if (len >=3D WQ_NAME_LEN) + pr_warn_once("workqueue: name exceeds WQ_NAME_LEN. Truncating to: %s\n",= wq->name); + max_active =3D max_active ?: WQ_DFL_ACTIVE; max_active =3D wq_clamp_max_active(max_active, flags, wq->name); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 672843FB8B; Sun, 24 Mar 2024 22:35:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319701; cv=none; b=MzpVS+iXrVGZQ2BD2S/PYlgg81XpCa91oNLesKGGcTFVkvVebhc5R9RWcUNGlmqViHt4PTVtE6ttI6XNOsmbX7Gy/UqlJxOJcLrr9egFtwZsZsnDZpKZkXWAwxLSmkePp1No9ySlgzyF6lAMrKQivL4xKLhLafE2kcYOAP1bFNM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319701; c=relaxed/simple; bh=VjgA9eV7DuaiugXZY3qZanrdV+wvoAHbsCqc6iB2qSs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XYv2uHDT1/KUKezT9SmfIFx5Ixe49FiS+u63LL4T6drML56TFi08c9DnTCr+JhVIcgd3gBc4VfFdVMp1b5pKIecgtDaot1FnEL32dJTwaxtiTYFhmsCW5xYAzIZy1QKKYEPlFWKZRXZLac37rsg8h9IVoG6RWJSEKxEOn0uQl1E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=n1trqFIo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="n1trqFIo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58043C433C7; Sun, 24 Mar 2024 22:35:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319701; bh=VjgA9eV7DuaiugXZY3qZanrdV+wvoAHbsCqc6iB2qSs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=n1trqFIoY4QeV3CzugjEbTdCk0tADoyaTZVQ0ONq1aq8yjCJFWZNXJLvIsnjK4O4C xIOkWUonJcAC7o5fKuggwGxiFtt3dQR7Gvxzcs6yVU4W2tdPtv8zU9SsCw5zMIHFA3 IV9ir3dqE81Jj7lAxjF/HCxxLQrMWmU3mhOsNj2Wq+qwNNmzKZMVME1szkQ5L11/lw GsZc4Hg3Hq/WLxSBye+YyzYULq7mdh2tmW1rDiZiTHo7kJnbo7R+RHdd4Tcij0RekM jFKF0Y+Nq5iQlQR3G+SaM6RPr82Fq+T5Ok6H9WXyXU4OA3lqRZQz1n49K7ejw2Pv/Z IXkQc3b1NqsNw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tejun Heo , Lai Jiangshan , Sasha Levin Subject: [PATCH 6.8 003/715] workqueue: Move pwq->max_active to wq->max_active Date: Sun, 24 Mar 2024 18:23:02 -0400 Message-ID: <20240324223455.1342824-4-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tejun Heo [ Upstream commit a045a272d887575da17ad86d6573e82871b50c27 ] max_active is a workqueue-wide setting and the configured value is stored in wq->saved_max_active; however, the effective value was stored in pwq->max_active. While this is harmless, it makes max_active update process more complicated and gets in the way of the planned max_active semantic updates for unbound workqueues. This patches moves pwq->max_active to wq->max_active. This simplifies the code and makes freezing and noop max_active updates cheaper too. No user-visible behavior change is intended. As wq->max_active is updated while holding wq mutex but read without any locking, it now uses WRITE/READ_ONCE(). A new locking locking rule WO is added for it. v2: wq->max_active now uses WRITE/READ_ONCE() as suggested by Lai. Signed-off-by: Tejun Heo Reviewed-by: Lai Jiangshan Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active en= forcement for unbound workqueues") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/workqueue.c | 133 ++++++++++++++++++++++----------------------- 1 file changed, 66 insertions(+), 67 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 8a06fddb23e66..8ee754dd319da 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -143,6 +143,9 @@ enum { * * WR: wq->mutex protected for writes. RCU protected for reads. * + * WO: wq->mutex protected for writes. Updated with WRITE_ONCE() and can b= e read + * with READ_ONCE() without locking. + * * MD: wq_mayday_lock protected. * * WD: Used internally by the watchdog. @@ -250,7 +253,6 @@ struct pool_workqueue { * is marked with WORK_STRUCT_INACTIVE iff it is in pwq->inactive_works. */ int nr_active; /* L: nr of active works */ - int max_active; /* L: max active works */ struct list_head inactive_works; /* L: inactive works */ struct list_head pwqs_node; /* WR: node on wq->pwqs */ struct list_head mayday_node; /* MD: node on wq->maydays */ @@ -298,7 +300,8 @@ struct workqueue_struct { struct worker *rescuer; /* MD: rescue worker */ =20 int nr_drainers; /* WQ: drain in progress */ - int saved_max_active; /* WQ: saved pwq max_active */ + int max_active; /* WO: max active works */ + int saved_max_active; /* WQ: saved max_active */ =20 struct workqueue_attrs *unbound_attrs; /* PW: only for unbound wqs */ struct pool_workqueue *dfl_pwq; /* PW: only for unbound wqs */ @@ -1492,7 +1495,7 @@ static void pwq_dec_nr_in_flight(struct pool_workqueu= e *pwq, unsigned long work_ pwq->nr_active--; if (!list_empty(&pwq->inactive_works)) { /* one down, submit an inactive one */ - if (pwq->nr_active < pwq->max_active) + if (pwq->nr_active < READ_ONCE(pwq->wq->max_active)) pwq_activate_first_inactive(pwq); } } @@ -1793,7 +1796,13 @@ static void __queue_work(int cpu, struct workqueue_s= truct *wq, pwq->nr_in_flight[pwq->work_color]++; work_flags =3D work_color_to_flags(pwq->work_color); =20 - if (likely(pwq->nr_active < pwq->max_active)) { + /* + * Limit the number of concurrently active work items to max_active. + * @work must also queue behind existing inactive work items to maintain + * ordering when max_active changes. See wq_adjust_max_active(). + */ + if (list_empty(&pwq->inactive_works) && + pwq->nr_active < READ_ONCE(pwq->wq->max_active)) { if (list_empty(&pool->worklist)) pool->watchdog_ts =3D jiffies; =20 @@ -4142,50 +4151,6 @@ static void pwq_release_workfn(struct kthread_work *= work) } } =20 -/** - * pwq_adjust_max_active - update a pwq's max_active to the current setting - * @pwq: target pool_workqueue - * - * If @pwq isn't freezing, set @pwq->max_active to the associated - * workqueue's saved_max_active and activate inactive work items - * accordingly. If @pwq is freezing, clear @pwq->max_active to zero. - */ -static void pwq_adjust_max_active(struct pool_workqueue *pwq) -{ - struct workqueue_struct *wq =3D pwq->wq; - bool freezable =3D wq->flags & WQ_FREEZABLE; - unsigned long flags; - - /* for @wq->saved_max_active */ - lockdep_assert_held(&wq->mutex); - - /* fast exit for non-freezable wqs */ - if (!freezable && pwq->max_active =3D=3D wq->saved_max_active) - return; - - /* this function can be called during early boot w/ irq disabled */ - raw_spin_lock_irqsave(&pwq->pool->lock, flags); - - /* - * During [un]freezing, the caller is responsible for ensuring that - * this function is called at least once after @workqueue_freezing - * is updated and visible. - */ - if (!freezable || !workqueue_freezing) { - pwq->max_active =3D wq->saved_max_active; - - while (!list_empty(&pwq->inactive_works) && - pwq->nr_active < pwq->max_active) - pwq_activate_first_inactive(pwq); - - kick_pool(pwq->pool); - } else { - pwq->max_active =3D 0; - } - - raw_spin_unlock_irqrestore(&pwq->pool->lock, flags); -} - /* initialize newly allocated @pwq which is associated with @wq and @pool = */ static void init_pwq(struct pool_workqueue *pwq, struct workqueue_struct *= wq, struct worker_pool *pool) @@ -4218,9 +4183,6 @@ static void link_pwq(struct pool_workqueue *pwq) /* set the matching work_color */ pwq->work_color =3D wq->work_color; =20 - /* sync max_active to the current setting */ - pwq_adjust_max_active(pwq); - /* link in @pwq */ list_add_rcu(&pwq->pwqs_node, &wq->pwqs); } @@ -4658,6 +4620,52 @@ static int init_rescuer(struct workqueue_struct *wq) return 0; } =20 +/** + * wq_adjust_max_active - update a wq's max_active to the current setting + * @wq: target workqueue + * + * If @wq isn't freezing, set @wq->max_active to the saved_max_active and + * activate inactive work items accordingly. If @wq is freezing, clear + * @wq->max_active to zero. + */ +static void wq_adjust_max_active(struct workqueue_struct *wq) +{ + struct pool_workqueue *pwq; + + lockdep_assert_held(&wq->mutex); + + if ((wq->flags & WQ_FREEZABLE) && workqueue_freezing) { + WRITE_ONCE(wq->max_active, 0); + return; + } + + if (wq->max_active =3D=3D wq->saved_max_active) + return; + + /* + * Update @wq->max_active and then kick inactive work items if more + * active work items are allowed. This doesn't break work item ordering + * because new work items are always queued behind existing inactive + * work items if there are any. + */ + WRITE_ONCE(wq->max_active, wq->saved_max_active); + + for_each_pwq(pwq, wq) { + unsigned long flags; + + /* this function can be called during early boot w/ irq disabled */ + raw_spin_lock_irqsave(&pwq->pool->lock, flags); + + while (!list_empty(&pwq->inactive_works) && + pwq->nr_active < wq->max_active) + pwq_activate_first_inactive(pwq); + + kick_pool(pwq->pool); + + raw_spin_unlock_irqrestore(&pwq->pool->lock, flags); + } +} + __printf(1, 4) struct workqueue_struct *alloc_workqueue(const char *fmt, unsigned int flags, @@ -4665,7 +4673,6 @@ struct workqueue_struct *alloc_workqueue(const char *= fmt, { va_list args; struct workqueue_struct *wq; - struct pool_workqueue *pwq; int len; =20 /* @@ -4704,6 +4711,7 @@ struct workqueue_struct *alloc_workqueue(const char *= fmt, =20 /* init wq */ wq->flags =3D flags; + wq->max_active =3D max_active; wq->saved_max_active =3D max_active; mutex_init(&wq->mutex); atomic_set(&wq->nr_pwqs_to_flush, 0); @@ -4732,8 +4740,7 @@ struct workqueue_struct *alloc_workqueue(const char *= fmt, mutex_lock(&wq_pool_mutex); =20 mutex_lock(&wq->mutex); - for_each_pwq(pwq, wq) - pwq_adjust_max_active(pwq); + wq_adjust_max_active(wq); mutex_unlock(&wq->mutex); =20 list_add_tail_rcu(&wq->list, &workqueues); @@ -4871,8 +4878,6 @@ EXPORT_SYMBOL_GPL(destroy_workqueue); */ void workqueue_set_max_active(struct workqueue_struct *wq, int max_active) { - struct pool_workqueue *pwq; - /* disallow meddling with max_active for ordered workqueues */ if (WARN_ON(wq->flags & __WQ_ORDERED_EXPLICIT)) return; @@ -4883,9 +4888,7 @@ void workqueue_set_max_active(struct workqueue_struct= *wq, int max_active) =20 wq->flags &=3D ~__WQ_ORDERED; wq->saved_max_active =3D max_active; - - for_each_pwq(pwq, wq) - pwq_adjust_max_active(pwq); + wq_adjust_max_active(wq); =20 mutex_unlock(&wq->mutex); } @@ -5132,8 +5135,8 @@ static void show_pwq(struct pool_workqueue *pwq) pr_info(" pwq %d:", pool->id); pr_cont_pool_info(pool); =20 - pr_cont(" active=3D%d/%d refcnt=3D%d%s\n", - pwq->nr_active, pwq->max_active, pwq->refcnt, + pr_cont(" active=3D%d refcnt=3D%d%s\n", + pwq->nr_active, pwq->refcnt, !list_empty(&pwq->mayday_node) ? " MAYDAY" : ""); =20 hash_for_each(pool->busy_hash, bkt, worker, hentry) { @@ -5681,7 +5684,6 @@ EXPORT_SYMBOL_GPL(work_on_cpu_safe_key); void freeze_workqueues_begin(void) { struct workqueue_struct *wq; - struct pool_workqueue *pwq; =20 mutex_lock(&wq_pool_mutex); =20 @@ -5690,8 +5692,7 @@ void freeze_workqueues_begin(void) =20 list_for_each_entry(wq, &workqueues, list) { mutex_lock(&wq->mutex); - for_each_pwq(pwq, wq) - pwq_adjust_max_active(pwq); + wq_adjust_max_active(wq); mutex_unlock(&wq->mutex); } =20 @@ -5756,7 +5757,6 @@ bool freeze_workqueues_busy(void) void thaw_workqueues(void) { struct workqueue_struct *wq; - struct pool_workqueue *pwq; =20 mutex_lock(&wq_pool_mutex); =20 @@ -5768,8 +5768,7 @@ void thaw_workqueues(void) /* restore max_active and repopulate worklist */ list_for_each_entry(wq, &workqueues, list) { mutex_lock(&wq->mutex); - for_each_pwq(pwq, wq) - pwq_adjust_max_active(pwq); + wq_adjust_max_active(wq); mutex_unlock(&wq->mutex); } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 801034204E; Sun, 24 Mar 2024 22:35:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319702; cv=none; b=MG9M7Ulql3YJJga8pomMKYczIGo/WS9x5Aq6OzZl16CCDDaRe8J4V3TnRLFE4mOlm/g3Ij4VXZeU5r/bBwebIdCCf5deSwABIfXdikT1F5oBMmi8dQdGBT6FijOBeF0UtgPpS5ABzf4tg8hiRdrba66SoJaN/WX02idCDbyf4Xw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319702; c=relaxed/simple; bh=UOA95C2nRZx1WdV76grdqxOWS8HjHR6ci7gp4nbAr+I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WdgnDTYYZmcyjYnq6hCIdFa67vmj5MgQNfzH3AyHHsAsqke4tvUY1YfRqYPlOH5iwgWo7cp5V60I2GnTijLUUZyPflkv0Ub22CeZRYFEiqolu65KTxhIlC0CbQTdi9asLuOvOpQswPQe3AjJ84mOX5EKw39e8eXQqyDOKIRtmrk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a6ZLrgWK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a6ZLrgWK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4104BC43394; Sun, 24 Mar 2024 22:35:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319701; bh=UOA95C2nRZx1WdV76grdqxOWS8HjHR6ci7gp4nbAr+I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a6ZLrgWKJSyPRl2Z08vqLh+Tx0Ao4rswDx1gwKCY3pzwwgNZ+KRLYu+WnxkPTYe6l vLP0CjeGqSkKwt7teCHDgk9PlkpIFkvUgtUKwgju/xMCIw+p3/X02GhDmfIasAoS/U /vvljTDBf9M71qIJb6adz0gOsyA/ch6FQ2Dg1Y4xuSpFOy4sWj53BHbwo4ayjWJBiw SA61wEuWfN3csp7opfVMbpGWqliuBaDN40orqwUzJLeaUdMI1INmRBlwWafiHw3ila fnxNS3X8h2Z5ELpmtu5yQNGJ1XHZbS6LGVL4Fd+0chc2k+DBzGSkxdveNTERcXYDyP oNb7iFGwZQnVA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tejun Heo , Lai Jiangshan , Sasha Levin Subject: [PATCH 6.8 004/715] workqueue: Factor out pwq_is_empty() Date: Sun, 24 Mar 2024 18:23:03 -0400 Message-ID: <20240324223455.1342824-5-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tejun Heo [ Upstream commit afa87ce85379e2d93863fce595afdb5771a84004 ] "!pwq->nr_active && list_empty(&pwq->inactive_works)" test is repeated multiple times. Let's factor it out into pwq_is_empty(). Signed-off-by: Tejun Heo Reviewed-by: Lai Jiangshan Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active en= forcement for unbound workqueues") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/workqueue.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 8ee754dd319da..6d0f64b5918ba 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -1456,6 +1456,11 @@ static void put_pwq_unlocked(struct pool_workqueue *= pwq) } } =20 +static bool pwq_is_empty(struct pool_workqueue *pwq) +{ + return !pwq->nr_active && list_empty(&pwq->inactive_works); +} + static void pwq_activate_inactive_work(struct work_struct *work) { struct pool_workqueue *pwq =3D get_work_pwq(work); @@ -3325,7 +3330,7 @@ void drain_workqueue(struct workqueue_struct *wq) bool drained; =20 raw_spin_lock_irq(&pwq->pool->lock); - drained =3D !pwq->nr_active && list_empty(&pwq->inactive_works); + drained =3D pwq_is_empty(pwq); raw_spin_unlock_irq(&pwq->pool->lock); =20 if (drained) @@ -4772,7 +4777,7 @@ static bool pwq_busy(struct pool_workqueue *pwq) =20 if ((pwq !=3D pwq->wq->dfl_pwq) && (pwq->refcnt > 1)) return true; - if (pwq->nr_active || !list_empty(&pwq->inactive_works)) + if (!pwq_is_empty(pwq)) return true; =20 return false; @@ -5210,7 +5215,7 @@ void show_one_workqueue(struct workqueue_struct *wq) unsigned long flags; =20 for_each_pwq(pwq, wq) { - if (pwq->nr_active || !list_empty(&pwq->inactive_works)) { + if (!pwq_is_empty(pwq)) { idle =3D false; break; } @@ -5222,7 +5227,7 @@ void show_one_workqueue(struct workqueue_struct *wq) =20 for_each_pwq(pwq, wq) { raw_spin_lock_irqsave(&pwq->pool->lock, flags); - if (pwq->nr_active || !list_empty(&pwq->inactive_works)) { + if (!pwq_is_empty(pwq)) { /* * Defer printing to avoid deadlocks in console * drivers that queue work while holding locks --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 45F20482EE; Sun, 24 Mar 2024 22:35:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319703; cv=none; b=Zm6HlFtw6B5LB6tAbHHJgQws7xZLxfWtfCYv8/UdmpC0c7auyMUKHy8xJTCeWBOcLndPksIBH/WVSibTGiMG9wRkvWtO5ykVzsMAT2WaSkVrpSawVfYErAj36HazHIp/FgVGmyrEBRI168IPK/yy1pQUbXJGHC5Fn8iD2agtwZ4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319703; c=relaxed/simple; bh=l9ny8GqDQj32iNYYIqnbkFSzH/g8eVE5gNxj0kXzuP8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dJU6+EZgVL0QXzQvmiKCoBumf3A7sJqEvY/be+dj9di//Woqgy/7FA85aQS6G89e90oyGLFkhvRencVImrqw5QeoVAChURz/5+f9VmSpN9NU+w/b/P67rtAWkpqCgQhLb7PnxcjmZnWidQE1eKyqUJsxFtOG0fiYJoBMbnq5ERE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SJLP1LCD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SJLP1LCD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28FF3C43141; Sun, 24 Mar 2024 22:35:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319702; bh=l9ny8GqDQj32iNYYIqnbkFSzH/g8eVE5gNxj0kXzuP8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SJLP1LCDjQP7y7uc9trefJRox+5Gv3503nkVtvmd0FqfuyTwU18BQJMErWFWWqc7e o/Hw8cEG6CqI6l6qCwvI2kw98oGbUq+m3OK/xKemd6Fn1Pf7w6o6mRSLn6FQX2LszT XrGtPA1bVTugQhFfZDXcdCGNcXu+z5BowdqDJM7x/QZb6dW6G6tYNlv5JDv1JpnX9J B1etjlCocOifxGxR4xGROmxFLEw0jYmOJAG85Gww30pukKw9PIrN/rf3xqmRLyEWQG 98liLEqmerQQxOg26RQjV6VT5YZGI+lbUg6yo8Fr2dvxxida96/BttfgtuUzCMwB7h TVMt4UAZXWCEA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tejun Heo , Lai Jiangshan , Sasha Levin Subject: [PATCH 6.8 005/715] workqueue: Replace pwq_activate_inactive_work() with [__]pwq_activate_work() Date: Sun, 24 Mar 2024 18:23:04 -0400 Message-ID: <20240324223455.1342824-6-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tejun Heo [ Upstream commit 4c6380305d21e36581b451f7337a36c93b64e050 ] To prepare for unbound nr_active handling improvements, move work activation part of pwq_activate_inactive_work() into __pwq_activate_work() and add pwq_activate_work() which tests WORK_STRUCT_INACTIVE and updates nr_active. pwq_activate_first_inactive() and try_to_grab_pending() are updated to use pwq_activate_work(). The latter conversion is functionally identical. For the former, this conversion adds an unnecessary WORK_STRUCT_INACTIVE testing. This is temporary and will be removed by the next patch. Signed-off-by: Tejun Heo Reviewed-by: Lai Jiangshan Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active en= forcement for unbound workqueues") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/workqueue.c | 31 +++++++++++++++++++++++++------ 1 file changed, 25 insertions(+), 6 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 6d0f64b5918ba..7e1b0238158ea 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -1461,16 +1461,36 @@ static bool pwq_is_empty(struct pool_workqueue *pwq) return !pwq->nr_active && list_empty(&pwq->inactive_works); } =20 -static void pwq_activate_inactive_work(struct work_struct *work) +static void __pwq_activate_work(struct pool_workqueue *pwq, + struct work_struct *work) { - struct pool_workqueue *pwq =3D get_work_pwq(work); - trace_workqueue_activate_work(work); if (list_empty(&pwq->pool->worklist)) pwq->pool->watchdog_ts =3D jiffies; move_linked_works(work, &pwq->pool->worklist, NULL); __clear_bit(WORK_STRUCT_INACTIVE_BIT, work_data_bits(work)); +} + +/** + * pwq_activate_work - Activate a work item if inactive + * @pwq: pool_workqueue @work belongs to + * @work: work item to activate + * + * Returns %true if activated. %false if already active. + */ +static bool pwq_activate_work(struct pool_workqueue *pwq, + struct work_struct *work) +{ + struct worker_pool *pool =3D pwq->pool; + + lockdep_assert_held(&pool->lock); + + if (!(*work_data_bits(work) & WORK_STRUCT_INACTIVE)) + return false; + pwq->nr_active++; + __pwq_activate_work(pwq, work); + return true; } =20 static void pwq_activate_first_inactive(struct pool_workqueue *pwq) @@ -1478,7 +1498,7 @@ static void pwq_activate_first_inactive(struct pool_w= orkqueue *pwq) struct work_struct *work =3D list_first_entry(&pwq->inactive_works, struct work_struct, entry); =20 - pwq_activate_inactive_work(work); + pwq_activate_work(pwq, work); } =20 /** @@ -1616,8 +1636,7 @@ static int try_to_grab_pending(struct work_struct *wo= rk, bool is_dwork, * management later on and cause stall. Make sure the work * item is activated before grabbing. */ - if (*work_data_bits(work) & WORK_STRUCT_INACTIVE) - pwq_activate_inactive_work(work); + pwq_activate_work(pwq, work); =20 list_del_init(&work->entry); pwq_dec_nr_in_flight(pwq, *work_data_bits(work)); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2851143AC5; Sun, 24 Mar 2024 22:35:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319704; cv=none; b=pAZ8kbDZD0zrU5IhueI5+OjaZCN7pLukjC84fS95WXofFu1JOL5WP8RJmLdCA4peF990FIxPRL0P4ih53oQ38fnKsAYNOoAQ37PQeAJqFFTlQXniN6aib9ScmO0HLwZk3jgC68JLdP5DKmhWG37F/Jxv8g09+WyN6YRX9OTT32Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319704; c=relaxed/simple; bh=CYKCU5m1Lbnhi0N/OhAGJKYTjm7/p8K6CjRh77KXypA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nXR/CNxj6oGu9MXP2ipQa61F5NuSvB9qD2jTigwsA5noTyZWeEnO1jaP6SsZoA1gBlQLfGmFH/sBwN/dm9G9Yo+nqh667x0b9QqB5/Qc6QlgXMetTJ2CdHVNBHxmyFcBBlAdVniYhIzkEbbxhpBiz6MDrnXoafaSvC1TlztZrqg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IqOFuSlk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IqOFuSlk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F70FC433B2; Sun, 24 Mar 2024 22:35:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319703; bh=CYKCU5m1Lbnhi0N/OhAGJKYTjm7/p8K6CjRh77KXypA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IqOFuSlkXrbea8LnbKK4PZv+050a2lolToSG3k6bHnAXNIQWfPtF4Tjt9Q9l4ncyW U1WizDbiDf/yLDGjoU80MrP9BnSsH1ZkwmMEOsa0LahgPmsGCDFOdx5SqU0nQ+DCN0 X7jsdxAsq8IJ4ldQqd2+koMY83xLaciyyXo+vDTtkl/RmW11ETtc/NvG0gijx8Cfrh qcAUtYzu8kIfh67uSvROTPDWct9BJeX9fE+OymgSGXzfoGHL1DyEmLWSOZWHfAHv6s l5bqidlxJ6PXnQsvAw+pNoA9fLuxQCSG5s0x/HcXct5AmYXkZujwGBxolDYYusiXs1 AYCVyNKG+MjUQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tejun Heo , Lai Jiangshan , Sasha Levin Subject: [PATCH 6.8 006/715] workqueue: Move nr_active handling into helpers Date: Sun, 24 Mar 2024 18:23:05 -0400 Message-ID: <20240324223455.1342824-7-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tejun Heo [ Upstream commit 1c270b79ce0b8290f146255ea9057243f6dd3c17 ] __queue_work(), pwq_dec_nr_in_flight() and wq_adjust_max_active() were open-coding nr_active handling, which is fine given that the operations are trivial. However, the planned unbound nr_active update will make them more complicated, so let's move them into helpers. - pwq_tryinc_nr_active() is added. It increments nr_active if under max_active limit and return a boolean indicating whether inc was successful. Note that the function is structured to accommodate future changes. __queue_work() is updated to use the new helper. - pwq_activate_first_inactive() is updated to use pwq_tryinc_nr_active() and thus no longer assumes that nr_active is under max_active and returns a boolean to indicate whether a work item has been activated. - wq_adjust_max_active() no longer tests directly whether a work item can be activated. Instead, it's updated to use the return value of pwq_activate_first_inactive() to tell whether a work item has been activated. - nr_active decrement and activating the first inactive work item is factored into pwq_dec_nr_active(). v3: - WARN_ON_ONCE(!WORK_STRUCT_INACTIVE) added to __pwq_activate_work() as now we're calling the function unconditionally from pwq_activate_first_inactive(). v2: - wq->max_active now uses WRITE/READ_ONCE() as suggested by Lai. Signed-off-by: Tejun Heo Reviewed-by: Lai Jiangshan Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active en= forcement for unbound workqueues") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/workqueue.c | 86 ++++++++++++++++++++++++++++++++++++---------- 1 file changed, 67 insertions(+), 19 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 7e1b0238158ea..80733046ee012 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -1464,11 +1464,14 @@ static bool pwq_is_empty(struct pool_workqueue *pwq) static void __pwq_activate_work(struct pool_workqueue *pwq, struct work_struct *work) { + unsigned long *wdb =3D work_data_bits(work); + + WARN_ON_ONCE(!(*wdb & WORK_STRUCT_INACTIVE)); trace_workqueue_activate_work(work); if (list_empty(&pwq->pool->worklist)) pwq->pool->watchdog_ts =3D jiffies; move_linked_works(work, &pwq->pool->worklist, NULL); - __clear_bit(WORK_STRUCT_INACTIVE_BIT, work_data_bits(work)); + __clear_bit(WORK_STRUCT_INACTIVE_BIT, wdb); } =20 /** @@ -1493,12 +1496,66 @@ static bool pwq_activate_work(struct pool_workqueue= *pwq, return true; } =20 -static void pwq_activate_first_inactive(struct pool_workqueue *pwq) +/** + * pwq_tryinc_nr_active - Try to increment nr_active for a pwq + * @pwq: pool_workqueue of interest + * + * Try to increment nr_active for @pwq. Returns %true if an nr_active coun= t is + * successfully obtained. %false otherwise. + */ +static bool pwq_tryinc_nr_active(struct pool_workqueue *pwq) +{ + struct workqueue_struct *wq =3D pwq->wq; + struct worker_pool *pool =3D pwq->pool; + bool obtained; + + lockdep_assert_held(&pool->lock); + + obtained =3D pwq->nr_active < READ_ONCE(wq->max_active); + + if (obtained) + pwq->nr_active++; + return obtained; +} + +/** + * pwq_activate_first_inactive - Activate the first inactive work item on = a pwq + * @pwq: pool_workqueue of interest + * + * Activate the first inactive work item of @pwq if available and allowed = by + * max_active limit. + * + * Returns %true if an inactive work item has been activated. %false if no + * inactive work item is found or max_active limit is reached. + */ +static bool pwq_activate_first_inactive(struct pool_workqueue *pwq) +{ + struct work_struct *work =3D + list_first_entry_or_null(&pwq->inactive_works, + struct work_struct, entry); + + if (work && pwq_tryinc_nr_active(pwq)) { + __pwq_activate_work(pwq, work); + return true; + } else { + return false; + } +} + +/** + * pwq_dec_nr_active - Retire an active count + * @pwq: pool_workqueue of interest + * + * Decrement @pwq's nr_active and try to activate the first inactive work = item. + */ +static void pwq_dec_nr_active(struct pool_workqueue *pwq) { - struct work_struct *work =3D list_first_entry(&pwq->inactive_works, - struct work_struct, entry); + struct worker_pool *pool =3D pwq->pool; =20 - pwq_activate_work(pwq, work); + lockdep_assert_held(&pool->lock); + + pwq->nr_active--; + pwq_activate_first_inactive(pwq); } =20 /** @@ -1516,14 +1573,8 @@ static void pwq_dec_nr_in_flight(struct pool_workque= ue *pwq, unsigned long work_ { int color =3D get_work_color(work_data); =20 - if (!(work_data & WORK_STRUCT_INACTIVE)) { - pwq->nr_active--; - if (!list_empty(&pwq->inactive_works)) { - /* one down, submit an inactive one */ - if (pwq->nr_active < READ_ONCE(pwq->wq->max_active)) - pwq_activate_first_inactive(pwq); - } - } + if (!(work_data & WORK_STRUCT_INACTIVE)) + pwq_dec_nr_active(pwq); =20 pwq->nr_in_flight[color]--; =20 @@ -1825,13 +1876,11 @@ static void __queue_work(int cpu, struct workqueue_= struct *wq, * @work must also queue behind existing inactive work items to maintain * ordering when max_active changes. See wq_adjust_max_active(). */ - if (list_empty(&pwq->inactive_works) && - pwq->nr_active < READ_ONCE(pwq->wq->max_active)) { + if (list_empty(&pwq->inactive_works) && pwq_tryinc_nr_active(pwq)) { if (list_empty(&pool->worklist)) pool->watchdog_ts =3D jiffies; =20 trace_workqueue_activate_work(work); - pwq->nr_active++; insert_work(pwq, work, &pool->worklist, work_flags); kick_pool(pool); } else { @@ -4680,9 +4729,8 @@ static void wq_adjust_max_active(struct workqueue_str= uct *wq) /* this function can be called during early boot w/ irq disabled */ raw_spin_lock_irqsave(&pwq->pool->lock, flags); =20 - while (!list_empty(&pwq->inactive_works) && - pwq->nr_active < wq->max_active) - pwq_activate_first_inactive(pwq); + while (pwq_activate_first_inactive(pwq)) + ; =20 kick_pool(pwq->pool); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05D5C4D9E3; Sun, 24 Mar 2024 22:35:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319705; cv=none; b=msHSRqlohzZ24PQ10anM6Lukahf/4GCAbT+IosT736BluMBeVMsna4igb23wjqlKGjV5VTCQzBvI4oDRkHQKbPXuh9I8EoRz19XrKWDM12MGOO9qN7jVSWn/6E+cTirf1bgxS11ZD162vHVRj+DRkLsPddTzFfrXmSAxTQbkf0E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319705; c=relaxed/simple; bh=VNKgCdf+8XLDqyA5oqNOYsgu4Nyq48Fer9bqXElncUQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=EVuyZ5tPjxVZ0iUydL0WxGfTBejyDBVkUOcW6Tk6U19PLSvNDMRTZ9zEdGllMeUmWd35K1mvgBxSKnQF6Clc7tWnos5N+CP8A2bdHo91ZDUR6fQu+rEjhEQKaO/WSCE2+fNVJKxOhGlZpU4MPAcIsm1csZqASdZ1sOHsRgZmK5o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Pg+dLDYb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Pg+dLDYb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE1E6C43390; Sun, 24 Mar 2024 22:35:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319704; bh=VNKgCdf+8XLDqyA5oqNOYsgu4Nyq48Fer9bqXElncUQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Pg+dLDYbWAMz1BG5G6M8A4hcMF2vvphlJJ2x3atYexdIf2bHBEgYuCf24XsVKfIwJ rWPcUW2tFuH3QJ4Yaoc6Xqa27z4VugpPkPYqqxJlzbC4bZLzsIrEY8SGrwKpEmDDV+ OrYh1DEsgFutwnSjAqOwqvE5Dt2tioPTOLDBCxVfRjexN5R32j/mmc6sXBIjGInJ2S Azad9ySTFD73hqo+diEO0fGPQ2Kk+2oatsKrhchPxMjFLZZI7mblKcCmfriHX9B212 ndjcpTfmpjYt2y3tzKtUZvwaTZzS7np3Rzl2BxqwNbN+B9WZkd1Wnc0NNxCXvJ1D+c AWWrkGeWm1RrA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tejun Heo , Lai Jiangshan , Sasha Levin Subject: [PATCH 6.8 007/715] workqueue: Make wq_adjust_max_active() round-robin pwqs while activating Date: Sun, 24 Mar 2024 18:23:06 -0400 Message-ID: <20240324223455.1342824-8-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tejun Heo [ Upstream commit c5404d4e6df6faba1007544b5f4e62c7c14416dd ] wq_adjust_max_active() needs to activate work items after max_active is increased. Previously, it did that by visiting each pwq once activating all that could be activated. While this makes sense with per-pwq nr_active, nr_active will be shared across multiple pwqs for unbound wqs. Then, we'd want to round-robin through pwqs to be fairer. In preparation, this patch makes wq_adjust_max_active() round-robin pwqs while activating. While the activation ordering changes, this shouldn't cause user-noticeable behavior changes. Signed-off-by: Tejun Heo Reviewed-by: Lai Jiangshan Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active en= forcement for unbound workqueues") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/workqueue.c | 31 +++++++++++++++++++------------ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 80733046ee012..1659cd4a36c62 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -4703,7 +4703,7 @@ static int init_rescuer(struct workqueue_struct *wq) */ static void wq_adjust_max_active(struct workqueue_struct *wq) { - struct pool_workqueue *pwq; + bool activated; =20 lockdep_assert_held(&wq->mutex); =20 @@ -4723,19 +4723,26 @@ static void wq_adjust_max_active(struct workqueue_s= truct *wq) */ WRITE_ONCE(wq->max_active, wq->saved_max_active); =20 - for_each_pwq(pwq, wq) { - unsigned long flags; - - /* this function can be called during early boot w/ irq disabled */ - raw_spin_lock_irqsave(&pwq->pool->lock, flags); - - while (pwq_activate_first_inactive(pwq)) - ; + /* + * Round-robin through pwq's activating the first inactive work item + * until max_active is filled. + */ + do { + struct pool_workqueue *pwq; =20 - kick_pool(pwq->pool); + activated =3D false; + for_each_pwq(pwq, wq) { + unsigned long flags; =20 - raw_spin_unlock_irqrestore(&pwq->pool->lock, flags); - } + /* can be called during early boot w/ irq disabled */ + raw_spin_lock_irqsave(&pwq->pool->lock, flags); + if (pwq_activate_first_inactive(pwq)) { + activated =3D true; + kick_pool(pwq->pool); + } + raw_spin_unlock_irqrestore(&pwq->pool->lock, flags); + } + } while (activated); } =20 __printf(1, 4) --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A8D0B4EB22; Sun, 24 Mar 2024 22:35:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319705; cv=none; b=SrewyFewSCQ8O80zNoWbXpAu1zyCWxJTyu7QaSZychUwWFxKGERaCXjl9V1gxUwQWRABYQ07AKXw/yc5X6H9tZWTTsNHTpXHtVLSKI2U0J4fCiyRgdVGKKPkCUDk1/l8zeoNYAjn1SH1oGK4npD3t7ekwlpoFvbT+x/SntGuNOQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319705; c=relaxed/simple; bh=CWw8F2fVqP4cLPu49IP63ZuAjTHzljhZGVc9EXSg6Kg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L9QZBQhtsuiDZbjL/Thgu7cAws/8+XHtKrxIIYpnjyCPgtNJ46VTZ+LS0CT8WcC62Qv9t/HCjFCcqtfoJwYp5O0ies9Kwqm5uK3lSZs38QPzGSuzunrAjhW3Flfux476iKmQxuqIwC/gqj8TTTAEGPYaEUS+QXI3y40tWfO9hCw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ShS/YUPB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ShS/YUPB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAB9FC433B1; Sun, 24 Mar 2024 22:35:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319705; bh=CWw8F2fVqP4cLPu49IP63ZuAjTHzljhZGVc9EXSg6Kg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ShS/YUPBdWXCrLzfdhmQE5KBwhuNDmhRnXdnnOm28fT5IRlcBj2M9lhqjSbl8oXpA vD7C8IPtcz1+P0FC89Xo+cOm2f2ccy+Qqirga7Vlvtt1YZqTMXf5KK8+5IY1PYyLCR AVCXhLWZ+HZig77GjFAHvVwZoF6cUR6QTD4xb1oz3S/MZT7DI9CCuLHtvsDFGbKZRO +EyJsjx8i6y1169f3r1FEg3k6amE+D3pufy4MoqnO8GOF5JAMWkseEjtCB6f8iMoCH f5OiDEJsNLWHOVCx0jGmcq6B/5CgZzdRggvRRdCvsVtMNpBKk4GB7HAVUelOmSAAhl Cv58qpwwLWLkA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tejun Heo , Lai Jiangshan , Sasha Levin Subject: [PATCH 6.8 008/715] workqueue: RCU protect wq->dfl_pwq and implement accessors for it Date: Sun, 24 Mar 2024 18:23:07 -0400 Message-ID: <20240324223455.1342824-9-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tejun Heo [ Upstream commit 9f66cff212bb3c1cd25996aaa0dfd0c9e9d8baab ] wq->cpu_pwq is RCU protected but wq->dfl_pwq isn't. This is okay because currently wq->dfl_pwq is used only accessed to install it into wq->cpu_pwq which doesn't require RCU access. However, we want to be able to access wq->dfl_pwq under RCU in the future to access its __pod_cpumask and the code can be made easier to read by making the two pwq fields behave in the same way. - Make wq->dfl_pwq RCU protected. - Add unbound_pwq_slot() and unbound_pwq() which can access both ->dfl_pwq and ->cpu_pwq. The former returns the double pointer that can be used access and update the pwqs. The latter performs locking check and dereferences the double pointer. - pwq accesses and updates are converted to use unbound_pwq[_slot](). Signed-off-by: Tejun Heo Reviewed-by: Lai Jiangshan Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active en= forcement for unbound workqueues") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/workqueue.c | 64 +++++++++++++++++++++++++++++----------------- 1 file changed, 40 insertions(+), 24 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 1659cd4a36c62..5cfc04dd05ad6 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -304,7 +304,7 @@ struct workqueue_struct { int saved_max_active; /* WQ: saved max_active */ =20 struct workqueue_attrs *unbound_attrs; /* PW: only for unbound wqs */ - struct pool_workqueue *dfl_pwq; /* PW: only for unbound wqs */ + struct pool_workqueue __rcu *dfl_pwq; /* PW: only for unbound wqs */ =20 #ifdef CONFIG_SYSFS struct wq_device *wq_dev; /* I: for sysfs interface */ @@ -635,6 +635,23 @@ static int worker_pool_assign_id(struct worker_pool *p= ool) return ret; } =20 +static struct pool_workqueue __rcu ** +unbound_pwq_slot(struct workqueue_struct *wq, int cpu) +{ + if (cpu >=3D 0) + return per_cpu_ptr(wq->cpu_pwq, cpu); + else + return &wq->dfl_pwq; +} + +/* @cpu < 0 for dfl_pwq */ +static struct pool_workqueue *unbound_pwq(struct workqueue_struct *wq, int= cpu) +{ + return rcu_dereference_check(*unbound_pwq_slot(wq, cpu), + lockdep_is_held(&wq_pool_mutex) || + lockdep_is_held(&wq->mutex)); +} + static unsigned int work_color_to_flags(int color) { return color << WORK_STRUCT_COLOR_SHIFT; @@ -4324,10 +4341,11 @@ static void wq_calc_pod_cpumask(struct workqueue_at= trs *attrs, int cpu, "possible intersect\n"); } =20 -/* install @pwq into @wq's cpu_pwq and return the old pwq */ +/* install @pwq into @wq and return the old pwq, @cpu < 0 for dfl_pwq */ static struct pool_workqueue *install_unbound_pwq(struct workqueue_struct = *wq, int cpu, struct pool_workqueue *pwq) { + struct pool_workqueue __rcu **slot =3D unbound_pwq_slot(wq, cpu); struct pool_workqueue *old_pwq; =20 lockdep_assert_held(&wq_pool_mutex); @@ -4336,8 +4354,8 @@ static struct pool_workqueue *install_unbound_pwq(str= uct workqueue_struct *wq, /* link_pwq() can handle duplicate calls */ link_pwq(pwq); =20 - old_pwq =3D rcu_access_pointer(*per_cpu_ptr(wq->cpu_pwq, cpu)); - rcu_assign_pointer(*per_cpu_ptr(wq->cpu_pwq, cpu), pwq); + old_pwq =3D rcu_access_pointer(*slot); + rcu_assign_pointer(*slot, pwq); return old_pwq; } =20 @@ -4437,14 +4455,11 @@ static void apply_wqattrs_commit(struct apply_wqatt= rs_ctx *ctx) =20 copy_workqueue_attrs(ctx->wq->unbound_attrs, ctx->attrs); =20 - /* save the previous pwq and install the new one */ + /* save the previous pwqs and install the new ones */ for_each_possible_cpu(cpu) ctx->pwq_tbl[cpu] =3D install_unbound_pwq(ctx->wq, cpu, ctx->pwq_tbl[cpu]); - - /* @dfl_pwq might not have been used, ensure it's linked */ - link_pwq(ctx->dfl_pwq); - swap(ctx->wq->dfl_pwq, ctx->dfl_pwq); + ctx->dfl_pwq =3D install_unbound_pwq(ctx->wq, -1, ctx->dfl_pwq); =20 mutex_unlock(&ctx->wq->mutex); } @@ -4554,9 +4569,7 @@ static void wq_update_pod(struct workqueue_struct *wq= , int cpu, =20 /* nothing to do if the target cpumask matches the current pwq */ wq_calc_pod_cpumask(target_attrs, cpu, off_cpu); - pwq =3D rcu_dereference_protected(*per_cpu_ptr(wq->cpu_pwq, cpu), - lockdep_is_held(&wq_pool_mutex)); - if (wqattrs_equal(target_attrs, pwq->pool->attrs)) + if (wqattrs_equal(target_attrs, unbound_pwq(wq, cpu)->pool->attrs)) return; =20 /* create a new pwq */ @@ -4574,10 +4587,11 @@ static void wq_update_pod(struct workqueue_struct *= wq, int cpu, =20 use_dfl_pwq: mutex_lock(&wq->mutex); - raw_spin_lock_irq(&wq->dfl_pwq->pool->lock); - get_pwq(wq->dfl_pwq); - raw_spin_unlock_irq(&wq->dfl_pwq->pool->lock); - old_pwq =3D install_unbound_pwq(wq, cpu, wq->dfl_pwq); + pwq =3D unbound_pwq(wq, -1); + raw_spin_lock_irq(&pwq->pool->lock); + get_pwq(pwq); + raw_spin_unlock_irq(&pwq->pool->lock); + old_pwq =3D install_unbound_pwq(wq, cpu, pwq); out_unlock: mutex_unlock(&wq->mutex); put_pwq_unlocked(old_pwq); @@ -4615,10 +4629,13 @@ static int alloc_and_link_pwqs(struct workqueue_str= uct *wq) =20 cpus_read_lock(); if (wq->flags & __WQ_ORDERED) { + struct pool_workqueue *dfl_pwq; + ret =3D apply_workqueue_attrs(wq, ordered_wq_attrs[highpri]); /* there should only be single pwq for ordering guarantee */ - WARN(!ret && (wq->pwqs.next !=3D &wq->dfl_pwq->pwqs_node || - wq->pwqs.prev !=3D &wq->dfl_pwq->pwqs_node), + dfl_pwq =3D rcu_access_pointer(wq->dfl_pwq); + WARN(!ret && (wq->pwqs.next !=3D &dfl_pwq->pwqs_node || + wq->pwqs.prev !=3D &dfl_pwq->pwqs_node), "ordering guarantee broken for workqueue %s\n", wq->name); } else { ret =3D apply_workqueue_attrs(wq, unbound_std_wq_attrs[highpri]); @@ -4849,7 +4866,7 @@ static bool pwq_busy(struct pool_workqueue *pwq) if (pwq->nr_in_flight[i]) return true; =20 - if ((pwq !=3D pwq->wq->dfl_pwq) && (pwq->refcnt > 1)) + if ((pwq !=3D rcu_access_pointer(pwq->wq->dfl_pwq)) && (pwq->refcnt > 1)) return true; if (!pwq_is_empty(pwq)) return true; @@ -4933,13 +4950,12 @@ void destroy_workqueue(struct workqueue_struct *wq) rcu_read_lock(); =20 for_each_possible_cpu(cpu) { - pwq =3D rcu_access_pointer(*per_cpu_ptr(wq->cpu_pwq, cpu)); - RCU_INIT_POINTER(*per_cpu_ptr(wq->cpu_pwq, cpu), NULL); - put_pwq_unlocked(pwq); + put_pwq_unlocked(unbound_pwq(wq, cpu)); + RCU_INIT_POINTER(*unbound_pwq_slot(wq, cpu), NULL); } =20 - put_pwq_unlocked(wq->dfl_pwq); - wq->dfl_pwq =3D NULL; + put_pwq_unlocked(unbound_pwq(wq, -1)); + RCU_INIT_POINTER(*unbound_pwq_slot(wq, -1), NULL); =20 rcu_read_unlock(); } --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 859C251C56; Sun, 24 Mar 2024 22:35:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319706; cv=none; b=Ps9R6wG/ezBr272dlVgK+wIuYAyhAW6rV9eIY8DNzNoNWsWoBJqzqLC4sEHGONNMd9WlWedHm3Shv644+jRweuQ/NUycSixAC1U0tULhQpvlFuNvE30wCeytwuu/0nfbZ74R8ByJRIbqpArRktCvLplt77bORQgeH1eOkkmrebo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319706; c=relaxed/simple; bh=qPveSif7G2kTOKM12YWkv4+XvUMrMVRIT48FgzPizp8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oehCRPmY5GE9DZXg90ZpjGgN81ArxVRbZkKSwkUWlGrdBk1LiP8bQ8VTyJHx2B9NqZ+2kFVfdvEDp7N6uNSmESsn84GAhmg9SMjJtuUsGJAN9LEs/wTfreMO2BiSu9+ksqhbRx483Z9QrKN6zhetPqSZjax09mOQ5YJ5A3qZIW4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Zq/FRVC8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Zq/FRVC8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C47B6C433F1; Sun, 24 Mar 2024 22:35:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319706; bh=qPveSif7G2kTOKM12YWkv4+XvUMrMVRIT48FgzPizp8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Zq/FRVC8WMBdcTCf4RlzE7hDIdXVBmYUUvF0nbJgah1+npOLS/8PAAqFXpmoyoAs1 EsSWkcfrXrkiWqt6/5Ao6xfZ/Pr3OcFLBzzaHHal+Qj4JYkqXs7tBl/bIdlU2B+w0f Ikwggy4G/7vSwfHaDMwWQmQe5A7eBgA0GvAP+/Ep8P/7vaw12qyTGeUi0f1b54CfrD xonM4gM2TKsLgiFSJ9bIXenY44dxowVZcZzz/gJBjnfo16sSwBcE6pSj2gwRf7/+ps h43yi8M+t7vJWcnNK5tiuRCWUnpXPdC65HAKc02o7tAz7zNW1nxkmrrJcH67IKnyrf p4k1tSMZ+nTPg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tejun Heo , Lai Jiangshan , Sasha Levin Subject: [PATCH 6.8 009/715] workqueue: Introduce struct wq_node_nr_active Date: Sun, 24 Mar 2024 18:23:08 -0400 Message-ID: <20240324223455.1342824-10-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tejun Heo [ Upstream commit 91ccc6e7233bb10a9c176aa4cc70d6f432a441a5 ] Currently, for both percpu and unbound workqueues, max_active applies per-cpu, which is a recent change for unbound workqueues. The change for unbound workqueues was a significant departure from the previous behavior of per-node application. It made some use cases create undesirable number of concurrent work items and left no good way of fixing them. To address the problem, workqueue is implementing a NUMA node segmented global nr_active mechanism, which will be explained further in the next patch. As a preparation, this patch introduces struct wq_node_nr_active. It's a data structured allocated for each workqueue and NUMA node pair and currently only tracks the workqueue's number of active work items on the node. This is split out from the next patch to make it easier to understand and review. Note that there is an extra wq_node_nr_active allocated for the invalid node nr_node_ids which is used to track nr_active for pools which don't have NUMA node associated such as the default fallback system-wide pool. This doesn't cause any behavior changes visible to userland yet. The next patch will expand to implement the control mechanism on top. v4: - Fixed out-of-bound access when freeing per-cpu workqueues. v3: - Use flexible array for wq->node_nr_active as suggested by Lai. v2: - wq->max_active now uses WRITE/READ_ONCE() as suggested by Lai. - Lai pointed out that pwq_tryinc_nr_active() incorrectly dropped pwq->max_active check. Restored. As the next patch replaces the max_active enforcement mechanism, this doesn't change the end result. Signed-off-by: Tejun Heo Reviewed-by: Lai Jiangshan Stable-dep-of: 5797b1c18919 ("workqueue: Implement system-wide nr_active en= forcement for unbound workqueues") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/workqueue.c | 142 ++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 135 insertions(+), 7 deletions(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 5cfc04dd05ad6..686899845475f 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -280,6 +280,16 @@ struct wq_flusher { =20 struct wq_device; =20 +/* + * Unlike in a per-cpu workqueue where max_active limits its concurrency l= evel + * on each CPU, in an unbound workqueue, max_active applies to the whole s= ystem. + * As sharing a single nr_active across multiple sockets can be very expen= sive, + * the counting and enforcement is per NUMA node. + */ +struct wq_node_nr_active { + atomic_t nr; /* per-node nr_active count */ +}; + /* * The externally visible workqueue. It relays the issued work items to * the appropriate worker_pool through its pool_workqueues. @@ -326,6 +336,7 @@ struct workqueue_struct { /* hot fields used during command issue, aligned to cacheline */ unsigned int flags ____cacheline_aligned; /* WQ: WQ_* flags */ struct pool_workqueue __percpu __rcu **cpu_pwq; /* I: per-cpu pwqs */ + struct wq_node_nr_active *node_nr_active[]; /* I: per-node nr_active */ }; =20 static struct kmem_cache *pwq_cache; @@ -1421,6 +1432,31 @@ work_func_t wq_worker_last_func(struct task_struct *= task) return worker->last_func; } =20 +/** + * wq_node_nr_active - Determine wq_node_nr_active to use + * @wq: workqueue of interest + * @node: NUMA node, can be %NUMA_NO_NODE + * + * Determine wq_node_nr_active to use for @wq on @node. Returns: + * + * - %NULL for per-cpu workqueues as they don't need to use shared nr_acti= ve. + * + * - node_nr_active[nr_node_ids] if @node is %NUMA_NO_NODE. + * + * - Otherwise, node_nr_active[@node]. + */ +static struct wq_node_nr_active *wq_node_nr_active(struct workqueue_struct= *wq, + int node) +{ + if (!(wq->flags & WQ_UNBOUND)) + return NULL; + + if (node =3D=3D NUMA_NO_NODE) + node =3D nr_node_ids; + + return wq->node_nr_active[node]; +} + /** * get_pwq - get an extra reference on the specified pool_workqueue * @pwq: pool_workqueue to get @@ -1502,12 +1538,17 @@ static bool pwq_activate_work(struct pool_workqueue= *pwq, struct work_struct *work) { struct worker_pool *pool =3D pwq->pool; + struct wq_node_nr_active *nna; =20 lockdep_assert_held(&pool->lock); =20 if (!(*work_data_bits(work) & WORK_STRUCT_INACTIVE)) return false; =20 + nna =3D wq_node_nr_active(pwq->wq, pool->node); + if (nna) + atomic_inc(&nna->nr); + pwq->nr_active++; __pwq_activate_work(pwq, work); return true; @@ -1524,14 +1565,18 @@ static bool pwq_tryinc_nr_active(struct pool_workqu= eue *pwq) { struct workqueue_struct *wq =3D pwq->wq; struct worker_pool *pool =3D pwq->pool; + struct wq_node_nr_active *nna =3D wq_node_nr_active(wq, pool->node); bool obtained; =20 lockdep_assert_held(&pool->lock); =20 obtained =3D pwq->nr_active < READ_ONCE(wq->max_active); =20 - if (obtained) + if (obtained) { pwq->nr_active++; + if (nna) + atomic_inc(&nna->nr); + } return obtained; } =20 @@ -1568,10 +1613,26 @@ static bool pwq_activate_first_inactive(struct pool= _workqueue *pwq) static void pwq_dec_nr_active(struct pool_workqueue *pwq) { struct worker_pool *pool =3D pwq->pool; + struct wq_node_nr_active *nna =3D wq_node_nr_active(pwq->wq, pool->node); =20 lockdep_assert_held(&pool->lock); =20 + /* + * @pwq->nr_active should be decremented for both percpu and unbound + * workqueues. + */ pwq->nr_active--; + + /* + * For a percpu workqueue, it's simple. Just need to kick the first + * inactive work item on @pwq itself. + */ + if (!nna) { + pwq_activate_first_inactive(pwq); + return; + } + + atomic_dec(&nna->nr); pwq_activate_first_inactive(pwq); } =20 @@ -4026,11 +4087,63 @@ static void wq_free_lockdep(struct workqueue_struct= *wq) } #endif =20 +static void free_node_nr_active(struct wq_node_nr_active **nna_ar) +{ + int node; + + for_each_node(node) { + kfree(nna_ar[node]); + nna_ar[node] =3D NULL; + } + + kfree(nna_ar[nr_node_ids]); + nna_ar[nr_node_ids] =3D NULL; +} + +static void init_node_nr_active(struct wq_node_nr_active *nna) +{ + atomic_set(&nna->nr, 0); +} + +/* + * Each node's nr_active counter will be accessed mostly from its own node= and + * should be allocated in the node. + */ +static int alloc_node_nr_active(struct wq_node_nr_active **nna_ar) +{ + struct wq_node_nr_active *nna; + int node; + + for_each_node(node) { + nna =3D kzalloc_node(sizeof(*nna), GFP_KERNEL, node); + if (!nna) + goto err_free; + init_node_nr_active(nna); + nna_ar[node] =3D nna; + } + + /* [nr_node_ids] is used as the fallback */ + nna =3D kzalloc_node(sizeof(*nna), GFP_KERNEL, NUMA_NO_NODE); + if (!nna) + goto err_free; + init_node_nr_active(nna); + nna_ar[nr_node_ids] =3D nna; + + return 0; + +err_free: + free_node_nr_active(nna_ar); + return -ENOMEM; +} + static void rcu_free_wq(struct rcu_head *rcu) { struct workqueue_struct *wq =3D container_of(rcu, struct workqueue_struct, rcu); =20 + if (wq->flags & WQ_UNBOUND) + free_node_nr_active(wq->node_nr_active); + wq_free_lockdep(wq); free_percpu(wq->cpu_pwq); free_workqueue_attrs(wq->unbound_attrs); @@ -4769,7 +4882,8 @@ struct workqueue_struct *alloc_workqueue(const char *= fmt, { va_list args; struct workqueue_struct *wq; - int len; + size_t wq_size; + int name_len; =20 /* * Unbound && max_active =3D=3D 1 used to imply ordered, which is no long= er @@ -4785,7 +4899,12 @@ struct workqueue_struct *alloc_workqueue(const char = *fmt, flags |=3D WQ_UNBOUND; =20 /* allocate wq and format name */ - wq =3D kzalloc(sizeof(*wq), GFP_KERNEL); + if (flags & WQ_UNBOUND) + wq_size =3D struct_size(wq, node_nr_active, nr_node_ids + 1); + else + wq_size =3D sizeof(*wq); + + wq =3D kzalloc(wq_size, GFP_KERNEL); if (!wq) return NULL; =20 @@ -4796,11 +4915,12 @@ struct workqueue_struct *alloc_workqueue(const char= *fmt, } =20 va_start(args, max_active); - len =3D vsnprintf(wq->name, sizeof(wq->name), fmt, args); + name_len =3D vsnprintf(wq->name, sizeof(wq->name), fmt, args); va_end(args); =20 - if (len >=3D WQ_NAME_LEN) - pr_warn_once("workqueue: name exceeds WQ_NAME_LEN. Truncating to: %s\n",= wq->name); + if (name_len >=3D WQ_NAME_LEN) + pr_warn_once("workqueue: name exceeds WQ_NAME_LEN. Truncating to: %s\n", + wq->name); =20 max_active =3D max_active ?: WQ_DFL_ACTIVE; max_active =3D wq_clamp_max_active(max_active, flags, wq->name); @@ -4819,8 +4939,13 @@ struct workqueue_struct *alloc_workqueue(const char = *fmt, wq_init_lockdep(wq); INIT_LIST_HEAD(&wq->list); =20 + if (flags & WQ_UNBOUND) { + if (alloc_node_nr_active(wq->node_nr_active) < 0) + goto err_unreg_lockdep; + } + if (alloc_and_link_pwqs(wq) < 0) - goto err_unreg_lockdep; + goto err_free_node_nr_active; =20 if (wq_online && init_rescuer(wq) < 0) goto err_destroy; @@ -4845,6 +4970,9 @@ struct workqueue_struct *alloc_workqueue(const char *= fmt, =20 return wq; =20 +err_free_node_nr_active: + if (wq->flags & WQ_UNBOUND) + free_node_nr_active(wq->node_nr_active); err_unreg_lockdep: wq_unregister_lockdep(wq); wq_free_lockdep(wq); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83B345337B; Sun, 24 Mar 2024 22:35:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319707; cv=none; b=pbUK5HU5RbgRcseLT5zOKVHQf3Egi6Z5Mj1qdceyT5amG9tRCqj4QA7Kz2KoTM5wSh325EbrYpSmstWAA7ZicxWMnTQ1m7Z58PkScN7UuFAA/5YVrI18YjO4KTcvfl6knRdXHmbPLxJ/q6+skgix7ob9/UEbmq5OuTEgiHQEWcs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319707; c=relaxed/simple; bh=HZfvyBjuHa7qCktrLVv/w9RQj3552P02ZDZhy98hFjw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Cx4FbTCKZnxWW0tWJrFxo7LNQBCvPwUONu0mfQVGN0ze9RN4AQ7jkWBnR1TScmFTSTwsNQ52rCVIQpCzYUHUChemNBNcOkSoXXWdnhtXMDDSSjtHFUc5XXkYbvFjyUpOd7Lm5QlrNYGp2qqNVCKsnbqUtkX0P5E70d1s28km10s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BMWwSGdM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BMWwSGdM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8D7DC43394; Sun, 24 Mar 2024 22:35:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319707; bh=HZfvyBjuHa7qCktrLVv/w9RQj3552P02ZDZhy98hFjw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BMWwSGdMp3aE2l2DjucWd0kRi6Qd4mgaDO4w1xFluoUO3BKiDl4skNYTeHuPEfgU2 lLEBfKAHSASp23D69lp7aetKryUmLbx/omz8reKWsC6Jsbuc2yQRnqcBzZ8lLfIebD z5ps0qTYh70ZMAcTuTgf4G/G2PPavCKh7vJcYl3KxGPRNGsCjDEfuHw4BlhMxsARHc bUQ2Kr3RqW2graDcKnooeupOywwmjc75W9QjhJ/W0yiWU72jgnlaBJ/AJg509Pkngi 4lBO4vACM0FoM+y2aPKmgjXoDTt1lVS4+G09TEy4sF+9EVYcmVImIDSvEVXii9Bw4g okt+8AB+ES9IA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tejun Heo , Naohiro Aota , Lai Jiangshan , Sasha Levin Subject: [PATCH 6.8 010/715] workqueue: Implement system-wide nr_active enforcement for unbound workqueues Date: Sun, 24 Mar 2024 18:23:09 -0400 Message-ID: <20240324223455.1342824-11-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tejun Heo [ Upstream commit 5797b1c18919cd9c289ded7954383e499f729ce0 ] A pool_workqueue (pwq) represents the connection between a workqueue and a worker_pool. One of the roles that a pwq plays is enforcement of the max_active concurrency limit. Before 636b927eba5b ("workqueue: Make unbound workqueues to use per-cpu pool_workqueues"), there was one pwq per each CPU for per-cpu workqueues and per each NUMA node for unbound workqueues, which was a natural result of per-cpu workqueues being served by per-cpu pools and unbound by per-NUMA pools. In terms of max_active enforcement, this was, while not perfect, workable. For per-cpu workqueues, it was fine. For unbound, it wasn't great in that NUMA machines would get max_active that's multiplied by the number of nodes but didn't cause huge problems because NUMA machines are relatively rare and the node count is usually pretty low. However, cache layouts are more complex now and sharing a worker pool across a whole node didn't really work well for unbound workqueues. Thus, a series of commits culminating on 8639ecebc9b1 ("workqueue: Make unbound workqueues to use per-cpu pool_workqueues") implemented more flexible affinity mechanism for unbound workqueues which enables using e.g. last-level-cache aligned pools. In the process, 636b927eba5b ("workqueue: Make unbound workqueues to use per-cpu pool_workqueues") made unbound workqueues use per-cpu pwqs like per-cpu workqueues. While the change was necessary to enable more flexible affinity scopes, this came with the side effect of blowing up the effective max_active for unbound workqueues. Before, the effective max_active for unbound workqueues was multiplied by the number of nodes. After, by the number of CPUs. 636b927eba5b ("workqueue: Make unbound workqueues to use per-cpu pool_workqueues") claims that this should generally be okay. It is okay for users which self-regulates concurrency level which are the vast majority; however, there are enough use cases which actually depend on max_active to prevent the level of concurrency from going bonkers including several IO handling workqueues that can issue a work item for each in-flight IO. With targeted benchmarks, the misbehavior can easily be exposed as reported in http://lkml.kernel.org/r/dbu6wiwu3sdhmhikb2w6lns7b27gbobfavhjj57kwi2quafgwl= @htjcc5oikcr3. Unfortunately, there is no way to express what these use cases need using per-cpu max_active. A CPU may issue most of in-flight IOs, so we don't want to set max_active too low but as soon as we increase max_active a bit, we can end up with unreasonable number of in-flight work items when many CPUs issue IOs at the same time. ie. The acceptable lowest max_active is higher than the acceptable highest max_active. Ideally, max_active for an unbound workqueue should be system-wide so that the users can regulate the total level of concurrency regardless of node and cache layout. The reasons workqueue hasn't implemented that yet are: - One max_active enforcement decouples from pool boundaires, chaining execution after a work item finishes requires inter-pool operations which would require lock dancing, which is nasty. - Sharing a single nr_active count across the whole system can be pretty expensive on NUMA machines. - Per-pwq enforcement had been more or less okay while we were using per-node pools. It looks like we no longer can avoid decoupling max_active enforcement from pool boundaries. This patch implements system-wide nr_active mechanism with the following design characteristics: - To avoid sharing a single counter across multiple nodes, the configured max_active is split across nodes according to the proportion of each workqueue's online effective CPUs per node. e.g. A node with twice more online effective CPUs will get twice higher portion of max_active. - Workqueue used to be able to process a chain of interdependent work items which is as long as max_active. We can't do this anymore as max_active is distributed across the nodes. Instead, a new parameter min_active is introduced which determines the minimum level of concurrency within a node regardless of how max_active distribution comes out to be. It is set to the smaller of max_active and WQ_DFL_MIN_ACTIVE which is 8. This can lead to higher effective max_weight than configured and also deadlocks if a workqueue was depending on being able to handle chains of interdependent work items that are longer than 8. I believe these should be fine given that the number of CPUs in each NUMA node is usually higher than 8 and work item chain longer than 8 is pretty unlikely. However, if these assumptions turn out to be wrong, we'll need to add an interface to adjust min_active. - Each unbound wq has an array of struct wq_node_nr_active which tracks per-node nr_active. When its pwq wants to run a work item, it has to obtain the matching node's nr_active. If over the node's max_active, the pwq is queued on wq_node_nr_active->pending_pwqs. As work items finish, the completion path round-robins the pending pwqs activating the first inactive work item of each, which involves some pool lock dancing and kicking other pools. It's not the simplest code but doesn't look too bad. v4: - wq_adjust_max_active() updated to invoke wq_update_node_max_active(). - wq_adjust_max_active() is now protected by wq->mutex instead of wq_pool_mutex. v3: - wq_node_max_active() used to calculate per-node max_active on the fly based on system-wide CPU online states. Lai pointed out that this can lead to skewed distributions for workqueues with restricted cpumasks. Update the max_active distribution to use per-workqueue effective online CPU counts instead of system-wide and cache the calculation results in node_nr_active->max. v2: - wq->min/max_active now uses WRITE/READ_ONCE() as suggested by Lai. Signed-off-by: Tejun Heo Reported-by: Naohiro Aota Link: http://lkml.kernel.org/r/dbu6wiwu3sdhmhikb2w6lns7b27gbobfavhjj57kwi2q= uafgwl@htjcc5oikcr3 Fixes: 636b927eba5b ("workqueue: Make unbound workqueues to use per-cpu poo= l_workqueues") Reviewed-by: Lai Jiangshan Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- include/linux/workqueue.h | 35 +++- kernel/workqueue.c | 341 ++++++++++++++++++++++++++++++++++---- 2 files changed, 341 insertions(+), 35 deletions(-) diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h index 2cc0a9606175f..515e7958c6c10 100644 --- a/include/linux/workqueue.h +++ b/include/linux/workqueue.h @@ -391,6 +391,13 @@ enum { WQ_MAX_ACTIVE =3D 512, /* I like 512, better ideas? */ WQ_UNBOUND_MAX_ACTIVE =3D WQ_MAX_ACTIVE, WQ_DFL_ACTIVE =3D WQ_MAX_ACTIVE / 2, + + /* + * Per-node default cap on min_active. Unless explicitly set, min_active + * is set to min(max_active, WQ_DFL_MIN_ACTIVE). For more details, see + * workqueue_struct->min_active definition. + */ + WQ_DFL_MIN_ACTIVE =3D 8, }; =20 /* @@ -433,11 +440,33 @@ extern struct workqueue_struct *system_freezable_powe= r_efficient_wq; * alloc_workqueue - allocate a workqueue * @fmt: printf format for the name of the workqueue * @flags: WQ_* flags - * @max_active: max in-flight work items per CPU, 0 for default + * @max_active: max in-flight work items, 0 for default * remaining args: args for @fmt * - * Allocate a workqueue with the specified parameters. For detailed - * information on WQ_* flags, please refer to + * For a per-cpu workqueue, @max_active limits the number of in-flight work + * items for each CPU. e.g. @max_active of 1 indicates that each CPU can be + * executing at most one work item for the workqueue. + * + * For unbound workqueues, @max_active limits the number of in-flight work= items + * for the whole system. e.g. @max_active of 16 indicates that that there = can be + * at most 16 work items executing for the workqueue in the whole system. + * + * As sharing the same active counter for an unbound workqueue across mult= iple + * NUMA nodes can be expensive, @max_active is distributed to each NUMA no= de + * according to the proportion of the number of online CPUs and enforced + * independently. + * + * Depending on online CPU distribution, a node may end up with per-node + * max_active which is significantly lower than @max_active, which can lea= d to + * deadlocks if the per-node concurrency limit is lower than the maximum n= umber + * of interdependent work items for the workqueue. + * + * To guarantee forward progress regardless of online CPU distribution, the + * concurrency limit on every node is guaranteed to be equal to or greater= than + * min_active which is set to min(@max_active, %WQ_DFL_MIN_ACTIVE). This m= eans + * that the sum of per-node max_active's may be larger than @max_active. + * + * For detailed information on %WQ_* flags, please refer to * Documentation/core-api/workqueue.rst. * * RETURNS: diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 686899845475f..4f3425ed62ed9 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -122,6 +122,9 @@ enum { * * L: pool->lock protected. Access with pool->lock held. * + * LN: pool->lock and wq_node_nr_active->lock protected for writes. Either= for + * reads. + * * K: Only modified by worker while holding pool->lock. Can be safely read= by * self, while holding pool->lock or from IRQ context if %current is the * kworker. @@ -243,17 +246,18 @@ struct pool_workqueue { * pwq->inactive_works instead of pool->worklist and marked with * WORK_STRUCT_INACTIVE. * - * All work items marked with WORK_STRUCT_INACTIVE do not participate - * in pwq->nr_active and all work items in pwq->inactive_works are - * marked with WORK_STRUCT_INACTIVE. But not all WORK_STRUCT_INACTIVE - * work items are in pwq->inactive_works. Some of them are ready to - * run in pool->worklist or worker->scheduled. Those work itmes are - * only struct wq_barrier which is used for flush_work() and should - * not participate in pwq->nr_active. For non-barrier work item, it - * is marked with WORK_STRUCT_INACTIVE iff it is in pwq->inactive_works. + * All work items marked with WORK_STRUCT_INACTIVE do not participate in + * nr_active and all work items in pwq->inactive_works are marked with + * WORK_STRUCT_INACTIVE. But not all WORK_STRUCT_INACTIVE work items are + * in pwq->inactive_works. Some of them are ready to run in + * pool->worklist or worker->scheduled. Those work itmes are only struct + * wq_barrier which is used for flush_work() and should not participate + * in nr_active. For non-barrier work item, it is marked with + * WORK_STRUCT_INACTIVE iff it is in pwq->inactive_works. */ int nr_active; /* L: nr of active works */ struct list_head inactive_works; /* L: inactive works */ + struct list_head pending_node; /* LN: node on wq_node_nr_active->pending_= pwqs */ struct list_head pwqs_node; /* WR: node on wq->pwqs */ struct list_head mayday_node; /* MD: node on wq->maydays */ =20 @@ -285,9 +289,19 @@ struct wq_device; * on each CPU, in an unbound workqueue, max_active applies to the whole s= ystem. * As sharing a single nr_active across multiple sockets can be very expen= sive, * the counting and enforcement is per NUMA node. + * + * The following struct is used to enforce per-node max_active. When a pwq= wants + * to start executing a work item, it should increment ->nr using + * tryinc_node_nr_active(). If acquisition fails due to ->nr already being= over + * ->max, the pwq is queued on ->pending_pwqs. As in-flight work items fin= ish + * and decrement ->nr, node_activate_pending_pwq() activates the pending p= wqs in + * round-robin order. */ struct wq_node_nr_active { - atomic_t nr; /* per-node nr_active count */ + int max; /* per-node max_active */ + atomic_t nr; /* per-node nr_active */ + raw_spinlock_t lock; /* nests inside pool locks */ + struct list_head pending_pwqs; /* LN: pwqs with inactive works */ }; =20 /* @@ -310,8 +324,12 @@ struct workqueue_struct { struct worker *rescuer; /* MD: rescue worker */ =20 int nr_drainers; /* WQ: drain in progress */ + + /* See alloc_workqueue() function comment for info on min/max_active */ int max_active; /* WO: max active works */ + int min_active; /* WO: min active works */ int saved_max_active; /* WQ: saved max_active */ + int saved_min_active; /* WQ: saved min_active */ =20 struct workqueue_attrs *unbound_attrs; /* PW: only for unbound wqs */ struct pool_workqueue __rcu *dfl_pwq; /* PW: only for unbound wqs */ @@ -663,6 +681,19 @@ static struct pool_workqueue *unbound_pwq(struct workq= ueue_struct *wq, int cpu) lockdep_is_held(&wq->mutex)); } =20 +/** + * unbound_effective_cpumask - effective cpumask of an unbound workqueue + * @wq: workqueue of interest + * + * @wq->unbound_attrs->cpumask contains the cpumask requested by the user = which + * is masked with wq_unbound_cpumask to determine the effective cpumask. T= he + * default pwq is always mapped to the pool with the current effective cpu= mask. + */ +static struct cpumask *unbound_effective_cpumask(struct workqueue_struct *= wq) +{ + return unbound_pwq(wq, -1)->pool->attrs->__pod_cpumask; +} + static unsigned int work_color_to_flags(int color) { return color << WORK_STRUCT_COLOR_SHIFT; @@ -1457,6 +1488,46 @@ static struct wq_node_nr_active *wq_node_nr_active(s= truct workqueue_struct *wq, return wq->node_nr_active[node]; } =20 +/** + * wq_update_node_max_active - Update per-node max_actives to use + * @wq: workqueue to update + * @off_cpu: CPU that's going down, -1 if a CPU is not going down + * + * Update @wq->node_nr_active[]->max. @wq must be unbound. max_active is + * distributed among nodes according to the proportions of numbers of onli= ne + * cpus. The result is always between @wq->min_active and max_active. + */ +static void wq_update_node_max_active(struct workqueue_struct *wq, int off= _cpu) +{ + struct cpumask *effective =3D unbound_effective_cpumask(wq); + int min_active =3D READ_ONCE(wq->min_active); + int max_active =3D READ_ONCE(wq->max_active); + int total_cpus, node; + + lockdep_assert_held(&wq->mutex); + + if (!cpumask_test_cpu(off_cpu, effective)) + off_cpu =3D -1; + + total_cpus =3D cpumask_weight_and(effective, cpu_online_mask); + if (off_cpu >=3D 0) + total_cpus--; + + for_each_node(node) { + int node_cpus; + + node_cpus =3D cpumask_weight_and(effective, cpumask_of_node(node)); + if (off_cpu >=3D 0 && cpu_to_node(off_cpu) =3D=3D node) + node_cpus--; + + wq_node_nr_active(wq, node)->max =3D + clamp(DIV_ROUND_UP(max_active * node_cpus, total_cpus), + min_active, max_active); + } + + wq_node_nr_active(wq, NUMA_NO_NODE)->max =3D min_active; +} + /** * get_pwq - get an extra reference on the specified pool_workqueue * @pwq: pool_workqueue to get @@ -1554,35 +1625,98 @@ static bool pwq_activate_work(struct pool_workqueue= *pwq, return true; } =20 +static bool tryinc_node_nr_active(struct wq_node_nr_active *nna) +{ + int max =3D READ_ONCE(nna->max); + + while (true) { + int old, tmp; + + old =3D atomic_read(&nna->nr); + if (old >=3D max) + return false; + tmp =3D atomic_cmpxchg_relaxed(&nna->nr, old, old + 1); + if (tmp =3D=3D old) + return true; + } +} + /** * pwq_tryinc_nr_active - Try to increment nr_active for a pwq * @pwq: pool_workqueue of interest + * @fill: max_active may have increased, try to increase concurrency level * * Try to increment nr_active for @pwq. Returns %true if an nr_active coun= t is * successfully obtained. %false otherwise. */ -static bool pwq_tryinc_nr_active(struct pool_workqueue *pwq) +static bool pwq_tryinc_nr_active(struct pool_workqueue *pwq, bool fill) { struct workqueue_struct *wq =3D pwq->wq; struct worker_pool *pool =3D pwq->pool; struct wq_node_nr_active *nna =3D wq_node_nr_active(wq, pool->node); - bool obtained; + bool obtained =3D false; =20 lockdep_assert_held(&pool->lock); =20 - obtained =3D pwq->nr_active < READ_ONCE(wq->max_active); + if (!nna) { + /* per-cpu workqueue, pwq->nr_active is sufficient */ + obtained =3D pwq->nr_active < READ_ONCE(wq->max_active); + goto out; + } + + /* + * Unbound workqueue uses per-node shared nr_active $nna. If @pwq is + * already waiting on $nna, pwq_dec_nr_active() will maintain the + * concurrency level. Don't jump the line. + * + * We need to ignore the pending test after max_active has increased as + * pwq_dec_nr_active() can only maintain the concurrency level but not + * increase it. This is indicated by @fill. + */ + if (!list_empty(&pwq->pending_node) && likely(!fill)) + goto out; + + obtained =3D tryinc_node_nr_active(nna); + if (obtained) + goto out; + + /* + * Lockless acquisition failed. Lock, add ourself to $nna->pending_pwqs + * and try again. The smp_mb() is paired with the implied memory barrier + * of atomic_dec_return() in pwq_dec_nr_active() to ensure that either + * we see the decremented $nna->nr or they see non-empty + * $nna->pending_pwqs. + */ + raw_spin_lock(&nna->lock); + + if (list_empty(&pwq->pending_node)) + list_add_tail(&pwq->pending_node, &nna->pending_pwqs); + else if (likely(!fill)) + goto out_unlock; + + smp_mb(); + + obtained =3D tryinc_node_nr_active(nna); =20 - if (obtained) { + /* + * If @fill, @pwq might have already been pending. Being spuriously + * pending in cold paths doesn't affect anything. Let's leave it be. + */ + if (obtained && likely(!fill)) + list_del_init(&pwq->pending_node); + +out_unlock: + raw_spin_unlock(&nna->lock); +out: + if (obtained) pwq->nr_active++; - if (nna) - atomic_inc(&nna->nr); - } return obtained; } =20 /** * pwq_activate_first_inactive - Activate the first inactive work item on = a pwq * @pwq: pool_workqueue of interest + * @fill: max_active may have increased, try to increase concurrency level * * Activate the first inactive work item of @pwq if available and allowed = by * max_active limit. @@ -1590,13 +1724,13 @@ static bool pwq_tryinc_nr_active(struct pool_workqu= eue *pwq) * Returns %true if an inactive work item has been activated. %false if no * inactive work item is found or max_active limit is reached. */ -static bool pwq_activate_first_inactive(struct pool_workqueue *pwq) +static bool pwq_activate_first_inactive(struct pool_workqueue *pwq, bool f= ill) { struct work_struct *work =3D list_first_entry_or_null(&pwq->inactive_works, struct work_struct, entry); =20 - if (work && pwq_tryinc_nr_active(pwq)) { + if (work && pwq_tryinc_nr_active(pwq, fill)) { __pwq_activate_work(pwq, work); return true; } else { @@ -1604,11 +1738,93 @@ static bool pwq_activate_first_inactive(struct pool= _workqueue *pwq) } } =20 +/** + * node_activate_pending_pwq - Activate a pending pwq on a wq_node_nr_acti= ve + * @nna: wq_node_nr_active to activate a pending pwq for + * @caller_pool: worker_pool the caller is locking + * + * Activate a pwq in @nna->pending_pwqs. Called with @caller_pool locked. + * @caller_pool may be unlocked and relocked to lock other worker_pools. + */ +static void node_activate_pending_pwq(struct wq_node_nr_active *nna, + struct worker_pool *caller_pool) +{ + struct worker_pool *locked_pool =3D caller_pool; + struct pool_workqueue *pwq; + struct work_struct *work; + + lockdep_assert_held(&caller_pool->lock); + + raw_spin_lock(&nna->lock); +retry: + pwq =3D list_first_entry_or_null(&nna->pending_pwqs, + struct pool_workqueue, pending_node); + if (!pwq) + goto out_unlock; + + /* + * If @pwq is for a different pool than @locked_pool, we need to lock + * @pwq->pool->lock. Let's trylock first. If unsuccessful, do the unlock + * / lock dance. For that, we also need to release @nna->lock as it's + * nested inside pool locks. + */ + if (pwq->pool !=3D locked_pool) { + raw_spin_unlock(&locked_pool->lock); + locked_pool =3D pwq->pool; + if (!raw_spin_trylock(&locked_pool->lock)) { + raw_spin_unlock(&nna->lock); + raw_spin_lock(&locked_pool->lock); + raw_spin_lock(&nna->lock); + goto retry; + } + } + + /* + * $pwq may not have any inactive work items due to e.g. cancellations. + * Drop it from pending_pwqs and see if there's another one. + */ + work =3D list_first_entry_or_null(&pwq->inactive_works, + struct work_struct, entry); + if (!work) { + list_del_init(&pwq->pending_node); + goto retry; + } + + /* + * Acquire an nr_active count and activate the inactive work item. If + * $pwq still has inactive work items, rotate it to the end of the + * pending_pwqs so that we round-robin through them. This means that + * inactive work items are not activated in queueing order which is fine + * given that there has never been any ordering across different pwqs. + */ + if (likely(tryinc_node_nr_active(nna))) { + pwq->nr_active++; + __pwq_activate_work(pwq, work); + + if (list_empty(&pwq->inactive_works)) + list_del_init(&pwq->pending_node); + else + list_move_tail(&pwq->pending_node, &nna->pending_pwqs); + + /* if activating a foreign pool, make sure it's running */ + if (pwq->pool !=3D caller_pool) + kick_pool(pwq->pool); + } + +out_unlock: + raw_spin_unlock(&nna->lock); + if (locked_pool !=3D caller_pool) { + raw_spin_unlock(&locked_pool->lock); + raw_spin_lock(&caller_pool->lock); + } +} + /** * pwq_dec_nr_active - Retire an active count * @pwq: pool_workqueue of interest * * Decrement @pwq's nr_active and try to activate the first inactive work = item. + * For unbound workqueues, this function may temporarily drop @pwq->pool->= lock. */ static void pwq_dec_nr_active(struct pool_workqueue *pwq) { @@ -1628,12 +1844,29 @@ static void pwq_dec_nr_active(struct pool_workqueue= *pwq) * inactive work item on @pwq itself. */ if (!nna) { - pwq_activate_first_inactive(pwq); + pwq_activate_first_inactive(pwq, false); return; } =20 - atomic_dec(&nna->nr); - pwq_activate_first_inactive(pwq); + /* + * If @pwq is for an unbound workqueue, it's more complicated because + * multiple pwqs and pools may be sharing the nr_active count. When a + * pwq needs to wait for an nr_active count, it puts itself on + * $nna->pending_pwqs. The following atomic_dec_return()'s implied + * memory barrier is paired with smp_mb() in pwq_tryinc_nr_active() to + * guarantee that either we see non-empty pending_pwqs or they see + * decremented $nna->nr. + * + * $nna->max may change as CPUs come online/offline and @pwq->wq's + * max_active gets updated. However, it is guaranteed to be equal to or + * larger than @pwq->wq->min_active which is above zero unless freezing. + * This maintains the forward progress guarantee. + */ + if (atomic_dec_return(&nna->nr) >=3D READ_ONCE(nna->max)) + return; + + if (!list_empty(&nna->pending_pwqs)) + node_activate_pending_pwq(nna, pool); } =20 /** @@ -1954,7 +2187,7 @@ static void __queue_work(int cpu, struct workqueue_st= ruct *wq, * @work must also queue behind existing inactive work items to maintain * ordering when max_active changes. See wq_adjust_max_active(). */ - if (list_empty(&pwq->inactive_works) && pwq_tryinc_nr_active(pwq)) { + if (list_empty(&pwq->inactive_works) && pwq_tryinc_nr_active(pwq, false))= { if (list_empty(&pool->worklist)) pool->watchdog_ts =3D jiffies; =20 @@ -3187,7 +3420,7 @@ static void insert_wq_barrier(struct pool_workqueue *= pwq, =20 barr->task =3D current; =20 - /* The barrier work item does not participate in pwq->nr_active. */ + /* The barrier work item does not participate in nr_active. */ work_flags |=3D WORK_STRUCT_INACTIVE; =20 /* @@ -4103,6 +4336,8 @@ static void free_node_nr_active(struct wq_node_nr_act= ive **nna_ar) static void init_node_nr_active(struct wq_node_nr_active *nna) { atomic_set(&nna->nr, 0); + raw_spin_lock_init(&nna->lock); + INIT_LIST_HEAD(&nna->pending_pwqs); } =20 /* @@ -4342,6 +4577,15 @@ static void pwq_release_workfn(struct kthread_work *= work) mutex_unlock(&wq_pool_mutex); } =20 + if (!list_empty(&pwq->pending_node)) { + struct wq_node_nr_active *nna =3D + wq_node_nr_active(pwq->wq, pwq->pool->node); + + raw_spin_lock_irq(&nna->lock); + list_del_init(&pwq->pending_node); + raw_spin_unlock_irq(&nna->lock); + } + call_rcu(&pwq->rcu, rcu_free_pwq); =20 /* @@ -4367,6 +4611,7 @@ static void init_pwq(struct pool_workqueue *pwq, stru= ct workqueue_struct *wq, pwq->flush_color =3D -1; pwq->refcnt =3D 1; INIT_LIST_HEAD(&pwq->inactive_works); + INIT_LIST_HEAD(&pwq->pending_node); INIT_LIST_HEAD(&pwq->pwqs_node); INIT_LIST_HEAD(&pwq->mayday_node); kthread_init_work(&pwq->release_work, pwq_release_workfn); @@ -4574,6 +4819,9 @@ static void apply_wqattrs_commit(struct apply_wqattrs= _ctx *ctx) ctx->pwq_tbl[cpu]); ctx->dfl_pwq =3D install_unbound_pwq(ctx->wq, -1, ctx->dfl_pwq); =20 + /* update node_nr_active->max */ + wq_update_node_max_active(ctx->wq, -1); + mutex_unlock(&ctx->wq->mutex); } =20 @@ -4834,24 +5082,35 @@ static int init_rescuer(struct workqueue_struct *wq) static void wq_adjust_max_active(struct workqueue_struct *wq) { bool activated; + int new_max, new_min; =20 lockdep_assert_held(&wq->mutex); =20 if ((wq->flags & WQ_FREEZABLE) && workqueue_freezing) { - WRITE_ONCE(wq->max_active, 0); - return; + new_max =3D 0; + new_min =3D 0; + } else { + new_max =3D wq->saved_max_active; + new_min =3D wq->saved_min_active; } =20 - if (wq->max_active =3D=3D wq->saved_max_active) + if (wq->max_active =3D=3D new_max && wq->min_active =3D=3D new_min) return; =20 /* - * Update @wq->max_active and then kick inactive work items if more + * Update @wq->max/min_active and then kick inactive work items if more * active work items are allowed. This doesn't break work item ordering * because new work items are always queued behind existing inactive * work items if there are any. */ - WRITE_ONCE(wq->max_active, wq->saved_max_active); + WRITE_ONCE(wq->max_active, new_max); + WRITE_ONCE(wq->min_active, new_min); + + if (wq->flags & WQ_UNBOUND) + wq_update_node_max_active(wq, -1); + + if (new_max =3D=3D 0) + return; =20 /* * Round-robin through pwq's activating the first inactive work item @@ -4866,7 +5125,7 @@ static void wq_adjust_max_active(struct workqueue_str= uct *wq) =20 /* can be called during early boot w/ irq disabled */ raw_spin_lock_irqsave(&pwq->pool->lock, flags); - if (pwq_activate_first_inactive(pwq)) { + if (pwq_activate_first_inactive(pwq, true)) { activated =3D true; kick_pool(pwq->pool); } @@ -4928,7 +5187,9 @@ struct workqueue_struct *alloc_workqueue(const char *= fmt, /* init wq */ wq->flags =3D flags; wq->max_active =3D max_active; - wq->saved_max_active =3D max_active; + wq->min_active =3D min(max_active, WQ_DFL_MIN_ACTIVE); + wq->saved_max_active =3D wq->max_active; + wq->saved_min_active =3D wq->min_active; mutex_init(&wq->mutex); atomic_set(&wq->nr_pwqs_to_flush, 0); INIT_LIST_HEAD(&wq->pwqs); @@ -5094,7 +5355,8 @@ EXPORT_SYMBOL_GPL(destroy_workqueue); * @wq: target workqueue * @max_active: new max_active value. * - * Set max_active of @wq to @max_active. + * Set max_active of @wq to @max_active. See the alloc_workqueue() function + * comment. * * CONTEXT: * Don't call from IRQ context. @@ -5111,6 +5373,9 @@ void workqueue_set_max_active(struct workqueue_struct= *wq, int max_active) =20 wq->flags &=3D ~__WQ_ORDERED; wq->saved_max_active =3D max_active; + if (wq->flags & WQ_UNBOUND) + wq->saved_min_active =3D min(wq->saved_min_active, max_active); + wq_adjust_max_active(wq); =20 mutex_unlock(&wq->mutex); @@ -5792,6 +6057,10 @@ int workqueue_online_cpu(unsigned int cpu) =20 for_each_cpu(tcpu, pt->pod_cpus[pt->cpu_pod[cpu]]) wq_update_pod(wq, tcpu, cpu, true); + + mutex_lock(&wq->mutex); + wq_update_node_max_active(wq, -1); + mutex_unlock(&wq->mutex); } } =20 @@ -5820,6 +6089,10 @@ int workqueue_offline_cpu(unsigned int cpu) =20 for_each_cpu(tcpu, pt->pod_cpus[pt->cpu_pod[cpu]]) wq_update_pod(wq, tcpu, cpu, false); + + mutex_lock(&wq->mutex); + wq_update_node_max_active(wq, cpu); + mutex_unlock(&wq->mutex); } } mutex_unlock(&wq_pool_mutex); @@ -7100,8 +7373,12 @@ void __init workqueue_init_topology(void) * combinations to apply per-pod sharing. */ list_for_each_entry(wq, &workqueues, list) { - for_each_online_cpu(cpu) { + for_each_online_cpu(cpu) wq_update_pod(wq, cpu, cpu, true); + if (wq->flags & WQ_UNBOUND) { + mutex_lock(&wq->mutex); + wq_update_node_max_active(wq, -1); + mutex_unlock(&wq->mutex); } } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E3F165381B; Sun, 24 Mar 2024 22:35:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319709; cv=none; b=bRm9qiSK1v9UeXx/4cFqz+BBAv6ZOogAc/FKKMb2EEBab9zMrAfJlPz27PJ5cz+4NqIwyvlUs3lAyxapUZO0l2jLWGjyUZOtqE9sqIllsohaBe1XAjm4mnV7eS+Bfcf1CZqPN5SNaDOQBklugxcEluGr/EVbViX2U6NTN3DSGY8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319709; c=relaxed/simple; bh=WDc2CdjJwHVoN79rGTJFg+3uVuux82aXT82wcc+F104=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aLEVFuxBMsvWzyo8ExBKDztqrHOlVGuUGiI0sMr4oAL3yv3/vNaOA1JXnqnRYbqU7GZ4WN95NxR+pTIe72dreuQ7p/BvpgkZksG94TO66uP6dgk1JyXzK1los2xjtXktr1QF5MFsyhwWm8bKucED9WdoYu5nrDbqghHq0xjA2vQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p0Ya6EQH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p0Ya6EQH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A568FC43399; Sun, 24 Mar 2024 22:35:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319708; bh=WDc2CdjJwHVoN79rGTJFg+3uVuux82aXT82wcc+F104=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p0Ya6EQH2C4Jkol610Y/ZJT/WcZ/g08bzDzgcYVCkuEhINKGGgxg7kt+Kq3mKNzJy 42CfyLVjw0fEI3SSGjlS15jI9G8uUvaLBk8LTdRKTKcrZdIQ3aFgHcb3GxumY2jjnu iiBekV/OL9KahUOdqBkPy9R47uAoGIwXxrOS0xBl8JZD6k7eQm3B4sksK0+Z7SVurf K9K1s9BQmDqfon2MS5aLCgzuyzEGZqC5ae0PP3MPruBlBqkoHpDcTr1Ixo/URCRZ9y dE+BG+Q+45sReCvcs1bmoJovlLlPWkJf6P4xmgmW8UDpva990oHCiNYVTp0/dHW3u4 0A9WZR+JekC2w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tejun Heo , Marek Szyprowski , Nathan Chancellor , Sasha Levin Subject: [PATCH 6.8 011/715] workqueue: Don't call cpumask_test_cpu() with -1 CPU in wq_update_node_max_active() Date: Sun, 24 Mar 2024 18:23:10 -0400 Message-ID: <20240324223455.1342824-12-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tejun Heo [ Upstream commit 15930da42f8981dc42c19038042947b475b19f47 ] For wq_update_node_max_active(), @off_cpu of -1 indicates that no CPU is going down. The function was incorrectly calling cpumask_test_cpu() with -1 CPU leading to oopses like the following on some archs: Unable to handle kernel paging request at virtual address ffff0002100296e0 .. pc : wq_update_node_max_active+0x50/0x1fc lr : wq_update_node_max_active+0x1f0/0x1fc ... Call trace: wq_update_node_max_active+0x50/0x1fc apply_wqattrs_commit+0xf0/0x114 apply_workqueue_attrs_locked+0x58/0xa0 alloc_workqueue+0x5ac/0x774 workqueue_init_early+0x460/0x540 start_kernel+0x258/0x684 __primary_switched+0xb8/0xc0 Code: 9100a273 35000d01 53067f00 d0016dc1 (f8607a60) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Attempted to kill the idle task! ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- Fix it. Signed-off-by: Tejun Heo Reported-by: Marek Szyprowski Reported-by: Nathan Chancellor Tested-by: Nathan Chancellor Link: http://lkml.kernel.org/r/91eacde0-df99-4d5c-a980-91046f66e612@samsung= .com Fixes: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcemen= t for unbound workqueues") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/workqueue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/workqueue.c b/kernel/workqueue.c index 4f3425ed62ed9..ed8ebc9776016 100644 --- a/kernel/workqueue.c +++ b/kernel/workqueue.c @@ -1506,7 +1506,7 @@ static void wq_update_node_max_active(struct workqueu= e_struct *wq, int off_cpu) =20 lockdep_assert_held(&wq->mutex); =20 - if (!cpumask_test_cpu(off_cpu, effective)) + if (off_cpu >=3D 0 && !cpumask_test_cpu(off_cpu, effective)) off_cpu =3D -1; =20 total_cpus =3D cpumask_weight_and(effective, cpu_online_mask); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A8845548E3; Sun, 24 Mar 2024 22:35:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319709; cv=none; b=CHwHHl2uHNU2Lt3WLXxY5fDO3h11wItifn3B7evsUnrpaA+CTb7sCY+A9ir6GnQdtxQnnvMGE93GNvOEkeCEKa5Ii3QJG/keMcBSE2FhJ/rt+NzQks2dc+UBirbsg9dh0dzrjXJFKiYnSJ25uo9KA1J74PYKbLmcAy4iWdgCssM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319709; c=relaxed/simple; bh=UZ1IFt2fs6RF2Ir542kA8pBRLhL3MsJPGgyv1aIBtTc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gKskoOjN0pxxadEruF6WE46baHL8VxiL6FHhA42X/x63EM02x8vQT6XmmBzi3559fmKM+5D41duHFh5GtBxeqkRRcjLGeDN733kyrRuYHk1uIBvhYxOaEyIJyQZVwjsxPGYbyWsU6kVnV+tXwOJiqF8YJJ6XBkYZI8T40NWeHcY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Mxv0l1Rx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Mxv0l1Rx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9EA44C433C7; Sun, 24 Mar 2024 22:35:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319709; bh=UZ1IFt2fs6RF2Ir542kA8pBRLhL3MsJPGgyv1aIBtTc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Mxv0l1RxE1eBJejMbHzZrAV5cYd5P76pIpPvCSCrjM8/Huhw2texGJRpUcsQWmXv0 b15y9SM8JfxUuIPrWpMCZGbvzK7zFxGJPkmJqsLL3x5H7sEPMcxuEe42OQNBNy7dFf EKKSJ/Uuddl/lR8Yw7pQTA+DZQc6tOBr5ErRCuvV8wops4YytU+j3rFYV1eiWyzAsX PNQ+Gqx7I/MdgWSBIH0q+ZEhWOSM1Y5vdWk3B8aBomY6h5HNUjtlxn9KQXIvIrsBS2 nD0cZsuPedz9mbzGsNexqopIo5cPeZuWZ3MKsr166mtUPLUS4PpRr7bvzr6BrUdnHm /PxqYykk5+Hfg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christoph Hellwig , Christian Brauner , Sasha Levin Subject: [PATCH 6.8 012/715] iomap: clear the per-folio dirty bits on all writeback failures Date: Sun, 24 Mar 2024 18:23:11 -0400 Message-ID: <20240324223455.1342824-13-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Christoph Hellwig [ Upstream commit 7ea1d9b4a840c2dd01d1234663d4a8ef256cfe39 ] write_cache_pages always clear the page dirty bit before calling into the file systems, and leaves folios with a writeback failure without the dirty bit after return. We also clear the per-block writeback bits for writeback failures unless no I/O has submitted, which will leave the folio in an inconsistent state where it doesn't have the folio dirty, but one or more per-block dirty bits. This seems to be due the place where the iomap_clear_range_dirty call was inserted into the existing not very clearly structured code when adding per-block dirty bit support and not actually intentional. Switch to always clearing the dirty on writeback failure. Fixes: 4ce02c679722 ("iomap: Add per-block dirty state tracking to improve = performance") Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20231207072710.176093-2-hch@lst.de Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- fs/iomap/buffered-io.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c index 093c4515b22a5..228fd2e05e12f 100644 --- a/fs/iomap/buffered-io.c +++ b/fs/iomap/buffered-io.c @@ -1833,16 +1833,10 @@ iomap_writepage_map(struct iomap_writepage_ctx *wpc, if (unlikely(error)) { /* * Let the filesystem know what portion of the current page - * failed to map. If the page hasn't been added to ioend, it - * won't be affected by I/O completion and we must unlock it - * now. + * failed to map. */ if (wpc->ops->discard_folio) wpc->ops->discard_folio(folio, pos); - if (!count) { - folio_unlock(folio); - goto done; - } } =20 /* @@ -1851,6 +1845,16 @@ iomap_writepage_map(struct iomap_writepage_ctx *wpc, * all the dirty bits in the folio here. */ iomap_clear_range_dirty(folio, 0, folio_size(folio)); + + /* + * If the page hasn't been added to the ioend, it won't be affected by + * I/O completion and we must unlock it now. + */ + if (error && !count) { + folio_unlock(folio); + goto done; + } + folio_start_writeback(folio); folio_unlock(folio); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D9A1554916; Sun, 24 Mar 2024 22:35:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319710; cv=none; b=PCHd4/JWZPQmj1mhmiyaKY4JIsrMRWMrxn6R1aFJJ4RLnzR0HaHp91lEvp14YfB7tC8WdtvqRhuq2R5jinOtDYEYHUVXOEjSP5VqRU2QTlWVfhCrMW1urrgzsIbX2m8JLXd+CwQ8UvRnX9Rl5cHo9N+Upxmz7hztJpoz1T1pVbk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319710; c=relaxed/simple; bh=76vkGyrV3hb3aWyw3PS3hSUigT9JbLaVi74F4EZkltQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Q5s2qc38bKclZY4z5PJiZWc0cmYrxoK1NhFwnU2li7D3TFG3qFpAcCAmrjBHKxQe0f/07a3z9cgTSrfI02JCQ2cav/TkQUNmSLJCk0yLjM0DcnlYbds5XtfjUW6TEqS6IVp3Osaxx5wmMt1Z8fw+raBLQUk9sWK5u9pPD2+53mM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KjrBFK2j; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KjrBFK2j" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 85C28C433F1; Sun, 24 Mar 2024 22:35:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319710; bh=76vkGyrV3hb3aWyw3PS3hSUigT9JbLaVi74F4EZkltQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KjrBFK2jOlWhfJ0YF1t2+n+lPhqZGV6fseqd2hDAv1HlOEm2++2m94rhNqpI+mkYg dXDcWyI7pdPVKmdm7c2A26jF2+YWjC4Kmf8kVdvuRjE+A6pe1VoBa4xoKpdvhn+B7Z g2L74Nnfp4PNhII0FUvej4HfHNVx9tRyjZ/GlKwrBsgk6CI9qqbXOamjTF+mqJlggV REYpjTrhSfQkHy2+98Xjp26OfeoNCIhvlYQ5wBPSXRo64VAE+BB0yKlyTUT7xtj3F7 mG+iISNIhrGlpLKwLodVeFLHbFCasZPyQ9Kvh1t9kve7JdFBfLhcDGgWZWEWinMVt7 QI31NR2mY4U8w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bart Van Assche , Christoph Hellwig , Kanchan Joshi , Jeff Layton , Chuck Lever , Jens Axboe , Stephen Rothwell , Christian Brauner , Sasha Levin Subject: [PATCH 6.8 013/715] fs: Fix rw_hint validation Date: Sun, 24 Mar 2024 18:23:12 -0400 Message-ID: <20240324223455.1342824-14-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bart Van Assche [ Upstream commit ec16b147a55bfa14e858234eb7b1a7c8e7cd5021 ] Reject values that are valid rw_hints after truncation but not before truncation by passing an untruncated value to rw_hint_valid(). Reviewed-by: Christoph Hellwig Reviewed-by: Kanchan Joshi Cc: Jeff Layton Cc: Chuck Lever Cc: Jens Axboe Cc: Stephen Rothwell Fixes: 5657cb0797c4 ("fs/fcntl: use copy_to/from_user() for u64 types") Signed-off-by: Bart Van Assche Link: https://lore.kernel.org/r/20240202203926.2478590-2-bvanassche@acm.org Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- fs/fcntl.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/fs/fcntl.c b/fs/fcntl.c index c80a6acad742f..3ff707bf2743a 100644 --- a/fs/fcntl.c +++ b/fs/fcntl.c @@ -268,7 +268,7 @@ static int f_getowner_uids(struct file *filp, unsigned = long arg) } #endif =20 -static bool rw_hint_valid(enum rw_hint hint) +static bool rw_hint_valid(u64 hint) { switch (hint) { case RWH_WRITE_LIFE_NOT_SET: @@ -288,19 +288,17 @@ static long fcntl_rw_hint(struct file *file, unsigned= int cmd, { struct inode *inode =3D file_inode(file); u64 __user *argp =3D (u64 __user *)arg; - enum rw_hint hint; - u64 h; + u64 hint; =20 switch (cmd) { case F_GET_RW_HINT: - h =3D inode->i_write_hint; - if (copy_to_user(argp, &h, sizeof(*argp))) + hint =3D inode->i_write_hint; + if (copy_to_user(argp, &hint, sizeof(*argp))) return -EFAULT; return 0; case F_SET_RW_HINT: - if (copy_from_user(&h, argp, sizeof(h))) + if (copy_from_user(&hint, argp, sizeof(hint))) return -EFAULT; - hint =3D (enum rw_hint) h; if (!rw_hint_valid(hint)) return -EINVAL; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1961356475; Sun, 24 Mar 2024 22:35:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319712; cv=none; b=Td3mNCAbxNHO0EfrIdUsZNOThBLSoot6MXJYU01hSBbiM3zbO7EJFwMJFvrB0hbKz0YVYd/TTCJZyA14okA/J3nIcFlfJIAFPXVDxDh02qSSSZ6h0ItUX4Noh9JS7pzygcgZ2OIWKS9KEoxySywF+Xbckkkv5Ad4dR5mkccJP4Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319712; c=relaxed/simple; bh=RJktv4e4kUbn7b3tmJcoyfQyqcymeuVaVCsOQ4HQ5xg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OuaXJpy2otuma+aVndlyJb8E1XQwlzdJG+ObAf+QvQsqRYukhygcKIuthPzPgO4Vgg7FsP0zl60rVxhIaqhBPB+xOLJqEBm+RVFH0Gh5JjecB7L2egMJptCZ5uV5zQSzt8Nty9W64jIbpwggMV9qOpIwi68ctl2az57S3+dUQcg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BSfArjWM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BSfArjWM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0AABBC433A6; Sun, 24 Mar 2024 22:35:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319711; bh=RJktv4e4kUbn7b3tmJcoyfQyqcymeuVaVCsOQ4HQ5xg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BSfArjWMU03ioIvbig9Q4wjCfx6iPmZm3lk6IE5sSF9Rk1YJdyLrjRpKysfd3Gw0F 7jIVPcHbK57XmvDu72yr6b/7HaS6f8QhWXjfFRnq86TNECZ2cy2ijuUSC+BXXGCFOd dHOLFfLcm8V5eyOMC8HX9N8tlDWFRA2AbE8JuWHUhUD3t/ejAj62y4gv/MBzyql4L8 4nRMx+657dvIWmUokFcIbqWkBF+58ZByoRhQA++KDv4YmKtb0q272ce121Q3uX6oQd hGXuDDKbyXTF3pjwt0rIIsf6Fzk4VCicMyil9Ntp84qrnLRZjpExnr9TvQ7dQksb6z qj0FuNCfk5ROw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jens Axboe , Sasha Levin Subject: [PATCH 6.8 014/715] io_uring: remove looping around handling traditional task_work Date: Sun, 24 Mar 2024 18:23:13 -0400 Message-ID: <20240324223455.1342824-15-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jens Axboe [ Upstream commit 592b4805432af075468876771c0f7d41273ccb3c ] A previous commit added looping around handling traditional task_work as an optimization, and while that may seem like a good idea, it's also possible to run into application starvation doing so. If the task_work generation is bursty, we can get very deep task_work queues, and we can end up looping in here for a very long time. One immediately observable problem with that is handling network traffic using provided buffers, where flooding incoming traffic and looping task_work handling will very quickly lead to buffer starvation as we keep running task_work rather than returning to the application so it can handle the associated CQEs and also provide buffers back. Fixes: 3a0c037b0e16 ("io_uring: batch task_work") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- io_uring/io_uring.c | 45 +++++++-------------------------------------- 1 file changed, 7 insertions(+), 38 deletions(-) diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c index cd9a137ad6cef..5233a20d01b54 100644 --- a/io_uring/io_uring.c +++ b/io_uring/io_uring.c @@ -1176,12 +1176,11 @@ static void ctx_flush_and_put(struct io_ring_ctx *c= tx, struct io_tw_state *ts) =20 static unsigned int handle_tw_list(struct llist_node *node, struct io_ring_ctx **ctx, - struct io_tw_state *ts, - struct llist_node *last) + struct io_tw_state *ts) { unsigned int count =3D 0; =20 - while (node && node !=3D last) { + do { struct llist_node *next =3D node->next; struct io_kiocb *req =3D container_of(node, struct io_kiocb, io_task_work.node); @@ -1205,7 +1204,7 @@ static unsigned int handle_tw_list(struct llist_node = *node, *ctx =3D NULL; cond_resched(); } - } + } while (node); =20 return count; } @@ -1224,22 +1223,6 @@ static inline struct llist_node *io_llist_xchg(struc= t llist_head *head, return xchg(&head->first, new); } =20 -/** - * io_llist_cmpxchg - possibly swap all entries in a lock-less list - * @head: the head of lock-less list to delete all entries - * @old: expected old value of the first entry of the list - * @new: new entry as the head of the list - * - * perform a cmpxchg on the first entry of the list. - */ - -static inline struct llist_node *io_llist_cmpxchg(struct llist_head *head, - struct llist_node *old, - struct llist_node *new) -{ - return cmpxchg(&head->first, old, new); -} - static __cold void io_fallback_tw(struct io_uring_task *tctx, bool sync) { struct llist_node *node =3D llist_del_all(&tctx->task_list); @@ -1274,9 +1257,7 @@ void tctx_task_work(struct callback_head *cb) struct io_ring_ctx *ctx =3D NULL; struct io_uring_task *tctx =3D container_of(cb, struct io_uring_task, task_work); - struct llist_node fake =3D {}; struct llist_node *node; - unsigned int loops =3D 0; unsigned int count =3D 0; =20 if (unlikely(current->flags & PF_EXITING)) { @@ -1284,21 +1265,9 @@ void tctx_task_work(struct callback_head *cb) return; } =20 - do { - loops++; - node =3D io_llist_xchg(&tctx->task_list, &fake); - count +=3D handle_tw_list(node, &ctx, &ts, &fake); - - /* skip expensive cmpxchg if there are items in the list */ - if (READ_ONCE(tctx->task_list.first) !=3D &fake) - continue; - if (ts.locked && !wq_list_empty(&ctx->submit_state.compl_reqs)) { - io_submit_flush_completions(ctx); - if (READ_ONCE(tctx->task_list.first) !=3D &fake) - continue; - } - node =3D io_llist_cmpxchg(&tctx->task_list, &fake, NULL); - } while (node !=3D &fake); + node =3D llist_del_all(&tctx->task_list); + if (node) + count =3D handle_tw_list(node, &ctx, &ts); =20 ctx_flush_and_put(ctx, &ts); =20 @@ -1306,7 +1275,7 @@ void tctx_task_work(struct callback_head *cb) if (unlikely(atomic_read(&tctx->in_cancel))) io_uring_drop_tctx_refs(current); =20 - trace_io_uring_task_work_run(tctx, count, loops); + trace_io_uring_task_work_run(tctx, count, 1); } =20 static inline void io_req_local_work_add(struct io_kiocb *req, unsigned fl= ags) --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C802157308; Sun, 24 Mar 2024 22:35:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319712; cv=none; b=jZvDwm/L43V72JakSqTTSFiRN/rPIJxKmo3fAEZUf7CWY1ejkAQEI/ynW++G1RKGuIoMtE6RNU8zFUNi/UUNRHwd5Laq9Yjhf/QX0TrJsJGzYd0QrSB+ga5wgo+o0VHNaRAjx4sF+PcjfVeGQJCfE3297qhvszvMsAxAwecW64U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319712; c=relaxed/simple; bh=ahYmKFAbYmpgZObyfuJr7+Oyxy1a3muSRCFbugkPj44=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tesgEo0Fp70uETVHRxglsHyBft6osnlQPzUKyiBo5h/g5FFnCUC/hcTC4tiCkn7uF1Pki9DnOySAKy5ODAk5Ges8qUe4WIH7+S7fcDUZqzRYFGXlK53dAjAaSD+CLRwBi5GMY3HsLJmmfMmu0hm/4YOI/kyFlQRvYAggAg9GD5o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Humg0umH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Humg0umH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0EC2C433C7; Sun, 24 Mar 2024 22:35:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319712; bh=ahYmKFAbYmpgZObyfuJr7+Oyxy1a3muSRCFbugkPj44=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Humg0umH+JpnXIafFNhyvdXlY27dKb+dSkv06cEcQMm0bMZ/23CLdrplho5AL1Ntf rBJGJvPpRDexuSvRul9jqozWpaBJVrzuTwmPdZLKs1GktmzAxsgdNGzrhXrHOewBkB Pgu439KBDd7Fwcb3/sjQKDWNLXWP8nKv4k9pKee4AKYjBO39UPD2vE93MeK/MPPFfq 4n0NkysdXGyMuI+W65J5tOmjZLAXZSZTesYpIXFTL/1lwOkzGRivdvzHgKh6h8dkIX REPxxAUMedASEgJp792NIjeYKfjWDmTthJc12ifwpUQssTYt/4HtzOnxzPzNB2YrYH TDZPLSeGz7dQg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jens Axboe , Sasha Levin Subject: [PATCH 6.8 015/715] io_uring: remove unconditional looping in local task_work handling Date: Sun, 24 Mar 2024 18:23:14 -0400 Message-ID: <20240324223455.1342824-16-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jens Axboe [ Upstream commit 9fe3eaea4a3530ca34a8d8ff00b1848c528789ca ] If we have a ton of notifications coming in, we can be looping in here for a long time. This can be problematic for various reasons, mostly because we can starve userspace. If the application is waiting on N events, then only re-run if we need more events. Fixes: c0e0d6ba25f1 ("io_uring: add IORING_SETUP_DEFER_TASKRUN") Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- io_uring/io_uring.c | 44 +++++++++++++++++++++++++++++--------------- 1 file changed, 29 insertions(+), 15 deletions(-) diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c index 5233a20d01b54..39dfb83dc9fc4 100644 --- a/io_uring/io_uring.c +++ b/io_uring/io_uring.c @@ -1389,7 +1389,20 @@ static void __cold io_move_task_work_from_local(stru= ct io_ring_ctx *ctx) } } =20 -static int __io_run_local_work(struct io_ring_ctx *ctx, struct io_tw_state= *ts) +static bool io_run_local_work_continue(struct io_ring_ctx *ctx, int events, + int min_events) +{ + if (llist_empty(&ctx->work_llist)) + return false; + if (events < min_events) + return true; + if (ctx->flags & IORING_SETUP_TASKRUN_FLAG) + atomic_or(IORING_SQ_TASKRUN, &ctx->rings->sq_flags); + return false; +} + +static int __io_run_local_work(struct io_ring_ctx *ctx, struct io_tw_state= *ts, + int min_events) { struct llist_node *node; unsigned int loops =3D 0; @@ -1418,18 +1431,20 @@ static int __io_run_local_work(struct io_ring_ctx *= ctx, struct io_tw_state *ts) } loops++; =20 - if (!llist_empty(&ctx->work_llist)) + if (io_run_local_work_continue(ctx, ret, min_events)) goto again; if (ts->locked) { io_submit_flush_completions(ctx); - if (!llist_empty(&ctx->work_llist)) + if (io_run_local_work_continue(ctx, ret, min_events)) goto again; } + trace_io_uring_local_work_run(ctx, ret, loops); return ret; } =20 -static inline int io_run_local_work_locked(struct io_ring_ctx *ctx) +static inline int io_run_local_work_locked(struct io_ring_ctx *ctx, + int min_events) { struct io_tw_state ts =3D { .locked =3D true, }; int ret; @@ -1437,20 +1452,20 @@ static inline int io_run_local_work_locked(struct i= o_ring_ctx *ctx) if (llist_empty(&ctx->work_llist)) return 0; =20 - ret =3D __io_run_local_work(ctx, &ts); + ret =3D __io_run_local_work(ctx, &ts, min_events); /* shouldn't happen! */ if (WARN_ON_ONCE(!ts.locked)) mutex_lock(&ctx->uring_lock); return ret; } =20 -static int io_run_local_work(struct io_ring_ctx *ctx) +static int io_run_local_work(struct io_ring_ctx *ctx, int min_events) { struct io_tw_state ts =3D {}; int ret; =20 ts.locked =3D mutex_trylock(&ctx->uring_lock); - ret =3D __io_run_local_work(ctx, &ts); + ret =3D __io_run_local_work(ctx, &ts, min_events); if (ts.locked) mutex_unlock(&ctx->uring_lock); =20 @@ -1646,7 +1661,7 @@ static int io_iopoll_check(struct io_ring_ctx *ctx, l= ong min) io_task_work_pending(ctx)) { u32 tail =3D ctx->cached_cq_tail; =20 - (void) io_run_local_work_locked(ctx); + (void) io_run_local_work_locked(ctx, min); =20 if (task_work_pending(current) || wq_list_empty(&ctx->iopoll_list)) { @@ -2489,7 +2504,7 @@ int io_run_task_work_sig(struct io_ring_ctx *ctx) { if (!llist_empty(&ctx->work_llist)) { __set_current_state(TASK_RUNNING); - if (io_run_local_work(ctx) > 0) + if (io_run_local_work(ctx, INT_MAX) > 0) return 0; } if (io_run_task_work() > 0) @@ -2557,7 +2572,7 @@ static int io_cqring_wait(struct io_ring_ctx *ctx, in= t min_events, if (!io_allowed_run_tw(ctx)) return -EEXIST; if (!llist_empty(&ctx->work_llist)) - io_run_local_work(ctx); + io_run_local_work(ctx, min_events); io_run_task_work(); io_cqring_overflow_flush(ctx); /* if user messes with these they will just get an early return */ @@ -2595,11 +2610,10 @@ static int io_cqring_wait(struct io_ring_ctx *ctx, = int min_events, =20 trace_io_uring_cqring_wait(ctx, min_events); do { + int nr_wait =3D (int) iowq.cq_tail - READ_ONCE(ctx->rings->cq.tail); unsigned long check_cq; =20 if (ctx->flags & IORING_SETUP_DEFER_TASKRUN) { - int nr_wait =3D (int) iowq.cq_tail - READ_ONCE(ctx->rings->cq.tail); - atomic_set(&ctx->cq_wait_nr, nr_wait); set_current_state(TASK_INTERRUPTIBLE); } else { @@ -2618,7 +2632,7 @@ static int io_cqring_wait(struct io_ring_ctx *ctx, in= t min_events, */ io_run_task_work(); if (!llist_empty(&ctx->work_llist)) - io_run_local_work(ctx); + io_run_local_work(ctx, nr_wait); =20 /* * Non-local task_work will be run on exit to userspace, but @@ -3273,7 +3287,7 @@ static __cold bool io_uring_try_cancel_requests(struc= t io_ring_ctx *ctx, =20 if ((ctx->flags & IORING_SETUP_DEFER_TASKRUN) && io_allowed_defer_tw_run(ctx)) - ret |=3D io_run_local_work(ctx) > 0; + ret |=3D io_run_local_work(ctx, INT_MAX) > 0; ret |=3D io_cancel_defer_files(ctx, task, cancel_all); mutex_lock(&ctx->uring_lock); ret |=3D io_poll_remove_all(ctx, task, cancel_all); @@ -3635,7 +3649,7 @@ SYSCALL_DEFINE6(io_uring_enter, unsigned int, fd, u32= , to_submit, * it should handle ownership problems if any. */ if (ctx->flags & IORING_SETUP_DEFER_TASKRUN) - (void)io_run_local_work_locked(ctx); + (void)io_run_local_work_locked(ctx, min_complete); } mutex_unlock(&ctx->uring_lock); } --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 899295789F; Sun, 24 Mar 2024 22:35:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319713; cv=none; b=bcFfLootJwItr5dBa6fM6YZ2xEFEG5y9yYZcr/DcvyFFiduJvstOxTdHyTAWDudeEhR5r08NVg5GQjECItEl2Cv/SH+9uCrHA7LwC0fwIqNVJKRIbWypxalu1gf+41/cva1wESAS1KjefvBXyceVHT3YYIrLXGgbD2vNRBBbUCg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319713; c=relaxed/simple; bh=bFPh+6OA+JYDyi7jFiN5kCZbCRHA5RJ6L5tddcxC0pA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=n1oE2NfnV7FGUXY4+y1Z32O/OLnksAo1gO+Y1cdvYZLGMyhIcxKih9o4Pq4VOpVtofvZbCMrl3htFgr3rBVLPRla+sG4ExOCNPszIdbcnNErJxm4AxLbZIOIB9KJlUoXxiTdXSMGTkPyptmV9KNS59rZOOU9/vBBA4rGmymEjVQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JH3rKjVH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JH3rKjVH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7FEAC433F1; Sun, 24 Mar 2024 22:35:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319713; bh=bFPh+6OA+JYDyi7jFiN5kCZbCRHA5RJ6L5tddcxC0pA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JH3rKjVH8Y6bsNTiH2jRaQ0XHJwDkHjp1dQg6QnaIgLIG4e7fLjeMN7Gt7Ua7N+3T kmlzHIps6xyyYwY6rrZ2u72Q5YDXQVBYE7hHlLoPo69BGP5hrbjEdr0UUSOqF876Cf UxbTH4QT2pzjm64X6lN3u1do24wS9KqqPJuYomLzcDS6J9H5IKf5MGCKs95u4nsqn7 qPPts4A6SAplvTiCvHPaFx4sMVzOwdVmLX5EBQs2PSENkDrMGbU1TVz4IWDltg2spR rr23FozmvgazXTFgpkIDymZd92P7MbxXdLFfoUOyLv9RJXKnzKdh0N4BOFij5onP9u OsrC7pJVkMSyQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Jan=20H=C3=B6ppner?= , Stefan Haberland , Jens Axboe , Sasha Levin Subject: [PATCH 6.8 016/715] s390/dasd: Use dev_*() for device log messages Date: Sun, 24 Mar 2024 18:23:15 -0400 Message-ID: <20240324223455.1342824-17-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Jan H=C3=B6ppner [ Upstream commit 79ae56fc475869d636071f66d9e4ef2a3819eee6 ] All log messages in dasd.c use the printk variants of pr_*(). They all add the name of the affected device manually to the log message. This can be simplified by using the dev_*() variants of printk, which include the device information and make a separate call to dev_name() unnecessary. The KMSG_COMPONENT and the pr_fmt() definition can be dropped. Note that this removes the "dasd: " prefix from the one pr_info() call in dasd_init(). However, the log message already provides all relevant information. Signed-off-by: Jan H=C3=B6ppner Reviewed-by: Stefan Haberland Signed-off-by: Stefan Haberland Link: https://lore.kernel.org/r/20240208164248.540985-10-sth@linux.ibm.com Signed-off-by: Jens Axboe Stable-dep-of: c3116e62ddef ("s390/dasd: fix double module refcount decreme= nt") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/s390/block/dasd.c | 50 +++++++++++++++++++-------------------- 1 file changed, 24 insertions(+), 26 deletions(-) diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c index 7327e81352e9c..4a7d70426a6e6 100644 --- a/drivers/s390/block/dasd.c +++ b/drivers/s390/block/dasd.c @@ -8,9 +8,6 @@ * Copyright IBM Corp. 1999, 2009 */ =20 -#define KMSG_COMPONENT "dasd" -#define pr_fmt(fmt) KMSG_COMPONENT ": " fmt - #include #include #include @@ -3402,8 +3399,7 @@ static void dasd_generic_auto_online(void *data, asyn= c_cookie_t cookie) =20 ret =3D ccw_device_set_online(cdev); if (ret) - pr_warn("%s: Setting the DASD online failed with rc=3D%d\n", - dev_name(&cdev->dev), ret); + dev_warn(&cdev->dev, "Setting the DASD online failed with rc=3D%d\n", re= t); } =20 /* @@ -3490,8 +3486,11 @@ int dasd_generic_set_online(struct ccw_device *cdev, { struct dasd_discipline *discipline; struct dasd_device *device; + struct device *dev; int rc; =20 + dev =3D &cdev->dev; + /* first online clears initial online feature flag */ dasd_set_feature(cdev, DASD_FEATURE_INITIAL_ONLINE, 0); device =3D dasd_create_device(cdev); @@ -3504,11 +3503,10 @@ int dasd_generic_set_online(struct ccw_device *cdev, /* Try to load the required module. */ rc =3D request_module(DASD_DIAG_MOD); if (rc) { - pr_warn("%s Setting the DASD online failed " - "because the required module %s " - "could not be loaded (rc=3D%d)\n", - dev_name(&cdev->dev), DASD_DIAG_MOD, - rc); + dev_warn(dev, "Setting the DASD online failed " + "because the required module %s " + "could not be loaded (rc=3D%d)\n", + DASD_DIAG_MOD, rc); dasd_delete_device(device); return -ENODEV; } @@ -3516,8 +3514,7 @@ int dasd_generic_set_online(struct ccw_device *cdev, /* Module init could have failed, so check again here after * request_module(). */ if (!dasd_diag_discipline_pointer) { - pr_warn("%s Setting the DASD online failed because of missing DIAG disc= ipline\n", - dev_name(&cdev->dev)); + dev_warn(dev, "Setting the DASD online failed because of missing DIAG d= iscipline\n"); dasd_delete_device(device); return -ENODEV; } @@ -3538,8 +3535,8 @@ int dasd_generic_set_online(struct ccw_device *cdev, /* check_device will allocate block device if necessary */ rc =3D discipline->check_device(device); if (rc) { - pr_warn("%s Setting the DASD online with discipline %s failed with rc=3D= %i\n", - dev_name(&cdev->dev), discipline->name, rc); + dev_warn(dev, "Setting the DASD online with discipline %s failed with rc= =3D%i\n", + discipline->name, rc); module_put(discipline->owner); module_put(base_discipline->owner); dasd_delete_device(device); @@ -3548,16 +3545,15 @@ int dasd_generic_set_online(struct ccw_device *cdev, =20 dasd_set_target_state(device, DASD_STATE_ONLINE); if (device->state <=3D DASD_STATE_KNOWN) { - pr_warn("%s Setting the DASD online failed because of a missing discipli= ne\n", - dev_name(&cdev->dev)); + dev_warn(dev, "Setting the DASD online failed because of a missing disci= pline\n"); rc =3D -ENODEV; dasd_set_target_state(device, DASD_STATE_NEW); if (device->block) dasd_free_block(device->block); dasd_delete_device(device); - } else - pr_debug("dasd_generic device %s found\n", - dev_name(&cdev->dev)); + } else { + dev_dbg(dev, "dasd_generic device found\n"); + } =20 wait_event(dasd_init_waitq, _wait_for_device(device)); =20 @@ -3568,10 +3564,13 @@ EXPORT_SYMBOL_GPL(dasd_generic_set_online); =20 int dasd_generic_set_offline(struct ccw_device *cdev) { + int max_count, open_count, rc; struct dasd_device *device; struct dasd_block *block; - int max_count, open_count, rc; unsigned long flags; + struct device *dev; + + dev =3D &cdev->dev; =20 rc =3D 0; spin_lock_irqsave(get_ccwdev_lock(cdev), flags); @@ -3592,11 +3591,10 @@ int dasd_generic_set_offline(struct ccw_device *cde= v) open_count =3D atomic_read(&device->block->open_count); if (open_count > max_count) { if (open_count > 0) - pr_warn("%s: The DASD cannot be set offline with open count %i\n", - dev_name(&cdev->dev), open_count); + dev_warn(dev, "The DASD cannot be set offline with open count %i\n", + open_count); else - pr_warn("%s: The DASD cannot be set offline while it is in use\n", - dev_name(&cdev->dev)); + dev_warn(dev, "The DASD cannot be set offline while it is in use\n"); rc =3D -EBUSY; goto out_err; } @@ -3956,8 +3954,8 @@ static int dasd_handle_autoquiesce(struct dasd_device= *device, if (dasd_eer_enabled(device)) dasd_eer_write(device, NULL, DASD_EER_AUTOQUIESCE); =20 - pr_info("%s: The DASD has been put in the quiesce state\n", - dev_name(&device->cdev->dev)); + dev_info(&device->cdev->dev, + "The DASD has been put in the quiesce state\n"); dasd_device_set_stop_bits(device, DASD_STOPPED_QUIESCE); =20 if (device->features & DASD_FEATURE_REQUEUEQUIESCE) --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ACA8759B4A; Sun, 24 Mar 2024 22:35:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319714; cv=none; b=UgO6e5ZctkRztbsfEjPe48yIZNwnlaAhPnjKCqHows5FZIyvP+Uq2nfKtUAIEoXQy47SyKVd+ncp4MjJvJ0p7pxwiTpacdcJ+HetFYMnXt7V/RC3DAiiWCuksrTijYWRhRXifc3TeAB7kbSGMp7IYiiT+pwOABZ46Uw90H3pTss= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319714; c=relaxed/simple; bh=oVZwtmDcHYvBHMhU9YZMSDC5oMFaskHjpmfI0C7pr9E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KaWrOCItd37zwX2arrCQqriefagos/qReDVbQk1QmiJr9ZIMnUfonvKPpPQWWnU7+lDVjP2m3rndAb0UzksO8az8Wr/Nh8h2k00nunFevr13h6wZbbG6yUKqFMjTRaisskBb2NOi/icwjf9kLPdZ58N/pvN66Gf3j4Xz4Gl/DCE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VCgyDxaC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VCgyDxaC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADBC4C43394; Sun, 24 Mar 2024 22:35:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319714; bh=oVZwtmDcHYvBHMhU9YZMSDC5oMFaskHjpmfI0C7pr9E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VCgyDxaCGYOtfhbTrVyM81alx4oS9oxFc0r5pft3B4wnvUw/Dt3bF715kKUf/a7Az QS9EJoon1Qh0Gx2bjEJgyatMeuzyS1yEsDo0+jUIyGRGzJukJRAjO99HdkEO8Nu3Gq T4n6OAex5chsqxHeKJGtCrZa4DJxjl9FYUkQ7JKxEt+AUdFcGM2TDWa88BwiySS0oL VMM8dy+8sofL/X9yfxY2vCfhp08SQBCfI8M3HqSVZMacXWJNUDV9roi2BUqvAC3Al2 g5caA9rwnF4MwGmVf3jKvIUn+1LQpptmJQE6omGidEsNBLSZk66dlWnpuszClFMpY+ 9xB2CvSXSrwjw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Miroslav Franc , =?UTF-8?q?Jan=20H=C3=B6ppner?= , Stefan Haberland , Jens Axboe , Sasha Levin Subject: [PATCH 6.8 017/715] s390/dasd: fix double module refcount decrement Date: Sun, 24 Mar 2024 18:23:16 -0400 Message-ID: <20240324223455.1342824-18-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Miroslav Franc [ Upstream commit c3116e62ddeff79cae342147753ce596f01fcf06 ] Once the discipline is associated with the device, deleting the device takes care of decrementing the module's refcount. Doing it manually on this error path causes refcount to artificially decrease on each error while it should just stay the same. Fixes: c020d722b110 ("s390/dasd: fix panic during offline processing") Signed-off-by: Miroslav Franc Signed-off-by: Jan H=C3=B6ppner Signed-off-by: Stefan Haberland Link: https://lore.kernel.org/r/20240209124522.3697827-3-sth@linux.ibm.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/s390/block/dasd.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c index 4a7d70426a6e6..30851faade97b 100644 --- a/drivers/s390/block/dasd.c +++ b/drivers/s390/block/dasd.c @@ -3524,12 +3524,11 @@ int dasd_generic_set_online(struct ccw_device *cdev, dasd_delete_device(device); return -EINVAL; } + device->base_discipline =3D base_discipline; if (!try_module_get(discipline->owner)) { - module_put(base_discipline->owner); dasd_delete_device(device); return -EINVAL; } - device->base_discipline =3D base_discipline; device->discipline =3D discipline; =20 /* check_device will allocate block device if necessary */ @@ -3537,8 +3536,6 @@ int dasd_generic_set_online(struct ccw_device *cdev, if (rc) { dev_warn(dev, "Setting the DASD online with discipline %s failed with rc= =3D%i\n", discipline->name, rc); - module_put(discipline->owner); - module_put(base_discipline->owner); dasd_delete_device(device); return rc; } --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D8C295A4D4; Sun, 24 Mar 2024 22:35:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319715; cv=none; b=E/1Y6Ic5EPd6qnf3fLd690Kbvi2ZmyYqtxCZcgK6H6gps7awqY2nYgvUEWV0ssvvuyvTVFSEfRZVpkGndEU7/8kzWfjzjKMFr1my6JpCZYFvFR/vZ8+pBFDOxdk/9zsT4B+GevGCZZVaQ1vjH1FSsJqOvt3hu+277Ssq6WpiOvA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319715; c=relaxed/simple; bh=RY4fZ8mZCRjC1hfMfgy2It3O12J1jbt/aQFzDaDY7RI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I9Xh3HdAchI7Ih/7Yx2MJtDkepjKdKiMN8htCO66dRXaZ3qEViYFNf6POUy0/lMgsZlVmtYetOEwirLJzkBLGmpvubGzAndcwrgRScFHR3uhyUEFcEsatho4QzyfKTaQpZdsOEc137yUNp0Nl86Nz4DpQv9VwuCEOT9VPnOyqKw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=slrtTsP2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="slrtTsP2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C63AFC433C7; Sun, 24 Mar 2024 22:35:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319715; bh=RY4fZ8mZCRjC1hfMfgy2It3O12J1jbt/aQFzDaDY7RI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=slrtTsP2IL1xGSzbWKSumjbrARGbXEBkhExv4vzLeHL+DDKOghehQnRImJwoVr62m 4KvMCKGkIDVT3jMMaZV62icZ82WwpvWRu2WJaIRS0wWC4BDeKUpt79pLtiPOD2i12x ZwTf3zZ68w1JKqY3KW8VDfSsLEjeIydHWnhiRdPZiydy86gfIhFWnomIue4L6VKSn7 S+F44vZQdZnzWIwL0wOYRLq8xl62v2468jEb1KvLSeXiPhKp57D6Fm41fT3BdiLWpl ymp594Cl+JqWe/jaK6qPUsee81JG4AxwWT1sCmJ3gC2qUC+yP4XKyKtsay7dae+evB p7e5GNgsl2I7A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Randy Dunlap , Bart Van Assche , Alexander Viro , Christian Brauner , Jens Axboe , Sasha Levin Subject: [PATCH 6.8 018/715] fs/hfsplus: use better @opf description Date: Sun, 24 Mar 2024 18:23:17 -0400 Message-ID: <20240324223455.1342824-19-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Randy Dunlap [ Upstream commit cf12445daec01aaa2d27bb34bd7c796a53442c42 ] Use a more descriptive explanation of the @opf function parameter, more in line with . Fixes: 02105f18a26c ("fs/hfsplus: wrapper.c: fix kernel-doc warnings") Suggested-by: Bart Van Assche Signed-off-by: Randy Dunlap Link: https://lore.kernel.org/r/20240210050606.9182-1-rdunlap@infradead.org Reviewed-by: Bart Van Assche Cc: Alexander Viro Cc: Christian Brauner Cc: Jens Axboe Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- fs/hfsplus/wrapper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/hfsplus/wrapper.c b/fs/hfsplus/wrapper.c index b0cb704009963..ce9346099c72d 100644 --- a/fs/hfsplus/wrapper.c +++ b/fs/hfsplus/wrapper.c @@ -30,7 +30,7 @@ struct hfsplus_wd { * @sector: block to read or write, for blocks of HFSPLUS_SECTOR_SIZE bytes * @buf: buffer for I/O * @data: output pointer for location of requested data - * @opf: request op flags + * @opf: I/O operation type and flags * * The unit of I/O is hfsplus_min_io_size(sb), which may be bigger than * HFSPLUS_SECTOR_SIZE, and @buf must be sized accordingly. On reads --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C4F55C602; Sun, 24 Mar 2024 22:35:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319717; cv=none; b=jkrrGcLvIeqYIP8HlqdNHIWEE6W1G9yK25Z0A+3HPf1QqT0okTVfTFOkNRvJMps4e1Dxq3kf3/eKO0U0wT9vGU01AKXVT5cGPirnFimyv7hLj7O2R0uPZtERvk5FSCPjtAHbJp80JampgxwNZR3rAtATYraPq7+zKtZjZdtN+JY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319717; c=relaxed/simple; bh=/MXY001JO4rLNN5N/AiOlea/3bdqF4k05VDdxhv4NLA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VQbErFdxlE5nQrgvhTpqtkL2i1S+dAf0Jf76f8I3ha1lJ8WP3wGvrmZJPUX/PwPTEBoJMlvsxjNeZJjGJhpdxaaIvHeKldMBI9rlf7evJVbZKACFqL4q0Z0lRjqyCCYCtQM9QiCNJu7vET8BytTtiiEcZGufGI0QdJwanVdx0n8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z8er6NBE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z8er6NBE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05EB6C433A6; Sun, 24 Mar 2024 22:35:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319716; bh=/MXY001JO4rLNN5N/AiOlea/3bdqF4k05VDdxhv4NLA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z8er6NBEFifZqZIJQOVUIakuSeO0p+8wN1pa99/edMtu/n6gwg8wXILTO6VvPJQmd wc1TSXqhJTdlnOwqfEjoXsqizR7OP0z0+ItPcDweOaFfYEdcBXUGqS9ptjMM2QweCk psB4U869rHRaxwPa10Bw1fylXDWqIyrMKhge9btL4j495fjVtOYiEaVgx+r5D0pp/L JzGhXHcoI6U/hCMp9xFAA2x+z0AzPJwtDso1PkEEpXH4m4XznjH5fchomRLNmeCrar g9SkGb/pmzKj9jJiMbCBs/Yxxb/ExDAYV+h+5o2gJeNrADFoR/TYCxE/9IuMxcmrMC 3Yu+Dtsjnh2tw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Li Nan , Song Liu , Sasha Levin Subject: [PATCH 6.8 019/715] md: fix kmemleak of rdev->serial Date: Sun, 24 Mar 2024 18:23:18 -0400 Message-ID: <20240324223455.1342824-20-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Li Nan [ Upstream commit 6cf350658736681b9d6b0b6e58c5c76b235bb4c4 ] If kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will be alloc not be freed, and kmemleak occurs. unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74 Fixes: 963c555e75b0 ("md: introduce mddev_create/destroy_wb_pool for the ch= ange of member device") Signed-off-by: Li Nan Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240208085556.2412922-1-linan666@huaweiclo= ud.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/md/md.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/md/md.c b/drivers/md/md.c index 9e41a9aaba8b5..bfd04a9e80796 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -2566,6 +2566,7 @@ static int bind_rdev_to_array(struct md_rdev *rdev, s= truct mddev *mddev) fail: pr_warn("md: failed to register dev-%s for %s\n", b, mdname(mddev)); + mddev_destroy_serial_pool(mddev, rdev); return err; } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2AD3B45033; Sun, 24 Mar 2024 22:35:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319718; cv=none; b=TBUMa19CEVOhDQSqPFSWRuh+qy/F1SlbDunGw7Z1HAio4wvJn6T6EqOYceLfAxA7MtHKPrzrvSaUCeGwLhpJJwCWr6NeWxUhPrhNythMgQ59G8txqhmdeQGTTuT2ALwUPyUxeO/2sLysXuwforiVOpRH5sQZAhev8ZWGCEB/yzM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319718; c=relaxed/simple; bh=Oy/tMwvVydN42G0bJnVh71AIihietZ6FD/F8TRdgP4Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=muxZubRKPQtKwvtJKWIUmFdOP5a7zAAvjujEmm9YOTNO3Urcdq/tdOrvztm25ZqafZY75rT+1OJPNvtlLxMBwx82L+NSK0znXWJT1FO0DxZMb1olS71mw39lyfc3qGk2zDHRnJeuR8zRO9TpA20izVBIx5t5cJFsErqyytGIW5s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=vPuMTlRn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="vPuMTlRn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E382EC433B2; Sun, 24 Mar 2024 22:35:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319717; bh=Oy/tMwvVydN42G0bJnVh71AIihietZ6FD/F8TRdgP4Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=vPuMTlRn23RcT0+oXGi+82vA9LeWgqlPz4I8YM9sNcV+vMyGFq6k2SctP3fhxtmPe mVxJy6R5APmY+6EHmcjsLHR97cb0B/eaGTehdZFuna0f3xyUe4ewc5emyDE1EqxHuy mcGbrDbDrmiM6q5rhtfqlBMziUqtgHXrk7aM2+osGujM2TOAUl1gMuQwDeZCk+7rco cSWYyvg3cIqMYbbN5TFwY0aLdg2/HyAft/SGrUoN0f5fXsiovuqp2bxNvnh2E8EIRE Np57OcqaNiWeNJhjtKSjNxVfWyyC24s1eNDjFNMmcgWSl2UnWn9O+93aMPUBybCDdQ SVZv7qraqtzkg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Frederic Weisbecker , Kalesh Singh , "Paul E . McKenney" , Boqun Feng , Sasha Levin Subject: [PATCH 6.8 020/715] rcu/exp: Fix RCU expedited parallel grace period kworker allocation failure recovery Date: Sun, 24 Mar 2024 18:23:19 -0400 Message-ID: <20240324223455.1342824-21-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Frederic Weisbecker [ Upstream commit a636c5e6f8fc34be520277e69c7c6ee1d4fc1d17 ] Under CONFIG_RCU_EXP_KTHREAD=3Dy, the nodes initialization for expedited grace periods is queued to a kworker. However if the allocation of that kworker failed, the nodes initialization is performed synchronously by the caller instead. Now the check for kworker initialization failure relies on the kworker pointer to be NULL while its value might actually encapsulate an allocation failure error. Make sure to handle this case. Reviewed-by: Kalesh Singh Fixes: 9621fbee44df ("rcu: Move expedited grace period (GP) work to RT kthr= ead_worker") Signed-off-by: Frederic Weisbecker Reviewed-by: Paul E. McKenney Signed-off-by: Boqun Feng Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/rcu/tree.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index b2bccfd37c383..38c86f2c040b5 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -4749,6 +4749,7 @@ static void __init rcu_start_exp_gp_kworkers(void) rcu_exp_par_gp_kworker =3D kthread_create_worker(0, par_gp_kworker_name); if (IS_ERR_OR_NULL(rcu_exp_par_gp_kworker)) { pr_err("Failed to create %s!\n", par_gp_kworker_name); + rcu_exp_par_gp_kworker =3D NULL; kthread_destroy_worker(rcu_exp_gp_kworker); return; } --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EFE7F5D477; Sun, 24 Mar 2024 22:35:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319719; cv=none; b=Wo925uK1cHg8gaJzdsHjGRaz4GOSlD+eHBlUBV9m6sQo010kY3Nq9pFh6oo5w4q+0k0iFlrVs0JZLO3FNFmd2xgH6rPqPn1Xk6L9jZHMrVAUSgdaCU4n/DnmAlJd86ORba8UNSOCxb1xi5g44MmIXwiJzVyU9lRuArVE9Bnpvg4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319719; c=relaxed/simple; bh=85vqVoxtI42H/ALYmgrcO3An3l6bGc3itYafrMJW/oc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gY7e4rA7gdkGtyqnarZGQEdjqUAhJ7EkGdyTg9K7MDpRZEVDgW3qH81nvopTqMwXYFlwredMAiEoF+yFv76dz23aXeeIX3T7L/NdQgc2MmFXTsTSuVyR1iYhuXNGFOaVkBh30ojrtfi0EnZ+1AWXCdGSeaEf5WbML5EEtl0tUbI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jnIq1OuU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jnIq1OuU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 09BD2C43394; Sun, 24 Mar 2024 22:35:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319718; bh=85vqVoxtI42H/ALYmgrcO3An3l6bGc3itYafrMJW/oc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jnIq1OuUe26o0Iz2M6CLuXP0Gb/uidr57ZSsu5XbTz2UOHyiSnN0hxGKR9x9e+mow AZi4xrqIY4xqQEr3vUovygvEtl/jVrbApiVdSRl49LY5sNXwiUooWb2iZhOjfsMA9O 0j3JzHPcz6vGRvbIYgCWEyt7YKdkBIysxhJE2OJWEqa6O79B5dLyJVpWdWwyPEj5OO 1NVIER/AP2nJOI6CD6Uk6weo/OE1qXcQl+ari4u7UZ53LKKN0XMS4MNNdtc8kkR+iI 6E3VTk+eXEf3Q/I5LE9kFQIH7yP47xCe92w4ptjixAu7OMyw8msb7CWMgPxYtieCiT w46ZQWTbFQjBw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Frederic Weisbecker , Kalesh Singh , "Paul E . McKenney" , Boqun Feng , Sasha Levin Subject: [PATCH 6.8 021/715] rcu/exp: Handle RCU expedited grace period kworker allocation failure Date: Sun, 24 Mar 2024 18:23:20 -0400 Message-ID: <20240324223455.1342824-22-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Frederic Weisbecker [ Upstream commit e7539ffc9a770f36bacedcf0fbfb4bf2f244f4a5 ] Just like is done for the kworker performing nodes initialization, gracefully handle the possible allocation failure of the RCU expedited grace period main kworker. While at it perform a rename of the related checking functions to better reflect the expedited specifics. Reviewed-by: Kalesh Singh Fixes: 9621fbee44df ("rcu: Move expedited grace period (GP) work to RT kthr= ead_worker") Signed-off-by: Frederic Weisbecker Reviewed-by: Paul E. McKenney Signed-off-by: Boqun Feng Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/rcu/tree.c | 2 ++ kernel/rcu/tree_exp.h | 25 +++++++++++++++++++------ 2 files changed, 21 insertions(+), 6 deletions(-) diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 38c86f2c040b5..f2c10d351b597 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -4743,6 +4743,7 @@ static void __init rcu_start_exp_gp_kworkers(void) rcu_exp_gp_kworker =3D kthread_create_worker(0, gp_kworker_name); if (IS_ERR_OR_NULL(rcu_exp_gp_kworker)) { pr_err("Failed to create %s!\n", gp_kworker_name); + rcu_exp_gp_kworker =3D NULL; return; } =20 @@ -4751,6 +4752,7 @@ static void __init rcu_start_exp_gp_kworkers(void) pr_err("Failed to create %s!\n", par_gp_kworker_name); rcu_exp_par_gp_kworker =3D NULL; kthread_destroy_worker(rcu_exp_gp_kworker); + rcu_exp_gp_kworker =3D NULL; return; } =20 diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h index 2ac440bc7e10b..8107f818455da 100644 --- a/kernel/rcu/tree_exp.h +++ b/kernel/rcu/tree_exp.h @@ -428,7 +428,12 @@ static void sync_rcu_exp_select_node_cpus(struct kthre= ad_work *wp) __sync_rcu_exp_select_node_cpus(rewp); } =20 -static inline bool rcu_gp_par_worker_started(void) +static inline bool rcu_exp_worker_started(void) +{ + return !!READ_ONCE(rcu_exp_gp_kworker); +} + +static inline bool rcu_exp_par_worker_started(void) { return !!READ_ONCE(rcu_exp_par_gp_kworker); } @@ -478,7 +483,12 @@ static void sync_rcu_exp_select_node_cpus(struct work_= struct *wp) __sync_rcu_exp_select_node_cpus(rewp); } =20 -static inline bool rcu_gp_par_worker_started(void) +static inline bool rcu_exp_worker_started(void) +{ + return !!READ_ONCE(rcu_gp_wq); +} + +static inline bool rcu_exp_par_worker_started(void) { return !!READ_ONCE(rcu_par_gp_wq); } @@ -541,7 +551,7 @@ static void sync_rcu_exp_select_cpus(void) rnp->exp_need_flush =3D false; if (!READ_ONCE(rnp->expmask)) continue; /* Avoid early boot non-existent wq. */ - if (!rcu_gp_par_worker_started() || + if (!rcu_exp_par_worker_started() || rcu_scheduler_active !=3D RCU_SCHEDULER_RUNNING || rcu_is_last_leaf_node(rnp)) { /* No worker started yet or last leaf, do direct call. */ @@ -956,7 +966,7 @@ static void rcu_exp_print_detail_task_stall_rnp(struct = rcu_node *rnp) */ void synchronize_rcu_expedited(void) { - bool boottime =3D (rcu_scheduler_active =3D=3D RCU_SCHEDULER_INIT); + bool use_worker; unsigned long flags; struct rcu_exp_work rew; struct rcu_node *rnp; @@ -967,6 +977,9 @@ void synchronize_rcu_expedited(void) lock_is_held(&rcu_sched_lock_map), "Illegal synchronize_rcu_expedited() in RCU read-side critical section= "); =20 + use_worker =3D (rcu_scheduler_active !=3D RCU_SCHEDULER_INIT) && + rcu_exp_worker_started(); + /* Is the state is such that the call is a grace period? */ if (rcu_blocking_is_gp()) { // Note well that this code runs with !PREEMPT && !SMP. @@ -996,7 +1009,7 @@ void synchronize_rcu_expedited(void) return; /* Someone else did our work for us. */ =20 /* Ensure that load happens before action based on it. */ - if (unlikely(boottime)) { + if (unlikely(!use_worker)) { /* Direct call during scheduler init and early_initcalls(). */ rcu_exp_sel_wait_wake(s); } else { @@ -1014,7 +1027,7 @@ void synchronize_rcu_expedited(void) /* Let the next expedited grace period start. */ mutex_unlock(&rcu_state.exp_mutex); =20 - if (likely(!boottime)) + if (likely(use_worker)) synchronize_rcu_expedited_destroy_work(&rew); } EXPORT_SYMBOL_GPL(synchronize_rcu_expedited); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0AFCE5D8E1; Sun, 24 Mar 2024 22:35:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319720; cv=none; b=KZhSmkUAGsVFgr5pKcyoLdct5SBQr8FZUv7d+c8mSH5vVj0xwVjNrCeRVT4antIyo1ub+NlaThSHNz01Wpc4rpk5ym7hOccIQJO1vi7CzS7Bb89AXmdXLtXpZ/Ha1mnYY+1ro2Cg8jb5474PsG9z6suQ+5ve8lQ4PTtUcLPL3L8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319720; c=relaxed/simple; bh=6alEoGO6nr4EhRoVtIgT4k+syFQEq+PbxvG/g+gpRtI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=px8M99ssIk4x6dEkY3LJAxNc7Dzdy8GPQ8jm/nopuifZUDg1WWRN5v2RIlUYkVteGnIhEbYG6FAVK/QuEXM3U7KG7FRn1qZNgwSUYDKOwkzA/ifmgCvlcvgLSvCtftuLnXRdEjZ5vTfduOg58jseW/xdLuUpcLb4Y0USDeoTMeI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tjAYMapN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tjAYMapN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E182C43330; Sun, 24 Mar 2024 22:35:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319719; bh=6alEoGO6nr4EhRoVtIgT4k+syFQEq+PbxvG/g+gpRtI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tjAYMapNswU1PIExmjPGLhRuvWkh/HjxqDqyTIVbpOQcA3A7kTZ1Qid/Hya8YyFAg 2wZcNUElFH3UFvESexGK2AfW81fygh1dcZ/lLY46inAHuejE55Fo2+e/ZsxrcEXNrZ 9xzMFcdU8KrwgB0EBXjzHrKBxEKrwVmqsWniGaJNL1popSE1wGUm39I6pfl2Jc1dr0 cSl1Jg4sGoBpYxHjStcBWtdw2gARPAtchwJGJR3vfnR34Ph0tnyrP8Cwo8gfieuCrV VG7r4Zw6JKsK8eRQJEWMb13GM5ZPD3CzeyRRYLDzu4k8Bt8qWd9gjblddm/hFxxanf HploNJDTj7mVw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Navid Emamdoost , Michal Kubecek , Kees Cook , Jens Axboe , Sasha Levin Subject: [PATCH 6.8 022/715] nbd: null check for nla_nest_start Date: Sun, 24 Mar 2024 18:23:21 -0400 Message-ID: <20240324223455.1342824-23-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Navid Emamdoost [ Upstream commit 31edf4bbe0ba27fd03ac7d87eb2ee3d2a231af6d ] nla_nest_start() may fail and return NULL. Insert a check and set errno based on other call sites within the same source code. Signed-off-by: Navid Emamdoost Reviewed-by: Michal Kubecek Fixes: 47d902b90a32 ("nbd: add a status netlink command") Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20240218042534.it.206-kees@kernel.org Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/block/nbd.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c index 33a8f37bb6a1f..b7c332528ed7a 100644 --- a/drivers/block/nbd.c +++ b/drivers/block/nbd.c @@ -2433,6 +2433,12 @@ static int nbd_genl_status(struct sk_buff *skb, stru= ct genl_info *info) } =20 dev_list =3D nla_nest_start_noflag(reply, NBD_ATTR_DEVICE_LIST); + if (!dev_list) { + nlmsg_free(reply); + ret =3D -EMSGSIZE; + goto out; + } + if (index =3D=3D -1) { ret =3D idr_for_each(&nbd_index_idr, &status_cb, reply); if (ret) { --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8104E62802; Sun, 24 Mar 2024 22:35:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319721; cv=none; b=XF3zFEQE7SmVk3Jyj5qerzzfJ3yuu4cA56LlRH0n5TuBqTAOQSNvq7wG6M9yxH4gps1vxoQk0fe+T0/ZnlrgSA8IEDD1iA6qg7R6zj3oSAl+SD7Gn/+MVsSxjNzkYVyKr3yj+KxBYpxEbgScsQZWrW1/oY3Ic19sK70Y3+gfLV8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319721; c=relaxed/simple; bh=c/8ThzkfXePMKSUnih7WKsu2s/C2H5smRXIfTXnLdnc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MvOSQoLrOwn8IfQTRVQd3TRc7E/V0Gwffb3na/ErmdQr/gUADDJTtXcA79sV+kNC1/OJB5yOzjQ55/36NxGbpRj7pQ9R06kwZ5NHyUAM6xm6aq6CC9Wfj8gEx89GSPskmZu6Fz0nNeTV6B+suUyOr8R34hjb134A6D+FxoKYgdo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gZF9RYIw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gZF9RYIw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2B6FEC433C7; Sun, 24 Mar 2024 22:35:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319721; bh=c/8ThzkfXePMKSUnih7WKsu2s/C2H5smRXIfTXnLdnc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gZF9RYIw/nR3jg+ructF7EbBdjduUsN/Odhm1nHGHUd8iG2u3U07pdCc8es1tnm3Q mB5Zsk7AlI7TRD4zn9do1YDTInmLYBGf7QADlZiMayaFuqN7zzhDuI7J7UoOEVKT0A o5qhRIEug0HyhWq0ulZ6chSB8s9Mq7w4IdYNEA85IuAt7JxgYmJ402Op9CcfmyrQ+M 6gIWd+v/QTo4gfzvmXVvsu5s+yBbwwqMUq8RwWOz2pUkB0kxxlZfI2xnEuWRamu+oA WHjprW2VuSlODvY3V49dUUFHxHDQpiqvIDjbv8ppkq/aAgIVOzPL0sZJ9SYvXYBx2O RqWgmELXwpRZQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Arnd Bergmann , Kees Cook , Andi Kleen , Jan Kara , Christian Brauner , Sasha Levin Subject: [PATCH 6.8 023/715] fs/select: rework stack allocation hack for clang Date: Sun, 24 Mar 2024 18:23:22 -0400 Message-ID: <20240324223455.1342824-24-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnd Bergmann [ Upstream commit ddb9fd7a544088ed70eccbb9f85e9cc9952131c1 ] A while ago, we changed the way that select() and poll() preallocate a temporary buffer just under the size of the static warning limit of 1024 bytes, as clang was frequently going slightly above that limit. The warnings have recently returned and I took another look. As it turns out, clang is not actually inherently worse at reserving stack space, it just happens to inline do_select() into core_sys_select(), while gcc never inlines it. Annotate do_select() to never be inlined and in turn remove the special case for the allocation size. This should give the same behavior for both clang and gcc all the time and once more avoids those warnings. Fixes: ad312f95d41c ("fs/select: avoid clang stack usage warning") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20240216202352.2492798-1-arnd@kernel.org Reviewed-by: Kees Cook Reviewed-by: Andi Kleen Reviewed-by: Jan Kara Signed-off-by: Christian Brauner Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- fs/select.c | 2 +- include/linux/poll.h | 4 ---- 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/fs/select.c b/fs/select.c index 0ee55af1a55c2..d4d881d439dcd 100644 --- a/fs/select.c +++ b/fs/select.c @@ -476,7 +476,7 @@ static inline void wait_key_set(poll_table *wait, unsig= ned long in, wait->_key |=3D POLLOUT_SET; } =20 -static int do_select(int n, fd_set_bits *fds, struct timespec64 *end_time) +static noinline_for_stack int do_select(int n, fd_set_bits *fds, struct ti= mespec64 *end_time) { ktime_t expire, *to =3D NULL; struct poll_wqueues table; diff --git a/include/linux/poll.h b/include/linux/poll.h index a9e0e1c2d1f2f..d1ea4f3714a84 100644 --- a/include/linux/poll.h +++ b/include/linux/poll.h @@ -14,11 +14,7 @@ =20 /* ~832 bytes of stack space used max in sys_select/sys_poll before alloca= ting additional memory. */ -#ifdef __clang__ -#define MAX_STACK_ALLOC 768 -#else #define MAX_STACK_ALLOC 832 -#endif #define FRONTEND_STACK_ALLOC 256 #define SELECT_STACK_ALLOC FRONTEND_STACK_ALLOC #define POLL_STACK_ALLOC FRONTEND_STACK_ALLOC --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5B7E167A0E; Sun, 24 Mar 2024 22:35:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319722; cv=none; b=k2Vf3epMh4KJv3qGd6U4gUvqFKiTBmgHxmeIUQLZuPSy0KTUuMiTmaDUjn3I6sHZH2jloOhPhGyUgQB3LjP/vSdADY1cXZ4IEffxnxRmC8eybVJRL/BJEwYnny3vw/f1Jxppo3Ap75rObGrGlduj7x4sXxiC9jYbTtscwVkwpVI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319722; c=relaxed/simple; bh=XOYrKTWco8HiIB6DZWLSwMFHj0pkQP8UMX5FuLWZT+E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gbMXPxfq2AZTNwd9jD28/bIGUmz8GAi+0BU6mDeEIQHxOt/9kNw9zxgnPZT+OYDqUVb8u4NJ/JJZIAdtvjZcifjnEtGiDlFDPrT0SuMO7k3bPpHQKsqOb0lZAy65xnm35RmDjkO5t+rA9DCITf8MAn8S+rb+THKZgYLfK783H8w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=L1Bcpp1v; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="L1Bcpp1v" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54CA2C43390; Sun, 24 Mar 2024 22:35:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319722; bh=XOYrKTWco8HiIB6DZWLSwMFHj0pkQP8UMX5FuLWZT+E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=L1Bcpp1vwc34Mu5u5YKDWt8bF0LmhngwLMF7c0qvDQB5b7yZQLQ8UJIRjeoaFj9hO qCkcQ++Hk7qXJf+Y8fTv177YE/ev/DCEMdqjSx/JUGhDio79kxhD0jIterw9pKFDrQ DAylzTVef9OG9SASkHiEMaae3veCTkGSqFA4iywFSGzzQFOZdlKf9EJWNgwyHb3wMo JEKhs60KB9AJ7tGrAfn70d/Xcakq6tjZyPAlvrwP8e23BiF1P+/Y60Jo2AiujscFqd Pwoot/KCxzdpUac3+f8bXd51i7ZU2a2mc7f/gJLycKpdakNzmzlw28fKZbLaa0YNlf Je8+9PSdJqaRA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Li Nan , mgperkow@gmail.com, Christoph Hellwig , Yu Kuai , Jens Axboe , Sasha Levin Subject: [PATCH 6.8 024/715] block: fix deadlock between bd_link_disk_holder and partition scan Date: Sun, 24 Mar 2024 18:23:23 -0400 Message-ID: <20240324223455.1342824-25-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Li Nan [ Upstream commit 03f12122b20b6e6028e9ed69030a49f9cffcbb75 ] 'open_mutex' of gendisk is used to protect open/close block devices. But in bd_link_disk_holder(), it is used to protect the creation of symlink between holding disk and slave bdev, which introduces some issues. When bd_link_disk_holder() is called, the driver is usually in the process of initialization/modification and may suspend submitting io. At this time, any io hold 'open_mutex', such as scanning partitions, can cause deadlocks. For example, in raid: T1 T2 bdev_open_by_dev lock open_mutex [1] ... efi_partition ... md_submit_bio md_ioctl mddev_syspend -> suspend all io md_add_new_disk bind_rdev_to_array bd_link_disk_holder try lock open_mutex [2] md_handle_request -> wait mddev_resume T1 scan partition, T2 add a new device to raid. T1 waits for T2 to resume mddev, but T2 waits for open_mutex held by T1. Deadlock occurs. Fix it by introducing a local mutex 'blk_holder_mutex' to replace 'open_mutex'. Fixes: 1b0a2d950ee2 ("md: use new apis to suspend array for ioctls involed = array reconfiguration") Reported-by: mgperkow@gmail.com Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D218459 Signed-off-by: Li Nan Reviewed-by: Christoph Hellwig Reviewed-by: Yu Kuai Link: https://lore.kernel.org/r/20240221090122.1281868-1-linan666@huaweiclo= ud.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- block/holder.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/block/holder.c b/block/holder.c index 37d18c13d9581..791091a7eac23 100644 --- a/block/holder.c +++ b/block/holder.c @@ -8,6 +8,8 @@ struct bd_holder_disk { int refcnt; }; =20 +static DEFINE_MUTEX(blk_holder_mutex); + static struct bd_holder_disk *bd_find_holder_disk(struct block_device *bde= v, struct gendisk *disk) { @@ -80,7 +82,7 @@ int bd_link_disk_holder(struct block_device *bdev, struct= gendisk *disk) kobject_get(bdev->bd_holder_dir); mutex_unlock(&bdev->bd_disk->open_mutex); =20 - mutex_lock(&disk->open_mutex); + mutex_lock(&blk_holder_mutex); WARN_ON_ONCE(!bdev->bd_holder); =20 holder =3D bd_find_holder_disk(bdev, disk); @@ -108,7 +110,7 @@ int bd_link_disk_holder(struct block_device *bdev, stru= ct gendisk *disk) goto out_del_symlink; list_add(&holder->list, &disk->slave_bdevs); =20 - mutex_unlock(&disk->open_mutex); + mutex_unlock(&blk_holder_mutex); return 0; =20 out_del_symlink: @@ -116,7 +118,7 @@ int bd_link_disk_holder(struct block_device *bdev, stru= ct gendisk *disk) out_free_holder: kfree(holder); out_unlock: - mutex_unlock(&disk->open_mutex); + mutex_unlock(&blk_holder_mutex); if (ret) kobject_put(bdev->bd_holder_dir); return ret; @@ -140,7 +142,7 @@ void bd_unlink_disk_holder(struct block_device *bdev, s= truct gendisk *disk) if (WARN_ON_ONCE(!disk->slave_dir)) return; =20 - mutex_lock(&disk->open_mutex); + mutex_lock(&blk_holder_mutex); holder =3D bd_find_holder_disk(bdev, disk); if (!WARN_ON_ONCE(holder =3D=3D NULL) && !--holder->refcnt) { del_symlink(disk->slave_dir, bdev_kobj(bdev)); @@ -149,6 +151,6 @@ void bd_unlink_disk_holder(struct block_device *bdev, s= truct gendisk *disk) list_del_init(&holder->list); kfree(holder); } - mutex_unlock(&disk->open_mutex); + mutex_unlock(&blk_holder_mutex); } EXPORT_SYMBOL_GPL(bd_unlink_disk_holder); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5788C5D8E1; Sun, 24 Mar 2024 22:35:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319723; cv=none; b=BgKzkS8y7yiGqJYzZpX/xfXJV/Lq8jXAu8VYY+2UFK3DPM4jD7d7vScXc53LfDS+teNMNKV+2//7uenEl5YdCA6i3LvPUZ9AwLa03l/63Er0VhpRyFZFMu/7O+UDfdYO9Snmn/dLfMmwR7Sq0abfiqxUZoqsXqUud38CwOQZ+FE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319723; c=relaxed/simple; bh=9ow4d0I8ykKepUEvPvrJCVgpBOAMKiYp+QNhUH5Nfv8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fW7twq92qh4WjZKPTNwVLZ7F5hHXDA0RXz1obcHfLn5gTMGA5O29f8S7rqvDGYI4a9qE4Ta+v3JdxdywgMWr+8iByS69Woq7iJPamBUoBiWYB8e+3+H44JEMtl5B7oiCh/3Q1ScLoWxtcGdVXb7eRWktxjBRsaNvG5inZQrxUco= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uPohn6xB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uPohn6xB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7BF80C433B1; Sun, 24 Mar 2024 22:35:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319723; bh=9ow4d0I8ykKepUEvPvrJCVgpBOAMKiYp+QNhUH5Nfv8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uPohn6xBclq1NYKNUfcswXshr1jgGuSBPqmff3GMCPSYHEGQCGVnJsTsUBAGtT9aF vr1OtAeMPBRsycmJmsIScehY1GAXMg/ulwTnQaduGxvRIdTvkPUyeZgqG5kJiwEivv ixzuIfj8Tu7c9AnrV4eF+KDkrScHIN5poDNUFH3cqyE4yduoLe35Lu7D/F62nXY7xx K2JOWrzqkilr82Ic/MC9O+1l4C5fkbuX2KAQ9XVTaDDeodrIpGOm/qyAwSAs65JrfG yZdbtDcvToiUoEvdGqXtlj69xPUWfvEZT2Lbp7f4KX8N/RjScdQAMj02OLB3bFlgju C6axcDvfbPbdQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Li Nan , Yu Kuai , Song Liu , Sasha Levin Subject: [PATCH 6.8 025/715] md: Don't clear MD_CLOSING when the raid is about to stop Date: Sun, 24 Mar 2024 18:23:24 -0400 Message-ID: <20240324223455.1342824-26-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Li Nan [ Upstream commit 9674f54e41fffaf06f6a60202e1fa4cc13de3cf5 ] The raid should not be opened anymore when it is about to be stopped. However, other processes can open it again if the flag MD_CLOSING is cleared before exiting. From now on, this flag will not be cleared when the raid will be stopped. Fixes: 065e519e71b2 ("md: MD_CLOSING needs to be cleared after called md_se= t_readonly or do_md_stop") Signed-off-by: Li Nan Reviewed-by: Yu Kuai Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240226031444.3606764-6-linan666@huaweiclo= ud.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/md/md.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/md/md.c b/drivers/md/md.c index bfd04a9e80796..d344e6fa3b26f 100644 --- a/drivers/md/md.c +++ b/drivers/md/md.c @@ -6279,7 +6279,15 @@ static void md_clean(struct mddev *mddev) mddev->persistent =3D 0; mddev->level =3D LEVEL_NONE; mddev->clevel[0] =3D 0; - mddev->flags =3D 0; + /* + * Don't clear MD_CLOSING, or mddev can be opened again. + * 'hold_active !=3D 0' means mddev is still in the creation + * process and will be used later. + */ + if (mddev->hold_active) + mddev->flags =3D 0; + else + mddev->flags &=3D BIT_ULL_MASK(MD_CLOSING); mddev->sb_flags =3D 0; mddev->ro =3D MD_RDWR; mddev->metadata_type[0] =3D 0; @@ -7625,7 +7633,6 @@ static int md_ioctl(struct block_device *bdev, blk_mo= de_t mode, int err =3D 0; void __user *argp =3D (void __user *)arg; struct mddev *mddev =3D NULL; - bool did_set_md_closing =3D false; =20 if (!md_ioctl_valid(cmd)) return -ENOTTY; @@ -7709,7 +7716,6 @@ static int md_ioctl(struct block_device *bdev, blk_mo= de_t mode, err =3D -EBUSY; goto out; } - did_set_md_closing =3D true; mutex_unlock(&mddev->open_mutex); sync_blockdev(bdev); } @@ -7851,7 +7857,7 @@ static int md_ioctl(struct block_device *bdev, blk_mo= de_t mode, mddev_unlock(mddev); =20 out: - if(did_set_md_closing) + if (cmd =3D=3D STOP_ARRAY_RO || (err && cmd =3D=3D STOP_ARRAY)) clear_bit(MD_CLOSING, &mddev->flags); return err; } --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 763366BFBF; Sun, 24 Mar 2024 22:35:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319724; cv=none; b=khqTzxz5BG8Xb/XSgoNouS9nVA9Vk/oFtbG+cp5rJnBF560qaQSFeBTSCIkFsC/7I5nJ8YBzStem2BwvgfSn4QOGcXGJAIxhWkyH4PltVaB3mj4NEsPGulkA2tdjYRBQdDuHe0q9i/VbBjcFlFWlWGlUPvGhElUYAtGv7XriU08= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319724; c=relaxed/simple; bh=A9hhnNGKNJQvbzqjwj11sc2xcTjo7vfpsW+pBYyE2/k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I6jQiOr0DSdomLskWaBCj9zH1dT6XvmeY8kceHoK6MMsCwHIxTaK44J8YzGsPrIRPxJ541LaJB3AAHkK9Kwa9mFTucPVcSxt5YlpHpr9EnLsXt8IDLfiH0D/uqzoCJV1V8MPbbd7hwUORlBGEPcNUB5zRGZITDH4APYcbsLHGuk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AEWWheiW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AEWWheiW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C9A7C433C7; Sun, 24 Mar 2024 22:35:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319724; bh=A9hhnNGKNJQvbzqjwj11sc2xcTjo7vfpsW+pBYyE2/k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AEWWheiW6txc+xSEbVqe5FmchDSWK3vdqL2uDTRolvCrsJIXoylb2cXX7MX2d+qLI z5LCFL/shzVXyr0YBTsKfFW3YdQxY8wyha/drPADn/c/On1b63sIsW+oKBMZVDTfnT QRU0ODPP57sMuhZEHX4x5arbgw8QMXW9if04p1uo/9avDD5SFY1LfX6Qa3/aTzkHSI KwgloABaTjLko7dDJ/UEK8tWeByngqvVEecFrb/aMJQPE8e+4j0EEvbKG/odIrNYgJ XPajJ6MMnvr9VBFmcVHThz56facv2fINyCdEXsju8z/WwsJJc8qRpEdcWJ/F+rWn7W O5CXYjn1T/cmg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Maxime Ripard , Guenter Roeck , David Gow , Shuah Khan , Sasha Levin Subject: [PATCH 6.8 026/715] kunit: Setup DMA masks on the kunit device Date: Sun, 24 Mar 2024 18:23:25 -0400 Message-ID: <20240324223455.1342824-27-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maxime Ripard [ Upstream commit c5215d54dc10e801a6cefef62445a00a4c28a515 ] Commit d393acce7b3f ("drm/tests: Switch to kunit devices") switched the DRM device creation helpers from an ad-hoc implementation to the new kunit device creation helpers introduced in commit d03c720e03bd ("kunit: Add APIs for managing devices"). However, while the DRM helpers were using a platform_device, the kunit helpers are using a dedicated bus and device type. That situation creates small differences in the initialisation, and one of them is that the kunit devices do not have the DMA masks setup. In turn, this means that we can't do any kind of DMA buffer allocation anymore, which creates a regression on some (downstream for now) tests. Let's set up a default DMA mask that should work on any platform to fix it. Fixes: d03c720e03bd ("kunit: Add APIs for managing devices") Signed-off-by: Maxime Ripard Tested-by: Guenter Roeck Reviewed-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- lib/kunit/device.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/lib/kunit/device.c b/lib/kunit/device.c index 644a38a1f5b1c..9ea399049749e 100644 --- a/lib/kunit/device.c +++ b/lib/kunit/device.c @@ -10,6 +10,7 @@ */ =20 #include +#include =20 #include #include @@ -133,6 +134,9 @@ static struct kunit_device *kunit_device_register_inter= nal(struct kunit *test, return ERR_PTR(err); } =20 + kunit_dev->dev.dma_mask =3D &kunit_dev->dev.coherent_dma_mask; + kunit_dev->dev.coherent_dma_mask =3D DMA_BIT_MASK(32); + kunit_add_action(test, device_unregister_wrapper, &kunit_dev->dev); =20 return kunit_dev; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 789DB6CDAD; Sun, 24 Mar 2024 22:35:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319725; cv=none; b=g0f6s5KrdHygWNVLlZZ+XcY52DsX8mHdRkM3FqfB1aNBK6ModCUx6kjVnANgQaAP9kkcWgyoT226RtVVfGMVRXB7JsUJi7OyiHAyzPI8EOQsXkJL7o7w/5+YKVj5oXrvDFWK5AvkItNaNmuJfxJcBfLSMnAZR1/O3L/cg413Y7o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319725; c=relaxed/simple; bh=fzaSZg1cousZPFs9g2V1Go91FbBqdlg74fePrxfpCrA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sZeTTEKGJV+yGsh0798W6T9hbWz1loFBBjJ16N/paqsIFsZ44hnhRlUoLQgF0Ss8LDyUerDmjyPzn0KUNUEWl7svLbnTY4bJqutyhw4PPqrfYXqyvTtgTzP8t4p5sOkvPQ/+NK8TkoDGMoTVkoS1dX1+GGhkWhDKRWeCsL2P+Cc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Lm3vhMkV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Lm3vhMkV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B6F9C433A6; Sun, 24 Mar 2024 22:35:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319725; bh=fzaSZg1cousZPFs9g2V1Go91FbBqdlg74fePrxfpCrA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Lm3vhMkVizUdZ4fbGKTV0IkEWKJ9sCCCsTc26TA2YR2k/7APhETlzzWvjA3AMNGLA myYdMMrzmd6g5z8ivQJIGcN8Ozu2rpTPeX/zh6+O7kvRVm+voWScGyWllhmnsJmGET qYwJDCFAEoc7BNzG4bhzs6Q76t0E3JJa/VSAHDi2qqF+O6m+3g+TOK+IDYlpc9mblM U1jGXbL2RVKmtllyc1Qmobj7eIOviAmtTF/U7d/Tm9j84zSZKF7ha1glPkKZsvYsT+ /FI7yKmqNrgZGKm7UlV5wLcBBmdzFKW2HbwWbIhfrffbeGlf2yYnjemWaIF1OE6FTz 9IcJK8FG/ejEQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gabriel Krisman Bertazi , Amir Goldstein , Eric Biggers , Sasha Levin Subject: [PATCH 6.8 027/715] ovl: Always reject mounting over case-insensitive directories Date: Sun, 24 Mar 2024 18:23:26 -0400 Message-ID: <20240324223455.1342824-28-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gabriel Krisman Bertazi [ Upstream commit 2824083db76cb9d4b7910607b367e93b02912865 ] overlayfs relies on the filesystem setting DCACHE_OP_HASH or DCACHE_OP_COMPARE to reject mounting over case-insensitive directories. Since commit bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops"), we set ->d_op through a hook in ->d_lookup, which means the root dentry won't have them, causing the mount to accidentally succeed. In v6.7-rc7, the following sequence will succeed to mount, but any dentry other than the root dentry will be a "weird" dentry to ovl and fail with EREMOTE. mkfs.ext4 -O casefold lower.img mount -O loop lower.img lower mount -t overlay -o lowerdir=3Dlower,upperdir=3Dupper,workdir=3Dwork ovl = /mnt Mounting on a subdirectory fails, as expected, because DCACHE_OP_HASH and DCACHE_OP_COMPARE are properly set by ->lookup. Fix by explicitly rejecting superblocks that allow case-insensitive dentries. Yes, this will be solved when we move d_op configuration back to ->s_d_op. Yet, we better have an explicit fix to avoid messing up again. While there, re-sort the entries to have more descriptive error messages first. Fixes: bb9cd9106b22 ("fscrypt: Have filesystems handle their d_ops") Acked-by: Amir Goldstein Reviewed-by: Eric Biggers Link: https://lore.kernel.org/r/20240221171412.10710-2-krisman@suse.de Signed-off-by: Gabriel Krisman Bertazi Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- fs/overlayfs/params.c | 14 +++++++++++--- include/linux/fs.h | 9 +++++++++ 2 files changed, 20 insertions(+), 3 deletions(-) diff --git a/fs/overlayfs/params.c b/fs/overlayfs/params.c index 112b4b12f8252..36dcc530ac286 100644 --- a/fs/overlayfs/params.c +++ b/fs/overlayfs/params.c @@ -280,12 +280,20 @@ static int ovl_mount_dir_check(struct fs_context *fc,= const struct path *path, { struct ovl_fs_context *ctx =3D fc->fs_private; =20 - if (ovl_dentry_weird(path->dentry)) - return invalfc(fc, "filesystem on %s not supported", name); - if (!d_is_dir(path->dentry)) return invalfc(fc, "%s is not a directory", name); =20 + /* + * Root dentries of case-insensitive capable filesystems might + * not have the dentry operations set, but still be incompatible + * with overlayfs. Check explicitly to prevent post-mount + * failures. + */ + if (sb_has_encoding(path->mnt->mnt_sb)) + return invalfc(fc, "case-insensitive capable filesystem on %s not suppor= ted", name); + + if (ovl_dentry_weird(path->dentry)) + return invalfc(fc, "filesystem on %s not supported", name); =20 /* * Check whether upper path is read-only here to report failures diff --git a/include/linux/fs.h b/include/linux/fs.h index 1fbc72c5f112c..630468c005040 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -3281,6 +3281,15 @@ extern int generic_check_addressable(unsigned, u64); =20 extern void generic_set_encrypted_ci_d_ops(struct dentry *dentry); =20 +static inline bool sb_has_encoding(const struct super_block *sb) +{ +#if IS_ENABLED(CONFIG_UNICODE) + return !!sb->s_encoding; +#else + return false; +#endif +} + int may_setattr(struct mnt_idmap *idmap, struct inode *inode, unsigned int ia_valid); int setattr_prepare(struct mnt_idmap *, struct dentry *, struct iattr *); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C30156CDDF; Sun, 24 Mar 2024 22:35:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319726; cv=none; b=EJ8bN+Pomj4IFwsALjL01CFdv+CHpIIZUYN6/xI4yKV/wkLr8UGVyJABBmnz2x8EcpJuN+O0bIC+xm/XhfvNqzKzrVpleYbXDYmU8vDyAw6q8nSf8aiUuEJoscG2BcEx5nryooP/tq9s1uW6FAgtkwnqK4lKtUK+3p6Z8AqFrVM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319726; c=relaxed/simple; bh=kcjCwDbEJD49FCkn7bWPsxt2uts52PTkJf8FWlS/DAE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LrZ/kagZnJATaoeKQTqhnHOseecuk01hMqndGbuEpAmuNL10YaOAnUJBxrvxUJ8HJYhqpgMz1F98QDsAJ+8Kr+fJWCkck7p07CJktJmEZy/rSSsowyd5lhloXohlJDpoUhGVM8FdsEn29H2EhJplm9Fjo3jYv5bXYPHxre87HxA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=g4HSJJqq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="g4HSJJqq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C652C43399; Sun, 24 Mar 2024 22:35:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319726; bh=kcjCwDbEJD49FCkn7bWPsxt2uts52PTkJf8FWlS/DAE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g4HSJJqqKGlxdGpcT5rJiXw1C/IvAoxCdtZxXPALN7yNikhdMW5kfFfMU+Kzrnnfk NN0x+mpIMNWHJm8XiJmnQl0kOHipfPkvyXnH4Ih5Msd+VNpczCgG7Jm0LmkL7GiPxk iiYXf5yQj2bLblQZEEWKmhv/KLlOq9USb8SXWcchrXCnthb7XNxs9JsfzDPPzpcoJI 79rN3nmh455mvlcOM1NEJ2RdYLwhXXtsYojrkuh0NK+vrrfgfVW14ErqMDGh99yDtK 3HTNPH2JQN8SNgiX7gV502/By41lhcjA95d5iK8REqbycf+w7elNF3tPTfSdCmF8n4 27AOb14G6gzOA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Gow , Guenter Roeck , Justin Stitt , Daniel Latypov , Rae Moar , Shuah Khan , Sasha Levin Subject: [PATCH 6.8 028/715] kunit: test: Log the correct filter string in executor_test Date: Sun, 24 Mar 2024 18:23:27 -0400 Message-ID: <20240324223455.1342824-29-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Gow [ Upstream commit 6f2f793fba78eb4a0d5a34a71bc781118ed923d3 ] KUnit's executor_test logs the filter string in KUNIT_ASSERT_EQ_MSG(), but passed a random character from the filter, rather than the whole string. This was found by annotating KUNIT_ASSERT_EQ_MSG() to let gcc validate the format string. Fixes: 76066f93f1df ("kunit: add tests for filtering attributes") Signed-off-by: David Gow Tested-by: Guenter Roeck Reviewed-by: Justin Stitt Reviewed-by: Daniel Latypov Reviewed-by: Rae Moar Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- lib/kunit/executor_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/kunit/executor_test.c b/lib/kunit/executor_test.c index 22d4ee86dbedd..3f7f967e3688e 100644 --- a/lib/kunit/executor_test.c +++ b/lib/kunit/executor_test.c @@ -129,7 +129,7 @@ static void parse_filter_attr_test(struct kunit *test) GFP_KERNEL); for (j =3D 0; j < filter_count; j++) { parsed_filters[j] =3D kunit_next_attr_filter(&filter, &err); - KUNIT_ASSERT_EQ_MSG(test, err, 0, "failed to parse filter '%s'", filters= [j]); + KUNIT_ASSERT_EQ_MSG(test, err, 0, "failed to parse filter from '%s'", fi= lters); } =20 KUNIT_EXPECT_STREQ(test, kunit_attr_filter_name(parsed_filters[0]), "spee= d"); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A5E56DCF5; Sun, 24 Mar 2024 22:35:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319728; cv=none; b=lX1sFkJSWcJBco9cN73kH+vOScZJzqWlZJsFdx3McgoeRl6Voh7MZ3LP0dM/9wG72x2KU4VYpxX0O/s6odLst/8kJJOepo8KZvpsbfYjLe3X1iecF2rc98i6b1gUAqgpDUfq1aIAFA3AkMdQ9EJWy8EZtDgM5tTJociO7rrrYhk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319728; c=relaxed/simple; bh=UtPbFHo8lwti70qwLux/kF9zRmuI2UztEodfyyPfoCg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=U1IxLBpD6CcIfEOlrV2pzqIkbbZAik6xSevIpP3MsLx8ZPyepcwZZuyv81r1vy5skp/9FjF9mSXeC2aT6kal0OYExMk7Yj5q2r7nqaLDPR8xgUE9oUqjXN+aQQTXN8Qysk93RLskaqgv3lDLXTHDPjLtuGNGOGYPUlAVhbOyjL4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ksGCOPnn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ksGCOPnn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5D1CC433C7; Sun, 24 Mar 2024 22:35:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319727; bh=UtPbFHo8lwti70qwLux/kF9zRmuI2UztEodfyyPfoCg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ksGCOPnnbpSerW8vz6zFtqvEmug78gJKX0Uu4O/yUZDVNQXuTFd1sdN7aJ0GzQshI GkQW1G1zsW/bQa+Of6NjvWO+Ul0bmamNrpNM4Yw57GgJDDMYzT1l7eI6i5b4oT3HVq COrBFDtgH1a5PfKJ9yHtniUPcLldSxEdiC3s3DgPzxsrY1CezKOyVUJuVhdqXr4lfx D1y4SbJYj354eR+bEry9IhqnOwpTFSxCfceJUcYpcdtN1GOYG/qr9dRPwh6kmMQZv3 7BxrhmQ4C34YGcyLPbunKmPvtG1UaE70RncX8ij4Po7ycsS529eFoLqokW+5AxdcjM g2VxMTs2c8qnA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Gow , Guenter Roeck , Daniel Latypov , Shuah Khan , Sasha Levin Subject: [PATCH 6.8 029/715] lib/cmdline: Fix an invalid format specifier in an assertion msg Date: Sun, 24 Mar 2024 18:23:28 -0400 Message-ID: <20240324223455.1342824-30-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Gow [ Upstream commit d2733a026fc7247ba42d7a8e1b737cf14bf1df21 ] The correct format specifier for p - n (both p and n are pointers) is %td, as the type should be ptrdiff_t. This was discovered by annotating KUnit assertion macros with gcc's printf specifier, but note that gcc incorrectly suggested a %d or %ld specifier (depending on the pointer size of the architecture being built). Fixes: 0ea09083116d ("lib/cmdline: Allow get_options() to take 0 to validat= e the input") Signed-off-by: David Gow Tested-by: Guenter Roeck Reviewed-by: Daniel Latypov Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- lib/cmdline_kunit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/cmdline_kunit.c b/lib/cmdline_kunit.c index d4572dbc91453..705b82736be08 100644 --- a/lib/cmdline_kunit.c +++ b/lib/cmdline_kunit.c @@ -124,7 +124,7 @@ static void cmdline_do_one_range_test(struct kunit *tes= t, const char *in, n, e[0], r[0]); =20 p =3D memchr_inv(&r[1], 0, sizeof(r) - sizeof(r[0])); - KUNIT_EXPECT_PTR_EQ_MSG(test, p, NULL, "in test %u at %u out of bound", n= , p - r); + KUNIT_EXPECT_PTR_EQ_MSG(test, p, NULL, "in test %u at %td out of bound", = n, p - r); } =20 static void cmdline_test_range(struct kunit *test) --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 06EE06E619; Sun, 24 Mar 2024 22:35:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319729; cv=none; b=R/3c2TF6wXKgGCxPtCc619Iq+V14u/Do1zsJiP8A9ihVC0whtzT4mB7tevI3225FtWfYhPKzxDPVDou687B6ondSJJSzzGvz9ODMcEmqFXPd5t5IhcQNhWptldKOz7MePcPJqzMS8+06Q6nqMcKcrSo9v/cLLbpjlOANhThjRSc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319729; c=relaxed/simple; bh=//otllxWTZARqxoMNJaZWiaXPi8swLKbFrMrfBueuy4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OIBOccocdmWbIlgIhBR8bzk8/tbOgfgvGLXCMmwPY+E4CEeldCgpF60Ip3s5AkIku9ZFGYQ+Woqo7GMDbddUr4lu8ChZJpfXESL38Ws2iUp2DnMObqc5NVqIM0INohTuTx68WLb8EKuGP98CsUhIHuhrwLtHuqoVRx6PwGaANDA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=feQg+1S9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="feQg+1S9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0869AC43390; Sun, 24 Mar 2024 22:35:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319728; bh=//otllxWTZARqxoMNJaZWiaXPi8swLKbFrMrfBueuy4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=feQg+1S9dNPqbCXbdBZk/RbP+6arGQX+mIcw9qOKCI1jk//96gsj839QwMI1kLDat ELBz6+3NtYNXTmo6ZGpVdL1sKEYoeTdotnO6tTRi+IClgOofPJuMdz0SaTmkrL6cnW 2+NGal4MM9Pa6MWoeHqQeozX+PKBX/ho/zCAkathd4PvF7vjCdx82m1IEdazpjAEej yDBm+pm7+F/tzsybZB7p+sOWvgmS4TWfeX9dPPxmzdIzVBBvn1Dk91RwjZbqZnnmAK NM8eFAt0d/1pRjTBGWQu0zXFknknhZm525heftVbTmDsz2WU4yRmxoSv68yL1fwhNi d/eULWOCqQQbQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Gow , Guenter Roeck , Justin Stitt , Shuah Khan , Sasha Levin Subject: [PATCH 6.8 030/715] lib: memcpy_kunit: Fix an invalid format specifier in an assertion msg Date: Sun, 24 Mar 2024 18:23:29 -0400 Message-ID: <20240324223455.1342824-31-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Gow [ Upstream commit 0a549ed22c3c7cc6da5c5f5918efd019944489a5 ] The 'i' passed as an assertion message is a size_t, so should use '%zu', not '%d'. This was found by annotating the _MSG() variants of KUnit's assertions to let gcc validate the format strings. Fixes: bb95ebbe89a7 ("lib: Introduce CONFIG_MEMCPY_KUNIT_TEST") Signed-off-by: David Gow Tested-by: Guenter Roeck Reviewed-by: Justin Stitt Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- lib/memcpy_kunit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/memcpy_kunit.c b/lib/memcpy_kunit.c index 440aee705ccca..30e00ef0bf2e0 100644 --- a/lib/memcpy_kunit.c +++ b/lib/memcpy_kunit.c @@ -32,7 +32,7 @@ struct some_bytes { BUILD_BUG_ON(sizeof(instance.data) !=3D 32); \ for (size_t i =3D 0; i < sizeof(instance.data); i++) { \ KUNIT_ASSERT_EQ_MSG(test, instance.data[i], v, \ - "line %d: '%s' not initialized to 0x%02x @ %d (saw 0x%02x)\n", \ + "line %d: '%s' not initialized to 0x%02x @ %zu (saw 0x%02x)\n", \ __LINE__, #instance, v, i, instance.data[i]); \ } \ } while (0) @@ -41,7 +41,7 @@ struct some_bytes { BUILD_BUG_ON(sizeof(one) !=3D sizeof(two)); \ for (size_t i =3D 0; i < sizeof(one); i++) { \ KUNIT_EXPECT_EQ_MSG(test, one.data[i], two.data[i], \ - "line %d: %s.data[%d] (0x%02x) !=3D %s.data[%d] (0x%02x)\n", \ + "line %d: %s.data[%zu] (0x%02x) !=3D %s.data[%zu] (0x%02x)\n", \ __LINE__, #one, i, one.data[i], #two, i, two.data[i]); \ } \ kunit_info(test, "ok: " TEST_OP "() " name "\n"); \ --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 14A316EB5C; Sun, 24 Mar 2024 22:35:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319730; cv=none; b=jDDOFvdAhRdreEIdq32+ceYjvpegIDMiXrB+W4ltB4L7BYzn2Ax9ZWCsD77TV3F4kX/WQYp4VeVzYMlie2VXzDTsQPHkGhRBapz/ARzfXWFRCD8zV4CUX/MDg8VKgv2H8Pe/O1/pHyUCgUB75xicsVHKsr8rj+BkpfCHsbOtIWE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319730; c=relaxed/simple; bh=5Ds3TB7+/SF9s/aIHH6qhACfJy7hakZs8cM0naRFrrU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VMIHqAzkAy5I4vStZUFRPImoRflHzz2/m4eL6iEBK7t/E2SNi3IY4lWpwcWpf+/8NRM06lyYslqE+UwLNhHWZiv8ao8Dhc+4CB8ki4QR0OaDZ6hkLEk2jonE/ILe+1Bjv7FWI4Og8Om++L6v35wmdtMFiIdw+zIWaPlIrXd8IYM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R83V/4X2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R83V/4X2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D8E1C43394; Sun, 24 Mar 2024 22:35:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319729; bh=5Ds3TB7+/SF9s/aIHH6qhACfJy7hakZs8cM0naRFrrU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R83V/4X2i+aESD0ce3KNHtXQMeXsd7gMZJ/s6Rd6ZLjSbqVT32SgCyY/74YPIsEfU 5FphGNcRqpfh84BxbquJegfF30fWnmqBZviIvoaBZrFpnUOEKhQA11K3qyAfnc0fmv TeV75fNAWg+9xdOm251Iu8l+v3md5wiNnTNf6TwYnsBlVlcMe2Kvzd/uDr5aBVUNDS F/V/d+PXvQOabQBoUh+N/uNOq6AfZZ624fIMRO30lq2gF3uzrgKlU3Zl4oFUDOzmuu NZm+nJj3yS5a7rFSi+a9YjdH69AiBeEg+pBnN9YdCzkFI3tOwCeuN3OltKmwa1M+9Q 9i1uU5O9fsafA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Gow , Guenter Roeck , Justin Stitt , Shuah Khan , Sasha Levin Subject: [PATCH 6.8 031/715] time: test: Fix incorrect format specifier Date: Sun, 24 Mar 2024 18:23:30 -0400 Message-ID: <20240324223455.1342824-32-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Gow [ Upstream commit 133e267ef4a26d19c93996a874714e9f3f8c70aa ] 'days' is a s64 (from div_s64), and so should use a %lld specifier. This was found by extending KUnit's assertion macros to use gcc's __printf attribute. Fixes: 276010551664 ("time: Improve performance of time64_to_tm()") Signed-off-by: David Gow Tested-by: Guenter Roeck Reviewed-by: Justin Stitt Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/time/time_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/time/time_test.c b/kernel/time/time_test.c index ca058c8af6baf..3e5d422dd15cb 100644 --- a/kernel/time/time_test.c +++ b/kernel/time/time_test.c @@ -73,7 +73,7 @@ static void time64_to_tm_test_date_range(struct kunit *te= st) =20 days =3D div_s64(secs, 86400); =20 - #define FAIL_MSG "%05ld/%02d/%02d (%2d) : %ld", \ + #define FAIL_MSG "%05ld/%02d/%02d (%2d) : %lld", \ year, month, mdday, yday, days =20 KUNIT_ASSERT_EQ_MSG(test, year - 1900, result.tm_year, FAIL_MSG); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 39C9D6EB7C; Sun, 24 Mar 2024 22:35:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319731; cv=none; b=c+D8h9gA6McMky/cZpEUEu4vJyXIUDDuAtCtdzeNujvyWyGY4hlojVwZvE+an6+HAGq8IxHiORArmbh9O9cWpsONrXOpKPp1amULrCEKBoakTi13MSouC73EC8IR+0XnquPPPrijGt7/ipKHpr8p4Woi0JthpMFEw7gErZVuXwQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319731; c=relaxed/simple; bh=5C+htp1cj21cUDOBsDFxDwPW3yx1GRI9GjuFvV4teBA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QYwOemICwudZwka9+GxQwPcdcdHSbDzXQdWU2GGgEueNZNalxY3GuhRgQ5pmFiKaqYNlwj2MuF6jDr+AHDdPSdKTfDLo88nqQwUbL2zXhRad9SqPRjX95brlljZGiAJbhJoWFhYSbG4cRaQSxtBs9SRYtSDosLcU6SRXbETm8vE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lYKYVW4f; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lYKYVW4f" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 333A5C433C7; Sun, 24 Mar 2024 22:35:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319731; bh=5C+htp1cj21cUDOBsDFxDwPW3yx1GRI9GjuFvV4teBA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lYKYVW4fCC/IvR/1m0eq7YQXMHe9aX5LT17KVEmtKzbzFjo2C3sG1C2tzwziADlyZ tmns1ws9PY07jjcBZk2vX4jH1HwmoQrXL65N2TOUzwIXkjsc86Pa61ZYUut1llSEVq kR9lfdR8y1ZRZH5MfJT1SpmWboV3nspfN+9gCNS+WHMXitFH0XckAOd7o4d7oEupPy e6FBe8kl8LoJEfYYRM2OtRHdpdaQnaTzr4LDbZiw3wxkR0JSywP1zxR7jEMXKtCBn4 dh1BXDS8PysRPidyaBbfrtzxl824SG1VOfraP0ufu5I+RQqvrd8w6qMfpNjT4kBvCh NRDL1LX5vMGjw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Gow , Guenter Roeck , Justin Stitt , Alexandre Belloni , Shuah Khan , Sasha Levin Subject: [PATCH 6.8 032/715] rtc: test: Fix invalid format specifier. Date: Sun, 24 Mar 2024 18:23:31 -0400 Message-ID: <20240324223455.1342824-33-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Gow [ Upstream commit 8a904a3caa88118744062e872ae90f37748a8fd8 ] 'days' is a s64 (from div_s64), and so should use a %lld specifier. This was found by extending KUnit's assertion macros to use gcc's __printf attribute. Fixes: 1d1bb12a8b18 ("rtc: Improve performance of rtc_time64_to_tm(). Add t= ests.") Signed-off-by: David Gow Tested-by: Guenter Roeck Reviewed-by: Justin Stitt Acked-by: Alexandre Belloni Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/rtc/lib_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/rtc/lib_test.c b/drivers/rtc/lib_test.c index d5caf36c56cdc..225c859d6da55 100644 --- a/drivers/rtc/lib_test.c +++ b/drivers/rtc/lib_test.c @@ -54,7 +54,7 @@ static void rtc_time64_to_tm_test_date_range(struct kunit= *test) =20 days =3D div_s64(secs, 86400); =20 - #define FAIL_MSG "%d/%02d/%02d (%2d) : %ld", \ + #define FAIL_MSG "%d/%02d/%02d (%2d) : %lld", \ year, month, mday, yday, days =20 KUNIT_ASSERT_EQ_MSG(test, year - 1900, result.tm_year, FAIL_MSG); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4BAD66F085; Sun, 24 Mar 2024 22:35:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319732; cv=none; b=ulwsfM8xfkBaPZBqvDVQLV4uilv+IE9ZId4pVeeNBVcf286+CqqIRa6Q74YI7xaYehdFviumHshoUnghDZICp98xngve1xkcarmd/P8PX7emXqWnnGwksBihgmDyhD1EwvoEmHYEQllEOZOIcQnE+oJTqQrVUePzE0Lvb/KhFVo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319732; c=relaxed/simple; bh=vrxNdixPF1P+PaS8QLrMH1Ze7LzOwQIc98jq+2n817o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PVhWhM4aznsurOQosjlVWgr4dhL7pbXc4GnAOzjnVsVZsim4sAVI+LsemFNp8fqdwPlmwx4in64BVcHR5pzmL1jvYbEuFgilXkjO6RPmG1VLKQJv0IaleMf1EETz4HkrRqNP81KcxJ2i6wHc6iS6kx6jrBBv4NZzN7JuMk28GoI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UWyLH/5u; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UWyLH/5u" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DB17C43399; Sun, 24 Mar 2024 22:35:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319732; bh=vrxNdixPF1P+PaS8QLrMH1Ze7LzOwQIc98jq+2n817o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UWyLH/5uUwgENdiUOQpdaOSsTFOBTo9zurie28eTI/d+RDODvQJeYWyGyqF0yq9yi I2vK+mWMB+YKF5aafShXutw33lMMdOl78e/wKnEReGA9Ys9ubmHhBffNrjiHlBqGz0 28LiH7a8M/M2gfjiz+PvlyYRwvGRASAkrMrFP6lfShcdSayoLxCoqAiTDVav4ZKzyz SRIQnodEeShJpSScbumSg+g4x7pxhJYW2x1fIoPy2bUiv+9CmSR1T9JS58Yd+7aPmf U3wPNHvgPz+PwwYrhRIY2kVpwmE/aUrrt4FLQXUir0pfpDVidGbCmY6CVAA0yEv6xh SLKAvGYjw3WYg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Gow , Guenter Roeck , Justin Stitt , Shuah Khan , Sasha Levin Subject: [PATCH 6.8 033/715] net: test: Fix printf format specifier in skb_segment kunit test Date: Sun, 24 Mar 2024 18:23:32 -0400 Message-ID: <20240324223455.1342824-34-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Gow [ Upstream commit ff3b96f2c9e5c24fca12239cd519a8a18569e687 ] KUNIT_FAIL() accepts a printf-style format string, but previously did not let gcc validate it with the __printf() attribute. The use of %lld for the result of PTR_ERR() is not correct. Instead, use %pe and pass the actual error pointer. printk() will format it correctly (and give a symbolic name rather than a number if available, which should make the output more readable, too). Fixes: b3098d32ed6e ("net: add skb_segment kunit test") Signed-off-by: David Gow Tested-by: Guenter Roeck Reviewed-by: Justin Stitt Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/core/gso_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/core/gso_test.c b/net/core/gso_test.c index 4c2e77bd12f4b..358c44680d917 100644 --- a/net/core/gso_test.c +++ b/net/core/gso_test.c @@ -225,7 +225,7 @@ static void gso_test_func(struct kunit *test) =20 segs =3D skb_segment(skb, features); if (IS_ERR(segs)) { - KUNIT_FAIL(test, "segs error %lld", PTR_ERR(segs)); + KUNIT_FAIL(test, "segs error %pe", segs); goto free_gso_skb; } else if (!segs) { KUNIT_FAIL(test, "no segments"); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 767146FB80; Sun, 24 Mar 2024 22:35:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319733; cv=none; b=X6ZIGT4pz3dFVf4VEiQPhr3X+1VP6UJ3rooXRQtyxRDY5rTd8cE+Z3YlaPgupRzxKym2qQeUnm+ybZ35BaxFCdDZsBzJboCmUTFhfS6uBPIlVjERudIZnSljvX9LYC8DAV+th6Sd8AIMsc9oIJHJchUG4KypKmknyIdPHrJQVAM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319733; c=relaxed/simple; bh=UObW9I6bfIlw9H+IP5DBPRyzBWISzkmfqE7NiZ/xRH8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=Zhg34yLr1VzvlZwoYsPnKh1FW0LK9Eckp1zB3wn/a0bE1PBbkqzPcTOxe4UNOH3gncfZevv6LbFfqZMrdcK4BgSe443jKbqB9aYpFsXW3ZVRgdF4V9BcNtdbyCjIUkD91mQo1ttJrNPCkxCJo8sJCrabpliU7kfBZ7p3JL8BUj4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cK2DYiwY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cK2DYiwY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7125BC43394; Sun, 24 Mar 2024 22:35:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319733; bh=UObW9I6bfIlw9H+IP5DBPRyzBWISzkmfqE7NiZ/xRH8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cK2DYiwY2bIsFCTbpnEMYc2LG5Lz4x0rGNy75TfnP2YGiBhownskLDnb4K0wRd76b 7cDLCz5FP5dD5Oj8daMUYocV9ND9Li0Jr+I/0vM5oIEEKdwcuYL8DT2T0LAGJAKo84 hdRTTe33Cx/Zi5JgsDWrf5HNLGry9cOlcfqb9vrGqnOoE2iUqSwkFBvp1zSUfBMQ/m TeB4CrN3Hjhd2FSooLPQcMU4iHawrn3F20MVUnkwraMbLHdOB1jXwAre5K1aXVLY6E a3h3MFpoxPuXEnyXsIQcGAXC/0HG4Xg0FdQLtQQm3AK757ieleNJl4zf5/miv47tds r5FSdyOlPcSZQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Gow , Guenter Roeck , Lucas De Marchi , =?UTF-8?q?Thomas=20Hellstr=C3=B6m?= , Shuah Khan , Sasha Levin Subject: [PATCH 6.8 034/715] drm/xe/tests: Fix printf format specifiers in xe_migrate test Date: Sun, 24 Mar 2024 18:23:33 -0400 Message-ID: <20240324223455.1342824-35-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: David Gow [ Upstream commit 689a930b93c5c20294df5da0407df361c5412eac ] KUNIT_FAIL() is used to fail the xe_migrate test when an error occurs. However, there's a mismatch in the format specifier: '%li' is used to log 'err', which is an 'int'. Use '%i' instead of '%li', and for the case where we're printing an error pointer, just use '%pe', instead of extracting the error code manually with PTR_ERR(). (This also results in a nicer output when the error code is known.) Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Signed-off-by: David Gow Tested-by: Guenter Roeck Reviewed-by: Lucas De Marchi Acked-by: Thomas Hellstr=C3=B6m Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/xe/tests/xe_migrate.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/xe/tests/xe_migrate.c b/drivers/gpu/drm/xe/tes= ts/xe_migrate.c index a6523df0f1d39..c347e2c29f81f 100644 --- a/drivers/gpu/drm/xe/tests/xe_migrate.c +++ b/drivers/gpu/drm/xe/tests/xe_migrate.c @@ -114,21 +114,21 @@ static void test_copy(struct xe_migrate *m, struct xe= _bo *bo, region | XE_BO_NEEDS_CPU_ACCESS); if (IS_ERR(remote)) { - KUNIT_FAIL(test, "Failed to allocate remote bo for %s: %li\n", - str, PTR_ERR(remote)); + KUNIT_FAIL(test, "Failed to allocate remote bo for %s: %pe\n", + str, remote); return; } =20 err =3D xe_bo_validate(remote, NULL, false); if (err) { - KUNIT_FAIL(test, "Failed to validate system bo for %s: %li\n", + KUNIT_FAIL(test, "Failed to validate system bo for %s: %i\n", str, err); goto out_unlock; } =20 err =3D xe_bo_vmap(remote); if (err) { - KUNIT_FAIL(test, "Failed to vmap system bo for %s: %li\n", + KUNIT_FAIL(test, "Failed to vmap system bo for %s: %i\n", str, err); goto out_unlock; } --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B7C186FE2B; Sun, 24 Mar 2024 22:35:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319734; cv=none; b=imf7UUiXdLv5hV8JimdHXKoY8WqRVCXe+9DGHszXUWGH8mHowIeKKJqXdwSVCkdSrDhs4Z+xefOhaPshKSRuZ83wxGpR++R+uO+WgduGP/UyJyu3oAa3Aq27wnzT52yQO2Gm22j6nSkPIbZAF7OzlRCd/f6cjOCcMppdvwA/kA8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319734; c=relaxed/simple; bh=QaMkZjrTKAwC5rT+/146rHqBP0Wkx1m7aIt1TJjwpCI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=lQUJ70NGGciBnowxwBjhOBtDznIQ7WA2m98xuqmQw6okwp0lr6m0dUp2fwewknBURZPqJxMUMKi374Iia4wtbKaPCCSok2682SxHPiz1NbWAoepR5yV2TVsePNPu9PoeYnZzuYTbUTv0opsN4myJZUSNChhfArUs4COSEzMUQmQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DCCWDA2C; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DCCWDA2C" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 998DAC433F1; Sun, 24 Mar 2024 22:35:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319734; bh=QaMkZjrTKAwC5rT+/146rHqBP0Wkx1m7aIt1TJjwpCI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DCCWDA2CD1Wh1gcRNE5oNVrXjmURHqdjMGzIAFWbBMm8b8uj1mk4KdDCz/EUhQHpq CdasrL6gVE8AU0F86pyXEIgT2Bp2GLOwFKE/PPsfKgVfZuyw6SXjMWdCAA9EQ9TEId e+ZkqGMZF9vLqDIXxJ04/rYuP8gSk8HlubqVEExhUpEk0Gz3Hn/rYL5qpLKV2LdIwp ydWTGjb6TWwPfh09Nf/eYJP7o5Q+W49uPc2rZ+0QfZpmseUGErnI5kMVenodp2OaVJ yGQOJo1NulSah4PtYl7N7sXxkiAX6lVnnOrfWohm+xnvOfMvHOABrcVC/V01f+1qKO hQmooKF3BtA2g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Gow , Matthew Auld , =?UTF-8?q?Christian=20K=C3=B6nig?= , Guenter Roeck , Justin Stitt , Shuah Khan , Sasha Levin Subject: [PATCH 6.8 035/715] drm: tests: Fix invalid printf format specifiers in KUnit tests Date: Sun, 24 Mar 2024 18:23:34 -0400 Message-ID: <20240324223455.1342824-36-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: David Gow [ Upstream commit fc9a615200d48e076af58f4309f507e500ed900d ] The drm_buddy_test's alloc_contiguous test used a u64 for the page size, which was then updated to be an 'unsigned long' to avoid 64-bit multiplication division helpers. However, the variable is logged by some KUNIT_ASSERT_EQ_MSG() using the '%d' or '%llu' format specifiers, the former of which is always wrong, and the latter is no longer correct now that ps is no longer a u64. Fix these to all use '%lu'. Also, drm_mm_test calls KUNIT_FAIL() with an empty string as the message. gcc and clang warns if a printf format string is empty, so give these some more detailed error messages, which should be more useful anyway. Fixes: a64056bb5a32 ("drm/tests/drm_buddy: add alloc_contiguous test") Fixes: fca7526b7d89 ("drm/tests/drm_buddy: fix build failure on 32-bit targ= ets") Fixes: fc8d29e298cf ("drm: selftest: convert drm_mm selftest to KUnit") Reviewed-by: Matthew Auld Acked-by: Christian K=C3=B6nig Tested-by: Guenter Roeck Reviewed-by: Justin Stitt Signed-off-by: David Gow Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/tests/drm_buddy_test.c | 14 +++++++------- drivers/gpu/drm/tests/drm_mm_test.c | 6 +++--- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c b/drivers/gpu/drm/tests= /drm_buddy_test.c index 484360c7e1f65..e48863a445564 100644 --- a/drivers/gpu/drm/tests/drm_buddy_test.c +++ b/drivers/gpu/drm/tests/drm_buddy_test.c @@ -260,30 +260,30 @@ static void drm_test_buddy_alloc_contiguous(struct ku= nit *test) KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size, ps, ps, list, 0), - "buddy_alloc hit an error size=3D%u\n", + "buddy_alloc hit an error size=3D%lu\n", ps); } while (++i < n_pages); =20 KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size, 3 * ps, ps, &allocated, DRM_BUDDY_CONTIGUOUS_ALLOCATION), - "buddy_alloc didn't error size=3D%u\n", 3 * ps); + "buddy_alloc didn't error size=3D%lu\n", 3 * ps); =20 drm_buddy_free_list(&mm, &middle); KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size, 3 * ps, ps, &allocated, DRM_BUDDY_CONTIGUOUS_ALLOCATION), - "buddy_alloc didn't error size=3D%u\n", 3 * ps); + "buddy_alloc didn't error size=3D%lu\n", 3 * ps); KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size, 2 * ps, ps, &allocated, DRM_BUDDY_CONTIGUOUS_ALLOCATION), - "buddy_alloc didn't error size=3D%u\n", 2 * ps); + "buddy_alloc didn't error size=3D%lu\n", 2 * ps); =20 drm_buddy_free_list(&mm, &right); KUNIT_ASSERT_TRUE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size, 3 * ps, ps, &allocated, DRM_BUDDY_CONTIGUOUS_ALLOCATION), - "buddy_alloc didn't error size=3D%u\n", 3 * ps); + "buddy_alloc didn't error size=3D%lu\n", 3 * ps); /* * At this point we should have enough contiguous space for 2 blocks, * however they are never buddies (since we freed middle and right) so @@ -292,13 +292,13 @@ static void drm_test_buddy_alloc_contiguous(struct ku= nit *test) KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size, 2 * ps, ps, &allocated, DRM_BUDDY_CONTIGUOUS_ALLOCATION), - "buddy_alloc hit an error size=3D%u\n", 2 * ps); + "buddy_alloc hit an error size=3D%lu\n", 2 * ps); =20 drm_buddy_free_list(&mm, &left); KUNIT_ASSERT_FALSE_MSG(test, drm_buddy_alloc_blocks(&mm, 0, mm_size, 3 * ps, ps, &allocated, DRM_BUDDY_CONTIGUOUS_ALLOCATION), - "buddy_alloc hit an error size=3D%u\n", 3 * ps); + "buddy_alloc hit an error size=3D%lu\n", 3 * ps); =20 total =3D 0; list_for_each_entry(block, &allocated, link) diff --git a/drivers/gpu/drm/tests/drm_mm_test.c b/drivers/gpu/drm/tests/dr= m_mm_test.c index 1eb0c304f9607..f37c0d7658656 100644 --- a/drivers/gpu/drm/tests/drm_mm_test.c +++ b/drivers/gpu/drm/tests/drm_mm_test.c @@ -157,7 +157,7 @@ static void drm_test_mm_init(struct kunit *test) =20 /* After creation, it should all be one massive hole */ if (!assert_one_hole(test, &mm, 0, size)) { - KUNIT_FAIL(test, ""); + KUNIT_FAIL(test, "mm not one hole on creation"); goto out; } =20 @@ -171,14 +171,14 @@ static void drm_test_mm_init(struct kunit *test) =20 /* After filling the range entirely, there should be no holes */ if (!assert_no_holes(test, &mm)) { - KUNIT_FAIL(test, ""); + KUNIT_FAIL(test, "mm has holes when filled"); goto out; } =20 /* And then after emptying it again, the massive hole should be back */ drm_mm_remove_node(&tmp); if (!assert_one_hole(test, &mm, 0, size)) { - KUNIT_FAIL(test, ""); + KUNIT_FAIL(test, "mm does not have single hole after emptying"); goto out; } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 030C070CCC; Sun, 24 Mar 2024 22:35:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319736; cv=none; b=HqrL6UFwK1gGNfGWi071k5QqtBm1P2EcHwApx/gh8AfwBjWHY6vBucCpjpG45VCcm+NOLo7N2q1Id0+70ADxhXv5Cy9k7PjCk44AUO3REcSGVNI3ebZvOTh32N+fB9G1L4ezI3snvA36o0E+UjF36kYvM32Dz4H4Ygxa38NBcuE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319736; c=relaxed/simple; bh=PNAdyC6rPjgFUpItYxARC4mcur4TAXXTn2fULoUfsmI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=D884303GDDhi4wO5xBxcPfcBHVJC8DzzBlNT4LlvkIv49aXPDdEF0XqAOPx5UsbhaiKVopdN0H6ASNWcY3p3rP4OvS/bimFC7JwMVcgyiDPrhKeLrLUn1zwPKRsRpLQoysDGnS9dw/E1fz/N8Gby2ckqV9qxgzB7MjOwgsnhFEY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KXXBF3x8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KXXBF3x8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DAB3FC433A6; Sun, 24 Mar 2024 22:35:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319735; bh=PNAdyC6rPjgFUpItYxARC4mcur4TAXXTn2fULoUfsmI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KXXBF3x8+lX0gcVct+ULqfaN3Q27Ey7Jq8fTfwYZbAJKk7PnAxLHkWT3/suh2xPpj LICfB7jfmpMudNw0yOpGPKtW/BDga99Bw2WTR1jIYgEMqPzh3+IS8PHDJLbBySiIqo qZxdjyP4yWn+i9SWeWKw56LBV7JrP6UFiSQcDmD2zFCNRPkqtHNsFiCifV3nilmV8c 95H0QddqBMwvdQB/YRBRiMwAKbIw3WKIBF89IowCazuOqSBh40g/x0i25LgarlXxRe sxugY6oC+TU7U5VBGU4tqaMlLDUEhPnTzCVjzFdSdgiiVTmnwVpl7zASUG2pYX+Fl0 ZZ2R8tpxK7PBA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yu Kuai , Song Liu , Sasha Levin Subject: [PATCH 6.8 036/715] md/raid1: factor out helpers to add rdev to conf Date: Sun, 24 Mar 2024 18:23:35 -0400 Message-ID: <20240324223455.1342824-37-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yu Kuai [ Upstream commit 969d6589abcb369d53d84ec7c9c37f4b23ec1ad9 ] There are no functional changes, just make code cleaner and prepare to record disk non-rotational information while adding and removing rdev to conf Signed-off-by: Yu Kuai Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240229095714.926789-3-yukuai1@huaweicloud= .com Stable-dep-of: 257ac239ffcf ("md/raid1: fix choose next idle in read_balanc= e()") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/md/raid1.c | 85 +++++++++++++++++++++++++++++----------------- 1 file changed, 53 insertions(+), 32 deletions(-) diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c index 286f8b16c7bde..a560824e038b4 100644 --- a/drivers/md/raid1.c +++ b/drivers/md/raid1.c @@ -1760,6 +1760,44 @@ static int raid1_spare_active(struct mddev *mddev) return count; } =20 +static bool raid1_add_conf(struct r1conf *conf, struct md_rdev *rdev, int = disk, + bool replacement) +{ + struct raid1_info *info =3D conf->mirrors + disk; + + if (replacement) + info +=3D conf->raid_disks; + + if (info->rdev) + return false; + + rdev->raid_disk =3D disk; + info->head_position =3D 0; + info->seq_start =3D MaxSector; + WRITE_ONCE(info->rdev, rdev); + + return true; +} + +static bool raid1_remove_conf(struct r1conf *conf, int disk) +{ + struct raid1_info *info =3D conf->mirrors + disk; + struct md_rdev *rdev =3D info->rdev; + + if (!rdev || test_bit(In_sync, &rdev->flags) || + atomic_read(&rdev->nr_pending)) + return false; + + /* Only remove non-faulty devices if recovery is not possible. */ + if (!test_bit(Faulty, &rdev->flags) && + rdev->mddev->recovery_disabled !=3D conf->recovery_disabled && + rdev->mddev->degraded < conf->raid_disks) + return false; + + WRITE_ONCE(info->rdev, NULL); + return true; +} + static int raid1_add_disk(struct mddev *mddev, struct md_rdev *rdev) { struct r1conf *conf =3D mddev->private; @@ -1795,15 +1833,13 @@ static int raid1_add_disk(struct mddev *mddev, stru= ct md_rdev *rdev) disk_stack_limits(mddev->gendisk, rdev->bdev, rdev->data_offset << 9); =20 - p->head_position =3D 0; - rdev->raid_disk =3D mirror; + raid1_add_conf(conf, rdev, mirror, false); err =3D 0; /* As all devices are equivalent, we don't need a full recovery * if this was recently any drive of the array */ if (rdev->saved_raid_disk < 0) conf->fullsync =3D 1; - WRITE_ONCE(p->rdev, rdev); break; } if (test_bit(WantReplacement, &p->rdev->flags) && @@ -1813,13 +1849,11 @@ static int raid1_add_disk(struct mddev *mddev, stru= ct md_rdev *rdev) =20 if (err && repl_slot >=3D 0) { /* Add this device as a replacement */ - p =3D conf->mirrors + repl_slot; clear_bit(In_sync, &rdev->flags); set_bit(Replacement, &rdev->flags); - rdev->raid_disk =3D repl_slot; + raid1_add_conf(conf, rdev, repl_slot, true); err =3D 0; conf->fullsync =3D 1; - WRITE_ONCE(p[conf->raid_disks].rdev, rdev); } =20 print_conf(conf); @@ -1836,27 +1870,20 @@ static int raid1_remove_disk(struct mddev *mddev, s= truct md_rdev *rdev) if (unlikely(number >=3D conf->raid_disks)) goto abort; =20 - if (rdev !=3D p->rdev) - p =3D conf->mirrors + conf->raid_disks + number; + if (rdev !=3D p->rdev) { + number +=3D conf->raid_disks; + p =3D conf->mirrors + number; + } =20 print_conf(conf); if (rdev =3D=3D p->rdev) { - if (test_bit(In_sync, &rdev->flags) || - atomic_read(&rdev->nr_pending)) { - err =3D -EBUSY; - goto abort; - } - /* Only remove non-faulty devices if recovery - * is not possible. - */ - if (!test_bit(Faulty, &rdev->flags) && - mddev->recovery_disabled !=3D conf->recovery_disabled && - mddev->degraded < conf->raid_disks) { + if (!raid1_remove_conf(conf, number)) { err =3D -EBUSY; goto abort; } - WRITE_ONCE(p->rdev, NULL); - if (conf->mirrors[conf->raid_disks + number].rdev) { + + if (number < conf->raid_disks && + conf->mirrors[conf->raid_disks + number].rdev) { /* We just removed a device that is being replaced. * Move down the replacement. We drain all IO before * doing this to avoid confusion. @@ -3006,23 +3033,17 @@ static struct r1conf *setup_conf(struct mddev *mdde= v) =20 err =3D -EINVAL; spin_lock_init(&conf->device_lock); + conf->raid_disks =3D mddev->raid_disks; rdev_for_each(rdev, mddev) { int disk_idx =3D rdev->raid_disk; - if (disk_idx >=3D mddev->raid_disks - || disk_idx < 0) + + if (disk_idx >=3D conf->raid_disks || disk_idx < 0) continue; - if (test_bit(Replacement, &rdev->flags)) - disk =3D conf->mirrors + mddev->raid_disks + disk_idx; - else - disk =3D conf->mirrors + disk_idx; =20 - if (disk->rdev) + if (!raid1_add_conf(conf, rdev, disk_idx, + test_bit(Replacement, &rdev->flags))) goto abort; - disk->rdev =3D rdev; - disk->head_position =3D 0; - disk->seq_start =3D MaxSector; } - conf->raid_disks =3D mddev->raid_disks; conf->mddev =3D mddev; INIT_LIST_HEAD(&conf->retry_list); INIT_LIST_HEAD(&conf->bio_end_io_list); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F8C87172B; Sun, 24 Mar 2024 22:35:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319736; cv=none; b=mq/QQbTSNi3l3qx9gfCLY1Jvo5b6BBX67NkriKIOVDXpbHEnNEbqh42vUwUf+/wFftnyAmtk5dUCr8W68vR9V2sgfj71piswRHaY2vjH6wsBtmp9lElBxMi12fVchdm7JBYrSayygG7g3aPZTjSlvFcknFSyYEcY/pyy3UuM8+o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319736; c=relaxed/simple; bh=/nkVN1yDcY9oxD5onlKvnyC7QCORQPVPAOK6wS4gzPo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SUA5WK31LiWq+LUQ0Ab1EMaB1xVWqJzLRnLdmHn/cjvwdbQJqiya4uL9fxPFJTaWZ28YafIy8iSeaABS8KSjZOdqe39nm32mZ8iEDgJ9raEIJk8sH41KzJKqFnPgzHZnE5Bht37qRg+/ihfPZ4/y9B4042jR8aLG0wnG6M8Qre4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WOObiQcm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WOObiQcm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BDFCBC433B1; Sun, 24 Mar 2024 22:35:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319736; bh=/nkVN1yDcY9oxD5onlKvnyC7QCORQPVPAOK6wS4gzPo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WOObiQcmyDGUjSGy2t2kUUS7ijOvFPqJBANL6jDyOrd+g7ZGqt4EWU2zzw4pwrVaz jcpjXdtJ9N/s6R5ts4fd/rW1EzD4xrL+CTktTF54nCZjjjl25zRJFjAiA7eoX4thn+ O3/3Fk6QxEuOEBtYM1HG6BJH0je1HXfy7whFWBkkqfjtplb8OmwtfCxtSoERXSwvhE c2KmW3F6aERn0Wk2YNxD0+PSU5rq4zd59AmNr8gcAQy6rIN/AYhpl7V1OwN1o7HN3q L7BNIxMaWBvA3wY9nAK2qc7z0Br+8x3pjddqwqXh+l6gSJ24a2CRZyYQF5C6b7rS6w TNCgpoCVsaOFA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yu Kuai , Paul Luse , Song Liu , Sasha Levin Subject: [PATCH 6.8 037/715] md/raid1: record nonrot rdevs while adding/removing rdevs to conf Date: Sun, 24 Mar 2024 18:23:36 -0400 Message-ID: <20240324223455.1342824-38-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yu Kuai [ Upstream commit 2c27d09d3a76b33629d2e681bf8b774f776ade7f ] For raid1, each read will iterate all the rdevs from conf and check if any rdev is non-rotational, then choose rdev with minimal IO inflight if so, or rdev with closest distance otherwise. Disk nonrot info can be changed through sysfs entry: /sys/block/[disk_name]/queue/rotational However, consider that this should only be used for testing, and user really shouldn't do this in real life. Record the number of non-rotational disks in conf, to avoid checking each rdev in IO fast path and simplify read_balance() a little bit. Co-developed-by: Paul Luse Signed-off-by: Paul Luse Signed-off-by: Yu Kuai Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240229095714.926789-4-yukuai1@huaweicloud= .com Stable-dep-of: 257ac239ffcf ("md/raid1: fix choose next idle in read_balanc= e()") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/md/md.h | 1 + drivers/md/raid1.c | 17 ++++++++++------- drivers/md/raid1.h | 1 + 3 files changed, 12 insertions(+), 7 deletions(-) diff --git a/drivers/md/md.h b/drivers/md/md.h index 8d881cc597992..27d187ca6258a 100644 --- a/drivers/md/md.h +++ b/drivers/md/md.h @@ -207,6 +207,7 @@ enum flag_bits { * check if there is collision between raid1 * serial bios. */ + Nonrot, /* non-rotational device (SSD) */ }; =20 static inline int is_badblock(struct md_rdev *rdev, sector_t s, int sector= s, diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c index a560824e038b4..456d745eb93b3 100644 --- a/drivers/md/raid1.c +++ b/drivers/md/raid1.c @@ -602,7 +602,6 @@ static int read_balance(struct r1conf *conf, struct r1b= io *r1_bio, int *max_sect int sectors; int best_good_sectors; int best_disk, best_dist_disk, best_pending_disk; - int has_nonrot_disk; int disk; sector_t best_dist; unsigned int min_pending; @@ -623,7 +622,6 @@ static int read_balance(struct r1conf *conf, struct r1b= io *r1_bio, int *max_sect best_pending_disk =3D -1; min_pending =3D UINT_MAX; best_good_sectors =3D 0; - has_nonrot_disk =3D 0; choose_next_idle =3D 0; clear_bit(R1BIO_FailFast, &r1_bio->state); =20 @@ -640,7 +638,6 @@ static int read_balance(struct r1conf *conf, struct r1b= io *r1_bio, int *max_sect sector_t first_bad; int bad_sectors; unsigned int pending; - bool nonrot; =20 rdev =3D conf->mirrors[disk].rdev; if (r1_bio->bios[disk] =3D=3D IO_BLOCKED @@ -706,8 +703,6 @@ static int read_balance(struct r1conf *conf, struct r1b= io *r1_bio, int *max_sect /* At least two disks to choose from so failfast is OK */ set_bit(R1BIO_FailFast, &r1_bio->state); =20 - nonrot =3D bdev_nonrot(rdev->bdev); - has_nonrot_disk |=3D nonrot; pending =3D atomic_read(&rdev->nr_pending); dist =3D abs(this_sector - conf->mirrors[disk].head_position); if (choose_first) { @@ -734,7 +729,7 @@ static int read_balance(struct r1conf *conf, struct r1b= io *r1_bio, int *max_sect * small, but not a big deal since when the second disk * starts IO, the first disk is likely still busy. */ - if (nonrot && opt_iosize > 0 && + if (test_bit(Nonrot, &rdev->flags) && opt_iosize > 0 && mirror->seq_start !=3D MaxSector && mirror->next_seq_sect > opt_iosize && mirror->next_seq_sect - opt_iosize >=3D @@ -766,7 +761,7 @@ static int read_balance(struct r1conf *conf, struct r1b= io *r1_bio, int *max_sect * mixed ratation/non-rotational disks depending on workload. */ if (best_disk =3D=3D -1) { - if (has_nonrot_disk || min_pending =3D=3D 0) + if (READ_ONCE(conf->nonrot_disks) || min_pending =3D=3D 0) best_disk =3D best_pending_disk; else best_disk =3D best_dist_disk; @@ -1771,6 +1766,11 @@ static bool raid1_add_conf(struct r1conf *conf, stru= ct md_rdev *rdev, int disk, if (info->rdev) return false; =20 + if (bdev_nonrot(rdev->bdev)) { + set_bit(Nonrot, &rdev->flags); + WRITE_ONCE(conf->nonrot_disks, conf->nonrot_disks + 1); + } + rdev->raid_disk =3D disk; info->head_position =3D 0; info->seq_start =3D MaxSector; @@ -1794,6 +1794,9 @@ static bool raid1_remove_conf(struct r1conf *conf, in= t disk) rdev->mddev->degraded < conf->raid_disks) return false; =20 + if (test_and_clear_bit(Nonrot, &rdev->flags)) + WRITE_ONCE(conf->nonrot_disks, conf->nonrot_disks - 1); + WRITE_ONCE(info->rdev, NULL); return true; } diff --git a/drivers/md/raid1.h b/drivers/md/raid1.h index 14d4211a123a8..5300cbaa58a41 100644 --- a/drivers/md/raid1.h +++ b/drivers/md/raid1.h @@ -71,6 +71,7 @@ struct r1conf { * allow for replacements. */ int raid_disks; + int nonrot_disks; =20 spinlock_t device_lock; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B011771747; Sun, 24 Mar 2024 22:35:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319737; cv=none; b=R5jrZKEuQw7LvtusPXf/8gGf26kTw38Z9taZUdUdQqPBj1vcGVhrXztS4fWaDPKWXhoPbVzEJnnm2//n6RulndbBB6FO3hEsu+tU4HrYhjTWmxbRzFMmzpZzTa87rWD4MFhR9HLbofQ6/N/zVfvi6AjRMHKEdorIMClniBzZYF0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319737; c=relaxed/simple; bh=DnHkSY9plbk9r7wPX12P8m0EHcoLpjUbPAbBxvt2Jqg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RgRUFQ4HAfLhb2qYc9wku4vYb/nr1DYkhkbRlwoCFFFfknQvWUcvwC0bRUZhZXiRNO4ejMSY7djnUDkeCoLq8FluYnr8h+j41lRSGtfS2IJx+p4kTAvRqzqB+zFKmXFaeO0nzEvd6OsJMbqzllCXp/sUWlmy/ChdidMgolHeAiQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mEKdGbum; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mEKdGbum" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B701CC433A6; Sun, 24 Mar 2024 22:35:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319737; bh=DnHkSY9plbk9r7wPX12P8m0EHcoLpjUbPAbBxvt2Jqg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mEKdGbum5vA/Mm8IrkbvMxJ2bSeLEqH9MNVU2bWrsmlLz1A3876hmqwpUrQ2xv4yw kLCa5oe2Q6i68riiG4CrEwjVM5yw3Hocr+ftekexRumP1k5P1NyEhjwPO0qcowfwlT Zrw2MjdiuW4RSVpJa45hnNZ4cZtW5p+M6nqQvXiDK1FMrv/fux/wp024SJnSESsod+ /DKCUdT7mEz9NKUyomk9U8Nm2WBebiQNOfadFxwdSCWot+zKdDwWOaCzLLGY3VIL9q JVlvKQaF0Z7ldOW83w2BXkyb9L2i6vJG3qwtrVVfCObEYEAu9+n8eShiQumggHBAwF fiM3zsyZ7YOqA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yu Kuai , Paul Luse , Xiao Ni , Song Liu , Sasha Levin Subject: [PATCH 6.8 038/715] md/raid1: fix choose next idle in read_balance() Date: Sun, 24 Mar 2024 18:23:37 -0400 Message-ID: <20240324223455.1342824-39-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yu Kuai [ Upstream commit 257ac239ffcfd097a9a0732bf5095fb00164f334 ] Commit 12cee5a8a29e ("md/raid1: prevent merging too large request") add the case choose next idle in read_balance(): read_balance: for_each_rdev if(next_seq_sect =3D=3D this_sector || dist =3D=3D 0) -> sequential reads best_disk =3D disk; if (...) choose_next_idle =3D 1 continue; for_each_rdev -> iterate next rdev if (pending =3D=3D 0) best_disk =3D disk; -> choose the next idle disk break; if (choose_next_idle) -> keep using this rdev if there are no other idle disk contine However, commit 2e52d449bcec ("md/raid1: add failfast handling for reads.") remove the code: - /* If device is idle, use it */ - if (pending =3D=3D 0) { - best_disk =3D disk; - break; - } Hence choose next idle will never work now, fix this problem by following: 1) don't set best_disk in this case, read_balance() will choose the best disk after iterating all the disks; 2) add 'pending' so that other idle disk will be chosen; 3) add a new local variable 'sequential_disk' to record the disk, and if there is no other idle disk, 'sequential_disk' will be chosen; Fixes: 2e52d449bcec ("md/raid1: add failfast handling for reads.") Co-developed-by: Paul Luse Signed-off-by: Paul Luse Signed-off-by: Yu Kuai Reviewed-by: Xiao Ni Signed-off-by: Song Liu Link: https://lore.kernel.org/r/20240229095714.926789-5-yukuai1@huaweicloud= .com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/md/raid1.c | 32 ++++++++++++++++++++++---------- 1 file changed, 22 insertions(+), 10 deletions(-) diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c index 456d745eb93b3..82c9bb404ccca 100644 --- a/drivers/md/raid1.c +++ b/drivers/md/raid1.c @@ -601,13 +601,12 @@ static int read_balance(struct r1conf *conf, struct r= 1bio *r1_bio, int *max_sect const sector_t this_sector =3D r1_bio->sector; int sectors; int best_good_sectors; - int best_disk, best_dist_disk, best_pending_disk; + int best_disk, best_dist_disk, best_pending_disk, sequential_disk; int disk; sector_t best_dist; unsigned int min_pending; struct md_rdev *rdev; int choose_first; - int choose_next_idle; =20 /* * Check if we can balance. We can balance on the whole @@ -618,11 +617,11 @@ static int read_balance(struct r1conf *conf, struct r= 1bio *r1_bio, int *max_sect sectors =3D r1_bio->sectors; best_disk =3D -1; best_dist_disk =3D -1; + sequential_disk =3D -1; best_dist =3D MaxSector; best_pending_disk =3D -1; min_pending =3D UINT_MAX; best_good_sectors =3D 0; - choose_next_idle =3D 0; clear_bit(R1BIO_FailFast, &r1_bio->state); =20 if ((conf->mddev->recovery_cp < this_sector + sectors) || @@ -715,7 +714,6 @@ static int read_balance(struct r1conf *conf, struct r1b= io *r1_bio, int *max_sect int opt_iosize =3D bdev_io_opt(rdev->bdev) >> 9; struct raid1_info *mirror =3D &conf->mirrors[disk]; =20 - best_disk =3D disk; /* * If buffered sequential IO size exceeds optimal * iosize, check if there is idle disk. If yes, choose @@ -734,15 +732,22 @@ static int read_balance(struct r1conf *conf, struct r= 1bio *r1_bio, int *max_sect mirror->next_seq_sect > opt_iosize && mirror->next_seq_sect - opt_iosize >=3D mirror->seq_start) { - choose_next_idle =3D 1; - continue; + /* + * Add 'pending' to avoid choosing this disk if + * there is other idle disk. + */ + pending++; + /* + * If there is no other idle disk, this disk + * will be chosen. + */ + sequential_disk =3D disk; + } else { + best_disk =3D disk; + break; } - break; } =20 - if (choose_next_idle) - continue; - if (min_pending > pending) { min_pending =3D pending; best_pending_disk =3D disk; @@ -754,6 +759,13 @@ static int read_balance(struct r1conf *conf, struct r1= bio *r1_bio, int *max_sect } } =20 + /* + * sequential IO size exceeds optimal iosize, however, there is no other + * idle disk, so choose the sequential disk. + */ + if (best_disk =3D=3D -1 && min_pending !=3D 0) + best_disk =3D sequential_disk; + /* * If all disks are rotational, choose the closest disk. If any disk is * non-rotational, choose the disk with less pending request even the --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7BB7E71B27; Sun, 24 Mar 2024 22:35:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319738; cv=none; b=gwxaGx+gFa6KsO0RgKNUpGnaR4f1FcdL3YKwRlQYLr3jHu7rfwozInG3nCO9FMUXMOkbOQVD5Rww1C4U4Gu3OvT4UjdU/9cXAJnFGveKCgVp1lpYsyrrG3C6sqFMQ8qDvEF7oiNideGeROJnlIn1CwtRXJoXsrRT3mUCNrgrsx4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319738; c=relaxed/simple; bh=o0P18BDc75hN2CyaedHN48mE5buT5ZzzGqs59ZBu8ls=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iS61FswleVqPzo/QWj9Q14NdyGHHTFhVjHF7JF/FgAD6H/EamJez0BA4XBpTo1OsGdHXxJspZUBhERgPZUTjoev1EDaGT6AejKa0u5XCDxdih6Qb+GezJ3kvRvvcMY2sgj4QXrbtTekQkBrtz9NACMXPRBVAcbIERZ0rjULDTt0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GWkw6TKe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GWkw6TKe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9E25C433F1; Sun, 24 Mar 2024 22:35:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319738; bh=o0P18BDc75hN2CyaedHN48mE5buT5ZzzGqs59ZBu8ls=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GWkw6TKeJewCqhJxGijsgPaH8PvSDrp7PDCjOUX1bloCh8uMymh0lrc9RND5Cjfld j6Fvkvdf6lM31PzfXaav4dxqoO7nDlsrF4xmFAROKG28pNB2xyQS/SmVv3dIGTHzS6 acLCiOwQAv+yKUm4O7y2WHE7BNslrqNYD8rz3IZHkyNzJfqOpHJHpx5drqP02weDi7 Nvw1x+zPLC2OXzC8pkYx1z/zJ+cmsb9Xt2w0Z0wVJq/hBy1FnK9hHdTujg6fAJltuK H/aVboklemGE0sJV60uETiiSGsZvK9EmC2Lwt8rqE/e+yyeA+zLr7tG78bv8rpNMbY Opg7ErDQwuD4Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jens Axboe , Sasha Levin Subject: [PATCH 6.8 039/715] io_uring/net: unify how recvmsg and sendmsg copy in the msghdr Date: Sun, 24 Mar 2024 18:23:38 -0400 Message-ID: <20240324223455.1342824-40-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jens Axboe [ Upstream commit 52307ac4f2b507f60bae6df5be938d35e199c688 ] For recvmsg, we roll our own since we support buffer selections. This isn't the case for sendmsg right now, but in preparation for doing so, make the recvmsg copy helpers generic so we can call them from the sendmsg side as well. Signed-off-by: Jens Axboe Stable-dep-of: 8ede3db5061b ("io_uring/net: fix overflow check in io_recvms= g_mshot_prep()") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- io_uring/net.c | 271 ++++++++++++++++++++++++++----------------------- 1 file changed, 142 insertions(+), 129 deletions(-) diff --git a/io_uring/net.c b/io_uring/net.c index 161622029147c..ef495e2aac2bc 100644 --- a/io_uring/net.c +++ b/io_uring/net.c @@ -204,16 +204,150 @@ static int io_setup_async_msg(struct io_kiocb *req, return -EAGAIN; } =20 +static bool io_recvmsg_multishot_overflow(struct io_async_msghdr *iomsg) +{ + int hdr; + + if (iomsg->namelen < 0) + return true; + if (check_add_overflow((int)sizeof(struct io_uring_recvmsg_out), + iomsg->namelen, &hdr)) + return true; + if (check_add_overflow(hdr, (int)iomsg->controllen, &hdr)) + return true; + + return false; +} + +#ifdef CONFIG_COMPAT +static int __io_compat_msg_copy_hdr(struct io_kiocb *req, + struct io_async_msghdr *iomsg, + struct sockaddr __user **addr, int ddir) +{ + struct io_sr_msg *sr =3D io_kiocb_to_cmd(req, struct io_sr_msg); + struct compat_msghdr msg; + struct compat_iovec __user *uiov; + int ret; + + if (copy_from_user(&msg, sr->umsg_compat, sizeof(msg))) + return -EFAULT; + + ret =3D __get_compat_msghdr(&iomsg->msg, &msg, addr); + if (ret) + return ret; + + uiov =3D compat_ptr(msg.msg_iov); + if (req->flags & REQ_F_BUFFER_SELECT) { + compat_ssize_t clen; + + iomsg->free_iov =3D NULL; + if (msg.msg_iovlen =3D=3D 0) { + sr->len =3D 0; + } else if (msg.msg_iovlen > 1) { + return -EINVAL; + } else { + if (!access_ok(uiov, sizeof(*uiov))) + return -EFAULT; + if (__get_user(clen, &uiov->iov_len)) + return -EFAULT; + if (clen < 0) + return -EINVAL; + sr->len =3D clen; + } + + if (ddir =3D=3D ITER_DEST && req->flags & REQ_F_APOLL_MULTISHOT) { + iomsg->namelen =3D msg.msg_namelen; + iomsg->controllen =3D msg.msg_controllen; + if (io_recvmsg_multishot_overflow(iomsg)) + return -EOVERFLOW; + } + + return 0; + } + + iomsg->free_iov =3D iomsg->fast_iov; + ret =3D __import_iovec(ddir, (struct iovec __user *)uiov, msg.msg_iovlen, + UIO_FASTIOV, &iomsg->free_iov, + &iomsg->msg.msg_iter, true); + if (unlikely(ret < 0)) + return ret; + + return 0; +} +#endif + +static int __io_msg_copy_hdr(struct io_kiocb *req, struct io_async_msghdr = *iomsg, + struct sockaddr __user **addr, int ddir) +{ + struct io_sr_msg *sr =3D io_kiocb_to_cmd(req, struct io_sr_msg); + struct user_msghdr msg; + int ret; + + if (copy_from_user(&msg, sr->umsg, sizeof(*sr->umsg))) + return -EFAULT; + + ret =3D __copy_msghdr(&iomsg->msg, &msg, addr); + if (ret) + return ret; + + if (req->flags & REQ_F_BUFFER_SELECT) { + if (msg.msg_iovlen =3D=3D 0) { + sr->len =3D iomsg->fast_iov[0].iov_len =3D 0; + iomsg->fast_iov[0].iov_base =3D NULL; + iomsg->free_iov =3D NULL; + } else if (msg.msg_iovlen > 1) { + return -EINVAL; + } else { + if (copy_from_user(iomsg->fast_iov, msg.msg_iov, + sizeof(*msg.msg_iov))) + return -EFAULT; + sr->len =3D iomsg->fast_iov[0].iov_len; + iomsg->free_iov =3D NULL; + } + + if (ddir =3D=3D ITER_DEST && req->flags & REQ_F_APOLL_MULTISHOT) { + iomsg->namelen =3D msg.msg_namelen; + iomsg->controllen =3D msg.msg_controllen; + if (io_recvmsg_multishot_overflow(iomsg)) + return -EOVERFLOW; + } + + return 0; + } + + iomsg->free_iov =3D iomsg->fast_iov; + ret =3D __import_iovec(ddir, msg.msg_iov, msg.msg_iovlen, UIO_FASTIOV, + &iomsg->free_iov, &iomsg->msg.msg_iter, false); + if (unlikely(ret < 0)) + return ret; + + return 0; +} + +static int io_msg_copy_hdr(struct io_kiocb *req, struct io_async_msghdr *i= omsg, + struct sockaddr __user **addr, int ddir) +{ + iomsg->msg.msg_name =3D &iomsg->addr; + iomsg->msg.msg_iter.nr_segs =3D 0; + +#ifdef CONFIG_COMPAT + if (req->ctx->compat) + return __io_compat_msg_copy_hdr(req, iomsg, addr, ddir); +#endif + + return __io_msg_copy_hdr(req, iomsg, addr, ddir); +} + static int io_sendmsg_copy_hdr(struct io_kiocb *req, struct io_async_msghdr *iomsg) { struct io_sr_msg *sr =3D io_kiocb_to_cmd(req, struct io_sr_msg); int ret; =20 - iomsg->msg.msg_name =3D &iomsg->addr; - iomsg->free_iov =3D iomsg->fast_iov; - ret =3D sendmsg_copy_msghdr(&iomsg->msg, sr->umsg, sr->msg_flags, - &iomsg->free_iov); + ret =3D io_msg_copy_hdr(req, iomsg, NULL, ITER_SOURCE); + if (ret) + return ret; + /* save msg_control as sys_sendmsg() overwrites it */ sr->msg_control =3D iomsg->msg.msg_control_user; return ret; @@ -435,142 +569,21 @@ int io_send(struct io_kiocb *req, unsigned int issue= _flags) return IOU_OK; } =20 -static bool io_recvmsg_multishot_overflow(struct io_async_msghdr *iomsg) -{ - int hdr; - - if (iomsg->namelen < 0) - return true; - if (check_add_overflow((int)sizeof(struct io_uring_recvmsg_out), - iomsg->namelen, &hdr)) - return true; - if (check_add_overflow(hdr, (int)iomsg->controllen, &hdr)) - return true; - - return false; -} - -static int __io_recvmsg_copy_hdr(struct io_kiocb *req, - struct io_async_msghdr *iomsg) -{ - struct io_sr_msg *sr =3D io_kiocb_to_cmd(req, struct io_sr_msg); - struct user_msghdr msg; - int ret; - - if (copy_from_user(&msg, sr->umsg, sizeof(*sr->umsg))) - return -EFAULT; - - ret =3D __copy_msghdr(&iomsg->msg, &msg, &iomsg->uaddr); - if (ret) - return ret; - - if (req->flags & REQ_F_BUFFER_SELECT) { - if (msg.msg_iovlen =3D=3D 0) { - sr->len =3D iomsg->fast_iov[0].iov_len =3D 0; - iomsg->fast_iov[0].iov_base =3D NULL; - iomsg->free_iov =3D NULL; - } else if (msg.msg_iovlen > 1) { - return -EINVAL; - } else { - if (copy_from_user(iomsg->fast_iov, msg.msg_iov, sizeof(*msg.msg_iov))) - return -EFAULT; - sr->len =3D iomsg->fast_iov[0].iov_len; - iomsg->free_iov =3D NULL; - } - - if (req->flags & REQ_F_APOLL_MULTISHOT) { - iomsg->namelen =3D msg.msg_namelen; - iomsg->controllen =3D msg.msg_controllen; - if (io_recvmsg_multishot_overflow(iomsg)) - return -EOVERFLOW; - } - } else { - iomsg->free_iov =3D iomsg->fast_iov; - ret =3D __import_iovec(ITER_DEST, msg.msg_iov, msg.msg_iovlen, UIO_FASTI= OV, - &iomsg->free_iov, &iomsg->msg.msg_iter, - false); - if (ret > 0) - ret =3D 0; - } - - return ret; -} - -#ifdef CONFIG_COMPAT -static int __io_compat_recvmsg_copy_hdr(struct io_kiocb *req, - struct io_async_msghdr *iomsg) -{ - struct io_sr_msg *sr =3D io_kiocb_to_cmd(req, struct io_sr_msg); - struct compat_msghdr msg; - struct compat_iovec __user *uiov; - int ret; - - if (copy_from_user(&msg, sr->umsg_compat, sizeof(msg))) - return -EFAULT; - - ret =3D __get_compat_msghdr(&iomsg->msg, &msg, &iomsg->uaddr); - if (ret) - return ret; - - uiov =3D compat_ptr(msg.msg_iov); - if (req->flags & REQ_F_BUFFER_SELECT) { - compat_ssize_t clen; - - iomsg->free_iov =3D NULL; - if (msg.msg_iovlen =3D=3D 0) { - sr->len =3D 0; - } else if (msg.msg_iovlen > 1) { - return -EINVAL; - } else { - if (!access_ok(uiov, sizeof(*uiov))) - return -EFAULT; - if (__get_user(clen, &uiov->iov_len)) - return -EFAULT; - if (clen < 0) - return -EINVAL; - sr->len =3D clen; - } - - if (req->flags & REQ_F_APOLL_MULTISHOT) { - iomsg->namelen =3D msg.msg_namelen; - iomsg->controllen =3D msg.msg_controllen; - if (io_recvmsg_multishot_overflow(iomsg)) - return -EOVERFLOW; - } - } else { - iomsg->free_iov =3D iomsg->fast_iov; - ret =3D __import_iovec(ITER_DEST, (struct iovec __user *)uiov, msg.msg_i= ovlen, - UIO_FASTIOV, &iomsg->free_iov, - &iomsg->msg.msg_iter, true); - if (ret < 0) - return ret; - } - - return 0; -} -#endif - static int io_recvmsg_copy_hdr(struct io_kiocb *req, struct io_async_msghdr *iomsg) { - iomsg->msg.msg_name =3D &iomsg->addr; - iomsg->msg.msg_iter.nr_segs =3D 0; - -#ifdef CONFIG_COMPAT - if (req->ctx->compat) - return __io_compat_recvmsg_copy_hdr(req, iomsg); -#endif - - return __io_recvmsg_copy_hdr(req, iomsg); + return io_msg_copy_hdr(req, iomsg, &iomsg->uaddr, ITER_DEST); } =20 int io_recvmsg_prep_async(struct io_kiocb *req) { + struct io_async_msghdr *iomsg; int ret; =20 if (!io_msg_alloc_async_prep(req)) return -ENOMEM; - ret =3D io_recvmsg_copy_hdr(req, req->async_data); + iomsg =3D req->async_data; + ret =3D io_recvmsg_copy_hdr(req, iomsg); if (!ret) req->flags |=3D REQ_F_NEED_CLEANUP; return ret; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 440E371B48; Sun, 24 Mar 2024 22:35:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319739; cv=none; b=TAIN0R+p9m4RjiJRxE8lm33rPJBxFdSDpp1vj02rpZzBczcpyaL8HzHL9DCTKhPr6vxMJVHIPE9CkngxR0S/sSQ9yed9FN1h9Cwo8DHIkYNAU+/5efQnV84a6o8qZLxmRqYHAqzBzXeR8skoLukgfg1UBCR9XnMV1SVcizxGrN4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319739; c=relaxed/simple; bh=gUOyQMOyLGmeWKluDeufXTqUbLq9Ei/WR0Jgx0MLd2w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BiJURnzazV6WUCAQb5LoBeKoRqaF4PNgWjjPbuqtuJAPvOaOUYrct+nUWSFXbIBYiuUsJjFqFftn+H2afF14hdmOhO9qvNDIJbkv6IDpnrWP7yzzHTiPMqPEs7K5jXG0av9yJj5bbREzBkU33VwErjDdk8kb7Z6nrp6xO67VoWE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LHJh3rCo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LHJh3rCo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 956C3C433C7; Sun, 24 Mar 2024 22:35:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319739; bh=gUOyQMOyLGmeWKluDeufXTqUbLq9Ei/WR0Jgx0MLd2w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LHJh3rCoAolj4vIjMy7uhPKXuk6rewb0bZfoiQmn/ealxarmYBMbdOny35abwCXTU 3JYVEBzNLhxIAjjzXDwC462BaGhX3dD0VAH6O7XUuJjzNEH6KlxVaCdx2bB3Ivy3AB wYOhmBVJi9T3guanw3P/K+jdHyaFSvWki1rOliSoC+boSPFwL9ZozuZL062UtHzOmP JGvJuzci81vUO/sGaP7kwiKQj+0M5gNiVH7jKXxOFqoenHYhzC7oI7V8MGJzELjhSD I1bKS+VikH/89gzo/XauKKPR0srxEzEDn3loW2AUN11dJBY0wzhAl0vze1GaPeLSp9 w6i/T6U/a5ZGQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jens Axboe , Sasha Levin Subject: [PATCH 6.8 040/715] io_uring/net: move receive multishot out of the generic msghdr path Date: Sun, 24 Mar 2024 18:23:39 -0400 Message-ID: <20240324223455.1342824-41-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jens Axboe [ Upstream commit c55978024d123d43808ab393a0a4ce3ce8568150 ] Move the actual user_msghdr / compat_msghdr into the send and receive sides, respectively, so we can move the uaddr receive handling into its own handler, and ditto the multishot with buffer selection logic. Signed-off-by: Jens Axboe Stable-dep-of: 8ede3db5061b ("io_uring/net: fix overflow check in io_recvms= g_mshot_prep()") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- io_uring/net.c | 161 ++++++++++++++++++++++++++++--------------------- 1 file changed, 91 insertions(+), 70 deletions(-) diff --git a/io_uring/net.c b/io_uring/net.c index ef495e2aac2bc..1d9bfde71809a 100644 --- a/io_uring/net.c +++ b/io_uring/net.c @@ -204,46 +204,26 @@ static int io_setup_async_msg(struct io_kiocb *req, return -EAGAIN; } =20 -static bool io_recvmsg_multishot_overflow(struct io_async_msghdr *iomsg) -{ - int hdr; - - if (iomsg->namelen < 0) - return true; - if (check_add_overflow((int)sizeof(struct io_uring_recvmsg_out), - iomsg->namelen, &hdr)) - return true; - if (check_add_overflow(hdr, (int)iomsg->controllen, &hdr)) - return true; - - return false; -} - #ifdef CONFIG_COMPAT -static int __io_compat_msg_copy_hdr(struct io_kiocb *req, - struct io_async_msghdr *iomsg, - struct sockaddr __user **addr, int ddir) +static int io_compat_msg_copy_hdr(struct io_kiocb *req, + struct io_async_msghdr *iomsg, + struct compat_msghdr *msg, int ddir) { struct io_sr_msg *sr =3D io_kiocb_to_cmd(req, struct io_sr_msg); - struct compat_msghdr msg; struct compat_iovec __user *uiov; int ret; =20 - if (copy_from_user(&msg, sr->umsg_compat, sizeof(msg))) + if (copy_from_user(msg, sr->umsg_compat, sizeof(*msg))) return -EFAULT; =20 - ret =3D __get_compat_msghdr(&iomsg->msg, &msg, addr); - if (ret) - return ret; - - uiov =3D compat_ptr(msg.msg_iov); + uiov =3D compat_ptr(msg->msg_iov); if (req->flags & REQ_F_BUFFER_SELECT) { compat_ssize_t clen; =20 iomsg->free_iov =3D NULL; - if (msg.msg_iovlen =3D=3D 0) { + if (msg->msg_iovlen =3D=3D 0) { sr->len =3D 0; - } else if (msg.msg_iovlen > 1) { + } else if (msg->msg_iovlen > 1) { return -EINVAL; } else { if (!access_ok(uiov, sizeof(*uiov))) @@ -255,18 +235,11 @@ static int __io_compat_msg_copy_hdr(struct io_kiocb *= req, sr->len =3D clen; } =20 - if (ddir =3D=3D ITER_DEST && req->flags & REQ_F_APOLL_MULTISHOT) { - iomsg->namelen =3D msg.msg_namelen; - iomsg->controllen =3D msg.msg_controllen; - if (io_recvmsg_multishot_overflow(iomsg)) - return -EOVERFLOW; - } - return 0; } =20 iomsg->free_iov =3D iomsg->fast_iov; - ret =3D __import_iovec(ddir, (struct iovec __user *)uiov, msg.msg_iovlen, + ret =3D __import_iovec(ddir, (struct iovec __user *)uiov, msg->msg_iovlen, UIO_FASTIOV, &iomsg->free_iov, &iomsg->msg.msg_iter, true); if (unlikely(ret < 0)) @@ -276,47 +249,35 @@ static int __io_compat_msg_copy_hdr(struct io_kiocb *= req, } #endif =20 -static int __io_msg_copy_hdr(struct io_kiocb *req, struct io_async_msghdr = *iomsg, - struct sockaddr __user **addr, int ddir) +static int io_msg_copy_hdr(struct io_kiocb *req, struct io_async_msghdr *i= omsg, + struct user_msghdr *msg, int ddir) { struct io_sr_msg *sr =3D io_kiocb_to_cmd(req, struct io_sr_msg); - struct user_msghdr msg; int ret; =20 - if (copy_from_user(&msg, sr->umsg, sizeof(*sr->umsg))) + if (copy_from_user(msg, sr->umsg, sizeof(*sr->umsg))) return -EFAULT; =20 - ret =3D __copy_msghdr(&iomsg->msg, &msg, addr); - if (ret) - return ret; - if (req->flags & REQ_F_BUFFER_SELECT) { - if (msg.msg_iovlen =3D=3D 0) { + if (msg->msg_iovlen =3D=3D 0) { sr->len =3D iomsg->fast_iov[0].iov_len =3D 0; iomsg->fast_iov[0].iov_base =3D NULL; iomsg->free_iov =3D NULL; - } else if (msg.msg_iovlen > 1) { + } else if (msg->msg_iovlen > 1) { return -EINVAL; } else { - if (copy_from_user(iomsg->fast_iov, msg.msg_iov, - sizeof(*msg.msg_iov))) + if (copy_from_user(iomsg->fast_iov, msg->msg_iov, + sizeof(*msg->msg_iov))) return -EFAULT; sr->len =3D iomsg->fast_iov[0].iov_len; iomsg->free_iov =3D NULL; } =20 - if (ddir =3D=3D ITER_DEST && req->flags & REQ_F_APOLL_MULTISHOT) { - iomsg->namelen =3D msg.msg_namelen; - iomsg->controllen =3D msg.msg_controllen; - if (io_recvmsg_multishot_overflow(iomsg)) - return -EOVERFLOW; - } - return 0; } =20 iomsg->free_iov =3D iomsg->fast_iov; - ret =3D __import_iovec(ddir, msg.msg_iov, msg.msg_iovlen, UIO_FASTIOV, + ret =3D __import_iovec(ddir, msg->msg_iov, msg->msg_iovlen, UIO_FASTIOV, &iomsg->free_iov, &iomsg->msg.msg_iter, false); if (unlikely(ret < 0)) return ret; @@ -324,30 +285,34 @@ static int __io_msg_copy_hdr(struct io_kiocb *req, st= ruct io_async_msghdr *iomsg return 0; } =20 -static int io_msg_copy_hdr(struct io_kiocb *req, struct io_async_msghdr *i= omsg, - struct sockaddr __user **addr, int ddir) +static int io_sendmsg_copy_hdr(struct io_kiocb *req, + struct io_async_msghdr *iomsg) { + struct io_sr_msg *sr =3D io_kiocb_to_cmd(req, struct io_sr_msg); + struct user_msghdr msg; + int ret; + iomsg->msg.msg_name =3D &iomsg->addr; iomsg->msg.msg_iter.nr_segs =3D 0; =20 #ifdef CONFIG_COMPAT - if (req->ctx->compat) - return __io_compat_msg_copy_hdr(req, iomsg, addr, ddir); -#endif + if (unlikely(req->ctx->compat)) { + struct compat_msghdr cmsg; =20 - return __io_msg_copy_hdr(req, iomsg, addr, ddir); -} + ret =3D io_compat_msg_copy_hdr(req, iomsg, &cmsg, ITER_SOURCE); + if (unlikely(ret)) + return ret; =20 -static int io_sendmsg_copy_hdr(struct io_kiocb *req, - struct io_async_msghdr *iomsg) -{ - struct io_sr_msg *sr =3D io_kiocb_to_cmd(req, struct io_sr_msg); - int ret; + return __get_compat_msghdr(&iomsg->msg, &cmsg, NULL); + } +#endif =20 - ret =3D io_msg_copy_hdr(req, iomsg, NULL, ITER_SOURCE); - if (ret) + ret =3D io_msg_copy_hdr(req, iomsg, &msg, ITER_SOURCE); + if (unlikely(ret)) return ret; =20 + ret =3D __copy_msghdr(&iomsg->msg, &msg, NULL); + /* save msg_control as sys_sendmsg() overwrites it */ sr->msg_control =3D iomsg->msg.msg_control_user; return ret; @@ -569,10 +534,66 @@ int io_send(struct io_kiocb *req, unsigned int issue_= flags) return IOU_OK; } =20 +static int io_recvmsg_mshot_prep(struct io_kiocb *req, + struct io_async_msghdr *iomsg, + size_t namelen, size_t controllen) +{ + if ((req->flags & (REQ_F_APOLL_MULTISHOT|REQ_F_BUFFER_SELECT)) =3D=3D + (REQ_F_APOLL_MULTISHOT|REQ_F_BUFFER_SELECT)) { + int hdr; + + if (unlikely(namelen < 0)) + return -EOVERFLOW; + if (check_add_overflow((int)sizeof(struct io_uring_recvmsg_out), + namelen, &hdr)) + return -EOVERFLOW; + if (check_add_overflow(hdr, (int)controllen, &hdr)) + return -EOVERFLOW; + + iomsg->namelen =3D namelen; + iomsg->controllen =3D controllen; + return 0; + } + + return 0; +} + static int io_recvmsg_copy_hdr(struct io_kiocb *req, struct io_async_msghdr *iomsg) { - return io_msg_copy_hdr(req, iomsg, &iomsg->uaddr, ITER_DEST); + struct user_msghdr msg; + int ret; + + iomsg->msg.msg_name =3D &iomsg->addr; + iomsg->msg.msg_iter.nr_segs =3D 0; + +#ifdef CONFIG_COMPAT + if (unlikely(req->ctx->compat)) { + struct compat_msghdr cmsg; + + ret =3D io_compat_msg_copy_hdr(req, iomsg, &cmsg, ITER_DEST); + if (unlikely(ret)) + return ret; + + ret =3D __get_compat_msghdr(&iomsg->msg, &cmsg, &iomsg->uaddr); + if (unlikely(ret)) + return ret; + + return io_recvmsg_mshot_prep(req, iomsg, cmsg.msg_namelen, + cmsg.msg_controllen); + } +#endif + + ret =3D io_msg_copy_hdr(req, iomsg, &msg, ITER_DEST); + if (unlikely(ret)) + return ret; + + ret =3D __copy_msghdr(&iomsg->msg, &msg, &iomsg->uaddr); + if (unlikely(ret)) + return ret; + + return io_recvmsg_mshot_prep(req, iomsg, msg.msg_namelen, + msg.msg_controllen); } =20 int io_recvmsg_prep_async(struct io_kiocb *req) --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 907CD7172B; Sun, 24 Mar 2024 22:35:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319740; cv=none; b=qtjTdWF7+Rzz/LSHkvGSXzPpgy2qpBP6shg6wOfLEtQtaxlevTjy8bYmPPd6hfaXbO+1TYU/+5sSpuRUuZk1rNMp7rbw3d49FU8eRM/PsSpqT6QdH9vH7doCTV6O1f9kYZGbaVLefrzzy/UBsBJo9A5IvIz9e8d+ZVigPGWeRaA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319740; c=relaxed/simple; bh=+mRypTj2AN+uFrmsMst73xXavbGCXAj069qIzrAjzZE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nqm0uwJ4YiwHDVJOzWiPtmaM4bApbk1tJHN7tzRBWU9ftmBA/mlwEVINIEaV5y5Ulq/wgBgjaP2P4kDcNpPqU/ZAamxsd9IdJy3fjFqKrO3ebtZ0SCmAMt8Qfn08OAFn7T9VhBprokill125pHghTcjY/MRz49gZ1uSG78nKZco= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fuEoHIDY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fuEoHIDY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66339C43399; Sun, 24 Mar 2024 22:35:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319740; bh=+mRypTj2AN+uFrmsMst73xXavbGCXAj069qIzrAjzZE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fuEoHIDYd2Et/hDtJ+r072Bm7rwYTo+R/HhliPb+cUeIqtXCx9/iXMkuOhwR0klEL 7Q1OzTI/4SLjKAdEaLTHq075nh94Vr/s3SRPAxPYqkK6ES1Xg/5HKxn2g2juMEzWfM 4+QSH0ZuO+7YI1Vfy3Qc6ePZWtbnws972UKVARKY6gSIoaAh3+yG6IAyGy5K8dzCbe AL++iwPTgn/Me7uMHLNPbRz126NpClBzrOoZEHcibRPSvb99NUJK74bwOavMCZ9D9O ObnAOMRNWpI4cg6QrzhrMtaFySmQ2mlxy5rQZ0GouF7xnHEbRGicG1etF69mcMlmBr C8qDfR8EPiv2A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dan Carpenter , Jens Axboe , Sasha Levin Subject: [PATCH 6.8 041/715] io_uring/net: fix overflow check in io_recvmsg_mshot_prep() Date: Sun, 24 Mar 2024 18:23:40 -0400 Message-ID: <20240324223455.1342824-42-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dan Carpenter [ Upstream commit 8ede3db5061bb1fe28e2c9683329aafa89d2b1b4 ] The "controllen" variable is type size_t (unsigned long). Casting it to int could lead to an integer underflow. The check_add_overflow() function considers the type of the destination which is type int. If we add two positive values and the result cannot fit in an integer then that's counted as an overflow. However, if we cast "controllen" to an int and it turns negative, then negative values *can* fit into an int type so there is no overflow. Good: 100 + (unsigned long)-4 =3D 96 <-- overflow Bad: 100 + (int)-4 =3D 96 <-- no overflow I deleted the cast of the sizeof() as well. That's not a bug but the cast is unnecessary. Fixes: 9b0fc3c054ff ("io_uring: fix types in io_recvmsg_multishot_overflow") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/138bd2e2-ede8-4bcc-aa7b-f3d9de167a37@moroto= .mountain Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- io_uring/net.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/io_uring/net.c b/io_uring/net.c index 1d9bfde71809a..058e04ea68c04 100644 --- a/io_uring/net.c +++ b/io_uring/net.c @@ -544,10 +544,10 @@ static int io_recvmsg_mshot_prep(struct io_kiocb *req, =20 if (unlikely(namelen < 0)) return -EOVERFLOW; - if (check_add_overflow((int)sizeof(struct io_uring_recvmsg_out), + if (check_add_overflow(sizeof(struct io_uring_recvmsg_out), namelen, &hdr)) return -EOVERFLOW; - if (check_add_overflow(hdr, (int)controllen, &hdr)) + if (check_add_overflow(hdr, controllen, &hdr)) return -EOVERFLOW; =20 iomsg->namelen =3D namelen; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5876D73509; Sun, 24 Mar 2024 22:35:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319741; cv=none; b=tqMV6Q5tSkuHjpDhx8BqiCCqSh2e7zXLWSYCpLhykOpopUBUJhnapoN6msfi8EFqZ0SRVSw+n/fGjB8DyEUCNjBtT7FgXN3hc/5I7Or+B8ANTw+UWXrcbiDn7hLsfYXseJ42iozXFq4gNM9SG199+faokCOuHm3k8hnoE9M+r80= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319741; c=relaxed/simple; bh=sISgqsba65O84SziZyljgb9eLMnknulilo+A5OuNOLc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=U+qlGtWdOemoIV58EBbvLeUjPp+dkSZcIs5jEK3aQpzHGXifRfqpmlmmDtqxd6gz/Kv/QuQ7+/k5seHOKPfP9fjrEMby1CcNKoZKRstVVP7QNDa2eBIbwCc6GIUcNAdSRuQE9Bxo7AwYaC65gUXIpLl2aujUapn2Ve6kbiCa+YU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MFO9Kd0x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MFO9Kd0x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4CE74C433F1; Sun, 24 Mar 2024 22:35:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319741; bh=sISgqsba65O84SziZyljgb9eLMnknulilo+A5OuNOLc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MFO9Kd0xUclEX0iXZ4cRbxxxwWhMY5NHE9WlP4b90Sp4DqMfmDWHVxt+0FFlxvFJm e81QY93aTfJtwzPz3nK9nP4GGt/uGf/RE/Qoyp0fe+7dZpoeQQhgUioQD/IrcQ163r hUErhCy7P4jdV/wlYltRobFmY+gkBYuyKUDqgvo4iq8U6gZI4+Fm122K748+aYH/37 KX0lVIwePeDi8Ui7UZq3JW7Pr8omKt5GtBuKZjDOxVo8CHOMhH9c6mIKeHU3fwFrBC iHRA56fbBJfAhwNoyI94rCGWSWulR50GjaGn+mGt4vfCaL8qhSugv7YRZYQrqZI2JA 5Y5dmM18z6xww== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shin'ichiro Kawasaki , Christoph Hellwig , Daniel Wagner , Chaitanya Kulkarni , Keith Busch , Sasha Levin Subject: [PATCH 6.8 042/715] nvme: host: fix double-free of struct nvme_id_ns in ns_update_nuse() Date: Sun, 24 Mar 2024 18:23:41 -0400 Message-ID: <20240324223455.1342824-43-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shin'ichiro Kawasaki [ Upstream commit 8d0d2447394b13fb22a069f0330f9c49b7fff9d3 ] When nvme_identify_ns() fails, it frees the pointer to the struct nvme_id_ns before it returns. However, ns_update_nuse() calls kfree() for the pointer even when nvme_identify_ns() fails. This results in KASAN double-free, which was observed with blktests nvme/045 with proposed patches [1] on the kernel v6.8-rc7. Fix the double-free by skipping kfree() when nvme_identify_ns() fails. Link: https://lore.kernel.org/linux-block/20240304161303.19681-1-dwagner@su= se.de/ [1] Fixes: a1a825ab6a60 ("nvme: add csi, ms and nuse to sysfs") Signed-off-by: Shin'ichiro Kawasaki Reviewed-by: Christoph Hellwig Reviewed-by: Daniel Wagner Reviewed-by: Chaitanya Kulkarni Signed-off-by: Keith Busch Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/nvme/host/sysfs.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/nvme/host/sysfs.c b/drivers/nvme/host/sysfs.c index f2832f70e7e0a..09fcaa519e5bc 100644 --- a/drivers/nvme/host/sysfs.c +++ b/drivers/nvme/host/sysfs.c @@ -221,14 +221,11 @@ static int ns_update_nuse(struct nvme_ns *ns) =20 ret =3D nvme_identify_ns(ns->ctrl, ns->head->ns_id, &id); if (ret) - goto out_free_id; + return ret; =20 ns->head->nuse =3D le64_to_cpu(id->nuse); - -out_free_id: kfree(id); - - return ret; + return 0; } =20 static ssize_t nuse_show(struct device *dev, struct device_attribute *attr, --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C7C574404; Sun, 24 Mar 2024 22:35:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319742; cv=none; b=oH3JdvshWA2p3ro8JYmJtHwVBmt0qNcslAclOaWMCNIOoISPtLZM94Knd4SqyKt4sr4X2Vq4x3/RULQ2gNfi4Fv7w3iAT6zubzhQWQuue61Y50nv66XrBfGncWA4Pni0+HDaS+9/CMeeOFmqtkd4Ebhsz2lsD05qknWeNOHxYaI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319742; c=relaxed/simple; bh=oR6kvkBMYS2cpiqZLlshxpoI6c+KY4+ToxoVOXN4ufk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=q3kzZNDLrnXbZEW4+LbgalCapGpDO2CvqueQak33FzPlkNBUcWFCmWXJXWh7w1TCce1UXI2qgQ18HALm1Pb05tN5AifC7toXeBWJcR30ogpz+RlRPFVM+h4/Nap4il0oebbCZZxZOrdGZONyXfS6V/qJ4qfIoN7mByBkAM1/StE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j/z6kTz5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="j/z6kTz5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7348AC433C7; Sun, 24 Mar 2024 22:35:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319742; bh=oR6kvkBMYS2cpiqZLlshxpoI6c+KY4+ToxoVOXN4ufk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=j/z6kTz5ghy3C+diuJQ6bcKQhjnrp8VrTpk8MRu0sHUGWC3IiOMnj5EvA+Tk8Hss3 FeCjXMm6kIXIiINbpal3mD0z7NeI1vTDjZPhiNGHoOlfodVr51meSS3HTm28TcOaa2 KKH8kMopbUu28tPrO5f4hDr6/1zn3Ov6P7kMpM6KsPN9dn0IRFPYI63osoL/twVaTd P/jwkTVehkXujeHUfiH7JqoNrU9NAsmjI54qI19e+b/HFHQEXOhuweQhCd0P5yrCZg Q7ua51O1bptmMmyK6DJrFwwN4YxIrv+CZIN9iU3ILbtC9dOfJ93KFOTBJz5pBlhqBG 9FuOp3WprJ05Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chun-Yi Lee , Jens Axboe , Sasha Levin Subject: [PATCH 6.8 043/715] aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts Date: Sun, 24 Mar 2024 18:23:42 -0400 Message-ID: <20240324223455.1342824-44-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chun-Yi Lee [ Upstream commit f98364e926626c678fb4b9004b75cacf92ff0662 ] This patch is against CVE-2023-6270. The description of cve is: A flaw was found in the ATA over Ethernet (AoE) driver in the Linux kernel. The aoecmd_cfg_pkts() function improperly updates the refcnt on `struct net_device`, and a use-after-free can be triggered by racing between the free on the struct and the access through the `skbtxq` global queue. This could lead to a denial of service condition or potential code execution. In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial code is finished. But the net_device ifp will still be used in later tx()->dev_queue_xmit() in kthread. Which means that the dev_put(ifp) should NOT be called in the success path of skb initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into use-after-free because the net_device is freed. This patch removed the dev_put(ifp) in the success path in aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx(). Link: https://nvd.nist.gov/vuln/detail/CVE-2023-6270 Fixes: 7562f876cd93 ("[NET]: Rework dev_base via list_head (v3)") Signed-off-by: Chun-Yi Lee Link: https://lore.kernel.org/r/20240305082048.25526-1-jlee@suse.com Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/block/aoe/aoecmd.c | 12 ++++++------ drivers/block/aoe/aoenet.c | 1 + 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c index d7317425be510..cc9077b588d7e 100644 --- a/drivers/block/aoe/aoecmd.c +++ b/drivers/block/aoe/aoecmd.c @@ -419,13 +419,16 @@ aoecmd_cfg_pkts(ushort aoemajor, unsigned char aoemin= or, struct sk_buff_head *qu rcu_read_lock(); for_each_netdev_rcu(&init_net, ifp) { dev_hold(ifp); - if (!is_aoe_netif(ifp)) - goto cont; + if (!is_aoe_netif(ifp)) { + dev_put(ifp); + continue; + } =20 skb =3D new_skb(sizeof *h + sizeof *ch); if (skb =3D=3D NULL) { printk(KERN_INFO "aoe: skb alloc failure\n"); - goto cont; + dev_put(ifp); + continue; } skb_put(skb, sizeof *h + sizeof *ch); skb->dev =3D ifp; @@ -440,9 +443,6 @@ aoecmd_cfg_pkts(ushort aoemajor, unsigned char aoeminor= , struct sk_buff_head *qu h->major =3D cpu_to_be16(aoemajor); h->minor =3D aoeminor; h->cmd =3D AOECMD_CFG; - -cont: - dev_put(ifp); } rcu_read_unlock(); } diff --git a/drivers/block/aoe/aoenet.c b/drivers/block/aoe/aoenet.c index c51ea95bc2ce4..923a134fd7665 100644 --- a/drivers/block/aoe/aoenet.c +++ b/drivers/block/aoe/aoenet.c @@ -63,6 +63,7 @@ tx(int id) __must_hold(&txlock) pr_warn("aoe: packet could not be sent on %s. %s\n", ifp ? ifp->name : "netif", "consider increasing tx_queue_len"); + dev_put(ifp); spin_lock_irq(&txlock); } return 0; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7F687441F; Sun, 24 Mar 2024 22:35:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319743; cv=none; b=KUE1JpDS7BW9mqaKcrejKs9XVNwjXxWjmk56bNYII752iLTrIY+62PbI0VLpiHOtZqihTCNBbHuonlqAG56UF/krF/q3jmBgCEO0QIoUNcotD5F1WTpU/lmrgY/MDafN5vpakagm4r+zqyfU4oJ9bSfA6QTcyeAdy3wQjJO+Lz4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319743; c=relaxed/simple; bh=vYYFwKto6yg6woV1Hr3fxCR11bex2S34Ri9YamTHIhE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TH0MD59/vcagRtx+3h0tHHycW7qOX7qFFe+g3Z0u84SzCS+8RDgS/yX++tBOTTWnW1f4wj/MxBLvq9SP0yeVq/KMXn6G1ZdugTV2r2yMtDUdK6eO+3DA64bBQKJPYQFv63B2HsRVwUEy2L6lfaD1Ptdi3mxnoSbRK8gxs1zULZE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=POCNoGvU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="POCNoGvU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57E35C433A6; Sun, 24 Mar 2024 22:35:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319743; bh=vYYFwKto6yg6woV1Hr3fxCR11bex2S34Ri9YamTHIhE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=POCNoGvUqs7kP3hwUNumSwgNscJdCSKxGQaMQDv6AiNmkCvWkoVV63did86WUoT/V cwb2fh+5PPM0ZMTbC0sJ3IsNN2l8zEcr0Oa7az0wo7OVAxu5Y5d2I1qvfpKU0plHz+ ZZarxHz70KoR+d9n9vHk5f0/EV0cjt0Nm994cgv1QHpwu+sFfPwtstVVVnlG0wZ5i8 N/ctf5z8VhwBJ1AUjw330FQGGqsgBgPttRcSgL85ob22F9nEE9HfCVR7av7tQLQKOw YUpUe9iQgay8l7cjlopERSp4qfK7FdtTJ6Jg6z4FNw5Eq+lXh081oAQNWsD7o2lXCi Va+CLtqW1Rt1g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Michael Roth , Dave Hansen , "H . Peter Anvin" , Ingo Molnar , Andy Lutomirski , Peter Zijlstra , Rik van Riel , Linus Torvalds , Sasha Levin Subject: [PATCH 6.8 044/715] x86/mm: Ensure input to pfn_to_kaddr() is treated as a 64-bit type Date: Sun, 24 Mar 2024 18:23:43 -0400 Message-ID: <20240324223455.1342824-45-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Michael Roth [ Upstream commit 8e5647a723c49d73b9f108a8bb38e8c29d3948ea ] On 64-bit platforms, the pfn_to_kaddr() macro requires that the input value is 64 bits in order to ensure that valid address bits don't get lost when shifting that input by PAGE_SHIFT to calculate the physical address to provide a virtual address for. One such example is in pvalidate_pages() (used by SEV-SNP guests), where the GFN in the struct used for page-state change requests is a 40-bit bit-field, so attempts to pass this GFN field directly into pfn_to_kaddr() ends up causing guest crashes when dealing with addresses above the 1TB range due to the above. Fix this issue with SEV-SNP guests, as well as any similar cases that might cause issues in current/future code, by using an inline function, instead of a macro, so that the input is implicitly cast to the expected 64-bit input type prior to performing the shift operation. While it might be argued that the issue is on the caller side, other archs/macros have taken similar approaches to deal with instances like this, such as ARM explicitly casting the input to phys_addr_t: e48866647b48 ("ARM: 8396/1: use phys_addr_t in pfn_to_kaddr()") A C inline function is even better though. [ mingo: Refined the changelog some more & added __always_inline. ] Fixes: 6c3211796326 ("x86/sev: Add SNP-specific unaccepted memory support") Suggested-by: Dave Hansen Suggested-by: H. Peter Anvin Signed-off-by: Michael Roth Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20231122163700.400507-1-michael.roth@amd.com Cc: Andy Lutomirski Cc: Peter Zijlstra Cc: Rik van Riel Cc: Linus Torvalds Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/x86/include/asm/page.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h index d18e5c332cb9f..1b93ff80b43bc 100644 --- a/arch/x86/include/asm/page.h +++ b/arch/x86/include/asm/page.h @@ -66,10 +66,14 @@ static inline void copy_user_page(void *to, void *from,= unsigned long vaddr, * virt_addr_valid(kaddr) returns true. */ #define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT) -#define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT) extern bool __virt_addr_valid(unsigned long kaddr); #define virt_addr_valid(kaddr) __virt_addr_valid((unsigned long) (kaddr)) =20 +static __always_inline void *pfn_to_kaddr(unsigned long pfn) +{ + return __va(pfn << PAGE_SHIFT); +} + static __always_inline u64 __canonical_address(u64 vaddr, u8 vaddr_bits) { return ((s64)vaddr << (64 - vaddr_bits)) >> (64 - vaddr_bits); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A0F6C74BE1; Sun, 24 Mar 2024 22:35:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319744; cv=none; b=rQpm+gRUdXi2vzXKQ9TYmHIVma7dAO9bbNBn/aobp8VswjyKzmbZ6HZXGxSAXb6U3OnaFZzdS8YXPN15dNJG1J5WxOylx/zDcfX3qoLx7pn8hJiA3ya/ae8V3qqIMytkMMndX1GjUGe+ZktWNkIacfqAnLCgCyTTFZNegLafsms= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319744; c=relaxed/simple; bh=Bo9STP/2YMxC8WX0+B/N7gU8gl/AULgfdFnHDucbbc8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VxQL/6o4KXa5eMcZAaS3Lzms1ppWgg+0RvB5bAoz6uixrg4xeroYTu5279JPwX7R8os4Sg4VemZcsabH4lJJYGak4QPGqlNOximc1G09uKdPWQe+drRDw61msCyNJtVODKUqPh2XDZwGNMdGBf3bfcEYGDw44YDPLb7u1d45dPY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aYcyow/i; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aYcyow/i" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C63FAC433F1; Sun, 24 Mar 2024 22:35:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319744; bh=Bo9STP/2YMxC8WX0+B/N7gU8gl/AULgfdFnHDucbbc8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aYcyow/iH0Zd/vRUD1WEXXcQeZquECfZrG3WBPwLT8Hwk61UeFN4KtmIc7kbRHfcB 10t8tZkG9glyL2AzmFsRwdM2YNtrKm14P/iW9hl+oC0emi1z2BDm/WzGidPRSXab1/ g61urtO4uwkwdLEadmx/KS2BQS1fmPJz1oSL8JxHYSrQ/41v6tNTBpnw1+J2X0fBRn fGuHseGHjqLiBkwRzMyXsJbefxWsaGVSDaslN24eKL8XMof/kAdgo7OS5d0B1buyEs dztyDQSDAZCN4j+bgqJkCBlnKm6nNaKYiyMl57ihk7Rtodh6//yu6UejAdM+q7RbBW ehJJYhBrDnhJQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Babu Moger , Borislav Petkov , Reinette Chatre , Sasha Levin Subject: [PATCH 6.8 045/715] x86/resctrl: Remove hard-coded memory bandwidth limit Date: Sun, 24 Mar 2024 18:23:44 -0400 Message-ID: <20240324223455.1342824-46-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Babu Moger [ Upstream commit 0976783bb123f30981bc1e7a14d9626a6f63aeac ] The QOS Memory Bandwidth Enforcement Limit is reported by CPUID_Fn80000020_EAX_x01 and CPUID_Fn80000020_EAX_x02: Bits Description 31:0 BW_LEN: Size of the QOS Memory Bandwidth Enforcement Limit. Newer processors can support higher bandwidth limit than the current hard-coded value. Remove latter and detect using CPUID instead. Also, update the register variables eax and edx to match the AMD CPUID definition. The CPUID details are documented in the Processor Programming Reference (PPR) Vol 1.1 for AMD Family 19h Model 11h B1 - 55901 Rev 0.25 in the Link tag below. Fixes: 4d05bf71f157 ("x86/resctrl: Introduce AMD QOS feature") Signed-off-by: Babu Moger Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Reinette Chatre Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D206537 Link: https://lore.kernel.org/r/c26a8ca79d399ed076cf8bf2e9fbc58048808289.17= 05359148.git.babu.moger@amd.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/x86/kernel/cpu/resctrl/core.c | 10 ++++------ arch/x86/kernel/cpu/resctrl/internal.h | 1 - 2 files changed, 4 insertions(+), 7 deletions(-) diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resct= rl/core.c index 19e0681f04356..d04371e851b4c 100644 --- a/arch/x86/kernel/cpu/resctrl/core.c +++ b/arch/x86/kernel/cpu/resctrl/core.c @@ -231,9 +231,7 @@ static bool __get_mem_config_intel(struct rdt_resource = *r) static bool __rdt_get_mem_config_amd(struct rdt_resource *r) { struct rdt_hw_resource *hw_res =3D resctrl_to_arch_res(r); - union cpuid_0x10_3_eax eax; - union cpuid_0x10_x_edx edx; - u32 ebx, ecx, subleaf; + u32 eax, ebx, ecx, edx, subleaf; =20 /* * Query CPUID_Fn80000020_EDX_x01 for MBA and @@ -241,9 +239,9 @@ static bool __rdt_get_mem_config_amd(struct rdt_resourc= e *r) */ subleaf =3D (r->rid =3D=3D RDT_RESOURCE_SMBA) ? 2 : 1; =20 - cpuid_count(0x80000020, subleaf, &eax.full, &ebx, &ecx, &edx.full); - hw_res->num_closid =3D edx.split.cos_max + 1; - r->default_ctrl =3D MAX_MBA_BW_AMD; + cpuid_count(0x80000020, subleaf, &eax, &ebx, &ecx, &edx); + hw_res->num_closid =3D edx + 1; + r->default_ctrl =3D 1 << eax; =20 /* AMD does not use delay */ r->membw.delay_linear =3D false; diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/r= esctrl/internal.h index a4f1aa15f0a2a..d2979748fae47 100644 --- a/arch/x86/kernel/cpu/resctrl/internal.h +++ b/arch/x86/kernel/cpu/resctrl/internal.h @@ -18,7 +18,6 @@ #define MBM_OVERFLOW_INTERVAL 1000 #define MAX_MBA_BW 100u #define MBA_IS_LINEAR 0x4 -#define MAX_MBA_BW_AMD 0x800 #define MBM_CNTR_WIDTH_OFFSET_AMD 20 =20 #define RMID_VAL_ERROR BIT_ULL(63) --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A83E374C0E; Sun, 24 Mar 2024 22:35:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319745; cv=none; b=s8zmaNlNAjMtKtqGNAygVD47VDtf3/2w/DFsEkKPe9CugwNZ9Gg46GscUm7WBW6TtCKcsZ/Yg1+Jywp7imuzdddfHBiylKTFB2Wt21jQ69rmTv14rQqTteiLkbVPKMSHSTytfgRDo87tsFwZJvWz8S3B2RameTLxKis7nT8Ukfc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319745; c=relaxed/simple; bh=P49efD8rlRGlUbOAd0Tvwnd/0EIr02E5XZUZfN8A1nI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=agb0K1FSV/Wyp+2qAtveqvil5b8qdQLSTHMzmuwNaMQa3ILDf8jyNdcsSu9MoqFxdIjGBuCvFTmn75NgOSjrCHhbVZ3Mqsc9AlZpOn/FXsP+PoXldwIYHolK/ecNNOV4aYu8FtFMPVKCaaayHeup4V4SZAnoOcmpqfinJV8KfwU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bdvi8PHy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bdvi8PHy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C326EC433C7; Sun, 24 Mar 2024 22:35:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319745; bh=P49efD8rlRGlUbOAd0Tvwnd/0EIr02E5XZUZfN8A1nI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bdvi8PHyAt9wOQYw+9r7iuJ7PdydMVAC5OCA3SncE0Zzvg7JSXwpkKKBjWOBYMomF fjMfaKTnwfDYmch0I4PxPDhCz/lacpjJMj8nrjM0gV1DVidhLp7GUMljRdrVTnI860 jFNILUJSoTJyKQUYi54pQ9NyZ4IL4OL3+abrA6W8g6B/6zajyFZrct+5UigwZDrVp5 XoLJY7oL6w4oX13zER3HQqPlChScucCzcTbMAjZseIThRJZyfpNIakHcEDE3FzG9NV MSuq/Qx31LNvvsmsvPtvjilCFSkEXoc0UmOSMFgrzlgDcIzbK5uc5IjYJ+JLXevTJu PJNQ2YX+kyTug== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Babu Moger , Borislav Petkov , Reinette Chatre , Sasha Levin Subject: [PATCH 6.8 046/715] x86/resctrl: Read supported bandwidth sources from CPUID Date: Sun, 24 Mar 2024 18:23:45 -0400 Message-ID: <20240324223455.1342824-47-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Babu Moger [ Upstream commit 54e35eb8611cce5550d3d7689679b1a91c864f28 ] If the BMEC (Bandwidth Monitoring Event Configuration) feature is supported, the bandwidth events can be configured. The maximum supported bandwidth bitmask can be read from CPUID: CPUID_Fn80000020_ECX_x03 [Platform QoS Monitoring Bandwidth Event Configu= ration] Bits Description 31:7 Reserved 6:0 Identifies the bandwidth sources that can be tracked. While at it, move the mask checking to mon_config_write() before iterating over all the domains. Also, print the valid bitmask when the user tries to configure invalid event configuration value. The CPUID details are documented in the Processor Programming Reference (PPR) Vol 1.1 for AMD Family 19h Model 11h B1 - 55901 Rev 0.25 in the Link tag. Fixes: dc2a3e857981 ("x86/resctrl: Add interface to read mbm_total_bytes_co= nfig") Signed-off-by: Babu Moger Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Reinette Chatre Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D206537 Link: https://lore.kernel.org/r/669896fa512c7451319fa5ca2fdb6f7e015b5635.17= 05359148.git.babu.moger@amd.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/x86/kernel/cpu/resctrl/internal.h | 3 +++ arch/x86/kernel/cpu/resctrl/monitor.c | 6 ++++++ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 14 ++++++++------ 3 files changed, 17 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/r= esctrl/internal.h index d2979748fae47..e3dc35a00a197 100644 --- a/arch/x86/kernel/cpu/resctrl/internal.h +++ b/arch/x86/kernel/cpu/resctrl/internal.h @@ -394,6 +394,8 @@ struct rdt_parse_data { * @msr_update: Function pointer to update QOS MSRs * @mon_scale: cqm counter * mon_scale =3D occupancy in bytes * @mbm_width: Monitor width, to detect and correct for overflow. + * @mbm_cfg_mask: Bandwidth sources that can be tracked when Bandwidth + * Monitoring Event Configuration (BMEC) is supported. * @cdp_enabled: CDP state of this resource * * Members of this structure are either private to the architecture @@ -408,6 +410,7 @@ struct rdt_hw_resource { struct rdt_resource *r); unsigned int mon_scale; unsigned int mbm_width; + unsigned int mbm_cfg_mask; bool cdp_enabled; }; =20 diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/re= sctrl/monitor.c index f136ac046851c..acca577e2b066 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -813,6 +813,12 @@ int __init rdt_get_mon_l3_config(struct rdt_resource *= r) return ret; =20 if (rdt_cpu_has(X86_FEATURE_BMEC)) { + u32 eax, ebx, ecx, edx; + + /* Detect list of bandwidth sources that can be tracked */ + cpuid_count(0x80000020, 3, &eax, &ebx, &ecx, &edx); + hw_res->mbm_cfg_mask =3D ecx & MAX_EVT_CONFIG_BITS; + if (rdt_cpu_has(X86_FEATURE_CQM_MBM_TOTAL)) { mbm_total_event.configurable =3D true; mbm_config_rftype_init("mbm_total_bytes_config"); diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/r= esctrl/rdtgroup.c index 69a1de92384ab..2b69e560b05f1 100644 --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c @@ -1620,12 +1620,6 @@ static int mbm_config_write_domain(struct rdt_resour= ce *r, struct mon_config_info mon_info =3D {0}; int ret =3D 0; =20 - /* mon_config cannot be more than the supported set of events */ - if (val > MAX_EVT_CONFIG_BITS) { - rdt_last_cmd_puts("Invalid event configuration\n"); - return -EINVAL; - } - /* * Read the current config value first. If both are the same then * no need to write it again. @@ -1663,6 +1657,7 @@ static int mbm_config_write_domain(struct rdt_resourc= e *r, =20 static int mon_config_write(struct rdt_resource *r, char *tok, u32 evtid) { + struct rdt_hw_resource *hw_res =3D resctrl_to_arch_res(r); char *dom_str =3D NULL, *id_str; unsigned long dom_id, val; struct rdt_domain *d; @@ -1686,6 +1681,13 @@ static int mon_config_write(struct rdt_resource *r, = char *tok, u32 evtid) return -EINVAL; } =20 + /* Value from user cannot be more than the supported set of events */ + if ((val & hw_res->mbm_cfg_mask) !=3D val) { + rdt_last_cmd_printf("Invalid event configuration: max valid mask is 0x%0= 2x\n", + hw_res->mbm_cfg_mask); + return -EINVAL; + } + list_for_each_entry(d, &r->domains, list) { if (d->id =3D=3D dom_id) { ret =3D mbm_config_write_domain(r, d, evtid, val); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B6ED3757F0; Sun, 24 Mar 2024 22:35:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319746; cv=none; b=pnNxG9E7qLpAv3Fi3jZIlPHJFOA2ma/jfmDUsMMcsqmr4StZJmv6QZC8TD4GGvl0hPjEfGDqmTCUhA4UTUD2ZD9Js+wsfnACzzyLLU/mzmyEs9Sj9MEkmQ6VpkLKsgxRwyP5LFFQ+NxemnR4Srz1qWqeeFVfcc7LJzAJXP93nsM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319746; c=relaxed/simple; bh=3O2ZGMzYJDzn9u6tCYoGpiraSg8V3UozvV2JPZySKYU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HLG3Ne9aQrt+TNWv3zpkpVVS965J5KGEWDJxUKMYx7yICw+fRCoW+pjnVUJqUoIiNed8kTTHK7/0esMFq87mc+05sgiTbnqacQJe6z5mVoGnTI9I7avLGmV2n9NeNbKVYL3uiEL9oOE088drt1JlQEBOFk6LjdTTMJfsrzKual0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XH7Q4Rd/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XH7Q4Rd/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0F65C43390; Sun, 24 Mar 2024 22:35:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319746; bh=3O2ZGMzYJDzn9u6tCYoGpiraSg8V3UozvV2JPZySKYU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XH7Q4Rd/GEmIiIkyOvs34bVQyGbyXW0+Kf9G2gNAkrgRLszyTkFyA2FdvU1vIHa8u V4cOOQoUzhlazqCD8ybOkgyzbn9ApOnPjJapk3oTAj1rEvsghVCv6NcLDSmp1w2EQk DYxLFitTr4IHcAr26azp0VkrClJD4dqaKaTNbKcSKxaJq7HT0yOm5uAdU05oVxCInl N035ZNPl06ljnZPjPMWhP76yFpT14uoa2hVH1zziqfxS42HNQP8M4XNp8gAwQYKrr6 lSS2hbZR9dd6feiX/vrf590vGQTftALyvJggMQiIQbLoMAoL2UIYsVLxPYaxHrKuYZ AE39D1c5Lqg9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tony Luck , Xiaochen Shen , Borislav Petkov , Reinette Chatre , Sasha Levin Subject: [PATCH 6.8 047/715] x86/resctrl: Implement new mba_MBps throttling heuristic Date: Sun, 24 Mar 2024 18:23:46 -0400 Message-ID: <20240324223455.1342824-48-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tony Luck [ Upstream commit c2427e70c1630d98966375fffc2b713ab9768a94 ] The mba_MBps feedback loop increases throttling when a group is using more bandwidth than the target set by the user in the schemata file, and decreases throttling when below target. To avoid possibly stepping throttling up and down on every poll a flag "delta_comp" is set whenever throttling is changed to indicate that the actual change in bandwidth should be recorded on the next poll in "delta_bw". Throttling is only reduced if the current bandwidth plus delta_bw is below the user target. This algorithm works well if the workload has steady bandwidth needs. But it can go badly wrong if the workload moves to a different phase just as the throttling level changed. E.g. if the workload becomes essentially idle right as throttling level is increased, the value calculated for delta_bw will be more or less the old bandwidth level. If the workload then resumes, Linux may never reduce throttling because current bandwidth plus delta_bw is above the target set by the user. Implement a simpler heuristic by assuming that in the worst case the currently measured bandwidth is being controlled by the current level of throttling. Compute how much it may increase if throttling is relaxed to the next higher level. If that is still below the user target, then it is ok to reduce the amount of throttling. Fixes: ba0f26d8529c ("x86/intel_rdt/mba_sc: Prepare for feedback loop") Reported-by: Xiaochen Shen Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Reinette Chatre Tested-by: Xiaochen Shen Link: https://lore.kernel.org/r/20240122180807.70518-1-tony.luck@intel.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/x86/kernel/cpu/resctrl/internal.h | 4 --- arch/x86/kernel/cpu/resctrl/monitor.c | 42 ++++++-------------------- 2 files changed, 10 insertions(+), 36 deletions(-) diff --git a/arch/x86/kernel/cpu/resctrl/internal.h b/arch/x86/kernel/cpu/r= esctrl/internal.h index e3dc35a00a197..52e7e7deee106 100644 --- a/arch/x86/kernel/cpu/resctrl/internal.h +++ b/arch/x86/kernel/cpu/resctrl/internal.h @@ -295,14 +295,10 @@ struct rftype { * struct mbm_state - status for each MBM counter in each domain * @prev_bw_bytes: Previous bytes value read for bandwidth calculation * @prev_bw: The most recent bandwidth in MBps - * @delta_bw: Difference between the current and previous bandwidth - * @delta_comp: Indicates whether to compute the delta_bw */ struct mbm_state { u64 prev_bw_bytes; u32 prev_bw; - u32 delta_bw; - bool delta_comp; }; =20 /** diff --git a/arch/x86/kernel/cpu/resctrl/monitor.c b/arch/x86/kernel/cpu/re= sctrl/monitor.c index acca577e2b066..3a6c069614eb8 100644 --- a/arch/x86/kernel/cpu/resctrl/monitor.c +++ b/arch/x86/kernel/cpu/resctrl/monitor.c @@ -440,9 +440,6 @@ static void mbm_bw_count(u32 rmid, struct rmid_read *rr) =20 cur_bw =3D bytes / SZ_1M; =20 - if (m->delta_comp) - m->delta_bw =3D abs(cur_bw - m->prev_bw); - m->delta_comp =3D false; m->prev_bw =3D cur_bw; } =20 @@ -520,11 +517,11 @@ static void update_mba_bw(struct rdtgroup *rgrp, stru= ct rdt_domain *dom_mbm) { u32 closid, rmid, cur_msr_val, new_msr_val; struct mbm_state *pmbm_data, *cmbm_data; - u32 cur_bw, delta_bw, user_bw; struct rdt_resource *r_mba; struct rdt_domain *dom_mba; struct list_head *head; struct rdtgroup *entry; + u32 cur_bw, user_bw; =20 if (!is_mbm_local_enabled()) return; @@ -543,7 +540,6 @@ static void update_mba_bw(struct rdtgroup *rgrp, struct= rdt_domain *dom_mbm) =20 cur_bw =3D pmbm_data->prev_bw; user_bw =3D dom_mba->mbps_val[closid]; - delta_bw =3D pmbm_data->delta_bw; =20 /* MBA resource doesn't support CDP */ cur_msr_val =3D resctrl_arch_get_config(r_mba, dom_mba, closid, CDP_NONE); @@ -555,49 +551,31 @@ static void update_mba_bw(struct rdtgroup *rgrp, stru= ct rdt_domain *dom_mbm) list_for_each_entry(entry, head, mon.crdtgrp_list) { cmbm_data =3D &dom_mbm->mbm_local[entry->mon.rmid]; cur_bw +=3D cmbm_data->prev_bw; - delta_bw +=3D cmbm_data->delta_bw; } =20 /* * Scale up/down the bandwidth linearly for the ctrl group. The * bandwidth step is the bandwidth granularity specified by the * hardware. - * - * The delta_bw is used when increasing the bandwidth so that we - * dont alternately increase and decrease the control values - * continuously. - * - * For ex: consider cur_bw =3D 90MBps, user_bw =3D 100MBps and if - * bandwidth step is 20MBps(> user_bw - cur_bw), we would keep - * switching between 90 and 110 continuously if we only check - * cur_bw < user_bw. + * Always increase throttling if current bandwidth is above the + * target set by user. + * But avoid thrashing up and down on every poll by checking + * whether a decrease in throttling is likely to push the group + * back over target. E.g. if currently throttling to 30% of bandwidth + * on a system with 10% granularity steps, check whether moving to + * 40% would go past the limit by multiplying current bandwidth by + * "(30 + 10) / 30". */ if (cur_msr_val > r_mba->membw.min_bw && user_bw < cur_bw) { new_msr_val =3D cur_msr_val - r_mba->membw.bw_gran; } else if (cur_msr_val < MAX_MBA_BW && - (user_bw > (cur_bw + delta_bw))) { + (user_bw > (cur_bw * (cur_msr_val + r_mba->membw.min_bw) / cur_msr_va= l))) { new_msr_val =3D cur_msr_val + r_mba->membw.bw_gran; } else { return; } =20 resctrl_arch_update_one(r_mba, dom_mba, closid, CDP_NONE, new_msr_val); - - /* - * Delta values are updated dynamically package wise for each - * rdtgrp every time the throttle MSR changes value. - * - * This is because (1)the increase in bandwidth is not perfectly - * linear and only "approximately" linear even when the hardware - * says it is linear.(2)Also since MBA is a core specific - * mechanism, the delta values vary based on number of cores used - * by the rdtgrp. - */ - pmbm_data->delta_comp =3D true; - list_for_each_entry(entry, head, mon.crdtgrp_list) { - cmbm_data =3D &dom_mbm->mbm_local[entry->mon.rmid]; - cmbm_data->delta_comp =3D true; - } } =20 static void mbm_update(struct rdt_resource *r, struct rdt_domain *d, int r= mid) --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1B34F7581D; Sun, 24 Mar 2024 22:35:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319748; cv=none; b=u3f2hMwlFOeUh81isHedBem6pjg4IqYBFgspg436Chxv5NkYPSSgeFOdYfgQc5BARfa/aRh4ZIFSnQ9KpzCDBW7HentcTyaF6iVoKkK6SjUWIyBPINr7GxTnGl4iT44Ed66EPJXdBkwHl12Bpp7DXeWKgNHgw0769VWUDJ8ZHaQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319748; c=relaxed/simple; bh=jdfu/KH7YL1zTK/NxSGJU5Hr4wSQlNuG4dX03k2hbfQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jmUOZpuAz/+jTGjQk2dkejoXvw79hT62mOiOde8voaOSmed+2Z+UdsgVYBr4Yew+hvOU5aZmw+U98LnXT5cjq3nzEGQbcHJYHw+ELjv29/vVIhAI3yz+OcC+kLMzjawSVtIxYQJZRZ496PXnVjiAodUzM08ONSx3Sy9X+d4zcMo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nEVTuLiG; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nEVTuLiG" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3111C43394; Sun, 24 Mar 2024 22:35:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319747; bh=jdfu/KH7YL1zTK/NxSGJU5Hr4wSQlNuG4dX03k2hbfQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nEVTuLiGbR+vNSCr/CGK2srh6YoFhdlD94/9505MI7COig8Clzvt8Tt2rKgqN7dSv zKAcfKSkAquClJRstz+GUpkP6kiqKq1n4x2ybKP5N7FUDJ0LUOoyJTYPzQqokzLzA8 JT72elH8C5okPDtbKfBWj8lBvRq3RCy91ptPVSRCB85G0OnIaWmLwihN1gqo0+Ba2r a48c9EHig9+Tzd4AwZU9I+BebVW8dEWb2HyuI9yoMC2uenGxHHOC6VwfvvlbL8owbs pEtBzwElSYd2rUir4hr5PqUsatKCYsSaMfkH+e0vPl98u0VVcuYCcBfIib4P/6PA2G NReLoqJ8Wa4IQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ard Biesheuvel , Borislav Petkov , Tom Lendacky , Sasha Levin Subject: [PATCH 6.8 048/715] x86/sme: Fix memory encryption setting if enabled by default and not overridden Date: Sun, 24 Mar 2024 18:23:47 -0400 Message-ID: <20240324223455.1342824-49-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ard Biesheuvel [ Upstream commit e814b59e6c2b11f5a3d007b2e61f7d550c354c3a ] Commit cbebd68f59f0 ("x86/mm: Fix use of uninitialized buffer in sme_enable()") 'fixed' an issue in sme_enable() detected by static analysis, and broke the common case in the process. cmdline_find_option() will return < 0 on an error, or when the command line argument does not appear at all. In this particular case, the latter is not an error condition, and so the early exit is wrong. Instead, without mem_encrypt=3D on the command line, the compile time default should be honoured, which could be to enable memory encryption, and this is currently broken. Fix it by setting sme_me_mask to a preliminary value based on the compile time default, and only omitting the command line argument test when cmdline_find_option() returns an error. [ bp: Drop active_by_default while at it. ] Fixes: cbebd68f59f0 ("x86/mm: Fix use of uninitialized buffer in sme_enable= ()") Signed-off-by: Ard Biesheuvel Signed-off-by: Borislav Petkov (AMD) Reviewed-by: Tom Lendacky Link: https://lore.kernel.org/r/20240126163918.2908990-2-ardb+git@google.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/x86/mm/mem_encrypt_identity.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/x86/mm/mem_encrypt_identity.c b/arch/x86/mm/mem_encrypt_i= dentity.c index d73aeb16417fc..7f72472a34d6d 100644 --- a/arch/x86/mm/mem_encrypt_identity.c +++ b/arch/x86/mm/mem_encrypt_identity.c @@ -507,7 +507,6 @@ void __init sme_enable(struct boot_params *bp) const char *cmdline_ptr, *cmdline_arg, *cmdline_on, *cmdline_off; unsigned int eax, ebx, ecx, edx; unsigned long feature_mask; - bool active_by_default; unsigned long me_mask; char buffer[16]; bool snp; @@ -593,22 +592,19 @@ void __init sme_enable(struct boot_params *bp) : "p" (sme_cmdline_off)); =20 if (IS_ENABLED(CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT)) - active_by_default =3D true; - else - active_by_default =3D false; + sme_me_mask =3D me_mask; =20 cmdline_ptr =3D (const char *)((u64)bp->hdr.cmd_line_ptr | ((u64)bp->ext_cmd_line_ptr << 32)); =20 if (cmdline_find_option(cmdline_ptr, cmdline_arg, buffer, sizeof(buffer))= < 0) - return; + goto out; =20 if (!strncmp(buffer, cmdline_on, sizeof(buffer))) sme_me_mask =3D me_mask; else if (!strncmp(buffer, cmdline_off, sizeof(buffer))) sme_me_mask =3D 0; - else - sme_me_mask =3D active_by_default ? me_mask : 0; + out: if (sme_me_mask) { physical_mask &=3D ~sme_me_mask; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 07A3B76047; Sun, 24 Mar 2024 22:35:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319749; cv=none; b=BBOPJqP+qSiBUHRdKWrrzRb5fbPmW6ezT9dIPf+Xarjm5UfbS9edNQcnDmO5kpQKfDgeNoJJw5KKAWz8Ky279B8L7cahQk1YaDL1Xh3BooBR6BsKux2kHc1bMkQbkmS3uJRShkBmKzcWjUwuDaTr3+PlMJzefk3gs+fJNOFkVaM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319749; c=relaxed/simple; bh=23eHHuh/DV2k7PZWl6XBVkeG9jJGgENpTKhIC6FWxGs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OXbTpexkdCUVb+p9NXYjFZfKzZNnSLqSfUMHvECJAD56X/lpIkU53MLZ4EbUmP2gpYeEqwhclNHCrOmhrwyZ9TVw8kr+uOBU0qJVLdLcJteQ2nDSbEoIKbUpkJAn3Hj2GbnEvQdRtpOuJOl2y/bX1aaCQ5ZtCBBDhpuOFT3p1JM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=edZeNxu4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="edZeNxu4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CFDABC433A6; Sun, 24 Mar 2024 22:35:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319748; bh=23eHHuh/DV2k7PZWl6XBVkeG9jJGgENpTKhIC6FWxGs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=edZeNxu4CtDTK4WDuqSmv4BXYpV61gz1g+gImkcOAEYZWMFflOnOgHq9r+g7cq4aA FV/PRrQc3gQ/fWhY9hoi7ce9BfvJU5BLbUBPVY1EjY69dQLi138BfMH8gdoBqZzuz4 PfwXdxsTCujl/jAlIoWniO2qniyr3vVl0LGI6SGHxeTUe1Vuz61IvLPb/ekANbhSf/ Xrc357bhJw/HrJGkpA7DXa9EK06tF8wxujJXQmgeTmpCxKMA4Ogk4UtDz7jbhp3grH 2M/hFYxM5rotqzJYpSKyJU8jkY1mzKGLNEF8Bbgxm0QzjJmasDiu03vkPa4snTc1aB CuQN8JB973TtA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Hilber , Thomas Gleixner , John Stultz , Sasha Levin Subject: [PATCH 6.8 049/715] timekeeping: Fix cross-timestamp interpolation on counter wrap Date: Sun, 24 Mar 2024 18:23:48 -0400 Message-ID: <20240324223455.1342824-50-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Hilber [ Upstream commit 84dccadd3e2a3f1a373826ad71e5ced5e76b0c00 ] cycle_between() decides whether get_device_system_crosststamp() will interpolate for older counter readings. cycle_between() yields wrong results for a counter wrap-around where after < before < test, and for the case after < test < before. Fix the comparison logic. Fixes: 2c756feb18d9 ("time: Add history to cross timestamp interface suppor= ting slower devices") Signed-off-by: Peter Hilber Signed-off-by: Thomas Gleixner Acked-by: John Stultz Link: https://lore.kernel.org/r/20231218073849.35294-2-peter.hilber@opensyn= ergy.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/time/timekeeping.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 266d02809dbb1..8f35455b62509 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -1186,7 +1186,7 @@ static bool cycle_between(u64 before, u64 test, u64 a= fter) { if (test > before && test < after) return true; - if (test < before && before > after) + if (before > after && (test > before || test < after)) return true; return false; } --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90C2D762FF; Sun, 24 Mar 2024 22:35:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319749; cv=none; b=neQoP8WSqFfdoHekdymVE8hsXYlzE28GjffolTE1LvvnRPSg4Ic27xIy7Q7FHtXKizVOQzQGfrIhD436ao3HRZSiN3OOqKD3Tpea7JVK6tsZJd1SN2m9qp7t8FJXBmbqV6jzlz2E3xrgHNoXsjYqhgDcIBqgDkgsxi+bkTpJ/b0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319749; c=relaxed/simple; bh=OrTxKuavkmAwp8h1Jo3aMTmD6H5/LjHaoUEWZ+XZ/aQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=M96vuT1ZNQmNmn0OS2kQ2k6DwKm2GIsy3koOkl402+9wvYFzpuIPaSrhYqNJtO+oksr1E+Kc1gyAbbr/mIanPVyTb5GWcmYt97B13vX5RuBNr2YeGrakmz9E7exDaC1fdtnGHE3e3yQAEhzu3HLtXIP/T3wMhCr3HCCF3wPCy+Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=g0gv85sZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="g0gv85sZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE2DFC433F1; Sun, 24 Mar 2024 22:35:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319749; bh=OrTxKuavkmAwp8h1Jo3aMTmD6H5/LjHaoUEWZ+XZ/aQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g0gv85sZMGw3Lh4HL0pgB1Bw1hQtFdSVDyOh0LkqVRl+MBw6TYVoUv03GBNmR5z/P fchC/KmkIx5SnmXtWoOlohay6UwJUG1e6NXeY0PKUq1NuhWdUGH8dGS+7QQvMfdhmf EzNrQZyOK4YJt6C5T6osrwupmPjJy09ooPkyZXEr3ViAJe8YHEvhlDuE/Opch5gIgf s/i8fL7IPTJTTwhc0+bYUz707siN2L/TlT8jCb0KlY+hHF3ToT5LbupF/cOgv7EIah dSTqaAZCMLCR8otyy2O2b0z2T+CbdEBw1Mg0Pq5XroqszHAOV5nbiZgipDeLIbAgMv tRK9vDGsdbslw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Hilber , Thomas Gleixner , Sasha Levin Subject: [PATCH 6.8 050/715] timekeeping: Fix cross-timestamp interpolation corner case decision Date: Sun, 24 Mar 2024 18:23:49 -0400 Message-ID: <20240324223455.1342824-51-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Hilber [ Upstream commit 87a41130881995f82f7adbafbfeddaebfb35f0ef ] The cycle_between() helper checks if parameter test is in the open interval (before, after). Colloquially speaking, this also applies to the counter wrap-around special case before > after. get_device_system_crosststamp() currently uses cycle_between() at the first call site to decide whether to interpolate for older counter readings. get_device_system_crosststamp() has the following problem with cycle_between() testing against an open interval: Assume that, by chance, cycles =3D=3D tk->tkr_mono.cycle_last (in the following, "cycle_last" for brevity). Then, cycle_between() at the first call site, with effective argument values cycle_between(cycle_last, cycles, now), returns false, enabling interpolation. During interpolation, get_device_system_crosststamp() will then call cycle_between() at the second call site (if a history_begin was supplied). The effective argument values are cycle_between(history_begin->cycles, cycles, cycles), since system_counterval.cycles =3D=3D interval_start =3D=3D cycles, per the assum= ption. Due to the test against the open interval, cycle_between() returns false again. This causes get_device_system_crosststamp() to return -EINVAL. This failure should be avoided, since get_device_system_crosststamp() works both when cycles follows cycle_last (no interpolation), and when cycles precedes cycle_last (interpolation). For the case cycles =3D=3D cycle_last, interpolation is actually unneeded. Fix this by changing cycle_between() into timestamp_in_interval(), which now checks against the closed interval, rather than the open interval. This changes the get_device_system_crosststamp() behavior for three corner cases: 1. Bypass interpolation in the case cycles =3D=3D tk->tkr_mono.cycle_last, fixing the problem described above. 2. At the first timestamp_in_interval() call site, cycles =3D=3D now no lon= ger causes failure. 3. At the second timestamp_in_interval() call site, history_begin->cycles =3D=3D system_counterval.cycles no longer causes failure. adjust_historical_crosststamp() also works for this corner case, where partial_history_cycles =3D=3D total_history_cycles. These behavioral changes should not cause any problems. Fixes: 2c756feb18d9 ("time: Add history to cross timestamp interface suppor= ting slower devices") Signed-off-by: Peter Hilber Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20231218073849.35294-3-peter.hilber@opensyn= ergy.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/time/timekeeping.c | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 8f35455b62509..4e9f2f88c9d6e 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -1180,13 +1180,15 @@ static int adjust_historical_crosststamp(struct sys= tem_time_snapshot *history, } =20 /* - * cycle_between - true if test occurs chronologically between before and = after + * timestamp_in_interval - true if ts is chronologically in [start, end] + * + * True if ts occurs chronologically at or after start, and before or at e= nd. */ -static bool cycle_between(u64 before, u64 test, u64 after) +static bool timestamp_in_interval(u64 start, u64 end, u64 ts) { - if (test > before && test < after) + if (ts >=3D start && ts <=3D end) return true; - if (before > after && (test > before || test < after)) + if (start > end && (ts >=3D start || ts <=3D end)) return true; return false; } @@ -1246,7 +1248,7 @@ int get_device_system_crosststamp(int (*get_time_fn) */ now =3D tk_clock_read(&tk->tkr_mono); interval_start =3D tk->tkr_mono.cycle_last; - if (!cycle_between(interval_start, cycles, now)) { + if (!timestamp_in_interval(interval_start, now, cycles)) { clock_was_set_seq =3D tk->clock_was_set_seq; cs_was_changed_seq =3D tk->cs_was_changed_seq; cycles =3D interval_start; @@ -1277,13 +1279,13 @@ int get_device_system_crosststamp(int (*get_time_fn) bool discontinuity; =20 /* - * Check that the counter value occurs after the provided + * Check that the counter value is not before the provided * history reference and that the history doesn't cross a * clocksource change */ if (!history_begin || - !cycle_between(history_begin->cycles, - system_counterval.cycles, cycles) || + !timestamp_in_interval(history_begin->cycles, + cycles, system_counterval.cycles) || history_begin->cs_was_changed_seq !=3D cs_was_changed_seq) return -EINVAL; partial_history_cycles =3D cycles - system_counterval.cycles; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D40137640F; Sun, 24 Mar 2024 22:35:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319750; cv=none; b=DQ0w2fGi+Y3Eh3ibbBNepaQakH8EP9FU4AwSs0Q1GV9WTvI1tlZjdQ69p3uDczp6ymqSNqj+gQx3atnUZf51y9U2Ag63mbgUP3EWXjbIhVZBH5FMxB5m/8CueuR1o0dtXo+1/35u5VRD17J/a/z94zl31gB+iueEg+h69U9FIHA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319750; c=relaxed/simple; bh=4NV8jozK46/fbyAfW2dcGTbTjJRTkGsTkxZjNikSahs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WpK59C2QTBOw/y/aYTaW5ztO6QW4UJDDVag7+xQnsOKxToILznH5RLsXzZffqOaOfuOx38EfWkMdrvm6FdR4rYk93Uazo8MJ8n9VJVjnjfTNEaK0u3EVigW0hax7c1AItulriLXV4FW4k9v8MMRymkwjNU89Jp7PqK0acNSRczE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mXKHtYKC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mXKHtYKC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4D3FC43394; Sun, 24 Mar 2024 22:35:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319750; bh=4NV8jozK46/fbyAfW2dcGTbTjJRTkGsTkxZjNikSahs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mXKHtYKCvBtvhjztJhqODT9tBFVoMdFJ+yCqRZHRMV+o56We4jF2CDlh5rttorNh2 klWoBNGz6aauUn3JJiN53jXMnG44iFd3pdeYOuwK4kEi2YyVvZx4Wq2zGqJEF0wkPf zT+PCH6wjRB5OU7pfy9vcHiQeiLsUNZI/UrgGONfqp7hbNP9o+3Z9UvliUBGideGvM ubSy50qP/mMNo8+2VKxAWjDwtGjyX0QcS9TRsaEiMtP+MXmWO1gQO5OT13VbD3jkBe 48nBgF3bNKJunMNNnqtdnGukgo8MZFEmkZm3w6nRPA4kGvEI8w6tlxSMe/P/VaYBte Zj8iSK5iwCTeA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Hilber , Thomas Gleixner , John Stultz , Sasha Levin Subject: [PATCH 6.8 051/715] timekeeping: Fix cross-timestamp interpolation for non-x86 Date: Sun, 24 Mar 2024 18:23:50 -0400 Message-ID: <20240324223455.1342824-52-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Hilber [ Upstream commit 14274d0bd31b4debf28284604589f596ad2e99f2 ] So far, get_device_system_crosststamp() unconditionally passes system_counterval.cycles to timekeeping_cycles_to_ns(). But when interpolating system time (do_interp =3D=3D true), system_counterval.cycles= is before tkr_mono.cycle_last, contrary to the timekeeping_cycles_to_ns() expectations. On x86, CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE will mitigate on interpolating, setting delta to 0. With delta =3D=3D 0, xtstamp->sys_monoraw and xtstamp->sys_realtime are then set to the last update time, as implicitly expected by adjust_historical_crosststamp(). On other architectures, the resulting nonsense xtstamp->sys_monoraw and xtstamp->sys_realtime corrupt the xtstamp (ts) adjustment in adjust_historical_crosststamp(). Fix this by deriving xtstamp->sys_monoraw and xtstamp->sys_realtime from the last update time when interpolating, by using the local variable "cycles". The local variable already has the right value when interpolating, unlike system_counterval.cycles. Fixes: 2c756feb18d9 ("time: Add history to cross timestamp interface suppor= ting slower devices") Signed-off-by: Peter Hilber Signed-off-by: Thomas Gleixner Acked-by: John Stultz Link: https://lore.kernel.org/r/20231218073849.35294-4-peter.hilber@opensyn= ergy.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/time/timekeeping.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c index 4e9f2f88c9d6e..8aab7ed414907 100644 --- a/kernel/time/timekeeping.c +++ b/kernel/time/timekeeping.c @@ -1261,10 +1261,8 @@ int get_device_system_crosststamp(int (*get_time_fn) tk_core.timekeeper.offs_real); base_raw =3D tk->tkr_raw.base; =20 - nsec_real =3D timekeeping_cycles_to_ns(&tk->tkr_mono, - system_counterval.cycles); - nsec_raw =3D timekeeping_cycles_to_ns(&tk->tkr_raw, - system_counterval.cycles); + nsec_real =3D timekeeping_cycles_to_ns(&tk->tkr_mono, cycles); + nsec_raw =3D timekeeping_cycles_to_ns(&tk->tkr_raw, cycles); } while (read_seqcount_retry(&tk_core.seq, seq)); =20 xtstamp->sys_realtime =3D ktime_add_ns(base_real, nsec_real); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB2167EF05; Sun, 24 Mar 2024 22:35:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319751; cv=none; b=HbyfKEEsLql/X4iD1MfI2J3pHsV7uLMReufGyg78r5NoNCxxH68R68SADj5N1pEDMQ9BfvlY41grqv2QneUoRLTPPkEt73AHMpxg+DMKTm1w/l/0jJ6YoLA4JSOmtIfKCNePWL2NWlWlL5qNcQaaC34yE+DWr2bgiIfo8JDO790= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319751; c=relaxed/simple; bh=OYBxtdsfzusqnwQiK4p5xxJ3U+GQNmbFOaggNSEenBs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=R7Pi7LJDFuMq+bXlq7KNa/zxhgYuxCLRtjlYbPBn/KLdLe5sN71V9FmN8YZisrp4L1rpZnyYYCbzzlSGQgrv8gP7KZO9ems39uHYm03bbpI5AvJY7vs1PDtoW6RyXxaa79DazOzAlDts/u21w3vw3XlT5mSWrc7aJdK5dQNr7Qs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s7sj1L9Z; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s7sj1L9Z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1EF1C43399; Sun, 24 Mar 2024 22:35:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319751; bh=OYBxtdsfzusqnwQiK4p5xxJ3U+GQNmbFOaggNSEenBs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s7sj1L9ZK3TuNT4/ao7fJTQOfVC6kOTCspr6hmC3uaMJDo4eca2yHhtArd4jZWHsc 71LE7nXKADKYLhLvPnsHVwYG5Z/CRhPclcCJHZRIwg98r9K7LX5rnaR48XmYNmUl6t AVKPDP9sPPGqHccW2X5N1X+4kDHsehFdMosksd6KciTjg+J6oSXQEleDZ6ASsKrHi4 2ySm8XzfQT1JWZJW8k4tGa47rr1KYeB60SHS3ol9L1s/OGyJOBQufObgK656L0NxfC Lz0V85HT3kUBC8B4iC0sK26hdhu4AotjpapFM9H+XBob/Dd2A5R5H1LgtiAvW5OUGQ RukUIS2sGTAkQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kai Huang , kernel test robot , Dave Hansen , Dave Jiang , "Kirill A . Shutemov" , Yuan Yao , Sasha Levin Subject: [PATCH 6.8 052/715] x86/asm: Remove the __iomem annotation of movdir64b()'s dst argument Date: Sun, 24 Mar 2024 18:23:51 -0400 Message-ID: <20240324223455.1342824-53-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kai Huang [ Upstream commit 5bdd181821b2c65b074cfad07d7c7d5d3cfe20bf ] Commit e56d28df2f66 ("x86/virt/tdx: Configure global KeyID on all packages") causes a sparse warning: arch/x86/virt/vmx/tdx/tdx.c:683:27: warning: incorrect type in argument 1= (different address spaces) arch/x86/virt/vmx/tdx/tdx.c:683:27: expected void [noderef] __iomem *d= st arch/x86/virt/vmx/tdx/tdx.c:683:27: got void * The reason is TDX must use the MOVDIR64B instruction to convert TDX private memory (which is normal RAM but not MMIO) back to normal. The TDX code uses existing movdir64b() helper to do that, but the first argument @dst of movdir64b() is annotated with __iomem. When movdir64b() was firstly introduced in commit 0888e1030d3e ("x86/asm: Carve out a generic movdir64b() helper for general usage"), it didn't have the __iomem annotation. But this commit also introduced the same "incorrect type" sparse warning because the iosubmit_cmds512(), which was the solo caller of movdir64b(), has the __iomem annotation. This was later fixed by commit 6ae58d871319 ("x86/asm: Annotate movdir64b()'s dst argument with __iomem"). That fix was reasonable because until TDX code the movdir64b() was only used to move data to MMIO location, as described by the commit message: ... The current usages send a 64-bytes command descriptor to an MMIO location (portal) on a device for consumption. When future usages for the MOVDIR64B instruction warrant a separate variant of a memory to memory operation, the argument annotation can be revisited. Now TDX code uses MOVDIR64B to move data to normal memory so it's time to revisit. The SDM says the destination of MOVDIR64B is "memory location specified in a general register", thus it's more reasonable that movdir64b() does not have the __iomem annotation on the @dst. Remove the __iomem annotation from the @dst argument of movdir64b() to fix the sparse warning in TDX code. Similar to memset_io(), introduce a new movdir64b_io() to cover the case where the destination is an MMIO location, and change the solo caller iosubmit_cmds512() to use the new movdir64b_io(). In movdir64b_io() explicitly use __force in the type casting otherwise there will be below sparse warning: warning: cast removes address space '__iomem' of expression [ dhansen: normal changelog tweaks ] Closes: https://lore.kernel.org/oe-kbuild-all/202312311924.tGjsBIQD-lkp@int= el.com/ Fixes: e56d28df2f66 ("x86/virt/tdx: Configure global KeyID on all packages") Reported-by: kernel test robot Signed-off-by: Kai Huang Signed-off-by: Dave Hansen Reviewed-by: Dave Jiang Reviewed-by: Kirill A. Shutemov Reviewed-by: Yuan Yao Link: https://lore.kernel.org/all/20240126023852.11065-1-kai.huang%40intel.= com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/x86/include/asm/io.h | 2 +- arch/x86/include/asm/special_insns.h | 9 +++++++-- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index 3814a9263d64e..294cd2a408181 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -379,7 +379,7 @@ static inline void iosubmit_cmds512(void __iomem *dst, = const void *src, const u8 *end =3D from + count * 64; =20 while (from < end) { - movdir64b(dst, from); + movdir64b_io(dst, from); from +=3D 64; } } diff --git a/arch/x86/include/asm/special_insns.h b/arch/x86/include/asm/sp= ecial_insns.h index 48f8dd47cf688..09a5461d72439 100644 --- a/arch/x86/include/asm/special_insns.h +++ b/arch/x86/include/asm/special_insns.h @@ -224,10 +224,10 @@ static inline void serialize(void) } =20 /* The dst parameter must be 64-bytes aligned */ -static inline void movdir64b(void __iomem *dst, const void *src) +static inline void movdir64b(void *dst, const void *src) { const struct { char _[64]; } *__src =3D src; - struct { char _[64]; } __iomem *__dst =3D dst; + struct { char _[64]; } *__dst =3D dst; =20 /* * MOVDIR64B %(rdx), rax. @@ -245,6 +245,11 @@ static inline void movdir64b(void __iomem *dst, const = void *src) : "m" (*__src), "a" (__dst), "d" (__src)); } =20 +static inline void movdir64b_io(void __iomem *dst, const void *src) +{ + movdir64b((void __force *)dst, src); +} + /** * enqcmds - Enqueue a command in supervisor (CPL0) mode * @dst: destination, in MMIO space (must be 512-bit aligned) --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E62DC7F7DF; Sun, 24 Mar 2024 22:35:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319753; cv=none; b=bwmXhBX+BsvOEtatgqb9UW7B4P1dYbAwuCGZdqV8cHoxolDHuXbsA706xJ7SpF4XVFfx1U4TpDR5RCfrPei0iqvQ/ZTyQ2AK7/+wkWbgjnMNkx/1xRJJMDK+KR9IZah5w9rYk7saZkWpsN7vPhj5YxUh+9/StIRUaSHoA0LZU0A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319753; c=relaxed/simple; bh=1gglt1oQJ1MNnZhWrJGf0VB0kc9/2EXTX9V9hXcUnE8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=C9/3NK2jd+d7jtVs+JXeozgnOpRosrcOYdrK3c2MS75Rm6O+NxrHkV1K93bJW/lDVrqcIwcMQ3UN9oH0FiaVZmjPmV5z3WJxeeERPAtL+jrZx3mIAIG6pEwJ8/mSUaWppZfDPPQHzQjf60jpaKSV5++XgoLvAkUX72bpUR2bDL8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ob6ibY5B; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ob6ibY5B" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0060DC433F1; Sun, 24 Mar 2024 22:35:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319752; bh=1gglt1oQJ1MNnZhWrJGf0VB0kc9/2EXTX9V9hXcUnE8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ob6ibY5BqtgWhA5XH5PhPGx4WFr3XYY5TmWsmiqirCaBV0Z1DM61ikEi2w7WvrtHt V3SYoSRziLjgevUyMIKn1gI+e/hWlGRLIaaoBwgpZqlwV15QgTZeGAtmAeMRuivMer 7kkvbEKh3DJG8oVGjtIx691AL3bJ6nD/u2Tp3XCz5GKtR5w1vC2S0Br+35FZ4bY8RP Pbur+nO6I4eItA2PG2iy3BnN+WcihO7uZ8RXL3426Xz4m2o0nVj9R0g2mTPGLIdW80 OdBmD3u8VIhGm75E6hwDxSVXTwKTWa7k6aJivplth5mpTUnzLApV+LUp0VB2QDlZEn 4I1C4o0YORNow== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Keisuke Nishimura , Julia Lawall , Ingo Molnar , Vincent Guittot , Sasha Levin Subject: [PATCH 6.8 053/715] sched/fair: Take the scheduling domain into account in select_idle_smt() Date: Sun, 24 Mar 2024 18:23:52 -0400 Message-ID: <20240324223455.1342824-54-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Keisuke Nishimura [ Upstream commit 8aeaffef8c6eceab0e1498486fdd4f3dc3b7066c ] When picking a CPU on task wakeup, select_idle_smt() has to take into account the scheduling domain of @target. This is because the "isolcpus" kernel command line option can remove CPUs from the domain to isolate them from other SMT siblings. This fix checks if the candidate CPU is in the target scheduling domain. Commit: df3cb4ea1fb6 ("sched/fair: Fix wrong cpu selecting from isolated domain") ... originally introduced this fix by adding the check of the scheduling domain in the loop. However, commit: 3e6efe87cd5cc ("sched/fair: Remove redundant check in select_idle_smt()") ... accidentally removed the check. Bring it back. Fixes: 3e6efe87cd5c ("sched/fair: Remove redundant check in select_idle_smt= ()") Signed-off-by: Keisuke Nishimura Signed-off-by: Julia Lawall Signed-off-by: Ingo Molnar Reviewed-by: Vincent Guittot Link: https://lore.kernel.org/r/20240110131707.437301-1-keisuke.nishimura@i= nria.fr Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/sched/fair.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 533547e3c90a7..66457d4b8965c 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7311,13 +7311,19 @@ static int select_idle_core(struct task_struct *p, = int core, struct cpumask *cpu /* * Scan the local SMT mask for idle CPUs. */ -static int select_idle_smt(struct task_struct *p, int target) +static int select_idle_smt(struct task_struct *p, struct sched_domain *sd,= int target) { int cpu; =20 for_each_cpu_and(cpu, cpu_smt_mask(target), p->cpus_ptr) { if (cpu =3D=3D target) continue; + /* + * Check if the CPU is in the LLC scheduling domain of @target. + * Due to isolcpus, there is no guarantee that all the siblings are in t= he domain. + */ + if (!cpumask_test_cpu(cpu, sched_domain_span(sd))) + continue; if (available_idle_cpu(cpu) || sched_idle_cpu(cpu)) return cpu; } @@ -7341,7 +7347,7 @@ static inline int select_idle_core(struct task_struct= *p, int core, struct cpuma return __select_idle_cpu(core, p); } =20 -static inline int select_idle_smt(struct task_struct *p, int target) +static inline int select_idle_smt(struct task_struct *p, struct sched_doma= in *sd, int target) { return -1; } @@ -7591,7 +7597,7 @@ static int select_idle_sibling(struct task_struct *p,= int prev, int target) has_idle_core =3D test_idle_cores(target); =20 if (!has_idle_core && cpus_share_cache(prev, target)) { - i =3D select_idle_smt(p, prev); + i =3D select_idle_smt(p, sd, prev); if ((unsigned int)i < nr_cpumask_bits) return i; } --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E16E780026; Sun, 24 Mar 2024 22:35:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319754; cv=none; b=flp4jv9DAlCL2XYwhTU47Pka6XJN3bhDg4UzrxgicmEanOVcZDxa5FyMGwx6M7E4HOCWn52Lu4DpvysWfFY6BJvWKFQLhBXo+jGqpHxNoa0PlX/fgBRKvQwxoHCzXaqJqg8KuiZ6dmrvZXjj+JKbeqij6XCUjHXxm8QZSK/jZco= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319754; c=relaxed/simple; bh=pPJ1TW10UmyE3sNxjNNcrlM7CqVYVT02xmFTk6rywQk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fK+pD/aXtmPTetdorG93M4sb3EHcLG0b6jbxCEStmjxy/TenHU7Zp49261XMsTcSlq5Ls/Pzqc48XmkLxaOdj65XiMhufW6Gd5eRWtgjIS1YCy5K3NK6/lqOn+Ubf93VuwajUyx8OkEhX7iQJsh1uKaxu+b1iMtcnQ66jrQ9Y3M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jL8lHQxU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jL8lHQxU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 13EB6C43390; Sun, 24 Mar 2024 22:35:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319753; bh=pPJ1TW10UmyE3sNxjNNcrlM7CqVYVT02xmFTk6rywQk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jL8lHQxUGNnLP+gv4xf9XLv712GDiA4hBrTtvasMBilHBeKJja/NJdLncKp7MUMSA lU4qh3Ks2CIPfQnrDCUGq16eUrAAuF3/z8PuNZHwUXcIjUCWP+oxA6aEbThNQPxBYF W3SNkr0fN9JfilhMGB6uCfQd5XxIpLI001Fas/EgjUJ/K2zgLkDXXEUuAzev/DkqOL U8Jxus9pIVU1AborhMkulbHErnO5FzGylort7eWMmqSITqGPsp9IhdVi7vE1AEOkDE b+sI2b2pJhMyqncEdc7QXFWnSLr7LgUL7utpJZh1CaKdvBQWv65uX7MG3g8v61HMCW 85nPucBK0ZRWw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Keisuke Nishimura , Julia Lawall , Ingo Molnar , Sasha Levin Subject: [PATCH 6.8 054/715] sched/fair: Take the scheduling domain into account in select_idle_core() Date: Sun, 24 Mar 2024 18:23:53 -0400 Message-ID: <20240324223455.1342824-55-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Keisuke Nishimura [ Upstream commit 23d04d8c6b8ec339057264659b7834027f3e6a63 ] When picking a CPU on task wakeup, select_idle_core() has to take into account the scheduling domain where the function looks for the CPU. This is because the "isolcpus" kernel command line option can remove CPUs from the domain to isolate them from other SMT siblings. This change replaces the set of CPUs allowed to run the task from p->cpus_ptr by the intersection of p->cpus_ptr and sched_domain_span(sd) which is stored in the 'cpus' argument provided by select_idle_cpu(). Fixes: 9fe1f127b913 ("sched/fair: Merge select_idle_core/cpu()") Signed-off-by: Keisuke Nishimura Signed-off-by: Julia Lawall Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20240110131707.437301-2-keisuke.nishimura@i= nria.fr Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/sched/fair.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 66457d4b8965c..e2b4e0396af84 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -7289,7 +7289,7 @@ static int select_idle_core(struct task_struct *p, in= t core, struct cpumask *cpu if (!available_idle_cpu(cpu)) { idle =3D false; if (*idle_cpu =3D=3D -1) { - if (sched_idle_cpu(cpu) && cpumask_test_cpu(cpu, p->cpus_ptr)) { + if (sched_idle_cpu(cpu) && cpumask_test_cpu(cpu, cpus)) { *idle_cpu =3D cpu; break; } @@ -7297,7 +7297,7 @@ static int select_idle_core(struct task_struct *p, in= t core, struct cpumask *cpu } break; } - if (*idle_cpu =3D=3D -1 && cpumask_test_cpu(cpu, p->cpus_ptr)) + if (*idle_cpu =3D=3D -1 && cpumask_test_cpu(cpu, cpus)) *idle_cpu =3D cpu; } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EBAE380612; Sun, 24 Mar 2024 22:35:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319755; cv=none; b=J2MVcaxSJBef/9WDkoiNDuCeGX+Q83t2hRdBIegoKc8fl2dXMTEcd4zny2aCiOuum7V99vaU7dLokBn0nv08IqrWaruEj+muStLW+j5siPAiJ4yMtZIIGzSl4hQ6d6JfBDVZ8gx0rf2XwRUG3Xgrmf9FozGdtmI3rRJ01xKeJ7w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319755; c=relaxed/simple; bh=oYYvn/6nxGWAVbko5rNqBa3zP6x2dNPOvgw8qbioNx4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gWJzbTAgq3WMOPq8p2aRYYmawAaWrzNJ0cEZpMS/1RnAc0pIrDA/6Myol/1sg890KG5dQTGZIkk92RH6xCFj/A6tEFbSA4N6fNbReV4J8X3qMAyi/TyUD1Ztin7vSdI5hhg9Tu0gv7rra35f9qtHjBph4MJuKQDaMQa1JI4G9Xc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hR2xXuwf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hR2xXuwf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F2D2C433C7; Sun, 24 Mar 2024 22:35:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319754; bh=oYYvn/6nxGWAVbko5rNqBa3zP6x2dNPOvgw8qbioNx4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hR2xXuwfjXPU3owqX0ayc+3+aZbqYzJb+qJ4vMjD4v9jwhqRW9j96Pm/glurdb/PC Q4K4S6Zyf6j0+BvsOLFmdUtVtIAxIW5U60+WUGpuwSrB6eO4wp0A7JBlhi2xQ0pd9j C5Tyrh6M1JXD9vViLkgxsxOvDyu0A2nIu/Y8+GVGg3TaYtqIXtuVfEQXXDwrRK2fY2 fqNXRSoJAJJpy6OMdXta/JnHWrG3RJLzmBW/M826kRdbnFHq/crjZw53GOe7I0KlCP DpGSqfu2M/zL4yuvdc0D/d48R92IoRdIHvV7s4gN/LoGia2x4dbVKjmipx89tSoWei lHM422INdSLkQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Xingyuan Mo , Jeff Johnson , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 055/715] wifi: ath10k: fix NULL pointer dereference in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() Date: Sun, 24 Mar 2024 18:23:54 -0400 Message-ID: <20240324223455.1342824-56-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Xingyuan Mo [ Upstream commit ad25ee36f00172f7d53242dc77c69fff7ced0755 ] We should check whether the WMI_TLV_TAG_STRUCT_MGMT_TX_COMPL_EVENT tlv is present before accessing it, otherwise a null pointer deference error will occur. Fixes: dc405152bb64 ("ath10k: handle mgmt tx completion event") Signed-off-by: Xingyuan Mo Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20231208043433.271449-1-hdthky0@gmail.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/ath/ath10k/wmi-tlv.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wirele= ss/ath/ath10k/wmi-tlv.c index 6b6aa3c367448..0ce08e9a0a3d2 100644 --- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c +++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c @@ -851,6 +851,10 @@ ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev(struct ath10k = *ar, struct sk_buff *skb, } =20 ev =3D tb[WMI_TLV_TAG_STRUCT_MGMT_TX_COMPL_EVENT]; + if (!ev) { + kfree(tb); + return -EPROTO; + } =20 arg->desc_id =3D ev->desc_id; arg->status =3D ev->status; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB67880C0D; Sun, 24 Mar 2024 22:35:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319756; cv=none; b=RSPE6T7+6RvSQ/SyBQ6euE6FkN1r39AaTMmQDGlt2LqOGj2vY8NI6BB0x5k7ANg5SNdXJKvyxdLY5ZsrtOnwGWg0zxUWBZEFWqS8Jzo6Qr6kJi6bFS3kKD2ePrrv6/2R5OkgFuAB7cL9uGEBKxTZB8bgYOSkR1DOlQdkKxNt3xk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319756; c=relaxed/simple; bh=MdKkC8K2KCUHqqeU/mA8WssUVLz2uaJbi/ZYVNKSEuI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Xkn9qrQYhZd6WIEpj5mGsesw60VYBm5yKAFnZ9jPSLK9RQzi4ZM4KfkTaY4CKlahzauRAgiHwOjUF9df78t6CfZopXWCZSJurxQnNQ4v8ihLGCitbXZPP1VihiUpfmQ9NgxmxqSB0tzdVR5df//tajOPBjspbWbcstzv/vxWP8E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gojwi0f6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gojwi0f6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0BDCEC43390; Sun, 24 Mar 2024 22:35:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319755; bh=MdKkC8K2KCUHqqeU/mA8WssUVLz2uaJbi/ZYVNKSEuI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gojwi0f6smrZyRfvNwQGatRoQBitEWX1U4y+m2Nl8J9he86ssBqVFTB+shHatfo8I K5eBVpR7O0/lYCjzcG7ud3nd/aiAI20A4MBzred3T0pIaVrKYAoyNG6hg1b6cwf74f eQv6G9eIBtsZKQkxOC79WMn3XMYM5wkEG06Asm0RAd/Ip1xAVNRmc6Mc6x0VwTUydb 1LVyctcdQGbLn2SaWpFeHpIgPyWTSWMo1XCBjoAusCddh7DI//byMf/b65UeNc0Xfu ELS/et/SJBFKlwN1pMpKFr9f+LqC+dw385PL3j7s/V6yr7WcEKPRijNVapjm3pv6kK b41HgvEe2IAZg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Rahul Rameshbabu , Julian Calaby , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 056/715] wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled Date: Sun, 24 Mar 2024 18:23:55 -0400 Message-ID: <20240324223455.1342824-57-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Rahul Rameshbabu [ Upstream commit 9636951e4468f02c72cc75a82dc65d003077edbc ] When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated. Log of issue before change (with kernel parameter qos=3D0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __i= eee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_s= eq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt= _addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_g= eneric ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf= _defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf= _log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uin= put iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp j= oydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap bt= mtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 a= pplesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat = videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_cl= mulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suball= oc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobu= f2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_help= er cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_= common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_unco= re llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastc= harge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux= i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_powe= r_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libar= c4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore con= figfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_= keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class h= id_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10d= if_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul = crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_= intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc3= 2c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last = unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O= 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B1= 71B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 = f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 = <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 00000000= 00000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8882= 0b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 00000000= 0003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 00000000= 00000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffff= c0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knl= GS:0000000000000000 [ +0.000001] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007fafda7ae008 CR3: 000000046d220005 CR4: 00000000= 000606e0 [ +0.000002] Call Trace: [ +0.000003] [ +0.000001] ? __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000044] ? __warn+0x81/0x130 [ +0.000005] ? __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000045] ? report_bug+0x171/0x1a0 [ +0.000004] ? handle_bug+0x41/0x70 [ +0.000004] ? exc_invalid_op+0x17/0x70 [ +0.000003] ? asm_exc_invalid_op+0x1a/0x20 [ +0.000005] ? __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000043] ieee80211_wake_queue+0x4a/0x80 [mac80211] [ +0.000044] b43_dma_handle_txstatus+0x29c/0x3a0 [b43] [ +0.000016] ? __pfx_irq_thread_fn+0x10/0x10 [ +0.000002] b43_handle_txstatus+0x61/0x80 [b43] [ +0.000012] b43_interrupt_thread_handler+0x3f9/0x6b0 [b43] [ +0.000011] irq_thread_fn+0x23/0x60 [ +0.000002] irq_thread+0xfe/0x1c0 [ +0.000002] ? __pfx_irq_thread_dtor+0x10/0x10 [ +0.000001] ? __pfx_irq_thread+0x10/0x10 [ +0.000001] kthread+0xe8/0x120 [ +0.000003] ? __pfx_kthread+0x10/0x10 [ +0.000003] ret_from_fork+0x34/0x50 [ +0.000002] ? __pfx_kthread+0x10/0x10 [ +0.000002] ret_from_fork_asm+0x1b/0x30 [ +0.000004] [ +0.000001] ---[ end trace 0000000000000000 ]--- [ +0.000065] ------------[ cut here ]------------ [ +0.000001] WARNING: CPU: 0 PID: 56077 at net/mac80211/util.c:514 __i= eee80211_stop_queue+0xcc/0xe0 [mac80211] [ +0.000077] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_s= eq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt= _addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_g= eneric ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf= _defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf= _log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uin= put iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp j= oydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap bt= mtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 a= pplesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat = videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_cl= mulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suball= oc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobu= f2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000073] videodev bridge snd_hda_core rapl crc16 drm_display_help= er cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_= common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_unco= re llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastc= harge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux= i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_powe= r_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libar= c4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore con= figfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_= keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class h= id_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10d= if_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul = crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_= intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000084] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc3= 2c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last = unloaded: b43] [ +0.000012] CPU: 0 PID: 56077 Comm: kworker/u16:17 Tainted: G = W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B1= 71B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] Workqueue: phy7 b43_tx_work [b43] [ +0.000019] RIP: 0010:__ieee80211_stop_queue+0xcc/0xe0 [mac80211] [ +0.000076] Code: 74 11 48 8b 78 08 0f b7 d6 89 e9 4c 89 e6 e8 ab f4 = 00 00 65 ff 0d 9c b7 34 3f 0f 85 55 ff ff ff 0f 1f 44 00 00 e9 4b ff ff ff = <0f> 0b 5b 5d 41 5c 41 5d c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 [ +0.000002] RSP: 0000:ffffc90004157d50 EFLAGS: 00010097 [ +0.000002] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 00000000= 00000000 [ +0.000002] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff8882= d65d0900 [ +0.000002] RBP: 0000000000000000 R08: 0000000000000001 R09: 00000000= 00000001 [ +0.000001] R10: 00000000000000ff R11: ffff88814d0155a0 R12: ffff8882= d65d0900 [ +0.000002] R13: 0000000000000000 R14: ffff8881002d2800 R15: 00000000= 000000d0 [ +0.000002] FS: 0000000000000000(0000) GS:ffff88846f800000(0000) knl= GS:0000000000000000 [ +0.000003] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000002] CR2: 00007f2e8c10c880 CR3: 0000000385b66005 CR4: 00000000= 000606f0 [ +0.000002] Call Trace: [ +0.000001] [ +0.000001] ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211] [ +0.000075] ? __warn+0x81/0x130 [ +0.000004] ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211] [ +0.000075] ? report_bug+0x171/0x1a0 [ +0.000005] ? handle_bug+0x41/0x70 [ +0.000003] ? exc_invalid_op+0x17/0x70 [ +0.000004] ? asm_exc_invalid_op+0x1a/0x20 [ +0.000004] ? __ieee80211_stop_queue+0xcc/0xe0 [mac80211] [ +0.000076] ieee80211_stop_queue+0x36/0x50 [mac80211] [ +0.000077] b43_dma_tx+0x550/0x780 [b43] [ +0.000023] b43_tx_work+0x90/0x130 [b43] [ +0.000018] process_one_work+0x174/0x340 [ +0.000003] worker_thread+0x27b/0x3a0 [ +0.000004] ? __pfx_worker_thread+0x10/0x10 [ +0.000002] kthread+0xe8/0x120 [ +0.000003] ? __pfx_kthread+0x10/0x10 [ +0.000004] ret_from_fork+0x34/0x50 [ +0.000002] ? __pfx_kthread+0x10/0x10 [ +0.000003] ret_from_fork_asm+0x1b/0x30 [ +0.000006] [ +0.000001] ---[ end trace 0000000000000000 ]--- Fixes: e6f5b934fba8 ("b43: Add QOS support") Signed-off-by: Rahul Rameshbabu Reviewed-by: Julian Calaby Signed-off-by: Kalle Valo Link: https://msgid.link/20231231050300.122806-2-sergeantsagara@protonmail.= com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/broadcom/b43/b43.h | 16 ++++++++++++++++ drivers/net/wireless/broadcom/b43/dma.c | 4 ++-- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/broadcom/b43/b43.h b/drivers/net/wireless= /broadcom/b43/b43.h index 67b4bac048e58..c0d8fc0b22fb2 100644 --- a/drivers/net/wireless/broadcom/b43/b43.h +++ b/drivers/net/wireless/broadcom/b43/b43.h @@ -1082,6 +1082,22 @@ static inline bool b43_using_pio_transfers(struct b4= 3_wldev *dev) return dev->__using_pio_transfers; } =20 +static inline void b43_wake_queue(struct b43_wldev *dev, int queue_prio) +{ + if (dev->qos_enabled) + ieee80211_wake_queue(dev->wl->hw, queue_prio); + else + ieee80211_wake_queue(dev->wl->hw, 0); +} + +static inline void b43_stop_queue(struct b43_wldev *dev, int queue_prio) +{ + if (dev->qos_enabled) + ieee80211_stop_queue(dev->wl->hw, queue_prio); + else + ieee80211_stop_queue(dev->wl->hw, 0); +} + /* Message printing */ __printf(2, 3) void b43info(struct b43_wl *wl, const char *fmt, ...); __printf(2, 3) void b43err(struct b43_wl *wl, const char *fmt, ...); diff --git a/drivers/net/wireless/broadcom/b43/dma.c b/drivers/net/wireless= /broadcom/b43/dma.c index 760d1a28edc6c..6ac7dcebfff9d 100644 --- a/drivers/net/wireless/broadcom/b43/dma.c +++ b/drivers/net/wireless/broadcom/b43/dma.c @@ -1399,7 +1399,7 @@ int b43_dma_tx(struct b43_wldev *dev, struct sk_buff = *skb) should_inject_overflow(ring)) { /* This TX ring is full. */ unsigned int skb_mapping =3D skb_get_queue_mapping(skb); - ieee80211_stop_queue(dev->wl->hw, skb_mapping); + b43_stop_queue(dev, skb_mapping); dev->wl->tx_queue_stopped[skb_mapping] =3D true; ring->stopped =3D true; if (b43_debug(dev, B43_DBG_DMAVERBOSE)) { @@ -1570,7 +1570,7 @@ void b43_dma_handle_txstatus(struct b43_wldev *dev, } else { /* If the driver queue is running wake the corresponding * mac80211 queue. */ - ieee80211_wake_queue(dev->wl->hw, ring->queue_prio); + b43_wake_queue(dev, ring->queue_prio); if (b43_debug(dev, B43_DBG_DMAVERBOSE)) { b43dbg(dev->wl, "Woke up TX ring %d\n", ring->index); } --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E0D1781207; Sun, 24 Mar 2024 22:35:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319757; cv=none; b=TQMaXisOKuunX++5IgxSjTxDCrbznE8R0vSi3Fhbm5t8UcGR/FNEnLKYZ2p6fG/bkGSZOJuzheX5zuMFPLDUFWdJAg5y8UVA4gAqfTXUf5t/3j3mmpqJJcYeCFGd1yaiB6DS9Um++tzO7mVZMK8MmgvVNDhlGhgEIfDjBhsyEBI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319757; c=relaxed/simple; bh=5WtQM2tX+LYOhsFO7UKkhfKkpfG6hezjSSD2zr4H3Qo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Xy9enWlKfSsOasHkP44LgrtBcaxtxbwLqQ1kh/7ceIv7CMXnE1Zszf+y7/N5D0bmNa6E25ZieMTiezt5L4j9cGQgyyzf5JEhUtNaH7AefY8Jd/amtv9mXJjwhuW46uXKYKgTpYzHymSkBGxCc/Zey+D0hu8w2yp5UY5ElMuOKEQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nVyuclJ/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nVyuclJ/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C866C433C7; Sun, 24 Mar 2024 22:35:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319756; bh=5WtQM2tX+LYOhsFO7UKkhfKkpfG6hezjSSD2zr4H3Qo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nVyuclJ/QNE0uZSva0WeDLgjdLoBEQAmkNCLdiPfdRcGM55zj/44+cYhMhAr/azXW HgCKnCvMf/Mlztw/mTCiiq+UhiZ2ItRXVDAxNyJrvgONvtfR9PA68BbjVDzmZHghF9 b/WfjkIt4mzFfPGZiubRbOuTpMxl1JcdlMsnGM6HIsnHnfu9GLYlpSMMdg+X7ddSgP F5xucXthgJ8Oss2yE9VSf0Y+SFyvaBAQasXYhS2FTF0NdFTe49wF9X9hrV4jsCLoYl AsLXnS0nt/IZ4CxqVQFr7tTv1DTStCaU7DE0LtyoJfzbVsvnl7j09M1KlSR+VJDkF0 IF+ajlSVTYKtA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Rahul Rameshbabu , Julian Calaby , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 057/715] wifi: b43: Stop/wake correct queue in PIO Tx path when QoS is disabled Date: Sun, 24 Mar 2024 18:23:56 -0400 Message-ID: <20240324223455.1342824-58-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Rahul Rameshbabu [ Upstream commit 77135a38f6c2f950d2306ac3d37cbb407e6243f2 ] When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS is disabled to prevent trying to stop/wake a non-existent queue and failing to stop/wake the actual queue instantiated. Fixes: 5100d5ac81b9 ("b43: Add PIO support for PCMCIA devices") Signed-off-by: Rahul Rameshbabu Reviewed-by: Julian Calaby Signed-off-by: Kalle Valo Link: https://msgid.link/20231231050300.122806-3-sergeantsagara@protonmail.= com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/broadcom/b43/pio.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/broadcom/b43/pio.c b/drivers/net/wireless= /broadcom/b43/pio.c index 0cf70fdb60a6a..e41f2f5b4c266 100644 --- a/drivers/net/wireless/broadcom/b43/pio.c +++ b/drivers/net/wireless/broadcom/b43/pio.c @@ -525,7 +525,7 @@ int b43_pio_tx(struct b43_wldev *dev, struct sk_buff *s= kb) if (total_len > (q->buffer_size - q->buffer_used)) { /* Not enough memory on the queue. */ err =3D -EBUSY; - ieee80211_stop_queue(dev->wl->hw, skb_get_queue_mapping(skb)); + b43_stop_queue(dev, skb_get_queue_mapping(skb)); q->stopped =3D true; goto out; } @@ -552,7 +552,7 @@ int b43_pio_tx(struct b43_wldev *dev, struct sk_buff *s= kb) if (((q->buffer_size - q->buffer_used) < roundup(2 + 2 + 6, 4)) || (q->free_packet_slots =3D=3D 0)) { /* The queue is full. */ - ieee80211_stop_queue(dev->wl->hw, skb_get_queue_mapping(skb)); + b43_stop_queue(dev, skb_get_queue_mapping(skb)); q->stopped =3D true; } =20 @@ -587,7 +587,7 @@ void b43_pio_handle_txstatus(struct b43_wldev *dev, list_add(&pack->list, &q->packets_list); =20 if (q->stopped) { - ieee80211_wake_queue(dev->wl->hw, q->queue_prio); + b43_wake_queue(dev, q->queue_prio); q->stopped =3D false; } } --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4681681AD8; Sun, 24 Mar 2024 22:35:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319758; cv=none; b=shYpIUdAylr2mhKsEVTgaiCRv72V7CMDfUQNm05Utg5/MXXceKF33/BI1H4Kx4fErZsdeyAHdn3v03dR18hkztGg8/UayQ+E3AEIQuDUQSu1onYhIRN8PggkgGZ7xbX0j12y+Tc7H+HpGpYYEQNrdzm4HNbf+yenZnEokx8gAfw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319758; c=relaxed/simple; bh=T+ReKdZ9roAuzU/DfsquugIpMTaDIpDuv/0TiIsOPPI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KGXdN88sCh7e9l3YdyxgL+10ttYcD46f8h3WM98DrxNabY3QfBL2ModiikgvTi8IXJreE/pf5kGjIl3tybdgjNPJAv8Wg+httNdw4hrC3RfAoPDxn/JwCRpYYTJycFAzS+CYtIEm1fmPNtkKg7xjqda9tFjMT+G6GUeFEiJB+W8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gCGSu0jY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gCGSu0jY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 086C6C43390; Sun, 24 Mar 2024 22:35:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319757; bh=T+ReKdZ9roAuzU/DfsquugIpMTaDIpDuv/0TiIsOPPI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gCGSu0jY7evgzMDny8Vyuovq9qeSQEYFX2/ojodCbEMXY/HZMgLc6akIo85xmp6EL siZ7KTkfeIKFCOr9OJ6IuPm6W0q273/4cdvEodIoYbmYWpiGucTkJW7mJjLgdwUB/I SiXCiDXgqiMyUdHHyjnixsfuYN3uuCn9KuyWS0NSM2Ko/NW4svtesE3iz8HAbnmoD8 UeWnpHr1qlQ+eV6cD+LNbH7FgqC09W5fgECzgcpKGazBfNVw0K+vXlf9xyWQ+v3E4m sBrHJkWSQ6jN7VIyXaA/FwwHggqy5oKfhM9qOhc/y+Rz2B2Y5/t7R828cKLu24IUGq BdgVto/M4UNnw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Rahul Rameshbabu , Julian Calaby , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 058/715] wifi: b43: Stop correct queue in DMA worker when QoS is disabled Date: Sun, 24 Mar 2024 18:23:57 -0400 Message-ID: <20240324223455.1342824-59-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Rahul Rameshbabu [ Upstream commit 581c8967d66c4961076dbbee356834e9c6777184 ] When QoS is disabled, the queue priority value will not map to the correct ieee80211 queue since there is only one queue. Stop queue 0 when QoS is disabled to prevent trying to stop a non-existent queue and failing to stop the actual queue instantiated. Fixes: bad691946966 ("b43: avoid packet losses in the dma worker code.") Signed-off-by: Rahul Rameshbabu Reviewed-by: Julian Calaby Signed-off-by: Kalle Valo Link: https://msgid.link/20231231050300.122806-4-sergeantsagara@protonmail.= com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/broadcom/b43/main.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/net/wireless/broadcom/b43/main.c b/drivers/net/wireles= s/broadcom/b43/main.c index 92ca0b2ca286d..97d8bdeaa06cb 100644 --- a/drivers/net/wireless/broadcom/b43/main.c +++ b/drivers/net/wireless/broadcom/b43/main.c @@ -3603,7 +3603,7 @@ static void b43_tx_work(struct work_struct *work) err =3D b43_dma_tx(dev, skb); if (err =3D=3D -ENOSPC) { wl->tx_queue_stopped[queue_num] =3D true; - ieee80211_stop_queue(wl->hw, queue_num); + b43_stop_queue(dev, queue_num); skb_queue_head(&wl->tx_queue[queue_num], skb); break; } @@ -3627,6 +3627,7 @@ static void b43_op_tx(struct ieee80211_hw *hw, struct sk_buff *skb) { struct b43_wl *wl =3D hw_to_b43_wl(hw); + u16 skb_queue_mapping; =20 if (unlikely(skb->len < 2 + 2 + 6)) { /* Too short, this can't be a valid frame. */ @@ -3635,12 +3636,12 @@ static void b43_op_tx(struct ieee80211_hw *hw, } B43_WARN_ON(skb_shinfo(skb)->nr_frags); =20 - skb_queue_tail(&wl->tx_queue[skb->queue_mapping], skb); - if (!wl->tx_queue_stopped[skb->queue_mapping]) { + skb_queue_mapping =3D skb_get_queue_mapping(skb); + skb_queue_tail(&wl->tx_queue[skb_queue_mapping], skb); + if (!wl->tx_queue_stopped[skb_queue_mapping]) ieee80211_queue_work(wl->hw, &wl->tx_work); - } else { - ieee80211_stop_queue(wl->hw, skb->queue_mapping); - } + else + b43_stop_queue(wl->current_dev, skb_queue_mapping); } =20 static void b43_qos_params_upload(struct b43_wldev *dev, --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3421C10A36; Sun, 24 Mar 2024 22:35:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319759; cv=none; b=MnMIj86/5rN02Kdj08A3loqNfbEckgllfL+xChY+FSDyWSmYQK8D3T3zqN01xbrBza/squuZ0Hm1D4ZWgEpFIKctASTd1cbedEgpbimapn5Hrpq+69fD6DZDqSxAtgK/bP6j81VAuN9C8RXGQGNTnyxDYL5MvvxzXMAjR1TVwtw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319759; c=relaxed/simple; bh=CsAMiHQAXIh3ppx29hoMWB2i85+/qOx9nZjiv2Urp3o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NLeUfbMKjoTlF/enRwFOi3LoeJZZPL1q6NlnOqRcD0dFpccFEXx0sO2lfJ3QEV/px0cS44rq+KMsbDKMx2/XXHyCcM8vO/NNFd5596olCm/HaVPtn1MclWl85ZaA1DBzSVX5HND7Q/AVTIV8bp/ZVeIXH98hsWUulWQnxXIvhCY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NSz5UHiO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NSz5UHiO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06E32C433C7; Sun, 24 Mar 2024 22:35:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319758; bh=CsAMiHQAXIh3ppx29hoMWB2i85+/qOx9nZjiv2Urp3o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NSz5UHiO2cgW0Q7tndVohfI2aRn1djKeMj3DTfjXhQ5CD2x0c2RXRm/n1mO2toPar 1mSC4JX9r6HJ8xjx/JQjebEeUDR9htilPhKsNMPxiwuvuKXlsbdvoWZLl843f595/p k3HRve5AselTROUi02KbD13pka1g7VDS0+SjuWXnzpUjx6FGy+O4k+YbqJuH8TtTzQ zwm++iPsbdRQFCIeWBzYerIU+2iM/SSR5sODnOveQpeCy/HvXsTZ7leC4oMnl4ylD7 CCh0xeeMiDeWkFp2kXXJaZYxFhmMUIrj9DSGzDFTPLfj7Yc0HYTngxDzHiVikD4w7R 0UjIdehj6f4eg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Rahul Rameshbabu , Julian Calaby , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 059/715] wifi: b43: Disable QoS for bcm4331 Date: Sun, 24 Mar 2024 18:23:58 -0400 Message-ID: <20240324223455.1342824-60-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Rahul Rameshbabu [ Upstream commit 09795bded2e725443fe4a4803cae2079cdaf7b26 ] bcm4331 seems to not function correctly with QoS support. This may be due to issues with currently available firmware or potentially a device specific issue. When queues that are not of the default "best effort" priority are selected, traffic appears to not transmit out of the hardware while no errors are returned. This behavior is present among all the other priority queues: video, voice, and background. While this can be worked around by setting a kernel parameter, the default behavior is problematic for most users and may be difficult to debug. This patch offers a working out-of-box experience for bcm4331 users. Log of the issue (using ssh low-priority traffic as an example): ssh -T -vvvv git@github.com OpenSSH_9.6p1, OpenSSL 3.0.12 24 Oct 2023 debug1: Reading configuration data /etc/ssh/ssh_config debug2: checking match for 'host * exec "/nix/store/q1c2flcykgr4wwg5a6h= 450hxbk4ch589-bash-5.2-p15/bin/bash -c '/nix/store/c015armnkhr6v18za0rypm7s= h1i8js8w-gnupg-2.4.1/bin/gpg-connect-agent --quiet updatestartuptty /bye >/= dev/null 2>&1'"' host github.com originally github.com debug3: /etc/ssh/ssh_config line 5: matched 'host "github.com"' debug1: Executing command: '/nix/store/q1c2flcykgr4wwg5a6h450hxbk4ch589= -bash-5.2-p15/bin/bash -c '/nix/store/c015armnkhr6v18za0rypm7sh1i8js8w-gnup= g-2.4.1/bin/gpg-connect-agent --quiet updatestartuptty /bye >/dev/null 2>&1= '' debug3: command returned status 0 debug3: /etc/ssh/ssh_config line 5: matched 'exec "/nix/store/q1c2flcyk= gr4wwg5a6h450hxbk4ch589-bash-5.2-p15/bin/bash -c '/nix/store/c015armnkhr6v1= 8za0r"' debug2: match found debug1: /etc/ssh/ssh_config line 9: Applying options for * debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/bina= ry-eater/.ssh/known_hosts' debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/bin= ary-eater/.ssh/known_hosts2' debug2: resolving "github.com" port 22 debug3: resolve_host: lookup github.com:22 debug3: channel_clear_timeouts: clearing debug3: ssh_connect_direct: entering debug1: Connecting to github.com [192.30.255.113] port 22. debug3: set_sock_tos: set socket 3 IP_TOS 0x48 Fixes: e6f5b934fba8 ("b43: Add QOS support") Signed-off-by: Rahul Rameshbabu Reviewed-by: Julian Calaby Signed-off-by: Kalle Valo Link: https://msgid.link/20231231050300.122806-5-sergeantsagara@protonmail.= com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/broadcom/b43/main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/b43/main.c b/drivers/net/wireles= s/broadcom/b43/main.c index 97d8bdeaa06cb..effb6c23f8257 100644 --- a/drivers/net/wireless/broadcom/b43/main.c +++ b/drivers/net/wireless/broadcom/b43/main.c @@ -2587,7 +2587,8 @@ static void b43_request_firmware(struct work_struct *= work) =20 start_ieee80211: wl->hw->queues =3D B43_QOS_QUEUE_NUM; - if (!modparam_qos || dev->fw.opensource) + if (!modparam_qos || dev->fw.opensource || + dev->dev->chip_id =3D=3D BCMA_CHIP_ID_BCM4331) wl->hw->queues =3D 1; =20 err =3D ieee80211_register_hw(wl->hw); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB0AB82860; Sun, 24 Mar 2024 22:35:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319759; cv=none; b=uHgMOfSwPDm+PcuXxQHNag4FZZdx8p/JxLfJcZEEm8J7Fjm4oODYsaGS77fzi6q2PM0neBYZsJSmS0UdNNc1Ipwvboz+sDVmZZT9Ja/5u4FuftHj02/aHMoolMf/ObRh5x/MmfUSzHm2aVfK/9guRtwT0Q+2ttHUWDZ3IqdlPCc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319759; c=relaxed/simple; bh=Qdef+ftIbJ1XbL9pjOrUZIcLWOBV/tvSiOqygjidF7A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ZUL5NiiFTAz2KQ/SuQoQxkdh3U5oyiY588Kb4Ejt8/8om9pXtj3NcLj8y1nBqjZldcPLwXFbPYzRIMPpwLvE3LNR72dYHTikspv+iCdisVSMYma9bafbaGuv/WU4XdGqSSTvTacpSe9eDLBPeECE7DT4IklglAWgqJKbZbekilE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LlazJP5S; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LlazJP5S" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02432C43390; Sun, 24 Mar 2024 22:35:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319759; bh=Qdef+ftIbJ1XbL9pjOrUZIcLWOBV/tvSiOqygjidF7A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LlazJP5SCND32n8236YReX+yUTDwTUETuCOxfY1N6KppWMo65lbTVhUuNPEOjYbSe QZh23neelBAJe6+Y0tlNcCs/xbPYekCt95mU855QLWYJskTx7J4TJ2WTdgrav1M5OI myVupbKByrDiY9UJ0FCa4WHl7Is7ssA5q68Iylvv3Iwwz9epCK0Jqkgy/hBi4A8CZs TbptapGh21O829LNicUrZXEaM6EatgK/5d/f2m8QHFvkGi4KfToQhjscoT0byHKeoL n2ms4zWXhd0tm65f/iDgY8QfZwDVgL78n7vWEkupVXlShjbSr9H6aT3LAzlKOfhnta 5w3aWQ0Y4vtBQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Alexis=20Lothor=C3=A9?= , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 060/715] wifi: wilc1000: fix declarations ordering Date: Sun, 24 Mar 2024 18:23:59 -0400 Message-ID: <20240324223455.1342824-61-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Alexis Lothor=C3=A9 [ Upstream commit 535733e90e5d8912ebeccebb05b354a2d06ff459 ] Reorder parameters declaration in wilc_parse_join_bss_param to enforce reverse christmas tree Signed-off-by: Alexis Lothor=C3=A9 Signed-off-by: Kalle Valo Link: https://msgid.link/20240105075733.36331-2-alexis.lothore@bootlin.com Stable-dep-of: 205c50306acf ("wifi: wilc1000: fix RCU usage in connect path= ") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/microchip/wilc1000/hif.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/microchip/wilc1000/hif.c b/drivers/net/wi= reless/microchip/wilc1000/hif.c index 839f142663e86..6f1218a510610 100644 --- a/drivers/net/wireless/microchip/wilc1000/hif.c +++ b/drivers/net/wireless/microchip/wilc1000/hif.c @@ -377,13 +377,13 @@ struct wilc_join_bss_param * wilc_parse_join_bss_param(struct cfg80211_bss *bss, struct cfg80211_crypto_settings *crypto) { - struct wilc_join_bss_param *param; - struct ieee80211_p2p_noa_attr noa_attr; - u8 rates_len =3D 0; + const struct cfg80211_bss_ies *ies =3D rcu_dereference(bss->ies); const u8 *tim_elm, *ssid_elm, *rates_ie, *supp_rates_ie; const u8 *ht_ie, *wpa_ie, *wmm_ie, *rsn_ie; + struct ieee80211_p2p_noa_attr noa_attr; + struct wilc_join_bss_param *param; + u8 rates_len =3D 0; int ret; - const struct cfg80211_bss_ies *ies =3D rcu_dereference(bss->ies); =20 param =3D kzalloc(sizeof(*param), GFP_KERNEL); if (!param) --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA51E82C7D; Sun, 24 Mar 2024 22:36:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319760; cv=none; b=OX+yhl/d1ZbiG1WKf7mEuxzxO5aNnZi+YSQS5KoOHZG3d4sLpPG5irqnZTxmdg5udtvIBa5wRZRge4lI90fZMJb9rdOCyfWfwj0jF0Lx+ZCZ2C+hJeVC1Gng4uGzT6zS5B1YgZVxUipb53lelZlrYG8WtwyupL55K/wOuDhz5B4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319760; c=relaxed/simple; bh=aYRWsu3jtHPlmDLMiK0tfe/w6tVZsHfRbf97JSVmNRk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KTrxehEJIUCRhtI6ifkRchXUXRASdArgzdUvRa95nBrFKcO0SNQVYjA7c6wW1rck1w4II9pzeXr9QO035HmiQg1WzqcE7xalsUgpQGKs3Wvq0VDjUOpzUuW+RdDqoudhCm1q5zq85SzUGVTGD8j4EG3TqTMCgxX85TPUW8grZM4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RCLuMaOu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RCLuMaOu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DEA38C43394; Sun, 24 Mar 2024 22:35:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319760; bh=aYRWsu3jtHPlmDLMiK0tfe/w6tVZsHfRbf97JSVmNRk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RCLuMaOuN++gxzL9ZFeuHTeslrNk8tFK0BCd9mAg8IJZFJetV/xVCo9jRRh8KnyIo Gblr1pP4f6PSKe9uepFGlWqY7f2auLBl4udVYi8UI0faT23KrR9+c4EqdHA1csNnC1 WHv4HTQ2UJlsh+GVgt2teofft8t3kzQ1svVvi1QbZV6bq2OvlHuGWuHteOsEENcf9w L3F7wPqpHKojQi6rC2FZ5WYGGuc2dZGf5qmbWzUR5ZULuFZZymoOmhmwDzyEYB9nga ZJEHXywsANUcdquZRzAKSMbKx+CTWdcDCsIbb8rWEt82UChF9myokctuwUm75cbHm0 cW4QxULPXldLQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Alexis=20Lothor=C3=A9?= , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 061/715] wifi: wilc1000: fix RCU usage in connect path Date: Sun, 24 Mar 2024 18:24:00 -0400 Message-ID: <20240324223455.1342824-62-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Alexis Lothor=C3=A9 [ Upstream commit 205c50306acf58a335eb19fa84e40140f4fe814f ] With lockdep enabled, calls to the connect function from cfg802.11 layer lead to the following warning: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D WARNING: suspicious RCU usage 6.7.0-rc1-wt+ #333 Not tainted Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya ----------------------------- drivers/net/wireless/microchip/wilc1000/hif.c:386 suspicious rcu_dereference_check() usage! [...] stack backtrace: CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x48 dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4 wilc_parse_join_bss_param from connect+0x2c4/0x648 connect from cfg80211_connect+0x30c/0xb74 cfg80211_connect from nl80211_connect+0x860/0xa94 nl80211_connect from genl_rcv_msg+0x3fc/0x59c genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8 netlink_rcv_skb from genl_rcv+0x2c/0x3c genl_rcv from netlink_unicast+0x3b0/0x550 netlink_unicast from netlink_sendmsg+0x368/0x688 netlink_sendmsg from ____sys_sendmsg+0x190/0x430 ____sys_sendmsg from ___sys_sendmsg+0x110/0x158 ___sys_sendmsg from sys_sendmsg+0xe8/0x150 sys_sendmsg from ret_fast_syscall+0x0/0x1c This warning is emitted because in the connect path, when trying to parse target BSS parameters, we dereference a RCU pointer whithout being in RCU critical section. Fix RCU dereference usage by moving it to a RCU read critical section. To avoid wrapping the whole wilc_parse_join_bss_param under the critical section, just use the critical section to copy ies data Fixes: c460495ee072 ("staging: wilc1000: fix incorrent type in initializer") Signed-off-by: Alexis Lothor=C3=A9 Signed-off-by: Kalle Valo Link: https://msgid.link/20240105075733.36331-3-alexis.lothore@bootlin.com Signed-off-by: Sasha Levin --- drivers/net/wireless/microchip/wilc1000/hif.c | 36 ++++++++++++------- 1 file changed, 24 insertions(+), 12 deletions(-) diff --git a/drivers/net/wireless/microchip/wilc1000/hif.c b/drivers/net/wi= reless/microchip/wilc1000/hif.c index 6f1218a510610..d2b8c26308198 100644 --- a/drivers/net/wireless/microchip/wilc1000/hif.c +++ b/drivers/net/wireless/microchip/wilc1000/hif.c @@ -377,38 +377,49 @@ struct wilc_join_bss_param * wilc_parse_join_bss_param(struct cfg80211_bss *bss, struct cfg80211_crypto_settings *crypto) { - const struct cfg80211_bss_ies *ies =3D rcu_dereference(bss->ies); - const u8 *tim_elm, *ssid_elm, *rates_ie, *supp_rates_ie; + const u8 *ies_data, *tim_elm, *ssid_elm, *rates_ie, *supp_rates_ie; const u8 *ht_ie, *wpa_ie, *wmm_ie, *rsn_ie; struct ieee80211_p2p_noa_attr noa_attr; + const struct cfg80211_bss_ies *ies; struct wilc_join_bss_param *param; - u8 rates_len =3D 0; + u8 rates_len =3D 0, ies_len; int ret; =20 param =3D kzalloc(sizeof(*param), GFP_KERNEL); if (!param) return NULL; =20 + rcu_read_lock(); + ies =3D rcu_dereference(bss->ies); + ies_data =3D kmemdup(ies->data, ies->len, GFP_ATOMIC); + if (!ies_data) { + rcu_read_unlock(); + kfree(param); + return NULL; + } + ies_len =3D ies->len; + rcu_read_unlock(); + param->beacon_period =3D cpu_to_le16(bss->beacon_interval); param->cap_info =3D cpu_to_le16(bss->capability); param->bss_type =3D WILC_FW_BSS_TYPE_INFRA; param->ch =3D ieee80211_frequency_to_channel(bss->channel->center_freq); ether_addr_copy(param->bssid, bss->bssid); =20 - ssid_elm =3D cfg80211_find_ie(WLAN_EID_SSID, ies->data, ies->len); + ssid_elm =3D cfg80211_find_ie(WLAN_EID_SSID, ies_data, ies_len); if (ssid_elm) { if (ssid_elm[1] <=3D IEEE80211_MAX_SSID_LEN) memcpy(param->ssid, ssid_elm + 2, ssid_elm[1]); } =20 - tim_elm =3D cfg80211_find_ie(WLAN_EID_TIM, ies->data, ies->len); + tim_elm =3D cfg80211_find_ie(WLAN_EID_TIM, ies_data, ies_len); if (tim_elm && tim_elm[1] >=3D 2) param->dtim_period =3D tim_elm[3]; =20 memset(param->p_suites, 0xFF, 3); memset(param->akm_suites, 0xFF, 3); =20 - rates_ie =3D cfg80211_find_ie(WLAN_EID_SUPP_RATES, ies->data, ies->len); + rates_ie =3D cfg80211_find_ie(WLAN_EID_SUPP_RATES, ies_data, ies_len); if (rates_ie) { rates_len =3D rates_ie[1]; if (rates_len > WILC_MAX_RATES_SUPPORTED) @@ -419,7 +430,7 @@ wilc_parse_join_bss_param(struct cfg80211_bss *bss, =20 if (rates_len < WILC_MAX_RATES_SUPPORTED) { supp_rates_ie =3D cfg80211_find_ie(WLAN_EID_EXT_SUPP_RATES, - ies->data, ies->len); + ies_data, ies_len); if (supp_rates_ie) { u8 ext_rates =3D supp_rates_ie[1]; =20 @@ -434,11 +445,11 @@ wilc_parse_join_bss_param(struct cfg80211_bss *bss, } } =20 - ht_ie =3D cfg80211_find_ie(WLAN_EID_HT_CAPABILITY, ies->data, ies->len); + ht_ie =3D cfg80211_find_ie(WLAN_EID_HT_CAPABILITY, ies_data, ies_len); if (ht_ie) param->ht_capable =3D true; =20 - ret =3D cfg80211_get_p2p_attr(ies->data, ies->len, + ret =3D cfg80211_get_p2p_attr(ies_data, ies_len, IEEE80211_P2P_ATTR_ABSENCE_NOTICE, (u8 *)&noa_attr, sizeof(noa_attr)); if (ret > 0) { @@ -462,7 +473,7 @@ wilc_parse_join_bss_param(struct cfg80211_bss *bss, } wmm_ie =3D cfg80211_find_vendor_ie(WLAN_OUI_MICROSOFT, WLAN_OUI_TYPE_MICROSOFT_WMM, - ies->data, ies->len); + ies_data, ies_len); if (wmm_ie) { struct ieee80211_wmm_param_ie *ie; =20 @@ -477,13 +488,13 @@ wilc_parse_join_bss_param(struct cfg80211_bss *bss, =20 wpa_ie =3D cfg80211_find_vendor_ie(WLAN_OUI_MICROSOFT, WLAN_OUI_TYPE_MICROSOFT_WPA, - ies->data, ies->len); + ies_data, ies_len); if (wpa_ie) { param->mode_802_11i =3D 1; param->rsn_found =3D true; } =20 - rsn_ie =3D cfg80211_find_ie(WLAN_EID_RSN, ies->data, ies->len); + rsn_ie =3D cfg80211_find_ie(WLAN_EID_RSN, ies_data, ies_len); if (rsn_ie) { int rsn_ie_len =3D sizeof(struct element) + rsn_ie[1]; int offset =3D 8; @@ -517,6 +528,7 @@ wilc_parse_join_bss_param(struct cfg80211_bss *bss, param->akm_suites[i] =3D crypto->akm_suites[i] & 0xFF; } =20 + kfree(ies_data); return (void *)param; } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05CAB82D9A; Sun, 24 Mar 2024 22:36:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319762; cv=none; b=G0SUOsFZO9uNsOIfPH+Qxu/UHaoKmwNGoKVlj0GPDZufHdDnWSkEmY6FCTgYyD+GXe1BVwdS4FxpCFsGry9hZTqlYYY+ERj58SSOiRGRA+I1MefemOUJv7FvADDrrZ67LgMGWTAYyNyZSITNvk1ZPmVmGajYbM7WBOKE7WFxJzY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319762; c=relaxed/simple; bh=yPEpggvVYgRTK+qo2VSDS2wmWg/PsKskHvQIgsYNqI4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FkKZuDBRoMjz+1Vi8q1neSIz8THwNk/EK9MRQmJ5xqP15Twfyg6OcunUj60s2Z5nEUqLY+LSb3LyZ4ZcsY+uCM0Gx6Wkn2Uct5J69wlpPz/fnNT48tCPAfnkUEpYRKR91PP1snp+CWNM8Hn0ghBCqfc6S1+HDW+zMuzi2W1LMkk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VinzE83B; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VinzE83B" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C6D7EC433C7; Sun, 24 Mar 2024 22:36:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319761; bh=yPEpggvVYgRTK+qo2VSDS2wmWg/PsKskHvQIgsYNqI4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VinzE83Bpg3AaZKT9SAJFbXxVcEZGb06Aq3iVV9EEgqKEuAChRIFDfJd7aDebOJoo Dfxoj7e7FJkFSc+qBUxLoHsUItn21WuhziJroUyJZMtZHgolfPuiRdnuSoyFDFTP1j Oz/uKUwQYDjp2vHUDmC26bNm1L9qIC6X7gq5glDu0Gn+ux6cqV2i+srth+fbaYsL4N a9yzLQbj3AHAsLsOg/zlhosffmGdOoAUMpcqMdTHl3a4cFy+gWhOsdGE4Y4aWIwgus KyuxsLr6m6S8a++ltYQ4HENxV76LgXXBPJBHttJEDpTQJbNcOzLclYEDY7NwEFKCrK nRxVHirrhn37A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Wen Gong , Baochen Qiang , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 062/715] wifi: ath11k: add support to select 6 GHz regulatory type Date: Sun, 24 Mar 2024 18:24:01 -0400 Message-ID: <20240324223455.1342824-63-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Wen Gong [ Upstream commit e3d373ec4f02bf41379d91707e3e3f2a46464cd7 ] There are 3 types of regulatory rules for AP mode and 6 type for station mode. Add wmi_vdev_type and ieee80211_ap_reg_power to select the exact reg rules. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_L= ITE-3.6510.23 Signed-off-by: Wen Gong Signed-off-by: Baochen Qiang Signed-off-by: Kalle Valo Link: https://msgid.link/20231218085844.2658-2-quic_bqiang@quicinc.com Stable-dep-of: cf2df0080bd5 ("wifi: ath11k: fix a possible dead lock caused= by ab->base_lock") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/ath/ath11k/reg.c | 70 +++++++++++++++++++++------ drivers/net/wireless/ath/ath11k/reg.h | 6 ++- drivers/net/wireless/ath/ath11k/wmi.c | 3 +- 3 files changed, 62 insertions(+), 17 deletions(-) diff --git a/drivers/net/wireless/ath/ath11k/reg.c b/drivers/net/wireless/a= th/ath11k/reg.c index b4fd4d2107c71..78b99ab10c634 100644 --- a/drivers/net/wireless/ath/ath11k/reg.c +++ b/drivers/net/wireless/ath/ath11k/reg.c @@ -618,25 +618,68 @@ ath11k_reg_update_weather_radar_band(struct ath11k_ba= se *ab, *rule_idx =3D i; } =20 +enum wmi_reg_6ghz_ap_type +ath11k_reg_ap_pwr_convert(enum ieee80211_ap_reg_power power_type) +{ + switch (power_type) { + case IEEE80211_REG_LPI_AP: + return WMI_REG_INDOOR_AP; + case IEEE80211_REG_SP_AP: + return WMI_REG_STANDARD_POWER_AP; + case IEEE80211_REG_VLP_AP: + return WMI_REG_VERY_LOW_POWER_AP; + default: + return WMI_REG_MAX_AP_TYPE; + } +} + struct ieee80211_regdomain * ath11k_reg_build_regd(struct ath11k_base *ab, - struct cur_regulatory_info *reg_info, bool intersect) + struct cur_regulatory_info *reg_info, bool intersect, + enum wmi_vdev_type vdev_type, + enum ieee80211_ap_reg_power power_type) { struct ieee80211_regdomain *tmp_regd, *default_regd, *new_regd =3D NULL; - struct cur_reg_rule *reg_rule; + struct cur_reg_rule *reg_rule, *reg_rule_6ghz; u8 i =3D 0, j =3D 0, k =3D 0; u8 num_rules; u16 max_bw; - u32 flags; + u32 flags, reg_6ghz_number, max_bw_6ghz; char alpha2[3]; =20 num_rules =3D reg_info->num_5ghz_reg_rules + reg_info->num_2ghz_reg_rules; =20 - /* FIXME: Currently taking reg rules for 6 GHz only from Indoor AP mode l= ist. - * This can be updated after complete 6 GHz regulatory support is added. - */ - if (reg_info->is_ext_reg_event) - num_rules +=3D reg_info->num_6ghz_rules_ap[WMI_REG_INDOOR_AP]; + if (reg_info->is_ext_reg_event) { + if (vdev_type =3D=3D WMI_VDEV_TYPE_STA) { + enum wmi_reg_6ghz_ap_type ap_type; + + ap_type =3D ath11k_reg_ap_pwr_convert(power_type); + + if (ap_type =3D=3D WMI_REG_MAX_AP_TYPE) + ap_type =3D WMI_REG_INDOOR_AP; + + reg_6ghz_number =3D reg_info->num_6ghz_rules_client + [ap_type][WMI_REG_DEFAULT_CLIENT]; + + if (reg_6ghz_number =3D=3D 0) { + ap_type =3D WMI_REG_INDOOR_AP; + reg_6ghz_number =3D reg_info->num_6ghz_rules_client + [ap_type][WMI_REG_DEFAULT_CLIENT]; + } + + reg_rule_6ghz =3D reg_info->reg_rules_6ghz_client_ptr + [ap_type][WMI_REG_DEFAULT_CLIENT]; + max_bw_6ghz =3D reg_info->max_bw_6ghz_client + [ap_type][WMI_REG_DEFAULT_CLIENT]; + } else { + reg_6ghz_number =3D reg_info->num_6ghz_rules_ap[WMI_REG_INDOOR_AP]; + reg_rule_6ghz =3D + reg_info->reg_rules_6ghz_ap_ptr[WMI_REG_INDOOR_AP]; + max_bw_6ghz =3D reg_info->max_bw_6ghz_ap[WMI_REG_INDOOR_AP]; + } + + num_rules +=3D reg_6ghz_number; + } =20 if (!num_rules) goto ret; @@ -683,13 +726,10 @@ ath11k_reg_build_regd(struct ath11k_base *ab, * per other BW rule flags we pass from here */ flags =3D NL80211_RRF_AUTO_BW; - } else if (reg_info->is_ext_reg_event && - reg_info->num_6ghz_rules_ap[WMI_REG_INDOOR_AP] && - (k < reg_info->num_6ghz_rules_ap[WMI_REG_INDOOR_AP])) { - reg_rule =3D reg_info->reg_rules_6ghz_ap_ptr[WMI_REG_INDOOR_AP] + - k++; - max_bw =3D min_t(u16, reg_rule->max_bw, - reg_info->max_bw_6ghz_ap[WMI_REG_INDOOR_AP]); + } else if (reg_info->is_ext_reg_event && reg_6ghz_number && + k < reg_6ghz_number) { + reg_rule =3D reg_rule_6ghz + k++; + max_bw =3D min_t(u16, reg_rule->max_bw, max_bw_6ghz); flags =3D NL80211_RRF_AUTO_BW; } else { break; diff --git a/drivers/net/wireless/ath/ath11k/reg.h b/drivers/net/wireless/a= th/ath11k/reg.h index f28902f85e419..989b27b16bea0 100644 --- a/drivers/net/wireless/ath/ath11k/reg.h +++ b/drivers/net/wireless/ath/ath11k/reg.h @@ -34,7 +34,11 @@ void ath11k_reg_free(struct ath11k_base *ab); void ath11k_regd_update_work(struct work_struct *work); struct ieee80211_regdomain * ath11k_reg_build_regd(struct ath11k_base *ab, - struct cur_regulatory_info *reg_info, bool intersect); + struct cur_regulatory_info *reg_info, bool intersect, + enum wmi_vdev_type vdev_type, + enum ieee80211_ap_reg_power power_type); int ath11k_regd_update(struct ath11k *ar); int ath11k_reg_update_chan_list(struct ath11k *ar, bool wait); +enum wmi_reg_6ghz_ap_type +ath11k_reg_ap_pwr_convert(enum ieee80211_ap_reg_power power_type); #endif diff --git a/drivers/net/wireless/ath/ath11k/wmi.c b/drivers/net/wireless/a= th/ath11k/wmi.c index 8a65fa04b48d9..75c79c99faa9f 100644 --- a/drivers/net/wireless/ath/ath11k/wmi.c +++ b/drivers/net/wireless/ath/ath11k/wmi.c @@ -7151,7 +7151,8 @@ static int ath11k_reg_chan_list_event(struct ath11k_b= ase *ab, !ath11k_reg_is_world_alpha((char *)reg_info->alpha2)) intersect =3D true; =20 - regd =3D ath11k_reg_build_regd(ab, reg_info, intersect); + regd =3D ath11k_reg_build_regd(ab, reg_info, intersect, + WMI_VDEV_TYPE_AP, IEEE80211_REG_LPI_AP); if (!regd) { ath11k_warn(ab, "failed to build regd from reg_info\n"); goto fallback; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B3B2839F7; Sun, 24 Mar 2024 22:36:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319763; cv=none; b=twC7r0l5xnnTD7AqbgBR/r1BHRphJzKjrNpjhaNXsm7bEnfOl419BTgkyyhASONaZd/cwnTitZcb6tABKrCeLHPGpdOFBf58EfLDUsCnZtE3JciV+QNM9CrIxnVNk6dKMs6+xpIYo1b4kYXm4fhwX3Zt7iPENw5iJcLFGElMwqo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319763; c=relaxed/simple; bh=ij/exhe6MxlvYzSaAUW5lT8UHw3ffcYZANUvmXuzxr4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YDUyQH5qocBvcggd3MiFAzSGUe8rcyz2p7fk+eW0xz3eCxDj2RnAmW27oqhZTaRfTuRtaf3QFNQfLIiCvXkT/A1Vq5HRQwp/DgxQnMuhXu3n0mqLivnaPwwLRxxXoPzBOWIXVsAD8YS6OSLrxJk4cVI+X/fhlGAJll2EN9T8Ax8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HT6oKMJE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HT6oKMJE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C78EDC43390; Sun, 24 Mar 2024 22:36:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319762; bh=ij/exhe6MxlvYzSaAUW5lT8UHw3ffcYZANUvmXuzxr4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HT6oKMJEZecihl8jkWlr/mSx2WKyO+SYFVYNJbzGZKP30bGeI3brhTxONQutrScvJ GjPtCn95/tA0GibveLaWO2UI+cDE1CACcA0Ow+UFeADFUrTfj9ZrvKJq83Mf+92U0v eNoYRgEhmFEm+FRu1RrjHa+uNOqne8yJUB2W8rzQgVGKUpOC1W+j6T5AtFptA2cgpe sP9U3+4KXIwoTpRs5tWNiculrBs723nORdjtsJZfEdKi3gguNg0Kx43WM4Ci9VGusY ta/3E0LOB7B39U2GT/ThFy9GvagULT9rdh7jSC/Yu0fZD/GtYqpXlyyGd7XBDprsnp zRSUbC6SiNHBg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Wen Gong , Jeff Johnson , Baochen Qiang , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 063/715] wifi: ath11k: store cur_regulatory_info for each radio Date: Sun, 24 Mar 2024 18:24:02 -0400 Message-ID: <20240324223455.1342824-64-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Wen Gong [ Upstream commit 7004bdceef605e5c1c5ab4aaf282002ad7523ddd ] The regulatory info of WMI_REG_CHAN_LIST_CC_EXT_EVENTID is not saved in ath11k now, the info should be saved in ath11k. Save the info for each radio and support switch regulatory rules dynamically. As mac.c will also call ath11k_reg_handle_chan_list() in next patches move = the function to reg.c. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_L= ITE-3.6510.23 Signed-off-by: Wen Gong Acked-by: Jeff Johnson Signed-off-by: Baochen Qiang Signed-off-by: Kalle Valo Link: https://msgid.link/20231218085844.2658-3-quic_bqiang@quicinc.com Stable-dep-of: cf2df0080bd5 ("wifi: ath11k: fix a possible dead lock caused= by ab->base_lock") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/ath/ath11k/core.h | 1 + drivers/net/wireless/ath/ath11k/reg.c | 179 +++++++++++++++++++++++++ drivers/net/wireless/ath/ath11k/reg.h | 5 + drivers/net/wireless/ath/ath11k/wmi.c | 148 +++----------------- drivers/net/wireless/ath/ath11k/wmi.h | 1 + 5 files changed, 207 insertions(+), 127 deletions(-) diff --git a/drivers/net/wireless/ath/ath11k/core.h b/drivers/net/wireless/= ath/ath11k/core.h index 02e160d831bed..cd829ec70d76b 100644 --- a/drivers/net/wireless/ath/ath11k/core.h +++ b/drivers/net/wireless/ath/ath11k/core.h @@ -918,6 +918,7 @@ struct ath11k_base { * This may or may not be used during the runtime */ struct ieee80211_regdomain *new_regd[MAX_RADIOS]; + struct cur_regulatory_info *reg_info_store; =20 /* Current DFS Regulatory */ enum ath11k_dfs_region dfs_region; diff --git a/drivers/net/wireless/ath/ath11k/reg.c b/drivers/net/wireless/a= th/ath11k/reg.c index 78b99ab10c634..adcd9063a59c3 100644 --- a/drivers/net/wireless/ath/ath11k/reg.c +++ b/drivers/net/wireless/ath/ath11k/reg.c @@ -798,6 +798,159 @@ ath11k_reg_build_regd(struct ath11k_base *ab, return new_regd; } =20 +static bool ath11k_reg_is_world_alpha(char *alpha) +{ + if (alpha[0] =3D=3D '0' && alpha[1] =3D=3D '0') + return true; + + if (alpha[0] =3D=3D 'n' && alpha[1] =3D=3D 'a') + return true; + + return false; +} + +static enum wmi_vdev_type ath11k_reg_get_ar_vdev_type(struct ath11k *ar) +{ + struct ath11k_vif *arvif; + + /* Currently each struct ath11k maps to one struct ieee80211_hw/wiphy + * and one struct ieee80211_regdomain, so it could only store one group + * reg rules. It means multi-interface concurrency in the same ath11k is + * not support for the regdomain. So get the vdev type of the first entry + * now. After concurrency support for the regdomain, this should change. + */ + arvif =3D list_first_entry_or_null(&ar->arvifs, struct ath11k_vif, list); + if (arvif) + return arvif->vdev_type; + + return WMI_VDEV_TYPE_UNSPEC; +} + +int ath11k_reg_handle_chan_list(struct ath11k_base *ab, + struct cur_regulatory_info *reg_info, + enum ieee80211_ap_reg_power power_type) +{ + struct ieee80211_regdomain *regd; + bool intersect =3D false; + int pdev_idx; + struct ath11k *ar; + enum wmi_vdev_type vdev_type; + + ath11k_dbg(ab, ATH11K_DBG_WMI, "event reg handle chan list"); + + if (reg_info->status_code !=3D REG_SET_CC_STATUS_PASS) { + /* In case of failure to set the requested ctry, + * fw retains the current regd. We print a failure info + * and return from here. + */ + ath11k_warn(ab, "Failed to set the requested Country regulatory setting\= n"); + return -EINVAL; + } + + pdev_idx =3D reg_info->phy_id; + + /* Avoid default reg rule updates sent during FW recovery if + * it is already available + */ + spin_lock(&ab->base_lock); + if (test_bit(ATH11K_FLAG_RECOVERY, &ab->dev_flags) && + ab->default_regd[pdev_idx]) { + spin_unlock(&ab->base_lock); + goto retfail; + } + spin_unlock(&ab->base_lock); + + if (pdev_idx >=3D ab->num_radios) { + /* Process the event for phy0 only if single_pdev_only + * is true. If pdev_idx is valid but not 0, discard the + * event. Otherwise, it goes to fallback. In either case + * ath11k_reg_reset_info() needs to be called to avoid + * memory leak issue. + */ + ath11k_reg_reset_info(reg_info); + + if (ab->hw_params.single_pdev_only && + pdev_idx < ab->hw_params.num_rxmda_per_pdev) + return 0; + goto fallback; + } + + /* Avoid multiple overwrites to default regd, during core + * stop-start after mac registration. + */ + if (ab->default_regd[pdev_idx] && !ab->new_regd[pdev_idx] && + !memcmp((char *)ab->default_regd[pdev_idx]->alpha2, + (char *)reg_info->alpha2, 2)) + goto retfail; + + /* Intersect new rules with default regd if a new country setting was + * requested, i.e a default regd was already set during initialization + * and the regd coming from this event has a valid country info. + */ + if (ab->default_regd[pdev_idx] && + !ath11k_reg_is_world_alpha((char *) + ab->default_regd[pdev_idx]->alpha2) && + !ath11k_reg_is_world_alpha((char *)reg_info->alpha2)) + intersect =3D true; + + ar =3D ab->pdevs[pdev_idx].ar; + vdev_type =3D ath11k_reg_get_ar_vdev_type(ar); + + ath11k_dbg(ab, ATH11K_DBG_WMI, + "wmi handle chan list power type %d vdev type %d intersect %d\n", + power_type, vdev_type, intersect); + + regd =3D ath11k_reg_build_regd(ab, reg_info, intersect, vdev_type, power_= type); + if (!regd) { + ath11k_warn(ab, "failed to build regd from reg_info\n"); + goto fallback; + } + + if (power_type =3D=3D IEEE80211_REG_UNSET_AP) { + ath11k_reg_reset_info(&ab->reg_info_store[pdev_idx]); + ab->reg_info_store[pdev_idx] =3D *reg_info; + } + + spin_lock(&ab->base_lock); + if (ab->default_regd[pdev_idx]) { + /* The initial rules from FW after WMI Init is to build + * the default regd. From then on, any rules updated for + * the pdev could be due to user reg changes. + * Free previously built regd before assigning the newly + * generated regd to ar. NULL pointer handling will be + * taken care by kfree itself. + */ + ar =3D ab->pdevs[pdev_idx].ar; + kfree(ab->new_regd[pdev_idx]); + ab->new_regd[pdev_idx] =3D regd; + queue_work(ab->workqueue, &ar->regd_update_work); + } else { + /* This regd would be applied during mac registration and is + * held constant throughout for regd intersection purpose + */ + ab->default_regd[pdev_idx] =3D regd; + } + ab->dfs_region =3D reg_info->dfs_region; + spin_unlock(&ab->base_lock); + + return 0; + +fallback: + /* Fallback to older reg (by sending previous country setting + * again if fw has succeeded and we failed to process here. + * The Regdomain should be uniform across driver and fw. Since the + * FW has processed the command and sent a success status, we expect + * this function to succeed as well. If it doesn't, CTRY needs to be + * reverted at the fw and the old SCAN_CHAN_LIST cmd needs to be sent. + */ + /* TODO: This is rare, but still should also be handled */ + WARN_ON(1); + +retfail: + + return -EINVAL; +} + void ath11k_regd_update_work(struct work_struct *work) { struct ath11k *ar =3D container_of(work, struct ath11k, @@ -821,10 +974,36 @@ void ath11k_reg_init(struct ath11k *ar) ar->hw->wiphy->reg_notifier =3D ath11k_reg_notifier; } =20 +void ath11k_reg_reset_info(struct cur_regulatory_info *reg_info) +{ + int i, j; + + if (!reg_info) + return; + + kfree(reg_info->reg_rules_2ghz_ptr); + kfree(reg_info->reg_rules_5ghz_ptr); + + for (i =3D 0; i < WMI_REG_CURRENT_MAX_AP_TYPE; i++) { + kfree(reg_info->reg_rules_6ghz_ap_ptr[i]); + + for (j =3D 0; j < WMI_REG_MAX_CLIENT_TYPE; j++) + kfree(reg_info->reg_rules_6ghz_client_ptr[i][j]); + } + + memset(reg_info, 0, sizeof(*reg_info)); +} + void ath11k_reg_free(struct ath11k_base *ab) { int i; =20 + for (i =3D 0; i < ab->num_radios; i++) + ath11k_reg_reset_info(&ab->reg_info_store[i]); + + kfree(ab->reg_info_store); + ab->reg_info_store =3D NULL; + for (i =3D 0; i < ab->hw_params.max_radios; i++) { kfree(ab->default_regd[i]); kfree(ab->new_regd[i]); diff --git a/drivers/net/wireless/ath/ath11k/reg.h b/drivers/net/wireless/a= th/ath11k/reg.h index 989b27b16bea0..64edb794260ab 100644 --- a/drivers/net/wireless/ath/ath11k/reg.h +++ b/drivers/net/wireless/ath/ath11k/reg.h @@ -30,6 +30,7 @@ enum ath11k_dfs_region { =20 /* ATH11K Regulatory API's */ void ath11k_reg_init(struct ath11k *ar); +void ath11k_reg_reset_info(struct cur_regulatory_info *reg_info); void ath11k_reg_free(struct ath11k_base *ab); void ath11k_regd_update_work(struct work_struct *work); struct ieee80211_regdomain * @@ -41,4 +42,8 @@ int ath11k_regd_update(struct ath11k *ar); int ath11k_reg_update_chan_list(struct ath11k *ar, bool wait); enum wmi_reg_6ghz_ap_type ath11k_reg_ap_pwr_convert(enum ieee80211_ap_reg_power power_type); +int ath11k_reg_handle_chan_list(struct ath11k_base *ab, + struct cur_regulatory_info *reg_info, + enum ieee80211_ap_reg_power power_type); + #endif diff --git a/drivers/net/wireless/ath/ath11k/wmi.c b/drivers/net/wireless/a= th/ath11k/wmi.c index 75c79c99faa9f..442afda7ec885 100644 --- a/drivers/net/wireless/ath/ath11k/wmi.c +++ b/drivers/net/wireless/ath/ath11k/wmi.c @@ -4749,6 +4749,14 @@ static int ath11k_wmi_tlv_ext_soc_hal_reg_caps_parse= (struct ath11k_base *soc, soc->pdevs[0].pdev_id =3D 0; } =20 + if (!soc->reg_info_store) { + soc->reg_info_store =3D kcalloc(soc->num_radios, + sizeof(*soc->reg_info_store), + GFP_ATOMIC); + if (!soc->reg_info_store) + return -ENOMEM; + } + return 0; } =20 @@ -7060,32 +7068,15 @@ static void ath11k_wmi_htc_tx_complete(struct ath11= k_base *ab, wake_up(&wmi->tx_ce_desc_wq); } =20 -static bool ath11k_reg_is_world_alpha(char *alpha) -{ - if (alpha[0] =3D=3D '0' && alpha[1] =3D=3D '0') - return true; - - if (alpha[0] =3D=3D 'n' && alpha[1] =3D=3D 'a') - return true; - - return false; -} - -static int ath11k_reg_chan_list_event(struct ath11k_base *ab, - struct sk_buff *skb, +static int ath11k_reg_chan_list_event(struct ath11k_base *ab, struct sk_bu= ff *skb, enum wmi_reg_chan_list_cmd_type id) { - struct cur_regulatory_info *reg_info =3D NULL; - struct ieee80211_regdomain *regd =3D NULL; - bool intersect =3D false; - int ret =3D 0, pdev_idx, i, j; - struct ath11k *ar; + struct cur_regulatory_info *reg_info; + int ret; =20 reg_info =3D kzalloc(sizeof(*reg_info), GFP_ATOMIC); - if (!reg_info) { - ret =3D -ENOMEM; - goto fallback; - } + if (!reg_info) + return -ENOMEM; =20 if (id =3D=3D WMI_REG_CHAN_LIST_CC_ID) ret =3D ath11k_pull_reg_chan_list_update_ev(ab, skb, reg_info); @@ -7093,119 +7084,22 @@ static int ath11k_reg_chan_list_event(struct ath11= k_base *ab, ret =3D ath11k_pull_reg_chan_list_ext_update_ev(ab, skb, reg_info); =20 if (ret) { - ath11k_warn(ab, "failed to extract regulatory info from received event\n= "); - goto fallback; - } - - ath11k_dbg(ab, ATH11K_DBG_WMI, "event reg chan list id %d", id); - - if (reg_info->status_code !=3D REG_SET_CC_STATUS_PASS) { - /* In case of failure to set the requested ctry, - * fw retains the current regd. We print a failure info - * and return from here. - */ - ath11k_warn(ab, "Failed to set the requested Country regulatory setting\= n"); - goto mem_free; - } - - pdev_idx =3D reg_info->phy_id; - - /* Avoid default reg rule updates sent during FW recovery if - * it is already available - */ - spin_lock(&ab->base_lock); - if (test_bit(ATH11K_FLAG_RECOVERY, &ab->dev_flags) && - ab->default_regd[pdev_idx]) { - spin_unlock(&ab->base_lock); + ath11k_warn(ab, "failed to extract regulatory info\n"); goto mem_free; } - spin_unlock(&ab->base_lock); =20 - if (pdev_idx >=3D ab->num_radios) { - /* Process the event for phy0 only if single_pdev_only - * is true. If pdev_idx is valid but not 0, discard the - * event. Otherwise, it goes to fallback. - */ - if (ab->hw_params.single_pdev_only && - pdev_idx < ab->hw_params.num_rxmda_per_pdev) - goto mem_free; - else - goto fallback; - } - - /* Avoid multiple overwrites to default regd, during core - * stop-start after mac registration. - */ - if (ab->default_regd[pdev_idx] && !ab->new_regd[pdev_idx] && - !memcmp((char *)ab->default_regd[pdev_idx]->alpha2, - (char *)reg_info->alpha2, 2)) + ret =3D ath11k_reg_handle_chan_list(ab, reg_info, IEEE80211_REG_UNSET_AP); + if (ret) { + ath11k_warn(ab, "failed to process regulatory info %d\n", ret); goto mem_free; - - /* Intersect new rules with default regd if a new country setting was - * requested, i.e a default regd was already set during initialization - * and the regd coming from this event has a valid country info. - */ - if (ab->default_regd[pdev_idx] && - !ath11k_reg_is_world_alpha((char *) - ab->default_regd[pdev_idx]->alpha2) && - !ath11k_reg_is_world_alpha((char *)reg_info->alpha2)) - intersect =3D true; - - regd =3D ath11k_reg_build_regd(ab, reg_info, intersect, - WMI_VDEV_TYPE_AP, IEEE80211_REG_LPI_AP); - if (!regd) { - ath11k_warn(ab, "failed to build regd from reg_info\n"); - goto fallback; - } - - spin_lock(&ab->base_lock); - if (ab->default_regd[pdev_idx]) { - /* The initial rules from FW after WMI Init is to build - * the default regd. From then on, any rules updated for - * the pdev could be due to user reg changes. - * Free previously built regd before assigning the newly - * generated regd to ar. NULL pointer handling will be - * taken care by kfree itself. - */ - ar =3D ab->pdevs[pdev_idx].ar; - kfree(ab->new_regd[pdev_idx]); - ab->new_regd[pdev_idx] =3D regd; - queue_work(ab->workqueue, &ar->regd_update_work); - } else { - /* This regd would be applied during mac registration and is - * held constant throughout for regd intersection purpose - */ - ab->default_regd[pdev_idx] =3D regd; } - ab->dfs_region =3D reg_info->dfs_region; - spin_unlock(&ab->base_lock); =20 - goto mem_free; + kfree(reg_info); + return 0; =20 -fallback: - /* Fallback to older reg (by sending previous country setting - * again if fw has succeeded and we failed to process here. - * The Regdomain should be uniform across driver and fw. Since the - * FW has processed the command and sent a success status, we expect - * this function to succeed as well. If it doesn't, CTRY needs to be - * reverted at the fw and the old SCAN_CHAN_LIST cmd needs to be sent. - */ - /* TODO: This is rare, but still should also be handled */ - WARN_ON(1); mem_free: - if (reg_info) { - kfree(reg_info->reg_rules_2ghz_ptr); - kfree(reg_info->reg_rules_5ghz_ptr); - if (reg_info->is_ext_reg_event) { - for (i =3D 0; i < WMI_REG_CURRENT_MAX_AP_TYPE; i++) - kfree(reg_info->reg_rules_6ghz_ap_ptr[i]); - - for (j =3D 0; j < WMI_REG_CURRENT_MAX_AP_TYPE; j++) - for (i =3D 0; i < WMI_REG_MAX_CLIENT_TYPE; i++) - kfree(reg_info->reg_rules_6ghz_client_ptr[j][i]); - } - kfree(reg_info); - } + ath11k_reg_reset_info(reg_info); + kfree(reg_info); return ret; } =20 diff --git a/drivers/net/wireless/ath/ath11k/wmi.h b/drivers/net/wireless/a= th/ath11k/wmi.h index ff0a9a92beeb0..cd2098d78e861 100644 --- a/drivers/net/wireless/ath/ath11k/wmi.h +++ b/drivers/net/wireless/ath/ath11k/wmi.h @@ -4951,6 +4951,7 @@ struct ath11k_targ_cap { }; =20 enum wmi_vdev_type { + WMI_VDEV_TYPE_UNSPEC =3D 0, WMI_VDEV_TYPE_AP =3D 1, WMI_VDEV_TYPE_STA =3D 2, WMI_VDEV_TYPE_IBSS =3D 3, --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 308B483A0F; Sun, 24 Mar 2024 22:36:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319764; cv=none; b=gB4yDe3YQTR7jkZKXmM+ef2YwoGY/EQTXjQ7UKUGpS26X7MFaahaxDm1exmdSJK++TSEpJ74iw9O/c0YW0hyTKOlxNVMjAEHdnM03grYd08hQb3jarb0EpfZuOjr3FA3701eUk4bs3kZwRh44PCDiJmLc4X6+il5kKn7LJ/ZVI8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319764; c=relaxed/simple; bh=MOxlhC3dPM+XBhOSTUcc9poorlCAcDLGIwRC0xTng1M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PkZZvbHYORv1S+bDUUFpjx2Ap2mPBHQiysQAm8S4TYBv/w4Z8DvD0mVWy8Uu5QlAATu38VP7iQzEbHW+aOjKPpIzAmoNfg4q2KXJ/Ung4KZG+CK+ZY69jW7l8SEYnGkIL3KZMl2lNjGg/i6F3okb0lN/4EHGEDxkARDbPnUMuos= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=i00GsFaP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="i00GsFaP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6427C43394; Sun, 24 Mar 2024 22:36:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319763; bh=MOxlhC3dPM+XBhOSTUcc9poorlCAcDLGIwRC0xTng1M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i00GsFaPDH+Mr6og8hryEDAjSsSB3vCdP6vHS6ygEsRRwYArUepz9hyjJMvQD0h41 bokrWFI3XIC6SuAtBN47l2TKNE2E/VdKm5uxn4N83hrXy1tdNlIACRdT2D0rxMJcf/ F+Si1o+vLioOs9b3zeQMZYMyhulc3KTY4/hCeIzRtYdPWOJHWq3w4ViylUzBoLIvIB EtSa8J5mwSBsjkuFS8JVTmvLBuWEbah3FCFwS08Om6HkDqYhXIj0VNCMK6DvjgXyBu c1zxnwIL9x1xNh2bJwrQNwCTL7lO/Oa3z9N0corvjFs9GS/yYT44juq6yT8WS+7jPM enHoEHzQMt+lA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Baochen Qiang , Wen Gong , Jeff Johnson , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 064/715] wifi: ath11k: fix a possible dead lock caused by ab->base_lock Date: Sun, 24 Mar 2024 18:24:03 -0400 Message-ID: <20240324223455.1342824-65-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Baochen Qiang [ Upstream commit cf2df0080bd59cb97a1519ddefaf59788febdaa5 ] spin_lock()/spin_unlock() are used in ath11k_reg_chan_list_event() to acquire/release ab->base_lock. For now this is safe because that function is only called in soft IRQ context. But ath11k_reg_chan_list_event() will be called from process context in an upcoming patch, and this can result in a deadlock if ab->base_lock is acquired in process context and then soft IRQ occurs on the same CPU and tries to acquire that lock. Fix it by using spin_lock_bh() and spin_unlock_bh() instead. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_L= ITE-3.6510.23 Fixes: 69a0fcf8a9f2 ("ath11k: Avoid reg rules update during firmware recove= ry") Signed-off-by: Baochen Qiang Signed-off-by: Wen Gong Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20231218085844.2658-4-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/ath/ath11k/reg.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/ath/ath11k/reg.c b/drivers/net/wireless/a= th/ath11k/reg.c index adcd9063a59c3..d4fd3509e608c 100644 --- a/drivers/net/wireless/ath/ath11k/reg.c +++ b/drivers/net/wireless/ath/ath11k/reg.c @@ -852,13 +852,13 @@ int ath11k_reg_handle_chan_list(struct ath11k_base *a= b, /* Avoid default reg rule updates sent during FW recovery if * it is already available */ - spin_lock(&ab->base_lock); + spin_lock_bh(&ab->base_lock); if (test_bit(ATH11K_FLAG_RECOVERY, &ab->dev_flags) && ab->default_regd[pdev_idx]) { - spin_unlock(&ab->base_lock); + spin_unlock_bh(&ab->base_lock); goto retfail; } - spin_unlock(&ab->base_lock); + spin_unlock_bh(&ab->base_lock); =20 if (pdev_idx >=3D ab->num_radios) { /* Process the event for phy0 only if single_pdev_only @@ -911,7 +911,7 @@ int ath11k_reg_handle_chan_list(struct ath11k_base *ab, ab->reg_info_store[pdev_idx] =3D *reg_info; } =20 - spin_lock(&ab->base_lock); + spin_lock_bh(&ab->base_lock); if (ab->default_regd[pdev_idx]) { /* The initial rules from FW after WMI Init is to build * the default regd. From then on, any rules updated for @@ -931,7 +931,7 @@ int ath11k_reg_handle_chan_list(struct ath11k_base *ab, ab->default_regd[pdev_idx] =3D regd; } ab->dfs_region =3D reg_info->dfs_region; - spin_unlock(&ab->base_lock); + spin_unlock_bh(&ab->base_lock); =20 return 0; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D482483CA8; Sun, 24 Mar 2024 22:36:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319764; cv=none; b=ggoJh2j+lyzou+ZhmN5mN7Cp2UEc/x0hzUI9BMRf78adDVkfUrgrUU7M6C8nlPNoio+ghMCpLTigo8tmtRUalBEpq572xjfcqO+Ey3Qhr/mesygL2S4Vd7waijOGRA5szDmQvsCV+isam4VZRirmosvM+ZoE4GBdPPqiC7H5NQ8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319764; c=relaxed/simple; bh=HRsI8JAt342So7xUBYg8KsqVHOOsA3e9WgoFFAH9MKM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JZ+eiyLgaQtNTxdra708ZREQwLcVyCrI48UZRYmBtdzH3THILYAUElvyI/H9u6Vyo1/TJ7XCPoo2hocpqxxRIKzw3+oamumkvJ7zwhlQOm1HqFq119m5A9cjoqMNBilZkTPCx6wE/XTe1s0mN7EyGX4Nc6AfsAqB5kAAKbGGCQw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dcdN++al; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dcdN++al" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 072F1C433C7; Sun, 24 Mar 2024 22:36:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319764; bh=HRsI8JAt342So7xUBYg8KsqVHOOsA3e9WgoFFAH9MKM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dcdN++alNhgSYgN1n6IUBhw39owBp81TUMSt4hHKV91bHMVfEHtqXPI2fhLqTHVu7 9Ny6/kZ+XJjevJm082NQpsIpdSFYpraMUfcdpZd8GTT41me/pfISbAKc7g0pGHxCrA 0R80WbjfryEBnXlXOTttHh967OVoahwdSyiCcO9dB3oiooDRx6X5VgpvCRVrdjLIT6 41s3eQoZkRJZorzMYYn2X5yjZmStjHPacKSq6hWEeDtD6nXVNtfZniCsvcXjhcUzss q5LMtL2y3PCUuWwLpfE0Xq7DYk3O28jgXA6q1e5JeXp4F7accryGCExBVtfHDhA6f4 zCcO+QeQ52Ivg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Martin Kaistra , Ping-Ke Shih , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 065/715] wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_work Date: Sun, 24 Mar 2024 18:24:04 -0400 Message-ID: <20240324223455.1342824-66-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Martin Kaistra [ Upstream commit 1213acb478a7181cd73eeaf00db430f1e45b1361 ] The workqueue might still be running, when the driver is stopped. To avoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop(). Fixes: e542e66b7c2e ("rtl8xxxu: add bluetooth co-existence support for sing= le antenna") Signed-off-by: Martin Kaistra Reviewed-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://msgid.link/20240111163628.320697-2-martin.kaistra@linutronix.= de Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/driver= s/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c index 180907319e8cd..04df0f54aa667 100644 --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c @@ -7304,6 +7304,7 @@ static void rtl8xxxu_stop(struct ieee80211_hw *hw) if (priv->usb_interrupts) rtl8xxxu_write32(priv, REG_USB_HIMR, 0); =20 + cancel_work_sync(&priv->c2hcmd_work); cancel_delayed_work_sync(&priv->ra_watchdog); =20 rtl8xxxu_free_rx_resources(priv); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D5AE684FC8; Sun, 24 Mar 2024 22:36:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319765; cv=none; b=F3nK406EobouftbNMnX643j5qzNj93NRDTYMXKbvGFtvpRsr4EyInIqIXGBwDPk0EaIgAf9QPqU0/GY7ru3ZLLJ8qGJI2IfAJRK9ePlyBfiEkE9y7m1KKgwZpSKZYurMU4CkKTH+s0Jv35dLuhw7hzTUfgeySU+zibbCIJO6xA8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319765; c=relaxed/simple; bh=dBV3B8MJUjFevc8l59/H8W8X83MP2S5X0b+e+rWPCVg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=B2/i+3R7tS9TAUN4t5GNbXOiaJsyFmcdz9TtF/nAV8EKvlUr+wtPhQbjeTMbDheygBUH/GO0nGBO0m9o2VvWstOzt/pW0Dkr/9u34YWTi+EATKskXN9zr8H/+p7VSeb74tcAHbmCrG8awF+PlT/06nluxtd2fTZxqcmyvO30XsI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SHUsgGf+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SHUsgGf+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05FA1C433F1; Sun, 24 Mar 2024 22:36:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319765; bh=dBV3B8MJUjFevc8l59/H8W8X83MP2S5X0b+e+rWPCVg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SHUsgGf+8Tb1KirPoXQkZdq3BEQ9Qqv9MOtmQxjIwY8DH69qjl9WC0SMjM6lQufev YwoqgQuL5Ut2EnZYjvLOKmLSc4TNueDA9wv1GH4qrQtM+t7nLql2yEzkqePgEl0H1E e59chdUjYDXlgWZyqVlZjE3+whz2vkfxj9bJ3FZHS4ylRnx/SvAWbBj47WXG30MRvy LUTGrvjqLWYOJhMumssVzI//nB5DGsoCnAgZgseP8U4r+oevTIz0FNuKtN4oi+k4fI eCLzFzQWpOtWSKX0N/od+juxPqueNKfcScSVeHE5xjJRhTK8bkp6ej+zguGTGiwZTA 3sU7Nzkv2/elA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ajay Singh , =?UTF-8?q?Alexis=20Lothor=C3=A9?= , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 066/715] wifi: wilc1000: do not realloc workqueue everytime an interface is added Date: Sun, 24 Mar 2024 18:24:05 -0400 Message-ID: <20240324223455.1342824-67-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ajay Singh [ Upstream commit 328efda22af81130c2ad981c110518cb29ff2f1d ] Commit 09ed8bfc5215 ("wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-wq"") moved workqueue creation in wilc_netdev_ifc_init in order to set the interface name in the workqueue name. However, while the driver needs only one workqueue, the wilc_netdev_ifc_init is called each time we add an interface over a phy, which in turns overwrite the workqueue with a new one. This can be observed with the following commands: for i in $(seq 0 10) do iw phy phy0 interface add wlan1 type managed iw dev wlan1 del done ps -eo pid,comm|grep wlan 39 kworker/R-wlan0 98 kworker/R-wlan1 102 kworker/R-wlan1 105 kworker/R-wlan1 108 kworker/R-wlan1 111 kworker/R-wlan1 114 kworker/R-wlan1 117 kworker/R-wlan1 120 kworker/R-wlan1 123 kworker/R-wlan1 126 kworker/R-wlan1 129 kworker/R-wlan1 Fix this leakage by putting back hif_workqueue allocation in wilc_cfg80211_init. Regarding the workqueue name, it is indeed relevant to set it lowercase, however it is not attached to a specific netdev, so enforcing netdev name in the name is not so relevant. Still, enrich the name with the wiphy name to make it clear which phy is using the workqueue. Fixes: 09ed8bfc5215 ("wilc1000: Rename workqueue from "WILC_wq" to "NETDEV-= wq"") Signed-off-by: Ajay Singh Co-developed-by: Alexis Lothor=C3=A9 Signed-off-by: Alexis Lothor=C3=A9 Signed-off-by: Kalle Valo Link: https://msgid.link/20240115-wilc_1000_fixes-v1-3-54d29463a738@bootlin= .com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/microchip/wilc1000/cfg80211.c | 11 ++++++++++- drivers/net/wireless/microchip/wilc1000/netdev.c | 10 +--------- 2 files changed, 11 insertions(+), 10 deletions(-) diff --git a/drivers/net/wireless/microchip/wilc1000/cfg80211.c b/drivers/n= et/wireless/microchip/wilc1000/cfg80211.c index ad2509d8c99a4..2d0474e6404e1 100644 --- a/drivers/net/wireless/microchip/wilc1000/cfg80211.c +++ b/drivers/net/wireless/microchip/wilc1000/cfg80211.c @@ -1804,15 +1804,24 @@ int wilc_cfg80211_init(struct wilc **wilc, struct d= evice *dev, int io_type, INIT_LIST_HEAD(&wl->rxq_head.list); INIT_LIST_HEAD(&wl->vif_list); =20 + wl->hif_workqueue =3D alloc_ordered_workqueue("%s", WQ_MEM_RECLAIM, + wiphy_name(wl->wiphy)); + if (!wl->hif_workqueue) { + ret =3D -ENOMEM; + goto free_cfg; + } vif =3D wilc_netdev_ifc_init(wl, "wlan%d", WILC_STATION_MODE, NL80211_IFTYPE_STATION, false); if (IS_ERR(vif)) { ret =3D PTR_ERR(vif); - goto free_cfg; + goto free_hq; } =20 return 0; =20 +free_hq: + destroy_workqueue(wl->hif_workqueue); + free_cfg: wilc_wlan_cfg_deinit(wl); =20 diff --git a/drivers/net/wireless/microchip/wilc1000/netdev.c b/drivers/net= /wireless/microchip/wilc1000/netdev.c index 81e8f25863f5b..6c1058e5299c7 100644 --- a/drivers/net/wireless/microchip/wilc1000/netdev.c +++ b/drivers/net/wireless/microchip/wilc1000/netdev.c @@ -989,13 +989,6 @@ struct wilc_vif *wilc_netdev_ifc_init(struct wilc *wl,= const char *name, goto error; } =20 - wl->hif_workqueue =3D alloc_ordered_workqueue("%s-wq", WQ_MEM_RECLAIM, - ndev->name); - if (!wl->hif_workqueue) { - ret =3D -ENOMEM; - goto unregister_netdev; - } - ndev->needs_free_netdev =3D true; vif->iftype =3D vif_type; vif->idx =3D wilc_get_available_idx(wl); @@ -1008,12 +1001,11 @@ struct wilc_vif *wilc_netdev_ifc_init(struct wilc *= wl, const char *name, =20 return vif; =20 -unregister_netdev: +error: if (rtnl_locked) cfg80211_unregister_netdevice(ndev); else unregister_netdev(ndev); - error: free_netdev(ndev); return ERR_PTR(ret); } --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1D52B85941; Sun, 24 Mar 2024 22:36:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319767; cv=none; b=duzHev0BCdxyo5fsyQXduUZAflOnjQlioId6TiImok1vE4SBc6onmU2n7Iql3KAg8zdWr18hlj2Pxaqhd7uEhkO3DZ0d2ou6AIBno0DpukzpMwlzRqDvrblv7KFxBh5eIktpNvXRInzt1KfZjm0C1lYHotLG16cVN3PkFJcME7U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319767; c=relaxed/simple; bh=7eUBJ5IjDgPLqBRxbfms1rpD5UqfO/FsYLiLZqXzTXE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=VMf8GECxi6OvoCURqADHpu93j+bIaLSmBcihO/ar8i0QW+SLLHxuGpLyBvCsI2ToUJJHHVPAlEWTr0TCex+2k3CtynN0dcjBE+P5Lom4N/Q6MIcNZCdRTBDubc01OTNjctRJr7P4U7sN2gh+po4pgTFMmB+lm1Dv4xuzbD6wNko= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ko8bceW1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ko8bceW1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04201C433C7; Sun, 24 Mar 2024 22:36:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319766; bh=7eUBJ5IjDgPLqBRxbfms1rpD5UqfO/FsYLiLZqXzTXE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ko8bceW1VfnSYSPYKVsmecJibTwIRek/Wud4kLEvczEgasIka0Xdk8nd6WvSZ6PIg 2ByoAXBL37bkpKsVwdBaNmN9pkBB2Ym9U5GNvVGTJTGOaAkNGAH89wIiyARje/Nc/z 66JPYiTRO4zOi2WENeUtTzWuXIZ3gPoBwI5revxy/Zw9lk55/V10NP1v/l5a8O6CI5 Y/BSnj+JO4CnJB+pKhP5nbFGPH+aQ8BDeunoQm10xD5K9YUj99X/aSdtcCjkjabFgN XJZM9BSsKqJVgpLV+HzKbZkueS4co79O9zz82eMqievSXsfFu6ZauidSS/xS/SqrM9 P9RyUxqee4o+Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ajay Singh , =?UTF-8?q?Alexis=20Lothor=C3=A9?= , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 067/715] wifi: wilc1000: fix multi-vif management when deleting a vif Date: Sun, 24 Mar 2024 18:24:06 -0400 Message-ID: <20240324223455.1342824-68-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ajay Singh [ Upstream commit 12cfc9c8d3faf887a202c89bc312202445fca7e8 ] Adding then removing a second vif currently makes the first vif not working anymore. This is visible for example when we have a first interface connected to some access point: - create a wpa_supplicant.conf with some AP credentials - wpa_supplicant -Dnl80211 -c /etc/wpa_supplicant.conf -i wlan0 - dhclient wlan0 - iw phy phy0 interface add wlan1 type managed - iw dev wlan1 del wlan0 does not manage properly traffic anymore (eg: ping not working) This is due to vif mode being incorrectly reconfigured with some default values in del_virtual_intf, affecting by default first vif. Prevent first vif from being affected on second vif removal by removing vif mode change command in del_virtual_intf Fixes: 9bc061e88054 ("staging: wilc1000: added support to dynamically add/r= emove interfaces") Signed-off-by: Ajay Singh Co-developed-by: Alexis Lothor=C3=A9 Signed-off-by: Alexis Lothor=C3=A9 Signed-off-by: Kalle Valo Link: https://msgid.link/20240115-wilc_1000_fixes-v1-5-54d29463a738@bootlin= .com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/microchip/wilc1000/cfg80211.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/microchip/wilc1000/cfg80211.c b/drivers/n= et/wireless/microchip/wilc1000/cfg80211.c index 2d0474e6404e1..f03fd15c0c97a 100644 --- a/drivers/net/wireless/microchip/wilc1000/cfg80211.c +++ b/drivers/net/wireless/microchip/wilc1000/cfg80211.c @@ -1609,7 +1609,6 @@ static int del_virtual_intf(struct wiphy *wiphy, stru= ct wireless_dev *wdev) cfg80211_unregister_netdevice(vif->ndev); vif->monitor_flag =3D 0; =20 - wilc_set_operation_mode(vif, 0, 0, 0); mutex_lock(&wl->vif_mutex); list_del_rcu(&vif->list); wl->vif_num--; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 346228627C; Sun, 24 Mar 2024 22:36:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319768; cv=none; b=tOEjfVnOOcD+mwgU3PTjjecsw8n/8UD/GF6yTW+FPhufhozAc3PFSVyo62BPG3HJfUq4WFN/Rx8OsHyGHJIhM7F473V2OVhzPyEPcMwTjFePK0TfHoYGZ+r4umbZpgJAQEok1VmlytWLTSYnd4CiiMPdFkHFF69WDUQLeR3CaSc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319768; c=relaxed/simple; bh=60vo75mBcZsaaWRfia1pLHWloNQ83WhNjty4gGNM0pg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=c9q1itLe/pjk/9Y2caqdeQCl+QCmCSucJtdm9gmVD5CCvlxPZ9ChAraJmVciQeZeqGpp7trk00zbriGu7x52A7ZkSKCXRfsTSjz+KGNV7eAK7jGTa6t/NmCxHSgW7W+/pr6KTYrb9mD+KjppwYMuhuGAFfoG4MZAYg08HQ/QWMA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Vc205BCC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Vc205BCC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F3C6AC43394; Sun, 24 Mar 2024 22:36:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319767; bh=60vo75mBcZsaaWRfia1pLHWloNQ83WhNjty4gGNM0pg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Vc205BCCEVCFiYWwWzvseHOPtPkhFlDbIIl4FRkWLziRWsO+n4jbzuLfZWg9zktmj +sxnbtc+3LvVrvr61LqfmPEP25+YQ04Gxr66GVPsrZyxVEKkubIjaAEvHx1MmoE1qA Ft8995VwS1fDfSrRDDibA/TKl5KKx+s+zOl8/EY2MIpf/HfJ4gNcWa83d/g7pp6KUK q/wt2oSKPaDICRp/KDWUe86ZTw3xL8wwpigURfbYhdpBMya+PARB2frPon14QhR9ox xNKQCUOLD1YPW+YTylBYSKg+gYtMra05Tr6KhLFFbarLiO+OBGpyJ4RWQ/P86zOUeh H0L5nJhkUMPow== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jinjie Ruan , Russell King , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 068/715] wifi: mwifiex: debugfs: Drop unnecessary error check for debugfs_create_dir() Date: Sun, 24 Mar 2024 18:24:07 -0400 Message-ID: <20240324223455.1342824-69-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jinjie Ruan [ Upstream commit 50180c7f8e3de7c2d87f619131776598fcb1478d ] debugfs_create_dir() returns ERR_PTR and never return NULL. As Russell suggested, this patch removes the error checking for debugfs_create_dir(). This is because the DebugFS kernel API is developed in a way that the caller can safely ignore the errors that occur during the creation of DebugFS nodes. The debugfs APIs have a IS_ERR() judge in start_creating() which can handle it gracefully. So these checks are unnecessary. Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex= driver") Signed-off-by: Jinjie Ruan Suggested-by: Russell King (Oracle) Signed-off-by: Kalle Valo Link: https://msgid.link/20230903030216.1509013-3-ruanjinjie@huawei.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/marvell/mwifiex/debugfs.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/wireless/marvell/mwifiex/debugfs.c b/drivers/net/w= ireless/marvell/mwifiex/debugfs.c index f9c9fec7c792a..d14a0f4c1b6d7 100644 --- a/drivers/net/wireless/marvell/mwifiex/debugfs.c +++ b/drivers/net/wireless/marvell/mwifiex/debugfs.c @@ -970,9 +970,6 @@ mwifiex_dev_debugfs_init(struct mwifiex_private *priv) priv->dfs_dev_dir =3D debugfs_create_dir(priv->netdev->name, mwifiex_dfs_dir); =20 - if (!priv->dfs_dev_dir) - return; - MWIFIEX_DFS_ADD_FILE(info); MWIFIEX_DFS_ADD_FILE(debug); MWIFIEX_DFS_ADD_FILE(getlog); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C16E586639; Sun, 24 Mar 2024 22:36:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319768; cv=none; b=gIY/7iKQ0oriJmL8cBWjiM44zcW8LMrxXU+A/P8RT2P/L2OouTFovMUP3NPOjhz879kyWvCzRHUHnFDwcBMOJm6W8HvsPj3x4PNKtvKFl3aL9sxdInRntXN450ilypYHLTMNwsCWr01ShtJn70qDTUBqk5TRFNZwyrY/ghmJQ6w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319768; c=relaxed/simple; bh=YEPz7/LV8rFX1YoEpidCsvFq2drnraVPp+Gh9O1b24A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mpQqSspokHmZAVfPFjU+XYXlJ92YueeD31jRFiV0SeHik2lVFjWu50H6fhU54WYUDzrQ066MnffuArsOPYH9Ldx3KPf2cTY9FZ1AHL3thKOv65PIPq0NecIDL6hoyufKt4EZlfByssOVFrJpJHRCL7RIOPpYkJ0hk/8JCM6V7Jw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CnT9ln0s; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CnT9ln0s" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 04887C433C7; Sun, 24 Mar 2024 22:36:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319768; bh=YEPz7/LV8rFX1YoEpidCsvFq2drnraVPp+Gh9O1b24A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CnT9ln0si4zb+R+cnsdINgv4DGk32lP37EY6RiQmP7iYWS7afhAPy0RTNRoix9ZZu Gkmnb7RH80tykym0fnOoGT/jxiQmD9pmwIaJI38s21M/h0QAR4/SeZY6OlJKH/qJGN QEtMGxaty32H+d4l8TnPrxf3XC01tdm93gJ9Zi6atHg+ze9U2yWm8dGjmkDAtn+YeG tyV+nm4BCUkYlnx7l6EFFC/ZeSw3W8QVj07GwCIkbVSgL3hlmBCi9ckXgaJ/TUTH3N mdAHjXrPtc5KyLde8u2QAf/7QyY2C2DYC579vdQiKCmwL0dUSKQz7+KOyRzOAhXtra 5LDFYhzlHToJA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Geert Uytterhoeven , =?UTF-8?q?Niklas=20S=C3=B6derlund?= , Sasha Levin Subject: [PATCH 6.8 069/715] ARM: dts: renesas: r8a73a4: Fix external clocks and clock rate Date: Sun, 24 Mar 2024 18:24:08 -0400 Message-ID: <20240324223455.1342824-70-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Geert Uytterhoeven [ Upstream commit 090c4094574705b0afc7d37825cdc5d06f0e7e02 ] External clocks should be defined as zero-Hz clocks in the SoC .dtsi, and overridden in the board .dts when present. Correct the clock rate of extal1 from 25 to 26 MHz, to match the crystal oscillator present on the APE6-EVM board. Fixes: a76809a329d6ebae ("ARM: shmobile: r8a73a4: Common clock framework DT= description") Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas S=C3=B6derlund Link: https://lore.kernel.org/r/1692bc8cd465d62168cbf110522ad62a7af3f606.17= 05315614.git.geert+renesas@glider.be Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm/boot/dts/renesas/r8a73a4-ape6evm.dts | 12 ++++++++++++ arch/arm/boot/dts/renesas/r8a73a4.dtsi | 9 ++++++--- 2 files changed, 18 insertions(+), 3 deletions(-) diff --git a/arch/arm/boot/dts/renesas/r8a73a4-ape6evm.dts b/arch/arm/boot/= dts/renesas/r8a73a4-ape6evm.dts index ed75c01dbee10..3d02f065f71c2 100644 --- a/arch/arm/boot/dts/renesas/r8a73a4-ape6evm.dts +++ b/arch/arm/boot/dts/renesas/r8a73a4-ape6evm.dts @@ -209,6 +209,18 @@ &cmt1 { status =3D "okay"; }; =20 +&extal1_clk { + clock-frequency =3D <26000000>; +}; + +&extal2_clk { + clock-frequency =3D <48000000>; +}; + +&extalr_clk { + clock-frequency =3D <32768>; +}; + &pfc { scifa0_pins: scifa0 { groups =3D "scifa0_data"; diff --git a/arch/arm/boot/dts/renesas/r8a73a4.dtsi b/arch/arm/boot/dts/ren= esas/r8a73a4.dtsi index c39066967053f..d1f4cbd099efb 100644 --- a/arch/arm/boot/dts/renesas/r8a73a4.dtsi +++ b/arch/arm/boot/dts/renesas/r8a73a4.dtsi @@ -450,17 +450,20 @@ clocks { extalr_clk: extalr { compatible =3D "fixed-clock"; #clock-cells =3D <0>; - clock-frequency =3D <32768>; + /* This value must be overridden by the board. */ + clock-frequency =3D <0>; }; extal1_clk: extal1 { compatible =3D "fixed-clock"; #clock-cells =3D <0>; - clock-frequency =3D <25000000>; + /* This value must be overridden by the board. */ + clock-frequency =3D <0>; }; extal2_clk: extal2 { compatible =3D "fixed-clock"; #clock-cells =3D <0>; - clock-frequency =3D <48000000>; + /* This value must be overridden by the board. */ + clock-frequency =3D <0>; }; fsiack_clk: fsiack { compatible =3D "fixed-clock"; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ACB9B86AC9; Sun, 24 Mar 2024 22:36:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319769; cv=none; b=HAXutAfmWIDKOqqB/TrBqC7b29tnJK8mSOGD5/lnXYBsc3/Q0jGcgqOUR1ljDuUINgwXQ8mcWQKmLCm/LTDFX0VxF6juAPTcvH3Mre1QaJZ4uh+C0wIvGWgo126UjZTAV12a7jYZtTxpTHwd6xtGfjBJZ0Xo87KfhOsgzHAqi4Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319769; c=relaxed/simple; bh=OEcpBvYt6RTe0MaBpB3+cd6RgldMLzd60t+NxZBffJA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=H1sk+1nFYRf2tQ7n51mgkuxLnf3LJh0juu13zWJRW3xCtZhJMW75a1zTQP0ZsfqtKlPmufY7y7kDRKvp5Su6Id0tKObtqH1kWv0EeUXo1LrGxRHDLVzuqZ+CXc+pVwuxRAqoW4gpI6KjOiEqikf4qz4FNeJ9k3PO4L0FoLWvMtQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=njofFJDx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="njofFJDx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E532EC43399; Sun, 24 Mar 2024 22:36:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319769; bh=OEcpBvYt6RTe0MaBpB3+cd6RgldMLzd60t+NxZBffJA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=njofFJDxA0G1g+BKS3LGTNVxO6Yca/UEGB+S7cTWDD1pEi1GxlQdJ8M/oKkNQulEN 4b5gsehDG7WswVtkftgSwYotDHdW0O4VE89ERrwx7VM1eFa7jfxeWr2pRfkjYiCBnv DqOF9kzK7025/ugr8tg0WRgL/SDZ/0VGhirWyvYik8g+a6Sf1rWMt9nXAnbtAGVxec hkNVkh1XGqJqTVADju/upyybZMPEqOPzE9Q+Y1vhJIGGa+I3VALVqenSLpM99MnkR7 jwe4+0nmLrDuKXD98KPUx4m6yRiIB/8JDGPSah8+r59y3wL/rm3xwF1IGucLZComjk Y5muJ5AnuHYAQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Krzysztof Kozlowski , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 070/715] arm64: dts: qcom: x1e80100: drop qcom,drv-count Date: Sun, 24 Mar 2024 18:24:09 -0400 Message-ID: <20240324223455.1342824-71-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Krzysztof Kozlowski [ Upstream commit e81e86765f957f3c5d48df9e275c527bd8c14156 ] Property qcom,drv-count in the RSC node is not allowed and not used: x1e80100-crd.dtb: rsc@17500000: 'qcom,drv-count' does not match any of th= e regexes: '^regulators(-[0-9])?$', 'pinctrl-[0-9]+' Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP = dts") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20231218145050.66394-1-krzysztof.kozlowski@= linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/x1e80100.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/q= com/x1e80100.dtsi index 6f75fc342ceb3..be1285d9919e0 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi @@ -3315,7 +3315,6 @@ apps_rsc: rsc@17500000 { <0 0x17510000 0 0x10000>, <0 0x17520000 0 0x10000>; reg-names =3D "drv-0", "drv-1", "drv-2"; - qcom,drv-count =3D <3>; =20 interrupts =3D , , --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E4691126F1A; Sun, 24 Mar 2024 22:36:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319771; cv=none; b=BiDDTH/Fkf/9jvggiHBzNxMFqssjKR7h7iBBkGYd119wjLlwaUIWNAJTdlOPBQSfSOIHjR/Bzk0eDNMfcMNUOlYhWQMb3N99GAknmMXBJQI00ME9kbXNKTtQp8H9CLWDK1hlu5tpLGIA0eRAiMWJ0KcIeSw3KiNW/+XvXlf/bJI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319771; c=relaxed/simple; bh=xjqHKYSgG2+1s7bWEwmzpDAXT7akFxCKu5c5fcVHtHU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZSASYx0kE7lw0Gd1rympUiECUiIi3HwNNzSIsDWFX8nVXNHVxQkrs1LAFTCKtpWdXnkta5N+0VmYOURILxlP18uSHBnXPWlvDGktWOfkIAZOkO6pVwuAWXEjUcO1SqhUL44Q4RXevKOSgYPVC4vWxbwcUVzEq7Mp8LyaknQYNFw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VJr96o8e; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VJr96o8e" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD2B2C433F1; Sun, 24 Mar 2024 22:36:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319770; bh=xjqHKYSgG2+1s7bWEwmzpDAXT7akFxCKu5c5fcVHtHU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VJr96o8eTr8V6EW5mFprFE788foTgDGRx1Pd2H9COvcxTZ8UVrAZfrHH+TbMcjvTF TH9HbN4hqgxMpSgt4rLVQ1X3jqAEkBxIDukx95mAnetkfhxtsFyOZL/9x/iwXYX3WZ 8nskJj5LTlReTGelv/cd7996ej9ORR38VvwEeF35LknkdNkc9BwipqwG5WuTysOTDi /S7gqww7mQQj2JroeW8z+8S70/9htmBIewMB8YAGqTCUvcY/hw2wKU47BjiF9NJn/y HHBtdUhr8RevsFWu2Tx4HZ1Q/AF83StIUyAYX1ngdKzfulsVq41U3bYOEr0iHOEOUN zv/DCmS/z7Dgw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 071/715] arm64: dts: qcom: sc8180x: Hook up VDD_CX as GCC parent domain Date: Sun, 24 Mar 2024 18:24:10 -0400 Message-ID: <20240324223455.1342824-72-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit 3c58b96df110a80e78fa36ef928f1e6c375008e3 ] Most of GCC is powered by the CX rail. Describe that relationship to let the performance state requests trickle up the chain. Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231230-topic-8180_more_fixes-v1-2-93b5c10= 7ed43@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sc8180x.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/qcom/sc8180x.dtsi b/arch/arm64/boot/dts/qc= om/sc8180x.dtsi index 0430d99091e30..91fd805f17a1b 100644 --- a/arch/arm64/boot/dts/qcom/sc8180x.dtsi +++ b/arch/arm64/boot/dts/qcom/sc8180x.dtsi @@ -782,6 +782,7 @@ gcc: clock-controller@100000 { clock-names =3D "bi_tcxo", "bi_tcxo_ao", "sleep_clk"; + power-domains =3D <&rpmhpd SC8180X_CX>; }; =20 qupv3_id_0: geniqup@8c0000 { --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6EAD0126F25; Sun, 24 Mar 2024 22:36:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319771; cv=none; b=ZezWfb0Y5BpaMrF/XjEvB4S+A1hLaXF7/cuphqjkv6LJw140eujuDA9kZiqkpM92KPFL0Ln2g8ojXOMWdX2B5aARLEPNIrGt2lgBWgqIUbkVqPHj6ZJSWd2zRUnet16S+MJw1tskQQwaUhL5q+Xwad+U6UKEpxQbY4NoMgZW6Wo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319771; c=relaxed/simple; bh=ejEken6MNn40cWSqDfSx13qHzU93nZ33Dq8SRiNXNHE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l15gd5hDBP1oNb99hoZzSY9sOBQ2Jsys07gfn/jjzfTaIDNAx03ABn2FTtPjsG3hTfD6TLh36ZQA9fUdkBsaKEnpq5pCJ3MvEf2by6+PABhUfzwHLOLLPF+6MjqSDN4hojfwiHlFPj9iwF4IBVtkHpp84UuucFk2TQ2LIC+NdRk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EuEhaq7Q; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EuEhaq7Q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1469C433A6; Sun, 24 Mar 2024 22:36:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319771; bh=ejEken6MNn40cWSqDfSx13qHzU93nZ33Dq8SRiNXNHE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EuEhaq7QEGNCV3EfWMUeF8FjeTBEzEEV2vou7okcLHK5lWN8b98qEqNmn3lL5SAr4 z5swCxigAlYsqFdVYGOSQ8gJ+oCLNuZpxiXbGelg85WrJSTvhYGEUS1G9PqzMfwlfK ihSuHiivyZAzoHszpGkT3ZjXBemTRVZeELE5aZCavki5xAfOcZ8tjr2LUl5bEmeFz0 xwrCqLDNE2K6awS32CxBJjTD66jsj9y9c5HJCZCNxtZvAIFJIhTj6nCO/qfT1YeZfw jyvNcLQLKho+o/dHieCS8cLU0mvEcJtFJhbh09eKqdgVcq3tCuQak+2ye8o569E7qf eaIv4T9b+vECQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 072/715] arm64: dts: qcom: sc8180x: Fix up big CPU idle state entry latency Date: Sun, 24 Mar 2024 18:24:11 -0400 Message-ID: <20240324223455.1342824-73-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit 266a3a92044b89c392b3e9cfcc328d4167c18294 ] The entry latency was oddly low.. Turns out somebody forgot about a second '1'! Fix it. Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231230-topic-8180_more_fixes-v1-3-93b5c10= 7ed43@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sc8180x.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/sc8180x.dtsi b/arch/arm64/boot/dts/qc= om/sc8180x.dtsi index 91fd805f17a1b..b84fe5f3b41cb 100644 --- a/arch/arm64/boot/dts/qcom/sc8180x.dtsi +++ b/arch/arm64/boot/dts/qcom/sc8180x.dtsi @@ -290,7 +290,7 @@ LITTLE_CPU_SLEEP_0: cpu-sleep-0-0 { BIG_CPU_SLEEP_0: cpu-sleep-1-0 { compatible =3D "arm,idle-state"; arm,psci-suspend-param =3D <0x40000004>; - entry-latency-us =3D <241>; + entry-latency-us =3D <2411>; exit-latency-us =3D <1461>; min-residency-us =3D <4488>; local-timer-stop; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 611851272B8; Sun, 24 Mar 2024 22:36:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319772; cv=none; b=q1o4NdTqzJomGwaFwIWFdeuCuzkoFrPoeYY4/lNGC4gA14xOQ9h06cXXxZjw0Xd0nOmykzI0Zvzw4XFEXVJ9owtrtQF9BTeK3LTG9gkctkp7zpnXZ03rBUhMWuys22rYjrWXDp0vY5CopqRODojpqvC/J+JzbBkw9OWMJWjwd/M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319772; c=relaxed/simple; bh=tV8tPyjDBqcivZy7fQnifxHJaUsNLTeXhPXtDBg9Lzw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZGFoIeowUGlW9DQ8BgLS+AoHjBZh00FiOT/pjHwoSxncPU03Vr1OVhfxTeMfKxRl6SZOua4uUCfWX4j6VqFXAT0iVjYFFnFgTl/L/cJkustzxz12lJyXJRGCls7eWh48ZGP9RIFmzEvYBv2WcHCEFFziwgGET5Ap2oW7emzWRbQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NxYnWzwM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NxYnWzwM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9507DC433C7; Sun, 24 Mar 2024 22:36:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319772; bh=tV8tPyjDBqcivZy7fQnifxHJaUsNLTeXhPXtDBg9Lzw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NxYnWzwMvsj8qno1zmcbxUaiuCv23FY97s8fc/4NRDeOZ0hs9xKwUDWJ1Qrw9KZxh 73pP/FRGOKlWJU3TFD+VHGnQXX9D4XCWfhiLuTtQ258HGqMRv+etTI+03BnEdiyBVl pQq0USOhyVwXm7AH9aPdcLAxu91JqBRUgp9QSQg+XzRb2K/QGUT9y2wdm13nP2zXBe POatgUno9jQlT9itnjspWz1lvhW5OPcFFRGS0cg3BlpJYwolDyjz2ksxC68PfbQvL5 eK0AnBaHj5dN14R+vaKmxwDRNolqg/EZUoL9Rf8c3PRj1VkZzZnMXWa4Elj7vlRDiL iZNd6DrBqa4zg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 073/715] arm64: dts: qcom: sc8180x: Add missing CPU off state Date: Sun, 24 Mar 2024 18:24:12 -0400 Message-ID: <20240324223455.1342824-74-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit 07b600dfdfea65d58dd80ea25becd8cff69bfafc ] The CPUs can be powered off without pulling the plug from the rest of the system. Describe the idle state responsible for this. Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231230-topic-8180_more_fixes-v1-4-93b5c10= 7ed43@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sc8180x.dtsi | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sc8180x.dtsi b/arch/arm64/boot/dts/qc= om/sc8180x.dtsi index b84fe5f3b41cb..8849469d0aa10 100644 --- a/arch/arm64/boot/dts/qcom/sc8180x.dtsi +++ b/arch/arm64/boot/dts/qcom/sc8180x.dtsi @@ -298,7 +298,15 @@ BIG_CPU_SLEEP_0: cpu-sleep-1-0 { }; =20 domain-idle-states { - CLUSTER_SLEEP_0: cluster-sleep-0 { + CLUSTER_SLEEP_APSS_OFF: cluster-sleep-0 { + compatible =3D "domain-idle-state"; + arm,psci-suspend-param =3D <0x41000044>; + entry-latency-us =3D <3300>; + exit-latency-us =3D <3300>; + min-residency-us =3D <6000>; + }; + + CLUSTER_SLEEP_AOSS_SLEEP: cluster-sleep-1 { compatible =3D "domain-idle-state"; arm,psci-suspend-param =3D <0x4100a344>; entry-latency-us =3D <3263>; @@ -582,7 +590,7 @@ CPU_PD7: power-domain-cpu7 { =20 CLUSTER_PD: power-domain-cpu-cluster0 { #power-domain-cells =3D <0>; - domain-idle-states =3D <&CLUSTER_SLEEP_0>; + domain-idle-states =3D <&CLUSTER_SLEEP_APSS_OFF &CLUSTER_SLEEP_AOSS_SLE= EP>; }; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3DA0986AC9; Sun, 24 Mar 2024 22:36:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319773; cv=none; b=RTr9yQQeYMqbYB1OSqQAmqQX5dGUyzRqBkmodmP807eKxwEShuZeHzCbOozgAqLB4M4ku3MNFqoB4KIMHpVJz7T0dPb09XLdEUO87NBz3nbc6urQlted3JaYY25Y69zbBk6XwzsgossCIt4lsARpWOEydSf58bZEFzAr8j6pqx4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319773; c=relaxed/simple; bh=U/7ozjVEdbXt7Kzw2m1O4hRYL7yDtZq3zrZBCHN1xno=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CIXzAybARWLYGONX+DdsDKk6l0I1/AL5ggsUERrVeNM81B4Ig0nxEBQ6JHtKz8spYdJQhyXW1+Vr0znujNTvSsEMq9+5yBfUKWZQu4ZuQsrAFl74FaUTRwVXpkH647DXym3x9RCNof7ERpeQbKW6FaRkbPOoH2hNqP5OkwMpBcc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jRH+1Yol; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jRH+1Yol" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D473C433F1; Sun, 24 Mar 2024 22:36:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319773; bh=U/7ozjVEdbXt7Kzw2m1O4hRYL7yDtZq3zrZBCHN1xno=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jRH+1Yol+5UL77b0Kfvjvee8wv4bSIsxOoMmXEvJyM+tZjpYKl1POM/vJ0qkQVliq Z1SD9JSGzcS5/yuIOSF8QABj8+NTKxfT1AHh++7x3bt0/9Q3I0AJY2wcI6gbetAPdO qNcLzcvWlyIJmF0acIm2cgeV2RYOBCI4D/y427KF1ACd6OlytA53VVupFrLTpX7twY re17NCqVSaV2k3E+kgIsXwUCJolq1QbXM4bIQUnYUKbg1Si1I5cZDTNiP80FY398V9 KLsxZBMsHUgh/xLsJpJmHkedmWiPWhGl2D45OVLyPuIxkhIUdcAlzFl5eIkSrr5obi /V6ieh4D6AiRg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 074/715] arm64: dts: qcom: sc8180x: Fix eDP PHY power-domains Date: Sun, 24 Mar 2024 18:24:13 -0400 Message-ID: <20240324223455.1342824-75-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit 24e98cb3d5e2c86565680e00008a794b4eac0040 ] The (e)DP PHYs are powered by the MX line, not through the MDSS GDSC. Fix that up. Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231230-topic-8180_more_fixes-v1-5-93b5c10= 7ed43@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sc8180x.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/sc8180x.dtsi b/arch/arm64/boot/dts/qc= om/sc8180x.dtsi index 8849469d0aa10..8f7f5b74cdb9f 100644 --- a/arch/arm64/boot/dts/qcom/sc8180x.dtsi +++ b/arch/arm64/boot/dts/qcom/sc8180x.dtsi @@ -3193,7 +3193,7 @@ edp_phy: phy@aec2a00 { <&dispcc DISP_CC_MDSS_AHB_CLK>; clock-names =3D "aux", "cfg_ahb"; =20 - power-domains =3D <&dispcc MDSS_GDSC>; + power-domains =3D <&rpmhpd SC8180X_MX>; =20 #clock-cells =3D <1>; #phy-cells =3D <0>; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9757F127B6B; Sun, 24 Mar 2024 22:36:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319774; cv=none; b=cpRvnrUWPHXTiPLWmivEE/B4KIq/da7SM9UFsBDRbKfakYM+y6X+tDlxzeLYBt/cVOn/qmLP/GbRfkXCPz/ODq1snaBi2e69AxeVFk/jFV/R0GsvewbIvh8bE//ywlE3S3/AcoT+EObNxwqvKD7M6PLSAXqES/EDv5ZWWHlcCdA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319774; c=relaxed/simple; bh=BVUOlcZ0kGNiaGpte4w8wppOTrP2rpZwLft9Jy2ZPNE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DiwHIAL3vcXUnNznPKH4z/E8MQkjoTbLO26LMaJUv4n6aF2wM4eEZHzaKUfVGqyBTzVbL88VBkL6vY3qwv6NVUcCzow6L4fIdQ/ykfYO6J+o0aacroRohf6zjbUNUJ2+6WJoWyLwO3ezHtoHem0L9UkEgV+VeHxkVLC/fxT1Dn0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O0DFw21T; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="O0DFw21T" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 622E4C433A6; Sun, 24 Mar 2024 22:36:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319774; bh=BVUOlcZ0kGNiaGpte4w8wppOTrP2rpZwLft9Jy2ZPNE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O0DFw21T2V9vC7FcG5Guin2CxfW4Fr+mrVPcXISP7dexybbObQQIsA9u26W/3zolL VRn0JFjjcua/MtkUh+bE0yLDt7T3b3jsDaOlhGrAQLfLL2yPi/ceddtzz5cq/IiAp0 l5Ble2PsBf0mI4guq7e8IT1yRVHXJ2XqmaWEuJ5PsJ6g3qhfG9T0+4TwZzQIH3843j uxuPbGhDBF+qeqkydFaiIdu8bAFw3e+3bZSCRaPySikJM3CkOiWYdngsYUJbWo9MNa /6XQ31el9F1JbtUitv7yDwYihRFuhFFvJJ7X6R4dXKwBEO92JQmy5GKAipEVIvSSQW 1NJG2v8VUCztQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 075/715] arm64: dts: qcom: sc8180x: Don't hold MDP core clock at FMAX Date: Sun, 24 Mar 2024 18:24:14 -0400 Message-ID: <20240324223455.1342824-76-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit 309b5774f45aafd002efdb2656673542419abd6f ] There's an OPP table to handle this, drop the permanent vote. Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231230-topic-8180_more_fixes-v1-6-93b5c10= 7ed43@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sc8180x.dtsi | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sc8180x.dtsi b/arch/arm64/boot/dts/qc= om/sc8180x.dtsi index 8f7f5b74cdb9f..3bb9d25b1dec6 100644 --- a/arch/arm64/boot/dts/qcom/sc8180x.dtsi +++ b/arch/arm64/boot/dts/qcom/sc8180x.dtsi @@ -2732,10 +2732,8 @@ mdss_mdp: mdp@ae01000 { "rot", "lut"; =20 - assigned-clocks =3D <&dispcc DISP_CC_MDSS_MDP_CLK>, - <&dispcc DISP_CC_MDSS_VSYNC_CLK>; - assigned-clock-rates =3D <460000000>, - <19200000>; + assigned-clocks =3D <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + assigned-clock-rates =3D <19200000>; =20 operating-points-v2 =3D <&mdp_opp_table>; power-domains =3D <&rpmhpd SC8180X_MMCX>; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0B2E5127B7E; Sun, 24 Mar 2024 22:36:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319775; cv=none; b=MAMVUV1cDTEF1jltObZj2N0WIguzo23nph0dZUEqmfDyw90wDOyZb7BP2/f03N32049dT7MbokhpwgVDOrLgIu43tggmcMb7gh9Vg61xchsDDWZW9mOEiWG9uNfedJGrIdjzqU5+qUxsUpG3nr+DIo03bdrtE9tkwjqsKFQAivU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319775; c=relaxed/simple; bh=Xck2m66cI9zOAz8cKRalWaRFNWvUQtCxJHs6BRohMG0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PozElwhd9zLJAlaebO9rwmQ82q8o3K0Mae8By/YApOWqhKHxlmAVh2YuAMAT+IDPykuM1urAQZ+qzG1aXoB0tLViAasJQbBaERXSkAoFdQSnuTkv+ZCeNwU3aQgX/iS0FdEmWR20ch+ZMjCX2HyyQuXbS8q0if7nZhnfrCeqjLI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tYPer1z9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tYPer1z9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49234C433B2; Sun, 24 Mar 2024 22:36:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319774; bh=Xck2m66cI9zOAz8cKRalWaRFNWvUQtCxJHs6BRohMG0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tYPer1z9Nb9w6QW6AL/uOSRjI9lO2T55iinMiHId/afWlseCb6J+81fpv3vakIaLB uKFcrU6LBBCqtbyV+0y0y25QkDKMkq9wrefT7FhhSteJTc+CF8yQtPeOvozP9E2RgO FOxBowhobcP4NyimsxapuLOYstFkf86+JNxkflIawti+xfyD8Fx0Kc4NWK7xpK8kAv kq3/AL2+Y4i+/rir7gQc69+PqfyYvAQxMexO9nss7rZSCPs3sw3ybHaxoGc5NlFHsb MEMyx/Kx0+xh4dtP7jeabieKMs4vpMITSiRQA2xR6L74INcM3KO+jyG0K8FUyyrU9M KU/TV4yOkYVVA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 076/715] arm64: dts: qcom: sc8180x: Require LOW_SVS vote for MMCX if DISPCC is on Date: Sun, 24 Mar 2024 18:24:15 -0400 Message-ID: <20240324223455.1342824-77-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit 6d9fb9e4c473cdfd2adca019b46d8e482105cae7 ] To ensure the PLLs are getting enough power, cast a vote with DISPCC so that MMCX is at least at LOW_SVS. Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231230-topic-8180_more_fixes-v1-7-93b5c10= 7ed43@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sc8180x.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/qcom/sc8180x.dtsi b/arch/arm64/boot/dts/qc= om/sc8180x.dtsi index 3bb9d25b1dec6..97c139d0399d4 100644 --- a/arch/arm64/boot/dts/qcom/sc8180x.dtsi +++ b/arch/arm64/boot/dts/qcom/sc8180x.dtsi @@ -3217,6 +3217,7 @@ dispcc: clock-controller@af00000 { "edp_phy_pll_link_clk", "edp_phy_pll_vco_div_clk"; power-domains =3D <&rpmhpd SC8180X_MMCX>; + required-opps =3D <&rpmhpd_opp_low_svs>; #clock-cells =3D <1>; #reset-cells =3D <1>; #power-domain-cells =3D <1>; --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF7BE128383; Sun, 24 Mar 2024 22:36:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319776; cv=none; b=o30QrhyC4Oh2U4rRvwcCEiUmM3PNWs9ksV5kFWbg75oNBtS+fYawA4Z7AcDRliVB+qRaQV9LwXkWImeGL6R1SlAxsnKBiYLk9P2z2/dSr3LL/2sb/fygGYkWeoIyl1Y8vjR/IjQzYPrSbUC0my2P+Xwu0ZR+PEuA3lvkTw+ncX4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319776; c=relaxed/simple; bh=vJGujO832JFLqHOAnflcavIqgqW+KvXTlKq+tz7Z5VQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oFOCfWKDCpxmRr6VTZRVqRHNUP5UFGoBK80tMbzrFOBJCRZp7ezD2TYaxpZ2S5rImgN3xGX9mtEhm2KklIgpCji3lqq08UZvMM26ipWa0QF0v6OnMidLrXnP9FOG8AtXGf61DbTRaBvgEHRyfLJmih64QfVMlwgvHrjLmG4c62o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=fail (0-bit key) header.d=kernel.org header.i=@kernel.org header.b=nJHKYjqp reason="key not found in DNS"; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=kernel.org header.i=@kernel.org header.b="nJHKYjqp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30123C433C7; Sun, 24 Mar 2024 22:36:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319775; bh=vJGujO832JFLqHOAnflcavIqgqW+KvXTlKq+tz7Z5VQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nJHKYjqpdxMhJ1tFv58iXZo2Hsx1KcRhgur/m2GrSrHq/GDxMwB6elkD8JtNWMeUw lHGdJbpFP37NjPcwq0Nw7cbV9omMJjEykGSd2Jbn5+1Ixj/jwuorzEtKX7G7PBTQFg K8xL13D1Dx+fNSp0AmN5Zb/EI04nvIKxD/7n2l97/8zePr7O2i6+oeSyYisAv36Q+Y 33wW5O5F7HU0jLtNXoZqCq45uLjoJvv4HmsTZulnsCJpBFm905uLg+HsgOWTwwth4T u3hsNmHBldEM9btN5/k9nO26u9EtKL2cecrv7aNzWQjHuPPOkdLM4e1RandCjiT/yw n76Dj6yr27TzA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 077/715] arm64: dts: qcom: sc8180x: Add missing CPU<->MDP_CFG path Date: Sun, 24 Mar 2024 18:24:16 -0400 Message-ID: <20240324223455.1342824-78-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit f0cd5a0ebd419bd151ed79baf5f044da797521ac ] To guarantee the required resources are enabled, describe the interconnect path between the MDSS and the CPU. Fixes: 494dec9b6f54 ("arm64: dts: qcom: sc8180x: Add display and gpu nodes") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231230-topic-8180_more_fixes-v1-8-93b5c10= 7ed43@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sc8180x.dtsi | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sc8180x.dtsi b/arch/arm64/boot/dts/qc= om/sc8180x.dtsi index 97c139d0399d4..960058624a2f5 100644 --- a/arch/arm64/boot/dts/qcom/sc8180x.dtsi +++ b/arch/arm64/boot/dts/qcom/sc8180x.dtsi @@ -2701,9 +2701,15 @@ mdss: mdss@ae00000 { interrupt-controller; #interrupt-cells =3D <1>; =20 - interconnects =3D <&mmss_noc MASTER_MDP_PORT0 0 &mc_virt SLAVE_EBI_CH0 = 0>, - <&mmss_noc MASTER_MDP_PORT1 0 &mc_virt SLAVE_EBI_CH0 0>; - interconnect-names =3D "mdp0-mem", "mdp1-mem"; + interconnects =3D <&mmss_noc MASTER_MDP_PORT0 QCOM_ICC_TAG_ALWAYS + &mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>, + <&mmss_noc MASTER_MDP_PORT1 QCOM_ICC_TAG_ALWAYS + &mc_virt SLAVE_EBI_CH0 QCOM_ICC_TAG_ALWAYS>, + <&gem_noc MASTER_AMPSS_M0 QCOM_ICC_TAG_ALWAYS + &config_noc SLAVE_DISPLAY_CFG QCOM_ICC_TAG_ALWAYS>; + interconnect-names =3D "mdp0-mem", + "mdp1-mem", + "cpu-cfg"; =20 iommus =3D <&apps_smmu 0x800 0x420>; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE55F128804; Sun, 24 Mar 2024 22:36:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319776; cv=none; b=JPoW57j3IadyQojEgLOfjnzaPEkDLBcic4oo5lC07Dg9Ca7cgjmLzsrq1DoJld0rtiZ8SCRN4q0SBClnfzmSCOLWPAqlKwmubQTBcCaokiMa/MjbX4cV+fvJOrgFx7992jTjUbnSyUJgNWKPzpzo7Kh0L91KCPFZ5J9njeNkkLc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319776; c=relaxed/simple; bh=32wK1excrnZ2+2QYO7wKdO5ch1mYAdkXBPu6cF7By2k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ELx1Uoexk5s+v6jHnXtdNCFeL1QXmdi158RA/ovhQ+Bc+BKO5MrV4UtAEM96ujGOXo6yHm1zWqHMy++c7FqTiqlkQkb9w9g3sChxMAoYHEVV2iwJzOrQxRKOKYnNG0Q1DlSP9hw0Wgn5YbvAMqRf11pP8BpT0aWH+2ca9Qb7wkU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MCojed3a; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MCojed3a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 15B85C433F1; Sun, 24 Mar 2024 22:36:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319776; bh=32wK1excrnZ2+2QYO7wKdO5ch1mYAdkXBPu6cF7By2k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MCojed3au9UL9QUE+8S80BaoReMast38JYP4pKkM0mCkw5D/gqTPwUNPcZ18bnLkm YAebdQ+Ngh1k9dNTdYqwoqeQC25ACEwmbJ7KOHfbDj01vMCkrzTNMvMmrVge2mAgKO ErEDQbuMJMY2PUygGNtUviKPmyPr/UtmrjOzZjgK2a+X7sm8kXKhyVdj1bnbENX6bB otmILbQWO4S4ZeBXokK6ble1XahbVjrjTrxUHGBYLLZX6uxcpL23C3UeWrV5uBNMHf mpZz9U+Hmw9UB4wvTjSqQqirm425tSEqZUCBka67pxUET7N7OnpqzcZTtrJYuE58Fg rYihkVD2/C1lw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 078/715] arm64: dts: qcom: sc8180x: Shrink aoss_qmp register space size Date: Sun, 24 Mar 2024 18:24:17 -0400 Message-ID: <20240324223455.1342824-79-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit dcad0590d1ea4278a55c30dd2903611a96111601 ] The AOSS_QMP region is overallocated, bleeding into space that's supposed to be used by other peripherals. Fix it. Fixes: 8575f197b077 ("arm64: dts: qcom: Introduce the SC8180x platform") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231230-topic-8180_more_fixes-v1-9-93b5c10= 7ed43@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sc8180x.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/sc8180x.dtsi b/arch/arm64/boot/dts/qc= om/sc8180x.dtsi index 960058624a2f5..c0dd44f146748 100644 --- a/arch/arm64/boot/dts/qcom/sc8180x.dtsi +++ b/arch/arm64/boot/dts/qcom/sc8180x.dtsi @@ -3262,7 +3262,7 @@ tsens1: thermal-sensor@c265000 { =20 aoss_qmp: power-controller@c300000 { compatible =3D "qcom,sc8180x-aoss-qmp", "qcom,aoss-qmp"; - reg =3D <0x0 0x0c300000 0x0 0x100000>; + reg =3D <0x0 0x0c300000 0x0 0x400>; interrupts =3D ; mboxes =3D <&apss_shared 0>; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BDB1312882C; Sun, 24 Mar 2024 22:36:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319777; cv=none; b=q2RJmtprufQAq3p+Z758PXV/IF0Ra4n80Qrf171ZqVTn/bqMiDWcCWwtr6D50nAcLneahP5Rne4JCOxPFl/Mdmx2hsWP/61i+ALBqLr8PDMx/opgZ3R7+A47ieu1Yumk7Fca6Y/LqmL7k0CqHE1+10pxhxzxzOVYShb8pqSaOvQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319777; c=relaxed/simple; bh=RiNJz9zlSFXEx8zYJSB1a4ND7aEOOQrZQdR/XEnpxN4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=B+3m2zueTwVTSpJWkDtZAjaEFgO9l9Bb2FiRww3AxcrD7nuT00YOjR+WTzLXDvnhkQ3UvEkpUn5nuudpJ1KO1IfKdQdmW3ve0B7/P0q573Gq4idq+PrYj/Gi22VpZBylgF1Lfc5oCxNXvPwLNRTJHt6JEAFXKTlIZR6hlXBW/cg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JXJB8BWJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JXJB8BWJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE9DDC433C7; Sun, 24 Mar 2024 22:36:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319777; bh=RiNJz9zlSFXEx8zYJSB1a4ND7aEOOQrZQdR/XEnpxN4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JXJB8BWJadwdBs+vSLJdprGNC94d8AaJqVrNUp7q0YWULHfRJko7ii7qftWICISh2 zfsuApO1k4V8IBAP5QtZeKr+l/jc2pbHvmAdboUqM9axfNdl/hG+SiFXw3Rnm+AmTT APFDBN6yS06fVzvn1h2gP5sqfck1aDffcoBWq75DpynQruk3ny0gWbFl2XGKtWkW4N WKzS6TflnJjaYlhWTIaXcgbH8Petsog92UWTEUASTCy/SG/rUkxUPemIoO+XoQCYT/ hSlVQ4QeiaNH0IrIE9l3I6ug8eXnMyPXJePnhXznlhnqBoQCQnZ/aDYoxyJMoNyMFG Ow4qSXuLRk8GA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Anastasia Belova , Viresh Kumar , Sasha Levin Subject: [PATCH 6.8 079/715] cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value Date: Sun, 24 Mar 2024 18:24:18 -0400 Message-ID: <20240324223455.1342824-80-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Anastasia Belova [ Upstream commit f661017e6d326ee187db24194cabb013d81bc2a6 ] cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return 0 in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for = Broadcom STB SoCs") Signed-off-by: Anastasia Belova Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/cpufreq/brcmstb-avs-cpufreq.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/cpufreq/brcmstb-avs-cpufreq.c b/drivers/cpufreq/brcmst= b-avs-cpufreq.c index 35fb3a559ea97..1a1857b0a6f48 100644 --- a/drivers/cpufreq/brcmstb-avs-cpufreq.c +++ b/drivers/cpufreq/brcmstb-avs-cpufreq.c @@ -481,6 +481,8 @@ static bool brcm_avs_is_firmware_loaded(struct private_= data *priv) static unsigned int brcm_avs_cpufreq_get(unsigned int cpu) { struct cpufreq_policy *policy =3D cpufreq_cpu_get(cpu); + if (!policy) + return 0; struct private_data *priv =3D policy->driver_data; =20 cpufreq_cpu_put(policy); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 202AD1292E3; Sun, 24 Mar 2024 22:36:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319779; cv=none; b=MKALo1B9EkEK4IKzCLqYnuYJ+RYo3hrYyqaodLFFBn7+HCoTa+NwRn3C2bSfUfcx3aNKBoi6oCopp3hAKuYt2ogvo/+ujx98ehphTAHRb+5t74CX0LhuCz4qMb4T49UQB/45c45O6vEvFg9G6EzeY1wjZT2n9ugCvFu4yzPuyGs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319779; c=relaxed/simple; bh=yo2Z2RP8nH+NEKT0SUBmtftPM/25colUC9zO2Yovi1w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=p0nGN5B5LpfUWCOx4jX5gowyzYWEiaWdLCDLkFV81buoKThaAYP7WVDCuAmzE0+TRh/tdzUSRcYS840z1hinzYmGVlPsYz1PtUiY3c5umpVZtVHp6F0qfEehqoMXRn1FdBlhUXKngi3EJeoWcDrD/qTVHLH5Z9N/9yFwxdETKh8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Py55qTDL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Py55qTDL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D9A25C43399; Sun, 24 Mar 2024 22:36:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319778; bh=yo2Z2RP8nH+NEKT0SUBmtftPM/25colUC9zO2Yovi1w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Py55qTDLnp4Cka0kJJBwaLJmzy59kAZAxgjV8nRDnzbKPntaqRHDHxPIHtNKpag92 4n6VSgb9L+PzB/a0se0PQWw6PGshpf6670O0NVuS7eL/Os7bESzHNNXLOZvGRact1Q LlmDD4BC2Mep9cTfyLAL0zJMIuXCP0PTMxaHTRQaO9amwCkPWuRFNxYIcZBEaptzMH LXKwVEVu2m0x4R8PxiUhyNN0qGdbp8heSsWMlMISQYYuPzzfNz5kcvJZDN9TdYtTd/ IN5lzMc2k1k7SUPMnO6yzLb7YE4CVFfK9gGULUccvZ2yTwJCWJRm7LB0f+sP+hV4hp JvfnIi52xfuUA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= , AngeloGioacchino Del Regno , Matthias Brugger , Viresh Kumar , Sasha Levin Subject: [PATCH 6.8 080/715] cpufreq: mediatek-hw: Wait for CPU supplies before probing Date: Sun, 24 Mar 2024 18:24:19 -0400 Message-ID: <20240324223455.1342824-81-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: N=C3=ADcolas F. R. A. Prado [ Upstream commit 788715b5f21c6455264fe00a1779e61bec407fe2 ] Before proceeding with the probe and enabling frequency scaling for the CPUs, make sure that all supplies feeding the CPUs have probed. This fixes an issue observed on MT8195-Tomato where if the mediatek-cpufreq-hw driver enabled the hardware (by writing to REG_FREQ_ENABLE) before the SPMI controller driver (spmi-mtk-pmif), behind which lies the big CPU supply, probed the platform would hang shortly after with "rcu: INFO: rcu_preempt detected stalls on CPUs/tasks" being printed in the log. Fixes: 4855e26bcf4d ("cpufreq: mediatek-hw: Add support for CPUFREQ HW") Signed-off-by: N=C3=ADcolas F. R. A. Prado Reviewed-by: AngeloGioacchino Del Regno Reviewed-by: Matthias Brugger Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/cpufreq/mediatek-cpufreq-hw.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/mediatek-cpufreq-hw.c b/drivers/cpufreq/mediat= ek-cpufreq-hw.c index d46afb3c00923..a1aa9385980ae 100644 --- a/drivers/cpufreq/mediatek-cpufreq-hw.c +++ b/drivers/cpufreq/mediatek-cpufreq-hw.c @@ -13,6 +13,7 @@ #include #include #include +#include #include =20 #define LUT_MAX_ENTRIES 32U @@ -300,7 +301,23 @@ static struct cpufreq_driver cpufreq_mtk_hw_driver =3D= { static int mtk_cpufreq_hw_driver_probe(struct platform_device *pdev) { const void *data; - int ret; + int ret, cpu; + struct device *cpu_dev; + struct regulator *cpu_reg; + + /* Make sure that all CPU supplies are available before proceeding. */ + for_each_possible_cpu(cpu) { + cpu_dev =3D get_cpu_device(cpu); + if (!cpu_dev) + return dev_err_probe(&pdev->dev, -EPROBE_DEFER, + "Failed to get cpu%d device\n", cpu); + + cpu_reg =3D devm_regulator_get_optional(cpu_dev, "cpu"); + if (IS_ERR(cpu_reg)) + return dev_err_probe(&pdev->dev, PTR_ERR(cpu_reg), + "CPU%d regulator get failed\n", cpu); + } + =20 data =3D of_device_get_match_data(&pdev->dev); if (!data) --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 614D0129A68; Sun, 24 Mar 2024 22:36:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319780; cv=none; b=sxh4/qxBlthx1jHkoZXV29H4+rVrDgVwV+RnW9iFfd0a/lK2IIizDaChS1+CYsjSghpDdec0lvZ2urfYHXz2syG3loFH93bGTnolnQ8JAuyeqMva3+/MtP1TYmkCfn3pl1GCRuVQIn1E5QKjuceTiauQqotsGq/T90W/s1cahlg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319780; c=relaxed/simple; bh=D57pdJksZDNWerhEQsBg1nHrR5mUgawKpu8fiJ1v6ro=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NtiA/hEK/PZwq7nO4NkRDyZnHU0ZxF1IkMoFPCp7LTcnOLXef1dkPpmc06c0imyDjFzNnhRQWxf8SggJ/NpyHu9ZL0sAoEnTzz+PLIYtpilcl7DhNy78Cd9HFf8+hxqadAgAJfiLwUL4uh8dk4JaTtFrUEavJo1FCBjlq9fN5vk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PN4g1ghd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PN4g1ghd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE7F9C433F1; Sun, 24 Mar 2024 22:36:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319779; bh=D57pdJksZDNWerhEQsBg1nHrR5mUgawKpu8fiJ1v6ro=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PN4g1ghdsv8GUxsHW50QHBIrH8eOinGnrFR6odlIZbL9UxLiHQtB0tFTfRz3tPR9u 9+Ic+EsMc/kKVGz91iFRrmEhR7lsMTafOkP1MTphdO8Svp5wA/SZ7FZkXcGNADftjB L92KHvCGsxbT5lXzvuy+aG+BMVAG8xwFw5lJPNawge8ozZMyuN8NZTaLFnARb/M9z5 ShqHwqjLjOTuw785dr5zXPFr9TjCYbhDKyo3SRGHrYNRM2iIGCT0FeWlwLPUzImER6 axzZlFCjhnLwvKYw7znUF8vPUdBgxFjOcYEGD8/UXJEv390iqp6oBxpRLlcW+Ua/2j BhUOVmgbB4Izg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , Guillaume Nault , Kuniyuki Iwashima , Willem de Bruijn , Paolo Abeni , Sasha Levin Subject: [PATCH 6.8 081/715] sock_diag: annotate data-races around sock_diag_handlers[family] Date: Sun, 24 Mar 2024 18:24:20 -0400 Message-ID: <20240324223455.1342824-82-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit efd402537673f9951992aea4ef0f5ff51d858f4b ] __sock_diag_cmd() and sock_diag_bind() read sock_diag_handlers[family] without a lock held. Use READ_ONCE()/WRITE_ONCE() annotations to avoid potential issues. Fixes: 8ef874bfc729 ("sock_diag: Move the sock_ code to net/core/") Signed-off-by: Eric Dumazet Reviewed-by: Guillaume Nault Reviewed-by: Kuniyuki Iwashima Reviewed-by: Willem de Bruijn Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/core/sock_diag.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/net/core/sock_diag.c b/net/core/sock_diag.c index b1e29e18d1d60..c53b731f2d672 100644 --- a/net/core/sock_diag.c +++ b/net/core/sock_diag.c @@ -193,7 +193,7 @@ int sock_diag_register(const struct sock_diag_handler *= hndl) if (sock_diag_handlers[hndl->family]) err =3D -EBUSY; else - sock_diag_handlers[hndl->family] =3D hndl; + WRITE_ONCE(sock_diag_handlers[hndl->family], hndl); mutex_unlock(&sock_diag_table_mutex); =20 return err; @@ -209,7 +209,7 @@ void sock_diag_unregister(const struct sock_diag_handle= r *hnld) =20 mutex_lock(&sock_diag_table_mutex); BUG_ON(sock_diag_handlers[family] !=3D hnld); - sock_diag_handlers[family] =3D NULL; + WRITE_ONCE(sock_diag_handlers[family], NULL); mutex_unlock(&sock_diag_table_mutex); } EXPORT_SYMBOL_GPL(sock_diag_unregister); @@ -227,7 +227,7 @@ static int __sock_diag_cmd(struct sk_buff *skb, struct = nlmsghdr *nlh) return -EINVAL; req->sdiag_family =3D array_index_nospec(req->sdiag_family, AF_MAX); =20 - if (sock_diag_handlers[req->sdiag_family] =3D=3D NULL) + if (READ_ONCE(sock_diag_handlers[req->sdiag_family]) =3D=3D NULL) sock_load_diag_module(req->sdiag_family, 0); =20 mutex_lock(&sock_diag_table_mutex); @@ -286,12 +286,12 @@ static int sock_diag_bind(struct net *net, int group) switch (group) { case SKNLGRP_INET_TCP_DESTROY: case SKNLGRP_INET_UDP_DESTROY: - if (!sock_diag_handlers[AF_INET]) + if (!READ_ONCE(sock_diag_handlers[AF_INET])) sock_load_diag_module(AF_INET, 0); break; case SKNLGRP_INET6_TCP_DESTROY: case SKNLGRP_INET6_UDP_DESTROY: - if (!sock_diag_handlers[AF_INET6]) + if (!READ_ONCE(sock_diag_handlers[AF_INET6])) sock_load_diag_module(AF_INET6, 0); break; } --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B002129A7D; Sun, 24 Mar 2024 22:36:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319781; cv=none; b=WR3p9FcpXqeNDeubCkiXPqa7OVcXdbEavC2OpifJ7UAzAEI4cRL9qdfuLWv7uMkTgZXDhUVHO/HT6+i+1aeglF2kH/IT2b7yry7vGIAdCuloVnhvAapHgGib/njYvqlnhs5ZDWyVwwMofEUkHV9GkIbZKDhUTFriBtMTK2Kuy9M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319781; c=relaxed/simple; bh=06FpT3mRKSJTpgTZHFDze+IrA6YW+8cePTPaBKN39AE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kedkT3XB1DpRtXqTWdcoz+Oc1rNDbas6IgUBDs8onNP1bwOn+G5qSvGD77/OLbESlpVOWOiGAgTc0b5MZrqUtObA6pnM5qoXKYt7G1JzFVv3Zd9h1ejWw8KSzqZiVdOUVAXwAAhJ19rvOr6MJI/A2RO01u5oDrbh7aU1dIB3vuE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y2ZyWgqa; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Y2ZyWgqa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2763EC433C7; Sun, 24 Mar 2024 22:36:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319781; bh=06FpT3mRKSJTpgTZHFDze+IrA6YW+8cePTPaBKN39AE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y2ZyWgqazo7hKazo4zZ2y32RDv5fd1BkQgm2Wm5cny98oZ6LQkrbFwIQfPeJ+BrSR /+6q2THE5S/+wyJs/OOLTD06ohlxcv1vrFArNHczBbVOCCu59dQ4s2u7GC85/e8TP2 YYrdX+eVGu/Avio95wUyyi0PdFP1i5xhcZTukG562vmCy0EmoYbaJ5lrvi/5eYEdzj L0LD+jkcQG+NfgbRDe668Eb7bRjRZzwRlltiibguqeS4s/XVn0THxo4i+uB1lYNWWb 1oCgbiI0kAwIWBXbuTXf+LAIIl7bg9rC2nGtkL/zUhLfZRDiwCL1M9BKzgRSoQSq4B +Y1LSGHWtp73w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , Guillaume Nault , Kuniyuki Iwashima , Willem de Bruijn , Paolo Abeni , Sasha Levin Subject: [PATCH 6.8 082/715] inet_diag: annotate data-races around inet_diag_table[] Date: Sun, 24 Mar 2024 18:24:21 -0400 Message-ID: <20240324223455.1342824-83-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit e50e10ae5d81ddb41547114bfdc5edc04422f082 ] inet_diag_lock_handler() reads inet_diag_table[proto] locklessly. Use READ_ONCE()/WRITE_ONCE() annotations to avoid potential issues. Fixes: d523a328fb02 ("[INET]: Fix inet_diag dead-lock regression") Signed-off-by: Eric Dumazet Reviewed-by: Guillaume Nault Reviewed-by: Kuniyuki Iwashima Reviewed-by: Willem de Bruijn Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/ipv4/inet_diag.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c index 8e6b6aa0579e1..9804e9608a5a0 100644 --- a/net/ipv4/inet_diag.c +++ b/net/ipv4/inet_diag.c @@ -57,7 +57,7 @@ static const struct inet_diag_handler *inet_diag_lock_han= dler(int proto) return ERR_PTR(-ENOENT); } =20 - if (!inet_diag_table[proto]) + if (!READ_ONCE(inet_diag_table[proto])) sock_load_diag_module(AF_INET, proto); =20 mutex_lock(&inet_diag_table_mutex); @@ -1503,7 +1503,7 @@ int inet_diag_register(const struct inet_diag_handler= *h) mutex_lock(&inet_diag_table_mutex); err =3D -EEXIST; if (!inet_diag_table[type]) { - inet_diag_table[type] =3D h; + WRITE_ONCE(inet_diag_table[type], h); err =3D 0; } mutex_unlock(&inet_diag_table_mutex); @@ -1520,7 +1520,7 @@ void inet_diag_unregister(const struct inet_diag_hand= ler *h) return; =20 mutex_lock(&inet_diag_table_mutex); - inet_diag_table[type] =3D NULL; + WRITE_ONCE(inet_diag_table[type], NULL); mutex_unlock(&inet_diag_table_mutex); } EXPORT_SYMBOL_GPL(inet_diag_unregister); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F177129A9D; Sun, 24 Mar 2024 22:36:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319782; cv=none; b=pQwI4nFVO+Slz7b8+cIsVPTr+xSq0AsmHvIOu/WMA/5eqysD4O2Agu3D5lV/fh8N6W3OG4OlQ6My4l5bDMoK+rjJ47NsJ6nedeJ9fvbG3ERjzxXIlLPL6zOQwp/8UkGrSBbEfeP2BFYrsuNb58Bu5uoI3M23NdlBzjvttYdDbSo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319782; c=relaxed/simple; bh=YSBl1ZyTFCq6mOKswwz7IpYku0zQ+dj1+kqQKD82ROc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=D22Q7gCkCWhdE39yGRXVFq+gjTet4oKZ+lpAwpeCuCjsXq0VY8pDN9UoGwTv+y4VEGm6rXfJ1vrrk1B7CGMik7IkxlOpPSDj48GOMXTlTYLYBYR+vbEmR9ZewtqC/GIz6Uvioxxmqp6BnJYaDzpI0G78ZjUDALKjjhfWevAone8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YD2x00qI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YD2x00qI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 51005C43394; Sun, 24 Mar 2024 22:36:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319782; bh=YSBl1ZyTFCq6mOKswwz7IpYku0zQ+dj1+kqQKD82ROc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YD2x00qI2Wa6poLYwq9HXMy/WnBy3O3ji6C0g7msux9P9Y88GS3F6HH8VwpZ7BT9H RIhAguaANMpjzE6b4A4i3DPsli37npB/iQoLnGqW/iTdgDX8UokpO+gHJRaWCd6i4b lIMVHaiTQCghCLb6AUqWxmjpSAOClYszx1oamhanDtyNQOgpNryQQo6QWbMyoAEnpP EDCOt6Uq6LwoyqXFkkIqL2iSbrHKqEMr2N4UJmMCbUxiz40geu6F16KuhQGkZImv43 HBHk14ofbum3eQK6Fr1kL3AOIq62gIBPgRQG4Md2VK7l1J7FTBzCgJZVvYhYyPMoF0 GgXeRalQDQ6fA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tiezhu Yang , Daniel Borkmann , Quentin Monnet , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 083/715] bpftool: Silence build warning about calloc() Date: Sun, 24 Mar 2024 18:24:22 -0400 Message-ID: <20240324223455.1342824-84-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Tiezhu Yang [ Upstream commit f5f30386c78105cba520e443a6a9ee945ec1d066 ] There exists the following warning when building bpftool: CC prog.o prog.c: In function =E2=80=98profile_open_perf_events=E2=80=99: prog.c:2301:24: warning: =E2=80=98calloc=E2=80=99 sizes specified with =E2= =80=98sizeof=E2=80=99 in the earlier argument and not in the later argument= [-Wcalloc-transposed-args] 2301 | sizeof(int), obj->rodata->num_cpu * obj->rodata->nu= m_metric); | ^~~ prog.c:2301:24: note: earlier argument should specify number of elements, l= ater size of each element Tested with the latest upstream GCC which contains a new warning option -Wcalloc-transposed-args. The first argument to calloc is documented to be number of elements in array, while the second argument is size of each element, just switch the first and second arguments of calloc() to silence the build warning, compile tested only. Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command") Signed-off-by: Tiezhu Yang Signed-off-by: Daniel Borkmann Reviewed-by: Quentin Monnet Link: https://lore.kernel.org/bpf/20240116061920.31172-1-yangtiezhu@loongso= n.cn Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/bpf/bpftool/prog.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c index feb8e305804fc..9cb42a3366c07 100644 --- a/tools/bpf/bpftool/prog.c +++ b/tools/bpf/bpftool/prog.c @@ -2298,7 +2298,7 @@ static int profile_open_perf_events(struct profiler_b= pf *obj) int map_fd; =20 profile_perf_events =3D calloc( - sizeof(int), obj->rodata->num_cpu * obj->rodata->num_metric); + obj->rodata->num_cpu * obj->rodata->num_metric, sizeof(int)); if (!profile_perf_events) { p_err("failed to allocate memory for perf_event array: %s", strerror(errno)); --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE24F12A163; Sun, 24 Mar 2024 22:36:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319783; cv=none; b=jdMVUXQar8iXlOTRKFZVbrxmOOicW/kmkf/+o4JEFfVf4G8KYKBwmHq/SZsF7YGFx9UVPd1/Id37NZWqBCkkJj8VPV7GUr9gQKhQAcx/cj4Qa2bwS0ZciNwIuXeH+xJcadibzpUbFW1SWFiZn66lPiZl+0Ch56Jvv5wdTyqQLAM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319783; c=relaxed/simple; bh=S5lSRSEl+8Ri8IPAHVMzY1VhWNuSPB/Hjn9uxUE1cn0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VxPLAnwK0+iSSsuvL2F5nyLkPnCzxBOfDeByinP53L75n4QRHKpBguPnX5cS+xFkGl7cCNNSsaodfwEwcVDvc/2GMv5Ype5rFOoq5XsyOOarxGnxdPNm3Vpjhyuj9QLiGSs6qwgP8EgVJ4OCfFoN3kgiqMPZPc0ogPPjQvERQNA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kltgbURj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kltgbURj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64B33C43390; Sun, 24 Mar 2024 22:36:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319783; bh=S5lSRSEl+8Ri8IPAHVMzY1VhWNuSPB/Hjn9uxUE1cn0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kltgbURjUKeboxIP1kBM8O1ZHWmCE/sqLWloRTlDeFhffeJ97j/43s2nTKPyaX1Pf p2McEbfHzcjcwkgIIVeP8ZbCN0KLUphB4LNvchyzgz6nqmVFJJLDiV+BCxvBh2Yd5k FNYE0SlvLlQyefmnVZ0KpSM+vJtLOTv6+0Otm29Wr7yBO5sUAj2SruFjLUXKWr4VKJ B9nbU94c78168yLbr+4Qq1251c1xpGC4pcYzI7MCvDFkE9pD3qVSoVTvCt4jHYcOQz mldvqBV5uYolCM6v7JczMHEblqht45cjJCmu+FAygghJRNPRjMv8RKRUTenGGTVkdW O4PtQLbJxQ05w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Artem Savkov , Daniel Borkmann , Yonghong Song , Jiri Olsa , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 084/715] selftests/bpf: Fix potential premature unload in bpf_testmod Date: Sun, 24 Mar 2024 18:24:23 -0400 Message-ID: <20240324223455.1342824-85-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Artem Savkov [ Upstream commit d177c1be06ce28aa8c8710ac55be1b5ad3f314c6 ] It is possible for bpf_kfunc_call_test_release() to be called from bpf_map_free_deferred() when bpf_testmod is already unloaded and perf_test_stuct.cnt which it tries to decrease is no longer in memory. This patch tries to fix the issue by waiting for all references to be dropped in bpf_testmod_exit(). The issue can be triggered by running 'test_progs -t map_kptr' in 6.5, but is obscured in 6.6 by d119357d07435 ("rcu-tasks: Treat only synchronous grace periods urgently"). Fixes: 65eb006d85a2 ("bpf: Move kernel test kfuncs to bpf_testmod") Signed-off-by: Artem Savkov Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Cc: Jiri Olsa Link: https://lore.kernel.org/bpf/82f55c0e-0ec8-4fe1-8d8c-b1de07558ad9@linu= x.dev Link: https://lore.kernel.org/bpf/20240110085737.8895-1-asavkov@redhat.com Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c b/tools/= testing/selftests/bpf/bpf_testmod/bpf_testmod.c index 91907b321f913..e7c9e1c7fde04 100644 --- a/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c +++ b/tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c @@ -2,6 +2,7 @@ /* Copyright (c) 2020 Facebook */ #include #include +#include #include #include #include @@ -544,6 +545,14 @@ static int bpf_testmod_init(void) =20 static void bpf_testmod_exit(void) { + /* Need to wait for all references to be dropped because + * bpf_kfunc_call_test_release() which currently resides in kernel= can + * be called after bpf_testmod is unloaded. Once release function = is + * moved into the module this wait can be removed. + */ + while (refcount_read(&prog_test_struct.cnt) > 1) + msleep(20); + return sysfs_remove_bin_file(kernel_kobj, &bin_attr_bpf_testmod_file); } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 00C4312AAC1; Sun, 24 Mar 2024 22:36:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319785; cv=none; b=O86Jn7EA5L3PQlxxTxEZDnzekNGD+/It3PXn/P19lZYIjgqrkCLEwulru048MNVUqzXbnOi3aGKu3Kdy5CXeNeUUl5zxM0MTCg8cavlo8tj0xk5mjXGxwXzaAcntnrUpFK+J8tJoiT8Nfxjtk6AZGSLxQNbfmOpLuwCOmaj4jh8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319785; c=relaxed/simple; bh=pX8VyodF2yR/udKJM+Zj5vWSK6HknsYK0yLQhEYqcg4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lh+sAbm8y1TzI3DHyqmtKA5ln2wkpRD+2nH8BEPbI4WtHf2R8Uu3eT9HSAeDHVwwOnDUObMJCKK0CFVEiTkEzGvCRrFDwLRe2N4udQDSJoHpfX1Cu5OxugOoj/y1WLkIy3f4MSyrNydq2K8dfJwd8Bt1RCHzsL8SPBgRn9yF+BY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lInKEKmH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lInKEKmH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9022BC433C7; Sun, 24 Mar 2024 22:36:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319784; bh=pX8VyodF2yR/udKJM+Zj5vWSK6HknsYK0yLQhEYqcg4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lInKEKmHwKX2XYr9JZ5DgYJYojgRSN9VwWEFN+RzsvGKeMNW+nWn3TKQqoZSzRt4Y KKHpRRvwQTQyqzsM3rL9MV9HbVLIoUmWmOdvCGans7QkGNw9dbep/HoDIkVXO6HVQX 3ITKdgD6PR2LPlUl6BL2eT7MCVf49bTueVVPQBGrKG8wznLB4+DxwIuyGlnmMqrhWI t8+72MBDWpsCI9lKfmBDQY52Rj93p0yaVsjDSXpVoKE9ucoWgxyNGVG6Mvyri+A29B 7QX+iP4P85JT3uglFOocvMJBeeHKPn1Y4ydqIiVBdMy14JDZBober+1Ctd9E3r91KM rMkJhCDPQkKVA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrey Grafin , Andrii Nakryiko , Yonghong Song , Hou Tao , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 085/715] libbpf: Apply map_set_def_max_entries() for inner_maps on creation Date: Sun, 24 Mar 2024 18:24:24 -0400 Message-ID: <20240324223455.1342824-86-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrey Grafin [ Upstream commit f04deb90e516e8e48bf8693397529bc942a9e80b ] This patch allows to auto create BPF_MAP_TYPE_ARRAY_OF_MAPS and BPF_MAP_TYPE_HASH_OF_MAPS with values of BPF_MAP_TYPE_PERF_EVENT_ARRAY by bpf_object__load(). Previous behaviour created a zero filled btf_map_def for inner maps and tried to use it for a map creation but the linux kernel forbids to create a BPF_MAP_TYPE_PERF_EVENT_ARRAY map with max_entries=3D0. Fixes: 646f02ffdd49 ("libbpf: Add BTF-defined map-in-map support") Signed-off-by: Andrey Grafin Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Acked-by: Hou Tao Link: https://lore.kernel.org/bpf/20240117130619.9403-1-conquistador@yandex= -team.ru Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/lib/bpf/libbpf.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index afd09571c482b..b8b00da629071 100644 --- a/tools/lib/bpf/libbpf.c +++ b/tools/lib/bpf/libbpf.c @@ -70,6 +70,7 @@ =20 static struct bpf_map *bpf_object__add_map(struct bpf_object *obj); static bool prog_is_subprog(const struct bpf_object *obj, const struct bpf= _program *prog); +static int map_set_def_max_entries(struct bpf_map *map); =20 static const char * const attach_type_name[] =3D { [BPF_CGROUP_INET_INGRESS] =3D "cgroup_inet_ingress", @@ -5172,6 +5173,9 @@ static int bpf_object__create_map(struct bpf_object *= obj, struct bpf_map *map, b =20 if (bpf_map_type__is_map_in_map(def->type)) { if (map->inner_map) { + err =3D map_set_def_max_entries(map->inner_map); + if (err) + return err; err =3D bpf_object__create_map(obj, map->inner_map, true); if (err) { pr_warn("map '%s': failed to create inner map: %d\n", --=20 2.43.0 From nobody Thu Dec 18 23:00:19 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F0C512AAE4; Sun, 24 Mar 2024 22:36:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319786; cv=none; b=IhLKhSCso1lPOy8iI3/hvfZdO3ScgBQshoTB50Dyn9BElo9IYXmjI/V87BD75Rx4q3W+414UzERER+llD9Jqb79x3j5qMAmZaef/wGs7YUqJd514+Q6L2x/ulFcnHZ7AQDOg8ZbMqFgDTOx4DjZxan2cWcxLhSA9dMUhQuM4uo8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319786; c=relaxed/simple; bh=xK0i92mfHWjtbHuvvYSsqP6XNXzKzuRNT/nlSFXVJtk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hII44sqdZdTBxP6ZyIvNQziOU5XZ97UfbOSkccQyMUykcmcQtmHGu+8POXXxVaivd1v9a4ZnNLiKOrcQiw+vGOJ9PYq7RzRkxjzYt3j81RRmil0IExZ4WxHfa6TFjK8Fmp2zXQMmuVIbFT4rlrvVb2NZLR6CEXpewmbB+Q81X40= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BmDYf7gw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BmDYf7gw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB621C433F1; Sun, 24 Mar 2024 22:36:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319785; bh=xK0i92mfHWjtbHuvvYSsqP6XNXzKzuRNT/nlSFXVJtk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BmDYf7gwqcHendEvHWHyzcE0Ic/HonxL4CfQndx9K05wW5POJpaIchDvT+6OdRIuV +HHcF67FyWIcJADd7KtoezzvHkFrqeAfrDtG+KlGfu6ur/z32wXdu6whYAuDWf6Eo6 GN+kaJk8cm94ff/SQzR+/SdmUWWThbxqM8tKmPdZ7UCS4D46c+HeeKyAr4sVZqpWbg TJvUDqv15468HQCDMwizPZG/KxSpZTto9ueMdPUgI2aXhox6BHcRb8UUOLhevZodOw VGAK20tw4l8gzIkUzJydtPUNMr4WkuLmGLLgJPbz8FhdvJ9iirCmNrTOWl0XyjsGVx 7WspQ3Nspt9MA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrey Grafin , Andrii Nakryiko , Yonghong Song , Hou Tao , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 086/715] selftest/bpf: Add map_in_maps with BPF_MAP_TYPE_PERF_EVENT_ARRAY values Date: Sun, 24 Mar 2024 18:24:25 -0400 Message-ID: <20240324223455.1342824-87-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrey Grafin [ Upstream commit 40628f9fff73adecac77a9aa390f8016724cad99 ] Check that bpf_object__load() successfully creates map_in_maps with BPF_MAP_TYPE_PERF_EVENT_ARRAY values. These changes cover fix in the previous patch "libbpf: Apply map_set_def_max_entries() for inner_maps on creation". A command line output is: - w/o fix $ sudo ./test_maps libbpf: map 'mim_array_pe': failed to create inner map: -22 libbpf: map 'mim_array_pe': failed to create: Invalid argument(-22) libbpf: failed to load object './test_map_in_map.bpf.o' Failed to load test prog - with fix $ sudo ./test_maps ... test_maps: OK, 0 SKIPPED Fixes: 646f02ffdd49 ("libbpf: Add BTF-defined map-in-map support") Signed-off-by: Andrey Grafin Signed-off-by: Andrii Nakryiko Acked-by: Yonghong Song Acked-by: Hou Tao Link: https://lore.kernel.org/bpf/20240117130619.9403-2-conquistador@yandex= -team.ru Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../selftests/bpf/progs/test_map_in_map.c | 26 +++++++++++++++++++ tools/testing/selftests/bpf/test_maps.c | 6 ++++- 2 files changed, 31 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/progs/test_map_in_map.c b/tools/te= sting/selftests/bpf/progs/test_map_in_map.c index f416032ba858b..b295f9b721bf8 100644 --- a/tools/testing/selftests/bpf/progs/test_map_in_map.c +++ b/tools/testing/selftests/bpf/progs/test_map_in_map.c @@ -21,6 +21,32 @@ struct { __type(value, __u32); } mim_hash SEC(".maps"); =20 +/* The following three maps are used to test + * perf_event_array map can be an inner + * map of hash/array_of_maps. + */ +struct perf_event_array { + __uint(type, BPF_MAP_TYPE_PERF_EVENT_ARRAY); + __type(key, __u32); + __type(value, __u32); +} inner_map0 SEC(".maps"); + +struct { + __uint(type, BPF_MAP_TYPE_ARRAY_OF_MAPS); + __uint(max_entries, 1); + __type(key, __u32); + __array(values, struct perf_event_array); +} mim_array_pe SEC(".maps") =3D { + .values =3D {&inner_map0}}; + +struct { + __uint(type, BPF_MAP_TYPE_HASH_OF_MAPS); + __uint(max_entries, 1); + __type(key, __u32); + __array(values, struct perf_event_array); +} mim_hash_pe SEC(".maps") =3D { + .values =3D {&inner_map0}}; + SEC("xdp") int xdp_mimtest0(struct xdp_md *ctx) { diff --git a/tools/testing/selftests/bpf/test_maps.c b/tools/testing/selfte= sts/bpf/test_maps.c index 767e0693df106..dfbab214f4d1c 100644 --- a/tools/testing/selftests/bpf/test_maps.c +++ b/tools/testing/selftests/bpf/test_maps.c @@ -1190,7 +1190,11 @@ static void test_map_in_map(void) goto out_map_in_map; } =20 - bpf_object__load(obj); + err =3D bpf_object__load(obj); + if (err) { + printf("Failed to load test prog\n"); + goto out_map_in_map; + } =20 map =3D bpf_object__find_map_by_name(obj, "mim_array"); if (!map) { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EEF4112AAEC; Sun, 24 Mar 2024 22:36:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319787; cv=none; b=pnenMjdJ6dJQSA579XlvnLTl5TuYbCzSFRko6/0kriwurC8YTaqoy4LRIm5623yT7f79YmAysM6OIqAFBXxyezWGi9DyK89W/AoF8E40Arv40FnT/bAVkXgScrMvX58MJE+acpxYshSu+hyj8BslZEn1X4BqPSqeggiailzss30= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319787; c=relaxed/simple; bh=PCOZYknRcewXzsIhOF0XD8bL6rrqEfRfHwALBDHzhnQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Esgp3egYLRfZGOSOUK3YYc71dPC2wHzTTTT0VUXAOrBlvaNp235bKd+dgSWT2xXlpszka583SUVTEDJtbkzgkQcMokM9+QRjolXoftiWFZtTeP9zOzKMQbhGOGhka7GGNS7P1BqDcqk82N41SO4ZFq1YoaxUGUotdr9WtiW8mPU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VV+wVb20; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VV+wVb20" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EAB22C433C7; Sun, 24 Mar 2024 22:36:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319786; bh=PCOZYknRcewXzsIhOF0XD8bL6rrqEfRfHwALBDHzhnQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VV+wVb20TPm9k7eW4yNETVN8/EVXnwkrJT90sL9Ugis0ahvYQ1Y1qlh0JgdgZm6N8 5SfljofD0UursDmS/5YLT5hm9A4lN2diKRrTDXVRS7kKbIlJBBaQAMg3sT+Twww8vT tTDXRE305GxCXKlNDuY3t+vAqfxIMdX0TnKf9MTU42IBW5D+dcH2U/3yp00sGwjgpd oNtBPxRllmOnr19TTYTi+L3ekGDtopXX0frZBK1AZdizYs3UKota0FB7oKawo/oPx8 +JpWwdkdN4C9GoB+366oO39Gglt+RVJLAEN5l465Zo3ZVLODw9cwHKV9i14gYoSw/J 6r2z72+BfF4mw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jiri Olsa , Yafang Shao , Quentin Monnet , Song Liu , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 087/715] bpftool: Fix wrong free call in do_show_link Date: Sun, 24 Mar 2024 18:24:26 -0400 Message-ID: <20240324223455.1342824-88-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jiri Olsa [ Upstream commit 2adb2e0fcdf3c6d8e28a5a9c33e458e1037ae5ad ] The error path frees wrong array, it should be ref_ctr_offsets. Acked-by: Yafang Shao Reviewed-by: Quentin Monnet Fixes: a7795698f8b6 ("bpftool: Add support to display uprobe_multi links") Signed-off-by: Jiri Olsa Acked-by: Song Liu Link: https://lore.kernel.org/r/20240119110505.400573-4-jolsa@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/bpf/bpftool/link.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c index cb46667a6b2e7..35b6859dd7c3d 100644 --- a/tools/bpf/bpftool/link.c +++ b/tools/bpf/bpftool/link.c @@ -977,7 +977,7 @@ static int do_show_link(int fd) cookies =3D calloc(count, sizeof(__u64)); if (!cookies) { p_err("mem alloc failed"); - free(cookies); + free(ref_ctr_offsets); free(offsets); close(fd); return -ENOMEM; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E6C0012B147; Sun, 24 Mar 2024 22:36:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319788; cv=none; b=rV24q7VHyKzTQ99FF1/H0KBoKsd+XcE/MzoHpZxcdmSDsMKbLYt9+ek0uS0PZUmbB78pAEWdpnVOlvSIXwjwauU4Df72kGKOpw/cxaeWzEn3mvpvn+86GwNbjHg5svd/XS2NhVeoIyjlvI7WcuZSAjdUnv1c292Lz0qS/+ILWAg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319788; c=relaxed/simple; bh=C3HRYMW5Znvaia7gAvlg0IcUGE4X37KAKyR3ou87898=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BAr/wcd+wc+StS7yqQQRaPv7mWBr1Denwe8TGLOLJtZo7yerjSvDYizd9mRY3hWbKnDA+4ZM0XHBNgyRudCaI85ktCdEWRWosmyMSGj5nTdsjD8AI17MFeQ3BpcHA2mNTUlevc9KUmNsAgQe8HOO2gbDQYBKMfpsI0K980TYgpE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dEM73VGQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dEM73VGQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D064C43390; Sun, 24 Mar 2024 22:36:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319787; bh=C3HRYMW5Znvaia7gAvlg0IcUGE4X37KAKyR3ou87898=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dEM73VGQrn7wCKWD2W+/Jk1+2DrH7id7CnHM4if9s+lCTlBmIuWDaGVJ0Ve0kbPCw zwordSVsFdN7NhlyGGOYGcXUiRMqzfTCHVUq7dMT7HfY1nkdICt1MG4/P344Jtu1jX ddhm5ZFllNg5du6b7FTZXg0tMGvSfoj0dp2VQQq9koU4P7O10BxVA8ZRoN4rR4j3U0 rtAwxhPaeiVpaKzsVf8iBs44b+7udn/AG2690PHEmw2eHGFabcZyZ3cOPdmpi6uA3M CygRQwZDtzjJ+z3V87tGRgNfqcPUHB+Jjyj7IotQLiYtcQvcKDotWqAY6UGQHVACW+ 18jVgbTkLYsmg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sriram R , Jeff Johnson , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 088/715] wifi: ath12k: Fix issues in channel list update Date: Sun, 24 Mar 2024 18:24:27 -0400 Message-ID: <20240324223455.1342824-89-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sriram R [ Upstream commit 67a48d937fac917947540c9f89630d472cd61fcb ] Currently, the logic used to select the 6 GHz band is incorrect, which may cause 6 GHz supported channels to not be updated properly. This is because the 6 GHz Max frequency supported by the driver is being compared to the Max frequency supported on the board. If in some cases, the 6 GHz Max frequency supported on the board is less than the defined 6 GHz Max frequency, all 6 GHz channels are disabled. To address this, compare the max frequency supported by the board to the defined 6 GHz Minimum frequency by the driver. Similarly, when a dual mac card supports both 6 GHz and 5 GHz radios, if the 5 GHz radio gets enumerated first before 6 GHz, the checks in ath12k_mac_setup_channels_rates() can cause the 5 GHz channels which were enabled earlier to get disabled when the 6 GHz channel list is updated. This is because the Min 6 GHz frequency defined in the driver is 5945 MHz, which should be 5925 MHz since channel 2 is not considered currently, but the firmware can pass 5925 MHz as the minimum. Hence, update the Min frequency supported by the driver to 5925 MHz. In addition, ensure that the channel list update to firmware updates only the channels that the current radio (ar) supports rather than considering the wiphy support. This would be required when multiple pdevs are supported in a wiphy and they support different ranges of frequencies or bands as in single wiphy support. Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00188-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SIL= ICONZ-3 Signed-off-by: Sriram R Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240117062628.8260-1-quic_srirrama@quicinc.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/ath/ath12k/core.h | 2 +- drivers/net/wireless/ath/ath12k/mac.c | 2 +- drivers/net/wireless/ath/ath12k/reg.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/= ath/ath12k/core.h index 8458dc292821a..01fb9b2ae4314 100644 --- a/drivers/net/wireless/ath/ath12k/core.h +++ b/drivers/net/wireless/ath/ath12k/core.h @@ -420,7 +420,7 @@ struct ath12k_sta { }; =20 #define ATH12K_MIN_5G_FREQ 4150 -#define ATH12K_MIN_6G_FREQ 5945 +#define ATH12K_MIN_6G_FREQ 5925 #define ATH12K_MAX_6G_FREQ 7115 #define ATH12K_NUM_CHANS 100 #define ATH12K_MAX_5G_CHAN 173 diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/a= th/ath12k/mac.c index 88cec54c6c2e6..f4e5dc363472b 100644 --- a/drivers/net/wireless/ath/ath12k/mac.c +++ b/drivers/net/wireless/ath/ath12k/mac.c @@ -7198,7 +7198,7 @@ static int ath12k_mac_setup_channels_rates(struct ath= 12k *ar, } =20 if (supported_bands & WMI_HOST_WLAN_5G_CAP) { - if (reg_cap->high_5ghz_chan >=3D ATH12K_MAX_6G_FREQ) { + if (reg_cap->high_5ghz_chan >=3D ATH12K_MIN_6G_FREQ) { channels =3D kmemdup(ath12k_6ghz_channels, sizeof(ath12k_6ghz_channels), GFP_KERNEL); if (!channels) { diff --git a/drivers/net/wireless/ath/ath12k/reg.c b/drivers/net/wireless/a= th/ath12k/reg.c index f924bc13ccff5..29542c46b0941 100644 --- a/drivers/net/wireless/ath/ath12k/reg.c +++ b/drivers/net/wireless/ath/ath12k/reg.c @@ -103,7 +103,7 @@ int ath12k_reg_update_chan_list(struct ath12k *ar) =20 bands =3D hw->wiphy->bands; for (band =3D 0; band < NUM_NL80211_BANDS; band++) { - if (!bands[band]) + if (!(ar->mac.sbands[band].channels && bands[band])) continue; =20 for (i =3D 0; i < bands[band]->n_channels; i++) { @@ -129,7 +129,7 @@ int ath12k_reg_update_chan_list(struct ath12k *ar) ch =3D arg->channel; =20 for (band =3D 0; band < NUM_NL80211_BANDS; band++) { - if (!bands[band]) + if (!(ar->mac.sbands[band].channels && bands[band])) continue; =20 for (i =3D 0; i < bands[band]->n_channels; i++) { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D456E43AA4; Sun, 24 Mar 2024 22:36:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319788; cv=none; b=mZlCGmI7iUePdHa4Qfbyy4ytE6Dk9h2mDZXHfTsaQdC9ESQHYLMQ2CBj5wrNrc2KmKHILRgLgdD6NIVpjwZYBVikQsHAvDFzX2pIp2ok55mQlckqX9j7ugwqwIkImbvWwSKdp595YXse+cftPmRhNU6o/36huqM6npHB0fawYGQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319788; c=relaxed/simple; bh=qFpUQqMP2OvlrWkLC22tIXBrzZPa6exUEWIiFlsA8jY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=paGlhMej9XBIPrLfWP2NI/8T5LvB7BeDzVn+qJpHBKwRpLarwgjvd07EkKIdDUYe69A24hNwOsNBqotJdN7UKYFahK+GPL+q402WbdVrzuiEB1wGDlMErM2g/hLIfGkFAGL+TkgRmO9855kIBg/2f3Y2eb0YpnWSI8IUgcwKZTg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=L0hR7w1x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="L0hR7w1x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1853CC43394; Sun, 24 Mar 2024 22:36:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319788; bh=qFpUQqMP2OvlrWkLC22tIXBrzZPa6exUEWIiFlsA8jY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=L0hR7w1xMZYXeP/rv6NcULpLQ+Q74m6/eMcNl11WAH5d3AbNuK1W00Dfs1vwoahQ9 amV7GUSUynAYyFMjvwtqWW2ur4C9pADpE8xfte0gK5o8k91Lughx3f9MlxHHUWG3yP 3llsrW2UQkDvZg3SDTjY6/GRq0A2iEBi9sNqI9kfmn53xYIP1Rmrb9gynrf8XeMrcs szPZ3QSuaRuyM4d7354d/mvcbKbzLY12qvsxCKaBXizd9Tk+5k+Dh044T18hV7pY0y fifgZ3xgRDPeOeTPtYb/osCsg08aU3Dvfuz3M09cPrub738YyJ4D+HsU9Tuyuqcjus ifwjWiIOORCyQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Martin KaFai Lau , Andrii Nakryiko , Sasha Levin Subject: [PATCH 6.8 089/715] selftests/bpf: Fix the flaky tc_redirect_dtime test Date: Sun, 24 Mar 2024 18:24:28 -0400 Message-ID: <20240324223455.1342824-90-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Martin KaFai Lau [ Upstream commit 177f1d083a19af58f4b1206d299ed73689249fd8 ] BPF CI has been reporting the tc_redirect_dtime test failing from time to time: test_inet_dtime:PASS:setns src 0 nsec (network_helpers.c:253: errno: No route to host) Failed to connect to server close_netns:PASS:setns 0 nsec test_inet_dtime:FAIL:connect_to_fd unexpected connect_to_fd: actual -1 < ex= pected 0 test_tcp_clear_dtime:PASS:tcp ip6 clear dtime ingress_fwdns_p100 0 nsec The connect_to_fd failure (EHOSTUNREACH) is from the test_tcp_clear_dtime() test and it is the very first IPv6 traffic after setting up all the links, addresses, and routes. The symptom is this first connect() is always slow. In my setup, it could take ~3s. After some tracing and tcpdump, the slowness is mostly spent in the neighbor solicitation in the "ns_fwd" namespace while the "ns_src" and "ns_dst" are fine. I forced the kernel to drop the neighbor solicitation messages. I can then reproduce EHOSTUNREACH. What actually happen could be: - the neighbor advertisement came back a little slow. - the "ns_fwd" namespace concluded a neighbor discovery failure and triggered the ndisc_error_report() =3D> ip6_link_failure() =3D> icmpv6_send(skb, ICMPV6_DEST_UNREACH, ICMPV6_ADDR_UNREACH, 0) - the client's connect() reports EHOSTUNREACH after receiving the ICMPV6_DEST_UNREACH message. The neigh table of both "ns_src" and "ns_dst" namespace has already been manually populated but not the "ns_fwd" namespace. This patch fixes it by manually populating the neigh table also in the "ns_fwd" namespace. Although the namespace configuration part had been existed before the tc_redirect_dtime test, still Fixes-tagging the patch when the tc_redirect_dtime test was added since it is the only test hitting it so far. Fixes: c803475fd8dd ("bpf: selftests: test skb->tstamp in redirect_neigh") Signed-off-by: Martin KaFai Lau Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20240120060518.3604920-1-martin.lau@linux= .dev Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/testing/selftests/bpf/prog_tests/tc_redirect.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/tools/testing/selftests/bpf/prog_tests/tc_redirect.c b/tools/t= esting/selftests/bpf/prog_tests/tc_redirect.c index 518f143c5b0fe..610887157fd85 100644 --- a/tools/testing/selftests/bpf/prog_tests/tc_redirect.c +++ b/tools/testing/selftests/bpf/prog_tests/tc_redirect.c @@ -188,6 +188,7 @@ static int netns_setup_links_and_routes(struct netns_se= tup_result *result) { struct nstoken *nstoken =3D NULL; char src_fwd_addr[IFADDR_STR_LEN+1] =3D {}; + char src_addr[IFADDR_STR_LEN + 1] =3D {}; int err; =20 if (result->dev_mode =3D=3D MODE_VETH) { @@ -208,6 +209,9 @@ static int netns_setup_links_and_routes(struct netns_se= tup_result *result) if (get_ifaddr("src_fwd", src_fwd_addr)) goto fail; =20 + if (get_ifaddr("src", src_addr)) + goto fail; + result->ifindex_src =3D if_nametoindex("src"); if (!ASSERT_GT(result->ifindex_src, 0, "ifindex_src")) goto fail; @@ -270,6 +274,13 @@ static int netns_setup_links_and_routes(struct netns_s= etup_result *result) SYS(fail, "ip route add " IP4_DST "/32 dev dst_fwd scope global"); SYS(fail, "ip route add " IP6_DST "/128 dev dst_fwd scope global"); =20 + if (result->dev_mode =3D=3D MODE_VETH) { + SYS(fail, "ip neigh add " IP4_SRC " dev src_fwd lladdr %s", src_addr); + SYS(fail, "ip neigh add " IP6_SRC " dev src_fwd lladdr %s", src_addr); + SYS(fail, "ip neigh add " IP4_DST " dev dst_fwd lladdr %s", MAC_DST); + SYS(fail, "ip neigh add " IP6_DST " dev dst_fwd lladdr %s", MAC_DST); + } + close_netns(nstoken); =20 /** setup in 'dst' namespace */ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB89012BE94; Sun, 24 Mar 2024 22:36:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319790; cv=none; b=MMBXmTvAqG0C3E7khJZZyv+x1qrSo3PCpY3ExYenlzpTKhrcaeobDYYnoiAH53i2WFQZjJesqe9zFJpWkdTTs3ZMnuBKwyeEOrPZmePbwVR+eckT0UEwY8PasGu8xFTIFU0raI3xSiAZEqCOqQ1RpjPaPV3FXqItExH9YwUxarw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319790; c=relaxed/simple; bh=K757j1h2gj/8YT/wZT3TO9lwrI+Py+jNR2IhmZioBqg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sFw1Ji7SsX0Rbcnep4eW/4mZ/Y2+/6eiX00IuoFb/KEn6zetiO2+4zv7UeLLxfuMJG9z8leZ4/w/2DHjmE0sokrdQ5VWKB3+8isa04AdXuaH0B+RDh/UAA1spkEToNMtzX0GjHijXALgeEqtAsaPDLhuI1Rt3UCIli/06Af0ZHQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KZUGYMM8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KZUGYMM8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EEC4FC433C7; Sun, 24 Mar 2024 22:36:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319789; bh=K757j1h2gj/8YT/wZT3TO9lwrI+Py+jNR2IhmZioBqg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KZUGYMM8v+8dPIYa5EiZBT5xohrlD4tPCpmAqISi24HTOibmS8XgJ4KjD1i1zay1c KbD82yE/nScCQIvD56HDNOBKypKpT48ja93J2T6DAM3wCE4gMCqYBlghVIBnXCbfkW KLjljs6opq3lGV8ZzQ2rhBs/3Np3UU1UWJa/8WY3OjPP4QcsT9HnJDY/HQCXBmksiV lRJocuToIjsnY1YCLWu7PSkopXulGQkjS83IBiCU9WXLpmUnckfhfz5tUHRia6NiHm 5zQ1NhtXOj/EmoDaLszSJ2vDXvslzjYJNtyRfRu7JHkFo13xA3pf2JBpB2//FZQX8a C3hfTaItvXdGA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Martin KaFai Lau , Andrii Nakryiko , Sasha Levin Subject: [PATCH 6.8 090/715] selftests/bpf: Wait for the netstamp_needed_key static key to be turned on Date: Sun, 24 Mar 2024 18:24:29 -0400 Message-ID: <20240324223455.1342824-91-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Martin KaFai Lau [ Upstream commit ce6f6cffaeaa0a3bcdafcae7fe03c68c3afae631 ] After the previous patch that speeded up the test (by avoiding neigh discovery in IPv6), the BPF CI occasionally hits this error: rcv tstamp unexpected pkt rcv tstamp: actual 0 =3D=3D expected 0 The test complains about the cmsg returned from the recvmsg() does not have the rcv timestamp. Setting skb->tstamp or not is controlled by a kernel static key "netstamp_needed_key". The static key is enabled whenever this is at least one sk with the SOCK_TIMESTAMP set. The test_redirect_dtime does use setsockopt() to turn on the SOCK_TIMESTAMP for the reading sk. In the kernel net_enable_timestamp() has a delay to enable the "netstamp_needed_key" when CONFIG_JUMP_LABEL is set. This potential delay is the likely reason for packet missing rcv timestamp occasionally. This patch is to create udp sockets with SOCK_TIMESTAMP set. It sends and receives some packets until the received packet has a rcv timestamp. It currently retries at most 5 times with 1s in between. This should be enough to wait for the "netstamp_needed_key". It then holds on to the socket and only closes it at the end of the test. This guarantees that the test has the "netstamp_needed_key" key turned on from the beginning. To simplify the udp sockets setup, they are sending/receiving packets in the same netns (ns_dst is used) and communicate over the "lo" dev. Hence, the patch enables the "lo" dev in the ns_dst. Fixes: c803475fd8dd ("bpf: selftests: test skb->tstamp in redirect_neigh") Signed-off-by: Martin KaFai Lau Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20240120060518.3604920-2-martin.lau@linux= .dev Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../selftests/bpf/prog_tests/tc_redirect.c | 79 ++++++++++++++++++- 1 file changed, 75 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/bpf/prog_tests/tc_redirect.c b/tools/t= esting/selftests/bpf/prog_tests/tc_redirect.c index 610887157fd85..dbe06aeaa2b27 100644 --- a/tools/testing/selftests/bpf/prog_tests/tc_redirect.c +++ b/tools/testing/selftests/bpf/prog_tests/tc_redirect.c @@ -291,6 +291,7 @@ static int netns_setup_links_and_routes(struct netns_se= tup_result *result) SYS(fail, "ip addr add " IP4_DST "/32 dev dst"); SYS(fail, "ip addr add " IP6_DST "/128 dev dst nodad"); SYS(fail, "ip link set dev dst up"); + SYS(fail, "ip link set dev lo up"); =20 SYS(fail, "ip route add " IP4_SRC "/32 dev dst scope global"); SYS(fail, "ip route add " IP4_NET "/16 dev dst scope global"); @@ -468,7 +469,7 @@ static int set_forwarding(bool enable) return 0; } =20 -static void rcv_tstamp(int fd, const char *expected, size_t s) +static int __rcv_tstamp(int fd, const char *expected, size_t s, __u64 *tst= amp) { struct __kernel_timespec pkt_ts =3D {}; char ctl[CMSG_SPACE(sizeof(pkt_ts))]; @@ -489,7 +490,7 @@ static void rcv_tstamp(int fd, const char *expected, si= ze_t s) =20 ret =3D recvmsg(fd, &msg, 0); if (!ASSERT_EQ(ret, s, "recvmsg")) - return; + return -1; ASSERT_STRNEQ(data, expected, s, "expected rcv data"); =20 cmsg =3D CMSG_FIRSTHDR(&msg); @@ -498,6 +499,12 @@ static void rcv_tstamp(int fd, const char *expected, s= ize_t s) memcpy(&pkt_ts, CMSG_DATA(cmsg), sizeof(pkt_ts)); =20 pkt_ns =3D pkt_ts.tv_sec * NSEC_PER_SEC + pkt_ts.tv_nsec; + if (tstamp) { + /* caller will check the tstamp itself */ + *tstamp =3D pkt_ns; + return 0; + } + ASSERT_NEQ(pkt_ns, 0, "pkt rcv tstamp"); =20 ret =3D clock_gettime(CLOCK_REALTIME, &now_ts); @@ -507,6 +514,60 @@ static void rcv_tstamp(int fd, const char *expected, s= ize_t s) if (ASSERT_GE(now_ns, pkt_ns, "check rcv tstamp")) ASSERT_LT(now_ns - pkt_ns, 5 * NSEC_PER_SEC, "check rcv tstamp"); + return 0; +} + +static void rcv_tstamp(int fd, const char *expected, size_t s) +{ + __rcv_tstamp(fd, expected, s, NULL); +} + +static int wait_netstamp_needed_key(void) +{ + int opt =3D 1, srv_fd =3D -1, cli_fd =3D -1, nretries =3D 0, err, n; + char buf[] =3D "testing testing"; + struct nstoken *nstoken; + __u64 tstamp =3D 0; + + nstoken =3D open_netns(NS_DST); + if (!nstoken) + return -1; + + srv_fd =3D start_server(AF_INET6, SOCK_DGRAM, "::1", 0, 0); + if (!ASSERT_GE(srv_fd, 0, "start_server")) + goto done; + + err =3D setsockopt(srv_fd, SOL_SOCKET, SO_TIMESTAMPNS_NEW, + &opt, sizeof(opt)); + if (!ASSERT_OK(err, "setsockopt(SO_TIMESTAMPNS_NEW)")) + goto done; + + cli_fd =3D connect_to_fd(srv_fd, TIMEOUT_MILLIS); + if (!ASSERT_GE(cli_fd, 0, "connect_to_fd")) + goto done; + +again: + n =3D write(cli_fd, buf, sizeof(buf)); + if (!ASSERT_EQ(n, sizeof(buf), "send to server")) + goto done; + err =3D __rcv_tstamp(srv_fd, buf, sizeof(buf), &tstamp); + if (!ASSERT_OK(err, "__rcv_tstamp")) + goto done; + if (!tstamp && nretries++ < 5) { + sleep(1); + printf("netstamp_needed_key retry#%d\n", nretries); + goto again; + } + +done: + if (!tstamp && srv_fd !=3D -1) { + close(srv_fd); + srv_fd =3D -1; + } + if (cli_fd !=3D -1) + close(cli_fd); + close_netns(nstoken); + return srv_fd; } =20 static void snd_tstamp(int fd, char *b, size_t s) @@ -843,11 +904,20 @@ static void test_tc_redirect_dtime(struct netns_setup= _result *setup_result) { struct test_tc_dtime *skel; struct nstoken *nstoken; - int err; + int hold_tstamp_fd, err; + + /* Hold a sk with the SOCK_TIMESTAMP set to ensure there + * is no delay in the kernel net_enable_timestamp(). + * This ensures the following tests must have + * non zero rcv tstamp in the recvmsg(). + */ + hold_tstamp_fd =3D wait_netstamp_needed_key(); + if (!ASSERT_GE(hold_tstamp_fd, 0, "wait_netstamp_needed_key")) + return; =20 skel =3D test_tc_dtime__open(); if (!ASSERT_OK_PTR(skel, "test_tc_dtime__open")) - return; + goto done; =20 skel->rodata->IFINDEX_SRC =3D setup_result->ifindex_src_fwd; skel->rodata->IFINDEX_DST =3D setup_result->ifindex_dst_fwd; @@ -892,6 +962,7 @@ static void test_tc_redirect_dtime(struct netns_setup_r= esult *setup_result) =20 done: test_tc_dtime__destroy(skel); + close(hold_tstamp_fd); } =20 static void test_tc_redirect_neigh_fib(struct netns_setup_result *setup_re= sult) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AAD7C12BEAA; Sun, 24 Mar 2024 22:36:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319790; cv=none; b=Z3fGXzSW+vig+KAvMgpYt2RFQzLi0bz0A+rxeHytrw1u0BTSBaKe1E8qyhoPq7V75VsyW1LULMGpaKd1eGfHQsZ5r0mdXX1Q7YejOwjwzPA02iD5gWgsJW9Kkh2wrp0OvbLXaOjNNeBy3840y/suw2HwyQmo3jRns3R0efP4PNU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319790; c=relaxed/simple; bh=tdPXBerBXov0spvfnNiuYzMsfFi3OFvV7DejymwhKRU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UDc7wjfvvsZBMeOPaB50rLtvMz89olEWV7p+ssjxbsWzyNf782fXTrupGLvirC9ncYxy/uwyo+0NDe9eVMzYqS9aZj4J80luLIuiHg3WCN47NrlOTRX7tBeLWPomGHsr1eKpOyVmOPt8ONEiApLK22a11O8w7YmyWp7MlE2w8og= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Kxe0SgyR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Kxe0SgyR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D15C8C433B1; Sun, 24 Mar 2024 22:36:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319790; bh=tdPXBerBXov0spvfnNiuYzMsfFi3OFvV7DejymwhKRU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Kxe0SgyRcQhmKr31ojXs7+HDR4RRt9HC7Z08qSW6Hm8qzIDQYb6lljEatsFPEbujd BBJrZEH9K3YGxXyu8ZMI657BDp2vjnndUHlSoomrbl4u99QjKAUcD6YdEdnWDbDxI4 wAsk7zLGvdtByK9FWQHfZspIej6l1QX8MHWi8Y/tZ8XbQSlj+/56PuS0uYPqGqbMJH shABi1M2VJp9lb1hVrgL0jYdNrFbok/cg0DKeDRa6cCOXiaNButq0HJzsI2ipRu+vG h3/4B+8uUxuF9xUBCC+pf2/sb4ZhA4XRnfmxl/VwjEokdH2GeaGprMleEwruIqkl/1 ozELmkTxu9SnA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benjamin Berg , Miri Korenblit , Johannes Berg , Sasha Levin Subject: [PATCH 6.8 091/715] wifi: cfg80211: add RNR with reporting AP information Date: Sun, 24 Mar 2024 18:24:30 -0400 Message-ID: <20240324223455.1342824-92-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benjamin Berg [ Upstream commit 4d1d6b3f45999b1ddde53831d639a67e2655285f ] If the reporting AP is part of the same MLD, then an entry in the RNR is required in order to discover it again from the BSS generated from the per-STA profile in the Multi-Link Probe Response. We need this because we do not have a direct concept of an MLD AP and just do the lookup from one to the other on the fly if needed. As such, we need to ensure that this lookup will work both ways. Fixes: 2481b5da9c6b ("wifi: cfg80211: handle BSS data contained in ML probe= responses") Signed-off-by: Benjamin Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240102213313.4cb3dbb1d84f.I7c74edec83c5d7598cdd5= 78929fd0876d67aef7f@changeid [roll in off-by-one fix and test updates from Benjamin] Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/wireless/scan.c | 135 ++++++++++++++++++++++++++++++++++++-- net/wireless/tests/scan.c | 36 +++++++++- 2 files changed, 163 insertions(+), 8 deletions(-) diff --git a/net/wireless/scan.c b/net/wireless/scan.c index 389a52c29bfc7..7c9dc52ed783e 100644 --- a/net/wireless/scan.c +++ b/net/wireless/scan.c @@ -2674,6 +2674,103 @@ cfg80211_tbtt_info_for_mld_ap(const u8 *ie, size_t = ielen, u8 mld_id, u8 link_id, return 0; } =20 +static struct element * +cfg80211_gen_reporter_rnr(struct cfg80211_bss *source_bss, bool is_mbssid, + bool same_mld, u8 link_id, u8 bss_change_count, + gfp_t gfp) +{ + const struct cfg80211_bss_ies *ies; + struct ieee80211_neighbor_ap_info ap_info; + struct ieee80211_tbtt_info_ge_11 tbtt_info; + u32 short_ssid; + const struct element *elem; + struct element *res; + + /* + * We only generate the RNR to permit ML lookups. For that we do not + * need an entry for the corresponding transmitting BSS, lets just skip + * it even though it would be easy to add. + */ + if (!same_mld) + return NULL; + + /* We could use tx_data->ies if we change cfg80211_calc_short_ssid */ + rcu_read_lock(); + ies =3D rcu_dereference(source_bss->ies); + + ap_info.tbtt_info_len =3D offsetofend(typeof(tbtt_info), mld_params); + ap_info.tbtt_info_hdr =3D + u8_encode_bits(IEEE80211_TBTT_INFO_TYPE_TBTT, + IEEE80211_AP_INFO_TBTT_HDR_TYPE) | + u8_encode_bits(0, IEEE80211_AP_INFO_TBTT_HDR_COUNT); + + ap_info.channel =3D ieee80211_frequency_to_channel(source_bss->channel->c= enter_freq); + + /* operating class */ + elem =3D cfg80211_find_elem(WLAN_EID_SUPPORTED_REGULATORY_CLASSES, + ies->data, ies->len); + if (elem && elem->datalen >=3D 1) { + ap_info.op_class =3D elem->data[0]; + } else { + struct cfg80211_chan_def chandef; + + /* The AP is not providing us with anything to work with. So + * make up a somewhat reasonable operating class, but don't + * bother with it too much as no one will ever use the + * information. + */ + cfg80211_chandef_create(&chandef, source_bss->channel, + NL80211_CHAN_NO_HT); + + if (!ieee80211_chandef_to_operating_class(&chandef, + &ap_info.op_class)) + goto out_unlock; + } + + /* Just set TBTT offset and PSD 20 to invalid/unknown */ + tbtt_info.tbtt_offset =3D 255; + tbtt_info.psd_20 =3D IEEE80211_RNR_TBTT_PARAMS_PSD_RESERVED; + + memcpy(tbtt_info.bssid, source_bss->bssid, ETH_ALEN); + if (cfg80211_calc_short_ssid(ies, &elem, &short_ssid)) + goto out_unlock; + + rcu_read_unlock(); + + tbtt_info.short_ssid =3D cpu_to_le32(short_ssid); + + tbtt_info.bss_params =3D IEEE80211_RNR_TBTT_PARAMS_SAME_SSID; + + if (is_mbssid) { + tbtt_info.bss_params |=3D IEEE80211_RNR_TBTT_PARAMS_MULTI_BSSID; + tbtt_info.bss_params |=3D IEEE80211_RNR_TBTT_PARAMS_TRANSMITTED_BSSID; + } + + tbtt_info.mld_params.mld_id =3D 0; + tbtt_info.mld_params.params =3D + le16_encode_bits(link_id, IEEE80211_RNR_MLD_PARAMS_LINK_ID) | + le16_encode_bits(bss_change_count, + IEEE80211_RNR_MLD_PARAMS_BSS_CHANGE_COUNT); + + res =3D kzalloc(struct_size(res, data, + sizeof(ap_info) + ap_info.tbtt_info_len), + gfp); + if (!res) + return NULL; + + /* Copy the data */ + res->id =3D WLAN_EID_REDUCED_NEIGHBOR_REPORT; + res->datalen =3D sizeof(ap_info) + ap_info.tbtt_info_len; + memcpy(res->data, &ap_info, sizeof(ap_info)); + memcpy(res->data + sizeof(ap_info), &tbtt_info, ap_info.tbtt_info_len); + + return res; + +out_unlock: + rcu_read_unlock(); + return NULL; +} + static void cfg80211_parse_ml_elem_sta_data(struct wiphy *wiphy, struct cfg80211_inform_single_bss_data *tx_data, @@ -2687,13 +2784,14 @@ cfg80211_parse_ml_elem_sta_data(struct wiphy *wiphy, .source_bss =3D source_bss, .bss_source =3D BSS_SOURCE_STA_PROFILE, }; + struct element *reporter_rnr =3D NULL; struct ieee80211_multi_link_elem *ml_elem; struct cfg80211_mle *mle; u16 control; u8 ml_common_len; - u8 *new_ie; + u8 *new_ie =3D NULL; struct cfg80211_bss *bss; - int mld_id; + u8 mld_id, reporter_link_id, bss_change_count; u16 seen_links =3D 0; const u8 *pos; u8 i; @@ -2715,8 +2813,14 @@ cfg80211_parse_ml_elem_sta_data(struct wiphy *wiphy, =20 ml_common_len =3D ml_elem->variable[0]; =20 - /* length + MLD MAC address + link ID info + BSS Params Change Count */ - pos =3D ml_elem->variable + 1 + 6 + 1 + 1; + /* length + MLD MAC address */ + pos =3D ml_elem->variable + 1 + 6; + + reporter_link_id =3D pos[0]; + pos +=3D 1; + + bss_change_count =3D pos[0]; + pos +=3D 1; =20 if (u16_get_bits(control, IEEE80211_MLC_BASIC_PRES_MED_SYNC_DELAY)) pos +=3D 2; @@ -2747,10 +2851,21 @@ cfg80211_parse_ml_elem_sta_data(struct wiphy *wiphy, if (!mle) return; =20 + /* No point in doing anything if there is no per-STA profile */ + if (!mle->sta_prof[0]) + goto out; + new_ie =3D kmalloc(IEEE80211_MAX_DATA_LEN, gfp); if (!new_ie) goto out; =20 + reporter_rnr =3D cfg80211_gen_reporter_rnr(source_bss, + u16_get_bits(control, + IEEE80211_MLC_BASIC_PRES_MLD_ID), + mld_id =3D=3D 0, reporter_link_id, + bss_change_count, + gfp); + for (i =3D 0; i < ARRAY_SIZE(mle->sta_prof) && mle->sta_prof[i]; i++) { const struct ieee80211_neighbor_ap_info *ap_info; enum nl80211_band band; @@ -2860,7 +2975,16 @@ cfg80211_parse_ml_elem_sta_data(struct wiphy *wiphy, =20 data.ielen +=3D sizeof(*ml_elem) + ml_common_len; =20 - /* TODO: Add an RNR containing only the reporting AP */ + if (reporter_rnr && (use_for & NL80211_BSS_USE_FOR_NORMAL)) { + if (data.ielen + sizeof(struct element) + + reporter_rnr->datalen > IEEE80211_MAX_DATA_LEN) + continue; + + memcpy(new_ie + data.ielen, reporter_rnr, + sizeof(struct element) + reporter_rnr->datalen); + data.ielen +=3D sizeof(struct element) + + reporter_rnr->datalen; + } =20 bss =3D cfg80211_inform_single_bss_data(wiphy, &data, gfp); if (!bss) @@ -2869,6 +2993,7 @@ cfg80211_parse_ml_elem_sta_data(struct wiphy *wiphy, } =20 out: + kfree(reporter_rnr); kfree(new_ie); kfree(mle); } diff --git a/net/wireless/tests/scan.c b/net/wireless/tests/scan.c index 77854161cd22b..f9ea44aee9952 100644 --- a/net/wireless/tests/scan.c +++ b/net/wireless/tests/scan.c @@ -2,7 +2,7 @@ /* * KUnit tests for inform_bss functions * - * Copyright (C) 2023 Intel Corporation + * Copyright (C) 2023-2024 Intel Corporation */ #include #include @@ -406,9 +406,27 @@ static struct inform_bss_ml_sta_case { const char *desc; int mld_id; bool sta_prof_vendor_elems; + bool include_oper_class; } inform_bss_ml_sta_cases[] =3D { - { .desc =3D "no_mld_id", .mld_id =3D 0, .sta_prof_vendor_elems =3D false = }, - { .desc =3D "mld_id_eq_1", .mld_id =3D 1, .sta_prof_vendor_elems =3D true= }, + { + .desc =3D "zero_mld_id", + .mld_id =3D 0, + .sta_prof_vendor_elems =3D false, + }, { + .desc =3D "zero_mld_id_with_oper_class", + .mld_id =3D 0, + .sta_prof_vendor_elems =3D false, + .include_oper_class =3D true, + }, { + .desc =3D "mld_id_eq_1", + .mld_id =3D 1, + .sta_prof_vendor_elems =3D true, + }, { + .desc =3D "mld_id_eq_1_with_oper_class", + .mld_id =3D 1, + .sta_prof_vendor_elems =3D true, + .include_oper_class =3D true, + }, }; KUNIT_ARRAY_PARAM_DESC(inform_bss_ml_sta, inform_bss_ml_sta_cases, desc) =20 @@ -515,6 +533,12 @@ static void test_inform_bss_ml_sta(struct kunit *test) skb_put_u8(input, 4); skb_put_data(input, "TEST", 4); =20 + if (params->include_oper_class) { + skb_put_u8(input, WLAN_EID_SUPPORTED_REGULATORY_CLASSES); + skb_put_u8(input, 1); + skb_put_u8(input, 81); + } + skb_put_u8(input, WLAN_EID_REDUCED_NEIGHBOR_REPORT); skb_put_u8(input, sizeof(rnr)); skb_put_data(input, &rnr, sizeof(rnr)); @@ -582,15 +606,21 @@ static void test_inform_bss_ml_sta(struct kunit *test) KUNIT_EXPECT_EQ(test, ies->tsf, tsf + le64_to_cpu(sta_prof.tsf_offset)); /* Resulting length should be: * SSID (inherited) + RNR (inherited) + vendor element(s) + + * operating class (if requested) + + * generated RNR (if MLD ID =3D=3D 0) + * MLE common info + MLE header and control */ if (params->sta_prof_vendor_elems) KUNIT_EXPECT_EQ(test, ies->len, 6 + 2 + sizeof(rnr) + 2 + 160 + 2 + 165 + + (params->include_oper_class ? 3 : 0) + + (!params->mld_id ? 22 : 0) + mle_basic_common_info.var_len + 5); else KUNIT_EXPECT_EQ(test, ies->len, 6 + 2 + sizeof(rnr) + 2 + 155 + + (params->include_oper_class ? 3 : 0) + + (!params->mld_id ? 22 : 0) + mle_basic_common_info.var_len + 5); rcu_read_unlock(); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1A6DE12BF16; Sun, 24 Mar 2024 22:36:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319792; cv=none; b=MdWdVpGiMmd8m+TA1pykoYSk0PJvK2JVYW63LLhz7+NTXT4ZEmEFprTcujPBBa7G5TxKZms1q/08NO3ipjaUuZ3Ly5Gx4Q/OFCxi9M4AR5VkbGzKwAEJHLCMK6zalbIVE4OScgNOPHlfMtRbAtFkirnhhj3Q6VXpnoyx92aqtzU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319792; c=relaxed/simple; bh=FWe9WRlEAvGjT19jcAwd238r8ebAAw8RYSXfaycOTi4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K4en68KYkJvqm20Stjn3s2ZlCQ4YppDcA91FRC+kjbQyjivpFC1eqUZ0Z4+08998epfQVMADvUTDxUXP8cLkrxpCLGiB8PTysI47m62T0npolzrr3syBeGfPSJHncG7KXAnpctcWQyLpCuHPG2DsGP+jIcVYkIcqOIan9kX9aGY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DX7AAySb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DX7AAySb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE8B9C43394; Sun, 24 Mar 2024 22:36:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319791; bh=FWe9WRlEAvGjT19jcAwd238r8ebAAw8RYSXfaycOTi4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DX7AAySbcDl6ynvue4E5RWH/Id+rg1JyYFX6+azWIDfo1wgiE2eFHwcEO2IG1RDIh RMjS8OF5sp3rGQnJmDOuWnem/YDbwNdWP10n0mZlHlDjvHi2exyOaSrrcSCIQ0T4+K Ksnvtl/CT/p4ktn50M8F4zr96P0kVGvOih/hucGEz5f5TVPfooLtSmuY/g7otw3sjA t2MIaa5agdKKGr4jxdx7qqszvSo/6ic0+i4/J+ZK5zDor66VGpnbM+WyRtfSiT2QHZ 3naRXf4OXKhqmDUEj8Vghc/rp076jHYpzVUvqdL+ubtCKXUrJiapkMtfwokCVA4mJz P0DJFjUfr2O2A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benjamin Berg , Ilan Peer , Miri Korenblit , Johannes Berg , Sasha Levin Subject: [PATCH 6.8 092/715] wifi: mac80211: use deflink and fix typo in link ID check Date: Sun, 24 Mar 2024 18:24:31 -0400 Message-ID: <20240324223455.1342824-93-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benjamin Berg [ Upstream commit e10322810ce0d0d4a5a319458c4e1e052c6fe9be ] This does not change anything effectively, but it is closer to what the code is trying to achieve here. i.e. select the link data if it is an MLD and fall back to using the deflink otherwise. Fixes: 0f99f0878350 ("wifi: mac80211: Print local link address during authe= ntication") Signed-off-by: Benjamin Berg Reviewed-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://msgid.link/20240111181514.4c4b1c40eb3c.I2771621dee328c6185365= 96b7e56232df42a79c8@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/mac80211/mlme.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c index 2022a26eb8811..20d863370796d 100644 --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -7523,10 +7523,10 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data= *sdata, if (err) goto err_clear; =20 - if (req->link_id > 0) + if (req->link_id >=3D 0) link =3D sdata_dereference(sdata->link[req->link_id], sdata); else - link =3D sdata_dereference(sdata->link[0], sdata); + link =3D &sdata->deflink; =20 if (WARN_ON(!link)) { err =3D -ENOLINK; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB9E912C531; Sun, 24 Mar 2024 22:36:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319792; cv=none; b=AlLuzKkOfInNoI8BSsTmOfIc3cI4geXLTaaLlbSvNE9tQO0J2rL6BiHjYUUTWIq86zvZrdw9N0g57jqF0zcUPFxCYlcTtSAft9lLGaw8LGwLR8NbCZGolERc9FizxSZr5DCNBy33CzSFwWU7bLfOuLzV3T/WsyEiJeoJWvhHUC8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319792; c=relaxed/simple; bh=SRhcAxzWDqvx+SkAN6oS+yUrqdVHya4jnt3WTg9eaMA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kjafXuSUf2Xj5KU1MzPIE33JIJvEnseXq62F7+UCtLRh+kkygCzlAp11wD06Ac7/+fH7GS5uRnhVT2G3MF8T8c4h/4u//dkVSQNwUPmAsBElZ6n4YejsS97gjKnAWSZpjgM5F4X75613CooVRpBAxyaZJblD5vcz43OJGigAhJ8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZA16R3jj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZA16R3jj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DEDFFC433F1; Sun, 24 Mar 2024 22:36:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319792; bh=SRhcAxzWDqvx+SkAN6oS+yUrqdVHya4jnt3WTg9eaMA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZA16R3jjIiZ/0GBvVIGFVY/ld/CKVMCvV4dbHlFEm5UnNVt/er9LXozE5gLJHbz+W kIsl1rYNdjZnwRuo51mi9BmATj37uxjfBTPa8GZBdJQy/1wjWpB1ofo50ytD+AayK6 79TRTR8bcO+xYj9kWrofg0TezVTBKRHXxMUmy913Bb0VN52bXi7Ly/9S7zUh4B5459 hrOkRA84tw95CzHR1njfI4o/zl+5RSJNm78ZEvRfdN8HnghHnxBn8Cmh2Q6GftH6Zj NwJsg7h2WMxG61394abgVy7E28wZ08y7RNPBLma7V1rOVLD9QJGfdOhPujLy+l+ifL EP1FrWug51GKw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Miri Korenblit , Gregory Greenman , Johannes Berg , Sasha Levin Subject: [PATCH 6.8 093/715] wifi: iwlwifi: change link id in time event to s8 Date: Sun, 24 Mar 2024 18:24:32 -0400 Message-ID: <20240324223455.1342824-94-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Miri Korenblit [ Upstream commit 6c8ce23854b66db94d88e0957e531cb074806c16 ] Link ID in time event data is -1 when the time event is cleared. Change the type of the link ID in the time event data structure and in the affected function from unsigned to signed. Fixes: 135065837310 ("wifi: iwlwifi: support link_id in SESSION_PROTECTION = cmd") Signed-off-by: Miri Korenblit Reviewed-by: Gregory Greenman Link: https://msgid.link/20240123200528.50d4941f946c.Iea990b118c69bc3e1eb61= c1d134c9d470b3a17ac@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/mvm/mvm.h | 2 +- drivers/net/wireless/intel/iwlwifi/mvm/time-event.c | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h b/drivers/net/wir= eless/intel/iwlwifi/mvm/mvm.h index 81dbef6947f55..fe0fa9ff533d7 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h +++ b/drivers/net/wireless/intel/iwlwifi/mvm/mvm.h @@ -121,7 +121,7 @@ struct iwl_mvm_time_event_data { * if the te is in the time event list or not (when id =3D=3D TE_MAX) */ u32 id; - u8 link_id; + s8 link_id; }; =20 /* Power management */ diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c b/drivers/= net/wireless/intel/iwlwifi/mvm/time-event.c index 2e653a417d626..98c64ae315e68 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c @@ -692,7 +692,7 @@ void iwl_mvm_protect_session(struct iwl_mvm *mvm, /* Determine whether mac or link id should be used, and validate the link = id */ static int iwl_mvm_get_session_prot_id(struct iwl_mvm *mvm, struct ieee80211_vif *vif, - u32 link_id) + s8 link_id) { struct iwl_mvm_vif *mvmvif =3D iwl_mvm_vif_from_mac80211(vif); int ver =3D iwl_fw_lookup_cmd_ver(mvm->fw, @@ -716,7 +716,7 @@ static int iwl_mvm_get_session_prot_id(struct iwl_mvm *= mvm, =20 static void iwl_mvm_cancel_session_protection(struct iwl_mvm *mvm, struct ieee80211_vif *vif, - u32 id, u32 link_id) + u32 id, s8 link_id) { int mac_link_id =3D iwl_mvm_get_session_prot_id(mvm, vif, link_id); struct iwl_mvm_session_prot_cmd cmd =3D { @@ -745,7 +745,7 @@ static bool __iwl_mvm_remove_time_event(struct iwl_mvm = *mvm, struct ieee80211_vif *vif =3D te_data->vif; struct iwl_mvm_vif *mvmvif; enum nl80211_iftype iftype; - unsigned int link_id; + s8 link_id; =20 if (!vif) return false; @@ -1297,7 +1297,7 @@ void iwl_mvm_schedule_session_protection(struct iwl_m= vm *mvm, struct iwl_mvm_time_event_data *te_data =3D &mvmvif->time_event_data; const u16 notif[] =3D { WIDE_ID(MAC_CONF_GROUP, SESSION_PROTECTION_NOTIF)= }; struct iwl_notification_wait wait_notif; - int mac_link_id =3D iwl_mvm_get_session_prot_id(mvm, vif, link_id); + int mac_link_id =3D iwl_mvm_get_session_prot_id(mvm, vif, (s8)link_id); struct iwl_mvm_session_prot_cmd cmd =3D { .id_and_color =3D cpu_to_le32(mac_link_id), .action =3D cpu_to_le32(FW_CTXT_ACTION_ADD), --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9CC6312C556; Sun, 24 Mar 2024 22:36:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319793; cv=none; b=laaDdGdBN4Tf2f5QumcU3ZBCh7U7hVaL5inWZkYgh6bTqoKjjmW8fWvJ5b8/bVHRsLNHvQVyhmyBa8Xj4SW7aacfnWTzBhaKNuwYwm1p9/ZXpYPrmE5vGlUlG8ZZzXLpj+avlyGHMFRE9zldZD8+pvFT2enQe4mVarsiTD2/5TM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319793; c=relaxed/simple; bh=i/ETv3Z0+14MObVPjWUndDksu7lvCqc1LjL8w6W1XSQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FJ707RAc4Mzx0YtQnXKwZoxRwD7GeXqfxFa7OnG9zxYdIPygrMQtc/55awkv8ZNbecWis2GuJaqAzSgQ9h/ZfjACIh/ubpP++WYl4X//eFg8qanQJDCVHGpySznjXXluGLp5ggze2kGnwOf8f7lIwbC6MQHNUKhdx+YFTpKS7t8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=giBgSok2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="giBgSok2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D9F50C43390; Sun, 24 Mar 2024 22:36:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319793; bh=i/ETv3Z0+14MObVPjWUndDksu7lvCqc1LjL8w6W1XSQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=giBgSok27Toy35vP9wk4bqOwljP42SUjO3LM+WTGCNZ7ngJxn8nO0GKJ23+GMuLS0 F1f73RV2z4UIuMpkdifUU1/fkINHQ3gvCEWpxTGOrjJz4B82zn7s/Ne0Y15nXhPeh4 Uu2Cvt1WmkIpCchysKCAtvoIzrA9tA8NCp2DK2L4ijQqzFaohn2Z1feY82CQ2JjEvA haMbftEjdwKfB2dZGOPVuXUIXaMJI2TzVX1ALoq/F0wbez5+VznTBttyay0/2QYDvQ PYzAymCQeKz77/wfIwqeilt7kj8AXvcEVoAJo76l7Sxjs7/TcbCwqaTRBhl91UtFXl 4Pu/O9LL9salg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kuniyuki Iwashima , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.8 094/715] af_unix: Annotate data-race of gc_in_progress in wait_for_unix_gc(). Date: Sun, 24 Mar 2024 18:24:33 -0400 Message-ID: <20240324223455.1342824-95-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kuniyuki Iwashima [ Upstream commit 31e03207119a535d0b0e3b3a7f91983aeb2cb14d ] gc_in_progress is changed under spin_lock(&unix_gc_lock), but wait_for_unix_gc() reads it locklessly. Let's use READ_ONCE(). Fixes: 5f23b734963e ("net: Fix soft lockups/OOM issues w/ unix garbage coll= ector") Signed-off-by: Kuniyuki Iwashima Link: https://lore.kernel.org/r/20240123170856.41348-2-kuniyu@amazon.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/unix/garbage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/unix/garbage.c b/net/unix/garbage.c index 2a81880dac7b7..027c86e804f8a 100644 --- a/net/unix/garbage.c +++ b/net/unix/garbage.c @@ -198,7 +198,7 @@ void wait_for_unix_gc(void) if (READ_ONCE(unix_tot_inflight) > UNIX_INFLIGHT_TRIGGER_GC && !READ_ONCE(gc_in_progress)) unix_gc(); - wait_event(unix_gc_wait, gc_in_progress =3D=3D false); + wait_event(unix_gc_wait, !READ_ONCE(gc_in_progress)); } =20 /* The external entry point: unix_gc() */ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 12ED112C807; Sun, 24 Mar 2024 22:36:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319795; cv=none; b=AasJcyM1JwcYg9f/1ncGNlc/XVJRV8u9t06F57YqUH+rsObZdaRtNTAR4z/ZcU7N9xzxcxDpxb/e6xptJVQIR1zhekfxT21Rlpnach2RDy48KdoCZyaBXT9EHVh/PEm3V6rWReiCAs53C6p0dbJ2UenQHdAdap022RhOZFTglgY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319795; c=relaxed/simple; bh=Blzv/RlEZdknSh9LaT2pxEkZECzLDfUTOqXdqZrDiug=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XO00UBJQMNEolIt4ko8WQ1NFPcADDuCDhkC70JUqRF1piHG/4ijh3f49QVMtlxg1bqlSBwdjPkwFlLkupGr/uveY2rwGSjAbSZQc0Tj8FrvexnNPb5INxxymnoNLc4ZPTCK22hd/f0CFldNIeTdDgRxPfHEVq5o6BQhK/5fK/oM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=i0u4BKhK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="i0u4BKhK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0F94C433F1; Sun, 24 Mar 2024 22:36:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319794; bh=Blzv/RlEZdknSh9LaT2pxEkZECzLDfUTOqXdqZrDiug=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i0u4BKhKGD78YF3eeZYZsKWubarnKhZ568PPDTWm+WFrCipKhi383pQNwWztdd6qv 5Pq95kPQ+zwNjAgP4O0Td6UfEJP4eA2ZIggln0g/sdaDws4SwXOmys62Dxx6HqU5Eg a4k1iohEKxziEEgRIgzskzKO9wSdkPZ3It2ohod1bFl7wN6i5DbvVIetM3Ze5Vr5YJ Yp8U0QeAzuZJgiMSRrH7KNvL/vIS9ihjBFBYt+BKYp8Y1Y/m1oSiZs0QJrAGBAkTbJ /d+IjdGI0yHedycYURcd2LPIFkSEXVNG6/gODWRC4o053B+X/R0mDrTQ50ugTFmIL3 85+AeHiX6ByiQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Krzysztof Kozlowski , Georgi Djakov , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 095/715] arm64: dts: qcom: sm8450: Add missing interconnects to serial Date: Sun, 24 Mar 2024 18:24:34 -0400 Message-ID: <20240324223455.1342824-96-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit 6e115b75b43bd12d4061e53c8ff175e387783d8a ] The serial ports did not have their interconnect paths specified when they were first introduced. Fix that. Fixes: 5188049c9b36 ("arm64: dts: qcom: Add base SM8450 DTSI") Fixes: f5837418479a ("arm64: dts: qcom: sm8450: add uart20 node") Reported-by: Krzysztof Kozlowski Suggested-by: Georgi Djakov Signed-off-by: Konrad Dybcio Reviewed-by: Krzysztof Kozlowski Tested-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240116-topic-8450serial-v1-1-b685e6a5ad78= @linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sm8450.dtsi | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qco= m/sm8450.dtsi index 01e4dfc4babd2..06f183ef8c78f 100644 --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi @@ -1028,6 +1028,12 @@ uart20: serial@894000 { pinctrl-names =3D "default"; pinctrl-0 =3D <&qup_uart20_default>; interrupts =3D ; + interconnects =3D <&clk_virt MASTER_QUP_CORE_2 QCOM_ICC_TAG_ALWAYS + &clk_virt SLAVE_QUP_CORE_2 QCOM_ICC_TAG_ALWAYS>, + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS + &config_noc SLAVE_QUP_2 QCOM_ICC_TAG_ALWAYS>; + interconnect-names =3D "qup-core", + "qup-config"; status =3D "disabled"; }; =20 @@ -1420,6 +1426,12 @@ uart7: serial@99c000 { pinctrl-names =3D "default"; pinctrl-0 =3D <&qup_uart7_tx>, <&qup_uart7_rx>; interrupts =3D ; + interconnects =3D <&clk_virt MASTER_QUP_CORE_2 QCOM_ICC_TAG_ALWAYS + &clk_virt SLAVE_QUP_CORE_2 QCOM_ICC_TAG_ALWAYS>, + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS + &config_noc SLAVE_QUP_2 QCOM_ICC_TAG_ALWAYS>; + interconnect-names =3D "qup-core", + "qup-config"; status =3D "disabled"; }; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 267EC46537; Sun, 24 Mar 2024 22:36:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319796; cv=none; b=kbZOQvfTN5yUmbcZZjW5tfXj8fGOwUfR7b4qwjt7CTfqG/JLTJHnPI1p1lpgTncV6Ay41ddHFakz0dDlap21PqNAG8Gm4+4cNJwqv6P/4eFUdu47pw2sflb7z8W7oA4p+LtbKoAuiR3pQ+P7pKRpN15Lg0OAsmFphB06O8IxKNA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319796; c=relaxed/simple; bh=mYG6uuvygBhyuJATiduM+s95bhxW+Profp/+8aCZrZ0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Sj7mbXPNdKAG6Ar5luNCBl+sZpFR4+kyVRS2aYCUNcnniE75h6i/khgeYr3wmSzW+mDOiZVIIASgjfOLCzyXPVp+xTTvCCuoKTl+Cy4EAPuKL1LFyaCvirNa4060xesWfc1YsYVPiuqDnODZw+go0e1uOSYV5brC2Jg9dcEpTag= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Gqjaj2Vt; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Gqjaj2Vt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA021C433C7; Sun, 24 Mar 2024 22:36:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319795; bh=mYG6uuvygBhyuJATiduM+s95bhxW+Profp/+8aCZrZ0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Gqjaj2VtPVzqfU3bfM6pB6PqjfNk9BfH661EW0eDqbN4HaxEWie/NMbI1k4Ho+Ncs yNmDaUx2DnYasqbY8oF9kurT50mb+brmPe5pCp8RD/XSHZt4GnDH3KOs+by2oegjyz 8G7xsW9XSD+xvggPvBYamvCf09+AwBXHuLFs5PJn/wwoHXkA3sBS0/KSEcD4S+U20D Yz88LrkInBSMYZFaKHGqKwbqt/1A16DAwoNMx/0MiO8NgXpNftV+zdg6r3Umqo5lkV bTI43KXafq5jbOBeZNbg6ik9AO4RzPZLaz6NX4lGjV/R6by9mGpb2KMP3n7HCgWYPJ T5EKy9CZKQ1aQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 096/715] soc: qcom: socinfo: rename PM2250 to PM4125 Date: Sun, 24 Mar 2024 18:24:35 -0400 Message-ID: <20240324223455.1342824-97-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dmitry Baryshkov [ Upstream commit 5155e48128826d0c5999dc9f47aa746df54da448 ] It seems, the only actual mentions of PM2250 can be found are related to the Qualcomm RB1 platform. However even RB1 schematics use PM4125 as a PMIC name. Rename PM2250 to PM4125 to follow the documentation. Fixes: 082f9bc60f33 ("soc: qcom: spmi-pmic: add more PMIC SUBTYPE IDs") Fixes: 112d96fd2927 ("soc: qcom: socinfo: Add some PMICs") Acked-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240128-pm2250-pm4125-rename-v2-1-d51987e9= f83a@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/soc/qcom/socinfo.c | 2 +- include/soc/qcom/qcom-spmi-pmic.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c index 6349a0debeb57..a980020ab854f 100644 --- a/drivers/soc/qcom/socinfo.c +++ b/drivers/soc/qcom/socinfo.c @@ -124,7 +124,7 @@ static const char *const pmic_models[] =3D { [50] =3D "PM8350B", [51] =3D "PMR735A", [52] =3D "PMR735B", - [55] =3D "PM2250", + [55] =3D "PM4125", [58] =3D "PM8450", [65] =3D "PM8010", [69] =3D "PM8550VS", diff --git a/include/soc/qcom/qcom-spmi-pmic.h b/include/soc/qcom/qcom-spmi= -pmic.h index 17a0a8c3d6560..a62d500a6fdaf 100644 --- a/include/soc/qcom/qcom-spmi-pmic.h +++ b/include/soc/qcom/qcom-spmi-pmic.h @@ -49,7 +49,7 @@ #define PMK8350_SUBTYPE 0x2f #define PMR735B_SUBTYPE 0x34 #define PM6350_SUBTYPE 0x36 -#define PM2250_SUBTYPE 0x37 +#define PM4125_SUBTYPE 0x37 =20 #define PMI8998_FAB_ID_SMIC 0x11 #define PMI8998_FAB_ID_GF 0x30 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98CA812CDA6; Sun, 24 Mar 2024 22:36:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319796; cv=none; b=OtyuODrnjs5cJz8JqkCeG5WNI2N6Jq/mlZ3cQh6Mvxdenr2P4/ts7Gv7QQGFGs9DNvc2oKgWVST6X2XeCMUjjiEtJs01uKl8NNP64E/gFzrRR0ONgs0v0wGR0GI6yMx8AzBcyhYbdKXmq7qzRfGIkyBPoJ5V9lTr8Mxz4BaowJc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319796; c=relaxed/simple; bh=RBVPrMoX2IbuTed5Qqc5/hGraWjdBztCcc693+RJwvU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OaEOQnH8BROClMlsrHpkwJV+PMZiMbDHvFPDv0tK0ftiAShKgj9QxGjfg4nouJZ76DVHYC2QnhYBc9Hk8CxndBwPXpNZmKxTCvrWNfK7lySPgkyQq1AzTUJ0LxyA36w+Df/z3076C2P5mqnwwCj4kJ+HfRwmOKRQCIkzhc3wudc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tR60MWxl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tR60MWxl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D68CEC43394; Sun, 24 Mar 2024 22:36:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319796; bh=RBVPrMoX2IbuTed5Qqc5/hGraWjdBztCcc693+RJwvU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tR60MWxlq0foMvpyADuoqyZ889GTWU9c4iWbVvAl6mpHS4dzRzCpVsB/+crRiQKsd gq4rmMZniWFViOnVWRQqAO2mvJ1t1whRvKOGlE+bNidISyoVrFaECr13dVcjPYapTX nxQchKfJZtFkjxvAc/HBy2HjlB14ETJH7ooESM+ueSkHhGeZuvf8ePSO52UbuKudFh OLzFrvrMBm/jii9SEQMRFBUUlBlp/agKpdzjvNeMCONpb1bki2DeXuRf3NGmpHPwrJ rms/jfuHCoGGgNDd4/xLhhZ2LVKisxem8D1B+ViGlm3Lu/30TtFLa5jxwM7DxjGOJm YumI4DVSuyQaw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luca Weiss , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 097/715] arm64: dts: qcom: sc7280: Add static properties to cryptobam Date: Sun, 24 Mar 2024 18:24:36 -0400 Message-ID: <20240324223455.1342824-98-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luca Weiss [ Upstream commit 40ec6a2817d927367461fb0335b42b0d494ff927 ] When the properties num-channels & qcom,num-ees are not specified, the driver tries to read the values from registers, but this read fails and resets the device if the interconnect from the qcom,qce node is not already active when that happens. Add the static properties to not touch any registers during probe, the rest of the time when the BAM is used by QCE then the interconnect will be active already. Fixes: d488f903a860 ("arm64: dts: qcom: sc7280: add QCrypto nodes") Signed-off-by: Luca Weiss Link: https://lore.kernel.org/r/20231229-sc7280-cryptobam-fixup-v1-1-bd8f68= 589b80@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sc7280.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qco= m/sc7280.dtsi index 83b5b76ba1794..ce0d24ee7eedb 100644 --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi @@ -2345,6 +2345,8 @@ cryptobam: dma-controller@1dc4000 { <&apps_smmu 0x4e6 0x0011>; qcom,ee =3D <0>; qcom,controlled-remotely; + num-channels =3D <16>; + qcom,num-ees =3D <4>; }; =20 crypto: crypto@1dfa000 { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 916C112D1E1; Sun, 24 Mar 2024 22:36:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319797; cv=none; b=M+QARm18X0w2LeqtthG8CB5Wg89Fnflr120/8ri4Jd/lP3UyrgUFK2FbkhvCMjr5CflD3z6rXXe1ZWI7pygoGVPrABDnMrL8hJ3wl3/Rpmt4FOlEsxLVWPDz/unL+lbRtoDxxoCm3YIR6VzFsaOvYZ77j0zDx0jnPoSQCqtVjRU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319797; c=relaxed/simple; bh=lVhF2tyAdyjMo5qbbEvNAsIr+Sohc3Mo7jrDyWXP6mc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CBZAnDYbba2CtP1FMVsSHseHwHFG3BHcNNqss/hYHRZtmc+vi4uP1e0Gl1EFgUnz2n312YNZ+FuzwAkHOLlBK1fEc7sSHpRSdlclMPm75sQ7pCYxNltXfLO/E24bWN5gaQEmZja1OC24Sp4uLVF4Yd7uqPWd+MUR9/pDxxk5lXE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Eqg9wvrO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Eqg9wvrO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD84CC433C7; Sun, 24 Mar 2024 22:36:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319797; bh=lVhF2tyAdyjMo5qbbEvNAsIr+Sohc3Mo7jrDyWXP6mc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Eqg9wvrOFj4nlko8v/CmXgy2A33p3d0Ro8ZcQOr7euT2/5vhXumBbd3OxDmPh+8AV qbSW0Ei2R35l9zwijsTi3xKAc4kvr4EFzTsqDBBMCbXitQXUR2+hDFko+U9T/CCD5E 4SkjfsY1HSpyDeG66qCdqcELE2+G6brrYl2l7I27PuLafdT2SNGEb1+fTS0I421H+/ DiXsTGttvjgoxaDL/2rqcFdGQDKdkO3nb1jgPISattp9H9/K93sKEdL8gDkwYDBmHc MRNo54ffW76eUSRsRp2u4u4OVw+SOLa0zpJL+4FwK5YCLyGtmTbzQxZRp26i45qORs Jnc8spwUa19tw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luca Weiss , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 098/715] arm64: dts: qcom: qcm6490-fairphone-fp5: Add missing reserved-memory Date: Sun, 24 Mar 2024 18:24:37 -0400 Message-ID: <20240324223455.1342824-99-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luca Weiss [ Upstream commit 5dbbe7e0a2b91ac5901ee188724a997004759171 ] It seems we also need to reserve a region of 81 MiB called "removed_mem" otherwise we can easily hit the following error with higher RAM usage: [ 1467.809274] Internal error: synchronous external abort: 00000000960000= 10 [#2] SMP Fixes: eee9602ad649 ("arm64: dts: qcom: qcm6490: Add device-tree for Fairph= one 5") Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231229-fp5-reserved-mem-v1-1-87bb818f1397= @fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm6= 4/boot/dts/qcom/qcm6490-fairphone-fp5.dts index 176898c9dbbd7..1e85c43a6fd14 100644 --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts @@ -82,6 +82,11 @@ cdsp_mem: cdsp@88f00000 { no-map; }; =20 + removed_mem: removed@c0000000 { + reg =3D <0x0 0xc0000000 0x0 0x5100000>; + no-map; + }; + rmtfs_mem: memory@f8500000 { compatible =3D "qcom,rmtfs-mem"; reg =3D <0x0 0xf8500000 0x0 0x600000>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9160712D206; Sun, 24 Mar 2024 22:36:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319798; cv=none; b=ZnTXItHPMJOBTi79HNPVQkqiCNhFXaCCN9X/3PtJcNaQlHuGF1AcqpTjFmXsDM2mJbNbOfjxikF92n/z5c+r+jZsH8Fplcr9Myy0YIW3OqbinVAEcWtIzPU52OtxFt2W0MmlJHB3B+FyMiVZ8ACC2LYbZYGfTWUgqCfErAuqHFw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319798; c=relaxed/simple; bh=oL72wGx3zwjeeKYeLuybUd//Og1bGXKWdISX0373VC0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZFejAIBujd0cj+OzcNlVtOe5MJis6+j20clrZMQM5WD+tmY6w8fgXw8yAQcwFKvPzHVoXoQrLWP/WE6eLvMLDJAfrKv6iQORufQ+0lJujMgMNMReLlFrVYrTutD8UKi6gPQp5BkCUpJM7+fCwWXTFycIYoQMRuxC+lNyfo9mj/A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ucC8I+KN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ucC8I+KN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B69FDC433A6; Sun, 24 Mar 2024 22:36:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319798; bh=oL72wGx3zwjeeKYeLuybUd//Og1bGXKWdISX0373VC0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ucC8I+KNsobTMe3csaQFnp1Oyxfg6nisAhujGSFxbk0ByHcZH286XDDPvP3qQGSod nUWnN75WYdKpU3IWV+n5d2VvYQshwXwU63GupkCi6eQuP+0bHJo13m6O1vqoXobPKb UIYckhyCmGngrBb+DF/YlXnzLZCezy/pWx2jyGp5Qykd0HTiERtPdTk2iOl3e7rQ4V y3PYLvAR6jUtHADWc/RLUHQ0WM08WR0kowpDeG7yEbVOkQ9RI2q6BbXvyDB1hK6l6Z PqLANNAbtXsnAqSOJUzZCaY+0yfrex7AXvGLwTj4DMT3TWtQONZ/abl4xUV92RdZJM i+eicMUHZNydw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Heidelberg , Luca Weiss , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 099/715] arm64: dts: qcom: sdm845-oneplus-common: improve DAI node naming Date: Sun, 24 Mar 2024 18:24:38 -0400 Message-ID: <20240324223455.1342824-100-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Heidelberg [ Upstream commit afe9867a0c0e10ba618c15d4ef6f8699872f6cc3 ] Make it easier to understand what the reg in those nodes is by using the constants provided by qcom,q6dsp-lpass-ports.h. Name nodes according to dt-binding expectations. Fix for ``` arch/arm64/boot/dts/qcom/sdm845-oneplus-enchilada.dtb: service@4: dais: Une= valuated properties are not allowed ('qi2s@22', 'qi2s@23' were unexpected) ``` Fixes: b7b734286856 ("arm64: dts: qcom: sdm845-oneplus-*: add audio devices= ") Signed-off-by: David Heidelberg Reviewed-by: Luca Weiss Link: https://lore.kernel.org/r/20231229200245.259689-1-david@ixit.cz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi b/arch/arm= 64/boot/dts/qcom/sdm845-oneplus-common.dtsi index e821103d49c0a..46e25c53829ad 100644 --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi @@ -508,13 +508,13 @@ led-1 { }; =20 &q6afedai { - qi2s@22 { - reg =3D <22>; + dai@22 { + reg =3D ; qcom,sd-lines =3D <1>; }; =20 - qi2s@23 { - reg =3D <23>; + dai@23 { + reg =3D ; qcom,sd-lines =3D <0>; }; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8F84E12D748; Sun, 24 Mar 2024 22:36:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319799; cv=none; b=TPgsFLQyz+/TPhAqA/dHys2ZazqGLDGX+8eyD0kkK2H2Y1P5/0djODUoQKWqOZCG/aPsFPS/rcmyq3T+HuzQD8AfqDJICxyoKasni5Jr/VLXoS3iP7gBUmrhKj6256a3wzNRyrLowdaCIt6jJUESkd8DcvALXsHwVm9mlFYR8AQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319799; c=relaxed/simple; bh=o8+OYAOS1Tf089+igt6V9qtzuWQuHbNGYmwkAGlL+cU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Zb+3WFXCu3ULtCPlMzmKhenieYFM9j5Lp0GMDmxdcStGNPbqjpuZWEDQwoF7SGjMTczr1cJyYTuWlBKsRyMfHJhiKEZHpc9v2TgmwwN/wR6dsmPfpPcLdU0kyPslDPr4yFiNPOP2rpaDqIUtMzKNAMIjhlOhZIIkXcrvFKYYIQM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QkeZupro; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QkeZupro" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB3CCC433F1; Sun, 24 Mar 2024 22:36:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319799; bh=o8+OYAOS1Tf089+igt6V9qtzuWQuHbNGYmwkAGlL+cU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QkeZupropQs29JnBgcyenZIQle8ByF0I7b0de4rCYDpq/+IcEmmfZGRo76gC4f/ij 4rXxIYd8gm+HPzIgekL5Yx1VVY1OeP+Ctd+1mkDvSWmc515BbV2XGEogGGo1kl0UsB koMikrS7WwTFZ5C/RUcAqi8SyrWHqVVKsp+VekI7tqkL9SzTmSfLx5sRBU0PYfHOeH SGn9Os1yJs0T5sGqYjOP78XDY/FGKOKF7D5yzm4RG7mMRMDiK+qL18qyhk/cPkXe0Y ecmyqTULGQ9TNlCYDyVOtw3Yap3XVARu/bFY2IDq2TUxQRIwhwfLx9B1DzwXW3EjPv yBw+6awJEO54Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 100/715] arm64: dts: qcom: rename PM2250 to PM4125 Date: Sun, 24 Mar 2024 18:24:39 -0400 Message-ID: <20240324223455.1342824-101-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dmitry Baryshkov [ Upstream commit 39e62f41c3ce210554cc054f345d4135ef4e587b ] It seems, the only actual mentions of PM2250 can be found are related to the Qualcomm RB1 platform. However even RB1 schematics use PM4125 as a PMIC name. Rename PM2250 to PM4125 to follow the documentation. Note, this doesn't change the compatible strings. There was a previous argument regarding renaming of compat strings. Fixes: c309b9a54039 ("arm64: dts: qcom: Add initial PM2250 device tree") Acked-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240128-pm2250-pm4125-rename-v2-2-d51987e9= f83a@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../dts/qcom/{pm2250.dtsi =3D> pm4125.dtsi} | 8 +- arch/arm64/boot/dts/qcom/qrb2210-rb1.dts | 78 +++++++++---------- 2 files changed, 43 insertions(+), 43 deletions(-) rename arch/arm64/boot/dts/qcom/{pm2250.dtsi =3D> pm4125.dtsi} (91%) diff --git a/arch/arm64/boot/dts/qcom/pm2250.dtsi b/arch/arm64/boot/dts/qco= m/pm4125.dtsi similarity index 91% rename from arch/arm64/boot/dts/qcom/pm2250.dtsi rename to arch/arm64/boot/dts/qcom/pm4125.dtsi index 5f1d15db5c993..d886a9e4b0918 100644 --- a/arch/arm64/boot/dts/qcom/pm2250.dtsi +++ b/arch/arm64/boot/dts/qcom/pm4125.dtsi @@ -19,7 +19,7 @@ pon@800 { compatible =3D "qcom,pm8916-pon"; reg =3D <0x800>; =20 - pm2250_pwrkey: pwrkey { + pm4125_pwrkey: pwrkey { compatible =3D "qcom,pm8941-pwrkey"; interrupts-extended =3D <&spmi_bus 0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>; linux,code =3D ; @@ -27,7 +27,7 @@ pm2250_pwrkey: pwrkey { bias-pull-up; }; =20 - pm2250_resin: resin { + pm4125_resin: resin { compatible =3D "qcom,pm8941-resin"; interrupts-extended =3D <&spmi_bus 0x0 0x8 1 IRQ_TYPE_EDGE_BOTH>; debounce =3D <15625>; @@ -43,11 +43,11 @@ rtc@6000 { interrupts-extended =3D <&spmi_bus 0x0 0x61 0x1 IRQ_TYPE_EDGE_RISING>; }; =20 - pm2250_gpios: gpio@c000 { + pm4125_gpios: gpio@c000 { compatible =3D "qcom,pm2250-gpio", "qcom,spmi-gpio"; reg =3D <0xc000>; gpio-controller; - gpio-ranges =3D <&pm2250_gpios 0 0 10>; + gpio-ranges =3D <&pm4125_gpios 0 0 10>; #gpio-cells =3D <2>; interrupt-controller; #interrupt-cells =3D <2>; diff --git a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts b/arch/arm64/boot/dts= /qcom/qrb2210-rb1.dts index aa53b6af6d9cb..64b2ab2862793 100644 --- a/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts +++ b/arch/arm64/boot/dts/qcom/qrb2210-rb1.dts @@ -7,7 +7,7 @@ =20 #include #include "qcm2290.dtsi" -#include "pm2250.dtsi" +#include "pm4125.dtsi" =20 / { model =3D "Qualcomm Technologies, Inc. Robotics RB1"; @@ -226,7 +226,7 @@ &mdss { }; =20 &mdss_dsi0 { - vdda-supply =3D <&pm2250_l5>; + vdda-supply =3D <&pm4125_l5>; status =3D "okay"; }; =20 @@ -239,7 +239,7 @@ &mdss_dsi0_phy { status =3D "okay"; }; =20 -&pm2250_resin { +&pm4125_resin { linux,code =3D ; status =3D "okay"; }; @@ -263,23 +263,23 @@ regulators { compatible =3D "qcom,rpm-pm2250-regulators"; vdd_s3-supply =3D <&vph_pwr>; vdd_s4-supply =3D <&vph_pwr>; - vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12-supply =3D <&pm2250_s3>; + vdd_l1_l2_l3_l5_l6_l7_l8_l9_l10_l11_l12-supply =3D <&pm4125_s3>; vdd_l4_l17_l18_l19_l20_l21_l22-supply =3D <&vph_pwr>; - vdd_l13_l14_l15_l16-supply =3D <&pm2250_s4>; + vdd_l13_l14_l15_l16-supply =3D <&pm4125_s4>; =20 /* * S1 - VDD_APC * S2 - VDD_CX */ =20 - pm2250_s3: s3 { + pm4125_s3: s3 { /* 0.4V-1.6625V -> 1.3V (Power tree requirements) */ regulator-min-microvolt =3D <1352000>; regulator-max-microvolt =3D <1352000>; regulator-boot-on; }; =20 - pm2250_s4: s4 { + pm4125_s4: s4 { /* 1.2V-2.35V -> 2.05V (Power tree requirements) */ regulator-min-microvolt =3D <2072000>; regulator-max-microvolt =3D <2072000>; @@ -288,7 +288,7 @@ pm2250_s4: s4 { =20 /* L1 - VDD_MX */ =20 - pm2250_l2: l2 { + pm4125_l2: l2 { /* LPDDR4X VDD2 */ regulator-min-microvolt =3D <1136000>; regulator-max-microvolt =3D <1136000>; @@ -296,7 +296,7 @@ pm2250_l2: l2 { regulator-boot-on; }; =20 - pm2250_l3: l3 { + pm4125_l3: l3 { /* LPDDR4X VDDQ */ regulator-min-microvolt =3D <616000>; regulator-max-microvolt =3D <616000>; @@ -304,14 +304,14 @@ pm2250_l3: l3 { regulator-boot-on; }; =20 - pm2250_l4: l4 { + pm4125_l4: l4 { /* max =3D 3.05V -> max =3D 2.7 to disable 3V signaling (SDHCI2) */ regulator-min-microvolt =3D <1800000>; regulator-max-microvolt =3D <2700000>; regulator-allow-set-load; }; =20 - pm2250_l5: l5 { + pm4125_l5: l5 { /* CSI/DSI */ regulator-min-microvolt =3D <1232000>; regulator-max-microvolt =3D <1232000>; @@ -319,7 +319,7 @@ pm2250_l5: l5 { regulator-boot-on; }; =20 - pm2250_l6: l6 { + pm4125_l6: l6 { /* DRAM PLL */ regulator-min-microvolt =3D <928000>; regulator-max-microvolt =3D <928000>; @@ -327,7 +327,7 @@ pm2250_l6: l6 { regulator-boot-on; }; =20 - pm2250_l7: l7 { + pm4125_l7: l7 { /* Wi-Fi CX/MX */ regulator-min-microvolt =3D <664000>; regulator-max-microvolt =3D <664000>; @@ -338,20 +338,20 @@ pm2250_l7: l7 { * L9 - VDD_LPI_MX */ =20 - pm2250_l10: l10 { + pm4125_l10: l10 { /* Wi-Fi RFA */ regulator-min-microvolt =3D <1304000>; regulator-max-microvolt =3D <1304000>; }; =20 - pm2250_l11: l11 { + pm4125_l11: l11 { /* GPS RF1 */ regulator-min-microvolt =3D <1000000>; regulator-max-microvolt =3D <1000000>; regulator-boot-on; }; =20 - pm2250_l12: l12 { + pm4125_l12: l12 { /* USB PHYs */ regulator-min-microvolt =3D <928000>; regulator-max-microvolt =3D <928000>; @@ -359,7 +359,7 @@ pm2250_l12: l12 { regulator-boot-on; }; =20 - pm2250_l13: l13 { + pm4125_l13: l13 { /* USB/QFPROM/PLLs */ regulator-min-microvolt =3D <1800000>; regulator-max-microvolt =3D <1800000>; @@ -367,7 +367,7 @@ pm2250_l13: l13 { regulator-boot-on; }; =20 - pm2250_l14: l14 { + pm4125_l14: l14 { /* SDHCI1 VQMMC */ regulator-min-microvolt =3D <1800000>; regulator-max-microvolt =3D <1800000>; @@ -376,7 +376,7 @@ pm2250_l14: l14 { regulator-always-on; }; =20 - pm2250_l15: l15 { + pm4125_l15: l15 { /* WCD/DSI/BT VDDIO */ regulator-min-microvolt =3D <1800000>; regulator-max-microvolt =3D <1800000>; @@ -385,38 +385,38 @@ pm2250_l15: l15 { regulator-boot-on; }; =20 - pm2250_l16: l16 { + pm4125_l16: l16 { /* GPS RF2 */ regulator-min-microvolt =3D <1800000>; regulator-max-microvolt =3D <1800000>; regulator-boot-on; }; =20 - pm2250_l17: l17 { + pm4125_l17: l17 { regulator-min-microvolt =3D <3000000>; regulator-max-microvolt =3D <3000000>; }; =20 - pm2250_l18: l18 { + pm4125_l18: l18 { /* VDD_PXn */ regulator-min-microvolt =3D <1800000>; regulator-max-microvolt =3D <1800000>; }; =20 - pm2250_l19: l19 { + pm4125_l19: l19 { /* VDD_PXn */ regulator-min-microvolt =3D <1800000>; regulator-max-microvolt =3D <1800000>; }; =20 - pm2250_l20: l20 { + pm4125_l20: l20 { /* SDHCI1 VMMC */ regulator-min-microvolt =3D <2400000>; regulator-max-microvolt =3D <3600000>; regulator-allow-set-load; }; =20 - pm2250_l21: l21 { + pm4125_l21: l21 { /* SDHCI2 VMMC */ regulator-min-microvolt =3D <2960000>; regulator-max-microvolt =3D <3300000>; @@ -424,7 +424,7 @@ pm2250_l21: l21 { regulator-boot-on; }; =20 - pm2250_l22: l22 { + pm4125_l22: l22 { /* Wi-Fi */ regulator-min-microvolt =3D <3312000>; regulator-max-microvolt =3D <3312000>; @@ -433,8 +433,8 @@ pm2250_l22: l22 { }; =20 &sdhc_1 { - vmmc-supply =3D <&pm2250_l20>; - vqmmc-supply =3D <&pm2250_l14>; + vmmc-supply =3D <&pm4125_l20>; + vqmmc-supply =3D <&pm4125_l14>; pinctrl-0 =3D <&sdc1_state_on>; pinctrl-1 =3D <&sdc1_state_off>; pinctrl-names =3D "default", "sleep"; @@ -446,8 +446,8 @@ &sdhc_1 { }; =20 &sdhc_2 { - vmmc-supply =3D <&pm2250_l21>; - vqmmc-supply =3D <&pm2250_l4>; + vmmc-supply =3D <&pm4125_l21>; + vqmmc-supply =3D <&pm4125_l4>; cd-gpios =3D <&tlmm 88 GPIO_ACTIVE_LOW>; pinctrl-0 =3D <&sdc2_state_on &sd_det_in_on>; pinctrl-1 =3D <&sdc2_state_off &sd_det_in_off>; @@ -518,8 +518,8 @@ &usb { }; =20 &usb_qmpphy { - vdda-phy-supply =3D <&pm2250_l12>; - vdda-pll-supply =3D <&pm2250_l13>; + vdda-phy-supply =3D <&pm4125_l12>; + vdda-pll-supply =3D <&pm4125_l13>; status =3D "okay"; }; =20 @@ -528,17 +528,17 @@ &usb_dwc3 { }; =20 &usb_hsphy { - vdd-supply =3D <&pm2250_l12>; - vdda-pll-supply =3D <&pm2250_l13>; - vdda-phy-dpdm-supply =3D <&pm2250_l21>; + vdd-supply =3D <&pm4125_l12>; + vdda-pll-supply =3D <&pm4125_l13>; + vdda-phy-dpdm-supply =3D <&pm4125_l21>; status =3D "okay"; }; =20 &wifi { - vdd-0.8-cx-mx-supply =3D <&pm2250_l7>; - vdd-1.8-xo-supply =3D <&pm2250_l13>; - vdd-1.3-rfa-supply =3D <&pm2250_l10>; - vdd-3.3-ch0-supply =3D <&pm2250_l22>; + vdd-0.8-cx-mx-supply =3D <&pm4125_l7>; + vdd-1.8-xo-supply =3D <&pm4125_l13>; + vdd-1.3-rfa-supply =3D <&pm4125_l10>; + vdd-3.3-ch0-supply =3D <&pm4125_l22>; qcom,ath10k-calibration-variant =3D "Thundercomm_RB1"; status =3D "okay"; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 03EED12D76F; Sun, 24 Mar 2024 22:36:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319801; cv=none; b=J/vQRhB3HtW1YLyiPKNQvlICt8sU0C5MRLfHjqNh7MLTE/2GwZv+tq1pI/GmEE9N73C7AxjCeFKtTICRW2mlEPFPTrWfHou7G6crXwUkd2z5aZD5fc6PB5g/dkI8lscS/540c2dujKTvt/+omvkVJXKVczKqKub1tWk90ESjK4A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319801; c=relaxed/simple; bh=2jaq6Nv6r4YCmGhbPVeZlY0UKTMbM3LoqcudLDvUkVM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=omvlCUE8j2ji7ZuyL08z6Uw8+yxj1dowXOd7XnAG2CP3XHHBwSSs22GrJLMB7OiJz00jtiNQHQHCvHqV6c2ebj5QNRqaow2+lJS6TUktNbx3pKmLG0Bx1gX6upSrlWKA9GewIQZhzauKrN0G7vV08T466+qLPcX8NyAJhrroiCE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=fail (0-bit key) header.d=kernel.org header.i=@kernel.org header.b=Xzk5XxjY reason="key not found in DNS"; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=kernel.org header.i=@kernel.org header.b="Xzk5XxjY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8832C433A6; Sun, 24 Mar 2024 22:36:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319800; bh=2jaq6Nv6r4YCmGhbPVeZlY0UKTMbM3LoqcudLDvUkVM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Xzk5XxjYxEZp/ZcjinApYChrPkvo3LTITPlrpjD5NJt5EAW34Yzqo0fYJsGAj+rFF 9udgBqRawTo6jBN+fuqk1p4AGBuGu67yCh583qRHjgKgkebjeajVkKcZyCkPMaoqnN FIwZ+lPR7sGvLhbLbpm4AZD2KJ5NyAorjVGZ+qlfSantIao9brw3RaDj6XChPeWmlM TNQlbpVQhRVATQmSsG/f3eGIkuuxvpr52Fz81mn/6ojN6tOl0Ja8zzPrX4UocHKxF8 RXobDxCLVBc3AEo/84Imex5jiuxvU9FABytz1KbHhLIJFq/eym+1clyIvfmdhLRysi +OeuoQAvw6ISA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= , "kernelci . org bot" , AngeloGioacchino Del Regno , Viresh Kumar , Sasha Levin Subject: [PATCH 6.8 101/715] cpufreq: mediatek-hw: Don't error out if supply is not found Date: Sun, 24 Mar 2024 18:24:40 -0400 Message-ID: <20240324223455.1342824-102-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: N=C3=ADcolas F. R. A. Prado [ Upstream commit eaffb10b51bf74415c9252fd8fb4dd77122501ee ] devm_regulator_get_optional() returns -ENODEV if no supply can be found. By introducing its usage, commit 788715b5f21c ("cpufreq: mediatek-hw: Wait for CPU supplies before probing") caused the driver to fail probe if no supply was present in any of the CPU DT nodes. Use devm_regulator_get() instead since the CPUs do require supplies even if not described in the DT. It will gracefully return a dummy regulator if none is found in the DT node, allowing probe to succeed. Fixes: 788715b5f21c ("cpufreq: mediatek-hw: Wait for CPU supplies before pr= obing") Reported-by: kernelci.org bot Closes: https://linux.kernelci.org/test/case/id/65b0b169710edea22852a3fa/ Signed-off-by: N=C3=ADcolas F. R. A. Prado Reviewed-by: AngeloGioacchino Del Regno Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/cpufreq/mediatek-cpufreq-hw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/cpufreq/mediatek-cpufreq-hw.c b/drivers/cpufreq/mediat= ek-cpufreq-hw.c index a1aa9385980ae..8d097dcddda47 100644 --- a/drivers/cpufreq/mediatek-cpufreq-hw.c +++ b/drivers/cpufreq/mediatek-cpufreq-hw.c @@ -312,7 +312,7 @@ static int mtk_cpufreq_hw_driver_probe(struct platform_= device *pdev) return dev_err_probe(&pdev->dev, -EPROBE_DEFER, "Failed to get cpu%d device\n", cpu); =20 - cpu_reg =3D devm_regulator_get_optional(cpu_dev, "cpu"); + cpu_reg =3D devm_regulator_get(cpu_dev, "cpu"); if (IS_ERR(cpu_reg)) return dev_err_probe(&pdev->dev, PTR_ERR(cpu_reg), "CPU%d regulator get failed\n", cpu); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A553012D77E; Sun, 24 Mar 2024 22:36:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319801; cv=none; b=Mm1J0rBESb9O9e/zeBrM7GtHMSRWJf396s/coX3Ay6phIMxcUhBPcp88en0vI8c8GU6ajiTrEwkAXORZL3trVjeB645fNwh3zeF3nw093cnonaMsE8TE9WemFlUa7OqqnrO0NhnU6VKLgcVjsO2upl7lccjtWUPLPowdYyzuaOU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319801; c=relaxed/simple; bh=t7XSdAj6yxAQYf5fZv1wzXR8vjQRSTG70d/2KIqw3JE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hdyDZSmKV+jSnJJZKcm68cpyKfGk9+3Lw+w4WgnoUX8z+dB/bG+urP5fEFokXvVthV0GsO9SlxsI9qwUGhm6GQP6Jl1/g1UyYYUXt/+tEBNVQ32RmLnOHjNeTZlGA/OAtjtDp8767akIRrMA4cB4aznv/CLYcKRFY24QquKMQrE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dldgVlO6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dldgVlO6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDF57C43390; Sun, 24 Mar 2024 22:36:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319801; bh=t7XSdAj6yxAQYf5fZv1wzXR8vjQRSTG70d/2KIqw3JE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dldgVlO6d3w7BZe3Mra8c1lCEHd2cdfE80cASxIwTTi5g7DUQLeWlkHV2QrLTKWuB 8AoMbJAZTjUhww55+OX0uBqOF9fMV8E7GyAa3ZCzoALRQEOm+zHDU4IDtRElk0Z7Hr +UcX18ZChFTrixLVyulCL2EPFh2vHMsaxMGoH24w6dyUaFhZiwXfeYzm9gIZc5dLQv r4f6kmkQLXfIDhkMjbT9fNsW28/aI3QKd8Dc9JADFdd0O7MxnEwxx+fPq1yL+/4SkW n0B3YG648Ug4ZaG+VsTI1fhb1ngO1inf66VDJppCnI4u2r0AdphwBl4Y+KMoFVw1OD XAGbNOb51DY6A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrii Nakryiko , Daniel Borkmann , Jiri Olsa , Sasha Levin Subject: [PATCH 6.8 102/715] libbpf: Fix faccessat() usage on Android Date: Sun, 24 Mar 2024 18:24:41 -0400 Message-ID: <20240324223455.1342824-103-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrii Nakryiko [ Upstream commit ad57654053805bf9a62602aaec74cc78edb6f235 ] Android implementation of libc errors out with -EINVAL in faccessat() if passed AT_EACCESS ([0]), this leads to ridiculous issue with libbpf refusing to load /sys/kernel/btf/vmlinux on Androids ([1]). Fix by detecting Android and redefining AT_EACCESS to 0, it's equivalent on Android. [0] https://android.googlesource.com/platform/bionic/+/refs/heads/android= 13-release/libc/bionic/faccessat.cpp#50 [1] https://github.com/libbpf/libbpf-bootstrap/issues/250#issuecomment-19= 11324250 Fixes: 6a4ab8869d0b ("libbpf: Fix the case of running as non-root with capa= bilities") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20240126220944.2497665-1-andrii@kernel.org Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/lib/bpf/libbpf_internal.h | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/tools/lib/bpf/libbpf_internal.h b/tools/lib/bpf/libbpf_interna= l.h index 27e4e320e1a69..878a0d0b51f5c 100644 --- a/tools/lib/bpf/libbpf_internal.h +++ b/tools/lib/bpf/libbpf_internal.h @@ -18,6 +18,20 @@ #include #include "relo_core.h" =20 +/* Android's libc doesn't support AT_EACCESS in faccessat() implementation + * ([0]), and just returns -EINVAL even if file exists and is accessible. + * See [1] for issues caused by this. + * + * So just redefine it to 0 on Android. + * + * [0] https://android.googlesource.com/platform/bionic/+/refs/heads/andro= id13-release/libc/bionic/faccessat.cpp#50 + * [1] https://github.com/libbpf/libbpf-bootstrap/issues/250#issuecomment-= 1911324250 + */ +#ifdef __ANDROID__ +#undef AT_EACCESS +#define AT_EACCESS 0 +#endif + /* make sure libbpf doesn't use kernel-only integer typedefs */ #pragma GCC poison u8 u16 u32 u64 s8 s16 s32 s64 =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8ABC412DD99; Sun, 24 Mar 2024 22:36:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319802; cv=none; b=kw2ro03KP8grL3cx+jaMkvd9SoOXwdhclEUshkJK03dFuty/1lTzb9dC6rXDSa6xOy6AJ9F42wqJxP1RWnmfB49bHGc5ln2RLcK16A808AbvH6saXGi0/KJIvmM0mh16fLW7T2mr+WGHLMDk6bPSutKw+MsOh4nFRC2MZkHICdA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319802; c=relaxed/simple; bh=Pt8lfoqc4pHW8JA5jUyEQqyGcf753/ema3dIBVHANG0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mzsgWe5O6SbV2nQN6KqfC5RCSxb0oVFSf3UlBy1hVxNNmaf+kPuZOlRcyNzbF0YCw1IaPxQyRp7t13beI6VfgHVhpW4OuVw8gu6g0SWhGcaqcC6roH3+JI92Itm77BNaztCM9BXx5ZTDQ6PYrHL6Qk6oisXSExULi30Tjrqj5w0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QtARC0bx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QtARC0bx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C88DFC433C7; Sun, 24 Mar 2024 22:36:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319802; bh=Pt8lfoqc4pHW8JA5jUyEQqyGcf753/ema3dIBVHANG0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QtARC0bxHUGNRWASKUlk5lgv1zoETnWQgC6rQ16mHBpONnoSgN2bbJtqkPrcyT52r zvI7UFbO8p8qnmib9sHBvVNSO8cJ7E1WxFuirQTiBfSXpN8sshox/qTji5aJqRchm5 Hu5g9r7gnvrDJE0BbYucHeXwQMf1oSiWV6jR726nWgy+M4eNU433oOgPd74QbvRHaL mqWApKpd9pPSbpVnvth/yfvxzEbThqPdMmwr2LDEvrwh0ET8QZVmQHWuL7af7MM+G5 rWq3n4TVh6QD/luhzPGnsZKNG0zsgGaPPKVLgMiV/GjZ9nx6Uw/ulzE2YuVKUoRUfw zj3+HtNOWjKAA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrii Nakryiko , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 103/715] libbpf: fix __arg_ctx type enforcement for perf_event programs Date: Sun, 24 Mar 2024 18:24:42 -0400 Message-ID: <20240324223455.1342824-104-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrii Nakryiko [ Upstream commit 9eea8fafe33eb70868f6ace2fc1e17c4ff5539c3 ] Adjust PERF_EVENT type enforcement around __arg_ctx to match exactly what kernel is doing. Fixes: 76ec90a996e3 ("libbpf: warn on unexpected __arg_ctx type when rewrit= ing BTF") Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20240125205510.3642094-3-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/lib/bpf/libbpf.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index b8b00da629071..910f72c9e6a49 100644 --- a/tools/lib/bpf/libbpf.c +++ b/tools/lib/bpf/libbpf.c @@ -33,6 +33,7 @@ #include #include #include +#include #include #include #include @@ -6699,6 +6700,14 @@ static struct { /* all other program types don't have "named" context structs */ }; =20 +/* forward declarations for arch-specific underlying types of bpf_user_pt_= regs_t typedef, + * for below __builtin_types_compatible_p() checks; + * with this approach we don't need any extra arch-specific #ifdef guards + */ +struct pt_regs; +struct user_pt_regs; +struct user_regs_struct; + static bool need_func_arg_type_fixup(const struct btf *btf, const struct b= pf_program *prog, const char *subprog_name, int arg_idx, int arg_type_id, const char *ctx_name) @@ -6739,11 +6748,21 @@ static bool need_func_arg_type_fixup(const struct b= tf *btf, const struct bpf_pro /* special cases */ switch (prog->type) { case BPF_PROG_TYPE_KPROBE: - case BPF_PROG_TYPE_PERF_EVENT: /* `struct pt_regs *` is expected, but we need to fix up */ if (btf_is_struct(t) && strcmp(tname, "pt_regs") =3D=3D 0) return true; break; + case BPF_PROG_TYPE_PERF_EVENT: + if (__builtin_types_compatible_p(bpf_user_pt_regs_t, struct pt_regs) && + btf_is_struct(t) && strcmp(tname, "pt_regs") =3D=3D 0) + return 0; + if (__builtin_types_compatible_p(bpf_user_pt_regs_t, struct user_pt_regs= ) && + btf_is_struct(t) && strcmp(tname, "user_pt_regs") =3D=3D 0) + return 0; + if (__builtin_types_compatible_p(bpf_user_pt_regs_t, struct user_regs_st= ruct) && + btf_is_struct(t) && strcmp(tname, "user_regs_struct") =3D=3D 0) + return 0; + break; case BPF_PROG_TYPE_RAW_TRACEPOINT: case BPF_PROG_TYPE_RAW_TRACEPOINT_WRITABLE: /* allow u64* as ctx */ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E694612E1CB; Sun, 24 Mar 2024 22:36:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319804; cv=none; b=k4qRoeXsNJWQriTJ6JNyCf3ajo9YEwWV5yCDwY8tbRYR1C6crcNM/okersm8Y9VUERVnVJhianyqNwLBDMe8I0kveCg/YJYCcDJhU3O/4F+z7AJS2UjMebDV0J1YtkSSz4jdMwtBtBtXjQAF5664F6WvQjWsMdvCOGYGto4e0rY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319804; c=relaxed/simple; bh=ZHyLupHb1tRjqpeqOZ71dtb6ihCcKfKUiHeXXpOP6+4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sLUe4PTWrEvsWFuH85XTfPNRJ/avuY6BmBSQ/1AdesxWLEwnF4TySCH0lh91V+ZRdwvE+dgPoQmgXSaGxh7rH277+kpVCeygNGlmCcVBHaZLgrJOxV2qExVRCAPYZKdNa7qdA6htN9pIThWv4/EQlHLRX3UcXs+ksfJNqUCc2ZM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iddfvdKM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iddfvdKM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1329C43390; Sun, 24 Mar 2024 22:36:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319803; bh=ZHyLupHb1tRjqpeqOZ71dtb6ihCcKfKUiHeXXpOP6+4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iddfvdKMN4AEwEjI3eFUm2VRKze19xcdHKzrs2FDrhrW9AE9lA2H+wxLmJttN9vYG A+eWc8H6gwVZOd8vZpymf9hOoPgNNC3AtJTPL0rtJPxmgfpd5KSIMfPh4PB3+DSHYd qU0Ft2hNWGCb1rCXhrnf1jm9c6yXcCNXYGd3hFjhmpbXPImdJmrU1Q1By+CsmjjSxO T+/Ehuz2T+OQ2p3Zz5+jblQtitp1BAiZtDKc1ijrJPcNBZY1ajEZ6I5T9RqBtrYWcN UIZnmVozA9hkhRY9zkeXeBS9motrgJSefkGIFFXOdOrAmO4QLKgzTc7qw4jEyQaMuA mkpLr/BMwop5A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bjorn Andersson , Dmitry Baryshkov , Ulf Hansson , Konrad Dybcio , Sasha Levin Subject: [PATCH 6.8 104/715] pmdomain: qcom: rpmhpd: Drop SA8540P gfx.lvl Date: Sun, 24 Mar 2024 18:24:43 -0400 Message-ID: <20240324223455.1342824-105-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bjorn Andersson [ Upstream commit 883957bee580b723fd87d49ac73e0c84fc03a446 ] On SA8295P and SA8540P gfx.lvl is not provdied by rpmh, but rather is handled by an external regulator (max20411). Drop gfx.lvl from the list of power-domains exposed on this platform. Fixes: f68f1cb3437d ("soc: qcom: rpmhpd: add sc8280xp & sa8540p rpmh power-= domains") Reviewed-by: Dmitry Baryshkov Acked-by: Ulf Hansson Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240125-sa8295p-gpu-v4-4-7011c2a63037@quic= inc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/pmdomain/qcom/rpmhpd.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/pmdomain/qcom/rpmhpd.c b/drivers/pmdomain/qcom/rpmhpd.c index 47df910645f66..de9121ef4216b 100644 --- a/drivers/pmdomain/qcom/rpmhpd.c +++ b/drivers/pmdomain/qcom/rpmhpd.c @@ -217,7 +217,6 @@ static struct rpmhpd *sa8540p_rpmhpds[] =3D { [SC8280XP_CX] =3D &cx, [SC8280XP_CX_AO] =3D &cx_ao, [SC8280XP_EBI] =3D &ebi, - [SC8280XP_GFX] =3D &gfx, [SC8280XP_LCX] =3D &lcx, [SC8280XP_LMX] =3D &lmx, [SC8280XP_MMCX] =3D &mmcx, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B2AC912E1E5; Sun, 24 Mar 2024 22:36:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319804; cv=none; b=KDj5uivokX9ao4lzn31xsPDYIMXzY47IH6OizyFqGHgIwzRko2Rex0NrNoXdbc9AT4voymhRGCota4S6JOr4NjUmNs7hMzQKXijOSGspiGjzOi8eQ5RB10I8FNDxE5FGvZ0yL5sUnZbwtBIdfBRp8QvL6oHi4WViRXX8ZA65Clo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319804; c=relaxed/simple; bh=UcRpu7p1jKQyG+pfEXtk4kRecvA2V6BI+5dODNtRxC4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lojf3mYES+k/lWzrC5eyV6+3pEz9bKNwWOf2chGlfHE2i7KkKYVKdMhRQTY0Wm0xC6Nb0d1i+ddDbDUkyRtAZLIVLMa6boIw/ZQEsmJsPPfcCt5H1D8Ovt0rD1SxWAksQryCKkuIHzm08VnCcDTr70pMHG9INLNmtGV0s+c1hk8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gOWkF85W; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gOWkF85W" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3BDDC433B2; Sun, 24 Mar 2024 22:36:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319804; bh=UcRpu7p1jKQyG+pfEXtk4kRecvA2V6BI+5dODNtRxC4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gOWkF85W3yaicRYmF6DlaxStaJ3/JwGLFJK6o7VJVtEWPuvQGWEVUe3aseW6YIKEh xC+USqObo24/Marvg20Mb5eI3wV6wmR+4oWuhguUApG57Zf+mKCSH4N7Yj2wTRvgNO 2YGG0RDOrv5O4OMKRJGiIWbtDCE2Mm500GJahR8TkAK73eN1IEiVHCYo1f4DeQjWaZ +/ZWA8TviiGvsehgFCIC0Qim0GCzKJaioRe+8IV//vuX7dBUY8LlzJRJU/HPxtAyr7 /CHced3jLzv22J6CZx0N3JwfOiOmfPSIQRFySfvTKiwaXWWNuXTo2drNg05qsRgxTZ Xcf04WsJyF/uw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bjorn Andersson , Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 105/715] arm64: dts: qcom: sa8540p: Drop gfx.lvl as power-domain for gpucc Date: Sun, 24 Mar 2024 18:24:44 -0400 Message-ID: <20240324223455.1342824-106-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bjorn Andersson [ Upstream commit fd5821a1a83c969ed2dcc72fef885f3a82c1d978 ] The SA8295P and SA8540P uses an external regulator (max20411), and gfx.lvl is not provided by rpmh. Drop the power-domains property of the gpucc node to reflect this. Fixes: eec51ab2fd6f ("arm64: dts: qcom: sc8280xp: Add GPU related nodes") Reviewed-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20240125-sa8295p-gpu-v4-5-7011c2a63037@quic= inc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sa8540p.dtsi | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sa8540p.dtsi b/arch/arm64/boot/dts/qc= om/sa8540p.dtsi index 96b2c59ad02b4..23888029cc117 100644 --- a/arch/arm64/boot/dts/qcom/sa8540p.dtsi +++ b/arch/arm64/boot/dts/qcom/sa8540p.dtsi @@ -168,6 +168,9 @@ opp-2592000000 { }; =20 &gpucc { + /* SA8295P and SA8540P doesn't provide gfx.lvl */ + /delete-property/ power-domains; + status =3D "disabled"; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE41712EBC4; Sun, 24 Mar 2024 22:36:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319805; cv=none; b=cUkMRzq6aek4GGWe7dLgCsbFDkIoPGKFUftjTOX+D1RwwsOumj82EPb5izN8wulZc0HTMos8Zi4H2vMbNyvgYwGY/PPqQRHprePwUxfFjqPeQk71+pB/G3JZAC+9DygJoziY7hFtZH43nlLuMKYSHcNxZMAanqUQU1EZCZ/txRw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319805; c=relaxed/simple; bh=+4AiABqnksxNdiMVZMOXIxNcwiZbJbOVBDo6C4zJjWs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tKEieE1GFhG05q6gvpkwdOjrRq+1C3/ZE/yLPkvJatGMC8cnfapffr3zWdRTMRoQyaIkDEve0sRKjoX9aTZntMn44oOMlWbKCaoyAWrG3bxfGoTKTW4xPEj28FwyA612FmtK0PYX2cliggjGQRP8u5RmCYm2tslv7mH4LTiV0NM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N/IuPgar; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N/IuPgar" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7C15C43394; Sun, 24 Mar 2024 22:36:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319805; bh=+4AiABqnksxNdiMVZMOXIxNcwiZbJbOVBDo6C4zJjWs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N/IuPgarsXYorAjwEjxnY459Q+AR2jy5pN14diIHPyMhdhrqixIpjcLHi+mYuPufY t1g+kzfhNo98e6V2N+U3be6W2C+9k5U8o/9aG70xKrIsJQOSp+ZHc4gAcNP1Ld7hNL RdBwRqu2cbgAOu/iV3koH44efqEfGMiCZfSdsegWU0g3G+L1SUU/Cm0wnhM7oBNaVo rWrCU/8B9XS0oCfDxvVVLZ1xSBEZxCwadkYmpKa29g7KxrvNjO05tFlWK8ECGUniPn 7IkMTz2imltHkmcMsaGi+9dKpQIUkhDgnqQq0RhYkcLHNxi17Kf2TDNo/nJzWBklil VLuDi1DHOje1g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.8 106/715] arm64: dts: renesas: r8a779g0: Restore sort order Date: Sun, 24 Mar 2024 18:24:45 -0400 Message-ID: <20240324223455.1342824-107-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Geert Uytterhoeven [ Upstream commit 8b93657c976a61726d7ffbe8d019b84b4abfb673 ] Numerical by unit address, alphabetical by node name. Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/f00ef274a73c8fd60f940a1649423a8927b9ae8a.17= 05324708.git.geert+renesas@glider.be Stable-dep-of: 08e799f6bce8 ("arm64: dts: renesas: r8a779g0: Add missing SC= IF_CLK2") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 72 +++++++++++------------ 1 file changed, 36 insertions(+), 36 deletions(-) diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dt= s/renesas/r8a779g0.dtsi index d3d25e077c5d5..3be1159982b20 100644 --- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi @@ -161,11 +161,6 @@ L3_CA76_1: cache-controller-1 { }; }; =20 - psci { - compatible =3D "arm,psci-1.0", "arm,psci-0.2"; - method =3D "smc"; - }; - extal_clk: extal { compatible =3D "fixed-clock"; #clock-cells =3D <0>; @@ -185,6 +180,11 @@ pmu_a76 { interrupts-extended =3D <&gic GIC_PPI 7 IRQ_TYPE_LEVEL_LOW>; }; =20 + psci { + compatible =3D "arm,psci-1.0", "arm,psci-0.2"; + method =3D "smc"; + }; + /* External SCIF clock - to be overridden by boards that provide it */ scif_clk: scif { compatible =3D "fixed-clock"; @@ -1777,6 +1777,37 @@ ssi0: ssi-0 { }; }; =20 + mmc0: mmc@ee140000 { + compatible =3D "renesas,sdhi-r8a779g0", + "renesas,rcar-gen4-sdhi"; + reg =3D <0 0xee140000 0 0x2000>; + interrupts =3D ; + clocks =3D <&cpg CPG_MOD 706>, + <&cpg CPG_CORE R8A779G0_CLK_SD0H>; + clock-names =3D "core", "clkh"; + power-domains =3D <&sysc R8A779G0_PD_ALWAYS_ON>; + resets =3D <&cpg 706>; + max-frequency =3D <200000000>; + iommus =3D <&ipmmu_ds0 32>; + status =3D "disabled"; + }; + + rpc: spi@ee200000 { + compatible =3D "renesas,r8a779g0-rpc-if", + "renesas,rcar-gen4-rpc-if"; + reg =3D <0 0xee200000 0 0x200>, + <0 0x08000000 0 0x04000000>, + <0 0xee208000 0 0x100>; + reg-names =3D "regs", "dirmap", "wbuf"; + interrupts =3D ; + clocks =3D <&cpg CPG_MOD 629>; + power-domains =3D <&sysc R8A779G0_PD_ALWAYS_ON>; + resets =3D <&cpg 629>; + #address-cells =3D <1>; + #size-cells =3D <0>; + status =3D "disabled"; + }; + ipmmu_rt0: iommu@ee480000 { compatible =3D "renesas,ipmmu-r8a779g0", "renesas,rcar-gen4-ipmmu-vmsa"; @@ -1886,37 +1917,6 @@ ipmmu_mm: iommu@eefc0000 { #iommu-cells =3D <1>; }; =20 - mmc0: mmc@ee140000 { - compatible =3D "renesas,sdhi-r8a779g0", - "renesas,rcar-gen4-sdhi"; - reg =3D <0 0xee140000 0 0x2000>; - interrupts =3D ; - clocks =3D <&cpg CPG_MOD 706>, - <&cpg CPG_CORE R8A779G0_CLK_SD0H>; - clock-names =3D "core", "clkh"; - power-domains =3D <&sysc R8A779G0_PD_ALWAYS_ON>; - resets =3D <&cpg 706>; - max-frequency =3D <200000000>; - iommus =3D <&ipmmu_ds0 32>; - status =3D "disabled"; - }; - - rpc: spi@ee200000 { - compatible =3D "renesas,r8a779g0-rpc-if", - "renesas,rcar-gen4-rpc-if"; - reg =3D <0 0xee200000 0 0x200>, - <0 0x08000000 0 0x04000000>, - <0 0xee208000 0 0x100>; - reg-names =3D "regs", "dirmap", "wbuf"; - interrupts =3D ; - clocks =3D <&cpg CPG_MOD 629>; - power-domains =3D <&sysc R8A779G0_PD_ALWAYS_ON>; - resets =3D <&cpg 629>; - #address-cells =3D <1>; - #size-cells =3D <0>; - status =3D "disabled"; - }; - gic: interrupt-controller@f1000000 { compatible =3D "arm,gic-v3"; #interrupt-cells =3D <3>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B2CDF12EBDE; Sun, 24 Mar 2024 22:36:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319806; cv=none; b=MC2WoPZW6s2RRkphHneXzSBkzkUbKLNqXSdS6V35Cj9f+a+HDNyaOEo9Xz8MxVTodE/jitQANavU0SkD/NQAZl+1VlCieDu9LhmD16UPt9go8OPhFlS1GeGP4WRGPYtKXAU7Sb32JuoKzXtjgOAlW1Tx3v/b2kyAn/LwinNuWY8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319806; c=relaxed/simple; bh=9Qq1iVEdw0G3vZVt9MiiXBeQOuukWCru2oMuL3av5NQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oDoZSD2pXg46VrCNQ9WZxZc5EFA+Tow6nhQSffASZDxLSHHJHABDKARBJ7WWsuj0UH/fLJQPFBj4At5w3qooK1B5eFd4xMcHx5eyjGYb+2PexvQS3wQsOvF3R6RJmNZD90lGxihcJdRKdUQD7LLmcJBI2Uzm0Cjuis4NZROT4rM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jxQH8enf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jxQH8enf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9088C433B1; Sun, 24 Mar 2024 22:36:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319806; bh=9Qq1iVEdw0G3vZVt9MiiXBeQOuukWCru2oMuL3av5NQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jxQH8enfb875uJ1vHGeKYZle4JBzMO84OnRGVqThYqZ4BP8AO2Xtp2Is8CO/Eq3zb +DoPE24T7XEeHM25AMZcwjtbZ+geO2EhzGWGA1ToSvLtShFyO31S3BzzWhlEWeUqFW EivMIH61aVshrv3luiNNnxmKuEyEpqQKxNnvKuJYveh/cdkCCOMwtsI3hfW8rQxwe/ F638sFHRWj8SNXAze/jHtOsVthUhz62PyE3jMo6myz6oLZLudsECsFaQAdqcQ/2hTa 5ppgiF5pYazxYgT/xbzSyPQ+DOBnBCIEQs+tnNYV/QhKcC+jPrxlXZahm14FEb4kCz YXswy5HCT9XvA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.8 107/715] arm64: dts: renesas: r8a779g0: Add missing SCIF_CLK2 Date: Sun, 24 Mar 2024 18:24:46 -0400 Message-ID: <20240324223455.1342824-108-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Geert Uytterhoeven [ Upstream commit 08e799f6bce80dd63c174d8d0fc61d1a6149960b ] R-Car V4H actually has two SCIF_CLK pins. The second pin provides the SCIF_CLK signal for HSCIF2 and SCIF4. Fixes: a4c31c56d2d35641 ("arm64: dts: renesas: r8a779g0: Add SCIF nodes") Fixes: 39d9dfc6fbe1860e ("arm64: dts: renesas: r8a779g0: Add remaining HSCI= F nodes") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/72f20c1bf32187bd30a963cafe27252907d661f9.17= 05589612.git.geert+renesas@glider.be Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dt= s/renesas/r8a779g0.dtsi index 3be1159982b20..0c83940b3d8a1 100644 --- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi @@ -185,13 +185,19 @@ psci { method =3D "smc"; }; =20 - /* External SCIF clock - to be overridden by boards that provide it */ + /* External SCIF clocks - to be overridden by boards that provide them */ scif_clk: scif { compatible =3D "fixed-clock"; #clock-cells =3D <0>; clock-frequency =3D <0>; }; =20 + scif_clk2: scif2 { + compatible =3D "fixed-clock"; + #clock-cells =3D <0>; + clock-frequency =3D <0>; + }; + soc: soc { compatible =3D "simple-bus"; interrupt-parent =3D <&gic>; @@ -681,7 +687,7 @@ hscif2: serial@e6560000 { interrupts =3D ; clocks =3D <&cpg CPG_MOD 516>, <&cpg CPG_CORE R8A779G0_CLK_SASYNCPERD1>, - <&scif_clk>; + <&scif_clk2>; clock-names =3D "fck", "brg_int", "scif_clk"; dmas =3D <&dmac0 0x35>, <&dmac0 0x34>, <&dmac1 0x35>, <&dmac1 0x34>; @@ -1057,7 +1063,7 @@ scif4: serial@e6c40000 { interrupts =3D ; clocks =3D <&cpg CPG_MOD 705>, <&cpg CPG_CORE R8A779G0_CLK_SASYNCPERD1>, - <&scif_clk>; + <&scif_clk2>; clock-names =3D "fck", "brg_int", "scif_clk"; dmas =3D <&dmac0 0x59>, <&dmac0 0x58>, <&dmac1 0x59>, <&dmac1 0x58>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D2E212EBF8; Sun, 24 Mar 2024 22:36:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319807; cv=none; b=Bx5n6arj9diMGluDRj8XTxttOW5tVQ6lMRq+zQlNIy47208OZt1bEGbbSEtaRjWWrzhi5vvzHDPeMDFvfvNQhNSi8d43HRaikejFz5zAFu6CZ3o80coZY9G+Q6AiDB5LqsE/zolnD7LKIcxB9fojxqFjWKy2W1KwYwxpFtsli4U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319807; c=relaxed/simple; bh=jcSa7AED0sYNrjMzwm3P5thW7G1RPQj5kfgFF+4N0IY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=E5507VmFf6spnuWLtvCshBhxdmPzNkah0nm3yWO6nzdZnBGNnvEqmXKNa2Yf4bnQ3il9/0+tQcV0j3AJWMFbQswSC0spxwdC9wE3B7x2HR6mhwkkaj9KpeXdl/s0sHsarsdNQ6SNmZN5sWIJ0oQPH3AHEmgiSTSh5kvYE+3YXw8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YOFn248u; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YOFn248u" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 787EAC433F1; Sun, 24 Mar 2024 22:36:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319807; bh=jcSa7AED0sYNrjMzwm3P5thW7G1RPQj5kfgFF+4N0IY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YOFn248uSWNsLzd8SBDN0mhgVqQ/ON0ynQR5IdvoRl7X5jvfsGvnH4jnsON1XxCNB 8wu684/k0luu/D+nNQRK46Yzgcnhh+z4Azpw3r3U8A27OypQMkRxv6YkHXprFqs/T3 kxnQSryh+L/ag+EpsMOFUCOwiPuYYjjYZF0aRvu09Sqm2xvvTg1DV7Vvpew8Av/HVR dBXL3/tW3XIjctIidIsuKPi9OgBffs1+n6gbO7k8ChYC8iO9GJmQq4bCz2RM3Ewrdo Gp6nrGkRG0CBdimACgcKDYlOOHvhiIvlFHLBdud3ZHBWmhpovFPvf2QtrE8CXbxiyO 488Xjy4TKNP6w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Manu Bretelle , Andrii Nakryiko , Sasha Levin Subject: [PATCH 6.8 108/715] selftests/bpf: Disable IPv6 for lwt_redirect test Date: Sun, 24 Mar 2024 18:24:47 -0400 Message-ID: <20240324223455.1342824-109-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Manu Bretelle [ Upstream commit 2ef61296d2844c6a4211e07ab70ef2fb412b2c30 ] After a recent change in the vmtest runner, this test started failing sporadically. Investigation showed that this test was subject to race condition which got exacerbated after the vm runner change. The symptoms being that the logic that waited for an ICMPv4 packet is naive and will break if 5 or more non-ICMPv4 packets make it to tap0. When ICMPv6 is enabled, the kernel will generate traffic such as ICMPv6 router solicitation... On a system with good performance, the expected ICMPv4 packet would very likely make it to the network interface promptly, but on a system with poor performance, those "guarantees" do not hold true anymore. Given that the test is IPv4 only, this change disable IPv6 in the test netns by setting `net.ipv6.conf.all.disable_ipv6` to 1. This essentially leaves "ping" as the sole generator of traffic in the network namespace. If this test was to be made IPv6 compatible, the logic in `wait_for_packet` would need to be modified. In more details... At a high level, the test does: - create a new namespace - in `setup_redirect_target` set up lo, tap0, and link_err interfaces as well as add 2 routes that attaches ingress/egress sections of `test_lwt_redirect.bpf.o` to the xmit path. - in `send_and_capture_test_packets` send an ICMP packet and read off the tap interface (using `wait_for_packet`) to check that a ICMP packet with the right size is read. `wait_for_packet` will try to read `max_retry` (5) times from the tap0 fd looking for an ICMPv4 packet matching some criteria. The problem is that when we set up the `tap0` interface, because IPv6 is enabled by default, traffic such as Router solicitation is sent through tap0, as in: # tcpdump -r /tmp/lwt_redirect.pc reading from file /tmp/lwt_redirect.pcap, link-type EN10MB (Ethernet) 04:46:23.578352 IP6 :: > ff02::1:ffc0:4427: ICMP6, neighbor solicitation,= who has fe80::fcba:dff:fec0:4427, length 32 04:46:23.659522 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v= 2, 1 group record(s), length 28 04:46:24.389169 IP 10.0.0.1 > 20.0.0.9: ICMP echo request, id 122, seq 1,= length 108 04:46:24.618599 IP6 fe80::fcba:dff:fec0:4427 > ff02::16: HBH ICMP6, multi= cast listener report v2, 1 group record(s), length 28 04:46:24.619985 IP6 fe80::fcba:dff:fec0:4427 > ff02::2: ICMP6, router sol= icitation, length 16 04:46:24.767326 IP6 fe80::fcba:dff:fec0:4427 > ff02::16: HBH ICMP6, multi= cast listener report v2, 1 group record(s), length 28 04:46:28.936402 IP6 fe80::fcba:dff:fec0:4427 > ff02::2: ICMP6, router sol= icitation, length 16 If `wait_for_packet` sees 5 non-ICMPv4 packets, it will return 0, which is = what we see in: 2024-01-31T03:51:25.0336992Z test_lwt_redirect_run:PASS:netns_create 0 ns= ec 2024-01-31T03:51:25.0341309Z open_netns:PASS:malloc token 0 nsec 2024-01-31T03:51:25.0344844Z open_netns:PASS:open /proc/self/ns/net 0 nsec 2024-01-31T03:51:25.0350071Z open_netns:PASS:open netns fd 0 nsec 2024-01-31T03:51:25.0353516Z open_netns:PASS:setns 0 nsec 2024-01-31T03:51:25.0356560Z test_lwt_redirect_run:PASS:setns 0 nsec 2024-01-31T03:51:25.0360140Z open_tuntap:PASS:open(/dev/net/tun) 0 nsec 2024-01-31T03:51:25.0363822Z open_tuntap:PASS:ioctl(TUNSETIFF) 0 nsec 2024-01-31T03:51:25.0367402Z open_tuntap:PASS:fcntl(O_NONBLOCK) 0 nsec 2024-01-31T03:51:25.0371167Z setup_redirect_target:PASS:open_tuntap 0 nsec 2024-01-31T03:51:25.0375180Z setup_redirect_target:PASS:if_nametoindex 0 = nsec 2024-01-31T03:51:25.0379929Z setup_redirect_target:PASS:ip link add link_= err type dummy 0 nsec 2024-01-31T03:51:25.0384874Z setup_redirect_target:PASS:ip link set lo up= 0 nsec 2024-01-31T03:51:25.0389678Z setup_redirect_target:PASS:ip addr add dev l= o 10.0.0.1/32 0 nsec 2024-01-31T03:51:25.0394814Z setup_redirect_target:PASS:ip link set link_= err up 0 nsec 2024-01-31T03:51:25.0399874Z setup_redirect_target:PASS:ip link set tap0 = up 0 nsec 2024-01-31T03:51:25.0407731Z setup_redirect_target:PASS:ip route add 10.0= .0.0/24 dev link_err encap bpf xmit obj test_lwt_redirect.bpf.o sec redir_i= ngress 0 nsec 2024-01-31T03:51:25.0419105Z setup_redirect_target:PASS:ip route add 20.0= .0.0/24 dev link_err encap bpf xmit obj test_lwt_redirect.bpf.o sec redir_e= gress 0 nsec 2024-01-31T03:51:25.0427209Z test_lwt_redirect_normal:PASS:setup_redirect= _target 0 nsec 2024-01-31T03:51:25.0431424Z ping_dev:PASS:if_nametoindex 0 nsec 2024-01-31T03:51:25.0437222Z send_and_capture_test_packets:FAIL:wait_for_= epacket unexpected wait_for_epacket: actual 0 !=3D expected 1 2024-01-31T03:51:25.0448298Z (/tmp/work/bpf/bpf/tools/testing/selftests/b= pf/prog_tests/lwt_redirect.c:175: errno: Success) test_lwt_redirect_normal = egress test fails 2024-01-31T03:51:25.0457124Z close_netns:PASS:setns 0 nsec When running in a VM which potential resource contrains, the odds that call= ing `ping` is not scheduled very soon after bringing `tap0` up increases, and with this the chances to get our ICMP packet pushed to position 6+ in the network trace. To confirm this indeed solves the issue, I ran the test 100 times in a row with: errors=3D0 successes=3D0 for i in `seq 1 100` do ./test_progs -t lwt_redirect/lwt_redirect_normal if [ $? -eq 0 ]; then successes=3D$((successes+1)) else errors=3D$((errors+1)) fi done echo "successes: $successes/errors: $errors" While this test would at least fail a couple of time every 10 runs, here it ran 100 times with no error. Fixes: 43a7c3ef8a15 ("selftests/bpf: Add lwt_xmit tests for BPF_REDIRECT") Signed-off-by: Manu Bretelle Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20240131053212.2247527-1-chantr4@gmail.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/testing/selftests/bpf/prog_tests/lwt_redirect.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/bpf/prog_tests/lwt_redirect.c b/tools/= testing/selftests/bpf/prog_tests/lwt_redirect.c index 59b38569f310b..2bc932a18c17e 100644 --- a/tools/testing/selftests/bpf/prog_tests/lwt_redirect.c +++ b/tools/testing/selftests/bpf/prog_tests/lwt_redirect.c @@ -203,6 +203,7 @@ static int setup_redirect_target(const char *target_dev= , bool need_mac) if (!ASSERT_GE(target_index, 0, "if_nametoindex")) goto fail; =20 + SYS(fail, "sysctl -w net.ipv6.conf.all.disable_ipv6=3D1"); SYS(fail, "ip link add link_err type dummy"); SYS(fail, "ip link set lo up"); SYS(fail, "ip addr add dev lo " LOCAL_SRC "/32"); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 20DAF12F36C; Sun, 24 Mar 2024 22:36:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319808; cv=none; b=LTD7ZbxLT9gIWd+TjlSznxIkRLawMMRUUZgaqYYSZZtdFvnvyhXItsGZa18+yZJoKARjEc9tyIJAPR8qbKqkCvO/gw8voM9Ba8L8upDpx939CLDmEnOOSvOkaRkbnM3J+NCjuX2naPQA2eQyPNf3luENXK9PkuZSsQW0mFjQR4Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319808; c=relaxed/simple; bh=ze5NvR4EfcKhR0fNuwbdLlByKeSoQS9yq6vaY4x24bQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uEpKREpWXvjpqVYOIt2bBut1MtwclqW4K/dSdvmVPg0fYcui1BAzaTIT5iYqhn7cQ+UfseyEkapPgPGFCbJr/oXlEvdUbvxEmxtL+vWrRUA1T4p7PPMV3xdTusvAcqk6oV1sNvySOeqlcRkGTKABnWYHwt2jPpf3qxqCrPhQlg8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=grZW4DR2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="grZW4DR2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F3A6C433B1; Sun, 24 Mar 2024 22:36:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319808; bh=ze5NvR4EfcKhR0fNuwbdLlByKeSoQS9yq6vaY4x24bQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=grZW4DR2kbhdyzj46djI3pGg1e++JjTkVlvQY8ZS5CCAQaV37xSKFX1K9hRQPYTo2 Y+nvgmuITf9mHjsQ2mQ9IrDKkQdPkdsds4VQCRjsjb7hMKhH/BlY4a9QUX24TGgJdG Oc30unItB+AEdOgpvojkZUW/KKG6H3DqQ29b+udouVV1bDuehB0Sx5tbJ0+8hO9wi5 bslqeapz9GVgKcZZ3yNT78UY9S23109ifFojfr1H2mh/9mfAd48Zckas9rAUFdODdc GqJ4uuPzi78H6rYL6FyCyQ9NgbZqEM3zU6RQmna0feDbeJvl3gOU6mFITmJhPt923p MwZi1Bmw8QX+Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Frieder Schrempf , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 109/715] arm64: dts: imx8mm-kontron: Disable pullups for I2C signals on OSM-S i.MX8MM Date: Sun, 24 Mar 2024 18:24:48 -0400 Message-ID: <20240324223455.1342824-110-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Frieder Schrempf [ Upstream commit 96293af54f6aa859015d8ca40a1437d3115ad50c ] There are external pullup resistors on the board and due to silicon errata ERR050080 let's disable the internal ones to prevent any unwanted behavior in case they wear out. Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM= -S") Signed-off-by: Frieder Schrempf Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts | 4 ++-- arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/ar= ch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts index 8b16bd68576c0..0730c22e5b6b9 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts @@ -294,8 +294,8 @@ MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2 0x19 =20 pinctrl_i2c4: i2c4grp { fsl,pins =3D < - MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL 0x400001c3 - MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA 0x400001c3 + MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL 0x40000083 + MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA 0x40000083 >; }; =20 diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch= /arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi index 6e75ab879bf59..3e7db968f7e64 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi @@ -252,8 +252,8 @@ MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x19 =20 pinctrl_i2c1: i2c1grp { fsl,pins =3D < - MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL 0x400001c3 - MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3 + MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL 0x40000083 + MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x40000083 >; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0CF1612F389; Sun, 24 Mar 2024 22:36:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319809; cv=none; b=i4mULMbLL+sXf6dKjsr0H8pdHcJNN8AtqkZW03T0Xtix8u+/qCizBTjqjt4P6PCE1Cf6huWmyowBlmmlbNymBFqYKQNphFQy+fSZ94kNAna4jaG2R0l7LOZNP0lN5S/x3tUaXLkNCKZ2y6MH6xquO9lySw4z3GlXOVoc/IptcnI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319809; c=relaxed/simple; bh=5jaLuzVu03LfcgTNCeqDwZBUUHqQVrNeybRDDhk2+Y0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sd6V+IW4r++U7BnD3pmh1I/hKVMcqtnTYdB287RKfrFVmOlZmckgf3De7ROHHWy+gTlG+JmL9ChP0RyvfLRZsox588Yu9MzK8CMctLC9WiPSHMPXVQ1K8wZcxqzj9iGnliRgOhOaC5LChwqaCpWDfagr52T72SR71dY38JKmMG8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iX6htGVX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iX6htGVX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43468C433F1; Sun, 24 Mar 2024 22:36:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319808; bh=5jaLuzVu03LfcgTNCeqDwZBUUHqQVrNeybRDDhk2+Y0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iX6htGVXDZHwxBEw91TpxQ11fS/qutH7ktcrxwlvJ6/yrtbKtIgHt23shUuIf3gBG HODmlvhfZCEcgZy56zDeHc+0y4gzg9C79iDAwSjTrmGGHZCpIANDW68ZQdDPDWwTJu +ZZ0w2a4LbjPwvUjRElAvH5ar5VnW3DT8+Q9hZIOr5jkxXHAG6dj+dSIJiPNXG5VvD IaCZ4eSY6CTPxTnMVAtqkWmMa9M+7ayVecAVQZyUeM1LrZYL/nIwfLmZN/e5+2V7jx mG6SBY6gbukNiapT6exd0g8DNRMTp6ucKVuD0Gdf92LoqMkPtRhnA7XIrj8MPY8cCI yvj2kxQU2Y2ZQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Frieder Schrempf , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 110/715] arm64: dts: imx8mm-kontron: Disable pullups for I2C signals on SL/BL i.MX8MM Date: Sun, 24 Mar 2024 18:24:49 -0400 Message-ID: <20240324223455.1342824-111-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Frieder Schrempf [ Upstream commit f19e5bb91d53264d7dac5d845a4825afadf72440 ] There are external pullup resistors on the board and due to silicon errata ERR050080 let's disable the internal ones to prevent any unwanted behavior in case they wear out. Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and base= boards") Signed-off-by: Frieder Schrempf Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts | 4 ++-- arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm= 64/boot/dts/freescale/imx8mm-kontron-bl.dts index dcec57c20399e..5fd2e45258b11 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts @@ -279,8 +279,8 @@ MX8MM_IOMUXC_SAI3_MCLK_GPIO5_IO2 0x19 =20 pinctrl_i2c4: i2c4grp { fsl,pins =3D < - MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL 0x400001c3 - MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA 0x400001c3 + MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL 0x40000083 + MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA 0x40000083 >; }; =20 diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi b/arch/ar= m64/boot/dts/freescale/imx8mm-kontron-sl.dtsi index 1f8326613ee9e..2076148e08627 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-sl.dtsi @@ -237,8 +237,8 @@ MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x19 =20 pinctrl_i2c1: i2c1grp { fsl,pins =3D < - MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL 0x400001c3 - MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3 + MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL 0x40000083 + MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x40000083 >; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC8F712F588; Sun, 24 Mar 2024 22:36:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319810; cv=none; b=F3G43zTQuoNxxygiUl5rkJfNK+fY0zLMs80GmrmuU05V1CvmD5s9gUSZpWgohnbzbyRpVqy/kDQmmIa+vZ8ycuK8QWRvNquBCXu6DOlB7ZgOXl5HREAiqw9KesGvYABRZpGEyNQ8s8frZxazSMIOV2CAcJbTaEy1gatYcOtbEXQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319810; c=relaxed/simple; bh=2diJNys690X5vuo8K0Z2rkLA90NikcwwPE7MwS9PceI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qg1gI/EdNzZoFZU2xDmNSmVG2PfQ6DP/MYnlXd9cdJ2GQYwzvT46hr/Uf5jXjb8xkVHBIx+vhvdQtbYJXxFjMWftMKPFaWWj5uzJtKJaNHatfyhiLjZqn8T5m/EdkRLPi6IcUYpgclx4XlQ4Qc3NWPPoLT24wE2C067QdZSQaII= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V4A63o6/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V4A63o6/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 296F9C43394; Sun, 24 Mar 2024 22:36:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319809; bh=2diJNys690X5vuo8K0Z2rkLA90NikcwwPE7MwS9PceI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V4A63o6//R4Mt4+Jl2g+B6hqU3rlKOaPetR12NgcMF9h13bhGBh4uRsW0mlAefDd6 1LBtXq/OeBJnyq8BOHAV/tU4p2X022etGrn1bezOZmr/8RXIwoDhRsvqufjELU4LWA Cgv3b16eBubkVZICJJw8uY8ZgnlFOCKJs0NVZARs5ccPCAobvx2zjpLCQxcdtXbEKC scdX+2HtmhzUD8o5FfC/4IuWqha06E7aEWpbWJ6QjsR0nBdjaEQAfwQQ0zKGwnKLuw 2JFtU7dRawjwKdIGoj+cg/+7sNswUDhIKK5jMJTllCPMbHhQl+DxrV3iIAeBg3d860 y6GGo5rdVxdDg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Frieder Schrempf , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 111/715] arm64: dts: imx8mm-kontron: Disable pullups for onboard UART signals on BL OSM-S board Date: Sun, 24 Mar 2024 18:24:50 -0400 Message-ID: <20240324223455.1342824-112-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Frieder Schrempf [ Upstream commit c6d9b5672a0e2c4b1079a50d2fc8780c40cfd3eb ] These signals are actively driven by the SoC or by the onboard transceiver. There's no need to enable the internal pull resistors and due to silicon errata ERR050080 let's disable the internal ones to prevent any unwanted behavior in case they wear out. Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM= -S") Signed-off-by: Frieder Schrempf Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../dts/freescale/imx8mm-kontron-bl-osm-s.dts | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/ar= ch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts index 0730c22e5b6b9..1dd03ef0a7835 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts @@ -313,19 +313,19 @@ MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25 0x19 =20 pinctrl_uart1: uart1grp { fsl,pins =3D < - MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x140 - MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x140 - MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x140 - MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x140 + MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x0 + MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x0 + MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x0 + MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x0 >; }; =20 pinctrl_uart2: uart2grp { fsl,pins =3D < - MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX 0x140 - MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX 0x140 - MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B 0x140 - MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B 0x140 + MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX 0x0 + MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX 0x0 + MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B 0x0 + MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B 0x0 >; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C04A712F5A2; Sun, 24 Mar 2024 22:36:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319810; cv=none; b=UIhK4jETYICB3nfZH5vQuaoNIWo8eF62XCcDbDWWd/yYPBp5PpchtvNcJGNYhVsomR12QE05cQomNWknPkc5O5Rus1nv+j9z2H0JLOXE8JxjzeA6DPAYlXuARvj7iOIX0RgNGfNlLk3b8nMXjnJc3Je1phJOxmFdBn0EgcgPTbk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319810; c=relaxed/simple; bh=37Zel5azHMMPsuJmvBbKgkaQSVhGNE8yCrKdKwCBDRk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mTidizBpNTyl6C8Rwc9BG1kXAz0ENv9ajuRX8t122v2kg0QMhx/zkTXGSVjgFJlF1a5FnTpWC/tBW+P6a12c/xL9YKIbSRLwX1olGfPLZyUZo/PFgLJ9ArqFqnO6rpttcGkxfpb5O6HpAHocFP5d//aueCWuht7cTBBQDLS38iQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NKfoSMld; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NKfoSMld" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D910C433F1; Sun, 24 Mar 2024 22:36:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319810; bh=37Zel5azHMMPsuJmvBbKgkaQSVhGNE8yCrKdKwCBDRk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NKfoSMld3u3bOD4tBtc/fRH5rQQuo0sa+A7aIei7EOBjueNtZS2qdC/HFzIW4ORep PHwPhylYFFXeCv9GO8mzztGFjZvgVdYSTTji/UM9ZBVqX6JMM7N033U9XCKP8DPIeT 8NIBgi/wh60vp6UZql+lBVpEZK+66t4rbx2Aqvt1yKeuZpZaa2yIfIew9pK/oL5ztT lMDQu/V2WJUrfxxflcmSjYDbChXe1SK6F/df7ISq45dT0I9VysyqDOQkOj0E+TslcS JHdPzsvJ//Mcx3MwT2SFhIvtXUkai07PZkiYXAXk7O6uKMlYKWGMg1K2D0Z/1NOFsu TSpOIe7EbgIiw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Frieder Schrempf , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 112/715] arm64: dts: imx8mm-kontron: Disable pullups for onboard UART signals on BL board Date: Sun, 24 Mar 2024 18:24:51 -0400 Message-ID: <20240324223455.1342824-113-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Frieder Schrempf [ Upstream commit 162aadaa0df8217b0cc49d919dd00022fef65e78 ] These signals are actively driven by the SoC or by the onboard transceiver. There's no need to enable the internal pull resistors and due to silicon errata ERR050080 let's disable the internal ones to prevent any unwanted behavior in case they wear out. Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and base= boards") Signed-off-by: Frieder Schrempf Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../boot/dts/freescale/imx8mm-kontron-bl.dts | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm= 64/boot/dts/freescale/imx8mm-kontron-bl.dts index 5fd2e45258b11..ee93db11c0d06 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts @@ -292,19 +292,19 @@ MX8MM_IOMUXC_SPDIF_RX_PWM2_OUT 0x19 =20 pinctrl_uart1: uart1grp { fsl,pins =3D < - MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x140 - MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x140 - MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x140 - MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x140 + MX8MM_IOMUXC_SAI2_RXC_UART1_DCE_RX 0x0 + MX8MM_IOMUXC_SAI2_RXFS_UART1_DCE_TX 0x0 + MX8MM_IOMUXC_SAI2_RXD0_UART1_DCE_RTS_B 0x0 + MX8MM_IOMUXC_SAI2_TXFS_UART1_DCE_CTS_B 0x0 >; }; =20 pinctrl_uart2: uart2grp { fsl,pins =3D < - MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX 0x140 - MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX 0x140 - MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B 0x140 - MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B 0x140 + MX8MM_IOMUXC_SAI3_TXFS_UART2_DCE_RX 0x0 + MX8MM_IOMUXC_SAI3_TXC_UART2_DCE_TX 0x0 + MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B 0x0 + MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B 0x0 >; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A83E912FB09; Sun, 24 Mar 2024 22:36:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319811; cv=none; b=kM5UlTs0i0Bqdja4HxZqINK093UJYZH43rUlsEhU4XsGgBa5ibwNt0gvclAvJR1Qy9Nt2RNmbDPFrF7etGBGH+03FCPX6Hhr3d9pd7GvpFi9/IMMpT95YH0zcxxsJIkOCsjUEvURp525MbNKs4umGyivzUAQpPVBv5BygZEaj3w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319811; c=relaxed/simple; bh=C5+iWgv1WmZKo9V89Vlt5pXL8s+c771eDGwih5584Qk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Dm/1znlJMVL/3ngcRrx7UTSj0vhZnElzY2RC/BuP+D7yHJ4O3EEqmYDkxnZvFr77uK50Blb3VWRsY1S9pofOsBi3r0nyoFXHLShe6nQ2ZsMFOEM4Hs5eaTfW5VgU6CoGZvg0iSr/5TghYtZNPREpfbl2GdAqJYjzSjhjvj6Zu/w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ktnHX4Kq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ktnHX4Kq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E549DC433A6; Sun, 24 Mar 2024 22:36:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319811; bh=C5+iWgv1WmZKo9V89Vlt5pXL8s+c771eDGwih5584Qk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ktnHX4KqrdDGEmHKTyT4jdTa1N/s57obmCo7mW0EnincTLbrvk6IXtur6+WW2Vd+Z hq1pOO90N9HEnNwN7wPaGDzrAvEYCjCkL4xTdCo81BNcdD4QLmnqm2A5Y2CtxDpUjS QTj1ZFIvZgjGrA3RGzXsHUhmzfebzSQdsmXfAJ/ekpyPcCmr342nhahKSRAAvjFXci c35WcIxKcX4aKTvxZtNPx8MugIkljY6q+74BpxYZdF0RwDUrYy2S+WO1Xux1jn70jk Nrn6CW00eqAlTk9FKqac211Vec+hXZIZgKm4Ic1MNjtLyoispR6z0gHU82kQVZvjfN kapYXUMlyRETw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Frieder Schrempf , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 113/715] arm64: dts: imx8mm-kontron: Disable pull resistors for SD card signals on BL OSM-S board Date: Sun, 24 Mar 2024 18:24:52 -0400 Message-ID: <20240324223455.1342824-114-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Frieder Schrempf [ Upstream commit 5a940ba3e4d7c8710c9073ff5d0ca4644d4da9db ] Some signals have external pullup resistors on the board and don't need the internal ones to be enabled. Due to silicon errata ERR050080 let's disable the internal pull resistors whererever possible and prevent any unwanted behavior in case they wear out. Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM= -S") Signed-off-by: Frieder Schrempf Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../dts/freescale/imx8mm-kontron-bl-osm-s.dts | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts b/ar= ch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts index 1dd03ef0a7835..d9fa0deea7002 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl-osm-s.dts @@ -337,40 +337,40 @@ MX8MM_IOMUXC_NAND_CE1_B_GPIO3_IO2 0x19 =20 pinctrl_usdhc2: usdhc2grp { fsl,pins =3D < - MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x190 + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x90 MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d0 MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d0 MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 - MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x19 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xd0 >; }; =20 pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp { fsl,pins =3D < - MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194 + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x94 MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4 MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d4 MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 - MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x19 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xd0 >; }; =20 pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp { fsl,pins =3D < - MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196 + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x96 MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6 MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d6 MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 - MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x19 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xd0 >; }; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DAE9B12FB33; Sun, 24 Mar 2024 22:36:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319813; cv=none; b=jQp275F410zdKjzc61OpMg1J70FQpFIpUi+AgzWZOja1raIatYsAsJrEQLHYUpztuFVaNGlAxarEqCqmNwdfGCLe9j0lqSnHphc+VlepMh+tEOXQEnYf9lvVw/Jphy4tw5iPW0SpfEBc5vh/YEJ6t3XgYGMNGlNGKx10tfZL2Eo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319813; c=relaxed/simple; bh=xPRqP6qMDypdxzrwhFJPn3DwXf9dhukUsTYwU4wACgE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bN80XUqhrVKwZrOeDlO/8TYQAfZTxK/QYUoZ0oH5C+3WCOh2llxpaOv9NbYhqbarZ9AtELGaC+UqexHyy62FloeVzQuTutrtKNrcpVlp3dz1seZrYwIpaeoglyD1z6hmFTiwdGfBCPQUkGXPt84/1D8kiFAEQGoekEBYgM3DrkU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Qww9D8zu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Qww9D8zu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CCABEC433C7; Sun, 24 Mar 2024 22:36:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319812; bh=xPRqP6qMDypdxzrwhFJPn3DwXf9dhukUsTYwU4wACgE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Qww9D8zu9CakI/2FuT3RV3B5274EgPI44eg6KEtClJxHTJluJECEU02Qm0z53oaMj b1IZqUr783+1dPaKY0kSNHDtRQeIgrwZxEQ+1WGhjrW2WBrGQMKMcF0lKPnpq8Xtwy jPZ4MpvaKnfcMx9cxXybpOlfz1qSBllQ8OWQV0MAiMyUhH8S94QqNI7DMNEsdwPJyN abvp19ZLvuy66YBy1SS6GVAHjmJGQqWb8otD5jvd4UctUrv/QKIo9Rs/GCoUfsaMH/ crlYaB5hoYJ5OIlvg1yc/qWLWtuGP3RFB5vPt8DXZkIstyuS9DHXkvqfLX4PrakVF+ YNR2Nl3yvdb5A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Frieder Schrempf , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 114/715] arm64: dts: imx8mm-kontron: Disable pull resistors for SD card signals on BL board Date: Sun, 24 Mar 2024 18:24:53 -0400 Message-ID: <20240324223455.1342824-115-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Frieder Schrempf [ Upstream commit 008820524844326ffb3123cebceba1960c0ad0dc ] Some signals have external pullup resistors on the board and don't need the internal ones to be enabled. Due to silicon errata ERR050080 let's disable the internal pull resistors whererever possible and prevent any unwanted behavior in case they wear out. Fixes: 8668d8b2e67f ("arm64: dts: Add the Kontron i.MX8M Mini SoMs and base= boards") Signed-off-by: Frieder Schrempf Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../boot/dts/freescale/imx8mm-kontron-bl.dts | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts b/arch/arm= 64/boot/dts/freescale/imx8mm-kontron-bl.dts index ee93db11c0d06..aab8e24216501 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts @@ -316,40 +316,40 @@ MX8MM_IOMUXC_NAND_CE1_B_GPIO3_IO2 0x19 =20 pinctrl_usdhc2: usdhc2grp { fsl,pins =3D < - MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x190 + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x90 MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d0 MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d0 MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0 - MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x19 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xd0 >; }; =20 pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp { fsl,pins =3D < - MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194 + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x94 MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4 MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d4 MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4 - MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x19 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xd0 >; }; =20 pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp { fsl,pins =3D < - MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196 + MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x96 MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6 MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d6 MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6 MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6 MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6 - MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x019 - MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0 + MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x19 + MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0xd0 >; }; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7677C12FF67; Sun, 24 Mar 2024 22:36:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319813; cv=none; b=fhxMhgB02jB5T/1hz9TSu9kGaWbzM7rk63GwkbNc/8oSh4I/R47jj0S70+qVg2EO4UgLb9wTTaFA8dS2ZC0xd6s9NDb1Vpfu3WSIK2LylLxdhg2WAVG22tGCpnYgzAshEWQFzzl3vLzDAc4n8SjbCdRGRHdTJftjYscXI8m/0x0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319813; c=relaxed/simple; bh=aMDo02VAK1zjVAZyROahyTo3LEtSa9UVeeqPFxBRTII=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kXYPNlG9k1TCj0zMGaEz4G3ZacNVn63YpYZMgJljzB1DQWawLf0OVY0prJR+C2I1aCIU/PX5PmBFK6iL2gHncsMJapnGIrskmgG28Ozfza4uitECyA7UasINIu8uIVMYH/fsvnvemNjgucwnMPhc2b2y6XDsGTG4i5AloAwjjl0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YR0vzom9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YR0vzom9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B5A69C433F1; Sun, 24 Mar 2024 22:36:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319813; bh=aMDo02VAK1zjVAZyROahyTo3LEtSa9UVeeqPFxBRTII=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YR0vzom9WDP22kPpO3Fxe7qNF3pn35rZzkvPCCn5d5u5rqcG40ZSNL2dkJjWWWCoC yMartm17DF5KgLDUUBJaSGAD22wQ2g85ilMUZ2WwtqYF0Hfs09KVcB/IPVMPsQsnH/ ugjthsLKGRkp3x7MjXMF4GOhoxI7CmTNILiOBZTS6ZMeXFoYmJU25cAkFz3LH9Pllx ZdCBwIjRnIeVqMp9H4rT5uCzslSZg78iLatdXGruPyJigXDy9cwucnTLdmHbRX7l0p iXpiPiZmG2EUlq+t6h5LUKyPbF081eglMeIW1E/A4gYXh8MKfoqMbiTrxic16DyDHT t2Rms7HxiRBkQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Frieder Schrempf , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 115/715] arm64: dts: imx8mm-kontron: Fix interrupt for RTC on OSM-S i.MX8MM module Date: Sun, 24 Mar 2024 18:24:54 -0400 Message-ID: <20240324223455.1342824-116-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Frieder Schrempf [ Upstream commit 8d0f39b7d04d864e89b84063b124fd10aa4b8809 ] The level of the interrupt signal is active low instead. Fix this. Fixes: de9618e84f76 ("arm64: dts: Add support for Kontron SL/BL i.MX8MM OSM= -S") Signed-off-by: Frieder Schrempf Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi b/arch= /arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi index 3e7db968f7e64..60abcb636cedf 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi @@ -210,7 +210,7 @@ rv3028: rtc@52 { reg =3D <0x52>; pinctrl-names =3D "default"; pinctrl-0 =3D <&pinctrl_rtc>; - interrupts-extended =3D <&gpio4 1 IRQ_TYPE_LEVEL_HIGH>; + interrupts-extended =3D <&gpio4 1 IRQ_TYPE_LEVEL_LOW>; trickle-diode-disable; }; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A67412FF89; Sun, 24 Mar 2024 22:36:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319814; cv=none; b=DW94EZSdFe8WV5f/KDxwbUWxeuA2sDpFBAecXgtAt3KrpmxpEC9GxCeYkTsCeAPp6lqoVaU00PNYufWOpHzRaYTB09e/HHMd5YOLISnkRZn7p8EbMh9cqH4o8iDiz7aw0gjftqzj5eM/4UxdKgkDgfRh+IQR1i/jpSDbO0iSel0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319814; c=relaxed/simple; bh=DiYoUl9hVkKIa+xG9L0jGwjfOCAQrQdPAAxKOqq5xnE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oN/A1eWM4fWHu+zDqenHFZA7NWiHgWNs9ruVwlE5ptPk0RHAAe23mnhnmf/FC6adHKtAx9wQ7N7PI8TNdzEjAhcpk7E4k3YtCq3jFNqD5Qcoy64/erVOeUVf9NXUZMqpNcVJ64vbBoq2DePwdjg+B+LK6PmTDr9MIoZYRiDY3ts= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YvZ9gcRg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YvZ9gcRg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E107C43390; Sun, 24 Mar 2024 22:36:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319814; bh=DiYoUl9hVkKIa+xG9L0jGwjfOCAQrQdPAAxKOqq5xnE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YvZ9gcRgt8xBggvmgyTggPkbpCzNPmW7tEpi5K4w0bPO4prAKUyoWGzBaNQ9WDKc6 RFOI/Mo0ajMvGcjalAP5urSzawhDxifORdkjA3ldYq1++0VS1Fl+Xj5VPeQrvi+NHZ f8/VA1trgweF3Z2uqsVe9Mi+hrHgBUltjwwWmD3v1HcnmQi5UE1LM+wxwzqeokZq81 ShYAqnsysmlpcdsGORl9SqWlSjbgmgZREJ9Fy3IV6ESbec9fm8UevQiis2aaADnvhc Hz1GHUJ8l0ur6D4slckDHIRB3ExQywJ9rHUsFbP8LvfcgaS3HBsorf3HFhSY+sjSow GAJi5euzGVEVw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Frank Li , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 116/715] arm64: dts: imx8qm: Align edma3 power-domains resources indentation Date: Sun, 24 Mar 2024 18:24:55 -0400 Message-ID: <20240324223455.1342824-117-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Frank Li [ Upstream commit 7edee2b297e5a4f805e5b945c0c0e6f4f8f719b5 ] <&pd IMX_SC_R_DMA_1_CH*> is now properly aligned with the previous line for improved code readability. Signed-off-by: Frank Li Signed-off-by: Shawn Guo Stable-dep-of: 5136ea6b109d ("arm64: dts: imx8qm: Correct edma3 power-domai= ns and interrupt numbers") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi b/arch/arm64/= boot/dts/freescale/imx8qm-ss-dma.dtsi index 69cb8676732ea..453fabfd17b81 100644 --- a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi @@ -98,13 +98,13 @@ &edma2 { =20 &edma3 { power-domains =3D <&pd IMX_SC_R_DMA_1_CH0>, - <&pd IMX_SC_R_DMA_1_CH1>, - <&pd IMX_SC_R_DMA_1_CH2>, - <&pd IMX_SC_R_DMA_1_CH3>, - <&pd IMX_SC_R_DMA_1_CH4>, - <&pd IMX_SC_R_DMA_1_CH5>, - <&pd IMX_SC_R_DMA_1_CH6>, - <&pd IMX_SC_R_DMA_1_CH7>; + <&pd IMX_SC_R_DMA_1_CH1>, + <&pd IMX_SC_R_DMA_1_CH2>, + <&pd IMX_SC_R_DMA_1_CH3>, + <&pd IMX_SC_R_DMA_1_CH4>, + <&pd IMX_SC_R_DMA_1_CH5>, + <&pd IMX_SC_R_DMA_1_CH6>, + <&pd IMX_SC_R_DMA_1_CH7>; }; =20 &flexcan1 { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C368130AC8; Sun, 24 Mar 2024 22:36:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319815; cv=none; b=pjJS9CFRWz62PozR/Yw9VCBjNnliG59dGkRPtBBrYXBv2xutA6QcpoIMPu5/5YmVlqt8BZD5JJuiRbxM8x3u+RTz2lbNJfZA8uGZ8AvOw+pTcCGJsQXv6dzNwiApr6sg4MoBMtvY4yL+EAwJTXMjvUAMwa6+Br68QJXYwQUe3wY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319815; c=relaxed/simple; bh=EIbMxu/q2XMUhSWQMGGLvMeG00Row+WgL4DEBSSi048=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AHWHO/x5cVJaYW/zaPr/BZLE/vNbS2/Nf2COQx+QAunk1ER3h169XdppqcEFnsY5GjnErxD9lKQnajGqK8jlg/s7PMWOThGqwGJgywzSU1+I4QbAEjtvfMeTJtFgaW2JRACZvulmB6cDkKER/WV1Hha8F+xvXCN5OKLO4hcx1EA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AgeOh++F; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AgeOh++F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8976BC43394; Sun, 24 Mar 2024 22:36:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319815; bh=EIbMxu/q2XMUhSWQMGGLvMeG00Row+WgL4DEBSSi048=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AgeOh++FyCRiksr6g9S8uA536oLYmqFEycD4A6nP7YtKUVa7AEfZ318HUIMkz6GQ/ kQtbkCpDTOJseoe8rQhEkNAL81X2mfC5zzo7UnpdukK7j49A9AcTga9+ZMOBS8yAH/ Ti0l7mtXaiBkLywDbAIBs3jTgJqABs4CqG5a6DVMpKlnXzEL4i1tGO4zlbdMoTAUPj s9ooSBpSKn4Vbrthh1F86ou3cMO53Gw+EFKKgqy+otvCiNh+MCNA7okQ+g9zqFG5GG rUGQmW5bFJtIJLM7OZVugQVmX3m7FEbWkqNlLXTT6vpXZw2jvO7Xwn7W9xelRlMzTX np/iwIb6KNWEw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Frank Li , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 117/715] arm64: dts: imx8qm: Correct edma3 power-domains and interrupt numbers Date: Sun, 24 Mar 2024 18:24:56 -0400 Message-ID: <20240324223455.1342824-118-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Frank Li [ Upstream commit 5136ea6b109de66b1327a3069f88ad8f5efb37b2 ] It is eDMA1 at QM, which have the same register with eDMA3 at qxp. The below commit fix panic problem. commit b37e75bddc35 ("arm64: dts: imx8qm: Add imx8qm's own pm to avoid pani= c during startup") This fixes the IRQ and DMA channel numbers. While QM eDMA1 technically has 32 channels, only 10 channels are likely used for I2C. The exact IRQ numbers for the remaining channels were unclear in the reference manual. Fixes: e4d7a330fb7a ("arm64: dts: imx8: add edma[0..3]") Signed-off-by: Frank Li Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi b/arch/arm64/= boot/dts/freescale/imx8qm-ss-dma.dtsi index 453fabfd17b81..cafc1383115ab 100644 --- a/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8qm-ss-dma.dtsi @@ -96,7 +96,20 @@ &edma2 { status =3D "okay"; }; =20 +/* It is eDMA1 in 8QM RM, but 8QXP it is eDMA3 */ &edma3 { + reg =3D <0x5a9f0000 0x210000>; + dma-channels =3D <10>; + interrupts =3D , + , + , + , + , + , + , + , + , + ; power-domains =3D <&pd IMX_SC_R_DMA_1_CH0>, <&pd IMX_SC_R_DMA_1_CH1>, <&pd IMX_SC_R_DMA_1_CH2>, @@ -104,7 +117,9 @@ &edma3 { <&pd IMX_SC_R_DMA_1_CH4>, <&pd IMX_SC_R_DMA_1_CH5>, <&pd IMX_SC_R_DMA_1_CH6>, - <&pd IMX_SC_R_DMA_1_CH7>; + <&pd IMX_SC_R_DMA_1_CH7>, + <&pd IMX_SC_R_DMA_1_CH8>, + <&pd IMX_SC_R_DMA_1_CH9>; }; =20 &flexcan1 { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A303F130AF0; Sun, 24 Mar 2024 22:36:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319816; cv=none; b=jwJ8x2s/aQGBJsqaZZQruAqYweiwy7pkqcapE5vun4DlS0Ole5O7oKaQay9fIAi9y/Zb9RcuSuB6Jx02g9KZmDOg93w4ejG+vZGvf6AAmaKXcXIouQaoYGW6xJN8fC4/FWGh3FQjIKvzYiELYWm1OvnzBqcVSLZJpVY2HFb13LA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319816; c=relaxed/simple; bh=v7G71XpAS4tiF9hc66eXK5SwNfvpgF8Od1uEjij+cHg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RqAPuABDRCcmVPoYmHU6hgiNaskqKILtBF8nmoGOfZOual/FwIbQ6Rs232Aebwm115Cdm9mqvBJttIZ5Rn0b4xWGTQQi0Ow0mo9gXxizpcy31MAvPUl8VYPt7HuiDVRTL/yzlof1hi6doN9HqFTDrKaDTyYAMpQzxbdEdzob1zI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ete0feBV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ete0feBV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F53AC433A6; Sun, 24 Mar 2024 22:36:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319816; bh=v7G71XpAS4tiF9hc66eXK5SwNfvpgF8Od1uEjij+cHg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ete0feBVfHrCncrbkfowqj5GRp8LIBvupWxIHatgHxA6X4tuLeyNFEfCr0Zamn1Fe soWpsJqXjFZGNLQ2BDrxDijHJ+b/SH9E5rC0SgqTsjN0ASFvLVUJvsieqjw+xT6+1A PRrzJ0iSbSk7BtpCwEMhpknt6k0Z9lKzgQCAqDbmYH5J36U0mmatgTBbgyfTQeTN/8 e/2WF1IpSwjLh15UTyHPEurCl4iXCE/W0YKZx+ihHLor5E8ELZoVJx+D5KNc2Chv3d aLpIeLaufjQ2giCNKElz2jzc/1F0M1BcGfur3Xyku7FpOmyEC1+Vg91QsZ0jjh9y+U CeqalD3GEoUXQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrii Nakryiko , Daniel Borkmann , Eduard Zingerman , Sasha Levin Subject: [PATCH 6.8 118/715] libbpf: Add missing LIBBPF_API annotation to libbpf_set_memlock_rlim API Date: Sun, 24 Mar 2024 18:24:57 -0400 Message-ID: <20240324223455.1342824-119-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrii Nakryiko [ Upstream commit 93ee1eb85e28d1e35bb059c1f5965d65d5fc83c2 ] LIBBPF_API annotation seems missing on libbpf_set_memlock_rlim API, so add it to make this API callable from libbpf's shared library version. Fixes: e542f2c4cd16 ("libbpf: Auto-bump RLIMIT_MEMLOCK if kernel needs it f= or BPF") Fixes: ab9a5a05dc48 ("libbpf: fix up few libbpf.map problems") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20240201172027.604869-3-andrii@kernel.org Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/lib/bpf/bpf.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h index d0f53772bdc02..dad7917903d19 100644 --- a/tools/lib/bpf/bpf.h +++ b/tools/lib/bpf/bpf.h @@ -35,7 +35,7 @@ extern "C" { #endif =20 -int libbpf_set_memlock_rlim(size_t memlock_bytes); +LIBBPF_API int libbpf_set_memlock_rlim(size_t memlock_bytes); =20 struct bpf_map_create_opts { size_t sz; /* size of this struct for forward/backward compatibility */ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F996130E23; Sun, 24 Mar 2024 22:36:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319817; cv=none; b=LK3DRhayfdW555tto1wRYXNdUNlxbsAN6KbudqPWOOZ1Jghd9xb6UdsEzR7SjbG8qaXIUfaEFqQ3LVJHKBJmHPqwH/fJsP844rQxmPwMbJwpfOMp+cvXz16EzFuWME1rOQDH2BG6Y+EsvVpIU1QsW0tI3FSaOAEF1UV3mN/RHic= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319817; c=relaxed/simple; bh=x7MBC1LnLVlN1SIxN2lBwTgv8V2dAtUZ48xMLpKIpCQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W6iz7qOL7CBvwJs0mx3V2WEBLrOu0DDUqKBg6sV9nAX9CO/4dlBDbcR65iqvIFSgzgqSlBZ/nomWklzKuK0mmvbNJMZwt9Q7Q4wirLL/qlQMdmzVGXSuVVeso5EwA5t2TeZ8eoo8AxWIpWBEJDHAIT4yieeTevCpmLHvBDpcFqE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rwUts/lI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rwUts/lI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 70A0BC433C7; Sun, 24 Mar 2024 22:36:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319817; bh=x7MBC1LnLVlN1SIxN2lBwTgv8V2dAtUZ48xMLpKIpCQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rwUts/lIzI39a3Xe94iyzK0k6CmFD5m1XOs9MSZJnYDdUsFP9MEky+MQeGG+qHJJU /K87vyTyfzsAUqT0uBeiwtdqIjk7q2bYcQxGu7jqOkGyFcYJiJRhbvc6Kq9HL9utIR TlVP+iF9uv2vIoah5np75npC6XDcDJ4/osGipt8XKz4MCYkw8E8ZdhUT0svbkkQ5G3 tFv8ux8q4FQemNIg9Eui7oJDxdvBi4EOmh6kzgDUQrw/ghN5+nyOBuFT9F9b4pVQYF 0HxD2E2UyUHOXG1G/tmFHZTsEYiN8sMFVzqnjtdkAEokp3FlxNv1YcjaBFRI1oXm1I FZZwuNSfqgazA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrii Nakryiko , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 119/715] libbpf: Add bpf_token_create() API Date: Sun, 24 Mar 2024 18:24:58 -0400 Message-ID: <20240324223455.1342824-120-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrii Nakryiko [ Upstream commit 639ecd7d6247c48a0175f5b458b648f5d4b6dc34 ] Add low-level wrapper API for BPF_TOKEN_CREATE command in bpf() syscall. Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20240124022127.2379740-13-andrii@kernel.o= rg Stable-dep-of: c81a8ab196b5 ("libbpf: Add btf__new_split() API that was dec= lared but not implemented") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/lib/bpf/bpf.c | 17 +++++++++++++++++ tools/lib/bpf/bpf.h | 24 ++++++++++++++++++++++++ tools/lib/bpf/libbpf.map | 1 + 3 files changed, 42 insertions(+) diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c index 9dc9625651dcf..d4019928a8646 100644 --- a/tools/lib/bpf/bpf.c +++ b/tools/lib/bpf/bpf.c @@ -1287,3 +1287,20 @@ int bpf_prog_bind_map(int prog_fd, int map_fd, ret =3D sys_bpf(BPF_PROG_BIND_MAP, &attr, attr_sz); return libbpf_err_errno(ret); } + +int bpf_token_create(int bpffs_fd, struct bpf_token_create_opts *opts) +{ + const size_t attr_sz =3D offsetofend(union bpf_attr, token_create); + union bpf_attr attr; + int fd; + + if (!OPTS_VALID(opts, bpf_token_create_opts)) + return libbpf_err(-EINVAL); + + memset(&attr, 0, attr_sz); + attr.token_create.bpffs_fd =3D bpffs_fd; + attr.token_create.flags =3D OPTS_GET(opts, flags, 0); + + fd =3D sys_bpf_fd(BPF_TOKEN_CREATE, &attr, attr_sz); + return libbpf_err_errno(fd); +} diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h index dad7917903d19..02b0810c8dece 100644 --- a/tools/lib/bpf/bpf.h +++ b/tools/lib/bpf/bpf.h @@ -640,6 +640,30 @@ struct bpf_test_run_opts { LIBBPF_API int bpf_prog_test_run_opts(int prog_fd, struct bpf_test_run_opts *opts); =20 +struct bpf_token_create_opts { + size_t sz; /* size of this struct for forward/backward compatibility */ + __u32 flags; + size_t :0; +}; +#define bpf_token_create_opts__last_field flags + +/** + * @brief **bpf_token_create()** creates a new instance of BPF token deriv= ed + * from specified BPF FS mount point. + * + * BPF token created with this API can be passed to bpf() syscall for + * commands like BPF_PROG_LOAD, BPF_MAP_CREATE, etc. + * + * @param bpffs_fd FD for BPF FS instance from which to derive a BPF token + * instance. + * @param opts optional BPF token creation options, can be NULL + * + * @return BPF token FD > 0, on success; negative error code, otherwise (e= rrno + * is also set to the error code) + */ +LIBBPF_API int bpf_token_create(int bpffs_fd, + struct bpf_token_create_opts *opts); + #ifdef __cplusplus } /* extern "C" */ #endif diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map index 91c5aef7dae7d..d9e1f57534fa7 100644 --- a/tools/lib/bpf/libbpf.map +++ b/tools/lib/bpf/libbpf.map @@ -411,4 +411,5 @@ LIBBPF_1.3.0 { } LIBBPF_1.2.0; =20 LIBBPF_1.4.0 { + bpf_token_create; } LIBBPF_1.3.0; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2881B130E46; Sun, 24 Mar 2024 22:36:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319818; cv=none; b=P3GncP4mLjBYplsRekBoFhUWcJgmHriUt2T4t9Q+jhsx+vBPyxw3wLrv9FOU757SZ4puC7ta9oaXWTTDP5yrNJds5cjZqyay4Hv4KgfrpwEsVxdXyTAMUmySFgr9tJZQUBx1Aj6uPaff7p63gkoXMnzK6V0dWqy6YWQCwEleaIg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319818; c=relaxed/simple; bh=nf1lrAZt+kqjRBVh05F0G23Lf7AHK4xB6OibgOB8eR8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Qk1FqLgY4EQFexrPK+vodX1a5+054EyCLqHST3BSdGwu60oJf65Q0tDM2A01VqZFxL5Lq8yxeG+IUkr3HC1SQERg3lnGOisHVPkIHVJCsr7fjbuvUDGP/QC9RfQm9d1WM5iW5qYQ5pJiT8eT2QTfPg+ssGLxdb39Z5lxTSxv4n8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QX6z5iYZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QX6z5iYZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5318DC433C7; Sun, 24 Mar 2024 22:36:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319818; bh=nf1lrAZt+kqjRBVh05F0G23Lf7AHK4xB6OibgOB8eR8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QX6z5iYZ/PcMrI4br4nUGHFRV2BssGaLYEDxe+LR/rqwcboO5Yn/L02ZFvKrO6DZh swoQPCg8ve7A/vqyoKqQ7VJOt0ehpr4vgzdBKwzG2kOqk2QzDqAnzghRoObGi9Fp5Q Adicj9Wj+z2WQspAQEbRPOwjgc/PFx+NF5TY96Ah8wWxOXTuYuVDO9Lz4cRhkI097J eNHISBkcv6iVKiPQv9kyMbtak/tDOJzQirr1I/1eni8X4P0W+SwQYbW6DsD7qks641 d01eGLVlmk6gh9iDeqqHIfRFBhI1hOaeI7ctPHvFmTDuhiEFFavCbjgOdPkTn24NPY f2zfqwtliB/jg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrii Nakryiko , Daniel Borkmann , Eduard Zingerman , Sasha Levin Subject: [PATCH 6.8 120/715] libbpf: Add btf__new_split() API that was declared but not implemented Date: Sun, 24 Mar 2024 18:24:59 -0400 Message-ID: <20240324223455.1342824-121-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrii Nakryiko [ Upstream commit c81a8ab196b5083d5109a51585fcc24fa2055a77 ] Seems like original commit adding split BTF support intended to add btf__new_split() API, and even declared it in libbpf.map, but never added (trivial) implementation. Fix this. Fixes: ba451366bf44 ("libbpf: Implement basic split BTF support") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20240201172027.604869-4-andrii@kernel.org Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/lib/bpf/btf.c | 5 +++++ tools/lib/bpf/libbpf.map | 3 ++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c index ee95fd379d4d8..b61bc5d1009b7 100644 --- a/tools/lib/bpf/btf.c +++ b/tools/lib/bpf/btf.c @@ -1079,6 +1079,11 @@ struct btf *btf__new(const void *data, __u32 size) return libbpf_ptr(btf_new(data, size, NULL)); } =20 +struct btf *btf__new_split(const void *data, __u32 size, struct btf *base_= btf) +{ + return libbpf_ptr(btf_new(data, size, base_btf)); +} + static struct btf *btf_parse_elf(const char *path, struct btf *base_btf, struct btf_ext **btf_ext) { diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map index d9e1f57534fa7..386964f572a8f 100644 --- a/tools/lib/bpf/libbpf.map +++ b/tools/lib/bpf/libbpf.map @@ -245,7 +245,6 @@ LIBBPF_0.3.0 { btf__parse_raw_split; btf__parse_split; btf__new_empty_split; - btf__new_split; ring_buffer__epoll_fd; } LIBBPF_0.2.0; =20 @@ -411,5 +410,7 @@ LIBBPF_1.3.0 { } LIBBPF_1.2.0; =20 LIBBPF_1.4.0 { + global: bpf_token_create; + btf__new_split; } LIBBPF_1.3.0; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 255F013172A; Sun, 24 Mar 2024 22:36:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319819; cv=none; b=gc8JcvbeqemEfhT3pPnvSvnMdnlH3jsrGLQPeJcJvb2RXyXLMLmi4AD9QrD2Uu2X9V68Xjx2BucQpJOpIvsRoKGsvjwpA6Y8lZ/rEnANIViVy2vvkPSNYX/UJ5VUTzo4sHw0iTwxYoBTf/Bn5AFRh6I9T98UI0VT0VB9795mAhw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319819; c=relaxed/simple; bh=ub5gTDg45u7ZTcHGkS5iJFn3fIXQKswUIcupG71O8js=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rs90tazKUNNiyISn4PdZQKusWu7yQINdYYYHkQ7CjGCRisiyqlXZX+7Hu8LX39nvxQpkvHke2AgRlbQNuZ3bjYhHDyKS+hXHQuW+9maUgLGZ5Q4Y6mIKcqPU6J5kf8CL9zSu8nI8o3ybgjKjZ2sdlbZwM3T4jrM0xHLUMM0a7fY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NZunQo7E; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NZunQo7E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4DBADC433F1; Sun, 24 Mar 2024 22:36:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319819; bh=ub5gTDg45u7ZTcHGkS5iJFn3fIXQKswUIcupG71O8js=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NZunQo7ETtp8cYDeJ2Pa5JpKbidqe414BYoHJbwXOV3c+m5IOPpYWlbNY3A5cjLDI kOXGBgAjLo0Usnt7wVP0iVDcdNjzSWJJbyGVWyl9LZmW12jrFyX1gh/umMJiYskG8L 0+9AcAx3APKGek+Iku6/BUKslDHTwWTDtpS1jRHfgwtme2EoSrA/nPjVNkJa6onCE4 nPmfA8WFYtE8oJqB3SFYaRZeZTL5PQSKG7OENClxnv23nN5Yh/rYFc61jkgQnIWjHy mjmME/pPn8hDZao3PzV5LU9EhpkJ+NIRmAjbdmMowtw8Vo8hSXDk2hhPGBzY8gFjMv GjzkMmq87qUGg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrii Nakryiko , Daniel Borkmann , Eduard Zingerman , Sasha Levin Subject: [PATCH 6.8 121/715] libbpf: Add missed btf_ext__raw_data() API Date: Sun, 24 Mar 2024 18:25:00 -0400 Message-ID: <20240324223455.1342824-122-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrii Nakryiko [ Upstream commit b9551da8cf3ade01a50316df8a618fd945723ee0 ] Another API that was declared in libbpf.map but actual implementation was missing. btf_ext__get_raw_data() was intended as a discouraged alias to consistently-named btf_ext__raw_data(), so make this an actuality. Fixes: 20eccf29e297 ("libbpf: hide and discourage inconsistently named gett= ers") Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Acked-by: Eduard Zingerman Link: https://lore.kernel.org/bpf/20240201172027.604869-5-andrii@kernel.org Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/lib/bpf/btf.c | 6 +++++- tools/lib/bpf/libbpf.map | 2 +- tools/lib/bpf/linker.c | 2 +- 3 files changed, 7 insertions(+), 3 deletions(-) diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c index b61bc5d1009b7..119d45eadb2ed 100644 --- a/tools/lib/bpf/btf.c +++ b/tools/lib/bpf/btf.c @@ -3044,12 +3044,16 @@ struct btf_ext *btf_ext__new(const __u8 *data, __u3= 2 size) return btf_ext; } =20 -const void *btf_ext__get_raw_data(const struct btf_ext *btf_ext, __u32 *si= ze) +const void *btf_ext__raw_data(const struct btf_ext *btf_ext, __u32 *size) { *size =3D btf_ext->data_size; return btf_ext->data; } =20 +__attribute__((alias("btf_ext__raw_data"))) +const void *btf_ext__get_raw_data(const struct btf_ext *btf_ext, __u32 *si= ze); + + struct btf_dedup; =20 static struct btf_dedup *btf_dedup_new(struct btf *btf, const struct btf_d= edup_opts *opts); diff --git a/tools/lib/bpf/libbpf.map b/tools/lib/bpf/libbpf.map index 386964f572a8f..86804fd90dd1a 100644 --- a/tools/lib/bpf/libbpf.map +++ b/tools/lib/bpf/libbpf.map @@ -325,7 +325,6 @@ LIBBPF_0.7.0 { bpf_xdp_detach; bpf_xdp_query; bpf_xdp_query_id; - btf_ext__raw_data; libbpf_probe_bpf_helper; libbpf_probe_bpf_map_type; libbpf_probe_bpf_prog_type; @@ -413,4 +412,5 @@ LIBBPF_1.4.0 { global: bpf_token_create; btf__new_split; + btf_ext__raw_data; } LIBBPF_1.3.0; diff --git a/tools/lib/bpf/linker.c b/tools/lib/bpf/linker.c index 16bca56002ab3..0d4be829551b5 100644 --- a/tools/lib/bpf/linker.c +++ b/tools/lib/bpf/linker.c @@ -2732,7 +2732,7 @@ static int finalize_btf(struct bpf_linker *linker) =20 /* Emit .BTF.ext section */ if (linker->btf_ext) { - raw_data =3D btf_ext__get_raw_data(linker->btf_ext, &raw_sz); + raw_data =3D btf_ext__raw_data(linker->btf_ext, &raw_sz); if (!raw_data) return -ENOMEM; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2024113175C; Sun, 24 Mar 2024 22:37:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319820; cv=none; b=f3Q87IG8olraiynSdcvbjlaHbDgLcTyfjZL2uWUH38Vp5SQpv9G73hxJyMCfaqpP24oMSlSlN4hJHu+1H+iAEJwc0ry1FsywLrow6pIEOHNLfSAL6VjFgNJkaX0L9x5MqfW9tH7MG0csgbTiH9Vu/KAi+MnZP/6ole/2L07Tr2o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319820; c=relaxed/simple; bh=rM3dsPA2kSnTAIx0YDesNOq5Kux+L3ZJpjx1smEwXuw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=j9LfLstoPIktDxMkEjdHI4+g3AzryFSvl85CIMZ8f6c88VLbdkk6wRkUOy6JZAEQhBiGQo/8aJfNn3XOv2p3muSxbcuCX7fQY0DAQ82giXICpwDQaTvm+pODr5VIaLQfAPBgsvQuFDRzygB8DZwqvvMv1Zafc0/bGm+NyVw5d+g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C+Ji2PQZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="C+Ji2PQZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49896C433C7; Sun, 24 Mar 2024 22:36:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319820; bh=rM3dsPA2kSnTAIx0YDesNOq5Kux+L3ZJpjx1smEwXuw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C+Ji2PQZVS25YKD55zRqObEfE8JU0ZOcZYx7SEBm6JVAi7JtGP0d/0oZ2mNW9LFVU 0BNVaQhm94n6+fI1H2Rpr4AfKs4poqX4HS8pmI5lzw/l0xr8L1BSWmfNneKORdoWxc ygpe8P+2z9dnCWQx3CZx861xoIzCyIJIel2nl+r7qv4xxOWao6Q1zhU+gNKyNbVOLi FK2zfAsMiTIMjAvqVu/nLXBAq0wCpeRma7z2r980MtJAYYrSRUqYWcnMCQbiaIs7vC T+s+1sqi7TLWU4xzjOVm1LbBAi97SQ4pCblB4azqMpvu0DyUQcGHfqUM104P8o3i6r WNaWeGFz/D6HQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= , Ubisectech Sirius , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 122/715] wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete Date: Sun, 24 Mar 2024 18:25:01 -0400 Message-ID: <20240324223455.1342824-123-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Toke H=C3=B8iland-J=C3=B8rgensen [ Upstream commit 24355fcb0d4cbcb6ddda262596558e8cfba70f11 ] The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data structures have been fully initialised by the time it runs. However, becaus= e of the order in which things are initialised, this is not guaranteed to be the case, because the device is exposed to the USB subsystem before the ath9k d= river initialisation is completed. We already committed a partial fix for this in commit: 8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_= packet()") However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the e= vent tasklet, pairing it with an "initialisation complete" bit in the TX struct.= It seems syzbot managed to trigger the race for one of the other commands as w= ell, so let's just move the existing synchronisation bit to cover the whole tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside ath9k_tx_init()). Link: https://lore.kernel.org/r/ed1d2c66-1193-4c81-9542-d514c29ba8b8.bugrep= ort@ubisectech.com Fixes: 8b3046abc99e ("ath9k_htc: fix NULL pointer dereference at ath9k_htc_= tx_get_packet()") Reported-by: Ubisectech Sirius Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen Signed-off-by: Kalle Valo Link: https://msgid.link/20240126140218.1033443-1-toke@toke.dk Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/ath/ath9k/htc.h | 2 +- drivers/net/wireless/ath/ath9k/htc_drv_init.c | 4 ++++ drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 4 ---- drivers/net/wireless/ath/ath9k/wmi.c | 10 ++++++---- 4 files changed, 11 insertions(+), 9 deletions(-) diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/at= h/ath9k/htc.h index 237f4ec2cffd7..6c33e898b3000 100644 --- a/drivers/net/wireless/ath/ath9k/htc.h +++ b/drivers/net/wireless/ath/ath9k/htc.h @@ -306,7 +306,6 @@ struct ath9k_htc_tx { DECLARE_BITMAP(tx_slot, MAX_TX_BUF_NUM); struct timer_list cleanup_timer; spinlock_t tx_lock; - bool initialized; }; =20 struct ath9k_htc_tx_ctl { @@ -515,6 +514,7 @@ struct ath9k_htc_priv { unsigned long ps_usecount; bool ps_enabled; bool ps_idle; + bool initialized; =20 #ifdef CONFIG_MAC80211_LEDS enum led_brightness brightness; diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wi= reless/ath/ath9k/htc_drv_init.c index 0aa5bdeb44a1b..3633f9eb2c559 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c @@ -966,6 +966,10 @@ int ath9k_htc_probe_device(struct htc_target *htc_hand= le, struct device *dev, =20 htc_handle->drv_priv =3D priv; =20 + /* Allow ath9k_wmi_event_tasklet() to operate. */ + smp_wmb(); + priv->initialized =3D true; + return 0; =20 err_init: diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wi= reless/ath/ath9k/htc_drv_txrx.c index efcaeccb055aa..ce9c04e418b8d 100644 --- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c +++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c @@ -815,10 +815,6 @@ int ath9k_tx_init(struct ath9k_htc_priv *priv) skb_queue_head_init(&priv->tx.data_vo_queue); skb_queue_head_init(&priv->tx.tx_failed); =20 - /* Allow ath9k_wmi_event_tasklet(WMI_TXSTATUS_EVENTID) to operate. */ - smp_wmb(); - priv->tx.initialized =3D true; - return 0; } =20 diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/at= h/ath9k/wmi.c index 1476b42b52a91..805ad31edba2b 100644 --- a/drivers/net/wireless/ath/ath9k/wmi.c +++ b/drivers/net/wireless/ath/ath9k/wmi.c @@ -155,6 +155,12 @@ void ath9k_wmi_event_tasklet(struct tasklet_struct *t) } spin_unlock_irqrestore(&wmi->wmi_lock, flags); =20 + /* Check if ath9k_htc_probe_device() completed. */ + if (!data_race(priv->initialized)) { + kfree_skb(skb); + continue; + } + hdr =3D (struct wmi_cmd_hdr *) skb->data; cmd_id =3D be16_to_cpu(hdr->command_id); wmi_event =3D skb_pull(skb, sizeof(struct wmi_cmd_hdr)); @@ -169,10 +175,6 @@ void ath9k_wmi_event_tasklet(struct tasklet_struct *t) &wmi->drv_priv->fatal_work); break; case WMI_TXSTATUS_EVENTID: - /* Check if ath9k_tx_init() completed. */ - if (!data_race(priv->tx.initialized)) - break; - spin_lock_bh(&priv->tx.tx_lock); if (priv->tx.flags & ATH9K_HTC_OP_TX_DRAIN) { spin_unlock_bh(&priv->tx.tx_lock); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2BF21131E3D; Sun, 24 Mar 2024 22:37:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319821; cv=none; b=p4bgB+DKUn9pKy/xYrzGZxaKBpAEJD/T6/RRd6GlraAlbxS1QBvkb8QwOkui49Q+7aGuWBYeCCZ/iKe6OaAKlV3rcwLeayldcuCsM+e6Bpjaqxnurbtl6YyrFZUviQU9yVf7ZVEue/Tdk7K15tYCjmsoIqMajJgGETqrynYGrL0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319821; c=relaxed/simple; bh=/lZFRa509+d8US95VkuY8rBTEAwtCvjx3GyeNYLjDC0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XcVJPqcQz8iy3HEo4SnM8sLk5p+qUTAhWZvQ3jShnx8FxeTj/Ek26MwaB0RoHEQl4IPfGbxPNYuUZFt7C7c7yzuB3+cKRI8MYZ1brBTMMo7Nf6YQBY8HwKarpIXc8Y/uO2dNVYNrqxAG06eEH3RYWwoZ0aD5ZGk+RPuLzivXCks= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BXFHXH2U; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BXFHXH2U" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4268EC433F1; Sun, 24 Mar 2024 22:37:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319821; bh=/lZFRa509+d8US95VkuY8rBTEAwtCvjx3GyeNYLjDC0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BXFHXH2UK/N/7rFGI2HlTKRTVgPWuAXLsl7xG0ob15e8kxwJxaJm/wjVDlxGtKpvr yrc7ll4z37Ae3O0RNcGy+4YHg5rmR1K+3uD/9mVzGEkZnQEc1LtF5r+yPk63But6SB RvijN8N9ZX+2TJ2lfQZYSpdlev6g27BISGECT3g4hChCbPOsgLnnft7Cskyg4HzLUo 5DP6+n5ITFPhEY5HDsqyz6ez7iPFUlA44RisffF6guOVRstIjCxNAcu6KQ3SPYO9fw ZZ8Wf3lG5mrgtXXssnNyt/6ofGmA8ZxocF4o6lfoRAPDjrtI3QkPI5jDrpw1NDNmpZ eGeeZp5qxFhKQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Wen Gong , Baochen Qiang , Jeff Johnson , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 123/715] wifi: ath11k: change to move WMI_VDEV_PARAM_SET_HEMU_MODE before WMI_PEER_ASSOC_CMDID Date: Sun, 24 Mar 2024 18:25:02 -0400 Message-ID: <20240324223455.1342824-124-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Wen Gong [ Upstream commit 413e20e82ee78f142cb5194fd317db514f012602 ] Currently when connecting to an AP with 11AX-HE phy mode, host sends WMI_VDEV_PARAM_SET_HEMU_MODE parameter to firmware after WMI_PEER_ASSOC_CMDID command. This results in TXBF not working, because firmware calculates TXBF values while handling WMI_PEER_ASSOC_CMDID, however at that time WMI_VDEV_PARAM_SET_HEMU_MODE has not been sent yet. See below log: AP sends "VHT/HE/EHT NDP Announcement" to station, and station sends "Action no Ack" of category code HE to AP, the "Nc Index" and "Codebook Information" are wrong: Issued action: IEEE 802.11 Action No Ack, Flags: ........ IEEE 802.11 wireless LAN Fixed parameters Category code: HE (30) HE Action: HE Compressed Beamforming And CQI (0) Total length: 152 HE MIMO Control: 0x0004008018 .... .... .... .... .... .... .... .... .... .000 =3D Nc In= dex: 1 Column (0) .... .... .... .... .... .... .... ..0. .... .... =3D Codeb= ook Information: 0 Change to send WMI_VDEV_PARAM_SET_HEMU_MODE before WMI_PEER_ASSOC_CMDID, then firmware will calculate the TXBF values with valid parameters instead of empty values. TXBF works well and throughput performance is improved from 80 Mbps to 130 Mbps with this patch. Good action after this patch: IEEE 802.11 Action No Ack, Flags: ........ IEEE 802.11 wireless LAN Fixed parameters Category code: HE (30) HE Action: HE Compressed Beamforming And CQI (0) Total length: 409 HE MIMO Control: 0x0004008219 .... .... .... .... .... .... .... .... .... .001 =3D Nc In= dex: 2 Columns (1) .... .... .... .... .... .... .... ..1. .... .... =3D Codeb= ook Information: 1 This change applies to all chipsets. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_L= ITE-3.6510.23 Fixes: 38dfe775d0ab ("wifi: ath11k: push MU-MIMO params from hostapd to har= dware") Signed-off-by: Wen Gong Signed-off-by: Baochen Qiang Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240131021832.17298-1-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/ath/ath11k/mac.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/a= th/ath11k/mac.c index b13525bbbb808..b6b474a7f1c9c 100644 --- a/drivers/net/wireless/ath/ath11k/mac.c +++ b/drivers/net/wireless/ath/ath11k/mac.c @@ -3026,7 +3026,14 @@ static void ath11k_bss_assoc(struct ieee80211_hw *hw, =20 rcu_read_unlock(); =20 + if (!ath11k_mac_vif_recalc_sta_he_txbf(ar, vif, &he_cap)) { + ath11k_warn(ar->ab, "failed to recalc he txbf for vdev %i on bss %pM\n", + arvif->vdev_id, bss_conf->bssid); + return; + } + peer_arg.is_assoc =3D true; + ret =3D ath11k_wmi_send_peer_assoc_cmd(ar, &peer_arg); if (ret) { ath11k_warn(ar->ab, "failed to run peer assoc for %pM vdev %i: %d\n", @@ -3049,12 +3056,6 @@ static void ath11k_bss_assoc(struct ieee80211_hw *hw, return; } =20 - if (!ath11k_mac_vif_recalc_sta_he_txbf(ar, vif, &he_cap)) { - ath11k_warn(ar->ab, "failed to recalc he txbf for vdev %i on bss %pM\n", - arvif->vdev_id, bss_conf->bssid); - return; - } - WARN_ON(arvif->is_up); =20 arvif->aid =3D vif->cfg.aid; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 61AFB132492; Sun, 24 Mar 2024 22:37:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319822; cv=none; b=H7PKMHyIEy45Ing8Pu7ymAiWnj0LGH88hi8mLUuDpCUuzTPhXitMVmV0YqD12AihEPOmlyhRRhgua9gG9D4hBUO5USwYqXLMXaBmORPv/w3TdBz1T6f6G6urexCEfFYlJdqtQXdqpZLerpjW03TipmpsiHR2R2EMud/3ZsuSkBc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319822; c=relaxed/simple; bh=CCMTvASji0/stHiT5ImMEo2vqL9mPQDDspFCl9RXgnw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KAf28DxIsPUM45o/9mXyr1TDtVgrYMr1q6LOFP8e2995g1khMKBMStmtun7G2GF+5ZJbYXSww+vwJ5I+IVadORn/eqkWn+jnI+aeQLrXInobdHpQ7/f6ftwYHCWiSo6s9NmZ0oCG2LIjzLQwg5O0ciIi0lu8h6wxiVGVpiAyOyA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=plO59LZM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="plO59LZM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 505D7C43394; Sun, 24 Mar 2024 22:37:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319822; bh=CCMTvASji0/stHiT5ImMEo2vqL9mPQDDspFCl9RXgnw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=plO59LZMxM2D1ai6tS0+AVbxeNPsEgDW4/FCynbQfAmkcbz9SaFHpOTVqXuu83Fzo dmuObQz/K7RJA/AwoYslTiFG3rIGZusVbDTcy/wJ2EY4lanzFtAR9uQPJ4nkd/BWPc IS/HJo3qUBoSFGUTYAPZw4N46uH/yvjCni2hvqnuBMCT4NxbLQczwlsiw+25+hxsTw T0SALn8VHaN+GsDja781YldPUZVQCxkkuboIjWhoIxFj4Q0+1Aa0JXvhAi83LwZyV8 uMnB0+uGQI5rk7QteOF065IY8xheckGymLmPVmwT0Gp0OnWZIQifVuAp5x5P6IQxVZ eIgPpX/JOdBjw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Raj Kumar Bhagat , Jeff Johnson , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 124/715] wifi: ath12k: fix fetching MCBC flag for QCN9274 Date: Sun, 24 Mar 2024 18:25:03 -0400 Message-ID: <20240324223455.1342824-125-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Raj Kumar Bhagat [ Upstream commit 902700d55d4a4522bb3eb4ef94f752a19c42230a ] In QCN9274, RX packet's multicast and broadcast(MCBC) flag is fetched from RX descriptor's msdu_end info5 member but it is not correct for QCN9274. Due to this with encryption, ARP request packet is wrongly marked as MCBC packet and it is sent to mac80211 without setting RX_FLAG_PN_VALIDATED & RX_FLAG_DECRYPTED flag. This results in packet getting dropped in mac80211. Hence ping initiated from station to AP fails. Fix this by fetching correct MCBC flag in case of QCN9274. For QC9274 MCBC flag should be fetched from RX descriptor's mpdu_start info6 member. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00188-QCAHKSWPL_SILICONZ-1 Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1 Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SIL= ICONZ-3 Fixes: 8f04852e90cb ("wifi: ath12k: Use msdu_end to check MCBC") Signed-off-by: Raj Kumar Bhagat Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240129065724.2310207-5-quic_rajkbhag@quicinc.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/ath/ath12k/hal.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/ath/ath12k/hal.c b/drivers/net/wireless/a= th/ath12k/hal.c index a489369d80687..1bdab8604db94 100644 --- a/drivers/net/wireless/ath/ath12k/hal.c +++ b/drivers/net/wireless/ath/ath12k/hal.c @@ -1,7 +1,7 @@ // SPDX-License-Identifier: BSD-3-Clause-Clear /* * Copyright (c) 2018-2021 The Linux Foundation. All rights reserved. - * Copyright (c) 2021-2023 Qualcomm Innovation Center, Inc. All rights res= erved. + * Copyright (c) 2021-2024 Qualcomm Innovation Center, Inc. All rights res= erved. */ #include #include "hal_tx.h" @@ -449,8 +449,8 @@ static u8 *ath12k_hw_qcn9274_rx_desc_mpdu_start_addr2(s= truct hal_rx_desc *desc) =20 static bool ath12k_hw_qcn9274_rx_desc_is_da_mcbc(struct hal_rx_desc *desc) { - return __le16_to_cpu(desc->u.qcn9274.msdu_end.info5) & - RX_MSDU_END_INFO5_DA_IS_MCBC; + return __le32_to_cpu(desc->u.qcn9274.mpdu_start.info6) & + RX_MPDU_START_INFO6_MCAST_BCAST; } =20 static void ath12k_hw_qcn9274_rx_desc_get_dot11_hdr(struct hal_rx_desc *de= sc, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8171513342A; Sun, 24 Mar 2024 22:37:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319823; cv=none; b=kkQQgYXdt7a3M8/K+YwaYhV76hiA7jOr3z/TNLl09KFEkLGBEcahRU2AIuY7eeifSdIVbIZx+DKsYlBgt8/3VIq9iHWgxRmWcxFhSLzAptY6d2+0fPng0VsStLr+eN95i6K039ep7Ntp1inkYZBcaHtaZqUoUA6H88B1osguGMQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319823; c=relaxed/simple; bh=bTEChCyEJj/3Nl554eWTVKSB0lt5bi1igmaG3wMuy3k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gmOuinNr6ICVxjHf4GSMxkmGNCLIe9Xqb1wmXQoSvpZpPsZZvR2BGJGtEqGLVUlJVNBMvidv4V4ONho+BpHOe2h8ef4GByrONGOB5SjCB+iNri9Caj0rHIi+9kcxhth9jpH3m2nHu1cT6po8MWW/3ILiNXvHtL4NGUQS5cY0GLU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K0qqcDpb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K0qqcDpb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 498C7C433C7; Sun, 24 Mar 2024 22:37:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319823; bh=bTEChCyEJj/3Nl554eWTVKSB0lt5bi1igmaG3wMuy3k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K0qqcDpb8eIF6FBe2D8XAs0JEQDjJ7zqjJvvqQ2d39gYvKOpKexWjfMkwgMLSbaK7 tNm1n2tCXCk5pts/BdRVx+j1nYT2wLf8Yi8jV2MAeGqEWFzXD6pt6aDsOhNqqdnGcE Wf58Qrg1J+fcnZLHeZ4I3eRUGTJS8iUbb2h5PAuUHC2xpX9zHees4Vm0mKlz+StkyO AwOmX1u+jQvZzGLY/+L4a3L7OtlkkElJX8LrlU9qMcmfjJXpfatIgqOWgUEn1X1jL1 2VplpHs788W9Sk2WK5yuU/Ot04hoXqSfQFIM4+or8YVwV/qTmCNt/UOYLBXpiR8nEA IVVNOIbyChetQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johannes Berg , Andrei Otcheretianski , Gregory Greenman , Miri Korenblit , Sasha Levin Subject: [PATCH 6.8 125/715] wifi: iwlwifi: mvm: report beacon protection failures Date: Sun, 24 Mar 2024 18:25:04 -0400 Message-ID: <20240324223455.1342824-126-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johannes Berg [ Upstream commit 91380f768d7f6e3d003755defa792e9a00a1444a ] Andrei reports that we just silently drop beacons after we report the key counters, but never report to userspace, so wpa_supplicant cannot send the WNM action frame. Fix that. Fixes: b1fdc2505abc ("iwlwifi: mvm: advertise BIGTK client support if avail= able") Reported-by: Andrei Otcheretianski Signed-off-by: Johannes Berg Reviewed-by: Gregory Greenman Signed-off-by: Miri Korenblit Link: https://msgid.link/20240128084842.7d855442cdce.Iba90b26f893dc8c49bfb8= be65373cd0a138af12c@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c | 26 +++++++++++-------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c b/drivers/net/wi= reless/intel/iwlwifi/mvm/rxmq.c index af15d470c69bd..7bf2a5947e5e9 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c @@ -282,6 +282,7 @@ static int iwl_mvm_rx_mgmt_prot(struct ieee80211_sta *s= ta, u32 status, struct ieee80211_rx_status *stats) { + struct wireless_dev *wdev; struct iwl_mvm_sta *mvmsta; struct iwl_mvm_vif *mvmvif; u8 keyid; @@ -303,9 +304,15 @@ static int iwl_mvm_rx_mgmt_prot(struct ieee80211_sta *= sta, if (!ieee80211_is_beacon(hdr->frame_control)) return 0; =20 + if (!sta) + return -1; + + mvmsta =3D iwl_mvm_sta_from_mac80211(sta); + mvmvif =3D iwl_mvm_vif_from_mac80211(mvmsta->vif); + /* key mismatch - will also report !MIC_OK but we shouldn't count it */ if (!(status & IWL_RX_MPDU_STATUS_KEY_VALID)) - return -1; + goto report; =20 /* good cases */ if (likely(status & IWL_RX_MPDU_STATUS_MIC_OK && @@ -314,13 +321,6 @@ static int iwl_mvm_rx_mgmt_prot(struct ieee80211_sta *= sta, return 0; } =20 - if (!sta) - return -1; - - mvmsta =3D iwl_mvm_sta_from_mac80211(sta); - - mvmvif =3D iwl_mvm_vif_from_mac80211(mvmsta->vif); - /* * both keys will have the same cipher and MIC length, use * whichever one is available @@ -329,11 +329,11 @@ static int iwl_mvm_rx_mgmt_prot(struct ieee80211_sta = *sta, if (!key) { key =3D rcu_dereference(mvmvif->bcn_prot.keys[1]); if (!key) - return -1; + goto report; } =20 if (len < key->icv_len + IEEE80211_GMAC_PN_LEN + 2) - return -1; + goto report; =20 /* get the real key ID */ keyid =3D frame[len - key->icv_len - IEEE80211_GMAC_PN_LEN - 2]; @@ -347,7 +347,7 @@ static int iwl_mvm_rx_mgmt_prot(struct ieee80211_sta *s= ta, return -1; key =3D rcu_dereference(mvmvif->bcn_prot.keys[keyid - 6]); if (!key) - return -1; + goto report; } =20 /* Report status to mac80211 */ @@ -355,6 +355,10 @@ static int iwl_mvm_rx_mgmt_prot(struct ieee80211_sta *= sta, ieee80211_key_mic_failure(key); else if (status & IWL_RX_MPDU_STATUS_REPLAY_ERROR) ieee80211_key_replay(key); +report: + wdev =3D ieee80211_vif_to_wdev(mvmsta->vif); + if (wdev->netdev) + cfg80211_rx_unprot_mlme_mgmt(wdev->netdev, (void *)hdr, len); =20 return -1; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83B294D9FE; Sun, 24 Mar 2024 22:37:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319824; cv=none; b=L0cvC+K6KqywiiDNj1V0wKA/pDbRZWHs0CIs6ouph3FFvverdgl7uVztOQfTxluCGz7H4j3cyqe6lgU/70PVHG5DGmUavrG/fDzDzbwWMsyGO2hjtPVKj9E6imZPjDmHM+bHr+68xefH2Pfu2wCjfAOMPp4R76HMH1pXuIoKo2E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319824; c=relaxed/simple; bh=KO8U+3kFg3Bhq9PhySBL+icUpyYJRdIbG31x0XFRssg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KOHjQshuQ+dBp/BhmmbtzxqxVlqv4zd8eUr5BJnA9zHSOQEuv4kB5dwjX6MWkzYftraXMKV6ZD9I57F7UJuwFu3/c4p8iZz0uqZrXMHfs3EabaTXjqm+kgtlpDV33RuoPdsWBpRi2vW9OeOVGzXVynYIWkUa0euMiQupfXQfKfY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=so3dOg46; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="so3dOg46" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B547C43399; Sun, 24 Mar 2024 22:37:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319824; bh=KO8U+3kFg3Bhq9PhySBL+icUpyYJRdIbG31x0XFRssg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=so3dOg46Wus2pk/VDih58Kpi9JxT+iokXS6HtoOxaQYdinYQOXhbaoyJBWQUhtOND iMDmzssIVWp3jkV+COCQT8hnm7e0l4n9yL/v3PRqpYYwD+70bk+Imy456/2Xn9S8V8 l1MMaDeFzjCPM74V+PldDplnOsTZP/dC04ySm4gm6CAGFtdDGLnDjsI3dRIPVbULmT nMR6/eyX0xHAqQHL4qmIlM9GUc0+C+jtgYXvoJdcE5wLAV9mf9s4KmoIwsaiHHy9jy EbieDA939jliej59EUSVpDmz9bf7NyYQ2M1hV1ODaKyRBlCvH7vCz2HHByP3fobFcJ Vuulc65JfxCKQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johannes Berg , Gregory Greenman , Miri Korenblit , Sasha Levin Subject: [PATCH 6.8 126/715] wifi: iwlwifi: dbg-tlv: ensure NUL termination Date: Sun, 24 Mar 2024 18:25:05 -0400 Message-ID: <20240324223455.1342824-127-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johannes Berg [ Upstream commit ea1d166fae14e05d49ffb0ea9fcd4658f8d3dcea ] The iwl_fw_ini_debug_info_tlv is used as a string, so we must ensure the string is terminated correctly before using it. Fixes: a9248de42464 ("iwlwifi: dbg_ini: add TLV allocation new API support") Signed-off-by: Johannes Berg Reviewed-by: Gregory Greenman Signed-off-by: Miri Korenblit Link: https://msgid.link/20240128084842.be15e858ee89.Ibff93429cf999eafc7b26= f3eef4c055dc84984a0@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c b/drivers/net= /wireless/intel/iwlwifi/iwl-dbg-tlv.c index 72075720969c0..3442dfab50b53 100644 --- a/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c +++ b/drivers/net/wireless/intel/iwlwifi/iwl-dbg-tlv.c @@ -103,6 +103,12 @@ static int iwl_dbg_tlv_alloc_debug_info(struct iwl_tra= ns *trans, if (le32_to_cpu(tlv->length) !=3D sizeof(*debug_info)) return -EINVAL; =20 + /* we use this as a string, ensure input was NUL terminated */ + if (strnlen(debug_info->debug_cfg_name, + sizeof(debug_info->debug_cfg_name)) =3D=3D + sizeof(debug_info->debug_cfg_name)) + return -EINVAL; + IWL_DEBUG_FW(trans, "WRT: Loading debug cfg: %s\n", debug_info->debug_cfg_name); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A0AB1350E3; Sun, 24 Mar 2024 22:37:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319825; cv=none; b=C1RX5sPooUt2GxMRBXiu7nF4Y3h9gOk1xfIEDkm/QuXXHK8MCWDEaQNEP7OmqY7xWG85c1yvfPEe0cihmBrGUH2FaOk2INic7HQ/PWd8zw9WifCgdh5IJDtoieGCdbv5n6NtiQ3ur6WrCOumMCc+QdqFkSlt2cLSrDaX00NVFBc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319825; c=relaxed/simple; bh=Q33wawuXrNE4Ttm2focUd5VKY7etrwROUKCZsilVbIM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bVC9SbOQ369rSghZN5zLMAmbgSNBpcsMTZCPHQa7MUyjxOzMczB7soX3dqfO7HRDmvnpxrznFSwv5r9JvZRatJmC6jjDm8pg8xkWSaTQUuIZKrxzoSKIqP0GKm3SzZ0JZ9M9EuCm5KSXSUxSk18cJ1F2S6VdE0CjIay/abUs+EM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o5vHsjiM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="o5vHsjiM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53958C43390; Sun, 24 Mar 2024 22:37:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319825; bh=Q33wawuXrNE4Ttm2focUd5VKY7etrwROUKCZsilVbIM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o5vHsjiMOiNdW1xVZ1LBZUt0tjYteR+t2urmZPBIOG7edJcdgdSl8yVn/JYZ/s2Xu oCLs7VKcN5y5h7ipEqwjB0LuC0mxHVAmqIoUuUqQVi1PfLij3yRNlpnqrsW+e9K8TS /BpezmnfC4cBWmTaR38mptk2z1FCm37DKVL5d5bMBUQc+IcisK2Wpi7w4aVBlD6oLs Z/e5fiHBPLjdzmpPvXpE/Pft+RawYd/q4RVp2Sy+qzlJcnDqnoGY8lc+v32nt1l5RN uD9teu3AELCmSBwGI7UD0RQX1rXZMehgO+A5YyIRfcl7EuMBW832ZQlcx7cSdqONUq xizDP0zJeFfAA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johannes Berg , Miri Korenblit , Gregory Greenman Gregory , Sasha Levin Subject: [PATCH 6.8 127/715] wifi: iwlwifi: acpi: fix WPFC reading Date: Sun, 24 Mar 2024 18:25:06 -0400 Message-ID: <20240324223455.1342824-128-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johannes Berg [ Upstream commit 296f3e926716ded8dc29e349d2b042b362f96515 ] The code reading the WPFC table needs to take into account the domain type (first element in the package), shouldn't leak the memory if it fails, and has a bad comment. Fix all these issues. Fixes: c4c954547755 ("wifi: iwlwifi: implement WPFC ACPI table loading") Reported-by: Miri Korenblit Signed-off-by: Johannes Berg Reviewed-by: Gregory Greenman Gregory Link: https://msgid.link/20240128084842.2afeb476b62d.I200568dc42a277e21c12b= e99d5aaa39b009d45da@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/fw/acpi.c | 10 +++++----- drivers/net/wireless/intel/iwlwifi/fw/acpi.h | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/fw/acpi.c b/drivers/net/wir= eless/intel/iwlwifi/fw/acpi.c index dcc4810cb3247..f6ee5afb3320e 100644 --- a/drivers/net/wireless/intel/iwlwifi/fw/acpi.c +++ b/drivers/net/wireless/intel/iwlwifi/fw/acpi.c @@ -1296,7 +1296,6 @@ void iwl_acpi_get_phy_filters(struct iwl_fw_runtime *= fwrt, if (IS_ERR(data)) return; =20 - /* try to read wtas table revision 1 or revision 0*/ wifi_pkg =3D iwl_acpi_get_wifi_pkg(fwrt->dev, data, ACPI_WPFC_WIFI_DATA_SIZE, &tbl_rev); @@ -1306,13 +1305,14 @@ void iwl_acpi_get_phy_filters(struct iwl_fw_runtime= *fwrt, if (tbl_rev !=3D 0) goto out_free; =20 - BUILD_BUG_ON(ARRAY_SIZE(filters->filter_cfg_chains) !=3D ACPI_WPFC_WIFI_D= ATA_SIZE); + BUILD_BUG_ON(ARRAY_SIZE(filters->filter_cfg_chains) !=3D + ACPI_WPFC_WIFI_DATA_SIZE - 1); =20 for (i =3D 0; i < ARRAY_SIZE(filters->filter_cfg_chains); i++) { - if (wifi_pkg->package.elements[i].type !=3D ACPI_TYPE_INTEGER) - return; + if (wifi_pkg->package.elements[i + 1].type !=3D ACPI_TYPE_INTEGER) + goto out_free; tmp.filter_cfg_chains[i] =3D - cpu_to_le32(wifi_pkg->package.elements[i].integer.value); + cpu_to_le32(wifi_pkg->package.elements[i + 1].integer.value); } =20 IWL_DEBUG_RADIO(fwrt, "Loaded WPFC filter config from ACPI\n"); diff --git a/drivers/net/wireless/intel/iwlwifi/fw/acpi.h b/drivers/net/wir= eless/intel/iwlwifi/fw/acpi.h index e9277f6f35821..39106ccb4b9b6 100644 --- a/drivers/net/wireless/intel/iwlwifi/fw/acpi.h +++ b/drivers/net/wireless/intel/iwlwifi/fw/acpi.h @@ -56,7 +56,7 @@ #define ACPI_EWRD_WIFI_DATA_SIZE_REV2 ((ACPI_SAR_PROFILE_NUM - 1) * \ ACPI_SAR_NUM_CHAINS_REV2 * \ ACPI_SAR_NUM_SUB_BANDS_REV2 + 3) -#define ACPI_WPFC_WIFI_DATA_SIZE 4 /* 4 filter config words */ +#define ACPI_WPFC_WIFI_DATA_SIZE 5 /* domain and 4 filter config words */ =20 /* revision 0 and 1 are identical, except for the semantics in the FW */ #define ACPI_GEO_NUM_BANDS_REV0 2 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5647A136665; Sun, 24 Mar 2024 22:37:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319826; cv=none; b=GNFp7AzFHc9g8+cmChD+05fVndVHBOA0dhgTy0WzjoHQwPCsSXfzCV/FDumBMJR4bsTcyUFBcfMvGziyMuifzt4v93IJwlwgvqNTb9TeP1a+X0UDM7r4l0BschUD/4BUy8pBYrl3v5Nq01QaO7V2tRlSuGz1d09mPXYkbBxpaHw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319826; c=relaxed/simple; bh=Sq1yoVc+QhRAvCHnEwpkbv8UNUqdJphlqJF9/OpnzFY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YeufralqTNuJfiJqxytRfjNv4k6EA1RyFxPzLHELj2bP3l5sBAGqNuKHdFTlwICpRvAjMwLJQX/K79SIPE2qQ4mPUaKE4a/yW7nAHY7szvL2/13n2Wwc+9YBdp7AfZMEso6S608v1zG8I3ekQEg3b4CnJVrF5NFhP0hgD5Jns8w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mJUXivtc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mJUXivtc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 500F1C43394; Sun, 24 Mar 2024 22:37:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319825; bh=Sq1yoVc+QhRAvCHnEwpkbv8UNUqdJphlqJF9/OpnzFY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mJUXivtcn1s3EToq+Zduqj+4VHF+n7IBJtM27GXTxnGMmSjQScdbBlID72amVjYZ7 vJ+l5gpeYUZxi1caQkKcZmi5rZNKlSVbs5+NDlHwSWLQ+xTyIciZoWNpoc2ef1Tnhl lDCl/N+i9I/nPkJP4txytw2w3ZhQwd86B/mFDLTxoXtN19Ka9A3xblEPZTNZ0Fvebe 9Uqx5mD8yDXfkdJroKRIbJgYuB691s0cX8pUSGLyCI0xSOV07gWSuFXNtwnfdp+OBf 5jNldwQOaSWkxQ+LBtwAF8zWIC3x2b99+SeH4uwMez1wOdr1p539DO7MtCX3ZPfwGT jJlkGCX9NKfIQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johannes Berg , Miri Korenblit , Sasha Levin Subject: [PATCH 6.8 128/715] wifi: iwlwifi: mvm: initialize rates in FW earlier Date: Sun, 24 Mar 2024 18:25:07 -0400 Message-ID: <20240324223455.1342824-129-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johannes Berg [ Upstream commit d3b2c6c65bfd3b9616084e91bd0d402964ea7cef ] When connecting to an AP, we currently initialize the rate control only after associating. Since we now use firmware to assign rates to auth/assoc frames rather than using the data in the station and the firmware doesn't know, they're transmitted using low mandatory rates. However, if the AP advertised only higher supported rates we want to use them to be nicer (it still must receive mandatory rates though), so send the information to the firmware earlier to have it know about it and be able to use it. Fixes: 499d02790495 ("wifi: iwlwifi: Use FW rate for non-data frames") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240128084842.ed7ab1c859c2.I4b4d4fc3905c8d8470fc0= fee4648f25c950c9bb7@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/ne= t/wireless/intel/iwlwifi/mvm/mac80211.c index 53e26c3c3a9af..346512696bd1c 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c @@ -3698,6 +3698,19 @@ iwl_mvm_sta_state_notexist_to_none(struct iwl_mvm *m= vm, if (vif->type =3D=3D NL80211_IFTYPE_STATION && !sta->tdls) mvmvif->ap_sta =3D sta; =20 + /* + * Initialize the rates here already - this really tells + * the firmware only what the supported legacy rates are + * (may be) since it's initialized already from what the + * AP advertised in the beacon/probe response. This will + * allow the firmware to send auth/assoc frames with one + * of the supported rates already, rather than having to + * use a mandatory rate. + * If we're the AP, we'll just assume mandatory rates at + * this point, but we know nothing about the STA anyway. + */ + iwl_mvm_rs_rate_init_all_links(mvm, vif, sta); + return 0; } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4D32C1369B2; Sun, 24 Mar 2024 22:37:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319827; cv=none; b=hRgCMUGEFQxAeV0+Mwpo4GpoM94bn554fZXgzPqjZJOt8paFeVk09YLqSr8TGk/6qt34mvCzTzBNuOQ1h/t1mlVcZPyTVRRyRBbrmCqwxRFClhj7M+087ygnEE5pp/COhiqv1thB7goub/6THS4t97QfA+3pydWHkAMDMpZd50Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319827; c=relaxed/simple; bh=hqGZ4LC/p9yLhUx80JTHDn5iP1OAqL/6mwd8bLXnsaA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I8+/0fUW2QvXxBAg1YbUdRwRY81qJuMJXVyYDB1QUhnQgL/BZKB4LXGgS+QtH/k2jY8/XFrNZ12QzwR1zVOkE2tvGyXDg45QkD1HmA47s2fpZy85CpHjobdALhJ5CtJoHVLYw/riT1kSdxNvCyox8bbq7fuMCaQWa+9E2BGKIjI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=niYNNNtR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="niYNNNtR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35064C43390; Sun, 24 Mar 2024 22:37:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319826; bh=hqGZ4LC/p9yLhUx80JTHDn5iP1OAqL/6mwd8bLXnsaA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=niYNNNtRS2afXZrJWxOk+Mj6VD68ZiVW3dxCQJ45cVPao8bfnzOTOxEa1qqXrRNj6 7F8ogXtKUKOS4S/LdsXejb/HE8x0ywX43XG7OUbHoofYvWqHouMpmgpCiDHq+Kllhv Dcya/iwBDid/9nMMR5pKruvXttATTdv7DO29Y36CPVmV1ixUmM5dzu+WJJWNqgSsWW 3Ks3ufRoZrdGmlnHT28BFTAudXrDuxQsS3ZT64PtuIgsFTNoJyGgfCt2sKr1UuTwJL wqsSm+BOvG8mUG1QSHtc1EmQnNHEyebS16XPFKRwvEu6xpuKTlP0grUahHBJ1fxlcd rR9QKMpKVhFRg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Miri Korenblit , Gregory Greenman , Johannes Berg , Sasha Levin Subject: [PATCH 6.8 129/715] wifi: iwlwifi: fix EWRD table validity check Date: Sun, 24 Mar 2024 18:25:08 -0400 Message-ID: <20240324223455.1342824-130-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Miri Korenblit [ Upstream commit c8d8f3911135921ace8e939ea0956b55f74bf8a0 ] EWRD ACPI table contains up to 3 additional sar profiles. According to the BIOS spec, the table contains a n_profile variable indicating how many additional profiles exist in the table. Currently we check that n_profiles is not <=3D 0. But according to the BIOS spec, 0 is a valid value, and it can't be < 0 anyway because we receive that from ACPI as an unsigned integer. Fixes: 39c1a9728f93 ("iwlwifi: refactor the SAR tables from mvm to acpi") Signed-off-by: Miri Korenblit Reviewed-by: Gregory Greenman Link: https://msgid.link/20240129211905.448ea2f40814.Iffd2aadf8e8693e6cb599= bee0406a800a0c1e081@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/fw/acpi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlwifi/fw/acpi.c b/drivers/net/wir= eless/intel/iwlwifi/fw/acpi.c index f6ee5afb3320e..e161b44539069 100644 --- a/drivers/net/wireless/intel/iwlwifi/fw/acpi.c +++ b/drivers/net/wireless/intel/iwlwifi/fw/acpi.c @@ -767,7 +767,7 @@ int iwl_sar_get_ewrd_table(struct iwl_fw_runtime *fwrt) * from index 1, so the maximum value allowed here is * ACPI_SAR_PROFILES_NUM - 1. */ - if (n_profiles <=3D 0 || n_profiles >=3D ACPI_SAR_PROFILE_NUM) { + if (n_profiles >=3D ACPI_SAR_PROFILE_NUM) { ret =3D -EINVAL; goto out_free; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0F93B4DA19; Sun, 24 Mar 2024 22:37:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319828; cv=none; b=Mv9yIWagYDiqPKyAFzS77ZnnPjqUV/gN2eBZwTsF1ZSrH50ieEh4ZQ0Fck/ZZXVk6pYMk+RGpD7QcDEpM1eOj9j54LkmFIiz8gifXIoNUJQHrHwlXV1lDHMHODzqh1FNFHf4L/QnN9yBtWNYFozqZto6XmYi6MflS0UH1VYJz0M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319828; c=relaxed/simple; bh=soa6+wLeSx4p3+23fyg42wBQs0Dyods3SJnIOwXqhOU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BzIgkKcQiSkX/9QPoaJRXwo8ZGI28J61IjILdmrlZiZU/YZTUsOwlqVowd4FuzGOo69hnQelwAe/Fwxg8krNqqSOFUiUqdGktMin9EVMHVxjyFsB2qwLFJNyDccXkcnD9INo+ckiJXfUTOpBbhQSs3BPRvH9LYqhp/udJZAoQ2U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=d+kxftCP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="d+kxftCP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32325C433F1; Sun, 24 Mar 2024 22:37:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319827; bh=soa6+wLeSx4p3+23fyg42wBQs0Dyods3SJnIOwXqhOU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=d+kxftCPmHa7z4xRbwuP/kKSIuyFrilWnxuC3UnpawXp/bRGzU+QwfrUr+3dMHxg6 v3GREJlCfRt/SJ9y0Q48KLYH+2TiE3sf2AijFf5FgaFOMtATqCSPBdsdNZx7R61zO4 apA4iyNcNyVuB3jpY55YVXN1x8fr3ynXM+k4Zo7cXOvfQJgizjCo3Vn272k1HXfbJ2 jQjpD7KKI+YMzeakq8NQ5TspaihO131QcFyzz4z6IjNKfMJVV/86EX3DUktPpLSEIT uBbXnZ4m9rm4talft75NxOfYNvtqCm09NElTLP7cXr7GpfezcHDa/pXrIfSYiYjAWN CJmOxClLxtGAA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johannes Berg , Gregory Greenman , Miri Korenblit , Sasha Levin Subject: [PATCH 6.8 130/715] wifi: iwlwifi: mvm: d3: fix IPN byte order Date: Sun, 24 Mar 2024 18:25:09 -0400 Message-ID: <20240324223455.1342824-131-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johannes Berg [ Upstream commit 0c769cb6b9f364423c255f117774c9ecd5bf23ea ] The IPN is reported by the firmware in 6 bytes little endian, but mac80211 expects big endian so it can do memcmp() on it. We used to store this as a u64 which was filled in the right way, but never used. When implementing that it's used, we changed it to just be 6 bytes, but lost the conversion. Add it back. Fixes: 04f78e242fff ("wifi: iwlwifi: mvm: Add support for IGTK in D3 resume= flow") Signed-off-by: Johannes Berg Reviewed-by: Gregory Greenman Signed-off-by: Miri Korenblit Link: https://msgid.link/20240129211905.138ed8a698e3.I1b66c386e45b539269642= 4ec636474bff86fd5ef@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c b/drivers/net/wire= less/intel/iwlwifi/mvm/d3.c index 05b64176859e8..03d0c9ab73fc0 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c @@ -2200,7 +2200,10 @@ static void iwl_mvm_convert_gtk_v3(struct iwl_wowlan= _status_data *status, static void iwl_mvm_convert_igtk(struct iwl_wowlan_status_data *status, struct iwl_wowlan_igtk_status *data) { + int i; + BUILD_BUG_ON(sizeof(status->igtk.key) < sizeof(data->key)); + BUILD_BUG_ON(sizeof(status->igtk.ipn) !=3D sizeof(data->ipn)); =20 if (!data->key_len) return; @@ -2212,7 +2215,10 @@ static void iwl_mvm_convert_igtk(struct iwl_wowlan_s= tatus_data *status, + WOWLAN_IGTK_MIN_INDEX; =20 memcpy(status->igtk.key, data->key, sizeof(data->key)); - memcpy(status->igtk.ipn, data->ipn, sizeof(data->ipn)); + + /* mac80211 expects big endian for memcmp() to work, convert */ + for (i =3D 0; i < sizeof(data->ipn); i++) + status->igtk.ipn[i] =3D data->ipn[sizeof(data->ipn) - i - 1]; } =20 static void iwl_mvm_convert_bigtk(struct iwl_wowlan_status_data *status, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 68583137907; Sun, 24 Mar 2024 22:37:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319829; cv=none; b=XIcsJ3zpBmJstS1Qnh6cnG3rI3XDIhXJjfEiLiRnm3xjZkHpAdSO5gy6T2qS67DFunEK8asbh1nXVLrSC10Nn2qrxtV5IV7Dm3TfbtC/QV5lXRgJcY8rK2baBci+OwhLu5mTpndnuMhrbKGPHKHlny7YSoE1OwYVsmjHIi+tZHw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319829; c=relaxed/simple; bh=afXxZDuytKdo2b9kX8f74F3OLY83odqcQkTH0+MIdeY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lTZdnEUs9IK64Jw6UqPuBmKGZLHZjEflvKly8jQFtiHj9ProgLPJmPqvXzGQMGuTjryNfXwawgw5v0zqX0gEsAAV2fEcUMMrWXuNmrjTb8goOtTtd3PtXtmqycGgyvF4Wwm5xYRIpgpP2b80sc9AWr/DIRe9ghcdj/1JyAnf2fY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j6wvVavK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="j6wvVavK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E2C6C433C7; Sun, 24 Mar 2024 22:37:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319829; bh=afXxZDuytKdo2b9kX8f74F3OLY83odqcQkTH0+MIdeY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=j6wvVavK2NqTDt/omJukgnuy4LwgYAxxLFj+D6QvlZGOKjETJkjEQX22UY6WyMVhR fah7WHP8m0lwztq4glgw9zcxTL5A6mbdzYmoMp1SvSAbFpiRtn1Ljg/WGoAwWWePCw fJASypTfTKryt1HPdEAIDyPcmk1pLFXqijIo+Fq0BBxAm3GzWywhQ0aekSmUmGBGWQ 9ZfuwYEV0hAf+tHM8w2HDTzWz6LkvTCD0O7I6CIPAmGEUodvn0PCBXehov8oVHvz8q LYcFl6VNp3wZSjkHC2jC/CXOR1SYYTnXLQCgyVDpK7KJBBTTPGCUWvihPeyKOwKD8d L9n/ZtAG2hAyQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johannes Berg , Mukesh Sisodiya , Gregory Greenman , Miri Korenblit , Sasha Levin Subject: [PATCH 6.8 131/715] wifi: iwlwifi: always have 'uats_enabled' Date: Sun, 24 Mar 2024 18:25:10 -0400 Message-ID: <20240324223455.1342824-132-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johannes Berg [ Upstream commit f639602a58e7564dd091c7c0793f61042bad9bb6 ] We check this in code that'd be complicated to put under ifdef (CONFIG_ACPI), so just always have 'uats_enabled'. Fixes: 4a9bb5b4d949 ("wifi: iwlwifi: fw: Add support for UATS table in UHB") Signed-off-by: Johannes Berg Reviewed-by: Mukesh Sisodiya Reviewed-by: Gregory Greenman Signed-off-by: Miri Korenblit Link: https://msgid.link/20240129211905.bdc5fb20f00a.I902d801d79873c5c9cd51= cef8e8226e2acefe88d@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/fw/runtime.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlwifi/fw/runtime.h b/drivers/net/= wireless/intel/iwlwifi/fw/runtime.h index 357727774db90..baabb8e321f8d 100644 --- a/drivers/net/wireless/intel/iwlwifi/fw/runtime.h +++ b/drivers/net/wireless/intel/iwlwifi/fw/runtime.h @@ -173,9 +173,9 @@ struct iwl_fw_runtime { struct iwl_sar_offset_mapping_cmd sgom_table; bool sgom_enabled; u8 reduced_power_flags; - bool uats_enabled; struct iwl_uats_table_cmd uats_table; #endif + bool uats_enabled; }; =20 void iwl_fw_runtime_init(struct iwl_fw_runtime *fwrt, struct iwl_trans *tr= ans, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E10D13791C; Sun, 24 Mar 2024 22:37:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319830; cv=none; b=Pcd+Su1EyiY9b2HGldY7lPwZgLychPTf+n+gSen8vn8SrxqeHKLnAO/puAHzzPEGn3LIMi9bme7FSKq3MA/HYa/Clis4LRy92clVTsjJ7dmnvn9p+VtBILVfOnlZ2vDSI9IbrbW8PDXSM3F58kOn5dLVlxC9zO0LIZiAJSO4g40= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319830; c=relaxed/simple; bh=/DKVbN6tduAwbcxg3CQbSjcbip6MeRF1LCLPOK6gFqw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mMK+k0V7FaItgPeRyubfGHIP9pEDF5GPKO0yELDT3dCIEBU+x/RauD+25/Jacmgeks5ejDuniqHiU8lmIF8uxgApOMA32/rS7R6dr4ArwU8hoXb53iWiG8clne422qa3L9+u2vxINLlNSFblvf10OKvhbhQiiklvitlsk7S2RQE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PES7IwWn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PES7IwWn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 407D2C433A6; Sun, 24 Mar 2024 22:37:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319830; bh=/DKVbN6tduAwbcxg3CQbSjcbip6MeRF1LCLPOK6gFqw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PES7IwWns0Pmim+PGGBhL3OD5iV1/qT7S8qetMYnhfJohWGscrTrqIOi3gpPZkREj d5MV9p0JEtbObBdBlaHBe0I6dtFQsFQ+cdfRKa2lKGXnZ5IkuMsbG2fCabf3R6yWkh yef7cWGIyEaS9Rp6iG0Sn4qblvvWDLDjR7QfQjQyWQeA5CfT1ThBRJJSDEetqjnpqC 3ltt5uses5091ltZEA3enNF8Q4oA+7Y71v/fWGoi22o8UzGe0j4OenySf/SM6HIS93 N4xMJvS0DPZm+QjVaO6D1Er/uuc+V9DA81BhJzc3atNLdZCL4ddKx+Z/p9PB/8a85d 1866ZdKOxTVOQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Emmanuel Grumbach , Johannes Berg , Miri Korenblit , Sasha Levin Subject: [PATCH 6.8 132/715] wifi: iwlwifi: mvm: fix the TLC command after ADD_STA Date: Sun, 24 Mar 2024 18:25:11 -0400 Message-ID: <20240324223455.1342824-133-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Emmanuel Grumbach [ Upstream commit 0fcdf55fced7121c43fa576433986f1c04115b73 ] ADD_STA resets the link quality data inside the firmware. This is not supposed to happen and has been fixed for newer devices. For older devices (AX201 and down), this makes us send frames with rates that are not in the TLC table. Fixes: 5a86dcb4a908 ("wifi: iwlwifi: mvm: update station's MFP flag after a= ssociation") Signed-off-by: Emmanuel Grumbach Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240129211905.1deca7eaff14.I597abd7aab36fdab4aa83= 11a48c98a3d5bd433ba@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c b/drivers/ne= t/wireless/intel/iwlwifi/mvm/mac80211.c index 346512696bd1c..f60d4258e1b95 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c @@ -3809,13 +3809,17 @@ iwl_mvm_sta_state_assoc_to_authorized(struct iwl_mv= m *mvm, =20 mvm_sta->authorized =3D true; =20 - iwl_mvm_rs_rate_init_all_links(mvm, vif, sta); - /* MFP is set by default before the station is authorized. * Clear it here in case it's not used. */ - if (!sta->mfp) - return callbacks->update_sta(mvm, vif, sta); + if (!sta->mfp) { + int ret =3D callbacks->update_sta(mvm, vif, sta); + + if (ret) + return ret; + } + + iwl_mvm_rs_rate_init_all_links(mvm, vif, sta); =20 return 0; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0FDE113793D; Sun, 24 Mar 2024 22:37:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319831; cv=none; b=Tbm40qHgc8LMFLscDgFFCbvvKRsB3td+Xln8lsuzM6QvHCLNvGtOtFOMQvDoUxeIiRr3jNbPhobb4ti71Rt+RBMrlKco4SnZjjFu2K0Jbt3afdYa5B7jSPWDzvy7l94InaPqq0h/iQwSv29v2soAcU6Ln/060Bh4tCiCPNbhlg0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319831; c=relaxed/simple; bh=R5MgffQAqsovV9p+t6iCvXpyZJGJXls0j6QgS0aphW8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IydbbqI4A1ABKm3ZeXtovjvKnDfKL5cipIaVvjYbL1jjivBS680JryV4sqwuSMZgvEYhoqEn6qcNycX7jKrUN/mt8o4t71qUg7fiITUi+6K/7g+rnIVfEZsMHBu7UTbDqwh6g77eBPXyVUpuj+BQtPBtBblueY4s/z6pwlLiHm4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Fjed9SvL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Fjed9SvL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38A39C433B2; Sun, 24 Mar 2024 22:37:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319830; bh=R5MgffQAqsovV9p+t6iCvXpyZJGJXls0j6QgS0aphW8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Fjed9SvLHpCit5qCPkiJ7G32p7ypxB+7OdjpchehUAKOjUufS5FchDh9ig0CyAkj+ o6dNNBw53ZquHre/dexowUqJTAvQoIY9GknjtN4o054BokXkZJ21qTjorZdWHH8EJY v+AKX04pnH04MtesUqxy46QZjRRvZur2iXCFU1pFd0FpK+EmpAQbCsrfGz6W6+TpqN n62wFzjJnQOJ71ouV0YcD+eX7YchvAZ/Y1DJUjz99cPKLEf0fggObEz9lRjG4psMp6 AaSTlkaNQFjpYCux+mIFYjOsNb6YajZR8H4N2t12i4ly00QUl0MG/YzmHe2BXxqrPf S4DN4QNOdDoSA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Miri Korenblit , Gregory Greenman , Johannes Berg , Sasha Levin Subject: [PATCH 6.8 133/715] wifi: iwlwifi: read BIOS PNVM only for non-Intel SKU Date: Sun, 24 Mar 2024 18:25:12 -0400 Message-ID: <20240324223455.1342824-134-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Miri Korenblit [ Upstream commit c868a189ecfe8cc0b3173c2eaa7f0b659326c151 ] The driver is supposed to read the PNVM from BIOS only for non-Intel SKUs. For Intel SKUs the OEM ID will be 0. Read BIOS PNVM only when a non-Intel SKU is indicated. Fixes: b99e32cbfdf6 ("wifi: iwlwifi: Take loading and setting of pnvm image= out of parsing part") Signed-off-by: Miri Korenblit Reviewed-by: Gregory Greenman Link: https://msgid.link/20240131091413.3625cf1223d3.Ieffda5f506713b1c97938= 8dd7a0e1c1a0145cfca@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/fw/pnvm.c | 30 ++++++++++++-------- 1 file changed, 18 insertions(+), 12 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/fw/pnvm.c b/drivers/net/wir= eless/intel/iwlwifi/fw/pnvm.c index 650e4bde9c17b..56ee0ceed78ab 100644 --- a/drivers/net/wireless/intel/iwlwifi/fw/pnvm.c +++ b/drivers/net/wireless/intel/iwlwifi/fw/pnvm.c @@ -255,21 +255,27 @@ static u8 *iwl_get_pnvm_image(struct iwl_trans *trans= _p, size_t *len) struct pnvm_sku_package *package; u8 *image =3D NULL; =20 - /* First attempt to get the PNVM from BIOS */ - package =3D iwl_uefi_get_pnvm(trans_p, len); - if (!IS_ERR_OR_NULL(package)) { - if (*len >=3D sizeof(*package)) { - /* we need only the data */ - *len -=3D sizeof(*package); - image =3D kmemdup(package->data, *len, GFP_KERNEL); + /* Get PNVM from BIOS for non-Intel SKU */ + if (trans_p->sku_id[2]) { + package =3D iwl_uefi_get_pnvm(trans_p, len); + if (!IS_ERR_OR_NULL(package)) { + if (*len >=3D sizeof(*package)) { + /* we need only the data */ + *len -=3D sizeof(*package); + image =3D kmemdup(package->data, + *len, GFP_KERNEL); + } + /* + * free package regardless of whether kmemdup + * succeeded + */ + kfree(package); + if (image) + return image; } - /* free package regardless of whether kmemdup succeeded */ - kfree(package); - if (image) - return image; } =20 - /* If it's not available, try from the filesystem */ + /* If it's not available, or for Intel SKU, try from the filesystem */ if (iwl_pnvm_get_from_fs(trans_p, &image, len)) return NULL; return image; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3DC5B137C44; Sun, 24 Mar 2024 22:37:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319832; cv=none; b=bKsacYD05vZcTFmd5M0i2z+eCj3ob/ioqTZl/7v0apaboRUhZVL76RJaxnoe4EeqCW/YENMMUGzHa5tTr/iBOcqGrHxYB8da79Nc6JnrAIfVoXQKHEpDamdzaSliKvPy8jEcFaN/Fol32fEsBFZZxrSY0VNggd41dBnQ+CEwCOo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319832; c=relaxed/simple; bh=UU3RW3VG76C1ppMjisYC2nlueT7fVuWvWnBOyvqAUqs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hvvP4QxXorLSQ+wy7F9F1a5gwSTauDc13ySVYpkABiI5QogLC9ISYVxwwi9fmMNYvlCeifHZN7MMm5UC157QdvOauOJgPB3WcMfUqej9K+v5Nn1gkV69isx/qXSZnp9Dgy3h0vHTLcn22YtdQYYUCgssuqizcmcQHn4PpAyil6E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AxxEU3J9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AxxEU3J9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34F89C433F1; Sun, 24 Mar 2024 22:37:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319831; bh=UU3RW3VG76C1ppMjisYC2nlueT7fVuWvWnBOyvqAUqs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AxxEU3J9gBAmd6C75zq/WrVU/1ghR+LX/64A1rPcgNiAYI9xHIflarm7QW5K1EyoP 8oNzSX0N86+g791JS0xdAL4ca1eqslu4CbsQ4a1glUP2BuGQvOVDH5egg9cWfcnkV8 hMWzWcH/KSY818d5RA4Q1/L5R/I1a5/sdxsCnrlYl4Z+AJMUxZc7kd3THjz05Zvc0s EYQLpWOSYx2e9INwt/ty31mnZlyrTYIAhMXhypryWoPk+YxoAKqmyiG8s4P10KfKAN iAVn85nZamEgBgN+Skqu8nTD0YfbK4IgkbdUD9NaMmkNScQB8frd3OzCrW86MMbqHz NRb4yMWHTDYHg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Martin Kaiser , Bartosz Golaszewski , Sasha Levin Subject: [PATCH 6.8 134/715] gpio: vf610: allow disabling the vf610 driver Date: Sun, 24 Mar 2024 18:25:13 -0400 Message-ID: <20240324223455.1342824-135-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Martin Kaiser [ Upstream commit f57595788244a838deec2d3be375291327cbc035 ] The vf610 gpio driver is enabled by default for all i.MX machines, without any option to disable it in a board-specific config file. Most i.MX chipsets have no hardware for this driver. Change the default to enable GPIO_VF610 for SOC_VF610 and disable it otherwise. Add a text description after the bool type, this makes the driver selectable by make config etc. Fixes: 30a35c07d9e9 ("gpio: vf610: drop the SOC_VF610 dependency for GPIO_V= F610") Signed-off-by: Martin Kaiser Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpio/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 1301cec94f128..353af1a4d0ace 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -711,7 +711,8 @@ config GPIO_UNIPHIER Say yes here to support UniPhier GPIOs. =20 config GPIO_VF610 - def_bool y + bool "VF610 GPIO support" + default y if SOC_VF610 depends on ARCH_MXC select GPIOLIB_IRQCHIP help --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 03481138482; Sun, 24 Mar 2024 22:37:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319833; cv=none; b=VkZS6SlIot79yaYoQoz30UORg4+aDMYMugq3bMgxXBn7BsregqXAeg/QwQ5NQKpWwiLayOqT8XKaQ5S+nSnzPNI+OwQbz1m3bG66AagO7FpN1ZvBIDCS6QS0IuH9+hgct/4wwXZOaaK+rw3VEs+EglpoKSzfPA9ZcW/pc7YTRnw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319833; c=relaxed/simple; bh=Rk1Q+Aok+VkjPFU/uEYsGNr2WdeCIZyK5WHjnMJWslQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=m//lNk8upquAZgu4y4k1/sbUdd+bW+xejNS7c4V48j/t1GegBIOnLrbBToglwfGDfPgX6XEY7LPQGSPhaH/oOBWXUcE0FKM5cxId0syPMP4BoLblwiS3Hcbm5fTA1EoY6yJFQJ/xpwI8c7R/2uMPHFpNSyhVuh1kfg2XrKDTh0c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pPWYT/T5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pPWYT/T5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1A344C433C7; Sun, 24 Mar 2024 22:37:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319832; bh=Rk1Q+Aok+VkjPFU/uEYsGNr2WdeCIZyK5WHjnMJWslQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pPWYT/T5zZv3eD6ar8Hho2C8lAglnvT6MH0l046bwFTwmG2ik5WMt7EGfBbQlIR21 Goas7mRVUPtCHXDJ3hrYRisUL3bipYLUJpvO/GCc+Mt4+PfX0XNfF52+lSechhGr1p hvIscDhJ35pYAUSFU3AF/FK4IfNnfIGhyHE+6A3pD5L8XDjjX73FMMd5H2ik0KIR1+ rDdSGDNLl8uBNf9E1sbm9Pi7apvIv7TUsroimFks+C951U5RR69xWc/8KU8hAFMnFh z7sXG5EpAVobvUl/FAH8ZalBAnFUW3E5pvEcn7YnVeugwGVTluDaUBfHSGaue2iKD7 CIuvQd8OBb7Nw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shung-Hsi Yu , Jiri Olsa , Martin KaFai Lau , Sasha Levin Subject: [PATCH 6.8 135/715] selftests/bpf: trace_helpers.c: do not use poisoned type Date: Sun, 24 Mar 2024 18:25:14 -0400 Message-ID: <20240324223455.1342824-136-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shung-Hsi Yu [ Upstream commit a68b50f47bec8bd6a33b07b7e1562db2553981a7 ] After commit c698eaebdf47 ("selftests/bpf: trace_helpers.c: Optimize kallsyms cache") trace_helpers.c now includes libbpf_internal.h, and thus can no longer use the u32 type (among others) since they are poison in libbpf_internal.h. Replace u32 with __u32 to fix the following error when building trace_helpers.c on powerpc: error: attempt to use poisoned "u32" Fixes: c698eaebdf47 ("selftests/bpf: trace_helpers.c: Optimize kallsyms cac= he") Signed-off-by: Shung-Hsi Yu Acked-by: Jiri Olsa Link: https://lore.kernel.org/r/20240202095559.12900-1-shung-hsi.yu@suse.com Signed-off-by: Martin KaFai Lau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/testing/selftests/bpf/trace_helpers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/trace_helpers.c b/tools/testing/se= lftests/bpf/trace_helpers.c index 4faa898ff7fc4..27fd7ed3e4b0c 100644 --- a/tools/testing/selftests/bpf/trace_helpers.c +++ b/tools/testing/selftests/bpf/trace_helpers.c @@ -271,7 +271,7 @@ ssize_t get_uprobe_offset(const void *addr) * addi r2,r2,XXXX */ { - const u32 *insn =3D (const u32 *)(uintptr_t)addr; + const __u32 *insn =3D (const __u32 *)(uintptr_t)addr; =20 if ((((*insn & OP_RT_RA_MASK) =3D=3D ADDIS_R2_R12) || ((*insn & OP_RT_RA_MASK) =3D=3D LIS_R2)) && --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFE6D1384AB; Sun, 24 Mar 2024 22:37:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319834; cv=none; b=OszU8U5myae8IcmvaB+f8OTDnLtSM8q9cjp2XCRADr74y8lMngu+H5+EwGLChVxGsM8kMRvThXqrLPMNMUqIRgTa/AVPvKteOVwre12HkH13TWsUhs8K2Y4WRFchecU6PFX96cuNrtVM9qDi/aQO1n6kahNr9tElXcNQC427SfM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319834; c=relaxed/simple; bh=suxZku+fuSyERt5pEGR0WhhSb5rTWiSWM7+czOYqsSI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WRqzSyNnCk7Y+jjlUp1mllx4bGE6XMTuyXliwlU2PK+Euxdruthy1/LUQsJ3GTtVpofeRQOWQjE1fWaiRxK5osPudAJ8vbNja/2ydt33vRoD4bXvAXKRrJ8EozqOLZeQBpiGmdohUxSr7rGwtieJcEj7UbO47KfBcYUhpA17Xlo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qLtzu5Y4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qLtzu5Y4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 16541C433A6; Sun, 24 Mar 2024 22:37:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319833; bh=suxZku+fuSyERt5pEGR0WhhSb5rTWiSWM7+czOYqsSI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qLtzu5Y4qhA97ExDx+hkGQWitIHvExMBwl6leRxRqSpaaPROM3SwGYtjcqSvoU0H1 ZVUZpmQ42BUTHwY5KXg8Kdslrhb6Zfc4/YM7QrC8GVmNYJGZyKlQpXgzGmSgWcTAap GpphYLzLSY8cJ7bzuqCi9j6Mb7kQttVRj19579BY3i+4l9Vck5xzHlS02gSGjCHzAD Sdkn0s8PRYaTNmmte3ks+O5/Dvujj9hwgT2mWIDXzJAsm9BNHvnEXpWWgRFhr5mowC 62zIg7KJ46/P3Vz9VYIBPn9NDMbO5JYl5RX2c77FdE2k+N+p/0bGNof0LwNcpbVVX5 wRu7Dr73T2TcA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrii Nakryiko , Eduard Zingerman , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 136/715] bpf: make sure scalar args don't accept __arg_nonnull tag Date: Sun, 24 Mar 2024 18:25:15 -0400 Message-ID: <20240324223455.1342824-137-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrii Nakryiko [ Upstream commit 18810ad3929ff6b5d8e67e3adc40d690bd780fd6 ] Move scalar arg processing in btf_prepare_func_args() after all pointer arg processing is done. This makes it easier to do validation. One example of unintended behavior right now is ability to specify __arg_nonnull for integer/enum arguments. This patch fixes this. Signed-off-by: Andrii Nakryiko Acked-by: Eduard Zingerman Link: https://lore.kernel.org/r/20240105000909.2818934-3-andrii@kernel.org Signed-off-by: Alexei Starovoitov Stable-dep-of: 1eb986746a67 ("bpf: don't emit warnings intended for global = subprogs for static subprogs") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/bpf/btf.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c index 5964711891767..dbe7a590f565a 100644 --- a/kernel/bpf/btf.c +++ b/kernel/bpf/btf.c @@ -7058,10 +7058,6 @@ int btf_prepare_func_args(struct bpf_verifier_env *e= nv, int subprog) =20 while (btf_type_is_modifier(t)) t =3D btf_type_by_id(btf, t->type); - if (btf_type_is_int(t) || btf_is_any_enum(t)) { - sub->args[i].arg_type =3D ARG_ANYTHING; - continue; - } if (btf_type_is_ptr(t) && btf_get_prog_ctx_type(log, btf, t, prog_type, = i)) { sub->args[i].arg_type =3D ARG_PTR_TO_CTX; continue; @@ -7091,6 +7087,10 @@ int btf_prepare_func_args(struct bpf_verifier_env *e= nv, int subprog) bpf_log(log, "arg#%d marked as non-null, but is not a pointer type\n", = i); return -EINVAL; } + if (btf_type_is_int(t) || btf_is_any_enum(t)) { + sub->args[i].arg_type =3D ARG_ANYTHING; + continue; + } bpf_log(log, "Arg#%d type %s in %s() is not supported yet.\n", i, btf_type_str(t), tname); return -EINVAL; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 31CD21386B9; Sun, 24 Mar 2024 22:37:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319835; cv=none; b=U7aiK2DiipgWxWwrss6WtnUttVdhhiDfo7zHlwXlD5yhe7nRaAqSswYI0AbZ/wZFcVqP1Bd18+7PqclKSoUSv5m2G3k/jFEthcVZ4Zcb8MZ+kTqakgp4Fu5U0s5zUkh9ymxTr+5B1tVsGrpUs0mce0QBMV9M/GT3dI6Q94XPC7U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319835; c=relaxed/simple; bh=gZBhs5OFS0aSII4De22PvYT5QM8kh5F/h4/+8pOfbgY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SLQ8FXbwXhFwZZN70OPhYbAZd9h13IQOx6t9iRGxXUgCN1D/+JqZbM6dUyF2Bx2xgT23eiQEaBb5NWgJ+E5KWjFcnR7TkT1UrD+LExmfrNvhsLm8abwo/VIKkEvEZufme933WTkBJaQPM/bikkhX21BL1zvRAoUAssJ/h5kC28s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=j3gQNCL6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="j3gQNCL6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 110B0C43399; Sun, 24 Mar 2024 22:37:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319834; bh=gZBhs5OFS0aSII4De22PvYT5QM8kh5F/h4/+8pOfbgY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=j3gQNCL6xcTXtpByWjaqIvxd3KNlwUvMkpn5aEx99rLL1QA5kDB54Tm8UjT32KTMI hVjwvbQRpFlrxcTGsimT5zr5fxYJi9Qt9fm7nAf3GfK4sFBA4yfYEyOeuW41jfVSq3 bTGdqGNxcYquyBELgjq4n/Zq+p+BRt4qRZsgmf6BzJutLOLHmeuQQ+CFZWvuIjFael lUj1hgRZQYR45Gvi1zQPqjSDY8UB4qRmftI0UXQ0jQ4r0m0jKsyUDLxKLxgVuVWHn6 0sj7siUlXXYgRqIRpGPNdOpb01QpfhEGWatB00/KmeotuywbU0Za46QeoEZbux6m2J PhJjirEp+0IYw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrii Nakryiko , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 137/715] bpf: don't emit warnings intended for global subprogs for static subprogs Date: Sun, 24 Mar 2024 18:25:16 -0400 Message-ID: <20240324223455.1342824-138-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrii Nakryiko [ Upstream commit 1eb986746a67952df86eb2c50a36450ef103d01b ] When btf_prepare_func_args() was generalized to handle both static and global subprogs, a few warnings/errors that are meant only for global subprog cases started to be emitted for static subprogs, where they are sort of expected and irrelavant. Stop polutting verifier logs with irrelevant scary-looking messages. Fixes: e26080d0da87 ("bpf: prepare btf_prepare_func_args() for handling sta= tic subprogs") Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20240202190529.2374377-4-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/bpf/btf.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c index dbe7a590f565a..92aa3cf0396b8 100644 --- a/kernel/bpf/btf.c +++ b/kernel/bpf/btf.c @@ -7009,6 +7009,8 @@ int btf_prepare_func_args(struct bpf_verifier_env *en= v, int subprog) args =3D (const struct btf_param *)(t + 1); nargs =3D btf_type_vlen(t); if (nargs > MAX_BPF_FUNC_REG_ARGS) { + if (!is_global) + return -EINVAL; bpf_log(log, "Global function %s() with %d > %d args. Buggy compiler.\n", tname, nargs, MAX_BPF_FUNC_REG_ARGS); return -EINVAL; @@ -7018,6 +7020,8 @@ int btf_prepare_func_args(struct bpf_verifier_env *en= v, int subprog) while (btf_type_is_modifier(t)) t =3D btf_type_by_id(btf, t->type); if (!btf_type_is_int(t) && !btf_is_any_enum(t)) { + if (!is_global) + return -EINVAL; bpf_log(log, "Global function %s() doesn't return scalar. Only those are supported.\= n", tname); @@ -7091,6 +7095,8 @@ int btf_prepare_func_args(struct bpf_verifier_env *en= v, int subprog) sub->args[i].arg_type =3D ARG_ANYTHING; continue; } + if (!is_global) + return -EINVAL; bpf_log(log, "Arg#%d type %s in %s() is not supported yet.\n", i, btf_type_str(t), tname); return -EINVAL; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA9C51386D5; Sun, 24 Mar 2024 22:37:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319835; cv=none; b=M3DKeQaFmZmWPqwNOVDhx7zEl6tijatowGv247NDGM0/XUa6kSZliWpizVwHR+4P/ih4odpSa0npGH+N9Gw3sGJXyTwxYTXHlu1CMv5XfDBuBDR6qmCsVf/NGqMUqW3RT15hTSnOxM5kfgLdJkawMKezrLIAFf94woSP7bfbW4U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319835; c=relaxed/simple; bh=49DnlI4xLg7fy52362vWUJfff/Ui3fQ8OkDoSAzHm0A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cayqfoaV5mJJktB6WAJgLCcmsoPreVe0P9mRd+bxVouQQ2dGx/5Y//PDCnfcFFv32a00AHbxFEurC4JLT4057uCX5v3tixGVLlzmyxAVrUolhYpDFSXwWx++dg7ATHwzU8apzLgPaQuZUhZ8G/6E4wzOa3wPuLAaDH+oYpUCyJk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CWus3nS9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CWus3nS9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC448C433F1; Sun, 24 Mar 2024 22:37:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319835; bh=49DnlI4xLg7fy52362vWUJfff/Ui3fQ8OkDoSAzHm0A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CWus3nS9BKw7fxkguM1u8m3ZoOBox672PXzYRjq+dnAQsYbzCbfOOUqOvI+pWFXBg ZSTAnZ+3h9WTpdTEww1pZpcdR1gScdBXwYYzo1VBGQ/vBYlqKor/Fp9hCtqKBi1FMX HRgHTGaMU4mqdRdyL+v7HAcFo/ZFZW1SZdRJF63QM4y5bTDp03Zg7fDzJzKU7cF5Az FSdvz0id6udtMsrmdEqnK3enhztKWfTI13QQVaT2APbvfRHbxGSdd5Wchkq4WoN+lv aXOZFzK9IScCAswaxjcakYtb8XVE3spj459xaRIixcgf3cV1i6OVx8/pD1lS+SYqO7 PenAOpKLUBwxg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tim Harvey , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 138/715] arm64: dts: imx8mm-venice-gw71xx: fix USB OTG VBUS Date: Sun, 24 Mar 2024 18:25:17 -0400 Message-ID: <20240324223455.1342824-139-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tim Harvey [ Upstream commit ec2cb52fcfef5d58574f2cfbc9a99ffc20ae5a9d ] The GW71xx does not have a gpio controlled vbus regulator but it does require some pinctrl. Remove the regulator and move the valid pinctrl into the usbotg1 node. Fixes: bd306fdb4e60 ("arm64: dts: imx8mm-venice-gw71xx: fix USB OTG VBUS") Signed-off-by: Tim Harvey Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../dts/freescale/imx8mm-venice-gw71xx.dtsi | 29 ++++++------------- 1 file changed, 9 insertions(+), 20 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi b/arch= /arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi index 6425773f68e0a..bbbaf2165ea28 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-venice-gw71xx.dtsi @@ -47,17 +47,6 @@ pps { gpios =3D <&gpio1 15 GPIO_ACTIVE_HIGH>; status =3D "okay"; }; - - reg_usb_otg1_vbus: regulator-usb-otg1 { - pinctrl-names =3D "default"; - pinctrl-0 =3D <&pinctrl_reg_usb1_en>; - compatible =3D "regulator-fixed"; - regulator-name =3D "usb_otg1_vbus"; - gpio =3D <&gpio1 10 GPIO_ACTIVE_HIGH>; - enable-active-high; - regulator-min-microvolt =3D <5000000>; - regulator-max-microvolt =3D <5000000>; - }; }; =20 /* off-board header */ @@ -144,9 +133,10 @@ &uart3 { }; =20 &usbotg1 { + pinctrl-names =3D "default"; + pinctrl-0 =3D <&pinctrl_usbotg1>; dr_mode =3D "otg"; over-current-active-low; - vbus-supply =3D <®_usb_otg1_vbus>; status =3D "okay"; }; =20 @@ -204,14 +194,6 @@ MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x41 >; }; =20 - pinctrl_reg_usb1_en: regusb1grp { - fsl,pins =3D < - MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10 0x41 - MX8MM_IOMUXC_GPIO1_IO12_GPIO1_IO12 0x141 - MX8MM_IOMUXC_GPIO1_IO13_USB1_OTG_OC 0x41 - >; - }; - pinctrl_spi2: spi2grp { fsl,pins =3D < MX8MM_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK 0xd6 @@ -234,4 +216,11 @@ MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX 0x140 MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX 0x140 >; }; + + pinctrl_usbotg1: usbotg1grp { + fsl,pins =3D < + MX8MM_IOMUXC_GPIO1_IO12_GPIO1_IO12 0x141 + MX8MM_IOMUXC_GPIO1_IO13_USB1_OTG_OC 0x41 + >; + }; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DB2C413957F; Sun, 24 Mar 2024 22:37:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319837; cv=none; b=P6cxjsWX1ich3w7+79KSSpB/DHVtWW7/NrxWgtdaZ/Xqd9wBu1aEp2qpsDzknt3paUjko/z1GisVy3hbvbxIXRPxp0kOiwtGqB6H2My9ASiQBTqweeaiRJtZGn/4Atz1S29Nj1RWajpHHu2veLwEx4KCD+szbggpDGOHO79MhhY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319837; c=relaxed/simple; bh=BlrEduLhK8IxCF6Js5m5Yhu9/N1eH5XB7begusWkerc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=cVYst828vWVzSCSol9xKNGpraYmQUpZukBwtXDXiDIqSXENE64df+SvfAlsYudxf3taPszwir2hnSHzZmRqxJ99HnqL9IMJcqvQL7Sp1oP5tfEfgWzEzRvte4pau53ltljj28AOQ0vYXileag0rkmXG7FhNkPmyse6M1NNH53Og= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JkRT/sJh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JkRT/sJh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CEBE6C43330; Sun, 24 Mar 2024 22:37:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319836; bh=BlrEduLhK8IxCF6Js5m5Yhu9/N1eH5XB7begusWkerc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JkRT/sJhkbfnPTT7h+DA5Va7EQ+YlEEMqkGcZlpe6WIQ+eRbikfTrqmfmLjgPckwd 0FT+X6CTxHY7casZeyfgelUyNyIAUmXjv4TSMFye2KCUnE1W/zPYODGSw2OSip5U1o onDecMXyuNVTzNpl5i0t2DgmQ2d3UpfK7cOgTSwLLVLbAWbEfde28R6fLfk/QT8Muj zMatPHyCst+Mrqe9jMb0RcKjFdb8iwqTM3NZzyKZH/El1g7EFq7RdfSy5fuwwwk1Sr 96qp6lRORPy4cslMvOmAS+q6YtzFGgOTXoSaiz18aRIZ/MYPOT66Df7e9NLC9vO/e/ CqgbVuaEUVU9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= , Claudiu Beznea , Sasha Levin Subject: [PATCH 6.8 139/715] pwm: atmel-hlcdc: Fix clock imbalance related to suspend support Date: Sun, 24 Mar 2024 18:25:18 -0400 Message-ID: <20240324223455.1342824-140-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Uwe Kleine-K=C3=B6nig [ Upstream commit e25ac87d3f831fed002c34aadddaf4ebb4ea45ec ] The suspend callback disables the periph clock when the PWM is enabled and resume reenables this clock if the PWM was disabled before. Judging from the code comment it's suspend that is wrong here. Fix accordingly. Fixes: f9bb9da7c09d ("pwm: atmel-hlcdc: Implement the suspend/resume hooks") Reviewed-by: Claudiu Beznea Link: https://lore.kernel.org/r/b51ea92b0a45eff3dc83b08adefd43d930df996c.17= 06269232.git.u.kleine-koenig@pengutronix.de Signed-off-by: Uwe Kleine-K=C3=B6nig Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/pwm/pwm-atmel-hlcdc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c index 3f2c5031a3ba8..1f6fc9a9fcf3e 100644 --- a/drivers/pwm/pwm-atmel-hlcdc.c +++ b/drivers/pwm/pwm-atmel-hlcdc.c @@ -185,7 +185,7 @@ static int atmel_hlcdc_pwm_suspend(struct device *dev) struct atmel_hlcdc_pwm *atmel =3D dev_get_drvdata(dev); =20 /* Keep the periph clock enabled if the PWM is still running. */ - if (pwm_is_enabled(&atmel->chip.pwms[0])) + if (!pwm_is_enabled(&atmel->chip.pwms[0])) clk_disable_unprepare(atmel->hlcdc->periph_clk); =20 return 0; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 845B9139598; Sun, 24 Mar 2024 22:37:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319837; cv=none; b=YJgY30Y7zfHWqfbOSAOsMNJEMuQw5wtZxVrBsgkjqnDrAtP23kmBzvgjwBA7kzRW4d84pXr/UmBiiFIP1fh4N7UvINEhnpbp+/MR/UfpwUxgNQtXcvN2L1x4hYJX4hKB1mpDeVTPKCI2CXTPrlgcAN3Qx/QAU8Q/xTZJrbL0BVc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319837; c=relaxed/simple; bh=LvtZg5e0VQtOBT+DmVlIpjevxUc7VebV46SOEb3fPHw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fvCqL+XsYQbWLR1yyAr7lBuiyKLQfnMqt20sDVOCO/wZ29ch5uJ1rwzgR50lhIUNl2qePuRg1EIoohiezFizgS0+rsw3PrPc7fw3FNRv0Ahx6FG8yiphBYQn+B8eLIHTEZGZcxhDksaCwq/YiKPHb3tM1HQiDBk8yzSHKgV+VP8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VNe2Mdz1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VNe2Mdz1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B22C7C43399; Sun, 24 Mar 2024 22:37:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319837; bh=LvtZg5e0VQtOBT+DmVlIpjevxUc7VebV46SOEb3fPHw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VNe2Mdz1jvhZOmL7v1IPHuiyWCxz63U/aYYx5JF6xWunGCVq1rvvs7u5mZt7+LuKI BItTsXj0C4k0l5tukM8NohfMu7080GmIE2ZrvWKr4EVk7QWSmFt7i4V/svrd99gRxs PEEpZROTzHKFm5D3SASvhiarC9ZPQnrWbi0FS5e3vJf6XdHHqRpg+CyTNaIkE28YRs C0u2KZ51pf6x18K2X+EApNineXoN98P1Od4PlsETxe6/biYzTbTi4Wtgiz/q2F8GX2 vMpSKYOQf/MsL90OYd6HqS1dc4yf5JsLA2AzM6Epalxdg0Sm4bk4YLdsaeRxsm6eLD Pcerybp3Dfbsw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Breno Leitao , Jiri Pirko , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 140/715] net: blackhole_dev: fix build warning for ethh set but not used Date: Sun, 24 Mar 2024 18:25:19 -0400 Message-ID: <20240324223455.1342824-141-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Breno Leitao [ Upstream commit 843a8851e89e2e85db04caaf88d8554818319047 ] lib/test_blackhole_dev.c sets a variable that is never read, causing this following building warning: lib/test_blackhole_dev.c:32:17: warning: variable 'ethh' set but not used = [-Wunused-but-set-variable] Remove the variable struct ethhdr *ethh, which is unused. Fixes: 509e56b37cc3 ("blackhole_dev: add a selftest") Signed-off-by: Breno Leitao Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- lib/test_blackhole_dev.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/lib/test_blackhole_dev.c b/lib/test_blackhole_dev.c index 4c40580a99a36..f247089d63c08 100644 --- a/lib/test_blackhole_dev.c +++ b/lib/test_blackhole_dev.c @@ -29,7 +29,6 @@ static int __init test_blackholedev_init(void) { struct ipv6hdr *ip6h; struct sk_buff *skb; - struct ethhdr *ethh; struct udphdr *uh; int data_len; int ret; @@ -61,7 +60,7 @@ static int __init test_blackholedev_init(void) ip6h->saddr =3D in6addr_loopback; ip6h->daddr =3D in6addr_loopback; /* Ether */ - ethh =3D (struct ethhdr *)skb_push(skb, sizeof(struct ethhdr)); + skb_push(skb, sizeof(struct ethhdr)); skb_set_mac_header(skb, 0); =20 skb->protocol =3D htons(ETH_P_IPV6); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7084913A256; Sun, 24 Mar 2024 22:37:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319838; cv=none; b=GNCkusRByK0RIj9aPImzeXxB/lrCxm8LB0PbxvqqK7Xyo16ZRqFXYGfNj6vOQxVRjGZMwo92S7icwB0JzAN6zuIMs+rhSJZ+kUrIKkjGPW1NpcS93M2r5d5fCc6PzqZPc++qnHOU88H6/p+05zs77YsXKxPzj+WaQnF3qqGOFyA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319838; c=relaxed/simple; bh=TF481GA7/dvxygYzeDlVCuY0/d+mkVT9zKQRiVlmJiQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L69oRrjjpJ9uOL0NHbs7Bxvqfsbly0Dm/vtTVRkhcpEdQuLwOSe3JWe+ysxWBP1/72YuvOqi53axEEA7DN3DxwNDnXd2pNQwSNgpt0P724eoUe3AYCzMlVtz7toYFoSXxjDgQQbekyx5RdfNMYKSypYUsDDWFOvwgt2fkwPcTVQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=owsjPHF4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="owsjPHF4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8313C43390; Sun, 24 Mar 2024 22:37:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319838; bh=TF481GA7/dvxygYzeDlVCuY0/d+mkVT9zKQRiVlmJiQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=owsjPHF4zHYSIE9NmWjLr0cVHnuX2s+s7A3k/Kd4DdhKJmpHgdUDHHtqxpvRXX/DF GAtWjWZVJaSZ8HhJQcBT1ZvSMG3tzTiHTEZ7uBU5Ri1PJMI7i7yhEaJVyPhhQakWq3 bMgCLQgmeo7MOPRs99EpaA7yEkiAQ7TSmgFjfpedob/skGfeX4t1J32aDYq7ECIj7A kk6qbwS+D8TeQg3appi43XYY62h6oUC0qUXv/IQ7jweGd84W3dQqnseBonq50qWaSA XA3dRplCtvs438hugmn6IjQw3iDjKagEGJyioyL8n73lg0YKKeggBViAQQvo3AUcpv ShXxi91PXITTA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Lechner , Mark Brown , Sasha Levin Subject: [PATCH 6.8 141/715] spi: consolidate setting message->spi Date: Sun, 24 Mar 2024 18:25:20 -0400 Message-ID: <20240324223455.1342824-142-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Lechner [ Upstream commit b204aa0f99cfe3c9d796ecfc0bc6f3f89585789e ] Previously, __spi_sync() and __spi_async() set message->spi to the spi device independently after calling __spi_validate(). __spi_validate() also would conditionally set this if it needed to split the message since it wasn't set yet. Since both __spi_sync() and __spi_async() call __spi_validate(), we can consolidate this into only setting message->spi once (unconditionally) in __spi_validate(). This will also save any future callers of __spi_validate() from also needing to set message->spi. Signed-off-by: David Lechner Link: https://msgid.link/r/20240123214946.2616786-1-dlechner@baylibre.com Signed-off-by: Mark Brown Stable-dep-of: c8bec3355f08 ("spi: move split xfers for CS_WORD emulation") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/spi/spi.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index f2170f4b50775..8dfe635fffd63 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -4063,6 +4063,8 @@ static int __spi_validate(struct spi_device *spi, str= uct spi_message *message) if (list_empty(&message->transfers)) return -EINVAL; =20 + message->spi =3D spi; + /* * If an SPI controller does not support toggling the CS line on each * transfer (indicated by the SPI_CS_WORD flag) or we are using a GPIO @@ -4075,9 +4077,6 @@ static int __spi_validate(struct spi_device *spi, str= uct spi_message *message) size_t maxsize =3D BITS_TO_BYTES(spi->bits_per_word); int ret; =20 - /* spi_split_transfers_maxsize() requires message->spi */ - message->spi =3D spi; - ret =3D spi_split_transfers_maxsize(ctlr, message, maxsize, GFP_KERNEL); if (ret) @@ -4214,8 +4213,6 @@ static int __spi_async(struct spi_device *spi, struct= spi_message *message) if (!ctlr->transfer) return -ENOTSUPP; =20 - message->spi =3D spi; - SPI_STATISTICS_INCREMENT_FIELD(ctlr->pcpu_statistics, spi_async); SPI_STATISTICS_INCREMENT_FIELD(spi->pcpu_statistics, spi_async); =20 @@ -4395,8 +4392,6 @@ static int __spi_sync(struct spi_device *spi, struct = spi_message *message) if (status !=3D 0) return status; =20 - message->spi =3D spi; - SPI_STATISTICS_INCREMENT_FIELD(ctlr->pcpu_statistics, spi_sync); SPI_STATISTICS_INCREMENT_FIELD(spi->pcpu_statistics, spi_sync); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F70E13A864; Sun, 24 Mar 2024 22:37:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319839; cv=none; b=Cv5OhzGU9s+0gdkBEzvW2Snq88n8kS9TMknaWjWc3ATHci7Azm86id4liD0buImKIbrpTky4txNV9+al94RK7xbzhyg+tVsNjXuLIPRDHTHGRMNuH2RAM54vIb1YnkiKKl+jjpWJAe1TWwXyx0DEyUJG9NbBJkvI3H0Tfud6Z3c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319839; c=relaxed/simple; bh=3bfJkURzDIggy6eepBk4lgt5ahplmu2n/xt07WfrKJE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=toYGFZLClxusH7SODM8M7I64YlejLHYcbX7EDlwTs3MwScMiH/gZb8ClZXwupXL5W1/64XmERDaU+uZFOSQ3cOfDx6hKc3KW/xNv9n3CRwnnt9DaPWKMacHNE9Cn4NJWDOhf1o96KrRGJcobI7JkmGRI9SJ+QX0vY4XipwhjYLU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M1qTLK9c; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M1qTLK9c" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E319C433C7; Sun, 24 Mar 2024 22:37:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319839; bh=3bfJkURzDIggy6eepBk4lgt5ahplmu2n/xt07WfrKJE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M1qTLK9cO3rjNhSpb0rUEhG/05Rmzl0aVMd8UEfa0bYi1dhgBHrj1GS7nMIPPDkok iRzQ6iuuVCTR/lWAIhWN4zUE+qhXTgjoNdQ4p04wshukNSEWX+i4SN6pscI9EMwYYO toHCQKDL6FC7IaB3na1pVN0gZbv4ZyvFD3PDPA9LsqdxbS3qtqScEuODaca6r54GFl 6CMpNnyeUFh7VIrTRjqdO19tnP0MUSknAY2IaAamJloi3K8b2oZ2WweNNyCjcpG9Qj LIciLsEj4wuM4vrwfLvk6zvATlfLbUS8UA0Bg+gzjjzfarU5vZN+qN1QviNzn7TaOW 5qFzvAZNZIfVQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: David Lechner , Mark Brown , Sasha Levin Subject: [PATCH 6.8 142/715] spi: move split xfers for CS_WORD emulation Date: Sun, 24 Mar 2024 18:25:21 -0400 Message-ID: <20240324223455.1342824-143-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: David Lechner [ Upstream commit c8bec3355f08ddb887d5c13b7095dfa79e6db108 ] This moves splitting transfers for CS_WORD software emulation to the same place where we split transfers for controller-specific reasons. This fixes a few subtle bugs. The calculation for maxsize was wrong for bit sizes between 17 and 24. This is fixed by making use of spi_split_transfers_maxwords() which already has the correct calculation. Also, since this indirectly calls spi_res_alloc(), to avoid leaking resources, spi_finalize_current_message() would need to be called on all error paths in __spi_validate() and callers of __spi_validate() would need to do the same. This is fixed by moving the call to __spi_pump_transfer_message() where it is already splitting transfers for other reasons and correctly releases resources in the subsequent error paths. Fixes: cbaa62e0094a ("spi: add software implementation for SPI_CS_WORD") Signed-off-by: David Lechner Link: https://lore.kernel.org/r/20240126212358.3916280-2-dlechner@baylibre.= com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/spi/spi.c | 63 +++++++++++++++++++++++------------------------ 1 file changed, 31 insertions(+), 32 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index 8dfe635fffd63..d1b297f438f14 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -1747,13 +1747,37 @@ static int __spi_pump_transfer_message(struct spi_c= ontroller *ctlr, =20 trace_spi_message_start(msg); =20 - ret =3D spi_split_transfers_maxsize(ctlr, msg, - spi_max_transfer_size(msg->spi), - GFP_KERNEL | GFP_DMA); - if (ret) { - msg->status =3D ret; - spi_finalize_current_message(ctlr); - return ret; + /* + * If an SPI controller does not support toggling the CS line on each + * transfer (indicated by the SPI_CS_WORD flag) or we are using a GPIO + * for the CS line, we can emulate the CS-per-word hardware function by + * splitting transfers into one-word transfers and ensuring that + * cs_change is set for each transfer. + */ + if ((msg->spi->mode & SPI_CS_WORD) && (!(ctlr->mode_bits & SPI_CS_WORD) || + spi_is_csgpiod(msg->spi))) { + ret =3D spi_split_transfers_maxwords(ctlr, msg, 1, GFP_KERNEL); + if (ret) { + msg->status =3D ret; + spi_finalize_current_message(ctlr); + return ret; + } + + list_for_each_entry(xfer, &msg->transfers, transfer_list) { + /* Don't change cs_change on the last entry in the list */ + if (list_is_last(&xfer->transfer_list, &msg->transfers)) + break; + xfer->cs_change =3D 1; + } + } else { + ret =3D spi_split_transfers_maxsize(ctlr, msg, + spi_max_transfer_size(msg->spi), + GFP_KERNEL | GFP_DMA); + if (ret) { + msg->status =3D ret; + spi_finalize_current_message(ctlr); + return ret; + } } =20 if (ctlr->prepare_message) { @@ -4065,31 +4089,6 @@ static int __spi_validate(struct spi_device *spi, st= ruct spi_message *message) =20 message->spi =3D spi; =20 - /* - * If an SPI controller does not support toggling the CS line on each - * transfer (indicated by the SPI_CS_WORD flag) or we are using a GPIO - * for the CS line, we can emulate the CS-per-word hardware function by - * splitting transfers into one-word transfers and ensuring that - * cs_change is set for each transfer. - */ - if ((spi->mode & SPI_CS_WORD) && (!(ctlr->mode_bits & SPI_CS_WORD) || - spi_is_csgpiod(spi))) { - size_t maxsize =3D BITS_TO_BYTES(spi->bits_per_word); - int ret; - - ret =3D spi_split_transfers_maxsize(ctlr, message, maxsize, - GFP_KERNEL); - if (ret) - return ret; - - list_for_each_entry(xfer, &message->transfers, transfer_list) { - /* Don't change cs_change on the last entry in the list */ - if (list_is_last(&xfer->transfer_list, &message->transfers)) - break; - xfer->cs_change =3D 1; - } - } - /* * Half-duplex links include original MicroWire, and ones with * only one data pin like SPI_3WIRE (switches direction) or where --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8F17F13A89C; Sun, 24 Mar 2024 22:37:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319840; cv=none; b=lYNSm/6WxtcCe8RXHyJ6sL99YMl4jqyFLr/kkXXdeiCDMqB+Z8MM9NPeixg+WRaZ6BRkXhLibbkDfzIw8GazUdfgA9W4st/7CN16H3KczcIGBdFohGuWLtH3001hi7Zhl5nf+R/8KmakxzO/3qlkl5njreThevD0YQF9TfYsjPU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319840; c=relaxed/simple; bh=WdOioiW+2XSsShu2o9vngQVtVbR3+sZyIsXaFbAZv54=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=i3X7Y1Ri/J2ftBo8jJPqvNLCHSYZD4+/0qN1vl52pwRZiVJ2GDKGZ6vLNG16XRSVH0nzSwZ5UsA2O8MTHfvIamEvg453M/4gAm+XrsVYypFsSlMYtRWkZrXN0KJxurG4dxKg7yZ2G4qtx11fIXPP8lYrXcEBElBYrTx4BqYbXUM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fpZkxxAr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fpZkxxAr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73518C43399; Sun, 24 Mar 2024 22:37:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319840; bh=WdOioiW+2XSsShu2o9vngQVtVbR3+sZyIsXaFbAZv54=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fpZkxxArddvOtJl6vSh1Sau4IgUO5h6yzqReCOk9WSKflP409tSexVpR3F59AWYaA jWnOIapGF2IFjk2dHy5qCQwt0bu3qSqfGFfkh+K3OAL831u5Ka4rpJ6ws11R9opQA5 8xp8qDE+qhDaMtxyUgaJbD5JnVJZXc2BCrmDH9bcIrkN8en+MDbz51OZOJOYc4VYio akoTOFIymTldffBnP0PVwUwfmg8Q/G8BCtCf/O+UyVivPG3lLoyFyjkiuzlJR5M3LX clHOcwHPzKNx07CR1zrBA9hwxLYbJG99o3n7nOyBokOHLLTm3dtiFOhxeR7v3kmpeC dYcAUAEoVC7xQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ravi Gunasekaran , Jai Luthra , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 143/715] arm64: dts: ti: k3-am62p5-sk: Enable CPSW MDIO node Date: Sun, 24 Mar 2024 18:25:22 -0400 Message-ID: <20240324223455.1342824-144-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ravi Gunasekaran [ Upstream commit 8839a9af397e803e0447a6b3e69fad54ed22d26d ] Enable the CPSW MDIO node, and link the pinctrl information to enable ethernet on SK-AM62P. Ethernet was unintentally broken on this board, even though these nodes were already present, as enabling them was missed in the original patch. Fixes: c00504ea42c0 ("arm64: dts: ti: k3-am62p5-sk: Updates for SK EVM") Signed-off-by: Ravi Gunasekaran Signed-off-by: Jai Luthra Link: https://lore.kernel.org/r/20240201-am62p_cpsw_mdio-v1-1-05f758300f6e@= ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts b/arch/arm64/boot/dts/= ti/k3-am62p5-sk.dts index 1773c05f752cd..60868862e3b43 100644 --- a/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts +++ b/arch/arm64/boot/dts/ti/k3-am62p5-sk.dts @@ -445,6 +445,10 @@ &cpsw_port2 { }; =20 &cpsw3g_mdio { + pinctrl-names =3D "default"; + pinctrl-0 =3D <&main_mdio1_pins_default>; + status =3D "okay"; + cpsw3g_phy0: ethernet-phy@0 { reg =3D <0>; ti,rx-internal-delay =3D ; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4428813AA38; Sun, 24 Mar 2024 22:37:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319841; cv=none; b=XOzoHAASzf26Z6QaOo2hvYPaAsAgaMDzAUYUlBfPIj6okA89AOhxb8M9MfxrcCNAHX3YsLMbwHo5rYJR0StSzNkbsuD1Rq7x9kwCxkoVpArepIJxh1MBiUj4Ms1jfbbX9HsREWoyktKg+dx4UlCqpmbhJ+Vt96uOLerGUFep1Wg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319841; c=relaxed/simple; bh=Ss+KgOwG9QJQ+Pdfqn7/6z9VceW9yvJPmtKSu+GCfPw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hmkRAaasTv5UE1FuTjTaxiYE+zPmbMe7+tjhy4GvaivaGYdVPAS47f00G3m/kJs1KbxiJguXRb+MoevnkK4YF0bEdy3vDChW9khlP8orJHf9qqnsfKXthCSlDONjwGGS5XtYNIte+m0/aoOdGbDRDSCdHVb5zec+2wDRGrCT5+g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mXnVeoBR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mXnVeoBR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6EBB6C433A6; Sun, 24 Mar 2024 22:37:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319841; bh=Ss+KgOwG9QJQ+Pdfqn7/6z9VceW9yvJPmtKSu+GCfPw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mXnVeoBRCON9lHzjY4TPcBpWm/YHJRkdyQm96Oz61DgC9UQgN09tJoyaMDZh+RZ+D QdCI2mArGnvIEJOK70v/kOETZuBcr33qlx7Ms+9R4QR1GxywGpPOAKxSDAmS60NwX8 taNQggKSx/BiVgIRKiQmTbuPuFax18e/EKyA0H5Rn9Hnnuq1tph8fqA+a2tKDCS2iw 9lCR+7Sui9oMn6W5t1UlCUhX/ZGzfm0YDAonC5kt4mwVDw2xww7tjkaW/dOKgqabH1 w/j50albfIlssHpVsxeIPfnJWjI4vxNMwN0Pi8yo9nsFdD18EdcsthYOVPXZJA5Vgn BsLC940S12Qmw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Manorit Chawdhry , Andrew Davis , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 144/715] arm64: dts: ti: k3-j721s2: Fix power domain for VTM node Date: Sun, 24 Mar 2024 18:25:23 -0400 Message-ID: <20240324223455.1342824-145-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Manorit Chawdhry [ Upstream commit 5ef196ed912e80a1e64936119ced8d7eb5635f0f ] Fix the power domain device ID for wkup_vtm0 node. Link: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721s2/devices.= html Fixes: d148e3fe52c8 ("arm64: dts: ti: j721s2: Add VTM node") Signed-off-by: Manorit Chawdhry Reviewed-by: Andrew Davis Link: https://lore.kernel.org/r/20240201-b4-upstream-j721s2-fix-vtm-devid-v= 2-1-85fd568b77e3@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi b/arch/arm64/= boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi index 80aa33c58a452..a47cb557dd956 100644 --- a/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi +++ b/arch/arm64/boot/dts/ti/k3-j721s2-mcu-wakeup.dtsi @@ -663,7 +663,7 @@ wkup_vtm0: temperature-sensor@42040000 { compatible =3D "ti,j7200-vtm"; reg =3D <0x00 0x42040000 0x0 0x350>, <0x00 0x42050000 0x0 0x350>; - power-domains =3D <&k3_pds 154 TI_SCI_PD_SHARED>; + power-domains =3D <&k3_pds 180 TI_SCI_PD_SHARED>; #thermal-sensor-cells =3D <1>; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4521313AA5A; Sun, 24 Mar 2024 22:37:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319842; cv=none; b=nFmtTwk2GDzFv0sxTmTZc9OS9FZS56TXw9/uoMAN4UyvYwXvsUa6cieOuQCaCMzxNaH94mVN6MsJ2GkzJq4ljq9kGWqSuFXCaF2SnO7uOiO7g97r0jtjBGKsx2Hlhzv7mOOBI5aJww+xv76TFPC/44BzEPxjY07grP3BQl6hiPk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319842; c=relaxed/simple; bh=9NcakU9G8bqt6hsTUXpyWlRCofJvXcdffxzku17p6/8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b0l/pe/I/hek8Cs2BxPKv2rbChtWMj9jkdV/PzihWCAGHb6FKvGA5OV4gACO/MvfNoW0UmI78jtaSRMf6XdY+zDIU/gVAe6co5yqSpgCZzJw3pVe9ZhlKfMzwXcTHgwU0Dt6mk6wON9/ZvZQVu7G9nu5R43z2uzkL6kUqN0zdqU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ONO5Ddea; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ONO5Ddea" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B90FC43390; Sun, 24 Mar 2024 22:37:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319842; bh=9NcakU9G8bqt6hsTUXpyWlRCofJvXcdffxzku17p6/8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ONO5Ddea/k17fUcg+sBZI96Vnb6DgH22tnMQgzTCf24plXkPwjEOVLnyE0gOv6Fxt JVsqkA1VCaUIyeVhUGQuYN8RF+vNINQ2q2UhqIeFRIdUI/ATvGHSesSeAVP5cf2IG5 G9IucWkJBZ9NjlF2TmO3B+yVOOhLY2Q6g0eAQFTJZsMFYlSbTRmX+rrKuoFlo00j/b VfS/MuKc0ZEt6XBnZL6hD15JvKUBe/7XfyeEgrEKZR5o9fML8PEBP3EUZLdIGlyaW0 SANR+Uovr0nv8pbNzo6Y6jHvRtOohcaixtFBjig2SXV89jJ1q0u+W6Ss6YX7fkt0HB Bgn/nmPPigrcQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Manorit Chawdhry , Andrew Davis , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 145/715] arm64: dts: ti: k3-j784s4: Fix power domain for VTM node Date: Sun, 24 Mar 2024 18:25:24 -0400 Message-ID: <20240324223455.1342824-146-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Manorit Chawdhry [ Upstream commit e4d252e6d29208aea56d4c04270523e306b1e3c2 ] Fix the power domain device ID for wkup_vtm0 node. Link: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j784s4/devices.= html Fixes: 64821fbf6738 ("arm64: dts: ti: j784s4: Add VTM node") Signed-off-by: Manorit Chawdhry Reviewed-by: Andrew Davis Link: https://lore.kernel.org/r/20240201-b4-upstream-j721s2-fix-vtm-devid-v= 2-2-85fd568b77e3@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi b/arch/arm64/= boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi index 3902a921d7e58..337122c3f4020 100644 --- a/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi +++ b/arch/arm64/boot/dts/ti/k3-j784s4-mcu-wakeup.dtsi @@ -628,7 +628,7 @@ wkup_vtm0: temperature-sensor@42040000 { compatible =3D "ti,j7200-vtm"; reg =3D <0x00 0x42040000 0x00 0x350>, <0x00 0x42050000 0x00 0x350>; - power-domains =3D <&k3_pds 154 TI_SCI_PD_SHARED>; + power-domains =3D <&k3_pds 243 TI_SCI_PD_SHARED>; #thermal-sensor-cells =3D <1>; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4E73813B29F; Sun, 24 Mar 2024 22:37:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319843; cv=none; b=ByjM58N2PfcUm+rtfLP5tBB7uA2JEWcQzN3aelfWY97XbSDueGHs6pSG3GUJPoURNPI7RZaFgS4d62u6m4Iz28UJwpHgfKCCxxF1E2V8Lf/hf4d/50UfGAF3x9+iJK6smIjm8kJC0/cCV/bazatx1SwWrTjQZr1VyVHMFf9whkE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319843; c=relaxed/simple; bh=7yg7GgPd0ZDeUdmhMXbVBOY/7e+30tl6Ej6hje7XTFQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YmTejbDVVF8Sfd77bcqQ99HRiZapTiYcM3VMoY3bM9WsB0foOaMDVd6mXJFgUhYw66ODRR/13qEogKRM2z6Apkz2mnwK/utoVJXFwJo+rORXo68qHTrDtMPlzeumaJq25QmMXlu7dcz1nwkHA9FMGVZmgF4mKy8XjYSLk+g1tHY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=D5CR40BO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="D5CR40BO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 674C8C433C7; Sun, 24 Mar 2024 22:37:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319843; bh=7yg7GgPd0ZDeUdmhMXbVBOY/7e+30tl6Ej6hje7XTFQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=D5CR40BOMmiF1QxmiD9Q0xp/p+QIHGmqNeCig2vQqPQlPmRhTDtDm5DWuS7jgNewo rEr6IeplnYTGWseTDtGcR3GgKmvL9UIbmmX/+JfQa9MEd5eCrKw8Ctxa5l206hgbEX 2mq7QaFC2giz11B6cLZd08LFqEUwMy6LZBDkGDp+owcsLHh6A4DyXWlGbLUTg24L8e 0k+VaHNJQIo81LZzDE2OCXHv8yFFX2CN0TcUpDAPvH32Idw2/R4X2NwODN9rDAwt5W opUNgoTK7DslDujV1fc9uKJr1EUKpcsqnLobsS6DBe31TUwcBD6+U6hMlXso20xFcB rh0qc3ls01WHQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Baochen Qiang , kernel test robot , Jeff Johnson , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 146/715] wifi: ath11k: initialize rx_mcs_80 and rx_mcs_160 before use Date: Sun, 24 Mar 2024 18:25:25 -0400 Message-ID: <20240324223455.1342824-147-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Baochen Qiang [ Upstream commit b802e7b7e771dee3377d071418281f8b64d2d832 ] Currently in ath11k_peer_assoc_h_he() rx_mcs_80 and rx_mcs_160 are used to calculate max_nss, see if (support_160) max_nss =3D min(rx_mcs_80, rx_mcs_160); else max_nss =3D rx_mcs_80; Kernel test robot complains on uninitialized symbols: drivers/net/wireless/ath/ath11k/mac.c:2321 ath11k_peer_assoc_h_he() error: = uninitialized symbol 'rx_mcs_80'. drivers/net/wireless/ath/ath11k/mac.c:2321 ath11k_peer_assoc_h_he() error: = uninitialized symbol 'rx_mcs_160'. drivers/net/wireless/ath/ath11k/mac.c:2323 ath11k_peer_assoc_h_he() error: = uninitialized symbol 'rx_mcs_80'. This is because there are some code paths that never set them, so the assignment of max_nss can come from uninitialized variables. This could result in some unknown issues since a wrong peer_nss might be passed to firmware. Change to initialize them to an invalid value at the beginning. This makes sense because even max_nss gets an invalid value, due to either or both of them being invalid, we can get an valid peer_nss with following guard: arg->peer_nss =3D min(sta->deflink.rx_nss, max_nss) Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_L= ITE-3.6510.23 Fixes: 3db26ecf7114 ("ath11k: calculate the correct NSS of peer for HE capa= bilities") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202401311243.NyXwWZxP-lkp@int= el.com/ Signed-off-by: Baochen Qiang Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240202023547.11141-1-quic_bqiang@quicinc.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/ath/ath11k/mac.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/a= th/ath11k/mac.c index b6b474a7f1c9c..cc80310088ce1 100644 --- a/drivers/net/wireless/ath/ath11k/mac.c +++ b/drivers/net/wireless/ath/ath11k/mac.c @@ -2297,6 +2297,8 @@ static void ath11k_peer_assoc_h_he(struct ath11k *ar, mcs_160_map =3D le16_to_cpu(he_cap->he_mcs_nss_supp.rx_mcs_160); mcs_80_map =3D le16_to_cpu(he_cap->he_mcs_nss_supp.rx_mcs_80); =20 + /* Initialize rx_mcs_160 to 9 which is an invalid value */ + rx_mcs_160 =3D 9; if (support_160) { for (i =3D 7; i >=3D 0; i--) { u8 mcs_160 =3D (mcs_160_map >> (2 * i)) & 3; @@ -2308,6 +2310,8 @@ static void ath11k_peer_assoc_h_he(struct ath11k *ar, } } =20 + /* Initialize rx_mcs_80 to 9 which is an invalid value */ + rx_mcs_80 =3D 9; for (i =3D 7; i >=3D 0; i--) { u8 mcs_80 =3D (mcs_80_map >> (2 * i)) & 3; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 33E3E13B789; Sun, 24 Mar 2024 22:37:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319844; cv=none; b=GFLgRTzPg3NORZXmpWW8xlz6BE4SLwZzYgAx7Ku13XwW17YdBjJDvTTlgYE/+fe4ChK2vLNQTWngFN7uW03iBIgYf7Y7u9xr2RnOLbZE5OBCR64KxHw6ZAcGpZoKlYLLCSdUthHvsIjkotNATCwLdBGvdn1VdkEmMEDO242noo0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319844; c=relaxed/simple; bh=RQrolhc/4neGjp94YqluMsQFQZd5V1OjoECo2SmYWsM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RhZRJhFclxVlr+IcdsP1qAEYmfN44y6YPuYYYKyt78HNr/QvgGQvGkqbOSp46O1w1cFlSHc00ryXe0070vF7sV8XhEsvzZDzCXejEMhiw2nS5zK6bNK98XKn92/vMIe7lfUNtJM2BjBdigqp0ntq34TtuM4I1oGCt05TOJ7XQR0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oa9nLK38; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oa9nLK38" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73A0AC43399; Sun, 24 Mar 2024 22:37:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319844; bh=RQrolhc/4neGjp94YqluMsQFQZd5V1OjoECo2SmYWsM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oa9nLK38Zy6K6uNyruhiS1s6AozBrf2ryei3juou4B+vNfJ1Ut9DQJX+14rAjHi4/ p1QUTKrrT+udefM6G3IYgBAqTeGuTUkt7uv1Brb5t+fjaZlbBU8fss5m/mvXN3sP6K dC8X71TcW9YO8cgJBF3nmr3/HQRDXkDVRrGiv+bDU2OuhuZPKDFKy3/liQrkNZ/cYJ yraEwaAYJKJ9pADpIGYL6wU9jz+Kpi/86cOVyfMAfRmQNdOOJjwHudcjHOxrLAst5x Oe9OJXbR1uJHWk5+8BuAlfdbLJ+DsS57VSOrWhdSbKxPgmIZrOUgX74Zj+gvu7UeUC lnh9FXdQQr7/A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zhipeng Lu , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 147/715] wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer() Date: Sun, 24 Mar 2024 18:25:26 -0400 Message-ID: <20240324223455.1342824-148-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zhipeng Lu [ Upstream commit 5f0e4aede01cb01fa633171f0533affd25328c3a ] In the for statement of lbs_allocate_cmd_buffer(), if the allocation of cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer(). Fixes: 876c9d3aeb98 ("[PATCH] Marvell Libertas 8388 802.11b/g USB driver") Signed-off-by: Zhipeng Lu Signed-off-by: Kalle Valo Link: https://msgid.link/20240126075336.2825608-1-alexious@zju.edu.cn Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/marvell/libertas/cmd.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/marvell/libertas/cmd.c b/drivers/net/wire= less/marvell/libertas/cmd.c index 104d2b6dc9af6..5a525da434c28 100644 --- a/drivers/net/wireless/marvell/libertas/cmd.c +++ b/drivers/net/wireless/marvell/libertas/cmd.c @@ -1132,7 +1132,7 @@ int lbs_allocate_cmd_buffer(struct lbs_private *priv) if (!cmdarray[i].cmdbuf) { lbs_deb_host("ALLOC_CMD_BUF: ptempvirtualaddr is NULL\n"); ret =3D -1; - goto done; + goto free_cmd_array; } } =20 @@ -1140,8 +1140,17 @@ int lbs_allocate_cmd_buffer(struct lbs_private *priv) init_waitqueue_head(&cmdarray[i].cmdwait_q); lbs_cleanup_and_insert_cmd(priv, &cmdarray[i]); } - ret =3D 0; + return 0; =20 +free_cmd_array: + for (i =3D 0; i < LBS_NUM_CMD_BUFFERS; i++) { + if (cmdarray[i].cmdbuf) { + kfree(cmdarray[i].cmdbuf); + cmdarray[i].cmdbuf =3D NULL; + } + } + kfree(priv->cmd_array); + priv->cmd_array =3D NULL; done: return ret; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 719705102B; Sun, 24 Mar 2024 22:37:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319845; cv=none; b=Y1sZMc6ljy/5VJmhtjTix55QTVx08eJgD2hjG2vRquRDDcKoV71libvJcD+H6tF2b8JdNsulAbqMF7RJUG6iq3uvjEGe0y7J1UjRGvWEg7Kn7ZxJXtUzRJnTP0tFTk18Yugb0ycYEo550Ad58GRzSrcB0FHjwHAjFlOnWe4qFck= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319845; c=relaxed/simple; bh=i8WxCooOi6vx5cFxryVnmLSk4xFvJqunsS2uEQTcELQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NmdknFOHCjC8L1k2bpUe58JXLEbLI+PB91flGvQFkv0PIvtGl6GSrzgxfHQY20GamEwl8hdU8xkN8wYlv8nsZHch/0BorX5WvH4U/+tHIOLI/AhY2l1v1T0IbpPa2chUKsa0yW8pPGUuzzDKP3qQKxxI5gOywSVIRMK45bs6ZkE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Jw+IKGZV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Jw+IKGZV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58893C433B2; Sun, 24 Mar 2024 22:37:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319845; bh=i8WxCooOi6vx5cFxryVnmLSk4xFvJqunsS2uEQTcELQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Jw+IKGZVy3S1eXLg8MGiwHfzKbrkx2lOZiF3IUGyUYfaz2g9psyWynrtUpVjKS//n UrjcSi60uK2qDe0Zy7wCSccK2tGmZVof6i4HzAkPqRY0oGfQX6pf8VQ1kb9Cqdh5kZ JxLkmOnmjHdKn3Cr/ovAjx/06bxkQMlFKagaDDNyqCtH1gIRLAPyN8PbRVlNTevkm9 0OFiFGuvEZdMJxNNxlhdqT7AYuYuq8gU0KcOJBrBa7MjhXUiwBal6mW9jpTbcbOJCX Kd4vedZZbjdywz7lEKhIfbU8UeFROlxIeOGeXYRRWLwo2zkUocaqymJXQ9Ihx+UZaB 92Rff9t/h6vRA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jayesh Choudhary , Nishanth Menon , Tomi Valkeinen , Aradhya Bhatia , Enric Balletbo i Serra , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 148/715] arm64: dts: ti: k3-am69-sk: remove assigned-clock-parents for unused VP Date: Sun, 24 Mar 2024 18:25:27 -0400 Message-ID: <20240324223455.1342824-149-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jayesh Choudhary [ Upstream commit cfdb4f7ffdb855c1a3d274dc7757e780dcbf2d55 ] VP2 and VP3 are unused video ports and VP3 share the same parent clock as VP1 causing issue with pixel clock setting for HDMI (VP1). The current DM firmware does not support changing parent clock if it is shared by another component. It returns 0 for the determine_rate query before causing set_rate to set the clock at default maximum of 1.8GHz which is a lot more than the maximum frequency videoports can support (600MHz) causing SYNC LOST issues. So remove the parent clocks for unused VPs to avoid conflict. Fixes: 6f8605fd7d11 ("arm64: dts: ti: k3-am69-sk: Add DP and HDMI support") Reported-by: Nishanth Menon Signed-off-by: Jayesh Choudhary Reviewed-by: Tomi Valkeinen Reviewed-by: Aradhya Bhatia Tested-by: Enric Balletbo i Serra Link: https://lore.kernel.org/r/20240201142308.4954-1-j-choudhary@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-am69-sk.dts | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti= /k3-am69-sk.dts index 8da5915798688..370980eb59b02 100644 --- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts +++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts @@ -918,13 +918,9 @@ &dss { pinctrl-names =3D "default"; pinctrl-0 =3D <&dss_vout0_pins_default>; assigned-clocks =3D <&k3_clks 218 2>, - <&k3_clks 218 5>, - <&k3_clks 218 14>, - <&k3_clks 218 18>; + <&k3_clks 218 5>; assigned-clock-parents =3D <&k3_clks 218 3>, - <&k3_clks 218 7>, - <&k3_clks 218 16>, - <&k3_clks 218 22>; + <&k3_clks 218 7>; }; =20 &serdes_wiz4 { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9B54313B2AD; Sun, 24 Mar 2024 22:37:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319846; cv=none; b=ZXD+QfMPnQKdUv/EDC9MyOd7EpPsl++EU1pVgsPthqOwYjFTeKILBgFn5xFFjezimUneRJo/cjsTkDBqxIF6exstnOvj0slh+VRESsNXgKR/RhFYXUawSt4/OkJ+pgiT6q1ue7GCyJ+vfef8YHHAvGcQhtE0rRje8f2h3q9WFzY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319846; c=relaxed/simple; bh=RS261kmGXJYyPUvad40D15vQBBgpG6lBChV7vQ11Syw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AoxPIbQ8jOwBA302NCKLz9091A6sSXyjnr58la815u7c+cesq4GvSvLLNrGf7v0wrUq9Igx5iTgSKjNXUkt0q9nW7xeM3ErXHj6acvAzVn6MLxvFPpdRMFC30Stbs4Tp1guye2LlGmJYOH9yXmXXHNL9TJ9V7OggIQNip0CjioE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tduXeUpW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tduXeUpW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92AD6C43390; Sun, 24 Mar 2024 22:37:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319846; bh=RS261kmGXJYyPUvad40D15vQBBgpG6lBChV7vQ11Syw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tduXeUpWfQkM6SaKmZC21L0DyY4e4a2SkBfbTZ/jnN8D25W5ALyQHOkO/3DRHrdXj QR2xYmaxoGLey1MG0OeFX1Swvn5kpuwJiqERidE+QIsRpcTHr1Amkau6beImI1DuLG 9YjO4pqemMcwF+NyBSQpPzlwbfTJsjdFwfg+jp3BTXcipdR3Ocn3cmf6gFrj2v31hL kttPJLeukH7rhGRuDc1PFAVDduC39hImrl8nZSxezGOYsvZcl8AO9YmKBG7RWx/kVx FW1uY14YJJuzR1pAviG12vFzkDTxBQId5E8cAQPTpYtWWUfT9Woe4pjvUCciTtF3Fi sPPdhuElMb4Yg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrii Nakryiko , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 149/715] libbpf: fix return value for PERF_EVENT __arg_ctx type fix up check Date: Sun, 24 Mar 2024 18:25:28 -0400 Message-ID: <20240324223455.1342824-150-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrii Nakryiko [ Upstream commit d7bc416aa5cc183691287e8f0b1d5b182a7ce9c3 ] If PERF_EVENT program has __arg_ctx argument with matching architecture-specific pt_regs/user_pt_regs/user_regs_struct pointer type, libbpf should still perform type rewrite for old kernels, but not emit the warning. Fix copy/paste from kernel code where 0 is meant to signify "no error" condition. For libbpf we need to return "true" to proceed with type rewrite (which for PERF_EVENT program will be a canonical `struct bpf_perf_event_data *` type). Fixes: 9eea8fafe33e ("libbpf: fix __arg_ctx type enforcement for perf_event= programs") Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20240206002243.1439450-1-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/lib/bpf/libbpf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c index 910f72c9e6a49..92bca96587a4a 100644 --- a/tools/lib/bpf/libbpf.c +++ b/tools/lib/bpf/libbpf.c @@ -6755,13 +6755,13 @@ static bool need_func_arg_type_fixup(const struct b= tf *btf, const struct bpf_pro case BPF_PROG_TYPE_PERF_EVENT: if (__builtin_types_compatible_p(bpf_user_pt_regs_t, struct pt_regs) && btf_is_struct(t) && strcmp(tname, "pt_regs") =3D=3D 0) - return 0; + return true; if (__builtin_types_compatible_p(bpf_user_pt_regs_t, struct user_pt_regs= ) && btf_is_struct(t) && strcmp(tname, "user_pt_regs") =3D=3D 0) - return 0; + return true; if (__builtin_types_compatible_p(bpf_user_pt_regs_t, struct user_regs_st= ruct) && btf_is_struct(t) && strcmp(tname, "user_regs_struct") =3D=3D 0) - return 0; + return true; break; case BPF_PROG_TYPE_RAW_TRACEPOINT: case BPF_PROG_TYPE_RAW_TRACEPOINT_WRITABLE: --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5DE3B13DB8A; Sun, 24 Mar 2024 22:37:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319847; cv=none; b=M3NQS/VWj8xPGtSK6JO+zyG44E8zzyT7rwB2qbo+lMIhesl2epg8d0bBzL3C1LYQewc9eM4FOwliyrtDKDwcZBy0blGzoZV7zzXqO4XvU+w6bsAfirJ12fkyfdjTtG+/AHB4JQnq0ZNAg+HrTfDEDRKSch7+szTUu0z7e748GvI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319847; c=relaxed/simple; bh=rG5XrogOSq/XWBkIgCSJ3+HmAxbP/ixfn56h6FYIyuQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fI+/+dEr7b2Et541CJ79suyu4h2unYS1phKalObyvPdsafnbyoXZvVh7iSpI6RggB9E2AtmOgJUhV2qYkatKeOSV8MAfeAdDGj8uf56kV7sWvTeZMyfJGncCy3/wSJ+ZvQ9CQ6AFmVmeyAieUKc9kiraJ4bRg8K1zlC1LtOQUz0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nPDAfp7N; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nPDAfp7N" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75148C43394; Sun, 24 Mar 2024 22:37:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319847; bh=rG5XrogOSq/XWBkIgCSJ3+HmAxbP/ixfn56h6FYIyuQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nPDAfp7N4k+hNewM5qQg30HGgUaoi/mmyEG/0zq9Oz3wNryMG1pl1OAh0yuKdFwD+ PMRKPCCeaLHDkCjD0SA2WOQeVhSI5DOzxgjjtui9rvZMaAzbhKIpTPLXiXdLlx7zbk LJSuVOEDO5syhzTOBPhKw5ak21f0WC/gdZu2tUfjYv5oKQ/gxdp0vuFGWwQjXJkTPa guh41tuKHU+8EJyy1/dMTVVjrn5WbvZ+7P3Kz/es53S5VrVNJ/zIQEUEIYASK0AspY xtqm2vgAjUYUCUv4N4FixlSxU8DE0AjXuzUC5T0UcSIlXm7hBaEq93EGjRf+dNneU1 cqZmpdVHLMMug== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vaishnav Achath , Jayesh Choudhary , Nishanth Menon , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 150/715] arm64: dts: ti: k3-am62p-mcu/wakeup: Disable MCU and wakeup R5FSS nodes Date: Sun, 24 Mar 2024 18:25:29 -0400 Message-ID: <20240324223455.1342824-151-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vaishnav Achath [ Upstream commit dfc90e5f1a0fe0f8124521bc1911e38aa6cd9118 ] K3 Remoteproc R5 driver requires reserved memory carveouts and mailbox configuration to instantiate the cores successfully. Since this is a board level dependency, keep the R5 subsytem disabled at SoC dtsi, otherwise it results in probe errors like below during AM62P SK boot: r5fss@79000000: reserved memory init failed, ret =3D -22 r5fss@79000000: k3_r5_cluster_rproc_init failed, ret =3D -22 r5fss@78000000: reserved memory init failed, ret =3D -22 r5fss@78000000: k3_r5_cluster_rproc_init failed, ret =3D -22 Fixes: b5080c7c1f7e ("arm64: dts: ti: k3-am62p: Add nodes for more IPs") Signed-off-by: Vaishnav Achath Reviewed-by: Jayesh Choudhary Reviewed-by: Nishanth Menon Link: https://lore.kernel.org/r/20240121134017.374992-1-vaishnav.a@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-am62p-mcu.dtsi | 2 ++ arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi | 1 + 2 files changed, 3 insertions(+) diff --git a/arch/arm64/boot/dts/ti/k3-am62p-mcu.dtsi b/arch/arm64/boot/dts= /ti/k3-am62p-mcu.dtsi index c4b0b91d70cf3..14eb9ba836d32 100644 --- a/arch/arm64/boot/dts/ti/k3-am62p-mcu.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62p-mcu.dtsi @@ -187,6 +187,8 @@ mcu_r5fss0: r5fss@79000000 { ranges =3D <0x79000000 0x00 0x79000000 0x8000>, <0x79020000 0x00 0x79020000 0x8000>; power-domains =3D <&k3_pds 7 TI_SCI_PD_EXCLUSIVE>; + status =3D "disabled"; + mcu_r5fss0_core0: r5f@79000000 { compatible =3D "ti,am62-r5f"; reg =3D <0x79000000 0x00008000>, diff --git a/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi b/arch/arm64/boot/= dts/ti/k3-am62p-wakeup.dtsi index 19f42b39394ee..10a7059b2d9b5 100644 --- a/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi @@ -78,6 +78,7 @@ wkup_r5fss0: r5fss@78000000 { ranges =3D <0x78000000 0x00 0x78000000 0x8000>, <0x78100000 0x00 0x78100000 0x8000>; power-domains =3D <&k3_pds 119 TI_SCI_PD_EXCLUSIVE>; + status =3D "disabled"; =20 wkup_r5fss0_core0: r5f@78000000 { compatible =3D "ti,am62-r5f"; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5399E13DBBB; Sun, 24 Mar 2024 22:37:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319848; cv=none; b=irvXcVaTS27KAtZ4isAIVcyOvMIi1S1Z96AimipyzpHk83xBvrljr4s8vyZosEXHpSOgs6DyDmatPWvN3uVx23/J6lhxg5vjtL/uEBYN1tEIiQOULskE+erSzS+eafkbq3r3ODD0JgtjonG2J9fHokUjvJhK1DMpq2GUxWsn0yo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319848; c=relaxed/simple; bh=gx4eZVC9G/0GVO15fm/mEKgXDVa2hcqjveI2hkLEjSE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RfhEwMrISllbv333O3nUGkB7qK2UqwKB8HIlEzhiusFr//oND9lY16NUkE3otm0UvYwO2FP+Xog7+1g17Mk5FdieQMWjnotPfa1lFH+kUxSt/eoeUVslEyxeGuXHpIwly05cXIg+5lqKll+a6kItYMcbBtv5K2u2tuEeU3fCkBM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Q6/7bs03; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Q6/7bs03" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 810CFC433C7; Sun, 24 Mar 2024 22:37:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319848; bh=gx4eZVC9G/0GVO15fm/mEKgXDVa2hcqjveI2hkLEjSE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Q6/7bs03bOpU7GUo3FTxMtvTRLs6B0rHM9xtB3Fr7YSDe0tRfkz3qgCBDH576RA4A X06CtXGJrMwLkBAoGR46jUucYoMPVZ1IbLsL1kmQfISDF3csXs53gIA51ctZsh2iHD 1K9LxwNavZ6c962oJRuKhvSdJ0novwbI7mTpUIpZjXQJRSbYBAUO9iNXBdWX+YQ/Bg VjmNotrjvC4B2ifNPcfrISDfTNQqvFnbI5fCXJOT9GpklKbeCmwRJdFUP+ea1qdHAp cM9qMdqdGvk2vWqDt6hXfdv8c8ScSWr4P2CbnjPY9m5Js3E/8bRNgNJ/cUMRD257iP rDp4FR1UvaDSA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Abel Vesa , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 151/715] arm64: dts: qcom: x1e80100-qcp: Fix supplies for LDOs 3E and 2J Date: Sun, 24 Mar 2024 18:25:30 -0400 Message-ID: <20240324223455.1342824-152-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Abel Vesa [ Upstream commit 7eac281cbedbd71d777eabca3a52d97983c61692 ] The LDOs 3E and 2J are actually supplied by SMPS 5J. Fix accordingly. Fixes: af16b00578a7 ("arm64: dts: qcom: Add base X1E80100 dtsi and the QCP = dts") Acked-by: Konrad Dybcio Signed-off-by: Abel Vesa Link: https://lore.kernel.org/r/20240129-x1e80100-dts-missing-nodes-v6-11-2= c0e691cfa3b@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/x1e80100-qcp.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts b/arch/arm64/boot/dt= s/qcom/x1e80100-qcp.dts index a37ad9475c90d..3112487d2a168 100644 --- a/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts +++ b/arch/arm64/boot/dts/qcom/x1e80100-qcp.dts @@ -243,7 +243,7 @@ regulators-3 { qcom,pmic-id =3D "e"; =20 vdd-l2-supply =3D <&vreg_s1f_0p7>; - vdd-l3-supply =3D <&vph_pwr>; + vdd-l3-supply =3D <&vreg_s5j_1p2>; =20 vreg_l2e_0p8: ldo2 { regulator-name =3D "vreg_l2e_0p8"; @@ -349,7 +349,7 @@ regulators-7 { qcom,pmic-id =3D "j"; =20 vdd-l1-supply =3D <&vreg_s1f_0p7>; - vdd-l2-supply =3D <&vph_pwr>; + vdd-l2-supply =3D <&vreg_s5j_1p2>; vdd-l3-supply =3D <&vreg_s1f_0p7>; vdd-s5-supply =3D <&vph_pwr>; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 36C8D13F00A; Sun, 24 Mar 2024 22:37:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319849; cv=none; b=rrHxXx2DzWK4lxJ1PlrKaqUYBbrIffeDru6yyJL2rH/PYIZNSkMymGUXk08aThHbYTJxJS6UjnvrIctDhWtEUgd2+v1Yy7P0k0X+Ln9KNp1q1PP50Z6rF+nGuypT/0uhLEp2DAVszrYtWbOl6Wg3yo3+pi7d3iGZ3Md0KEfW9ck= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319849; c=relaxed/simple; bh=Un5M0+Yy9i5pV1czleybjGf4TKM5KEaVe8OK7vHagJE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nDB/J8Eh9ZcM5rLxMl1rQWb0rxVVw2FoGe9Bac4tdsoBasAtXwg+xOzm9QeYw83fUESPbocUG13+1ga1Gkw4s+Y60U1qqzkhvpVyDxfsfn2cdNfeA66Eh7Z+vKzfTYRZZMhR1O65oZFTm/BnSrNP+fV7AOEaK+WUpiC6Y+FEtmE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f9nz3ABa; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="f9nz3ABa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79F56C433F1; Sun, 24 Mar 2024 22:37:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319849; bh=Un5M0+Yy9i5pV1czleybjGf4TKM5KEaVe8OK7vHagJE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f9nz3ABaaQJu2OpYQU4ApEUihX2TJ9if3E5UbBPMGal3Dc6J2YbkXSPy4RTDwgIdy 0RAVRdn8hc4CF2WCF21DeP6dLvkARn97groFW/RDiPbPsRDp78Zt0K6jtuYmCfHnPl sFocEJ4RcRQf3aNtbj/AZvwAS+eJypx9N07l3wXQrcUbx1ZfR4GwACMyKmjO7qNdvN fFq/GtD1NBl3L0BPuUSQ11xvDu4WTPu6N66JIaUs286WqC18KDE+N7Gd6J4jBP8m0S IwoR0WdGiKiwLa4YJ+feQ3rW6G5UpC83feYFAXqjS1lPvFkFQg034ufsdsskonIFeO oh987lS4aRTXQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= , Andrii Nakryiko , Sasha Levin Subject: [PATCH 6.8 152/715] libbpf: Use OPTS_SET() macro in bpf_xdp_query() Date: Sun, 24 Mar 2024 18:25:31 -0400 Message-ID: <20240324223455.1342824-153-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Toke H=C3=B8iland-J=C3=B8rgensen [ Upstream commit 92a871ab9fa59a74d013bc04f321026a057618e7 ] When the feature_flags and xdp_zc_max_segs fields were added to the libbpf bpf_xdp_query_opts, the code writing them did not use the OPTS_SET() macro. This causes libbpf to write to those fields unconditionally, which means that programs compiled against an older version of libbpf (with a smaller size of the bpf_xdp_query_opts struct) will have its stack corrupted by libbpf writing out of bounds. The patch adding the feature_flags field has an early bail out if the feature_flags field is not part of the opts struct (via the OPTS_HAS) macro, but the patch adding xdp_zc_max_segs does not. For consistency, this fix just changes the assignments to both fields to use the OPTS_SET() macro. Fixes: 13ce2daa259a ("xsk: add new netlink attribute dedicated for ZC max f= rags") Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20240206125922.1992815-1-toke@redhat.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/lib/bpf/netlink.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/lib/bpf/netlink.c b/tools/lib/bpf/netlink.c index 090bcf6e3b3d5..68a2def171751 100644 --- a/tools/lib/bpf/netlink.c +++ b/tools/lib/bpf/netlink.c @@ -496,8 +496,8 @@ int bpf_xdp_query(int ifindex, int xdp_flags, struct bp= f_xdp_query_opts *opts) if (err) return libbpf_err(err); =20 - opts->feature_flags =3D md.flags; - opts->xdp_zc_max_segs =3D md.xdp_zc_max_segs; + OPTS_SET(opts, feature_flags, md.flags); + OPTS_SET(opts, xdp_zc_max_segs, md.xdp_zc_max_segs); =20 skip_feature_flags: return 0; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 33E5F13F430; Sun, 24 Mar 2024 22:37:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319850; cv=none; b=j4ZQHL34Qs88lRcUQ4B3+bipZ/tsgWO2ZATOXscDPkrVf562BE3vVYP2qpbEZC7wiwTFTADt2HVNtS44U6yvqsGP1SLCaXQu0WN1Uu8FhE/IvELpM95o9tDd3KceIY4ajULmiQ6qlsy4FKxsh2Av/MUPv4ahL06BsIaXE++Ys9w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319850; c=relaxed/simple; bh=X8VLIvZrwN5fBir6rvd0OfOk45Gpo7bw7ybhXi54sp0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=RZwM5sq7nDeoirgb5x1mc2V3OAnvI9s4gmAAfk17V9TC0+rPvXxmTXoKhdt8LtqczMBPvOGkMpfFeshLma3syOUu7hMvVUZDGQpAw3XEMk/Pc1zN9aMW1NJhi6ye3e2hLP45skYAi006PAN3r5wWCpV0VPJg1gJJeexCCxoIEJY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KpRUscqM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KpRUscqM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B8A1C43390; Sun, 24 Mar 2024 22:37:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319850; bh=X8VLIvZrwN5fBir6rvd0OfOk45Gpo7bw7ybhXi54sp0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KpRUscqM9yPHyXV2IS4yN3/sFlDaJDuAfech7Ua9z1aQlBZ9pi7WTdW+UFbJtpf+N tIMfPQYKxbwxmWo2UNS/Dng17hNOn46oOjSwzPzoR+ZauhQZVRDYt8cxYa2+nUyw4X 3Ezc9ngDVOX3mfSBSKHYpfOiFFhtBSgsgpt43neZQA8HIM5aN5tDHgY6sGzUUl8Chw Bpk6l6hi0LpWLXkSM7PnQp2++nn9M7Brt55m4nRaaelFB29IYCpb0hmCKZZ0IoUVjY w3x/iPbgS0rEtB/n9jNLC2crc/TE+Dp5VBbPEmrJiEAJfK8QImkuWT/lHWIMPLgX+W MMb1ZANEKa/Hw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?J=C3=A9r=C3=B4me=20Pouiller?= , Ulrich Mohr , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 153/715] wifi: wfx: fix memory leak when starting AP Date: Sun, 24 Mar 2024 18:25:32 -0400 Message-ID: <20240324223455.1342824-154-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: J=C3=A9r=C3=B4me Pouiller [ Upstream commit b8cfb7c819dd39965136a66fe3a7fde688d976fc ] Kmemleak reported this error: unreferenced object 0xd73d1180 (size 184): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................ backtrace: [<5ca11420>] kmem_cache_alloc+0x20c/0x5ac [<127bdd74>] __alloc_skb+0x144/0x170 [] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] ___sys_sendmsg+0x80/0xb4 [<69954f45>] __sys_sendmsg+0x64/0xa8 unreferenced object 0xce087000 (size 1024): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<9a993714>] __kmalloc_track_caller+0x230/0x600 [] kmalloc_reserve.constprop.0+0x30/0x74 [] __alloc_skb+0xa0/0x170 [] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] ___sys_sendmsg+0x80/0xb4 However, since the kernel is build optimized, it seems the stack is not accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue is obvious in this function: memory allocated by ieee80211_beacon_get() is never released. Fixing this leak makes kmemleak happy. Reported-by: Ulrich Mohr Co-developed-by: Ulrich Mohr Signed-off-by: Ulrich Mohr Fixes: 268bceec1684 ("staging: wfx: fix BA when device is AP and MFP is ena= bled") Signed-off-by: J=C3=A9r=C3=B4me Pouiller Signed-off-by: Kalle Valo Link: https://msgid.link/20240202164213.1606145-1-jerome.pouiller@silabs.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/silabs/wfx/sta.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/silabs/wfx/sta.c b/drivers/net/wireless/s= ilabs/wfx/sta.c index 537caf9d914a7..bb4446b88c12b 100644 --- a/drivers/net/wireless/silabs/wfx/sta.c +++ b/drivers/net/wireless/silabs/wfx/sta.c @@ -344,6 +344,7 @@ static int wfx_set_mfp_ap(struct wfx_vif *wvif) const int pairwise_cipher_suite_count_offset =3D 8 / sizeof(u16); const int pairwise_cipher_suite_size =3D 4 / sizeof(u16); const int akm_suite_size =3D 4 / sizeof(u16); + int ret =3D -EINVAL; const u16 *ptr; =20 if (unlikely(!skb)) @@ -352,22 +353,26 @@ static int wfx_set_mfp_ap(struct wfx_vif *wvif) ptr =3D (u16 *)cfg80211_find_ie(WLAN_EID_RSN, skb->data + ieoffset, skb->len - ieoffset); if (unlikely(!ptr)) - return -EINVAL; + goto free_skb; =20 ptr +=3D pairwise_cipher_suite_count_offset; if (WARN_ON(ptr > (u16 *)skb_tail_pointer(skb))) - return -EINVAL; + goto free_skb; =20 ptr +=3D 1 + pairwise_cipher_suite_size * *ptr; if (WARN_ON(ptr > (u16 *)skb_tail_pointer(skb))) - return -EINVAL; + goto free_skb; =20 ptr +=3D 1 + akm_suite_size * *ptr; if (WARN_ON(ptr > (u16 *)skb_tail_pointer(skb))) - return -EINVAL; + goto free_skb; =20 wfx_hif_set_mfp(wvif, *ptr & BIT(7), *ptr & BIT(6)); - return 0; + ret =3D 0; + +free_skb: + dev_kfree_skb(skb); + return ret; } =20 int wfx_start_ap(struct ieee80211_hw *hw, struct ieee80211_vif *vif, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9CCB013F456; Sun, 24 Mar 2024 22:37:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319851; cv=none; b=e4Er+JFIrHUBuMASo5W/gXu75DdmMGAdSWohjWoo0cIWgUkNtpG2Zfriv+m8RzZd9mupqvUPZPFpK8Krq/KwIidi5GJwm/ryLU8bNnG45u0X8HFCPgBjMIGK7hsu+ye005DbvJj22fuOMHNzZWfmBt1knx/41T8fDVGjODTao/s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319851; c=relaxed/simple; bh=cNdB/pqQYyF0iJeryPbJ9ObnQ7YMg6C50WwnaW6HwYk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BQA+dlIqAEl2QmXw4v9MKwlPvWUQHHuJB794/zcoTIr1n1R1uyr1KIdrLZo3PfLpM3bJdVeUtpFkRX7IDiK/FkLXvmFqMa56ksIPQtIBWBaPPb/ocDLzES4CIgBjEI9qriGJCliaPSH0UG9M3Aqu15E2mcv1vJ1VModby9xMg00= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sGHvmtDC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sGHvmtDC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54FBFC43399; Sun, 24 Mar 2024 22:37:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319851; bh=cNdB/pqQYyF0iJeryPbJ9ObnQ7YMg6C50WwnaW6HwYk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sGHvmtDC4Olu4JUVfkg5SpxFpRPTYQ5gKrolcoXnpbaOYyNJXlCCr7vS6s/dr6VK0 6dPIb6sy4qg1FsWR5qKUdCQCPrOEK5yb4JhS8OWXMlPPacVG+3wqUQYn7N7+5Kr7F3 kFYFF8cVGjaA7v0FzCyn3Z29Q15Y/MvQ3WPQi7LwMnDAEc3VVHL3ASNKQ0Sn+rtUmM SlUA3lXPLzBIjdc9V5o4/xo/4ZZQpnTXFCqfpfjzFi+3eDEX5tD/19ya4VFgiQEI3y oCM7pO/97O8rk+AOTEcN8t4pIDaKC76UBVLUjdUleHLWw4BvJQ3R8Ub9N38OHkhsyM ponNdfoeDSQAA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dmitry Baryshkov , Jeffrey Hugo , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 154/715] arm64: dts: qcom: msm8998: declare VLS CLAMP register for USB3 PHY Date: Sun, 24 Mar 2024 18:25:33 -0400 Message-ID: <20240324223455.1342824-155-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dmitry Baryshkov [ Upstream commit fc835b2311d4deb85d776c1d73562338462aa7ac ] The USB3 PHY on the MSM8998 platform doesn't have built-in PCS_MISC_CLAMP_ENABLE register. Instead clamping is handled separately via the register in the TCSR space. Declare corresponding register. Fixes: 026dad8f5873 ("arm64: dts: qcom: msm8998: Add USB-related nodes") Cc: Jeffrey Hugo Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Reviewed-by: Jeffrey Hugo Link: https://lore.kernel.org/r/20240117-usbc-phy-vls-clamp-v2-4-a950c223f1= 0f@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/msm8998.dtsi | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qc= om/msm8998.dtsi index 2793cc22d381a..317a91d669f82 100644 --- a/arch/arm64/boot/dts/qcom/msm8998.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi @@ -1072,6 +1072,11 @@ tcsr_regs_1: syscon@1f60000 { reg =3D <0x01f60000 0x20000>; }; =20 + tcsr_regs_2: syscon@1fc0000 { + compatible =3D "qcom,msm8998-tcsr", "syscon"; + reg =3D <0x01fc0000 0x26000>; + }; + tlmm: pinctrl@3400000 { compatible =3D "qcom,msm8998-pinctrl"; reg =3D <0x03400000 0xc00000>; @@ -2174,6 +2179,8 @@ usb3phy: phy@c010000 { reset-names =3D "phy", "phy_phy"; =20 + qcom,tcsr-reg =3D <&tcsr_regs_2 0xb244>; + status =3D "disabled"; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 83F4C482EE; Sun, 24 Mar 2024 22:37:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319852; cv=none; b=bNfx8G3GuOLNPjxLSUaMC7JT1n5Cb3It5qn0RPMiQa1Y6HvIGhGMiCqL/l46dOhCC9rNmt+uXe1UjNwudiZzrmX08B1DmFYCS4OFBXZ4cNMzIN5i6zxNbPfl2ay0/nknsB1I+cdw2SvcCn6Vi+drRQkLu6PCDwjM5rMs/Iz9njc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319852; c=relaxed/simple; bh=E2EDG6e7E1HOrhGCm5ge/wOxqVvEJkTrwXvXG19O9sE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gUh+SXpMdkTYXWZhGyXg/k4kYtuPdFFBz5SQBR/6JOSimiOg5+9fLic048EhdLm1/zSFuUBx97V7r5dW9W6E/b/2LuXk495/gLPbh1r5BU9bC44Z138H4H43Sc4htbrfOC+c8cXH1i/IiirT57QWOaDKn1RFx4Iddm7EcD9Hiyo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e0ISpO2X; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="e0ISpO2X" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 69225C433C7; Sun, 24 Mar 2024 22:37:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319852; bh=E2EDG6e7E1HOrhGCm5ge/wOxqVvEJkTrwXvXG19O9sE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=e0ISpO2Xq03ZxKKGyR2wyFi4NVu6/a4WAGBdRMs9OB37HSoaR86qVV+9ovVXrn2WO x4W1nwDftULrjYnPD09OVixJqO/0n3k2tH2/zhhL+JJ876Crza+hKJ6TgHdBgo7u7F K60G8Rf9JoTlPYG6URPod/lekcJ1c7IsVWCOmhSpZpBRRCSWTjJ61AOA3YigPCBqwH 39R7sagSE3qQaSBTFxQewITgTirTiDGb4ftJCaYBBWvHfg+UNotCFSEE0igY4QPa0Q +iRwXbSfJ5TIUHpcLVJ3wMUzy6NwmutanrMgRuSfa2K/G/R+3wRr1wvspzlAPH2prg XLC3QluVUtLSg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 155/715] arm64: dts: qcom: qcm2290: declare VLS CLAMP register for USB3 PHY Date: Sun, 24 Mar 2024 18:25:34 -0400 Message-ID: <20240324223455.1342824-156-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dmitry Baryshkov [ Upstream commit acb94d67f5a23dbb2e0021b6c30609ed05d7d6a5 ] The USB3 PHY on the QCM2290 platform doesn't have built-in PCS_MISC_CLAMP_ENABLE register. Instead clamping is handled separately via the register in the TCSR space. Declare corresponding register. Fixes: 0c55f6229bc3 ("arm64: dts: qcom: qcm2290: Add USB3 PHY") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240117-usbc-phy-vls-clamp-v2-5-a950c223f1= 0f@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/qcm2290.dtsi | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/qcm2290.dtsi b/arch/arm64/boot/dts/qc= om/qcm2290.dtsi index 0911fb08ed632..89beac833d435 100644 --- a/arch/arm64/boot/dts/qcom/qcm2290.dtsi +++ b/arch/arm64/boot/dts/qcom/qcm2290.dtsi @@ -442,6 +442,11 @@ tcsr_mutex: hwlock@340000 { #hwlock-cells =3D <1>; }; =20 + tcsr_regs: syscon@3c0000 { + compatible =3D "qcom,qcm2290-tcsr", "syscon"; + reg =3D <0x0 0x003c0000 0x0 0x40000>; + }; + tlmm: pinctrl@500000 { compatible =3D "qcom,qcm2290-tlmm"; reg =3D <0x0 0x00500000 0x0 0x300000>; @@ -690,6 +695,8 @@ usb_qmpphy: phy@1615000 { =20 #phy-cells =3D <0>; =20 + qcom,tcsr-reg =3D <&tcsr_regs 0xb244>; + status =3D "disabled"; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3B90D14038E; Sun, 24 Mar 2024 22:37:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319853; cv=none; b=oQYG0ufl1VI1td758zJ0CQSbJmVzoRS2WQZOvP2HaYPXB162DTutl7Jl5DQU0HEHqST/H7Iv3gLkQtRCGfVetcwFOfW5AB03FNPxEC6QCCATNceTJbFWC0fSEu7uozLAu3335VWSC/rJ+10acryGU97lZZuwvueCdXlPYVZTbzM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319853; c=relaxed/simple; bh=NRCKEtw5FEZEB1cAvNhMBod8zjMtinZJoPRlHF708sg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NamHCsZKGWEsTD1rBBZHAHtoxIakdC+HIo7qqjSOeHws98mGP+wrzdjM7KNtPWip6TH29KOkIrAwFRlL5NRymGlSl2ovRv/AEJcd4RXNl0u4701EwwYAgMV6Yh7hI6LerOu6PQxGT6W5PqIM/okHC2UhZVno0mRfObr6a2nPnl4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AsXU1zkO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AsXU1zkO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66A9CC43390; Sun, 24 Mar 2024 22:37:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319853; bh=NRCKEtw5FEZEB1cAvNhMBod8zjMtinZJoPRlHF708sg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AsXU1zkOiZqtdwEoQFc+aLCyjljuWSE9+pMWBKc++GpYWlHLY/wTSe8tQCkZdtGhZ yZEql1H2ie2uvLDaMo0DM00m7iVdb2J//FUbDQKh6UvzzgV7E9WCqJsJ6e7agI0mGm eDSre5zuPPU/6mQXKLLlfJtZkrMvd8/AOpPbVyBQY07Hg217oLZ7evEK53n12avxUh pE0v/Ph4M7WDo9FXJ6VxF/JaOphaag5nPeN3mi+owlNsrrkjU9IRYIEwIS2AHQj3VP 8obHNG94oZHKnTigR4H72NTJUUvjfLOyvb0AzI7CApra2Fx8krGmWb/GLOuOFM6B9n tKGIQ0cFXlCQA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Dmitry Baryshkov , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 156/715] arm64: dts: qcom: sm6115: declare VLS CLAMP register for USB3 PHY Date: Sun, 24 Mar 2024 18:25:35 -0400 Message-ID: <20240324223455.1342824-157-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Dmitry Baryshkov [ Upstream commit 95d739ed962c9aaa17d77b739606dbdf31879f6e ] The USB3 PHY on the SM6115 platform doesn't have built-in PCS_MISC_CLAMP_ENABLE register. Instead clamping is handled separately via the register in the TCSR space. Declare corresponding register. Fixes: 9dd5f6dba729 ("arm64: dts: qcom: sm6115: Add USB SS qmp phy node") Signed-off-by: Dmitry Baryshkov Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240117-usbc-phy-vls-clamp-v2-6-a950c223f1= 0f@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sm6115.dtsi | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qco= m/sm6115.dtsi index f9849b8befbf2..b627c473ffa54 100644 --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi @@ -614,6 +614,11 @@ tcsr_mutex: hwlock@340000 { #hwlock-cells =3D <1>; }; =20 + tcsr_regs: syscon@3c0000 { + compatible =3D "qcom,sm6115-tcsr", "syscon"; + reg =3D <0x0 0x003c0000 0x0 0x40000>; + }; + tlmm: pinctrl@500000 { compatible =3D "qcom,sm6115-tlmm"; reg =3D <0x0 0x00500000 0x0 0x400000>, @@ -879,6 +884,8 @@ usb_qmpphy: phy@1615000 { =20 #phy-cells =3D <0>; =20 + qcom,tcsr-reg =3D <&tcsr_regs 0xb244>; + status =3D "disabled"; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 46EAC140E58; Sun, 24 Mar 2024 22:37:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319854; cv=none; b=GZ3qKwcFIGpZFCJT3jXxXp6bKGfQ/kjiZ2NU7bRJykmavskA8WOZS+3BuQVstf+DwRUoT4tgEj8hY+27Xj/9k9KhFxTAmvn1xfiSSZU5GWLcL2055d8Lt6HuqWhWoUgccksKzeKaY+kX1Wybd7UyFLST9lWxo5vUxU4DezChX+A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319854; c=relaxed/simple; bh=3dyTJT4nnoaVRgAZyeo0M/RmlnJNy3l+FyeWtIk1zoM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=auw24PSA4XITlpnsjlWf2lDmAIiyzAhkfoTs1QmpakLuLqyQVSNddilN/IAEVlulCWLaZnKxnww2A5fqNu/zr/cNYfwht/fwEQ/qve8FLvgyGgFhzSfqAYXedRfD0s4EBgNRS6DNFnEsbJVy8Id6pDlIcJrquRMIKAlpncPCif4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K3jHMzxh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K3jHMzxh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5DBF2C43399; Sun, 24 Mar 2024 22:37:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319854; bh=3dyTJT4nnoaVRgAZyeo0M/RmlnJNy3l+FyeWtIk1zoM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K3jHMzxh6q6/wP4x9N+XEr1ux1ke74uhS7Wo35hAQuE81gP0VRXALwHDEeVU50Ggp OaLrsYrtiWecb/2aqN2IArnOy5b40R2BCU8bHUHNgcXQFliqVK9OxEnNIrP9vuFwQP Ly40pD5FaV7TVUYumdsb6FbiFTw/vwgpx71W7Xorxc9X48ygKp5pPMA3JovYA/B5cE wGCEbt+IRW9XFxiWQIMFUlpCoA8R8qCZXQiH6RT110ZsmXhIIjo6heo5pfb0VCb4Mk ug5G1LoxPFLR5XFnGCyzUfbm3lQO1Olt5RxWq/XCf4v0R/1LIF6wwma6yeT6WUMVJr ut6b+lmwO1qjA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Manivannan Sadhasivam , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 157/715] arm64: dts: qcom: sm8650: Fix UFS PHY clocks Date: Sun, 24 Mar 2024 18:25:36 -0400 Message-ID: <20240324223455.1342824-158-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Manivannan Sadhasivam [ Upstream commit 0f9b8054bb4abd7b4686cc66b85f71fec9160136 ] QMP PHY used in SM8650 requires 3 clocks: * ref - 19.2MHz reference clock from RPMh * ref_aux - Auxiliary reference clock from GCC * qref - QREF clock from TCSR Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent = device nodes") Signed-off-by: Manivannan Sadhasivam Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240131-ufs-phy-clock-v3-17-58a49d2f4605@l= inaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sm8650.dtsi | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qco= m/sm8650.dtsi index 2df77123a8c7b..bad0eb84549fe 100644 --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi @@ -2448,10 +2448,12 @@ ufs_mem_phy: phy@1d80000 { compatible =3D "qcom,sm8650-qmp-ufs-phy"; reg =3D <0 0x01d80000 0 0x2000>; =20 - clocks =3D <&tcsr TCSR_UFS_CLKREF_EN>, - <&gcc GCC_UFS_PHY_PHY_AUX_CLK>; + clocks =3D <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_UFS_PHY_PHY_AUX_CLK>, + <&tcsr TCSR_UFS_CLKREF_EN>; clock-names =3D "ref", - "ref_aux"; + "ref_aux", + "qref"; =20 resets =3D <&ufs_mem_hc 0>; reset-names =3D "ufsphy"; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2FB3E524DC; Sun, 24 Mar 2024 22:37:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319855; cv=none; b=jsqTp/gWa6yk/ydjPvB47UMZHzOyyAtGu72A0kLa9MTO0WWviuvFeeDL7BemcbTrQoALZ8iqfg9tk3MXxuR1p+u3HHAIu0P6pxpYOSjEyY47dIb8nW3u8PtD53TcMK569khxv6jd6gbQhEKgISeiDQSF+VqQ9QtZlE9VzBUemj4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319855; c=relaxed/simple; bh=bm0nHDz5om7WHLyihz32vRBvx8OpXaA6YLsgeYe1SWI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sFNhR25EXgvplKITzl8KYZH4CH+0TpviXCtPiUAtm+09YTDEO4uKg+gqDmsIMKIHOgl/cnzk38FUltZ8zYGMSvV0NsY0Vr6M6ZltmK+e2tbw40aP5RtPS0fWfVMt+ZV6loV0FOB59xGP8Gu1fc29s54KyOc9CDXjmYmqPAzUF9w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OiRBAtin; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OiRBAtin" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5850FC433F1; Sun, 24 Mar 2024 22:37:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319855; bh=bm0nHDz5om7WHLyihz32vRBvx8OpXaA6YLsgeYe1SWI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OiRBAtinypgsGzN5wca30VlofG/R/wJKJFTzaWflYm4Q26ChWM4JgcklHs5RHBqYG Yw7nEK87RdSpAJlIa4S0eE0et2EqQ4Batvo7ulYY/RK9UqRp2kZVqpkPZyN6IEAt1v wI2a3rZ+rwDaOxZgE3EZEh+PjVjAvSdv6Vc5hF4hVAOCTrUA7uaVGgLusvCrtKuwt4 jROiQxJInTAEzSohc0YDJXPN+fgu6Mxnlusv9/RUX4d7w6B/GRSzkJh2KbscDcHP8I 4NEOouYEkmbZvlETsyLOlQybQSnhCOtR3jGfek7tTo7kwW3Uv8FOS5FNcUJ4eicHTw wObajVDRmWwaw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kang Yang , Jeff Johnson , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 158/715] wifi: ath12k: fix incorrect logic of calculating vdev_stats_id Date: Sun, 24 Mar 2024 18:25:37 -0400 Message-ID: <20240324223455.1342824-159-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kang Yang [ Upstream commit 019b58dcb6ed267e17b7efd03ec8575c1b67d942 ] During calculate vdev_stats_id, will compare vdev_stats_id with ATH12K_INVAL_VDEV_STATS_ID by '<=3D'. If vdev_stats_id is relatively small, then assign ATH12K_INVAL_VDEV_STATS_ID to vdev_stats_id. This logic is incorrect. Firstly, should use '>=3D' instead of '<=3D' to check if this u8 variable exceeds the max valid range. Secondly, should use the maximum value as comparison value. Correct comparison symbols and use the maximum value ATH12K_MAX_VDEV_STATS_ID for comparison. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SIL= ICONZ-3 Fixes: d889913205cf ("wifi: ath12k: driver for Qualcomm Wi-Fi 7 devices") Signed-off-by: Kang Yang Acked-by: Jeff Johnson Signed-off-by: Kalle Valo Link: https://msgid.link/20240130040303.370590-3-quic_kangyang@quicinc.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/ath/ath12k/mac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/a= th/ath12k/mac.c index f4e5dc363472b..b965fc46ad89a 100644 --- a/drivers/net/wireless/ath/ath12k/mac.c +++ b/drivers/net/wireless/ath/ath12k/mac.c @@ -5269,7 +5269,7 @@ ath12k_mac_get_vdev_stats_id(struct ath12k_vif *arvif) do { if (ab->free_vdev_stats_id_map & (1LL << vdev_stats_id)) { vdev_stats_id++; - if (vdev_stats_id <=3D ATH12K_INVAL_VDEV_STATS_ID) { + if (vdev_stats_id >=3D ATH12K_MAX_VDEV_STATS_ID) { vdev_stats_id =3D ATH12K_INVAL_VDEV_STATS_ID; break; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1B7B352F68; Sun, 24 Mar 2024 22:37:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319856; cv=none; b=lfXKdt7333IbE4Wp2n+g8ALdGHu9bRntvjy1cVSZm21ghgYjc8t8aC+6B+YD4Unm58hvwNnsySwi34QicdQ243td0nOTUAm2P+9hBtXJOL0xWh9R6pEH6iZ9yPMMIZPPf5bqj/bKVaCbBD+sjdFUcPZU2xMo/wE6Uo/EwfdWxL0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319856; c=relaxed/simple; bh=JOG+YyezGeMBbIJgXZ49Ud5Nd6CLwHeZEpDp+srOCHU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pbe2W0DyQLg7Cwy+ibxwrpA2Nstykm2mxj3pJljh9aHm+bkkqrICYk71wJppA/vp6gprCXTt3q+CpV+Z59GvAakkvtkYnp2qeHzhLfYRQsjaZ4BHS53wmv9GaIZiRs/H4igDAkK16NzqugINYFsuHyXj1iBJ6vmWL1w7QTqAqvc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=a6iGaK1l; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="a6iGaK1l" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 520CBC43390; Sun, 24 Mar 2024 22:37:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319855; bh=JOG+YyezGeMBbIJgXZ49Ud5Nd6CLwHeZEpDp+srOCHU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=a6iGaK1lY0NAYjEnKTbAu9+/jJDbfNkFAW6o1y1mt/I9SUy/Pyz87DlGQ+s+6kVZr ElxNxBrDeNkiNMN3j50DjDO8WrsyOi4kYX3QuCKAfNAxdedIERCDA2lvAvDDJDJbOm 2QKwzzecxAla6PrSvTti7LXYUwY6S3usQPUOpb/Mq0RMIZHtVTH05IMzjsIpH6pa4F ZzMEdX2bOvxZp+/xnmomcxmcZAJloZmZKNhoVYVZSXDnkf87aohsldVbQS9yeWA1JE uOPMnSsbl3huiJAegvLEe5bM1DO7as/e71OcADJuG14Iy5mIqFbmrHDS5HTpmjS1ff wodHL8ZsUJ5rQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: John Ogness , Petr Mladek , Sasha Levin Subject: [PATCH 6.8 159/715] printk: nbcon: Relocate 32bit seq macros Date: Sun, 24 Mar 2024 18:25:38 -0400 Message-ID: <20240324223455.1342824-160-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: John Ogness [ Upstream commit 5b73e706f00f3553e1a4efbb31951ce9fe18f2dc ] The macros __seq_to_nbcon_seq() and __nbcon_seq_to_seq() are used to provide support for atomic handling of sequence numbers on 32bit systems. Until now this was only used by nbcon.c, which is why they were located in nbcon.c and include nbcon in the name. In a follow-up commit this functionality is also needed by printk_ringbuffer. Rather than duplicating the functionality, relocate the macros to printk_ringbuffer.h. Also, since the macros will be no longer nbcon-specific, rename them to __u64seq_to_ulseq() and __ulseq_to_u64seq(). This does not result in any functional change. Signed-off-by: John Ogness Reviewed-by: Petr Mladek Link: https://lore.kernel.org/r/20240207134103.1357162-2-john.ogness@linutr= onix.de Signed-off-by: Petr Mladek Stable-dep-of: 5f72e52ba959 ("printk: ringbuffer: Do not skip non-finalized= records with prb_next_seq()") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/printk/nbcon.c | 41 +++---------------------------- kernel/printk/printk_ringbuffer.h | 33 +++++++++++++++++++++++++ 2 files changed, 37 insertions(+), 37 deletions(-) diff --git a/kernel/printk/nbcon.c b/kernel/printk/nbcon.c index b96077152f49d..c8093bcc01fe6 100644 --- a/kernel/printk/nbcon.c +++ b/kernel/printk/nbcon.c @@ -140,39 +140,6 @@ static inline bool nbcon_state_try_cmpxchg(struct cons= ole *con, struct nbcon_sta return atomic_try_cmpxchg(&ACCESS_PRIVATE(con, nbcon_state), &cur->atom, = new->atom); } =20 -#ifdef CONFIG_64BIT - -#define __seq_to_nbcon_seq(seq) (seq) -#define __nbcon_seq_to_seq(seq) (seq) - -#else /* CONFIG_64BIT */ - -#define __seq_to_nbcon_seq(seq) ((u32)seq) - -static inline u64 __nbcon_seq_to_seq(u32 nbcon_seq) -{ - u64 seq; - u64 rb_next_seq; - - /* - * The provided sequence is only the lower 32 bits of the ringbuffer - * sequence. It needs to be expanded to 64bit. Get the next sequence - * number from the ringbuffer and fold it. - * - * Having a 32bit representation in the console is sufficient. - * If a console ever gets more than 2^31 records behind - * the ringbuffer then this is the least of the problems. - * - * Also the access to the ring buffer is always safe. - */ - rb_next_seq =3D prb_next_seq(prb); - seq =3D rb_next_seq - ((u32)rb_next_seq - nbcon_seq); - - return seq; -} - -#endif /* CONFIG_64BIT */ - /** * nbcon_seq_read - Read the current console sequence * @con: Console to read the sequence of @@ -183,7 +150,7 @@ u64 nbcon_seq_read(struct console *con) { unsigned long nbcon_seq =3D atomic_long_read(&ACCESS_PRIVATE(con, nbcon_s= eq)); =20 - return __nbcon_seq_to_seq(nbcon_seq); + return __ulseq_to_u64seq(prb, nbcon_seq); } =20 /** @@ -204,7 +171,7 @@ void nbcon_seq_force(struct console *con, u64 seq) */ u64 valid_seq =3D max_t(u64, seq, prb_first_valid_seq(prb)); =20 - atomic_long_set(&ACCESS_PRIVATE(con, nbcon_seq), __seq_to_nbcon_seq(valid= _seq)); + atomic_long_set(&ACCESS_PRIVATE(con, nbcon_seq), __u64seq_to_ulseq(valid_= seq)); =20 /* Clear con->seq since nbcon consoles use con->nbcon_seq instead. */ con->seq =3D 0; @@ -223,11 +190,11 @@ void nbcon_seq_force(struct console *con, u64 seq) */ static void nbcon_seq_try_update(struct nbcon_context *ctxt, u64 new_seq) { - unsigned long nbcon_seq =3D __seq_to_nbcon_seq(ctxt->seq); + unsigned long nbcon_seq =3D __u64seq_to_ulseq(ctxt->seq); struct console *con =3D ctxt->console; =20 if (atomic_long_try_cmpxchg(&ACCESS_PRIVATE(con, nbcon_seq), &nbcon_seq, - __seq_to_nbcon_seq(new_seq))) { + __u64seq_to_ulseq(new_seq))) { ctxt->seq =3D new_seq; } else { ctxt->seq =3D nbcon_seq_read(con); diff --git a/kernel/printk/printk_ringbuffer.h b/kernel/printk/printk_ringb= uffer.h index 18cd25e489b89..b82a96dc2ea2b 100644 --- a/kernel/printk/printk_ringbuffer.h +++ b/kernel/printk/printk_ringbuffer.h @@ -381,4 +381,37 @@ bool prb_read_valid_info(struct printk_ringbuffer *rb,= u64 seq, u64 prb_first_valid_seq(struct printk_ringbuffer *rb); u64 prb_next_seq(struct printk_ringbuffer *rb); =20 +#ifdef CONFIG_64BIT + +#define __u64seq_to_ulseq(u64seq) (u64seq) +#define __ulseq_to_u64seq(rb, ulseq) (ulseq) + +#else /* CONFIG_64BIT */ + +#define __u64seq_to_ulseq(u64seq) ((u32)u64seq) + +static inline u64 __ulseq_to_u64seq(struct printk_ringbuffer *rb, u32 ulse= q) +{ + u64 seq; + u64 rb_next_seq; + + /* + * The provided sequence is only the lower 32 bits of the ringbuffer + * sequence. It needs to be expanded to 64bit. Get the next sequence + * number from the ringbuffer and fold it. + * + * Having a 32bit representation in the console is sufficient. + * If a console ever gets more than 2^31 records behind + * the ringbuffer then this is the least of the problems. + * + * Also the access to the ring buffer is always safe. + */ + rb_next_seq =3D prb_next_seq(rb); + seq =3D rb_next_seq - ((u32)rb_next_seq - ulseq); + + return seq; +} + +#endif /* CONFIG_64BIT */ + #endif /* _KERNEL_PRINTK_RINGBUFFER_H */ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EBE9D52F8A; Sun, 24 Mar 2024 22:37:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319857; cv=none; b=jyJTTPxwF3NQYL2ck1nFxHbfFt3JEfsaegHAFr+bXiJivAv+8rxQEGrBk4FRouBnsITBzCvhAFrMadQqjiRz/ybXwwDRLLQZ1+grGypGSFvp+LvxGVgf0k75NqIy+912VcA7BOWhuUfj08TRfjeJul8wJysclBNecbauVjh5POU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319857; c=relaxed/simple; bh=8DZF5T2Zt/1RDnSa62/ypRFyPp+OyJ7ZkonbZFS7G8Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Kcc6DzG51xHeu2Ey/kLh9hbk77xv7LDsjDU8evGwiz2T2wwnLhHpx/tW4rZIaFKgy3tH0aRA2Rtjn3T0o/adGzMF6tNhayHdxdrG4UjIWLrkyvgqQOLt1bIKB1IT008jEVQqCAE2O91JWiBRFJcPlKngHpAkoWxzmrSa3aZ2PJw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LQiIjd/F; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LQiIjd/F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3340DC43394; Sun, 24 Mar 2024 22:37:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319856; bh=8DZF5T2Zt/1RDnSa62/ypRFyPp+OyJ7ZkonbZFS7G8Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LQiIjd/FrOiONwzf08U1gQJSHuZL41uGsKv4uVIsKId46tSriwG8j4pRy+le6n/qV psKoFEIICqQ4/jCBUWJ70lpApaQmMPrMIHY5bZts50R+k147kcilCKE13S0GFso69J 1HUV22Q8J/goXaInnymUgqjA3NMon8sQIfvgF/5lS7bnODHB0q/mpn73l1uF3raGRj nCyrSOFTezd+GhCrj8KZOfYeti2nl6yU6ILrtTtWeCxuj2VUR/580UXAmh+1d0fpLY FyHGd5HUmtXfVNxB7sJhoF9yPS2cu+/kTbaqghTYv/3GWE2QS2KHIHGp4eExRcgyJw p3Oe3UfktIrSQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: John Ogness , Petr Mladek , Sasha Levin Subject: [PATCH 6.8 160/715] printk: ringbuffer: Do not skip non-finalized records with prb_next_seq() Date: Sun, 24 Mar 2024 18:25:39 -0400 Message-ID: <20240324223455.1342824-161-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: John Ogness [ Upstream commit 5f72e52ba959e50680b8d83599da1368cd7a6ee2 ] Commit f244b4dc53e5 ("printk: ringbuffer: Improve prb_next_seq() performance") introduced an optimization for prb_next_seq() by using best-effort to track recently finalized records. However, the order of finalization does not necessarily match the order of the records. The optimization changed prb_next_seq() to return inconsistent results, possibly yielding sequence numbers that are not available to readers because they are preceded by non-finalized records or they are not yet visible to the reader CPU. Rather than simply best-effort tracking recently finalized records, force the committing writer to read records and increment the last "contiguous block" of finalized records. In order to do this, the sequence number instead of ID must be stored because ID's cannot be directly compared. A new memory barrier pair is introduced to guarantee that a reader can always read the records up until the sequence number returned by prb_next_seq() (unless the records have since been overwritten in the ringbuffer). This restores the original functionality of prb_next_seq() while also keeping the optimization. For 32bit systems, only the lower 32 bits of the sequence number are stored. When reading the value, it is expanded to the full 64bit sequence number using the 32bit seq macros, which fold in the value returned by prb_first_seq(). Fixes: f244b4dc53e5 ("printk: ringbuffer: Improve prb_next_seq() performanc= e") Signed-off-by: John Ogness Reviewed-by: Petr Mladek Link: https://lore.kernel.org/r/20240207134103.1357162-5-john.ogness@linutr= onix.de Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/printk/printk_ringbuffer.c | 164 +++++++++++++++++++++++------- kernel/printk/printk_ringbuffer.h | 4 +- 2 files changed, 127 insertions(+), 41 deletions(-) diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringb= uffer.c index fde338606ce83..4ce1826dc9426 100644 --- a/kernel/printk/printk_ringbuffer.c +++ b/kernel/printk/printk_ringbuffer.c @@ -6,6 +6,7 @@ #include #include #include "printk_ringbuffer.h" +#include "internal.h" =20 /** * DOC: printk_ringbuffer overview @@ -303,6 +304,9 @@ * * desc_push_tail:B / desc_reserve:D * set descriptor reusable (state), then push descriptor tail (id) + * + * desc_update_last_finalized:A / desc_last_finalized_seq:A + * store finalized record, then set new highest finalized sequence num= ber */ =20 #define DATA_SIZE(data_ring) _DATA_SIZE((data_ring)->size_bits) @@ -1441,20 +1445,118 @@ bool prb_reserve_in_last(struct prb_reserved_entry= *e, struct printk_ringbuffer return false; } =20 +/* + * @last_finalized_seq value guarantees that all records up to and includi= ng + * this sequence number are finalized and can be read. The only exception = are + * too old records which have already been overwritten. + * + * It is also guaranteed that @last_finalized_seq only increases. + * + * Be aware that finalized records following non-finalized records are not + * reported because they are not yet available to the reader. For example, + * a new record stored via printk() will not be available to a printer if + * it follows a record that has not been finalized yet. However, once that + * non-finalized record becomes finalized, @last_finalized_seq will be + * appropriately updated and the full set of finalized records will be + * available to the printer. And since each printk() caller will either + * directly print or trigger deferred printing of all available unprinted + * records, all printk() messages will get printed. + */ +static u64 desc_last_finalized_seq(struct printk_ringbuffer *rb) +{ + struct prb_desc_ring *desc_ring =3D &rb->desc_ring; + unsigned long ulseq; + + /* + * Guarantee the sequence number is loaded before loading the + * associated record in order to guarantee that the record can be + * seen by this CPU. This pairs with desc_update_last_finalized:A. + */ + ulseq =3D atomic_long_read_acquire(&desc_ring->last_finalized_seq + ); /* LMM(desc_last_finalized_seq:A) */ + + return __ulseq_to_u64seq(rb, ulseq); +} + +static bool _prb_read_valid(struct printk_ringbuffer *rb, u64 *seq, + struct printk_record *r, unsigned int *line_count); + +/* + * Check if there are records directly following @last_finalized_seq that = are + * finalized. If so, update @last_finalized_seq to the latest of these + * records. It is not allowed to skip over records that are not yet finali= zed. + */ +static void desc_update_last_finalized(struct printk_ringbuffer *rb) +{ + struct prb_desc_ring *desc_ring =3D &rb->desc_ring; + u64 old_seq =3D desc_last_finalized_seq(rb); + unsigned long oldval; + unsigned long newval; + u64 finalized_seq; + u64 try_seq; + +try_again: + finalized_seq =3D old_seq; + try_seq =3D finalized_seq + 1; + + /* Try to find later finalized records. */ + while (_prb_read_valid(rb, &try_seq, NULL, NULL)) { + finalized_seq =3D try_seq; + try_seq++; + } + + /* No update needed if no later finalized record was found. */ + if (finalized_seq =3D=3D old_seq) + return; + + oldval =3D __u64seq_to_ulseq(old_seq); + newval =3D __u64seq_to_ulseq(finalized_seq); + + /* + * Set the sequence number of a later finalized record that has been + * seen. + * + * Guarantee the record data is visible to other CPUs before storing + * its sequence number. This pairs with desc_last_finalized_seq:A. + * + * Memory barrier involvement: + * + * If desc_last_finalized_seq:A reads from + * desc_update_last_finalized:A, then desc_read:A reads from + * _prb_commit:B. + * + * Relies on: + * + * RELEASE from _prb_commit:B to desc_update_last_finalized:A + * matching + * ACQUIRE from desc_last_finalized_seq:A to desc_read:A + * + * Note: _prb_commit:B and desc_update_last_finalized:A can be + * different CPUs. However, the desc_update_last_finalized:A + * CPU (which performs the release) must have previously seen + * _prb_commit:B. + */ + if (!atomic_long_try_cmpxchg_release(&desc_ring->last_finalized_seq, + &oldval, newval)) { /* LMM(desc_update_last_finalized:A) */ + old_seq =3D __ulseq_to_u64seq(rb, oldval); + goto try_again; + } +} + /* * Attempt to finalize a specified descriptor. If this fails, the descript= or * is either already final or it will finalize itself when the writer comm= its. */ -static void desc_make_final(struct prb_desc_ring *desc_ring, unsigned long= id) +static void desc_make_final(struct printk_ringbuffer *rb, unsigned long id) { + struct prb_desc_ring *desc_ring =3D &rb->desc_ring; unsigned long prev_state_val =3D DESC_SV(id, desc_committed); struct prb_desc *d =3D to_desc(desc_ring, id); =20 - atomic_long_cmpxchg_relaxed(&d->state_var, prev_state_val, - DESC_SV(id, desc_finalized)); /* LMM(desc_make_final:A) */ - - /* Best effort to remember the last finalized @id. */ - atomic_long_set(&desc_ring->last_finalized_id, id); + if (atomic_long_try_cmpxchg_relaxed(&d->state_var, &prev_state_val, + DESC_SV(id, desc_finalized))) { /* LMM(desc_make_final:A) */ + desc_update_last_finalized(rb); + } } =20 /** @@ -1550,7 +1652,7 @@ bool prb_reserve(struct prb_reserved_entry *e, struct= printk_ringbuffer *rb, * readers. (For seq=3D=3D0 there is no previous descriptor.) */ if (info->seq > 0) - desc_make_final(desc_ring, DESC_ID(id - 1)); + desc_make_final(rb, DESC_ID(id - 1)); =20 r->text_buf =3D data_alloc(rb, r->text_buf_size, &d->text_blk_lpos, id); /* If text data allocation fails, a data-less record is committed. */ @@ -1643,7 +1745,7 @@ void prb_commit(struct prb_reserved_entry *e) */ head_id =3D atomic_long_read(&desc_ring->head_id); /* LMM(prb_commit:A) */ if (head_id !=3D e->id) - desc_make_final(desc_ring, e->id); + desc_make_final(e->rb, e->id); } =20 /** @@ -1663,12 +1765,9 @@ void prb_commit(struct prb_reserved_entry *e) */ void prb_final_commit(struct prb_reserved_entry *e) { - struct prb_desc_ring *desc_ring =3D &e->rb->desc_ring; - _prb_commit(e, desc_finalized); =20 - /* Best effort to remember the last finalized @id. */ - atomic_long_set(&desc_ring->last_finalized_id, e->id); + desc_update_last_finalized(e->rb); } =20 /* @@ -2008,7 +2107,9 @@ u64 prb_first_valid_seq(struct printk_ringbuffer *rb) * newest sequence number available to readers will be. * * This provides readers a sequence number to jump to if all currently - * available records should be skipped. + * available records should be skipped. It is guaranteed that all records + * previous to the returned value have been finalized and are (or were) + * available to the reader. * * Context: Any context. * Return: The sequence number of the next newest (not yet available) reco= rd @@ -2016,34 +2117,19 @@ u64 prb_first_valid_seq(struct printk_ringbuffer *r= b) */ u64 prb_next_seq(struct printk_ringbuffer *rb) { - struct prb_desc_ring *desc_ring =3D &rb->desc_ring; - enum desc_state d_state; - unsigned long id; u64 seq; =20 - /* Check if the cached @id still points to a valid @seq. */ - id =3D atomic_long_read(&desc_ring->last_finalized_id); - d_state =3D desc_read(desc_ring, id, NULL, &seq, NULL); + seq =3D desc_last_finalized_seq(rb); =20 - if (d_state =3D=3D desc_finalized || d_state =3D=3D desc_reusable) { - /* - * Begin searching after the last finalized record. - * - * On 0, the search must begin at 0 because of hack#2 - * of the bootstrapping phase it is not known if a - * record at index 0 exists. - */ - if (seq !=3D 0) - seq++; - } else { - /* - * The information about the last finalized sequence number - * has gone. It should happen only when there is a flood of - * new messages and the ringbuffer is rapidly recycled. - * Give up and start from the beginning. - */ - seq =3D 0; - } + /* + * Begin searching after the last finalized record. + * + * On 0, the search must begin at 0 because of hack#2 + * of the bootstrapping phase it is not known if a + * record at index 0 exists. + */ + if (seq !=3D 0) + seq++; =20 /* * The information about the last finalized @seq might be inaccurate. @@ -2085,7 +2171,7 @@ void prb_init(struct printk_ringbuffer *rb, rb->desc_ring.infos =3D infos; atomic_long_set(&rb->desc_ring.head_id, DESC0_ID(descbits)); atomic_long_set(&rb->desc_ring.tail_id, DESC0_ID(descbits)); - atomic_long_set(&rb->desc_ring.last_finalized_id, DESC0_ID(descbits)); + atomic_long_set(&rb->desc_ring.last_finalized_seq, 0); =20 rb->text_data_ring.size_bits =3D textbits; rb->text_data_ring.data =3D text_buf; diff --git a/kernel/printk/printk_ringbuffer.h b/kernel/printk/printk_ringb= uffer.h index b82a96dc2ea2b..70457916d577d 100644 --- a/kernel/printk/printk_ringbuffer.h +++ b/kernel/printk/printk_ringbuffer.h @@ -75,7 +75,7 @@ struct prb_desc_ring { struct printk_info *infos; atomic_long_t head_id; atomic_long_t tail_id; - atomic_long_t last_finalized_id; + atomic_long_t last_finalized_seq; }; =20 /* @@ -259,7 +259,7 @@ static struct printk_ringbuffer name =3D { \ .infos =3D &_##name##_infos[0], \ .head_id =3D ATOMIC_INIT(DESC0_ID(descbits)), \ .tail_id =3D ATOMIC_INIT(DESC0_ID(descbits)), \ - .last_finalized_id =3D ATOMIC_INIT(DESC0_ID(descbits)), \ + .last_finalized_seq =3D ATOMIC_INIT(0), \ }, \ .text_data_ring =3D { \ .size_bits =3D (avgtextbits) + (descbits), \ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 22A5C1428ED; Sun, 24 Mar 2024 22:37:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319858; cv=none; b=DykJUVJw+trLF+eFXgQQzTknizSqwx6SgCFsG5FdR11Ptf64jhnC8BwV5b2pvPU0PyWxY1ruB8V0oAJUzglrKpUtVPGjEbUAA3U/Kl5FSk3QWQN1cqoEMoMUewtz6SmQSJTUQLGMkZLSqnrI4Efdo5ziCFW+4HNOwQF0/Ll33Fc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319858; c=relaxed/simple; bh=Hb/NsZOhMbQg490AAjzJrWojSX3thYXJ3sqhmuaCxWw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IlDaR3lEod8IT6lnyUGSLeREfubhDzrmSzlnu+9skRbimSYu7/c7hbQBOCp7z5qvuqig0GBCeTc/a/Biyzml+n/oxokUC0HSLibab3BAyikKmw0PYqOapBv+RqJDlgA+F/mGveD1+3DdutaIDy+c3cflOtsp6Oi59X/A23ciQvc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QF+edNKD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QF+edNKD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14CD4C433C7; Sun, 24 Mar 2024 22:37:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319857; bh=Hb/NsZOhMbQg490AAjzJrWojSX3thYXJ3sqhmuaCxWw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QF+edNKDo5S/Y6frqX2lajIKQ173w4pXug5mTrn0m6pffN+flOcszENcvEamdI7yB uOCTCkHblUkp9pQ2BtoR/9BAh0rdrOHVmS306IOam7AYIA4K2Tfef6AAk/uN9dEspK ghNOICi+qHq6H9VGpRTGcblgPfeG596wPwZxc/N1mEyagYhfpoR6JA8SWhTGPrtc95 dCakJ/cI6ynjstBFHMJYtSZMtagAg+y7LYhZRmD4sAC7cI6wUNAsPIDkPTv4AUaWeu impo/iYjeEVOCrhlDxkai+OBo7jAWk7uBnovRAJb1jqCt9SGvSYmYVMtiRgr48sPLQ N5Mt7Oa2s0lnA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: John Ogness , Petr Mladek , Sasha Levin Subject: [PATCH 6.8 161/715] printk: Wait for all reserved records with pr_flush() Date: Sun, 24 Mar 2024 18:25:40 -0400 Message-ID: <20240324223455.1342824-162-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: John Ogness [ Upstream commit ac7d7844c64d15603daa3e905a311ddcfbb4bc91 ] Currently pr_flush() will only wait for records that were available to readers at the time of the call (using prb_next_seq()). But there may be more records (non-finalized) that have following finalized records. pr_flush() should wait for these to print as well. Particularly because any trailing finalized records may be the messages that the calling context wants to ensure are printed. Add a new ringbuffer function prb_next_reserve_seq() to return the sequence number following the most recently reserved record. This guarantees that pr_flush() will wait until all current printk() messages (completed or in progress) have been printed. Fixes: 3b604ca81202 ("printk: add pr_flush()") Signed-off-by: John Ogness Reviewed-by: Petr Mladek Link: https://lore.kernel.org/r/20240207134103.1357162-10-john.ogness@linut= ronix.de Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/printk/printk.c | 2 +- kernel/printk/printk_ringbuffer.c | 105 ++++++++++++++++++++++++++++++ kernel/printk/printk_ringbuffer.h | 1 + 3 files changed, 107 insertions(+), 1 deletion(-) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index f2444b581e16c..d9420207282ac 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -3761,7 +3761,7 @@ static bool __pr_flush(struct console *con, int timeo= ut_ms, bool reset_on_progre =20 might_sleep(); =20 - seq =3D prb_next_seq(prb); + seq =3D prb_next_reserve_seq(prb); =20 /* Flush the consoles so that records up to @seq are printed. */ console_lock(); diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringb= uffer.c index 4ce1826dc9426..d152b6bd35c9a 100644 --- a/kernel/printk/printk_ringbuffer.c +++ b/kernel/printk/printk_ringbuffer.c @@ -1974,6 +1974,111 @@ static u64 prb_first_seq(struct printk_ringbuffer *= rb) return seq; } =20 +/** + * prb_next_reserve_seq() - Get the sequence number after the most recently + * reserved record. + * + * @rb: The ringbuffer to get the sequence number from. + * + * This is the public function available to readers to see what sequence + * number will be assigned to the next reserved record. + * + * Note that depending on the situation, this value can be equal to or + * higher than the sequence number returned by prb_next_seq(). + * + * Context: Any context. + * Return: The sequence number that will be assigned to the next record + * reserved. + */ +u64 prb_next_reserve_seq(struct printk_ringbuffer *rb) +{ + struct prb_desc_ring *desc_ring =3D &rb->desc_ring; + unsigned long last_finalized_id; + atomic_long_t *state_var; + u64 last_finalized_seq; + unsigned long head_id; + struct prb_desc desc; + unsigned long diff; + struct prb_desc *d; + int err; + + /* + * It may not be possible to read a sequence number for @head_id. + * So the ID of @last_finailzed_seq is used to calculate what the + * sequence number of @head_id will be. + */ + +try_again: + last_finalized_seq =3D desc_last_finalized_seq(rb); + + /* + * @head_id is loaded after @last_finalized_seq to ensure that + * it points to the record with @last_finalized_seq or newer. + * + * Memory barrier involvement: + * + * If desc_last_finalized_seq:A reads from + * desc_update_last_finalized:A, then + * prb_next_reserve_seq:A reads from desc_reserve:D. + * + * Relies on: + * + * RELEASE from desc_reserve:D to desc_update_last_finalized:A + * matching + * ACQUIRE from desc_last_finalized_seq:A to prb_next_reserve_seq:A + * + * Note: desc_reserve:D and desc_update_last_finalized:A can be + * different CPUs. However, the desc_update_last_finalized:A CPU + * (which performs the release) must have previously seen + * desc_read:C, which implies desc_reserve:D can be seen. + */ + head_id =3D atomic_long_read(&desc_ring->head_id); /* LMM(prb_next_reserv= e_seq:A) */ + + d =3D to_desc(desc_ring, last_finalized_seq); + state_var =3D &d->state_var; + + /* Extract the ID, used to specify the descriptor to read. */ + last_finalized_id =3D DESC_ID(atomic_long_read(state_var)); + + /* Ensure @last_finalized_id is correct. */ + err =3D desc_read_finalized_seq(desc_ring, last_finalized_id, last_finali= zed_seq, &desc); + + if (err =3D=3D -EINVAL) { + if (last_finalized_seq =3D=3D 0) { + /* + * No record has been finalized or even reserved yet. + * + * The @head_id is initialized such that the first + * increment will yield the first record (seq=3D0). + * Handle it separately to avoid a negative @diff + * below. + */ + if (head_id =3D=3D DESC0_ID(desc_ring->count_bits)) + return 0; + + /* + * One or more descriptors are already reserved. Use + * the descriptor ID of the first one (@seq=3D0) for + * the @diff below. + */ + last_finalized_id =3D DESC0_ID(desc_ring->count_bits) + 1; + } else { + /* Record must have been overwritten. Try again. */ + goto try_again; + } + } + + /* Diff of known descriptor IDs to compute related sequence numbers. */ + diff =3D head_id - last_finalized_id; + + /* + * @head_id points to the most recently reserved record, but this + * function returns the sequence number that will be assigned to the + * next (not yet reserved) record. Thus +1 is needed. + */ + return (last_finalized_seq + diff + 1); +} + /* * Non-blocking read of a record. Updates @seq to the last finalized record * (which may have no data available). diff --git a/kernel/printk/printk_ringbuffer.h b/kernel/printk/printk_ringb= uffer.h index 70457916d577d..5aebe97bd4afc 100644 --- a/kernel/printk/printk_ringbuffer.h +++ b/kernel/printk/printk_ringbuffer.h @@ -380,6 +380,7 @@ bool prb_read_valid_info(struct printk_ringbuffer *rb, = u64 seq, =20 u64 prb_first_valid_seq(struct printk_ringbuffer *rb); u64 prb_next_seq(struct printk_ringbuffer *rb); +u64 prb_next_reserve_seq(struct printk_ringbuffer *rb); =20 #ifdef CONFIG_64BIT =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B1C381428FD; Sun, 24 Mar 2024 22:37:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319858; cv=none; b=sYo8pMDyayr56mczOgRqUEuMsRsf+wbQ/yEhtmTAURwu6PqnBDQOpWzYVY8zxdvrhGqhDa76OB6y4eSOI6inrN/JKFveLhvyBQ54I4yChgd2mfOi/WTA+TTkFqdCFqgh+JEUaMi48uAHVWVrDcAiRgVxRYZiEd+RGOZqHvLM5Yo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319858; c=relaxed/simple; bh=weL9bKStwrCWZ03fP6/Vywm6N8qOPfvGjjZrxMDFsZM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rOwhsYnPh5Bsb3CKvfpvHYDoJeAXiV6ahvUFq3ypTzm9KXfQsCuvHpAP2HG7mlIdE9CJhVQjWZb17F1xnygs0z8Mr3dwvHNY/qVbNDV6tr7tvipbadGZicku8EROhJgpkvd9Jujxtr7xzG4MNJnhyq6DNFNeqscDHhcTjdcIlO0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C4HjjQ0d; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="C4HjjQ0d" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EB1A9C43390; Sun, 24 Mar 2024 22:37:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319858; bh=weL9bKStwrCWZ03fP6/Vywm6N8qOPfvGjjZrxMDFsZM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C4HjjQ0dl4JX8oFdGVPcOI2ak5lPMj2F5hRI5UBp88uxu9e6IRetd7gTNONxmWFjN JmfgR6aYyY0xn04LQmBMy0JxRMJL0B5O48RFGzL/oc8USFapTs7Sxo86FTHDlQRLnD SC2Lw8T9u1k4+xtA2aYzNk7pL4J6sCAF/mDbX2v6veDCSJa6+Zc6HNWIau4dIq+xfc 1WK3qbVRMM1Uwj4mjPEOZElXA5sKPbRwXJ99UR4iM9vRJPBKsagiBOS116ludvm5mp nDzXBNRJ7ZF143iPL2D7stPkz/BGL5XIHZUGM5r2/YQpuUS2GhrYrIWRM5BcZL8/sQ OK0C3UPp13PrQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: John Ogness , Petr Mladek , Sasha Levin Subject: [PATCH 6.8 162/715] printk: Add this_cpu_in_panic() Date: Sun, 24 Mar 2024 18:25:41 -0400 Message-ID: <20240324223455.1342824-163-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: John Ogness [ Upstream commit 36652d0f3bf34899e82d31a5fa9e2bdd02fd6381 ] There is already panic_in_progress() and other_cpu_in_panic(), but checking if the current CPU is the panic CPU must still be open coded. Add this_cpu_in_panic() to complete the set. Signed-off-by: John Ogness Reviewed-by: Petr Mladek Link: https://lore.kernel.org/r/20240207134103.1357162-8-john.ogness@linutr= onix.de Signed-off-by: Petr Mladek Stable-dep-of: b1c4c67a5e90 ("printk: ringbuffer: Skip non-finalized record= s in panic") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/printk/internal.h | 1 + kernel/printk/printk.c | 43 +++++++++++++++++++++------------------- 2 files changed, 24 insertions(+), 20 deletions(-) diff --git a/kernel/printk/internal.h b/kernel/printk/internal.h index 6c2afee5ef620..ac2d9750e5f81 100644 --- a/kernel/printk/internal.h +++ b/kernel/printk/internal.h @@ -130,6 +130,7 @@ struct printk_message { }; =20 bool other_cpu_in_panic(void); +bool this_cpu_in_panic(void); bool printk_get_next_message(struct printk_message *pmsg, u64 seq, bool is_extended, bool may_supress); =20 diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index d9420207282ac..b7e50f8438df3 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -347,6 +347,29 @@ static bool panic_in_progress(void) return unlikely(atomic_read(&panic_cpu) !=3D PANIC_CPU_INVALID); } =20 +/* Return true if a panic is in progress on the current CPU. */ +bool this_cpu_in_panic(void) +{ + /* + * We can use raw_smp_processor_id() here because it is impossible for + * the task to be migrated to the panic_cpu, or away from it. If + * panic_cpu has already been set, and we're not currently executing on + * that CPU, then we never will be. + */ + return unlikely(atomic_read(&panic_cpu) =3D=3D raw_smp_processor_id()); +} + +/* + * Return true if a panic is in progress on a remote CPU. + * + * On true, the local CPU should immediately release any printing resources + * that may be needed by the panic CPU. + */ +bool other_cpu_in_panic(void) +{ + return (panic_in_progress() && !this_cpu_in_panic()); +} + /* * This is used for debugging the mess that is the VT code by * keeping track if we have the console semaphore held. It's @@ -2601,26 +2624,6 @@ static int console_cpu_notify(unsigned int cpu) return 0; } =20 -/* - * Return true if a panic is in progress on a remote CPU. - * - * On true, the local CPU should immediately release any printing resources - * that may be needed by the panic CPU. - */ -bool other_cpu_in_panic(void) -{ - if (!panic_in_progress()) - return false; - - /* - * We can use raw_smp_processor_id() here because it is impossible for - * the task to be migrated to the panic_cpu, or away from it. If - * panic_cpu has already been set, and we're not currently executing on - * that CPU, then we never will be. - */ - return atomic_read(&panic_cpu) !=3D raw_smp_processor_id(); -} - /** * console_lock - block the console subsystem from printing * --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CDF0F14291E; Sun, 24 Mar 2024 22:37:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319859; cv=none; b=fYEZr+/BgXux6t9CpGyXNdyQJgGWw2visRYiugLrctVBysHqOn+AlWeg7pa5R0MtwtEWpYLAu/AoKeR1k3qiG7TA33rJ9B8W4Vy4HZo7UxmtbXF7xM4MEdoQWzNlPs/bVB0vmlRP7/oNXG49PiEFtPHI+ZDfEN+T/yI/CJagZDs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319859; c=relaxed/simple; bh=55Nb6Gl3zSs4ji63PyDfoyTChWWBkNx9WldkUmv7yW4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=F7xVmEKaaUkP1JVfCBgrGRmC00lvhR0uChXPYbHfhUOpY3piWv+nz04FGuhHJEBsqeIodk5K7OZ1wvFgNbFp4BwBi64PSDea9Z3LmCyQnqP7GDYgqRPmoRA8CJyEeEFA3pdGJR1MvxdOJRscUh0wsNlybyPBdyMzXeI6vssGA54= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BUBADQqw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BUBADQqw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE80AC433C7; Sun, 24 Mar 2024 22:37:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319859; bh=55Nb6Gl3zSs4ji63PyDfoyTChWWBkNx9WldkUmv7yW4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BUBADQqwRLKG+vXVYhERb1zum9zrX9TybyH5boR+RRfIq+tLMwBny/bzmjGK6lm3Y V+vfh035uVcG753ETbTySi7zrVyPtzewpTvS7t6ZBK0edzIdG6DQM3RVDNvSo8GZwP i/hY6nvFSQ7PPL7eOOLNEJXWUkim7pCt1Mw6hbgEUMEBO+sq01jHWZ3VPuRJkqKF66 a6eLXrlTWx65c66yz20zHX/xD4WpISkPitw8miLdI3SEuH8iM8JuQWik48TsPIa5PU T99dLola3GB+NymK2FP3N7jMVbDeZ87Vr+9o4bA8xhW1lrfQPnLuJ+WNQO4KEJMlNi S07FV2ypsB8yw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: John Ogness , Petr Mladek , Sasha Levin Subject: [PATCH 6.8 163/715] printk: ringbuffer: Cleanup reader terminology Date: Sun, 24 Mar 2024 18:25:42 -0400 Message-ID: <20240324223455.1342824-164-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: John Ogness [ Upstream commit 584528d621459d1a5c31da7a591218ad3bb96d6c ] With the lockless ringbuffer, it is allowed that multiple CPUs/contexts write simultaneously into the buffer. This creates an ambiguity as some writers will finalize sooner. The documentation for the prb_read functions is not clear as it refers to "not yet written" and "no data available". Clarify the return values and language to be in terms of the reader: records available for reading. Signed-off-by: John Ogness Reviewed-by: Petr Mladek Link: https://lore.kernel.org/r/20240207134103.1357162-9-john.ogness@linutr= onix.de Signed-off-by: Petr Mladek Stable-dep-of: b1c4c67a5e90 ("printk: ringbuffer: Skip non-finalized record= s in panic") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/printk/printk_ringbuffer.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringb= uffer.c index d152b6bd35c9a..97ec25d227976 100644 --- a/kernel/printk/printk_ringbuffer.c +++ b/kernel/printk/printk_ringbuffer.c @@ -2080,11 +2080,13 @@ u64 prb_next_reserve_seq(struct printk_ringbuffer *= rb) } =20 /* - * Non-blocking read of a record. Updates @seq to the last finalized record - * (which may have no data available). + * Non-blocking read of a record. * - * See the description of prb_read_valid() and prb_read_valid_info() - * for details. + * On success @seq is updated to the record that was read and (if provided) + * @r and @line_count will contain the read/calculated data. + * + * On failure @seq is updated to a record that is not yet available to the + * reader, but it will be the next record available to the reader. */ static bool _prb_read_valid(struct printk_ringbuffer *rb, u64 *seq, struct printk_record *r, unsigned int *line_count) @@ -2103,7 +2105,7 @@ static bool _prb_read_valid(struct printk_ringbuffer = *rb, u64 *seq, *seq =3D tail_seq; =20 } else if (err =3D=3D -ENOENT) { - /* Record exists, but no data available. Skip. */ + /* Record exists, but the data was lost. Skip. */ (*seq)++; =20 } else { @@ -2136,7 +2138,7 @@ static bool _prb_read_valid(struct printk_ringbuffer = *rb, u64 *seq, * On success, the reader must check r->info.seq to see which record was * actually read. This allows the reader to detect dropped records. * - * Failure means @seq refers to a not yet written record. + * Failure means @seq refers to a record not yet available to the reader. */ bool prb_read_valid(struct printk_ringbuffer *rb, u64 seq, struct printk_record *r) @@ -2166,7 +2168,7 @@ bool prb_read_valid(struct printk_ringbuffer *rb, u64= seq, * On success, the reader must check info->seq to see which record meta da= ta * was actually read. This allows the reader to detect dropped records. * - * Failure means @seq refers to a not yet written record. + * Failure means @seq refers to a record not yet available to the reader. */ bool prb_read_valid_info(struct printk_ringbuffer *rb, u64 seq, struct printk_info *info, unsigned int *line_count) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B681D143C5F; Sun, 24 Mar 2024 22:37:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319860; cv=none; b=AmV/K4O9JKIOvyj6dvq0apqa0M7QxPF/LJ9HqvQLjjjqa7vRGy4wXXJk6cEE41snDmbmAx0A0cV0NpFY2i1EHq1QqiNFkBsiSxYAHm6FrnKg9NvWl8/t1gXK/ivMNajwPb5FQlBjrV0xFkfvBop+A6+zUHUHDdj8Pu5q/3GpSFI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319860; c=relaxed/simple; bh=RN/Gjmnw+EceYASHDrod4BrDl4PiVcldLWDVe0b9138=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SwuJJDL8StOCS26Mo9x8vb0ulG8u5TeGk51ju5IlW+8uCrdA/zBAjsvYQeHu96v6a/IJX8nT32fZbb93JEcr4Kwd0XGeMHjDngAfRYJLVYDvY2RQO8m98fplHaz9mcmGRL1i2JmNYikL0sjtCZEGBTVuB4rN6Ai02pIVQi8nNIc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dSCkxZ4Y; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dSCkxZ4Y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE66CC43390; Sun, 24 Mar 2024 22:37:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319860; bh=RN/Gjmnw+EceYASHDrod4BrDl4PiVcldLWDVe0b9138=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dSCkxZ4Yr7a4dCWC1uYRvK6OvlvtdYtDVugxSlUpGGXAjfNJdXNYjQ60bLEsHmRwE GScy7NgVvUsgHla8H75nHeAlOnyFId1BKmKzwr5YSKpopRFsJ+c7bmIZwWU93yKeop SBm2stQY6XgHix61gv2l+CyOvtkK29U76P48SvjzK4aRPgkivOPXum/5DmBlsnK2cq +tBpjyy4TEofbuk/6PuoxRygpeDcqda4Wm2dJ1vWVv7AmlBSdVRnSwrDbOgg+RDuiE +bYkvhQYMcoSj/YXyv6R6A6vRfoEMtr6rQXx5EB1SYlUaK+a/tCi2jxadM+aoBEJkN 53shRrln8SNLA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: John Ogness , Petr Mladek , Sasha Levin Subject: [PATCH 6.8 164/715] printk: ringbuffer: Skip non-finalized records in panic Date: Sun, 24 Mar 2024 18:25:43 -0400 Message-ID: <20240324223455.1342824-165-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: John Ogness [ Upstream commit b1c4c67a5e90db8fbdb5b5504fe16e17b564cca8 ] Normally a reader will stop once reaching a non-finalized record. However, when a panic happens, writers from other CPUs (or an interrupted context on the panic CPU) may have been writing a record and were unable to finalize it. The panic CPU will reserve/commit/finalize its panic records, but these will be located after the non-finalized records. This results in panic() not flushing the panic messages. Extend _prb_read_valid() to skip over non-finalized records if on the panic CPU. Fixes: 896fbe20b4e2 ("printk: use the lockless ringbuffer") Signed-off-by: John Ogness Reviewed-by: Petr Mladek Link: https://lore.kernel.org/r/20240207134103.1357162-11-john.ogness@linut= ronix.de Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/printk/printk_ringbuffer.c | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/kernel/printk/printk_ringbuffer.c b/kernel/printk/printk_ringb= uffer.c index 97ec25d227976..3d98232902cfd 100644 --- a/kernel/printk/printk_ringbuffer.c +++ b/kernel/printk/printk_ringbuffer.c @@ -2087,6 +2087,10 @@ u64 prb_next_reserve_seq(struct printk_ringbuffer *r= b) * * On failure @seq is updated to a record that is not yet available to the * reader, but it will be the next record available to the reader. + * + * Note: When the current CPU is in panic, this function will skip over any + * non-existent/non-finalized records in order to allow the panic CPU + * to print any and all records that have been finalized. */ static bool _prb_read_valid(struct printk_ringbuffer *rb, u64 *seq, struct printk_record *r, unsigned int *line_count) @@ -2109,8 +2113,28 @@ static bool _prb_read_valid(struct printk_ringbuffer= *rb, u64 *seq, (*seq)++; =20 } else { - /* Non-existent/non-finalized record. Must stop. */ - return false; + /* + * Non-existent/non-finalized record. Must stop. + * + * For panic situations it cannot be expected that + * non-finalized records will become finalized. But + * there may be other finalized records beyond that + * need to be printed for a panic situation. If this + * is the panic CPU, skip this + * non-existent/non-finalized record unless it is + * at or beyond the head, in which case it is not + * possible to continue. + * + * Note that new messages printed on panic CPU are + * finalized when we are here. The only exception + * might be the last message without trailing newline. + * But it would have the sequence number returned + * by "prb_next_reserve_seq() - 1". + */ + if (this_cpu_in_panic() && ((*seq + 1) < prb_next_reserve_seq(rb))) + (*seq)++; + else + return false; } } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 54F8A1448D8; Sun, 24 Mar 2024 22:37:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319862; cv=none; b=M6WoNBA4ly1yYV8WRdgm4YlMPSj9Udgkl3JcxxSogO99qvpMR1R538f4cKFSSoukCLSRSU412Lzt2bdNkhYP3znj81j6wETLsRLsR4/882jAc+3OaXfiduIr8FWXvNk0mcbWBcrNd6wVLNRDUKxPayVEPMZKF6U/sMyFNpyr2sk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319862; c=relaxed/simple; bh=Jb7k3GoU6Ve+LODOIYdKGbcfDg48IkkmThzdS/zf9lE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=OWeLOEC8iN3D/sPm3ZSTLgAHOrgIZub6FkvkfKpODDt8oye1tnqfs6yNHhtznP6/RyrtTignsvysKEcFLJJGoLCq3Bg69imYls8llN5yb1UHOEppK5g1DiNSZj7fY7dOesLUeykw0qCx4y+K8/kBMeJOFf2lTrGPM07HgpFsyXc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IH7mSFuI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IH7mSFuI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90B0CC433C7; Sun, 24 Mar 2024 22:37:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319861; bh=Jb7k3GoU6Ve+LODOIYdKGbcfDg48IkkmThzdS/zf9lE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IH7mSFuIPdJK7zd8gD/NYm0RLnBqzes39j9uigRoBtzsyBszkPIPdnpCebyfYgub1 8kLc8BYEq5JPoxu5+ASK3jT4ssh3FeFiByS9ZEQfKD6f0waVRHllhFuBqns+nty8r2 WhGYcPqAtOCM8PnyFK8ysTVfP2jak1Hff1EQYb0YMBsb139rHX2wvUPu8G7raIQbM3 PtvuQtAqH7oRXFkaSrDJIjolMOxcxH3TYTQjubop2ypC1slNe2vLLlynuH+tfgUYxj UmPhMdWDoEfeHVGtdn6HyUJD9RsDR6D4xpeZ73fCPwimVKCOBBElC3DxgR8Ie8io64 0tne1MvKhEpng== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Petr Mladek , John Ogness , Sasha Levin Subject: [PATCH 6.8 165/715] printk: Disable passing console lock owner completely during panic() Date: Sun, 24 Mar 2024 18:25:44 -0400 Message-ID: <20240324223455.1342824-166-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Petr Mladek [ Upstream commit d04d5882cd678b898a9d7c5aee6afbe9e6e77fcd ] The commit d51507098ff91 ("printk: disable optimistic spin during panic") added checks to avoid becoming a console waiter if a panic is in progress. However, the transition to panic can occur while there is already a waiter. The current owner should not pass the lock to the waiter because it might get stopped or blocked anytime. Also the panic context might pass the console lock owner to an already stopped waiter by mistake. It might happen when console_flush_on_panic() ignores the current lock owner, for example: CPU0 CPU1 Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya ---- ---- console_lock_spinning_enable() console_trylock_spinning() [CPU1 now console waiter] NMI: panic() panic_other_cpus_shutdown() [stopped as console waiter] console_flush_on_panic() console_lock_spinning_enable() [print 1 record] console_lock_spinning_disable_and_check() [handover to stopped CPU1] This results in panic() not flushing the panic messages. Fix these problems by disabling all spinning operations completely during panic(). Another advantage is that it prevents possible deadlocks caused by "console_owner_lock". The panic() context does not need to take it any longer. The lockless checks are safe because the functions become NOPs when they see the panic in progress. All operations manipulating the state are still synchronized by the lock even when non-panic CPUs would notice the panic synchronously. The current owner might stay spinning. But non-panic() CPUs would get stopped anyway and the panic context will never start spinning. Fixes: dbdda842fe96 ("printk: Add console owner and waiter logic to load ba= lance console writes") Signed-off-by: John Ogness Link: https://lore.kernel.org/r/20240207134103.1357162-12-john.ogness@linut= ronix.de Signed-off-by: Petr Mladek Signed-off-by: Sasha Levin --- kernel/printk/printk.c | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index b7e50f8438df3..72f6a564e832f 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -1869,10 +1869,23 @@ static bool console_waiter; */ static void console_lock_spinning_enable(void) { + /* + * Do not use spinning in panic(). The panic CPU wants to keep the lock. + * Non-panic CPUs abandon the flush anyway. + * + * Just keep the lockdep annotation. The panic-CPU should avoid + * taking console_owner_lock because it might cause a deadlock. + * This looks like the easiest way how to prevent false lockdep + * reports without handling races a lockless way. + */ + if (panic_in_progress()) + goto lockdep; + raw_spin_lock(&console_owner_lock); console_owner =3D current; raw_spin_unlock(&console_owner_lock); =20 +lockdep: /* The waiter may spin on us after setting console_owner */ spin_acquire(&console_owner_dep_map, 0, 0, _THIS_IP_); } @@ -1897,6 +1910,22 @@ static int console_lock_spinning_disable_and_check(i= nt cookie) { int waiter; =20 + /* + * Ignore spinning waiters during panic() because they might get stopped + * or blocked at any time, + * + * It is safe because nobody is allowed to start spinning during panic + * in the first place. If there has been a waiter then non panic CPUs + * might stay spinning. They would get stopped anyway. The panic context + * will never start spinning and an interrupted spin on panic CPU will + * never continue. + */ + if (panic_in_progress()) { + /* Keep lockdep happy. */ + spin_release(&console_owner_dep_map, _THIS_IP_); + return 0; + } + raw_spin_lock(&console_owner_lock); waiter =3D READ_ONCE(console_waiter); console_owner =3D NULL; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 572801448D9; Sun, 24 Mar 2024 22:37:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319862; cv=none; b=XQ3MWu0nm7fXtt/wY8PzfNWPovkjvoU9/eMDIqBSgzQjjixYRe4nWWpsB1q+Oq+Ku5EWSaLHXXQdqe2OH4pbq2hbia+/YtH/j2rXFbXVrQgdY/waKmB/mi42swwCL6IePmk2lZUzT2MBZD1uXkpBjhnH2dIlFv3PGMTUjgkldo4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319862; c=relaxed/simple; bh=U7UUfpnSunlKz2k+7C0ZDRf/QE5Hl7pDxKb9sSrtVZw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=rXxexc/75e7BE5R1kxhNaM0NM3nrZlr++l/l9bl6ghu1bs96r+yIwJBuwhGSG0aXi/8YR5+eBypuC+kzVh+IcrMsDsA0R23s8pY1YCWB2HZ1dPg8iVUSp9Ns0QktMSl3H8JYFmUrTUk9BLKQ5tMOAuLyV4DNNCFl81oapQ7gayY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MHY00jqq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MHY00jqq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7397BC43390; Sun, 24 Mar 2024 22:37:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319862; bh=U7UUfpnSunlKz2k+7C0ZDRf/QE5Hl7pDxKb9sSrtVZw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MHY00jqqh2+xD9zV5lhTnLrd62JqMOLBc10EdCADxHLV9oplNPyf7J0Y7+TP6tdK2 YR8R2AC1f3tCL/Xhzn+BSzHQ1WWl9EmQ+olGP8wpiSXirjt2WumIhdh/bGizQ6PR/X zoltIKYA1rK7XiPGWT6z0dRZ5itHHg3yWJL7JC/+0zcJEsv3P9lmOFWav05Mrs/1kp GfLcvQEr7oUGUCLDEy7iv9N1rwJwgGVOhPHXZ2uLMwBreuV1cULwN+M6ZqDn8vmEA8 asbBuMtKLD46t10N4OHqsGA+w4djQH/lLMfN8Eexi2sRjI0F7GK1dTWwbuk0DPgyDx /JymRIKvUI6yg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= , Sasha Levin Subject: [PATCH 6.8 166/715] pwm: sti: Fix capture for st,pwm-num-chan < st,capture-num-chan Date: Sun, 24 Mar 2024 18:25:45 -0400 Message-ID: <20240324223455.1342824-167-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Uwe Kleine-K=C3=B6nig [ Upstream commit 5f623835584f1c8d1030666796f40c47a448ce0b ] The driver only used the number of pwm channels to set the pwm_chip's npwm member. The result is that if there are more capture channels than PWM channels specified in the device tree, only a part of the capture channel is usable. Fix that by passing the bigger channel count to the pwm framework. This makes it possible that the .apply() callback is called with .hwpwm >=3D pwm_num_devs, catch that case and return an error code. Fixes: c97267ae831d ("pwm: sti: Add PWM capture callback") Link: https://lore.kernel.org/r/20240204212043.2951852-2-u.kleine-koenig@pe= ngutronix.de Signed-off-by: Uwe Kleine-K=C3=B6nig Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/pwm/pwm-sti.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/pwm/pwm-sti.c b/drivers/pwm/pwm-sti.c index 6cf55cf34d39f..69b1113c6b821 100644 --- a/drivers/pwm/pwm-sti.c +++ b/drivers/pwm/pwm-sti.c @@ -395,8 +395,17 @@ static int sti_pwm_capture(struct pwm_chip *chip, stru= ct pwm_device *pwm, static int sti_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm, const struct pwm_state *state) { + struct sti_pwm_chip *pc =3D to_sti_pwmchip(chip); + struct sti_pwm_compat_data *cdata =3D pc->cdata; + struct device *dev =3D pc->dev; int err; =20 + if (pwm->hwpwm >=3D cdata->pwm_num_devs) { + dev_err(dev, "device %u is not valid for pwm mode\n", + pwm->hwpwm); + return -EINVAL; + } + if (state->polarity !=3D PWM_POLARITY_NORMAL) return -EINVAL; =20 @@ -646,7 +655,7 @@ static int sti_pwm_probe(struct platform_device *pdev) =20 pc->chip.dev =3D dev; pc->chip.ops =3D &sti_pwm_ops; - pc->chip.npwm =3D pc->cdata->pwm_num_devs; + pc->chip.npwm =3D max(cdata->pwm_num_devs, cdata->cpt_num_devs); =20 for (i =3D 0; i < cdata->cpt_num_devs; i++) { struct sti_cpt_ddata *ddata =3D &cdata->ddata[i]; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 14D531448F6; Sun, 24 Mar 2024 22:37:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319863; cv=none; b=jD7mP/afRRIfFene1F9AA8zR7ekt0Bpq4xdOhgI8WbxmZbjDZsxp+2HZVkfiSygCrcqx0TgIBvd/QAvgj29xplXxDYMVHYkTINOqEuoIE7W3clQqL9/nMQW1e4Vb43XScBtHHe3naWsRXYXyry7mKA8gBoPzymMbs8pRqCNof18= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319863; c=relaxed/simple; bh=lrV3hF7pREKUALqHJGjU2QWD2BAkZOc4EaJoGgQ0cV0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p+JrkKjZBzcMtuLaGPIlhTv0LM5aymDFpqksq2OyGGIxa3hbP5tDmui4/YUUkf7HTRa2l0Bjb2jk3VqZNs6+8H5Hn/QcNyT9YRZa1gu0a8pww3KnpHsIE7xrGEcnaYcbBa73WqP7Zled6jDo2/SWlgwGJhwwnQ6hUiVivaXMR38= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=diAeKqxg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="diAeKqxg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41F01C43399; Sun, 24 Mar 2024 22:37:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319863; bh=lrV3hF7pREKUALqHJGjU2QWD2BAkZOc4EaJoGgQ0cV0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=diAeKqxgKlP+a1M356wVloiBHSU3KDBnEunpG7SBJKR2LOgwFla2gKC9FEDmRxrxk T+eb2XpnnBDCLLfIYTHxjNg13SUFDGix7VVt96WtHSZbDb7CGrYTRICyAaIiuarbNv 7rVscmvufO+1cGATP3TDwGKeaXNeSoPAXZnsJ3Q0Q+H0/i408l/xDDnotjfBfRlNVb G7rW40hAmJ1gshT+3RygPGaEGqEqnmNPDW791bDUW+xN8vIVvUjWpwACD/nkKuVU9w mRd1KqZ/WMmKvVK1d5ln+oVfwN4tswSlABn6vH1nRxg6c0+HmVztdyXMptxycK9k4P Ez5V6WZApIs3g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Viktor Malik , Andrii Nakryiko , Daniel Xu , Sasha Levin Subject: [PATCH 6.8 167/715] tools/resolve_btfids: Refactor set sorting with types from btf_ids.h Date: Sun, 24 Mar 2024 18:25:46 -0400 Message-ID: <20240324223455.1342824-168-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Viktor Malik [ Upstream commit 9707ac4fe2f5bac6406d2403f8b8a64d7b3d8e43 ] Instead of using magic offsets to access BTF ID set data, leverage types from btf_ids.h (btf_id_set and btf_id_set8) which define the actual layout of the data. Thanks to this change, set sorting should also continue working if the layout changes. This requires to sync the definition of 'struct btf_id_set8' from include/linux/btf_ids.h to tools/include/linux/btf_ids.h. We don't sync the rest of the file at the moment, b/c that would require to also sync multiple dependent headers and we don't need any other defs from btf_ids.h. Signed-off-by: Viktor Malik Signed-off-by: Andrii Nakryiko Acked-by: Daniel Xu Link: https://lore.kernel.org/bpf/ff7f062ddf6a00815fda3087957c4ce667f50532.= 1707223196.git.vmalik@redhat.com Stable-dep-of: 903fad439466 ("tools/resolve_btfids: Fix cross-compilation t= o non-host endianness") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/bpf/resolve_btfids/main.c | 35 ++++++++++++++++++++------------- tools/include/linux/btf_ids.h | 9 +++++++++ 2 files changed, 30 insertions(+), 14 deletions(-) diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/mai= n.c index 27a23196d58e1..32634f00abba4 100644 --- a/tools/bpf/resolve_btfids/main.c +++ b/tools/bpf/resolve_btfids/main.c @@ -70,6 +70,7 @@ #include #include #include +#include #include #include #include @@ -78,7 +79,7 @@ #include =20 #define BTF_IDS_SECTION ".BTF_ids" -#define BTF_ID "__BTF_ID__" +#define BTF_ID_PREFIX "__BTF_ID__" =20 #define BTF_STRUCT "struct" #define BTF_UNION "union" @@ -161,7 +162,7 @@ static int eprintf(int level, int var, const char *fmt,= ...) =20 static bool is_btf_id(const char *name) { - return name && !strncmp(name, BTF_ID, sizeof(BTF_ID) - 1); + return name && !strncmp(name, BTF_ID_PREFIX, sizeof(BTF_ID_PREFIX) - 1); } =20 static struct btf_id *btf_id__find(struct rb_root *root, const char *name) @@ -441,7 +442,7 @@ static int symbols_collect(struct object *obj) * __BTF_ID__TYPE__vfs_truncate__0 * prefix =3D ^ */ - prefix =3D name + sizeof(BTF_ID) - 1; + prefix =3D name + sizeof(BTF_ID_PREFIX) - 1; =20 /* struct */ if (!strncmp(prefix, BTF_STRUCT, sizeof(BTF_STRUCT) - 1)) { @@ -649,19 +650,18 @@ static int cmp_id(const void *pa, const void *pb) static int sets_patch(struct object *obj) { Elf_Data *data =3D obj->efile.idlist; - int *ptr =3D data->d_buf; struct rb_node *next; =20 next =3D rb_first(&obj->sets); while (next) { - unsigned long addr, idx; + struct btf_id_set8 *set8; + struct btf_id_set *set; + unsigned long addr, off; struct btf_id *id; - int *base; - int cnt; =20 id =3D rb_entry(next, struct btf_id, rb_node); addr =3D id->addr[0]; - idx =3D addr - obj->efile.idlist_addr; + off =3D addr - obj->efile.idlist_addr; =20 /* sets are unique */ if (id->addr_cnt !=3D 1) { @@ -670,14 +670,21 @@ static int sets_patch(struct object *obj) return -1; } =20 - idx =3D idx / sizeof(int); - base =3D &ptr[idx] + (id->is_set8 ? 2 : 1); - cnt =3D ptr[idx]; + if (id->is_set) { + set =3D data->d_buf + off; + qsort(set->ids, set->cnt, sizeof(set->ids[0]), cmp_id); + } else { + set8 =3D data->d_buf + off; + /* + * Make sure id is at the beginning of the pairs + * struct, otherwise the below qsort would not work. + */ + BUILD_BUG_ON(set8->pairs !=3D &set8->pairs[0].id); + qsort(set8->pairs, set8->cnt, sizeof(set8->pairs[0]), cmp_id); + } =20 pr_debug("sorting addr %5lu: cnt %6d [%s]\n", - (idx + 1) * sizeof(int), cnt, id->name); - - qsort(base, cnt, id->is_set8 ? sizeof(uint64_t) : sizeof(int), cmp_id); + off, id->is_set ? set->cnt : set8->cnt, id->name); =20 next =3D rb_next(next); } diff --git a/tools/include/linux/btf_ids.h b/tools/include/linux/btf_ids.h index 2f882d5cb30f5..72535f00572f6 100644 --- a/tools/include/linux/btf_ids.h +++ b/tools/include/linux/btf_ids.h @@ -8,6 +8,15 @@ struct btf_id_set { u32 ids[]; }; =20 +struct btf_id_set8 { + u32 cnt; + u32 flags; + struct { + u32 id; + u32 flags; + } pairs[]; +}; + #ifdef CONFIG_DEBUG_INFO_BTF =20 #include /* for __PASTE */ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3367E14533E; Sun, 24 Mar 2024 22:37:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319864; cv=none; b=P/IsOhiZc8sOO96g/LpPFwYnRmzAIgUbQb3yvcS+6FFtfWtDgPF3afyK474IyVuJbM6ZpgMnsNZ9XkNsXZau9crDvutQyMadB3kg95navhlyhqegbI20DdRsKn8j3MsoyJ9XHk0CbIP7xzNbpKKe3UVICK3MZjYq2m/TdedJccA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319864; c=relaxed/simple; bh=uZTzWKQcsPV7yMNUkAApk1NzfA6xdSEQZjBPmeeK1cY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LWs65jjO8re06H13+fjWu+dsTOsvX+YMH8mTjvPWz7RpZkQjQQhjeC9jFq/z+YSJeZkldqTrmqlep63xddXJi7YRrMKzNxYyUrzvB2P3Q5BaMxgwAef8O4TJW3QuVXE+Il7VMHgz537eZ6W8flevMyrNzz591Gz4+YhFM9KJQ98= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NZTAye+F; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="NZTAye+F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3A5ECC433C7; Sun, 24 Mar 2024 22:37:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319863; bh=uZTzWKQcsPV7yMNUkAApk1NzfA6xdSEQZjBPmeeK1cY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=NZTAye+FIEYc8WOjGO85crlkXyeS0xAbshohxmpfxCq++fteGbUCyNJw6HVtyP2ZW /8r6SFQdmPY5x6d6jxpq7BfbjjOwSU2lRyTSNrcSdLTnYNla6CeUkV1sCYjIyQoAF+ kPpd2aN0Aav14O3feJv0cxlwSVoDc7LhxW53+dBqQkRYasP/PsvStzTQkp2+3HXM+A o4PDEfOammlVYuF/+N4FsXvD95A5wUJ9TJUm35NOXCwXqR3piXbYsvAs5Lw5Yv/auy JM9QND4uANgOgX0PQbi0cbR9x+TaQ1HQGuhVra3/L1sspunWvbW8cDTDvF0QwEcxmu 23gJzI8NVIqKg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Viktor Malik , Andrii Nakryiko , Sasha Levin Subject: [PATCH 6.8 168/715] tools/resolve_btfids: Fix cross-compilation to non-host endianness Date: Sun, 24 Mar 2024 18:25:47 -0400 Message-ID: <20240324223455.1342824-169-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Viktor Malik [ Upstream commit 903fad4394666bc23975c93fb58f137ce64b5192 ] The .BTF_ids section is pre-filled with zeroed BTF ID entries during the build and afterwards patched by resolve_btfids with correct values. Since resolve_btfids always writes in host-native endianness, it relies on libelf to do the translation when the target ELF is cross-compiled to a different endianness (this was introduced in commit 61e8aeda9398 ("bpf: Fix libelf endian handling in resolv_btfids")). Unfortunately, the translation will corrupt the flags fields of SET8 entries because these were written during vmlinux compilation and are in the correct endianness already. This will lead to numerous selftests failures such as: $ sudo ./test_verifier 502 502 #502/p sleepable fentry accept FAIL Failed to load prog 'Invalid argument'! bpf_fentry_test1 is not sleepable verification time 34 usec stack depth 0 processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 = peak_states 0 mark_read 0 Summary: 0 PASSED, 0 SKIPPED, 1 FAILED Since it's not possible to instruct libelf to translate just certain values, let's manually bswap the flags (both global and entry flags) in resolve_btfids when needed, so that libelf then translates everything correctly. Fixes: ef2c6f370a63 ("tools/resolve_btfids: Add support for 8-byte BTF sets= ") Signed-off-by: Viktor Malik Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/7b6bff690919555574ce0f13d2a5996cacf7bf69.= 1707223196.git.vmalik@redhat.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/bpf/resolve_btfids/main.c | 35 +++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/tools/bpf/resolve_btfids/main.c b/tools/bpf/resolve_btfids/mai= n.c index 32634f00abba4..d9520cb826b31 100644 --- a/tools/bpf/resolve_btfids/main.c +++ b/tools/bpf/resolve_btfids/main.c @@ -90,6 +90,14 @@ =20 #define ADDR_CNT 100 =20 +#if __BYTE_ORDER =3D=3D __LITTLE_ENDIAN +# define ELFDATANATIVE ELFDATA2LSB +#elif __BYTE_ORDER =3D=3D __BIG_ENDIAN +# define ELFDATANATIVE ELFDATA2MSB +#else +# error "Unknown machine endianness!" +#endif + struct btf_id { struct rb_node rb_node; char *name; @@ -117,6 +125,7 @@ struct object { int idlist_shndx; size_t strtabidx; unsigned long idlist_addr; + int encoding; } efile; =20 struct rb_root sets; @@ -320,6 +329,7 @@ static int elf_collect(struct object *obj) { Elf_Scn *scn =3D NULL; size_t shdrstrndx; + GElf_Ehdr ehdr; int idx =3D 0; Elf *elf; int fd; @@ -351,6 +361,13 @@ static int elf_collect(struct object *obj) return -1; } =20 + if (gelf_getehdr(obj->efile.elf, &ehdr) =3D=3D NULL) { + pr_err("FAILED cannot get ELF header: %s\n", + elf_errmsg(-1)); + return -1; + } + obj->efile.encoding =3D ehdr.e_ident[EI_DATA]; + /* * Scan all the elf sections and look for save data * from .BTF_ids section and symbols. @@ -681,6 +698,24 @@ static int sets_patch(struct object *obj) */ BUILD_BUG_ON(set8->pairs !=3D &set8->pairs[0].id); qsort(set8->pairs, set8->cnt, sizeof(set8->pairs[0]), cmp_id); + + /* + * When ELF endianness does not match endianness of the + * host, libelf will do the translation when updating + * the ELF. This, however, corrupts SET8 flags which are + * already in the target endianness. So, let's bswap + * them to the host endianness and libelf will then + * correctly translate everything. + */ + if (obj->efile.encoding !=3D ELFDATANATIVE) { + int i; + + set8->flags =3D bswap_32(set8->flags); + for (i =3D 0; i < set8->cnt; i++) { + set8->pairs[i].flags =3D + bswap_32(set8->pairs[i].flags); + } + } } =20 pr_debug("sorting addr %5lu: cnt %6d [%s]\n", --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 40954145B03; Sun, 24 Mar 2024 22:37:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319865; cv=none; b=g6OlPx3NgeyAx+vFYhkemKSiVxMgys55q4/oC/yw9c2D0qSTVV+3Ph2JkcofmE2rfVHy5z5Koi+jo1gNaLjhm32cep/x6FOI6/0mh7HiPz5dU0YQi1DFDTKmuyndLBop7ho/x7mab+76l3lT5LbdYBLJZMa3UiGUXjfxRIsMx3o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319865; c=relaxed/simple; bh=fNXPmhqnFO8SCZHEsOeWlY34U2RBXFyeg4JIchaXuW8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b7Jr7USs5Q6KtlFIDwFLLh3s38Pb+JDx7qlroIZnf+8/7/YLmOyWzDOxVQrP+aH0Y33lUoLlkFW9XlIwCAUbrqiGgzDA6gVNsEuARSWU4P+xPdBrozEJwZM0VB9wtEZOHffi/sV3nqK/quCfifgltFNfDkeYQ/07PE1j3CrclGM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ItftEjyu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ItftEjyu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1FA94C433F1; Sun, 24 Mar 2024 22:37:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319864; bh=fNXPmhqnFO8SCZHEsOeWlY34U2RBXFyeg4JIchaXuW8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ItftEjyukzfgMxMtYVFnzek04J6k3UOT3FcGabLbC6JmO/7o7FSghkmv02Cz9HKiy WYXTZna50Ujs59mjYLX7yqT0Dils21g6bzbq/9H4C4Sfm5ai0RTspF4HpQXDdXdhZr YqMp2w+G6LLI3+ItINbmzeix57vCW0WhhxFDjxv49d8GlRDKIYMWbjPOEkjxodeSxo z0v2BrZtoV3U70PpoZ+oO4dZZuZW6b7PcwVFBp+7awAeXn346PRMeGOM+ymXUExn8i VbyspM58dNVhC4iCI99lbe0xFxG1kvXUq88RIHmSg5ryeQwPWCvKpesxdr84PGhIel n7beQuVBf3mvw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Miri Korenblit , Emmanuel Grumbach , Johannes Berg , Sasha Levin Subject: [PATCH 6.8 169/715] wifi: iwlwifi: support EHT for WH Date: Sun, 24 Mar 2024 18:25:48 -0400 Message-ID: <20240324223455.1342824-170-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Miri Korenblit [ Upstream commit f51d6431824f0afb9f73d68971d154c47c26b86a ] sku_cap_11be_enable should be set to true also for WH. Fixes: e1374ed25324 ("wifi: iwlwifi: Add support for new CNVi (SC)") Signed-off-by: Miri Korenblit Reviewed-by: Emmanuel Grumbach Link: https://msgid.link/20240204235836.a6d4097cbaca.I8b00fa7b6226b4116cd91= f70fb0b15e79b4dee5a@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c b/drivers/n= et/wireless/intel/iwlwifi/iwl-nvm-parse.c index 2f6774ec37b22..501a8cc2134cf 100644 --- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c +++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c @@ -2097,7 +2097,7 @@ struct iwl_nvm_data *iwl_get_nvm(struct iwl_trans *tr= ans, !!(mac_flags & NVM_MAC_SKU_FLAGS_BAND_5_2_ENABLED); nvm->sku_cap_mimo_disabled =3D !!(mac_flags & NVM_MAC_SKU_FLAGS_MIMO_DISABLED); - if (CSR_HW_RFID_TYPE(trans->hw_rf_id) =3D=3D IWL_CFG_RF_TYPE_FM) + if (CSR_HW_RFID_TYPE(trans->hw_rf_id) >=3D IWL_CFG_RF_TYPE_FM) nvm->sku_cap_11be_enable =3D true; =20 /* Initialize PHY sku data */ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEFBC145B1B; Sun, 24 Mar 2024 22:37:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319865; cv=none; b=D6Mdh0Zt8HJkY/Cpim6x0W+h6QVrQBU2wlob4KvKpQzQ39djAH3lS7GR5rItOQoRHz7F2/VFfuk6sx7sC9dSlu5VodRDJKjnsqhBgw4ZnoUdUcmKuAeLTwcxysqTm+ywlfkfK+UuSqCo1XqsSLZQeTTy34dQiXwlRyaVIlacqdU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319865; c=relaxed/simple; bh=2q6oHfjoHzX8gP5qDR5Um+xcUNC7XmVJXbcW1TFzcOM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=d0DADdATAv5G6tYgiVtK2NFKzGTM4QGUPV0CT6wBOn2vr4JgqhjglI4FRSbHn3PY5h8o3aulm2Nh6mPm9CMcGNwTEbfWQfF/YpO3uFnc50fWOYKBcomv0hI0MPAc9uCQj6Gf6mnhM89V2YVE1l0WkYyhORyTGhN70/RJ1ACSARw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=os4uNrF2; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="os4uNrF2" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DB32C433C7; Sun, 24 Mar 2024 22:37:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319865; bh=2q6oHfjoHzX8gP5qDR5Um+xcUNC7XmVJXbcW1TFzcOM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=os4uNrF27X8vpdiUuNmGr7rHbMcQ7RgkCxYVv7uXmpoUwiHAjsPX/Bw+iLni4Z++v RKFYnrlyRH6DprlgLPqi9TZTB5v7cj0+wHuAjPCd44vaMHENf66xaxywoEfqdJlg+Y dvGqIcYTc1COLfmxdpVxkNQ4SOrZpe5G8SlYRG8wIQVWSFDAlaZwYM+lJ1b2vFkAbN krrOGTMPIVX9Z06Hif6e3agEF0d+6NrCovGuoBNmhZ6+MyBI33oPanm59eO4An3whT SBXph8xfEa92ui+t4Lkd4oB9BcywIPYhkZ11gknWDyuMWAnlk1I7twsAgdGRZi4ofM VaBL70/d3qG7A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Miri Korenblit , Johannes Berg , Sasha Levin Subject: [PATCH 6.8 170/715] wifi: iwlwifi: properly check if link is active Date: Sun, 24 Mar 2024 18:25:49 -0400 Message-ID: <20240324223455.1342824-171-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Miri Korenblit [ Upstream commit 556c7cd721b5262579ba1710c3b4e7ffdb5573ac ] Before sending SESSION PROTECTION cmd the driver verifies that the link for which the cmd is going to be sent is active. The existing code is checking it only for MLD vifs, but also the deflink (in non-MLD vifs) needs to be active in order the have a session protection for it. Fix this by checking if the link is active also for non-MLD vifs Fixes: 135065837310 ("wifi: iwlwifi: support link_id in SESSION_PROTECTION = cmd") Signed-off-by: Miri Korenblit Reviewed-by: Johannes Berg Link: https://msgid.link/20240205211151.c61820f14ca6.Ibbe0f848f3e71f64313d2= 1642650b6e4bfbe4b39@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/mvm/time-event.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c b/drivers/= net/wireless/intel/iwlwifi/mvm/time-event.c index 98c64ae315e68..da00ef6e4fbcf 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/time-event.c @@ -706,8 +706,7 @@ static int iwl_mvm_get_session_prot_id(struct iwl_mvm *= mvm, "Invalid link ID for session protection: %u\n", link_id)) return -EINVAL; =20 - if (WARN(ieee80211_vif_is_mld(vif) && - !(vif->active_links & BIT(link_id)), + if (WARN(!mvmvif->link[link_id]->active, "Session Protection on an inactive link: %u\n", link_id)) return -EINVAL; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B617F145B3C; Sun, 24 Mar 2024 22:37:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319866; cv=none; b=EzfBD1QU+mcaW/bxgltDOtaoCQMDfD/o5El0bEE4pbt331t/Z8qdxoGMxomZ89WrHSJRmSMDws2ZLsWFgOQXCaAuyECtu4zs4OtR+Q/gudUQWWetFx7a/NRWJXJxRCWdRRFmHzwqUESqlUaCK3vkavyunnmIVNDSNlO1yqaoxjM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319866; c=relaxed/simple; bh=lzVnQlyO7tR3vPso14hf/vGA5Oj0nELSAcGLnpQb/UU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MeqyC+JT2Yo6tCroDGOBxKFljR1YtErfk35tfLCLPniEQjOgVPeMwXnUIlepyy0/1FVP4Vpo/SHKoW/v3bwGuSULw/rPzRRgRBNjb7f3q7cw7kFM7NNTyRIP5tnsneRnfaWMeFHXpi33+xrRirWgu6dp1K+yzOaiY2ROX5EFSts= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K/TPv3Zs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K/TPv3Zs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0176FC43390; Sun, 24 Mar 2024 22:37:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319866; bh=lzVnQlyO7tR3vPso14hf/vGA5Oj0nELSAcGLnpQb/UU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K/TPv3ZsqfDyW0nK39bFykE34nZqzoiyRyvYXhG8y8tZ9j8m/EXT53NXqEpN2DDhG 1pb3z9XVcYbUeW2UPdn39jA41vUIYq1cIYywvB3lrS5852Xnc557LgsQI57j5gpf6V 988Y5rLVHOitL6YB5ytrrJGGmhVr6X6e72UZ8zyokrpaK9JVI5xipVi8PRH56QECJ7 Q6pOosdPqRUTZV3UC6Rva6fAGrWF9YMWgui9iHVPcO+3SkxGoE5K0FFchyB+X1gmZd flP4PRxkp2mOd4nyJOq3euaKqh77cRFrlDx605Sf253II21Az5Spymwn3/vwVAvNfo btVu+LCLuQYIQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johannes Berg , Miri Korenblit , Sasha Levin Subject: [PATCH 6.8 171/715] wifi: iwlwifi: mvm: fix erroneous queue index mask Date: Sun, 24 Mar 2024 18:25:50 -0400 Message-ID: <20240324223455.1342824-172-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johannes Berg [ Upstream commit 2e0e766bd8a7f14f10c3e70b8203c4c1e6d9ec76 ] When retrieving the queue index ("SCD SSN") from the TX response, it's currently masked with 0xFFF. However, now that we have queues longer than 4k, that became wrong, so make the mask depend on the hardware family. This fixes an issue where if we get a single frame reclaim while in the top half of an 8k long queue, we'd reclaim-wrap the queue twice (once on this and then again on the next non-single reclaim) which at least triggers the WARN_ON_ONCE() in iwl_txq_reclaim(), but could have other negative side effects (such as unmapping a frame that wasn't transmitted yet, and then taking an IOMMU fault) as well. Fixes: 7b3e42ea2ead ("iwlwifi: support multiple tfd queue max sizes for dif= ferent devices") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240205211151.4148a6ef54e0.I733a70f679c25f9f99097= a8dcb3a1f8165da6997@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/mvm/tx.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c b/drivers/net/wire= less/intel/iwlwifi/mvm/tx.c index 461f26d9214e4..930742e75c02a 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/tx.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/tx.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause /* - * Copyright (C) 2012-2014, 2018-2023 Intel Corporation + * Copyright (C) 2012-2014, 2018-2024 Intel Corporation * Copyright (C) 2013-2015 Intel Mobile Communications GmbH * Copyright (C) 2016-2017 Intel Deutschland GmbH */ @@ -1636,12 +1636,18 @@ static void iwl_mvm_tx_status_check_trigger(struct = iwl_mvm *mvm, * of the batch. This is why the SSN of the SCD is written at the end of t= he * whole struct at a variable offset. This function knows how to cope with= the * variable offset and returns the SSN of the SCD. + * + * For 22000-series and lower, this is just 12 bits. For later, 16 bits. */ static inline u32 iwl_mvm_get_scd_ssn(struct iwl_mvm *mvm, struct iwl_mvm_tx_resp *tx_resp) { - return le32_to_cpup((__le32 *)iwl_mvm_get_agg_status(mvm, tx_resp) + - tx_resp->frame_count) & 0xfff; + u32 val =3D le32_to_cpup((__le32 *)iwl_mvm_get_agg_status(mvm, tx_resp) + + tx_resp->frame_count); + + if (mvm->trans->trans_cfg->device_family >=3D IWL_DEVICE_FAMILY_AX210) + return val & 0xFFFF; + return val & 0xFFF; } =20 static void iwl_mvm_rx_tx_cmd_single(struct iwl_mvm *mvm, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F33FB146003; Sun, 24 Mar 2024 22:37:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319868; cv=none; b=itb1twZ4+Q8LzaHorA7Z1awJSq3978NIr9OrR9axgQLYHqQSlkpigjWf2mu+Qq30Lk0p/3vC/+uFMHQTErLWUs719S6Jo24LGXKH8t2YV3R42dz3diVetx/T0jp56W3qlKZYDh0Q0po4pTKNW7wNXYZmknRg809keXkrdrEvNDE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319868; c=relaxed/simple; bh=qBDDt3UEpEEh1v+s/AaZiH9vTDwgz70LlK5QGjZqtYk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=o5xxcvEev1YFNY6B0zlZfJqNmbryQkRGtXvjbEvMetrtojd5yx6DAUaTKbrYBdz+ouxYF2WDYKHYfdDjkABCxQTTEBDsvdOkNAYXhvQudPpNQmmhl1v3ekgGj0Af1T38bECf4ktvB//h2HoJ3EcXZ7GXA7PKoRCFAy90wqdR/gk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OBKO+7sl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OBKO+7sl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA12CC433F1; Sun, 24 Mar 2024 22:37:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319867; bh=qBDDt3UEpEEh1v+s/AaZiH9vTDwgz70LlK5QGjZqtYk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OBKO+7slTxKBCgh9Vz7djSdm2L9URXoOneQvozyb1s5rJ6zMn4g7deAAsCZdMdr+/ l3x9jXT3IJ4k99hnzlkBFDyBqWCqFtwN1LgION4Aj30HLXYbUro+rnuwBr+fGebvg5 D3VEWxinlTaBfAVWL2ifUO2IhJbw4xtElreJ9SUlIHswYpHglvJlMor/rwN6Mw9iED YkTimyA8pQaButRKuT6A13sg6XZnCanh64ENkB+IdxnRUywt6yLB5RY0nXf08oqMyY DGZtI8JxWXv6yV3hQY7zS/0/qf2LVCIq7XtoOr/s8umsGPmCcdvr6mLSzuAe7dXx3+ brPFbRaRi4HLg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Emmanuel Grumbach , Miri Korenblit , Johannes Berg , Sasha Levin Subject: [PATCH 6.8 172/715] wifi: iwlwifi: mvm: don't set the MFP flag for the GTK Date: Sun, 24 Mar 2024 18:25:51 -0400 Message-ID: <20240324223455.1342824-173-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Emmanuel Grumbach [ Upstream commit e35f316bce9e5733c9826120c1838f4c447b2c4c ] The firmware doesn't need the MFP flag for the GTK, it can even make the firmware crash. in case the AP is configured with: group cipher TKIP and MFPC. We would send the GTK with cipher =3D TKIP and MFP which is of course not possible. Fixes: 5c75a208c244 ("wifi: iwlwifi: mvm: support new key API") Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://msgid.link/20240206175739.2f2c602ab3c6.If13b2e2fa532381d985c0= 7df130bee1478046c89@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../net/wireless/intel/iwlwifi/mvm/mld-key.c | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mld-key.c b/drivers/net= /wireless/intel/iwlwifi/mvm/mld-key.c index ea3e9e9c6e26c..fe4b39b19a612 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/mld-key.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/mld-key.c @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause /* - * Copyright (C) 2022 - 2023 Intel Corporation + * Copyright (C) 2022 - 2024 Intel Corporation */ #include #include @@ -62,11 +62,13 @@ u32 iwl_mvm_get_sec_flags(struct iwl_mvm *mvm, struct ieee80211_key_conf *keyconf) { struct iwl_mvm_vif *mvmvif =3D iwl_mvm_vif_from_mac80211(vif); + bool pairwise =3D keyconf->flags & IEEE80211_KEY_FLAG_PAIRWISE; + bool igtk =3D keyconf->keyidx =3D=3D 4 || keyconf->keyidx =3D=3D 5; u32 flags =3D 0; =20 lockdep_assert_held(&mvm->mutex); =20 - if (!(keyconf->flags & IEEE80211_KEY_FLAG_PAIRWISE)) + if (!pairwise) flags |=3D IWL_SEC_KEY_FLAG_MCAST_KEY; =20 switch (keyconf->cipher) { @@ -96,12 +98,14 @@ u32 iwl_mvm_get_sec_flags(struct iwl_mvm *mvm, if (!sta && vif->type =3D=3D NL80211_IFTYPE_STATION) sta =3D mvmvif->ap_sta; =20 - /* Set the MFP flag also for an AP interface where the key is an IGTK - * key as in such a case the station would always be NULL + /* + * If we are installing an iGTK (in AP or STA mode), we need to tell + * the firmware this key will en/decrypt MGMT frames. + * Same goes if we are installing a pairwise key for an MFP station. + * In case we're installing a groupwise key (which is not an iGTK), + * then, we will not use this key for MGMT frames. */ - if ((!IS_ERR_OR_NULL(sta) && sta->mfp) || - (vif->type =3D=3D NL80211_IFTYPE_AP && - (keyconf->keyidx =3D=3D 4 || keyconf->keyidx =3D=3D 5))) + if ((!IS_ERR_OR_NULL(sta) && sta->mfp && pairwise) || igtk) flags |=3D IWL_SEC_KEY_FLAG_MFP; =20 return flags; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9DA9A14601C; Sun, 24 Mar 2024 22:37:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319868; cv=none; b=I8gI2E15/ph+QvMuUbGL+QhF5AAYec73JpXHKzf5a+60l/pUN7uRNK7l3oayxWd8QMdp06ByhAr9uqD90c1srQCxepzkQq3js97ZIC1UKTpJSqXYmW4Em6QmGZNXiTFZD70pS5iA+yL7bHgYdiKfTnP4R3Rnk77HnyJfg38hSBo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319868; c=relaxed/simple; bh=vRIH/teENEUyKZXX8+33/a5ZC/EJzFWpJ0jYowbh0yQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eqUJCLwfI2oagdSl8WtBEnL7UpSFZ1W3eD5LLy7tIucLrN8HMQFVksRmnERtN+95PrGS5zPdhJ1tX0SwutyedYqplVyFaw3SQrUBlUavn+ZTM+HpUyTBQng7fHrIGlasxTwXg2CiMf7XrTVaEn1j0TNMl0E1ktdS2Id8yy1Olak= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=e40wPAE6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="e40wPAE6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D637CC43390; Sun, 24 Mar 2024 22:37:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319868; bh=vRIH/teENEUyKZXX8+33/a5ZC/EJzFWpJ0jYowbh0yQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=e40wPAE6HfiV9K1GnaKzRF6YhDdzwbHabW9FLzU2ta8iaEvpHv+qKQqHGljsCc4mG TcMF4O1llrxwFanvLkVP767/1i/cWdVBbvfm6fhsVI2gJWonXd3uDnhiKtQxm4hAag GSKRwXoWF/S4jNZjuaK+fZp1TEb4E91ulpW8rkm5xnMWX4yGyQk0X/G2ye7QOFgSxL D1Yar70tMZq9ku4A3WMDFBCYu8lLI7iG/rq0vv3oU+CLJw2oRFS8oUhkaDKgAzkqxI FNhXQROXURwhaCszm7oEXmHfsbpErqsrNDaw+SNNC5GyvLqV+azXMDWU6W3IWLG8oC 0F9ZrtEgzpKpA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johannes Berg , Miri Korenblit , Sasha Levin Subject: [PATCH 6.8 173/715] wifi: iwlwifi: mvm: don't set replay counters to 0xff Date: Sun, 24 Mar 2024 18:25:52 -0400 Message-ID: <20240324223455.1342824-174-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johannes Berg [ Upstream commit d5bd4041cd70faf26fc9a54bd6f172537bbe77f3 ] The firmware (later) actually uses the values even for keys that are invalid as far as the host is concerned, later in rekeying, and then only sets the low 48 bits since the PNs are only 48 bits over the air. It does, however, compare the full 64 bits later, obviously causing problems. Remove the memset and use kzalloc instead to avoid any old heap data leaking to the firmware. We already init all the other fields in the struct anyway. This leaves the data set to zero for any unused fields, so the firmware can look at them safely even if they're not used right now. Fixes: 79e561f0f05a ("iwlwifi: mvm: d3: implement RSC command version 5") Signed-off-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240206175739.462101146fef.I10f3855b99417af4247cf= f04af78dcbc6cb75c9c@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c b/drivers/net/wire= less/intel/iwlwifi/mvm/d3.c index 03d0c9ab73fc0..2a08369238f23 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c @@ -461,12 +461,10 @@ static int iwl_mvm_wowlan_config_rsc_tsc(struct iwl_m= vm *mvm, struct wowlan_key_rsc_v5_data data =3D {}; int i; =20 - data.rsc =3D kmalloc(sizeof(*data.rsc), GFP_KERNEL); + data.rsc =3D kzalloc(sizeof(*data.rsc), GFP_KERNEL); if (!data.rsc) return -ENOMEM; =20 - memset(data.rsc, 0xff, sizeof(*data.rsc)); - for (i =3D 0; i < ARRAY_SIZE(data.rsc->mcast_key_id_map); i++) data.rsc->mcast_key_id_map[i] =3D IWL_MCAST_KEY_MAP_INVALID; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8AA681474B8; Sun, 24 Mar 2024 22:37:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319869; cv=none; b=kR0gDChwuedRSfVH/uNfVjCAVwpgITTUVzHizXvI+qClcOgW6a1c13AOgAxbn1RioBzEs1JqpdFqABItkNR9LKUhlCPWTZ61ryV8xLgM4rFucVQyqtIadcqvwA9NffkX9c/nA2Ag3OWJUVpcURu8BWJKU4kWG4FtBajunXhMxxk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319869; c=relaxed/simple; bh=xZvsKGoR/svHEqZp3qpLgCTKbWwG471nH+E4WozJpus=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rQDV2GeLjuNTiCx+YiqHYuVLqbqTPhUVuDqu2/7MXIvDdisaLaPJampwZPhN4vEtlerxFcTZ3i5U2tb58LZ5QWvU9WHiAiF/tb/y9H4fIui07p37IjCdNMdBtg/jvkpeINGD63bmCuaiADDmkAP0AvaAwqxrJpQHF1/XzH04T/Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qugSufB3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qugSufB3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9843C433A6; Sun, 24 Mar 2024 22:37:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319869; bh=xZvsKGoR/svHEqZp3qpLgCTKbWwG471nH+E4WozJpus=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qugSufB3lcB5u/n14s843SFK+QmLjZA7eApTyMBm89zio4MySYMCozsmu1PjTj6Uf +8grHeCvpPtTrrF2eNQcrZ/v67fmz48fgFQ5/+n1gj4AA8caWOtQwNqxscOfgtK2E1 9/F0tJSnmpVbYCLyJUBqg3vYVg/OMnhzrOJbcak3ZnhfKsAAE0sl3p/gNsGPi+1reE IxolHAm13vtZ+rwNxnWjHw+zJJ5IHsCvHwqpUQK2oROHyTILLxO7vzzPshMV/7UlCK jCVC8jdrsDsRMFVyHmFpfOs9vWr5pqjgYt4erFJXRLO3pqq1VYn3z4LTK6nf7XRSe6 QYxiZex6r8kbQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Thomas Richter , Sumanth Korikkar , Heiko Carstens , Sasha Levin Subject: [PATCH 6.8 174/715] s390/pai: fix attr_event_free upper limit for pai device drivers Date: Sun, 24 Mar 2024 18:25:53 -0400 Message-ID: <20240324223455.1342824-175-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Thomas Richter [ Upstream commit 225d09d6e5f3870560665a1829d2db79330b4c58 ] When the device drivers are initialized, a sysfs directory is created. This contains many attributes which are allocated with kzalloc(). Should it fail, the memory for the attributes already created is freed in attr_event_free(). Its second parameter is number of attribute elements to delete. This parameter is off by one. When i. e. the 10th attribute fails to get created, attributes numbered 0 to 9 should be deleted. Currently only attributes numbered 0 to 8 are deleted. Fixes: 39d62336f5c1 ("s390/pai: add support for cryptography counters") Reported-by: Sumanth Korikkar Signed-off-by: Thomas Richter Acked-by: Sumanth Korikkar Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/s390/kernel/perf_pai_crypto.c | 2 +- arch/s390/kernel/perf_pai_ext.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/s390/kernel/perf_pai_crypto.c b/arch/s390/kernel/perf_pai= _crypto.c index bf8a672b15a41..522a5ea0a9f49 100644 --- a/arch/s390/kernel/perf_pai_crypto.c +++ b/arch/s390/kernel/perf_pai_crypto.c @@ -721,7 +721,7 @@ static int __init attr_event_init(void) for (i =3D 0; i < ARRAY_SIZE(paicrypt_ctrnames); i++) { ret =3D attr_event_init_one(attrs, i); if (ret) { - attr_event_free(attrs, i - 1); + attr_event_free(attrs, i); return ret; } } diff --git a/arch/s390/kernel/perf_pai_ext.c b/arch/s390/kernel/perf_pai_ex= t.c index af7f2b538c8fd..95d1a890640a3 100644 --- a/arch/s390/kernel/perf_pai_ext.c +++ b/arch/s390/kernel/perf_pai_ext.c @@ -611,7 +611,7 @@ static int __init attr_event_init(void) for (i =3D 0; i < ARRAY_SIZE(paiext_ctrnames); i++) { ret =3D attr_event_init_one(attrs, i); if (ret) { - attr_event_free(attrs, i - 1); + attr_event_free(attrs, i); return ret; } } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 823B21474D7; Sun, 24 Mar 2024 22:37:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319870; cv=none; b=ImbxCN+nYQgZS+pjWwGgvsOWU6qlH9y+7bBlo+Ea4yCQ3IvtjK+qef+Wvq1cnensXF0Y7Q7tP79bJViKlwGCch7wOrVpklq5pQ4FEXF+ntardHPvwjYAEoqU+jlJnCdkGSDZTQVC0lk3/HJN31AOsMQAP6+QYaQ0QnCQQqGLxm0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319870; c=relaxed/simple; bh=D+nadqxwlJrpxWU98ynFUoEvId/9NZQwyj9q4BxpIUA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PVsYq6sY4NS+tK3q1BVQASv08n7zoqFX6tCvjD/h6HIV0fiD0IHKwNA8znqe4gVr7/B1NWWetooX7Pz3jRfXo+Sk8E699GFhd/fC2fKhdT4KCm4EQiOvYvnbLA6eST+Xqlm1pGN3jeKMh2Ib5Uxft8tRG6dt/g1n5WuuwjQTiKU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cKVxDvJg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cKVxDvJg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE6E0C433C7; Sun, 24 Mar 2024 22:37:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319870; bh=D+nadqxwlJrpxWU98ynFUoEvId/9NZQwyj9q4BxpIUA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cKVxDvJgTLCoJb4IfP7j+pFgbqIjAEAcScQRMKDZP8sIUizP22INhfpBrXzSjYLIO umn4qxeqFLMP+EG5E50O9eERwogVs07bOca0kXB9PAGZVlOD/alALZGRp/UH5mtxvc 9EYtJO6Flo4tNYbd/yMnXnduUFKAvRRj9oHfzAX6+N/Sm0ushsSyB49UcLUGC9d8QO ZnV+tMnqmpp4KoFoGq8YNJHxo4e4avCUel2hnzDjSXPAc2Vd8OloNLJQ/kBXbDAVdD sPNInlRyFDwnZYyAL0//j7JNvITWEt4o1KhYbFCP4Bh+Mj2vuTR4Dln5dli9I0cRT2 sNm6g2yZTp63Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nathan Chancellor , Fangrui Song , Heiko Carstens , Sasha Levin Subject: [PATCH 6.8 175/715] s390/vdso: drop '-fPIC' from LDFLAGS Date: Sun, 24 Mar 2024 18:25:54 -0400 Message-ID: <20240324223455.1342824-176-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nathan Chancellor [ Upstream commit 0628c03934187be33942580e10bb9afcc61adeed ] '-fPIC' as an option to the linker does not do what it seems like it should. With ld.bfd, it is treated as '-f PIC', which does not make sense based on the meaning of '-f': -f SHLIB, --auxiliary SHLIB Auxiliary filter for shared object symbol tab= le When building with ld.lld (currently under review in a GitHub pull request), it just errors out because '-f' means nothing and neither does '-fPIC': ld.lld: error: unknown argument '-fPIC' '-fPIC' was blindly copied from CFLAGS when the vDSO stopped being linked with '$(CC)', it should not be needed. Remove it to clear up the build failure with ld.lld. Fixes: 2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO") Link: https://github.com/llvm/llvm-project/pull/75643 Signed-off-by: Nathan Chancellor Reviewed-by: Fangrui Song Link: https://lore.kernel.org/r/20240130-s390-vdso-drop-fpic-from-ldflags-v= 1-1-094ad104fc55@kernel.org Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/s390/kernel/vdso32/Makefile | 2 +- arch/s390/kernel/vdso64/Makefile | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/s390/kernel/vdso32/Makefile b/arch/s390/kernel/vdso32/Mak= efile index caec7db6f9668..b12a274cbb473 100644 --- a/arch/s390/kernel/vdso32/Makefile +++ b/arch/s390/kernel/vdso32/Makefile @@ -22,7 +22,7 @@ KBUILD_CFLAGS_32 :=3D $(filter-out -m64,$(KBUILD_CFLAGS)) KBUILD_CFLAGS_32 :=3D $(filter-out -mno-pic-data-is-text-relative,$(KBUILD= _CFLAGS_32)) KBUILD_CFLAGS_32 +=3D -m31 -fPIC -shared -fno-common -fno-builtin =20 -LDFLAGS_vdso32.so.dbg +=3D -fPIC -shared -soname=3Dlinux-vdso32.so.1 \ +LDFLAGS_vdso32.so.dbg +=3D -shared -soname=3Dlinux-vdso32.so.1 \ --hash-style=3Dboth --build-id=3Dsha1 -melf_s390 -T =20 $(targets:%=3D$(obj)/%.dbg): KBUILD_CFLAGS =3D $(KBUILD_CFLAGS_32) diff --git a/arch/s390/kernel/vdso64/Makefile b/arch/s390/kernel/vdso64/Mak= efile index e3c9085f8fa72..caa4ebff8a193 100644 --- a/arch/s390/kernel/vdso64/Makefile +++ b/arch/s390/kernel/vdso64/Makefile @@ -26,7 +26,7 @@ KBUILD_AFLAGS_64 +=3D -m64 KBUILD_CFLAGS_64 :=3D $(filter-out -m64,$(KBUILD_CFLAGS)) KBUILD_CFLAGS_64 :=3D $(filter-out -mno-pic-data-is-text-relative,$(KBUILD= _CFLAGS_64)) KBUILD_CFLAGS_64 +=3D -m64 -fPIC -fno-common -fno-builtin -ldflags-y :=3D -fPIC -shared -soname=3Dlinux-vdso64.so.1 \ +ldflags-y :=3D -shared -soname=3Dlinux-vdso64.so.1 \ --hash-style=3Dboth --build-id=3Dsha1 -T =20 $(targets:%=3D$(obj)/%.dbg): KBUILD_CFLAGS =3D $(KBUILD_CFLAGS_64) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C65D7148300; Sun, 24 Mar 2024 22:37:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319871; cv=none; b=JZihiHpW6xmybtqOiCzdrJ3UUKmgsKMSq2LrrCEWl3/Tlrq+TFtjZZdmiLQlfkv70oN79dhNYs5pkrfC2gq1vHNMmEN8hSM5oxcRC2/6HsvqXH9pQLDBqwvrXiDAv1WemXUEPyBAwTb4dBmnUEN2FbLq+VfSbLrk+aruMw/9a08= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319871; c=relaxed/simple; bh=qduKI41qQjAZO3OgB4mRI0vjBVd4E4BI9n6clwtwL78=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Z5OKvBxkORV1Ye6jrHrAkErG6sUsACwQmLQEqXL5X2xGXBCJdy0d6OGz0rnSmCuLh0+vEOjJz2Pq+L0qW0jY+FQ/x5Gm6BqFbF5pNepvK4USbBhHHM5Vzw5N/tBRvQ30qe4IcbqI5KMplRpywvBLr1ucfqQkF2O+vLJ3IBWFCnM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qkCmBpfz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qkCmBpfz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A742CC433F1; Sun, 24 Mar 2024 22:37:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319871; bh=qduKI41qQjAZO3OgB4mRI0vjBVd4E4BI9n6clwtwL78=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qkCmBpfzQuf6HJTieXMPZu5atmZ1magVF1HGJij6Oh6/vEw6Mz2hv+syhRHp3CGth 1csu3+jCRzTsbTsBISYKfsQfS5MJvq8cW9tkSYGKC9ctPW+8rHnRiPrLOsPZDh4inV nMICocImhuDmk1GxcwLelR0cUO2KP13LPJkYn5TOHQUzEC7c0gf59ne0GjekWGvWVh BzZ3WeDxJ5Ahr0H5F/KlIJQOuW7fjCmQPrFkh9z7p2ojfsPByqVfxNS/Y3J0zo5szl baL8ubB6VPR31IPsbbA32kKI4bz5Zv0hSG7AwL2iMQkEqaOkZYQoXAKHQtTjwAa3mL soCU3hrOOLH2g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Komal Bajaj , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 176/715] arm64: dts: qcom: qcm6490-idp: Correct the voltage setting for vph_pwr Date: Sun, 24 Mar 2024 18:25:55 -0400 Message-ID: <20240324223455.1342824-177-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Komal Bajaj [ Upstream commit aa56130e88de50773f84de4039c7de81ab783744 ] Min and max voltages for vph_pwr should be same, otherwise rpmh will not probe, so correcting the min and max voltages for vph_pwr. Fixes: 9af6a9f32ad0 ("arm64: dts: qcom: Add base qcm6490 idp board dts") Signed-off-by: Komal Bajaj Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231220110015.25378-2-quic_kbajaj@quicinc.= com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts= /qcom/qcm6490-idp.dts index 03e97e27d16d4..74f5a43d53db9 100644 --- a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts +++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts @@ -123,8 +123,8 @@ debug_vm_mem: debug-vm@d0600000 { vph_pwr: vph-pwr-regulator { compatible =3D "regulator-fixed"; regulator-name =3D "vph_pwr"; - regulator-min-microvolt =3D <2500000>; - regulator-max-microvolt =3D <4350000>; + regulator-min-microvolt =3D <3700000>; + regulator-max-microvolt =3D <3700000>; }; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7FAEF148316; Sun, 24 Mar 2024 22:37:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319872; cv=none; b=nw186C+hu4MPF5X/cwShW6pHyQ3YNqN2DgqUF/m8VakIC8mv35LAMQ5mHaY1T9486ixjboPlsrV8VuuKKEJBscgZh4twJiBHTaVBiNzJASfm0oU1tiae7UaQ4NQu9cIXEqF2yYdvC0BcpAVjvF0Zpe4uxZ9gPW8ixsBuS456eis= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319872; c=relaxed/simple; bh=/oBBgZrQ+FEexfLW/rIq/NTI4BG3br/QSuJ8X/PmO1I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CFM3+kQ5FKJqdB+w/wHRH5nGldW5hd+TLdIC30oM+ZZQ8UtoFMFNDGGHZ/PVjkPi9EnUcIfGtYGrTEbhBYNl2F39aooMZ7/qwCK/VP24wg5pW8owVVqcnXiya9kNGNbyI3RPHPFxXdr2XRdS1yiebBVvRtekpf9U/lonnxqsWnU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BNkCe2Jy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BNkCe2Jy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A228DC43399; Sun, 24 Mar 2024 22:37:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319872; bh=/oBBgZrQ+FEexfLW/rIq/NTI4BG3br/QSuJ8X/PmO1I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BNkCe2Jyobb7x+lkHh1TfWPz4uDllJ4Svwbz2R3NrYXK7y+0JiPB2uQi/8BnK7Jqy IKMiPkBMUsIcOWlEIMcDAgT8GUxf+Z0KCjRS2lk++VfbJf/rVjpqo/w3rsAaqxcpbi K0Mg2UNwORskaCuRVkaiWSL1BGV/CvRjQgF5oHlNmKyiTbRahcZgIo2LL8k6hvudvr Ul9x8B4op6MutBFYvHkd1lh+XCGWySxbLpyWyyvq6Eechs7boknflQcw8W/yvIP4a8 FRrO/MwFFtbAa1EDmOFn9/mZlWCK/zWCCjvOcAtR3lT+Hw+6CSRjfB3QBgmX7yYEoU 95ezz+jgvIAEg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Komal Bajaj , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 177/715] arm64: dts: qcom: qcs6490-rb3gen2: Correct the voltage setting for vph_pwr Date: Sun, 24 Mar 2024 18:25:56 -0400 Message-ID: <20240324223455.1342824-178-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Komal Bajaj [ Upstream commit 05f439c0e64b877c1f9cc7f0bed894b6df45d43d ] Min and max voltages for vph_pwr should be same, otherwise rpmh will not probe, so correcting the min and max voltages for vph_pwr. Fixes: 04cf333afc75 ("arm64: dts: qcom: Add base qcs6490-rb3gen2 board dts") Signed-off-by: Komal Bajaj Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231220110015.25378-3-quic_kbajaj@quicinc.= com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot= /dts/qcom/qcs6490-rb3gen2.dts index 8bb7d13d85f66..ae1632182d7c1 100644 --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts @@ -124,8 +124,8 @@ debug_vm_mem: debug-vm@d0600000 { vph_pwr: vph-pwr-regulator { compatible =3D "regulator-fixed"; regulator-name =3D "vph_pwr"; - regulator-min-microvolt =3D <2500000>; - regulator-max-microvolt =3D <4350000>; + regulator-min-microvolt =3D <3700000>; + regulator-max-microvolt =3D <3700000>; }; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 58CF91487D1; Sun, 24 Mar 2024 22:37:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319873; cv=none; b=R+4MPjeHaR5BOQnOqHkHktgtiPNNgECPcMJl7QqE8oI1oDA5QmQyPLrbv+Rm05CJvW7bqkagV/vYU22DvLGdKOF9wh89j7zBDVA768J649q3szG4RTf/b1A0ktOoQaeovH5iDin+fBSfBkeeU1NaStweezhufk0LhiBag65t3aA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319873; c=relaxed/simple; bh=of02US8bUUeHmltBhwO0q0jgCHO9nnXXigQFqbU83BU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ULa7ioaxFcD3qDF0uJSMPC7uMgRmbjc/UxkwxYRfIBvm99eZYhb+JS40Acg8UYWvQ/2wqWPFTA2Xs0pf/lgovcAXhNpwy2uxYY8vQWolX4GMOm+D8a6nSxn4cgpf6ww7/Qh3ZQ0BFPDE++KHzLPmPaKyZNxC3p0RAKJ6GmaqCrg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f9JqIpQu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="f9JqIpQu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9D450C433C7; Sun, 24 Mar 2024 22:37:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319873; bh=of02US8bUUeHmltBhwO0q0jgCHO9nnXXigQFqbU83BU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f9JqIpQup9qw13yc7zZmx/gAkceQXh3ygNHBeVtn9hIlHw7lZMWzEkQyOnqvCBgBX ZVVMZAr40IwuO+FLtddxPMbtVmBr3bNqfJOJSf+9bcUxjWfTM4TqVfBjjVlNSh7iyp K+hgaS36vGmugmoxc+8P8iYucjnbQ9NhA49/4thBFZto7OzR6KsseEbzXZd1VnKI0A +vBvjX+VXjoH27E0O8G0My4Cg10MSHIyESZenU2TwXVbNKE7McyweGsEs2dA5dS9sr DLzxYnOO7tcc573OxewXNHYEJ2H4+X9xD/oq1+pHmJaX+3stDCkOWhZnv1eyEaHcYV 8hZqjHHzjBxbg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Petr Machata , Paolo Abeni , Sasha Levin Subject: [PATCH 6.8 178/715] selftests: forwarding: Add missing config entries Date: Sun, 24 Mar 2024 18:25:57 -0400 Message-ID: <20240324223455.1342824-179-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Petr Machata [ Upstream commit 4acf4e62cd572b0c806035046b3698f5585ab821 ] The config file contains a partial kernel configuration to be used by `virtme-configkernel --custom'. The presumption is that the config file contains all Kconfig options needed by the selftests from the directory. In net/forwarding/config, many are missing, which manifests as spurious failures when running the selftests, with messages about unknown device types, qdisc kinds or classifier actions. Add the missing configurations. Tested the resulting configuration using virtme-ng as follows: # vng -b -f tools/testing/selftests/net/forwarding/config # vng --user root (within the VM:) # make -C tools/testing/selftests TARGETS=3Dnet/forwarding run_tests Signed-off-by: Petr Machata Link: https://lore.kernel.org/r/025abded7ff9cea5874a7fe35dcd3fd41bf5e6ac.17= 06286755.git.petrm@nvidia.com Signed-off-by: Paolo Abeni Stable-dep-of: f0ddf15f0a74 ("selftests: forwarding: Add missing multicast = routing config entries") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/testing/selftests/net/forwarding/config | 28 +++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/tools/testing/selftests/net/forwarding/config b/tools/testing/= selftests/net/forwarding/config index 697994a9278bb..ba23435145827 100644 --- a/tools/testing/selftests/net/forwarding/config +++ b/tools/testing/selftests/net/forwarding/config @@ -6,14 +6,42 @@ CONFIG_IPV6_MULTIPLE_TABLES=3Dy CONFIG_NET_VRF=3Dm CONFIG_BPF_SYSCALL=3Dy CONFIG_CGROUP_BPF=3Dy +CONFIG_DUMMY=3Dm +CONFIG_IPV6=3Dy +CONFIG_IPV6_GRE=3Dm +CONFIG_MACVLAN=3Dm CONFIG_NET_ACT_CT=3Dm CONFIG_NET_ACT_MIRRED=3Dm CONFIG_NET_ACT_MPLS=3Dm +CONFIG_NET_ACT_PEDIT=3Dm +CONFIG_NET_ACT_POLICE=3Dm +CONFIG_NET_ACT_SAMPLE=3Dm +CONFIG_NET_ACT_SKBEDIT=3Dm +CONFIG_NET_ACT_TUNNEL_KEY=3Dm CONFIG_NET_ACT_VLAN=3Dm CONFIG_NET_CLS_FLOWER=3Dm CONFIG_NET_CLS_MATCHALL=3Dm +CONFIG_NET_CLS_BASIC=3Dm +CONFIG_NET_EMATCH=3Dy +CONFIG_NET_EMATCH_META=3Dm +CONFIG_NET_IPGRE=3Dm +CONFIG_NET_IPGRE_DEMUX=3Dm +CONFIG_NET_IPIP=3Dm +CONFIG_NET_SCH_ETS=3Dm CONFIG_NET_SCH_INGRESS=3Dm CONFIG_NET_ACT_GACT=3Dm +CONFIG_NET_SCH_PRIO=3Dm +CONFIG_NET_SCH_RED=3Dm +CONFIG_NET_SCH_TBF=3Dm +CONFIG_NET_TC_SKB_EXT=3Dy +CONFIG_NET_TEAM=3Dy +CONFIG_NET_TEAM_MODE_LOADBALANCE=3Dy +CONFIG_NETFILTER=3Dy +CONFIG_NF_CONNTRACK=3Dm +CONFIG_NF_FLOW_TABLE=3Dm +CONFIG_NF_TABLES=3Dm CONFIG_VETH=3Dm CONFIG_NAMESPACES=3Dy CONFIG_NET_NS=3Dy +CONFIG_VXLAN=3Dm +CONFIG_XFRM_USER=3Dm --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AC9AA1487F8; Sun, 24 Mar 2024 22:37:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319874; cv=none; b=K+k38jpZcRJhnsxDO09mSQBy+9UYTtk9T03EjeQFhHmOskglGDUvE5FkbIUDOQkgH1C8l/k6k2yOgHsexRZ7u2RsLbfNNpeh1ysryTaz4BuK4oAxQlqHODu1B9rb5DO2GwqXIvYHXIjJsJ+nDO58zhZ6dchgeTO/bHr4LDqdgjc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319874; c=relaxed/simple; bh=PixZTdAIXb+apt1+3VrFpubrgiRaiLYdNla0aHXf+/Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=V2WSqW5YGXHjKTccizDtQoqnJ3jOKZcjldBfVnDX/Rss38nbXLORnZV+Ov93xjXfu/3Z9vAXUizUS68LXXj0wZX/y9ygYJGdXRRR2n3Vfx+nrf16PkNDHwRumzPOKQ3od1018xfbhzfQhRJHb/sIxNdTjWjhFVamlYCHCAEN6YE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JKJy8KXS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JKJy8KXS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D4A2C433F1; Sun, 24 Mar 2024 22:37:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319874; bh=PixZTdAIXb+apt1+3VrFpubrgiRaiLYdNla0aHXf+/Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JKJy8KXS6g8NwWxJfYCq3AqkcVWjmBfCSARm7Lk4HCw3urdpu9cIUKUJHoHn7LRNU 5DU2xvxWPyz1pANRz4DljkKmnhoD9PeaF3HdmqS9Djd5WStaWXoDWRbFs+eB0rYXJL 49B2VbY85IcgbTneTAyQ762eqOlFnJphpyz1xqW38p1mIHPBgAXwt+5jnyBQWpDFL7 ZgbciDmuhBosGSLnkfOQurl6r4Qyv+/MzRgRl4DkHLbGIP+Npk8QBXBd5VQaitHGxz fEtov+CaLea7/Bekc3c8frhrl7FVLScGVdyNIsjLP9GDt8WIrT7+mdzJANxg036+LG dfSaFBuOlAI1Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ido Schimmel , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.8 179/715] selftests: forwarding: Add missing multicast routing config entries Date: Sun, 24 Mar 2024 18:25:58 -0400 Message-ID: <20240324223455.1342824-180-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ido Schimmel [ Upstream commit f0ddf15f0a74c27eb4b2271a90e69948acc3fa2c ] The two tests that make use of multicast routig (router.sh and router_multicast.sh) are currently failing in the netdev CI because the kernel is missing multicast routing support. Fix by adding the required config entries. Fixes: 6d4efada3b82 ("selftests: forwarding: Add multicast routing test") Signed-off-by: Ido Schimmel Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240208165538.1303021-1-idosch@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/testing/selftests/net/forwarding/config | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/tools/testing/selftests/net/forwarding/config b/tools/testing/= selftests/net/forwarding/config index ba23435145827..8d7a1a004b7c3 100644 --- a/tools/testing/selftests/net/forwarding/config +++ b/tools/testing/selftests/net/forwarding/config @@ -9,6 +9,13 @@ CONFIG_CGROUP_BPF=3Dy CONFIG_DUMMY=3Dm CONFIG_IPV6=3Dy CONFIG_IPV6_GRE=3Dm +CONFIG_IPV6_MROUTE=3Dy +CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=3Dy +CONFIG_IPV6_PIMSM_V2=3Dy +CONFIG_IP_MROUTE=3Dy +CONFIG_IP_MROUTE_MULTIPLE_TABLES=3Dy +CONFIG_IP_PIMSM_V1=3Dy +CONFIG_IP_PIMSM_V2=3Dy CONFIG_MACVLAN=3Dm CONFIG_NET_ACT_CT=3Dm CONFIG_NET_ACT_MIRRED=3Dm --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 821FF148FF1; Sun, 24 Mar 2024 22:37:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319875; cv=none; b=EiSSTkahxIpl2WH3UxCDoH6bdwnmtUiIR0e2/d8/I3am42r4ITHwaUUsN/ZVD+FcNan/47qG/VuN3LZC0hsUBELuECsAvO1LXZUEwxa8Q1l7PFt3LN8dmI6QWNFKCXdxpcuPNyNy/j/dOCSITyXBl3oUpHv5LcWqhxtf71FPLks= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319875; c=relaxed/simple; bh=krVTbJ8AJBoOHI4fjxKAGFx/O03ugBxGshBY+MbovKM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cA0e4BrouA8yYdPXVyhBlcphxtxL8SECNM6SsLU/3icu267r7wU03mWCAI6QQeExm8L/GqhtJ5ixJQCIXN3UeJo+Kclz3r85ngdgy5Yhoz1Jd1RBPFaK3H2HsJtiEhFEl11/qex7Nt6f1NPoWiwnVsUTkACNnPBsft8YvtLne20= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BU96WHjJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BU96WHjJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 78B14C433B1; Sun, 24 Mar 2024 22:37:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319875; bh=krVTbJ8AJBoOHI4fjxKAGFx/O03ugBxGshBY+MbovKM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BU96WHjJ5ZN39l0VKNNC1WFOFjlCgcx/J7qaiNV+IowasQ+PFa5XATU2GJV0oGdh/ 8NATkuoS/xsN3quWl8Cv50fVmAmemO+hBh5ElvwW4GTAdncHThE9xmXvnPxf+NFIYw 8ncKAMP1tqnQxmFwN65UjyWQ2LpLF0TaU+SqFtI9RJ+527I0FOoAMgtiE2W/9u+CdW u+bOfyoBKWCtOzC0RZFVe+ho1BmQWan57XPlmyV9fj+gLQCTUrnfDxn+kfpVYvoe1N natcgctCUyKFWY8kA9Vue/9dlha9xvji9eZSll3VtmIS0C3RlRAKDra7lglnJyB+Cy xgysZVyLz4Krw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vladimir Zapolskiy , Konrad Dybcio , Luca Weiss , Dmitry Baryshkov , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 180/715] arm64: dts: qcom: sm6115: drop pipe clock selection Date: Sun, 24 Mar 2024 18:25:59 -0400 Message-ID: <20240324223455.1342824-181-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vladimir Zapolskiy [ Upstream commit 7e3a1f6470f7243c81156d2ead60f87da1184225 ] Stop selecting UTMI clock as the USB3 PIPE clock. This setting is incompatible with the USB host working in USB3 (SuperSpeed) mode. While we are at it, also drop the default setting for the port speed. Fixes: 9dd5f6dba729 ("arm64: dts: qcom: sm6115: Add USB SS qmp phy node") Signed-off-by: Vladimir Zapolskiy [DB: fixed commit message, dropped dr_mode setting] Reviewed-by: Konrad Dybcio Tested-by: Luca Weiss # sdm632-fairphone-fp3 Signed-off-by: Dmitry Baryshkov Link: https://lore.kernel.org/r/20240130-pmi632-typec-v3-5-b05fe44f0a51@lin= aro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/qrb4210-rb2.dts | 4 ---- arch/arm64/boot/dts/qcom/sm6115.dtsi | 1 - 2 files changed, 5 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/qrb4210-rb2.dts b/arch/arm64/boot/dts= /qcom/qrb4210-rb2.dts index 7c19f874fa716..52f31f3166c2f 100644 --- a/arch/arm64/boot/dts/qcom/qrb4210-rb2.dts +++ b/arch/arm64/boot/dts/qcom/qrb4210-rb2.dts @@ -607,10 +607,6 @@ &usb { status =3D "okay"; }; =20 -&usb_dwc3 { - maximum-speed =3D "super-speed"; -}; - &usb_hsphy { vdd-supply =3D <&vreg_l4a_0p9>; vdda-pll-supply =3D <&vreg_l12a_1p8>; diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qco= m/sm6115.dtsi index b627c473ffa54..d33763d092659 100644 --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi @@ -1610,7 +1610,6 @@ &bimc SLAVE_EBI_CH0 RPM_ALWAYS_TAG>, interconnect-names =3D "usb-ddr", "apps-usb"; =20 - qcom,select-utmi-as-pipe-clk; status =3D "disabled"; =20 usb_dwc3: usb@4e00000 { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4991149016; Sun, 24 Mar 2024 22:37:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319876; cv=none; b=F6uabqV88RCW3vy89hBl9+PT4qIfLJJTJHqbfslzipoDwRNREsd4t8w1gztxV8PyWy/QV/FsBAyQjVUN7U50hLe5QrLvCgDim00xu1AKn5hQ2ihPPOraZ26HreLefyHalPs+zdzJ1Pf+1KJ95sOras1rc/L+XplCe8F8JI+C8TQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319876; c=relaxed/simple; bh=ATExb8dnzR1+3OF1sfOlEjOUy1xTMLsnkXvdaxfAZEA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jV6D+vY7BRosyO6BguGGfRwk/p7ROlUSwEXQqtLmN2AqD0FnbZzUPtoJRUnHo6pXLiGR1YA0Uoxxz5xxgcMgQ7yg0ZMiY9+vZlpZXHI2NO+OtMbFzVAaKY49LRSJa+r36+EMLgfbnx955yPwzKgWygKh/SIbV8w9pw+Iw/8oSpg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eAbPLGle; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eAbPLGle" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7767C43399; Sun, 24 Mar 2024 22:37:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319876; bh=ATExb8dnzR1+3OF1sfOlEjOUy1xTMLsnkXvdaxfAZEA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eAbPLGlejuyehHCaUA9F1MUk63O3VdhoAwqRhD4Lyysgs9SrWI/FzJ6aRKJEzDfIG szRyZjzj6vTqDolKEWUijnC25H6DXgO1W5UnSCCtDDp3ISsrwjrQ0V+PpEMKvtdtub 2KQtKGv3v0CXu/6fP7QhZ4em5F4qF1uClp0ajFWfzAUqDnPHXmNzJifEdbigTGexs3 X8ruDmQWra17DPP6y31e8fKxBFCnSkMSyotWltqoIQwolQpEB15a9iOoc7rbQ6Ms1B /kwYnGAw0LHy5vzr3vsPGpCt6uZnsPM7OWgp0lMKKeoiAbsAlo4J+KPLk9mifr60Uc EZbGPZJj71DHA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , Taehee Yoo , Cong Wang , David Ahern , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 181/715] ipv6: mcast: remove one synchronize_net() barrier in ipv6_mc_down() Date: Sun, 24 Mar 2024 18:26:00 -0400 Message-ID: <20240324223455.1342824-182-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit 17ef8efc00b34918b966388b2af0993811895a8c ] As discussed in the past (commit 2d3916f31891 ("ipv6: fix skb drops in igmp6_event_query() and igmp6_event_report()")) I think the synchronize_net() call in ipv6_mc_down() is not needed. Under load, synchronize_net() can last between 200 usec and 5 ms. KASAN seems to agree as well. Fixes: f185de28d9ae ("mld: add new workqueues for process mld events") Signed-off-by: Eric Dumazet Cc: Taehee Yoo Cc: Cong Wang Cc: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/ipv6/mcast.c | 1 - 1 file changed, 1 deletion(-) diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c index bc6e0a0bad3c1..76ee1615ff2a0 100644 --- a/net/ipv6/mcast.c +++ b/net/ipv6/mcast.c @@ -2719,7 +2719,6 @@ void ipv6_mc_down(struct inet6_dev *idev) /* Should stop work after group drop. or we will * start work again in mld_ifc_event() */ - synchronize_net(); mld_query_stop_work(idev); mld_report_stop_work(idev); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE889149DF2; Sun, 24 Mar 2024 22:37:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319877; cv=none; b=goo7yiJFUQZADg8OBfTvID65kkRXy5iQ1hzO89VY262nSz1EkKkwqVXSkrmLui8mpxnbZyMomtHNd4cJNPZOYxyOlQ81jIhD6OrHafNRkSwiR72xZLsvujBY3jySc5vgdeuNctZ5kaN5b0mQUEFOoDWA40hVfWB/b0FmX3zk9XA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319877; c=relaxed/simple; bh=uFJCPcfK3HiaF30YI8WVLqKDVaeGAnvAx86TI/xeRLg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=tbVcdF3NbxfXaSoUOB9ll9t259DUwQ7YAm5QhOD3ou1hPsSsXWq1PbUJf5seHoG/EisNp8z2qi+ExeSxumFaUYbQmTTN8u6cTtw9VIw3VE4w1jnF1dc45Taiae4Lxe6uoDdr0twL1nD8gkSyvwxP0UNPjrauIfKSx9wMiIwCmpU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Gj+Cb/m8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Gj+Cb/m8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D25F6C433C7; Sun, 24 Mar 2024 22:37:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319877; bh=uFJCPcfK3HiaF30YI8WVLqKDVaeGAnvAx86TI/xeRLg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Gj+Cb/m8D2f4mqxRpVOdU9B0kV6xx0Se9EQB4TkOjvKK0zAyekJb1XLHxzYoeS0gX gSR+bnYw0HrE3LCNiyiNuUtoF8lrj61ywgVIZAoEvzZdtUPFU1iA4gno4llO4+/lpV YUz2gqyw+I6WIAO7DGW+rxqDWX+ykBMQVgy8h7bbqQ/XTM7x8t3D/+u5Z38Cu4D+6d U6PUWotG6Tv3ffrApN+ILZnFhEbyEYPGQBoIfA2Y1h1QvVnPq8h5726mAxZDiyiZDf QtfLa98eaxqgdsuyiSwDibuRdLn4vS4R4HoFdTujjd+BIn4FpSSajSunNSwZL7WAsC r2kJ3E0p+4jtw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= , AngeloGioacchino Del Regno , Matthias Brugger , Sasha Levin Subject: [PATCH 6.8 182/715] arm64: dts: mt8183: Move CrosEC base detection node to kukui-based DTs Date: Sun, 24 Mar 2024 18:26:01 -0400 Message-ID: <20240324223455.1342824-183-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: N=C3=ADcolas F. R. A. Prado [ Upstream commit 04bd6411f506357fd1faedc2b2156e7ef206aa9a ] The cbas node is used to describe base detection functionality in the ChromeOS EC, which is used for units that have a detachable keyboard and thus rely on this functionality to switch between tablet and laptop mode. Despite the original commit having added the cbas node to the mt8183-kukui.dtsi, not all machines that include it are detachables. In fact all machines that include from mt8183-kukui-jacuzzi.dtsi are either clamshells (ie normal laptops) or convertibles, meaning the keyboard can be flipped but not detached. The detection for the keyboard getting flipped is handled by the driver bound to the keyboard-controller node in the EC. Move the base detection node from the base kukui dtsi to the dtsis where all machines are detachables, and thus actually make use of the node. Fixes: 4fa8492d1e5b ("arm64: dts: mt8183: add cbas node under cros_ec") Signed-off-by: N=C3=ADcolas F. R. A. Prado Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240116-mt8183-kukui-cbas-remove-v3-1-055e= 21406e86@collabora.com Signed-off-by: Matthias Brugger Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi | 4 ++++ arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi | 4 ++++ arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi | 4 ++++ arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 4 ---- 4 files changed, 12 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi b/arch/a= rm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi index b6a9830af2696..bfb9e42c8acaa 100644 --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kakadu.dtsi @@ -360,6 +360,10 @@ pen_eject { }; =20 &cros_ec { + cbas { + compatible =3D "google,cros-cbas"; + }; + keyboard-controller { compatible =3D "google,cros-ec-keyb-switches"; }; diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi b/arch/a= rm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi index 306c95166f3fe..5c1bf6a1e4758 100644 --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-kodama.dtsi @@ -339,6 +339,10 @@ touch_pin_reset: pin_reset { }; =20 &cros_ec { + cbas { + compatible =3D "google,cros-cbas"; + }; + keyboard-controller { compatible =3D "google,cros-ec-keyb-switches"; }; diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi b/arch/ar= m64/boot/dts/mediatek/mt8183-kukui-krane.dtsi index 382e4c6d7191c..0f5fa893a7742 100644 --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui-krane.dtsi @@ -343,6 +343,10 @@ rst_pin { }; =20 &cros_ec { + cbas { + compatible =3D "google,cros-cbas"; + }; + keyboard-controller { compatible =3D "google,cros-ec-keyb-switches"; }; diff --git a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi b/arch/arm64/bo= ot/dts/mediatek/mt8183-kukui.dtsi index 1b3396b1cee39..90c5ad917a9ba 100644 --- a/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi @@ -937,10 +937,6 @@ usbc_extcon: extcon0 { google,usb-port-id =3D <0>; }; =20 - cbas { - compatible =3D "google,cros-cbas"; - }; - typec { compatible =3D "google,cros-ec-typec"; #address-cells =3D <1>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BADCF149E10; Sun, 24 Mar 2024 22:37:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319878; cv=none; b=W4BGHwrM4I/x17cO09aYS4lS69d7SjPIYuXkYPM7JLVFqVf3VsqM0icR6DGUw1QPOeGrDwFpoiM4kYgFH78z0nphzfNRI9grRytTawzHfI8V8LTDfpRLpadrG/SnIBg18NhbWvk/oelFlW8aZs4NoU+eaNv7Z4TtdMY1LGC7ddo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319878; c=relaxed/simple; bh=9Ax1Uj1kIBKrtW1PQ7nHwXAUOFdXzJH6pmIS0VM1ePU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OZu6imGGRgkWrYnhOzRt/POODXVYd6inUMfh+yz6p27pGdgMlRORtqAa2Va59GUV6PXy5SMzjkoTXlb44ncZj1r8kva7VJjeW5kzm+6/Z9S6EeUFmn4YQYsG26NNKo3Qxf04tR4lQEAi5b3DtF39FoznXCwBi8hvr352dmYNeww= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HRZTH+4N; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HRZTH+4N" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBBA7C433F1; Sun, 24 Mar 2024 22:37:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319878; bh=9Ax1Uj1kIBKrtW1PQ7nHwXAUOFdXzJH6pmIS0VM1ePU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HRZTH+4NjIA6NY9nBD1GAczpwaLeceXDdrEkzaUXEUxCPTWywp1UGvdYjKatvgrZF p2Dhb7XXzIJgjqOhBhq4R1XIZEMFXOodAKj5nY+s/TsFozxm2IebJ137l0bQvGJUL3 tNDiz9sOqzVtIYvxZYE5qsTas+D1apFazVXEbrt6dKmf6lfsMJJizg2OgnKMOqL2uT /hBjhn4XfkjkKZic46IN1QUFYlRT6rzfhEVDRapXT7fkLRnxgDJXjPQMuXVA00SXVA jJJJxsdgS5yWEafKZj6DTfx3QxdznyGLk7vAxGc90BaHSn1EPOhMJMXwDMFumBuHle 3wRmwb6obpWSg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= , Daniel Golle , AngeloGioacchino Del Regno , Matthias Brugger , Sasha Levin Subject: [PATCH 6.8 183/715] arm64: dts: mediatek: mt7986: fix reference to PWM in fan node Date: Sun, 24 Mar 2024 18:26:02 -0400 Message-ID: <20240324223455.1342824-184-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Rafa=C5=82 Mi=C5=82ecki [ Upstream commit 7865abbbdf1e1ee57a0bb8ec83079f8840c16854 ] This fixes typo and resolves following validation error: arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: pwm-fan: pwms: [[= 54, 0, 10000], [0]] is too long from schema $id: http://devicetree.org/schemas/hwmon/pwm-fan.yaml# Fixes: c26f779a2295 ("arm64: dts: mt7986: add pwm-fan and cooling-maps to B= PI-R3 dts") Cc: Daniel Golle Signed-off-by: Rafa=C5=82 Mi=C5=82ecki Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20231116130816.4932-1-zajec5@gmail.com Signed-off-by: Matthias Brugger Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts b/arc= h/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts index d06d4af43cbff..e04b1c0c0ebbf 100644 --- a/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts +++ b/arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dts @@ -43,7 +43,7 @@ fan: pwm-fan { #cooling-cells =3D <2>; /* cooling level (0, 1, 2) - pwm inverted */ cooling-levels =3D <255 96 0>; - pwms =3D <&pwm 0 10000 0>; + pwms =3D <&pwm 0 10000>; status =3D "okay"; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 161A414A091; Sun, 24 Mar 2024 22:37:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319880; cv=none; b=C65oHnTmf3j0Y8iyEoMWFeojl6+BBdvw4O3DDLn4YS/GE4xXeHNqDyZUTaZJePOj/3h+ds77+ZoPQGuTD+uWEYiHZDw3Bg2q7biXJB4yTyOSCgtrNcF3IAlxWGetR+YCCsbHEx0RshFdps2Y83+aBZUMszr3MVC3Unke4/3xQEI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319880; c=relaxed/simple; bh=/Cgj1l+Rb/KLXPOO1028JhYLxPr473Y7ZEhHjRqRylU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=V1LzNjFlkLhKgfiG7wZ4BQoEmrRZ4D9v5tasAwjz1ehhbkPI2Lvrlkf/5pdJYT0O4+UsBUlvMXLshIegmea8SvAymEbwMskYK3O3BpFbhoic7Sosd1stTrKoVsY4G1DVZDqhyAeiMICi5mWMsjx3e0Vit3BF9leCKuq727aWenw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DV3TyEzE; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DV3TyEzE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0711C433C7; Sun, 24 Mar 2024 22:37:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319879; bh=/Cgj1l+Rb/KLXPOO1028JhYLxPr473Y7ZEhHjRqRylU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DV3TyEzE0ERD0V4hXLLMGdkNBH6qw/xLbOeSfAA78AEgdsSSVTqUcxRTter3Kxgnh MqFyGG88MSLyPcOnPvjeVhaV4tencVpOWejrisq2DefAeW+Gz5hNynbL+F2uhN6fmD 3jm9p1MhLmChDsO+7J0gaa/V2yP1c5qqZSXWSYwOgTlQXW21kSWAe4PblU3xRiLEFg 28ggvYKlDZo+5KSUVIX5YeG64MAo9Nr/z6+RSsz9M8qGJyNthgYR9NQYUFvtvG6D8Q m0xG+bLwLIO7cnmbE0r/ZGK3jnzyMNqIRZ7dT8Glas2nPc8dcW+RfwER+ijVCFzwHv FdW6sYEQZfFFA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= , Sam Shih , AngeloGioacchino Del Regno , Matthias Brugger , Sasha Levin Subject: [PATCH 6.8 184/715] arm64: dts: mediatek: mt7986: drop crypto's unneeded/invalid clock name Date: Sun, 24 Mar 2024 18:26:03 -0400 Message-ID: <20240324223455.1342824-185-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Rafa=C5=82 Mi=C5=82ecki [ Upstream commit bb69d19c649669f700149df309245cd925612f7c ] According to the "inside-secure,safexcel-eip97" binding "clock-names" is required only if there are two clocks specified. If present the first name must by "core". Name "infra_eip97_ck" is invalid and was probably just a typo. Drop it. Fixes: ecc5287cfe53 ("arm64: dts: mt7986: add crypto related device nodes") Cc: Sam Shih Signed-off-by: Rafa=C5=82 Mi=C5=82ecki Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20231116132411.7665-1-zajec5@gmail.com Signed-off-by: Matthias Brugger Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi b/arch/arm64/boot/dt= s/mediatek/mt7986a.dtsi index fc751e049953c..a7d9c3246a875 100644 --- a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi @@ -234,7 +234,6 @@ crypto: crypto@10320000 { ; interrupt-names =3D "ring0", "ring1", "ring2", "ring3"; clocks =3D <&infracfg CLK_INFRA_EIP97_CK>; - clock-names =3D "infra_eip97_ck"; assigned-clocks =3D <&topckgen CLK_TOP_EIP_B_SEL>; assigned-clock-parents =3D <&apmixedsys CLK_APMIXED_NET2PLL>; status =3D "disabled"; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9DCE14A0A9; Sun, 24 Mar 2024 22:38:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319880; cv=none; b=m4Chb8BzaS5rZsRSJ0K5rBPSidXclG0ipWQ3YOMCUruIitR1gnNfHQ/zk29AVNrTCnzcAy3fkJQzyzkReHEFFfXq5WJafpL2W3nQNSpBwz8PtGA5C8X29oRQyb7X/RfuFO4fITtOh5Gp2peAC75XwFAo+cUnS9pqmDJTynpj8/E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319880; c=relaxed/simple; bh=dX+p9aq8ZTnlef2Gmg+V8hnuIMD3+xTYM25f1+TPgKM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=KyLVvPLFFAUNfDKh2xk6qdtfunvOprQzttA80ktgS10gQj40F+mb9ggH3EJokhvrYgOL3AR3TVSyJyAGjs61FRtmtfoyNAof9E7vWLFCLYaM+ibV/ZDFUTdGqfOfc5uXB3Xl7TRi859eopX92/86fMmypPiyLWwTWtad9GYIVFM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I7+4GHY/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I7+4GHY/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F2E82C43394; Sun, 24 Mar 2024 22:37:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319880; bh=dX+p9aq8ZTnlef2Gmg+V8hnuIMD3+xTYM25f1+TPgKM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I7+4GHY/v7YveokmqshX03WITxFufE/YO8QWxul3f+6yc1v1txM/M0k1w9CFANfaf tG8bERJku4j/8S08wQMKTCRwYD6pKTSBvIiLEDwNu+Jkv76nZ2ZrjsWxfzapmz4GyL BtIiRY7Dm43e0QE4rhFoUZyRdA7T7or8VxtYNWtD4FM6sGKuB+hpwKm5fcs46i6dE3 tBMSEg0Nlv+vGaiNlYPlUMcfrpY3oeFORjHqSYFW2C5NMZPnZOnOAp/855lPWdaR8x HPwHW93vMm8zs3CYZid5kbTCEHBfleiboegQPUcdZToFacxC/NdDe+SkTuSQGkmWJ0 hQzx2qqOxwCIw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= , AngeloGioacchino Del Regno , Matthias Brugger , Sasha Levin Subject: [PATCH 6.8 185/715] arm64: dts: mediatek: mt7986: fix SPI bus width properties Date: Sun, 24 Mar 2024 18:26:04 -0400 Message-ID: <20240324223455.1342824-186-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Rafa=C5=82 Mi=C5=82ecki [ Upstream commit 4e7dc18a753cec130b06f1ddbae10ea9dcfb1723 ] This fixes SPI setup and resolves following validation errors: arch/arm64/boot/dts/mediatek/mt7986a-rfb.dtb: spi_nand@0: Unevaluated prope= rties are not allowed ('spi-rx-buswidth', 'spi-tx-buswidth' were unexpected) from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml# arch/arm64/boot/dts/mediatek/mt7986b-rfb.dtb: spi_nand@0: Unevaluated prope= rties are not allowed ('spi-rx-buswidth', 'spi-tx-buswidth' were unexpected) from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml# Fixes: 885e153ed7c1 ("arm64: dts: mt7986: add spi related device nodes") Signed-off-by: Rafa=C5=82 Mi=C5=82ecki Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20231116130952.5099-1-zajec5@gmail.com Signed-off-by: Matthias Brugger Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts | 4 ++-- arch/arm64/boot/dts/mediatek/mt7986b-rfb.dts | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts b/arch/arm64/boot= /dts/mediatek/mt7986a-rfb.dts index 3ef371ca254e8..bcb3ebb85d708 100644 --- a/arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts +++ b/arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts @@ -241,8 +241,8 @@ spi_nand: spi_nand@0 { compatible =3D "spi-nand"; reg =3D <0>; spi-max-frequency =3D <10000000>; - spi-tx-buswidth =3D <4>; - spi-rx-buswidth =3D <4>; + spi-tx-bus-width =3D <4>; + spi-rx-bus-width =3D <4>; }; }; =20 diff --git a/arch/arm64/boot/dts/mediatek/mt7986b-rfb.dts b/arch/arm64/boot= /dts/mediatek/mt7986b-rfb.dts index dde190442e386..48fe50e671779 100644 --- a/arch/arm64/boot/dts/mediatek/mt7986b-rfb.dts +++ b/arch/arm64/boot/dts/mediatek/mt7986b-rfb.dts @@ -156,8 +156,8 @@ spi_nand: spi_nand@0 { compatible =3D "spi-nand"; reg =3D <0>; spi-max-frequency =3D <10000000>; - spi-tx-buswidth =3D <4>; - spi-rx-buswidth =3D <4>; + spi-tx-bus-width =3D <4>; + spi-rx-bus-width =3D <4>; }; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CEAE914A4C8; Sun, 24 Mar 2024 22:38:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319881; cv=none; b=CtdOm5AxFUyndLGsM4fMpmndZCmp1PdApKbSwQRGEmkQYz1uM+lCOWEynDw5BJE5QFIqTZkizoyiKmVceNzrUfQT1zswb9Mk5oXH6IR0HnHva1aGt0nMNB9TiZX0VVtHQEu50J8lRiT7ol0PEHAskHWduoawfpNpNmSYHA2Ez0Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319881; c=relaxed/simple; bh=6IAXt7kg0mXsg5guh9sUHvOjMA33teZAxvgBy5cfGJY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=N8C/fMhubu8QyNWEM6XLIGLQ+Eo28p5pPmGmwzuebz1uLe81pR8acb8XxRJarOYMi1g7kiaHa/6jjPlpd02nvMo9xFPouAsAS0QweP8s04WwRwiBkiqULNr0fuCa4okH1mOom5wtdD5dfPUyhhLa1ED0cEiO8idHENBvtvrxCjc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lbf7ISbz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lbf7ISbz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE2E5C43390; Sun, 24 Mar 2024 22:38:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319881; bh=6IAXt7kg0mXsg5guh9sUHvOjMA33teZAxvgBy5cfGJY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lbf7ISbzATtWWAVDrbpGLTwN4H9334JuduvA8udVlqCpGf6bT97KNJ3KI33WmLU6b d5eD5L/mnf4PyDVQ8IEWTVbAjE01aXDJLFFRiN8opjNJMrz8xL2Mgu4HuR+cvKYvZC rzS5ThV0J9xz01/6U/HR5Mvt4aVCG34vAfJ3qjxtJS419UqtEoVA9MH7B8hgBvGSHP FKWb+tBvH7UXvZzQM1j2pDzcnjZRBnePx8nIf/7fVzeUP1R2OQWzXbQkCgFP+a/3pB ubjwxStpFCvS3dXg76dJubZ/M3cJi254J4pqH9EW1wtMBSmmrond43RN25ibB+6j+k 64ciw2OdnFZVg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= , AngeloGioacchino Del Regno , Matthias Brugger , Sasha Levin Subject: [PATCH 6.8 186/715] arm64: dts: mediatek: mt7986: fix SPI nodename Date: Sun, 24 Mar 2024 18:26:05 -0400 Message-ID: <20240324223455.1342824-187-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Rafa=C5=82 Mi=C5=82ecki [ Upstream commit bbe266c70e1343ee3e71ca31138141b3da265085 ] This fixes following validation errors: arch/arm64/boot/dts/mediatek/mt7986a-rfb.dtb: spi_nand@0: $nodename:0: 'spi= _nand@0' does not match '^(flash|.*sram|nand)(@.*)?$' from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml# arch/arm64/boot/dts/mediatek/mt7986b-rfb.dtb: spi_nand@0: $nodename:0: 'spi= _nand@0' does not match '^(flash|.*sram|nand)(@.*)?$' from schema $id: http://devicetree.org/schemas/mtd/spi-nand.yaml# Fixes: 885e153ed7c1 ("arm64: dts: mt7986: add spi related device nodes") Signed-off-by: Rafa=C5=82 Mi=C5=82ecki Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20231116130952.5099-2-zajec5@gmail.com Signed-off-by: Matthias Brugger Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts | 3 ++- arch/arm64/boot/dts/mediatek/mt7986b-rfb.dts | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts b/arch/arm64/boot= /dts/mediatek/mt7986a-rfb.dts index bcb3ebb85d708..2f884c24f1eb4 100644 --- a/arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts +++ b/arch/arm64/boot/dts/mediatek/mt7986a-rfb.dts @@ -237,7 +237,8 @@ &spi0 { pinctrl-0 =3D <&spi_flash_pins>; cs-gpios =3D <0>, <0>; status =3D "okay"; - spi_nand: spi_nand@0 { + + spi_nand: flash@0 { compatible =3D "spi-nand"; reg =3D <0>; spi-max-frequency =3D <10000000>; diff --git a/arch/arm64/boot/dts/mediatek/mt7986b-rfb.dts b/arch/arm64/boot= /dts/mediatek/mt7986b-rfb.dts index 48fe50e671779..57dcaeef31d7f 100644 --- a/arch/arm64/boot/dts/mediatek/mt7986b-rfb.dts +++ b/arch/arm64/boot/dts/mediatek/mt7986b-rfb.dts @@ -152,7 +152,8 @@ &spi0 { pinctrl-0 =3D <&spi_flash_pins>; cs-gpios =3D <0>, <0>; status =3D "okay"; - spi_nand: spi_nand@0 { + + spi_nand: flash@0 { compatible =3D "spi-nand"; reg =3D <0>; spi-max-frequency =3D <10000000>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFC9D14A4EA; Sun, 24 Mar 2024 22:38:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319883; cv=none; b=rl1yuSXaXrohjI/H6CDGXx2vICPVA5kxxB1aUnq1sFJj9B/9XwrYY1g60VVa9aiKuVBB1kNZVHPzjwEN98bpf3ER5pJP1B85sDd7XkNdx3QfmvOVCfajbvuGVx5Xn2w6OGDM4rF9FGO4EiG14KDBcDJyy98GILr1CD/yqFt4KWQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319883; c=relaxed/simple; bh=JZ9hjUv65VKWnCNf16bYhhk7KizDvVvRGq96t8SMwzs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YmqtxRCAAlFOCrdicgAOgmXYPQ2Zj8R+P9EkSVIm60zRNkx9M8vyW16TGAoj5F3gTeevzNnmuimC/JO0Ts77AjHfzeJk82Fumwg1i+25wQYQDd1APf6a437I/BFpJbfq7XGhSJetwpn5HB2lcwtcWHmekbVpPnEpNqFw+IdZ9J4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mh7xpah/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mh7xpah/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EEA09C43399; Sun, 24 Mar 2024 22:38:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319882; bh=JZ9hjUv65VKWnCNf16bYhhk7KizDvVvRGq96t8SMwzs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mh7xpah/gwxeGhPEhRqIsW/t0jldMYky45laiZ/T2pos/fo9kFgLjHxnMsJTau6ao /S7BeP/EqaYclui8JTQK1CpjqtMat01aCfHpPNBtk0MI9WXbU5JmVpIR5HWAQ6rPO8 WvOBhcSBJnzHzS90e5mDQQsVevJzHI1UlrrruY58Mcr84YzTy0DlN4nP0bGWEF3yV0 U7GmznnP/gRqW7QGsu9GLw+fzcoXhe/6ddMkoa181dXoOyCTWQpdMAEKt5kvH0RfqE f6hKvCHv9h/Z/Z2Si8GTjDFytGfZZngGaBTarfO+H4dK+BDssMr1vF0LeNZU6LM9nl WCCoiQFjrGQ1Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= , Daniel Golle , Matthias Brugger , AngeloGioacchino Del Regno , Sasha Levin Subject: [PATCH 6.8 187/715] arm64: dts: mediatek: mt7986: drop "#clock-cells" from PWM Date: Sun, 24 Mar 2024 18:26:06 -0400 Message-ID: <20240324223455.1342824-188-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Rafa=C5=82 Mi=C5=82ecki [ Upstream commit 0b721691f0c80af682d0ef3aa4a177c23d41b072 ] PWM is not a clock provider and its binding doesn't specify "#clock-cells" property. This fixes: arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: pwm@10048000: '#c= lock-cells' does not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/pwm/mediatek,mt2712-= pwm.yaml# Fixes: eabb04df46c6 ("arm64: dts: mt7986: add PWM") Cc: Daniel Golle Signed-off-by: Rafa=C5=82 Mi=C5=82ecki Link: https://lore.kernel.org/r/20240101182040.28538-1-zajec5@gmail.com Signed-off-by: Matthias Brugger Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi b/arch/arm64/boot/dt= s/mediatek/mt7986a.dtsi index a7d9c3246a875..7b6591509c54d 100644 --- a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi @@ -242,7 +242,6 @@ crypto: crypto@10320000 { pwm: pwm@10048000 { compatible =3D "mediatek,mt7986-pwm"; reg =3D <0 0x10048000 0 0x1000>; - #clock-cells =3D <1>; #pwm-cells =3D <2>; interrupts =3D ; clocks =3D <&topckgen CLK_TOP_PWM_SEL>, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 00CBA54735; Sun, 24 Mar 2024 22:38:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319884; cv=none; b=oOwk7mX4haZFdMDpn/z7eKzE24t2j/YGdPfA6noOVVWyZb/sSB0BSBXYVVYHFg+f1DJzXlqbq8qZg9Z7vc9rMySVvQTC4w7g0N9o9nulYHE6e+I0qHfSa8iWtVKqFWzJ9NRnWGneWRZoFFMrUDoC/5JAjslDCGLChe9g+cbd7TY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319884; c=relaxed/simple; bh=/qCNevVVEggzTf1GpDuuZorY4cKNTJEWoKSpqvi5tJ4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=df5Gho7UBqLIdc1MMj1R59Im+s9iQaiEf4zg7KQIeUePN5Gjtd+gpoQfDcc8qLcIpRXv9dTOZDvYp8ACWaMM1KByr+UCgY6zB2OmEEUS769jHZAuhAwSa3z9/uAY/eO3YkgH9wZkVt5WEX4Um7dCakvsaAWFyWmm7V0VIOq1m+0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZGM6jiF6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZGM6jiF6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1102AC433F1; Sun, 24 Mar 2024 22:38:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319883; bh=/qCNevVVEggzTf1GpDuuZorY4cKNTJEWoKSpqvi5tJ4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZGM6jiF6fwnzwHDo91seJ55WU12pnXfNlLoI2b47VFYK8lJxxpIRXTr6ojUbOvNIK x00SjsPH4FlK8Kc/1pQh+mctY2YwJrLyPb5t11OBRAQDzaNusWqe5y0Gj8orsSpKrY SDaR6+5YvN1A0IhW+v6dM+wSQfFzac0sXmMbtaEnCxeU9mqYmhz9EXO3Ks51zzne39 51ZYX8/eJ2IxkJ32BbF6WqG7kp3QSD7M1/OxG38sny7E59Se1IH/9zfg6hwEnTmFDu FmqcANb6/RNkJXpNMtQv1JMZmJrKzLn7uu9eECX07zrp+mcBPmEUMSoHEmgYJYxKP8 kZ/sj/Svx+01Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= , Sam Shih , Matthias Brugger , AngeloGioacchino Del Regno , Sasha Levin Subject: [PATCH 6.8 188/715] arm64: dts: mediatek: mt7986: add "#reset-cells" to infracfg Date: Sun, 24 Mar 2024 18:26:07 -0400 Message-ID: <20240324223455.1342824-189-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Rafa=C5=82 Mi=C5=82ecki [ Upstream commit d993daff5962b2dd08f32a83bb1c0e5fa75732ea ] MT7986's Infrastructure System Configuration Controller includes reset controller. It can reset blocks as specified in the include/dt-bindings/reset/mt7986-resets.h . Add #reset-cells so it can be referenced properly. This fixes: arch/arm64/boot/dts/mediatek/mt7986a-bananapi-bpi-r3.dtb: infracfg@10001000= : '#reset-cells' is a required property from schema $id: http://devicetree.org/schemas/arm/mediatek/mediate= k,infracfg.yaml# Fixes: 1f9986b258c2 ("arm64: dts: mediatek: add clock support for mt7986a") Cc: Sam Shih Signed-off-by: Rafa=C5=82 Mi=C5=82ecki Link: https://lore.kernel.org/r/20240101182040.28538-2-zajec5@gmail.com Signed-off-by: Matthias Brugger Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt7986a.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi b/arch/arm64/boot/dt= s/mediatek/mt7986a.dtsi index 7b6591509c54d..d974739eae1c9 100644 --- a/arch/arm64/boot/dts/mediatek/mt7986a.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt7986a.dtsi @@ -153,6 +153,7 @@ infracfg: infracfg@10001000 { compatible =3D "mediatek,mt7986-infracfg", "syscon"; reg =3D <0 0x10001000 0 0x1000>; #clock-cells =3D <1>; + #reset-cells =3D <1>; }; =20 wed_pcie: wed-pcie@10003000 { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3610E14AD2F; Sun, 24 Mar 2024 22:38:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319885; cv=none; b=WynrMIarzs/flDB3vVMjlvhqIHjy9Q/M9qo5/Wu0lZBX/YWo4goMD8OdQ0XCiU5mOIPjQOGjR4G0clzy3z2W014QNLlY5I4q3JFayHMugrLamCQhvp2W6/G5vzLF04I1QdtGf9CnJsx3UBQa1U8+8ExaUG9xu8qO1p1E2GWrOhs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319885; c=relaxed/simple; bh=Qqwg4J3ai484A6gC6stXIaNlROAtJFQ5aC1I52Ocx0o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=i4ktnoEOhB86K4wG81xy85fo5/+t8GV8khSKcqVTBMsfIioK7j+SblWJ55tTgJxvrB6FAmJIAyxPDwJxGJ/fY/afekedV5l+OVOZFRoCcdQawtfSYW4M5YN/cUAW+kP9hbfIWr3Nq0jYMGt1OijKeao0XHLSpYpdB22xnTowJr4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jsZLlwhv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jsZLlwhv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1EA50C433C7; Sun, 24 Mar 2024 22:38:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319884; bh=Qqwg4J3ai484A6gC6stXIaNlROAtJFQ5aC1I52Ocx0o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jsZLlwhvMyy5y/D46Khc/CWfCJLUBx+elJ5LdZ2NgMS/tWhEujV1uuHtGxiJFeG3R 9ZBYf0ZU2YyOTFNaadDVT6+uvSgmUlwhHRH2UCaCuU9VOyTmUxNPpoEPNPvk+CaT3b 0jlySN53D2oNolgd1LIzespQf7dh4qDPvlkr7MwIzWtAfhjm43RHPHExD9L3WKFSrs lTYyY1JQftzbGXajS+eCcY/lboby6LYAt9Wpx5PD2SnGi4fx+69ccsOeMqvZT1p1nh Md6RkkOkD3OmRSgGUO6mptyGh9lu83/m6qy/9YBvFBTyAf8K5ZmAx8lmkwgDBzgeAe Je77hAx+UweRA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= , AngeloGioacchino Del Regno , Sasha Levin Subject: [PATCH 6.8 189/715] arm64: dts: mediatek: mt8192-asurada: Remove CrosEC base detection node Date: Sun, 24 Mar 2024 18:26:08 -0400 Message-ID: <20240324223455.1342824-190-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: N=C3=ADcolas F. R. A. Prado [ Upstream commit 9b49cabe631b0a25aaf8fc2ba81b5b9ea6ff01b7 ] The commit adding the ChromeOS EC to the Asurada Devicetree mistakenly added a base detection node. While tablet mode detection is supported by CrosEC and used by Hayato, it is done through the cros-ec-keyb driver. The base detection node, which is handled by the hid-google-hammer driver, also provides tablet mode detection but by checking base attachment status on the CrosEC, which is not supported for Asurada. Hence, remove the unused CrosEC base detection node for Asurada. Fixes: eb188a2aaa82 ("arm64: dts: mediatek: asurada: Add ChromeOS EC") Signed-off-by: N=C3=ADcolas F. R. A. Prado Link: https://lore.kernel.org/r/20240207-mt8192-asurada-cbas-remove-v1-1-04= cb65951975@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi | 4 ---- 1 file changed, 4 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi b/arch/arm64/= boot/dts/mediatek/mt8192-asurada.dtsi index d87aab8d7a79e..d4dd5e8b2e1d3 100644 --- a/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8192-asurada.dtsi @@ -1336,10 +1336,6 @@ cros_ec: ec@0 { #address-cells =3D <1>; #size-cells =3D <0>; =20 - base_detection: cbas { - compatible =3D "google,cros-cbas"; - }; - cros_ec_pwm: pwm { compatible =3D "google,cros-ec-pwm"; #pwm-cells =3D <1>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BA8B714AD08; Sun, 24 Mar 2024 22:38:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319885; cv=none; b=idFJpEJysAXGiNiMXxse0crnIv6p2rCAh88duNqJjpZTHJFoWtFMDyfZ2VUZlTrA8Z9ZKZlmbc6gvDHdhWBNws+AGzQOhE5AW8Ml9Voh0c4RqYwFs9mjwoHCkn3a2xKuGrWNxtbsAIkjcq7PfHiu1M6RqWyTftwOaoWHP/8fRWw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319885; c=relaxed/simple; bh=Bi6N9t4aRKgVA4P0PqsF7x1GHKprdkWEHWbgHbzfyhQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=X99kX01xZGyAo+P3j7Z40CqexVr0SIKqSLELOVIoPNxnwyW4xHHcHeXI+EBtx6AhnAZn7TFY++eiswhvPYCeiFYb1S55ucqMfjPDSIAg5U6patjLr/zp/x4rlhWF4YEhIll6MuspvnGi5TRTy/u1A5tXm7P2TjrnLFah3PpCjf8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ew5FPKJJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ew5FPKJJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 039ACC433B1; Sun, 24 Mar 2024 22:38:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319885; bh=Bi6N9t4aRKgVA4P0PqsF7x1GHKprdkWEHWbgHbzfyhQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ew5FPKJJ77nbYifvHRbzoX5UDj7Vj3ubplEaZ1WT4jZ/NhPymg9DLhY3wWfZrWS2c 8E6ayl0JKP9wfbpMZRIYo7Oz95pOGs9FKHE7/GwEcf3nmfFArKJN/b4OM9fxVrXv7L C9kH6z+cGe2szKtzVNQZeX0SnUZbUYDmEGrewk0Z68qzuAYI75OJmPF+sI34HJiUJb 7xCIs+vMpQj3gOtIphT3MjeER6A004oeGMm3gU+hjNmuBP6X4So9C4UCibHtn2TzXv VYpGIJBkEQ+oHu2HlG3Xb43O7ZLIG9lQp1z8L+19MMT4T1y21Z9/Q1wzBvFpnDwLd3 xxN532+P3phqg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eugen Hristev , AngeloGioacchino Del Regno , Sasha Levin Subject: [PATCH 6.8 190/715] arm64: dts: mediatek: mt8192: fix vencoder clock name Date: Sun, 24 Mar 2024 18:26:09 -0400 Message-ID: <20240324223455.1342824-191-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eugen Hristev [ Upstream commit 76aac0f2a46847ed4a7a4fdd848dd66023c19ad1 ] Clock name should be `venc_sel` as per binding. Fix the warning message : arch/arm64/boot/dts/mediatek/mt8192-asurada-hayato-r1.dtb: vcodec@17020000:= clock-names:0: 'venc_sel' was expected from schema $id: http://devicetree.org/schemas/media/mediatek,vcode= c-encoder.yaml# Fixes: aa8f3711fc87 ("arm64: dts: mt8192: Add H264 venc device node") Signed-off-by: Eugen Hristev Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20231228113245.174706-4-eugen.hristev@colla= bora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt8192.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts= /mediatek/mt8192.dtsi index 6dd32dbfb832e..0e432636b8c23 100644 --- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi @@ -1814,7 +1814,7 @@ vcodec_enc: vcodec@17020000 { mediatek,scp =3D <&scp>; power-domains =3D <&spm MT8192_POWER_DOMAIN_VENC>; clocks =3D <&vencsys CLK_VENC_SET1_VENC>; - clock-names =3D "venc-set1"; + clock-names =3D "venc_sel"; assigned-clocks =3D <&topckgen CLK_TOP_VENC_SEL>; assigned-clock-parents =3D <&topckgen CLK_TOP_UNIVPLL_D4>; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A01B114C59A; Sun, 24 Mar 2024 22:38:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319886; cv=none; b=sewkVHEXrnBmc27RQd99LPubRJVIviIwYiOIB4G06Syny4YLUcCbaygVeCzuWRUetQdHY85lLNgh60fU0YQRRioZZ9FAlVSYzAk3Xu36tYj3y5BTW0QuGUph1tpW4v6cDdshjU1IitysAag2eIEPTDFGjSDKHKU2FYreuCC4360= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319886; c=relaxed/simple; bh=O9eze3/Xwc/ji+cKXEagCMTc8AL45Jdq9HEYPVII6WA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=d7CfJILf65XEHXh5VO1R8ubasIfwncZJ8MkJWFgrYKbFlsXL/hShrXHTnH7XmszTe94nZ6SCHSDwB8lf6hT3OQ6oB8SqPTAHu+NReiEemyBTmtb3vh9Hqkx4aqWQR3QKFGXK08z3UUjoq/gYuQImZO/uG0nZQ1A2C/cxYFP6Oss= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WNS3meRh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WNS3meRh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DE124C433F1; Sun, 24 Mar 2024 22:38:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319886; bh=O9eze3/Xwc/ji+cKXEagCMTc8AL45Jdq9HEYPVII6WA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WNS3meRhkdE1ZMhn2lECxJJ4NGVB/dc+obcpBwd7+vidRChPsZSn+uYFmqIwcmbQk qkAUYNnM6QogGD5UNlO43YGiKVQEhh9k0dXiYPPeTTy2yO5KQycMxnUDETvsGBWK2t OWIph4ZwaSBx0+vmyBAiXCfdn+3ryH9xpFaVq4yI/RlAvMTPvRvB4qRUUHVDoCj0Lq fXZvCT/qDzAXBmTdCCieE9wBugMFrj3VBj1R6hwB1g31MiGSMEvWkSKLTsdjScIjpF s/0vkw0/ycuNCw60h/XwwFImoHPqcpR6LhG+3miWMiCQAMp5wbDaVt5a9PftoAwuLw bGQWVuaS4SgdQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eugen Hristev , AngeloGioacchino Del Regno , Sasha Levin Subject: [PATCH 6.8 191/715] arm64: dts: mediatek: mt8186: fix VENC power domain clocks Date: Sun, 24 Mar 2024 18:26:10 -0400 Message-ID: <20240324223455.1342824-192-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eugen Hristev [ Upstream commit 09860910c589a3bb3b5268ff6f704cf6b18ada73 ] The larb clock is in fact a subsys clock, so it must be prefixed by 'subsys-' to be correctly identified in the driver. Fixes: d9e43c1e7a38 ("arm64: dts: mt8186: Add power domains controller") Signed-off-by: Eugen Hristev Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20231228113245.174706-6-eugen.hristev@colla= bora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt8186.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts= /mediatek/mt8186.dtsi index 2fec6fd1c1a71..ee0feadbf9619 100644 --- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi @@ -1061,7 +1061,7 @@ power-domain@MT8186_POWER_DOMAIN_VENC { reg =3D ; clocks =3D <&topckgen CLK_TOP_VENC>, <&vencsys CLK_VENC_CKE1_VENC>; - clock-names =3D "venc0", "larb"; + clock-names =3D "venc0", "subsys-larb"; mediatek,infracfg =3D <&infracfg_ao>; #power-domain-cells =3D <0>; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A184954735; Sun, 24 Mar 2024 22:38:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319887; cv=none; b=pUU9Ng1J4+rTNcfRtMOJM4Z85XCrjmOnToUgUOc4IZ/prKhsExfh1ohR8mQe55nNDapAF/0s9qMD39zw9VjjgSZvk8Sky9A0HX69nFVjRlS2H3/MJZKW2lo+gs2e8rnWPYokeQ/n2dG7HwyHlaAbxKH7CnJWyEOBzmvVRYm/h+0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319887; c=relaxed/simple; bh=i6d8nId4acQL2nz8imcsUWI9nn4vWU6z66u0NR4onf0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ejTtN5hbKLfQFuZt9WTe6sv0yUQwFZNqI8SDUxWprLmejtU9LaiKlxOPkK5+xblr0FqfCnPXusfTjkwkEETgvhxIU2a6RsswbJngIx0Mo5g1B7TWgrXld/aZhxh9evp6g4Rh0ZsvR3Gk9hcCLgBxYvrPI853tD33BE7FV6pUUwY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JfJnZIbK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JfJnZIbK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2A58C43394; Sun, 24 Mar 2024 22:38:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319887; bh=i6d8nId4acQL2nz8imcsUWI9nn4vWU6z66u0NR4onf0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JfJnZIbKflQsSyE4R1TuwoVlHkVjFeFtx5W1ZvC9rAO5csHdIcHiM9MtbTKEXxVgR u200KtPHYTfYCSY3CswVB17h54stOvpE8Pgf8EidsS1ur7SwXsTUYFH+Izuhu2s6ZP ByI3aFuljt2BZQD5yLWX0PQp1NocryV4bGEnGsmCcHNfRHaBu8WKmZjzYGpbaeJNbH ll8cczF0Af+7gIatibZ7Z/sx64J+0WtmeNyXrEoumldhi1V+KuWxQ6EW+iZ7QvMDKr Igi8GMDOW4UW2cwfBvPduRCTvBdSmUrIJSLOgQBP4iiCmeVQK7z76tXoPlUMVTEWlA +o36sRQ5jirXA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= , Matthias Brugger , AngeloGioacchino Del Regno , Sasha Levin Subject: [PATCH 6.8 192/715] arm64: dts: mediatek: mt7622: add missing "device_type" to memory nodes Date: Sun, 24 Mar 2024 18:26:11 -0400 Message-ID: <20240324223455.1342824-193-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Rafa=C5=82 Mi=C5=82ecki [ Upstream commit 99d100e00144bc01b49a697f4bc4398f2f7e7ce4 ] This fixes: arch/arm64/boot/dts/mediatek/mt7622-rfb1.dtb: /: memory@40000000: 'device_t= ype' is a required property from schema $id: http://devicetree.org/schemas/memory.yaml# arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dtb: /: memory@4000000= 0: 'device_type' is a required property from schema $id: http://devicetree.org/schemas/memory.yaml# Signed-off-by: Rafa=C5=82 Mi=C5=82ecki Reviewed-by: Matthias Brugger Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240122132357.31264-1-zajec5@gmail.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts | 1 + arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts b/arc= h/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts index a1f42048dcc70..850b3e2773680 100644 --- a/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts +++ b/arch/arm64/boot/dts/mediatek/mt7622-bananapi-bpi-r64.dts @@ -75,6 +75,7 @@ led-1 { =20 memory@40000000 { reg =3D <0 0x40000000 0 0x40000000>; + device_type =3D "memory"; }; =20 reg_1p8v: regulator-1p8v { diff --git a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts b/arch/arm64/boot= /dts/mediatek/mt7622-rfb1.dts index 2dc1bdc74e212..5c26021fc4cf1 100644 --- a/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts +++ b/arch/arm64/boot/dts/mediatek/mt7622-rfb1.dts @@ -57,6 +57,7 @@ key-wps { =20 memory@40000000 { reg =3D <0 0x40000000 0 0x20000000>; + device_type =3D "memory"; }; =20 reg_1p8v: regulator-1p8v { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BCAF75478B; Sun, 24 Mar 2024 22:38:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319888; cv=none; b=bEUKGchqWcfbD0quaNhmi2sP0oH6u/Fx9k/qFg3Nf5zn2rXb3x2JBd7U4fMDcIXSaVNmd2nfVh9xhudK+dW86HGi2K0CTEjWdfVTX3amIAVm+IQkvo77srlsYN8jgUIFj7Ug0vAA8hfTeUPS81J0zXgKGDHOBcZMkZfvdbY2+hI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319888; c=relaxed/simple; bh=z9jUFiSp3MUg0mH6coUgrT0+E54jL2MUqfmnswH9CjU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HmnyCtoVUlPpVAj1LgPqSWvxB+LLuaPYYi86lkrEYdVeTFr9MFdKBX8aGsjVwpYatEwY0oSjI3OoFvMqd/QGpalywtNp4l6gtiAFxRG2gYeiWLtEyB9lcll32nt0X3aYozlTZ1PHFxJXloPYT8Zpd01EMLu4WDMM2Clq6PYK62o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s1JJ/q3S; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s1JJ/q3S" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C2800C433C7; Sun, 24 Mar 2024 22:38:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319888; bh=z9jUFiSp3MUg0mH6coUgrT0+E54jL2MUqfmnswH9CjU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s1JJ/q3SNaOZWuXw4+j/K3Rpli7oZboruScfIueAoFvruaZmZBGeKXUmAFm6j5mkZ wZyUluhg9+tN+RWOWMXrJsm6d+ebGivq24/+4gi8rTzJ2AtT0h1IPHKa0IB68G7O/a Gpa5/WDR9MXmyrwrhyk6M19TOtcAoTxAN/uhdvWvIS1eIikZQCgGAt33jEvNx/fTgx z6WWb25Q11Tw4CMu4ZOPjp8pkV1oj3T+VPCHVxEZBM+nvaJS1QpyUIWIuIaI1U7nMN 8trn+tXCzh+JBYm3Uqygrlvc8qfpuY2NyAzAU+1L8zpADbsHtJNZ/Y0fmng3MmLXaq fuJv4O9tsniUw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Markus Schneider-Pargmann , Judith Mendez , Simon Horman , Marc Kleine-Budde , Sasha Levin Subject: [PATCH 6.8 193/715] can: m_can: Start/Cancel polling timer together with interrupts Date: Sun, 24 Mar 2024 18:26:12 -0400 Message-ID: <20240324223455.1342824-194-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Markus Schneider-Pargmann [ Upstream commit a163c5761019b94258ca655b27b46e82657fd6f5 ] Interrupts are enabled/disabled in more places than just m_can_start() and m_can_stop(). Couple the polling timer with enabling/disabling of all interrupts to achieve equivalent behavior. Cc: Judith Mendez Fixes: b382380c0d2d ("can: m_can: Add hrtimer to generate software interrup= t") Signed-off-by: Markus Schneider-Pargmann Reviewed-by: Simon Horman Link: https://lore.kernel.org/all/20240207093220.2681425-2-msp@baylibre.com Signed-off-by: Marc Kleine-Budde Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/can/m_can/m_can.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c index 16ecc11c7f62a..2395b1225cc8a 100644 --- a/drivers/net/can/m_can/m_can.c +++ b/drivers/net/can/m_can/m_can.c @@ -418,6 +418,13 @@ static void m_can_config_endisable(struct m_can_classd= ev *cdev, bool enable) =20 static inline void m_can_enable_all_interrupts(struct m_can_classdev *cdev) { + if (!cdev->net->irq) { + dev_dbg(cdev->dev, "Start hrtimer\n"); + hrtimer_start(&cdev->hrtimer, + ms_to_ktime(HRTIMER_POLL_INTERVAL_MS), + HRTIMER_MODE_REL_PINNED); + } + /* Only interrupt line 0 is used in this driver */ m_can_write(cdev, M_CAN_ILE, ILE_EINT0); } @@ -425,6 +432,11 @@ static inline void m_can_enable_all_interrupts(struct = m_can_classdev *cdev) static inline void m_can_disable_all_interrupts(struct m_can_classdev *cde= v) { m_can_write(cdev, M_CAN_ILE, 0x0); + + if (!cdev->net->irq) { + dev_dbg(cdev->dev, "Stop hrtimer\n"); + hrtimer_cancel(&cdev->hrtimer); + } } =20 /* Retrieve internal timestamp counter from TSCV.TSC, and shift it to 32-b= it @@ -1417,12 +1429,6 @@ static int m_can_start(struct net_device *dev) =20 m_can_enable_all_interrupts(cdev); =20 - if (!dev->irq) { - dev_dbg(cdev->dev, "Start hrtimer\n"); - hrtimer_start(&cdev->hrtimer, ms_to_ktime(HRTIMER_POLL_INTERVAL_MS), - HRTIMER_MODE_REL_PINNED); - } - return 0; } =20 @@ -1577,11 +1583,6 @@ static void m_can_stop(struct net_device *dev) { struct m_can_classdev *cdev =3D netdev_priv(dev); =20 - if (!dev->irq) { - dev_dbg(cdev->dev, "Stop hrtimer\n"); - hrtimer_cancel(&cdev->hrtimer); - } - /* disable all interrupts */ m_can_disable_all_interrupts(cdev); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 00E9714E2D4; Sun, 24 Mar 2024 22:38:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319891; cv=none; b=ZWVfTLOJJAonDk4Fj1NcBB+WfYbgcL+62QWsrxEP/00zpIyG+mkfJ94JZxtkyQQc7mjTWsb8iclUHKYYxCrGyzs0S7AOUUtgkBhEQgoVcNrcLhuJWLTsSJvhzccSPZmWOewvSXBZFS8IUAQGzHYo8EmGj4GgLfgnP0O73h5BznM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319891; c=relaxed/simple; bh=SSr5RFektTQL/EnOjOh7JFgVsHETDVqB8XLdmop9QhU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BGwI5LeLSDP3HgvOE82+y57qSEUN62idepRlyj8gbTkEynXJaRbbFOiB7UbH/p4pDXyVMUl4MoeTKMRn+iZYsVvN3DKIG1hRQj6Ly2kNTOfpKVrrbXL3sG6uMowW40KJQzSVecKPXXmveLmdFQCQeRl8OARcMGdj80kjGknCIGo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HBS70aGW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HBS70aGW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7842C433A6; Sun, 24 Mar 2024 22:38:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319889; bh=SSr5RFektTQL/EnOjOh7JFgVsHETDVqB8XLdmop9QhU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HBS70aGWtx2ui+RCdZC+KwQeradPQXfrwstGuq5Hirvp18mcE4gBN3rcVPkriwBNg NofTPsRkStKX1K+pBQOZ53VWIsDn+TbduVLKebeq8/tEZXFB2xFTru+zShDRT7Mmwk 2Fxmgr8/Te2mjBekeDMg0+cDblefto1gPEvPt+mRWfdxkDsVFH0j1QFmhqyUL79JvD JiF1Vy6l7/B3Amc9dJt0ftkur1XgrxaaCIR+HGztTGQBABf5ifE/JQOYH7YlmRNLgt JJ0x9paAVMo8j8YjtZ2ApXPxdJ4F5FrRKbeW+agtVBkYTmQLNLvl/h/JNGAQd0Ke+i DKPipPJ2mYYfA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ilan Peer , Miri Korenblit , Johannes Berg , Sasha Levin Subject: [PATCH 6.8 194/715] wifi: iwlwifi: mvm: Fix the listener MAC filter flags Date: Sun, 24 Mar 2024 18:26:13 -0400 Message-ID: <20240324223455.1342824-195-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ilan Peer [ Upstream commit 4cdb86487e3eaddb4b3a7df30ae709e810aac84b ] One of the flags was from the wrong API. Fixes: 9be162a7b670 ("wifi: iwlwifi: mvm: add support for the new MAC CTXT = command") Signed-off-by: Ilan Peer Signed-off-by: Miri Korenblit Link: https://msgid.link/20240208185302.a338c30ec4e9.Ic2813cdeba4443c692d46= 2fc4859392f069d7e33@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/intel/iwlwifi/mvm/mld-mac.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/mld-mac.c b/drivers/net= /wireless/intel/iwlwifi/mvm/mld-mac.c index f313a8d771e42..ad78c69cc6cb7 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/mld-mac.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/mld-mac.c @@ -167,7 +167,7 @@ static int iwl_mvm_mld_mac_ctxt_cmd_listener(struct iwl= _mvm *mvm, iwl_mvm_mld_mac_ctxt_cmd_common(mvm, vif, &cmd, action); =20 cmd.filter_flags =3D cpu_to_le32(MAC_CFG_FILTER_PROMISC | - MAC_FILTER_IN_CONTROL_AND_MGMT | + MAC_CFG_FILTER_ACCEPT_CONTROL_AND_MGMT | MAC_CFG_FILTER_ACCEPT_BEACON | MAC_CFG_FILTER_ACCEPT_PROBE_REQ | MAC_CFG_FILTER_ACCEPT_GRP); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AF554548E2; Sun, 24 Mar 2024 22:38:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319890; cv=none; b=sUvE6/n5pxX30pt4Wn83CVANDzh5K/mcJkpzEV0skVbCW90q0NiCYWZt5AZ3DuJbruoqT8J5D6DAZxdSOo2tsckCI2yjeDWS4Sg3+2d9hD2N96a+YzhpGLLClnEMpQb0yEa0IOQKzwjPxoF+lnrOEjIUmCJ0lyw9dV150bv2+kE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319890; c=relaxed/simple; bh=ZnrPdgvk06axdQ2YBtY3yByvM2uHKf4dwGAffJixHV0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RHdlbV7i1VGJxVJHIh9178T+gjdDPcMCvx88u4tXuiXulPvXPPBT0qG9oO0HSFoqW+S4v7N1h8pAuGIsSHKlrRYClh1us1RXimxldWSohXwVzyP0qQ7QlsU5PtFb2RlJ775ELOtac0DWlQyOQonhUrYL5uMwqMjAlfi2fYe9Olc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SUpmGfhF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SUpmGfhF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6881C433C7; Sun, 24 Mar 2024 22:38:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319890; bh=ZnrPdgvk06axdQ2YBtY3yByvM2uHKf4dwGAffJixHV0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SUpmGfhF2yAQitpTRRopdZxZhHys5k8giWvVdnB6JeOYWwRNjrCH3omkjiaKEHibx bXhDEWGNhIi3qKBo6jZy6za9x+KwpEnSN8IssVX4wdta3XRnD3wnvmbp6ue9Yb3GY1 7tZw6L13shMbBwaRaVS2mri9oL7vpOHsq7jwM1JF1kLc40K7PdLiNNFquT+lG8AoI0 d7oY/noKDijCnTBUzEHw7tTrh2xYYMeZnwr406YDi7QKSHXSr2+ZOJ92dtNO5CkMuW dCVyYYmVl+DYAeU64tXegZ/YlS0znTTisNvuZVX5M2YDaedHvcns0x+eG7bA6ohnv9 aNM8qs6RPqWWQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yonghong Song , Andrii Nakryiko , Jiri Olsa , Sasha Levin Subject: [PATCH 6.8 195/715] bpf: Mark bpf_spin_{lock,unlock}() helpers with notrace correctly Date: Sun, 24 Mar 2024 18:26:14 -0400 Message-ID: <20240324223455.1342824-196-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yonghong Song [ Upstream commit 178c54666f9c4d2f49f2ea661d0c11b52f0ed190 ] Currently tracing is supposed not to allow for bpf_spin_{lock,unlock}() helper calls. This is to prevent deadlock for the following cases: - there is a prog (prog-A) calling bpf_spin_{lock,unlock}(). - there is a tracing program (prog-B), e.g., fentry, attached to bpf_spin_lock() and/or bpf_spin_unlock(). - prog-B calls bpf_spin_{lock,unlock}(). For such a case, when prog-A calls bpf_spin_{lock,unlock}(), a deadlock will happen. The related source codes are below in kernel/bpf/helpers.c: notrace BPF_CALL_1(bpf_spin_lock, struct bpf_spin_lock *, lock) notrace BPF_CALL_1(bpf_spin_unlock, struct bpf_spin_lock *, lock) notrace is supposed to prevent fentry prog from attaching to bpf_spin_{lock,unlock}(). But actually this is not the case and fentry prog can successfully attached to bpf_spin_lock(). Siddharth Chintamaneni reported the issue in [1]. The following is the macro definition for above BPF_CALL_1: #define BPF_CALL_x(x, name, ...) = \ static __always_inline = \ u64 ____##name(__BPF_MAP(x, __BPF_DECL_ARGS, __BPF_V, __VA_ARGS__))= ; \ typedef u64 (*btf_##name)(__BPF_MAP(x, __BPF_DECL_ARGS, __BPF_V, __= VA_ARGS__)); \ u64 name(__BPF_REG(x, __BPF_DECL_REGS, __BPF_N, __VA_ARGS__)); = \ u64 name(__BPF_REG(x, __BPF_DECL_REGS, __BPF_N, __VA_ARGS__)) = \ { = \ return ((btf_##name)____##name)(__BPF_MAP(x,__BPF_CAST,__BP= F_N,__VA_ARGS__));\ } = \ static __always_inline = \ u64 ____##name(__BPF_MAP(x, __BPF_DECL_ARGS, __BPF_V, __VA_ARGS__)) #define BPF_CALL_1(name, ...) BPF_CALL_x(1, name, __VA_ARGS__) The notrace attribute is actually applied to the static always_inline funct= ion ____bpf_spin_{lock,unlock}(). The actual callback function bpf_spin_{lock,unlock}() is not marked with notrace, hence allowing fentry prog to attach to two helpers, and this may cause the above mentioned deadlock. Siddharth Chintamaneni actually has a reproducer in [2]. To fix the issue, a new macro NOTRACE_BPF_CALL_1 is introduced which will add notrace attribute to the original function instead of the hidden always_inline function and this fixed the problem. [1] https://lore.kernel.org/bpf/CAE5sdEigPnoGrzN8WU7Tx-h-iFuMZgW06qp0KHWt= pvoXxf1OAQ@mail.gmail.com/ [2] https://lore.kernel.org/bpf/CAE5sdEg6yUc_Jz50AnUXEEUh6O73yQ1Z6NV2srJn= ef0ZrQkZew@mail.gmail.com/ Fixes: d83525ca62cf ("bpf: introduce bpf_spin_lock") Signed-off-by: Yonghong Song Signed-off-by: Andrii Nakryiko Acked-by: Jiri Olsa Link: https://lore.kernel.org/bpf/20240207070102.335167-1-yonghong.song@lin= ux.dev Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- include/linux/filter.h | 21 ++++++++++++--------- kernel/bpf/helpers.c | 4 ++-- 2 files changed, 14 insertions(+), 11 deletions(-) diff --git a/include/linux/filter.h b/include/linux/filter.h index 68fb6c8142fec..f537a394c42d0 100644 --- a/include/linux/filter.h +++ b/include/linux/filter.h @@ -547,24 +547,27 @@ static inline bool insn_is_zext(const struct bpf_insn= *insn) __BPF_MAP(n, __BPF_DECL_ARGS, __BPF_N, u64, __ur_1, u64, __ur_2, \ u64, __ur_3, u64, __ur_4, u64, __ur_5) =20 -#define BPF_CALL_x(x, name, ...) \ +#define BPF_CALL_x(x, attr, name, ...) \ static __always_inline \ u64 ____##name(__BPF_MAP(x, __BPF_DECL_ARGS, __BPF_V, __VA_ARGS__)); \ typedef u64 (*btf_##name)(__BPF_MAP(x, __BPF_DECL_ARGS, __BPF_V, __VA_ARG= S__)); \ - u64 name(__BPF_REG(x, __BPF_DECL_REGS, __BPF_N, __VA_ARGS__)); \ - u64 name(__BPF_REG(x, __BPF_DECL_REGS, __BPF_N, __VA_ARGS__)) \ + attr u64 name(__BPF_REG(x, __BPF_DECL_REGS, __BPF_N, __VA_ARGS__)); \ + attr u64 name(__BPF_REG(x, __BPF_DECL_REGS, __BPF_N, __VA_ARGS__)) \ { \ return ((btf_##name)____##name)(__BPF_MAP(x,__BPF_CAST,__BPF_N,__VA_ARGS= __));\ } \ static __always_inline \ u64 ____##name(__BPF_MAP(x, __BPF_DECL_ARGS, __BPF_V, __VA_ARGS__)) =20 -#define BPF_CALL_0(name, ...) BPF_CALL_x(0, name, __VA_ARGS__) -#define BPF_CALL_1(name, ...) BPF_CALL_x(1, name, __VA_ARGS__) -#define BPF_CALL_2(name, ...) BPF_CALL_x(2, name, __VA_ARGS__) -#define BPF_CALL_3(name, ...) BPF_CALL_x(3, name, __VA_ARGS__) -#define BPF_CALL_4(name, ...) BPF_CALL_x(4, name, __VA_ARGS__) -#define BPF_CALL_5(name, ...) BPF_CALL_x(5, name, __VA_ARGS__) +#define __NOATTR +#define BPF_CALL_0(name, ...) BPF_CALL_x(0, __NOATTR, name, __VA_ARGS__) +#define BPF_CALL_1(name, ...) BPF_CALL_x(1, __NOATTR, name, __VA_ARGS__) +#define BPF_CALL_2(name, ...) BPF_CALL_x(2, __NOATTR, name, __VA_ARGS__) +#define BPF_CALL_3(name, ...) BPF_CALL_x(3, __NOATTR, name, __VA_ARGS__) +#define BPF_CALL_4(name, ...) BPF_CALL_x(4, __NOATTR, name, __VA_ARGS__) +#define BPF_CALL_5(name, ...) BPF_CALL_x(5, __NOATTR, name, __VA_ARGS__) + +#define NOTRACE_BPF_CALL_1(name, ...) BPF_CALL_x(1, notrace, name, __VA_AR= GS__) =20 #define bpf_ctx_range(TYPE, MEMBER) \ offsetof(TYPE, MEMBER) ... offsetofend(TYPE, MEMBER) - 1 diff --git a/kernel/bpf/helpers.c b/kernel/bpf/helpers.c index d19cd863d294e..b10092754dde3 100644 --- a/kernel/bpf/helpers.c +++ b/kernel/bpf/helpers.c @@ -334,7 +334,7 @@ static inline void __bpf_spin_lock_irqsave(struct bpf_s= pin_lock *lock) __this_cpu_write(irqsave_flags, flags); } =20 -notrace BPF_CALL_1(bpf_spin_lock, struct bpf_spin_lock *, lock) +NOTRACE_BPF_CALL_1(bpf_spin_lock, struct bpf_spin_lock *, lock) { __bpf_spin_lock_irqsave(lock); return 0; @@ -357,7 +357,7 @@ static inline void __bpf_spin_unlock_irqrestore(struct = bpf_spin_lock *lock) local_irq_restore(flags); } =20 -notrace BPF_CALL_1(bpf_spin_unlock, struct bpf_spin_lock *, lock) +NOTRACE_BPF_CALL_1(bpf_spin_unlock, struct bpf_spin_lock *, lock) { __bpf_spin_unlock_irqrestore(lock); return 0; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 97DC214E2E5; Sun, 24 Mar 2024 22:38:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319891; cv=none; b=Snbmbvtv1IcQC3vX6wvjUUe2XRinJMNnOdo5tJfib8IR6ra0BqEY4xMgsuv7v1jDO6gWIIVPItRzp3eC0tN+Vce/bPuvrenUQ/s5A/QGMts74qmNhtttDcaYukv5NBXAN6f1bAub+f/y9LuyxyqLXDEAoHpHtMSzDuSGP4XSJIo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319891; c=relaxed/simple; bh=nTdHPVEhp+m6EDgmRo0XGumx0slog8xFkDKuDFI+Krk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SvTvG5HG31nriMoDoU88cbOucuilV/1iju9NQSioOjCNvC3X4kY4HYBk3hPabXgfiXSMloHvM+Ua9cZixdpb7RTmtP9w1DGVmrj9A3g4Jekxb5QDUiGGK5Z4UKelM1FBNYl631iYB8nzjqc8HOsIkr+QIPP1o+gTFpqaRpat/7g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fV0gYiMV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fV0gYiMV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3CECC43390; Sun, 24 Mar 2024 22:38:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319891; bh=nTdHPVEhp+m6EDgmRo0XGumx0slog8xFkDKuDFI+Krk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fV0gYiMVuDPpMUbBC5+ASAq3lH4Qv7Bng/CQTNTZNR1ekI9uPAmmrcpRoimSUnyFL Q6a/3tQDx95M7UgjfH9oojR+S8qUcbJOm22jPCyLYU0u3dAXgEBaSJXmP00u7c5PmU uvBxLyG96esaemRmAq9BLiXjkD/+myVoWmL8jbXflm3SC5YJEW8kKT4q0NMA1fHLzh tmXaHfkUioD1Dyz4Zs3TApibaiq1q4Ece91jEh3t0JbgW0kjIOzXIQ+twZOjIo2OMd 5Msh4G6m0TtFB3mQdag52tOUcnvbMBiSERVo+DOe1yYEhE/RhfeEuLayMDFqqdZoKo pf9DdPKWXJDbQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrii Nakryiko , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 196/715] bpf: don't infer PTR_TO_CTX for programs with unnamed context type Date: Sun, 24 Mar 2024 18:26:15 -0400 Message-ID: <20240324223455.1342824-197-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrii Nakryiko [ Upstream commit 879bbe7aa4afa80acf72a1cad7f52416ea78c52d ] For program types that don't have named context type name (e.g., BPF iterator programs or tracepoint programs), ctx_tname will be a non-NULL empty string. For such programs it shouldn't be possible to have PTR_TO_CTX argument for global subprogs based on type name alone. arg:ctx tag is the only way to have PTR_TO_CTX passed into global subprog for such program types. Fix this loophole, which currently would assume PTR_TO_CTX whenever user uses a pointer to anonymous struct as an argument to their global subprogs. This happens in practice with the following (quite common, in practice) approach: typedef struct { /* anonymous */ int x; } my_type_t; int my_subprog(my_type_t *arg) { ... } User's intent is to have PTR_TO_MEM argument for `arg`, but verifier will complain about expecting PTR_TO_CTX. This fix also closes unintended s390x-specific KPROBE handling of PTR_TO_CTX case. Selftest change is necessary to accommodate this. Fixes: 91cc1a99740e ("bpf: Annotate context types") Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20240212233221.2575350-4-andrii@kernel.org Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/bpf/btf.c | 3 +++ .../bpf/progs/test_global_func_ctx_args.c | 19 +++++++++++++++++++ 2 files changed, 22 insertions(+) diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c index 92aa3cf0396b8..9041848cf1a1b 100644 --- a/kernel/bpf/btf.c +++ b/kernel/bpf/btf.c @@ -5685,6 +5685,9 @@ btf_get_prog_ctx_type(struct bpf_verifier_log *log, c= onst struct btf *btf, bpf_log(log, "Please fix kernel include/linux/bpf_types.h\n"); return NULL; } + /* program types without named context types work only with arg:ctx tag */ + if (ctx_tname[0] =3D=3D '\0') + return false; /* only compare that prog's ctx type name is the same as * kernel expects. No need to compare field by field. * It's ok for bpf prog to do: diff --git a/tools/testing/selftests/bpf/progs/test_global_func_ctx_args.c = b/tools/testing/selftests/bpf/progs/test_global_func_ctx_args.c index 9a06e5eb1fbef..143c8a4852bfe 100644 --- a/tools/testing/selftests/bpf/progs/test_global_func_ctx_args.c +++ b/tools/testing/selftests/bpf/progs/test_global_func_ctx_args.c @@ -26,6 +26,23 @@ int kprobe_typedef_ctx(void *ctx) return kprobe_typedef_ctx_subprog(ctx); } =20 +/* s390x defines: + * + * typedef user_pt_regs bpf_user_pt_regs_t; + * typedef struct { ... } user_pt_regs; + * + * And so "canonical" underlying struct type is anonymous. + * So on s390x only valid ways to have PTR_TO_CTX argument in global subpr= ogs + * are: + * - bpf_user_pt_regs_t *ctx (typedef); + * - struct bpf_user_pt_regs_t *ctx (backwards compatible struct hack); + * - void *ctx __arg_ctx (arg:ctx tag) + * + * Other architectures also allow using underlying struct types (e.g., + * `struct pt_regs *ctx` for x86-64) + */ +#ifndef bpf_target_s390 + #define pt_regs_struct_t typeof(*(__PT_REGS_CAST((struct pt_regs *)NULL))) =20 __weak int kprobe_struct_ctx_subprog(pt_regs_struct_t *ctx) @@ -40,6 +57,8 @@ int kprobe_resolved_ctx(void *ctx) return kprobe_struct_ctx_subprog(ctx); } =20 +#endif + /* this is current hack to make this work on old kernels */ struct bpf_user_pt_regs_t {}; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C4B8414F9C9; Sun, 24 Mar 2024 22:38:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319892; cv=none; b=J9X1iGcveLtn2lTPUVJucLyRNrhKp/ILcxJWk3kQ1Kyvh+CW3EuThbJ/HzW/wndV9Rt0eiyvKdgzIUI4Rg+tAvi06HN8OL3tTMerxmEiuWuBQH6dn1BzkH0qvJ+HKtAyMXquEGn8xM4YCM6yXsYewcqZIyYTjiW/GAiRwJBtisE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319892; c=relaxed/simple; bh=W/eocuTimWRq8wjEAwfXhQK4vhU5I4Kc5f4DFkIO8S8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fIA3zk/xqRGBcRXAhKK6MwIdj403AFS0z9l0sFpcW1aaTfjG0FAvuLHrsQvrZBVrUsVti1WJaJXAQY3Fj4nnQ+oztcm4u9GQuLkSs0THNAa93RLobyjgH8wgpE7CIbk6zXtoDmWVb+2KeI+Ff5iR6NRtAi3QSqpBuWaMeM0JY+E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cNfNWj4K; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cNfNWj4K" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE4F9C43390; Sun, 24 Mar 2024 22:38:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319892; bh=W/eocuTimWRq8wjEAwfXhQK4vhU5I4Kc5f4DFkIO8S8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cNfNWj4KcdIMmiMbE7HhULFil/Mrvs6Gv3QK612vDLYcaOYgMHYPf62+k+pDbfUxW gJ+9EvBMnqoeTmC2Tz6HFIAfi43b7v6otoWPRL4SBt4ktZD3pUR6tEht24KJpNqhdM 0vkNY+3z+BtkOAcZ/VWgMDpoMqS0R8OZyabGKs+86JxgRjHFCmeyNaJs0tsLN9wBVC l1oztDKDmE0kLc9CpoloVETN9rpcT6YM9y+VYTrYqtTVsoEleALIO96K0QXE76dh1q cyezY+yx208YQwUfe9IOABT8VG3LE9IhEetChsO6WmEYeXeNiX6pfDuu+Px0j7ZAOa u4fQGT1KQ7f0Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 197/715] arm64: dts: qcom: sdm845: Use the Low Power Island CX/MX for SLPI Date: Sun, 24 Mar 2024 18:26:16 -0400 Message-ID: <20240324223455.1342824-198-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit 5dd227ccfb9568935bdaf82bc1893b36457dd4d3 ] The SLPI is powered by the Low Power Island power rails. Fix the incorrect assignment. Fixes: 74588aada59a ("arm64: dts: qcom: sdm845: add SLPI remoteproc") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20231220-topic-sdm845_slpi_lcxmx-v1-1-db7c7= 2ef99ae@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qco= m/sdm845.dtsi index c2244824355a2..237d404861424 100644 --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi @@ -3366,8 +3366,8 @@ slpi_pas: remoteproc@5c00000 { =20 qcom,qmp =3D <&aoss_qmp>; =20 - power-domains =3D <&rpmhpd SDM845_CX>, - <&rpmhpd SDM845_MX>; + power-domains =3D <&rpmhpd SDM845_LCX>, + <&rpmhpd SDM845_LMX>; power-domain-names =3D "lcx", "lmx"; =20 memory-region =3D <&slpi_mem>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 982B914E2CB; Sun, 24 Mar 2024 22:38:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319893; cv=none; b=iVC3nD5ZPxjIxRBxZcZ0mShpSH1fka0Iohji+/ZZatUz3sLvYi2Ft4W7x/QCg3q/CsUOEHc7oKl+wKB5kJaF2Iy5K19fNWPqobYdWGE50olhRbX6G0lvbTsXnsR9QwdHTNL6JHIuOTWdQge7jpLUJq6UjZsvvWYDhzW7eam6ORo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319893; c=relaxed/simple; bh=XTfxCywVWqK8pg6d8yIzBn4qNjzARm/lWyecsJM7WN4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sRroTQC1kZd1ZsQCBusinUgqyl8a9qDwukUA+43e9VIo+qUXtapZe6TSmKHs0E/5Hz7T496EZ51BWTvdJLpAW+Xlx/+KK4WhCQ3csga9Bq8YNbnh64TdGffPa8fjLEzvZVD6uvtgU3MtKNvzz6pwwBHl5kf4J5tQVPYHifGeHJY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ncNvJONy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ncNvJONy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A945DC433F1; Sun, 24 Mar 2024 22:38:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319893; bh=XTfxCywVWqK8pg6d8yIzBn4qNjzARm/lWyecsJM7WN4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ncNvJONyaP6kt2ROV4iOu1+JJLgeB0n0EnZB3etS8QTS5bE9AmSuNtsY9fDriIvht 61JSNojzt81Zd+dB/mJGJ2H9eQFknRoZDZuhBhGu3uswNGyBWVYUdPmMaK7TU7MdMW TCVzVMo9AlbJKZsegHpf1IVTSFfPUZdXwE7HikSh1c/GHYwtlAbo4ptGYo00ugJdRT Sj23j6Ajx/S765tGNNH/JHckZK3Pweb0lgcTX9Lp7qNld/iALARc62yuyP8dMuiEst ncx4jfQqlM2SD38Qk6Pd9qw97BLbj+atO9uGm4ijEuR9tIDOo4Vm/+zPD9EZePgzuy B+4LuuFO4cNLA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Unnathi Chalicheemala , Elliot Berman , Mukesh Ojha , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 198/715] soc: qcom: llcc: Check return value on Broadcast_OR reg read Date: Sun, 24 Mar 2024 18:26:17 -0400 Message-ID: <20240324223455.1342824-199-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Unnathi Chalicheemala [ Upstream commit ceeaddc19a90039861564d8e1078b778a8f95101 ] Commit c72ca343f911 ("soc: qcom: llcc: Add v4.1 HW version support") introduced a new 4.1 if statement in llcc_update_act_ctrl() without considering that ret might be overwritten. So, add return value check after Broadcast_OR register read in llcc_update_act_ctrl(). Fixes: c72ca343f911 ("soc: qcom: llcc: Add v4.1 HW version support") Signed-off-by: Unnathi Chalicheemala Reviewed-by: Elliot Berman Reviewed-by: Mukesh Ojha Link: https://lore.kernel.org/r/20240212183515.433873-1-quic_uchalich@quici= nc.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/soc/qcom/llcc-qcom.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/soc/qcom/llcc-qcom.c b/drivers/soc/qcom/llcc-qcom.c index 4ca88eaebf06a..cbef0dea1d5d7 100644 --- a/drivers/soc/qcom/llcc-qcom.c +++ b/drivers/soc/qcom/llcc-qcom.c @@ -859,6 +859,8 @@ static int llcc_update_act_ctrl(u32 sid, ret =3D regmap_read_poll_timeout(drv_data->bcast_regmap, status_reg, slice_status, !(slice_status & status), 0, LLCC_STATUS_READ_DELAY); + if (ret) + return ret; =20 if (drv_data->version >=3D LLCC_VERSION_4_1_0_0) ret =3D regmap_write(drv_data->bcast_regmap, act_clear_reg, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB3CA150990; Sun, 24 Mar 2024 22:38:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319895; cv=none; b=hveICqaqWBY4+G7iyPVMxqMiMhs90cV5ZmEMTF3reKRWpG07D68ek7cPNKmR1nBzrrw3PXh3nYes80SxrkbjbkIh0uoGIvIASShM99AXY6L5UNLu0gi8BJ3NSVuiGd4cF2NJ8120YzDImn0xrfdBPovStlzckKrhfRKZSNZZcmk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319895; c=relaxed/simple; bh=gEgFcLLDiBB0JVgk2uIkggn1J6MoZu+KA+98Ajlgd48=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UZrftRhCQXz+9fJwlqh1B/zmfMlak3Hpwn/xRTkKs/i57JGgJHAsd6YBMi00LIP0W6hgO4FEjnnwNZymH9aepZW8b5C4VMb3Q9Z1aWFNvpDrfURtsolkG3NY7SR27S9DjjLged9hptgj3q5tH05zlC6SWcMkN6bV/qCns+I0cCM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sMagzXjB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sMagzXjB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B94A0C43390; Sun, 24 Mar 2024 22:38:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319894; bh=gEgFcLLDiBB0JVgk2uIkggn1J6MoZu+KA+98Ajlgd48=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sMagzXjB3s/QvWZleOk5ThrR2IQoHBohJLP/BR/LpSl63oa8aaZKbPbT9LumQU7fd YvlzJmvez257TRbY/i6kxpA3SoMANg/0eGiCewFebD2cXQM5zWdRXvKCCf4SVa3M8R 8dFDdX+5eVPPNpkoG1nfb9EW024L84U+Ibga+Lg8vvKb6jKgdcPivjQ+rlcEVwvQvX Bbv50xHdZ4Bp4fadFGTe7UrT2/qFmpGH5H9jEWZuV8+JrRPoOiM4tCqTEwqPnMBmh2 IqH+pV3Y40LRss/P7SHSuvHs/JM3kxCx8x6FFMOrxGGE4fULRhLueFYiTZX+PJRp4W lkHp0Ymga5yAg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Craig Tatlor , Luca Weiss , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 199/715] ARM: dts: qcom: msm8974: correct qfprom node size Date: Sun, 24 Mar 2024 18:26:18 -0400 Message-ID: <20240324223455.1342824-200-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Craig Tatlor [ Upstream commit 724c4bf0e4bf81dba77736afb93964c986c3c123 ] The qfprom actually is bigger than 0x1000, so adjust the reg. Note that the non-ECC-corrected qfprom can be found at 0xfc4b8000 (-0x4000). The current reg points to the ECC-corrected qfprom block which should have equivalent values at all offsets compared to the non-corrected version. [luca@z3ntu.xyz: extract to standalone patch and adjust for review comments] Fixes: c59ffb519357 ("arm: dts: msm8974: Add thermal zones, tsens and qfpro= m nodes") Signed-off-by: Craig Tatlor Signed-off-by: Luca Weiss Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240210-msm8974-qfprom-v3-1-26c424160334@z= 3ntu.xyz Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm/boot/dts/qcom/qcom-msm8974.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi b/arch/arm/boot/dts/q= com/qcom-msm8974.dtsi index b1413983787c2..083ab780ab7e4 100644 --- a/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi +++ b/arch/arm/boot/dts/qcom/qcom-msm8974.dtsi @@ -1234,7 +1234,7 @@ restart@fc4ab000 { =20 qfprom: qfprom@fc4bc000 { compatible =3D "qcom,msm8974-qfprom", "qcom,qfprom"; - reg =3D <0xfc4bc000 0x1000>; + reg =3D <0xfc4bc000 0x2100>; #address-cells =3D <1>; #size-cells =3D <1>; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9F1731509A3; Sun, 24 Mar 2024 22:38:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319895; cv=none; b=ueUG051OoVxurR9EOvRzObXNdPf45T+4T9q2azsFRf6rC+2LRKP6kPWtfzmemqCDXWiyGtTfaK+3p2Jq5XKhTmscaNRsURqoH31JpmVoV49q0R83q7Kgm+ratBqUuVka16Tyvt6oqLxn3kkXHXyYakurIFbeK7ZeH+5+W17tG/M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319895; c=relaxed/simple; bh=0BWxCl2nFw/sJ7Q83TuBcBmbqeMeajlBN2JcRS5sjwQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=TSQ4kj274gZap6jvCQjeFnbB5RMwyPyQoMnl7wBqelHDBtryo58UMu5s9vtElO2kSkM9o8rQKWJJSYmxTiVMT1f3Y9VGm23SRrP8m3hdxNHiAIyC6YEULGuqR4bSSd2IE3+kNCfUECBxE0L98s+il2MHAsjM5DdrqhhdXe46B0g= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p8y7mQ2r; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p8y7mQ2r" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDBB8C433A6; Sun, 24 Mar 2024 22:38:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319895; bh=0BWxCl2nFw/sJ7Q83TuBcBmbqeMeajlBN2JcRS5sjwQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p8y7mQ2rmiqlrzlB4v8ITpKAvvfvl3Dt8AVn59Ae9gg017Dqel788Z88wAG2kjZvX juqsZoxka/Lydshtz16DDsTOC8/Oqkkkw9+OdEvOG51uevKOJ148Vs1/46lvB1ZwDw epsYB+koEZsg8EDcGy+jTDWBD5syaTIp0p+AY7jeydnHNT5Fco22BYCiM8WyQ4tL6y pClvSz5NK31x7sljJx4qoWEhRCr8z72FIhDyCal3R7hEIJimtOH23iaqIgVUrDhsWe O6jAL2xZDVZd4axBYMGHDPAp+dvVBJlWWzAxdshXRYWSo3BvcR65XwT4DDTBDHBVIL mFz+7+h4AMWTQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= , AngeloGioacchino Del Regno , Sasha Levin Subject: [PATCH 6.8 200/715] arm64: dts: mediatek: mt8186: Add missing clocks to ssusb power domains Date: Sun, 24 Mar 2024 18:26:19 -0400 Message-ID: <20240324223455.1342824-201-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: N=C3=ADcolas F. R. A. Prado [ Upstream commit a00d4a98af44e025891e97c490b2545368a25e08 ] The ssusb power domains currently don't list any clocks, despite depending on some, and thus rely on the bootloader leaving the required clocks on in order to work. When booting with the upstream arm64 defconfig, the power domain controller will defer probe until modules have loaded since it has an indirect dependency on CONFIG_MTK_CMDQ, which is configured as a module. However at the point where modules are loaded, unused clocks are also disabled, causing the ssusb domains to fail to be enabled and consequently the controller to fail probe: mtk-power-controller 10006000.syscon:power-controller: /soc/syscon@10006000= /power-controller/power-domain@4: failed to power on domain: -110 mtk-power-controller: probe of 10006000.syscon:power-controller failed with= error -110 Add the missing clocks for the ssusb power domains so that they can successfully probe without relying on the bootloader state. Fixes: d9e43c1e7a38 ("arm64: dts: mt8186: Add power domains controller") Signed-off-by: N=C3=ADcolas F. R. A. Prado Link: https://lore.kernel.org/r/20240213-mt8186-ssusb-domain-clk-fix-v2-1-1= f981d35f3fd@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt8186.dtsi | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts= /mediatek/mt8186.dtsi index ee0feadbf9619..4fd25f0f313d2 100644 --- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi @@ -931,11 +931,17 @@ power-domain@MT8186_POWER_DOMAIN_CSIRX_TOP { =20 power-domain@MT8186_POWER_DOMAIN_SSUSB { reg =3D ; + clocks =3D <&topckgen CLK_TOP_USB_TOP>, + <&infracfg_ao CLK_INFRA_AO_SSUSB_TOP_REF>; + clock-names =3D "sys_ck", "ref_ck"; #power-domain-cells =3D <0>; }; =20 power-domain@MT8186_POWER_DOMAIN_SSUSB_P1 { reg =3D ; + clocks =3D <&infracfg_ao CLK_INFRA_AO_SSUSB_TOP_P1_SYS>, + <&infracfg_ao CLK_INFRA_AO_SSUSB_TOP_P1_REF>; + clock-names =3D "sys_ck", "ref_ck"; #power-domain-cells =3D <0>; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB647152DE1; Sun, 24 Mar 2024 22:38:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319896; cv=none; b=hpawrQsnvGP4JrlaaV3+wZBTVJJ0TRyDecF3VQ/0epckMqp+nddP5nlUkN2ogM7cUkApN56yXeO0PfaVfeTf7/q8BXIN+l2eESDFAhP3F9ILITYF92vAn/qPxdDmXNSo1xnnMeXuJV48SvWqTi8DHW3BsisPke0QQ7hSnRlu7Nk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319896; c=relaxed/simple; bh=8AaEs2Sq3uwPfjgBGNCVId+9i+0GuIBA1mhuf3MjHLg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dwzWYxXLAC0+vDpfzcZeaRZ5Ki3hy8qQ7Ziai3d73vUNHA9dxfsvNnbMoRec790MRsWV/fo43REmZHg27z1cUrh/3twffOHnO637GgXC5nIZEfTwJ1UscDZRFqeBmsmwXlBFIpBZqFRlW88PsjKDFNVhKYy6q4HHnKUzjjFrUF8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=D6WxaeLC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="D6WxaeLC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3248C433C7; Sun, 24 Mar 2024 22:38:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319896; bh=8AaEs2Sq3uwPfjgBGNCVId+9i+0GuIBA1mhuf3MjHLg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=D6WxaeLCPq9bLkSCWii6FuveW0hO88Dhgm+5jQLEjDld894qh2cK4LxUiQrMjc9nW HHMUROzVN6Kgoi6w1+YxjYRiOVmOEdvPtbL6lyVOxp6p3z7SjlAdgQKmZGVycqXTgJ fTyfT1iCdIDJ7FlBG4XjB9SpbeC4rvVQ1U0AoC/UnlUMxpThbN8A+lDYjkAKo2X3Fb vvJ8j5KovFFcTBPy8t9v2r+TMj3fjbayKqKoYnOlyO76/nwZeAvEWR7tB1pOU+TFWT BAeg9Jmwbc99+LLVFLA5NZdMQ3ZK4zlcwXJT2iNVeq9GXNimYo0OfFLjoU8nVjr+4l D3px3jxvzhsAQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?N=C3=ADcolas=20F=2E=20R=2E=20A=2E=20Prado?= , AngeloGioacchino Del Regno , Sasha Levin Subject: [PATCH 6.8 201/715] arm64: dts: mediatek: mt8186: Add missing xhci clock to usb controllers Date: Sun, 24 Mar 2024 18:26:20 -0400 Message-ID: <20240324223455.1342824-202-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: N=C3=ADcolas F. R. A. Prado [ Upstream commit 1af98c3e53da5a8f627855cecd68b017e753ffd3 ] The mtu3 usb controllers don't list the xhci clock, though they require it, and thus rely on the bootloader leaving it on in order to work. When booting with the upstream arm64 defconfig, the usb controllers will defer probe until modules have loaded since they have an indirect dependency on CONFIG_MTK_CMDQ, which is configured as a module. However at the point where modules are loaded, unused clocks are also disabled, causing the usb controllers to probe without the xhci clock enabled and fail to probe: mtu3 11201000.usb: clks of sts1 are not stable! mtu3 11201000.usb: device enable failed -110 mtu3 11201000.usb: mtu3 hw init failed:-110 mtu3 11201000.usb: failed to initialize gadget mtu3: probe of 11201000.usb failed with error -110 (and same for the one at 11281000) Add the missing clock for the usb controllers so that they can successfully probe without relying on the bootloader state. Fixes: f6c3e61c5486 ("arm64: dts: mediatek: mt8186: Add MTU3 nodes") Signed-off-by: N=C3=ADcolas F. R. A. Prado Link: https://lore.kernel.org/r/20240213-mt8186-ssusb-domain-clk-fix-v2-2-1= f981d35f3fd@collabora.com Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt8186.dtsi | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi b/arch/arm64/boot/dts= /mediatek/mt8186.dtsi index 4fd25f0f313d2..84ec6c1aa12b9 100644 --- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi +++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi @@ -1536,8 +1536,9 @@ ssusb0: usb@11201000 { clocks =3D <&topckgen CLK_TOP_USB_TOP>, <&infracfg_ao CLK_INFRA_AO_SSUSB_TOP_REF>, <&infracfg_ao CLK_INFRA_AO_SSUSB_TOP_HCLK>, - <&infracfg_ao CLK_INFRA_AO_ICUSB>; - clock-names =3D "sys_ck", "ref_ck", "mcu_ck", "dma_ck"; + <&infracfg_ao CLK_INFRA_AO_ICUSB>, + <&infracfg_ao CLK_INFRA_AO_SSUSB_TOP_XHCI>; + clock-names =3D "sys_ck", "ref_ck", "mcu_ck", "dma_ck", "xhci_ck"; interrupts =3D ; phys =3D <&u2port0 PHY_TYPE_USB2>; power-domains =3D <&spm MT8186_POWER_DOMAIN_SSUSB>; @@ -1601,8 +1602,9 @@ ssusb1: usb@11281000 { clocks =3D <&infracfg_ao CLK_INFRA_AO_SSUSB_TOP_P1_SYS>, <&infracfg_ao CLK_INFRA_AO_SSUSB_TOP_P1_REF>, <&infracfg_ao CLK_INFRA_AO_SSUSB_TOP_P1_HCLK>, - <&clk26m>; - clock-names =3D "sys_ck", "ref_ck", "mcu_ck", "dma_ck"; + <&clk26m>, + <&infracfg_ao CLK_INFRA_AO_SSUSB_TOP_P1_XHCI>; + clock-names =3D "sys_ck", "ref_ck", "mcu_ck", "dma_ck", "xhci_ck"; interrupts =3D ; phys =3D <&u2port1 PHY_TYPE_USB2>, <&u3port1 PHY_TYPE_USB3>; power-domains =3D <&spm MT8186_POWER_DOMAIN_SSUSB_P1>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AFF6A152DFC; Sun, 24 Mar 2024 22:38:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319897; cv=none; b=g7G3FyUExhAbFGWLd77YvEJ5DtXZogezo3J0KShUutR1s5xxxFCUl9qbbLUaBut3l5MVNa4a2xLUTUYZFNRB4xiPg5MljltHhu6bB+9kk2obR/q70hNWc+IZXcdc0lK2Ydow8RKwpMJCreNtROryjPFY8t8+Tv8AJWuLpTE15Hc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319897; c=relaxed/simple; bh=a6Ou2TGAoOsIm6LFpewaaxQoBqH4uC1WhR41znB/YTE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FJg9hDUskSaP0OQRCqYP9DU5Kzb2mNIHIfNPdeVIpBGCH/hbjyOCY2n7S6AfSnAYysnF5M0XxtN5oazDk8F6u6ah4YQdbV4NLWlqWVUAAcqB9KXX9ayRvlg6N6+YP/slN9IJ2Ow/QQ1IGL8RJs6MtL3xOACsKMpNQHobnHO+ZR0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IUcat1nT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IUcat1nT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98293C43601; Sun, 24 Mar 2024 22:38:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319897; bh=a6Ou2TGAoOsIm6LFpewaaxQoBqH4uC1WhR41znB/YTE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IUcat1nTEmcyLDilsI1Xl+P9ksoIcvwKig99eEmpzLy8DCqRTVmfS4AFaotowAp76 Ukvk5o8Cx4eEP7dXf7uUZ3MNF4eTdHoqDFg23z38SFUlf/x7K4TERp6WKJwj2s/Et9 DlbNGiTEFfRG9yucVaalusefHDzb/eA5PFG6EHW+gJp+JeLQyXzcfFaxtx6PbwuoGg ndy421iYCMZ/Bfnky4c4FjfMn/mRlLLL+fh5BND7D+H8xXF8HcV4rgO1K8LXSAa8Ip n0aTKh+/ATu/i5YQdyCPLR9m6fctUNewWJ//Jfc1P68K0YPNbJhPylL+CAsSp7GPrB Bl0ML899tCQ7g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Roger Quadros , Aradhya Bhatia , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 202/715] arm64: dts: ti: am65x: Fix dtbs_install for Rocktech OLDI overlay Date: Sun, 24 Mar 2024 18:26:21 -0400 Message-ID: <20240324223455.1342824-203-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Roger Quadros [ Upstream commit 8ada14cafc5e185c668198617cd1ab4f1d8d325a ] Add the overlay dtbo file to a Makefile target so it can be picked by the dtbs_install command. Fixes: b8690ed3d1d1 ("arm64: dts: ti: am65x: Add Rocktech OLDI panel DT ove= rlay") Signed-off-by: Roger Quadros Reviewed-by: Aradhya Bhatia Link: https://lore.kernel.org/r/20240208-for-v6-9-am65-overlays-2-0-v2-1-70= bae3e91597@kernel.org Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makef= ile index 52c1dc9103087..08ce34d21d5d0 100644 --- a/arch/arm64/boot/dts/ti/Makefile +++ b/arch/arm64/boot/dts/ti/Makefile @@ -57,6 +57,7 @@ dtb-$(CONFIG_ARCH_K3) +=3D k3-am654-base-board.dtb dtb-$(CONFIG_ARCH_K3) +=3D k3-am654-gp-evm.dtb dtb-$(CONFIG_ARCH_K3) +=3D k3-am654-evm.dtb dtb-$(CONFIG_ARCH_K3) +=3D k3-am654-idk.dtb +dtb-$(CONFIG_ARCH_K3) +=3D k3-am654-base-board-rocktech-rk101-panel.dtbo =20 # Boards with J7200 SoC k3-j7200-evm-dtbs :=3D k3-j7200-common-proc-board.dtb k3-j7200-evm-quad-po= rt-eth-exp.dtbo --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 60577152E14; Sun, 24 Mar 2024 22:38:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319898; cv=none; b=KF70yuTTP2hCI6RMLYnuT3DZAMV2FWX2vXgFMSCtVyH6959O/n3g/guz4sPDAK7umdsZIHTI/Ei/Jl/ccUxfi0e4pz4wZRlQpMxNUcCyGP07thrzA14oyxJSwX5aF74OwD+59KZf8LaoAGkKYs0eA4jXMT/zv2SxrCrtBIwsdwY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319898; c=relaxed/simple; bh=qkyyFxehdzwxsIPB2u6hGwdn4DIIGZjJoaAfpK7eZzw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=f4/HQ+JG3uZ2UD/O2Q50gXkvBk2h3anSjebb46m2gugls1V215WUCwzpo6ZSw+Q5pe23QIdKWM3ZAKKPVTMtgALuYcVrz6M1dS4t8TbGEyWJ+tfD1Ma3ameOLvV7IyTMxrrY2LmOSGTVKLHh993mJm/DiUx8KLBDcbKIagI25ko= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tKgvWbIJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tKgvWbIJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 94856C43399; Sun, 24 Mar 2024 22:38:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319898; bh=qkyyFxehdzwxsIPB2u6hGwdn4DIIGZjJoaAfpK7eZzw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=tKgvWbIJFpLxfklYqX5XfJi1WtQzt6EAAdzTXCYofEn5rJLnKp+F5x7BB4+rsnkbZ cbEVq2WXwtGkW4Pe37Oq7LNf1j4wwMUX3a8+HobhWTGd9u1ge99SrKb6OlyCBNPnVi dnE/d7wNwYhgfY0fTeYz/gS04DrrsPH9w9eAqsjTdokadL6+ODpnlABqz5PTYa0Rus MSSrvVho0GgOL1q4QYyItkze3Hkjs4mjhpNrOvssalW7kZQue4MKNZyhApFf7pGQAA tA7+zTXiNOY8qFbbAKmOM2k171UklgFyDhhj6OckS4H0V/5hu/fcHfqgFf4hRE7tcs 4EOdxtUMrxv4A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Arnd Bergmann , Viresh Kumar , Sasha Levin Subject: [PATCH 6.8 203/715] cpufreq: qcom-hw: add CONFIG_COMMON_CLK dependency Date: Sun, 24 Mar 2024 18:26:22 -0400 Message-ID: <20240324223455.1342824-204-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnd Bergmann [ Upstream commit 3093fa33539b54db77171d2919352ad4f044a1c5 ] It is still possible to compile-test a kernel without CONFIG_COMMON_CLK for some ancient ARM boards or other architectures, but this causes a link failure in the qcom-cpufreq-hw driver: ERROR: modpost: "devm_clk_hw_register" [drivers/cpufreq/qcom-cpufreq-hw.ko]= undefined! ERROR: modpost: "devm_of_clk_add_hw_provider" [drivers/cpufreq/qcom-cpufreq= -hw.ko] undefined! ERROR: modpost: "of_clk_hw_onecell_get" [drivers/cpufreq/qcom-cpufreq-hw.ko= ] undefined! Add a Kconfig dependency here to make sure this always work. Apparently this bug has been in the kernel for a while without me running into it on randconfig builds as COMMON_CLK is almost always enabled. I have cross-checked by building an allmodconfig kernel with COMMON_CLK disabled, which showed no other driver having this problem. Fixes: 4370232c727b ("cpufreq: qcom-hw: Add CPU clock provider support") Signed-off-by: Arnd Bergmann Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/cpufreq/Kconfig.arm | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm index f911606897b8d..a0ebad77666e3 100644 --- a/drivers/cpufreq/Kconfig.arm +++ b/drivers/cpufreq/Kconfig.arm @@ -173,6 +173,7 @@ config ARM_QCOM_CPUFREQ_NVMEM config ARM_QCOM_CPUFREQ_HW tristate "QCOM CPUFreq HW driver" depends on ARCH_QCOM || COMPILE_TEST + depends on COMMON_CLK help Support for the CPUFreq HW driver. Some QCOM chipsets have a HW engine to offload the steps --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B95A1534F2; Sun, 24 Mar 2024 22:38:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319899; cv=none; b=o3JDsWT0NoJ0xCm+W4Pkiv1tTe5wE5KgF18Suucehs1Msj/bVgz7SU3xFTGSbPnWQdGgxCWwSWw1O2CEKJA3we+i3HLgtmIaib3BF046IcKrflpnIdO3LtLQdAhdFqqTY4u8t9iAQlbrGqRjco7Cay5FEDimJPkfOXrVwqHV0II= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319899; c=relaxed/simple; bh=l00MORsq8btbIiz1muHBw899LKnbLxaZxGNj39NOsa4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QVCFNZQKU3TOHoxBNndw16N+Zqz3OMP7Ufne29TahotHzSTgyPnU/Ciy1ctW6Ph7ux2vG8aabNAFV3MkeDMrEsQ9X59cYSE3DyEY21jO1R9kXOQEauUeDrmZFSWjliwf+SO/7YLPNtM7YIYbROHQshYhSbonFF5xDh/iZnCgn0A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DqxVsMmP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DqxVsMmP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C218C433C7; Sun, 24 Mar 2024 22:38:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319899; bh=l00MORsq8btbIiz1muHBw899LKnbLxaZxGNj39NOsa4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DqxVsMmPewPPHtpEt76e0o1wOQc7GM/7L1NgOVQzCX9JlK2kV/mAw68PQ/qoE01U2 CDJPUCSYHof/UyNQ0cx6yHntayjehVr+M4ZMPJrLfK0cmuTkVBTO3K4Sij5lgCmK8x dLczbkcz9zdpLTDR1JO70zvFEBP/+6UrMIM1P6zPjjWplVwgfHsj3Uy1qo16MO+QRN /71xV5E2eZGSiN2ivE4LEOOozB0xxLD1n5dM0eljuPLMCPnfWai5L6VRoQiCUClKjA BAAfC4m2CTAokoqTyggrQ5Q0FHFmSa9ArUZ4J1LhHyz1SnV4bhDeOfvsAHgKQL3Bjr iGm6dGYzKZ39A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Alexis=20Lothor=C3=A9?= , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 204/715] wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces Date: Sun, 24 Mar 2024 18:26:23 -0400 Message-ID: <20240324223455.1342824-205-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Alexis Lothor=C3=A9 [ Upstream commit cb5942b77c05d54310a0420cac12935e9b6aa21c ] wilc_netdev_cleanup currently triggers a KASAN warning, which can be observed on interface registration error path, or simply by removing the module/unbinding device from driver: echo spi0.1 > /sys/bus/spi/drivers/wilc1000_spi/unbind =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc Read of size 4 at addr c54d1ce8 by task sh/86 CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117 Hardware name: Atmel SAMA5 unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x58 dump_stack_lvl from print_report+0x154/0x500 print_report from kasan_report+0xac/0xd8 kasan_report from wilc_netdev_cleanup+0x508/0x5cc wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec wilc_bus_remove from spi_remove+0x8c/0xac spi_remove from device_release_driver_internal+0x434/0x5f8 device_release_driver_internal from unbind_store+0xbc/0x108 unbind_store from kernfs_fop_write_iter+0x398/0x584 kernfs_fop_write_iter from vfs_write+0x728/0xf88 vfs_write from ksys_write+0x110/0x1e4 ksys_write from ret_fast_syscall+0x0/0x1c [...] Allocated by task 1: kasan_save_track+0x30/0x5c __kasan_kmalloc+0x8c/0x94 __kmalloc_node+0x1cc/0x3e4 kvmalloc_node+0x48/0x180 alloc_netdev_mqs+0x68/0x11dc alloc_etherdev_mqs+0x28/0x34 wilc_netdev_ifc_init+0x34/0x8ec wilc_cfg80211_init+0x690/0x910 wilc_bus_probe+0xe0/0x4a0 spi_probe+0x158/0x1b0 really_probe+0x270/0xdf4 __driver_probe_device+0x1dc/0x580 driver_probe_device+0x60/0x140 __driver_attach+0x228/0x5d4 bus_for_each_dev+0x13c/0x1a8 bus_add_driver+0x2a0/0x608 driver_register+0x24c/0x578 do_one_initcall+0x180/0x310 kernel_init_freeable+0x424/0x484 kernel_init+0x20/0x148 ret_from_fork+0x14/0x28 Freed by task 86: kasan_save_track+0x30/0x5c kasan_save_free_info+0x38/0x58 __kasan_slab_free+0xe4/0x140 kfree+0xb0/0x238 device_release+0xc0/0x2a8 kobject_put+0x1d4/0x46c netdev_run_todo+0x8fc/0x11d0 wilc_netdev_cleanup+0x1e4/0x5cc wilc_bus_remove+0xc8/0xec spi_remove+0x8c/0xac device_release_driver_internal+0x434/0x5f8 unbind_store+0xbc/0x108 kernfs_fop_write_iter+0x398/0x584 vfs_write+0x728/0xf88 ksys_write+0x110/0x1e4 ret_fast_syscall+0x0/0x1c [...] David Mosberger-Tan initial investigation [1] showed that this use-after-free is due to netdevice unregistration during vif list traversal. When unregistering a net device, since the needs_free_netdev has been set to true during registration, the netdevice object is also freed, and as a consequence, the corresponding vif object too, since it is attached to it as private netdevice data. The next occurrence of the loop then tries to access freed vif pointer to the list to move forward in the list. Fix this use-after-free thanks to two mechanisms: - navigate in the list with list_for_each_entry_safe, which allows to safely modify the list as we go through each element. For each element, remove it from the list with list_del_rcu - make sure to wait for RCU grace period end after each vif removal to make sure it is safe to free the corresponding vif too (through unregister_netdev) Since we are in a RCU "modifier" path (not a "reader" path), and because such path is expected not to be concurrent to any other modifier (we are using the vif_mutex lock), we do not need to use RCU list API, that's why we can benefit from list_for_each_entry_safe. [1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a0= 7af967d2.camel@egauge.net/ Fixes: 8399918f3056 ("staging: wilc1000: use RCU list to maintain vif inter= faces list") Signed-off-by: Alexis Lothor=C3=A9 Signed-off-by: Kalle Valo Link: https://msgid.link/20240212-wilc_rework_deinit-v1-1-9203ae56c27f@boot= lin.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../net/wireless/microchip/wilc1000/netdev.c | 28 +++++-------------- 1 file changed, 7 insertions(+), 21 deletions(-) diff --git a/drivers/net/wireless/microchip/wilc1000/netdev.c b/drivers/net= /wireless/microchip/wilc1000/netdev.c index 6c1058e5299c7..6068699e44109 100644 --- a/drivers/net/wireless/microchip/wilc1000/netdev.c +++ b/drivers/net/wireless/microchip/wilc1000/netdev.c @@ -890,8 +890,7 @@ static const struct net_device_ops wilc_netdev_ops =3D { =20 void wilc_netdev_cleanup(struct wilc *wilc) { - struct wilc_vif *vif; - int srcu_idx, ifc_cnt =3D 0; + struct wilc_vif *vif, *vif_tmp; =20 if (!wilc) return; @@ -901,32 +900,19 @@ void wilc_netdev_cleanup(struct wilc *wilc) wilc->firmware =3D NULL; } =20 - srcu_idx =3D srcu_read_lock(&wilc->srcu); - list_for_each_entry_rcu(vif, &wilc->vif_list, list) { + list_for_each_entry_safe(vif, vif_tmp, &wilc->vif_list, list) { + mutex_lock(&wilc->vif_mutex); + list_del_rcu(&vif->list); + wilc->vif_num--; + mutex_unlock(&wilc->vif_mutex); + synchronize_srcu(&wilc->srcu); if (vif->ndev) unregister_netdev(vif->ndev); } - srcu_read_unlock(&wilc->srcu, srcu_idx); =20 wilc_wfi_deinit_mon_interface(wilc, false); destroy_workqueue(wilc->hif_workqueue); =20 - while (ifc_cnt < WILC_NUM_CONCURRENT_IFC) { - mutex_lock(&wilc->vif_mutex); - if (wilc->vif_num <=3D 0) { - mutex_unlock(&wilc->vif_mutex); - break; - } - vif =3D wilc_get_wl_to_vif(wilc); - if (!IS_ERR(vif)) - list_del_rcu(&vif->list); - - wilc->vif_num--; - mutex_unlock(&wilc->vif_mutex); - synchronize_srcu(&wilc->srcu); - ifc_cnt++; - } - wilc_wlan_cfg_deinit(wilc); wlan_deinit_locks(wilc); wiphy_unregister(wilc->wiphy); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E7BC15350D; Sun, 24 Mar 2024 22:38:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319900; cv=none; b=RApWwcH3l6JVwzswuPtdutABEFgHdUrijtiSr9KusQCyrneUPEULP9hQ5dYqk14ZrC3w12gWhZDTEd4LHpPKARW6xHwj5Ox2gcD5N9pHvptxLAajeFwT6zdWOybuTJU/+4tah0OqfPyu5H20z9gPpZ4yRtwB2YKHF0BkgIe2lhc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319900; c=relaxed/simple; bh=QF9tLI7gf/p9jDhZggGqID7Hb+pxEccMgbICkwA6//w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=q4wA5+VjFKXNcbxxulqxhhv1IMxjHNV46woJrl3zsXDTdlukGlES2FUkbvVg2/Su76JveBiEb0hyeEqqfMV0OK91WCl5yeraZobcF3psgPayYStljGtE44UL9xSY0kbjgpGKxG5C9FOB/I87ufj++MU2GDfCN3Zsx5QdX6FZc08= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Yj2RYXs/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Yj2RYXs/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63739C433F1; Sun, 24 Mar 2024 22:38:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319900; bh=QF9tLI7gf/p9jDhZggGqID7Hb+pxEccMgbICkwA6//w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Yj2RYXs/dZhMHGWQJYvY/ljBGNjmYjkwkqTILk36ps8DBIL19uu1/pDG5hAWzABYB 3yb9pN4IolioDNHZO0YunA85yqZiHMotdc4ZkNEbAgr8YALWJpia4POCSFgxG3U67y CjF2NRvN9Z0LkM3q152fQIJIPZEdDGSWXvPyWVBS1a+Nh3EU/BdxTMKpEA8szBtsgj FECbFbFG+J+vjPnuicgV2LCkC9AljfYNmEsakd7WbEUgFOTaXqXgiS4tZFDJoJMTUs j87QttewPWVBWaNHQGf4VLLkvyM1a1e1P9qrp0k3sXoOEcmsbWO5ZkkgyuGSr/2/VI tRyzH73ILbMQQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Raag Jadav , Andy Shevchenko , =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= , Sasha Levin Subject: [PATCH 6.8 205/715] pwm: dwc: use pm_sleep_ptr() macro Date: Sun, 24 Mar 2024 18:26:24 -0400 Message-ID: <20240324223455.1342824-206-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Raag Jadav [ Upstream commit 7cfce2b80d5ff7aa713a7710bfe3a562707cb226 ] Since we don't have runtime PM handles here, we should be using pm_sleep_ptr() macro, so that the compiler can discard it in case CONFIG_PM_SLEEP=3Dn. Fixes: 30b5b066fa83 ("pwm: dwc: Use DEFINE_SIMPLE_DEV_PM_OPS for PM functio= ns") Signed-off-by: Raag Jadav Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20240212130247.9985-2-raag.jadav@intel.com Signed-off-by: Uwe Kleine-K=C3=B6nig Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/pwm/pwm-dwc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pwm/pwm-dwc.c b/drivers/pwm/pwm-dwc.c index 4929354f8cd95..a4a057ae03ea2 100644 --- a/drivers/pwm/pwm-dwc.c +++ b/drivers/pwm/pwm-dwc.c @@ -120,7 +120,7 @@ static struct pci_driver dwc_pwm_driver =3D { .remove =3D dwc_pwm_remove, .id_table =3D dwc_pwm_id_table, .driver =3D { - .pm =3D pm_ptr(&dwc_pwm_pm_ops), + .pm =3D pm_sleep_ptr(&dwc_pwm_pm_ops), }, }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3E41E153BCD; Sun, 24 Mar 2024 22:38:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319901; cv=none; b=HXlluRs0JUiKE1TabZ3+EY3UCkiCEWpYK8wfnSVGzWAQySSihUp/U8opDIbHletyyK9zyd4M3nKM/WvM0U1cWLzLP6jQ2xYyCGuXgX1K91HdLCBkHGIh+/Ku3nIDcnNqtxIfQCvbfplE6AAq7lvZmmApfzoNJE49TRtMXb3DkYA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319901; c=relaxed/simple; bh=o1pdNCELQ9oh009glihFufrf0sK75GE00e/ZC4Jg/QU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cv/dvxVkBh+Bv0qLGhcpFAJnwlfeCTRcl+8AVRvsQwBpFeVQ2MeXCS/OaRGkj8LAlXB2nX2TB2vUkqDkyVTyzygE088uI7grCyiswDwxr8TPyuT+AJ2cgEtddkjrtVPya+KWgI8I1fPUObexLe9OhFLB2xetcgrh113Alyh562o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=p7Phdmpw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="p7Phdmpw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61823C43394; Sun, 24 Mar 2024 22:38:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319901; bh=o1pdNCELQ9oh009glihFufrf0sK75GE00e/ZC4Jg/QU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=p7PhdmpwEosxNfvFWbcj5DSLcAAnhrMMLDRlVisYkvPaOZ+9mwBq0iYlSjBgkSM78 18SX+7xY+qZ6Lbut3V0acg6pMr+9hWn4/LxHGZnBuuubasGF7nijKRHWPS7y2KXHCP MH753hoPtVtyktjkjQ+yfPXHQ1DtZOULN16PL8p8lAtvGEah7kcKppcC78TGA8PXhE a2x/wrAitBRuovDF3+fsSDlNKqjgL+Rlr0Wewxi6EtfJEAm+ZFX8g3milxB+QG5hKs WOCN05bSjTD/NW8JLpl0CxEHSGH9QhQtjCXg2Sr1yTUVZbkb4ia2mhSVt9mTw3DF42 S61iKDI3obJzQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Romain Naour , Neha Malcom Francis , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 206/715] arm64: dts: ti: k3-am69-sk: fix PMIC interrupt number Date: Sun, 24 Mar 2024 18:26:25 -0400 Message-ID: <20240324223455.1342824-207-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Romain Naour [ Upstream commit c205595e3b708c36ef2d7609b9182c6729bb06ae ] The tps659413 node set WKUP_GPIO0_83 (AA37) pin as input to be used as PMIC interrupt but uses 39 (WKUP_GPIO0_39) as "interrupts" property. Replace 39 by 83 after checking in the board schematic [1]. [1] https://www.ti.com/tool/SK-AM69 Fixes: 865a1593bf99 ("arm64: dts: ti: k3-am69-sk: Add support for TPS6594 P= MIC") Cc: Neha Malcom Francis Signed-off-by: Romain Naour Reviewed-by: Neha Malcom Francis Link: https://lore.kernel.org/r/20240209171146.307465-1-romain.naour@smile.= fr Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-am69-sk.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-am69-sk.dts b/arch/arm64/boot/dts/ti= /k3-am69-sk.dts index 370980eb59b02..c8fb9dfb89723 100644 --- a/arch/arm64/boot/dts/ti/k3-am69-sk.dts +++ b/arch/arm64/boot/dts/ti/k3-am69-sk.dts @@ -646,7 +646,7 @@ tps659413: pmic@48 { pinctrl-names =3D "default"; pinctrl-0 =3D <&pmic_irq_pins_default>; interrupt-parent =3D <&wkup_gpio0>; - interrupts =3D <39 IRQ_TYPE_EDGE_FALLING>; + interrupts =3D <83 IRQ_TYPE_EDGE_FALLING>; gpio-controller; #gpio-cells =3D <2>; ti,primary-pmic; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 391BF153BE9; Sun, 24 Mar 2024 22:38:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319902; cv=none; b=P5lZfohhvqvUz2sfVSXmpG7tca5Kq2RxakaWbaHyp5iCka5ysvC21T3lNADbFeSJLJBGEwjEeIQaAkITyJpAI4jVB7PDCUlHAWLq+tzMu1iKdQHwAW4JauGFI4LlkG2x5qTgi+8Tw4OmtaPVhp6auJWLSJOTHurOtq5xVZ5DyCQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319902; c=relaxed/simple; bh=7dpTwiOnZAO9FZsNTkOr0S+hOw0Zk3lrSPh8sthhtPc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UQe/zvivZQl7boVwtk19dPHXGDXX1+gFar6gzYUrMvduLt3yo8XmemBgIXAQAJXwQP6a4V7O9vPA7luputuznjKshT4h3DJPqrJQtgDjP+VkPpsxnJ19HJBc5Og/KACmNRwWkOsOfDEgOR3wycwlsFtbFv+wXm8XBrNoRMV3UIg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=D+iy6e2V; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="D+iy6e2V" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 61775C433C7; Sun, 24 Mar 2024 22:38:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319902; bh=7dpTwiOnZAO9FZsNTkOr0S+hOw0Zk3lrSPh8sthhtPc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=D+iy6e2V7k+waNzXR5eogm+mvENQhraIbTWoRYvgFAphpZjM34GZu5Q3ApJXfiVpi n6F1Sa1e0ideT6UduDs3HOopS+NrU6FULKHxXHScoPg2+UQ3QrWEotPOwXT6HyzUHC S5u3k90hQH86KIiZncVEh3iW0YpTrqn0IF8Y9ad+EcCCuM/MtIy8KPUqV8LEKqAMSi htm6RhB/rfFVo0s0V0ioQlDNpMnqdJSiY2vlWJGM9pnFeQWkctEeQrKi/YUhPgu1bO FUDkG0fZInH3sK8Qhzm9dMYB8qEuZhutgDXI8eNfUayFi5AMJvKyJ3lKF3YpN5XwPk GzfvDjmQlvTnQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Romain Naour , Neha Malcom Francis , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 207/715] arm64: dts: ti: k3-j721e-sk: fix PMIC interrupt number Date: Sun, 24 Mar 2024 18:26:26 -0400 Message-ID: <20240324223455.1342824-208-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Romain Naour [ Upstream commit 7f25d6926d178734db17cfc12f0b1841e82914da ] The tps659413 and tps659411 nodes set WKUP_GPIO0_7 (G28) pin as input to be used as PMIC interrupt but uses 9 (WKUP_GPIO0_9) as "interrupts" property. Replace 9 by 7 for both tps659413 and tps659411 after checking in the board schematic [1]. [1] https://www.ti.com/tool/SK-TDA4VM Fixes: b808cef0be46 ("arm64: dts: ti: k3-j721e-sk: Add TPS6594 family PMICs= ") Cc: Neha Malcom Francis Signed-off-by: Romain Naour Reviewed-by: Neha Malcom Francis Link: https://lore.kernel.org/r/20240209171146.307465-2-romain.naour@smile.= fr Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-j721e-sk.dts | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts b/arch/arm64/boot/dts/t= i/k3-j721e-sk.dts index 188dfe291a32b..658764f7d5443 100644 --- a/arch/arm64/boot/dts/ti/k3-j721e-sk.dts +++ b/arch/arm64/boot/dts/ti/k3-j721e-sk.dts @@ -574,7 +574,7 @@ tps659413: pmic@48 { pinctrl-names =3D "default"; pinctrl-0 =3D <&pmic_irq_pins_default>; interrupt-parent =3D <&wkup_gpio0>; - interrupts =3D <9 IRQ_TYPE_EDGE_FALLING>; + interrupts =3D <7 IRQ_TYPE_EDGE_FALLING>; gpio-controller; #gpio-cells =3D <2>; ti,primary-pmic; @@ -651,7 +651,7 @@ tps659411: pmic@4c { reg =3D <0x4c>; system-power-controller; interrupt-parent =3D <&wkup_gpio0>; - interrupts =3D <9 IRQ_TYPE_EDGE_FALLING>; + interrupts =3D <7 IRQ_TYPE_EDGE_FALLING>; gpio-controller; #gpio-cells =3D <2>; buck1234-supply =3D <&vsys_3v3>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 91F61154433; Sun, 24 Mar 2024 22:38:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319903; cv=none; b=TmNx7Rd+ebGcFF6TGpF25GUGeOhl5L4W8CMRETuupbRROWgBq9qC53Ki4cL3KEU974WtXjxXTaSPqFDh2OUEjrY4lS+i6MALBR6WLQSgrqZ5idjXVsR+//O+vJWOwDJ7cCMH0JHDTzbb3i80XVLKyp/dH+KdGCSKkjN+JCMP3hY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319903; c=relaxed/simple; bh=H+N6wK2nOlHM64kSMXDBu3o5Ttw2i8hWbdQcvOy8Jpc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Cs2K43lysA8gFGLW4nHScGnEb+8mKfmgl4xp+qVyb+YLfe/ue1Noi4VD6FzLAbeMb3WIxK3SMf/NtEXurIqN9UY2OICXybiLMaajjOMlD5GVeIZYjXbOWTxg5h1DEv0T2WROEbsX1roe6N60T+ZLjKU4Xggi0BVhmKdk334ePQs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cBmPdzbo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cBmPdzbo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AE28C43390; Sun, 24 Mar 2024 22:38:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319903; bh=H+N6wK2nOlHM64kSMXDBu3o5Ttw2i8hWbdQcvOy8Jpc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cBmPdzbofkxQcicuzwMsJmShkncnLLZyf8l4HMfM5IA5cC7j0l0KMK0fzn7tsHBq3 nipjJYWtOhZ1vRgAYT4YUwzBU3pzJk2fDqc2XiofQjn0L8qIjNXMg2f03sKczV4Owc dQHERKEY482zJET6Px9sScPoXXpjLt3gCwZ8Cy2K0+2z0n6JivnEkN+uHYf0QSQeOa OkWs7MbF3DWaihpYR/tYxAZlg/IdINaboukkmlel3YpDMxTzicaAAXn9EJqdU7IB4l ctd8crqYv53KRbdAINdAtFWdTvUxHjHHOtEeU+PvgfxzdMIVtvg33AkO8DqsAQSJ3Y QdVcb0yOm66bw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrejs Cainikovs , Francesco Dolcini , Roger Quadros , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 208/715] arm64: dts: ti: k3-am62-main: disable usb lpm Date: Sun, 24 Mar 2024 18:26:27 -0400 Message-ID: <20240324223455.1342824-209-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrejs Cainikovs [ Upstream commit 9c99b337a8755a09df7735d4324ae26a6eca6261 ] AM62 USB works with some devices, while failing to operate with others. [ 560.189822] xhci-hcd xhci-hcd.4.auto: xHCI Host Controller [ 560.195631] xhci-hcd xhci-hcd.4.auto: new USB bus registered, assigned b= us number 2 [ 574.388509] xhci-hcd xhci-hcd.4.auto: can't setup: -110 [ 574.393814] xhci-hcd xhci-hcd.4.auto: USB bus 2 deregistered [ 574.399544] xhci-hcd: probe of xhci-hcd.4.auto failed with error -110 This seems to be related to LPM (Link Power Management), and disabling it turns USB into reliable working state. As per AM62 reference manual: > 4.8.2.1 USB2SS Unsupported Features > > The following features are not supported on this family of devices: > ... > - USB 2.0 ECN: Link Power Management (LPM) > ... Fixes: 2240f96cf3cd ("arm64: dts: ti: k3-am62-main: Add support for USB") Signed-off-by: Andrejs Cainikovs Reviewed-by: Francesco Dolcini Reviewed-by: Roger Quadros Link: https://lore.kernel.org/r/20240209130213.38908-1-andrejs.cainikovs@gm= ail.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts= /ti/k3-am62-main.dtsi index 464b7565d085d..c49fbce5cb707 100644 --- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi @@ -640,6 +640,8 @@ usb0: usb@31000000 { interrupt-names =3D "host", "peripheral"; maximum-speed =3D "high-speed"; dr_mode =3D "otg"; + snps,usb2-gadget-lpm-disable; + snps,usb2-lpm-disable; }; }; =20 @@ -663,6 +665,8 @@ usb1: usb@31100000 { interrupt-names =3D "host", "peripheral"; maximum-speed =3D "high-speed"; dr_mode =3D "otg"; + snps,usb2-gadget-lpm-disable; + snps,usb2-lpm-disable; }; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2CAE3154443; Sun, 24 Mar 2024 22:38:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319904; cv=none; b=FXaMV7bbUhjOe5Kx6/VkdxRINPiGZQwUHW03hXJfholLy/xMVjtpPcsbDakeeEMgOXrNnXl4vXGDlfaHkZswA9I/wZhaxkdmu5N+iCOrIZVWma7sXuXREuK2oy8fTEwqGOhpHSexLLFA8kBk+B2nnWrCpdY8MvOq3aHbWP6h57M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319904; c=relaxed/simple; bh=nfu/1bifCRzhzUwuYeSYF4B5jVHi/FobrLmXrxCk7CI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bXcQlipyuAJbc6nF6yapuZXDRmfCLj0J40pXvz3nbA2wpep+mK4wCgwKjrHqQ+XXMjhaFU4K85xIV9ufMQ/lhxXL8nptrp+WI+GoNKRQe94iGcrWrGT54psizjFyvMWl54nESczwh1EI94cUya0VhxNtbPEs7rc9/OVyaU8e4JM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VKt+9sJz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VKt+9sJz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B7B2C43399; Sun, 24 Mar 2024 22:38:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319904; bh=nfu/1bifCRzhzUwuYeSYF4B5jVHi/FobrLmXrxCk7CI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VKt+9sJznh2vJlxnrKeRSOAvscqzLh6S2BwjB8OKd3jChQKPoF+EVte6xibKHWl2I S1emPnVf+RZFyafUjzFGTYMb3VyqL+06Cu1cS+6zvfE5U6Hk7IIHbwZ/cKS1pl4rbP V1AVb/GheVe9EklDrStwi9zVSUdbD7X5KvhAJj7dYRoiNWGSla3FZcRelaacTinQWW Rv2i/tz/BHvhkDwve52OI9oBZW6Lj9rYB8mRKjiJJt1JPsJ0YikWavc515TVl5CX1p TAzv+cxZpL6lJY2liKFgtX8sUGrP8K8gNqA7ORdJ157gAgNQXvL52EjUH6Wvr4VNvX 2RnhtjX/P9QOw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Armin Wolf , "Rafael J . Wysocki" , Sasha Levin Subject: [PATCH 6.8 209/715] ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit() Date: Sun, 24 Mar 2024 18:26:28 -0400 Message-ID: <20240324223455.1342824-210-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Armin Wolf [ Upstream commit e18afcb7b2a12b635ac10081f943fcf84ddacc51 ] After unregistering the CPU idle device, the memory associated with it is not freed, leading to a memory leak: unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 8836a742): [] kmalloc_trace+0x29d/0x340 [] acpi_processor_power_init+0xf3/0x1c0 [] __acpi_processor_start+0xd3/0xf0 [] acpi_processor_start+0x2c/0x50 [] really_probe+0xe2/0x480 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+0x55/0x100 [] acpi_processor_driver_init+0x3b/0xc0 [] do_one_initcall+0x41/0x300 [] kernel_init_freeable+0x320/0x470 [] kernel_init+0x16/0x1b0 [] ret_from_fork+0x2d/0x50 Fix this by freeing the CPU idle device after unregistering it. Fixes: 3d339dcbb56d ("cpuidle / ACPI : move cpuidle_device field out of the= acpi_processor_power structure") Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/acpi/processor_idle.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c index 55437f5e0c3ae..bd6a7857ce058 100644 --- a/drivers/acpi/processor_idle.c +++ b/drivers/acpi/processor_idle.c @@ -1430,6 +1430,8 @@ int acpi_processor_power_exit(struct acpi_processor *= pr) acpi_processor_registered--; if (acpi_processor_registered =3D=3D 0) cpuidle_unregister_driver(&acpi_idle_driver); + + kfree(dev); } =20 pr->flags.power_setup_done =3D 0; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 352A4154BE3; Sun, 24 Mar 2024 22:38:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319905; cv=none; b=TU6QeqcpbrkTlkQki4OYtlBO/VMDJ+vsBw/IC/LSED0fU/PI2fQnUCa0GXqmo5IzRrD3IIZVstjtqLVz6PhvJzXb1ao99sy345VlGEFEWxTLy8zv/tI9j9ePz2wH17PNRC14NNxRiRFVEyk9sZZlC5TT+WEIi5YYBdRYkaO2R9c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319905; c=relaxed/simple; bh=4FNTlPBsr7Z7V1+dAD2XdYCPyICn4BPhFJMGPZUBfg0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aOO7fsR7O2fJtHJ8++asycb/LUPh/9lnE4po0Y5vCixvouGvrhCG4XYQfsjw4VGPlV6rsiPlGGr9yBeWeyKIJcPrO33dJXvCc9AAuNyra5IuekWlNHtOP8eHHeyGhPaI5VrwgCNab8GAwcWbMQDP/gSOUVBIVKqykWKOmvXOXFY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BsiD3Uub; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BsiD3Uub" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 519FDC433C7; Sun, 24 Mar 2024 22:38:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319905; bh=4FNTlPBsr7Z7V1+dAD2XdYCPyICn4BPhFJMGPZUBfg0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BsiD3UubSiSZZsGRfnrhTFjVk8WEzCohkSVrC3rwlzlJywbTnJuyb1qNZrNfn9KxT 6rUAswPObOhHwOQuJFEWQOOGpOG5dMRtIgXp0Levj0+RIy1i/P13hkR0dLN+Jk7+ec keULtvVPko89/PGhJgHIJN2QTZ7yVjYPe26MJoKZBaOGD4qRjCfNx/RoQ4wgbI7W5p 2q6NT6BeHL1Rz0gfPxrDll/6620aJjgTQiuR9zl2hYGqQ2hTWglLx/e7uNa4U1atuz qrUW8pHNqfcXgZgbw2ySoyZdtAZ20DM6nai/VqdGAmAZ0Xsrl7A7h1dePuaCynvPdS f88JYtQKHxw9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Robinson , Jon Hunter , Thierry Reding , Sasha Levin Subject: [PATCH 6.8 210/715] bus: tegra-aconnect: Update dependency to ARCH_TEGRA Date: Sun, 24 Mar 2024 18:26:29 -0400 Message-ID: <20240324223455.1342824-211-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Robinson [ Upstream commit 4acd21a45c1446277e2abaece97d7fa7c2e692a9 ] Update the architecture dependency to be the generic Tegra because the driver works on the four latest Tegra generations not just Tegra210, if you build a kernel with a specific ARCH_TEGRA_xxx_SOC option that excludes Tegra210 you don't get this driver. Fixes: 46a88534afb59 ("bus: Add support for Tegra ACONNECT") Signed-off-by: Peter Robinson Cc: Jon Hunter Cc: Thierry Reding Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/bus/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig index e6742998f372c..d5e7fa9173a16 100644 --- a/drivers/bus/Kconfig +++ b/drivers/bus/Kconfig @@ -186,11 +186,12 @@ config SUNXI_RSB =20 config TEGRA_ACONNECT tristate "Tegra ACONNECT Bus Driver" - depends on ARCH_TEGRA_210_SOC + depends on ARCH_TEGRA depends on OF && PM help Driver for the Tegra ACONNECT bus which is used to interface with - the devices inside the Audio Processing Engine (APE) for Tegra210. + the devices inside the Audio Processing Engine (APE) for + Tegra210 and later. =20 config TEGRA_GMI tristate "Tegra Generic Memory Interface bus driver" --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2DE00154C03; Sun, 24 Mar 2024 22:38:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319906; cv=none; b=HyvT1UL2ttHUAvSNPUt+YHXxHID9Z41jtwCf2O4URDnA3s4BT4Gf8viA5GVxuZMg9ECDYgVxrw2tO14IJzOfaAZfpNcCLEcL2+SERBPBc6rnGrSJoxihrrb+BqUJ9f3YS2OWQjvxB0N4OWA/4+e37bqTn03gMQ5puS7zUw3hEH8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319906; c=relaxed/simple; bh=2x/Hes09mX+HIrCaUeu20eEQs98dHEZBfJlCTJyvmVs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tbrFatRhXIohpBfVDMfc2tIqIAl+WPRmo1KaH3hxW2E6UrSYMlm1qeTW3V5QLCj1LTdI57Nt7ajo6jY7GP9jnL0oa7EPJSAvWERFumkt/aoIyx9LkpIgBq5mIed4FoC+DSGgtdNWuqyIdbjf3Ln5OUnn2b+SyJvMIfYrJtbLbFk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E7EW2lNu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="E7EW2lNu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 525FEC433F1; Sun, 24 Mar 2024 22:38:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319906; bh=2x/Hes09mX+HIrCaUeu20eEQs98dHEZBfJlCTJyvmVs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E7EW2lNusJJKRS2FgZIR53Nk+qMrUClyEI/TIckZFSztLcok6Z72/7615utoYXI/Z E99o8s0VCgvoFL7dsd9GVYpFDQQBA5usyp4lbB2jAymDvNfmlU8jDyBflDihTfaAMZ 8Gu7HSzXscJqV87eGebaOa560IWKjK6sSWntlXs2G1zFaUaxI6MU4jS0taXXM2GnpJ qQoUp+M8oTBHwAQnhEsITEXYcuSw/0S+6elUTIxclwVywjRf8xEbKQJojUwrvIYCWF ZJ9u1IalGy6iX3afkBRhML36IiR1qjljJqF7COBGRkTEitOdfHdd11/Tpaihjy+BJ1 i/xXYQtFeTC4g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mario Limonciello , Vasant Hegde , Joerg Roedel , Sasha Levin Subject: [PATCH 6.8 211/715] iommu/amd: Mark interrupt as managed Date: Sun, 24 Mar 2024 18:26:30 -0400 Message-ID: <20240324223455.1342824-212-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mario Limonciello [ Upstream commit 0feda94c868d396fac3b3cb14089d2d989a07c72 ] On many systems that have an AMD IOMMU the following sequence of warnings is observed during bootup. ``` pci 0000:00:00.2 can't derive routing for PCI INT A pci 0000:00:00.2: PCI INT A: not connected ``` This series of events happens because of the IOMMU initialization sequence order and the lack of _PRT entries for the IOMMU. During initialization the IOMMU driver first enables the PCI device using pci_enable_device(). This will call acpi_pci_irq_enable() which will check if the interrupt is declared in a PCI routing table (_PRT) entry. According to the PCI spec [1] these routing entries are only required under PCI root bridges: The _PRT object is required under all PCI root bridges The IOMMU is directly connected to the root complex, so there is no parent bridge to look for a _PRT entry. The first warning is emitted since no entry could be found in the hierarchy. The second warning is then emitted because the interrupt hasn't yet been configured to any value. The pin was configured in pci_read_irq() but the byte in PCI_INTERRUPT_LINE return 0xff which means "Unknown". After that sequence of events pci_enable_msi() is called and this will allocate an interrupt. That is both of these warnings are totally harmless because the IOMMU uses MSI for interrupts. To avoid even trying to probe for a _PRT entry mark the IOMMU as IRQ managed. This avoids both warnings. Link: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/06_Device_Configuration= /Device_Configuration.html?highlight=3D_prt#prt-pci-routing-table [1] Signed-off-by: Mario Limonciello Fixes: cffe0a2b5a34 ("x86, irq: Keep balance of IOAPIC pin reference count") Reviewed-by: Vasant Hegde Link: https://lore.kernel.org/r/20240122233400.1802-1-mario.limonciello@amd= .com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/iommu/amd/init.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iommu/amd/init.c b/drivers/iommu/amd/init.c index c83bd0c2a1c92..40979b0f5250f 100644 --- a/drivers/iommu/amd/init.c +++ b/drivers/iommu/amd/init.c @@ -2068,6 +2068,9 @@ static int __init iommu_init_pci(struct amd_iommu *io= mmu) /* Prevent binding other PCI device drivers to IOMMU devices */ iommu->dev->match_driver =3D false; =20 + /* ACPI _PRT won't have an IRQ for IOMMU */ + iommu->dev->irq_managed =3D 1; + pci_read_config_dword(iommu->dev, cap_ptr + MMIO_CAP_HDR_OFFSET, &iommu->cap); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 376381552E7; Sun, 24 Mar 2024 22:38:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319907; cv=none; b=Ex/vhdTmRswlXMAIRrg6zOAYQojhnDafs/UrZsojuMZB+DdlOOTkBLdgifpOYlc6/drVV2VnHtOxzEw3SRwArCZsE9JfEgAgkdpXeXX4PX5GjNZo3VPA366AZHlZuDakgEl0fVPqiLhAxEJb9O2g/URsbgBA+9wOe9z+uEd7Ugg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319907; c=relaxed/simple; bh=nt4DweudXrWSOOYE0nV/wX2peusxuk3T7M9VaEFEUOQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N6WPK3FO/TtJFd0Oi2kuMLprUUB3SU1klixNJF9hfGD5M3IIXD9MbMP2NcqBlk3dGk0m1eSIJjflio/ZFK4XSbBRwWAn72g90VOMMPqTjIOvdscZYX+QNPDgJE8YtALk+jD4ntfCHeULfmttbIrFegLEAD1+oJ/588HM37s9TMI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cy5TDY5Q; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cy5TDY5Q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54487C433C7; Sun, 24 Mar 2024 22:38:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319907; bh=nt4DweudXrWSOOYE0nV/wX2peusxuk3T7M9VaEFEUOQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cy5TDY5Qfv/Hsrl5a1b3g/a213zzkojhPidBDavYHC73ZPwP9XBxpNYYB08vUjp57 tgBXM6kC9UMw57zxuzWPsIfxuK4NJ6RiL81mIMc8BVGxJyZ4Rs5GY0aD9h7OsYN5bM RY0JLhhZVIFnkpaOYkSE7MQf///0vFgsOOR9wtGbHQ8Rhl892YZTvizlnHc6ZCRuah 2P0SoHUyZDm8jqHMVSVUf9kXVE8223A79ZTC0lousvZrLcpT66l2LGEkScPovJ7jAF C2fmdGEyH6fby+uDVb6hl0lyruFjHcKt27o0VuBwWSNP70iI1oLkuR1/zEaiZx/rlD nxDthxaGgcs7g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Arnd Bergmann , Arend van Spriel , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 212/715] wifi: brcmsmac: avoid function pointer casts Date: Sun, 24 Mar 2024 18:26:31 -0400 Message-ID: <20240324223455.1342824-213-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnd Bergmann [ Upstream commit e1ea6db35fc3ba5ff063f097385e9f7a88c25356 ] An old cleanup went a little too far and causes a warning with clang-16 and higher as it breaks control flow integrity (KCFI) rules: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.c:64:34: error: c= ast from 'void (*)(struct brcms_phy *)' to 'void (*)(void *)' converts to i= ncompatible function type [-Werror,-Wcast-function-type-strict] 64 | brcms_init_timer(physhim->wl, (void (*)(voi= d *))fn, | ^~~~~~~~~~~~~= ~~~~~~~ Change this one instance back to passing a void pointer so it can be used with the timer callback interface. Fixes: d89a4c80601d ("staging: brcm80211: removed void * from softmac phy") Signed-off-by: Arnd Bergmann Acked-by: Arend van Spriel Signed-off-by: Kalle Valo Link: https://msgid.link/20240213100548.457854-1-arnd@kernel.org Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 3 ++- drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.c | 5 ++--- drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.h | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c= b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c index ccc621b8ed9f2..4a1fe982a948e 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_cmn.c @@ -383,8 +383,9 @@ struct shared_phy *wlc_phy_shared_attach(struct shared_= phy_params *shp) return sh; } =20 -static void wlc_phy_timercb_phycal(struct brcms_phy *pi) +static void wlc_phy_timercb_phycal(void *ptr) { + struct brcms_phy *pi =3D ptr; uint delay =3D 5; =20 if (PHY_PERICAL_MPHASE_PENDING(pi)) { diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.c b/= drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.c index a0de5db0cd646..b723817915365 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.c @@ -57,12 +57,11 @@ void wlc_phy_shim_detach(struct phy_shim_info *physhim) } =20 struct wlapi_timer *wlapi_init_timer(struct phy_shim_info *physhim, - void (*fn)(struct brcms_phy *pi), + void (*fn)(void *pi), void *arg, const char *name) { return (struct wlapi_timer *) - brcms_init_timer(physhim->wl, (void (*)(void *))fn, - arg, name); + brcms_init_timer(physhim->wl, fn, arg, name); } =20 void wlapi_free_timer(struct wlapi_timer *t) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.h b/= drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.h index dd8774717adee..27d0934e600ed 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.h +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy_shim.h @@ -131,7 +131,7 @@ void wlc_phy_shim_detach(struct phy_shim_info *physhim); =20 /* PHY to WL utility functions */ struct wlapi_timer *wlapi_init_timer(struct phy_shim_info *physhim, - void (*fn)(struct brcms_phy *pi), + void (*fn)(void *pi), void *arg, const char *name); void wlapi_free_timer(struct wlapi_timer *t); void wlapi_add_timer(struct wlapi_timer *t, uint ms, int periodic); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 36DAB1552FD; Sun, 24 Mar 2024 22:38:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319908; cv=none; b=Mo9YRukFtum8PC+456PyjjHh/ndzvEpmZ/XjaU4z8TaFL6lKUp65mI1OXLPO0b5Mib4RodH0Thgrgl7F1WlCwLaavRLWAZYkVsvNpiv2oR7TdjM6CW2Lp0dcfs/W6fhNsa18zijtbH4877ca0N5C041caTF2h//zE+eXgrIQ2mo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319908; c=relaxed/simple; bh=cfMRW/npnSb3gZVTKDkgAfAeDudw9+aidofO2uKEBmE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gVTEmtHNhODVjORM5DmzYim2C2WoXhHZdlSEAyPrSJPo9/MkGddKLVOY8hC3EoiANwDGPSL8UDCXtL4kdfy2Ur+iDKjD8j+Ye0hplzzYkNEIRvb7TguOi5uhUFjunSYjXAnHq3n4l/zJN5+jaOIy1elavmVXi2ZwDu96Tv7ThNM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cFzysawy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cFzysawy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 53DB5C433F1; Sun, 24 Mar 2024 22:38:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319908; bh=cfMRW/npnSb3gZVTKDkgAfAeDudw9+aidofO2uKEBmE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cFzysawyeHsEsDEHIwtrq5z7Os5njgY8agCjZA40ICMxFOMoaQsc1naGaRo/4azj4 Lf07/NP8TnNnPljizbxBrZzEz8MRzhfSmWaMrKSZCpQufR7bRQ7vCbgWfY10hwSHn9 yu/Xn/IB4bjEojVRg9YddcJ8rIbFMe7rmgdCzoe5MWX6TKqsK7WeJSe9JFzNQVt6Ra J26Q9WcExfRd6jzT4vsduo3GJqdYSrvI8uKughjhykigowf3wJ3rje+UkQk2f4qeXH D070OBYIqlGG0xKhJzP4rldk0d8dQAX8uprsANc7FzATeKvgFpUtWtL9YEOvezqkP7 UaOEe3ovU0F9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Krzysztof Kozlowski , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 213/715] arm64: dts: qcom: sdm845-db845c: correct PCIe wake-gpios Date: Sun, 24 Mar 2024 18:26:32 -0400 Message-ID: <20240324223455.1342824-214-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Krzysztof Kozlowski [ Upstream commit 584a327c5cffc36369b2a8953d9448826240f1ac ] Bindings allow a "wake", not "enable", GPIO. Schematics also use WAKE name for the pin: sdm845-db845c.dtb: pcie@1c00000: Unevaluated properties are not allowed (= 'enable-gpio' was unexpected) Fixes: 4a657c264b78 ("arm64: dts: qcom: db845c: Enable PCIe controllers") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240108131216.53867-1-krzysztof.kozlowski@= linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sdm845-db845c.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts b/arch/arm64/boot/d= ts/qcom/sdm845-db845c.dts index ab6220456513c..1f517328199b9 100644 --- a/arch/arm64/boot/dts/qcom/sdm845-db845c.dts +++ b/arch/arm64/boot/dts/qcom/sdm845-db845c.dts @@ -580,7 +580,7 @@ &mss_pil { &pcie0 { status =3D "okay"; perst-gpios =3D <&tlmm 35 GPIO_ACTIVE_LOW>; - enable-gpio =3D <&tlmm 134 GPIO_ACTIVE_HIGH>; + wake-gpios =3D <&tlmm 134 GPIO_ACTIVE_HIGH>; =20 vddpe-3v3-supply =3D <&pcie0_3p3v_dual>; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3299C15531F; Sun, 24 Mar 2024 22:38:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319909; cv=none; b=f6dRVV2AZAdExLgeDB7heI2HRtR/Vlf/5OYTsUQPBJFWXh2pFRTGR5ImX/NdIU2Vy0cp+QVOWjdPhD4eb4gc2RyD8uTY2EhjdkcFm6Mw51OdF8VOls4fKQqH2yBf0RGHj/1w8P84rcKCqS2nBXxpjqSGMXuFxUKt1St7QsGvPt4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319909; c=relaxed/simple; bh=y1oXh9npTIO0O2nMld9d9/Y4lPp0t3KM/HN98aO+7WY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aeWeR72eayukFfa+Jbxv5ZVw3kq7aU1JQDFpwrohNLVaHVf932dB94uJQvE/20XiZut5chHfJ/MOGYLOvpPPTVaRHN5OVyOTdjSDgXJDeFsAhWboqsQFwVbtRZUF8rMVBwgmJqpuUMpUFr6y4utcqigZiEo9Cs9/tEI9n4Nw7DI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nkMmn+df; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nkMmn+df" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FF3BC433C7; Sun, 24 Mar 2024 22:38:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319909; bh=y1oXh9npTIO0O2nMld9d9/Y4lPp0t3KM/HN98aO+7WY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nkMmn+dfAA/q35KUGkOVNICtuOn4N97jKiLrzN/rH5u/n/JySovJPCWQ2FJsGxn1o xn+Btk3463MbSJvPmBSG2yu7xtdNAQZRjSv0TwQrGsaM20jL4HN4qpBeDUhy4tB57T WWQCufHljxhaoz1V/rSAuG5Q5gvuOakZ44XlN5h+alM3JIEG4Hd8sxJHk8iscYrT0E g12EU9b3EkVebzdEwgwCYatcg0CkI/LMjuT7uPYyWCS+PSSt0tozkPvXpQUyVgWZlu gqUVzONHeQ+0D/G74mmNrZY+ygGajWTkrtdE6uqd0t+E5BuOJy1Ryzq1jNXDGsiAc6 0SG8CFwRv41JQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Krzysztof Kozlowski , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 214/715] arm64: dts: qcom: sm8150: correct PCIe wake-gpios Date: Sun, 24 Mar 2024 18:26:33 -0400 Message-ID: <20240324223455.1342824-215-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Krzysztof Kozlowski [ Upstream commit 7c38989d0f7a35c83e7c4781271d42662903fa8d ] Bindings allow a "wake", not "enable", GPIO. Schematics also use WAKE name for the pin: sa8155p-adp.dtb: pcie@1c00000: Unevaluated properties are not allowed ('e= nable-gpio' was unexpected) Fixes: a1c86c680533 ("arm64: dts: qcom: sm8150: Add PCIe nodes") Signed-off-by: Krzysztof Kozlowski Reviewed-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240108131216.53867-2-krzysztof.kozlowski@= linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sm8150.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi b/arch/arm64/boot/dts/qco= m/sm8150.dtsi index 761a6757dc26f..2abd4c87a3ca9 100644 --- a/arch/arm64/boot/dts/qcom/sm8150.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi @@ -1879,7 +1879,7 @@ pcie0: pcie@1c00000 { phy-names =3D "pciephy"; =20 perst-gpios =3D <&tlmm 35 GPIO_ACTIVE_HIGH>; - enable-gpio =3D <&tlmm 37 GPIO_ACTIVE_HIGH>; + wake-gpios =3D <&tlmm 37 GPIO_ACTIVE_HIGH>; =20 pinctrl-names =3D "default"; pinctrl-0 =3D <&pcie0_default_state>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 447BB15530F; Sun, 24 Mar 2024 22:38:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319910; cv=none; b=doTcro/jsOriSIj9RIohir6XPqKmNizd0xK8DHOSUQcYpB7A0Hj7B7yj8n9a3HdLh9Snt4H2/dYxfy/X6n+nD8rBI5L3QqgMh5bfNrs1nK6t+Rl4+B3N1hiE6Yk2zECwwBhId5bLgnVmJJaJKZTEm2KxiByMUcuswcL/ZiWBWPc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319910; c=relaxed/simple; bh=OC6s1nGnzvG27cdhEV9v+152Ge649GD6EUnGf7Ba9Jc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UHJ453o1MI7JkBe9gwOnWPBVs3pMHS2/MHf4CNXIeqDzSLr9FJ5LjE891IqKrhLWuMwotKMB/xuU61XmpATSyOlD9LBvnhaJa/zuIgjLkzGKMvCeFFfk7hyuk9GDha4Qa74XIcSu3y0cakQh2FNiWECdFFLxNv5oFBNLiHWn3Ds= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EiRPpfp+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EiRPpfp+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B386C433F1; Sun, 24 Mar 2024 22:38:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319909; bh=OC6s1nGnzvG27cdhEV9v+152Ge649GD6EUnGf7Ba9Jc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EiRPpfp+kpzLZ3NwyrkyMij71Ny6Eq4ga9Mwhvvf0Tbxr2nrCe7hGDKFP24xTB/db +7I/W/wq8PyUq1roK9FxWpyskCeLldYhxm3FiAwwg7uH931rYEte0YxxbkBk4WEy8e izrWcgIEvzPJMpisvDa7NjxKzNXOS+PYHJARBk6/TghLZ9CBKvUrOyuv/dUkslkWHN nRkWfMJW9Rg2Oxq4beibr6hh9Le3fikd+aj6oVPWAFx3vmvghAXa5dCxm0gD/Jq9pV Al+aWFfkK1FoAghAuUdiSnbheaNUe4mHYQFAD85aDfcZT8ycx98GCHvwgzWvSfPnfE FboJuyDszODsQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Daniel Lezcano , "Rafael J . Wysocki" , Sasha Levin Subject: [PATCH 6.8 215/715] powercap: dtpm_cpu: Fix error check against freq_qos_add_request() Date: Sun, 24 Mar 2024 18:26:34 -0400 Message-ID: <20240324223455.1342824-216-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Daniel Lezcano [ Upstream commit b50155cb0d609437236c88201206267835c6f965 ] The caller of the function freq_qos_add_request() checks again a non zero value but freq_qos_add_request() can return '1' if the request already exists. Therefore, the setup function fails while the QoS request actually did not failed. Fix that by changing the check against a negative value like all the other callers of the function. Fixes: 0e8f68d7f0485 ("Add CPU energy model based support") Signed-off-by: Daniel Lezcano Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/powercap/dtpm_cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/powercap/dtpm_cpu.c b/drivers/powercap/dtpm_cpu.c index 9193c3b8edebe..ae7ee611978ba 100644 --- a/drivers/powercap/dtpm_cpu.c +++ b/drivers/powercap/dtpm_cpu.c @@ -219,7 +219,7 @@ static int __dtpm_cpu_setup(int cpu, struct dtpm *paren= t) ret =3D freq_qos_add_request(&policy->constraints, &dtpm_cpu->qos_req, FREQ_QOS_MAX, pd->table[pd->nr_perf_states - 1].frequency); - if (ret) + if (ret < 0) goto out_dtpm_unregister; =20 cpufreq_cpu_put(policy); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 510E7156975; Sun, 24 Mar 2024 22:38:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319911; cv=none; b=FeRfj12pSS9PsNhgUMO+C3NyaEoSGiQ7E/4CLOUOYwpYkuIc7N8kYhYKnedfaHf6Pdnc/iqbNrvWU81Fk801poO6AgUNc5cS3uknK9U4u+oDzvXhWl0Hbvdgjj7zcvL8tfKhkpJjwVP9jvgtzMtONmYAvaxCbHl688LthrewThw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319911; c=relaxed/simple; bh=dhlXIN0G772gb/0OtjhjujHY758spByvfKEwk4FRehk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QZQCNng203bvguRpB3sz+77uKt1fyJsgyDTzU7w7CLBugy21dcmbOtkXkR4pGpBLOb0Bt3eW+9TWXgJZwsEwH7dWiSlVK6/LSSYgdgnLSv85p8y2KycRIHL7q+xtDWPC3RbUUD1fHzNAcDT1NcKFawku9gvLJwdrbJT2Z1CqfV4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aTF5vTY/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aTF5vTY/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2FEDEC433C7; Sun, 24 Mar 2024 22:38:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319910; bh=dhlXIN0G772gb/0OtjhjujHY758spByvfKEwk4FRehk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aTF5vTY/GGloIgBVEYE3wf/7kIW3NloVGRIFKyJ+jIlBZZYDg+WhsiWi2spV6FwO0 bdji7kpOEsXAvWWsmN17Q8NSSuIh1mniL5RLmjl5FyuuWIhBZR47BS8AC9fVMAPuuj dyA352fstddMTTytD92nU9bp/Z6vghpxuy8PqyY1MFSE1CDsap3TTq+icDZf7zAvMp MhcPttQRuYT4Dd5dgrsHgnPZonmZE78Dja2EZ0CipnHQr7uPtXISZr3mBrMm7Heq6n hQp19h4Ngm1RixVibKokAnjHL44WwxPit8e0vvkw4jo1zoPYPwJT5pr10imfqeux1I opCbZrWd7XeLQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kamal Heib , Jacob Keller , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 216/715] net: ena: Remove ena_select_queue Date: Sun, 24 Mar 2024 18:26:35 -0400 Message-ID: <20240324223455.1342824-217-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kamal Heib [ Upstream commit 78e886ba2b549945ecada055ee0765f0ded5707a ] Avoid the following warnings by removing the ena_select_queue() function and rely on the net core to do the queue selection, The issue happen when an skb received from an interface with more queues than ena is forwarded to the ena interface. [ 1176.159959] eth0 selects TX queue 11, but real number of TX queues is 8 [ 1176.863976] eth0 selects TX queue 14, but real number of TX queues is 8 [ 1180.767877] eth0 selects TX queue 14, but real number of TX queues is 8 [ 1188.703742] eth0 selects TX queue 14, but real number of TX queues is 8 Fixes: 1738cd3ed342 ("net: ena: Add a driver for Amazon Elastic Network Ada= pters (ENA)") Signed-off-by: Kamal Heib Reviewed-by: Jacob Keller Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/ethernet/amazon/ena/ena_netdev.c | 17 ----------------- 1 file changed, 17 deletions(-) diff --git a/drivers/net/ethernet/amazon/ena/ena_netdev.c b/drivers/net/eth= ernet/amazon/ena/ena_netdev.c index 1c0a7828d397b..5482015411f2f 100644 --- a/drivers/net/ethernet/amazon/ena/ena_netdev.c +++ b/drivers/net/ethernet/amazon/ena/ena_netdev.c @@ -2670,22 +2670,6 @@ static netdev_tx_t ena_start_xmit(struct sk_buff *sk= b, struct net_device *dev) return NETDEV_TX_OK; } =20 -static u16 ena_select_queue(struct net_device *dev, struct sk_buff *skb, - struct net_device *sb_dev) -{ - u16 qid; - /* we suspect that this is good for in--kernel network services that - * want to loop incoming skb rx to tx in normal user generated traffic, - * most probably we will not get to this - */ - if (skb_rx_queue_recorded(skb)) - qid =3D skb_get_rx_queue(skb); - else - qid =3D netdev_pick_tx(dev, skb, NULL); - - return qid; -} - static void ena_config_host_info(struct ena_com_dev *ena_dev, struct pci_d= ev *pdev) { struct device *dev =3D &pdev->dev; @@ -2863,7 +2847,6 @@ static const struct net_device_ops ena_netdev_ops =3D= { .ndo_open =3D ena_open, .ndo_stop =3D ena_close, .ndo_start_xmit =3D ena_start_xmit, - .ndo_select_queue =3D ena_select_queue, .ndo_get_stats64 =3D ena_get_stats64, .ndo_tx_timeout =3D ena_tx_timeout, .ndo_change_mtu =3D ena_change_mtu, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E2C2B156986; Sun, 24 Mar 2024 22:38:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319912; cv=none; b=FkZPh/1GkGU7sdtzy27QY6KAhf6T8GP+hnDr//qmdhh8rhS/HFAbG89EEp6ea0GbegNSkVas8DuiW32wT6PFQgegGc0c9DSG6tF65MGbF8gnJZA3OpV8oR3+cuxe7IqG0NfULAHdN0B4unrUEPNNnp41/hKt81eNxOS0c3uNq1c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319912; c=relaxed/simple; bh=b3EGla1ceGQDu3kI0qNL7DjBL1cafs8iz7Jsl5WCx38=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VHgeJqKqdTkGQpOkPvEXef//lKZgUViviyI/YbK9SjIcGtQTSY3EdfmrSpARe2g8E5FQN/Ed7lskqlvJZqlGRD4nDgLyihYbl0G4mi29fudMhvRuCPzYrOrZTNLlvLZsFQ/JN3nrNC6ZShdYNQ3zTID8/zucHmfH+OrjdvCG2jY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Fe/T94XW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Fe/T94XW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28551C43390; Sun, 24 Mar 2024 22:38:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319911; bh=b3EGla1ceGQDu3kI0qNL7DjBL1cafs8iz7Jsl5WCx38=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Fe/T94XWVA0ODiiovsLbj4gVvWbGsohv3FijB6AoF8TvDgwo/GRGlvGOCdbIXiH2e ozUQJRaEY8Emu+y24Feb7xPhBCzWBSQhtiHmXe9xkYrCSVqn+CtstB4pv7GET3r1G4 VVwKT8Vjwr1xyrvgtdVsuMyWlrhE8/F1oX21BEf7+XAaOm6RM64yqoHQGNBRrI2BE0 NqRUPIsMeyFPKBFKtq+1VYL46+1RhWmUuGhAO8lWgEZaEGP0LRYlNWU7pt2snD8+ih bkLDINM7dJmAPRADab/IRhd6Xtpqwvg76sO8kdtbMRmFsS8DG0CBMRMM7AQlrssFjP XIFfsOqderU4w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bhavya Kapoor , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 217/715] arm64: dts: ti: k3-j7200-common-proc-board: Modify Pinmux for wkup_uart0 and mcu_uart0 Date: Sun, 24 Mar 2024 18:26:36 -0400 Message-ID: <20240324223455.1342824-218-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bhavya Kapoor [ Upstream commit 566feddd2ba5e29d9ccab36d6508592ae563f275 ] WKUP_PADCONFIG registers for wkup_uart0 and mcu_uart0 lies under wkup_pmx2 for J7200. Thus, modify pinmux for both of them. Fixes: 3709ea7f960e ("arm64: dts: ti: k3-j7200-common-proc-board: Add uart = pinmux") Signed-off-by: Bhavya Kapoor Link: https://lore.kernel.org/r/20240214105846.1096733-2-b-kapoor@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../boot/dts/ti/k3-j7200-common-proc-board.dts | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts b/arch/a= rm64/boot/dts/ti/k3-j7200-common-proc-board.dts index cee2b4b0eb87d..53594c5fb8e8f 100644 --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts @@ -91,24 +91,25 @@ vdd_sd_dv: gpio-regulator-TLV71033 { }; =20 &wkup_pmx0 { +}; + +&wkup_pmx2 { mcu_uart0_pins_default: mcu-uart0-default-pins { pinctrl-single,pins =3D < - J721E_WKUP_IOPAD(0xf4, PIN_INPUT, 0) /* (D20) MCU_UART0_RXD */ - J721E_WKUP_IOPAD(0xf0, PIN_OUTPUT, 0) /* (D19) MCU_UART0_TXD */ - J721E_WKUP_IOPAD(0xf8, PIN_INPUT, 0) /* (E20) MCU_UART0_CTSn */ - J721E_WKUP_IOPAD(0xfc, PIN_OUTPUT, 0) /* (E21) MCU_UART0_RTSn */ + J721E_WKUP_IOPAD(0x90, PIN_INPUT, 0) /* (E20) MCU_UART0_CTSn */ + J721E_WKUP_IOPAD(0x94, PIN_OUTPUT, 0) /* (E21) MCU_UART0_RTSn */ + J721E_WKUP_IOPAD(0x8c, PIN_INPUT, 0) /* (D20) MCU_UART0_RXD */ + J721E_WKUP_IOPAD(0x88, PIN_OUTPUT, 0) /* (D19) MCU_UART0_TXD */ >; }; =20 wkup_uart0_pins_default: wkup-uart0-default-pins { pinctrl-single,pins =3D < - J721E_WKUP_IOPAD(0xb0, PIN_INPUT, 0) /* (B14) WKUP_UART0_RXD */ - J721E_WKUP_IOPAD(0xb4, PIN_OUTPUT, 0) /* (A14) WKUP_UART0_TXD */ + J721E_WKUP_IOPAD(0x48, PIN_INPUT, 0) /* (B14) WKUP_UART0_RXD */ + J721E_WKUP_IOPAD(0x4c, PIN_OUTPUT, 0) /* (A14) WKUP_UART0_TXD */ >; }; -}; =20 -&wkup_pmx2 { mcu_cpsw_pins_default: mcu-cpsw-default-pins { pinctrl-single,pins =3D < J721E_WKUP_IOPAD(0x0000, PIN_OUTPUT, 0) /* MCU_RGMII1_TX_CTL */ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1EF4B157E6B; Sun, 24 Mar 2024 22:38:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319913; cv=none; b=D9INBBa4jBskigtOWiPS3XgOHgAW98ghVX9cfB8e4JeV6CvPD6dUuqJszqmuFdsRP2T48PDtBkasP878aw2HR3evkfNJFKzhNTW3NOe2Fs4tjIOR/NnXvx+CFkaYVWe3feREW+H4cfEEls5n/GvAB4OjHJIAP0dyq3Z3Pq1Srd4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319913; c=relaxed/simple; bh=UhipjQvNWfeeujAdzDwbZqGmfdqnpiMVNNRI02gZzEk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KpaiIA+Bt2HdIqFvMeQQwGwZtpo5F2cC4PjA+T3gmY58i2mOuBfoaJjklvViEGdGLDEXEvwe448EGiS/olSpuycrpbLW1SJzJd9vMilrOuaICH9eNE7GDKOBv+4fcKxnaRuCHTRVrjqEkKtCQ/H1tsBaIZX9hwmsAuoUwxlwIgs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ddYfXdL8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ddYfXdL8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0F855C433F1; Sun, 24 Mar 2024 22:38:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319912; bh=UhipjQvNWfeeujAdzDwbZqGmfdqnpiMVNNRI02gZzEk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ddYfXdL8xI1czYBZX7zyHQKRwtyadc0vdMDvhvu6wff9UYM9rJ42PbD67UIC3G5eS ZtvrJiZ6f/7J0A0xW7ve5pqQUnpcXgbSNqJyiRSX5m5AgG3+PqBEunRGWwQ/xMfR6p JBKxH0fOTdy4ylBYItJ9os3SuXIcKm/rCGrVCQK1XxChtWPlYuAjd+vuuaeYD29ALU c8Go9CGkWZE4mWcIaxRJpyB3aO5j5TGRi2ecfvLLRySUhJuILtBdcs3rJ+A8Moar1t 7HQonFnm3TA4gSXu47qFoFUaHzVMaiye4BuWgX2SoVuveFJNk1i2tCrcjde77dzeFw VhDVLVQzm9fQw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bhavya Kapoor , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 218/715] arm64: dts: ti: k3-j7200-common-proc-board: Remove clock-frequency from mcu_uart0 Date: Sun, 24 Mar 2024 18:26:37 -0400 Message-ID: <20240324223455.1342824-219-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bhavya Kapoor [ Upstream commit 0fa8b0e2083d333e4854b9767fb893f924e70ae5 ] Clock-frequency property is already present in mcu_uart0 node of the k3-j7200-mcu-wakeup.dtsi file. Thus, remove redundant clock-frequency property from mcu_uart0 node. Fixes: 3709ea7f960e ("arm64: dts: ti: k3-j7200-common-proc-board: Add uart = pinmux") Signed-off-by: Bhavya Kapoor Link: https://lore.kernel.org/r/20240214105846.1096733-3-b-kapoor@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts b/arch/a= rm64/boot/dts/ti/k3-j7200-common-proc-board.dts index 53594c5fb8e8f..7a0c599f2b1c3 100644 --- a/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts +++ b/arch/arm64/boot/dts/ti/k3-j7200-common-proc-board.dts @@ -211,7 +211,6 @@ &mcu_uart0 { status =3D "okay"; pinctrl-names =3D "default"; pinctrl-0 =3D <&mcu_uart0_pins_default>; - clock-frequency =3D <96000000>; }; =20 &main_uart0 { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B4FEE55C13; Sun, 24 Mar 2024 22:38:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319913; cv=none; b=N9oxtajk1laTIoFt66kuOU4+/jJpLjkf5eYCyhI/C+FMVJbQ/tIS7EI+jUEQdIoZsIP7M3PemyRB4LaqKomtLr0idCiI+2ox1LMQ4wDpzIrR5geazlR2aglTPKkerWl86IFSsLGUoyoQcBKvpo22stjVOfk56FlNprcgQ/JP91M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319913; c=relaxed/simple; bh=9fBJTe87mI9XM2IpLXAQVydlYYvMSHSgDaCK0LeAZws=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QUSPFqI93rl019GJzE8hPNWOrIB2WrrQzhwBGs0yBbQ52V9CzsbqpXIrp1Kr5vJG+h9O/+xbylNcyxrVcHRfw5scT0oV5omvuczJI5Er/CIWrEGzGsQYxGlgPigYfPFOzvjwEAB9i/9BeQnrPD+U+YyOv1qDPBjyhH5+On/HdYc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ejB6ssuN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ejB6ssuN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EBFFAC433B2; Sun, 24 Mar 2024 22:38:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319913; bh=9fBJTe87mI9XM2IpLXAQVydlYYvMSHSgDaCK0LeAZws=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ejB6ssuN+5YIoaGW6UyrOZfAEbYK0+eQZybnem0zujHzuSTh2f7vj37LFT9G4U8dT hh1kit8BvYD4y7YXm6GNTPphouxmnMZ9ZM5rFqzRLY6OR0S/lkjVI5IJxFQ3m4YANY pXMqygmdyFCcPiyESflF2/HKn+E52N546meKZdk++sg+ea5p5e1LJj8NE/12TZMI75 jHceCOdBbqtZ4GsX/oN3tEOkdDLSpPOokk7932kRJ/sMNtAGxl4dMWRf3KjOVkzu2u z+L4xHJoJ+jWLeRvgrEiZB3CLz3inDKmY8ekzL2Qt3lK9emGBoWpgpTt8h8TrSU3z2 nrf0bec5BxbVw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bhavya Kapoor , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 219/715] arm64: dts: ti: k3-j721s2-common-proc-board: Remove Pinmux for CTS and RTS in wkup_uart0 Date: Sun, 24 Mar 2024 18:26:38 -0400 Message-ID: <20240324223455.1342824-220-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bhavya Kapoor [ Upstream commit 28e5b74d524050008edf415f20a3e38907b8f176 ] Only Tx and Rx Signal lines for wkup_uart0 are brought out on the Common Proc Board through SoM, but CTS and RTS signal lines are not brought on the board. Thus, remove pinmux for CTS and RTS signal lines for wkup_uart0 in J721S2. Fixes: f5e9ee0b354a ("arm64: dts: ti: k3-j721s2-common-proc-board: Add uart= pinmux") Signed-off-by: Bhavya Kapoor Link: https://lore.kernel.org/r/20240214105846.1096733-4-b-kapoor@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts b/arch/= arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts index c6b85bbf9a179..1ba1f53c72d03 100644 --- a/arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts +++ b/arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts @@ -190,8 +190,6 @@ J721S2_IOPAD(0x038, PIN_OUTPUT, 0) /* (AB28) MCASP0_ACL= KX.MCAN5_TX */ &wkup_pmx2 { wkup_uart0_pins_default: wkup-uart0-default-pins { pinctrl-single,pins =3D < - J721S2_WKUP_IOPAD(0x070, PIN_INPUT, 0) /* (E25) WKUP_GPIO0_6.WKUP_UART0= _CTSn */ - J721S2_WKUP_IOPAD(0x074, PIN_OUTPUT, 0) /* (F28) WKUP_GPIO0_7.WKUP_UART= 0_RTSn */ J721S2_WKUP_IOPAD(0x048, PIN_INPUT, 0) /* (D28) WKUP_UART0_RXD */ J721S2_WKUP_IOPAD(0x04c, PIN_OUTPUT, 0) /* (D27) WKUP_UART0_TXD */ >; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9877E157E9E; Sun, 24 Mar 2024 22:38:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319914; cv=none; b=GZWSguo8u+nP8L3Q4Df9LYH3w9t4Ptm0+mB9XlbZaxJfJH1sIo1NamvDAwaVkl1oL6Sq9EhJrHmxAjXfsuGDdL6MJDzLA6KgNbHJBOdDzSe0VZldmDjfevQavoYrxmswJv9p1Dosy5vHn0LUbd/6LBhf9XbmgwAiLTY6ZZiljPk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319914; c=relaxed/simple; bh=s63ujHTQhYmDGDVB83IzyZeuVeupg1ZEtdnm+HFw1WU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tZtKxftKhwuEfHtlf72HlYE/LK+WXnLDGDbFqYD5jJtwOKo3Yi52Gbvp4TE48XCZdfh28g2v96xuFqA4HyyebwvbaSOM0HZ5MLfUxLXG44lKQXtoE/MZkVNLhOuG6DWRfG0MqXQjHqPD7S+eplM+JO4DaAL7jf1VuckUGkribJI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SoGPVs53; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SoGPVs53" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7357C43390; Sun, 24 Mar 2024 22:38:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319914; bh=s63ujHTQhYmDGDVB83IzyZeuVeupg1ZEtdnm+HFw1WU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SoGPVs53SeH+wu3lv/TWWbYU5i8QzOOaFmeby2p1piK+ZKBgUmMnfb36ImLSNCZIJ 4GCqlsn3Ig8pHONoXOKwM/QcoAQYw37eRPpesYMQvZdln3ZDiwQFuxNgLdmzh8A1OM nciptczDCypum5hVw07rr3BQq6v5l/mXMLhzGlMygtrFv0fRb8K37ObXW4W+noCMuw wdrkw5ZR/s3r7RJUQCdFTpJIixYj0xmhNl9qwoo3ldN2TeUBU03hIm9wn9zGhZUz41 zmrfGyyS4eKQKQbla5hBcxJ0NyhqbiL7cPnDuYnz1HOKq00SnCmAtillwjk2wPbpq0 vcv5h3+RkVPAQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bhavya Kapoor , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 220/715] arm64: dts: ti: k3-j784s4-evm: Remove Pinmux for CTS and RTS in wkup_uart0 Date: Sun, 24 Mar 2024 18:26:39 -0400 Message-ID: <20240324223455.1342824-221-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bhavya Kapoor [ Upstream commit d29a6cf980572d8cf7b63935716fca663e2610f0 ] Only Tx and Rx Signal lines for wkup_uart0 are brought out on the J784S4 EVM from SoC, but CTS and RTS signal lines are not brought on the EVM. Thus, remove pinmux for CTS and RTS signal lines for wkup_uart0 in J784S4. Fixes: 6fa5d37a2f34 ("arm64: dts: ti: k3-j784s4-evm: Add mcu and wakeup uar= ts") Signed-off-by: Bhavya Kapoor Link: https://lore.kernel.org/r/20240214105846.1096733-5-b-kapoor@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts b/arch/arm64/boot/dts= /ti/k3-j784s4-evm.dts index f34b92acc56d8..33795a0bc69cf 100644 --- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts @@ -335,8 +335,6 @@ &wkup_pmx2 { wkup_uart0_pins_default: wkup-uart0-default-pins { bootph-all; pinctrl-single,pins =3D < - J721S2_WKUP_IOPAD(0x070, PIN_INPUT, 0) /* (L37) WKUP_GPIO0_6.WKUP_UART0= _CTSn */ - J721S2_WKUP_IOPAD(0x074, PIN_INPUT, 0) /* (L36) WKUP_GPIO0_7.WKUP_UART0= _RTSn */ J721S2_WKUP_IOPAD(0x048, PIN_INPUT, 0) /* (K35) WKUP_UART0_RXD */ J721S2_WKUP_IOPAD(0x04c, PIN_INPUT, 0) /* (K34) WKUP_UART0_TXD */ >; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98CB71586DB; Sun, 24 Mar 2024 22:38:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319915; cv=none; b=nyYZ7mXeKsgL3iMOAwhC37oZ5yUDJi25uYzcaXUKzcgerVxlaZ3uYnE6UB0To2G26ApZ8SpVfMRzTHVlJBuT3efen7SXs+ZacKx2BWe51y83BPvjBmeGNV2dMNwvKD/x79pVd9nBkSp9gnkPeKtcbS7KePRryZLC/kxHCR7RDgM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319915; c=relaxed/simple; bh=hgKXfShRnwipZ+Km/9JNBJH4+qiU82rIGPcSvqOOfTc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cXHJyDA21WXlvhcNrG8fGvQlpCDeopVkGczlrAsCDwbfZcHfi7eD/rhxnIzxic4OZs95hnYKY54sjVW11q/pCqG55bg7nzv/HCPQUUeGFGR5L1toAaX6XtVqphC6siEMBC0qTQV//3eSA7hRtKqcpgvWtMZJHJGfN6KeLuJAMKw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Rcedlwfc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Rcedlwfc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE79BC433C7; Sun, 24 Mar 2024 22:38:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319915; bh=hgKXfShRnwipZ+Km/9JNBJH4+qiU82rIGPcSvqOOfTc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RcedlwfcHitWfKYyZkYc1E9pcG5ETATo58m578/bOwVNJyzM8d/+K16lr8TsKIQpm INNDy4pi9QMica8SJ6XL2GSUGkQnyHzijHSAIzjPGnAoUkTBOufFGzE9C89de20AIK G0and/efekhaOVBuMAjCR24IBlYncpvpn9cYXiFGo9GW8haXMQmDfGOafAejOr4pJF Fg5Z5o8g1dAs3da7QFkKU5UnzQ67mvdM0f0ryAmifrMceAOQBFKkgsFrJNq3Zx7aZ4 6UaqR1mHwBT12Yh9JCXEsT7hdS2LDrmeM/16Xr0OpLKNjsCSUNq50OwcWHAtOkE6NC iCJ/SB4JkSxwA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Judith Mendez , Wadim Egorov , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 221/715] arm64: dts: ti: k3-am64-main: Fix ITAP/OTAP values for MMC Date: Sun, 24 Mar 2024 18:26:40 -0400 Message-ID: <20240324223455.1342824-222-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Judith Mendez [ Upstream commit 379c7752bbd0e81654544a896dd19c19ebb6faba ] Update MMC0/MMC1 OTAP/ITAP values according to the datasheet [0], refer to Table 7-68 for MMC0 and Table 7-77 for MMC1. [0] https://www.ti.com/lit/ds/symlink/am6442.pdf Fixes: 8abae9389bdb ("arm64: dts: ti: Add support for AM642 SoC") Signed-off-by: Judith Mendez Tested-by: Wadim Egorov Link: https://lore.kernel.org/r/20240213235701.2438513-5-jm@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi b/arch/arm64/boot/dts= /ti/k3-am64-main.dtsi index e348114f42e01..ba624ef72f5b4 100644 --- a/arch/arm64/boot/dts/ti/k3-am64-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am64-main.dtsi @@ -633,6 +633,9 @@ sdhci0: mmc@fa10000 { ti,otap-del-sel-mmc-hs =3D <0x0>; ti,otap-del-sel-ddr52 =3D <0x6>; ti,otap-del-sel-hs200 =3D <0x7>; + ti,itap-del-sel-legacy =3D <0x10>; + ti,itap-del-sel-mmc-hs =3D <0xa>; + ti,itap-del-sel-ddr52 =3D <0x3>; status =3D "disabled"; }; =20 @@ -645,12 +648,16 @@ sdhci1: mmc@fa00000 { clock-names =3D "clk_ahb", "clk_xin"; ti,trm-icp =3D <0x2>; ti,otap-del-sel-legacy =3D <0x0>; - ti,otap-del-sel-sd-hs =3D <0xf>; + ti,otap-del-sel-sd-hs =3D <0x0>; ti,otap-del-sel-sdr12 =3D <0xf>; ti,otap-del-sel-sdr25 =3D <0xf>; ti,otap-del-sel-sdr50 =3D <0xc>; ti,otap-del-sel-sdr104 =3D <0x6>; ti,otap-del-sel-ddr50 =3D <0x9>; + ti,itap-del-sel-legacy =3D <0x0>; + ti,itap-del-sel-sd-hs =3D <0x0>; + ti,itap-del-sel-sdr12 =3D <0x0>; + ti,itap-del-sel-sdr25 =3D <0x0>; ti,clkbuf-sel =3D <0x7>; status =3D "disabled"; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E8F36158D61; Sun, 24 Mar 2024 22:38:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319917; cv=none; b=f0l87rY7BRUSkRaM+yWW2WKueZx5YDQWBzX7K58FkFlmQMhUz4r6zvK1Q6kFFKPfs9IGuGj0dgp99SSLS68RkOczCsvHxyE2g/gd+38UFE8NnVYpLt4eMrEwdVvEsoEWtytREtHLzCPFJufgRTQzU+QvqbjnV2lW/X2SniHKqxw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319917; c=relaxed/simple; bh=NWPrkaaaSy9kKYxmurUP9GafqEG7VJh8Z50d+eN03o8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nAc4dywXo9g1jstQa55sxq/ZorNL+vwCeCODnOQRZts4W8C1g6V8Us17uwWRuSclylqQubdwFcAS4COqfN95QrQDtfPFxDRXyy31CAUB+lSpVhbMWFmBhS9hfldNb1UM5ksNSBDbpU5+q/j6WtNalm5WD8HO0nisqIohYM6eXks= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mN3FhzuT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mN3FhzuT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0C60C433F1; Sun, 24 Mar 2024 22:38:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319916; bh=NWPrkaaaSy9kKYxmurUP9GafqEG7VJh8Z50d+eN03o8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mN3FhzuTHqJvmoO4r2pWKNmJ9zVblJNM9BAnZm9Uk/vqfN7t9upk/+FHAo970mG6i Moed8CffcAktcI4MB3xDlfKZtwX+LiYsS+0TGtQbP7EGg54OFT5W5216NhApcmlv95 lTuMMD7DloN3sOPk4gGAdwV0D4j9OcCOgw0DuGGNNz3Wrj7LklilY04qN3ueMGsrfz nix8H4FLy6j0kDQ2Kbwq2Ud2vq6ZyCPaETOhlzuZcjggXP4fQUZ+ne76HGpKXpUvXq 46opjab65jxRP9ETkLUpY975V3iF3b52ap9CtoAg9hk4umiLVcfKte0UPPZGD1ll5J +si3qkSWhN9Og== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hsin-Te Yuan , Hsin-Te Yuan , AngeloGioacchino Del Regno , Sasha Levin Subject: [PATCH 6.8 222/715] arm64: dts: mt8195-cherry-tomato: change watchdog reset boot flow Date: Sun, 24 Mar 2024 18:26:41 -0400 Message-ID: <20240324223455.1342824-223-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hsin-Te Yuan [ Upstream commit ef569d5db50e7edd709e482157769a5b3c367e22 ] The external output reset signal was originally disabled and sent from firmware. However, an unfixed bug in the firmware on tomato prevents the signal from being sent, causing the device to fail to boot. To fix this, enable external output reset signal to allow the device to reboot normally. Fixes: 5eb2e303ec6b ("arm64: dts: mediatek: Introduce MT8195 Cherry platfor= m's Tomato") Signed-off-by: Hsin-Te Yuan Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240124-send-upstream-v3-1-5097c9862a73@ch= romium.org Signed-off-by: AngeloGioacchino Del Regno Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts | 4 ++++ arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r2.dts | 4 ++++ arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r3.dts | 4 ++++ 3 files changed, 12 insertions(+) diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts b/arc= h/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts index 2d5e8f371b6de..a82d716f10d44 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r1.dts @@ -23,3 +23,7 @@ &sound { &ts_10 { status =3D "okay"; }; + +&watchdog { + /delete-property/ mediatek,disable-extrst; +}; diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r2.dts b/arc= h/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r2.dts index 2586c32ce6e6f..2fe20e0dad836 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r2.dts +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r2.dts @@ -43,3 +43,7 @@ &sound { &ts_10 { status =3D "okay"; }; + +&watchdog { + /delete-property/ mediatek,disable-extrst; +}; diff --git a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r3.dts b/arc= h/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r3.dts index f54f9477b99da..dd294ca98194c 100644 --- a/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r3.dts +++ b/arch/arm64/boot/dts/mediatek/mt8195-cherry-tomato-r3.dts @@ -44,3 +44,7 @@ &sound { &ts_10 { status =3D "okay"; }; + +&watchdog { + /delete-property/ mediatek,disable-extrst; +}; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BC7C7158D7C; Sun, 24 Mar 2024 22:38:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319917; cv=none; b=VqZciZcLYDU9DUDdEtXaAmUQnlRtGhtBWCyJqScmOHHcD7XE1NcNqyHZD3rnNlqDs2WCsJDIpA4Nqd5rGOJkXQoN2f6mQLggA1sKtoTEQPBLQO5F34+kgt9ssqi4Sh5XqOGQvLmaaJ4MTB3R6SKmf0jtc6WepfLGVlK4f1IGQPY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319917; c=relaxed/simple; bh=Fsph2RHRgiCvLe/wmjnW94kS4ttpaddfA6Xw96Bl6SY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l5SFYfK34Xpn3t53JZ0m5GqVYL8uh9dE4BXKtNg+z7nkU/+h2LUxTSttOI3PQDKtu6M/7YhfYGQ8TPLraQBE59XC78iJSfG68TbbuSFEVVCKHV5ln4k8q+FOvqgQgdAXLZxbpVjIXmRBN/1ApLyR/9pJEmHivtGT/TIOiJ8IyEQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UJ7dCvSY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UJ7dCvSY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C5155C433C7; Sun, 24 Mar 2024 22:38:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319917; bh=Fsph2RHRgiCvLe/wmjnW94kS4ttpaddfA6Xw96Bl6SY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UJ7dCvSYwY1aMVel2RyswRSM+3/sOJCRB12CJ9j/lSHNpvYLXYXEYHC1pUEL8cSbM 9Ti8/qBnoAx+lncK2yRZhR7KdgUmgbJnmuXZVRTGWtiC2P6HkT3OoXj5Ksh7XejN40 XADKJ2BNobDLqifCn1LFUj6iE8+5McRAafk00wFDunxBo1fXEwybRw+YDfHG1ydA4I KlaG1SESpksXWjT6OQ0CQWdOcpoCFvHVu+RZKkBeyiEfMGrBP3S8BFxwMAJCJYU4Ug U6+h9+H2p/mGHNNCvhuKFsnEBQqmZBKo+Qc19vm42YK4cu7VvmqZqrbovlkI1ONmf0 k8hnLMQaJxN1w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Devarsh Thakkar , Tomi Valkeinen , Aradhya Bhatia , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 223/715] arm64: dts: ti: Add common1 register space for AM65x SoC Date: Sun, 24 Mar 2024 18:26:42 -0400 Message-ID: <20240324223455.1342824-224-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Devarsh Thakkar [ Upstream commit 1a5010eade10b409d353b770d97b548b0fbdf5d7 ] This adds common1 register space for AM65x SoC which is using TI's Keystone display hardware and supporting it as described in Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node") Signed-off-by: Devarsh Thakkar Reviewed-by: Tomi Valkeinen Reviewed-by: Aradhya Bhatia Link: https://lore.kernel.org/r/20240216062426.4170528-3-devarsht@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts= /ti/k3-am65-main.dtsi index fcea544656360..5b2d4365b9111 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi @@ -1019,9 +1019,10 @@ dss: dss@4a00000 { <0x0 0x04a07000 0x0 0x1000>, /* ovr1 */ <0x0 0x04a08000 0x0 0x1000>, /* ovr2 */ <0x0 0x04a0a000 0x0 0x1000>, /* vp1 */ - <0x0 0x04a0b000 0x0 0x1000>; /* vp2 */ + <0x0 0x04a0b000 0x0 0x1000>, /* vp2 */ + <0x0 0x04a01000 0x0 0x1000>; /* common1 */ reg-names =3D "common", "vidl1", "vid", - "ovr1", "ovr2", "vp1", "vp2"; + "ovr1", "ovr2", "vp1", "vp2", "common1"; =20 ti,am65x-oldi-io-ctrl =3D <&dss_oldi_io_ctrl>; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 29E59158D9E; Sun, 24 Mar 2024 22:38:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319919; cv=none; b=CDKaB1etW12UTl79fx+JBRUMU3A1Nhg6rkVyhSseQWaWr1QZ+X7ckY8AQnX8CZt7Q8XTCFAOHaHuH5ZDwhSqNrLoIYfbPr7JPFzhEONnyYkNO5UkacBksE+Rd32ZGllTeqa6wLVQPqhxD28wgh2lHaJpYFnXyyn+U7NM+gnwQ/w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319919; c=relaxed/simple; bh=oeEEazOyNiSzqLggZOqEJTHSkyn2RVzqOkN2OREuYNA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tI5viuyrRJtIkfsFLAB+g3/wwGJE1MuJK63EavPIXgTO810/6fvOGZBlz2cI2ccM47ob3XBv/gvHCrNnwCtOuSBz5/9ypIMOptUuNraCrrNeaURBlFfVoqYRWFfA215U+GV/GXXtEZD/VQzO11yIZFUhZsjpmKYG1+0n8F8PqDw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DKwJcHKH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DKwJcHKH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E0D02C433F1; Sun, 24 Mar 2024 22:38:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319918; bh=oeEEazOyNiSzqLggZOqEJTHSkyn2RVzqOkN2OREuYNA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DKwJcHKHO4e6qFxHO5VP/0gB8YEBRDiGy+qeh1UAFvFeXuqh2JPnsLVI7g+2AVZYU hPfO5JEVlmkDXJDc1Ut3iHHsYlmFL3CCGNMUBF6QYPiPUvjo610g9zSEfxXZwM5Uqw WqU9LD8eGePb/UHcsu76MU1G9K114mcTIGMGxrs1Bkz/b4/+WM1HtLA5XzKXKS8U5k ge+bUCgMOSMA2bRCiXWfBtTpuq81sgAbRvPGmROQO7uXlGqkNgn5iSFVSz6uMET+m4 92GC5/nieZDyJr/8mBePV7Ur/Wi6gisjd42v7p4LUjjyFvTH5PTPABzFBS4QfSjM+K w8u1OQh/Ylk0w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Devarsh Thakkar , Tomi Valkeinen , Aradhya Bhatia , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 224/715] arm64: dts: ti: Add common1 register space for AM62x SoC Date: Sun, 24 Mar 2024 18:26:43 -0400 Message-ID: <20240324223455.1342824-225-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Devarsh Thakkar [ Upstream commit 7d8ee2c3b8a2aabb9ce75795bad20773bfe1ba13 ] This adds common1 register space for AM62x SoC which is using TI's Keystone display hardware and supporting it as described in Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml Fixes: 8ccc1073c7bb ("arm64: dts: ti: k3-am62-main: Add node for DSS") Signed-off-by: Devarsh Thakkar Reviewed-by: Tomi Valkeinen Reviewed-by: Aradhya Bhatia Link: https://lore.kernel.org/r/20240216062426.4170528-4-devarsht@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts= /ti/k3-am62-main.dtsi index c49fbce5cb707..6d07b65a3614e 100644 --- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi @@ -783,9 +783,10 @@ dss: dss@30200000 { <0x00 0x30207000 0x00 0x1000>, /* ovr1 */ <0x00 0x30208000 0x00 0x1000>, /* ovr2 */ <0x00 0x3020a000 0x00 0x1000>, /* vp1: Used for OLDI */ - <0x00 0x3020b000 0x00 0x1000>; /* vp2: Used as DPI Out */ + <0x00 0x3020b000 0x00 0x1000>, /* vp2: Used as DPI Out */ + <0x00 0x30201000 0x00 0x1000>; /* common1 */ reg-names =3D "common", "vidl1", "vid", - "ovr1", "ovr2", "vp1", "vp2"; + "ovr1", "ovr2", "vp1", "vp2", "common1"; power-domains =3D <&k3_pds 186 TI_SCI_PD_EXCLUSIVE>; clocks =3D <&k3_clks 186 6>, <&dss_vp1_clk>, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 406D1159579; Sun, 24 Mar 2024 22:38:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319920; cv=none; b=XIf60F24KzopgwVSQKQwQZWyxcF69NiuxkUeJxaI2HzjpM/sFIpFbFFBBrt2ZR4Z6pkew182zWbwkOwkdJeADneeldore+uUWtqu5oThdK+1afUIhKi9RUxwTem86gYggzxQBSpq+CGtA+z5awI9qbZriM7Ogw0IJSJYR1qHqK0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319920; c=relaxed/simple; bh=1lwHRMfdeOG67Fs2sEkZD3y3XqkdjZSm0N3AdDXg11g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iFlHsx1vHVzol7xmUNet1rHSLvrSVzsFtAwSc4YRJE9sCP452IrvsDvvpTe70+Y22cJukXDAtFFwjeNHUT4PfZQnXreBgPK9FR06cOtWW0vGHBBmmoMhEGr28CbWwLYkC663gGVNiMDqGNvJ/EH1XamIkjJI66KSPIsmML+03tw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WxzNdXKX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WxzNdXKX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0564DC433C7; Sun, 24 Mar 2024 22:38:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319919; bh=1lwHRMfdeOG67Fs2sEkZD3y3XqkdjZSm0N3AdDXg11g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WxzNdXKX8DofVamfeg5k75uCmAfvNP7d+YisU30BHzCIRJPBiYRO7cpRaSNedS01d p4wg2nF0h/xZt3cM9vhjds7eTVjb8yl4LtNgLBTqHfVbcy0ExI3G+wOU7LKj90s8PL IarUiu9AgKeanJj4/0yax/C9aHUxC9+fGM+E3iw7EDmpgIk+D4bvva1WquLeSu0wZZ fHHN7W3My64LzVD5OoimyTDQ8ZF+QkmzGtIG8QK95w+8YJ7eQLF0qT7HaGprz6dSM9 /mmH7WyXth+R4CnikruUaFGoe4cSIZHtBTy6WAHbAet+SgXoshIv68E4dD5iLOo2LN UWdSm7LRUpuZA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andre Przywara , Cristian Marussi , Sudeep Holla , Sasha Levin Subject: [PATCH 6.8 225/715] firmware: arm_scmi: Fix double free in SMC transport cleanup path Date: Sun, 24 Mar 2024 18:26:44 -0400 Message-ID: <20240324223455.1342824-226-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andre Przywara [ Upstream commit f1d71576d2c9ec8fdb822173fa7f3de79475e9bd ] When the generic SCMI code tears down a channel, it calls the chan_free callback function, defined by each transport. Since multiple protocols might share the same transport_info member, chan_free() might want to clean up the same member multiple times within the given SCMI transport implementation. In this case, it is SMC transport. This will lead to a NULL pointer dereference at the second time: | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16 | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled. | arm-scmi firmware:scmi: unable to communicate with SCMI | Unable to handle kernel NULL pointer dereference at virtual address 0= 000000000000000 | Mem abort info: | ESR =3D 0x0000000096000004 | EC =3D 0x25: DABT (current EL), IL =3D 32 bits | SET =3D 0, FnV =3D 0 | EA =3D 0, S1PTW =3D 0 | FSC =3D 0x04: level 0 translation fault | Data abort info: | ISV =3D 0, ISS =3D 0x00000004, ISS2 =3D 0x00000000 | CM =3D 0, WnR =3D 0, TnD =3D 0, TagAccess =3D 0 | GCS =3D 0, Overlay =3D 0, DirtyBit =3D 0, Xs =3D 0 | user pgtable: 4k pages, 48-bit VAs, pgdp=3D0000000881ef8000 | [0000000000000000] pgd=3D0000000000000000, p4d=3D0000000000000000 | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP | Modules linked in: | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016= c9-dirty #793 | Hardware name: FVP Base RevC (DT) | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=3D--) | pc : smc_chan_free+0x3c/0x6c | lr : smc_chan_free+0x3c/0x6c | Call trace: | smc_chan_free+0x3c/0x6c | idr_for_each+0x68/0xf8 | scmi_cleanup_channels.isra.0+0x2c/0x58 | scmi_probe+0x434/0x734 | platform_probe+0x68/0xd8 | really_probe+0x110/0x27c | __driver_probe_device+0x78/0x12c | driver_probe_device+0x3c/0x118 | __driver_attach+0x74/0x128 | bus_for_each_dev+0x78/0xe0 | driver_attach+0x24/0x30 | bus_add_driver+0xe4/0x1e8 | driver_register+0x60/0x128 | __platform_driver_register+0x28/0x34 | scmi_driver_init+0x84/0xc0 | do_one_initcall+0x78/0x33c | kernel_init_freeable+0x2b8/0x51c | kernel_init+0x24/0x130 | ret_from_fork+0x10/0x20 | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280) | ---[ end trace 0000000000000000 ]--- Simply check for the struct pointer being NULL before trying to access its members, to avoid this situation. This was found when a transport doesn't really work (for instance no SMC service), the probe routines then tries to clean up, and triggers a crash. Signed-off-by: Andre Przywara Fixes: 1dc6558062da ("firmware: arm_scmi: Add smc/hvc transport") Reviewed-by: Cristian Marussi Link: https://lore.kernel.org/r/20240126122325.2039669-1-andre.przywara@arm= .com Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/firmware/arm_scmi/smc.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/firmware/arm_scmi/smc.c b/drivers/firmware/arm_scmi/sm= c.c index 7611e9665038d..39936e1dd30e9 100644 --- a/drivers/firmware/arm_scmi/smc.c +++ b/drivers/firmware/arm_scmi/smc.c @@ -214,6 +214,13 @@ static int smc_chan_free(int id, void *p, void *data) struct scmi_chan_info *cinfo =3D p; struct scmi_smc *scmi_info =3D cinfo->transport_info; =20 + /* + * Different protocols might share the same chan info, so a previous + * smc_chan_free call might have already freed the structure. + */ + if (!scmi_info) + return 0; + /* Ignore any possible further reception on the IRQ path */ if (scmi_info->irq > 0) free_irq(scmi_info->irq, scmi_info); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E674415958B; Sun, 24 Mar 2024 22:38:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319921; cv=none; b=QJfBwRezDC1SrRnxoONPgOhIg3J2cSlc2EgtwxTpFw6bdAC2dfFwhzJE8xHyzXWrqWqGirS6Y+EUM9EimqjbzltTNVBrEbXGETemUMEeGtLsTHABxF4A1Wr3tSAggJUd6ZE+cBvRBG9ugC8M0wwgZ0GblAQUWNXctcYcJe1MoLk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319921; c=relaxed/simple; bh=DrXP0gs68dleLeX1kuokUh6LqmywretmDJba3cfde2w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qGtqGrhKaBPBQgactq52GCvGP4yJk7ZoutTty0dI6ykGd2bVAWXftiPjco+lJle1LUAbKXEdd4Q8qBldwsUbgPsSd8LDJfYq5l2uGC4Z/WKDT/2CLMVhV0rFz+Q4Ldae9X6t3DfIOFe0ZSAuXNc8za7r2d2n0UDGaOz1Ly0sPGQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=fail (0-bit key) header.d=kernel.org header.i=@kernel.org header.b=MNi9Duwq reason="key not found in DNS"; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=kernel.org header.i=@kernel.org header.b="MNi9Duwq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A72FC43399; Sun, 24 Mar 2024 22:38:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319920; bh=DrXP0gs68dleLeX1kuokUh6LqmywretmDJba3cfde2w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MNi9DuwqzQXb9Q8+sd33F7xjwxxha+BhOqzEfGKp6/HGPR3rk5gxW48deIbKRDJqn v/9vH+YOYaeRTnIV7OHg5DCIp4XF2g6CPHlKNZ5KgosqhV/DJoFqp+O2Vsu3f8EzGq TP/2LDVhMAe69hY5fHfLz+W42t/9//VT2eVLkXET+nxmmg3JwR6dpH1VESxOGCR3qZ v9nlN5w6sxWRyGpsiP9fqsiueioao5grA+bc5ESS39PfsBIauYQ5LdyOVyr1rHYhYR qwocEZH3cSmPsEdRZdp+Lanxnq6TKzReSIMdqM+bFQdxgXFBdBzZkuJJhGZo3SnlIo 863VUQmgq1FgQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benjamin Berg , Johannes Berg , Miri Korenblit , Sasha Levin Subject: [PATCH 6.8 226/715] wifi: cfg80211: set correct param change count in ML element Date: Sun, 24 Mar 2024 18:26:45 -0400 Message-ID: <20240324223455.1342824-227-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benjamin Berg [ Upstream commit f8599d634094b1257054a8d0815785d658cbdb74 ] The ML element generation code to create a BSS entry from a per-STA profile was not overwriting the BSS parameter change count. This meant that the incorrect parameter change count would be reported within the multi-link element. Fix this by returning the BSS parameter change count from the function and placing it into the ML element. The returned tbtt info was never used, so just drop that to simplify the code. Fixes: 5f478adf1f99 ("wifi: cfg80211: generate an ML element for per-STA pr= ofiles") Signed-off-by: Benjamin Berg Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://msgid.link/20240216135047.f2a507634692.I06b122c7a319a38b4e970= f5e0bd3d3ef9cac4cbe@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/wireless/scan.c | 26 ++++++++++++++++---------- 1 file changed, 16 insertions(+), 10 deletions(-) diff --git a/net/wireless/scan.c b/net/wireless/scan.c index 7c9dc52ed783e..f138f88be9048 100644 --- a/net/wireless/scan.c +++ b/net/wireless/scan.c @@ -2602,9 +2602,9 @@ cfg80211_defrag_mle(const struct element *mle, const = u8 *ie, size_t ielen, } =20 static u8 -cfg80211_tbtt_info_for_mld_ap(const u8 *ie, size_t ielen, u8 mld_id, u8 li= nk_id, - const struct ieee80211_neighbor_ap_info **ap_info, - const u8 **tbtt_info) +cfg80211_rnr_info_for_mld_ap(const u8 *ie, size_t ielen, u8 mld_id, u8 lin= k_id, + const struct ieee80211_neighbor_ap_info **ap_info, + u8 *param_ch_count) { const struct ieee80211_neighbor_ap_info *info; const struct element *rnr; @@ -2661,7 +2661,9 @@ cfg80211_tbtt_info_for_mld_ap(const u8 *ie, size_t ie= len, u8 mld_id, u8 link_id, if (mld_id =3D=3D mld_params->mld_id && link_id =3D=3D lid) { *ap_info =3D info; - *tbtt_info =3D pos; + *param_ch_count =3D + le16_get_bits(mld_params->params, + IEEE80211_RNR_MLD_PARAMS_BSS_CHANGE_COUNT); =20 return use_for; } @@ -2871,8 +2873,8 @@ cfg80211_parse_ml_elem_sta_data(struct wiphy *wiphy, enum nl80211_band band; u32 freq; const u8 *profile; - const u8 *tbtt_info; ssize_t profile_len; + u8 param_ch_count; u8 link_id, use_for; =20 if (!ieee80211_mle_basic_sta_prof_size_ok((u8 *)mle->sta_prof[i], @@ -2915,10 +2917,11 @@ cfg80211_parse_ml_elem_sta_data(struct wiphy *wiphy, profile_len -=3D 2; =20 /* Find in RNR to look up channel information */ - use_for =3D cfg80211_tbtt_info_for_mld_ap(tx_data->ie, - tx_data->ielen, - mld_id, link_id, - &ap_info, &tbtt_info); + use_for =3D cfg80211_rnr_info_for_mld_ap(tx_data->ie, + tx_data->ielen, + mld_id, link_id, + &ap_info, + ¶m_ch_count); if (!use_for) continue; =20 @@ -2961,7 +2964,8 @@ cfg80211_parse_ml_elem_sta_data(struct wiphy *wiphy, continue; =20 /* Copy the Basic Multi-Link element including the common - * information, and then fix up the link ID. + * information, and then fix up the link ID and BSS param + * change count. * Note that the ML element length has been verified and we * also checked that it contains the link ID. */ @@ -2972,6 +2976,8 @@ cfg80211_parse_ml_elem_sta_data(struct wiphy *wiphy, sizeof(*ml_elem) + ml_common_len); =20 new_ie[data.ielen + sizeof(*ml_elem) + 1 + ETH_ALEN] =3D link_id; + new_ie[data.ielen + sizeof(*ml_elem) + 1 + ETH_ALEN + 1] =3D + param_ch_count; =20 data.ielen +=3D sizeof(*ml_elem) + ml_common_len; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA6E515A487; Sun, 24 Mar 2024 22:38:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319921; cv=none; b=pskPb0fyjWhdzqfXBGZ0N5VNHwvUyVMXlju/kpaQ/MwhPVmWHKe0IBW5hEeV+e7RVwLjlutCLBjCbdUH/yETJVwHmIukcXDefdn8GHugJ+CqYKnWNZGg/WHeV9nho9Lcrss9bT4aF3nxrYTUKGMN8SiinYrWx6jov8VDzv76lsA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319921; c=relaxed/simple; bh=SSauXZUCi0ZbV1EEAVHKrppW6w6f8R/euJkogkXNDF0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mIQeVqvAAZQPnfvh8a7qy+7cKe3GtVCpJi0jl0HLz8NPlIvSwM8B8Ebn41F4nafcegoPQYV6c+s/tXHDlyrX/QMegTGQSEctgjn0tz58YommnXJYJXcIOcPT1gJVtoqXOUAnDuObuQOSG4OksXhYGRL+dourdbZXQ+xOKoWWcSc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o0CbkE7t; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="o0CbkE7t" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D697C433F1; Sun, 24 Mar 2024 22:38:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319921; bh=SSauXZUCi0ZbV1EEAVHKrppW6w6f8R/euJkogkXNDF0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o0CbkE7tGKlC6p5NiUdNMHa2v6v/OgH4MtQPzcOVc81dTg5O9hHDUDoP+GDlgboua XRwSd0vbgO7Uu6hKQdJYzQsMwpcucW8lBNOMJUwYyX5k2Hno359irNyqwbbdcAPXGY 9BD5a5deAC7ygxjc8YrlD34BroLsxUzS8DSEcLBSFwAdjvh5yM0QOs49fXWiSE0bMx lHu0vq73bE3IGZcgUNBzPciFE444F/MXHJ+xnpbI5ZKNcRqv07ZnhJwkIQ/KBvnW2Z nEYSLXTyKm41N9p0GICSa0lZ5HJDepPUDl3xliM5Kq+G0oB7Jik1vI22z33tRl6zrH Qb4xBXT5T207w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrew Davis , Peter Rosin , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 227/715] arm64: dts: ti: k3-j721e: Fix mux-reg-masks in hbmc_mux Date: Sun, 24 Mar 2024 18:26:46 -0400 Message-ID: <20240324223455.1342824-228-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrew Davis [ Upstream commit 3d585389d454e147187684e492a0eb8f56adf311 ] Change offset in mux-reg-masks property for hbmc_mux node since reg-mux property is used in compatible. While here, update the reg region to include 4 bytes as this is a 32bit register. Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not= a syscon") Suggested-by: Peter Rosin Signed-off-by: Andrew Davis Link: https://lore.kernel.org/r/20240215141957.13775-1-afd@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/b= oot/dts/ti/k3-j721e-mcu-wakeup.dtsi index a74912d9e4daf..c463e23ced04e 100644 --- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi +++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi @@ -353,9 +353,9 @@ fss: bus@47000000 { =20 hbmc_mux: mux-controller@47000004 { compatible =3D "reg-mux"; - reg =3D <0x00 0x47000004 0x00 0x2>; + reg =3D <0x00 0x47000004 0x00 0x4>; #mux-control-cells =3D <1>; - mux-reg-masks =3D <0x4 0x2>; /* HBMC select */ + mux-reg-masks =3D <0x0 0x2>; /* HBMC select */ }; =20 hbmc: hyperbus@47034000 { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4E5E015A4B2; Sun, 24 Mar 2024 22:38:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319923; cv=none; b=QFnJek4hb5s4p6CeDrqKsTMG7nsc+4DF85mID9Ppsqx40PHXVvuRh1f9sHP3rLPV6/8MNrm8pVXH7XP4dYGSmc89uIiMFYoc7K5WGrYszrhzr98K3xHArqWqzX7P4G/xrp6KJdk4CSPoSoT24/CiO0sM+HJwD53Q2jOihxx6Ois= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319923; c=relaxed/simple; bh=zUMXudOLJzroedM2iuRziZdAstmhElFFeH8iJ3zqLMI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SUO1lpBzXM3vvZeFD1ownd0FC4orXyIoH1ZdTxjr4sbgMdLjGm/PUrQ+KWZpxZVWColDXO6QI3yjoh450wRK30x9plRjiqTtbjP+GlE6629Of5bEd6xSwkrTqLW+Am5/ztRp/YGU8rRMjOkJq+pguyFZiWlvlq1YBJAFx+T5ib0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kN126w52; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kN126w52" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CC63C43399; Sun, 24 Mar 2024 22:38:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319922; bh=zUMXudOLJzroedM2iuRziZdAstmhElFFeH8iJ3zqLMI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kN126w52hxJU5eUd6SSPhU+QgMRxupk/oDNvzw1t90C0BUwQBN15HnWkdDQgyYvOL +0RWgw1NGfHSI5oFzKdzf1NOKkW2G8mq35YGNQsN1a+3zkd8ppuIvOcnA0jSHaj103 Agm18Do8CeI420RZTV5/dUI0NQBx0bWUCh4QcGNhziDXB8y8RXO3HvtUs4I42fumRh rtVGbppeFQHVvSFpC2xjSxmEHbGN3+TckEoS3Z3Mx/zs3eYoLGcKHMh2mUpyBiOs8X izch5N2agR6krpN59rIrwH9X/368hiyz+2X+QWGSGihh2dPepTFpNBc0JgRY4GpCuG khImLDLqLkp8Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chintan Vankar , Andrew Davis , Siddharth Vadapalli , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 228/715] arm64: dts: ti: k3-j784s4-main: Fix mux-reg-masks in serdes_ln_ctrl Date: Sun, 24 Mar 2024 18:26:47 -0400 Message-ID: <20240324223455.1342824-229-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chintan Vankar [ Upstream commit 9a0c0a9baa2d1f906589d715f9baeab93e7fcdcb ] Change offset in mux-reg-masks property for serdes_ln_ctrl node since reg-mux property is used in compatible. Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not= a syscon") Signed-off-by: Chintan Vankar Acked-by: Andrew Davis Signed-off-by: Siddharth Vadapalli Link: https://lore.kernel.org/r/20240213080348.248916-1-s-vadapalli@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/d= ts/ti/k3-j784s4-main.dtsi index f2b720ed1e4f2..56c8eaad6324b 100644 --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi @@ -52,12 +52,12 @@ serdes_ln_ctrl: mux-controller@4080 { compatible =3D "reg-mux"; reg =3D <0x00004080 0x30>; #mux-control-cells =3D <1>; - mux-reg-masks =3D <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select= */ - <0x4088 0x3>, <0x408c 0x3>, /* SERDES0 lane2/3 select */ - <0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */ - <0x4098 0x3>, <0x409c 0x3>, /* SERDES1 lane2/3 select */ - <0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */ - <0x40a8 0x3>, <0x40ac 0x3>; /* SERDES2 lane2/3 select */ + mux-reg-masks =3D <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */ + <0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */ + <0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */ + <0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */ + <0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */ + <0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */ idle-states =3D , , , --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C38015AAA6; Sun, 24 Mar 2024 22:38:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319924; cv=none; b=oFDoAwauAw8TfDLQyudrPGAp6bPiUL+N79HP7YGR9XdwLqwVWDVXBwsXSDrUPH47FARaQwKnu3zV/UH4gWvB3tmqb1R2c6aDh+92J2chuYSakGDxybMuV/Ir+G2r3+Co/Upnmx/17SiR+oTRWbCHknxti1kmpE5tkktfoIkY5NA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319924; c=relaxed/simple; bh=hqBbDuRgdmrUloL1U9utTYvFeiQt+JTbYKGUkQT9D1M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XWrr2oDh8bMNyP5A4p5jxq33ysfIJBVC3fNLJmVLCSkGaUZ1Q6J/nXQNfDaWGA9c27uwhz8+4wP0QZuu8i2Mp50s8wjvzkmEQFYnSY8j9Co6CI0hjel8/2kj9YVVePp6X1JjG9o8n40NLDr6b+xG4sMAwCuQ+HqSQajMINXI9o0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QTxnZVee; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QTxnZVee" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2E08AC433A6; Sun, 24 Mar 2024 22:38:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319923; bh=hqBbDuRgdmrUloL1U9utTYvFeiQt+JTbYKGUkQT9D1M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QTxnZVeecO+VLUQRBhVUW/N6SbzpAGEgI09N9wU3L/wxfC1d+MrnBh+mYTrcKbN8L Q7ZW5u7uoqg829o3KU4I3vXJZGhh0IzYm5vM1GoeWhgvjaUYE7QNCoUvCgYx/lRf4j 344J2qTp8wmkKgAAV9LBO0ajceT98imkzZYCjb63ZDdrSEoZKoOBsmfBOhQNaJPb4z tFNzoD5c9LO0fjZ6pTVk1KFO8wB90y2IZ+zedSAt7nmUFrsVW6TPnFSvpwP2Yn3p1V wMEN5WbnlhqMa4eKXd3hw96NjQnE6sULwOqids8Y5o8B2q4d2sivwcuiewseWcuaXt oPxHB5TSAggwA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jai Luthra , Vaishnav Achath , Vignesh Raghavendra , Sasha Levin Subject: [PATCH 6.8 229/715] arm64: dts: ti: k3-am62p: Fix memory ranges for DMSS Date: Sun, 24 Mar 2024 18:26:48 -0400 Message-ID: <20240324223455.1342824-230-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jai Luthra [ Upstream commit 90a67583171f213711de662fab9f8d24a2d291a9 ] The INTR module for DMASS1 (CSI specific DMASS) is outside the currently available ranges, as it starts at 0x4e400000. So fix the ranges property to enable programming the interrupts correctly. Fixes: 29075cc09f43 ("arm64: dts: ti: Introduce AM62P5 family of SoCs") Reviewed-by: Vaishnav Achath Signed-off-by: Jai Luthra Link: https://lore.kernel.org/r/20240220-am62p_csi-v2-1-3e71d9945571@ti.com Signed-off-by: Vignesh Raghavendra Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/ti/k3-am62p.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/ti/k3-am62p.dtsi b/arch/arm64/boot/dts/ti/= k3-am62p.dtsi index 84ffe7b9dcaf3..4f22b5d9fb9f0 100644 --- a/arch/arm64/boot/dts/ti/k3-am62p.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am62p.dtsi @@ -71,7 +71,7 @@ cbass_main: bus@f0000 { <0x00 0x43600000 0x00 0x43600000 0x00 0x00010000>, /* SA3 sproxy data = */ <0x00 0x44043000 0x00 0x44043000 0x00 0x00000fe0>, /* TI SCI DEBUG */ <0x00 0x44860000 0x00 0x44860000 0x00 0x00040000>, /* SA3 sproxy confi= g */ - <0x00 0x48000000 0x00 0x48000000 0x00 0x06400000>, /* DMSS */ + <0x00 0x48000000 0x00 0x48000000 0x00 0x06408000>, /* DMSS */ <0x00 0x60000000 0x00 0x60000000 0x00 0x08000000>, /* FSS0 DAT1 */ <0x00 0x70000000 0x00 0x70000000 0x00 0x00010000>, /* OCSRAM */ <0x01 0x00000000 0x01 0x00000000 0x00 0x00310000>, /* A53 PERIPHBASE */ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 28BB015AACA; Sun, 24 Mar 2024 22:38:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319925; cv=none; b=Rv8qJDF0vpKepTV1NHMFkjqizE25LcxcgLB0oYQ/WD+0jsaKg6x+4gik7v0uIPgeDMXDOm7fomhWV5UK8KoSNbFTyQcUXGnZrV4VB9U3N0dC+SCE7E5C7Tmp7Ropc5C7HVD0UtH3O3OSKQutY3Xk3IVa6EyPvEEMeT/vk3nGW1o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319925; c=relaxed/simple; bh=hbKIBNSWUPiHR4rMABXrgLXVEZf8rqQ5ZcXfkHHMod8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=DG0iE8bQxhVmnBx1muL7vFxCgQ575PpO7r2SVHm99S4R2Fem58+wW0ql+Yvxc1RI1ZMsJcxKxf3Izp/PsgT6NCMl1ooMYvSOZMLhEQ6IHVzZwfAxOWinFSwQIqUMdSxCfxJERCFaYSvUfKRePoe2LaUd3nGtD2WII10Ed+EqMKo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nnD09Lxq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nnD09Lxq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3318DC433F1; Sun, 24 Mar 2024 22:38:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319925; bh=hbKIBNSWUPiHR4rMABXrgLXVEZf8rqQ5ZcXfkHHMod8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nnD09LxqSknO0ys30zh+0VeL/hf8tlMwPONH9qCgJqsGh4z4Z80fbN2oMdnzyl2EY jcYaV8uZ+OMiUT9SX86MJszbzlfcCpgPSlTkg2SGGD4NVOdYUmYlf9xBIryHjGo4UK 8HaJfu6c5bANI12rOTLvGdjEZdtyrSWzK2s34HOhZlH540sB7BPjYFo9LPmqZ2qxz+ ZO43+B2LXO0n132hPzVGG6Asd9Qzgt5P9T3IIXWK+bpGPoN+o/9eHDI+q+auMwefoC jGPqk6AdrB4bK+hd/EA7+FDsEW4TEju8+fZzdwV44pSrs/U2rNiGxPNuDWCq3gC9Uo TrBCW9arBLBOg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Alexis=20Lothor=C3=A9?= , Conor Dooley , Ajay Singh , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 230/715] wifi: wilc1000: revert reset line logic flip Date: Sun, 24 Mar 2024 18:26:49 -0400 Message-ID: <20240324223455.1342824-231-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Alexis Lothor=C3=A9 [ Upstream commit f3ec643947634bed41b97bd56b248f7c78498eab ] This reverts commit fcf690b0b47494df51d214db5c5a714a400b0257. When using a wilc1000 chip over a spi bus, users can optionally define a reset gpio and a chip enable gpio. The reset line of wilc1000 is active low, so to hold the chip in reset, a low (physical) value must be applied. The corresponding device tree binding documentation was introduced by commit f31ee3c0a555 ("wilc1000: Document enable-gpios and reset-gpios properties") and correctly indicates that the reset line is an active-low signal. The corresponding driver part, brought by commit ec031ac4792c ("wilc1000: Add reset/enable GPIO support to SPI driver") was applying the correct logic. But commit fcf690b0b474 ("wifi: wilc1000: use correct sequence of RESET for chip Power-UP/Down") eventually flipped this logic and started misusing the gpiod APIs, applying an inverted logic when powering up/down the chip (for example, setting the reset line to a logic "1" during power up, which in fact asserts the reset line when device tree describes the reset line as GPIO_ACTIVE_LOW). As a consequence, any platform currently using the driver in SPI mode must use a faulty reset line description in device tree, or else chip will be maintained in reset and will not even allow to bring up the chip. Fix reset line usage by inverting back the gpiod APIs usage, setting the reset line to the logic value "0" when powering the chip, and the logic value "1" when powering off the chip. Fixes: fcf690b0b474 ("wifi: wilc1000: use correct sequence of RESET for chi= p Power-UP/Down") Signed-off-by: Alexis Lothor=C3=A9 Acked-by: Conor Dooley Acked-by: Ajay Singh Signed-off-by: Kalle Valo Link: https://msgid.link/20240217-wilc_1000_reset_line-v2-1-b216f433d7d5@bo= otlin.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/microchip/wilc1000/spi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/microchip/wilc1000/spi.c b/drivers/net/wi= reless/microchip/wilc1000/spi.c index 1d8b241ce43ca..6a82b6ca2769e 100644 --- a/drivers/net/wireless/microchip/wilc1000/spi.c +++ b/drivers/net/wireless/microchip/wilc1000/spi.c @@ -192,11 +192,11 @@ static void wilc_wlan_power(struct wilc *wilc, bool o= n) /* assert ENABLE: */ gpiod_set_value(gpios->enable, 1); mdelay(5); - /* assert RESET: */ - gpiod_set_value(gpios->reset, 1); - } else { /* deassert RESET: */ gpiod_set_value(gpios->reset, 0); + } else { + /* assert RESET: */ + gpiod_set_value(gpios->reset, 1); /* deassert ENABLE: */ gpiod_set_value(gpios->enable, 0); } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 67E0215AABA; Sun, 24 Mar 2024 22:38:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319926; cv=none; b=X64y50pHV5jpVi6fZjjQ38NDI0mEX8tHMYUt+rIsCzt/J3paXbOmdEDJkgqI2t4H/LG1va91QiAKtNyJTwQG1dJiRaC/hTE0RsqPSeS86BH3XOkyS9rfi33MCapDP02vSqiMCVBs79PlBhS7PkKnb4fJThHWPU3OWLl605dUo4Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319926; c=relaxed/simple; bh=YKVcdpL5+OrlaJ4q8k+EUbtblJGBjMh/yaBxJ7pH7dk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HDcb2JVT7J9Px6m1CEfwN7LjMjaQtGsFf+rvyGkOkyoNcsbsmezKfWcJBuO8ZW/1GY3dEnqij3r4PxHNC2kBPzuh+6383YSJ7ALDA/qbuMaJ4q9az7QU9aMkJ04GTnlbrLNZPBPnC5HDnQNMrNjoXPAkhIcBYdEOZuOCTrBPtXo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UGmVaUxx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UGmVaUxx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5085CC433F1; Sun, 24 Mar 2024 22:38:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319925; bh=YKVcdpL5+OrlaJ4q8k+EUbtblJGBjMh/yaBxJ7pH7dk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UGmVaUxxH/20XO0jOQdLM+cugdInnVvxqWQ6LBB5DVCfD/2MQ23nIe9H8cWypRua+ YTElvjOhfRdMphvmppxjSkypX7z8L9RxIHaLzDmTiLvF+HAKSeF4ZXl1X+PEY4Llkx JhXs/2GSwpq7vOmSnILVHs+6PTFD+m5bKx3uC0ygpPn3RHHkHoQxmiwc5jp/9PIgHY TdPJ//PU4+LL+IXqu2Dx2mddPCXiN/iPJzV8sWaFdrMxjl/6FOon42HdtNu/yd7yaQ UqqAEm/fAn7H2Pyezc9m0jnults5ehcugJejSW451ZUgSZOWWBh7bPvBdAp9IaMv9N TVzFqiB6YxMOw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Geert Uytterhoeven , Linus Walleij , Sasha Levin Subject: [PATCH 6.8 231/715] ARM: dts: arm: realview: Fix development chip ROM compatible value Date: Sun, 24 Mar 2024 18:26:50 -0400 Message-ID: <20240324223455.1342824-232-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Geert Uytterhoeven [ Upstream commit 3baa4c5143d65ebab2de0d99a395e5f4f1f46608 ] When the development chip ROM was added, the "direct-mapped" compatible value was already obsolete. In addition, the device node lacked the accompanying "probe-type" property, causing the old physmap_of_core driver to fall back to trying all available probe types. Unfortunately this fallback was lost when the DT and pdata cases were merged. Fix this by using the modern "mtd-rom" compatible value instead. Fixes: 5c3f5edbe0a1dff3 ("ARM: realview: add flash devices to the PB1176 DT= S") Fixes: 642b1e8dbed7bbbf ("mtd: maps: Merge physmap_of.c into physmap-core.c= ") Signed-off-by: Geert Uytterhoeven Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm/boot/dts/arm/arm-realview-pb1176.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/arm/arm-realview-pb1176.dts b/arch/arm/boot/= dts/arm/arm-realview-pb1176.dts index efed325af88d2..d99bac02232b3 100644 --- a/arch/arm/boot/dts/arm/arm-realview-pb1176.dts +++ b/arch/arm/boot/dts/arm/arm-realview-pb1176.dts @@ -451,7 +451,7 @@ pb1176_serial3: serial@1010f000 { =20 /* Direct-mapped development chip ROM */ pb1176_rom@10200000 { - compatible =3D "direct-mapped"; + compatible =3D "mtd-rom"; reg =3D <0x10200000 0x4000>; bank-width =3D <1>; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E641115B0F7; Sun, 24 Mar 2024 22:38:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319927; cv=none; b=h0xHgVq904on9CMS9gcX5VpgpW9hMWXnTHYWxL3+oaA0sL5jo8rXXA6zAZPY8wzhMxLmMR7awoNuGCW1o63kzhMNx7h5pWHjyizdv8D+qvJkoYHB1E22nWPgz70GY7I3B3HotxhFvII0qvaINsxccXN762OAjEol+wU1qTpuD7w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319927; c=relaxed/simple; bh=FqGypTOb490W/ywG+V8ao7/xpZ8vZxNiO43DA4jiXGk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VbXJMA4Hw9fFo0CM18eRSnow2C0RwuVmEzVozHND4zEUdBkCQIscKBwLJZ/V/Ak1V44NiHS2Uw10LcLYpVIC2xKrzZMfuqR2QaVnCTZPFvnQViUCcPudMuFpSKlHwyWXqGQmUVkv1udWnGYSrfxRYuLiaRc/TfFLMN71wFiINbM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oHBeiNQb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oHBeiNQb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 33CD6C43399; Sun, 24 Mar 2024 22:38:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319926; bh=FqGypTOb490W/ywG+V8ao7/xpZ8vZxNiO43DA4jiXGk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oHBeiNQb+Bhi4uL5yQT9gNH6JgwLO2RDImgQ4cIAvP/LmYxR1XkSHau9ZiHs1EOn5 EB2tmayZcroWnN0VwGcuzgmVizE//aO20UIgH04ber2GC15Kdh/zUjDbQSSgAABD6q G8BE6+qkD2dPAKqcebRgCgCk0q0S1DzQdQV+1DI/cCRx8A7Ri06lCHZnvoT3Kc+/Uy 2rhG9FC1d6oJtVHbrf45o+02Fd0qcQIcLTvnIzqesmP6o7UtIqYLZb1GFE9URu2Ug7 ZlduYO1YuI92dm08Sdgf3kSjq57WlTqVvA2lJo9vI7D30X1/KDPWCBbaUd1B1SdwHd Rlmedjw+xohPQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jon Hunter , Krzysztof Kozlowski , Sasha Levin Subject: [PATCH 6.8 232/715] memory: tegra: Correct DLA client names Date: Sun, 24 Mar 2024 18:26:51 -0400 Message-ID: <20240324223455.1342824-233-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jon Hunter [ Upstream commit 51d915cbeef4c7a154f5d810b1e10d8125f2b0cc ] Some of the names for the Tegra234 DLA clients are not unique and do not align with the name of the client ID definitions. Therefore, it is not possible to determine the exact DLA client from messages that print the client name. Fix this by correcting the DLA memory client names for Tegra234 to align with the name of the corresponding memory client ID. Note that although the client names are also used by the interconnect framework, interconnect support for the DLA clients has not been added and so this issue does not impact the interconnect support. Fixes: 5cd24ca0985f ("memory: tegra: Add DLA clients for Tegra234") Signed-off-by: Jon Hunter Link: https://lore.kernel.org/r/20240220124430.19072-1-jonathanh@nvidia.com Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/memory/tegra/tegra234.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/drivers/memory/tegra/tegra234.c b/drivers/memory/tegra/tegra23= 4.c index abff87f917cb4..b8a7af2d36c11 100644 --- a/drivers/memory/tegra/tegra234.c +++ b/drivers/memory/tegra/tegra234.c @@ -121,7 +121,7 @@ static const struct tegra_mc_client tegra234_mc_clients= [] =3D { }, }, { .id =3D TEGRA234_MEMORY_CLIENT_DLA1RDB, - .name =3D "dla0rdb", + .name =3D "dla1rdb", .sid =3D TEGRA234_SID_NVDLA1, .regs =3D { .sid =3D { @@ -407,7 +407,7 @@ static const struct tegra_mc_client tegra234_mc_clients= [] =3D { }, }, { .id =3D TEGRA234_MEMORY_CLIENT_DLA1RDB1, - .name =3D "dla0rdb1", + .name =3D "dla1rdb1", .sid =3D TEGRA234_SID_NVDLA1, .regs =3D { .sid =3D { @@ -417,7 +417,7 @@ static const struct tegra_mc_client tegra234_mc_clients= [] =3D { }, }, { .id =3D TEGRA234_MEMORY_CLIENT_DLA1WRB, - .name =3D "dla0wrb", + .name =3D "dla1wrb", .sid =3D TEGRA234_SID_NVDLA1, .regs =3D { .sid =3D { @@ -699,7 +699,7 @@ static const struct tegra_mc_client tegra234_mc_clients= [] =3D { }, }, { .id =3D TEGRA234_MEMORY_CLIENT_DLA1RDA, - .name =3D "dla0rda", + .name =3D "dla1rda", .sid =3D TEGRA234_SID_NVDLA1, .regs =3D { .sid =3D { @@ -709,7 +709,7 @@ static const struct tegra_mc_client tegra234_mc_clients= [] =3D { }, }, { .id =3D TEGRA234_MEMORY_CLIENT_DLA1FALRDB, - .name =3D "dla0falrdb", + .name =3D "dla1falrdb", .sid =3D TEGRA234_SID_NVDLA1, .regs =3D { .sid =3D { @@ -719,7 +719,7 @@ static const struct tegra_mc_client tegra234_mc_clients= [] =3D { }, }, { .id =3D TEGRA234_MEMORY_CLIENT_DLA1WRA, - .name =3D "dla0wra", + .name =3D "dla1wra", .sid =3D TEGRA234_SID_NVDLA1, .regs =3D { .sid =3D { @@ -729,7 +729,7 @@ static const struct tegra_mc_client tegra234_mc_clients= [] =3D { }, }, { .id =3D TEGRA234_MEMORY_CLIENT_DLA1FALWRB, - .name =3D "dla0falwrb", + .name =3D "dla1falwrb", .sid =3D TEGRA234_SID_NVDLA1, .regs =3D { .sid =3D { @@ -917,7 +917,7 @@ static const struct tegra_mc_client tegra234_mc_clients= [] =3D { }, }, { .id =3D TEGRA234_MEMORY_CLIENT_DLA1RDA1, - .name =3D "dla0rda1", + .name =3D "dla1rda1", .sid =3D TEGRA234_SID_NVDLA1, .regs =3D { .sid =3D { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A05715B119; Sun, 24 Mar 2024 22:38:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319928; cv=none; b=j+g/30etb1kdZm8VOYe9+z/23J2Rc4y3NnoDTjpw6UIuCLKA1vs6tAScYaaOOGg2enZoIII94gwGn88F9Pe0XuSSW2JZ1FLkpxkw/LmwJ4SIniUGBMAXYv67qJA543K2yl62COda9OQAFkj+SwPS5/8DEROPA7dN4gtKl72zRbU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319928; c=relaxed/simple; bh=4HXVmvJJAi7+alimoqiVvNXc6ec3CXY1JNDIKUw8Mp8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gJkwIWP+tHLtfiEE/fRB9KuwKxAVJLYyyk8k5a88XI1s6rLmLuIj/BtuUkiwX/bBoUK+op0bqw4tzs5H7DFaznN4fwPoiqq3O7dKMhT187ukkPdMz8+Or0RNdTr+OMFVz2XhTLPXhSIsLYOXf/ybUAQJj9/sEICZmLvRWGumGp0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oviC+T9+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oviC+T9+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17069C43390; Sun, 24 Mar 2024 22:38:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319927; bh=4HXVmvJJAi7+alimoqiVvNXc6ec3CXY1JNDIKUw8Mp8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oviC+T9+V44Hr3NMX2CF6YR3B+kK/vNRvI7dIeX2idfzUIPKEk4q3ZNHwDKxPZ2dQ pJujiLnoPisTYssWzVmNLKEtTwsWdK68AFAdO1zE7GgoTqTPjI/TlR7IBwskXkQBgl 4f+gxJJBWMt7cWGbFu49EAl737nTGPIyOK5NfRcDZXr52kWxEoDF594CHYLb+U/WYN 7uYP2tim1fI188dPT5ZzsSRCNPsXv3dMtsMApEabPPFNkcpSmb0j74/b7OTL1DHMpV VqX1yrI26SLke0nnQ/Q8XYms9jo/ZgAuYasvxWYmpEbxZ11yzteUTQu2SRIZiiUx+s r6+oBOIk1ld9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lorenzo Bianconi , "Sujuan Chen" , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 233/715] wifi: mt76: mt7996: fix fw loading timeout Date: Sun, 24 Mar 2024 18:26:52 -0400 Message-ID: <20240324223455.1342824-234-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lorenzo Bianconi [ Upstream commit 030d2e287a902b44ef45e660cf1d73af23fe7d2e ] Fix the following firmware loading error due to a wrong dma register configuration if wed is disabled. [ 8.245881] mt7996e_hif 0001:01:00.0: assign IRQ: got 128 [ 8.251308] mt7996e_hif 0001:01:00.0: enabling device (0000 -> 0002) [ 8.257674] mt7996e_hif 0001:01:00.0: enabling bus mastering [ 8.263488] mt7996e 0000:01:00.0: assign IRQ: got 126 [ 8.268537] mt7996e 0000:01:00.0: enabling device (0000 -> 0002) [ 8.274551] mt7996e 0000:01:00.0: enabling bus mastering [ 28.648773] mt7996e 0000:01:00.0: Message 00000010 (seq 1) timeout [ 28.654959] mt7996e 0000:01:00.0: Failed to get patch semaphore [ 29.661033] mt7996e: probe of 0000:01:00.0 failed with error -11 Suggested-by: "Sujuan Chen" Fixes: 4920a3a1285f ("wifi: mt76: mt7996: set DMA mask to 36 bits for board= s with more than 4GB of RAM") Signed-off-by: Lorenzo Bianconi Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt7996/dma.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/dma.c b/drivers/net/= wireless/mediatek/mt76/mt7996/dma.c index 483ad81b6eec6..fe37110e66875 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/dma.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/dma.c @@ -237,7 +237,8 @@ void mt7996_dma_start(struct mt7996_dev *dev, bool rese= t, bool wed_reset) MT_WFDMA0_GLO_CFG_TX_DMA_EN | MT_WFDMA0_GLO_CFG_RX_DMA_EN | MT_WFDMA0_GLO_CFG_OMIT_TX_INFO | - MT_WFDMA0_GLO_CFG_OMIT_RX_INFO_PFET2); + MT_WFDMA0_GLO_CFG_OMIT_RX_INFO_PFET2 | + MT_WFDMA0_GLO_CFG_EXT_EN); =20 if (dev->hif2) mt76_set(dev, MT_WFDMA0_GLO_CFG + hif1_ofs, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C215715AACA; Sun, 24 Mar 2024 22:38:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319928; cv=none; b=OzjQURk3Zsjy7LQkdSE8OyYy3xMCaiRxHW76Jmmdd+DejJps52GNHlqd7KdU/o4CJfAmh+8PK+2cW0vfZO1NFzQKfwWycNt7tINV4o7NYH3y2q79x9krHybzMplbR/c1LmFAGGQ/XxZuPHRRsTXKoCwHaR5JvXqvPOIhmJ/SuFU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319928; c=relaxed/simple; bh=RNYsYuQKgUBgQGFFaVdlUzbMpqamsaKv3m/Dft4PQXs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=P9+IKDv4m8K3vE/gLjVc/sFQQBRm3Ly3B1h4eJzkX53f/U6SI2r+jYPgTrWZNf6SUNwNMrFqf2vQrrbBm6TkrpRbBoAAUPCBY5xKh7bHfMS5teqSJKy08azkravzsbJ8Jo99zFLQkXzCJREsrad4opeVBdxj6bZoi6V/KdXXeeo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=l+zoR5dS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="l+zoR5dS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 048D8C433A6; Sun, 24 Mar 2024 22:38:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319928; bh=RNYsYuQKgUBgQGFFaVdlUzbMpqamsaKv3m/Dft4PQXs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=l+zoR5dSzIkKJT5LlqBkU2+DhpD2Xu14mhADozLGipDe9zdoXPbMirFJJnLJ5rhtG mIuPvfLQzYccMRCll07HAKnyKlwkWzJ8y4aPqtJuREu6+EB7uM+WEAmlHGJxwPnutg DIKI0rc7aMBa+rkJ0oHb1HjD4FbnRhLFyJksoItFHKvllf1hg/GHeOtbjcvWEMRiRZ U6xlyni1Jqkytf+wypFTnBdTaJYDSIh6uJMto2yL39OF6feuTNexzqZpwgh9mwDNiQ 8X2/ZMZkLlZrfItcUSREdX3g6f97cxxJW8sGHN9qwOcOSF50FqQ1wUfWyWH5FIQCul 0FII9aBb4rB7Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Yen Hsieh , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 234/715] wifi: mt76: mt7925: fix connect to 80211b mode fail in 2Ghz band Date: Sun, 24 Mar 2024 18:26:53 -0400 Message-ID: <20240324223455.1342824-235-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Yen Hsieh [ Upstream commit 479146078a21ff2015cdd4e0467cba0559911915 ] Driver should setting correct phy mode to firmware when in legacy mode. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt= 7925 chips") Signed-off-by: Ming Yen Hsieh Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/= wireless/mediatek/mt76/mt7925/mcu.c index c5fd7116929b7..1fc9ecb96bc43 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c @@ -1460,12 +1460,10 @@ mt7925_mcu_sta_phy_tlv(struct sk_buff *skb, struct tlv *tlv; u8 af =3D 0, mm =3D 0; =20 - if (!sta->deflink.ht_cap.ht_supported && !sta->deflink.he_6ghz_capa.capa) - return; - tlv =3D mt76_connac_mcu_add_tlv(skb, STA_REC_PHY, sizeof(*phy)); phy =3D (struct sta_rec_phy *)tlv; phy->phy_type =3D mt76_connac_get_phy_mode_v2(mvif->phy->mt76, vif, chand= ef->chan->band, sta); + phy->basic_rate =3D cpu_to_le16((u16)vif->bss_conf.basic_rates); if (sta->deflink.ht_cap.ht_supported) { af =3D sta->deflink.ht_cap.ampdu_factor; mm =3D sta->deflink.ht_cap.ampdu_density; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CD03215B997; Sun, 24 Mar 2024 22:38:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319929; cv=none; b=QP7U9Ns/18wiZLzVyW8Kuo1NovEnrV+S8RvNMjFYmY801L/feWZVFHia/usNexF89xAJUYhnLPCdnFSfu+qQUuKQqhL9pZVrAOwRFhbi4sAXob0V3iLsrCg8cR7VAvvcrzPPlFPbSfXpfeWmx4xqy7GZzuHn3Wcq9pYpxYYPWqg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319929; c=relaxed/simple; bh=n/QDKm2Is9NtqPda8nZ0fr078Cx7AGlR/QVlfMhzCj4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hqp3a8noVwMuhv/ynAYbex4pdCERXz0hc1CgqRDsN2koxEADlPoBFNySYi/ldF+3MLA5JkbhlKoFS9objB6KQU/6m7TLbucM31zGL/ZsnYOa41hC+F43sfrLdxp08EVxF2TT65N/0kgxXBu5uUzpFOiiDhqDGDs79rd5oRvenbY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=O2GDAEI7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="O2GDAEI7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7BE0C43390; Sun, 24 Mar 2024 22:38:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319929; bh=n/QDKm2Is9NtqPda8nZ0fr078Cx7AGlR/QVlfMhzCj4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=O2GDAEI7lDpIO4gdItRrM9+3KsvtfQwhZAic+U5DqmTpDIZKnrNXl3b7CKnk1094e ajsF+XfrCiKz+hGbLvFB793vvY2R0VfVlJUC+PM9AET2kJz9Ba3aO3Yc2slqvSzdIO B4Pg01xzxh+XWstTSgUOf3a0i72tEE+VyAEBuUBxrkNxfvDZrdONfL0pnMXyxaI+wR lChIX5mHp1G/YjrMw+HduaE85LNO6t2EQMXgYvzGGl5YtMDE3uolB1wMgpUfdGucjf Yk+iFjf/AVGz27+iHN23UCBhqutrthfClpVsRyNLS2BPzQYSEJ1SqidWN4JAyAtc5l XR0r5PRjSJV/A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "rong.yan" , Ming Yen Hsieh , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 235/715] wifi: mt76: mt7925: fix SAP no beacon issue in 5Ghz and 6Ghz band Date: Sun, 24 Mar 2024 18:26:54 -0400 Message-ID: <20240324223455.1342824-236-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "rong.yan" [ Upstream commit 243cecc857735344473ea33a713cd5c2ec1fe347 ] Driver should configure basic rate and phy mode for SAP mode. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt= 7925 chips") Signed-off-by: rong.yan Signed-off-by: Ming Yen Hsieh Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../net/wireless/mediatek/mt76/mt76_connac_mcu.h | 3 +++ drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 13 ++++++++++--- drivers/net/wireless/mediatek/mt76/mt7925/mcu.h | 3 ++- 3 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.h b/drivers= /net/wireless/mediatek/mt76/mt76_connac_mcu.h index ae6d0179727df..db96ddbeb9e70 100644 --- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.h +++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.h @@ -935,6 +935,9 @@ enum { PHY_TYPE_INDEX_NUM }; =20 +#define HR_DSSS_ERP_BASIC_RATE GENMASK(3, 0) +#define OFDM_BASIC_RATE (BIT(6) | BIT(8) | BIT(10)) + #define PHY_TYPE_BIT_HR_DSSS BIT(PHY_TYPE_HR_DSSS_INDEX) #define PHY_TYPE_BIT_ERP BIT(PHY_TYPE_ERP_INDEX) #define PHY_TYPE_BIT_OFDM BIT(PHY_TYPE_OFDM_INDEX) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/= wireless/mediatek/mt76/mt7925/mcu.c index 1fc9ecb96bc43..9a8db9b1a4f2b 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c @@ -2047,9 +2047,9 @@ mt7925_mcu_bss_basic_tlv(struct sk_buff *skb, struct cfg80211_chan_def *chandef =3D ctx ? &ctx->def : &phy->chandef; enum nl80211_band band =3D chandef->chan->band; struct mt76_connac_bss_basic_tlv *basic_req; - u8 idx, basic_phy; struct tlv *tlv; int conn_type; + u8 idx; =20 tlv =3D mt76_connac_mcu_add_tlv(skb, UNI_BSS_INFO_BASIC, sizeof(*basic_re= q)); basic_req =3D (struct mt76_connac_bss_basic_tlv *)tlv; @@ -2060,8 +2060,10 @@ mt7925_mcu_bss_basic_tlv(struct sk_buff *skb, =20 basic_req->phymode_ext =3D mt7925_get_phy_mode_ext(phy, vif, band, sta); =20 - basic_phy =3D mt76_connac_get_phy_mode_v2(phy, vif, band, sta); - basic_req->nonht_basic_phy =3D cpu_to_le16(basic_phy); + if (band =3D=3D NL80211_BAND_2GHZ) + basic_req->nonht_basic_phy =3D cpu_to_le16(PHY_TYPE_ERP_INDEX); + else + basic_req->nonht_basic_phy =3D cpu_to_le16(PHY_TYPE_OFDM_INDEX); =20 memcpy(basic_req->bssid, vif->bss_conf.bssid, ETH_ALEN); basic_req->phymode =3D mt76_connac_get_phy_mode(phy, vif, band, sta); @@ -2165,6 +2167,11 @@ mt7925_mcu_bss_bmc_tlv(struct sk_buff *skb, struct m= t792x_phy *phy, =20 bmc =3D (struct bss_rate_tlv *)tlv; =20 + if (band =3D=3D NL80211_BAND_2GHZ) + bmc->basic_rate =3D cpu_to_le16(HR_DSSS_ERP_BASIC_RATE); + else + bmc->basic_rate =3D cpu_to_le16(OFDM_BASIC_RATE); + bmc->short_preamble =3D (band =3D=3D NL80211_BAND_2GHZ); bmc->bc_fixed_rate =3D idx; bmc->mc_fixed_rate =3D idx; diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h b/drivers/net/= wireless/mediatek/mt76/mt7925/mcu.h index 3c41e21303b1f..0218fd2a0eb01 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h @@ -334,7 +334,8 @@ struct bss_req_hdr { struct bss_rate_tlv { __le16 tag; __le16 len; - u8 __rsv1[4]; + u8 __rsv1[2]; + __le16 basic_rate; __le16 bc_trans; __le16 mc_trans; u8 short_preamble; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C950215B112; Sun, 24 Mar 2024 22:38:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319930; cv=none; b=HhQldXkgwBeQiJnblj72qDe4LoivApr9VCJt0D6smDUBobwio7YbdZVfutZJEqA1mWWFtA2N4po1FWR6YLKBKOCvFfVuLdcsnsMrkvzOPdn6/2cckKOEJBPWcLQK41yyYqY2chD9s27sSlVNFnx1YTqfOTJW1oNlddz9/3iL4w4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319930; c=relaxed/simple; bh=7I+eM9iiHn0jw27jBGSgNtkVizxzH2JvS6oAmHe0shc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DraWe/BeCFJtLda7CgCD2ejCC6pXN64Dm0ofKKkX/w2i8cULB4RNjxWtfs+vgb3v2LUORGy+AaFf1Ay+J/nUhIxWw33jevTLlvnQzGR0530/o6/XLu4Qc6mH5n/L2y/8ZHR8NW6y2m82/rKi0QRgeq8dnVPi1//aw1b0FvYxwT8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nVzqEYzY; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nVzqEYzY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ECB12C433B1; Sun, 24 Mar 2024 22:38:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319930; bh=7I+eM9iiHn0jw27jBGSgNtkVizxzH2JvS6oAmHe0shc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nVzqEYzYkGSjFTXzE9jvNZBO//QeLndHQL3pgtCJukLSaXelFAb1EMPkQNBH0JWka uVcdHASA1JmKfsF4srUVLRuuFIoGpA9kgwhiNB5/ZvgqZ4Am1sdJxH3kpDGrgLhD0/ yjQiArigdAuL80X2Kjt2/neUWLb90LApxraT23FyQSd4Lzr14pW2tZrzGVNHZ5QciQ y0CdNMKSfGx/drkdGPzZs2/Mdy6QcM2qJRHSNZGsWWZ2X99ronqTQiMyQ+ViZrVeQO zbLT67UPI7jATgHUbSMlcZ/V6e7JOgyuZNuO8odmDGpg7OEkKIk3TuhLVYZafrkhlu rLt717eiO8EQg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hao Zhang , Ming Yen Hsieh , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 236/715] wifi: mt76: mt7925: fix mcu query command fail Date: Sun, 24 Mar 2024 18:26:55 -0400 Message-ID: <20240324223455.1342824-237-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hao Zhang [ Upstream commit 2f475cb63eb304bdbb58c9b07b0547ca6c343012 ] Apply query command type properly to make the chip send the response back. Otherwise, we may see the command timeout in driver side. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt= 7925 chips") Signed-off-by: Hao Zhang Signed-off-by: Ming Yen Hsieh Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt7925/mcu.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/= wireless/mediatek/mt76/mt7925/mcu.c index 9a8db9b1a4f2b..4811fccbe30e8 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c @@ -2850,12 +2850,16 @@ int mt7925_mcu_fill_message(struct mt76_dev *mdev, = struct sk_buff *skb, if (cmd & __MCU_CMD_FIELD_UNI) { uni_txd =3D (struct mt76_connac2_mcu_uni_txd *)txd; uni_txd->len =3D cpu_to_le16(skb->len - sizeof(uni_txd->txd)); - uni_txd->option =3D MCU_CMD_UNI_EXT_ACK; uni_txd->cid =3D cpu_to_le16(mcu_cmd); uni_txd->s2d_index =3D MCU_S2D_H2N; uni_txd->pkt_type =3D MCU_PKT_ID; uni_txd->seq =3D seq; =20 + if (cmd & __MCU_CMD_FIELD_QUERY) + uni_txd->option =3D MCU_CMD_UNI_QUERY_ACK; + else + uni_txd->option =3D MCU_CMD_UNI_EXT_ACK; + goto exit; } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B5FCD15CD79; Sun, 24 Mar 2024 22:38:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319931; cv=none; b=KgOCWX3CmcO81535LbZFf2v84c4nQb3NpQfPrm0hQcipPEHd17HpSQF9+NkIBu2jKWOpQWSNnOZSNnxAoIOiRYmAXg2DgcqFOl2TluYIKTx+6yuSLXZr1UXmhS/bc7TrCMNNvphBJWJd1pYU6yiVFddHLLHQBxap9fmKI9w3Q0Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319931; c=relaxed/simple; bh=UeK/A54gDnmHHZB4cJGUlqGjX029xfIIdbAYLn/yJ6M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cv4O6lBWQSxcv4tpFn4pfkgkQ8tYQDdn48B4vcn18ujEtdDAFl2CDAG/ZmQptTk5t4vuBhy/o47ZksetT250BKWlRrGk4S224U5+7Olj+HqHRWBi8uwwer4v9dAHSX2XHBue3tnEQwraMs5L+O0uauDtI91pVGMIpKk3zLATwxg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jv2BgYB1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jv2BgYB1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F130DC43390; Sun, 24 Mar 2024 22:38:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319931; bh=UeK/A54gDnmHHZB4cJGUlqGjX029xfIIdbAYLn/yJ6M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jv2BgYB1hALUG18UketgwSCyJsQDuJCULnV1EW2M5buX+KjNiQdGnP8K4S7UTegdr Pkd1RCuqgEH2nbSZdYS0XGbCaFdZp50jr+0ofF0QP2AHnjZK0zEOQ8IPwtSbWq6Jft ZJ1M4nWXUVVrxK9l7F7ecZhzvzsAKXEaXwnPt1IRHKyzERpFREU8oAT4g9gT5q2Fe3 yqa0H6JdO1wNXxeSjBsaQBjU+RWoyc5sjTdkgMQ5LayWcnX4p+nzV1E13Yo6HJ/5IF xy5xz+jrlRaM4UhMD39lJ1ESly+anlifiXQj09nui837JUywWAxIyL2jB2+MhlMW5Y Ks5UuCiFLUwjg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Yen Hsieh , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 237/715] wifi: mt76: mt7925: fix wmm queue mapping Date: Sun, 24 Mar 2024 18:26:56 -0400 Message-ID: <20240324223455.1342824-238-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Yen Hsieh [ Upstream commit 9d89edb576e385267f40193bd3776157101a504a ] Firmware uses access class index (ACI) for wmm parameters update, so convert mac80211 queue to ACI in mt7925_conf_tx(). Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt= 7925 chips") Signed-off-by: Ming Yen Hsieh Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../net/wireless/mediatek/mt76/mt7925/main.c | 21 ++++++++++++++++++- .../net/wireless/mediatek/mt76/mt7925/mcu.c | 2 +- 2 files changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net= /wireless/mediatek/mt76/mt7925/main.c index 125a1be3cb64c..5671e08dec654 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c @@ -1273,6 +1273,25 @@ mt7925_channel_switch_beacon(struct ieee80211_hw *hw, mt792x_mutex_release(dev); } =20 +static int +mt7925_conf_tx(struct ieee80211_hw *hw, struct ieee80211_vif *vif, + unsigned int link_id, u16 queue, + const struct ieee80211_tx_queue_params *params) +{ + struct mt792x_vif *mvif =3D (struct mt792x_vif *)vif->drv_priv; + static const u8 mq_to_aci[] =3D { + [IEEE80211_AC_VO] =3D 3, + [IEEE80211_AC_VI] =3D 2, + [IEEE80211_AC_BE] =3D 0, + [IEEE80211_AC_BK] =3D 1, + }; + + /* firmware uses access class index */ + mvif->queue_params[mq_to_aci[queue]] =3D *params; + + return 0; +} + static int mt7925_start_ap(struct ieee80211_hw *hw, struct ieee80211_vif *vif, struct ieee80211_bss_conf *link_conf) @@ -1396,7 +1415,7 @@ const struct ieee80211_ops mt7925_ops =3D { .add_interface =3D mt7925_add_interface, .remove_interface =3D mt792x_remove_interface, .config =3D mt7925_config, - .conf_tx =3D mt792x_conf_tx, + .conf_tx =3D mt7925_conf_tx, .configure_filter =3D mt7925_configure_filter, .bss_info_changed =3D mt7925_bss_info_changed, .start_ap =3D mt7925_start_ap, diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/= wireless/mediatek/mt76/mt7925/mcu.c index 4811fccbe30e8..0299045b4b833 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c @@ -895,7 +895,7 @@ int mt7925_mcu_set_tx(struct mt792x_dev *dev, struct ie= ee80211_vif *vif) =20 e =3D (struct edca *)tlv; e->set =3D WMM_PARAM_SET; - e->queue =3D ac + mvif->mt76.wmm_idx * MT76_CONNAC_MAX_WMM_SETS; + e->queue =3D ac; e->aifs =3D q->aifs; e->txop =3D cpu_to_le16(q->txop); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E280915D5BD; Sun, 24 Mar 2024 22:38:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319933; cv=none; b=brc3zbJLLFfy2CNA9IJxnkeBq3FpK8pegki5jmP8hylojOmPuEopD+HakJT9p7GeAiuU4eRUziLrQxaF9gj2p6xRq7tbELOcjsQ9ghr2dcKsNjvzYr86bzsb/wzK2wlgYWtmy9ik4ajD2/+5OhrBzlJ6NaG8qHo6oRlmrqeah88= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319933; c=relaxed/simple; bh=4DdoKp3nQAIVSuaDK5ih/GO5vNy63cJ29dxl7Kt/W/A=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eJjmKpwSgKHl8vuWDBNqVYo+3ZgUD3kBwNeznNosBc7O8nYvFnxnKXUQ5OsPaAhxRlNmVjAQEPAkHmuEZGijRl2yu0pQNy35lfM6ISqoBs5IKWR9y2rEixcTPJCgleESZbjBGJKwOpiS66MP8WotPdFBAHHj7oQhRw9xzeBOcTo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cB5hgmDH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cB5hgmDH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DD93DC43394; Sun, 24 Mar 2024 22:38:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319932; bh=4DdoKp3nQAIVSuaDK5ih/GO5vNy63cJ29dxl7Kt/W/A=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cB5hgmDHHfWSwuWyQOd5ii+XLTs5QZHO19fgRlPa41hMyksy5DwPbRKgkWQVrRZoP Ger9K+07dvVVkPkSrQxHi6eaqwe/4nJ71pPqB1ULOvB9f9Lhlv6q0RUGIVghiwcdRw 2SDx0GJv+leSdy8vN0plb9JOxlcXwj0YtdN4R9KhXv49NFVe4bCIZgBo8QPfo3mZue RjiSJeJGZmConCS/18Mh6AgGU6reCkE5CIO2E0F9tJuJ5QasvEKy2+9L3ZTRmiuT4R sp/PNVGNJGIOs6Y30GDT4ftVtWOt/ca5IGoO5FOLC+bbMr/F1ns8GiPIPH+tODPBJT qu6fHSQfLS55g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Yen Hsieh , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 238/715] wifi: mt76: mt7925: fix fw download fail Date: Sun, 24 Mar 2024 18:26:57 -0400 Message-ID: <20240324223455.1342824-239-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Yen Hsieh [ Upstream commit 6864bc734a48e90012cca8040cd0af72616666ca ] Add an address of fw region for fw download. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt= 7925 chips") Signed-off-by: Ming Yen Hsieh Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c b/drivers= /net/wireless/mediatek/mt76/mt76_connac_mcu.c index 3a20ba0d24928..ea7ffa16a4b12 100644 --- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c @@ -66,7 +66,7 @@ int mt76_connac_mcu_init_download(struct mt76_dev *dev, u= 32 addr, u32 len, =20 if ((!is_connac_v1(dev) && addr =3D=3D MCU_PATCH_ADDRESS) || (is_mt7921(dev) && addr =3D=3D 0x900000) || - (is_mt7925(dev) && addr =3D=3D 0x900000) || + (is_mt7925(dev) && (addr =3D=3D 0x900000 || addr =3D=3D 0xe0002800)) = || (is_mt7996(dev) && addr =3D=3D 0x900000) || (is_mt7992(dev) && addr =3D=3D 0x900000)) cmd =3D MCU_CMD(PATCH_START_REQ); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9471515D5C5; Sun, 24 Mar 2024 22:38:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319933; cv=none; b=k5hGt6FQ1rSrZ1rYSd55UglK2+ImucHgdtiME1IVXNC55gk9PGMwops4xIiYNMvkrQ27rXQrUuGERgjx11A31hE4yNNvcHUqrGELZiMpbSU6xhEaYcZCfU4+KyhS4C0amulW8eV5iFeKvkj79jscqcLf0/tVJ7DZHLROPWBIUwg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319933; c=relaxed/simple; bh=DR2C44Fi0XU0W7xJIVmvRT0pMyW8nb72FrIO2GwpCKY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=urux4HWlGTQjL/X8OfLvhtOBPeXR/9DDvWoP3rw/IkTzQ8r9VK6qMK187ei/JTqbt5BYO/eK4LfIFKQ4OGqWozzBMW/dyY9lTLbb4sJC+x53MXwzQIDHzhzVC4gPRx/duJEEjFEYGKio+/r+fG1FwLVDw8X7uYW5VXAmjdzNtIo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=daXBnEyx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="daXBnEyx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC735C433C7; Sun, 24 Mar 2024 22:38:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319933; bh=DR2C44Fi0XU0W7xJIVmvRT0pMyW8nb72FrIO2GwpCKY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=daXBnEyxGNSy/JgSvoXf4I3Laa/NUiUby7HwAP/pBQ8MM0jpSegvyL4HDbeD99KuJ JezjnvqQgZikD3u6V5xe+OwjLRAa6rMokqKv311X7enr/CwsDejCnR0pZUa6Ppri2V Kg1nqPOxaa447sbGAWz69oHIW9rSs8mHBJH2AE3c4hTiYlEjFNyHKlJ1tkL9rVy7uJ 4+r1JfTkb045EPRaTHGspEn6KTLDo3paRaJB/WvvuURUVmodXNRTHsWyUksR34a3i3 ugwnxfdSaeYGroQQDLpBkm9h1LYjBm+coEghKDnbpyTuklFEhBgSh0ROVTSq1GfZcd zZLl66CPj+ZQw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Yen Hsieh , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 239/715] wifi: mt76: mt7925: fix WoW failed in encrypted mode Date: Sun, 24 Mar 2024 18:26:58 -0400 Message-ID: <20240324223455.1342824-240-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Yen Hsieh [ Upstream commit 47916693ec7cd1b283ffa7554fc48ff4eec2daa1 ] When in suspend mode, WoW (Wake-on-WLAN) fails to wake the system remotely due to incorrect encryption mode settings. For the new mt7925 chipset, the old STA_REC_KEY_V2 command will send incorrect parameters to the firmware. Therefore, STA_REC_KEY_V3 has been introduced as a replacement for it. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt= 7925 chips") Signed-off-by: Ming Yen Hsieh Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../wireless/mediatek/mt76/mt76_connac_mcu.h | 1 + .../net/wireless/mediatek/mt76/mt7925/main.c | 3 +- .../net/wireless/mediatek/mt76/mt7925/mcu.c | 86 ++++++++++--------- .../net/wireless/mediatek/mt76/mt7925/mcu.h | 70 +++++++++++---- 4 files changed, 103 insertions(+), 57 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.h b/drivers= /net/wireless/mediatek/mt76/mt76_connac_mcu.h index db96ddbeb9e70..657a4d1f856b2 100644 --- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.h +++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.h @@ -808,6 +808,7 @@ enum { STA_REC_MLD =3D 0x20, STA_REC_EHT =3D 0x22, STA_REC_PN_INFO =3D 0x26, + STA_REC_KEY_V3 =3D 0x27, STA_REC_HDRT =3D 0x28, STA_REC_HDR_TRANS =3D 0x2B, STA_REC_MAX_NUM diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net= /wireless/mediatek/mt76/mt7925/main.c index 5671e08dec654..c74ba9642fc8d 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c @@ -359,6 +359,7 @@ mt7925_add_interface(struct ieee80211_hw *hw, struct ie= ee80211_vif *vif) mvif->sta.wcid.phy_idx =3D mvif->mt76.band_idx; mvif->sta.wcid.hw_key_idx =3D -1; mvif->sta.wcid.tx_info |=3D MT_WCID_TX_INFO_SET; + mvif->sta.vif =3D mvif; mt76_wcid_init(&mvif->sta.wcid); =20 mt7925_mac_wtbl_update(dev, idx, @@ -526,7 +527,7 @@ static int mt7925_set_key(struct ieee80211_hw *hw, enum= set_key_cmd cmd, if (cmd =3D=3D SET_KEY && !mvif->mt76.cipher) { struct mt792x_phy *phy =3D mt792x_hw_phy(hw); =20 - mvif->mt76.cipher =3D mt76_connac_mcu_get_cipher(key->cipher); + mvif->mt76.cipher =3D mt7925_mcu_get_cipher(key->cipher); mt7925_mcu_add_bss_info(phy, mvif->mt76.ctx, vif, sta, true); } =20 diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/= wireless/mediatek/mt76/mt7925/mcu.c index 0299045b4b833..8c3233182083f 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c @@ -921,61 +921,67 @@ mt7925_mcu_sta_key_tlv(struct mt76_wcid *wcid, struct ieee80211_key_conf *key, enum set_key_cmd cmd) { + struct mt792x_sta *msta =3D container_of(wcid, struct mt792x_sta, wcid); struct sta_rec_sec_uni *sec; + struct mt792x_vif *mvif =3D msta->vif; + struct ieee80211_sta *sta; + struct ieee80211_vif *vif; struct tlv *tlv; =20 - tlv =3D mt76_connac_mcu_add_tlv(skb, STA_REC_KEY_V2, sizeof(*sec)); + sta =3D msta =3D=3D &mvif->sta ? + NULL : + container_of((void *)msta, struct ieee80211_sta, drv_priv); + vif =3D container_of((void *)mvif, struct ieee80211_vif, drv_priv); + + tlv =3D mt76_connac_mcu_add_tlv(skb, STA_REC_KEY_V3, sizeof(*sec)); sec =3D (struct sta_rec_sec_uni *)tlv; - sec->add =3D cmd; + sec->bss_idx =3D mvif->mt76.idx; + sec->is_authenticator =3D 0; + sec->mgmt_prot =3D 0; + sec->wlan_idx =3D (u8)wcid->idx; + + if (sta) { + sec->tx_key =3D 1; + sec->key_type =3D 1; + memcpy(sec->peer_addr, sta->addr, ETH_ALEN); + } else { + memcpy(sec->peer_addr, vif->bss_conf.bssid, ETH_ALEN); + } =20 if (cmd =3D=3D SET_KEY) { - struct sec_key_uni *sec_key; u8 cipher; =20 - cipher =3D mt76_connac_mcu_get_cipher(key->cipher); - if (cipher =3D=3D MCU_CIPHER_NONE) + sec->add =3D 1; + cipher =3D mt7925_mcu_get_cipher(key->cipher); + if (cipher =3D=3D CONNAC3_CIPHER_NONE) return -EOPNOTSUPP; =20 - sec_key =3D &sec->key[0]; - sec_key->cipher_len =3D sizeof(*sec_key); - - if (cipher =3D=3D MCU_CIPHER_BIP_CMAC_128) { - sec_key->wlan_idx =3D cpu_to_le16(wcid->idx); - sec_key->cipher_id =3D MCU_CIPHER_AES_CCMP; - sec_key->key_id =3D sta_key_conf->keyidx; - sec_key->key_len =3D 16; - memcpy(sec_key->key, sta_key_conf->key, 16); - - sec_key =3D &sec->key[1]; - sec_key->wlan_idx =3D cpu_to_le16(wcid->idx); - sec_key->cipher_id =3D MCU_CIPHER_BIP_CMAC_128; - sec_key->cipher_len =3D sizeof(*sec_key); - sec_key->key_len =3D 16; - memcpy(sec_key->key, key->key, 16); - sec->n_cipher =3D 2; + if (cipher =3D=3D CONNAC3_CIPHER_BIP_CMAC_128) { + sec->cipher_id =3D CONNAC3_CIPHER_BIP_CMAC_128; + sec->key_id =3D sta_key_conf->keyidx; + sec->key_len =3D 32; + memcpy(sec->key, sta_key_conf->key, 16); + memcpy(sec->key + 16, key->key, 16); } else { - sec_key->wlan_idx =3D cpu_to_le16(wcid->idx); - sec_key->cipher_id =3D cipher; - sec_key->key_id =3D key->keyidx; - sec_key->key_len =3D key->keylen; - memcpy(sec_key->key, key->key, key->keylen); + sec->cipher_id =3D cipher; + sec->key_id =3D key->keyidx; + sec->key_len =3D key->keylen; + memcpy(sec->key, key->key, key->keylen); =20 - if (cipher =3D=3D MCU_CIPHER_TKIP) { + if (cipher =3D=3D CONNAC3_CIPHER_TKIP) { /* Rx/Tx MIC keys are swapped */ - memcpy(sec_key->key + 16, key->key + 24, 8); - memcpy(sec_key->key + 24, key->key + 16, 8); + memcpy(sec->key + 16, key->key + 24, 8); + memcpy(sec->key + 24, key->key + 16, 8); } =20 /* store key_conf for BIP batch update */ - if (cipher =3D=3D MCU_CIPHER_AES_CCMP) { + if (cipher =3D=3D CONNAC3_CIPHER_AES_CCMP) { memcpy(sta_key_conf->key, key->key, key->keylen); sta_key_conf->keyidx =3D key->keyidx; } - - sec->n_cipher =3D 1; } } else { - sec->n_cipher =3D 0; + sec->add =3D 0; } =20 return 0; @@ -2122,21 +2128,21 @@ mt7925_mcu_bss_sec_tlv(struct sk_buff *skb, struct = ieee80211_vif *vif) sec =3D (struct bss_sec_tlv *)tlv; =20 switch (mvif->cipher) { - case MCU_CIPHER_GCMP_256: - case MCU_CIPHER_GCMP: + case CONNAC3_CIPHER_GCMP_256: + case CONNAC3_CIPHER_GCMP: sec->mode =3D MODE_WPA3_SAE; sec->status =3D 8; break; - case MCU_CIPHER_AES_CCMP: + case CONNAC3_CIPHER_AES_CCMP: sec->mode =3D MODE_WPA2_PSK; sec->status =3D 6; break; - case MCU_CIPHER_TKIP: + case CONNAC3_CIPHER_TKIP: sec->mode =3D MODE_WPA2_PSK; sec->status =3D 4; break; - case MCU_CIPHER_WEP104: - case MCU_CIPHER_WEP40: + case CONNAC3_CIPHER_WEP104: + case CONNAC3_CIPHER_WEP40: sec->mode =3D MODE_SHARED; sec->status =3D 0; break; diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h b/drivers/net/= wireless/mediatek/mt76/mt7925/mcu.h index 0218fd2a0eb01..9fce054e50657 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h @@ -159,6 +159,20 @@ enum { UNI_EVENT_SCAN_DONE_NLO =3D 3, }; =20 +enum connac3_mcu_cipher_type { + CONNAC3_CIPHER_NONE =3D 0, + CONNAC3_CIPHER_WEP40 =3D 1, + CONNAC3_CIPHER_TKIP =3D 2, + CONNAC3_CIPHER_AES_CCMP =3D 4, + CONNAC3_CIPHER_WEP104 =3D 5, + CONNAC3_CIPHER_BIP_CMAC_128 =3D 6, + CONNAC3_CIPHER_WEP128 =3D 7, + CONNAC3_CIPHER_WAPI =3D 8, + CONNAC3_CIPHER_CCMP_256 =3D 10, + CONNAC3_CIPHER_GCMP =3D 11, + CONNAC3_CIPHER_GCMP_256 =3D 12, +}; + struct mt7925_mcu_scan_chinfo_event { u8 nr_chan; u8 alpha2[3]; @@ -383,25 +397,22 @@ struct sta_rec_eht { u8 _rsv2[3]; } __packed; =20 -struct sec_key_uni { - __le16 wlan_idx; - u8 mgmt_prot; - u8 cipher_id; - u8 cipher_len; - u8 key_id; - u8 key_len; - u8 need_resp; - u8 key[32]; -} __packed; - struct sta_rec_sec_uni { __le16 tag; __le16 len; u8 add; - u8 n_cipher; - u8 rsv[2]; - - struct sec_key_uni key[2]; + u8 tx_key; + u8 key_type; + u8 is_authenticator; + u8 peer_addr[6]; + u8 bss_idx; + u8 cipher_id; + u8 key_id; + u8 key_len; + u8 wlan_idx; + u8 mgmt_prot; + u8 key[32]; + u8 key_rsc[16]; } __packed; =20 struct sta_rec_hdr_trans { @@ -441,7 +452,7 @@ struct sta_rec_mld { sizeof(struct sta_rec_bfee) + \ sizeof(struct sta_rec_phy) + \ sizeof(struct sta_rec_ra) + \ - sizeof(struct sta_rec_sec) + \ + sizeof(struct sta_rec_sec_uni) + \ sizeof(struct sta_rec_ra_fixed) + \ sizeof(struct sta_rec_he_6g_capa) + \ sizeof(struct sta_rec_eht) + \ @@ -510,6 +521,33 @@ struct mt7925_wow_pattern_tlv { u8 rsv[4]; } __packed; =20 +static inline enum connac3_mcu_cipher_type +mt7925_mcu_get_cipher(int cipher) +{ + switch (cipher) { + case WLAN_CIPHER_SUITE_WEP40: + return CONNAC3_CIPHER_WEP40; + case WLAN_CIPHER_SUITE_WEP104: + return CONNAC3_CIPHER_WEP104; + case WLAN_CIPHER_SUITE_TKIP: + return CONNAC3_CIPHER_TKIP; + case WLAN_CIPHER_SUITE_AES_CMAC: + return CONNAC3_CIPHER_BIP_CMAC_128; + case WLAN_CIPHER_SUITE_CCMP: + return CONNAC3_CIPHER_AES_CCMP; + case WLAN_CIPHER_SUITE_CCMP_256: + return CONNAC3_CIPHER_CCMP_256; + case WLAN_CIPHER_SUITE_GCMP: + return CONNAC3_CIPHER_GCMP; + case WLAN_CIPHER_SUITE_GCMP_256: + return CONNAC3_CIPHER_GCMP_256; + case WLAN_CIPHER_SUITE_SMS4: + return CONNAC3_CIPHER_WAPI; + default: + return CONNAC3_CIPHER_NONE; + } +} + int mt7925_mcu_set_dbdc(struct mt76_phy *phy); int mt7925_mcu_hw_scan(struct mt76_phy *phy, struct ieee80211_vif *vif, struct ieee80211_scan_request *scan_req); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 895F915B112; Sun, 24 Mar 2024 22:38:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319934; cv=none; b=JFKvVOEXtlC+hmz8wKbYQsG298bD0sUgDjOHvjHUu2QQ4jhM5Sy+6Pnnr7qxczlgIXbx9IQHnpze4wlXCKA1mbYzX6a0s9A5Cv6FfauB68QBR4HRa0NqtMmDNA2hYq+RwOcxDQLfAfhBomzktzy2vDGrXLejbCRkT9GFw2Ic8GM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319934; c=relaxed/simple; bh=cMa/YebYRaM5db2GNXDbF6ZFaSOgx4eEKsBajtAisko=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IA6SECBV/Xc34D9RRb6d+v7aQhJkDX+VJ5l1oecWmRQk6iMENvx1LGK03ss8llVzQHhgWX7qJ4UwQmJMCrUaRLO+cS/ET96vzYU9lkLS5LTJnsorDDpKdLskGeX8gII6zydg5g3zG+cCB9PGFk3iMJIkamDmyBgPn2s6ty4P4oY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eumT5jqq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eumT5jqq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB943C433B1; Sun, 24 Mar 2024 22:38:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319934; bh=cMa/YebYRaM5db2GNXDbF6ZFaSOgx4eEKsBajtAisko=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eumT5jqqSIez5GQ/7f9NBw7pStBJDB4Qdpa7GgmEbibukICMxbXs1u6eBtddn01O8 GWp0riCXo6jk2TW2zleLXtoNj1m0iTYs4oQ2mFKj/GoWNb7Hhn3VO7StXNnLUNFF99 9WOcKsB/mKmUPVFJFQKGyoaNtxKr3r+UUuQIDIfEzDYtPwGOP1kEiklHn+x8xwQpAA f1MkM0XZI4bDpKIyT7p+ND5gt7L8LTL3dJd4MlQCtey+uimkznyqo9fS/2plbGRvrB WIpxKcqyjKNti4Lu/AkFEb9JzChCPZ4kVYknXOsGhiCPAKRKTSFWTlQBlYTD0zLULB gFfieSKbjIlFQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Yen Hsieh , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 240/715] wifi: mt76: mt7925: fix the wrong header translation config Date: Sun, 24 Mar 2024 18:26:59 -0400 Message-ID: <20240324223455.1342824-241-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Yen Hsieh [ Upstream commit d8cf7e1344727b80b4ec3dc17ca520238d55a88d ] The header translation config should set to broadcast and unicast cases correctly, not only unicast case. And also remove the cmds of wtbl (wlan table) series, because these MCU commands have already been replaced by other commands in mt7925. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt= 7925 chips") Signed-off-by: Ming Yen Hsieh Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../net/wireless/mediatek/mt76/mt7925/mcu.c | 32 +++++-------------- 1 file changed, 8 insertions(+), 24 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/= wireless/mediatek/mt76/mt7925/mcu.c index 8c3233182083f..932ecf38672c4 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c @@ -814,6 +814,7 @@ mt7925_mcu_sta_hdr_trans_tlv(struct sk_buff *skb, struct ieee80211_vif *vif, struct ieee80211_sta *sta) { + struct mt792x_vif *mvif =3D (struct mt792x_vif *)vif->drv_priv; struct sta_rec_hdr_trans *hdr_trans; struct mt76_wcid *wcid; struct tlv *tlv; @@ -827,7 +828,11 @@ mt7925_mcu_sta_hdr_trans_tlv(struct sk_buff *skb, else hdr_trans->from_ds =3D true; =20 - wcid =3D (struct mt76_wcid *)sta->drv_priv; + if (sta) + wcid =3D (struct mt76_wcid *)sta->drv_priv; + else + wcid =3D &mvif->sta.wcid; + if (!wcid) return; =20 @@ -1577,8 +1582,6 @@ mt7925_mcu_sta_cmd(struct mt76_phy *phy, { struct mt76_vif *mvif =3D (struct mt76_vif *)info->vif->drv_priv; struct mt76_dev *dev =3D phy->dev; - struct wtbl_req_hdr *wtbl_hdr; - struct tlv *sta_wtbl; struct sk_buff *skb; =20 skb =3D __mt76_connac_mcu_alloc_sta_req(dev, mvif, info->wcid, @@ -1602,30 +1605,11 @@ mt7925_mcu_sta_cmd(struct mt76_phy *phy, mt7925_mcu_sta_state_v2_tlv(phy, skb, info->sta, info->vif, info->rcpi, info->state); - mt7925_mcu_sta_hdr_trans_tlv(skb, info->vif, info->sta); mt7925_mcu_sta_mld_tlv(skb, info->vif, info->sta); } =20 - sta_wtbl =3D mt76_connac_mcu_add_tlv(skb, STA_REC_WTBL, - sizeof(struct tlv)); - - wtbl_hdr =3D mt76_connac_mcu_alloc_wtbl_req(dev, info->wcid, - WTBL_RESET_AND_SET, - sta_wtbl, &skb); - if (IS_ERR(wtbl_hdr)) - return PTR_ERR(wtbl_hdr); - - if (info->enable) { - mt76_connac_mcu_wtbl_generic_tlv(dev, skb, info->vif, - info->sta, sta_wtbl, - wtbl_hdr); - mt76_connac_mcu_wtbl_hdr_trans_tlv(skb, info->vif, info->wcid, - sta_wtbl, wtbl_hdr); - if (info->sta) - mt76_connac_mcu_wtbl_ht_tlv(dev, skb, info->sta, - sta_wtbl, wtbl_hdr, - true, true); - } + if (info->enable) + mt7925_mcu_sta_hdr_trans_tlv(skb, info->vif, info->sta); =20 return mt76_mcu_skb_send_msg(dev, skb, info->cmd, true); } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8147E15E5A4; Sun, 24 Mar 2024 22:38:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319935; cv=none; b=NQZVSs1gV2fVJ6xRqXaw344xFcstnVK4vIYKbjEpN9XfHDTSbYVOGEC72GIbr7c4/1LqICfEK7cFk9L9miqiu/vzMdNZSrWxNkJ321nIEshvoWD6yArXiNIc1TtyrGB4TjaHXvBCckvQzzyIAqKx+1po3cpHEDaO2dkGc1CF+HI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319935; c=relaxed/simple; bh=1hQ0IocJrYAHyKor1VYE7+Z3UQNw34mx7Cz6RERCIpE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hZJM0W9u72XDlEQfDoHc1Blr18k8S8DHOwz/162bWIfRyjuDhnzzQGZB6D2tkT8U/z3YSCvYSDoZn7VpzdRCX3d5xBDDNfCE3a86VWwCJ/YrnJs3GR8+b0iaxZ2X8vVbhIIpnqHooSsM/PRvqOwMObaHzIXhbODtOtex8EB93C8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ltpGnGpr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ltpGnGpr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5F3CC433C7; Sun, 24 Mar 2024 22:38:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319935; bh=1hQ0IocJrYAHyKor1VYE7+Z3UQNw34mx7Cz6RERCIpE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ltpGnGpre26xCVxp6S16DbH2GHeQynTLCArcCuBBZ+UZ1Y22T6/QXqztyh0f0GiZK 1tOwGDX767zLjoeblA3aTevOWj5WW2J3FyeUs3i85UJbIJsPxXhPNK8kiihomRdNSs 8hYT4r0yX34Awrse1H6PcYlPSBdwjD0JB/wN4eXr5KTc9Q4AFfeyF6qy4p3LxoD3Zw DXAAQBb4Dh0AgQlnrMQHbX6QPZJquwexXAO6t1Wg0sYofz0dqUXlDjkT/R2uhb1VJV fMObFXXeQCAZRPT145j0LgBEQqzflGw6IMlWe4/12sgYmWe3I9pWVGaxuTptVUKUlx 7ShmG+qgOTV6w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Quan Zhou , Ming Yen Hsieh , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 241/715] wifi: mt76: mt7925: add flow to avoid chip bt function fail Date: Sun, 24 Mar 2024 18:27:00 -0400 Message-ID: <20240324223455.1342824-242-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Quan Zhou [ Upstream commit 9300ae0cd9e8f2407b20e0e67ee3ea03dc8b06af ] A sub-process of Wifi L0.5 reset will make chip common partition enter low power, and have chance lead to Bluetooth host-to-chip command timeout, modify the software flow according to the chip's design to solve the problem. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt= 7925 chips") Signed-off-by: Quan Zhou Signed-off-by: Ming Yen Hsieh Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 2 ++ drivers/net/wireless/mediatek/mt76/mt792x_regs.h | 3 +++ 2 files changed, 5 insertions(+) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c b/drivers/net/= wireless/mediatek/mt76/mt7925/pci.c index 1fd99a8565415..74cfba7675beb 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c @@ -386,6 +386,8 @@ static int mt7925_pci_probe(struct pci_dev *pdev, =20 dev_info(mdev->dev, "ASIC revision: %04x\n", mdev->rev); =20 + mt76_rmw_field(dev, MT_HW_EMI_CTL, MT_HW_EMI_CTL_SLPPROT_EN, 1); + ret =3D mt792x_wfsys_reset(dev); if (ret) goto err_free_dev; diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h b/drivers/net= /wireless/mediatek/mt76/mt792x_regs.h index a99af23e4b564..d7f9b24cd665f 100644 --- a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h +++ b/drivers/net/wireless/mediatek/mt76/mt792x_regs.h @@ -389,6 +389,9 @@ #define MT_HW_CHIPID 0x70010200 #define MT_HW_REV 0x70010204 =20 +#define MT_HW_EMI_CTL 0x18011100 +#define MT_HW_EMI_CTL_SLPPROT_EN BIT(1) + #define MT_PCIE_MAC_BASE 0x10000 #define MT_PCIE_MAC(ofs) (MT_PCIE_MAC_BASE + (ofs)) #define MT_PCIE_MAC_INT_ENABLE MT_PCIE_MAC(0x188) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9D5C57324; Sun, 24 Mar 2024 22:38:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319936; cv=none; b=CbZCzYqqf4etak3ad6EDrkfiP7NW3YleTk5xLqPLzjiMLBZ5ES1vpWu4fA2DSgZLKnS4HUbnJiHLorEO+FxbFoB0/tee7LqCSkx2ooj5hszIn0dsyHA3JBFqOsXwDq8vd5qMtkdZPvYUN6za+Ae+0Vz009bZXmFa0ppeqlGTvqs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319936; c=relaxed/simple; bh=PkrDQnjEjY2i83EVqHK2QJp/nO8YXFzDnIBB6hMF2DY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TOgH+XVbM6L2jXGPwv7DtYwDkq8QcA/PFK2jFGnpJ9dBEs08pkzOhh5His+R+4HCqGeHM3trI11nUROs7pR9cxOcsKzw3tzvW+FkLoM0w6cmGzauc4KjadM43ALCpHmzT1ye1UfFbS62QnniruCFu6nS3l7o7F1owO23qj6kOeM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C9vAb1ga; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="C9vAb1ga" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8FC5C43390; Sun, 24 Mar 2024 22:38:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319936; bh=PkrDQnjEjY2i83EVqHK2QJp/nO8YXFzDnIBB6hMF2DY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C9vAb1gao7tm3VXnujT58rWcpbpFZLAcvNiByL+tDDPvJ5VoMLRLAsI5mAs5gmXUg pZk+U5FBaz0tHwNLVQNCeTiP4o8X1VitbUIuEbiJ9/rhBlmHyFl8EE1x70SlOjqsEu x+zz1jbeeiddqXdvs45az85rSthSxg3/e0a+YNCuovJuma8/8gLRi9Sv2P+l+NqFb+ WrrTl+1V4TEWWXPFJ5DG3Nvr1L4mSljcoaHQEAd4wZ7vK+VbGIoWmnulah+5+xnIBm 6OVxXPXEO/Vxow4i28vJ85gDRIs9Yj8WZlABOJEOacJ8etiD4UIA+vh9I2quShprYK eS0i5Wcbxfz3Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Yen Hsieh , Deren Wu , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 242/715] wifi: mt76: mt7925: add support to set ifs time by mcu command Date: Sun, 24 Mar 2024 18:27:01 -0400 Message-ID: <20240324223455.1342824-243-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Yen Hsieh [ Upstream commit 8536ef0aeae1177c4a59b043d4b1c41ddaa9df2a ] There's a race between driver and fw on some tx/rx control registers when setting ifs, which will cause accidental hw queue pause problems. Avoid this by setting ifs time with bss_info mcu command. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt= 7925 chips") Co-developed-by: Deren Wu Signed-off-by: Deren Wu Signed-off-by: Ming Yen Hsieh Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../net/wireless/mediatek/mt76/mt7925/main.c | 2 +- .../net/wireless/mediatek/mt76/mt7925/mcu.c | 33 +++++++++++++++++++ .../net/wireless/mediatek/mt76/mt7925/mcu.h | 19 +++++++++++ 3 files changed, 53 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net= /wireless/mediatek/mt76/mt7925/main.c index c74ba9642fc8d..6179798a8845a 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c @@ -711,7 +711,7 @@ static void mt7925_bss_info_changed(struct ieee80211_hw= *hw, =20 if (slottime !=3D phy->slottime) { phy->slottime =3D slottime; - mt792x_mac_set_timeing(phy); + mt7925_mcu_set_timing(phy, vif); } } =20 diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/= wireless/mediatek/mt76/mt7925/mcu.c index 932ecf38672c4..e1dd89a7a79ca 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c @@ -2244,6 +2244,38 @@ mt7925_mcu_bss_color_tlv(struct sk_buff *skb, struct= ieee80211_vif *vif, vif->bss_conf.he_bss_color.color : 0; } =20 +static void +mt7925_mcu_bss_ifs_tlv(struct sk_buff *skb, struct ieee80211_vif *vif) +{ + struct mt792x_vif *mvif =3D (struct mt792x_vif *)vif->drv_priv; + struct mt792x_phy *phy =3D mvif->phy; + struct bss_ifs_time_tlv *ifs_time; + struct tlv *tlv; + + tlv =3D mt76_connac_mcu_add_tlv(skb, UNI_BSS_INFO_IFS_TIME, sizeof(*ifs_t= ime)); + ifs_time =3D (struct bss_ifs_time_tlv *)tlv; + ifs_time->slot_valid =3D true; + ifs_time->slot_time =3D cpu_to_le16(phy->slottime); +} + +int mt7925_mcu_set_timing(struct mt792x_phy *phy, + struct ieee80211_vif *vif) +{ + struct mt792x_vif *mvif =3D (struct mt792x_vif *)vif->drv_priv; + struct mt792x_dev *dev =3D phy->dev; + struct sk_buff *skb; + + skb =3D __mt7925_mcu_alloc_bss_req(&dev->mt76, &mvif->mt76, + MT7925_BSS_UPDATE_MAX_SIZE); + if (IS_ERR(skb)) + return PTR_ERR(skb); + + mt7925_mcu_bss_ifs_tlv(skb, vif); + + return mt76_mcu_skb_send_msg(&dev->mt76, skb, + MCU_UNI_CMD(BSS_INFO_UPDATE), true); +} + int mt7925_mcu_add_bss_info(struct mt792x_phy *phy, struct ieee80211_chanctx_conf *ctx, struct ieee80211_vif *vif, @@ -2268,6 +2300,7 @@ int mt7925_mcu_add_bss_info(struct mt792x_phy *phy, mt7925_mcu_bss_bmc_tlv(skb, phy, ctx, vif, sta); mt7925_mcu_bss_qos_tlv(skb, vif); mt7925_mcu_bss_mld_tlv(skb, vif, sta); + mt7925_mcu_bss_ifs_tlv(skb, vif); =20 if (vif->bss_conf.he_support) { mt7925_mcu_bss_he_tlv(skb, vif, phy); diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h b/drivers/net/= wireless/mediatek/mt76/mt7925/mcu.h index 9fce054e50657..2cf39276118eb 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h @@ -440,6 +440,22 @@ struct sta_rec_mld { } __packed link[2]; } __packed; =20 +struct bss_ifs_time_tlv { + __le16 tag; + __le16 len; + u8 slot_valid; + u8 sifs_valid; + u8 rifs_valid; + u8 eifs_valid; + __le16 slot_time; + __le16 sifs_time; + __le16 rifs_time; + __le16 eifs_time; + u8 eifs_cck_valid; + u8 rsv; + __le16 eifs_cck_time; +} __packed; + #define MT7925_STA_UPDATE_MAX_SIZE (sizeof(struct sta_req_hdr) + \ sizeof(struct sta_rec_basic) + \ sizeof(struct sta_rec_bf) + \ @@ -467,6 +483,7 @@ struct sta_rec_mld { sizeof(struct bss_mld_tlv) + \ sizeof(struct bss_info_uni_he) + \ sizeof(struct bss_info_uni_bss_color) + \ + sizeof(struct bss_ifs_time_tlv) + \ sizeof(struct tlv)) =20 #define MT_CONNAC3_SKU_POWER_LIMIT 449 @@ -564,6 +581,8 @@ int mt7925_mcu_add_bss_info(struct mt792x_phy *phy, struct ieee80211_vif *vif, struct ieee80211_sta *sta, int enable); +int mt7925_mcu_set_timing(struct mt792x_phy *phy, + struct ieee80211_vif *vif); int mt7925_mcu_set_deep_sleep(struct mt792x_dev *dev, bool enable); int mt7925_mcu_set_channel_domain(struct mt76_phy *phy); int mt7925_mcu_set_radio_en(struct mt792x_phy *phy, bool enable); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D223315E5B7; Sun, 24 Mar 2024 22:38:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319937; cv=none; b=ZPJjB/eIQiAU73PlmhkJYAdX1xSrWLnl8PmTSwXr4HlY9sVY8pUdJngrO2S7CiTRQBlKY/T13xkkZnL9QyFgpxfm85QFKBY/M9phPMcr0MfQxxiPTX//nJpBUuDRsvh3csHY7NaQXPfS4MQngLe2k/anKcs3f4Tsea+d5dmqwCM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319937; c=relaxed/simple; bh=v/fESFmUSW40UM2hj5S3JboOxncvfxWDP/34gyFSfCA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dlKG2MHbH0+TEKOLlr1NaBVByqHd4qJtv0R7mjdYAkdbHBPc0Y5YUDJhf9hQVImIwOei/JGAZrbRNNln026FuXxWhiVoChenLhux0cf4vFiVPmXYVxPckoRT9bUESL5BWrV3JBdlaRDJBCwilapSiNelDgaki9qEJsrxdCZnxyY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=fail (0-bit key) header.d=kernel.org header.i=@kernel.org header.b=pJp7UYrW reason="key not found in DNS"; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=kernel.org header.i=@kernel.org header.b="pJp7UYrW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A91B8C43394; Sun, 24 Mar 2024 22:38:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319937; bh=v/fESFmUSW40UM2hj5S3JboOxncvfxWDP/34gyFSfCA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pJp7UYrWfP7RyejAgJTBBCnGQoPcbdNTcPjjBf9P0czhjUh6P5XF8PO/uVPrRFF2L lVbhxJM50nfvQHlxY4nbYmJDJE6h3jj6pvko4XG6sBpUV/u/ZwkNunxSQAcemMF4uB jNoYGBxmhK+D/pLMk7SRxn987fDmvvOGafLoWe9pwtEDoW6Y9FpOFLlg6GaP2isQQM Ql+qKoNH407GAPhFIgPiREc3LDxdRw2a/xfrPdRemoD7TN9pMhdiHQg5Qqt5MxzWRd ut0N8NZ9WBvWPA+Sw9Q+SJXhywLgomkdMv8AYgHuGywYszojm9ytp0SxbFWQ0pwxdv J21ezQeCFVg6Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Deren Wu , Ming Yen Hsieh , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 243/715] wifi: mt76: mt7925: update PCIe DMA settings Date: Sun, 24 Mar 2024 18:27:02 -0400 Message-ID: <20240324223455.1342824-244-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Deren Wu [ Upstream commit 0844947ccf64ea45edf6619ae2ba6dd9098b3308 ] Fix the wrong WFDMA settings to improve TX performance. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt= 7925 chips") Signed-off-by: Deren Wu Signed-off-by: Ming Yen Hsieh Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt792x_dma.c | 13 ++++++++++--- drivers/net/wireless/mediatek/mt76/mt792x_regs.h | 5 +++++ 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_dma.c b/drivers/net/= wireless/mediatek/mt76/mt792x_dma.c index 488326ce5ed4d..8fa36b59e738d 100644 --- a/drivers/net/wireless/mediatek/mt76/mt792x_dma.c +++ b/drivers/net/wireless/mediatek/mt76/mt792x_dma.c @@ -123,14 +123,13 @@ static void mt792x_dma_prefetch(struct mt792x_dev *de= v) =20 int mt792x_dma_enable(struct mt792x_dev *dev) { - if (is_mt7925(&dev->mt76)) - mt76_rmw(dev, MT_UWFDMA0_GLO_CFG_EXT1, BIT(28), BIT(28)); - /* configure perfetch settings */ mt792x_dma_prefetch(dev); =20 /* reset dma idx */ mt76_wr(dev, MT_WFDMA0_RST_DTX_PTR, ~0); + if (is_mt7925(&dev->mt76)) + mt76_wr(dev, MT_WFDMA0_RST_DRX_PTR, ~0); =20 /* configure delay interrupt */ mt76_wr(dev, MT_WFDMA0_PRI_DLY_INT_CFG0, 0); @@ -140,12 +139,20 @@ int mt792x_dma_enable(struct mt792x_dev *dev) MT_WFDMA0_GLO_CFG_FIFO_LITTLE_ENDIAN | MT_WFDMA0_GLO_CFG_CLK_GAT_DIS | MT_WFDMA0_GLO_CFG_OMIT_TX_INFO | + FIELD_PREP(MT_WFDMA0_GLO_CFG_DMA_SIZE, 3) | + MT_WFDMA0_GLO_CFG_FIFO_DIS_CHECK | + MT_WFDMA0_GLO_CFG_RX_WB_DDONE | MT_WFDMA0_GLO_CFG_CSR_DISP_BASE_PTR_CHAIN_EN | MT_WFDMA0_GLO_CFG_OMIT_RX_INFO_PFET2); =20 mt76_set(dev, MT_WFDMA0_GLO_CFG, MT_WFDMA0_GLO_CFG_TX_DMA_EN | MT_WFDMA0_GLO_CFG_RX_DMA_EN); =20 + if (is_mt7925(&dev->mt76)) { + mt76_rmw(dev, MT_UWFDMA0_GLO_CFG_EXT1, BIT(28), BIT(28)); + mt76_set(dev, MT_WFDMA0_INT_RX_PRI, 0x0F00); + mt76_set(dev, MT_WFDMA0_INT_TX_PRI, 0x7F00); + } mt76_set(dev, MT_WFDMA_DUMMY_CR, MT_WFDMA_NEED_REINIT); =20 /* enable interrupts for TX/RX rings */ diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h b/drivers/net= /wireless/mediatek/mt76/mt792x_regs.h index d7f9b24cd665f..458cfd0260b13 100644 --- a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h +++ b/drivers/net/wireless/mediatek/mt76/mt792x_regs.h @@ -292,9 +292,12 @@ #define MT_WFDMA0_GLO_CFG_TX_DMA_BUSY BIT(1) #define MT_WFDMA0_GLO_CFG_RX_DMA_EN BIT(2) #define MT_WFDMA0_GLO_CFG_RX_DMA_BUSY BIT(3) +#define MT_WFDMA0_GLO_CFG_DMA_SIZE GENMASK(5, 4) #define MT_WFDMA0_GLO_CFG_TX_WB_DDONE BIT(6) #define MT_WFDMA0_GLO_CFG_FW_DWLD_BYPASS_DMASHDL BIT(9) +#define MT_WFDMA0_GLO_CFG_FIFO_DIS_CHECK BIT(11) #define MT_WFDMA0_GLO_CFG_FIFO_LITTLE_ENDIAN BIT(12) +#define MT_WFDMA0_GLO_CFG_RX_WB_DDONE BIT(13) #define MT_WFDMA0_GLO_CFG_CSR_DISP_BASE_PTR_CHAIN_EN BIT(15) #define MT_WFDMA0_GLO_CFG_OMIT_RX_INFO_PFET2 BIT(21) #define MT_WFDMA0_GLO_CFG_OMIT_RX_INFO BIT(27) @@ -322,6 +325,8 @@ =20 #define MT_WFDMA0_RST_DTX_PTR MT_WFDMA0(0x20c) #define MT_WFDMA0_RST_DRX_PTR MT_WFDMA0(0x280) +#define MT_WFDMA0_INT_RX_PRI MT_WFDMA0(0x298) +#define MT_WFDMA0_INT_TX_PRI MT_WFDMA0(0x29c) #define MT_WFDMA0_GLO_CFG_EXT0 MT_WFDMA0(0x2b0) #define MT_WFDMA0_CSR_TX_DMASHDL_ENABLE BIT(6) #define MT_WFDMA0_PRI_DLY_INT_CFG0 MT_WFDMA0(0x2f0) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 909A8160860; Sun, 24 Mar 2024 22:38:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319938; cv=none; b=OvixyPlYMtxThPnJQ7g4/AjzbSdXwNvKvdkmQ8I2s5JRtHFw7+knFHRVFFXgujLqCLy1iRR29oomxOkTdKwJakL7U57lcLvD+f7YEP0WuFcBgJrAlQ5E2XD9MeDSY9FY6S2PN2PERiJAzGAhY7w19X4z/gFOnDvq/xD9FTrHU6I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319938; c=relaxed/simple; bh=jmipEGN2Qr/7Qt+ZoRYcn6UJow5481zKKbSe0sa1dF0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=scjDqDHn30qq7NhFYvIkqBHdhBqZtlmC/soc9jAiZQMBAHfdD/zbNlAV42egTPrQK+ZFDb4+luisdcWAf7xcOF/EN4/IlSZfrJm0z013URsBktUsvWIsX36oxDezRSKsQ3asdVKdcP/I42pSVM8t4EFKQ4x9iRWLDzMdSw7jPtQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jLnh3kk8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jLnh3kk8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9AC5C433A6; Sun, 24 Mar 2024 22:38:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319938; bh=jmipEGN2Qr/7Qt+ZoRYcn6UJow5481zKKbSe0sa1dF0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jLnh3kk8Ue9pfJTk3gQHWld4JY1w0vsbFiP6Lgy6GBDj/5Oh07dKsLS0OOss2WHdk xgrXjl6chZIGIrxRJKIh/osRzJWwjKttOEJIloe2TQa66F5aowB41hLd7avNo+0ILH iFL2kJFfbaRbMd5ptQLlyX4BEJYyFBP9cmxJaK8ibuE3ALjE6gFM2edCJDuYJlfXTJ G9uCLqvxKYbq98U8zVIUShtmyArb5kW0jLVigPY1xhHyBQX5N3j8u0Z19dVNfVN7Z/ 5GLWouHJHXe0wegDveUR7EzX4op8BbBdPoRhFTVMtHGu7r/SxwiP0Zq3pk5XdAmamI 8OkSTWe09vtfQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Chiu , Shayne Chen , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 244/715] wifi: mt76: mt7996: check txs format before getting skb by pid Date: Sun, 24 Mar 2024 18:27:03 -0400 Message-ID: <20240324223455.1342824-245-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Chiu [ Upstream commit 9c9c25f1dcdd98fffda564d2073f26219c84a2c3 ] The PPDU TXS does not include the error bit so it cannot use to report status to mac80211. This patch fixes issue that STA wrongly detects if AP is still alive. Fixes: 2569ea5326e2 ("wifi: mt76: mt7996: enable PPDU-TxS to host") Signed-off-by: Peter Chiu Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../net/wireless/mediatek/mt76/mt7996/mac.c | 23 +++++++++++-------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c b/drivers/net/= wireless/mediatek/mt76/mt7996/mac.c index 53258488d49f3..a8414fbb07c82 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c @@ -1188,25 +1188,28 @@ mt7996_mac_add_txs_skb(struct mt7996_dev *dev, stru= ct mt76_wcid *wcid, struct ieee80211_tx_info *info; struct sk_buff_head list; struct rate_info rate =3D {}; - struct sk_buff *skb; + struct sk_buff *skb =3D NULL; bool cck =3D false; u32 txrate, txs, mode, stbc; =20 txs =3D le32_to_cpu(txs_data[0]); =20 mt76_tx_status_lock(mdev, &list); - skb =3D mt76_tx_status_skb_get(mdev, wcid, pid, &list); =20 - if (skb) { - info =3D IEEE80211_SKB_CB(skb); - if (!(txs & MT_TXS0_ACK_ERROR_MASK)) - info->flags |=3D IEEE80211_TX_STAT_ACK; + /* only report MPDU TXS */ + if (le32_get_bits(txs_data[0], MT_TXS0_TXS_FORMAT) =3D=3D 0) { + skb =3D mt76_tx_status_skb_get(mdev, wcid, pid, &list); + if (skb) { + info =3D IEEE80211_SKB_CB(skb); + if (!(txs & MT_TXS0_ACK_ERROR_MASK)) + info->flags |=3D IEEE80211_TX_STAT_ACK; =20 - info->status.ampdu_len =3D 1; - info->status.ampdu_ack_len =3D - !!(info->flags & IEEE80211_TX_STAT_ACK); + info->status.ampdu_len =3D 1; + info->status.ampdu_ack_len =3D + !!(info->flags & IEEE80211_TX_STAT_ACK); =20 - info->status.rates[0].idx =3D -1; + info->status.rates[0].idx =3D -1; + } } =20 if (mtk_wed_device_active(&dev->mt76.mmio.wed) && wcid->sta) { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 853AF161B56; Sun, 24 Mar 2024 22:38:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319939; cv=none; b=KCJAssfF1odxtxmY0H6NDO+WfQmxqKpCu6LnuDvNGtHMA4oeKr1dViK7QEGUyF6EXydtH/o1wppFb6oCjp/nywYCOYpyEJLsecnFauQO4/0sRZ73rFjTa70es4UDaKsvmGyj8+iCxf78vhwQaxs8xS8DrfCfEmU+4cCDA5sdNwc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319939; c=relaxed/simple; bh=z2iUOQCdt0N2rh0v6Bua7z3hbJ7d+N7jjIvJfVpe/jY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TYn2gbWTF/ai005VX+fbTO+CwekO+SkCVtKXTzoeUcUN717bzao4iZy0DuafQmvdb0ymbWnV48dbgQMIvY5ExDMPQvasK0YphwrP1783pXNOyq2S6soZjFwVCFxejpnvffvgZiqGv4JGR4peVW/3mXrIfrTNgNEqCO+tXRpVRVg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V8rKjwBl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V8rKjwBl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AAC7CC43394; Sun, 24 Mar 2024 22:38:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319939; bh=z2iUOQCdt0N2rh0v6Bua7z3hbJ7d+N7jjIvJfVpe/jY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V8rKjwBlzxUFR1lVNLldeAGOX8ZqV4JjhTRWNUqVttk4TfWh/v+gA1KBjyWXMt0Fo mdEDsOyXc/Y72aZE86rSeZs+AxsfB6+MGRw3iuGvHrR2OskTrqm+6opJhLAoFhcvZ9 vuHABEBhsT7P8RCsl4fBuzYpSgkA0r8G4UYivqGiJ4KsFayOvAHEUFYmrxE5842C/U lXStJDe512r7h2l57a19JhwWaNN9fddMRWerPf+8PFatyw0A7k0O7eEl64Iw2c6/Qg bZA7ADZ0H+MrNPQYMbUYELLRhMkupnluW4SO9HY+8jkbDtqvTuhsxbnpF0AxDAfavz 0Sa52Cz3k223A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Chiu , Shayne Chen , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 245/715] wifi: mt76: mt7996: fix TWT issues Date: Sun, 24 Mar 2024 18:27:04 -0400 Message-ID: <20240324223455.1342824-246-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Chiu [ Upstream commit 5c832c228f6a7ba7e900c5296ce0fb3844bafec5 ] This patch fixes the following TWT issues: - Change table_mask to u16 to support up to 16 TWT stations - Reject TWT flows for duplicated establishment - Fix possible unaligned pointer - Remove unsupported TWT_CONTROL_WAKE_DUR_UNIT flag - The minimum TWT duration supported by mt7996 chipsets is 64. Reply with TWT_SETUP_CMD_DICTATE if the min_twt_dur is smaller than 64 Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (= 802.11be) devices") Signed-off-by: Peter Chiu Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../net/wireless/mediatek/mt76/mt7996/mac.c | 53 ++++++++++++++++--- .../wireless/mediatek/mt76/mt7996/mt7996.h | 3 +- 2 files changed, 47 insertions(+), 9 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c b/drivers/net/= wireless/mediatek/mt76/mt7996/mac.c index a8414fbb07c82..63d34844c1223 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/mac.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mac.c @@ -2530,6 +2530,34 @@ static int mt7996_mac_check_twt_req(struct ieee80211= _twt_setup *twt) return 0; } =20 +static bool +mt7996_mac_twt_param_equal(struct mt7996_sta *msta, + struct ieee80211_twt_params *twt_agrt) +{ + u16 type =3D le16_to_cpu(twt_agrt->req_type); + u8 exp; + int i; + + exp =3D FIELD_GET(IEEE80211_TWT_REQTYPE_WAKE_INT_EXP, type); + for (i =3D 0; i < MT7996_MAX_STA_TWT_AGRT; i++) { + struct mt7996_twt_flow *f; + + if (!(msta->twt.flowid_mask & BIT(i))) + continue; + + f =3D &msta->twt.flow[i]; + if (f->duration =3D=3D twt_agrt->min_twt_dur && + f->mantissa =3D=3D twt_agrt->mantissa && + f->exp =3D=3D exp && + f->protection =3D=3D !!(type & IEEE80211_TWT_REQTYPE_PROTECTION) && + f->flowtype =3D=3D !!(type & IEEE80211_TWT_REQTYPE_FLOWTYPE) && + f->trigger =3D=3D !!(type & IEEE80211_TWT_REQTYPE_TRIGGER)) + return true; + } + + return false; +} + void mt7996_mac_add_twt_setup(struct ieee80211_hw *hw, struct ieee80211_sta *sta, struct ieee80211_twt_setup *twt) @@ -2541,8 +2569,7 @@ void mt7996_mac_add_twt_setup(struct ieee80211_hw *hw, enum ieee80211_twt_setup_cmd sta_setup_cmd; struct mt7996_dev *dev =3D mt7996_hw_dev(hw); struct mt7996_twt_flow *flow; - int flowid, table_id; - u8 exp; + u8 flowid, table_id, exp; =20 if (mt7996_mac_check_twt_req(twt)) goto out; @@ -2555,9 +2582,19 @@ void mt7996_mac_add_twt_setup(struct ieee80211_hw *h= w, if (hweight8(msta->twt.flowid_mask) =3D=3D ARRAY_SIZE(msta->twt.flow)) goto unlock; =20 + if (twt_agrt->min_twt_dur < MT7996_MIN_TWT_DUR) { + setup_cmd =3D TWT_SETUP_CMD_DICTATE; + twt_agrt->min_twt_dur =3D MT7996_MIN_TWT_DUR; + goto unlock; + } + + if (mt7996_mac_twt_param_equal(msta, twt_agrt)) + goto unlock; + flowid =3D ffs(~msta->twt.flowid_mask) - 1; - le16p_replace_bits(&twt_agrt->req_type, flowid, - IEEE80211_TWT_REQTYPE_FLOWID); + twt_agrt->req_type &=3D ~cpu_to_le16(IEEE80211_TWT_REQTYPE_FLOWID); + twt_agrt->req_type |=3D le16_encode_bits(flowid, + IEEE80211_TWT_REQTYPE_FLOWID); =20 table_id =3D ffs(~dev->twt.table_mask) - 1; exp =3D FIELD_GET(IEEE80211_TWT_REQTYPE_WAKE_INT_EXP, req_type); @@ -2604,10 +2641,10 @@ void mt7996_mac_add_twt_setup(struct ieee80211_hw *= hw, unlock: mutex_unlock(&dev->mt76.mutex); out: - le16p_replace_bits(&twt_agrt->req_type, setup_cmd, - IEEE80211_TWT_REQTYPE_SETUP_CMD); - twt->control =3D (twt->control & IEEE80211_TWT_CONTROL_WAKE_DUR_UNIT) | - (twt->control & IEEE80211_TWT_CONTROL_RX_DISABLED); + twt_agrt->req_type &=3D ~cpu_to_le16(IEEE80211_TWT_REQTYPE_SETUP_CMD); + twt_agrt->req_type |=3D + le16_encode_bits(setup_cmd, IEEE80211_TWT_REQTYPE_SETUP_CMD); + twt->control =3D twt->control & IEEE80211_TWT_CONTROL_RX_DISABLED; } =20 void mt7996_mac_twt_teardown_flow(struct mt7996_dev *dev, diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mt7996.h b/drivers/n= et/wireless/mediatek/mt76/mt7996/mt7996.h index bc73bcb47bf02..8154ad37827f0 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/mt7996.h +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mt7996.h @@ -53,6 +53,7 @@ =20 #define MT7996_MAX_TWT_AGRT 16 #define MT7996_MAX_STA_TWT_AGRT 8 +#define MT7996_MIN_TWT_DUR 64 #define MT7996_MAX_QUEUE (__MT_RXQ_MAX + __MT_MCUQ_MAX + 3) =20 /* NOTE: used to map mt76_rates. idx may change if firmware expands table = */ @@ -320,7 +321,7 @@ struct mt7996_dev { struct rchan *relay_fwlog; =20 struct { - u8 table_mask; + u16 table_mask; u8 n_agrt; } twt; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D14A1649CE; Sun, 24 Mar 2024 22:39:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319940; cv=none; b=PZOWWQNGgnmG7EyQl48y8g2UYNxIxWrQ2ws2Fqs24dMcKag71KEFYcij+BbAvbvpyizAFupNMmbDqr2Yy3PLfHXsK2cmaieAVpB/sNnf834OOIADXHS1d6G2Gb806TspiuP3mFwW0Y+yWZWVp+cnAl/YToTsBBR3lT4PB32Z2gA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319940; c=relaxed/simple; bh=WixLlg00liAoc2SVnyGhXix2+bX3u5K/kKyo2dFe7cM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=L2wtwJ9trA2x6YPzmOAEYYNnXp0ZLGH1bmB9vREx5jWOwmHpAsDdxhr9T0bxhpARfxgec1gnxA141LsPeLFZ8/Eyew4j86jSLDW3R/KDomdpmtNmE8a2qwxpHEbi32rTJngHUZeGw15pXpUBcb0FNy5W+QywWy5HS9Nvpj3yoww= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BRetIItA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BRetIItA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AE2C6C433F1; Sun, 24 Mar 2024 22:38:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319940; bh=WixLlg00liAoc2SVnyGhXix2+bX3u5K/kKyo2dFe7cM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BRetIItAbV+mU2vvK26YqFJZO+z6MjDb5cxr5TU6deanAucPI6ZJkeMye0a5E/z+6 91Wd4kUGCjxgYJYIx/Y7X+5dJTnL7J4K6G4+DP84uuWLuVP8RdZWuTtQoeWQ4Tu+t5 O3d8lozbL+e9opvRCllNPkreu7Rg9/TCMtiYCFI7UqY301hA9MwFo7yykzRBBBLOwK qA6JdBet5K8QV2MKRolp5ZDlmvRFYc2VyeWEV/i32HUuMl5KF7t9G25ZxxG7Si1n9N kJvoqq9+fTe9wDrErE5SiYTgUn9RUEQ88M2SjMtU5xgJoFzdTDAEdlK1rHwCrYBaf/ xqc8R5Fao+THA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benjamin Lin , Shayne Chen , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 246/715] wifi: mt76: mt7996: fix incorrect interpretation of EHT MCS caps Date: Sun, 24 Mar 2024 18:27:05 -0400 Message-ID: <20240324223455.1342824-247-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benjamin Lin [ Upstream commit d52c97592f06552a4289008602b5d5b724084ba7 ] The EHT MCS map subfield of 20 MHz-Only is not present in the EHT capability of AP, so STA does not need to parse the subfield. Moreover, AP should parse the subfield only if STA is 20 MHz-Only, which can be confirmed by checking supported channel width in HE capability. Fixes: 92aa2da9fa49 ("wifi: mt76: mt7996: enable EHT support in firmware") Co-developed-by: Shayne Chen Signed-off-by: Shayne Chen Signed-off-by: Benjamin Lin Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c b/drivers/net/= wireless/mediatek/mt76/mt7996/mcu.c index 699be57309c2e..66351c19dbe41 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c @@ -1240,6 +1240,9 @@ mt7996_mcu_sta_he_6g_tlv(struct sk_buff *skb, struct = ieee80211_sta *sta) static void mt7996_mcu_sta_eht_tlv(struct sk_buff *skb, struct ieee80211_sta *sta) { + struct mt7996_sta *msta =3D (struct mt7996_sta *)sta->drv_priv; + struct ieee80211_vif *vif =3D container_of((void *)msta->vif, + struct ieee80211_vif, drv_priv); struct ieee80211_eht_mcs_nss_supp *mcs_map; struct ieee80211_eht_cap_elem_fixed *elem; struct sta_rec_eht *eht; @@ -1259,8 +1262,17 @@ mt7996_mcu_sta_eht_tlv(struct sk_buff *skb, struct i= eee80211_sta *sta) eht->phy_cap =3D cpu_to_le64(*(u64 *)elem->phy_cap_info); eht->phy_cap_ext =3D cpu_to_le64(elem->phy_cap_info[8]); =20 - if (sta->deflink.bandwidth =3D=3D IEEE80211_STA_RX_BW_20) - memcpy(eht->mcs_map_bw20, &mcs_map->only_20mhz, sizeof(eht->mcs_map_bw20= )); + if (vif->type !=3D NL80211_IFTYPE_STATION && + (sta->deflink.he_cap.he_cap_elem.phy_cap_info[0] & + (IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_40MHZ_IN_2G | + IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_40MHZ_80MHZ_IN_5G | + IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_160MHZ_IN_5G | + IEEE80211_HE_PHY_CAP0_CHANNEL_WIDTH_SET_80PLUS80_MHZ_IN_5G)) =3D=3D= 0) { + memcpy(eht->mcs_map_bw20, &mcs_map->only_20mhz, + sizeof(eht->mcs_map_bw20)); + return; + } + memcpy(eht->mcs_map_bw80, &mcs_map->bw._80, sizeof(eht->mcs_map_bw80)); memcpy(eht->mcs_map_bw160, &mcs_map->bw._160, sizeof(eht->mcs_map_bw160)); memcpy(eht->mcs_map_bw320, &mcs_map->bw._320, sizeof(eht->mcs_map_bw320)); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90D8D16FF3B; Sun, 24 Mar 2024 22:39:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319941; cv=none; b=VLXqk6gAlfutGtyk7PxlYNe1w1UbenvQNxAUqTWXTcjpR21JGj4iXX+zWIE0+Rl7Q0hL63Sg4Ynt3yiZV1QyrZ52L6YGDPUdEgnLT9kRGtW6PklXzs3wP1P8vTe4OeaPzdwJEhp2K2qcKyLDFMyS8t395DvOsC4GjG2FpTez+4c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319941; c=relaxed/simple; bh=c+3EJWvAEmgGLHgnQsMuUKcHVuSIgMWz435MQegGdok=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=POBOK73JgXX6iV4jt0O0ocVlKMYTkEWUC4ywNcctCf57ruN+Vk4A7XTo2iPvAci01sheR8q3X8DK+xipe7/yGOZ4d+wLPY4xKPJoik8Tl+NZpjfc1QFWuqYXPpzid5OnU/JoovSvSwbPc5eUNqYeO6UI3uWtskQu+B+VlsDKPQQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VvEdY1/M; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VvEdY1/M" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B291AC433B1; Sun, 24 Mar 2024 22:39:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319941; bh=c+3EJWvAEmgGLHgnQsMuUKcHVuSIgMWz435MQegGdok=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=VvEdY1/MuqEJFDEV435SZ8KWwAZaWof1oQdh/OB1ch00WFgU30rgz5sQhRswqBV+J gF/8670fqh69q/kkfLfUPSNHR0Lt0i0JzL02cjjlXY7bCWfH/3guLBNuEX2CJFf4hs hSW73iBNiRvK+vjlS5U56xExZQqFNzVSM12OveXe2XomaiScCPIS0Efz0z+8goVmef 7tVAUHdVNU10x6q0zIPq2NFWD6ofgaiRcQRWrTMe838T5RDxl7l9IkyE9ymb7Q4c62 2y0UwpTzGyUQ7XeaKoRrcUkm7wt/eBb76BUL6d7L+dFXO0NvmjBCnJpQcth/q5+LaC oq4TMHwOnsarQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Howard Hsu , Shayne Chen , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 247/715] wifi: mt76: mt7996: fix HE beamformer phy cap for station vif Date: Sun, 24 Mar 2024 18:27:06 -0400 Message-ID: <20240324223455.1342824-248-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Howard Hsu [ Upstream commit e1a491e856a8a36c46b39ecd07f3bba5a119d83a ] Set correct beamformer capabilities for station vif in HE PHY capability IE. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (= 802.11be) devices") Signed-off-by: Howard Hsu Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt7996/init.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/init.c b/drivers/net= /wireless/mediatek/mt76/mt7996/init.c index 0cf0d1fe420a2..1a1a60744272d 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/init.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/init.c @@ -1012,11 +1012,12 @@ mt7996_set_stream_he_txbf_caps(struct mt7996_phy *p= hy, /* the maximum cap is 4 x 3, (Nr, Nc) =3D (3, 2) */ elem->phy_cap_info[7] |=3D min_t(int, sts - 1, 2) << 3; =20 - if (vif !=3D NL80211_IFTYPE_AP) + if (!(vif =3D=3D NL80211_IFTYPE_AP || vif =3D=3D NL80211_IFTYPE_STATION)) return; =20 elem->phy_cap_info[3] |=3D IEEE80211_HE_PHY_CAP3_SU_BEAMFORMER; - elem->phy_cap_info[4] |=3D IEEE80211_HE_PHY_CAP4_MU_BEAMFORMER; + if (vif =3D=3D NL80211_IFTYPE_AP) + elem->phy_cap_info[4] |=3D IEEE80211_HE_PHY_CAP4_MU_BEAMFORMER; =20 c =3D FIELD_PREP(IEEE80211_HE_PHY_CAP5_BEAMFORMEE_NUM_SND_DIM_UNDER_80MHZ= _MASK, sts - 1) | --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99D7016FF5D; Sun, 24 Mar 2024 22:39:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319942; cv=none; b=HEFREiziFlK5oM1SnD+6QvIxRkZR3Dwo4QCwdswfvDpU3BQnrkV2p1UmtuwQgpRdRIkScUJBlsDvMnmR9MKtEu6ktu+ao02cEyjvPxWu6TORzQwo8cbiqrP2w+Na065XJjO8x+QGuK9moMz3lcMp0SPAAFcYWnpiujPJtC/hohM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319942; c=relaxed/simple; bh=xM4m3mZYXN/V90A7kAeayvG5Mdp5nbzjpe3S7nwJfrI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kbEgjBkO3CUuYonxk6MWWNlRHFn5qWqN18JX5tkUT2de1TKA/8C1ku7aaLKN+tPTxaqzc/Bp6Ri4PfeEnDvF4ZUjNcBc+3XkyVrsuZm69HFtqEgzwMBBx8XDa7UGbbDMRGir+P6mY+aHetRo8r3qL22wBDUreh+T0bcbI9pFaF0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ox5T8wlA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ox5T8wlA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4A6FC433F1; Sun, 24 Mar 2024 22:39:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319942; bh=xM4m3mZYXN/V90A7kAeayvG5Mdp5nbzjpe3S7nwJfrI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ox5T8wlAG90H6AAtRc8Vg1AP2E/Ioxd82J8iu3QvQ6Op3g+tv0Ceyyda563IwVy4D bezG3lLgFf2yUUeuKRHatj5IDxJoMqrQM+Ktf6jQJG6N1u2pyyNolyLI7sX3d2MVNP igv5DpsBUT/B20VvaJYxnKKBbQSShDvedYFlORLVtiS3OrXJO7i9jI0dyTwjLqFHNY syky4kepiKBJpFOnhoASJmDX5eR+lz7hclPY/kC0XktnxyjBW/xufX+rbbq+TtC2co 0Dwc8axo/Ftpwxv0nNWB2wjRADo5YU/EN274SG+ZeokYDaqq/t7lFrOtpveVmMwpdo VFbQDtmRJhLmg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: StanleyYP Wang , Shayne Chen , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 248/715] wifi: mt76: mt7996: fix efuse reading issue Date: Sun, 24 Mar 2024 18:27:07 -0400 Message-ID: <20240324223455.1342824-249-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: StanleyYP Wang [ Upstream commit d3ad99be7cc2d174126d908addd6bea2b157aa75 ] The efuse data starts from the 48th bytes instead of 64th bytes in the returned event skb. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (= 802.11be) devices") Signed-off-by: StanleyYP Wang Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt7996/mcu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c b/drivers/net/= wireless/mediatek/mt76/mt7996/mcu.c index 66351c19dbe41..9e70b960086ac 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/mcu.c @@ -3551,7 +3551,7 @@ int mt7996_mcu_get_eeprom(struct mt7996_dev *dev, u32= offset) u32 addr =3D le32_to_cpu(*(__le32 *)(skb->data + 12)); u8 *buf =3D (u8 *)dev->mt76.eeprom.data + addr; =20 - skb_pull(skb, 64); + skb_pull(skb, 48); memcpy(buf, skb->data, MT7996_EEPROM_BLOCK_SIZE); } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CE65457899; Sun, 24 Mar 2024 22:39:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319943; cv=none; b=BhhaUrOxOs9Kjsxz6qG1GPulachOXyHn8lHtEztN8rCDhjDYW/pjOBRNbJUvXUSfFaNosvCwyp6oM+RQtfuI4CsW+DbJqYkC483Q0Mg8gBN1WXI+yKJqvScLjyxewUX3k8jTso5KeNDZYAIqkeeMnEQuBo1cT0vE1LIMCQRYkFg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319943; c=relaxed/simple; bh=SPCV+ObubcSKVsfZuQiEsJDfvzkLinbGc8VIthJu8ps=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gPrY8mF5mCZxugyxllY88GhiANjD3mq0P4PizMhIN/8EsD7oDPmHZpcAiC79DKBAqzH1nLS6scZJsGrxTGOz09hHtVHoiOd7noVzAVwMyNUqWzRRtIBlRbHrBMGag7YTfft0kyNhAnTxnTJx/4nICev1afUHkiNnwNX/z+iSuDQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Xs0PRC+B; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Xs0PRC+B" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B8CFFC43399; Sun, 24 Mar 2024 22:39:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319943; bh=SPCV+ObubcSKVsfZuQiEsJDfvzkLinbGc8VIthJu8ps=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Xs0PRC+BisyRCQH/7A/cGO/H8FrzZz5pv1UED1RzGo73ZdgOfVMrBPrqNgBXqN0FE Gn/45yiIFiirP4zm5Gjwbsib6xwzRQKMgHJ5oipLld1tttkR4q05eklOVoU24x349i 5gIwZVpWD9ewqB+kT9r02pvk9F9iRIt5t+0Kmz2DyCQCay6w3xnHRZ/w/E8dtDmI8N HqpBELu1GH5qExaTYeqG5lIUfKTIXKjzbQHiihDFBNUe0J/s5cO/GMLDRIVaMaaX77 Put2NLsJiAAq+GETtjRgOvZrHC5QnPIen/1gwzkv8q2uwSwogEg5trlan0MLC9Rg8n 5TuG5cUgaxa0w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Benjamin Lin , Shayne Chen , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 249/715] wifi: mt76: mt7996: fix HIF_TXD_V2_1 value Date: Sun, 24 Mar 2024 18:27:08 -0400 Message-ID: <20240324223455.1342824-250-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Benjamin Lin [ Upstream commit de8882775156682ba358afc82cb575c92cf3d092 ] Sync the value of HIF_TXD_V2_1 with firmware to let it correctly fill TXD values for HW path. Fixes: 98686cd21624 ("wifi: mt76: mt7996: add driver for MediaTek Wi-Fi 7 (= 802.11be) devices") Signed-off-by: Benjamin Lin Signed-off-by: Shayne Chen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt7996/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7996/init.c b/drivers/net= /wireless/mediatek/mt76/mt7996/init.c index 1a1a60744272d..a929c657be1c4 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7996/init.c +++ b/drivers/net/wireless/mediatek/mt76/mt7996/init.c @@ -493,7 +493,7 @@ static void mt7996_mac_init_basic_rates(struct mt7996_d= ev *dev) =20 void mt7996_mac_init(struct mt7996_dev *dev) { -#define HIF_TXD_V2_1 4 +#define HIF_TXD_V2_1 0x21 int i; =20 mt76_clear(dev, MT_MDP_DCR2, MT_MDP_DCR2_RX_TRANS_SHORT); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D9E9D84D3F; Sun, 24 Mar 2024 22:39:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319944; cv=none; b=Wa408Fw74XeouYQTW0skJv7HCDeoAJZH4Juxhca6PSYLvs8H3z9g75VR6jLR3AxL1Afc516t3ZoN+RmeL8rm8UrCASSXil3f81EPj5ilURifk580PXC3C8iL5doiP2n0jDnJjoKD1YGEEsGjV10eBba7/L9ZvI3X7pFNRhPbkhE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319944; c=relaxed/simple; bh=IaFRpmeld72c6LkomiAk4EHfxlt6SMG/fVgjVIcW9cM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MTX5xMJXqZXfUVmmSDg8O0KjwJkymagJHbFUq8DoO7jxTpSaKaGJl9bkmbtVzKiSPssMrnfiw19Ow1D58pOfLlTnmg/fvMJVQaNiZIvGgtHSfNMhkIDp35BR7ly3bsoP1xtFrs2oH3sd5jIHfWv1UlWOP1LHRtk8e/6wzdR4sq0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=t7QdrSZ4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="t7QdrSZ4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C17F0C433F1; Sun, 24 Mar 2024 22:39:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319944; bh=IaFRpmeld72c6LkomiAk4EHfxlt6SMG/fVgjVIcW9cM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=t7QdrSZ4JOds5Lesq/pDpD0ipMJ8DFaFeE9YTlSijxaqudXRQQsdmFfHEGuVKCDEW TnfkoXoZ7JjLg3iT+fUswLfANjBViDzymXi/vHcqPrwfW14MyW/rrMezBvSX2+RA6T zUXgQO1wb2q0bQhaaxvzBWx/24MfZgxlCpjsu7pIipEsMT31/9niaJpyuHf/jPms89 BVa7u37IEYtRzb8ov2dLDSbjpk8weH7I3s4peOsjRGZHmun10ofP9IoaANhiD826m1 Yscfs7GTH34OfpZV6lkC+7Oj6m4azxaxcwbRC6wu//iIyZdGmROWeW9/2OUVJTDxSy +JRBDDXjMG9ow== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gen Xu , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 250/715] wifi: mt76: mt792x: fix ethtool warning Date: Sun, 24 Mar 2024 18:27:09 -0400 Message-ID: <20240324223455.1342824-251-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gen Xu [ Upstream commit 7b4f9cd6a5fc221895b1d9be83ee3c13c00d09ab ] Add a missing EHT related field to fix the following ethtool warning: [98179.287352] mt7921e 0003:01:00.0: ei: 74 SSTATS_LEN: 73 Fixes: c74df1c067f2 ("wifi: mt76: mt792x: introduce mt792x-lib module") Signed-off-by: Gen Xu Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt792x_core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_core.c b/drivers/net= /wireless/mediatek/mt76/mt792x_core.c index c42101aa9e45e..9ac5161dfff8c 100644 --- a/drivers/net/wireless/mediatek/mt76/mt792x_core.c +++ b/drivers/net/wireless/mediatek/mt76/mt792x_core.c @@ -354,6 +354,7 @@ static const char mt792x_gstrings_stats[][ETH_GSTRING_L= EN] =3D { "v_tx_bw_40", "v_tx_bw_80", "v_tx_bw_160", + "v_tx_bw_320", "v_tx_mcs_0", "v_tx_mcs_1", "v_tx_mcs_2", --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C329C13C3D2; Sun, 24 Mar 2024 22:39:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319945; cv=none; b=hJayHOyWz4K5JOJtR0Y+9kXFkYRKgV/mftfyuf6HoY3PhkTQN8AIsK8bJKQcj0WVgq9H6T9raym4WBG84GOFFLl/kmCTodweX7BEJYs11NKGlGtDbpOrOe4w4S5txoVke143B9k/LaTTt3iE6U1MoOGlbo3MCF3+PAmExibEpxI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319945; c=relaxed/simple; bh=ikmk3d//F6F+x4ngv5EXpqUTA6+K6pqxRuJxID3wO00=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZQxQOHzKuYB0wnjpcjghkshNAbeE5ZZMEC+ohSxW4Yb9I6ElS0lrQ0//awbYTSnBxHppsb5Hi8bDTIAztoHHwlQ9HmQP4/IdV+zqKOT7ymrUu9uSv+11gsWelmBBTZ78Ajzg6A6jkIu6h57+GcGyWR5b7PBq7JvRAcgCNOdOKbU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=M2TNCxdZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="M2TNCxdZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3A9AC433C7; Sun, 24 Mar 2024 22:39:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319945; bh=ikmk3d//F6F+x4ngv5EXpqUTA6+K6pqxRuJxID3wO00=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=M2TNCxdZAe6pu70aIctDst0dFMg8fjDAkBirYe2g1jprJ1TThAibst5JYB6QYeWT3 Jzw7jP4AM5Ya+oFung838GhYq0IrLBC2Z7f44NTnCmgznb5WOirLe5y59V8UnQbOzw UoGQh+ajoKMtLG631IUprxLI7j+/5ziNz1Xw/Rw+kpmJCfz0sOVU4fPCO0K4SRceEc 5dsDtXxGd8oFYGvx5Bo53xPsairo4kzzJ0ZWpPdc0SNqQeeOr7NwR9eNR7wm/c3Any Eq+OGV7LsKwSovLp6t9o46wO3Io/HSQoL++nijVs2+fiy5ipqmzJ2xSaRs4c8bIogt zdlRhtS4IaWgA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Deren Wu , Mikhail Gavrilov , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 251/715] wifi: mt76: mt7921e: fix use-after-free in free_irq() Date: Sun, 24 Mar 2024 18:27:10 -0400 Message-ID: <20240324223455.1342824-252-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Deren Wu [ Upstream commit c957280ef6ab6bdf559a91ae693a6b34310697e3 ] From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test to make sure the shared irq handler should be able to handle the unexpected event after deregistration. For this case, let's apply MT76_REMOVED flag to indicate the device was removed and do not run into the resource access anymore. BUG: KASAN: use-after-free in mt7921_irq_handler+0xd8/0x100 [mt7921e] Read of size 8 at addr ffff88824a7d3b78 by task rmmod/11115 CPU: 28 PID: 11115 Comm: rmmod Tainted: G W L 5.17.0 #10 Hardware name: Micro-Star International Co., Ltd. MS-7D73/MPG B650I EDGE WIFI (MS-7D73), BIOS 1.81 01/05/2024 Call Trace: dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x1f/0x190 ? mt7921_irq_handler+0xd8/0x100 [mt7921e] ? mt7921_irq_handler+0xd8/0x100 [mt7921e] kasan_report.cold+0x7f/0x11b ? mt7921_irq_handler+0xd8/0x100 [mt7921e] mt7921_irq_handler+0xd8/0x100 [mt7921e] free_irq+0x627/0xaa0 devm_free_irq+0x94/0xd0 ? devm_request_any_context_irq+0x160/0x160 ? kobject_put+0x18d/0x4a0 mt7921_pci_remove+0x153/0x190 [mt7921e] pci_device_remove+0xa2/0x1d0 __device_release_driver+0x346/0x6e0 driver_detach+0x1ef/0x2c0 bus_remove_driver+0xe7/0x2d0 ? __check_object_size+0x57/0x310 pci_unregister_driver+0x26/0x250 __do_sys_delete_module+0x307/0x510 ? free_module+0x6a0/0x6a0 ? fpregs_assert_state_consistent+0x4b/0xb0 ? rcu_read_lock_sched_held+0x10/0x70 ? syscall_enter_from_user_mode+0x20/0x70 ? trace_hardirqs_on+0x1c/0x130 do_syscall_64+0x5c/0x80 ? trace_hardirqs_on_prepare+0x72/0x160 ? do_syscall_64+0x68/0x80 ? trace_hardirqs_on_prepare+0x72/0x160 entry_SYSCALL_64_after_hwframe+0x44/0xae Reported-by: Mikhail Gavrilov Closes: https://lore.kernel.org/linux-wireless/CABXGCsOdvVwdLmSsC8TZ1jF0UOg= _F_W3wqLECWX620PUkvNk=3DA@mail.gmail.com/ Fixes: 9270270d6219 ("wifi: mt76: mt7921: fix PCI DMA hang after reboot") Tested-by: Mikhail Gavrilov Signed-off-by: Deren Wu Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt7921/pci.c | 1 + drivers/net/wireless/mediatek/mt76/mt792x_dma.c | 2 ++ 2 files changed, 3 insertions(+) diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c b/drivers/net/= wireless/mediatek/mt76/mt7921/pci.c index dde26f3274783..82cf3ce90b52f 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c +++ b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c @@ -387,6 +387,7 @@ static void mt7921_pci_remove(struct pci_dev *pdev) struct mt792x_dev *dev =3D container_of(mdev, struct mt792x_dev, mt76); =20 mt7921e_unregister_device(dev); + set_bit(MT76_REMOVED, &mdev->phy.state); devm_free_irq(&pdev->dev, pdev->irq, dev); mt76_free_device(&dev->mt76); pci_free_irq_vectors(pdev); diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_dma.c b/drivers/net/= wireless/mediatek/mt76/mt792x_dma.c index 8fa36b59e738d..5cc2d59b774af 100644 --- a/drivers/net/wireless/mediatek/mt76/mt792x_dma.c +++ b/drivers/net/wireless/mediatek/mt76/mt792x_dma.c @@ -12,6 +12,8 @@ irqreturn_t mt792x_irq_handler(int irq, void *dev_instanc= e) { struct mt792x_dev *dev =3D dev_instance; =20 + if (test_bit(MT76_REMOVED, &dev->mt76.phy.state)) + return IRQ_NONE; mt76_wr(dev, dev->irq_map->host_irq_enable, 0); =20 if (!test_bit(MT76_STATE_INITIALIZED, &dev->mphy.state)) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 840B313C3ED; Sun, 24 Mar 2024 22:39:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319946; cv=none; b=SwnJZ6kMIcGixawWWAEwgnJoCgVA1Rl/BsKh6qeUOOG85eqhfcOu1T1JEE4dE4WWqAeJ2WXTkrhICHudjwJ8RFEn6Gdjpk7ylJXGHA1toY1a+QBfyMmuRN1nHr28e46unCO8IGE3INHGUnB9RULvR4mxhXl+NZV4Hokfe20JN8A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319946; c=relaxed/simple; bh=Q4+ByOQI6AC/hRIgafFeNoLkyAsC2er0jPK3iWRch10=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DV5JKPx4unxtOgwSBuzhRS8V3o1AkX3tjWs126rLFfsehKe0ID2HEX5erdXfgMm/WAwIxY255/4YO21wYkJVui3YZqgZyb0t54MpVofK5fmhSyO7uua/q1JkHPyVz6qoWKsXc44s053ezmIZM45DQWfEM4sl2xEtmmlgF9NmEvc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=fail (0-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ux/1ZNf/ reason="key not found in DNS"; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ux/1ZNf/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B3B1BC433B1; Sun, 24 Mar 2024 22:39:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319946; bh=Q4+ByOQI6AC/hRIgafFeNoLkyAsC2er0jPK3iWRch10=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ux/1ZNf/bgR6ROWRWO9mviR+2OFYvVB0fJ0Bsq/YjWfnqU3r3w3Rwpk3AfDvzE+EN 0s/x2EqQOCofqQzi+50V9L6Ja+vxXu3/i+mvIIXC5e1Tv122kkOC2MoN3kKTLk87Sn qE3RcloRljtKC1Codb64t46KZevrXmYeWpPuIgXCtileP5IAuEzSFSWZ9tbYU7MsMF nhQ9dcFJt0r1fsRjISLnwHm3midh35+QOCJZadx5EizOkvryJViI8Vy2Ab32QoWZrc RRQyV2BaiRDONq9O8pKCOT8Si4sfiLBKiz4ytpWa2qtVXpF9ScwyIOxCoQedUYPVKa QI6kbdeCjPamA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Deren Wu , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 252/715] wifi: mt76: mt7925e: fix use-after-free in free_irq() Date: Sun, 24 Mar 2024 18:27:11 -0400 Message-ID: <20240324223455.1342824-253-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Deren Wu [ Upstream commit a5a5f4413d91f395cb2d89829d376d7393ad48b9 ] From commit a304e1b82808 ("[PATCH] Debug shared irqs"), there is a test to make sure the shared irq handler should be able to handle the unexpected event after deregistration. For this case, let's apply MT76_REMOVED flag to indicate the device was removed and do not run into the resource access anymore. Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt= 7925 chips") Signed-off-by: Deren Wu Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt7925/pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c b/drivers/net/= wireless/mediatek/mt76/mt7925/pci.c index 74cfba7675beb..07b74d492ce15 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/pci.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/pci.c @@ -427,6 +427,7 @@ static void mt7925_pci_remove(struct pci_dev *pdev) struct mt792x_dev *dev =3D container_of(mdev, struct mt792x_dev, mt76); =20 mt7925e_unregister_device(dev); + set_bit(MT76_REMOVED, &mdev->phy.state); devm_free_irq(&pdev->dev, pdev->irq, dev); mt76_free_device(&dev->mt76); pci_free_irq_vectors(pdev); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8594D16EBE4; Sun, 24 Mar 2024 22:39:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319947; cv=none; b=qrelHRpGuKmhfcvF2nAsfo3QXcCKQCswtSPeL+YnpOJaOTTkauo7/qccvvo8d0h6U1sM1ZYoKWNyZke01gid3EAj+c4at69X0wwXK88HeGCmrDjJNevuoQoZPca6E/0aN7RtzjuH5fNd+qcAZMROl3VZTl2eTrzG4SOjggatq08= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319947; c=relaxed/simple; bh=sv4/1oKiZ1NfQVtAx8ws3BB1smFkKwt+29gB5TTjeXo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aT7jZcuPuBPZ7+czREXuVCxmEmf7lEdZfARA0YzD2pXCgbqUdrK47eHF2oBWmc6zSzT2UGknUJntDZWJK3Ga+/CAIMdZAOkaGGrkAl7aCJKi25z2oj0AJW1OMcVF3Y9sD2FRNbHHqrOvTvxlH77uHFquPdSDtlZupfcfLqDfVlY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y9ZCoII8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Y9ZCoII8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8E69C433F1; Sun, 24 Mar 2024 22:39:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319947; bh=sv4/1oKiZ1NfQVtAx8ws3BB1smFkKwt+29gB5TTjeXo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Y9ZCoII8VoQ2xVAp6bKD7t7aow+N/YrgNTe/wonLjn0CSUOQr0AfojkToUIuehMn6 sBc6ZpEMSlGTYqirVIXjnxXxg+Zu+ofEBE2GfqDiu0Dn0LnhKD7qY5Duupwn0jGKAq x6jJEDj9q3ynHa4Z3Bm+UqxWd0SIyFvDEYzaoBeC4989hMALJx3RPtsc2OvfHV7BZB zsIpSRc6+/+ape9lD/bC+XsIiNR/xfd6m4VDc6pjLvme0CILQwHNXLePJd5Hx7kufs uxbsodQ0bRCqpTFGlLY4h70k+jO/ElO1a1hbJlUf6wSJCrsbxVWEY4eXc+m1KOv3kI /Lexnf09uNqCA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Yen Hsieh , kernel test robot , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 253/715] wifi: mt76: mt7921: fix incorrect type conversion for CLC command Date: Sun, 24 Mar 2024 18:27:12 -0400 Message-ID: <20240324223455.1342824-254-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Yen Hsieh [ Upstream commit b6351ef9994ccb93b2447d396a0c517964dff2bc ] clc->len is defined as 32 bits in length, so it must also be operated on with 32 bits, not 16 bits. Fixes: fa6ad88e023d ("wifi: mt76: mt7921: fix country count limitation for = CLC") Signed-off-by: Ming Yen Hsieh Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202312112104.Zkc3QUHr-lkp@int= el.com/ Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt7921/mcu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c b/drivers/net/= wireless/mediatek/mt76/mt7921/mcu.c index f5582477c7e4c..8b4ce32a2cd12 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7921/mcu.c @@ -1272,7 +1272,7 @@ int __mt7921_mcu_set_clc(struct mt792x_dev *dev, u8 *= alpha2, .mtcl_conf =3D mt792x_acpi_get_mtcl_conf(&dev->phy, alpha2), }; int ret, valid_cnt =3D 0; - u16 buf_len =3D 0; + u32 buf_len =3D 0; u8 *pos; =20 if (!clc) @@ -1283,7 +1283,7 @@ int __mt7921_mcu_set_clc(struct mt792x_dev *dev, u8 *= alpha2, if (mt76_find_power_limits_node(&dev->mt76)) req.cap |=3D CLC_CAP_DTS_EN; =20 - buf_len =3D le16_to_cpu(clc->len) - sizeof(*clc); + buf_len =3D le32_to_cpu(clc->len) - sizeof(*clc); pos =3D clc->data; while (buf_len > 16) { struct mt7921_clc_rule *rule =3D (struct mt7921_clc_rule *)pos; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D10AB16EC10; Sun, 24 Mar 2024 22:39:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319948; cv=none; b=QazJQjADbkUAbYqKe6I20MoYITAlNMcwVd5H9nhem+0/td5RVAWURxJxidGeszLb6kHrrdKvedrRgodj5obcpY/YPJw6da/wt7BlLaeP1+x1np53lGr8XEbI1zejRuk2+Ihv6+a7YfQdugFHgzBdbfYxa2UXEI7+ewKMtkW/kzg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319948; c=relaxed/simple; bh=dKi3U0fdatZ7Ch7IsQNs3ZCbOcFztWAhzn7bV7x69kw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ShF8XkbS73b3a1s7cbJkA7LBPa5DIGa8r/99HRm4ZgxhBEnDlZjoImAnmsfrs40bsuWefs6/GVkvWOZMoX5BfGvJW/rp4V2sLT7yaEQ/IMkc/rR+xVRv4jvNfS7G1cZ47aYaY5BV32/w0qyVX4wdh/AEBSVuYyFb0r1S1Xnpxvc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nHJkb3SZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="nHJkb3SZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA7ACC433C7; Sun, 24 Mar 2024 22:39:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319948; bh=dKi3U0fdatZ7Ch7IsQNs3ZCbOcFztWAhzn7bV7x69kw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=nHJkb3SZiPUghCQGRoi6ZP2Wrvg0N/pifdItanE7+pXaLBk2fEipautjaiinCYY1u HqP5qmpS26dGQcoBDnvTZvQl9AUTyXlmSay0oMXxj6Tnd7ufpHdFiEBPMbvFn6lNTx JxcBXthHIzXjEzb5xbYV0pRZ8up/lw+IfSJ/97axVhYkdycRnagatZjjqQhs07ybHJ 9airokfQaTjyS3LXRqGKRUTrN0wwBe/8yNVLbH1KFE/R4rTniovJ3Th4U7te1Sg8Uy N5djAS0Q8T/moyJBSB+cD0JqshOBHXIn4uI8DtqQZdEjDcxu5pc4M1o5ZTVRzeUXmx 7IvIUQ0YxPXcQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Yen Hsieh , Leon Yen , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 254/715] wifi: mt76: mt792x: fix a potential loading failure of the 6Ghz channel config from ACPI Date: Sun, 24 Mar 2024 18:27:13 -0400 Message-ID: <20240324223455.1342824-255-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Yen Hsieh [ Upstream commit 07ce1d46372489d90f9cccebb3277d1af801c4b9 ] In some case, the MTCL table will exist, but MTDS table will not. So the SAR will init fail. This patch make MTCL and MTDS can exist with no dependence. Fixes: f965333e491e ("mt76: mt7921: introduce ACPI SAR support") Signed-off-by: Ming Yen Hsieh Signed-off-by: Leon Yen Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../wireless/mediatek/mt76/mt792x_acpi_sar.c | 26 ++++++++++--------- 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c b/drivers= /net/wireless/mediatek/mt76/mt792x_acpi_sar.c index e7afea87e82e2..8fee3d481df0d 100644 --- a/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c +++ b/drivers/net/wireless/mediatek/mt76/mt792x_acpi_sar.c @@ -66,13 +66,15 @@ mt792x_acpi_read(struct mt792x_dev *dev, u8 *method, u8= **tbl, u32 *len) } =20 /* MTCL : Country List Table for 6G band */ -static void +static int mt792x_asar_acpi_read_mtcl(struct mt792x_dev *dev, u8 **table, u8 *version) { - if (mt792x_acpi_read(dev, MT792x_ACPI_MTCL, table, NULL) < 0) - *version =3D 1; - else - *version =3D 2; + int ret; + + *version =3D ((ret =3D mt792x_acpi_read(dev, MT792x_ACPI_MTCL, table, NUL= L)) < 0) + ? 1 : 2; + + return ret; } =20 /* MTDS : Dynamic SAR Power Table */ @@ -166,16 +168,16 @@ int mt792x_init_acpi_sar(struct mt792x_dev *dev) if (!asar) return -ENOMEM; =20 - mt792x_asar_acpi_read_mtcl(dev, (u8 **)&asar->countrylist, &asar->ver); + ret =3D mt792x_asar_acpi_read_mtcl(dev, (u8 **)&asar->countrylist, &asar-= >ver); + if (ret) { + devm_kfree(dev->mt76.dev, asar->countrylist); + asar->countrylist =3D NULL; + } =20 - /* MTDS is mandatory. Return error if table is invalid */ ret =3D mt792x_asar_acpi_read_mtds(dev, (u8 **)&asar->dyn, asar->ver); if (ret) { devm_kfree(dev->mt76.dev, asar->dyn); - devm_kfree(dev->mt76.dev, asar->countrylist); - devm_kfree(dev->mt76.dev, asar); - - return ret; + asar->dyn =3D NULL; } =20 /* MTGS is optional */ @@ -290,7 +292,7 @@ int mt792x_init_acpi_sar_power(struct mt792x_phy *phy, = bool set_default) const struct cfg80211_sar_capa *capa =3D phy->mt76->hw->wiphy->sar_capa; int i; =20 - if (!phy->acpisar) + if (!phy->acpisar || !((struct mt792x_acpi_sar *)phy->acpisar)->dyn) return 0; =20 /* When ACPI SAR enabled in HW, we should apply rules for .frp --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6DEAD13C3D2; Sun, 24 Mar 2024 22:39:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319949; cv=none; b=rwMXYVNyI5vTag/Dgp5uXEK2SIDkWyOYSpAXCUksuHSXJq8/mda0T0HDYiOlgfQOfOmZpsbqqXRD/3HBcqziv+2AsJjwKJmwIEPdLXrM+0cxUHGiWezJmFL1cxb5HKeocdIz+YL1PPJf3m+GLzezu+Q+2Yg7kwMhk8LObOE1htI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319949; c=relaxed/simple; bh=NexbagmyqgKdVb4XpfNijJu/lL6hIr1kSEOaWacCw/0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dC/pxSCgYUt53U4hxY7QCJR1ADU391oAAmbgjpn7dKNO++LFlZHZ+qXlq/B/fqtL8d77kbQmt2HC8C/uX1G8cU29W0kPetsixT6YU0srHgFPx1d+3kfqb0ffutz/5Bg1PX03sqBmO4Zq6BnNWDV5YSpjc4URhBodk2SAN5Zla0E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ru6Pmuwf; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ru6Pmuwf" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A9B76C433A6; Sun, 24 Mar 2024 22:39:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319949; bh=NexbagmyqgKdVb4XpfNijJu/lL6hIr1kSEOaWacCw/0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ru6Pmuwfdko1BREqzTAb0r8/TcwrvDjxQkaaj0stU6H47USgjIj+NGj9kgCm/5K6n Bl7EhL7R/9ga3iiCZtFek/z9QGjlTACU52G5RIZ4Hw11lROGwpLDudvW3IJZv/hCgx ZPz+4mnbeW68ngn9Leg40m8WbHWhnBLdTF03R0RWjSPp01f6NgRbRhRdkEaqQQcIIH tqaersiiXPEYgLUHaQSdUQWwWhWsOb+bjmT+5lO83TG2Y0hiPUbkK1XDOeNOh8xImv LVH7ZJ4qmts84DUA+u209CjXRWWFzXlHyYjEQ1Mjbr/2uIbaRAMkYEa/utoXpc9yab VD0WfXFV/imjA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Yen Hsieh , Felix Fietkau , Sasha Levin Subject: [PATCH 6.8 255/715] wifi: mt76: fix the issue of missing txpwr settings from ch153 to ch177 Date: Sun, 24 Mar 2024 18:27:14 -0400 Message-ID: <20240324223455.1342824-256-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Yen Hsieh [ Upstream commit e9a46175a79fbc591c48d433020444b8fa2750ee ] Because the number of channels to be configured is calculated using the %, and it results in 0 when there's an exact division, this leads to some channels not having their tx power configured. Fixes: 7801da338856 ("wifi: mt76: mt7921: enable set txpower for UNII-4") Signed-off-by: Ming Yen Hsieh Signed-off-by: Felix Fietkau Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c b/drivers= /net/wireless/mediatek/mt76/mt76_connac_mcu.c index ea7ffa16a4b12..ae19174b46ee5 100644 --- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mcu.c @@ -2101,7 +2101,7 @@ mt76_connac_mcu_rate_txpower_band(struct mt76_phy *ph= y, int j, msg_len, num_ch; struct sk_buff *skb; =20 - num_ch =3D i =3D=3D batch_size - 1 ? n_chan % batch_len : batch_len; + num_ch =3D i =3D=3D batch_size - 1 ? n_chan - i * batch_len : batch_len; msg_len =3D sizeof(tx_power_tlv) + num_ch * sizeof(sku_tlbv); skb =3D mt76_mcu_msg_alloc(dev, NULL, msg_len); if (!skb) { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AFED316F285; Sun, 24 Mar 2024 22:39:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319950; cv=none; b=seXtRqDTKzkdnQ+ijbxUEN8MIfIYneVP8fitR0Zl8piFiJOnolBD8RrcBMHMHqZuhgO5+T8b90Jv12FLrK2MIIeZdKwcuOvEpkgyeuPdh4s7nWfOtUGWW43XwouKdk8b628mh7Dhh0DNAW69nsuft+K74a6Zu2oQq+fq1GSNj6c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319950; c=relaxed/simple; bh=iBV/5/Z+cGNqIANUq+vBJr418QFN4hXW/Rfok5Qg3Zw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=s1frewNxDCLVC1SBXli46RQyKiFcrTgzH+zDYKK+dkULtVZnJVSdpWQdi5j2L6ZqVWzhn477iiixI/ki5vehS+LL2pLGZBOZM22WMU901vsNcV+Uy6QFhXsjKJXg3QgLiZc5lNeIdvzveDTe4rsv79Wmntu+z7jWk63E8T4nWi0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=s/rgaTGC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="s/rgaTGC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91D9DC43601; Sun, 24 Mar 2024 22:39:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319950; bh=iBV/5/Z+cGNqIANUq+vBJr418QFN4hXW/Rfok5Qg3Zw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=s/rgaTGCFxpIAPMeKE+uxOs+nww6ViGiKFsc+u2mM7l0nrKS1tRUrVddEFtu6bt6I cE8KKmWiZiRsOe0zjPBrL/MScZhhcXEk8XinfhadQNKoTVZR7vcv0A4RD/JPYS5Qr5 NxKF/Bb77Q6Iyg/YholWjR8jWn0rWlf6AZ5bjq357jrUTHtTrP9CsPo2FBtjNFANS7 QYT2GERGGMM5wYme7P4j1VbLHpUJqVlUy7N9E9+h23b35bQHfaAS/yW2kUib6IkqlB wxsNMCuIDseMRcImIY9u3eeCj34v271hu956I2JzUKsVz34Sa11mNRrzvof0Q6E2J1 kzc/E1o3n84Bg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lad Prabhakar , Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.8 256/715] arm64: dts: renesas: rzg2l: Add missing interrupts to IRQC nodes Date: Sun, 24 Mar 2024 18:27:15 -0400 Message-ID: <20240324223455.1342824-257-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lad Prabhakar [ Upstream commit 14fe225dd5fcd5928583b0bcc34398a581f51602 ] The IRQC IP block supports Bus error and ECCRAM interrupts on RZ/G2L and alike SoC's (listed below). Update the IRQC nodes with the missing interrupts, and additionally, include the 'interrupt-names' properties in the IRQC nodes so that the driver can parse interrupts by name. - R9A07G043U - RZ/G2UL - R9A07G044L/R9A07G044LC - RZ/{G2L,G2LC} - R9A07G054 - RZ/V2L Fixes: 5edc51af5b30 ("arm64: dts: renesas: r9a07g044: Add IRQC node") Fixes: 48ab6eddd8bb ("arm64: dts: renesas: r9a07g043u: Add IRQC node") Fixes: 379478ab09e0 ("arm64: dts: renesas: r9a07g054: Add IRQC node") Signed-off-by: Lad Prabhakar Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20240205144421.51195-3-prabhakar.mahadev-la= d.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/renesas/r9a07g043u.dtsi | 12 +++++++++-- arch/arm64/boot/dts/renesas/r9a07g044.dtsi | 22 ++++++++++++++++++++- arch/arm64/boot/dts/renesas/r9a07g054.dtsi | 22 ++++++++++++++++++++- 3 files changed, 52 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi b/arch/arm64/boot/= dts/renesas/r9a07g043u.dtsi index 2ab231572d95f..b3f83d0ebcbb5 100644 --- a/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi +++ b/arch/arm64/boot/dts/renesas/r9a07g043u.dtsi @@ -109,7 +109,13 @@ irqc: interrupt-controller@110a0000 { , , , - ; + , + , + , + , + , + , + ; interrupt-names =3D "nmi", "irq0", "irq1", "irq2", "irq3", "irq4", "irq5", "irq6", "irq7", @@ -121,7 +127,9 @@ irqc: interrupt-controller@110a0000 { "tint20", "tint21", "tint22", "tint23", "tint24", "tint25", "tint26", "tint27", "tint28", "tint29", "tint30", "tint31", - "bus-err"; + "bus-err", "ec7tie1-0", "ec7tie2-0", + "ec7tiovf-0", "ec7tie1-1", "ec7tie2-1", + "ec7tiovf-1"; clocks =3D <&cpg CPG_MOD R9A07G043_IA55_CLK>, <&cpg CPG_MOD R9A07G043_IA55_PCLK>; clock-names =3D "clk", "pclk"; diff --git a/arch/arm64/boot/dts/renesas/r9a07g044.dtsi b/arch/arm64/boot/d= ts/renesas/r9a07g044.dtsi index 66f68fc2b2411..081d8f49db879 100644 --- a/arch/arm64/boot/dts/renesas/r9a07g044.dtsi +++ b/arch/arm64/boot/dts/renesas/r9a07g044.dtsi @@ -905,7 +905,27 @@ irqc: interrupt-controller@110a0000 { , , , - ; + , + , + , + , + , + , + , + ; + interrupt-names =3D "nmi", "irq0", "irq1", "irq2", "irq3", + "irq4", "irq5", "irq6", "irq7", + "tint0", "tint1", "tint2", "tint3", + "tint4", "tint5", "tint6", "tint7", + "tint8", "tint9", "tint10", "tint11", + "tint12", "tint13", "tint14", "tint15", + "tint16", "tint17", "tint18", "tint19", + "tint20", "tint21", "tint22", "tint23", + "tint24", "tint25", "tint26", "tint27", + "tint28", "tint29", "tint30", "tint31", + "bus-err", "ec7tie1-0", "ec7tie2-0", + "ec7tiovf-0", "ec7tie1-1", "ec7tie2-1", + "ec7tiovf-1"; clocks =3D <&cpg CPG_MOD R9A07G044_IA55_CLK>, <&cpg CPG_MOD R9A07G044_IA55_PCLK>; clock-names =3D "clk", "pclk"; diff --git a/arch/arm64/boot/dts/renesas/r9a07g054.dtsi b/arch/arm64/boot/d= ts/renesas/r9a07g054.dtsi index 1f1d481dc7830..0d327464d2baf 100644 --- a/arch/arm64/boot/dts/renesas/r9a07g054.dtsi +++ b/arch/arm64/boot/dts/renesas/r9a07g054.dtsi @@ -912,7 +912,27 @@ irqc: interrupt-controller@110a0000 { , , , - ; + , + , + , + , + , + , + , + ; + interrupt-names =3D "nmi", "irq0", "irq1", "irq2", "irq3", + "irq4", "irq5", "irq6", "irq7", + "tint0", "tint1", "tint2", "tint3", + "tint4", "tint5", "tint6", "tint7", + "tint8", "tint9", "tint10", "tint11", + "tint12", "tint13", "tint14", "tint15", + "tint16", "tint17", "tint18", "tint19", + "tint20", "tint21", "tint22", "tint23", + "tint24", "tint25", "tint26", "tint27", + "tint28", "tint29", "tint30", "tint31", + "bus-err", "ec7tie1-0", "ec7tie2-0", + "ec7tiovf-0", "ec7tie1-1", "ec7tie2-1", + "ec7tiovf-1"; clocks =3D <&cpg CPG_MOD R9A07G054_IA55_CLK>, <&cpg CPG_MOD R9A07G054_IA55_PCLK>; clock-names =3D "clk", "pclk"; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EBD7C16F8F4; Sun, 24 Mar 2024 22:39:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319952; cv=none; b=QB240lkFu+Kk3aGRwH4F53vImoFjSJofzXeE286Gec2AYq37xWp1LaOHMP2L/s5feFS+mHqy7ia6Glfu7kp0YBfpJu6Y3jrKS73bRYb6ilDPaJwt2/wszsfnsPz37ToOZennT/+F6TnEDCkBr7NnXQQwUc0cYLtSZGY2BoJcTxs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319952; c=relaxed/simple; bh=UdODhsLqPh/+m5k338G4uLy8cOv40xr96gGPJ/2rmNY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=H894S9J2jdF/iCFORXDmk4QrM2r7j90Z7FNLRlLx0ofnsDrkGuJFsYy/3PmkvK7fFZ4yrDT2g+URl81aLI1qbWbp2QooWyV/1ixsDPULiaFE3G/wpSWfZE386mFh8vheCzomeSWIZP+bDR+rXBHf1pIZLaa5i1sxghcXBo43vdA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pTk+so1d; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pTk+so1d" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8109BC433C7; Sun, 24 Mar 2024 22:39:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319951; bh=UdODhsLqPh/+m5k338G4uLy8cOv40xr96gGPJ/2rmNY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pTk+so1d+9s7DAPsWnRobkROLQdLHKg+nP5nEm+Ql9PHjxQbT9XIhcnh70ikRlXBT BJDXAl2Ley/y47IRrwnSMJJsgdYBNzzccoO4+VGjC5XtbXIEIw67Cik9LDQ/Vebo/v 8WKR11acCVzY1nlWilUrBognR7hwNx8WbtKJlvXNPJUNTZR4pTyMPBJl4MVDRLAtzE RbvnzJpM6OXfL2STLhGzbHvyqAOD39zXI9zFVO7QwpCBFeLH/a+EQ/D24mbAnONORT TghoAiPXNo6izOkHW0dC88kqzHl+kt8UZtNrF1dE67tOZwLiaL9JwDNm6KNzofql7Z tVPp51ayDSkdw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lad Prabhakar , Claudiu Beznea , Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.8 257/715] arm64: dts: renesas: r9a08g045: Add missing interrupts to IRQC node Date: Sun, 24 Mar 2024 18:27:16 -0400 Message-ID: <20240324223455.1342824-258-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lad Prabhakar [ Upstream commit bf7e37716d995c54630c30540db5642f58ea037a ] The IRQC block on the RZ/G3S (R9A08G045) SoC supports ECCRAM error interrupts too. Add those missing interrupts to the IRQC node. Fixes: 837918aa3fdd ("arm64: dts: renesas: r9a08g045: Add IA55 interrupt co= ntroller node") Signed-off-by: Lad Prabhakar Reviewed-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20240205144421.51195-4-prabhakar.mahadev-la= d.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/renesas/r9a08g045.dtsi | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi b/arch/arm64/boot/d= ts/renesas/r9a08g045.dtsi index 5facfad961583..6315ffa6c1bb9 100644 --- a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi +++ b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi @@ -152,7 +152,10 @@ irqc: interrupt-controller@11050000 { , , , - ; + , + , + , + ; interrupt-names =3D "nmi", "irq0", "irq1", "irq2", "irq3", "irq4", "irq5", "irq6", "irq7", @@ -164,7 +167,8 @@ irqc: interrupt-controller@11050000 { "tint20", "tint21", "tint22", "tint23", "tint24", "tint25", "tint26", "tint27", "tint28", "tint29", "tint30", "tint31", - "bus-err"; + "bus-err", "ec7tie1-0", "ec7tie2-0", + "ec7tiovf-0"; clocks =3D <&cpg CPG_MOD R9A08G045_IA55_CLK>, <&cpg CPG_MOD R9A08G045_IA55_PCLK>; clock-names =3D "clk", "pclk"; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5F95016F910; Sun, 24 Mar 2024 22:39:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319952; cv=none; b=NTZNMRsVXSxNHwuAkVsYASPaDSCvZrCrW3tD74N/lfWFbjfMVxTKESj6T7jgr49OBbm0kijke1XjkTg9GooizZcBIJC89t408qRwg5Od2rtuuDzB+LRYdx9UJMMwchXXHn1oLtBsZgs+IV8hKJZwC9zG5SV9Zji7ekaGh34X4vQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319952; c=relaxed/simple; bh=Xr8kLLrVwgeoPlmaIABADrI/R7hOw5vbzs+NXDMVYOw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ehhMvj1VHFaTqxD8QStPhUFg5xBIh74CNdBviEQ2sDhg2qD1axWIe2t/Gztd6zWXt9Qd7ernQ/pveQ9h7MEG48vU10Nu5UeiNc8Jm4y9wjns1kyTGnkV2vYRqr1bvPUtom3yWgRXz1Fltub9ZLg+L9eWXcHLolXe9Icvr/DKCgM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kdVtbNoo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kdVtbNoo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 983E7C433A6; Sun, 24 Mar 2024 22:39:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319952; bh=Xr8kLLrVwgeoPlmaIABADrI/R7hOw5vbzs+NXDMVYOw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kdVtbNooXZqDUSJQ/PcW4kEBfIcJrWhI3Mqf4QSYbB1mVh3wPuPJglV0Zd1oWMbqf ipGn7upTCCS/264CUhevNHa7DNQGv/zJetLIUgyjExyWidly8bh72LqEGAORi+l97s 6V6j0NCc1zQlXGxQbY+jb2DTXDJ4ziBK3U7GNY49eAZpXYvR3OuKs31pmmbS3Ro2Lq VRFdDkwhighAN33f9+l0GXJ8NmCdWgwcddGi1rlfMkBkPUgesCE4tv5AcLxDq7NhkQ HN6pa/cHawxbFP2Zgc8ZnqJ2hPPy1yJ+S+dIs6/nbWvyPYpQDU5NSAqHrWKFP4PZFx x9TYyot9tWzgQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Claudiu Beznea , Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.8 258/715] arm64: dts: renesas: rzg3s-smarc-som: Guard Ethernet IRQ GPIO hogs Date: Sun, 24 Mar 2024 18:27:17 -0400 Message-ID: <20240324223455.1342824-259-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Claudiu Beznea [ Upstream commit 150d81f7a260f36c118cbec253fdd493c671dc29 ] Ethernet IRQ GPIOs are marked as GPIO hogs. Thus, these GPIOs are requested at probe time without considering if there are other peripherals that need them. The Ethernet IRQ GPIOs are shared with SDHI2. Selection between Ethernet and SDHI2 is done through a hardware switch. To avoid scenarios where one wants to boot with SDHI2 support and some SDHI pins are not propertly configured because of the GPIO hogs, guard the Ethernet IRQ GPIO hogs with the proper build flag. Fixes: 932ff0c802c6 ("arm64: dts: renesas: rzg3s-smarc-som: Enable the Ethe= rnet interfaces") Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20240208124300.2740313-13-claudiu.beznea.uj= @bp.renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi b/arch/arm64/= boot/dts/renesas/rzg3s-smarc-som.dtsi index f062d4ad78b79..d33ab4c887878 100644 --- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi +++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi @@ -193,12 +193,14 @@ &sdhi2 { #endif =20 &pinctrl { +#if SW_CONFIG3 =3D=3D SW_ON eth0-phy-irq-hog { gpio-hog; gpios =3D ; input; line-name =3D "eth0-phy-irq"; }; +#endif =20 eth0_pins: eth0 { txc { @@ -234,12 +236,14 @@ mux { }; }; =20 +#if SW_CONFIG3 =3D=3D SW_ON eth1-phy-irq-hog { gpio-hog; gpios =3D ; input; line-name =3D "eth1-phy-irq"; }; +#endif =20 eth1_pins: eth1 { txc { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 40BAE129E8C; Sun, 24 Mar 2024 22:39:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319953; cv=none; b=Dm4wcpNzs3O5QdBOBg6vAhwCsvDoOYEj4mGga4u5p/KrY63+kM80FphEkKm0ZJUYPuNq9lRA/84WTCb5NXdSdzuX9klKylHKLzOlizZPEHkitkKR16LIEbelZjGBN3ODZJRD4WcFUt6ZzvK9Dl1EQK9oa92VGoOz8liu8zkMrQE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319953; c=relaxed/simple; bh=58B98bGY5tMD2svD0Au4W1Qr/ZKoc4cnw7wxauTqbjE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Rf6yboOTFHWVkJyyFQda0aJJ0K1B53Jni+d2lAdcyD2+v5EvqHbpKXagd9FJ6z3EYusUopZaNiaaeFeRtFlUlt9I508D3miy6FSt7VIDDfCRQUYZpPCfIr7pzCBj+nD1fgJLLcxwKXAdhaL7JjZXIkpJs5cu1u4HZbRWK75YUhE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=C6rhIyMu; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="C6rhIyMu" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 885F0C43399; Sun, 24 Mar 2024 22:39:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319953; bh=58B98bGY5tMD2svD0Au4W1Qr/ZKoc4cnw7wxauTqbjE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=C6rhIyMusr/uE3RQY7dnt40RZZIeQOy/gamFqFqiK5/0c/7TrNpghEroeqUq6ViGn iaX9qLyhUxM83qop8f5E17bB6VTKF8Iif5R7itG0ngXOByOe4RS1gpsrPIt067lPSJ pOp3k9q37xKIhOcY1o4pS4n2QNvmHFu1O+12vxXMGObi4A02lT/0Hmr5gS4gH4OX6b vAiQrV88SPnVKvhdsEQkBQMICyGOAjgqgaWKw0LYhXLv8KnE+R63yMw4nTuNht4PHo 54LWyNcgNKVwbfrorcnmGc/CWCgf+G7spq9DQkVzctKvX9LisVUQ7USr72K+tNhehM 3OM21ZWPm1L+g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.8 259/715] arm64: dts: renesas: r8a779a0: Correct avb[01] reg sizes Date: Sun, 24 Mar 2024 18:27:18 -0400 Message-ID: <20240324223455.1342824-260-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Geert Uytterhoeven [ Upstream commit 0c51912331f8ba5ce5fb52f46e340945160672a3 ] All Ethernet AVB instances on R-Car V3U have registers related to UDP/IP support, but the declared register blocks for the first two instances are too small to cover them. Fix this by extending the register block sizes. Fixes: 5a633320f08b8c9b ("arm64: dts: renesas: r8a779a0: Add Ethernet-AVB s= upport") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/ce6ce3c4b1495e02e7c1803fca810a7178a84500.17= 07660323.git.geert+renesas@glider.be Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/renesas/r8a779a0.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/renesas/r8a779a0.dtsi b/arch/arm64/boot/dt= s/renesas/r8a779a0.dtsi index 4e67a03564971..504ac8c93faf5 100644 --- a/arch/arm64/boot/dts/renesas/r8a779a0.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a779a0.dtsi @@ -658,7 +658,7 @@ channel7 { avb0: ethernet@e6800000 { compatible =3D "renesas,etheravb-r8a779a0", "renesas,etheravb-rcar-gen4"; - reg =3D <0 0xe6800000 0 0x800>; + reg =3D <0 0xe6800000 0 0x1000>; interrupts =3D , , , @@ -706,7 +706,7 @@ avb0: ethernet@e6800000 { avb1: ethernet@e6810000 { compatible =3D "renesas,etheravb-r8a779a0", "renesas,etheravb-rcar-gen4"; - reg =3D <0 0xe6810000 0 0x800>; + reg =3D <0 0xe6810000 0 0x1000>; interrupts =3D , , , --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1D318170EC2; Sun, 24 Mar 2024 22:39:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319954; cv=none; b=NE3Ul/CFtHEAS/Jk63zzR3mtbRbZddQ0xs6KCI9RywWWDu04kNp4pwN2v2FSF3RVTfZDbLBpplFOG8Tzizw9Yz6EXuCEI1ZmiHCcl6B6eHGGthsXrDI1jq5HdjFt7FDBP30hYBqSmFU0kgCPYlWMvv9UlH6FlurtyLFhK6keuow= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319954; c=relaxed/simple; bh=hmQWRWL7arDI/JH7/+hDhSSggeI1GZPVqcl3qHGLP78=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LFBZj8VyVC4HXF0EDc/UxRuWPMthiUVWs1J5WZ3FYqIGh/Ls/5FjsmAXBxegUtdNrvEvw1gzkJTCA5IeEad6W2IHLRQdC7iUzQ3vNQRinGOpQnG6NHQsvVrk6NtnvIWVAJnqy64BKhUH5nVwZQPPs0dAjt4DYsZW9GbAEEfvWH4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OCK8DOwe; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OCK8DOwe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E6F8C433F1; Sun, 24 Mar 2024 22:39:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319953; bh=hmQWRWL7arDI/JH7/+hDhSSggeI1GZPVqcl3qHGLP78=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OCK8DOwecB+pSABbE/20CLJ8uFi7l1vATwCAlUZZFUQg92TpiXoUWDd+4c7Ai8WsH 9aXKPcBrNLPFoKMaQVfOMHSUtP9pJRswjA99yAcPTgqoAgMD7YjOqUnC4qPqIk45P2 syLfCDEovlnMPAXaJMZg932doyHPtWlovMFYhc1UDjRwEYIsSssIyS6nW1NnatW18G +Tw6bYGjY3pSRsL4cpNLcLGRBkVs5xoDAz7u8UFR4X6ZEeKht9H3tT6Pyvr8mDpD1J CZVYadhwRJRERV0LLbW+TzA64BLuW1LJuZu+D/66frb9/4ZpqIbK3L9O8KxgumGZxC DUcmquysfQuQQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.8 260/715] arm64: dts: renesas: r8a779g0: Correct avb[01] reg sizes Date: Sun, 24 Mar 2024 18:27:19 -0400 Message-ID: <20240324223455.1342824-261-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Geert Uytterhoeven [ Upstream commit 7edbb5880dc3317a5eaec2166de71ff394598e6b ] All Ethernet AVB instances on R-Car V4H have registers related to UDP/IP support, but the declared register blocks for the first two instances are too small to cover them. Fix this by extending the register block sizes. Fixes: 848c82db56923a8b ("arm64: dts: renesas: r8a779g0: Add RAVB nodes") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/83437778614a7c96f4d8f1be98dffeee29bb4a0b.17= 07660323.git.geert+renesas@glider.be Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dt= s/renesas/r8a779g0.dtsi index 0c83940b3d8a1..d7677595204dc 100644 --- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi @@ -767,7 +767,7 @@ channel7 { avb0: ethernet@e6800000 { compatible =3D "renesas,etheravb-r8a779g0", "renesas,etheravb-rcar-gen4"; - reg =3D <0 0xe6800000 0 0x800>; + reg =3D <0 0xe6800000 0 0x1000>; interrupts =3D , , , @@ -814,7 +814,7 @@ avb0: ethernet@e6800000 { avb1: ethernet@e6810000 { compatible =3D "renesas,etheravb-r8a779g0", "renesas,etheravb-rcar-gen4"; - reg =3D <0 0xe6810000 0 0x800>; + reg =3D <0 0xe6810000 0 0x1000>; interrupts =3D , , , --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7FFB117166F; Sun, 24 Mar 2024 22:39:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319955; cv=none; b=bLfUAnZKwIBbmTKt6sOROtA+Gt96OeJmAlscExEaMjpCLbhJ1uyHQ3SkkLpCuLANSo7gfIBmlci9t4JnytIcSyTvvR3nzzW+Bu1wPunaaoU9AE7XoAuPv7z9Ip1ilWwWTX9CyPenazTACoOtVB5A++MXhGO0z5NJk49qnBeQAzA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319955; c=relaxed/simple; bh=983g+75i0F3kiQCRwasLkkri3umIsFUdvvOJTOdXjMM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=p+VMo23CqJC2E4xSuyOO9gVAMqsQfxOXQbriD5UUUvP6Nq/xiGzPMMZg6kJpCFnxPiOeRToOzWOBTO8gC4gnp6nBNr0G/IQNf9tHXnrfi3Cm1oeysxnDL6vh9yo5nDz/UPIRAHI3ixQ42c2bAKRCg2p13NHRLvN6fiYubNA7/QI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pUWSHjh1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pUWSHjh1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32A2FC43390; Sun, 24 Mar 2024 22:39:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319954; bh=983g+75i0F3kiQCRwasLkkri3umIsFUdvvOJTOdXjMM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pUWSHjh1Ir4JtEewXa5YVzIwh5uKLbacbpyBSP6C9Fhv/usKFWjURQ4YBoKVESMUE QJrDy5ysyJcMO939JQM6mfb43vpIUdKoRpcgumcoej8sRf1ck9LDth+xIaL2l6XGcL oZfM/kma4Xn1a3mm/7FtnHW+24MSFWbPDxdJFdI+/oKO1GcYont4gYYinZuGkcR4jW xu/GIPALrfRTx4D0yo3RZBxd6MMDWwmkZt6ZVpXO2imTlFo0tvAncvHxaADpZOXYW/ XDS4p1AjDtcsJbvtanI1JoGPB1UgwWXH3BN/qlUi3p5ufULP7T4HJ5CLvv/+rOm7GU us5/Xas2dhaIw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jeremy Kerr , Jian Zhang , Paolo Abeni , Sasha Levin Subject: [PATCH 6.8 261/715] net: mctp: copy skb ext data when fragmenting Date: Sun, 24 Mar 2024 18:27:20 -0400 Message-ID: <20240324223455.1342824-262-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jeremy Kerr [ Upstream commit 1394c1dec1c619a46867ed32791a29695372bff8 ] If we're fragmenting on local output, the original packet may contain ext data for the MCTP flows. We'll want this in the resulting fragment skbs too. So, do a skb_ext_copy() in the fragmentation path, and implement the MCTP-specific parts of an ext copy operation. Fixes: 67737c457281 ("mctp: Pass flow data & flow release events to drivers= ") Reported-by: Jian Zhang Signed-off-by: Jeremy Kerr Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/core/skbuff.c | 8 ++++++++ net/mctp/route.c | 3 +++ 2 files changed, 11 insertions(+) diff --git a/net/core/skbuff.c b/net/core/skbuff.c index edbbef563d4d9..71dee435d549d 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -6736,6 +6736,14 @@ static struct skb_ext *skb_ext_maybe_cow(struct skb_= ext *old, for (i =3D 0; i < sp->len; i++) xfrm_state_hold(sp->xvec[i]); } +#endif +#ifdef CONFIG_MCTP_FLOWS + if (old_active & (1 << SKB_EXT_MCTP)) { + struct mctp_flow *flow =3D skb_ext_get_ptr(old, SKB_EXT_MCTP); + + if (flow->key) + refcount_inc(&flow->key->refs); + } #endif __skb_ext_put(old); return new; diff --git a/net/mctp/route.c b/net/mctp/route.c index ceee44ea09d97..01c530dbc1a65 100644 --- a/net/mctp/route.c +++ b/net/mctp/route.c @@ -843,6 +843,9 @@ static int mctp_do_fragment_route(struct mctp_route *rt= , struct sk_buff *skb, /* copy message payload */ skb_copy_bits(skb, pos, skb_transport_header(skb2), size); =20 + /* we need to copy the extensions, for MCTP flow data */ + skb_ext_copy(skb2, skb); + /* do route */ rc =3D rt->output(rt, skb2); if (rc) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 11F9A171E43; Sun, 24 Mar 2024 22:39:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319956; cv=none; b=VtQPyyHXcaJopMxSkcUasQ7f12li3ABdJ4GTo2CgkgOnLT/d3ggsVYqDLTTCRmvUrPF84eBFBsFXAixoDtKq3zM7Lm0F7jQLsWNJQ5gG1krCZCWXGe2IjzpdxHy/hUoIpWjtMkA8KiCggFdG0iwy7igNM7avR28+PtpZGcWs7JE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319956; c=relaxed/simple; bh=3ROeb6f/oWDvJLS5zUVN+VKwhzwBKnpR4YsCgI+SwU4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=jNM1vWECROnQqx4uCbCKjr+NvWKSOA3D3eC8ZPw0YVRijxkrE8bV9wpo1IQgib17wk+xrOc7YwnZRrYBYBeFKdYiCjNQY3Upq/iORFy+Dg5GLaiDBVoNRzwghxD5jhzswsPPDWYF3Sg5lpbIZNiLwlVRvkMgxZzGgHuVS10h6Ak= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QoQXtTrs; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QoQXtTrs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34226C43394; Sun, 24 Mar 2024 22:39:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319955; bh=3ROeb6f/oWDvJLS5zUVN+VKwhzwBKnpR4YsCgI+SwU4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QoQXtTrsagw2AfgSnoN6aZIhyWYS3P04nASwrZXpJhpQkquhQMMFusnaujJFRj10x 6ed1a3/g93OaBO4I23OokJRGoTXrCG/IW0/9Hzm3U3ujmMz/JROQHCLRVgUTQSltf/ A1+ss5Qo2LfMsZJ8OUdBKaAv+IV8ZK6e7TcT2BFt33b1vOTjULwba9ZLv5ZJM9pcHi 7Rezr0kNnnaXtbz+kmfdczdvdFtNnKKst1TQpJCEfWK/QSiJxbJuP7Ph+Se/gWm65/ iutAMB/PlR/eVF6BI+D1l3kM359ryfKg4kp6G3Mrbz5DhO2HbLK4fnXF5yB94umihC +9/DTl6cWbBLA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kees Cook , Alexander Viro Subject: [PATCH 6.8 262/715] pstore: inode: Only d_invalidate() is needed Date: Sun, 24 Mar 2024 18:27:21 -0400 Message-ID: <20240324223455.1342824-263-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kees Cook [ Upstream commit a43e0fc5e9134a46515de2f2f8d4100b74e50de3 ] Unloading a modular pstore backend with records in pstorefs would trigger the dput() double-drop warning: WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410 Using the combo of d_drop()/dput() (as mentioned in Documentation/filesystems/vfs.rst) isn't the right approach here, and leads to the reference counting problem seen above. Use d_invalidate() and update the code to not bother checking for error codes that can never happen. Suggested-by: Alexander Viro Fixes: 609e28bb139e ("pstore: Remove filesystem records when backend is unr= egistered") Signed-off-by: Kees Cook Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- fs/pstore/inode.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c index d0d9bfdad30cc..56815799ce798 100644 --- a/fs/pstore/inode.c +++ b/fs/pstore/inode.c @@ -307,7 +307,6 @@ int pstore_put_backend_records(struct pstore_info *psi) { struct pstore_private *pos, *tmp; struct dentry *root; - int rc =3D 0; =20 root =3D psinfo_lock_root(); if (!root) @@ -317,11 +316,8 @@ int pstore_put_backend_records(struct pstore_info *psi) list_for_each_entry_safe(pos, tmp, &records_list, list) { if (pos->record->psi =3D=3D psi) { list_del_init(&pos->list); - rc =3D simple_unlink(d_inode(root), pos->dentry); - if (WARN_ON(rc)) - break; - d_drop(pos->dentry); - dput(pos->dentry); + d_invalidate(pos->dentry); + simple_unlink(d_inode(root), pos->dentry); pos->dentry =3D NULL; } } @@ -329,7 +325,7 @@ int pstore_put_backend_records(struct pstore_info *psi) =20 inode_unlock(d_inode(root)); =20 - return rc; + return 0; } =20 /* --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3F258171E6D; Sun, 24 Mar 2024 22:39:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319957; cv=none; b=c2NTHh4xrMFixFu5BMuwAp8aSDVmvyJf4TrWVjli8EImzCNWOFoAwGpgFkxGrIDu50Zu3Xws8sXYnkMUSWE53WvPOHyNyCv+bY2rkMsexqiK14N6nTgS9pGujIgNGu5Zwy0uHL+c6/761P3m+1+JGPdCq/gaESUyhp/VFU5TN6s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319957; c=relaxed/simple; bh=PSfaJaGHfeh9RYxvNOEV3FNhCqWgQCV/Di0zLdoOfeM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Hi53VkEsuRisT0jLxe/i+0OgE+2K33XdDagXbo19EiDd7+e1rl0ctcDz23yscTDTF6oIiqc+vdRjZwdkNGY+Rh8bDkfwfhtm2Fiu4igwN7lPcV+eEjMtg2xcwBdcNvCHoSSSDUtyzOjn+6PCsrAJ+TaXS/wdoK8zOgxZvzyq+sQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=c5XBNmww; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="c5XBNmww" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 05496C433A6; Sun, 24 Mar 2024 22:39:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319956; bh=PSfaJaGHfeh9RYxvNOEV3FNhCqWgQCV/Di0zLdoOfeM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=c5XBNmww75W2Lkl/E6NK+LmmFY9UYqDSxQk2n2yJ44lgtAUTHaF3gjV7CIeKgQWGu w16R3Cb3GAUVITSUPbCldUNfWIZyfzbzMKafIlvlLIUN6dDYjyhzgHe+Gwj6cYZOAT e8ZwXrcARFjOG1cJrFZmINP4/rRGhQOBzjK/KEW5TEMSW2cH0B9Al4SqGIAIMstop4 b7uYKK+afXKTa28iGaJCcEV+rz4AvXosKJo58DMqrRl6IQlQEqwa1Vv9c0lo5rGYhc jFbqAu1kVAMcGTd5UOLqoL0vvEn9P3iIfyhyJcnBjdR6+M2zTWx3yRwQ/Z6GfhMcde ejVFewfbOIZ0A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chen-Yu Tsai , Andre Przywara , Jernej Skrabec , Sasha Levin Subject: [PATCH 6.8 263/715] arm64: dts: allwinner: h6: Add RX DMA channel for SPDIF Date: Sun, 24 Mar 2024 18:27:22 -0400 Message-ID: <20240324223455.1342824-264-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chen-Yu Tsai [ Upstream commit 7b59348c11f3355e284d77bbe3d33632ddadcfc2 ] The SPDIF hardware found on the H6 supports both transmit and receive functions. However it is missing the RX DMA channel. Add the SPDIF hardware block's RX DMA channel. Also remove the by-default pinmux, since the end device can choose to implement either or both functionalities. Fixes: f95b598df419 ("arm64: dts: allwinner: Add SPDIF node for Allwinner H= 6") Signed-off-by: Chen-Yu Tsai Reviewed-by: Andre Przywara Reviewed-by: Jernej Skrabec Link: https://lore.kernel.org/r/20240127163247.384439-6-wens@kernel.org Signed-off-by: Jernej Skrabec Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 2 ++ arch/arm64/boot/dts/allwinner/sun50i-h6-tanix.dtsi | 2 ++ arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 7 +++---- 3 files changed, 7 insertions(+), 4 deletions(-) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts b/arch= /arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts index 9ec49ac2f6fd5..381d58cea092d 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts @@ -291,6 +291,8 @@ sw { }; =20 &spdif { + pinctrl-names =3D "default"; + pinctrl-0 =3D <&spdif_tx_pin>; status =3D "okay"; }; =20 diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix.dtsi b/arch/arm6= 4/boot/dts/allwinner/sun50i-h6-tanix.dtsi index 4903d6358112d..855b7d43bc503 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-tanix.dtsi @@ -166,6 +166,8 @@ &r_ir { }; =20 &spdif { + pinctrl-names =3D "default"; + pinctrl-0 =3D <&spdif_tx_pin>; status =3D "okay"; }; =20 diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot= /dts/allwinner/sun50i-h6.dtsi index ca1d287a0a01d..d11e5041bae9a 100644 --- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi @@ -406,6 +406,7 @@ spi1_cs_pin: spi1-cs-pin { function =3D "spi1"; }; =20 + /omit-if-no-ref/ spdif_tx_pin: spdif-tx-pin { pins =3D "PH7"; function =3D "spdif"; @@ -655,10 +656,8 @@ spdif: spdif@5093000 { clocks =3D <&ccu CLK_BUS_SPDIF>, <&ccu CLK_SPDIF>; clock-names =3D "apb", "spdif"; resets =3D <&ccu RST_BUS_SPDIF>; - dmas =3D <&dma 2>; - dma-names =3D "tx"; - pinctrl-names =3D "default"; - pinctrl-0 =3D <&spdif_tx_pin>; + dmas =3D <&dma 2>, <&dma 2>; + dma-names =3D "rx", "tx"; status =3D "disabled"; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D92E1170EB3; Sun, 24 Mar 2024 22:39:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319958; cv=none; b=TsEoOscRs9UslZKRHyyPKPy8OZLJ2fwGIZ3qTfki367I1ptq5Ae7zfVyzkHPyHgSJUfUe3X0Wt5sD7JY1y/G2foQ/e9JOJEHKJhGwgipC+xHHo/hidxtaJPwatHNtt7iT8H5xeIuw4ydzdXNQiNUKrBoBF1LzELiwHkVy9cJ994= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319958; c=relaxed/simple; bh=ND4MKUcYcMyYShL2dADwCd1T3/24PLG/95Zp8DoRkb4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=mBMmO0MgxKz5u92Qf//ZgMmwzLimkq7ZlFyqC71RuDTw6fYGGLefB1Y5tDvmOcsF6EDSLSTFtFEc+uL5xG5Qjp7J+K4fEculKP+EbwzrRc2sTW+FUebJw9MI7w/MiSn/T930n0NWjY0+oqgworE2QA6Eh1rCxJMS9DPDG+r+cKE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Emm9MP/I; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Emm9MP/I" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 072FFC433F1; Sun, 24 Mar 2024 22:39:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319957; bh=ND4MKUcYcMyYShL2dADwCd1T3/24PLG/95Zp8DoRkb4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Emm9MP/IVNvCFCvnp0en5qvVST+bgm5J4FT7VTMiuNSqGfdjSe4Zx5iBMLehEvx7W 56cWmtTaFiZh1lhYdrscG56TMKwr9j8oBSJTKbPbrjkwEoqQZzOxt7aagCpIu/iqZq 2+Ca3uBMk0h02YkYoMNulXauASrwoRbhogP1cY5im/ekEw36d+AGfA4ZkPu1wcdd9U lxkNu2VX54A2Kj0W3NVLGFvjzaFE8GFZOKEE5L/aCVE5Nd/3CXK2IJFB4UzVK1fZLB gE1uKQWyzK75JuBy89HMbeLdSMibcAcNVsqF8/LSXiSaNYaBaBt0TKMgtAjUR9YcFQ 7PK6YKyRHTu2w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Michal=20Vok=C3=A1=C4=8D?= , Andrew Lunn , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 264/715] ARM: dts: imx6dl-yapp4: Fix typo in the QCA switch register address Date: Sun, 24 Mar 2024 18:27:23 -0400 Message-ID: <20240324223455.1342824-265-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Michal Vok=C3=A1=C4=8D [ Upstream commit 023bd910d3ab735459f84b22bb99fb9e00bd9d76 ] This change does not have any functional effect. The switch works just fine without this patch as it has full access to all the addresses on the bus. This is simply a clean-up to set the node name address and reg address to the same value. Fixes: 15b43e497ffd ("ARM: dts: imx6dl-yapp4: Use correct pseudo PHY addres= s for the switch") Signed-off-by: Michal Vok=C3=A1=C4=8D Reviewed-by: Andrew Lunn Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm/boot/dts/nxp/imx/imx6dl-yapp4-common.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-yapp4-common.dtsi b/arch/arm/= boot/dts/nxp/imx/imx6dl-yapp4-common.dtsi index 3be38a3c4bb11..d2b3e09eb7df8 100644 --- a/arch/arm/boot/dts/nxp/imx/imx6dl-yapp4-common.dtsi +++ b/arch/arm/boot/dts/nxp/imx/imx6dl-yapp4-common.dtsi @@ -127,7 +127,7 @@ phy_port3: phy@2 { =20 switch@10 { compatible =3D "qca,qca8334"; - reg =3D <10>; + reg =3D <0x10>; reset-gpios =3D <&gpio1 25 GPIO_ACTIVE_LOW>; =20 switch_ports: ports { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C6EA5172635; Sun, 24 Mar 2024 22:39:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319958; cv=none; b=b950t6KY73cTw6OsYo5dpMAVQdq3v1PfFYdtL+C35AnWW6YsLMkn1Y9Bg1hQTCg6a8wePQHD02gvbYFB/T3j+ljuBe3jc0w6hHb47n+r/cfwXRtRerI08j2elR4R2FT7GEaNTwX0kpxKetOsUi/aKhi4wGiEuKCrSLz2Nv9c/8M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319958; c=relaxed/simple; bh=qDdkBp52whbIdsEQJeQ73Fo2VF9QAYIUfc9LlJxEzNg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YW1aAUOWy3k8KTHThpZwDiFaf6wcvS9qsbYIwb8qqUB6mutRsgaPLPDBBo0JXuSvVTqoL1jf3Vi5GqwYtGwSoZ3sSlqSsYhZ316ogtZPUQcwv9DmmzTLhLxwJDK8MRaVNAi4LxeX7UwNJURsGG+iAyjIJ7pXVyl6oSRS4Wtw0vY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rPa9t2tK; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rPa9t2tK" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DFFAC433C7; Sun, 24 Mar 2024 22:39:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319958; bh=qDdkBp52whbIdsEQJeQ73Fo2VF9QAYIUfc9LlJxEzNg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rPa9t2tKJr0nhCbPYgHzAS57oK111cezEV4sOEMkTIThMvXmdE1sYpZBv3Q3pflc1 XlPkFgf8xWIEDchuFOCaw9z5OX4eFfbpmLckFBVdx0Sw1Rz+ZuijsfAyMnqIhsaR9m 4DxhpZMBBS9YCw55Ua7hmoiOJOZlSlsi2mDXpIMdIe6Qdak4r2mHu911ATjXM5GzKz yoQ7VlDMDFG63VWo6EDa4WB5YK62fB8oPHUB6lZImzfVrOfTFRqTDn41lxOfdu6E5u MhQiiWw8WilEoZFnaLAlrr/bKUAU2rSGzYS7WAJ7cuL7OGke2FvUd7Jpjxxy1ybICa gwW6tDNtxzXrQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Michal=20Vok=C3=A1=C4=8D?= , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 265/715] ARM: dts: imx6dl-yapp4: Move the internal switch PHYs under the switch node Date: Sun, 24 Mar 2024 18:27:24 -0400 Message-ID: <20240324223455.1342824-266-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Michal Vok=C3=A1=C4=8D [ Upstream commit 79978bff2e4b8e05ebdf5fc3ee6b794002393484 ] We identified that the PHYs actually do not work since commit 7da7b84fee58 ("ARM: dts: imx6dl-yapp4: Move phy reset into switch node") as a coincidence of several circumstances. The reset signal is kept asserted by a pull-down resistor on the board unless it is deasserted by GPIO from the SoC. This is to keep the switch dead until it is configured properly by the kernel and user space. Prior to the referenced commit the switch was reset by the FEC driver and the reset GPIO was actively deasserted. The mdio-bus was scanned and the attached switch and its PHYs were found and configured. With the referenced commit the switch is reset by the qca8k driver. Because of another bug in the qca8k driver, functionality of the reset pin depends on its pre-kernel configuration. See commit c44fc98f0a8f ("net: dsa: qca8k: fix illegal usage of GPIO") The problem did not appear until we removed support for the switch and configuration of its reset pin from the bootloader. To fix that, properly describe the internal mdio-bus configuration of the qca8334 switch. The PHYs are internal to the switch and sit on its internal mdio-bus. Fixes: 7da7b84fee58 ("ARM: dts: imx6dl-yapp4: Move phy reset into switch no= de") Signed-off-by: Michal Vok=C3=A1=C4=8D Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../boot/dts/nxp/imx/imx6dl-yapp4-common.dtsi | 23 ++++++++++++------- 1 file changed, 15 insertions(+), 8 deletions(-) diff --git a/arch/arm/boot/dts/nxp/imx/imx6dl-yapp4-common.dtsi b/arch/arm/= boot/dts/nxp/imx/imx6dl-yapp4-common.dtsi index d2b3e09eb7df8..c32ea040fecdd 100644 --- a/arch/arm/boot/dts/nxp/imx/imx6dl-yapp4-common.dtsi +++ b/arch/arm/boot/dts/nxp/imx/imx6dl-yapp4-common.dtsi @@ -117,14 +117,6 @@ mdio { #address-cells =3D <1>; #size-cells =3D <0>; =20 - phy_port2: phy@1 { - reg =3D <1>; - }; - - phy_port3: phy@2 { - reg =3D <2>; - }; - switch@10 { compatible =3D "qca,qca8334"; reg =3D <0x10>; @@ -149,15 +141,30 @@ fixed-link { eth2: port@2 { reg =3D <2>; label =3D "eth2"; + phy-mode =3D "internal"; phy-handle =3D <&phy_port2>; }; =20 eth1: port@3 { reg =3D <3>; label =3D "eth1"; + phy-mode =3D "internal"; phy-handle =3D <&phy_port3>; }; }; + + mdio { + #address-cells =3D <1>; + #size-cells =3D <0>; + + phy_port2: ethernet-phy@1 { + reg =3D <1>; + }; + + phy_port3: ethernet-phy@2 { + reg =3D <2>; + }; + }; }; }; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1572C172BA0; Sun, 24 Mar 2024 22:39:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319960; cv=none; b=mI075z/Jq2dJOnMAD+6A5Y7XycshMQ8h1Lecr8bVSLwwbn/NSADrrtpowkiEPUiKKGc7D4hdc0k6BqRzF5LUEbCcBfzFsOqxZyCKnvrYMYaBA78hH+nvLeE/5BSv4ge4pkqobOqwgcNM73o5UO+hZ4IzGBN/8mcs9bUNLJNNlLI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319960; c=relaxed/simple; bh=+I604YvrVbmBP/fR3nTzqZgyNQVHXkAtJ9TyLm1Qv1I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JaSG1GM9j/GRNBb5xjGkL+JpxfnewdDxuQeSun60J2GVBuuxQdwVva6U3Wxun6lOgsoXNQwBGeFDFWxnPjVLG2ef8qQkDX3l29SIw74uxPejXv/Hm/pTYPTz5CbMyAes/l4NMPisZBtR1OteLl2XYK2ep7KGxxK4PKJbq3dd6fg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rgLLEx3x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rgLLEx3x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EEC79C433F1; Sun, 24 Mar 2024 22:39:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319959; bh=+I604YvrVbmBP/fR3nTzqZgyNQVHXkAtJ9TyLm1Qv1I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rgLLEx3x+fIsFzjvQHaxeVNVAsVIbli3vRIQ06zyled5OH10upNjeUCKB6bc1z2Z8 7FjmCA2ExFzgIu6LP1YYIVjfxtvJfjfuJufCI3GYV91HK69qQ+oJqYsVBHWmnvU4pz O4z5ODMBhfqBZ8RkJj6Q/JyRLDOs9dbwkM+R5BFQDUvoOmVbAFIvD7b+WZ6j6W65Wk Ppzo69wFjAoBL+mgugPTAX1kqIuhppHx4n3f4c3yu/dEqsvW23XQoHRgLorJIg5BeE /j7sOw6dlIIuGW3p2stbgfsnvpzGJvBLHMb6crNyLVTczFjTYnxu+gsfrMztiJpvCn rSQScU5pL/SZA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Marek Vasut , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 266/715] arm64: dts: imx8mp: Set SPI NOR to max 40 MHz on Data Modul i.MX8M Plus eDM SBC Date: Sun, 24 Mar 2024 18:27:25 -0400 Message-ID: <20240324223455.1342824-267-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Marek Vasut [ Upstream commit 13ab6f174a6b577bd7d09124b47ec8ace2682e42 ] The SPI NOR bus routing on this board cannot go above 50 MHz, set the clock frequency to maximum of 40 MHz to be within a safe margin. Remove the comment as well. Fixes: 562d222f23f0 ("arm64: dts: imx8mp: Add support for Data Modul i.MX8M= Plus eDM SBC") Signed-off-by: Marek Vasut Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts b/= arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts index 5828c9d7821de..b5ce7b14b5434 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-data-modul-edm-sbc.dts @@ -121,7 +121,7 @@ &ecspi1 { flash@0 { /* W25Q128JVEI */ compatible =3D "jedec,spi-nor"; reg =3D <0>; - spi-max-frequency =3D <100000000>; /* Up to 133 MHz */ + spi-max-frequency =3D <40000000>; spi-tx-bus-width =3D <1>; spi-rx-bus-width =3D <1>; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A6511172BB3; Sun, 24 Mar 2024 22:39:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319960; cv=none; b=E0LumgYKIt1KgPXlvH7xd1Vlu+1fJpHxkIh+IL3PBQ8LHzSV19KM7Vqdzxc8OAYBWpy/9c3oaLHiP4mYWTr99KU0zEtesLefwZuKuLPCMVMwbrvNlSki96VUaSoboSH2bu1nZIWQMbMEoufftuBbxcIy2Nq+j/FnI8ggJuUQhoI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319960; c=relaxed/simple; bh=im1qitA3y3Fjmo4eLlVmZm8/7y/SC+50O7yYIeNO5Wk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Bs7N82Q32Eu5hISPOxwitbmPAAf6vt9CW+PqUeBVXzX/4Mr/XagdIN5hsXUEgWUB422Ovx+eHl/EOHCKhVEDJG+n7dCCewvdwVmbiD7aMbGyeFApKPYP9EkFi9a62i0IOV6KOaaj8ahMbPIONQftNa93B4tDZPa83DpCd+khp1s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bNJ8fgo9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bNJ8fgo9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB42FC43390; Sun, 24 Mar 2024 22:39:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319960; bh=im1qitA3y3Fjmo4eLlVmZm8/7y/SC+50O7yYIeNO5Wk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bNJ8fgo9jq2gR6Yfhe/D1d92VvEi8fXIr5G3YnzWqQGnAdTxdJc98fbgAJWcDxZGJ veo0BTU0nI+PtEMZZ4MeQZo37PCyK+hccdVunerN7LtTjWopX/1kINPCXITGCylN7i ucw/NNU72H59PQXwdZq6hHk4rznPqWZUNpKklpBUDWrf5hF84K2bea30oieZIAEAJV 1hd4+Rz3rvcKqIfdltjufyXEt+GOVJeFBwP4K6mALccFPBn7LC++8PIgBMCQlCdRQX CBwq9nULDJ4K+MvxCzStnBsHIbVLBZEOoKXjE8q99PNhTxnx4IhgTRriSABxxZqdJr FVRHylA83KysQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Liu Ying , Shawn Guo , Sasha Levin Subject: [PATCH 6.8 267/715] arm64: dts: imx8mp-evk: Fix hdmi@3d node Date: Sun, 24 Mar 2024 18:27:26 -0400 Message-ID: <20240324223455.1342824-268-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Liu Ying [ Upstream commit 0ff08803eca417dfa9372194bebf3d1b1f501f98 ] The hdmi@3d node's compatible string is "adi,adv7535" instead of "adi,adv7533" or "adi,adv751*". Fix the hdmi@3d node by means of: * Use default register addresses for "cec", "edid" and "packet", because there is no need to use a non-default address map. * Add missing interrupt related properties. * Drop "adi,input-*" properties which are only valid for adv751*. * Add VEXT_3V3 fixed regulator. * Add "*-supply" properties, since most are required. * Fix label names - s/adv7533/adv7535/. Fixes: 65344b9bed3a ("arm64: dts: imx8mp-evk: Add HDMI support") Signed-off-by: Liu Ying Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 33 +++++++++++++------- 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts b/arch/arm64/boot= /dts/freescale/imx8mp-evk.dts index f87fa5a948ccc..9beba8d6a0dfe 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-evk.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk.dts @@ -23,7 +23,7 @@ hdmi-connector { =20 port { hdmi_connector_in: endpoint { - remote-endpoint =3D <&adv7533_out>; + remote-endpoint =3D <&adv7535_out>; }; }; }; @@ -107,6 +107,13 @@ reg_usdhc2_vmmc: regulator-usdhc2 { enable-active-high; }; =20 + reg_vext_3v3: regulator-vext-3v3 { + compatible =3D "regulator-fixed"; + regulator-name =3D "VEXT_3V3"; + regulator-min-microvolt =3D <3300000>; + regulator-max-microvolt =3D <3300000>; + }; + sound { compatible =3D "simple-audio-card"; simple-audio-card,name =3D "wm8960-audio"; @@ -364,7 +371,7 @@ BUCK4 { regulator-always-on; }; =20 - BUCK5 { + reg_buck5: BUCK5 { regulator-name =3D "BUCK5"; regulator-min-microvolt =3D <1650000>; regulator-max-microvolt =3D <1950000>; @@ -415,14 +422,16 @@ &i2c2 { =20 hdmi@3d { compatible =3D "adi,adv7535"; - reg =3D <0x3d>, <0x3c>, <0x3e>, <0x3f>; - reg-names =3D "main", "cec", "edid", "packet"; + reg =3D <0x3d>; + interrupt-parent =3D <&gpio1>; + interrupts =3D <9 IRQ_TYPE_EDGE_FALLING>; adi,dsi-lanes =3D <4>; - adi,input-depth =3D <8>; - adi,input-colorspace =3D "rgb"; - adi,input-clock =3D "1x"; - adi,input-style =3D <1>; - adi,input-justification =3D "evenly"; + avdd-supply =3D <®_buck5>; + dvdd-supply =3D <®_buck5>; + pvdd-supply =3D <®_buck5>; + a2vdd-supply =3D <®_buck5>; + v3p3-supply =3D <®_vext_3v3>; + v1p2-supply =3D <®_buck5>; =20 ports { #address-cells =3D <1>; @@ -431,7 +440,7 @@ ports { port@0 { reg =3D <0>; =20 - adv7533_in: endpoint { + adv7535_in: endpoint { remote-endpoint =3D <&dsi_out>; }; }; @@ -439,7 +448,7 @@ adv7533_in: endpoint { port@1 { reg =3D <1>; =20 - adv7533_out: endpoint { + adv7535_out: endpoint { remote-endpoint =3D <&hdmi_connector_in>; }; }; @@ -524,7 +533,7 @@ port@1 { reg =3D <1>; =20 dsi_out: endpoint { - remote-endpoint =3D <&adv7533_in>; + remote-endpoint =3D <&adv7535_in>; data-lanes =3D <1 2 3 4>; }; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 88253172BD4; Sun, 24 Mar 2024 22:39:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319961; cv=none; b=XIZEkYEYqTKHYKmS5waHJ8IUvxy0RQq68ee0O/UsBfBy9FUyoIbV6Tqa/cbqJBdibJherSZIR6fzaF3vu+oFf1SBkM0/ngxv3R5Q1m1+AiK2BHGz/9sMSPfLROHQeKj+tFcQsNs7pZhaUL8T1IIRASrtJHfK0mGGlM/Td6qk6hE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319961; c=relaxed/simple; bh=yEacVUk4vPPXTEet/MLxzVr9gJMeEgue7ybvIiF3cPQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tQ7OuVsx0MjfYnZ4wEuq2FKVhrGfZ57+X2QdvaojHT4GrnVU1G9+tGoDPCJw5roLBOq4Ctjywm8Dav+7N5+Att/9rKbv31/nYX5tzXFFaMRbcceLbU4yrQu74cnLkAfD56iFhO941ETSpc7CnG03EDf+LHq25QCP3+m8jo8EK+8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QwFXP7xa; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QwFXP7xa" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C53B9C43394; Sun, 24 Mar 2024 22:39:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319961; bh=yEacVUk4vPPXTEet/MLxzVr9gJMeEgue7ybvIiF3cPQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QwFXP7xaFxy0OqIVypzMtO0QmLzEAX7jWBxP4wWh098cJSg1i9/xIKH/CNNJAFYIV 4gurepvXVYe07fWoq+4/Pp6vm8/Zcgmc3hZkv2XzT9LixxyLYr+1X7761s3n69vy9J 2mzHftJJJFNjGiCbqEh9YSZ/NovSWLfbuNWX+gPw0M+Rxc9uShLgzFCYE242+TFEzc zjv4VV/46bI+7AJRT200/DxE1hx2A7DYlP9Uj7WasWuMfTKaF7a0+I42r26IDMBiWS CXwuZBqDUDZu6BTPheTach3Xrx33ywJdFagWs4dQmxfPw6mGPNBodZ9XHP1qaut80g UObqz6QcWuDlg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: John Keeping , Mark Brown , Sasha Levin Subject: [PATCH 6.8 268/715] regulator: userspace-consumer: add module device table Date: Sun, 24 Mar 2024 18:27:27 -0400 Message-ID: <20240324223455.1342824-269-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: John Keeping [ Upstream commit 531a0c0cdbff9cecf41073220a826f8b1132f9ab ] The userspace consumer can be built as a module but it cannot be automatically probed as there is no device table to match it up with device tree nodes. Add the missing macro so that the module can load automatically. Fixes: 5c51d4afcf3fd ("regulator: userspace-consumer: Handle regulator-outp= ut DT nodes") Signed-off-by: John Keeping Link: https://msgid.link/r/20240226160554.1453283-1-jkeeping@inmusicbrands.= com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/regulator/userspace-consumer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/regulator/userspace-consumer.c b/drivers/regulator/use= rspace-consumer.c index 53d1b9d6f69c5..86a626a4f610a 100644 --- a/drivers/regulator/userspace-consumer.c +++ b/drivers/regulator/userspace-consumer.c @@ -208,6 +208,7 @@ static const struct of_device_id regulator_userspace_co= nsumer_of_match[] =3D { { .compatible =3D "regulator-output", }, {}, }; +MODULE_DEVICE_TABLE(of, regulator_userspace_consumer_of_match); =20 static struct platform_driver regulator_userspace_consumer_driver =3D { .probe =3D regulator_userspace_consumer_probe, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9783817332C; Sun, 24 Mar 2024 22:39:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319962; cv=none; b=nEjo+j3bwZM5ES/AIiraZvlGY5KXI1E6dVQyu2UFjQC8/awiz5C3T6R57d7rnActUY+bbrrMVr1T8Mn+tWGZfLjU3YGHiWvG2ArpYMxWL8/xavgfZ/Bgpa/Ouifp7Q/GRPOEFeS0gABJs2GkOcnQqfeYoo8rY/ZEewf3jmnmKe4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319962; c=relaxed/simple; bh=05gqi39uXIlBRnhdZDnAky2RW2b2mzwYsIck1TaCRx8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I1NxqoTM2KLvcNEwh0MNlaayU9x1OzqXXo0sgGbgKQru//BLJWLDKh8ZzsJLUpSPDyl9Wi1ohnMnitSQmYUvpN++VKJw3eVfwf372x+n24Uc2QrDdYApoMIk5oUEuTIpAzOapLFeeYD77Ij0vkbgN0gQQZH92bM5wIzReIoMcQM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BQZxqLix; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BQZxqLix" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AED0DC43390; Sun, 24 Mar 2024 22:39:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319962; bh=05gqi39uXIlBRnhdZDnAky2RW2b2mzwYsIck1TaCRx8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BQZxqLixT/BEUvI6lGdCGofCH9fwhEbJfYdKAIpb1ymrQ4LYohT0IaiLKPYElzdFP +UxBKhpCxzQAtPwOIDeBp8jtiYNDEjXOOWvpcPfkgLy7gpydulZNxyqPa2rO6FhOAI bdvaJ58Wruj/GgWkCZarCb1QwBxMlg9lSRAo35B7FOK5wXeivOdqFE4HWB6s7XCRLC ZGfmlMELqnoXS9X92mQhK5zvQX9RMJuJJXypwXDzwia3zFj2JWi/wLLf3ZjCHIFEHS wK5/rBM7xHPB+DQHsvImhi87z3lqyMTqZbzRfQVi2UNSbJ+Kg7hDRGpA6j8WyGg8lh Tc8yrq+FCrLDQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Stephen Boyd , Dmitry Torokhov , Bartosz Golaszewski , Sasha Levin Subject: [PATCH 6.8 269/715] gpiolib: Pass consumer device through to core in devm_fwnode_gpiod_get_index() Date: Sun, 24 Mar 2024 18:27:28 -0400 Message-ID: <20240324223455.1342824-270-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Stephen Boyd [ Upstream commit 0d776cfd5e5b559fdf2e38285c2aea4b7048acbd ] This devm API takes a consumer device as an argument to setup the devm action, but throws it away when calling further into gpiolib. This leads to odd debug messages like this: (NULL device *): using DT '/gpio-keys/switch-pen-insert' for '(null)' GPIO= lookup Let's pass the consumer device down, by directly calling what fwnode_gpiod_get_index() calls but pass the device used for devm. This changes the message to look like this instead: gpio-keys gpio-keys: using DT '/gpio-keys/switch-pen-insert' for '(null)' = GPIO lookup Note that callers of fwnode_gpiod_get_index() will still see the NULL device pointer debug message, but there's not much we can do about that because the API doesn't take a struct device. Cc: Dmitry Torokhov Fixes: 8eb1f71e7acc ("gpiolib: consolidate GPIO lookups") Signed-off-by: Stephen Boyd Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpio/gpiolib-devres.c | 2 +- drivers/gpio/gpiolib.c | 14 +++++++------- drivers/gpio/gpiolib.h | 8 ++++++++ 3 files changed, 16 insertions(+), 8 deletions(-) diff --git a/drivers/gpio/gpiolib-devres.c b/drivers/gpio/gpiolib-devres.c index fe9ce6b19f15c..4987e62dcb3d1 100644 --- a/drivers/gpio/gpiolib-devres.c +++ b/drivers/gpio/gpiolib-devres.c @@ -158,7 +158,7 @@ struct gpio_desc *devm_fwnode_gpiod_get_index(struct de= vice *dev, if (!dr) return ERR_PTR(-ENOMEM); =20 - desc =3D fwnode_gpiod_get_index(fwnode, con_id, index, flags, label); + desc =3D gpiod_find_and_request(dev, fwnode, con_id, index, flags, label,= false); if (IS_ERR(desc)) { devres_free(dr); return desc; diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 75be4a3ca7f84..3ad09d2193330 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -4138,13 +4138,13 @@ static struct gpio_desc *gpiod_find_by_fwnode(struc= t fwnode_handle *fwnode, return desc; } =20 -static struct gpio_desc *gpiod_find_and_request(struct device *consumer, - struct fwnode_handle *fwnode, - const char *con_id, - unsigned int idx, - enum gpiod_flags flags, - const char *label, - bool platform_lookup_allowed) +struct gpio_desc *gpiod_find_and_request(struct device *consumer, + struct fwnode_handle *fwnode, + const char *con_id, + unsigned int idx, + enum gpiod_flags flags, + const char *label, + bool platform_lookup_allowed) { unsigned long lookupflags =3D GPIO_LOOKUP_FLAGS_DEFAULT; struct gpio_desc *desc; diff --git a/drivers/gpio/gpiolib.h b/drivers/gpio/gpiolib.h index a4a2520b5f31c..c6e5fb9aa2122 100644 --- a/drivers/gpio/gpiolib.h +++ b/drivers/gpio/gpiolib.h @@ -202,6 +202,14 @@ static inline int gpiod_request_user(struct gpio_desc = *desc, const char *label) return ret; } =20 +struct gpio_desc *gpiod_find_and_request(struct device *consumer, + struct fwnode_handle *fwnode, + const char *con_id, + unsigned int idx, + enum gpiod_flags flags, + const char *label, + bool platform_lookup_allowed); + int gpiod_configure_flags(struct gpio_desc *desc, const char *con_id, unsigned long lflags, enum gpiod_flags dflags); int gpio_set_debounce_timeout(struct gpio_desc *desc, unsigned int debounc= e); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7DE5B17334D; Sun, 24 Mar 2024 22:39:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319963; cv=none; b=KsjRQu/X99CSU3pqRElEE4sevZSRKmg+5pp30yoCpj9Mi2+5TNN25jdiGbYzVZBY6RsyOMVoE/K1v3qu3iWfXRZDVqB9ONlLMxO3/cZHiDTayzYaTfK6yrUeu3iWMw7pXVfORgBRwXYY+hLMliZE+OkSDOouD4jnw1FmPWD+tUA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319963; c=relaxed/simple; bh=SshzBxQWI3HSxD262UrFfxJZBE5bBzCQvEdLf58jmno=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=WKyJ5umqQiLGE3CqDdXjTErQwc8Yg1y1fFyUfHaxzrckh6qsx1p/8B+S5G22GuJ8Y6L515SByKNqFl9iSgT6CvRHMLztIp2AvsJbNVgdTAHelWk30jrjfGapgGZXYKt/IPioIsnBXY6T4yf1610Enc8+I+kTZ19Rh4O1CUihFq4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sd50yhGg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sd50yhGg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B385AC433C7; Sun, 24 Mar 2024 22:39:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319963; bh=SshzBxQWI3HSxD262UrFfxJZBE5bBzCQvEdLf58jmno=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sd50yhGgrZ8S3sn1ADOc+FRHtwyKAbU3H0kmZqsY835yZqAkDqVHtmUgnLioV9q0Y IriFcFYQAYIb2GqKFZVmnzeHWmS5mdNzTcSjFTJDqM7kNI3nnmRYaOvpCsu5kXlOEl sQgMPKhyDMYpcvKKVGCbzGXcBFNUMM2/mlLEM7rrrHKRpLAjozNueI4HjZPKE5XtmV BCQsrE4R6VFFbaViSE5AdZT9M5y4iA/5DMwGb+/aRvAbX+WZD0nd/nvH3x2CjCOVR8 aTYGYH1KHDJdrWdZ3RK7lndzxL049Cr2rtomaIVlt7Cjmf2mm0oxsrcqJpbDlHr6Bq kF5r95+HoNU5g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= , Gregory CLEMENT , Sasha Levin Subject: [PATCH 6.8 270/715] arm64: dts: marvell: reorder crypto interrupts on Armada SoCs Date: Sun, 24 Mar 2024 18:27:29 -0400 Message-ID: <20240324223455.1342824-271-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Rafa=C5=82 Mi=C5=82ecki [ Upstream commit ec55a22149d64f9ac41845d923b884d4a666bf4d ] Match order specified in binding documentation. It says "mem" should be the last interrupt. This fixes: arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-nam= es:0: 'ring0' was expected from schema $id: http://devicetree.org/schemas/crypto/inside-secure= ,safexcel.yaml# arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-nam= es:1: 'ring1' was expected from schema $id: http://devicetree.org/schemas/crypto/inside-secure= ,safexcel.yaml# arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-nam= es:2: 'ring2' was expected from schema $id: http://devicetree.org/schemas/crypto/inside-secure= ,safexcel.yaml# arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-nam= es:3: 'ring3' was expected from schema $id: http://devicetree.org/schemas/crypto/inside-secure= ,safexcel.yaml# arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-nam= es:4: 'eip' was expected from schema $id: http://devicetree.org/schemas/crypto/inside-secure= ,safexcel.yaml# arch/arm64/boot/dts/marvell/armada-3720-db.dtb: crypto@90000: interrupt-nam= es:5: 'mem' was expected from schema $id: http://devicetree.org/schemas/crypto/inside-secure= ,safexcel.yaml# Signed-off-by: Rafa=C5=82 Mi=C5=82ecki Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 10 +++++----- arch/arm64/boot/dts/marvell/armada-cp11x.dtsi | 10 +++++----- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot= /dts/marvell/armada-37xx.dtsi index e300145ad1a6f..1cc3fa1c354de 100644 --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi @@ -431,14 +431,14 @@ xor11 { crypto: crypto@90000 { compatible =3D "inside-secure,safexcel-eip97ies"; reg =3D <0x90000 0x20000>; - interrupts =3D , - , + interrupts =3D , , , , - ; - interrupt-names =3D "mem", "ring0", "ring1", - "ring2", "ring3", "eip"; + , + ; + interrupt-names =3D "ring0", "ring1", "ring2", + "ring3", "eip", "mem"; clocks =3D <&nb_periph_clk 15>; }; =20 diff --git a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi b/arch/arm64/boo= t/dts/marvell/armada-cp11x.dtsi index 4ec1aae0a3a9c..7e595ac80043a 100644 --- a/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi +++ b/arch/arm64/boot/dts/marvell/armada-cp11x.dtsi @@ -511,14 +511,14 @@ CP11X_LABEL(sdhci0): mmc@780000 { CP11X_LABEL(crypto): crypto@800000 { compatible =3D "inside-secure,safexcel-eip197b"; reg =3D <0x800000 0x200000>; - interrupts =3D <87 IRQ_TYPE_LEVEL_HIGH>, - <88 IRQ_TYPE_LEVEL_HIGH>, + interrupts =3D <88 IRQ_TYPE_LEVEL_HIGH>, <89 IRQ_TYPE_LEVEL_HIGH>, <90 IRQ_TYPE_LEVEL_HIGH>, <91 IRQ_TYPE_LEVEL_HIGH>, - <92 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names =3D "mem", "ring0", "ring1", - "ring2", "ring3", "eip"; + <92 IRQ_TYPE_LEVEL_HIGH>, + <87 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names =3D "ring0", "ring1", "ring2", "ring3", + "eip", "mem"; clock-names =3D "core", "reg"; clocks =3D <&CP11X_LABEL(clk) 1 26>, <&CP11X_LABEL(clk) 1 17>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 63A2C130487; Sun, 24 Mar 2024 22:39:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319964; cv=none; b=DnPA7XZwOqK+RuSht+emxP8xFjhW1cb27//DoH5KNXgl2JTZ80UqpFd/mUsxR4Suyfmh4P++KtmEqGo3QzAEcq5DjcxjKGIgkO/ubRzTKHhy5jBqevLn8PMsR957Ej1GdsOMMT+6kz8pNfecPb+yPdEtmyUguwmjAg3Daz1Hp4Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319964; c=relaxed/simple; bh=0STq7XixVzodxPyfWUmK0TRE9zcmsjRtxfTpQn9z/xI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=gNMKTJ7OkwNVLt4fh2c9mhtls63GGrIyaJXIFSDX2F8l7NLbSfr4Xr0k5ttOZzZ0Rxv9VxqGOYKKH09JQNPDl7+Ep4s28lSBOjjjVTrepbb2h957zRwOQOvLE64B+dRso4gDQET/7OrtRcgpHE9paaxeO1AikTTFWt4DZhcxDME= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EVyr+4IH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EVyr+4IH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F3ACC433F1; Sun, 24 Mar 2024 22:39:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319964; bh=0STq7XixVzodxPyfWUmK0TRE9zcmsjRtxfTpQn9z/xI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EVyr+4IHf+YkEJ5Kmf1/1TlMKyYm0c+851CHriq4lVCj+NK5l8dWqenqnwllsfyCJ 2jGfplpZVmtAqSCjCDmiTQZoFbbsHo2axmI4TFM6GwxoPE3nOq/a6NnsovCwRqvkSd zsehrA7UcIFcZombwk/fAGyIlAW8oWtnG2+R+qkdsw3HwdBTWu4brZtmtx0e5p4ndU ownCJDPro5FXd/qFoRIU0RS73JgW4rwkOKJG07KlPuURbQc81T4WuiPEGDdtRmkUnH AUArj16e2lwBNCfZudBdJAAiAx2K+LWwr3N20yuZvfOs+sElMnfLgXdKOEYCM74zRo wlj9DoLNlklfw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Alexey I. Froloff" , "Rafael J . Wysocki" , Sasha Levin Subject: [PATCH 6.8 271/715] ACPI: resource: Do IRQ override on Lunnen Ground laptops Date: Sun, 24 Mar 2024 18:27:30 -0400 Message-ID: <20240324223455.1342824-272-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Alexey I. Froloff" [ Upstream commit e23ad54fef186aa66007895be1382c88f1ee2bf7 ] The Lunnen Ground 15 and 16 needs IRQ overriding for the keyboard to work. Adding an entries for these laptops to the override_table makes the internal keyboard functional. Signed-off-by: Alexey I. Froloff Signed-off-by: Rafael J. Wysocki Stable-dep-of: 021a67d09615 ("ACPI: resource: Add MAIBENBEN X577 to irq1_ed= ge_low_force_override") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/acpi/resource.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index dacad1d846c0d..3ebb74eb768a5 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -588,6 +588,20 @@ static const struct dmi_system_id irq1_edge_low_force_= override[] =3D { DMI_MATCH(DMI_BOARD_NAME, "GM5RGEE0016COM"), }, }, + { + /* Lunnen Ground 15 / AMD Ryzen 5 5500U */ + .matches =3D { + DMI_MATCH(DMI_SYS_VENDOR, "Lunnen"), + DMI_MATCH(DMI_BOARD_NAME, "LLL5DAW"), + }, + }, + { + /* Lunnen Ground 16 / AMD Ryzen 7 5800U */ + .matches =3D { + DMI_MATCH(DMI_SYS_VENDOR, "Lunnen"), + DMI_MATCH(DMI_BOARD_NAME, "LL6FA"), + }, + }, { } }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A616F1304B0; Sun, 24 Mar 2024 22:39:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319965; cv=none; b=PEERwcdZb+oZNQPFxptDxVnKjS2TuzaPdbcnW7jqyJ6/tl5v1a8niPYVNcFH07OpZhotiA5p6RrdKNxqR1OTCN7AIEXbZn1wx9X3ahxMTaUCwfVCEXSRgiTBz+QBcFixNYKwrr/FJwLeBlQnLY0IGuqpOvAIQ8otKzXGuefBmQ0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319965; c=relaxed/simple; bh=XDtBQWhsDplhQAGI/ZUTgS2XDcZOfYklpJ8bHYM4Src=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GB3TSmLLIsYVuV6IvWx9ff+60lk8n0s+tHl2bE7qv2TbAfshSbu+baRF3sI3ZMW6tjjAbj26zT/QPxZWyeqpWyuRu8jamXwHurFns/PiWvODvzBqTH8/l+BJB8JtYq9YImBE8qo9ON9kVh6VF9WtFOWsfusA6V4I26XFUVFrsLk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z3pgStxg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z3pgStxg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8971AC43394; Sun, 24 Mar 2024 22:39:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319965; bh=XDtBQWhsDplhQAGI/ZUTgS2XDcZOfYklpJ8bHYM4Src=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Z3pgStxgRJPhrw3WZuGxQ7wtP54+kPTSslMFWrhbBjREaGg/NPKLWqYdV4QuBJWsy 6VdaVXrvn8Oku5LCdM6PTFsA5Nzbwn+vnLDIU80iQ+dlF4EdqcsjAsMKyqYS4mktYc 04pKsYuQCQvd5unk5jdkE6cq26732d0EPJ24E310xvuCLwfdlVqWkqqFKfb7466E6R 0lClz5egOHub8319wTsdYNsd1zwOuWVVGYTlovQ5JuFF6rsG5TfkptIHmTLo7t71Ye T7HN24zw3R/lPGpAJvbom7UCAfjuynVZr+gyIopOuZ+ov25YopZGvjka8joS4/UFAt 1qE1v7Lt/2zvg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Maxim Kudinov , Maxim Trofimov , "Rafael J . Wysocki" , Sasha Levin Subject: [PATCH 6.8 272/715] ACPI: resource: Add MAIBENBEN X577 to irq1_edge_low_force_override Date: Sun, 24 Mar 2024 18:27:31 -0400 Message-ID: <20240324223455.1342824-273-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Maxim Kudinov [ Upstream commit 021a67d096154893cd1d883c7be0097e2ee327fd ] A known issue on some Zen laptops, keyboard stopped working due to commit 9946e39fe8d0 fael@kernel.org("ACPI: resource: skip IRQ override on AMD Zen platforms") on kernel 5.19.10. The ACPI IRQ override is required for this board due to buggy DSDT, thus adding the board vendor and name to irq1_edge_low_force_override fixes the issue. Fixes: 9946e39fe8d0 ("ACPI: resource: skip IRQ override on AMD Zen platform= s") Link: https://bugzilla.kernel.org/show_bug.cgi?id=3D217394 Link: https://lore.kernel.org/linux-acpi/20231006123304.32686-1-hdegoede@re= dhat.com/ Tested-by: Maxim Trofimov Signed-off-by: Maxim Kudinov Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/acpi/resource.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c index 3ebb74eb768a5..c843feb02e980 100644 --- a/drivers/acpi/resource.c +++ b/drivers/acpi/resource.c @@ -602,6 +602,13 @@ static const struct dmi_system_id irq1_edge_low_force_= override[] =3D { DMI_MATCH(DMI_BOARD_NAME, "LL6FA"), }, }, + { + /* MAIBENBEN X577 */ + .matches =3D { + DMI_MATCH(DMI_SYS_VENDOR, "MAIBENBEN"), + DMI_MATCH(DMI_BOARD_NAME, "X577"), + }, + }, { } }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 549B5172BD4; Sun, 24 Mar 2024 22:39:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319966; cv=none; b=qzhIvtJwb7hbENtVts1VRJ7HkXvXCeU+NhfIP6sHtsNiZuJ/VucZKmh8csZQcTHIf+uOtgBKYI0CukyZIVusy2rsgy+xJXAl2XexCUxSGP93JfcketuxMImhFE55bLolnfqKfGVdSgdwsbiP5rX0dpWK0NqSwwuMzdBLDa6le48= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319966; c=relaxed/simple; bh=G2nFSWvTjRA3LBCHCsROK0kX2JXbUoFgeHqE6piTCxw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XTejY1wTPw0UvMTaM0RiUOKb5Bhl8KWkoFPSS1nufimSPTNLuLnWQJ/EvTZsmvwYfEsejbXzxIRb+Te9TU1J1zBG83KmQOBN02WHAo0yBL4HkUjg6nqSfFKS+vUHVQNP7laHohhQLUZfvYXHUEoDaEyReK6wQURL404tZnG48GM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LEYOH4jk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="LEYOH4jk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 886B4C43399; Sun, 24 Mar 2024 22:39:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319966; bh=G2nFSWvTjRA3LBCHCsROK0kX2JXbUoFgeHqE6piTCxw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LEYOH4jkULON/ymCKVkFnWzG9/dMn68uoYWx0ShJSLxeuF5LAV8syMr/l0yVLk4Z0 5ed/MO9PaV2Vyec2VvBYsD4vytvfmRssKzxpbrZVFyGF4m73mZ6ZhD+/nJTBtxKEqX nhyUcXSOfIbHLYTbr7rDVyV1C/mb1zXB9j8vM8rFS6iXx2CA45TRXrcEFlqx98kj1i GkRlsPphAq5TCgF30ox5kWt35R3LRZxidE0FwSBnM5tPsn6CzctpxI5Z4zeApYPCq5 CiMVfQ7mPhK8pbNrvQzriF7P3Y/O9/eE6ftf9oC1Tx++euHjCR+LsTYtbKOLAeh3Me PtqUrBK016XJA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: "Rafael J. Wysocki" , Jonathan Cameron , Sasha Levin Subject: [PATCH 6.8 273/715] ACPI: scan: Fix device check notification handling Date: Sun, 24 Mar 2024 18:27:32 -0400 Message-ID: <20240324223455.1342824-274-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: "Rafael J. Wysocki" [ Upstream commit 793551c965116d9dfaf0550dacae1396a20efa69 ] It is generally invalid to fail a Device Check notification if the scan handler has not been attached to the given device after a bus rescan, because there may be valid reasons for the scan handler to refuse attaching to the device (for example, the device is not ready). For this reason, modify acpi_scan_device_check() to return 0 in that case without printing a warning. While at it, reduce the log level of the "already enumerated" message in the same function, because it is only interesting when debugging notification handling Fixes: 443fc8202272 ("ACPI / hotplug: Rework generic code to handle suprise= removals") Signed-off-by: Rafael J. Wysocki Reviewed-by: Jonathan Cameron Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/acpi/scan.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index e6ed1ba91e5c9..617f3e0e963d5 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -314,18 +314,14 @@ static int acpi_scan_device_check(struct acpi_device = *adev) * again). */ if (adev->handler) { - dev_warn(&adev->dev, "Already enumerated\n"); - return -EALREADY; + dev_dbg(&adev->dev, "Already enumerated\n"); + return 0; } error =3D acpi_bus_scan(adev->handle); if (error) { dev_warn(&adev->dev, "Namespace scan failure\n"); return error; } - if (!adev->handler) { - dev_warn(&adev->dev, "Enumeration failure\n"); - error =3D -ENODEV; - } } else { error =3D acpi_scan_device_not_enumerated(adev); } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4DF5A1741DD; Sun, 24 Mar 2024 22:39:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319967; cv=none; b=fyttnbdHIWEtykyCCpYoShZadHvo4ZD/lj43armPU3pLMNE3M8zDbTv2dV5vzcE9PZj0duSliIOLZL1vHBcJD83iA1h5sIJhiFjymyITZwv2+qmb7ipZK3LyooOnxwOg6zin9OgFHTo1kRF99qBMBY6I0z4JEqEjjRFo0ew/gxI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319967; c=relaxed/simple; bh=Cv+D7q9WvVAequB7TUaTMLoBK1zzgqdQ3pgOi7ApiqE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=qOVoBaYvPCq4uID8aadXQtM8iqZu/Mud5rdlllvydvgsV5RI6a7nOUNBuXUUDGKnImtvEPq4Pw4STp3Uw8vqdWMzVAo0kyWQaMei8SVNJ8UlYDopn2Z6n7ELfTikvXe9p0nKqMw+GPMSEfHvzN99WwHjYEpU4sK2xbppAEVcr6s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pXqDI0cz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pXqDI0cz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73ED1C433A6; Sun, 24 Mar 2024 22:39:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319967; bh=Cv+D7q9WvVAequB7TUaTMLoBK1zzgqdQ3pgOi7ApiqE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pXqDI0czBvwO8qdT0VQo5dE4s60CMH4ArmroutALh1eamfFeXbACfw/zHTReinonL hm+eaH6XPViMwcc9ZkvsNc0eBr2JKutF7PCKDAmxpCrCin70LkkFZRLYzAybO6Jy22 K7Wi6tiq6YqiB8Nk4nn6+rQzXEepOM5o/AdYbqopHgQrXkfNw6rbcE2akpRjJs9JXr cMetqW4CPlZC9tp5dfSWWVviASbbqjkI+g8bpX54p6qaz+/eVjveqTBm4GwjAsgANv QrYcwuccYfzuLElXfw5vO4PNeeXWd3wtCt8gS/zWO7VXeXXaIwTvYSksuzk7DQUfUR 92r3HuLnqMw/A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Heiko Stuebner , Piotr Oniszczuk , =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= , Sasha Levin Subject: [PATCH 6.8 274/715] arm64: dts: rockchip: add missing interrupt-names for rk356x vdpu Date: Sun, 24 Mar 2024 18:27:33 -0400 Message-ID: <20240324223455.1342824-275-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Heiko Stuebner [ Upstream commit d1c44d9afa6f89aa0e10a191f30868eb12cd719f ] The video-codec@fdea0400 was missing the interrupt-names property that is part of the binding. Add it. Fixes: 944be6fba401 ("arm64: dts: rockchip: Add VPU support for RK3568/RK35= 66") Cc: Piotr Oniszczuk Acked-by: Uwe Kleine-K=C3=B6nig Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20240227173526.710056-1-heiko@sntech.de Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/rockchip/rk356x.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts= /rockchip/rk356x.dtsi index c19c0f1b3778f..6a9bfb0550c04 100644 --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi @@ -597,6 +597,7 @@ vpu: video-codec@fdea0400 { compatible =3D "rockchip,rk3568-vpu"; reg =3D <0x0 0xfdea0000 0x0 0x800>; interrupts =3D ; + interrupt-names =3D "vdpu"; clocks =3D <&cru ACLK_VPU>, <&cru HCLK_VPU>; clock-names =3D "aclk", "hclk"; iommus =3D <&vdpu_mmu>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3552D1741FC; Sun, 24 Mar 2024 22:39:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319968; cv=none; b=sFac1hg1wc2P3N7MGrk5CGvPOZV7vnVn0Yxb9rGzyum4CHZDTq68PA/n0QctFLbI9aHNQozvkmIbo7bIvGU5KcHkUSxUnRgUDuI5RCXZ83a95lOu0jbo7Uv+WLUvQjAMlJzREPM8q0ckD06kZP8Qubx/037JqfKADE0V0dTOByc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319968; c=relaxed/simple; bh=3amgfx0AshjHIMz2Es+2BaOqMWFTibDYt+16ztnBPHw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=SJ5YvB8lE0CqPJJsGI+NVEr3FUNGJqLFvdSpDDVbmdWnz6jl2aq5vVw5Rv+tBry7Wb4m3AtE/+YUpWAbX9xoi2TN0WqJxvfDB687kJkoh9WGI8sim43h25mWUEmfZRFkendboLZhcJDZ+Cskb3sLhuG15pcw6fKMezxIJLu0mPE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iCzZ4AcD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iCzZ4AcD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 73185C433F1; Sun, 24 Mar 2024 22:39:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319968; bh=3amgfx0AshjHIMz2Es+2BaOqMWFTibDYt+16ztnBPHw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iCzZ4AcDJg6Ov1KW/aLJ5J6mIpFX52mEO1CiKIivLCFqidOEdxZwWEeutkPM2VEbO bwlfD8r2ExGOjxSrOPrRcA41td92RjXg+ihoQLh08wQpp2+WOIw7gDHTm4+vceZLt6 3sxAk5/CN50ruvyfUcrItqZAWoCAzNOTfh/XlCppLegdGRA/uz2DSIM0zzWiB1+nOl ZVhdQtfim9ZALhw5+B47yDiqpRajJFiMX1oHxxyPLUp3cAiwP/QTlXY+4EQz8LxPv9 AYiMBcv7PQ546p6wJ5kVzXVIMQpc7PrIKwcpJBaVRoz4qfUHPeHV+qQPdNGgLUNohs V8yeKCiEdLcRQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Heiko Stuebner , =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= , Sasha Levin Subject: [PATCH 6.8 275/715] arm64: dts: rockchip: fix reset-names for rk356x i2s2 controller Date: Sun, 24 Mar 2024 18:27:34 -0400 Message-ID: <20240324223455.1342824-276-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Heiko Stuebner [ Upstream commit 0fc19ab75acde78558bd0f6fe3e5f63cf8ee88b0 ] The dtbscheck reports a warning for a wrong reset-names property for the i2s2 controller on rk356x socs. The other controllers on the soc provide tx and rx directions and hence two resets and separate clocks for each direction, while i2s2 only provides one reset. This was so far named just "m" which isn't part of the binding. The clock-names the controller uses all end in "tx", so use the matching "tx-m" reset-name for the i2s controller. Fixes: 755f37010f3e ("arm64: dts: rockchip: RK356x: Add I2S2 device node") Acked-by: Uwe Kleine-K=C3=B6nig Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20240227173526.710056-2-heiko@sntech.de Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/rockchip/rk356x.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts= /rockchip/rk356x.dtsi index 6a9bfb0550c04..92f96ec01385d 100644 --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi @@ -1124,7 +1124,7 @@ i2s2_2ch: i2s@fe420000 { dmas =3D <&dmac1 4>, <&dmac1 5>; dma-names =3D "tx", "rx"; resets =3D <&cru SRST_M_I2S2_2CH>; - reset-names =3D "m"; + reset-names =3D "tx-m"; rockchip,grf =3D <&grf>; pinctrl-names =3D "default"; pinctrl-0 =3D <&i2s2m0_sclktx --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6DC245A0F1; Sun, 24 Mar 2024 22:39:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319969; cv=none; b=TxiPyzbSVI7ghyFqGMFGZC9AqnoORkih4+C3iAHo4sn58Y6L5JfTbqfuHMLgSUHko7ZFSe84Dd9t51VSq8cfaiWLzu+60YhXZFrzgprd7sokXQMluJ1z8dybyAcr9eokWhQpF8LXamIsqRyynDBsWhYdtLaFdEXy3Jp8ePWRGPo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319969; c=relaxed/simple; bh=Kh7U/mKHQ+anKiD0Nygr9rYXgz72DaOZ679gP3rRRg4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CiDZKnXL5dNMIT1+AOcL1ZNLNDS3V+kIFflalGsok0Awx1ZMu2Wr48KLIFAQnvxyfCnaqu1daorZ4rbazuM2ngrkdyUdsOPArbKJlF3T7m7OPMN/JEmknV59G0agFNVD2lQNlt1rPOGHw3LAZl6Y6XjmSeihWMeiz0dk012pqaE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fhayWkFM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fhayWkFM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5B8B7C43399; Sun, 24 Mar 2024 22:39:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319969; bh=Kh7U/mKHQ+anKiD0Nygr9rYXgz72DaOZ679gP3rRRg4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fhayWkFMj+KE2xlal/WhTMyfU2EMIt83LWBhSCDsm+eI0BgYSY8gvoc0UvVEigII7 /PgDyv4wcpO0VBZyCn7ysGn+M/7UHeLhRMRRi8/g8KYwN+NCNlZsHVAeb4dURgEQx1 6S6+qJUhfTck7+Zv17ElxdUvjx4UtltIzV5BCklAjaEwljEoGG2aXy6AjIEUvgpHRP TCAWr9IgTmcion2ffyAyRG3DRYWptuBw5gUiaAdnRUMszyNdQqHX9clMopNbBXcgjU C8jILnbyGXrcSqpL/8FNlWvxM2tJOhSQLWEmDRpc/L67pxyJIfUzDAfuTstqnBFcLR ScGkDvgYNd+pw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Heiko Stuebner , Sugar Zhang , Cristian Ciocaltea , Quentin Schulz , Heiko Stuebner , Sasha Levin Subject: [PATCH 6.8 276/715] arm64: dts: rockchip: drop rockchip,trcm-sync-tx-only from rk3588 i2s Date: Sun, 24 Mar 2024 18:27:35 -0400 Message-ID: <20240324223455.1342824-277-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Heiko Stuebner [ Upstream commit a8037ceb89649659831e86a87a9329d1bb43c735 ] The rockchip,trcm-sync-tx-only property is at this time only documented for the tdm variant of Rockchip i2s controllers. While there was a series [0] adding code and binding for the property, it doesn't seem to have gone forward back in 2021. So for now fix the devicetree check by removing the property from rk3588 i2s controllers until support for it gets merged. [0] https://patchwork.kernel.org/project/linux-rockchip/patch/1629796734-42= 43-5-git-send-email-sugar.zhang@rock-chips.com/ Fixes: 8ae112a5554f ("arm64: dts: rockchip: Add rk3588s I2S nodes") Cc: Sugar Zhang Cc: Cristian Ciocaltea Signed-off-by: Heiko Stuebner Reviewed-by: Quentin Schulz Link: https://lore.kernel.org/r/20240227164659.705271-2-heiko@sntech.de Signed-off-by: Heiko Stuebner Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi b/arch/arm64/boot/dt= s/rockchip/rk3588s.dtsi index 36b1b7acfe6a1..82350ddb262f2 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi @@ -1704,7 +1704,6 @@ i2s2_2ch: i2s@fe490000 { dmas =3D <&dmac1 0>, <&dmac1 1>; dma-names =3D "tx", "rx"; power-domains =3D <&power RK3588_PD_AUDIO>; - rockchip,trcm-sync-tx-only; pinctrl-names =3D "default"; pinctrl-0 =3D <&i2s2m1_lrck &i2s2m1_sclk @@ -1725,7 +1724,6 @@ i2s3_2ch: i2s@fe4a0000 { dmas =3D <&dmac1 2>, <&dmac1 3>; dma-names =3D "tx", "rx"; power-domains =3D <&power RK3588_PD_AUDIO>; - rockchip,trcm-sync-tx-only; pinctrl-names =3D "default"; pinctrl-0 =3D <&i2s3_lrck &i2s3_sclk --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8316817497A; Sun, 24 Mar 2024 22:39:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319970; cv=none; b=H6MzThCucqNWtAxpE1/4Emt1nIS+wcBljGBQM7bM4x79pJGv96WLaZJhLblnoqQfSZ2zLg6JQQ0HiLW1oI+JlS+4arN1J58B6g8f8SAfGcKKYSjxe3ZgwbH0F36vgAGRK1/1VSapx9/VQnk79oCncaq8Zi0kxZscMpfLzWQl4Xg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319970; c=relaxed/simple; bh=FwRUlJdf2CwufbTEJaPahXujuWP54HzSK35Xuao6dhE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=V9kuf4dtlWrMcNB7lkvBRRnP/d3+mTPMeAmI1XtK3O5C+JmYPlrrIDNbi5BSuWhZrIJBkjyoJUFYAhAct9Yn+kBeczLV/u7/30eBEXKt/c6fRUblSasumJQiW7h39jze3scaaqaC+E1uKpZFv8Fe7Pm2znp1eeAKr6gZQwDA0AQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WnBllwjm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WnBllwjm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 895A3C433F1; Sun, 24 Mar 2024 22:39:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319970; bh=FwRUlJdf2CwufbTEJaPahXujuWP54HzSK35Xuao6dhE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WnBllwjm8WtwWO6qyp+X7LRsAT/zecqsIuP+1yitih5coTmtljeAKxyPXPJQzRMIN xsHIXsdHIh4W5boYiGZeeZGXg4LdiEPonJD4BzewNdDDD9LfMBOaMwfrbFVJXCGMau XuEK1RcR3rCmFjVZNYRR+Cvw8IYAztui0sOZWNJDxWKZJ8spFjIZHXRIjauWuZIvVN XRDMUtD4+kL9Oyl+WMFAzuow4fp0EFqpGnOId/jiJXPyL772OhVJOryj7+lQUSnhZG 8YjQ5IbABXVAboeUtEI/Wxh5RkQhNDfE70W8fZTMtzVnvkJ6+7vCvVR3kGvc5dEglZ FccyYNY6O7DRg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jason Gunthorpe , Shameerali Kolothum Thodi , Nicolin Chen , Will Deacon , Sasha Levin Subject: [PATCH 6.8 277/715] iommu/arm-smmu-v3: Check that the RID domain is S1 in SVA Date: Sun, 24 Mar 2024 18:27:36 -0400 Message-ID: <20240324223455.1342824-278-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jason Gunthorpe [ Upstream commit ae91f6552c301e5e8569667e9d5440d5f75a90c4 ] The SVA code only works if the RID domain is a S1 domain and has already installed the cdtable. Originally the check for this was in arm_smmu_sva_bind() but when the op was removed the test didn't get copied over to the new arm_smmu_sva_set_dev_pasid(). Without the test wrong usage usually will hit a WARN_ON() in arm_smmu_write_ctx_desc() due to a missing ctx table. However, the next patches wil change things so that an IDENTITY domain is not a struct arm_smmu_domain and this will get into memory corruption if the struct is wrongly casted. Fail in arm_smmu_sva_set_dev_pasid() if the STE does not have a S1, which is a proxy for the STE having a pointer to the CD table. Write it in a way that will be compatible with the next patches. Fixes: 386fa64fd52b ("arm-smmu-v3/sva: Add SVA domain support") Reported-by: Shameerali Kolothum Thodi Closes: https://lore.kernel.org/linux-iommu/2a828e481416405fb3a4cceb9e075a5= 9@huawei.com/ Tested-by: Nicolin Chen Signed-off-by: Jason Gunthorpe Link: https://lore.kernel.org/r/11-v6-96275f25c39d+2d4-smmuv3_newapi_p1_jgg= @nvidia.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iomm= u/arm/arm-smmu-v3/arm-smmu-v3-sva.c index 4a27fbdb2d844..2610e82c0ecd0 100644 --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c @@ -364,7 +364,13 @@ static int __arm_smmu_sva_bind(struct device *dev, ioa= sid_t pasid, struct arm_smmu_bond *bond; struct arm_smmu_master *master =3D dev_iommu_priv_get(dev); struct iommu_domain *domain =3D iommu_get_domain_for_dev(dev); - struct arm_smmu_domain *smmu_domain =3D to_smmu_domain(domain); + struct arm_smmu_domain *smmu_domain; + + if (!(domain->type & __IOMMU_DOMAIN_PAGING)) + return -ENODEV; + smmu_domain =3D to_smmu_domain(domain); + if (smmu_domain->stage !=3D ARM_SMMU_DOMAIN_S1) + return -ENODEV; =20 if (!master || !master->sva_enabled) return -ENODEV; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7EDAA174ED7; Sun, 24 Mar 2024 22:39:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319971; cv=none; b=mVPxbkTxrdQ0lj5uSO48tzwvJs+lLT5HFMZTcSviWZtnQ8gw3avzMkFjIKStmF0dukDKQ0gCG3X/vmt9ZMu8Whxuv4kqntUj8BH0vkrjkB9EyAOaH4+IWvGGsBSglGdefYTxoupcQJH0a9nHcLOilso8hCY8xNEVZ52uI4emA6A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319971; c=relaxed/simple; bh=1lcqNUEnQ0ADi75cyhwnE7U3PFvqMXBMU/9HDfCGPls=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l267XDpf8iHn85K6/jH9XxAc1e27CZ/KxR4T1cbSSYBJpNxWno/QEDLulxpQUyWCqLwUiXjiIOpIDHiw3zRFB5EmJLB9Tk6pDFVqkfJYjn3AaolZeilEa/7Z0MvZ1S9NyrNKZePsVRcYXhpVmu+W/LeB/fhOlgyAgjD8JOT4tKY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WYUUpFl7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WYUUpFl7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0985C43390; Sun, 24 Mar 2024 22:39:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319971; bh=1lcqNUEnQ0ADi75cyhwnE7U3PFvqMXBMU/9HDfCGPls=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WYUUpFl7yONBbk83JSCG45Ll6vKnZ/6hZwiDDNt/519sC/zIosumNX/YxytSYWe+y 5U3QYCIROEPBqA3y0hLW9pZFDDwXoZYsIbnYvFbYYDrgMKVAxRIAVXDlUv8MWJpHh3 n/Id7nU5TYShuP6c+nSj+PqZsFTp74fRcK/lO5YvrByIUeyqvVApkk451lInD2R1RF YMPMLu1H9WIw/FUKvF8SMjaG0Buze50hb+E9ZCfQvoE2jSBKl4fDLZ3HPvfMkKrcq9 FBPEVfKsPLpWlOGfuOpKP3LFE4GvSApOrgj6DHS85m+kTQfyVLbVGHeYQIkoJ4LdeL AkcI0l7q0sF2Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Josh Poimboeuf , kernel test robot , Kees Cook , Sasha Levin Subject: [PATCH 6.8 278/715] objtool: Fix UNWIND_HINT_{SAVE,RESTORE} across basic blocks Date: Sun, 24 Mar 2024 18:27:37 -0400 Message-ID: <20240324223455.1342824-279-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Josh Poimboeuf [ Upstream commit 10b4c4bce3f5541f54bcc2039720b11d2bc96d79 ] If SAVE and RESTORE unwind hints are in different basic blocks, and objtool sees the RESTORE before the SAVE, it errors out with: vmlinux.o: warning: objtool: vmw_port_hb_in+0x242: objtool isn't smart en= ough to handle this CFI save/restore combo In such a case, defer following the RESTORE block until the straight-line path gets followed later. Fixes: 8faea26e6111 ("objtool: Re-add UNWIND_HINT_{SAVE_RESTORE}") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202402240702.zJFNmahW-lkp@int= el.com/ Signed-off-by: Josh Poimboeuf Link: https://lore.kernel.org/r/20240227073527.avcm5naavbv3cj5s@treble Signed-off-by: Kees Cook Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/objtool/check.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/tools/objtool/check.c b/tools/objtool/check.c index 548ec3cd7c00c..c4c2f75eadfd9 100644 --- a/tools/objtool/check.c +++ b/tools/objtool/check.c @@ -3620,6 +3620,18 @@ static int validate_branch(struct objtool_file *file= , struct symbol *func, } =20 if (!save_insn->visited) { + /* + * If the restore hint insn is at the + * beginning of a basic block and was + * branched to from elsewhere, and the + * save insn hasn't been visited yet, + * defer following this branch for now. + * It will be seen later via the + * straight-line path. + */ + if (!prev_insn) + return 0; + WARN_INSN(insn, "objtool isn't smart enough to handle this CFI save/r= estore combo"); return 1; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C3DF3174EF9; Sun, 24 Mar 2024 22:39:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319972; cv=none; b=NgL4D/4hEUqBSvEF8bduFIIz3kQluCOMHxunFpiIb4nMaeWrKh/0Wx3N/w2JNxXKAKV1Zorgr5qqZaAo/6dHKu9kLSLoUg6RNC08CDkZyHd+5m/EkrT0PA+vRJp2DuaIlmCIcKEAP121NcnQHd76IOIuykI3WHx+BtTjvw9nlb0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319972; c=relaxed/simple; bh=sgMet8Ys7vXbgoPCUJNEgcAJoQloFmo0UIL3Zyz8JnI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fczVpc9c/Bh4g3eZDMx03TpexsoTjEvUgUrY3Zm37xTydb3huVPILdiMR7HXqUmOQYKeM+2iiKZGMHq1t1OD+ncvi6nI0gF/f+RXZae3TzVMjZez21kP7Bh4MBGfnKWyRKdNHOnUlimogGzL76lpQDsJo5AiLEPANgMagAdppHg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I2eTgha1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I2eTgha1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1CD3C43394; Sun, 24 Mar 2024 22:39:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319972; bh=sgMet8Ys7vXbgoPCUJNEgcAJoQloFmo0UIL3Zyz8JnI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I2eTgha1CeQNvzO6CVDujF+yXB9dVo+eK1Uug8ewZEaZEVEGlR5o5Aw6bzBV3qhz3 DxJkOysOT+Nn2OCu33VC3wTt/AQCQ8UQJNh2ooPc5a59JITdZhhAa8mUPMShI6s8E7 fsY3Q0MN+0rM9jQBDNZ9UVGMh7kNnDWSAzlAxFHoWaiR5ECnd5+TZ2YlQ1FW/7LzBp NUke9sbrOSNVUTBS6LxsythoK9eYHtVRHDTskxg7fvf/4IIOgpxpYIRHhokKjks55h kvJBsesIEJw40PkzTBfAN/8DhkoV72sMFCWzAEGF5n+ImjeF0sM3CpLtaWjBI1Y62k +R9tVXiqdoFHw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Kees Cook , Guixiong Wei , Juergen Gross , Sasha Levin Subject: [PATCH 6.8 279/715] x86, relocs: Ignore relocations in .notes section Date: Sun, 24 Mar 2024 18:27:38 -0400 Message-ID: <20240324223455.1342824-280-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Kees Cook [ Upstream commit aaa8736370db1a78f0e8434344a484f9fd20be3b ] When building with CONFIG_XEN_PV=3Dy, .text symbols are emitted into the .notes section so that Xen can find the "startup_xen" entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map. Reported-by: Guixiong Wei Closes: https://lore.kernel.org/all/20240218073501.54555-1-guixiongwei@gmai= l.com/ Fixes: 5ead97c84fa7 ("xen: Core Xen implementation") Fixes: da1a679cde9b ("Add /sys/kernel/notes") Reviewed-by: Juergen Gross Signed-off-by: Kees Cook Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/x86/tools/relocs.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c index a3bae2b24626b..b029fb81ebeee 100644 --- a/arch/x86/tools/relocs.c +++ b/arch/x86/tools/relocs.c @@ -653,6 +653,14 @@ static void print_absolute_relocs(void) if (!(sec_applies->shdr.sh_flags & SHF_ALLOC)) { continue; } + /* + * Do not perform relocations in .notes section; any + * values there are meant for pre-boot consumption (e.g. + * startup_xen). + */ + if (sec_applies->shdr.sh_type =3D=3D SHT_NOTE) { + continue; + } sh_symtab =3D sec_symtab->symtab; sym_strtab =3D sec_symtab->link->strtab; for (j =3D 0; j < sec->shdr.sh_size/sizeof(Elf_Rel); j++) { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BFF52175546; Sun, 24 Mar 2024 22:39:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319973; cv=none; b=KxvAjEJkhZVMsSHlj7ScUbWJzB75/d0Kg1A7kM4hFfZ+WbemCBzbE9/xcU5mwGE2PC+KlYN7ejQmRKEbKPtGsEI2h7q2xilGTxW7dY+VvZEm5KA1wHdE1Yioo+27cMGHcz+GRJE4dPlineueAIr/uGaPvKPt1fEyuez8jkw1QKM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319973; c=relaxed/simple; bh=dxYv9j9I1vk7dVkAyDPF9nCoByCOZRCBcJTWm36K76w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lvVWW6EOdM6XhUQnFP1DeuNlATLsjAQmZ0PQPncYLPLnmpRe8oA8o5ZOzt+C90Xojv2hcbEGI5nXBR2iJOUUAXbnIlOmBs4VV9Ap+IX2Ej5mertIItZXVQYq3ebg67UFdOYTwk+3FiW7xXAxGiIKTmgaOSCSXALGlcp9gEZ22Mc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qUmSTNkv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qUmSTNkv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9FF89C433B1; Sun, 24 Mar 2024 22:39:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319973; bh=dxYv9j9I1vk7dVkAyDPF9nCoByCOZRCBcJTWm36K76w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qUmSTNkv5wQEcHW+BknOv+IyzOdwXQa8Eo+pIyMVvOZ6T5CGqmuE9PqCELQGygC7d kAwze90mgVx+kwXulx1JsM6LodT7fsXlraFmiDxJhdlxN9DKtnPgioBYVAReQotFX7 oA8bkfUdHERD4CiMZ0VJPp0oTdLAP9+aT3LK+b3dBF74eLPLa2bJeiTFdPfLNoXKUN pYjaUG//oNFbJWzHlgFAx0Zr51XWe0GJ2qX3Xat5J6L1lLKpul5B5fU1Eb4x+PkLaX vIX7NsFjuEpPnvqml3tL+3TUM0NbQNGqTfk2g2QdchJLPbALd9rc3j7rUj6qky3cr7 cGjug4xhE7axw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zhipeng Lu , Jeff Layton , Chuck Lever , Sasha Levin Subject: [PATCH 6.8 280/715] SUNRPC: fix a memleak in gss_import_v2_context Date: Sun, 24 Mar 2024 18:27:39 -0400 Message-ID: <20240324223455.1342824-281-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zhipeng Lu [ Upstream commit e67b652d8e8591d3b1e569dbcdfcee15993e91fa ] The ctx->mech_used.data allocated by kmemdup is not freed in neither gss_import_v2_context nor it only caller gss_krb5_import_sec_context, which frees ctx on error. Thus, this patch reform the last call of gss_import_v2_context to the gss_krb5_import_ctx_v2, preventing the memleak while keepping the return formation. Fixes: 47d848077629 ("gss_krb5: handle new context format from gssd") Signed-off-by: Zhipeng Lu Reviewed-by: Jeff Layton Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/sunrpc/auth_gss/gss_krb5_mech.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/auth_gss/gss_= krb5_mech.c index 64cff717c3d9b..3366505bc669a 100644 --- a/net/sunrpc/auth_gss/gss_krb5_mech.c +++ b/net/sunrpc/auth_gss/gss_krb5_mech.c @@ -398,6 +398,7 @@ gss_import_v2_context(const void *p, const void *end, s= truct krb5_ctx *ctx, u64 seq_send64; int keylen; u32 time32; + int ret; =20 p =3D simple_get_bytes(p, end, &ctx->flags, sizeof(ctx->flags)); if (IS_ERR(p)) @@ -450,8 +451,16 @@ gss_import_v2_context(const void *p, const void *end, = struct krb5_ctx *ctx, } ctx->mech_used.len =3D gss_kerberos_mech.gm_oid.len; =20 - return gss_krb5_import_ctx_v2(ctx, gfp_mask); + ret =3D gss_krb5_import_ctx_v2(ctx, gfp_mask); + if (ret) { + p =3D ERR_PTR(ret); + goto out_free; + } =20 + return 0; + +out_free: + kfree(ctx->mech_used.data); out_err: return PTR_ERR(p); } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 61BBF17555A; Sun, 24 Mar 2024 22:39:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319974; cv=none; b=p8QEAdvGkGQdcBy2YsWx+seh4jrQq016ylV1JTy5daNrBvxInHW4pBrq7cmPJ4sZ2bdipPQp64BGfo5q1xRiOYgBGo2MH9Xhi/kIX2mcZ9bbfxR2NM1rWZ9TIJeQlEyrhd9FmXy5Xqz2LiyZGvXOCZlUwA5hleE1nSzMkbHHq8A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319974; c=relaxed/simple; bh=uRoRsaHWAWpKpAmF0MLAb2S1bcEcuSVKZ2mxImqiWlo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bIpjvG7Gut5sgKvmuuQxKanZf1c+eLEh3vp2U5AWAHocoWk/vRGQyWOtQFE/XguXSMNrU/KPRhKUGJ325gFXCbh5USSfxsaRc7gi1mql8dbYzREN7QsYlJu1SL0XMa/XbSGjPpQTXemJuv2tdCw+ODj5e+FBQasuWSRfIgr9Sy4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=R7i+cr7C; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="R7i+cr7C" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9C3ABC43399; Sun, 24 Mar 2024 22:39:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319974; bh=uRoRsaHWAWpKpAmF0MLAb2S1bcEcuSVKZ2mxImqiWlo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=R7i+cr7CH/1cHzjq5YtWg7d72+nupUWRoahdfWsRa1ai+aqJxOD8/j8V3SRkmIelU 0gROC2mQNgchNTyswvHx50JK/Vl2k8mCZM8ttVNDAP7IAvm+ZqPBN4aXoR7R/dG4My oKk5KTSGkmownV5nEEvr+07LwozCF219MMa2TY9y9SmtZJXQEXAKPL24K0LQV9E+HW WksYpoWNxwwLmHbiREgzwkoCnSgVKgjvz+jCi3sEEVvv157enCOuAVilGfX8itooCb kyOFnXgMDoqUE/LjTY7/y72yjNpqSmm9MbDk6my7j3MMuEwhv8HknRt2ADPgKkzzOZ bW04sZvecs1RQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zhipeng Lu , Chuck Lever , Sasha Levin Subject: [PATCH 6.8 281/715] SUNRPC: fix some memleaks in gssx_dec_option_array Date: Sun, 24 Mar 2024 18:27:40 -0400 Message-ID: <20240324223455.1342824-282-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zhipeng Lu [ Upstream commit 3cfcfc102a5e57b021b786a755a38935e357797d ] The creds and oa->data need to be freed in the error-handling paths after their allocation. So this patch add these deallocations in the corresponding paths. Fixes: 1d658336b05f ("SUNRPC: Add RPC based upcall mechanism for RPCGSS aut= h") Signed-off-by: Zhipeng Lu Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/sunrpc/auth_gss/gss_rpc_xdr.c | 27 +++++++++++++++++++-------- 1 file changed, 19 insertions(+), 8 deletions(-) diff --git a/net/sunrpc/auth_gss/gss_rpc_xdr.c b/net/sunrpc/auth_gss/gss_rp= c_xdr.c index d79f12c2550ac..cb32ab9a83952 100644 --- a/net/sunrpc/auth_gss/gss_rpc_xdr.c +++ b/net/sunrpc/auth_gss/gss_rpc_xdr.c @@ -250,8 +250,8 @@ static int gssx_dec_option_array(struct xdr_stream *xdr, =20 creds =3D kzalloc(sizeof(struct svc_cred), GFP_KERNEL); if (!creds) { - kfree(oa->data); - return -ENOMEM; + err =3D -ENOMEM; + goto free_oa; } =20 oa->data[0].option.data =3D CREDS_VALUE; @@ -265,29 +265,40 @@ static int gssx_dec_option_array(struct xdr_stream *x= dr, =20 /* option buffer */ p =3D xdr_inline_decode(xdr, 4); - if (unlikely(p =3D=3D NULL)) - return -ENOSPC; + if (unlikely(p =3D=3D NULL)) { + err =3D -ENOSPC; + goto free_creds; + } =20 length =3D be32_to_cpup(p); p =3D xdr_inline_decode(xdr, length); - if (unlikely(p =3D=3D NULL)) - return -ENOSPC; + if (unlikely(p =3D=3D NULL)) { + err =3D -ENOSPC; + goto free_creds; + } =20 if (length =3D=3D sizeof(CREDS_VALUE) && memcmp(p, CREDS_VALUE, sizeof(CREDS_VALUE)) =3D=3D 0) { /* We have creds here. parse them */ err =3D gssx_dec_linux_creds(xdr, creds); if (err) - return err; + goto free_creds; oa->data[0].value.len =3D 1; /* presence */ } else { /* consume uninteresting buffer */ err =3D gssx_dec_buffer(xdr, &dummy); if (err) - return err; + goto free_creds; } } return 0; + +free_creds: + kfree(creds); +free_oa: + kfree(oa->data); + oa->data =3D NULL; + return err; } =20 static int gssx_dec_status(struct xdr_stream *xdr, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id ADAF2174945; Sun, 24 Mar 2024 22:39:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319975; cv=none; b=q4wGAFr6bsTnXILdRBMhojt35gjgDTv9SpnFy/5WjP0vdkXLKEMNn7gdpwOgDPH6N5sJdL9q2oQ9ZjKy2jLA76V81DfehgNSua4JnipEMX/en17/zsElgZPchViXgsSCHyuC+eriX5ryV0G4ViwOxnWb7WccUnkDeRqUFPS5MAo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319975; c=relaxed/simple; bh=syZ7zM0ZQCpE2wuH6W5pZKG769FBlLja+iwHGtXJ1Ww=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XcQMsOIwV33Vf0gJ6Wlhstb72gQl8h29kqTlSAoJCPoaxaHTJ5CbTsvYt31QHHXOF15YH6XsU/0b1a1LMlmm+TE70gUd5c3Mwr/PJxu2uPztUyNvK8HtzWVNCH9BvuJFVgQHb6qaQDgkGgSt2lTLuA4hcihK0MOgCIdG/5X19pc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kgwspFE0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kgwspFE0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87C32C43390; Sun, 24 Mar 2024 22:39:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319975; bh=syZ7zM0ZQCpE2wuH6W5pZKG769FBlLja+iwHGtXJ1Ww=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kgwspFE0k2R40Z8fdN1q+enl9S3XYs/8igsXhwuEJG2FpPIrXd4baHj6qmA5wJakk bYtkSHujcJW+rCgu75pbYrE3A80z49SyMXwAJVbZtjndhttVAL8lbnP2dcgDCAH7vL QlMZhk6IzwQCeq4fHGb6MlZrWRbC1EGK1AkAk1Ya0JdTBF6csSfyTucMHGD0iemC7o Bd2jBtUFc0HiH/xqqa5MDWOA96Z1kJNwEq3NE0aULjaBIvc67fnnKs/m2TygyP47hE XJ0/uglhWA2YFNnbzQol4j8R2qVKaSD+GDpzeGZcejZi6fuWUJgoSSpE+kJk0PTpSX SxKY6Z20FTC9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Abel Vesa , Neil Armstrong , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 282/715] arm64: dts: qcom: sm8550: Fix SPMI channels size Date: Sun, 24 Mar 2024 18:27:41 -0400 Message-ID: <20240324223455.1342824-283-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Abel Vesa [ Upstream commit 77dd1e50ffcba33c3195ae4fc78f354368ddacb2 ] The actual size of the channels registers region is 4MB, according to the documentation. This issue was not caught until now because the driver was supposed to allow same regions being mapped multiple times for supporting multiple buses. Thie driver is using platform_get_resource_byname() and devm_ioremap() towards that purpose, which intentionally avoids devm_request_mem_region() altogether. Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Reviewed-by: Neil Armstrong Signed-off-by: Abel Vesa Reviewed-by: Konrad Dybcio Tested-by: Neil Armstrong # on SM8550-QRD Link: https://lore.kernel.org/r/20240221-dts-qcom-sm8550-fix-spmi-chnls-siz= e-v2-1-72b5efd9dc4f@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sm8550.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qco= m/sm8550.dtsi index ee1ba5a8c8fc2..90acdf16b8307 100644 --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi @@ -3248,7 +3248,7 @@ sram@c3f0000 { spmi_bus: spmi@c400000 { compatible =3D "qcom,spmi-pmic-arb"; reg =3D <0 0x0c400000 0 0x3000>, - <0 0x0c500000 0 0x4000000>, + <0 0x0c500000 0 0x400000>, <0 0x0c440000 0 0x80000>, <0 0x0c4c0000 0 0x20000>, <0 0x0c42d000 0 0x4000>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87522175C9A; Sun, 24 Mar 2024 22:39:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319976; cv=none; b=hiUbwklH0Tix21hskJCYy3wIl436oNaAB9L4rG4PB/RUN5+QZXp+rXGdGIt0EmIcmw8wWvA9An7dDGVuS5FzmSFqSe1PmzaGsp9m8Gguy+wNrRKgayWjszESEh5+YO7YE24HAYkRkPbTzePCtdA6USz1rptTK8x4C+G9RI3qmcc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319976; c=relaxed/simple; bh=puQb5c0VDCrUhJLPMw1yY8HRPfs5JtJz+AqwO2U7XmQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N6QsE3ZU3pe257VGp9VSsgdjoVveaszSTV6TVq/5p1FEq6lSnHEHLMWPmaLo6Rq5kCG2w+8VI1kmOAf5vL60W1gD3pH3LRZ8fsnrRmswD7rrpAttebdu6UNZtI6m+hQPe/GligqRqTaTB2s/VTYU2+ZJL+I2OtJkqp5qX7z70NE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ln7VZ+rH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ln7VZ+rH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97DB2C43394; Sun, 24 Mar 2024 22:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319976; bh=puQb5c0VDCrUhJLPMw1yY8HRPfs5JtJz+AqwO2U7XmQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ln7VZ+rHNud/3OCSu89VJ33V0bIBl9Pr6GM5XoaQpSdiDBkRFgKpfgU+sMWNIs0xJ HujEwdO67aD4Pm0STxfGi/QknujGxvJaEwaIdX4GO5bLnbfUGKbyb7wFfRwebUlFje 8vn5tyUM0+wQLmlNmmJsVvfJDyvTYppyI1nbuJkzb2YbyVcpx81le93ADYfy60uequ 1aN35ysZ3V25iAx3eSC4iYKQrqiTPjmYTkhD3uEH79bjhajRXKkf2oYRde7akrse9s gi+xaWzP5LqPBXUdPL3jemdkFEgUFw1DuGBFhoAgckp6IhPm0+KdiOuhg8OokH/glN YW/ebfjoeUBpA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Abel Vesa , Neil Armstrong , Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 283/715] arm64: dts: qcom: sm8650: Fix SPMI channels size Date: Sun, 24 Mar 2024 18:27:42 -0400 Message-ID: <20240324223455.1342824-284-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Abel Vesa [ Upstream commit a4f82b8045e3c7913266aa6ea1ee15752a062abd ] The actual size of the channels registers region is 4MB, according to the documentation. This issue was not caught until now because the driver was supposed to allow same regions being mapped multiple times for supporting multiple buses. Thie driver is using platform_get_resource_byname() and devm_ioremap() towards that purpose, which intentionally avoids devm_request_mem_region() altogether. Fixes: 10e024671295 ("arm64: dts: qcom: sm8650: add interconnect dependent = device nodes") Reviewed-by: Neil Armstrong Signed-off-by: Abel Vesa Reviewed-by: Konrad Dybcio Tested-by: Neil Armstrong # on SM8650-QRD Link: https://lore.kernel.org/r/20240221-dts-qcom-sm8550-fix-spmi-chnls-siz= e-v2-2-72b5efd9dc4f@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/arm64/boot/dts/qcom/sm8650.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi b/arch/arm64/boot/dts/qco= m/sm8650.dtsi index bad0eb84549fe..0e4bd83b2c68a 100644 --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi @@ -3705,7 +3705,7 @@ sram@c3f0000 { spmi_bus: spmi@c400000 { compatible =3D "qcom,spmi-pmic-arb"; reg =3D <0 0x0c400000 0 0x3000>, - <0 0x0c500000 0 0x4000000>, + <0 0x0c500000 0 0x400000>, <0 0x0c440000 0 0x80000>, <0 0x0c4c0000 0 0x20000>, <0 0x0c42d000 0 0x4000>; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BB5A1175CBC; Sun, 24 Mar 2024 22:39:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319977; cv=none; b=nV+DqY/HIq2zLPKlYNatOTOJQ9SohYPqAADBoC451qe8nROlNLtSGPpLgY2iymGpvcs0X0iIJzpzJk2+zmlp5B1+t3NhtX3xh3rXCLefS6Lb/zG0+RLnplWXDAWLLdXZAEqU/5hSBjiWDOwOPqccBGrvhxkiztxLvvimpguxgJc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319977; c=relaxed/simple; bh=bu/cLGl0Ou6FdE2ZToeEYLdGrXcfFHwS3SKibvwNMpo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=eEWJ9f4qtqUpb9UHXoVu5Yc/p4TaTulWaN5DW1IfDb2IXPKIq9gEMSmouoZz/JiOG597sq5qWuUXqLyXVX/te2iHBkCNWsRmA7GHsBKGEhgvdPXJ60PJ1KD0gFJ/W1SgPptOSPn1qAA6bJXb9KH8lsqzHo9XG2nmlm2giBU7WWA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FNTPBYQM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FNTPBYQM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AD0F5C433F1; Sun, 24 Mar 2024 22:39:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319977; bh=bu/cLGl0Ou6FdE2ZToeEYLdGrXcfFHwS3SKibvwNMpo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FNTPBYQMTlnFkH71PR6uywpdHkuifORpILvMJSvyWm3jthso0eZ87Ar3zfq55Vbuy 4VbdO0FXrmai3SKLaXcVVUacvw0cr8dDFSUP+Rgnb/+Wu+KLucbPub5IP1wwGCyaXi awPCK/z0EolrhL8F1YPNW/EcU7sT3YrB+ueUuWIBZPBH6fDRykTU0RNV3SVhNVt99k YVlEz9RFqb5qryU/quBpI5RqfLFKGUC8x4CrJE9bGvcvegCupSE4ERmSxAU5GjoM5J mxTuTnDub25SuWPwjp9bIGMRpGyIsRxPk1oL2ThTM5CqmqjywG9entiYCDd9/Z5bvL qkzWZnkpMBw+g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christophe JAILLET , Ulf Hansson , Sasha Levin Subject: [PATCH 6.8 284/715] mmc: wmt-sdmmc: remove an incorrect release_mem_region() call in the .remove function Date: Sun, 24 Mar 2024 18:27:43 -0400 Message-ID: <20240324223455.1342824-285-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Christophe JAILLET [ Upstream commit ae5004a40a262d329039b99b62bd3fe7645b66ad ] This looks strange to call release_mem_region() in a remove function without any request_mem_region() in the probe or "struct resource" somewhere. So remove the corresponding code. Fixes: 3a96dff0f828 ("mmc: SD/MMC Host Controller for Wondermedia WM8505/WM= 8650") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/bb0bb1ed1e18de55e8c0547625bde271e64b8c31.17= 08983064.git.christophe.jaillet@wanadoo.fr Signed-off-by: Ulf Hansson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/mmc/host/wmt-sdmmc.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/mmc/host/wmt-sdmmc.c b/drivers/mmc/host/wmt-sdmmc.c index 77d5f1d244899..860380931b6cd 100644 --- a/drivers/mmc/host/wmt-sdmmc.c +++ b/drivers/mmc/host/wmt-sdmmc.c @@ -883,7 +883,6 @@ static void wmt_mci_remove(struct platform_device *pdev) { struct mmc_host *mmc; struct wmt_mci_priv *priv; - struct resource *res; u32 reg_tmp; =20 mmc =3D platform_get_drvdata(pdev); @@ -911,9 +910,6 @@ static void wmt_mci_remove(struct platform_device *pdev) clk_disable_unprepare(priv->clk_sdmmc); clk_put(priv->clk_sdmmc); =20 - res =3D platform_get_resource(pdev, IORESOURCE_MEM, 0); - release_mem_region(res->start, resource_size(res)); - mmc_free_host(mmc); =20 dev_info(&pdev->dev, "WMT MCI device removed\n"); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9EE93130A4D; Sun, 24 Mar 2024 22:39:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319978; cv=none; b=pcdGlJW0ZXo54l5tuWCojNy8vX2A78BnkT1IzzbaAVHOAAyW7Pzy8HWhz5fbl87mX7yI5pOvSxgp5DQBvIhagqpDE/FoS6pIWYC6ulYwiX8vjKUx1ZEHycyLpX3ScJOSRti6PC2xKiHm889PeFkB010G15LQrYPHoNn6R2J8V44= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319978; c=relaxed/simple; bh=yoUldDTV2NJujGlAxoNcWJ40t+aa06GDaoJ4gRjf/do=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dn2yFHywUrPWE8zOWxSDkaay3BrNKUD+yqREuRiOTGbez0lHG20qKE7rkNJNaScqeBqfI7G40jRM9hLmswr/UP5kYK/YlQ6R/XX1mIMMACml7gyCXJUSBsCpSVBgBp15O8Vm8CjORvkcB9AcT074p3au50ve6BdWJitgD1xhdTU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gOyzzzjT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gOyzzzjT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 99BD4C43601; Sun, 24 Mar 2024 22:39:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319978; bh=yoUldDTV2NJujGlAxoNcWJ40t+aa06GDaoJ4gRjf/do=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gOyzzzjTfRlOT/Mfb3OlEfbJcRpv1IdiXE3oA9tJih63muFH2RVgqZGvoab5gAEBr ym7zNi798T9m3hLpyE+zyuycrp+SkWYJFJWxJrgHc5UlIVJrQDVsjA2QEdFLkVm28G K6afLnAFhzclCc0tQZSQs91/9xbWXs4a6YRTR0iT9bWV4U8A39x6AMn///BdfcgBYE YV1COK0iUJLfLxGkY7bIUIlWsUTwekzrIX+jbWnK+HtW5ifiA4cF1oNyV3HFsze5cf +hnJEuhfQZjkFuAFqefZjohmaCSL8fXUCY1fmkiiEF/ndK+GoSIKsyNEitaC1NXX9+ pNNxj7jEb4GJA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Perry Yuan , Mario Limonciello , Gino Badouri , "Gautham R . Shenoy" , "Rafael J . Wysocki" , Sasha Levin Subject: [PATCH 6.8 285/715] ACPI: CPPC: enable AMD CPPC V2 support for family 17h processors Date: Sun, 24 Mar 2024 18:27:44 -0400 Message-ID: <20240324223455.1342824-286-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Perry Yuan [ Upstream commit a51ab63b297ce9e26e3ffb9be896018a42d5f32f ] As there are some AMD processors which only support CPPC V2 firmware and BIOS implementation, the amd_pstate driver will be failed to load when system booting with below kernel warning message: [ 0.477523] amd_pstate: the _CPC object is not present in SBIOS or ACPI = disabled To make the amd_pstate driver can be loaded on those TR40 processors, it needs to match x86_model from 0x30 to 0x7F for family 17H. With the change, the system can load amd_pstate driver as expected. Reviewed-by: Mario Limonciello Reported-by: Gino Badouri Closes: https://bugzilla.kernel.org/show_bug.cgi?id=3D218171 Fixes: fbd74d1689 ("ACPI: CPPC: Fix enabling CPPC on AMD systems with share= d memory") Signed-off-by: Perry Yuan Reviewed-by: Gautham R. Shenoy Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/x86/kernel/acpi/cppc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kernel/acpi/cppc.c b/arch/x86/kernel/acpi/cppc.c index 8d8752b44f113..ff8f25faca3dd 100644 --- a/arch/x86/kernel/acpi/cppc.c +++ b/arch/x86/kernel/acpi/cppc.c @@ -20,7 +20,7 @@ bool cpc_supported_by_cpu(void) (boot_cpu_data.x86_model >=3D 0x20 && boot_cpu_data.x86_model <=3D 0= x2f))) return true; else if (boot_cpu_data.x86 =3D=3D 0x17 && - boot_cpu_data.x86_model >=3D 0x70 && boot_cpu_data.x86_model <=3D 0x7f) + boot_cpu_data.x86_model >=3D 0x30 && boot_cpu_data.x86_model <=3D 0x7f) return true; return boot_cpu_has(X86_FEATURE_CPPC); } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9BF94130A6E; Sun, 24 Mar 2024 22:39:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319979; cv=none; b=c9xPlIlkNO9/SNCeKYxo9czP7Kw9lQgy5z30eXKDXHSa3wlSr7dvo8wUHoRW3s4QE7dr7Bi9xGjbCi+BJZ8gInh65mS+BQZFLK9CeT5OfQiMiKaxuw0Y2IHUtS0Dbg31B3aWS8H52ZJcIBNPvT7uLNFntbxx/YPcUwzy4et7k14= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319979; c=relaxed/simple; bh=R9B4lL1lL2pQWZMKSMku/DSdwCaHjPU1Eeal9bS1cgM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AKz7Q5D56DvynKWuBOa+six3GRNQwXIIFMPlZjE3NTKa+eOpetAE+Ba+Z2cYyvcj2ZEJKQY9/9wj6SY5yWY9NzE39fno4Q9ArqnNiUir3RdE4mcbYOOXOf6nXzFiDWLUS/HirOICWbU8dc3FmPqqmpfKytpBXon+plQXoT2Cg1Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eMna+JM/; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eMna+JM/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C46D6C433C7; Sun, 24 Mar 2024 22:39:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319979; bh=R9B4lL1lL2pQWZMKSMku/DSdwCaHjPU1Eeal9bS1cgM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eMna+JM/3z/ETg9Gfqr56XxwQr+9rVLusDYE+3ri4yNcZ2I23eM1qgcp/tMCjQjpy 9uayRhcUoq70TUqH+tVsOkXiNqoOA78UARWCVWQlG5q1HGTtPcDc/BppiOzpsac7AX +kEMbVtS/t68NQ9awIHEG4Ixbf+nl3JyJMggEwvBijs2M4C1NHZ2q2VUAaTK49S0wU 94y6iwn363Smo24zbTw+YhMKBhXuSw4O1ms4dtLyxzMtBMamGYyxIlna3jDbffByQH epEDmbkAG+8B27UD87V/c0d5U56zJ0lBrQ5flgZ81wbfQ+MIX83NKDk9YbKbYQAEx/ kwnFABKm8Ma5w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Filipe Manana , Josef Bacik , David Sterba , Sasha Levin Subject: [PATCH 6.8 286/715] btrfs: fix race when detecting delalloc ranges during fiemap Date: Sun, 24 Mar 2024 18:27:45 -0400 Message-ID: <20240324223455.1342824-287-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Filipe Manana [ Upstream commit 978b63f7464abcfd364a6c95f734282c50f3decf ] For fiemap we recently stopped locking the target extent range for the whole duration of the fiemap call, in order to avoid a deadlock in a scenario where the fiemap buffer happens to be a memory mapped range of the same file. This use case is very unlikely to be useful in practice but it may be triggered by fuzz testing (syzbot, etc). This however introduced a race that makes us miss delalloc ranges for file regions that are currently holes, so the caller of fiemap will not be aware that there's data for some file regions. This can be quite serious for some use cases - for example in coreutils versions before 9.0, the cp program used fiemap to detect holes and data in the source file, copying only regions with data (extents or delalloc) from the source file to the destination file in order to preserve holes (see the documentation for its --sparse command line option). This means that if cp was used with a source file that had delalloc in a hole, the destination file could end up without that data, which is effectively a data loss issue, if it happened to hit the race described below. The race happens like this: 1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that has delalloc in the file range [64M, 65M[, which is currently a hole; 2) Fiemap locks the inode in shared mode, then starts iterating the inode's subvolume tree searching for file extent items, without having the whole fiemap target range locked in the inode's io tree - the change introduced recently by commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking"). It only locks ranges in the io tree when it finds a hole or prealloc extent since that commit; 3) Note that fiemap clones each leaf before using it, and this is to avoid deadlocks when locking a file range in the inode's io tree and the fiemap buffer is memory mapped to some file, because writing to the page with btrfs_page_mkwrite() will wait on any ordered extent for the page's range and the ordered extent needs to lock the range and may need to modify the same leaf, therefore leading to a deadlock on the leaf; 4) While iterating the file extent items in the cloned leaf before finding the hole in the range [64M, 65M[, the delalloc in that range is flushed and its ordered extent completes - meaning the corresponding file extent item is in the inode's subvolume tree, but not present in the cloned leaf that fiemap is iterating over; 5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in the cloned leaf (or a file extent item with disk_bytenr =3D=3D 0 in case the NO_HOLES feature is not enabled), it will lock that file range in the inode's io tree and then search for delalloc by checking for the EXTENT_DELALLOC bit in the io tree for that range and ordered extents (with btrfs_find_delalloc_in_range()). But it finds nothing since the delalloc in that range was already flushed and the ordered extent completed and is gone - as a result fiemap will not report that there's delalloc or an extent for the range [64M, 65M[, so user space will be mislead into thinking that there's a hole in that range. This could actually be sporadically triggered with test case generic/094 from fstests, which reports a missing extent/delalloc range like this: # generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstest= s/results//generic/094.out.bad) # --- tests/generic/094.out 2020-06-10 19:29:03.830519425 +0100 # +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad 202= 4-02-28 11:00:00.381071525 +0000 # @@ -1,3 +1,9 @@ # QA output created by 094 # fiemap run with sync # fiemap run without sync # +ERROR: couldn't find extent at 7 # +map is 'HHDDHPPDPHPH' # +logical: [ 5.. 6] phys: 301517.. 301518 flags: 0x800= tot: 2 # +logical: [ 8.. 8] phys: 301520.. 301520 flags: 0x800= tot: 1 # ... # (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/generic/094.out = /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad' to see the e= ntire diff) So in order to fix this, while still avoiding deadlocks in the case where the fiemap buffer is memory mapped to the same file, change fiemap to work like the following: 1) Always lock the whole range in the inode's io tree before starting to iterate the inode's subvolume tree searching for file extent items, just like we did before commit b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking"); 2) Now instead of writing to the fiemap buffer every time we have an extent to report, write instead to a temporary buffer (1 page), and when that buffer becomes full, stop iterating the file extent items, unlock the range in the io tree, release the search path, submit all the entries kept in that buffer to the fiemap buffer, and then resume the search for file extent items after locking again the remainder of the range in the io tree. The buffer having a size of a page, allows for 146 entries in a system with 4K pages. This is a large enough value to have a good performance by avoiding too many restarts of the search for file extent items. In other words this preserves the huge performance gains made in the last two years to fiemap, while avoiding the deadlocks in case the fiemap buffer is memory mapped to the same file (useless in practice, but possible and exercised by fuzz testing and syzbot). Fixes: b0ad381fa769 ("btrfs: fix deadlock with fiemap and extent locking") Reviewed-by: Josef Bacik Signed-off-by: Filipe Manana Signed-off-by: David Sterba Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- fs/btrfs/extent_io.c | 221 +++++++++++++++++++++++++++++++------------ 1 file changed, 160 insertions(+), 61 deletions(-) diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 8b4bef05e2221..7761d7d93ba98 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2453,12 +2453,65 @@ int try_release_extent_mapping(struct page *page, g= fp_t mask) return try_release_extent_state(tree, page, mask); } =20 +struct btrfs_fiemap_entry { + u64 offset; + u64 phys; + u64 len; + u32 flags; +}; + /* - * To cache previous fiemap extent + * Indicate the caller of emit_fiemap_extent() that it needs to unlock the= file + * range from the inode's io tree, unlock the subvolume tree search path, = flush + * the fiemap cache and relock the file range and research the subvolume t= ree. + * The value here is something negative that can't be confused with a valid + * errno value and different from 1 because that's also a return value from + * fiemap_fill_next_extent() and also it's often used to mean some btree s= earch + * did not find a key, so make it some distinct negative value. + */ +#define BTRFS_FIEMAP_FLUSH_CACHE (-(MAX_ERRNO + 1)) + +/* + * Used to: + * + * - Cache the next entry to be emitted to the fiemap buffer, so that we c= an + * merge extents that are contiguous and can be grouped as a single one; * - * Will be used for merging fiemap extent + * - Store extents ready to be written to the fiemap buffer in an intermed= iary + * buffer. This intermediary buffer is to ensure that in case the fiemap + * buffer is memory mapped to the fiemap target file, we don't deadlock + * during btrfs_page_mkwrite(). This is because during fiemap we are loc= king + * an extent range in order to prevent races with delalloc flushing and + * ordered extent completion, which is needed in order to reliably detect + * delalloc in holes and prealloc extents. And this can lead to a deadlo= ck + * if the fiemap buffer is memory mapped to the file we are running fiem= ap + * against (a silly, useless in practice scenario, but possible) because + * btrfs_page_mkwrite() will try to lock the same extent range. */ struct fiemap_cache { + /* An array of ready fiemap entries. */ + struct btrfs_fiemap_entry *entries; + /* Number of entries in the entries array. */ + int entries_size; + /* Index of the next entry in the entries array to write to. */ + int entries_pos; + /* + * Once the entries array is full, this indicates what's the offset for + * the next file extent item we must search for in the inode's subvolume + * tree after unlocking the extent range in the inode's io tree and + * releasing the search path. + */ + u64 next_search_offset; + /* + * This matches struct fiemap_extent_info::fi_mapped_extents, we use it + * to count ourselves emitted extents and stop instead of relying on + * fiemap_fill_next_extent() because we buffer ready fiemap entries at + * the @entries array, and we want to stop as soon as we hit the max + * amount of extents to map, not just to save time but also to make the + * logic at extent_fiemap() simpler. + */ + unsigned int extents_mapped; + /* Fields for the cached extent (unsubmitted, not ready, extent). */ u64 offset; u64 phys; u64 len; @@ -2466,6 +2519,28 @@ struct fiemap_cache { bool cached; }; =20 +static int flush_fiemap_cache(struct fiemap_extent_info *fieinfo, + struct fiemap_cache *cache) +{ + for (int i =3D 0; i < cache->entries_pos; i++) { + struct btrfs_fiemap_entry *entry =3D &cache->entries[i]; + int ret; + + ret =3D fiemap_fill_next_extent(fieinfo, entry->offset, + entry->phys, entry->len, + entry->flags); + /* + * Ignore 1 (reached max entries) because we keep track of that + * ourselves in emit_fiemap_extent(). + */ + if (ret < 0) + return ret; + } + cache->entries_pos =3D 0; + + return 0; +} + /* * Helper to submit fiemap extent. * @@ -2480,8 +2555,8 @@ static int emit_fiemap_extent(struct fiemap_extent_in= fo *fieinfo, struct fiemap_cache *cache, u64 offset, u64 phys, u64 len, u32 flags) { + struct btrfs_fiemap_entry *entry; u64 cache_end; - int ret =3D 0; =20 /* Set at the end of extent_fiemap(). */ ASSERT((flags & FIEMAP_EXTENT_LAST) =3D=3D 0); @@ -2494,7 +2569,9 @@ static int emit_fiemap_extent(struct fiemap_extent_in= fo *fieinfo, * find an extent that starts at an offset behind the end offset of the * previous extent we processed. This happens if fiemap is called * without FIEMAP_FLAG_SYNC and there are ordered extents completing - * while we call btrfs_next_leaf() (through fiemap_next_leaf_item()). + * after we had to unlock the file range, release the search path, emit + * the fiemap extents stored in the buffer (cache->entries array) and + * the lock the remainder of the range and re-search the btree. * * For example we are in leaf X processing its last item, which is the * file extent item for file range [512K, 1M[, and after @@ -2607,11 +2684,35 @@ static int emit_fiemap_extent(struct fiemap_extent_= info *fieinfo, =20 emit: /* Not mergeable, need to submit cached one */ - ret =3D fiemap_fill_next_extent(fieinfo, cache->offset, cache->phys, - cache->len, cache->flags); - cache->cached =3D false; - if (ret) - return ret; + + if (cache->entries_pos =3D=3D cache->entries_size) { + /* + * We will need to research for the end offset of the last + * stored extent and not from the current offset, because after + * unlocking the range and releasing the path, if there's a hole + * between that end offset and this current offset, a new extent + * may have been inserted due to a new write, so we don't want + * to miss it. + */ + entry =3D &cache->entries[cache->entries_size - 1]; + cache->next_search_offset =3D entry->offset + entry->len; + cache->cached =3D false; + + return BTRFS_FIEMAP_FLUSH_CACHE; + } + + entry =3D &cache->entries[cache->entries_pos]; + entry->offset =3D cache->offset; + entry->phys =3D cache->phys; + entry->len =3D cache->len; + entry->flags =3D cache->flags; + cache->entries_pos++; + cache->extents_mapped++; + + if (cache->extents_mapped =3D=3D fieinfo->fi_extents_max) { + cache->cached =3D false; + return 1; + } assign: cache->cached =3D true; cache->offset =3D offset; @@ -2737,8 +2838,8 @@ static int fiemap_search_slot(struct btrfs_inode *ino= de, struct btrfs_path *path * neighbour leaf). * We also need the private clone because holding a read lock on an * extent buffer of the subvolume's b+tree will make lockdep unhappy - * when we call fiemap_fill_next_extent(), because that may cause a page - * fault when filling the user space buffer with fiemap data. + * when we check if extents are shared, as backref walking may need to + * lock the same leaf we are processing. */ clone =3D btrfs_clone_extent_buffer(path->nodes[0]); if (!clone) @@ -2778,34 +2879,16 @@ static int fiemap_process_hole(struct btrfs_inode *= inode, * it beyond i_size. */ while (cur_offset < end && cur_offset < i_size) { - struct extent_state *cached_state =3D NULL; u64 delalloc_start; u64 delalloc_end; u64 prealloc_start; - u64 lockstart; - u64 lockend; u64 prealloc_len =3D 0; bool delalloc; =20 - lockstart =3D round_down(cur_offset, inode->root->fs_info->sectorsize); - lockend =3D round_up(end, inode->root->fs_info->sectorsize); - - /* - * We are only locking for the delalloc range because that's the - * only thing that can change here. With fiemap we have a lock - * on the inode, so no buffered or direct writes can happen. - * - * However mmaps and normal page writeback will cause this to - * change arbitrarily. We have to lock the extent lock here to - * make sure that nobody messes with the tree while we're doing - * btrfs_find_delalloc_in_range. - */ - lock_extent(&inode->io_tree, lockstart, lockend, &cached_state); delalloc =3D btrfs_find_delalloc_in_range(inode, cur_offset, end, delalloc_cached_state, &delalloc_start, &delalloc_end); - unlock_extent(&inode->io_tree, lockstart, lockend, &cached_state); if (!delalloc) break; =20 @@ -2973,6 +3056,7 @@ int extent_fiemap(struct btrfs_inode *inode, struct f= iemap_extent_info *fieinfo, u64 start, u64 len) { const u64 ino =3D btrfs_ino(inode); + struct extent_state *cached_state =3D NULL; struct extent_state *delalloc_cached_state =3D NULL; struct btrfs_path *path; struct fiemap_cache cache =3D { 0 }; @@ -2985,26 +3069,33 @@ int extent_fiemap(struct btrfs_inode *inode, struct= fiemap_extent_info *fieinfo, bool stopped =3D false; int ret; =20 + cache.entries_size =3D PAGE_SIZE / sizeof(struct btrfs_fiemap_entry); + cache.entries =3D kmalloc_array(cache.entries_size, + sizeof(struct btrfs_fiemap_entry), + GFP_KERNEL); backref_ctx =3D btrfs_alloc_backref_share_check_ctx(); path =3D btrfs_alloc_path(); - if (!backref_ctx || !path) { + if (!cache.entries || !backref_ctx || !path) { ret =3D -ENOMEM; goto out; } =20 +restart: range_start =3D round_down(start, sectorsize); range_end =3D round_up(start + len, sectorsize); prev_extent_end =3D range_start; =20 + lock_extent(&inode->io_tree, range_start, range_end, &cached_state); + ret =3D fiemap_find_last_extent_offset(inode, path, &last_extent_end); if (ret < 0) - goto out; + goto out_unlock; btrfs_release_path(path); =20 path->reada =3D READA_FORWARD; ret =3D fiemap_search_slot(inode, path, range_start); if (ret < 0) { - goto out; + goto out_unlock; } else if (ret > 0) { /* * No file extent item found, but we may have delalloc between @@ -3051,7 +3142,7 @@ int extent_fiemap(struct btrfs_inode *inode, struct f= iemap_extent_info *fieinfo, backref_ctx, 0, 0, 0, prev_extent_end, hole_end); if (ret < 0) { - goto out; + goto out_unlock; } else if (ret > 0) { /* fiemap_fill_next_extent() told us to stop. */ stopped =3D true; @@ -3107,7 +3198,7 @@ int extent_fiemap(struct btrfs_inode *inode, struct f= iemap_extent_info *fieinfo, extent_gen, backref_ctx); if (ret < 0) - goto out; + goto out_unlock; else if (ret > 0) flags |=3D FIEMAP_EXTENT_SHARED; } @@ -3118,9 +3209,9 @@ int extent_fiemap(struct btrfs_inode *inode, struct f= iemap_extent_info *fieinfo, } =20 if (ret < 0) { - goto out; + goto out_unlock; } else if (ret > 0) { - /* fiemap_fill_next_extent() told us to stop. */ + /* emit_fiemap_extent() told us to stop. */ stopped =3D true; break; } @@ -3129,12 +3220,12 @@ int extent_fiemap(struct btrfs_inode *inode, struct= fiemap_extent_info *fieinfo, next_item: if (fatal_signal_pending(current)) { ret =3D -EINTR; - goto out; + goto out_unlock; } =20 ret =3D fiemap_next_leaf_item(inode, path); if (ret < 0) { - goto out; + goto out_unlock; } else if (ret > 0) { /* No more file extent items for this inode. */ break; @@ -3143,22 +3234,12 @@ int extent_fiemap(struct btrfs_inode *inode, struct= fiemap_extent_info *fieinfo, } =20 check_eof_delalloc: - /* - * Release (and free) the path before emitting any final entries to - * fiemap_fill_next_extent() to keep lockdep happy. This is because - * once we find no more file extent items exist, we may have a - * non-cloned leaf, and fiemap_fill_next_extent() can trigger page - * faults when copying data to the user space buffer. - */ - btrfs_free_path(path); - path =3D NULL; - if (!stopped && prev_extent_end < range_end) { ret =3D fiemap_process_hole(inode, fieinfo, &cache, &delalloc_cached_state, backref_ctx, 0, 0, 0, prev_extent_end, range_end - 1); if (ret < 0) - goto out; + goto out_unlock; prev_extent_end =3D range_end; } =20 @@ -3166,28 +3247,16 @@ int extent_fiemap(struct btrfs_inode *inode, struct= fiemap_extent_info *fieinfo, const u64 i_size =3D i_size_read(&inode->vfs_inode); =20 if (prev_extent_end < i_size) { - struct extent_state *cached_state =3D NULL; u64 delalloc_start; u64 delalloc_end; - u64 lockstart; - u64 lockend; bool delalloc; =20 - lockstart =3D round_down(prev_extent_end, sectorsize); - lockend =3D round_up(i_size, sectorsize); - - /* - * See the comment in fiemap_process_hole as to why - * we're doing the locking here. - */ - lock_extent(&inode->io_tree, lockstart, lockend, &cached_state); delalloc =3D btrfs_find_delalloc_in_range(inode, prev_extent_end, i_size - 1, &delalloc_cached_state, &delalloc_start, &delalloc_end); - unlock_extent(&inode->io_tree, lockstart, lockend, &cached_state); if (!delalloc) cache.flags |=3D FIEMAP_EXTENT_LAST; } else { @@ -3195,9 +3264,39 @@ int extent_fiemap(struct btrfs_inode *inode, struct = fiemap_extent_info *fieinfo, } } =20 +out_unlock: + unlock_extent(&inode->io_tree, range_start, range_end, &cached_state); + + if (ret =3D=3D BTRFS_FIEMAP_FLUSH_CACHE) { + btrfs_release_path(path); + ret =3D flush_fiemap_cache(fieinfo, &cache); + if (ret) + goto out; + len -=3D cache.next_search_offset - start; + start =3D cache.next_search_offset; + goto restart; + } else if (ret < 0) { + goto out; + } + + /* + * Must free the path before emitting to the fiemap buffer because we + * may have a non-cloned leaf and if the fiemap buffer is memory mapped + * to a file, a write into it (through btrfs_page_mkwrite()) may trigger + * waiting for an ordered extent that in order to complete needs to + * modify that leaf, therefore leading to a deadlock. + */ + btrfs_free_path(path); + path =3D NULL; + + ret =3D flush_fiemap_cache(fieinfo, &cache); + if (ret) + goto out; + ret =3D emit_last_fiemap_cache(fieinfo, &cache); out: free_extent_state(delalloc_cached_state); + kfree(cache.entries); btrfs_free_backref_share_ctx(backref_ctx); btrfs_free_path(path); return ret; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CADC41769E4; Sun, 24 Mar 2024 22:39:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319980; cv=none; b=FAgpeX2jj5pJf80n+QnkjqayjjXTwn9VA0WpsDpDeM9ptU/vfFb9uRwjcXZL+gqsfXMVJ9/o7Nx4nWFTRaHJUOmFVay53bJdvPHM8rGA5PuGdEdb3ZhWQ/mVLRIk/r21GsdUoqsHW5HKINURdqrqxcp1h/8c6zlJxkf+ycSqM0w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319980; c=relaxed/simple; bh=k9fXtCbqXNZ0AnUWWV++CufZSs17sIiecx+63pb9vlI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uc122Fn+eTevhl5k7ihxwsZbrQbZpcDq0B76gPRYKu8NQthbfWp45xKiin9FqZW8RRSawON72wNyafJkqK1veauD8/nUv6FnhU2r8nZkrXdxs0VFwtLufG9hjmEw7GRTkh7qFsEXm8A5ckEbd4luH2WajnnE3OADlURScLUhj5c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HFrQ92eC; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HFrQ92eC" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C06D6C433F1; Sun, 24 Mar 2024 22:39:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319980; bh=k9fXtCbqXNZ0AnUWWV++CufZSs17sIiecx+63pb9vlI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HFrQ92eC45Ll9sTswyYvPNnBNyd+VjNjV3XLeYfAy6wbGj/FrHodv1s+/9W2TI3uF U9OstyeplxmTx5XUMxc7uZZyEtyllJbXAgzhV44COOFTAVxo3ztBqj8Giyqir4xlyT lL8eQJrdL+3PD5l58rlMpJjgH4Gw/5WOp1LOu7tiy/1LUfo6uWRc0UVaNNlkd96ToF V+I5wkLjb7AzU1qjlw5vEjJDJXava+7aA6274xiNT6QMn2nKGbNtHR/+6YlZQaeDtB 1CK85q+GgAnsjdm3tCJdmQYVYJZXqpnUXGJBjJEZWFNWsN+8Z+0lJtEn31hHfciKwv 60aOOvDOfVNYA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bitterblue Smith , Ping-Ke Shih , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 287/715] wifi: rtw88: 8821cu: Fix firmware upload fail Date: Sun, 24 Mar 2024 18:27:46 -0400 Message-ID: <20240324223455.1342824-288-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bitterblue Smith [ Upstream commit 41a7acb7dde8395f52a707bbba7712a898dfafb0 ] RTL8822CU, RTL8822BU, and RTL8821CU need an extra register write after reading and writing certain addresses. Without this, the firmware upload fails approximately more than 50% of the time. Tested with RTL8811CU (Tenda U9 V2.0) which is the same as RTL8821CU but without Bluetooth. Fixes: a82dfd33d123 ("wifi: rtw88: Add common USB chip support") Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://msgid.link/f12ed39d-28e8-4b8b-8d22-447bcf295afc@gmail.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/realtek/rtw88/usb.c | 40 ++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireles= s/realtek/rtw88/usb.c index e6ab1ac6d7093..a0188511099a1 100644 --- a/drivers/net/wireless/realtek/rtw88/usb.c +++ b/drivers/net/wireless/realtek/rtw88/usb.c @@ -33,6 +33,36 @@ static void rtw_usb_fill_tx_checksum(struct rtw_usb *rtw= usb, rtw_tx_fill_txdesc_checksum(rtwdev, &pkt_info, skb->data); } =20 +static void rtw_usb_reg_sec(struct rtw_dev *rtwdev, u32 addr, __le32 *data) +{ + struct rtw_usb *rtwusb =3D rtw_get_usb_priv(rtwdev); + struct usb_device *udev =3D rtwusb->udev; + bool reg_on_section =3D false; + u16 t_reg =3D 0x4e0; + u8 t_len =3D 1; + int status; + + /* There are three sections: + * 1. on (0x00~0xFF; 0x1000~0x10FF): this section is always powered on + * 2. off (< 0xFE00, excluding "on" section): this section could be + * powered off + * 3. local (>=3D 0xFE00): usb specific registers section + */ + if (addr <=3D 0xff || (addr >=3D 0x1000 && addr <=3D 0x10ff)) + reg_on_section =3D true; + + if (!reg_on_section) + return; + + status =3D usb_control_msg(udev, usb_sndctrlpipe(udev, 0), + RTW_USB_CMD_REQ, RTW_USB_CMD_WRITE, + t_reg, 0, data, t_len, 500); + + if (status !=3D t_len && status !=3D -ENODEV) + rtw_err(rtwdev, "%s: reg 0x%x, usb write %u fail, status: %d\n", + __func__, t_reg, t_len, status); +} + static u32 rtw_usb_read(struct rtw_dev *rtwdev, u32 addr, u16 len) { struct rtw_usb *rtwusb =3D rtw_get_usb_priv(rtwdev); @@ -58,6 +88,11 @@ static u32 rtw_usb_read(struct rtw_dev *rtwdev, u32 addr= , u16 len) rtw_err(rtwdev, "read register 0x%x failed with %d\n", addr, ret); =20 + if (rtwdev->chip->id =3D=3D RTW_CHIP_TYPE_8822C || + rtwdev->chip->id =3D=3D RTW_CHIP_TYPE_8822B || + rtwdev->chip->id =3D=3D RTW_CHIP_TYPE_8821C) + rtw_usb_reg_sec(rtwdev, addr, data); + return le32_to_cpu(*data); } =20 @@ -102,6 +137,11 @@ static void rtw_usb_write(struct rtw_dev *rtwdev, u32 = addr, u32 val, int len) if (ret < 0 && ret !=3D -ENODEV && count++ < 4) rtw_err(rtwdev, "write register 0x%x failed with %d\n", addr, ret); + + if (rtwdev->chip->id =3D=3D RTW_CHIP_TYPE_8822C || + rtwdev->chip->id =3D=3D RTW_CHIP_TYPE_8822B || + rtwdev->chip->id =3D=3D RTW_CHIP_TYPE_8821C) + rtw_usb_reg_sec(rtwdev, addr, data); } =20 static void rtw_usb_write8(struct rtw_dev *rtwdev, u32 addr, u8 val) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E8AB6176A03; Sun, 24 Mar 2024 22:39:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319982; cv=none; b=glt+Qy0QiBWjjQI50gPb7Ft+EU1oh1y7l/FB9tY0W/ZOUtOnYaiL5jnpkSv3H1KXu7S04JSajZZw+syLbI+ZuLlzRywbCJLfj3KAZQE7Y36CWSh3/8Hv5VIdcbSMyegCTX5U0ZQsGWjm+OvxizF3UTQoOryhRBusxDg6saxthFs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319982; c=relaxed/simple; bh=1Ex5kFBpZC5U0wW56mG+2vwHB7YDpbOowaTErJyFC9o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AG2wQi54QBXyAYM526RHI1oaiBYmgWnIzdG9VSXlzG1xcWSEgQyDrwL6bcWm/CSKAigjwLFA9hsEecZFRiVumxSF+TvHWpPOJk6KVKIm/FpN4gIlzNGG0zK4ntLq23zX9EBBfJ2TT0v511YwFUesdFI69CfAVs+4vzZiVE51XrE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AVWTE4fv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AVWTE4fv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BB90CC43330; Sun, 24 Mar 2024 22:39:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319981; bh=1Ex5kFBpZC5U0wW56mG+2vwHB7YDpbOowaTErJyFC9o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AVWTE4fvWFoEmMkZPXD3EOToaYVaJ6JjHf2NwQlPFojC9xMVN3c/I92tKcIgyrX38 VijdBi2cxtxKFY31HlwJuS6thqEno+hrHJUqLf9bT8yP/V2qUnpaEsH7MLSJ5Mmjt+ Su4Si4vxZ5yqdJuH46KfWNAiA3bjCRNVXKr9lQ79kgrP3zMwoGo5qUzEen6rXjYSmu zWnqVU2WjXjHsXRYHuEU6eg4TPRDFZ25HJvaf2M3ciPuak9dBACtUPvxL8XvvE4Xa5 t0nC/qzi0Sa8HykzLYIpDIcenoX/e5lwnO8pv/kf3PZpxDZT8T1t0wt5QI2T7TDhgy GDZT85eTds0zA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bitterblue Smith , Ping-Ke Shih , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 288/715] wifi: rtw88: 8821c: Fix beacon loss and disconnect Date: Sun, 24 Mar 2024 18:27:47 -0400 Message-ID: <20240324223455.1342824-289-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bitterblue Smith [ Upstream commit e1dfa21427baeb813f9a2f9ceab6b7d32c3ca425 ] Tenda U9 V2.0, which contains RTL8811CU, is practically unusable because of frequent disconnections: Feb 23 14:46:45 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-BEACON= -LOSS Feb 23 14:46:46 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-DISCON= NECTED bssid=3D90:55:de:__:__:__ reason=3D4 locally_generated=3D1 Feb 23 14:46:52 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-CONNEC= TED - Connection to 90:55:de:__:__:__ completed [id=3D0 id_str=3D] Feb 23 14:46:54 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-BEACON= -LOSS Feb 23 14:46:55 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-DISCON= NECTED bssid=3D90:55:de:__:__:__ reason=3D4 locally_generated=3D1 Feb 23 14:47:01 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-CONNEC= TED - Connection to 90:55:de:__:__:__ completed [id=3D0 id_str=3D] Feb 23 14:47:04 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-BEACON= -LOSS Feb 23 14:47:05 ideapad2 wpa_supplicant[427]: wlp3s0f3u2: CTRL-EVENT-DISCON= NECTED bssid=3D90:55:de:__:__:__ reason=3D4 locally_generated=3D1 This is caused by a mistake in the chip initialisation. This version of the chip requires loading an extra AGC table right after the main one, but the extra table is being loaded at the wrong time, in rtw_chip_board_info_setup(). Move the extra AGC table loading to the right place, in rtw_phy_load_tables(). The rtw_chip_board_info_setup() can only do "software" things, and rtw_phy_load_tables() can really do IO. Fixes: 5d6651fe8583 ("rtw88: 8821c: support RFE type2 wifi NIC") Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://msgid.link/276c31d8-b9a8-4e54-a3ac-09b74657aff7@gmail.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/realtek/rtw88/main.c | 2 -- drivers/net/wireless/realtek/rtw88/phy.c | 3 +++ 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wirele= ss/realtek/rtw88/main.c index 6d22628129d0d..ffba6b88f392c 100644 --- a/drivers/net/wireless/realtek/rtw88/main.c +++ b/drivers/net/wireless/realtek/rtw88/main.c @@ -2032,8 +2032,6 @@ static int rtw_chip_board_info_setup(struct rtw_dev *= rtwdev) rtw_phy_setup_phy_cond(rtwdev, hal->pkg_type); =20 rtw_phy_init_tx_power(rtwdev); - if (rfe_def->agc_btg_tbl) - rtw_load_table(rtwdev, rfe_def->agc_btg_tbl); rtw_load_table(rtwdev, rfe_def->phy_pg_tbl); rtw_load_table(rtwdev, rfe_def->txpwr_lmt_tbl); rtw_phy_tx_power_by_rate_config(hal); diff --git a/drivers/net/wireless/realtek/rtw88/phy.c b/drivers/net/wireles= s/realtek/rtw88/phy.c index 128e75a81bf3c..37ef80c9091db 100644 --- a/drivers/net/wireless/realtek/rtw88/phy.c +++ b/drivers/net/wireless/realtek/rtw88/phy.c @@ -1761,12 +1761,15 @@ static void rtw_load_rfk_table(struct rtw_dev *rtwd= ev) =20 void rtw_phy_load_tables(struct rtw_dev *rtwdev) { + const struct rtw_rfe_def *rfe_def =3D rtw_get_rfe_def(rtwdev); const struct rtw_chip_info *chip =3D rtwdev->chip; u8 rf_path; =20 rtw_load_table(rtwdev, chip->mac_tbl); rtw_load_table(rtwdev, chip->bb_tbl); rtw_load_table(rtwdev, chip->agc_tbl); + if (rfe_def->agc_btg_tbl) + rtw_load_table(rtwdev, rfe_def->agc_btg_tbl); rtw_load_rfk_table(rtwdev); =20 for (rf_path =3D 0; rf_path < rtwdev->hal.rf_path_num; rf_path++) { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98C10176A16; Sun, 24 Mar 2024 22:39:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319982; cv=none; b=gnA2n97de4ugSq9uLXdask5IlrjgAyV+eGcYIEss64Z8cL9fkC11uTG+piCeOMIRnhJySWasEWjUhnmyc02l8fyRkW/pHgk81ZQYqskQOJ462UFqKPaOyTFYpGYXUPFNxLvc7A/vzPgc85b213sU5of8P/C5XPMRFRRthTMupbE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319982; c=relaxed/simple; bh=mZScqgdFbFxEEZ5oStzghiuQovEy8pryA8k/LHb0adw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YT20pG2bH/GzuVrid9cCLW+QUk+GrVPhtYRWXjhTRLoVkIk+E8OmcbLUEjIeoA5tyWgLQI6+7xcTJB7pCQVAdyvYue3PGN0qGersrTpoQcBbxsgsOfPN1vo49ng/9PvFW21r+1oQq5oKfBJOSs7NKyLVmbAuzZIlIFQ6qA0Cahc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WUmm2wIA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WUmm2wIA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C099CC433C7; Sun, 24 Mar 2024 22:39:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319982; bh=mZScqgdFbFxEEZ5oStzghiuQovEy8pryA8k/LHb0adw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WUmm2wIAcelmmQiMkz52P3562qBLl7o+Y9b3iZXYTukAs9heGY+MkSeUC80WLrA87 7fzBqh298PzrFcxxE/3mZjXciDH4JmOJ0Ee9qdWJK2u+lv3U+Ja0d6Ly9j53XBxetR a86VEAr0MFlwIS3584DVDgZlYvP/Zd8RYdJkHoCsASQtdl0FV/SI7M9O7W4FA7lpmz vIAxZ5SV5ORg1aCCI62jXypz8xxcSTKNzi5gBJD5veaK715evbzAwoKDRduZtilvC/ M9pSjm2qKebTqSxaGiLxs+QvjU8hdGaHg1dYl6CIHWtvYpAaKbTHsQhnBZ86YRbL5a 9ZKpx/oBmQeCA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bitterblue Smith , Ping-Ke Shih , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 289/715] wifi: rtw88: 8821c: Fix false alarm count Date: Sun, 24 Mar 2024 18:27:48 -0400 Message-ID: <20240324223455.1342824-290-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bitterblue Smith [ Upstream commit c238adbc578eeb70cbc8fdd1bef3666b0f585b13 ] total_fa_cnt is supposed to include cck_fa_cnt and ofdm_fa_cnt, not just ofdm_fa_cnt. Fixes: 960361238b86 ("rtw88: 8821c: add false alarm statistics") Signed-off-by: Bitterblue Smith Acked-by: Ping-Ke Shih Signed-off-by: Kalle Valo Link: https://msgid.link/f3cb6d17-e4e4-44a7-9c9b-72aed994b5c9@gmail.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/realtek/rtw88/rtw8821c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/realtek/rtw88/rtw8821c.c b/drivers/net/wi= reless/realtek/rtw88/rtw8821c.c index 429bb420b0563..fe5d8e1883509 100644 --- a/drivers/net/wireless/realtek/rtw88/rtw8821c.c +++ b/drivers/net/wireless/realtek/rtw88/rtw8821c.c @@ -773,9 +773,9 @@ static void rtw8821c_false_alarm_statistics(struct rtw_= dev *rtwdev) =20 dm_info->cck_fa_cnt =3D cck_fa_cnt; dm_info->ofdm_fa_cnt =3D ofdm_fa_cnt; + dm_info->total_fa_cnt =3D ofdm_fa_cnt; if (cck_enable) dm_info->total_fa_cnt +=3D cck_fa_cnt; - dm_info->total_fa_cnt =3D ofdm_fa_cnt; =20 crc32_cnt =3D rtw_read32(rtwdev, REG_CRC_CCK); dm_info->cck_ok_cnt =3D FIELD_GET(GENMASK(15, 0), crc32_cnt); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA4B013C66C; Sun, 24 Mar 2024 22:39:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319983; cv=none; b=ujX7NMHSJZTISTS9+11CLZfksMKxG3T0aqv/dxq26DsFOTLw4BqthS88cP9AsKqFQRZByYXAO0SK05Ox7RdqiM0R57axVMAG83LhNM0WlusNauQzjuodsQ75+hvfNwL2Oc9SPAzoF98EyxCRzguvhqJuYWJgpnbu76c6TK9z3Pk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319983; c=relaxed/simple; bh=ODNq6VjdTAkK9hE3MwH5qsHXBCQEHWswAoxlRaHG5z0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qn//k86UjFZ9b3qnnb/Qf3pFU36eNmAalQjMSFrn17V6iDkbVKfkwd7etmCribzhBU50k80gLK163XIoMvYjaZmWYV+Ren80zj9d/dVZ6/COUf83U5J8Os6CW2Xj7sS0VmkKRZxycij3vxO0XFZoF0gXHzczXrFKrMY31jmNQzE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OGC+aCQB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OGC+aCQB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD690C433F1; Sun, 24 Mar 2024 22:39:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319983; bh=ODNq6VjdTAkK9hE3MwH5qsHXBCQEHWswAoxlRaHG5z0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OGC+aCQBfQSWjMCzEGOOAWofOuLso//5GwAhzAacjWORtT9oPJPNm+Dz8kA8h6jJe Cy+eWxglBri+EsCiOIzfNjmS6zjhrq2+fcSDNDiqT5oYKuG25P1FiVJKFaSvhNH46m fyOHqaYu8L5UhCN2qb2jGetWWWovBlYohlpv32dosqwveUxVzo7ojc/X0PXCI3BCV/ GONJlsfcpD3xwbkMXILjD87CKi3aOQro3D5OWPgpuqHkDhzz7bQ8itgj5/ZcmFYMEu 0cpUySwBM4OwgDhMHKUHFsg3A2P3+Nb7cQKCASMbksEgXjfXq1KifnEAiamvyGyX1K PQi/bIPaCIRcw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Duoming Zhou , Arend van Spriel , Kees Cook , Kalle Valo , Sasha Levin Subject: [PATCH 6.8 290/715] wifi: brcm80211: handle pmk_op allocation failure Date: Sun, 24 Mar 2024 18:27:49 -0400 Message-ID: <20240324223455.1342824-291-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Duoming Zhou [ Upstream commit b4152222e04cb8afeeca239c90e3fcaf4c553b42 ] The kzalloc() in brcmf_pmksa_v3_op() will return null if the physical memory has run out. As a result, if we dereference the null value, the null pointer dereference bug will happen. Return -ENOMEM from brcmf_pmksa_v3_op() if kzalloc() fails for pmk_op. Fixes: a96202acaea4 ("wifi: brcmfmac: cfg80211: Add support for PMKID_V3 op= erations") Acked-by: Arend van Spriel Signed-off-by: Duoming Zhou Reviewed-by: Kees Cook Signed-off-by: Kalle Valo Link: https://msgid.link/20240229103153.18533-1-duoming@zju.edu.cn Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/= drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index 28d6a30cc0106..1a5d7494f5e80 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c @@ -4322,6 +4322,9 @@ brcmf_pmksa_v3_op(struct brcmf_if *ifp, struct cfg802= 11_pmksa *pmksa, int ret; =20 pmk_op =3D kzalloc(sizeof(*pmk_op), GFP_KERNEL); + if (!pmk_op) + return -ENOMEM; + pmk_op->version =3D cpu_to_le16(BRCMF_PMKSA_VER_3); =20 if (!pmksa) { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C71F05A7B9; Sun, 24 Mar 2024 22:39:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319984; cv=none; b=can3dyQJFXZC24n/B59sko9r8jO/nvSoB6/EwORmMwarIlmiNnKcE5EyceGdFrL7UM60ZP6PuSueYcejl6bk1/gj+QW9VKKwFeV8HpEFr2ZJiPs/U7XVl08fCpDemLDNvOZuEkMo02hED8rjKHx4wIXtHTd/3R1jX69b1drWrxE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319984; c=relaxed/simple; bh=GLZteGuO3mk6l7Mu/yJVfor6rpFiIEd8o6TuZwT2rCI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZFLd9Btgg++ZSiB1y18zC/uDrzu8svqFY7K803gR8R7Q0o0f+Dqa2qCfZd18HWVY/bmmh9iVh/4SDIy8Y4gehTdbvq6S1pMWq1+cEaMN2QDuH4qWkRbVFLNVgzIiR64t57hrv8LsMzqte4kom2j4D0e2S5Dn12uN6gy9VaArsZU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GBkhexMq; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GBkhexMq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF708C43394; Sun, 24 Mar 2024 22:39:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319984; bh=GLZteGuO3mk6l7Mu/yJVfor6rpFiIEd8o6TuZwT2rCI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GBkhexMq8anokMCTaGjfA7z7nZL9VyUzV3gw1CcHqu+wmWVj8LLI3xZ7JRkccfRT/ yrEjmrNm2/g437G/VLR4q3A9uhPuk3LOKjDIJPWXQsE05ELaJMUGbEnDQFn1vSuvoT bgsjoWvvQcaKi+Igtx4NKH9Z4soOYCd6UCAegWvx+FPyxLcgecAiO+IhYTMOYRQwJo 9qafojVMDx4ax0eIoQtgZ8qeKu6bHLFo9VLkaAVACmkCGDRFxT2R/hme+9JLJ6Znm7 r3GsoHmpm5G6yy4Wnkpik6Erqy4C8IffOhK5V1l7qzS98I25JZaFTWmmdM4bDGTsI2 prwD5Ag+3cLLQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Krzysztof Kozlowski , Geert Uytterhoeven , Geert Uytterhoeven , Conor Dooley , Sasha Levin Subject: [PATCH 6.8 291/715] riscv: dts: starfive: jh7100: fix root clock names Date: Sun, 24 Mar 2024 18:27:50 -0400 Message-ID: <20240324223455.1342824-292-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Krzysztof Kozlowski [ Upstream commit 7921e231f85a349d5927b26c812c86e03f4cd37b ] JH7100 clock controller driver depends on certain root clock names. Reported-by: Geert Uytterhoeven Closes: https://lore.kernel.org/all/CAMuHMdWw0dteXO2jw4cwGvzKcL6vmnb96C=3Dq= gPgUqNDMtF6X0Q@mail.gmail.com/ Fixes: f03606470886 ("riscv: dts: starfive: replace underscores in node nam= es") Signed-off-by: Krzysztof Kozlowski Tested-by: Geert Uytterhoeven Signed-off-by: Conor Dooley Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/riscv/boot/dts/starfive/jh7100.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/riscv/boot/dts/starfive/jh7100.dtsi b/arch/riscv/boot/dts= /starfive/jh7100.dtsi index 8bcf36d07f3f7..5d499d8aa8044 100644 --- a/arch/riscv/boot/dts/starfive/jh7100.dtsi +++ b/arch/riscv/boot/dts/starfive/jh7100.dtsi @@ -116,6 +116,7 @@ cpu-crit { osc_sys: osc-sys { compatible =3D "fixed-clock"; #clock-cells =3D <0>; + clock-output-names =3D "osc_sys"; /* This value must be overridden by the board */ clock-frequency =3D <0>; }; @@ -123,6 +124,7 @@ osc_sys: osc-sys { osc_aud: osc-aud { compatible =3D "fixed-clock"; #clock-cells =3D <0>; + clock-output-names =3D "osc_aud"; /* This value must be overridden by the board */ clock-frequency =3D <0>; }; @@ -130,6 +132,7 @@ osc_aud: osc-aud { gmac_rmii_ref: gmac-rmii-ref { compatible =3D "fixed-clock"; #clock-cells =3D <0>; + clock-output-names =3D "gmac_rmii_ref"; /* Should be overridden by the board when needed */ clock-frequency =3D <0>; }; @@ -137,6 +140,7 @@ gmac_rmii_ref: gmac-rmii-ref { gmac_gr_mii_rxclk: gmac-gr-mii-rxclk { compatible =3D "fixed-clock"; #clock-cells =3D <0>; + clock-output-names =3D "gmac_gr_mii_rxclk"; /* Should be overridden by the board when needed */ clock-frequency =3D <0>; }; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0A8FA177A93; Sun, 24 Mar 2024 22:39:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319986; cv=none; b=lp7Ms7MbwRWk5W+Vn3P5TYMXbbjGs/b+ijMnhPFLScsHYBveGuGATM3ez+A7WXiaoXpRXZE41oKzvCYb7K79R5uZEzq+HRdDDpjJKH0Xi7+oRwJ5hgySow1VL06PJJmouvAQHSw4ouHh/AInS6iULcq+zkrQMRVRxrbD7ISU7ic= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319986; c=relaxed/simple; bh=c5vcWHI1lXaAgL3ymV8nfDcQqZ2uWduNr5eQVUN5HlY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=n4+S+zMiKdU/tnUgm3G5Sm5cLBXp6qVUoVoetM20uGd6J4lc3dA4Kmw5zBfSqV+/0ZpAB2vNm+YZHnUvOyxC2x/7aIeFfcDMaElXdbr59F/BISOlxlN0U2X17EfEQZr4XK3dy68Q+pvSJ+41HMIkLV7QyhTbQkOHlpyefY5DqRo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RlKUOExk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RlKUOExk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E4624C43390; Sun, 24 Mar 2024 22:39:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319985; bh=c5vcWHI1lXaAgL3ymV8nfDcQqZ2uWduNr5eQVUN5HlY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RlKUOExkqtiuejUjLhyqdvLLXKEEgTdFP2OpDExslrTLI5psezsMnJlChP+nnIqh+ tZyUssVdAXzTIWzGE+VtPS+pvO94kwrT1Qhp8KazCB1MXNMj2saM5XUIn5cs9qXwhQ qgzcmBaENF7B0DvmfXHgbwIu/GpBu7iliq4Jvmwl/E77ayLtt0r/sX+bL0t5I7bB9Z o3Dg8WmFEDhvYoAMlf/n1GaRapID2KGKh4m0sbI7R+p8iZGfgV3JhwtKE++LqsK2LR slrHTvAa92/dxTeaPGtmdlCyTpzrgMjXk8BPtZpNDanwwoA7OgNnRBz2KiE1+lA8ve OANwureZH0afw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ethan Zhao , Bjorn Helgaas , Dan Carpenter , Haorong Ye , Lu Baolu , Joerg Roedel , Sasha Levin Subject: [PATCH 6.8 292/715] PCI: Make pci_dev_is_disconnected() helper public for other drivers Date: Sun, 24 Mar 2024 18:27:51 -0400 Message-ID: <20240324223455.1342824-293-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ethan Zhao [ Upstream commit 39714fd73c6b60a8d27bcc5b431afb0828bf4434 ] Make pci_dev_is_disconnected() public so that it can be called from Intel VT-d driver to quickly fix/workaround the surprise removal unplug hang issue for those ATS capable devices on PCIe switch downstream hotplug capable ports. Beside pci_device_is_present() function, this one has no config space space access, so is light enough to optimize the normal pure surprise removal and safe removal flow. Acked-by: Bjorn Helgaas Reviewed-by: Dan Carpenter Tested-by: Haorong Ye Signed-off-by: Ethan Zhao Link: https://lore.kernel.org/r/20240301080727.3529832-2-haifeng.zhao@linux= .intel.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Stable-dep-of: 4fc82cd907ac ("iommu/vt-d: Don't issue ATS Invalidation requ= est when device is disconnected") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/pci/pci.h | 5 ----- include/linux/pci.h | 5 +++++ 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h index e9750b1b19bad..bfc56f7bee1c9 100644 --- a/drivers/pci/pci.h +++ b/drivers/pci/pci.h @@ -368,11 +368,6 @@ static inline int pci_dev_set_disconnected(struct pci_= dev *dev, void *unused) return 0; } =20 -static inline bool pci_dev_is_disconnected(const struct pci_dev *dev) -{ - return dev->error_state =3D=3D pci_channel_io_perm_failure; -} - /* pci_dev priv_flags */ #define PCI_DEV_ADDED 0 #define PCI_DPC_RECOVERED 1 diff --git a/include/linux/pci.h b/include/linux/pci.h index 7ab0d13672daf..213109d3c601d 100644 --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -2517,6 +2517,11 @@ static inline struct pci_dev *pcie_find_root_port(st= ruct pci_dev *dev) return NULL; } =20 +static inline bool pci_dev_is_disconnected(const struct pci_dev *dev) +{ + return dev->error_state =3D=3D pci_channel_io_perm_failure; +} + void pci_request_acs(void); bool pci_acs_enabled(struct pci_dev *pdev, u16 acs_flags); bool pci_acs_path_enabled(struct pci_dev *start, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D7F85B200; Sun, 24 Mar 2024 22:39:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319987; cv=none; b=FIyLa6KyWEM8RZXeddcfTIVv8Z6mqs64lsc6GtwMXjkE6Jfe40j4dj+xsfCegkdMXGtmurdh2Mrjp7rv9M902vkMq3ppvKJYkpBBgSc1rKaCONWr6B2vlSmy87qOImlLD+sBNNaM/82IPS09O+R330Of9SjJTvK3ZjBqwPUB3hM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319987; c=relaxed/simple; bh=QSg0BwiBsWtoiEiqW/O2B4tepHX3VVzHsoQPPHTYgJQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MlR8dOnOAWYbahtSrXyWF8YOeNcw+wSdcmtM7oYeFm3k7VNRhXX9u34DTNYcZeQW6zpqJRyWb5Z6d2fD+udhLYEBQNWWvwJee0cMyHcguAh50YsBZQYGnQEvH4kLil699NJUOhZZMTh6fx6iaTyW8S6nshgx+Zas7HEf7vqCSFc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=g854a91+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="g854a91+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 31FDCC43390; Sun, 24 Mar 2024 22:39:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319987; bh=QSg0BwiBsWtoiEiqW/O2B4tepHX3VVzHsoQPPHTYgJQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=g854a91+HRICdAuMBsHMtwtRbhhx7OEqVRwhMKXTPKy2RPPYfCK1eOLFjJ1eKs4sa /fPPj4KabLVKnu0QxwJVQFXs+TbuxgAO2NnzHuu6GrUrdTaIwZUqyjTkupetWKi/bi N4qc5CMrMx2cymilJ1fVGN1UhblY6uh2bgQsf8kxuXBoUBWTFDc51fvuUYfXiJSOcc 6Wr6G4ub8QwkoNVKjUuVF8qsppKh/jSALi5DhpsMW4AAJx0un1MlLW2ZyhoTwzaBXm YAoV+LsiEf5kjgfLFdIi7HTvkL5VGFR4LWO37zcRwBGq/rBe1f7k9jrxN1GgfvbTSZ EshSiJSdY7QwQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ethan Zhao , Dan Carpenter , Haorong Ye , Lu Baolu , Joerg Roedel , Sasha Levin Subject: [PATCH 6.8 293/715] iommu/vt-d: Don't issue ATS Invalidation request when device is disconnected Date: Sun, 24 Mar 2024 18:27:52 -0400 Message-ID: <20240324223455.1342824-294-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ethan Zhao [ Upstream commit 4fc82cd907ac075648789cc3a00877778aa1838b ] For those endpoint devices connect to system via hotplug capable ports, users could request a hot reset to the device by flapping device's link through setting the slot's link control register, as pciehp_ist() DLLSC interrupt sequence response, pciehp will unload the device driver and then power it off. thus cause an IOMMU device-TLB invalidation (Intel VT-d spec, or ATS Invalidation in PCIe spec r6.1) request for non-existence target device to be sent and deadly loop to retry that request after ITE fault triggered in interrupt context. That would cause following continuous hard lockup warning and system hang [ 4211.433662] pcieport 0000:17:01.0: pciehp: Slot(108): Link Down [ 4211.433664] pcieport 0000:17:01.0: pciehp: Slot(108): Card not present [ 4223.822591] NMI watchdog: Watchdog detected hard LOCKUP on cpu 144 [ 4223.822622] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted= : G S OE kernel version xxxx [ 4223.822623] Hardware name: vendorname xxxx 666-106, BIOS 01.01.02.03.01 05/15/2023 [ 4223.822623] RIP: 0010:qi_submit_sync+0x2c0/0x490 [ 4223.822624] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 = 48 8b 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 = c6 1 0 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 [ 4223.822624] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 [ 4223.822625] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 00000000000= 00005 [ 4223.822625] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401= a8340 [ 4223.822625] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 00000000000= 00000 [ 4223.822626] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f38400= 5e200 [ 4223.822626] R13: 0000000000000004 R14: 0000000000000046 R15: 00000000000= 00004 [ 4223.822626] FS: 0000000000000000(0000) GS:ffffa237ae400000(0000) knlGS:0000000000000000 [ 4223.822627] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4223.822627] CR2: 00007ffe86515d80 CR3: 000002fd3000a001 CR4: 00000000007= 70ee0 [ 4223.822627] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000= 00000 [ 4223.822628] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 00000000000= 00400 [ 4223.822628] PKRU: 55555554 [ 4223.822628] Call Trace: [ 4223.822628] qi_flush_dev_iotlb+0xb1/0xd0 [ 4223.822628] __dmar_remove_one_dev_info+0x224/0x250 [ 4223.822629] dmar_remove_one_dev_info+0x3e/0x50 [ 4223.822629] intel_iommu_release_device+0x1f/0x30 [ 4223.822629] iommu_release_device+0x33/0x60 [ 4223.822629] iommu_bus_notifier+0x7f/0x90 [ 4223.822630] blocking_notifier_call_chain+0x60/0x90 [ 4223.822630] device_del+0x2e5/0x420 [ 4223.822630] pci_remove_bus_device+0x70/0x110 [ 4223.822630] pciehp_unconfigure_device+0x7c/0x130 [ 4223.822631] pciehp_disable_slot+0x6b/0x100 [ 4223.822631] pciehp_handle_presence_or_link_change+0xd8/0x320 [ 4223.822631] pciehp_ist+0x176/0x180 [ 4223.822631] ? irq_finalize_oneshot.part.50+0x110/0x110 [ 4223.822632] irq_thread_fn+0x19/0x50 [ 4223.822632] irq_thread+0x104/0x190 [ 4223.822632] ? irq_forced_thread_fn+0x90/0x90 [ 4223.822632] ? irq_thread_check_affinity+0xe0/0xe0 [ 4223.822633] kthread+0x114/0x130 [ 4223.822633] ? __kthread_cancel_work+0x40/0x40 [ 4223.822633] ret_from_fork+0x1f/0x30 [ 4223.822633] Kernel panic - not syncing: Hard LOCKUP [ 4223.822634] CPU: 144 PID: 1422 Comm: irq/57-pciehp Kdump: loaded Tainted= : G S OE kernel version xxxx [ 4223.822634] Hardware name: vendorname xxxx 666-106, BIOS 01.01.02.03.01 05/15/2023 [ 4223.822634] Call Trace: [ 4223.822634] [ 4223.822635] dump_stack+0x6d/0x88 [ 4223.822635] panic+0x101/0x2d0 [ 4223.822635] ? ret_from_fork+0x11/0x30 [ 4223.822635] nmi_panic.cold.14+0xc/0xc [ 4223.822636] watchdog_overflow_callback.cold.8+0x6d/0x81 [ 4223.822636] __perf_event_overflow+0x4f/0xf0 [ 4223.822636] handle_pmi_common+0x1ef/0x290 [ 4223.822636] ? __set_pte_vaddr+0x28/0x40 [ 4223.822637] ? flush_tlb_one_kernel+0xa/0x20 [ 4223.822637] ? __native_set_fixmap+0x24/0x30 [ 4223.822637] ? ghes_copy_tofrom_phys+0x70/0x100 [ 4223.822637] ? __ghes_peek_estatus.isra.16+0x49/0xa0 [ 4223.822637] intel_pmu_handle_irq+0xba/0x2b0 [ 4223.822638] perf_event_nmi_handler+0x24/0x40 [ 4223.822638] nmi_handle+0x4d/0xf0 [ 4223.822638] default_do_nmi+0x49/0x100 [ 4223.822638] exc_nmi+0x134/0x180 [ 4223.822639] end_repeat_nmi+0x16/0x67 [ 4223.822639] RIP: 0010:qi_submit_sync+0x2c0/0x490 [ 4223.822639] Code: 48 be 00 00 00 00 00 08 00 00 49 85 74 24 20 0f 95 c1 = 48 8b 57 10 83 c1 04 83 3c 1a 03 0f 84 a2 01 00 00 49 8b 04 24 8b 70 34 <40> f6 = c6 10 74 17 49 8b 04 24 8b 80 80 00 00 00 89 c2 d3 fa 41 39 [ 4223.822640] RSP: 0018:ffffc4f074f0bbb8 EFLAGS: 00000093 [ 4223.822640] RAX: ffffc4f040059000 RBX: 0000000000000014 RCX: 00000000000= 00005 [ 4223.822640] RDX: ffff9f3841315800 RSI: 0000000000000000 RDI: ffff9f38401= a8340 [ 4223.822641] RBP: ffff9f38401a8340 R08: ffffc4f074f0bc00 R09: 00000000000= 00000 [ 4223.822641] R10: 0000000000000010 R11: 0000000000000018 R12: ffff9f38400= 5e200 [ 4223.822641] R13: 0000000000000004 R14: 0000000000000046 R15: 00000000000= 00004 [ 4223.822641] ? qi_submit_sync+0x2c0/0x490 [ 4223.822642] ? qi_submit_sync+0x2c0/0x490 [ 4223.822642] [ 4223.822642] qi_flush_dev_iotlb+0xb1/0xd0 [ 4223.822642] __dmar_remove_one_dev_info+0x224/0x250 [ 4223.822643] dmar_remove_one_dev_info+0x3e/0x50 [ 4223.822643] intel_iommu_release_device+0x1f/0x30 [ 4223.822643] iommu_release_device+0x33/0x60 [ 4223.822643] iommu_bus_notifier+0x7f/0x90 [ 4223.822644] blocking_notifier_call_chain+0x60/0x90 [ 4223.822644] device_del+0x2e5/0x420 [ 4223.822644] pci_remove_bus_device+0x70/0x110 [ 4223.822644] pciehp_unconfigure_device+0x7c/0x130 [ 4223.822644] pciehp_disable_slot+0x6b/0x100 [ 4223.822645] pciehp_handle_presence_or_link_change+0xd8/0x320 [ 4223.822645] pciehp_ist+0x176/0x180 [ 4223.822645] ? irq_finalize_oneshot.part.50+0x110/0x110 [ 4223.822645] irq_thread_fn+0x19/0x50 [ 4223.822646] irq_thread+0x104/0x190 [ 4223.822646] ? irq_forced_thread_fn+0x90/0x90 [ 4223.822646] ? irq_thread_check_affinity+0xe0/0xe0 [ 4223.822646] kthread+0x114/0x130 [ 4223.822647] ? __kthread_cancel_work+0x40/0x40 [ 4223.822647] ret_from_fork+0x1f/0x30 [ 4223.822647] Kernel Offset: 0x6400000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) Such issue could be triggered by all kinds of regular surprise removal hotplug operation. like: 1. pull EP(endpoint device) out directly. 2. turn off EP's power. 3. bring the link down. etc. this patch aims to work for regular safe removal and surprise removal unplug. these hot unplug handling process could be optimized for fix the ATS Invalidation hang issue by calling pci_dev_is_disconnected() in function devtlb_invalidation_with_pasid() to check target device state to avoid sending meaningless ATS Invalidation request to iommu when device is gone. (see IMPLEMENTATION NOTE in PCIe spec r6.1 section 10.3.1) For safe removal, device wouldn't be removed until the whole software handling process is done, it wouldn't trigger the hard lock up issue caused by too long ATS Invalidation timeout wait. In safe removal path, device state isn't set to pci_channel_io_perm_failure in pciehp_unconfigure_device() by checking 'presence' parameter, calling pci_dev_is_disconnected() in devtlb_invalidation_with_pasid() will return false there, wouldn't break the function. For surprise removal, device state is set to pci_channel_io_perm_failure in pciehp_unconfigure_device(), means device is already gone (disconnected) call pci_dev_is_disconnected() in devtlb_invalidation_with_pasid() will return true to break the function not to send ATS Invalidation request to the disconnected device blindly, thus avoid to trigger further ITE fault, and ITE fault will block all invalidation request to be handled. furthermore retry the timeout request could trigger hard lockup. safe removal (present) & surprise removal (not present) pciehp_ist() pciehp_handle_presence_or_link_change() pciehp_disable_slot() remove_board() pciehp_unconfigure_device(presence) { if (!presence) pci_walk_bus(parent, pci_dev_set_disconnected, NULL); } this patch works for regular safe removal and surprise removal of ATS capable endpoint on PCIe switch downstream ports. Fixes: 6f7db75e1c46 ("iommu/vt-d: Add second level page table interface") Reviewed-by: Dan Carpenter Tested-by: Haorong Ye Signed-off-by: Ethan Zhao Link: https://lore.kernel.org/r/20240301080727.3529832-3-haifeng.zhao@linux= .intel.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/iommu/intel/pasid.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c index 108158e2b907d..746c7abe2237d 100644 --- a/drivers/iommu/intel/pasid.c +++ b/drivers/iommu/intel/pasid.c @@ -214,6 +214,9 @@ devtlb_invalidation_with_pasid(struct intel_iommu *iomm= u, if (!info || !info->ats_enabled) return; =20 + if (pci_dev_is_disconnected(to_pci_dev(dev))) + return; + sid =3D info->bus << 8 | info->devfn; qdep =3D info->ats_qdep; pfsid =3D info->pfsid; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 52FFC1782EE; Sun, 24 Mar 2024 22:39:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319988; cv=none; b=PmUSsJFUX6paGYLpkAB00dPDIrzgmBrT7reCozorGd/ApaZi/UGupNUsTfBywuvU2CHHdmZnIhAC5NqKEYB3Wxg6B0IsHvqqrpIzLwBrDJueJpKR+tsK2ZAm0t2ygNJf7hZSM83qoBZV/ZKOEpCK17HdZG/Kjsq5TQ25ZsV3DSw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319988; c=relaxed/simple; bh=vnNixpthKYaUbRxBV7EcjomeXWvZ98h49aXkBAsosKo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=b1ZOvIbTBnirlSYooXRC6t1fLy8wXoSUN15r3pnhii165grijph3cIrF3acGOECNkMeoFIu9+LGYP+gqlMUqtt1eCIq6Ua+LLrqgMjBjiagg5h4KXmHi8vmApoUdi8qSF/f34++dujJa0wlf5pwJOlrdoWY/cCePH254VEnXoWg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=P6fZe28W; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="P6fZe28W" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5AF2DC433A6; Sun, 24 Mar 2024 22:39:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319988; bh=vnNixpthKYaUbRxBV7EcjomeXWvZ98h49aXkBAsosKo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P6fZe28WUplYOGI4ocSg3aVbpGGGPiQZNoLcvwlJcmVDtODr3tG33hNzgV8SaO9H5 nNyBz8fg+ZN589WtdJQ977yctW/46+zjGZ8q+YUR60l52QN/YoBxh3izZfUeatg6u1 oXv2wlr6PjHUILiSQ7vD/oKtyFm8BrAonn7ZTBYyTL76QNUkbIAwc5hxpcXIL+VUHG BkR+d0lAvVbEWeQnTFU3dmpZYvqJjSFpHhIE5XnOLBY4WrZZ26TwK+whnXqskFnu1y rTDqTheQ3DFcJbBVFJdgef0jysxN6CEB0staiFLF2viF/O62/J5/lrYMi6j4SRC5h4 vXTQkEdg0mipA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lu Baolu , Huang Jiaqing , Jason Gunthorpe , Joerg Roedel , Sasha Levin Subject: [PATCH 6.8 294/715] iommu/vt-d: Use rbtree to track iommu probed devices Date: Sun, 24 Mar 2024 18:27:53 -0400 Message-ID: <20240324223455.1342824-295-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lu Baolu [ Upstream commit 1a75cc710b956010137b4fe1d1fa3282bfd8f86c ] Use a red-black tree(rbtree) to track devices probed by the driver's probe_device callback. These devices need to be looked up quickly by a source ID when the hardware reports a fault, either recoverable or unrecoverable. Fault reporting paths are critical. Searching a list in this scenario is inefficient, with an algorithm complexity of O(n). An rbtree is a self-balancing binary search tree, offering an average search time complexity of O(log(n)). This significant performance improvement makes rbtrees a better choice. Furthermore, rbtrees are implemented on a per-iommu basis, eliminating the need for global searches and further enhancing efficiency in critical fault paths. The rbtree is protected by a spin lock with interrupts disabled to ensure thread-safe access even within interrupt contexts. Co-developed-by: Huang Jiaqing Signed-off-by: Huang Jiaqing Signed-off-by: Lu Baolu Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20240220065939.121116-2-baolu.lu@linux.inte= l.com Signed-off-by: Joerg Roedel Stable-dep-of: 80a9b50c0b9e ("iommu/vt-d: Improve ITE fault handling if tar= get device isn't present") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/iommu/intel/dmar.c | 3 +- drivers/iommu/intel/iommu.c | 88 ++++++++++++++++++++++++++++++++++++- drivers/iommu/intel/iommu.h | 8 ++++ 3 files changed, 96 insertions(+), 3 deletions(-) diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index 23cb80d62a9ab..f9b63c2875f71 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -1095,7 +1095,8 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd) iommu->agaw =3D agaw; iommu->msagaw =3D msagaw; iommu->segment =3D drhd->segment; - + iommu->device_rbtree =3D RB_ROOT; + spin_lock_init(&iommu->device_rbtree_lock); iommu->node =3D NUMA_NO_NODE; =20 ver =3D readl(iommu->reg + DMAR_VER_REG); diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 11652e0bcab3a..9e07e4425ff65 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -97,6 +97,81 @@ static phys_addr_t root_entry_uctp(struct root_entry *re) return re->hi & VTD_PAGE_MASK; } =20 +static int device_rid_cmp_key(const void *key, const struct rb_node *node) +{ + struct device_domain_info *info =3D + rb_entry(node, struct device_domain_info, node); + const u16 *rid_lhs =3D key; + + if (*rid_lhs < PCI_DEVID(info->bus, info->devfn)) + return -1; + + if (*rid_lhs > PCI_DEVID(info->bus, info->devfn)) + return 1; + + return 0; +} + +static int device_rid_cmp(struct rb_node *lhs, const struct rb_node *rhs) +{ + struct device_domain_info *info =3D + rb_entry(lhs, struct device_domain_info, node); + u16 key =3D PCI_DEVID(info->bus, info->devfn); + + return device_rid_cmp_key(&key, rhs); +} + +/* + * Looks up an IOMMU-probed device using its source ID. + * + * Returns the pointer to the device if there is a match. Otherwise, + * returns NULL. + * + * Note that this helper doesn't guarantee that the device won't be + * released by the iommu subsystem after being returned. The caller + * should use its own synchronization mechanism to avoid the device + * being released during its use if its possibly the case. + */ +struct device *device_rbtree_find(struct intel_iommu *iommu, u16 rid) +{ + struct device_domain_info *info =3D NULL; + struct rb_node *node; + unsigned long flags; + + spin_lock_irqsave(&iommu->device_rbtree_lock, flags); + node =3D rb_find(&rid, &iommu->device_rbtree, device_rid_cmp_key); + if (node) + info =3D rb_entry(node, struct device_domain_info, node); + spin_unlock_irqrestore(&iommu->device_rbtree_lock, flags); + + return info ? info->dev : NULL; +} + +static int device_rbtree_insert(struct intel_iommu *iommu, + struct device_domain_info *info) +{ + struct rb_node *curr; + unsigned long flags; + + spin_lock_irqsave(&iommu->device_rbtree_lock, flags); + curr =3D rb_find_add(&info->node, &iommu->device_rbtree, device_rid_cmp); + spin_unlock_irqrestore(&iommu->device_rbtree_lock, flags); + if (WARN_ON(curr)) + return -EEXIST; + + return 0; +} + +static void device_rbtree_remove(struct device_domain_info *info) +{ + struct intel_iommu *iommu =3D info->iommu; + unsigned long flags; + + spin_lock_irqsave(&iommu->device_rbtree_lock, flags); + rb_erase(&info->node, &iommu->device_rbtree); + spin_unlock_irqrestore(&iommu->device_rbtree_lock, flags); +} + /* * This domain is a statically identity mapping domain. * 1. This domain creats a static 1:1 mapping to all usable memory. @@ -4330,25 +4405,34 @@ static struct iommu_device *intel_iommu_probe_devic= e(struct device *dev) } =20 dev_iommu_priv_set(dev, info); + ret =3D device_rbtree_insert(iommu, info); + if (ret) + goto free; =20 if (sm_supported(iommu) && !dev_is_real_dma_subdevice(dev)) { ret =3D intel_pasid_alloc_table(dev); if (ret) { dev_err(dev, "PASID table allocation failed\n"); - kfree(info); - return ERR_PTR(ret); + goto clear_rbtree; } } =20 intel_iommu_debugfs_create_dev(info); =20 return &iommu->iommu; +clear_rbtree: + device_rbtree_remove(info); +free: + kfree(info); + + return ERR_PTR(ret); } =20 static void intel_iommu_release_device(struct device *dev) { struct device_domain_info *info =3D dev_iommu_priv_get(dev); =20 + device_rbtree_remove(info); dmar_remove_one_dev_info(dev); intel_pasid_free_table(dev); intel_iommu_debugfs_remove_dev(info); diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 4145c04cb1c68..df00240ebe90b 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -722,6 +722,11 @@ struct intel_iommu { struct q_inval *qi; /* Queued invalidation info */ u32 iommu_state[MAX_SR_DMAR_REGS]; /* Store iommu states between suspend = and resume.*/ =20 + /* rb tree for all probed devices */ + struct rb_root device_rbtree; + /* protect the device_rbtree */ + spinlock_t device_rbtree_lock; + #ifdef CONFIG_IRQ_REMAP struct ir_table *ir_table; /* Interrupt remapping info */ struct irq_domain *ir_domain; @@ -755,6 +760,8 @@ struct device_domain_info { struct intel_iommu *iommu; /* IOMMU used by this device */ struct dmar_domain *domain; /* pointer to domain */ struct pasid_table *pasid_table; /* pasid table */ + /* device tracking node(lookup by PCI RID) */ + struct rb_node node; #ifdef CONFIG_INTEL_IOMMU_DEBUGFS struct dentry *debugfs_dentry; /* pointer to device directory dentry */ #endif @@ -1081,6 +1088,7 @@ void free_pgtable_page(void *vaddr); void iommu_flush_write_buffer(struct intel_iommu *iommu); struct iommu_domain *intel_nested_domain_alloc(struct iommu_domain *parent, const struct iommu_user_data *user_data); +struct device *device_rbtree_find(struct intel_iommu *iommu, u16 rid); =20 #ifdef CONFIG_INTEL_IOMMU_SVM void intel_svm_check(struct intel_iommu *iommu); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD66B17830D; Sun, 24 Mar 2024 22:39:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319989; cv=none; b=hCKvLBKAR8MQCXBtHoMZ6/5yzXEK/RvSiYQwwHUd6cY/uTs1T34S/iVYAC6aVuSOra1HlHLCfl87gi6JiqPOPIcfaf7FJdq84f5Yid6ti/LgPCD8xXq96q4cPMXmKiw9J056yI8xpUZHkVb3gTWdcO+8DOLpzWhk3jjQtTk5aAY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319989; c=relaxed/simple; bh=+5Vq+qVxbbUVom2yStWiKQ6O7ZceOnXGwq1aKdAD+0I=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TYLpCZpVBU/yR+8QcFt98n4jl8huVgohJd8Ck8yfAor6U1fNj2D1sKH+3ze+Jb9mNuDkOSo2luCCatuR8QE/0f+gjzCiwdUnsOq/PNjRVPGmn3HMrnn4gAHh8iANd621w6EXiKghfsFxbtvdFnezZLIp3i4ouDATVh1aabA4VAw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o/r3pZ23; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="o/r3pZ23" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7095FC433F1; Sun, 24 Mar 2024 22:39:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319989; bh=+5Vq+qVxbbUVom2yStWiKQ6O7ZceOnXGwq1aKdAD+0I=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=o/r3pZ23edKjgv9D8lqVXQ7KDCwM/gsaTlv89H4cJ4NrqOaxrzu/A362KpAJLQDCl dXZL4HoUT72fvDZFPylQdVSfNwjfJgANgw5+l8qUNjrtg1zEQEGjj5aHhntFjOQ2rB XQNwrrm/dc5xUZCxDuz34K/ib/mjSIyc631qOojFZj17NYljjEmh/hrptPXjD1kZ6L NmJ9nn4A3YUTMwYe2+XPSGBFLgmTjOAs0qzJ6sVrp9+uAppKI97NCgf2lnTPXtO3KO BnzK1o/FpRMYW+05GO9jgu98RvCsSi+SNeIv2bmIUWQ259c7/wRBOvL0qDvIrdOmql 4PbUwMTu+8OxA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ethan Zhao , Dan Carpenter , Lu Baolu , Joerg Roedel , Sasha Levin Subject: [PATCH 6.8 295/715] iommu/vt-d: Improve ITE fault handling if target device isn't present Date: Sun, 24 Mar 2024 18:27:54 -0400 Message-ID: <20240324223455.1342824-296-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ethan Zhao [ Upstream commit 80a9b50c0b9e297669a8a400eb35468cd87a9aed ] Because surprise removal could happen anytime, e.g. user could request safe removal to EP(endpoint device) via sysfs and brings its link down to do surprise removal cocurrently. such aggressive cases would cause ATS invalidation request issued to non-existence target device, then deadly loop to retry that request after ITE fault triggered in interrupt context. this patch aims to optimize the ITE handling by checking the target device presence state to avoid retrying the timeout request blindly, thus avoid hard lockup or system hang. Devices TLB should only be invalidated when devices are in the iommu->device_rbtree (probed, not released) and present. Fixes: 6ba6c3a4cacf ("VT-d: add device IOTLB invalidation support") Reviewed-by: Dan Carpenter Signed-off-by: Ethan Zhao Link: https://lore.kernel.org/r/20240301080727.3529832-4-haifeng.zhao@linux= .intel.com Signed-off-by: Lu Baolu Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/iommu/intel/dmar.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index f9b63c2875f71..ad8a340fc7f1d 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -1272,6 +1272,8 @@ static int qi_check_fault(struct intel_iommu *iommu, = int index, int wait_index) { u32 fault; int head, tail; + struct device *dev; + u64 iqe_err, ite_sid; struct q_inval *qi =3D iommu->qi; int shift =3D qi_shift(iommu); =20 @@ -1316,6 +1318,13 @@ static int qi_check_fault(struct intel_iommu *iommu,= int index, int wait_index) tail =3D readl(iommu->reg + DMAR_IQT_REG); tail =3D ((tail >> shift) - 1 + QI_LENGTH) % QI_LENGTH; =20 + /* + * SID field is valid only when the ITE field is Set in FSTS_REG + * see Intel VT-d spec r4.1, section 11.4.9.9 + */ + iqe_err =3D dmar_readq(iommu->reg + DMAR_IQER_REG); + ite_sid =3D DMAR_IQER_REG_ITESID(iqe_err); + writel(DMA_FSTS_ITE, iommu->reg + DMAR_FSTS_REG); pr_info("Invalidation Time-out Error (ITE) cleared\n"); =20 @@ -1325,6 +1334,19 @@ static int qi_check_fault(struct intel_iommu *iommu,= int index, int wait_index) head =3D (head - 2 + QI_LENGTH) % QI_LENGTH; } while (head !=3D tail); =20 + /* + * If device was released or isn't present, no need to retry + * the ATS invalidate request anymore. + * + * 0 value of ite_sid means old VT-d device, no ite_sid value. + * see Intel VT-d spec r4.1, section 11.4.9.9 + */ + if (ite_sid) { + dev =3D device_rbtree_find(iommu, ite_sid); + if (!dev || !dev_is_pci(dev) || + !pci_device_is_present(to_pci_dev(dev))) + return -ETIMEDOUT; + } if (qi->desc_status[wait_index] =3D=3D QI_ABORT) return -EAGAIN; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5DAEB17831C; Sun, 24 Mar 2024 22:39:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319990; cv=none; b=MswAodL0Jz2da9LtwdPT1pbJ/WsGauA2nh9Twc3LlQ5rFV85Hi8KLc3Bx/iICj71kqnh48aztRUSDTSlakdYMRDIN4IIhtpXaHTbhGhoxEVkeftryE+tN6xMmfVKj3IWtE1zlKefSirODXK00QmkEkKzKrIRyiVtpgh4jaoHnJM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319990; c=relaxed/simple; bh=IxEqqKIe9EzhCZoMkEFAE23hSEe6gRgkdmo8KMpCwJA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=q6yFpglA07oineuw6XJmGx2wSD8mUPiG+qIjaIXKTCken0U3T38+2Si0849O3d+Pt0y2igGwJ/oI1mUwUA95yTh0zSr2Kyk3ehymsz0dH9RfXfGjWeMgi81EQNdColcqQuW7gCNIH7VhmfrJe+C9zRmhAqPgoCWNFnIcbmPC1+c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=mW0P7HOH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="mW0P7HOH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 84B4CC43399; Sun, 24 Mar 2024 22:39:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319990; bh=IxEqqKIe9EzhCZoMkEFAE23hSEe6gRgkdmo8KMpCwJA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=mW0P7HOHLMZyMFgUur5AVeIGy5k6spVZL3X1JJXhUpMxELngygBf/QtOMuN6OJs0M s3ilSfuxsXMoQxlNFe6jsFX67a+oq/Fw25Y3N0/s25ufSBcPPd8/h2fmUaBWjoVXZG sn65jI8YkoVroPRPwpBsji3+64ypvjkqO3YGMZw0SP9Pbz5dxYCjhXEAiByj9AwDZE J5V3zx5Q6Cw99UBCERy+bguP8T6g+kB43GHCksgNhLYkrjykKKXzK0cCc9qMqnkM27 HaBFXO56ULGf2H9T6IZc6DaQoXhHngWePY3wIQLddftBsI21DdmSvK7ylNgIPF4SHI tt9ASBnGrO3hw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lu Baolu , Jason Gunthorpe , Joerg Roedel , Sasha Levin Subject: [PATCH 6.8 296/715] iommu/vt-d: Use device rbtree in iopf reporting path Date: Sun, 24 Mar 2024 18:27:55 -0400 Message-ID: <20240324223455.1342824-297-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lu Baolu [ Upstream commit def054b01a867822254e1dda13d587f5c7a99e2a ] The existing I/O page fault handler currently locates the PCI device by calling pci_get_domain_bus_and_slot(). This function searches the list of all PCI devices until the desired device is found. To improve lookup efficiency, replace it with device_rbtree_find() to search the device within the probed device rbtree. The I/O page fault is initiated by the device, which does not have any synchronization mechanism with the software to ensure that the device stays in the probed device tree. Theoretically, a device could be released by the IOMMU subsystem after device_rbtree_find() and before iopf_get_dev_fault_param(), which would cause a use-after-free problem. Add a mutex to synchronize the I/O page fault reporting path and the IOMMU release device path. This lock doesn't introduce any performance overhead, as the conflict between I/O page fault reporting and device releasing is very rare. Signed-off-by: Lu Baolu Reviewed-by: Jason Gunthorpe Link: https://lore.kernel.org/r/20240220065939.121116-3-baolu.lu@linux.inte= l.com Signed-off-by: Joerg Roedel Stable-dep-of: 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release= ") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/iommu/intel/dmar.c | 1 + drivers/iommu/intel/iommu.c | 3 +++ drivers/iommu/intel/iommu.h | 2 ++ drivers/iommu/intel/svm.c | 17 +++++++++-------- 4 files changed, 15 insertions(+), 8 deletions(-) diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c index ad8a340fc7f1d..36d7427b12026 100644 --- a/drivers/iommu/intel/dmar.c +++ b/drivers/iommu/intel/dmar.c @@ -1097,6 +1097,7 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd) iommu->segment =3D drhd->segment; iommu->device_rbtree =3D RB_ROOT; spin_lock_init(&iommu->device_rbtree_lock); + mutex_init(&iommu->iopf_lock); iommu->node =3D NUMA_NO_NODE; =20 ver =3D readl(iommu->reg + DMAR_VER_REG); diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 9e07e4425ff65..31b5d852ba732 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -4431,8 +4431,11 @@ static struct iommu_device *intel_iommu_probe_device= (struct device *dev) static void intel_iommu_release_device(struct device *dev) { struct device_domain_info *info =3D dev_iommu_priv_get(dev); + struct intel_iommu *iommu =3D info->iommu; =20 + mutex_lock(&iommu->iopf_lock); device_rbtree_remove(info); + mutex_unlock(&iommu->iopf_lock); dmar_remove_one_dev_info(dev); intel_pasid_free_table(dev); intel_iommu_debugfs_remove_dev(info); diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index df00240ebe90b..cd267ba64eda1 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -719,6 +719,8 @@ struct intel_iommu { #endif struct iopf_queue *iopf_queue; unsigned char iopfq_name[16]; + /* Synchronization between fault report and iommu device release. */ + struct mutex iopf_lock; struct q_inval *qi; /* Queued invalidation info */ u32 iommu_state[MAX_SR_DMAR_REGS]; /* Store iommu states between suspend = and resume.*/ =20 diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c index 40edd282903fb..ec47ec81f0ecd 100644 --- a/drivers/iommu/intel/svm.c +++ b/drivers/iommu/intel/svm.c @@ -650,7 +650,7 @@ static irqreturn_t prq_event_thread(int irq, void *d) struct intel_iommu *iommu =3D d; struct page_req_dsc *req; int head, tail, handled; - struct pci_dev *pdev; + struct device *dev; u64 address; =20 /* @@ -696,23 +696,24 @@ static irqreturn_t prq_event_thread(int irq, void *d) if (unlikely(req->lpig && !req->rd_req && !req->wr_req)) goto prq_advance; =20 - pdev =3D pci_get_domain_bus_and_slot(iommu->segment, - PCI_BUS_NUM(req->rid), - req->rid & 0xff); /* * If prq is to be handled outside iommu driver via receiver of * the fault notifiers, we skip the page response here. */ - if (!pdev) + mutex_lock(&iommu->iopf_lock); + dev =3D device_rbtree_find(iommu, req->rid); + if (!dev) { + mutex_unlock(&iommu->iopf_lock); goto bad_req; + } =20 - if (intel_svm_prq_report(iommu, &pdev->dev, req)) + if (intel_svm_prq_report(iommu, dev, req)) handle_bad_prq_event(iommu, req, QI_RESP_INVALID); else - trace_prq_report(iommu, &pdev->dev, req->qw_0, req->qw_1, + trace_prq_report(iommu, dev, req->qw_0, req->qw_1, req->priv_data[0], req->priv_data[1], iommu->prq_seq_number++); - pci_dev_put(pdev); + mutex_unlock(&iommu->iopf_lock); prq_advance: head =3D (head + sizeof(*req)) & PRQ_RING_MASK; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7E8AA178CCF; Sun, 24 Mar 2024 22:39:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319991; cv=none; b=d4E3gEKCAko/PiXTHqY+UluoQAykzqYvWC6oT5HnMLzrMUilCkiyx3TLwMLoP7kADKbmT6dP8YHXUcFVvl1rp8+FRQ5JqVE+IuwP5zfPwFqmYYTBxjBGK3Chuf2rF+OUyQjgnTWsZq/qI2s7JXsa1EXdRBU/G2hqQKabtmSX4Fc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319991; c=relaxed/simple; bh=3IZlNOzBqHQHY4gQvWgHcGXr5SgHDQHzF++1kUXuWEg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pRaOSAITMB+6asD63D1qe8Qf0MIXjGJkRh80UhsYgcKBCljm6qLaAUCzp08hxWAPRNQDFFRjugb9UOuPm7n9YYQmi7EQq5NpNFFKFkG0COsgXUwSCTXnuddtTeYcl2NQbB8/VvXPvzps4plq9xBj/uXQARpJMwNvq2Tyb6QgE4Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GxsHbRC0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GxsHbRC0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8419EC433F1; Sun, 24 Mar 2024 22:39:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319991; bh=3IZlNOzBqHQHY4gQvWgHcGXr5SgHDQHzF++1kUXuWEg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GxsHbRC0ORk50Gr5c1nJyJvSwmVTZNOXwdmuRSL5uuhmY4JL4Sy7DnTupEAaFu+P0 823zcy0pI54mtBp2YZyabgPhW2bbykILbDkbdDVF8n7PZ/K0hJ1mTITpSZQvF9192H WN4lKwGvmXwOB/nMRGuhvFLMFMh/96k9/TxPyeQ/pEfuIZycVU0THCq79R01k90V9Q /Pg7NKhoR1tsdKYBMqzdQQeoU/kigDdDF7488Fjo0lsPsTdsxXG7a5ywc/Ry8OtWwc 1C9Kghq3cBF9V1GzwVZeOc7oBpTVZ3Q2d5jFS0AwbVqFuSfcDfuJytN2JOIAUZZqGT tytkB9wB0nHKw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lu Baolu , Jason Gunthorpe , Kevin Tian , Joerg Roedel , Sasha Levin Subject: [PATCH 6.8 297/715] iommu: Add static iommu_ops->release_domain Date: Sun, 24 Mar 2024 18:27:56 -0400 Message-ID: <20240324223455.1342824-298-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lu Baolu [ Upstream commit 0061ffe289e19caabeea8103e69cb0f1896e34d8 ] The current device_release callback for individual iommu drivers does the following: 1) Silent IOMMU DMA translation: It detaches any existing domain from the device and puts it into a blocking state (some drivers might use the identity state). 2) Resource release: It releases resources allocated during the device_probe callback and restores the device to its pre-probe state. Step 1 is challenging for individual iommu drivers because each must check if a domain is already attached to the device. Additionally, if a deferred attach never occurred, the device_release should avoid modifying hardware configuration regardless of the reason for its call. To simplify this process, introduce a static release_domain within the iommu_ops structure. It can be either a blocking or identity domain depending on the iommu hardware. The iommu core will decide whether to attach this domain before the device_release callback, eliminating the need for repetitive code in various drivers. Consequently, the device_release callback can focus solely on the opposite operations of device_probe, including releasing all resources allocated during that callback. Co-developed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20240305013305.204605-2-baolu.lu@linux.inte= l.com Signed-off-by: Joerg Roedel Stable-dep-of: 81e921fd3216 ("iommu/vt-d: Fix NULL domain on device release= ") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/iommu/iommu.c | 19 +++++++++++++++---- include/linux/iommu.h | 1 + 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index d14413916f93a..cd1210026ac53 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -463,13 +463,24 @@ static void iommu_deinit_device(struct device *dev) =20 /* * release_device() must stop using any attached domain on the device. - * If there are still other devices in the group they are not effected + * If there are still other devices in the group, they are not affected * by this callback. * - * The IOMMU driver must set the device to either an identity or - * blocking translation and stop using any domain pointer, as it is - * going to be freed. + * If the iommu driver provides release_domain, the core code ensures + * that domain is attached prior to calling release_device. Drivers can + * use this to enforce a translation on the idle iommu. Typically, the + * global static blocked_domain is a good choice. + * + * Otherwise, the iommu driver must set the device to either an identity + * or a blocking translation in release_device() and stop using any + * domain pointer, as it is going to be freed. + * + * Regardless, if a delayed attach never occurred, then the release + * should still avoid touching any hardware configuration either. */ + if (!dev->iommu->attach_deferred && ops->release_domain) + ops->release_domain->ops->attach_dev(ops->release_domain, dev); + if (ops->release_device) ops->release_device(dev); =20 diff --git a/include/linux/iommu.h b/include/linux/iommu.h index 5e27cb3a3be99..c948289f64d08 100644 --- a/include/linux/iommu.h +++ b/include/linux/iommu.h @@ -487,6 +487,7 @@ struct iommu_ops { struct module *owner; struct iommu_domain *identity_domain; struct iommu_domain *blocked_domain; + struct iommu_domain *release_domain; struct iommu_domain *default_domain; }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D25D45B696; Sun, 24 Mar 2024 22:39:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319992; cv=none; b=ST3DdXVNCpOJbEfMW2HG9YUrZCWPD5QsSYIRecuSlis5iamOhCbJ/COg7rXNt1jlq+C3eA0ke6kFBKAKL99P1/ZE6e+briA+yL9MHnxYlJcOJmN+UNWHmxlrvvp/mSLXrnrhSNP5VdptxopGgdCqXMpFIkhisF5xz7FyHlYkorY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319992; c=relaxed/simple; bh=I1bDq07OqvrWsJM/pOX7OqiGpg3Lu/to4BRLZ/VJ0z4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Qe1tMosAxWBaRelbyX6L4Z7L2jQdMZ84st10gt3GXqKOLrWiSKfdinN8VKHr2TNKJRUBMA+h8z7oTEJwDcgIdxexFP2/yhz7ajfC5ijtRJlwTHKMuN0yjmZ5aWOZSWhbH36XGj2Z+277ds9PCFeb35G+EZrc16IuzDDltvADonI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AV1fgDND; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AV1fgDND" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9BB3FC433C7; Sun, 24 Mar 2024 22:39:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319992; bh=I1bDq07OqvrWsJM/pOX7OqiGpg3Lu/to4BRLZ/VJ0z4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AV1fgDNDezG+E/8BnDPmqava8j2+fFifNBxaDUSYLK2Gt3AXLwtR4lBV0nLlz7BCN daLzzTDtprfx77zw90iOPO25VYlOWVIEbyvCSZ2C8DOd0E8YW0FujB12Ud9hT41cDm aMa4a31iKT6fLyUU2MZ9GKvxQ0NuGbaZKN1tzXCD8cRSt9yxRYydWarVg7btohz/OG 6Rg9hcApb0CEJ2K9k3csfu46WKyB+g/oY7g1Gg/VoRuT4Mothhub9Vo5kPzqYY+rFh pOFT8lLg+s2mYHaDMRh/7leXd5rhIJIj7gXWfkE6yZCHM9+QumkfD/QlHiX3IidGyY V6IqJZpEyujew== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lu Baolu , Eric Badger , Kevin Tian , Joerg Roedel , Sasha Levin Subject: [PATCH 6.8 298/715] iommu/vt-d: Fix NULL domain on device release Date: Sun, 24 Mar 2024 18:27:57 -0400 Message-ID: <20240324223455.1342824-299-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lu Baolu [ Upstream commit 81e921fd321614c2ad8ac333b041aae1da7a1c6d ] In the kdump kernel, the IOMMU operates in deferred_attach mode. In this mode, info->domain may not yet be assigned by the time the release_device function is called. It leads to the following crash in the crash kernel: BUG: kernel NULL pointer dereference, address: 000000000000003c ... RIP: 0010:do_raw_spin_lock+0xa/0xa0 ... _raw_spin_lock_irqsave+0x1b/0x30 intel_iommu_release_device+0x96/0x170 iommu_deinit_device+0x39/0xf0 __iommu_group_remove_device+0xa0/0xd0 iommu_bus_notifier+0x55/0xb0 notifier_call_chain+0x5a/0xd0 blocking_notifier_call_chain+0x41/0x60 bus_notify+0x34/0x50 device_del+0x269/0x3d0 pci_remove_bus_device+0x77/0x100 p2sb_bar+0xae/0x1d0 ... i801_probe+0x423/0x740 Use the release_domain mechanism to fix it. The scalable mode context entry which is not part of release domain should be cleared in release_device(). Fixes: 586081d3f6b1 ("iommu/vt-d: Remove DEFER_DEVICE_DOMAIN_INFO") Reported-by: Eric Badger Closes: https://lore.kernel.org/r/20240113181713.1817855-1-ebadger@purestor= age.com Signed-off-by: Lu Baolu Reviewed-by: Kevin Tian Link: https://lore.kernel.org/r/20240305013305.204605-3-baolu.lu@linux.inte= l.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/iommu/intel/iommu.c | 31 ++++-------------- drivers/iommu/intel/pasid.c | 64 +++++++++++++++++++++++++++++++++++++ drivers/iommu/intel/pasid.h | 1 + 3 files changed, 71 insertions(+), 25 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 31b5d852ba732..5dba58f322f03 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -3874,30 +3874,6 @@ static void domain_context_clear(struct device_domai= n_info *info) &domain_context_clear_one_cb, info); } =20 -static void dmar_remove_one_dev_info(struct device *dev) -{ - struct device_domain_info *info =3D dev_iommu_priv_get(dev); - struct dmar_domain *domain =3D info->domain; - struct intel_iommu *iommu =3D info->iommu; - unsigned long flags; - - if (!dev_is_real_dma_subdevice(info->dev)) { - if (dev_is_pci(info->dev) && sm_supported(iommu)) - intel_pasid_tear_down_entry(iommu, info->dev, - IOMMU_NO_PASID, false); - - iommu_disable_pci_caps(info); - domain_context_clear(info); - } - - spin_lock_irqsave(&domain->lock, flags); - list_del(&info->link); - spin_unlock_irqrestore(&domain->lock, flags); - - domain_detach_iommu(domain, iommu); - info->domain =3D NULL; -} - /* * Clear the page table pointer in context or pasid table entries so that * all DMA requests without PASID from the device are blocked. If the page @@ -4436,7 +4412,11 @@ static void intel_iommu_release_device(struct device= *dev) mutex_lock(&iommu->iopf_lock); device_rbtree_remove(info); mutex_unlock(&iommu->iopf_lock); - dmar_remove_one_dev_info(dev); + + if (sm_supported(iommu) && !dev_is_real_dma_subdevice(dev) && + !context_copied(iommu, info->bus, info->devfn)) + intel_pasid_teardown_sm_context(dev); + intel_pasid_free_table(dev); intel_iommu_debugfs_remove_dev(info); kfree(info); @@ -4942,6 +4922,7 @@ static const struct iommu_dirty_ops intel_dirty_ops = =3D { =20 const struct iommu_ops intel_iommu_ops =3D { .blocked_domain =3D &blocking_domain, + .release_domain =3D &blocking_domain, .capable =3D intel_iommu_capable, .hw_info =3D intel_iommu_hw_info, .domain_alloc =3D intel_iommu_domain_alloc, diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c index 746c7abe2237d..a51e895d9a178 100644 --- a/drivers/iommu/intel/pasid.c +++ b/drivers/iommu/intel/pasid.c @@ -670,3 +670,67 @@ int intel_pasid_setup_nested(struct intel_iommu *iommu= , struct device *dev, =20 return 0; } + +/* + * Interfaces to setup or teardown a pasid table to the scalable-mode + * context table entry: + */ + +static void device_pasid_table_teardown(struct device *dev, u8 bus, u8 dev= fn) +{ + struct device_domain_info *info =3D dev_iommu_priv_get(dev); + struct intel_iommu *iommu =3D info->iommu; + struct context_entry *context; + + spin_lock(&iommu->lock); + context =3D iommu_context_addr(iommu, bus, devfn, false); + if (!context) { + spin_unlock(&iommu->lock); + return; + } + + context_clear_entry(context); + __iommu_flush_cache(iommu, context, sizeof(*context)); + spin_unlock(&iommu->lock); + + /* + * Cache invalidation for changes to a scalable-mode context table + * entry. + * + * Section 6.5.3.3 of the VT-d spec: + * - Device-selective context-cache invalidation; + * - Domain-selective PASID-cache invalidation to affected domains + * (can be skipped if all PASID entries were not-present); + * - Domain-selective IOTLB invalidation to affected domains; + * - Global Device-TLB invalidation to affected functions. + * + * The iommu has been parked in the blocking state. All domains have + * been detached from the device or PASID. The PASID and IOTLB caches + * have been invalidated during the domain detach path. + */ + iommu->flush.flush_context(iommu, 0, PCI_DEVID(bus, devfn), + DMA_CCMD_MASK_NOBIT, DMA_CCMD_DEVICE_INVL); + devtlb_invalidation_with_pasid(iommu, dev, IOMMU_NO_PASID); +} + +static int pci_pasid_table_teardown(struct pci_dev *pdev, u16 alias, void = *data) +{ + struct device *dev =3D data; + + if (dev =3D=3D &pdev->dev) + device_pasid_table_teardown(dev, PCI_BUS_NUM(alias), alias & 0xff); + + return 0; +} + +void intel_pasid_teardown_sm_context(struct device *dev) +{ + struct device_domain_info *info =3D dev_iommu_priv_get(dev); + + if (!dev_is_pci(dev)) { + device_pasid_table_teardown(dev, info->bus, info->devfn); + return; + } + + pci_for_each_dma_alias(to_pci_dev(dev), pci_pasid_table_teardown, dev); +} diff --git a/drivers/iommu/intel/pasid.h b/drivers/iommu/intel/pasid.h index 487ede039bdde..42fda97fd8516 100644 --- a/drivers/iommu/intel/pasid.h +++ b/drivers/iommu/intel/pasid.h @@ -318,4 +318,5 @@ void intel_pasid_tear_down_entry(struct intel_iommu *io= mmu, bool fault_ignore); void intel_pasid_setup_page_snoop_control(struct intel_iommu *iommu, struct device *dev, u32 pasid); +void intel_pasid_teardown_sm_context(struct device *dev); #endif /* __INTEL_PASID_H */ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B5B7717964E; Sun, 24 Mar 2024 22:39:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319993; cv=none; b=fhmwaxX4FrADEUJJN8oJCqgl2LGHv8Q7VdL42txRXT7BYpCMEkbp13xuDc5jn0fwF/CAw0ngtXnOjkypKb7g1h/821mbIQa12wYlYxLgJbLwo7aNkaxKqiHbgngOJxCXV1J8OqV2V+zk5jH0EASZvaI2tiX2eVJRi/T/MMgFoEs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319993; c=relaxed/simple; bh=rMlIlxnxaYsH4cN4S0jrQRcDKJX2g/yoQOCqfN/YUjg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nS/K8b4ShdBAEBPJEb5FuKb846RdrqaD9XXN5o78u9kgs6gwvF6ZD7S8lBIlSVl0cjz3NSKfacl7g09BRd1stFD0L0QbtcdBeaJSuqSYzUtMoEZ+iWAZx4zjI/bvvT0edaGAh6g7v0LA5bXXNjl7aiSUTrx+QuM4sp1pcNtICg8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ecHk2n1J; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ecHk2n1J" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C050CC43399; Sun, 24 Mar 2024 22:39:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319993; bh=rMlIlxnxaYsH4cN4S0jrQRcDKJX2g/yoQOCqfN/YUjg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ecHk2n1J9WIJuW1D3VRa0R1wm1o0uvCqZxDSOOXqTM/kjYulNNvLSI0MwfFQ4CDNR VFZ14hwtQlYZLI0W0UO0vPCD4FjnnayiJJrGIKse39N6H/XjGmj4pIvwMojktFpjL3 P8rRiJ4rHgW3GcCm82y6s6zCc1krsS5gHT2h9CV9wj9lO7fkDNBdtbF9CYhDTUS1Y2 zykbHtLc8j9mUAwC4XCyzklslMM1TRcSjz1lIQmFOCSG07hfD4UcS9lrLc0FPP9Edd 5A5aiQA+kEIVhrVNEHGGHtFITvDuSqFMx4gMdkmc3WNeG7SJpDrdiGdHb4x3ZGyx+X vTc4AnUQT0UFg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vinicius Costa Gomes , Kurt Kanzenbach , Naama Meir , Tony Nguyen , Sasha Levin Subject: [PATCH 6.8 299/715] igc: Fix missing time sync events Date: Sun, 24 Mar 2024 18:27:58 -0400 Message-ID: <20240324223455.1342824-300-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vinicius Costa Gomes [ Upstream commit 244ae992e3e80e5c9c272c77324c831148457f95 ] Fix "double" clearing of interrupts, which can cause external events or timestamps to be missed. The IGC_TSIRC Time Sync Interrupt Cause register can be cleared in two ways, by either reading it or by writing '1' into the specific cause bit. This is documented in section 8.16.1. The following flow was used: 1. read IGC_TSIRC into 'tsicr'; 2. handle the interrupts present in 'tsirc' and mark them in 'ack'; 3. write 'ack' into IGC_TSICR; As both (1) and (3) will clear the interrupt cause, if the same interrupt happens again between (1) and (3) it will be ignored, causing events to be missed. Remove the extra clear in (3). Fixes: 2c344ae24501 ("igc: Add support for TX timestamping") Reviewed-by: Kurt Kanzenbach Tested-by: Kurt Kanzenbach # Intel i225 Signed-off-by: Vinicius Costa Gomes Tested-by: Naama Meir Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/ethernet/intel/igc/igc_main.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-) diff --git a/drivers/net/ethernet/intel/igc/igc_main.c b/drivers/net/ethern= et/intel/igc/igc_main.c index 81c21a893ede9..e447ba0370568 100644 --- a/drivers/net/ethernet/intel/igc/igc_main.c +++ b/drivers/net/ethernet/intel/igc/igc_main.c @@ -5302,25 +5302,22 @@ igc_features_check(struct sk_buff *skb, struct net_= device *dev, =20 static void igc_tsync_interrupt(struct igc_adapter *adapter) { - u32 ack, tsauxc, sec, nsec, tsicr; struct igc_hw *hw =3D &adapter->hw; + u32 tsauxc, sec, nsec, tsicr; struct ptp_clock_event event; struct timespec64 ts; =20 tsicr =3D rd32(IGC_TSICR); - ack =3D 0; =20 if (tsicr & IGC_TSICR_SYS_WRAP) { event.type =3D PTP_CLOCK_PPS; if (adapter->ptp_caps.pps) ptp_clock_event(adapter->ptp_clock, &event); - ack |=3D IGC_TSICR_SYS_WRAP; } =20 if (tsicr & IGC_TSICR_TXTS) { /* retrieve hardware timestamp */ igc_ptp_tx_tstamp_event(adapter); - ack |=3D IGC_TSICR_TXTS; } =20 if (tsicr & IGC_TSICR_TT0) { @@ -5334,7 +5331,6 @@ static void igc_tsync_interrupt(struct igc_adapter *a= dapter) wr32(IGC_TSAUXC, tsauxc); adapter->perout[0].start =3D ts; spin_unlock(&adapter->tmreg_lock); - ack |=3D IGC_TSICR_TT0; } =20 if (tsicr & IGC_TSICR_TT1) { @@ -5348,7 +5344,6 @@ static void igc_tsync_interrupt(struct igc_adapter *a= dapter) wr32(IGC_TSAUXC, tsauxc); adapter->perout[1].start =3D ts; spin_unlock(&adapter->tmreg_lock); - ack |=3D IGC_TSICR_TT1; } =20 if (tsicr & IGC_TSICR_AUTT0) { @@ -5358,7 +5353,6 @@ static void igc_tsync_interrupt(struct igc_adapter *a= dapter) event.index =3D 0; event.timestamp =3D sec * NSEC_PER_SEC + nsec; ptp_clock_event(adapter->ptp_clock, &event); - ack |=3D IGC_TSICR_AUTT0; } =20 if (tsicr & IGC_TSICR_AUTT1) { @@ -5368,11 +5362,7 @@ static void igc_tsync_interrupt(struct igc_adapter *= adapter) event.index =3D 1; event.timestamp =3D sec * NSEC_PER_SEC + nsec; ptp_clock_event(adapter->ptp_clock, &event); - ack |=3D IGC_TSICR_AUTT1; } - - /* acknowledge the interrupts */ - wr32(IGC_TSICR, ack); } =20 /** --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 18DDD179674; Sun, 24 Mar 2024 22:39:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319995; cv=none; b=Wa4TwMv6LWwdGKsJVj72cMqsHbEVhZ7h3clVhV46Voy7PLyh8J+dFVKWPYMcJAD3QukqWcJv3nLAZaK1yPXRLLbikBBf64leCNorNRRrPVsHS8LpCs0ixvLfsSuV8EUxn5zf4Lh7z9B0YvKL7ntHLH4pwy+SYiqpLnQzInwP7cM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319995; c=relaxed/simple; bh=pAKBOIgC4EEXttjYElQekc9pn6L7DPK0ZU2LJdE5KMU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GfiszJT2DKhUeENmNGIyNHWapyT6bUwj2VpsdLkel9+DOyBcjvLt5DFeSe6VOUl0N+idHYVnOgi6iI9r2AYyposJZ+52Gy/wQpG6tgboIG9mL9jPAzKAx/W9T57F73EM4IW8wKJeNLaVw3AVej+q/mF1LF35PaKcsaSFBeRJILk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=X6tbMvvp; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="X6tbMvvp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8DA9C433C7; Sun, 24 Mar 2024 22:39:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319994; bh=pAKBOIgC4EEXttjYElQekc9pn6L7DPK0ZU2LJdE5KMU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=X6tbMvvpznLYlMnhweRMgGluhZNxz3Z0YEvROsCeqGlvbjRGgt1AkJGFnZDdZDddl kctywlI9MdOyFPt9Z3ut8guIV5erT/53j2d4Z+h6OPYwcn4L3L/2PloWp0Kxs+nxfb FscoGkEDVBSSmnQOTGAYjHmH4j7Yh7/Ev1ZJ7drSdxC3CRp9ApAMTVDhDJkS3O7OXU cqPzgn+DUoBkJn+YRY8LZUD0cW/pEsTACgKgquHe5yHkFeR0CkuDnLVmJJZ50brSQd YUqb33SYrEtO2dnPOUOYVkYe+Qli3WSUj9aCw9qmthuw0GpNyEu/7WKSUq8iOWd5/Q wUpalK9a4OtQw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Vinicius Costa Gomes , Richard Cochran , Pucha Himasekhar Reddy , Tony Nguyen , Sasha Levin Subject: [PATCH 6.8 300/715] igb: Fix missing time sync events Date: Sun, 24 Mar 2024 18:27:59 -0400 Message-ID: <20240324223455.1342824-301-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Vinicius Costa Gomes [ Upstream commit ee14cc9ea19ba9678177e2224a9c58cce5937c73 ] Fix "double" clearing of interrupts, which can cause external events or timestamps to be missed. The E1000_TSIRC Time Sync Interrupt Cause register can be cleared in two ways, by either reading it or by writing '1' into the specific cause bit. This is documented in section 8.16.1. The following flow was used: 1. read E1000_TSIRC into 'tsicr'; 2. handle the interrupts present into 'tsirc' and mark them in 'ack'; 3. write 'ack' into E1000_TSICR; As both (1) and (3) will clear the interrupt cause, if the same interrupt happens again between (1) and (3) it will be ignored, causing events to be missed. Remove the extra clear in (3). Fixes: 00c65578b47b ("igb: enable internal PPS for the i210") Acked-by: Richard Cochran Signed-off-by: Vinicius Costa Gomes Tested-by: Pucha Himasekhar Reddy (A Co= ntingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/ethernet/intel/igb/igb_main.c | 23 +++++------------------ 1 file changed, 5 insertions(+), 18 deletions(-) diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethern= et/intel/igb/igb_main.c index cebb44f51d5f5..7662c42e35c11 100644 --- a/drivers/net/ethernet/intel/igb/igb_main.c +++ b/drivers/net/ethernet/intel/igb/igb_main.c @@ -6985,44 +6985,31 @@ static void igb_extts(struct igb_adapter *adapter, = int tsintr_tt) static void igb_tsync_interrupt(struct igb_adapter *adapter) { struct e1000_hw *hw =3D &adapter->hw; - u32 ack =3D 0, tsicr =3D rd32(E1000_TSICR); + u32 tsicr =3D rd32(E1000_TSICR); struct ptp_clock_event event; =20 if (tsicr & TSINTR_SYS_WRAP) { event.type =3D PTP_CLOCK_PPS; if (adapter->ptp_caps.pps) ptp_clock_event(adapter->ptp_clock, &event); - ack |=3D TSINTR_SYS_WRAP; } =20 if (tsicr & E1000_TSICR_TXTS) { /* retrieve hardware timestamp */ schedule_work(&adapter->ptp_tx_work); - ack |=3D E1000_TSICR_TXTS; } =20 - if (tsicr & TSINTR_TT0) { + if (tsicr & TSINTR_TT0) igb_perout(adapter, 0); - ack |=3D TSINTR_TT0; - } =20 - if (tsicr & TSINTR_TT1) { + if (tsicr & TSINTR_TT1) igb_perout(adapter, 1); - ack |=3D TSINTR_TT1; - } =20 - if (tsicr & TSINTR_AUTT0) { + if (tsicr & TSINTR_AUTT0) igb_extts(adapter, 0); - ack |=3D TSINTR_AUTT0; - } =20 - if (tsicr & TSINTR_AUTT1) { + if (tsicr & TSINTR_AUTT1) igb_extts(adapter, 1); - ack |=3D TSINTR_AUTT1; - } - - /* acknowledge the interrupts */ - wr32(E1000_TSICR, ack); } =20 static irqreturn_t igb_msix_other(int irq, void *data) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 314CE179FA9; Sun, 24 Mar 2024 22:39:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319996; cv=none; b=uU+5TBuqU/Ya0n0KiqAytUq+mIpW2nlbZN7Pg84BubWqH8IM2mF9FzJdbQICcWZzwwPC32M2h38m7h6WfNWyvHcPWGlux+ZM+3UWzzjszIYFu4ZV6qz+wA5K8CT3MvkpcNgxGesG8+kOCPI/HQ9rDxwkxPwPz4qgYIRVUe18u7U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319996; c=relaxed/simple; bh=Dt4ST1YsLTZdXovoH8qxzKx5QKkoan5vCwg9Px+ARL4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lULTCoiHiD/J4b1WmAoWbnpaOrsXmpf30rxRtovKaJcEnazt3m9npmVIsUkmvC7GuOsn88fpYOk+2OgRtuT7+JDtJhnKRCx4Ke2XKLO7detEcC48jY43XqzQP167aIwJGWXLa8mxGW/RAKXSqfFcmEAlcm3XdtEy5dbHkwU3tjY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f/Ict50e; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="f/Ict50e" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EF8D9C43390; Sun, 24 Mar 2024 22:39:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319996; bh=Dt4ST1YsLTZdXovoH8qxzKx5QKkoan5vCwg9Px+ARL4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f/Ict50eh4tg+B1We8GrAJtFLUMTrWN1hp+6t2rNSFpLXzRvtdE1mi1w1AYF1pApB 7dkRp9zpzjugl8zC2wPJnIb/VB0rslczl83L4oXjOItPXfL7wfspg3RJ9mgpRYB4H9 ffZoGwqsX/tiQEUvhnMtGih0PtCQtrGF7zqb8CeVOdqiVCGUg6gAWZi1FPsczlVvPW M6ON8Q6X46cLIRbvbJ98hNnktlHqwVixQonGhxnQgFlCoXsT43X3ialZjUANWeScsV H1BUoDqzAfDCbuP5QlQRzYQppITNdo8kLdvgQiguUQjUUNTgQNtZ9hoF8VsAwJlpsw pKTJEKiFTZAfA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Przemek Kitszel , Nebojsa Stevanovic , Christian Rohmann , Jacob Keller , Simon Horman , Pucha Himasekhar Reddy , Tony Nguyen , Sasha Levin Subject: [PATCH 6.8 301/715] ice: fix stats being updated by way too large values Date: Sun, 24 Mar 2024 18:28:00 -0400 Message-ID: <20240324223455.1342824-302-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Przemek Kitszel [ Upstream commit 257310e998700e60382fbd3f4fd275fdbd9b2aaf ] Simplify stats accumulation logic to fix the case where we don't take previous stat value into account, we should always respect it. Main netdev stats of our PF (Tx/Rx packets/bytes) were reported orders of magnitude too big during OpenStack reconfiguration events, possibly other reconfiguration cases too. The regression was reported to be between 6.1 and 6.2, so I was almost certain that on of the two "preserve stats over reset" commits were the culprit. While reading the code, it was found that in some cases we will increase the stats by arbitrarily large number (thanks to ignoring "-prev" part of condition, after zeroing it). Note that this fixes also the case where we were around limits of u64, but that was not the regression reported. Full disclosure: I remember suggesting this particular piece of code to Ben a few years ago, so blame on me. Fixes: 2fd5e433cd26 ("ice: Accumulate HW and Netdev statistics over reset") Reported-by: Nebojsa Stevanovic Link: https://lore.kernel.org/intel-wired-lan/VI1PR02MB439744DEDAA7B59B9A28= 33FE912EA@VI1PR02MB4397.eurprd02.prod.outlook.com Reported-by: Christian Rohmann Link: https://lore.kernel.org/intel-wired-lan/f38a6ca4-af05-48b1-a3e6-17ef2= 054e525@inovex.de Reviewed-by: Jacob Keller Signed-off-by: Przemek Kitszel Reviewed-by: Simon Horman Tested-by: Pucha Himasekhar Reddy (A Co= ntingent worker at Intel) Signed-off-by: Tony Nguyen Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/ethernet/intel/ice/ice_main.c | 24 +++++++++++------------ 1 file changed, 11 insertions(+), 13 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethern= et/intel/ice/ice_main.c index df6a68ab747ee..6d256dbcb77d0 100644 --- a/drivers/net/ethernet/intel/ice/ice_main.c +++ b/drivers/net/ethernet/intel/ice/ice_main.c @@ -6737,6 +6737,7 @@ static void ice_update_vsi_ring_stats(struct ice_vsi = *vsi) { struct rtnl_link_stats64 *net_stats, *stats_prev; struct rtnl_link_stats64 *vsi_stats; + struct ice_pf *pf =3D vsi->back; u64 pkts, bytes; int i; =20 @@ -6782,21 +6783,18 @@ static void ice_update_vsi_ring_stats(struct ice_vs= i *vsi) net_stats =3D &vsi->net_stats; stats_prev =3D &vsi->net_stats_prev; =20 - /* clear prev counters after reset */ - if (vsi_stats->tx_packets < stats_prev->tx_packets || - vsi_stats->rx_packets < stats_prev->rx_packets) { - stats_prev->tx_packets =3D 0; - stats_prev->tx_bytes =3D 0; - stats_prev->rx_packets =3D 0; - stats_prev->rx_bytes =3D 0; + /* Update netdev counters, but keep in mind that values could start at + * random value after PF reset. And as we increase the reported stat by + * diff of Prev-Cur, we need to be sure that Prev is valid. If it's not, + * let's skip this round. + */ + if (likely(pf->stat_prev_loaded)) { + net_stats->tx_packets +=3D vsi_stats->tx_packets - stats_prev->tx_packet= s; + net_stats->tx_bytes +=3D vsi_stats->tx_bytes - stats_prev->tx_bytes; + net_stats->rx_packets +=3D vsi_stats->rx_packets - stats_prev->rx_packet= s; + net_stats->rx_bytes +=3D vsi_stats->rx_bytes - stats_prev->rx_bytes; } =20 - /* update netdev counters */ - net_stats->tx_packets +=3D vsi_stats->tx_packets - stats_prev->tx_packets; - net_stats->tx_bytes +=3D vsi_stats->tx_bytes - stats_prev->tx_bytes; - net_stats->rx_packets +=3D vsi_stats->rx_packets - stats_prev->rx_packets; - net_stats->rx_bytes +=3D vsi_stats->rx_bytes - stats_prev->rx_bytes; - stats_prev->tx_packets =3D vsi_stats->tx_packets; stats_prev->tx_bytes =3D vsi_stats->tx_bytes; stats_prev->rx_packets =3D vsi_stats->rx_packets; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 19E28179FC5; Sun, 24 Mar 2024 22:39:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319997; cv=none; b=OYXnCPnYarlm7riv20HC7SeUJpwWP0ycTY2PzVHCsE01u7GYq6rh5/V46lfC/bjBUf1VRgY9KPPsi10/MfGLyDRuUUWO0WRX5n7OWHqFjLZSGin0G4uYG1jdVz4GZgl2Ga079jCfXjYaVsPy2+XmmXGmTjrX9FyHM6ISeuCdnX4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319997; c=relaxed/simple; bh=n0ZZGalvuA0PD6jzMmVDBM2mpyQqpmLP63G0KklBvQ4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=df6VaHJ/5vGD09ROJqc74ZlCYIvaDeKu6M5rRzHct0khoblh0lmLT53f8rV+X/3Bcmc2/zHNLnhZ+DSil7KzqgFvF6jHRYAnRXUYzAzgrSeCX1jF8MdZ+35BFBBbHeyyjOTPeqLMZ9DRuxjaCYCpFFNi3y2SL3XBXofFG/RT4Gs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IZTvSIb0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IZTvSIb0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 58CEBC433B2; Sun, 24 Mar 2024 22:39:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319997; bh=n0ZZGalvuA0PD6jzMmVDBM2mpyQqpmLP63G0KklBvQ4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IZTvSIb0qsdVsHz2aitxCc/ru/iBh4HqVvfsA33qHVOduBtJozK32deH3Hm0T3nSx tA4dNzBXHpBcAbH+VBfTli+hXdSRBXjEK0p3DwWxUFngu6fyB+YaAoF6OUmIN3Giq6 ktdqdUphVgUBl+GaNZeALDvKKAlFvJM73sHQyabZ5rArJm8P1gOSJeeFcBHqSMoFIz ukDHoxMxeHpzKMBMMERytedX7npYO5uRhFK0Umw5HwoP6+gAL0Eom530u2kNeJ1eJa eCW9mJp+2tINaCI1gYqYSQQQKjarISOxsrwMnGElC5X3ETU7pquiy4JnDd0HsP7g+u e3DZG9soO6BuQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Jonas=20Dre=C3=9Fler?= , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 302/715] Bluetooth: Remove HCI_POWER_OFF_TIMEOUT Date: Sun, 24 Mar 2024 18:28:01 -0400 Message-ID: <20240324223455.1342824-303-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Jonas Dre=C3=9Fler [ Upstream commit 968667f2e0345a67a6eea5a502f4659085666564 ] With commit cf75ad8b41d2 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED"), the power off sequence got refactored so that this timeout was no longer necessary, let's remove the leftover define from the header too. Fixes: cf75ad8b41d2 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED") Signed-off-by: Jonas Dre=C3=9Fler Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- include/net/bluetooth/hci.h | 1 - 1 file changed, 1 deletion(-) diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index bdee5d649cc61..f7918c7551834 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -437,7 +437,6 @@ enum { #define HCI_NCMD_TIMEOUT msecs_to_jiffies(4000) /* 4 seconds */ #define HCI_ACL_TX_TIMEOUT msecs_to_jiffies(45000) /* 45 seconds */ #define HCI_AUTO_OFF_TIMEOUT msecs_to_jiffies(2000) /* 2 seconds */ -#define HCI_POWER_OFF_TIMEOUT msecs_to_jiffies(5000) /* 5 seconds */ #define HCI_LE_CONN_TIMEOUT msecs_to_jiffies(20000) /* 20 seconds */ #define HCI_LE_AUTOCONN_TIMEOUT msecs_to_jiffies(4000) /* 4 seconds */ =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 044D65BADF; Sun, 24 Mar 2024 22:39:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319998; cv=none; b=fz3+6clHgVUmKBdID3qXxXnLAsRdQeMd3XAsydsZ+BqhPpXX540+Op890j+UukCNxcQdtBGon7LBweshTY5eQrB1KSkpxLizDPQaURzEi1RgRLgda5tF8CsSHybsZJwt5QPyyDnEOeM3CGI1oLbsZCbf+RmtrsxwZ23dU5JI6t8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319998; c=relaxed/simple; bh=tosONE1ZR1Z4f9tEU+BN8SkJFGiVft4BZq34dziYWus=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=L0qc3wdfhNcCYvoykVaMR7noXMPA6agktdIkSqDZH/JQL6tIs9TyMTc3Qiwk4Etwp7XA9aevEelyyvkWDKL6lxyG/bEOUbfT2EiweT9i9XaFJ5aTSXxLU0yV9RlYffgQfkx4vZshzYSjk+VVduJnX78kDWNOPCDiGtEmdto+cmE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=W7+MND6x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="W7+MND6x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 423F5C43394; Sun, 24 Mar 2024 22:39:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319997; bh=tosONE1ZR1Z4f9tEU+BN8SkJFGiVft4BZq34dziYWus=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=W7+MND6x3h7uq/RsHPnSspKDTVKiUiA2CicP6n+Lpc+dzVHMt6inioAo0Ps3nw45L /OCsFkQOLarcsgLuoLJSb/vox+6Tez3PA4tkYuBZ4YEyZxhn06VF7F5zH33BZ6TNx4 dy2CXrDSJwQt7lDHxf1Q/IPHOSnnzxnLEbLfoXyOsj3CbrIgYGrRxfeOOoeIsDPZz/ cJf94dC0p0IHSfLRnL2tg5HNoYW8eNpHsF0DW82VsmT5xvJfwnP7Qk6JbRq9ceBOO5 pCTdCq5G/m6vyC0n5O7UGI+NuFdQ9PzQApS7qZr1+zmPw7H0hya8nsxJOCMx8czKQf KGuVB0z9fKEog== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Jonas=20Dre=C3=9Fler?= , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 303/715] Bluetooth: mgmt: Remove leftover queuing of power_off work Date: Sun, 24 Mar 2024 18:28:02 -0400 Message-ID: <20240324223455.1342824-304-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Jonas Dre=C3=9Fler [ Upstream commit fee054b7579fe252f8b9e6c17b9c5bfdaa84dd7e ] Queuing of power_off work was introduced in these functions with commits 8b064a3ad377 ("Bluetooth: Clean up HCI state when doing power off") and c9910d0fb4fc ("Bluetooth: Fix disconnecting connections in non-connected states") in an effort to clean up state and do things like disconnecting devices before actually powering off the device. After that, commit a3172b7eb4a2 ("Bluetooth: Add timer to force power off") introduced a timeout to ensure that the device actually got powered off, even if some of the cleanup work would never complete. This code later got refactored with commit cf75ad8b41d2 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED"), which made powering off the device synchronous and removed the need for initiating the power_off work from other places. The timeout mentioned above got removed too, because we now also made use of the command timeout during power on/off. These days the power_off work still exists, but it only seems to only be used for HCI_AUTO_OFF functionality, which is why we never noticed those two leftover places where we queue power_off work. So let's remove that code. Fixes: cf75ad8b41d2 ("Bluetooth: hci_sync: Convert MGMT_SET_POWERED") Signed-off-by: Jonas Dre=C3=9Fler Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/bluetooth/mgmt.c | 16 ---------------- 1 file changed, 16 deletions(-) diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index ee3b4aad8bd8d..688890f581cba 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -9766,14 +9766,6 @@ void mgmt_device_disconnected(struct hci_dev *hdev, = bdaddr_t *bdaddr, struct mgmt_ev_device_disconnected ev; struct sock *sk =3D NULL; =20 - /* The connection is still in hci_conn_hash so test for 1 - * instead of 0 to know if this is the last one. - */ - if (mgmt_powering_down(hdev) && hci_conn_count(hdev) =3D=3D 1) { - cancel_delayed_work(&hdev->power_off); - queue_work(hdev->req_workqueue, &hdev->power_off.work); - } - if (!mgmt_connected) return; =20 @@ -9830,14 +9822,6 @@ void mgmt_connect_failed(struct hci_dev *hdev, bdadd= r_t *bdaddr, u8 link_type, { struct mgmt_ev_connect_failed ev; =20 - /* The connection is still in hci_conn_hash so test for 1 - * instead of 0 to know if this is the last one. - */ - if (mgmt_powering_down(hdev) && hci_conn_count(hdev) =3D=3D 1) { - cancel_delayed_work(&hdev->power_off); - queue_work(hdev->req_workqueue, &hdev->power_off.work); - } - bacpy(&ev.addr.bdaddr, bdaddr); ev.addr.type =3D link_to_bdaddr(link_type, addr_type); ev.status =3D mgmt_status(status); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 35BC713119F; Sun, 24 Mar 2024 22:39:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319999; cv=none; b=XLiGpBXHvlnRRgBFcQ9C2giv4kc0xCjSES9y7COl21jCYHxfFlE45V0esE7yzIC/j8UGDJcKwy0R8FsR0vOXWMWyJ/w5+kas6PR3pV4/h50dfoJwABYIUmWtBcbxDB2FoIgiqTFR6zbMohCsGcRFhkgSHjzwh8fcgLfFVOZG2eU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319999; c=relaxed/simple; bh=8/kr8B8u6KwyMHX/o0qNOYBBY6aCjmBMpsM2+5DKcnw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MW305bzCFEUHLJuK0XRocumblgrB2oHLoRf1OzF0QCSShd3m5eQLBpG/XJW9Rlzh4kjtIvBiO5DKNm1QiyUiUxfzmgs4O9eJjjfFsLDKYxs1NQja7+wF9yedTXyAVWOc0l+1WeqUvv7z5n2MI06/tprb/YxTCe3FsmnuvPOXyu8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dZK1Iuhk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dZK1Iuhk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 296F1C433C7; Sun, 24 Mar 2024 22:39:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319998; bh=8/kr8B8u6KwyMHX/o0qNOYBBY6aCjmBMpsM2+5DKcnw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dZK1Iuhk/SXLQRR6J3B2oDp273pDInNZugbj3QvJa1ABmwBeFWbTbkCzWNEVLE5Kl gAzlIC/juLeBu3+Mqz/zW+20ZiEzrr7qyEKFSqlrnJKvvIqxORgOco9zABNyMjmHRT 3nYXBMjAwIPX75WXOce4OO3qXcYdQXAUmOxVe1UqajeEOlI129/Gc7Zcom2NmilXnF nHT1P+loJsgxgvNvaEVjQDZhGc9U7HuJdfDJBQNjE2QJw6p0D8jeFMdTyffATwSdKe tIRHDNYJe22/6/NAf8FAJvlmt/bgZX083ArOfq2todb1dEofj9Dw5h/Z+sKp/YNpKq p26WDFmPXPIjA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Jonas=20Dre=C3=9Fler?= , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 304/715] Bluetooth: Remove superfluous call to hci_conn_check_pending() Date: Sun, 24 Mar 2024 18:28:03 -0400 Message-ID: <20240324223455.1342824-305-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Jonas Dre=C3=9Fler [ Upstream commit 78e3639fc8031275010c3287ac548c0bc8de83b1 ] The "pending connections" feature was originally introduced with commit 4c67bc74f016 ("[Bluetooth] Support concurrent connect requests") and 6bd57416127e ("[Bluetooth] Handling pending connect attempts after inquiry") to handle controllers supporting only a single connection request at a time. Later things were extended to also cancel ongoing inquiries on connect() with commit 89e65975fea5 ("Bluetooth: Cancel Inquiry before Create Connection"). With commit a9de9248064b ("[Bluetooth] Switch from OGF+OCF to using only opcodes"), hci_conn_check_pending() was introduced as a helper to consolidate a few places where we check for pending connections (indicated by the BT_CONNECT2 flag) and then try to connect. This refactoring commit also snuck in two more calls to hci_conn_check_pending(): - One is in the failure callback of hci_cs_inquiry(), this one probably makes sense: If we send an "HCI Inquiry" command and then immediately after a "Create Connection" command, the "Create Connection" command might fail before the "HCI Inquiry" command, and then we want to retry the "Create Connection" on failure of the "HCI Inquiry". - The other added call to hci_conn_check_pending() is in the event handler for the "Remote Name" event, this seems unrelated and is possibly a copy-paste error, so remove that one. Fixes: a9de9248064b ("[Bluetooth] Switch from OGF+OCF to using only opcodes= ") Signed-off-by: Jonas Dre=C3=9Fler Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/bluetooth/hci_event.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index 2a5f5a7d2412b..1f63f77661dce 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -3556,8 +3556,6 @@ static void hci_remote_name_evt(struct hci_dev *hdev,= void *data, =20 bt_dev_dbg(hdev, "status 0x%2.2x", ev->status); =20 - hci_conn_check_pending(hdev); - hci_dev_lock(hdev); =20 conn =3D hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D5C721311B5; Sun, 24 Mar 2024 22:39:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319999; cv=none; b=d/9taYBf2Zh8FQng7GirH437foHJjpIPNM6xs8/uo2PvNE77FM41KpVZcPYuctKIcAnDeIZyJwBGOIgjO2K9St5+awiFxNL+wDtzLgpr8LbfdSx/O4Ga14S17SlPm+XNXPflQG6NKUMMHxsbBJb+AOMNx7tcWKkjFr6J+K1gJh8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711319999; c=relaxed/simple; bh=T1pWRrHiJEEPiNDVJFo1csXwp/rRnRNh9HE8l96xm7Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XbCukutGS3XAouv8aNSuH0lQ+6qj5+HA3TLksliqaicKQmR3MGFyvpTDsw2VbHK52zmJDDf0qJ5auQwfSdSidVBFfTpzNIGCH71wxbR4pJEBj+2OILx3CH/JIAzrQbAWy5MteKiURGUKTXTjtnB5Y7kqLLK7+SCnx7Kjg1HXKFE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rZTtXy7X; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rZTtXy7X" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11601C433F1; Sun, 24 Mar 2024 22:39:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711319999; bh=T1pWRrHiJEEPiNDVJFo1csXwp/rRnRNh9HE8l96xm7Q=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rZTtXy7XxoBippyD3SGf/+frellQlh67QqbOzjJqntvB1rMzAjR+IzZtuyiCCIg30 HiSDJRfpbHk+lu2+q0Q/ZZnKkEfBOislzfi0KMfQ/JtQfJgq2g2PVgXHV6EtD21fyK KNds7VHcfbnsurcmbNdVJ3k60NeykD7H9KlSsLcpz/6ibIELhU7pzcSRZbW92KJ14W MmklbKcdwqYhIyMprvAbgve0jTLkBhh8E2tNvu1zMlVaoRjaVWAtQsl/iEJm1Su/dq a7OWaTcRLqSddTb71qGvzZr8d8Fu+IuI9W7e35DMeqKkipVz3hmRFMTqtnDcpg/2qR gXgUm+3JacYNQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 305/715] Bluetooth: Remove BT_HS Date: Sun, 24 Mar 2024 18:28:04 -0400 Message-ID: <20240324223455.1342824-306-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit e7b02296fb400ee64822fbdd81a0718449066333 ] High Speed, Alternate MAC and PHY (AMP) extension, has been removed from Bluetooth Core specification on 5.3: https://www.bluetooth.com/blog/new-core-specification-v5-3-feature-enhancem= ents/ Fixes: 244bc377591c ("Bluetooth: Add BT_HS config option") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- include/net/bluetooth/hci.h | 1 - include/net/bluetooth/l2cap.h | 42 -- net/bluetooth/Kconfig | 8 - net/bluetooth/Makefile | 1 - net/bluetooth/a2mp.c | 1054 -------------------------------- net/bluetooth/a2mp.h | 154 ----- net/bluetooth/amp.c | 590 ------------------ net/bluetooth/amp.h | 60 -- net/bluetooth/hci_conn.c | 4 - net/bluetooth/hci_event.c | 2 - net/bluetooth/l2cap_core.c | 1069 +-------------------------------- net/bluetooth/l2cap_sock.c | 18 +- net/bluetooth/mgmt.c | 73 +-- 13 files changed, 20 insertions(+), 3056 deletions(-) delete mode 100644 net/bluetooth/a2mp.c delete mode 100644 net/bluetooth/a2mp.h delete mode 100644 net/bluetooth/amp.c delete mode 100644 net/bluetooth/amp.h diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h index f7918c7551834..0d231024570a3 100644 --- a/include/net/bluetooth/hci.h +++ b/include/net/bluetooth/hci.h @@ -393,7 +393,6 @@ enum { HCI_LIMITED_PRIVACY, HCI_RPA_EXPIRED, HCI_RPA_RESOLVING, - HCI_HS_ENABLED, HCI_LE_ENABLED, HCI_ADVERTISING, HCI_ADVERTISING_CONNECTABLE, diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h index cf393e72d6ed6..92d7197f9a563 100644 --- a/include/net/bluetooth/l2cap.h +++ b/include/net/bluetooth/l2cap.h @@ -59,8 +59,6 @@ #define L2CAP_WAIT_ACK_POLL_PERIOD msecs_to_jiffies(200) #define L2CAP_WAIT_ACK_TIMEOUT msecs_to_jiffies(10000) =20 -#define L2CAP_A2MP_DEFAULT_MTU 670 - /* L2CAP socket address */ struct sockaddr_l2 { sa_family_t l2_family; @@ -109,12 +107,6 @@ struct l2cap_conninfo { #define L2CAP_ECHO_RSP 0x09 #define L2CAP_INFO_REQ 0x0a #define L2CAP_INFO_RSP 0x0b -#define L2CAP_CREATE_CHAN_REQ 0x0c -#define L2CAP_CREATE_CHAN_RSP 0x0d -#define L2CAP_MOVE_CHAN_REQ 0x0e -#define L2CAP_MOVE_CHAN_RSP 0x0f -#define L2CAP_MOVE_CHAN_CFM 0x10 -#define L2CAP_MOVE_CHAN_CFM_RSP 0x11 #define L2CAP_CONN_PARAM_UPDATE_REQ 0x12 #define L2CAP_CONN_PARAM_UPDATE_RSP 0x13 #define L2CAP_LE_CONN_REQ 0x14 @@ -144,7 +136,6 @@ struct l2cap_conninfo { /* L2CAP fixed channels */ #define L2CAP_FC_SIG_BREDR 0x02 #define L2CAP_FC_CONNLESS 0x04 -#define L2CAP_FC_A2MP 0x08 #define L2CAP_FC_ATT 0x10 #define L2CAP_FC_SIG_LE 0x20 #define L2CAP_FC_SMP_LE 0x40 @@ -267,7 +258,6 @@ struct l2cap_conn_rsp { /* channel identifier */ #define L2CAP_CID_SIGNALING 0x0001 #define L2CAP_CID_CONN_LESS 0x0002 -#define L2CAP_CID_A2MP 0x0003 #define L2CAP_CID_ATT 0x0004 #define L2CAP_CID_LE_SIGNALING 0x0005 #define L2CAP_CID_SMP 0x0006 @@ -282,7 +272,6 @@ struct l2cap_conn_rsp { #define L2CAP_CR_BAD_PSM 0x0002 #define L2CAP_CR_SEC_BLOCK 0x0003 #define L2CAP_CR_NO_MEM 0x0004 -#define L2CAP_CR_BAD_AMP 0x0005 #define L2CAP_CR_INVALID_SCID 0x0006 #define L2CAP_CR_SCID_IN_USE 0x0007 =20 @@ -404,29 +393,6 @@ struct l2cap_info_rsp { __u8 data[]; } __packed; =20 -struct l2cap_create_chan_req { - __le16 psm; - __le16 scid; - __u8 amp_id; -} __packed; - -struct l2cap_create_chan_rsp { - __le16 dcid; - __le16 scid; - __le16 result; - __le16 status; -} __packed; - -struct l2cap_move_chan_req { - __le16 icid; - __u8 dest_amp_id; -} __packed; - -struct l2cap_move_chan_rsp { - __le16 icid; - __le16 result; -} __packed; - #define L2CAP_MR_SUCCESS 0x0000 #define L2CAP_MR_PEND 0x0001 #define L2CAP_MR_BAD_ID 0x0002 @@ -539,8 +505,6 @@ struct l2cap_seq_list { =20 struct l2cap_chan { struct l2cap_conn *conn; - struct hci_conn *hs_hcon; - struct hci_chan *hs_hchan; struct kref kref; atomic_t nesting; =20 @@ -591,12 +555,6 @@ struct l2cap_chan { unsigned long conn_state; unsigned long flags; =20 - __u8 remote_amp_id; - __u8 local_amp_id; - __u8 move_id; - __u8 move_state; - __u8 move_role; - __u16 next_tx_seq; __u16 expected_ack_seq; __u16 expected_tx_seq; diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig index da7cac0a1b716..6b2b65a667008 100644 --- a/net/bluetooth/Kconfig +++ b/net/bluetooth/Kconfig @@ -62,14 +62,6 @@ source "net/bluetooth/cmtp/Kconfig" =20 source "net/bluetooth/hidp/Kconfig" =20 -config BT_HS - bool "Bluetooth High Speed (HS) features" - depends on BT_BREDR - help - Bluetooth High Speed includes support for off-loading - Bluetooth connections via 802.11 (wifi) physical layer - available with Bluetooth version 3.0 or later. - config BT_LE bool "Bluetooth Low Energy (LE) features" depends on BT diff --git a/net/bluetooth/Makefile b/net/bluetooth/Makefile index 141ac1fda0bfa..628d448d78be3 100644 --- a/net/bluetooth/Makefile +++ b/net/bluetooth/Makefile @@ -21,7 +21,6 @@ bluetooth-$(CONFIG_DEV_COREDUMP) +=3D coredump.o =20 bluetooth-$(CONFIG_BT_BREDR) +=3D sco.o bluetooth-$(CONFIG_BT_LE) +=3D iso.o -bluetooth-$(CONFIG_BT_HS) +=3D a2mp.o amp.o bluetooth-$(CONFIG_BT_LEDS) +=3D leds.o bluetooth-$(CONFIG_BT_MSFTEXT) +=3D msft.o bluetooth-$(CONFIG_BT_AOSPEXT) +=3D aosp.o diff --git a/net/bluetooth/a2mp.c b/net/bluetooth/a2mp.c deleted file mode 100644 index e7adb8a98cf90..0000000000000 --- a/net/bluetooth/a2mp.c +++ /dev/null @@ -1,1054 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0-only -/* - Copyright (c) 2010,2011 Code Aurora Forum. All rights reserved. - Copyright (c) 2011,2012 Intel Corp. - -*/ - -#include -#include -#include - -#include "hci_request.h" -#include "a2mp.h" -#include "amp.h" - -#define A2MP_FEAT_EXT 0x8000 - -/* Global AMP Manager list */ -static LIST_HEAD(amp_mgr_list); -static DEFINE_MUTEX(amp_mgr_list_lock); - -/* A2MP build & send command helper functions */ -static struct a2mp_cmd *__a2mp_build(u8 code, u8 ident, u16 len, void *dat= a) -{ - struct a2mp_cmd *cmd; - int plen; - - plen =3D sizeof(*cmd) + len; - cmd =3D kzalloc(plen, GFP_KERNEL); - if (!cmd) - return NULL; - - cmd->code =3D code; - cmd->ident =3D ident; - cmd->len =3D cpu_to_le16(len); - - memcpy(cmd->data, data, len); - - return cmd; -} - -static void a2mp_send(struct amp_mgr *mgr, u8 code, u8 ident, u16 len, voi= d *data) -{ - struct l2cap_chan *chan =3D mgr->a2mp_chan; - struct a2mp_cmd *cmd; - u16 total_len =3D len + sizeof(*cmd); - struct kvec iv; - struct msghdr msg; - - cmd =3D __a2mp_build(code, ident, len, data); - if (!cmd) - return; - - iv.iov_base =3D cmd; - iv.iov_len =3D total_len; - - memset(&msg, 0, sizeof(msg)); - - iov_iter_kvec(&msg.msg_iter, ITER_SOURCE, &iv, 1, total_len); - - l2cap_chan_send(chan, &msg, total_len); - - kfree(cmd); -} - -static u8 __next_ident(struct amp_mgr *mgr) -{ - if (++mgr->ident =3D=3D 0) - mgr->ident =3D 1; - - return mgr->ident; -} - -static struct amp_mgr *amp_mgr_lookup_by_state(u8 state) -{ - struct amp_mgr *mgr; - - mutex_lock(&_mgr_list_lock); - list_for_each_entry(mgr, &_mgr_list, list) { - if (test_and_clear_bit(state, &mgr->state)) { - amp_mgr_get(mgr); - mutex_unlock(&_mgr_list_lock); - return mgr; - } - } - mutex_unlock(&_mgr_list_lock); - - return NULL; -} - -/* hci_dev_list shall be locked */ -static void __a2mp_add_cl(struct amp_mgr *mgr, struct a2mp_cl *cl) -{ - struct hci_dev *hdev; - int i =3D 1; - - cl[0].id =3D AMP_ID_BREDR; - cl[0].type =3D AMP_TYPE_BREDR; - cl[0].status =3D AMP_STATUS_BLUETOOTH_ONLY; - - list_for_each_entry(hdev, &hci_dev_list, list) { - if (hdev->dev_type =3D=3D HCI_AMP) { - cl[i].id =3D hdev->id; - cl[i].type =3D hdev->amp_type; - if (test_bit(HCI_UP, &hdev->flags)) - cl[i].status =3D hdev->amp_status; - else - cl[i].status =3D AMP_STATUS_POWERED_DOWN; - i++; - } - } -} - -/* Processing A2MP messages */ -static int a2mp_command_rej(struct amp_mgr *mgr, struct sk_buff *skb, - struct a2mp_cmd *hdr) -{ - struct a2mp_cmd_rej *rej =3D (void *) skb->data; - - if (le16_to_cpu(hdr->len) < sizeof(*rej)) - return -EINVAL; - - BT_DBG("ident %u reason %d", hdr->ident, le16_to_cpu(rej->reason)); - - skb_pull(skb, sizeof(*rej)); - - return 0; -} - -static int a2mp_discover_req(struct amp_mgr *mgr, struct sk_buff *skb, - struct a2mp_cmd *hdr) -{ - struct a2mp_discov_req *req =3D (void *) skb->data; - u16 len =3D le16_to_cpu(hdr->len); - struct a2mp_discov_rsp *rsp; - u16 ext_feat; - u8 num_ctrl; - struct hci_dev *hdev; - - if (len < sizeof(*req)) - return -EINVAL; - - skb_pull(skb, sizeof(*req)); - - ext_feat =3D le16_to_cpu(req->ext_feat); - - BT_DBG("mtu %d efm 0x%4.4x", le16_to_cpu(req->mtu), ext_feat); - - /* check that packet is not broken for now */ - while (ext_feat & A2MP_FEAT_EXT) { - if (len < sizeof(ext_feat)) - return -EINVAL; - - ext_feat =3D get_unaligned_le16(skb->data); - BT_DBG("efm 0x%4.4x", ext_feat); - len -=3D sizeof(ext_feat); - skb_pull(skb, sizeof(ext_feat)); - } - - read_lock(&hci_dev_list_lock); - - /* at minimum the BR/EDR needs to be listed */ - num_ctrl =3D 1; - - list_for_each_entry(hdev, &hci_dev_list, list) { - if (hdev->dev_type =3D=3D HCI_AMP) - num_ctrl++; - } - - len =3D struct_size(rsp, cl, num_ctrl); - rsp =3D kmalloc(len, GFP_ATOMIC); - if (!rsp) { - read_unlock(&hci_dev_list_lock); - return -ENOMEM; - } - - rsp->mtu =3D cpu_to_le16(L2CAP_A2MP_DEFAULT_MTU); - rsp->ext_feat =3D 0; - - __a2mp_add_cl(mgr, rsp->cl); - - read_unlock(&hci_dev_list_lock); - - a2mp_send(mgr, A2MP_DISCOVER_RSP, hdr->ident, len, rsp); - - kfree(rsp); - return 0; -} - -static int a2mp_discover_rsp(struct amp_mgr *mgr, struct sk_buff *skb, - struct a2mp_cmd *hdr) -{ - struct a2mp_discov_rsp *rsp =3D (void *) skb->data; - u16 len =3D le16_to_cpu(hdr->len); - struct a2mp_cl *cl; - u16 ext_feat; - bool found =3D false; - - if (len < sizeof(*rsp)) - return -EINVAL; - - len -=3D sizeof(*rsp); - skb_pull(skb, sizeof(*rsp)); - - ext_feat =3D le16_to_cpu(rsp->ext_feat); - - BT_DBG("mtu %d efm 0x%4.4x", le16_to_cpu(rsp->mtu), ext_feat); - - /* check that packet is not broken for now */ - while (ext_feat & A2MP_FEAT_EXT) { - if (len < sizeof(ext_feat)) - return -EINVAL; - - ext_feat =3D get_unaligned_le16(skb->data); - BT_DBG("efm 0x%4.4x", ext_feat); - len -=3D sizeof(ext_feat); - skb_pull(skb, sizeof(ext_feat)); - } - - cl =3D (void *) skb->data; - while (len >=3D sizeof(*cl)) { - BT_DBG("Remote AMP id %u type %u status %u", cl->id, cl->type, - cl->status); - - if (cl->id !=3D AMP_ID_BREDR && cl->type !=3D AMP_TYPE_BREDR) { - struct a2mp_info_req req; - - found =3D true; - - memset(&req, 0, sizeof(req)); - - req.id =3D cl->id; - a2mp_send(mgr, A2MP_GETINFO_REQ, __next_ident(mgr), - sizeof(req), &req); - } - - len -=3D sizeof(*cl); - cl =3D skb_pull(skb, sizeof(*cl)); - } - - /* Fall back to L2CAP init sequence */ - if (!found) { - struct l2cap_conn *conn =3D mgr->l2cap_conn; - struct l2cap_chan *chan; - - mutex_lock(&conn->chan_lock); - - list_for_each_entry(chan, &conn->chan_l, list) { - - BT_DBG("chan %p state %s", chan, - state_to_string(chan->state)); - - if (chan->scid =3D=3D L2CAP_CID_A2MP) - continue; - - l2cap_chan_lock(chan); - - if (chan->state =3D=3D BT_CONNECT) - l2cap_send_conn_req(chan); - - l2cap_chan_unlock(chan); - } - - mutex_unlock(&conn->chan_lock); - } - - return 0; -} - -static int a2mp_change_notify(struct amp_mgr *mgr, struct sk_buff *skb, - struct a2mp_cmd *hdr) -{ - struct a2mp_cl *cl =3D (void *) skb->data; - - while (skb->len >=3D sizeof(*cl)) { - BT_DBG("Controller id %u type %u status %u", cl->id, cl->type, - cl->status); - cl =3D skb_pull(skb, sizeof(*cl)); - } - - /* TODO send A2MP_CHANGE_RSP */ - - return 0; -} - -static void read_local_amp_info_complete(struct hci_dev *hdev, u8 status, - u16 opcode) -{ - BT_DBG("%s status 0x%2.2x", hdev->name, status); - - a2mp_send_getinfo_rsp(hdev); -} - -static int a2mp_getinfo_req(struct amp_mgr *mgr, struct sk_buff *skb, - struct a2mp_cmd *hdr) -{ - struct a2mp_info_req *req =3D (void *) skb->data; - struct hci_dev *hdev; - struct hci_request hreq; - int err =3D 0; - - if (le16_to_cpu(hdr->len) < sizeof(*req)) - return -EINVAL; - - BT_DBG("id %u", req->id); - - hdev =3D hci_dev_get(req->id); - if (!hdev || hdev->dev_type !=3D HCI_AMP) { - struct a2mp_info_rsp rsp; - - memset(&rsp, 0, sizeof(rsp)); - - rsp.id =3D req->id; - rsp.status =3D A2MP_STATUS_INVALID_CTRL_ID; - - a2mp_send(mgr, A2MP_GETINFO_RSP, hdr->ident, sizeof(rsp), - &rsp); - - goto done; - } - - set_bit(READ_LOC_AMP_INFO, &mgr->state); - hci_req_init(&hreq, hdev); - hci_req_add(&hreq, HCI_OP_READ_LOCAL_AMP_INFO, 0, NULL); - err =3D hci_req_run(&hreq, read_local_amp_info_complete); - if (err < 0) - a2mp_send_getinfo_rsp(hdev); - -done: - if (hdev) - hci_dev_put(hdev); - - skb_pull(skb, sizeof(*req)); - return 0; -} - -static int a2mp_getinfo_rsp(struct amp_mgr *mgr, struct sk_buff *skb, - struct a2mp_cmd *hdr) -{ - struct a2mp_info_rsp *rsp =3D (struct a2mp_info_rsp *) skb->data; - struct a2mp_amp_assoc_req req; - struct amp_ctrl *ctrl; - - if (le16_to_cpu(hdr->len) < sizeof(*rsp)) - return -EINVAL; - - BT_DBG("id %u status 0x%2.2x", rsp->id, rsp->status); - - if (rsp->status) - return -EINVAL; - - ctrl =3D amp_ctrl_add(mgr, rsp->id); - if (!ctrl) - return -ENOMEM; - - memset(&req, 0, sizeof(req)); - - req.id =3D rsp->id; - a2mp_send(mgr, A2MP_GETAMPASSOC_REQ, __next_ident(mgr), sizeof(req), - &req); - - skb_pull(skb, sizeof(*rsp)); - return 0; -} - -static int a2mp_getampassoc_req(struct amp_mgr *mgr, struct sk_buff *skb, - struct a2mp_cmd *hdr) -{ - struct a2mp_amp_assoc_req *req =3D (void *) skb->data; - struct hci_dev *hdev; - struct amp_mgr *tmp; - - if (le16_to_cpu(hdr->len) < sizeof(*req)) - return -EINVAL; - - BT_DBG("id %u", req->id); - - /* Make sure that other request is not processed */ - tmp =3D amp_mgr_lookup_by_state(READ_LOC_AMP_ASSOC); - - hdev =3D hci_dev_get(req->id); - if (!hdev || hdev->amp_type =3D=3D AMP_TYPE_BREDR || tmp) { - struct a2mp_amp_assoc_rsp rsp; - - memset(&rsp, 0, sizeof(rsp)); - rsp.id =3D req->id; - - if (tmp) { - rsp.status =3D A2MP_STATUS_COLLISION_OCCURED; - amp_mgr_put(tmp); - } else { - rsp.status =3D A2MP_STATUS_INVALID_CTRL_ID; - } - - a2mp_send(mgr, A2MP_GETAMPASSOC_RSP, hdr->ident, sizeof(rsp), - &rsp); - - goto done; - } - - amp_read_loc_assoc(hdev, mgr); - -done: - if (hdev) - hci_dev_put(hdev); - - skb_pull(skb, sizeof(*req)); - return 0; -} - -static int a2mp_getampassoc_rsp(struct amp_mgr *mgr, struct sk_buff *skb, - struct a2mp_cmd *hdr) -{ - struct a2mp_amp_assoc_rsp *rsp =3D (void *) skb->data; - u16 len =3D le16_to_cpu(hdr->len); - struct hci_dev *hdev; - struct amp_ctrl *ctrl; - struct hci_conn *hcon; - size_t assoc_len; - - if (len < sizeof(*rsp)) - return -EINVAL; - - assoc_len =3D len - sizeof(*rsp); - - BT_DBG("id %u status 0x%2.2x assoc len %zu", rsp->id, rsp->status, - assoc_len); - - if (rsp->status) - return -EINVAL; - - /* Save remote ASSOC data */ - ctrl =3D amp_ctrl_lookup(mgr, rsp->id); - if (ctrl) { - u8 *assoc; - - assoc =3D kmemdup(rsp->amp_assoc, assoc_len, GFP_KERNEL); - if (!assoc) { - amp_ctrl_put(ctrl); - return -ENOMEM; - } - - ctrl->assoc =3D assoc; - ctrl->assoc_len =3D assoc_len; - ctrl->assoc_rem_len =3D assoc_len; - ctrl->assoc_len_so_far =3D 0; - - amp_ctrl_put(ctrl); - } - - /* Create Phys Link */ - hdev =3D hci_dev_get(rsp->id); - if (!hdev) - return -EINVAL; - - hcon =3D phylink_add(hdev, mgr, rsp->id, true); - if (!hcon) - goto done; - - BT_DBG("Created hcon %p: loc:%u -> rem:%u", hcon, hdev->id, rsp->id); - - mgr->bredr_chan->remote_amp_id =3D rsp->id; - - amp_create_phylink(hdev, mgr, hcon); - -done: - hci_dev_put(hdev); - skb_pull(skb, len); - return 0; -} - -static int a2mp_createphyslink_req(struct amp_mgr *mgr, struct sk_buff *sk= b, - struct a2mp_cmd *hdr) -{ - struct a2mp_physlink_req *req =3D (void *) skb->data; - struct a2mp_physlink_rsp rsp; - struct hci_dev *hdev; - struct hci_conn *hcon; - struct amp_ctrl *ctrl; - - if (le16_to_cpu(hdr->len) < sizeof(*req)) - return -EINVAL; - - BT_DBG("local_id %u, remote_id %u", req->local_id, req->remote_id); - - memset(&rsp, 0, sizeof(rsp)); - - rsp.local_id =3D req->remote_id; - rsp.remote_id =3D req->local_id; - - hdev =3D hci_dev_get(req->remote_id); - if (!hdev || hdev->amp_type =3D=3D AMP_TYPE_BREDR) { - rsp.status =3D A2MP_STATUS_INVALID_CTRL_ID; - goto send_rsp; - } - - ctrl =3D amp_ctrl_lookup(mgr, rsp.remote_id); - if (!ctrl) { - ctrl =3D amp_ctrl_add(mgr, rsp.remote_id); - if (ctrl) { - amp_ctrl_get(ctrl); - } else { - rsp.status =3D A2MP_STATUS_UNABLE_START_LINK_CREATION; - goto send_rsp; - } - } - - if (ctrl) { - size_t assoc_len =3D le16_to_cpu(hdr->len) - sizeof(*req); - u8 *assoc; - - assoc =3D kmemdup(req->amp_assoc, assoc_len, GFP_KERNEL); - if (!assoc) { - amp_ctrl_put(ctrl); - hci_dev_put(hdev); - return -ENOMEM; - } - - ctrl->assoc =3D assoc; - ctrl->assoc_len =3D assoc_len; - ctrl->assoc_rem_len =3D assoc_len; - ctrl->assoc_len_so_far =3D 0; - - amp_ctrl_put(ctrl); - } - - hcon =3D phylink_add(hdev, mgr, req->local_id, false); - if (hcon) { - amp_accept_phylink(hdev, mgr, hcon); - rsp.status =3D A2MP_STATUS_SUCCESS; - } else { - rsp.status =3D A2MP_STATUS_UNABLE_START_LINK_CREATION; - } - -send_rsp: - if (hdev) - hci_dev_put(hdev); - - /* Reply error now and success after HCI Write Remote AMP Assoc - command complete with success status - */ - if (rsp.status !=3D A2MP_STATUS_SUCCESS) { - a2mp_send(mgr, A2MP_CREATEPHYSLINK_RSP, hdr->ident, - sizeof(rsp), &rsp); - } else { - set_bit(WRITE_REMOTE_AMP_ASSOC, &mgr->state); - mgr->ident =3D hdr->ident; - } - - skb_pull(skb, le16_to_cpu(hdr->len)); - return 0; -} - -static int a2mp_discphyslink_req(struct amp_mgr *mgr, struct sk_buff *skb, - struct a2mp_cmd *hdr) -{ - struct a2mp_physlink_req *req =3D (void *) skb->data; - struct a2mp_physlink_rsp rsp; - struct hci_dev *hdev; - struct hci_conn *hcon; - - if (le16_to_cpu(hdr->len) < sizeof(*req)) - return -EINVAL; - - BT_DBG("local_id %u remote_id %u", req->local_id, req->remote_id); - - memset(&rsp, 0, sizeof(rsp)); - - rsp.local_id =3D req->remote_id; - rsp.remote_id =3D req->local_id; - rsp.status =3D A2MP_STATUS_SUCCESS; - - hdev =3D hci_dev_get(req->remote_id); - if (!hdev) { - rsp.status =3D A2MP_STATUS_INVALID_CTRL_ID; - goto send_rsp; - } - - hcon =3D hci_conn_hash_lookup_ba(hdev, AMP_LINK, - &mgr->l2cap_conn->hcon->dst); - if (!hcon) { - bt_dev_err(hdev, "no phys link exist"); - rsp.status =3D A2MP_STATUS_NO_PHYSICAL_LINK_EXISTS; - goto clean; - } - - /* TODO Disconnect Phys Link here */ - -clean: - hci_dev_put(hdev); - -send_rsp: - a2mp_send(mgr, A2MP_DISCONNPHYSLINK_RSP, hdr->ident, sizeof(rsp), &rsp); - - skb_pull(skb, sizeof(*req)); - return 0; -} - -static inline int a2mp_cmd_rsp(struct amp_mgr *mgr, struct sk_buff *skb, - struct a2mp_cmd *hdr) -{ - BT_DBG("ident %u code 0x%2.2x", hdr->ident, hdr->code); - - skb_pull(skb, le16_to_cpu(hdr->len)); - return 0; -} - -/* Handle A2MP signalling */ -static int a2mp_chan_recv_cb(struct l2cap_chan *chan, struct sk_buff *skb) -{ - struct a2mp_cmd *hdr; - struct amp_mgr *mgr =3D chan->data; - int err =3D 0; - - amp_mgr_get(mgr); - - while (skb->len >=3D sizeof(*hdr)) { - u16 len; - - hdr =3D (void *) skb->data; - len =3D le16_to_cpu(hdr->len); - - BT_DBG("code 0x%2.2x id %u len %u", hdr->code, hdr->ident, len); - - skb_pull(skb, sizeof(*hdr)); - - if (len > skb->len || !hdr->ident) { - err =3D -EINVAL; - break; - } - - mgr->ident =3D hdr->ident; - - switch (hdr->code) { - case A2MP_COMMAND_REJ: - a2mp_command_rej(mgr, skb, hdr); - break; - - case A2MP_DISCOVER_REQ: - err =3D a2mp_discover_req(mgr, skb, hdr); - break; - - case A2MP_CHANGE_NOTIFY: - err =3D a2mp_change_notify(mgr, skb, hdr); - break; - - case A2MP_GETINFO_REQ: - err =3D a2mp_getinfo_req(mgr, skb, hdr); - break; - - case A2MP_GETAMPASSOC_REQ: - err =3D a2mp_getampassoc_req(mgr, skb, hdr); - break; - - case A2MP_CREATEPHYSLINK_REQ: - err =3D a2mp_createphyslink_req(mgr, skb, hdr); - break; - - case A2MP_DISCONNPHYSLINK_REQ: - err =3D a2mp_discphyslink_req(mgr, skb, hdr); - break; - - case A2MP_DISCOVER_RSP: - err =3D a2mp_discover_rsp(mgr, skb, hdr); - break; - - case A2MP_GETINFO_RSP: - err =3D a2mp_getinfo_rsp(mgr, skb, hdr); - break; - - case A2MP_GETAMPASSOC_RSP: - err =3D a2mp_getampassoc_rsp(mgr, skb, hdr); - break; - - case A2MP_CHANGE_RSP: - case A2MP_CREATEPHYSLINK_RSP: - case A2MP_DISCONNPHYSLINK_RSP: - err =3D a2mp_cmd_rsp(mgr, skb, hdr); - break; - - default: - BT_ERR("Unknown A2MP sig cmd 0x%2.2x", hdr->code); - err =3D -EINVAL; - break; - } - } - - if (err) { - struct a2mp_cmd_rej rej; - - memset(&rej, 0, sizeof(rej)); - - rej.reason =3D cpu_to_le16(0); - hdr =3D (void *) skb->data; - - BT_DBG("Send A2MP Rej: cmd 0x%2.2x err %d", hdr->code, err); - - a2mp_send(mgr, A2MP_COMMAND_REJ, hdr->ident, sizeof(rej), - &rej); - } - - /* Always free skb and return success error code to prevent - from sending L2CAP Disconnect over A2MP channel */ - kfree_skb(skb); - - amp_mgr_put(mgr); - - return 0; -} - -static void a2mp_chan_close_cb(struct l2cap_chan *chan) -{ - l2cap_chan_put(chan); -} - -static void a2mp_chan_state_change_cb(struct l2cap_chan *chan, int state, - int err) -{ - struct amp_mgr *mgr =3D chan->data; - - if (!mgr) - return; - - BT_DBG("chan %p state %s", chan, state_to_string(state)); - - chan->state =3D state; - - switch (state) { - case BT_CLOSED: - if (mgr) - amp_mgr_put(mgr); - break; - } -} - -static struct sk_buff *a2mp_chan_alloc_skb_cb(struct l2cap_chan *chan, - unsigned long hdr_len, - unsigned long len, int nb) -{ - struct sk_buff *skb; - - skb =3D bt_skb_alloc(hdr_len + len, GFP_KERNEL); - if (!skb) - return ERR_PTR(-ENOMEM); - - return skb; -} - -static const struct l2cap_ops a2mp_chan_ops =3D { - .name =3D "L2CAP A2MP channel", - .recv =3D a2mp_chan_recv_cb, - .close =3D a2mp_chan_close_cb, - .state_change =3D a2mp_chan_state_change_cb, - .alloc_skb =3D a2mp_chan_alloc_skb_cb, - - /* Not implemented for A2MP */ - .new_connection =3D l2cap_chan_no_new_connection, - .teardown =3D l2cap_chan_no_teardown, - .ready =3D l2cap_chan_no_ready, - .defer =3D l2cap_chan_no_defer, - .resume =3D l2cap_chan_no_resume, - .set_shutdown =3D l2cap_chan_no_set_shutdown, - .get_sndtimeo =3D l2cap_chan_no_get_sndtimeo, -}; - -static struct l2cap_chan *a2mp_chan_open(struct l2cap_conn *conn, bool loc= ked) -{ - struct l2cap_chan *chan; - int err; - - chan =3D l2cap_chan_create(); - if (!chan) - return NULL; - - BT_DBG("chan %p", chan); - - chan->chan_type =3D L2CAP_CHAN_FIXED; - chan->scid =3D L2CAP_CID_A2MP; - chan->dcid =3D L2CAP_CID_A2MP; - chan->omtu =3D L2CAP_A2MP_DEFAULT_MTU; - chan->imtu =3D L2CAP_A2MP_DEFAULT_MTU; - chan->flush_to =3D L2CAP_DEFAULT_FLUSH_TO; - - chan->ops =3D &a2mp_chan_ops; - - l2cap_chan_set_defaults(chan); - chan->remote_max_tx =3D chan->max_tx; - chan->remote_tx_win =3D chan->tx_win; - - chan->retrans_timeout =3D L2CAP_DEFAULT_RETRANS_TO; - chan->monitor_timeout =3D L2CAP_DEFAULT_MONITOR_TO; - - skb_queue_head_init(&chan->tx_q); - - chan->mode =3D L2CAP_MODE_ERTM; - - err =3D l2cap_ertm_init(chan); - if (err < 0) { - l2cap_chan_del(chan, 0); - return NULL; - } - - chan->conf_state =3D 0; - - if (locked) - __l2cap_chan_add(conn, chan); - else - l2cap_chan_add(conn, chan); - - chan->remote_mps =3D chan->omtu; - chan->mps =3D chan->omtu; - - chan->state =3D BT_CONNECTED; - - return chan; -} - -/* AMP Manager functions */ -struct amp_mgr *amp_mgr_get(struct amp_mgr *mgr) -{ - BT_DBG("mgr %p orig refcnt %d", mgr, kref_read(&mgr->kref)); - - kref_get(&mgr->kref); - - return mgr; -} - -static void amp_mgr_destroy(struct kref *kref) -{ - struct amp_mgr *mgr =3D container_of(kref, struct amp_mgr, kref); - - BT_DBG("mgr %p", mgr); - - mutex_lock(&_mgr_list_lock); - list_del(&mgr->list); - mutex_unlock(&_mgr_list_lock); - - amp_ctrl_list_flush(mgr); - kfree(mgr); -} - -int amp_mgr_put(struct amp_mgr *mgr) -{ - BT_DBG("mgr %p orig refcnt %d", mgr, kref_read(&mgr->kref)); - - return kref_put(&mgr->kref, &_mgr_destroy); -} - -static struct amp_mgr *amp_mgr_create(struct l2cap_conn *conn, bool locked) -{ - struct amp_mgr *mgr; - struct l2cap_chan *chan; - - mgr =3D kzalloc(sizeof(*mgr), GFP_KERNEL); - if (!mgr) - return NULL; - - BT_DBG("conn %p mgr %p", conn, mgr); - - mgr->l2cap_conn =3D conn; - - chan =3D a2mp_chan_open(conn, locked); - if (!chan) { - kfree(mgr); - return NULL; - } - - mgr->a2mp_chan =3D chan; - chan->data =3D mgr; - - conn->hcon->amp_mgr =3D mgr; - - kref_init(&mgr->kref); - - /* Remote AMP ctrl list initialization */ - INIT_LIST_HEAD(&mgr->amp_ctrls); - mutex_init(&mgr->amp_ctrls_lock); - - mutex_lock(&_mgr_list_lock); - list_add(&mgr->list, &_mgr_list); - mutex_unlock(&_mgr_list_lock); - - return mgr; -} - -struct l2cap_chan *a2mp_channel_create(struct l2cap_conn *conn, - struct sk_buff *skb) -{ - struct amp_mgr *mgr; - - if (conn->hcon->type !=3D ACL_LINK) - return NULL; - - mgr =3D amp_mgr_create(conn, false); - if (!mgr) { - BT_ERR("Could not create AMP manager"); - return NULL; - } - - BT_DBG("mgr: %p chan %p", mgr, mgr->a2mp_chan); - - return mgr->a2mp_chan; -} - -void a2mp_send_getinfo_rsp(struct hci_dev *hdev) -{ - struct amp_mgr *mgr; - struct a2mp_info_rsp rsp; - - mgr =3D amp_mgr_lookup_by_state(READ_LOC_AMP_INFO); - if (!mgr) - return; - - BT_DBG("%s mgr %p", hdev->name, mgr); - - memset(&rsp, 0, sizeof(rsp)); - - rsp.id =3D hdev->id; - rsp.status =3D A2MP_STATUS_INVALID_CTRL_ID; - - if (hdev->amp_type !=3D AMP_TYPE_BREDR) { - rsp.status =3D 0; - rsp.total_bw =3D cpu_to_le32(hdev->amp_total_bw); - rsp.max_bw =3D cpu_to_le32(hdev->amp_max_bw); - rsp.min_latency =3D cpu_to_le32(hdev->amp_min_latency); - rsp.pal_cap =3D cpu_to_le16(hdev->amp_pal_cap); - rsp.assoc_size =3D cpu_to_le16(hdev->amp_assoc_size); - } - - a2mp_send(mgr, A2MP_GETINFO_RSP, mgr->ident, sizeof(rsp), &rsp); - amp_mgr_put(mgr); -} - -void a2mp_send_getampassoc_rsp(struct hci_dev *hdev, u8 status) -{ - struct amp_mgr *mgr; - struct amp_assoc *loc_assoc =3D &hdev->loc_assoc; - struct a2mp_amp_assoc_rsp *rsp; - size_t len; - - mgr =3D amp_mgr_lookup_by_state(READ_LOC_AMP_ASSOC); - if (!mgr) - return; - - BT_DBG("%s mgr %p", hdev->name, mgr); - - len =3D sizeof(struct a2mp_amp_assoc_rsp) + loc_assoc->len; - rsp =3D kzalloc(len, GFP_KERNEL); - if (!rsp) { - amp_mgr_put(mgr); - return; - } - - rsp->id =3D hdev->id; - - if (status) { - rsp->status =3D A2MP_STATUS_INVALID_CTRL_ID; - } else { - rsp->status =3D A2MP_STATUS_SUCCESS; - memcpy(rsp->amp_assoc, loc_assoc->data, loc_assoc->len); - } - - a2mp_send(mgr, A2MP_GETAMPASSOC_RSP, mgr->ident, len, rsp); - amp_mgr_put(mgr); - kfree(rsp); -} - -void a2mp_send_create_phy_link_req(struct hci_dev *hdev, u8 status) -{ - struct amp_mgr *mgr; - struct amp_assoc *loc_assoc =3D &hdev->loc_assoc; - struct a2mp_physlink_req *req; - struct l2cap_chan *bredr_chan; - size_t len; - - mgr =3D amp_mgr_lookup_by_state(READ_LOC_AMP_ASSOC_FINAL); - if (!mgr) - return; - - len =3D sizeof(*req) + loc_assoc->len; - - BT_DBG("%s mgr %p assoc_len %zu", hdev->name, mgr, len); - - req =3D kzalloc(len, GFP_KERNEL); - if (!req) { - amp_mgr_put(mgr); - return; - } - - bredr_chan =3D mgr->bredr_chan; - if (!bredr_chan) - goto clean; - - req->local_id =3D hdev->id; - req->remote_id =3D bredr_chan->remote_amp_id; - memcpy(req->amp_assoc, loc_assoc->data, loc_assoc->len); - - a2mp_send(mgr, A2MP_CREATEPHYSLINK_REQ, __next_ident(mgr), len, req); - -clean: - amp_mgr_put(mgr); - kfree(req); -} - -void a2mp_send_create_phy_link_rsp(struct hci_dev *hdev, u8 status) -{ - struct amp_mgr *mgr; - struct a2mp_physlink_rsp rsp; - struct hci_conn *hs_hcon; - - mgr =3D amp_mgr_lookup_by_state(WRITE_REMOTE_AMP_ASSOC); - if (!mgr) - return; - - memset(&rsp, 0, sizeof(rsp)); - - hs_hcon =3D hci_conn_hash_lookup_state(hdev, AMP_LINK, BT_CONNECT); - if (!hs_hcon) { - rsp.status =3D A2MP_STATUS_UNABLE_START_LINK_CREATION; - } else { - rsp.remote_id =3D hs_hcon->remote_id; - rsp.status =3D A2MP_STATUS_SUCCESS; - } - - BT_DBG("%s mgr %p hs_hcon %p status %u", hdev->name, mgr, hs_hcon, - status); - - rsp.local_id =3D hdev->id; - a2mp_send(mgr, A2MP_CREATEPHYSLINK_RSP, mgr->ident, sizeof(rsp), &rsp); - amp_mgr_put(mgr); -} - -void a2mp_discover_amp(struct l2cap_chan *chan) -{ - struct l2cap_conn *conn =3D chan->conn; - struct amp_mgr *mgr =3D conn->hcon->amp_mgr; - struct a2mp_discov_req req; - - BT_DBG("chan %p conn %p mgr %p", chan, conn, mgr); - - if (!mgr) { - mgr =3D amp_mgr_create(conn, true); - if (!mgr) - return; - } - - mgr->bredr_chan =3D chan; - - memset(&req, 0, sizeof(req)); - - req.mtu =3D cpu_to_le16(L2CAP_A2MP_DEFAULT_MTU); - req.ext_feat =3D 0; - a2mp_send(mgr, A2MP_DISCOVER_REQ, 1, sizeof(req), &req); -} diff --git a/net/bluetooth/a2mp.h b/net/bluetooth/a2mp.h deleted file mode 100644 index 2fd253a61a2a1..0000000000000 --- a/net/bluetooth/a2mp.h +++ /dev/null @@ -1,154 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -/* - Copyright (c) 2010,2011 Code Aurora Forum. All rights reserved. - Copyright (c) 2011,2012 Intel Corp. - -*/ - -#ifndef __A2MP_H -#define __A2MP_H - -#include - -enum amp_mgr_state { - READ_LOC_AMP_INFO, - READ_LOC_AMP_ASSOC, - READ_LOC_AMP_ASSOC_FINAL, - WRITE_REMOTE_AMP_ASSOC, -}; - -struct amp_mgr { - struct list_head list; - struct l2cap_conn *l2cap_conn; - struct l2cap_chan *a2mp_chan; - struct l2cap_chan *bredr_chan; - struct kref kref; - __u8 ident; - __u8 handle; - unsigned long state; - unsigned long flags; - - struct list_head amp_ctrls; - struct mutex amp_ctrls_lock; -}; - -struct a2mp_cmd { - __u8 code; - __u8 ident; - __le16 len; - __u8 data[]; -} __packed; - -/* A2MP command codes */ -#define A2MP_COMMAND_REJ 0x01 -struct a2mp_cmd_rej { - __le16 reason; - __u8 data[]; -} __packed; - -#define A2MP_DISCOVER_REQ 0x02 -struct a2mp_discov_req { - __le16 mtu; - __le16 ext_feat; -} __packed; - -struct a2mp_cl { - __u8 id; - __u8 type; - __u8 status; -} __packed; - -#define A2MP_DISCOVER_RSP 0x03 -struct a2mp_discov_rsp { - __le16 mtu; - __le16 ext_feat; - struct a2mp_cl cl[]; -} __packed; - -#define A2MP_CHANGE_NOTIFY 0x04 -#define A2MP_CHANGE_RSP 0x05 - -#define A2MP_GETINFO_REQ 0x06 -struct a2mp_info_req { - __u8 id; -} __packed; - -#define A2MP_GETINFO_RSP 0x07 -struct a2mp_info_rsp { - __u8 id; - __u8 status; - __le32 total_bw; - __le32 max_bw; - __le32 min_latency; - __le16 pal_cap; - __le16 assoc_size; -} __packed; - -#define A2MP_GETAMPASSOC_REQ 0x08 -struct a2mp_amp_assoc_req { - __u8 id; -} __packed; - -#define A2MP_GETAMPASSOC_RSP 0x09 -struct a2mp_amp_assoc_rsp { - __u8 id; - __u8 status; - __u8 amp_assoc[]; -} __packed; - -#define A2MP_CREATEPHYSLINK_REQ 0x0A -#define A2MP_DISCONNPHYSLINK_REQ 0x0C -struct a2mp_physlink_req { - __u8 local_id; - __u8 remote_id; - __u8 amp_assoc[]; -} __packed; - -#define A2MP_CREATEPHYSLINK_RSP 0x0B -#define A2MP_DISCONNPHYSLINK_RSP 0x0D -struct a2mp_physlink_rsp { - __u8 local_id; - __u8 remote_id; - __u8 status; -} __packed; - -/* A2MP response status */ -#define A2MP_STATUS_SUCCESS 0x00 -#define A2MP_STATUS_INVALID_CTRL_ID 0x01 -#define A2MP_STATUS_UNABLE_START_LINK_CREATION 0x02 -#define A2MP_STATUS_NO_PHYSICAL_LINK_EXISTS 0x02 -#define A2MP_STATUS_COLLISION_OCCURED 0x03 -#define A2MP_STATUS_DISCONN_REQ_RECVD 0x04 -#define A2MP_STATUS_PHYS_LINK_EXISTS 0x05 -#define A2MP_STATUS_SECURITY_VIOLATION 0x06 - -struct amp_mgr *amp_mgr_get(struct amp_mgr *mgr); - -#if IS_ENABLED(CONFIG_BT_HS) -int amp_mgr_put(struct amp_mgr *mgr); -struct l2cap_chan *a2mp_channel_create(struct l2cap_conn *conn, - struct sk_buff *skb); -void a2mp_discover_amp(struct l2cap_chan *chan); -#else -static inline int amp_mgr_put(struct amp_mgr *mgr) -{ - return 0; -} - -static inline struct l2cap_chan *a2mp_channel_create(struct l2cap_conn *co= nn, - struct sk_buff *skb) -{ - return NULL; -} - -static inline void a2mp_discover_amp(struct l2cap_chan *chan) -{ -} -#endif - -void a2mp_send_getinfo_rsp(struct hci_dev *hdev); -void a2mp_send_getampassoc_rsp(struct hci_dev *hdev, u8 status); -void a2mp_send_create_phy_link_req(struct hci_dev *hdev, u8 status); -void a2mp_send_create_phy_link_rsp(struct hci_dev *hdev, u8 status); - -#endif /* __A2MP_H */ diff --git a/net/bluetooth/amp.c b/net/bluetooth/amp.c deleted file mode 100644 index 5d698f19868c5..0000000000000 --- a/net/bluetooth/amp.c +++ /dev/null @@ -1,590 +0,0 @@ -// SPDX-License-Identifier: GPL-2.0-only -/* - Copyright (c) 2011,2012 Intel Corp. - -*/ - -#include -#include -#include -#include - -#include "hci_request.h" -#include "a2mp.h" -#include "amp.h" - -/* Remote AMP Controllers interface */ -void amp_ctrl_get(struct amp_ctrl *ctrl) -{ - BT_DBG("ctrl %p orig refcnt %d", ctrl, - kref_read(&ctrl->kref)); - - kref_get(&ctrl->kref); -} - -static void amp_ctrl_destroy(struct kref *kref) -{ - struct amp_ctrl *ctrl =3D container_of(kref, struct amp_ctrl, kref); - - BT_DBG("ctrl %p", ctrl); - - kfree(ctrl->assoc); - kfree(ctrl); -} - -int amp_ctrl_put(struct amp_ctrl *ctrl) -{ - BT_DBG("ctrl %p orig refcnt %d", ctrl, - kref_read(&ctrl->kref)); - - return kref_put(&ctrl->kref, &_ctrl_destroy); -} - -struct amp_ctrl *amp_ctrl_add(struct amp_mgr *mgr, u8 id) -{ - struct amp_ctrl *ctrl; - - ctrl =3D kzalloc(sizeof(*ctrl), GFP_KERNEL); - if (!ctrl) - return NULL; - - kref_init(&ctrl->kref); - ctrl->id =3D id; - - mutex_lock(&mgr->amp_ctrls_lock); - list_add(&ctrl->list, &mgr->amp_ctrls); - mutex_unlock(&mgr->amp_ctrls_lock); - - BT_DBG("mgr %p ctrl %p", mgr, ctrl); - - return ctrl; -} - -void amp_ctrl_list_flush(struct amp_mgr *mgr) -{ - struct amp_ctrl *ctrl, *n; - - BT_DBG("mgr %p", mgr); - - mutex_lock(&mgr->amp_ctrls_lock); - list_for_each_entry_safe(ctrl, n, &mgr->amp_ctrls, list) { - list_del(&ctrl->list); - amp_ctrl_put(ctrl); - } - mutex_unlock(&mgr->amp_ctrls_lock); -} - -struct amp_ctrl *amp_ctrl_lookup(struct amp_mgr *mgr, u8 id) -{ - struct amp_ctrl *ctrl; - - BT_DBG("mgr %p id %u", mgr, id); - - mutex_lock(&mgr->amp_ctrls_lock); - list_for_each_entry(ctrl, &mgr->amp_ctrls, list) { - if (ctrl->id =3D=3D id) { - amp_ctrl_get(ctrl); - mutex_unlock(&mgr->amp_ctrls_lock); - return ctrl; - } - } - mutex_unlock(&mgr->amp_ctrls_lock); - - return NULL; -} - -/* Physical Link interface */ -static u8 __next_handle(struct amp_mgr *mgr) -{ - if (++mgr->handle =3D=3D 0) - mgr->handle =3D 1; - - return mgr->handle; -} - -struct hci_conn *phylink_add(struct hci_dev *hdev, struct amp_mgr *mgr, - u8 remote_id, bool out) -{ - bdaddr_t *dst =3D &mgr->l2cap_conn->hcon->dst; - struct hci_conn *hcon; - u8 role =3D out ? HCI_ROLE_MASTER : HCI_ROLE_SLAVE; - - hcon =3D hci_conn_add(hdev, AMP_LINK, dst, role, __next_handle(mgr)); - if (!hcon) - return NULL; - - BT_DBG("hcon %p dst %pMR", hcon, dst); - - hcon->state =3D BT_CONNECT; - hcon->attempt++; - hcon->remote_id =3D remote_id; - hcon->amp_mgr =3D amp_mgr_get(mgr); - - return hcon; -} - -/* AMP crypto key generation interface */ -static int hmac_sha256(u8 *key, u8 ksize, char *plaintext, u8 psize, u8 *o= utput) -{ - struct crypto_shash *tfm; - struct shash_desc *shash; - int ret; - - if (!ksize) - return -EINVAL; - - tfm =3D crypto_alloc_shash("hmac(sha256)", 0, 0); - if (IS_ERR(tfm)) { - BT_DBG("crypto_alloc_ahash failed: err %ld", PTR_ERR(tfm)); - return PTR_ERR(tfm); - } - - ret =3D crypto_shash_setkey(tfm, key, ksize); - if (ret) { - BT_DBG("crypto_ahash_setkey failed: err %d", ret); - goto failed; - } - - shash =3D kzalloc(sizeof(*shash) + crypto_shash_descsize(tfm), - GFP_KERNEL); - if (!shash) { - ret =3D -ENOMEM; - goto failed; - } - - shash->tfm =3D tfm; - - ret =3D crypto_shash_digest(shash, plaintext, psize, output); - - kfree(shash); - -failed: - crypto_free_shash(tfm); - return ret; -} - -int phylink_gen_key(struct hci_conn *conn, u8 *data, u8 *len, u8 *type) -{ - struct hci_dev *hdev =3D conn->hdev; - struct link_key *key; - u8 keybuf[HCI_AMP_LINK_KEY_SIZE]; - u8 gamp_key[HCI_AMP_LINK_KEY_SIZE]; - int err; - - if (!hci_conn_check_link_mode(conn)) - return -EACCES; - - BT_DBG("conn %p key_type %d", conn, conn->key_type); - - /* Legacy key */ - if (conn->key_type < 3) { - bt_dev_err(hdev, "legacy key type %u", conn->key_type); - return -EACCES; - } - - *type =3D conn->key_type; - *len =3D HCI_AMP_LINK_KEY_SIZE; - - key =3D hci_find_link_key(hdev, &conn->dst); - if (!key) { - BT_DBG("No Link key for conn %p dst %pMR", conn, &conn->dst); - return -EACCES; - } - - /* BR/EDR Link Key concatenated together with itself */ - memcpy(&keybuf[0], key->val, HCI_LINK_KEY_SIZE); - memcpy(&keybuf[HCI_LINK_KEY_SIZE], key->val, HCI_LINK_KEY_SIZE); - - /* Derive Generic AMP Link Key (gamp) */ - err =3D hmac_sha256(keybuf, HCI_AMP_LINK_KEY_SIZE, "gamp", 4, gamp_key); - if (err) { - bt_dev_err(hdev, "could not derive Generic AMP Key: err %d", err); - return err; - } - - if (conn->key_type =3D=3D HCI_LK_DEBUG_COMBINATION) { - BT_DBG("Use Generic AMP Key (gamp)"); - memcpy(data, gamp_key, HCI_AMP_LINK_KEY_SIZE); - return err; - } - - /* Derive Dedicated AMP Link Key: "802b" is 802.11 PAL keyID */ - return hmac_sha256(gamp_key, HCI_AMP_LINK_KEY_SIZE, "802b", 4, data); -} - -static void read_local_amp_assoc_complete(struct hci_dev *hdev, u8 status, - u16 opcode, struct sk_buff *skb) -{ - struct hci_rp_read_local_amp_assoc *rp =3D (void *)skb->data; - struct amp_assoc *assoc =3D &hdev->loc_assoc; - size_t rem_len, frag_len; - - BT_DBG("%s status 0x%2.2x", hdev->name, rp->status); - - if (rp->status) - goto send_rsp; - - frag_len =3D skb->len - sizeof(*rp); - rem_len =3D __le16_to_cpu(rp->rem_len); - - if (rem_len > frag_len) { - BT_DBG("frag_len %zu rem_len %zu", frag_len, rem_len); - - memcpy(assoc->data + assoc->offset, rp->frag, frag_len); - assoc->offset +=3D frag_len; - - /* Read other fragments */ - amp_read_loc_assoc_frag(hdev, rp->phy_handle); - - return; - } - - memcpy(assoc->data + assoc->offset, rp->frag, rem_len); - assoc->len =3D assoc->offset + rem_len; - assoc->offset =3D 0; - -send_rsp: - /* Send A2MP Rsp when all fragments are received */ - a2mp_send_getampassoc_rsp(hdev, rp->status); - a2mp_send_create_phy_link_req(hdev, rp->status); -} - -void amp_read_loc_assoc_frag(struct hci_dev *hdev, u8 phy_handle) -{ - struct hci_cp_read_local_amp_assoc cp; - struct amp_assoc *loc_assoc =3D &hdev->loc_assoc; - struct hci_request req; - int err; - - BT_DBG("%s handle %u", hdev->name, phy_handle); - - cp.phy_handle =3D phy_handle; - cp.max_len =3D cpu_to_le16(hdev->amp_assoc_size); - cp.len_so_far =3D cpu_to_le16(loc_assoc->offset); - - hci_req_init(&req, hdev); - hci_req_add(&req, HCI_OP_READ_LOCAL_AMP_ASSOC, sizeof(cp), &cp); - err =3D hci_req_run_skb(&req, read_local_amp_assoc_complete); - if (err < 0) - a2mp_send_getampassoc_rsp(hdev, A2MP_STATUS_INVALID_CTRL_ID); -} - -void amp_read_loc_assoc(struct hci_dev *hdev, struct amp_mgr *mgr) -{ - struct hci_cp_read_local_amp_assoc cp; - struct hci_request req; - int err; - - memset(&hdev->loc_assoc, 0, sizeof(struct amp_assoc)); - memset(&cp, 0, sizeof(cp)); - - cp.max_len =3D cpu_to_le16(hdev->amp_assoc_size); - - set_bit(READ_LOC_AMP_ASSOC, &mgr->state); - hci_req_init(&req, hdev); - hci_req_add(&req, HCI_OP_READ_LOCAL_AMP_ASSOC, sizeof(cp), &cp); - err =3D hci_req_run_skb(&req, read_local_amp_assoc_complete); - if (err < 0) - a2mp_send_getampassoc_rsp(hdev, A2MP_STATUS_INVALID_CTRL_ID); -} - -void amp_read_loc_assoc_final_data(struct hci_dev *hdev, - struct hci_conn *hcon) -{ - struct hci_cp_read_local_amp_assoc cp; - struct amp_mgr *mgr =3D hcon->amp_mgr; - struct hci_request req; - int err; - - if (!mgr) - return; - - cp.phy_handle =3D hcon->handle; - cp.len_so_far =3D cpu_to_le16(0); - cp.max_len =3D cpu_to_le16(hdev->amp_assoc_size); - - set_bit(READ_LOC_AMP_ASSOC_FINAL, &mgr->state); - - /* Read Local AMP Assoc final link information data */ - hci_req_init(&req, hdev); - hci_req_add(&req, HCI_OP_READ_LOCAL_AMP_ASSOC, sizeof(cp), &cp); - err =3D hci_req_run_skb(&req, read_local_amp_assoc_complete); - if (err < 0) - a2mp_send_getampassoc_rsp(hdev, A2MP_STATUS_INVALID_CTRL_ID); -} - -static void write_remote_amp_assoc_complete(struct hci_dev *hdev, u8 statu= s, - u16 opcode, struct sk_buff *skb) -{ - struct hci_rp_write_remote_amp_assoc *rp =3D (void *)skb->data; - - BT_DBG("%s status 0x%2.2x phy_handle 0x%2.2x", - hdev->name, rp->status, rp->phy_handle); - - if (rp->status) - return; - - amp_write_rem_assoc_continue(hdev, rp->phy_handle); -} - -/* Write AMP Assoc data fragments, returns true with last fragment written= */ -static bool amp_write_rem_assoc_frag(struct hci_dev *hdev, - struct hci_conn *hcon) -{ - struct hci_cp_write_remote_amp_assoc *cp; - struct amp_mgr *mgr =3D hcon->amp_mgr; - struct amp_ctrl *ctrl; - struct hci_request req; - u16 frag_len, len; - - ctrl =3D amp_ctrl_lookup(mgr, hcon->remote_id); - if (!ctrl) - return false; - - if (!ctrl->assoc_rem_len) { - BT_DBG("all fragments are written"); - ctrl->assoc_rem_len =3D ctrl->assoc_len; - ctrl->assoc_len_so_far =3D 0; - - amp_ctrl_put(ctrl); - return true; - } - - frag_len =3D min_t(u16, 248, ctrl->assoc_rem_len); - len =3D frag_len + sizeof(*cp); - - cp =3D kzalloc(len, GFP_KERNEL); - if (!cp) { - amp_ctrl_put(ctrl); - return false; - } - - BT_DBG("hcon %p ctrl %p frag_len %u assoc_len %u rem_len %u", - hcon, ctrl, frag_len, ctrl->assoc_len, ctrl->assoc_rem_len); - - cp->phy_handle =3D hcon->handle; - cp->len_so_far =3D cpu_to_le16(ctrl->assoc_len_so_far); - cp->rem_len =3D cpu_to_le16(ctrl->assoc_rem_len); - memcpy(cp->frag, ctrl->assoc, frag_len); - - ctrl->assoc_len_so_far +=3D frag_len; - ctrl->assoc_rem_len -=3D frag_len; - - amp_ctrl_put(ctrl); - - hci_req_init(&req, hdev); - hci_req_add(&req, HCI_OP_WRITE_REMOTE_AMP_ASSOC, len, cp); - hci_req_run_skb(&req, write_remote_amp_assoc_complete); - - kfree(cp); - - return false; -} - -void amp_write_rem_assoc_continue(struct hci_dev *hdev, u8 handle) -{ - struct hci_conn *hcon; - - BT_DBG("%s phy handle 0x%2.2x", hdev->name, handle); - - hcon =3D hci_conn_hash_lookup_handle(hdev, handle); - if (!hcon) - return; - - /* Send A2MP create phylink rsp when all fragments are written */ - if (amp_write_rem_assoc_frag(hdev, hcon)) - a2mp_send_create_phy_link_rsp(hdev, 0); -} - -void amp_write_remote_assoc(struct hci_dev *hdev, u8 handle) -{ - struct hci_conn *hcon; - - BT_DBG("%s phy handle 0x%2.2x", hdev->name, handle); - - hcon =3D hci_conn_hash_lookup_handle(hdev, handle); - if (!hcon) - return; - - BT_DBG("%s phy handle 0x%2.2x hcon %p", hdev->name, handle, hcon); - - amp_write_rem_assoc_frag(hdev, hcon); -} - -static void create_phylink_complete(struct hci_dev *hdev, u8 status, - u16 opcode) -{ - struct hci_cp_create_phy_link *cp; - - BT_DBG("%s status 0x%2.2x", hdev->name, status); - - cp =3D hci_sent_cmd_data(hdev, HCI_OP_CREATE_PHY_LINK); - if (!cp) - return; - - hci_dev_lock(hdev); - - if (status) { - struct hci_conn *hcon; - - hcon =3D hci_conn_hash_lookup_handle(hdev, cp->phy_handle); - if (hcon) - hci_conn_del(hcon); - } else { - amp_write_remote_assoc(hdev, cp->phy_handle); - } - - hci_dev_unlock(hdev); -} - -void amp_create_phylink(struct hci_dev *hdev, struct amp_mgr *mgr, - struct hci_conn *hcon) -{ - struct hci_cp_create_phy_link cp; - struct hci_request req; - - cp.phy_handle =3D hcon->handle; - - BT_DBG("%s hcon %p phy handle 0x%2.2x", hdev->name, hcon, - hcon->handle); - - if (phylink_gen_key(mgr->l2cap_conn->hcon, cp.key, &cp.key_len, - &cp.key_type)) { - BT_DBG("Cannot create link key"); - return; - } - - hci_req_init(&req, hdev); - hci_req_add(&req, HCI_OP_CREATE_PHY_LINK, sizeof(cp), &cp); - hci_req_run(&req, create_phylink_complete); -} - -static void accept_phylink_complete(struct hci_dev *hdev, u8 status, - u16 opcode) -{ - struct hci_cp_accept_phy_link *cp; - - BT_DBG("%s status 0x%2.2x", hdev->name, status); - - if (status) - return; - - cp =3D hci_sent_cmd_data(hdev, HCI_OP_ACCEPT_PHY_LINK); - if (!cp) - return; - - amp_write_remote_assoc(hdev, cp->phy_handle); -} - -void amp_accept_phylink(struct hci_dev *hdev, struct amp_mgr *mgr, - struct hci_conn *hcon) -{ - struct hci_cp_accept_phy_link cp; - struct hci_request req; - - cp.phy_handle =3D hcon->handle; - - BT_DBG("%s hcon %p phy handle 0x%2.2x", hdev->name, hcon, - hcon->handle); - - if (phylink_gen_key(mgr->l2cap_conn->hcon, cp.key, &cp.key_len, - &cp.key_type)) { - BT_DBG("Cannot create link key"); - return; - } - - hci_req_init(&req, hdev); - hci_req_add(&req, HCI_OP_ACCEPT_PHY_LINK, sizeof(cp), &cp); - hci_req_run(&req, accept_phylink_complete); -} - -void amp_physical_cfm(struct hci_conn *bredr_hcon, struct hci_conn *hs_hco= n) -{ - struct hci_dev *bredr_hdev =3D hci_dev_hold(bredr_hcon->hdev); - struct amp_mgr *mgr =3D hs_hcon->amp_mgr; - struct l2cap_chan *bredr_chan; - - BT_DBG("bredr_hcon %p hs_hcon %p mgr %p", bredr_hcon, hs_hcon, mgr); - - if (!bredr_hdev || !mgr || !mgr->bredr_chan) - return; - - bredr_chan =3D mgr->bredr_chan; - - l2cap_chan_lock(bredr_chan); - - set_bit(FLAG_EFS_ENABLE, &bredr_chan->flags); - bredr_chan->remote_amp_id =3D hs_hcon->remote_id; - bredr_chan->local_amp_id =3D hs_hcon->hdev->id; - bredr_chan->hs_hcon =3D hs_hcon; - bredr_chan->conn->mtu =3D hs_hcon->hdev->block_mtu; - - __l2cap_physical_cfm(bredr_chan, 0); - - l2cap_chan_unlock(bredr_chan); - - hci_dev_put(bredr_hdev); -} - -void amp_create_logical_link(struct l2cap_chan *chan) -{ - struct hci_conn *hs_hcon =3D chan->hs_hcon; - struct hci_cp_create_accept_logical_link cp; - struct hci_dev *hdev; - - BT_DBG("chan %p hs_hcon %p dst %pMR", chan, hs_hcon, - &chan->conn->hcon->dst); - - if (!hs_hcon) - return; - - hdev =3D hci_dev_hold(chan->hs_hcon->hdev); - if (!hdev) - return; - - cp.phy_handle =3D hs_hcon->handle; - - cp.tx_flow_spec.id =3D chan->local_id; - cp.tx_flow_spec.stype =3D chan->local_stype; - cp.tx_flow_spec.msdu =3D cpu_to_le16(chan->local_msdu); - cp.tx_flow_spec.sdu_itime =3D cpu_to_le32(chan->local_sdu_itime); - cp.tx_flow_spec.acc_lat =3D cpu_to_le32(chan->local_acc_lat); - cp.tx_flow_spec.flush_to =3D cpu_to_le32(chan->local_flush_to); - - cp.rx_flow_spec.id =3D chan->remote_id; - cp.rx_flow_spec.stype =3D chan->remote_stype; - cp.rx_flow_spec.msdu =3D cpu_to_le16(chan->remote_msdu); - cp.rx_flow_spec.sdu_itime =3D cpu_to_le32(chan->remote_sdu_itime); - cp.rx_flow_spec.acc_lat =3D cpu_to_le32(chan->remote_acc_lat); - cp.rx_flow_spec.flush_to =3D cpu_to_le32(chan->remote_flush_to); - - if (hs_hcon->out) - hci_send_cmd(hdev, HCI_OP_CREATE_LOGICAL_LINK, sizeof(cp), - &cp); - else - hci_send_cmd(hdev, HCI_OP_ACCEPT_LOGICAL_LINK, sizeof(cp), - &cp); - - hci_dev_put(hdev); -} - -void amp_disconnect_logical_link(struct hci_chan *hchan) -{ - struct hci_conn *hcon =3D hchan->conn; - struct hci_cp_disconn_logical_link cp; - - if (hcon->state !=3D BT_CONNECTED) { - BT_DBG("hchan %p not connected", hchan); - return; - } - - cp.log_handle =3D cpu_to_le16(hchan->handle); - hci_send_cmd(hcon->hdev, HCI_OP_DISCONN_LOGICAL_LINK, sizeof(cp), &cp); -} - -void amp_destroy_logical_link(struct hci_chan *hchan, u8 reason) -{ - BT_DBG("hchan %p", hchan); - - hci_chan_del(hchan); -} diff --git a/net/bluetooth/amp.h b/net/bluetooth/amp.h deleted file mode 100644 index 97c87abd129f6..0000000000000 --- a/net/bluetooth/amp.h +++ /dev/null @@ -1,60 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0-only */ -/* - Copyright (c) 2011,2012 Intel Corp. - -*/ - -#ifndef __AMP_H -#define __AMP_H - -struct amp_ctrl { - struct list_head list; - struct kref kref; - __u8 id; - __u16 assoc_len_so_far; - __u16 assoc_rem_len; - __u16 assoc_len; - __u8 *assoc; -}; - -int amp_ctrl_put(struct amp_ctrl *ctrl); -void amp_ctrl_get(struct amp_ctrl *ctrl); -struct amp_ctrl *amp_ctrl_add(struct amp_mgr *mgr, u8 id); -struct amp_ctrl *amp_ctrl_lookup(struct amp_mgr *mgr, u8 id); -void amp_ctrl_list_flush(struct amp_mgr *mgr); - -struct hci_conn *phylink_add(struct hci_dev *hdev, struct amp_mgr *mgr, - u8 remote_id, bool out); - -int phylink_gen_key(struct hci_conn *hcon, u8 *data, u8 *len, u8 *type); - -void amp_read_loc_assoc_frag(struct hci_dev *hdev, u8 phy_handle); -void amp_read_loc_assoc(struct hci_dev *hdev, struct amp_mgr *mgr); -void amp_read_loc_assoc_final_data(struct hci_dev *hdev, - struct hci_conn *hcon); -void amp_create_phylink(struct hci_dev *hdev, struct amp_mgr *mgr, - struct hci_conn *hcon); -void amp_accept_phylink(struct hci_dev *hdev, struct amp_mgr *mgr, - struct hci_conn *hcon); - -#if IS_ENABLED(CONFIG_BT_HS) -void amp_create_logical_link(struct l2cap_chan *chan); -void amp_disconnect_logical_link(struct hci_chan *hchan); -#else -static inline void amp_create_logical_link(struct l2cap_chan *chan) -{ -} - -static inline void amp_disconnect_logical_link(struct hci_chan *hchan) -{ -} -#endif - -void amp_write_remote_assoc(struct hci_dev *hdev, u8 handle); -void amp_write_rem_assoc_continue(struct hci_dev *hdev, u8 handle); -void amp_physical_cfm(struct hci_conn *bredr_hcon, struct hci_conn *hs_hco= n); -void amp_create_logical_link(struct l2cap_chan *chan); -void amp_disconnect_logical_link(struct hci_chan *hchan); -void amp_destroy_logical_link(struct hci_chan *hchan, u8 reason); - -#endif /* __AMP_H */ diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index a41d2693f4d8c..fc4d72f83ac25 100644 --- a/net/bluetooth/hci_conn.c +++ b/net/bluetooth/hci_conn.c @@ -36,7 +36,6 @@ =20 #include "hci_request.h" #include "smp.h" -#include "a2mp.h" #include "eir.h" =20 struct sco_param { @@ -1175,9 +1174,6 @@ void hci_conn_del(struct hci_conn *conn) } } =20 - if (conn->amp_mgr) - amp_mgr_put(conn->amp_mgr); - skb_queue_purge(&conn->data_q); =20 /* Remove the connection from the list and cleanup its remaining diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index 1f63f77661dce..55daada8dc15d 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -36,8 +36,6 @@ #include "hci_request.h" #include "hci_debugfs.h" #include "hci_codec.h" -#include "a2mp.h" -#include "amp.h" #include "smp.h" #include "msft.h" #include "eir.h" diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c index 656f49b299d20..ab5a9d42fae71 100644 --- a/net/bluetooth/l2cap_core.c +++ b/net/bluetooth/l2cap_core.c @@ -39,8 +39,6 @@ #include =20 #include "smp.h" -#include "a2mp.h" -#include "amp.h" =20 #define LE_FLOWCTL_MAX_CREDITS 65535 =20 @@ -167,24 +165,6 @@ static struct l2cap_chan *__l2cap_get_chan_by_ident(st= ruct l2cap_conn *conn, return NULL; } =20 -static struct l2cap_chan *l2cap_get_chan_by_ident(struct l2cap_conn *conn, - u8 ident) -{ - struct l2cap_chan *c; - - mutex_lock(&conn->chan_lock); - c =3D __l2cap_get_chan_by_ident(conn, ident); - if (c) { - /* Only lock if chan reference is not 0 */ - c =3D l2cap_chan_hold_unless_zero(c); - if (c) - l2cap_chan_lock(c); - } - mutex_unlock(&conn->chan_lock); - - return c; -} - static struct l2cap_chan *__l2cap_global_chan_by_addr(__le16 psm, bdaddr_t= *src, u8 src_type) { @@ -651,7 +631,6 @@ void l2cap_chan_del(struct l2cap_chan *chan, int err) chan->ops->teardown(chan, err); =20 if (conn) { - struct amp_mgr *mgr =3D conn->hcon->amp_mgr; /* Delete from channel list */ list_del(&chan->list); =20 @@ -666,16 +645,6 @@ void l2cap_chan_del(struct l2cap_chan *chan, int err) if (chan->chan_type !=3D L2CAP_CHAN_FIXED || test_bit(FLAG_HOLD_HCI_CONN, &chan->flags)) hci_conn_drop(conn->hcon); - - if (mgr && mgr->bredr_chan =3D=3D chan) - mgr->bredr_chan =3D NULL; - } - - if (chan->hs_hchan) { - struct hci_chan *hs_hchan =3D chan->hs_hchan; - - BT_DBG("chan %p disconnect hs_hchan %p", chan, hs_hchan); - amp_disconnect_logical_link(hs_hchan); } =20 if (test_bit(CONF_NOT_COMPLETE, &chan->conf_state)) @@ -977,12 +946,6 @@ static void l2cap_send_cmd(struct l2cap_conn *conn, u8= ident, u8 code, u16 len, hci_send_acl(conn->hchan, skb, flags); } =20 -static bool __chan_is_moving(struct l2cap_chan *chan) -{ - return chan->move_state !=3D L2CAP_MOVE_STABLE && - chan->move_state !=3D L2CAP_MOVE_WAIT_PREPARE; -} - static void l2cap_do_send(struct l2cap_chan *chan, struct sk_buff *skb) { struct hci_conn *hcon =3D chan->conn->hcon; @@ -991,15 +954,6 @@ static void l2cap_do_send(struct l2cap_chan *chan, str= uct sk_buff *skb) BT_DBG("chan %p, skb %p len %d priority %u", chan, skb, skb->len, skb->priority); =20 - if (chan->hs_hcon && !__chan_is_moving(chan)) { - if (chan->hs_hchan) - hci_send_acl(chan->hs_hchan, skb, ACL_COMPLETE); - else - kfree_skb(skb); - - return; - } - /* Use NO_FLUSH for LE links (where this is the only option) or * if the BR/EDR link supports it and flushing has not been * explicitly requested (through FLAG_FLUSHABLE). @@ -1180,9 +1134,6 @@ static void l2cap_send_sframe(struct l2cap_chan *chan, if (!control->sframe) return; =20 - if (__chan_is_moving(chan)) - return; - if (test_and_clear_bit(CONN_SEND_FBIT, &chan->conn_state) && !control->poll) control->final =3D 1; @@ -1237,40 +1188,6 @@ static inline int __l2cap_no_conn_pending(struct l2c= ap_chan *chan) return !test_bit(CONF_CONNECT_PEND, &chan->conf_state); } =20 -static bool __amp_capable(struct l2cap_chan *chan) -{ - struct l2cap_conn *conn =3D chan->conn; - struct hci_dev *hdev; - bool amp_available =3D false; - - if (!(conn->local_fixed_chan & L2CAP_FC_A2MP)) - return false; - - if (!(conn->remote_fixed_chan & L2CAP_FC_A2MP)) - return false; - - read_lock(&hci_dev_list_lock); - list_for_each_entry(hdev, &hci_dev_list, list) { - if (hdev->amp_type !=3D AMP_TYPE_BREDR && - test_bit(HCI_UP, &hdev->flags)) { - amp_available =3D true; - break; - } - } - read_unlock(&hci_dev_list_lock); - - if (chan->chan_policy =3D=3D BT_CHANNEL_POLICY_AMP_PREFERRED) - return amp_available; - - return false; -} - -static bool l2cap_check_efs(struct l2cap_chan *chan) -{ - /* Check EFS parameters */ - return true; -} - void l2cap_send_conn_req(struct l2cap_chan *chan) { struct l2cap_conn *conn =3D chan->conn; @@ -1286,76 +1203,6 @@ void l2cap_send_conn_req(struct l2cap_chan *chan) l2cap_send_cmd(conn, chan->ident, L2CAP_CONN_REQ, sizeof(req), &req); } =20 -static void l2cap_send_create_chan_req(struct l2cap_chan *chan, u8 amp_id) -{ - struct l2cap_create_chan_req req; - req.scid =3D cpu_to_le16(chan->scid); - req.psm =3D chan->psm; - req.amp_id =3D amp_id; - - chan->ident =3D l2cap_get_ident(chan->conn); - - l2cap_send_cmd(chan->conn, chan->ident, L2CAP_CREATE_CHAN_REQ, - sizeof(req), &req); -} - -static void l2cap_move_setup(struct l2cap_chan *chan) -{ - struct sk_buff *skb; - - BT_DBG("chan %p", chan); - - if (chan->mode !=3D L2CAP_MODE_ERTM) - return; - - __clear_retrans_timer(chan); - __clear_monitor_timer(chan); - __clear_ack_timer(chan); - - chan->retry_count =3D 0; - skb_queue_walk(&chan->tx_q, skb) { - if (bt_cb(skb)->l2cap.retries) - bt_cb(skb)->l2cap.retries =3D 1; - else - break; - } - - chan->expected_tx_seq =3D chan->buffer_seq; - - clear_bit(CONN_REJ_ACT, &chan->conn_state); - clear_bit(CONN_SREJ_ACT, &chan->conn_state); - l2cap_seq_list_clear(&chan->retrans_list); - l2cap_seq_list_clear(&chan->srej_list); - skb_queue_purge(&chan->srej_q); - - chan->tx_state =3D L2CAP_TX_STATE_XMIT; - chan->rx_state =3D L2CAP_RX_STATE_MOVE; - - set_bit(CONN_REMOTE_BUSY, &chan->conn_state); -} - -static void l2cap_move_done(struct l2cap_chan *chan) -{ - u8 move_role =3D chan->move_role; - BT_DBG("chan %p", chan); - - chan->move_state =3D L2CAP_MOVE_STABLE; - chan->move_role =3D L2CAP_MOVE_ROLE_NONE; - - if (chan->mode !=3D L2CAP_MODE_ERTM) - return; - - switch (move_role) { - case L2CAP_MOVE_ROLE_INITIATOR: - l2cap_tx(chan, NULL, NULL, L2CAP_EV_EXPLICIT_POLL); - chan->rx_state =3D L2CAP_RX_STATE_WAIT_F; - break; - case L2CAP_MOVE_ROLE_RESPONDER: - chan->rx_state =3D L2CAP_RX_STATE_WAIT_P; - break; - } -} - static void l2cap_chan_ready(struct l2cap_chan *chan) { /* The channel may have already been flagged as connected in @@ -1505,10 +1352,7 @@ static void l2cap_le_start(struct l2cap_chan *chan) =20 static void l2cap_start_connection(struct l2cap_chan *chan) { - if (__amp_capable(chan)) { - BT_DBG("chan %p AMP capable: discover AMPs", chan); - a2mp_discover_amp(chan); - } else if (chan->conn->hcon->type =3D=3D LE_LINK) { + if (chan->conn->hcon->type =3D=3D LE_LINK) { l2cap_le_start(chan); } else { l2cap_send_conn_req(chan); @@ -1611,11 +1455,6 @@ static void l2cap_send_disconn_req(struct l2cap_chan= *chan, int err) __clear_ack_timer(chan); } =20 - if (chan->scid =3D=3D L2CAP_CID_A2MP) { - l2cap_state_change(chan, BT_DISCONN); - return; - } - req.dcid =3D cpu_to_le16(chan->dcid); req.scid =3D cpu_to_le16(chan->scid); l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_DISCONN_REQ, @@ -1754,11 +1593,6 @@ static void l2cap_conn_ready(struct l2cap_conn *conn) =20 l2cap_chan_lock(chan); =20 - if (chan->scid =3D=3D L2CAP_CID_A2MP) { - l2cap_chan_unlock(chan); - continue; - } - if (hcon->type =3D=3D LE_LINK) { l2cap_le_start(chan); } else if (chan->chan_type !=3D L2CAP_CHAN_CONN_ORIENTED) { @@ -2067,9 +1901,6 @@ static void l2cap_streaming_send(struct l2cap_chan *c= han, =20 BT_DBG("chan %p, skbs %p", chan, skbs); =20 - if (__chan_is_moving(chan)) - return; - skb_queue_splice_tail_init(skbs, &chan->tx_q); =20 while (!skb_queue_empty(&chan->tx_q)) { @@ -2112,9 +1943,6 @@ static int l2cap_ertm_send(struct l2cap_chan *chan) if (test_bit(CONN_REMOTE_BUSY, &chan->conn_state)) return 0; =20 - if (__chan_is_moving(chan)) - return 0; - while (chan->tx_send_head && chan->unacked_frames < chan->remote_tx_win && chan->tx_state =3D=3D L2CAP_TX_STATE_XMIT) { @@ -2180,9 +2008,6 @@ static void l2cap_ertm_resend(struct l2cap_chan *chan) if (test_bit(CONN_REMOTE_BUSY, &chan->conn_state)) return; =20 - if (__chan_is_moving(chan)) - return; - while (chan->retrans_list.head !=3D L2CAP_SEQ_LIST_CLEAR) { seq =3D l2cap_seq_list_pop(&chan->retrans_list); =20 @@ -2522,8 +2347,7 @@ static int l2cap_segment_sdu(struct l2cap_chan *chan, pdu_len =3D chan->conn->mtu; =20 /* Constrain PDU size for BR/EDR connections */ - if (!chan->hs_hcon) - pdu_len =3D min_t(size_t, pdu_len, L2CAP_BREDR_MAX_PAYLOAD); + pdu_len =3D min_t(size_t, pdu_len, L2CAP_BREDR_MAX_PAYLOAD); =20 /* Adjust for largest possible L2CAP overhead. */ if (chan->fcs) @@ -3287,11 +3111,6 @@ int l2cap_ertm_init(struct l2cap_chan *chan) =20 skb_queue_head_init(&chan->tx_q); =20 - chan->local_amp_id =3D AMP_ID_BREDR; - chan->move_id =3D AMP_ID_BREDR; - chan->move_state =3D L2CAP_MOVE_STABLE; - chan->move_role =3D L2CAP_MOVE_ROLE_NONE; - if (chan->mode !=3D L2CAP_MODE_ERTM) return 0; =20 @@ -3326,52 +3145,19 @@ static inline __u8 l2cap_select_mode(__u8 mode, __u= 16 remote_feat_mask) =20 static inline bool __l2cap_ews_supported(struct l2cap_conn *conn) { - return ((conn->local_fixed_chan & L2CAP_FC_A2MP) && - (conn->feat_mask & L2CAP_FEAT_EXT_WINDOW)); + return (conn->feat_mask & L2CAP_FEAT_EXT_WINDOW); } =20 static inline bool __l2cap_efs_supported(struct l2cap_conn *conn) { - return ((conn->local_fixed_chan & L2CAP_FC_A2MP) && - (conn->feat_mask & L2CAP_FEAT_EXT_FLOW)); + return (conn->feat_mask & L2CAP_FEAT_EXT_FLOW); } =20 static void __l2cap_set_ertm_timeouts(struct l2cap_chan *chan, struct l2cap_conf_rfc *rfc) { - if (chan->local_amp_id !=3D AMP_ID_BREDR && chan->hs_hcon) { - u64 ertm_to =3D chan->hs_hcon->hdev->amp_be_flush_to; - - /* Class 1 devices have must have ERTM timeouts - * exceeding the Link Supervision Timeout. The - * default Link Supervision Timeout for AMP - * controllers is 10 seconds. - * - * Class 1 devices use 0xffffffff for their - * best-effort flush timeout, so the clamping logic - * will result in a timeout that meets the above - * requirement. ERTM timeouts are 16-bit values, so - * the maximum timeout is 65.535 seconds. - */ - - /* Convert timeout to milliseconds and round */ - ertm_to =3D DIV_ROUND_UP_ULL(ertm_to, 1000); - - /* This is the recommended formula for class 2 devices - * that start ERTM timers when packets are sent to the - * controller. - */ - ertm_to =3D 3 * ertm_to + 500; - - if (ertm_to > 0xffff) - ertm_to =3D 0xffff; - - rfc->retrans_timeout =3D cpu_to_le16((u16) ertm_to); - rfc->monitor_timeout =3D rfc->retrans_timeout; - } else { - rfc->retrans_timeout =3D cpu_to_le16(L2CAP_DEFAULT_RETRANS_TO); - rfc->monitor_timeout =3D cpu_to_le16(L2CAP_DEFAULT_MONITOR_TO); - } + rfc->retrans_timeout =3D cpu_to_le16(L2CAP_DEFAULT_RETRANS_TO); + rfc->monitor_timeout =3D cpu_to_le16(L2CAP_DEFAULT_MONITOR_TO); } =20 static inline void l2cap_txwin_setup(struct l2cap_chan *chan) @@ -3623,13 +3409,7 @@ static int l2cap_parse_conf_req(struct l2cap_chan *c= han, void *data, size_t data case L2CAP_CONF_EWS: if (olen !=3D 2) break; - if (!(chan->conn->local_fixed_chan & L2CAP_FC_A2MP)) - return -ECONNREFUSED; - set_bit(FLAG_EXT_CTRL, &chan->flags); - set_bit(CONF_EWS_RECV, &chan->conf_state); - chan->tx_win_max =3D L2CAP_DEFAULT_EXT_WINDOW; - chan->remote_tx_win =3D val; - break; + return -ECONNREFUSED; =20 default: if (hint) @@ -4027,11 +3807,7 @@ void __l2cap_connect_rsp_defer(struct l2cap_chan *ch= an) rsp.dcid =3D cpu_to_le16(chan->scid); rsp.result =3D cpu_to_le16(L2CAP_CR_SUCCESS); rsp.status =3D cpu_to_le16(L2CAP_CS_NO_INFO); - - if (chan->hs_hcon) - rsp_code =3D L2CAP_CREATE_CHAN_RSP; - else - rsp_code =3D L2CAP_CONN_RSP; + rsp_code =3D L2CAP_CONN_RSP; =20 BT_DBG("chan %p rsp_code %u", chan, rsp_code); =20 @@ -4190,7 +3966,6 @@ static struct l2cap_chan *l2cap_connect(struct l2cap_= conn *conn, chan->dst_type =3D bdaddr_dst_type(conn->hcon); chan->psm =3D psm; chan->dcid =3D scid; - chan->local_amp_id =3D amp_id; =20 __l2cap_chan_add(conn, chan); =20 @@ -4516,10 +4291,7 @@ static inline int l2cap_config_req(struct l2cap_conn= *conn, /* check compatibility */ =20 /* Send rsp for BR/EDR channel */ - if (!chan->hs_hcon) - l2cap_send_efs_conf_rsp(chan, rsp, cmd->ident, flags); - else - chan->ident =3D cmd->ident; + l2cap_send_efs_conf_rsp(chan, rsp, cmd->ident, flags); } =20 unlock: @@ -4571,15 +4343,7 @@ static inline int l2cap_config_rsp(struct l2cap_conn= *conn, goto done; } =20 - if (!chan->hs_hcon) { - l2cap_send_efs_conf_rsp(chan, buf, cmd->ident, - 0); - } else { - if (l2cap_check_efs(chan)) { - amp_create_logical_link(chan); - chan->ident =3D cmd->ident; - } - } + l2cap_send_efs_conf_rsp(chan, buf, cmd->ident, 0); } goto done; =20 @@ -4750,9 +4514,6 @@ static inline int l2cap_information_req(struct l2cap_= conn *conn, if (!disable_ertm) feat_mask |=3D L2CAP_FEAT_ERTM | L2CAP_FEAT_STREAMING | L2CAP_FEAT_FCS; - if (conn->local_fixed_chan & L2CAP_FC_A2MP) - feat_mask |=3D L2CAP_FEAT_EXT_FLOW - | L2CAP_FEAT_EXT_WINDOW; =20 put_unaligned_le32(feat_mask, rsp->data); l2cap_send_cmd(conn, cmd->ident, L2CAP_INFO_RSP, sizeof(buf), @@ -4841,751 +4602,6 @@ static inline int l2cap_information_rsp(struct l2ca= p_conn *conn, return 0; } =20 -static int l2cap_create_channel_req(struct l2cap_conn *conn, - struct l2cap_cmd_hdr *cmd, - u16 cmd_len, void *data) -{ - struct l2cap_create_chan_req *req =3D data; - struct l2cap_create_chan_rsp rsp; - struct l2cap_chan *chan; - struct hci_dev *hdev; - u16 psm, scid; - - if (cmd_len !=3D sizeof(*req)) - return -EPROTO; - - if (!(conn->local_fixed_chan & L2CAP_FC_A2MP)) - return -EINVAL; - - psm =3D le16_to_cpu(req->psm); - scid =3D le16_to_cpu(req->scid); - - BT_DBG("psm 0x%2.2x, scid 0x%4.4x, amp_id %d", psm, scid, req->amp_id); - - /* For controller id 0 make BR/EDR connection */ - if (req->amp_id =3D=3D AMP_ID_BREDR) { - l2cap_connect(conn, cmd, data, L2CAP_CREATE_CHAN_RSP, - req->amp_id); - return 0; - } - - /* Validate AMP controller id */ - hdev =3D hci_dev_get(req->amp_id); - if (!hdev) - goto error; - - if (hdev->dev_type !=3D HCI_AMP || !test_bit(HCI_UP, &hdev->flags)) { - hci_dev_put(hdev); - goto error; - } - - chan =3D l2cap_connect(conn, cmd, data, L2CAP_CREATE_CHAN_RSP, - req->amp_id); - if (chan) { - struct amp_mgr *mgr =3D conn->hcon->amp_mgr; - struct hci_conn *hs_hcon; - - hs_hcon =3D hci_conn_hash_lookup_ba(hdev, AMP_LINK, - &conn->hcon->dst); - if (!hs_hcon) { - hci_dev_put(hdev); - cmd_reject_invalid_cid(conn, cmd->ident, chan->scid, - chan->dcid); - return 0; - } - - BT_DBG("mgr %p bredr_chan %p hs_hcon %p", mgr, chan, hs_hcon); - - mgr->bredr_chan =3D chan; - chan->hs_hcon =3D hs_hcon; - chan->fcs =3D L2CAP_FCS_NONE; - conn->mtu =3D hdev->block_mtu; - } - - hci_dev_put(hdev); - - return 0; - -error: - rsp.dcid =3D 0; - rsp.scid =3D cpu_to_le16(scid); - rsp.result =3D cpu_to_le16(L2CAP_CR_BAD_AMP); - rsp.status =3D cpu_to_le16(L2CAP_CS_NO_INFO); - - l2cap_send_cmd(conn, cmd->ident, L2CAP_CREATE_CHAN_RSP, - sizeof(rsp), &rsp); - - return 0; -} - -static void l2cap_send_move_chan_req(struct l2cap_chan *chan, u8 dest_amp_= id) -{ - struct l2cap_move_chan_req req; - u8 ident; - - BT_DBG("chan %p, dest_amp_id %d", chan, dest_amp_id); - - ident =3D l2cap_get_ident(chan->conn); - chan->ident =3D ident; - - req.icid =3D cpu_to_le16(chan->scid); - req.dest_amp_id =3D dest_amp_id; - - l2cap_send_cmd(chan->conn, ident, L2CAP_MOVE_CHAN_REQ, sizeof(req), - &req); - - __set_chan_timer(chan, L2CAP_MOVE_TIMEOUT); -} - -static void l2cap_send_move_chan_rsp(struct l2cap_chan *chan, u16 result) -{ - struct l2cap_move_chan_rsp rsp; - - BT_DBG("chan %p, result 0x%4.4x", chan, result); - - rsp.icid =3D cpu_to_le16(chan->dcid); - rsp.result =3D cpu_to_le16(result); - - l2cap_send_cmd(chan->conn, chan->ident, L2CAP_MOVE_CHAN_RSP, - sizeof(rsp), &rsp); -} - -static void l2cap_send_move_chan_cfm(struct l2cap_chan *chan, u16 result) -{ - struct l2cap_move_chan_cfm cfm; - - BT_DBG("chan %p, result 0x%4.4x", chan, result); - - chan->ident =3D l2cap_get_ident(chan->conn); - - cfm.icid =3D cpu_to_le16(chan->scid); - cfm.result =3D cpu_to_le16(result); - - l2cap_send_cmd(chan->conn, chan->ident, L2CAP_MOVE_CHAN_CFM, - sizeof(cfm), &cfm); - - __set_chan_timer(chan, L2CAP_MOVE_TIMEOUT); -} - -static void l2cap_send_move_chan_cfm_icid(struct l2cap_conn *conn, u16 ici= d) -{ - struct l2cap_move_chan_cfm cfm; - - BT_DBG("conn %p, icid 0x%4.4x", conn, icid); - - cfm.icid =3D cpu_to_le16(icid); - cfm.result =3D cpu_to_le16(L2CAP_MC_UNCONFIRMED); - - l2cap_send_cmd(conn, l2cap_get_ident(conn), L2CAP_MOVE_CHAN_CFM, - sizeof(cfm), &cfm); -} - -static void l2cap_send_move_chan_cfm_rsp(struct l2cap_conn *conn, u8 ident, - u16 icid) -{ - struct l2cap_move_chan_cfm_rsp rsp; - - BT_DBG("icid 0x%4.4x", icid); - - rsp.icid =3D cpu_to_le16(icid); - l2cap_send_cmd(conn, ident, L2CAP_MOVE_CHAN_CFM_RSP, sizeof(rsp), &rsp); -} - -static void __release_logical_link(struct l2cap_chan *chan) -{ - chan->hs_hchan =3D NULL; - chan->hs_hcon =3D NULL; - - /* Placeholder - release the logical link */ -} - -static void l2cap_logical_fail(struct l2cap_chan *chan) -{ - /* Logical link setup failed */ - if (chan->state !=3D BT_CONNECTED) { - /* Create channel failure, disconnect */ - l2cap_send_disconn_req(chan, ECONNRESET); - return; - } - - switch (chan->move_role) { - case L2CAP_MOVE_ROLE_RESPONDER: - l2cap_move_done(chan); - l2cap_send_move_chan_rsp(chan, L2CAP_MR_NOT_SUPP); - break; - case L2CAP_MOVE_ROLE_INITIATOR: - if (chan->move_state =3D=3D L2CAP_MOVE_WAIT_LOGICAL_COMP || - chan->move_state =3D=3D L2CAP_MOVE_WAIT_LOGICAL_CFM) { - /* Remote has only sent pending or - * success responses, clean up - */ - l2cap_move_done(chan); - } - - /* Other amp move states imply that the move - * has already aborted - */ - l2cap_send_move_chan_cfm(chan, L2CAP_MC_UNCONFIRMED); - break; - } -} - -static void l2cap_logical_finish_create(struct l2cap_chan *chan, - struct hci_chan *hchan) -{ - struct l2cap_conf_rsp rsp; - - chan->hs_hchan =3D hchan; - chan->hs_hcon->l2cap_data =3D chan->conn; - - l2cap_send_efs_conf_rsp(chan, &rsp, chan->ident, 0); - - if (test_bit(CONF_INPUT_DONE, &chan->conf_state)) { - int err; - - set_default_fcs(chan); - - err =3D l2cap_ertm_init(chan); - if (err < 0) - l2cap_send_disconn_req(chan, -err); - else - l2cap_chan_ready(chan); - } -} - -static void l2cap_logical_finish_move(struct l2cap_chan *chan, - struct hci_chan *hchan) -{ - chan->hs_hcon =3D hchan->conn; - chan->hs_hcon->l2cap_data =3D chan->conn; - - BT_DBG("move_state %d", chan->move_state); - - switch (chan->move_state) { - case L2CAP_MOVE_WAIT_LOGICAL_COMP: - /* Move confirm will be sent after a success - * response is received - */ - chan->move_state =3D L2CAP_MOVE_WAIT_RSP_SUCCESS; - break; - case L2CAP_MOVE_WAIT_LOGICAL_CFM: - if (test_bit(CONN_LOCAL_BUSY, &chan->conn_state)) { - chan->move_state =3D L2CAP_MOVE_WAIT_LOCAL_BUSY; - } else if (chan->move_role =3D=3D L2CAP_MOVE_ROLE_INITIATOR) { - chan->move_state =3D L2CAP_MOVE_WAIT_CONFIRM_RSP; - l2cap_send_move_chan_cfm(chan, L2CAP_MC_CONFIRMED); - } else if (chan->move_role =3D=3D L2CAP_MOVE_ROLE_RESPONDER) { - chan->move_state =3D L2CAP_MOVE_WAIT_CONFIRM; - l2cap_send_move_chan_rsp(chan, L2CAP_MR_SUCCESS); - } - break; - default: - /* Move was not in expected state, free the channel */ - __release_logical_link(chan); - - chan->move_state =3D L2CAP_MOVE_STABLE; - } -} - -/* Call with chan locked */ -void l2cap_logical_cfm(struct l2cap_chan *chan, struct hci_chan *hchan, - u8 status) -{ - BT_DBG("chan %p, hchan %p, status %d", chan, hchan, status); - - if (status) { - l2cap_logical_fail(chan); - __release_logical_link(chan); - return; - } - - if (chan->state !=3D BT_CONNECTED) { - /* Ignore logical link if channel is on BR/EDR */ - if (chan->local_amp_id !=3D AMP_ID_BREDR) - l2cap_logical_finish_create(chan, hchan); - } else { - l2cap_logical_finish_move(chan, hchan); - } -} - -void l2cap_move_start(struct l2cap_chan *chan) -{ - BT_DBG("chan %p", chan); - - if (chan->local_amp_id =3D=3D AMP_ID_BREDR) { - if (chan->chan_policy !=3D BT_CHANNEL_POLICY_AMP_PREFERRED) - return; - chan->move_role =3D L2CAP_MOVE_ROLE_INITIATOR; - chan->move_state =3D L2CAP_MOVE_WAIT_PREPARE; - /* Placeholder - start physical link setup */ - } else { - chan->move_role =3D L2CAP_MOVE_ROLE_INITIATOR; - chan->move_state =3D L2CAP_MOVE_WAIT_RSP_SUCCESS; - chan->move_id =3D 0; - l2cap_move_setup(chan); - l2cap_send_move_chan_req(chan, 0); - } -} - -static void l2cap_do_create(struct l2cap_chan *chan, int result, - u8 local_amp_id, u8 remote_amp_id) -{ - BT_DBG("chan %p state %s %u -> %u", chan, state_to_string(chan->state), - local_amp_id, remote_amp_id); - - chan->fcs =3D L2CAP_FCS_NONE; - - /* Outgoing channel on AMP */ - if (chan->state =3D=3D BT_CONNECT) { - if (result =3D=3D L2CAP_CR_SUCCESS) { - chan->local_amp_id =3D local_amp_id; - l2cap_send_create_chan_req(chan, remote_amp_id); - } else { - /* Revert to BR/EDR connect */ - l2cap_send_conn_req(chan); - } - - return; - } - - /* Incoming channel on AMP */ - if (__l2cap_no_conn_pending(chan)) { - struct l2cap_conn_rsp rsp; - char buf[128]; - rsp.scid =3D cpu_to_le16(chan->dcid); - rsp.dcid =3D cpu_to_le16(chan->scid); - - if (result =3D=3D L2CAP_CR_SUCCESS) { - /* Send successful response */ - rsp.result =3D cpu_to_le16(L2CAP_CR_SUCCESS); - rsp.status =3D cpu_to_le16(L2CAP_CS_NO_INFO); - } else { - /* Send negative response */ - rsp.result =3D cpu_to_le16(L2CAP_CR_NO_MEM); - rsp.status =3D cpu_to_le16(L2CAP_CS_NO_INFO); - } - - l2cap_send_cmd(chan->conn, chan->ident, L2CAP_CREATE_CHAN_RSP, - sizeof(rsp), &rsp); - - if (result =3D=3D L2CAP_CR_SUCCESS) { - l2cap_state_change(chan, BT_CONFIG); - set_bit(CONF_REQ_SENT, &chan->conf_state); - l2cap_send_cmd(chan->conn, l2cap_get_ident(chan->conn), - L2CAP_CONF_REQ, - l2cap_build_conf_req(chan, buf, sizeof(buf)), buf); - chan->num_conf_req++; - } - } -} - -static void l2cap_do_move_initiate(struct l2cap_chan *chan, u8 local_amp_i= d, - u8 remote_amp_id) -{ - l2cap_move_setup(chan); - chan->move_id =3D local_amp_id; - chan->move_state =3D L2CAP_MOVE_WAIT_RSP; - - l2cap_send_move_chan_req(chan, remote_amp_id); -} - -static void l2cap_do_move_respond(struct l2cap_chan *chan, int result) -{ - struct hci_chan *hchan =3D NULL; - - /* Placeholder - get hci_chan for logical link */ - - if (hchan) { - if (hchan->state =3D=3D BT_CONNECTED) { - /* Logical link is ready to go */ - chan->hs_hcon =3D hchan->conn; - chan->hs_hcon->l2cap_data =3D chan->conn; - chan->move_state =3D L2CAP_MOVE_WAIT_CONFIRM; - l2cap_send_move_chan_rsp(chan, L2CAP_MR_SUCCESS); - - l2cap_logical_cfm(chan, hchan, L2CAP_MR_SUCCESS); - } else { - /* Wait for logical link to be ready */ - chan->move_state =3D L2CAP_MOVE_WAIT_LOGICAL_CFM; - } - } else { - /* Logical link not available */ - l2cap_send_move_chan_rsp(chan, L2CAP_MR_NOT_ALLOWED); - } -} - -static void l2cap_do_move_cancel(struct l2cap_chan *chan, int result) -{ - if (chan->move_role =3D=3D L2CAP_MOVE_ROLE_RESPONDER) { - u8 rsp_result; - if (result =3D=3D -EINVAL) - rsp_result =3D L2CAP_MR_BAD_ID; - else - rsp_result =3D L2CAP_MR_NOT_ALLOWED; - - l2cap_send_move_chan_rsp(chan, rsp_result); - } - - chan->move_role =3D L2CAP_MOVE_ROLE_NONE; - chan->move_state =3D L2CAP_MOVE_STABLE; - - /* Restart data transmission */ - l2cap_ertm_send(chan); -} - -/* Invoke with locked chan */ -void __l2cap_physical_cfm(struct l2cap_chan *chan, int result) -{ - u8 local_amp_id =3D chan->local_amp_id; - u8 remote_amp_id =3D chan->remote_amp_id; - - BT_DBG("chan %p, result %d, local_amp_id %d, remote_amp_id %d", - chan, result, local_amp_id, remote_amp_id); - - if (chan->state =3D=3D BT_DISCONN || chan->state =3D=3D BT_CLOSED) - return; - - if (chan->state !=3D BT_CONNECTED) { - l2cap_do_create(chan, result, local_amp_id, remote_amp_id); - } else if (result !=3D L2CAP_MR_SUCCESS) { - l2cap_do_move_cancel(chan, result); - } else { - switch (chan->move_role) { - case L2CAP_MOVE_ROLE_INITIATOR: - l2cap_do_move_initiate(chan, local_amp_id, - remote_amp_id); - break; - case L2CAP_MOVE_ROLE_RESPONDER: - l2cap_do_move_respond(chan, result); - break; - default: - l2cap_do_move_cancel(chan, result); - break; - } - } -} - -static inline int l2cap_move_channel_req(struct l2cap_conn *conn, - struct l2cap_cmd_hdr *cmd, - u16 cmd_len, void *data) -{ - struct l2cap_move_chan_req *req =3D data; - struct l2cap_move_chan_rsp rsp; - struct l2cap_chan *chan; - u16 icid =3D 0; - u16 result =3D L2CAP_MR_NOT_ALLOWED; - - if (cmd_len !=3D sizeof(*req)) - return -EPROTO; - - icid =3D le16_to_cpu(req->icid); - - BT_DBG("icid 0x%4.4x, dest_amp_id %d", icid, req->dest_amp_id); - - if (!(conn->local_fixed_chan & L2CAP_FC_A2MP)) - return -EINVAL; - - chan =3D l2cap_get_chan_by_dcid(conn, icid); - if (!chan) { - rsp.icid =3D cpu_to_le16(icid); - rsp.result =3D cpu_to_le16(L2CAP_MR_NOT_ALLOWED); - l2cap_send_cmd(conn, cmd->ident, L2CAP_MOVE_CHAN_RSP, - sizeof(rsp), &rsp); - return 0; - } - - chan->ident =3D cmd->ident; - - if (chan->scid < L2CAP_CID_DYN_START || - chan->chan_policy =3D=3D BT_CHANNEL_POLICY_BREDR_ONLY || - (chan->mode !=3D L2CAP_MODE_ERTM && - chan->mode !=3D L2CAP_MODE_STREAMING)) { - result =3D L2CAP_MR_NOT_ALLOWED; - goto send_move_response; - } - - if (chan->local_amp_id =3D=3D req->dest_amp_id) { - result =3D L2CAP_MR_SAME_ID; - goto send_move_response; - } - - if (req->dest_amp_id !=3D AMP_ID_BREDR) { - struct hci_dev *hdev; - hdev =3D hci_dev_get(req->dest_amp_id); - if (!hdev || hdev->dev_type !=3D HCI_AMP || - !test_bit(HCI_UP, &hdev->flags)) { - if (hdev) - hci_dev_put(hdev); - - result =3D L2CAP_MR_BAD_ID; - goto send_move_response; - } - hci_dev_put(hdev); - } - - /* Detect a move collision. Only send a collision response - * if this side has "lost", otherwise proceed with the move. - * The winner has the larger bd_addr. - */ - if ((__chan_is_moving(chan) || - chan->move_role !=3D L2CAP_MOVE_ROLE_NONE) && - bacmp(&conn->hcon->src, &conn->hcon->dst) > 0) { - result =3D L2CAP_MR_COLLISION; - goto send_move_response; - } - - chan->move_role =3D L2CAP_MOVE_ROLE_RESPONDER; - l2cap_move_setup(chan); - chan->move_id =3D req->dest_amp_id; - - if (req->dest_amp_id =3D=3D AMP_ID_BREDR) { - /* Moving to BR/EDR */ - if (test_bit(CONN_LOCAL_BUSY, &chan->conn_state)) { - chan->move_state =3D L2CAP_MOVE_WAIT_LOCAL_BUSY; - result =3D L2CAP_MR_PEND; - } else { - chan->move_state =3D L2CAP_MOVE_WAIT_CONFIRM; - result =3D L2CAP_MR_SUCCESS; - } - } else { - chan->move_state =3D L2CAP_MOVE_WAIT_PREPARE; - /* Placeholder - uncomment when amp functions are available */ - /*amp_accept_physical(chan, req->dest_amp_id);*/ - result =3D L2CAP_MR_PEND; - } - -send_move_response: - l2cap_send_move_chan_rsp(chan, result); - - l2cap_chan_unlock(chan); - l2cap_chan_put(chan); - - return 0; -} - -static void l2cap_move_continue(struct l2cap_conn *conn, u16 icid, u16 res= ult) -{ - struct l2cap_chan *chan; - struct hci_chan *hchan =3D NULL; - - chan =3D l2cap_get_chan_by_scid(conn, icid); - if (!chan) { - l2cap_send_move_chan_cfm_icid(conn, icid); - return; - } - - __clear_chan_timer(chan); - if (result =3D=3D L2CAP_MR_PEND) - __set_chan_timer(chan, L2CAP_MOVE_ERTX_TIMEOUT); - - switch (chan->move_state) { - case L2CAP_MOVE_WAIT_LOGICAL_COMP: - /* Move confirm will be sent when logical link - * is complete. - */ - chan->move_state =3D L2CAP_MOVE_WAIT_LOGICAL_CFM; - break; - case L2CAP_MOVE_WAIT_RSP_SUCCESS: - if (result =3D=3D L2CAP_MR_PEND) { - break; - } else if (test_bit(CONN_LOCAL_BUSY, - &chan->conn_state)) { - chan->move_state =3D L2CAP_MOVE_WAIT_LOCAL_BUSY; - } else { - /* Logical link is up or moving to BR/EDR, - * proceed with move - */ - chan->move_state =3D L2CAP_MOVE_WAIT_CONFIRM_RSP; - l2cap_send_move_chan_cfm(chan, L2CAP_MC_CONFIRMED); - } - break; - case L2CAP_MOVE_WAIT_RSP: - /* Moving to AMP */ - if (result =3D=3D L2CAP_MR_SUCCESS) { - /* Remote is ready, send confirm immediately - * after logical link is ready - */ - chan->move_state =3D L2CAP_MOVE_WAIT_LOGICAL_CFM; - } else { - /* Both logical link and move success - * are required to confirm - */ - chan->move_state =3D L2CAP_MOVE_WAIT_LOGICAL_COMP; - } - - /* Placeholder - get hci_chan for logical link */ - if (!hchan) { - /* Logical link not available */ - l2cap_send_move_chan_cfm(chan, L2CAP_MC_UNCONFIRMED); - break; - } - - /* If the logical link is not yet connected, do not - * send confirmation. - */ - if (hchan->state !=3D BT_CONNECTED) - break; - - /* Logical link is already ready to go */ - - chan->hs_hcon =3D hchan->conn; - chan->hs_hcon->l2cap_data =3D chan->conn; - - if (result =3D=3D L2CAP_MR_SUCCESS) { - /* Can confirm now */ - l2cap_send_move_chan_cfm(chan, L2CAP_MC_CONFIRMED); - } else { - /* Now only need move success - * to confirm - */ - chan->move_state =3D L2CAP_MOVE_WAIT_RSP_SUCCESS; - } - - l2cap_logical_cfm(chan, hchan, L2CAP_MR_SUCCESS); - break; - default: - /* Any other amp move state means the move failed. */ - chan->move_id =3D chan->local_amp_id; - l2cap_move_done(chan); - l2cap_send_move_chan_cfm(chan, L2CAP_MC_UNCONFIRMED); - } - - l2cap_chan_unlock(chan); - l2cap_chan_put(chan); -} - -static void l2cap_move_fail(struct l2cap_conn *conn, u8 ident, u16 icid, - u16 result) -{ - struct l2cap_chan *chan; - - chan =3D l2cap_get_chan_by_ident(conn, ident); - if (!chan) { - /* Could not locate channel, icid is best guess */ - l2cap_send_move_chan_cfm_icid(conn, icid); - return; - } - - __clear_chan_timer(chan); - - if (chan->move_role =3D=3D L2CAP_MOVE_ROLE_INITIATOR) { - if (result =3D=3D L2CAP_MR_COLLISION) { - chan->move_role =3D L2CAP_MOVE_ROLE_RESPONDER; - } else { - /* Cleanup - cancel move */ - chan->move_id =3D chan->local_amp_id; - l2cap_move_done(chan); - } - } - - l2cap_send_move_chan_cfm(chan, L2CAP_MC_UNCONFIRMED); - - l2cap_chan_unlock(chan); - l2cap_chan_put(chan); -} - -static int l2cap_move_channel_rsp(struct l2cap_conn *conn, - struct l2cap_cmd_hdr *cmd, - u16 cmd_len, void *data) -{ - struct l2cap_move_chan_rsp *rsp =3D data; - u16 icid, result; - - if (cmd_len !=3D sizeof(*rsp)) - return -EPROTO; - - icid =3D le16_to_cpu(rsp->icid); - result =3D le16_to_cpu(rsp->result); - - BT_DBG("icid 0x%4.4x, result 0x%4.4x", icid, result); - - if (result =3D=3D L2CAP_MR_SUCCESS || result =3D=3D L2CAP_MR_PEND) - l2cap_move_continue(conn, icid, result); - else - l2cap_move_fail(conn, cmd->ident, icid, result); - - return 0; -} - -static int l2cap_move_channel_confirm(struct l2cap_conn *conn, - struct l2cap_cmd_hdr *cmd, - u16 cmd_len, void *data) -{ - struct l2cap_move_chan_cfm *cfm =3D data; - struct l2cap_chan *chan; - u16 icid, result; - - if (cmd_len !=3D sizeof(*cfm)) - return -EPROTO; - - icid =3D le16_to_cpu(cfm->icid); - result =3D le16_to_cpu(cfm->result); - - BT_DBG("icid 0x%4.4x, result 0x%4.4x", icid, result); - - chan =3D l2cap_get_chan_by_dcid(conn, icid); - if (!chan) { - /* Spec requires a response even if the icid was not found */ - l2cap_send_move_chan_cfm_rsp(conn, cmd->ident, icid); - return 0; - } - - if (chan->move_state =3D=3D L2CAP_MOVE_WAIT_CONFIRM) { - if (result =3D=3D L2CAP_MC_CONFIRMED) { - chan->local_amp_id =3D chan->move_id; - if (chan->local_amp_id =3D=3D AMP_ID_BREDR) - __release_logical_link(chan); - } else { - chan->move_id =3D chan->local_amp_id; - } - - l2cap_move_done(chan); - } - - l2cap_send_move_chan_cfm_rsp(conn, cmd->ident, icid); - - l2cap_chan_unlock(chan); - l2cap_chan_put(chan); - - return 0; -} - -static inline int l2cap_move_channel_confirm_rsp(struct l2cap_conn *conn, - struct l2cap_cmd_hdr *cmd, - u16 cmd_len, void *data) -{ - struct l2cap_move_chan_cfm_rsp *rsp =3D data; - struct l2cap_chan *chan; - u16 icid; - - if (cmd_len !=3D sizeof(*rsp)) - return -EPROTO; - - icid =3D le16_to_cpu(rsp->icid); - - BT_DBG("icid 0x%4.4x", icid); - - chan =3D l2cap_get_chan_by_scid(conn, icid); - if (!chan) - return 0; - - __clear_chan_timer(chan); - - if (chan->move_state =3D=3D L2CAP_MOVE_WAIT_CONFIRM_RSP) { - chan->local_amp_id =3D chan->move_id; - - if (chan->local_amp_id =3D=3D AMP_ID_BREDR && chan->hs_hchan) - __release_logical_link(chan); - - l2cap_move_done(chan); - } - - l2cap_chan_unlock(chan); - l2cap_chan_put(chan); - - return 0; -} - static inline int l2cap_conn_param_update_req(struct l2cap_conn *conn, struct l2cap_cmd_hdr *cmd, u16 cmd_len, u8 *data) @@ -5745,7 +4761,6 @@ static inline int l2cap_bredr_sig_cmd(struct l2cap_co= nn *conn, break; =20 case L2CAP_CONN_RSP: - case L2CAP_CREATE_CHAN_RSP: l2cap_connect_create_rsp(conn, cmd, cmd_len, data); break; =20 @@ -5780,26 +4795,6 @@ static inline int l2cap_bredr_sig_cmd(struct l2cap_c= onn *conn, l2cap_information_rsp(conn, cmd, cmd_len, data); break; =20 - case L2CAP_CREATE_CHAN_REQ: - err =3D l2cap_create_channel_req(conn, cmd, cmd_len, data); - break; - - case L2CAP_MOVE_CHAN_REQ: - err =3D l2cap_move_channel_req(conn, cmd, cmd_len, data); - break; - - case L2CAP_MOVE_CHAN_RSP: - l2cap_move_channel_rsp(conn, cmd, cmd_len, data); - break; - - case L2CAP_MOVE_CHAN_CFM: - err =3D l2cap_move_channel_confirm(conn, cmd, cmd_len, data); - break; - - case L2CAP_MOVE_CHAN_CFM_RSP: - l2cap_move_channel_confirm_rsp(conn, cmd, cmd_len, data); - break; - default: BT_ERR("Unknown BR/EDR signaling command 0x%2.2x", cmd->code); err =3D -EINVAL; @@ -7051,8 +6046,8 @@ static int l2cap_rx_state_recv(struct l2cap_chan *cha= n, if (control->final) { clear_bit(CONN_REMOTE_BUSY, &chan->conn_state); =20 - if (!test_and_clear_bit(CONN_REJ_ACT, &chan->conn_state) && - !__chan_is_moving(chan)) { + if (!test_and_clear_bit(CONN_REJ_ACT, + &chan->conn_state)) { control->final =3D 0; l2cap_retransmit_all(chan, control); } @@ -7245,11 +6240,7 @@ static int l2cap_finish_move(struct l2cap_chan *chan) BT_DBG("chan %p", chan); =20 chan->rx_state =3D L2CAP_RX_STATE_RECV; - - if (chan->hs_hcon) - chan->conn->mtu =3D chan->hs_hcon->hdev->block_mtu; - else - chan->conn->mtu =3D chan->conn->hcon->hdev->acl_mtu; + chan->conn->mtu =3D chan->conn->hcon->hdev->acl_mtu; =20 return l2cap_resegment(chan); } @@ -7316,11 +6307,7 @@ static int l2cap_rx_state_wait_f(struct l2cap_chan *= chan, */ chan->next_tx_seq =3D control->reqseq; chan->unacked_frames =3D 0; - - if (chan->hs_hcon) - chan->conn->mtu =3D chan->hs_hcon->hdev->block_mtu; - else - chan->conn->mtu =3D chan->conn->hcon->hdev->acl_mtu; + chan->conn->mtu =3D chan->conn->hcon->hdev->acl_mtu; =20 err =3D l2cap_resegment(chan); =20 @@ -7672,21 +6659,10 @@ static void l2cap_data_channel(struct l2cap_conn *c= onn, u16 cid, =20 chan =3D l2cap_get_chan_by_scid(conn, cid); if (!chan) { - if (cid =3D=3D L2CAP_CID_A2MP) { - chan =3D a2mp_channel_create(conn, skb); - if (!chan) { - kfree_skb(skb); - return; - } - - l2cap_chan_hold(chan); - l2cap_chan_lock(chan); - } else { - BT_DBG("unknown cid 0x%4.4x", cid); - /* Drop packet and return */ - kfree_skb(skb); - return; - } + BT_DBG("unknown cid 0x%4.4x", cid); + /* Drop packet and return */ + kfree_skb(skb); + return; } =20 BT_DBG("chan %p, len %d", chan, skb->len); @@ -7887,10 +6863,6 @@ static struct l2cap_conn *l2cap_conn_add(struct hci_= conn *hcon) =20 conn->local_fixed_chan =3D L2CAP_FC_SIG_BREDR | L2CAP_FC_CONNLESS; =20 - if (hcon->type =3D=3D ACL_LINK && - hci_dev_test_flag(hcon->hdev, HCI_HS_ENABLED)) - conn->local_fixed_chan |=3D L2CAP_FC_A2MP; - if (hci_dev_test_flag(hcon->hdev, HCI_LE_ENABLED) && (bredr_sc_enabled(hcon->hdev) || hci_dev_test_flag(hcon->hdev, HCI_FORCE_BREDR_SMP))) @@ -8355,11 +7327,6 @@ static void l2cap_security_cfm(struct hci_conn *hcon= , u8 status, u8 encrypt) BT_DBG("chan %p scid 0x%4.4x state %s", chan, chan->scid, state_to_string(chan->state)); =20 - if (chan->scid =3D=3D L2CAP_CID_A2MP) { - l2cap_chan_unlock(chan); - continue; - } - if (!status && encrypt) chan->sec_level =3D hcon->sec_level; =20 diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c index e50d3d102078e..ee7a41d6994fc 100644 --- a/net/bluetooth/l2cap_sock.c +++ b/net/bluetooth/l2cap_sock.c @@ -1027,23 +1027,7 @@ static int l2cap_sock_setsockopt(struct socket *sock= , int level, int optname, break; } =20 - if (opt > BT_CHANNEL_POLICY_AMP_PREFERRED) { - err =3D -EINVAL; - break; - } - - if (chan->mode !=3D L2CAP_MODE_ERTM && - chan->mode !=3D L2CAP_MODE_STREAMING) { - err =3D -EOPNOTSUPP; - break; - } - - chan->chan_policy =3D (u8) opt; - - if (sk->sk_state =3D=3D BT_CONNECTED && - chan->move_role =3D=3D L2CAP_MOVE_ROLE_NONE) - l2cap_move_start(chan); - + err =3D -EOPNOTSUPP; break; =20 case BT_SNDMTU: diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index 688890f581cba..b2a272bc4d7c5 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -835,8 +835,6 @@ static u32 get_supported_settings(struct hci_dev *hdev) =20 if (lmp_ssp_capable(hdev)) { settings |=3D MGMT_SETTING_SSP; - if (IS_ENABLED(CONFIG_BT_HS)) - settings |=3D MGMT_SETTING_HS; } =20 if (lmp_sc_capable(hdev)) @@ -901,9 +899,6 @@ static u32 get_current_settings(struct hci_dev *hdev) if (hci_dev_test_flag(hdev, HCI_SSP_ENABLED)) settings |=3D MGMT_SETTING_SSP; =20 - if (hci_dev_test_flag(hdev, HCI_HS_ENABLED)) - settings |=3D MGMT_SETTING_HS; - if (hci_dev_test_flag(hdev, HCI_ADVERTISING)) settings |=3D MGMT_SETTING_ADVERTISING; =20 @@ -1930,7 +1925,6 @@ static void set_ssp_complete(struct hci_dev *hdev, vo= id *data, int err) =20 if (enable && hci_dev_test_and_clear_flag(hdev, HCI_SSP_ENABLED)) { - hci_dev_clear_flag(hdev, HCI_HS_ENABLED); new_settings(hdev, NULL); } =20 @@ -1943,12 +1937,6 @@ static void set_ssp_complete(struct hci_dev *hdev, v= oid *data, int err) changed =3D !hci_dev_test_and_set_flag(hdev, HCI_SSP_ENABLED); } else { changed =3D hci_dev_test_and_clear_flag(hdev, HCI_SSP_ENABLED); - - if (!changed) - changed =3D hci_dev_test_and_clear_flag(hdev, - HCI_HS_ENABLED); - else - hci_dev_clear_flag(hdev, HCI_HS_ENABLED); } =20 mgmt_pending_foreach(MGMT_OP_SET_SSP, hdev, settings_rsp, &match); @@ -2012,11 +2000,6 @@ static int set_ssp(struct sock *sk, struct hci_dev *= hdev, void *data, u16 len) } else { changed =3D hci_dev_test_and_clear_flag(hdev, HCI_SSP_ENABLED); - if (!changed) - changed =3D hci_dev_test_and_clear_flag(hdev, - HCI_HS_ENABLED); - else - hci_dev_clear_flag(hdev, HCI_HS_ENABLED); } =20 err =3D send_settings_rsp(sk, MGMT_OP_SET_SSP, hdev); @@ -2062,63 +2045,10 @@ static int set_ssp(struct sock *sk, struct hci_dev = *hdev, void *data, u16 len) =20 static int set_hs(struct sock *sk, struct hci_dev *hdev, void *data, u16 l= en) { - struct mgmt_mode *cp =3D data; - bool changed; - u8 status; - int err; - bt_dev_dbg(hdev, "sock %p", sk); =20 - if (!IS_ENABLED(CONFIG_BT_HS)) - return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, + return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, MGMT_STATUS_NOT_SUPPORTED); - - status =3D mgmt_bredr_support(hdev); - if (status) - return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, status); - - if (!lmp_ssp_capable(hdev)) - return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, - MGMT_STATUS_NOT_SUPPORTED); - - if (!hci_dev_test_flag(hdev, HCI_SSP_ENABLED)) - return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, - MGMT_STATUS_REJECTED); - - if (cp->val !=3D 0x00 && cp->val !=3D 0x01) - return mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, - MGMT_STATUS_INVALID_PARAMS); - - hci_dev_lock(hdev); - - if (pending_find(MGMT_OP_SET_SSP, hdev)) { - err =3D mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, - MGMT_STATUS_BUSY); - goto unlock; - } - - if (cp->val) { - changed =3D !hci_dev_test_and_set_flag(hdev, HCI_HS_ENABLED); - } else { - if (hdev_is_powered(hdev)) { - err =3D mgmt_cmd_status(sk, hdev->id, MGMT_OP_SET_HS, - MGMT_STATUS_REJECTED); - goto unlock; - } - - changed =3D hci_dev_test_and_clear_flag(hdev, HCI_HS_ENABLED); - } - - err =3D send_settings_rsp(sk, MGMT_OP_SET_HS, hdev); - if (err < 0) - goto unlock; - - if (changed) - err =3D new_settings(hdev, sk); - -unlock: - hci_dev_unlock(hdev); - return err; } =20 static void set_le_complete(struct hci_dev *hdev, void *data, int err) @@ -6766,7 +6696,6 @@ static int set_bredr(struct sock *sk, struct hci_dev = *hdev, void *data, u16 len) hci_dev_clear_flag(hdev, HCI_SSP_ENABLED); hci_dev_clear_flag(hdev, HCI_LINK_SECURITY); hci_dev_clear_flag(hdev, HCI_FAST_CONNECTABLE); - hci_dev_clear_flag(hdev, HCI_HS_ENABLED); } =20 hci_dev_change_flag(hdev, HCI_BREDR_ENABLED); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9C99E17AF8C; Sun, 24 Mar 2024 22:40:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320000; cv=none; b=jo5vTfvTNF4zsFVj9C+80GpEEwXcQRw31WlDyp99LJMu0KumpqPQZL2a8Wc1S7gybgN3nHCLHNEzWU183aod6nGMEdYvkGuz6x/aw63DNyD7iw0blkYCmzdxRC7EZ4loeAkm7XC3RpnKEG82uZsTbnJ6UQ083fM+2R8aHoC+1bA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320000; c=relaxed/simple; bh=y+HV7YtlBJC6/jdrObaiVxHo/vUzd46iZhPpIrgXRLo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dso1KAORumY041oNHe1p4/FaTEl/JzSlxntJJ0dj5X8xNSEbWJe5/CWAQMMCHX3MsaVUfPbaK2WDfvcPYThe2Jdofu+zg0Zfqt+eRg9ZMKIxlmzW6O5UR1pgUrkWO4ShIuuLY5Un8RmKOyojQQg9SLfNqCC27e9ckbzr08oB7Ro= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AUCnSj5a; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AUCnSj5a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EEE6CC43399; Sun, 24 Mar 2024 22:39:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320000; bh=y+HV7YtlBJC6/jdrObaiVxHo/vUzd46iZhPpIrgXRLo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AUCnSj5aIZDesIYOxWcVI1oTATWSY1ODHwAD0lWJL3MNnkF/gZlkTMxouITLXvMEk PKCD3dFgQxJgBcu2y0runn/KXW4eHU+yf/xs95rAWDLLxVB8Pu3c8UOsM+rWk2vAA3 oZefYxfzxfS2fAuR9STUQ+luTYqGzel4wpQF4t5SGzOCUejgxzt0/zBtQlrSpZIciz 2HP7JaoqjsvgPaSQbCuv6HHxk2UTfxYmGqMAN5o8oO63YYqjehoM8EmLaAIo1Rr5u0 7zDRUTd3nz2fOWHNI/hkJwv8Sl89/LSLqwEUYy1oXTXyNRM4nTt9F9h2le9EJyfUwU pJdPmprJMsrqw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 306/715] Bluetooth: hci_event: Fix not indicating new connection for BIG Sync Date: Sun, 24 Mar 2024 18:28:05 -0400 Message-ID: <20240324223455.1342824-307-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit eeda1bf97bb500a901f7a9ee5615bad2160f2378 ] BIG Sync (aka. Broadcast sink) requires to inform that the device is connected when a data path is active otherwise userspace could attempt to free resources allocated to the device object while scanning. Fixes: 1d11d70d1f6b ("Bluetooth: ISO: Pass BIG encryption info through QoS") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/bluetooth/hci_event.c | 21 ++++++++++++++------- net/bluetooth/mgmt.c | 4 ++++ 2 files changed, 18 insertions(+), 7 deletions(-) diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index 55daada8dc15d..9ee66b393981b 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -2524,9 +2524,7 @@ static void hci_check_pending_name(struct hci_dev *hd= ev, struct hci_conn *conn, * Only those in BT_CONFIG or BT_CONNECTED states can be * considered connected. */ - if (conn && - (conn->state =3D=3D BT_CONFIG || conn->state =3D=3D BT_CONNECTED) && - !test_and_set_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags)) + if (conn && (conn->state =3D=3D BT_CONFIG || conn->state =3D=3D BT_CONNEC= TED)) mgmt_device_connected(hdev, conn, name, name_len); =20 if (discov->state =3D=3D DISCOVERY_STOPPED) @@ -3758,8 +3756,9 @@ static void hci_remote_features_evt(struct hci_dev *h= dev, void *data, bacpy(&cp.bdaddr, &conn->dst); cp.pscan_rep_mode =3D 0x02; hci_send_cmd(hdev, HCI_OP_REMOTE_NAME_REQ, sizeof(cp), &cp); - } else if (!test_and_set_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags)) + } else { mgmt_device_connected(hdev, conn, NULL, 0); + } =20 if (!hci_outgoing_auth_needed(hdev, conn)) { conn->state =3D BT_CONNECTED; @@ -3932,6 +3931,11 @@ static u8 hci_cc_le_setup_iso_path(struct hci_dev *h= dev, void *data, * last. */ hci_connect_cfm(conn, rp->status); + + /* Notify device connected in case it is a BIG Sync */ + if (!rp->status && test_bit(HCI_CONN_BIG_SYNC, &conn->flags)) + mgmt_device_connected(hdev, conn, NULL, 0); + break; } =20 @@ -5006,8 +5010,9 @@ static void hci_remote_ext_features_evt(struct hci_de= v *hdev, void *data, bacpy(&cp.bdaddr, &conn->dst); cp.pscan_rep_mode =3D 0x02; hci_send_cmd(hdev, HCI_OP_REMOTE_NAME_REQ, sizeof(cp), &cp); - } else if (!test_and_set_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags)) + } else { mgmt_device_connected(hdev, conn, NULL, 0); + } =20 if (!hci_outgoing_auth_needed(hdev, conn)) { conn->state =3D BT_CONNECTED; @@ -5980,8 +5985,7 @@ static void le_conn_complete_evt(struct hci_dev *hdev= , u8 status, goto unlock; } =20 - if (!test_and_set_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags)) - mgmt_device_connected(hdev, conn, NULL, 0); + mgmt_device_connected(hdev, conn, NULL, 0); =20 conn->sec_level =3D BT_SECURITY_LOW; conn->state =3D BT_CONFIG; @@ -7210,6 +7214,9 @@ static void hci_le_big_info_adv_report_evt(struct hci= _dev *hdev, void *data, /* Notify iso layer */ hci_connect_cfm(pa_sync, 0x00); =20 + /* Notify MGMT layer */ + mgmt_device_connected(hdev, pa_sync, NULL, 0); + unlock: hci_dev_unlock(hdev); } diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index b2a272bc4d7c5..7490092ccb2de 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -3118,6 +3118,7 @@ static int disconnect(struct sock *sk, struct hci_dev= *hdev, void *data, static u8 link_to_bdaddr(u8 link_type, u8 addr_type) { switch (link_type) { + case ISO_LINK: case LE_LINK: switch (addr_type) { case ADDR_LE_DEV_PUBLIC: @@ -9610,6 +9611,9 @@ void mgmt_device_connected(struct hci_dev *hdev, stru= ct hci_conn *conn, u16 eir_len =3D 0; u32 flags =3D 0; =20 + if (test_and_set_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags)) + return; + /* allocate buff for LE or BR/EDR adv */ if (conn->le_adv_data_len > 0) skb =3D mgmt_alloc_skb(hdev, MGMT_EV_DEVICE_CONNECTED, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8AB5717AFA7; Sun, 24 Mar 2024 22:40:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320001; cv=none; b=MRRyVdxYCfvEh1xFLElrT42tho6BMwmpKb2AC/nT3pYuq7PBRPQPvcfroiywiwyLJjxEacrZT1SPuYDNzw77iOU6o4h153BX8jebXjyw9eaw8VxYeKsh/mU1MxDJeL5fzfVYSA6SlGwG+hpTMqq/z2I3czVPd9l9K7+P9wriG6w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320001; c=relaxed/simple; bh=5mSPBjLV0u+Pvcr5pGiX6KSIy1OJMNHkJXXHNu0TY4c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=P2MBQD3ENJyWBHt4qEeXP/NzF2QUSf3aiKl/B1Tu5WrKzHD8oD/abUDVcZ2BU/fuzR3gVcckVw9Xb4Dc9qfbul9AMkdibLC1sp65YoZNWHkFEvwEpY8dgRW1UErp1hIQxfjxvtDOr/ZqOy3fSOXMQRNu1awXsJMwmwWl80NDBEs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f4A1S/wz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="f4A1S/wz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BE700C433C7; Sun, 24 Mar 2024 22:40:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320001; bh=5mSPBjLV0u+Pvcr5pGiX6KSIy1OJMNHkJXXHNu0TY4c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f4A1S/wz81b76DaVTvl8ngdsuHzE6T+iH56Ijufz+XJXmI8FQbVu+fEO/vRgoxnLx EjDGH1tTim1J1xp0+68oxwEK//hjRzdZ/GFX1iptiUWXLqIEoDxgOqddHLuUmkwvoH 1JjtEg4hrpIZeIWLFk5fzaN8B/WjGdmZE+Q1WGmZWM26VXkeqQ7S0isJg/ygOmkgvA YtM2+LfeMIZ04jq+0wa1Y+NfVzTmOodbDiCyz7vHBNZcIj1sflLtx1hTnZCaRyXWkk N36rmdWooKQ7pwstcwHV72OvV5EaiENa+tLgRg+GDiuFYZxHkmeZqEOD34vnB3a3Y5 KMNiek1wlEwqg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bartosz Golaszewski , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 307/715] Bluetooth: hci_qca: don't use IS_ERR_OR_NULL() with gpiod_get_optional() Date: Sun, 24 Mar 2024 18:28:06 -0400 Message-ID: <20240324223455.1342824-308-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bartosz Golaszewski [ Upstream commit 56d074d26c5828773b00b2185dd7e1d08273b8e8 ] The optional variants for the gpiod_get() family of functions return NULL if the GPIO in question is not associated with this device. They return ERR_PTR() on any other error. NULL descriptors are graciously handled by GPIOLIB and can be safely passed to any of the GPIO consumer interfaces as they will return 0 and act as if the function succeeded. If one is using the optional variant, then there's no point in checking for NULL. Fixes: 6845667146a2 ("Bluetooth: hci_qca: Fix NULL vs IS_ERR_OR_NULL check = in qca_serdev_probe") Signed-off-by: Bartosz Golaszewski Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/bluetooth/hci_qca.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index edd2a81b4d5ed..8a60ad7acd705 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -2326,7 +2326,7 @@ static int qca_serdev_probe(struct serdev_device *ser= dev) =20 qcadev->bt_en =3D devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW); - if (IS_ERR_OR_NULL(qcadev->bt_en) && + if (IS_ERR(qcadev->bt_en) && (data->soc_type =3D=3D QCA_WCN6750 || data->soc_type =3D=3D QCA_WCN6855)) { dev_err(&serdev->dev, "failed to acquire BT_EN gpio\n"); @@ -2335,7 +2335,7 @@ static int qca_serdev_probe(struct serdev_device *ser= dev) =20 qcadev->sw_ctrl =3D devm_gpiod_get_optional(&serdev->dev, "swctrl", GPIOD_IN); - if (IS_ERR_OR_NULL(qcadev->sw_ctrl) && + if (IS_ERR(qcadev->sw_ctrl) && (data->soc_type =3D=3D QCA_WCN6750 || data->soc_type =3D=3D QCA_WCN6855 || data->soc_type =3D=3D QCA_WCN7850)) @@ -2357,7 +2357,7 @@ static int qca_serdev_probe(struct serdev_device *ser= dev) default: qcadev->bt_en =3D devm_gpiod_get_optional(&serdev->dev, "enable", GPIOD_OUT_LOW); - if (IS_ERR_OR_NULL(qcadev->bt_en)) { + if (IS_ERR(qcadev->bt_en)) { dev_warn(&serdev->dev, "failed to acquire enable gpio\n"); power_ctrl_enabled =3D false; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5823C17AFBA; Sun, 24 Mar 2024 22:40:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320002; cv=none; b=ulo6pskEJ1yVDNxnXODXLwoeYfQEr0hTrL/sCTGvszcaCuwed+2gfgGPqa5D3IsvSaVmJYYEZvCJUKvgTyOSXq62jdsNkWLxJV4VAVf4DaSzz3vbfKHhpA44UbzdmU1UzcC1joDTjh6N9Z5Exxj8gGMkonOuJRaK8pipuwdXDO8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320002; c=relaxed/simple; bh=VGpJg9nUtL5QVkUKtg/CMgG2y38usEe4a4r4Fwz44gE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CgDzvQnJtsXursLuJ6sd97wyAtwApTVi4cv836Ubzbc7020vmP3dGNHqodQjOvPMYkANgfDOGyZcPjYdwQ8yWnky92Q952OqZsRElDMEYs/+GAPs3VfazzuAg7FEj2TKEgeQ9ku5gVFjd3OLxEvpHzoDQO3xNF2zezojZLb0GZc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sAGV/Izz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sAGV/Izz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5F5BC433F1; Sun, 24 Mar 2024 22:40:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320002; bh=VGpJg9nUtL5QVkUKtg/CMgG2y38usEe4a4r4Fwz44gE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sAGV/Izz+/YVyNhgwzoOCY0mLTfIpUVfGmRLv9Mh5fnSUkpwARByH+Z+lUotN2kp7 nkuD1ndPVJOE9xDqDWjbRx0pTZQXp9q67hSUAM6LeVuVb0t0WoXhFFJacuiMGN9SZk JYVU+wMupgPAnfUj/8y9za1OKBX3ei0F8+bIreoO8/HdJbUrjN6qY7tKZe0ksPWtvJ nppFRWqBNZ/MfVLe/HXKwfQ9YG2/ha+AkAI/zz36eIqF7hqj2Lm1FsOyA9lP/78aty d4+BYZykexwXhyM0+3C/qQ5bDNeLshBA1kORUTOT/NOEbE73xwk8ShQOKgdijOM/YO Ut7Ho5Jz6Bu4Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 308/715] Bluetooth: hci_core: Cancel request on command timeout Date: Sun, 24 Mar 2024 18:28:07 -0400 Message-ID: <20240324223455.1342824-309-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit 63298d6e752fc0ec7f5093860af8bc9f047b30c8 ] If command has timed out call __hci_cmd_sync_cancel to notify the hci_req since it will inevitably cause a timeout. This also rework the code around __hci_cmd_sync_cancel since it was wrongly assuming it needs to cancel timer as well, but sometimes the timers have not been started or in fact they already had timed out in which case they don't need to be cancel yet again. Signed-off-by: Luiz Augusto von Dentz Stable-dep-of: 2615fd9a7c25 ("Bluetooth: hci_sync: Fix overwriting request = callback") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- include/net/bluetooth/hci_sync.h | 2 +- net/bluetooth/hci_core.c | 84 ++++++++++++++++++++++---------- net/bluetooth/hci_request.c | 2 +- net/bluetooth/hci_sync.c | 20 ++++---- net/bluetooth/mgmt.c | 2 +- 5 files changed, 71 insertions(+), 39 deletions(-) diff --git a/include/net/bluetooth/hci_sync.h b/include/net/bluetooth/hci_s= ync.h index 6efbc2152146b..e2582c2425449 100644 --- a/include/net/bluetooth/hci_sync.h +++ b/include/net/bluetooth/hci_sync.h @@ -42,7 +42,7 @@ int __hci_cmd_sync_status_sk(struct hci_dev *hdev, u16 op= code, u32 plen, void hci_cmd_sync_init(struct hci_dev *hdev); void hci_cmd_sync_clear(struct hci_dev *hdev); void hci_cmd_sync_cancel(struct hci_dev *hdev, int err); -void __hci_cmd_sync_cancel(struct hci_dev *hdev, int err); +void hci_cmd_sync_cancel_sync(struct hci_dev *hdev, int err); =20 int hci_cmd_sync_submit(struct hci_dev *hdev, hci_cmd_sync_work_func_t fun= c, void *data, hci_cmd_sync_work_destroy_t destroy); diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 2821a42cefdc6..539305b9a0e27 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -1492,10 +1492,11 @@ static void hci_cmd_timeout(struct work_struct *wor= k) cmd_timer.work); =20 if (hdev->sent_cmd) { - struct hci_command_hdr *sent =3D (void *) hdev->sent_cmd->data; - u16 opcode =3D __le16_to_cpu(sent->opcode); + u16 opcode =3D hci_skb_opcode(hdev->sent_cmd); =20 bt_dev_err(hdev, "command 0x%4.4x tx timeout", opcode); + + hci_cmd_sync_cancel_sync(hdev, ETIMEDOUT); } else { bt_dev_err(hdev, "command tx timeout"); } @@ -2826,6 +2827,23 @@ int hci_unregister_suspend_notifier(struct hci_dev *= hdev) return ret; } =20 +/* Cancel ongoing command synchronously: + * + * - Cancel command timer + * - Reset command counter + * - Cancel command request + */ +static void hci_cancel_cmd_sync(struct hci_dev *hdev, int err) +{ + bt_dev_dbg(hdev, "err 0x%2.2x", err); + + cancel_delayed_work_sync(&hdev->cmd_timer); + cancel_delayed_work_sync(&hdev->ncmd_timer); + atomic_set(&hdev->cmd_cnt, 1); + + hci_cmd_sync_cancel_sync(hdev, -err); +} + /* Suspend HCI device */ int hci_suspend_dev(struct hci_dev *hdev) { @@ -2843,7 +2861,7 @@ int hci_suspend_dev(struct hci_dev *hdev) return 0; =20 /* Cancel potentially blocking sync operation before suspend */ - __hci_cmd_sync_cancel(hdev, -EHOSTDOWN); + hci_cancel_cmd_sync(hdev, -EHOSTDOWN); =20 hci_req_sync_lock(hdev); ret =3D hci_suspend_sync(hdev); @@ -4128,6 +4146,33 @@ static void hci_rx_work(struct work_struct *work) } } =20 +static void hci_send_cmd_sync(struct hci_dev *hdev, struct sk_buff *skb) +{ + int err; + + bt_dev_dbg(hdev, "skb %p", skb); + + kfree_skb(hdev->sent_cmd); + + hdev->sent_cmd =3D skb_clone(skb, GFP_KERNEL); + if (!hdev->sent_cmd) { + skb_queue_head(&hdev->cmd_q, skb); + queue_work(hdev->workqueue, &hdev->cmd_work); + return; + } + + err =3D hci_send_frame(hdev, skb); + if (err < 0) { + hci_cmd_sync_cancel_sync(hdev, err); + return; + } + + if (hci_req_status_pend(hdev)) + hci_dev_set_flag(hdev, HCI_CMD_PENDING); + + atomic_dec(&hdev->cmd_cnt); +} + static void hci_cmd_work(struct work_struct *work) { struct hci_dev *hdev =3D container_of(work, struct hci_dev, cmd_work); @@ -4142,30 +4187,15 @@ static void hci_cmd_work(struct work_struct *work) if (!skb) return; =20 - kfree_skb(hdev->sent_cmd); - - hdev->sent_cmd =3D skb_clone(skb, GFP_KERNEL); - if (hdev->sent_cmd) { - int res; - if (hci_req_status_pend(hdev)) - hci_dev_set_flag(hdev, HCI_CMD_PENDING); - atomic_dec(&hdev->cmd_cnt); + hci_send_cmd_sync(hdev, skb); =20 - res =3D hci_send_frame(hdev, skb); - if (res < 0) - __hci_cmd_sync_cancel(hdev, -res); - - rcu_read_lock(); - if (test_bit(HCI_RESET, &hdev->flags) || - hci_dev_test_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE)) - cancel_delayed_work(&hdev->cmd_timer); - else - queue_delayed_work(hdev->workqueue, &hdev->cmd_timer, - HCI_CMD_TIMEOUT); - rcu_read_unlock(); - } else { - skb_queue_head(&hdev->cmd_q, skb); - queue_work(hdev->workqueue, &hdev->cmd_work); - } + rcu_read_lock(); + if (test_bit(HCI_RESET, &hdev->flags) || + hci_dev_test_flag(hdev, HCI_CMD_DRAIN_WORKQUEUE)) + cancel_delayed_work(&hdev->cmd_timer); + else + queue_delayed_work(hdev->workqueue, &hdev->cmd_timer, + HCI_CMD_TIMEOUT); + rcu_read_unlock(); } } diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c index 6e023b0104b03..00e02138003ec 100644 --- a/net/bluetooth/hci_request.c +++ b/net/bluetooth/hci_request.c @@ -895,7 +895,7 @@ void hci_request_setup(struct hci_dev *hdev) =20 void hci_request_cancel_all(struct hci_dev *hdev) { - __hci_cmd_sync_cancel(hdev, ENODEV); + hci_cmd_sync_cancel_sync(hdev, ENODEV); =20 cancel_interleave_scan(hdev); } diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c index 5716345a26dfb..5236fe72a8553 100644 --- a/net/bluetooth/hci_sync.c +++ b/net/bluetooth/hci_sync.c @@ -584,7 +584,7 @@ void hci_cmd_sync_clear(struct hci_dev *hdev) mutex_unlock(&hdev->cmd_sync_work_lock); } =20 -void __hci_cmd_sync_cancel(struct hci_dev *hdev, int err) +void hci_cmd_sync_cancel(struct hci_dev *hdev, int err) { bt_dev_dbg(hdev, "err 0x%2.2x", err); =20 @@ -592,15 +592,17 @@ void __hci_cmd_sync_cancel(struct hci_dev *hdev, int = err) hdev->req_result =3D err; hdev->req_status =3D HCI_REQ_CANCELED; =20 - cancel_delayed_work_sync(&hdev->cmd_timer); - cancel_delayed_work_sync(&hdev->ncmd_timer); - atomic_set(&hdev->cmd_cnt, 1); - - wake_up_interruptible(&hdev->req_wait_q); + queue_work(hdev->workqueue, &hdev->cmd_sync_cancel_work); } } +EXPORT_SYMBOL(hci_cmd_sync_cancel); =20 -void hci_cmd_sync_cancel(struct hci_dev *hdev, int err) +/* Cancel ongoing command request synchronously: + * + * - Set result and mark status to HCI_REQ_CANCELED + * - Wakeup command sync thread + */ +void hci_cmd_sync_cancel_sync(struct hci_dev *hdev, int err) { bt_dev_dbg(hdev, "err 0x%2.2x", err); =20 @@ -608,10 +610,10 @@ void hci_cmd_sync_cancel(struct hci_dev *hdev, int er= r) hdev->req_result =3D err; hdev->req_status =3D HCI_REQ_CANCELED; =20 - queue_work(hdev->workqueue, &hdev->cmd_sync_cancel_work); + wake_up_interruptible(&hdev->req_wait_q); } } -EXPORT_SYMBOL(hci_cmd_sync_cancel); +EXPORT_SYMBOL(hci_cmd_sync_cancel_sync); =20 /* Submit HCI command to be run in as cmd_sync_work: * diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index 7490092ccb2de..cc8efdc4ad431 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -1404,7 +1404,7 @@ static int set_powered(struct sock *sk, struct hci_de= v *hdev, void *data, =20 /* Cancel potentially blocking sync operation before power off */ if (cp->val =3D=3D 0x00) { - __hci_cmd_sync_cancel(hdev, -EHOSTDOWN); + hci_cmd_sync_cancel_sync(hdev, -EHOSTDOWN); err =3D hci_cmd_sync_queue(hdev, set_powered_sync, cmd, mgmt_set_powered_complete); } else { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A833617BB14; Sun, 24 Mar 2024 22:40:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320003; cv=none; b=pAca8v3Tzac1ScF1c/m7N9hiKXYKNtwjgbDY0OzMzefw08fhjM7i6cl8HZlNHI8ECn+SUYalqNFhQXibqxYiQcu8Di2VQYEjdRoETclhPL1WvUnvHIk+Z1NcErUCtOVvn6qNwI3w9KEiCZCqYJ7am6cD1ZJru+dPCdDPNvyNJOc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320003; c=relaxed/simple; bh=o1PrxWBeDcVkLBc9bFA7XtFajJXADeAu5yZGrI0gE4E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pUTwhTI+3uJN8BUluBvxc1f5s/xqIv1UyzOeyrVqZbZN7HhGth+0PZsAvtBpLSco502BBkL4awJdTjFK1YX2KyIJMxwtZ9V8ahnc0qwxx9L0yFUYfgJ381esTpmMfKzAZDGeCtYkFqpXF4dKLt/2CrOsCm6jJGckNIDo5yA30Jk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EwdCznYc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EwdCznYc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75B0AC433A6; Sun, 24 Mar 2024 22:40:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320003; bh=o1PrxWBeDcVkLBc9bFA7XtFajJXADeAu5yZGrI0gE4E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=EwdCznYc4kMxdPnHhEJOsrj3cT/7e7q9bMQSvOBuuUX08tCgmEhAvSMwRWmdjCozv jNrdLKWnM7ZLpgyY6bmQBwKC6s4D6hqF0kpQpCfRl7KOqhoNzflv9ZEElEiEjSg8lJ dHmTzPX51B66wZHvTLqHnR09a5quDt74jYEqGwBdmTOLLtjJBL0JbBDmwy0kFkWC8T /a7PB0yUAPSXWFDRRQxK71JoJXI5RMOtWfJSduwZlM6z+sqazOYMQErFAON/kee11u fhIbwLv0vkpiRJrsiUkUSocO9EHpBGjJXKmlsH2nkOFqhmkfm/0ABwBBzvXFKIQ49R QnaG6ZX70VhRg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 309/715] Bluetooth: hci_sync: Fix overwriting request callback Date: Sun, 24 Mar 2024 18:28:08 -0400 Message-ID: <20240324223455.1342824-310-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit 2615fd9a7c2507eb3be3fbe49dcec88a2f56454a ] In a few cases the stack may generate commands as responses to events which would happen to overwrite the sent_cmd, so this attempts to store the request in req_skb so even if sent_cmd is replaced with a new command the pending request will remain in stored in req_skb. Fixes: 6a98e3836fa2 ("Bluetooth: Add helper for serialized HCI command exec= ution") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- include/net/bluetooth/hci_core.h | 1 + net/bluetooth/hci_conn.c | 2 +- net/bluetooth/hci_core.c | 46 ++++++++++++++++++++++---------- net/bluetooth/hci_event.c | 18 ++++++------- net/bluetooth/hci_sync.c | 21 ++++++++++++--- 5 files changed, 61 insertions(+), 27 deletions(-) diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_c= ore.h index 8f8dd91737142..d1228857b1d0f 100644 --- a/include/net/bluetooth/hci_core.h +++ b/include/net/bluetooth/hci_core.h @@ -552,6 +552,7 @@ struct hci_dev { __u32 req_status; __u32 req_result; struct sk_buff *req_skb; + struct sk_buff *req_rsp; =20 void *smp_data; void *smp_bredr_data; diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c index fc4d72f83ac25..ba330114d38f7 100644 --- a/net/bluetooth/hci_conn.c +++ b/net/bluetooth/hci_conn.c @@ -3010,7 +3010,7 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason) case HCI_EV_LE_CONN_COMPLETE: case HCI_EV_LE_ENHANCED_CONN_COMPLETE: case HCI_EVT_LE_CIS_ESTABLISHED: - hci_cmd_sync_cancel(hdev, -ECANCELED); + hci_cmd_sync_cancel(hdev, ECANCELED); break; } } diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 539305b9a0e27..96707deef296b 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -1491,8 +1491,8 @@ static void hci_cmd_timeout(struct work_struct *work) struct hci_dev *hdev =3D container_of(work, struct hci_dev, cmd_timer.work); =20 - if (hdev->sent_cmd) { - u16 opcode =3D hci_skb_opcode(hdev->sent_cmd); + if (hdev->req_skb) { + u16 opcode =3D hci_skb_opcode(hdev->req_skb); =20 bt_dev_err(hdev, "command 0x%4.4x tx timeout", opcode); =20 @@ -2796,6 +2796,7 @@ void hci_release_dev(struct hci_dev *hdev) ida_destroy(&hdev->unset_handle_ida); ida_simple_remove(&hci_index_ida, hdev->id); kfree_skb(hdev->sent_cmd); + kfree_skb(hdev->req_skb); kfree_skb(hdev->recv_event); kfree(hdev); } @@ -3125,21 +3126,33 @@ int __hci_cmd_send(struct hci_dev *hdev, u16 opcode= , u32 plen, EXPORT_SYMBOL(__hci_cmd_send); =20 /* Get data from the previously sent command */ -void *hci_sent_cmd_data(struct hci_dev *hdev, __u16 opcode) +static void *hci_cmd_data(struct sk_buff *skb, __u16 opcode) { struct hci_command_hdr *hdr; =20 - if (!hdev->sent_cmd) + if (!skb || skb->len < HCI_COMMAND_HDR_SIZE) return NULL; =20 - hdr =3D (void *) hdev->sent_cmd->data; + hdr =3D (void *)skb->data; =20 if (hdr->opcode !=3D cpu_to_le16(opcode)) return NULL; =20 - BT_DBG("%s opcode 0x%4.4x", hdev->name, opcode); + return skb->data + HCI_COMMAND_HDR_SIZE; +} =20 - return hdev->sent_cmd->data + HCI_COMMAND_HDR_SIZE; +/* Get data from the previously sent command */ +void *hci_sent_cmd_data(struct hci_dev *hdev, __u16 opcode) +{ + void *data; + + /* Check if opcode matches last sent command */ + data =3D hci_cmd_data(hdev->sent_cmd, opcode); + if (!data) + /* Check if opcode matches last request */ + data =3D hci_cmd_data(hdev->req_skb, opcode); + + return data; } =20 /* Get data from last received event */ @@ -4040,17 +4053,19 @@ void hci_req_cmd_complete(struct hci_dev *hdev, u16= opcode, u8 status, if (!status && !hci_req_is_complete(hdev)) return; =20 + skb =3D hdev->req_skb; + /* If this was the last command in a request the complete - * callback would be found in hdev->sent_cmd instead of the + * callback would be found in hdev->req_skb instead of the * command queue (hdev->cmd_q). */ - if (bt_cb(hdev->sent_cmd)->hci.req_flags & HCI_REQ_SKB) { - *req_complete_skb =3D bt_cb(hdev->sent_cmd)->hci.req_complete_skb; + if (skb && bt_cb(skb)->hci.req_flags & HCI_REQ_SKB) { + *req_complete_skb =3D bt_cb(skb)->hci.req_complete_skb; return; } =20 - if (bt_cb(hdev->sent_cmd)->hci.req_complete) { - *req_complete =3D bt_cb(hdev->sent_cmd)->hci.req_complete; + if (skb && bt_cb(skb)->hci.req_complete) { + *req_complete =3D bt_cb(skb)->hci.req_complete; return; } =20 @@ -4167,8 +4182,11 @@ static void hci_send_cmd_sync(struct hci_dev *hdev, = struct sk_buff *skb) return; } =20 - if (hci_req_status_pend(hdev)) - hci_dev_set_flag(hdev, HCI_CMD_PENDING); + if (hci_req_status_pend(hdev) && + !hci_dev_test_and_set_flag(hdev, HCI_CMD_PENDING)) { + kfree_skb(hdev->req_skb); + hdev->req_skb =3D skb_clone(skb, GFP_KERNEL); + } =20 atomic_dec(&hdev->cmd_cnt); } diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index 9ee66b393981b..6275b14b56927 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -4381,7 +4381,7 @@ static void hci_cmd_status_evt(struct hci_dev *hdev, = void *data, * (since for this kind of commands there will not be a command * complete event). */ - if (ev->status || (hdev->sent_cmd && !hci_skb_event(hdev->sent_cmd))) { + if (ev->status || (hdev->req_skb && !hci_skb_event(hdev->req_skb))) { hci_req_cmd_complete(hdev, *opcode, ev->status, req_complete, req_complete_skb); if (hci_dev_test_flag(hdev, HCI_CMD_PENDING)) { @@ -7327,10 +7327,10 @@ static void hci_le_meta_evt(struct hci_dev *hdev, v= oid *data, bt_dev_dbg(hdev, "subevent 0x%2.2x", ev->subevent); =20 /* Only match event if command OGF is for LE */ - if (hdev->sent_cmd && - hci_opcode_ogf(hci_skb_opcode(hdev->sent_cmd)) =3D=3D 0x08 && - hci_skb_event(hdev->sent_cmd) =3D=3D ev->subevent) { - *opcode =3D hci_skb_opcode(hdev->sent_cmd); + if (hdev->req_skb && + hci_opcode_ogf(hci_skb_opcode(hdev->req_skb)) =3D=3D 0x08 && + hci_skb_event(hdev->req_skb) =3D=3D ev->subevent) { + *opcode =3D hci_skb_opcode(hdev->req_skb); hci_req_cmd_complete(hdev, *opcode, 0x00, req_complete, req_complete_skb); } @@ -7717,10 +7717,10 @@ void hci_event_packet(struct hci_dev *hdev, struct = sk_buff *skb) } =20 /* Only match event if command OGF is not for LE */ - if (hdev->sent_cmd && - hci_opcode_ogf(hci_skb_opcode(hdev->sent_cmd)) !=3D 0x08 && - hci_skb_event(hdev->sent_cmd) =3D=3D event) { - hci_req_cmd_complete(hdev, hci_skb_opcode(hdev->sent_cmd), + if (hdev->req_skb && + hci_opcode_ogf(hci_skb_opcode(hdev->req_skb)) !=3D 0x08 && + hci_skb_event(hdev->req_skb) =3D=3D event) { + hci_req_cmd_complete(hdev, hci_skb_opcode(hdev->req_skb), status, &req_complete, &req_complete_skb); req_evt =3D event; } diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c index 5236fe72a8553..684a6ac02b80d 100644 --- a/net/bluetooth/hci_sync.c +++ b/net/bluetooth/hci_sync.c @@ -32,6 +32,10 @@ static void hci_cmd_sync_complete(struct hci_dev *hdev, = u8 result, u16 opcode, hdev->req_result =3D result; hdev->req_status =3D HCI_REQ_DONE; =20 + /* Free the request command so it is not used as response */ + kfree_skb(hdev->req_skb); + hdev->req_skb =3D NULL; + if (skb) { struct sock *sk =3D hci_skb_sk(skb); =20 @@ -39,7 +43,7 @@ static void hci_cmd_sync_complete(struct hci_dev *hdev, u= 8 result, u16 opcode, if (sk) sock_put(sk); =20 - hdev->req_skb =3D skb_get(skb); + hdev->req_rsp =3D skb_get(skb); } =20 wake_up_interruptible(&hdev->req_wait_q); @@ -187,8 +191,8 @@ struct sk_buff *__hci_cmd_sync_sk(struct hci_dev *hdev,= u16 opcode, u32 plen, =20 hdev->req_status =3D 0; hdev->req_result =3D 0; - skb =3D hdev->req_skb; - hdev->req_skb =3D NULL; + skb =3D hdev->req_rsp; + hdev->req_rsp =3D NULL; =20 bt_dev_dbg(hdev, "end: err %d", err); =20 @@ -4836,6 +4840,11 @@ int hci_dev_open_sync(struct hci_dev *hdev) hdev->sent_cmd =3D NULL; } =20 + if (hdev->req_skb) { + kfree_skb(hdev->req_skb); + hdev->req_skb =3D NULL; + } + clear_bit(HCI_RUNNING, &hdev->flags); hci_sock_dev_event(hdev, HCI_DEV_CLOSE); =20 @@ -4996,6 +5005,12 @@ int hci_dev_close_sync(struct hci_dev *hdev) hdev->sent_cmd =3D NULL; } =20 + /* Drop last request */ + if (hdev->req_skb) { + kfree_skb(hdev->req_skb); + hdev->req_skb =3D NULL; + } + clear_bit(HCI_RUNNING, &hdev->flags); hci_sock_dev_event(hdev, HCI_DEV_CLOSE); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 095A617BB21; Sun, 24 Mar 2024 22:40:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320004; cv=none; b=PFcj9sGeUDEMERO0u3B6TPY6+vJghX0yAAR6c8BDaCc872+h59wz+Krgj1mzaXn/DWoO6FxYwrtxtz1UddZt50WenyEewAR05c9MPfsL2QGxYbi3G3WKqx9qkWXjjOioOctIwhDYtq8kdW+4/5H4+fQ6TH+zAdJZmpLc2n+QQKA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320004; c=relaxed/simple; bh=PUibFJzq8s1O50wIgMpnQ+UAHV1ejtQduBLCizncLr8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Pf+9ZSKZlpAboC/wtHg0XxNJxPYrTNJCLanif/wOx6eebhGwLKNxra1UgXaiEzADFr68TcKHI4/Y1X5+qgwA4FX/aiKH879hdnmUl1BaeJERNHO/JW7MGzjkpIw1jidza9ANEoiN+8vZx9F4rr1kDFV5eXbZyMvKKuweQuYZO8k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bU+70fyM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bU+70fyM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4661DC433C7; Sun, 24 Mar 2024 22:40:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320003; bh=PUibFJzq8s1O50wIgMpnQ+UAHV1ejtQduBLCizncLr8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bU+70fyMb7FJmPaXE6GMZv4dZGZmOGadIqtaFYll6EoaynJSePQbOJJYgblOOVJin YCN6i57W8SXJh9oBjQeEIwxZN58xBqwIh6y/oWaS30/YVLMBPo+JGQWfhd6oSs+Qkn kEYU7gFQCY0+j2pOUevssARahnDyxeRWkyd1Ysup7a3hHPCTH+rFdtKPAXwLC+TPbU AsKYzMIa+lo4AHrJPUc3xNs89KsVsdKwnMRRPFJ9XHu4y/Idocbcymbp37cSIoNntY /jLCJ+wwiSZyNd3lz9Q+meSd1uvnt6idsGbWBY2rw7qGcupOFsbpscB8bXTfvwXyKZ /UEOYMEwcubBA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrey Skvortsov , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 310/715] Bluetooth: hci_h5: Add ability to allocate memory for private data Date: Sun, 24 Mar 2024 18:28:09 -0400 Message-ID: <20240324223455.1342824-311-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrey Skvortsov [ Upstream commit 7a6d793e9ca8bc0c1d2f0aa0a02ec380d1124c74 ] In some cases uart-base drivers may need to use priv data. For example, to store information needed for devcoredump. Fixes: 044014ce85a1 ("Bluetooth: btrtl: Add Realtek devcoredump support") Signed-off-by: Andrey Skvortsov Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/bluetooth/hci_h5.c | 4 +++- drivers/bluetooth/hci_serdev.c | 9 +++++---- drivers/bluetooth/hci_uart.h | 12 +++++++++++- 3 files changed, 19 insertions(+), 6 deletions(-) diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c index 71e748a9477e4..b66136348bd64 100644 --- a/drivers/bluetooth/hci_h5.c +++ b/drivers/bluetooth/hci_h5.c @@ -113,6 +113,7 @@ struct h5_vnd { int (*suspend)(struct h5 *h5); int (*resume)(struct h5 *h5); const struct acpi_gpio_mapping *acpi_gpio_map; + int sizeof_priv; }; =20 struct h5_device_data { @@ -863,7 +864,8 @@ static int h5_serdev_probe(struct serdev_device *serdev) if (IS_ERR(h5->device_wake_gpio)) return PTR_ERR(h5->device_wake_gpio); =20 - return hci_uart_register_device(&h5->serdev_hu, &h5p); + return hci_uart_register_device_priv(&h5->serdev_hu, &h5p, + h5->vnd->sizeof_priv); } =20 static void h5_serdev_remove(struct serdev_device *serdev) diff --git a/drivers/bluetooth/hci_serdev.c b/drivers/bluetooth/hci_serdev.c index 39c8b567da3c0..214fff876eae5 100644 --- a/drivers/bluetooth/hci_serdev.c +++ b/drivers/bluetooth/hci_serdev.c @@ -300,8 +300,9 @@ static const struct serdev_device_ops hci_serdev_client= _ops =3D { .write_wakeup =3D hci_uart_write_wakeup, }; =20 -int hci_uart_register_device(struct hci_uart *hu, - const struct hci_uart_proto *p) +int hci_uart_register_device_priv(struct hci_uart *hu, + const struct hci_uart_proto *p, + int sizeof_priv) { int err; struct hci_dev *hdev; @@ -325,7 +326,7 @@ int hci_uart_register_device(struct hci_uart *hu, set_bit(HCI_UART_PROTO_READY, &hu->flags); =20 /* Initialize and register HCI device */ - hdev =3D hci_alloc_dev(); + hdev =3D hci_alloc_dev_priv(sizeof_priv); if (!hdev) { BT_ERR("Can't allocate HCI device"); err =3D -ENOMEM; @@ -394,7 +395,7 @@ int hci_uart_register_device(struct hci_uart *hu, percpu_free_rwsem(&hu->proto_lock); return err; } -EXPORT_SYMBOL_GPL(hci_uart_register_device); +EXPORT_SYMBOL_GPL(hci_uart_register_device_priv); =20 void hci_uart_unregister_device(struct hci_uart *hu) { diff --git a/drivers/bluetooth/hci_uart.h b/drivers/bluetooth/hci_uart.h index fb4a2d0d8cc80..68c8c7e95d64d 100644 --- a/drivers/bluetooth/hci_uart.h +++ b/drivers/bluetooth/hci_uart.h @@ -97,7 +97,17 @@ struct hci_uart { =20 int hci_uart_register_proto(const struct hci_uart_proto *p); int hci_uart_unregister_proto(const struct hci_uart_proto *p); -int hci_uart_register_device(struct hci_uart *hu, const struct hci_uart_pr= oto *p); + +int hci_uart_register_device_priv(struct hci_uart *hu, + const struct hci_uart_proto *p, + int sizeof_priv); + +static inline int hci_uart_register_device(struct hci_uart *hu, + const struct hci_uart_proto *p) +{ + return hci_uart_register_device_priv(hu, p, 0); +} + void hci_uart_unregister_device(struct hci_uart *hu); =20 int hci_uart_tx_wakeup(struct hci_uart *hu); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E05655C61D; Sun, 24 Mar 2024 22:40:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320005; cv=none; b=GUeCYMyvJXV4iDaSBHAjwqTCJZskGRjx/YzIl/HccghQrDFxkKLY4xHHdfYcLZnrJ/7CzJY54k3ZyLLDsXNASlAOT0ZntYWuIE/E6Xxh8f0WtBkB1mfPgkdTmpeUNdUkCgybNrknBsD2sPZf8dSsh6jQ6Xh8GodIuCk9idMQoQA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320005; c=relaxed/simple; bh=ZcHPGh/+6JRCBw+dWU/yC1PN20jUS9Kcv6f7ag8lQs8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=siZ1nJqIKJXWDwRle/x61geN2cbCzol5AR/8Z6bC3EP5VCnTr6vxPNlnMOFecdjb7TK8wa/eFKs6/DiL4g420iPcd7hC04HNINuCpW5Jx+jnd7Cktj5IKCkklbxD5vbYOUkGCMrEdQ21nQWRNu1Zn0zoY5fxc23buU68qoR9hUg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=foxhJHaO; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="foxhJHaO" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2B365C43394; Sun, 24 Mar 2024 22:40:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320004; bh=ZcHPGh/+6JRCBw+dWU/yC1PN20jUS9Kcv6f7ag8lQs8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=foxhJHaOMBNpX82v2PhLxuL6CBzgh/WSNwMyE4PaC0ttH5ApPrmp0kFiThmg3tQAK egoNx767jn2E0VtHIP0IEpGmp9FwVjYE1hFot3sp9XH2eIjbyTq7kyg/r183DRmpld F6N7N0XQIgFw9gK4jU3y/JYbBqaMI62DJNIueENh1rlYftGCiZhmy0TZaUCWKLbWH0 aid7af51IKbQD94FahFWm80stzhDL2O9L7/8uOENYZ5+ack9/FVx2elA14jpW16Mjg ejROp3G8AuvIKdYjLoE/YRKAJfGIWqcGrMZnv1IcbKXEXJlqv0iAfdBvXDjV5O5ymD 3FnEJEGAcibcw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Andrey Skvortsov , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 311/715] Bluetooth: btrtl: fix out of bounds memory access Date: Sun, 24 Mar 2024 18:28:10 -0400 Message-ID: <20240324223455.1342824-312-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Andrey Skvortsov [ Upstream commit de4e88ec58c4202efd1f02eebb4939bbf6945358 ] The problem is detected by KASAN. btrtl driver uses private hci data to store 'struct btrealtek_data'. If btrtl driver is used with btusb, then memory for private hci data is allocated in btusb. But no private data is allocated after hci_dev, when btrtl is used with hci_h5. This commit adds memory allocation for hci_h5 case. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BUG: KASAN: slab-out-of-bounds in btrtl_initialize+0x6cc/0x958 [btrtl] Write of size 8 at addr ffff00000f5a5748 by task kworker/u9:0/76 Hardware name: Pine64 PinePhone (1.2) (DT) Workqueue: hci0 hci_power_on [bluetooth] Call trace: dump_backtrace+0x9c/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x48/0x60 print_report+0xf8/0x5d8 kasan_report+0x90/0xd0 __asan_store8+0x9c/0xc0 [btrtl] h5_btrtl_setup+0xd0/0x2f8 [hci_uart] h5_setup+0x50/0x80 [hci_uart] hci_uart_setup+0xd4/0x260 [hci_uart] hci_dev_open_sync+0x1cc/0xf68 [bluetooth] hci_dev_do_open+0x34/0x90 [bluetooth] hci_power_on+0xc4/0x3c8 [bluetooth] process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Allocated by task 53: kasan_save_stack+0x3c/0x68 kasan_save_track+0x20/0x40 kasan_save_alloc_info+0x68/0x78 __kasan_kmalloc+0xd4/0xd8 __kmalloc+0x1b4/0x3b0 hci_alloc_dev_priv+0x28/0xa58 [bluetooth] hci_uart_register_device+0x118/0x4f8 [hci_uart] h5_serdev_probe+0xf4/0x178 [hci_uart] serdev_drv_probe+0x54/0xa0 really_probe+0x254/0x588 __driver_probe_device+0xc4/0x210 driver_probe_device+0x64/0x160 __driver_attach_async_helper+0x88/0x158 async_run_entry_fn+0xd0/0x388 process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Last potentially related work creation: kasan_save_stack+0x3c/0x68 __kasan_record_aux_stack+0xb0/0x150 kasan_record_aux_stack_noalloc+0x14/0x20 __queue_work+0x33c/0x960 queue_work_on+0x98/0xc0 hci_recv_frame+0xc8/0x1e8 [bluetooth] h5_complete_rx_pkt+0x2c8/0x800 [hci_uart] h5_rx_payload+0x98/0xb8 [hci_uart] h5_recv+0x158/0x3d8 [hci_uart] hci_uart_receive_buf+0xa0/0xe8 [hci_uart] ttyport_receive_buf+0xac/0x178 flush_to_ldisc+0x130/0x2c8 process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 Second to last potentially related work creation: kasan_save_stack+0x3c/0x68 __kasan_record_aux_stack+0xb0/0x150 kasan_record_aux_stack_noalloc+0x14/0x20 __queue_work+0x788/0x960 queue_work_on+0x98/0xc0 __hci_cmd_sync_sk+0x23c/0x7a0 [bluetooth] __hci_cmd_sync+0x24/0x38 [bluetooth] btrtl_initialize+0x760/0x958 [btrtl] h5_btrtl_setup+0xd0/0x2f8 [hci_uart] h5_setup+0x50/0x80 [hci_uart] hci_uart_setup+0xd4/0x260 [hci_uart] hci_dev_open_sync+0x1cc/0xf68 [bluetooth] hci_dev_do_open+0x34/0x90 [bluetooth] hci_power_on+0xc4/0x3c8 [bluetooth] process_one_work+0x328/0x6f0 worker_thread+0x410/0x778 kthread+0x168/0x178 ret_from_fork+0x10/0x20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fixes: 5b355944b190 ("Bluetooth: btrtl: Add btrealtek data struct") Fixes: 044014ce85a1 ("Bluetooth: btrtl: Add Realtek devcoredump support") Signed-off-by: Andrey Skvortsov Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/bluetooth/hci_h5.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c index b66136348bd64..c0436881a533c 100644 --- a/drivers/bluetooth/hci_h5.c +++ b/drivers/bluetooth/hci_h5.c @@ -1072,6 +1072,7 @@ static struct h5_vnd rtl_vnd =3D { .suspend =3D h5_btrtl_suspend, .resume =3D h5_btrtl_resume, .acpi_gpio_map =3D acpi_btrtl_gpios, + .sizeof_priv =3D sizeof(struct btrealtek_data), }; =20 static const struct h5_device_data h5_data_rtl8822cs =3D { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0C29617C6BF; Sun, 24 Mar 2024 22:40:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320006; cv=none; b=HcO4tGaPcCqjxW5Au5cyU46eGPHrFI+5UO1riEvvYwEAsNVUt9j8sWjBBgljvI0Dr1KmW2+lAI6ITYyMAtLWQexKWuTBw7aAeAZngWNvgP36P/aBvD/N+0OYliYo6FAiiHEiD9h8lLRHJu+x8iTaesgi8w+51XDBCd5VxsI8f5Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320006; c=relaxed/simple; bh=Ugg1J7IKQDMYXnCywrahvRSEfKqAl3Vln5nLujV8KfQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iPVDOvCceebkJUQDcCWB0HlWnm9ckQL64kV1jdcRJxGPJvpZ7tBk4fi7txsLW1G3iZkF6VgFOStHbRA7w9gNs9XtDHH3nhVSF+aZn3K7RlCmT8o+aPgYvbwd2euQMj6HptC9l4XIn0EZPyrZjMu3pzfq0KHTUsWOXMOOvZkbRfI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=fail (0-bit key) header.d=kernel.org header.i=@kernel.org header.b=I5TzMeFs reason="key not found in DNS"; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="key not found in DNS" (0-bit key) header.d=kernel.org header.i=@kernel.org header.b="I5TzMeFs" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 126A0C433F1; Sun, 24 Mar 2024 22:40:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320005; bh=Ugg1J7IKQDMYXnCywrahvRSEfKqAl3Vln5nLujV8KfQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I5TzMeFsJtoT3Im4TEpQLTctddumqFkAN3up8sHX/MBLiTLDPOpWLXLrbsDabWtyq SNoi5vGCIvp2ulKKugfTdxifn/x8ah7oKm/kJPnUbMxTytMugsqo0JejWCrBc5zDTi iOeH0nznx2ZGm3KDTDyi25EsJjCZzElAWMZmz4vcWhlIDhqewucMEQW4RJ1X0kDrzT UCJiDJXjFnZKwbEsL7AAWGDeyPYxIpnLDUPyNkYa4y2X+26aFh2Or8oS8mw1PG/JlZ cjda5dCkbzoRbjoj76hr690HH11GgRAeJoqiMmkhYIlH6x0Vl/4sUt34BG4uQQHz55 fydaGgrLFpVNw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 312/715] Bluetooth: hci_core: Fix possible buffer overflow Date: Sun, 24 Mar 2024 18:28:11 -0400 Message-ID: <20240324223455.1342824-313-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit 81137162bfaa7278785b24c1fd2e9e74f082e8e4 ] struct hci_dev_info has a fixed size name[8] field so in the event that hdev->name is bigger than that strcpy would attempt to write past its size, so this fixes this problem by switching to use strscpy. Fixes: dcda165706b9 ("Bluetooth: hci_core: Fix build warnings") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/bluetooth/hci_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 96707deef296b..85a91c438d721 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -908,7 +908,7 @@ int hci_get_dev_info(void __user *arg) else flags =3D hdev->flags; =20 - strcpy(di.name, hdev->name); + strscpy(di.name, hdev->name, sizeof(di.name)); di.bdaddr =3D hdev->bdaddr; di.type =3D (hdev->bus & 0x0f) | ((hdev->dev_type & 0x03) << 4); di.flags =3D flags; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C85CE17C6D7; Sun, 24 Mar 2024 22:40:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320006; cv=none; b=TdS4MH00xEe9XdlzFWz/zobs0XN7jTN6UWH/9H13zjO5er28qmpggu2xGPckvrgkZqzgWOk+37FF11O70CFGN6+RztSe5FqB7OJAewonol+ENDkDwvruQpJLczS9+I0KPWAS5CuEGpbVOgp5Q+UIZl939eZWbOwUCqKCrg+46OU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320006; c=relaxed/simple; bh=eZ8P3VvFJh8AOiFHtetE+vSb5xhTtJgCpVECyeF04SA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RVSXGhmnDUc6MgSFWNA8Ry1Pv8YeOTattN37ryBaOJfsLzHcO8//QAZyRzcKtCWaXqyr63UBd5wo4JhNuAMrzXXinHO+6/rft5R/aduH5//CbqpLzLzYUBcmLkQUXDS3a3VX0zFW/pWh7vfkqqiW+QSHS04GNUGfH0LQpT2EqTc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=c9li5U84; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="c9li5U84" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3B9BC43399; Sun, 24 Mar 2024 22:40:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320006; bh=eZ8P3VvFJh8AOiFHtetE+vSb5xhTtJgCpVECyeF04SA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=c9li5U84URkqNto81I00q47G6+N8Gcn4V8F7jYHos3fxnrTWv1rG4c/rvvDk+5X+J 8QrbHFAZkRRHww2kxECLGlrIvMN+cneheznxz6Ny+npZaj84fz7lZ0CbUnpIQ6Y0rT euAK4jqJDRjntj9vCSUXTdLxmuVRjwYmZMKOa42HxU9pFafOTS4Z2V8HVKVAj1IXTn IdDpwNd3w/+i8WTDI7V6Wt16wixJ3Ljk3dxBC/uQQIVjET2fKgSXawTIs4qpf4ChE1 xtYqm7OTPmpXSgKOwc/85O9v6Il9vUVptHY+nEtdSjEjf5g1vS2UZ9UCM10vMIPDU6 NNfw1ikRuZyWg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 313/715] Bluetooth: msft: Fix memory leak Date: Sun, 24 Mar 2024 18:28:12 -0400 Message-ID: <20240324223455.1342824-314-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit a6e06258f4c31eba0fcd503e19828b5f8fe7b08b ] Fix leaking buffer allocated to send MSFT_OP_LE_MONITOR_ADVERTISEMENT. Fixes: 9e14606d8f38 ("Bluetooth: msft: Extended monitor tracking by address= filter") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/bluetooth/msft.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/net/bluetooth/msft.c b/net/bluetooth/msft.c index 630e3023273b2..9612c5d1b13f6 100644 --- a/net/bluetooth/msft.c +++ b/net/bluetooth/msft.c @@ -875,6 +875,7 @@ static int msft_add_address_filter_sync(struct hci_dev = *hdev, void *data) remove =3D true; goto done; } + cp->sub_opcode =3D MSFT_OP_LE_MONITOR_ADVERTISEMENT; cp->rssi_high =3D address_filter->rssi_high; cp->rssi_low =3D address_filter->rssi_low; @@ -887,6 +888,8 @@ static int msft_add_address_filter_sync(struct hci_dev = *hdev, void *data) =20 skb =3D __hci_cmd_sync(hdev, hdev->msft_opcode, size, cp, HCI_CMD_TIMEOUT); + kfree(cp); + if (IS_ERR(skb)) { bt_dev_err(hdev, "Failed to enable address %pMR filter", &address_filter->bdaddr); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4DA7617D228; Sun, 24 Mar 2024 22:40:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320007; cv=none; b=powViEbk3gCVdEnWPcOrm+vHAQr6dICWUQ0zDKqGyNBWHt4B1Lfiv4fzvmznSHDclRQ/vaXLsxmuUjAj3w1/4VwfoEukHPgcu+d+r7KG+X0GHthkTDADP1TeK/2+aVFXRhpzZRhHN077RLLqjAwCyqR0z2ji8RoB22xJuJMcNcc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320007; c=relaxed/simple; bh=DJS3TGp3Td4MV9ZRjIwo5xMPi1BQTcb3/FYgdCrfEqo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cE2T0aPT+g6VhJZ5yeT0ce9vwbAM3JwCKDDRidggr2q5l4Lf+j4fsV9hECHjmTMMZGJSNsPQF+WEuy2AmPeLStYvp/gwlPR2sVv2u42I1pFpt4JamYQF81HId0GvTmE/AtEhbaioRpmq+5JeaSfwgK/YWxNLdB6WbRnxy/KvoCw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bi0wxxlm; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bi0wxxlm" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0E9CC433F1; Sun, 24 Mar 2024 22:40:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320007; bh=DJS3TGp3Td4MV9ZRjIwo5xMPi1BQTcb3/FYgdCrfEqo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bi0wxxlmbGD36mkdAwNw1jBoDGOeoGcC6n5ki994OZOOzY8ogBCSYqb1EFypREDxH hPqjXYSnKmmlwnoJgZ1bipySV/41oN5D1FSsd00xFA1nNiZ2AtMpccjIYzsaLlllGg BQKPdkEohIjGoTgrS2ty3OwoIqX3+wmRVC5yhUux+ocAnqnEonLSbU2FC08KFVXUq4 5lgL0CCJC6Sxkkfg7yTZZsXsBH6OTI5StFkFTL7+whlA4OObrfE0NgbmjbUnHf1HFa RAkinz3+MSVaax2I4/gHZyo6yAQbKGjGPrz6RWA94Dj3MGAXa6hbZzTmKw/WLOH5f4 PQDyPbIvbvtpw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 314/715] Bluetooth: btusb: Fix memory leak Date: Sun, 24 Mar 2024 18:28:13 -0400 Message-ID: <20240324223455.1342824-315-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit 79f4127a502c5905f04da1f20a7bbe07103fb77c ] This checks if CONFIG_DEV_COREDUMP is enabled before attempting to clone the skb and also make sure btmtk_process_coredump frees the skb passed following the same logic. Fixes: 0b7015132878 ("Bluetooth: btusb: mediatek: add MediaTek devcoredump = support") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/bluetooth/btmtk.c | 4 +++- drivers/bluetooth/btusb.c | 10 ++++++---- 2 files changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c index aaabb732082cd..285418dbb43f5 100644 --- a/drivers/bluetooth/btmtk.c +++ b/drivers/bluetooth/btmtk.c @@ -372,8 +372,10 @@ int btmtk_process_coredump(struct hci_dev *hdev, struc= t sk_buff *skb) struct btmediatek_data *data =3D hci_get_priv(hdev); int err; =20 - if (!IS_ENABLED(CONFIG_DEV_COREDUMP)) + if (!IS_ENABLED(CONFIG_DEV_COREDUMP)) { + kfree_skb(skb); return 0; + } =20 switch (data->cd_info.state) { case HCI_DEVCOREDUMP_IDLE: diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c index d31edad7a0560..6cb87d47ad7d5 100644 --- a/drivers/bluetooth/btusb.c +++ b/drivers/bluetooth/btusb.c @@ -3273,7 +3273,6 @@ static int btusb_recv_acl_mtk(struct hci_dev *hdev, s= truct sk_buff *skb) { struct btusb_data *data =3D hci_get_drvdata(hdev); u16 handle =3D le16_to_cpu(hci_acl_hdr(skb)->handle); - struct sk_buff *skb_cd; =20 switch (handle) { case 0xfc6f: /* Firmware dump from device */ @@ -3286,9 +3285,12 @@ static int btusb_recv_acl_mtk(struct hci_dev *hdev, = struct sk_buff *skb) * for backward compatibility, so we have to clone the packet * extraly for the in-kernel coredump support. */ - skb_cd =3D skb_clone(skb, GFP_ATOMIC); - if (skb_cd) - btmtk_process_coredump(hdev, skb_cd); + if (IS_ENABLED(CONFIG_DEV_COREDUMP)) { + struct sk_buff *skb_cd =3D skb_clone(skb, GFP_ATOMIC); + + if (skb_cd) + btmtk_process_coredump(hdev, skb_cd); + } =20 fallthrough; case 0x05ff: /* Firmware debug logging 1 */ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1BECA17D23D; Sun, 24 Mar 2024 22:40:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320008; cv=none; b=J+P3PTdiHD1ZtOahkO9WxOSA2FOeol+z9oqYePeD3XIUKy3rDMfCW5Odc+xjDda+j6ps2rbhIvc165MKs4V0ec7HsP4n5zmAurOchllYum+rCdqrbkpHIKCoej/2FEEfYwhqSbx1Ov+rTyLqZdXQ8vLuX6JPJ5j7yem2ZWZUM1I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320008; c=relaxed/simple; bh=8Mq+y2b4QoasCHiS9C0t/oVV7yRpu9gPxY4aigJk7HQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=vGOWTShb7N2HBBoxtORLH+ndwZZwaqKmx55hHOsWslxQG+HntHwErVqCl27M32upYsqL8sF8sgbm0/vS1UrU7nFpPcmFS1N0P/ueBjw2ot4gDcEOevTgdtDPTZSM7m3BEqHaJw4n/HIqAS7zQUVT4lhm8h772h/USTk5zrv1hZ0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hdLNKv+F; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hdLNKv+F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6FD2BC433A6; Sun, 24 Mar 2024 22:40:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320008; bh=8Mq+y2b4QoasCHiS9C0t/oVV7yRpu9gPxY4aigJk7HQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=hdLNKv+Fi6ObKyk/2ACijgBidyNUF2KE3YJA+uZZSWpDzzEPc3xlUYRCz2RfAcfoo aTuL3eHyJTHQPJD3c5OyX3q8zMcaoGdeuFxBiAfjBJOOisx46Fm+McPhbL6p/P9Mi4 wF9qkebJa+5JpM/Vhw9at2mIcjuA4TiAibmShK45T0B/6z3iZYRRh4vqNtyLJigLmS bgTA5a2xaw153hBzmGy8csPWjVI3f3UEpgA+AB8uCrxUN+nMRLzFPgsUVxL1UJGF2O LGdNgiwkLihA2u4v4nwmH/mvH7bFyN8ftS2/HMZSdc0ZSOnXSd9EBk38XpikT4abRh Ke5xFxU7UNCTA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 315/715] Bluetooth: af_bluetooth: Fix deadlock Date: Sun, 24 Mar 2024 18:28:14 -0400 Message-ID: <20240324223455.1342824-316-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Luiz Augusto von Dentz [ Upstream commit f7b94bdc1ec107c92262716b073b3e816d4784fb ] Attemting to do sock_lock on .recvmsg may cause a deadlock as shown bellow, so instead of using sock_sock this uses sk_receive_queue.lock on bt_sock_ioctl to avoid the UAF: INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183 Workqueue: hci0 hci_rx_work Call Trace: __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Fixes: 2e07e8348ea4 ("Bluetooth: af_bluetooth: Fix Use-After-Free in bt_soc= k_recvmsg") Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/bluetooth/af_bluetooth.c | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/net/bluetooth/af_bluetooth.c b/net/bluetooth/af_bluetooth.c index b93464ac3517f..67604ccec2f42 100644 --- a/net/bluetooth/af_bluetooth.c +++ b/net/bluetooth/af_bluetooth.c @@ -309,14 +309,11 @@ int bt_sock_recvmsg(struct socket *sock, struct msghd= r *msg, size_t len, if (flags & MSG_OOB) return -EOPNOTSUPP; =20 - lock_sock(sk); - skb =3D skb_recv_datagram(sk, flags, &err); if (!skb) { if (sk->sk_shutdown & RCV_SHUTDOWN) err =3D 0; =20 - release_sock(sk); return err; } =20 @@ -346,8 +343,6 @@ int bt_sock_recvmsg(struct socket *sock, struct msghdr = *msg, size_t len, =20 skb_free_datagram(sk, skb); =20 - release_sock(sk); - if (flags & MSG_TRUNC) copied =3D skblen; =20 @@ -570,10 +565,11 @@ int bt_sock_ioctl(struct socket *sock, unsigned int c= md, unsigned long arg) if (sk->sk_state =3D=3D BT_LISTEN) return -EINVAL; =20 - lock_sock(sk); + spin_lock(&sk->sk_receive_queue.lock); skb =3D skb_peek(&sk->sk_receive_queue); amount =3D skb ? skb->len : 0; - release_sock(sk); + spin_unlock(&sk->sk_receive_queue.lock); + err =3D put_user(amount, (int __user *)arg); break; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0567B131BA5; Sun, 24 Mar 2024 22:40:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320009; cv=none; b=qxqr6ZnHJL9NbdiUiP88AozMcSpwvCuxdnMfy7YwyJaF/heKQ08t8ooyXT87ZZFOoQ4AlIWhzX6Ykb0Kv6gPYmPDnPPRMccABGmv283ThgaL8KZ/JNe4OXv6jOJhn+PDBmycdaA/PxXijSNFSC6w6cl1oJKw+Ih/k+f8kwyIutQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320009; c=relaxed/simple; bh=CgppWVbYSdfdH7pUfBvvux86ej8YyJiAHOmFHrzmnXI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GHIheQECA/OzV1hxTqFJ81QT51zXXXuDhVPEYbWXJC7jnWz7jrEOkKkV01nXSVw3A+0anMaIc6J5NMiBiTjxNJMurHWC3+WSwR3xOD9gaijpI/GCncXVZD8/qRfZlxFzROmY0ME+k9JUmgcwa7GLH7orClWhy7Us6wSq7IlC08o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OSpdP+0F; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OSpdP+0F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E611C43399; Sun, 24 Mar 2024 22:40:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320008; bh=CgppWVbYSdfdH7pUfBvvux86ej8YyJiAHOmFHrzmnXI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OSpdP+0FgNnBsb84NNj+RV+ZAv5gway4REsNXF+EcXn7JVFEBNRavNMcZBIFsx4kE DQhuVPutO+3KdpwKKg5DohE48UlPWNn56uO3RksBbUcmqkcCbUUUr2WITz1ln/wrR0 frg+nI5PkYRpNxyfL2LeX7lyJdSpF6PEAaVek2P58gKkuuGBUteir99o7zOw9JPwzh GTsBGul+8qJ5T8DUuYduBhmDHzQ7F0yD9/ViQQmNJ+DQclRsP9lQNDHhGrseLnHFB+ wwan61Cwdf6gCSTOpQpNGqfcEzWx9wIlF1jVWo28ASqkPlZfQWG0iYLta5U/i0eZZT yEGGH7qk+Gcyw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Pauli Virtanen , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 316/715] Bluetooth: fix use-after-free in accessing skb after sending it Date: Sun, 24 Mar 2024 18:28:15 -0400 Message-ID: <20240324223455.1342824-317-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Pauli Virtanen [ Upstream commit 947ec0d002dce8577b655793dcc6fc78d67b7cb6 ] hci_send_cmd_sync first sends skb and then tries to clone it. However, the driver may have already freed the skb at that point. Fix by cloning the sent_cmd cloned just above, instead of the original. Log: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D BUG: KASAN: slab-use-after-free in __copy_skb_header+0x1a/0x240 ... Call Trace: .. __skb_clone+0x59/0x2c0 hci_cmd_work+0x3b3/0x3d0 [bluetooth] process_one_work+0x459/0x900 ... Allocated by task 129: ... __alloc_skb+0x1ae/0x220 __hci_cmd_sync_sk+0x44c/0x7a0 [bluetooth] __hci_cmd_sync_status+0x24/0xb0 [bluetooth] set_cig_params_sync+0x778/0x7d0 [bluetooth] ... Freed by task 0: ... kmem_cache_free+0x157/0x3c0 __usb_hcd_giveback_urb+0x11e/0x1e0 usb_giveback_urb_bh+0x1ad/0x2a0 tasklet_action_common.isra.0+0x259/0x4a0 __do_softirq+0x15b/0x5a7 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Fixes: 2615fd9a7c25 ("Bluetooth: hci_sync: Fix overwriting request callback= ") Signed-off-by: Pauli Virtanen Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/bluetooth/hci_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c index 85a91c438d721..7d5334b529834 100644 --- a/net/bluetooth/hci_core.c +++ b/net/bluetooth/hci_core.c @@ -4185,7 +4185,7 @@ static void hci_send_cmd_sync(struct hci_dev *hdev, s= truct sk_buff *skb) if (hci_req_status_pend(hdev) && !hci_dev_test_and_set_flag(hdev, HCI_CMD_PENDING)) { kfree_skb(hdev->req_skb); - hdev->req_skb =3D skb_clone(skb, GFP_KERNEL); + hdev->req_skb =3D skb_clone(hdev->sent_cmd, GFP_KERNEL); } =20 atomic_dec(&hdev->cmd_cnt); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 11D865C8FE; Sun, 24 Mar 2024 22:40:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320010; cv=none; b=OQN1RFRN9j2IgLNUHiHMSetXrMdS0BnU+QaTRb060HSHmH1MNJ6SPFTRdlOQ9L72zIZ5jCd+EaPo077BRRZJheDsx6Xe7hJhigkCdqwCt4pqUB0tR5ZBEW9iYO2U40up/cT/zLeYmvLtqbr2PyhnNFxpwEeiY0sbY3/SSsRrgUU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320010; c=relaxed/simple; bh=36c3PdCk3dmv9ATi1Ur1ycwjHJ3q6K33jYl8d79ERfA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=alYNFwntKb16zWvF4QltrjuR4Df1sdL7I0uYj0xzUs+vlbFwHrdzILK/Vie2qO/DtJ9uJk6wJDHx9IP2JeJ9oHeNfZ/ISVMfLb7eVBN8kquCNEdPBWo5qfDWpo+eiP0QqYfkCZS/tqPWzMBkc3e7ALGF4WIGIym6d8z+1FYTLA0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=feaTqofB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="feaTqofB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2773AC433F1; Sun, 24 Mar 2024 22:40:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320009; bh=36c3PdCk3dmv9ATi1Ur1ycwjHJ3q6K33jYl8d79ERfA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=feaTqofBFW+tTsRuBBb777SJH5+qCGCW6jfiAl257mXzabB7FeIckj50jBI2KQEZE gPw+UUhCj5/kEIUaXU64A6sdFWwUPmqf1Cwv7VH0Z7idsktZp0wSo4lgdZ2PSs1j3o wiPCKsBpMNhZ3lwhEuvArt4qd7EJYs05GKVPWUFCMdGOOzbJewPkcc7KBa+KidNWmN MihF4nH20FEpGgHmEXeVay7ZzO0dBToYOQAYv5IDKmaSvz7oBrEq5QjgGWFYc6Wcfx 6LrmiPkF3RYps9CejMBCUUaJkw/i/sjVs3YAkLLKhXCKjvDYIkh9/o+1/eSQ5tMVkr XGJUW80RCmWdQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chen Ni , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.8 317/715] sr9800: Add check for usbnet_get_endpoints Date: Sun, 24 Mar 2024 18:28:16 -0400 Message-ID: <20240324223455.1342824-318-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chen Ni [ Upstream commit 07161b2416f740a2cb87faa5566873f401440a61 ] Add check for usbnet_get_endpoints() and return the error if it fails in order to transfer the error. Signed-off-by: Chen Ni Reviewed-by: Simon Horman Fixes: 19a38d8e0aa3 ("USB2NET : SR9800 : One chip USB2.0 USB2NET SR9800 Dev= ice Driver Support") Link: https://lore.kernel.org/r/20240305075927.261284-1-nichen@iscas.ac.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/usb/sr9800.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/sr9800.c b/drivers/net/usb/sr9800.c index 143bd4ab160df..57947a5590cca 100644 --- a/drivers/net/usb/sr9800.c +++ b/drivers/net/usb/sr9800.c @@ -737,7 +737,9 @@ static int sr9800_bind(struct usbnet *dev, struct usb_i= nterface *intf) =20 data->eeprom_len =3D SR9800_EEPROM_LEN; =20 - usbnet_get_endpoints(dev, intf); + ret =3D usbnet_get_endpoints(dev, intf); + if (ret) + goto out; =20 /* LED Setting Rule : * AABB:CCDD --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C1E217E3BE; Sun, 24 Mar 2024 22:40:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320011; cv=none; b=LS5ISOLmWi7oABxEAf6Fk+7eVWqO+JJ7SWkW21JUtm+S95LCLQJy3ET7K4GeU63NJ9ZWm3mwDso0u6NKbuEm8q96YPMHsE/a8bVN4GLvl0Hi++5moK2vJhOgx8JtLce123hXdMBtSoD6Dvz6fBK+lcRB+YJUHBucG9oPxPqr2Gw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320011; c=relaxed/simple; bh=1CZXj3ZSEJhTLO9kDaryueK7/Emi8Jki56hPONpCagg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qoXzi2Iy+lMLLC1hPLvVWxyuWfxOiCHWesbPo8qpzo90+0EZc7YhgC0H36tk+Nfnj4zXeQc0nJtbWZhZDW3TKxEZMBR0S92hvJsprJchezhQRkM965KHZzPpJyWFOHvL2n++IE0rKj+3V5tOGP9V9wiu+RfF4fyoO4XSaH4eZVI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XVFlCH4J; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="XVFlCH4J" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 22C1CC43399; Sun, 24 Mar 2024 22:40:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320010; bh=1CZXj3ZSEJhTLO9kDaryueK7/Emi8Jki56hPONpCagg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=XVFlCH4JYFzjCzR8uV83P8aJuqM5HdhIOdDdn59rBK8xyui/rROnN90YErKwvUMZJ EPeORa0bXRBGMFTrDm57Wqzut4OxUQX51dQw0NLf1iZ0a8aq27qKnT7EyVRobd9fJW QRR1yXiidrv4tNI4uvDDJOpR1CgU0v/3BPasfSTOzrg2Vr4Avc4DV+5pa6yP2Rp1az iACtpE8ktKfWDqJScllXdaBFq7Zct3Av0vqp9dbFwmRndO9WMEZk78qEQJSmcaOBR8 sbmR+YW83Fo7YL8vkFLG6ZRpAH0k5+quVZKhspc396S9yXjIxSUHlbdsc1N451WasY qRiDzgLUgaKxw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Heiko Carstens , Sasha Levin Subject: [PATCH 6.8 318/715] s390/cache: prevent rebuild of shared_cpu_list Date: Sun, 24 Mar 2024 18:28:17 -0400 Message-ID: <20240324223455.1342824-319-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Heiko Carstens [ Upstream commit cb0cd4ee11142339f2d47eef6db274290b7a482d ] With commit 36bbc5b4ffab ("cacheinfo: Allow early detection and population of cache attributes") the shared cpu list for each cache level higher than L1 is rebuilt even if the list already has been set up. This is caused by the removal of the cpumask_empty() check within cache_shared_cpu_map_setup(). However architectures can enforce that the shared cpu list is not rebuilt by simply setting cpu_map_populated of the per cpu cache info structure to true, which is also the fix for this problem. Before: $ cat /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list 0-7 After: $ cat /sys/devices/system/cpu/cpu1/cache/index2/shared_cpu_list 1 Fixes: 36bbc5b4ffab ("cacheinfo: Allow early detection and population of ca= che attributes") Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- arch/s390/kernel/cache.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/s390/kernel/cache.c b/arch/s390/kernel/cache.c index 56254fa06f990..4f26690302209 100644 --- a/arch/s390/kernel/cache.c +++ b/arch/s390/kernel/cache.c @@ -166,5 +166,6 @@ int populate_cache_leaves(unsigned int cpu) ci_leaf_init(this_leaf++, pvt, ctype, level, cpu); } } + this_cpu_ci->cpu_map_populated =3D true; return 0; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C2F6A17E3D8; Sun, 24 Mar 2024 22:40:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320011; cv=none; b=cJux1mgNn82nFZpVLw+tJRPU9pKQUW7WNUrN4DRAgKbjdTh1NsXoqBiJgkdQTlfxwWaVWoTIOGZm1SAJ0pHjBB1qFAjPje86oInREoifD62hFX4mtlgmMVaGjR3OMCFJ3goaa3TseduLJdLcR5A+NJEe8dfchJbMchgYuLCD3QM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320011; c=relaxed/simple; bh=r+eUaeSBbJITi10eWBdwYxrKWd/L8nsqR8864q3AH38=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=nmG55iG2PERfhGgYfS3fbmZNSg8VtBI6N6UH+mVKrqS+CsjlWWEqz2eot/xnBaA6n4jtozyXaWY4Idkn5SFO9yLHeJUuCDsOP9AgDPF+14E6tafXlGRVPizLht55NoEqohlOfW6gO3pMnIqGiV3a/Wc6vtlMI4dRtsFxURwS9eE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZBIUPN88; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZBIUPN88" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E65B8C433F1; Sun, 24 Mar 2024 22:40:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320011; bh=r+eUaeSBbJITi10eWBdwYxrKWd/L8nsqR8864q3AH38=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ZBIUPN88vbzGf+jzen+vqUaRdWRqDwfVCuIfJ9YAYzUjmcO5jEUHgojcIGKq2Rg9x BQOi8SbJBcvDlD4kRdjg2oUGoZnpJ9xgwZYdvPvMw9MUN4RLRB+UNU96ixX0AW6VdS SuV6Kks/vBlm14aB9Kz5eC4/Sp0Noib/3SxMvH4AEqMWxOok/9XTdGfqUS6wrmRr1P Nv9or+K/0vdSrZt7vzg5STwx4mfPSWecy7osUYlksa6y0mPIgvRmPcfSE6Y/uKrNC+ a5yuew0h5HW59bgD1XrE9C7o/D1gUDRF5a3a9HbIV3IEhHkSxGSCBZ4EdVPLNcRtQx kj2pd4NJyrLHQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= , syzbot+8cd36f6b65f3cafd400a@syzkaller.appspotmail.com, Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 319/715] bpf: Fix DEVMAP_HASH overflow check on 32-bit arches Date: Sun, 24 Mar 2024 18:28:18 -0400 Message-ID: <20240324223455.1342824-320-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Toke H=C3=B8iland-J=C3=B8rgensen [ Upstream commit 281d464a34f540de166cee74b723e97ac2515ec3 ] The devmap code allocates a number hash buckets equal to the next power of two of the max_entries value provided when creating the map. When rounding up to the next power of two, the 32-bit variable storing the number of buckets can overflow, and the code checks for overflow by checking if the truncated 32-bit value is equal to 0. However, on 32-bit arches the rounding up itself can overflow mid-way through, because it ends up doing a left-shift of 32 bits on an unsigned long value. If the size of an unsigned long is four bytes, this is undefined behaviour, so there is no guarantee that we'll end up with a nice and tidy 0-value at the end. Syzbot managed to turn this into a crash on arm32 by creating a DEVMAP_HASH with max_entries > 0x80000000 and then trying to update it. Fix this by moving the overflow check to before the rounding up operation. Fixes: 6f9d451ab1a3 ("xdp: Add devmap_hash map type for looking up devices = by hashed index") Link: https://lore.kernel.org/r/000000000000ed666a0611af6818@google.com Reported-and-tested-by: syzbot+8cd36f6b65f3cafd400a@syzkaller.appspotmail.c= om Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen Message-ID: <20240307120340.99577-2-toke@redhat.com> Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/bpf/devmap.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c index a936c704d4e77..4e2cdbb5629f2 100644 --- a/kernel/bpf/devmap.c +++ b/kernel/bpf/devmap.c @@ -130,13 +130,14 @@ static int dev_map_init_map(struct bpf_dtab *dtab, un= ion bpf_attr *attr) bpf_map_init_from_attr(&dtab->map, attr); =20 if (attr->map_type =3D=3D BPF_MAP_TYPE_DEVMAP_HASH) { - dtab->n_buckets =3D roundup_pow_of_two(dtab->map.max_entries); - - if (!dtab->n_buckets) /* Overflow check */ + /* hash table size must be power of 2; roundup_pow_of_two() can + * overflow into UB on 32-bit arches, so check that first + */ + if (dtab->map.max_entries > 1UL << 31) return -EINVAL; - } =20 - if (attr->map_type =3D=3D BPF_MAP_TYPE_DEVMAP_HASH) { + dtab->n_buckets =3D roundup_pow_of_two(dtab->map.max_entries); + dtab->dev_index_head =3D dev_map_create_hash(dtab->n_buckets, dtab->map.numa_node); if (!dtab->dev_index_head) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 169B317EB75; Sun, 24 Mar 2024 22:40:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320013; cv=none; b=ePWh+c4ggvHDW7h1/OYgHC8hA/rzqBQ1DwRQowyErwt6Mq5kq+7cLebbTeBFQoGiWcYrpqKRtvU85keHxsbogIVG7z4SUpvqjIw19BZ+FTFr5j6VJMU5RvA/GtIBTT551GWuX71liFMxz1VoGvgHmSr2FU8bwnIqAuOIk9wHkIM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320013; c=relaxed/simple; bh=VIbvBBzSO6jB4GlKBMOGSPLMt75A1XyStIcCo4tKvWg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=UweUgPQebyXGQoBHAWWEPpgfHP2WgbUJKQdLJv+3YORT9BLd0iVdPYf1El0o66ZxzURxmbGtV3ar8ru3ICM9iQk+QUjHIEqboqOETq0G6IjFzPbIsiJq5i506GYJgbtWM1oiC6/UUzqORaR7oCKYnFa7I2h54zoffD5KY+Z6juA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GKq+934i; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GKq+934i" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E656BC433C7; Sun, 24 Mar 2024 22:40:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320012; bh=VIbvBBzSO6jB4GlKBMOGSPLMt75A1XyStIcCo4tKvWg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GKq+934i3IiQ0A8J9tY9mOkG5pnV0jxgxj7gMetSaaLUm+x5Be7BalSbO5w1szUwy GOSlr9vPC5OA6doJItwcjG0omRN5ZjehgQyOYOw2SRsXL8HONhs+HTckw09nW4uoZ4 Aq5hFL+yQjqbAxN/O5btp+BlS1GpML0haj8Pq7UugJoybbtqNS9OvpK1ctydQOcYPW XcJGphuoaSsKIzyGshkxRFiGDUTCMA21Ibo5ET2DquJ9pXa3VVhOrCYho+uoLkXC+S 7MvnRU6W0UaQxrkb210WHMaKypNd0S9WPsfo7Ilwng6LJMvpdjDIFNJsnQCXSZQHIh WRcBuRfRvcCQg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 320/715] bpf: Fix hashtab overflow check on 32-bit arches Date: Sun, 24 Mar 2024 18:28:19 -0400 Message-ID: <20240324223455.1342824-321-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Toke H=C3=B8iland-J=C3=B8rgensen [ Upstream commit 6787d916c2cf9850c97a0a3f73e08c43e7d973b1 ] The hashtab code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. So apply the same fix to hashtab, by moving the overflow check to before the roundup. Fixes: daaf427c6ab3 ("bpf: fix arraymap NULL deref and missing overflow and= zero size checks") Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen Message-ID: <20240307120340.99577-3-toke@redhat.com> Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/bpf/hashtab.c | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/kernel/bpf/hashtab.c b/kernel/bpf/hashtab.c index 03a6a2500b6ab..3a088a5349bc0 100644 --- a/kernel/bpf/hashtab.c +++ b/kernel/bpf/hashtab.c @@ -499,7 +499,13 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *= attr) num_possible_cpus()); } =20 - /* hash table size must be power of 2 */ + /* hash table size must be power of 2; roundup_pow_of_two() can overflow + * into UB on 32-bit arches, so check that first + */ + err =3D -E2BIG; + if (htab->map.max_entries > 1UL << 31) + goto free_htab; + htab->n_buckets =3D roundup_pow_of_two(htab->map.max_entries); =20 htab->elem_size =3D sizeof(struct htab_elem) + @@ -509,10 +515,8 @@ static struct bpf_map *htab_map_alloc(union bpf_attr *= attr) else htab->elem_size +=3D round_up(htab->map.value_size, 8); =20 - err =3D -E2BIG; - /* prevent zero size kmalloc and check for u32 overflow */ - if (htab->n_buckets =3D=3D 0 || - htab->n_buckets > U32_MAX / sizeof(struct bucket)) + /* check for u32 overflow */ + if (htab->n_buckets > U32_MAX / sizeof(struct bucket)) goto free_htab; =20 err =3D bpf_map_init_elem_count(&htab->map); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A795C17EB90; Sun, 24 Mar 2024 22:40:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320013; cv=none; b=gs9MFI9y3xxduPr2rtbMhFwYlZVRz6d5v1K07wjiKn2XAr8w1hXagosf9gA5FyH8iJ1N4icpFSQEPYIdkQxWlQo064736G3v+MbaXJxUUgvZY9BXeax7BJIPmSjqDTyKtGH6eEoWL8+N7GaXOqdwooFfKRp+REDqpfr3WcwNMN4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320013; c=relaxed/simple; bh=2hRt1La1a0cLNCTGH/9iSTwtq5WzHFv8P3BW3OtCK1U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jAto2Lvcz6PpWzPFT/Np8lQ3j7NKM0KVu6OTzVSxAAcKIbgAxkwEFs8iuvipaeMGuO5Wxgng3TDOAxnaDD7ya3nrs9JE7v83hq4ciyEgt56drdqwyspZCA3KvEzqVTGehUSgm6T3F0u4Xjkgdlt8I64aF5zIE6iHbHZnRn0Zfl0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FoO5OJZk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FoO5OJZk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD7EEC43390; Sun, 24 Mar 2024 22:40:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320013; bh=2hRt1La1a0cLNCTGH/9iSTwtq5WzHFv8P3BW3OtCK1U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FoO5OJZkyNNFRyj7qAvvCKYZUv+akDXKdAD9E56SSZBt9g7h1lHFzSsyxIRSg3upw fIrkgsbNRylDn5qBgCZ4+ART+0UaIyVvwHt52SE+Mn4KHGBPdtpWeB+Cf9AU90hzpp AzS5fzrZirbOf2gDjzILJLu+CtW5pRMFVN5cRqAbxRENPbo7NDVPxFH4pqPMX2KJMC /NdTyTQcQj+rEpOCXJuog1fEjCCtIyKDRjQ6WOfRNOTvGaZXQDN5gRiZX2XutTUdl7 Mlh8omMXreEF60u4X/fcX1qDcqfGPVGEeeSrGOxHNeXQ34y5c8fEV+g/loEfhvb2LL AxgwNkZck7xuw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Toke=20H=C3=B8iland-J=C3=B8rgensen?= , Bui Quang Minh , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 321/715] bpf: Fix stackmap overflow check on 32-bit arches Date: Sun, 24 Mar 2024 18:28:20 -0400 Message-ID: <20240324223455.1342824-322-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Toke H=C3=B8iland-J=C3=B8rgensen [ Upstream commit 7a4b21250bf79eef26543d35bd390448646c536b ] The stackmap code relies on roundup_pow_of_two() to compute the number of hash buckets, and contains an overflow check by checking if the resulting value is 0. However, on 32-bit arches, the roundup code itself can overflow by doing a 32-bit left-shift of an unsigned long value, which is undefined behaviour, so it is not guaranteed to truncate neatly. This was triggered by syzbot on the DEVMAP_HASH type, which contains the same check, copied from the hashtab code. The commit in the fixes tag actually attempted to fix this, but the fix did not account for the UB, so the fix only works on CPUs where an overflow does result in a neat truncation to zero, which is not guaranteed. Checking the value before rounding does not have this problem. Fixes: 6183f4d3a0a2 ("bpf: Check for integer overflow when using roundup_po= w_of_two()") Signed-off-by: Toke H=C3=B8iland-J=C3=B8rgensen Reviewed-by: Bui Quang Minh Message-ID: <20240307120340.99577-4-toke@redhat.com> Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/bpf/stackmap.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/kernel/bpf/stackmap.c b/kernel/bpf/stackmap.c index dff7ba5397015..c99f8e5234ac4 100644 --- a/kernel/bpf/stackmap.c +++ b/kernel/bpf/stackmap.c @@ -91,11 +91,14 @@ static struct bpf_map *stack_map_alloc(union bpf_attr *= attr) } else if (value_size / 8 > sysctl_perf_event_max_stack) return ERR_PTR(-EINVAL); =20 - /* hash table size must be power of 2 */ - n_buckets =3D roundup_pow_of_two(attr->max_entries); - if (!n_buckets) + /* hash table size must be power of 2; roundup_pow_of_two() can overflow + * into UB on 32-bit arches, so check that first + */ + if (attr->max_entries > 1UL << 31) return ERR_PTR(-E2BIG); =20 + n_buckets =3D roundup_pow_of_two(attr->max_entries); + cost =3D n_buckets * sizeof(struct stack_map_bucket *) + sizeof(*smap); smap =3D bpf_map_area_alloc(cost, bpf_map_attr_numa_node(attr)); if (!smap) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E30017F362; Sun, 24 Mar 2024 22:40:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320014; cv=none; b=McJuwx8tSYlnJSQxCcs1j7tR9WqlFdazpp2VtG7sVRvZOLhomhLrFqg3BgPOIMhsFhZnMDL5DWrxGVd9pnV89frHuf7PI/K0z6HF5XnWY6TDeMyy+MIo3tjMP86p5mlIMoMQcbdzxpdokNrdyjcjReRGx4awDgDReHgB4nlHI60= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320014; c=relaxed/simple; bh=57sDBaEV7+i6YJcxG9jMYmtxVdI50Z1CD7GMNvOrjIY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cD4SXCZPOTh5lYmu/VXKx0C2XWEIFnjd/u2nSet7RggwspuQqIoKdctWDd9cuRT7Lyc/OnUS1yB+jT/4Y5twYCdodxagtFfJtvfcflwUiO5c7IMgE3wByuhdB3gloanCfarDQ+S/EwJFBDJZAZGHwfNIUBK8S0DHmK6l0ypMw6c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MYBrp0tU; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MYBrp0tU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9D8FC43399; Sun, 24 Mar 2024 22:40:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320014; bh=57sDBaEV7+i6YJcxG9jMYmtxVdI50Z1CD7GMNvOrjIY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MYBrp0tUHruqe1CbkBI1rszUgJE5vmVAS6hnPKk1g684KHo9aihvj+y0etj4KrCOS 6Tb3vwih1216Q0eIE9E2S9tmQr94NC6O8rJzgeGj1wKjUXx8Ye2REl1D1u2BH8VF5K l+VijeZwt1QZs8GSBAILKX73IGg7AIXbuGOJx4Rrw9I3x82kmPEuuHyhrPyONng49N Cjd2UP2i9PNDJNjEgkmtNDIVKgEF4ZZQHfda8EuBO16yYa/5XR3h/zEZCX9cIfVF5N 9ovbaaXhwdJ5W2dLwQhazyhNKTyl8JSlSmkSpCu6cev0jMtBIbHCRYDJpmmNr0+qM1 KWuqEmjKtyoCw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Oleksij Rempel , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.8 322/715] net: dsa: microchip: make sure drive strength configuration is not lost by soft reset Date: Sun, 24 Mar 2024 18:28:21 -0400 Message-ID: <20240324223455.1342824-323-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Oleksij Rempel [ Upstream commit e3fb8e8ba72b053d05ca2602acdd6b869f9f296f ] This driver has two separate reset sequence in different places: - gpio/HW reset on start of ksz_switch_register() - SW reset on start of ksz_setup() The second one will overwrite drive strength configuration made in the ksz_switch_register(). To fix it, move ksz_parse_drive_strength() from ksz_switch_register() to ksz_setup(). Fixes: d67d7247f641 ("net: dsa: microchip: Add drive strength configuration= ") Signed-off-by: Oleksij Rempel Link: https://lore.kernel.org/r/20240304135612.814404-1-o.rempel@pengutroni= x.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/dsa/microchip/ksz_common.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/micro= chip/ksz_common.c index 245dfb7a7a315..25a49708f4842 100644 --- a/drivers/net/dsa/microchip/ksz_common.c +++ b/drivers/net/dsa/microchip/ksz_common.c @@ -2185,6 +2185,8 @@ static int ksz_pirq_setup(struct ksz_device *dev, u8 = p) return ksz_irq_common_setup(dev, pirq); } =20 +static int ksz_parse_drive_strength(struct ksz_device *dev); + static int ksz_setup(struct dsa_switch *ds) { struct ksz_device *dev =3D ds->priv; @@ -2206,6 +2208,10 @@ static int ksz_setup(struct dsa_switch *ds) return ret; } =20 + ret =3D ksz_parse_drive_strength(dev); + if (ret) + return ret; + /* set broadcast storm protection 10% rate */ regmap_update_bits(ksz_regmap_16(dev), regs[S_BROADCAST_CTRL], BROADCAST_STORM_RATE, @@ -4242,10 +4248,6 @@ int ksz_switch_register(struct ksz_device *dev) for (port_num =3D 0; port_num < dev->info->port_cnt; ++port_num) dev->ports[port_num].interface =3D PHY_INTERFACE_MODE_NA; if (dev->dev->of_node) { - ret =3D ksz_parse_drive_strength(dev); - if (ret) - return ret; - ret =3D of_get_phy_mode(dev->dev->of_node, &interface); if (ret =3D=3D 0) dev->compat_interface =3D interface; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C2B5017F38F; Sun, 24 Mar 2024 22:40:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320015; cv=none; b=HrbC2+I8bwXlr+1rm9CclsNdf85OROmuRUTr3CEkfGLW7qS4RnhSA4WoyQZPZBX1km1240eQ0VEpnuYZffj7qI+yeLQ1ZEF4M5XeUQGd0Njz0jhCvFPmdHJWKiC+jun/f5eLOCL9IAk1g7z/RMPTiDnWm6KLvZXEvhjTuMM5w50= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320015; c=relaxed/simple; bh=xFqGKpyx47Kh25uyLbApAyioWas3r0gmrmDyV1O32aU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WEEz0qVRlEItBY4hd2ZmHhwjuXpoKZ6LMKao448F74tHxeWQEh9Rd6ZEruaxI2kaby2Y+IUlIjWKZ3RR+ht1wSU5FYK7wggr+S7JTFNNmRCMEbVSwjC9l3xeJy7ZIlmj5AUF6hLRNvQ5YwJZM2kURdk988CvbOR3lS9rlAH5stc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ha5vsQVj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ha5vsQVj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2C48C433C7; Sun, 24 Mar 2024 22:40:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320015; bh=xFqGKpyx47Kh25uyLbApAyioWas3r0gmrmDyV1O32aU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ha5vsQVjhUJAKfSGUq3hOk1dFclMFVpuHvV9/zhhqHhFJPjMY6j3oZJ9zWECY8wx4 yz4ChDdfJZYgZXYuGQqchxhcV0dr5pZLguyWudBjAP6nL+RhmxrjUIENyVKosK9b2b AQiTsiWILwpKQlrMGQ1WXq7lbkleo4c5mMHDSexbe4YZ7otcqkOVqAroS9KtCfUHSX pZklloPiCbSQ56ZJrurwyRKr+TBRrFGjks/dmNNu2jt1WrrhwkdHWCKT9+LRkXZf7q 1ste+galcrPZBY9zdCg/+RbdAT76Kui5JsLcu94xW62umtfAmI//fZTavOhEy9zJcL 2c9hoTXnApzXA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jiri Pirko , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.8 323/715] dpll: spec: use proper enum for pin capabilities attribute Date: Sun, 24 Mar 2024 18:28:22 -0400 Message-ID: <20240324223455.1342824-324-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jiri Pirko [ Upstream commit 5c497a64820ef9f10962a9c37607df45d6395fa5 ] The enum is defined, however the pin capabilities attribute does refer to it. Add this missing enum field. This fixes ynl cli output: Example current output: $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml = --do pin-get --json '{"id": 0}' {'capabilities': 4, ... Example new output: $ sudo ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml = --do pin-get --json '{"id": 0}' {'capabilities': {'state-can-change'}, ... Fixes: 3badff3a25d8 ("dpll: spec: Add Netlink spec in YAML") Signed-off-by: Jiri Pirko Reviewed-by: Jakub Kicinski Link: https://lore.kernel.org/r/20240306120739.1447621-1-jiri@resnulli.us Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- Documentation/netlink/specs/dpll.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/netlink/specs/dpll.yaml b/Documentation/netlink/= specs/dpll.yaml index 3dcc9ece272aa..d0c821c202036 100644 --- a/Documentation/netlink/specs/dpll.yaml +++ b/Documentation/netlink/specs/dpll.yaml @@ -274,6 +274,7 @@ attribute-sets: - name: capabilities type: u32 + enum: pin-capabilities - name: parent-device type: nest --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7098317EB82; Sun, 24 Mar 2024 22:40:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320016; cv=none; b=Qm3rkXIlvR3vxi/A5xptE5haJosCLHykg5iNGiZatosWxZiQYZKOCssLD1tnk6tUeYz18blEm82nDv1J+dpIp23bMkcn9lk31S2I0dehHwA1ExS9IshOjXdP3BmOcPjyQg0KeO/SRCXkmSWEAAptfcb8iYoiZ3kMPOyYfdP424w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320016; c=relaxed/simple; bh=b7ejtDltFIu6hTTp3AUM0Hnm/ru5scpjy7t1uf24Ek4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HLAqpkya/KXeTzO5vhRns/4wyQ6c2kA3gv6MKwYJrPFxLbaDA4Fj7uL/+eYFnmzbfnyIphI/RHzb2deAbLirfCfxAZpoUryW6ImlBzZg+kvQfFsqbstEnqahvmxoWI9/pkEbJsk/h+tIXoA4O2gGAXZ9O3G8+D02nE5cpPew6g4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WuyHl2oQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WuyHl2oQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B66DC43399; Sun, 24 Mar 2024 22:40:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320016; bh=b7ejtDltFIu6hTTp3AUM0Hnm/ru5scpjy7t1uf24Ek4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WuyHl2oQZ8pqKcRhXCmHAs+zDXEpq9sf5gHn0go/c8TflszLeltD1pwprJ3+EAC04 r7lrjJ2R50Mudgs+ReQbKxjquRXkwdofncx8gB1brFAoz0n0MBQYdsQTOyA3xXj/NM S/pmbBuAZmYuRaRblQ+YD56OFh7p4eNyixFjyFMEdMPwB7f5AdiQ51qrJXZsuu+t1Z wTkXLmiRFidvS/lAzvpxp5pQVFeqCQqu+9ubWnNdG0lcRHNL0HXYvKoxa/3zZJyB2k g63NbpmZZMePD0P/P5D7zHsSeLcStdnyfAKjl9/BvlJHX6xA+zz7Tn33erEpFeu4fk yrePC+Pvv3BWw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bert Karwatzki , Lu Baolu , Joerg Roedel , Sasha Levin Subject: [PATCH 6.8 324/715] iommu: Fix compilation without CONFIG_IOMMU_INTEL Date: Sun, 24 Mar 2024 18:28:23 -0400 Message-ID: <20240324223455.1342824-325-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Bert Karwatzki [ Upstream commit 70bad345e622c23bb530016925c936ab04a646ac ] When the kernel is comiled with CONFIG_IRQ_REMAP=3Dy but without CONFIG_IOMMU_INTEL compilation fails since commit def054b01a8678 with an undefined reference to device_rbtree_find(). This patch makes sure that intel specific code is only compiled with CONFIG_IOMMU_INTEL=3Dy. Signed-off-by: Bert Karwatzki Fixes: 80a9b50c0b9e ("iommu/vt-d: Improve ITE fault handling if target dev= ice isn't present") Reviewed-by: Lu Baolu Link: https://lore.kernel.org/r/20240307194419.15801-1-spasswolf@web.de Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/iommu/Kconfig | 2 +- drivers/iommu/intel/Makefile | 2 ++ drivers/iommu/irq_remapping.c | 3 ++- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index 9a29d742617e3..9dbb55e745bd9 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -196,7 +196,7 @@ source "drivers/iommu/iommufd/Kconfig" config IRQ_REMAP bool "Support for Interrupt Remapping" depends on X86_64 && X86_IO_APIC && PCI_MSI && ACPI - select DMAR_TABLE + select DMAR_TABLE if INTEL_IOMMU help Supports Interrupt remapping for IO-APIC and MSI devices. To use x2apic mode in the CPU's which support x2APIC enhancements or diff --git a/drivers/iommu/intel/Makefile b/drivers/iommu/intel/Makefile index 5dabf081a7793..5402b699a1229 100644 --- a/drivers/iommu/intel/Makefile +++ b/drivers/iommu/intel/Makefile @@ -5,5 +5,7 @@ obj-$(CONFIG_DMAR_TABLE) +=3D trace.o cap_audit.o obj-$(CONFIG_DMAR_PERF) +=3D perf.o obj-$(CONFIG_INTEL_IOMMU_DEBUGFS) +=3D debugfs.o obj-$(CONFIG_INTEL_IOMMU_SVM) +=3D svm.o +ifdef CONFIG_INTEL_IOMMU obj-$(CONFIG_IRQ_REMAP) +=3D irq_remapping.o +endif obj-$(CONFIG_INTEL_IOMMU_PERF_EVENTS) +=3D perfmon.o diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c index 83314b9d8f38b..ee59647c20501 100644 --- a/drivers/iommu/irq_remapping.c +++ b/drivers/iommu/irq_remapping.c @@ -99,7 +99,8 @@ int __init irq_remapping_prepare(void) if (disable_irq_remap) return -ENOSYS; =20 - if (intel_irq_remap_ops.prepare() =3D=3D 0) + if (IS_ENABLED(CONFIG_INTEL_IOMMU) && + intel_irq_remap_ops.prepare() =3D=3D 0) remap_ops =3D &intel_irq_remap_ops; else if (IS_ENABLED(CONFIG_AMD_IOMMU) && amd_iommu_irq_ops.prepare() =3D=3D 0) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DFD9813C830; Sun, 24 Mar 2024 22:40:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320018; cv=none; b=UEhOgKao/FgvPpXZiIhSiEf62kMCYUknlP5Wb82uOIwURuGCtLPCWscM+fBdAHcAU2mWKoRIudP9rptp9x5/XBCcdxczxqIny0jgUAPx54N3wOtfL2yOPKrhh2d3mPsC4j/g8YZdXjfbkH/5f4PfSP3y2pfFHAWv7j4h5tQQuJE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320018; c=relaxed/simple; bh=eH0vhInP9O3buHkVrLjIuiVn8EvjiIiqgfKW7ScCJVE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=afGpopiv3GYEGnaJ3j9ltRI/3ULuh3mGfiuV/Q8Kygz6LyEMT7jRTSivNpiQ5zcxw5vM7YtTJcuRyIaPRIv0pZPdszESP914ltZmKMKTydtkhjUGi3Z5J6K1SfawIVNZs9DqQ2VLxqTBL3BgFIuQAfjsOoWK7m9w4EwFwQV2Fvs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PTc0FlSN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PTc0FlSN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 938D2C433C7; Sun, 24 Mar 2024 22:40:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320017; bh=eH0vhInP9O3buHkVrLjIuiVn8EvjiIiqgfKW7ScCJVE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PTc0FlSNYyrVKXU9FFcy4Zp9BY/vOH9yx6Pr8B90yWPYwWlkBQ2K5hBSIJQ3vmhko t4wigHqcQBEfnw/FnEhvWlBKlSqERSmdsPecadspG9w9tEQTJfvQ83xAT6vN9zR0Ds 4TcHkS1HG0G3rZPP3TytcbwA2fvxg1cbe27X2v7WSDc6ypLKMsKjAznOkhUCxRvHDk dGeXxc4+HI6IvIwurDM7KEkOtFyWJdcnw6BrVISOHPN4aMUC57wgaD5h2JK6lyypZY rEt3hxCu7AOfmm42RYLFmI0s0LTY2fM2TqTOUyBLoJI7XtGpnPFrmbXLTB2P0Dhkut 4Wo62UzDvMqYw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Shiming Cheng , Lena Wang , David Ahern , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 325/715] ipv6: fib6_rules: flush route cache when rule is changed Date: Sun, 24 Mar 2024 18:28:24 -0400 Message-ID: <20240324223455.1342824-326-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Shiming Cheng [ Upstream commit c4386ab4f6c600f75fdfd21143f89bac3e625d0d ] When rule policy is changed, ipv6 socket cache is not refreshed. The sock's skb still uses a outdated route cache and was sent to a wrong interface. To avoid this error we should update fib node's version when rule is changed. Then skb's route will be reroute checked as route cache version is already different with fib node version. The route cache is refreshed to match the latest rule. Fixes: 101367c2f8c4 ("[IPV6]: Policy Routing Rules") Signed-off-by: Shiming Cheng Signed-off-by: Lena Wang Reviewed-by: David Ahern Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/ipv6/fib6_rules.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/ipv6/fib6_rules.c b/net/ipv6/fib6_rules.c index 7523c4baef35e..52c04f0ac4981 100644 --- a/net/ipv6/fib6_rules.c +++ b/net/ipv6/fib6_rules.c @@ -449,6 +449,11 @@ static size_t fib6_rule_nlmsg_payload(struct fib_rule = *rule) + nla_total_size(16); /* src */ } =20 +static void fib6_rule_flush_cache(struct fib_rules_ops *ops) +{ + rt_genid_bump_ipv6(ops->fro_net); +} + static const struct fib_rules_ops __net_initconst fib6_rules_ops_template = =3D { .family =3D AF_INET6, .rule_size =3D sizeof(struct fib6_rule), @@ -461,6 +466,7 @@ static const struct fib_rules_ops __net_initconst fib6_= rules_ops_template =3D { .compare =3D fib6_rule_compare, .fill =3D fib6_rule_fill, .nlmsg_payload =3D fib6_rule_nlmsg_payload, + .flush_cache =3D fib6_rule_flush_cache, .nlgroup =3D RTNLGRP_IPV6_RULE, .owner =3D THIS_MODULE, .fro_net =3D &init_net, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8A44228EB; Sun, 24 Mar 2024 22:40:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320018; cv=none; b=n8SLYNM5/I5jQ4+AkJsFPMbMi9TF/JdJZ9CcGhMlAlLCOJLxcm0Q26Am4frIP2EqaBVlzJvdDloUJiJVvmygOhSlrt5+m78RaG//PwIMoB/rDnNAwJKr2znFQmtvuEPQ97/3YEeqy6TBGnmcwlWYfq+cqtN+a2CgdaS00oS27SI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320018; c=relaxed/simple; bh=p3pO7s0QZU7G2V1xi9YzeCaI/B/Meok2VFkoX4U835o=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TphGBcOhj4M1+Bf14nFIkPfDRS8w7XR7o7hcSuLlICETo/FbgZLC6dKXHZ/zHPUh8aCYADOVQBlZXcYpuhYQKB1Ei2S/IbRY/THu0k45O+xqmz6+Pn5XAGZ0go2N+jeZYdJYD6AjsA4pdtFfXcm9ro194GLct/hejWIj6G7jXew= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uXPD0spT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uXPD0spT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ABA7FC433F1; Sun, 24 Mar 2024 22:40:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320018; bh=p3pO7s0QZU7G2V1xi9YzeCaI/B/Meok2VFkoX4U835o=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uXPD0spTllCJIKHS4D2x/ePCy3Lhgx5mtzUi+ZUMxgXetcoR6Hx/d8sp/PHE/5P8U XGXl+Jg2wys4atTm89NaU1Ut4Ifoe+tX7BhzUefU9cxghXGHvTvjRvBxOc0ANDu3Co cvwehs+l8P1tnzNiDYIqvL3aIW1xHRP+JdyLQZeWIQ8Vz586slFywE4p3Dve1z/X9Z o7dVrBKWpIyLkCXpRVkRyXumMGukIi4PF07PRuKgvDIU4ZJ2jugosn5+lATQCDbXiH /BORUolstD1nfgrVzqZ6AvlVVx2g44T9Qydv0+zncMC7eW/FC2v/iCZWjk2c2WdhFc v8V2a/E2ATnsg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Eric Dumazet , syzbot , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 326/715] net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv() Date: Sun, 24 Mar 2024 18:28:25 -0400 Message-ID: <20240324223455.1342824-327-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Eric Dumazet [ Upstream commit b0ec2abf98267f14d032102551581c833b0659d3 ] Apply the same fix than ones found in : 8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv(= )") 1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()") We have to save skb->network_header in a temporary variable in order to be able to recompute the network_header pointer after a pskb_inet_may_pull() call. pskb_inet_may_pull() makes sure the needed headers are in skb->head. syzbot reported: BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:2= 53 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:27= 5 [inline] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 = [inline] BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.= c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [inline] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5793 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [inline] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.") Reported-by: syzbot Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/ipv4/ip_tunnel.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c index 1b6981de3f295..7af36e4f1647d 100644 --- a/net/ipv4/ip_tunnel.c +++ b/net/ipv4/ip_tunnel.c @@ -378,7 +378,7 @@ int ip_tunnel_rcv(struct ip_tunnel *tunnel, struct sk_b= uff *skb, bool log_ecn_error) { const struct iphdr *iph =3D ip_hdr(skb); - int err; + int nh, err; =20 #ifdef CONFIG_NET_IPGRE_BROADCAST if (ipv4_is_multicast(iph->daddr)) { @@ -404,8 +404,21 @@ int ip_tunnel_rcv(struct ip_tunnel *tunnel, struct sk_= buff *skb, tunnel->i_seqno =3D ntohl(tpi->seq) + 1; } =20 + /* Save offset of outer header relative to skb->head, + * because we are going to reset the network header to the inner header + * and might change skb->head. + */ + nh =3D skb_network_header(skb) - skb->head; + skb_set_network_header(skb, (tunnel->dev->type =3D=3D ARPHRD_ETHER) ? ETH= _HLEN : 0); =20 + if (!pskb_inet_may_pull(skb)) { + DEV_STATS_INC(tunnel->dev, rx_length_errors); + DEV_STATS_INC(tunnel->dev, rx_errors); + goto drop; + } + iph =3D (struct iphdr *)(skb->head + nh); + err =3D IP_ECN_decapsulate(iph, skb); if (unlikely(err)) { if (log_ecn_error) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C467D1802CB; Sun, 24 Mar 2024 22:40:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320019; cv=none; b=mRY7q68liLE+lWcKQsodp+VISsQf4xZDCcrY3ohZDpjLrrOyGPTXuAMAOxI8D/Ahkqt8f+fOKEWxJ08GFpvK6k2ilVLqlulmnbtTWAQHW2ejjYLSV4G2MRS2z061dDJify12WfOp48J0frqFTHS8pctHW55N5zg4koxTinm70BI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320019; c=relaxed/simple; bh=Hfi/TqPi91TIeYhP6Dc4Tjeb4JsDHT3JQTAvUmwMzY4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nZdsGp08DKh6pu36kBz3pcVSz/kVdlYIjriRUedTmYlj9/KbxI1eCGtG5VvsspsAsllqchlFsL8KRH+kFE8tnCFaidhLOVUpip7K9tIg7w8v0trcvuR+cIUNNl7dHJTObUfIxpIHPMOse1ovnesBkSOzaxuTCkEg7Z9FnH+Pj8I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=E+EFKtew; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="E+EFKtew" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AEA87C433A6; Sun, 24 Mar 2024 22:40:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320019; bh=Hfi/TqPi91TIeYhP6Dc4Tjeb4JsDHT3JQTAvUmwMzY4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=E+EFKtew2c+jMMsS6zdlpZSW8ayP1EYmS2IW5fLesSLykYXjgUUneLCFW+rT1vYpg FmByd38kF6RzztZ7JT/Of9+T+4sDPgHZrvQXH2/gg9F1xnkCScE+zqPM3c6bdi5ZHr KHJo5eO1NoyjF26WmCz/45Ru5J0QkRHPMiQOuiK1oiChbHncKP+O6vXY94bQP/KdEl STwUMKnVsbx0lQ6mKKXG5v92bfWCw+r+KLM2Yrep+HdqBwhWBz4NS12DqN9+Rav9iV JhNKDS9cOitOOf6TzPqRsYGUbiq8s1+oHF+v/tFTEhT98zgLB5I//c8JAkSVb+KOYX aWG6JHwpVxN8g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sunil Goutham , Sai Krishna , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 327/715] octeontx2-af: Fix devlink params Date: Sun, 24 Mar 2024 18:28:26 -0400 Message-ID: <20240324223455.1342824-328-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sunil Goutham [ Upstream commit fc1b2901e0feed933aaee273d0b0ca961539f4d7 ] Devlink param for adjusting NPC MCAM high zone area is in wrong param list and is not getting activated on CN10KA silicon. That patch fixes this issue. Fixes: dd7842878633 ("octeontx2-af: Add new devlink param to configure maxi= mum usable NIX block LFs") Signed-off-by: Sunil Goutham Signed-off-by: Sai Krishna Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../marvell/octeontx2/af/rvu_devlink.c | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c b/driv= ers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c index 1e6fbd98423dc..96c04f7d93f8b 100644 --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_devlink.c @@ -1235,8 +1235,8 @@ static int rvu_af_dl_dwrr_mtu_get(struct devlink *dev= link, u32 id, enum rvu_af_dl_param_id { RVU_AF_DEVLINK_PARAM_ID_BASE =3D DEVLINK_PARAM_GENERIC_ID_MAX, RVU_AF_DEVLINK_PARAM_ID_DWRR_MTU, - RVU_AF_DEVLINK_PARAM_ID_NPC_EXACT_FEATURE_DISABLE, RVU_AF_DEVLINK_PARAM_ID_NPC_MCAM_ZONE_PERCENT, + RVU_AF_DEVLINK_PARAM_ID_NPC_EXACT_FEATURE_DISABLE, RVU_AF_DEVLINK_PARAM_ID_NIX_MAXLF, }; =20 @@ -1434,15 +1434,6 @@ static const struct devlink_param rvu_af_dl_params[]= =3D { BIT(DEVLINK_PARAM_CMODE_RUNTIME), rvu_af_dl_dwrr_mtu_get, rvu_af_dl_dwrr_mtu_set, rvu_af_dl_dwrr_mtu_validate), -}; - -static const struct devlink_param rvu_af_dl_param_exact_match[] =3D { - DEVLINK_PARAM_DRIVER(RVU_AF_DEVLINK_PARAM_ID_NPC_EXACT_FEATURE_DISABLE, - "npc_exact_feature_disable", DEVLINK_PARAM_TYPE_STRING, - BIT(DEVLINK_PARAM_CMODE_RUNTIME), - rvu_af_npc_exact_feature_get, - rvu_af_npc_exact_feature_disable, - rvu_af_npc_exact_feature_validate), DEVLINK_PARAM_DRIVER(RVU_AF_DEVLINK_PARAM_ID_NPC_MCAM_ZONE_PERCENT, "npc_mcam_high_zone_percent", DEVLINK_PARAM_TYPE_U8, BIT(DEVLINK_PARAM_CMODE_RUNTIME), @@ -1457,6 +1448,15 @@ static const struct devlink_param rvu_af_dl_param_ex= act_match[] =3D { rvu_af_dl_nix_maxlf_validate), }; =20 +static const struct devlink_param rvu_af_dl_param_exact_match[] =3D { + DEVLINK_PARAM_DRIVER(RVU_AF_DEVLINK_PARAM_ID_NPC_EXACT_FEATURE_DISABLE, + "npc_exact_feature_disable", DEVLINK_PARAM_TYPE_STRING, + BIT(DEVLINK_PARAM_CMODE_RUNTIME), + rvu_af_npc_exact_feature_get, + rvu_af_npc_exact_feature_disable, + rvu_af_npc_exact_feature_validate), +}; + /* Devlink switch mode */ static int rvu_devlink_eswitch_mode_get(struct devlink *devlink, u16 *mode) { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 982F15CDE7; Sun, 24 Mar 2024 22:40:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320020; cv=none; b=HulcfdiclDH/kfDQ/lxj3PDL7SOYIBODR/tR7fuqORk8MDFLvmGaqyo+OXKZGZszA/3tbEDI+WAUmMRS6URUEyISCdZTJc9s0IjVyBRWZR11BSew8ZHXuJYc4p6iz6lYHphCh4JJQbJploic5JEJzBUYO0MwOFQyTpb9JF6UdU4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320020; c=relaxed/simple; bh=HgEcKG5Vx/SjBZU6lXviRdeplvbHJ8xqQ+Kn3L/pG18=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=fzYr1Fdyqt52ZLy1YzP+9t3NTQJaPO7xiV7MysFsa2EDqVDyffiZoDa4MG3EuXL0pCiRBBGeqVoYOTg0GZ+TZUEjjli9tCkw8wmQ961C4/JrssxLdI8scy/I7T0GxRYchw/FEV85grEfTUFsLLCx+mHOrWS49lzVvaqnLw+zryc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HQL0JLHD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HQL0JLHD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB195C433C7; Sun, 24 Mar 2024 22:40:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320020; bh=HgEcKG5Vx/SjBZU6lXviRdeplvbHJ8xqQ+Kn3L/pG18=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HQL0JLHDes9zlR4EmKxRBWiMIe+FQjOwNXYBMByuNNoS62Rk6IOtNgAztlgdVbXZZ j2kUwc9sel3UZdjSKOuKQJEj7v+73TtBjLKG2D+doOOnme1I2dCW86gzDuU+lvwTND TePcZeOfnaWamfUVk9ZWU0828OmTyTo0SAggkSahqtdfooYDS4FkmMDi7gl65jm84A 536i4cnF+ncTcMDuttENiVNKEBVFWGc3fjprEA3K77+ytaVwA91G80wzwtLXBytYzd E71enE16l7YQfWd2AhYOa6XDFme868EwlWsoDJxOLM+aq5ynTyJg2HeEGkoNBUa18R I4L3qAQO0z6TA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?K=C3=A9vin=20L=27h=C3=B4pital?= , Enguerrand de Ribaucourt , Russell King , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 328/715] net: phy: fix phy_get_internal_delay accessing an empty array Date: Sun, 24 Mar 2024 18:28:27 -0400 Message-ID: <20240324223455.1342824-329-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: K=C3=A9vin L'h=C3=B4pital [ Upstream commit 4469c0c5b14a0919f5965c7ceac96b523eb57b79 ] The phy_get_internal_delay function could try to access to an empty array in the case that the driver is calling phy_get_internal_delay without defining delay_values and rx-internal-delay-ps or tx-internal-delay-ps is defined to 0 in the device-tree. This will lead to "unable to handle kernel NULL pointer dereference at virtual address 0". To avoid this kernel oops, the test should be delay >=3D 0. As there is already delay < 0 test just before, the test could only be size =3D=3D 0. Fixes: 92252eec913b ("net: phy: Add a helper to return the index for of the= internal delay") Co-developed-by: Enguerrand de Ribaucourt Signed-off-by: Enguerrand de Ribaucourt Signed-off-by: K=C3=A9vin L'h=C3=B4pital Reviewed-by: Russell King (Oracle) Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/phy/phy_device.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c index 3611ea64875ef..3ad9bbf65cbeb 100644 --- a/drivers/net/phy/phy_device.c +++ b/drivers/net/phy/phy_device.c @@ -2959,7 +2959,7 @@ s32 phy_get_internal_delay(struct phy_device *phydev,= struct device *dev, if (delay < 0) return delay; =20 - if (delay && size =3D=3D 0) + if (size =3D=3D 0) return delay; =20 if (delay < delay_values[0] || delay > delay_values[size - 1]) { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9A0FC180B7C; Sun, 24 Mar 2024 22:40:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320021; cv=none; b=PYtaho4skRQi2ShBiLjRo0UxanJClRnYn4ahbVx5IsqEXsSHOmdNI7GFAgpfe9tyTtRF6/Mdms81iffTKyLk9I04S8paWG0X8Wn0urV/8cSkzwLyZVS6eLdvMbExT39C+e7axW7g1BR/ugvgD547fuQ1LxjvpzG6i+QJBgmOliw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320021; c=relaxed/simple; bh=FAT2yniJKJbWTQWBE0dDoAbysmicJfUvGas2RFGQpZU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NDEbOX8PA+jbLblH/ZK/+8h0Nn2lJgKeRxvdKx2thZBvTxYkavWUQlhxICFEoenzQTJ6Ban8nGZSjM1vDp3c6tZkDjzfgcaKs7q1T/nV4/JeZ5ooHyAfDe0wHLAG9ZY37V+dmXgGPWumVq97TrNXqjU7AdcuNamrBAKtMvKEq5E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=dEzgkEFI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="dEzgkEFI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC6A5C43399; Sun, 24 Mar 2024 22:40:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320021; bh=FAT2yniJKJbWTQWBE0dDoAbysmicJfUvGas2RFGQpZU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dEzgkEFILlTXNzq4zNgBuXXudyxlhgzMYEERqPIeE/D6Vw8v435PIQzB4qCPFquPd zqJJQHPFhjzgWa1Asm8deB+3EbQLHe5gA41IopKDTMzKl7gmRVeV3lxFAwKr9QlQ2l jUyRlLd81Tk4euVWWgKcuw2kLgucWqX1nBJXR8aTzM5HtTK4l+pb5Q8aT/SDf1i/pp NGXSaF0IfJ3zqNDhMPaXf03G4DtTq0rSXJXOoC6zXL4DY0GPeNYDMpiPu80fHjJYtU 7SodCQBAZQkDwqTWPKzmCes2MTJZbWAKuR4i0gPmBci1/LRX5dOVGH5bZbr4mXhK9w L3YQN3fbqWEbg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jiri Pirko , Rahul Rameshbabu , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 329/715] dpll: fix dpll_xa_ref_*_del() for multiple registrations Date: Sun, 24 Mar 2024 18:28:28 -0400 Message-ID: <20240324223455.1342824-330-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jiri Pirko [ Upstream commit b446631f355ece73b13c311dd712c47381a23172 ] Currently, if there are multiple registrations of the same pin on the same dpll device, following warnings are observed: WARNING: CPU: 5 PID: 2212 at drivers/dpll/dpll_core.c:143 dpll_xa_ref_pin_d= el.isra.0+0x21e/0x230 WARNING: CPU: 5 PID: 2212 at drivers/dpll/dpll_core.c:223 __dpll_pin_unregi= ster+0x2b3/0x2c0 The problem is, that in both dpll_xa_ref_dpll_del() and dpll_xa_ref_pin_del() registration is only removed from list in case the reference count drops to zero. That is wrong, the registration has to be removed always. To fix this, remove the registration from the list and free it unconditionally, instead of doing it only when the ref reference counter reaches zero. Fixes: 9431063ad323 ("dpll: core: Add DPLL framework base functions") Signed-off-by: Jiri Pirko Reviewed-by: Rahul Rameshbabu Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/dpll/dpll_core.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/dpll/dpll_core.c b/drivers/dpll/dpll_core.c index 7f686d179fc93..c751a87c7a8e6 100644 --- a/drivers/dpll/dpll_core.c +++ b/drivers/dpll/dpll_core.c @@ -129,9 +129,9 @@ static int dpll_xa_ref_pin_del(struct xarray *xa_pins, = struct dpll_pin *pin, reg =3D dpll_pin_registration_find(ref, ops, priv); if (WARN_ON(!reg)) return -EINVAL; + list_del(®->list); + kfree(reg); if (refcount_dec_and_test(&ref->refcount)) { - list_del(®->list); - kfree(reg); xa_erase(xa_pins, i); WARN_ON(!list_empty(&ref->registration_list)); kfree(ref); @@ -209,9 +209,9 @@ dpll_xa_ref_dpll_del(struct xarray *xa_dplls, struct dp= ll_device *dpll, reg =3D dpll_pin_registration_find(ref, ops, priv); if (WARN_ON(!reg)) return; + list_del(®->list); + kfree(reg); if (refcount_dec_and_test(&ref->refcount)) { - list_del(®->list); - kfree(reg); xa_erase(xa_dplls, i); WARN_ON(!list_empty(&ref->registration_list)); kfree(ref); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 74E74180B9A; Sun, 24 Mar 2024 22:40:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320022; cv=none; b=umDYVg4Nn3qotlIUM1uzVSs0Of4KdLGXwDxWyGI8AUzi8NL4md732ArM930x2nApxivjrc6FI/QtMl2T8cyj6UGcvQM8v/DjTzDlaq4yOB/UbcQGpT23rEKnFwOT4b8/fsNZOM+49SLX5Qs29LyxoKIdpUp+9k4XRciEbGG6POg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320022; c=relaxed/simple; bh=vP825Ku2Y5fpQtvsySFA7Z6w4KP+omheovnqVtB+F0Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=E+7abthOQwiN9pfh2v9hd5u5bvQSajTEcu99GS0Cpovu2Ugc4HRlZ7Mg3X+YFjBIWpT8v5arGEdg61ctI8QHMiifjhtTySvUt5AUbyvydcJuMqm5UT6cdusblvsS8S1TCtvnUJb7YcfSdK+fyoGASWIBCclIhfSDBcLKbkOtBOI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=H4gVxb9E; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="H4gVxb9E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B69BCC433A6; Sun, 24 Mar 2024 22:40:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320022; bh=vP825Ku2Y5fpQtvsySFA7Z6w4KP+omheovnqVtB+F0Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=H4gVxb9EJQBbnIzVWnlknzNh62vVXNlHs1NTzHbUC/wtIcY9Si2ozdf7XrB9s7qYL sGfTg9Ajr13stJvqiVlnfgde0toZgYbkcE55zoAtGKICyJz2Wu4Z4edESScPRbRfI1 i0Wa7e3xubN25KykRJDGSlll4W2q/dJmfHY9oM6j6hZefTD5jXqHcMOVdvj+2CKkHr rqetDkZ2HLaGhrmFsNStbaHr0MSm2GaN1aHntcyaOOaTEmi8nYFh17rdz3bSbQlxF+ h1myY6Z/LyIy2pjAiQsWy146vJCtcvKR/oDC42CE0oV7juLdcmQXMMxW7+I9iFtXvo 3d7k6TpBvaaxw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jijie Shao , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 330/715] net: hns3: fix wrong judgment condition issue Date: Sun, 24 Mar 2024 18:28:29 -0400 Message-ID: <20240324223455.1342824-331-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jijie Shao [ Upstream commit 07a1d6dc90baedcf5d713e2b003b9e387130ee30 ] In hns3_dcbnl_ieee_delapp, should check ieee_delapp not ieee_setapp. This path fix the wrong judgment. Fixes: 0ba22bcb222d ("net: hns3: add support config dscp map to tc") Signed-off-by: Jijie Shao Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/ethernet/hisilicon/hns3/hns3_dcbnl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_dcbnl.c b/drivers/net= /ethernet/hisilicon/hns3/hns3_dcbnl.c index 3b6dbf158b98d..f72dc0cee30e5 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3_dcbnl.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_dcbnl.c @@ -76,7 +76,7 @@ static int hns3_dcbnl_ieee_delapp(struct net_device *ndev= , struct dcb_app *app) if (hns3_nic_resetting(ndev)) return -EBUSY; =20 - if (h->kinfo.dcb_ops->ieee_setapp) + if (h->kinfo.dcb_ops->ieee_delapp) return h->kinfo.dcb_ops->ieee_delapp(h, app); =20 return -EOPNOTSUPP; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C18FF18147C; Sun, 24 Mar 2024 22:40:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320023; cv=none; b=W4uNmzyy65O16lnR+zUDOByRdzZtsK8m5jPVgYeON/Zqwbnc/6mC8JtrQDoGVc4zca89MEW/x+afTteVoWx3MWpzU/Izz8aw3psTra6LnLEHgZAhKCesbRzXNhHXrZ0ePjQghkfyMUCHfq0wZSbEU5yqY4Q5vFT8YnmuRadsEnA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320023; c=relaxed/simple; bh=vqdGYh2qX5PJMHJlK/yEfcvomm37fo5U2NvzLr8m9aU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UR76zDIEGX4fNvwetCheVIr7XmUpfnbIkgOQPj1IiCYeW+tHYhN9gw3/VzKHla1qVtcxF0oQBo0yqA/6MNxzY7TMqWHlXptZVj0RoqCsOZ9cuvROvod7HUGJKsMg+dC5iswHBGqplPL+yrXz4Lzb2LO0BMNDE0vaRZPxkLpiBos= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TrtRex13; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TrtRex13" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B422C433C7; Sun, 24 Mar 2024 22:40:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320023; bh=vqdGYh2qX5PJMHJlK/yEfcvomm37fo5U2NvzLr8m9aU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TrtRex13awJHTD+LK5Sp2kbKXgTPhTDR6Kf8q1jA3Dt8tzEK57JY0K0iya/pP3MIu C320ZebXzTrcft5UIQV1mCh6VvtiM1XNZIzjmPTJ17pnZ3pO0tkPJAPh7w8E93SX8B c7fQcFLdqIqM2pofi+PUQFvjEWakPJZ1VeA/CRy36QYUdov3cbb5/pqkYXQ2Ub7b9N 3mz/l73KgxyadI1WWvW0fqbg9tvqupXe9Pc49hJr1oKMQQmvDZEMQWY8wtM3LZL5Y3 Sa+Jtne7KoLIcyEx10Y2HTrU5/mTlxzS3b3K+tK1Wkc60UMy8l6e6zk3stqrd95fUM eHNF3dbssmq7w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yonglong Liu , Jijie Shao , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 331/715] net: hns3: fix kernel crash when 1588 is received on HIP08 devices Date: Sun, 24 Mar 2024 18:28:30 -0400 Message-ID: <20240324223455.1342824-332-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yonglong Liu [ Upstream commit 0fbcf2366ba9888cf02eda23e35fde7f7fcc07c3 ] The HIP08 devices does not register the ptp devices, so the hdev->ptp is NULL, but the hardware can receive 1588 messages, and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the access of hdev->ptp->flags will cause a kernel crash: [ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual = address 0000000000000018 [ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual = address 0000000000000018 ... [ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge] [ 5889.279101] sp : ffff800012c3bc50 [ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040 [ 5889.289927] x27: ffff800009116484 x26: 0000000080007500 [ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000 [ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000 [ 5889.309134] x21: 0000000000000000 x20: ffff204004220080 [ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000 [ 5889.321897] x17: 0000000000000000 x16: 0000000000000000 [ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000 [ 5889.334617] x13: 0000000000000000 x12: 00000000010011df [ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000 [ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d [ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480 [ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000 [ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000 [ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080 [ 5889.378857] Call trace: [ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge] [ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3] [ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3] [ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3] [ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3] [ 5889.411084] napi_poll+0xcc/0x264 [ 5889.415329] net_rx_action+0xd4/0x21c [ 5889.419911] __do_softirq+0x130/0x358 [ 5889.424484] irq_exit+0x134/0x154 [ 5889.428700] __handle_domain_irq+0x88/0xf0 [ 5889.433684] gic_handle_irq+0x78/0x2c0 [ 5889.438319] el1_irq+0xb8/0x140 [ 5889.442354] arch_cpu_idle+0x18/0x40 [ 5889.446816] default_idle_call+0x5c/0x1c0 [ 5889.451714] cpuidle_idle_call+0x174/0x1b0 [ 5889.456692] do_idle+0xc8/0x160 [ 5889.460717] cpu_startup_entry+0x30/0xfc [ 5889.465523] secondary_start_kernel+0x158/0x1ec [ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80) [ 5889.477950] SMP: stopping secondary CPUs [ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95 [ 5890.522951] Starting crashdump kernel... Fixes: 0bf5eb788512 ("net: hns3: add support for PTP") Signed-off-by: Yonglong Liu Signed-off-by: Jijie Shao Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_ptp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_ptp.c b/drive= rs/net/ethernet/hisilicon/hns3/hns3pf/hclge_ptp.c index 80a2a0073d97a..507d7ce26d831 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_ptp.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_ptp.c @@ -108,7 +108,7 @@ void hclge_ptp_get_rx_hwts(struct hnae3_handle *handle,= struct sk_buff *skb, u64 ns =3D nsec; u32 sec_h; =20 - if (!test_bit(HCLGE_PTP_FLAG_RX_EN, &hdev->ptp->flags)) + if (!hdev->ptp || !test_bit(HCLGE_PTP_FLAG_RX_EN, &hdev->ptp->flags)) return; =20 /* Since the BD does not have enough space for the higher 16 bits of --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6CC90181491; Sun, 24 Mar 2024 22:40:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320024; cv=none; b=T0t9eq7aOUm1G2HG8kFteZNKNCa5jsp7ihWaoFa53Ef4j6JpC8q5Cm7osDMCLy2+OovSl/mYU2OgRvOiKqZHyCpW7/L+tVCYepcQeLzlaM+VUHJjzHr43DId1Rns6BN5PdEe3hVJ18I1QD7GWLxTLXW4VDm8hCoELCNYihxdZGI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320024; c=relaxed/simple; bh=cfO/pSwv8DvtXWRMznN57ZBsrXBoyZbOV1j5gmASnTI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=UWMGizT+tdqPY4gEHVF6mYU1ePYHjDJJmWdLZBOUZCqIeUm7Hngs5yUNrdg4ZVMH9SwRrbInd9G3IOc1uuqBdt9xCruMRNKUBk5kfBy7y6GK4u+9Ucj1xCWjo4eir72e3a01QwmNohtwmdMgzTVY+fU2HeFOo6kLYsIo55ijTws= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=pwAvBi8m; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="pwAvBi8m" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 95B63C43399; Sun, 24 Mar 2024 22:40:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320024; bh=cfO/pSwv8DvtXWRMznN57ZBsrXBoyZbOV1j5gmASnTI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=pwAvBi8mwyAEr9PaNyJTzK48Uc39QYZfwEXIoQcM4KhYEpdMJkW881yaicuKoYyqQ Bw/LbFlLFgO5qjcKMvViLYkjXWmo2AXUHv3MRNtJrI2RBJlyW8w3KkxH3xMOs0vQHT mEhqC8JvIHna+/XdbeOF0mfat6JID07o0ffHCnOt2dGEaKEkg0rzB4eTskichmTAND BBlgWSnqd/3ObeGDHJaJvc+0X8jUbupCbsMww4pEe9R2xp8Z1dUWCLqgPfhatLo5k+ 1iBI5BivAGHDYNcyOkgRwtSoH99Wv7vmRRRmZsBQuaJhItiV+Qx0CA0R/O/CtQWLu5 WdqZg8LmDZJfw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jie Wang , Jijie Shao , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 332/715] net: hns3: fix port duplex configure error in IMP reset Date: Sun, 24 Mar 2024 18:28:31 -0400 Message-ID: <20240324223455.1342824-333-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jie Wang [ Upstream commit 11d80f79dd9f871a52feba4bf24b5ac39f448eb7 ] Currently, the mac port is fixed to configured as full dplex mode in hclge_mac_init() when driver initialization or reset restore. Users may change the mode to half duplex with ethtool, so it may cause the user configuration dropped after reset. To fix it, don't change the duplex mode when resetting. Fixes: 2d03eacc0b7e ("net: hns3: Only update mac configuation when necessar= y") Signed-off-by: Jie Wang Signed-off-by: Jijie Shao Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c b/driv= ers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c index 5ea9e59569eff..609d3799d7738 100644 --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c @@ -2890,7 +2890,10 @@ static int hclge_mac_init(struct hclge_dev *hdev) int ret; =20 hdev->support_sfp_query =3D true; - hdev->hw.mac.duplex =3D HCLGE_MAC_FULL; + + if (!test_bit(HCLGE_STATE_RST_HANDLING, &hdev->state)) + hdev->hw.mac.duplex =3D HCLGE_MAC_FULL; + ret =3D hclge_cfg_mac_speed_dup_hw(hdev, hdev->hw.mac.speed, hdev->hw.mac.duplex, hdev->hw.mac.lane_num); if (ret) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5C078181CE9; Sun, 24 Mar 2024 22:40:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320025; cv=none; b=T8j1Oari7sCU3jUN/VYip3h9P03amoKrbrCBdeacbWJfmIdoDFCYdR6Hs9WoveVDZeJo5cF4Z8NxDL9A1ZfZId+ePhGAygWKhBRTXQjBastbmuYn1TSUoP9gSv0k9+qmHKpO7d/RtAjas/LAFxZU6BJSjj9IXhx2UqDcpG7W4CA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320025; c=relaxed/simple; bh=4mF4V8TS65Jj2vD7gHAcMiY35vWWyWzZ99pCIrEaiwk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=OfgLKYCNBE6311KAsBzQ6ZqzW6vasJshiH4Nurn/eA9KgcYzvQEuJKT1SR9qU61AKuN5bLG/FgDG8TXqJO0cdoE1AcG2CtsEyDUWCi+rjrmZdK13OcP1jxTomvL8ZmZ5nUJ9U1JrX0Q780Ov0hCjKmXZ7we/P4A6hJsUM1yjHoQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rpmyfhTL; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rpmyfhTL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 936DFC433C7; Sun, 24 Mar 2024 22:40:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320025; bh=4mF4V8TS65Jj2vD7gHAcMiY35vWWyWzZ99pCIrEaiwk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rpmyfhTLQlylJbHSFKvRBeQMnX8KEPbY5VHxRf9+rYBa9jGut1/WUTD1bX3sb1pvz qgnL3t7FiD0uTASUyN1SPWFNq14L5yxLTaTIt83bo+txgmdGIgtofqDqkjoyM+3T16 CT//kBtdXvhocyFQYVOStlq1OGxXcil1MQVh/bOCI08EtrIAV+PJSGbt9a6q7pwMMK lERAZQTMW45O5xE+2MsAW0xFCjxZTZJmH5HJ5URW4cid60rQPRXgzTz7/KEiites/w 3bHghHJm8Nqp56+gQdLMIfoDbGJcc3T3Pi85sk2Oo7rfhYBDYre3NhMYvXG0EjlFO8 X5uepvuiQ7I0Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Fr=C3=A9d=C3=A9ric=20Danis?= , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.8 333/715] Bluetooth: Fix eir name length Date: Sun, 24 Mar 2024 18:28:32 -0400 Message-ID: <20240324223455.1342824-334-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Fr=C3=A9d=C3=A9ric Danis [ Upstream commit 2ab3e8d67fc1d4a7638b769cf83023ec209fc0a9 ] According to Section 1.2 of Core Specification Supplement Part A the complete or short name strings are defined as utf8s, which should not include the trailing NULL for variable length array as defined in Core Specification Vol1 Part E Section 2.9.3. Removing the trailing NULL allows PTS to retrieve the random address based on device name, e.g. for SM/PER/KDU/BV-02-C, SM/PER/KDU/BV-08-C or GAP/BROB/BCST/BV-03-C. Fixes: f61851f64b17 ("Bluetooth: Fix append max 11 bytes of name to scan rs= p data") Signed-off-by: Fr=C3=A9d=C3=A9ric Danis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/bluetooth/eir.c | 29 +++++++---------------------- net/bluetooth/mgmt.c | 2 +- 2 files changed, 8 insertions(+), 23 deletions(-) diff --git a/net/bluetooth/eir.c b/net/bluetooth/eir.c index 9214189279e80..1bc51e2b05a34 100644 --- a/net/bluetooth/eir.c +++ b/net/bluetooth/eir.c @@ -13,48 +13,33 @@ =20 #define PNP_INFO_SVCLASS_ID 0x1200 =20 -static u8 eir_append_name(u8 *eir, u16 eir_len, u8 type, u8 *data, u8 data= _len) -{ - u8 name[HCI_MAX_SHORT_NAME_LENGTH + 1]; - - /* If data is already NULL terminated just pass it directly */ - if (data[data_len - 1] =3D=3D '\0') - return eir_append_data(eir, eir_len, type, data, data_len); - - memcpy(name, data, HCI_MAX_SHORT_NAME_LENGTH); - name[HCI_MAX_SHORT_NAME_LENGTH] =3D '\0'; - - return eir_append_data(eir, eir_len, type, name, sizeof(name)); -} - u8 eir_append_local_name(struct hci_dev *hdev, u8 *ptr, u8 ad_len) { size_t short_len; size_t complete_len; =20 - /* no space left for name (+ NULL + type + len) */ - if ((max_adv_len(hdev) - ad_len) < HCI_MAX_SHORT_NAME_LENGTH + 3) + /* no space left for name (+ type + len) */ + if ((max_adv_len(hdev) - ad_len) < HCI_MAX_SHORT_NAME_LENGTH + 2) return ad_len; =20 /* use complete name if present and fits */ complete_len =3D strnlen(hdev->dev_name, sizeof(hdev->dev_name)); if (complete_len && complete_len <=3D HCI_MAX_SHORT_NAME_LENGTH) - return eir_append_name(ptr, ad_len, EIR_NAME_COMPLETE, - hdev->dev_name, complete_len + 1); + return eir_append_data(ptr, ad_len, EIR_NAME_COMPLETE, + hdev->dev_name, complete_len); =20 /* use short name if present */ short_len =3D strnlen(hdev->short_name, sizeof(hdev->short_name)); if (short_len) - return eir_append_name(ptr, ad_len, EIR_NAME_SHORT, + return eir_append_data(ptr, ad_len, EIR_NAME_SHORT, hdev->short_name, - short_len =3D=3D HCI_MAX_SHORT_NAME_LENGTH ? - short_len : short_len + 1); + short_len); =20 /* use shortened full name if present, we already know that name * is longer then HCI_MAX_SHORT_NAME_LENGTH */ if (complete_len) - return eir_append_name(ptr, ad_len, EIR_NAME_SHORT, + return eir_append_data(ptr, ad_len, EIR_NAME_SHORT, hdev->dev_name, HCI_MAX_SHORT_NAME_LENGTH); =20 diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c index cc8efdc4ad431..640d6d54ac6ba 100644 --- a/net/bluetooth/mgmt.c +++ b/net/bluetooth/mgmt.c @@ -8400,7 +8400,7 @@ static int read_adv_features(struct sock *sk, struct = hci_dev *hdev, =20 static u8 calculate_name_len(struct hci_dev *hdev) { - u8 buf[HCI_MAX_SHORT_NAME_LENGTH + 3]; + u8 buf[HCI_MAX_SHORT_NAME_LENGTH + 2]; /* len + type + name */ =20 return eir_append_local_name(hdev, buf, 0); } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 42010181D0A; Sun, 24 Mar 2024 22:40:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320026; cv=none; b=G5ZSIbmP/FMrndAjaXMAJPNnNwYyTN61izuCCPkQ6Hf9quv82onFHZ1RMkBiodu/alT7iJsj9XsOHcFAwbFA49YMljNLdG3JdOdVfiCt5cyEov/YGNZmHecmFFRb2RgN27noB5RcNq9j8XPBEz/9rmW49lTfbFZRoBY+xfszcW4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320026; c=relaxed/simple; bh=eHTqfpRH4w1jwSBCjC/7u/xx40HMa+l75jbyu7n46y0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CiFEyfppM4P4xbvTm6muqEx8e0NiLcTXxv3j34JBg7VcrXB2NqCV0l4cOWeeFt69n1lo0MSe6OzTlx8VufhmFSSHKfsymj8+qbkj7vLoxb4uhTcm2PSfrnzarEZ8Wmac4joQ18+brPPxQjS4DYdUU+t0FGhH4pyP6a5795X/bF0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=kY60L++Y; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="kY60L++Y" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79261C43390; Sun, 24 Mar 2024 22:40:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320026; bh=eHTqfpRH4w1jwSBCjC/7u/xx40HMa+l75jbyu7n46y0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kY60L++YfIyJMIc32UnFOrHGfBcV2eGA7AYVNx2hygmnu2tABNDfnqRdBf1df+tXa n+JGdJWwMLWgFlNNUuNiRDEgbVk2FSuaXGREc6KTFmmUsKkQLIpOucET3f+7Jg1T5+ a4F5J3VXRSj6rQKpD2OhqQoaHTTLwbKuLELkznB/1+SdUHqSnTnGLkKp6wE7gL94Sa LynpYxOgLQfYtGEeCFpfAmFUUHZauGJr56LK2TezJz8Y8HqBwvk01pG5oQHjErKz83 pg/WZMBBI45pM9yInomqS4KrSCNdMXFflPrDI3fvmFXMDGcnfR4h3E+hOFfb8QSkcw xhF63J8jDX03g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Tim Pambor , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.8 334/715] net: phy: dp83822: Fix RGMII TX delay configuration Date: Sun, 24 Mar 2024 18:28:33 -0400 Message-ID: <20240324223455.1342824-335-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Tim Pambor [ Upstream commit c8a5c731fd1223090af57da33838c671a7fc6a78 ] The logic for enabling the TX clock shift is inverse of enabling the RX clock shift. The TX clock shift is disabled when DP83822_TX_CLK_SHIFT is set. Correct the current behavior and always write the delay configuration to ensure consistent delay settings regardless of bootloader configuration. Reference: https://www.ti.com/lit/ds/symlink/dp83822i.pdf p. 69 Fixes: 8095295292b5 ("net: phy: DP83822: Add setting the fixed internal del= ay") Signed-off-by: Tim Pambor Link: https://lore.kernel.org/r/20240305110608.104072-1-tp@osasysteme.de Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/phy/dp83822.c | 37 ++++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/drivers/net/phy/dp83822.c b/drivers/net/phy/dp83822.c index b7cb71817780c..29e1cbea6dc0c 100644 --- a/drivers/net/phy/dp83822.c +++ b/drivers/net/phy/dp83822.c @@ -380,7 +380,7 @@ static int dp83822_config_init(struct phy_device *phyde= v) { struct dp83822_private *dp83822 =3D phydev->priv; struct device *dev =3D &phydev->mdio.dev; - int rgmii_delay; + int rgmii_delay =3D 0; s32 rx_int_delay; s32 tx_int_delay; int err =3D 0; @@ -390,30 +390,33 @@ static int dp83822_config_init(struct phy_device *phy= dev) rx_int_delay =3D phy_get_internal_delay(phydev, dev, NULL, 0, true); =20 - if (rx_int_delay <=3D 0) - rgmii_delay =3D 0; - else - rgmii_delay =3D DP83822_RX_CLK_SHIFT; + /* Set DP83822_RX_CLK_SHIFT to enable rx clk internal delay */ + if (rx_int_delay > 0) + rgmii_delay |=3D DP83822_RX_CLK_SHIFT; =20 tx_int_delay =3D phy_get_internal_delay(phydev, dev, NULL, 0, false); + + /* Set DP83822_TX_CLK_SHIFT to disable tx clk internal delay */ if (tx_int_delay <=3D 0) - rgmii_delay &=3D ~DP83822_TX_CLK_SHIFT; - else rgmii_delay |=3D DP83822_TX_CLK_SHIFT; =20 - if (rgmii_delay) { - err =3D phy_set_bits_mmd(phydev, DP83822_DEVADDR, - MII_DP83822_RCSR, rgmii_delay); - if (err) - return err; - } + err =3D phy_modify_mmd(phydev, DP83822_DEVADDR, MII_DP83822_RCSR, + DP83822_RX_CLK_SHIFT | DP83822_TX_CLK_SHIFT, rgmii_delay); + if (err) + return err; + + err =3D phy_set_bits_mmd(phydev, DP83822_DEVADDR, + MII_DP83822_RCSR, DP83822_RGMII_MODE_EN); =20 - phy_set_bits_mmd(phydev, DP83822_DEVADDR, - MII_DP83822_RCSR, DP83822_RGMII_MODE_EN); + if (err) + return err; } else { - phy_clear_bits_mmd(phydev, DP83822_DEVADDR, - MII_DP83822_RCSR, DP83822_RGMII_MODE_EN); + err =3D phy_clear_bits_mmd(phydev, DP83822_DEVADDR, + MII_DP83822_RCSR, DP83822_RGMII_MODE_EN); + + if (err) + return err; } =20 if (dp83822->fx_enabled) { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 684AF18274B; Sun, 24 Mar 2024 22:40:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320027; cv=none; b=rqS07AM+Uie5VyKCJnXMkqhhSNYgCyEvevSCoQ8EziY7Esrhh2FnzvbtssYH6zpktcfkzQCfrSIsfVGKhqPTajjgNIRrFr0X0E5svA3S9TcOsKRRZ2xGGIi1rsNVQBbXbMhJk5H6cyW/ca+k/4V96q9VUBimB4sdo24jZQtB7z4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320027; c=relaxed/simple; bh=jLep0Qm18v0+lf/rVqUKcq5gN5cPgy//4JMpC19HHDY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KEshDfAv6+epRtHXQZV0oLbuTGUsmMGwfB0d8wJ2R0OArf2zNbVK8wtbKCpgPHNfrjypExGuUg+Qf3XzGoWOBPmU9oej9tjNeawIVigpn+s1cK7MvHVBV+ys8DHUFvGTPHOxT5B/kGTrqgtQqoSUita164N9+/3yC47IrcLoUsM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=A3AazCkb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="A3AazCkb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6071CC433C7; Sun, 24 Mar 2024 22:40:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320027; bh=jLep0Qm18v0+lf/rVqUKcq5gN5cPgy//4JMpC19HHDY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A3AazCkbZYPD4vbVu4kESQjg7BgZTLja2Br506PJw3+4k1boeM6X0QEQrpc5LAURp T1gcfvsJSYVchQEGvlDI5L5AOTaKaFYPhp1KSykRk6RbLy7IcGu1Xd1OTNSKWxL1Jr Gpe2PMZVK1nK1JA8GivvA2X9gJ92/6ZqHG3sYEMhFUU9R6FqrPqYmTGbylqm9IbiJS KmBn1UTxvC/jxp4GplWI17PF/QTuClkl/UBnrdQB7mlPwPJ+VfO1HryJM97anUzRgs eBkcb8gSMXkS+vlXANYhggvcefnx8awuE9YOw0UrRimJ2znsYH1qOwjSYReHHrsLGU WdS821SNQqMYQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Baokun Li , Al Viro , Jingbo Xu , Yang Erkun , Gao Xiang , Sasha Levin Subject: [PATCH 6.8 335/715] erofs: fix lockdep false positives on initializing erofs_pseudo_mnt Date: Sun, 24 Mar 2024 18:28:34 -0400 Message-ID: <20240324223455.1342824-336-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Baokun Li [ Upstream commit 0f28be64d132aaf95d06375c8002ad9ecea69d71 ] Lockdep reported the following issue when mounting erofs with a domain_id: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D WARNING: possible recursive locking detected 6.8.0-rc7-xfstests #521 Not tainted Reported-by: Linux Kernel Functional Testing Reviewed-by: Yang Erkun Suggested-by: Al Viro Tested-by: Bagas Sanjaya -------------------------------------------- mount/396 is trying to acquire lock: ffff907a8aaaa0e0 (&type->s_umount_key#50/1){+.+.}-{3:3}, at: alloc_super+0xe3/0x3d0 but task is already holding lock: ffff907a8aaa90e0 (&type->s_umount_key#50/1){+.+.}-{3:3}, at: alloc_super+0xe3/0x3d0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&type->s_umount_key#50/1); lock(&type->s_umount_key#50/1); *** DEADLOCK *** May be due to missing lock nesting notation 2 locks held by mount/396: #0: ffff907a8aaa90e0 (&type->s_umount_key#50/1){+.+.}-{3:3}, at: alloc_super+0xe3/0x3d0 #1: ffffffffc00e6f28 (erofs_domain_list_lock){+.+.}-{3:3}, at: erofs_fscache_register_fs+0x3d/0x270 [erofs] stack backtrace: CPU: 1 PID: 396 Comm: mount Not tainted 6.8.0-rc7-xfstests #521 Call Trace: dump_stack_lvl+0x64/0xb0 validate_chain+0x5c4/0xa00 __lock_acquire+0x6a9/0xd50 lock_acquire+0xcd/0x2b0 down_write_nested+0x45/0xd0 alloc_super+0xe3/0x3d0 sget_fc+0x62/0x2f0 vfs_get_super+0x21/0x90 vfs_get_tree+0x2c/0xf0 fc_mount+0x12/0x40 vfs_kern_mount.part.0+0x75/0x90 kern_mount+0x24/0x40 erofs_fscache_register_fs+0x1ef/0x270 [erofs] erofs_fc_fill_super+0x213/0x380 [erofs] This is because the file_system_type of both erofs and the pseudo-mount point of domain_id is erofs_fs_type, so two successive calls to alloc_super() are considered to be using the same lock and trigger the warning above. Therefore add a nodev file_system_type called erofs_anon_fs_type in fscache.c to silence this complaint. Because kern_mount() takes a pointer to struct file_system_type, not its (string) name. So we don't need to call register_filesystem(). In addition, call init_pseudo() in erofs_anon_init_fs_context() as suggested by Al Viro, so that we can remove erofs_fc_fill_pseudo_super(), erofs_fc_anon_get_tree(), and erofs_anon_context_ops. Suggested-by: Al Viro Fixes: a9849560c55e ("erofs: introduce a pseudo mnt to manage shared cookie= s") Signed-off-by: Baokun Li Reviewed-and-tested-by: Jingbo Xu Reviewed-by: Yang Erkun Link: https://lore.kernel.org/r/20240307101018.2021925-1-libaokun1@huawei.c= om Signed-off-by: Gao Xiang Signed-off-by: Sasha Levin --- fs/erofs/fscache.c | 15 ++++++++++++++- fs/erofs/internal.h | 1 - fs/erofs/super.c | 30 +----------------------------- 3 files changed, 15 insertions(+), 31 deletions(-) diff --git a/fs/erofs/fscache.c b/fs/erofs/fscache.c index 89a7c2453aae6..122a4753ecea4 100644 --- a/fs/erofs/fscache.c +++ b/fs/erofs/fscache.c @@ -3,6 +3,7 @@ * Copyright (C) 2022, Alibaba Cloud * Copyright (C) 2022, Bytedance Inc. All rights reserved. */ +#include #include #include "internal.h" =20 @@ -12,6 +13,18 @@ static LIST_HEAD(erofs_domain_list); static LIST_HEAD(erofs_domain_cookies_list); static struct vfsmount *erofs_pseudo_mnt; =20 +static int erofs_anon_init_fs_context(struct fs_context *fc) +{ + return init_pseudo(fc, EROFS_SUPER_MAGIC) ? 0 : -ENOMEM; +} + +static struct file_system_type erofs_anon_fs_type =3D { + .owner =3D THIS_MODULE, + .name =3D "pseudo_erofs", + .init_fs_context =3D erofs_anon_init_fs_context, + .kill_sb =3D kill_anon_super, +}; + struct erofs_fscache_request { struct erofs_fscache_request *primary; struct netfs_cache_resources cache_resources; @@ -381,7 +394,7 @@ static int erofs_fscache_init_domain(struct super_block= *sb) goto out; =20 if (!erofs_pseudo_mnt) { - struct vfsmount *mnt =3D kern_mount(&erofs_fs_type); + struct vfsmount *mnt =3D kern_mount(&erofs_anon_fs_type); if (IS_ERR(mnt)) { err =3D PTR_ERR(mnt); goto out; diff --git a/fs/erofs/internal.h b/fs/erofs/internal.h index b0409badb0172..410f5af623540 100644 --- a/fs/erofs/internal.h +++ b/fs/erofs/internal.h @@ -385,7 +385,6 @@ struct erofs_map_dev { unsigned int m_deviceid; }; =20 -extern struct file_system_type erofs_fs_type; extern const struct super_operations erofs_sops; =20 extern const struct address_space_operations erofs_raw_access_aops; diff --git a/fs/erofs/super.c b/fs/erofs/super.c index 5f60f163bd56e..24788c230b494 100644 --- a/fs/erofs/super.c +++ b/fs/erofs/super.c @@ -579,13 +579,6 @@ static const struct export_operations erofs_export_ops= =3D { .get_parent =3D erofs_get_parent, }; =20 -static int erofs_fc_fill_pseudo_super(struct super_block *sb, struct fs_co= ntext *fc) -{ - static const struct tree_descr empty_descr =3D {""}; - - return simple_fill_super(sb, EROFS_SUPER_MAGIC, &empty_descr); -} - static int erofs_fc_fill_super(struct super_block *sb, struct fs_context *= fc) { struct inode *inode; @@ -712,11 +705,6 @@ static int erofs_fc_fill_super(struct super_block *sb,= struct fs_context *fc) return 0; } =20 -static int erofs_fc_anon_get_tree(struct fs_context *fc) -{ - return get_tree_nodev(fc, erofs_fc_fill_pseudo_super); -} - static int erofs_fc_get_tree(struct fs_context *fc) { struct erofs_fs_context *ctx =3D fc->fs_private; @@ -789,20 +777,10 @@ static const struct fs_context_operations erofs_conte= xt_ops =3D { .free =3D erofs_fc_free, }; =20 -static const struct fs_context_operations erofs_anon_context_ops =3D { - .get_tree =3D erofs_fc_anon_get_tree, -}; - static int erofs_init_fs_context(struct fs_context *fc) { struct erofs_fs_context *ctx; =20 - /* pseudo mount for anon inodes */ - if (fc->sb_flags & SB_KERNMOUNT) { - fc->ops =3D &erofs_anon_context_ops; - return 0; - } - ctx =3D kzalloc(sizeof(*ctx), GFP_KERNEL); if (!ctx) return -ENOMEM; @@ -824,12 +802,6 @@ static void erofs_kill_sb(struct super_block *sb) { struct erofs_sb_info *sbi; =20 - /* pseudo mount for anon inodes */ - if (sb->s_flags & SB_KERNMOUNT) { - kill_anon_super(sb); - return; - } - if (erofs_is_fscache_mode(sb)) kill_anon_super(sb); else @@ -868,7 +840,7 @@ static void erofs_put_super(struct super_block *sb) erofs_fscache_unregister_fs(sb); } =20 -struct file_system_type erofs_fs_type =3D { +static struct file_system_type erofs_fs_type =3D { .owner =3D THIS_MODULE, .name =3D "erofs", .init_fs_context =3D erofs_init_fs_context, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5E664182768; Sun, 24 Mar 2024 22:40:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320028; cv=none; b=i6MP9/81csjueVAQafHJN0kMGe2RQ79/WZ/vfytRIfDuZU2rN9ZVy3glXB3YDxXH0Sfk4/CUIea0dU8LYPv2LF/UjUs0SRip0ZVJHEsgIqPpWEdB/qjxKtNxf3mncUKUk8PHvvHl3sU6CG3Ph64HZL9zjwqv85TT5ho3+A2skFc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320028; c=relaxed/simple; bh=hP68GkQ2L6JTHbh2rG6h+rkhITHFGKUHyafkXz2mEaQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AEpvVBndloeOcQbYVMECZnpBMhfb6TzlTeEYcy9PADeMeWdNpnyMZ1n4l8jHEDowJSWcNjo5qADtnLxeBICyarqpJFKqhkkEp2ZAb7k8imbcZqFKgYsg5mKlycvdqlolaxbS6zbAeLzYrAvYNrk794CYurE7U0skNSc6rgIkg+8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WtuT8brS; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WtuT8brS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 88274C433F1; Sun, 24 Mar 2024 22:40:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320028; bh=hP68GkQ2L6JTHbh2rG6h+rkhITHFGKUHyafkXz2mEaQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WtuT8brSgOw50Z2ohzKv7FMKLWkuPAAWt1MPOE1d62hH85u7eTzXvayuZ0vjRRafa p9pkaoQeC/Y22t5JBGmYDiKAcj/lq/9vjgMv3bzLb3iWP1Gm/xqjz/pX5jko05ETtx I57vTiWb2FJ5FYhw7vLjRUp9wJIi1WXmQUobhE7Lzf3FVEfxyWCyxp0qveZhDxRUsf Tow6N9k2FotDTWalBNbBk77kp1K/YjjLHaNpaUgdIFJkwYJrhHjFXMqm74ZxF4xKiY jdZFuwuP3yhhj2VykHgrXvidSB9bUWDUqeJqKy35RVfBIB9c8QLKE/+/XHl6mLybqi lPT3DXtiZ/zkA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Viresh Kumar , kernel test robot , Dhruva Gole , Sasha Levin Subject: [PATCH 6.8 336/715] OPP: debugfs: Fix warning around icc_get_name() Date: Sun, 24 Mar 2024 18:28:35 -0400 Message-ID: <20240324223455.1342824-337-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Viresh Kumar [ Upstream commit 28330ceb953e39880ea77da4895bb902a1244860 ] If the kernel isn't built with interconnect support, icc_get_name() returns NULL and we get following warning: drivers/opp/debugfs.c: In function 'bw_name_read': drivers/opp/debugfs.c:43:42: error: '%.62s' directive argument is null [-We= rror=3Dformat-overflow=3D] i =3D scnprintf(buf, sizeof(buf), "%.62s\n", icc_get_name(path)); Fix it. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202402141313.81ltVF5g-lkp@int= el.com/ Fixes: 0430b1d5704b0 ("opp: Expose bandwidth information via debugfs") Signed-off-by: Viresh Kumar Reviewed-by: Dhruva Gole Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/opp/debugfs.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/opp/debugfs.c b/drivers/opp/debugfs.c index ec030b19164a3..f157fb50be50c 100644 --- a/drivers/opp/debugfs.c +++ b/drivers/opp/debugfs.c @@ -37,10 +37,12 @@ static ssize_t bw_name_read(struct file *fp, char __use= r *userbuf, size_t count, loff_t *ppos) { struct icc_path *path =3D fp->private_data; + const char *name =3D icc_get_name(path); char buf[64]; - int i; + int i =3D 0; =20 - i =3D scnprintf(buf, sizeof(buf), "%.62s\n", icc_get_name(path)); + if (name) + i =3D scnprintf(buf, sizeof(buf), "%.62s\n", name); =20 return simple_read_from_buffer(userbuf, count, ppos, buf, i); } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B113A17ADC2; Sun, 24 Mar 2024 22:40:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320029; cv=none; b=OZe/68Qpu4ZLSmxFOCP7wQmW5FaImpWL5j0KPVQFBdp85r8pmxvdhHmXWyCO4uWGwHJFJlX7a/FtKDuqI159/zyy7jaJ0fkgIvqzL1dYJRuDR0uIdOqQtVPWuG9PaohdzhurB9RQEaAQcYLF7brorADQVSXq7V9COt1XC9qeU+A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320029; c=relaxed/simple; bh=srNq0NrXfKRCl3FfFu+LjLJpVTxyIDjYe4yjGKTjrvU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dTA/Lti5afQihANSdoUl4dMaMfvNuAr+uTq7mGLBBEFAB+TFkyMFBCMrLLsKp4/vzBi0u4fheEdFSXC3Et+eai3mdENNxo3ge7VwtuxqJqtQib3V2oWykEWTwjsIdnqTuyGAw44MQs33NgwCkgkS3/KDXOFw2EUWUy1SstmZ1Vw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rH64gniD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="rH64gniD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 82FC6C433C7; Sun, 24 Mar 2024 22:40:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320029; bh=srNq0NrXfKRCl3FfFu+LjLJpVTxyIDjYe4yjGKTjrvU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=rH64gniDb6gKQtyQtf2OROLNX4XmVHSLmlsGPCqjgNzIkv2p+ICpjg0MZ6UjRdqfo Ko63O0rtWhtRIfY+PxLgm5U94E+YJv0HXs2U3A+4SgckDePS3oNwgl0sftVfG3FjJ+ msZL/e9A9L3fUXzpXGMq3ZJq2sWCS6W7td6l6zgReN5BBD9Mx+zy2WD6gbZL/nvu/I zT7hdzYXcipO8a/jak8ZfcrhXLS/EC0e7fGhElfCAgcGAk0/Yfbrnjil2gcgISVMmU lorv1mv7JgP0JI1sVOuwn9BOuxAFaAAW4/09NnVOqe4o5nOSMpWGmHsRA2/Kjyaad1 7ScjrtnL5STHQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gavrilov Ilia , Jason Xing , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 337/715] tcp: fix incorrect parameter validation in the do_tcp_getsockopt() function Date: Sun, 24 Mar 2024 18:28:36 -0400 Message-ID: <20240324223455.1342824-338-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gavrilov Ilia [ Upstream commit 716edc9706deb3bb2ff56e2eeb83559cea8f22db ] The 'len' variable can't be negative when assigned the result of 'min_t' because all 'min_t' parameters are cast to unsigned int, and then the minimum one is chosen. To fix the logic, check 'len' as read from 'optlen', where the types of relevant variables are (signed) int. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Gavrilov Ilia Reviewed-by: Jason Xing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/ipv4/tcp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index c82dc42f57c65..a4f4185923144 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -4010,11 +4010,11 @@ int do_tcp_getsockopt(struct sock *sk, int level, if (copy_from_sockptr(&len, optlen, sizeof(int))) return -EFAULT; =20 - len =3D min_t(unsigned int, len, sizeof(int)); - if (len < 0) return -EINVAL; =20 + len =3D min_t(unsigned int, len, sizeof(int)); + switch (optname) { case TCP_MAXSEG: val =3D tp->mss_cache; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 41C2117ADD8; Sun, 24 Mar 2024 22:40:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320030; cv=none; b=JOUSv5bVaXwCAJ9H7c8m1qREq66+R0wzcBGm5ykbOH4Tvvq6qTSmSZ7+jhyI94A0O09PSvOMiEj25yGao4Aj082AhbwASYSj+YimpQv1M4PnmnHcLByK475F1mh5BIGvTYEvyfk1y/yIkcvIFui2UMIyzj3BWKd6lE2wB5Pqtb8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320030; c=relaxed/simple; bh=EqXoCEfhgL+N/2DamQ2dbWHZzTTUlT7qV+UoCXKktWg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=qy2C0MqapIixfGvnIk5rh/OUM2mBpTa8YELFYk2h2ww1+/R3bx6NCeIsUiay1GYhrKypAF+6ReRzO/3s40mi6PVq8kGgO9RTXQb7vJwgVLAQ8s3I583SYbBsmRT5iX48lX7je/G/xWJfXVXFdMnfOoSp/8Jlq8aPFzqcgFwVT5Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=bdk1dxN5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="bdk1dxN5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C12BC433B2; Sun, 24 Mar 2024 22:40:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320030; bh=EqXoCEfhgL+N/2DamQ2dbWHZzTTUlT7qV+UoCXKktWg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=bdk1dxN5ueZJG8D1xEq7hmI8WSJ5ptjeUCQFTkcy8/noQA/VwhjIwFFqS6+iW9Cur +QkhzZqB6d3rFCzSswS8idDOfU0v3o3zsArRireeRguPAzxnUKkVdcT946zSa9NR52 nd6rL9su/eVVj2pSRsRE2qN/EFv2kVKFsPhuP5uH8DqDZzmkibniGoVotOPtLirVsC 6Uq6uBXSgGXiiVHja7nBU5DqNliYnDrRdJAEt/JHJOv5aX6fs8xB0sG2Vn+80USC7g koEsA59NtimlPniXOgXt5DGGCrD8pnCowWqFuh6VOIEjlng3uKUSsxNnexEES6Xg8G 1BmZzfMZjWV1g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gavrilov Ilia , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 338/715] ipmr: fix incorrect parameter validation in the ip_mroute_getsockopt() function Date: Sun, 24 Mar 2024 18:28:37 -0400 Message-ID: <20240324223455.1342824-339-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gavrilov Ilia [ Upstream commit 5c3be3e0eb44b7f978bb6cbb20ad956adb93f736 ] The 'olr' variable can't be negative when assigned the result of 'min_t' because all 'min_t' parameters are cast to unsigned int, and then the minimum one is chosen. To fix the logic, check 'olr' as read from 'optlen', where the types of relevant variables are (signed) int. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Gavrilov Ilia Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/ipv4/ipmr.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c index 3622298365105..b53c36c473a5b 100644 --- a/net/ipv4/ipmr.c +++ b/net/ipv4/ipmr.c @@ -1603,9 +1603,11 @@ int ip_mroute_getsockopt(struct sock *sk, int optnam= e, sockptr_t optval, =20 if (copy_from_sockptr(&olr, optlen, sizeof(int))) return -EFAULT; - olr =3D min_t(unsigned int, olr, sizeof(int)); if (olr < 0) return -EINVAL; + + olr =3D min_t(unsigned int, olr, sizeof(int)); + if (copy_to_sockptr(optlen, &olr, sizeof(int))) return -EFAULT; if (copy_to_sockptr(optval, &val, olr)) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4015317ADF6; Sun, 24 Mar 2024 22:40:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320031; cv=none; b=OgklmFEm1YsMOaWGEB32FtCmO92gFcTWxATOTgvmoGctXWqRIUdPTWver6jD1BsgxkLSwp2QL1MMIbSss/gVF2vavwAvvsutO+STZXYxq03CL3IqfI9fWTkyPDzyCNGE4ZH43G97ilFJ+6Id4K/ojvHtV4GKwbJzeO3bt51/QmI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320031; c=relaxed/simple; bh=OQsM+h49KmJCuY/Vc4xjJEjsD2hIGGvvSko+Q3j56jk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=TL4C4y2Au/FwgTgGWTPFdKcXvtvxZPg4uOy0rpPB6UsdrQh2N3AxTb1GdZkoVIYtcOL/x3ftnIGXuG6flDCbBcLVUUhizIFC/Oxnx3RJmncXuJN3M8TpYUv6p65xVdcKpnolClvv0gRg/QniH/1s99rO2LgTgCHG477ZL2A1mgY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aYULRwlJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aYULRwlJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 66660C43399; Sun, 24 Mar 2024 22:40:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320031; bh=OQsM+h49KmJCuY/Vc4xjJEjsD2hIGGvvSko+Q3j56jk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aYULRwlJ/djr+dv4WDo+TDKpLcYJ0GvckMxx/YYGjUh2gEh33KoOOnG7lO/YlZijO pn6IPfDIhvWvDmqZm6qZ0+7U3nQ+e37bUCAV/kXKv18pvA6Ae+y22zKO49SQaGkgER kDX2n77/BTzE+wZqqkJ1kPXB7fGO0iQCheRK/25kXldCBUXKCDj4U/sArXqI+hrdrs IaqEqk7cRamQubfvC7zITvvg5e95yr7pALaNuKVQayjHumgNHJVCaVRLsslX0tmf8F Q8QvtBkXcjLwkdi9k0L+FLCibGc7sAnmBDs02wzwnOb++cLEqU+0NZk6er6+Ktpck8 4XVm6UU4iOkoQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gavrilov Ilia , Tom Parkin , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 339/715] l2tp: fix incorrect parameter validation in the pppol2tp_getsockopt() function Date: Sun, 24 Mar 2024 18:28:38 -0400 Message-ID: <20240324223455.1342824-340-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gavrilov Ilia [ Upstream commit 955e9876ba4ee26eeaab1b13517f5b2c88e73d55 ] The 'len' variable can't be negative when assigned the result of 'min_t' because all 'min_t' parameters are cast to unsigned int, and then the minimum one is chosen. To fix the logic, check 'len' as read from 'optlen', where the types of relevant variables are (signed) int. Fixes: 3557baabf280 ("[L2TP]: PPP over L2TP driver core") Reviewed-by: Tom Parkin Signed-off-by: Gavrilov Ilia Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/l2tp/l2tp_ppp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c index f011af6601c9c..6146e4e67bbb5 100644 --- a/net/l2tp/l2tp_ppp.c +++ b/net/l2tp/l2tp_ppp.c @@ -1356,11 +1356,11 @@ static int pppol2tp_getsockopt(struct socket *sock,= int level, int optname, if (get_user(len, optlen)) return -EFAULT; =20 - len =3D min_t(unsigned int, len, sizeof(int)); - if (len < 0) return -EINVAL; =20 + len =3D min_t(unsigned int, len, sizeof(int)); + err =3D -ENOTCONN; if (!sk->sk_user_data) goto end; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 420F713C8F5; Sun, 24 Mar 2024 22:40:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320032; cv=none; b=sSMusVqOdOD8Vzn124Klozuh4WLTUeXyMmCBubngLuHKqbM0gXT9QuOlBucYzw1eykUROTlB6JIn2EZ1RutwUQTvN0h8Byp9eAvgCTVLEglwM7+nkYqyF990/RIjj3DGCmUqARGPjusGVByG7ha85L9o5jsuLlxom01Q2yiN9yU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320032; c=relaxed/simple; bh=v11nOk9WMIawSUi2NTo75pwxYN0u6dGKGLF3hwTXg3Y=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ap7KWONVedc79ot0sZoK6k5x6DKX+z5RzM0d/CxBhYeQOD9iarbwXQDLITXxXwEZACc75lIKX/iFsh0EiPkLdGRghof7IiZg6a2935uUVMYWWhxl0k8QSRj2+V9DPMbWU+jVvNwc83PANg4PJ/EEhK1mQSMalCzPNZ2pcK72XYE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BIsuMVlb; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BIsuMVlb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64445C433F1; Sun, 24 Mar 2024 22:40:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320032; bh=v11nOk9WMIawSUi2NTo75pwxYN0u6dGKGLF3hwTXg3Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BIsuMVlbn1Aiwegm+OIcEYxJdF/7wmujE2o3DNQbrlOYWvq8OdfZrqHV8ka4wyFiV 46ax869zvQsZ9dW0exGO+u7rbA+wr4AH3rzpj4p6wmkxRCzN1vw1jyL+EibYZnCE+d q+7k8hnH2T+Pm54UP1b2RQ5nndq5QitODKCFBdhNEBM7qrYwVxOFiF62Zuy5Dp0B5I /H1pCH4L0uphIRmpMaGpWVjUFA80JmYFFD45NR2RSsyZTfyVwB8bd42tARIYWCm/2U ZkHEV207zoWG0Vyt8vrqTycr3AcY0Q0D43TV3co60oz14pRAclifiO03JJDqkSjb87 W7rX7PQf+uUxw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gavrilov Ilia , Willem de Bruijn , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 340/715] udp: fix incorrect parameter validation in the udp_lib_getsockopt() function Date: Sun, 24 Mar 2024 18:28:39 -0400 Message-ID: <20240324223455.1342824-341-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gavrilov Ilia [ Upstream commit 4bb3ba7b74fceec6f558745b25a43c6521cf5506 ] The 'len' variable can't be negative when assigned the result of 'min_t' because all 'min_t' parameters are cast to unsigned int, and then the minimum one is chosen. To fix the logic, check 'len' as read from 'optlen', where the types of relevant variables are (signed) int. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reviewed-by: Willem de Bruijn Signed-off-by: Gavrilov Ilia Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/ipv4/udp.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c index e474b201900f9..17231c0f88302 100644 --- a/net/ipv4/udp.c +++ b/net/ipv4/udp.c @@ -2792,11 +2792,11 @@ int udp_lib_getsockopt(struct sock *sk, int level, = int optname, if (get_user(len, optlen)) return -EFAULT; =20 - len =3D min_t(unsigned int, len, sizeof(int)); - if (len < 0) return -EINVAL; =20 + len =3D min_t(unsigned int, len, sizeof(int)); + switch (optname) { case UDP_CORK: val =3D udp_test_bit(CORK, sk); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1E69013C911; Sun, 24 Mar 2024 22:40:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320033; cv=none; b=kcLOGeE2ceIknPdlSST2XQNUmJjxY3DtI53Se12b2olEsgblnpIoAGJB6Hnjsor1MGfMFvhwrPiho2bdWi/m+uTcA1HvyvR0NyAUgsIUa1duAChrVdgSJzSPPooen4e0FkgHdyk+NUG4Kuyqi0OPkKqb8C8++hDc3bxbc3IBe4g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320033; c=relaxed/simple; bh=KEnJYE7iFGmp2/B2QX8PVoBww/lPOvrAXRR2IkS82Ls=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hNp6DNTTxDIftg5/Ibz+9XXpHEeFYsM6mQGMBpM5IOoCcq3zYYvrFfITmzp5zvjE1v8dZyNY5a5oWPe+6BoN9xnviXpuPiyni32KfhVfgBixb4wKBdMkTQ0VucdOv+f0UnQEmbCe/0LRP7icdCbswyrs4AzoVTDCAScbzamN5ZI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Fp1jWJ8W; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Fp1jWJ8W" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6002EC433C7; Sun, 24 Mar 2024 22:40:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320033; bh=KEnJYE7iFGmp2/B2QX8PVoBww/lPOvrAXRR2IkS82Ls=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Fp1jWJ8W5X34j5sdTgMUPr/iCSiupe9ekZKv4hrTNY3HC9e4sspiKeyCR1mryceJ7 SBuX8ReIGtmhcmUtFqXYsViKGixlCNSKGbdiCdqsYwycZIJSAX0IgxwxR9aiRxv+E9 wzJeGH1emxpQLHCb3ziNfH5z4tWRSgxVTotBlvLZtnyIBNxp8l/DfUg6U5Iq3wxpvj iUSlSF9RMJb6qioC0L8oaWGNgwU0nqxuyJ72MStRUkZ2GQknRoXXhYtOtVwBQCWUEm yMyEPQ3iqJ9GTbTw3bXC8vbdxH97jvJTIVMCPagAcht8cvYE1h2lNVNqliwU6LY7pm eeVusImKeVsww== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gavrilov Ilia , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 341/715] net: kcm: fix incorrect parameter validation in the kcm_getsockopt) function Date: Sun, 24 Mar 2024 18:28:40 -0400 Message-ID: <20240324223455.1342824-342-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gavrilov Ilia [ Upstream commit 3ed5f415133f9b7518fbe55ba9ae9a3f5e700929 ] The 'len' variable can't be negative when assigned the result of 'min_t' because all 'min_t' parameters are cast to unsigned int, and then the minimum one is chosen. To fix the logic, check 'len' as read from 'optlen', where the types of relevant variables are (signed) int. Fixes: ab7ac4eb9832 ("kcm: Kernel Connection Multiplexor module") Signed-off-by: Gavrilov Ilia Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/kcm/kcmsock.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c index 1184d40167b86..eda933c097926 100644 --- a/net/kcm/kcmsock.c +++ b/net/kcm/kcmsock.c @@ -1152,10 +1152,11 @@ static int kcm_getsockopt(struct socket *sock, int = level, int optname, if (get_user(len, optlen)) return -EFAULT; =20 - len =3D min_t(unsigned int, len, sizeof(int)); if (len < 0) return -EINVAL; =20 + len =3D min_t(unsigned int, len, sizeof(int)); + switch (optname) { case KCM_RECV_DISABLE: val =3D kcm->rx_disabled; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5AE82183B92; Sun, 24 Mar 2024 22:40:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320034; cv=none; b=jk/XhPPSJ1oy6/tmvQXJVFSR86uDeKQDNN9/dq4fsZrEtLBRIFEEjU1pkehqhAyckf2GrJULaLwN3cSfZKEwxPl4kgKMwjxL8q2l5yTHOTDvDk2nk4zCME2NROm7/+QGPHDN/a6SJPue2XoRIQ1WWV2jHN6sw2Qy9Doa/sQDumQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320034; c=relaxed/simple; bh=Tbtb83D82ba5U9j7pO0kR77XqAV2NqjGsYQcqKEPiH0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LOqdsfCOzQ9axX7o34pQ4T/qFGfTrnNHKZfD/PPdt5byRpIK48K4bwVEw8cTeQv2i/BdbaUGR/Ofbi9lDcimhExSpfwUwaz+m8zgjF7dRl8ek/VfjnlLC6tEAQrWcbzIP148u+99a1I2YaU9W9PusesvxS8ImskuyBcZ+fgvNDA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FFLRXasI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FFLRXasI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 41998C43390; Sun, 24 Mar 2024 22:40:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320033; bh=Tbtb83D82ba5U9j7pO0kR77XqAV2NqjGsYQcqKEPiH0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FFLRXasI22Tfjx7R9Y89te2gVG/TrLaRx5CpLd60mllYWlRiLv0zZtCdVgvhqgKDm XlVxCryp3dYDE+HgCa+dQn+qNw9n4vBHwuen1F/iJL6m7GUHJwDCqIYf3F1IEk/Nq/ rfhtSm/OGubgYeNDz/tvqxsr+uxT3gr0vPdYQEaLOGdOIskObJgnfW716cVxAmrLz5 Ce4BxeETRxOBgJzakX5FEqXvFrAqypIJqYLkAKp9LlILnN02FVrKaKa6e3m69f+dn3 HntdbS5R+rt693+yFNDn7RuU4TeMbAQubt+eftuBsoJLut+cE64aravO6dUNbYuK7G WqcV1oDF9kdCw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Gavrilov Ilia , "David S . Miller" , Sasha Levin Subject: [PATCH 6.8 342/715] net/x25: fix incorrect parameter validation in the x25_getsockopt() function Date: Sun, 24 Mar 2024 18:28:41 -0400 Message-ID: <20240324223455.1342824-343-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Gavrilov Ilia [ Upstream commit d6eb8de2015f0c24822e47356f839167ebde2945 ] The 'len' variable can't be negative when assigned the result of 'min_t' because all 'min_t' parameters are cast to unsigned int, and then the minimum one is chosen. To fix the logic, check 'len' as read from 'optlen', where the types of relevant variables are (signed) int. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Gavrilov Ilia Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- net/x25/af_x25.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c index f7a7c7798c3b2..d18d51412cc00 100644 --- a/net/x25/af_x25.c +++ b/net/x25/af_x25.c @@ -460,12 +460,12 @@ static int x25_getsockopt(struct socket *sock, int le= vel, int optname, if (get_user(len, optlen)) goto out; =20 - len =3D min_t(unsigned int, len, sizeof(int)); - rc =3D -EINVAL; if (len < 0) goto out; =20 + len =3D min_t(unsigned int, len, sizeof(int)); + rc =3D -EFAULT; if (put_user(len, optlen)) goto out; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 14C98183BAA; Sun, 24 Mar 2024 22:40:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320035; cv=none; b=ip0V8uy1Gsmo6c/c+fGPaxds+GRtJHwuEVR46H3fw51lUVNd1MS4gyQA0pCECamxDmcwmmJD/5SeXfiR3dwkPAph/6n7UMLZvsMPHPlMBWNUYAPlIklC8HNnuNYCmPd6sCGQ3OBAvMXuELD6MKcDvnMsO0Zv+eq6BR+Rj9LxFxc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320035; c=relaxed/simple; bh=Vgkzwo37Keltrl0Mwke7Q+1JmJcXEaRiYrJXXdkBbTM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZEX1X1jiYKy7TwBLWTfTPi1Wmng/0WTxIwrVSkMJvl9UqNteUabsa05PGi5LwOs3tPx11Y7onx/6lZ/GfLObKmfmC+Q9Z/rhPGOSsB4KaGxzYKu8260NCNQXFyJdE0TaexYFNmzWFf5gjpDVfT4nH7zKxGkkennEEc28Bk4RvTA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WW4SElaF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WW4SElaF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 25220C43394; Sun, 24 Mar 2024 22:40:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320034; bh=Vgkzwo37Keltrl0Mwke7Q+1JmJcXEaRiYrJXXdkBbTM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WW4SElaFAdy2NuDNEqJvuJ+bs1k7du0NmT7Tbx6SFRQXjZk68iNJF/EGF/umQfDbB 9UaV0oiJ7ssS2FVvWDB+Wbb8AVwMSdO55ps2JCWgMaXMhm8e9B1JBmRiVHCszRlpBF ETO2N7DPAPKuIQNbnWYfWOzy1hknku1LNgifU3484VE3ZfONRVRfP6PJORdOOUdQXV 6lHCKRbH5kcL4i/beCMlTkVCV439Tu9RfuidXz+q+9wf4DhtfwDkr3S3MeqMgvUQ9D zAEIUnlTL7ZSw3ppY2RQTMykDi2tvLpr8d8LBkHMv74R3e4h25r54xvivS8x5PISMi s84CFHuxd7Vfg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: William Tu , Jiri Pirko , Simon Horman , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.8 343/715] devlink: Fix length of eswitch inline-mode Date: Sun, 24 Mar 2024 18:28:42 -0400 Message-ID: <20240324223455.1342824-344-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: William Tu [ Upstream commit 8f4cd89bf10607de08231d6d91a73dd63336808e ] Set eswitch inline-mode to be u8, not u16. Otherwise, errors below $ devlink dev eswitch set pci/0000:08:00.0 mode switchdev \ inline-mode network Error: Attribute failed policy validation. kernel answers: Numerical result out of rang netlink: 'devlink': attribute type 26 has an invalid length. Fixes: f2f9dd164db0 ("netlink: specs: devlink: add the remaining command to= generate complete split_ops") Signed-off-by: William Tu Reviewed-by: Jiri Pirko Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/20240310164547.35219-1-witu@nvidia.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- Documentation/netlink/specs/devlink.yaml | 2 +- net/devlink/netlink_gen.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/netlink/specs/devlink.yaml b/Documentation/netli= nk/specs/devlink.yaml index cf6eaa0da821b..09fbb4c03fc8d 100644 --- a/Documentation/netlink/specs/devlink.yaml +++ b/Documentation/netlink/specs/devlink.yaml @@ -290,7 +290,7 @@ attribute-sets: enum: eswitch-mode - name: eswitch-inline-mode - type: u16 + type: u8 enum: eswitch-inline-mode - name: dpipe-tables diff --git a/net/devlink/netlink_gen.c b/net/devlink/netlink_gen.c index c81cf2dd154f3..f9786d51f68f9 100644 --- a/net/devlink/netlink_gen.c +++ b/net/devlink/netlink_gen.c @@ -198,7 +198,7 @@ static const struct nla_policy devlink_eswitch_set_nl_p= olicy[DEVLINK_ATTR_ESWITC [DEVLINK_ATTR_BUS_NAME] =3D { .type =3D NLA_NUL_STRING, }, [DEVLINK_ATTR_DEV_NAME] =3D { .type =3D NLA_NUL_STRING, }, [DEVLINK_ATTR_ESWITCH_MODE] =3D NLA_POLICY_MAX(NLA_U16, 1), - [DEVLINK_ATTR_ESWITCH_INLINE_MODE] =3D NLA_POLICY_MAX(NLA_U16, 3), + [DEVLINK_ATTR_ESWITCH_INLINE_MODE] =3D NLA_POLICY_MAX(NLA_U8, 3), [DEVLINK_ATTR_ESWITCH_ENCAP_MODE] =3D NLA_POLICY_MAX(NLA_U8, 1), }; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 079EA184308; Sun, 24 Mar 2024 22:40:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320036; cv=none; b=II5tCYyCRpvW/oqfABB4QkuUPPTl9khPWWGNtdaxz+V4ZXca2MMAQbbh5ubl+PVJc4Ql9a7BHPVtu5hpUFUA8QuUcPqnZciStX9txldZ4WFoGYZelAnx+clhNbFtN7rwir+5D5GDLjARSvcRkHGY4rztYnydvahqCHPjeJaaa+A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320036; c=relaxed/simple; bh=FPBnRQhKMIBc/J0qBo7uQGtzOxuQ2Val9MKzDoQgzUo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JlRG3UH5AG3I/pab28psBCO+dr4CL9tIV66bURdaeodTzxjg9fqxLbWXnHGXkNaVkRxiauwUY2pl5vhbHvjO1KWtCYx2DBKnGbFaBO8UPvVj9ETtsNODdQsehXuHdUpfj99tjbZZtYUJr9U+XttP5ufkwhl38Xf5dSMK412oRY8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Ed1B3//0; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Ed1B3//0" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 38714C433A6; Sun, 24 Mar 2024 22:40:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320035; bh=FPBnRQhKMIBc/J0qBo7uQGtzOxuQ2Val9MKzDoQgzUo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Ed1B3//0d5zhR3A+Znr5aoOgBuYZxlQb2DGCejR/BRDlIitfW0irSmP9qpHXSbWxH K177OcfQmmwn0MQ1lPtnzg8nlnvg/IwH2EPS/1cGTf4RHrXKvpIxlwdxM1MSTv53YJ 8utEaFzxJVanesvyGwa1uhvX4V5Ax5zEQWucePPk9dbvFsX2Zx1MyKr7sTwCPqHF++ SGCpSBpWH8Bz8yulGXiVZ/i2seL3+9MLW4aBlp04cHQmMuvbkmjvCRiej5w2R08D6y G+AsrhZKJMd2Um/+uaGHJ9A79Tb6qxAICFIwfjKjg0IadevkWrj3EbQbtTX9OZjJHY SXqS9GNooveJA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hayes Wang , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.8 344/715] r8152: fix unknown device for choose_configuration Date: Sun, 24 Mar 2024 18:28:43 -0400 Message-ID: <20240324223455.1342824-345-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hayes Wang [ Upstream commit 46590b545df636aea0f9f7f2100d9963c0af5824 ] For the unknown device, rtl8152_cfgselector_choose_configuration() should return a negative value. Then, usb_choose_configuration() would set a configuration for CDC ECM or NCM mode. Otherwise, there is no usb interface driver for the device. Fixes: aa4f2b3e418e ("r8152: Choose our USB config with choose_configuratio= n() rather than probe()") Signed-off-by: Hayes Wang Link: https://lore.kernel.org/r/20240308075206.33553-436-nic_swsd@realtek.c= om Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/usb/r8152.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 0d0672d2a6545..51fe00c2b896e 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -10078,7 +10078,7 @@ static int rtl8152_cfgselector_choose_configuration= (struct usb_device *udev) * driver supports it. */ if (__rtl_get_hw_ver(udev) =3D=3D RTL_VER_UNKNOWN) - return 0; + return -ENODEV; =20 /* The vendor mode is not always config #1, so to find it out. */ c =3D udev->config; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 30F7318432A; Sun, 24 Mar 2024 22:40:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320037; cv=none; b=GjpaXKVCpdlVRz6eU6YU5aeDEZ06d6sX02Tb89TzD8QAsEUD4VdP/gGaNjHN+6cWc21bco/pzYixMK9n+YhlRUcOWtE/JWbaDm0yCz95clzG5yZJzwscd72br/n6kaR1CiUlDUk1/br7kKPc+hY/2YTGy+S0vvK0uoWFrpZWG4A= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320037; c=relaxed/simple; bh=PCEyESqUONtKRMCY+7M47ejrQsTEtigs2brUjBJLI5w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IOdNl5WiQmcLsJSod9qRFZLwLGOFcrUkg7uwEr4zFr+/qrqOjX/B9wCZRQMJIf4o9KV8weeanKJHFu5YrWutD4YvtzxQHC4uqLP1nTcRIx1H1eZd8yIkxHMGIcZkhajseEn31KWso9UGIfucTrvHtZrjTjR7Ps4Tg2b3P7aXwZE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=i0TWsthv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="i0TWsthv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1E186C43390; Sun, 24 Mar 2024 22:40:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320036; bh=PCEyESqUONtKRMCY+7M47ejrQsTEtigs2brUjBJLI5w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=i0TWsthvJPdSzen/rMPbd7sSyC0EbHN/lt/3pZxFRTcSUwLuT13iNsQBxWWZ240ke ZNDNxzrbuUbmct4mjdkQp0yP9W7cLXwZ2gDfvD/S4bwMSK2YPFGRFxMBeA9mYnzzQm fRADRn2cxZqXOX3NThaS5kUcc1ZS2/re+0iTSeAj4D/Ni3JRlZrAI6qq2fzbYyt9le Md63F0gfBdO7n6SK9HQY1y+c2vvoM0u4UrxoIi/yXMGUcRjXLHUXpj4GtBjcmQfIC+ 4nw/d4BIJhUPU3i2nX8UdZN4H/y9w5wNaniUhXFwYUtxxmThit17DTwIOdwt/kNj2t VvVPnaz1OhS0A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Duoming Zhou , Louis Peens , Jakub Kicinski , Sasha Levin Subject: [PATCH 6.8 345/715] nfp: flower: handle acti_netdevs allocation failure Date: Sun, 24 Mar 2024 18:28:44 -0400 Message-ID: <20240324223455.1342824-346-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Duoming Zhou [ Upstream commit 84e95149bd341705f0eca6a7fcb955c548805002 ] The kmalloc_array() in nfp_fl_lag_do_work() will return null, if the physical memory has run out. As a result, if we dereference the acti_netdevs, the null pointer dereference bugs will happen. This patch adds a check to judge whether allocation failure occurs. If it happens, the delayed work will be rescheduled and try again. Fixes: bb9a8d031140 ("nfp: flower: monitor and offload LAG groups") Signed-off-by: Duoming Zhou Reviewed-by: Louis Peens Link: https://lore.kernel.org/r/20240308142540.9674-1-duoming@zju.edu.cn Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/net/ethernet/netronome/nfp/flower/lag_conf.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c b/drivers= /net/ethernet/netronome/nfp/flower/lag_conf.c index 361d7c495e2d8..2c7bd6e80d993 100644 --- a/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c +++ b/drivers/net/ethernet/netronome/nfp/flower/lag_conf.c @@ -337,6 +337,11 @@ static void nfp_fl_lag_do_work(struct work_struct *wor= k) =20 acti_netdevs =3D kmalloc_array(entry->slave_cnt, sizeof(*acti_netdevs), GFP_KERNEL); + if (!acti_netdevs) { + schedule_delayed_work(&lag->work, + NFP_FL_LAG_DELAY); + continue; + } =20 /* Include sanity check in the loop. It may be that a bond has * changed between processing the last notification and the --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2A5DB5D74C; Sun, 24 Mar 2024 22:40:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320038; cv=none; b=keWVa1IUzLB02PnQ8fK68mkiwM/lhUhatDxUxkDxg9hL7waoAS0MGV2Dj9laEE5Mmh8rwjBtLRFw55L8uT8jJXX0miztWfkf/mQK2RuIyOxp5Dr4ddF6RhK831Ohfm8fsJsgL8shbX8mvr5KguINqXXRxELNQtUQ8TNK0TyNQxc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320038; c=relaxed/simple; bh=Hf/0iSxlOyzs7Gvuy/xTK00B0B5wdp+9ZWqBR3qUq8g=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Kg0Wqdqn4FVOWiWlh1qhtQVDFghU2szVVK57LNsdkix6I65KtmMu4884rKrxvO57m4xjR3xVeJGYA7lBOM43tr0HYNWt9J4lxrJS2jiGDBO5Rw8I/ZQcaf5LYE47ei70QLCu7idYZw5sRf8hUE0sld5hfPgSctNGCFb5q5I69P8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K4sQJZML; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K4sQJZML" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17C6EC433C7; Sun, 24 Mar 2024 22:40:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320038; bh=Hf/0iSxlOyzs7Gvuy/xTK00B0B5wdp+9ZWqBR3qUq8g=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K4sQJZMLhGgM4vowtTq7J3L217VGbc3cj1HslyNTh+Bzrc5Z0imcAKVCMGZnM2LW9 MkFXAF9OfzBdz+RxUNhoDdgUDHfWw11iRnZwRA5WJFqfIZ48D+Z++UzUrBrDFRgj3C N1mTICu2HCLLdZYG8tz7Tr1ftIwM2WIRC1d3H8iSgG2JWgaOobOs0uVy+D3wqUzLhO 8YRCWhF2wGvALRD5yy//5D7mdJHyvMjTJKi1knsqQNx8VJzhfnw7wVm4rfC+FGiH0M LleuC1dmFwTingPH+GMNCEwwsAIGGmtW+G+3khNMAoj4kNtbeB+Nv9hwYYCf7ep+Jv to+zKl/3PDX/A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Puranjay Mohan , "kernelci.org bot" , kernel test robot , Song Liu , Alexei Starovoitov , Sasha Levin Subject: [PATCH 6.8 346/715] bpf: hardcode BPF_PROG_PACK_SIZE to 2MB * num_possible_nodes() Date: Sun, 24 Mar 2024 18:28:45 -0400 Message-ID: <20240324223455.1342824-347-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Puranjay Mohan [ Upstream commit d6170e4aaf86424c24ce06e355b4573daa891b17 ] On some architectures like ARM64, PMD_SIZE can be really large in some configurations. Like with CONFIG_ARM64_64K_PAGES=3Dy the PMD_SIZE is 512MB. Use 2MB * num_possible_nodes() as the size for allocations done through the prog pack allocator. On most architectures, PMD_SIZE will be equal to 2MB in case of 4KB pages and will be greater than 2MB for bigger page sizes. Fixes: ea2babac63d4 ("bpf: Simplify bpf_prog_pack_[size|mask]") Reported-by: "kernelci.org bot" Closes: https://lore.kernel.org/all/7e216c88-77ee-47b8-becc-a0f780868d3c@si= rena.org.uk/ Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202403092219.dhgcuz2G-lkp@int= el.com/ Suggested-by: Song Liu Signed-off-by: Puranjay Mohan Message-ID: <20240311122722.86232-1-puranjay12@gmail.com> Signed-off-by: Alexei Starovoitov Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- kernel/bpf/core.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c index ea6843be2616c..026627226ec48 100644 --- a/kernel/bpf/core.c +++ b/kernel/bpf/core.c @@ -888,7 +888,12 @@ static LIST_HEAD(pack_list); * CONFIG_MMU=3Dn. Use PAGE_SIZE in these cases. */ #ifdef PMD_SIZE -#define BPF_PROG_PACK_SIZE (PMD_SIZE * num_possible_nodes()) +/* PMD_SIZE is really big for some archs. It doesn't make sense to + * reserve too much memory in one allocation. Hardcode BPF_PROG_PACK_SIZE = to + * 2MiB * num_possible_nodes(). On most architectures PMD_SIZE will be + * greater than or equal to 2MB. + */ +#define BPF_PROG_PACK_SIZE (SZ_2M * num_possible_nodes()) #else #define BPF_PROG_PACK_SIZE PAGE_SIZE #endif --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 19EA81327F7; Sun, 24 Mar 2024 22:40:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320039; cv=none; b=uqbhF4UqT5tPdhoyT2jInwrkr/CG1G9fHNfqi4C2o4SwF2SeZoiFjkWg8uvg+33Dnq6r2aLBkvqyaQxW5Tx/Y230bhONC48wXOvrfNJLREgiH5XDeakh+zzptr8PcxGRtSRcZXKRGCZUKh5cL8FV5Oxhr2muPIJ+pmQNbRiRrRU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320039; c=relaxed/simple; bh=MPJsfCYG3IQN5G/QHQfx5aTxiuzR9zsnaOhfuWbMtVI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ThhH1HdLDxEdvmUC2dHvpKs9zOntY47ZeNotEL8Fg0DkQ1AmTKUnpEvn1hsgkTSPKmNJtLFXXb79xSMOnpbHring7UllijQIjYvz+HbaMcks8LAMi8GCGOfTmyB4KhmZ8fzRFbSKjPdMUli8ZddH589VDyOsQ7acPrv3NTkzJ2U= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UtfoF4rF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UtfoF4rF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4238FC433A6; Sun, 24 Mar 2024 22:40:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320039; bh=MPJsfCYG3IQN5G/QHQfx5aTxiuzR9zsnaOhfuWbMtVI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UtfoF4rFgWMhsaC1bED+3EBLOYUl8QldKqPvBi7w/SBAwZGEniN2bKtgd7csW5SvS VYEaJjglqfUKFPnevaamF1z6A/WyrUu9N3M+GcGm2GXpt38tz0sZG3N12Ny6K01HYo GtmUjq2DuMKBNOliQKnFmHvbfxyl1tb/EjKLORF/qcGB4+O/lTLYumV9Uwd8kOMlKa 7kruMuoleVM13ZpC5Xv/swQ1oYHSRRfXbMB5BkaeRKuckHiliMJ+U0n6adkkbtRz2C 42e02Cdxib1e+N+R2kMmpP9+ghxOSbwVuy5YweQmWCGzABukE68QjvIbxY9SNDYxaL CLMzCVzHhFF0A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ming Lei , Patrick Plenefisch , Mike Snitzer , Sasha Levin Subject: [PATCH 6.8 347/715] dm raid: fix false positive for requeue needed during reshape Date: Sun, 24 Mar 2024 18:28:46 -0400 Message-ID: <20240324223455.1342824-348-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ming Lei [ Upstream commit b25b8f4b8ecef0f48c05f0c3572daeabefe16526 ] An empty flush doesn't have a payload, so it should never be looked at when considering to possibly requeue a bio for the case when a reshape is in progress. Fixes: 9dbd1aa3a81c ("dm raid: add reshaping support to the target") Reported-by: Patrick Plenefisch Signed-off-by: Ming Lei Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/md/dm-raid.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c index eb009d6bb03a1..13eb47b997f94 100644 --- a/drivers/md/dm-raid.c +++ b/drivers/md/dm-raid.c @@ -3329,14 +3329,14 @@ static int raid_map(struct dm_target *ti, struct bi= o *bio) struct mddev *mddev =3D &rs->md; =20 /* - * If we're reshaping to add disk(s)), ti->len and + * If we're reshaping to add disk(s), ti->len and * mddev->array_sectors will differ during the process * (ti->len > mddev->array_sectors), so we have to requeue * bios with addresses > mddev->array_sectors here or * there will occur accesses past EOD of the component * data images thus erroring the raid set. */ - if (unlikely(bio_end_sector(bio) > mddev->array_sectors)) + if (unlikely(bio_has_data(bio) && bio_end_sector(bio) > mddev->array_sect= ors)) return DM_MAPIO_REQUEUE; =20 md_handle_request(mddev, bio); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EEB01132816; Sun, 24 Mar 2024 22:40:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320040; cv=none; b=hpn5siXjnvp1pC+4wdYPQ6TGgciB9QH6E0/fQt3cj3ZGY5PuHkiGrXB0mcsVQwFq4Qckwandip8QcCsyEDI7hp7OGtGXH6g1fN7sFdu6AKH7s5LNZiRkGi1tjBUL+qoAfwPY+oIAGGouakOZYNQ8+WfgySGvGq9PICiKW/qhFlQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320040; c=relaxed/simple; bh=vN3j9v6c8tpDTvMyTzIX1vPcPw4IN6LGhMc4RM+tovY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KBJmk/syOPJBy3ASbUDD5CaGn6Pr/wax1Hvbc8TXQItr1DD06N7HSHoXdstECHsHPb8V25Cxp4K2fvPGxv3pDY1HciTiKnQ2e392jerYOUExdFW3E4hPnlqpwfHi0BnHobWDh+/wezwDuGu7YT5N2iaEfsnceP45ypoDP3Ittlc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ttKLGsTT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ttKLGsTT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3D198C433C7; Sun, 24 Mar 2024 22:40:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320039; bh=vN3j9v6c8tpDTvMyTzIX1vPcPw4IN6LGhMc4RM+tovY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ttKLGsTT6ukoiXkmZKLgDqbYAEnQHQOa7MYXDOfBhnC2W2Ysr17czTnh795+R7GFx 7y65wEau5f5FNx4csL3NWAnxI8x/ucTCD9LSTtagH3y/9VcAPJgFkNJ6fu4iESIxDi xvgOk2uCY3jkf8nnia4jAU343RTHhCamlGrWqqxbT2mYNxnotB/4Yv6l4CNj9yr3pH lOLOkuPKZWpTaIdStbZmWjCftP+BGw+0SusYuIAyocYzf/OSv67vbPmX5CvngRKWDf A40RJf91FE2241lwO36gvZm6DwgvigwxbiXFSSnd3prlR2PjKp9Px81PlI3zxiSJHl YNlhjQBowb0ZQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mikulas Patocka , Mike Snitzer , Sasha Levin Subject: [PATCH 6.8 348/715] dm: call the resume method on internal suspend Date: Sun, 24 Mar 2024 18:28:47 -0400 Message-ID: <20240324223455.1342824-349-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mikulas Patocka [ Upstream commit 65e8fbde64520001abf1c8d0e573561b4746ef38 ] There is this reported crash when experimenting with the lvm2 testsuite. The list corruption is caused by the fact that the postsuspend and resume methods were not paired correctly; there were two consecutive calls to the origin_postsuspend function. The second call attempts to remove the "hash_list" entry from a list, while it was already removed by the first call. Fix __dm_internal_resume so that it calls the preresume and resume methods of the table's targets. If a preresume method of some target fails, we are in a tricky situation. We can't return an error because dm_internal_resume isn't supposed to return errors. We can't return success, because then the "resume" and "postsuspend" methods would not be paired correctly. So, we set the DMF_SUSPENDED flag and we fake normal suspend - it may confuse userspace tools, but it won't cause a kernel crash. Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:56! invalid opcode: 0000 [#1] PREEMPT SMP CPU: 1 PID: 8343 Comm: dmsetup Not tainted 6.8.0-rc6 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/= 2014 RIP: 0010:__list_del_entry_valid_or_report+0x77/0xc0 RSP: 0018:ffff8881b831bcc0 EFLAGS: 00010282 RAX: 000000000000004e RBX: ffff888143b6eb80 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffffffff819053d0 RDI: 00000000ffffffff RBP: ffff8881b83a3400 R08: 00000000fffeffff R09: 0000000000000058 R10: 0000000000000000 R11: ffffffff81a24080 R12: 0000000000000001 R13: ffff88814538e000 R14: ffff888143bc6dc0 R15: ffffffffa02e4bb0 FS: 00000000f7c0f780(0000) GS:ffff8893f0a40000(0000) knlGS:0000000000000000 CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033 CR2: 0000000057fb5000 CR3: 0000000143474000 CR4: 00000000000006b0 Call Trace: ? die+0x2d/0x80 ? do_trap+0xeb/0xf0 ? __list_del_entry_valid_or_report+0x77/0xc0 ? do_error_trap+0x60/0x80 ? __list_del_entry_valid_or_report+0x77/0xc0 ? exc_invalid_op+0x49/0x60 ? __list_del_entry_valid_or_report+0x77/0xc0 ? asm_exc_invalid_op+0x16/0x20 ? table_deps+0x1b0/0x1b0 [dm_mod] ? __list_del_entry_valid_or_report+0x77/0xc0 origin_postsuspend+0x1a/0x50 [dm_snapshot] dm_table_postsuspend_targets+0x34/0x50 [dm_mod] dm_suspend+0xd8/0xf0 [dm_mod] dev_suspend+0x1f2/0x2f0 [dm_mod] ? table_deps+0x1b0/0x1b0 [dm_mod] ctl_ioctl+0x300/0x5f0 [dm_mod] dm_compat_ctl_ioctl+0x7/0x10 [dm_mod] __x64_compat_sys_ioctl+0x104/0x170 do_syscall_64+0x184/0x1b0 entry_SYSCALL_64_after_hwframe+0x46/0x4e RIP: 0033:0xf7e6aead ---[ end trace 0000000000000000 ]--- Fixes: ffcc39364160 ("dm: enhance internal suspend and resume interface") Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin --- drivers/md/dm.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/drivers/md/dm.c b/drivers/md/dm.c index 8dcabf84d866e..0dc3650c7f4ca 100644 --- a/drivers/md/dm.c +++ b/drivers/md/dm.c @@ -2945,6 +2945,9 @@ static void __dm_internal_suspend(struct mapped_devic= e *md, unsigned int suspend =20 static void __dm_internal_resume(struct mapped_device *md) { + int r; + struct dm_table *map; + BUG_ON(!md->internal_suspend_count); =20 if (--md->internal_suspend_count) @@ -2953,12 +2956,23 @@ static void __dm_internal_resume(struct mapped_devi= ce *md) if (dm_suspended_md(md)) goto done; /* resume from nested suspend */ =20 - /* - * NOTE: existing callers don't need to call dm_table_resume_targets - * (which may fail -- so best to avoid it for now by passing NULL map) - */ - (void) __dm_resume(md, NULL); - + map =3D rcu_dereference_protected(md->map, lockdep_is_held(&md->suspend_l= ock)); + r =3D __dm_resume(md, map); + if (r) { + /* + * If a preresume method of some target failed, we are in a + * tricky situation. We can't return an error to the caller. We + * can't fake success because then the "resume" and + * "postsuspend" methods would not be paired correctly, and it + * would break various targets, for example it would cause list + * corruption in the "origin" target. + * + * So, we fake normal suspend here, to make sure that the + * "resume" and "postsuspend" methods will be paired correctly. + */ + DMERR("Preresume method failed: %d", r); + set_bit(DMF_SUSPENDED, &md->flags); + } done: clear_bit(DMF_SUSPENDED_INTERNALLY, &md->flags); smp_mb__after_atomic(); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 75E025D8E8; Sun, 24 Mar 2024 22:40:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320041; cv=none; b=ttZt65F8QHZBS1XHq89WECHTmMHIzsj3xm6ArxyBRYrT0Ymr4TRVQta5EoFgkoDa7AV9Q1UG1jOqo5vW54vpV3s2vJLprShpY3d63ZJ3pGHRrctSDbs2SeSyPDtmCuUKY7T1MVQI8E1UvrCdMawhJHf6m/vqxq3/Rf6hT1Q/RLM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320041; c=relaxed/simple; bh=CmHz6jWUtmUH5j71hEdoZCyHHv5OIGWwqJJyu0uZFJA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LR5B5V+YQSvuaTJuf6ycaTc++OHmZeRY/CsO3kXcr/0FaC0w1xEfJKuj6LvPIKtM8mjHTsZ1mlJv5IyYe/zSZNtFvp1jVIz01jB3zN5Bre18YKYOC8UHICPAP+zCBrkXBZr0B59PY2qTbGvfMuriw7hMQIQqDe8lpKQMqL1H8gc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qVvEUP4H; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qVvEUP4H" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 20E9AC43330; Sun, 24 Mar 2024 22:40:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320041; bh=CmHz6jWUtmUH5j71hEdoZCyHHv5OIGWwqJJyu0uZFJA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qVvEUP4HdZnrVewsmg3JKk8IzmhD0pjd7kCCsdq/SPUm7NG2RN3wk5CF9qzOWBxlV rNqrJngKWXzsHCTQ1wYZMuij24lLbXP+T4H2VNekvZEozfmFPdSI6JKC+KrIn3jvZx 6AI3yqNFJqgmJlnm43pWCalC5faRTfiVPJ67Et+p7Q0qWMEm6wT5pQLfS5Cq9Ajvl/ /lRXVOLyzSW+c6ROd5UrmclxPXyq7oIFJlX8IvDLKcYEDEbeafFKkK9bo70JnIJEYi EqCOiM2e8O/NMktkg0A+Hq8eMwXLfUq63lc8a8Lo6E9hMdVbNfanZ2ov9PB8unu+0I xSPE60NRT0DNQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Brian Masney , Andrew Halaney , Javier Martinez Canillas , Thierry Reding , Hans de Goede , Sasha Levin Subject: [PATCH 6.8 349/715] fbdev/simplefb: change loglevel when the power domains cannot be parsed Date: Sun, 24 Mar 2024 18:28:48 -0400 Message-ID: <20240324223455.1342824-350-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Brian Masney [ Upstream commit 4350aa21cca48a5d951ba108290bad703fbc0630 ] When the power domains cannot be parsed, the message is incorrectly logged as an info message. Let's change this to an error since an error is returned. Fixes: 92a511a568e4 ("fbdev/simplefb: Add support for generic power-domains= ") Signed-off-by: Brian Masney Acked-by: Andrew Halaney Acked-by: Javier Martinez Canillas Acked-by: Thierry Reding Signed-off-by: Hans de Goede Link: https://patchwork.freedesktop.org/patch/msgid/20231212195754.232303-1= -bmasney@redhat.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/video/fbdev/simplefb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c index 6f58ee276ad1b..028a565250476 100644 --- a/drivers/video/fbdev/simplefb.c +++ b/drivers/video/fbdev/simplefb.c @@ -470,7 +470,7 @@ static int simplefb_attach_genpds(struct simplefb_par *= par, if (err =3D=3D -ENOENT) return 0; =20 - dev_info(dev, "failed to parse power-domains: %d\n", err); + dev_err(dev, "failed to parse power-domains: %d\n", err); return err; } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 03AFD184F0E; Sun, 24 Mar 2024 22:40:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320042; cv=none; b=DrAM481EWMBlxAlxrSSn40lctqx/awQRceo20c9yJD3NMgJ9oNdM1Xedi9rl+fsF5JpCZyOz74OVo2xgNGQKtG1885GOiame4rh1Sp7hd3mMSmnEqDUMBGdXLjEOdLm2hgLXctZCEtbs6YfduPVh8ouAoeps3gOp37iJZaoe4IE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320042; c=relaxed/simple; bh=1wD1lMemO0UeL75hTPilrXieqNAbYo6cSZgOGib9LQ8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=alQoa0aTNK7GRU+nhuM4RhA89lIvN/oeRuaC4kLeEqcESounLK6muP/yKjJileykuhJKYFxmw1vacu2JWrmDC6u+9qgXILUKYegSMWPVDSmbraFmFpzRYZ/wVrxcDTPUhiwHaSxifPIoS18e4xZn+x4wlS1WX3JlRkkvV+Nbei8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gpJx3hUF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="gpJx3hUF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 468C0C433C7; Sun, 24 Mar 2024 22:40:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320041; bh=1wD1lMemO0UeL75hTPilrXieqNAbYo6cSZgOGib9LQ8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=gpJx3hUFCMHfU7vGziacMttX6Kr8GJN5wAMxLC8drdjiVYMyPoYkLNvZ1/0vAtK84 MUCkCqX/lHysGqPbbfbNST6z3Wn2Eh+w4etSFAe5El1gGG2WBkGcvhzGdKvefHjQBR Al8dd0XlCaymXMYnkw35DebDyXs7u5M1aDpNces3z+mqUnNinruUBmi7kYe+fOOhc6 SA30XluDD+TKE0NvdyWzS7WWqU62kRH9W4Cc8h4GqAfUEIguuRDwI+ONEDmpcIDT07 0UxNa1XrxCjmAP234aJe3oEyHc0qyLIMXXM9bDqtn4q8QnqqPnR+I9htHT9ptI+rDo QzpXgvO9tu/1w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chen Ni , Thierry Reding , Sasha Levin Subject: [PATCH 6.8 350/715] drm/tegra: dsi: Add missing check for of_find_device_by_node Date: Sun, 24 Mar 2024 18:28:49 -0400 Message-ID: <20240324223455.1342824-351-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chen Ni [ Upstream commit afe6fcb9775882230cd29b529203eabd5d2a638d ] Add check for the return value of of_find_device_by_node() and return the error if it fails in order to avoid NULL pointer dereference. Fixes: e94236cde4d5 ("drm/tegra: dsi: Add ganged mode support") Signed-off-by: Chen Ni Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20231024080738.825553-1= -nichen@iscas.ac.cn Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/tegra/dsi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c index fbfe92a816d4b..e419b76e57d3e 100644 --- a/drivers/gpu/drm/tegra/dsi.c +++ b/drivers/gpu/drm/tegra/dsi.c @@ -1544,9 +1544,11 @@ static int tegra_dsi_ganged_probe(struct tegra_dsi *= dsi) np =3D of_parse_phandle(dsi->dev->of_node, "nvidia,ganged-mode", 0); if (np) { struct platform_device *gangster =3D of_find_device_by_node(np); + of_node_put(np); + if (!gangster) + return -EPROBE_DEFER; =20 dsi->slave =3D platform_get_drvdata(gangster); - of_node_put(np); =20 if (!dsi->slave) { put_device(&gangster->dev); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 403581856AE; Sun, 24 Mar 2024 22:40:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320043; cv=none; b=p1zY2H5fLWOYYoJ49kb46auOMu2/PAuuDNhFfX47beUYO6O/XW2teYqsv0lOW+EjnqCFEeROWEVCooDBv8/w2eNZVOB975t/MEqJaW5zm74cgLKxBG9oeXbGLyoMM0B05eMVStJogA3zdHfekDN3ewWgH0sZK+pqTcPSMnCaEDc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320043; c=relaxed/simple; bh=6PYzZwYgCOek78YwuwPl9iW6KBnvVCcfXpsYYRC/mW0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AKa+RBrwYFoFgyfen0BkVMupLx3WAvEYPFWkb0pK7+S2wrAfcZ6Uh0UTS1hClMigTU3Ce0BG4XArV63Ox0NUPvnb7qjE7Hje3RCQY/yo+LqXcAVAr+J3XBNZpnadDhBIDzxyKFkMEaiaiFGHSV0qEAgTpBPsvI/aZgQPg4bHDvc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PwBS5yZB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PwBS5yZB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28028C43394; Sun, 24 Mar 2024 22:40:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320042; bh=6PYzZwYgCOek78YwuwPl9iW6KBnvVCcfXpsYYRC/mW0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PwBS5yZBu/nIucAtD0rFFqbrJm6DAXowhk8yAq3Wt0UNwVwNqgvKL81DIVEBIoi6q K6TgJHmun/4aoRZt4uILZPcjQW1ZVvmNxUAgvqWKzkPYLXgivI6XoQ2DlR1+qRWbwH Lk/5oKb+TwiyyqLedrId8UtTMaB2Hgv7W3JJin5m+GNXVyHrYTxE7x1zbPLrWwRPpG aHHmHkpstV5dFA0I0rWb433myCbnpga8W6BaT31er+0qAdEsU+Q9k+z+OPOFYgZhwt DsmGDsa3OJdw2JE55/80TqyTr27mFePpud3WChKQGFQdDf3FICgRZZY5GJd4OZHVCu vL9s2LTTjpagQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zhang Shurong , Thierry Reding , Sasha Levin Subject: [PATCH 6.8 351/715] drm/tegra: dpaux: Fix PM disable depth imbalance in tegra_dpaux_probe Date: Sun, 24 Mar 2024 18:28:50 -0400 Message-ID: <20240324223455.1342824-352-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zhang Shurong [ Upstream commit 0800880f4eb789b7d299db40f2e86e056bd33a4e ] The pm_runtime_enable function increases the power disable depth, which means that we must perform a matching decrement on the error handling path to maintain balance within the given context. Additionally, we need to address the same issue for pm_runtime_get_sync. We fix this by invoking pm_runtime_disable and pm_runtime_put_sync when error returns. Fixes: 82b81b3ec1a7 ("drm/tegra: dpaux: Implement runtime PM") Signed-off-by: Zhang Shurong Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/tencent_B13DB7F6C0023C4= 6157250A524966F326A09@qq.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/tegra/dpaux.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/tegra/dpaux.c b/drivers/gpu/drm/tegra/dpaux.c index ef02d530f78d7..ae12d001a04bf 100644 --- a/drivers/gpu/drm/tegra/dpaux.c +++ b/drivers/gpu/drm/tegra/dpaux.c @@ -522,7 +522,7 @@ static int tegra_dpaux_probe(struct platform_device *pd= ev) if (err < 0) { dev_err(dpaux->dev, "failed to request IRQ#%u: %d\n", dpaux->irq, err); - return err; + goto err_pm_disable; } =20 disable_irq(dpaux->irq); @@ -542,7 +542,7 @@ static int tegra_dpaux_probe(struct platform_device *pd= ev) */ err =3D tegra_dpaux_pad_config(dpaux, DPAUX_PADCTL_FUNC_I2C); if (err < 0) - return err; + goto err_pm_disable; =20 #ifdef CONFIG_GENERIC_PINCONF dpaux->desc.name =3D dev_name(&pdev->dev); @@ -555,7 +555,8 @@ static int tegra_dpaux_probe(struct platform_device *pd= ev) dpaux->pinctrl =3D devm_pinctrl_register(&pdev->dev, &dpaux->desc, dpaux); if (IS_ERR(dpaux->pinctrl)) { dev_err(&pdev->dev, "failed to register pincontrol\n"); - return PTR_ERR(dpaux->pinctrl); + err =3D PTR_ERR(dpaux->pinctrl); + goto err_pm_disable; } #endif /* enable and clear all interrupts */ @@ -571,10 +572,15 @@ static int tegra_dpaux_probe(struct platform_device *= pdev) err =3D devm_of_dp_aux_populate_ep_devices(&dpaux->aux); if (err < 0) { dev_err(dpaux->dev, "failed to populate AUX bus: %d\n", err); - return err; + goto err_pm_disable; } =20 return 0; + +err_pm_disable: + pm_runtime_put_sync(&pdev->dev); + pm_runtime_disable(&pdev->dev); + return err; } =20 static void tegra_dpaux_remove(struct platform_device *pdev) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1D3D11856CE; Sun, 24 Mar 2024 22:40:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320044; cv=none; b=es9ECrDWhaKMVoQ/RejpxPs6fQYRsPDIuyRQkqBzhTsU9ERrY48oP8c3fHHegDyOR5KaooWbIGHhIaoSWTx5bltSRSGLLkxdvQKed0Bue0jkcVdBMpV10p5c/xTYoLVT7CnA6rgnpJVaPAgbZc47t72+veWpZ9529NY/CoWqKiE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320044; c=relaxed/simple; bh=qmN3b4C2aieEROCXbe9bEVu5uvgLY4liLvY7/rWUvmk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=B1I+NdFf0rCipjFt0E/ND6dB+K+XSk69ztkSywTgWsrqlI6MVtQO1//o/7Nz1DRi1Gyq289H+/LrTBcXBfXXDoVH0PgVcG/+K55FQyAjRjGEyuaMZDaU8SNJuFOZto+UFfoygqT0nO1ixjeQdci6RpaLG+cmPFXcstWYL6nJEZ0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GeOE6H/J; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GeOE6H/J" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C7EAC43390; Sun, 24 Mar 2024 22:40:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320043; bh=qmN3b4C2aieEROCXbe9bEVu5uvgLY4liLvY7/rWUvmk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GeOE6H/JIMMYhBGStATGde3xrhtJGaR9os+ZaU1wldWfJKY2fbFhalhdvWSa0Z+xj 0kvrTGGSFcKoiLncEEt3Wu8s84KeY3CAX8QBHJ8iBOVT7sGRSfR/YlZGpjnB2lklH5 kzzbeKCkitm/MrUxJGZkvpjyHLDuo2tyUwa6hUMTNvl8tJADLCHA54R/Eoa5yHvPVY ZhIf+ZSRj0+dabCe90Hq+2l87+4kUAnuQWCev/OtjVybjcVMkzt3fl0P+xywSRsv0R HylrH113Gwhb3Z203o/5/4QPf+K7HMfKLzxjyTjDrOl2ll9ZjsMv9FIx5n11oMJZVP IXfX6y2fH1tpg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christophe JAILLET , Thierry Reding , Sasha Levin Subject: [PATCH 6.8 352/715] drm/tegra: dsi: Fix some error handling paths in tegra_dsi_probe() Date: Sun, 24 Mar 2024 18:28:51 -0400 Message-ID: <20240324223455.1342824-353-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Christophe JAILLET [ Upstream commit 830c1ded356369cd1303e8bb87ce3fea6e744de8 ] If an error occurs after calling tegra_output_probe(), tegra_output_remove() should be called as already done in the remove function. Fixes: dec727399a4b ("drm/tegra: Add DSI support") Signed-off-by: Christophe JAILLET Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/16820073278d031f6c474a0= 8d5f22a255158585e.1693667005.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/tegra/dsi.c | 54 ++++++++++++++++++++++++------------- 1 file changed, 35 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c index e419b76e57d3e..0c8ad8ee5009a 100644 --- a/drivers/gpu/drm/tegra/dsi.c +++ b/drivers/gpu/drm/tegra/dsi.c @@ -1596,44 +1596,58 @@ static int tegra_dsi_probe(struct platform_device *= pdev) =20 if (!pdev->dev.pm_domain) { dsi->rst =3D devm_reset_control_get(&pdev->dev, "dsi"); - if (IS_ERR(dsi->rst)) - return PTR_ERR(dsi->rst); + if (IS_ERR(dsi->rst)) { + err =3D PTR_ERR(dsi->rst); + goto remove; + } } =20 dsi->clk =3D devm_clk_get(&pdev->dev, NULL); - if (IS_ERR(dsi->clk)) - return dev_err_probe(&pdev->dev, PTR_ERR(dsi->clk), - "cannot get DSI clock\n"); + if (IS_ERR(dsi->clk)) { + err =3D dev_err_probe(&pdev->dev, PTR_ERR(dsi->clk), + "cannot get DSI clock\n"); + goto remove; + } =20 dsi->clk_lp =3D devm_clk_get(&pdev->dev, "lp"); - if (IS_ERR(dsi->clk_lp)) - return dev_err_probe(&pdev->dev, PTR_ERR(dsi->clk_lp), - "cannot get low-power clock\n"); + if (IS_ERR(dsi->clk_lp)) { + err =3D dev_err_probe(&pdev->dev, PTR_ERR(dsi->clk_lp), + "cannot get low-power clock\n"); + goto remove; + } =20 dsi->clk_parent =3D devm_clk_get(&pdev->dev, "parent"); - if (IS_ERR(dsi->clk_parent)) - return dev_err_probe(&pdev->dev, PTR_ERR(dsi->clk_parent), - "cannot get parent clock\n"); + if (IS_ERR(dsi->clk_parent)) { + err =3D dev_err_probe(&pdev->dev, PTR_ERR(dsi->clk_parent), + "cannot get parent clock\n"); + goto remove; + } =20 dsi->vdd =3D devm_regulator_get(&pdev->dev, "avdd-dsi-csi"); - if (IS_ERR(dsi->vdd)) - return dev_err_probe(&pdev->dev, PTR_ERR(dsi->vdd), - "cannot get VDD supply\n"); + if (IS_ERR(dsi->vdd)) { + err =3D dev_err_probe(&pdev->dev, PTR_ERR(dsi->vdd), + "cannot get VDD supply\n"); + goto remove; + } =20 err =3D tegra_dsi_setup_clocks(dsi); if (err < 0) { dev_err(&pdev->dev, "cannot setup clocks\n"); - return err; + goto remove; } =20 regs =3D platform_get_resource(pdev, IORESOURCE_MEM, 0); dsi->regs =3D devm_ioremap_resource(&pdev->dev, regs); - if (IS_ERR(dsi->regs)) - return PTR_ERR(dsi->regs); + if (IS_ERR(dsi->regs)) { + err =3D PTR_ERR(dsi->regs); + goto remove; + } =20 dsi->mipi =3D tegra_mipi_request(&pdev->dev, pdev->dev.of_node); - if (IS_ERR(dsi->mipi)) - return PTR_ERR(dsi->mipi); + if (IS_ERR(dsi->mipi)) { + err =3D PTR_ERR(dsi->mipi); + goto remove; + } =20 dsi->host.ops =3D &tegra_dsi_host_ops; dsi->host.dev =3D &pdev->dev; @@ -1664,6 +1678,8 @@ static int tegra_dsi_probe(struct platform_device *pd= ev) mipi_dsi_host_unregister(&dsi->host); mipi_free: tegra_mipi_free(dsi->mipi); +remove: + tegra_output_remove(&dsi->output); return err; } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A33705DF05; Sun, 24 Mar 2024 22:40:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320044; cv=none; b=HQO3e/J5F2T0Bfb6mk9dMnARmXp1QGLf6GZLeymRMuw5U1wzORZJCO+O8Vd4hxbBc7Knnmk0kuje7TAOuxQpFpFunGVFTz7RLRe7mZjJegOqaK4cv8gJUdX0rLBzrOct6itnfjf/T1gH1Je3Yz1ep5Xb660t7xO/7Tz6Suw0QH0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320044; c=relaxed/simple; bh=H3YOOhBig6iwhtefRcb2o7O5wuSRi1oZdbrtIM+94i4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sNX0DehHUhSmCqWxrNth4F687rwW5Glt+Qj9uINpagYwHPcme9qeKfqkPjYWdt5J85bBrSok6qQs4pLu7/nTsxPeQp246uyf7ndXuXaKY1O4/pN0fUTcAqaI7MsHCpjoPKqmK6YhQ82VFBa5/42YbwmdPFAfjb55tgqErIkW8Vk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=GgLKdurT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="GgLKdurT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E356BC433C7; Sun, 24 Mar 2024 22:40:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320044; bh=H3YOOhBig6iwhtefRcb2o7O5wuSRi1oZdbrtIM+94i4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=GgLKdurTB13tB3j2bJV1Yqyr1eu+rdwf6QegniUoxhQ7yTPgP+st6e8d6zOC7ByW0 dBmLggDruqNs/A2C0/s5tGAjB4E0IiIHKUcG+JW0jD7OtDbLhsDVvlJ1+y4bDYTHFg 8iXsY0M5MNk454+6i6b1UYocDrDIPBjGqo7H9WhcqaECWC6fiWTWvw9mTeWjTH650g RWqYPuJZzgZ8vgK9JLpKtLLZH+yp/UDih3JSMgTyv5PHB3UHXLh4ssgHMTrcuhiw8S Jrf+Lnv7XsPoP27kCaKZv/5rmjVgnwJSv958C4+lMnLoLjQsi2pJtFQ+TllCJEHFIS 1BmtP6DHPY1fQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christophe JAILLET , Thierry Reding , Sasha Levin Subject: [PATCH 6.8 353/715] drm/tegra: dsi: Fix missing pm_runtime_disable() in the error handling path of tegra_dsi_probe() Date: Sun, 24 Mar 2024 18:28:52 -0400 Message-ID: <20240324223455.1342824-354-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Christophe JAILLET [ Upstream commit 5286a9fc280c45b6b307ee1b07f7a997e042252c ] If an error occurs after calling pm_runtime_enable(), pm_runtime_disable() should be called as already done in the remove function. Fixes: ef8187d75265 ("drm/tegra: dsi: Implement runtime PM") Signed-off-by: Christophe JAILLET Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/ee4a15c9cd4b574a55cd67c= 30d2411239ba2cee9.1693667005.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/tegra/dsi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c index 0c8ad8ee5009a..db606e151afc8 100644 --- a/drivers/gpu/drm/tegra/dsi.c +++ b/drivers/gpu/drm/tegra/dsi.c @@ -1675,6 +1675,7 @@ static int tegra_dsi_probe(struct platform_device *pd= ev) return 0; =20 unregister: + pm_runtime_disable(&pdev->dev); mipi_dsi_host_unregister(&dsi->host); mipi_free: tegra_mipi_free(dsi->mipi); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8862C13C9CC; Sun, 24 Mar 2024 22:40:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320046; cv=none; b=t29xjpjkJ0UuKvCGVCqNcYstFFF5Qv5ntwbFs69LCg4hl6iwBPhAKQyubSHYu+s+xdsYgw1O7l+87R9ywCxTRSN9NCBOFT+psIPpJ7Bp/00lNn9xg7mB2SB8RGXrKyrL3yExrVr1SRx/sDaJCEpxdB/fjdByaNxXczpMX38uwO8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320046; c=relaxed/simple; bh=E4/QfkdetyAy347aC7SD1ktF+sQbA0mQj8jR4J/AD9E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fdCRa+pkY2/eM5oHCPQdPunJxMaESZK5nkqFnofZC9Sxg6ESsUEl0j9owWgwQOc52LiF1KtuDDiVazDAf+LTuU5zEj29H92lQw/fH42Ot+Z11yubQDAxWHDikjL2nDVyy7CsvlqnqntIsK2eTI1WJdM54zTLU429wFEfnrfctcA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=RojH6K0U; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="RojH6K0U" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C657DC43394; Sun, 24 Mar 2024 22:40:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320045; bh=E4/QfkdetyAy347aC7SD1ktF+sQbA0mQj8jR4J/AD9E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=RojH6K0UkIXF38rV/t31ydmhWsebt9sjGSqoWMZe6ZCIbeHWJ2wsInXH+Tfrp7EWj fPrdE3+K9gQtl988tiEkI0gRS1AF3ZExAWqEmUlReI3XFtl9iOx8B78FEtSoXEkMV3 b5hf6Wkq7EuBBapY0DhXNTEBfQWqFfurC7NpWNQzvjdfRsCxIdQDKAHfjgrC0alvqd y4pqEYRB9vcJYpqD8VhjuQNyv6kgDI4NEfVZlkMAWkYVc1KzjBOKQdcgwhP6DLx0Sf /5WGhLbuq75xc1N0mQJnKCsYGoH7E8gOADDhQFeX0YP3iw1/p5p6HQ8rA+MgG5nG+w lQuaA6U0H+YlQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christophe JAILLET , Thierry Reding , Sasha Levin Subject: [PATCH 6.8 354/715] drm/tegra: hdmi: Fix some error handling paths in tegra_hdmi_probe() Date: Sun, 24 Mar 2024 18:28:53 -0400 Message-ID: <20240324223455.1342824-355-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Christophe JAILLET [ Upstream commit 643ae131b8598fb2940c92c7d23fe62823a119c8 ] If an error occurs after calling tegra_output_probe(), tegra_output_remove() should be called as already done in the remove function. Fixes: 59d29c0ec93f ("drm/tegra: Allocate resources at probe time") Signed-off-by: Christophe JAILLET Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/9b7c564eb71977678b20abd= 73ee52001a51cf327.1693667005.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/tegra/hdmi.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c index a1fcee665023b..417fb884240a6 100644 --- a/drivers/gpu/drm/tegra/hdmi.c +++ b/drivers/gpu/drm/tegra/hdmi.c @@ -1856,12 +1856,14 @@ static int tegra_hdmi_probe(struct platform_device = *pdev) return err; =20 hdmi->regs =3D devm_platform_ioremap_resource(pdev, 0); - if (IS_ERR(hdmi->regs)) - return PTR_ERR(hdmi->regs); + if (IS_ERR(hdmi->regs)) { + err =3D PTR_ERR(hdmi->regs); + goto remove; + } =20 err =3D platform_get_irq(pdev, 0); if (err < 0) - return err; + goto remove; =20 hdmi->irq =3D err; =20 @@ -1870,18 +1872,18 @@ static int tegra_hdmi_probe(struct platform_device = *pdev) if (err < 0) { dev_err(&pdev->dev, "failed to request IRQ#%u: %d\n", hdmi->irq, err); - return err; + goto remove; } =20 platform_set_drvdata(pdev, hdmi); =20 err =3D devm_pm_runtime_enable(&pdev->dev); if (err) - return err; + goto remove; =20 err =3D devm_tegra_core_dev_init_opp_table_common(&pdev->dev); if (err) - return err; + goto remove; =20 INIT_LIST_HEAD(&hdmi->client.list); hdmi->client.ops =3D &hdmi_client_ops; @@ -1891,10 +1893,14 @@ static int tegra_hdmi_probe(struct platform_device = *pdev) if (err < 0) { dev_err(&pdev->dev, "failed to register host1x client: %d\n", err); - return err; + goto remove; } =20 return 0; + +remove: + tegra_output_remove(&hdmi->output); + return err; } =20 static void tegra_hdmi_remove(struct platform_device *pdev) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 97DC713C9D0; Sun, 24 Mar 2024 22:40:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320046; cv=none; b=QXnHaTGaYPCnUlsT3v0u9fVtCBs14ITxpAwyxnrCYcfGAYfFekDpV25TXNRUcT9htEm8E6L/0jB4zq0Jm2dXnmhl9fzSGiS9K7tsIriMAtsJ8mq9QVE0kqOC3MXAgf1AJZOQzKFVU8nOj8fIcXdilE1kxgyuQHp3fkimWMTeW4U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320046; c=relaxed/simple; bh=+vKf/AD+EU5ShwD9w5bCge7Hc87d+rNN8o9xeCJe6BY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lP5PyN0nDNQepbkracX/si1tEO/WLQkh3BjLLRtbAdv3isVs3yVhQRm1nMWpX1LtAQ/0uG8N96ACjhsbQ/Tvj81l1PaV/Muj9A9Vo0yTlxPy2RfGGrPRpzMG1FgBYB+/V/DT/APT7oM952SqVzVeniMKHJlHotdhBY5YcvA0mQ4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jyyJcj0E; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jyyJcj0E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ADE58C433C7; Sun, 24 Mar 2024 22:40:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320046; bh=+vKf/AD+EU5ShwD9w5bCge7Hc87d+rNN8o9xeCJe6BY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=jyyJcj0E3jCPCdvdCnzFmTJ8rmf1rLKX7r7SdFRXcif3esiDtcP77n47APsczLFRZ KboKzx5ZV/pyMjzZHDytmLGOJY5TeOI5cbte9/ZZ3u7l6UvxQUUSuISlXwnJ7igjwI 0y1SCmeyzvlH1hQawzRl2/s7mhhBDdhv/80eouEKFM3TpNlu6KWnwEPenjBEOuuB/e ixuQI/UMh5v+YsWzIdn+oHPJuslIK8pjrQztnXfaWd1fu4B7NoOU4pjxXx51LNtn1R aaMusXO+vS1uyeLSl9egaMKOvD+KyY2L+t+XUkCCi09Awob5mhMJv3bcV3MK9KfZfP 2OyhBqhU71OEA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christophe JAILLET , Thierry Reding , Sasha Levin Subject: [PATCH 6.8 355/715] drm/tegra: rgb: Fix some error handling paths in tegra_dc_rgb_probe() Date: Sun, 24 Mar 2024 18:28:54 -0400 Message-ID: <20240324223455.1342824-356-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Christophe JAILLET [ Upstream commit bc456b5d93dbfdbd89f2a036f4f3d8026595f9e4 ] If an error occurs after calling tegra_output_probe(), tegra_output_remove() should be called as already done in the remove function. Fixes: 59d29c0ec93f ("drm/tegra: Allocate resources at probe time") Signed-off-by: Christophe JAILLET Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/0001f61eb89048bc3624162= 9b564195689cf54b6.1693667005.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/tegra/rgb.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c index fc66bbd913b24..53c492b13d129 100644 --- a/drivers/gpu/drm/tegra/rgb.c +++ b/drivers/gpu/drm/tegra/rgb.c @@ -225,26 +225,28 @@ int tegra_dc_rgb_probe(struct tegra_dc *dc) rgb->clk =3D devm_clk_get(dc->dev, NULL); if (IS_ERR(rgb->clk)) { dev_err(dc->dev, "failed to get clock\n"); - return PTR_ERR(rgb->clk); + err =3D PTR_ERR(rgb->clk); + goto remove; } =20 rgb->clk_parent =3D devm_clk_get(dc->dev, "parent"); if (IS_ERR(rgb->clk_parent)) { dev_err(dc->dev, "failed to get parent clock\n"); - return PTR_ERR(rgb->clk_parent); + err =3D PTR_ERR(rgb->clk_parent); + goto remove; } =20 err =3D clk_set_parent(rgb->clk, rgb->clk_parent); if (err < 0) { dev_err(dc->dev, "failed to set parent clock: %d\n", err); - return err; + goto remove; } =20 rgb->pll_d_out0 =3D clk_get_sys(NULL, "pll_d_out0"); if (IS_ERR(rgb->pll_d_out0)) { err =3D PTR_ERR(rgb->pll_d_out0); dev_err(dc->dev, "failed to get pll_d_out0: %d\n", err); - return err; + goto remove; } =20 if (dc->soc->has_pll_d2_out0) { @@ -252,13 +254,17 @@ int tegra_dc_rgb_probe(struct tegra_dc *dc) if (IS_ERR(rgb->pll_d2_out0)) { err =3D PTR_ERR(rgb->pll_d2_out0); dev_err(dc->dev, "failed to get pll_d2_out0: %d\n", err); - return err; + goto remove; } } =20 dc->rgb =3D &rgb->output; =20 return 0; + +remove: + tegra_output_remove(&rgb->output); + return err; } =20 void tegra_dc_rgb_remove(struct tegra_dc *dc) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 53C50186369; Sun, 24 Mar 2024 22:40:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320047; cv=none; b=l9FWXMq1WxodpiH7QNnsfAPk6gY6heTrWsqcIo4NcNEwuTcYgtYvTKkUJIsKMY20WEZsa63VfDKmmcXRtOI80vYj017W2dp7VaiW7/IzPP3Bxsz3TKfy1GDO4U30J7NlNndT1/ymUZuUdt3EXCvocdW7KieGJ8YsHldq64DtHro= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320047; c=relaxed/simple; bh=xx4kwvzAxT8EfZAIHWdVzcLqTUvuj8Q6VMgCYvPhFCo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=q9TXAYAWdzaDo1HRJKgCDd8Y5oK/AA7PK7wvJtmNSHnvqFNBZctXOCZw/pvXdAF66suU3ZknHd+t9U/KiPwmSECJxCOPTX9LixIw+XavsWxsKlbSEfYha8k6eMvfrSk11ZLmDo4eiUuLF/QwP+GmBFsuogJzRZh83UBOTyu3L1A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=daOJDXd1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="daOJDXd1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 92386C43399; Sun, 24 Mar 2024 22:40:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320047; bh=xx4kwvzAxT8EfZAIHWdVzcLqTUvuj8Q6VMgCYvPhFCo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=daOJDXd1iuIFaWsMejSfVa/IHTgpxF/5N+zjT6E20WQ2uWh2SCDQmRisy9n6FL+ae MSYoyXiJsS0NNOlETu3aZpV+tiOOi7AaQvMAvY+3ggMau8xgNqWBND4BjkjGxnsHej 3AMC2GcW972quryjLnUpzAG3s9VsdfnZtgsTflRNuIRnEqHUEo8F/fXnIcpgHyqEvW fbjxzl4crwdESLms9zqHi9K0fvqjcU5bj07gb/mtDWxQowrl7jP/OvYzad3dk4DgkV 3UwW1PfyHI2VE9OyxtxpKCSwBANA+lk1HOeadydH6O6XKYdxkRN2gYs6cG/aLej9Kv YGwKWHFBkUrwQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christophe JAILLET , Thierry Reding , Sasha Levin Subject: [PATCH 6.8 356/715] drm/tegra: rgb: Fix missing clk_put() in the error handling paths of tegra_dc_rgb_probe() Date: Sun, 24 Mar 2024 18:28:55 -0400 Message-ID: <20240324223455.1342824-357-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Christophe JAILLET [ Upstream commit 45c8034db47842b25a3ab6139d71e13b4e67b9b3 ] If clk_get_sys(..., "pll_d2_out0") fails, the clk_get_sys() call must be undone. Add the missing clk_put and a new 'put_pll_d_out0' label in the error handling path, and use it. Fixes: 0c921b6d4ba0 ("drm/tegra: dc: rgb: Allow changing PLLD rate on Tegra= 30+") Signed-off-by: Christophe JAILLET Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/0182895ead4e4730426616b= 0d9995954c960b634.1693667005.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/tegra/rgb.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/rgb.c b/drivers/gpu/drm/tegra/rgb.c index 53c492b13d129..1e8ec50b759e4 100644 --- a/drivers/gpu/drm/tegra/rgb.c +++ b/drivers/gpu/drm/tegra/rgb.c @@ -254,7 +254,7 @@ int tegra_dc_rgb_probe(struct tegra_dc *dc) if (IS_ERR(rgb->pll_d2_out0)) { err =3D PTR_ERR(rgb->pll_d2_out0); dev_err(dc->dev, "failed to get pll_d2_out0: %d\n", err); - goto remove; + goto put_pll; } } =20 @@ -262,6 +262,8 @@ int tegra_dc_rgb_probe(struct tegra_dc *dc) =20 return 0; =20 +put_pll: + clk_put(rgb->pll_d_out0); remove: tegra_output_remove(&rgb->output); return err; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3617518638C; Sun, 24 Mar 2024 22:40:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320048; cv=none; b=qw31kFzBM+m7le0AjqXYoMJGJ3uh/q79zhp6IXgXK2WTRZQYnWcTXieFWDKhx8PRCUR4WyaN4dba6QR5vDzFkGpoOYCQnfr1hl6Ad8zedMUahN0coZprWbn9PfZiMgxf9lZ41jlAVtn7HtqWDx+QiIOb/N1vESDW/L8AqBn83cU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320048; c=relaxed/simple; bh=HiFTlZ3SKcc4YSHufcREYcJE8gSsUS12Vn56iUfMUs4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K3yoHyvnDwRIwJcEnCNDxgK7NcjrGwFLT6ZkZfFSdEQ6SkKgX9y4f37YFIXLQ8DwlqlRqDYYDRNqN2YW2eB5pdMoswqBWSj++uu8Brt6w8ou3wcZlUMugeYmPgAJG1LG43qwc5NJYynFHVUE252Sor75BuqegP7DnidWKlzADPc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SUCzykO8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SUCzykO8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75E2FC433C7; Sun, 24 Mar 2024 22:40:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320048; bh=HiFTlZ3SKcc4YSHufcREYcJE8gSsUS12Vn56iUfMUs4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SUCzykO8QO3y3Vd3LKq2FkZ8xRb3zNvwa+LlIT5kHISwA0xmnmbdlMhiqNAT0ZANX 3mRmWF9DSU8KAQVlDUkS6KIuggmc49P2KgObzkFzEFOF1RouxIY3NozRBuMBt2ZYRM LabISNei/YEtNlQ4TZ6/PlCQHU3Irs+jJImsTjxWsyr9qRcWoXUD/YmTU7XGw+vtYp +qjf8/wfeQ0siKUMa6hKazRYxIE0vZDP59pH2ASB1EraGa8knRybhrL/68A907G85Q s/wIT/DR2+emFP8HZCi5hmzCWG6mgQsbvwJaePeICgsdpiQeQksWCaHsF2qi6YkJUd 7a5PIQzg8u5vQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christophe JAILLET , Thierry Reding , Sasha Levin Subject: [PATCH 6.8 357/715] drm/tegra: output: Fix missing i2c_put_adapter() in the error handling paths of tegra_output_probe() Date: Sun, 24 Mar 2024 18:28:56 -0400 Message-ID: <20240324223455.1342824-358-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Christophe JAILLET [ Upstream commit 2db4578ef6ffb2b52115ca0ebf897b60ec559556 ] If an error occurs after a successful of_get_i2c_adapter_by_node() call, it should be undone by a corresponding i2c_put_adapter(). Add the missing i2c_put_adapter() call. Fixes: 9be7d864cf07 ("drm/tegra: Implement panel support") Signed-off-by: Christophe JAILLET Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/b38604178991e1f08b2cda2= 19103be266be2d680.1693667005.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/tegra/output.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c index dc2dcb5ca1c89..d7d2389ac2f5a 100644 --- a/drivers/gpu/drm/tegra/output.c +++ b/drivers/gpu/drm/tegra/output.c @@ -142,8 +142,10 @@ int tegra_output_probe(struct tegra_output *output) GPIOD_IN, "HDMI hotplug detect"); if (IS_ERR(output->hpd_gpio)) { - if (PTR_ERR(output->hpd_gpio) !=3D -ENOENT) - return PTR_ERR(output->hpd_gpio); + if (PTR_ERR(output->hpd_gpio) !=3D -ENOENT) { + err =3D PTR_ERR(output->hpd_gpio); + goto put_i2c; + } =20 output->hpd_gpio =3D NULL; } @@ -152,7 +154,7 @@ int tegra_output_probe(struct tegra_output *output) err =3D gpiod_to_irq(output->hpd_gpio); if (err < 0) { dev_err(output->dev, "gpiod_to_irq(): %d\n", err); - return err; + goto put_i2c; } =20 output->hpd_irq =3D err; @@ -165,7 +167,7 @@ int tegra_output_probe(struct tegra_output *output) if (err < 0) { dev_err(output->dev, "failed to request IRQ#%u: %d\n", output->hpd_irq, err); - return err; + goto put_i2c; } =20 output->connector.polled =3D DRM_CONNECTOR_POLL_HPD; @@ -179,6 +181,12 @@ int tegra_output_probe(struct tegra_output *output) } =20 return 0; + +put_i2c: + if (output->ddc) + i2c_put_adapter(output->ddc); + + return err; } =20 void tegra_output_remove(struct tegra_output *output) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 95D5F1869CF; Sun, 24 Mar 2024 22:40:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320049; cv=none; b=QV0YdkN1taYHoejtmu1igbA0sFaqRM0pQf9UVL1+zbwFoorYFyUn1ufzVSfcNhZjDMUcXDXnrITfXNvTVg0n2Skwo0fLJxYkyp/ZTYavQyYyF3ZKgtrzK3TVptyRWW8Ap7iaop/gP6iJ2gDiofnkkU9yIW1f4iUYFwba4smHNY8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320049; c=relaxed/simple; bh=0I0EZZIC+HExk9WKNgMsmSGsSAveJIuCqA6OB74RttA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=VLpygPyiH/6uICgAlXp19InHIQrVMSuJReLkYP3psYVjpp/pvajkZUMH4P2DX7zIQVWNb7WFjHTeBif1rBRehV7zQk8AZwQDtAIge9SND17bfOkTZUm+icYPnyb+FPzHPC6w/E8cGYMXFzEzgrtTiX4qL+BpLSh/8wjQXWvjqAI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=V083HxHh; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="V083HxHh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5BE9CC43390; Sun, 24 Mar 2024 22:40:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320049; bh=0I0EZZIC+HExk9WKNgMsmSGsSAveJIuCqA6OB74RttA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=V083HxHhiO6gRi+WdRi8vv1UNTm9dU+GHOpVcxELOv5hFIlYEI2Z7fDxqpl546NYv v52jCSh+bGkmBpPXNr1BRG9wJnZ/MNqHDl28gFpJEwiM3FP3S37YO1ZqJx0otO/4Dq 4OLCXJayhJ9xsafLhqbrDfrGcm+foDRbpwmSgGWXZ+OB2QKmr5+O3HCFXWpQCFMfT2 8wK3SMUl8y+AwJs3yWx70TPntSVXzxBlfOvK6cwA/tClipMqy0WYMsV916pO3PxnR9 YGAWtpTfE7+2oFPN2Ylx3qCP4GMaUMVgvbcujIzjjts10qlfgkwyZ7lQfn/AXu8yiE VlCXUlRxWkiUw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alex Bee , Zheng Yang , Heiko Stuebner , Sasha Levin Subject: [PATCH 6.8 358/715] drm/rockchip: inno_hdmi: Fix video timing Date: Sun, 24 Mar 2024 18:28:57 -0400 Message-ID: <20240324223455.1342824-359-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alex Bee [ Upstream commit 47a145c03484d33e65d773169d5ca1b9fe2a492e ] The controller wants the difference between *total and *sync_start in the HDMI_VIDEO_EXT_*DELAY registers. Otherwise the signal is very unstable for certain non-VIC modes. See downstream commit [0]. [0] https://github.com/rockchip-linux/kernel/commit/8eb559f2502c Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support") Co-developed-by: Zheng Yang Signed-off-by: Zheng Yang Signed-off-by: Alex Bee Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20231222174220.55249-4-= knaerzche@gmail.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/rockchip/inno_hdmi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/rockchip/inno_hdmi.c b/drivers/gpu/drm/rockchi= p/inno_hdmi.c index e6fbe040ccf6a..b66c1ef5838fd 100644 --- a/drivers/gpu/drm/rockchip/inno_hdmi.c +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c @@ -411,7 +411,7 @@ static int inno_hdmi_config_video_timing(struct inno_hd= mi *hdmi, hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_L, value & 0xFF); hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HBLANK_H, (value >> 8) & 0xFF); =20 - value =3D mode->hsync_start - mode->hdisplay; + value =3D mode->htotal - mode->hsync_start; hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_L, value & 0xFF); hdmi_writeb(hdmi, HDMI_VIDEO_EXT_HDELAY_H, (value >> 8) & 0xFF); =20 @@ -426,7 +426,7 @@ static int inno_hdmi_config_video_timing(struct inno_hd= mi *hdmi, value =3D mode->vtotal - mode->vdisplay; hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VBLANK, value & 0xFF); =20 - value =3D mode->vsync_start - mode->vdisplay; + value =3D mode->vtotal - mode->vsync_start; hdmi_writeb(hdmi, HDMI_VIDEO_EXT_VDELAY, value & 0xFF); =20 value =3D mode->vsync_end - mode->vsync_start; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 412A31869EA; Sun, 24 Mar 2024 22:40:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320050; cv=none; b=U9hy9hl4e13IQB3gxG4c7OE8OmnrXK+Civ76Ovq1Zp6V6lCZfrLe5/P7MjI85MyFVE1m8wBWwqRsaw2h5aysfTfz6lZYMUrrP6phWreVHFhuwfqDzzcB8iU67p4iZoLL1/iDxoyoKXsWc5GF4GK9yCr+IULAwtf0eIMYowz6Wds= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320050; c=relaxed/simple; bh=qgWoNH854Qu3UszLlD0IS5mUljLWw9/aZEUoPzuQfUA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lIFxVyx3xL1nTvYeBlQaCQSqO3c7NxGlNtVJNyzYYQPBegj43AHKSI+k6zh934dokfSI5GUtY0x/Ul+L3wiQOy4Ujz8fjvfg89gJxEIA6elnvcS2DMobdO+XzE72ThguRvnFRqaEZsmR3OQUau/ptiiDyN7uKo7uuirId/Kaiys= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iZQUWZLl; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iZQUWZLl" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56518C43394; Sun, 24 Mar 2024 22:40:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320050; bh=qgWoNH854Qu3UszLlD0IS5mUljLWw9/aZEUoPzuQfUA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iZQUWZLl+MCtemuDY6dpidcM1VV4YWKWqLMDYDdck2/36OGY+Y2ZgZHP35PaMc8Wn AheqCxGyDS0mLV/hys35fDSZGfcTRVRIyj/czzw+dy/Hqh3LlCU5MaWOQwr1gETqa9 3GjlQTFhSUCKxjftCiduIAF1wedsp8R2Yz3k9AGnY6xgZQnQ2BFk9NmdlyYvLbWH7K U1pSvzKm3+1BP7HEaAmjO/KVCNkku8BJlWbYA0L8BMH1U+MgYUzFkBWlm2fSlkocZm GSRGGSlAqGXXFyaesXyRoCU8e/H0idkQpBzjviTa6gkui6fNkh3B4d/KWQ10iN5g9I kC3jwuqNhq/dQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Harry Wentland , Simon Ser , Melissa Wen , Melissa Wen , Sasha Levin Subject: [PATCH 6.8 359/715] drm: Don't treat 0 as -1 in drm_fixp2int_ceil Date: Sun, 24 Mar 2024 18:28:58 -0400 Message-ID: <20240324223455.1342824-360-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Harry Wentland [ Upstream commit cf8837d7204481026335461629b84ac7f4538fa5 ] Unit testing this in VKMS shows that passing 0 into this function returns -1, which is highly counter- intuitive. Fix it by checking whether the input is >=3D 0 instead of > 0. Fixes: 64566b5e767f ("drm: Add drm_fixp_from_fraction and drm_fixp2int_ceil= ") Signed-off-by: Harry Wentland Reviewed-by: Simon Ser Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20231108163647.106853-2= -harry.wentland@amd.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- include/drm/drm_fixed.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/drm_fixed.h b/include/drm/drm_fixed.h index 6ea339d5de088..0c9f917a4d4be 100644 --- a/include/drm/drm_fixed.h +++ b/include/drm/drm_fixed.h @@ -95,7 +95,7 @@ static inline int drm_fixp2int_round(s64 a) =20 static inline int drm_fixp2int_ceil(s64 a) { - if (a > 0) + if (a >=3D 0) return drm_fixp2int(a + DRM_FIXED_ALMOST_ONE); else return drm_fixp2int(a - DRM_FIXED_ALMOST_ONE); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5094B1870A8; Sun, 24 Mar 2024 22:40:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320051; cv=none; b=IpGe1RLGHtaodEa3oI1YZKNpqu94Ryq4TuaKxpTRkWmHkSpcwA5dMXxXh29LWR6yNwzjjE2AyVoVMAKdHGXB04OkuYCiyT/1zMzT4YCq18mY6qfG7b485UAMPzd1w5hF6boapec7nT+7DOK7PqSD3a2uVtQHNgtWylpM/IpspQQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320051; c=relaxed/simple; bh=r94iDyI3IDylZBFHddqhoES6VAbPF+0tOiw1jowT+zQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Cohg0yCbvHgjEtAL2zDPzyUNhFWV+9bbGZ9hp0pwRMVw2M1h+1czH7EKNTVBrh/uoK9H4tXI6LSuaBbiMne8gNZSneMrmMBJiDqqrd3U7gkA49qIkR+MTyR0/1lAgoGDW4Z0hzJpqJtwrcpjyZTfwNtCfRjBThXnkGJ02qsBcVc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N49H5tpA; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N49H5tpA" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64CD8C43390; Sun, 24 Mar 2024 22:40:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320051; bh=r94iDyI3IDylZBFHddqhoES6VAbPF+0tOiw1jowT+zQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=N49H5tpAhuxXiOKPkfrSAZ+WZtEXTA64tDCH0gHjTYCaKjLDTDhoBMPvRIh2HpVLh VJkG+f5WgvZ3+Tj0qC7pG/8r9nyOLav5XI8lT24+t491IK2IVCqJMK8HSnatFC005W Fvw0i4F9WT7bOcFfdzz8SbTB6XcgVKX8b6nwmvdSflJVHJiOWIGolEQ0scJwy5s+hV b4byKr117l3mqcuKKwJdxl1Ctkv1Dk+oZPJYUFdL0lrKfA66dgfS9VTSPlDI4C9860 YX8+BqBSyw9uvtvaAIB1Wo0owAxkFmVwjGAcGpjfz5Ox1zx8YsNqTFFTR1jHDTD8QD 7e454nM2YRieQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Harry Wentland , Arthur Grillo , Melissa Wen , Melissa Wen , Sasha Levin Subject: [PATCH 6.8 360/715] drm/vkms: Avoid reading beyond LUT array Date: Sun, 24 Mar 2024 18:28:59 -0400 Message-ID: <20240324223455.1342824-361-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Harry Wentland [ Upstream commit 2fee84030d12d9fddfa874e4562d71761a129277 ] When the floor LUT index (drm_fixp2int(lut_index) is the last index of the array the ceil LUT index will point to an entry beyond the array. Make sure we guard against it and use the value of the floor LUT index. v3: - Drop bits from commit description that didn't contribute anything of value Fixes: db1f254f2cfa ("drm/vkms: Add support to 1D gamma LUT") Signed-off-by: Harry Wentland Cc: Arthur Grillo Reviewed-by: Arthur Grillo Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20231108163647.106853-6= -harry.wentland@amd.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/vkms/vkms_composer.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vk= ms_composer.c index 3c99fb8b54e2d..e7441b227b3ce 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c @@ -123,6 +123,8 @@ static u16 apply_lut_to_channel_value(const struct vkms= _color_lut *lut, u16 chan enum lut_channel channel) { s64 lut_index =3D get_lut_index(lut, channel_value); + u16 *floor_lut_value, *ceil_lut_value; + u16 floor_channel_value, ceil_channel_value; =20 /* * This checks if `struct drm_color_lut` has any gap added by the compiler @@ -130,11 +132,15 @@ static u16 apply_lut_to_channel_value(const struct vk= ms_color_lut *lut, u16 chan */ static_assert(sizeof(struct drm_color_lut) =3D=3D sizeof(__u16) * 4); =20 - u16 *floor_lut_value =3D (__u16 *)&lut->base[drm_fixp2int(lut_index)]; - u16 *ceil_lut_value =3D (__u16 *)&lut->base[drm_fixp2int_ceil(lut_index)]; + floor_lut_value =3D (__u16 *)&lut->base[drm_fixp2int(lut_index)]; + if (drm_fixp2int(lut_index) =3D=3D (lut->lut_length - 1)) + /* We're at the end of the LUT array, use same value for ceil and floor = */ + ceil_lut_value =3D floor_lut_value; + else + ceil_lut_value =3D (__u16 *)&lut->base[drm_fixp2int_ceil(lut_index)]; =20 - u16 floor_channel_value =3D floor_lut_value[channel]; - u16 ceil_channel_value =3D ceil_lut_value[channel]; + floor_channel_value =3D floor_lut_value[channel]; + ceil_channel_value =3D ceil_lut_value[channel]; =20 return lerp_u16(floor_channel_value, ceil_channel_value, lut_index & DRM_FIXED_DECIMAL_MASK); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3082A1870C6; Sun, 24 Mar 2024 22:40:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320052; cv=none; b=OMbVDha95SNI1OSxicQ/MgVFMjuJGF/BpipvaHkLjATXRVZDKZHmpD6FhusPE2XA1d0oWc96VkTGyORpYEkVPtGto7oPxVrQsVPiWkA2Oz/AHkzZbixJU97Ik6b1UkfQD3c/VqZ1tIzGukPiAxsol1K5s98W3oieGuqlimF2Ass= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320052; c=relaxed/simple; bh=Ke97hrXldFBxj8KzdI5VmMC+f8kuAT2CHHarl1iwKgY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sBmpthEIbh/NLSqZO8cNlE5YnUA97q1fn3kwrddFLeyWaam8UKssHjTl+a28bQX1/d7s3CbdkcgFCtLJ+wntLqOP1HRGUzaJJJuYQ25oudbhveYnKcNTV5/FgmkSQoeY0m4Cm+e5Ep1n8uHvHJGkAQ5HtLTG9GHkBCwR8TyTAFA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FIY3k9U+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FIY3k9U+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 75033C433F1; Sun, 24 Mar 2024 22:40:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320052; bh=Ke97hrXldFBxj8KzdI5VmMC+f8kuAT2CHHarl1iwKgY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FIY3k9U+IcObwFrWPQXzhuPdwPXFruDCLUZ3fej3FXrEBkt1l8qPrqefxi8EigT5Z 33qjBfkVxDjSxpj8H1f2jBilZT5nUtVNuauQr/K2C2ZtKkaIVbsG8BrpFtFQNYfnZw mp9HjSoup2l/SKuT40ws/wwZmDWdYkd7NG0MGe1YMSxx41tlwkjeMj1/JIeYOuZpRw lHTEsHEYBdaHB2flai7DibouhVRv38WsEffiVYWoFsSB53qzkg6J61kRGzIsSxoK7c ayPX2lrqBhnomDqniyYafmw0OVxett6eRbuDBf52xmILg3LMB9D6fhc+Vkz8qh08PO PKzJxV49tt3qg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zhipeng Lu , Zack Rusin , Sasha Levin Subject: [PATCH 6.8 361/715] drm/vmwgfx: fix a memleak in vmw_gmrid_man_get_node Date: Sun, 24 Mar 2024 18:29:00 -0400 Message-ID: <20240324223455.1342824-362-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zhipeng Lu [ Upstream commit 89709105a6091948ffb6ec2427954cbfe45358ce ] When ida_alloc_max fails, resources allocated before should be freed, including *res allocated by kmalloc and ttm_resource_init. Fixes: d3bcb4b02fe9 ("drm/vmwgfx: switch the TTM backends to self alloc") Signed-off-by: Zhipeng Lu Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20231204091416.3308430-= 1-alexious@zju.edu.cn Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c b/drivers/gpu/dr= m/vmwgfx/vmwgfx_gmrid_manager.c index ceb4d3d3b965a..a0b47c9b33f55 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c @@ -64,8 +64,11 @@ static int vmw_gmrid_man_get_node(struct ttm_resource_ma= nager *man, ttm_resource_init(bo, place, *res); =20 id =3D ida_alloc_max(&gman->gmr_ida, gman->max_gmr_ids - 1, GFP_KERNEL); - if (id < 0) + if (id < 0) { + ttm_resource_fini(man, *res); + kfree(*res); return id; + } =20 spin_lock(&gman->lock); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D029187642; Sun, 24 Mar 2024 22:40:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320053; cv=none; b=nlq+pVVCSQYvhtlA5tU67we14UF0xwUIP7Zb+qohIvsCiVRgoMcLGc2dYQyZNJ0nHeSiKL+8T8frr+5hpKXRA3YuGuxqpzcaZQY1Q+N3mKJkVkVm3XD94dY1bL6L3UAydH2ctaQJohMRHZzQf1AvytaUzsK6OqNleNG+lxNixs8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320053; c=relaxed/simple; bh=2dsSi5JtAsBqm4Skku4k42Ycxqzvl16liEF0hci/lEU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=f32+RSJMWw0tuQhZ6mZJZXl4z2zdEwneceVYJyefk/u8dhGbJ675D9GO8X6WHe1GmkMT0dLVqFX1jtUqYCOuvjgIEfeNGPGGvWwGtzwrjAohj6jCdF5WjaxxPbQUTbjugVPnlKy42j5RHbRrL7tHI1DN2oBUIclTdURhPVjDBt8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TxNEynHH; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TxNEynHH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5649FC43390; Sun, 24 Mar 2024 22:40:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320053; bh=2dsSi5JtAsBqm4Skku4k42Ycxqzvl16liEF0hci/lEU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TxNEynHHhwk9Sw1EPg9IDq4nVLdOoZ7RkfDsntaCBO40Llw1E6blHTvLYhvCsxPJ4 gmz+sW4YfV/0RP8s4cgULilYDMr47myMSZz7oJzb3cHnDBi2m7taEXiK0b6Hf3zZfM JfaTakFKMKJvKaviGMUMKJgFXNbALO/6ubRzah3tN+DPIcqrsnVzV299l79A2cZiMb xbV1z2SPhjemnBVjxG8vd/imdXQXUtMGgDiSERwISefdDH/ulTFzCKEFW16sHvjExD WE+61uGmGKXFyltKRZO3fopOt96ZfHB+R9e6/uIsPLBUsAyqs8jvmOw+7k3d6XVj2l jTJaF29cRQTFA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Quentin Schulz , Quentin Schulz , Heiko Stuebner , Sasha Levin Subject: [PATCH 6.8 362/715] drm/rockchip: lvds: do not overwrite error code Date: Sun, 24 Mar 2024 18:29:01 -0400 Message-ID: <20240324223455.1342824-363-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Quentin Schulz [ Upstream commit 79b09453c4e369ca81cfb670d0136d089e3b92f0 ] ret variable stores the return value of drm_of_find_panel_or_bridge which can return error codes different from EPROBE_DEFER. Therefore, let's just return that error code instead of forcing it to EPROBE_DEFER. Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS") Cc: Quentin Schulz Signed-off-by: Quentin Schulz Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20231120-rk-lvds-defer-= msg-v2-1-9c59a5779cf9@theobroma-systems.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/rockchip/rockchip_lvds.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/roc= kchip/rockchip_lvds.c index 59341654ec32b..6ecb6b8a1dcde 100644 --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c @@ -577,7 +577,6 @@ static int rockchip_lvds_bind(struct device *dev, struc= t device *master, goto err_put_port; } else if (ret) { DRM_DEV_ERROR(dev, "failed to find panel and bridge node\n"); - ret =3D -EPROBE_DEFER; goto err_put_port; } if (lvds->panel) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7DA0B18766B; Sun, 24 Mar 2024 22:40:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320054; cv=none; b=bPgtK1CROSRsZOqCTLKK847PlXdL7yI+m9GWnqtj+m9Pglv3ABtZ6/35XDDH6dnnTYSHjoBGtrZL7ba3gtxgkhAMo/oJ9Sjqb7EdAeAWD6D23dbdfF4i3vCktioqjg/z0Ne32k0CjBhMhoS3YNskA6Qe5GNZ8nfZUR1NSu6zIXw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320054; c=relaxed/simple; bh=+m8PgEc4m1hDp00DWZW3ySf403TlbRokQ8MybhoqIVQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NUURVzsk9EiOllPkSZqbkoVl47rXAK+Ki37aYVyPaBEDSQkDBeo15h6q9Z3KGp7vce9nmG8tBP7PXogyxsJe7Jn2nF2NN9NH3ZkM5QOncWjCviWloAh4Un2PMS1ntfX7SFPnzkSEODpb2TAI4Sp10ILuxYbZ57kIREBYU28xouc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S9iyN3o5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S9iyN3o5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 52575C433F1; Sun, 24 Mar 2024 22:40:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320054; bh=+m8PgEc4m1hDp00DWZW3ySf403TlbRokQ8MybhoqIVQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=S9iyN3o5UAqlA6DrqKX4Kmc7ZMx+2lSn64BU6ne2ReV/Pda4BCg0jsNKtY0fQLJdQ 718/bDtNreH1h/ZXhzltSklmWDjN0wvixgL3I16uZWPHrAj3JoGNp1e+gDWsFdJIIu lmksAFMYSecOwEFoqilHoDB4+ez7GnhQ923a+acvMN8g7Gcb9iRts0eSFgeP7xWhXn OVBKYH1qaNlbbY+kzb+rccjCXJ05P4q1w8XM4lb5WVoq84haPeo9D1IX3eVUUak3Ad LtDSjl8Av8nhhd8VB18c9o3nXtAPctBbm/B94H3Vng7uyvzwdSgcCphFqmuwgzIYi+ qVIzfAXaECDOQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Quentin Schulz , Quentin Schulz , Heiko Stuebner , Sasha Levin Subject: [PATCH 6.8 363/715] drm/rockchip: lvds: do not print scary message when probing defer Date: Sun, 24 Mar 2024 18:29:02 -0400 Message-ID: <20240324223455.1342824-364-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Quentin Schulz [ Upstream commit 52d11c863ac92e36a0365249f7f6d27ac48c78bc ] This scary message can misled the user into thinking something bad has happened and needs to be fixed, however it could simply be part of a normal boot process where EPROBE_DEFER is taken into account. Therefore, let's use dev_err_probe so that this message doesn't get shown (by default) when the return code is EPROBE_DEFER. Fixes: 34cc0aa25456 ("drm/rockchip: Add support for Rockchip Soc LVDS") Cc: Quentin Schulz Signed-off-by: Quentin Schulz Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20231120-rk-lvds-defer-= msg-v2-2-9c59a5779cf9@theobroma-systems.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/rockchip/rockchip_lvds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/roc= kchip/rockchip_lvds.c index 6ecb6b8a1dcde..77b76cff1adb9 100644 --- a/drivers/gpu/drm/rockchip/rockchip_lvds.c +++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c @@ -576,7 +576,7 @@ static int rockchip_lvds_bind(struct device *dev, struc= t device *master, ret =3D -EINVAL; goto err_put_port; } else if (ret) { - DRM_DEV_ERROR(dev, "failed to find panel and bridge node\n"); + dev_err_probe(dev, ret, "failed to find panel and bridge node\n"); goto err_put_port; } if (lvds->panel) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 555791869EA; Sun, 24 Mar 2024 22:40:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320055; cv=none; b=CvJjZbZu19BcZRONtDiVeep0tjlbM7vUeXPPMmI1e9PkmP+NH5uCXkHRS+Y4bePh8S3xHeCvzNy8J2Km5oLgmWCiRDPmz55QiuPqZcGnyDyhnK8ryAzjCAhUvyZ2Ng50hFln3QnFKKIe7Uv0J5XsEUu8ybF7+0rjy7OHWnOk0ps= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320055; c=relaxed/simple; bh=XU6/lcTte6ODVuLBpwKzor3DKbsMmnjicRqB6FkGGXY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ZWUTCyJKnH5dp+S4kGK59adUqNY+0JoPnfG8yL5JoDBM8c+wvjc+Gn5Bsg2psiYAZW3df3DYLD9uKiklaEEvwcBw7OhvwMDyihfXnetXcf4Uy2Kb+X2lOiCgahns958gRPzQk+BUl6sr/W3q04lcQIjGDcuGkOA3P2AbKaZbk4I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=B6r9Cwkx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="B6r9Cwkx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49854C43394; Sun, 24 Mar 2024 22:40:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320054; bh=XU6/lcTte6ODVuLBpwKzor3DKbsMmnjicRqB6FkGGXY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=B6r9CwkxvmnjqNMK2IKdoAF0itjo8EfOMEDKHJHqgeAQKSfHTLzaj25pTYXJlF1II sN00Gy/dTNJyCs0UkXe7xHYPtfkWwwxAZ6znwfPC6pPPWBeeXbmSzBS2IriDeRXcY0 wxNtiQ/eCXTx6y4NEy+bmLQvWbp72Vvtwa7VNZjWfIYCfZ9+YUOcwjXBYaEynccznb 30G1NsOwbvFJL1NTVeoHBqtIbMbC6p7/ErAVKdHh6mijj49vhHLoXkeJdr63c7rx94 lykm3HHjdItQov5SQE57p/RJ+Ofyk5UhC9AJo4GSbHIQgywolnkexNXhs6stt2oMrr idTKElqlVyUiQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Hsin-Yi Wang , Douglas Anderson , Sasha Levin Subject: [PATCH 6.8 364/715] drm/panel-edp: use put_sync in unprepare Date: Sun, 24 Mar 2024 18:29:03 -0400 Message-ID: <20240324223455.1342824-365-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Hsin-Yi Wang [ Upstream commit 49ddab089611ae5ddd0201ddbbf633da75bfcc25 ] Some edp panel requires T10 (Delay from end of valid video data transmitted by the Source device to power-off) less than 500ms. Using autosuspend with delay set as 1000 violates this requirement. Use put_sync_suspend in unprepare to meet the spec. For other cases (such as getting EDID), it still uses autosuspend. Suggested-by: Douglas Anderson Fixes: 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid exce= ssive unprepare / prepare") Signed-off-by: Hsin-Yi Wang Reviewed-by: Douglas Anderson Signed-off-by: Douglas Anderson Link: https://patchwork.freedesktop.org/patch/msgid/20231220221418.2610185-= 1-hsinyi@chromium.org Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/panel/panel-edp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-edp.c b/drivers/gpu/drm/panel/pane= l-edp.c index a0b6f69b916f9..e5e3f0b9ca61d 100644 --- a/drivers/gpu/drm/panel/panel-edp.c +++ b/drivers/gpu/drm/panel/panel-edp.c @@ -413,8 +413,7 @@ static int panel_edp_unprepare(struct drm_panel *panel) if (!p->prepared) return 0; =20 - pm_runtime_mark_last_busy(panel->dev); - ret =3D pm_runtime_put_autosuspend(panel->dev); + ret =3D pm_runtime_put_sync_suspend(panel->dev); if (ret < 0) return ret; p->prepared =3D false; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DED5E187E6D; Sun, 24 Mar 2024 22:40:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320056; cv=none; b=cs7NK6rbOEJ8RBq6hQjGIQMIMWd3jfl1HTZH0bdt2BRido9PZCiuyHdkEjyYuigLwurmE7cAqcMW/THZcObFJN8dyAYuUp0CI5Rjb5GnmalrM/6QKw7X/mUIzxXn/iC9gn72RalsN5gnc/dtfk1LYDo5JFx23tEoPAMRpW12ZDg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320056; c=relaxed/simple; bh=0nT6+dnLat5eW46YYuat1egqogoXhgAReEx7/an+0Fs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GsELGmXW5My+29kC0igKiG4LoieDZfb5AmeE1+rT6KVJ4ZFo/35ze5gtT0ykydZO8imcR6C8ELuXp1cOSqegbgusl7Zq5fzaNjUe5VScRc/FZhcPY+O3BhnbXiBSgQaHonHLfH0Aoc34pP1/3vVsIp2CpNVOFmW2iTA92Lc4S/s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=I37O5HjN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="I37O5HjN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2C437C433F1; Sun, 24 Mar 2024 22:40:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320055; bh=0nT6+dnLat5eW46YYuat1egqogoXhgAReEx7/an+0Fs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=I37O5HjNSeBQCM6xRflx/AMKd3ey5UzG5frdF1nhAVmOqzl6BxyrKMTEMnuJ4dfPG fSk2C6su7Z5FLEwIN/g/vbB6cPLTi97EAqb2JbvaVHX2H90fK3caqxGFXTqoImJ/+U iNieJKMCiGUql7TXxAOL15lNoVyWsKVT4cXQKilL9pdI4DOexqVwEam9w8+Vp88X+l I7WGR+8lVnSH25/r4r10ZZPYY6+psuJb5s+b7ZGYYqTHDd9iNKrhTX49m5IH7x8dV+ nH4YdhrpGlxhrdH+TJiTB92EFeKDvYt9rUbM1rE6viDlonhzEeVwr0vEwR3tGRzkEO YJ5G0ZFmYsCLQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zhipeng Lu , Qiang Yu , Sasha Levin Subject: [PATCH 6.8 365/715] drm/lima: fix a memleak in lima_heap_alloc Date: Sun, 24 Mar 2024 18:29:04 -0400 Message-ID: <20240324223455.1342824-366-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zhipeng Lu [ Upstream commit 04ae3eb470e52a3c41babe85ff8cee195e4dcbea ] When lima_vm_map_bo fails, the resources need to be deallocated, or there will be memleaks. Fixes: 6aebc51d7aef ("drm/lima: support heap buffer creation") Signed-off-by: Zhipeng Lu Signed-off-by: Qiang Yu Link: https://patchwork.freedesktop.org/patch/msgid/20240117071328.3811480-= 1-alexious@zju.edu.cn Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/lima/lima_gem.c | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_ge= m.c index 4f9736e5f929b..7ea244d876ca6 100644 --- a/drivers/gpu/drm/lima/lima_gem.c +++ b/drivers/gpu/drm/lima/lima_gem.c @@ -75,29 +75,34 @@ int lima_heap_alloc(struct lima_bo *bo, struct lima_vm = *vm) } else { bo->base.sgt =3D kmalloc(sizeof(*bo->base.sgt), GFP_KERNEL); if (!bo->base.sgt) { - sg_free_table(&sgt); - return -ENOMEM; + ret =3D -ENOMEM; + goto err_out0; } } =20 ret =3D dma_map_sgtable(dev, &sgt, DMA_BIDIRECTIONAL, 0); - if (ret) { - sg_free_table(&sgt); - kfree(bo->base.sgt); - bo->base.sgt =3D NULL; - return ret; - } + if (ret) + goto err_out1; =20 *bo->base.sgt =3D sgt; =20 if (vm) { ret =3D lima_vm_map_bo(vm, bo, old_size >> PAGE_SHIFT); if (ret) - return ret; + goto err_out2; } =20 bo->heap_size =3D new_size; return 0; + +err_out2: + dma_unmap_sgtable(dev, &sgt, DMA_BIDIRECTIONAL, 0); +err_out1: + kfree(bo->base.sgt); + bo->base.sgt =3D NULL; +err_out0: + sg_free_table(&sgt); + return ret; } =20 int lima_gem_create_handle(struct drm_device *dev, struct drm_file *file, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D72F3187E90; Sun, 24 Mar 2024 22:40:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320056; cv=none; b=jnu2luSg0Bn8UhdrbhWAJBDQBUJnEnVMCZHeQJH07i3SbOLKKB7IeYRGAHr0iPjpHnXiV7vCe9fE0Gx40JjZiB91hxUAqDYniuhK54NdTYlL4ShqDWs3P7wO2+IiVfisVNvhRnLqT/HPfLn00oXCKfTFIct80qkOdDhE2MrYXW0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320056; c=relaxed/simple; bh=+rMlh2QubRCArm0kM1Dj0Fl4nnNuuvzgyDokws4LcJY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=I2KOScESkXiz0kEDWRFdvZxsxzoMgBZ6EXClZmnaqjD+3CF4HoHF7yePENKKdkK05CHt6+ycTCXIPn6TFF+56MGjV69C6eMpMTmGe2OG/9lXpms5MY3rbRNO7ugRvjukFDXwfVBjlq94c4/aoSjxLgmTIR23ip8eLIgPpLGoPcE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WTb8QbJ3; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WTb8QbJ3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EF4BC433A6; Sun, 24 Mar 2024 22:40:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320056; bh=+rMlh2QubRCArm0kM1Dj0Fl4nnNuuvzgyDokws4LcJY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WTb8QbJ3PCMdPSCOXww8imJ4NoYlbD7md0hQMdq3jcWUgarwIMGjDYO7twkl9b7/Q yskPhXKQ1SgU04JiL/FV3fOuf0Q4x2Gq6q/+o0mKOEAHgOZnlUhmqX7FLSSgrN3c9e xmy8mSNFZT9NV6GauZkQlk3zWj2hnpaJ7K7BRe5kJVWu18MV1qy0MT8DiN7a//nz9t eCn5yjkAW6EP1tWFLdGSmZLcT/fu59wHIFXJecwSiuJD74x7X3MdnN6Zpx81/qfnXS P+QxnHXomMhUfvFEkYNb8yJJFOQyzpV86K8bpyZ+wV8WUr4PQRjPJ8SoPb0ZAkE5eL sAwFlCIzhKv1g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Cristian Ciocaltea , Emil Velikov , Mark Brown , Sasha Levin Subject: [PATCH 6.8 366/715] ASoC: amd: acp: Add missing error handling in sof-mach Date: Sun, 24 Mar 2024 18:29:05 -0400 Message-ID: <20240324223455.1342824-367-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Cristian Ciocaltea [ Upstream commit d0ada20279db2649a7549a2b8a4a3379c59f238d ] Handle potential acp_sofdsp_dai_links_create() errors in ACP SOF machine driver's probe function. Note there is no need for an undo. While at it, switch to dev_err_probe(). Fixes: 9f84940f5004 ("ASoC: amd: acp: Add SOF audio support on Chrome board= ") Signed-off-by: Cristian Ciocaltea Reviewed-by: Emil Velikov Link: https://msgid.link/r/20231219030728.2431640-4-cristian.ciocaltea@coll= abora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- sound/soc/amd/acp/acp-sof-mach.c | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/sound/soc/amd/acp/acp-sof-mach.c b/sound/soc/amd/acp/acp-sof-m= ach.c index 20b94814a0462..b86f65d420054 100644 --- a/sound/soc/amd/acp/acp-sof-mach.c +++ b/sound/soc/amd/acp/acp-sof-mach.c @@ -126,16 +126,14 @@ static int acp_sof_probe(struct platform_device *pdev) if (dmi_id && dmi_id->driver_data) acp_card_drvdata->tdm_mode =3D dmi_id->driver_data; =20 - acp_sofdsp_dai_links_create(card); + ret =3D acp_sofdsp_dai_links_create(card); + if (ret) + return dev_err_probe(&pdev->dev, ret, "Failed to create DAI links\n"); =20 ret =3D devm_snd_soc_register_card(&pdev->dev, card); - if (ret) { - dev_err(&pdev->dev, - "devm_snd_soc_register_card(%s) failed: %d\n", - card->name, ret); - return ret; - } - + if (ret) + return dev_err_probe(&pdev->dev, ret, + "Failed to register card(%s)\n", card->name); return 0; } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D88613CA95; Sun, 24 Mar 2024 22:40:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320058; cv=none; b=L5d4qDt1y5cD3OxeB+qrrRfHM4EcmoaCrCHPHr6r9TFKQXcFHMapBtaFNfUj4GtuPlmWUT4WHzpzhG9JWSnLcAzNcPsMF0KYk1Xs5dYJ/ugTChtL1GMc4QDRKCjekVsg0Zfgb5jV0V1snh/PcVl0MgMDTLwr9FbTdyDCORjMxAI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320058; c=relaxed/simple; bh=w1lzHvGXBX3ANXxLc/UUheMyGtodUzRmiK0aL41bvzY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=K4VTwAF5TRk6MCNADBk1VTf6vp0LuWFSrAAxHSDypX5kxs/0p3Rimcm25yVb/DxuKsF8W/y+G7U945IhVOOE8DAvPTiDJTYb/UUCHA0tXIZZFMGsDwkd5EzzwhgLz4qqI/88nGDl+UhR+te/QM/5hR/frUMlBmFZckPc/OgJOng= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AND2Jkym; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AND2Jkym" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A38FC433B1; Sun, 24 Mar 2024 22:40:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320057; bh=w1lzHvGXBX3ANXxLc/UUheMyGtodUzRmiK0aL41bvzY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=AND2Jkym4RL0FL5PTFi6rjAGi+ft6Z+mFR/ehD2NM1dh/G1b2B+Kpln9pLAwsw5oF yNFKkvqOTdLffvUxbpzBxt4OU2mgvkY3t0y48EJnEkuyZG/axo8AAsImXIhzy+xoTR 8Lxd+GC9jcJRBB4/8kSAp8vEqPuSZmA3/SmuDtICXWXbjDOelGbMW8EoufRI/HTYvc NUNNUmEnnSN6TiBEtmiZkFy2h0PxlcqI//mfOTtKqN4Mz8JSZT6qevT/WOSOaUmDrJ f75f1Uar19KypU3Ap7C6A9Jcv63PO+53rpxijILgWHzPpA579N1+9sHPS2YH32Zk4U g9NH3cKQUhOpg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Cristian Ciocaltea , Emil Velikov , Mark Brown , Sasha Levin Subject: [PATCH 6.8 367/715] ASoC: SOF: amd: Fix memory leak in amd_sof_acp_probe() Date: Sun, 24 Mar 2024 18:29:06 -0400 Message-ID: <20240324223455.1342824-368-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Cristian Ciocaltea [ Upstream commit 222be59e5eed1554119294edc743ee548c2371d0 ] Driver uses kasprintf() to initialize fw_{code,data}_bin members of struct acp_dev_data, but kfree() is never called to deallocate the memory, which results in a memory leak. Fix the issue by switching to devm_kasprintf(). Additionally, ensure the allocation was successful by checking the pointer validity. Fixes: f7da88003c53 ("ASoC: SOF: amd: Enable signed firmware image loading = for Vangogh platform") Signed-off-by: Cristian Ciocaltea Reviewed-by: Emil Velikov Link: https://msgid.link/r/20231219030728.2431640-6-cristian.ciocaltea@coll= abora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- sound/soc/sof/amd/acp.c | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-) diff --git a/sound/soc/sof/amd/acp.c b/sound/soc/sof/amd/acp.c index 07632ae6ccf5e..9aa9600c05d61 100644 --- a/sound/soc/sof/amd/acp.c +++ b/sound/soc/sof/amd/acp.c @@ -560,17 +560,27 @@ int amd_sof_acp_probe(struct snd_sof_dev *sdev) adata->signed_fw_image =3D false; dmi_id =3D dmi_first_match(acp_sof_quirk_table); if (dmi_id && dmi_id->driver_data) { - adata->fw_code_bin =3D kasprintf(GFP_KERNEL, "%s/sof-%s-code.bin", - plat_data->fw_filename_prefix, - chip->name); - adata->fw_data_bin =3D kasprintf(GFP_KERNEL, "%s/sof-%s-data.bin", - plat_data->fw_filename_prefix, - chip->name); - adata->signed_fw_image =3D dmi_id->driver_data; + adata->fw_code_bin =3D devm_kasprintf(sdev->dev, GFP_KERNEL, + "%s/sof-%s-code.bin", + plat_data->fw_filename_prefix, + chip->name); + if (!adata->fw_code_bin) { + ret =3D -ENOMEM; + goto free_ipc_irq; + } + + adata->fw_data_bin =3D devm_kasprintf(sdev->dev, GFP_KERNEL, + "%s/sof-%s-data.bin", + plat_data->fw_filename_prefix, + chip->name); + if (!adata->fw_data_bin) { + ret =3D -ENOMEM; + goto free_ipc_irq; + } =20 - dev_dbg(sdev->dev, "fw_code_bin:%s, fw_data_bin:%s\n", adata->fw_code_bi= n, - adata->fw_data_bin); + adata->signed_fw_image =3D dmi_id->driver_data; } + adata->enable_fw_debug =3D enable_fw_debug; acp_memory_init(sdev); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D37AD13CAAE; Sun, 24 Mar 2024 22:40:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320058; cv=none; b=KatgnXT3aPUEoYVVeblnvgMH0/ScLMdw3Pdz+TgxL7dEfOjTOQXM31bcOtdBF0im9W9s0aQbXWF9WbP8MZOKhtTeeWs7mxYH/LwKWryXw4whdiLgf/6ntGYH9V0jsyCX/imntROgBax1meQdHK1twIr5AM8RoBS1I8F+lGOX1i4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320058; c=relaxed/simple; bh=jqBEbx6uLVaceB5dNxt0n9v1/Q0sXsq3XUNnRAUTcTk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uLEQxqqKIM+PH+Yd7ubLYP34QWNpm/8sOifh0i62KoZXCp/AQn+D8B0U9bW0wSiesT7gUcV3/v9GBcAyVkVHqO01Wp9edBmvc0dSZo4lcCPLLtDkNuPoj7SsFhjJ2lO9Pyut2N/ljbAoQx41fWG8axGzLtmfVgMv4EjN0N3VsGE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BdT2cT6q; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="BdT2cT6q" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 07C62C433F1; Sun, 24 Mar 2024 22:40:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320058; bh=jqBEbx6uLVaceB5dNxt0n9v1/Q0sXsq3XUNnRAUTcTk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BdT2cT6qrpz4/0tTQwjq7Tl1zirK1h+0vV6608Zfyhuc4dOTfROK3V+GvLyfjpS/5 t2LUslw7+q+Q+gOUvhk/NHbCzsfQqm4hW9M9VcvlLX4HmKuflf/IZOiLZNg20UHT6J J4dGDgQkBzdklvaKrCOtHxU7Aykp5f2/C7Ub3i9Fwz8yGTDbQ6zFDJhcClwL7xabH9 nk9r95BSR4e1ew5ixbhQvBRCipPvtzGBqmjZJBDP4zD9sbxSuTCLELRHqWI9UmB4Jm v2ciPART6V+WsQ90KE+RWqDsuQeAShcV6nlI2lQvgNYNqAVh8NpfH8cCTFgK6V+Ab4 QnE8j9sPJcNBw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Cristian Ciocaltea , =?UTF-8?q?P=C3=A9ter=20Ujfalusi?= , Mark Brown , Sasha Levin Subject: [PATCH 6.8 368/715] ASoC: SOF: core: Skip firmware test for custom loaders Date: Sun, 24 Mar 2024 18:29:07 -0400 Message-ID: <20240324223455.1342824-369-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Cristian Ciocaltea [ Upstream commit 369b997a1371aeecd0a1fb0f9f4ef3747a1d07a4 ] The ACP driver for Vangogh platform uses a quirk for Valve Galileo device to setup a custom firmware loader, which neither requires nor uses the firmware file indicated via the default_fw_filename member of struct sof_dev_desc. Since commit 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if firmware files are missing"), the provided filename gets verified and triggers a fatal error on probe: [ 7.719337] snd_sof_amd_vangogh 0000:04:00.5: enabling device (0000 -> 0002) [ 7.721486] snd_sof_amd_vangogh 0000:04:00.5: SOF firmware and/or topology = file not found. [ 7.721565] snd_sof_amd_vangogh 0000:04:00.5: Supported default profiles [ 7.721569] snd_sof_amd_vangogh 0000:04:00.5: - ipc type 0 (Requested): [ 7.721573] snd_sof_amd_vangogh 0000:04:00.5: Firmware file: amd/sof/sof-v= angogh.ri [ 7.721577] snd_sof_amd_vangogh 0000:04:00.5: Topology file: amd/sof-tplg/= sof-vangogh-nau8821-max.tplg [ 7.721582] snd_sof_amd_vangogh 0000:04:00.5: Check if you have 'sof-firmwa= re' package installed. [ 7.721585] snd_sof_amd_vangogh 0000:04:00.5: Optionally it can be manually= downloaded from: [ 7.721589] snd_sof_amd_vangogh 0000:04:00.5: https://github.com/thesofp= roject/sof-bin/ [ 7.721997] snd_sof_amd_vangogh: probe of 0000:04:00.5 failed with error -2 According to AMD, a combined ".ri" file which includes the code and data segments cannot be used due to a limitation preventing the code image to be signed on build time. Fix the issue by skipping the firmware file test if a custom loader is being used instead of the generic one. Fixes: 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if fi= rmware files are missing") Co-developed-by: P=C3=A9ter Ujfalusi Signed-off-by: P=C3=A9ter Ujfalusi Signed-off-by: Cristian Ciocaltea Link: https://msgid.link/r/20231219030728.2431640-8-cristian.ciocaltea@coll= abora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- sound/soc/sof/fw-file-profile.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/sound/soc/sof/fw-file-profile.c b/sound/soc/sof/fw-file-profil= e.c index 138a1ca2c4a85..b56b14232444c 100644 --- a/sound/soc/sof/fw-file-profile.c +++ b/sound/soc/sof/fw-file-profile.c @@ -89,6 +89,12 @@ static int sof_test_topology_file(struct device *dev, return ret; } =20 +static bool sof_platform_uses_generic_loader(struct snd_sof_dev *sdev) +{ + return (sdev->pdata->desc->ops->load_firmware =3D=3D snd_sof_load_firmwar= e_raw || + sdev->pdata->desc->ops->load_firmware =3D=3D snd_sof_load_firmware_memcp= y); +} + static int sof_file_profile_for_ipc_type(struct snd_sof_dev *sdev, enum sof_ipc_type ipc_type, @@ -130,7 +136,8 @@ sof_file_profile_for_ipc_type(struct snd_sof_dev *sdev, * For default path and firmware name do a verification before * continuing further. */ - if (base_profile->fw_path || base_profile->fw_name) { + if ((base_profile->fw_path || base_profile->fw_name) && + sof_platform_uses_generic_loader(sdev)) { ret =3D sof_test_firmware_file(dev, out_profile, &ipc_type); if (ret) return ret; @@ -181,7 +188,8 @@ sof_file_profile_for_ipc_type(struct snd_sof_dev *sdev, out_profile->ipc_type =3D ipc_type; =20 /* Test only default firmware file */ - if (!base_profile->fw_path && !base_profile->fw_name) + if ((!base_profile->fw_path && !base_profile->fw_name) && + sof_platform_uses_generic_loader(sdev)) ret =3D sof_test_firmware_file(dev, out_profile, NULL); =20 if (!ret) @@ -267,7 +275,11 @@ static void sof_print_profile_info(struct snd_sof_dev = *sdev, =20 dev_info(dev, "Firmware paths/files for ipc type %d:\n", profile->ipc_typ= e); =20 - dev_info(dev, " Firmware file: %s/%s\n", profile->fw_path, profile->f= w_name); + /* The firmware path is only valid when generic loader is used */ + if (sof_platform_uses_generic_loader(sdev)) + dev_info(dev, " Firmware file: %s/%s\n", + profile->fw_path, profile->fw_name); + if (profile->fw_lib_path) dev_info(dev, " Firmware lib path: %s\n", profile->fw_lib_path); dev_info(dev, " Topology file: %s/%s\n", profile->tplg_path, profile-= >tplg_name); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F801188A69; Sun, 24 Mar 2024 22:40:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320060; cv=none; b=jjewyt0pwt2hcNjrSVwv4JARGZ7qalrIttJJnXSUAy7yCrAbFu3mAP/rdxEZc+dGEugbXh9TKkpA1J0+UnGAvhDxUhgg50JFf5RUdOHu1zFfL5SOKjM/2ToNoIYsjs33Z+J9hakD3BRM04LTmkSkq74P94WGlgMTAACRbochAFs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320060; c=relaxed/simple; bh=7Kh9WBTrHZpZpHd+8mqm62KvN/Rtbc1InbRLgxFXGC4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JzIXhLeJrGyCE/ofNHk8hq95kCjYq9G37JWTQMwRhAl7FYmhevY01qDmyLN4WCzfGj2Fk8VHylimrmIq+y0tW9SNPUt4HJhhKd+7tVMV+COIRw6IRdh44/GwAauy+bVfmx1yXjwi0OBiY75rqA8w6mPzUyeyHuQ0hV0oCUZ0O3s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=c5GsmeH6; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="c5GsmeH6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0355BC433C7; Sun, 24 Mar 2024 22:40:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320059; bh=7Kh9WBTrHZpZpHd+8mqm62KvN/Rtbc1InbRLgxFXGC4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=c5GsmeH6JKFiGxr/OU4dJEvhmwVn631cYAesK3rcRjLWH14pZb7oWbdSu5WiRTkVd 18cJIlY3wdPVCQKxKSrvtYUwzWz2+oWJJOoSt7TLcN+o0jKSOFlbDwv8tNE1/rMH7v VtK8yQb7UezHYlZPhhDL4K0Jx7SSxlDZoVOIvh1XZCmasjmeibHWYD0l12qH5wpjVV WR9GMdwwgLfk/RZkG6/9IElnqZj+lvse0hPmO0dRFF9XePZxeAfrwZX9+cyXYcKta6 mVjRQavXfSuhU2UV8JdO1sL1OSi9rjLYEtb9T68TT4B1UMxMjchvLJkVO11xrRbXvt VaVrffUkfytHA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Cristian Ciocaltea , Emil Velikov , Mark Brown , Sasha Levin Subject: [PATCH 6.8 369/715] ASoC: SOF: amd: Compute file paths on firmware load Date: Sun, 24 Mar 2024 18:29:08 -0400 Message-ID: <20240324223455.1342824-370-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Cristian Ciocaltea [ Upstream commit d9cacc1a2af2e1cd781b5cd2a3e57fbde64f5a2d ] Commit 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if firmware files are missing") changed the order of some operations and the firmware paths are not available anymore at snd_sof_probe() time. Precisely, fw_filename_prefix is set by sof_select_ipc_and_paths() via plat_data->fw_filename_prefix =3D out_profile.fw_path; but sof_init_environment() which calls this function was moved from snd_sof_device_probe() to sof_probe_continue(). Moreover, snd_sof_probe() was moved from sof_probe_continue() to sof_init_environment(), but before the call to sof_select_ipc_and_paths(). The problem here is that amd_sof_acp_probe() uses fw_filename_prefix to compute fw_code_bin and fw_data_bin paths, and because the field is not yet initialized, the paths end up containing (null): snd_sof_amd_vangogh 0000:04:00.5: Direct firmware load for (null)/sof-vango= gh-code.bin failed with error -2 snd_sof_amd_vangogh 0000:04:00.5: sof signed firmware code bin is missing snd_sof_amd_vangogh 0000:04:00.5: error: failed to load DSP firmware -2 snd_sof_amd_vangogh: probe of 0000:04:00.5 failed with error -2 Move usage of fw_filename_prefix right before request_firmware() calls in acp_sof_load_signed_firmware(). Fixes: 6c393ebbd74a ("ASoC: SOF: core: Implement IPC version fallback if fi= rmware files are missing") Signed-off-by: Cristian Ciocaltea Reviewed-by: Emil Velikov Link: https://msgid.link/r/20231219030728.2431640-9-cristian.ciocaltea@coll= abora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- sound/soc/sof/amd/acp-loader.c | 32 ++++++++++++++++++++++++++------ sound/soc/sof/amd/acp.c | 7 ++----- 2 files changed, 28 insertions(+), 11 deletions(-) diff --git a/sound/soc/sof/amd/acp-loader.c b/sound/soc/sof/amd/acp-loader.c index e05eb7a86dd44..d2d21478399e0 100644 --- a/sound/soc/sof/amd/acp-loader.c +++ b/sound/soc/sof/amd/acp-loader.c @@ -267,29 +267,49 @@ int acp_sof_load_signed_firmware(struct snd_sof_dev *= sdev) { struct snd_sof_pdata *plat_data =3D sdev->pdata; struct acp_dev_data *adata =3D plat_data->hw_pdata; + const char *fw_filename; int ret; =20 - ret =3D request_firmware(&sdev->basefw.fw, adata->fw_code_bin, sdev->dev); + fw_filename =3D kasprintf(GFP_KERNEL, "%s/%s", + plat_data->fw_filename_prefix, + adata->fw_code_bin); + if (!fw_filename) + return -ENOMEM; + + ret =3D request_firmware(&sdev->basefw.fw, fw_filename, sdev->dev); if (ret < 0) { + kfree(fw_filename); dev_err(sdev->dev, "sof signed firmware code bin is missing\n"); return ret; } else { - dev_dbg(sdev->dev, "request_firmware %s successful\n", adata->fw_code_bi= n); + dev_dbg(sdev->dev, "request_firmware %s successful\n", fw_filename); } + kfree(fw_filename); + ret =3D snd_sof_dsp_block_write(sdev, SOF_FW_BLK_TYPE_IRAM, 0, - (void *)sdev->basefw.fw->data, sdev->basefw.fw->size); + (void *)sdev->basefw.fw->data, + sdev->basefw.fw->size); + + fw_filename =3D kasprintf(GFP_KERNEL, "%s/%s", + plat_data->fw_filename_prefix, + adata->fw_data_bin); + if (!fw_filename) + return -ENOMEM; =20 - ret =3D request_firmware(&adata->fw_dbin, adata->fw_data_bin, sdev->dev); + ret =3D request_firmware(&adata->fw_dbin, fw_filename, sdev->dev); if (ret < 0) { + kfree(fw_filename); dev_err(sdev->dev, "sof signed firmware data bin is missing\n"); return ret; =20 } else { - dev_dbg(sdev->dev, "request_firmware %s successful\n", adata->fw_data_bi= n); + dev_dbg(sdev->dev, "request_firmware %s successful\n", fw_filename); } + kfree(fw_filename); =20 ret =3D snd_sof_dsp_block_write(sdev, SOF_FW_BLK_TYPE_DRAM, 0, - (void *)adata->fw_dbin->data, adata->fw_dbin->size); + (void *)adata->fw_dbin->data, + adata->fw_dbin->size); return ret; } EXPORT_SYMBOL_NS(acp_sof_load_signed_firmware, SND_SOC_SOF_AMD_COMMON); diff --git a/sound/soc/sof/amd/acp.c b/sound/soc/sof/amd/acp.c index 9aa9600c05d61..9794d64a110fd 100644 --- a/sound/soc/sof/amd/acp.c +++ b/sound/soc/sof/amd/acp.c @@ -493,7 +493,6 @@ EXPORT_SYMBOL_NS(amd_sof_acp_resume, SND_SOC_SOF_AMD_CO= MMON); int amd_sof_acp_probe(struct snd_sof_dev *sdev) { struct pci_dev *pci =3D to_pci_dev(sdev->dev); - struct snd_sof_pdata *plat_data =3D sdev->pdata; struct acp_dev_data *adata; const struct sof_amd_acp_desc *chip; const struct dmi_system_id *dmi_id; @@ -561,8 +560,7 @@ int amd_sof_acp_probe(struct snd_sof_dev *sdev) dmi_id =3D dmi_first_match(acp_sof_quirk_table); if (dmi_id && dmi_id->driver_data) { adata->fw_code_bin =3D devm_kasprintf(sdev->dev, GFP_KERNEL, - "%s/sof-%s-code.bin", - plat_data->fw_filename_prefix, + "sof-%s-code.bin", chip->name); if (!adata->fw_code_bin) { ret =3D -ENOMEM; @@ -570,8 +568,7 @@ int amd_sof_acp_probe(struct snd_sof_dev *sdev) } =20 adata->fw_data_bin =3D devm_kasprintf(sdev->dev, GFP_KERNEL, - "%s/sof-%s-data.bin", - plat_data->fw_filename_prefix, + "sof-%s-data.bin", chip->name); if (!adata->fw_data_bin) { ret =3D -ENOMEM; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0296C188A85; Sun, 24 Mar 2024 22:41:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320061; cv=none; b=s5155n1TyCWeAwkXKaLebTRS6bjiTvwgx5O9iGgMhPM4NRGzfazva0qz9sbzLnOdP8IUFKLSBUhHDMKbpjtcN2fCsgHpVi6H5d0iEozKJZNtql3TpaoZ97TQ6Xeca4cQ3Jsi6kN5dYOlirUfNBlAlP1wMg2g5kI5WqNLzrQ1ugM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320061; c=relaxed/simple; bh=LknbtscaZXZV/9bS1cB+uwJmCI5cJHZBNwpJ1B9+Mzc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FLJ5kYwHMRXgFbYhqqb8cKoAVnYYxrsaw0zGpJYHehXaxapehzs2mEEBrhUz/9fBohmwBTCYiCam2uiCzjDljUh6lUDw+KclO6msbygK8vZhnwSzxiWTMSVlHHjN6yGiIw6IPhh3T6im7S4ui0Sdl/cwdDF6NiSiyfEyFSsFaUM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uVqDhpzF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uVqDhpzF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F1B13C43394; Sun, 24 Mar 2024 22:40:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320060; bh=LknbtscaZXZV/9bS1cB+uwJmCI5cJHZBNwpJ1B9+Mzc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uVqDhpzFKVgm41YpM59QUcoTJZqTTuvOuBlcIYHOtgJWGBpfmRBzEpdLddo8QKgFd F4jQQKVubHaLoEIytfIyX5EzX4D/DnXbLNzWenxdBYY98MaGni2wCb4AOmgBtpIptl 6E1QivQ+3NRraRJSFgLaNzyfVXbBcxvN1TRn5AXNrA/p+u9BBz9z2w3ZpXnkDb2vqv Rn3trjb+GeHIDbHO0/f5KZTYTWI7RWfpBOQowMj3LXtlrasK/5a9DdKgaZb/WPRHdq i63i/S4lGWbhIT23+PZ8et2zsQK1k758xLKv2oVs01B4ZE7Xq0Z5lgM4ZXHnuIyKN/ eErrPcHjOhpJg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Krzysztof Kozlowski , Vinod Koul , Sasha Levin Subject: [PATCH 6.8 370/715] soundwire: stream: add missing const to Documentation Date: Sun, 24 Mar 2024 18:29:09 -0400 Message-ID: <20240324223455.1342824-371-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Krzysztof Kozlowski [ Upstream commit 0707496ff4e416ea08c90053fd5fde5811b11b22 ] Commit 21f4c443731f ("soundwire: stream: constify sdw_port_config when adding devices") added const to sdw_port_config argument, but forgot documentation. Fixes: 21f4c443731f ("soundwire: stream: constify sdw_port_config when addi= ng devices") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20240117160639.1327266-1-krzysztof.kozlowsk= i@linaro.org Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- Documentation/driver-api/soundwire/stream.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/driver-api/soundwire/stream.rst b/Documentation/= driver-api/soundwire/stream.rst index b432a2de45d37..2a794484f62c9 100644 --- a/Documentation/driver-api/soundwire/stream.rst +++ b/Documentation/driver-api/soundwire/stream.rst @@ -324,12 +324,12 @@ framework, this stream state is linked to .hw_params(= ) operation. =20 int sdw_stream_add_master(struct sdw_bus * bus, struct sdw_stream_config * stream_config, - struct sdw_ports_config * ports_config, + const struct sdw_ports_config * ports_config, struct sdw_stream_runtime * stream); =20 int sdw_stream_add_slave(struct sdw_slave * slave, struct sdw_stream_config * stream_config, - struct sdw_ports_config * ports_config, + const struct sdw_ports_config * ports_config, struct sdw_stream_runtime * stream); =20 =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4AF76189281; Sun, 24 Mar 2024 22:41:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320062; cv=none; b=hKIBx6z/rk8w1cRypTmw9nquqPzB+PVeJCZPZA4H11DHmw94AWe7zW5Z68oZ9fbYMC6piTHE5iyvV3Wy66jFTE2iwguYTFoBanUvgIzCSOMdx2IkS6bLFxb33w/HjVnEJDseqYXZ4ylhgp2i81JNO886IErhIvnR8E4ouQcwa1Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320062; c=relaxed/simple; bh=NpmGYaOjFvZCqNyv/G/NLbLTYcYtn8vcWIXCfc14T6M=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=NmaIiwb39TzMNsKT3KwvEZymhnFOsbW3YIEp2Fqw55hUq0IbzZwVZkMA1hffnJKHstwPauE/vmQEX9rYl5uSFNjWrnHU6+tEBWXsSzAH2fo98ToRhBrhpXppxlZxqUA5beR95hHo2/P4jQ3EiwZV0IjWPRsHE7JRkVfJqYSd9ig= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sikFVSCR; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sikFVSCR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D73FDC433C7; Sun, 24 Mar 2024 22:41:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320061; bh=NpmGYaOjFvZCqNyv/G/NLbLTYcYtn8vcWIXCfc14T6M=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sikFVSCRqSox3XGpXgO9+VpqH+s3MsPrTswBXqfzeCJPifQ7e1Ir6NN1TQ/CnjZP/ AOOjL4i28t9ieUFcfnndm+39dHE3yKvmBA5R0MnL+KkCTowP16zigd9X7YpL1N3u43 0IqQPAtHaA779tXpHtFbD5TXHKNfk75pdtY4+84y930gLmdy/heyKpvGeb9dzDwD4l LcKQhq2cKNKrors7cpbXN4y7BlR2XjMwOagRP3vRLOHilBdJNBMAC3h5raR4ERUFe7 qKca7+RE1R39WQ71mvGxXP/lSu/+KcBfCrSYGNr5nptxzY5jbjUJYnWXpnzbQY8ePY z/S1dOq2pKmEg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Peter Robinson , Jon Hunter , Thierry Reding , Sameer Pujar , Laxman Dewangan , Vinod Koul , Sasha Levin Subject: [PATCH 6.8 371/715] dmaengine: tegra210-adma: Update dependency to ARCH_TEGRA Date: Sun, 24 Mar 2024 18:29:10 -0400 Message-ID: <20240324223455.1342824-372-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Peter Robinson [ Upstream commit 33b7db45533af240fe44e809f9dc4d604cf82d07 ] Update the architecture dependency to be the generic Tegra because the driver works on the four latest Tegra generations not just T210, if you build a kernel with a specific ARCH_TEGRA_xxx_SOC option that excludes 210 you don't get this driver. Fixes: 433de642a76c9 ("dmaengine: tegra210-adma: add support for Tegra186/T= egra194") Signed-off-by: Peter Robinson Cc: Jon Hunter Cc: Thierry Reding Cc: Sameer Pujar Cc: Laxman Dewangan Reviewed-by: Jon Hunter Link: https://lore.kernel.org/r/20240112093310.329642-2-pbrobinson@gmail.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/dma/Kconfig | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index e928f2ca0f1e9..002a5ec806207 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -643,16 +643,16 @@ config TEGRA20_APB_DMA =20 config TEGRA210_ADMA tristate "NVIDIA Tegra210 ADMA support" - depends on (ARCH_TEGRA_210_SOC || COMPILE_TEST) + depends on (ARCH_TEGRA || COMPILE_TEST) select DMA_ENGINE select DMA_VIRTUAL_CHANNELS help - Support for the NVIDIA Tegra210 ADMA controller driver. The - DMA controller has multiple DMA channels and is used to service - various audio clients in the Tegra210 audio processing engine - (APE). This DMA controller transfers data from memory to - peripheral and vice versa. It does not support memory to - memory data transfer. + Support for the NVIDIA Tegra210/Tegra186/Tegra194/Tegra234 ADMA + controller driver. The DMA controller has multiple DMA channels + and is used to service various audio clients in the Tegra210 + audio processing engine (APE). This DMA controller transfers + data from memory to peripheral and vice versa. It does not + support memory to memory data transfer. =20 config TIMB_DMA tristate "Timberdale FPGA DMA support" --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 00287189299; Sun, 24 Mar 2024 22:41:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320063; cv=none; b=bqA5IYFeIAsiksmF+6HRwWSB+TUpaLzuJ+aRTTHBG6JCc8sXAdJuPWBgZnXBCeRE6Mz/L/VAKB5ZWtNuj28B9vLcILOhelRjV9yPOQ9DLlBCiJsBscYEgY4uZo4jLFKhtJ2j3280w3H8LUBimYxPSdtVxP5nnlbcQRS3Fi9mgNg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320063; c=relaxed/simple; bh=vwK9mT2SDzhQT/VK/uvqjMKc6ljiGp44qtXkgvlh3Js=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CjbYkcgW0TYhskTZmLd+vQMZ2u6QoAH3ifWyOA2zjn+0tpDoMG48aul+PGH+5L3I78GkZPjlkIQthrC+1quOkTwEq926/Q32hk821etnpu1d7QFqB1o/pxC/ucl8O+BHWPSXCRJ7QVXOnFYqOAKCoFmUPRILGM6IPK9B+AUsqDc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WjJpLL18; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WjJpLL18" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 26EFBC43390; Sun, 24 Mar 2024 22:41:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320062; bh=vwK9mT2SDzhQT/VK/uvqjMKc6ljiGp44qtXkgvlh3Js=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WjJpLL18EQGnOpp86meQ1tarYk2LavsUV/j+FCiDGaREGeaoPcjQyJphCKNvGiGpJ vkonVi7rcgHp4WewDslNtUfEJtHtGl5kY5VXEkdwjCfF957Vdme32Xuzy+KtAuV/Yu t+obh3od9ZZsQ4ZI2f5Pis2b/OeXKzyG/J5pnrEwSyOHjazR72JaEwSHoVP+lteN0D l0H9gOoWzAf5Ofrs4ooHBr8VnTHQZWWoc17WiyfFynHDbSGglmc3oooQdGkBaKMVwH /OvpIc1uE+nPJDaHVbTeYtuqwdE96qcdiabORYjEzbzRE8Rl0rTyqDKlen3ImiW4ov FJ0Rc2+AZsdCg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Alexander Stein , Robert Foss , Sasha Levin Subject: [PATCH 6.8 372/715] media: tc358743: register v4l2 async device only after successful setup Date: Sun, 24 Mar 2024 18:29:11 -0400 Message-ID: <20240324223455.1342824-373-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Alexander Stein [ Upstream commit 87399f1ff92203d65f1febf5919429f4bb613a02 ] Ensure the device has been setup correctly before registering the v4l2 async device, thus allowing userspace to access. Signed-off-by: Alexander Stein Reviewed-by: Robert Foss Fixes: 4c5211a10039 ("[media] tc358743: register v4l2 asynchronous subdevic= e") Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20240110090111.458115-1= -alexander.stein@ew.tq-group.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/media/i2c/tc358743.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c index 2785935da497b..558152575d102 100644 --- a/drivers/media/i2c/tc358743.c +++ b/drivers/media/i2c/tc358743.c @@ -2091,9 +2091,6 @@ static int tc358743_probe(struct i2c_client *client) state->mbus_fmt_code =3D MEDIA_BUS_FMT_RGB888_1X24; =20 sd->dev =3D &client->dev; - err =3D v4l2_async_register_subdev(sd); - if (err < 0) - goto err_hdl; =20 mutex_init(&state->confctl_mutex); =20 @@ -2151,6 +2148,10 @@ static int tc358743_probe(struct i2c_client *client) if (err) goto err_work_queues; =20 + err =3D v4l2_async_register_subdev(sd); + if (err < 0) + goto err_work_queues; + v4l2_info(sd, "%s found @ 0x%x (%s)\n", client->name, client->addr << 1, client->adapter->name); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EAED1189282; Sun, 24 Mar 2024 22:41:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320064; cv=none; b=ooMWPLC43mscegf/6NE+RKLqE7xn8bDsgZGcNHNnxInJASH+/mJgfY9JzQ1o+XxSLYVddB+ygUkuzI6gEFVs3XiuDbkHDcu0vbbG08NfA42c60xGi8ChzM9TtigejASi/YLskPbv2iKuB5utnCPt0DAjIeF5N2XhQeOJBMHWb/M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320064; c=relaxed/simple; bh=VNH8aazt+hgmi98g0sVxWScnSlD7pb3NGFc4YISxvsA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YBS7TEaqIzBFHtqrhS2ygtiLPb60pVaPXGsXI2i8Ry3q7kij8EAFoJ05E2Ku2t56kQSH6ZiXuop5Y5XkDBGDIqvQmCL68rSeUq/YaxKoMVI106ZT/0Y5B33vHM67UQoqpUaKQu46LPl/5SKDTjCzjq19qSZarOSW3WdMLaLwsB0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lhBtUHlZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lhBtUHlZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0C609C433C7; Sun, 24 Mar 2024 22:41:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320063; bh=VNH8aazt+hgmi98g0sVxWScnSlD7pb3NGFc4YISxvsA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lhBtUHlZhal4e8XuhF2nFS4EoxLGLWyM29ZKEQPmw9bLLvd7hK19vkQP2vK270jnG DJSD7ian7wIVeFUAr5/EIvb4oS2vs5VyK7jGmx/MygyGDqizLTG5lmGwzwaMvNGr8w Y3ijdMpKeiVq09Aq7yjI+HYYqASpaJ7tePh0oaTdgkKBzJCfPcV+BfXkcyKTCCdeDU J1fbqn1Mc6ePpeLU/Sydap4QcuxFXK6o4NfIxW6f2ER7w4lhvJNaRAm50yPRvcLjrN 5UWJt44pci4SoI6QJ/pN4vqf+KnzDY+zX6BYffMfDnIgYVbNxJPqgVKkLwcLbFr2ib 8dIbZqewDmQnQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Julien Massot , Jai Luthra , Sakari Ailus , Hans Verkuil , Sasha Levin Subject: [PATCH 6.8 373/715] media: cadence: csi2rx: use match fwnode for media link Date: Sun, 24 Mar 2024 18:29:12 -0400 Message-ID: <20240324223455.1342824-374-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Julien Massot [ Upstream commit 448699c522af9e3266f168c3f51f4c3713c7bee1 ] Since commit 1029939b3782 ("media: v4l: async: Simplify async sub-device fw= node matching"), async connections are matched using the async sub-device fwnode, not that of the endpoint. Fix this by using the fwnode of the connection match to find the pad. Fixes: 1029939b3782 ("media: v4l: async: Simplify async sub-device fwnode m= atching") Signed-off-by: Julien Massot Reviewed-by: Jai Luthra Signed-off-by: Sakari Ailus Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/media/platform/cadence/cdns-csi2rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/cadence/cdns-csi2rx.c b/drivers/media/p= latform/cadence/cdns-csi2rx.c index fead5426830e8..0ea5fa956fe9a 100644 --- a/drivers/media/platform/cadence/cdns-csi2rx.c +++ b/drivers/media/platform/cadence/cdns-csi2rx.c @@ -468,7 +468,7 @@ static int csi2rx_async_bound(struct v4l2_async_notifie= r *notifier, struct csi2rx_priv *csi2rx =3D v4l2_subdev_to_csi2rx(subdev); =20 csi2rx->source_pad =3D media_entity_get_fwnode_pad(&s_subdev->entity, - s_subdev->fwnode, + asd->match.fwnode, MEDIA_PAD_FL_SOURCE); if (csi2rx->source_pad < 0) { dev_err(csi2rx->dev, "Couldn't find output pad for subdev %s\n", --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 29F9A189A38; Sun, 24 Mar 2024 22:41:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320065; cv=none; b=Cuq/REdD9IKCjltHyJJjmweMYZPBr/wB6liVjJjXrnr+1RqibfcZMZATkyWtVfr0O51Tivwed2wNhobAICWQavyMmjJkLVZTeE/C5FeWxt1Q6UWDIPTBCfys5ZT3QPX/YiLRtre9+/uCi1aL6Vz3XICdkRyVwnmdyjFIZHWoZJs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320065; c=relaxed/simple; bh=Bi+CbrTK4iD6H6njG6um+soEi21PZdr3qsucuDdlk/w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=cmjxeRvdo19df0GPA7f/E7N1HoT7nyUs3tuBg7SESXGwYm120wVVRAGDICLhkWvu96CTMBnIgCcsB61Qq6DfHJur8dOqw11AEzTpKv6GNC9Ig+KLSEaT16Nph7vqYhOAD1wcC+C6wMOjps7rCvFH1m3CwKKitM8B1AZNN6cHarI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=r7quGLt4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="r7quGLt4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D5E1C433F1; Sun, 24 Mar 2024 22:41:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320064; bh=Bi+CbrTK4iD6H6njG6um+soEi21PZdr3qsucuDdlk/w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=r7quGLt4gvan3PXumkrefb3EAeZaGxUq4CPkzXtqyICzinx+ss0gwMtp0LZ+lXIxZ tcsoXwxms0lAhGIUoLvA9ZSfMnBepXQ2rq3hkX3k8K7PB3jWuRi0SPW7N6SKFiobtJ qSsMr+C/OQfYiXWlGDfjK3W1RqxOmRq6h8q+lRuYy91b80/SnV42DHljHFLh8t2xdF b9Fbl6qEns3+E8MGIURgGdKgrK7yJ4/ByDAxkN3n256G4hL4a5Z0aSFmyDFg3Ops3E MK+BwHTdgCAM+wDTi+av41m1WPB/zUiuVm8N7Gq1/c2Bxgz9MkGENllfiYTLajmmMF L9h243NiWtf3g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: =?UTF-8?q?Ilpo=20J=C3=A4rvinen?= , Bjorn Helgaas , Sasha Levin Subject: [PATCH 6.8 374/715] PCI/DPC: Print all TLP Prefixes, not just the first Date: Sun, 24 Mar 2024 18:29:13 -0400 Message-ID: <20240324223455.1342824-375-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Ilpo J=C3=A4rvinen [ Upstream commit 6568d82512b0a64809acff3d7a747362fa4288c8 ] The TLP Prefix Log Register consists of multiple DWORDs (PCIe r6.1 sec 7.9.14.13) but the loop in dpc_process_rp_pio_error() keeps reading from the first DWORD, so we print only the first PIO TLP Prefix (duplicated several times), and we never print the second, third, etc., Prefixes. Add the iteration count based offset calculation into the config read. Fixes: f20c4ea49ec4 ("PCI/DPC: Add eDPC support") Link: https://lore.kernel.org/r/20240118110815.3867-1-ilpo.jarvinen@linux.i= ntel.com Signed-off-by: Ilpo J=C3=A4rvinen [bhelgaas: add user-visible details to commit log] Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/pci/pcie/dpc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/pcie/dpc.c b/drivers/pci/pcie/dpc.c index 94111e4382413..e5d7c12854fa0 100644 --- a/drivers/pci/pcie/dpc.c +++ b/drivers/pci/pcie/dpc.c @@ -234,7 +234,7 @@ static void dpc_process_rp_pio_error(struct pci_dev *pd= ev) =20 for (i =3D 0; i < pdev->dpc_rp_log_size - 5; i++) { pci_read_config_dword(pdev, - cap + PCI_EXP_DPC_RP_PIO_TLPPREFIX_LOG, &prefix); + cap + PCI_EXP_DPC_RP_PIO_TLPPREFIX_LOG + i * 4, &prefix); pci_err(pdev, "TLP Prefix Header: dw%d, %#010x\n", i, prefix); } clear_status: --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C5E21189A50; Sun, 24 Mar 2024 22:41:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320065; cv=none; b=CDn1rk2YbC0pLyXGw2Zi14PsQyIGPDj9rInMLZBpol26d2unlHGXWIyZJfdf4jsvbaBrSpblDbubL9l5GHlDBmrSft1ld5P+aRKnl6145y4tUhOtkpAyRhgSSqCOVLfmwX6Um/BqS0OOOWAhpAWpbJP53CWZMlgZnTKGbWnn+Jo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320065; c=relaxed/simple; bh=FT+rCKaxioFNKhY6F29SWX7MZZFV7Geg4xGwQ0Qs/Fw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JzMZ9iYUtXvLfbgku5OsJxBuxuEAGlkEZmBOWzxtIktowRKwbemKPwifLRe2xq6qdW/2qVfr521dgw1HO8Tw1iAYdklG4v7X51vhK31vlb9RPOgxPD3+VdvJ8BD1aHGIW6Mwdz58bixkiQTsibHWi3PikbfeLjE0aW8fUdK0XsA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CcNnduTi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CcNnduTi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 045EDC43399; Sun, 24 Mar 2024 22:41:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320065; bh=FT+rCKaxioFNKhY6F29SWX7MZZFV7Geg4xGwQ0Qs/Fw=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CcNnduTiJ4RP1lYD9xe9e+V14UilEwk1Ph4ZPsWJtMpi2OX9Xgn7EVfKc7d9JZt9+ bJyU8xFAnroLsy3SHxvaXAiCfzJq9Ludu5wWYYHA8OMHmrc9C9gtht5nYdkXNOnvqL 8HOYkJy9yo6PnxDbIhcgqrMMfyEB/WZCPxy53AnNRRAzWEfsDUrTDcrvH3MTpuhgjO Gs0J9k/TWAVCBsQdVY9hL1D1WlzNKp76MFhpAynjxeUM5Fq2vn5QjDX5Tq1Fe1YdKq HPCsCPXyK8IK/uF8awWGGj/GKocvZ9Mxg3u007i11mY2kgKsbsYdOgoivEGLzizGC5 3soV9yGf+I4ww== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yang Jihong , Namhyung Kim , Sasha Levin Subject: [PATCH 6.8 375/715] perf record: Fix possible incorrect free in record__switch_output() Date: Sun, 24 Mar 2024 18:29:14 -0400 Message-ID: <20240324223455.1342824-376-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yang Jihong [ Upstream commit aff10a165201f6f60cff225083ce301ad3f5d8f1 ] perf_data__switch() may not assign a legal value to 'new_filename'. In this case, 'new_filename' uses the on-stack value, which may cause a incorrect free and unexpected result. Fixes: 03724b2e9c45 ("perf record: Allow to limit number of reported perf.d= ata files") Signed-off-by: Yang Jihong Acked-by: Namhyung Kim Link: https://lore.kernel.org/r/20240119040304.3708522-2-yangjihong1@huawei= .com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/perf/builtin-record.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c index 86c9101251726..a8dfa533c1663 100644 --- a/tools/perf/builtin-record.c +++ b/tools/perf/builtin-record.c @@ -1830,8 +1830,8 @@ static int record__switch_output(struct record *rec, bool at_exit) { struct perf_data *data =3D &rec->data; + char *new_filename =3D NULL; int fd, err; - char *new_filename; =20 /* Same Size: "2015122520103046"*/ char timestamp[] =3D "InvalidTimestamp"; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D6868136E0D; Sun, 24 Mar 2024 22:41:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320066; cv=none; b=ZyMrxIb1aGvPL4cJJFM+eqwCSYD8CaFFkp486AxeXH5BBtMZqnwD+DtGztKhxwXZNZcjDkmWHnMfYaJX/bJuC8HBhXJm0zt8QhqDfuWe4fOdoXngrwSyTzCJ0yVVM7nBmVlz+2nGKoWhF9sr/Y1uDA1AY/3lrAEP0dww4VL4QMg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320066; c=relaxed/simple; bh=SfnGMASuO5Dvr2j3Q1CmvC8pIQdpk9kbiq/gwKfVvQs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ra+bZlXuINeOXNC4KcHr86xSwOGlxDP52s2RQJ2x2FmVIlHwYm3LKTqYZBIMjr9MPCkVJGzSayNt/Kndx1jK+Co4zT0BPS37HNv2qMKgIRMv7tjuMTWXXm9EaaDMYv21lIY4wYHQG9Gv6J6yPD3zzrk1HJHhJ2DLseqbkNCuXuk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CjDTLIK5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CjDTLIK5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3EC0C43390; Sun, 24 Mar 2024 22:41:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320066; bh=SfnGMASuO5Dvr2j3Q1CmvC8pIQdpk9kbiq/gwKfVvQs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CjDTLIK5feKATZ0DQkkYf+9TFwG5VONRq4pGMsyNGntwaxA3Y3cb7CjYA+wU5yafC tY/hNtPFMEqN7ZAXKrD7J/EnYKDhO2EuF9QDrAq2+sl2y8vujBKgSBV41QOq639Tez rOdiZ23XLUgRFGYJu06HrCqKYt9jhh0WUf7OaFmkMXxbGzLbxvn9MucR0AW/aKv0IU 7vxyif3nhmOzAkXqBAv+25fej0X2qqZtrjxfw+MgEZBxf5TdSzn5fRVJkUIMF3oaUP UEfBIT+YtbImutFBMyiHXS8GwEnjpYnyk8gQOMyRKbBM1MSikZQ7RS3FAzL2Gc9N9k YinPx/Txzfz9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yang Jihong , Namhyung Kim , Sasha Levin Subject: [PATCH 6.8 376/715] perf record: Check conflict between '--timestamp-filename' option and pipe mode before recording Date: Sun, 24 Mar 2024 18:29:15 -0400 Message-ID: <20240324223455.1342824-377-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yang Jihong [ Upstream commit 02f9b50e04812782fd006ed21c6da1c5e3e373da ] In pipe mode, no need to switch perf data output, therefore, '--timestamp-filename' option should not take effect. Check the conflict before recording and output WARNING. In this case, the check pipe mode in perf_data__switch() can be removed. Before: # perf record --timestamp-filename -o- perf test -w noploop | perf report= -i- --percent-limit=3D1 # To display the perf.data header info, please use --header/--header-only= options. # [ perf record: Woken up 1 times to write data ] [ perf record: Dump -.2024011812110182 ] # # Total Lost Samples: 0 # # Samples: 4K of event 'cycles:P' # Event count (approx.): 2176784359 # # Overhead Command Shared Object Symbol # ........ ....... .................... ..............................= ........ # 97.83% perf perf [.] noploop # # (Tip: Print event counts in CSV format with: perf stat -x,) # After: # perf record --timestamp-filename -o- perf test -w noploop | perf report= -i- --percent-limit=3D1 WARNING: --timestamp-filename option is not available in pipe mode. # To display the perf.data header info, please use --header/--header-only= options. # [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.000 MB - ] # # Total Lost Samples: 0 # # Samples: 4K of event 'cycles:P' # Event count (approx.): 2185575421 # # Overhead Command Shared Object Symbol # ........ ....... ..................... .............................= ................ # 97.75% perf perf [.] noploop # # (Tip: Profiling branch (mis)predictions with: perf record -b / perf rep= ort) # Fixes: ecfd7a9c044e ("perf record: Add '--timestamp-filename' option to app= end timestamp to output file name") Signed-off-by: Yang Jihong Acked-by: Namhyung Kim Link: https://lore.kernel.org/r/20240119040304.3708522-3-yangjihong1@huawei= .com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/perf/builtin-record.c | 5 +++++ tools/perf/util/data.c | 2 -- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c index a8dfa533c1663..3ddd4381aebd2 100644 --- a/tools/perf/builtin-record.c +++ b/tools/perf/builtin-record.c @@ -2472,6 +2472,11 @@ static int __cmd_record(struct record *rec, int argc= , const char **argv) if (data->is_pipe && rec->evlist->core.nr_entries =3D=3D 1) rec->opts.sample_id =3D true; =20 + if (rec->timestamp_filename && perf_data__is_pipe(data)) { + rec->timestamp_filename =3D false; + pr_warning("WARNING: --timestamp-filename option is not available in pip= e mode.\n"); + } + evlist__uniquify_name(rec->evlist); =20 /* Debug message used by test scripts */ diff --git a/tools/perf/util/data.c b/tools/perf/util/data.c index c29d8a382b196..550675ce0b787 100644 --- a/tools/perf/util/data.c +++ b/tools/perf/util/data.c @@ -430,8 +430,6 @@ int perf_data__switch(struct perf_data *data, { int ret; =20 - if (check_pipe(data)) - return -EINVAL; if (perf_data__is_read(data)) return -EINVAL; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 94BB8136E27; Sun, 24 Mar 2024 22:41:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320067; cv=none; b=Ri0C/FidlBMsq2Wj6K8Rr1NFgL4rqPWaBP5t2VAM3i7Q8gp64+bcv2Y8ANn9YpmcCokty5wBBqP8ZMwPj+buZ6EyF5rVMFmDJipc9N6zWguFKLPzzAn5tX9KMXsL19DjAzBcR0mfWo8o52hHa1L7j/LO8L9S79p+Sp6TS84nw+M= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320067; c=relaxed/simple; bh=k0CHCQeQYAxizY/a36oGNxW78++AXdIg+U+sNWUr7Wc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lBP6Ro4uKaD02AP6bPAFTFfQVoQ8NulSFUjne1eL5CQI8jwc3kLAtuctaHet97StccVeJqP+V7N07BJDmwJarypF1S78g4v1hLWluOQX22ta9uRe/4fR02JWT4IblXepvqS/ERnaCECirmxLyc+Q17ekZj+WL69bAepPL98Wquc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MpoppMnI; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MpoppMnI" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D1574C433A6; Sun, 24 Mar 2024 22:41:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320067; bh=k0CHCQeQYAxizY/a36oGNxW78++AXdIg+U+sNWUr7Wc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=MpoppMnI3ik6oZcmkNQF5jofg5C0CnX1mfV0hP5o8nctMqdFu+u0wJ4RTQluNowPs SZQSqgr9oHNdcEwMDcH+1BLU6BaBCHIM0L5UeJQVuELsLLjjOcJa0BLPRLlceXt1uC l38s/aRV/jqCSta7iZO1cGv8n/kh6Nr+eL4+rB6iZ9a9Tea/wC9JhTZALt5uUvjMGY d8PyLCwT9i2iXZP0qHK9Yj2qHTbgPoNbV7ffT7DPu1NEJphCFbtuBpEMy0EYK/gOgk iycDjolvyybKOxkLGvhn9Rqhr0hB3XC9IzZYSgQjyJ3SoJadX/JKpA894uBoNnzS6k HaQojoCLQrt/Q== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Mikhail Khvainitski , Jiri Kosina , Sasha Levin Subject: [PATCH 6.8 377/715] HID: lenovo: Add middleclick_workaround sysfs knob for cptkbd Date: Sun, 24 Mar 2024 18:29:16 -0400 Message-ID: <20240324223455.1342824-378-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Mikhail Khvainitski [ Upstream commit 2814646f76f8518326964f12ff20aaee70ba154d ] Previous attempt to autodetect well-behaving patched firmware introduced in commit 46a0a2c96f0f ("HID: lenovo: Detect quirk-free fw on cptkbd and stop applying workaround") has shown that there are false-positives on original firmware (on both 1st gen and 2nd gen keyboards) which causes the middle button click workaround to be mistakenly disabled. This commit adds explicit parameter to sysfs to control this workaround. Fixes: 46a0a2c96f0f ("HID: lenovo: Detect quirk-free fw on cptkbd and stop = applying workaround") Fixes: 43527a0094c1 ("HID: lenovo: Restrict detection of patched firmware o= nly to USB cptkbd") Signed-off-by: Mikhail Khvainitski Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/hid/hid-lenovo.c | 57 +++++++++++++++++++++++++++------------- 1 file changed, 39 insertions(+), 18 deletions(-) diff --git a/drivers/hid/hid-lenovo.c b/drivers/hid/hid-lenovo.c index 149a3c74346b4..f86c1ea83a037 100644 --- a/drivers/hid/hid-lenovo.c +++ b/drivers/hid/hid-lenovo.c @@ -54,10 +54,10 @@ struct lenovo_drvdata { /* 0: Up * 1: Down (undecided) * 2: Scrolling - * 3: Patched firmware, disable workaround */ u8 middlebutton_state; bool fn_lock; + bool middleclick_workaround_cptkbd; }; =20 #define map_key_clear(c) hid_map_usage_clear(hi, usage, bit, max, EV_KEY, = (c)) @@ -621,6 +621,36 @@ static ssize_t attr_sensitivity_store_cptkbd(struct de= vice *dev, return count; } =20 +static ssize_t attr_middleclick_workaround_show_cptkbd(struct device *dev, + struct device_attribute *attr, + char *buf) +{ + struct hid_device *hdev =3D to_hid_device(dev); + struct lenovo_drvdata *cptkbd_data =3D hid_get_drvdata(hdev); + + return snprintf(buf, PAGE_SIZE, "%u\n", + cptkbd_data->middleclick_workaround_cptkbd); +} + +static ssize_t attr_middleclick_workaround_store_cptkbd(struct device *dev, + struct device_attribute *attr, + const char *buf, + size_t count) +{ + struct hid_device *hdev =3D to_hid_device(dev); + struct lenovo_drvdata *cptkbd_data =3D hid_get_drvdata(hdev); + int value; + + if (kstrtoint(buf, 10, &value)) + return -EINVAL; + if (value < 0 || value > 1) + return -EINVAL; + + cptkbd_data->middleclick_workaround_cptkbd =3D !!value; + + return count; +} + =20 static struct device_attribute dev_attr_fn_lock =3D __ATTR(fn_lock, S_IWUSR | S_IRUGO, @@ -632,10 +662,16 @@ static struct device_attribute dev_attr_sensitivity_c= ptkbd =3D attr_sensitivity_show_cptkbd, attr_sensitivity_store_cptkbd); =20 +static struct device_attribute dev_attr_middleclick_workaround_cptkbd =3D + __ATTR(middleclick_workaround, S_IWUSR | S_IRUGO, + attr_middleclick_workaround_show_cptkbd, + attr_middleclick_workaround_store_cptkbd); + =20 static struct attribute *lenovo_attributes_cptkbd[] =3D { &dev_attr_fn_lock.attr, &dev_attr_sensitivity_cptkbd.attr, + &dev_attr_middleclick_workaround_cptkbd.attr, NULL }; =20 @@ -686,23 +722,7 @@ static int lenovo_event_cptkbd(struct hid_device *hdev, { struct lenovo_drvdata *cptkbd_data =3D hid_get_drvdata(hdev); =20 - if (cptkbd_data->middlebutton_state !=3D 3) { - /* REL_X and REL_Y events during middle button pressed - * are only possible on patched, bug-free firmware - * so set middlebutton_state to 3 - * to never apply workaround anymore - */ - if (hdev->product =3D=3D USB_DEVICE_ID_LENOVO_CUSBKBD && - cptkbd_data->middlebutton_state =3D=3D 1 && - usage->type =3D=3D EV_REL && - (usage->code =3D=3D REL_X || usage->code =3D=3D REL_Y)) { - cptkbd_data->middlebutton_state =3D 3; - /* send middle button press which was hold before */ - input_event(field->hidinput->input, - EV_KEY, BTN_MIDDLE, 1); - input_sync(field->hidinput->input); - } - + if (cptkbd_data->middleclick_workaround_cptkbd) { /* "wheel" scroll events */ if (usage->type =3D=3D EV_REL && (usage->code =3D=3D REL_WHEEL || usage->code =3D=3D REL_HWHEEL)) { @@ -1166,6 +1186,7 @@ static int lenovo_probe_cptkbd(struct hid_device *hde= v) cptkbd_data->middlebutton_state =3D 0; cptkbd_data->fn_lock =3D true; cptkbd_data->sensitivity =3D 0x05; + cptkbd_data->middleclick_workaround_cptkbd =3D true; lenovo_features_set_cptkbd(hdev); =20 ret =3D sysfs_create_group(&hdev->dev.kobj, &lenovo_attr_group_cptkbd); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4626D18A711; Sun, 24 Mar 2024 22:41:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320069; cv=none; b=F5Km6h2O7F8tHcAD6ouCRIOr4DFJfJnFOtgd3BUINZYM6fY1bWmmmDPRfsiFpdsWsY5ERDUJvqT+xc/munv/Fp0A4mUS5cMbW1C10dyl6hu6kxsglvioMvo9MoMcv4a6jBKY77psr27yM1YaZgXJO28lC+o6lksGKojBEgv6dVI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320069; c=relaxed/simple; bh=ScdJiw+URJuyh2T7e7ak8jdhuXXwsn0SgimfE69B4C0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XPC6seWBbraAkdAp5spDg6HYEJJXvktZGKcz9IEApY95SFhmFI3CWb4zmTutVfQPJh7YeDtUUezLal8vMHcH1eoP/JxXGapHyIU7aRmXR3X0Q4gHHuwd4IPDutOzyFV1MZx/P2hcCeXhgsmDghdJ9/Dvzk4+etpMNKpOzPJr4WI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OlO2AUgr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OlO2AUgr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BA07CC433B1; Sun, 24 Mar 2024 22:41:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320068; bh=ScdJiw+URJuyh2T7e7ak8jdhuXXwsn0SgimfE69B4C0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OlO2AUgrGEg0dAeLPb799rs/MMfp8nfmij5qMYv+Gupdpko3O2TLjheSFtWLAWnIA RhvnLfa+Zmw6IOYGiQtu6QkVKiB6sL5rvfD6UlOUCWfnjk5EYlyMlnoaT08tHVlWGZ 03Hh+O7OlOC988QDIyxcpuUc4yRFOz7eh3EdKoqIl0RQc7qGHIN0FEGj7afLqjFlP6 G266tM5ryWwALpToY76QKQ/6gbP76f3KWJaYd82+dVfnoSR2jyFz775ZG8pQ3SHLJw Y3USvIqFHvtviC0IeM9JjKcC+YapAnp+yVQBPgQiNf/qRotlAWkj4CBJSt2cA8CjBV QKSEtwUNUPukA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Srinivasan Shanmugam , Alex Hung , Qingqing Zhuo , Rodrigo Siqueira , Aurabindo Pillai , Alex Deucher , Harry Wentland , Sasha Levin Subject: [PATCH 6.8 378/715] drm/amd/display: Fix a potential buffer overflow in 'dp_dsc_clock_en_read()' Date: Sun, 24 Mar 2024 18:29:17 -0400 Message-ID: <20240324223455.1342824-379-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Srinivasan Shanmugam [ Upstream commit 4b09715f1504f1b6e8dff0e9643630610bc05141 ] Tell snprintf() to store at most 10 bytes in the output buffer instead of 30. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp= _dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10 Fixes: c06e09b76639 ("drm/amd/display: Add DSC parameters logging to debugf= s") Cc: Alex Hung Cc: Qingqing Zhuo Cc: Rodrigo Siqueira Cc: Aurabindo Pillai Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Harry Wentland Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c b/dr= ivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c index 68a8463239127..85fc6181303bb 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_debugfs.c @@ -1483,7 +1483,7 @@ static ssize_t dp_dsc_clock_en_read(struct file *f, c= har __user *buf, const uint32_t rd_buf_size =3D 10; struct pipe_ctx *pipe_ctx; ssize_t result =3D 0; - int i, r, str_len =3D 30; + int i, r, str_len =3D 10; =20 rd_buf =3D kcalloc(rd_buf_size, sizeof(char), GFP_KERNEL); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 90F2E18A709; Sun, 24 Mar 2024 22:41:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320070; cv=none; b=CWrO0v++ODsNvA/cz+IPWzPm2N1luWrfqy49w6pGHNS46rT8mCXt0GaX7pDeAKcAlvU5bRo7tqDcNErTYk7EO87kM7PNLd53lnJS6iFjczGM8ru3guFqxaMC5qN2hbG0cVmizotQeqHH7IN9f0oSFgC5xLPkDhYJSl1SID4q1kY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320070; c=relaxed/simple; bh=MqLeLz/RiB5JWBEgcZw3fmstetrs49NWUuOfQE+Oe1E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GokntsAQ0RUiW07v7RdHelCLdH6Ge4s7HSfW3pzD2bWQkKt9N8HqYPVrzjX9p+h6V2pCuLD0muk4IFss0M+z330kpADpizdf1Yl3LzULc/x+F7ty82v1tT6JXQpqbThFA6eYr8E9vnS2tHonwY3b643EmRuERi4zz3VD9n+QIKk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eJ0a3hUy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eJ0a3hUy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 21FFAC433F1; Sun, 24 Mar 2024 22:41:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320070; bh=MqLeLz/RiB5JWBEgcZw3fmstetrs49NWUuOfQE+Oe1E=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eJ0a3hUy4o4eBUBbjSw6YY2FE+sQh7ZcLTEzlTNPdP5LGqQtCk8NKJo8GG1rBkXup 0Eyb3zYT80YTtVVg3ExARVWHUXHCvprn1hJVKo00vj6YH9mfxKrWUq0pnJGzkscTo6 UWOgyigyfuvO1jGZQYY1HH5BoWS9AW/Vn5iGHhFbsXH9vj4EYM7ru7bgDphJ5xC92q Xn48nFt9DYYhT1f2Sw7dl17w3qfwDrI+5c2dkbjiv8wbh/o2xlUw9WCmCO/XnSkWrG qPG5qSc3abiLYq8XWS0y7u1nyLXATJpMDYJENje9aZOIp8lZDL7NPrJgJ9HsobCyWB z3HGUlrJUPDKA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ian Rogers , Kan Liang , James Clark , Caleb Biggers , Edward Baker , Perry Taylor , Samantha Alt , Weilin Wang , Namhyung Kim , Sasha Levin Subject: [PATCH 6.8 379/715] perf pmu: Treat the msr pmu as software Date: Sun, 24 Mar 2024 18:29:18 -0400 Message-ID: <20240324223455.1342824-380-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ian Rogers [ Upstream commit 24852ef2e2d5c555c2da05baff112ea414b6e0f5 ] The msr PMU is a software one, meaning msr events may be grouped with events in a hardware context. As the msr PMU isn't marked as a software PMU by perf_pmu__is_software, groups with the msr PMU in are broken and the msr events placed in a different group. This may lead to multiplexing errors where a hardware event isn't counted while the msr event, such as tsc, is. Fix all of this by marking the msr PMU as software, which agrees with the driver. Before: ``` $ perf stat -e '{slots,tsc}' -a true WARNING: events were regrouped to match PMUs Performance counter stats for 'system wide': 1,750,335 slots 4,243,557 tsc 0.001456717 seconds time elapsed ``` After: ``` $ perf stat -e '{slots,tsc}' -a true Performance counter stats for 'system wide': 12,526,380 slots 3,415,163 tsc 0.001488360 seconds time elapsed ``` Fixes: 251aa040244a ("perf parse-events: Wildcard most "numeric" events") Signed-off-by: Ian Rogers Reviewed-by: Kan Liang Cc: James Clark Cc: Caleb Biggers Cc: Edward Baker Cc: Perry Taylor Cc: Samantha Alt Cc: Weilin Wang Link: https://lore.kernel.org/r/20240124234200.1510417-1-irogers@google.com Signed-off-by: Namhyung Kim Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/perf/util/pmu.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c index 3c9609944a2f3..88b9aa7d3a27a 100644 --- a/tools/perf/util/pmu.c +++ b/tools/perf/util/pmu.c @@ -1760,6 +1760,12 @@ bool pmu__name_match(const struct perf_pmu *pmu, con= st char *pmu_name) =20 bool perf_pmu__is_software(const struct perf_pmu *pmu) { + const char *known_sw_pmus[] =3D { + "kprobe", + "msr", + "uprobe", + }; + if (pmu->is_core || pmu->is_uncore || pmu->auxtrace) return false; switch (pmu->type) { @@ -1771,7 +1777,11 @@ bool perf_pmu__is_software(const struct perf_pmu *pm= u) case PERF_TYPE_BREAKPOINT: return true; default: break; } - return !strcmp(pmu->name, "kprobe") || !strcmp(pmu->name, "uprobe"); + for (size_t i =3D 0; i < ARRAY_SIZE(known_sw_pmus); i++) { + if (!strcmp(pmu->name, known_sw_pmus[i])) + return true; + } + return false; } =20 FILE *perf_pmu__open_file(const struct perf_pmu *pmu, const char *name) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 87BC8136E27; Sun, 24 Mar 2024 22:41:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320071; cv=none; b=swgmjsjHEFrsfZ1dP+HwS3uGpC84KTthiCEiuC8owoxhZS9eaN5aQqAZ29KJHc5cIUsBdtrMBr3AzfzY9I+EJHCuDrlMSIsi230EaV7CHh5rOWjBCZ4XWFBxt2NIkkCswXjzvdfxigSydcDnuk+fznBccXvokhzuWR+9Bcv87s4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320071; c=relaxed/simple; bh=gMPS2vvjXy5HnoZPJSlfOwuKwICB67VYD2q0qu8sqvY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ae2LUULl1WEObnKEjkPgX/Emfzd3gO6ew7iAfySFtWNjYjCfghl42jg62gFeM2UFE/noAZqXFj5ghqh0MqaKcz55zJrklehp15YEEMUiUfVp+L6B+CDxdGa4PcwWQ33RgmKaqfe7YjWRB2kvo0gEjGg5M9VCwmG7MUhhG/7Oebc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OX67gb4x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OX67gb4x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AA1B8C433C7; Sun, 24 Mar 2024 22:41:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320071; bh=gMPS2vvjXy5HnoZPJSlfOwuKwICB67VYD2q0qu8sqvY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OX67gb4xWoegb4PHrcE+l+Da4+nWGPmHZJbKVn7YM+DYJ7IIJ7kr0/piaI8LvSnen pJ4rjXMDIQcdtizjJW274Y1Y4qqxcjzxwqgn51VvFPzHknWf7qakm3ei5QUvpLtkgl ira+JBgqrrRVxKCcaLX0WX1djcNA0pspoeNI4ZRxXkSvA+iQzViyJIVV9aJYc4b27B ypQ7UOTFpNetFWYrJFT4hgIiekd8/z5uowPutDT98H24xVMDstUx5OfQLx/M6Lzh2l 3f4tHWInvpslahDc7XlvZUA7DZ+T3zA+ZCX9JoejFe6bxyee/Y/evG23tU1pKfBxOT fNQ8Jh5Jiiz0w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Arnd Bergmann , Giovanni Cabiddu , Herbert Xu , Sasha Levin Subject: [PATCH 6.8 380/715] crypto: qat - avoid memcpy() overflow warning Date: Sun, 24 Mar 2024 18:29:19 -0400 Message-ID: <20240324223455.1342824-381-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnd Bergmann [ Upstream commit 23a22e831ed4e6aa0831312e8cc8b7c60a657f60 ] The use of array_size() leads gcc to assume the memcpy() can have a larger limit than actually possible, which triggers a string fortification warning: In file included from include/linux/string.h:296, from include/linux/bitmap.h:12, from include/linux/cpumask.h:12, from include/linux/sched.h:16, from include/linux/delay.h:23, from include/linux/iopoll.h:12, from drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.= c:3: In function 'fortify_memcpy_chk', inlined from 'adf_gen4_init_thd2arb_map' at drivers/crypto/intel/qat/qa= t_common/adf_gen4_hw_data.c:401:3: include/linux/fortify-string.h:579:4: error: call to '__write_overflow_fiel= d' declared with attribute warning: detected write beyond size of field (1s= t parameter); maybe use struct_group()? [-Werror=3Dattribute-warning] 579 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ include/linux/fortify-string.h:588:4: error: call to '__read_overflow2_fiel= d' declared with attribute warning: detected read beyond size of field (2nd= parameter); maybe use struct_group()? [-Werror=3Dattribute-warning] 588 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Add an explicit range check to avoid this. Fixes: 5da6a2d5353e ("crypto: qat - generate dynamically arbiter mappings") Signed-off-by: Arnd Bergmann Acked-by: Giovanni Cabiddu Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.c b/drive= rs/crypto/intel/qat/qat_common/adf_gen4_hw_data.c index 9985683056d5f..f752653ccb47e 100644 --- a/drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.c +++ b/drivers/crypto/intel/qat/qat_common/adf_gen4_hw_data.c @@ -398,6 +398,9 @@ int adf_gen4_init_thd2arb_map(struct adf_accel_dev *acc= el_dev) ADF_GEN4_ADMIN_ACCELENGINES; =20 if (srv_id =3D=3D SVC_DCC) { + if (ae_cnt > ICP_QAT_HW_AE_DELIMITER) + return -EINVAL; + memcpy(thd2arb_map, thrd_to_arb_map_dcc, array_size(sizeof(*thd2arb_map), ae_cnt)); return 0; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78F7D18AFD7; Sun, 24 Mar 2024 22:41:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320072; cv=none; b=OVI4866mr9FuXer52iqjOr9EONIIP80A0fAhK0RhyhFwtNTzn2kC/+RAM3nMyA3hBdJOXKXGGhjUXXiMKgTER7N29Q7168iLjguuqTLzFY2H827sePR8JWMJRl/OWUEBhKqVmhDC492GEBL3X4SuibyfApunDDcMesZqUeWt/ow= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320072; c=relaxed/simple; bh=xifQRL+fORxpmntrffE/NQn4dgpIQhHCBsc94lA7hxE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=PPRP7FABPHi/ketZxz5B+EiBjslcPp2+/XGlSHjLXTtkKEebyAJTsdZeIl4Hh7QFWNVioe8a/2LPpbqVAjdbHmJsmY9cIF2lh8zHYiWd6ok5OzrcnrTqGvPaVBzAneqPTJxYFQX0sgXuGS9yCfjqEBFS0z9eOeAFKv9RvXuI7JI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ft8AyGUj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ft8AyGUj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AF1BAC43394; Sun, 24 Mar 2024 22:41:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320072; bh=xifQRL+fORxpmntrffE/NQn4dgpIQhHCBsc94lA7hxE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ft8AyGUjPpXmsOzgIheUhqJtLsr3P3e+sZedTXvMj7PKE6LsTROP3v1EnI4iH3X6F C7Wr14o69aztAZskXcKANpsaUKlVP4mkOD+8TXOP6Nvh1fizzo4dRHtpbHyjW3zdJo GZlDe32/vYEqYTEvj0D0fXOoHL3sUE+rmShNeOJaoFxayqqxAV2rP5w1zOhIjvPWdU xSBXqB636DF+Dwud0jjwAdgFdaNeIY9ZfujwrKlkUdPQCtnP0bF86GHh0Nr0yFqIct BllmGyw8kRfQ1G1vbxpJb7Zv7uS9mNSyA5RUv8eJRCE31zrPZIrlR1ciuNjMkCZE22 4rs3HuoM1nkGQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Stefan Binding , Takashi Iwai , Sasha Levin Subject: [PATCH 6.8 381/715] ALSA: hda: cs35l41: Set Channel Index correctly when system is missing _DSD Date: Sun, 24 Mar 2024 18:29:20 -0400 Message-ID: <20240324223455.1342824-382-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Stefan Binding [ Upstream commit 135096ebfab656823d0037102a00776f3914fee3 ] Current method to set Channel Index when the system is missing _DSD assumes that the channels alternate, which is not guaranteed. Instead use the same methodology as the main driver does when _DSD exists. Fixes: 8c4c216db8fb ("ALSA: hda: cs35l41: Add config table to support many = laptops without _DSD") Signed-off-by: Stefan Binding Link: https://lore.kernel.org/r/20240126164005.367021-2-sbinding@opensource= .cirrus.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- sound/pci/hda/cs35l41_hda_property.c | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/sound/pci/hda/cs35l41_hda_property.c b/sound/pci/hda/cs35l41_h= da_property.c index e436d4dab317f..86ddaff915de1 100644 --- a/sound/pci/hda/cs35l41_hda_property.c +++ b/sound/pci/hda/cs35l41_hda_property.c @@ -210,6 +210,7 @@ static int generic_dsd_config(struct cs35l41_hda *cs35l= 41, struct device *physde struct spi_device *spi; bool dsd_found; int ret; + int i; =20 for (cfg =3D cs35l41_config_table; cfg->ssid; cfg++) { if (!strcasecmp(cfg->ssid, cs35l41->acpi_subsystem_id)) @@ -295,16 +296,6 @@ static int generic_dsd_config(struct cs35l41_hda *cs35= l41, struct device *physde cs35l41->index =3D id =3D=3D 0x40 ? 0 : 1; } =20 - if (cfg->num_amps =3D=3D 3) - /* 3 amps means a center channel, so no duplicate channels */ - cs35l41->channel_index =3D 0; - else - /* - * if 4 amps, there are duplicate channels, so they need different index= es - * if 2 amps, no duplicate channels, channel_index would be 0 - */ - cs35l41->channel_index =3D cs35l41->index / 2; - cs35l41->reset_gpio =3D fwnode_gpiod_get_index(acpi_fwnode_handle(cs35l41= ->dacpi), "reset", cs35l41->index, GPIOD_OUT_LOW, "cs35l41-reset"); @@ -312,6 +303,11 @@ static int generic_dsd_config(struct cs35l41_hda *cs35= l41, struct device *physde =20 hw_cfg->spk_pos =3D cfg->channel[cs35l41->index]; =20 + cs35l41->channel_index =3D 0; + for (i =3D 0; i < cs35l41->index; i++) + if (cfg->channel[i] =3D=3D hw_cfg->spk_pos) + cs35l41->channel_index++; + if (cfg->boost_type =3D=3D INTERNAL) { hw_cfg->bst_type =3D CS35L41_INT_BOOST; hw_cfg->bst_ind =3D cfg->boost_ind_nanohenry; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 17A4167A0D; Sun, 24 Mar 2024 22:41:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320074; cv=none; b=TCMclipQChhY60EoqjNEuq9JztZ4Lt+KcRDygAomUdHMTgNH79V+NShU/b48TCo2eSTbKtxbchqA/zO2ukvbtQz41yqYJ2mO3CFwjs33Zv0jE1+br7Stwhm5AYwM/r28OABmhG02OEctzm4/UWikiqyK3iqWhcsb3YiOS4CXe1I= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320074; c=relaxed/simple; bh=gtdV+/+x84K14c1XoNJ7EP3kgl/E7Qw1TacTh0JRCsA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pGc74D9AO/SQdbmdz8hy1qq2cc3w9sNzzDblEcq9gT6lxglG7h31WFLXCraiJw4C+I/8DoVBvzsTMedH6cVwBO5Bk/lSc8FlEh4CAr5AzsY655C7cJSK1V/NFSmZJaLz5agAa7bqR9Xzal4gcaSU4bXuN7j7QeRq6S6EgTWDlUE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sxmp3J1A; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sxmp3J1A" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 992B0C43390; Sun, 24 Mar 2024 22:41:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320073; bh=gtdV+/+x84K14c1XoNJ7EP3kgl/E7Qw1TacTh0JRCsA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sxmp3J1AJvEzHSfiWimXFH0a9Em4D506vVVQcxrhtLzcU5Rja18KW8ZKFQ2KH3Rjr jnuaR2tnrUa3sNK1ARDTLJaCTQ5szJ2C4n9hNOCgBle1Kwv2ZMeLP++0CU8TnmICWh rQjJj9K8CDBo3tNPVbRIDMxJcSUV05/zOMkpDp6or+ypK4cCrJvioBqAkOjPBhuBxv PS/TQ1QEBdco3AI1Y5eG7nMHzHbMz2kBXKZJ50d+sgxUZtI+sGfSBaEj1ZRLxHpS5Y unMFKmDQ1JuU9rip6QNRosSniCfAX/OVMYA15r+oFrI/C3TgI3SrdJE/3iN2I3BugD z3uqgBzj+AL2A== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Srinivasan Shanmugam , Wyatt Wood , Anthony Koo , Rodrigo Siqueira , Aurabindo Pillai , Alex Deucher , Sasha Levin Subject: [PATCH 6.8 382/715] drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()' Date: Sun, 24 Mar 2024 18:29:21 -0400 Message-ID: <20240324223455.1342824-383-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Srinivasan Shanmugam [ Upstream commit 9ccfe80d022df7c595f1925afb31de2232900656 ] The 'stream' pointer is used in dcn10_set_output_transfer_func() before the check if 'stream' is NULL. Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn1= 0_set_output_transfer_func() warn: variable dereferenced before check 'stre= am' (see line 1875) Fixes: ddef02de0d71 ("drm/amd/display: add null checks before logging") Cc: Wyatt Wood Cc: Anthony Koo Cc: Rodrigo Siqueira Cc: Aurabindo Pillai Signed-off-by: Srinivasan Shanmugam Reviewed-by: Anthony Koo Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c b/driv= ers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c index 6dd479e8a3485..f614bc2806d86 100644 --- a/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c +++ b/drivers/gpu/drm/amd/display/dc/hwss/dcn10/dcn10_hwseq.c @@ -1840,6 +1840,9 @@ bool dcn10_set_output_transfer_func(struct dc *dc, st= ruct pipe_ctx *pipe_ctx, { struct dpp *dpp =3D pipe_ctx->plane_res.dpp; =20 + if (!stream) + return false; + if (dpp =3D=3D NULL) return false; =20 @@ -1862,8 +1865,8 @@ bool dcn10_set_output_transfer_func(struct dc *dc, st= ruct pipe_ctx *pipe_ctx, } else dpp->funcs->dpp_program_regamma_pwl(dpp, NULL, OPP_REGAMMA_BYPASS); =20 - if (stream !=3D NULL && stream->ctx !=3D NULL && - stream->out_transfer_func !=3D NULL) { + if (stream->ctx && + stream->out_transfer_func) { log_tf(stream->ctx, stream->out_transfer_func, dpp->regamma_params.hw_points_num); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 091AC18B5F9; Sun, 24 Mar 2024 22:41:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320075; cv=none; b=P5JOepunnznsPfKH24xoBsuSJHgqXkErI9C7NHOcqI4lITyU/Ew0gjpVFsPgq3l7eNpelCR/4dp/Umoqt+vh6FLj3O1lpGSfhWuUeegR1rZWObIVndKbsc0gzSGQbyBKaM5ZlZUItklDz3CDzpVKtoVsyZqzQ8gxei7d2X3o6xw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320075; c=relaxed/simple; bh=15la2HOP4BZJOz/HljR3aeBvlmkYLsdL1e3Rm1CDSGo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tV5G+XKBjO5M+tse11/WGtVf/mtVot4Lw65cM+wRIsyILWTA+K1fODXWRQ7czcOFAy8FB2Zd03Yo+OSuG9FH6g4QO6B1Y0JUz00b64PWN2g9kfJTuLuDpP8XFLUbUckRidfP9YWMssVly7lUbE2GgwwqqQYzYNlY/EgatKz7iVs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DtARr0iV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DtARr0iV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DDDAFC43394; Sun, 24 Mar 2024 22:41:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320074; bh=15la2HOP4BZJOz/HljR3aeBvlmkYLsdL1e3Rm1CDSGo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DtARr0iVN/PRXk2IkwtzM0z4zN9KaeCYaXP0NzSbJVG4n43uV2NvtmwpXXBQG2hgg 1wB/aFfU+h68dc9cAcP0sHu0AJk2LefXOQbSVUieL9TFDbYtpKTWGDWjakz2QtJ0tU rEViXvk7vkUqop9wMiw5hs1YPe+/ozFPhaqZqip3wM4UHVxWON39MvAsdfwTdgyA85 nhtpi8PghTqpLVQj8CmgNE6rvWSmckekGfkjIqa/Tqhkc/el5wlh0cZuk8p/cJ6a54 aO7pT+7JUN+3eq9yjndJL/0qvw63d0gCu9ZyyffFuaClm3IFJmeCUXjTK5xNdxR++O XkxH0qqqBLIJw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Lad Prabhakar , Geert Uytterhoeven , Mark Brown , Sasha Levin Subject: [PATCH 6.8 383/715] ASoC: sh: rz-ssi: Fix error message print Date: Sun, 24 Mar 2024 18:29:22 -0400 Message-ID: <20240324223455.1342824-384-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Lad Prabhakar [ Upstream commit 9a6d7c4fb2801b675a9c31a7ceb78c84b8c439bc ] The devm_request_irq() call is done for "dma_rt" interrupt but the error message printed "dma_tx" interrupt on failure, fix this by updating dma_tx -> dma_rt in dev_err_probe() message. While at it aligned the code. Signed-off-by: Lad Prabhakar Fixes: 38c042b59af0248a ("ASoC: sh: rz-ssi: Update interrupt handling for h= alf duplex channels") Reviewed-by: Geert Uytterhoeven Link: https://msgid.link/r/20240130150822.327434-1-prabhakar.mahadev-lad.rj= @bp.renesas.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- sound/soc/sh/rz-ssi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sh/rz-ssi.c b/sound/soc/sh/rz-ssi.c index 14cf1a41fb0d1..9d103646973ad 100644 --- a/sound/soc/sh/rz-ssi.c +++ b/sound/soc/sh/rz-ssi.c @@ -1015,7 +1015,7 @@ static int rz_ssi_probe(struct platform_device *pdev) dev_name(&pdev->dev), ssi); if (ret < 0) return dev_err_probe(&pdev->dev, ret, - "irq request error (dma_tx)\n"); + "irq request error (dma_rt)\n"); } else { if (ssi->irq_tx < 0) return ssi->irq_tx; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BFAF518B60D; Sun, 24 Mar 2024 22:41:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320075; cv=none; b=s/vksEF4IrRC20nsoq5FO4uSsr7MnYywDLuhMRqZQliauN1MoGGL/fCGwL6ECBOIS/BZos2fr2hXysK8LEycOXT6/axt87ygyA1svBrrC2XT5RYMDm64vk6oxotmwOBKSWgz62UUjKqrLzna5okS7u9b4gRegK26R48hZZneh/g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320075; c=relaxed/simple; bh=NOpg9zxaUBO0n+k+3suS+QM4rrKWbcPxqtgdxUs4IdQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KycTulsh83tF2cnIIiRVsZHa6u4X9UAMkeIb7JP6DLkqykcsd0TGsMrm1Ubpa5WYzXxB74ka/BPKobJZJwrM6KFPY8seY6RrmLoeAcdOq00pTTnp2pgGQ8o2WR3DUELZLgOdwHadM5ubgLN4oFqmtHcxb9Xr0DYgG3hjMlr619A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eGL/EZOM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eGL/EZOM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E05BFC43399; Sun, 24 Mar 2024 22:41:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320075; bh=NOpg9zxaUBO0n+k+3suS+QM4rrKWbcPxqtgdxUs4IdQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eGL/EZOMODSSjjIM3Ahkts2QVXI7amqaIsJXOiDG+d5syMK/bI+NO6BscrL/CFWup IG9IbO8ioTLflxo9qgoDDZ3jU1/M1Zcx2NTOwyjmRQ3hxXxw+Me6HsiEC78uwjqEKK uCBqrMuiAraEDYDNY1eygG6CEfc767MapK7eebfMheiCnG4gVtwSRxAus9CTc74IEk JmWvz9UmRyVJZe1Hha2osY8UcLGTOhtvO6fVZ9yMhxauRB67q6h0LeNLPbzcpItSij 1dVnsN0h+MT8ECW0IrrOOZGtH5rRrNKAd2jUF6mzXAmJ3HvzlgrQTg3jfe7hFynkae pRX49JcgDzccQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Martin Krastev , Maaz Mombasawala , Zack Rusin , Sasha Levin Subject: [PATCH 6.8 384/715] drm/vmwgfx: Fix vmw_du_get_cursor_mob fencing of newly-created MOBs Date: Sun, 24 Mar 2024 18:29:23 -0400 Message-ID: <20240324223455.1342824-385-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Martin Krastev [ Upstream commit ed96cf7ad590989b009d6da5cd26387d995dac13 ] The fencing of MOB creation used in vmw_du_get_cursor_mob was incompatible with register-based device communication employed by this routine. As a result cursor MOB creation was racy, leading to potentially broken/missing mouse cursor on desktops using CursorMob device feature. Fixes: 53bc3f6fb6b3 ("drm/vmwgfx: Clean up cursor mobs") Signed-off-by: Martin Krastev Reviewed-by: Maaz Mombasawala Reviewed-by: Zack Rusin Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20240126200804.732454-5= -zack.rusin@broadcom.com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/v= mwgfx_kms.c index 5fd0ccaa0b41b..b6f40781b907a 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -272,6 +272,7 @@ static int vmw_du_get_cursor_mob(struct vmw_cursor_plan= e *vcp, u32 size =3D vmw_du_cursor_mob_size(vps->base.crtc_w, vps->base.crtc_h); u32 i; u32 cursor_max_dim, mob_max_size; + struct vmw_fence_obj *fence =3D NULL; int ret; =20 if (!dev_priv->has_mob || @@ -313,7 +314,15 @@ static int vmw_du_get_cursor_mob(struct vmw_cursor_pla= ne *vcp, if (ret !=3D 0) goto teardown; =20 - vmw_bo_fence_single(&vps->cursor.bo->tbo, NULL); + ret =3D vmw_execbuf_fence_commands(NULL, dev_priv, &fence, NULL); + if (ret !=3D 0) { + ttm_bo_unreserve(&vps->cursor.bo->tbo); + goto teardown; + } + + dma_fence_wait(&fence->base, false); + dma_fence_put(&fence->base); + ttm_bo_unreserve(&vps->cursor.bo->tbo); return 0; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E688C18BC24; Sun, 24 Mar 2024 22:41:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320077; cv=none; b=M+/uHI6KV8eHMXxAimHv/T8FRI2jzoIALXoMiHa0kasoKCnEdtrB2qw+zmdaWWVrfEbh3VQSxp2byZs2qFlzIVMWmpPikca/NyVX1GWD55kwk3fq0s32pY6PmBz0ef1xgBCwp9+UAg+j1k1EmRkSEZKY33WzmZnwF1bFJbNd6aM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320077; c=relaxed/simple; bh=HKqxGiSuxgudu271ZME27j9gpBonBPZKW4BhhujDv/k=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Sv9HmeBNffXJ3B03tckJjkrpH/U+8ltQKLhfpGxnGGa+YI8gOVVvDZBl3h86wkOJWywrulKjaLVQ/4Dl+URaHVsgH7RpLUHzo4gY4PELL38saZ+XlHohox4MagNOPE7ifYqk8/qfwhhjoWEHnHdCp3nexiCPidR0CHzy4qFm0bM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WuNGdmG7; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="WuNGdmG7" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E5CB3C433C7; Sun, 24 Mar 2024 22:41:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320076; bh=HKqxGiSuxgudu271ZME27j9gpBonBPZKW4BhhujDv/k=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=WuNGdmG7bzzJxtznpriYn//kuhE0pCj7HX6e89S1+wl6EiC+lKM5pSAK2onkaLlIH NRVW3eOyS0oPo33EppxFR7wA94mNclfHVXW/dAVptkXTJmgBYbnmtBWe4k0iSL8tIE ENMKaV9izvNaDSpDrMywC0v4rmzULqJJR7A0jKKv8iGVmFS6Xkz6MeIuUxofSRMTzC +VJxXSpc9B7dwQ29cIxi0P71AIUUxhdiLX3qs+xvXA/56F0UoR210MmZUE3OT4Eg8q U/lbrE+PjbGZ9ZBAoaaVzDG0zQYAgcHSO8/r/AW6Im7pCPKwPbsoWVN+qwISfNuMMn E68mcrxOA0v2w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Geert Uytterhoeven , Wolfram Sang , Sasha Levin Subject: [PATCH 6.8 385/715] clk: renesas: r8a779g0: Fix PCIe clock name Date: Sun, 24 Mar 2024 18:29:24 -0400 Message-ID: <20240324223455.1342824-386-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Geert Uytterhoeven [ Upstream commit 096311157d2a6bb8f06e28e1143e2a5de6a0183b ] Fix a typo in the name of the module clock for the second PCIe channel. Fixes: 5ab16198b431ca48 ("clk: renesas: r8a779g0: Add PCIe clocks") Signed-off-by: Geert Uytterhoeven Reviewed-by: Wolfram Sang Link: https://lore.kernel.org/r/f582067564f357e2183d3db67b217084ecb51888.17= 06608032.git.geert+renesas@glider.be Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/clk/renesas/r8a779g0-cpg-mssr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/renesas/r8a779g0-cpg-mssr.c b/drivers/clk/renesas/= r8a779g0-cpg-mssr.c index 5974adcef3eda..31b13c997a057 100644 --- a/drivers/clk/renesas/r8a779g0-cpg-mssr.c +++ b/drivers/clk/renesas/r8a779g0-cpg-mssr.c @@ -193,7 +193,7 @@ static const struct mssr_mod_clk r8a779g0_mod_clks[] __= initconst =3D { DEF_MOD("msi4", 622, R8A779G0_CLK_MSO), DEF_MOD("msi5", 623, R8A779G0_CLK_MSO), DEF_MOD("pciec0", 624, R8A779G0_CLK_S0D2_HSC), - DEF_MOD("pscie1", 625, R8A779G0_CLK_S0D2_HSC), + DEF_MOD("pciec1", 625, R8A779G0_CLK_S0D2_HSC), DEF_MOD("pwm", 628, R8A779G0_CLK_SASYNCPERD4), DEF_MOD("rpc-if", 629, R8A779G0_CLK_RPCD2), DEF_MOD("scif0", 702, R8A779G0_CLK_SASYNCPERD4), --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B0C1118BC40; Sun, 24 Mar 2024 22:41:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320077; cv=none; b=S7/nTFprW3Ed8dEF4LueRa5UDSrqR/XAgFPz5PlgfuJa0iFgKpkhHQeQ0DF1H5D7q9vvCOeg9pl4VAuAr2yqyloFozdLijVe0G1Xx1Plx5dwMAVO/wSiQMI1WwWmjVTfdJFwoS0iLHUE4XZQVRPhSPdGxg7U4fLlBAtOeKPCzRo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320077; c=relaxed/simple; bh=0V0modpgI+8Pr8qgQ7JsqrWWI9vJdi3MzunN4UFnEr4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=XSYkZYWdOVejs/M22+Ovg1tnnYlpH0k2Qe4XcTTUxa4gOrdgUGlY1+foW6YS3Vgs5cOwfGKxOtjwJxDTrKeYFkrcuycQgaZPpN9XYddRuvsV+eF20L9X+/ka+X29e2/C2SKTY9FPOcOgeB+mbCTHgdBouG3z0/kJdAFCVYH8Fm4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Pkc3nfX5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Pkc3nfX5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDE0AC43399; Sun, 24 Mar 2024 22:41:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320077; bh=0V0modpgI+8Pr8qgQ7JsqrWWI9vJdi3MzunN4UFnEr4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Pkc3nfX52eVBzXCdWptRSa2KHw2DBZCG6gd5cZmiEYgEpXnmuNMsXfiIxk5Y/msX6 p5j/lndEaLjPASIZVC7j9iVSVYOPu4/DENabqbrR3zsaq7yKzwagKejJ43SiQgeVb1 tEzIUi2yPF7S94r8fx3Fm8zCF1zxsFP6jiX7/FarOoBaD3PQDePCicrNxl4G0TVDL0 mxB3FauVNSD5vqBDIDTzCVRIJ5unFSnQvnmsIaXG0dpEZZX67so4t9/K42gu4jSlwM N/84h/SxB8tAz4ETOakvx/5DrkbLTUUkzxzcAvQzAXaWQsjBUtjz1/OkmIAAKTK/Ob O0XFVeIAHIDUQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Claudiu Beznea , Dan Carpenter , Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.8 386/715] pinctrl: renesas: rzg2l: Fix locking in rzg2l_dt_subnode_to_map() Date: Sun, 24 Mar 2024 18:29:25 -0400 Message-ID: <20240324223455.1342824-387-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Claudiu Beznea [ Upstream commit bd433c25ca81b2ac6dca7ea288a8474eea4fb8a0 ] Commit d3aaa7203a17 ("pinctrl: renesas: rzg2l: Add pin configuration support for pinmux groups") introduced the possibility to parse pin configuration for pinmux groups. It did that by calling rzg2l_map_add_config() at the end of rzg2l_dt_subnode_to_map() and jumping to the remove_group label in case rzg2l_map_add_config() failed. But if that happens, the mutex will already be unlocked, thus this it will lead to double mutex unlock operation. To fix this move the rzg2l_map_add_config() call just after all the name argument is ready and before the mutex is locked. There is no harm in doing this, as this only parses the data from device tree that will be further processed by pinctrl core code. Fixes: d3aaa7203a17 ("pinctrl: renesas: rzg2l: Add pin configuration suppor= t for pinmux groups") Reported-by: Dan Carpenter Closes: https://lore.kernel.org/all/f8c3a3a0-7c48-4e40-8af0-ed4e9d9b049f@mo= roto.mountain Signed-off-by: Claudiu Beznea Reviewed-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20240115153453.99226-1-claudiu.beznea.uj@bp= .renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/pinctrl/renesas/pinctrl-rzg2l.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/pinctrl/renesas/pinctrl-rzg2l.c b/drivers/pinctrl/rene= sas/pinctrl-rzg2l.c index 80fb5011c7bbc..01ef6921cb35c 100644 --- a/drivers/pinctrl/renesas/pinctrl-rzg2l.c +++ b/drivers/pinctrl/renesas/pinctrl-rzg2l.c @@ -447,6 +447,16 @@ static int rzg2l_dt_subnode_to_map(struct pinctrl_dev = *pctldev, name =3D np->name; } =20 + if (num_configs) { + ret =3D rzg2l_map_add_config(&maps[idx], name, + PIN_MAP_TYPE_CONFIGS_GROUP, + configs, num_configs); + if (ret < 0) + goto done; + + idx++; + } + mutex_lock(&pctrl->mutex); =20 /* Register a single pin group listing all the pins we read from DT */ @@ -474,16 +484,6 @@ static int rzg2l_dt_subnode_to_map(struct pinctrl_dev = *pctldev, maps[idx].data.mux.function =3D name; idx++; =20 - if (num_configs) { - ret =3D rzg2l_map_add_config(&maps[idx], name, - PIN_MAP_TYPE_CONFIGS_GROUP, - configs, num_configs); - if (ret < 0) - goto remove_group; - - idx++; - } - dev_dbg(pctrl->dev, "Parsed %pOF with %d pins\n", np, num_pinmux); ret =3D 0; goto done; --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7D00618BC5B; Sun, 24 Mar 2024 22:41:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320078; cv=none; b=uZbvsap59C6NGg2ubmUMCpjP7nBRPVQv1bHRGGlD73WBqpyj+wV65owDe84UHjW8MXZXB8fQ/JfEdEkvyW4vhAvwNjWYyYeuRppC/MPe1FFhWwubw+XiFLGewPqkP/5hvktAXUM9QzCOMdMhhMqXkNTUihzeWBDaviCiBd1XhrM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320078; c=relaxed/simple; bh=C2Ua5kReEzwTd2V431PjK4bLeRHqCCInHnmeMP3BwsE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BRmWjJQxx8YqsPUzhdhgwpt0v3FeyCrgkCYM8s5iyOTARriBNntDnlxWBabZvw3jOYSN0NEFM84XP6YTP2xyyaHG/teBrng1B6K3LC7OZmt9i5nGN7dslsQU86swL1pFeCPL1xdtQAYQqeCSxivCxaFk4PU6tCFrtE0BpmIzV5I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UOAzCin5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UOAzCin5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CF7B3C433F1; Sun, 24 Mar 2024 22:41:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320078; bh=C2Ua5kReEzwTd2V431PjK4bLeRHqCCInHnmeMP3BwsE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=UOAzCin5tos891UH4qheZ4keI9abxFHk19c9E3ul88RlOGnzOFmNnZxPpbh6+wbX3 axTymIR/22NORUR1drsFdyP95gYPsEqCBr9qSYqXUnuzbNFRbG11AUddILjfBkQDks sdZs9rgTRlTh6LSsxjXLS3vlF96ST5g5g2dolnq9mjTFHAFIgz+GYwT2PLDjQRnCry k9pO0edT4HxxynCfTDk6oH+JV7Irxh2H+FyXoTlIKXeCa1tzR3bJA043oj4236/I3B u1wcBfyvzpS01JYDJKK8DykwZBfhawy1eqyAWMNbjzVyT0MzZRHxBiST0SxvuWvVJ7 1CMqjVtS5nxdQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Geert Uytterhoeven , Sasha Levin Subject: [PATCH 6.8 387/715] pinctrl: renesas: r8a779g0: Add missing SCIF_CLK2 pin group/function Date: Sun, 24 Mar 2024 18:29:26 -0400 Message-ID: <20240324223455.1342824-388-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Geert Uytterhoeven [ Upstream commit 68540257cdf1d07ff8a649aa94c21c5804bbb9b0 ] R-Car V4H actually has two SCIF_CLK pins. The second pin provides the SCIF_CLK signal for HSCIF2 and SCIF4. Fixes: 050442ae4c74f830 ("pinctrl: renesas: r8a779g0: Add pins, groups and = functions") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/6352ec9b63fdd38c2c70d8d203e46f21fbfeccdc.17= 05589612.git.geert+renesas@glider.be Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/pinctrl/renesas/pfc-r8a779g0.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/drivers/pinctrl/renesas/pfc-r8a779g0.c b/drivers/pinctrl/renes= as/pfc-r8a779g0.c index acdea6ac15253..d2de526a3b588 100644 --- a/drivers/pinctrl/renesas/pfc-r8a779g0.c +++ b/drivers/pinctrl/renesas/pfc-r8a779g0.c @@ -2384,6 +2384,14 @@ static const unsigned int scif_clk_mux[] =3D { SCIF_CLK_MARK, }; =20 +static const unsigned int scif_clk2_pins[] =3D { + /* SCIF_CLK2 */ + RCAR_GP_PIN(8, 11), +}; +static const unsigned int scif_clk2_mux[] =3D { + SCIF_CLK2_MARK, +}; + /* - SSI ------------------------------------------------- */ static const unsigned int ssi_data_pins[] =3D { /* SSI_SD */ @@ -2694,6 +2702,7 @@ static const struct sh_pfc_pin_group pinmux_groups[] = =3D { SH_PFC_PIN_GROUP(scif4_clk), SH_PFC_PIN_GROUP(scif4_ctrl), SH_PFC_PIN_GROUP(scif_clk), + SH_PFC_PIN_GROUP(scif_clk2), =20 SH_PFC_PIN_GROUP(ssi_data), SH_PFC_PIN_GROUP(ssi_ctrl), @@ -3015,6 +3024,10 @@ static const char * const scif_clk_groups[] =3D { "scif_clk", }; =20 +static const char * const scif_clk2_groups[] =3D { + "scif_clk2", +}; + static const char * const ssi_groups[] =3D { "ssi_data", "ssi_ctrl", @@ -3102,6 +3115,7 @@ static const struct sh_pfc_function pinmux_functions[= ] =3D { SH_PFC_FUNCTION(scif3), SH_PFC_FUNCTION(scif4), SH_PFC_FUNCTION(scif_clk), + SH_PFC_FUNCTION(scif_clk2), =20 SH_PFC_FUNCTION(ssi), =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8275818C235; Sun, 24 Mar 2024 22:41:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320079; cv=none; b=GOxB9J0R8FUxO1lvSPCUZl93Un4lvcPC3vtREgGH2cVOSlOQ/Q/gP5t8qsWfDEU9DBbY6gOOTMYrQeLUD5NNSotf2RQ6y5+a0H9tZly/KnKFq6bcIR7fNXuMys1fqGXfev50LHFjIqam/GoCXqD1GFvvH8AIJy886DBGEkK0Mo4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320079; c=relaxed/simple; bh=k1718tIRVtyBuPuPME4HoGIOwyBFb8V0fUYLmvZcUbM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=q0LRxdDfoctN9FbtgH8IODz0ajGIjkUymqIeGpxX/U1AlFhSgUCbZiSXL8trpOFvsYGQQSvjN48NVTNMgruoRVnD+9K9sdlx3X6mRQJwai1bf24n67fnnF3DI3J9wX1G6lKFFZ28SyQeMQpK64U29OJCLWJlS61WwZJhn044TU0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SvlMYl/1; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SvlMYl/1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A1EB3C43390; Sun, 24 Mar 2024 22:41:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320079; bh=k1718tIRVtyBuPuPME4HoGIOwyBFb8V0fUYLmvZcUbM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SvlMYl/1ZlsdyxaD4QiKF/eBosTjq0VWaBCEVdy0uMTHeDvAoC+JQK8w8UBV2Z/vk MP8/QTZyLB3Sry2e6K0Li35OyeE3BcdWarcZFbfnDhrbuC5Mq4yMrITr1pqTvClzfd nVTEfBg2+5HyhuBT+jY4qJvRhZYfDOTVKOGBlu0R2jnDRIybGr9eG/vhy4FiQCToQE co7yGArRKnpp/+kjURTsHBKBTDIBZ7xS7D8hTQaGSnX5gBc3CBVUdng5vmjyEo/LDd eySTaeac0dnMne+MlaJGf0I3tSa1+X/qhJEBaVv4Kz0XIIo+codfpQsU/hwSgLPocF S3HXkLjGfF53g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Sam Protsenko , Tudor Ambarus , Krzysztof Kozlowski , Sasha Levin Subject: [PATCH 6.8 388/715] clk: samsung: exynos850: Propagate SPI IPCLK rate change Date: Sun, 24 Mar 2024 18:29:27 -0400 Message-ID: <20240324223455.1342824-389-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Sam Protsenko [ Upstream commit 67c15187d4910ee353374676d4dddf09d8cb227e ] When SPI transfer is being prepared, the spi-s3c64xx driver will call clk_set_rate() to change the rate of SPI source clock (IPCLK). But IPCLK is a gate (leaf) clock, so it must propagate the rate change up the clock tree, so that corresponding DIV clocks can actually change their divider values. Add CLK_SET_RATE_PARENT flag to corresponding clocks for all SPI instances in Exynos850 (spi_0, spi_1 and spi_2) to make it possible. This change involves next clocks: usi_spi_0: Clock Block Div range -------------------------------------------- gout_spi0_ipclk CMU_PERI - dout_peri_spi0 CMU_PERI /1..32 mout_peri_spi_user CMU_PERI - dout_peri_ip CMU_TOP /1..16 usi_cmgp0: Clock Block Div range -------------------------------------------- gout_cmgp_usi0_ipclk CMU_CMGP - dout_cmgp_usi0 CMU_CMGP /1..32 mout_cmgp_usi0 CMU_CMGP - gout_clkcmu_cmgp_bus CMU_APM - dout_apm_bus CMU_APM /1..8 usi_cmgp1: Clock Block Div range -------------------------------------------- gout_cmgp_usi1_ipclk CMU_CMGP - dout_cmgp_usi1 CMU_CMGP /1..32 mout_cmgp_usi1 CMU_CMGP - gout_clkcmu_cmgp_bus CMU_APM - dout_apm_bus CMU_APM /1..8 With input clock of 400 MHz, this scheme provides next IPCLK rate range, for each SPI block: SPI0: 781 kHz ... 400 MHz SPI1/2: 1.6 MHz ... 400 MHz Accounting for internal /4 divider in SPI blocks, and because the max SPI frequency is limited at 50 MHz, it gives us next SPI SCK rates: SPI0: 200 kHz ... 49.9 MHz SPI1/2: 400 kHz ... 49.9 MHz Which should cover all possible applications of SPI bus. Of course, setting SPI frequency to values as low as 500 kHz will also affect the common bus dividers (dout_apm_bus or dout_peri_ip), which in turn effectively lowers the rates for all leaf bus clocks derived from those dividers, like HSI2C and I3C clocks. But at least it gives the board designer a choice, whether to keep all clocks (SPI/HSI2C/I3C) at high frequencies, or make all those clocks have lower frequencies. Not propagating the rate change to those common dividers would limit this choice to "only high frequencies are allowed for SPI/HSI2C/I3C" option, making the common dividers useless. This decision follows the "Worse is better" approach, relying on the users/engineers to know the system internals when working with such low-level features, instead of trying to account for all possible use-cases. Fixes: 7dd05578198b ("clk: samsung: Introduce Exynos850 clock driver") Signed-off-by: Sam Protsenko Reviewed-by: Tudor Ambarus Link: https://lore.kernel.org/r/20240125013858.3986-2-semen.protsenko@linar= o.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/clk/samsung/clk-exynos850.c | 33 +++++++++++++++-------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/drivers/clk/samsung/clk-exynos850.c b/drivers/clk/samsung/clk-= exynos850.c index bdc1eef7d6e54..c7b0b9751307b 100644 --- a/drivers/clk/samsung/clk-exynos850.c +++ b/drivers/clk/samsung/clk-exynos850.c @@ -605,7 +605,7 @@ static const struct samsung_div_clock apm_div_clks[] __= initconst =3D { =20 static const struct samsung_gate_clock apm_gate_clks[] __initconst =3D { GATE(CLK_GOUT_CLKCMU_CMGP_BUS, "gout_clkcmu_cmgp_bus", "dout_apm_bus", - CLK_CON_GAT_CLKCMU_CMGP_BUS, 21, 0, 0), + CLK_CON_GAT_CLKCMU_CMGP_BUS, 21, CLK_SET_RATE_PARENT, 0), GATE(CLK_GOUT_CLKCMU_CHUB_BUS, "gout_clkcmu_chub_bus", "mout_clkcmu_chub_bus", CLK_CON_GAT_GATE_CLKCMU_CHUB_BUS, 21, 0, 0), @@ -974,19 +974,19 @@ static const struct samsung_fixed_rate_clock cmgp_fix= ed_clks[] __initconst =3D { static const struct samsung_mux_clock cmgp_mux_clks[] __initconst =3D { MUX(CLK_MOUT_CMGP_ADC, "mout_cmgp_adc", mout_cmgp_adc_p, CLK_CON_MUX_CLK_CMGP_ADC, 0, 1), - MUX(CLK_MOUT_CMGP_USI0, "mout_cmgp_usi0", mout_cmgp_usi0_p, - CLK_CON_MUX_MUX_CLK_CMGP_USI_CMGP0, 0, 1), - MUX(CLK_MOUT_CMGP_USI1, "mout_cmgp_usi1", mout_cmgp_usi1_p, - CLK_CON_MUX_MUX_CLK_CMGP_USI_CMGP1, 0, 1), + MUX_F(CLK_MOUT_CMGP_USI0, "mout_cmgp_usi0", mout_cmgp_usi0_p, + CLK_CON_MUX_MUX_CLK_CMGP_USI_CMGP0, 0, 1, CLK_SET_RATE_PARENT, 0), + MUX_F(CLK_MOUT_CMGP_USI1, "mout_cmgp_usi1", mout_cmgp_usi1_p, + CLK_CON_MUX_MUX_CLK_CMGP_USI_CMGP1, 0, 1, CLK_SET_RATE_PARENT, 0), }; =20 static const struct samsung_div_clock cmgp_div_clks[] __initconst =3D { DIV(CLK_DOUT_CMGP_ADC, "dout_cmgp_adc", "gout_clkcmu_cmgp_bus", CLK_CON_DIV_DIV_CLK_CMGP_ADC, 0, 4), - DIV(CLK_DOUT_CMGP_USI0, "dout_cmgp_usi0", "mout_cmgp_usi0", - CLK_CON_DIV_DIV_CLK_CMGP_USI_CMGP0, 0, 5), - DIV(CLK_DOUT_CMGP_USI1, "dout_cmgp_usi1", "mout_cmgp_usi1", - CLK_CON_DIV_DIV_CLK_CMGP_USI_CMGP1, 0, 5), + DIV_F(CLK_DOUT_CMGP_USI0, "dout_cmgp_usi0", "mout_cmgp_usi0", + CLK_CON_DIV_DIV_CLK_CMGP_USI_CMGP0, 0, 5, CLK_SET_RATE_PARENT, 0), + DIV_F(CLK_DOUT_CMGP_USI1, "dout_cmgp_usi1", "mout_cmgp_usi1", + CLK_CON_DIV_DIV_CLK_CMGP_USI_CMGP1, 0, 5, CLK_SET_RATE_PARENT, 0), }; =20 static const struct samsung_gate_clock cmgp_gate_clks[] __initconst =3D { @@ -1001,12 +1001,12 @@ static const struct samsung_gate_clock cmgp_gate_cl= ks[] __initconst =3D { "gout_clkcmu_cmgp_bus", CLK_CON_GAT_GOUT_CMGP_GPIO_PCLK, 21, CLK_IGNORE_UNUSED, 0), GATE(CLK_GOUT_CMGP_USI0_IPCLK, "gout_cmgp_usi0_ipclk", "dout_cmgp_usi0", - CLK_CON_GAT_GOUT_CMGP_USI_CMGP0_IPCLK, 21, 0, 0), + CLK_CON_GAT_GOUT_CMGP_USI_CMGP0_IPCLK, 21, CLK_SET_RATE_PARENT, 0), GATE(CLK_GOUT_CMGP_USI0_PCLK, "gout_cmgp_usi0_pclk", "gout_clkcmu_cmgp_bus", CLK_CON_GAT_GOUT_CMGP_USI_CMGP0_PCLK, 21, 0, 0), GATE(CLK_GOUT_CMGP_USI1_IPCLK, "gout_cmgp_usi1_ipclk", "dout_cmgp_usi1", - CLK_CON_GAT_GOUT_CMGP_USI_CMGP1_IPCLK, 21, 0, 0), + CLK_CON_GAT_GOUT_CMGP_USI_CMGP1_IPCLK, 21, CLK_SET_RATE_PARENT, 0), GATE(CLK_GOUT_CMGP_USI1_PCLK, "gout_cmgp_usi1_pclk", "gout_clkcmu_cmgp_bus", CLK_CON_GAT_GOUT_CMGP_USI_CMGP1_PCLK, 21, 0, 0), @@ -1557,8 +1557,9 @@ static const struct samsung_mux_clock peri_mux_clks[]= __initconst =3D { mout_peri_uart_user_p, PLL_CON0_MUX_CLKCMU_PERI_UART_USER, 4, 1), MUX(CLK_MOUT_PERI_HSI2C_USER, "mout_peri_hsi2c_user", mout_peri_hsi2c_user_p, PLL_CON0_MUX_CLKCMU_PERI_HSI2C_USER, 4, 1), - MUX(CLK_MOUT_PERI_SPI_USER, "mout_peri_spi_user", mout_peri_spi_user_p, - PLL_CON0_MUX_CLKCMU_PERI_SPI_USER, 4, 1), + MUX_F(CLK_MOUT_PERI_SPI_USER, "mout_peri_spi_user", + mout_peri_spi_user_p, PLL_CON0_MUX_CLKCMU_PERI_SPI_USER, 4, 1, + CLK_SET_RATE_PARENT, 0), }; =20 static const struct samsung_div_clock peri_div_clks[] __initconst =3D { @@ -1568,8 +1569,8 @@ static const struct samsung_div_clock peri_div_clks[]= __initconst =3D { CLK_CON_DIV_DIV_CLK_PERI_HSI2C_1, 0, 5), DIV(CLK_DOUT_PERI_HSI2C2, "dout_peri_hsi2c2", "gout_peri_hsi2c2", CLK_CON_DIV_DIV_CLK_PERI_HSI2C_2, 0, 5), - DIV(CLK_DOUT_PERI_SPI0, "dout_peri_spi0", "mout_peri_spi_user", - CLK_CON_DIV_DIV_CLK_PERI_SPI_0, 0, 5), + DIV_F(CLK_DOUT_PERI_SPI0, "dout_peri_spi0", "mout_peri_spi_user", + CLK_CON_DIV_DIV_CLK_PERI_SPI_0, 0, 5, CLK_SET_RATE_PARENT, 0), }; =20 static const struct samsung_gate_clock peri_gate_clks[] __initconst =3D { @@ -1611,7 +1612,7 @@ static const struct samsung_gate_clock peri_gate_clks= [] __initconst =3D { "mout_peri_bus_user", CLK_CON_GAT_GOUT_PERI_PWM_MOTOR_PCLK, 21, 0, 0), GATE(CLK_GOUT_SPI0_IPCLK, "gout_spi0_ipclk", "dout_peri_spi0", - CLK_CON_GAT_GOUT_PERI_SPI_0_IPCLK, 21, 0, 0), + CLK_CON_GAT_GOUT_PERI_SPI_0_IPCLK, 21, CLK_SET_RATE_PARENT, 0), GATE(CLK_GOUT_SPI0_PCLK, "gout_spi0_pclk", "mout_peri_bus_user", CLK_CON_GAT_GOUT_PERI_SPI_0_PCLK, 21, 0, 0), GATE(CLK_GOUT_SYSREG_PERI_PCLK, "gout_sysreg_peri_pclk", --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DDD6C18C220; Sun, 24 Mar 2024 22:41:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320081; cv=none; b=hdPXrg5mJF1U33V9IFunQQLnmliMXDrADmuCamKQUf7KEJwn6ua4U/mXxL/5vrlm21LuRbATRLXlA+KMhjXCefEM4dbuwWBc/5x7nUiEwwQtuk9fv2Vgadwt3ynTJZn+ZXkVt03e/sHAoqlhxSI6fCdrEgkExnW1VLuEdq2O9DA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320081; c=relaxed/simple; bh=i6qbJ0YigLE3yuZNNmqK6Rf7CvUlWxagcLz5SoaV904=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hkRgilwQ/co63ps1pWTbQv+DQKLQIjhEyMNm4j1OXoQcSFKQM9v2b9WX3Rh568FuCchhWU16h2mZFuyieALOSl07dZXpiM4d+WaCwQ90RcJ4EGJAOtSd2QFXlpmb95KwPAMJW4xaJsz30u1/tb6Znroe+W57EO7A8JMyqAbYNAk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CJBZyrsi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CJBZyrsi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9E08EC43399; Sun, 24 Mar 2024 22:41:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320080; bh=i6qbJ0YigLE3yuZNNmqK6Rf7CvUlWxagcLz5SoaV904=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CJBZyrsigbHvBUEUNRc7cGemNZ98NP6fy5O5R/LlUATIXv3YNTVe4VzsWzLnem5rP t3g+dJ/VJRiGH8owtz1wy+g+xtaX1V3BQETq52ZJRqcUkAy/XbgWP8CelPXFcTRqcA bUTEwMBbqcPwJuKt5ui/9eBaz54DM1Fwys7HITiW71JeO/0ffHmZuBGJOqW23nxRWa 2Npi+8CvELsLCVgXEfBthDaOHidDjROOoBBX9Jd0AIARUNFtf7qepNfI8fqjlClUms F4NYVsKpvGOWwbz5lJbjgnAKcFhTM1t1P0Q0+0tIbRcTbKlWxSybSoxbbLwiYrPdEG WsHdy++AdaL+w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Julien Massot , Hans de Goede , Sakari Ailus , Mauro Carvalho Chehab , Sasha Levin Subject: [PATCH 6.8 389/715] media: v4l2: cci: print leading 0 on error Date: Sun, 24 Mar 2024 18:29:28 -0400 Message-ID: <20240324223455.1342824-390-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Julien Massot [ Upstream commit 58ab1f9e140006e9e5686640f1773260038fe889 ] In some error cases leading '0' for register address were missing. Fixes: 613cbb91e9ce ("media: Add MIPI CCI register access helper functions") Signed-off-by: Julien Massot Reviewed-by: Hans de Goede Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/media/v4l2-core/v4l2-cci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-cci.c b/drivers/media/v4l2-core/v= 4l2-cci.c index 10005c80f43b5..ee3475bed37fa 100644 --- a/drivers/media/v4l2-core/v4l2-cci.c +++ b/drivers/media/v4l2-core/v4l2-cci.c @@ -32,7 +32,7 @@ int cci_read(struct regmap *map, u32 reg, u64 *val, int *= err) =20 ret =3D regmap_bulk_read(map, reg, buf, len); if (ret) { - dev_err(regmap_get_device(map), "Error reading reg 0x%4x: %d\n", + dev_err(regmap_get_device(map), "Error reading reg 0x%04x: %d\n", reg, ret); goto out; } @@ -131,7 +131,7 @@ int cci_write(struct regmap *map, u32 reg, u64 val, int= *err) =20 ret =3D regmap_bulk_write(map, reg, buf, len); if (ret) - dev_err(regmap_get_device(map), "Error writing reg 0x%4x: %d\n", + dev_err(regmap_get_device(map), "Error writing reg 0x%04x: %d\n", reg, ret); =20 out: --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A7A1C18C9CA; Sun, 24 Mar 2024 22:41:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320081; cv=none; b=ViIz8Xg5ArxbTF3NAJHBUABYGNPedELGHYULlH8DKnUg8M7z4tpQGS2q8zt1r0S5JiFgmI3x/4wiBj6l0VMff9ZVuL9M/aHBl6tWC1NNqH/7/4ZKEYaeIkeLieGc6y6kBL4sSNLaVfhL4fmtrq+XDpQKq+HFIrxlAxDTFe6dqPQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320081; c=relaxed/simple; bh=PoyZnFczcwt9O6M6VXmc7lHJigt0cR0l+Qp9md3dErc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=kqNGUmn78g4I2cg80unTIqHv7LJJOJk1g82q/YpDd88cxPLa0z4eGGBub7k54Me3jnGCw+9Hdw79pDgOKef52Q7Z4A6f8BJQtiGDeltQaDCg+AJQQBqzfoG1X64X5o6j6J0AqI++H3XwN/XhNupNXEjIGwgaUvsQhCVuU6k5Ax8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OOUY25by; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="OOUY25by" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B56BCC43390; Sun, 24 Mar 2024 22:41:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320081; bh=PoyZnFczcwt9O6M6VXmc7lHJigt0cR0l+Qp9md3dErc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OOUY25by674rOdH3uLeGdijZkulZd09uNyGF+ARvsKI+3Kc9AxQhKuJ6JJHrHNI58 GoxnItkG7r6Z7hjyZK67eQFUgzsurV76V3SqNMU/qgLLkB0sTeOpGEl1v2jD7nyEVM mR1wZo9cYsAQpEdkAyWhWtIpdpe03sYmUYO5109hlyEhbWDahCL9VcHnnAS2EerLM1 tnEbMRMcSW9DjDYo8/jnqCf6Bq7VFmrXfsZ4aiOfncw2T9t8aDbtiBmClEurl0Jq2T YXWZZA26Q4klQ0mMXmX7YVN+uEfawksUfaQjqgE5/K+OZZFhQ+tfOnxM+arUWU+dCp 9+UUljAIx/zJQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Yang Jihong , Arnaldo Carvalho de Melo , Ian Rogers , Namhyung Kim , Sasha Levin Subject: [PATCH 6.8 390/715] perf evsel: Fix duplicate initialization of data->id in evsel__parse_sample() Date: Sun, 24 Mar 2024 18:29:29 -0400 Message-ID: <20240324223455.1342824-391-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Yang Jihong [ Upstream commit 4962aec0d684c8edb14574ccd0da53e4926ff834 ] data->id has been initialized at line 2362, remove duplicate initialization. Fixes: 3ad31d8a0df2 ("perf evsel: Centralize perf_sample initialization") Signed-off-by: Yang Jihong Reviewed-by: Arnaldo Carvalho de Melo Reviewed-by: Ian Rogers Signed-off-by: Namhyung Kim Link: https://lore.kernel.org/r/20240127025756.4041808-1-yangjihong1@huawei= .com Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/perf/util/evsel.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 6d7c9c58a9bcb..727dae445da9f 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -2363,7 +2363,6 @@ int evsel__parse_sample(struct evsel *evsel, union pe= rf_event *event, data->period =3D evsel->core.attr.sample_period; data->cpumode =3D event->header.misc & PERF_RECORD_MISC_CPUMODE_MASK; data->misc =3D event->header.misc; - data->id =3D -1ULL; data->data_src =3D PERF_MEM_DATA_SRC_NONE; data->vcpu =3D -1; =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 92F1818C9E4; Sun, 24 Mar 2024 22:41:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320082; cv=none; b=ED5Iyw0nCt+s5Ivu9ar9MZuiYxDXwRhP9tjyns/oekYcoa9wn/bJle2P9RoBLC+gkIKJzoHWCk4xjqDW1nNV1kZY4Uu0vFLBNoBN8vg6MK0dSBe/Sn9eRn0zMYrh7hysawQ165u8494BN7b/BU9AEDb6ci1wO7neSMkJlRe75/g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320082; c=relaxed/simple; bh=AblLMCLKhGeVcNTlP4GxhDoq/j9RcxhSil5RYWBtqm4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BxTv3vehDq6cOtelTx437luwBpLnLrWuwzU8UYjq3sthpp6IrFQUEyZ3sSsQ/wAAnqDwuxoFdzoj07KDkmiIDbP6py6O8pAFF4kzFLzEUsTsb9R/eHMl5HpeqTku4V1nID7gZPqs8oatJwIBjXC1a3+1nvP7AbzWDXJVcB8HkYc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SBcil/qZ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SBcil/qZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBF17C433C7; Sun, 24 Mar 2024 22:41:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320082; bh=AblLMCLKhGeVcNTlP4GxhDoq/j9RcxhSil5RYWBtqm4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SBcil/qZUl4NaH5kyr9+u4vDc2sPsjpHaQr5SzVdHfYYW1sXK3kYm47VzXotsEZ59 BpRawgZX2dgax3oJwpSRzWXA5whuEjYAbsiuThuM9mYB3wlb8IMiMWGcYua7eUF2hO ZjyaCpPLH+hOuR2S/a6provqjL2z88QMomCaVGb2C30++IVPy+FYSJBMFNbPcC1kqv 5Z4lJIbWo1jckI6FCVqTBw9nD2FevBdcc8IkfWC7snV9h+2hfetqq8bmz7u8w5fXCJ cRR6WAmib2Qux1anMkSvvQTM2CjmEuS5T8BmS9T/IBuI0DzDioLl3YGML30t3/2Nt/ RfFdBOkquSuRg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Johan Hovold , Bjorn Helgaas , Sasha Levin Subject: [PATCH 6.8 391/715] PCI/AER: Fix rootport attribute paths in ABI docs Date: Sun, 24 Mar 2024 18:29:30 -0400 Message-ID: <20240324223455.1342824-392-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Johan Hovold [ Upstream commit 0e7d29a39a546161ea3a49e8e282a43212d7ff68 ] The 'aer_stats' directory never made it into the sixth and final revision of the series adding the sysfs AER attributes. Link: https://lore.kernel.org/r/20240202131635.11405-2-johan+linaro@kernel.= org Link: https://lore.kernel.org/lkml/20180621184822.GB14136@bhelgaas-glaptop.= roam.corp.google.com/ Fixes: 12833017e581 ("PCI/AER: Add sysfs attributes for rootport cumulative= stats") Signed-off-by: Johan Hovold Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats b/Do= cumentation/ABI/testing/sysfs-bus-pci-devices-aer_stats index 860db53037a58..24087d5fd417a 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats @@ -100,19 +100,19 @@ collectors) that are AER capable. These indicate the = number of error messages as device, so these counters include them and are thus cumulative of all the = error messages on the PCI hierarchy originating at that root port. =20 -What: /sys/bus/pci/devices//aer_stats/aer_rootport_total_err_cor +What: /sys/bus/pci/devices//aer_rootport_total_err_cor Date: July 2018 KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com Description: Total number of ERR_COR messages reported to rootport. =20 -What: /sys/bus/pci/devices//aer_stats/aer_rootport_total_err_fatal +What: /sys/bus/pci/devices//aer_rootport_total_err_fatal Date: July 2018 KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com Description: Total number of ERR_FATAL messages reported to rootport. =20 -What: /sys/bus/pci/devices//aer_stats/aer_rootport_total_err_nonf= atal +What: /sys/bus/pci/devices//aer_rootport_total_err_nonfatal Date: July 2018 KernelVersion: 4.19.0 Contact: linux-pci@vger.kernel.org, rajatja@google.com --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2D37E13CC4F; Sun, 24 Mar 2024 22:41:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320084; cv=none; b=H96ZYyxp9t6vJ2OR3CuVF5z7juqZSJEKJXbbLvPex5m4j8SgAYb+fFnxWbH6in5xWJHYHOHZqsbvdmooaQG61jdWUe6482MsThQcI1sY2jY83vb7xiazZByvwzB/71ESC67A3m7ln0P0nJ/9pzggVOt18b0P9rHRFhI854M91Ss= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320084; c=relaxed/simple; bh=Y1cVgr2blchwClVyVWRsQSGFE/EQmsjAViufLUR7hy8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=W+CNuIGG9PXZGvRl7yhnGv7jdOBCoB+OvVssigRZcnEPRjWBu2HDXu2Ku0zSiKcgw1Az0V3t7zYFViVR+ASDGety+j9cXXZCsYyOF4/+d7SdxTYIRIGVchPN0hIJ9TzyybfFUyjDDZE6ezGkMYy/e46b0iCg8f8gGorEKN1VeQg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IS/FMnyy; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IS/FMnyy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B74CAC433F1; Sun, 24 Mar 2024 22:41:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320084; bh=Y1cVgr2blchwClVyVWRsQSGFE/EQmsjAViufLUR7hy8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IS/FMnyyXqlKTOWx80VMkDHs0umfA8mv+cKZgIRKolmys2GDgsurfs7e9oCk4Hw1z qN8vquuK8fEKcjS3uqHGJvEsrSrbaijwLGNuRLR6XLZdGOhQzX+DZ8HzhQXC8Rx9Ul /on49AiUe2QKc2YyG6xCpLjxin7bZzpFqQel/LEZ0285HXQOR1r4QDbCT9lRA4tZMD 2y9cE7gBjkr4TLVnmc1KsdK+xoGa91LAwW54WWWewIKpdP7GtkPbaNxIYLewiPCkLx KoHg/xDGF207duMrDm+lGLRPyMv1wYHI9L62aLf7ws+43LtQw36A+BIOBTUCJnVOop QEbzHEPTzn9uw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Arnaldo Carvalho de Melo , Ian Rogers , Andrii Nakryiko , James Clark , Tiezhu Yang , Yang Jihong , bpf@vger.kernel.org, Arnaldo Carvalho de Melo , Namhyung Kim , Sasha Levin Subject: [PATCH 6.8 392/715] perf bpf: Clean up the generated/copied vmlinux.h Date: Sun, 24 Mar 2024 18:29:31 -0400 Message-ID: <20240324223455.1342824-393-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Arnaldo Carvalho de Melo [ Upstream commit ffd856537b95dd65facb4e0c78ca1cb92c2048ff ] When building perf with BPF skels we either copy the minimalistic tools/perf/util/bpf_skel/vmlinux/vmlinux.h or use bpftool to generate a vmlinux from BTF, storing the result in $(SKEL_OUT)/vmlinux.h. We need to remove that when doing a 'make -C tools/perf clean', fix it. Fixes: b7a2d774c9c5a9a3 ("perf build: Add ability to build with a generated= vmlinux.h") Reviewed-by: Ian Rogers Cc: Andrii Nakryiko Cc: James Clark Cc: Tiezhu Yang Cc: Yang Jihong Cc: bpf@vger.kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Namhyung Kim Link: https://lore.kernel.org/r/Zbz89KK5wHfZ82jv@x1 Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- tools/perf/Makefile.perf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index f8774a9b1377a..116db7874412d 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -1167,7 +1167,7 @@ bpf-skel: endif # CONFIG_PERF_BPF_SKEL =20 bpf-skel-clean: - $(call QUIET_CLEAN, bpf-skel) $(RM) -r $(SKEL_TMP_OUT) $(SKELETONS) + $(call QUIET_CLEAN, bpf-skel) $(RM) -r $(SKEL_TMP_OUT) $(SKELETONS) $(SKE= L_OUT)/vmlinux.h =20 clean:: $(LIBAPI)-clean $(LIBBPF)-clean $(LIBSUBCMD)-clean $(LIBSYMBOL)-cl= ean $(LIBPERF)-clean arm64-sysreg-defs-clean fixdep-clean python-clean bpf-= skel-clean tests-coresight-targets-clean $(call QUIET_CLEAN, core-objs) $(RM) $(LIBPERF_A) $(OUTPUT)perf-archive = $(OUTPUT)perf-iostat $(LANG_BINDINGS) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1693313CC72; Sun, 24 Mar 2024 22:41:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320085; cv=none; b=lRlL1nrdRvfwskF1GL/NPSSh82ctHnZdbz4SdZUKR2wEImnl+U5hElEMusLM4S4Z8iZrbugBsiv2cuM1XP20qoamKujLisGNVWwCHE/qlivyfFUVqg1VGpgwqpPYn7U1ceAyOLUWxSgaP75LgJO/W1kZJ0QA7RzDWUrrOyDxSDQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320085; c=relaxed/simple; bh=8aj/goXBmUnz9yrgHDqGWbx3hqheBb4xsQdBsUfe4oM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Yd5zX32cPGfqBR8EgzZsxYLDdrc6FBAow3UCe02ifAZQRCyiUvdCq6Nr6ChYAs2sSTSUcljSjvGi79C50LnmPKu0xnWEAOs+hxSmm3D9H1q0sanOofdBQd/QuqbPk7w8WMcAmKc9cQCz3Qy4zkZ9vXiWCfYs+iyd2noDkasfGC8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=f8KLX8u4; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="f8KLX8u4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4BE8EC43399; Sun, 24 Mar 2024 22:41:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320084; bh=8aj/goXBmUnz9yrgHDqGWbx3hqheBb4xsQdBsUfe4oM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=f8KLX8u4WggNi7s5EmC5ow5S/Dvi+25k+qI2O751RTMsX9d2fl4Pjr//vw0Opy/mf x2ZIbmBIBiA+K5irC0/2SNpPzafHXV1H51WObgHpQzq6J6AazAn7T0VOQFjYGEEbyg eDk2U2ATJxoP3U+x7xU0XHXep7/eaiIksIGTCYUD69HCw3MKDcpZn6wPF8Ahe+Zo1B Sc4/AHCkgQn3ejNytbvpathWchQOb++2JTEO/FjDP9+FLBVetliW2xCX6NsJoaYsKs 6aMa7x4q6N3DcUew6dh8pg5No9gvRsIR+pjoyWYiZqJDj6aDJ8Y3a3K36AJcNbXjuF JMmbDxX7zzgJg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Igor Prusov , Jerome Brunet , Sasha Levin Subject: [PATCH 6.8 393/715] clk: meson: Add missing clocks to axg_clk_regmaps Date: Sun, 24 Mar 2024 18:29:32 -0400 Message-ID: <20240324223455.1342824-394-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Igor Prusov [ Upstream commit ba535bce57e71463a86f8b33a0ea88c26e3a6418 ] Some clocks were missing from axg_clk_regmaps, which caused kernel panic during cat /sys/kernel/debug/clk/clk_summary [ 57.349402] Unable to handle kernel NULL pointer dereference at virtual = address 00000000000001fc ... [ 57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE= =3D--) [ 57.436900] pc : regmap_read+0x1c/0x88 [ 57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0 [ 57.445611] sp : ffff800082f1b690 [ 57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080e= b9a70 [ 57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 00000000000= 00000 [ 57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7= e7000 [ 57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: fffffffffff= fffff [ 57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042= a3000 [ 57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f= 5e100 [ 57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805= e4b24 [ 57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f= 1b710 [ 57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 00000000000= 01000 [ 57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 00000000000= 00000 [ 57.519615] Call trace: [ 57.522030] regmap_read+0x1c/0x88 [ 57.525393] clk_regmap_gate_is_enabled+0x3c/0xb0 [ 57.530050] clk_core_is_enabled+0x44/0x120 [ 57.534190] clk_summary_show_subtree+0x154/0x2f0 [ 57.538847] clk_summary_show_subtree+0x220/0x2f0 [ 57.543505] clk_summary_show_subtree+0x220/0x2f0 [ 57.548162] clk_summary_show_subtree+0x220/0x2f0 [ 57.552820] clk_summary_show_subtree+0x220/0x2f0 [ 57.557477] clk_summary_show_subtree+0x220/0x2f0 [ 57.562135] clk_summary_show_subtree+0x220/0x2f0 [ 57.566792] clk_summary_show_subtree+0x220/0x2f0 [ 57.571450] clk_summary_show+0x84/0xb8 [ 57.575245] seq_read_iter+0x1bc/0x4b8 [ 57.578954] seq_read+0x8c/0xd0 [ 57.582059] full_proxy_read+0x68/0xc8 [ 57.585767] vfs_read+0xb0/0x268 [ 57.588959] ksys_read+0x70/0x108 [ 57.592236] __arm64_sys_read+0x24/0x38 [ 57.596031] invoke_syscall+0x50/0x128 [ 57.599740] el0_svc_common.constprop.0+0x48/0xf8 [ 57.604397] do_el0_svc+0x28/0x40 [ 57.607675] el0_svc+0x34/0xb8 [ 57.610694] el0t_64_sync_handler+0x13c/0x158 [ 57.615006] el0t_64_sync+0x190/0x198 [ 57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00) [ 57.624668] ---[ end trace 0000000000000000 ]--- [jbrunet: add missing Fixes tag] Signed-off-by: Igor Prusov Link: https://lore.kernel.org/r/20240202172537.1.I64656c75d84284bc91e6126b5= 0b33c502be7c42a@changeid Fixes: 14ebb3154b8f ("clk: meson: axg: add Video Clocks") Signed-off-by: Jerome Brunet Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/clk/meson/axg.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/clk/meson/axg.c b/drivers/clk/meson/axg.c index c12f81dfa6745..5f60f2bcca592 100644 --- a/drivers/clk/meson/axg.c +++ b/drivers/clk/meson/axg.c @@ -2142,7 +2142,9 @@ static struct clk_regmap *const axg_clk_regmaps[] =3D= { &axg_vclk_input, &axg_vclk2_input, &axg_vclk_div, + &axg_vclk_div1, &axg_vclk2_div, + &axg_vclk2_div1, &axg_vclk_div2_en, &axg_vclk_div4_en, &axg_vclk_div6_en, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 109B118D865; Sun, 24 Mar 2024 22:41:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320086; cv=none; b=sri9ymZst+im70qLeZMwvSmx8VdAZ9yHLpZgn6Wd+82qbZ31Z2lkJ9mFmwK3AHaWlL2OVClOa6o2qmi1BhxHJ/kUrOyoIWYFLyLpu3gj/M4mM88U0RhXyRUTKKxgXNKfzS1sCiDocLr+OQTiZZD3H8FWmuPajSl7JLmcHNhwQU4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320086; c=relaxed/simple; bh=CwWwXVhHyKnLQ10moKJIyAHUeLsBYRK/aKO6LwRtc0U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IvC+w1hzGSqa8rNu6d+4U0AZ058m9ZbMVZNUbAAR81uy8YQd1D9WC3HMjW71yl3kF4fgxE003DQrCBQ09Cn+5fsZJ5tD1YtBRI752V+TbYWIYyR7nRL/NgMKzNmOdJKIbphZqx9kEj+hiZFziLhOT9dXIwPwYcXWze7UzWwialo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JdoOfvr+; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JdoOfvr+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 34712C433B2; Sun, 24 Mar 2024 22:41:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320085; bh=CwWwXVhHyKnLQ10moKJIyAHUeLsBYRK/aKO6LwRtc0U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=JdoOfvr+VZSdmVC8LrtpFULwbyzXAEHQiV7h292Rjo1c7tKU8BzWvZxpeHK6RAwTR /IIYioCTAvfpFQd1bl6fZojKKIqRDIqqtKOL+G72PtCPcK/NcTpe9dT+OTy/cAdHV1 tExhO6Uc9hBzxA7fYkRBJVzSwiZsNZbt8SHlUUqtW34YydeBAHWY7XmRRlmvkfonZa gESInuNelhuTjon215wzVuxD0eKhU52jbCqEWCBnKczJshKPXOXz8Q1jP8qxEItOqb AC+yD6N4KOBPMjWXbylXO39G7YmJ36oG5NybErIVjqTxIdFKQV5z7/DNh5gL2oshaa W6zQ6BYC/7Bvg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Nikita Zhandarovich , Mauro Carvalho Chehab , Hans Verkuil , Sasha Levin Subject: [PATCH 6.8 394/715] media: em28xx: annotate unchecked call to media_device_register() Date: Sun, 24 Mar 2024 18:29:33 -0400 Message-ID: <20240324223455.1342824-395-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Nikita Zhandarovich [ Upstream commit fd61d77a3d28444b2635f0c8b5a2ecd6a4d94026 ] Static analyzers generate alerts for an unchecked call to `media_device_register()`. However, in this case, the device will work reliably without the media controller API. Add a comment above the call to prevent future unnecessary changes. Suggested-by: Mauro Carvalho Chehab Fixes: 37ecc7b1278f ("[media] em28xx: add media controller support") Signed-off-by: Nikita Zhandarovich Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/media/usb/em28xx/em28xx-cards.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em= 28xx/em28xx-cards.c index 4d037c92af7c5..bae76023cf71d 100644 --- a/drivers/media/usb/em28xx/em28xx-cards.c +++ b/drivers/media/usb/em28xx/em28xx-cards.c @@ -4094,6 +4094,10 @@ static int em28xx_usb_probe(struct usb_interface *in= tf, * topology will likely change after the load of the em28xx subdrivers. */ #ifdef CONFIG_MEDIA_CONTROLLER + /* + * No need to check the return value, the device will still be + * usable without media controller API. + */ retval =3D media_device_register(dev->media_dev); #endif =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5186418D886; Sun, 24 Mar 2024 22:41:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320087; cv=none; b=D+SHHB9FRZxAzcSXlKPqNwOi0wQAszJg5nND5bINOykY+NQ7RCq0o07suN/0rCLbUkwez1+FDHCFO51R+Z+bu710fl+mJt5B32Axodh7CDI/ITq4PKnzKbIy3E4UQHBH0SMtFwh2oJpRDYyO7GxxY3MQxjxoU92XiHii3VCclBM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320087; c=relaxed/simple; bh=EWgKnN4Jo0bf+oXAc5grq6JHSvSF9OfBeXnKDb9HOws=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=DNnOLwUqzeRtkUkpyFExU41JeAbqpD2GAFzDBHBRcJnKRW+4nIQqGdw+jZB9X8W0Pm2gltpj4JuhxGR+emsi6FyMW7rCsiyV+AhDBz9vI1Zd3AgbjZaJWmcEkcOWkeeUKZebc2bqmNPYDDhA37NU4oTzbdI70/wUs9e+cY1yCvU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=po2yI47z; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="po2yI47z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 35C8EC433F1; Sun, 24 Mar 2024 22:41:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320086; bh=EWgKnN4Jo0bf+oXAc5grq6JHSvSF9OfBeXnKDb9HOws=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=po2yI47zHtQihVtZxa5IrNbfCZXbAxTP2HwiKwi3z/GibvlJPyVl1OS3hyiTGwO0K h25A8gneFUjMd8jObQKr6IirO5VoC3bsx80PYpjE9GLWs0VaERPBLB5JRCh96fsnRB CGVz0ItQHtA9I2v383wgO0/F0j1ywVoft1+PdD8HzSnN/q5r0/eQzsLtUQHFs7G9uS coGXAlAQDG7nkxVcgwTruqa9okXEbdc8ZlQHJnfvIjBj2+JcQuisZz5cORd2H2UBmE xYPa6zwevsZNquIs1sdtfcUo41HUW/3E1EmlnG9vbK3jT0EaA0qa+Uo9nsiv7/S4FX 5kEVZFz8tGgjw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zhipeng Lu , Hans Verkuil , Sasha Levin Subject: [PATCH 6.8 395/715] media: v4l2-tpg: fix some memleaks in tpg_alloc Date: Sun, 24 Mar 2024 18:29:34 -0400 Message-ID: <20240324223455.1342824-396-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zhipeng Lu [ Upstream commit 8cf9c5051076e0eb958f4361d50d8b0c3ee6691c ] In tpg_alloc, resources should be deallocated in each and every error-handling paths, since they are allocated in for statements. Otherwise there would be memleaks because tpg_free is called only when tpg_alloc return 0. Fixes: 63881df94d3e ("[media] vivid: add the Test Pattern Generator") Signed-off-by: Zhipeng Lu Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/media/common/v4l2-tpg/v4l2-tpg-core.c | 52 +++++++++++++++---- 1 file changed, 42 insertions(+), 10 deletions(-) diff --git a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c b/drivers/media/= common/v4l2-tpg/v4l2-tpg-core.c index a366566f22c3b..642c48e8c1f58 100644 --- a/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c +++ b/drivers/media/common/v4l2-tpg/v4l2-tpg-core.c @@ -113,6 +113,7 @@ int tpg_alloc(struct tpg_data *tpg, unsigned max_w) { unsigned pat; unsigned plane; + int ret =3D 0; =20 tpg->max_line_width =3D max_w; for (pat =3D 0; pat < TPG_MAX_PAT_LINES; pat++) { @@ -121,14 +122,18 @@ int tpg_alloc(struct tpg_data *tpg, unsigned max_w) =20 tpg->lines[pat][plane] =3D vzalloc(array3_size(max_w, 2, pixelsz)); - if (!tpg->lines[pat][plane]) - return -ENOMEM; + if (!tpg->lines[pat][plane]) { + ret =3D -ENOMEM; + goto free_lines; + } if (plane =3D=3D 0) continue; tpg->downsampled_lines[pat][plane] =3D vzalloc(array3_size(max_w, 2, pixelsz)); - if (!tpg->downsampled_lines[pat][plane]) - return -ENOMEM; + if (!tpg->downsampled_lines[pat][plane]) { + ret =3D -ENOMEM; + goto free_lines; + } } } for (plane =3D 0; plane < TPG_MAX_PLANES; plane++) { @@ -136,18 +141,45 @@ int tpg_alloc(struct tpg_data *tpg, unsigned max_w) =20 tpg->contrast_line[plane] =3D vzalloc(array_size(pixelsz, max_w)); - if (!tpg->contrast_line[plane]) - return -ENOMEM; + if (!tpg->contrast_line[plane]) { + ret =3D -ENOMEM; + goto free_contrast_line; + } tpg->black_line[plane] =3D vzalloc(array_size(pixelsz, max_w)); - if (!tpg->black_line[plane]) - return -ENOMEM; + if (!tpg->black_line[plane]) { + ret =3D -ENOMEM; + goto free_contrast_line; + } tpg->random_line[plane] =3D vzalloc(array3_size(max_w, 2, pixelsz)); - if (!tpg->random_line[plane]) - return -ENOMEM; + if (!tpg->random_line[plane]) { + ret =3D -ENOMEM; + goto free_contrast_line; + } } return 0; + +free_contrast_line: + for (plane =3D 0; plane < TPG_MAX_PLANES; plane++) { + vfree(tpg->contrast_line[plane]); + vfree(tpg->black_line[plane]); + vfree(tpg->random_line[plane]); + tpg->contrast_line[plane] =3D NULL; + tpg->black_line[plane] =3D NULL; + tpg->random_line[plane] =3D NULL; + } +free_lines: + for (pat =3D 0; pat < TPG_MAX_PAT_LINES; pat++) + for (plane =3D 0; plane < TPG_MAX_PLANES; plane++) { + vfree(tpg->lines[pat][plane]); + tpg->lines[pat][plane] =3D NULL; + if (plane =3D=3D 0) + continue; + vfree(tpg->downsampled_lines[pat][plane]); + tpg->downsampled_lines[pat][plane] =3D NULL; + } + return ret; } EXPORT_SYMBOL_GPL(tpg_alloc); =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 250486BB51; Sun, 24 Mar 2024 22:41:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320088; cv=none; b=E3JuI49N3pWWFXbDHc61iaVCVKpci9CwowbPBuija+sUkEazoKtxtcepGx18+qX1x3fVfvwTXlkvSuBkmZxm9Asqr1JBOimwPIymGYMeQBhDzptla3x5MPPx+okJOEL6QZisUTYQ32K1gsaOR0wa/siDCcK8GOkj/xTlA5H4BNk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320088; c=relaxed/simple; bh=d6lzkkIjVC8j7FCAyLRzMX5ir2uPOxbS8UYQkWRwhlM=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Y46QL5DDgxmWWhCYYvoM8Xcmo/jtEDcf2CcVwu5vDp0Ekzk3SpXQmlkfCNPX0uO+4534VbddlmYj5KzE5TsXGdOtAMtpCKO5K+WCY00Z6ytB7q2taMN9vZvTthXAes6AIye2EvVvYshpQ0bw4oioSwrVG/7Lh0zrlSx8pPLOlNY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CQX4ijUv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CQX4ijUv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D144C433C7; Sun, 24 Mar 2024 22:41:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320087; bh=d6lzkkIjVC8j7FCAyLRzMX5ir2uPOxbS8UYQkWRwhlM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=CQX4ijUvkMl/CYFB9Pg2IhrXEc57kxKfvrti/osl2DMGDWjM+MoFVtRccNZ346WHi EYUY0t4nybEDaiVnYbMOZaXdOVeEYUEz1tQK1LIs6P3dJcOliX5Trgpghbsf4ooxag 3EghFDi2DLCZSQhCYGiWpcuB1hYOS9+f79cd0Pqe1P6VxiMiuyZ27PLppYNyN5+alk 9AAE6jJ65YhXMOMFIa1JkxfiLTIOojIo4Zo1XxgMG4ti9xAezREvWxCb/nvw26MAnH 8ZWH01JnuKIpY3hEfgnrw1L9C+Kd2PxaaUcV8p+YiIX5AjMwKk5ARu7vt+1stDB8cd T4baoQ8wjyZSA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zhipeng Lu , Hans Verkuil , Sasha Levin Subject: [PATCH 6.8 396/715] media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity Date: Sun, 24 Mar 2024 18:29:35 -0400 Message-ID: <20240324223455.1342824-397-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zhipeng Lu [ Upstream commit 8f94b49a5b5d386c038e355bef6347298aabd211 ] The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name. Fixes: be2fff656322 ("media: add helpers for memory-to-memory media control= ler") Signed-off-by: Zhipeng Lu Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/media/v4l2-core/v4l2-mem2mem.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-co= re/v4l2-mem2mem.c index 9e983176542be..75517134a5e94 100644 --- a/drivers/media/v4l2-core/v4l2-mem2mem.c +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c @@ -1087,11 +1087,17 @@ static int v4l2_m2m_register_entity(struct media_de= vice *mdev, entity->function =3D function; =20 ret =3D media_entity_pads_init(entity, num_pads, pads); - if (ret) + if (ret) { + kfree(entity->name); + entity->name =3D NULL; return ret; + } ret =3D media_device_register_entity(mdev, entity); - if (ret) + if (ret) { + kfree(entity->name); + entity->name =3D NULL; return ret; + } =20 return 0; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0BEB818E0D2; Sun, 24 Mar 2024 22:41:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320089; cv=none; b=gN6NeN1SDJ1rhCiRi7ZgAZFUtFwGtbucwjhYHRQ6RkS4Pb7gy6W5wRGn3fJjzprRM2s0iTN82glItwl2j11avgi9Fo9B0ADDpU61vvZwxZKXqG94lzHTY+FK6woKQuBByaJqrDSjuRwaNbi9m74zO5zm9uPHsVOud4KGBfMIcBo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320089; c=relaxed/simple; bh=tfC0CJv+EuNve4rNiL1lZoeJA6p65O56r/r2E6wkOnE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=SJRB8BkCzV9blhgM9C9abwidt3PFxbeGaxZkvOC86Xi0kpIc7sGenuoLCwL3oNdhlP7U2iXWGrUopD6eEket2OCk8FIz0LTnmoQNV8zQheW3LBcgkBkXyR/qP0Fka+hVnihnx3V+qRYjq6gCnPpI+2LJaTuRoH7m4B4TL/rq1nE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PkG1QYwp; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PkG1QYwp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 02AFFC433F1; Sun, 24 Mar 2024 22:41:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320088; bh=tfC0CJv+EuNve4rNiL1lZoeJA6p65O56r/r2E6wkOnE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PkG1QYwpYi+joAJ+FwvM9rRqrUpNzLrUCENP7svZMnpFbujCpjIGAwoSamTCwetR8 u3NfZVwLqmlb1bv+G/n+TLwpCnZrd2u1oC668na40tLghQliisr6YDi6US4ujMTVUG XfadJOmjR1Em3uUHxyAY0FQxUL8X3MlGMufGajiF6wz2V36UVNrsCZ4tqME96dp1K4 L/wrcmHhR7fuaHdw0RnPIfNCvcyYDACiXttpTTrvDi5lyt2lV9hcWmKgbUvzi498at BcyKHzB3CMcZ0KjdUC7n+pN/cpeTb3+l2rZYZVYvATT844lNq+Q8bDCPctvMg89p4O u9dfYADAWojuw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Rob Herring , Hans Verkuil , Sasha Levin Subject: [PATCH 6.8 397/715] media: dt-bindings: techwell,tw9900: Fix port schema ref Date: Sun, 24 Mar 2024 18:29:36 -0400 Message-ID: <20240324223455.1342824-398-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Rob Herring [ Upstream commit c9cd7308d64b13741ee03be81836a324fc4d657d ] The port@0 node doesn't define any extra properties in the port or endpoint nodes, so the $ref should be to "/properties/port" instead as it restricts extra properties. Fixes: 0f82ffa9a295 ("media: dt-bindings: media: i2c: Add bindings for TW99= 00") Signed-off-by: Rob Herring Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- .../devicetree/bindings/media/i2c/techwell,tw9900.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.ya= ml b/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml index e37317f810722..c9673391afdbd 100644 --- a/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml +++ b/Documentation/devicetree/bindings/media/i2c/techwell,tw9900.yaml @@ -36,7 +36,7 @@ properties: =20 properties: port@0: - $ref: /schemas/graph.yaml#/$defs/port-base + $ref: /schemas/graph.yaml#/properties/port description: Analog input port =20 properties: --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C254F18E0EE; Sun, 24 Mar 2024 22:41:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320089; cv=none; b=XAGCEG3SCptoaF9bSql4g25rj0hpDvVOEaR8vQOkSjHpcJp6g+txCQiFUFlrP+EEiqtG/btT9pV/D2U2swsk4a7EhiuGDVyBJE7YwbtUSwR3/Ob+wtQA0XldyPr0RZo090NNmtW9wenTD2ZJUJAjbS6ISirQymYbGZXrk9Hx4N8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320089; c=relaxed/simple; bh=YZPj3TCyeuHzFbALh1S/QKMJWCXWAsaZ839msyp0NqU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=tUFCCGHVQscGesuUw7+E42BvJaj7CMWmiXzB+5RCuVh2Xn5oRNdat6cptqYFX+jMY6rirgyw8MWnKFlE/z3uS6EiYX+jk5b8LPayw0uOw/PNCal1TKKK1whRYbAHFteVIrRLSGVsgsCm2h68hvuOwRxdN06TI24/4tP8u55B4pQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=l7/UeI8j; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="l7/UeI8j" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E6F08C43390; Sun, 24 Mar 2024 22:41:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320089; bh=YZPj3TCyeuHzFbALh1S/QKMJWCXWAsaZ839msyp0NqU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=l7/UeI8j2hXphPLcJWI05Z2hpgLkxElBihgWH+cz3beRTvK/UWQCM0h/I9vQJSc0e DaCYlCqIO0xHR7hqeq+tHi00TicrIHiQBaMzISKjs92/yO9lF89Nzvrh2+aXRLXxrL S429iYJXLCFhFHPt86NpaFtTGr3fC3bnAw6AyGK+Tr1zd91Qxr+TMH0pgawGEzDDo9 WA04SuwAe02XnPWmrrE+cfIMTar1diws1y5gE7Sq2/EHZRmzLXiJV2zG6bY+FI5NNC LK4BPzpINeRnOdl47hJf2PcQldQss5+lNgSnY9oOF/F9fgk76aD1/fzyTX6P2N+Qcj amyW1DbTh254g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Ezra Buehler , Martin Kurbanov , Miquel Raynal , Sasha Levin Subject: [PATCH 6.8 398/715] mtd: spinand: esmt: Extend IDs to 5 bytes Date: Sun, 24 Mar 2024 18:29:37 -0400 Message-ID: <20240324223455.1342824-399-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Ezra Buehler [ Upstream commit 4bd14b2fd8a83a2f5220ba4ef323f741e11bfdfd ] According to the datasheets, the ESMT chips in question will return a 5 byte long identification code where the last 3 bytes are the JEDEC continuation codes (7Fh). Although, I would have expected 4 continuation codes as Powerchip Semiconductor (C8h, corresponding to the parameter page data) is located in bank 5 of the JEDEC database. By matching the full 5 bytes we can avoid clashes with GigaDevice NAND flashes. This fix allows the MT7688-based GARDENA smart Gateway to boot again. Fixes: aa08bf187f32 ("mtd: spinand: esmt: add support for F50D2G41KA") Signed-off-by: Ezra Buehler Reviewed-by: Martin Kurbanov Tested-by: Martin Kurbanov Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20240125200108.24374-3-ezra@easyb.ch Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/mtd/nand/spi/esmt.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/mtd/nand/spi/esmt.c b/drivers/mtd/nand/spi/esmt.c index 31c439a557b18..4597a82de23a4 100644 --- a/drivers/mtd/nand/spi/esmt.c +++ b/drivers/mtd/nand/spi/esmt.c @@ -104,7 +104,8 @@ static const struct mtd_ooblayout_ops f50l1g41lb_ooblay= out =3D { =20 static const struct spinand_info esmt_c8_spinand_table[] =3D { SPINAND_INFO("F50L1G41LB", - SPINAND_ID(SPINAND_READID_METHOD_OPCODE_ADDR, 0x01), + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_ADDR, 0x01, 0x7f, + 0x7f, 0x7f), NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1), NAND_ECCREQ(1, 512), SPINAND_INFO_OP_VARIANTS(&read_cache_variants, @@ -113,7 +114,8 @@ static const struct spinand_info esmt_c8_spinand_table[= ] =3D { 0, SPINAND_ECCINFO(&f50l1g41lb_ooblayout, NULL)), SPINAND_INFO("F50D1G41LB", - SPINAND_ID(SPINAND_READID_METHOD_OPCODE_ADDR, 0x11), + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_ADDR, 0x11, 0x7f, + 0x7f, 0x7f), NAND_MEMORG(1, 2048, 64, 64, 1024, 20, 1, 1, 1), NAND_ECCREQ(1, 512), SPINAND_INFO_OP_VARIANTS(&read_cache_variants, @@ -122,7 +124,8 @@ static const struct spinand_info esmt_c8_spinand_table[= ] =3D { 0, SPINAND_ECCINFO(&f50l1g41lb_ooblayout, NULL)), SPINAND_INFO("F50D2G41KA", - SPINAND_ID(SPINAND_READID_METHOD_OPCODE_ADDR, 0x51), + SPINAND_ID(SPINAND_READID_METHOD_OPCODE_ADDR, 0x51, 0x7f, + 0x7f, 0x7f), NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 1, 1, 1), NAND_ECCREQ(8, 512), SPINAND_INFO_OP_VARIANTS(&read_cache_variants, --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B765A18E7E6; Sun, 24 Mar 2024 22:41:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320090; cv=none; b=EXRSw+ItUjCpgBz04vWfNBdbo5Vow7FUo8Xe036v1XWB1V+DpVJQhA8Y0jJHqV+nwJwKJH5I2oy/qs/ev8zDi6cSjdjcL5+DfTpLeeqh5UrlYb5LtrkVY/3VrQZ3VL1WGTGVF3sIwDG7CspVu45SWNa5kkZ1YHiK/GICj8jgves= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320090; c=relaxed/simple; bh=ScxSW6UgPUsVoztvMsj+KZEAdBvd7VPwubsif2s549w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=D0NpzIdPQGXX3mOuhvkaz6HSVETMnQmXipjSyGs1SHy8te6lmMp14Vd9YlaeiXVBCcak7wGizlzVPZ5gcImn/Xi/re7jHLjnuzysGfA8zetI0nFPwhAmOKoiO3HXTnMazMIInC+H5BWMe/gAfVLdayTY7PTIoEJYx7ggD3ZMdMM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SeB1BpL8; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SeB1BpL8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F06BCC43390; Sun, 24 Mar 2024 22:41:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320090; bh=ScxSW6UgPUsVoztvMsj+KZEAdBvd7VPwubsif2s549w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SeB1BpL8dcybdlQmxf7AjaHmK+m0NuvumjH6yAyUbzMoqC0Og4qZdNVnWRDBJJ9nh 7SDMFBV9lxiHQjyzgNMPsaWPenT7GTZv2OVBY1IsDLcb9T6KBOb4Y+FdHVwZzaQpyQ 7lT/LxMndSBqeDRcL7fxWz7JeqKkmWn8HDzZLmzPLWFhmMIdw5NNDMafjlXpvuhmRN jVa9NW9TDZjVFtHKSZ97/Yfyvtmk3t2yzIuiUVLFquPpmU4TH/eejozDT6TOeOfCjQ tgT9vmsRfqBwFV60JzkHd0XNFDImmvnHVKqU+ZftphLi7/4BTk19FSBMmnySgnk0HD AJ2RHmFZTolKw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Zhipeng Lu , Mauro Carvalho Chehab , Sasha Levin Subject: [PATCH 6.8 399/715] media: edia: dvbdev: fix a use-after-free Date: Sun, 24 Mar 2024 18:29:38 -0400 Message-ID: <20240324223455.1342824-400-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Zhipeng Lu [ Upstream commit 8c64f4cdf4e6cc5682c52523713af8c39c94e6d5 ] In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed in several error-handling paths. However, *pdvbdev is not set to NULL after dvbdev's deallocation, causing use-after-frees in many places, for example, in the following call chain: budget_register |-> dvb_dmxdev_init |-> dvb_register_device |-> dvb_dmxdev_release |-> dvb_unregister_device |-> dvb_remove_device |-> dvb_device_put |-> kref_put When calling dvb_unregister_device, dmxdev->dvbdev (i.e. *pdvbdev in dvb_register_device) could point to memory that had been freed in dvb_register_device. Thereafter, this pointer is transferred to kref_put and triggering a use-after-free. Link: https://lore.kernel.org/linux-media/20240203134046.3120099-1-alexious= @zju.edu.cn Fixes: b61901024776 ("V4L/DVB (5244): Dvbdev: fix illegal re-usage of fileo= perations struct") Signed-off-by: Zhipeng Lu Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/media/dvb-core/dvbdev.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbde= v.c index 49f0eb7d0b9d3..733d0bc4b4cc3 100644 --- a/drivers/media/dvb-core/dvbdev.c +++ b/drivers/media/dvb-core/dvbdev.c @@ -490,6 +490,7 @@ int dvb_register_device(struct dvb_adapter *adap, struc= t dvb_device **pdvbdev, dvbdevfops =3D kmemdup(template->fops, sizeof(*dvbdevfops), GFP_KERNEL); if (!dvbdevfops) { kfree(dvbdev); + *pdvbdev =3D NULL; mutex_unlock(&dvbdev_register_lock); return -ENOMEM; } @@ -498,6 +499,7 @@ int dvb_register_device(struct dvb_adapter *adap, struc= t dvb_device **pdvbdev, if (!new_node) { kfree(dvbdevfops); kfree(dvbdev); + *pdvbdev =3D NULL; mutex_unlock(&dvbdev_register_lock); return -ENOMEM; } @@ -531,6 +533,7 @@ int dvb_register_device(struct dvb_adapter *adap, struc= t dvb_device **pdvbdev, } list_del(&dvbdev->list_head); kfree(dvbdev); + *pdvbdev =3D NULL; up_write(&minor_rwsem); mutex_unlock(&dvbdev_register_lock); return -EINVAL; @@ -553,6 +556,7 @@ int dvb_register_device(struct dvb_adapter *adap, struc= t dvb_device **pdvbdev, dvb_media_device_free(dvbdev); list_del(&dvbdev->list_head); kfree(dvbdev); + *pdvbdev =3D NULL; mutex_unlock(&dvbdev_register_lock); return ret; } @@ -571,6 +575,7 @@ int dvb_register_device(struct dvb_adapter *adap, struc= t dvb_device **pdvbdev, dvb_media_device_free(dvbdev); list_del(&dvbdev->list_head); kfree(dvbdev); + *pdvbdev =3D NULL; mutex_unlock(&dvbdev_register_lock); return PTR_ERR(clsdev); } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C959318E809; Sun, 24 Mar 2024 22:41:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320091; cv=none; b=GrKKOc475O9jfLLKbddjE4pX15Amp5Fh6HEFr+0AmTDyuLH6LICyOkXulLe3js0fYRceX1MWkJQA08C4+1F70fQ6Wje1NaFtTgeJ9mBm/uVKhHqUOA+p+FdJvdnykdjtEmTHYSHrOAQgOZfJluvvJtoln40rDJ86OdABBUBeBQ4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320091; c=relaxed/simple; bh=Zec8QF+NmLIC7REopIU1XehcsypatEp5JuO/SuUNa/w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=c7goN+Kg2FrE4522zF6l+0UHWsMAECSk2zdSDU1dR1R48L4RsJ8rrCCzQ7Qk8HBhTW9rgHhdmCNwd27ZWF8lWkb0r+CHosUm0qC8+E66g2Nakwf7s9FO6ejz4YwATe4XIaBjISPfd9e+ig+QV8FJ9HT+YAqIzAGT7lOp9anUM2c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FZsXZZZX; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FZsXZZZX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DFBA0C43394; Sun, 24 Mar 2024 22:41:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320091; bh=Zec8QF+NmLIC7REopIU1XehcsypatEp5JuO/SuUNa/w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=FZsXZZZXEq0YDn4+J9AU2NdXbp0EeL7Fgt2rD7s02T+yig2LCPb0zL8rJdGbfaiNY vC+6+7Ucfu13J31Wx9ZgXq8qdLlILCAyaZ4eXjowa6otJBLcgW9E9BkIzJ9SETLEdp UQY1uePSUKM+i2Vn0wUC1VdXTxLV6hyMSvAKoIErqLS2tu7pBMp1dTT1a2Ddr9ILSI wtBFtKtCUwbm3ZRlJeSMLuqWFL9hgD9xaR2Pg5bawIwfWsjnwZcUsv0c09irJ+lB9k mIOFknOHLS3gG7vHxzX2iSI8JKS2VBCub51AtfG3H0XDIWQ7fsZ4HceGnfuasoqpyK 6N82EUpZ6Nawg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chen-Yu Tsai , AngeloGioacchino Del Regno , Linus Walleij , Sasha Levin Subject: [PATCH 6.8 400/715] pinctrl: mediatek: Drop bogus slew rate register range for MT8186 Date: Sun, 24 Mar 2024 18:29:39 -0400 Message-ID: <20240324223455.1342824-401-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chen-Yu Tsai [ Upstream commit 3a29c87548809405bcbc66acc69cbe6f15184d94 ] The MT8186 does not support configuring pin slew rate. This is evident from both the datasheet, and the fact that the driver points the slew rate register range at the GPIO direction register range. Drop the bogus setting. Fixes: 8b483bda1e46 ("pinctrl: add pinctrl driver on mt8186") Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240131071910.3950450-1-wenst@chromium.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/pinctrl/mediatek/pinctrl-mt8186.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8186.c b/drivers/pinctrl/me= diatek/pinctrl-mt8186.c index 7be591591cce5..dd19e74856a92 100644 --- a/drivers/pinctrl/mediatek/pinctrl-mt8186.c +++ b/drivers/pinctrl/mediatek/pinctrl-mt8186.c @@ -1198,7 +1198,6 @@ static const struct mtk_pin_reg_calc mt8186_reg_cals[= PINCTRL_PIN_REG_MAX] =3D { [PINCTRL_PIN_REG_DIR] =3D MTK_RANGE(mt8186_pin_dir_range), [PINCTRL_PIN_REG_DI] =3D MTK_RANGE(mt8186_pin_di_range), [PINCTRL_PIN_REG_DO] =3D MTK_RANGE(mt8186_pin_do_range), - [PINCTRL_PIN_REG_SR] =3D MTK_RANGE(mt8186_pin_dir_range), [PINCTRL_PIN_REG_SMT] =3D MTK_RANGE(mt8186_pin_smt_range), [PINCTRL_PIN_REG_IES] =3D MTK_RANGE(mt8186_pin_ies_range), [PINCTRL_PIN_REG_PU] =3D MTK_RANGE(mt8186_pin_pu_range), --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C82C318EF82; Sun, 24 Mar 2024 22:41:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320092; cv=none; b=WNHqn2QPMyDtQDLjgz/Cc93fYgwFq2aOkIrCyop+nDjOSRyT1ijeAdZ+jAQA6R31mfxwBgu14H5Wl8lOYZvKeGcOzGcjjCTy78kjqWYXjFq4bYlneKEmamIZfAoF5/okWBVovI2kBSgXi04Zu9XGpQPYhkvuKQbaZNr2tY2UVFw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320092; c=relaxed/simple; bh=Ie+uzGtluX698sd7ls4ng58ghZb0o8no6h5usjuWX5U=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=hc0ORehsjD047LdgMWJKv0wz5xdcLaidtGLgTeOLqRHl6MtO+PVLjGpnpgll5CP/h0VRuucLtGV8AbGDZNUXMwPIzDOtcveb3dSjiW/LbHVS1+RaMOtpu5bmPmbdRu6l8aUcJXOTK0Gb0/yfqGX0/fc9eSQ32WimOtPKBDxCJ5M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=eM2SGsCP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="eM2SGsCP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E727EC433C7; Sun, 24 Mar 2024 22:41:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320092; bh=Ie+uzGtluX698sd7ls4ng58ghZb0o8no6h5usjuWX5U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=eM2SGsCPP79sQZqKcAHK2DDpgKOYQavcnystNnBt803njma7cQpJiv78xbmd8+3ag Ql8t1QWZk1UOMQzYcLptaq6ntnPNcK09gdQWMotwBKzUASHKlLgU2XReeZ4PC0E7CR tI4YuXH1sJkfGno8TB+5U2vfGEGu+fjuyhSuUTyQQHWBZmk1YU5GW5X1rNTEbjIaus 6y9rKfMEHyjQmHHLzH12e3YKjx0Wi/sga/v7zRvRtTKxgEwsjj69LUgqQHy5rwqxGS RvX4BTL7mPgk2bg3wgmTQU+PDvC7HAjjV4T7vqDkKREqN4DlznujZn0Ib4RfOeaWI5 VcONtSlug3/jA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Chen-Yu Tsai , AngeloGioacchino Del Regno , Linus Walleij , Sasha Levin Subject: [PATCH 6.8 401/715] pinctrl: mediatek: Drop bogus slew rate register range for MT8192 Date: Sun, 24 Mar 2024 18:29:40 -0400 Message-ID: <20240324223455.1342824-402-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Chen-Yu Tsai [ Upstream commit e15ab05a6b3ed42f2f43f8bd1a1abdbde64afecd ] The MT8192 does not support configuring pin slew rate. This is evident from both the datasheet, and the fact that the driver points the slew rate register range at the GPIO direction register range. Drop the bogus setting. Fixes: d32f38f2a8fc ("pinctrl: mediatek: Add pinctrl driver for mt8192") Signed-off-by: Chen-Yu Tsai Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240131071910.3950450-2-wenst@chromium.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/pinctrl/mediatek/pinctrl-mt8192.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8192.c b/drivers/pinctrl/me= diatek/pinctrl-mt8192.c index e3a76381f7f4e..3f8a9dbcb7041 100644 --- a/drivers/pinctrl/mediatek/pinctrl-mt8192.c +++ b/drivers/pinctrl/mediatek/pinctrl-mt8192.c @@ -1379,7 +1379,6 @@ static const struct mtk_pin_reg_calc mt8192_reg_cals[= PINCTRL_PIN_REG_MAX] =3D { [PINCTRL_PIN_REG_DIR] =3D MTK_RANGE(mt8192_pin_dir_range), [PINCTRL_PIN_REG_DI] =3D MTK_RANGE(mt8192_pin_di_range), [PINCTRL_PIN_REG_DO] =3D MTK_RANGE(mt8192_pin_do_range), - [PINCTRL_PIN_REG_SR] =3D MTK_RANGE(mt8192_pin_dir_range), [PINCTRL_PIN_REG_SMT] =3D MTK_RANGE(mt8192_pin_smt_range), [PINCTRL_PIN_REG_IES] =3D MTK_RANGE(mt8192_pin_ies_range), [PINCTRL_PIN_REG_PU] =3D MTK_RANGE(mt8192_pin_pu_range), --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E1CDE18EFA6; Sun, 24 Mar 2024 22:41:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320094; cv=none; b=DmwKD12U/vdQYXwQ/+buUuBF3YjBOgtIZF/sVpeYm2X4rVYVlmkjKpy8fU6lVgRto2Wrce08RQWbGe+fCJoPYkOrHqvMcINNfs8fi5T4t66WVkZWDQJm5y0dgMZnQ9IUdnjSHGvWQO045r5JO4r6iOxoWNkoLzRJIiO+7caei6c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320094; c=relaxed/simple; bh=FeJ7rRD6Pl0PL3JQV059ZhHkAnbDL0udLtd1lvou/3w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=G8xVZYaSAE9s1ZRzS0yrkujF21tqlnpFXaCEqclY+ESz37gfzX3iT5ys0wCIbvVmouLIi1ygG1kgBb2Zd9dlNdL+0/EuBa+5n2WWwACy1iYJTP8LC9ndEXs5vqkYz05Nt0SOyyuCt1SrX9B0D2REMmmgsrPvNPTrpP3LJvQ6xUw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IRyxv8lW; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="IRyxv8lW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id ED3EDC433C7; Sun, 24 Mar 2024 22:41:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320093; bh=FeJ7rRD6Pl0PL3JQV059ZhHkAnbDL0udLtd1lvou/3w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=IRyxv8lWTraWrzizgJSp2x2af/I01cMFYA0j3UZNsT0LOq+cN8MEC1fFE/JvXCyY/ 5HKM1yHf0SoxWacsmdVE4cXN85vRUX4XMYfGspvHmr8HcivUmX5Krde+WRgEoeoZXE A9dABchx8AluYJUrcq2b0iBOPfW2mNOFfNz5jEYILWUsNviV++FsZIL3lWlCce8ZX0 bjRG4Glau1kNNqaNOpJ7lfGU9h/KIuXnRFs8lmTGlgMyeZCEQ3J9pva0g9gFsrBfG2 90rmaV1F7k7KMz/6YAlDk3xW20KWx2C+mbU/KL2SZUBLWbKtJ/MZlNWUyR9i5FvpmT X7mjMYHUP7/dA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Srinivasan Shanmugam , =?UTF-8?q?Christian=20K=C3=B6nig?= , Alex Deucher , Sasha Levin Subject: [PATCH 6.8 402/715] drm/amdgpu: Fix potential out-of-bounds access in 'amdgpu_discovery_reg_base_init()' Date: Sun, 24 Mar 2024 18:29:41 -0400 Message-ID: <20240324223455.1342824-403-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Srinivasan Shanmugam [ Upstream commit cdb637d339572398821204a1142d8d615668f1e9 ] The issue arises when the array 'adev->vcn.vcn_config' is accessed before checking if the index 'adev->vcn.num_vcn_inst' is within the bounds of the array. The fix involves moving the bounds check before the array access. This ensures that 'adev->vcn.num_vcn_inst' is within the bounds of the array before it is used as an index. Fixes the below: drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1289 amdgpu_discovery_reg_bas= e_init() error: testing array offset 'adev->vcn.num_vcn_inst' after use. Fixes: a0ccc717c4ab ("drm/amdgpu/discovery: validate VCN and SDMA instances= ") Cc: Christian K=C3=B6nig Cc: Alex Deucher Signed-off-by: Srinivasan Shanmugam Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c b/drivers/gpu/dr= m/amd/amdgpu/amdgpu_discovery.c index c7d60dd0fb975..4f9900779ef9e 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c @@ -1278,11 +1278,10 @@ static int amdgpu_discovery_reg_base_init(struct am= dgpu_device *adev) * 0b10 : encode is disabled * 0b01 : decode is disabled */ - adev->vcn.vcn_config[adev->vcn.num_vcn_inst] =3D - ip->revision & 0xc0; - ip->revision &=3D ~0xc0; if (adev->vcn.num_vcn_inst < AMDGPU_MAX_VCN_INSTANCES) { + adev->vcn.vcn_config[adev->vcn.num_vcn_inst] =3D + ip->revision & 0xc0; adev->vcn.num_vcn_inst++; adev->vcn.inst_mask |=3D (1U << ip->instance_number); @@ -1293,6 +1292,7 @@ static int amdgpu_discovery_reg_base_init(struct amdg= pu_device *adev) adev->vcn.num_vcn_inst + 1, AMDGPU_MAX_VCN_INSTANCES); } + ip->revision &=3D ~0xc0; } if (le16_to_cpu(ip->hw_id) =3D=3D SDMA0_HWID || le16_to_cpu(ip->hw_id) =3D=3D SDMA1_HWID || --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4862B13CD46; Sun, 24 Mar 2024 22:41:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320095; cv=none; b=TPug+YOic6dto/XW1AcrdUOKPiaFF0204/cXEYILcceb4AhymNqDz2jx2TALIAwmXnyTsUDpzWdU4MTTszXbLlrDNwOxstXIqUSm/dUqd3RVBN4XNjhj7kAcSrVih16iA7qkLspqiNYV/BJri8Gw9pW5TWobUwhv9YVspIUqB4o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320095; c=relaxed/simple; bh=uIDSKaGEKevri4m+701P4fwqcj5BZkuhrTLKSp6QbB8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bKKpt4KiTGO6Ni7Sj/GftldMreztY3gtEJQ96KKnT2XuIcC+Ibpi1ZpJbEKxV1xfUkoPB2xk9XPydkPjVXqUvHkslLWusLpFCD69orKwnoPvvi9Ze0SuL8UWuj60s3x/Vxe/TrwPjBWRLunJWxaouEEIxXxRHjmtncjeZYSlTfg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TTzAKVvF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="TTzAKVvF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 020F3C433B2; Sun, 24 Mar 2024 22:41:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320094; bh=uIDSKaGEKevri4m+701P4fwqcj5BZkuhrTLKSp6QbB8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=TTzAKVvFLNTWyh6oKnkDYox+o/oKnErKjKOT4bizGs0t4Mf7mX0awz7Cb1t9HFiK3 dxgLtvNs+ZNTpAASukgAqpbjwjfCQ3N4AHIBPo81nRqBf5WaWs7s2cCn2IeufjIXqH buucZFVRBCVUTrJSFuiYKLJZ8E7msVurVqQh1unMPiISssPCUmmt3gHkdATTxEtpJ6 AkNEykNmk4nwuUye7DMgvEESYsC5cnld7Z56H2X0QZ+At54cudn5hSqqRwvWMIoja0 NN1mlOs7nlVuRY0H1ICl7cqZTSi3yGrxm6+qnhMhXBpqFDrMGg/wzGEGc+f5ob9m1Q 0rJVpqmginA9w== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Bryan O'Donoghue , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 403/715] clk: qcom: reset: Commonize the de/assert functions Date: Sun, 24 Mar 2024 18:29:42 -0400 Message-ID: <20240324223455.1342824-404-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit eda40d9c583e95e0b6ac69d2950eec10f802e0e8 ] They do the same thing, except the last argument of the last function call differs. Commonize them. Reviewed-by: Bryan O'Donoghue Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240105-topic-venus_reset-v2-2-c37eba13b5c= e@linaro.org Signed-off-by: Bjorn Andersson Stable-dep-of: 2f8cf2c3f3e3 ("clk: qcom: reset: Ensure write completion on = reset de/assertion") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/clk/qcom/reset.c | 22 +++++++++------------- 1 file changed, 9 insertions(+), 13 deletions(-) diff --git a/drivers/clk/qcom/reset.c b/drivers/clk/qcom/reset.c index e45e32804d2c7..20d1d35aaf229 100644 --- a/drivers/clk/qcom/reset.c +++ b/drivers/clk/qcom/reset.c @@ -22,8 +22,8 @@ static int qcom_reset(struct reset_controller_dev *rcdev,= unsigned long id) return 0; } =20 -static int -qcom_reset_assert(struct reset_controller_dev *rcdev, unsigned long id) +static int qcom_reset_set_assert(struct reset_controller_dev *rcdev, + unsigned long id, bool assert) { struct qcom_reset_controller *rst; const struct qcom_reset_map *map; @@ -33,21 +33,17 @@ qcom_reset_assert(struct reset_controller_dev *rcdev, u= nsigned long id) map =3D &rst->reset_map[id]; mask =3D map->bitmask ? map->bitmask : BIT(map->bit); =20 - return regmap_update_bits(rst->regmap, map->reg, mask, mask); + return regmap_update_bits(rst->regmap, map->reg, mask, assert ? mask : 0); } =20 -static int -qcom_reset_deassert(struct reset_controller_dev *rcdev, unsigned long id) +static int qcom_reset_assert(struct reset_controller_dev *rcdev, unsigned = long id) { - struct qcom_reset_controller *rst; - const struct qcom_reset_map *map; - u32 mask; - - rst =3D to_qcom_reset_controller(rcdev); - map =3D &rst->reset_map[id]; - mask =3D map->bitmask ? map->bitmask : BIT(map->bit); + return qcom_reset_set_assert(rcdev, id, true); +} =20 - return regmap_update_bits(rst->regmap, map->reg, mask, 0); +static int qcom_reset_deassert(struct reset_controller_dev *rcdev, unsigne= d long id) +{ + return qcom_reset_set_assert(rcdev, id, false); } =20 const struct reset_control_ops qcom_reset_ops =3D { --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3670813CD62; Sun, 24 Mar 2024 22:41:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320096; cv=none; b=HuC6n91nmgqOk/U4wgyd9zOqMAOkNU5P6z21BYyLApdayM64UMYHx7bmem4K4qKTIqiaAXLhVvqiI5ViWz26y0TXdLjNyXrwB+crJBkzNaxOsbDiiYokSJBUNQyezz1zmegJuzp1IX0Klw4JnfjVXdjTto/G0BnQfksDg4K2j3c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320096; c=relaxed/simple; bh=pCc5yRqiW7zrM8WJbTTAP0OTtZg+beqdp63g2hcZTaQ=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mLypyTdQxO9fUoeqegz230WeqbxYqDfDMGhQCB2+VF+SiFId9HsnN8CeJDOmBVcgl9EmWxiJxnRQTCpBFC2bqKomphG8UzF1SUb+sq5Bvuhj0l+HRluZXBEImu5bi+PozMLb4AMUbSJ6lZuO+uRmy9rZBTO4xb/ydVzWRSio1qM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=fFpr9L4z; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="fFpr9L4z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A651C433A6; Sun, 24 Mar 2024 22:41:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320095; bh=pCc5yRqiW7zrM8WJbTTAP0OTtZg+beqdp63g2hcZTaQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fFpr9L4zdcGREvzwDtMfzHUrpnDhIbFWq31PrdKeJApzNp1A4WpZcnHi0oHPPwPzh QCFnq4tGdKLUtGztkp5ikNz/cehOhDFOZbLaaSvIUPyn/uybX2CVJaw7yMUc6A/m+a FYWUTo/zXZqClNlUQBVz94+EzEM0bAnJAvPW30gZubBRmg++G8JEb2dBQV+Joo4wv/ Re3zovD7tyN0YTYxAcDKTK+BF9QohX622Z02nxrnonGv0VL11iJreFWg9CFMNVE0iv WX/M8EMj2hBf+oGASoaVA59zY3eRSy59y82nnmBufDR6QkuDfVQQTZ0CxdFTbO1/Rn Vd66j6E/LTkxw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Konrad Dybcio , Bjorn Andersson , Sasha Levin Subject: [PATCH 6.8 404/715] clk: qcom: reset: Ensure write completion on reset de/assertion Date: Sun, 24 Mar 2024 18:29:43 -0400 Message-ID: <20240324223455.1342824-405-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Konrad Dybcio [ Upstream commit 2f8cf2c3f3e3f7ef61bd19abb4b0bb797ad50aaf ] Trying to toggle the resets in a rapid fashion can lead to the changes not actually arriving at the clock controller block when we expect them to. This was observed at least on SM8250. Read back the value after regmap_update_bits to ensure write completion. Fixes: b36ba30c8ac6 ("clk: qcom: Add reset controller support") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240105-topic-venus_reset-v2-3-c37eba13b5c= e@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/clk/qcom/reset.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/clk/qcom/reset.c b/drivers/clk/qcom/reset.c index 20d1d35aaf229..d96c96a9089f4 100644 --- a/drivers/clk/qcom/reset.c +++ b/drivers/clk/qcom/reset.c @@ -33,7 +33,12 @@ static int qcom_reset_set_assert(struct reset_controller= _dev *rcdev, map =3D &rst->reset_map[id]; mask =3D map->bitmask ? map->bitmask : BIT(map->bit); =20 - return regmap_update_bits(rst->regmap, map->reg, mask, assert ? mask : 0); + regmap_update_bits(rst->regmap, map->reg, mask, assert ? mask : 0); + + /* Read back the register to ensure write completion, ignore the value */ + regmap_read(rst->regmap, map->reg, &mask); + + return 0; } =20 static int qcom_reset_assert(struct reset_controller_dev *rcdev, unsigned = long id) --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0A36713CD79; Sun, 24 Mar 2024 22:41:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320097; cv=none; b=qQwT4ERxnZV+gQpqpjVJxE/XH/SNRNXNwcx081zxFKGO8v+I6K0LH+DC8N2ECrcAbGLNu4ZifRwKrRbPJ/hbA6OUAtN8d6JASzSzcLLnxkP+KS5PZfdPL6YLn00sBFUjJiX8oB+RUu3Me92U59g2ECqqfDn3oOrHXHgDiaZvXu0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320097; c=relaxed/simple; bh=0eDmzwiJ2tuAvetp8jpKMf5xybhAnNzi90nuJyaK00c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=vGZB33+tNdGwchV4BYKl/DSTKc+6cNjIX1Ak6niuERoKAgTt4YdmFtE1ypFhBbNe7tnhkHfTowF5ikuGw54qjyY5I93ACLFhSo4HFra3tnCxaAY7js2V/E8dgpS9vmFo17+N16rxA5zG3MP5zEnsxXspM8ctax0rc8DLuLR8MOE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uXXC8a2k; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="uXXC8a2k" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E97E5C433F1; Sun, 24 Mar 2024 22:41:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320096; bh=0eDmzwiJ2tuAvetp8jpKMf5xybhAnNzi90nuJyaK00c=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=uXXC8a2kUB39Hjl+ztmoAW/1JPOTJ5KOyZrmdTEXzWVEZm6++qr+kUfpFUdBZd2Xd ZnIdkHvH4M21WTInMeyK/j/UhEx4jgAJo9tb0JE/QO/lJMyTAMhJzXQ/DL1Or4dNrk 0XuA/lOWSpWylQEfC1NUt1lN9lElb1tpAA0w4P2Qy+i3PSdlfZIaS0T+MVKyX0ajSo 34YJDUevyzo9M+M/M6j87GJc7ukRDz/d/oIWuDZbWVCfaNR0n51OLEN/po2WUuy7Q4 Gi7SKQh1+5fiiaEI+8Ul79evTMqGOJNB/l7HShbS5pXP2L3ZZyluuASTTCIlivJfC6 gcDj5VLXlHFrw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Wang Jianjian , Jan Kara , Sasha Levin Subject: [PATCH 6.8 405/715] quota: Fix potential NULL pointer dereference Date: Sun, 24 Mar 2024 18:29:44 -0400 Message-ID: <20240324223455.1342824-406-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Wang Jianjian [ Upstream commit d0aa72604fbd80c8aabb46eda00535ed35570f1f ] Below race may cause NULL pointer dereference P1 P2 dquot_free_inode quota_off drop_dquot_ref remove_dquot_ref dquots =3D i_dquot(inode) dquots =3D i_dquot(inode) srcu_read_lock dquots[cnt]) !=3D NULL (1) dquots[type] =3D NULL (2) spin_lock(&dquots[cnt]->dq_dqb_lock) (3) .... If dquot_free_inode(or other routines) checks inode's quota pointers (1) before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer dereference will be triggered. So let's fix it by using a temporary pointer to avoid this issue. Signed-off-by: Wang Jianjian Signed-off-by: Jan Kara Message-Id: <20240202081852.2514092-1-wangjianjian3@huawei.com> Stable-dep-of: 179b8c97ebf6 ("quota: Fix rcu annotations of inode dquot poi= nters") Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- fs/quota/dquot.c | 98 ++++++++++++++++++++++++++++-------------------- 1 file changed, 57 insertions(+), 41 deletions(-) diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c index 1f0c754416b64..cafe65a03f6dc 100644 --- a/fs/quota/dquot.c +++ b/fs/quota/dquot.c @@ -399,15 +399,17 @@ int dquot_mark_dquot_dirty(struct dquot *dquot) EXPORT_SYMBOL(dquot_mark_dquot_dirty); =20 /* Dirtify all the dquots - this can block when journalling */ -static inline int mark_all_dquot_dirty(struct dquot * const *dquot) +static inline int mark_all_dquot_dirty(struct dquot * const *dquots) { int ret, err, cnt; + struct dquot *dquot; =20 ret =3D err =3D 0; for (cnt =3D 0; cnt < MAXQUOTAS; cnt++) { - if (dquot[cnt]) + dquot =3D srcu_dereference(dquots[cnt], &dquot_srcu); + if (dquot) /* Even in case of error we have to continue */ - ret =3D mark_dquot_dirty(dquot[cnt]); + ret =3D mark_dquot_dirty(dquot); if (!err) err =3D ret; } @@ -1678,6 +1680,7 @@ int __dquot_alloc_space(struct inode *inode, qsize_t = number, int flags) struct dquot_warn warn[MAXQUOTAS]; int reserve =3D flags & DQUOT_SPACE_RESERVE; struct dquot **dquots; + struct dquot *dquot; =20 if (!inode_quota_active(inode)) { if (reserve) { @@ -1697,27 +1700,26 @@ int __dquot_alloc_space(struct inode *inode, qsize_= t number, int flags) index =3D srcu_read_lock(&dquot_srcu); spin_lock(&inode->i_lock); for (cnt =3D 0; cnt < MAXQUOTAS; cnt++) { - if (!dquots[cnt]) + dquot =3D srcu_dereference(dquots[cnt], &dquot_srcu); + if (!dquot) continue; if (reserve) { - ret =3D dquot_add_space(dquots[cnt], 0, number, flags, - &warn[cnt]); + ret =3D dquot_add_space(dquot, 0, number, flags, &warn[cnt]); } else { - ret =3D dquot_add_space(dquots[cnt], number, 0, flags, - &warn[cnt]); + ret =3D dquot_add_space(dquot, number, 0, flags, &warn[cnt]); } if (ret) { /* Back out changes we already did */ for (cnt--; cnt >=3D 0; cnt--) { - if (!dquots[cnt]) + dquot =3D srcu_dereference(dquots[cnt], &dquot_srcu); + if (!dquot) continue; - spin_lock(&dquots[cnt]->dq_dqb_lock); + spin_lock(&dquot->dq_dqb_lock); if (reserve) - dquot_free_reserved_space(dquots[cnt], - number); + dquot_free_reserved_space(dquot, number); else - dquot_decr_space(dquots[cnt], number); - spin_unlock(&dquots[cnt]->dq_dqb_lock); + dquot_decr_space(dquot, number); + spin_unlock(&dquot->dq_dqb_lock); } spin_unlock(&inode->i_lock); goto out_flush_warn; @@ -1748,6 +1750,7 @@ int dquot_alloc_inode(struct inode *inode) int cnt, ret =3D 0, index; struct dquot_warn warn[MAXQUOTAS]; struct dquot * const *dquots; + struct dquot *dquot; =20 if (!inode_quota_active(inode)) return 0; @@ -1758,17 +1761,19 @@ int dquot_alloc_inode(struct inode *inode) index =3D srcu_read_lock(&dquot_srcu); spin_lock(&inode->i_lock); for (cnt =3D 0; cnt < MAXQUOTAS; cnt++) { - if (!dquots[cnt]) + dquot =3D srcu_dereference(dquots[cnt], &dquot_srcu); + if (!dquot) continue; - ret =3D dquot_add_inodes(dquots[cnt], 1, &warn[cnt]); + ret =3D dquot_add_inodes(dquot, 1, &warn[cnt]); if (ret) { for (cnt--; cnt >=3D 0; cnt--) { - if (!dquots[cnt]) + dquot =3D srcu_dereference(dquots[cnt], &dquot_srcu); + if (!dquot) continue; /* Back out changes we already did */ - spin_lock(&dquots[cnt]->dq_dqb_lock); - dquot_decr_inodes(dquots[cnt], 1); - spin_unlock(&dquots[cnt]->dq_dqb_lock); + spin_lock(&dquot->dq_dqb_lock); + dquot_decr_inodes(dquot, 1); + spin_unlock(&dquot->dq_dqb_lock); } goto warn_put_all; } @@ -1790,6 +1795,7 @@ EXPORT_SYMBOL(dquot_alloc_inode); void dquot_claim_space_nodirty(struct inode *inode, qsize_t number) { struct dquot **dquots; + struct dquot *dquot; int cnt, index; =20 if (!inode_quota_active(inode)) { @@ -1805,9 +1811,8 @@ void dquot_claim_space_nodirty(struct inode *inode, q= size_t number) spin_lock(&inode->i_lock); /* Claim reserved quotas to allocated quotas */ for (cnt =3D 0; cnt < MAXQUOTAS; cnt++) { - if (dquots[cnt]) { - struct dquot *dquot =3D dquots[cnt]; - + dquot =3D srcu_dereference(dquots[cnt], &dquot_srcu); + if (dquot) { spin_lock(&dquot->dq_dqb_lock); if (WARN_ON_ONCE(dquot->dq_dqb.dqb_rsvspace < number)) number =3D dquot->dq_dqb.dqb_rsvspace; @@ -1832,6 +1837,7 @@ EXPORT_SYMBOL(dquot_claim_space_nodirty); void dquot_reclaim_space_nodirty(struct inode *inode, qsize_t number) { struct dquot **dquots; + struct dquot *dquot; int cnt, index; =20 if (!inode_quota_active(inode)) { @@ -1847,9 +1853,8 @@ void dquot_reclaim_space_nodirty(struct inode *inode,= qsize_t number) spin_lock(&inode->i_lock); /* Claim reserved quotas to allocated quotas */ for (cnt =3D 0; cnt < MAXQUOTAS; cnt++) { - if (dquots[cnt]) { - struct dquot *dquot =3D dquots[cnt]; - + dquot =3D srcu_dereference(dquots[cnt], &dquot_srcu); + if (dquot) { spin_lock(&dquot->dq_dqb_lock); if (WARN_ON_ONCE(dquot->dq_dqb.dqb_curspace < number)) number =3D dquot->dq_dqb.dqb_curspace; @@ -1876,6 +1881,7 @@ void __dquot_free_space(struct inode *inode, qsize_t = number, int flags) unsigned int cnt; struct dquot_warn warn[MAXQUOTAS]; struct dquot **dquots; + struct dquot *dquot; int reserve =3D flags & DQUOT_SPACE_RESERVE, index; =20 if (!inode_quota_active(inode)) { @@ -1896,17 +1902,18 @@ void __dquot_free_space(struct inode *inode, qsize_= t number, int flags) int wtype; =20 warn[cnt].w_type =3D QUOTA_NL_NOWARN; - if (!dquots[cnt]) + dquot =3D srcu_dereference(dquots[cnt], &dquot_srcu); + if (!dquot) continue; - spin_lock(&dquots[cnt]->dq_dqb_lock); - wtype =3D info_bdq_free(dquots[cnt], number); + spin_lock(&dquot->dq_dqb_lock); + wtype =3D info_bdq_free(dquot, number); if (wtype !=3D QUOTA_NL_NOWARN) - prepare_warning(&warn[cnt], dquots[cnt], wtype); + prepare_warning(&warn[cnt], dquot, wtype); if (reserve) - dquot_free_reserved_space(dquots[cnt], number); + dquot_free_reserved_space(dquot, number); else - dquot_decr_space(dquots[cnt], number); - spin_unlock(&dquots[cnt]->dq_dqb_lock); + dquot_decr_space(dquot, number); + spin_unlock(&dquot->dq_dqb_lock); } if (reserve) *inode_reserved_space(inode) -=3D number; @@ -1931,6 +1938,7 @@ void dquot_free_inode(struct inode *inode) unsigned int cnt; struct dquot_warn warn[MAXQUOTAS]; struct dquot * const *dquots; + struct dquot *dquot; int index; =20 if (!inode_quota_active(inode)) @@ -1941,16 +1949,16 @@ void dquot_free_inode(struct inode *inode) spin_lock(&inode->i_lock); for (cnt =3D 0; cnt < MAXQUOTAS; cnt++) { int wtype; - warn[cnt].w_type =3D QUOTA_NL_NOWARN; - if (!dquots[cnt]) + dquot =3D srcu_dereference(dquots[cnt], &dquot_srcu); + if (!dquot) continue; - spin_lock(&dquots[cnt]->dq_dqb_lock); - wtype =3D info_idq_free(dquots[cnt], 1); + spin_lock(&dquot->dq_dqb_lock); + wtype =3D info_idq_free(dquot, 1); if (wtype !=3D QUOTA_NL_NOWARN) - prepare_warning(&warn[cnt], dquots[cnt], wtype); - dquot_decr_inodes(dquots[cnt], 1); - spin_unlock(&dquots[cnt]->dq_dqb_lock); + prepare_warning(&warn[cnt], dquot, wtype); + dquot_decr_inodes(dquot, 1); + spin_unlock(&dquot->dq_dqb_lock); } spin_unlock(&inode->i_lock); mark_all_dquot_dirty(dquots); @@ -1977,7 +1985,7 @@ int __dquot_transfer(struct inode *inode, struct dquo= t **transfer_to) qsize_t rsv_space =3D 0; qsize_t inode_usage =3D 1; struct dquot *transfer_from[MAXQUOTAS] =3D {}; - int cnt, ret =3D 0; + int cnt, index, ret =3D 0; char is_valid[MAXQUOTAS] =3D {}; struct dquot_warn warn_to[MAXQUOTAS]; struct dquot_warn warn_from_inodes[MAXQUOTAS]; @@ -2066,8 +2074,16 @@ int __dquot_transfer(struct inode *inode, struct dqu= ot **transfer_to) spin_unlock(&inode->i_lock); spin_unlock(&dq_data_lock); =20 + /* + * These arrays are local and we hold dquot references so we don't need + * the srcu protection but still take dquot_srcu to avoid warning in + * mark_all_dquot_dirty(). + */ + index =3D srcu_read_lock(&dquot_srcu); mark_all_dquot_dirty(transfer_from); mark_all_dquot_dirty(transfer_to); + srcu_read_unlock(&dquot_srcu, index); + flush_warnings(warn_to); flush_warnings(warn_from_inodes); flush_warnings(warn_from_space); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 96CE218FC60; Sun, 24 Mar 2024 22:41:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320097; cv=none; b=WsGPN6Hf5XKVr67dCNeI2EJTC0opf1ACIBzJiLTFi4JC9b59RBkWMvUKZoVm3tTHGbEAYuysE1Cdn7EnOT+TQisL1UZ88Sw/kDii6IzKQw+NMeLttYTYnYcSrGl2qMjt4LvBT4ZnDo+Z/+MQThNEu/uFgIrtKgABmnuNltE39rM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320097; c=relaxed/simple; bh=L00GR57LbLXh8v9JiTDBUUA4MvkNwiyP7Ul9BL+Soss=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IC8aSDp28I80Kc84qwDHPSO2MpW40sH9goAJJsVX9K9QJdHP4pZQ4cjNrUa14DwZBeNTlnLZfNKC737S9K5mjAs5Vu+v8JbXc6ofji9gV3eX9MYn8xOL4rImUaTO9ZmDvLZUyvQR+QK7rcS5AVq4aEfGkQuSHTY4T6Pemqp/s8M= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HflbvaO5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="HflbvaO5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D3F57C43394; Sun, 24 Mar 2024 22:41:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320097; bh=L00GR57LbLXh8v9JiTDBUUA4MvkNwiyP7Ul9BL+Soss=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HflbvaO5LyX4BBkxXNsYlGUazQamu/rOgaF4rd0J8HHTt8MKecvrDMLqCh7aQIdQX qv4GnjGuo6I3zBvbX6MERXjyRcd8JwtzlhBIDXn1fK72D1sQv21AJ+vfqZB/X24jVe J492pgQ9PpVrLowzJpQc8WyJHPJiWdNdMxaFcIh1z1hvTstF6fE/mYJgtXAeySNdG4 FeHTv/Jpzgz9m2xfg3y3QI1RyCjdnDlqHuItFBJxtSUWTGMiAlF4DpgJQWRuBkKelv 7MILnARF0zijGhw3E9MjMkUj6aDMkOiMPEqXlyBWjU9HJhxdhTxsOgMPQhKLdP4cTw WdZzsJkEp89ew== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jan Kara , kernel test robot , Sasha Levin Subject: [PATCH 6.8 406/715] quota: Fix rcu annotations of inode dquot pointers Date: Sun, 24 Mar 2024 18:29:45 -0400 Message-ID: <20240324223455.1342824-407-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jan Kara [ Upstream commit 179b8c97ebf63429589f5afeba59a181fe70603e ] Dquot pointers in i_dquot array in the inode are protected by dquot_srcu. Annotate the array pointers with __rcu, perform the locked dereferences with srcu_dereference_check() instead of plain reads, and set the array elements with rcu_assign_pointer(). Fixes: b9ba6f94b238 ("quota: remove dqptr_sem") Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202402061900.rTuYDlo6-lkp@int= el.com/ Signed-off-by: Jan Kara Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- fs/quota/dquot.c | 66 ++++++++++++++++++++++++++++-------------------- 1 file changed, 39 insertions(+), 27 deletions(-) diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c index cafe65a03f6dc..3a16867a6fbde 100644 --- a/fs/quota/dquot.c +++ b/fs/quota/dquot.c @@ -399,7 +399,7 @@ int dquot_mark_dquot_dirty(struct dquot *dquot) EXPORT_SYMBOL(dquot_mark_dquot_dirty); =20 /* Dirtify all the dquots - this can block when journalling */ -static inline int mark_all_dquot_dirty(struct dquot * const *dquots) +static inline int mark_all_dquot_dirty(struct dquot __rcu * const *dquots) { int ret, err, cnt; struct dquot *dquot; @@ -1000,14 +1000,15 @@ struct dquot *dqget(struct super_block *sb, struct = kqid qid) } EXPORT_SYMBOL(dqget); =20 -static inline struct dquot **i_dquot(struct inode *inode) +static inline struct dquot __rcu **i_dquot(struct inode *inode) { - return inode->i_sb->s_op->get_dquots(inode); + /* Force __rcu for now until filesystems are fixed */ + return (struct dquot __rcu **)inode->i_sb->s_op->get_dquots(inode); } =20 static int dqinit_needed(struct inode *inode, int type) { - struct dquot * const *dquots; + struct dquot __rcu * const *dquots; int cnt; =20 if (IS_NOQUOTA(inode)) @@ -1097,14 +1098,16 @@ static void remove_dquot_ref(struct super_block *sb= , int type) */ spin_lock(&dq_data_lock); if (!IS_NOQUOTA(inode)) { - struct dquot **dquots =3D i_dquot(inode); - struct dquot *dquot =3D dquots[type]; + struct dquot __rcu **dquots =3D i_dquot(inode); + struct dquot *dquot =3D srcu_dereference_check( + dquots[type], &dquot_srcu, + lockdep_is_held(&dq_data_lock)); =20 #ifdef CONFIG_QUOTA_DEBUG if (unlikely(inode_get_rsv_space(inode) > 0)) reserved =3D 1; #endif - dquots[type] =3D NULL; + rcu_assign_pointer(dquots[type], NULL); if (dquot) dqput(dquot); } @@ -1457,7 +1460,8 @@ static int inode_quota_active(const struct inode *ino= de) static int __dquot_initialize(struct inode *inode, int type) { int cnt, init_needed =3D 0; - struct dquot **dquots, *got[MAXQUOTAS] =3D {}; + struct dquot __rcu **dquots; + struct dquot *got[MAXQUOTAS] =3D {}; struct super_block *sb =3D inode->i_sb; qsize_t rsv; int ret =3D 0; @@ -1532,7 +1536,7 @@ static int __dquot_initialize(struct inode *inode, in= t type) if (!got[cnt]) continue; if (!dquots[cnt]) { - dquots[cnt] =3D got[cnt]; + rcu_assign_pointer(dquots[cnt], got[cnt]); got[cnt] =3D NULL; /* * Make quota reservation system happy if someone @@ -1540,12 +1544,16 @@ static int __dquot_initialize(struct inode *inode, = int type) */ rsv =3D inode_get_rsv_space(inode); if (unlikely(rsv)) { + struct dquot *dquot =3D srcu_dereference_check( + dquots[cnt], &dquot_srcu, + lockdep_is_held(&dq_data_lock)); + spin_lock(&inode->i_lock); /* Get reservation again under proper lock */ rsv =3D __inode_get_rsv_space(inode); - spin_lock(&dquots[cnt]->dq_dqb_lock); - dquots[cnt]->dq_dqb.dqb_rsvspace +=3D rsv; - spin_unlock(&dquots[cnt]->dq_dqb_lock); + spin_lock(&dquot->dq_dqb_lock); + dquot->dq_dqb.dqb_rsvspace +=3D rsv; + spin_unlock(&dquot->dq_dqb_lock); spin_unlock(&inode->i_lock); } } @@ -1567,7 +1575,7 @@ EXPORT_SYMBOL(dquot_initialize); =20 bool dquot_initialize_needed(struct inode *inode) { - struct dquot **dquots; + struct dquot __rcu **dquots; int i; =20 if (!inode_quota_active(inode)) @@ -1592,13 +1600,14 @@ EXPORT_SYMBOL(dquot_initialize_needed); static void __dquot_drop(struct inode *inode) { int cnt; - struct dquot **dquots =3D i_dquot(inode); + struct dquot __rcu **dquots =3D i_dquot(inode); struct dquot *put[MAXQUOTAS]; =20 spin_lock(&dq_data_lock); for (cnt =3D 0; cnt < MAXQUOTAS; cnt++) { - put[cnt] =3D dquots[cnt]; - dquots[cnt] =3D NULL; + put[cnt] =3D srcu_dereference_check(dquots[cnt], &dquot_srcu, + lockdep_is_held(&dq_data_lock)); + rcu_assign_pointer(dquots[cnt], NULL); } spin_unlock(&dq_data_lock); dqput_all(put); @@ -1606,7 +1615,7 @@ static void __dquot_drop(struct inode *inode) =20 void dquot_drop(struct inode *inode) { - struct dquot * const *dquots; + struct dquot __rcu * const *dquots; int cnt; =20 if (IS_NOQUOTA(inode)) @@ -1679,7 +1688,7 @@ int __dquot_alloc_space(struct inode *inode, qsize_t = number, int flags) int cnt, ret =3D 0, index; struct dquot_warn warn[MAXQUOTAS]; int reserve =3D flags & DQUOT_SPACE_RESERVE; - struct dquot **dquots; + struct dquot __rcu **dquots; struct dquot *dquot; =20 if (!inode_quota_active(inode)) { @@ -1749,7 +1758,7 @@ int dquot_alloc_inode(struct inode *inode) { int cnt, ret =3D 0, index; struct dquot_warn warn[MAXQUOTAS]; - struct dquot * const *dquots; + struct dquot __rcu * const *dquots; struct dquot *dquot; =20 if (!inode_quota_active(inode)) @@ -1794,7 +1803,7 @@ EXPORT_SYMBOL(dquot_alloc_inode); */ void dquot_claim_space_nodirty(struct inode *inode, qsize_t number) { - struct dquot **dquots; + struct dquot __rcu **dquots; struct dquot *dquot; int cnt, index; =20 @@ -1836,7 +1845,7 @@ EXPORT_SYMBOL(dquot_claim_space_nodirty); */ void dquot_reclaim_space_nodirty(struct inode *inode, qsize_t number) { - struct dquot **dquots; + struct dquot __rcu **dquots; struct dquot *dquot; int cnt, index; =20 @@ -1880,7 +1889,7 @@ void __dquot_free_space(struct inode *inode, qsize_t = number, int flags) { unsigned int cnt; struct dquot_warn warn[MAXQUOTAS]; - struct dquot **dquots; + struct dquot __rcu **dquots; struct dquot *dquot; int reserve =3D flags & DQUOT_SPACE_RESERVE, index; =20 @@ -1937,7 +1946,7 @@ void dquot_free_inode(struct inode *inode) { unsigned int cnt; struct dquot_warn warn[MAXQUOTAS]; - struct dquot * const *dquots; + struct dquot __rcu * const *dquots; struct dquot *dquot; int index; =20 @@ -1984,6 +1993,7 @@ int __dquot_transfer(struct inode *inode, struct dquo= t **transfer_to) qsize_t cur_space; qsize_t rsv_space =3D 0; qsize_t inode_usage =3D 1; + struct dquot __rcu **dquots; struct dquot *transfer_from[MAXQUOTAS] =3D {}; int cnt, index, ret =3D 0; char is_valid[MAXQUOTAS] =3D {}; @@ -2016,6 +2026,7 @@ int __dquot_transfer(struct inode *inode, struct dquo= t **transfer_to) } cur_space =3D __inode_get_bytes(inode); rsv_space =3D __inode_get_rsv_space(inode); + dquots =3D i_dquot(inode); /* * Build the transfer_from list, check limits, and update usage in * the target structures. @@ -2030,7 +2041,8 @@ int __dquot_transfer(struct inode *inode, struct dquo= t **transfer_to) if (!sb_has_quota_active(inode->i_sb, cnt)) continue; is_valid[cnt] =3D 1; - transfer_from[cnt] =3D i_dquot(inode)[cnt]; + transfer_from[cnt] =3D srcu_dereference_check(dquots[cnt], + &dquot_srcu, lockdep_is_held(&dq_data_lock)); ret =3D dquot_add_inodes(transfer_to[cnt], inode_usage, &warn_to[cnt]); if (ret) @@ -2069,7 +2081,7 @@ int __dquot_transfer(struct inode *inode, struct dquo= t **transfer_to) rsv_space); spin_unlock(&transfer_from[cnt]->dq_dqb_lock); } - i_dquot(inode)[cnt] =3D transfer_to[cnt]; + rcu_assign_pointer(dquots[cnt], transfer_to[cnt]); } spin_unlock(&inode->i_lock); spin_unlock(&dq_data_lock); @@ -2080,8 +2092,8 @@ int __dquot_transfer(struct inode *inode, struct dquo= t **transfer_to) * mark_all_dquot_dirty(). */ index =3D srcu_read_lock(&dquot_srcu); - mark_all_dquot_dirty(transfer_from); - mark_all_dquot_dirty(transfer_to); + mark_all_dquot_dirty((struct dquot __rcu **)transfer_from); + mark_all_dquot_dirty((struct dquot __rcu **)transfer_to); srcu_read_unlock(&dquot_srcu, index); =20 flush_warnings(warn_to); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B366318FC83; Sun, 24 Mar 2024 22:41:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320098; cv=none; b=L6n37doSrE0q2RiDv2Xck16tEbPyhL22Nh3azGSGMnBTKwf7WF4AutYdTTqFH3QWrvURlojk8I+Z9dIRrhELU2Xo52GPIPRj1wqYhZpZnR40/Wev/vHXgmmN138Ur/y4x4MVsbz95eeQxZ4mFmlS29ZE98gVP4fTSouQ07IOZY4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320098; c=relaxed/simple; bh=8K/eoN4S2BQ1fHMWvNDdH6FWWOioaSD9KjArBunDFS0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FKLENMKRTYj/+8ThlUN0UyLG+8GJT0RtcjNc7FPLxi7VYtD8SGYSCBumejM9AsSKNpq2wTRwU/jcZI7ifFUpLar1N9P8R/q8RxcGRveaR+tuUIoiueyYfbEWD6CMbwpNZPyiWdelMfVC8J1SB3JIkfjW6gSzjS0K+X0J6t0yk6A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=McIkzjyk; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="McIkzjyk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD49AC433C7; Sun, 24 Mar 2024 22:41:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320098; bh=8K/eoN4S2BQ1fHMWvNDdH6FWWOioaSD9KjArBunDFS0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=McIkzjykJNdAEF5m2nBVC01phIkyyp9T5VeFGoMhoZOJ0GJmJn+FMXAC4vwYSLy6r f3t6rFBzmIeYuCB6maJUPbvm5yAT3ozT+vtaIYaQ42HhP9zf70Z95gpkNkaPjF1Fs1 Fud1q33k0yK9X7IQg4VoCIvaCYmEgUQFOiG3lRs7nPptHe928kLdBhHMsyjkfRqsKy sHXcjcc29SV+RLbSuL5E1eWBKC1KqqIUAnWh5z8jc+iXOLCxbHo+/hMuvroz4VuGTV zbfp1ZblixJH8ee8+cWr/ypIRn5ZDT8oh0xaIhuFGTharcdKM6zt8iGtYp4a8AxYyd 2I2Blo6qSWyGQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Jan Kara , Sasha Levin Subject: [PATCH 6.8 407/715] quota: Properly annotate i_dquot arrays with __rcu Date: Sun, 24 Mar 2024 18:29:46 -0400 Message-ID: <20240324223455.1342824-408-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Jan Kara [ Upstream commit ccb49011bb2ebfd66164dbf68c5bff48917bb5ef ] Dquots pointed to from i_dquot arrays in inodes are protected by dquot_srcu. Annotate them as such and change .get_dquots callback to return properly annotated pointer to make sparse happy. Fixes: b9ba6f94b238 ("quota: remove dqptr_sem") Signed-off-by: Jan Kara Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- fs/ext2/ext2.h | 2 +- fs/ext2/super.c | 2 +- fs/ext4/ext4.h | 2 +- fs/ext4/super.c | 2 +- fs/f2fs/f2fs.h | 2 +- fs/f2fs/super.c | 2 +- fs/jfs/jfs_incore.h | 2 +- fs/jfs/super.c | 2 +- fs/ocfs2/inode.h | 2 +- fs/ocfs2/super.c | 2 +- fs/quota/dquot.c | 3 +-- fs/reiserfs/reiserfs.h | 2 +- fs/reiserfs/super.c | 2 +- include/linux/fs.h | 2 +- include/linux/shmem_fs.h | 2 +- mm/shmem.c | 2 +- 16 files changed, 16 insertions(+), 17 deletions(-) diff --git a/fs/ext2/ext2.h b/fs/ext2/ext2.h index 677a9ad45dcb7..f38bdd46e4f77 100644 --- a/fs/ext2/ext2.h +++ b/fs/ext2/ext2.h @@ -674,7 +674,7 @@ struct ext2_inode_info { struct inode vfs_inode; struct list_head i_orphan; /* unlinked but open inodes */ #ifdef CONFIG_QUOTA - struct dquot *i_dquot[MAXQUOTAS]; + struct dquot __rcu *i_dquot[MAXQUOTAS]; #endif }; =20 diff --git a/fs/ext2/super.c b/fs/ext2/super.c index 01f9addc8b1f6..6d8587505cea3 100644 --- a/fs/ext2/super.c +++ b/fs/ext2/super.c @@ -320,7 +320,7 @@ static ssize_t ext2_quota_read(struct super_block *sb, = int type, char *data, siz static ssize_t ext2_quota_write(struct super_block *sb, int type, const ch= ar *data, size_t len, loff_t off); static int ext2_quota_on(struct super_block *sb, int type, int format_id, const struct path *path); -static struct dquot **ext2_get_dquots(struct inode *inode) +static struct dquot __rcu **ext2_get_dquots(struct inode *inode) { return EXT2_I(inode)->i_dquot; } diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h index 023571f8dd1b4..4fb938ba3f359 100644 --- a/fs/ext4/ext4.h +++ b/fs/ext4/ext4.h @@ -1158,7 +1158,7 @@ struct ext4_inode_info { tid_t i_datasync_tid; =20 #ifdef CONFIG_QUOTA - struct dquot *i_dquot[MAXQUOTAS]; + struct dquot __rcu *i_dquot[MAXQUOTAS]; #endif =20 /* Precomputed uuid+inum+igen checksum for seeding inode checksums */ diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 0f931d0c227da..32bd83adf0bb8 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -1600,7 +1600,7 @@ static ssize_t ext4_quota_write(struct super_block *s= b, int type, static int ext4_quota_enable(struct super_block *sb, int type, int format_= id, unsigned int flags); =20 -static struct dquot **ext4_get_dquots(struct inode *inode) +static struct dquot __rcu **ext4_get_dquots(struct inode *inode) { return EXT4_I(inode)->i_dquot; } diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h index 65294e3b0bef8..31554e2a0a320 100644 --- a/fs/f2fs/f2fs.h +++ b/fs/f2fs/f2fs.h @@ -829,7 +829,7 @@ struct f2fs_inode_info { spinlock_t i_size_lock; /* protect last_disk_size */ =20 #ifdef CONFIG_QUOTA - struct dquot *i_dquot[MAXQUOTAS]; + struct dquot __rcu *i_dquot[MAXQUOTAS]; =20 /* quota space reservation, managed internally by quota code */ qsize_t i_reserved_quota; diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c index d45ab0992ae59..18cc4829f7e82 100644 --- a/fs/f2fs/super.c +++ b/fs/f2fs/super.c @@ -2768,7 +2768,7 @@ int f2fs_dquot_initialize(struct inode *inode) return dquot_initialize(inode); } =20 -static struct dquot **f2fs_get_dquots(struct inode *inode) +static struct dquot __rcu **f2fs_get_dquots(struct inode *inode) { return F2FS_I(inode)->i_dquot; } diff --git a/fs/jfs/jfs_incore.h b/fs/jfs/jfs_incore.h index dd4264aa9bedd..10934f9a11be3 100644 --- a/fs/jfs/jfs_incore.h +++ b/fs/jfs/jfs_incore.h @@ -92,7 +92,7 @@ struct jfs_inode_info { } link; } u; #ifdef CONFIG_QUOTA - struct dquot *i_dquot[MAXQUOTAS]; + struct dquot __rcu *i_dquot[MAXQUOTAS]; #endif u32 dev; /* will die when we get wide dev_t */ struct inode vfs_inode; diff --git a/fs/jfs/super.c b/fs/jfs/super.c index 8d8e556bd6104..ff135a43b5b7b 100644 --- a/fs/jfs/super.c +++ b/fs/jfs/super.c @@ -824,7 +824,7 @@ static ssize_t jfs_quota_write(struct super_block *sb, = int type, return len - towrite; } =20 -static struct dquot **jfs_get_dquots(struct inode *inode) +static struct dquot __rcu **jfs_get_dquots(struct inode *inode) { return JFS_IP(inode)->i_dquot; } diff --git a/fs/ocfs2/inode.h b/fs/ocfs2/inode.h index 82b28fdacc7e9..accf03d4765ed 100644 --- a/fs/ocfs2/inode.h +++ b/fs/ocfs2/inode.h @@ -65,7 +65,7 @@ struct ocfs2_inode_info tid_t i_sync_tid; tid_t i_datasync_tid; =20 - struct dquot *i_dquot[MAXQUOTAS]; + struct dquot __rcu *i_dquot[MAXQUOTAS]; }; =20 /* diff --git a/fs/ocfs2/super.c b/fs/ocfs2/super.c index 6b906424902b4..1259fe02cd53b 100644 --- a/fs/ocfs2/super.c +++ b/fs/ocfs2/super.c @@ -122,7 +122,7 @@ static int ocfs2_susp_quotas(struct ocfs2_super *osb, i= nt unsuspend); static int ocfs2_enable_quotas(struct ocfs2_super *osb); static void ocfs2_disable_quotas(struct ocfs2_super *osb); =20 -static struct dquot **ocfs2_get_dquots(struct inode *inode) +static struct dquot __rcu **ocfs2_get_dquots(struct inode *inode) { return OCFS2_I(inode)->i_dquot; } diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c index 3a16867a6fbde..51ff554dc875a 100644 --- a/fs/quota/dquot.c +++ b/fs/quota/dquot.c @@ -1002,8 +1002,7 @@ EXPORT_SYMBOL(dqget); =20 static inline struct dquot __rcu **i_dquot(struct inode *inode) { - /* Force __rcu for now until filesystems are fixed */ - return (struct dquot __rcu **)inode->i_sb->s_op->get_dquots(inode); + return inode->i_sb->s_op->get_dquots(inode); } =20 static int dqinit_needed(struct inode *inode, int type) diff --git a/fs/reiserfs/reiserfs.h b/fs/reiserfs/reiserfs.h index 725667880e626..b65549164590c 100644 --- a/fs/reiserfs/reiserfs.h +++ b/fs/reiserfs/reiserfs.h @@ -97,7 +97,7 @@ struct reiserfs_inode_info { struct rw_semaphore i_xattr_sem; #endif #ifdef CONFIG_QUOTA - struct dquot *i_dquot[MAXQUOTAS]; + struct dquot __rcu *i_dquot[MAXQUOTAS]; #endif =20 struct inode vfs_inode; diff --git a/fs/reiserfs/super.c b/fs/reiserfs/super.c index 67b5510beded2..7b3d5aeb2a6fe 100644 --- a/fs/reiserfs/super.c +++ b/fs/reiserfs/super.c @@ -802,7 +802,7 @@ static ssize_t reiserfs_quota_write(struct super_block = *, int, const char *, static ssize_t reiserfs_quota_read(struct super_block *, int, char *, size= _t, loff_t); =20 -static struct dquot **reiserfs_get_dquots(struct inode *inode) +static struct dquot __rcu **reiserfs_get_dquots(struct inode *inode) { return REISERFS_I(inode)->i_dquot; } diff --git a/include/linux/fs.h b/include/linux/fs.h index 630468c005040..08ecac9d7b8ba 100644 --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -2158,7 +2158,7 @@ struct super_operations { #ifdef CONFIG_QUOTA ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t); ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, l= off_t); - struct dquot **(*get_dquots)(struct inode *); + struct dquot __rcu **(*get_dquots)(struct inode *); #endif long (*nr_cached_objects)(struct super_block *, struct shrink_control *); diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h index 2caa6b86106aa..66828dfc6e74e 100644 --- a/include/linux/shmem_fs.h +++ b/include/linux/shmem_fs.h @@ -37,7 +37,7 @@ struct shmem_inode_info { unsigned int fsflags; /* for FS_IOC_[SG]ETFLAGS */ atomic_t stop_eviction; /* hold when working on inode */ #ifdef CONFIG_TMPFS_QUOTA - struct dquot *i_dquot[MAXQUOTAS]; + struct dquot __rcu *i_dquot[MAXQUOTAS]; #endif struct inode vfs_inode; }; diff --git a/mm/shmem.c b/mm/shmem.c index d7c84ff621860..791a6dc163244 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -311,7 +311,7 @@ static void shmem_disable_quotas(struct super_block *sb) dquot_quota_off(sb, type); } =20 -static struct dquot **shmem_get_dquots(struct inode *inode) +static struct dquot __rcu **shmem_get_dquots(struct inode *inode) { return SHMEM_I(inode)->i_dquot; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC57713CD46; Sun, 24 Mar 2024 22:41:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320099; cv=none; b=Q5Ot2sd/o89x3Ixt8f+PWVKxDIbw4WMlHcK8rXrji/N61QMCwHgzRf9h21GJ2G/eHuO1EMNsCJ0DvAMfHYq+f8InGvmVVpMxoah++P704z+Q+dcYNL5OxSvLnQrKbLBlXt5/uY8qI/HvI+QZxdyRTLI4ETu3/JEib9YD/KJWgnU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320099; c=relaxed/simple; bh=9JjK2PeRONgGDalNPKjTIIzQS2I0VNpFKGvX2wf6ss4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NL8+/fw8SO48EgeMmpGWrR1VtniNk/Mr0/AiaRZPqXcuQm/v+2sif0kzHN6q0t+x0lSkFMmLuIG+G7IADw9NBm12yjTzhD1HoiFp/23Eu7Ckmdu4+YqsTUj3Gx3m/Ecy2/+xgrcc4ZzOPEPd/6bT5+CBF1wRHope0lgEFy21soc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SJJ26Oix; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SJJ26Oix" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E87EC43394; Sun, 24 Mar 2024 22:41:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320099; bh=9JjK2PeRONgGDalNPKjTIIzQS2I0VNpFKGvX2wf6ss4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SJJ26OixraH+sjTvMnzy8iTRsFxTDksYHc+SxyVS6l+K1zpYi9718ALmUY/LacTTF akicBgfs39wPljsfbri5coDlBBJQezDjWHL97hDW1ztf+9gt2Jr9GewhvCicx0CeDW RWAxG7ysv6VsoKG2w5uebAl4BxmOPCYOHoqxI417toKIB5aAF+PQcg5JY/Wcxl67Cf f2/Sb5LxV4RfJeUjk/u3nB6Gw+ySzPTmWar90hfG8cVM86lajJ81Y6wjoIoErNwf+f JRFzNPA32rHfqiiY/sxb5rBC/Te1QvxpRHmKpdxEcbbrBdD9MoAEHmh5+PwxJJELT7 SE41VXjyisU7g== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Charles Keepax , Bard Liao , =?UTF-8?q?P=C3=A9ter=20Ujfalusi?= , Pierre-Louis Bossart , Mark Brown , Sasha Levin Subject: [PATCH 6.8 408/715] ASoC: Intel: ssp-common: Add stub for sof_ssp_get_codec_name Date: Sun, 24 Mar 2024 18:29:47 -0400 Message-ID: <20240324223455.1342824-409-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable From: Charles Keepax [ Upstream commit c1469c3a8a306e5f1eab1ae9585640d08e183f87 ] As this function is now used in sof_board_helpers it requires a build stub for the case SSP_COMMON is not built in. Fixes: ba0c7c328762 ("ASoC: Intel: board_helpers: support amp link initiali= zation") Reviewed-by: Bard Liao Reviewed-by: P=C3=A9ter Ujfalusi Signed-off-by: Charles Keepax Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20240208165545.93811-21-pierre-louis.bossar= t@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- sound/soc/intel/boards/sof_ssp_common.h | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/sound/soc/intel/boards/sof_ssp_common.h b/sound/soc/intel/boar= ds/sof_ssp_common.h index 6d827103479b5..d24888bc99fde 100644 --- a/sound/soc/intel/boards/sof_ssp_common.h +++ b/sound/soc/intel/boards/sof_ssp_common.h @@ -67,6 +67,14 @@ enum sof_ssp_codec { =20 enum sof_ssp_codec sof_ssp_detect_codec_type(struct device *dev); enum sof_ssp_codec sof_ssp_detect_amp_type(struct device *dev); + +#if IS_ENABLED(CONFIG_SND_SOC_INTEL_SOF_SSP_COMMON) const char *sof_ssp_get_codec_name(enum sof_ssp_codec codec_type); +#else +static inline const char *sof_ssp_get_codec_name(enum sof_ssp_codec codec_= type) +{ + return NULL; +} +#endif =20 #endif /* __SOF_SSP_COMMON_H */ --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 946C5190673; Sun, 24 Mar 2024 22:41:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320100; cv=none; b=L4rmif/WAjITv/OUMuQJoxoyE/MhzS7vfxHVu69dFUWw956FvmnSzQ+xh5nOvU9aMuReL8nJyfATqAeSbj8Fgez/OWd552PhB+zTo2PR9eJKzH4TweLqxXXeyEzCzE2KHq1eMCUsbCWYVzHPA/VtrczQrGE4c4gNzBHXtRRCOF8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320100; c=relaxed/simple; bh=TlP6/AQtNqw7rwGx8wZwwQ5PsKZq/5mbyDLs6BK6zYA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=dKTKZXTa/dEXKZxJtI1un/M5eNGidjH5nqWEiFmk0bo2hL6anYyEK8G9coeO3pgCxLY4M3EUDe1ayPERRFJ3Qjmd3r2a07S+4JKrUVoNirZNuMjDBxuRl4pZiRiVSn0usFLVn/um7UucQXpT/i7rFuCN7c5R3RSbJLCo/DUkxsc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=DZajpdAo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="DZajpdAo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B87E5C433B1; Sun, 24 Mar 2024 22:41:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320100; bh=TlP6/AQtNqw7rwGx8wZwwQ5PsKZq/5mbyDLs6BK6zYA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=DZajpdAoykbNCnHMIsqUTaodqw8q5CwUnj8WGZght53Fwo9LDHtAWG6oQP59ormkv YIVTwK0krC6KEo9gW2kwPdxTK1sdNTD1f41XhbnmD/g9esIPzUlJto5df6kLA0JB1i AiN3wI7bp/XvY2k1fVpyBCX8mHYmnUuijBfDuMOsigpStfuOqtJ7aBVdD7E1FDr4dp U8I3IkhGEF5qTWHMGPCP9ndaa5RaQ4WyGWHuBATd/NgqRpufAyfH+aRqn502m101ZD eWn4toqt4dY7HEJCvnvtARdNCw8zyk6dmcu8pV0nkYSP0X43Ap+4j+CldftBsOci59 68qRY98qVvfyA== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christophe JAILLET , Bjorn Helgaas , Logan Gunthorpe , Sasha Levin Subject: [PATCH 6.8 409/715] PCI/P2PDMA: Fix a sleeping issue in a RCU read section Date: Sun, 24 Mar 2024 18:29:48 -0400 Message-ID: <20240324223455.1342824-410-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Christophe JAILLET [ Upstream commit 1e5c66afd4a40bb7be17cb33cbb1a1085f727730 ] It is not allowed to sleep within a RCU read section, so use GFP_ATOMIC instead of GFP_KERNEL here. Link: https://lore.kernel.org/r/02d9ec4a10235def0e764ff1f5be881ba12e16e8.17= 04397858.git.christophe.jaillet@wanadoo.fr Fixes: ae21f835a5bd ("PCI/P2PDMA: Finish RCU conversion of pdev->p2pdma") Signed-off-by: Christophe JAILLET Signed-off-by: Bjorn Helgaas Reviewed-by: Logan Gunthorpe Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/pci/p2pdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c index 0c361561b855c..4f47a13cb500f 100644 --- a/drivers/pci/p2pdma.c +++ b/drivers/pci/p2pdma.c @@ -661,7 +661,7 @@ calc_map_type_and_dist(struct pci_dev *provider, struct= pci_dev *client, p2pdma =3D rcu_dereference(provider->p2pdma); if (p2pdma) xa_store(&p2pdma->map_types, map_types_idx(client), - xa_mk_value(map_type), GFP_KERNEL); + xa_mk_value(map_type), GFP_ATOMIC); rcu_read_unlock(); return map_type; } --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE8E8191056; Sun, 24 Mar 2024 22:41:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320102; cv=none; b=PyDkqWgeZd80Fzx/zcKbadSC6F9Myp1735/OPpzAeeaFpfmkHluUBOapnRT1xO0SWeDdIXrkd8NAq/VHcDdohe/hmTikO2iKaTzq4E4CHuTMW3U3X79Zvq3F2j3LvaWvFwa9/mxc8UE5i/5qvb2+PDUh+xx5X4wp4aXpj74Bg/g= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320102; c=relaxed/simple; bh=+9L2sOYcn70slea3K+0x6ySDW9NT356ZLSJHuWQ40e4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=RKgzjaQSXP+0knI3DQnyBezfsZTjlW9/Ztj9AVD3Hdvmu2KxqDdlDUX3TTcfHhLpURUeatcjOycuKq9XeJ2k8jmnRObMFg+T7FUjd4ga+cg/+lehWDl0l8klKK4sFnT9O25rH9TpD20lzq6H4WWM77w48dor/Zp7PyITWw2JVmQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ajPnLo+z; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ajPnLo+z" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6840C433C7; Sun, 24 Mar 2024 22:41:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320101; bh=+9L2sOYcn70slea3K+0x6ySDW9NT356ZLSJHuWQ40e4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=ajPnLo+znFgyGtiEpIp3UoAQy1dcyxSxTUnUULY6z6m8joLdT4iCCr02HYSelEhJu /1rmT0dxN54el2bcCH62Be923+yS/dYrWaUmktNbzesV4pqLpZk+88R49mBaZhg/qC huQ1UtVH/v0ONv99wTfIdcjUw+7obrDeKmZF6sPnKVJU4/N3a5CmgHw4u2dZMWL9uQ gzF98sd32cEDH9ozunV9jYw1gfS4Wwo9mXCE2CGZmcgNcO/AF1nRWe/PZL82V5uJoH 3HGb0xLvOWVfmGyhOiePBVTWhHtB4IwdYG3dznc63ufKjwMPiriJKGkfQuM0Qb4eRX kW4h4SsFliheQ== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Christophe JAILLET , Bjorn Helgaas , Sasha Levin Subject: [PATCH 6.8 410/715] PCI: switchtec: Fix an error handling path in switchtec_pci_probe() Date: Sun, 24 Mar 2024 18:29:49 -0400 Message-ID: <20240324223455.1342824-411-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Christophe JAILLET [ Upstream commit dec529b0b0572b32f9eb91c882dd1f08ca657efb ] The commit in Fixes changed the logic on how resources are released and introduced a new switchtec_exit_pci() that need to be called explicitly in order to undo a corresponding switchtec_init_pci(). This was done in the remove function, but not in the probe. Fix the probe now. Fixes: df25461119d9 ("PCI: switchtec: Fix stdev_release() crash after surpr= ise hot remove") Link: https://lore.kernel.org/r/01446d2ccb91a578239915812f2b7dfbeb2882af.17= 03428183.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/pci/switch/switchtec.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c index 1804794d0e686..5a4adf6c04cf8 100644 --- a/drivers/pci/switch/switchtec.c +++ b/drivers/pci/switch/switchtec.c @@ -1672,7 +1672,7 @@ static int switchtec_pci_probe(struct pci_dev *pdev, rc =3D switchtec_init_isr(stdev); if (rc) { dev_err(&stdev->dev, "failed to init isr.\n"); - goto err_put; + goto err_exit_pci; } =20 iowrite32(SWITCHTEC_EVENT_CLEAR | @@ -1693,6 +1693,8 @@ static int switchtec_pci_probe(struct pci_dev *pdev, =20 err_devadd: stdev_kill(stdev); +err_exit_pci: + switchtec_exit_pci(stdev); err_put: ida_free(&switchtec_minor_ida, MINOR(stdev->dev.devt)); put_device(&stdev->dev); --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 58CAC191044; Sun, 24 Mar 2024 22:41:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320102; cv=none; b=MfeDEso5w2CQPTNbveTjA26e5hmhVG5rxYH5LLQ/wTG3TkihaIm/OK6qbsfNAnb0RepenwoMcwGMOtmyV9TC+XbgeWdbd2GwQLjrQJTLf9Ern6q56RjntCee1jA46JL+eghqDmSuJMVWNGYrwcOTEyW2TyJKpHUy4XwryPIpahQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320102; c=relaxed/simple; bh=jmu23GktzhpBdA3rPY3ZLQOVWrFuA9mTgWTolJwlTE0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pA5zvsp6/b8E1nSsMdBbyu3/HtFK16ZJzdYBSY8BfaGO1Hpfr/JekCyf7wo5Jg7OcII+a2d1hMZrGicazrtrrmChwtwP8jLGrzzUq5RkfFEdeVV2h/jpRFglz4Fj+y5quuT0+XrvS7OGkxMGphiKBHs3dw5a7niZNW/lrltJMuo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=KsAa1NWd; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="KsAa1NWd" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 98DEAC43394; Sun, 24 Mar 2024 22:41:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320102; bh=jmu23GktzhpBdA3rPY3ZLQOVWrFuA9mTgWTolJwlTE0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KsAa1NWd1rqYALgSUPa6l7DVfGEFASDeOOOKZ5oYKFebJ1Xu9fTSv7I9vbcqXUpN+ q/QLDQOykmNc90HmLZL6+jI8qv088oAL1JOyeFbUxOKXjeomo+T5PvmhSTfWEd6n/h pJMHEIZy6L4x7gXXwkw4kPW+2GMeM374Yzm4s09SdgoOOAqmYzOHfgYi5twvmcAkmL 0glsKA6GG2YUO8Chg97Lfu2oSba6WJTaay856WmrEljzZy7jGv9u4lsbLNiXhGN4M4 Pdw9XXT9Dt5XpQT88/hv0KINYuiv8qefcU6DgOOOFDzNb9/HlmdQoDAzlf532ocn5h kGocEGPg3N+Cw== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Quanyang Wang , Herbert Xu , Sasha Levin Subject: [PATCH 6.8 411/715] crypto: xilinx - call finalize with bh disabled Date: Sun, 24 Mar 2024 18:29:50 -0400 Message-ID: <20240324223455.1342824-412-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Quanyang Wang [ Upstream commit a853450bf4c752e664abab0b2fad395b7ad7701c ] When calling crypto_finalize_request, BH should be disabled to avoid triggering the following calltrace: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_re= quest+0xa0/0x118 Modules linked in: cryptodev(O) CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0= -rc1-yocto-standard #323 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=3D--) pc : crypto_finalize_request+0xa0/0x118 lr : crypto_finalize_request+0x104/0x118 sp : ffffffc085353ce0 x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688 x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00 x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000 x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0 x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8 x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001 x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000 x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000 Call trace: crypto_finalize_request+0xa0/0x118 crypto_finalize_aead_request+0x18/0x30 zynqmp_handle_aes_req+0xcc/0x388 crypto_pump_work+0x168/0x2d8 kthread_worker_fn+0xfc/0x3a0 kthread+0x118/0x138 ret_from_fork+0x10/0x20 irq event stamp: 40 hardirqs last enabled at (39): [] _raw_spin_unlock_i= rqrestore+0x70/0xb0 hardirqs last disabled at (40): [] el1_dbg+0x28/0x90 softirqs last enabled at (36): [] kernel_neon_begin+= 0x8c/0xf0 softirqs last disabled at (34): [] kernel_neon_begin+= 0x60/0xf0 ---[ end trace 0000000000000000 ]--- Fixes: 4d96f7d48131 ("crypto: xilinx - Add Xilinx AES driver") Signed-off-by: Quanyang Wang Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin Reported-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya --- drivers/crypto/xilinx/zynqmp-aes-gcm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/crypto/xilinx/zynqmp-aes-gcm.c b/drivers/crypto/xilinx= /zynqmp-aes-gcm.c index 3c205324b22b6..e614057188409 100644 --- a/drivers/crypto/xilinx/zynqmp-aes-gcm.c +++ b/drivers/crypto/xilinx/zynqmp-aes-gcm.c @@ -231,7 +231,10 @@ static int zynqmp_handle_aes_req(struct crypto_engine = *engine, err =3D zynqmp_aes_aead_cipher(areq); } =20 + local_bh_disable(); crypto_finalize_aead_request(engine, areq, err); + local_bh_enable(); + return 0; } =20 --=20 2.43.0 From nobody Thu Dec 18 23:00:20 2025 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C6AB18FC60; Sun, 24 Mar 2024 22:41:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320104; cv=none; b=cdoAKSzATyfLQqHWgAOAjjBYxKyZmiaDG9UdNEaRbhp51giWyWoh9bKOWOJqh19+EO21gOvKJcxuooqvFTS8oD7OuCAbs2D7p29+Xv5Uk//VJExaeL0W9Ci5aILZcSJ+xgiTfbkvTYT3urk0cjzYD/5/muBU+heywgF2PNmATyM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1711320104; c=relaxed/simple; bh=mhk8zIC6m7tv0PpL5NQAiFH7vaX9lHUJnHwBiBZ7lbY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sodeZI69U3IQhzWeqfC8ghhZND51nmZ06gtsZJjvYOjpGYhJU0Z057p82d0zaN/7GWIvBLlSZuS24QY/0Pv2qbgTy1OCLdGaGLzdJJpB6uIsqPqr/D7H3aWpGQwEhVOomAASxFp6AzAtTnC/6tUcl0NOUmMR1G91+UUyfy/mBi4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PZgeuHrD; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="PZgeuHrD" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7F3A3C433A6; Sun, 24 Mar 2024 22:41:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1711320104; bh=mhk8zIC6m7tv0PpL5NQAiFH7vaX9lHUJnHwBiBZ7lbY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=PZgeuHrDoNvBX1Gd3YNCBEZ8NqMo/76FabatF4z1MJ6zV5LkrwJc+I96ltuHCNOvM 8hTau5qPH1O4ImGoq+7ndXdLPRDRHbyGBGVTuJf7UieKvTxamVOJdxQ0nsz3MW6BvP 7cyYoqt7p5wsruUxm8pIF/7DIvANYyPBy4I72w5eteRwU80CVCwlaWXKFMVrf0gWMU cO3jOck4+086E3AW9CWwBOyfj3UxRO2XcVVt9qImVAvV/JeVh8F6Q0RwZoHM6S/DEU EGyZM5BYomPQ13OLmB1lVB0hDfeWQaNY4ePCtxse60Uq8OCxP5HnoqblhGEhttAqST hXkyswoEwcxRg== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Randy Dunlap , Michael Ellerman , Nicholas Piggin , Christophe Leroy , "Aneesh Kumar K . V" , "Naveen N . Rao" , linuxppc-dev@lists.ozlabs.org, Thomas Zimmermann , Geoff Levand , linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org, Sasha Levin Subject: [PATCH 6.8 412/715] drivers/ps3: select VIDEO to provide cmdline functions Date: Sun, 24 Mar 2024 18:29:51 -0400 Message-ID: <20240324223455.1342824-413-sashal@kernel.org> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20240324223455.1342824-1-sashal@kernel.org> References: <20240324223455.1342824-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Randy Dunlap [ Upstream commit 7edd06233958d9086a9e3eb723a8768d3c5a9ce1 ] When VIDEO is not set, there is a build error. Fix that by selecting VIDEO for PS3_PS3AV. ERROR: modpost: ".video_get_options" [drivers/ps3/ps3av_mod.ko] undefined! Fixes: dae7fbf43fd0 ("driver/ps3: Include