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

[PATCH v2] mfd: cros_ec: Separate charge-control probing from USB-PD

by Thomas Weißschuh

The charge-control subsystem in the ChromeOS EC is not strictly tied to its USB-PD subsystem. Since commit 7613bc0d116a ("mfd: cros_ec: Don't load charger with UCSI") the presence of EC_FEATURE_UCSI_PPM would inhibit the probing of the charge-control driver. Furthermore recent versions of the EC firmware in Framework laptops hard-disable EC_FEATURE_USB_PD to avoid probing cros-usbpd-charger, which then also breaks cros-charge-control. Instead use the dedicated EC_FEATURE_CHARGER. Link: https://github.com/FrameworkComputer/EmbeddedController/commit/1d7bcf1d5013… Fixes: 555b5fcdb844 ("mfd: cros_ec: Register charge control subdevice") Cc: stable(a)vger.kernel.org Tested-by: Tom Vincent <linux(a)tlvince.com> Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Changes in v2: - Rebase onto v6.16-rc1 - Pick up tested-by from Tom - Also Cc stable@ - Link to v1: https://lore.kernel.org/r/20250521-cros-ec-mfd-chctl-probe-v1-1-6ebfe3a6efa… --- drivers/mfd/cros_ec_dev.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/mfd/cros_ec_dev.c b/drivers/mfd/cros_ec_dev.c index 9f84a52b48d6a8994d23edba999398684303ee64..dc80a272726bb16b58253418999021cd56dfd975 100644 --- a/drivers/mfd/cros_ec_dev.c +++ b/drivers/mfd/cros_ec_dev.c @@ -87,7 +87,6 @@ static const struct mfd_cell cros_ec_sensorhub_cells[] = { }; static const struct mfd_cell cros_usbpd_charger_cells[] = { - { .name = "cros-charge-control", }, { .name = "cros-usbpd-charger", }, { .name = "cros-usbpd-logger", }, }; @@ -112,6 +111,10 @@ static const struct mfd_cell cros_ec_ucsi_cells[] = { { .name = "cros_ec_ucsi", }, }; +static const struct mfd_cell cros_ec_charge_control_cells[] = { + { .name = "cros-charge-control", }, +}; + static const struct cros_feature_to_cells cros_subdevices[] = { { .id = EC_FEATURE_CEC, @@ -148,6 +151,11 @@ static const struct cros_feature_to_cells cros_subdevices[] = { .mfd_cells = cros_ec_keyboard_leds_cells, .num_cells = ARRAY_SIZE(cros_ec_keyboard_leds_cells), }, + { + .id = EC_FEATURE_CHARGER, + .mfd_cells = cros_ec_charge_control_cells, + .num_cells = ARRAY_SIZE(cros_ec_charge_control_cells), + }, }; static const struct mfd_cell cros_ec_platform_cells[] = { --- base-commit: 19272b37aa4f83ca52bdf9c16d5d81bdd1354494 change-id: 20250521-cros-ec-mfd-chctl-probe-64a63ac9c160 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

3 weeks, 3 days

3
2
0 0

[PATCH v3 1/3] mm/huge_memory: don't ignore queried cachemode in vmf_insert_pfn_pud()

by David Hildenbrand

We setup the cache mode but ... don't forward the updated pgprot to insert_pfn_pud(). Only a problem on x86-64 PAT when mapping PFNs using PUDs that require a special cachemode. Fix it by using the proper pgprot where the cachemode was setup. It is unclear in which configurations we would get the cachemode wrong: through vfio seems possible. Getting cachemodes wrong is usually ... bad. As the fix is easy, let's backport it to stable. Identified by code inspection. Fixes: 7b806d229ef1 ("mm: remove vmf_insert_pfn_xxx_prot() for huge page-table entries") Reviewed-by: Dan Williams <dan.j.williams(a)intel.com> Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Reviewed-by: Jason Gunthorpe <jgg(a)nvidia.com> Tested-by: Dan Williams <dan.j.williams(a)intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: David Hildenbrand <david(a)redhat.com> --- mm/huge_memory.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index d3e66136e41a3..49b98082c5401 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1516,10 +1516,9 @@ static pud_t maybe_pud_mkwrite(pud_t pud, struct vm_area_struct *vma) } static void insert_pfn_pud(struct vm_area_struct *vma, unsigned long addr, - pud_t *pud, pfn_t pfn, bool write) + pud_t *pud, pfn_t pfn, pgprot_t prot, bool write) { struct mm_struct *mm = vma->vm_mm; - pgprot_t prot = vma->vm_page_prot; pud_t entry; if (!pud_none(*pud)) { @@ -1581,7 +1580,7 @@ vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write) pfnmap_setup_cachemode_pfn(pfn_t_to_pfn(pfn), &pgprot); ptl = pud_lock(vma->vm_mm, vmf->pud); - insert_pfn_pud(vma, addr, vmf->pud, pfn, write); + insert_pfn_pud(vma, addr, vmf->pud, pfn, pgprot, write); spin_unlock(ptl); return VM_FAULT_NOPAGE; @@ -1625,7 +1624,7 @@ vm_fault_t vmf_insert_folio_pud(struct vm_fault *vmf, struct folio *folio, add_mm_counter(mm, mm_counter_file(folio), HPAGE_PUD_NR); } insert_pfn_pud(vma, addr, vmf->pud, pfn_to_pfn_t(folio_pfn(folio)), - write); + vma->vm_page_prot, write); spin_unlock(ptl); return VM_FAULT_NOPAGE; -- 2.49.0

3 weeks, 3 days

2
1
0 0

[PATCH v3] ata: ahci: Disallow LPM for ASUSPRO-D840SA motherboard

by Niklas Cassel

A user has bisected a regression which causes graphical corruptions on his screen to commit 7627a0edef54 ("ata: ahci: Drop low power policy board type"). Simply reverting commit 7627a0edef54 ("ata: ahci: Drop low power policy board type") makes the graphical corruptions on his screen to go away. (Note: there are no visible messages in dmesg that indicates a problem with AHCI.) The user also reports that the problem occurs regardless if there is an HDD or an SSD connected via AHCI, so the problem is not device related. The devices also work fine on other motherboards, so it seems specific to the ASUSPRO-D840SA motherboard. While enabling low power modes for AHCI is not supposed to affect completely unrelated hardware, like a graphics card, it does however allow the system to enter deeper PC-states, which could expose ACPI issues that were previously not visible (because the system never entered these lower power states before). There are previous examples where enabling LPM exposed serious BIOS/ACPI bugs, see e.g. commit 240630e61870 ("ahci: Disable LPM on Lenovo 50 series laptops with a too old BIOS"). Since there hasn't been any BIOS update in years for the ASUSPRO-D840SA motherboard, disable LPM for this board, in order to avoid entering lower PC-states, which triggers graphical corruptions. Cc: stable(a)vger.kernel.org Reported-by: Andy Yang <andyybtc79(a)gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220111 Fixes: 7627a0edef54 ("ata: ahci: Drop low power policy board type") Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- Changes since v2: -Rework how we handle the quirk so that we also quirk future BIOS versions unless a build date is explicitly added to driver_data. drivers/ata/ahci.c | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c index e7c8357cbc54..c8ad8ace7496 100644 --- a/drivers/ata/ahci.c +++ b/drivers/ata/ahci.c @@ -1410,8 +1410,15 @@ static bool ahci_broken_suspend(struct pci_dev *pdev) static bool ahci_broken_lpm(struct pci_dev *pdev) { + /* + * Platforms with LPM problems. + * If driver_data is NULL, there is no existing BIOS version with + * functioning LPM. + * If driver_data is non-NULL, then driver_data contains the DMI BIOS + * build date of the first BIOS version with functioning LPM (i.e. older + * BIOS versions have broken LPM). + */ static const struct dmi_system_id sysids[] = { - /* Various Lenovo 50 series have LPM issues with older BIOSen */ { .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), @@ -1440,6 +1447,13 @@ static bool ahci_broken_lpm(struct pci_dev *pdev) }, .driver_data = "20180409", /* 2.35 */ }, + { + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."), + DMI_MATCH(DMI_PRODUCT_VERSION, "ASUSPRO D840MB_M840SA"), + }, + /* 320 is broken, there is no known good version yet. */ + }, { } /* terminate list */ }; const struct dmi_system_id *dmi = dmi_first_match(sysids); @@ -1449,6 +1463,9 @@ static bool ahci_broken_lpm(struct pci_dev *pdev) if (!dmi) return false; + if (!dmi->driver_data) + return true; + dmi_get_date(DMI_BIOS_DATE, &year, &month, &date); snprintf(buf, sizeof(buf), "%04d%02d%02d", year, month, date); -- 2.49.0

3 weeks, 3 days

3
3
0 0

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

by Ankit Nautiyal

DIV_ROUND_CLOSEST_ULL uses do_div(), which expects a 32-bit divisor. When passing a 64-bit constant like CURVE2_MULTIPLIER, the value is silently truncated to u32, potentially leading to incorrect results on large divisors. Replace DIV_ROUND_CLOSEST_ULL with div64_u64(), which correctly handles full 64-bit division. Since the result is clamped between 1 and 127, rounding is unnecessary and truncating division is sufficient. Fixes: 5947642004bf ("drm/i915/display: Add support for SNPS PHY HDMI PLL algorithm for DG2") Cc: Ankit Nautiyal <ankit.k.nautiyal(a)intel.com> Cc: Suraj Kandpal <suraj.kandpal(a)intel.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.15+ Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal(a)intel.com> --- drivers/gpu/drm/i915/display/intel_snps_hdmi_pll.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_snps_hdmi_pll.c b/drivers/gpu/drm/i915/display/intel_snps_hdmi_pll.c index 74bb3bedf30f..ac609bdf6653 100644 --- a/drivers/gpu/drm/i915/display/intel_snps_hdmi_pll.c +++ b/drivers/gpu/drm/i915/display/intel_snps_hdmi_pll.c @@ -103,8 +103,8 @@ static void get_ana_cp_int_prop(u64 vco_clk, DIV_ROUND_DOWN_ULL(curve_1_interpolated, CURVE0_MULTIPLIER))); ana_cp_int_temp = - DIV_ROUND_CLOSEST_ULL(DIV_ROUND_DOWN_ULL(adjusted_vco_clk1, curve_2_scaled1), - CURVE2_MULTIPLIER); + div64_u64(DIV_ROUND_DOWN_ULL(adjusted_vco_clk1, curve_2_scaled1), + CURVE2_MULTIPLIER); *ana_cp_int = max(1, min(ana_cp_int_temp, 127)); -- 2.45.2

3 weeks, 3 days

3
2
0 0

Reply Request: UITP Summit - Hamburg 2025 Attendees List

by Michelle Calara

Hi, Following up on my primary email about the visitor list. Please let me know your thoughts, and I'd be happy to give more details. Best regards, Grace Subject: UITP Summit - Hamburg 2025! Hi, I wanted to check if you’d be interested in acquiring the attendees list of UITP Summit - Hamburg 2025? Event Overview: Dates: 15 - 18 Jun 2025 Location: Hamburg, Germany Attendees: 10,126 Exhibitors: 380 Each contact contains: Contact Name, First Name, Last Name, Job Title, Company, Website Address, City, State, Zip, Country Code, Revenue, Employee Size, Email, Phone Number, and Fax Number. If you're interested in the list, just reply "Send Counts and Cost"? Best regards, Michelle Calara Senior Marketing Manager To unsubscribe, simply respond with “Not interested.”

3 weeks, 3 days

1
0
0 0

[tip: perf/urgent] perf/x86/intel: Fix crash in icl_update_topdown_event()

by tip-bot2 for Kan Liang

The following commit has been merged into the perf/urgent branch of tip: Commit-ID: b0823d5fbacb1c551d793cbfe7af24e0d1fa45ed Gitweb: https://git.kernel.org/tip/b0823d5fbacb1c551d793cbfe7af24e0d1fa45ed Author: Kan Liang <kan.liang(a)linux.intel.com> AuthorDate: Thu, 12 Jun 2025 07:38:18 -07:00 Committer: Ingo Molnar <mingo(a)kernel.org> CommitterDate: Fri, 13 Jun 2025 09:38:06 +02:00 perf/x86/intel: Fix crash in icl_update_topdown_event() The perf_fuzzer found a hard-lockup crash on a RaptorLake machine: Oops: general protection fault, maybe for address 0xffff89aeceab400: 0000 CPU: 23 UID: 0 PID: 0 Comm: swapper/23 Tainted: [W]=WARN Hardware name: Dell Inc. Precision 9660/0VJ762 RIP: 0010:native_read_pmc+0x7/0x40 Code: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ... RSP: 000:fffb03100273de8 EFLAGS: 00010046 .... Call Trace: <TASK> icl_update_topdown_event+0x165/0x190 ? ktime_get+0x38/0xd0 intel_pmu_read_event+0xf9/0x210 __perf_event_read+0xf9/0x210 CPUs 16-23 are E-core CPUs that don't support the perf metrics feature. The icl_update_topdown_event() should not be invoked on these CPUs. It's a regression of commit: f9bdf1f95339 ("perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read") The bug introduced by that commit is that the is_topdown_event() function is mistakenly used to replace the is_topdown_count() call to check if the topdown functions for the perf metrics feature should be invoked. Fix it. Fixes: f9bdf1f95339 ("perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read") Closes: https://lore.kernel.org/lkml/352f0709-f026-cd45-e60c-60dfd97f73f3@maine.edu/ Reported-by: Vince Weaver <vincent.weaver(a)maine.edu> Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Tested-by: Vince Weaver <vincent.weaver(a)maine.edu> Cc: stable(a)vger.kernel.org # v6.15+ Link: https://lore.kernel.org/r/20250612143818.2889040-1-kan.liang@linux.intel.com --- arch/x86/events/intel/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 741b229..c2fb729 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -2826,7 +2826,7 @@ static void intel_pmu_read_event(struct perf_event *event) * If the PEBS counters snapshotting is enabled, * the topdown event is available in PEBS records. */ - if (is_topdown_event(event) && !is_pebs_counter_event_group(event)) + if (is_topdown_count(event) && !is_pebs_counter_event_group(event)) static_call(intel_pmu_update_topdown_event)(event, NULL); else intel_pmu_drain_pebs_buffer();

3 weeks, 3 days

1
0
0 0

[PATCH v2 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 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 drivers/media/platform/cadence/cdns-csi2rx.c | 76 +++++++++++++++++----- drivers/media/platform/cadence/cdns-csi2rx.h | 19 ++++++ drivers/media/platform/ti/Kconfig | 3 +- .../media/platform/ti/j721e-csi2rx/j721e-csi2rx.c | 66 ++++++++++++++----- 4 files changed, 129 insertions(+), 35 deletions(-) --- base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 change-id: 20250314-probe_fixes-7e0ec33c7fee Best regards, -- Jai Luthra <jai.luthra(a)ideasonboard.com>

3 weeks, 3 days

2
3
0 0

Re: it's Seven again for PCBA One-stop Service

by Seven

Hi , What would it mean to you if your business was able to reduce Expenses by 20% (Clients: Littelfuse, Corsair, BMB, Mercedes-Benz, Fantac) We are a PCBA factory with an area of 6,000 square meters. We have been in this industry for 18 years and have an experienced team of engineers. Help you reduce BOM Expenses Fast delivery (15 days for Demo) Competitive prices (10% lower than peers) Real factory processing fees are Fees Complete quality management system (ISO9001,ISO14001,ISO13485,IATF16949,UL)Given how well our pcba service suits your needs, I think we could do some Excellent work together. Seven LeeChief Technology Officer Business Department | Shenzhen STHL Technology Co,Ltd +8618569002840 Seven(a)pcba-china.com 在2025-06-04，Seven <seven(a)ems-sthi.com> 写道:-----原始邮件----- 发件人： Seven <seven(a)ems-sthi.com> 发件时间: 2025年06月04日周三收件人： [Linux-stable-mirror <linux-stable-mirror(a)lists.linaro.org>] 主题： Re:Jordan recommend me get in touch Hi, Glad to know you and your company from Jordan. I‘m Seven CTO of STHL We are a one-stop service provider for PCBA. We can help you with production from PCB to finished product assembly. Why Partner With Us? ✅ One-Stop Expertise: From PCB fabrication, PCBA (SMT & Through-Hole), custom cable harnesses, , to final product assembly – we eliminate multi-vendor coordination risks. ✅ Cost Efficiency: 40%+ clients reduce logistics/QC costs through our integrated service model (ISO 9001:2015 certified). ✅ Speed-to-Market: Average 15% faster lead times achieved via in-house vertical integration. Recent Success Case: Helped a German IoT startup scale from prototype to 50K-unit/month production within 6 months through our: PCB Design-for-Manufacturing (DFM) optimization Automated PCBA with 99.98% first-pass yield Mechanical housing CNC machining & IP67-rated assembly Seven Marcus CTO Shenzhen STHL Technology Co,Ltd +8618569002840 Seven(a)pcba-china.com

3 weeks, 3 days

1
0
0 0

[PATCH 6.12.y] wifi: rtw89: phy: add dummy C2H event handler for report of TAS power

by Zenm Chen

From: Ping-Ke Shih <pkshih(a)realtek.com> [ Upstream commit 09489812013f9ff3850c3af9900c88012b8c1e5d ] The newer firmware, like RTL8852C version 0.27.111.0, will notify driver report of TAS (Time Averaged SAR) power by new C2H events. This is to assist in higher accurate calculation of TAS. For now, driver doesn't use the report yet, so add a dummy handler to avoid it throws info like: rtw89_8852ce 0000:03:00.0: c2h class 9 func 6 not support Also add "MAC" and "PHY" to the message to disambiguate the source of C2H event. Signed-off-by: Ping-Ke Shih <pkshih(a)realtek.com> Link: https://patch.msgid.link/20241209042127.21424-1-pkshih@realtek.com Signed-off-by: Zenm Chen <zenmchen(a)gmail.com> --- Currently the rtw89 driver in kernel 6.12.y could spam the system log with the messages below if the distro provides a newer firmware, backport this patch to 6.12.y to fix it. [ 13.207637] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 17.115171] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 19.117996] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 21.122162] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 23.123588] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 25.127008] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 31.246591] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 34.665080] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 41.064308] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 43.067127] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 45.069878] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 47.072845] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 49.265599] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 51.268512] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 53.271490] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support [ 55.274271] rtw89_8852ce 0000:02:00.0: c2h class 9 func 6 not support --- drivers/net/wireless/realtek/rtw89/mac.c | 4 ++-- drivers/net/wireless/realtek/rtw89/phy.c | 10 ++++++++-- drivers/net/wireless/realtek/rtw89/phy.h | 1 + 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw89/mac.c b/drivers/net/wireless/realtek/rtw89/mac.c index 9b09d4b7d..2188bca89 100644 --- a/drivers/net/wireless/realtek/rtw89/mac.c +++ b/drivers/net/wireless/realtek/rtw89/mac.c @@ -5513,11 +5513,11 @@ void rtw89_mac_c2h_handle(struct rtw89_dev *rtwdev, struct sk_buff *skb, case RTW89_MAC_C2H_CLASS_FWDBG: return; default: - rtw89_info(rtwdev, "c2h class %d not support\n", class); + rtw89_info(rtwdev, "MAC c2h class %d not support\n", class); return; } if (!handler) { - rtw89_info(rtwdev, "c2h class %d func %d not support\n", class, + rtw89_info(rtwdev, "MAC c2h class %d func %d not support\n", class, func); return; } diff --git a/drivers/net/wireless/realtek/rtw89/phy.c b/drivers/net/wireless/realtek/rtw89/phy.c index 5c31639b4..355c3f58a 100644 --- a/drivers/net/wireless/realtek/rtw89/phy.c +++ b/drivers/net/wireless/realtek/rtw89/phy.c @@ -3062,10 +3062,16 @@ rtw89_phy_c2h_rfk_report_state(struct rtw89_dev *rtwdev, struct sk_buff *c2h, u3 (int)(len - sizeof(report->hdr)), &report->state); } +static void +rtw89_phy_c2h_rfk_log_tas_pwr(struct rtw89_dev *rtwdev, struct sk_buff *c2h, u32 len) +{ +} + static void (* const rtw89_phy_c2h_rfk_report_handler[])(struct rtw89_dev *rtwdev, struct sk_buff *c2h, u32 len) = { [RTW89_PHY_C2H_RFK_REPORT_FUNC_STATE] = rtw89_phy_c2h_rfk_report_state, + [RTW89_PHY_C2H_RFK_LOG_TAS_PWR] = rtw89_phy_c2h_rfk_log_tas_pwr, }; bool rtw89_phy_c2h_chk_atomic(struct rtw89_dev *rtwdev, u8 class, u8 func) @@ -3119,11 +3125,11 @@ void rtw89_phy_c2h_handle(struct rtw89_dev *rtwdev, struct sk_buff *skb, return; fallthrough; default: - rtw89_info(rtwdev, "c2h class %d not support\n", class); + rtw89_info(rtwdev, "PHY c2h class %d not support\n", class); return; } if (!handler) { - rtw89_info(rtwdev, "c2h class %d func %d not support\n", class, + rtw89_info(rtwdev, "PHY c2h class %d func %d not support\n", class, func); return; } diff --git a/drivers/net/wireless/realtek/rtw89/phy.h b/drivers/net/wireless/realtek/rtw89/phy.h index 9bb9c9c8e..961a4bacb 100644 --- a/drivers/net/wireless/realtek/rtw89/phy.h +++ b/drivers/net/wireless/realtek/rtw89/phy.h @@ -151,6 +151,7 @@ enum rtw89_phy_c2h_rfk_log_func { enum rtw89_phy_c2h_rfk_report_func { RTW89_PHY_C2H_RFK_REPORT_FUNC_STATE = 0, + RTW89_PHY_C2H_RFK_LOG_TAS_PWR = 6, }; enum rtw89_phy_c2h_dm_func { -- 2.49.0

3 weeks, 3 days

1
0
0 0

[PATCH 6.15 00/34] 6.15.2-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.15.2 release. There are 34 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. Responses should be made by Mon, 09 Jun 2025 10:07:05 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.15.2-rc1… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.15.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 6.15.2-rc1 Aurabindo Pillai <aurabindo.pillai(a)amd.com> Revert "drm/amd/display: more liberal vmin/vmax update for freesync" Xu Yang <xu.yang_2(a)nxp.com> dt-bindings: phy: imx8mq-usb: fix fsl,phy-tx-vboost-level-microvolt property Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> dt-bindings: usb: cypress,hx3: Add support for all variants Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> dt-bindings: remoteproc: qcom,sm8150-pas: Add missing SC8180X compatible David Lechner <dlechner(a)baylibre.com> dt-bindings: pwm: adi,axi-pwmgen: Fix clocks Sergey Senozhatsky <senozhatsky(a)chromium.org> thunderbolt: Do not double dequeue a configuration request Carlos Llamas <cmllamas(a)google.com> binder: fix yet another UAF in binder_devices Dmitry Antipov <dmantipov(a)yandex.ru> binder: fix use-after-free in binderfs_evict_inode() Dave Penkler <dpenkler(a)gmail.com> usb: usbtmc: Fix timeout value in get_stb Arnd Bergmann <arnd(a)arndb.de> nvmem: rmem: select CONFIG_CRC32 Dustin Lundquist <dustin(a)null-ptr.net> serial: jsm: fix NPE during jsm_uart_port_init Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> Bluetooth: hci_qca: move the SoC type check to the right place Qasim Ijaz <qasdev00(a)gmail.com> usb: typec: ucsi: fix Clang -Wsign-conversion warning Charles Yeh <charlesyeh522(a)gmail.com> USB: serial: pl2303: add new chip PL2303GC-Q20 and PL2303GT-2AB Hongyu Xie <xiehongyu1(a)kylinos.cn> usb: storage: Ignore UAS driver for SanDisk 3.2 Gen2 storage device Jiayi Li <lijiayi(a)kylinos.cn> usb: quirks: Add NO_LPM quirk for SanDisk Extreme 55AE Kent Overstreet <kent.overstreet(a)linux.dev> bcachefs: Fix subvol to missing root repair Kent Overstreet <kent.overstreet(a)linux.dev> bcachefs: Run may_delete_deleted_inode() checks in bch2_inode_rm() Kent Overstreet <kent.overstreet(a)linux.dev> bcachefs: delete dead code from may_delete_deleted_inode() Kent Overstreet <kent.overstreet(a)linux.dev> bcachefs: Repair code for directory i_size Kent Overstreet <kent.overstreet(a)linux.dev> bcachefs: Kill un-reverted directory i_size code Alexandre Mergnat <amergnat(a)baylibre.com> rtc: Fix offset calculation for .start_secs < 0 Alexandre Mergnat <amergnat(a)baylibre.com> rtc: Make rtc_time64_to_tm() support dates before 1970 Nícolas F. R. A. Prado <nfraprado(a)collabora.com> pinctrl: mediatek: eint: Fix invalid pointer dereference for v1 platforms Sakari Ailus <sakari.ailus(a)linux.intel.com> Documentation: ACPI: Use all-string data node references Gautham R. Shenoy <gautham.shenoy(a)amd.com> acpi-cpufreq: Fix nominal_freq units to KHz in get_max_boost_ratio() Pritam Manohar Sutar <pritam.sutar(a)samsung.com> clk: samsung: correct clock summary for hsi1 block Gabor Juhos <j4g8y7(a)gmail.com> pinctrl: armada-37xx: set GPIO output value before setting direction Gabor Juhos <j4g8y7(a)gmail.com> pinctrl: armada-37xx: use correct OUTPUT_VAL register for GPIOs > 31 Ahmed Salem <x0rw3ll(a)gmail.com> ACPICA: Apply ACPI_NONSTRING in more places Kees Cook <kees(a)kernel.org> ACPICA: Apply ACPI_NONSTRING Kees Cook <kees(a)kernel.org> ACPICA: Introduce ACPI_NONSTRING Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Revert "x86/smp: Eliminate mwait_play_dead_cpuid_hint()" Pan Taixi <pantaixi(a)huaweicloud.com> tracing: Fix compilation warning on arm32 ------------- Diffstat: .../bindings/phy/fsl,imx8mq-usb-phy.yaml | 3 +- .../devicetree/bindings/pwm/adi,axi-pwmgen.yaml | 13 +++- .../bindings/remoteproc/qcom,sm8150-pas.yaml | 3 + .../devicetree/bindings/usb/cypress,hx3.yaml | 19 +++++- .../acpi/dsd/data-node-references.rst | 26 ++++---- Documentation/firmware-guide/acpi/dsd/graph.rst | 11 ++-- Documentation/firmware-guide/acpi/dsd/leds.rst | 7 +- Makefile | 4 +- arch/x86/kernel/smpboot.c | 54 +++++++++++++-- drivers/acpi/acpica/acdebug.h | 2 +- drivers/acpi/acpica/aclocal.h | 4 +- drivers/acpi/acpica/nsnames.c | 2 +- drivers/acpi/acpica/nsrepair2.c | 2 +- drivers/android/binder.c | 16 ++++- drivers/android/binder_internal.h | 8 ++- drivers/android/binderfs.c | 2 +- drivers/bluetooth/hci_qca.c | 14 ++-- drivers/clk/samsung/clk-exynosautov920.c | 2 +- drivers/cpufreq/acpi-cpufreq.c | 2 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 16 ++--- drivers/nvmem/Kconfig | 1 + drivers/pinctrl/mediatek/mtk-eint.c | 26 ++++---- drivers/pinctrl/mediatek/mtk-eint.h | 5 +- drivers/pinctrl/mediatek/pinctrl-mtk-common-v2.c | 2 +- drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 2 +- drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 14 ++-- drivers/rtc/class.c | 2 +- drivers/rtc/lib.c | 24 +++++-- drivers/thunderbolt/ctl.c | 5 ++ drivers/tty/serial/jsm/jsm_tty.c | 1 + drivers/usb/class/usbtmc.c | 4 +- drivers/usb/core/quirks.c | 3 + drivers/usb/serial/pl2303.c | 2 + drivers/usb/storage/unusual_uas.h | 7 ++ drivers/usb/typec/ucsi/ucsi.h | 2 +- fs/bcachefs/dirent.c | 12 +--- fs/bcachefs/dirent.h | 4 +- fs/bcachefs/errcode.h | 2 + fs/bcachefs/fs.c | 8 ++- fs/bcachefs/fsck.c | 8 +++ fs/bcachefs/inode.c | 77 ++++++++++++++-------- fs/bcachefs/namei.c | 4 +- fs/bcachefs/sb-errors_format.h | 4 +- fs/bcachefs/subvolume.c | 19 ++++-- include/acpi/actbl.h | 6 +- include/acpi/actypes.h | 4 ++ include/acpi/platform/acgcc.h | 8 +++ kernel/trace/trace.c | 2 +- .../acpi/os_specific/service_layers/oslinuxtbl.c | 2 +- tools/power/acpi/tools/acpidump/apfiles.c | 2 +- 50 files changed, 314 insertions(+), 158 deletions(-)

3 weeks, 3 days

16
51
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 weeks, 3 days

3
7
0 0

[PATCH 6.6.y] wifi: rtw89: pci: use DBI function for 8852AE/8852BE/8851BE

by Zenm Chen

From: Chin-Yen Lee <timlee(a)realtek.com> [ Upstream commit 9496d62f3877bc0f97b415bc04af98d092878026 ] Sometimes driver can't use kernel API pci_read/write_config_byte to access the PCI config space of above address 0x100 due to the negotiated PCI setting. 8852AE/8852BE/8851BE provide another way called DBI function, which belongs to WiFi mac and could access all PCI config space for this case. Link: https://lore.kernel.org/linux-wireless/79fe81b7db7148b9a7da2353c16d70fb@rea… Signed-off-by: Chin-Yen Lee <timlee(a)realtek.com> Signed-off-by: Ping-Ke Shih <pkshih(a)realtek.com> Signed-off-by: Kalle Valo <kvalo(a)kernel.org> Link: https://msgid.link/20240103012346.6822-1-pkshih@realtek.com Signed-off-by: Zenm Chen <zenmchen(a)gmail.com> --- Without this patch applied, the rtw89 driver in kernel 6.6.y may fail to initialize the RTL8852BE chip and print the error messages below on some platforms [1]. [ 13.449168] rtw89_8852be_git 0000:02:00.0: [ERR]pci config read 719 [ 13.449754] rtw89_8852be_git 0000:02:00.0: [ERR] pcie autok fail -22 [ 13.450353] rtw89_8852be_git 0000:02:00.0: failed to setup chip information [ 13.455857] rtw89_8852be_git: probe of 0000:02:00.0 failed with error -22 [1] https://github.com/a5a5aa555oo/rtw89/issues/3 --- drivers/net/wireless/realtek/rtw89/pci.c | 69 +++++++++++++++++++++++- drivers/net/wireless/realtek/rtw89/pci.h | 1 + 2 files changed, 68 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/realtek/rtw89/pci.c b/drivers/net/wireless/realtek/rtw89/pci.c index 30cc6e03c..33b2543ee 100644 --- a/drivers/net/wireless/realtek/rtw89/pci.c +++ b/drivers/net/wireless/realtek/rtw89/pci.c @@ -1822,22 +1822,87 @@ static int rtw89_write16_mdio_clr(struct rtw89_dev *rtwdev, u8 addr, u16 mask, u return 0; } +static int rtw89_dbi_write8(struct rtw89_dev *rtwdev, u16 addr, u8 data) +{ + u16 addr_2lsb = addr & B_AX_DBI_2LSB; + u16 write_addr; + u8 flag; + int ret; + + write_addr = addr & B_AX_DBI_ADDR_MSK; + write_addr |= u16_encode_bits(BIT(addr_2lsb), B_AX_DBI_WREN_MSK); + rtw89_write8(rtwdev, R_AX_DBI_WDATA + addr_2lsb, data); + rtw89_write16(rtwdev, R_AX_DBI_FLAG, write_addr); + rtw89_write8(rtwdev, R_AX_DBI_FLAG + 2, B_AX_DBI_WFLAG >> 16); + + ret = read_poll_timeout_atomic(rtw89_read8, flag, !flag, 10, + 10 * RTW89_PCI_WR_RETRY_CNT, false, + rtwdev, R_AX_DBI_FLAG + 2); + if (ret) + rtw89_err(rtwdev, "failed to write DBI register, addr=0x%X\n", + addr); + + return ret; +} + +static int rtw89_dbi_read8(struct rtw89_dev *rtwdev, u16 addr, u8 *value) +{ + u16 read_addr = addr & B_AX_DBI_ADDR_MSK; + u8 flag; + int ret; + + rtw89_write16(rtwdev, R_AX_DBI_FLAG, read_addr); + rtw89_write8(rtwdev, R_AX_DBI_FLAG + 2, B_AX_DBI_RFLAG >> 16); + + ret = read_poll_timeout_atomic(rtw89_read8, flag, !flag, 10, + 10 * RTW89_PCI_WR_RETRY_CNT, false, + rtwdev, R_AX_DBI_FLAG + 2); + if (ret) { + rtw89_err(rtwdev, "failed to read DBI register, addr=0x%X\n", + addr); + return ret; + } + + read_addr = R_AX_DBI_RDATA + (addr & 3); + *value = rtw89_read8(rtwdev, read_addr); + + return 0; +} + static int rtw89_pci_write_config_byte(struct rtw89_dev *rtwdev, u16 addr, u8 data) { struct rtw89_pci *rtwpci = (struct rtw89_pci *)rtwdev->priv; + enum rtw89_core_chip_id chip_id = rtwdev->chip->chip_id; struct pci_dev *pdev = rtwpci->pdev; + int ret; + + ret = pci_write_config_byte(pdev, addr, data); + if (!ret) + return 0; - return pci_write_config_byte(pdev, addr, data); + if (chip_id == RTL8852A || chip_id == RTL8852B || chip_id == RTL8851B) + ret = rtw89_dbi_write8(rtwdev, addr, data); + + return ret; } static int rtw89_pci_read_config_byte(struct rtw89_dev *rtwdev, u16 addr, u8 *value) { struct rtw89_pci *rtwpci = (struct rtw89_pci *)rtwdev->priv; + enum rtw89_core_chip_id chip_id = rtwdev->chip->chip_id; struct pci_dev *pdev = rtwpci->pdev; + int ret; - return pci_read_config_byte(pdev, addr, value); + ret = pci_read_config_byte(pdev, addr, value); + if (!ret) + return 0; + + if (chip_id == RTL8852A || chip_id == RTL8852B || chip_id == RTL8851B) + ret = rtw89_dbi_read8(rtwdev, addr, value); + + return ret; } static int rtw89_pci_config_byte_set(struct rtw89_dev *rtwdev, u16 addr, diff --git a/drivers/net/wireless/realtek/rtw89/pci.h b/drivers/net/wireless/realtek/rtw89/pci.h index 4259b79b1..119c0608b 100644 --- a/drivers/net/wireless/realtek/rtw89/pci.h +++ b/drivers/net/wireless/realtek/rtw89/pci.h @@ -42,6 +42,7 @@ #define B_AX_DBI_WFLAG BIT(16) #define B_AX_DBI_WREN_MSK GENMASK(15, 12) #define B_AX_DBI_ADDR_MSK GENMASK(11, 2) +#define B_AX_DBI_2LSB GENMASK(1, 0) #define R_AX_DBI_WDATA 0x1094 #define R_AX_DBI_RDATA 0x1098 -- 2.49.0

3 weeks, 3 days

1
0
0 0

[PATCH] drm/xe: Fix early wedge on GuC load failure

by Daniele Ceraolo Spurio

When the GuC fails to load we declare the device wedged. However, the very first GuC load attempt on GT0 (from xe_gt_init_hwconfig) is done before the GT1 GuC objects are initialized, so things go bad when the wedge code attempts to cleanup GT1. To fix this, check the initialization status in the functions called during wedge. Fixes: 7dbe8af13c18 ("drm/xe: Wedge the entire device") Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Jonathan Cavitt <jonathan.cavitt(a)intel.com> Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: Zhanjun Dong <zhanjun.dong(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.12+: 1e1981b16bb1: drm/xe: Fix taking invalid lock on wedge Cc: <stable(a)vger.kernel.org> # v6.12+ Reviewed-by: Jonathan Cavitt <jonathan.cavitt(a)intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi(a)intel.com> --- drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c | 8 ++++++++ drivers/gpu/drm/xe/xe_guc_ct.c | 7 +++++-- drivers/gpu/drm/xe/xe_guc_ct.h | 5 +++++ drivers/gpu/drm/xe/xe_guc_submit.c | 3 +++ 4 files changed, 21 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c b/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c index 084cbdeba8ea..e1362e608146 100644 --- a/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c +++ b/drivers/gpu/drm/xe/xe_gt_tlb_invalidation.c @@ -137,6 +137,14 @@ void xe_gt_tlb_invalidation_reset(struct xe_gt *gt) struct xe_gt_tlb_invalidation_fence *fence, *next; int pending_seqno; + /* + * we can get here before the CTs are even initialized if we're wedging + * very early, in which case there are not going to be any pending + * fences so we can bail immediately. + */ + if (!xe_guc_ct_initialized(&gt->uc.guc.ct)) + return; + /* * CT channel is already disabled at this point. No new TLB requests can * appear. diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c index 822f4c33f730..e303fec18174 100644 --- a/drivers/gpu/drm/xe/xe_guc_ct.c +++ b/drivers/gpu/drm/xe/xe_guc_ct.c @@ -517,6 +517,9 @@ void xe_guc_ct_disable(struct xe_guc_ct *ct) */ void xe_guc_ct_stop(struct xe_guc_ct *ct) { + if (!xe_guc_ct_initialized(ct)) + return; + xe_guc_ct_set_state(ct, XE_GUC_CT_STATE_STOPPED); stop_g2h_handler(ct); } @@ -788,7 +791,7 @@ static int __guc_ct_send_locked(struct xe_guc_ct *ct, const u32 *action, u16 seqno; int ret; - xe_gt_assert(gt, ct->state != XE_GUC_CT_STATE_NOT_INITIALIZED); + xe_gt_assert(gt, xe_guc_ct_initialized(ct)); xe_gt_assert(gt, !g2h_len || !g2h_fence); xe_gt_assert(gt, !num_g2h || !g2h_fence); xe_gt_assert(gt, !g2h_len || num_g2h); @@ -1424,7 +1427,7 @@ static int g2h_read(struct xe_guc_ct *ct, u32 *msg, bool fast_path) u32 action; u32 *hxg; - xe_gt_assert(gt, ct->state != XE_GUC_CT_STATE_NOT_INITIALIZED); + xe_gt_assert(gt, xe_guc_ct_initialized(ct)); lockdep_assert_held(&ct->fast_lock); if (ct->state == XE_GUC_CT_STATE_DISABLED) diff --git a/drivers/gpu/drm/xe/xe_guc_ct.h b/drivers/gpu/drm/xe/xe_guc_ct.h index 5649bda82823..99c5dec446f2 100644 --- a/drivers/gpu/drm/xe/xe_guc_ct.h +++ b/drivers/gpu/drm/xe/xe_guc_ct.h @@ -24,6 +24,11 @@ void xe_guc_ct_print(struct xe_guc_ct *ct, struct drm_printer *p, bool want_ctb) void xe_guc_ct_fixup_messages_with_ggtt(struct xe_guc_ct *ct, s64 ggtt_shift); +static inline bool xe_guc_ct_initialized(struct xe_guc_ct *ct) +{ + return ct->state != XE_GUC_CT_STATE_NOT_INITIALIZED; +} + static inline bool xe_guc_ct_enabled(struct xe_guc_ct *ct) { return ct->state == XE_GUC_CT_STATE_ENABLED; diff --git a/drivers/gpu/drm/xe/xe_guc_submit.c b/drivers/gpu/drm/xe/xe_guc_submit.c index 4a5bcaf83965..55f6385c63a6 100644 --- a/drivers/gpu/drm/xe/xe_guc_submit.c +++ b/drivers/gpu/drm/xe/xe_guc_submit.c @@ -1787,6 +1787,9 @@ int xe_guc_submit_reset_prepare(struct xe_guc *guc) { int ret; + if (!guc->submission_state.initialized) + return 0; + /* * Using an atomic here rather than submission_state.lock as this * function can be called while holding the CT lock (engine reset -- 2.43.0

3 weeks, 4 days

2
1
0 0

[PATCH] drm/xe: Fix memset on iomem

by Lucas De Marchi

It should rather use xe_map_memset() as the BO is created with XE_BO_FLAG_VRAM_IF_DGFX in xe_guc_pc_init(). Fixes: dd08ebf6c352 ("drm/xe: Introduce a new DRM driver for Intel GPUs") Cc: stable(a)vger.kernel.org Signed-off-by: Lucas De Marchi <lucas.demarchi(a)intel.com> --- drivers/gpu/drm/xe/xe_guc_pc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_guc_pc.c b/drivers/gpu/drm/xe/xe_guc_pc.c index 18c6239920355..3beaaa7b25c1b 100644 --- a/drivers/gpu/drm/xe/xe_guc_pc.c +++ b/drivers/gpu/drm/xe/xe_guc_pc.c @@ -1068,7 +1068,7 @@ int xe_guc_pc_start(struct xe_guc_pc *pc) goto out; } - memset(pc->bo->vmap.vaddr, 0, size); + xe_map_memset(xe, &pc->bo->vmap, 0, 0, size); slpc_shared_data_write(pc, header.size, size); earlier = ktime_get();

3 weeks, 4 days

2
1
0 0

[PATCH v4 2/5] scsi: fnic: Fix crash in fnic_wq_cmpl_handler when FDMI times out

by Karan Tilak Kumar

When both the RHBA and RPA FDMI requests time out, fnic reuses a frame to send ABTS for each of them. On send completion, this causes an attempt to free the same frame twice that leads to a crash. Fix crash by allocating separate frames for RHBA and RPA, and modify ABTS logic accordingly. Tested by checking MDS for FDMI information. Tested by using instrumented driver to: Drop PLOGI response Drop RHBA response Drop RPA response Drop RHBA and RPA response Drop PLOGI response + ABTS response Drop RHBA response + ABTS response Drop RPA response + ABTS response Drop RHBA and RPA response + ABTS response for both of them 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> Tested-by: Arun Easi <aeasi(a)cisco.com> Co-developed-by: Arun Easi <aeasi(a)cisco.com> Signed-off-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 | 113 +++++++++++++++++++++++++--------- drivers/scsi/fnic/fnic_fdls.h | 1 + 2 files changed, 86 insertions(+), 28 deletions(-) diff --git a/drivers/scsi/fnic/fdls_disc.c b/drivers/scsi/fnic/fdls_disc.c index c2b6f4eb338e..0ee1b74967b9 100644 --- a/drivers/scsi/fnic/fdls_disc.c +++ b/drivers/scsi/fnic/fdls_disc.c @@ -763,47 +763,69 @@ static void fdls_send_fabric_abts(struct fnic_iport_s *iport) iport->fabric.timer_pending = 1; } -static void fdls_send_fdmi_abts(struct fnic_iport_s *iport) +static uint8_t *fdls_alloc_init_fdmi_abts_frame(struct fnic_iport_s *iport, + uint16_t oxid) { - uint8_t *frame; + struct fc_frame_header *pfdmi_abts; uint8_t d_id[3]; + uint8_t *frame; struct fnic *fnic = iport->fnic; - struct fc_frame_header *pfabric_abts; - unsigned long fdmi_tov; - uint16_t oxid; - uint16_t frame_size = FNIC_ETH_FCOE_HDRS_OFFSET + - sizeof(struct fc_frame_header); frame = fdls_alloc_frame(iport); if (frame == NULL) { FNIC_FCS_DBG(KERN_ERR, fnic->host, fnic->fnic_num, "Failed to allocate frame to send FDMI ABTS"); - return; + return NULL; } - pfabric_abts = (struct fc_frame_header *) (frame + FNIC_ETH_FCOE_HDRS_OFFSET); + pfdmi_abts = (struct fc_frame_header *) (frame + FNIC_ETH_FCOE_HDRS_OFFSET); fdls_init_fabric_abts_frame(frame, iport); hton24(d_id, FC_FID_MGMT_SERV); - FNIC_STD_SET_D_ID(*pfabric_abts, d_id); + FNIC_STD_SET_D_ID(*pfdmi_abts, d_id); + FNIC_STD_SET_OX_ID(*pfdmi_abts, oxid); + + return frame; +} + +static void fdls_send_fdmi_abts(struct fnic_iport_s *iport) +{ + uint8_t *frame; + unsigned long fdmi_tov; + uint16_t frame_size = FNIC_ETH_FCOE_HDRS_OFFSET + + sizeof(struct fc_frame_header); if (iport->fabric.fdmi_pending & FDLS_FDMI_PLOGI_PENDING) { - oxid = iport->active_oxid_fdmi_plogi; - FNIC_STD_SET_OX_ID(*pfabric_abts, oxid); + frame = fdls_alloc_init_fdmi_abts_frame(iport, + iport->active_oxid_fdmi_plogi); + if (frame == NULL) + return; + fnic_send_fcoe_frame(iport, frame, frame_size); } else { if (iport->fabric.fdmi_pending & FDLS_FDMI_REG_HBA_PENDING) { - oxid = iport->active_oxid_fdmi_rhba; - FNIC_STD_SET_OX_ID(*pfabric_abts, oxid); + frame = fdls_alloc_init_fdmi_abts_frame(iport, + iport->active_oxid_fdmi_rhba); + if (frame == NULL) + return; + fnic_send_fcoe_frame(iport, frame, frame_size); } if (iport->fabric.fdmi_pending & FDLS_FDMI_RPA_PENDING) { - oxid = iport->active_oxid_fdmi_rpa; - FNIC_STD_SET_OX_ID(*pfabric_abts, oxid); + frame = fdls_alloc_init_fdmi_abts_frame(iport, + iport->active_oxid_fdmi_rpa); + if (frame == NULL) { + if (iport->fabric.fdmi_pending & FDLS_FDMI_REG_HBA_PENDING) + goto arm_timer; + else + return; + } + fnic_send_fcoe_frame(iport, frame, frame_size); } } +arm_timer: fdmi_tov = jiffies + msecs_to_jiffies(2 * iport->e_d_tov); mod_timer(&iport->fabric.fdmi_timer, round_jiffies(fdmi_tov)); iport->fabric.fdmi_pending |= FDLS_FDMI_ABORT_PENDING; @@ -2244,6 +2266,21 @@ void fdls_fabric_timer_callback(struct timer_list *t) spin_unlock_irqrestore(&fnic->fnic_lock, flags); } +void fdls_fdmi_retry_plogi(struct fnic_iport_s *iport) +{ + struct fnic *fnic = iport->fnic; + + iport->fabric.fdmi_pending = 0; + /* If max retries not exhausted, start over from fdmi plogi */ + if (iport->fabric.fdmi_retry < FDLS_FDMI_MAX_RETRY) { + iport->fabric.fdmi_retry++; + FNIC_FCS_DBG(KERN_INFO, fnic->host, fnic->fnic_num, + "Retry FDMI PLOGI. FDMI retry: %d", + iport->fabric.fdmi_retry); + fdls_send_fdmi_plogi(iport); + } +} + void fdls_fdmi_timer_callback(struct timer_list *t) { struct fnic_fdls_fabric_s *fabric = from_timer(fabric, t, fdmi_timer); @@ -2289,14 +2326,7 @@ void fdls_fdmi_timer_callback(struct timer_list *t) FNIC_FCS_DBG(KERN_INFO, fnic->host, fnic->fnic_num, "fdmi timer callback : 0x%x\n", iport->fabric.fdmi_pending); - iport->fabric.fdmi_pending = 0; - /* If max retries not exhaused, start over from fdmi plogi */ - if (iport->fabric.fdmi_retry < FDLS_FDMI_MAX_RETRY) { - iport->fabric.fdmi_retry++; - FNIC_FCS_DBG(KERN_INFO, fnic->host, fnic->fnic_num, - "retry fdmi timer %d", iport->fabric.fdmi_retry); - fdls_send_fdmi_plogi(iport); - } + fdls_fdmi_retry_plogi(iport); FNIC_FCS_DBG(KERN_INFO, fnic->host, fnic->fnic_num, "fdmi timer callback : 0x%x\n", iport->fabric.fdmi_pending); spin_unlock_irqrestore(&fnic->fnic_lock, flags); @@ -3714,11 +3744,32 @@ static void fdls_process_fdmi_abts_rsp(struct fnic_iport_s *iport, switch (FNIC_FRAME_TYPE(oxid)) { case FNIC_FRAME_TYPE_FDMI_PLOGI: fdls_free_oxid(iport, oxid, &iport->active_oxid_fdmi_plogi); + + iport->fabric.fdmi_pending &= ~FDLS_FDMI_PLOGI_PENDING; + iport->fabric.fdmi_pending &= ~FDLS_FDMI_ABORT_PENDING; break; case FNIC_FRAME_TYPE_FDMI_RHBA: + iport->fabric.fdmi_pending &= ~FDLS_FDMI_REG_HBA_PENDING; + + /* If RPA is still pending, don't turn off ABORT PENDING. + * We count on the timer to detect the ABTS timeout and take + * corrective action. + */ + if (!(iport->fabric.fdmi_pending & FDLS_FDMI_RPA_PENDING)) + iport->fabric.fdmi_pending &= ~FDLS_FDMI_ABORT_PENDING; + fdls_free_oxid(iport, oxid, &iport->active_oxid_fdmi_rhba); break; case FNIC_FRAME_TYPE_FDMI_RPA: + iport->fabric.fdmi_pending &= ~FDLS_FDMI_RPA_PENDING; + + /* If RHBA is still pending, don't turn off ABORT PENDING. + * We count on the timer to detect the ABTS timeout and take + * corrective action. + */ + if (!(iport->fabric.fdmi_pending & FDLS_FDMI_REG_HBA_PENDING)) + iport->fabric.fdmi_pending &= ~FDLS_FDMI_ABORT_PENDING; + fdls_free_oxid(iport, oxid, &iport->active_oxid_fdmi_rpa); break; default: @@ -3728,10 +3779,16 @@ static void fdls_process_fdmi_abts_rsp(struct fnic_iport_s *iport, break; } - timer_delete_sync(&iport->fabric.fdmi_timer); - iport->fabric.fdmi_pending &= ~FDLS_FDMI_ABORT_PENDING; - - fdls_send_fdmi_plogi(iport); + /* + * Only if ABORT PENDING is off, delete the timer, and if no other + * operations are pending, retry FDMI. + * Otherwise, let the timer pop and take the appropriate action. + */ + if (!(iport->fabric.fdmi_pending & FDLS_FDMI_ABORT_PENDING)) { + timer_delete_sync(&iport->fabric.fdmi_timer); + if (!iport->fabric.fdmi_pending) + fdls_fdmi_retry_plogi(iport); + } } static void diff --git a/drivers/scsi/fnic/fnic_fdls.h b/drivers/scsi/fnic/fnic_fdls.h index 8e610b65ad57..531d0b37e450 100644 --- a/drivers/scsi/fnic/fnic_fdls.h +++ b/drivers/scsi/fnic/fnic_fdls.h @@ -394,6 +394,7 @@ void fdls_send_tport_abts(struct fnic_iport_s *iport, bool fdls_delete_tport(struct fnic_iport_s *iport, struct fnic_tport_s *tport); void fdls_fdmi_timer_callback(struct timer_list *t); +void fdls_fdmi_retry_plogi(struct fnic_iport_s *iport); /* fnic_fcs.c */ void fnic_fdls_init(struct fnic *fnic, int usefip); -- 2.47.1

3 weeks, 4 days

1
0
0 0

[PATCH v3 2/5] scsi: fnic: Fix crash in fnic_wq_cmpl_handler when FDMI times out

by Karan Tilak Kumar

When both the RHBA and RPA FDMI requests time out, fnic reuses a frame to send ABTS for each of them. On send completion, this causes an attempt to free the same frame twice that leads to a crash. Fix crash by allocating separate frames for RHBA and RPA, and modify ABTS logic accordingly. Tested by checking MDS for FDMI information. Tested by using instrumented driver to: Drop PLOGI response Drop RHBA response Drop RPA response Drop RHBA and RPA response Drop PLOGI response + ABTS response Drop RHBA response + ABTS response Drop RPA response + ABTS response Drop RHBA and RPA response + ABTS response for both of them 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> Tested-by: Arun Easi <aeasi(a)cisco.com> Co-developed-by: Arun Easi <aeasi(a)cisco.com> Signed-off-by: Arun Easi <aeasi(a)cisco.com> Tested-by: Karan Tilak Kumar <kartilak(a)cisco.com> Cc: <stable(a)vger.kernel.org> # 6.14.x Please see patch description Signed-off-by: Karan Tilak Kumar <kartilak(a)cisco.com> --- drivers/scsi/fnic/fdls_disc.c | 113 +++++++++++++++++++++++++--------- drivers/scsi/fnic/fnic_fdls.h | 1 + 2 files changed, 86 insertions(+), 28 deletions(-) diff --git a/drivers/scsi/fnic/fdls_disc.c b/drivers/scsi/fnic/fdls_disc.c index c2b6f4eb338e..0ee1b74967b9 100644 --- a/drivers/scsi/fnic/fdls_disc.c +++ b/drivers/scsi/fnic/fdls_disc.c @@ -763,47 +763,69 @@ static void fdls_send_fabric_abts(struct fnic_iport_s *iport) iport->fabric.timer_pending = 1; } -static void fdls_send_fdmi_abts(struct fnic_iport_s *iport) +static uint8_t *fdls_alloc_init_fdmi_abts_frame(struct fnic_iport_s *iport, + uint16_t oxid) { - uint8_t *frame; + struct fc_frame_header *pfdmi_abts; uint8_t d_id[3]; + uint8_t *frame; struct fnic *fnic = iport->fnic; - struct fc_frame_header *pfabric_abts; - unsigned long fdmi_tov; - uint16_t oxid; - uint16_t frame_size = FNIC_ETH_FCOE_HDRS_OFFSET + - sizeof(struct fc_frame_header); frame = fdls_alloc_frame(iport); if (frame == NULL) { FNIC_FCS_DBG(KERN_ERR, fnic->host, fnic->fnic_num, "Failed to allocate frame to send FDMI ABTS"); - return; + return NULL; } - pfabric_abts = (struct fc_frame_header *) (frame + FNIC_ETH_FCOE_HDRS_OFFSET); + pfdmi_abts = (struct fc_frame_header *) (frame + FNIC_ETH_FCOE_HDRS_OFFSET); fdls_init_fabric_abts_frame(frame, iport); hton24(d_id, FC_FID_MGMT_SERV); - FNIC_STD_SET_D_ID(*pfabric_abts, d_id); + FNIC_STD_SET_D_ID(*pfdmi_abts, d_id); + FNIC_STD_SET_OX_ID(*pfdmi_abts, oxid); + + return frame; +} + +static void fdls_send_fdmi_abts(struct fnic_iport_s *iport) +{ + uint8_t *frame; + unsigned long fdmi_tov; + uint16_t frame_size = FNIC_ETH_FCOE_HDRS_OFFSET + + sizeof(struct fc_frame_header); if (iport->fabric.fdmi_pending & FDLS_FDMI_PLOGI_PENDING) { - oxid = iport->active_oxid_fdmi_plogi; - FNIC_STD_SET_OX_ID(*pfabric_abts, oxid); + frame = fdls_alloc_init_fdmi_abts_frame(iport, + iport->active_oxid_fdmi_plogi); + if (frame == NULL) + return; + fnic_send_fcoe_frame(iport, frame, frame_size); } else { if (iport->fabric.fdmi_pending & FDLS_FDMI_REG_HBA_PENDING) { - oxid = iport->active_oxid_fdmi_rhba; - FNIC_STD_SET_OX_ID(*pfabric_abts, oxid); + frame = fdls_alloc_init_fdmi_abts_frame(iport, + iport->active_oxid_fdmi_rhba); + if (frame == NULL) + return; + fnic_send_fcoe_frame(iport, frame, frame_size); } if (iport->fabric.fdmi_pending & FDLS_FDMI_RPA_PENDING) { - oxid = iport->active_oxid_fdmi_rpa; - FNIC_STD_SET_OX_ID(*pfabric_abts, oxid); + frame = fdls_alloc_init_fdmi_abts_frame(iport, + iport->active_oxid_fdmi_rpa); + if (frame == NULL) { + if (iport->fabric.fdmi_pending & FDLS_FDMI_REG_HBA_PENDING) + goto arm_timer; + else + return; + } + fnic_send_fcoe_frame(iport, frame, frame_size); } } +arm_timer: fdmi_tov = jiffies + msecs_to_jiffies(2 * iport->e_d_tov); mod_timer(&iport->fabric.fdmi_timer, round_jiffies(fdmi_tov)); iport->fabric.fdmi_pending |= FDLS_FDMI_ABORT_PENDING; @@ -2244,6 +2266,21 @@ void fdls_fabric_timer_callback(struct timer_list *t) spin_unlock_irqrestore(&fnic->fnic_lock, flags); } +void fdls_fdmi_retry_plogi(struct fnic_iport_s *iport) +{ + struct fnic *fnic = iport->fnic; + + iport->fabric.fdmi_pending = 0; + /* If max retries not exhausted, start over from fdmi plogi */ + if (iport->fabric.fdmi_retry < FDLS_FDMI_MAX_RETRY) { + iport->fabric.fdmi_retry++; + FNIC_FCS_DBG(KERN_INFO, fnic->host, fnic->fnic_num, + "Retry FDMI PLOGI. FDMI retry: %d", + iport->fabric.fdmi_retry); + fdls_send_fdmi_plogi(iport); + } +} + void fdls_fdmi_timer_callback(struct timer_list *t) { struct fnic_fdls_fabric_s *fabric = from_timer(fabric, t, fdmi_timer); @@ -2289,14 +2326,7 @@ void fdls_fdmi_timer_callback(struct timer_list *t) FNIC_FCS_DBG(KERN_INFO, fnic->host, fnic->fnic_num, "fdmi timer callback : 0x%x\n", iport->fabric.fdmi_pending); - iport->fabric.fdmi_pending = 0; - /* If max retries not exhaused, start over from fdmi plogi */ - if (iport->fabric.fdmi_retry < FDLS_FDMI_MAX_RETRY) { - iport->fabric.fdmi_retry++; - FNIC_FCS_DBG(KERN_INFO, fnic->host, fnic->fnic_num, - "retry fdmi timer %d", iport->fabric.fdmi_retry); - fdls_send_fdmi_plogi(iport); - } + fdls_fdmi_retry_plogi(iport); FNIC_FCS_DBG(KERN_INFO, fnic->host, fnic->fnic_num, "fdmi timer callback : 0x%x\n", iport->fabric.fdmi_pending); spin_unlock_irqrestore(&fnic->fnic_lock, flags); @@ -3714,11 +3744,32 @@ static void fdls_process_fdmi_abts_rsp(struct fnic_iport_s *iport, switch (FNIC_FRAME_TYPE(oxid)) { case FNIC_FRAME_TYPE_FDMI_PLOGI: fdls_free_oxid(iport, oxid, &iport->active_oxid_fdmi_plogi); + + iport->fabric.fdmi_pending &= ~FDLS_FDMI_PLOGI_PENDING; + iport->fabric.fdmi_pending &= ~FDLS_FDMI_ABORT_PENDING; break; case FNIC_FRAME_TYPE_FDMI_RHBA: + iport->fabric.fdmi_pending &= ~FDLS_FDMI_REG_HBA_PENDING; + + /* If RPA is still pending, don't turn off ABORT PENDING. + * We count on the timer to detect the ABTS timeout and take + * corrective action. + */ + if (!(iport->fabric.fdmi_pending & FDLS_FDMI_RPA_PENDING)) + iport->fabric.fdmi_pending &= ~FDLS_FDMI_ABORT_PENDING; + fdls_free_oxid(iport, oxid, &iport->active_oxid_fdmi_rhba); break; case FNIC_FRAME_TYPE_FDMI_RPA: + iport->fabric.fdmi_pending &= ~FDLS_FDMI_RPA_PENDING; + + /* If RHBA is still pending, don't turn off ABORT PENDING. + * We count on the timer to detect the ABTS timeout and take + * corrective action. + */ + if (!(iport->fabric.fdmi_pending & FDLS_FDMI_REG_HBA_PENDING)) + iport->fabric.fdmi_pending &= ~FDLS_FDMI_ABORT_PENDING; + fdls_free_oxid(iport, oxid, &iport->active_oxid_fdmi_rpa); break; default: @@ -3728,10 +3779,16 @@ static void fdls_process_fdmi_abts_rsp(struct fnic_iport_s *iport, break; } - timer_delete_sync(&iport->fabric.fdmi_timer); - iport->fabric.fdmi_pending &= ~FDLS_FDMI_ABORT_PENDING; - - fdls_send_fdmi_plogi(iport); + /* + * Only if ABORT PENDING is off, delete the timer, and if no other + * operations are pending, retry FDMI. + * Otherwise, let the timer pop and take the appropriate action. + */ + if (!(iport->fabric.fdmi_pending & FDLS_FDMI_ABORT_PENDING)) { + timer_delete_sync(&iport->fabric.fdmi_timer); + if (!iport->fabric.fdmi_pending) + fdls_fdmi_retry_plogi(iport); + } } static void diff --git a/drivers/scsi/fnic/fnic_fdls.h b/drivers/scsi/fnic/fnic_fdls.h index 8e610b65ad57..531d0b37e450 100644 --- a/drivers/scsi/fnic/fnic_fdls.h +++ b/drivers/scsi/fnic/fnic_fdls.h @@ -394,6 +394,7 @@ void fdls_send_tport_abts(struct fnic_iport_s *iport, bool fdls_delete_tport(struct fnic_iport_s *iport, struct fnic_tport_s *tport); void fdls_fdmi_timer_callback(struct timer_list *t); +void fdls_fdmi_retry_plogi(struct fnic_iport_s *iport); /* fnic_fcs.c */ void fnic_fdls_init(struct fnic *fnic, int usefip); -- 2.47.1

3 weeks, 4 days

3
3
0 0

[PATCH net] net_sched: sch_sfq: reject invalid perturb period

by Eric Dumazet

Gerrard Tai reported that SFQ perturb_period has no range check yet, and this can be used to trigger a race condition fixed in a separate patch. We want to make sure ctl->perturb_period * HZ will not overflow and is positive. Tested: tc qd add dev lo root sfq perturb -10 # negative value : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 1000000000 # too big : error Error: sch_sfq: invalid perturb period. tc qd add dev lo root sfq perturb 2000000 # acceptable value tc -s -d qd sh dev lo qdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Signed-off-by: Eric Dumazet <edumazet(a)google.com> Cc: stable(a)vger.kernel.org --- net/sched/sch_sfq.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/net/sched/sch_sfq.c b/net/sched/sch_sfq.c index 77fa02f2bfcd56a36815199aa2e7987943ea226f..a8cca549b5a2eb2407949560c2b6b658fb7a581f 100644 --- a/net/sched/sch_sfq.c +++ b/net/sched/sch_sfq.c @@ -656,6 +656,14 @@ static int sfq_change(struct Qdisc *sch, struct nlattr *opt, NL_SET_ERR_MSG_MOD(extack, "invalid quantum"); return -EINVAL; } + + if (ctl->perturb_period < 0 || + ctl->perturb_period > INT_MAX / HZ) { + NL_SET_ERR_MSG_MOD(extack, "invalid perturb period"); + return -EINVAL; + } + perturb_period = ctl->perturb_period * HZ; + if (ctl_v1 && !red_check_params(ctl_v1->qth_min, ctl_v1->qth_max, ctl_v1->Wlog, ctl_v1->Scell_log, NULL)) return -EINVAL; @@ -672,14 +680,12 @@ static int sfq_change(struct Qdisc *sch, struct nlattr *opt, headdrop = q->headdrop; maxdepth = q->maxdepth; maxflows = q->maxflows; - perturb_period = q->perturb_period; quantum = q->quantum; flags = q->flags; /* update and validate configuration */ if (ctl->quantum) quantum = ctl->quantum; - perturb_period = ctl->perturb_period * HZ; if (ctl->flows) maxflows = min_t(u32, ctl->flows, SFQ_MAX_FLOWS); if (ctl->divisor) { -- 2.50.0.rc0.642.g800a2b2222-goog

3 weeks, 4 days

3
2
0 0

FAILED: patch "[PATCH] iio: dac: ad3552r-common: fix ad3541/2r ranges" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x 1e758b613212b6964518a67939535910b5aee831 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025021010-antarctic-untried-a72b@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 1e758b613212b6964518a67939535910b5aee831 Mon Sep 17 00:00:00 2001 From: Angelo Dureghello <adureghello(a)baylibre.com> Date: Wed, 8 Jan 2025 18:29:15 +0100 Subject: [PATCH] iio: dac: ad3552r-common: fix ad3541/2r ranges Fix ad3541/2r voltage ranges to be as per ad3542r datasheet, rev. C, table 38 (page 57). The wrong ad354xr ranges was generating erroneous Vpp output. In more details: - fix wrong number of ranges, they are 5 ranges, not 6, - remove non-existent 0-3V range, - adjust order, since ad3552r_find_range() get a wrong index, producing a wrong Vpp as output. Retested all the ranges on real hardware, EVALAD3542RFMCZ: adi,output-range-microvolt (fdt): <(000000) (2500000)>; ok (Rfbx1, switch 10) <(000000) (5000000)>; ok (Rfbx1, switch 10) <(000000) (10000000)>; ok (Rfbx1, switch 10) <(-5000000) (5000000)>; ok (Rfbx2, switch +/- 5) <(-2500000) (7500000)>; ok (Rfbx2, switch -2.5/7.5) Fixes: 8f2b54824b28 ("drivers:iio:dac: Add AD3552R driver support") Signed-off-by: Angelo Dureghello <adureghello(a)baylibre.com> Reviewed-by: David Lechner <dlechner(a)baylibre.com> Link: https://patch.msgid.link/20250108-wip-bl-ad3552r-axi-v0-iio-testing-carlos-… Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> diff --git a/drivers/iio/dac/ad3552r-common.c b/drivers/iio/dac/ad3552r-common.c index 0f495df2e5ce..03e0864f5084 100644 --- a/drivers/iio/dac/ad3552r-common.c +++ b/drivers/iio/dac/ad3552r-common.c @@ -22,11 +22,10 @@ EXPORT_SYMBOL_NS_GPL(ad3552r_ch_ranges, "IIO_AD3552R"); const s32 ad3542r_ch_ranges[AD3542R_MAX_RANGES][2] = { [AD3542R_CH_OUTPUT_RANGE_0__2P5V] = { 0, 2500 }, - [AD3542R_CH_OUTPUT_RANGE_0__3V] = { 0, 3000 }, [AD3542R_CH_OUTPUT_RANGE_0__5V] = { 0, 5000 }, [AD3542R_CH_OUTPUT_RANGE_0__10V] = { 0, 10000 }, - [AD3542R_CH_OUTPUT_RANGE_NEG_2P5__7P5V] = { -2500, 7500 }, - [AD3542R_CH_OUTPUT_RANGE_NEG_5__5V] = { -5000, 5000 } + [AD3542R_CH_OUTPUT_RANGE_NEG_5__5V] = { -5000, 5000 }, + [AD3542R_CH_OUTPUT_RANGE_NEG_2P5__7P5V] = { -2500, 7500 } }; EXPORT_SYMBOL_NS_GPL(ad3542r_ch_ranges, "IIO_AD3552R"); diff --git a/drivers/iio/dac/ad3552r.h b/drivers/iio/dac/ad3552r.h index fd5a3dfd1d1c..4b5581039ae9 100644 --- a/drivers/iio/dac/ad3552r.h +++ b/drivers/iio/dac/ad3552r.h @@ -131,7 +131,7 @@ #define AD3552R_CH1_ACTIVE BIT(1) #define AD3552R_MAX_RANGES 5 -#define AD3542R_MAX_RANGES 6 +#define AD3542R_MAX_RANGES 5 #define AD3552R_QUAD_SPI 2 extern const s32 ad3552r_ch_ranges[AD3552R_MAX_RANGES][2]; @@ -189,16 +189,14 @@ enum ad3552r_ch_vref_select { enum ad3542r_ch_output_range { /* Range from 0 V to 2.5 V. Requires Rfb1x connection */ AD3542R_CH_OUTPUT_RANGE_0__2P5V, - /* Range from 0 V to 3 V. Requires Rfb1x connection */ - AD3542R_CH_OUTPUT_RANGE_0__3V, /* Range from 0 V to 5 V. Requires Rfb1x connection */ AD3542R_CH_OUTPUT_RANGE_0__5V, /* Range from 0 V to 10 V. Requires Rfb2x connection */ AD3542R_CH_OUTPUT_RANGE_0__10V, - /* Range from -2.5 V to 7.5 V. Requires Rfb2x connection */ - AD3542R_CH_OUTPUT_RANGE_NEG_2P5__7P5V, /* Range from -5 V to 5 V. Requires Rfb2x connection */ AD3542R_CH_OUTPUT_RANGE_NEG_5__5V, + /* Range from -2.5 V to 7.5 V. Requires Rfb2x connection */ + AD3542R_CH_OUTPUT_RANGE_NEG_2P5__7P5V, }; enum ad3552r_ch_output_range {

3 weeks, 4 days

3
4
0 0

[PATCH v2 1/3] mm/huge_memory: don't ignore queried cachemode in vmf_insert_pfn_pud()

by David Hildenbrand

We setup the cache mode but ... don't forward the updated pgprot to insert_pfn_pud(). Only a problem on x86-64 PAT when mapping PFNs using PUDs that require a special cachemode. Fix it by using the proper pgprot where the cachemode was setup. Identified by code inspection. Fixes: 7b806d229ef1 ("mm: remove vmf_insert_pfn_xxx_prot() for huge page-table entries") Cc: <stable(a)vger.kernel.org> Signed-off-by: David Hildenbrand <david(a)redhat.com> --- mm/huge_memory.c | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index d3e66136e41a3..49b98082c5401 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1516,10 +1516,9 @@ static pud_t maybe_pud_mkwrite(pud_t pud, struct vm_area_struct *vma) } static void insert_pfn_pud(struct vm_area_struct *vma, unsigned long addr, - pud_t *pud, pfn_t pfn, bool write) + pud_t *pud, pfn_t pfn, pgprot_t prot, bool write) { struct mm_struct *mm = vma->vm_mm; - pgprot_t prot = vma->vm_page_prot; pud_t entry; if (!pud_none(*pud)) { @@ -1581,7 +1580,7 @@ vm_fault_t vmf_insert_pfn_pud(struct vm_fault *vmf, pfn_t pfn, bool write) pfnmap_setup_cachemode_pfn(pfn_t_to_pfn(pfn), &pgprot); ptl = pud_lock(vma->vm_mm, vmf->pud); - insert_pfn_pud(vma, addr, vmf->pud, pfn, write); + insert_pfn_pud(vma, addr, vmf->pud, pfn, pgprot, write); spin_unlock(ptl); return VM_FAULT_NOPAGE; @@ -1625,7 +1624,7 @@ vm_fault_t vmf_insert_folio_pud(struct vm_fault *vmf, struct folio *folio, add_mm_counter(mm, mm_counter_file(folio), HPAGE_PUD_NR); } insert_pfn_pud(vma, addr, vmf->pud, pfn_to_pfn_t(folio_pfn(folio)), - write); + vma->vm_page_prot, write); spin_unlock(ptl); return VM_FAULT_NOPAGE; -- 2.49.0

3 weeks, 4 days

5
9
0 0

[PATCH v3] arm64: Restrict pagetable teardown to avoid false warning

by Dev Jain

Commit 9c006972c3fe removes the pxd_present() checks because the caller checks pxd_present(). But, in case of vmap_try_huge_pud(), the caller only checks pud_present(); pud_free_pmd_page() recurses on each pmd through pmd_free_pte_page(), wherein the pmd may be none. Thus it is possible to hit a warning in the latter, since pmd_none => !pmd_table(). Thus, add a pmd_present() check in pud_free_pmd_page(). This problem was found by code inspection. Fixes: 9c006972c3fe (arm64: mmu: drop pXd_present() checks from pXd_free_pYd_table()) Cc: <stable(a)vger.kernel.org> Reported-by: Ryan Roberts <ryan.roberts(a)arm.com> Acked-by: David Hildenbrand <david(a)redhat.com> Signed-off-by: Dev Jain <dev.jain(a)arm.com> --- This patch is based on 6.15-rc6. v2->v3: - Use pmdp_get() v1->v2: - Enforce check in caller arch/arm64/mm/mmu.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c index ea6695d53fb9..5a9bf291c649 100644 --- a/arch/arm64/mm/mmu.c +++ b/arch/arm64/mm/mmu.c @@ -1286,7 +1286,8 @@ int pud_free_pmd_page(pud_t *pudp, unsigned long addr) next = addr; end = addr + PUD_SIZE; do { - pmd_free_pte_page(pmdp, next); + if (pmd_present(pmdp_get(pmdp))) + pmd_free_pte_page(pmdp, next); } while (pmdp++, next += PMD_SIZE, next != end); pud_clear(pudp); -- 2.30.2

3 weeks, 4 days

5
7
0 0

[PATCH v2 0/2] Samsung Exynos 7870 DECON driver support

by Kaustabh Chakraborty

This patch series aims at adding support for Exynos7870's DECON in the Exynos7 DECON driver. It introduces a driver data struct so that support for DECON on other SoCs can be added to it in the future. It also fixes a few bugs in the driver, such as functions receiving bad pointers. Tested on Samsung Galaxy J7 Prime (samsung-on7xelte), Samsung Galaxy A2 Core (samsung-a2corelte), and Samsung Galaxy J6 (samsung-j6lte). Signed-off-by: Kaustabh Chakraborty <kauschluss(a)disroot.org> --- Changes in v2: - Add a new commit to prevent an occasional panic under circumstances. - Rewrite and redo [v1 2/6] to be a more sensible commit. - Link to v1: https://lore.kernel.org/r/20240919-exynosdrm-decon-v1-0-6c5861c1cb04@disroo… --- Kaustabh Chakraborty (2): drm/exynos: exynos7_drm_decon: fix call of decon_commit() drm/exynos: exynos7_drm_decon: add vblank check in IRQ handling drivers/gpu/drm/exynos/exynos7_drm_decon.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- base-commit: 0bb71d301869446810a0b13d3da290bd455d7c78 change-id: 20240917-exynosdrm-decon-4c228dd1d2bf Best regards, -- Kaustabh Chakraborty <kauschluss(a)disroot.org>

3 weeks, 4 days

1
2
0 0

[PATCH] net: pfcp: fix typo in message_priority field name

by RubenKelevra

Fix 'message_priprity' typo to 'message_priority' in big endian bitfield definition. This typo breaks compilation on big endian architectures. Fixes: 6dd514f48110 ("pfcp: always set pfcp metadata") Cc: stable(a)vger.kernel.org # commit 6dd514f48110 ("pfcp: always set pfcp metadata") Signed-off-by: RubenKelevra <rubenkelevra(a)gmail.com> --- include/net/pfcp.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/net/pfcp.h b/include/net/pfcp.h index af14f970b80e1..639553797d3e4 100644 --- a/include/net/pfcp.h +++ b/include/net/pfcp.h @@ -45,7 +45,7 @@ struct pfcphdr_session { reserved:4; #elif defined(__BIG_ENDIAN_BITFIELD) u8 reserved:4, - message_priprity:4; + message_priority:4; #else #error "Please fix <asm/byteorder>" #endif -- 2.49.0

3 weeks, 4 days

4
4
0 0

[PATCH v2] iommu/amd: Fix geometry.aperture_end for V2 tables

by Jason Gunthorpe

The AMD IOMMU documentation seems pretty clear that the V2 table follows the normal CPU expectation of sign extension. This is shown in Figure 25: AMD64 Long Mode 4-Kbyte Page Address Translation Where bits Sign-Extend [63:57] == [56]. This is typical for x86 which would have three regions in the page table: lower, non-canonical, upper. The manual describes that the V1 table does not sign extend in section 2.2.4 Sharing AMD64 Processor and IOMMU Page Tables GPA-to-SPA Further, Vasant has checked this and indicates the HW has an addtional behavior that the manual does not yet describe. The AMDv2 table does not have the sign extended behavior when attached to PASID 0, which may explain why this has gone unnoticed. The iommu domain geometry does not directly support sign extended page tables. The driver should report only one of the lower/upper spaces. Solve this by removing the top VA bit from the geometry to use only the lower space. This will also make the iommu_domain work consistently on all PASID 0 and PASID != 1. Adjust dma_max_address() to remove the top VA bit. It now returns: 5 Level: Before 0x1ffffffffffffff After 0x0ffffffffffffff 4 Level: Before 0xffffffffffff After 0x7fffffffffff Fixes: 11c439a19466 ("iommu/amd/pgtbl_v2: Fix domain max address") Link: https://lore.kernel.org/all/8858d4d6-d360-4ef0-935c-bfd13ea54f42@amd.com/ Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> --- drivers/iommu/amd/iommu.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) v2: - Revise the commit message and comment with the new information from Vasant. v1: https://patch.msgid.link/r/0-v1-6925ece6b623+296-amdv2_geo_jgg@nvidia.com diff --git a/drivers/iommu/amd/iommu.c b/drivers/iommu/amd/iommu.c index 3117d99cf83d0d..1baa9d3583f369 100644 --- a/drivers/iommu/amd/iommu.c +++ b/drivers/iommu/amd/iommu.c @@ -2526,8 +2526,21 @@ static inline u64 dma_max_address(enum protection_domain_mode pgtable) if (pgtable == PD_MODE_V1) return ~0ULL; - /* V2 with 4/5 level page table */ - return ((1ULL << PM_LEVEL_SHIFT(amd_iommu_gpt_level)) - 1); + /* + * V2 with 4/5 level page table. Note that "2.2.6.5 AMD64 4-Kbyte Page + * Translation" shows that the V2 table sign extends the top of the + * address space creating a reserved region in the middle of the + * translation, just like the CPU does. Further Vasant says the docs are + * incomplete and this only applies to non-zero PASIDs. If the AMDv2 + * page table is assigned to the 0 PASID then there is no sign extension + * check. + * + * Since the IOMMU must have a fixed geometry, and the core code does + * not understand sign extended addressing, we have to chop off the high + * bit to get consistent behavior with attachments of the domain to any + * PASID. + */ + return ((1ULL << (PM_LEVEL_SHIFT(amd_iommu_gpt_level) - 1)) - 1); } static bool amd_iommu_hd_support(struct amd_iommu *iommu) base-commit: eb328711b15b17987021dbb674f446b7b008dca5 -- 2.43.0

3 weeks, 4 days

3
3
0 0

[PATCH v2] s390/pkey: prevent overflow in size calculation for memdup_user()

by Fedor Pchelkin

Number of apqn target list entries contained in 'nr_apqns' variable is determined by userspace via an ioctl call so the result of the product in calculation of size passed to memdup_user() may overflow. In this case the actual size of the allocated area and the value describing it won't be in sync leading to various types of unpredictable behaviour later. Use a proper memdup_array_user() helper which returns an error if an overflow is detected. Note that it is different from when nr_apqns is initially zero - that case is considered valid and should be handled in subsequent pkey_handler implementations. Found by Linux Verification Center (linuxtesting.org). Fixes: f2bbc96e7cfa ("s390/pkey: add CCA AES cipher key support") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- v2: use memdup_array_user() helper (Heiko Carstens) drivers/s390/crypto/pkey_api.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/s390/crypto/pkey_api.c b/drivers/s390/crypto/pkey_api.c index cef60770f68b..b3fcdcae379e 100644 --- a/drivers/s390/crypto/pkey_api.c +++ b/drivers/s390/crypto/pkey_api.c @@ -86,7 +86,7 @@ static void *_copy_apqns_from_user(void __user *uapqns, size_t nr_apqns) if (!uapqns || nr_apqns == 0) return NULL; - return memdup_user(uapqns, nr_apqns * sizeof(struct pkey_apqn)); + return memdup_array_user(uapqns, nr_apqns, sizeof(struct pkey_apqn)); } static int pkey_ioctl_genseck(struct pkey_genseck __user *ugs) -- 2.49.0

3 weeks, 4 days

4
3
0 0

Qualcomm Snapdragon <SM6375>

by Alan Ye

The Qualcomm SM6375 processor is a 7nm process SoC for the mid-range market with the following features: CPU: Eight-core design, including high-performance Kryo 670 core and efficient Kryo 265 core, optimized performance and energy efficiency. GPU: Equipped with Adreno 642L GPU, supporting high-quality graphics and gaming experience. AI Engine: Integrated Qualcomm AI engine to enhance intelligent features such as voice recognition and image processing. Connectivity: Supports modern wireless standards such as 5G, Wi-Fi 6 and Bluetooth 5.2. Multimedia: Supports 4K video encoding and decoding Mainly used in mid-to-high-end smartphones, tablets and some IoT devices, suitable for users who need to balance cost performance and performance. .# Part Number Manufacturer Date Code Quantity Unit Price Lead Time Condition (PCS) USD/Each one 1 SM-6375-1-PSP837-TR-00-0-AB QUALCOMM 2023+ 12000pcs US$18.00/pcs 7days New & original - stock 2 PM-6375-0-FOWNSP144-TR-01-0；TR-01-1 QUALCOMM 2023+ 12000pcs US$1.00/pcs 3 PMR-735A-0-WLNSP48-TR-05-0,TR-05-1 QUALCOMM 2023+ 12000pcs US$0.85/pcs 4 PMK-8003-0-FOWPSP36-TR-01-0 QUALCOMM 2023+ 12000pcs US$0.24/pcs 5 SDR-735-0-PSP219B-TR-01-0；TR-01-1 QUALCOMM 2023+ 12000pcs US$2.50/pcs 6 WCD-9370-0-WLPSP55-TR-01-0;TR-01-4 QUALCOMM 2023+ 12000pcs US$0.50/pcs 7 WCN-3988-0-82BWLPSP-TR-00-0 QUALCOMM 2023+ 12000pcs US$3.50/pcs 8 QET-6105-0-WLNSP24B-TR-00-1 QUALCOMM 2023+ 12000pcs US$1.20/pcs 9 QET4101-0-12WLNSP-TR-00-0 QUALCOMM 2022+ 12000pcs US$0.21/pcs These materials are sold as a set for $28/usd, and are guaranteed to be authentic. If you need other Qualcomm materials, please feel free to contact me Stay in tune with product evolutions—tap . Keep Receiving Notices Feel like taking a break? Select Configure Your Mailing.

3 weeks, 4 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror