August 2024 - Linux-stable-mirror

[PATCH v2] x86/fpu: Avoid writing LBR bit to IA32_XSS unless supported

by Mitchell Levy via B4 Relay

From: Mitchell Levy <levymitchell0(a)gmail.com> When computing which xfeatures are available, make sure that LBR is only present if both LBR is supported in general, as well as by XSAVES. There are two distinct CPU features related to the use of XSAVES as it applies to LBR: whether LBR is itself supported (strictly speaking, I'm not sure that this is necessary to check though it's certainly a good sanity check), and whether XSAVES supports LBR (see sections 13.2 and 13.5.12 of the Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 1). Currently, the LBR subsystem correctly checks both (see intel_pmu_arch_lbr_init), however the xstate initialization subsystem does not. When calculating what value to place in the IA32_XSS MSR, xfeatures_mask_independent only checks whether LBR support is present, not whether XSAVES supports LBR. If XSAVES does not support LBR, this write causes #GP, leaving the state of IA32_XSS unchanged (i.e., set to zero, as its not written with other values, and its default value is zero out of RESET per section 13.3 of the arch manual). Then, the next time XRSTORS is used to restore supervisor state, it will fail with #GP (because the RFBM has zero for all supervisor features, which does not match the XCOMP_BV field). In particular, XFEATURE_MASK_FPSTATE includes supervisor features, so setting up the FPU will cause a #GP. This results in a call to fpu_reset_from_exception_fixup, which by the same process results in another #GP. Eventually this causes the kernel to run out of stack space and #DF. Fixes: f0dccc9da4c0 ("x86/fpu/xstate: Support dynamic supervisor feature for LBR") Cc: stable(a)vger.kernel.org Signed-off-by: Mitchell Levy <levymitchell0(a)gmail.com> --- Changes in v2: - Corrected Fixes tag (thanks tglx) - Properly check for XSAVES support of LBR (thanks tglx) - Link to v1: https://lore.kernel.org/r/20240808-xsave-lbr-fix-v1-1-a223806c83e7@gmail.com --- arch/x86/include/asm/fpu/types.h | 7 +++++++ arch/x86/kernel/fpu/xstate.c | 3 +++ arch/x86/kernel/fpu/xstate.h | 4 ++-- 3 files changed, 12 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/fpu/types.h b/arch/x86/include/asm/fpu/types.h index eb17f31b06d2..de16862bf230 100644 --- a/arch/x86/include/asm/fpu/types.h +++ b/arch/x86/include/asm/fpu/types.h @@ -591,6 +591,13 @@ struct fpu_state_config { * even without XSAVE support, i.e. legacy features FP + SSE */ u64 legacy_features; + /* + * @independent_features: + * + * Features that are supported by XSAVES, but not managed as part of + * the FPU core, such as LBR + */ + u64 independent_features; }; /* FPU state configuration information */ diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index c5a026fee5e0..1339f8328db5 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -788,6 +788,9 @@ void __init fpu__init_system_xstate(unsigned int legacy_size) goto out_disable; } + fpu_kernel_cfg.independent_features = fpu_kernel_cfg.max_features & + XFEATURE_MASK_INDEPENDENT; + /* * Clear XSAVE features that are disabled in the normal CPUID. */ diff --git a/arch/x86/kernel/fpu/xstate.h b/arch/x86/kernel/fpu/xstate.h index 2ee0b9c53dcc..afb404cd2059 100644 --- a/arch/x86/kernel/fpu/xstate.h +++ b/arch/x86/kernel/fpu/xstate.h @@ -62,9 +62,9 @@ static inline u64 xfeatures_mask_supervisor(void) static inline u64 xfeatures_mask_independent(void) { if (!cpu_feature_enabled(X86_FEATURE_ARCH_LBR)) - return XFEATURE_MASK_INDEPENDENT & ~XFEATURE_MASK_LBR; + return fpu_kernel_cfg.independent_features & ~XFEATURE_MASK_LBR; - return XFEATURE_MASK_INDEPENDENT; + return fpu_kernel_cfg.independent_features; } /* XSAVE/XRSTOR wrapper functions */ --- base-commit: de9c2c66ad8e787abec7c9d7eff4f8c3cdd28aed change-id: 20240807-xsave-lbr-fix-02d52f641653 Best regards, -- Mitchell Levy <levymitchell0(a)gmail.com>

11 months, 1 week

3
3
0 0

[PATCH RESEND] drm/nouveau: fix a possible null pointer dereference

by Ma Ke

In ch7006_encoder_get_modes(), the return value of drm_mode_duplicate() is used directly in drm_mode_probed_add(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable(a)vger.kernel.org Fixes: 6ee738610f41 ("drm/nouveau: Add DRM driver for NVIDIA GPUs") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/gpu/drm/i2c/ch7006_drv.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c index 131512a5f3bd..48bf6e4e8bdb 100644 --- a/drivers/gpu/drm/i2c/ch7006_drv.c +++ b/drivers/gpu/drm/i2c/ch7006_drv.c @@ -229,6 +229,7 @@ static int ch7006_encoder_get_modes(struct drm_encoder *encoder, { struct ch7006_priv *priv = to_ch7006_priv(encoder); const struct ch7006_mode *mode; + struct drm_display_mode *encoder_mode = NULL; int n = 0; for (mode = ch7006_modes; mode->mode.clock; mode++) { @@ -236,8 +237,11 @@ static int ch7006_encoder_get_modes(struct drm_encoder *encoder, ~mode->valid_norms & 1<<priv->norm) continue; - drm_mode_probed_add(connector, - drm_mode_duplicate(encoder->dev, &mode->mode)); + encoder_mode = drm_mode_duplicate(encoder->dev, &mode->mode); + if (!encoder_mode) + return 0; + + drm_mode_probed_add(connector, encoder_mode); n++; } -- 2.25.1

11 months, 1 week

1
0
0 0

[PATCH v2 RESEND] dmaengine: moxart: handle irq_of_parse_and_map() errors

by Ma Ke

Zero and negative number is not a valid IRQ for in-kernel code and the irq_of_parse_and_map() function returns zero on error. So this check for valid IRQs should only accept values > 0. Cc: stable(a)vger.kernel.org Fixes: 2d9e31b9412c ("dmaengine: moxart: remove NO_IRQ") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/dma/moxart-dma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/moxart-dma.c b/drivers/dma/moxart-dma.c index 66dc6d31b603..16dd3c5aba4d 100644 --- a/drivers/dma/moxart-dma.c +++ b/drivers/dma/moxart-dma.c @@ -568,7 +568,7 @@ static int moxart_probe(struct platform_device *pdev) return -ENOMEM; irq = irq_of_parse_and_map(node, 0); - if (!irq) { + if (irq <= 0) { dev_err(dev, "no IRQ resource\n"); return -EINVAL; } -- 2.25.1

11 months, 1 week

1
0
0 0

[PATCH] arm64: dts: rockchip: Raise Pinebook Pro's panel backlight PWM frequency

by Dragan Simic

Increase the frequency of the PWM signal that drives the LED backlight of the Pinebook Pro's panel, from about 1.35 KHz (which equals to the PWM period of 740,740 ns), to exactly 8 kHz (which equals to the PWM period of 125,000 ns). Using a higher PWM frequency for the panel backlight, which reduces the flicker, can only be beneficial to the end users' eyes. On top of that, increasing the backlight PWM signal frequency reportedly eliminates the buzzing emitted from the Pinebook Pro's built-in speakers when certain backlight levels are set, which cause some weird interference with some of the components of the Pinebook Pro's audio chain. The old value for the backlight PWM period, i.e. 740,740 ns, is pretty much an arbitrary value that was selected during the very early bring-up of the Pinebook Pro, only because that value seemed to minimize horizontal line distortion on the display, which resulted from the old X.org drivers causing screen tearing when dragging windows around. That's no longer an issue, so there are no reasons to stick with the old PWM period value. The lower and the upper backlight PWM frequency limits for the Pinebook Pro's panel, according to its datasheet, are 200 Hz and 10 kHz, respectively. [1] These changes still leave some headroom, which may have some positive effects on the lifetime expectancy of the panel's backlight LEDs. [1] https://files.pine64.org/doc/datasheet/PinebookPro/NV140FHM-N49_Rev.P0_2016… Fixes: 5a65505a6988 ("arm64: dts: rockchip: Add initial support for Pinebook Pro") Cc: stable(a)vger.kernel.org Reported-by: Nikola Radojevic <nikola(a)radojevic.rs> Signed-off-by: Dragan Simic <dsimic(a)manjaro.org> --- arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts index 294eb2de263d..b3f76cc2d6e1 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts +++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts @@ -32,7 +32,7 @@ chosen { backlight: edp-backlight { compatible = "pwm-backlight"; power-supply = <&vcc_12v>; - pwms = <&pwm0 0 740740 0>; + pwms = <&pwm0 0 125000 0>; }; bat: battery {

11 months, 1 week

3
4
0 0

[PATCH] wifi: mac80211: check basic rates validity

by Vincenzo Mezzela

From: Johannes Berg <johannes.berg(a)intel.com> commit ce04abc3fcc62cd5640af981ebfd7c4dc3bded28 upstream. When userspace sets basic rates, it might send us some rates list that's empty or consists of invalid values only. We're currently ignoring invalid values and then may end up with a rates bitmap that's empty, which later results in a warning. Reject the call if there were no valid rates. [ Conflict resolution involved adjusting the patch to accommodate changes in the function signature of ieee80211_parse_bitrates and ieee80211_check_rate_mask ] Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Reported-by: syzbot+07bee335584b04e7c2f8(a)syzkaller.appspotmail.com Tested-by: syzbot+07bee335584b04e7c2f8(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=07bee335584b04e7c2f8 Signed-off-by: Vincenzo Mezzela <vincenzo.mezzela(a)gmail.com> --- Hi, please note that a backport of the same patch for v5.15 is available at [1]. Thanks, Vincenzo - [1] https://lore.kernel.org/all/20240727125033.1774143-1-vincenzo.mezzela@gmail… net/mac80211/cfg.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index 2c60fc165801..d121a3b460f4 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -2577,6 +2577,17 @@ static int ieee80211_change_bss(struct wiphy *wiphy, if (!sband) return -EINVAL; + if (params->basic_rates) { + if (!ieee80211_parse_bitrates(sdata->vif.bss_conf.chandef.width, + wiphy->bands[sband->band], + params->basic_rates, + params->basic_rates_len, + &sdata->vif.bss_conf.basic_rates)) + return -EINVAL; + changed |= BSS_CHANGED_BASIC_RATES; + ieee80211_check_rate_mask(&sdata->deflink); + } + if (params->use_cts_prot >= 0) { sdata->vif.bss_conf.use_cts_prot = params->use_cts_prot; changed |= BSS_CHANGED_ERP_CTS_PROT; @@ -2600,16 +2611,6 @@ static int ieee80211_change_bss(struct wiphy *wiphy, changed |= BSS_CHANGED_ERP_SLOT; } - if (params->basic_rates) { - ieee80211_parse_bitrates(sdata->vif.bss_conf.chandef.width, - wiphy->bands[sband->band], - params->basic_rates, - params->basic_rates_len, - &sdata->vif.bss_conf.basic_rates); - changed |= BSS_CHANGED_BASIC_RATES; - ieee80211_check_rate_mask(&sdata->deflink); - } - if (params->ap_isolate >= 0) { if (params->ap_isolate) sdata->flags |= IEEE80211_SDATA_DONT_BRIDGE_PACKETS; -- 2.43.0

11 months, 1 week

3
3
0 0

[PATCH] ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()

by Gui-Dong Han

This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the patch introduces a goto unregister_pins; statement when the condition is met, ensuring that the resources are correctly released and the reference count is decremented before returning the error. This change prevents potential memory leaks and ensures proper resource management within the function. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch. Fixes: d7999f5ea64b ("ice: implement dpll interface to control cgu") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02(a)outlook.com> --- drivers/net/ethernet/intel/ice/ice_dpll.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c index e92be6f130a3..f3f204cae093 100644 --- a/drivers/net/ethernet/intel/ice/ice_dpll.c +++ b/drivers/net/ethernet/intel/ice/ice_dpll.c @@ -1641,8 +1641,10 @@ ice_dpll_init_rclk_pins(struct ice_pf *pf, struct ice_dpll_pin *pin, if (ret) goto unregister_pins; } - if (WARN_ON((!vsi || !vsi->netdev))) - return -EINVAL; + if (WARN_ON((!vsi || !vsi->netdev))) { + ret = -EINVAL; + goto unregister_pins; + } dpll_netdev_pin_set(vsi->netdev, pf->dplls.rclk.pin); return 0; -- 2.25.1

11 months, 1 week

2
1
0 0

[PATCH AUTOSEL 5.10 01/11] PCI: Add ACS quirk for Broadcom BCM5760X NIC

by Sasha Levin

From: Ajit Khaparde <ajit.khaparde(a)broadcom.com> [ Upstream commit 524e057b2d66b61f9b63b6db30467ab7b0bb4796 ] The Broadcom BCM5760X NIC may be a multi-function device. While it does not advertise an ACS capability, peer-to-peer transactions are not possible between the individual functions. So it is ok to treat them as fully isolated. Add an ACS quirk for this device so the functions can be in independent IOMMU groups and attached individually to userspace applications using VFIO. [kwilczynski: commit log] Link: https://lore.kernel.org/linux-pci/20240510204228.73435-1-ajit.khaparde@broa… Signed-off-by: Ajit Khaparde <ajit.khaparde(a)broadcom.com> Signed-off-by: Krzysztof Wilczyński <kwilczynski(a)kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Reviewed-by: Andy Gospodarek <gospo(a)broadcom.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/pci/quirks.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 60a469bdc7e3e..39c42a1e8d9a3 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -4945,6 +4945,10 @@ static const struct pci_dev_acs_enabled { { PCI_VENDOR_ID_BROADCOM, 0x1750, pci_quirk_mf_endpoint_acs }, { PCI_VENDOR_ID_BROADCOM, 0x1751, pci_quirk_mf_endpoint_acs }, { PCI_VENDOR_ID_BROADCOM, 0x1752, pci_quirk_mf_endpoint_acs }, + { PCI_VENDOR_ID_BROADCOM, 0x1760, pci_quirk_mf_endpoint_acs }, + { PCI_VENDOR_ID_BROADCOM, 0x1761, pci_quirk_mf_endpoint_acs }, + { PCI_VENDOR_ID_BROADCOM, 0x1762, pci_quirk_mf_endpoint_acs }, + { PCI_VENDOR_ID_BROADCOM, 0x1763, pci_quirk_mf_endpoint_acs }, { PCI_VENDOR_ID_BROADCOM, 0xD714, pci_quirk_brcm_acs }, /* Amazon Annapurna Labs */ { PCI_VENDOR_ID_AMAZON_ANNAPURNA_LABS, 0x0031, pci_quirk_al_acs }, -- 2.43.0

11 months, 1 week

2
12
0 0

[PATCH] ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()

by Gui-Dong Han

This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. Specifically, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch. Fixes: 4035c72dc1ba ("ice: reconfig host after changing MSI-X on VF") Cc: stable(a)vger.kernel.org Signed-off-by: Gui-Dong Han <hanguidong02(a)outlook.com> --- drivers/net/ethernet/intel/ice/ice_sriov.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c index 55ef33208456..eb5030aba9a5 100644 --- a/drivers/net/ethernet/intel/ice/ice_sriov.c +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c @@ -1096,8 +1096,10 @@ int ice_sriov_set_msix_vec_count(struct pci_dev *vf_dev, int msix_vec_count) return -ENOENT; vsi = ice_get_vf_vsi(vf); - if (!vsi) + if (!vsi) { + ice_put_vf(vf); return -ENOENT; + } prev_msix = vf->num_msix; prev_queues = vf->num_vf_qs; -- 2.25.1

11 months, 1 week

2
1
0 0

[PATCH] wifi: brcmfmac: cfg80211: Handle SSID based pmksa deletion

by Janne Grunau via B4 Relay

From: Janne Grunau <j(a)jannau.net> wpa_supplicant 2.11 sends since 1efdba5fdc2c ("Handle PMKSA flush in the driver for SAE/OWE offload cases") SSID based PMKSA del commands. brcmfmac is not prepared and tries to dereference the NULL bssid and pmkid pointers in cfg80211_pmksa. PMKID_V3 operations support SSID based updates so copy the SSID. Fixes: a96202acaea4 ("wifi: brcmfmac: cfg80211: Add support for PMKID_V3 operations") Cc: stable(a)vger.kernel.org Signed-off-by: Janne Grunau <j(a)jannau.net> --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index 5fe0e671ecb3..826b768196e2 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c @@ -4320,9 +4320,16 @@ brcmf_pmksa_v3_op(struct brcmf_if *ifp, struct cfg80211_pmksa *pmksa, /* Single PMK operation */ pmk_op->count = cpu_to_le16(1); length += sizeof(struct brcmf_pmksa_v3); - memcpy(pmk_op->pmk[0].bssid, pmksa->bssid, ETH_ALEN); - memcpy(pmk_op->pmk[0].pmkid, pmksa->pmkid, WLAN_PMKID_LEN); - pmk_op->pmk[0].pmkid_len = WLAN_PMKID_LEN; + if (pmksa->bssid) + memcpy(pmk_op->pmk[0].bssid, pmksa->bssid, ETH_ALEN); + if (pmksa->pmkid) { + memcpy(pmk_op->pmk[0].pmkid, pmksa->pmkid, WLAN_PMKID_LEN); + pmk_op->pmk[0].pmkid_len = WLAN_PMKID_LEN; + } + if (pmksa->ssid && pmksa->ssid_len) { + memcpy(pmk_op->pmk[0].ssid.SSID, pmksa->ssid, pmksa->ssid_len); + pmk_op->pmk[0].ssid.SSID_len = pmksa->ssid_len; + } pmk_op->pmk[0].time_left = cpu_to_le32(alive ? BRCMF_PMKSA_NO_EXPIRY : 0); } --- base-commit: 0c3836482481200ead7b416ca80c68a29cfdaabd change-id: 20240803-brcmfmac_pmksa_del_ssid-3c35efe35330 Best regards, -- Janne Grunau <j(a)jannau.net>

11 months, 1 week

4
4
0 0

[tip: irq/urgent] irqchip/xilinx: Fix shift out of bounds

by tip-bot2 for Radhey Shyam Pandey

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: d73f0f49daa84176c3beee1606e73c7ffb6af8b2 Gitweb: https://git.kernel.org/tip/d73f0f49daa84176c3beee1606e73c7ffb6af8b2 Author: Radhey Shyam Pandey <radhey.shyam.pandey(a)amd.com> AuthorDate: Fri, 09 Aug 2024 12:32:24 +05:30 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Sat, 10 Aug 2024 10:39:24 +02:00 irqchip/xilinx: Fix shift out of bounds The device tree property 'xlnx,kind-of-intr' is sanity checked that the bitmask contains only set bits which are in the range of the number of interrupts supported by the controller. The check is done by shifting the mask right by the number of supported interrupts and checking the result for zero. The data type of the mask is u32 and the number of supported interrupts is up to 32. In case of 32 interrupts the shift is out of bounds, resulting in a mismatch warning. The out of bounds condition is also reported by UBSAN: UBSAN: shift-out-of-bounds in irq-xilinx-intc.c:332:22 shift exponent 32 is too large for 32-bit type 'unsigned int' Fix it by promoting the mask to u64 for the test. Fixes: d50466c90724 ("microblaze: intc: Refactor DT sanity check") Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey(a)amd.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/1723186944-3571957-1-git-send-email-radhey.shya… --- drivers/irqchip/irq-xilinx-intc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/irqchip/irq-xilinx-intc.c b/drivers/irqchip/irq-xilinx-intc.c index 238d3d3..7e08714 100644 --- a/drivers/irqchip/irq-xilinx-intc.c +++ b/drivers/irqchip/irq-xilinx-intc.c @@ -189,7 +189,7 @@ static int __init xilinx_intc_of_init(struct device_node *intc, irqc->intr_mask = 0; } - if (irqc->intr_mask >> irqc->nr_irq) + if ((u64)irqc->intr_mask >> irqc->nr_irq) pr_warn("irq-xilinx: mismatch in kind-of-intr param\n"); pr_info("irq-xilinx: %pOF: num_irq=%d, edge=0x%x\n",

11 months, 1 week

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2024