--- /dev/null
+From 903cc7096db22f889d48e2cee8840709ce04fdac Mon Sep 17 00:00:00 2001
+From: Akhil R <akhilrajeev@nvidia.com>
+Date: Tue, 3 Jun 2025 21:00:20 +0530
+Subject: dt-bindings: i2c: nvidia,tegra20-i2c: Specify the required properties
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Akhil R <akhilrajeev@nvidia.com>
+
+commit 903cc7096db22f889d48e2cee8840709ce04fdac upstream.
+
+Specify the properties which are essential and which are not for the
+Tegra I2C driver to function correctly. This was not added correctly when
+the TXT binding was converted to yaml. All the existing DT nodes have
+these properties already and hence this does not break the ABI.
+
+dmas and dma-names which were specified as a must in the TXT binding
+is now made optional since the driver can work in PIO mode if dmas are
+missing.
+
+Fixes: f10a9b722f80 ("dt-bindings: i2c: tegra: Convert to json-schema”)
+Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
+Cc: <stable@vger.kernel.org> # v5.17+
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Signed-off-by: Andi Shyti <andi@smida.it>
+Link: https://lore.kernel.org/r/20250603153022.39434-1-akhilrajeev@nvidia.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml | 24 +++++++++-
+ 1 file changed, 23 insertions(+), 1 deletion(-)
+
+--- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
++++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.yaml
+@@ -97,7 +97,10 @@ properties:
+
+ resets:
+ items:
+- - description: module reset
++ - description:
++ Module reset. This property is optional for controllers in Tegra194,
++ Tegra234 etc where an internal software reset is available as an
++ alternative.
+
+ reset-names:
+ items:
+@@ -116,6 +119,13 @@ properties:
+ - const: rx
+ - const: tx
+
++required:
++ - compatible
++ - reg
++ - interrupts
++ - clocks
++ - clock-names
++
+ allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml
+ - if:
+@@ -169,6 +179,18 @@ allOf:
+ properties:
+ power-domains: false
+
++ - if:
++ not:
++ properties:
++ compatible:
++ contains:
++ enum:
++ - nvidia,tegra194-i2c
++ then:
++ required:
++ - resets
++ - reset-names
++
+ unevaluatedProperties: false
+
+ examples:
--- /dev/null
+From b2e673ae53ef4b943f68585207a5f21cfc9a0714 Mon Sep 17 00:00:00 2001
+From: Avadhut Naik <avadhut.naik@amd.com>
+Date: Fri, 13 Jun 2025 00:51:35 +0000
+Subject: EDAC/amd64: Correct number of UMCs for family 19h models 70h-7fh
+
+From: Avadhut Naik <avadhut.naik@amd.com>
+
+commit b2e673ae53ef4b943f68585207a5f21cfc9a0714 upstream.
+
+AMD's Family 19h-based Models 70h-7fh support 4 unified memory controllers
+(UMC) per processor die.
+
+The amd64_edac driver, however, assumes only 2 UMCs are supported since
+max_mcs variable for the models has not been explicitly set to 4. The same
+results in incomplete or incorrect memory information being logged to dmesg by
+the module during initialization in some instances.
+
+Fixes: 6c79e42169fe ("EDAC/amd64: Add support for ECC on family 19h model 60h-7Fh")
+Closes: https://lore.kernel.org/all/27dc093f-ce27-4c71-9e81-786150a040b6@reox.at/
+Reported-by: reox <mailinglist@reox.at>
+Signed-off-by: Avadhut Naik <avadhut.naik@amd.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: stable@kernel.org
+Link: https://lore.kernel.org/20250613005233.2330627-1-avadhut.naik@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/edac/amd64_edac.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/edac/amd64_edac.c
++++ b/drivers/edac/amd64_edac.c
+@@ -3882,6 +3882,7 @@ static int per_family_init(struct amd64_
+ break;
+ case 0x70 ... 0x7f:
+ pvt->ctl_name = "F19h_M70h";
++ pvt->max_mcs = 4;
+ pvt->flags.zn_regs_v2 = 1;
+ break;
+ case 0x90 ... 0x9f:
x86-tools-drop-duplicate-unlikely-definition-in-insn_decoder_test.c.patch
ipv6-remove-leftover-ip6-cookie-initializer.patch
ipv6-replace-ipcm6_init-calls-with-ipcm6_init_sk.patch
+smb-fix-secondary-channel-creation-issue-with-kerberos-by-populating-hostname-when-adding-channels.patch
drm-msm-disp-correct-porch-timing-for-sdm845.patch
drm-msm-dsi-dsi_phy_10nm-fix-missing-initial-vco-rat.patch
drm-msm-fix-cp_reset_context_state-bitfield-names.patch
mlxbf_gige-return-eprobe_defer-if-phy-irq-is-not-ava.patch
net-atm-add-lec_mutex.patch
net-atm-fix-proc-net-atm-lec-handling.patch
+edac-amd64-correct-number-of-umcs-for-family-19h-models-70h-7fh.patch
+dt-bindings-i2c-nvidia-tegra20-i2c-specify-the-required-properties.patch
+smb-log-an-error-when-close_all_cached_dirs-fails.patch
--- /dev/null
+From 306cb65bb0cb243389fcbd0a66907d5bdea07d1e Mon Sep 17 00:00:00 2001
+From: Bharath SM <bharathsm@microsoft.com>
+Date: Mon, 17 Mar 2025 15:57:27 +0530
+Subject: smb: fix secondary channel creation issue with kerberos by populating hostname when adding channels
+
+From: Bharath SM <bharathsm@microsoft.com>
+
+commit 306cb65bb0cb243389fcbd0a66907d5bdea07d1e upstream.
+
+When mounting a share with kerberos authentication with multichannel
+support, share mounts correctly, but fails to create secondary
+channels. This occurs because the hostname is not populated when
+adding the channels. The hostname is necessary for the userspace
+cifs.upcall program to retrieve the required credentials and pass
+it back to kernel, without hostname secondary channels fails
+establish.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
+Signed-off-by: Bharath SM <bharathsm@microsoft.com>
+Reported-by: xfuren <xfuren@gmail.com>
+Link: https://bugzilla.samba.org/show_bug.cgi?id=15824
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/sess.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/fs/smb/client/sess.c
++++ b/fs/smb/client/sess.c
+@@ -526,8 +526,7 @@ cifs_ses_add_channel(struct cifs_ses *se
+ ctx->domainauto = ses->domainAuto;
+ ctx->domainname = ses->domainName;
+
+- /* no hostname for extra channels */
+- ctx->server_hostname = "";
++ ctx->server_hostname = ses->server->hostname;
+
+ ctx->username = ses->user_name;
+ ctx->password = ses->password;
--- /dev/null
+From a2182743a8b4969481f64aec4908ff162e8a206c Mon Sep 17 00:00:00 2001
+From: Paul Aurich <paul@darkrain42.org>
+Date: Wed, 20 Nov 2024 08:01:54 -0800
+Subject: smb: Log an error when close_all_cached_dirs fails
+
+From: Paul Aurich <paul@darkrain42.org>
+
+commit a2182743a8b4969481f64aec4908ff162e8a206c upstream.
+
+Under low-memory conditions, close_all_cached_dirs() can't move the
+dentries to a separate list to dput() them once the locks are dropped.
+This will result in a "Dentry still in use" error, so add an error
+message that makes it clear this is what happened:
+
+[ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries
+[ 495.281595] ------------[ cut here ]------------
+[ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs]
+[ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0
+
+Also, bail out of looping through all tcons as soon as a single
+allocation fails, since we're already in trouble, and kmalloc() attempts
+for subseqeuent tcons are likely to fail just like the first one did.
+
+Signed-off-by: Paul Aurich <paul@darkrain42.org>
+Acked-by: Bharath SM <bharathsm@microsoft.com>
+Suggested-by: Ruben Devos <rdevos@oxya.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/smb/client/cached_dir.c | 14 ++++++++++++--
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+--- a/fs/smb/client/cached_dir.c
++++ b/fs/smb/client/cached_dir.c
+@@ -484,8 +484,17 @@ void close_all_cached_dirs(struct cifs_s
+ spin_lock(&cfids->cfid_list_lock);
+ list_for_each_entry(cfid, &cfids->entries, entry) {
+ tmp_list = kmalloc(sizeof(*tmp_list), GFP_ATOMIC);
+- if (tmp_list == NULL)
+- break;
++ if (tmp_list == NULL) {
++ /*
++ * If the malloc() fails, we won't drop all
++ * dentries, and unmounting is likely to trigger
++ * a 'Dentry still in use' error.
++ */
++ cifs_tcon_dbg(VFS, "Out of memory while dropping dentries\n");
++ spin_unlock(&cfids->cfid_list_lock);
++ spin_unlock(&cifs_sb->tlink_tree_lock);
++ goto done;
++ }
+ spin_lock(&cfid->fid_lock);
+ tmp_list->dentry = cfid->dentry;
+ cfid->dentry = NULL;
+@@ -497,6 +506,7 @@ void close_all_cached_dirs(struct cifs_s
+ }
+ spin_unlock(&cifs_sb->tlink_tree_lock);
+
++done:
+ list_for_each_entry_safe(tmp_list, q, &entry, entry) {
+ list_del(&tmp_list->entry);
+ dput(tmp_list->dentry);
projects / thirdparty / kernel / stable-queue.git / commitdiff
