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

[PATCH v4 4/5] scsi: fnic: Turn off FDMI ACTIVE flags on link down

by Karan Tilak Kumar

When the link goes down and comes up, FDMI requests are not sent out anymore. Fix bug by turning off FNIC_FDMI_ACTIVE when the link goes down. Fixes: 09c1e6ab4ab2 ("scsi: fnic: Add and integrate support for FDMI") Reviewed-by: Sesidhar Baddela <sebaddel(a)cisco.com> Reviewed-by: Arulprabhu Ponnusamy <arulponn(a)cisco.com> Reviewed-by: Gian Carlo Boffa <gcboffa(a)cisco.com> Reviewed-by: Arun Easi <aeasi(a)cisco.com> Tested-by: Karan Tilak Kumar <kartilak(a)cisco.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Karan Tilak Kumar <kartilak(a)cisco.com> --- Changes between v3 and v4: - Incorporate review comments from Dan: - Remove comments from Cc tag Changes between v2 and v3: - Incorporate review comments from Dan: - Add Cc to stable Changes between v1 and v2: - Incorporate review comments from Dan: - Add Fixes tag --- drivers/scsi/fnic/fdls_disc.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/fnic/fdls_disc.c b/drivers/scsi/fnic/fdls_disc.c index 9e9939d41fa8..14691db4d5f9 100644 --- a/drivers/scsi/fnic/fdls_disc.c +++ b/drivers/scsi/fnic/fdls_disc.c @@ -5078,9 +5078,12 @@ void fnic_fdls_link_down(struct fnic_iport_s *iport) fdls_delete_tport(iport, tport); } - if ((fnic_fdmi_support == 1) && (iport->fabric.fdmi_pending > 0)) { - timer_delete_sync(&iport->fabric.fdmi_timer); - iport->fabric.fdmi_pending = 0; + if (fnic_fdmi_support == 1) { + if (iport->fabric.fdmi_pending > 0) { + timer_delete_sync(&iport->fabric.fdmi_timer); + iport->fabric.fdmi_pending = 0; + } + iport->flags &= ~FNIC_FDMI_ACTIVE; } FNIC_FCS_DBG(KERN_INFO, fnic->host, fnic->fnic_num, -- 2.47.1

3 months

3
4
0 0

Design Automation Conference 2025 Updated Attendee's List!

by Delilah Murray

Hi, We’re pleased to offer you exclusive access to the “Design Automation Conference 2025” Visitor Contact List—a powerful resource to connect directly with key industry professionals. Event Recap:- Date: 22 - 25 Jun 2025 Location: San Francisco, USA Registrants Counts: 6,286 Visitors Contacts Data Fields Available: Individual Email Address, Cell Phone Number, Contact Name, Job Title, Company Name, Website, Physical Address, LinkedIn Profile, and more. This list gives you a direct line to your ideal audience—no gatekeepers, no guesswork. Want pricing or a sample? Just reply: “Send me pricing” or “Sample please.” Best regards, Delilah Murray Sr. Marketing Manager Prefer not to receive these emails? Just reply “NOT INTERESTED”.

3 months

1
0
0 0

[PATCH 6.1] Mm/uffd: fix vma operation where start addr cuts part of vma

by Jakub Acs

commit 270aa010620697fb27b8f892cc4e194bc2b7d134 upstream. Patch series "mm/uffd: Fix vma merge/split", v2. This series contains two patches that fix vma merge/split for userfaultfd on two separate issues. Patch 1 fixes a regression since 6.1+ due to something we overlooked when converting to maple tree apis. The plan is we use patch 1 to replace the commit "2f628010799e (mm: userfaultfd: avoid passing an invalid range to vma_merge())" in mm-hostfixes-unstable tree if possible, so as to bring uffd vma operations back aligned with the rest code again. Patch 2 fixes a long standing issue that vma can be left unmerged even if we can for either uffd register or unregister. Many thanks to Lorenzo on either noticing this issue from the assert movement patch, looking at this problem, and also provided a reproducer on the unmerged vma issue [1]. [1] https://gist.github.com/lorenzo-stoakes/a11a10f5f479e7a977fc456331266e0e This patch (of 2): It seems vma merging with uffd paths is broken with either register/unregister, where right now we can feed wrong parameters to vma_merge() and it's found by recent patch which moved asserts upwards in vma_merge() by Lorenzo Stoakes: https://lore.kernel.org/all/ZFunF7DmMdK05MoF@FVFF77S0Q05N.cambridge.arm.com/ It's possible that "start" is contained within vma but not clamped to its start. We need to convert this into either "cannot merge" case or "can merge" case 4 which permits subdivision of prev by assigning vma to prev. As we loop, each subsequent VMA will be clamped to the start. This patch will eliminate the report and make sure vma_merge() calls will become legal again. One thing to mention is that the "Fixes: 29417d292bd0" below is there only to help explain where the warning can start to trigger, the real commit to fix should be 69dbe6daf104. Commit 29417d292bd0 helps us to identify the issue, but unfortunately we may want to keep it in Fixes too just to ease kernel backporters for easier tracking. Link: https://lkml.kernel.org/r/20230517190916.3429499-1-peterx@redhat.com Link: https://lkml.kernel.org/r/20230517190916.3429499-2-peterx@redhat.com Fixes: 69dbe6daf104 ("userfaultfd: use maple tree iterator to iterate VMAs") Signed-off-by: Peter Xu <peterx(a)redhat.com> Reported-by: Mark Rutland <mark.rutland(a)arm.com> Reviewed-by: Lorenzo Stoakes <lstoakes(a)gmail.com> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)oracle.com> Closes: https://lore.kernel.org/all/ZFunF7DmMdK05MoF@FVFF77S0Q05N.cambridge.arm.com/ Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> Cc: Mike Rapoport (IBM) <rppt(a)kernel.org> Cc: Liam R. Howlett <Liam.Howlett(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Jakub Acs <acsjakub(a)amazon.com> [acsjakub: contextual change - keep call to mas_next()] Cc: linux-mm(a)kvack.org --- This backport fixes a security issue - dangling pointer to a VMA in maple tree. Omitting details in this message to be brief, but happy to provide if requested. Since the envelope mentions series fixes 2 separate issues I hope the patch is acceptable on its own? fs/userfaultfd.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c index 82101a2cf933..fcf96f52b2e9 100644 --- a/fs/userfaultfd.c +++ b/fs/userfaultfd.c @@ -1426,6 +1426,9 @@ static int userfaultfd_register(struct userfaultfd_ctx *ctx, if (prev != vma) mas_next(&mas, ULONG_MAX); + if (vma->vm_start < start) + prev = vma; + ret = 0; do { cond_resched(); @@ -1603,6 +1606,9 @@ static int userfaultfd_unregister(struct userfaultfd_ctx *ctx, if (prev != vma) mas_next(&mas, ULONG_MAX); + if (vma->vm_start < start) + prev = vma; + ret = 0; do { cond_resched(); -- 2.47.1 Amazon Web Services Development Center Germany GmbH Tamara-Danz-Str. 13 10243 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B Sitz: Berlin Ust-ID: DE 365 538 597

3 months

3
2
0 0

[PATCH v7 0/4] media: pisp-be: Split jobs creation and scheduling

by Jacopo Mondi

Currently the 'pispbe_schedule()' function does two things: 1) Tries to assemble a job by inspecting all the video node queues to make sure all the required buffers are available 2) Submit the job to the hardware The pispbe_schedule() function is called at: - video device start_streaming() time - video device qbuf() time - irq handler As assembling a job requires inspecting all queues, it is a rather time consuming operation which is better not run in IRQ context. To avoid executing the time consuming job creation in interrupt context, split the job creation and job scheduling in two distinct operations. When a well-formed job is created, append it to the newly introduced 'pispbe->job_queue' where it will be dequeued from by the scheduling routine. At start_streaming() and qbuf() time immediately try to schedule a job if one has been created as the irq handler routine is only called when a job has completed, and we can't solely rely on it for scheduling new jobs. Signed-off-by: Jacopo Mondi <jacopo.mondi(a)ideasonboard.com> --- Changes in v7: - Rebased on media-committers/next - Fix lockdep warning by using the proper spinlock_irq() primitive in pispbe_prepare_job() which can race with the IRQ handler - Link to v6: https://lore.kernel.org/r/20240930-pispbe-mainline-split-jobs-handling-v6-v… v5->v6: - Make the driver depend on PM - Simplify the probe() routine by using pm_runtime_ - Remove suspend call from remove() v4->v5: - Use appropriate locking constructs: - spin_lock_irq() for pispbe_prepare_job() called from non irq context - spin_lock_irqsave() for pispbe_schedule() called from irq context - Remove hw_lock from ready_queue accesses in stop_streaming and start_streaming - Fix trivial indentation mistake in 4/4 v3->v4: - Expand commit message in 2/4 to explain why removing validation in schedule() is safe - Drop ready_lock spinlock - Use non _irqsave version of safe_guard(spinlock - Support !CONFIG_PM in 4/4 by calling the enable/disable routines directly and adjust pm_runtime usage as suggested by Laurent v2->v3: - Mark pispbe_runtime_resume() as __maybe_unused - Add fixes tags where appropriate v1->v2: - Add two patches to address Laurent's comments separately - use scoped_guard() when possible - Add patch to fix runtime_pm imbalance --- Jacopo Mondi (4): media: pisp_be: Drop reference to non-existing function media: pisp_be: Remove config validation from schedule() media: pisp_be: Split jobs creation and scheduling media: pisp_be: Fix pm_runtime underrun in probe drivers/media/platform/raspberrypi/pisp_be/Kconfig | 1 + .../media/platform/raspberrypi/pisp_be/pisp_be.c | 187 ++++++++++----------- 2 files changed, 90 insertions(+), 98 deletions(-) --- base-commit: 5e1ff2314797bf53636468a97719a8222deca9ae change-id: 20240930-pispbe-mainline-split-jobs-handling-v6-15dc16e11e3a Best regards, -- Jacopo Mondi <jacopo.mondi(a)ideasonboard.com>

3 months

2
2
0 0

[PATCH] net/9p: Fix buffer overflow in USB transport layer

by Yuhao Jiang

A buffer overflow vulnerability exists in the USB 9pfs transport layer where inconsistent size validation between packet header parsing and actual data copying allows a malicious USB host to overflow heap buffers. The issue occurs because: - usb9pfs_rx_header() validates only the declared size in packet header - usb9pfs_rx_complete() uses req->actual (actual received bytes) for memcpy This allows an attacker to craft packets with small declared size (bypassing validation) but large actual payload (triggering overflow in memcpy). Add validation in usb9pfs_rx_complete() to ensure req->actual does not exceed the buffer capacity before copying data. Reported-by: Yuhao Jiang <danisjiang(a)gmail.com> Fixes: a3be076dc174 ("net/9p/usbg: Add new usb gadget function transport") Cc: stable(a)vger.kernel.org Signed-off-by: Yuhao Jiang <danisjiang(a)gmail.com> --- net/9p/trans_usbg.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/net/9p/trans_usbg.c b/net/9p/trans_usbg.c index 6b694f117aef..047a2862fc84 100644 --- a/net/9p/trans_usbg.c +++ b/net/9p/trans_usbg.c @@ -242,6 +242,15 @@ static void usb9pfs_rx_complete(struct usb_ep *ep, struct usb_request *req) if (!p9_rx_req) return; + /* Validate actual received size against buffer capacity */ + if (req->actual > p9_rx_req->rc.capacity) { + dev_err(&cdev->gadget->dev, + "received data size %u exceeds buffer capacity %zu\n", + req->actual, p9_rx_req->rc.capacity); + p9_req_put(usb9pfs->client, p9_rx_req); + return; + } + memcpy(p9_rx_req->rc.sdata, req->buf, req->actual); p9_rx_req->rc.size = req->actual; -- 2.43.0

3 months

1
0
0 0

[PATCH v2 00/10] soc: aspeed: lpc-snoop: Miscellaneous fixes

by Andrew Jeffery

Henry's bug[1] and fix[2] prompted some further inspection by Jean. This series provides fixes for the remaining issues Jean identified, as well as reworking the channel paths to reduce cleanup required in error paths. It is based on v6.16-rc1. Lightly tested under qemu and on an AST2600 EVB. Further testing on platforms designed around the snoop device appreciated. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=219934 [2]: https://lore.kernel.org/all/20250401074647.21300-1-bsdhenrymartin@gmail.com/ Signed-off-by: Andrew Jeffery <andrew(a)codeconstruct.com.au> --- Changes in v2: - Address comments on v1 from Jean - Implement channel indexing using enums to avoid unnecessary tests - Switch to devm_clk_get_enabled() - Use dev_err_probe() where possible - Link to v1: https://patch.msgid.link/20250411-aspeed-lpc-snoop-fixes-v1-0-64f522e3ad6f@… --- Andrew Jeffery (10): soc: aspeed: lpc-snoop: Cleanup resources in stack-order soc: aspeed: lpc-snoop: Don't disable channels that aren't enabled soc: aspeed: lpc-snoop: Ensure model_data is valid soc: aspeed: lpc-snoop: Constrain parameters in channel paths soc: aspeed: lpc-snoop: Rename 'channel' to 'index' in channel paths soc: aspeed: lpc-snoop: Rearrange channel paths soc: aspeed: lpc-snoop: Switch to devm_clk_get_enabled() soc: aspeed: lpc-snoop: Use dev_err_probe() where possible soc: aspeed: lpc-snoop: Consolidate channel initialisation soc: aspeed: lpc-snoop: Lift channel config to const structs drivers/soc/aspeed/aspeed-lpc-snoop.c | 224 +++++++++++++++++----------------- 1 file changed, 110 insertions(+), 114 deletions(-) --- base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494 change-id: 20250401-aspeed-lpc-snoop-fixes-e5d2883da3a3 Best regards, -- Andrew Jeffery <andrew(a)codeconstruct.com.au>

3 months

1
2
0 0

Re: [PATCH] drm/i915/snps_hdmi_pll: Fix 64-bit divisor truncation by using div64_u64

by Jani Nikula

On Sun, 15 Jun 2025, "Nautiyal, Ankit K" <ankit.k.nautiyal(a)intel.com> wrote: > On 6/13/2025 3:06 PM, Jani Nikula wrote: >> On Fri, 13 Jun 2025, Ankit Nautiyal<ankit.k.nautiyal(a)intel.com> wrote: >>> *ana_cp_int = max(1, min(ana_cp_int_temp, 127)); >> Unrelated to this patch, but this should be: >> >> *ana_cp_int = clamp(ana_cp_int_temp, 1, 127); >> >> There's a similar issue with ana_cp_prop also in the file. >> > Agreed. Should there be a separate patch for this? Yes. That's why I emphasized "unrelated to this patch". ;) BR, Jani. -- Jani Nikula, Intel

3 months

1
0
0 0

[PATCH] fpga: zynq-fpga: use sgtable-based scatterlist wrappers

by Marek Szyprowski

Use common wrappers operating directly on the struct sg_table objects to fix incorrect use of statterlists related calls. dma_unmap_sg() function has to be called with the number of elements originally passed to the dma_map_sg() function, not the one returned in sgtable's nents. CC: stable(a)vger.kernel.org Fixes: 425902f5c8e3 ("fpga zynq: Use the scatterlist interface") Signed-off-by: Marek Szyprowski <m.szyprowski(a)samsung.com> --- drivers/fpga/zynq-fpga.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/fpga/zynq-fpga.c b/drivers/fpga/zynq-fpga.c index f7e08f7ea9ef..9bd39d1d4048 100644 --- a/drivers/fpga/zynq-fpga.c +++ b/drivers/fpga/zynq-fpga.c @@ -406,7 +406,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr, struct sg_table *sgt) } priv->dma_nelms = - dma_map_sg(mgr->dev.parent, sgt->sgl, sgt->nents, DMA_TO_DEVICE); + dma_map_sgtable(mgr->dev.parent, sgt, DMA_TO_DEVICE); if (priv->dma_nelms == 0) { dev_err(&mgr->dev, "Unable to DMA map (TO_DEVICE)\n"); return -ENOMEM; @@ -478,7 +478,7 @@ static int zynq_fpga_ops_write(struct fpga_manager *mgr, struct sg_table *sgt) clk_disable(priv->clk); out_free: - dma_unmap_sg(mgr->dev.parent, sgt->sgl, sgt->nents, DMA_TO_DEVICE); + dma_unmap_sgtable(mgr->dev.parent, sgt, DMA_TO_DEVICE); return err; } -- 2.34.1

3 months

3
3
0 0

[PATCH] wifi: mt76: mt7925: fix incorrect scan probe IE handling for hw_scan

by Mingyen Hsieh

From: Ming Yen Hsieh <mingyen.hsieh(a)mediatek.com> The IEs should be processed and filled into the command tlv separately according to each band. Cc: stable(a)vger.kernel.org Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Signed-off-by: Ming Yen Hsieh <mingyen.hsieh(a)mediatek.com> --- .../net/wireless/mediatek/mt76/mt7925/main.c | 2 +- .../net/wireless/mediatek/mt76/mt7925/mcu.c | 75 +++++++++++++++---- .../net/wireless/mediatek/mt76/mt7925/mcu.h | 5 +- 3 files changed, 63 insertions(+), 19 deletions(-) diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/main.c b/drivers/net/wireless/mediatek/mt76/mt7925/main.c index 555ef302ae97..506387b4ce13 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c @@ -1540,7 +1540,7 @@ mt7925_start_sched_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif, mt792x_mutex_acquire(dev); - err = mt7925_mcu_sched_scan_req(mphy, vif, req); + err = mt7925_mcu_sched_scan_req(mphy, vif, req, ies); if (err < 0) goto out; diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c index ef1d42af96f7..9993d47e643c 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.c @@ -192,6 +192,7 @@ mt7925_connac_mcu_set_wow_ctrl(struct mt76_phy *phy, struct ieee80211_vif *vif, bool suspend, struct cfg80211_wowlan *wowlan) { struct mt76_vif_link *mvif = (struct mt76_vif_link *)vif->drv_priv; + struct ieee80211_scan_ies ies = {}; struct mt76_dev *dev = phy->dev; struct { struct { @@ -227,7 +228,7 @@ mt7925_connac_mcu_set_wow_ctrl(struct mt76_phy *phy, struct ieee80211_vif *vif, req.wow_ctrl_tlv.trigger |= (UNI_WOW_DETECT_TYPE_DISCONNECT | UNI_WOW_DETECT_TYPE_BCN_LOST); if (wowlan->nd_config) { - mt7925_mcu_sched_scan_req(phy, vif, wowlan->nd_config); + mt7925_mcu_sched_scan_req(phy, vif, wowlan->nd_config, &ies); req.wow_ctrl_tlv.trigger |= UNI_WOW_DETECT_TYPE_SCH_SCAN_HIT; mt7925_mcu_sched_scan_enable(phy, vif, suspend); } @@ -3085,6 +3086,54 @@ int mt7925_mcu_set_dbdc(struct mt76_phy *phy, bool enable) return err; } +static void +mt7925_mcu_build_scan_ie_tlv(struct mt76_dev *mdev, + struct sk_buff *skb, + struct ieee80211_scan_ies *scan_ies) +{ + u32 max_len = sizeof(struct scan_ie_tlv) + MT76_CONNAC_SCAN_IE_LEN; + struct scan_ie_tlv *ie; + enum nl80211_band i; + struct tlv *tlv; + const u8 *ies; + u16 ies_len; + + for (i = 0; i <= NL80211_BAND_6GHZ; i++) { + if (i == NL80211_BAND_60GHZ) + continue; + + ies = scan_ies->ies[i]; + ies_len = scan_ies->len[i]; + + if (!ies || !ies_len) + continue; + + if (ies_len > max_len) + return; + + tlv = mt76_connac_mcu_add_tlv(skb, UNI_SCAN_IE, + sizeof(*ie) + ies_len); + ie = (struct scan_ie_tlv *)tlv; + + memcpy(ie->ies, ies, ies_len); + ie->ies_len = cpu_to_le16(ies_len); + + switch (i) { + case NL80211_BAND_2GHZ: + ie->band = 1; + break; + case NL80211_BAND_6GHZ: + ie->band = 3; + break; + default: + ie->band = 2; + break; + } + + max_len -= (sizeof(*ie) + ies_len); + } +} + int mt7925_mcu_hw_scan(struct mt76_phy *phy, struct ieee80211_vif *vif, struct ieee80211_scan_request *scan_req) { @@ -3110,7 +3159,8 @@ int mt7925_mcu_hw_scan(struct mt76_phy *phy, struct ieee80211_vif *vif, max_len = sizeof(*hdr) + sizeof(*req) + sizeof(*ssid) + sizeof(*bssid) * MT7925_RNR_SCAN_MAX_BSSIDS + - sizeof(*chan_info) + sizeof(*misc) + sizeof(*ie); + sizeof(*chan_info) + sizeof(*misc) + sizeof(*ie) + + MT76_CONNAC_SCAN_IE_LEN; skb = mt76_mcu_msg_alloc(mdev, NULL, max_len); if (!skb) @@ -3192,13 +3242,6 @@ int mt7925_mcu_hw_scan(struct mt76_phy *phy, struct ieee80211_vif *vif, } chan_info->channel_type = sreq->n_channels ? 4 : 0; - tlv = mt76_connac_mcu_add_tlv(skb, UNI_SCAN_IE, sizeof(*ie)); - ie = (struct scan_ie_tlv *)tlv; - if (sreq->ie_len > 0) { - memcpy(ie->ies, sreq->ie, sreq->ie_len); - ie->ies_len = cpu_to_le16(sreq->ie_len); - } - req->scan_func |= SCAN_FUNC_SPLIT_SCAN; tlv = mt76_connac_mcu_add_tlv(skb, UNI_SCAN_MISC, sizeof(*misc)); @@ -3209,6 +3252,9 @@ int mt7925_mcu_hw_scan(struct mt76_phy *phy, struct ieee80211_vif *vif, req->scan_func |= SCAN_FUNC_RANDOM_MAC; } + /* Append scan probe IEs as the last tlv */ + mt7925_mcu_build_scan_ie_tlv(mdev, skb, &scan_req->ies); + err = mt76_mcu_skb_send_msg(mdev, skb, MCU_UNI_CMD(SCAN_REQ), true); if (err < 0) @@ -3220,7 +3266,8 @@ EXPORT_SYMBOL_GPL(mt7925_mcu_hw_scan); int mt7925_mcu_sched_scan_req(struct mt76_phy *phy, struct ieee80211_vif *vif, - struct cfg80211_sched_scan_request *sreq) + struct cfg80211_sched_scan_request *sreq, + struct ieee80211_scan_ies *ies) { struct mt76_vif_link *mvif = (struct mt76_vif_link *)vif->drv_priv; struct ieee80211_channel **scan_list = sreq->channels; @@ -3308,12 +3355,8 @@ int mt7925_mcu_sched_scan_req(struct mt76_phy *phy, } chan_info->channel_type = sreq->n_channels ? 4 : 0; - tlv = mt76_connac_mcu_add_tlv(skb, UNI_SCAN_IE, sizeof(*ie)); - ie = (struct scan_ie_tlv *)tlv; - if (sreq->ie_len > 0) { - memcpy(ie->ies, sreq->ie, sreq->ie_len); - ie->ies_len = cpu_to_le16(sreq->ie_len); - } + /* Append scan probe IEs as the last tlv */ + mt7925_mcu_build_scan_ie_tlv(mdev, skb, ies); return mt76_mcu_skb_send_msg(mdev, skb, MCU_UNI_CMD(SCAN_REQ), true); diff --git a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h index 3dddadb7457b..c34b28769782 100644 --- a/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h +++ b/drivers/net/wireless/mediatek/mt76/mt7925/mcu.h @@ -269,7 +269,7 @@ struct scan_ie_tlv { __le16 ies_len; u8 band; u8 pad; - u8 ies[MT76_CONNAC_SCAN_IE_LEN]; + u8 ies[]; }; struct scan_misc_tlv { @@ -674,7 +674,8 @@ int mt7925_mcu_cancel_hw_scan(struct mt76_phy *phy, struct ieee80211_vif *vif); int mt7925_mcu_sched_scan_req(struct mt76_phy *phy, struct ieee80211_vif *vif, - struct cfg80211_sched_scan_request *sreq); + struct cfg80211_sched_scan_request *sreq, + struct ieee80211_scan_ies *ies); int mt7925_mcu_sched_scan_enable(struct mt76_phy *phy, struct ieee80211_vif *vif, bool enable); -- 2.34.1

3 months

1
0
0 0

[PATCH v2 0/5] drm/xe: enable driver usage on non-4KiB kernels

by Mingcong Bai via B4 Relay

This patch series attempts to enable the use of xe DRM driver on non-4KiB kernel page platforms. This involves fixing the ttm/bo interface, as well as parts of the userspace API to make use of kernel `PAGE_SIZE' for alignment instead of the assumed `SZ_4K', it also fixes incorrect usage of `PAGE_SIZE' in the GuC and ring buffer interface code to make sure all instructions/commands were aligned to 4KiB barriers (per the Programmer's Manual for the GPUs covered by this DRM driver). This issue was first discovered and reported by members of the LoongArch user communities, whose hardware commonly ran on 16KiB-page kernels. The patch series began on an unassuming branch of a downstream kernel tree maintained by Shang Yatsen.[^1] It worked well but remained sparsely documented, a lot of the work done here relied on Shang Yatsen's original patch. AOSC OS then picked it up[^2] to provide Intel Xe/Arc support for users of its LoongArch port, for which I worked extensively on. After months of positive user feedback and from encouragement from Kexy Biscuit, my colleague at the community, I decided to examine its potential for upstreaming, cross-reference kernel and Intel documentation to better document and revise this patch. Now that this series has been tested good (for boot up, OpenGL, and playback of a standardised set of video samples[^3] on the following platforms (motherboard + GPU model): - x86-64, 4KiB kernel page: - MS-7D42 + Intel Arc A580 - COLORFIRE B760M-MEOW WIFI D5 + Intel Arc B580 - LoongArch, 16KiB kernel page: - XA61200 + GUNNIR DG1 Blue Halberd (Intel DG1) - XA61200 + GUNNIR Iris Xe Index 4 (Intel DG1) - XA61200 + GUNNIR Intel Iris Xe Max Index V2 (Intel DG1) - XA61200 + GUNNIR Intel Arc A380 Index 6G (Intel Arc A380) - XA61200 + ASRock Arc A380 Challenger ITX OC (Intel Arc A380) - XA61200 + Intel Arc A580 - XA61200 + GUNNIR Intel Arc A750 Photon 8G OC (Intel Arc A750) - XA61200 + Intel Arc B580 - XB612B0 + GUNNIR Intel Iris Xe Max Index V2 (Intel DG1) - XB612B0 + GUNNIR Intel Arc A380 Index 6G (Intel Arc A380) - ASUS XC-LS3A6M + GUNNIR Intel Arc B580 INDEX 12G (Intel Arc B580) On these platforms, basic functionalities tested good but the driver was unstable with occasional resets (I do suspect however, that this platform suffers from PCIe coherence issues, as instability only occurs under heavy VRAM I/O load): - AArch64, 4KiB/64KiB kernel pages: - ERUN-FD3000 (Phytium D3000) + GUNNIR Intel Iris Xe Max Index V2 (Intel DG1) - ERUN-FD3000 (Phytium D3000) + GUNNIR Intel Arc A380 Index 6G (Intel Arc A380) - ERUN-FD3000 (Phytium D3000) + GUNNIR Intel Arc A750 Photon 8G OC (Intel Arc A750) I think that this patch series is now ready for your comment and review. Please forgive me if I made any simple mistake or used wrong terminologies, but I have never worked on a patch for the DRM subsystem and my experience is still quite thin. But anyway, just letting you all know that Intel Xe/Arc works on non-4KiB kernel page platforms (and honestly, it's great to use, especially for games and media playback)! [^1]: https://github.com/FanFansfan/loongson-linux/tree/loongarch-xe [^2]: We maintained Shang Yatsen's patch until our v6.13.3 tree, until we decided to test and send this series upstream, https://github.com/AOSC-Tracking/linux/tree/aosc/v6.13.3 [^3]: Delicious hot pot! https://repo.aosc.io/ahvl/sample-videos-20250223.tar.zst --- Matthew(s), Lucas, and Francois: Thanks again for your patience and review. I recently had a job change and it put me off this series for months, but I'm back (and should be a lot more responsive now) - sorry! Let's get this ball rolling again. I was unfortunately unable to revise 1/5 from v1 as you requested, neither of your suggestions to allow allocation of VRAM smaller than page size worked... So I kept that part as is. As for the your comment in 5/5, I'm not sure about what the right approach to implement a SZ_64K >= PAGE_SIZE assert was, as there are many other instances of similar ternary conditional operators in the xe code. Correct me if I'm wrong but I felt that it might be better handled in a separate patch series? --- Changes in v2: - Define `GUC_ALIGN' and use them in GuC code to improve clarity. - Update documentation on `DRM_XE_QUERY_CONFIG_MIN_ALIGNMENT'. - Rebase, and other minor changes. - Link to v1: https://lore.kernel.org/all/20250226-xe-non-4k-fix-v1-0-80f23b5ee40e@aosc.i… To: Lucas De Marchi <lucas.demarchi(a)intel.com> To: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> To: Rodrigo Vivi <rodrigo.vivi(a)intel.com> To: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> To: Maxime Ripard <mripard(a)kernel.org> To: Thomas Zimmermann <tzimmermann(a)suse.de> To: David Airlie <airlied(a)gmail.com> To: Simona Vetter <simona(a)ffwll.ch> To: José Roberto de Souza <jose.souza(a)intel.com> To: Francois Dugast <francois.dugast(a)intel.com> To: Matthew Brost <matthew.brost(a)intel.com> To: Alan Previn <alan.previn.teres.alexis(a)intel.com> To: Zhanjun Dong <zhanjun.dong(a)intel.com> To: Matt Roper <matthew.d.roper(a)intel.com> To: Mateusz Naklicki <mateusz.naklicki(a)intel.com> Cc: Mauro Carvalho Chehab <mauro.chehab(a)linux.intel.com> Cc: Zbigniew Kempczyński <zbigniew.kempczynski(a)intel.com> Cc: intel-xe(a)lists.freedesktop.org Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kernel(a)vger.kernel.org Suggested-by: Kexy Biscuit <kexybiscuit(a)aosc.io> Co-developed-by: Shang Yatsen <429839446(a)qq.com> Signed-off-by: Shang Yatsen <429839446(a)qq.com> Signed-off-by: Mingcong Bai <jeffbai(a)aosc.io> --- Mingcong Bai (5): drm/xe/bo: fix alignment with non-4KiB kernel page sizes drm/xe/guc: use GUC_SIZE (SZ_4K) for alignment drm/xe/regs: fix RING_CTL_SIZE(size) calculation drm/xe: use 4KiB alignment for cursor jumps drm/xe/query: use PAGE_SIZE as the minimum page alignment drivers/gpu/drm/xe/regs/xe_engine_regs.h | 2 +- drivers/gpu/drm/xe/xe_bo.c | 8 ++++---- drivers/gpu/drm/xe/xe_guc.c | 4 ++-- drivers/gpu/drm/xe/xe_guc.h | 3 +++ drivers/gpu/drm/xe/xe_guc_ads.c | 32 ++++++++++++++++---------------- drivers/gpu/drm/xe/xe_guc_capture.c | 8 ++++---- drivers/gpu/drm/xe/xe_guc_ct.c | 2 +- drivers/gpu/drm/xe/xe_guc_log.c | 5 +++-- drivers/gpu/drm/xe/xe_guc_pc.c | 4 ++-- drivers/gpu/drm/xe/xe_migrate.c | 4 ++-- drivers/gpu/drm/xe/xe_query.c | 2 +- include/uapi/drm/xe_drm.h | 7 +++++-- 12 files changed, 44 insertions(+), 37 deletions(-) --- base-commit: 546b1c9e93c2bb8cf5ed24e0be1c86bb089b3253 change-id: 20250603-upstream-xe-non-4k-v2-4acf253c9bfd Best regards, -- Mingcong Bai <jeffbai(a)aosc.io>

3 months

2
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror