From: Tanmay Kathpalia <tanmay.kathpalia(a)altera.com>
A Partial Region Controller can be connected to one or more
Freeze Bridge. Each Freeze Bridge has an illegal_request
bit represented in the freeze_illegal_request register.
Thus, instead of just set to clear the illegal_request bit
for first Freeze Bridge, we need to ensure the set to clear
action is applied to which ever Freeze Bridge that has
occurrence of illegal request.
Fixes: ca24a648f535 ("fpga: add altera freeze bridge support")
Cc: stable(a)vger.kernel.org
Signed-off-by: Chiau Ee Chew <chiau.ee.chew(a)intel.com>
Signed-off-by: Tanmay Kathpalia <tanmay.kathpalia(a)altera.com>
---
drivers/fpga/altera-freeze-bridge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/fpga/altera-freeze-bridge.c b/drivers/fpga/altera-freeze-bridge.c
index 594693ff786e..23e8b2b54355 100644
--- a/drivers/fpga/altera-freeze-bridge.c
+++ b/drivers/fpga/altera-freeze-bridge.c
@@ -52,7 +52,7 @@ static int altera_freeze_br_req_ack(struct altera_freeze_br_data *priv,
if (illegal) {
dev_err(dev, "illegal request detected 0x%x", illegal);
- writel(1, csr_illegal_req_addr);
+ writel(illegal, csr_illegal_req_addr);
illegal = readl(csr_illegal_req_addr);
if (illegal)
--
2.35.3
This patch series addresses 2 issues
1) Fix typo in pattern properties for R-Car V4M.
2) Fix page entries in the AFL list.
v1->v2:
* Split fixes patches as separate series.
* Added Rb tag from Geert for binding patch.
* Added the tag Cc:stable@vger.kernel.org
Biju Das (2):
dt-bindings: can: renesas,rcar-canfd: Fix typo in pattern properties
for R-Car V4M
can: rcar_canfd: Fix page entries in the AFL list
.../bindings/net/can/renesas,rcar-canfd.yaml | 2 +-
drivers/net/can/rcar/rcar_canfd.c | 17 ++++++++++-------
2 files changed, 11 insertions(+), 8 deletions(-)
--
2.43.0
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Turns out LNL+ and BMG+ no longer have the weird extra scanline
offset for HDMI outputs. Fix intel_crtc_scanline_offset()
accordingly so that scanline evasion/etc. works correctly on
HDMI outputs on these new platforms.
Cc: stable(a)vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_vblank.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c b/drivers/gpu/drm/i915/display/intel_vblank.c
index 4efd4f7d497a..7b240ce681a0 100644
--- a/drivers/gpu/drm/i915/display/intel_vblank.c
+++ b/drivers/gpu/drm/i915/display/intel_vblank.c
@@ -222,7 +222,9 @@ int intel_crtc_scanline_offset(const struct intel_crtc_state *crtc_state)
* However if queried just before the start of vblank we'll get an
* answer that's slightly in the future.
*/
- if (DISPLAY_VER(display) == 2)
+ if (DISPLAY_VER(display) >= 20 || display->platform.battlemage)
+ return 1;
+ else if (DISPLAY_VER(display) == 2)
return -1;
else if (HAS_DDI(display) && intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
return 2;
--
2.45.3
In mptsas_setup_wide_ports() the calculation of phy bitmask is a subject
to undefined behavior when phy index exceeds the width of type 'int', but
is still less than 64.
Utilize BIT_ULL macro to fix this.
Found by Linux Verification Center (linuxtesting.org) with SVACE static
analysis tool.
Fixes: 547f9a218436 ("[SCSI] mptsas: wide port support")
Cc: stable(a)vger.kernel.org
Co-developed-by: Aleksandr Mishin <amishin(a)t-argos.ru>
Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru>
Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru>
---
struct mptsas_portinfo_details::phy_bitmask is used only in various
logging printks throughout the driver. Another option would be to drop
this field completely if it is considered a more appropriate solution..
drivers/message/fusion/mptsas.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index 7e79da9684ed..cd95655f1592 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -43,6 +43,7 @@
*/
/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
+#include <linux/bits.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
@@ -880,7 +881,7 @@ mptsas_setup_wide_ports(MPT_ADAPTER *ioc, struct mptsas_portinfo *port_info)
"%s: [%p]: deleting phy = %d\n",
ioc->name, __func__, port_details, i));
port_details->num_phys--;
- port_details->phy_bitmask &= ~ (1 << phy_info->phy_id);
+ port_details->phy_bitmask &= ~BIT_ULL(phy_info->phy_id);
memset(&phy_info->attached, 0, sizeof(struct mptsas_devinfo));
if (phy_info->phy) {
devtprintk(ioc, dev_printk(KERN_DEBUG,
@@ -915,7 +916,7 @@ mptsas_setup_wide_ports(MPT_ADAPTER *ioc, struct mptsas_portinfo *port_info)
port_details->port_info = port_info;
if (phy_info->phy_id < 64 )
port_details->phy_bitmask |=
- (1 << phy_info->phy_id);
+ BIT_ULL(phy_info->phy_id);
phy_info->sas_port_add_phy=1;
dsaswideprintk(ioc, printk(MYIOC_s_DEBUG_FMT "\t\tForming port\n\t\t"
"phy_id=%d sas_address=0x%018llX\n",
@@ -957,7 +958,7 @@ mptsas_setup_wide_ports(MPT_ADAPTER *ioc, struct mptsas_portinfo *port_info)
phy_info_cmp->port_details = port_details;
if (phy_info_cmp->phy_id < 64 )
port_details->phy_bitmask |=
- (1 << phy_info_cmp->phy_id);
+ BIT_ULL(phy_info_cmp->phy_id);
port_details->num_phys++;
}
}
--
2.48.1
<qh6envvnuw45w2omvpufqtbq5k5343ymdzswxrxmczwoe64d6g@a4z5wjdbdw6w>
Reply-To:
In-Reply-To:
<ah4qm66q5q7we7ykhl3uywgrexi7izdxrmfyn2zm3jhswitebt@cz2ipkdgr6yf>
On Tue, Feb 18, 2025 at 05:01:31PM +0100, Stefano Garzarella wrote:
>>
>>No, nothing I can think of.
>>
>>Note however that the comment above vsock_close() ("Dummy callback
>>required
>>by sockmap. See unconditional call of saved_close() in
>>sock_map_close().")
>>becomes somewhat misleading :)
>>
>
>Yeah, we can mention in the commit description of the backport that we
>backport it just to reduce conflicts but sockmap features are not
>backported. I'd touch as less as possibile in the patch, otherwise IMHO
>is better to just fix the conflicts in the 2 patches.
>
>Thanks,
>Stefano
>
Totally agree with you, will send the backport in a couple of days if
nobody has any objections.
Luigi