* [PATCH 09/10] perf hisi-ptt: Add field-level parsing for header DW2/DW3
From: Sizhe Liu @ 2026-06-04 7:50 UTC (permalink / raw)
To: rostedt, mhiramat, mathieu.desnoyers, corbet, skhan, bhelgaas,
yangyccccc, jic23, john.g.garry, will, james.clark, mike.leach,
leo.yan, peterz, mingo, acme, namhyung, mark.rutland,
alexander.shishkin, jolsa, irogers, adrian.hunter, wangyushan12,
shenyang39, gaozhihao6, yuzhichengcheng, liyihang9
Cc: linux-kernel, linux-pci, linux-perf-users, linux-arm-kernel,
linux-doc, linuxarm, prime.zeng, fanghao11, wuyifan50, liusizhe5
In-Reply-To: <20260604075005.2219785-1-liusizhe5@huawei.com>
Add detailed field parsing for TLP header DW2 and DW3 based on the
message type parsed from header DW0:
- HEADER DW0: fields printed in 4DW format, printed as generic label
in 8DW format for compatibility.
- HEADER DW1: printed with the field name for both 4DW and 8DW formats.
- HEADER DW2: fields printed for MWr/Msg/Atomic/IO TLPs, generic label
for others.
- HEADER DW3: fields printed for Completion and Configuration TLPs,
generic label for others.
This gives users more structured information when analysing PTT
trace data.
Signed-off-by: Sizhe Liu <liusizhe5@huawei.com>
---
.../hisi-ptt-decoder/hisi-ptt-pkt-decoder.c | 161 +++++++++++++++++-
1 file changed, 152 insertions(+), 9 deletions(-)
diff --git a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
index 59ab8ec3a03d..46f11d5719ac 100644
--- a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
+++ b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
@@ -38,6 +38,21 @@
* DW1 [ Header DW1 ]
* DW2 [ Header DW2 ]
* DW3 [ Header DW3 ]
+ *
+ * Header DW2 for MWr/Msg/MsgD/FetchAdd/Swap/CAS/IORd/IOWr is like:
+ * bits [ 31 ][ 30:23 ][22][21][20][ 19:16 ][ 15:0 ]
+ * |---------|----------------|----|---|--|-----------|----------|
+ * fields [Reserved][Request Segment][RSV][TV][T][Tag<13:10>][Header DW2]
+ *
+ * Header DW3 for CfgRd0/CfgWr0/CfgRd1/CfgWr1 is like:
+ * bits [ 31 ][ 30:23 ][22][21][20][ 19:16 ][ 15:0 ]
+ * |---------|--------------------|----|---|--|-----------|----------|
+ * fields [Reserved][Destination Segment][DSV][TV][T][Tag<13:10>][Header DW3]
+ *
+ * Header DW3 for Cpl/CplD/CplLk/CplDlk is like:
+ * bits [ 31:24 ][ 23:16 ][15][ 14:6 ][5][4][ 3:0 ]
+ * |--------------------|------------------|----|---------|--|---|----------|
+ * fields [Destination Segment][Completer Segment][DSV][Reserved][TV][T][Tag<13:10>]
*/
enum hisi_ptt_8dw_pkt_field_type {
@@ -127,6 +142,45 @@ union hisi_ptt_field_data {
uint32_t type : 5;
uint32_t format : 3;
} dw0_8dw;
+ /*
+ * Header DW2 for MWr/Msg/MsgD/FetchAdd/Swap/CAS/IORd/IOWr TLPs.
+ * Affects both 4DW and 8DW format.
+ */
+ struct {
+ uint32_t header_dw2 : 16;
+ uint32_t tag : 4;
+ uint32_t t : 1;
+ uint32_t tv : 1;
+ uint32_t rsv : 1;
+ uint32_t request_segment : 8;
+ uint32_t reserved : 1;
+ } dw2_mixed;
+ /*
+ * Header DW3 for CfgRd0/CfgWr0/CfgRd1/CfgWr1 TLPs.
+ * Affects both 4DW and 8DW format.
+ */
+ struct {
+ uint32_t header_dw3 : 16;
+ uint32_t tag : 4;
+ uint32_t t : 1;
+ uint32_t tv : 1;
+ uint32_t dsv : 1;
+ uint32_t destination_segment : 8;
+ uint32_t reserved : 1;
+ } dw3_cfg;
+ /*
+ * Header DW3 for Cpl/CplD/CplLk/CplDlk TLPs.
+ * Affects both 4DW and 8DW format.
+ */
+ struct {
+ uint32_t tag : 4;
+ uint32_t t : 1;
+ uint32_t tv : 1;
+ uint32_t reserved : 9;
+ uint32_t dsv : 1;
+ uint32_t completer_segment : 8;
+ uint32_t destination_segment : 8;
+ } dw3_cpl;
uint32_t value;
};
@@ -211,6 +265,85 @@ static void hisi_ptt_print_head0(struct hisi_ptt_pkt_buf *pkt_buf)
pkt_buf->pos += HISI_PTT_FIELD_LENGTH;
}
+static void hisi_ptt_print_head1(struct hisi_ptt_pkt_buf *pkt_buf)
+{
+ const char *color = PERF_COLOR_BLUE;
+ union hisi_ptt_field_data dw;
+
+ dw.value = le32_to_cpu(*(__le32 *)(pkt_buf->buf + pkt_buf->pos));
+ hisi_ptt_print_raw_record(pkt_buf->pos, dw.value);
+ color_fprintf(stdout, color, " %s\n",
+ pkt_buf->pkt_type == HISI_PTT_4DW_PKT ?
+ hisi_ptt_4dw_pkt_field_name[HISI_PTT_4DW_HEAD1] :
+ hisi_ptt_8dw_pkt_field_name[HISI_PTT_8DW_HEAD1]);
+
+ pkt_buf->pos += HISI_PTT_FIELD_LENGTH;
+}
+
+static void hisi_ptt_print_head2(struct hisi_ptt_pkt_buf *pkt_buf)
+{
+ const char *color = PERF_COLOR_BLUE;
+ union hisi_ptt_field_data dw;
+
+ dw.value = le32_to_cpu(*(__le32 *)(pkt_buf->buf + pkt_buf->pos));
+ hisi_ptt_print_raw_record(pkt_buf->pos, dw.value);
+
+ if (pkt_buf->pkt_msg_type == HISI_PTT_PKT_TYPE_MWR ||
+ pkt_buf->pkt_msg_type == HISI_PTT_PKT_TYPE_MSG ||
+ pkt_buf->pkt_msg_type == HISI_PTT_PKT_TYPE_ATOM ||
+ pkt_buf->pkt_msg_type == HISI_PTT_PKT_TYPE_IO)
+ color_fprintf(stdout, color,
+ " %s %x %s %x %s %x %s %x %s %x %s %x %s %x\n",
+ "Reserved", dw.dw2_mixed.reserved,
+ "Request Segment", dw.dw2_mixed.request_segment,
+ "RSV", dw.dw2_mixed.rsv, "TV", dw.dw2_mixed.tv,
+ "T", dw.dw2_mixed.t, "Tag", dw.dw2_mixed.tag,
+ "Header DW2", dw.dw2_mixed.header_dw2);
+ else
+ color_fprintf(stdout, color, " %s\n",
+ pkt_buf->pkt_type == HISI_PTT_4DW_PKT ?
+ hisi_ptt_4dw_pkt_field_name[HISI_PTT_4DW_HEAD2] :
+ hisi_ptt_8dw_pkt_field_name[HISI_PTT_8DW_HEAD2]);
+
+ pkt_buf->pos += HISI_PTT_FIELD_LENGTH;
+}
+
+static void hisi_ptt_print_head3(struct hisi_ptt_pkt_buf *pkt_buf)
+{
+ const char *color = PERF_COLOR_BLUE;
+ union hisi_ptt_field_data dw;
+
+ dw.value = le32_to_cpu(*(__le32 *)(pkt_buf->buf + pkt_buf->pos));
+ hisi_ptt_print_raw_record(pkt_buf->pos, dw.value);
+
+ if (pkt_buf->pkt_msg_type == HISI_PTT_PKT_TYPE_CPL)
+ color_fprintf(stdout, color,
+ " %s %x %s %x %s %x %s %x %s %x %s %x %s %x\n",
+ "Destination Segment",
+ dw.dw3_cpl.destination_segment,
+ "Completer Segment", dw.dw3_cpl.completer_segment,
+ "DSV", dw.dw3_cpl.dsv,
+ "Reserved", dw.dw3_cpl.reserved,
+ "TV", dw.dw3_cpl.tv, "T", dw.dw3_cpl.t,
+ "Tag", dw.dw3_cpl.tag);
+ else if (pkt_buf->pkt_msg_type == HISI_PTT_PKT_TYPE_CFG)
+ color_fprintf(stdout, color,
+ " %s %x %s %x %s %x %s %x %s %x %s %x %s %x\n",
+ "Reserved", dw.dw3_cfg.reserved,
+ "Destination Segment",
+ dw.dw3_cfg.destination_segment,
+ "DSV", dw.dw3_cfg.dsv, "TV", dw.dw3_cfg.tv,
+ "T", dw.dw3_cfg.t, "Tag", dw.dw3_cfg.tag,
+ "Header DW3", dw.dw3_cfg.header_dw3);
+ else
+ color_fprintf(stdout, color, " %s\n",
+ pkt_buf->pkt_type == HISI_PTT_4DW_PKT ?
+ hisi_ptt_4dw_pkt_field_name[HISI_PTT_4DW_HEAD3] :
+ hisi_ptt_8dw_pkt_field_name[HISI_PTT_8DW_HEAD3]);
+
+ pkt_buf->pos += HISI_PTT_FIELD_LENGTH;
+}
+
static int hisi_ptt_8dw_pkt_desc(struct hisi_ptt_pkt_buf *pkt_buf)
{
int i;
@@ -222,12 +355,24 @@ static int hisi_ptt_8dw_pkt_desc(struct hisi_ptt_pkt_buf *pkt_buf)
continue;
}
- if (i == HISI_PTT_8DW_HEAD0) {
+ switch (i) {
+ case HISI_PTT_8DW_HEAD0:
hisi_ptt_print_head0(pkt_buf);
- continue;
+ break;
+ case HISI_PTT_8DW_HEAD1:
+ hisi_ptt_print_head1(pkt_buf);
+ break;
+ case HISI_PTT_8DW_HEAD2:
+ hisi_ptt_print_head2(pkt_buf);
+ break;
+ case HISI_PTT_8DW_HEAD3:
+ hisi_ptt_print_head3(pkt_buf);
+ break;
+ default:
+ hisi_ptt_print_pkt(pkt_buf,
+ hisi_ptt_8dw_pkt_field_name[i]);
+ break;
}
-
- hisi_ptt_print_pkt(pkt_buf, hisi_ptt_8dw_pkt_field_name[i]);
}
return hisi_ptt_pkt_size[HISI_PTT_8DW_PKT];
@@ -235,12 +380,10 @@ static int hisi_ptt_8dw_pkt_desc(struct hisi_ptt_pkt_buf *pkt_buf)
static int hisi_ptt_4dw_pkt_desc(struct hisi_ptt_pkt_buf *pkt_buf)
{
- int i;
-
hisi_ptt_print_head0(pkt_buf);
-
- for (i = HISI_PTT_4DW_HEAD1; i < HISI_PTT_4DW_TYPE_MAX; i++)
- hisi_ptt_print_pkt(pkt_buf, hisi_ptt_4dw_pkt_field_name[i]);
+ hisi_ptt_print_head1(pkt_buf);
+ hisi_ptt_print_head2(pkt_buf);
+ hisi_ptt_print_head3(pkt_buf);
return hisi_ptt_pkt_size[HISI_PTT_4DW_PKT];
}
--
2.33.0
^ permalink raw reply related
* [PATCH 04/10] perf hisi-ptt: Abstract trace data buf and offset
From: Sizhe Liu @ 2026-06-04 7:49 UTC (permalink / raw)
To: rostedt, mhiramat, mathieu.desnoyers, corbet, skhan, bhelgaas,
yangyccccc, jic23, john.g.garry, will, james.clark, mike.leach,
leo.yan, peterz, mingo, acme, namhyung, mark.rutland,
alexander.shishkin, jolsa, irogers, adrian.hunter, wangyushan12,
shenyang39, gaozhihao6, yuzhichengcheng, liyihang9
Cc: linux-kernel, linux-pci, linux-perf-users, linux-arm-kernel,
linux-doc, linuxarm, prime.zeng, fanghao11, wuyifan50, liusizhe5
In-Reply-To: <20260604075005.2219785-1-liusizhe5@huawei.com>
Abstract the base address, current offset, length and packet type of
analysing trace data into structure hisi_ptt_pkt_buf and move the step
of current offset into the corresponding function.
Signed-off-by: Sizhe Liu <liusizhe5@huawei.com>
---
.../hisi-ptt-decoder/hisi-ptt-pkt-decoder.c | 39 ++++++++++---------
.../hisi-ptt-decoder/hisi-ptt-pkt-decoder.h | 9 ++++-
tools/perf/util/hisi-ptt.c | 20 ++++------
3 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
index 5daae2eaf435..201ca948c4fb 100644
--- a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
+++ b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
@@ -89,16 +89,17 @@ union hisi_ptt_field_data {
uint32_t value;
};
-static void hisi_ptt_print_pkt(const unsigned char *buf, int pos, const char *desc)
+static void hisi_ptt_print_pkt(struct hisi_ptt_pkt_buf *pkt_buf,
+ const char *desc)
{
const char *color = PERF_COLOR_BLUE;
uint32_t value;
uint8_t byte;
int i;
- value = le32_to_cpu(*(__le32 *)(buf + pos));
+ value = le32_to_cpu(*(__le32 *)(pkt_buf->buf + pkt_buf->pos));
printf(".");
- color_fprintf(stdout, color, " %08x: ", pos);
+ color_fprintf(stdout, color, " %08zx: ", pkt_buf->pos);
for (i = 0; i < HISI_PTT_FIELD_LENGTH; i++) {
byte = (value >> (24 - i * 8)) & 0xFF;
color_fprintf(stdout, color, "%02x ", byte);
@@ -106,36 +107,36 @@ static void hisi_ptt_print_pkt(const unsigned char *buf, int pos, const char *de
for (i = 0; i < HISI_PTT_MAX_SPACE_LEN; i++)
color_fprintf(stdout, color, " ");
color_fprintf(stdout, color, " %s\n", desc);
+ pkt_buf->pos += HISI_PTT_FIELD_LENGTH;
}
-static int hisi_ptt_8dw_pkt_desc(const unsigned char *buf, int pos)
+static int hisi_ptt_8dw_pkt_desc(struct hisi_ptt_pkt_buf *pkt_buf)
{
int i;
for (i = 0; i < HISI_PTT_8DW_TYPE_MAX; i++) {
/* Do not show 8DW check field and reserved fields */
if (i == HISI_PTT_8DW_CHK_AND_RSV0 || i == HISI_PTT_8DW_RSV1) {
- pos += HISI_PTT_FIELD_LENGTH;
+ pkt_buf->pos += HISI_PTT_FIELD_LENGTH;
continue;
}
- hisi_ptt_print_pkt(buf, pos, hisi_ptt_8dw_pkt_field_name[i]);
- pos += HISI_PTT_FIELD_LENGTH;
+ hisi_ptt_print_pkt(pkt_buf, hisi_ptt_8dw_pkt_field_name[i]);
}
return hisi_ptt_pkt_size[HISI_PTT_8DW_PKT];
}
-static void hisi_ptt_4dw_print_dw0(const unsigned char *buf, int pos)
+static void hisi_ptt_4dw_print_dw0(struct hisi_ptt_pkt_buf *pkt_buf)
{
const char *color = PERF_COLOR_BLUE;
union hisi_ptt_field_data dw;
uint8_t byte;
int i;
- dw.value = le32_to_cpu(*(__le32 *)(buf + pos));
+ dw.value = le32_to_cpu(*(__le32 *)(pkt_buf->buf + pkt_buf->pos));
printf(".");
- color_fprintf(stdout, color, " %08x: ", pos);
+ color_fprintf(stdout, color, " %08zx: ", pkt_buf->pos);
for (i = 0; i < HISI_PTT_FIELD_LENGTH; i++) {
byte = (dw.value >> (24 - i * 8)) & 0xFF;
color_fprintf(stdout, color, "%02x ", byte);
@@ -149,27 +150,27 @@ static void hisi_ptt_4dw_print_dw0(const unsigned char *buf, int pos)
"T9", dw.dw0_4dw.t9, "T8", dw.dw0_4dw.t8,
"TH", dw.dw0_4dw.th, "SO", dw.dw0_4dw.so,
"Length", dw.dw0_4dw.len, "Time", dw.dw0_4dw.time);
+
+ pkt_buf->pos += HISI_PTT_FIELD_LENGTH;
}
-static int hisi_ptt_4dw_pkt_desc(const unsigned char *buf, int pos)
+static int hisi_ptt_4dw_pkt_desc(struct hisi_ptt_pkt_buf *pkt_buf)
{
int i;
- hisi_ptt_4dw_print_dw0(buf, pos);
- pos += HISI_PTT_FIELD_LENGTH;
+ hisi_ptt_4dw_print_dw0(pkt_buf);
for (i = 0; i < HISI_PTT_4DW_TYPE_MAX; i++) {
- hisi_ptt_print_pkt(buf, pos, hisi_ptt_4dw_pkt_field_name[i]);
- pos += HISI_PTT_FIELD_LENGTH;
+ hisi_ptt_print_pkt(pkt_buf, hisi_ptt_4dw_pkt_field_name[i]);
}
return hisi_ptt_pkt_size[HISI_PTT_4DW_PKT];
}
-int hisi_ptt_pkt_desc(const unsigned char *buf, int pos, enum hisi_ptt_pkt_type type)
+int hisi_ptt_pkt_desc(struct hisi_ptt_pkt_buf *pkt_buf)
{
- if (type == HISI_PTT_8DW_PKT)
- return hisi_ptt_8dw_pkt_desc(buf, pos);
+ if (pkt_buf->pkt_type == HISI_PTT_8DW_PKT)
+ return hisi_ptt_8dw_pkt_desc(pkt_buf);
- return hisi_ptt_4dw_pkt_desc(buf, pos);
+ return hisi_ptt_4dw_pkt_desc(pkt_buf);
}
diff --git a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.h b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.h
index 6772b16b817b..316f24f01068 100644
--- a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.h
+++ b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.h
@@ -26,6 +26,13 @@ static int hisi_ptt_pkt_size[] = {
[HISI_PTT_8DW_PKT] = 32,
};
-int hisi_ptt_pkt_desc(const unsigned char *buf, int pos, enum hisi_ptt_pkt_type type);
+struct hisi_ptt_pkt_buf {
+ const unsigned char *buf;
+ size_t pos;
+ size_t len;
+ enum hisi_ptt_pkt_type pkt_type;
+};
+
+int hisi_ptt_pkt_desc(struct hisi_ptt_pkt_buf *pkt_buf);
#endif
diff --git a/tools/perf/util/hisi-ptt.c b/tools/perf/util/hisi-ptt.c
index e4cc4785f744..4efda3f3e5f9 100644
--- a/tools/perf/util/hisi-ptt.c
+++ b/tools/perf/util/hisi-ptt.c
@@ -49,22 +49,18 @@ static void hisi_ptt_dump(struct hisi_ptt *ptt __maybe_unused,
unsigned char *buf, size_t len)
{
const char *color = PERF_COLOR_BLUE;
- enum hisi_ptt_pkt_type type;
- size_t pos = 0;
- int pkt_len;
+ struct hisi_ptt_pkt_buf pkt_buf;
- type = hisi_ptt_check_packet_type(buf);
- len = round_down(len, hisi_ptt_pkt_size[type]);
+ pkt_buf.buf = buf;
+ pkt_buf.pos = 0;
+ pkt_buf.pkt_type = hisi_ptt_check_packet_type(buf);
+ pkt_buf.len = round_down(len, hisi_ptt_pkt_size[pkt_buf.pkt_type]);
color_fprintf(stdout, color, ". ... HISI PTT data: size %zu bytes\n",
- len);
+ pkt_buf.len);
- while (len > 0) {
- pkt_len = hisi_ptt_pkt_desc(buf, pos, type);
- if (!pkt_len)
+ while (pkt_buf.pos < pkt_buf.len) {
+ if (!hisi_ptt_pkt_desc(&pkt_buf))
color_fprintf(stdout, color, " Bad packet!\n");
-
- pos += pkt_len;
- len -= pkt_len;
}
}
--
2.33.0
^ permalink raw reply related
* [PATCH 05/10] perf hisi-ptt: Complete the field names for 4DW and 8DW packets
From: Sizhe Liu @ 2026-06-04 7:50 UTC (permalink / raw)
To: rostedt, mhiramat, mathieu.desnoyers, corbet, skhan, bhelgaas,
yangyccccc, jic23, john.g.garry, will, james.clark, mike.leach,
leo.yan, peterz, mingo, acme, namhyung, mark.rutland,
alexander.shishkin, jolsa, irogers, adrian.hunter, wangyushan12,
shenyang39, gaozhihao6, yuzhichengcheng, liyihang9
Cc: linux-kernel, linux-pci, linux-perf-users, linux-arm-kernel,
linux-doc, linuxarm, prime.zeng, fanghao11, wuyifan50, liusizhe5
In-Reply-To: <20260604075005.2219785-1-liusizhe5@huawei.com>
Add the missing HISI_PTT_4DW_HEAD0 entry to the 4DW field name table
and add the HISI_PTT_8DW_CHK_AND_RSV0/HISI_PTT_8DW_RSV1 entries to
the 8DW field name table so that all DW indices have corresponding
names.
Replace the variable in the printing loop with enum members.
8DW format is like:
bits [ 31:11 ][ 10:0 ]
|---------------------------------------|-------------------|
DW0 [ 0x1fffff ][ Reserved (0x7ff) ]
DW1 [ Prefix ]
DW2 [ Header DW0 ]
DW3 [ Header DW1 ]
DW4 [ Header DW2 ]
DW5 [ Header DW3 ]
DW6 [ Reserved (0x0) ]
DW7 [ Time ]
Signed-off-by: Sizhe Liu <liusizhe5@huawei.com>
---
.../hisi-ptt-decoder/hisi-ptt-pkt-decoder.c | 21 +++++++++++--------
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
index 201ca948c4fb..33804bcd0642 100644
--- a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
+++ b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
@@ -53,6 +53,7 @@ enum hisi_ptt_8dw_pkt_field_type {
};
enum hisi_ptt_4dw_pkt_field_type {
+ HISI_PTT_4DW_HEAD0,
HISI_PTT_4DW_HEAD1,
HISI_PTT_4DW_HEAD2,
HISI_PTT_4DW_HEAD3,
@@ -60,15 +61,18 @@ enum hisi_ptt_4dw_pkt_field_type {
};
static const char * const hisi_ptt_8dw_pkt_field_name[] = {
- [HISI_PTT_8DW_PREFIX] = "Prefix",
- [HISI_PTT_8DW_HEAD0] = "Header DW0",
- [HISI_PTT_8DW_HEAD1] = "Header DW1",
- [HISI_PTT_8DW_HEAD2] = "Header DW2",
- [HISI_PTT_8DW_HEAD3] = "Header DW3",
- [HISI_PTT_8DW_TIME] = "Time"
+ [HISI_PTT_8DW_CHK_AND_RSV0] = "CHK & RSV0",
+ [HISI_PTT_8DW_PREFIX] = "Prefix",
+ [HISI_PTT_8DW_HEAD0] = "Header DW0",
+ [HISI_PTT_8DW_HEAD1] = "Header DW1",
+ [HISI_PTT_8DW_HEAD2] = "Header DW2",
+ [HISI_PTT_8DW_HEAD3] = "Header DW3",
+ [HISI_PTT_8DW_RSV1] = "RSV1",
+ [HISI_PTT_8DW_TIME] = "Time"
};
static const char * const hisi_ptt_4dw_pkt_field_name[] = {
+ [HISI_PTT_4DW_HEAD0] = "Header DW0",
[HISI_PTT_4DW_HEAD1] = "Header DW1",
[HISI_PTT_4DW_HEAD2] = "Header DW2",
[HISI_PTT_4DW_HEAD3] = "Header DW3",
@@ -114,7 +118,7 @@ static int hisi_ptt_8dw_pkt_desc(struct hisi_ptt_pkt_buf *pkt_buf)
{
int i;
- for (i = 0; i < HISI_PTT_8DW_TYPE_MAX; i++) {
+ for (i = HISI_PTT_8DW_CHK_AND_RSV0; i < HISI_PTT_8DW_TYPE_MAX; i++) {
/* Do not show 8DW check field and reserved fields */
if (i == HISI_PTT_8DW_CHK_AND_RSV0 || i == HISI_PTT_8DW_RSV1) {
pkt_buf->pos += HISI_PTT_FIELD_LENGTH;
@@ -160,9 +164,8 @@ static int hisi_ptt_4dw_pkt_desc(struct hisi_ptt_pkt_buf *pkt_buf)
hisi_ptt_4dw_print_dw0(pkt_buf);
- for (i = 0; i < HISI_PTT_4DW_TYPE_MAX; i++) {
+ for (i = HISI_PTT_4DW_HEAD1; i < HISI_PTT_4DW_TYPE_MAX; i++)
hisi_ptt_print_pkt(pkt_buf, hisi_ptt_4dw_pkt_field_name[i]);
- }
return hisi_ptt_pkt_size[HISI_PTT_4DW_PKT];
}
--
2.33.0
^ permalink raw reply related
* [PATCH 03/10] perf hisi-ptt: Rename hisi_ptt_4dw union for reuse
From: Sizhe Liu @ 2026-06-04 7:49 UTC (permalink / raw)
To: rostedt, mhiramat, mathieu.desnoyers, corbet, skhan, bhelgaas,
yangyccccc, jic23, john.g.garry, will, james.clark, mike.leach,
leo.yan, peterz, mingo, acme, namhyung, mark.rutland,
alexander.shishkin, jolsa, irogers, adrian.hunter, wangyushan12,
shenyang39, gaozhihao6, yuzhichengcheng, liyihang9
Cc: linux-kernel, linux-pci, linux-perf-users, linux-arm-kernel,
linux-doc, linuxarm, prime.zeng, fanghao11, wuyifan50, liusizhe5
In-Reply-To: <20260604075005.2219785-1-liusizhe5@huawei.com>
Rename union hisi_ptt_4dw to hisi_ptt_field_data so that it can hold
bit field layouts for different DW headers. Add the struct member name
dw0_4dw to indicate that the inner struct is for 4DW format DW0.
Signed-off-by: Sizhe Liu <liusizhe5@huawei.com>
---
.../hisi-ptt-decoder/hisi-ptt-pkt-decoder.c | 18 ++++++++++--------
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
index 67024f18ebbb..5daae2eaf435 100644
--- a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
+++ b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
@@ -74,7 +74,8 @@ static const char * const hisi_ptt_4dw_pkt_field_name[] = {
[HISI_PTT_4DW_HEAD3] = "Header DW3",
};
-union hisi_ptt_4dw {
+union hisi_ptt_field_data {
+ /* Header DW0 for 4DW format */
struct {
uint32_t time : 11;
uint32_t len : 10;
@@ -84,7 +85,7 @@ union hisi_ptt_4dw {
uint32_t t9 : 1;
uint32_t type : 5;
uint32_t format : 2;
- };
+ } dw0_4dw;
uint32_t value;
};
@@ -128,15 +129,15 @@ static int hisi_ptt_8dw_pkt_desc(const unsigned char *buf, int pos)
static void hisi_ptt_4dw_print_dw0(const unsigned char *buf, int pos)
{
const char *color = PERF_COLOR_BLUE;
- union hisi_ptt_4dw dw0;
+ union hisi_ptt_field_data dw;
uint8_t byte;
int i;
- dw0.value = le32_to_cpu(*(__le32 *)(buf + pos));
+ dw.value = le32_to_cpu(*(__le32 *)(buf + pos));
printf(".");
color_fprintf(stdout, color, " %08x: ", pos);
for (i = 0; i < HISI_PTT_FIELD_LENGTH; i++) {
- byte = (dw0.value >> (24 - i * 8)) & 0xFF;
+ byte = (dw.value >> (24 - i * 8)) & 0xFF;
color_fprintf(stdout, color, "%02x ", byte);
}
for (i = 0; i < HISI_PTT_MAX_SPACE_LEN; i++)
@@ -144,9 +145,10 @@ static void hisi_ptt_4dw_print_dw0(const unsigned char *buf, int pos)
color_fprintf(stdout, color,
" %s %x %s %x %s %x %s %x %s %x %s %x %s %x %s %x\n",
- "Format", dw0.format, "Type", dw0.type, "T9", dw0.t9,
- "T8", dw0.t8, "TH", dw0.th, "SO", dw0.so, "Length",
- dw0.len, "Time", dw0.time);
+ "Format", dw.dw0_4dw.format, "Type", dw.dw0_4dw.type,
+ "T9", dw.dw0_4dw.t9, "T8", dw.dw0_4dw.t8,
+ "TH", dw.dw0_4dw.th, "SO", dw.dw0_4dw.so,
+ "Length", dw.dw0_4dw.len, "Time", dw.dw0_4dw.time);
}
static int hisi_ptt_4dw_pkt_desc(const unsigned char *buf, int pos)
--
2.33.0
^ permalink raw reply related
* [PATCH 08/10] perf hisi-ptt: Add parsing of supported message types
From: Sizhe Liu @ 2026-06-04 7:50 UTC (permalink / raw)
To: rostedt, mhiramat, mathieu.desnoyers, corbet, skhan, bhelgaas,
yangyccccc, jic23, john.g.garry, will, james.clark, mike.leach,
leo.yan, peterz, mingo, acme, namhyung, mark.rutland,
alexander.shishkin, jolsa, irogers, adrian.hunter, wangyushan12,
shenyang39, gaozhihao6, yuzhichengcheng, liyihang9
Cc: linux-kernel, linux-pci, linux-perf-users, linux-arm-kernel,
linux-doc, linuxarm, prime.zeng, fanghao11, wuyifan50, liusizhe5
In-Reply-To: <20260604075005.2219785-1-liusizhe5@huawei.com>
Parse TLP message types from Header DW0 Format and Type fields for
both 4DW and 8DW formats, classifying packets into:
- MWr (Posted Memory Write)
- Msg (Posted Message)
- Atom (Non-Posted Atomic)
- IO (Non-Posted IO)
- CFG (Non-Posted Configuration)
- CPL (Completion)
Support for those message types depends on the hisi_ptt hardware.
The parsed message type is stored in pkt_buf->pkt_msg_type and will
be used by subsequent patches to select the correct field layout for
DW2 and DW3 printing.
Signed-off-by: Sizhe Liu <liusizhe5@huawei.com>
---
.../hisi-ptt-decoder/hisi-ptt-pkt-decoder.c | 65 +++++++++++++++++++
.../hisi-ptt-decoder/hisi-ptt-pkt-decoder.h | 12 ++++
tools/perf/util/hisi-ptt.c | 1 +
3 files changed, 78 insertions(+)
diff --git a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
index 9ec84d398cc1..59ab8ec3a03d 100644
--- a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
+++ b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.c
@@ -78,6 +78,37 @@ static const char * const hisi_ptt_4dw_pkt_field_name[] = {
[HISI_PTT_4DW_HEAD3] = "Header DW3",
};
+static bool hisi_ptt_is_mwr_tlp(uint32_t format, uint32_t type)
+{
+ return (format == 0x2 || format == 0x3) && (type == 0);
+}
+
+static bool hisi_ptt_is_msg_tlp(uint32_t format, uint32_t type)
+{
+ return (format == 0x1 || format == 0x3) && ((type & 0x10) != 0);
+}
+
+static bool hisi_ptt_is_io_tlp(uint32_t format, uint32_t type)
+{
+ return (format == 0 || format == 0x2) && (type == 0x2);
+}
+
+static bool hisi_ptt_is_atomic_tlp(uint32_t format, uint32_t type)
+{
+ return (format == 0x2 || format == 0x3) &&
+ (type == 0xc || type == 0xd || type == 0xe);
+}
+
+static bool hisi_ptt_is_cfg_tlp(uint32_t format, uint32_t type)
+{
+ return (format == 0 || format == 0x2) && (type == 0x4 || type == 0x5);
+}
+
+static bool hisi_ptt_is_cpl_tlp(uint32_t format, uint32_t type)
+{
+ return (format == 0 || format == 0x2) && (type == 0xa || type == 0xb);
+}
+
union hisi_ptt_field_data {
/* Header DW0 for 4DW format */
struct {
@@ -90,9 +121,41 @@ union hisi_ptt_field_data {
uint32_t type : 5;
uint32_t format : 2;
} dw0_4dw;
+ /* Header DW0 for 8DW format */
+ struct {
+ uint32_t others : 24;
+ uint32_t type : 5;
+ uint32_t format : 3;
+ } dw0_8dw;
uint32_t value;
};
+static int hisi_ptt_parse_pkt_msg_type(union hisi_ptt_field_data dw,
+ enum hisi_ptt_pkt_type pkt_type)
+{
+ uint32_t format, type;
+
+ format = (pkt_type == HISI_PTT_4DW_PKT) ? dw.dw0_4dw.format :
+ dw.dw0_8dw.format;
+ type = (pkt_type == HISI_PTT_4DW_PKT) ? dw.dw0_4dw.type :
+ dw.dw0_8dw.type;
+
+ if (hisi_ptt_is_mwr_tlp(format, type))
+ return HISI_PTT_PKT_TYPE_MWR;
+ else if (hisi_ptt_is_msg_tlp(format, type))
+ return HISI_PTT_PKT_TYPE_MSG;
+ else if (hisi_ptt_is_atomic_tlp(format, type))
+ return HISI_PTT_PKT_TYPE_ATOM;
+ else if (hisi_ptt_is_io_tlp(format, type))
+ return HISI_PTT_PKT_TYPE_IO;
+ else if (hisi_ptt_is_cfg_tlp(format, type))
+ return HISI_PTT_PKT_TYPE_CFG;
+ else if (hisi_ptt_is_cpl_tlp(format, type))
+ return HISI_PTT_PKT_TYPE_CPL;
+
+ return HISI_PTT_PKT_TYPE_UNKNOWN;
+}
+
static void hisi_ptt_print_raw_record(size_t offset, uint32_t value)
{
const char *color = PERF_COLOR_BLUE;
@@ -128,6 +191,8 @@ static void hisi_ptt_print_head0(struct hisi_ptt_pkt_buf *pkt_buf)
union hisi_ptt_field_data dw;
dw.value = le32_to_cpu(*(__le32 *)(pkt_buf->buf + pkt_buf->pos));
+ pkt_buf->pkt_msg_type = hisi_ptt_parse_pkt_msg_type(dw,
+ pkt_buf->pkt_type);
hisi_ptt_print_raw_record(pkt_buf->pos, dw.value);
if (pkt_buf->pkt_type == HISI_PTT_4DW_PKT)
diff --git a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.h b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.h
index 316f24f01068..3fdad34fe400 100644
--- a/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.h
+++ b/tools/perf/util/hisi-ptt-decoder/hisi-ptt-pkt-decoder.h
@@ -26,11 +26,23 @@ static int hisi_ptt_pkt_size[] = {
[HISI_PTT_8DW_PKT] = 32,
};
+enum hisi_ptt_pkt_msg_type {
+ HISI_PTT_PKT_TYPE_UNKNOWN, /* Types do not support analysis */
+ HISI_PTT_PKT_TYPE_MWR, /* P-(MemWr) */
+ HISI_PTT_PKT_TYPE_MSG, /* P-(Message) */
+ HISI_PTT_PKT_TYPE_ATOM, /* NP-(Atomic) */
+ HISI_PTT_PKT_TYPE_IO, /* NP-(IO) */
+ HISI_PTT_PKT_TYPE_CFG, /* NP-(CFG) */
+ HISI_PTT_PKT_TYPE_CPL, /* CPL-(CPL) */
+ HISI_PTT_PKT_TYPE_MAX
+};
+
struct hisi_ptt_pkt_buf {
const unsigned char *buf;
size_t pos;
size_t len;
enum hisi_ptt_pkt_type pkt_type;
+ enum hisi_ptt_pkt_msg_type pkt_msg_type;
};
int hisi_ptt_pkt_desc(struct hisi_ptt_pkt_buf *pkt_buf);
diff --git a/tools/perf/util/hisi-ptt.c b/tools/perf/util/hisi-ptt.c
index 4efda3f3e5f9..e321f393601b 100644
--- a/tools/perf/util/hisi-ptt.c
+++ b/tools/perf/util/hisi-ptt.c
@@ -55,6 +55,7 @@ static void hisi_ptt_dump(struct hisi_ptt *ptt __maybe_unused,
pkt_buf.pos = 0;
pkt_buf.pkt_type = hisi_ptt_check_packet_type(buf);
pkt_buf.len = round_down(len, hisi_ptt_pkt_size[pkt_buf.pkt_type]);
+ pkt_buf.pkt_msg_type = HISI_PTT_PKT_TYPE_UNKNOWN;
color_fprintf(stdout, color, ". ... HISI PTT data: size %zu bytes\n",
pkt_buf.len);
--
2.33.0
^ permalink raw reply related
* Re: [PATCH v7 11/15] powerpc/code-patching: Avoid r/w mapping of the zero page
From: Christophe Leroy (CS GROUP) @ 2026-06-04 7:43 UTC (permalink / raw)
To: Ard Biesheuvel, linux-arm-kernel
Cc: linux-kernel, will, catalin.marinas, mark.rutland, Ard Biesheuvel,
Ryan Roberts, Anshuman Khandual, Kevin Brodsky, Liz Prucka,
Seth Jenkins, Kees Cook, Mike Rapoport, David Hildenbrand,
Andrew Morton, Jann Horn, linux-mm, linux-hardening, linuxppc-dev,
linux-sh, Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin
In-Reply-To: <20260529150150.1670604-28-ardb+git@google.com>
Le 29/05/2026 à 17:02, Ard Biesheuvel a écrit :
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The only remaining use of map_patch_area() is mapping the zero page, and
> immediately unmapping it again so that the intermediate page table
> levels are all guaranteed to be populated.
>
> The use of the zero page here is completely arbitrary, and not harmful
> per se, but currently, it creates a writable mapping, and does so in a
> manner that requires that the empty_zero_page[] symbol is not
> const-qualified.
>
> Given that this is about to change, and that map_patch_area() now never
> maps anything other than the zero page, let's simplify the code and
> - remove the helpers and call [un]map_kernel_page() directly
> - take the PA of empty_zero_page directly
> - create a read-only temporary mapping.
>
> This allows empty_zero_page[] to be repainted as const u8[] in a
> subsequent patch, without making substantial changes to this code
> patching logic.
>
> Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
> Link: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2F20260520085423.485402-1-ardb%40kernel.org%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7Ca75a9b5e25f14d0d9b2208debd935266%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639156637598013085%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Q82ykchJOsuWlbmq%2BKFb2cTWIU4wGXbR53VQjNvgOCk%3D&reserved=0
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
> ---
> arch/powerpc/lib/code-patching.c | 52 +-------------------
> 1 file changed, 2 insertions(+), 50 deletions(-)
>
> diff --git a/arch/powerpc/lib/code-patching.c b/arch/powerpc/lib/code-patching.c
> index f84e0337cc02..44ff9f684bef 100644
> --- a/arch/powerpc/lib/code-patching.c
> +++ b/arch/powerpc/lib/code-patching.c
> @@ -60,9 +60,6 @@ struct patch_context {
>
> static DEFINE_PER_CPU(struct patch_context, cpu_patching_context);
>
> -static int map_patch_area(void *addr, unsigned long text_poke_addr);
> -static void unmap_patch_area(unsigned long addr);
> -
> static bool mm_patch_enabled(void)
> {
> return IS_ENABLED(CONFIG_SMP) && radix_enabled();
> @@ -117,11 +114,11 @@ static int text_area_cpu_up(unsigned int cpu)
>
> // Map/unmap the area to ensure all page tables are pre-allocated
> addr = (unsigned long)area->addr;
> - err = map_patch_area(empty_zero_page, addr);
> + err = map_kernel_page(addr, __pa_symbol(empty_zero_page), PAGE_KERNEL_RO);
> if (err)
> return err;
>
> - unmap_patch_area(addr);
> + unmap_kernel_page(addr);
>
> this_cpu_write(cpu_patching_context.area, area);
> this_cpu_write(cpu_patching_context.addr, addr);
> @@ -233,51 +230,6 @@ static unsigned long get_patch_pfn(void *addr)
> return __pa_symbol(addr) >> PAGE_SHIFT;
> }
>
> -/*
> - * This can be called for kernel text or a module.
> - */
> -static int map_patch_area(void *addr, unsigned long text_poke_addr)
> -{
> - unsigned long pfn = get_patch_pfn(addr);
> -
> - return map_kernel_page(text_poke_addr, (pfn << PAGE_SHIFT), PAGE_KERNEL);
> -}
> -
> -static void unmap_patch_area(unsigned long addr)
> -{
> - pte_t *ptep;
> - pmd_t *pmdp;
> - pud_t *pudp;
> - p4d_t *p4dp;
> - pgd_t *pgdp;
> -
> - pgdp = pgd_offset_k(addr);
> - if (WARN_ON(pgd_none(*pgdp)))
> - return;
> -
> - p4dp = p4d_offset(pgdp, addr);
> - if (WARN_ON(p4d_none(*p4dp)))
> - return;
> -
> - pudp = pud_offset(p4dp, addr);
> - if (WARN_ON(pud_none(*pudp)))
> - return;
> -
> - pmdp = pmd_offset(pudp, addr);
> - if (WARN_ON(pmd_none(*pmdp)))
> - return;
> -
> - ptep = pte_offset_kernel(pmdp, addr);
> - if (WARN_ON(pte_none(*ptep)))
> - return;
> -
> - /*
> - * In hash, pte_clear flushes the tlb, in radix, we have to
> - */
> - pte_clear(&init_mm, addr, ptep);
> - flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> -}
> -
> static int __do_patch_mem_mm(void *addr, unsigned long val, bool is_dword)
> {
> int err;
^ permalink raw reply
* [PATCH] coresight: ultrasoc-smb: Fix OOB write in smb_sync_perf_buffer()
From: Junrui Luo @ 2026-06-04 7:34 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Qi Liu, Junhao He, Jonathan Cameron
Cc: coresight, linux-arm-kernel, linux-kernel, Yuhao Jiang, stable,
Junrui Luo
When the SMB sink is used as a perf AUX sink, smb_update_buffer() calls
smb_sync_perf_buffer() to copy hardware trace data into the perf AUX ring
buffer pages. It derives pg_idx = head >> PAGE_SHIFT from @head, which is
handle->head, and indexes dst_pages[pg_idx]. The pg_idx %= nr_pages
normalization is only applied after the first loop iteration.
This leaves the initial page index underived from the buffer size, which
can result in an out-of-bounds write past dst_pages[] when head exceeds
the AUX buffer size.
Normalize head modulo the AUX buffer size before deriving the page index
and offset, mirroring tmc_etr_sync_perf_buffer().
Fixes: 06f5c2926aaa ("drivers/coresight: Add UltraSoc System Memory Buffer driver")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
---
drivers/hwtracing/coresight/ultrasoc-smb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwtracing/coresight/ultrasoc-smb.c b/drivers/hwtracing/coresight/ultrasoc-smb.c
index 5776f63468fa..20a950b9dd4f 100644
--- a/drivers/hwtracing/coresight/ultrasoc-smb.c
+++ b/drivers/hwtracing/coresight/ultrasoc-smb.c
@@ -337,6 +337,7 @@ static void smb_sync_perf_buffer(struct smb_drv_data *drvdata,
unsigned long to_copy;
long pg_idx, pg_offset;
+ head %= (unsigned long)buf->nr_pages << PAGE_SHIFT;
pg_idx = head >> PAGE_SHIFT;
pg_offset = head & (PAGE_SIZE - 1);
---
base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
change-id: 20260604-fixes-edc5369a8aca
Best regards,
--
Junrui Luo <moonafterrain@outlook.com>
^ permalink raw reply related
* Re: [PATCH net-next] net: stmmac: dwmac4: Report DCB feature capability
From: Maxime Chevallier @ 2026-06-04 7:24 UTC (permalink / raw)
To: Ovidiu Panait, andrew+netdev, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, alexandre.torgue, rmk+kernel, o.rempel
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20260603173644.24371-1-ovidiu.panait.rb@renesas.com>
Hi,
On 6/3/26 19:36, Ovidiu Panait wrote:
> Bit 16 of the MAC HW Feature1 register reports the DCB (Data Centre
> Bridging) feature. Read it so that dma_cap.dcben and the debugfs
> report it accurately. Right now it is always reported as being disabled.
>
> Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
This matches with what I have in the iMX8MP ref manual :)
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Thank you,
Maxime
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 1 +
> drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> index ffcd036d4c02..6382836828ba 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
> @@ -198,6 +198,7 @@ enum power_event {
> #define GMAC_HW_FEAT_AVSEL BIT(20)
> #define GMAC_HW_TSOEN BIT(18)
> #define GMAC_HW_FEAT_SPHEN BIT(17)
> +#define GMAC_HW_FEAT_DCBEN BIT(16)
> #define GMAC_HW_ADDR64 GENMASK(15, 14)
> #define GMAC_HW_TXFIFOSIZE GENMASK(10, 6)
> #define GMAC_HW_RXFIFOSIZE GENMASK(4, 0)
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
> index 28728271fbc9..829a23bdad01 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
> @@ -391,6 +391,7 @@ static int dwmac4_get_hw_feature(void __iomem *ioaddr,
> dma_cap->av = (hw_cap & GMAC_HW_FEAT_AVSEL) >> 20;
> dma_cap->tsoen = (hw_cap & GMAC_HW_TSOEN) >> 18;
> dma_cap->sphen = (hw_cap & GMAC_HW_FEAT_SPHEN) >> 17;
> + dma_cap->dcben = (hw_cap & GMAC_HW_FEAT_DCBEN) >> 16;
>
> dma_cap->addr64 = (hw_cap & GMAC_HW_ADDR64) >> 14;
> switch (dma_cap->addr64) {
^ permalink raw reply
* Re: [PATCH v3 5/5] KVM: arm64: nv: Create nested IPA direct map to speed up reverse map removal
From: Itaru Kitayama @ 2026-06-04 7:24 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon
In-Reply-To: <20260510145338.322962-6-weilin.chang@arm.com>
On Sun, May 10, 2026 at 03:53:38PM +0100, Wei-Lin Chang wrote:
> Iterating through the whole reverse map to find which entries to remove
> when handling guest hypervisor TLBIs is not efficient. Create a direct
> map that goes from nested IPA to canonical IPA so that the canonical
> IPA range affected by the TLBI can be quickly determined, then remove
> the entries in the reverse map accordingly.
>
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> arch/arm64/include/asm/kvm_host.h | 5 ++
> arch/arm64/kvm/mmu.c | 9 ++-
> arch/arm64/kvm/nested.c | 124 ++++++++++++++++++++++--------
> 3 files changed, 104 insertions(+), 34 deletions(-)
>
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index dc4c0bce1bbb..f9e95a023ec4 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -226,6 +226,11 @@ struct kvm_s2_mmu {
> bool nested_revmap_broken;
> /* canonical IPA to nested IPA range lookup */
> struct maple_tree nested_revmap_mt;
> + /*
> + * Nested IPA to canonical IPA range lookup, essentially a cache of
> + * the guest's stage-2.
> + */
> + struct maple_tree nested_direct_mt;
>
> #ifdef CONFIG_PTDUMP_STAGE2_DEBUGFS
> struct dentry *shadow_pt_debugfs_dentry;
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index ce0bd88cd3c1..77146431be6d 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1101,6 +1101,7 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
> struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
> struct kvm_pgtable *pgt = NULL;
> struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
Naming, do you prefer revmap over rmap?
> + struct maple_tree *direct_mt = &mmu->nested_direct_mt;
>
> write_lock(&kvm->mmu_lock);
> pgt = mmu->pgt;
> @@ -1111,8 +1112,12 @@ void kvm_free_stage2_pgd(struct kvm_s2_mmu *mmu)
> }
>
> if (kvm_is_nested_s2_mmu(kvm, mmu)) {
> - if (!mtree_empty(revmap_mt))
> - mtree_destroy(revmap_mt);
> + if (!mtree_empty(revmap_mt) || !mtree_empty(direct_mt)) {
> + mtree_lock(revmap_mt);
> + __mt_destroy(revmap_mt);
> + __mt_destroy(direct_mt);
> + mtree_unlock(revmap_mt);
> + }
> kvm_init_nested_s2_mmu(mmu);
> }
>
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index 96b88d9c0c2a..fcb6a88047e1 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -45,14 +45,14 @@ struct vncr_tlb {
> #define S2_MMU_PER_VCPU 2
>
> /*
> - * Per shadow S2 reverse map (IPA -> nested IPA range) maple tree payload
> - * layout:
> + * Per shadow S2 reverse & direct map maple tree payload layout:
> *
> - * bit 62: valid, prevents the case where the nested IPA is 0 and turning
> + * bit 62: valid, prevents the case where the address is 0 and turning
> * the whole value to 0
> - * bits 55-12: nested IPA bits 55-12
> + * bits 55-12: {nested, canonical} IPA bits 55-12
> * bit 0: UNKNOWN_IPA bit, 1 indicates we give up on tracking what nested
> - * IPA maps to this canonical IPA in the shadow stage-2
> + * IPA maps to this canonical IPA in the shadow stage-2, only used
> + * in reverse map
> */
> #define VALID_ENTRY BIT(62)
> #define ADDR_MASK GENMASK_ULL(55, 12)
> @@ -787,37 +787,67 @@ static struct kvm_s2_mmu *get_s2_mmu_nested(struct kvm_vcpu *vcpu)
> void kvm_remove_nested_revmap(struct kvm_s2_mmu *mmu, u64 nested_ipa, size_t size)
> {
> /*
> - * Iterate through the mt of this mmu, remove all canonical ipa ranges
> - * with !UNKNOWN_IPA that maps to ranges that are strictly within
> - * [addr, addr + size).
> + * For all ranges in direct_mt that are completely covered by the range
> + * we are TLBIing [gpa, gpa + size), remove the reverse map and its
> + * corresponding direct map together, when these conditions are met:
> + *
> + * 1. The reverse map is not UNKNOWN_IPA.
> + * 2. The reverse map is completely covered by the TLBI range.
> + * 3. The reverse map and the direct map are symmetric i.e. they map to
> + * each other, with the same size.
> + *
> + * Symmetry must be checked because there are three places where the
> + * direct map could become inconsistent:
> + *
> + * 1. Direct map removal failure during an mmu notifier in
> + * unmap_mmu_ipa_range().
> + * 2. Direct map insertion failure during an s2 fault in
> + * kvm_record_nested_revmap().
> + * 3. Direct map removal failure during a previous call of this very
> + * function.
> */
> struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
> - void *entry;
> - u64 entry_val, nested_ipa_end = nested_ipa + size;
> - u64 this_nested_ipa, this_nested_ipa_end;
> - size_t revmap_size;
> -
> - MA_STATE(mas_rev, revmap_mt, 0, ULONG_MAX);
> -
> + struct maple_tree *direct_mt = &mmu->nested_direct_mt;
> + gpa_t nested_ipa_end = nested_ipa + size - 1;
> + u64 entry_dir;
> + struct mapping {
> + u64 from;
> + u64 to;
> + size_t size;
entry_dir sounds like a directory related one, if entry_drect is too
long, perhaps entry_d? But it's up to you and Marc and Oliver.
Thanks,
Itaru.
> + };
> +
> + MA_STATE(mas_dir, direct_mt, nested_ipa, nested_ipa_end);
> mtree_lock(revmap_mt);
> - mas_for_each(&mas_rev, entry, ULONG_MAX) {
> - entry_val = xa_to_value(entry);
> - if (entry_val & UNKNOWN_IPA)
> - continue;
> -
> - revmap_size = mas_rev.last - mas_rev.index + 1;
> - this_nested_ipa = entry_val & ADDR_MASK;
> - this_nested_ipa_end = this_nested_ipa + revmap_size;
> -
> - if (this_nested_ipa >= nested_ipa &&
> - this_nested_ipa_end <= nested_ipa_end) {
> - /*
> - * As the shadow stage-2 is about to be unmapped
> - * after this function, it doesn't matter whether the
> - * removal of the reverse map failed or not.
> - */
> + entry_dir = xa_to_value(mas_find_range(&mas_dir, nested_ipa_end));
> +
> + while (entry_dir && mas_dir.index <= nested_ipa_end) {
> + struct mapping dir, rev;
> + u64 entry_rev;
> +
> + dir.from = mas_dir.index;
> + dir.to = entry_dir & ADDR_MASK;
> + dir.size = mas_dir.last - mas_dir.index + 1;
> +
> + /* Use ipa range to find the corresponding entry in revmap. */
> + MA_STATE(mas_rev, revmap_mt, dir.to, dir.to + dir.size - 1);
> + entry_rev = xa_to_value(mas_find_range(&mas_rev,
> + dir.to + dir.size - 1));
> +
> + rev.from = mas_rev.index;
> + rev.to = entry_rev & ADDR_MASK;
> + rev.size = mas_rev.last - mas_rev.index + 1;
> +
> + /* The three conditions outlined above. */
> + if (entry_rev && !(entry_rev & UNKNOWN_IPA) &&
> + dir.from >= nested_ipa &&
> + dir.from + dir.size - 1 <= nested_ipa_end &&
> + dir.from == rev.to &&
> + rev.from == dir.to &&
> + dir.size == rev.size) {
> + mas_store_gfp(&mas_dir, NULL, GFP_NOWAIT | __GFP_ACCOUNT);
> mas_store_gfp(&mas_rev, NULL, GFP_NOWAIT | __GFP_ACCOUNT);
> }
> + entry_dir = xa_to_value(mas_find_range(&mas_dir, nested_ipa_end));
> }
> mtree_unlock(revmap_mt);
> }
> @@ -826,9 +856,12 @@ void kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
> gpa_t fault_ipa, size_t map_size)
> {
> struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
> + struct maple_tree *direct_mt = &mmu->nested_direct_mt;
> gpa_t ipa_end = ipa + map_size - 1;
> + gpa_t fault_ipa_end = fault_ipa + map_size - 1;
> u64 entry, new_entry = 0;
> MA_STATE(mas_rev, revmap_mt, ipa, ipa_end);
> + MA_STATE(mas_dir, direct_mt, fault_ipa, fault_ipa_end);
>
> if (mmu->nested_revmap_broken)
> return;
> @@ -861,6 +894,15 @@ void kvm_record_nested_revmap(gpa_t ipa, struct kvm_s2_mmu *mmu,
> if (mas_store_gfp(&mas_rev, xa_mk_value(new_entry),
> GFP_NOWAIT | __GFP_ACCOUNT))
> mmu->nested_revmap_broken = true;
> +
> + /*
> + * Add direct map but ignore the result, missing a direct map does not
> + * affect correctness.
> + */
> + if (new_entry & VALID_ENTRY && !mmu->nested_revmap_broken)
> + mas_store_gfp(&mas_dir, xa_mk_value(ipa | VALID_ENTRY),
> + GFP_NOWAIT | __GFP_ACCOUNT);
> +
> unlock:
> mtree_unlock(revmap_mt);
> }
> @@ -872,6 +914,8 @@ void kvm_init_nested_s2_mmu(struct kvm_s2_mmu *mmu)
> mmu->nested_stage2_enabled = false;
> atomic_set(&mmu->refcnt, 0);
> mt_init(&mmu->nested_revmap_mt);
> + mt_init_flags(&mmu->nested_direct_mt, MT_FLAGS_LOCK_EXTERN);
> + mt_set_external_lock(&mmu->nested_direct_mt, &mmu->nested_revmap_mt.ma_lock);
> mmu->nested_revmap_broken = false;
> }
>
> @@ -1250,7 +1294,10 @@ void kvm_nested_s2_wp(struct kvm *kvm)
>
> static void reset_revmap_and_unmap(struct kvm_s2_mmu *mmu, bool may_block)
> {
> - mtree_destroy(&mmu->nested_revmap_mt);
> + mtree_lock(&mmu->nested_revmap_mt);
> + __mt_destroy(&mmu->nested_revmap_mt);
> + __mt_destroy(&mmu->nested_direct_mt);
> + mtree_unlock(&mmu->nested_revmap_mt);
> mmu->nested_revmap_broken = false;
> kvm_stage2_unmap_range(mmu, 0, kvm_phys_size(mmu), may_block);
> }
> @@ -1259,11 +1306,14 @@ static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
> size_t unmap_size, bool may_block)
> {
> struct maple_tree *revmap_mt = &mmu->nested_revmap_mt;
> + struct maple_tree *direct_mt = &mmu->nested_direct_mt;
> gpa_t ipa = gpa;
> gpa_t ipa_end = gpa + unmap_size - 1;
> + gpa_t nested_ipa, nested_ipa_end;
> u64 entry;
> size_t entry_size;
> MA_STATE(mas_rev, revmap_mt, gpa, ipa_end);
> + MA_STATE(mas_dir, direct_mt, 0, ULONG_MAX);
>
> if (mmu->nested_revmap_broken) {
> reset_revmap_and_unmap(mmu, may_block);
> @@ -1292,6 +1342,16 @@ static void unmap_mmu_ipa_range(struct kvm_s2_mmu *mmu, gpa_t gpa,
> */
> mas_store_gfp(&mas_rev, NULL, GFP_NOWAIT | __GFP_ACCOUNT);
>
> + /*
> + * Try to also remove the direct map, it is okay if this fails,
> + * as we check for direct map consistency in
> + * kvm_remove_nested_revmap().
> + */
> + nested_ipa = entry & ADDR_MASK;
> + nested_ipa_end = nested_ipa + entry_size - 1;
> + mas_set_range(&mas_dir, nested_ipa, nested_ipa_end);
> + mas_store_gfp(&mas_dir, NULL, GFP_NOWAIT | __GFP_ACCOUNT);
> +
> mtree_unlock(revmap_mt);
> kvm_stage2_unmap_range(mmu, entry & ADDR_MASK, entry_size,
> may_block);
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH 10/12] crypto: atmel - update workqueue flags and add flush on exit
From: Lothar Rubusch @ 2026-06-04 7:22 UTC (permalink / raw)
To: Marco Crivellari
Cc: alexandre.belloni, claudiu.beznea, davem, herbert,
linux-arm-kernel, linux-crypto, linux-kernel, nicolas.ferre,
thorsten.blum
In-Reply-To: <20260601090329.52616-1-marco.crivellari@suse.com>
Hi Marco,
On Mon, Jun 1, 2026 at 11:03 AM Marco Crivellari
<marco.crivellari@suse.com> wrote:
>
> Hi,
>
> > Update workqueue initialization to use WQ_MEM_RECLAIM instead of
> > WQ_PERCPU
>
> Not sure if you're working on this series right now, but this must keep
> the WQ_PERCPU flag. WQ_PERCPU has been added to mark explicitly mark
> workqueue that are per-CPU (it is the complement of WQ_UNBOUND).
>
Yes. I plan on splitting up the material presented in this series.
This particular patch was one of the things I was a unsure, if this
actually could be done.
Therefore it was already separted out. I highly appreciate your
feedback. I will drop this
change and leave WQ_PERCPU until I get there.
>
> Thanks!
>
^ permalink raw reply
* Re: [PATCH v7 10/11] iommu/arm-smmu-v3: Invoke pm_runtime before hw access
From: Pranjal Shrivastava @ 2026-06-04 7:18 UTC (permalink / raw)
To: Daniel Mentz
Cc: Nicolin Chen, iommu, Will Deacon, Joerg Roedel, Robin Murphy,
Jason Gunthorpe, Mostafa Saleh, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <CAE2F3rDeZe+w7-V6hyJtSOwCj619E5SNtjJjZ1-yu1sVdf=35A@mail.gmail.com>
On Wed, Jun 03, 2026 at 03:18:32PM -0700, Daniel Mentz wrote:
> On Thu, May 28, 2026 at 2:46 PM Pranjal Shrivastava <praan@google.com> wrote:
> >
> > On Thu, May 28, 2026 at 01:28:15PM -0700, Nicolin Chen wrote:
> > > On Wed, May 27, 2026 at 10:14:06PM +0000, Pranjal Shrivastava wrote:
> > > > TLB and CFG invalidations are
> > > > elided if the SMMU is suspended by observing the CMDQ_PROD_STOP_FLAG via
> > > > the arm_smmu_can_elide() helper.
> > >
> > > All the arm_smmu_can_elide() call sites here would eventually elide
> > > the commands in arm_smmu_cmdq_issue_cmdlist() that is already gated
> > > by CMDQ_PROD_STOP_FLAG? It doesn't seem necessary to gate again?
> >
> > While issue_cmdlist() would eventually elide these commands, the
> > can_elide() check is necessary to return early during suspension.
> >
> > This avoids unnecessary stack allocation, cmd building, and spinlock
> > contention on the cmdq->lock for threads that are anyway about to be
> > elided.
> >
> > By dropping these requests immediately, we significantly reduce cacheline
> > bouncing and contention during unmap storms. Furthermore, the early check
> > also allows us to specifically trigger the WARN_ON_ONCE() for broken
> > devlinks.
>
> Hi Pranjal,
>
> Have you observed unmap storms in a real-world use case, or is this a
> preemptive optimization? I would not expect a high rate of map/unmap
> operations while the SMMU is suspended. If a client device calls
> iommu_map/iommu_unmap (directly or indirectly), it suggests the client
> device is RPM_ACTIVE, meaning the SMMU should be active as well.
>
> I am in favor of removing arm_smmu_can_elide().
I saw some with DMA_FQ (fq_timer does batched async invalidations) but
the early ellision doesn't really help with perf which I agreed to in my
reply to Nicolin as well.
The early checks were dropped in v8 (except for invs_array and for the
WARN_ON in inv_master).
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH] char: xilinx_hwicap: replace in_be32/out_be32 with ioread32be/iowrite32be
From: Rosen Penev @ 2026-06-04 7:13 UTC (permalink / raw)
To: Michal Simek, Rosen Penev
Cc: linux-kernel, Arnd Bergmann, chleroy, Greg Kroah-Hartman,
moderated list:ARM/ZYNQ ARCHITECTURE
In-Reply-To: <e331f8d0-11e7-40c1-b4f5-76a591e93bd9@amd.com>
On Wed Jun 3, 2026 at 11:30 PM PDT, Michal Simek wrote:
>
>
> On 6/3/26 21:52, Rosen Penev wrote:
>> On Mon, Jun 1, 2026 at 11:22 PM Michal Simek <michal.simek@amd.com> wrote:
>>>
>>>
>>>
>>> On 6/2/26 05:57, Rosen Penev wrote:
>>>> Mechanical conversion of the ppc4xx-specific accessors to the generic
>>>> portable helpers.
>>>>
>>>> As a result, COMPILE_TEST is added for extra compile coverage.
>>>>
>>>> Assisted-by: opencode:big-pickle
>>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>>>> ---
>>>> drivers/char/Kconfig | 2 +-
>>>> drivers/char/xilinx_hwicap/buffer_icap.c | 16 +++++------
>>>> drivers/char/xilinx_hwicap/fifo_icap.c | 34 +++++++++++-------------
>>>> 3 files changed, 24 insertions(+), 28 deletions(-)
>>>
>>> I don't really mind about this because I think that we can also remove the whole
>>> driver.
>> I looked into this. The problem here is that there are actual users
>>
>> arch/microblaze/boot/dts/system.dts
>>
>> and
>>
>> arch/mips/boot/dts/xilfpga/nexys4ddr.dts
>
>
> I can't see users of it.
Hrm looks like I just grepped xlns,xps and found system.dts. You're
right.
>
> on v7.1-rc1
> $ git grep opb-hwicap
> Documentation/devicetree/bindings/xilinx.txt:126:
> "xlnx,opb-hwicap-1.00.b".
> drivers/char/xilinx_hwicap/xilinx_hwicap.c:733: { .compatible =
> "xlnx,opb-hwicap-1.00.b", .data = &buffer_icap_config},
> $ git grep xps-hwicap
> Documentation/devicetree/bindings/xilinx.txt:125: - compatible :
> should contain "xlnx,xps-hwicap-1.00.a" or
> drivers/char/xilinx_hwicap/xilinx_hwicap.c:734: { .compatible =
> "xlnx,xps-hwicap-1.00.a", .data = &fifo_icap_config},
>
> Thanks,
> Michal
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: spi: Add for Nuvoton MA35D1 SoC QSPI Controller
From: Chi-Wen Weng @ 2026-06-04 7:07 UTC (permalink / raw)
To: Conor Dooley
Cc: broonie, robh, krzk+dt, conor+dt, linux-arm-kernel, linux-spi,
devicetree, linux-kernel, cwweng
In-Reply-To: <20260603-daybed-absentee-1b64f5caabe0@spud>
Hi Conor,
Thanks for the review.
> Missing commit message for one, but why can't your Nuvoton mail be used
> here?
I apologize for the missing commit message; I will add a proper
description in v2.
Regarding the email address, my Nuvoton mail adds a corporate
confidentiality disclaimer to outgoing
external mail, so I use my personal address for sending kernel patches.
> Sashiko had two comments about resets and num-cs that looked valid.
Noted. I will add the `num-cs` and `resets` properties in v2.
> Drop this flash node, it serves no purpose here.
Understood, I will remove the flash child node from the example in v2.
Thanks,
Chi-Wen Weng
Conor Dooley 於 2026/6/3 下午 11:24 寫道:
> On Wed, Jun 03, 2026 at 12:35:50PM +0800, Chi-Wen Weng wrote:
>> Signed-off-by: Chi-Wen Weng <cwweng.linux@gmail.com>
> Missing commit message for one, but why can't your Nuvoton mail be used
> here?
>
> Sashiko had two comments about resets and num-cs that looked valid.
>
>> ---
>> .../bindings/spi/nuvoton,ma35d1-qspi.yaml | 61 +++++++++++++++++++
>> 1 file changed, 61 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
>> new file mode 100644
>> index 000000000000..f7b9cb52d8e5
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
>> @@ -0,0 +1,61 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/spi/nuvoton,ma35d1-qspi.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Nuvoton MA35D1 Quad SPI Controller
>> +
>> +maintainers:
>> + - Chi-Wen Weng <cwweng@nuvoton.com>
>> +
>> +allOf:
>> + - $ref: spi-controller.yaml#
>> +
>> +properties:
>> + compatible:
>> + const: nuvoton,ma35d1-qspi
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + clocks:
>> + maxItems: 1
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - clocks
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
>> +
>> + soc {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + spi@40680000 {
>> + compatible = "nuvoton,ma35d1-qspi";
>> + reg = <0x0 0x40680000 0x0 0x100>;
>> + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&clk QSPI0_GATE>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + flash@0 {
> Drop this flash node, it serves no purpose here.
>
> pw-bot: changes-requested
>
> Thanks,
> Conor.
>
>> + compatible = "jedec,spi-nor";
>> + spi-max-frequency = <30000000>;
>> + reg = <0>;
>> + spi-rx-bus-width = <4>;
>> + spi-tx-bus-width = <1>;
>> + };
>> + };
>> + };
>> +
>> --
>> 2.25.1
>>
^ permalink raw reply
* [PATCH net] net: airoha: Add NULL check for of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues()
From: ZhaoJinming @ 2026-06-04 7:03 UTC (permalink / raw)
To: lorenzo, andrew+netdev, davem, edumazet, kuba, pabeni
Cc: horms, linux-arm-kernel, linux-mediatek, netdev, linux-kernel,
stable, ZhaoJinming
of_reserved_mem_lookup() may return NULL if the reserved memory region
referenced by the "memory-region" phandle is not found in the reserved
memory table (e.g. due to a misconfigured DTS or a removed
memory-region node). The current code dereferences the returned
pointer without checking for NULL, leading to a kernel NULL pointer
dereference at the following lines:
dma_addr = rmem->base; // line 1156
num_desc = div_u64(rmem->size, buf_size); // line 1160
Add a NULL check after of_reserved_mem_lookup() and return -ENODEV if
the lookup fails, which is consistent with the existing error handling
for of_parse_phandle() failure in the same code block.
Fixes: 3a1ce9e3d01b ("net: airoha: Add the capability to allocate hwfd buffers via reserved-memory")
Cc: stable@vger.kernel.org
Signed-off-by: ZhaoJinming<zhaojinming@uniontech.com>
---
drivers/net/ethernet/airoha/airoha_eth.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index cecd66251dba..2444d3275a81 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1153,6 +1153,9 @@ static int airoha_qdma_init_hfwd_queues(struct airoha_qdma *qdma)
rmem = of_reserved_mem_lookup(np);
of_node_put(np);
+ if (!rmem)
+ return -ENODEV;
+
dma_addr = rmem->base;
/* Compute the number of hw descriptors according to the
* reserved memory size and the payload buffer size
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] KVM/arm64: vgic-its: Fix memory leak when vgic_its_set_abi() fails
From: Jackie Liu @ 2026-06-04 6:59 UTC (permalink / raw)
To: Oliver Upton; +Cc: maz, linux-arm-kernel, yuzenghui, will, kvmarm
In-Reply-To: <aiEeKGsLg9098OUt@kernel.org>
2026年6月4日 14:41, "Oliver Upton" <oupton@kernel.org mailto:oupton@kernel.org?to=%22Oliver%20Upton%22%20%3Coupton%40kernel.org%3E > 写到:
>
> On Thu, Jun 04, 2026 at 11:14:26AM +0800, Jackie Liu wrote:
>
> >
> > From: Jackie Liu <liuyun01@kylinos.cn>
> >
> > In vgic_its_create(), if vgic_its_set_abi() fails after allocating the
> > its structure and setting kvm state, the allocated 'its' is leaked
> > because the function returns without freeing it.
> >
> > Fix by rolling back the kvm state flags and freeing the its structure
> > when vgic_its_set_abi() returns an error.
> >
> > Fixes: 71afe470e20d ("KVM: arm64: vgic-its: Introduce migration ABI infrastructure")
> > Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
> >
> vgic_its_set_abi() always succeeds so there's no actual memory leak
> here. I'd prefer getting rid of the return value instead.
That was my original thought as well. However, I kept the defensive cleanup logic in place
to make future extensions easier. This way, if additional resource allocation paths are
introduced later, we're less likely to miss the corresponding cleanup.
That said, looking at the current code, the return value no longer serves any real
purpose, so removing it would also be a reasonable and cleaner approach.
I'll send a V2 with this change.
Thanks.
Jackie
>
> Thanks,
> Oliver
>
^ permalink raw reply
* RE: [PATCH v2] arm64: dts: imx94: Add Root Port node and PERST property
From: Sherry Sun @ 2026-06-04 6:49 UTC (permalink / raw)
To: Hongxing Zhu (OSS), robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, Frank Li, s.hauer@pengutronix.de,
festevam@gmail.com
Cc: kernel@pengutronix.de, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Hongxing Zhu
In-Reply-To: <20260604062846.310810-1-hongxing.zhu@oss.nxp.com>
> From: Richard Zhu <hongxing.zhu@nxp.com>
>
> Since describing the PCIe PERST# property under Host Bridge node is now
> deprecated, it is recommended to add it to the Root Port node, so creating the
> Root Port node and add the reset-gpios property in Root Port.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Sherry Sun <sherry.sun@nxp.com>
Best Regards
Sherry
> ---
> arch/arm64/boot/dts/freescale/imx94.dtsi | 11 +++++++++++
> arch/arm64/boot/dts/freescale/imx943-evk.dts | 10 ++++++++--
> arch/arm64/boot/dts/freescale/imx943.dtsi | 11 +++++++++++
> 3 files changed, 30 insertions(+), 2 deletions(-)
> ---
> Changes in v2:
> - Delete reset-gpio properties in PCIe bridge node.
> - Correct the "reset-gpio" property to "reset-gpios".
>
> Since the patch-set [1] issued by Sherry had been landed. Add according
> changes on i.MX943 board too.
> [1] https://lkml.org/lkml/2026/6/1/1461
>
> diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi
> b/arch/arm64/boot/dts/freescale/imx94.dtsi
> index 1f9035e6cf159..dfbb73603cb24 100644
> --- a/arch/arm64/boot/dts/freescale/imx94.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
> @@ -1411,6 +1411,17 @@ pcie0: pcie@4c300000 {
> power-domains = <&scmi_devpd
> IMX94_PD_HSIO_TOP>;
> fsl,max-link-speed = <3>;
> status = "disabled";
> +
> + pcie0_port0: pcie@0 {
> + compatible = "pciclass,0604";
> + device_type = "pci";
> + reg = <0x0 0x0 0x0 0x0 0x0>;
> + bus-range = <0x01 0xff>;
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges;
> + };
> };
>
> pcie0_ep: pcie-ep@4c300000 {
> diff --git a/arch/arm64/boot/dts/freescale/imx943-evk.dts
> b/arch/arm64/boot/dts/freescale/imx943-evk.dts
> index 7cfd424689507..99d66484ded04 100644
> --- a/arch/arm64/boot/dts/freescale/imx943-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx943-evk.dts
> @@ -1034,12 +1034,15 @@ &pcie0 {
> <&pcie_ref_clk>;
> clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
> "ref", "extref";
> - reset-gpio = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
> vpcie3v3aux-supply = <®_m2_wlan>;
> supports-clkreq;
> status = "okay";
> };
>
> +&pcie0_port0 {
> + reset-gpios = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>; };
> +
> &pcie0_ep {
> pinctrl-0 = <&pinctrl_pcie0>;
> pinctrl-names = "default";
> @@ -1058,12 +1061,15 @@ &pcie1 {
> <&pcie_ref_clk>;
> clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
> "ref", "extref";
> - reset-gpio = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
> vpcie3v3aux-supply = <®_slot_pwr>;
> supports-clkreq;
> status = "okay";
> };
>
> +&pcie1_port0 {
> + reset-gpios = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>; };
> +
> &pcie1_ep {
> pinctrl-0 = <&pinctrl_pcie1>;
> pinctrl-names = "default";
> diff --git a/arch/arm64/boot/dts/freescale/imx943.dtsi
> b/arch/arm64/boot/dts/freescale/imx943.dtsi
> index cf5b3dbb47ff7..01152fd0efa5e 100644
> --- a/arch/arm64/boot/dts/freescale/imx943.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx943.dtsi
> @@ -255,6 +255,17 @@ pcie1: pcie@4c380000 {
> power-domains = <&scmi_devpd
> IMX94_PD_HSIO_TOP>;
> fsl,max-link-speed = <3>;
> status = "disabled";
> +
> + pcie1_port0: pcie@0 {
> + compatible = "pciclass,0604";
> + device_type = "pci";
> + reg = <0x0 0x0 0x0 0x0 0x0>;
> + bus-range = <0x01 0xff>;
> +
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges;
> + };
> };
>
> pcie1_ep: pcie-ep@4c380000 {
> --
> 2.34.1
^ permalink raw reply
* RE: [PATCH 01/11] net: wwan: t9xx: Add PCIe core
From: Wu. JackBB (GSM) @ 2026-06-04 6:42 UTC (permalink / raw)
To: Jagielski, Jedrzej, Loic Poulain, Sergey Ryazanov, Johannes Berg,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng,
Matthias Brugger, AngeloGioacchino Del Regno, Simon Horman,
Jonathan Corbet, Shuah Khan
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <PH0PR11MB5902127C590230B9FE50F78AF0152@PH0PR11MB5902.namprd11.prod.outlook.com>
> Sent: Friday, May 29, 2026 12:32 PM
>
> > +
>
> please also take a look on sashiko notes, there is some number of them
Hi Jagielski,
Thank you for your review. We have fixed some issues and are still discussing others with MediaTek. All of them will be addressed in V2.
Regarding sashiko notes, how should I handle them if discussion is needed? I cannot find sashiko's email address, and its website does not have a reply option.
For example:
https://sashiko.dev/#/patchset/20260529-t9xx_driver_v1-v1-0-bdbfe2c01e57%40compal.com?part=2
Q1:
The commit message mentions implementing TX and RX services, but the patch primarily adds empty structures and boilerplate code. Is the patch missing the actual TX/RX implementation described here?
Reply:
We plan to update the commit message. Would the following be acceptable?
Add the control plane transaction layer framework for the t9xx
WWAN driver, including configuration options, device structure
definitions, and initialization/cleanup functions.
The actual TX/RX service implementations that use this framework
are introduced in subsequent patches.
Thanks.
================================================================================================================================================================
This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
================================================================================================================================================================
^ permalink raw reply
* Re: [PATCH] KVM/arm64: vgic-its: Fix memory leak when vgic_its_set_abi() fails
From: Oliver Upton @ 2026-06-04 6:41 UTC (permalink / raw)
To: Jackie Liu; +Cc: maz, linux-arm-kernel, yuzenghui, will, kvmarm
In-Reply-To: <20260604031426.16109-1-liu.yun@linux.dev>
On Thu, Jun 04, 2026 at 11:14:26AM +0800, Jackie Liu wrote:
> From: Jackie Liu <liuyun01@kylinos.cn>
>
> In vgic_its_create(), if vgic_its_set_abi() fails after allocating the
> its structure and setting kvm state, the allocated 'its' is leaked
> because the function returns without freeing it.
>
> Fix by rolling back the kvm state flags and freeing the its structure
> when vgic_its_set_abi() returns an error.
>
> Fixes: 71afe470e20d ("KVM: arm64: vgic-its: Introduce migration ABI infrastructure")
> Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
vgic_its_set_abi() always succeeds so there's no actual memory leak
here. I'd prefer getting rid of the return value instead.
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH] char: xilinx_hwicap: replace in_be32/out_be32 with ioread32be/iowrite32be
From: Michal Simek @ 2026-06-04 6:30 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-kernel, Arnd Bergmann, chleroy, Greg Kroah-Hartman,
moderated list:ARM/ZYNQ ARCHITECTURE
In-Reply-To: <CAKxU2N_U=Wk4f9ankopVBMRGH+YdTn8FOuyoDs4Of04o63bTHg@mail.gmail.com>
On 6/3/26 21:52, Rosen Penev wrote:
> On Mon, Jun 1, 2026 at 11:22 PM Michal Simek <michal.simek@amd.com> wrote:
>>
>>
>>
>> On 6/2/26 05:57, Rosen Penev wrote:
>>> Mechanical conversion of the ppc4xx-specific accessors to the generic
>>> portable helpers.
>>>
>>> As a result, COMPILE_TEST is added for extra compile coverage.
>>>
>>> Assisted-by: opencode:big-pickle
>>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>>> ---
>>> drivers/char/Kconfig | 2 +-
>>> drivers/char/xilinx_hwicap/buffer_icap.c | 16 +++++------
>>> drivers/char/xilinx_hwicap/fifo_icap.c | 34 +++++++++++-------------
>>> 3 files changed, 24 insertions(+), 28 deletions(-)
>>
>> I don't really mind about this because I think that we can also remove the whole
>> driver.
> I looked into this. The problem here is that there are actual users
>
> arch/microblaze/boot/dts/system.dts
>
> and
>
> arch/mips/boot/dts/xilfpga/nexys4ddr.dts
I can't see users of it.
on v7.1-rc1
$ git grep opb-hwicap
Documentation/devicetree/bindings/xilinx.txt:126:
"xlnx,opb-hwicap-1.00.b".
drivers/char/xilinx_hwicap/xilinx_hwicap.c:733: { .compatible =
"xlnx,opb-hwicap-1.00.b", .data = &buffer_icap_config},
$ git grep xps-hwicap
Documentation/devicetree/bindings/xilinx.txt:125: - compatible :
should contain "xlnx,xps-hwicap-1.00.a" or
drivers/char/xilinx_hwicap/xilinx_hwicap.c:734: { .compatible =
"xlnx,xps-hwicap-1.00.a", .data = &fifo_icap_config},
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v8 11/12] iommu/arm-smmu-v3: Invoke pm_runtime before hw access
From: Pranjal Shrivastava @ 2026-06-04 6:27 UTC (permalink / raw)
To: Daniel Mentz
Cc: iommu, Will Deacon, Joerg Roedel, Robin Murphy, Jason Gunthorpe,
Mostafa Saleh, Nicolin Chen, Ashish Mhetre, linux-arm-kernel
In-Reply-To: <CAE2F3rCPgnFU=d5At1zrOLhsuVEbsweogOHGz9gDddRx73zRtw@mail.gmail.com>
On Wed, Jun 03, 2026 at 01:28:19PM -0700, Daniel Mentz wrote:
> On Mon, Jun 1, 2026 at 2:59 PM Pranjal Shrivastava <praan@google.com> wrote:
> > @@ -2361,8 +2394,33 @@ static irqreturn_t arm_smmu_handle_gerror(struct arm_smmu_device *smmu)
> > static irqreturn_t arm_smmu_gerror_handler(int irq, void *dev)
> > {
> > struct arm_smmu_device *smmu = dev;
> > + irqreturn_t ret;
> > +
> > + /*
> > + * Global Errors are only processed if the SMMU is active.
> > + *
> > + * If the STOP_FLAG is set (can_elide == true), the hardware is
> > + * either already disabled or in the process of being disabled.
> > + * Any errors captured during the quiesce/drain phase will be
> > + * handled by the explicit arm_smmu_handle_gerror() call at the
> > + * end of arm_smmu_runtime_suspend() callback. On resume, the
> > + * STOP_FLAG is cleared before interrupts are re-enabled, ensuring
> > + * no valid errors are missed.
> > + *
> > + * A lockless check is favoured here over a dynamic PM core check
> > + * since the runtime_pm_get_if_active would return false during
> > + * transient states like RPM_RESUMING & ignore level-triggered
> > + * interrupts.
> > + */
> > + if (arm_smmu_cmdq_can_elide(smmu)) {
> > + dev_err(smmu->dev,
> > + "Ignoring gerror interrupt because the SMMU is suspended\n");
> > + return IRQ_NONE;
> > + }
>
> Have you considered using arm_smmu_rpm_get() here instead?
> I can see two issues with the currenlty proposal:
> * Returning IRQ_NONE when an interrupt is indeed active and needs to
> be handled. This might be interpreted as a spurious interrupt
> * Nothing is preventing the suspend handler from running while
> arm_smmu_gerror_handler is in the middle of handling an interrupt
>
> I understand that using arm_smmu_rpm_get() also has downsides,
> including an unnecessary resume operation when the SMMU is already in
> RPM_SUSPENDING state. However, using arm_smmu_rpm_get() would make it
> easier to ensure correctness.
>
I don't think using arm_smmu_rpm_get() here is possible..
GERROR is registered as a hard IRQ handler, so calling rpm_get (which
can sleep) would be wrong.
Regarding the race, the STOP_FLAG is set at the very beginning of the
suspend sequence. If an IRQ fires after that, we return IRQ_NONE and
let the explicit arm_smmu_handle_gerror() call at the end of
runtime_suspend catch and clear it. After CMDQEN, PRIQEN, EVTQEN &
SMMUEN are all cleared, getting a Gerror should be treated as spurious
That said, I understand your concerns about a real IRQ being interpreted
as a spurious one, and creating an IRQ storm since the gerror register
isn't really written. I have 2 ideas here:
1. We could have a "suspended" flag and check it with can_elide here:
arm_smmu_cmdq_can_elide() && is_suspended() to correctly return IRQ_NONE
2. We could explicitly disable Gerror in IRQ_CTRL write after setting
the CMDQ_STOP_FLAG. Even if there are Gerrors during the CMDQ drain,
we'll catcup to those at the end of our suspend callback.
I'm more inclined towards 2 as it prevents potential races (execution of
an IRQ handler with handle_gerror calls at the end of the suspend).
WDYT?
Thanks.
Praan
^ permalink raw reply
* [PATCH v2] arm64: dts: imx94: Add Root Port node and PERST property
From: hongxing.zhu @ 2026-06-04 6:28 UTC (permalink / raw)
To: sherry.sun, robh, krzk+dt, conor+dt, frank.li, s.hauer, festevam
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel,
Richard Zhu
From: Richard Zhu <hongxing.zhu@nxp.com>
Since describing the PCIe PERST# property under Host Bridge node is now
deprecated, it is recommended to add it to the Root Port node, so
creating the Root Port node and add the reset-gpios property in Root
Port.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
arch/arm64/boot/dts/freescale/imx94.dtsi | 11 +++++++++++
arch/arm64/boot/dts/freescale/imx943-evk.dts | 10 ++++++++--
arch/arm64/boot/dts/freescale/imx943.dtsi | 11 +++++++++++
3 files changed, 30 insertions(+), 2 deletions(-)
---
Changes in v2:
- Delete reset-gpio properties in PCIe bridge node.
- Correct the "reset-gpio" property to "reset-gpios".
Since the patch-set [1] issued by Sherry had been landed. Add according
changes on i.MX943 board too.
[1] https://lkml.org/lkml/2026/6/1/1461
diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
index 1f9035e6cf159..dfbb73603cb24 100644
--- a/arch/arm64/boot/dts/freescale/imx94.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
@@ -1411,6 +1411,17 @@ pcie0: pcie@4c300000 {
power-domains = <&scmi_devpd IMX94_PD_HSIO_TOP>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcie0_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie0_ep: pcie-ep@4c300000 {
diff --git a/arch/arm64/boot/dts/freescale/imx943-evk.dts b/arch/arm64/boot/dts/freescale/imx943-evk.dts
index 7cfd424689507..99d66484ded04 100644
--- a/arch/arm64/boot/dts/freescale/imx943-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx943-evk.dts
@@ -1034,12 +1034,15 @@ &pcie0 {
<&pcie_ref_clk>;
clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
"ref", "extref";
- reset-gpio = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
vpcie3v3aux-supply = <®_m2_wlan>;
supports-clkreq;
status = "okay";
};
+&pcie0_port0 {
+ reset-gpios = <&pcal6416_i2c3_u46 3 GPIO_ACTIVE_LOW>;
+};
+
&pcie0_ep {
pinctrl-0 = <&pinctrl_pcie0>;
pinctrl-names = "default";
@@ -1058,12 +1061,15 @@ &pcie1 {
<&pcie_ref_clk>;
clock-names = "pcie", "pcie_bus", "pcie_phy", "pcie_aux",
"ref", "extref";
- reset-gpio = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
vpcie3v3aux-supply = <®_slot_pwr>;
supports-clkreq;
status = "okay";
};
+&pcie1_port0 {
+ reset-gpios = <&pcal6416_i2c3_u46 1 GPIO_ACTIVE_LOW>;
+};
+
&pcie1_ep {
pinctrl-0 = <&pinctrl_pcie1>;
pinctrl-names = "default";
diff --git a/arch/arm64/boot/dts/freescale/imx943.dtsi b/arch/arm64/boot/dts/freescale/imx943.dtsi
index cf5b3dbb47ff7..01152fd0efa5e 100644
--- a/arch/arm64/boot/dts/freescale/imx943.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx943.dtsi
@@ -255,6 +255,17 @@ pcie1: pcie@4c380000 {
power-domains = <&scmi_devpd IMX94_PD_HSIO_TOP>;
fsl,max-link-speed = <3>;
status = "disabled";
+
+ pcie1_port0: pcie@0 {
+ compatible = "pciclass,0604";
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
};
pcie1_ep: pcie-ep@4c380000 {
--
2.34.1
^ permalink raw reply related
* [PATCH] arm64: dts: nuvoton: ma35d1: add CAN nodes
From: Zi-Yu Chen @ 2026-06-04 6:01 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt
Cc: ychuang3, schung, linux-arm-kernel, devicetree, linux-kernel,
Zi-Yu Chen
Add controller nodes for the four Bosch M_CAN blocks found on the
Nuvoton MA35D1 SoC.
Additionally, configure pinctrl and enable CAN1 and CAN3 on the
MA35D1 SOM board.
Signed-off-by: Zi-Yu Chen <zychennvt@gmail.com>
---
.../boot/dts/nuvoton/ma35d1-som-256m.dts | 26 ++++++++
arch/arm64/boot/dts/nuvoton/ma35d1.dtsi | 60 +++++++++++++++++++
2 files changed, 86 insertions(+)
diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts b/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
index f6f20a17e501..1b8ea14d3446 100644
--- a/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
+++ b/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
@@ -37,6 +37,18 @@ clk_hxt: clock-hxt {
};
};
+&can1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can1>;
+};
+
+&can3 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can3>;
+};
+
&clk {
assigned-clocks = <&clk CAPLL>,
<&clk DDRPLL>,
@@ -56,6 +68,20 @@ &clk {
};
&pinctrl {
+ can-grp {
+ pinctrl_can1: can1-pins {
+ nuvoton,pins = <11 14 4>,
+ <11 15 4>;
+ bias-disable;
+ };
+
+ pinctrl_can3: can3-pins {
+ nuvoton,pins = <11 10 3>,
+ <11 11 3>;
+ bias-disable;
+ };
+ };
+
uart-grp {
pinctrl_uart0: uart0-pins {
nuvoton,pins = <4 14 1>,
diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
index e51b98f5bdce..584dd8d44701 100644
--- a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
+++ b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
@@ -244,6 +244,66 @@ gpion: gpio@340 {
};
};
+ can0: can@403c0000 {
+ compatible = "bosch,m_can";
+ reg = <0x0 0x403c0000 0x0 0x200>, <0x0 0x403c0200 0x0 0x2000>;
+ reg-names = "m_can", "message_ram";
+ interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "int0", "int1";
+ clocks = <&clk HCLK3>, <&clk CAN0_GATE>;
+ clock-names = "hclk", "cclk";
+ assigned-clocks = <&clk APLL>, <&clk CAN0_DIV>;
+ assigned-clock-rates = <200000000>, <50000000>;
+ bosch,mram-cfg = <0x0 4 4 32 32 32 8 8>;
+ status = "disabled";
+ };
+
+ can1: can@403d0000 {
+ compatible = "bosch,m_can";
+ reg = <0x0 0x403d0000 0x0 0x200>, <0x0 0x403d0200 0x0 0x2000>;
+ reg-names = "m_can", "message_ram";
+ interrupts = <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "int0", "int1";
+ clocks = <&clk HCLK3>, <&clk CAN1_GATE>;
+ clock-names = "hclk", "cclk";
+ assigned-clocks = <&clk APLL>, <&clk CAN1_DIV>;
+ assigned-clock-rates = <200000000>, <50000000>;
+ bosch,mram-cfg = <0x0 4 4 32 32 32 8 8>;
+ status = "disabled";
+ };
+
+ can2: can@403e0000 {
+ compatible = "bosch,m_can";
+ reg = <0x0 0x403e0000 0x0 0x200>, <0x0 0x403e0200 0x0 0x2000>;
+ reg-names = "m_can", "message_ram";
+ interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "int0", "int1";
+ clocks = <&clk HCLK3>, <&clk CAN2_GATE>;
+ clock-names = "hclk", "cclk";
+ assigned-clocks = <&clk APLL>, <&clk CAN2_DIV>;
+ assigned-clock-rates = <200000000>, <50000000>;
+ bosch,mram-cfg = <0x0 4 4 32 32 32 8 8>;
+ status = "disabled";
+ };
+
+ can3: can@403f0000 {
+ compatible = "bosch,m_can";
+ reg = <0x0 0x403f0000 0x0 0x200>, <0x0 0x403f0200 0x0 0x2000>;
+ reg-names = "m_can", "message_ram";
+ interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "int0", "int1";
+ clocks = <&clk HCLK3>, <&clk CAN3_GATE>;
+ clock-names = "hclk", "cclk";
+ assigned-clocks = <&clk APLL>, <&clk CAN3_DIV>;
+ assigned-clock-rates = <200000000>, <50000000>;
+ bosch,mram-cfg = <0x0 4 4 32 32 32 8 8>;
+ status = "disabled";
+ };
+
uart0: serial@40700000 {
compatible = "nuvoton,ma35d1-uart";
reg = <0x0 0x40700000 0x0 0x100>;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] ARM: OMAP2+: Add CFI type for omap4_finish_suspend
From: Mithil Bavishi @ 2026-06-04 5:43 UTC (permalink / raw)
To: nathan
Cc: aaro.koskinen, andreas, bavishimithil, kees, khilman,
linux-arm-kernel, linux-kernel, linux-omap, linux, lkp, llvm,
oe-kbuild-all, rogerq, samitolvanen, tony
In-Reply-To: <20260525165527.GA18457@ax162>
> are both pointing out that cfi_types.h needs to be included in
> arch/arm/mach-omap2/sleep44xx.S for SYM_TYPED_FUNC_START to always be
> expanded properly. I tested adding
>
> #include <linux/cfi_types.h>
>
> as the first include line and both issues were resolved.
My apologies, I was switching systems and seem to have lost this somewhere
in the process. Sent a v3 with the include, thanks a lot!
Best,
Mithil Bavishi
^ permalink raw reply
* [PATCH v3] ARM: OMAP2+: Add CFI type for omap4_finish_suspend
From: Mithil Bavishi @ 2026-06-04 5:40 UTC (permalink / raw)
To: Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Russell King
Cc: Sami Tolvanen, Kees Cook, Nathan Chancellor, linux-arm-kernel,
linux-omap, llvm, linux-kernel, Mithil Bavishi
With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower()
because omap_pm_ops.finish_suspend points directly to the assembly
routine omap4_finish_suspend, which lacks the expected KCFI type
metadata.
Annotate omap4_finish_suspend with SYM_TYPED_FUNC_START so the assembly
routine carries the KCFI type metadata.
Signed-off-by: Mithil Bavishi <bavishimithil@gmail.com>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Andreas Kemnade <andreas@kemnade.info>
---
arch/arm/mach-omap2/sleep44xx.S | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep44xx.S b/arch/arm/mach-omap2/sleep44xx.S
index f09c91978..8b515f300 100644
--- a/arch/arm/mach-omap2/sleep44xx.S
+++ b/arch/arm/mach-omap2/sleep44xx.S
@@ -6,6 +6,7 @@
* Santosh Shilimkar <santosh.shilimkar@ti.com>
*/
+#include <linux/cfi_types.h>
#include <linux/linkage.h>
#include <asm/assembler.h>
#include <asm/smp_scu.h>
@@ -58,7 +59,7 @@
* stack frame and it expects the caller to take care of it. Hence the entire
* stack frame is saved to avoid possible stack corruption.
*/
-ENTRY(omap4_finish_suspend)
+SYM_TYPED_FUNC_START(omap4_finish_suspend)
stmfd sp!, {r4-r12, lr}
cmp r0, #0x0
beq do_WFI @ No lowpower state, jump to WFI
@@ -223,7 +224,7 @@ skip_scu_gp_clear:
isb
dsb
ldmfd sp!, {r4-r12, pc}
-ENDPROC(omap4_finish_suspend)
+SYM_FUNC_END(omap4_finish_suspend)
/*
* ============================
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] arm: gen-mach-types: don't include absolute filename
From: Alexander Stein @ 2026-06-04 5:26 UTC (permalink / raw)
To: Russell King, Sascha Hauer
Cc: linux-arm-kernel, linux-kernel, Marco Felsch,
Uwe Kleine-König, Ryan Eatmon, kernel, Sascha Hauer
In-Reply-To: <20260603-arm-remove-path-from-mach-types-h-v1-1-cda9890ba788@pengutronix.de>
Hi Sascha,
thanks for bringing this up (again).
Am Mittwoch, 3. Juni 2026, 16:12:10 CEST schrieb Sascha Hauer:
> mach-types.h is part of the kapi and as such shipped in the
> linux-headers package. The embedded build path makes that package
> non-reproducible without going through an extra step of normalizing the
> path. YOCTO has similar problems in the kernel debug source package.
>
> Make the path relative to the kernel source tree which is enough to
> find the tool that has generated the file.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
> This topic comes up every once in a while, without any clear objection
> other than "Or just leave it as is. It's in a comment, it doesn't get
> into the executable, and thus is harmless.", from which I am not sure if
> it actually is an objection. Cced the authors of the previous patches
> that I am aware of:
>
> https://lore.kernel.org/all/20241114130021.2802803-1-m.felsch@pengutronix.de/
> https://lore.kernel.org/all/13360982.O9o76ZdvQC@steina-w/
> https://lore.kernel.org/all/20240213092835.754462-2-u.kleine-koenig@pengutronix.de/
> https://lore.kernel.org/all/20241002175049.15219-1-reatmon@ti.com/
This is much simpler as it hard-codes the file name. I don't have a preference
on that, so
Acked-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Thanks
Alexander
> ---
> arch/arm/tools/gen-mach-types | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/tools/gen-mach-types b/arch/arm/tools/gen-mach-types
> index cbe1c33bb8710..65ec262b31e65 100644
> --- a/arch/arm/tools/gen-mach-types
> +++ b/arch/arm/tools/gen-mach-types
> @@ -24,7 +24,7 @@ NF == 3 {
>
> END {
> printf("/*\n");
> - printf(" * This was automagically generated from %s!\n", FILENAME);
> + printf(" * This was automagically generated from arch/arm/tools/gen-mach-types!\n");
> printf(" * Do NOT edit\n");
> printf(" */\n\n");
> printf("#ifndef __ASM_ARM_MACH_TYPE_H\n");
>
> ---
> base-commit: ba3e43a9e601636f5edb54e259a74f96ca3b8fd8
> change-id: 20260603-arm-remove-path-from-mach-types-h-a6f528d60e00
>
> Best regards,
>
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox