April 2025 - Linux-stable-mirror

[PATCH rtw-next v2] wifi: rtlwifi: disable ASPM for RTL8723BE with subsystem ID 11ad:1723

by Mingcong Bai

RTL8723BE found on some ASUSTek laptops, such as F441U and X555UQ with subsystem ID 11ad:1723 are known to output large amounts of PCIe AER errors during and after boot up, causing heavy lags and at times lock-ups: pcieport 0000:00:1c.5: AER: Correctable error message received from 0000:00:1c.5 pcieport 0000:00:1c.5: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID) pcieport 0000:00:1c.5: device [8086:9d15] error status/mask=00000001/00002000 pcieport 0000:00:1c.5: [ 0] RxErr Disable ASPM on this combo as a quirk. This patch is a revision of a previous patch (linked below) which attempted to disable ASPM for RTL8723BE on all Intel Skylake and Kaby Lake PCIe bridges. I take a more conservative approach as all known reports point to ASUSTek laptops of these two generations with this particular wireless card. Please note, however, before the rtl8723be finishes probing, the AER errors remained. After the module finishes probing, all AER errors would indeed be eliminated, along with heavy lags, poor network throughput, and/or occasional lock-ups. Cc: <stable(a)vger.kernel.org> Fixes: a619d1abe20c ("rtlwifi: rtl8723be: Add new driver") Reported-by: Liangliang Zou <rawdiamondmc(a)outlook.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=218127 Link: https://lore.kernel.org/lkml/05390e0b-27fd-4190-971e-e70a498c8221@lwfinger.… Tested-by: Liangliang Zou <rawdiamondmc(a)outlook.com> Signed-off-by: Mingcong Bai <jeffbai(a)aosc.io> --- drivers/net/wireless/realtek/rtlwifi/pci.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c b/drivers/net/wireless/realtek/rtlwifi/pci.c index 0eafc4d125f9..898f597f70a9 100644 --- a/drivers/net/wireless/realtek/rtlwifi/pci.c +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c @@ -155,6 +155,16 @@ static void _rtl_pci_update_default_setting(struct ieee80211_hw *hw) ((u8)init_aspm) == (PCI_EXP_LNKCTL_ASPM_L0S | PCI_EXP_LNKCTL_ASPM_L1 | PCI_EXP_LNKCTL_CCC)) ppsc->support_aspm = false; + + /* RTL8723BE found on some ASUSTek laptops, such as F441U and + * X555UQ with subsystem ID 11ad:1723 are known to output large + * amounts of PCIe AER errors during and after boot up, causing + * heavy lags, poor network throughput, and occasional lock-ups. + */ + if (rtlpriv->rtlhal.hw_type == HARDWARE_TYPE_RTL8723BE && + (rtlpci->pdev->subsystem_vendor == 0x11ad && + rtlpci->pdev->subsystem_device == 0x1723)) + ppsc->support_aspm = false; } static bool _rtl_pci_platform_switch_device_pci_aspm( -- 2.49.0

4 months, 1 week

2
1
0 0

RE: Several questions for backporting fix for CVE-2024-50063 to linux-5.15/5.10

by Ren, Jianqi (Jacky) (CN)

Hello, We are evaluating CVE-2024-50063 for v5.15 and v5.10. But the context of v5.15 and v5.10 is behind current version quite a lot. It seems the suggested fix in https://www.cve.org/CVERecord?id=CVE-2024-50063, https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id…, requires https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… to work. But it seems risky to port so many changes. Is it worth porting commit f45d5b6ce2e8 plus 28ead3eaabc1 to v5.15 and v5.10? Is there any mitigation for this CVE? Is there any reproducer and test case for this CVE so that we could validate the fix if we decide to port it?

4 months, 1 week

1
0
0 0

[PATCH rc] iommu: Skip PASID validation for devices without PASID capability

by Tushar Dave

Generally PASID support requires ACS settings that usually create single device groups, but there are some niche cases where we can get multi-device groups and still have working PASID support. The primary issue is that PCI switches are not required to treat PASID tagged TLPs specially so appropriate ACS settings are required to route all TLPs to the host bridge if PASID is going to work properly. pci_enable_pasid() does check that each device that will use PASID has the proper ACS settings to achieve this routing. However, no-PASID devices can be combined with PASID capable devices within the same topology using non-uniform ACS settings. In this case the no-PASID devices may not have strict route to host ACS flags and end up being grouped with the PASID devices. This configuration fails to allow use of the PASID within the iommu core code which wrongly checks if the no-PASID device supports PASID. Fix this by ignoring no-PASID devices during the PASID validation. They will never issue a PASID TLP anyhow so they can be ignored. Fixes: c404f55c26fc ("iommu: Validate the PASID in iommu_attach_device_pasid()") Cc: stable(a)vger.kernel.org Signed-off-by: Tushar Dave <tdave(a)nvidia.com> --- drivers/iommu/iommu.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c index 4f91a740c15f..e01df4c3e709 100644 --- a/drivers/iommu/iommu.c +++ b/drivers/iommu/iommu.c @@ -3440,7 +3440,13 @@ int iommu_attach_device_pasid(struct iommu_domain *domain, mutex_lock(&group->mutex); for_each_group_device(group, device) { - if (pasid >= device->dev->iommu->max_pasids) { + /* + * Skip PASID validation for devices without PASID support + * (max_pasids = 0). These devices cannot issue transactions + * with PASID, so they don't affect group's PASID usage. + */ + if ((device->dev->iommu->max_pasids > 0) && + (pasid >= device->dev->iommu->max_pasids)) { ret = -EINVAL; goto out_unlock; } -- 2.34.1

4 months, 1 week

5
8
0 0

[PATCH AUTOSEL 6.14 01/31] staging: gpib: Use min for calculating transfer length

by Sasha Levin

From: Dave Penkler <dpenkler(a)gmail.com> [ Upstream commit 76d54fd5471b10ee993c217928a39d7351eaff5c ] In the accel read and write functions the transfer length was being calculated by an if statement setting it to the lesser of the remaining bytes to read/write and the fifo size. Replace both instances with min() which is clearer and more compact. Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Julia Lawall <julia.lawall(a)inria.fr> Closes: https://lore.kernel.org/r/202501182153.qHfL4Fbc-lkp@intel.com/ Signed-off-by: Dave Penkler <dpenkler(a)gmail.com> Link: https://lore.kernel.org/r/20250120145030.29684-1-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/gpib/agilent_82350b/agilent_82350b.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/staging/gpib/agilent_82350b/agilent_82350b.c b/drivers/staging/gpib/agilent_82350b/agilent_82350b.c index 3f4f95b7fe34a..0ba592dc98490 100644 --- a/drivers/staging/gpib/agilent_82350b/agilent_82350b.c +++ b/drivers/staging/gpib/agilent_82350b/agilent_82350b.c @@ -66,10 +66,7 @@ int agilent_82350b_accel_read(gpib_board_t *board, uint8_t *buffer, size_t lengt int j; int count; - if (num_fifo_bytes - i < agilent_82350b_fifo_size) - block_size = num_fifo_bytes - i; - else - block_size = agilent_82350b_fifo_size; + block_size = min(num_fifo_bytes - i, agilent_82350b_fifo_size); set_transfer_counter(a_priv, block_size); writeb(ENABLE_TI_TO_SRAM | DIRECTION_GPIB_TO_HOST, a_priv->gpib_base + SRAM_ACCESS_CONTROL_REG); @@ -200,10 +197,7 @@ int agilent_82350b_accel_write(gpib_board_t *board, uint8_t *buffer, size_t leng for (i = 1; i < fifotransferlength;) { clear_bit(WRITE_READY_BN, &tms_priv->state); - if (fifotransferlength - i < agilent_82350b_fifo_size) - block_size = fifotransferlength - i; - else - block_size = agilent_82350b_fifo_size; + block_size = min(fifotransferlength - i, agilent_82350b_fifo_size); set_transfer_counter(a_priv, block_size); for (j = 0; j < block_size; ++j, ++i) { // load data into board's sram -- 2.39.5

4 months, 1 week

3
34
0 0

[PATCH AUTOSEL 6.13 01/28] staging: gpib: Use min for calculating transfer length

by Sasha Levin

From: Dave Penkler <dpenkler(a)gmail.com> [ Upstream commit 76d54fd5471b10ee993c217928a39d7351eaff5c ] In the accel read and write functions the transfer length was being calculated by an if statement setting it to the lesser of the remaining bytes to read/write and the fifo size. Replace both instances with min() which is clearer and more compact. Reported-by: kernel test robot <lkp(a)intel.com> Reported-by: Julia Lawall <julia.lawall(a)inria.fr> Closes: https://lore.kernel.org/r/202501182153.qHfL4Fbc-lkp@intel.com/ Signed-off-by: Dave Penkler <dpenkler(a)gmail.com> Link: https://lore.kernel.org/r/20250120145030.29684-1-dpenkler@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/staging/gpib/agilent_82350b/agilent_82350b.c | 10 ++-------- 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/staging/gpib/agilent_82350b/agilent_82350b.c b/drivers/staging/gpib/agilent_82350b/agilent_82350b.c index 8e2334fe5c9b8..533cc956b3f6c 100644 --- a/drivers/staging/gpib/agilent_82350b/agilent_82350b.c +++ b/drivers/staging/gpib/agilent_82350b/agilent_82350b.c @@ -69,10 +69,7 @@ int agilent_82350b_accel_read(gpib_board_t *board, uint8_t *buffer, size_t lengt int j; int count; - if (num_fifo_bytes - i < agilent_82350b_fifo_size) - block_size = num_fifo_bytes - i; - else - block_size = agilent_82350b_fifo_size; + block_size = min(num_fifo_bytes - i, agilent_82350b_fifo_size); set_transfer_counter(a_priv, block_size); writeb(ENABLE_TI_TO_SRAM | DIRECTION_GPIB_TO_HOST, a_priv->gpib_base + SRAM_ACCESS_CONTROL_REG); @@ -203,10 +200,7 @@ int agilent_82350b_accel_write(gpib_board_t *board, uint8_t *buffer, size_t leng for (i = 1; i < fifotransferlength;) { clear_bit(WRITE_READY_BN, &tms_priv->state); - if (fifotransferlength - i < agilent_82350b_fifo_size) - block_size = fifotransferlength - i; - else - block_size = agilent_82350b_fifo_size; + block_size = min(fifotransferlength - i, agilent_82350b_fifo_size); set_transfer_counter(a_priv, block_size); for (j = 0; j < block_size; ++j, ++i) { // load data into board's sram -- 2.39.5

4 months, 1 week

2
30
0 0

[PATCH AUTOSEL 6.13 01/34] KVM: s390: Don't use %pK through tracepoints

by Sasha Levin

From: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> [ Upstream commit 6c9567e0850be2f0f94ab64fa6512413fd1a1eb1 ] Restricted pointers ("%pK") are not meant to be used through TP_format(). It can unintentionally expose security sensitive, raw pointer values. Use regular pointer formatting instead. Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c70704… Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> Reviewed-by: Michael Mueller <mimu(a)linux.ibm.com> Link: https://lore.kernel.org/r/20250217-restricted-pointers-s390-v1-1-0e4ace75d8… Signed-off-by: Janosch Frank <frankja(a)linux.ibm.com> Message-ID: <20250217-restricted-pointers-s390-v1-1-0e4ace75d8aa(a)linutronix.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- arch/s390/kvm/trace-s390.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/s390/kvm/trace-s390.h b/arch/s390/kvm/trace-s390.h index 9ac92dbf680db..9e28f165c114c 100644 --- a/arch/s390/kvm/trace-s390.h +++ b/arch/s390/kvm/trace-s390.h @@ -56,7 +56,7 @@ TRACE_EVENT(kvm_s390_create_vcpu, __entry->sie_block = sie_block; ), - TP_printk("create cpu %d at 0x%pK, sie block at 0x%pK", + TP_printk("create cpu %d at 0x%p, sie block at 0x%p", __entry->id, __entry->vcpu, __entry->sie_block) ); @@ -255,7 +255,7 @@ TRACE_EVENT(kvm_s390_enable_css, __entry->kvm = kvm; ), - TP_printk("enabling channel I/O support (kvm @ %pK)\n", + TP_printk("enabling channel I/O support (kvm @ %p)\n", __entry->kvm) ); -- 2.39.5

4 months, 1 week

2
35
0 0

[PATCH] PCI: dw-rockchip: Fix function call sequence in rockchip_pcie_phy_deinit

by Diederik de Haas

The documentation for the phy_power_off() function explicitly says Must be called before phy_exit(). So let's follow that instruction. Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host controller driver") Cc: stable(a)vger.kernel.org # v5.15+ Signed-off-by: Diederik de Haas <didi.debian(a)cknow.org> --- drivers/pci/controller/dwc/pcie-dw-rockchip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c index c624b7ebd118..4f92639650e3 100644 --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c @@ -410,8 +410,8 @@ static int rockchip_pcie_phy_init(struct rockchip_pcie *rockchip) static void rockchip_pcie_phy_deinit(struct rockchip_pcie *rockchip) { - phy_exit(rockchip->phy); phy_power_off(rockchip->phy); + phy_exit(rockchip->phy); } static const struct dw_pcie_ops dw_pcie_ops = { -- 2.49.0

4 months, 1 week

5
6
0 0

[PATCH 6.1.y] jfs: define xtree root and page independently

by Aditya Dutt

From: Dave Kleikamp <dave.kleikamp(a)oracle.com> [ Upstream commit a779ed754e52d582b8c0e17959df063108bd0656 ] In order to make array bounds checking sane, provide a separate definition of the in-inode xtree root and the external xtree page. Signed-off-by: Dave Kleikamp <dave.kleikamp(a)oracle.com> Tested-by: Manas Ghandat <ghandatmanas(a)gmail.com> (cherry picked from commit a779ed754e52d582b8c0e17959df063108bd0656) Closes: https://syzkaller.appspot.com/bug?extid=7cb897779f3c479d0615 Closes: https://syzkaller.appspot.com/bug?extid=6b1d79dad6cc6b3eef41 Closes: https://syzkaller.appspot.com/bug?extid=67f714a53ce18d5b542e Closes: https://syzkaller.appspot.com/bug?extid=e829cfdd0de521302df4 Reported-by: syzbot+7cb897779f3c479d0615(a)syzkaller.appspotmail.com Reported-by: syzbot+6b1d79dad6cc6b3eef41(a)syzkaller.appspotmail.com Reported-by: syzbot+67f714a53ce18d5b542e(a)syzkaller.appspotmail.com Reported-by: syzbot+e829cfdd0de521302df4(a)syzkaller.appspotmail.com Signed-off-by: Aditya Dutt <duttaditya18(a)gmail.com> --- I am sending this as per the suggestion by Greg to submit backports for all the relevant stable trees: https://lore.kernel.org/stable/2025042210-stylized-nearest-ea59@gregkh/ I will send one more mail for 5.15. This patch has been applied in >= 6.12 and has been backported to 6.6: 2ff51719ec615e1b373c1811443efe93594c41a9 syzbot checked the patch against 6.1.y and confirmed that the reproducer did not trigger any issues. check here: https://lore.kernel.org/all/680e4455.050a0220.3b8549.0082.GAE@google.com/ I also tested the patch manually using the C reproducer: https://syzkaller.appspot.com/text?tag=ReproC&x=15b291ef680000 (given in the syzkaller dashboard link) fs/jfs/jfs_dinode.h | 2 +- fs/jfs/jfs_imap.c | 6 +++--- fs/jfs/jfs_incore.h | 2 +- fs/jfs/jfs_txnmgr.c | 4 ++-- fs/jfs/jfs_xtree.c | 4 ++-- fs/jfs/jfs_xtree.h | 37 +++++++++++++++++++++++-------------- 6 files changed, 32 insertions(+), 23 deletions(-) diff --git a/fs/jfs/jfs_dinode.h b/fs/jfs/jfs_dinode.h index 6b231d0d0071..603aae17a693 100644 --- a/fs/jfs/jfs_dinode.h +++ b/fs/jfs/jfs_dinode.h @@ -96,7 +96,7 @@ struct dinode { #define di_gengen u._file._u1._imap._gengen union { - xtpage_t _xtroot; + xtroot_t _xtroot; struct { u8 unused[16]; /* 16: */ dxd_t _dxd; /* 16: */ diff --git a/fs/jfs/jfs_imap.c b/fs/jfs/jfs_imap.c index 155f66812934..9adb29e7862c 100644 --- a/fs/jfs/jfs_imap.c +++ b/fs/jfs/jfs_imap.c @@ -673,7 +673,7 @@ int diWrite(tid_t tid, struct inode *ip) * This is the special xtree inside the directory for storing * the directory table */ - xtpage_t *p, *xp; + xtroot_t *p, *xp; xad_t *xad; jfs_ip->xtlid = 0; @@ -687,7 +687,7 @@ int diWrite(tid_t tid, struct inode *ip) * copy xtree root from inode to dinode: */ p = &jfs_ip->i_xtroot; - xp = (xtpage_t *) &dp->di_dirtable; + xp = (xtroot_t *) &dp->di_dirtable; lv = ilinelock->lv; for (n = 0; n < ilinelock->index; n++, lv++) { memcpy(&xp->xad[lv->offset], &p->xad[lv->offset], @@ -716,7 +716,7 @@ int diWrite(tid_t tid, struct inode *ip) * regular file: 16 byte (XAD slot) granularity */ if (type & tlckXTREE) { - xtpage_t *p, *xp; + xtroot_t *p, *xp; xad_t *xad; /* diff --git a/fs/jfs/jfs_incore.h b/fs/jfs/jfs_incore.h index 721def69e732..dd4264aa9bed 100644 --- a/fs/jfs/jfs_incore.h +++ b/fs/jfs/jfs_incore.h @@ -66,7 +66,7 @@ struct jfs_inode_info { lid_t xtlid; /* lid of xtree lock on directory */ union { struct { - xtpage_t _xtroot; /* 288: xtree root */ + xtroot_t _xtroot; /* 288: xtree root */ struct inomap *_imap; /* 4: inode map header */ } file; struct { diff --git a/fs/jfs/jfs_txnmgr.c b/fs/jfs/jfs_txnmgr.c index ce4b4760fcb1..dccc8b3f1045 100644 --- a/fs/jfs/jfs_txnmgr.c +++ b/fs/jfs/jfs_txnmgr.c @@ -783,7 +783,7 @@ struct tlock *txLock(tid_t tid, struct inode *ip, struct metapage * mp, if (mp->xflag & COMMIT_PAGE) p = (xtpage_t *) mp->data; else - p = &jfs_ip->i_xtroot; + p = (xtpage_t *) &jfs_ip->i_xtroot; xtlck->lwm.offset = le16_to_cpu(p->header.nextindex); } @@ -1676,7 +1676,7 @@ static void xtLog(struct jfs_log * log, struct tblock * tblk, struct lrd * lrd, if (tlck->type & tlckBTROOT) { lrd->log.redopage.type |= cpu_to_le16(LOG_BTROOT); - p = &JFS_IP(ip)->i_xtroot; + p = (xtpage_t *) &JFS_IP(ip)->i_xtroot; if (S_ISDIR(ip->i_mode)) lrd->log.redopage.type |= cpu_to_le16(LOG_DIR_XTREE); diff --git a/fs/jfs/jfs_xtree.c b/fs/jfs/jfs_xtree.c index 2d304cee884c..5ee618d17e77 100644 --- a/fs/jfs/jfs_xtree.c +++ b/fs/jfs/jfs_xtree.c @@ -1213,7 +1213,7 @@ xtSplitRoot(tid_t tid, struct xtlock *xtlck; int rc; - sp = &JFS_IP(ip)->i_xtroot; + sp = (xtpage_t *) &JFS_IP(ip)->i_xtroot; INCREMENT(xtStat.split); @@ -2098,7 +2098,7 @@ int xtAppend(tid_t tid, /* transaction id */ */ void xtInitRoot(tid_t tid, struct inode *ip) { - xtpage_t *p; + xtroot_t *p; /* * acquire a transaction lock on the root diff --git a/fs/jfs/jfs_xtree.h b/fs/jfs/jfs_xtree.h index 142caafc73b1..15da4e16d8b2 100644 --- a/fs/jfs/jfs_xtree.h +++ b/fs/jfs/jfs_xtree.h @@ -65,24 +65,33 @@ struct xadlist { #define XTPAGEMAXSLOT 256 #define XTENTRYSTART 2 -/* - * xtree page: - */ -typedef union { - struct xtheader { - __le64 next; /* 8: */ - __le64 prev; /* 8: */ +struct xtheader { + __le64 next; /* 8: */ + __le64 prev; /* 8: */ - u8 flag; /* 1: */ - u8 rsrvd1; /* 1: */ - __le16 nextindex; /* 2: next index = number of entries */ - __le16 maxentry; /* 2: max number of entries */ - __le16 rsrvd2; /* 2: */ + u8 flag; /* 1: */ + u8 rsrvd1; /* 1: */ + __le16 nextindex; /* 2: next index = number of entries */ + __le16 maxentry; /* 2: max number of entries */ + __le16 rsrvd2; /* 2: */ - pxd_t self; /* 8: self */ - } header; /* (32) */ + pxd_t self; /* 8: self */ +}; +/* + * xtree root (in inode): + */ +typedef union { + struct xtheader header; xad_t xad[XTROOTMAXSLOT]; /* 16 * maxentry: xad array */ +} xtroot_t; + +/* + * xtree page: + */ +typedef union { + struct xtheader header; + xad_t xad[XTPAGEMAXSLOT]; /* 16 * maxentry: xad array */ } xtpage_t; /* -- 2.34.1

4 months, 1 week

1
0
0 0

[PATCH v4] arm64: dts: imx8mm-verdin: Link reg_usdhc2_vqmmc to usdhc2

by Wojciech Dubowik

Define vqmmc regulator-gpio for usdhc2 with vin-supply coming from LDO5. Without this definition LDO5 will be powered down, disabling SD card after bootup. This has been introduced in commit f5aab0438ef1 ("regulator: pca9450: Fix enable register for LDO5"). Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Tested-by: Manuel Traut <manuel.traut(a)mt.com> Reviewed-by: Philippe Schenker <philippe.schenker(a)impulsing.ch> Tested-by: Francesco Dolcini <francesco.dolcini(a)toradex.com> Reviewed-by: Francesco Dolcini <francesco.dolcini(a)toradex.com> Cc: stable(a)vger.kernel.org Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik(a)mt.com> --- v1 -> v2: https://lore.kernel.org/all/20250417112012.785420-1-Wojciech.Dubowik@mt.com/ - define gpio regulator for LDO5 vin controlled by vselect signal v2 -> v3: https://lore.kernel.org/all/20250422130127.GA238494@francesco-nb/ - specify vselect as gpio v3 -> v4: https://lore.kernel.org/all/84dc6fdf295902044d49cafc4479eb75477bba5c.camel@… - add reviewed and tested by tags and changed fixes --- .../boot/dts/freescale/imx8mm-verdin.dtsi | 25 +++++++++++++++---- 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi index 7251ad3a0017..b46566f3ce20 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin.dtsi @@ -144,6 +144,19 @@ reg_usdhc2_vmmc: regulator-usdhc2 { startup-delay-us = <20000>; }; + reg_usdhc2_vqmmc: regulator-usdhc2-vqmmc { + compatible = "regulator-gpio"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_usdhc2_vsel>; + gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>; + regulator-max-microvolt = <3300000>; + regulator-min-microvolt = <1800000>; + states = <1800000 0x1>, + <3300000 0x0>; + regulator-name = "PMIC_USDHC_VSELECT"; + vin-supply = <&reg_nvcc_sd>; + }; + reserved-memory { #address-cells = <2>; #size-cells = <2>; @@ -269,7 +282,7 @@ &gpio1 { "SODIMM_19", "", "", - "", + "PMIC_USDHC_VSELECT", "", "", "", @@ -785,6 +798,7 @@ &usdhc2 { pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_cd>; pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_usdhc2_cd_sleep>; vmmc-supply = <&reg_usdhc2_vmmc>; + vqmmc-supply = <&reg_usdhc2_vqmmc>; }; &wdog1 { @@ -1206,13 +1220,17 @@ pinctrl_usdhc2_pwr_en: usdhc2pwrengrp { <MX8MM_IOMUXC_NAND_CLE_GPIO3_IO5 0x6>; /* SODIMM 76 */ }; + pinctrl_usdhc2_vsel: usdhc2vselgrp { + fsl,pins = + <MX8MM_IOMUXC_GPIO1_IO04_GPIO1_IO4 0x10>; /* PMIC_USDHC_VSELECT */ + }; + /* * Note: Due to ERR050080 we use discrete external on-module resistors pulling-up to the * on-module +V3.3_1.8_SD (LDO5) rail and explicitly disable the internal pull-ups here. */ pinctrl_usdhc2: usdhc2grp { fsl,pins = - <MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x10>, <MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x90>, /* SODIMM 78 */ <MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x90>, /* SODIMM 74 */ <MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x90>, /* SODIMM 80 */ @@ -1223,7 +1241,6 @@ pinctrl_usdhc2: usdhc2grp { pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp { fsl,pins = - <MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x10>, <MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x94>, <MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x94>, <MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x94>, @@ -1234,7 +1251,6 @@ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp { pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp { fsl,pins = - <MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x10>, <MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x96>, <MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x96>, <MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x96>, @@ -1246,7 +1262,6 @@ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp { /* Avoid backfeeding with removed card power */ pinctrl_usdhc2_sleep: usdhc2slpgrp { fsl,pins = - <MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x0>, <MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x0>, <MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x0>, <MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x0>, -- 2.47.2

4 months, 1 week

3
2
0 0

Hope to hear from you soon..

by MRS NORAH JANE

My Dear, I am pleased to find your email address via google search when i was searching for my lost childhood friend which I have not seen for the past 30 years, i have been searching for him on all social media platforms to no avail. Actually I was searching for him because of my health, which started since covid 19, 2020, covid 19 killed every member of my family, I am the only surviving member. I Survived the pandemic through the assistance of the CDC, But my life has never remained the same since ever then. my heart and lungs is Severely affected and damaged, my life is gradually fading away before me. I was searching for my childhood friend to be the beneficiary of my family estate and funds in the bank. When I saw your name there was something fascinating about it. Please can you grant me the opportunity to make you the beneficiary. I shall be awaiting your response for more details. Thanks Mrs Norah Jane

4 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2025