- Linux-stable-mirror - lists.linaro.org

[PATCH v3 0/6] media: ti, cdns: Multiple pixel support and misc fixes

by Jai Luthra

Hi, The first four patches in this series are miscellaneous fixes and improvements in the Cadence and TI CSI-RX drivers around probing, fwnode and link creation. The last two patches add support for transmitting multiple pixels per clock on the internal bus between Cadence CSI-RX bridge and TI CSI-RX wrapper. As this internal bus is 32-bit wide, the maximum number of pixels that can be transmitted per cycle depend upon the format's bit width. Secondly, the downstream element must support unpacking of multiple pixels. Thus we export a module function that can be used by the downstream driver to negotiate the pixels per cycle on the output pixel stream of the Cadence bridge. Signed-off-by: Jai Luthra <jai.luthra(a)ideasonboard.com> --- Changes in v3: - Move cdns-csi2rx header to include/media - Export symbol from cdns-csi2rx.c to be used only through the j721e-csi2rx.c module namespace - Other minor fixes suggested by Sakari - Add Abhilash's T-by tags - Link to v2: https://lore.kernel.org/r/20250410-probe_fixes-v2-0-801bc6eebdea@ideasonboa… Changes in v2: - Rebase on v6.15-rc1 - Fix lkp warnings in PATCH 5/6 missing header for FIELD_PREP - Add R-By tags from Devarsh and Changhuang - Link to v1: https://lore.kernel.org/r/20250324-probe_fixes-v1-0-5cd5b9e1cfac@ideasonboa… --- Jai Luthra (6): media: ti: j721e-csi2rx: Use devm_of_platform_populate media: ti: j721e-csi2rx: Use fwnode_get_named_child_node media: ti: j721e-csi2rx: Fix source subdev link creation media: cadence: csi2rx: Implement get_fwnode_pad op media: cadence: cdns-csi2rx: Support multiple pixels per clock cycle media: ti: j721e-csi2rx: Support multiple pixels per clock MAINTAINERS | 1 + drivers/media/platform/cadence/cdns-csi2rx.c | 74 ++++++++++++++++------ drivers/media/platform/ti/Kconfig | 3 +- .../media/platform/ti/j721e-csi2rx/j721e-csi2rx.c | 65 ++++++++++++++----- include/media/cadence/cdns-csi2rx.h | 19 ++++++ 5 files changed, 127 insertions(+), 35 deletions(-) --- base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494 change-id: 20250314-probe_fixes-7e0ec33c7fee Best regards, -- Jai Luthra <jai.luthra(a)ideasonboard.com>

3 days, 20 hours

1
2
0 0

[PATCH v2 1/1] iommu/vt-d: Assign devtlb cache tag on ATS enablement

by Lu Baolu

Commit <4f1492efb495> ("iommu/vt-d: Revert ATS timing change to fix boot failure") placed the enabling of ATS in the probe_finalize callback. This occurs after the default domain attachment, which is when the ATS cache tag is assigned. Consequently, the device TLB cache tag is missed when the domain is attached, leading to the device TLB not being invalidated in the iommu_unmap paths. Fix this by assigning the CACHE_TAG_DEVTLB cache tag when ATS is enabled. Fixes: 4f1492efb495 ("iommu/vt-d: Revert ATS timing change to fix boot failure") Cc: stable(a)vger.kernel.org Suggested-by: Kevin Tian <kevin.tian(a)intel.com> Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com> Tested-by: Shuicheng Lin <shuicheng.lin(a)intel.com> --- drivers/iommu/intel/cache.c | 5 ++--- drivers/iommu/intel/iommu.c | 11 ++++++++++- drivers/iommu/intel/iommu.h | 2 ++ 3 files changed, 14 insertions(+), 4 deletions(-) Change log: v2: - The v1 solution has a flaw: ATS will never be enabled for drivers with driver_managed_dma enabled, as their devices are not expected to be automatically attached to the default domain. v1: https://lore.kernel.org/linux-iommu/20250620060802.3036137-1-baolu.lu@linux… diff --git a/drivers/iommu/intel/cache.c b/drivers/iommu/intel/cache.c index fc35cba59145..47692cbfaabd 100644 --- a/drivers/iommu/intel/cache.c +++ b/drivers/iommu/intel/cache.c @@ -40,9 +40,8 @@ static bool cache_tage_match(struct cache_tag *tag, u16 domain_id, } /* Assign a cache tag with specified type to domain. */ -static int cache_tag_assign(struct dmar_domain *domain, u16 did, - struct device *dev, ioasid_t pasid, - enum cache_tag_type type) +int cache_tag_assign(struct dmar_domain *domain, u16 did, struct device *dev, + ioasid_t pasid, enum cache_tag_type type) { struct device_domain_info *info = dev_iommu_priv_get(dev); struct intel_iommu *iommu = info->iommu; diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index 7aa3932251b2..148b944143b8 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -3780,8 +3780,17 @@ static void intel_iommu_probe_finalize(struct device *dev) !pci_enable_pasid(to_pci_dev(dev), info->pasid_supported & ~1)) info->pasid_enabled = 1; - if (sm_supported(iommu) && !dev_is_real_dma_subdevice(dev)) + if (sm_supported(iommu) && !dev_is_real_dma_subdevice(dev)) { iommu_enable_pci_ats(info); + /* Assign a DEVTLB cache tag to the default domain. */ + if (info->ats_enabled && info->domain) { + u16 did = domain_id_iommu(info->domain, iommu); + + if (cache_tag_assign(info->domain, did, dev, + IOMMU_NO_PASID, CACHE_TAG_DEVTLB)) + iommu_disable_pci_ats(info); + } + } iommu_enable_pci_pri(info); } diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h index 3ddbcc603de2..2d1afab5eedc 100644 --- a/drivers/iommu/intel/iommu.h +++ b/drivers/iommu/intel/iommu.h @@ -1289,6 +1289,8 @@ struct cache_tag { unsigned int users; }; +int cache_tag_assign(struct dmar_domain *domain, u16 did, struct device *dev, + ioasid_t pasid, enum cache_tag_type type); int cache_tag_assign_domain(struct dmar_domain *domain, struct device *dev, ioasid_t pasid); void cache_tag_unassign_domain(struct dmar_domain *domain, -- 2.43.0

3 days, 21 hours

2
1
0 0

Instability in ALL stable and LTS distro kernels (IRQ #16 being disabled, PCIe bus errors, ath10k_pci) in Dell Inspiron 5567

by Bandhan Pramanik

Hello, The following is the original thread, where a bug was reported to the linux-wireless and ath10k mailing lists. The specific bug has been detailed clearly here. https://lore.kernel.org/linux-wireless/690B1DB2-C9DC-4FAD-8063-4CED659B1701… There is also a Bugzilla report by me, which was opened later: https://bugzilla.kernel.org/show_bug.cgi?id=220264 As stated, it is highly encouraged to check out all the logs, especially the line of IRQ #16 in /proc/interrupts. Here is where all the logs are: https://gist.github.com/BandhanPramanik/ddb0cb23eca03ca2ea43a1d832a16180 (these logs are taken from an Arch liveboot) On my daily driver, I found these on my IRQ #16: 16: 173210 0 0 0 IR-IO-APIC 16-fasteoi i2c_designware.0, idma64.0, i801_smbus The fixes stated on the Reddit post for this Wi-Fi card didn't quite work. (But git-cloning the firmware files did give me some more time to have stable internet) This time, I had to go for the GRUB kernel parameters. Right now, I'm using "irqpoll" to curb the errors caused. "intel_iommu=off" did not work, and the Wi-Fi was constantly crashing even then. Did not try out "pci=noaer" this time. If it's of any concern, there is a very weird error in Chromium-based browsers which has only happened after I started using irqpoll. When I Google something, the background of the individual result boxes shows as pure black, while the surrounding space is the usual greyish-blackish, like we see in Dark Mode. Here is a picture of the exact thing I'm experiencing: https://files.catbox.moe/mjew6g.png If you notice anything in my logs/bug reports, please let me know. (Because it seems like Wi-Fi errors are just a red herring, there are some ACPI or PCIe-related errors in the computers of this model - just a naive speculation, though.) Thanking you, Bandhan Pramanik

3 days, 22 hours

2
4
0 0

[PATCH v2] dmaengine: mediatek: Fix a flag reuse error in mtk_cqdma_tx_status()

by Qiu-ji Chen

Fixed a flag reuse bug in the mtk_cqdma_tx_status() function. Fixes: 157ae5ffd76a ("dmaengine: mediatek: Fix a possible deadlock error in mtk_cqdma_tx_status()") Cc: stable(a)vger.kernel.org Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202505270641.MStzJUfU-lkp@intel.com/ Signed-off-by: Qiu-ji Chen <chenqiuji666(a)gmail.com> --- V2: Change the inner vc lock from spin_lock_irqsave() to spin_lock() Thanks Eugen Hristev for helpful suggestion. --- drivers/dma/mediatek/mtk-cqdma.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/mediatek/mtk-cqdma.c b/drivers/dma/mediatek/mtk-cqdma.c index 47c8adfdc155..9f0c41ca7770 100644 --- a/drivers/dma/mediatek/mtk-cqdma.c +++ b/drivers/dma/mediatek/mtk-cqdma.c @@ -449,9 +449,9 @@ static enum dma_status mtk_cqdma_tx_status(struct dma_chan *c, return ret; spin_lock_irqsave(&cvc->pc->lock, flags); - spin_lock_irqsave(&cvc->vc.lock, flags); + spin_lock(&cvc->vc.lock); vd = mtk_cqdma_find_active_desc(c, cookie); - spin_unlock_irqrestore(&cvc->vc.lock, flags); + spin_unlock(&cvc->vc.lock); spin_unlock_irqrestore(&cvc->pc->lock, flags); if (vd) { -- 2.34.1

3 days, 22 hours

4
3
0 0

[PATCH] i2c/designware: Fix an initialization issue

by Michael J. Ruhl

The i2c_dw_xfer_init() function requires msgs and msg_write_idx from the dev context to be initialized. amd_i2c_dw_xfer_quirk() inits msgs and msgs_num, but not msg_write_idx. This could allow an out of bounds access (of msgs). Initialize msg_write_idx before calling i2c_dw_xfer_init(). Fixes: 17631e8ca2d3 ("i2c: designware: Add driver support for AMD NAVI GPU") Cc: <stable(a)vger.kernel.org> Signed-off-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> --- drivers/i2c/busses/i2c-designware-master.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c index c5394229b77f..40aa5114bf8c 100644 --- a/drivers/i2c/busses/i2c-designware-master.c +++ b/drivers/i2c/busses/i2c-designware-master.c @@ -363,6 +363,7 @@ static int amd_i2c_dw_xfer_quirk(struct i2c_adapter *adap, struct i2c_msg *msgs, dev->msgs = msgs; dev->msgs_num = num_msgs; + dev->msg_write_idx = 0; i2c_dw_xfer_init(dev); /* Initiate messages read/write transaction */ -- 2.49.0

4 days, 1 hour

2
1
0 0

[PATCH V2] powercap: intel_rapl: Do not change CLAMPING bit if ENABLE bit cannot be changed

by Zhang Rui

PL1 cannot be disabled on some platforms. The ENABLE bit is still set after software clears it. This behavior leads to a scenario where, upon user request to disable the Power Limit through the powercap sysfs, the ENABLE bit remains set while the CLAMPING bit is inadvertently cleared. According to the Intel Software Developer's Manual, the CLAMPING bit, "When set, allows the processor to go below the OS requested P states in order to maintain the power below specified Platform Power Limit value." Thus this means the system may operate at higher power levels than intended on such platforms. Enhance the code to check ENABLE bit after writing to it, and stop further processing if ENABLE bit cannot be changed. Cc: stable(a)vger.kernel.org Reported-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Fixes: 2d281d8196e3 ("PowerCap: Introduce Intel RAPL power capping driver") Signed-off-by: Zhang Rui <rui.zhang(a)intel.com> --- Changes since V1: - Add Fixes tag - CC stable kernel --- drivers/powercap/intel_rapl_common.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/powercap/intel_rapl_common.c b/drivers/powercap/intel_rapl_common.c index e3be40adc0d7..602f540cbe15 100644 --- a/drivers/powercap/intel_rapl_common.c +++ b/drivers/powercap/intel_rapl_common.c @@ -341,12 +341,27 @@ static int set_domain_enable(struct powercap_zone *power_zone, bool mode) { struct rapl_domain *rd = power_zone_to_rapl_domain(power_zone); struct rapl_defaults *defaults = get_defaults(rd->rp); + u64 val; int ret; cpus_read_lock(); ret = rapl_write_pl_data(rd, POWER_LIMIT1, PL_ENABLE, mode); - if (!ret && defaults->set_floor_freq) + if (ret) + goto end; + + ret = rapl_read_pl_data(rd, POWER_LIMIT1, PL_ENABLE, false, &val); + if (ret) + goto end; + + if (mode != val) { + pr_debug("%s cannot be %s\n", power_zone->name, mode ? "enabled" : "disabled"); + goto end; + } + + if (defaults->set_floor_freq) defaults->set_floor_freq(rd, mode); + +end: cpus_read_unlock(); return ret; -- 2.43.0

4 days, 2 hours

2
1
0 0

[PATCH] i2c/designware: Fix an initialization issue

by Michael J. Ruhl

The i2c_dw_xfer_init() function requires msgs and msg_write_idx from the dev context to be initialized. amd_i2c_dw_xfer_quirk() inits msgs and msgs_num, but not msg_write_idx. This could allow an out of bounds access (of msgs). Initialize msg_write_idx before calling i2c_dw_xfer_init(). Fixes: 17631e8ca2d3 ("i2c: designware: Add driver support for AMD NAVI GPU") Cc: <stable(a)vger.kernel.org> Signed-off-by: Michael J. Ruhl <michael.j.ruhl(a)intel.com> --- drivers/i2c/busses/i2c-designware-master.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i2c/busses/i2c-designware-master.c b/drivers/i2c/busses/i2c-designware-master.c index c5394229b77f..40aa5114bf8c 100644 --- a/drivers/i2c/busses/i2c-designware-master.c +++ b/drivers/i2c/busses/i2c-designware-master.c @@ -363,6 +363,7 @@ static int amd_i2c_dw_xfer_quirk(struct i2c_adapter *adap, struct i2c_msg *msgs, dev->msgs = msgs; dev->msgs_num = num_msgs; + dev->msg_write_idx = 0; i2c_dw_xfer_init(dev); /* Initiate messages read/write transaction */ -- 2.49.0

4 days, 2 hours

1
0
0 0

[PATCH] tpm_crb_ffa: Remove unused export

by Jarkko Sakkinen

From: Jarkko Sakkinen <jarkko.sakkinen(a)opinsys.com> Remove the export of tpm_crb_ffa_get_interface_version() as it has no callers outside tpm_crb_ffa. Cc: stable(a)vger.kernel.org # v6.15+ Fixes: eb93f0734ef1 ("tpm_crb: ffa_tpm: Implement driver compliant to CRB over FF-A") Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)opinsys.com> --- drivers/char/tpm/tpm_crb_ffa.c | 3 +-- drivers/char/tpm/tpm_crb_ffa.h | 2 -- 2 files changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/char/tpm/tpm_crb_ffa.c b/drivers/char/tpm/tpm_crb_ffa.c index 462fcf610020..9c6a2988a598 100644 --- a/drivers/char/tpm/tpm_crb_ffa.c +++ b/drivers/char/tpm/tpm_crb_ffa.c @@ -247,7 +247,7 @@ static int __tpm_crb_ffa_send_recieve(unsigned long func_id, * * Return: 0 on success, negative error code on failure. */ -int tpm_crb_ffa_get_interface_version(u16 *major, u16 *minor) +static int tpm_crb_ffa_get_interface_version(u16 *major, u16 *minor) { int rc; @@ -275,7 +275,6 @@ int tpm_crb_ffa_get_interface_version(u16 *major, u16 *minor) return rc; } -EXPORT_SYMBOL_GPL(tpm_crb_ffa_get_interface_version); /** * tpm_crb_ffa_start() - signals the TPM that a field has changed in the CRB diff --git a/drivers/char/tpm/tpm_crb_ffa.h b/drivers/char/tpm/tpm_crb_ffa.h index 645c41ede10e..d7e1344ea003 100644 --- a/drivers/char/tpm/tpm_crb_ffa.h +++ b/drivers/char/tpm/tpm_crb_ffa.h @@ -11,11 +11,9 @@ #if IS_REACHABLE(CONFIG_TCG_ARM_CRB_FFA) int tpm_crb_ffa_init(void); -int tpm_crb_ffa_get_interface_version(u16 *major, u16 *minor); int tpm_crb_ffa_start(int request_type, int locality); #else static inline int tpm_crb_ffa_init(void) { return 0; } -static inline int tpm_crb_ffa_get_interface_version(u16 *major, u16 *minor) { return 0; } static inline int tpm_crb_ffa_start(int request_type, int locality) { return 0; } #endif -- 2.39.5

4 days, 2 hours

3
4
0 0

Tulip 21142 panic on physical link disconnect

by Greg Chandler

This is a from-scratch build (non-vendor/non-distribution) Host/Target = alpha ev6 Kernel source = 6.12.12 My last working kernel on this was a 2.6.x, it's been a while since I've had time to bring this system up to date, so I don't know when this may have started. I had a 3.0.102 in there, but I didn't test the networking while using it. Please let me know what I can do to help out with figuring this one out. The kernel output: [ 0.692382] net eth0: Digital DS21142/43 Tulip rev 65 at MMIO 0xa120000, 08:00:2b:86:ab:b1, IRQ 29 [ 0.710937] net eth1: Digital DS21142/43 Tulip rev 65 at MMIO 0xa121000, 08:00:2b:86:a8:5b, IRQ 30 [ 0.989257] e1000 0000:00:10.0 eth2: (PCI:33MHz:64-bit) 00:02:b3:f3:e6:3d [ 0.990233] e1000 0000:00:10.0 eth2: Intel(R) PRO/1000 Network Connection [ 6.088864] tulip 0000:00:09.0 eth126: renamed from eth0 [ 6.103512] tulip 0000:00:09.0 rename_eth126: renamed from eth126 [ 6.164059] e1000 0000:00:10.0 eth124: renamed from eth2 [ 6.172848] e1000 0000:00:10.0 eth0: renamed from eth124 [ 6.207028] tulip 0000:00:09.0 eth2: renamed from rename_eth126 [ 18.957998] net eth2: Using user-specified media 10baseT-FDX [ 19.082021] net eth2: 21143 10baseT link beat good I attempted to set the interface to 100MB/FDX with mii-tool but didn't seem to be having any luck, so I disconnected the cord, and it dropped this immediately: [ 195.170798] ------------[ cut here ]------------ [ 195.170798] WARNING: CPU: 0 PID: 0 at kernel/time/timer.c:1657 __timer_delete_sync+0x104/0x120 [ 195.170798] Modules linked in: loop [ 195.170798] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.12.12 #4 [ 195.170798] fffffc0000c83ab0 fffffc0000388c94 fffffc0000326744 fffffc0000afbee8 [ 195.170798] 0000000000000000 fffffc0000388c94 fffffc00009e0d70 0000000000000000 [ 195.170798] fffffc0000afbee8 0000000000000679 fffffc0000388c94 0000000000000009 [ 195.170798] fffffc0000cf9100 0000000000000000 fffffc0000388c94 0000000000000000 [ 195.170798] fffffc00020e6000 fffffc00020e73d0 fffffffff0669000 fffffd000a120000 [ 195.170798] fffffc00007cff70 fffffc00024b5c00 0000000000000000 0000000000000122 [ 195.170798] Trace: [ 195.170798] [<fffffc0000388c94>] __timer_delete_sync+0x104/0x120 [ 195.170798] [<fffffc0000326744>] __warn+0x194/0x1a0 [ 195.170798] [<fffffc0000388c94>] __timer_delete_sync+0x104/0x120 [ 195.170798] [<fffffc00009e0d70>] warn_slowpath_fmt+0x84/0xf0 [ 195.170798] [<fffffc0000388c94>] __timer_delete_sync+0x104/0x120 [ 195.170798] [<fffffc0000388c94>] __timer_delete_sync+0x104/0x120 [ 195.170798] [<fffffc00007cff70>] usb_hcd_poll_rh_status+0x140/0x1a0 [ 195.170798] [<fffffc0000919a2c>] tcp_orphan_update+0x6c/0x90 [ 195.170798] [<fffffc000038be64>] timekeeping_update+0xd4/0x290 [ 195.170798] [<fffffc0000780fdc>] t21142_lnk_change+0x1bc/0x790 [ 195.170798] [<fffffc000077a890>] tulip_interrupt+0x280/0xac0 [ 195.170798] [<fffffc0000372b90>] __handle_irq_event_percpu+0x60/0x180 [ 195.170798] [<fffffc0000372d30>] handle_irq_event_percpu+0x80/0xa0 [ 195.170798] [<fffffc0000372d98>] handle_irq_event+0x48/0xe0 [ 195.170798] [<fffffc0000377af0>] handle_level_irq+0xc0/0x1f0 [ 195.170798] [<fffffc0000315300>] handle_irq+0x70/0xe0 [ 195.170798] [<fffffc000031d6c0>] dp264_srm_device_interrupt+0x30/0x50 [ 195.170798] [<fffffc00003153dc>] do_entInt+0x6c/0x1c0 [ 195.170798] [<fffffc0000310cc0>] ret_from_sys_call+0x0/0x10 [ 195.170798] [<fffffc000035c69c>] pick_task_fair+0x3c/0x100 [ 195.170798] [<fffffc000035d89c>] task_non_contending+0x6c/0x2a0 [ 195.170798] [<fffffc000035fc28>] do_idle+0x58/0x190 [ 195.170798] [<fffffc00009eda20>] cpu_idle_poll.isra.0+0x0/0x60 [ 195.170798] [<fffffc00009eda50>] cpu_idle_poll.isra.0+0x30/0x60 [ 195.170798] [<fffffc0000360058>] cpu_startup_entry+0x38/0x50 [ 195.170798] [<fffffc00009edbc8>] rest_init+0xe8/0xec [ 195.170798] [<fffffc000031001c>] _stext+0x1c/0x20 [ 195.170798] [<fffffc0000312460>] common_shutdown_1+0x0/0x150 [ 195.170798] ---[ end trace 0000000000000000 ]--- Kernel options that may be relevant: CONFIG_ALPHA_DP264=y CONFIG_NET_TULIP=y CONFIG_TULIP=y CONFIG_TULIP_MWI=y CONFIG_TULIP_MMIO=y CONFIG_TULIP_NAPI=y CONFIG_TULIP_NAPI_HW_MITIGATION=y Device info: root@bigbang:~# lspci -vvv |more 00:09.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: Digital Equipment Corporation DE500B Fast Ethernet Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 255 (5000ns min, 10000ns max), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 29 Region 0: I/O ports at 8400 [size=128] Region 1: Memory at 0a120000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at 0a000000 [disabled] [size=256K] Kernel driver in use: tulip 00:0b.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 (rev 41) Subsystem: Digital Equipment Corporation DE500B Fast Ethernet Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 255 (5000ns min, 10000ns max), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 30 Region 0: I/O ports at 8480 [size=128] Region 1: Memory at 0a121000 (32-bit, non-prefetchable) [size=1K] Expansion ROM at 0a040000 [disabled] [size=256K] Kernel driver in use: tulip

4 days, 3 hours

3
18
0 0

[PATCH] drm/vkms: Fix race-condition between the hrtimer and the atomic commit

by Pranav Tyagi

From: Maíra Canal <mcanal(a)igalia.com> [ Upstream commit a0e6a017ab56936c0405fe914a793b241ed25ee0 ] Currently, it is possible for the composer to be set as enabled and then as disabled without a proper call for the vkms_vblank_simulate(). This is problematic, because the driver would skip one CRC output, causing CRC tests to fail. Therefore, we need to make sure that, for each time the composer is set as enabled, a composer job is added to the queue. In order to provide this guarantee, add a mutex that will lock before the composer is set as enabled and will unlock only after the composer job is added to the queue. This way, we can have a guarantee that the driver won't skip a CRC entry. This race-condition is affecting the IGT test "writeback-check-output", making the test fail and also, leaking writeback framebuffers, as the writeback job is queued, but it is not signaled. This patch avoids both problems. [v2]: * Create a new mutex and keep the spinlock across the atomic commit in order to avoid interrupts that could result in deadlocks. [ Backport to 5.15: context cleanly applied with no semantic changes. Build-tested. ] Signed-off-by: Maíra Canal <mcanal(a)igalia.com> Reviewed-by: Arthur Grillo <arthurgrillo(a)riseup.net> Signed-off-by: Maíra Canal <mairacanal(a)riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230523123207.173976-1-mcana… Signed-off-by: Pranav Tyagi <pranav.tyagi03(a)gmail.com> --- drivers/gpu/drm/vkms/vkms_composer.c | 9 +++++++-- drivers/gpu/drm/vkms/vkms_crtc.c | 9 +++++---- drivers/gpu/drm/vkms/vkms_drv.h | 4 +++- 3 files changed, 15 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/vkms/vkms_composer.c b/drivers/gpu/drm/vkms/vkms_composer.c index 9e8204be9a14..77fced36af55 100644 --- a/drivers/gpu/drm/vkms/vkms_composer.c +++ b/drivers/gpu/drm/vkms/vkms_composer.c @@ -332,10 +332,15 @@ void vkms_set_composer(struct vkms_output *out, bool enabled) if (enabled) drm_crtc_vblank_get(&out->crtc); - spin_lock_irq(&out->lock); + mutex_lock(&out->enabled_lock); old_enabled = out->composer_enabled; out->composer_enabled = enabled; - spin_unlock_irq(&out->lock); + + /* the composition wasn't enabled, so unlock the lock to make sure the lock + * will be balanced even if we have a failed commit + */ + if (!out->composer_enabled) + mutex_unlock(&out->enabled_lock); if (old_enabled) drm_crtc_vblank_put(&out->crtc); diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c index 57bbd32e9beb..1b02dee8587a 100644 --- a/drivers/gpu/drm/vkms/vkms_crtc.c +++ b/drivers/gpu/drm/vkms/vkms_crtc.c @@ -16,7 +16,7 @@ static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer) struct drm_crtc *crtc = &output->crtc; struct vkms_crtc_state *state; u64 ret_overrun; - bool ret, fence_cookie; + bool ret, fence_cookie, composer_enabled; fence_cookie = dma_fence_begin_signalling(); @@ -25,15 +25,15 @@ static enum hrtimer_restart vkms_vblank_simulate(struct hrtimer *timer) if (ret_overrun != 1) pr_warn("%s: vblank timer overrun\n", __func__); - spin_lock(&output->lock); ret = drm_crtc_handle_vblank(crtc); if (!ret) DRM_ERROR("vkms failure on handling vblank"); state = output->composer_state; - spin_unlock(&output->lock); + composer_enabled = output->composer_enabled; + mutex_unlock(&output->enabled_lock); - if (state && output->composer_enabled) { + if (state && composer_enabled) { u64 frame = drm_crtc_accurate_vblank_count(crtc); /* update frame_start only if a queued vkms_composer_worker() @@ -293,6 +293,7 @@ int vkms_crtc_init(struct drm_device *dev, struct drm_crtc *crtc, spin_lock_init(&vkms_out->lock); spin_lock_init(&vkms_out->composer_lock); + mutex_init(&vkms_out->enabled_lock); vkms_out->composer_workq = alloc_ordered_workqueue("vkms_composer", 0); if (!vkms_out->composer_workq) diff --git a/drivers/gpu/drm/vkms/vkms_drv.h b/drivers/gpu/drm/vkms/vkms_drv.h index d48c23d40ce5..666997e2bcab 100644 --- a/drivers/gpu/drm/vkms/vkms_drv.h +++ b/drivers/gpu/drm/vkms/vkms_drv.h @@ -83,8 +83,10 @@ struct vkms_output { struct workqueue_struct *composer_workq; /* protects concurrent access to composer */ spinlock_t lock; + /* guarantees that if the composer is enabled, a job will be queued */ + struct mutex enabled_lock; - /* protected by @lock */ + /* protected by @enabled_lock */ bool composer_enabled; struct vkms_crtc_state *composer_state; -- 2.49.0

4 days, 4 hours

4
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror