[tip:ras/core] BUILD SUCCESS 7bb39313cd6239e7eb95198950a02b4ad2a08316
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git ras/core branch HEAD: 7bb39313cd6239e7eb95198950a02b4ad2a08316 x86/mce: Make mce_timed_out() identify holdout CPUs elapsed time: 892m configs tested: 122 configs skipped: 59 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig openriscdefconfig powerpc arches_defconfig mipsqi_lb60_defconfig powerpc sbc8548_defconfig openrisc simple_smp_defconfig sh se7780_defconfig powerpc mgcoge_defconfig mips malta_kvm_defconfig m68kmvme16x_defconfig powerpc wii_defconfig riscv rv32_defconfig powerpcsam440ep_defconfig mips tb0219_defconfig mips bmips_stb_defconfig powerpc ppc6xx_defconfig mips decstation_64_defconfig arm lpc18xx_defconfig armmvebu_v7_defconfig microblaze defconfig armoxnas_v6_defconfig m68kdefconfig m68k apollo_defconfig powerpc64 defconfig arm cns3420vb_defconfig m68kmvme147_defconfig shshmin_defconfig powerpc iss476-smp_defconfig ia64defconfig powerpc pseries_defconfig arm lpc32xx_defconfig powerpc kilauea_defconfig m68k allyesconfig arm aspeed_g5_defconfig m68k m5249evb_defconfig sh se7619_defconfig mips maltaaprp_defconfig arc axs103_defconfig arm eseries_pxa_defconfig sh r7780mp_defconfig powerpc acadia_defconfig riscvallyesconfig arc axs101_defconfig mips gcw0_defconfig mips pic32mzda_defconfig pariscgeneric-32bit_defconfig powerpcmpc7448_hpc2_defconfig mips pistachio_defconfig armvt8500_v6_v7_defconfig powerpc chrp32_defconfig arm lpd270_defconfig mips ci20_defconfig ia64 allmodconfig ia64 allyesconfig m68k allmodconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a004-20210108 x86_64 randconfig-a006-20210108 x86_64 randconfig-a001-20210108 x86_64 randconfig-a002-20210108 x86_64 randconfig-a003-20210108 x86_64 randconfig-a005-20210108 i386 randconfig-a005-20210108 i386 randconfig-a002-20210108 i386 randconfig-a001-20210108 i386 randconfig-a003-20210108 i386 randconfig-a006-20210108 i386 randconfig-a004-20210108 i386 randconfig-a016-20210108 i386 randconfig-a011-20210108 i386
[PATCH] mm: Fix potential pte_unmap_unlock pte error
Since commit 42e4089c7890 ("x86/speculation/l1tf: Disallow non privileged
high MMIO PROT_NONE mappings"), when the first pfn modify is not allowed,
we would break the loop with pte unchanged. Then the wrong pte - 1 would
be passed to pte_unmap_unlock.
Fixes: 42e4089c789 ("x86/speculation/l1tf: Disallow non privileged high MMIO
PROT_NONE mappings")
Signed-off-by: Hongxiang Lou
Signed-off-by: Miaohe Lin
Cc: sta...@kernel.org
---
mm/memory.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index feff48e1465a..351b78ebd5a4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2165,11 +2165,11 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t
*pmd,
unsigned long addr, unsigned long end,
unsigned long pfn, pgprot_t prot)
{
- pte_t *pte;
+ pte_t *pte, *mapped_pte;
spinlock_t *ptl;
int err = 0;
- pte = pte_alloc_map_lock(mm, pmd, addr, );
+ mapped_pte = pte = pte_alloc_map_lock(mm, pmd, addr, );
if (!pte)
return -ENOMEM;
arch_enter_lazy_mmu_mode();
@@ -2183,7 +2183,7 @@ static int remap_pte_range(struct mm_struct *mm, pmd_t
*pmd,
pfn++;
} while (pte++, addr += PAGE_SIZE, addr != end);
arch_leave_lazy_mmu_mode();
- pte_unmap_unlock(pte - 1, ptl);
+ pte_unmap_unlock(mapped_pte, ptl);
return err;
}
--
2.19.1
[PATCH] mm/swap_slots.c: Remove unnecessary NULL pointer check
The cache->slots and cache->slots_ret is already checked before we try to
drain it. And kvfree can handle the NULL pointer itself. So remove the
NULL pointer check here.
Signed-off-by: Miaohe Lin
---
mm/swap_slots.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/mm/swap_slots.c b/mm/swap_slots.c
index 0357fbe70645..4cf99ce033d0 100644
--- a/mm/swap_slots.c
+++ b/mm/swap_slots.c
@@ -178,7 +178,7 @@ static void drain_slots_cache_cpu(unsigned int cpu,
unsigned int type,
swapcache_free_entries(cache->slots + cache->cur, cache->nr);
cache->cur = 0;
cache->nr = 0;
- if (free_slots && cache->slots) {
+ if (free_slots) {
kvfree(cache->slots);
cache->slots = NULL;
}
@@ -188,13 +188,12 @@ static void drain_slots_cache_cpu(unsigned int cpu,
unsigned int type,
spin_lock_irq(>free_lock);
swapcache_free_entries(cache->slots_ret, cache->n_ret);
cache->n_ret = 0;
- if (free_slots && cache->slots_ret) {
+ if (free_slots) {
slots = cache->slots_ret;
cache->slots_ret = NULL;
}
spin_unlock_irq(>free_lock);
- if (slots)
- kvfree(slots);
+ kvfree(slots);
}
}
--
2.19.1
[PATCH] MAINTAINERS: mark all linux-arm-kernel@infradead as moderated
Consistently annotate all linux-arm-ker...@lists.infradead.org as moderated for non-subscribers. 132 entries are already annotated as moderated. Do the same for the other 28 entries. Signed-off-by: Randy Dunlap Cc: Russell King Cc: Andrew Morton Cc: linux-arm-ker...@lists.infradead.org --- MAINTAINERS | 56 +- 1 file changed, 28 insertions(+), 28 deletions(-) --- linux-next-20210108.orig/MAINTAINERS +++ linux-next-20210108/MAINTAINERS @@ -2240,14 +2240,14 @@ N: oxnas ARM/PALM TREO SUPPORT M: Tomas Cech -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained W: http://hackndev.com F: arch/arm/mach-pxa/palmtreo.* ARM/PALMTX,PALMT5,PALMLD,PALMTE2,PALMTC SUPPORT M: Marek Vasut -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained W: http://hackndev.com F: arch/arm/mach-pxa/include/mach/palmld.h @@ -2261,7 +2261,7 @@ F:arch/arm/mach-pxa/palmtx.c ARM/PALMZ72 SUPPORT M: Sergey Lapin -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained W: http://hackndev.com F: arch/arm/mach-pxa/palmz72.* @@ -2425,7 +2425,7 @@ N:s5pv210 ARM/SAMSUNG S5P SERIES 2D GRAPHICS ACCELERATION (G2D) SUPPORT M: Andrzej Hajda -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) L: linux-me...@vger.kernel.org S: Maintained F: drivers/media/platform/s5p-g2d/ @@ -2442,14 +2442,14 @@ ARM/SAMSUNG S5P SERIES JPEG CODEC SUPPOR M: Andrzej Pietrasiewicz M: Jacek Anaszewski M: Sylwester Nawrocki -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) L: linux-me...@vger.kernel.org S: Maintained F: drivers/media/platform/s5p-jpeg/ ARM/SAMSUNG S5P SERIES Multi Format Codec (MFC) SUPPORT M: Andrzej Hajda -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) L: linux-me...@vger.kernel.org S: Maintained F: drivers/media/platform/s5p-mfc/ @@ -2563,7 +2563,7 @@ F:arch/arm64/boot/dts/synaptics/ ARM/TANGO ARCHITECTURE M: Marc Gonzalez M: Mans Rullgard -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Odd Fixes N: tango @@ -3446,7 +3446,7 @@ BROADCOM BCM5301X ARM ARCHITECTURE M: Hauke Mehrtens M: Rafał Miłecki M: bcm-kernel-feedback-l...@broadcom.com -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm/boot/dts/bcm470* F: arch/arm/boot/dts/bcm5301* @@ -3456,7 +3456,7 @@ F:arch/arm/mach-bcm/bcm_5301x.c BROADCOM BCM53573 ARM ARCHITECTURE M: Rafał Miłecki L: bcm-kernel-feedback-l...@broadcom.com -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: arch/arm/boot/dts/bcm47189* F: arch/arm/boot/dts/bcm53573* @@ -4623,7 +4623,7 @@ CPUIDLE DRIVER - ARM BIG LITTLE M: Lorenzo Pieralisi M: Daniel Lezcano L: linux...@vger.kernel.org -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git F: drivers/cpuidle/cpuidle-big_little.c @@ -4642,14 +4642,14 @@ CPUIDLE DRIVER - ARM PSCI M: Lorenzo Pieralisi M: Sudeep Holla L: linux...@vger.kernel.org -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Supported F: drivers/cpuidle/cpuidle-psci.c CPUIDLE DRIVER - ARM PSCI PM DOMAIN M: Ulf Hansson L: linux...@vger.kernel.org -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Supported F: drivers/cpuidle/cpuidle-psci.h F: drivers/cpuidle/cpuidle-psci-domain.c @@ -7088,7 +7088,7 @@ F:include/linux/platform_data/video-imx FREESCALE IMX DDR PMU DRIVER M: Frank Li -L: linux-arm-ker...@lists.infradead.org +L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers) S: Maintained F: Documentation/admin-guide/perf/imx-ddr.rst F: Documentation/devicetree/bindings/perf/fsl-imx-ddr.yaml @@ -7172,7 +7172,7 @@ F:drivers/tty/serial/ucc_uart.c FREESCALE SOC DRIVERS M: Li Yang L: linuxppc-...@lists.ozlabs.org -L:
[PATCH] mm/compaction: Remove duplicated VM_BUG_ON_PAGE !PageLocked
The VM_BUG_ON_PAGE(!PageLocked(page), page) is also done in PageMovable.
Remove this explicitly one.
Signed-off-by: Miaohe Lin
---
mm/compaction.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 02af220fb992..6d316eb99913 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -137,7 +137,6 @@ EXPORT_SYMBOL(__SetPageMovable);
void __ClearPageMovable(struct page *page)
{
- VM_BUG_ON_PAGE(!PageLocked(page), page);
VM_BUG_ON_PAGE(!PageMovable(page), page);
/*
* Clear registered address_space val with keeping PAGE_MAPPING_MOVABLE
--
2.19.1
Re: [PATCH v2] ACPI: scan: Fix a Hyper-V Linux VM panic caused by buffer overflow
On 2021-01-08 08:23, Dexuan Cui wrote:
> Linux VM on Hyper-V crashes with the latest mainline:
>
> [4.069624] detected buffer overflow in strcpy
> [4.077733] kernel BUG at lib/string.c:1149!
> ..
> [4.085819] RIP: 0010:fortify_panic+0xf/0x11
> ...
> [4.085819] Call Trace:
> [4.085819] acpi_device_add.cold.15+0xf2/0xfb
> [4.085819] acpi_add_single_object+0x2a6/0x690
> [4.085819] acpi_bus_check_add+0xc6/0x280
> [4.085819] acpi_ns_walk_namespace+0xda/0x1aa
> [4.085819] acpi_walk_namespace+0x9a/0xc2
> [4.085819] acpi_bus_scan+0x78/0x90
> [4.085819] acpi_scan_init+0xfa/0x248
> [4.085819] acpi_init+0x2c1/0x321
> [4.085819] do_one_initcall+0x44/0x1d0
> [4.085819] kernel_init_freeable+0x1ab/0x1f4
>
> This is because of the recent buffer overflow detection in the
> commit 6a39e62abbaf ("lib: string.h: detect intra-object overflow in
> fortified string functions")
>
> Here acpi_device_bus_id->bus_id can only hold 14 characters, while the
> the acpi_device_hid(device) returns a 22-char string
> "HYPER_V_GEN_COUNTER_V1".
>
> Per ACPI Spec v6.2, Section 6.1.5 _HID (Hardware ID), if the ID is a
> string, it must be of the form AAA or , i.e. 7 chars or 8
> chars.
>
> The field bus_id in struct acpi_device_bus_id was originally defined as
> char bus_id[9], and later was enlarged to char bus_id[15] in 2007 in the
> commit bb0958544f3c ("ACPI: use more understandable bus_id for ACPI devices")
>
> Fix the issue by changing the field bus_id to const char *, and use
> kstrdup_const() to initialize it.
>
> Signed-off-by: Dexuan Cui
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=210449
Tested-By: Jethro Beekman
--
Jethro Beekman | Fortanix
smime.p7s
Description: S/MIME Cryptographic Signature
general protection fault in io_sqe_files_unregister
Hello, syzbot found the following issue on: HEAD commit:71c061d2 Merge tag 'for-5.11-rc2-tag' of git://git.kernel... git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=17ec3f6750 kernel config: https://syzkaller.appspot.com/x/.config?x=8aa30b9da402d224 dashboard link: https://syzkaller.appspot.com/bug?extid=9ec0395bc17f2b1e3cc1 compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+9ec0395bc17f2b1e3...@syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdc00: [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x-0x0007] CPU: 1 PID: 9107 Comm: syz-executor.2 Not tainted 5.11.0-rc2-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__list_add include/linux/list.h:71 [inline] RIP: 0010:list_add_tail include/linux/list.h:100 [inline] RIP: 0010:io_sqe_files_set_node fs/io_uring.c:7243 [inline] RIP: 0010:io_sqe_files_unregister+0x42a/0x770 fs/io_uring.c:7279 Code: 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 07 03 00 00 4c 89 ea 4c 89 ad 88 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 f4 02 00 00 49 8d 7f 18 48 8d 85 80 00 00 00 48 RSP: 0018:c9000982fcf8 EFLAGS: 00010247 RAX: dc00 RBX: 88814763fe90 RCX: c9000d28d000 RDX: RSI: 81d82695 RDI: 0003 RBP: 88814763fe00 R08: 0001 R09: 0001 R10: 81d82684 R11: R12: fffc R13: 0004 R14: 88814763fe80 R15: fff4 FS: 7f6532203700() GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 20d8 CR3: 14ad5000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 Call Trace: __io_uring_register fs/io_uring.c:9916 [inline] __do_sys_io_uring_register+0x1185/0x4080 fs/io_uring.c:1 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x45e219 Code: 0d b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 db b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7f6532202c68 EFLAGS: 0246 ORIG_RAX: 01ab RAX: ffda RBX: 0007 RCX: 0045e219 RDX: RSI: 0003 RDI: 0003 RBP: 7f6532202ca0 R08: R09: R10: R11: 0246 R12: R13: 016afb5f R14: 7f65322039c0 R15: 0119bf8c Modules linked in: ---[ end trace 6e4aada9e44ca3d1 ]--- RIP: 0010:__list_add include/linux/list.h:71 [inline] RIP: 0010:list_add_tail include/linux/list.h:100 [inline] RIP: 0010:io_sqe_files_set_node fs/io_uring.c:7243 [inline] RIP: 0010:io_sqe_files_unregister+0x42a/0x770 fs/io_uring.c:7279 Code: 00 fc ff df 48 c1 ea 03 80 3c 02 00 0f 85 07 03 00 00 4c 89 ea 4c 89 ad 88 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 f4 02 00 00 49 8d 7f 18 48 8d 85 80 00 00 00 48 RSP: 0018:c9000982fcf8 EFLAGS: 00010247 RAX: dc00 RBX: 88814763fe90 RCX: c9000d28d000 RDX: RSI: 81d82695 RDI: 0003 RBP: 88814763fe00 R08: 0001 R09: 0001 R10: 81d82684 R11: R12: fffc R13: 0004 R14: 88814763fe80 R15: fff4 FS: 7f6532203700() GS:8880b9f0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 20d8 CR3: 14ad5000 CR4: 001506e0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
[RESEND, V2] i2c: mediatek: Move suspend and resume handling to NOIRQ phase
From: Qii Wang
Some i2c device driver indirectly uses I2C driver when it is now
being suspended. The i2c devices driver is suspended during the
NOIRQ phase and this cannot be changed due to other dependencies.
Therefore, we also need to move the suspend handling for the I2C
controller driver to the NOIRQ phase as well.
Signed-off-by: Qii Wang
---
Changes in v2:
- Replied some comments
- Fixed the wrong spelling medaitek to mediatek
drivers/i2c/busses/i2c-mt65xx.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
index 0818d3e..2ffd2f3 100644
--- a/drivers/i2c/busses/i2c-mt65xx.c
+++ b/drivers/i2c/busses/i2c-mt65xx.c
@@ -1275,7 +1275,8 @@ static int mtk_i2c_probe(struct platform_device *pdev)
mtk_i2c_clock_disable(i2c);
ret = devm_request_irq(>dev, irq, mtk_i2c_irq,
- IRQF_TRIGGER_NONE, I2C_DRV_NAME, i2c);
+ IRQF_NO_SUSPEND | IRQF_TRIGGER_NONE,
+ I2C_DRV_NAME, i2c);
if (ret < 0) {
dev_err(>dev,
"Request I2C IRQ %d fail\n", irq);
@@ -1302,7 +1303,16 @@ static int mtk_i2c_remove(struct platform_device *pdev)
}
#ifdef CONFIG_PM_SLEEP
-static int mtk_i2c_resume(struct device *dev)
+static int mtk_i2c_suspend_noirq(struct device *dev)
+{
+ struct mtk_i2c *i2c = dev_get_drvdata(dev);
+
+ i2c_mark_adapter_suspended(>adap);
+
+ return 0;
+}
+
+static int mtk_i2c_resume_noirq(struct device *dev)
{
int ret;
struct mtk_i2c *i2c = dev_get_drvdata(dev);
@@ -1317,12 +1327,15 @@ static int mtk_i2c_resume(struct device *dev)
mtk_i2c_clock_disable(i2c);
+ i2c_mark_adapter_resumed(>adap);
+
return 0;
}
#endif
static const struct dev_pm_ops mtk_i2c_pm = {
- SET_SYSTEM_SLEEP_PM_OPS(NULL, mtk_i2c_resume)
+ SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(mtk_i2c_suspend_noirq,
+ mtk_i2c_resume_noirq)
};
static struct platform_driver mtk_i2c_driver = {
--
1.9.1
[PULL REQUEST] i2c for 5.11
Linus, here are three driver bugfixes for I2C. Buisness as usual. Please pull. Thanks, Wolfram The following changes since commit e71ba9452f0b5b2e8dc8aa5445198cd9214a6a62: Linux 5.11-rc2 (2021-01-03 15:55:30 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current for you to fetch changes up to 05f6f7271a38c482c5021967433f7b698e102c45: i2c: mediatek: Fix apdma and i2c hand-shake timeout (2021-01-05 10:54:37 +0100) Chunyan Zhang (1): i2c: sprd: use a specific timeout to avoid system hang up issue Hans de Goede (1): i2c: i801: Fix the i2c-mux gpiod_lookup_table not being properly terminated Qii Wang (1): i2c: mediatek: Fix apdma and i2c hand-shake timeout with much appreciated quality assurance from Linus Walleij (1): (Rev.) i2c: i801: Fix the i2c-mux gpiod_lookup_table not being properly terminated Mika Westerberg (1): (Rev.) i2c: i801: Fix the i2c-mux gpiod_lookup_table not being properly terminated drivers/i2c/busses/i2c-i801.c | 2 +- drivers/i2c/busses/i2c-mt65xx.c | 27 ++- drivers/i2c/busses/i2c-sprd.c | 8 +++- 3 files changed, 30 insertions(+), 7 deletions(-) signature.asc Description: PGP signature
Re: [PATCH v8 04/20] dlb: add device ioctl layer and first three ioctls
On Sat, Jan 09, 2021 at 07:49:24AM +, Chen, Mike Ximing wrote:
> > > +static int dlb_ioctl_arg_size[NUM_DLB_CMD] = {
> > > + sizeof(struct dlb_get_device_version_args),
> > > + sizeof(struct dlb_create_sched_domain_args),
> > > + sizeof(struct dlb_get_num_resources_args)
> >
> > That list.
> >
> > Ugh, no. that's no way to write maintainable code that you will be able
> > to understand in 2 years.
> >
>
> dlb_ioctl() was implemented with switch-case and real function calls
> previously.
> We changed to the table/list implementation during a code restructure. I will
> move
> back to the old implementation.
Who said to change this? And why did they say that? Please go back to
those developers and point them at this thread so that doesn't happen
again...
> > > +{
> > > + struct dlb *dlb;
> > > + dlb_ioctl_fn_t fn;
> > > + u32 cmd_nr;
> > > + void *karg;
> > > + int size;
> > > + int ret;
> > > +
> > > + dlb = f->private_data;
> > > +
> > > + if (!dlb) {
> > > + pr_err("dlb: [%s()] Invalid DLB data\n", __func__);
> > > + return -EFAULT;
> >
> > This error value is only allowed if you really do have a memory fault.
> >
> > Hint, you do not here.
> >
> > How can that value ever be NULL?
> >
>
> It is targeted at some very rare cases, in which an ioctl command are called
> immediately after a device unbind (by a different process/application).
And how can that happen? If it really can happen, where is the lock
that you are holding to keep that pointer from becoming "stale" right
after you assign it?
So either this never can happen, or your logic here for this type of
thing is totally wrong. Please work to determine which it is.
> > > +#define DLB_DEVICE_VERSION(x) (((x) >> 8) & 0xFF)
> > > +#define DLB_DEVICE_REVISION(x) ((x) & 0xFF)
> > > +
> > > +enum dlb_revisions {
> > > + DLB_REV_A0 = 0,
> >
> > What is a "revision" and why do you care about it?
>
> This is for different revisions of hardware. Each revision of hardware may
> have a slight different configuration/feature.
So what does this mean? What are you going to do based on it?
> > > +/*
> > > + * DLB_CMD_GET_DEVICE_VERSION: Query the DLB device version.
> > > + *
> > > + * Each DLB device version has its own unique ioctl API, but all
> > > share
> > > + * this as the first command in their interface, which tells
> > > user-space
> > > + * which API to use. The device revision is provided in case of any
> > > + * hardware errata.
> > > + *
> > > + * Output parameters:
> > > + * - response.status: Detailed error code. In certain cases, such as if
> > > the
> > > + * ioctl request arg is invalid, the driver won't set status.
> > > + * - response.id[7:0]: Device revision.
> > > + * - response.id[15:8]: Device version.
> >
> > So userspace has to do different things depending on what the hardware
> > type is? Why not make a totally different driver for new hardware
> > types if things are going to change in the future?
> >
>
> This comment is not correct (sorry about this). There will be different
> versions of DLB hardware (of the same type). All DLB devices will have the
> same ioctl
> API and userspace interface.
Good, please fix then :)
thanks,
greg k-h
Same symbol with EXPORT_SYMBOL and EXPORT_SYMBOL_GPL
Hi,
I have a question regarding EXPORT_SYMBOL vs. EXPORT_SYMBOL_GPL:
I did stumble upon different export declarations between different
architectures, e.g.:
$ grep -r -e "EXPORT_SYMBOL[^(]*(" * | tr ":()" " " | sort -s -k 3 -k 2 |
grep __virt_addr_valid
arch/mips/mm/mmap.c EXPORT_SYMBOL_GPL __virt_addr_valid ;
arch/x86/mm/physaddr.c EXPORT_SYMBOL __virt_addr_valid ;
Bug or feature?
Other examples are:
clk_disable EXPORT_SYMBOL 7
clk_disable EXPORT_SYMBOL_GPL 3
clk_enable EXPORT_SYMBOL 7
clk_enable EXPORT_SYMBOL_GPL 3
clk_get_parent EXPORT_SYMBOL 4
clk_get_parent EXPORT_SYMBOL_GPL 2
clk_get_rateEXPORT_SYMBOL 7
clk_get_rateEXPORT_SYMBOL_GPL 3
clk_registerEXPORT_SYMBOL 2
clk_registerEXPORT_SYMBOL_GPL 2
clk_round_rate EXPORT_SYMBOL 6
clk_round_rate EXPORT_SYMBOL_GPL 4
clk_set_parent EXPORT_SYMBOL 5
clk_set_parent EXPORT_SYMBOL_GPL 2
clk_set_rateEXPORT_SYMBOL 6
clk_set_rateEXPORT_SYMBOL_GPL 4
clk_unregister EXPORT_SYMBOL 2
clk_unregister EXPORT_SYMBOL_GPL 2
copy_user_highpage EXPORT_SYMBOL 4
copy_user_highpage EXPORT_SYMBOL_GPL 1
cpu_have_featureEXPORT_SYMBOL 1
cpu_have_featureEXPORT_SYMBOL_GPL 1
ec_read EXPORT_SYMBOL 1
ec_read EXPORT_SYMBOL_GPL 1
ec_writeEXPORT_SYMBOL 1
ec_writeEXPORT_SYMBOL_GPL 1
elf_hwcap EXPORT_SYMBOL 2
elf_hwcap EXPORT_SYMBOL_GPL 2
empty_zero_page EXPORT_SYMBOL 26
empty_zero_page EXPORT_SYMBOL_GPL 1
flush_icache_range EXPORT_SYMBOL 9
flush_icache_range EXPORT_SYMBOL_GPL 2
ioremap_uc EXPORT_SYMBOL 1
ioremap_uc EXPORT_SYMBOL_GPL 1
irq_of_parse_and_mapEXPORT_SYMBOL 1
irq_of_parse_and_mapEXPORT_SYMBOL_GPL 1
irq_to_desc EXPORT_SYMBOL 1
irq_to_desc EXPORT_SYMBOL_GPL 1
machine_power_off EXPORT_SYMBOL 1
machine_power_off EXPORT_SYMBOL_GPL 1
memcpy_flushcache EXPORT_SYMBOL 1
memcpy_flushcache EXPORT_SYMBOL_GPL 1
memstart_addr EXPORT_SYMBOL 1
memstart_addr EXPORT_SYMBOL_GPL 1
node_data EXPORT_SYMBOL 7
node_data EXPORT_SYMBOL_GPL 1
pci_domain_nr EXPORT_SYMBOL 2
pci_domain_nr EXPORT_SYMBOL_GPL 1
pci_iomap_wcEXPORT_SYMBOL 1
pci_iomap_wcEXPORT_SYMBOL_GPL 1
pci_iomap_wc_range EXPORT_SYMBOL 1
pci_iomap_wc_range EXPORT_SYMBOL_GPL 1
perf_num_counters EXPORT_SYMBOL 1
perf_num_counters EXPORT_SYMBOL_GPL 2
perf_pmu_name EXPORT_SYMBOL 1
perf_pmu_name EXPORT_SYMBOL_GPL 2
pm_power_offEXPORT_SYMBOL 22
pm_power_offEXPORT_SYMBOL_GPL 3
pv_ops EXPORT_SYMBOL 1
pv_ops EXPORT_SYMBOL_GPL 2
rcu_barrier EXPORT_SYMBOL 1
rcu_barrier EXPORT_SYMBOL_GPL 1
return_address EXPORT_SYMBOL 1
return_address EXPORT_SYMBOL_GPL 3
rtc_lockEXPORT_SYMBOL 5
rtc_lockEXPORT_SYMBOL_GPL 2
save_stack_traceEXPORT_SYMBOL 1
save_stack_traceEXPORT_SYMBOL_GPL 14
save_stack_trace_tskEXPORT_SYMBOL 1
save_stack_trace_tskEXPORT_SYMBOL_GPL 11
smp_call_function_single_async EXPORT_SYMBOL 1
smp_call_function_single_async EXPORT_SYMBOL_GPL 1
start_threadEXPORT_SYMBOL 4
start_threadEXPORT_SYMBOL_GPL 2
ww_mutex_lock EXPORT_SYMBOL 1
ww_mutex_lock EXPORT_SYMBOL_GPL 1
ww_mutex_lock_interruptible EXPORT_SYMBOL 1
ww_mutex_lock_interruptible EXPORT_SYMBOL_GPL 1
xen_domain_type EXPORT_SYMBOL 1
xen_domain_type EXPORT_SYMBOL_GPL 1
xen_start_info EXPORT_SYMBOL 1
xen_start_info EXPORT_SYMBOL_GPL 1
Mfg
thomas
Re: [PATCH] arm/kasan:fix the arry size of kasan_early_shadow_pte
(+ Linus)
On Sat, 9 Jan 2021 at 05:50, Hailong liu wrote:
>
> From: Hailong Liu
>
> The size of kasan_early_shadow_pte[] now is PTRS_PER_PTE which defined to
> 512 for arm architecture. This means that it only covers the prev Linux pte
> entries, but not the HWTABLE pte entries for arm.
>
> The reason it works well current is that the symbol kasan_early_shadow_page
> immediately following kasan_early_shadow_pte in memory is page aligned,
> which makes kasan_early_shadow_pte look like a 4KB size array. But we can't
> ensure the order always right with different compiler/linker, nor more bss
> symbols be introduced.
>
> We had a test with QEMU + vexpress：put a 512KB-size symbol with attribute
> __section(".bss..page_aligned") after kasan_early_shadow_pte, and poison it
> after kasan_early_init(). Then enabled CONFIG_KASAN, it failed to boot up.
>
> Signed-off-by: Hailong Liu
> Signed-off-by: Ziliang Guo
> ---
> include/linux/kasan.h | 6 +-
> mm/kasan/init.c | 3 ++-
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index 5e0655fb2a6f..fe1ae73ff8b5 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -35,8 +35,12 @@ struct kunit_kasan_expectation {
> #define KASAN_SHADOW_INIT 0
> #endif
>
> +#ifndef PTE_HWTABLE_PTRS
> +#define PTE_HWTABLE_PTRS 0
> +#endif
> +
> extern unsigned char kasan_early_shadow_page[PAGE_SIZE];
> -extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE];
> +extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE + PTE_HWTABLE_PTRS];
> extern pmd_t kasan_early_shadow_pmd[PTRS_PER_PMD];
> extern pud_t kasan_early_shadow_pud[PTRS_PER_PUD];
> extern p4d_t kasan_early_shadow_p4d[MAX_PTRS_PER_P4D];
> diff --git a/mm/kasan/init.c b/mm/kasan/init.c
> index bc0ad208b3a7..7ca0b92d5886 100644
> --- a/mm/kasan/init.c
> +++ b/mm/kasan/init.c
> @@ -64,7 +64,8 @@ static inline bool kasan_pmd_table(pud_t pud)
> return false;
> }
> #endif
> -pte_t kasan_early_shadow_pte[PTRS_PER_PTE] __page_aligned_bss;
> +pte_t kasan_early_shadow_pte[PTRS_PER_PTE + PTE_HWTABLE_PTRS]
> + __page_aligned_bss;
>
> static inline bool kasan_pte_table(pmd_t pmd)
> {
> --
> 2.17.1
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
[GIT PULL]: Generic phy fixes for v5.11
Hi Greg, Please pull to receive couple of driver fixes for generic phy subsystem. All these are in linux-next The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git tags/phy-fixes-5.11 for you to fetch changes up to d092bd9110494de3372722b317510b3692f1b2fe: phy: mediatek: allow compile-testing the dsi phy (2021-01-04 13:00:54 +0530) phy: fixes for 5.11 *) Fix Ingenic driver build *) Warning fix for cpcap-usb *) Compile test enabling for mediatek phy Alexander Lobakin (1): PHY: Ingenic: fix unconditional build of phy-ingenic-usb Arnd Bergmann (1): phy: mediatek: allow compile-testing the dsi phy Tony Lindgren (1): phy: cpcap-usb: Fix warning for missing regulator_disable drivers/phy/ingenic/Makefile | 2 +- drivers/phy/mediatek/Kconfig | 4 +++- drivers/phy/motorola/phy-cpcap-usb.c | 19 +-- 3 files changed, 17 insertions(+), 8 deletions(-) -- ~Vinod signature.asc Description: PGP signature
Re: [RFC PATCH 1/8] rcu: Remove superfluous rdp fetch
On Sat, Jan 09, 2021 at 03:05:29AM +0100, Frederic Weisbecker wrote: > Signed-off-by: Frederic Weisbecker > Cc: Paul E. McKenney > Cc: Rafael J. Wysocki > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Cc: Ingo Molnar > --- > kernel/rcu/tree.c | 1 - > 1 file changed, 1 deletion(-) I know I will not take patches without any changelog comments, maybe other maintainers are more lax. Please write something real. And as for sending this to stable@vger, here's my form letter: This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
[GIT PULL]: dmaengine fixes for v5.11
Hello Linus, Please pull to receive fixes for dmaengine drivers. Odd fixes for few drivers. The following changes since commit 5c8fe583cce542aa0b84adc939ce85293de36e5e: Linux 5.11-rc1 (2020-12-27 15:30:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git tags/dmaengine-fix-5.11 for you to fetch changes up to e1263f9277bad198c2acc8092a41aea1edbea0e4: dmaengine: stm32-mdma: fix STM32_MDMA_VERY_HIGH_PRIORITY value (2021-01-04 21:27:45 +0530) dmaengine fixes for v5.11 Bunch of dmaengine driver fixes for: - coverity discovered issues for xilinx driver - qcom, gpi driver fix for undefined bhaviour and one off cleanup - Update Peter's email for TI DMA drivers - one off for idxd driver - resource leak fix for mediatek and milbeaut drivers Amelie Delaunay (1): dmaengine: stm32-mdma: fix STM32_MDMA_VERY_HIGH_PRIORITY value Arnd Bergmann (1): dmaengine: qcom: fix gpi undefined behavior Christophe JAILLET (2): dmaengine: mediatek: mtk-hsdma: Fix a resource leak in the error handling path of the probe function dmaengine: milbeaut-xdmac: Fix a resource leak in the error handling path of the probe function Dan Carpenter (2): dmaengine: idxd: off by one in cleanup code dmaengine: dw-edma: Fix use after free in dw_edma_alloc_chunk() Peter Ujfalusi (3): dmaengine: ti: k3-udma: Fix pktdma rchan TPL level setup MAINTAINERS: Add entry for Texas Instruments DMA drivers dt-bindings: dma: ti: Update maintainer and author information Shravya Kumbham (3): dmaengine: xilinx_dma: check dma_async_device_register return value dmaengine: xilinx_dma: fix incompatible param warning in _child_probe() dmaengine: xilinx_dma: fix mixed_enum_type coverity warning Xiaoming Ni (1): dmaengine: qcom: gpi: Fixes a format mismatch Zheng Yongjun (1): qcom: bam_dma: Delete useless kfree code Documentation/devicetree/bindings/dma/ti/k3-bcdma.yaml | 4 +++- Documentation/devicetree/bindings/dma/ti/k3-pktdma.yaml | 4 +++- Documentation/devicetree/bindings/dma/ti/k3-udma.yaml | 4 +++- MAINTAINERS | 13 + drivers/dma/dw-edma/dw-edma-core.c | 4 ++-- drivers/dma/idxd/sysfs.c| 4 ++-- drivers/dma/mediatek/mtk-hsdma.c| 1 + drivers/dma/milbeaut-xdmac.c| 4 +++- drivers/dma/qcom/bam_dma.c | 6 +- drivers/dma/qcom/gpi.c | 10 +- drivers/dma/stm32-mdma.c| 2 +- drivers/dma/ti/k3-udma.c| 6 +++--- drivers/dma/xilinx/xilinx_dma.c | 11 --- 13 files changed, 48 insertions(+), 25 deletions(-) -- ~Vinod signature.asc Description: PGP signature
Re: [PATCH v2 6/6] iommu: Delete iommu_dev_has_feature()
On Thu, Jan 07, 2021 at 09:18:06AM +0800, Lu Baolu wrote:
> The typical use case is
>
> if (iommu_dev_has_feature(dev, IOMMU_DEV_FEAT_AUX)) {
> rc = iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_AUX);
> if (rc < 0) {
> dev_warn(dev, "Failed to enable aux-domain: %d\n",
> rc);
> return rc;
> }
> }
>
> So please don't remove it.
This doesn't have an upstream user, and did not have for years! If
new users show up they can add it back. Note that the above API with
a separate has vs enable is horrible anyway - the right way is to just
enable and fail it with a specific error code if not supported.
We have a general rule that APIs should only be introduced with their
users, and this example just confirms the reasons of why that rule is in
place once again.
[tip:x86/cleanups] BUILD SUCCESS 4af0e6e39b7ed77796a41537db91d717fedd0ac3
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cleanups branch HEAD: 4af0e6e39b7ed77796a41537db91d717fedd0ac3 x86/mm: Remove duplicate definition of _PAGE_PAT_LARGE elapsed time: 721m configs tested: 126 configs skipped: 61 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: arm defconfig arm64allyesconfig arm64 defconfig arm allyesconfig arm allmodconfig powerpc mgcoge_defconfig mips malta_kvm_defconfig m68kmvme16x_defconfig powerpc wii_defconfig riscv rv32_defconfig arm socfpga_defconfig powerpc ebony_defconfig mips bigsur_defconfig armrealview_defconfig shmigor_defconfig m68km5307c3_defconfig mipsgpr_defconfig powerpc tqm8540_defconfig powerpc iss476-smp_defconfig powerpcsam440ep_defconfig mips tb0219_defconfig mips bmips_stb_defconfig powerpc ppc6xx_defconfig mips decstation_64_defconfig mipsworkpad_defconfig mipsomega2p_defconfig shtitan_defconfig powerpc ppc64e_defconfig shdreamcast_defconfig powerpc allnoconfig m68k apollo_defconfig powerpc64 defconfig arm cns3420vb_defconfig m68kmvme147_defconfig shshmin_defconfig mips tb0287_defconfig arm mainstone_defconfig arm h3600_defconfig c6x defconfig xtensa audio_kc705_defconfig arm aspeed_g5_defconfig m68k m5249evb_defconfig sh se7619_defconfig mips maltaaprp_defconfig arc axs103_defconfig arc axs101_defconfig mips gcw0_defconfig mips pic32mzda_defconfig pariscgeneric-32bit_defconfig powerpcmpc7448_hpc2_defconfig mips pistachio_defconfig armvt8500_v6_v7_defconfig powerpc chrp32_defconfig arm lpd270_defconfig mips ci20_defconfig powerpc akebono_defconfig sh rsk7269_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig x86_64 randconfig-a004-20210108 x86_64 randconfig-a006-20210108 x86_64 randconfig-a001-20210108 x86_64 randconfig-a002-20210108 x86_64 randconfig-a003-20210108 x86_64 randconfig-a005-20210108 i386 randconfig-a005-20210108 i386 randconfig-a002-20210108 i386 randconfig-a001-20210108 i386 randconfig-a003-20210108 i386 randconfig-a006-20210108 i386
Re: [PATCH 2/2] arm64: dts: renesas: Add usb2_clksel to RZ/G2 M/N/H
On Sat, Jan 9, 2021 at 10:29 AM Geert Uytterhoeven wrote:
> On Fri, Jan 8, 2021 at 3:10 PM Geert Uytterhoeven
> wrote:
> > On Mon, Dec 28, 2020 at 9:22 PM Adam Ford wrote:
> > > Per the reference manal for the RZ/G Series, 2nd Generation,
> >
> > manual
> >
> > > the RZ/G2M, RZ/G2N, and RZ/G2H have a bit that can be set to
> > > choose between a crystal oscillator and an external oscillator.
> > >
> > > Because only boards that need this should enable it, it's marked
> > > as disabled by default for backwards compatibility with existing
> > > boards.
> > >
> > > Signed-off-by: Adam Ford
> >
> > Reviewed-by: Geert Uytterhoeven
> > i.e. will queue in renesas-devel for v5.12 (with the typo fixed).
>
> (and the unneeded 'status = "disabled"' dropped).
Please disregard that. Lazy Saturday morning...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 2/2] arm64: dts: renesas: Add usb2_clksel to RZ/G2 M/N/H
On Fri, Jan 8, 2021 at 3:10 PM Geert Uytterhoeven wrote:
> On Mon, Dec 28, 2020 at 9:22 PM Adam Ford wrote:
> > Per the reference manal for the RZ/G Series, 2nd Generation,
>
> manual
>
> > the RZ/G2M, RZ/G2N, and RZ/G2H have a bit that can be set to
> > choose between a crystal oscillator and an external oscillator.
> >
> > Because only boards that need this should enable it, it's marked
> > as disabled by default for backwards compatibility with existing
> > boards.
> >
> > Signed-off-by: Adam Ford
>
> Reviewed-by: Geert Uytterhoeven
> i.e. will queue in renesas-devel for v5.12 (with the typo fixed).
(and the unneeded 'status = "disabled"' dropped).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [PATCH] ACPI: scan: Fix a Hyper-V Linux VM panic caused by buffer overflow
> From: Andy Shevchenko
> Sent: Saturday, January 9, 2021 12:52 AM
>>
>> Hi Rafael, Len, and all,
>> Can you please take a look at the v2 patch?
>>
>> The Linux mainline has been broken for several weeks when it
>> runs as a guest on Hyper-V, so we'd like this to be fixed ASAP,
>> as more people are being affected
>
> I would like to see a warning printed when the dupped
> string violates the spec.
Hi Andy,
Do you want a simple strlen() check like the below, or a full
check of the AAA or format?
Can we have the v2 (https://lkml.org/lkml/2021/1/8/53) merged
first, and then we can add another patch for the format checking?
I'm trying to do one thing in one patch so the patch is small enough
for easy reviewing.
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index cb229e24c563..e6a5d997241c 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -97,7 +97,7 @@ void acpi_scan_table_handler(u32 event, void *table, void
*context);
extern struct list_head acpi_bus_id_list;
struct acpi_device_bus_id {
- char bus_id[15];
+ const char *bus_id;
unsigned int instance_no;
struct list_head node;
};
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index a1b226eb2ce2..3b9902e5d965 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -486,6 +486,7 @@ static void acpi_device_del(struct acpi_device *device)
acpi_device_bus_id->instance_no--;
else {
list_del(_device_bus_id->node);
+ kfree_const(acpi_device_bus_id->bus_id);
kfree(acpi_device_bus_id);
}
break;
@@ -674,7 +675,23 @@ int acpi_device_add(struct acpi_device *device,
}
if (!found) {
acpi_device_bus_id = new_bus_id;
- strcpy(acpi_device_bus_id->bus_id, acpi_device_hid(device));
+ acpi_device_bus_id->bus_id =
+ kstrdup_const(acpi_device_hid(device), GFP_KERNEL);
+ if (!acpi_device_bus_id->bus_id) {
+ pr_err(PREFIX "Memory allocation error for bus id\n");
+ result = -ENOMEM;
+ goto err_free_new_bus_id;
+ }
+
+ /*
+* ACPI Spec v6.2, Section 6.1.5 _HID (Hardware ID): if the
+* ID is a string, it must be of the form AAA or ,
+* i.e. 7 chars or 8 characters.
+*/
+ if (strlen(acpi_device_bus_id->bus_id) > 8)
+ pr_warn(PREFIX "too long HID name: %s\n",
+ acpi_device_bus_id->bus_id);
+
acpi_device_bus_id->instance_no = 0;
list_add_tail(_device_bus_id->node, _bus_id_list);
}
@@ -709,6 +726,10 @@ int acpi_device_add(struct acpi_device *device,
if (device->parent)
list_del(>node);
list_del(>wakeup_list);
+
+ err_free_new_bus_id:
+ if (!found)
+ kfree(new_bus_id);
mutex_unlock(_device_lock);
err_detach:
ERROR: modpost: ".__gcov_init" undefined!
Hi Madhavan, First bad commit (maybe != root cause): tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: f5e6c330254ae691f6d7befe61c786eb5056007e commit: 3c9450c053f88e525b2db1e6990cdf34d14e7696 powerpc/perf: Fix missing is_sier_aviable() during build date: 6 months ago config: powerpc-randconfig-r004-20210108 (attached as .config) compiler: powerpc64-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3c9450c053f88e525b2db1e6990cdf34d14e7696 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 3c9450c053f88e525b2db1e6990cdf34d14e7696 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>, old ones prefixed by <<): ERROR: modpost: ".hid_hw_start" [drivers/hid/hid-petalynx.ko] undefined! ERROR: modpost: ".hid_open_report" [drivers/hid/hid-petalynx.ko] undefined! ERROR: modpost: "._dev_info" [drivers/hid/hid-petalynx.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_const_cmp1" [drivers/hid/hid-petalynx.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_switch" [drivers/hid/hid-petalynx.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_const_cmp4" [drivers/hid/hid-petalynx.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_pc" [drivers/hid/hid-petalynx.ko] undefined! ERROR: modpost: ".__gcov_exit" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".__gcov_init" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".hid_unregister_driver" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".__hid_register_driver" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".hid_hw_start" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".hid_open_report" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_const_cmp8" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: "._dev_info" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: "._dev_err" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".kfree" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_const_cmp4" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".input_ff_create_memless" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".kmem_cache_alloc_trace" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".__hid_request" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".__dynamic_pr_debug" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_pc" [drivers/hid/hid-pl.ko] undefined! ERROR: modpost: ".__gcov_exit" [drivers/hid/hid-ortek.ko] undefined! ERROR: modpost: ".__gcov_init" [drivers/hid/hid-ortek.ko] undefined! ERROR: modpost: ".hid_unregister_driver" [drivers/hid/hid-ortek.ko] undefined! ERROR: modpost: ".__hid_register_driver" [drivers/hid/hid-ortek.ko] undefined! ERROR: modpost: "._dev_info" [drivers/hid/hid-ortek.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_const_cmp1" [drivers/hid/hid-ortek.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_const_cmp4" [drivers/hid/hid-ortek.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_pc" [drivers/hid/hid-ortek.ko] undefined! ERROR: modpost: ".__gcov_exit" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".__gcov_init" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".hid_unregister_driver" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".__hid_register_driver" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".sysfs_create_group" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".hid_hw_start" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".hid_open_report" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".init_timer_key" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_cmp8" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".__hid_request" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".find_next_bit" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".mod_timer" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_const_cmp2" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".jiffies_to_usecs" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".input_mt_get_slot_by_key" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".__sanitizer_cov_trace_cmp1" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost: ".strlen" [drivers/hid/hid-multitouch.ko] undefined! ERROR: modpost:
[PATCH] PCI: decline to resize resources if boot config must be preserved
The _DSM #5 method in the ACPI host bridge object tells us whether the
OS is permitted to deviate from the resource assignment configured by
the firmware. If this is not the case, we should not permit drivers to
resize BARs on the fly. So make pci_resize_resource() take this into
account.
Cc: # v5.4+
Signed-off-by: Ard Biesheuvel
---
drivers/pci/setup-res.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index 43eda101fcf4..3b38be081e93 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -410,10 +410,16 @@ EXPORT_SYMBOL(pci_release_resource);
int pci_resize_resource(struct pci_dev *dev, int resno, int size)
{
struct resource *res = dev->resource + resno;
+ struct pci_host_bridge *host;
int old, ret;
u32 sizes;
u16 cmd;
+ /* Check if we must preserve the firmware's resource assignment */
+ host = pci_find_host_bridge(dev->bus);
+ if (host->preserve_config)
+ return -ENOTSUPP;
+
/* Make sure the resource isn't assigned before resizing it. */
if (!(res->flags & IORESOURCE_UNSET))
return -EBUSY;
--
2.17.1
Re: [PATCH 18/18] ipu3: Add driver for dummy INT3472 ACPI device
On 09/01/2021 09:17, Andy Shevchenko wrote: > On Saturday, January 9, 2021, Daniel Scally wrote: > >> Hi Andy >> >> On 08/01/2021 12:17, Andy Shevchenko wrote: >>> On Fri, Jan 8, 2021 at 1:56 AM Daniel Scally >> wrote: On 30/11/2020 20:07, Andy Shevchenko wrote: > On Mon, Nov 30, 2020 at 01:31:29PM +, Daniel Scally wrote: >>> ... >>> > It's solely Windows driver design... > Luckily I found some information and can clarify above table: > > 0x00 Reset > 0x01 Power down > 0x0b Power enable > 0x0c Clock enable > 0x0d LED (active high) > > The above text perhaps should go somewhere under Documentation. Coming back to this; there's a bit of an anomaly with the 0x01 Power Down pin for at least one platform. As listed above, the OV2680 on one of my platforms has 3 GPIOs defined, and the table above gives them as type Reset, Power down and Clock enable. I'd assumed from this table that "power down" meant a powerdown GPIO (I.E. the one usually called PWDNB in Omnivision datasheets and "powerdown" in drivers), but the datasheet for the OV2680 doesn't list a separate reset and powerdown pin, but rather a single pin that performs both functions. >>> All of them are GPIOs, the question here is how they are actually >>> connected on PCB level and I have no answer to that. You have to find >>> schematics somewhere. >> Yeah; I've been trying to get those but so far, no dice. >> >> > Can you share the exact name / model of the hardware in question here? I > would try to search for the schematics. Lenovo Miix 510-12ISK 80U1 - I also tried asking Lenovo for them but that didn't really go anywhere; but of course I'm just contacting their usual support line and explaining what I'm after, so I didn't really expect it to. > > Am I wrong to treat that as something that ought to be mapped as a powerdown GPIO to the sensors? Or do you know of any other way to reconcile that discrepancy? >>> The GPIOs can go directly to the sensors or be a control pin for >>> separate discrete power gates. >>> So, we can do one of the following: >>> a) present PD GPIO as fixed regulator; >>> b) present PD & Reset GPIOs as regulator; >>> c) provide them as is to the sensor and sensor driver must do what it >>> considers right. >>> >>> Since we don't have schematics (yet?) and we have plenty of variations >>> of sensors, I would go to c) and update the driver of the affected >>> sensor as needed. Because even if you have separate discrete PD for >>> one sensor on one platform there is no guarantee that it will be the >>> same on another. Providing a "virtual" PD in a sensor that doesn't >>> support it is the best choice I think. Let's hear what Sakari and >>> other experienced camera sensor developers say. >>> >>> My vision is purely based on electrical engineering background, >>> experience with existing (not exactly camera) sensor drivers and >>> generic cases. >> Alright; thanks. I'm happy with C being the answer, so unless someone >> thinks differently I'll work on that basis. >> >> > Laurent answered that it is not the best choice from camera sensor driver > perspective. Yep, seen - no problem. I will look at doing it via the method he suggests.
Re: [PATCH 0/3] arm64: kasan: support CONFIG_KASAN_VMALLOC
Hi Ard,
> On Fri, 8 Jan 2021 at 19:31, Andrey Konovalov wrote:
> >
> > On Sun, Jan 3, 2021 at 6:12 PM Lecopzer Chen wrote:
> > >
> > > Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
> > > ("kasan: support backing vmalloc space with real shadow memory")
> > >
> > > Acroding to how x86 ported it [1], they early allocated p4d and pgd,
> > > but in arm64 I just simulate how KAsan supports MODULES_VADDR in arm64
> > > by not to populate the vmalloc area except for kimg address.
> > >
> > > Test environment:
> > > 4G and 8G Qemu virt,
> > > 39-bit VA + 4k PAGE_SIZE with 3-level page table,
> > > test by lib/test_kasan.ko and lib/test_kasan_module.ko
> > >
> > > It also works in Kaslr with CONFIG_RANDOMIZE_MODULE_REGION_FULL,
> > > but not test for HW_TAG(I have no proper device), thus keep
> > > HW_TAG and KASAN_VMALLOC mutual exclusion until confirming
> > > the functionality.
> > >
> > >
> > > [1]: commit 0609ae011deb41c ("x86/kasan: support KASAN_VMALLOC")
> > >
> > > Signed-off-by: Lecopzer Chen
> >
> > Hi Lecopzer,
> >
> > Thanks for working on this!
> >
> > Acked-by: Andrey Konovalov
> > Tested-by: Andrey Konovalov
> >
> > for the series along with the other two patches minding the nit in patch #3.
> >
> > Will, Catalin, could you please take a look at the arm changes?
> >
> > Thanks!
> >
>
>
> If vmalloc can now be backed with real shadow memory, we no longer
> have to keep the module region in its default location when KASLR and
> KASAN are both enabled.
>
> So the check on line 164 in arch/arm64/kernel/kaslr.c should probably
> be updated to reflect this change.
>
I've tested supporting module region randomized and It looks fine
in some easy test(insmod some modules).
I'll add this to patch v2, thanks for your suggestion.
BRs,
Lecopzer
[PATCH v2 2/4] arm64: kasan: abstract _text and _end to KERNEL_START/END
Arm64 provide defined macro for KERNEL_START and KERNEL_END, thus replace them by the abstration instead of using _text and _end. Signed-off-by: Lecopzer Chen --- arch/arm64/mm/kasan_init.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c index 39b218a64279..fa8d7ece895d 100644 --- a/arch/arm64/mm/kasan_init.c +++ b/arch/arm64/mm/kasan_init.c @@ -218,8 +218,8 @@ static void __init kasan_init_shadow(void) phys_addr_t pa_start, pa_end; u64 i; - kimg_shadow_start = (u64)kasan_mem_to_shadow(_text) & PAGE_MASK; - kimg_shadow_end = PAGE_ALIGN((u64)kasan_mem_to_shadow(_end)); + kimg_shadow_start = (u64)kasan_mem_to_shadow(KERNEL_START) & PAGE_MASK; + kimg_shadow_end = PAGE_ALIGN((u64)kasan_mem_to_shadow(KERNEL_END)); mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR); mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END); @@ -241,7 +241,7 @@ static void __init kasan_init_shadow(void) clear_pgds(KASAN_SHADOW_START, KASAN_SHADOW_END); kasan_map_populate(kimg_shadow_start, kimg_shadow_end, - early_pfn_to_nid(virt_to_pfn(lm_alias(_text; + early_pfn_to_nid(virt_to_pfn(lm_alias(KERNEL_START; kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END), (void *)mod_shadow_start); -- 2.25.1
[PATCH v2 0/4] arm64: kasan: support CONFIG_KASAN_VMALLOC
Linux supports KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
("kasan: support backing vmalloc space with real shadow memory")
Acroding to how x86 ported it [1], they early allocated p4d and pgd,
but in arm64 I just simulate how KAsan supports MODULES_VADDR in arm64
by not to populate the vmalloc area except for kimg address.
Test environment:
4G and 8G Qemu virt,
39-bit VA + 4k PAGE_SIZE with 3-level page table,
test by lib/test_kasan.ko and lib/test_kasan_module.ko
It also works in Kaslr with CONFIG_RANDOMIZE_MODULE_REGION_FULL
and randomize module region inside vmalloc area.
[1]: commit 0609ae011deb41c ("x86/kasan: support KASAN_VMALLOC")
Signed-off-by: Lecopzer Chen
Acked-by: Andrey Konovalov
Tested-by: Andrey Konovalov
v2 -> v1
1. kasan_init.c tweak indent
2. change Kconfig depends only on HAVE_ARCH_KASAN
3. support randomized module region.
v1:
https://lore.kernel.org/lkml/20210103171137.153834-1-lecop...@gmail.com/
Lecopzer Chen (4):
arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC
arm64: kasan: abstract _text and _end to KERNEL_START/END
arm64: Kconfig: support CONFIG_KASAN_VMALLOC
arm64: kaslr: support randomized module area with KASAN_VMALLOC
arch/arm64/Kconfig | 1 +
arch/arm64/kernel/kaslr.c | 18 ++
arch/arm64/kernel/module.c | 16 +---
arch/arm64/mm/kasan_init.c | 29 +
4 files changed, 41 insertions(+), 23 deletions(-)
--
2.25.1
[PATCH v2 4/4] arm64: kaslr: support randomized module area with KASAN_VMALLOC
After KASAN_VMALLOC works in arm64, we can randomize module region into vmalloc area now. Test: VMALLOC area ffc01000 fffdf000 before the patch: module_alloc_base/end ffc008b8 ffc01000 after the patch: module_alloc_base/end ffdcf4bed000 ffc01000 And the function that insmod some modules is fine. Suggested-by: Ard Biesheuvel Signed-off-by: Lecopzer Chen --- arch/arm64/kernel/kaslr.c | 18 ++ arch/arm64/kernel/module.c | 16 +--- 2 files changed, 19 insertions(+), 15 deletions(-) diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c index 1c74c45b9494..a2858058e724 100644 --- a/arch/arm64/kernel/kaslr.c +++ b/arch/arm64/kernel/kaslr.c @@ -161,15 +161,17 @@ u64 __init kaslr_early_init(u64 dt_phys) /* use the top 16 bits to randomize the linear region */ memstart_offset_seed = seed >> 48; - if (IS_ENABLED(CONFIG_KASAN_GENERIC) || - IS_ENABLED(CONFIG_KASAN_SW_TAGS)) + if (!IS_ENABLED(CONFIG_KASAN_VMALLOC) && + (IS_ENABLED(CONFIG_KASAN_GENERIC) || +IS_ENABLED(CONFIG_KASAN_SW_TAGS))) /* -* KASAN does not expect the module region to intersect the -* vmalloc region, since shadow memory is allocated for each -* module at load time, whereas the vmalloc region is shadowed -* by KASAN zero pages. So keep modules out of the vmalloc -* region if KASAN is enabled, and put the kernel well within -* 4 GB of the module region. +* KASAN without KASAN_VMALLOC does not expect the module region +* to intersect the vmalloc region, since shadow memory is +* allocated for each module at load time, whereas the vmalloc +* region is shadowed by KASAN zero pages. So keep modules +* out of the vmalloc region if KASAN is enabled without +* KASAN_VMALLOC, and put the kernel well within 4 GB of the +* module region. */ return offset % SZ_2G; diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c index fe21e0f06492..b5ec010c481f 100644 --- a/arch/arm64/kernel/module.c +++ b/arch/arm64/kernel/module.c @@ -40,14 +40,16 @@ void *module_alloc(unsigned long size) NUMA_NO_NODE, __builtin_return_address(0)); if (!p && IS_ENABLED(CONFIG_ARM64_MODULE_PLTS) && - !IS_ENABLED(CONFIG_KASAN_GENERIC) && - !IS_ENABLED(CONFIG_KASAN_SW_TAGS)) + (IS_ENABLED(CONFIG_KASAN_VMALLOC) || +(!IS_ENABLED(CONFIG_KASAN_GENERIC) && + !IS_ENABLED(CONFIG_KASAN_SW_TAGS /* -* KASAN can only deal with module allocations being served -* from the reserved module region, since the remainder of -* the vmalloc region is already backed by zero shadow pages, -* and punching holes into it is non-trivial. Since the module -* region is not randomized when KASAN is enabled, it is even +* KASAN without KASAN_VMALLOC can only deal with module +* allocations being served from the reserved module region, +* since the remainder of the vmalloc region is already +* backed by zero shadow pages, and punching holes into it +* is non-trivial. Since the module region is not randomized +* when KASAN is enabled without KASAN_VMALLOC, it is even * less likely that the module region gets exhausted, so we * can simply omit this fallback in that case. */ -- 2.25.1
[PATCH v2 3/4] arm64: Kconfig: support CONFIG_KASAN_VMALLOC
now we can backed shadow memory in vmalloc area, thus support KASAN_VMALLOC in KASAN_GENERIC mode. Signed-off-by: Lecopzer Chen --- arch/arm64/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 05e17351e4f3..ba03820402ee 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -136,6 +136,7 @@ config ARM64 select HAVE_ARCH_JUMP_LABEL select HAVE_ARCH_JUMP_LABEL_RELATIVE select HAVE_ARCH_KASAN if !(ARM64_16K_PAGES && ARM64_VA_BITS_48) + select HAVE_ARCH_KASAN_VMALLOC if HAVE_ARCH_KASAN select HAVE_ARCH_KASAN_SW_TAGS if HAVE_ARCH_KASAN select HAVE_ARCH_KASAN_HW_TAGS if (HAVE_ARCH_KASAN && ARM64_MTE) select HAVE_ARCH_KGDB -- 2.25.1
[PATCH v2 1/4] arm64: kasan: don't populate vmalloc area for CONFIG_KASAN_VMALLOC
Linux support KAsan for VMALLOC since commit 3c5c3cfb9ef4da9
("kasan: support backing vmalloc space with real shadow memory")
Like how the MODULES_VADDR does now, just not to early populate
the VMALLOC_START between VMALLOC_END.
similarly, the kernel code mapping is now in the VMALLOC area and
should keep these area populated.
Signed-off-by: Lecopzer Chen
---
arch/arm64/mm/kasan_init.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/mm/kasan_init.c b/arch/arm64/mm/kasan_init.c
index d8e66c78440e..39b218a64279 100644
--- a/arch/arm64/mm/kasan_init.c
+++ b/arch/arm64/mm/kasan_init.c
@@ -214,6 +214,7 @@ static void __init kasan_init_shadow(void)
{
u64 kimg_shadow_start, kimg_shadow_end;
u64 mod_shadow_start, mod_shadow_end;
+ u64 vmalloc_shadow_start, vmalloc_shadow_end;
phys_addr_t pa_start, pa_end;
u64 i;
@@ -223,6 +224,9 @@ static void __init kasan_init_shadow(void)
mod_shadow_start = (u64)kasan_mem_to_shadow((void *)MODULES_VADDR);
mod_shadow_end = (u64)kasan_mem_to_shadow((void *)MODULES_END);
+ vmalloc_shadow_start = (u64)kasan_mem_to_shadow((void *)VMALLOC_START);
+ vmalloc_shadow_end = (u64)kasan_mem_to_shadow((void *)VMALLOC_END);
+
/*
* We are going to perform proper setup of shadow memory.
* At first we should unmap early shadow (clear_pgds() call below).
@@ -241,12 +245,21 @@ static void __init kasan_init_shadow(void)
kasan_populate_early_shadow(kasan_mem_to_shadow((void *)PAGE_END),
(void *)mod_shadow_start);
- kasan_populate_early_shadow((void *)kimg_shadow_end,
- (void *)KASAN_SHADOW_END);
+ if (IS_ENABLED(CONFIG_KASAN_VMALLOC)) {
+ kasan_populate_early_shadow((void *)vmalloc_shadow_end,
+ (void *)KASAN_SHADOW_END);
+ if (vmalloc_shadow_start > mod_shadow_end)
+ kasan_populate_early_shadow((void *)mod_shadow_end,
+ (void
*)vmalloc_shadow_start);
+
+ } else {
+ kasan_populate_early_shadow((void *)kimg_shadow_end,
+ (void *)KASAN_SHADOW_END);
+ if (kimg_shadow_start > mod_shadow_end)
+ kasan_populate_early_shadow((void *)mod_shadow_end,
+ (void *)kimg_shadow_start);
+ }
- if (kimg_shadow_start > mod_shadow_end)
- kasan_populate_early_shadow((void *)mod_shadow_end,
- (void *)kimg_shadow_start);
for_each_mem_range(i, _start, _end) {
void *start = (void *)__phys_to_virt(pa_start);
--
2.25.1
[rcu:rcu/next] BUILD SUCCESS WITH WARNING cffdc9c7c24c0bcdd0c9735a8eaca2a39d5c1291
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git rcu/next branch HEAD: cffdc9c7c24c0bcdd0c9735a8eaca2a39d5c1291 EXP sched: Print list of runnable tasks in the current rq Warning ids grouped by kconfigs: gcc_recent_errors `-- xtensa-randconfig-c004-20210108 `-- kernel-rcu-rcutorture.c:WARNING-kmalloc-is-used-to-allocate-this-memory-at-line elapsed time: 1151m configs tested: 129 configs skipped: 2 gcc tested configs: arm64allyesconfig arm allyesconfig arm defconfig arm64 defconfig arm allmodconfig mips ip28_defconfig riscvalldefconfig mipsjmr3927_defconfig arm spitz_defconfig armmagician_defconfig shmigor_defconfig arm socfpga_defconfig powerpc ebony_defconfig mips bigsur_defconfig armrealview_defconfig m68km5307c3_defconfig mipsgpr_defconfig powerpc tqm8540_defconfig powerpc iss476-smp_defconfig mipsworkpad_defconfig mipsomega2p_defconfig shtitan_defconfig powerpc ppc64e_defconfig shdreamcast_defconfig m68k apollo_defconfig powerpc64 defconfig arm cns3420vb_defconfig m68kmvme147_defconfig shshmin_defconfig m68k hp300_defconfig sh polaris_defconfig mips ip27_defconfig mips loongson1c_defconfig ia64generic_defconfig sh sh03_defconfig powerpc ppc40x_defconfig arm jornada720_defconfig arm pxa3xx_defconfig sh se7619_defconfig mips ip22_defconfig riscvnommu_virt_defconfig riscvallmodconfig powerpc mpc885_ads_defconfig mipsmalta_kvm_guest_defconfig powerpc ppc64_defconfig powerpc tqm8560_defconfig mips cobalt_defconfig arm aspeed_g5_defconfig m68k m5249evb_defconfig mips maltaaprp_defconfig arc axs103_defconfig arm eseries_pxa_defconfig sh r7780mp_defconfig powerpc acadia_defconfig arc axs101_defconfig mips gcw0_defconfig mips pic32mzda_defconfig pariscgeneric-32bit_defconfig powerpcmpc7448_hpc2_defconfig mips pistachio_defconfig ia64 allmodconfig ia64defconfig ia64 allyesconfig m68k allmodconfig m68kdefconfig m68k allyesconfig nios2 defconfig arc allyesconfig nds32 allnoconfig c6x allyesconfig nds32 defconfig nios2allyesconfig cskydefconfig alpha defconfig alphaallyesconfig xtensa allyesconfig h8300allyesconfig arc defconfig sh allmodconfig parisc defconfig s390 allyesconfig parisc allyesconfig s390defconfig i386 allyesconfig sparcallyesconfig sparc defconfig i386 tinyconfig i386defconfig mips allyesconfig mips allmodconfig powerpc allyesconfig powerpc allmodconfig powerpc allnoconfig x86_64 randconfig-a004-20210108 x86_64 randconfig-a006-20210108 x86_64 randconfig-a001-20210108 x86_64 randconfig-a002-20210108 x86_64 randconfig-a003-20210108 x86_64
Re: [PATCH 1/3] regulator: mt6360: Add OF match table
Hi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on regulator/for-next]
[also build test WARNING on v5.11-rc2 next-20210108]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/matthias-bgg-kernel-org/regulator-mt6360-Add-OF-match-table/20210109-101451
base: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
for-next
config: x86_64-randconfig-a013-20210108 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
bc556e5685c0f97e79fb7b3c6f15cc5062db8e36)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/3afb01e34a78dae03d0f75af620ac4eab7f4064c
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
matthias-bgg-kernel-org/regulator-mt6360-Add-OF-match-table/20210109-101451
git checkout 3afb01e34a78dae03d0f75af620ac4eab7f4064c
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/regulator/mt6360-regulator.c:448:34: warning: unused variable
>> 'mt6360_of_match' [-Wunused-const-variable]
static const struct of_device_id mt6360_of_match[] = {
^
1 warning generated.
vim +/mt6360_of_match +448 drivers/regulator/mt6360-regulator.c
447
> 448 static const struct of_device_id mt6360_of_match[] = {
449 { .compatible = "mediatek,mt6360-regulator", },
450 { /* sentinel */ },
451 };
452 MODULE_DEVICE_TABLE(of, mt6360_of_match);
453
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
possible deadlock in input_event
Hello,
syzbot found the following issue on:
HEAD commit:36bbbd0e Merge branch 'rcu/urgent' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=150148f750
kernel config: https://syzkaller.appspot.com/x/.config?x=8aa30b9da402d224
dashboard link: https://syzkaller.appspot.com/bug?extid=5f27d4a2c40aea06d3ea
compiler: gcc (GCC) 10.1.0-syz 20200507
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13397e1f50
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11233bc0d0
The issue was bisected to:
commit f08e3888574d490b31481eef6d84c61bedba7a47
Author: Boqun Feng
Date: Fri Aug 7 07:42:30 2020 +
lockdep: Fix recursive read lock related safe->unsafe detection
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=13b3814f50
final oops: https://syzkaller.appspot.com/x/report.txt?x=1073814f50
console output: https://syzkaller.appspot.com/x/log.txt?x=17b3814f50
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5f27d4a2c40aea06d...@syzkaller.appspotmail.com
Fixes: f08e3888574d ("lockdep: Fix recursive read lock related safe->unsafe
detection")
=
WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
5.11.0-rc2-syzkaller #0 Not tainted
-
syz-executor435/8478 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
88801c992638 (>f_owner.lock){.+.+}-{2:2}, at: send_sigio+0x24/0x360
fs/fcntl.c:787
and this task is already holding:
88802063e018 (>fa_lock){}-{2:2}, at: kill_fasync_rcu
fs/fcntl.c:1004 [inline]
88802063e018 (>fa_lock){}-{2:2}, at: kill_fasync fs/fcntl.c:1025
[inline]
88802063e018 (>fa_lock){}-{2:2}, at: kill_fasync+0x14b/0x460
fs/fcntl.c:1018
which would create a new lock dependency:
(>fa_lock){}-{2:2} -> (>f_owner.lock){.+.+}-{2:2}
but this new dependency connects a HARDIRQ-irq-safe lock:
(>event_lock){-...}-{2:2}
... which became HARDIRQ-irq-safe at:
lock_acquire kernel/locking/lockdep.c:5437 [inline]
lock_acquire+0x29d/0x740 kernel/locking/lockdep.c:5402
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:159
input_event drivers/input/input.c:445 [inline]
input_event+0x7b/0xb0 drivers/input/input.c:438
input_report_key include/linux/input.h:425 [inline]
psmouse_report_standard_buttons+0x2c/0x80
drivers/input/mouse/psmouse-base.c:123
psmouse_report_standard_packet drivers/input/mouse/psmouse-base.c:141 [inline]
psmouse_process_byte+0x1e1/0x890 drivers/input/mouse/psmouse-base.c:232
psmouse_handle_byte+0x41/0x1b0 drivers/input/mouse/psmouse-base.c:274
psmouse_interrupt+0x304/0xf00 drivers/input/mouse/psmouse-base.c:426
serio_interrupt+0x88/0x150 drivers/input/serio/serio.c:1002
i8042_interrupt+0x27a/0x520 drivers/input/serio/i8042.c:602
__handle_irq_event_percpu+0x303/0x8f0 kernel/irq/handle.c:156
handle_irq_event_percpu kernel/irq/handle.c:196 [inline]
handle_irq_event+0x102/0x290 kernel/irq/handle.c:213
handle_edge_irq+0x25f/0xd00 kernel/irq/chip.c:819
asm_call_irq_on_stack+0xf/0x20
__run_irq_on_irqstack arch/x86/include/asm/irq_stack.h:48 [inline]
run_irq_on_irqstack_cond arch/x86/include/asm/irq_stack.h:101 [inline]
handle_irq arch/x86/kernel/irq.c:230 [inline]
__common_interrupt arch/x86/kernel/irq.c:249 [inline]
common_interrupt+0x120/0x200 arch/x86/kernel/irq.c:239
asm_common_interrupt+0x1e/0x40 arch/x86/include/asm/idtentry.h:619
unwind_next_frame+0x445/0x1f90 arch/x86/kernel/unwind_orc.c:464
arch_stack_walk+0x7d/0xe0 arch/x86/kernel/stacktrace.c:25
stack_trace_save+0x8c/0xc0 kernel/stacktrace.c:121
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track mm/kasan/common.c:46 [inline]
set_alloc_info mm/kasan/common.c:401 [inline]
kasan_kmalloc.constprop.0+0x82/0xa0 mm/kasan/common.c:429
kasan_slab_alloc include/linux/kasan.h:205 [inline]
slab_post_alloc_hook mm/slab.h:512 [inline]
slab_alloc_node mm/slub.c:2891 [inline]
slab_alloc mm/slub.c:2899 [inline]
kmem_cache_alloc+0x1c6/0x440 mm/slub.c:2904
anon_vma_chain_alloc mm/rmap.c:136 [inline]
__anon_vma_prepare+0x5d/0x560 mm/rmap.c:190
anon_vma_prepare include/linux/rmap.h:152 [inline]
do_anonymous_page mm/memory.c:3533 [inline]
handle_pte_fault mm/memory.c:4385 [inline]
__handle_mm_fault mm/memory.c:4522 [inline]
handle_mm_fault+0x87d/0x5640 mm/memory.c:4620
faultin_page mm/gup.c:851 [inline]
__get_user_pages+0x7ca/0x1490 mm/gup.c:1070
__get_user_pages_locked mm/gup.c:1256 [inline]
__get_user_pages_remote+0x18f/0x810 mm/gup.c:1723
get_user_pages_remote+0x63/0x90 mm/gup.c:1796
get_arg_page+0xba/0x200 fs/exec.c:223
copy_string_kernel+0x1b4/0x520 fs/exec.c:634
kernel_execve+0x25c/0x460 fs/exec.c:1956
call_usermodehelper_exec_async+0x2de/0x580
drivers/net/wan/fsl_ucc_hdlc.c:305:57: sparse: sparse: incorrect type in argument 2 (different address spaces)
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 996e435fd401de35df62ac943ab9402cfe85c430 commit: 894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e powerpc: inline iomap accessors date: 5 weeks ago config: powerpc-randconfig-s032-20210109 (attached as .config) compiler: powerpc-linux-gcc (GCC) 9.3.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # apt-get install sparse # sparse version: v0.6.3-208-g46a52ca4-dirty # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 894fa235eb4ca0bfa692dbe4932c2f940cdc8c1e # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot "sparse warnings: (new ones prefixed by >>)" >> drivers/net/wan/fsl_ucc_hdlc.c:305:57: sparse: sparse: incorrect type in >> argument 2 (different address spaces) @@ expected void [noderef] __iomem >> *addr @@ got restricted __be16 * @@ drivers/net/wan/fsl_ucc_hdlc.c:305:57: sparse: expected void [noderef] __iomem *addr drivers/net/wan/fsl_ucc_hdlc.c:305:57: sparse: got restricted __be16 * >> drivers/net/wan/fsl_ucc_hdlc.c:307:46: sparse: sparse: incorrect type in >> argument 2 (different address spaces) @@ expected void [noderef] __iomem >> *addr @@ got restricted __be32 * @@ drivers/net/wan/fsl_ucc_hdlc.c:307:46: sparse: expected void [noderef] __iomem *addr drivers/net/wan/fsl_ucc_hdlc.c:307:46: sparse: got restricted __be32 * drivers/net/wan/fsl_ucc_hdlc.c:316:57: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/net/wan/fsl_ucc_hdlc.c:316:57: sparse: expected void [noderef] __iomem *addr drivers/net/wan/fsl_ucc_hdlc.c:316:57: sparse: got restricted __be16 * drivers/net/wan/fsl_ucc_hdlc.c:318:46: sparse: sparse: incorrect type in argument 2 (different address spaces) @@ expected void [noderef] __iomem *addr @@ got restricted __be32 * @@ drivers/net/wan/fsl_ucc_hdlc.c:318:46: sparse: expected void [noderef] __iomem *addr drivers/net/wan/fsl_ucc_hdlc.c:318:46: sparse: got restricted __be32 * drivers/net/wan/fsl_ucc_hdlc.c:368:29: sparse: sparse: incorrect type in assignment (different base types) @@ expected unsigned short [usertype] @@ got restricted __be16 [usertype] @@ drivers/net/wan/fsl_ucc_hdlc.c:368:29: sparse: expected unsigned short [usertype] drivers/net/wan/fsl_ucc_hdlc.c:368:29: sparse: got restricted __be16 [usertype] drivers/net/wan/fsl_ucc_hdlc.c:375:36: sparse: sparse: restricted __be16 degrades to integer drivers/net/wan/fsl_ucc_hdlc.c:398:12: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct qe_bd [noderef] __iomem *bd @@ got struct qe_bd *curtx_bd @@ drivers/net/wan/fsl_ucc_hdlc.c:398:12: sparse: expected struct qe_bd [noderef] __iomem *bd drivers/net/wan/fsl_ucc_hdlc.c:398:12: sparse: got struct qe_bd *curtx_bd drivers/net/wan/fsl_ucc_hdlc.c:421:20: sparse: sparse: incorrect type in assignment (different address spaces) @@ expected struct qe_bd [noderef] __iomem *[assigned] bd @@ got struct qe_bd *tx_bd_base @@ drivers/net/wan/fsl_ucc_hdlc.c:421:20: sparse: expected struct qe_bd [noderef] __iomem *[assigned] bd drivers/net/wan/fsl_ucc_hdlc.c:421:20: sparse: got struct qe_bd *tx_bd_base drivers/net/wan/fsl_ucc_hdlc.c:423:16: sparse: sparse: incompatible types in comparison expression (different address spaces): drivers/net/wan/fsl_ucc_hdlc.c:423:16: sparse:struct qe_bd [noderef] __iomem * drivers/net/wan/fsl_ucc_hdlc.c:423:16: sparse:struct qe_bd * >> drivers/net/wan/fsl_ucc_hdlc.c:458:33: sparse: sparse: incorrect type in >> argument 1 (different address spaces) @@ expected void const [noderef] >> __iomem *addr @@ got restricted __be16 * @@ drivers/net/wan/fsl_ucc_hdlc.c:502:41: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/net/wan/fsl_ucc_hdlc.c:524:33: sparse: sparse: incorrect type in argument 1 (different address spaces) @@ expected void const [noderef] __iomem *addr @@ got restricted __be16 * @@ drivers/net/wan/fsl_ucc_hdlc.c:548:38: s
Re: [PATCH] mmc: sdhci-iproc: Add ACPI bindings for the rpi4
Hi Jeremy,
+add Nicolas
Am 08.01.21 um 22:13 schrieb Jeremy Linton:
> The rpi4 has a Arasan controller it carries over
> from the rpi3, and a newer eMMC2 controller.
> Because of a couple "quirks" it seems wiser to bind
> these controllers to the same driver that DT is using
> on this platform rather than the generic sdhci_acpi
> driver with PNP0D40.
>
> So, we use BCM2847 for the older Arasan and BRCME88C
> for the newer eMMC2.
>
> With this change linux is capable of utilizing the
> SD card slot, and the wifi on this platform
> with linux.
>
> Signed-off-by: Jeremy Linton
> ---
> drivers/mmc/host/sdhci-iproc.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index c9434b461aab..f79d97b41805 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -250,6 +250,14 @@ static const struct sdhci_pltfm_data
> sdhci_bcm2835_pltfm_data = {
> .ops = _iproc_32only_ops,
> };
>
> +static const struct sdhci_pltfm_data sdhci_bcm_arasan_data = {
> + .quirks = SDHCI_QUIRK_BROKEN_CARD_DETECTION |
> + SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> + SDHCI_QUIRK_NO_HISPD_BIT,
> + .quirks2 = SDHCI_QUIRK2_PRESET_VALUE_BROKEN,
> + .ops = _iproc_32only_ops,
> +};
Why do we need an almost exact copy of bcm2835_data which works fine for
all Raspberry Pi boards?
> +
> static const struct sdhci_iproc_data bcm2835_data = {
> .pdata = _bcm2835_pltfm_data,
> .caps = ((0x1 << SDHCI_MAX_BLOCK_SHIFT)
> @@ -261,6 +269,10 @@ static const struct sdhci_iproc_data bcm2835_data = {
> .mmc_caps = 0x,
> };
>
> +static const struct sdhci_iproc_data bcm_arasan_data = {
> + .pdata = _bcm_arasan_data,
> +};
> +
> static const struct sdhci_ops sdhci_iproc_bcm2711_ops = {
> .read_l = sdhci_iproc_readl,
> .read_w = sdhci_iproc_readw,
> @@ -299,6 +311,8 @@ MODULE_DEVICE_TABLE(of, sdhci_iproc_of_match);
> static const struct acpi_device_id sdhci_iproc_acpi_ids[] = {
> { .id = "BRCM5871", .driver_data = (kernel_ulong_t)_cygnus_data },
> { .id = "BRCM5872", .driver_data = (kernel_ulong_t)_data },
> + { .id = "BCM2847", .driver_data = (kernel_ulong_t)_arasan_data },
Sorry, i don't have deeper knowledge about ACPI, but BCM2837 is the
official naming of the SoC on the RPi 3.
Is this a typo in the id?
> + { .id = "BRCME88C", .driver_data = (kernel_ulong_t)_data },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(acpi, sdhci_iproc_acpi_ids);
[PATCH v2 2/3] regulator: mt6358: Add OF match table
From: Matthias Brugger
The binding documentation mentions that a compatible is required for the
MT6358 device node. But the driver does not provide a OF match table.
This way auto-loading is broken as the MFD driver that registers the
device has a .of_compatible set which makes the platform .uevent
callback report a OF modalias, but that's not in the module.
Fixes: f67ff1bd58f0 ("regulator: mt6358: Add support for MT6358 regulator")
Signed-off-by: Matthias Brugger
---
Changes in v2:
- check for CONFIG_OF
- add Fixes tag
drivers/regulator/mt6358-regulator.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/regulator/mt6358-regulator.c
b/drivers/regulator/mt6358-regulator.c
index 13cb6ac9a892..a4ed19a54ec6 100644
--- a/drivers/regulator/mt6358-regulator.c
+++ b/drivers/regulator/mt6358-regulator.c
@@ -534,9 +534,18 @@ static const struct platform_device_id
mt6358_platform_ids[] = {
};
MODULE_DEVICE_TABLE(platform, mt6358_platform_ids);
+#ifdef CONFIG_OF
+static const struct of_device_id mt6358_of_match[] = {
+ { .compatible = "mediatek,mt6358-regulator", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mt6358_of_match);
+#endif
+
static struct platform_driver mt6358_regulator_driver = {
.driver = {
.name = "mt6358-regulator",
+ .of_match_table = of_match_ptr(mt6358_of_match),
},
.probe = mt6358_regulator_probe,
.id_table = mt6358_platform_ids,
--
2.29.2
[PATCH v2 1/3] regulator: mt6360: Add OF match table
From: Matthias Brugger
Binding documentation mentions that a compatible is required for the
MT6360 device node, but the driver doesn't provide a OF match table.
Fixes: d321571d5e4c ("regulator: mt6360: Add support for MT6360 regulator")
Signed-off-by: Matthias Brugger
---
Changes in v2:
- check for CONFIG_OF
- add Fixes tag
drivers/regulator/mt6360-regulator.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/regulator/mt6360-regulator.c
b/drivers/regulator/mt6360-regulator.c
index 15308ee29c13..f7b2514feabf 100644
--- a/drivers/regulator/mt6360-regulator.c
+++ b/drivers/regulator/mt6360-regulator.c
@@ -445,9 +445,18 @@ static const struct platform_device_id
mt6360_regulator_id_table[] = {
};
MODULE_DEVICE_TABLE(platform, mt6360_regulator_id_table);
+#ifdef CONFIG_OF
+static const struct of_device_id mt6360_of_match[] = {
+ { .compatible = "mediatek,mt6360-regulator", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mt6360_of_match);
+#endif
+
static struct platform_driver mt6360_regulator_driver = {
.driver = {
.name = "mt6360-regulator",
+ .of_match_table = of_match_ptr(mt6360_of_match),
},
.probe = mt6360_regulator_probe,
.id_table = mt6360_regulator_id_table,
--
2.29.2
[PATCH v2 3/3] regulator: mt6323: Add OF match table
From: Matthias Brugger
The binding documentation mentions that a compatible is required for the
MT6323 device node. But the driver does not provide a OF match table.
This way auto-loading is broken as the MFD driver that registers the
device has a .of_compatible set which makes the platform .uevent
callback report a OF modalias, but that's not in the module.
Fixes: 2fdf82923618 ("regulator: mt6323: Add support for MT6323 regulator")
Signed-off-by: Matthias Brugger
---
Changes in v2:
- check for CONFIG_OF
- add Fixes tag
drivers/regulator/mt6323-regulator.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/regulator/mt6323-regulator.c
b/drivers/regulator/mt6323-regulator.c
index ff9016170db3..646742d4db74 100644
--- a/drivers/regulator/mt6323-regulator.c
+++ b/drivers/regulator/mt6323-regulator.c
@@ -406,9 +406,18 @@ static const struct platform_device_id
mt6323_platform_ids[] = {
};
MODULE_DEVICE_TABLE(platform, mt6323_platform_ids);
+#ifdef CONFIG_OF
+static const struct of_device_id mt6323_of_match[] = {
+ { .compatible = "mediatek,mt6323-regulator", },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(of, mt6323_of_match);
+#endif
+
static struct platform_driver mt6323_regulator_driver = {
.driver = {
.name = "mt6323-regulator",
+ .of_match_table = of_match_ptr(mt6323_of_match),
},
.probe = mt6323_regulator_probe,
.id_table = mt6323_platform_ids,
--
2.29.2
Re: [PATCH v3 2/2] misc: pvpanic: introduce module parameter 'events'
On Fri, Jan 08, 2021 at 04:26:17PM +0100, Paolo Bonzini wrote: > On 08/01/21 16:15, Greg KH wrote: > > On Fri, Jan 08, 2021 at 04:04:24PM +0100, Paolo Bonzini wrote: > > > On 08/01/21 15:07, Greg KH wrote: > > > > >static void __iomem *base; > > > > > +static unsigned int events = PVPANIC_PANICKED | PVPANIC_CRASH_LOADED; > > > > > +module_param(events, uint, 0644); > > > > > +MODULE_PARM_DESC(events, "set event limitation of pvpanic device"); > > > > I do not understand you wanting a module parameter as well as a sysfs > > > > file. Why is this needed? Why are you spreading this information out > > > > across different apis and locations? > > > > > > It can be useful to disable some functionality, for example in case you > > > want > > > to fake running on an older virtualization host. This can be done for > > > debugging reasons, or to keep uniform handling across a fleet that is > > > running different versions of QEMU. > > > > And where is this all going to be documented? > > I don't disagree. > > > And what's wrong with just making the sysfs attribute writable? > > Isn't it harder to configure it at boot? Also the sysfs attribute added by > patch 1 is documenting what is supported by the device, while the module > parameter can be set to any value (you can think of the module parameter as > of a "what to log" option, except the logging happens on another machine). But the module parameter is global, and not device specific. And yes, it would be harder to configure this at boot, is this something that is required? If so, please document that somewhere. > Therefore, if you make the sysfs attribute writable, you would actually need > _two_ attributes, one for the in-use capabilities and one for the device > capabilities. And sysfs files are runtime values, which is different > concept than 0444 module parameters (which are more like just > configuration). That's not the module parameter mode setting in this patch :( > So you would have to decide whether it's valid to write 2 > to the in-use capabilities file when the device capabilities are "1", and I > don't really have a good answer for that. > > Also considering that there will not be more than one copy of this device > (it doesn't make sense as they would all do exactly the same thing), in this > case a module parameter really seems to be the simplest way to configure it. So you never can have more than one of these in the system at one time? Because if this ever becomes not true, the module parameter is a mess... thanks, greg k-h
[PATCH] evm: Fix memleak in init_desc
When kmalloc() fails, tmp_tfm allocated by
crypto_alloc_shash() has not been freed, which
leads to memleak.
Fixes: d46eb3699502b ("evm: crypto hash replaced by shash")
Signed-off-by: Dinghao Liu
---
security/integrity/evm/evm_crypto.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/security/integrity/evm/evm_crypto.c
b/security/integrity/evm/evm_crypto.c
index 168c3b78ac47..39fb31a638ac 100644
--- a/security/integrity/evm/evm_crypto.c
+++ b/security/integrity/evm/evm_crypto.c
@@ -73,7 +73,7 @@ static struct shash_desc *init_desc(char type, uint8_t
hash_algo)
{
long rc;
const char *algo;
- struct crypto_shash **tfm, *tmp_tfm;
+ struct crypto_shash **tfm, *tmp_tfm = NULL;
struct shash_desc *desc;
if (type == EVM_XATTR_HMAC) {
@@ -118,13 +118,18 @@ static struct shash_desc *init_desc(char type, uint8_t
hash_algo)
alloc:
desc = kmalloc(sizeof(*desc) + crypto_shash_descsize(*tfm),
GFP_KERNEL);
- if (!desc)
+ if (!desc) {
+ if (tmp_tfm)
+ crypto_free_shash(tmp_tfm);
return ERR_PTR(-ENOMEM);
+ }
desc->tfm = *tfm;
rc = crypto_shash_init(desc);
if (rc) {
+ if (tmp_tfm)
+ crypto_free_shash(tmp_tfm);
kfree(desc);
return ERR_PTR(rc);
}
--
2.17.1
possible deadlock in evdev_pass_values
Hello,
syzbot found the following issue on:
HEAD commit:6207214a Merge tag 'afs-fixes-04012021' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16558750d0
kernel config: https://syzkaller.appspot.com/x/.config?x=8aa30b9da402d224
dashboard link: https://syzkaller.appspot.com/bug?extid=44ec99f248f7052472f1
compiler: gcc (GCC) 10.1.0-syz 20200507
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+44ec99f248f705247...@syzkaller.appspotmail.com
=
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
5.11.0-rc2-syzkaller #0 Not tainted
-
syz-executor.4/17012 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
888013a7f210 (>fa_lock){.+.+}-{2:2}, at: kill_fasync_rcu
fs/fcntl.c:1004 [inline]
888013a7f210 (>fa_lock){.+.+}-{2:2}, at: kill_fasync fs/fcntl.c:1025
[inline]
888013a7f210 (>fa_lock){.+.+}-{2:2}, at: kill_fasync+0x14b/0x460
fs/fcntl.c:1018
and this task is already holding:
88806c53b028 (>buffer_lock){..-.}-{2:2}, at: spin_lock
include/linux/spinlock.h:354 [inline]
88806c53b028 (>buffer_lock){..-.}-{2:2}, at:
evdev_pass_values.part.0+0xf6/0x970 drivers/input/evdev.c:261
which would create a new lock dependency:
(>buffer_lock){..-.}-{2:2} -> (>fa_lock){.+.+}-{2:2}
but this new dependency connects a SOFTIRQ-irq-safe lock:
(>buffer_lock){..-.}-{2:2}
... which became SOFTIRQ-irq-safe at:
lock_acquire kernel/locking/lockdep.c:5437 [inline]
lock_acquire+0x29d/0x740 kernel/locking/lockdep.c:5402
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151
spin_lock include/linux/spinlock.h:354 [inline]
evdev_pass_values.part.0+0xf6/0x970 drivers/input/evdev.c:261
evdev_pass_values drivers/input/evdev.c:253 [inline]
evdev_events+0x28b/0x3f0 drivers/input/evdev.c:306
input_to_handler+0x2a0/0x4c0 drivers/input/input.c:115
input_pass_values.part.0+0x284/0x700 drivers/input/input.c:145
input_pass_values drivers/input/input.c:134 [inline]
input_handle_event+0x373/0x1440 drivers/input/input.c:404
input_event drivers/input/input.c:446 [inline]
input_event+0x8e/0xb0 drivers/input/input.c:438
input_sync include/linux/input.h:450 [inline]
usbtouch_process_pkt+0x25c/0x460
drivers/input/touchscreen/usbtouchscreen.c:1404
usbtouch_irq+0x192/0x380 drivers/input/touchscreen/usbtouchscreen.c:1517
__usb_hcd_giveback_urb+0x2b0/0x5c0 drivers/usb/core/hcd.c:1657
usb_hcd_giveback_urb+0x367/0x410 drivers/usb/core/hcd.c:1728
dummy_timer+0x11f4/0x3280 drivers/usb/gadget/udc/dummy_hcd.c:1971
call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1417
expire_timers kernel/time/timer.c:1462 [inline]
__run_timers.part.0+0x67c/0xa50 kernel/time/timer.c:1731
__run_timers kernel/time/timer.c:1712 [inline]
run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1744
__do_softirq+0x2a5/0x9f7 kernel/softirq.c:343
asm_call_irq_on_stack+0xf/0x20
__run_on_irqstack arch/x86/include/asm/irq_stack.h:26 [inline]
run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:77 [inline]
do_softirq_own_stack+0xaa/0xd0 arch/x86/kernel/irq_64.c:77
invoke_softirq kernel/softirq.c:226 [inline]
__irq_exit_rcu kernel/softirq.c:420 [inline]
irq_exit_rcu+0x134/0x200 kernel/softirq.c:432
sysvec_apic_timer_interrupt+0x4d/0x100 arch/x86/kernel/apic/apic.c:1096
asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:628
__orc_find+0x0/0xf0 include/asm-generic/rwonce.h:68
orc_find arch/x86/kernel/unwind_orc.c:173 [inline]
unwind_next_frame+0x342/0x1f90 arch/x86/kernel/unwind_orc.c:443
arch_stack_walk+0x7d/0xe0 arch/x86/kernel/stacktrace.c:25
stack_trace_save+0x8c/0xc0 kernel/stacktrace.c:121
kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
kasan_set_track+0x1c/0x30 mm/kasan/common.c:46
kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:356
kasan_slab_free+0xe1/0x110 mm/kasan/common.c:362
kasan_slab_free include/linux/kasan.h:188 [inline]
slab_free_hook mm/slub.c:1547 [inline]
slab_free_freelist_hook+0x5d/0x150 mm/slub.c:1580
slab_free mm/slub.c:3142 [inline]
kfree+0xdb/0x360 mm/slub.c:4124
tomoyo_realpath_from_path+0x191/0x620 security/tomoyo/realpath.c:291
tomoyo_get_realpath security/tomoyo/file.c:151 [inline]
tomoyo_path_perm+0x21b/0x400 security/tomoyo/file.c:822
security_inode_getattr+0xcf/0x140 security/security.c:1280
vfs_getattr fs/stat.c:121 [inline]
vfs_statx+0x164/0x390 fs/stat.c:189
vfs_fstatat fs/stat.c:207 [inline]
vfs_lstat include/linux/fs.h:3122 [inline]
__do_sys_newlstat+0x91/0x110 fs/stat.c:362
do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
entry_SYSCALL_64_after_hwframe+0x44/0xa9
to a SOFTIRQ-irq-unsafe lock:
(>fa_lock){.+.+}-{2:2}
... which became
[PATCH] netfilter: Fix memleak in nf_nat_init
When register_pernet_subsys() fails, nf_nat_bysource
should be freed just like when nf_ct_extend_register()
fails.
Fixes: 1cd472bf036ca ("netfilter: nf_nat: add nat hook register functions to
nf_nat")
Signed-off-by: Dinghao Liu
---
net/netfilter/nf_nat_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/netfilter/nf_nat_core.c b/net/netfilter/nf_nat_core.c
index ea923f8cf9c4..b7c3c902290f 100644
--- a/net/netfilter/nf_nat_core.c
+++ b/net/netfilter/nf_nat_core.c
@@ -1174,6 +1174,7 @@ static int __init nf_nat_init(void)
ret = register_pernet_subsys(_net_ops);
if (ret < 0) {
nf_ct_extend_unregister(_extend);
+ kvfree(nf_nat_bysource);
return ret;
}
--
2.17.1
Re: [PATCH] netfilter: Fix memleak in nf_nat_init
Dinghao Liu wrote: > When register_pernet_subsys() fails, nf_nat_bysource > should be freed just like when nf_ct_extend_register() > fails. Acked-by: Florian Westphal
[PATCH v3] staging: media: rkvdec: rkvdec.c: Use semicolon in place of comma
Line 146 had a comma in place of a semicolon. Fix it. Signed-off-by: Sri Laasya Nutheti --- v3: Corrected email recipients drivers/staging/media/rkvdec/rkvdec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/media/rkvdec/rkvdec.c b/drivers/staging/media/rkvdec/rkvdec.c index aa4f8c287618..d3eb81ee8dc2 100644 --- a/drivers/staging/media/rkvdec/rkvdec.c +++ b/drivers/staging/media/rkvdec/rkvdec.c @@ -143,7 +143,7 @@ static void rkvdec_reset_fmt(struct rkvdec_ctx *ctx, struct v4l2_format *f, memset(f, 0, sizeof(*f)); f->fmt.pix_mp.pixelformat = fourcc; f->fmt.pix_mp.field = V4L2_FIELD_NONE; - f->fmt.pix_mp.colorspace = V4L2_COLORSPACE_REC709, + f->fmt.pix_mp.colorspace = V4L2_COLORSPACE_REC709; f->fmt.pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT; f->fmt.pix_mp.quantization = V4L2_QUANTIZATION_DEFAULT; f->fmt.pix_mp.xfer_func = V4L2_XFER_FUNC_DEFAULT; -- 2.17.1 signature.asc Description: PGP signature
Re: [PATCH v4 mips-next 0/7] MIPS: vmlinux.lds.S sections fixes & cleanup
On Thu, Jan 07, 2021 at 12:33:38PM +, Alexander Lobakin wrote: > This series hunts the problems discovered after manual enabling of > ARCH_WANT_LD_ORPHAN_WARN. Notably: > - adds the missing PAGE_ALIGNED_DATA() section affecting VDSO >placement (marked for stable); > - properly stops .eh_frame section generation. > > Compile and runtime tested on MIPS32R2 CPS board with no issues > using two different toolkits: > - Binutils 2.35.1, GCC 10.2.0; > - LLVM stack 11.0.0. > > Since v3 [2]: > - fix the third patch as GNU stack emits .rel.dyn into VDSO for >some reason if .cfi_sections is specified. > > Since v2 [1]: > - stop discarding .eh_frame and just prevent it from generating >(Kees); > - drop redundant sections assertions (Fangrui); > - place GOT table in .text instead of asserting as it's not empty >when building with LLVM (Nathan); > - catch compound literals in generic definitions when building with >LD_DEAD_CODE_DATA_ELIMINATION (Kees); > - collect two Reviewed-bys (Kees). > > Since v1 [0]: > - catch .got entries too as LLD may produce it (Nathan); > - check for unwanted sections to be zero-sized instead of >discarding (Fangrui). > > [0] https://lore.kernel.org/linux-mips/20210104121729.46981-1-aloba...@pm.me > [1] https://lore.kernel.org/linux-mips/20210106200713.31840-1-aloba...@pm.me > [2] https://lore.kernel.org/linux-mips/20210107115120.281008-1-aloba...@pm.me > > Alexander Lobakin (7): > MIPS: vmlinux.lds.S: add missing PAGE_ALIGNED_DATA() section > MIPS: vmlinux.lds.S: add ".gnu.attributes" to DISCARDS > MIPS: properly stop .eh_frame generation > MIPS: vmlinux.lds.S: catch bad .rel.dyn at link time > MIPS: vmlinux.lds.S: explicitly declare .got table > vmlinux.lds.h: catch compound literals into data and BSS > MIPS: select ARCH_WANT_LD_ORPHAN_WARN this breaks my builds: LD vmlinux.o MODPOST vmlinux.symvers MODINFO modules.builtin.modinfo GEN modules.builtin LD .tmp_vmlinux.kallsyms1 mips64-linux-gnu-ld: Unexpected run-time relocations (.rel) detected! $ mips64-linux-gnu-ld --version GNU ld version 2.27-3.fc24 $ mips64-linux-gnu-gcc --version mips64-linux-gnu-gcc (GCC) 6.1.1 20160621 (Red Hat Cross 6.1.1-2) Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea.[ RFC1925, 2.3 ]
Is Trump dead?
Is Trump dead? He never made it to the Capitol, was he killed? There's radio silence now. As a linux Kernel dev how does this make you feel?
Grsecurity GPL Violations: Linus/FSF/SFConservancy won't defend. Claw back your copyrights. BSD-in-Practice was not the deal.
Silence is consent. Are there FOSS developers making decent money via Patreon, GoFundMe, whatever? Yes, Grsecurity is making good money. They simply added a no-redistribution agreement to their patch of the Linux Kernel. ( https://perens.com/2017/06/28/warning-grsecurity-potential-contributory-infringement-risk-for-customers/ ) The FSF, Software Freedom Conservancy, and the Corporate Linux Kernel Developers all agree that this is fine (silence is consent). https://twitter.com/spendergrsec/status/1293155787859206146 Importantly, neither the FSF nor the SFC, nor in fact any actual lawyer agrees with this bizarre claim from an anonymous troll. More info about the source of the claim can be found here: https://grsecurity.net/setting_the_record_straight_on_oss_v_perens_part1 Thanks for doing your part, "Dr" to continue the troll's harrassment LOL. " #GRSecurity violates both the Linux kernel's copyright and the #GCC #copyright by forbidding redistribution of the patches (in their Access Agreement): which are non-seperable derivative works... Contributors should blanket-revoke their contributions from all free-takers since they didn't agree to BSD-in-Practice. They should also claw-back any transferred copyrights from the FSF using the 30 year clawback provision in the US Copyright Act. Design of how a program works is a copyrightable aspect (Ex: How RMS designed GCC 30 years ago or so etc) Had to repost this because the linux admins deleted the email: https://lkml.org/lkml/2020/12/28/2518 The message you requested cannot be found. The message you requested cannot be found. The message with the url http://feisty.lkml.org/lkml/2020/12/28/2518 does not exist in the database. Grsecurity GPL Violations: Bring a CASE act claim every time GrSecurity releases a new infringing work? (GRSecurity blatantly violates the clause in the Linux kernel and GCC copyright licenses regarding adding addtional terms between the licensee of the kernel / gcc and furthur down-the-line licensees, regarding derivative works) (The linux kernel has 1000s of copyright holders) (All who shake at the knees at the thought of initiating a federal Copyright lawsuit)
Re: [PATCH v2 4.9 00/10] fix a race in release_task when flushing the dentry
On Fri, Jan 08, 2021 at 10:42:47AM +0800, Wen Yang wrote:
>
>
> 在 2021/1/8 上午2:28, Greg Kroah-Hartman 写道:
> > On Fri, Jan 08, 2021 at 12:21:38AM +0800, Wen Yang wrote:
> > >
> > >
> > > 在 2021/1/7 下午8:17, Greg Kroah-Hartman 写道:
> > > > On Thu, Jan 07, 2021 at 03:52:12PM +0800, Wen Yang wrote:
> > > > > The dentries such as /proc//ns/ have the DCACHE_OP_DELETE flag,
> > > > > they
> > > > > should be deleted when the process exits.
> > > > >
> > > > > Suppose the following race appears：
> > > > >
> > > > > release_task dput
> > > > > -> proc_flush_task
> > > > >-> dentry->d_op->d_delete(dentry)
> > > > > -> __exit_signal
> > > > >-> dentry->d_lockref.count-- and
> > > > > return.
> > > > >
> > > > > In the proc_flush_task(), if another process is using this dentry, it
> > > > > will
> > > > > not be deleted. At the same time, in dput(), d_op->d_delete() can be
> > > > > executed
> > > > > before __exit_signal(pid has not been hashed), d_delete returns
> > > > > false, so
> > > > > this dentry still cannot be deleted.
> > > > >
> > > > > This dentry will always be cached (although its count is 0 and the
> > > > > DCACHE_OP_DELETE flag is set), its parent denry will also be cached
> > > > > too, and
> > > > > these dentries can only be deleted when drop_caches is manually
> > > > > triggered.
> > > > >
> > > > > This will result in wasted memory. What's more troublesome is that
> > > > > these
> > > > > dentries reference pid, according to the commit f333c700c610 ("pidns:
> > > > > Add a
> > > > > limit on the number of pid namespaces"), if the pid cannot be
> > > > > released, it
> > > > > may result in the inability to create a new pid_ns.
> > > > >
> > > > > This issue was introduced by 60347f6716aa ("pid namespaces: prepare
> > > > > proc_flust_task() to flush entries from multiple proc trees"),
> > > > > exposed by
> > > > > f333c700c610 ("pidns: Add a limit on the number of pid namespaces"),
> > > > > and then
> > > > > fixed by 7bc3e6e55acf ("proc: Use a list of inodes to flush from
> > > > > proc").
> > > >
> > > > Why are you just submitting a series for 4.9 and 4.19, what about 4.14?
> > > > We can't have users move to a newer kernel and then experience old bugs,
> > > > right?
> > > >
> > > Okay, the patches corresponding to 4.14 will be ready later.
> >
> > Note for some reason you didn't cc: the stable list for these patches :(
> >
> > > > But the larger question is why are you backporting a whole new feature
> > > > here? Why is CLONE_PIDFD needed? That feels really wrong...
> > > >
> > >
> > > The reason for backporting CLONE_PIDFD is because 7bc3e6e55acf ("proc:
> > > Use a
> > > list of inodes to flush from proc") relies on wait_pidfd.lock. There are
> > > indeed many associated modifications here. We are also testing it. Please
> > > check the code more.
> >
> > Is the only "issue" here wasted memory? Will it eventually be freed
> > anyway even if you do not echo to the proc file to flush caches?
> >
> > You mention the inability to create a new pid for a specific namespace,
> > is that really a problem? Shouldn't the code handle such issues
> > normally? What breaks without these changes?
> >
> > I think at this point, it might just time for you to move to a newer
> > kernel release, as adding a whole new userspace feature for this feels
> > really really odd.
> >
> > What is preventing you from doing that today? What holds you to older
> > kernels that will not allow you to move forward?
> >
>
> We have encountered this problem in the cloud server environment. Users will
> frequently create and delete containers, and the corresponding pid_ns will
> accumulate, eventually making it impossible to create a new container.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=208613
>
> The kernels (4.9/4.19) used on a large scale in our current production
> environment (almost tens of thousands of machines) may need to be fixed.
What prevents you from moving them to 5.4 or better yet, 5.10? You will
have to do it soon anyway, I'm sure you have been testing those kernels
to validate that all works well with them on a subset of your
environment, so for those systems that have this problem, why can't you
update the base kernel?
thanks,
greg k-h
Re: [PATCH v2 -next] media: rkvdec: convert comma to semicolon
On Fri, 2021-01-08 at 17:22 +0800, Zheng Yongjun wrote: > Replace a comma between expression statements by a semicolon. > > Signed-off-by: Zheng Yongjun > --- > drivers/staging/media/rkvdec/rkvdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/media/rkvdec/rkvdec.c > b/drivers/staging/media/rkvdec/rkvdec.c > index d25c4a37e2af..66572066e7a0 100644 > --- a/drivers/staging/media/rkvdec/rkvdec.c > +++ b/drivers/staging/media/rkvdec/rkvdec.c > @@ -130,7 +130,7 @@ static void rkvdec_reset_fmt(struct rkvdec_ctx *ctx, > struct v4l2_format *f, > memset(f, 0, sizeof(*f)); > f->fmt.pix_mp.pixelformat = fourcc; > f->fmt.pix_mp.field = V4L2_FIELD_NONE; > - f->fmt.pix_mp.colorspace = V4L2_COLORSPACE_REC709, > + f->fmt.pix_mp.colorspace = V4L2_COLORSPACE_REC709; > f->fmt.pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT; > f->fmt.pix_mp.quantization = V4L2_QUANTIZATION_DEFAULT; > f->fmt.pix_mp.xfer_func = V4L2_XFER_FUNC_DEFAULT; Seems a fix was sent already for this: https://patchwork.kernel.org/project/linux-rockchip/patch/20201204233743.GA8530@linuxmint-midtower-pc/ Thanks, Ezequiel
Re: [PATCH v3] staging: media: rkvdec: rkvdec.c: Use semicolon in place of comma
On Sat, 2021-01-09 at 17:43 +0530, Sri Laasya Nutheti wrote: > Line 146 had a comma in place of a semicolon. Fix it. > > Signed-off-by: Sri Laasya Nutheti > --- > v3: Corrected email recipients > drivers/staging/media/rkvdec/rkvdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/media/rkvdec/rkvdec.c > b/drivers/staging/media/rkvdec/rkvdec.c > index aa4f8c287618..d3eb81ee8dc2 100644 > --- a/drivers/staging/media/rkvdec/rkvdec.c > +++ b/drivers/staging/media/rkvdec/rkvdec.c > @@ -143,7 +143,7 @@ static void rkvdec_reset_fmt(struct rkvdec_ctx *ctx, > struct v4l2_format *f, > memset(f, 0, sizeof(*f)); > f->fmt.pix_mp.pixelformat = fourcc; > f->fmt.pix_mp.field = V4L2_FIELD_NONE; > - f->fmt.pix_mp.colorspace = V4L2_COLORSPACE_REC709, > + f->fmt.pix_mp.colorspace = V4L2_COLORSPACE_REC709; > f->fmt.pix_mp.ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT; > f->fmt.pix_mp.quantization = V4L2_QUANTIZATION_DEFAULT; > f->fmt.pix_mp.xfer_func = V4L2_XFER_FUNC_DEFAULT; A fix was sent already for this: https://patchwork.kernel.org/project/linux-rockchip/patch/20201204233743.GA8530@linuxmint-midtower-pc/ Thanks, Ezequiel
BUG: key ffff8b521bda9148 has not been registered!
Hi folks! I started to see this message every boot after replacing Radeon VII to 6900XT. $ journalctl | grep "BUG: key" Dec 31 05:19:42 localhost.localdomain kernel: BUG: key 98b59ab01148 has not been registered! Dec 31 05:25:44 localhost.localdomain kernel: BUG: key 8d425ba01148 has not been registered! Jan 02 17:36:25 localhost.localdomain kernel: BUG: key 935e5a959148 has not been registered! Jan 03 03:29:08 localhost.localdomain kernel: BUG: key 8d425b0b9148 has not been registered! Jan 03 03:33:35 localhost.localdomain kernel: BUG: key 8bc35aef9148 has not been registered! Jan 03 16:47:44 localhost.localdomain kernel: BUG: key 9a3cdb959148 has not been registered! Jan 06 14:59:58 localhost.localdomain kernel: BUG: key 97b6db9f9148 has not been registered! Jan 07 14:51:49 localhost.localdomain kernel: BUG: key 8f2dda569148 has not been registered! Jan 07 15:08:23 localhost.localdomain kernel: BUG: key a0849bd31148 has not been registered! Jan 08 18:07:28 localhost.localdomain kernel: BUG: key 89721a0e9148 has not been registered! Jan 08 18:12:51 localhost.localdomain kernel: BUG: key 8b521bda9148 has not been registered! Here is trace: [6.333672] [drm] REG_WAIT timeout 1us * 10 tries - mpc2_assert_idle_mpcc line:480 [6.335258] BUG: key 8b521bda9148 has not been registered! [6.335271] [ cut here ] [6.335273] DEBUG_LOCKS_WARN_ON(1) [6.335279] WARNING: CPU: 18 PID: 525 at kernel/locking/lockdep.c:4618 lockdep_init_map_waits+0x18b/0x210 [6.335284] Modules linked in: fjes(-) amdgpu(+) iommu_v2 gpu_sched ttm drm_kms_helper crct10dif_pclmul crc32_pclmul crc32c_intel cec drm ghash_clmulni_intel ccp igb nvme nvme_core dca i2c_algo_bit wmi pinctrl_amd fuse [6.335298] CPU: 18 PID: 525 Comm: systemd-udevd Not tainted 5.10.0-0.rc6.20201204git34816d20f173.92.fc34.x86_64 #1 [6.335302] Hardware name: System manufacturer System Product Name/ROG STRIX X570-I GAMING, BIOS 2802 10/21/2020 [6.335306] RIP: 0010:lockdep_init_map_waits+0x18b/0x210 [6.335309] Code: 00 85 c0 0f 84 75 ff ff ff 8b 3d 18 c4 f1 01 85 ff 0f 85 67 ff ff ff 48 c7 c6 68 43 60 97 48 c7 c7 1d 90 5a 97 e8 70 1f b6 00 <0f> 0b e9 4d ff ff ff e8 19 59 bc 00 85 c0 74 21 44 8b 1d e6 c3 f1 [6.335315] RSP: 0018:9e5a013d3910 EFLAGS: 00010282 [6.335317] RAX: 0016 RBX: 97247d80 RCX: 8b5908fdb238 [6.335320] RDX: ffd8 RSI: 0027 RDI: 8b5908fdb230 [6.335322] RBP: 8b520e2a7978 R08: R09: [6.335325] R10: 9e5a013d3740 R11: 8b592e2fffe8 R12: 8b521bda9148 [6.335327] R13: R14: 8b521bc30330 R15: 8b521bc30330 [6.335330] FS: 7fe019eb9140() GS:8b5908e0() knlGS: [6.335333] CS: 0010 DS: ES: CR0: 80050033 [6.335336] CR2: 7fe018f5e000 CR3: 0001142ee000 CR4: 00350ee0 [6.335338] Call Trace: [6.335342] __kernfs_create_file+0x7b/0x100 [6.335344] sysfs_add_file_mode_ns+0xa3/0x190 [6.335347] sysfs_create_bin_file+0x50/0x70 [6.335428] hdcp_create_workqueue+0x3bd/0x410 [amdgpu] [6.335499] amdgpu_dm_init.isra.0.cold+0x136/0x126d [amdgpu] [6.335570] ? psp_set_srm+0xb0/0xb0 [amdgpu] [6.335637] ? hdcp_update_display+0x1f0/0x1f0 [amdgpu] [6.335641] ? dev_printk_emit+0x3e/0x40 [6.335709] dm_hw_init+0xe/0x20 [amdgpu] [6.335776] amdgpu_device_init.cold+0x18c3/0x1bbc [amdgpu] [6.335781] ? pci_bus_read_config_word+0x39/0x50 [6.335831] amdgpu_driver_load_kms+0x2b/0x1f0 [amdgpu] [6.335879] amdgpu_pci_probe+0x129/0x1b0 [amdgpu] [6.335889] local_pci_probe+0x42/0x80 [6.335891] pci_device_probe+0xd9/0x1a0 [6.335896] really_probe+0x205/0x460 [6.335898] driver_probe_device+0xe1/0x150 [6.335901] device_driver_attach+0xa8/0xb0 [6.335904] __driver_attach+0x8c/0x150 [6.335907] ? device_driver_attach+0xb0/0xb0 [6.335909] ? device_driver_attach+0xb0/0xb0 [6.335911] bus_for_each_dev+0x67/0x90 [6.335914] bus_add_driver+0x12e/0x1f0 [6.335917] driver_register+0x8b/0xe0 [6.335919] ? 0xc0e4c000 [6.335922] do_one_initcall+0x67/0x320 [6.335925] ? rcu_read_lock_sched_held+0x3f/0x80 [6.335928] ? trace_kmalloc+0xb2/0xe0 [6.335930] ? kmem_cache_alloc_trace+0x157/0x270 [6.335934] do_init_module+0x5c/0x260 [6.335936] __do_sys_init_module+0x13d/0x1a0 [6.335940] do_syscall_64+0x33/0x40 [6.335943] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [6.335945] RIP: 0033:0x7fe01aab2efe [6.335948] Code: 48 8b 0d 7d 1f 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 4a 1f 0c 00 f7 d8 64 89 01 48 [6.335953] RSP: 002b:7ffdf4879928 EFLAGS: 0246 ORIG_RAX: 00af [6.335957] RAX:
[PATCH 3/8] i2c: remove licence boilerplate from i2c-dev UAPI header
Remove boilerplate because we now have the SPDX header. Signed-off-by: Wolfram Sang --- include/uapi/linux/i2c-dev.h | 25 + 1 file changed, 5 insertions(+), 20 deletions(-) diff --git a/include/uapi/linux/i2c-dev.h b/include/uapi/linux/i2c-dev.h index 85f8047afcf2..1c4cec4ddd84 100644 --- a/include/uapi/linux/i2c-dev.h +++ b/include/uapi/linux/i2c-dev.h @@ -1,25 +1,10 @@ /* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */ /* -i2c-dev.h - i2c-bus driver, char device interface - -Copyright (C) 1995-97 Simon G. Vogl -Copyright (C) 1998-99 Frodo Looijaard - -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or -(at your option) any later version. - -This program is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -GNU General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, -MA 02110-1301 USA. -*/ + * i2c-dev.h - I2C bus char device interface + * + * Copyright (C) 1995-97 Simon G. Vogl + * Copyright (C) 1998-99 Frodo Looijaard + */ #ifndef _UAPI_LINUX_I2C_DEV_H #define _UAPI_LINUX_I2C_DEV_H -- 2.29.2
[PATCH 0/8] i2c: improve RECV_LEN documentation & usage
Because I want to clarify I2C_M_RECV len usage, this series updates the documentation and some of its users. Patch 1 refactors the whole documentation of 'i2c_msg', so all usage of I2C_M_* flags and their conditions hopefully become clearer. Patch 2+3 remove some obvious boilerplate in the UAPI headers while here. Patch 4 is a driver fix I found while working on this series. Patch 5 introduces a new convenience macro to enable SMBus transfers which need I2C_M_RECV_LEN. Then, some drivers use the new macro, sometimes to remove boilerplate, sometimes because these SMBus transfers have been forgotten before. This series is the first part of a larger work to extend I2C_M_RECV_LEN to allow larger transfer sizes (as specified in the SMBus 3.0 standard) and to enable this on Renesas R-Car hardware. Looking forward to comments and/or reviews; the driver patches are only build-tested. Happy hacking, Wolfram Wolfram Sang (8): i2c: refactor documentation of struct i2c_msg i2c: remove licence boilerplate from main UAPI header i2c: remove licence boilerplate from i2c-dev UAPI header i2c: octeon: check correct size of maximum RECV_LEN packet i2c: uapi: add macro to describe support for all SMBus transfers i2c: algo: bit: use new macro to specifiy capabilities i2c: qup: advertise SMBus transfers using RECV_LEN i2c: s3c2410: advertise SMBus transfers using RECV_LEN drivers/i2c/algos/i2c-algo-bit.c | 4 +- drivers/i2c/busses/i2c-octeon-core.c | 2 +- drivers/i2c/busses/i2c-qup.c | 2 +- drivers/i2c/busses/i2c-s3c2410.c | 2 +- include/uapi/linux/i2c-dev.h | 25 ++ include/uapi/linux/i2c.h | 128 ++- 6 files changed, 76 insertions(+), 87 deletions(-) -- 2.29.2
[PATCH 4/8] i2c: octeon: check correct size of maximum RECV_LEN packet
I2C_SMBUS_BLOCK_MAX defines already the maximum number as defined in the
SMBus 2.0 specs. No reason to add one to it.
Fixes: 886f6f8337dd ("i2c: octeon: Support I2C_M_RECV_LEN")
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-octeon-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-octeon-core.c
b/drivers/i2c/busses/i2c-octeon-core.c
index d9607905dc2f..845eda70b8ca 100644
--- a/drivers/i2c/busses/i2c-octeon-core.c
+++ b/drivers/i2c/busses/i2c-octeon-core.c
@@ -347,7 +347,7 @@ static int octeon_i2c_read(struct octeon_i2c *i2c, int
target,
if (result)
return result;
if (recv_len && i == 0) {
- if (data[i] > I2C_SMBUS_BLOCK_MAX + 1)
+ if (data[i] > I2C_SMBUS_BLOCK_MAX)
return -EPROTO;
length += data[i];
}
--
2.29.2
[PATCH 5/8] i2c: uapi: add macro to describe support for all SMBus transfers
Some I2C bus master drivers which support I2C_M_RECV_LEN do not set
the functionality bits of the now supported SMBus transfers. Add a
convenience macro to make this very simple.
Signed-off-by: Wolfram Sang
---
include/uapi/linux/i2c.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/linux/i2c.h b/include/uapi/linux/i2c.h
index 7786551eb177..92326ebde350 100644
--- a/include/uapi/linux/i2c.h
+++ b/include/uapi/linux/i2c.h
@@ -129,6 +129,11 @@ struct i2c_msg {
I2C_FUNC_SMBUS_I2C_BLOCK | \
I2C_FUNC_SMBUS_PEC)
+/* if I2C_M_RECV_LEN is also supported */
+#define I2C_FUNC_SMBUS_EMUL_ALL(I2C_FUNC_SMBUS_EMUL | \
+I2C_FUNC_SMBUS_READ_BLOCK_DATA | \
+I2C_FUNC_SMBUS_BLOCK_PROC_CALL)
+
/*
* Data for SMBus Messages
*/
--
2.29.2
[PATCH 2/8] i2c: remove licence boilerplate from main UAPI header
Remove boilerplate because we now have the SPDX header. Signed-off-by: Wolfram Sang --- include/uapi/linux/i2c.h | 32 +++- 1 file changed, 7 insertions(+), 25 deletions(-) diff --git a/include/uapi/linux/i2c.h b/include/uapi/linux/i2c.h index 8d2f59f53324..7786551eb177 100644 --- a/include/uapi/linux/i2c.h +++ b/include/uapi/linux/i2c.h @@ -1,29 +1,11 @@ /* SPDX-License-Identifier: GPL-2.0+ WITH Linux-syscall-note */ -/* - */ -/* */ -/* i2c.h - definitions for the i2c-bus interface*/ -/* */ -/* - */ -/* Copyright (C) 1995-2000 Simon G. Vogl - -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or -(at your option) any later version. - -This program is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -GNU General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, -MA 02110-1301 USA. */ -/* - */ - -/* With some changes from Kyösti Mälkki and - Frodo Looijaard */ +/* + * i2c.h - definitions for the I2C bus interface + * + * Copyright (C) 1995-2000 Simon G. Vogl + * With some changes from Kyösti Mälkki and + * Frodo Looijaard + */ #ifndef _UAPI_LINUX_I2C_H #define _UAPI_LINUX_I2C_H -- 2.29.2
Re: [PATCH 4.19 0/8] 4.19.166-rc1 review
On Thu, Jan 07, 2021 at 06:58:01PM +0100, Pavel Machek wrote: > Hi! > > > This is the start of the stable review cycle for the 4.19.166 release. > > There are 8 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > This was tested by CIP project, and we did not find anything wrong. > > https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-4.19.y > > Tested-by: Pavel Machek (CIP) Thanks for testing two of these and letting me know. greg k-h
[PATCH 1/8] i2c: refactor documentation of struct i2c_msg
The information about 'i2c_msg' was spread between kdoc and comments.
Move all the explanations to kdoc and duplicate only the requirements
for the flags in the comments. Also, add some redundancy and fix some
typos while here.
Signed-off-by: Wolfram Sang
---
include/uapi/linux/i2c.h | 91
1 file changed, 55 insertions(+), 36 deletions(-)
diff --git a/include/uapi/linux/i2c.h b/include/uapi/linux/i2c.h
index f71a1751cacf..8d2f59f53324 100644
--- a/include/uapi/linux/i2c.h
+++ b/include/uapi/linux/i2c.h
@@ -32,18 +32,41 @@
/**
* struct i2c_msg - an I2C transaction segment beginning with START
- * @addr: Slave address, either seven or ten bits. When this is a ten
- * bit address, I2C_M_TEN must be set in @flags and the adapter
- * must support I2C_FUNC_10BIT_ADDR.
- * @flags: I2C_M_RD is handled by all adapters. No other flags may be
- * provided unless the adapter exported the relevant I2C_FUNC_*
- * flags through i2c_check_functionality().
- * @len: Number of data bytes in @buf being read from or written to the
- * I2C slave address. For read transactions where I2C_M_RECV_LEN
- * is set, the caller guarantees that this buffer can hold up to
- * 32 bytes in addition to the initial length byte sent by the
- * slave (plus, if used, the SMBus PEC); and this value will be
- * incremented by the number of block data bytes received.
+ *
+ * @addr: Slave address, either 7 or 10 bits. When this is a 10 bit address,
+ * %I2C_M_TEN must be set in @flags and the adapter must support
+ * %I2C_FUNC_10BIT_ADDR.
+ *
+ * @flags:
+ * Supported by all adapters:
+ * %I2C_M_RD: read data (from slave to master). Guaranteed to be 0x0001!
+ *
+ * Optional:
+ * %I2C_M_DMA_SAFE: the buffer of this message is DMA safe. Makes only sense
+ * in kernelspace, because userspace buffers are copied anyway
+ *
+ * Only if I2C_FUNC_10BIT_ADDR is set:
+ * %I2C_M_TEN: this is a 10 bit chip address
+ *
+ * Only if I2C_FUNC_SMBUS_READ_BLOCK_DATA is set:
+ * %I2C_M_RECV_LEN: message length will be first received byte
+ *
+ * Only if I2C_FUNC_NOSTART is set:
+ * %I2C_M_NOSTART: skip repeated start sequence
+
+ * Only if I2C_FUNC_PROTOCOL_MANGLING is set:
+ * %I2C_M_NO_RD_ACK: in a read message, master ACK/NACK bit is skipped
+ * %I2C_M_IGNORE_NAK: treat NACK from client as ACK
+ * %I2C_M_REV_DIR_ADDR: toggles the Rd/Wr bit
+ * %I2C_M_STOP: force a STOP condition after the message
+ *
+ * @len: Number of data bytes in @buf being read from or written to the I2C
+ * slave address. For read transactions where %I2C_M_RECV_LEN is set, the
+ * caller guarantees that this buffer can hold up to %I2C_SMBUS_BLOCK_MAX
+ * bytes in addition to the initial length byte sent by the slave (plus,
+ * if used, the SMBus PEC); and this value will be incremented by the number
+ * of block data bytes received.
+ *
* @buf: The buffer into which data is read, or from which it's written.
*
* An i2c_msg is the low level representation of one segment of an I2C
@@ -60,40 +83,36 @@
* group, it is followed by a STOP. Otherwise it is followed by the next
* @i2c_msg transaction segment, beginning with a (repeated) START.
*
- * Alternatively, when the adapter supports I2C_FUNC_PROTOCOL_MANGLING then
+ * Alternatively, when the adapter supports %I2C_FUNC_PROTOCOL_MANGLING then
* passing certain @flags may have changed those standard protocol behaviors.
* Those flags are only for use with broken/nonconforming slaves, and with
- * adapters which are known to support the specific mangling options they
- * need (one or more of IGNORE_NAK, NO_RD_ACK, NOSTART, and REV_DIR_ADDR).
+ * adapters which are known to support the specific mangling options they need.
*/
struct i2c_msg {
- __u16 addr; /* slave address*/
+ __u16 addr;
__u16 flags;
-#define I2C_M_RD 0x0001 /* read data, from slave to master */
- /* I2C_M_RD is guaranteed to be 0x0001!
*/
-#define I2C_M_TEN 0x0010 /* this is a ten bit chip address */
-#define I2C_M_DMA_SAFE 0x0200 /* the buffer of this message is DMA
safe */
- /* makes only sense in kernelspace */
- /* userspace buffers are copied anyway
*/
-#define I2C_M_RECV_LEN 0x0400 /* length will be first received byte */
-#define I2C_M_NO_RD_ACK0x0800 /* if
I2C_FUNC_PROTOCOL_MANGLING */
-#define I2C_M_IGNORE_NAK 0x1000 /* if I2C_FUNC_PROTOCOL_MANGLING */
-#define I2C_M_REV_DIR_ADDR 0x2000 /* if I2C_FUNC_PROTOCOL_MANGLING */
-#define I2C_M_NOSTART 0x4000 /* if I2C_FUNC_NOSTART */
-#define I2C_M_STOP 0x8000 /* if I2C_FUNC_PROTOCOL_MANGLING */
- __u16 len; /* msg length */
- __u8 *buf; /* pointer to
[PATCH 6/8] i2c: algo: bit: use new macro to specifiy capabilities
Let's use the new macro for emulating SMBus with RECV_LEN support.
Signed-off-by: Wolfram Sang
---
drivers/i2c/algos/i2c-algo-bit.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/algos/i2c-algo-bit.c b/drivers/i2c/algos/i2c-algo-bit.c
index 913db013fe90..fc90293afcbf 100644
--- a/drivers/i2c/algos/i2c-algo-bit.c
+++ b/drivers/i2c/algos/i2c-algo-bit.c
@@ -622,9 +622,7 @@ static int bit_xfer_atomic(struct i2c_adapter *i2c_adap,
struct i2c_msg msgs[],
static u32 bit_func(struct i2c_adapter *adap)
{
- return I2C_FUNC_I2C | I2C_FUNC_NOSTART | I2C_FUNC_SMBUS_EMUL |
- I2C_FUNC_SMBUS_READ_BLOCK_DATA |
- I2C_FUNC_SMBUS_BLOCK_PROC_CALL |
+ return I2C_FUNC_I2C | I2C_FUNC_NOSTART | I2C_FUNC_SMBUS_EMUL_ALL |
I2C_FUNC_10BIT_ADDR | I2C_FUNC_PROTOCOL_MANGLING;
}
--
2.29.2
[PATCH 8/8] i2c: s3c2410: advertise SMBus transfers using RECV_LEN
This driver implements I2C_M_RECV_LEN, so it can advertise the SMBus
transfers needing it. This also enables client devices to check for the
RECV_LEN capability.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-s3c2410.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 3eafe0eb3e4c..62a903fbe912 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -781,7 +781,7 @@ static int s3c24xx_i2c_xfer(struct i2c_adapter *adap,
/* declare our i2c functionality */
static u32 s3c24xx_i2c_func(struct i2c_adapter *adap)
{
- return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL | I2C_FUNC_NOSTART |
+ return I2C_FUNC_I2C | I2C_FUNC_SMBUS_EMUL_ALL | I2C_FUNC_NOSTART |
I2C_FUNC_PROTOCOL_MANGLING;
}
--
2.29.2
[PATCH 7/8] i2c: qup: advertise SMBus transfers using RECV_LEN
This driver implements I2C_M_RECV_LEN, so it can advertise the SMBus
transfers needing it. This also enables client devices to check for the
RECV_LEN capability.
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-qup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 5a47915869ae..61dc20fd1191 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -1603,7 +1603,7 @@ static int qup_i2c_xfer_v2(struct i2c_adapter *adap,
static u32 qup_i2c_func(struct i2c_adapter *adap)
{
- return I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL & ~I2C_FUNC_SMBUS_QUICK);
+ return I2C_FUNC_I2C | (I2C_FUNC_SMBUS_EMUL_ALL & ~I2C_FUNC_SMBUS_QUICK);
}
static const struct i2c_algorithm qup_i2c_algo = {
--
2.29.2
KMSAN: uninit-value in __crypto_memneq (2)
Hello, syzbot found the following issue on: HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_.. git tree: https://github.com/google/kmsan.git master console output: https://syzkaller.appspot.com/x/log.txt?x=142ab9c0d0 kernel config: https://syzkaller.appspot.com/x/.config?x=2cdf4151c9653e32 dashboard link: https://syzkaller.appspot.com/bug?extid=e0f501056b282add58a6 compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project.git ca2dcbd030eadbf0aa9b660efe864ff08af6e18b) Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+e0f501056b282add5...@syzkaller.appspotmail.com = BUG: KMSAN: uninit-value in __crypto_memneq_16 crypto/memneq.c:99 [inline] BUG: KMSAN: uninit-value in __crypto_memneq+0x42c/0x470 crypto/memneq.c:161 CPU: 0 PID: 20526 Comm: kworker/0:3 Not tainted 5.10.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: wg-crypt-wg1 wg_packet_decrypt_worker Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:118 __msan_warning+0x5f/0xa0 mm/kmsan/kmsan_instr.c:197 __crypto_memneq_16 crypto/memneq.c:99 [inline] __crypto_memneq+0x42c/0x470 crypto/memneq.c:161 crypto_memneq include/crypto/algapi.h:277 [inline] chacha20poly1305_crypt_sg_inplace+0x1662/0x1cd0 lib/crypto/chacha20poly1305.c:311 chacha20poly1305_decrypt_sg_inplace+0x179/0x1d0 lib/crypto/chacha20poly1305.c:351 decrypt_packet drivers/net/wireguard/receive.c:284 [inline] wg_packet_decrypt_worker+0x9cf/0x17d0 drivers/net/wireguard/receive.c:509 process_one_work+0x121c/0x1fc0 kernel/workqueue.c:2272 worker_thread+0x10cc/0x2740 kernel/workqueue.c:2418 kthread+0x51c/0x560 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 put_unaligned_le64 include/linux/unaligned/access_ok.h:50 [inline] poly1305_core_emit+0x625/0x6a0 lib/crypto/poly1305-donna64.c:182 poly1305_final_generic+0xe2/0x280 lib/crypto/poly1305.c:71 poly1305_final include/crypto/poly1305.h:94 [inline] chacha20poly1305_crypt_sg_inplace+0x15cf/0x1cd0 lib/crypto/chacha20poly1305.c:310 chacha20poly1305_decrypt_sg_inplace+0x179/0x1d0 lib/crypto/chacha20poly1305.c:351 decrypt_packet drivers/net/wireguard/receive.c:284 [inline] wg_packet_decrypt_worker+0x9cf/0x17d0 drivers/net/wireguard/receive.c:509 process_one_work+0x121c/0x1fc0 kernel/workqueue.c:2272 worker_thread+0x10cc/0x2740 kernel/workqueue.c:2418 kthread+0x51c/0x560 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 poly1305_core_blocks+0x8f4/0x940 lib/crypto/poly1305-donna64.c:107 poly1305_update_generic+0x1a7/0x5a0 lib/crypto/poly1305.c:49 poly1305_update include/crypto/poly1305.h:83 [inline] chacha20poly1305_crypt_sg_inplace+0x1496/0x1cd0 lib/crypto/chacha20poly1305.c:302 chacha20poly1305_decrypt_sg_inplace+0x179/0x1d0 lib/crypto/chacha20poly1305.c:351 decrypt_packet drivers/net/wireguard/receive.c:284 [inline] wg_packet_decrypt_worker+0x9cf/0x17d0 drivers/net/wireguard/receive.c:509 process_one_work+0x121c/0x1fc0 kernel/workqueue.c:2272 worker_thread+0x10cc/0x2740 kernel/workqueue.c:2418 kthread+0x51c/0x560 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 __msan_chain_origin+0x57/0xa0 mm/kmsan/kmsan_instr.c:147 poly1305_core_blocks+0x8f4/0x940 lib/crypto/poly1305-donna64.c:107 poly1305_update_generic+0x1a7/0x5a0 lib/crypto/poly1305.c:49 poly1305_update include/crypto/poly1305.h:83 [inline] chacha20poly1305_crypt_sg_inplace+0xb4d/0x1cd0 lib/crypto/chacha20poly1305.c:263 chacha20poly1305_decrypt_sg_inplace+0x179/0x1d0 lib/crypto/chacha20poly1305.c:351 decrypt_packet drivers/net/wireguard/receive.c:284 [inline] wg_packet_decrypt_worker+0x9cf/0x17d0 drivers/net/wireguard/receive.c:509 process_one_work+0x121c/0x1fc0 kernel/workqueue.c:2272 worker_thread+0x10cc/0x2740 kernel/workqueue.c:2418 kthread+0x51c/0x560 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296 Uninit was stored to memory at: kmsan_save_stack_with_flags mm/kmsan/kmsan.c:121 [inline] kmsan_internal_chain_origin+0xad/0x130 mm/kmsan/kmsan.c:289 __msan_chain_origin+0x57/0xa0
possible deadlock in fasync_remove_entry
Hello,
syzbot found the following issue on:
HEAD commit:f5e6c330 Merge tag 'spi-fix-v5.11-rc2' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1639f3a8d0
kernel config: https://syzkaller.appspot.com/x/.config?x=8aa30b9da402d224
dashboard link: https://syzkaller.appspot.com/bug?extid=5252d2712377e3867125
compiler: gcc (GCC) 10.1.0-syz 20200507
Unfortunately, I don't have any reproducer for this issue yet.
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5252d2712377e3867...@syzkaller.appspotmail.com
=
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
5.11.0-rc2-syzkaller #0 Not tainted
-
syz-executor.3/15310 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
888013d6b7b8 (>f_owner.lock){.+.?}-{2:2}, at: send_sigio+0x24/0x360
fs/fcntl.c:787
and this task is already holding:
8880289580c0 (>fa_lock){}-{2:2}, at: kill_fasync_rcu
fs/fcntl.c:1004 [inline]
8880289580c0 (>fa_lock){}-{2:2}, at: kill_fasync fs/fcntl.c:1025
[inline]
8880289580c0 (>fa_lock){}-{2:2}, at: kill_fasync+0x14b/0x460
fs/fcntl.c:1018
which would create a new lock dependency:
(>fa_lock){}-{2:2} -> (>f_owner.lock){.+.?}-{2:2}
but this new dependency connects a SOFTIRQ-irq-safe lock:
(fasync_lock){+.+.}-{2:2}
... which became SOFTIRQ-irq-safe at:
lock_acquire kernel/locking/lockdep.c:5437 [inline]
lock_acquire+0x29d/0x740 kernel/locking/lockdep.c:5402
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:151
spin_lock include/linux/spinlock.h:354 [inline]
fasync_remove_entry+0x2e/0x1f0 fs/fcntl.c:877
fasync_helper+0x9e/0xb0 fs/fcntl.c:985
__tty_fasync drivers/tty/tty_io.c:2130 [inline]
tty_release+0x16d/0x1210 drivers/tty/tty_io.c:1668
__fput+0x283/0x920 fs/file_table.c:280
task_work_run+0xdd/0x190 kernel/task_work.c:140
tracehook_notify_resume include/linux/tracehook.h:189 [inline]
exit_to_user_mode_loop kernel/entry/common.c:174 [inline]
exit_to_user_mode_prepare+0x249/0x250 kernel/entry/common.c:201
__syscall_exit_to_user_mode_work kernel/entry/common.c:291 [inline]
syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:302
entry_SYSCALL_64_after_hwframe+0x44/0xa9
to a SOFTIRQ-irq-unsafe lock:
(>f_owner.lock){.+.?}-{2:2}
... which became SOFTIRQ-irq-unsafe at:
...
lock_acquire kernel/locking/lockdep.c:5437 [inline]
lock_acquire+0x29d/0x740 kernel/locking/lockdep.c:5402
__raw_read_lock_irqsave include/linux/rwlock_api_smp.h:159 [inline]
_raw_read_lock_irqsave+0x45/0x90 kernel/locking/spinlock.c:231
send_sigurg+0x1e/0xac0 fs/fcntl.c:826
sk_send_sigurg+0x76/0x300 net/core/sock.c:2938
tcp_check_urg.isra.0+0x1f4/0x710 net/ipv4/tcp_input.c:5508
tcp_urg net/ipv4/tcp_input.c:5549 [inline]
tcp_rcv_established+0x106c/0x1eb0 net/ipv4/tcp_input.c:5883
tcp_v4_do_rcv+0x5d1/0x870 net/ipv4/tcp_ipv4.c:1676
tcp_v4_rcv+0x2d10/0x3750 net/ipv4/tcp_ipv4.c:2058
ip_protocol_deliver_rcu+0x5c/0x8a0 net/ipv4/ip_input.c:204
ip_local_deliver_finish+0x20a/0x370 net/ipv4/ip_input.c:231
NF_HOOK include/linux/netfilter.h:301 [inline]
NF_HOOK include/linux/netfilter.h:295 [inline]
ip_local_deliver+0x1b3/0x200 net/ipv4/ip_input.c:252
dst_input include/net/dst.h:447 [inline]
ip_rcv_finish+0x1da/0x2f0 net/ipv4/ip_input.c:428
NF_HOOK include/linux/netfilter.h:301 [inline]
NF_HOOK include/linux/netfilter.h:295 [inline]
ip_rcv+0xaa/0xd0 net/ipv4/ip_input.c:539
__netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5323
__netif_receive_skb+0x27/0x1c0 net/core/dev.c:5437
process_backlog+0x232/0x6c0 net/core/dev.c:6327
napi_poll net/core/dev.c:6805 [inline]
net_rx_action+0x461/0xe10 net/core/dev.c:6888
__do_softirq+0x2a5/0x9f7 kernel/softirq.c:343
run_ksoftirqd kernel/softirq.c:650 [inline]
run_ksoftirqd+0x2d/0x50 kernel/softirq.c:642
smpboot_thread_fn+0x655/0x9e0 kernel/smpboot.c:165
kthread+0x3b1/0x4a0 kernel/kthread.c:292
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
other info that might help us debug this:
Chain exists of:
fasync_lock --> >fa_lock --> >f_owner.lock
Possible interrupt unsafe locking scenario:
CPU0CPU1
lock(>f_owner.lock);
local_irq_disable();
lock(fasync_lock);
lock(>fa_lock);
lock(fasync_lock);
*** DEADLOCK ***
8 locks held by syz-executor.3/15310:
#0: 888144d4e110 (>mutex){+.+.}-{3:3}, at: evdev_write+0x1d3/0x760
drivers/input/evdev.c:513
#1: 88801cb5c230 (>event_lock){-...}-{2:2}, at:
input_inject_event+0xa6/0x310 drivers/input/input.c:471
#2: 8b363860 (rcu_read_lock){}-{1:2}, at: is_event_supported
drivers/input/input.c:53
[PATCH] drm/panel: panel-simple: add bus-format and connector-type to Innolux n116bge
From: Heiko Stuebner
The Innolux n116bge panel has an eDP connector and 3*6 bits bus format.
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/panel/panel-simple.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 41bbec72b2da..a0b65d263dce 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2265,6 +2265,8 @@ static const struct panel_desc innolux_n116bge = {
.width = 256,
.height = 144,
},
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .connector_type = DRM_MODE_CONNECTOR_eDP,
};
static const struct drm_display_mode innolux_n125hce_gn1_mode = {
--
2.29.2
fs/f2fs/gc.c:622:12: warning: stack frame size of 3056 bytes in function 'get_victim_by_default'
Hi Chao, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 996e435fd401de35df62ac943ab9402cfe85c430 commit: 093749e296e29a4b0162eb925a6701a01e8c9a98 f2fs: support age threshold based garbage collection date: 4 months ago config: powerpc-randconfig-r033-20210109 (attached as .config) compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project bc556e5685c0f97e79fb7b3c6f15cc5062db8e36) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=093749e296e29a4b0162eb925a6701a01e8c9a98 git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout 093749e296e29a4b0162eb925a6701a01e8c9a98 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :182:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:542:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from fs/f2fs/gc.c:10: In file included from include/linux/backing-dev.h:15: In file included from include/linux/blkdev.h:13: In file included from include/linux/pagemap.h:11: In file included from include/linux/highmem.h:10: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :184:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:543:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from fs/f2fs/gc.c:10: In file included from include/linux/backing-dev.h:15: In file included from include/linux/blkdev.h:13: In file included from include/linux/pagemap.h:11: In file included from include/linux/highmem.h:10: In file included from include/linux/hardirq.h:10: In file included from arch/powerpc/include/asm/hardirq.h:6: In file included from include/linux/irq.h:20: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:604: arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(outsb, (unsigned long p, const void *b, unsigned long c), ^~ arch/powerpc/include/asm/io.h:601:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :186:1: note: expanded from here __do_outsb ^ arch/powerpc/include/asm/io.h:544:58: note: expanded from macro '__do_outsb' #define __do_outsb(p, b, n) writesb((PCI_IO_ADDR)_IO_BASE+(p),(b),(n)) ~^ In file included from fs/f2fs/gc.c:10: In file included from include/linux/backing-dev.h:15: In file included from include/linux/blkdev.h:13: In file included from include/linux/pagemap.h:11: In file included from include/linux/highme
[PATCH] staging: greybus: audio_helper.c: Replace strlcpy() with strscpy()
In gbaudio_remove_controls() , replace the usage of strlcpy() with strscpy() because strlcpy() only limits the *destination* size, and the source is always read fully. https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=v6a6g1ouzcprm...@mail.gmail.com/ was quoted by checkpatch while showing this warning. Signed-off-by: B K Karthik --- drivers/staging/greybus/audio_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/greybus/audio_helper.c b/drivers/staging/greybus/audio_helper.c index 3011b8abce38..1ed4772d2771 100644 --- a/drivers/staging/greybus/audio_helper.c +++ b/drivers/staging/greybus/audio_helper.c @@ -166,7 +166,7 @@ static int gbaudio_remove_controls(struct snd_card *card, struct device *dev, snprintf(id.name, sizeof(id.name), "%s %s", prefix, control->name); else - strlcpy(id.name, control->name, sizeof(id.name)); + strscpy(id.name, control->name, sizeof(id.name)); id.numid = 0; id.iface = control->iface; id.device = control->device; -- 2.17.1 signature.asc Description: PGP signature
[PATCH 5/7] regulator: qcom-labibb: Implement short-circuit and over-current IRQs
Short-Circuit Protection (SCP) and Over-Current Protection (OCP) are
very important for regulators like LAB and IBB, which are designed to
provide from very small to relatively big amounts of current to the
device (normally, a display).
Now that this regulator supports both voltage setting and current
limiting in this driver, to me it looked like being somehow essential
to provide support for SCP and OCP, for two reasons:
1. SCP is a drastic measure to prevent damaging "more" hardware in
the worst situations, if any was damaged, preventing potentially
drastic issues;
2. OCP is a great way to protect the hardware that we're powering
through these regulators as if anything bad happens, the HW will
draw more current than expected: in this case, the OCP interrupt
will fire and the regulators will be immediately shut down,
preventing hardware damage in many cases.
Both interrupts were successfully tested in a "sort-of" controlled
manner, with the following methodology:
Short-Circuit Protection (SCP):
1. Set LAB/IBB to 4.6/-1.4V, current limit 200mA/50mA;
2. Connect a 10 KOhm resistor to LAB/IBB by poking the right traces
on a FxTec Pro1 smartphone for a very brief time (in short words,
"just a rapid touch with flying wires");
3. The Short-Circuit protection trips: IRQ raises, regulators get
cut. Recovery OK, test repeated without rebooting, OK.
Over-Current Protection (OCP):
1. Set LAB/IBB to the expected voltage to power up the display of
a Sony Xperia XZ Premium smartphone (Sharp LS055D1SX04), set
current limit to LAB 200mA, IBB 50mA (the values that this
display unit needs are 200/800mA);
2. Boot the kernel: OCP fires. Recovery never happens because
the selected current limit is too low, but that's expected.
Test OK.
3. Set LAB/IBB to the expected current limits for XZ Premium
(LAB 200mA, IBB 800mA), but lower than expected voltage,
specifically LAB 5.4V, IBB -5.6V (instead of 5.6, -5.8V);
4. Boot the kernel: OCP fires. Recovery never happens because
the selected voltage (still in the working range limits)
is producing a current draw of more than 200mA on LAB.
Test OK.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/regulator/qcom-labibb-regulator.c | 430 +-
1 file changed, 427 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/qcom-labibb-regulator.c
b/drivers/regulator/qcom-labibb-regulator.c
index 21175e297c1f..413506481a08 100644
--- a/drivers/regulator/qcom-labibb-regulator.c
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -17,8 +17,20 @@
#define PMI8998_LAB_REG_BASE 0xde00
#define PMI8998_IBB_REG_BASE 0xdc00
+#define PMI8998_IBB_LAB_REG_OFFSET 0x200
#define REG_LABIBB_STATUS1 0x08
+ #define LABIBB_STATUS1_SC_BIT BIT(6)
+ #define LABIBB_STATUS1_VREG_OK_BITBIT(7)
+
+#define REG_LABIBB_INT_SET_TYPE0x11
+#define REG_LABIBB_INT_POLARITY_HIGH 0x12
+#define REG_LABIBB_INT_POLARITY_LOW0x13
+#define REG_LABIBB_INT_LATCHED_CLR 0x14
+#define REG_LABIBB_INT_EN_SET 0x15
+#define REG_LABIBB_INT_EN_CLR 0x16
+ #define LABIBB_INT_VREG_OKBIT(0)
+ #define LABIBB_INT_VREG_TYPE_LEVEL0
#define REG_LABIBB_VOLTAGE 0x41
#define LABIBB_VOLTAGE_OVERRIDE_ENBIT(7)
@@ -26,8 +38,7 @@
#define IBB_VOLTAGE_SET_MASK GENMASK(5, 0)
#define REG_LABIBB_ENABLE_CTL 0x46
-#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
-#define LABIBB_CONTROL_ENABLE BIT(7)
+ #define LABIBB_CONTROL_ENABLE BIT(7)
#define REG_LABIBB_PD_CTL 0x47
#define LAB_PD_CTL_MASK GENMASK(1, 0)
@@ -56,6 +67,11 @@
#define LAB_ENABLE_TIME(LABIBB_OFF_ON_DELAY * 2)
#define IBB_ENABLE_TIME(LABIBB_OFF_ON_DELAY * 10)
#define LABIBB_POLL_ENABLED_TIME 1000
+#define OCP_RECOVERY_INTERVAL_MS 500
+#define SC_RECOVERY_INTERVAL_MS250
+#define LABIBB_MAX_OCP_COUNT 4
+#define LABIBB_MAX_SC_COUNT3
+#define LABIBB_MAX_FATAL_COUNT 2
struct labibb_current_limits {
u32 uA_min;
@@ -69,10 +85,18 @@ struct labibb_regulator {
struct regmap *regmap;
struct regulator_dev*rdev;
struct labibb_current_limitsuA_limits;
+ struct delayed_work ocp_recovery_work;
+ struct delayed_work sc_recovery_work;
u16 base;
u8 type;
u8 dischg_sel;
u8 soft_start_sel;
+ int sc_irq;
+ int sc_count;
+ int ocp_irq;
+ int ocp_irq_count;
+ int fatal_count;
+ bool
[PATCH 0/7] Really implement Qualcomm LAB/IBB regulators
Okay, the title may be a little "aggressive"? However, the qcom-labibb driver wasn't really .. doing much. The current form of this driver is only taking care of enabling or disabling the regulators, which is pretty useless if they were not pre-set from the bootloader, which sets them only if continuous splash is enabled. Moreover, some bootloaders are setting a higher voltage and/or a higher current limit compared to what's actually required by the attached hardware (which is, in 99.9% of the cases, a display) and this produces a higher power consumption, higher heat output and a risk of actually burning the display if kept up for a very long time: for example, this is true on at least some Sony Xperia MSM8998 (Yoshino platform) and especially on some Sony Xperia SDM845 (Tama platform) smartphones. In any case, the main reason why this change was necessary for us is that, during the bringup of Sony Xperia MSM8998 phones, we had an issue with the bootloader not turning on the display and not setting the lab and ibb regulators before booting the kernel, making it impossible to powerup the display. With this said, this patchset enables setting voltage, current limiting, overcurrent and short-circuit protection.. and others, on the LAB/IBB regulators. Each commit in this patch series provides as many informations as possible about what's going on and testing methodology. AngeloGioacchino Del Regno (7): regulator: qcom-labibb: Implement voltage selector ops regulator: qcom-labibb: Implement current limiting regulator: qcom-labibb: Implement pull-down, softstart, active discharge dt-bindings: regulator: qcom-labibb: Document soft start properties regulator: qcom-labibb: Implement short-circuit and over-current IRQs dt-bindings: regulator: qcom-labibb: Document SCP/OCP interrupts arm64: dts: pmi8998: Add the right interrupts for LAB/IBB SCP and OCP .../regulator/qcom-labibb-regulator.yaml | 28 +- arch/arm64/boot/dts/qcom/pmi8998.dtsi | 8 +- drivers/regulator/qcom-labibb-regulator.c | 636 +- 3 files changed, 660 insertions(+), 12 deletions(-) -- 2.29.2
[PATCH 1/7] regulator: qcom-labibb: Implement voltage selector ops
Implement {get,set}_voltage_sel, list_voltage, map_voltage with
the useful regulator regmap helpers in order to be able to manage
the voltage of LAB (positive) and IBB (negative) regulators.
In particular, the supported ranges are the following:
- LAB (pos): 4600mV to 6100mV with 100mV stepping,
- IBB (neg): -7700mV to -1400mV with 100mV stepping.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/regulator/qcom-labibb-regulator.c | 28 +++
1 file changed, 28 insertions(+)
diff --git a/drivers/regulator/qcom-labibb-regulator.c
b/drivers/regulator/qcom-labibb-regulator.c
index 8ccf572394a2..9f51c96f16fb 100644
--- a/drivers/regulator/qcom-labibb-regulator.c
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -19,6 +19,12 @@
#define PMI8998_IBB_REG_BASE 0xdc00
#define REG_LABIBB_STATUS1 0x08
+
+#define REG_LABIBB_VOLTAGE 0x41
+ #define LABIBB_VOLTAGE_OVERRIDE_ENBIT(7)
+ #define LAB_VOLTAGE_SET_MASK GENMASK(3, 0)
+ #define IBB_VOLTAGE_SET_MASK GENMASK(5, 0)
+
#define REG_LABIBB_ENABLE_CTL 0x46
#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
#define LABIBB_CONTROL_ENABLE BIT(7)
@@ -51,6 +57,10 @@ static const struct regulator_ops qcom_labibb_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
.is_enabled = regulator_is_enabled_regmap,
+ .set_voltage_sel= regulator_set_voltage_sel_regmap,
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .list_voltage = regulator_list_voltage_linear_range,
+ .map_voltage= regulator_map_voltage_linear_range,
};
static const struct regulator_desc pmi8998_lab_desc = {
@@ -59,9 +69,18 @@ static const struct regulator_desc pmi8998_lab_desc = {
.enable_val = LABIBB_CONTROL_ENABLE,
.enable_time= LAB_ENABLE_TIME,
.poll_enabled_time = LABIBB_POLL_ENABLED_TIME,
+ .vsel_reg = (PMI8998_LAB_REG_BASE + REG_LABIBB_VOLTAGE),
+ .vsel_mask = LAB_VOLTAGE_SET_MASK,
+ .apply_reg = (PMI8998_LAB_REG_BASE + REG_LABIBB_VOLTAGE),
+ .apply_bit = LABIBB_VOLTAGE_OVERRIDE_EN,
.off_on_delay = LABIBB_OFF_ON_DELAY,
.owner = THIS_MODULE,
.type = REGULATOR_VOLTAGE,
+ .linear_ranges = (struct linear_range[]) {
+ REGULATOR_LINEAR_RANGE(460, 0, 15, 10),
+ },
+ .n_linear_ranges= 1,
+ .n_voltages = 16,
.ops= _labibb_ops,
};
@@ -71,9 +90,18 @@ static const struct regulator_desc pmi8998_ibb_desc = {
.enable_val = LABIBB_CONTROL_ENABLE,
.enable_time= IBB_ENABLE_TIME,
.poll_enabled_time = LABIBB_POLL_ENABLED_TIME,
+ .vsel_reg = (PMI8998_IBB_REG_BASE + REG_LABIBB_VOLTAGE),
+ .vsel_mask = IBB_VOLTAGE_SET_MASK,
+ .apply_reg = (PMI8998_IBB_REG_BASE + REG_LABIBB_VOLTAGE),
+ .apply_bit = LABIBB_VOLTAGE_OVERRIDE_EN,
.off_on_delay = LABIBB_OFF_ON_DELAY,
.owner = THIS_MODULE,
.type = REGULATOR_VOLTAGE,
+ .linear_ranges = (struct linear_range[]) {
+ REGULATOR_LINEAR_RANGE(140, 0, 63, 10),
+ },
+ .n_linear_ranges= 1,
+ .n_voltages = 64,
.ops= _labibb_ops,
};
--
2.29.2
[PATCH 7/7] arm64: dts: pmi8998: Add the right interrupts for LAB/IBB SCP and OCP
In commit 208921bae696 ("arm64: dts: qcom: pmi8998: Add nodes for
LAB and IBB regulators") bindings for the lab/ibb regulators were
added to the pmi8998 dt, but the original committer has never
specified what the interrupts were for.
LAB and IBB regulators provide two interrupts, SC-ERR (short
circuit error) and VREG-OK but, in that commit, the regulators
were provided with two different types of interrupts;
specifically, IBB had the SC-ERR interrupt, while LAB had the
VREG-OK one, none of which were (luckily) used, since the driver
didn't actually use these at all.
Assuming that the original intention was to have the SC IRQ in
both LAB and IBB, as per the names appearing in documentation,
fix the SCP interrupt.
While at it, also add the OCP interrupt in order to be able to
enable the Over-Current Protection feature, if requested.
Signed-off-by: AngeloGioacchino Del Regno
---
arch/arm64/boot/dts/qcom/pmi8998.dtsi | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
index c8e21713cb9f..5742163d49b3 100644
--- a/arch/arm64/boot/dts/qcom/pmi8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmi8998.dtsi
@@ -30,11 +30,15 @@ labibb {
compatible = "qcom,pmi8998-lab-ibb";
ibb: ibb {
- interrupts = <0x3 0xdc 0x2
IRQ_TYPE_EDGE_RISING>;
+ interrupts = <0x3 0xdc 0x2
IRQ_TYPE_EDGE_RISING>,
+<0x3 0xdc 0x0 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "sc-err", "ocp";
};
lab: lab {
- interrupts = <0x3 0xde 0x0
IRQ_TYPE_EDGE_RISING>;
+ interrupts = <0x3 0xde 0x1
IRQ_TYPE_EDGE_RISING>,
+<0x3 0xde 0x0 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "sc-err", "ocp";
};
};
--
2.29.2
[PATCH 4/7] dt-bindings: regulator: qcom-labibb: Document soft start properties
Document properties to configure soft start and discharge resistor for LAB and IBB respectively. Signed-off-by: AngeloGioacchino Del Regno --- .../bindings/regulator/qcom-labibb-regulator.yaml | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml index 53853ec20fe2..1cdaff66fdb9 100644 --- a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml @@ -22,6 +22,10 @@ properties: type: object properties: + qcom,soft-start-us: +description: Regulator soft start time in microseconds. +enum: [200, 400, 600, 800] +default: 200 interrupts: maxItems: 1 @@ -35,6 +39,10 @@ properties: type: object properties: + qcom,discharge-resistor-kohms: +description: Discharge resistor value in KiloOhms. +enum: [300, 64, 32, 16] +default: 300 interrupts: maxItems: 1 -- 2.29.2
[PATCH 2/7] regulator: qcom-labibb: Implement current limiting
LAB and IBB regulators can be current-limited by setting the
appropriate registers, but this operation is granted only after
sending an unlock code for secure access.
Besides the secure access, it would be possible to use the
regmap helper for get_current_limit, as there is no security
blocking reads, but I chose not to as to avoid having a very
big array containing current limits, especially for IBB.
That said, these regulators support current limiting for:
- LAB (pos): 200-1600mA, with 200mA per step (8 steps),
- IBB (neg): 0-1550mA, with 50mA per step (32 steps).
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/regulator/qcom-labibb-regulator.c | 86 +++
1 file changed, 86 insertions(+)
diff --git a/drivers/regulator/qcom-labibb-regulator.c
b/drivers/regulator/qcom-labibb-regulator.c
index 9f51c96f16fb..c93d0d51cecb 100644
--- a/drivers/regulator/qcom-labibb-regulator.c
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -29,6 +29,15 @@
#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
#define LABIBB_CONTROL_ENABLE BIT(7)
+#define REG_LABIBB_CURRENT_LIMIT 0x4b
+ #define LAB_CURRENT_LIMIT_MASKGENMASK(2, 0)
+ #define IBB_CURRENT_LIMIT_MASKGENMASK(4, 0)
+ #define LAB_CURRENT_LIMIT_OVERRIDE_EN BIT(3)
+ #define LABIBB_CURRENT_LIMIT_EN BIT(7)
+
+#define REG_LABIBB_SEC_ACCESS 0xd0
+ #define LABIBB_SEC_UNLOCK_CODE0xa5
+
#define LAB_ENABLE_CTL_MASKBIT(7)
#define IBB_ENABLE_CTL_MASK(BIT(7) | BIT(6))
@@ -37,11 +46,18 @@
#define IBB_ENABLE_TIME(LABIBB_OFF_ON_DELAY * 10)
#define LABIBB_POLL_ENABLED_TIME 1000
+struct labibb_current_limits {
+ u32 uA_min;
+ u32 uA_step;
+ u8 ovr_val;
+};
+
struct labibb_regulator {
struct regulator_desc desc;
struct device *dev;
struct regmap *regmap;
struct regulator_dev*rdev;
+ struct labibb_current_limitsuA_limits;
u16 base;
u8 type;
};
@@ -53,6 +69,56 @@ struct labibb_regulator_data {
const struct regulator_desc *desc;
};
+static int qcom_labibb_set_current_limit(struct regulator_dev *rdev,
+int min_uA, int max_uA)
+{
+ struct labibb_regulator *vreg = rdev_get_drvdata(rdev);
+ struct regulator_desc *desc = >desc;
+ struct labibb_current_limits *lim = >uA_limits;
+ u32 mask, val;
+ int i, ret, sel = -1;
+
+ if (min_uA < lim->uA_min || max_uA < lim->uA_min)
+ return -EINVAL;
+
+ for (i = 0; i < desc->n_current_limits; i++) {
+ int uA_limit = (lim->uA_step * i) + lim->uA_min;
+ if (max_uA >= uA_limit && min_uA <= uA_limit)
+ sel = i;
+ }
+ if (sel < 0)
+ return -EINVAL;
+
+ /* Current limit setting needs secure access */
+ ret = regmap_write(vreg->regmap, vreg->base + REG_LABIBB_SEC_ACCESS,
+ LABIBB_SEC_UNLOCK_CODE);
+ if (ret)
+ return ret;
+
+ mask = desc->csel_mask | lim->ovr_val;
+ mask |= LABIBB_CURRENT_LIMIT_EN;
+ val = (u32)sel | lim->ovr_val;
+ val |= LABIBB_CURRENT_LIMIT_EN;
+
+ return regmap_update_bits(vreg->regmap, desc->csel_reg, mask, val);
+ }
+
+static int qcom_labibb_get_current_limit(struct regulator_dev *rdev)
+{
+ struct labibb_regulator *vreg = rdev_get_drvdata(rdev);
+ struct regulator_desc *desc = >desc;
+ struct labibb_current_limits *lim = >uA_limits;
+ unsigned int cur_step;
+ int ret;
+
+ ret = regmap_read(vreg->regmap, desc->csel_reg, _step);
+ if (ret)
+ return ret;
+ cur_step &= desc->csel_mask;
+
+ return (cur_step * lim->uA_step) + lim->uA_min;
+}
+
static const struct regulator_ops qcom_labibb_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
@@ -61,6 +127,8 @@ static const struct regulator_ops qcom_labibb_ops = {
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.list_voltage = regulator_list_voltage_linear_range,
.map_voltage= regulator_map_voltage_linear_range,
+ .set_current_limit = qcom_labibb_set_current_limit,
+ .get_current_limit = qcom_labibb_get_current_limit,
};
static const struct regulator_desc pmi8998_lab_desc = {
@@ -73,6 +141,9 @@ static const struct regulator_desc pmi8998_lab_desc = {
.vsel_mask = LAB_VOLTAGE_SET_MASK,
.apply_reg = (PMI8998_LAB_REG_BASE + REG_LABIBB_VOLTAGE),
.apply_bit = LABIBB_VOLTAGE_OVERRIDE_EN,
+ .csel_reg
[PATCH 6/7] dt-bindings: regulator: qcom-labibb: Document SCP/OCP interrupts
Short-Circuit Protection (SCP) and Over-Current Protection (OCP) are
now implemented in the driver: document the interrupts.
This also fixes wrong documentation about the SCP interrupt for LAB.
Signed-off-by: AngeloGioacchino Del Regno
---
.../regulator/qcom-labibb-regulator.yaml | 20 +++
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git
a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
index 1cdaff66fdb9..8cf883d78a45 100644
--- a/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/qcom-labibb-regulator.yaml
@@ -28,9 +28,10 @@ properties:
default: 200
interrupts:
-maxItems: 1
+minItems: 1
+maxItems: 2
description:
- Short-circuit interrupt for lab.
+ Short-circuit and over-current interrupts for lab.
required:
- interrupts
@@ -45,9 +46,10 @@ properties:
default: 300
interrupts:
-maxItems: 1
+minItems: 1
+maxItems: 2
description:
- Short-circuit interrupt for lab.
+ Short-circuit and over-current interrupts for ibb.
required:
- interrupts
@@ -65,13 +67,15 @@ examples:
compatible = "qcom,pmi8998-lab-ibb";
lab {
-interrupts = <0x3 0x0 IRQ_TYPE_EDGE_RISING>;
-interrupt-names = "sc-err";
+interrupts = <0x3 0xde 0x1 IRQ_TYPE_EDGE_RISING>,
+ <0x3 0xde 0x0 IRQ_TYPE_LEVEL_LOW>;
+interrupt-names = "sc-err", "ocp";
};
ibb {
-interrupts = <0x3 0x2 IRQ_TYPE_EDGE_RISING>;
-interrupt-names = "sc-err";
+interrupts = <0x3 0xdc 0x2 IRQ_TYPE_EDGE_RISING>,
+ <0x3 0xdc 0x0 IRQ_TYPE_LEVEL_LOW>;
+interrupt-names = "sc-err", "ocp";
};
};
--
2.29.2
[PATCH 3/7] regulator: qcom-labibb: Implement pull-down, softstart, active discharge
Soft start is required to avoid inrush current during LAB ramp-up and
IBB ramp-down, protecting connected hardware to which we supply voltage.
Since soft start is configurable on both LAB and IBB regulators, it
was necessary to add two DT properties, respectively "qcom,soft-start-us"
to control LAB ramp-up and "qcom,discharge-resistor-kohms" to control
the discharge resistor for IBB ramp-down, which obviously brought the
need of implementing a of_parse callback for both regulators.
Finally, also implement pull-down mode in order to avoid unpredictable
behavior when the regulators are disabled (random voltage spikes etc).
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/regulator/qcom-labibb-regulator.c | 94 +++
1 file changed, 94 insertions(+)
diff --git a/drivers/regulator/qcom-labibb-regulator.c
b/drivers/regulator/qcom-labibb-regulator.c
index c93d0d51cecb..21175e297c1f 100644
--- a/drivers/regulator/qcom-labibb-regulator.c
+++ b/drivers/regulator/qcom-labibb-regulator.c
@@ -29,12 +29,23 @@
#define LABIBB_STATUS1_VREG_OK_BIT BIT(7)
#define LABIBB_CONTROL_ENABLE BIT(7)
+#define REG_LABIBB_PD_CTL 0x47
+ #define LAB_PD_CTL_MASK GENMASK(1, 0)
+ #define IBB_PD_CTL_MASK (BIT(0) | BIT(7))
+ #define LAB_PD_CTL_STRONG_PULLBIT(0)
+ #define IBB_PD_CTL_HALF_STRENGTH BIT(0)
+ #define IBB_PD_CTL_EN BIT(7)
+
#define REG_LABIBB_CURRENT_LIMIT 0x4b
#define LAB_CURRENT_LIMIT_MASKGENMASK(2, 0)
#define IBB_CURRENT_LIMIT_MASKGENMASK(4, 0)
#define LAB_CURRENT_LIMIT_OVERRIDE_EN BIT(3)
#define LABIBB_CURRENT_LIMIT_EN BIT(7)
+#define REG_IBB_PWRUP_PWRDN_CTL_1 0x58
+ #define IBB_CTL_1_DISCHARGE_ENBIT(2)
+
+#define REG_LABIBB_SOFT_START_CTL 0x5f
#define REG_LABIBB_SEC_ACCESS 0xd0
#define LABIBB_SEC_UNLOCK_CODE0xa5
@@ -60,6 +71,8 @@ struct labibb_regulator {
struct labibb_current_limitsuA_limits;
u16 base;
u8 type;
+ u8 dischg_sel;
+ u8 soft_start_sel;
};
struct labibb_regulator_data {
@@ -119,6 +132,70 @@ static int qcom_labibb_get_current_limit(struct
regulator_dev *rdev)
return (cur_step * lim->uA_step) + lim->uA_min;
}
+static int qcom_labibb_set_soft_start(struct regulator_dev *rdev)
+{
+ struct labibb_regulator *vreg = rdev_get_drvdata(rdev);
+ u32 val = 0;
+
+ if (vreg->type == QCOM_IBB_TYPE)
+ val = vreg->dischg_sel;
+ else
+ val = vreg->soft_start_sel;
+
+ return regmap_write(rdev->regmap, rdev->desc->soft_start_reg, val);
+}
+
+static int qcom_labibb_get_table_sel(const int *table, int sz, u32 value)
+{
+ int i;
+
+ for (i = 0; i < sz; i++)
+ if (table[i] == value)
+ return i;
+ return -EINVAL;
+}
+
+/* IBB discharge resistor values in KOhms */
+static const int dischg_resistor_values[] = { 300, 64, 32, 16 };
+
+/* Soft start time in microseconds */
+static const int soft_start_values[] = { 200, 400, 600, 800 };
+
+static int qcom_labibb_of_parse_cb(struct device_node *np,
+ const struct regulator_desc *desc,
+ struct regulator_config *config)
+{
+ struct labibb_regulator *vreg = config->driver_data;
+ u32 dischg_kohms, soft_start_time;
+ int ret;
+
+ ret = of_property_read_u32(np, "qcom,discharge-resistor-kohms",
+ _kohms);
+ if (ret)
+ dischg_kohms = 300;
+
+ ret = qcom_labibb_get_table_sel(dischg_resistor_values,
+ ARRAY_SIZE(dischg_resistor_values),
+ dischg_kohms);
+ if (ret < 0)
+ return ret;
+ vreg->dischg_sel = (u8)ret;
+
+ ret = of_property_read_u32(np, "qcom,soft-start-us",
+ _start_time);
+ if (ret)
+ soft_start_time = 200;
+
+ ret = qcom_labibb_get_table_sel(soft_start_values,
+ ARRAY_SIZE(soft_start_values),
+ soft_start_time);
+ if (ret < 0)
+ return ret;
+ vreg->soft_start_sel = (u8)ret;
+
+ return 0;
+}
+
static const struct regulator_ops qcom_labibb_ops = {
.enable = regulator_enable_regmap,
.disable= regulator_disable_regmap,
@@ -127,8 +204,11 @@ static const struct regulator_ops qcom_labibb_ops = {
.get_voltage_sel= regulator_get_voltage_sel_regmap,
.list_voltage = regulator_list_voltage_linear_range,
.map_voltage= regulator_map_voltage_linear_range,
+
[PATCH 1/9] drm/msm/dpu: Fix VBIF_XINL_QOS_LVL_REMAP_000 register offset
On DPUs prior to version 4 the VBIF_XINL_QOS_LVL_REMAP_000 register
is at 0x570 offset from vbif base instead of 0x590, due to the
VBIF_XINL_QOS_RP_REMAP_000 having less instances (less possible XINs).
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
index cf867f3f7c36..b757054e1c23 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c
@@ -30,7 +30,7 @@
#define VBIF_XIN_HALT_CTRL00x0200
#define VBIF_XIN_HALT_CTRL10x0204
#define VBIF_XINL_QOS_RP_REMAP_000 0x0550
-#define VBIF_XINL_QOS_LVL_REMAP_0000x0590
+#define VBIF_XINL_QOS_LVL_REMAP_000(v) (v < DPU_HW_VER_400 ? 0x570 : 0x0590)
static void dpu_hw_clear_errors(struct dpu_hw_vbif *vbif,
u32 *pnd_errors, u32 *src_errors)
@@ -156,18 +156,19 @@ static void dpu_hw_set_qos_remap(struct dpu_hw_vbif *vbif,
u32 xin_id, u32 level, u32 remap_level)
{
struct dpu_hw_blk_reg_map *c;
- u32 reg_val, reg_val_lvl, mask, reg_high, reg_shift;
+ u32 reg_lvl, reg_val, reg_val_lvl, mask, reg_high, reg_shift;
if (!vbif)
return;
c = >hw;
+ reg_lvl = VBIF_XINL_QOS_LVL_REMAP_000(c->hwversion);
reg_high = ((xin_id & 0x8) >> 3) * 4 + (level * 8);
reg_shift = (xin_id & 0x7) * 4;
reg_val = DPU_REG_READ(c, VBIF_XINL_QOS_RP_REMAP_000 + reg_high);
- reg_val_lvl = DPU_REG_READ(c, VBIF_XINL_QOS_LVL_REMAP_000 + reg_high);
+ reg_val_lvl = DPU_REG_READ(c, reg_lvl + reg_high);
mask = 0x7 << reg_shift;
@@ -178,7 +179,7 @@ static void dpu_hw_set_qos_remap(struct dpu_hw_vbif *vbif,
reg_val_lvl |= (remap_level << reg_shift) & mask;
DPU_REG_WRITE(c, VBIF_XINL_QOS_RP_REMAP_000 + reg_high, reg_val);
- DPU_REG_WRITE(c, VBIF_XINL_QOS_LVL_REMAP_000 + reg_high, reg_val_lvl);
+ DPU_REG_WRITE(c, reg_lvl + reg_high, reg_val_lvl);
}
static void dpu_hw_set_write_gather_en(struct dpu_hw_vbif *vbif, u32 xin_id)
--
2.29.2
[PATCH 8/9] drm/msm/dpu: Add a function to retrieve the current CTL status
Add a function that returns whether the requested CTL is active or not:
this will be used in a later commit to fix command mode panel issues.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 6 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h | 7 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
index 758c355b4fd8..626fd41379fb 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c
@@ -82,6 +82,11 @@ static inline void dpu_hw_ctl_trigger_start(struct
dpu_hw_ctl *ctx)
DPU_REG_WRITE(>hw, CTL_START, 0x1);
}
+static inline bool dpu_hw_ctl_is_started(struct dpu_hw_ctl *ctx)
+{
+ return !!(DPU_REG_READ(>hw, CTL_START) & BIT(0));
+}
+
static inline void dpu_hw_ctl_trigger_pending(struct dpu_hw_ctl *ctx)
{
trace_dpu_hw_ctl_trigger_prepare(ctx->pending_flush_mask,
@@ -550,6 +555,7 @@ static void _setup_ctl_ops(struct dpu_hw_ctl_ops *ops,
ops->get_pending_flush = dpu_hw_ctl_get_pending_flush;
ops->get_flush_register = dpu_hw_ctl_get_flush_register;
ops->trigger_start = dpu_hw_ctl_trigger_start;
+ ops->is_started = dpu_hw_ctl_is_started;
ops->trigger_pending = dpu_hw_ctl_trigger_pending;
ops->reset = dpu_hw_ctl_reset_control;
ops->wait_reset_status = dpu_hw_ctl_wait_reset_status;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
index ec579b470a80..c376b5ae7803 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h
@@ -59,6 +59,13 @@ struct dpu_hw_ctl_ops {
*/
void (*trigger_start)(struct dpu_hw_ctl *ctx);
+ /**
+* check if the ctl is started
+* @ctx : ctl path ctx pointer
+* @Return: true if started, false if stopped
+*/
+ bool (*is_started)(struct dpu_hw_ctl *ctx);
+
/**
* kickoff prepare is in progress hw operation for sw
* controlled interfaces: DSI cmd mode and WB interface
--
2.29.2
[PATCH 4/9] drm/msm/dpu1: Allow specifying features and sblk in DSPP_BLK macro
The DSPP_BLK macro was ad-hoc made for SC7180, but this is wrong
because not all of the DPU DSPP versions can use the same DSPP block
configuration, and not all of them have got the same features.
For this reason, add two more params to the DSPP_BLK macro, so that
it is possible to specify the feature mask and the sblk config for
each DSPP.
Fixes: 4259ff7ae509 ("drm/msm/dpu: add support for pcc color block in dpu
driver")
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 253075091409..d1aebb5f48c1 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -454,16 +454,17 @@ static const struct dpu_dspp_sub_blks sc7180_dspp_sblk = {
.len = 0x90, .version = 0x1},
};
-#define DSPP_BLK(_name, _id, _base) \
+#define DSPP_BLK(_name, _id, _base, _mask, _desc) \
{\
.name = _name, .id = _id, \
.base = _base, .len = 0x1800, \
- .features = DSPP_SC7180_MASK, \
- .sblk = _dspp_sblk \
+ .features = _mask, \
+ .sblk = _desc \
}
static const struct dpu_dspp_cfg sc7180_dspp[] = {
- DSPP_BLK("dspp_0", DSPP_0, 0x54000),
+ DSPP_BLK("dspp_0", DSPP_0, 0x54000, DSPP_SC7180_MASK,
+_dspp_sblk),
};
/*
--
2.29.2
[PATCH 2/9] drm/msm/dpu1: Move DPU_SSPP_QOS_8LVL bit to SDM845 and SC7180 masks
Not all DPU versions that are supported in this driver are supposed to have a 8-Levels VIG QoS setting. Move this flag to SDM845 and SC7180 specific masks. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c index 60b304b72b7c..983ee5ac2c45 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c @@ -13,14 +13,14 @@ #define VIG_MASK \ (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) |\ - BIT(DPU_SSPP_CSC_10BIT) | BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_QOS_8LVL) |\ + BIT(DPU_SSPP_CSC_10BIT) | BIT(DPU_SSPP_CDP) |\ BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_EXCL_RECT)) #define VIG_SDM845_MASK \ - (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED3)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED3)) #define VIG_SC7180_MASK \ - (VIG_MASK | BIT(DPU_SSPP_SCALER_QSEED4)) + (VIG_MASK | BIT(DPU_SSPP_QOS_8LVL) | BIT(DPU_SSPP_SCALER_QSEED4)) #define DMA_SDM845_MASK \ (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\ -- 2.29.2
[PATCH 0/9] Qualcomm DRM DPU fixes
This patch series brings some fixes to the Qualcomm DPU driver, aim is to get it prepared for "legacy" SoCs (like MSM8998, SDM630/660) and to finally get command-mode displays working on this driver. The series was tested against MSM8998 (the commit that introduces it to the hw-catalog is not included in this series, as it needs to be cleaned up a little more) and specifically on: - Sony Xperia XZ Premium (MSM8998), 4K dual-dsi LCD display, command-mode - F(x)Tec Pro1 (MSM8998), single-dsi OLED display, video-mode ... And it obviously worked just perfect! AngeloGioacchino Del Regno (9): drm/msm/dpu: Fix VBIF_XINL_QOS_LVL_REMAP_000 register offset drm/msm/dpu1: Move DPU_SSPP_QOS_8LVL bit to SDM845 and SC7180 masks drm/msm/dpu1: Add prog_fetch_lines_worst_case to INTF_BLK macro drm/msm/dpu1: Allow specifying features and sblk in DSPP_BLK macro drm/msm/dpu: Disable autorefresh in command mode drm/msm/dpu: Correctly configure vsync tearcheck for command mode drm/msm/dpu: Remove unused call in wait_for_commit_done drm/msm/dpu: Add a function to retrieve the current CTL status drm/msm/dpu: Fix timeout issues on command mode panels .../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 91 --- .../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 39 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c| 6 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.h| 7 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 26 ++ .../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_vbif.c | 9 +- 7 files changed, 155 insertions(+), 37 deletions(-) -- 2.29.2
[PATCH 5/9] drm/msm/dpu: Disable autorefresh in command mode
When a command mode display is used, it may be retaining the bootloader
configuration which, in most of the cases, enables the autorefresh
feature in order to keep the splash up.
Since there is no autorefresh management in this driver, wire up the
autorefresh ops in the dpu_hw_pingpong and disable the feature when
preparing for cmd commit: instead of disabling it when initializing
the command mode, this road was chosen as to open future possibility
of enabling and managing the autorefresh feature in the driver.
Signed-off-by: AngeloGioacchino Del Regno
---
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 68 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 26 +++
.../gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 14
3 files changed, 108 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index 8493d68ad841..a367b093c888 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -4,8 +4,10 @@
*/
#define pr_fmt(fmt)"[drm:%s:%d] " fmt, __func__, __LINE__
+#include
#include "dpu_encoder_phys.h"
#include "dpu_hw_interrupts.h"
+#include "dpu_hw_pingpong.h"
#include "dpu_core_irq.h"
#include "dpu_formats.h"
#include "dpu_trace.h"
@@ -35,6 +37,8 @@
#define DPU_ENC_WR_PTR_START_TIMEOUT_US 2
+#define DPU_ENC_MAX_POLL_TIMEOUT_US2000
+
static bool dpu_encoder_phys_cmd_is_master(struct dpu_encoder_phys *phys_enc)
{
return (phys_enc->split_role != ENC_ROLE_SLAVE) ? true : false;
@@ -582,6 +586,69 @@ static void dpu_encoder_phys_cmd_prepare_for_kickoff(
atomic_read(_enc->pending_kickoff_cnt));
}
+static bool dpu_encoder_phys_cmd_is_ongoing_pptx(
+ struct dpu_encoder_phys *phys_enc)
+{
+ struct dpu_hw_pp_vsync_info info;
+
+ if (!phys_enc)
+ return false;
+
+ phys_enc->hw_pp->ops.get_vsync_info(phys_enc->hw_pp, );
+ if (info.wr_ptr_line_count > 0 &&
+ info.wr_ptr_line_count < phys_enc->cached_mode.vdisplay)
+ return true;
+
+ return false;
+}
+
+static void dpu_encoder_phys_cmd_prepare_commit(
+ struct dpu_encoder_phys *phys_enc)
+{
+ struct dpu_encoder_phys_cmd *cmd_enc =
+ to_dpu_encoder_phys_cmd(phys_enc);
+ int trial = 0;
+
+ if (!phys_enc)
+ return;
+ if (!phys_enc->hw_pp)
+ return;
+ if (!dpu_encoder_phys_cmd_is_master(phys_enc))
+ return;
+
+ /* If autorefresh is already disabled, we have nothing to do */
+ if (!phys_enc->hw_pp->ops.get_autorefresh(phys_enc->hw_pp, NULL))
+ return;
+
+ /*
+* If autorefresh is enabled, disable it and make sure it is safe to
+* proceed with current frame commit/push. Sequence fallowed is,
+* 1. Disable TE
+* 2. Disable autorefresh config
+* 4. Poll for frame transfer ongoing to be false
+* 5. Enable TE back
+*/
+ _dpu_encoder_phys_cmd_connect_te(phys_enc, false);
+ phys_enc->hw_pp->ops.setup_autorefresh(phys_enc->hw_pp, 0, false);
+
+ do {
+ udelay(DPU_ENC_MAX_POLL_TIMEOUT_US);
+ if ((trial * DPU_ENC_MAX_POLL_TIMEOUT_US)
+ > (KICKOFF_TIMEOUT_MS * USEC_PER_MSEC)) {
+ DPU_ERROR_CMDENC(cmd_enc,
+ "disable autorefresh failed\n");
+ break;
+ }
+
+ trial++;
+ } while (dpu_encoder_phys_cmd_is_ongoing_pptx(phys_enc));
+
+ _dpu_encoder_phys_cmd_connect_te(phys_enc, true);
+
+ DPU_DEBUG_CMDENC(to_dpu_encoder_phys_cmd(phys_enc),
+"disabled autorefresh\n");
+}
+
static int _dpu_encoder_phys_cmd_wait_for_ctl_start(
struct dpu_encoder_phys *phys_enc)
{
@@ -683,6 +750,7 @@ static void dpu_encoder_phys_cmd_trigger_start(
static void dpu_encoder_phys_cmd_init_ops(
struct dpu_encoder_phys_ops *ops)
{
+ ops->prepare_commit = dpu_encoder_phys_cmd_prepare_commit;
ops->is_master = dpu_encoder_phys_cmd_is_master;
ops->mode_set = dpu_encoder_phys_cmd_mode_set;
ops->mode_fixup = dpu_encoder_phys_cmd_mode_fixup;
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
index bea4ab5c58c5..245a7a62b5c6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c
@@ -23,6 +23,7 @@
#define PP_WR_PTR_IRQ 0x024
#define PP_OUT_LINE_COUNT 0x028
#define PP_LINE_COUNT 0x02C
+#define PP_AUTOREFRESH_CONFIG 0x030
#define PP_FBC_MODE 0x034
#define PP_FBC_BUDGET_CTL 0x038
@@ -120,6 +121,29 @@ static int
[PATCH 6/9] drm/msm/dpu: Correctly configure vsync tearcheck for command mode
When configuring the tearcheck, the parameters for the engine were being set mostly as they should've been, but then it wasn't getting configured to get the vsync indication from the TE GPIO input because it was assumed that autorefresh could be enabled: since a previous commit makes sure to disable the autorefresh bit when committing to the cmd engine, it is now safe to just enable the vsync pin input at tearcheck setup time (instead of erroneously never enabling it). Also, set the right sync_cfg_height to enable the DPU auto-generated TE signal in order to avoid stalls in the event that we miss one external TE signal: this will still trigger recovery mechanisms in case the display is really unreachable. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 11 --- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c index a367b093c888..c5cf59b5bd41 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c @@ -372,15 +372,12 @@ static void dpu_encoder_phys_cmd_tearcheck_config( tc_cfg.vsync_count = vsync_hz / (mode->vtotal * drm_mode_vrefresh(mode)); - /* enable external TE after kickoff to avoid premature autorefresh */ - tc_cfg.hw_vsync_mode = 0; - /* -* By setting sync_cfg_height to near max register value, we essentially -* disable dpu hw generated TE signal, since hw TE will arrive first. -* Only caveat is if due to error, we hit wrap-around. +* Set the sync_cfg_height to twice vtotal so that if we lose a +* TE event coming from the display TE pin we won't stall immediately */ - tc_cfg.sync_cfg_height = 0xFFF0; + tc_cfg.hw_vsync_mode = 1; + tc_cfg.sync_cfg_height = mode->vtotal * 2; tc_cfg.vsync_init_val = mode->vdisplay; tc_cfg.sync_threshold_start = DEFAULT_TEARCHECK_SYNC_THRESH_START; tc_cfg.sync_threshold_continue = DEFAULT_TEARCHECK_SYNC_THRESH_CONTINUE; -- 2.29.2
[PATCH 3/9] drm/msm/dpu1: Add prog_fetch_lines_worst_case to INTF_BLK macro
Not all DPU interface sub-block versions need the same value for
prog_fetch_lines_worst_case: add this to the INTF_BLK macro, so
that it becomes possible to vary it for other INTF versions.
For example, this is needed to implement support for older SoCs,
like MSM8998 and SDM630/660 and most probably will also be needed
for future SoCs.
Signed-off-by: AngeloGioacchino Del Regno
---
.../gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c| 24 +--
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 983ee5ac2c45..253075091409 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -520,33 +520,33 @@ static const struct dpu_pingpong_cfg sm8150_pp[] = {
/*
* INTF sub blocks config
*/
-#define INTF_BLK(_name, _id, _base, _type, _ctrl_id, _features) \
+#define INTF_BLK(_name, _id, _base, _type, _ctrl_id, _progfetch, _features) \
{\
.name = _name, .id = _id, \
.base = _base, .len = 0x280, \
.features = _features, \
.type = _type, \
.controller_id = _ctrl_id, \
- .prog_fetch_lines_worst_case = 24 \
+ .prog_fetch_lines_worst_case = _progfetch \
}
static const struct dpu_intf_cfg sdm845_intf[] = {
- INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, INTF_SDM845_MASK),
- INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SDM845_MASK),
- INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, INTF_SDM845_MASK),
- INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1, INTF_SDM845_MASK),
+ INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, 24, INTF_SDM845_MASK),
+ INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, 24, INTF_SDM845_MASK),
+ INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, 24, INTF_SDM845_MASK),
+ INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1, 24, INTF_SDM845_MASK),
};
static const struct dpu_intf_cfg sc7180_intf[] = {
- INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, INTF_SC7180_MASK),
- INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SC7180_MASK),
+ INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, 24, INTF_SC7180_MASK),
+ INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, 24, INTF_SC7180_MASK),
};
static const struct dpu_intf_cfg sm8150_intf[] = {
- INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, INTF_SC7180_MASK),
- INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, INTF_SC7180_MASK),
- INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, INTF_SC7180_MASK),
- INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1, INTF_SC7180_MASK),
+ INTF_BLK("intf_0", INTF_0, 0x6A000, INTF_DP, 0, 24, INTF_SC7180_MASK),
+ INTF_BLK("intf_1", INTF_1, 0x6A800, INTF_DSI, 0, 24, INTF_SC7180_MASK),
+ INTF_BLK("intf_2", INTF_2, 0x6B000, INTF_DSI, 1, 24, INTF_SC7180_MASK),
+ INTF_BLK("intf_3", INTF_3, 0x6B800, INTF_DP, 1, 24, INTF_SC7180_MASK),
};
/*
--
2.29.2
[PATCH 7/9] drm/msm/dpu: Remove unused call in wait_for_commit_done
The call to dpu_encoder_phys_cmd_prepare_for_kickoff is useless as
it's unused because the serialize_wait4pp variable is never set to
true by .. anything, literally: remove the call.
While at it, also reduce indentation by inverting the check for
dpu_encoder_phys_cmd_is_master.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index c5cf59b5bd41..2311e98480b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -687,20 +687,15 @@ static int dpu_encoder_phys_cmd_wait_for_tx_complete(
static int dpu_encoder_phys_cmd_wait_for_commit_done(
struct dpu_encoder_phys *phys_enc)
{
- int rc = 0;
struct dpu_encoder_phys_cmd *cmd_enc;
cmd_enc = to_dpu_encoder_phys_cmd(phys_enc);
/* only required for master controller */
- if (dpu_encoder_phys_cmd_is_master(phys_enc))
- rc = _dpu_encoder_phys_cmd_wait_for_ctl_start(phys_enc);
-
- /* required for both controllers */
- if (!rc && cmd_enc->serialize_wait4pp)
- dpu_encoder_phys_cmd_prepare_for_kickoff(phys_enc);
+ if (!dpu_encoder_phys_cmd_is_master(phys_enc))
+ return 0;
- return rc;
+ return _dpu_encoder_phys_cmd_wait_for_ctl_start(phys_enc);
}
static int dpu_encoder_phys_cmd_wait_for_vblank(
--
2.29.2
[PATCH 9/9] drm/msm/dpu: Fix timeout issues on command mode panels
In function dpu_encoder_phys_cmd_wait_for_commit_done we are always checking if the relative CTL is started by waiting for an interrupt to fire: it is fine to do that, but then sometimes we call this function while the CTL is up and has never been put down, but that interrupt gets raised only when the CTL gets a state change from 0 to 1 (disabled to enabled), so we're going to wait for something that will never happen on its own. Solving this while avoiding to restart the CTL is actually possible and can be done by just checking if it is already up and running when the wait_for_commit_done function is called: in this case, so, if the CTL was already running, we can say that the commit is done if the command transmission is complete (in other terms, if the interface has been flushed). Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c index 2311e98480b9..0624864da343 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c @@ -695,6 +695,9 @@ static int dpu_encoder_phys_cmd_wait_for_commit_done( if (!dpu_encoder_phys_cmd_is_master(phys_enc)) return 0; + if (phys_enc->hw_ctl->ops.is_started) + return dpu_encoder_phys_cmd_wait_for_tx_complete(phys_enc); + return _dpu_encoder_phys_cmd_wait_for_ctl_start(phys_enc); } -- 2.29.2
Re: [PATCH 2/2] ARM: dts: rockchip: add extra cpu opp points to rk3288-miqi
Hi Demetris,
Am Freitag, 8. Januar 2021, 16:10:36 CET schrieb Demetris Ierokipides:
> Add extra 1.7GHz and 1.8GHz opp points to the MiQi device-tree to improve
> performance.
>
> Signed-off-by: Demetris Ierokipides
> ---
> arch/arm/boot/dts/rk3288-miqi.dts | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/rk3288-miqi.dts
> b/arch/arm/boot/dts/rk3288-miqi.dts
> index 713f55e143c6..1b48855db6ff 100644
> --- a/arch/arm/boot/dts/rk3288-miqi.dts
> +++ b/arch/arm/boot/dts/rk3288-miqi.dts
> @@ -96,6 +96,18 @@ {
> cpu-supply = <_cpu>;
> };
>
> +_opp_table {
> + opp-170400 {
> + opp-hz = /bits/ 64 <170400>;
> + opp-microvolt = <135>;
> + };
> +
> + opp-18 {
> + opp-hz = /bits/ 64 <18>;
> + opp-microvolt = <135>;
> + };
> +};
> +
sorry, but no .
The OPPs in the mainline kernel match the specifications released by the
soc vendor. Going outside these specs _may_ affect things like stability
on some boards or in general simply the lifetime of the chip itself.
So yes, while boards may generally work with these higher frequencies
I don't think this should be the default coming from the mainline kernel.
If board-owners feel the need to exceed the specs they can still modify
the dts, but we shouldn't force this decision on everyone.
Heiko
[PATCH] drm/msm/a5xx: Allow all patchid for A540 chip
On at least MSM8998 it's possible to find Adreno 540.0 and 540.1
but I have never found any 540.2. In any case, the patchids 0-1
for A540 are completely supported by this driver and there is no
reason to disallow probing them (as they also share the same
firmware names).
Besides that, the patchid number is also used in the a5xx_power.c
function a540_lm_setup to disable the battery current limiter,
which makes faking the Adreno patchid to .2 (which would anyway
be sad) useless and even producing breakages.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 76a89a8175f8..133e3c15a1b7 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -216,7 +216,7 @@ static const struct adreno_info gpulist[] = {
.init = a5xx_gpu_init,
.zapfw = "a530_zap.mdt",
}, {
- .rev = ADRENO_REV(5, 4, 0, 2),
+ .rev = ADRENO_REV(5, 4, 0, ANY_ID),
.revn = 540,
.name = "A540",
.fw = {
--
2.29.2
[PATCH 0/9] Clock fixes for MSM8998 GCC, MMCC, GPUCC
This patch series fixes some issues with the MSM8998 clocks and, in particular, brings a very important fix to the GCC PLLs. These fixes are enhancing this SoC's stability and also makes it possible to eventually enable the Adreno GPU (with proper clock scaling) and other components. This patch series was tested on: - Sony Xperia XZ Premium (MSM8998) - F(x)Tec Pro1 (MSM8998) AngeloGioacchino Del Regno (9): clk: qcom: gcc-msm8998: Wire up gcc_mmss_gpll0 clock clk: qcom: gcc-msm8998: Add missing hmss_gpll0_clk_src clock clk: qcom: gcc-msm8998: Mark gpu_cfg_ahb_clk as critical clk: qcom: gcc-msm8998: Fix Alpha PLL type for all GPLLs clk: qcom: mmcc-msm8998: Set CLK_GET_RATE_NOCACHE to pixel/byte clks clk: qcom: mmcc-msm8998: Add hardware clockgating registers to some clks clk: qcom: mmcc-msm8998: Set bimc_smmu_gdsc always on clk: qcom: gpucc-msm8998: Add resets, cxc, fix flags on gpu_gx_gdsc clk: qcom: gpucc-msm8998: Allow fabia gpupll0 rate setting drivers/clk/qcom/gcc-msm8998.c | 143 --- drivers/clk/qcom/gpucc-msm8998.c | 18 ++- drivers/clk/qcom/mmcc-msm8998.c | 20 ++- include/dt-bindings/clock/qcom,gcc-msm8998.h | 2 + 4 files changed, 125 insertions(+), 58 deletions(-) -- 2.29.2
[PATCH 1/9] clk: qcom: gcc-msm8998: Wire up gcc_mmss_gpll0 clock
This clock enables the GPLL0 output to the multimedia subsystem
clock controller.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/clk/qcom/gcc-msm8998.c | 17 +
include/dt-bindings/clock/qcom,gcc-msm8998.h | 1 +
2 files changed, 18 insertions(+)
diff --git a/drivers/clk/qcom/gcc-msm8998.c b/drivers/clk/qcom/gcc-msm8998.c
index 9d7016bcd680..d51c556851ca 100644
--- a/drivers/clk/qcom/gcc-msm8998.c
+++ b/drivers/clk/qcom/gcc-msm8998.c
@@ -1341,6 +1341,22 @@ static struct clk_branch gcc_boot_rom_ahb_clk = {
},
};
+static struct clk_branch gcc_mmss_gpll0_clk = {
+ .halt_check = BRANCH_HALT_DELAY,
+ .clkr = {
+ .enable_reg = 0x5200c,
+ .enable_mask = BIT(1),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_mmss_gpll0_clk",
+ .parent_names = (const char *[]){
+ "gpll0_out_main",
+ },
+ .num_parents = 1,
+ .ops = _branch2_ops,
+ },
+ },
+};
+
static struct clk_branch gcc_mss_gpll0_div_clk_src = {
.halt_check = BRANCH_HALT_DELAY,
.clkr = {
@@ -2944,6 +2960,7 @@ static struct clk_regmap *gcc_msm8998_clocks[] = {
[GCC_MSS_GPLL0_DIV_CLK_SRC] = _mss_gpll0_div_clk_src.clkr,
[GCC_MSS_SNOC_AXI_CLK] = _mss_snoc_axi_clk.clkr,
[GCC_MSS_MNOC_BIMC_AXI_CLK] = _mss_mnoc_bimc_axi_clk.clkr,
+ [GCC_MMSS_GPLL0_CLK] = _mmss_gpll0_clk.clkr,
};
static struct gdsc *gcc_msm8998_gdscs[] = {
diff --git a/include/dt-bindings/clock/qcom,gcc-msm8998.h
b/include/dt-bindings/clock/qcom,gcc-msm8998.h
index 6a73a174f049..47ca17df780b 100644
--- a/include/dt-bindings/clock/qcom,gcc-msm8998.h
+++ b/include/dt-bindings/clock/qcom,gcc-msm8998.h
@@ -184,6 +184,7 @@
#define GCC_MSS_MNOC_BIMC_AXI_CLK 175
#define GCC_BIMC_GFX_CLK 176
#define UFS_UNIPRO_CORE_CLK_SRC177
+#define GCC_MMSS_GPLL0_CLK 178
#define PCIE_0_GDSC0
#define UFS_GDSC 1
--
2.29.2
[PATCH 2/9] clk: qcom: gcc-msm8998: Add missing hmss_gpll0_clk_src clock
To achieve CPR-Hardened functionality this clock must be on: add it
in order to be able to get it managed by the CPR3 driver.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/clk/qcom/gcc-msm8998.c | 20
include/dt-bindings/clock/qcom,gcc-msm8998.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/drivers/clk/qcom/gcc-msm8998.c b/drivers/clk/qcom/gcc-msm8998.c
index d51c556851ca..c8d4c0348952 100644
--- a/drivers/clk/qcom/gcc-msm8998.c
+++ b/drivers/clk/qcom/gcc-msm8998.c
@@ -2160,6 +2160,25 @@ static struct clk_branch gcc_hmss_trig_clk = {
},
};
+static struct freq_tbl ftbl_hmss_gpll0_clk_src[] = {
+ F( 3, P_GPLL0_OUT_MAIN, 2, 0, 0),
+ F( 6, P_GPLL0_OUT_MAIN, 1, 0, 0),
+ { }
+};
+
+static struct clk_rcg2 hmss_gpll0_clk_src = {
+ .cmd_rcgr = 0x4805c,
+ .hid_width = 5,
+ .parent_map = gcc_parent_map_1,
+ .freq_tbl = ftbl_hmss_gpll0_clk_src,
+ .clkr.hw.init = &(struct clk_init_data) {
+ .name = "hmss_gpll0_clk_src",
+ .parent_names = gcc_parent_names_1,
+ .num_parents = ARRAY_SIZE(gcc_parent_names_1),
+ .ops = _rcg2_ops,
+ },
+};
+
static struct clk_branch gcc_mmss_noc_cfg_ahb_clk = {
.halt_reg = 0x9004,
.halt_check = BRANCH_HALT,
@@ -2961,6 +2980,7 @@ static struct clk_regmap *gcc_msm8998_clocks[] = {
[GCC_MSS_SNOC_AXI_CLK] = _mss_snoc_axi_clk.clkr,
[GCC_MSS_MNOC_BIMC_AXI_CLK] = _mss_mnoc_bimc_axi_clk.clkr,
[GCC_MMSS_GPLL0_CLK] = _mmss_gpll0_clk.clkr,
+ [HMSS_GPLL0_CLK_SRC] = _gpll0_clk_src.clkr,
};
static struct gdsc *gcc_msm8998_gdscs[] = {
diff --git a/include/dt-bindings/clock/qcom,gcc-msm8998.h
b/include/dt-bindings/clock/qcom,gcc-msm8998.h
index 47ca17df780b..72c99e486d86 100644
--- a/include/dt-bindings/clock/qcom,gcc-msm8998.h
+++ b/include/dt-bindings/clock/qcom,gcc-msm8998.h
@@ -185,6 +185,7 @@
#define GCC_BIMC_GFX_CLK 176
#define UFS_UNIPRO_CORE_CLK_SRC177
#define GCC_MMSS_GPLL0_CLK 178
+#define HMSS_GPLL0_CLK_SRC 179
#define PCIE_0_GDSC0
#define UFS_GDSC 1
--
2.29.2
[PATCH 4/9] clk: qcom: gcc-msm8998: Fix Alpha PLL type for all GPLLs
All of the GPLLs in the MSM8998 Global Clock Controller are Fabia PLLs
and not generic alphas: this was producing bad effects over the entire
clock tree of MSM8998, where any GPLL child clock was declaring a false
clock rate, due to their parent also showing the same.
The issue resides in the calculation of the clock rate for the specific
Alpha PLL type, where Fabia has a different register layout; switching
the MSM8998 GPLLs to the correct Alpha Fabia PLL type fixes the rate
(calculation) reading. While at it, also make these PLLs fixed since
their rate is supposed to *never* be changed while the system runs, as
this would surely crash the entire SoC.
Now all the children of all the PLLs are also complying with their
specified clock table and system stability is improved.
Fixes: b5f5f525c547 ("clk: qcom: Add MSM8998 Global Clock Control (GCC) driver")
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/clk/qcom/gcc-msm8998.c | 100 -
1 file changed, 50 insertions(+), 50 deletions(-)
diff --git a/drivers/clk/qcom/gcc-msm8998.c b/drivers/clk/qcom/gcc-msm8998.c
index afea60a3ef43..050c91af888e 100644
--- a/drivers/clk/qcom/gcc-msm8998.c
+++ b/drivers/clk/qcom/gcc-msm8998.c
@@ -135,7 +135,7 @@ static struct pll_vco fabia_vco[] = {
static struct clk_alpha_pll gpll0 = {
.offset = 0x0,
- .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
.vco_table = fabia_vco,
.num_vco = ARRAY_SIZE(fabia_vco),
.clkr = {
@@ -145,58 +145,58 @@ static struct clk_alpha_pll gpll0 = {
.name = "gpll0",
.parent_names = (const char *[]){ "xo" },
.num_parents = 1,
- .ops = _alpha_pll_ops,
+ .ops = _alpha_pll_fixed_fabia_ops,
}
},
};
static struct clk_alpha_pll_postdiv gpll0_out_even = {
.offset = 0x0,
- .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
.clkr.hw.init = &(struct clk_init_data){
.name = "gpll0_out_even",
.parent_names = (const char *[]){ "gpll0" },
.num_parents = 1,
- .ops = _alpha_pll_postdiv_ops,
+ .ops = _alpha_pll_postdiv_fabia_ops,
},
};
static struct clk_alpha_pll_postdiv gpll0_out_main = {
.offset = 0x0,
- .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
.clkr.hw.init = &(struct clk_init_data){
.name = "gpll0_out_main",
.parent_names = (const char *[]){ "gpll0" },
.num_parents = 1,
- .ops = _alpha_pll_postdiv_ops,
+ .ops = _alpha_pll_postdiv_fabia_ops,
},
};
static struct clk_alpha_pll_postdiv gpll0_out_odd = {
.offset = 0x0,
- .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
.clkr.hw.init = &(struct clk_init_data){
.name = "gpll0_out_odd",
.parent_names = (const char *[]){ "gpll0" },
.num_parents = 1,
- .ops = _alpha_pll_postdiv_ops,
+ .ops = _alpha_pll_postdiv_fabia_ops,
},
};
static struct clk_alpha_pll_postdiv gpll0_out_test = {
.offset = 0x0,
- .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
.clkr.hw.init = &(struct clk_init_data){
.name = "gpll0_out_test",
.parent_names = (const char *[]){ "gpll0" },
.num_parents = 1,
- .ops = _alpha_pll_postdiv_ops,
+ .ops = _alpha_pll_postdiv_fabia_ops,
},
};
static struct clk_alpha_pll gpll1 = {
.offset = 0x1000,
- .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
.vco_table = fabia_vco,
.num_vco = ARRAY_SIZE(fabia_vco),
.clkr = {
@@ -206,58 +206,58 @@ static struct clk_alpha_pll gpll1 = {
.name = "gpll1",
.parent_names = (const char *[]){ "xo" },
.num_parents = 1,
- .ops = _alpha_pll_ops,
+ .ops = _alpha_pll_fixed_fabia_ops,
}
},
};
static struct clk_alpha_pll_postdiv gpll1_out_even = {
.offset = 0x1000,
- .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_DEFAULT],
+ .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
.clkr.hw.init = &(struct clk_init_data){
.name = "gpll1_out_even",
.parent_names = (const char *[]){ "gpll1" },
.num_parents = 1,
- .ops
[PATCH 7/9] clk: qcom: mmcc-msm8998: Set bimc_smmu_gdsc always on
This GDSC enables (or cuts!) power to the Multimedia Subsystem IOMMU
(mmss smmu), which has bootloader pre-set secure contexts.
In the event of a complete power loss, the secure contexts will be
reset and the hypervisor will crash the SoC.
To prevent this, and get a working multimedia subsystem, set this
GDSC as always on.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/clk/qcom/mmcc-msm8998.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/mmcc-msm8998.c b/drivers/clk/qcom/mmcc-msm8998.c
index f9510a248a36..b49c4137b7d7 100644
--- a/drivers/clk/qcom/mmcc-msm8998.c
+++ b/drivers/clk/qcom/mmcc-msm8998.c
@@ -2663,7 +2663,7 @@ static struct gdsc bimc_smmu_gdsc = {
.name = "bimc_smmu",
},
.pwrsts = PWRSTS_OFF_ON,
- .flags = HW_CTRL,
+ .flags = HW_CTRL | ALWAYS_ON,
};
static struct clk_regmap *mmcc_msm8998_clocks[] = {
--
2.29.2
[PATCH 9/9] clk: qcom: gpucc-msm8998: Allow fabia gpupll0 rate setting
The GPU PLL0 is not a fixed PLL and the rate can be set on it:
this is necessary especially on boards which bootloader is setting
a very low rate on this PLL before booting Linux, which would be
unsuitable for postdividing to reach the maximum allowed Adreno GPU
frequency of 710MHz (or, actually, even 670MHz..) on this SoC.
To allow setting rates on the GPU PLL0, also define VCO boundaries
and set the CLK_SET_RATE_PARENT flag to the GPU PLL0 postdivider.
With this change, the Adreno GPU is now able to scale through all
the available frequencies.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/clk/qcom/gpucc-msm8998.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/gpucc-msm8998.c b/drivers/clk/qcom/gpucc-msm8998.c
index 1a518c4915b4..fedfffaf0a8d 100644
--- a/drivers/clk/qcom/gpucc-msm8998.c
+++ b/drivers/clk/qcom/gpucc-msm8998.c
@@ -50,6 +50,11 @@ static struct clk_branch gpucc_cxo_clk = {
},
};
+static struct pll_vco fabia_vco[] = {
+ { 24960, 20, 0 },
+ { 12500, 10, 1 },
+};
+
static const struct clk_div_table post_div_table_fabia_even[] = {
{ 0x0, 1 },
{ 0x1, 2 },
@@ -61,11 +66,13 @@ static const struct clk_div_table
post_div_table_fabia_even[] = {
static struct clk_alpha_pll gpupll0 = {
.offset = 0x0,
.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_FABIA],
+ .vco_table = fabia_vco,
+ .num_vco = ARRAY_SIZE(fabia_vco),
.clkr.hw.init = &(struct clk_init_data){
.name = "gpupll0",
.parent_hws = (const struct clk_hw *[]){ _cxo_clk.clkr.hw
},
.num_parents = 1,
- .ops = _alpha_pll_fixed_fabia_ops,
+ .ops = _alpha_pll_fabia_ops,
},
};
@@ -80,6 +87,7 @@ static struct clk_alpha_pll_postdiv gpupll0_out_even = {
.name = "gpupll0_out_even",
.parent_hws = (const struct clk_hw *[]){ },
.num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
.ops = _alpha_pll_postdiv_fabia_ops,
},
};
--
2.29.2
[PATCH 5/9] clk: qcom: mmcc-msm8998: Set CLK_GET_RATE_NOCACHE to pixel/byte clks
The pixel and byte clocks rate should not be cached, as a VCO shutdown
may clear the frequency setup and this may not be set again due to the
cached rate being present.
This will also be useful when shadow clocks will be implemented in
the DSI PLL for seamless timing/resolution switch.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/clk/qcom/mmcc-msm8998.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/qcom/mmcc-msm8998.c b/drivers/clk/qcom/mmcc-msm8998.c
index dd68983fe22e..475e00a5fdf4 100644
--- a/drivers/clk/qcom/mmcc-msm8998.c
+++ b/drivers/clk/qcom/mmcc-msm8998.c
@@ -520,7 +520,7 @@ static struct clk_rcg2 byte0_clk_src = {
.parent_data = mmss_xo_dsibyte,
.num_parents = 4,
.ops = _byte2_ops,
- .flags = CLK_SET_RATE_PARENT,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
},
};
@@ -533,7 +533,7 @@ static struct clk_rcg2 byte1_clk_src = {
.parent_data = mmss_xo_dsibyte,
.num_parents = 4,
.ops = _byte2_ops,
- .flags = CLK_SET_RATE_PARENT,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
},
};
@@ -1084,7 +1084,7 @@ static struct clk_rcg2 pclk0_clk_src = {
.parent_data = mmss_xo_dsi0pll_dsi1pll,
.num_parents = 4,
.ops = _pixel_ops,
- .flags = CLK_SET_RATE_PARENT,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
},
};
@@ -1098,7 +1098,7 @@ static struct clk_rcg2 pclk1_clk_src = {
.parent_data = mmss_xo_dsi0pll_dsi1pll,
.num_parents = 4,
.ops = _pixel_ops,
- .flags = CLK_SET_RATE_PARENT,
+ .flags = CLK_SET_RATE_PARENT | CLK_GET_RATE_NOCACHE,
},
};
--
2.29.2
[PATCH 8/9] clk: qcom: gpucc-msm8998: Add resets, cxc, fix flags on gpu_gx_gdsc
The GPU GX GDSC has GPU_GX_BCR reset and gfx3d_clk CXC, as stated
on downstream kernels (and as verified upstream, because otherwise
random lockups happen).
Also, add PWRSTS_RET and NO_RET_PERIPH: also as found downstream,
and also as verified here, to avoid GPU related lockups it is
necessary to force retain mem, but *not* peripheral when enabling
this GDSC (and, of course, the inverse on disablement).
With this change, the GPU finally works flawlessly on my four
different MSM8998 devices from two different manufacturers.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/clk/qcom/gpucc-msm8998.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/qcom/gpucc-msm8998.c b/drivers/clk/qcom/gpucc-msm8998.c
index 9b3923af02a1..1a518c4915b4 100644
--- a/drivers/clk/qcom/gpucc-msm8998.c
+++ b/drivers/clk/qcom/gpucc-msm8998.c
@@ -253,12 +253,16 @@ static struct gdsc gpu_cx_gdsc = {
static struct gdsc gpu_gx_gdsc = {
.gdscr = 0x1094,
.clamp_io_ctrl = 0x130,
+ .resets = (unsigned int []){ GPU_GX_BCR },
+ .reset_count = 1,
+ .cxcs = (unsigned int []){ 0x1098 },
+ .cxc_count = 1,
.pd = {
.name = "gpu_gx",
},
.parent = _cx_gdsc.pd,
- .pwrsts = PWRSTS_OFF_ON,
- .flags = CLAMP_IO | AON_RESET,
+ .pwrsts = PWRSTS_OFF_ON | PWRSTS_RET,
+ .flags = CLAMP_IO | SW_RESET | AON_RESET | NO_RET_PERIPH,
};
static struct clk_regmap *gpucc_msm8998_clocks[] = {
--
2.29.2
[PATCH 3/9] clk: qcom: gcc-msm8998: Mark gpu_cfg_ahb_clk as critical
The GPU IOMMU depends on this clock and the hypervisor will crash
the SoC if this clock gets disabled because the secure contexts
that have been set on this IOMMU by the bootloader will become
unaccessible (or they get reset).
Mark this clock as critical to avoid this issue when the Adreno
GPU is enabled.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/clk/qcom/gcc-msm8998.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/qcom/gcc-msm8998.c b/drivers/clk/qcom/gcc-msm8998.c
index c8d4c0348952..afea60a3ef43 100644
--- a/drivers/clk/qcom/gcc-msm8998.c
+++ b/drivers/clk/qcom/gcc-msm8998.c
@@ -2081,6 +2081,12 @@ static struct clk_branch gcc_gpu_cfg_ahb_clk = {
.hw.init = &(struct clk_init_data){
.name = "gcc_gpu_cfg_ahb_clk",
.ops = _branch2_ops,
+ /*
+* The GPU IOMMU depends on this clock and hypervisor
+* will crash the SoC if this clock goes down, due to
+* secure contexts protection.
+*/
+ .flags = CLK_IS_CRITICAL,
},
},
};
--
2.29.2
[PATCH 6/9] clk: qcom: mmcc-msm8998: Add hardware clockgating registers to some clks
Hardware clock gating is supported on some of the clocks declared in
there: ignoring that it does exist may lead to unstabilities on some
firmwares.
Add the HWCG registers where applicable to stop potential crashes.
This was verified on a smartphone shipped with a recent MSM8998
firmware, which will experience random crashes without this change.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/clk/qcom/mmcc-msm8998.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/qcom/mmcc-msm8998.c b/drivers/clk/qcom/mmcc-msm8998.c
index 475e00a5fdf4..f9510a248a36 100644
--- a/drivers/clk/qcom/mmcc-msm8998.c
+++ b/drivers/clk/qcom/mmcc-msm8998.c
@@ -1211,6 +1211,8 @@ static struct clk_rcg2 vfe1_clk_src = {
static struct clk_branch misc_ahb_clk = {
.halt_reg = 0x328,
+ .hwcg_reg = 0x328,
+ .hwcg_bit = 1,
.clkr = {
.enable_reg = 0x328,
.enable_mask = BIT(0),
@@ -1241,6 +1243,8 @@ static struct clk_branch video_core_clk = {
static struct clk_branch video_ahb_clk = {
.halt_reg = 0x1030,
+ .hwcg_reg = 0x1030,
+ .hwcg_bit = 1,
.clkr = {
.enable_reg = 0x1030,
.enable_mask = BIT(0),
@@ -1315,6 +1319,8 @@ static struct clk_branch video_subcore1_clk = {
static struct clk_branch mdss_ahb_clk = {
.halt_reg = 0x2308,
+ .hwcg_reg = 0x2308,
+ .hwcg_bit = 1,
.clkr = {
.enable_reg = 0x2308,
.enable_mask = BIT(0),
@@ -2496,6 +2502,8 @@ static struct clk_branch mnoc_ahb_clk = {
static struct clk_branch bimc_smmu_ahb_clk = {
.halt_reg = 0xe004,
+ .hwcg_reg = 0xe004,
+ .hwcg_bit = 1,
.clkr = {
.enable_reg = 0xe004,
.enable_mask = BIT(0),
@@ -2511,6 +2519,8 @@ static struct clk_branch bimc_smmu_ahb_clk = {
static struct clk_branch bimc_smmu_axi_clk = {
.halt_reg = 0xe008,
+ .hwcg_reg = 0xe008,
+ .hwcg_bit = 1,
.clkr = {
.enable_reg = 0xe008,
.enable_mask = BIT(0),
--
2.29.2
Re: [RFC PATCH v1 1/4] media: dt-bindings: rockchip-rga: add more rga compatible properties
Am Samstag, 19. Dezember 2020, 12:26:50 CET schrieb Johan Jonker: > Add more rga compatible properties. > > "rockchip,px30-rga", "rockchip,rk3288-rga" > "rockchip,rk3328-rga", "rockchip,rk3288-rga" > "rockchip,rk3368-rga", "rockchip,rk3288-rga" > > make ARCH=arm64 dt_binding_check > DT_SCHEMA_FILES=Documentation/devicetree/bindings/media/rockchip-rga.yaml > > Signed-off-by: Johan Jonker this patch1 should probably go through the media-tree. So hopefully media-people will notice this series? > --- > Documentation/devicetree/bindings/media/rockchip-rga.yaml | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/media/rockchip-rga.yaml > b/Documentation/devicetree/bindings/media/rockchip-rga.yaml > index dd645ddcc..a609b63bb 100644 > --- a/Documentation/devicetree/bindings/media/rockchip-rga.yaml > +++ b/Documentation/devicetree/bindings/media/rockchip-rga.yaml > @@ -21,7 +21,11 @@ properties: >- const: rockchip,rk3288-rga >- const: rockchip,rk3399-rga >- items: > - - const: rockchip,rk3228-rga > + - enum: > + - rockchip,px30-rga > + - rockchip,rk3228-rga > + - rockchip,rk3328-rga > + - rockchip,rk3368-rga >- const: rockchip,rk3288-rga > >reg: >
[PATCH 1/5] drm/msm/dsi_pll_10nm: Fix dividing the same numbers twice
In function dsi_pll_calc_dec_frac we are calculating the decimal div start parameter by dividing the decimal multiple by the fractional multiplier: the remainder of that operation is stored to then get programmed to the fractional divider registers of the PLL. It's useless to call div_u64_rem to get the remainder and *then* call div_u64 to get the division result, as the first is already giving that result: let's fix it by just caring about the result of div_u64_rem. Signed-off-by: AngeloGioacchino Del Regno --- drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c index 6ac04fc303f5..2c1fcf092ab8 100644 --- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c +++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c @@ -172,9 +172,7 @@ static void dsi_pll_calc_dec_frac(struct dsi_pll_10nm *pll) multiplier = 1 << config->frac_bits; dec_multiple = div_u64(pll_freq * multiplier, divider); - div_u64_rem(dec_multiple, multiplier, ); - - dec = div_u64(dec_multiple, multiplier); + dec = div_u64_rem(dec_multiple, multiplier, ); if (pll_freq <= 19UL) regs->pll_prop_gain_rate = 8; -- 2.29.2
[PATCH 0/5] Clock fixes for DSI 10nm PLL
The DSI 10nm PLL driver was apparently ported from downstream, but some of its "features" were not ported over, for a good reason. Pity is that the removal of the downstream dependencies broke the clock calculation logic for this driver and that made it impossible to use any DSI display on at least MSM8998. This patch series fixes the calculation issues and also solves some TODOs that I've found in this driver. Tested on: - Sony Xperia XZ Premium (MSM8998) dual-dsi command-mode LCD display - F(x)Tec Pro1 (MSM8998) single dsi, video-mode OLED display AngeloGioacchino Del Regno (5): drm/msm/dsi_pll_10nm: Fix dividing the same numbers twice drm/msm/dsi_pll_10nm: Solve TODO for multiplier frac_bits assignment drm/msm/dsi_pll_10nm: Fix bad VCO rate calculation and prescaler drm/msm/dsi_pll_10nm: Fix variable usage for pll_lockdet_rate drm/msm/dsi_pll_10nm: Convert pr_err prints to DRM_DEV_ERROR drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 43 ++ 1 file changed, 20 insertions(+), 23 deletions(-) -- 2.29.2
[PATCH 5/5] drm/msm/dsi_pll_10nm: Convert pr_err prints to DRM_DEV_ERROR
DRM_DEV_ERROR should be used across this entire source: convert the
pr_err prints to the first as a cleanup.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index df3e4584dfd7..f1091c023836 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -342,6 +342,7 @@ static int dsi_pll_10nm_vco_set_rate(struct clk_hw *hw,
unsigned long rate,
static int dsi_pll_10nm_lock_status(struct dsi_pll_10nm *pll)
{
+ struct device *dev = >pdev->dev;
int rc;
u32 status = 0;
u32 const delay_us = 100;
@@ -354,8 +355,8 @@ static int dsi_pll_10nm_lock_status(struct dsi_pll_10nm
*pll)
delay_us,
timeout_us);
if (rc)
- pr_err("DSI PLL(%d) lock failed, status=0x%08x\n",
- pll->id, status);
+ DRM_DEV_ERROR(dev, "DSI PLL(%d) lock failed, status=0x%08x\n",
+ pll->id, status);
return rc;
}
@@ -402,6 +403,7 @@ static int dsi_pll_10nm_vco_prepare(struct clk_hw *hw)
{
struct msm_dsi_pll *pll = hw_clk_to_pll(hw);
struct dsi_pll_10nm *pll_10nm = to_pll_10nm(pll);
+ struct device *dev = _10nm->pdev->dev;
int rc;
dsi_pll_enable_pll_bias(pll_10nm);
@@ -410,7 +412,7 @@ static int dsi_pll_10nm_vco_prepare(struct clk_hw *hw)
rc = dsi_pll_10nm_vco_set_rate(hw,pll_10nm->vco_current_rate, 0);
if (rc) {
- pr_err("vco_set_rate failed, rc=%d\n", rc);
+ DRM_DEV_ERROR(dev, "vco_set_rate failed, rc=%d\n", rc);
return rc;
}
@@ -427,7 +429,7 @@ static int dsi_pll_10nm_vco_prepare(struct clk_hw *hw)
/* Check for PLL lock */
rc = dsi_pll_10nm_lock_status(pll_10nm);
if (rc) {
- pr_err("PLL(%d) lock failed\n", pll_10nm->id);
+ DRM_DEV_ERROR(dev, "PLL(%d) lock failed\n", pll_10nm->id);
goto error;
}
--
2.29.2
[PATCH 2/5] drm/msm/dsi_pll_10nm: Solve TODO for multiplier frac_bits assignment
The number of fractional registers bits is known and already set in
the frac_bits variable of the dsi_pll_config struct here in 10nm:
remove the TODO by simply using that variable.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
index 2c1fcf092ab8..8b66e852eb36 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c
@@ -481,6 +481,7 @@ static unsigned long dsi_pll_10nm_vco_recalc_rate(struct
clk_hw *hw,
{
struct msm_dsi_pll *pll = hw_clk_to_pll(hw);
struct dsi_pll_10nm *pll_10nm = to_pll_10nm(pll);
+ struct dsi_pll_config *config = _10nm->pll_configuration;
void __iomem *base = pll_10nm->mmio;
u64 ref_clk = pll_10nm->vco_ref_clk_rate;
u64 vco_rate = 0x0;
@@ -501,9 +502,8 @@ static unsigned long dsi_pll_10nm_vco_recalc_rate(struct
clk_hw *hw,
/*
* TODO:
* 1. Assumes prescaler is disabled
-* 2. Multiplier is 2^18. it should be 2^(num_of_frac_bits)
*/
- multiplier = 1 << 18;
+ multiplier = 1 << config->frac_bits;
pll_freq = dec * (ref_clk * 2);
tmp64 = (ref_clk * 2 * frac);
pll_freq += div_u64(tmp64, multiplier);
--
2.29.2
