January 2024 - Linux-stable-mirror

patch "usb: cdns3: fix uvc failure work since sg support enabled" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: cdns3: fix uvc failure work since sg support enabled to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From 1b8be5ecff26201bafb0a554c74e91571299fb94 Mon Sep 17 00:00:00 2001 From: Frank Li <Frank.Li(a)nxp.com> Date: Sun, 24 Dec 2023 10:38:13 -0500 Subject: usb: cdns3: fix uvc failure work since sg support enabled When IP version >= DEV_VER_V2, gadget:sg_supported is true. So uvc gadget function driver will use sg to equeue data, first is 8bytes header, the second is 1016bytes data. cdns3_prepare_trb: ep2in: trb 0000000000ac755f, dma buf: 0xbf455000, size: 8, burst: 128 ctrl: 0x00000415 (C=1, T=0, ISP, CHAIN, Normal) cdns3_prepare_trb: ep2in: trb 00000000a574e693, dma buf: 0xc0200fe0, size: 1016, burst: 128 ctrl: 0x00000405 (C=1, T=0, ISP, Normal) But cdns3_ep_run_transfer() can't correctly handle this case, which only support one TRB for ISO transfer. The controller requires duplicate the TD for each SOF if priv_ep->interval is not 1. DMA will read data from DDR to internal FIFO when get SOF. Send data to bus when receive IN token. DMA always refill FIFO when get SOF regardless host send IN token or not. If host send IN token later, some frames data will be lost. Fixed it by below major steps: 1. Calculate numembers of TRB base on sg_nums and priv_ep->interval. 2. Remove CHAIN flags for each end TRB of TD when duplicate TD. 3. The controller requires LINK TRB must be first TRB of TD. When check there are not enough TRBs lefts, just fill LINK TRB for left TRBs. .... CHAIN_TRB DATA_TRB, CHAIN_TRB DATA_TRB, LINK_TRB ... LINK_TRB ^End of TRB List Cc: <stable(a)vger.kernel.org> Fixes: 7733f6c32e36 ("usb: cdns3: Add Cadence USB3 DRD Driver") Signed-off-by: Frank Li <Frank.Li(a)nxp.com> Link: https://lore.kernel.org/r/20231224153816.1664687-2-Frank.Li@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/cdns3/cdns3-gadget.c | 53 ++++++++++++++++++++++++-------- 1 file changed, 41 insertions(+), 12 deletions(-) diff --git a/drivers/usb/cdns3/cdns3-gadget.c b/drivers/usb/cdns3/cdns3-gadget.c index 15463b7cddd2..22a31ffa6942 100644 --- a/drivers/usb/cdns3/cdns3-gadget.c +++ b/drivers/usb/cdns3/cdns3-gadget.c @@ -1119,6 +1119,7 @@ static int cdns3_ep_run_transfer(struct cdns3_endpoint *priv_ep, dma_addr_t trb_dma; u32 togle_pcs = 1; int sg_iter = 0; + int num_trb_req; int num_trb; int address; u32 control; @@ -1128,15 +1129,13 @@ static int cdns3_ep_run_transfer(struct cdns3_endpoint *priv_ep, bool sg_supported = !!(request->num_mapped_sgs); u32 ioc = request->no_interrupt ? 0 : TRB_IOC; - if (priv_ep->type == USB_ENDPOINT_XFER_ISOC) - num_trb = priv_ep->interval; - else - num_trb = sg_supported ? request->num_mapped_sgs : 1; + num_trb_req = sg_supported ? request->num_mapped_sgs : 1; - if (num_trb > priv_ep->free_trbs) { - priv_ep->flags |= EP_RING_FULL; - return -ENOBUFS; - } + /* ISO transfer require each SOF have a TD, each TD include some TRBs */ + if (priv_ep->type == USB_ENDPOINT_XFER_ISOC) + num_trb = priv_ep->interval * num_trb_req; + else + num_trb = num_trb_req; priv_req = to_cdns3_request(request); address = priv_ep->endpoint.desc->bEndpointAddress; @@ -1185,14 +1184,31 @@ static int cdns3_ep_run_transfer(struct cdns3_endpoint *priv_ep, link_trb->control = cpu_to_le32(((priv_ep->pcs) ? TRB_CYCLE : 0) | TRB_TYPE(TRB_LINK) | TRB_TOGGLE | ch_bit); + + if (priv_ep->type == USB_ENDPOINT_XFER_ISOC) { + /* + * ISO require LINK TRB must be first one of TD. + * Fill LINK TRBs for left trb space to simply software process logic. + */ + while (priv_ep->enqueue) { + *trb = *link_trb; + trace_cdns3_prepare_trb(priv_ep, trb); + + cdns3_ep_inc_enq(priv_ep); + trb = priv_ep->trb_pool + priv_ep->enqueue; + priv_req->trb = trb; + } + } + } + + if (num_trb > priv_ep->free_trbs) { + priv_ep->flags |= EP_RING_FULL; + return -ENOBUFS; } if (priv_dev->dev_ver <= DEV_VER_V2) togle_pcs = cdns3_wa1_update_guard(priv_ep, trb); - if (sg_supported) - s = request->sg; - /* set incorrect Cycle Bit for first trb*/ control = priv_ep->pcs ? 0 : TRB_CYCLE; trb->length = 0; @@ -1210,6 +1226,9 @@ static int cdns3_ep_run_transfer(struct cdns3_endpoint *priv_ep, do { u32 length; + if (!(sg_iter % num_trb_req) && sg_supported) + s = request->sg; + /* fill TRB */ control |= TRB_TYPE(TRB_NORMAL); if (sg_supported) { @@ -1251,7 +1270,7 @@ static int cdns3_ep_run_transfer(struct cdns3_endpoint *priv_ep, if (sg_supported) { trb->control |= cpu_to_le32(TRB_ISP); /* Don't set chain bit for last TRB */ - if (sg_iter < num_trb - 1) + if ((sg_iter % num_trb_req) < num_trb_req - 1) trb->control |= cpu_to_le32(TRB_CHAIN); s = sg_next(s); @@ -1509,6 +1528,12 @@ static void cdns3_transfer_completed(struct cdns3_device *priv_dev, /* The TRB was changed as link TRB, and the request was handled at ep_dequeue */ while (TRB_FIELD_TO_TYPE(le32_to_cpu(trb->control)) == TRB_LINK) { + + /* ISO ep_traddr may stop at LINK TRB */ + if (priv_ep->dequeue == cdns3_get_dma_pos(priv_dev, priv_ep) && + priv_ep->type == USB_ENDPOINT_XFER_ISOC) + break; + trace_cdns3_complete_trb(priv_ep, trb); cdns3_ep_inc_deq(priv_ep); trb = priv_ep->trb_pool + priv_ep->dequeue; @@ -1541,6 +1566,10 @@ static void cdns3_transfer_completed(struct cdns3_device *priv_dev, } if (request_handled) { + /* TRBs are duplicated by priv_ep->interval time for ISO IN */ + if (priv_ep->type == USB_ENDPOINT_XFER_ISOC && priv_ep->dir) + request->actual /= priv_ep->interval; + cdns3_gadget_giveback(priv_ep, priv_req, 0); request_handled = false; transfer_end = false; -- 2.43.0

1 year, 1 month

1
0
0 0

patch "usb: dwc: ep0: Update request status in dwc3_ep0_stall_restart" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc: ep0: Update request status in dwc3_ep0_stall_restart to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. From e9d40b215e38480fd94c66b06d79045717a59e9c Mon Sep 17 00:00:00 2001 From: Uttkarsh Aggarwal <quic_uaggarwa(a)quicinc.com> Date: Fri, 22 Dec 2023 15:17:04 +0530 Subject: usb: dwc: ep0: Update request status in dwc3_ep0_stall_restart Current implementation blocks the running operations when Plug-out and Plug-In is performed continuously, process gets stuck in dwc3_thread_interrupt(). Code Flow: CPU1 ->Gadget_start ->dwc3_interrupt ->dwc3_thread_interrupt ->dwc3_process_event_buf ->dwc3_process_event_entry ->dwc3_endpoint_interrupt ->dwc3_ep0_interrupt ->dwc3_ep0_inspect_setup ->dwc3_ep0_stall_and_restart By this time if pending_list is not empty, it will get the next request on the given list and calls dwc3_gadget_giveback which will unmap request and call its complete() callback to notify upper layers that it has completed. Currently dwc3_gadget_giveback status is set to -ECONNRESET, whereas it should be -ESHUTDOWN based on condition if not dwc->connected is true. Cc: <stable(a)vger.kernel.org> Fixes: d742220b3577 ("usb: dwc3: ep0: giveback requests on stall_and_restart") Signed-off-by: Uttkarsh Aggarwal <quic_uaggarwa(a)quicinc.com> Link: https://lore.kernel.org/r/20231222094704.20276-1-quic_uaggarwa@quicinc.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc3/ep0.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c index b94243237293..6ae8a36f21cf 100644 --- a/drivers/usb/dwc3/ep0.c +++ b/drivers/usb/dwc3/ep0.c @@ -238,7 +238,10 @@ void dwc3_ep0_stall_and_restart(struct dwc3 *dwc) struct dwc3_request *req; req = next_request(&dep->pending_list); - dwc3_gadget_giveback(dep, req, -ECONNRESET); + if (!dwc->connected) + dwc3_gadget_giveback(dep, req, -ESHUTDOWN); + else + dwc3_gadget_giveback(dep, req, -ECONNRESET); } dwc->eps[0]->trb_enqueue = 0; -- 2.43.0

1 year, 1 month

1
0
0 0

[PATCH v3 4/8] ext4: avoid bb_free and bb_fragments inconsistency in mb_free_blocks()

by Baokun Li

After updating bb_free in mb_free_blocks, it is possible to return without updating bb_fragments because the block being freed is found to have already been freed, which leads to inconsistency between bb_free and bb_fragments. Since the group may be unlocked in ext4_grp_locked_error(), this can lead to problems such as dividing by zero when calculating the average fragment length. Hence move the update of bb_free to after the block double-free check guarantees that the corresponding statistics are updated only after the core block bitmap is modified. Fixes: eabe0444df90 ("ext4: speed-up releasing blocks on commit") CC: stable(a)vger.kernel.org # 3.10 Suggested-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> --- fs/ext4/mballoc.c | 39 +++++++++++++++++++++------------------ 1 file changed, 21 insertions(+), 18 deletions(-) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index f6131ba514c8..7e08b1c4713a 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -1910,11 +1910,6 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b, mb_check_buddy(e4b); mb_free_blocks_double(inode, e4b, first, count); - this_cpu_inc(discard_pa_seq); - e4b->bd_info->bb_free += count; - if (first < e4b->bd_info->bb_first_free) - e4b->bd_info->bb_first_free = first; - /* access memory sequentially: check left neighbour, * clear range and then check right neighbour */ @@ -1928,23 +1923,31 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b, struct ext4_sb_info *sbi = EXT4_SB(sb); ext4_fsblk_t blocknr; + /* + * Fastcommit replay can free already freed blocks which + * corrupts allocation info. Regenerate it. + */ + if (sbi->s_mount_state & EXT4_FC_REPLAY) { + mb_regenerate_buddy(e4b); + goto check; + } + blocknr = ext4_group_first_block_no(sb, e4b->bd_group); blocknr += EXT4_C2B(sbi, block); - if (!(sbi->s_mount_state & EXT4_FC_REPLAY)) { - ext4_grp_locked_error(sb, e4b->bd_group, - inode ? inode->i_ino : 0, - blocknr, - "freeing already freed block (bit %u); block bitmap corrupt.", - block); - ext4_mark_group_bitmap_corrupted( - sb, e4b->bd_group, + ext4_grp_locked_error(sb, e4b->bd_group, + inode ? inode->i_ino : 0, blocknr, + "freeing already freed block (bit %u); block bitmap corrupt.", + block); + ext4_mark_group_bitmap_corrupted(sb, e4b->bd_group, EXT4_GROUP_INFO_BBITMAP_CORRUPT); - } else { - mb_regenerate_buddy(e4b); - } - goto done; + return; } + this_cpu_inc(discard_pa_seq); + e4b->bd_info->bb_free += count; + if (first < e4b->bd_info->bb_first_free) + e4b->bd_info->bb_first_free = first; + /* let's maintain fragments counter */ if (left_is_free && right_is_free) e4b->bd_info->bb_fragments--; @@ -1969,9 +1972,9 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b, if (first <= last) mb_buddy_mark_free(e4b, first >> 1, last >> 1); -done: mb_set_largest_free_order(sb, e4b->bd_info); mb_update_avg_fragment_size(sb, e4b->bd_info); +check: mb_check_buddy(e4b); } -- 2.31.1

1 year, 1 month

1
0
0 0

[PATCH v3 1/8] ext4: fix double-free of blocks due to wrong extents moved_len

by Baokun Li

In ext4_move_extents(), moved_len is only updated when all moves are successfully executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so it does not discard the preallocations. If the moved extents overlap with the preallocated extents, the overlapped extents are freed twice in ext4_mb_release_inode_pa() and ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is incremented twice. Hence when trim is executed, a zero-division bug is triggered in mb_update_avg_fragment_size() because bb_free is not zero and bb_fragments is zero. Therefore, update move_len after each extent move to avoid the issue. Reported-by: Wei Chen <harperchen1110(a)gmail.com> Reported-by: xingwei lee <xrivendell7(a)gmail.com> Closes: https://lore.kernel.org/r/CAO4mrferzqBUnCag8R3m2zf897ts9UEuhjFQGPtODT92rYyR… Fixes: fcf6b1b729bc ("ext4: refactor ext4_move_extents code base") CC: stable(a)vger.kernel.org # 3.18 Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Reviewed-by: Jan Kara <jack(a)suse.cz> --- fs/ext4/move_extent.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/ext4/move_extent.c b/fs/ext4/move_extent.c index 3aa57376d9c2..391efa6d4c56 100644 --- a/fs/ext4/move_extent.c +++ b/fs/ext4/move_extent.c @@ -618,6 +618,7 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk, goto out; o_end = o_start + len; + *moved_len = 0; while (o_start < o_end) { struct ext4_extent *ex; ext4_lblk_t cur_blk, next_blk; @@ -672,7 +673,7 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk, */ ext4_double_up_write_data_sem(orig_inode, donor_inode); /* Swap original branches with new branches */ - move_extent_per_page(o_filp, donor_inode, + *moved_len += move_extent_per_page(o_filp, donor_inode, orig_page_index, donor_page_index, offset_in_page, cur_len, unwritten, &ret); @@ -682,9 +683,6 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk, o_start += cur_len; d_start += cur_len; } - *moved_len = o_start - orig_blk; - if (*moved_len > len) - *moved_len = len; out: if (*moved_len) { -- 2.31.1

1 year, 1 month

1
0
0 0

[PATCH v3] media: ucvideo: Add quirk for Logitech Rally Bar

by Ricardo Ribalda

Logitech Rally Bar devices, despite behaving as UVC cameras, have a different power management system that the other cameras from Logitech. USB_QUIRK_RESET_RESUME is applied to all the UVC cameras from Logitech at the usb core. Unfortunately, USB_QUIRK_RESET_RESUME causes undesired USB disconnects, that make them completely unusable. Instead of creating a list for this family of devices in the core, let's create a quirk in the UVC driver. Fixes: e387ef5c47dd ("usb: Add USB_QUIRK_RESET_RESUME for all Logitech UVC webcams") Cc: stable(a)vger.kernel.org Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Alan Stern <stern(a)rowland.harvard.edu> Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Tested with a Rallybar Mini with an Acer Chromebook Spin 513 --- Changes in v3: - Move quirk to uvc driver - Link to v2: https://lore.kernel.org/r/20231222-rallybar-v2-1-5849d62a9514@chromium.org Changes in v2: - Add Fixes tag - Add UVC maintainer as Cc - Link to v1: https://lore.kernel.org/r/20231222-rallybar-v1-1-82b2a4d3106f@chromium.org --- drivers/media/usb/uvc/uvc_driver.c | 21 +++++++++++++++++++++ drivers/media/usb/uvc/uvcvideo.h | 1 + 2 files changed, 22 insertions(+) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index 08fcd2ffa727..77c1932c29ca 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -14,6 +14,7 @@ #include <linux/module.h> #include <linux/slab.h> #include <linux/usb.h> +#include <linux/usb/quirks.h> #include <linux/usb/uvc.h> #include <linux/videodev2.h> #include <linux/vmalloc.h> @@ -2233,6 +2234,8 @@ static int uvc_probe(struct usb_interface *intf, } uvc_dbg(dev, PROBE, "UVC device initialized\n"); + if (dev->quirks & UVC_QUIRK_FORCE_RESUME) + udev->quirks &= ~USB_QUIRK_RESET_RESUME; usb_enable_autosuspend(udev); return 0; @@ -2574,6 +2577,24 @@ static const struct usb_device_id uvc_ids[] = { .bInterfaceSubClass = 1, .bInterfaceProtocol = 0, .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_RESTORE_CTRLS_ON_INIT) }, + /* Logitech Rally Bar */ + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE + | USB_DEVICE_ID_MATCH_INT_INFO, + .idVendor = 0x046d, + .idProduct = 0x089b, + .bInterfaceClass = USB_CLASS_VIDEO, + .bInterfaceSubClass = 1, + .bInterfaceProtocol = 0, + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_FORCE_RESUME) }, + /* Logitech Rally Bar */ + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE + | USB_DEVICE_ID_MATCH_INT_INFO, + .idVendor = 0x046d, + .idProduct = 0x08d3, + .bInterfaceClass = USB_CLASS_VIDEO, + .bInterfaceSubClass = 1, + .bInterfaceProtocol = 0, + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_FORCE_RESUME) }, /* Chicony CNF7129 (Asus EEE 100HE) */ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO, diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h index 6fb0a78b1b00..fa59a21d2a28 100644 --- a/drivers/media/usb/uvc/uvcvideo.h +++ b/drivers/media/usb/uvc/uvcvideo.h @@ -73,6 +73,7 @@ #define UVC_QUIRK_FORCE_Y8 0x00000800 #define UVC_QUIRK_FORCE_BPP 0x00001000 #define UVC_QUIRK_WAKE_AUTOSUSPEND 0x00002000 +#define UVC_QUIRK_FORCE_RESUME 0x00004000 /* Format flags */ #define UVC_FMT_FLAG_COMPRESSED 0x00000001 --- base-commit: c0f65a7c112b3cfa691cead54bcf24d6cc2182b5 change-id: 20231222-rallybar-19ce0c64d5e6 Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

1 year, 1 month

2
1
0 0

Re: [PATCH] drm/amd/display: Fix sending VSC (+ colorimetry) packets for DP/eDP displays without PSR

by Hamza Mahfooz

On 1/3/24 14:17, Joshua Ashton wrote: > Thanks! Is it possible for us to get this backported too? Sure thing. Cc: stable(a)vger.kernel.org > > I forgot to add a Fixes: tag to this commit. It should be > > Fixes: 15f9dfd545a1 ("drm/amd/display: Register Colorspace property for > DP and HDMI") > > - Joshie 🐸✨ > > On 1/3/24 14:35, Hamza Mahfooz wrote: >> On 1/1/24 13:28, Joshua Ashton wrote: >>> The check for sending the vsc infopacket to the display was gated behind >>> PSR (Panel Self Refresh) being enabled. >>> >>> The vsc infopacket also contains the colorimetry (specifically the >>> container color gamut) information for the stream on modern DP. >>> >>> PSR is typically only supported on mobile phone eDP displays, thus this >>> was not getting sent for typical desktop monitors or TV screens. >>> >>> This functionality is needed for proper HDR10 functionality on DP as it >>> wants BT2020 RGB/YCbCr for the container color space. >>> >>> Signed-off-by: Joshua Ashton <joshua(a)froggi.es> >>> >>> Cc: Harry Wentland <harry.wentland(a)amd.com> >>> Cc: Xaver Hugl <xaver.hugl(a)gmail.com> >>> Cc: Melissa Wen <mwen(a)igalia.com> >> >> Applied, thanks! >> >>> --- >>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 +++++--- >>> .../amd/display/modules/info_packet/info_packet.c | 13 ++++++++----- >>> 2 files changed, 13 insertions(+), 8 deletions(-) >>> >>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c >>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c >>> index 2845c884398e..6dff56408bf4 100644 >>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c >>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c >>> @@ -6233,8 +6233,9 @@ create_stream_for_sink(struct drm_connector >>> *connector, >>> if (stream->signal == SIGNAL_TYPE_HDMI_TYPE_A) >>> mod_build_hf_vsif_infopacket(stream, &stream->vsp_infopacket); >>> - >>> - if (stream->link->psr_settings.psr_feature_enabled || >>> stream->link->replay_settings.replay_feature_enabled) { >>> + else if (stream->signal == SIGNAL_TYPE_DISPLAY_PORT || >>> + stream->signal == SIGNAL_TYPE_DISPLAY_PORT_MST || >>> + stream->signal == SIGNAL_TYPE_EDP) { >>> // >>> // should decide stream support vsc sdp colorimetry capability >>> // before building vsc info packet >>> @@ -6250,8 +6251,9 @@ create_stream_for_sink(struct drm_connector >>> *connector, >>> if (stream->out_transfer_func->tf == >>> TRANSFER_FUNCTION_GAMMA22) >>> tf = TRANSFER_FUNC_GAMMA_22; >>> mod_build_vsc_infopacket(stream, &stream->vsc_infopacket, >>> stream->output_color_space, tf); >>> - aconnector->psr_skip_count = AMDGPU_DM_PSR_ENTRY_DELAY; >>> + if (stream->link->psr_settings.psr_feature_enabled) >>> + aconnector->psr_skip_count = AMDGPU_DM_PSR_ENTRY_DELAY; >>> } >>> finish: >>> dc_sink_release(sink); >>> diff --git >>> a/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c >>> b/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c >>> index 84f9b412a4f1..738ee763f24a 100644 >>> --- a/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c >>> +++ b/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c >>> @@ -147,12 +147,15 @@ void mod_build_vsc_infopacket(const struct >>> dc_stream_state *stream, >>> } >>> /* VSC packet set to 4 for PSR-SU, or 2 for PSR1 */ >>> - if (stream->link->psr_settings.psr_version == DC_PSR_VERSION_SU_1) >>> - vsc_packet_revision = vsc_packet_rev4; >>> - else if (stream->link->replay_settings.config.replay_supported) >>> + if (stream->link->psr_settings.psr_feature_enabled) { >>> + if (stream->link->psr_settings.psr_version == >>> DC_PSR_VERSION_SU_1) >>> + vsc_packet_revision = vsc_packet_rev4; >>> + else if (stream->link->psr_settings.psr_version == >>> DC_PSR_VERSION_1) >>> + vsc_packet_revision = vsc_packet_rev2; >>> + } >>> + >>> + if (stream->link->replay_settings.config.replay_supported) >>> vsc_packet_revision = vsc_packet_rev4; >>> - else if (stream->link->psr_settings.psr_version == >>> DC_PSR_VERSION_1) >>> - vsc_packet_revision = vsc_packet_rev2; >>> /* Update to revision 5 for extended colorimetry support */ >>> if (stream->use_vsc_sdp_for_colorimetry) > -- Hamza

1 year, 1 month

2
1
0 0

[PATCH v2] firewire: ohci: suppress unexpected system reboot in AMD Ryzen machines and ASM108x/VT630x PCIe cards

by Takashi Sakamoto

VIA VT6306/6307/6308 provides PCI interface compliant to 1394 OHCI. When the hardware is combined with Asmedia ASM1083/1085 PCIe-to-PCI bus bridge, it appears that accesses to its 'Isochronous Cycle Timer' register (offset 0xf0 on PCI I/O space) often causes unexpected system reboot in any type of AMD Ryzen machine (both 0x17 and 0x19 families). It does not appears in the other type of machine (AMD pre-Ryzen machine, Intel machine, at least), or in the other OHCI 1394 hardware (e.g. Texas Instruments). The issue explicitly appears at a commit dcadfd7f7c74 ("firewire: core: use union for callback of transaction completion") added to v6.5 kernel. It changed 1394 OHCI driver to access to the register every time to dispatch local asynchronous transaction. However, the issue exists in older version of kernel as long as it runs in AMD Ryzen machine, since the access to the register is required to maintain bus time. It is not hard to imagine that users experience the unexpected system reboot when generating bus reset by plugging any devices in, or reading the register by time-aware application programs; e.g. audio sample processing. This commit suppresses the unexpected system reboot in the combination of hardware. It avoids the access itself. As a result, the software stack can not provide the hardware time anymore to unit drivers, userspace applications, and nodes in the same IEEE 1394 bus. It brings apparent disadvantage since time-aware application programs require it, while time-unaware applications are available again; e.g. sbp2. Cc: stable(a)vger.kernel.org Reported-by: Jiri Slaby <jirislaby(a)kernel.org> Closes: https://bugzilla.suse.com/show_bug.cgi?id=1215436 Reported-by: Mario Limonciello <mario.limonciello(a)amd.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217994 Reported-by: Tobias Gruetzmacher <tobias-lists(a)23.gs> Closes: https://sourceforge.net/p/linux1394/mailman/message/58711901/ Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2240973 Closes: https://bugs.launchpad.net/linux/+bug/2043905 Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- drivers/firewire/ohci.c | 51 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/drivers/firewire/ohci.c b/drivers/firewire/ohci.c index 7e88fd489741..9db9290c3269 100644 --- a/drivers/firewire/ohci.c +++ b/drivers/firewire/ohci.c @@ -279,6 +279,51 @@ static char ohci_driver_name[] = KBUILD_MODNAME; #define QUIRK_TI_SLLZ059 0x20 #define QUIRK_IR_WAKE 0x40 +// On PCI Express Root Complex in any type of AMD Ryzen machine, VIA VT6306/6307/6308 with Asmedia +// ASM1083/1085 brings an inconvenience that the read accesses to 'Isochronous Cycle Timer' register +// (at offset 0xf0 in PCI I/O space) often causes unexpected system reboot. The mechanism is not +// clear, since the read access to the other registers is enough safe; e.g. 'Node ID' register, +// while it is probable due to detection of any type of PCIe error. +#define QUIRK_REBOOT_BY_CYCLE_TIMER_READ 0x80000000 + +#if IS_ENABLED(CONFIG_X86) + +static bool has_reboot_by_cycle_timer_read_quirk(const struct fw_ohci *ohci) +{ + return !!(ohci->quirks & QUIRK_REBOOT_BY_CYCLE_TIMER_READ); +} + +#define PCI_DEVICE_ID_ASMEDIA_ASM108X 0x1080 + +static bool detect_vt630x_with_asm1083_on_amd_ryzen_machine(const struct pci_dev *pdev) +{ + const struct pci_dev *pcie_to_pci_bridge; + + // Detect any type of AMD Ryzen machine. + if (!static_cpu_has(X86_FEATURE_ZEN)) + return false; + + // Detect VIA VT6306/6307/6308. + if (pdev->vendor != PCI_VENDOR_ID_VIA) + return false; + if (pdev->device != PCI_DEVICE_ID_VIA_VT630X) + return false; + + // Detect Asmedia ASM1083/1085. + pcie_to_pci_bridge = pdev->bus->self; + if (pcie_to_pci_bridge->vendor != PCI_VENDOR_ID_ASMEDIA) + return false; + if (pcie_to_pci_bridge->device != PCI_DEVICE_ID_ASMEDIA_ASM108X) + return false; + + return true; +} + +#else +#define has_reboot_by_cycle_timer_read_quirk(ohci) false +#define detect_vt630x_with_asm1083_on_amd_ryzen_machine(pdev) false +#endif + /* In case of multiple matches in ohci_quirks[], only the first one is used. */ static const struct { unsigned short vendor, device, revision, flags; @@ -1724,6 +1769,9 @@ static u32 get_cycle_time(struct fw_ohci *ohci) s32 diff01, diff12; int i; + if (has_reboot_by_cycle_timer_read_quirk(ohci)) + return 0; + c2 = reg_read(ohci, OHCI1394_IsochronousCycleTimer); if (ohci->quirks & QUIRK_CYCLE_TIMER) { @@ -3630,6 +3678,9 @@ static int pci_probe(struct pci_dev *dev, if (param_quirks) ohci->quirks = param_quirks; + if (detect_vt630x_with_asm1083_on_amd_ryzen_machine(dev)) + ohci->quirks |= QUIRK_REBOOT_BY_CYCLE_TIMER_READ; + /* * Because dma_alloc_coherent() allocates at least one page, * we save space by using a common buffer for the AR request/ -- 2.40.1

1 year, 1 month

1
1
0 0

[PATCH v2 4/8] ext4: avoid bb_free and bb_fragments inconsistency in mb_free_blocks()

by Baokun Li

After updating bb_free in mb_free_blocks, it is possible to return without updating bb_fragments because the block being freed is found to have already been freed, which leads to inconsistency between bb_free and bb_fragments. Since the group may be unlocked in ext4_grp_locked_error(), this can lead to problems such as dividing by zero when calculating the average fragment length. Hence move the update of bb_free to after the block double-free check guarantees that the corresponding statistics are updated only after the core block bitmap is modified. Fixes: eabe0444df90 ("ext4: speed-up releasing blocks on commit") CC: stable(a)vger.kernel.org # 3.10 Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/ext4/mballoc.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c index f6131ba514c8..1f15774971d7 100644 --- a/fs/ext4/mballoc.c +++ b/fs/ext4/mballoc.c @@ -1910,11 +1910,6 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b, mb_check_buddy(e4b); mb_free_blocks_double(inode, e4b, first, count); - this_cpu_inc(discard_pa_seq); - e4b->bd_info->bb_free += count; - if (first < e4b->bd_info->bb_first_free) - e4b->bd_info->bb_first_free = first; - /* access memory sequentially: check left neighbour, * clear range and then check right neighbour */ @@ -1941,10 +1936,16 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b, EXT4_GROUP_INFO_BBITMAP_CORRUPT); } else { mb_regenerate_buddy(e4b); + goto check; } - goto done; + return; } + this_cpu_inc(discard_pa_seq); + e4b->bd_info->bb_free += count; + if (first < e4b->bd_info->bb_first_free) + e4b->bd_info->bb_first_free = first; + /* let's maintain fragments counter */ if (left_is_free && right_is_free) e4b->bd_info->bb_fragments--; @@ -1969,9 +1970,9 @@ static void mb_free_blocks(struct inode *inode, struct ext4_buddy *e4b, if (first <= last) mb_buddy_mark_free(e4b, first >> 1, last >> 1); -done: mb_set_largest_free_order(sb, e4b->bd_info); mb_update_avg_fragment_size(sb, e4b->bd_info); +check: mb_check_buddy(e4b); } -- 2.31.1

1 year, 1 month

2
2
0 0

[PATCH v2 1/8] ext4: fix double-free of blocks due to wrong extents moved_len

by Baokun Li

In ext4_move_extents(), moved_len is only updated when all moves are successfully executed, and only discards orig_inode and donor_inode preallocations when moved_len is not zero. When the loop fails to exit after successfully moving some extents, moved_len is not updated and remains at 0, so it does not discard the preallocations. If the moved extents overlap with the preallocated extents, the overlapped extents are freed twice in ext4_mb_release_inode_pa() and ext4_process_freed_data() (as described in commit 94d7c16cbbbd ("ext4: Fix double-free of blocks with EXT4_IOC_MOVE_EXT")), and bb_free is incremented twice. Hence when trim is executed, a zero-division bug is triggered in mb_update_avg_fragment_size() because bb_free is not zero and bb_fragments is zero. Therefore, update move_len after each extent move to avoid the issue. Reported-by: Wei Chen <harperchen1110(a)gmail.com> Reported-by: xingwei lee <xrivendell7(a)gmail.com> Closes: https://lore.kernel.org/r/CAO4mrferzqBUnCag8R3m2zf897ts9UEuhjFQGPtODT92rYyR… Fixes: fcf6b1b729bc ("ext4: refactor ext4_move_extents code base") CC: stable(a)vger.kernel.org # 3.18 Signed-off-by: Baokun Li <libaokun1(a)huawei.com> --- fs/ext4/move_extent.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/fs/ext4/move_extent.c b/fs/ext4/move_extent.c index 3aa57376d9c2..391efa6d4c56 100644 --- a/fs/ext4/move_extent.c +++ b/fs/ext4/move_extent.c @@ -618,6 +618,7 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk, goto out; o_end = o_start + len; + *moved_len = 0; while (o_start < o_end) { struct ext4_extent *ex; ext4_lblk_t cur_blk, next_blk; @@ -672,7 +673,7 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk, */ ext4_double_up_write_data_sem(orig_inode, donor_inode); /* Swap original branches with new branches */ - move_extent_per_page(o_filp, donor_inode, + *moved_len += move_extent_per_page(o_filp, donor_inode, orig_page_index, donor_page_index, offset_in_page, cur_len, unwritten, &ret); @@ -682,9 +683,6 @@ ext4_move_extents(struct file *o_filp, struct file *d_filp, __u64 orig_blk, o_start += cur_len; d_start += cur_len; } - *moved_len = o_start - orig_blk; - if (*moved_len > len) - *moved_len = len; out: if (*moved_len) { -- 2.31.1

1 year, 1 month

2
1
0 0

[PATCH v5 RESEND 0/5] Regather scattered PCI-Code

by Philipp Stanner

@Stable-Kernel: You receive this patch series because its first patch fixes leaks in PCI. Changes in v5: - Add forgotten update to MAINTAINERS file. Changes in v4: - Apply Arnd's Reviewed-by's - Add ifdef CONFIG_HAS_IOPORT_MAP guard in drivers/pci/iomap.c (build error on openrisc) - Fix typo in patch no.5 Changes in v3: - Create a separate patch for the leaks in lib/iomap.c. Make it the series' first patch. (Arnd) - Turns out the aforementioned bug wasn't just accidentally removing iounmap() with the ifdef, it was also missing ioport_unmap() to begin with. Add it. - Move the ARCH_WANTS_GENERIC_IOMEM_IS_IOPORT-mechanism from asm-generic/io.h to asm-generic/ioport.h. (Arnd) - Adjust the implementation of iomem_is_ioport() in asm-generic/io.h so that it matches exactly what pci_iounmap() previously did in lib/pci_iomap.c. (Arnd) - Move the CONFIG_HAS_IOPORT guard in asm-generic/io.h so that iomem_is_ioport() will always be compiled and just returns false if there are no ports. - Add TODOs to several places informing about the generic iomem_is_ioport() in lib/iomap.c not being generic. - Add TODO about the followup work to make drivers/pci/iomap.c's pci_iounmap() actually generic. Changes in v2: - Replace patch 4, previously extending the comment about pci_iounmap() in lib/iomap.c, with a patch that moves pci_iounmap() from that file to drivers/pci/iomap.c, creating a unified version there. (Arnd) - Implement iomem_is_ioport() as a new helper in asm-generic/io.h and lib/iomap.c. (Arnd) - Move the build rule in drivers/pci/Makefile for iomap.o under the guard of #if PCI. This had to be done because when just checking for GENERIC_PCI_IOMAP being defined, the functions don't disappear, which was the case previously in lib/pci_iomap.c, where the entire file was made empty if PCI was not set by the guard #ifdef PCI. (Intel's Bots) - Rephares all patches' commit messages a little bit. Sooooooooo. I reworked v1. Please review this carefully, the IO-Ranges are obviously a bit tricky, as is the build-system / ifdef-ery. Arnd has suggested that architectures defining a custom inb() need their own iomem_is_ioport(), as well. I've grepped for inb() and found the following list of archs that define their own: - alpha - arm - m68k <-- - parisc - powerpc - sh - sparc - x86 <-- All of those have their own definitons of pci_iounmap(). Therefore, they don't need our generic version in the first place and, thus, also need no iomem_is_ioport(). The two exceptions are x86 and m68k. The former uses lib/iomap.c through CONFIG_GENERIC_IOMAP, as Arnd pointed out in the previous discussion (thus, CONFIG_GENERIC_IOMAP is not really generic in this regard). So as I see it, only m68k WOULD need its own custom definition of iomem_is_ioport(). But as I understand it it doesn't because it uses the one from asm-generic/pci_iomap.h ?? I wasn't entirely sure how to deal with the address ranges for the generic implementation in asm-generic/io.h. It's marked with a TODO. Input appreciated. I removed the guard around define pci_iounmap in asm-generic/io.h. An alternative would be to have it be guarded by CONFIG_GENERIC_IOMAP and CONFIG_GENERIC_PCI_IOMAP, both. Without such a guard, there is no collision however, because generic pci_iounmap() from drivers/pci/iomap.c will only get pulled in when CONFIG_GENERIC_PCI_IOMAP is actually set. I cross-built this for a variety of architectures, including the usual suspects (s390, m68k). So far successfully. But let's see what Intel's robots say :O P. Original cover letter: Hi! So it seems that since ca. 2007 the PCI code has been scattered a bit. PCI's devres code, which is only ever used by users of the entire PCI-subsystem anyways, resides in lib/devres.c and is guarded by an ifdef PCI, just as the content of lib/pci_iomap.c is. It, thus, seems reasonable to move all of that. As I were at it, I moved as much of the devres-specific code from pci.c to devres.c, too. The only exceptions are four functions that are currently difficult to move. More information about that can be read here [1]. I noticed these scattered files while working on (new) PCI-specific devres functions. If we can get this here merged, I'll soon send another patch series that addresses some API-inconsistencies and could move the devres-part of the four remaining functions. I don't want to do that in this series as this here is only about moving code, whereas the next series would have to actually change API behavior. I successfully (cross-)built this for x86, x86_64, AARCH64 and ARM (allyesconfig). I booted a kernel with it on x86_64, with a Fedora desktop environment as payload. The OS came up fine I hope this is OK. If we can get it in, we'd soon have a very consistent PCI API again. Regards, P. Philipp Stanner (5): lib/pci_iomap.c: fix cleanup bugs in pci_iounmap() lib: move pci_iomap.c to drivers/pci/ lib: move pci-specific devres code to drivers/pci/ pci: move devres code from pci.c to devres.c lib, pci: unify generic pci_iounmap() MAINTAINERS | 1 - drivers/pci/Kconfig | 5 + drivers/pci/Makefile | 3 +- drivers/pci/devres.c | 450 +++++++++++++++++++++++++ lib/pci_iomap.c => drivers/pci/iomap.c | 49 +-- drivers/pci/pci.c | 249 -------------- drivers/pci/pci.h | 24 ++ include/asm-generic/io.h | 27 +- include/asm-generic/iomap.h | 21 ++ lib/Kconfig | 3 - lib/Makefile | 1 - lib/devres.c | 208 +----------- lib/iomap.c | 28 +- 13 files changed, 566 insertions(+), 503 deletions(-) create mode 100644 drivers/pci/devres.c rename lib/pci_iomap.c => drivers/pci/iomap.c (75%) -- 2.43.0

1 year, 1 month

2
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2024