All of lore.kernel.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download mbox.gz: |
* [PATCH v10 14/19] irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs
  2024-05-29 13:34  2% ` Jonathan Cameron
@ 2024-05-29 13:34  4%   ` Jonathan Cameron
  -1 siblings, 0 replies; 200+ results
From: Jonathan Cameron @ 2024-05-29 13:34 UTC (permalink / raw)
  To: Marc Zyngier, Will Deacon, Catalin Marinas, linux-acpi,
	linux-arch, linux-kernel, linux-arm-kernel, linux-pm
  Cc: Mark Rutland, Thomas Gleixner, Peter Zijlstra, loongarch, x86,
	Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
	Salil Mehta, Jean-Philippe Brucker, Hanjun Guo, Gavin Shan,
	Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm, justin.he,
	jianyong.wu

From: James Morse <james.morse@arm.com>

To support virtual CPU hotplug, ACPI has added an 'online capable' bit
to the MADT GICC entries. This indicates a disabled CPU entry may not
be possible to online via PSCI until firmware has set enabled bit in
_STA.

This means that a "usable" GIC redistributor is one that is marked as
either enabled, or online capable. The meaning of the
acpi_gicc_is_usable() would become less clear than just checking the
pair of flags at call sites. As such, drop that helper function.
The test in gic_acpi_match_gicc() remains as testing just the
enabled bit so the count of enabled distributors is correct.

What about the redistributor in the GICC entry? ACPI doesn't want to say.
Assume the worst: When a redistributor is described in the GICC entry,
but the entry is marked as disabled at boot, assume the redistributor
is inaccessible.

The GICv3 driver doesn't support late online of redistributors, so this
means the corresponding CPU can't be brought online either.
Rather than modifying cpu masks that may already have been used,
register a new cpuhp callback to fail this case. This must run earlier
than the main gic_starting_cpu() so that this case can be rejected
before the section of cpuhp that runs on the CPU that is coming up as
that is not allowed to fail. This solution keeps the handling of this
broken firmware corner case local to the GIC driver. As precise ordering
of this callback doesn't need to be controlled as long as it is
in that initial prepare phase, use CPUHP_BP_PREPARE_DYN.

Systems that want CPU hotplug in a VM can ensure their redistributors
are always-on, and describe them that way with a GICR entry in the MADT.

Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 arch/arm64/kernel/smp.c       |  3 ++-
 drivers/acpi/processor_core.c |  3 ++-
 drivers/irqchip/irq-gic-v3.c  | 46 ++++++++++++++++++++++++++++++++---
 include/linux/acpi.h          |  5 ----
 4 files changed, 46 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 31c8b3094dd7..6b0572daa9da 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -530,7 +530,8 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
 {
 	u64 hwid = processor->arm_mpidr;
 
-	if (!acpi_gicc_is_usable(processor)) {
+	if (!(processor->flags &
+	      (ACPI_MADT_ENABLED | ACPI_MADT_GICC_ONLINE_CAPABLE))) {
 		pr_debug("skipping disabled CPU entry with 0x%llx MPIDR\n", hwid);
 		return;
 	}
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index b203cfe28550..b04b684f3190 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -90,7 +90,8 @@ static int map_gicc_mpidr(struct acpi_subtable_header *entry,
 	struct acpi_madt_generic_interrupt *gicc =
 	    container_of(entry, struct acpi_madt_generic_interrupt, header);
 
-	if (!acpi_gicc_is_usable(gicc))
+	if (!(gicc->flags &
+	      (ACPI_MADT_ENABLED | ACPI_MADT_GICC_ONLINE_CAPABLE)))
 		return -ENODEV;
 
 	/* device_declaration means Device object in DSDT, in the
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 10af15f93d4d..cc81515c1413 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -44,6 +44,8 @@
 
 #define GIC_IRQ_TYPE_PARTITION	(GIC_IRQ_TYPE_LPI + 1)
 
+static struct cpumask broken_rdists __read_mostly;
+
 struct redist_region {
 	void __iomem		*redist_base;
 	phys_addr_t		phys_base;
@@ -1293,6 +1295,18 @@ static void gic_cpu_init(void)
 #define MPIDR_TO_SGI_RS(mpidr)	(MPIDR_RS(mpidr) << ICC_SGI1R_RS_SHIFT)
 #define MPIDR_TO_SGI_CLUSTER_ID(mpidr)	((mpidr) & ~0xFUL)
 
+/*
+ * gic_starting_cpu() is called after the last point where cpuhp is allowed
+ * to fail. So pre check for problems earlier.
+ */
+static int gic_check_rdist(unsigned int cpu)
+{
+	if (cpumask_test_cpu(cpu, &broken_rdists))
+		return -EINVAL;
+
+	return 0;
+}
+
 static int gic_starting_cpu(unsigned int cpu)
 {
 	gic_cpu_init();
@@ -1384,6 +1398,10 @@ static void __init gic_smp_init(void)
 	};
 	int base_sgi;
 
+	cpuhp_setup_state_nocalls(CPUHP_BP_PREPARE_DYN,
+				  "irqchip/arm/gicv3:checkrdist",
+				  gic_check_rdist, NULL);
+
 	cpuhp_setup_state_nocalls(CPUHP_AP_IRQ_GIC_STARTING,
 				  "irqchip/arm/gicv3:starting",
 				  gic_starting_cpu, NULL);
@@ -2365,8 +2383,24 @@ gic_acpi_parse_madt_gicc(union acpi_subtable_headers *header,
 	u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2;
 	void __iomem *redist_base;
 
-	if (!acpi_gicc_is_usable(gicc))
+	/* Neither enabled or online capable means it doesn't exist, skip it */
+	if (!(gicc->flags & (ACPI_MADT_ENABLED | ACPI_MADT_GICC_ONLINE_CAPABLE)))
+		return 0;
+
+	/*
+	 * Capable but disabled CPUs can be brought online later. What about
+	 * the redistributor? ACPI doesn't want to say!
+	 * Virtual hotplug systems can use the MADT's "always-on" GICR entries.
+	 * Otherwise, prevent such CPUs from being brought online.
+	 */
+	if (!(gicc->flags & ACPI_MADT_ENABLED)) {
+		int cpu = get_cpu_for_acpi_id(gicc->uid);
+
+		pr_warn("CPU %u's redistributor is inaccessible: this CPU can't be brought online\n", cpu);
+		if (cpu >= 0)
+			cpumask_set_cpu(cpu, &broken_rdists);
 		return 0;
+	}
 
 	redist_base = ioremap(gicc->gicr_base_address, size);
 	if (!redist_base)
@@ -2413,9 +2447,12 @@ static int __init gic_acpi_match_gicc(union acpi_subtable_headers *header,
 
 	/*
 	 * If GICC is enabled and has valid gicr base address, then it means
-	 * GICR base is presented via GICC
+	 * GICR base is presented via GICC. The redistributor is only known to
+	 * be accessible if the GICC is marked as enabled. If this bit is not
+	 * set, we'd need to add the redistributor at runtime, which isn't
+	 * supported.
 	 */
-	if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address)
+	if (gicc->flags & ACPI_MADT_ENABLED && gicc->gicr_base_address)
 		acpi_data.enabled_rdists++;
 
 	return 0;
@@ -2474,7 +2511,8 @@ static int __init gic_acpi_parse_virt_madt_gicc(union acpi_subtable_headers *hea
 	int maint_irq_mode;
 	static int first_madt = true;
 
-	if (!acpi_gicc_is_usable(gicc))
+	if (!(gicc->flags &
+	      (ACPI_MADT_ENABLED | ACPI_MADT_GICC_ONLINE_CAPABLE)))
 		return 0;
 
 	maint_irq_mode = (gicc->flags & ACPI_MADT_VGIC_IRQ_MODE) ?
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index fd45bfab66b8..9f8c9d29b035 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -237,11 +237,6 @@ acpi_table_parse_cedt(enum acpi_cedt_type id,
 int acpi_parse_mcfg (struct acpi_table_header *header);
 void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
 
-static inline bool acpi_gicc_is_usable(struct acpi_madt_generic_interrupt *gicc)
-{
-	return gicc->flags & ACPI_MADT_ENABLED;
-}
-
 #if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
 void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
 #else
-- 
2.39.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 4%]

* [PATCH v10 14/19] irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs
@ 2024-05-29 13:34  4%   ` Jonathan Cameron
  0 siblings, 0 replies; 200+ results
From: Jonathan Cameron @ 2024-05-29 13:34 UTC (permalink / raw)
  To: Marc Zyngier, Will Deacon, Catalin Marinas, linux-acpi,
	linux-arch, linux-kernel, linux-arm-kernel, linux-pm
  Cc: Mark Rutland, Thomas Gleixner, Peter Zijlstra, loongarch, x86,
	Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
	Salil Mehta, Jean-Philippe Brucker, Hanjun Guo, Gavin Shan,
	Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm, justin.he,
	jianyong.wu

From: James Morse <james.morse@arm.com>

To support virtual CPU hotplug, ACPI has added an 'online capable' bit
to the MADT GICC entries. This indicates a disabled CPU entry may not
be possible to online via PSCI until firmware has set enabled bit in
_STA.

This means that a "usable" GIC redistributor is one that is marked as
either enabled, or online capable. The meaning of the
acpi_gicc_is_usable() would become less clear than just checking the
pair of flags at call sites. As such, drop that helper function.
The test in gic_acpi_match_gicc() remains as testing just the
enabled bit so the count of enabled distributors is correct.

What about the redistributor in the GICC entry? ACPI doesn't want to say.
Assume the worst: When a redistributor is described in the GICC entry,
but the entry is marked as disabled at boot, assume the redistributor
is inaccessible.

The GICv3 driver doesn't support late online of redistributors, so this
means the corresponding CPU can't be brought online either.
Rather than modifying cpu masks that may already have been used,
register a new cpuhp callback to fail this case. This must run earlier
than the main gic_starting_cpu() so that this case can be rejected
before the section of cpuhp that runs on the CPU that is coming up as
that is not allowed to fail. This solution keeps the handling of this
broken firmware corner case local to the GIC driver. As precise ordering
of this callback doesn't need to be controlled as long as it is
in that initial prepare phase, use CPUHP_BP_PREPARE_DYN.

Systems that want CPU hotplug in a VM can ensure their redistributors
are always-on, and describe them that way with a GICR entry in the MADT.

Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 arch/arm64/kernel/smp.c       |  3 ++-
 drivers/acpi/processor_core.c |  3 ++-
 drivers/irqchip/irq-gic-v3.c  | 46 ++++++++++++++++++++++++++++++++---
 include/linux/acpi.h          |  5 ----
 4 files changed, 46 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 31c8b3094dd7..6b0572daa9da 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -530,7 +530,8 @@ acpi_map_gic_cpu_interface(struct acpi_madt_generic_interrupt *processor)
 {
 	u64 hwid = processor->arm_mpidr;
 
-	if (!acpi_gicc_is_usable(processor)) {
+	if (!(processor->flags &
+	      (ACPI_MADT_ENABLED | ACPI_MADT_GICC_ONLINE_CAPABLE))) {
 		pr_debug("skipping disabled CPU entry with 0x%llx MPIDR\n", hwid);
 		return;
 	}
diff --git a/drivers/acpi/processor_core.c b/drivers/acpi/processor_core.c
index b203cfe28550..b04b684f3190 100644
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -90,7 +90,8 @@ static int map_gicc_mpidr(struct acpi_subtable_header *entry,
 	struct acpi_madt_generic_interrupt *gicc =
 	    container_of(entry, struct acpi_madt_generic_interrupt, header);
 
-	if (!acpi_gicc_is_usable(gicc))
+	if (!(gicc->flags &
+	      (ACPI_MADT_ENABLED | ACPI_MADT_GICC_ONLINE_CAPABLE)))
 		return -ENODEV;
 
 	/* device_declaration means Device object in DSDT, in the
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 10af15f93d4d..cc81515c1413 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -44,6 +44,8 @@
 
 #define GIC_IRQ_TYPE_PARTITION	(GIC_IRQ_TYPE_LPI + 1)
 
+static struct cpumask broken_rdists __read_mostly;
+
 struct redist_region {
 	void __iomem		*redist_base;
 	phys_addr_t		phys_base;
@@ -1293,6 +1295,18 @@ static void gic_cpu_init(void)
 #define MPIDR_TO_SGI_RS(mpidr)	(MPIDR_RS(mpidr) << ICC_SGI1R_RS_SHIFT)
 #define MPIDR_TO_SGI_CLUSTER_ID(mpidr)	((mpidr) & ~0xFUL)
 
+/*
+ * gic_starting_cpu() is called after the last point where cpuhp is allowed
+ * to fail. So pre check for problems earlier.
+ */
+static int gic_check_rdist(unsigned int cpu)
+{
+	if (cpumask_test_cpu(cpu, &broken_rdists))
+		return -EINVAL;
+
+	return 0;
+}
+
 static int gic_starting_cpu(unsigned int cpu)
 {
 	gic_cpu_init();
@@ -1384,6 +1398,10 @@ static void __init gic_smp_init(void)
 	};
 	int base_sgi;
 
+	cpuhp_setup_state_nocalls(CPUHP_BP_PREPARE_DYN,
+				  "irqchip/arm/gicv3:checkrdist",
+				  gic_check_rdist, NULL);
+
 	cpuhp_setup_state_nocalls(CPUHP_AP_IRQ_GIC_STARTING,
 				  "irqchip/arm/gicv3:starting",
 				  gic_starting_cpu, NULL);
@@ -2365,8 +2383,24 @@ gic_acpi_parse_madt_gicc(union acpi_subtable_headers *header,
 	u32 size = reg == GIC_PIDR2_ARCH_GICv4 ? SZ_64K * 4 : SZ_64K * 2;
 	void __iomem *redist_base;
 
-	if (!acpi_gicc_is_usable(gicc))
+	/* Neither enabled or online capable means it doesn't exist, skip it */
+	if (!(gicc->flags & (ACPI_MADT_ENABLED | ACPI_MADT_GICC_ONLINE_CAPABLE)))
+		return 0;
+
+	/*
+	 * Capable but disabled CPUs can be brought online later. What about
+	 * the redistributor? ACPI doesn't want to say!
+	 * Virtual hotplug systems can use the MADT's "always-on" GICR entries.
+	 * Otherwise, prevent such CPUs from being brought online.
+	 */
+	if (!(gicc->flags & ACPI_MADT_ENABLED)) {
+		int cpu = get_cpu_for_acpi_id(gicc->uid);
+
+		pr_warn("CPU %u's redistributor is inaccessible: this CPU can't be brought online\n", cpu);
+		if (cpu >= 0)
+			cpumask_set_cpu(cpu, &broken_rdists);
 		return 0;
+	}
 
 	redist_base = ioremap(gicc->gicr_base_address, size);
 	if (!redist_base)
@@ -2413,9 +2447,12 @@ static int __init gic_acpi_match_gicc(union acpi_subtable_headers *header,
 
 	/*
 	 * If GICC is enabled and has valid gicr base address, then it means
-	 * GICR base is presented via GICC
+	 * GICR base is presented via GICC. The redistributor is only known to
+	 * be accessible if the GICC is marked as enabled. If this bit is not
+	 * set, we'd need to add the redistributor at runtime, which isn't
+	 * supported.
 	 */
-	if (acpi_gicc_is_usable(gicc) && gicc->gicr_base_address)
+	if (gicc->flags & ACPI_MADT_ENABLED && gicc->gicr_base_address)
 		acpi_data.enabled_rdists++;
 
 	return 0;
@@ -2474,7 +2511,8 @@ static int __init gic_acpi_parse_virt_madt_gicc(union acpi_subtable_headers *hea
 	int maint_irq_mode;
 	static int first_madt = true;
 
-	if (!acpi_gicc_is_usable(gicc))
+	if (!(gicc->flags &
+	      (ACPI_MADT_ENABLED | ACPI_MADT_GICC_ONLINE_CAPABLE)))
 		return 0;
 
 	maint_irq_mode = (gicc->flags & ACPI_MADT_VGIC_IRQ_MODE) ?
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index fd45bfab66b8..9f8c9d29b035 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -237,11 +237,6 @@ acpi_table_parse_cedt(enum acpi_cedt_type id,
 int acpi_parse_mcfg (struct acpi_table_header *header);
 void acpi_table_print_madt_entry (struct acpi_subtable_header *madt);
 
-static inline bool acpi_gicc_is_usable(struct acpi_madt_generic_interrupt *gicc)
-{
-	return gicc->flags & ACPI_MADT_ENABLED;
-}
-
 #if defined(CONFIG_X86) || defined(CONFIG_LOONGARCH)
 void acpi_numa_processor_affinity_init (struct acpi_srat_cpu_affinity *pa);
 #else
-- 
2.39.2


^ permalink raw reply related	[relevance 4%]

* [PATCH v10 12/19] arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
  2024-05-29 13:34  2% ` Jonathan Cameron
@ 2024-05-29 13:34  1%   ` Jonathan Cameron
  -1 siblings, 0 replies; 200+ results
From: Jonathan Cameron @ 2024-05-29 13:34 UTC (permalink / raw)
  To: Marc Zyngier, Will Deacon, Catalin Marinas, linux-acpi,
	linux-arch, linux-kernel, linux-arm-kernel, linux-pm
  Cc: Mark Rutland, Thomas Gleixner, Peter Zijlstra, loongarch, x86,
	Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
	Salil Mehta, Jean-Philippe Brucker, Hanjun Guo, Gavin Shan,
	Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm, justin.he,
	jianyong.wu

In a review discussion of the changes to support vCPU hotplug where
a check was added on the GICC being enabled if was online, it was
noted that there is need to map back to the cpu and use that to index
into a cpumask. As such, a valid ID is needed.

If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible
for the entry in cpu_madt_gicc[cpu] == NULL.  This function would
then cause a NULL pointer dereference.   Whilst a path to trigger
this has not been established, harden this caller against the
possibility.

Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

---
V10: Fix description above (duplicated word).
     Picked up Gavin's tag.
---
 arch/arm64/include/asm/acpi.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index bc9a6656fc0c..a407f9cd549e 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -124,7 +124,8 @@ static inline int get_cpu_for_acpi_id(u32 uid)
 	int cpu;
 
 	for (cpu = 0; cpu < nr_cpu_ids; cpu++)
-		if (uid == get_acpi_id_for_cpu(cpu))
+		if (acpi_cpu_get_madt_gicc(cpu) &&
+		    uid == get_acpi_id_for_cpu(cpu))
 			return cpu;
 
 	return -EINVAL;
-- 
2.39.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 1%]

* [PATCH v10 12/19] arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
@ 2024-05-29 13:34  1%   ` Jonathan Cameron
  0 siblings, 0 replies; 200+ results
From: Jonathan Cameron @ 2024-05-29 13:34 UTC (permalink / raw)
  To: Marc Zyngier, Will Deacon, Catalin Marinas, linux-acpi,
	linux-arch, linux-kernel, linux-arm-kernel, linux-pm
  Cc: Mark Rutland, Thomas Gleixner, Peter Zijlstra, loongarch, x86,
	Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
	Salil Mehta, Jean-Philippe Brucker, Hanjun Guo, Gavin Shan,
	Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm, justin.he,
	jianyong.wu

In a review discussion of the changes to support vCPU hotplug where
a check was added on the GICC being enabled if was online, it was
noted that there is need to map back to the cpu and use that to index
into a cpumask. As such, a valid ID is needed.

If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possible
for the entry in cpu_madt_gicc[cpu] == NULL.  This function would
then cause a NULL pointer dereference.   Whilst a path to trigger
this has not been established, harden this caller against the
possibility.

Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

---
V10: Fix description above (duplicated word).
     Picked up Gavin's tag.
---
 arch/arm64/include/asm/acpi.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index bc9a6656fc0c..a407f9cd549e 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -124,7 +124,8 @@ static inline int get_cpu_for_acpi_id(u32 uid)
 	int cpu;
 
 	for (cpu = 0; cpu < nr_cpu_ids; cpu++)
-		if (uid == get_acpi_id_for_cpu(cpu))
+		if (acpi_cpu_get_madt_gicc(cpu) &&
+		    uid == get_acpi_id_for_cpu(cpu))
 			return cpu;
 
 	return -EINVAL;
-- 
2.39.2


^ permalink raw reply related	[relevance 1%]

* Re: [PATCH v4] mc146818rtc: add a way to generate RTC interrupts via QMP
  2024-05-29 12:43  0%     ` Daniil Tatianin
@ 2024-05-29 13:39  0%       ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 200+ results
From: Philippe Mathieu-Daudé @ 2024-05-29 13:39 UTC (permalink / raw)
  To: Daniil Tatianin, Markus Armbruster
  Cc: Michael S. Tsirkin, Paolo Bonzini, Eric Blake, qemu-devel

On 29/5/24 14:43, Daniil Tatianin wrote:
> On 5/29/24 3:36 PM, Philippe Mathieu-Daudé wrote:
> 
>> On 29/5/24 14:03, Markus Armbruster wrote:
>>> Daniil Tatianin <d-tatianin@yandex-team.ru> writes:
>>>
>>>> This can be used to force-synchronize the time in guest after a long
>>>> stop-cont pause, which can be useful for serverless-type workload.
>>>>
>>>> Also add a comment to highlight the fact that this (and one other QMP
>>>> command) only works for the MC146818 RTC controller.
>>>>
>>>> Acked-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>>>> Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
>>>> ---
>>>>
>>>> Changes since v0:
>>>> - Rename to rtc-inject-irq to match other similar API
>>>> - Add a comment to highlight that this only works for the I386 RTC
>>>>
>>>> Changes since v1:
>>>> - Added a description below the QMP command to explain how it can be
>>>>    used and what it does.
>>>>
>>>> Changes since v2:
>>>> - Add a 'broadcast' suffix.
>>>> - Change the comments to explain the flags we're setting.
>>>> - Change the command description to fix styling & explain that it's 
>>>> a broadcast command.
>>>>
>>>> Changes since v3:
>>>> - Fix checkpatch complaints about usage of C99 comments
>>>>
>>>> ---
>>>>   hw/rtc/mc146818rtc.c         | 20 ++++++++++++++++++++
>>>>   include/hw/rtc/mc146818rtc.h |  1 +
>>>>   qapi/misc-target.json        | 19 +++++++++++++++++++
>>>>   3 files changed, 40 insertions(+)


>>>> diff --git a/qapi/misc-target.json b/qapi/misc-target.json
>>>> index 4e0a6492a9..7d388a3753 100644
>>>> --- a/qapi/misc-target.json
>>>> +++ b/qapi/misc-target.json
>>>> @@ -19,6 +19,25 @@
>>>>   { 'command': 'rtc-reset-reinjection',
>>>>     'if': 'TARGET_I386' }
>>>>   +##
>>>> +# @rtc-inject-irq-broadcast:
>>>> +#
>>>> +# Inject an RTC interrupt for all existing RTCs on the system.
>>>> +# The interrupt forces the guest to synchronize the time with RTC.
>>>> +# This is useful after a long stop-cont pause, which is common for
>>>> +# serverless-type workload.
>>
>> In previous version you said:
>>
>>   > This isn't really related to migration though. Serverless is based
>>   > on constantly stopping and resuming the VM on e.g. every HTTP
>>   > request to an endpoint.
>>
>> Which made some sense. Maybe mention HTTP? And point to that use case
>> (possibly with QMP commands) in the commit description?
> 
> Hmm, maybe it would be helpful for people who don't know what serverless 
> means.
> 
> How about:
>      This is useful after a long stop-const pause, which is common for 
> serverless-type workloads,
>      e.g. stopping/resuming the VM on every HTTP request to an endpoint, 
> which might involve
>      a long pause in between the requests, causing time drift in the guest.

Please help me understand your workflow. Your management layer call
@stop and @cont QMP commands, is that right?

@cont will emit a @RESUME event.

If we could listen to QAPI events from C code, we could have the
mc146818rtc device automatically sync on VM resume, and no need for
this async command.

I'll let our QAPI expert enlighten me on this :)


^ permalink raw reply	[relevance 0%]

* [PATCH v10 10/19] ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug
  2024-05-29 13:34  2% ` Jonathan Cameron
@ 2024-05-29 13:34  1%   ` Jonathan Cameron
  -1 siblings, 0 replies; 200+ results
From: Jonathan Cameron @ 2024-05-29 13:34 UTC (permalink / raw)
  To: Marc Zyngier, Will Deacon, Catalin Marinas, linux-acpi,
	linux-arch, linux-kernel, linux-arm-kernel, linux-pm
  Cc: Mark Rutland, Thomas Gleixner, Peter Zijlstra, loongarch, x86,
	Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
	Salil Mehta, Jean-Philippe Brucker, Hanjun Guo, Gavin Shan,
	Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm, justin.he,
	jianyong.wu

From: James Morse <james.morse@arm.com>

struct acpi_scan_handler has a detach callback that is used to remove
a driver when a bus is changed. When interacting with an eject-request,
the detach callback is called before _EJ0.

This means the ACPI processor driver can't use _STA to determine if a
CPU has been made not-present, or some of the other _STA bits have been
changed. acpi_processor_remove() needs to know the value of _STA after
_EJ0 has been called.

Add a post_eject callback to struct acpi_scan_handler. This is called
after acpi_scan_hot_remove() has successfully called _EJ0. Because
acpi_scan_check_and_detach() also clears the handler pointer,
it needs to be told if the caller will go on to call
acpi_bus_post_eject(), so that acpi_device_clear_enumerated()
and clearing the handler pointer can be deferred.
An extra flag is added to flags field introduced in the previous
patch to achieve this.

Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu@arm.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/acpi/acpi_processor.c |  4 ++--
 drivers/acpi/scan.c           | 30 +++++++++++++++++++++++++++---
 include/acpi/acpi_bus.h       |  1 +
 3 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index f0b7a789f0a1..64e10bad8072 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -475,7 +475,7 @@ static int acpi_processor_add(struct acpi_device *device,
 
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
 /* Removal */
-static void acpi_processor_remove(struct acpi_device *device)
+static void acpi_processor_post_eject(struct acpi_device *device)
 {
 	struct acpi_processor *pr;
 
@@ -643,7 +643,7 @@ static struct acpi_scan_handler processor_handler = {
 	.ids = processor_device_ids,
 	.attach = acpi_processor_add,
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
-	.detach = acpi_processor_remove,
+	.post_eject = acpi_processor_post_eject,
 #endif
 	.hotplug = {
 		.enabled = true,
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 4d649ce5876f..0aa20623525a 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -244,6 +244,7 @@ static int acpi_scan_try_to_offline(struct acpi_device *device)
 }
 
 #define ACPI_SCAN_CHECK_FLAG_STATUS	BIT(0)
+#define ACPI_SCAN_CHECK_FLAG_EJECT	BIT(1)
 
 static int acpi_scan_check_and_detach(struct acpi_device *adev, void *p)
 {
@@ -272,8 +273,6 @@ static int acpi_scan_check_and_detach(struct acpi_device *adev, void *p)
 	if (handler) {
 		if (handler->detach)
 			handler->detach(adev);
-
-		adev->handler = NULL;
 	} else {
 		device_release_driver(&adev->dev);
 	}
@@ -283,6 +282,28 @@ static int acpi_scan_check_and_detach(struct acpi_device *adev, void *p)
 	 */
 	acpi_device_set_power(adev, ACPI_STATE_D3_COLD);
 	adev->flags.initialized = false;
+
+	/* For eject this is deferred to acpi_bus_post_eject() */
+	if (!(flags & ACPI_SCAN_CHECK_FLAG_EJECT)) {
+		adev->handler = NULL;
+		acpi_device_clear_enumerated(adev);
+	}
+	return 0;
+}
+
+static int acpi_bus_post_eject(struct acpi_device *adev, void *not_used)
+{
+	struct acpi_scan_handler *handler = adev->handler;
+
+	acpi_dev_for_each_child_reverse(adev, acpi_bus_post_eject, NULL);
+
+	if (handler) {
+		if (handler->post_eject)
+			handler->post_eject(adev);
+
+		adev->handler = NULL;
+	}
+
 	acpi_device_clear_enumerated(adev);
 
 	return 0;
@@ -300,6 +321,7 @@ static int acpi_scan_hot_remove(struct acpi_device *device)
 	acpi_handle handle = device->handle;
 	unsigned long long sta;
 	acpi_status status;
+	uintptr_t flags = ACPI_SCAN_CHECK_FLAG_EJECT;
 
 	if (device->handler && device->handler->hotplug.demand_offline) {
 		if (!acpi_scan_is_offline(device, true))
@@ -312,7 +334,7 @@ static int acpi_scan_hot_remove(struct acpi_device *device)
 
 	acpi_handle_debug(handle, "Ejecting\n");
 
-	acpi_bus_trim(device);
+	acpi_scan_check_and_detach(device, (void *)flags);
 
 	acpi_evaluate_lck(handle, 0);
 	/*
@@ -335,6 +357,8 @@ static int acpi_scan_hot_remove(struct acpi_device *device)
 	} else if (sta & ACPI_STA_DEVICE_ENABLED) {
 		acpi_handle_warn(handle,
 			"Eject incomplete - status 0x%llx\n", sta);
+	} else {
+		acpi_bus_post_eject(device, NULL);
 	}
 
 	return 0;
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 1a4dfd7a1c4a..05ca49478537 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -134,6 +134,7 @@ struct acpi_scan_handler {
 	bool (*match)(const char *idstr, const struct acpi_device_id **matchid);
 	int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
 	void (*detach)(struct acpi_device *dev);
+	void (*post_eject)(struct acpi_device *dev);
 	void (*bind)(struct device *phys_dev);
 	void (*unbind)(struct device *phys_dev);
 	struct acpi_hotplug_profile hotplug;
-- 
2.39.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 1%]

* [PATCH v10 10/19] ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug
@ 2024-05-29 13:34  1%   ` Jonathan Cameron
  0 siblings, 0 replies; 200+ results
From: Jonathan Cameron @ 2024-05-29 13:34 UTC (permalink / raw)
  To: Marc Zyngier, Will Deacon, Catalin Marinas, linux-acpi,
	linux-arch, linux-kernel, linux-arm-kernel, linux-pm
  Cc: Mark Rutland, Thomas Gleixner, Peter Zijlstra, loongarch, x86,
	Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
	Salil Mehta, Jean-Philippe Brucker, Hanjun Guo, Gavin Shan,
	Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm, justin.he,
	jianyong.wu

From: James Morse <james.morse@arm.com>

struct acpi_scan_handler has a detach callback that is used to remove
a driver when a bus is changed. When interacting with an eject-request,
the detach callback is called before _EJ0.

This means the ACPI processor driver can't use _STA to determine if a
CPU has been made not-present, or some of the other _STA bits have been
changed. acpi_processor_remove() needs to know the value of _STA after
_EJ0 has been called.

Add a post_eject callback to struct acpi_scan_handler. This is called
after acpi_scan_hot_remove() has successfully called _EJ0. Because
acpi_scan_check_and_detach() also clears the handler pointer,
it needs to be told if the caller will go on to call
acpi_bus_post_eject(), so that acpi_device_clear_enumerated()
and clearing the handler pointer can be deferred.
An extra flag is added to flags field introduced in the previous
patch to achieve this.

Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Tested-by: Vishnu Pajjuri <vishnu@os.amperecomputing.com>
Tested-by: Jianyong Wu <jianyong.wu@arm.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/acpi/acpi_processor.c |  4 ++--
 drivers/acpi/scan.c           | 30 +++++++++++++++++++++++++++---
 include/acpi/acpi_bus.h       |  1 +
 3 files changed, 30 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index f0b7a789f0a1..64e10bad8072 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -475,7 +475,7 @@ static int acpi_processor_add(struct acpi_device *device,
 
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
 /* Removal */
-static void acpi_processor_remove(struct acpi_device *device)
+static void acpi_processor_post_eject(struct acpi_device *device)
 {
 	struct acpi_processor *pr;
 
@@ -643,7 +643,7 @@ static struct acpi_scan_handler processor_handler = {
 	.ids = processor_device_ids,
 	.attach = acpi_processor_add,
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
-	.detach = acpi_processor_remove,
+	.post_eject = acpi_processor_post_eject,
 #endif
 	.hotplug = {
 		.enabled = true,
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 4d649ce5876f..0aa20623525a 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -244,6 +244,7 @@ static int acpi_scan_try_to_offline(struct acpi_device *device)
 }
 
 #define ACPI_SCAN_CHECK_FLAG_STATUS	BIT(0)
+#define ACPI_SCAN_CHECK_FLAG_EJECT	BIT(1)
 
 static int acpi_scan_check_and_detach(struct acpi_device *adev, void *p)
 {
@@ -272,8 +273,6 @@ static int acpi_scan_check_and_detach(struct acpi_device *adev, void *p)
 	if (handler) {
 		if (handler->detach)
 			handler->detach(adev);
-
-		adev->handler = NULL;
 	} else {
 		device_release_driver(&adev->dev);
 	}
@@ -283,6 +282,28 @@ static int acpi_scan_check_and_detach(struct acpi_device *adev, void *p)
 	 */
 	acpi_device_set_power(adev, ACPI_STATE_D3_COLD);
 	adev->flags.initialized = false;
+
+	/* For eject this is deferred to acpi_bus_post_eject() */
+	if (!(flags & ACPI_SCAN_CHECK_FLAG_EJECT)) {
+		adev->handler = NULL;
+		acpi_device_clear_enumerated(adev);
+	}
+	return 0;
+}
+
+static int acpi_bus_post_eject(struct acpi_device *adev, void *not_used)
+{
+	struct acpi_scan_handler *handler = adev->handler;
+
+	acpi_dev_for_each_child_reverse(adev, acpi_bus_post_eject, NULL);
+
+	if (handler) {
+		if (handler->post_eject)
+			handler->post_eject(adev);
+
+		adev->handler = NULL;
+	}
+
 	acpi_device_clear_enumerated(adev);
 
 	return 0;
@@ -300,6 +321,7 @@ static int acpi_scan_hot_remove(struct acpi_device *device)
 	acpi_handle handle = device->handle;
 	unsigned long long sta;
 	acpi_status status;
+	uintptr_t flags = ACPI_SCAN_CHECK_FLAG_EJECT;
 
 	if (device->handler && device->handler->hotplug.demand_offline) {
 		if (!acpi_scan_is_offline(device, true))
@@ -312,7 +334,7 @@ static int acpi_scan_hot_remove(struct acpi_device *device)
 
 	acpi_handle_debug(handle, "Ejecting\n");
 
-	acpi_bus_trim(device);
+	acpi_scan_check_and_detach(device, (void *)flags);
 
 	acpi_evaluate_lck(handle, 0);
 	/*
@@ -335,6 +357,8 @@ static int acpi_scan_hot_remove(struct acpi_device *device)
 	} else if (sta & ACPI_STA_DEVICE_ENABLED) {
 		acpi_handle_warn(handle,
 			"Eject incomplete - status 0x%llx\n", sta);
+	} else {
+		acpi_bus_post_eject(device, NULL);
 	}
 
 	return 0;
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 1a4dfd7a1c4a..05ca49478537 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -134,6 +134,7 @@ struct acpi_scan_handler {
 	bool (*match)(const char *idstr, const struct acpi_device_id **matchid);
 	int (*attach)(struct acpi_device *dev, const struct acpi_device_id *id);
 	void (*detach)(struct acpi_device *dev);
+	void (*post_eject)(struct acpi_device *dev);
 	void (*bind)(struct device *phys_dev);
 	void (*unbind)(struct device *phys_dev);
 	struct acpi_hotplug_profile hotplug;
-- 
2.39.2


^ permalink raw reply related	[relevance 1%]

* Re: [PATCH v2 2/4] mfd: adp5585: Add Analog Devices ADP5585 core support
  @ 2024-05-29 13:38  1%           ` Andy Shevchenko
  0 siblings, 0 replies; 200+ results
From: Andy Shevchenko @ 2024-05-29 13:38 UTC (permalink / raw)
  To: Laurent Pinchart
  Cc: linux-kernel, devicetree, linux-gpio, linux-pwm,
	Bartosz Golaszewski, Conor Dooley, Krzysztof Kozlowski,
	Lee Jones, Linus Walleij, Rob Herring, Uwe Kleine-König,
	Haibo Chen

On Wed, May 29, 2024 at 12:35 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Wed, May 29, 2024 at 08:44:26AM +0300, Andy Shevchenko wrote:
> > On Tue, May 28, 2024 at 11:13 PM Laurent Pinchart wrote:
> > > On Tue, May 28, 2024 at 10:27:34PM +0300, Andy Shevchenko wrote:
> > > > Tue, May 28, 2024 at 10:03:12PM +0300, Laurent Pinchart kirjoitti:

...

> > > > > +   depends on I2C && OF
> > > >
> > > > Why OF?
> > >
> > > Because the driver works on OF systems only.
> > >
> > > > No COMPILE_TEST?
> > >
> > > The driver won't compile without CONFIG_I2C, so I can use
> > >
> > >         depends on I2C
> > >         depends on OF || COMPILE_TEST
> > >
> > > Do you think that's better ?
> >
> > I think that dropping OF completely is the best.
> > OF || COMPILE_TEST would work as well, but I still don't know why we need this.
>
> For the same reason that many drivers depend on specific CONFIG_$ARCH.

It's different. You may not do in many cases the $ARCH ||
COMPILE_TEST, while OF || COMPILE_TEST should just work in 100% cases.

> They can't run on other platforms, the dependency hides the symbol for
> users who can't use the driver. This driver works on OF platforms only.

What you are talking about is functional dependency, what I'm talking
about is the compilation one.
So, it's a pity that Kbuild doesn't distinguish these two basic
concepts in dependencies and
FOO || COMPILE_TEST is basically an artificial hack to tell "hey, FOO
is _functional_ dependency, I do not care if I can compile without
it".

...

> > > > > +#define            ADP5585_MAN_ID(v)               (((v) & 0xf0) >> 4)
> > > >
> > > > GENMASK()
> > >
> > > This is not a mask. Or do you mean
> > >
> > >         (((v) & GENMASK(7, 4)) >> 4)
> > >
> > > ?
> >
> > Yes.
> >
> > > I think that's overkill.
> >
> > Why? You have a mask, use it for less error prone code.
>
> I'll change this to

...

> -       if (ADP5585_MAN_ID(id) != ADP5585_MAN_ID_VALUE)
> +       if (id & ADP5585_MAN_ID_MASK != ADP5585_MAN_ID_VALUE)

(Don't forget inner parentheses)

...

> > > > > +#define            ADP5585_Rx_PULL_CFG_MASK        (3)
> > > >
> > > > GENMASK()
> > >
> > > Not here, as this value is meant to be passed to ADP5585_Rx_PULL_CFG().
> >
> > Why is it marked as a mask? Rename it to _ALL or alike.
>
> It's a mask, but used as
>
>         ADP5585_Rx_PULL_CFG(ADP5585_Rx_PULL_CFG_MASK)
>
> We're reaching a level of bike-shedding that even I find impressive :-)
> As with a few other of your review comments that I think are related to
> personal taste more than anything else, I'll defer to the subsystem
> maintainer and follow their preference on this one.

I would name it _ALL and use (BIT(2) - 1) notation to show that you
want all of them to be set. But okay, let's leave this to the
maintainer.

-- 
With Best Regards,
Andy Shevchenko

^ permalink raw reply	[relevance 1%]

* Re: [PATCH v3 1/6] dt-bindings: adc: ad7173: add support for ad411x
  @ 2024-05-29 13:38  1%         ` Ceclan, Dumitru
  0 siblings, 0 replies; 200+ results
From: Ceclan, Dumitru @ 2024-05-29 13:38 UTC (permalink / raw)
  To: Conor Dooley
  Cc: dumitru.ceclan, Lars-Peter Clausen, Michael Hennerich,
	Jonathan Cameron, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	David Lechner, linux-iio, devicetree, linux-kernel

On 28/05/2024 20:52, Conor Dooley wrote:
> On Tue, May 28, 2024 at 03:16:07PM +0300, Ceclan, Dumitru wrote:
>> On 27/05/2024 20:48, Conor Dooley wrote:
>>> On Mon, May 27, 2024 at 08:02:34PM +0300, Dumitru Ceclan via B4 Relay wrote:
>>>> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
>>>>
>>>> Add support for: AD4111, AD4112, AD4114, AD4115, AD4116.
>>>>
>>>> AD411x family ADCs support a VCOM pin, dedicated for single-ended usage.
>>>> AD4111/AD4112 support current channels, usage is implemented by
>>>>  specifying channel reg values bigger than 15.
>>>>
>>>> Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
>>>> ---
>>>>  .../devicetree/bindings/iio/adc/adi,ad7173.yaml    | 122 ++++++++++++++++++++-
>>>>  1 file changed, 120 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml
>>>> index ea6cfcd0aff4..5b1af382dad3 100644
>>>> --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml
>>>> +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7173.yaml
>>>> @@ -19,7 +19,18 @@ description: |
>>>>    primarily for measurement of signals close to DC but also delivers
>>>>    outstanding performance with input bandwidths out to ~10kHz.
>>>>  
>>>> +  Analog Devices AD411x ADC's:
>>>> +  The AD411X family encompasses a series of low power, low noise, 24-bit,
>>>> +  sigma-delta analog-to-digital converters that offer a versatile range of
>>>> +  specifications. They integrate an analog front end suitable for processing
>>>> +  fully differential/single-ended and bipolar voltage inputs.
>>>> +
>>>>    Datasheets for supported chips:
>>>> +    https://www.analog.com/media/en/technical-documentation/data-sheets/AD4111.pdf
>>>> +    https://www.analog.com/media/en/technical-documentation/data-sheets/AD4112.pdf
>>>> +    https://www.analog.com/media/en/technical-documentation/data-sheets/AD4114.pdf
>>>> +    https://www.analog.com/media/en/technical-documentation/data-sheets/AD4115.pdf
>>>> +    https://www.analog.com/media/en/technical-documentation/data-sheets/AD4116.pdf
>>>>      https://www.analog.com/media/en/technical-documentation/data-sheets/AD7172-2.pdf
>>>>      https://www.analog.com/media/en/technical-documentation/data-sheets/AD7172-4.pdf
>>>>      https://www.analog.com/media/en/technical-documentation/data-sheets/AD7173-8.pdf
>>>> @@ -31,6 +42,11 @@ description: |
>>>>  properties:
>>>>    compatible:
>>>>      enum:
>>>> +      - adi,ad4111
>>>> +      - adi,ad4112
>>>> +      - adi,ad4114
>>>> +      - adi,ad4115
>>>> +      - adi,ad4116
>>>>        - adi,ad7172-2
>>>>        - adi,ad7172-4
>>>>        - adi,ad7173-8
>>>> @@ -129,10 +145,36 @@ patternProperties:
>>>>          maximum: 15
>>>>  
>>>>        diff-channels:
>>>> +        description: |
>>>> +          For using current channels specify select the current inputs
>>>> +           and enable the adi,current-channel property.
>>>> +
>>>> +          Family AD411x supports a dedicated VINCOM voltage input.
>>>> +          To select it set the second channel to 16.
>>>> +            (VIN2, VINCOM) -> diff-channels = <2 16>
>>>> +
>>>> +          There are special values that can be selected besides the voltage
>>>> +          analog inputs:
>>>> +            21: REF+
>>>> +            22: REF−
>>>> +          Supported only by AD7172-2, AD7172-4, AD7175-2, AD7175-8, AD7177-2:
>>>> +            19: ((AVDD1 − AVSS)/5)+
>>>> +            20: ((AVDD1 − AVSS)/5)−
>>>> +
>>>>          items:
>>>>            minimum: 0
>>>>            maximum: 31
>>>>  
>>>> +      single-channel:
>>>> +        description: |
>>>> +          Models AD4111 and AD4112 support single-ended current channels.
>>>> +          To select the desired current input, specify the desired input pair:
>>>> +            (IIN2+, IIN2−) -> single-channel = <2>
>>>> +
>>>> +        items:
>>>> +          minimum: 1
>>>> +          maximum: 16
>>>> +
>>>>        adi,reference-select:
>>>>          description: |
>>>>            Select the reference source to use when converting on
>>>> @@ -154,9 +196,26 @@ patternProperties:
>>>>            - avdd
>>>>          default: refout-avss
>>>>  
>>>> +      adi,current-channel:
>>>> +        description: |
>>>> +          Signal that the selected inputs are current channels.
>>>> +          Only available on AD4111 and AD4112.
>>>> +        type: boolean
>>>> +
>>>> +      adi,channel-type:
>>>> +        description:
>>>> +          Used to differentiate between different channel types as the device
>>>> +           register configurations are the same for all usage types.
>>>> +          Both pseudo-differential and single-ended channels will use the
>>>> +           single-ended specifier.
>>>> +        $ref: /schemas/types.yaml#/definitions/string
>>>> +        enum:
>>>> +          - single-ended
>>>> +          - differential
>>>> +        default: differential
>>>
>>> I dunno if my brain just ain't workin' right today, or if this is not
>>> sufficiently explained, but why is this property needed? You've got
>>> diff-channels and single-channels already, why can you not infer the
>>> information you need from them? What should software do with this
>>> information?
>>> Additionally, "pseudo-differential" is not explained in this binding.
>>
>> In previous thread we arrived to the conclusion single-ended and
>> pseudo-differential channels should be marked with the flag
>> "differential=false" in the IIO channel struct. This cannot
>> really be inferred as any input pair could be used in that
>> manner and the only difference would be in external wiring.
>>
>> Single-channels cannot be used to define such a channel as
>> two voltage inputs need to be selected. Also, we are already
>> using single-channel to define the current channels.
> 
> If I understand correctly, the property could be simplified to a flag
> then, since it's only the pseudo differential mode that you cannot be
> sure of?
> You know when you're single-ended based on single-channel, so the
> additional info you need is only in the pseudo-differential case.
> 
Yes, it could just be a boolean flag. The only thing I have against
that is the awkwardness of having both diff-channels and
differential=false within a channel definition.

No, there is no uncertainty regarding pseudo-differential, it's
basically single-ended.

We cannot use single-channel for voltage channels, two voltage
inputs need to be specified. And again, single-channel will be
used here for the current channels. 

>> As for explaining the pseudo-differential, should it be explained?
>> A voltage channel within the context of these families is actually
>> differential(as there are always two inputs selected).
>> The single-ended and pseudo-diff use case is actually wiring up a
>> constant voltage to the selected negative input.
>>
>> I did not consider that this should be described, as there is no
>> need for an attribute to describe it.
> 
> I dunno, adding an explanation of it in the text for the channel type
> seems trivial to do. "Both pseudo-differential mode (where the
> one of differential inputs is connected to a constant voltage) and
> single-ended channels will..."
>
>>> Also, what does "the device register configurations are the same for
>>> all uses types" mean? The description here implies that you'd be reading
>>> the registers to determine the configuration, but as far as I understand
>>> it's the job of drivers to actually configure devices.
>>> The only way I could interpret this that makes sense to me is that you're
>>> trying to say that the device doesn't have registers that allow you to
>>> do runtime configuration detection - but that's the norm and I would not
>>> call it out here.
>>
>> No, I meant that the same register configuration will be set for
>> both fully differential and single-ended. 
>>
>> The user will set diff-channels = <0, 1>, bipolar(or not) and
>> then they can wire whatever to those pins: 
>> - a differential signal
>> - AVSS to 1 and a single-ended signal to 0
>> - AVSS+offset to 1 and a single-ended signal to 0
>> 	(which is called pseudo-differential in some datasheets)
>>
>> All these cases will look the same in terms of configuration
> 
> In that case, I'd just remove this sentence from the description then.
> How you configure the registers to use the device doesn't really have
> anything to do with describing the configuration of the hardware.
> Given it isn't related to configuration detection at runtime, what
> you've got written here just makes it seem like the property is
> redundant because the register settings do not change.
>
> Instead, use the description to talk about when the property should be
> used and what software should use it to determine, e.g. "Software can
> use vendor,channel-type to determine whether or not the measured voltage
> is absolute or relative". I pulled that outta my ass, it might not
> be what you're actually doing, but I figure you just want to know if
> you're measuring from the origin or either side of it.
>It's more to the "software can this property to correctly mark the channel
as differential or not". Hope this is acceptable. But got it, thanks.

> Cheers,
> Conor.


^ permalink raw reply	[relevance 1%]

* Re: [PATCH v2 0/2] drm/i915/display: Add comparison for pipe config for MTL+ >
  @ 2024-05-29 13:38  0% ` Jani Nikula
  0 siblings, 0 replies; 200+ results
From: Jani Nikula @ 2024-05-29 13:38 UTC (permalink / raw)
  To: Mika Kahola, intel-gfx; +Cc: Mika Kahola

On Thu, 23 May 2024, Mika Kahola <mika.kahola@intel.com> wrote:
> Currently, we may bump into pll mismatch errors during the
> state verification stage. This happens when we try to use
> fastset instead of full modeset. Hence, we would need to add
> a check for pipe configuration to ensure that the sw and the
> hw configuration will match. In case of hw and sw mismatch,
> we would need to disable fastset and use full modeset instead.
>
> However, first we need to revert the patch that disables fastset
> for C10.

I think the patch order should be reversed. Each commit should work. Can
be applied in a different order without resending.

There's maybe a bit too much happening in patch 2 for my liking, but
*shrug*.

Reviewed-by: Jani Nikula <jani.nikula@intel.com>



>
> v2: Fix C10 error on PLL comparison (BAT)
>     Use memcmp instead of fixed loops for pll config
>     comparison (Jani)
>     Clean up and use intel_cx0pll_dump_hw_state() to dump
>     pll information (Jani)
>
> Signed-off-by: Mika Kahola <mika.kahola@intel.com>
>
> Mika Kahola (2):
>   drm/i915/display: Revert "drm/i915/display: Skip C10 state
>     verification in case of fastset"
>   drm/i915/display: Add compare config for MTL+ platforms
>
>  drivers/gpu/drm/i915/display/intel_cx0_phy.c  | 80 ++++++++++++++++---
>  drivers/gpu/drm/i915/display/intel_cx0_phy.h  |  8 +-
>  drivers/gpu/drm/i915/display/intel_display.c  | 33 ++++++++
>  drivers/gpu/drm/i915/display/intel_dpll_mgr.h |  1 +
>  4 files changed, 109 insertions(+), 13 deletions(-)

-- 
Jani Nikula, Intel

^ permalink raw reply	[relevance 0%]

* Re: [meta-virtualization][PATCH] lxc: update to 6.0.0
       [not found]     ` <17C75EBD44309AA6.15491@lists.yoctoproject.org>
@ 2024-05-29 13:37  1%   ` Bruce Ashfield
  0 siblings, 0 replies; 200+ results
From: Bruce Ashfield @ 2024-05-29 13:37 UTC (permalink / raw)
  To: bruce.ashfield; +Cc: xiangyu.chen, meta-virtualization

As part of my fixing of the UNPACKDIR and other recent breakages due to oe-core
changes, I did a couple of early package updates. I included lxc, and
just let my scripts
do the uprev work.

Could you break the ptest parts out of this and re-submit them on top
of master-next ?

Bruce

On Thu, Apr 18, 2024 at 8:12 AM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@lists.yoctoproject.org> wrote:
>
> I'm not taking any package updates at this time, but I'll look at this when I do go through the next update cycle.
>
> Bruce
>
> On Thu, Apr 18, 2024 at 4:31 AM Xiangyu Chen via lists.yoctoproject.org <xiangyu.chen=eng.windriver.com@lists.yoctoproject.org> wrote:
>>
>> From: Xiangyu Chen <xiangyu.chen@windriver.com>
>>
>> Changes:
>> 17ac6f691 lxc.spec: Align SPDX license id
>> 5fe2de84c Makefile: Align SPDX license id
>> 97f93be72 meson: Align SPDX license id
>> d4cd3741d COPYING: Clarify licensing of files without SPDX
>> 8e67eb07c doc: Add SPDX headers and remove Author field
>> cb94edf53 src/include: Add SPDX headers
>> 7bc33ef6e src/tests: Add SPDX headers
>> 007642c89 hooks: Add SPDX headers
>> 1e9e66be3 lxc.spec: Clear default changelog
>> 202d649d1 lxc.spec: Use SPDX
>> 85abd4026 template: Use SPDX
>> a074b3d27 config/yum: Use SPDX header
>> 7ed43e5e9 COPYING: Remove whitespace
>> 522721216 MAINTAINERS: Remove Dwight from the maintainer list
>> 08bf8b9e2 lxc-checkconfig: Fix shellcheck
>> 0f18db543 lxc-checkconfig: Show namespace limits
>> f71b8e3f8 lxc-ls: list names with whitespaces in `--active`.
>> 816b8973d lxc/tools: set default log_priority to ERROR
>> 989ea3969 tools/lxc_autostart: don't fail when there are no containers
>> dc4df2335 lxc/lxccontainer: specify file mode in open() call inside mod_rdep
>> 630b46ed2 lxc/confile: do not print excess space before scale suffix for time.offset.boot
>> 796f2ccb7 lxc/confile: do not print newline symbol in getter for lxc.time.offset.*
>> dcc4fb929 tests/parse_config_file: fix some typos
>> 6fea67429 tests/parse_config_file: add tests for lxc.time.offset.*
>> ad8f55445 tree-wide: replace multiply_overflow with check_mul_overflow
>> 4464cee19 lxccontainer: rework copy_file()
>> 9d1aa932d lxccontainer: improve mod_rdep()
>> 81c1bbf45 Revert "lxccontainer: fixes"
>> 82fe01821 src/lxc/syscall_numbers.h: drop define -1
>> 590a95d83 rexec: Avoid invalid free in rexec failure path
>> f9978b179 README: Correct 'armvl7' to 'armv7l'
>> 046b63cd2 unshare: simplify lookup_name
>> 7452ee8ab lxc-unshare: fix an buffer overflow issue in lxc_unshare
>> e88883445 lxc-net: Enable IPv6 by default
>> d78ca00bc tests/meson: attempt to fix ossfuzz builds
>> d18f993b3 github: master -> main
>> 86799f554 meson: link with liblxc dynamically everywhere if possible
>> b90fecfda network: use IN_LIBLXC
>> 9eee450d2 storage_utils: move get_fssize to utils
>> 6eb0a73e2 storage_utils: unhide and rename is_valid_storage_type to lxc_is_valid_storage_type
>> 42eeffcb0 confile: unhide lxc_config_parse_arch() helper
>> 9bb318881 conf: reorganize/split code to utils.c
>> 863c59dc3 conf: reorganize/split code to idmap_utils.c
>> b7591ad49 confile: unhide lxc_config_define*() helpers
>> f14656ebf meson: introduce IN_LIBLXC preprocessor macro
>> 672b2172d confile: move lxc_fill_elevated_privileges() to tools/lxc_attach
>> 8f9733d75 tests: remove old and broken cgroup handling code from tests
>> d51ea224e config: apparmor: add AppArmor profile for lxc-copy
>> 627bb9460 tests: lxc-test-usernic: use iproute tool instead of brctl
>> df0665b6d oci: resolve cross-filesystem blob caching failure
>> ec85e5ca4 lxc-test-usernic: drop cgroup handling
>> 27ec0b0f6 test-usernic: don't use ifconfig
>> 44e845b3c Add x32 to the list of recognized architectures
>> 07e3a516e lxc-download, lxc-local: preserve xattrs on unpack
>> 9ac7c4895 tree-wide: use container_uses_namespace() in less trivial cases
>> 64341ce7b tree-wide: use container_uses_namespace() helper
>> 6b40e66c1 Fix error message.
>> c8189ee2a Add verbose output in download template.
>> 84cc3155a Align columns in lxc-download.in template
>> 872db5424 build: add more options for customizing install
>> df17ac417 Add loongarch64 support
>> 112d5615e build(deps): bump actions/upload-artifact from 3 to 4
>> 789457f1a config: try to create workdir if not exist
>> 86f5c1226 lxc-local: Add --no-dev option to exclude /dev from the fstree
>> f885a3c56 lxc-local: Re-organize code to use more functions
>> 7c025072e lxc-local: Improve usage info
>> faa38a197 lxc-local: Change LXC_CONFIG to LXC_METADATA to match args and be more clear
>> d65fe1b27 Disable IPv6 link-local addresses for bridged veth
>> 8cff8fa1a don't try to delete vlan 0 from veth
>> 0e932812a conf: fix ephemeral copies
>> abffab441 config/init: Drop upstart files
>> 79a4a3cf8 doc: remove the warning mentionning upstart
>> 7bf1695d0 hooks/ubuntu-cloud-prep: remove upstart handling
>> fb73c18d2 meson: Remove support for upstart
>> cc6819c69 reset root_nsuid_map and root_nsgid_map when idmaps is cleared
>> a87d6fcc9 lxc/checkconfig: use multiline `echo`
>> f3e01fa80 lxc/checkconfig: replace `echo -n` by printf
>> ba4f810bc lxc/checkconfig: minor cosmetic change
>> d52c345c8 lxc/checkconfig: avoid subshell (SC2235)
>> f84f03d1d lxc/checkconfig: remove superfluous (..) around test command (SC2234)
>> 74b9faa64 lxc/checkconfig: check exit code directly (SC2181)
>> 5cc69e440 lxc/checkconfig: replace `! -z` by `-n` (SC2236)
>> a4684eb11 lxc/checkconfig: add missing quotes to please shellcheck
>> 8a611c0b2 lxc/checkconfig: remove some unneeded `echo -n`
>> cb2574319 lxc/checkconfig: replace `type` by `command`
>> 003efe6db lxc/checkconfig: replace `cat | grep` with `grep`
>> adadfa372 lxc/lxccontainer: fix do_lxcapi_set_timeout retval
>> c02367e59 containers in the FREEZING state also need to be unfreeze
>> aca53bcf7 build(deps): bump actions/checkout from 3 to 4
>> 84169158f lxccontainer.h: Move new fields to the end
>> e2696df93 Remove references to LXD
>> 7cec54455 Update console perms to 0600
>> 3f45443fd Fix start api call to split quoted strings in execute or init command.
>>
>> Local patches modification:
>> Removed two patches due to they are available in the code:
>> 0001-lxc-test-usernic-drop-cgroup-handling.patch
>> 0001-tests-remove-old-and-broken-cgroup-handling-code-fro.patch
>>
>> Refreshed templates-use-curl-instead-of-wget.patch
>>
>> Ptest modification:
>> Released lxc-test-shutdowntest and lxc-test-state-server due to
>> those back to normal
>> lxc-test-no-new-privs and lxc-test-checkpoint-restore are
>> broken test, already reported to upstream[1][2], move them to blacklist
>> until upstream fixed them.
>> lxc-test-usernic always fails when use ptest-runner, but normal with
>> run-ptest by manual.
>>
>> Ref:
>> [1] https://github.com/lxc/lxc/issues/4296
>> [2] https://github.com/lxc/lxc/issues/4435
>>
>> Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
>> ---
>>  ...xc-test-usernic-drop-cgroup-handling.patch |  61 -----------
>>  ...-and-broken-cgroup-handling-code-fro.patch | 103 ------------------
>>  recipes-containers/lxc/files/run-ptest        |  12 +-
>>  .../templates-use-curl-instead-of-wget.patch  |  13 ++-
>>  recipes-containers/lxc/lxc_git.bb             |  10 +-
>>  5 files changed, 20 insertions(+), 179 deletions(-)
>>  delete mode 100644 recipes-containers/lxc/files/0001-lxc-test-usernic-drop-cgroup-handling.patch
>>  delete mode 100644 recipes-containers/lxc/files/0001-tests-remove-old-and-broken-cgroup-handling-code-fro.patch
>>
>> diff --git a/recipes-containers/lxc/files/0001-lxc-test-usernic-drop-cgroup-handling.patch b/recipes-containers/lxc/files/0001-lxc-test-usernic-drop-cgroup-handling.patch
>> deleted file mode 100644
>> index 162e8f9d..00000000
>> --- a/recipes-containers/lxc/files/0001-lxc-test-usernic-drop-cgroup-handling.patch
>> +++ /dev/null
>> @@ -1,61 +0,0 @@
>> -From ec85e5ca4953292c4341497704ce738669a79b64 Mon Sep 17 00:00:00 2001
>> -From: Serge Hallyn <serge@hallyn.com>
>> -Date: Fri, 2 Feb 2024 10:41:11 -0600
>> -Subject: [PATCH] lxc-test-usernic: drop cgroup handling
>> -
>> -This stuff is not needed in a modern systemd based system, and in fact
>> -breaks.  It would probably be better to detect such a system so that a
>> -non-systemd box can still run this test.  But I'm not sure what would be
>> -reliable.
>> -
>> -Upstream-Status: Backport from
>> -[https://github.com/lxc/lxc/commit/ec85e5ca4953292c4341497704ce738669a79b64]
>> -
>> -Signed-off-by: Serge Hallyn <serge@hallyn.com>
>> -Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
>> ----
>> - src/tests/lxc-test-usernic.in | 28 ----------------------------
>> - 1 file changed, 28 deletions(-)
>> -
>> -diff --git a/src/tests/lxc-test-usernic.in b/src/tests/lxc-test-usernic.in
>> -index 9af8678f3..49fd5e3f7 100755
>> ---- a/src/tests/lxc-test-usernic.in
>> -+++ b/src/tests/lxc-test-usernic.in
>> -@@ -80,34 +80,6 @@ lxc.idmap = u 0 910000 10000
>> - lxc.idmap = g 0 910000 10000
>> - EOF
>> -
>> --if command -v cgm >/dev/null 2>&1; then
>> --      cgm create all usernic-user
>> --      cgm chown all usernic-user $(id -u usernic-user) $(id -g usernic-user)
>> --      cgm movepid all usernic-user $$
>> --elif [ -e /sys/fs/cgroup/cgmanager/sock ]; then
>> --      for d in $(cut -d : -f 2 /proc/self/cgroup); do
>> --              dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock \
>> --                      --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.Create \
>> --                      string:$d string:usernic-user >/dev/null
>> --
>> --              dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock \
>> --                      --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.Chown \
>> --                      string:$d string:usernic-user int32:$(id -u usernic-user) int32:$(id -g usernic-user) >/dev/null
>> --
>> --              dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock \
>> --                      --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.MovePid \
>> --                      string:$d string:usernic-user int32:$$ >/dev/null
>> --      done
>> --else
>> --      for d in /sys/fs/cgroup/*; do
>> --              [ "$d" = "/sys/fs/cgroup/unified" ] && continue
>> --              [ -f $d/cgroup.clone_children ] && echo 1 > $d/cgroup.clone_children
>> --              [ ! -d $d/lxctest ] && mkdir $d/lxctest
>> --              chown -R usernic-user: $d/lxctest
>> --              echo $$ > $d/lxctest/tasks
>> --      done
>> --fi
>> --
>> - mkdir -p /run/user/$(id -u usernic-user)
>> - chown -R usernic-user: /run/user/$(id -u usernic-user) /home/usernic-user
>> -
>> ---
>> -2.35.5
>> -
>> diff --git a/recipes-containers/lxc/files/0001-tests-remove-old-and-broken-cgroup-handling-code-fro.patch b/recipes-containers/lxc/files/0001-tests-remove-old-and-broken-cgroup-handling-code-fro.patch
>> deleted file mode 100644
>> index bf8df795..00000000
>> --- a/recipes-containers/lxc/files/0001-tests-remove-old-and-broken-cgroup-handling-code-fro.patch
>> +++ /dev/null
>> @@ -1,103 +0,0 @@
>> -From 8f9733d756361ff8f8d8d589f286c0e064b1195d Mon Sep 17 00:00:00 2001
>> -From: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
>> -Date: Thu, 15 Feb 2024 18:13:05 +0100
>> -Subject: [PATCH] tests: remove old and broken cgroup handling code from tests
>> -
>> -We have removed the same piece of code in
>> -ec85e5ca495 ("lxc-test-usernic: drop cgroup handling")
>> -let's do the same for two other tests.
>> -
>> -This fixes autopkgtests.
>> -
>> -Upstream-Status: Backport from
>> -[https://github.com/lxc/lxc/commit/8f9733d756361ff8f8d8d589f286c0e064b1195d]
>> -
>> -Signed-off-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com>
>> -Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
>> ----
>> - src/tests/lxc-test-apparmor-mount | 29 -----------------------------
>> - src/tests/lxc-test-unpriv         | 28 ----------------------------
>> - 2 files changed, 57 deletions(-)
>> -
>> -diff --git a/src/tests/lxc-test-apparmor-mount b/src/tests/lxc-test-apparmor-mount
>> -index 7c9d9ad50..ddf783d4b 100755
>> ---- a/src/tests/lxc-test-apparmor-mount
>> -+++ b/src/tests/lxc-test-apparmor-mount
>> -@@ -119,35 +119,6 @@ chown -R $TUSER: /run/user/$(id -u $TUSER)
>> -
>> - cd $HDIR
>> -
>> --if command -v cgm >/dev/null 2>&1; then
>> --      cgm create all $TUSER
>> --      cgm chown all $TUSER $(id -u $TUSER) $(id -g $TUSER)
>> --      cgm movepid all $TUSER $$
>> --elif [ -e /sys/fs/cgroup/cgmanager/sock ]; then
>> --      for d in $(cut -d : -f 2 /proc/self/cgroup); do
>> --              dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock \
>> --                      --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.Create \
>> --                      string:$d string:$TUSER >/dev/null
>> --
>> --              dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock \
>> --                      --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.Chown \
>> --                      string:$d string:$TUSER int32:$(id -u $TUSER) int32:$(id -g $TUSER) >/dev/null
>> --
>> --              dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock \
>> --                      --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.MovePid \
>> --                      string:$d string:$TUSER int32:$$ >/dev/null
>> --      done
>> --else
>> --      for d in /sys/fs/cgroup/*; do
>> --              [ "$d" = "/sys/fs/cgroup/unified" ] && continue
>> --              [ -f $d/cgroup.clone_children ] && echo 1 > $d/cgroup.clone_children
>> --              [ ! -d $d/lxctest ] && mkdir $d/lxctest
>> --              chown -R $TUSER: $d/lxctest
>> --              echo $$ > $d/lxctest/tasks
>> --      done
>> --fi
>> --
>> --
>> - run_cmd lxc-create -t busybox -n $cname
>> -
>> - echo "test default confined container"
>> -diff --git a/src/tests/lxc-test-unpriv b/src/tests/lxc-test-unpriv
>> -index 8fb9106d6..426add9da 100755
>> ---- a/src/tests/lxc-test-unpriv
>> -+++ b/src/tests/lxc-test-unpriv
>> -@@ -130,34 +130,6 @@ chown -R $TUSER: /run/user/$(id -u $TUSER)
>> -
>> - cd $HDIR
>> -
>> --if command -v cgm >/dev/null 2>&1; then
>> --      cgm create all $TUSER
>> --      cgm chown all $TUSER $(id -u $TUSER) $(id -g $TUSER)
>> --      cgm movepid all $TUSER $$
>> --elif [ -e /sys/fs/cgroup/cgmanager/sock ]; then
>> --      for d in $(cut -d : -f 2 /proc/self/cgroup); do
>> --              dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock \
>> --                      --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.Create \
>> --                      string:$d string:$TUSER >/dev/null
>> --
>> --              dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock \
>> --                      --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.Chown \
>> --                      string:$d string:$TUSER int32:$(id -u $TUSER) int32:$(id -g $TUSER) >/dev/null
>> --
>> --              dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock \
>> --                      --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.MovePid \
>> --                      string:$d string:$TUSER int32:$$ >/dev/null
>> --      done
>> --else
>> --      for d in /sys/fs/cgroup/*; do
>> --              [ "$d" = "/sys/fs/cgroup/unified" ] && continue
>> --              [ -f $d/cgroup.clone_children ] && echo 1 > $d/cgroup.clone_children
>> --              [ ! -d $d/lxctest ] && mkdir $d/lxctest
>> --              chown -R $TUSER: $d/lxctest
>> --              echo $$ > $d/lxctest/tasks
>> --      done
>> --fi
>> --
>> - run_cmd lxc-create -t busybox -n c1 -l trace -o "${UNPRIV_LOG}"
>> -
>> - # Make sure we can start it - twice
>> ---
>> -2.35.5
>> -
>> diff --git a/recipes-containers/lxc/files/run-ptest b/recipes-containers/lxc/files/run-ptest
>> index 196adb04..278107d9 100644
>> --- a/recipes-containers/lxc/files/run-ptest
>> +++ b/recipes-containers/lxc/files/run-ptest
>> @@ -12,9 +12,15 @@ blacklist="$blacklist lxc-test-apparmor"
>>  blacklist="$blacklist lxc-test-apparmor-mount"
>>  #lxc-test-get_item would report Built without AppArmor support error
>>  blacklist="$blacklist lxc-test-get_item"
>> -# These currently hang so skip them until someone fixes them up
>> -blacklist="$blacklist lxc-test-shutdowntest"
>> -blacklist="$blacklist lxc-test-state-server"
>> +# This is a broken case, also fails on opensuse, already reported to
>> +# upstream https://github.com/lxc/lxc/issues/4296
>> +blacklist="$blacklist lxc-test-no-new-privs"
>> +# lxc doesn't adapt the criu's new mount flag, that cause restore fails
>> +# already reported to upstream https://github.com/lxc/lxc/issues/4435
>> +blacklist="$blacklist lxc-test-checkpoint-restore"
>> +# if we run "run-ptest" under /usr/lib64/lxc/ptest, the result is normal
>> +# but it would be failed when using "ptest-runner lxc"
>> +blacklist="$blacklist lxc-test-usernic"
>>
>>  # Tests in firstrunlist will be run first
>>  firstrunlist=""
>> diff --git a/recipes-containers/lxc/files/templates-use-curl-instead-of-wget.patch b/recipes-containers/lxc/files/templates-use-curl-instead-of-wget.patch
>> index e9af8335..3ef66138 100644
>> --- a/recipes-containers/lxc/files/templates-use-curl-instead-of-wget.patch
>> +++ b/recipes-containers/lxc/files/templates-use-curl-instead-of-wget.patch
>> @@ -10,6 +10,7 @@ Upstream-Status: Inappropriate [embedded specific]
>>  Signed-off-by: Joakim Roubert <joakimr@axis.com>
>>  Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com>
>>  Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
>> +Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
>>  ---
>>   templates/lxc-download.in | 8 ++++----
>>   1 file changed, 4 insertions(+), 4 deletions(-)
>> @@ -18,7 +19,7 @@ diff --git a/templates/lxc-download.in b/templates/lxc-download.in
>>  index a62ddf482..690307338 100755
>>  --- a/templates/lxc-download.in
>>  +++ b/templates/lxc-download.in
>> -@@ -59,9 +59,9 @@ cleanup() {
>> +@@ -45,9 +45,9 @@ cleanup() {
>>     fi
>>   }
>>
>> @@ -30,16 +31,16 @@ index a62ddf482..690307338 100755
>>         return 0
>>       fi
>>     done
>> -@@ -70,7 +70,7 @@ wget_wrapper() {
>> - }
>> -
>> - download_file() {
>> +@@ -59,7 +59,7 @@ download_file() {
>> +   if [ "${DOWNLOAD_VERBOSE}" = "true" ]; then
>> +     echo "Download file: https://${DOWNLOAD_SERVER}$1"
>> +   fi
>>  -  if ! wget_wrapper --user-agent="lxc/@PACKAGE_VERSION@ compat:${DOWNLOAD_COMPAT_LEVEL}" -T 30 -q "https://${DOWNLOAD_SERVER}/$1" -O "$2" >/dev/null 2>&1; then
>>  +  if ! curl_wrapper -L --user-agent "lxc/@PACKAGE_VERSION@ compat:${DOWNLOAD_COMPAT_LEVEL}" -m 30 -s "https://${DOWNLOAD_SERVER}/$1" -o "$2" >/dev/null 2>&1; then
>>       if [ "$3" = "noexit" ]; then
>>         return 1
>>       else
>> -@@ -176,7 +176,7 @@ while :; do
>> +@@ -167,7 +167,7 @@ while :; do
>>   done
>>
>>   # Check for required binaries
>> diff --git a/recipes-containers/lxc/lxc_git.bb b/recipes-containers/lxc/lxc_git.bb
>> index ee0e442f..379b4ecd 100644
>> --- a/recipes-containers/lxc/lxc_git.bb
>> +++ b/recipes-containers/lxc/lxc_git.bb
>> @@ -5,7 +5,7 @@ LIC_FILES_CHKSUM = "file://LICENSE.LGPL2.1;md5=4fbd65380cdd255951079008b364516c
>>                      file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
>>  "
>>
>> -DEPENDS = "libxml2 libcap"
>> +DEPENDS = "libxml2 libcap dbus"
>>  RDEPENDS:${PN} = " \
>>                 rsync \
>>                 curl \
>> @@ -36,7 +36,7 @@ RDEPENDS:${PN}-ptest += "file make gmp nettle gnutls bash libgcc"
>>
>>  RDEPENDS:${PN}-networking += "iptables"
>>
>> -SRC_URI = "git://github.com/lxc/lxc.git;branch=stable-5.0;protocol=https \
>> +SRC_URI = "git://github.com/lxc/lxc.git;branch=stable-6.0;protocol=https \
>>         file://lxc-1.0.0-disable-udhcp-from-busybox-template.patch \
>>         file://run-ptest \
>>         file://templates-actually-create-DOWNLOAD_TEMP-directory.patch \
>> @@ -47,12 +47,10 @@ SRC_URI = "git://github.com/lxc/lxc.git;branch=stable-5.0;protocol=https \
>>         file://0001-template-if-busybox-contains-init-use-it-in-containe.patch \
>>         file://dnsmasq.conf \
>>         file://lxc-net \
>> -       file://0001-lxc-test-usernic-drop-cgroup-handling.patch \
>> -       file://0001-tests-remove-old-and-broken-cgroup-handling-code-fro.patch \
>>         "
>>
>> -SRCREV = "cb8e38aca27a23964941f0f011a8919aab8bebab"
>> -PV = "5.0.3+git"
>> +SRCREV = "3dee5fb88c6f77496dbcab46f31bcd891c9ee4e0"
>> +PV = "6.0.0+git"
>>
>>  S = "${WORKDIR}/git"
>>
>> --
>> 2.25.1
>>
>>
>>
>>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#8685): https://lists.yoctoproject.org/g/meta-virtualization/message/8685
> Mute This Topic: https://lists.yoctoproject.org/mt/105594307/1050810
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


^ permalink raw reply	[relevance 1%]

* [PATCH v10 06/19] ACPI: processor: Move checks and availability of acpi_processor earlier
  2024-05-29 13:34  2% ` Jonathan Cameron
@ 2024-05-29 13:34  3%   ` Jonathan Cameron
  -1 siblings, 0 replies; 200+ results
From: Jonathan Cameron @ 2024-05-29 13:34 UTC (permalink / raw)
  To: Marc Zyngier, Will Deacon, Catalin Marinas, linux-acpi,
	linux-arch, linux-kernel, linux-arm-kernel, linux-pm
  Cc: Mark Rutland, Thomas Gleixner, Peter Zijlstra, loongarch, x86,
	Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
	Salil Mehta, Jean-Philippe Brucker, Hanjun Guo, Gavin Shan,
	Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm, justin.he,
	jianyong.wu

Make the per_cpu(processors, cpu) entries available earlier so that
they are available in arch_register_cpu() as ARM64 will need access
to the acpi_handle to distinguish between acpi_processor_add()
and earlier registration attempts (which will fail as _STA cannot
be checked).

Reorder the remove flow to clear this per_cpu() after
arch_unregister_cpu() has completed, allowing it to be used in
there as well.

Note that on x86 for the CPU hotplug case, the pr->id prior to
acpi_map_cpu() may be invalid. Thus the per_cpu() structures
must be initialized after that call or after checking the ID
is valid (not hotplug path).

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

---
v10: Thanks To Rafael and Gavin for the same suggestion.
  - Make the acpi_process_set_per_cpu() function return an int
    (-EINVAL or 0 as appropriate), simplifying how it is used.
---
 drivers/acpi/acpi_processor.c | 88 +++++++++++++++++++++--------------
 1 file changed, 52 insertions(+), 36 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 16e36e55a560..0bc0419adf6b 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -183,8 +183,38 @@ static void __init acpi_pcc_cpufreq_init(void) {}
 #endif /* CONFIG_X86 */
 
 /* Initialization */
+static DEFINE_PER_CPU(void *, processor_device_array);
+
+static int acpi_processor_set_per_cpu(struct acpi_processor *pr,
+				      struct acpi_device *device)
+{
+	BUG_ON(pr->id >= nr_cpu_ids);
+
+	/*
+	 * Buggy BIOS check.
+	 * ACPI id of processors can be reported wrongly by the BIOS.
+	 * Don't trust it blindly
+	 */
+	if (per_cpu(processor_device_array, pr->id) != NULL &&
+	    per_cpu(processor_device_array, pr->id) != device) {
+		dev_warn(&device->dev,
+			 "BIOS reported wrong ACPI id %d for the processor\n",
+			 pr->id);
+		return -EINVAL;
+	}
+	/*
+	 * processor_device_array is not cleared on errors to allow buggy BIOS
+	 * checks.
+	 */
+	per_cpu(processor_device_array, pr->id) = device;
+	per_cpu(processors, pr->id) = pr;
+
+	return 0;
+}
+
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
-static int acpi_processor_hotadd_init(struct acpi_processor *pr)
+static int acpi_processor_hotadd_init(struct acpi_processor *pr,
+				      struct acpi_device *device)
 {
 	int ret;
 
@@ -198,8 +228,16 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
 	if (ret)
 		goto out;
 
+	ret = acpi_processor_set_per_cpu(pr, device);
+	if (ret) {
+		acpi_unmap_cpu(pr->id);
+		goto out;
+	}
+
 	ret = arch_register_cpu(pr->id);
 	if (ret) {
+		/* Leave the processor device array in place to detect buggy bios */
+		per_cpu(processors, pr->id) = NULL;
 		acpi_unmap_cpu(pr->id);
 		goto out;
 	}
@@ -217,7 +255,8 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
 	return ret;
 }
 #else
-static inline int acpi_processor_hotadd_init(struct acpi_processor *pr)
+static inline int acpi_processor_hotadd_init(struct acpi_processor *pr,
+					     struct acpi_device *device)
 {
 	return -ENODEV;
 }
@@ -232,6 +271,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
 	acpi_status status = AE_OK;
 	static int cpu0_initialized;
 	unsigned long long value;
+	int ret;
 
 	acpi_processor_errata();
 
@@ -315,12 +355,12 @@ static int acpi_processor_get_info(struct acpi_device *device)
 	 *  NOTE: Even if the processor has a cpuid, it may not be present
 	 *  because cpuid <-> apicid mapping is persistent now.
 	 */
-	if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) {
-		int ret = acpi_processor_hotadd_init(pr);
-
-		if (ret)
-			return ret;
-	}
+	if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id))
+		ret = acpi_processor_hotadd_init(pr, device);
+	else
+		ret = acpi_processor_set_per_cpu(pr, device);
+	if (ret)
+		return ret;
 
 	/*
 	 * On some boxes several processors use the same processor bus id.
@@ -365,8 +405,6 @@ static int acpi_processor_get_info(struct acpi_device *device)
  * (cpu_data(cpu)) values, like CPU feature flags, family, model, etc.
  * Such things have to be put in and set up by the processor driver's .probe().
  */
-static DEFINE_PER_CPU(void *, processor_device_array);
-
 static int acpi_processor_add(struct acpi_device *device,
 					const struct acpi_device_id *id)
 {
@@ -395,28 +433,6 @@ static int acpi_processor_add(struct acpi_device *device,
 	if (result) /* Processor is not physically present or unavailable */
 		goto err_clear_driver_data;
 
-	BUG_ON(pr->id >= nr_cpu_ids);
-
-	/*
-	 * Buggy BIOS check.
-	 * ACPI id of processors can be reported wrongly by the BIOS.
-	 * Don't trust it blindly
-	 */
-	if (per_cpu(processor_device_array, pr->id) != NULL &&
-	    per_cpu(processor_device_array, pr->id) != device) {
-		dev_warn(&device->dev,
-			"BIOS reported wrong ACPI id %d for the processor\n",
-			pr->id);
-		/* Give up, but do not abort the namespace scan. */
-		goto err_clear_driver_data;
-	}
-	/*
-	 * processor_device_array is not cleared on errors to allow buggy BIOS
-	 * checks.
-	 */
-	per_cpu(processor_device_array, pr->id) = device;
-	per_cpu(processors, pr->id) = pr;
-
 	dev = get_cpu_device(pr->id);
 	if (!dev) {
 		result = -ENODEV;
@@ -470,10 +486,6 @@ static void acpi_processor_remove(struct acpi_device *device)
 	device_release_driver(pr->dev);
 	acpi_unbind_one(pr->dev);
 
-	/* Clean up. */
-	per_cpu(processor_device_array, pr->id) = NULL;
-	per_cpu(processors, pr->id) = NULL;
-
 	cpu_maps_update_begin();
 	cpus_write_lock();
 
@@ -481,6 +493,10 @@ static void acpi_processor_remove(struct acpi_device *device)
 	arch_unregister_cpu(pr->id);
 	acpi_unmap_cpu(pr->id);
 
+	/* Clean up. */
+	per_cpu(processor_device_array, pr->id) = NULL;
+	per_cpu(processors, pr->id) = NULL;
+
 	cpus_write_unlock();
 	cpu_maps_update_done();
 
-- 
2.39.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 3%]

* [PATCH v10 06/19] ACPI: processor: Move checks and availability of acpi_processor earlier
@ 2024-05-29 13:34  3%   ` Jonathan Cameron
  0 siblings, 0 replies; 200+ results
From: Jonathan Cameron @ 2024-05-29 13:34 UTC (permalink / raw)
  To: Marc Zyngier, Will Deacon, Catalin Marinas, linux-acpi,
	linux-arch, linux-kernel, linux-arm-kernel, linux-pm
  Cc: Mark Rutland, Thomas Gleixner, Peter Zijlstra, loongarch, x86,
	Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
	Salil Mehta, Jean-Philippe Brucker, Hanjun Guo, Gavin Shan,
	Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm, justin.he,
	jianyong.wu

Make the per_cpu(processors, cpu) entries available earlier so that
they are available in arch_register_cpu() as ARM64 will need access
to the acpi_handle to distinguish between acpi_processor_add()
and earlier registration attempts (which will fail as _STA cannot
be checked).

Reorder the remove flow to clear this per_cpu() after
arch_unregister_cpu() has completed, allowing it to be used in
there as well.

Note that on x86 for the CPU hotplug case, the pr->id prior to
acpi_map_cpu() may be invalid. Thus the per_cpu() structures
must be initialized after that call or after checking the ID
is valid (not hotplug path).

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

---
v10: Thanks To Rafael and Gavin for the same suggestion.
  - Make the acpi_process_set_per_cpu() function return an int
    (-EINVAL or 0 as appropriate), simplifying how it is used.
---
 drivers/acpi/acpi_processor.c | 88 +++++++++++++++++++++--------------
 1 file changed, 52 insertions(+), 36 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 16e36e55a560..0bc0419adf6b 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -183,8 +183,38 @@ static void __init acpi_pcc_cpufreq_init(void) {}
 #endif /* CONFIG_X86 */
 
 /* Initialization */
+static DEFINE_PER_CPU(void *, processor_device_array);
+
+static int acpi_processor_set_per_cpu(struct acpi_processor *pr,
+				      struct acpi_device *device)
+{
+	BUG_ON(pr->id >= nr_cpu_ids);
+
+	/*
+	 * Buggy BIOS check.
+	 * ACPI id of processors can be reported wrongly by the BIOS.
+	 * Don't trust it blindly
+	 */
+	if (per_cpu(processor_device_array, pr->id) != NULL &&
+	    per_cpu(processor_device_array, pr->id) != device) {
+		dev_warn(&device->dev,
+			 "BIOS reported wrong ACPI id %d for the processor\n",
+			 pr->id);
+		return -EINVAL;
+	}
+	/*
+	 * processor_device_array is not cleared on errors to allow buggy BIOS
+	 * checks.
+	 */
+	per_cpu(processor_device_array, pr->id) = device;
+	per_cpu(processors, pr->id) = pr;
+
+	return 0;
+}
+
 #ifdef CONFIG_ACPI_HOTPLUG_CPU
-static int acpi_processor_hotadd_init(struct acpi_processor *pr)
+static int acpi_processor_hotadd_init(struct acpi_processor *pr,
+				      struct acpi_device *device)
 {
 	int ret;
 
@@ -198,8 +228,16 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
 	if (ret)
 		goto out;
 
+	ret = acpi_processor_set_per_cpu(pr, device);
+	if (ret) {
+		acpi_unmap_cpu(pr->id);
+		goto out;
+	}
+
 	ret = arch_register_cpu(pr->id);
 	if (ret) {
+		/* Leave the processor device array in place to detect buggy bios */
+		per_cpu(processors, pr->id) = NULL;
 		acpi_unmap_cpu(pr->id);
 		goto out;
 	}
@@ -217,7 +255,8 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
 	return ret;
 }
 #else
-static inline int acpi_processor_hotadd_init(struct acpi_processor *pr)
+static inline int acpi_processor_hotadd_init(struct acpi_processor *pr,
+					     struct acpi_device *device)
 {
 	return -ENODEV;
 }
@@ -232,6 +271,7 @@ static int acpi_processor_get_info(struct acpi_device *device)
 	acpi_status status = AE_OK;
 	static int cpu0_initialized;
 	unsigned long long value;
+	int ret;
 
 	acpi_processor_errata();
 
@@ -315,12 +355,12 @@ static int acpi_processor_get_info(struct acpi_device *device)
 	 *  NOTE: Even if the processor has a cpuid, it may not be present
 	 *  because cpuid <-> apicid mapping is persistent now.
 	 */
-	if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) {
-		int ret = acpi_processor_hotadd_init(pr);
-
-		if (ret)
-			return ret;
-	}
+	if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id))
+		ret = acpi_processor_hotadd_init(pr, device);
+	else
+		ret = acpi_processor_set_per_cpu(pr, device);
+	if (ret)
+		return ret;
 
 	/*
 	 * On some boxes several processors use the same processor bus id.
@@ -365,8 +405,6 @@ static int acpi_processor_get_info(struct acpi_device *device)
  * (cpu_data(cpu)) values, like CPU feature flags, family, model, etc.
  * Such things have to be put in and set up by the processor driver's .probe().
  */
-static DEFINE_PER_CPU(void *, processor_device_array);
-
 static int acpi_processor_add(struct acpi_device *device,
 					const struct acpi_device_id *id)
 {
@@ -395,28 +433,6 @@ static int acpi_processor_add(struct acpi_device *device,
 	if (result) /* Processor is not physically present or unavailable */
 		goto err_clear_driver_data;
 
-	BUG_ON(pr->id >= nr_cpu_ids);
-
-	/*
-	 * Buggy BIOS check.
-	 * ACPI id of processors can be reported wrongly by the BIOS.
-	 * Don't trust it blindly
-	 */
-	if (per_cpu(processor_device_array, pr->id) != NULL &&
-	    per_cpu(processor_device_array, pr->id) != device) {
-		dev_warn(&device->dev,
-			"BIOS reported wrong ACPI id %d for the processor\n",
-			pr->id);
-		/* Give up, but do not abort the namespace scan. */
-		goto err_clear_driver_data;
-	}
-	/*
-	 * processor_device_array is not cleared on errors to allow buggy BIOS
-	 * checks.
-	 */
-	per_cpu(processor_device_array, pr->id) = device;
-	per_cpu(processors, pr->id) = pr;
-
 	dev = get_cpu_device(pr->id);
 	if (!dev) {
 		result = -ENODEV;
@@ -470,10 +486,6 @@ static void acpi_processor_remove(struct acpi_device *device)
 	device_release_driver(pr->dev);
 	acpi_unbind_one(pr->dev);
 
-	/* Clean up. */
-	per_cpu(processor_device_array, pr->id) = NULL;
-	per_cpu(processors, pr->id) = NULL;
-
 	cpu_maps_update_begin();
 	cpus_write_lock();
 
@@ -481,6 +493,10 @@ static void acpi_processor_remove(struct acpi_device *device)
 	arch_unregister_cpu(pr->id);
 	acpi_unmap_cpu(pr->id);
 
+	/* Clean up. */
+	per_cpu(processor_device_array, pr->id) = NULL;
+	per_cpu(processors, pr->id) = NULL;
+
 	cpus_write_unlock();
 	cpu_maps_update_done();
 
-- 
2.39.2


^ permalink raw reply related	[relevance 3%]

* [PATCH] doc: Add UEFI supplement document
@ 2024-05-29 13:36  4% Jiaxun Yang
  0 siblings, 0 replies; 200+ results
From: Jiaxun Yang @ 2024-05-29 13:36 UTC (permalink / raw)
  To: u-boot; +Cc: Tom Rini, Heinrich Schuchardt, Ilias Apalodimas, Jiaxun Yang

Add UEFI supplement document to define some behaviours
on architectures not covered by the original specification.

Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
Hi all,

This document is in response to discussion at [1]. It is produced
based on my attempt to port U-Boot UEFI to MIPS and Xtensa. I also
plan to try m68k.

Please review

Thanks
[1]: https://lore.kernel.org/u-boot/CAC_iWjLbY6+FaUYQw2Zv5y5byCnXRHxfzvrFf1dMyJX+ANP9VQ@mail.gmail.com/
---
 doc/develop/uefi/index.rst           |  1 +
 doc/develop/uefi/uefi_supplement.rst | 73 ++++++++++++++++++++++++++++++++++++
 2 files changed, 74 insertions(+)

diff --git a/doc/develop/uefi/index.rst b/doc/develop/uefi/index.rst
index e26b1fbe05c5..a274fff88754 100644
--- a/doc/develop/uefi/index.rst
+++ b/doc/develop/uefi/index.rst
@@ -11,6 +11,7 @@ can be run an UEFI payload.
    :maxdepth: 2
 
    uefi.rst
+   uefi_supplement.rst
    u-boot_on_efi.rst
    iscsi.rst
    fwu_updates.rst
diff --git a/doc/develop/uefi/uefi_supplement.rst b/doc/develop/uefi/uefi_supplement.rst
new file mode 100644
index 000000000000..cb20cd290912
--- /dev/null
+++ b/doc/develop/uefi/uefi_supplement.rst
@@ -0,0 +1,73 @@
+.. SPDX-License-Identifier: GPL-2.0+
+.. Copyright (c) 2024 Jiaxun Yang <jiaxun.yang@flygoat.com>
+
+U-Boot Supplement to UEFI Specifications
+========================================
+
+Motivation
+----------
+
+The UEFI specifications are designed to be platform-independent, enabling the
+implementation of UEFI-like API support across various architectures. However,
+some platform-dependent aspects and constraints remain. This document provides
+a supplement to the UEFI specifications for U-Boot, clarifying these platform
+dependent details for architectures not covered by the original specifications.
+
+Architectural Conventions
+-------------------------
+
+The UEFI specifications cover IA32, X64, ARM, AARCH64, RISC-V, LoongArch, and
+Itanium architectures. This document extends the UEFI specifications to include
+all architectures supported by U-Boot.
+
+The following conventions are used for these architectures:
+
+- For architectures with multiple ABIs, we adhere to the calling conventions
+  used by the Linux kernel for the same architecture.
+
+- Optional CPU registers (floating-point, SIMD) are excluded from calling
+  conventions. However, the UEFI payload should be able to utilize them if
+  available.
+
+- Control is handed over to the UEFI payload at the privilege level used
+  by the Linux kernel for the same architecture.
+
+- Identity mapping (i.e., VA == PA mapping) is preferred for UEFI. However,
+  this may not be possible for some architectures. In such cases, if the
+  processor supports a default linear translation, it should be used.
+
+- Endianness: UEFI specifications enforce little-endian architectures.
+  However, U-Boot supports both little-endian and big-endian architectures.
+  For big-endian architectures, UEFI data structures should be stored in
+  native endianness, with exceptions explicitly specified.
+
+UEFI Images
+-----------
+
+The UEFI specifications define the PE/COFF image format for UEFI applications.
+U-Boot extends this format as follows:
+
+- **PE32+ Machine Type**: UEFI specifications define machine types for supported
+  architectures. For machines not covered by UEFI specifications, we use the
+  machine type defined by the Microsoft PE/COFF specification if possible.
+  Otherwise, we use the ``IMAGE_FILE_MACHINE_UNKNOWN`` (0) machine type.
+  U-Boot should always accept ``IMAGE_FILE_MACHINE_UNKNOWN`` as a valid
+  machine type.
+
+- **Header Endianness**: PE/COFF header data fields are always stored as
+  little-endian, regardless of the target architecture's endianness.
+
+- **DOS Stub**: To accommodate various boot image formats, we relax the requirement
+  for a DOS stub in the UEFI image. U-Boot should accept UEFI images without a DOS
+  stub and MZ signature. However, U-Boot still expects the PE/COFF header at the
+  file offset specified at offset 0x3C.
+
+I/O Device Access
+-----------------
+
+UEFI specifications define the EFI_DEVICE_IO_PROTOCOL and EFI_PCI_IO_PROTOCOL
+for accessing I/O devices. U-Boot extends these specifications as follows:
+
+- All I/O access is performed using the CPU's native endianness.
+  For big-endian architectures, U-Boot should convert data to/from little-endian
+  before/after accessing I/O devices.

---
base-commit: 46ff00bea5dd2dd247d5e2fdadbf5dcf8653cd9a
change-id: 20240529-efi-spec-0ea657985272

Best regards,
-- 
Jiaxun Yang <jiaxun.yang@flygoat.com>


^ permalink raw reply related	[relevance 4%]

* Re: Intermittent inability to type in graphical Plymouth on UEFI VMs since kernel 6.9
  @ 2024-05-29 13:35  1%     ` Genes Lists
  0 siblings, 0 replies; 200+ results
From: Genes Lists @ 2024-05-29 13:35 UTC (permalink / raw)
  To: Linux regressions mailing list, Adam Williamson, linux-kernel
  Cc: jforbes, rstrode


[-- Attachment #1.1: Type: text/plain, Size: 860 bytes --]

On Wed, 2024-05-29 at 15:01 +0200, Linux regression tracking (Thorsten
Leemhuis) wrote:
> > 
> >     cpu i9-12900K  / Raptor Lake-P [Iris Xe Graphics]

  Sorry, this should be:  13th Gen Intel(R) Core(TM) i7-1360P


> > 
> 
> Does this happen every boot or only sometimes? Could you maybe upload
> the full dmesg from a boot where things worked and one where only the

For me it is every boot - the first few key strokes are accepted but no
asterisks are displayed - and it works fine even though fewer asterisks
are displayed than characters typed.


full dmesg attached.

> 
> P.S.: let me add this to the regression tracking
> 
> #regzbot report: /
> #regzbot introduced: v6.8..v6.9
> #regzbot summary: Intermittent inability to type in graphical
> Plymouth
> on UEFI VMs since kernel 6.9
> 

Thank you.


-- 
Gene


[-- Attachment #1.2: dmesg --]
[-- Type: text/plain, Size: 120990 bytes --]

[May27 07:45] Linux version 6.10.0-rc1-custom-2 (linux-custom@saplinux) (gcc (GCC) 14.1.1 20240522, GNU ld (GNU Binutils) 2.42.0) #1 SMP PREEMPT_DYNAMIC Mon, 27 May 2024 10:57:51 +0000
[  +0.000000] Command line: initrd=\initrd-linux-custom.img root="UUID=aa97c5c2-c3cf-4b82-8773-5970f490a90b" rw audit=0 quiet splash
[  +0.000000] x86/split lock detection: #AC: crashing the kernel on kernel split_locks and warning on user-space split_locks
[  +0.000000] BIOS-provided physical RAM map:
[  +0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
[  +0.000000] BIOS-e820: [mem 0x000000000009f000-0x00000000000fffff] reserved
[  +0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000580b5fff] usable
[  +0.000000] BIOS-e820: [mem 0x00000000580b6000-0x000000005d110fff] reserved
[  +0.000000] BIOS-e820: [mem 0x000000005d111000-0x000000005d971fff] ACPI NVS
[  +0.000000] BIOS-e820: [mem 0x000000005d972000-0x000000005dbfefff] ACPI data
[  +0.000000] BIOS-e820: [mem 0x000000005dbff000-0x000000005dbfffff] usable
[  +0.000000] BIOS-e820: [mem 0x000000005dc00000-0x00000000663fffff] reserved
[  +0.000000] BIOS-e820: [mem 0x0000000066e00000-0x00000000707fffff] reserved
[  +0.000000] BIOS-e820: [mem 0x00000000c0000000-0x00000000cfffffff] reserved
[  +0.000000] BIOS-e820: [mem 0x00000000f9000000-0x00000000f9ffffff] reserved
[  +0.000000] BIOS-e820: [mem 0x00000000fed20000-0x00000000fed7ffff] reserved
[  +0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
[  +0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000088f7fffff] usable
[  +0.000000] NX (Execute Disable) protection: active
[  +0.000000] APIC: Static calls initialized
[  +0.000000] efi: EFI v2.7 by Dell
[  +0.000000] efi: ACPI=0x5dbfe000 ACPI 2.0=0x5dbfe014 SMBIOS=0x58c06000 TPMFinalLog=0x5d8ab000 ESRT=0x58b9e718 MEMATTR=0x52a61018 RNG=0x5db2df18 INITRD=0x529f9718 TPMEventLog=0x529da018 
[  +0.000000] random: crng init done
[  +0.000000] efi: Remove mem131: MMIO range=[0xc0000000-0xcfffffff] (256MB) from e820 map
[  +0.000000] e820: remove [mem 0xc0000000-0xcfffffff] reserved
[  +0.000000] efi: Remove mem132: MMIO range=[0xf9000000-0xf9ffffff] (16MB) from e820 map
[  +0.000000] e820: remove [mem 0xf9000000-0xf9ffffff] reserved
[  +0.000000] efi: Remove mem134: MMIO range=[0xff000000-0xffffffff] (16MB) from e820 map
[  +0.000000] e820: remove [mem 0xff000000-0xffffffff] reserved
[  +0.000000] SMBIOS 3.6 present.
[  +0.000000] DMI: Dell Inc. XPS 9320/0CR6NC, BIOS 2.11.0 03/06/2024
[  +0.000000] DMI: Memory slots populated: 8/8
[  +0.000000] tsc: Detected 2600.000 MHz processor
[  +0.000000] tsc: Detected 2611.200 MHz TSC
[  +0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[  +0.000005] e820: remove [mem 0x000a0000-0x000fffff] usable
[  +0.000011] last_pfn = 0x88f800 max_arch_pfn = 0x400000000
[  +0.000007] MTRR map: 5 entries (3 fixed + 2 variable; max 23), built from 10 variable MTRRs
[  +0.000003] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[  +0.000748] last_pfn = 0x5dc00 max_arch_pfn = 0x400000000
[  +0.012385] esrt: Reserving ESRT space from 0x0000000058b9e718 to 0x0000000058b9e7a0.
[  +0.000025] Using GB pages for direct mapping
[  +0.000002] Incomplete global flushes, disabling PCID
[  +0.000320] Secure boot disabled
[  +0.000001] RAMDISK: [mem 0x4c812000-0x4eb3ffff]
[  +0.000009] ACPI: Early table checksum verification disabled
[  +0.000005] ACPI: RSDP 0x000000005DBFE014 000024 (v02 DELL  )
[  +0.000007] ACPI: XSDT 0x000000005DB3D188 00012C (v01 DELL   Dell Inc 00000002      01000013)
[  +0.000010] ACPI: FACP 0x000000005DBF0000 000114 (v06 DELL   Dell Inc 00000002      01000013)
[  +0.000008] ACPI: DSDT 0x000000005DB67000 085BFD (v02 DELL   Dell Inc 00000002      01000013)
[  +0.000005] ACPI: FACS 0x000000005D8DB000 000040
[  +0.000004] ACPI: SSDT 0x000000005DBFC000 00038C (v02 PmaxDv Pmax_Dev 00000001 INTL 20200717)
[  +0.000005] ACPI: SSDT 0x000000005DBF6000 005C55 (v02 CpuRef CpuSsdt  00003000 INTL 20200717)
[  +0.000005] ACPI: SSDT 0x000000005DBF1000 004472 (v02 DptfTb DptfTabl 00001000 INTL 20200717)
[  +0.000005] ACPI: HPET 0x000000005DBEF000 000038 (v01 DELL   Dell Inc 00000002      01000013)
[  +0.000004] ACPI: APIC 0x000000005DBEE000 0001DC (v05 DELL   Dell Inc 00000002      01000013)
[  +0.000005] ACPI: MCFG 0x000000005DBED000 00003C (v01 DELL   Dell Inc 00000002      01000013)
[  +0.000004] ACPI: SSDT 0x000000005DB65000 0013DF (v02 DELL   DellRtd3 00001000 INTL 20200717)
[  +0.000005] ACPI: SSDT 0x000000005DB62000 002C71 (v02 SaSsdt SaSsdt   00003000 INTL 20200717)
[  +0.000004] ACPI: SSDT 0x000000005DB60000 001343 (v02 INTEL  IgfxSsdt 00003000 INTL 20200717)
[  +0.000004] ACPI: SSDT 0x000000005DB52000 00D7C2 (v02 INTEL  TcssSsdt 00001000 INTL 20200717)
[  +0.000005] ACPI: SSDT 0x000000005DB51000 000150 (v02 INTEL  IpuSsdt  00001000 INTL 20200717)
[  +0.000004] ACPI: NHLT 0x000000005DB50000 0002F1 (v00 DELL   Dell Inc 00000002      01000013)
[  +0.000005] ACPI: SSDT 0x000000005DB4E000 0010C0 (v02 DELL   UsbCTabl 00001000 INTL 20200717)
[  +0.000004] ACPI: LPIT 0x000000005DB4D000 0000CC (v01 DELL   Dell Inc 00000002      01000013)
[  +0.000005] ACPI: WSMT 0x000000005DB4C000 000028 (v01 DELL   Dell Inc 00000002      01000013)
[  +0.000004] ACPI: SSDT 0x000000005DB4B000 000B44 (v02 DELL   PtidDevc 00001000 INTL 20200717)
[  +0.000005] ACPI: SSDT 0x000000005DB41000 0092F4 (v02 DELL   TbtTypeC 00000000 INTL 20200717)
[  +0.000004] ACPI: DBGP 0x000000005DB40000 000034 (v01 DELL   Dell Inc 00000002      01000013)
[  +0.000005] ACPI: DBG2 0x000000005DB3F000 000054 (v00 DELL   Dell Inc 00000002      01000013)
[  +0.000004] ACPI: BOOT 0x000000005DB3E000 000028 (v01 DELL   CBX3     00000002      01000013)
[  +0.000005] ACPI: SSDT 0x000000005DBFD000 00060E (v02 DELL   Tpm2Tabl 00001000 INTL 20200717)
[  +0.000004] ACPI: TPM2 0x000000005DB3C000 00004C (v04 DELL   Dell Inc 00000002      01000013)
[  +0.000005] ACPI: DMAR 0x000000005DB3B000 0000A0 (v01 INTEL  Dell Inc 00000002      01000013)
[  +0.000004] ACPI: FPDT 0x000000005DB3A000 000034 (v01 DELL   Dell Inc 00000002      01000013)
[  +0.000005] ACPI: SSDT 0x000000005DB39000 0009CC (v02 DELL   xh_Dell_ 00000000 INTL 20200717)
[  +0.000004] ACPI: SSDT 0x000000005DB35000 0039DA (v02 SocGpe SocGpe   00003000 INTL 20200717)
[  +0.000005] ACPI: SSDT 0x000000005DB31000 0039DA (v02 SocCmn SocCmn   00003000 INTL 20200717)
[  +0.000004] ACPI: SSDT 0x000000005DB30000 000144 (v02 Intel  ADebTabl 00001000 INTL 20200717)
[  +0.000004] ACPI: UEFI 0x000000005D8A6000 00063A (v01 INTEL  RstVmdE  00000000 INTL 00000000)
[  +0.000005] ACPI: UEFI 0x000000005D8A5000 00005C (v01 INTEL  RstVmdV  00000000 INTL 00000000)
[  +0.000005] ACPI: PHAT 0x000000005DB2F000 0005AD (v01 DELL   Dell Inc 00000005 MSFT 0100000D)
[  +0.000004] ACPI: BGRT 0x000000005DB2E000 000038 (v01 DELL   Dell Inc 00000002      01000013)
[  +0.000004] ACPI: Reserving FACP table memory at [mem 0x5dbf0000-0x5dbf0113]
[  +0.000002] ACPI: Reserving DSDT table memory at [mem 0x5db67000-0x5dbecbfc]
[  +0.000002] ACPI: Reserving FACS table memory at [mem 0x5d8db000-0x5d8db03f]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5dbfc000-0x5dbfc38b]
[  +0.000002] ACPI: Reserving SSDT table memory at [mem 0x5dbf6000-0x5dbfbc54]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5dbf1000-0x5dbf5471]
[  +0.000001] ACPI: Reserving HPET table memory at [mem 0x5dbef000-0x5dbef037]
[  +0.000001] ACPI: Reserving APIC table memory at [mem 0x5dbee000-0x5dbee1db]
[  +0.000002] ACPI: Reserving MCFG table memory at [mem 0x5dbed000-0x5dbed03b]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5db65000-0x5db663de]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5db62000-0x5db64c70]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5db60000-0x5db61342]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5db52000-0x5db5f7c1]
[  +0.000002] ACPI: Reserving SSDT table memory at [mem 0x5db51000-0x5db5114f]
[  +0.000001] ACPI: Reserving NHLT table memory at [mem 0x5db50000-0x5db502f0]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5db4e000-0x5db4f0bf]
[  +0.000001] ACPI: Reserving LPIT table memory at [mem 0x5db4d000-0x5db4d0cb]
[  +0.000002] ACPI: Reserving WSMT table memory at [mem 0x5db4c000-0x5db4c027]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5db4b000-0x5db4bb43]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5db41000-0x5db4a2f3]
[  +0.000001] ACPI: Reserving DBGP table memory at [mem 0x5db40000-0x5db40033]
[  +0.000001] ACPI: Reserving DBG2 table memory at [mem 0x5db3f000-0x5db3f053]
[  +0.000002] ACPI: Reserving BOOT table memory at [mem 0x5db3e000-0x5db3e027]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5dbfd000-0x5dbfd60d]
[  +0.000001] ACPI: Reserving TPM2 table memory at [mem 0x5db3c000-0x5db3c04b]
[  +0.000002] ACPI: Reserving DMAR table memory at [mem 0x5db3b000-0x5db3b09f]
[  +0.000001] ACPI: Reserving FPDT table memory at [mem 0x5db3a000-0x5db3a033]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5db39000-0x5db399cb]
[  +0.000002] ACPI: Reserving SSDT table memory at [mem 0x5db35000-0x5db389d9]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5db31000-0x5db349d9]
[  +0.000001] ACPI: Reserving SSDT table memory at [mem 0x5db30000-0x5db30143]
[  +0.000001] ACPI: Reserving UEFI table memory at [mem 0x5d8a6000-0x5d8a6639]
[  +0.000002] ACPI: Reserving UEFI table memory at [mem 0x5d8a5000-0x5d8a505b]
[  +0.000001] ACPI: Reserving PHAT table memory at [mem 0x5db2f000-0x5db2f5ac]
[  +0.000001] ACPI: Reserving BGRT table memory at [mem 0x5db2e000-0x5db2e037]
[  +0.000074] No NUMA configuration found
[  +0.000001] Faking a node at [mem 0x0000000000000000-0x000000088f7fffff]
[  +0.000007] NODE_DATA(0) allocated [mem 0x88f7fb000-0x88f7fffff]
[  +0.000073] Zone ranges:
[  +0.000002]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[  +0.000003]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
[  +0.000002]   Normal   [mem 0x0000000100000000-0x000000088f7fffff]
[  +0.000003]   Device   empty
[  +0.000001] Movable zone start for each node
[  +0.000001] Early memory node ranges
[  +0.000001]   node   0: [mem 0x0000000000001000-0x000000000009efff]
[  +0.000002]   node   0: [mem 0x0000000000100000-0x00000000580b5fff]
[  +0.000002]   node   0: [mem 0x000000005dbff000-0x000000005dbfffff]
[  +0.000002]   node   0: [mem 0x0000000100000000-0x000000088f7fffff]
[  +0.000005] Initmem setup node 0 [mem 0x0000000000001000-0x000000088f7fffff]
[  +0.000009] On node 0, zone DMA: 1 pages in unavailable ranges
[  +0.000043] On node 0, zone DMA: 97 pages in unavailable ranges
[  +0.003656] On node 0, zone DMA32: 23369 pages in unavailable ranges
[  +0.066414] On node 0, zone Normal: 9216 pages in unavailable ranges
[  +0.000023] On node 0, zone Normal: 2048 pages in unavailable ranges
[  +0.000063] Reserving Intel graphics memory at [mem 0x6c800000-0x707fffff]
[  +0.001597] ACPI: PM-Timer IO Port: 0x1808
[  +0.000014] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[  +0.000003] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x04] high edge lint[0x1])
[  +0.000002] ACPI: LAPIC_NMI (acpi_id[0x05] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x06] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x07] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x08] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x09] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x0a] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x0b] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x0c] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x0d] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x0e] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x0f] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x10] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x11] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x12] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x13] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x14] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x15] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x16] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x17] high edge lint[0x1])
[  +0.000001] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
[  +0.000143] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-119
[  +0.000006] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[  +0.000003] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[  +0.000007] ACPI: Using ACPI (MADT) for SMP configuration information
[  +0.000002] ACPI: HPET id: 0x8086a201 base: 0xfed00000
[  +0.000015] e820: update [mem 0x52820000-0x52924fff] usable ==> reserved
[  +0.000014] TSC deadline timer available
[  +0.000004] CPU topo: Max. logical packages:   1
[  +0.000002] CPU topo: Max. logical dies:       1
[  +0.000001] CPU topo: Max. dies per package:   1
[  +0.000004] CPU topo: Max. threads per core:   2
[  +0.000001] CPU topo: Num. cores per package:    12
[  +0.000001] CPU topo: Num. threads per package:  16
[  +0.000001] CPU topo: Allowing 16 present CPUs plus 0 hotplug CPUs
[  +0.000022] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff]
[  +0.000003] PM: hibernation: Registered nosave memory: [mem 0x0009f000-0x000fffff]
[  +0.000003] PM: hibernation: Registered nosave memory: [mem 0x52820000-0x52924fff]
[  +0.000002] PM: hibernation: Registered nosave memory: [mem 0x580b6000-0x5d110fff]
[  +0.000001] PM: hibernation: Registered nosave memory: [mem 0x5d111000-0x5d971fff]
[  +0.000001] PM: hibernation: Registered nosave memory: [mem 0x5d972000-0x5dbfefff]
[  +0.000002] PM: hibernation: Registered nosave memory: [mem 0x5dc00000-0x663fffff]
[  +0.000001] PM: hibernation: Registered nosave memory: [mem 0x66400000-0x66dfffff]
[  +0.000001] PM: hibernation: Registered nosave memory: [mem 0x66e00000-0x707fffff]
[  +0.000001] PM: hibernation: Registered nosave memory: [mem 0x70800000-0xfed1ffff]
[  +0.000001] PM: hibernation: Registered nosave memory: [mem 0xfed20000-0xfed7ffff]
[  +0.000001] PM: hibernation: Registered nosave memory: [mem 0xfed80000-0xffffffff]
[  +0.000003] [mem 0x70800000-0xfed1ffff] available for PCI devices
[  +0.000002] Booting paravirtualized kernel on bare hardware
[  +0.000003] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
[  +0.009090] setup_percpu: NR_CPUS:320 nr_cpumask_bits:16 nr_cpu_ids:16 nr_node_ids:1
[  +0.001346] percpu: Embedded 66 pages/cpu s233472 r8192 d28672 u524288
[  +0.000009] pcpu-alloc: s233472 r8192 d28672 u524288 alloc=1*2097152
[  +0.000004] pcpu-alloc: [0] 00 01 02 03 [0] 04 05 06 07 
[  +0.000007] pcpu-alloc: [0] 08 09 10 11 [0] 12 13 14 15 
[  +0.000029] Kernel command line: initrd=\initrd-linux-custom.img root="UUID=aa97c5c2-c3cf-4b82-8773-5970f490a90b" rw audit=0 quiet splash
[  +0.000055] audit: disabled (until reboot)
[  +0.000035] Unknown kernel command line parameters "splash", will be passed to user space.
[  +0.003073] Dentry cache hash table entries: 4194304 (order: 13, 33554432 bytes, linear)
[  +0.001475] Inode-cache hash table entries: 2097152 (order: 12, 16777216 bytes, linear)
[  +0.000247] Fallback order for Node 0: 0 
[  +0.000005] Built 1 zonelists, mobility grouping on.  Total pages: 8288341
[  +0.000002] Policy zone: Normal
[  +0.000217] mem auto-init: stack:all(zero), heap alloc:on, heap free:off, mlocked free:off
[  +0.000013] software IO TLB: area num 16.
[  +0.070277] Memory: 32319252K/33153364K available (18432K kernel code, 2208K rwdata, 13404K rodata, 3436K init, 3508K bss, 833852K reserved, 0K cma-reserved)
[  +0.000283] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=16, Nodes=1
[  +0.000052] ftrace: allocating 50384 entries in 197 pages
[  +0.008436] ftrace: allocated 197 pages with 4 groups
[  +0.000079] Dynamic Preempt: full
[  +0.000077] rcu: Preemptible hierarchical RCU implementation.
[  +0.000001] rcu: 	RCU restricting CPUs from NR_CPUS=320 to nr_cpu_ids=16.
[  +0.000002] rcu: 	RCU priority boosting: priority 1 delay 500 ms.
[  +0.000001] 	Trampoline variant of Tasks RCU enabled.
[  +0.000001] 	Rude variant of Tasks RCU enabled.
[  +0.000000] 	Tracing variant of Tasks RCU enabled.
[  +0.000001] rcu: RCU calculated value of scheduler-enlistment delay is 100 jiffies.
[  +0.000001] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=16
[  +0.000013] RCU Tasks: Setting shift to 4 and lim to 1 rcu_task_cb_adjust=1.
[  +0.000002] RCU Tasks Rude: Setting shift to 4 and lim to 1 rcu_task_cb_adjust=1.
[  +0.000002] RCU Tasks Trace: Setting shift to 4 and lim to 1 rcu_task_cb_adjust=1.
[  +0.005209] NR_IRQS: 20736, nr_irqs: 2184, preallocated irqs: 16
[  +0.000476] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[  +0.000655] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[  +0.000044] Console: colour dummy device 80x25
[  +0.000003] printk: legacy console [tty0] enabled
[  +0.000061] ACPI: Core revision 20240322
[  +0.000495] hpet: HPET dysfunctional in PC10. Force disabled.
[  +0.000001] APIC: Switch to symmetric I/O mode setup
[  +0.000002] DMAR: Host address width 39
[  +0.000002] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[  +0.000006] DMAR: dmar0: reg_base_addr fed90000 ver 4:0 cap 1c0000c40660462 ecap 29a00f0505e
[  +0.000003] DMAR: DRHD base: 0x000000fed92000 flags: 0x0
[  +0.000004] DMAR: dmar1: reg_base_addr fed92000 ver 1:0 cap d2008c40660462 ecap f050da
[  +0.000002] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[  +0.000006] DMAR: dmar2: reg_base_addr fed91000 ver 5:0 cap d2008c40660462 ecap f050da
[  +0.000002] DMAR: RMRR base: 0x0000006c000000 end: 0x000000707fffff
[  +0.000003] DMAR-IR: IOAPIC id 2 under DRHD base  0xfed91000 IOMMU 2
[  +0.000002] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[  +0.000001] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[  +0.005477] DMAR-IR: Enabled IRQ remapping in x2apic mode
[  +0.000003] x2apic enabled
[  +0.000119] APIC: Switched APIC routing to: cluster x2apic
[  +0.014471] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x25a39079a08, max_idle_ns: 440795310461 ns
[  +0.000009] Calibrating delay loop (skipped), value calculated using timer frequency.. 5222.40 BogoMIPS (lpj=2611200)
[  +0.000072] CPU0: Thermal monitoring enabled (TM1)
[  +0.000003] x86/cpu: User Mode Instruction Prevention (UMIP) activated
[  +0.000159] CET detected: Indirect Branch Tracking enabled
[  +0.000003] Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0
[  +0.000001] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[  +0.000004] process: using mwait in idle threads
[  +0.000003] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[  +0.000004] Spectre V2 : Mitigation: Enhanced / Automatic IBRS
[  +0.000001] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[  +0.000001] Spectre V2 : Spectre v2 / PBRSB-eIBRS: Retire a single CALL on VMEXIT
[  +0.000002] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
[  +0.000002] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
[  +0.000002] Register File Data Sampling: Mitigation: Clear Register File
[  +0.000014] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[  +0.000001] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[  +0.000001] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[  +0.000001] x86/fpu: Supporting XSAVE feature 0x200: 'Protection Keys User registers'
[  +0.000001] x86/fpu: Supporting XSAVE feature 0x800: 'Control-flow User registers'
[  +0.000002] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[  +0.000001] x86/fpu: xstate_offset[9]:  832, xstate_sizes[9]:    8
[  +0.000001] x86/fpu: xstate_offset[11]:  840, xstate_sizes[11]:   16
[  +0.000002] x86/fpu: Enabled xstate features 0xa07, context size is 856 bytes, using 'compacted' format.
[  +0.000716] Freeing SMP alternatives memory: 40K
[  +0.000000] pid_max: default: 32768 minimum: 301
[  +0.000000] LSM: initializing lsm=capability,landlock,lockdown,yama,bpf
[  +0.000000] landlock: Up and running.
[  +0.000000] Yama: becoming mindful.
[  +0.000000] LSM support for eBPF active
[  +0.000000] Mount-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
[  +0.000000] Mountpoint-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
[  +0.000000] smpboot: CPU0: 13th Gen Intel(R) Core(TM) i7-1360P (family: 0x6, model: 0xba, stepping: 0x2)
[  +0.000000] Performance Events: XSAVE Architectural LBR, PEBS fmt4+-baseline,  AnyThread deprecated, Alderlake Hybrid events, 32-deep LBR, full-width counters, Intel PMU driver.
[  +0.000000] core: cpu_core PMU driver: 
[  +0.000000] ... version:                5
[  +0.000000] ... bit width:              48
[  +0.000000] ... generic registers:      8
[  +0.000000] ... value mask:             0000ffffffffffff
[  +0.000000] ... max period:             00007fffffffffff
[  +0.000000] ... fixed-purpose events:   4
[  +0.000000] ... event mask:             0001000f000000ff
[  +0.000000] signal: max sigframe size: 3632
[  +0.000000] Estimated ratio of average max frequency by base frequency (times 1024): 1772
[  +0.000000] rcu: Hierarchical SRCU implementation.
[  +0.000000] rcu: 	Max phase no-delay instances is 400.
[  +0.000431] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
[  +0.000145] smp: Bringing up secondary CPUs ...
[  +0.000087] smpboot: x86: Booting SMP configuration:
[  +0.000001] .... node  #0, CPUs:        #2  #4  #6  #8  #9 #10 #11 #12 #13 #14 #15
[  -0.187751] core: cpu_atom PMU driver: PEBS-via-PT 
[  +0.000000] ... version:                5
[  +0.000000] ... bit width:              48
[  +0.000000] ... generic registers:      6
[  +0.000000] ... value mask:             0000ffffffffffff
[  +0.000000] ... max period:             00007fffffffffff
[  +0.000000] ... fixed-purpose events:   3
[  +0.000000] ... event mask:             000000070000003f
[  +0.193185]   #1  #3  #5  #7
[  +0.003951] smp: Brought up 1 node, 16 CPUs
[  +0.000000] smpboot: Total of 16 processors activated (83558.40 BogoMIPS)
[  +0.002053] devtmpfs: initialized
[  +0.000000] x86/mm: Memory block size: 128MB
[  +0.002036] ACPI: PM: Registering ACPI NVS region [mem 0x5d111000-0x5d971fff] (8785920 bytes)
[  +0.000000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[  +0.000006] futex hash table entries: 4096 (order: 6, 262144 bytes, linear)
[  +0.000083] pinctrl core: initialized pinctrl subsystem
[  +0.000577] PM: RTC time: 11:45:37, date: 2024-05-27
[  +0.000689] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[  +0.000431] DMA: preallocated 4096 KiB GFP_KERNEL pool for atomic allocations
[  +0.000363] DMA: preallocated 4096 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[  +0.000370] DMA: preallocated 4096 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[  +0.000093] thermal_sys: Registered thermal governor 'fair_share'
[  +0.000001] thermal_sys: Registered thermal governor 'bang_bang'
[  +0.000002] thermal_sys: Registered thermal governor 'step_wise'
[  +0.000000] thermal_sys: Registered thermal governor 'user_space'
[  +0.000001] thermal_sys: Registered thermal governor 'power_allocator'
[  +0.000012] cpuidle: using governor ladder
[  +0.000003] cpuidle: using governor menu
[  +0.000233] Simple Boot Flag at 0x47 set to 0x80
[  +0.000071] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
[  +0.000001] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[  +0.000150] PCI: ECAM [mem 0xc0000000-0xce0fffff] (base 0xc0000000) for domain 0000 [bus 00-e0]
[  +0.000015] PCI: Using configuration type 1 for base access
[  +0.000124] kprobes: kprobe jump-optimization is enabled. All kprobes are optimized if possible.
[  +0.001703] HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages
[  +0.000000] HugeTLB: 16380 KiB vmemmap can be freed for a 1.00 GiB page
[  +0.000000] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
[  +0.000000] HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page
[  +0.000222] Demotion targets for Node 0: null
[  +0.000000] ACPI: Added _OSI(Module Device)
[  +0.000000] ACPI: Added _OSI(Processor Device)
[  +0.000000] ACPI: Added _OSI(3.0 _SCP Extensions)
[  +0.000000] ACPI: Added _OSI(Processor Aggregator Device)
[  +0.135896] ACPI BIOS Error (bug): Failure creating named object [\_SB.PC00.TXHC.RHUB.SS01._DSM], AE_ALREADY_EXISTS (20240322/dswload2-326)
[  +0.000009] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20240322/psobject-220)
[  +0.000003] ACPI: Skipping parse of AML opcode: Method (0x0014)
[  +0.000015] ACPI BIOS Error (bug): Failure creating named object [\_SB.PC00.TXHC.RHUB.SS03._DSM], AE_ALREADY_EXISTS (20240322/dswload2-326)
[  +0.000004] ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20240322/psobject-220)
[  +0.000002] ACPI: Skipping parse of AML opcode: Method (0x0014)
[  +0.003076] ACPI: 17 ACPI AML tables successfully acquired and loaded
[  +0.027689] ACPI: USB4 _OSC: OS supports USB3+ DisplayPort+ PCIe+ XDomain+
[  +0.000003] ACPI: USB4 _OSC: OS controls USB3+ DisplayPort+ PCIe+ XDomain+
[  +0.002854] ACPI: Dynamic OEM Table Load:
[  +0.000013] ACPI: SSDT 0xFFFF965D01796800 000394 (v02 PmRef  Cpu0Cst  00003001 INTL 20200717)
[  +0.001792] ACPI: Dynamic OEM Table Load:
[  +0.000009] ACPI: SSDT 0xFFFF965D022E3000 000605 (v02 PmRef  Cpu0Ist  00003000 INTL 20200717)
[  +0.001820] ACPI: Dynamic OEM Table Load:
[  +0.000007] ACPI: SSDT 0xFFFF965D02262C00 0001AB (v02 PmRef  Cpu0Psd  00003000 INTL 20200717)
[  +0.001671] ACPI: Dynamic OEM Table Load:
[  +0.000008] ACPI: SSDT 0xFFFF965D022E2800 0004B5 (v02 PmRef  Cpu0Hwp  00003000 INTL 20200717)
[  +0.002330] ACPI: Dynamic OEM Table Load:
[  +0.000013] ACPI: SSDT 0xFFFF965D0178A000 001BAF (v02 PmRef  ApIst    00003000 INTL 20200717)
[  +0.002757] ACPI: Dynamic OEM Table Load:
[  +0.000009] ACPI: SSDT 0xFFFF965D0178E000 001038 (v02 PmRef  ApHwp    00003000 INTL 20200717)
[  +0.002477] ACPI: Dynamic OEM Table Load:
[  +0.000010] ACPI: SSDT 0xFFFF965D022E8000 001349 (v02 PmRef  ApPsd    00003000 INTL 20200717)
[  +0.002521] ACPI: Dynamic OEM Table Load:
[  +0.000010] ACPI: SSDT 0xFFFF965D01798000 000FBB (v02 PmRef  ApCst    00003000 INTL 20200717)
[  +0.010332] ACPI: _OSC evaluated successfully for all CPUs
[  +0.000203] ACPI: EC: EC started
[  +0.000001] ACPI: EC: interrupt blocked
[  +0.005269] ACPI: EC: EC_CMD/EC_SC=0x934, EC_DATA=0x930
[  +0.000004] ACPI: \_SB_.PC00.LPCB.ECDV: Boot DSDT EC used to handle transactions
[  +0.000002] ACPI: Interpreter enabled
[  +0.000081] ACPI: PM: (supports S0 S4 S5)
[  +0.000001] ACPI: Using IOAPIC for interrupt routing
[  +0.002161] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[  +0.000002] PCI: Ignoring E820 reservations for host bridge windows
[  +0.002869] ACPI: Enabled 8 GPEs in block 00 to 7F
[  +0.008751] ACPI: \_SB_.PC00.XHCI.RHUB.HS10.BTRT: New power resource
[  +0.011448] ACPI: \_SB_.PC00.CNVW.WRST: New power resource
[  +0.025299] ACPI: \_SB_.PC00.TBT0: New power resource
[  +0.000089] ACPI: \_SB_.PC00.TBT1: New power resource
[  +0.000081] ACPI: \_SB_.PC00.D3C_: New power resource
[  +0.247661] ACPI: \PIN_: New power resource
[  +0.000362] ACPI: PCI Root Bridge [PC00] (domain 0000 [bus 00-e0])
[  +0.000007] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
[  +0.002246] acpi PNP0A08:00: _OSC: platform does not support [AER]
[  +0.004311] acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug SHPCHotplug PME PCIeCapability LTR DPC]
[  +0.000001] acpi PNP0A08:00: FADT indicates ASPM is unsupported, using BIOS configuration
[  +0.005674] PCI host bridge to bus 0000:00
[  +0.000002] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
[  +0.000002] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
[  +0.000002] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
[  +0.000001] pci_bus 0000:00: root bus resource [mem 0x70800000-0xbfffffff window]
[  +0.000002] pci_bus 0000:00: root bus resource [mem 0x4000000000-0x7fffffffff window]
[  +0.000001] pci_bus 0000:00: root bus resource [bus 00-e0]
[  +0.000081] pci 0000:00:00.0: [8086:a707] type 00 class 0x060000 conventional PCI endpoint
[  +0.000286] pci 0000:00:02.0: [8086:a7a0] type 00 class 0x030000 PCIe Root Complex Integrated Endpoint
[  +0.000009] pci 0000:00:02.0: BAR 0 [mem 0x603f000000-0x603fffffff 64bit]
[  +0.000006] pci 0000:00:02.0: BAR 2 [mem 0x4000000000-0x400fffffff 64bit pref]
[  +0.000004] pci 0000:00:02.0: BAR 4 [io  0x3000-0x303f]
[  +0.000017] pci 0000:00:02.0: DMAR: Skip IOMMU disabling for graphics
[  +0.000003] pci 0000:00:02.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[  +0.000027] pci 0000:00:02.0: VF BAR 0 [mem 0x00000000-0x00ffffff 64bit]
[  +0.000002] pci 0000:00:02.0: VF BAR 0 [mem 0x00000000-0x06ffffff 64bit]: contains BAR 0 for 7 VFs
[  +0.000005] pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0x1fffffff 64bit pref]
[  +0.000001] pci 0000:00:02.0: VF BAR 2 [mem 0x00000000-0xdfffffff 64bit pref]: contains BAR 2 for 7 VFs
[  +0.000143] pci 0000:00:04.0: [8086:a71d] type 00 class 0x118000 conventional PCI endpoint
[  +0.000014] pci 0000:00:04.0: BAR 0 [mem 0x6040280000-0x604029ffff 64bit]
[  +0.000270] pci 0000:00:05.0: [8086:a75d] type 00 class 0x048000 PCIe Root Complex Integrated Endpoint
[  +0.000008] pci 0000:00:05.0: BAR 0 [mem 0x603e000000-0x603effffff 64bit]
[  +0.000013] pci 0000:00:05.0: enabling Extended Tags
[  +0.000126] pci 0000:00:06.0: [8086:09ab] type 00 class 0x088000 conventional PCI endpoint
[  +0.000735] pci 0000:00:07.0: [8086:a76e] type 01 class 0x060400 PCIe Root Port
[  +0.000018] pci 0000:00:07.0: PCI bridge to [bus 01-3f]
[  +0.000004] pci 0000:00:07.0:   bridge window [mem 0x82000000-0x8e1fffff]
[  +0.000007] pci 0000:00:07.0:   bridge window [mem 0x6000000000-0x601bffffff 64bit pref]
[  +0.000092] pci 0000:00:07.0: PME# supported from D0 D3hot D3cold
[  +0.000028] pci 0000:00:07.0: PTM enabled (root), 4ns granularity
[  +0.000951] pci 0000:00:07.2: [8086:a72f] type 01 class 0x060400 PCIe Root Port
[  +0.000018] pci 0000:00:07.2: PCI bridge to [bus 40-7e]
[  +0.000004] pci 0000:00:07.2:   bridge window [mem 0x74000000-0x801fffff]
[  +0.000006] pci 0000:00:07.2:   bridge window [mem 0x6020000000-0x603bffffff 64bit pref]
[  +0.000088] pci 0000:00:07.2: PME# supported from D0 D3hot D3cold
[  +0.000026] pci 0000:00:07.2: PTM enabled (root), 4ns granularity
[  +0.001005] pci 0000:00:08.0: [8086:a74f] type 00 class 0x088000 conventional PCI endpoint
[  +0.000008] pci 0000:00:08.0: BAR 0 [mem 0x60402f5000-0x60402f5fff 64bit]
[  +0.000115] pci 0000:00:0a.0: [8086:a77d] type 00 class 0x118000 PCIe Root Complex Integrated Endpoint
[  +0.000007] pci 0000:00:0a.0: BAR 0 [mem 0x60402d0000-0x60402d7fff 64bit]
[  +0.000018] pci 0000:00:0a.0: enabling Extended Tags
[  +0.000114] pci 0000:00:0d.0: [8086:a71e] type 00 class 0x0c0330 conventional PCI endpoint
[  +0.000010] pci 0000:00:0d.0: BAR 0 [mem 0x60402c0000-0x60402cffff 64bit]
[  +0.000041] pci 0000:00:0d.0: PME# supported from D3hot D3cold
[  +0.000503] pci 0000:00:0d.2: [8086:a73e] type 00 class 0x0c0340 conventional PCI endpoint
[  +0.000013] pci 0000:00:0d.2: BAR 0 [mem 0x6040240000-0x604027ffff 64bit]
[  +0.000006] pci 0000:00:0d.2: BAR 2 [mem 0x60402f4000-0x60402f4fff 64bit]
[  +0.000036] pci 0000:00:0d.2: supports D1 D2
[  +0.000001] pci 0000:00:0d.2: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000132] pci 0000:00:0d.3: [8086:a76d] type 00 class 0x0c0340 conventional PCI endpoint
[  +0.000010] pci 0000:00:0d.3: BAR 0 [mem 0x6040200000-0x604023ffff 64bit]
[  +0.000007] pci 0000:00:0d.3: BAR 2 [mem 0x60402f3000-0x60402f3fff 64bit]
[  +0.000031] pci 0000:00:0d.3: supports D1 D2
[  +0.000001] pci 0000:00:0d.3: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000250] pci 0000:00:0e.0: [8086:a77f] type 00 class 0x010400 PCIe Root Complex Integrated Endpoint
[  +0.000013] pci 0000:00:0e.0: BAR 0 [mem 0x603c000000-0x603dffffff 64bit]
[  +0.000007] pci 0000:00:0e.0: BAR 2 [mem 0x72000000-0x73ffffff]
[  +0.000016] pci 0000:00:0e.0: BAR 4 [mem 0x6040100000-0x60401fffff 64bit]
[  +0.000419] pci 0000:00:12.0: [8086:51fc] type 00 class 0x070000 conventional PCI endpoint
[  +0.000024] pci 0000:00:12.0: BAR 0 [mem 0x60402b0000-0x60402bffff 64bit]
[  +0.000094] pci 0000:00:12.0: PME# supported from D0 D3hot
[  +0.000655] pci 0000:00:14.0: [8086:51ed] type 00 class 0x0c0330 conventional PCI endpoint
[  +0.000024] pci 0000:00:14.0: BAR 0 [mem 0x60402a0000-0x60402affff 64bit]
[  +0.000109] pci 0000:00:14.0: PME# supported from D3hot D3cold
[  +0.000552] pci 0000:00:14.2: [8086:51ef] type 00 class 0x050000 conventional PCI endpoint
[  +0.000023] pci 0000:00:14.2: BAR 0 [mem 0x60402e8000-0x60402ebfff 64bit]
[  +0.000013] pci 0000:00:14.2: BAR 2 [mem 0x60402f2000-0x60402f2fff 64bit]
[  +0.000705] pci 0000:00:14.3: [8086:51f1] type 00 class 0x028000 PCIe Root Complex Integrated Endpoint
[  +0.000802] pci 0000:00:14.3: BAR 0 [mem 0x60402e4000-0x60402e7fff 64bit]
[  +0.002249] pci 0000:00:14.3: PME# supported from D0 D3hot D3cold
[  +0.002345] pci 0000:00:15.0: [8086:51e8] type 00 class 0x0c8000 conventional PCI endpoint
[  +0.000764] pci 0000:00:15.0: BAR 0 [mem 0x00000000-0x00000fff 64bit]
[  +0.004024] pci 0000:00:15.1: [8086:51e9] type 00 class 0x0c8000 conventional PCI endpoint
[  +0.000765] pci 0000:00:15.1: BAR 0 [mem 0x00000000-0x00000fff 64bit]
[  +0.003554] pci 0000:00:16.0: [8086:51e0] type 00 class 0x078000 conventional PCI endpoint
[  +0.000026] pci 0000:00:16.0: BAR 0 [mem 0x60402ef000-0x60402effff 64bit]
[  +0.000101] pci 0000:00:16.0: PME# supported from D3hot
[  +0.001319] pci 0000:00:1e.0: [8086:51a8] type 00 class 0x078000 conventional PCI endpoint
[  +0.000796] pci 0000:00:1e.0: BAR 0 [mem 0x00000000-0x00000fff 64bit]
[  +0.004094] pci 0000:00:1e.3: [8086:51ab] type 00 class 0x0c8000 conventional PCI endpoint
[  +0.000796] pci 0000:00:1e.3: BAR 0 [mem 0x00000000-0x00000fff 64bit]
[  +0.003509] pci 0000:00:1f.0: [8086:519d] type 00 class 0x060100 conventional PCI endpoint
[  +0.000446] pci 0000:00:1f.3: [8086:51ca] type 00 class 0x040100 conventional PCI endpoint
[  +0.000056] pci 0000:00:1f.3: BAR 0 [mem 0x60402e0000-0x60402e3fff 64bit]
[  +0.000070] pci 0000:00:1f.3: BAR 4 [mem 0x6040000000-0x60400fffff 64bit]
[  +0.000167] pci 0000:00:1f.3: PME# supported from D3hot D3cold
[  +0.000152] pci 0000:00:1f.4: [8086:51a3] type 00 class 0x0c0500 conventional PCI endpoint
[  +0.000029] pci 0000:00:1f.4: BAR 0 [mem 0x60402ec000-0x60402ec0ff 64bit]
[  +0.000036] pci 0000:00:1f.4: BAR 4 [io  0xefa0-0xefbf]
[  +0.000323] pci 0000:00:1f.5: [8086:51a4] type 00 class 0x0c8000 conventional PCI endpoint
[  +0.000022] pci 0000:00:1f.5: BAR 0 [mem 0xfe010000-0xfe010fff]
[  +0.000220] pci 0000:01:00.0: [8086:0b26] type 01 class 0x060400 PCIe Switch Upstream Port
[  +0.000046] pci 0000:01:00.0: PCI bridge to [bus 02-3f]
[  +0.000013] pci 0000:01:00.0:   bridge window [mem 0x82000000-0x8dffffff]
[  +0.000015] pci 0000:01:00.0:   bridge window [mem 0x6000000000-0x601befffff 64bit pref]
[  +0.000018] pci 0000:01:00.0: enabling Extended Tags
[  +0.000153] pci 0000:01:00.0: supports D1 D2
[  +0.000001] pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000137] pci 0000:01:00.0: PTM enabled, 4ns granularity
[  +0.000042] pci 0000:01:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:07.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[  +0.002849] pci 0000:00:07.0: PCI bridge to [bus 01-3f]
[  +0.000092] pci 0000:02:00.0: [8086:0b26] type 01 class 0x060400 PCIe Switch Downstream Port
[  +0.000046] pci 0000:02:00.0: PCI bridge to [bus 03]
[  +0.000046] pci 0000:02:00.0: enabling Extended Tags
[  +0.000163] pci 0000:02:00.0: supports D1 D2
[  +0.000001] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000308] pci 0000:02:01.0: [8086:0b26] type 01 class 0x060400 PCIe Switch Downstream Port
[  +0.000049] pci 0000:02:01.0: PCI bridge to [bus 04-16]
[  +0.000013] pci 0000:02:01.0:   bridge window [mem 0x8a000000-0x8dffffff]
[  +0.000015] pci 0000:02:01.0:   bridge window [mem 0x6012a00000-0x601befffff 64bit pref]
[  +0.000021] pci 0000:02:01.0: enabling Extended Tags
[  +0.000163] pci 0000:02:01.0: supports D1 D2
[  +0.000001] pci 0000:02:01.0: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000305] pci 0000:02:02.0: [8086:0b26] type 01 class 0x060400 PCIe Switch Downstream Port
[  +0.000047] pci 0000:02:02.0: PCI bridge to [bus 17-29]
[  +0.000013] pci 0000:02:02.0:   bridge window [mem 0x86000000-0x89ffffff]
[  +0.000015] pci 0000:02:02.0:   bridge window [mem 0x6009500000-0x60129fffff 64bit pref]
[  +0.000020] pci 0000:02:02.0: enabling Extended Tags
[  +0.000166] pci 0000:02:02.0: supports D1 D2
[  +0.000000] pci 0000:02:02.0: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000305] pci 0000:02:03.0: [8086:0b26] type 01 class 0x060400 PCIe Switch Downstream Port
[  +0.000046] pci 0000:02:03.0: PCI bridge to [bus 2a-3e]
[  +0.000012] pci 0000:02:03.0:   bridge window [mem 0x82000000-0x85ffffff]
[  +0.000016] pci 0000:02:03.0:   bridge window [mem 0x6000000000-0x60094fffff 64bit pref]
[  +0.000020] pci 0000:02:03.0: enabling Extended Tags
[  +0.000163] pci 0000:02:03.0: supports D1 D2
[  +0.000001] pci 0000:02:03.0: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000311] pci 0000:02:04.0: [8086:0b26] type 01 class 0x060400 PCIe Switch Downstream Port
[  +0.000046] pci 0000:02:04.0: PCI bridge to [bus 3f]
[  +0.000046] pci 0000:02:04.0: enabling Extended Tags
[  +0.000161] pci 0000:02:04.0: supports D1 D2
[  +0.000001] pci 0000:02:04.0: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000311] pci 0000:01:00.0: PCI bridge to [bus 02-3f]
[  +0.000067] pci 0000:02:00.0: PCI bridge to [bus 03]
[  +0.000070] pci 0000:02:01.0: PCI bridge to [bus 04-16]
[  +0.000069] pci 0000:02:02.0: PCI bridge to [bus 17-29]
[  +0.000072] pci 0000:02:03.0: PCI bridge to [bus 2a-3e]
[  +0.000069] pci 0000:02:04.0: PCI bridge to [bus 3f]
[  +0.000103] pci 0000:00:07.2: PCI bridge to [bus 40-7e]
[  +0.004475] ACPI: \_SB_.PEPD: Duplicate LPS0 _DSM functions (mask: 0x7f)
[  +0.385036] Low-power S0 idle used by default for system suspend
[  +0.009220] ACPI: EC: interrupt unblocked
[  +0.000002] ACPI: EC: event unblocked
[  +0.000026] ACPI: EC: EC_CMD/EC_SC=0x934, EC_DATA=0x930
[  +0.000001] ACPI: EC: GPE=0x6e
[  +0.000001] ACPI: \_SB_.PC00.LPCB.ECDV: Boot DSDT EC initialization complete
[  +0.000002] ACPI: \_SB_.PC00.LPCB.ECDV: EC: Used to handle transactions and events
[  +0.000836] iommu: Default domain type: Translated
[  +0.000000] iommu: DMA domain TLB invalidation policy: lazy mode
[  +0.000139] SCSI subsystem initialized
[  +0.000006] libata version 3.00 loaded.
[  +0.000000] ACPI: bus type USB registered
[  +0.000000] usbcore: registered new interface driver usbfs
[  +0.000000] usbcore: registered new interface driver hub
[  +0.000000] usbcore: registered new device driver usb
[  +0.000000] pps_core: LinuxPPS API ver. 1 registered
[  +0.000000] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[  +0.000000] PTP clock support registered
[  +0.000000] EDAC MC: Ver: 3.0.0
[  +0.000908] efivars: Registered efivars operations
[  +0.000165] NetLabel: Initializing
[  +0.000001] NetLabel:  domain hash size = 128
[  +0.000001] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
[  +0.000018] NetLabel:  unlabeled traffic allowed by default
[  +0.000004] mctp: management component transport protocol core
[  +0.000001] NET: Registered PF_MCTP protocol family
[  +0.000004] PCI: Using ACPI for IRQ routing
[  +0.056527] PCI: pci_cache_line_size set to 64 bytes
[  +0.000339] pci 0000:00:1f.5: BAR 0 [mem 0xfe010000-0xfe010fff]: can't claim; no compatible bridge window
[  +0.000304] e820: reserve RAM buffer [mem 0x0009f000-0x0009ffff]
[  +0.000003] e820: reserve RAM buffer [mem 0x52820000-0x53ffffff]
[  +0.000001] e820: reserve RAM buffer [mem 0x580b6000-0x5bffffff]
[  +0.000001] e820: reserve RAM buffer [mem 0x5dc00000-0x5fffffff]
[  +0.000000] e820: reserve RAM buffer [mem 0x88f800000-0x88fffffff]
[  +0.000028] pci 0000:00:02.0: vgaarb: setting as boot VGA device
[  +0.000000] pci 0000:00:02.0: vgaarb: bridge control possible
[  +0.000000] pci 0000:00:02.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[  +0.000000] vgaarb: loaded
[  +0.000000] clocksource: Switched to clocksource tsc-early
[  +0.000000] VFS: Disk quotas dquot_6.6.0
[  +0.000000] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[  +0.000000] pnp: PnP ACPI init
[  +0.000025] system 00:00: [io  0x0680-0x069f] has been reserved
[  +0.000003] system 00:00: [io  0x164e-0x164f] has been reserved
[  +0.000123] system 00:02: [io  0x1854-0x1857] has been reserved
[  +0.001159] pnp 00:05: disabling [mem 0xc0000000-0xcfffffff] because it overlaps 0000:00:02.0 BAR 9 [mem 0x00000000-0xdfffffff 64bit pref]
[  +0.000024] system 00:05: [mem 0xfedc0000-0xfedc7fff] has been reserved
[  +0.000002] system 00:05: [mem 0xfeda0000-0xfeda0fff] has been reserved
[  +0.000002] system 00:05: [mem 0xfeda1000-0xfeda1fff] has been reserved
[  +0.000001] system 00:05: [mem 0xfed20000-0xfed7ffff] could not be reserved
[  +0.000001] system 00:05: [mem 0xfed90000-0xfed93fff] could not be reserved
[  +0.000002] system 00:05: [mem 0xfed45000-0xfed8ffff] could not be reserved
[  +0.000001] system 00:05: [mem 0xfee00000-0xfeefffff] has been reserved
[  +0.001197] system 00:06: [io  0x2000-0x20fe] has been reserved
[  +0.004543] pnp: PnP ACPI: found 8 devices
[  +0.005463] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[  +0.000065] NET: Registered PF_INET protocol family
[  +0.000316] IP idents hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[  +0.013442] tcp_listen_portaddr_hash hash table entries: 16384 (order: 6, 262144 bytes, linear)
[  +0.000060] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[  +0.000293] TCP established hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[  +0.000381] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes, linear)
[  +0.000114] TCP: Hash tables configured (established 262144 bind 65536)
[  +0.000115] MPTCP token hash table entries: 32768 (order: 7, 786432 bytes, linear)
[  +0.000080] UDP hash table entries: 16384 (order: 7, 524288 bytes, linear)
[  +0.000097] UDP-Lite hash table entries: 16384 (order: 7, 524288 bytes, linear)
[  +0.000077] NET: Registered PF_UNIX/PF_LOCAL protocol family
[  +0.000006] NET: Registered PF_XDP protocol family
[  +0.000006] pci 0000:02:01.0: bridge window [io  0x1000-0x0fff] to [bus 04-16] add_size 1000
[  +0.000004] pci 0000:02:02.0: bridge window [io  0x1000-0x0fff] to [bus 17-29] add_size 1000
[  +0.000002] pci 0000:02:03.0: bridge window [io  0x1000-0x0fff] to [bus 2a-3e] add_size 1000
[  +0.000002] pci 0000:01:00.0: bridge window [io  0x1000-0x0fff] to [bus 02-3f] add_size 3000
[  +0.000002] pci 0000:00:07.0: bridge window [io  0x1000-0x0fff] to [bus 01-3f] add_size 4000
[  +0.000002] pci 0000:00:07.2: bridge window [io  0x1000-0x0fff] to [bus 40-7e] add_size 1000
[  +0.000009] pci 0000:00:02.0: VF BAR 2 [mem 0x4020000000-0x40ffffffff 64bit pref]: assigned
[  +0.000005] pci 0000:00:02.0: VF BAR 0 [mem 0x4010000000-0x4016ffffff 64bit]: assigned
[  +0.000002] pci 0000:00:07.0: bridge window [io  0x4000-0x7fff]: assigned
[  +0.000002] pci 0000:00:07.2: bridge window [io  0x8000-0x8fff]: assigned
[  +0.000002] pci 0000:00:15.0: BAR 0 [mem 0x4017000000-0x4017000fff 64bit]: assigned
[  +0.000389] pci 0000:00:15.1: BAR 0 [mem 0x4017001000-0x4017001fff 64bit]: assigned
[  +0.000373] pci 0000:00:1e.0: BAR 0 [mem 0x4017002000-0x4017002fff 64bit]: assigned
[  +0.000394] pci 0000:00:1e.3: BAR 0 [mem 0x4017003000-0x4017003fff 64bit]: assigned
[  +0.000374] pci 0000:00:1f.5: BAR 0 [mem 0x70800000-0x70800fff]: assigned
[  +0.000017] pci 0000:01:00.0: bridge window [io  0x4000-0x6fff]: assigned
[  +0.000003] pci 0000:02:01.0: bridge window [io  0x4000-0x4fff]: assigned
[  +0.000001] pci 0000:02:02.0: bridge window [io  0x5000-0x5fff]: assigned
[  +0.000001] pci 0000:02:03.0: bridge window [io  0x6000-0x6fff]: assigned
[  +0.000001] pci 0000:02:00.0: PCI bridge to [bus 03]
[  +0.000022] pci 0000:02:01.0: PCI bridge to [bus 04-16]
[  +0.000003] pci 0000:02:01.0:   bridge window [io  0x4000-0x4fff]
[  +0.000006] pci 0000:02:01.0:   bridge window [mem 0x8a000000-0x8dffffff]
[  +0.000005] pci 0000:02:01.0:   bridge window [mem 0x6012a00000-0x601befffff 64bit pref]
[  +0.000007] pci 0000:02:02.0: PCI bridge to [bus 17-29]
[  +0.000003] pci 0000:02:02.0:   bridge window [io  0x5000-0x5fff]
[  +0.000006] pci 0000:02:02.0:   bridge window [mem 0x86000000-0x89ffffff]
[  +0.000004] pci 0000:02:02.0:   bridge window [mem 0x6009500000-0x60129fffff 64bit pref]
[  +0.000007] pci 0000:02:03.0: PCI bridge to [bus 2a-3e]
[  +0.000003] pci 0000:02:03.0:   bridge window [io  0x6000-0x6fff]
[  +0.000006] pci 0000:02:03.0:   bridge window [mem 0x82000000-0x85ffffff]
[  +0.000004] pci 0000:02:03.0:   bridge window [mem 0x6000000000-0x60094fffff 64bit pref]
[  +0.000008] pci 0000:02:04.0: PCI bridge to [bus 3f]
[  +0.000015] pci 0000:01:00.0: PCI bridge to [bus 02-3f]
[  +0.000003] pci 0000:01:00.0:   bridge window [io  0x4000-0x6fff]
[  +0.000005] pci 0000:01:00.0:   bridge window [mem 0x82000000-0x8dffffff]
[  +0.000005] pci 0000:01:00.0:   bridge window [mem 0x6000000000-0x601befffff 64bit pref]
[  +0.000007] pci 0000:00:07.0: PCI bridge to [bus 01-3f]
[  +0.000001] pci 0000:00:07.0:   bridge window [io  0x4000-0x7fff]
[  +0.000003] pci 0000:00:07.0:   bridge window [mem 0x82000000-0x8e1fffff]
[  +0.000002] pci 0000:00:07.0:   bridge window [mem 0x6000000000-0x601bffffff 64bit pref]
[  +0.000003] pci 0000:00:07.2: PCI bridge to [bus 40-7e]
[  +0.000002] pci 0000:00:07.2:   bridge window [io  0x8000-0x8fff]
[  +0.000002] pci 0000:00:07.2:   bridge window [mem 0x74000000-0x801fffff]
[  +0.000002] pci 0000:00:07.2:   bridge window [mem 0x6020000000-0x603bffffff 64bit pref]
[  +0.000005] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
[  +0.000002] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
[  +0.000001] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
[  +0.000001] pci_bus 0000:00: resource 7 [mem 0x70800000-0xbfffffff window]
[  +0.000001] pci_bus 0000:00: resource 8 [mem 0x4000000000-0x7fffffffff window]
[  +0.000002] pci_bus 0000:01: resource 0 [io  0x4000-0x7fff]
[  +0.000001] pci_bus 0000:01: resource 1 [mem 0x82000000-0x8e1fffff]
[  +0.000001] pci_bus 0000:01: resource 2 [mem 0x6000000000-0x601bffffff 64bit pref]
[  +0.000001] pci_bus 0000:02: resource 0 [io  0x4000-0x6fff]
[  +0.000001] pci_bus 0000:02: resource 1 [mem 0x82000000-0x8dffffff]
[  +0.000001] pci_bus 0000:02: resource 2 [mem 0x6000000000-0x601befffff 64bit pref]
[  +0.000001] pci_bus 0000:04: resource 0 [io  0x4000-0x4fff]
[  +0.000001] pci_bus 0000:04: resource 1 [mem 0x8a000000-0x8dffffff]
[  +0.000001] pci_bus 0000:04: resource 2 [mem 0x6012a00000-0x601befffff 64bit pref]
[  +0.000002] pci_bus 0000:17: resource 0 [io  0x5000-0x5fff]
[  +0.000000] pci_bus 0000:17: resource 1 [mem 0x86000000-0x89ffffff]
[  +0.000001] pci_bus 0000:17: resource 2 [mem 0x6009500000-0x60129fffff 64bit pref]
[  +0.000002] pci_bus 0000:2a: resource 0 [io  0x6000-0x6fff]
[  +0.000001] pci_bus 0000:2a: resource 1 [mem 0x82000000-0x85ffffff]
[  +0.000001] pci_bus 0000:2a: resource 2 [mem 0x6000000000-0x60094fffff 64bit pref]
[  +0.000001] pci_bus 0000:40: resource 0 [io  0x8000-0x8fff]
[  +0.000001] pci_bus 0000:40: resource 1 [mem 0x74000000-0x801fffff]
[  +0.000001] pci_bus 0000:40: resource 2 [mem 0x6020000000-0x603bffffff 64bit pref]
[  +0.000945] PCI: CLS 0 bytes, default 64
[  +0.000113] DMAR: Intel-IOMMU force enabled due to platform opt in
[  +0.000009] DMAR: No ATSR found
[  +0.000001] DMAR: No SATC found
[  +0.000001] DMAR: IOMMU feature fl1gp_support inconsistent
[  +0.000001] DMAR: IOMMU feature pgsel_inv inconsistent
[  +0.000001] DMAR: IOMMU feature nwfs inconsistent
[  +0.000001] DMAR: IOMMU feature dit inconsistent
[  +0.000000] DMAR: IOMMU feature sc_support inconsistent
[  +0.000001] DMAR: IOMMU feature dev_iotlb_support inconsistent
[  +0.000001] DMAR: dmar1: Using Queued invalidation
[  +0.000003] DMAR: dmar0: Using Queued invalidation
[  +0.000002] DMAR: dmar2: Using Queued invalidation
[  +0.000062] Trying to unpack rootfs image as initramfs...
[  +0.000168] pci 0000:00:05.0: Adding to iommu group 0
[  +0.000037] pci 0000:00:02.0: Adding to iommu group 1
[  +0.000032] pci 0000:00:00.0: Adding to iommu group 2
[  +0.000009] pci 0000:00:04.0: Adding to iommu group 3
[  +0.000012] pci 0000:00:06.0: Adding to iommu group 4
[  +0.000010] pci 0000:00:07.0: Adding to iommu group 5
[  +0.000009] pci 0000:00:07.2: Adding to iommu group 6
[  +0.000009] pci 0000:00:08.0: Adding to iommu group 7
[  +0.000007] pci 0000:00:0a.0: Adding to iommu group 8
[  +0.000019] pci 0000:00:0d.0: Adding to iommu group 9
[  +0.000007] pci 0000:00:0d.2: Adding to iommu group 9
[  +0.000008] pci 0000:00:0d.3: Adding to iommu group 9
[  +0.000009] pci 0000:00:0e.0: Adding to iommu group 10
[  +0.000013] pci 0000:00:12.0: Adding to iommu group 11
[  +0.000015] pci 0000:00:14.0: Adding to iommu group 12
[  +0.000008] pci 0000:00:14.2: Adding to iommu group 12
[  +0.000008] pci 0000:00:14.3: Adding to iommu group 13
[  +0.000014] pci 0000:00:15.0: Adding to iommu group 14
[  +0.000009] pci 0000:00:15.1: Adding to iommu group 14
[  +0.000011] pci 0000:00:16.0: Adding to iommu group 15
[  +0.000015] pci 0000:00:1e.0: Adding to iommu group 16
[  +0.000009] pci 0000:00:1e.3: Adding to iommu group 16
[  +0.000021] pci 0000:00:1f.0: Adding to iommu group 17
[  +0.000009] pci 0000:00:1f.3: Adding to iommu group 17
[  +0.000009] pci 0000:00:1f.4: Adding to iommu group 17
[  +0.000010] pci 0000:00:1f.5: Adding to iommu group 17
[  +0.000011] pci 0000:01:00.0: Adding to iommu group 18
[  +0.000010] pci 0000:02:00.0: Adding to iommu group 19
[  +0.000008] pci 0000:02:01.0: Adding to iommu group 20
[  +0.000009] pci 0000:02:02.0: Adding to iommu group 21
[  +0.000009] pci 0000:02:03.0: Adding to iommu group 22
[  +0.000009] pci 0000:02:04.0: Adding to iommu group 23
[  +0.000425] DMAR: Intel(R) Virtualization Technology for Directed I/O
[  +0.000002] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[  +0.000000] software IO TLB: mapped [mem 0x00000000434e4000-0x00000000474e4000] (64MB)
[  +0.000034] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x25a39079a08, max_idle_ns: 440795310461 ns
[  +0.000216] clocksource: Switched to clocksource tsc
[  +0.003428] Initialise system trusted keyrings
[  +0.000008] Key type blacklist registered
[  +0.000071] workingset: timestamp_bits=41 max_order=23 bucket_order=0
[  +0.000006] zbud: loaded
[  +0.000119] integrity: Platform Keyring initialized
[  +0.000003] integrity: Machine keyring initialized
[  +0.009220] Key type asymmetric registered
[  +0.000002] Asymmetric key parser 'x509' registered
[  +0.000018] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 242)
[  +0.000044] io scheduler mq-deadline registered
[  +0.000001] io scheduler kyber registered
[  +0.000007] io scheduler bfq registered
[  +0.007933] pcieport 0000:00:07.0: PME: Signaling with IRQ 123
[  +0.000018] pcieport 0000:00:07.0: pciehp: Slot #3 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
[  +0.000291] pcieport 0000:00:07.2: PME: Signaling with IRQ 124
[  +0.000017] pcieport 0000:00:07.2: pciehp: Slot #5 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
[  +0.000790] pcieport 0000:02:01.0: pciehp: Slot #1 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
[  +0.000328] pcieport 0000:02:02.0: pciehp: Slot #2 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
[  +0.000344] pcieport 0000:02:03.0: pciehp: Slot #3 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
[  +0.000494] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[  +0.000223] Monitor-Mwait will be used to enter C-1 state
[  +0.000026] Monitor-Mwait will be used to enter C-2 state
[  +0.000005] Monitor-Mwait will be used to enter C-3 state
[  +0.000003] ACPI: \_SB_.PR00: Found 3 idle states
[  +0.001660] ACPI: AC: AC Adapter [AC] (on-line)
[  +0.000052] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0
[  +0.000040] ACPI: button: Lid Switch [LID0]
[  +0.000022] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input1
[  +0.000027] ACPI: button: Power Button [PBTN]
[  +0.003970] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[  +0.001543] serial 0000:00:12.0: enabling device (0000 -> 0002)
[  +0.000898] hpet_acpi_add: no address or irqs in _CRS
[  +0.000041] Non-volatile memory driver v1.3
[  +0.000001] Linux agpgart interface v0.103
[  +0.001807] tpm_tis STM0176:00: 2.0 TPM (device-id 0x0, rev-id 78)
[  +0.037458] ACPI: battery: Slot [BAT0] (battery present)
[  +0.021188] Freeing initrd memory: 36024K
[  +0.286816] ACPI: bus type drm_connector registered
[  +0.002615] ahci 0000:00:0e.0: version 3.0
[  +0.000009] ahci 0000:00:0e.0: probe with driver ahci failed with error -22
[  +0.000083] usbcore: registered new interface driver usbserial_generic
[  +0.000002] usbserial: USB Serial support registered for generic
[  +0.000026] rtc_cmos 00:01: RTC can wake from S4
[  +0.008441] rtc_cmos 00:01: registered as rtc0
[  +0.002045] rtc_cmos 00:01: setting system clock to 2024-05-27T11:45:38 UTC (1716810338)
[  +0.000027] rtc_cmos 00:01: alarms up to one month, y3k, 242 bytes nvram
[  +0.001138] intel_pstate: Intel P-state driver initializing
[  +0.001693] intel_pstate: HWP enabled
[  +0.000266] ledtrig-cpu: registered to indicate activity on CPUs
[  +0.000478] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
[  +0.001445] Console: switching to colour frame buffer device 100x37
[  +0.000720] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
[  +0.000536] hid: raw HID events driver (C) Jiri Kosina
[  +0.000106] drop_monitor: Initializing network drop monitor service
[  +0.000082] Initializing XFRM netlink socket
[  +0.000028] NET: Registered PF_INET6 protocol family
[  +0.005566] Segment Routing with IPv6
[  +0.000001] RPL Segment Routing with IPv6
[  +0.000005] In-situ OAM (IOAM) with IPv6
[  +0.000016] NET: Registered PF_PACKET protocol family
[  +0.001158] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
[  +0.000284] microcode: Current revision: 0x00004121
[  +0.000186] IPI shorthand broadcast: enabled
[  +0.001626] sched_clock: Marking stable (1657001321, 20833413)->(1720593366, -42758632)
[  +0.000214] Timer migration: 2 hierarchy levels; 8 children per group; 2 crossnode level
[  +0.000128] registered taskstats version 1
[  +0.000382] Loading compiled-in X.509 certificates
[  +0.002836] Loaded X.509 cert 'Build time autogenerated kernel key: 658c2d92e5069fca026f04f4aed038bb36c12159'
[  +0.002144] Loaded X.509 cert 'Local Out of tree kernel module signing key: fb179398c93b421e5b92a3374fbb078764f36b2c'
[  +0.004652] zswap: loaded using pool zstd/zsmalloc
[  +0.000034] Demotion targets for Node 0: null
[  +0.000203] Key type .fscrypt registered
[  +0.000001] Key type fscrypt-provisioning registered
[  +0.000149] integrity: Loading X.509 certificate: UEFI:db
[  +0.000021] integrity: Loaded X.509 cert 'Dell Inc.: Dell Bios DB Key: 637fa7a9f74471b406de0511557071fd41dd5487'
[  +0.000001] integrity: Loading X.509 certificate: UEFI:db
[  +0.000011] integrity: Loaded X.509 cert 'Dell Inc.: Dell Bios FW Aux Authority 2018: dd4df7c3f5ce7e5a77847915abc37b031f6b10bd'
[  +0.000001] integrity: Loading X.509 certificate: UEFI:db
[  +0.000015] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
[  +0.000001] integrity: Loading X.509 certificate: UEFI:db
[  +0.000015] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
[  +0.001355] PM:   Magic number: 8:425:783
[  +0.002376] RAS: Correctable Errors collector initialized.
[  +0.008913] clk: Disabling unused clocks
[  +0.000001] PM: genpd: Disabling unused power domains
[  +0.004464] Freeing unused decrypted memory: 2028K
[  +0.000644] Freeing unused kernel image (initmem) memory: 3436K
[  +0.000016] Write protecting the kernel read-only data: 32768k
[  +0.000500] Freeing unused kernel image (rodata/data gap) memory: 932K
[  +0.005883] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[  +0.000004] rodata_test: all tests were successful
[  +0.000003] Run /init as init process
[  +0.000001]   with arguments:
[  +0.000000]     /init
[  +0.000001]     splash
[  +0.000001]   with environment:
[  +0.000000]     HOME=/
[  +0.000001]     TERM=linux
[  +0.017597] systemd[1]: Successfully made /usr/ read-only.
[  +0.001442] systemd[1]: systemd 256rc3-1-arch-ga3680a4^ running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP -SYSVINIT +LIBARCHIVE)
[  +0.000010] systemd[1]: Detected architecture x86-64.
[  +0.000002] systemd[1]: Running in initrd.
[  +0.000177] systemd[1]: Hostname set to <lap7.prv.sapience.com>.
[  +0.078370] systemd[1]: Queued start job for default target Initrd Default Target.
[  +0.017501] systemd[1]: Expecting device /dev/disk/by-uuid/54B1-665A...
[  +0.000075] systemd[1]: Expecting device /dev/disk/by-uuid/aa97c5c2-c3cf-4b82-8773-5970f490a90b...
[  +0.000048] systemd[1]: Reached target Initrd /usr File System.
[  +0.000067] systemd[1]: Reached target Slice Units.
[  +0.000031] systemd[1]: Reached target Swaps.
[  +0.000028] systemd[1]: Reached target Timer Units.
[  +0.000171] systemd[1]: Listening on Journal Socket (/dev/log).
[  +0.000103] systemd[1]: Listening on Journal Sockets.
[  +0.000103] systemd[1]: Listening on udev Control Socket.
[  +0.000073] systemd[1]: Listening on udev Kernel Socket.
[  +0.000025] systemd[1]: Reached target Socket Units.
[  +0.001723] systemd[1]: Starting Create List of Static Device Nodes...
[  +0.002457] systemd[1]: Starting Journal Service...
[  +0.001033] systemd[1]: Starting Load Kernel Modules...
[  +0.000045] systemd[1]: TPM PCR Barrier (initrd) was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[  +0.000867] systemd[1]: Starting Virtual Console Setup...
[  +0.002447] systemd[1]: Finished Create List of Static Device Nodes.
[  +0.003296] systemd[1]: Starting Create Static Device Nodes in /dev gracefully...
[  +0.005306] systemd-journald[223]: Collecting audit messages is disabled.
[  +0.000577] systemd[1]: Finished Virtual Console Setup.
[  +0.000493] systemd[1]: Starting dracut ask for additional cmdline parameters...
[  +0.001621] loop: module loaded
[  +0.003088] systemd[1]: Finished Create Static Device Nodes in /dev gracefully.
[  +0.000373] systemd[1]: Starting Create System Users...
[  +0.008012] systemd[1]: Finished Create System Users.
[  +0.000444] systemd[1]: Starting Create Static Device Nodes in /dev...
[  +0.001300] systemd[1]: Started Journal Service.
[  +0.005602] wireguard: WireGuard 1.0.0 loaded. See www.wireguard.com for information.
[  +0.000002] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[  +0.001864] Asymmetric key parser 'pkcs8' registered
[  +0.233906] wmi_bus wmi_bus-PNP0C14:02: [Firmware Bug]: WQBC data block query control method not found
[  +0.003101] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
[  +0.001156] i8042: Warning: Keylock active
[  +0.003598] serio: i8042 KBD port at 0x60,0x64 irq 1
[  +0.000053] serio: i8042 AUX port at 0x60,0x64 irq 12
[  +0.004333] vmd 0000:00:0e.0: PCI host bridge to bus 10000:e0
[  +0.000005] pci_bus 10000:e0: root bus resource [bus e0-ff]
[  +0.000002] pci_bus 10000:e0: root bus resource [mem 0x72000000-0x73ffffff]
[  +0.000002] pci_bus 10000:e0: root bus resource [mem 0x6040102000-0x60401fffff 64bit]
[  +0.000022] pci 10000:e0:06.0: [8086:a74d] type 01 class 0x060400 PCIe Root Port
[  +0.000015] pci 10000:e0:06.0: PCI bridge to [bus e1]
[  +0.000005] pci 10000:e0:06.0:   bridge window [io  0x0000-0x0fff]
[  +0.000002] pci 10000:e0:06.0:   bridge window [mem 0x72000000-0x720fffff]
[  +0.000041] pci 10000:e0:06.0: PME# supported from D0 D3hot D3cold
[  +0.000024] pci 10000:e0:06.0: PTM enabled (root), 4ns granularity
[  +0.000099] pci 10000:e0:06.0: Adding to iommu group 10
[  +0.000020] pci 10000:e0:06.0: Primary bus is hard wired to 0
[  +0.000034] pci 10000:e1:00.0: [1c5c:1959] type 00 class 0x010802 PCIe Endpoint
[  +0.000015] pci 10000:e1:00.0: BAR 0 [mem 0x72000000-0x72003fff 64bit]
[  +0.000418] pci 10000:e1:00.0: Adding to iommu group 10
[  +0.000035] pci 10000:e0:06.0: PCI bridge to [bus e1]
[  +0.000017] pci 10000:e0:06.0: Primary bus is hard wired to 0
[  +0.004160] xhci_hcd 0000:00:0d.0: xHCI Host Controller
[  +0.000006] xhci_hcd 0000:00:0d.0: new USB bus registered, assigned bus number 1
[  +0.001060] xhci_hcd 0000:00:0d.0: hcc params 0x20007fc1 hci version 0x120 quirks 0x0000000200009810
[  +0.000280] xhci_hcd 0000:00:0d.0: xHCI Host Controller
[  +0.000003] xhci_hcd 0000:00:0d.0: new USB bus registered, assigned bus number 2
[  +0.000002] xhci_hcd 0000:00:0d.0: Host supports USB 3.2 Enhanced SuperSpeed
[  +0.000049] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.10
[  +0.000005] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  +0.000002] usb usb1: Product: xHCI Host Controller
[  +0.000002] usb usb1: Manufacturer: Linux 6.10.0-rc1-custom-2 xhci-hcd
[  +0.000001] usb usb1: SerialNumber: 0000:00:0d.0
[  +0.000164] hub 1-0:1.0: USB hub found
[  +0.000010] hub 1-0:1.0: 1 port detected
[  +0.000099] cryptd: max_cpu_qlen set to 1000
[  +0.000232] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.10
[  +0.000003] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  +0.000002] usb usb2: Product: xHCI Host Controller
[  +0.000001] usb usb2: Manufacturer: Linux 6.10.0-rc1-custom-2 xhci-hcd
[  +0.000001] usb usb2: SerialNumber: 0000:00:0d.0
[  +0.000065] hub 2-0:1.0: USB hub found
[  +0.000005] hub 2-0:1.0: 3 ports detected
[  +0.001350] xhci_hcd 0000:00:14.0: xHCI Host Controller
[  +0.000004] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 3
[  +0.001095] xhci_hcd 0000:00:14.0: hcc params 0x20007fc1 hci version 0x120 quirks 0x0000100200009810
[  +0.000385] xhci_hcd 0000:00:14.0: xHCI Host Controller
[  +0.000021] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 4
[  +0.000003] xhci_hcd 0000:00:14.0: Host supports USB 3.1 Enhanced SuperSpeed
[  +0.000063] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.10
[  +0.000005] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  +0.000002] usb usb3: Product: xHCI Host Controller
[  +0.000001] usb usb3: Manufacturer: Linux 6.10.0-rc1-custom-2 xhci-hcd
[  +0.000001] usb usb3: SerialNumber: 0000:00:14.0
[  +0.000414] hub 3-0:1.0: USB hub found
[  +0.000033] hub 3-0:1.0: 12 ports detected
[  +0.001403] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.10
[  +0.000005] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[  +0.000002] usb usb4: Product: xHCI Host Controller
[  +0.000002] usb usb4: Manufacturer: Linux 6.10.0-rc1-custom-2 xhci-hcd
[  +0.000001] usb usb4: SerialNumber: 0000:00:14.0
[  +0.000104] hub 4-0:1.0: USB hub found
[  +0.000016] hub 4-0:1.0: 4 ports detected
[  +0.003086] AVX2 version of gcm_enc/dec engaged.
[  +0.000142] AES CTR mode by8 optimization enabled
[  +0.005722] intel-lpss 0000:00:15.0: enabling device (0000 -> 0002)
[  +0.000700] idma64 idma64.0: Found Intel integrated DMA 64-bit
[  +0.006420] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input2
[  +0.108932] intel-lpss 0000:00:15.1: enabling device (0000 -> 0002)
[  +0.000343] idma64 idma64.1: Found Intel integrated DMA 64-bit
[  +0.060618] intel-lpss 0000:00:1e.0: enabling device (0000 -> 0002)
[  +0.000424] idma64 idma64.2: Found Intel integrated DMA 64-bit
[  +0.011619] intel-lpss 0000:00:1e.3: enabling device (0000 -> 0002)
[  +0.000251] idma64 idma64.3: Found Intel integrated DMA 64-bit
[  +0.017733] pci 10000:e0:06.0: bridge window [mem 0x72000000-0x720fffff]: assigned
[  +0.000003] pci 10000:e0:06.0: bridge window [io  size 0x1000]: can't assign; no space
[  +0.000002] pci 10000:e0:06.0: bridge window [io  size 0x1000]: failed to assign
[  +0.000003] pci 10000:e1:00.0: BAR 0 [mem 0x72000000-0x72003fff 64bit]: assigned
[  +0.000008] pci 10000:e0:06.0: PCI bridge to [bus e1]
[  +0.000003] pci 10000:e0:06.0:   bridge window [mem 0x72000000-0x720fffff]
[  +0.000009] pci 10000:e1:00.0: can't override BIOS ASPM; OS doesn't have ASPM control
[  +0.000022] pcieport 10000:e0:06.0: can't derive routing for PCI INT D
[  +0.000001] pcieport 10000:e0:06.0: PCI INT D: no GSI
[  +0.000050] pcieport 10000:e0:06.0: PME: Signaling with IRQ 166
[  +0.000075] vmd 0000:00:0e.0: Bound to PCI domain 10000
[  +0.016199] i915 0000:00:02.0: [drm] VT-d active for gfx access
[  +0.003633] Console: switching to colour dummy device 80x25
[  +0.006966] usb 3-1: new high-speed USB device number 2 using xhci_hcd
[  +0.015263] i915 0000:00:02.0: vgaarb: deactivate vga console
[  +0.000082] i915 0000:00:02.0: [drm] Using Transparent Hugepages
[  +0.000537] i915 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io+mem:owns=io+mem
[  +0.002761] input: LXT2021:00 29BD:3303 Touchscreen as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-LXT2021:00/0018:29BD:3303.0001/input/input5
[  +0.000063] hid-generic 0018:29BD:3303.0001: input,hidraw0: I2C HID v1.00 Device [LXT2021:00 29BD:3303] on i2c-LXT2021:00
[  +0.000739] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/adlp_dmc.bin (v2.20)
[  +0.013007] input: VEN_04F3:00 04F3:31D1 Mouse as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-VEN_04F3:00/0018:04F3:31D1.0002/input/input7
[  +0.000036] input: VEN_04F3:00 04F3:31D1 Touchpad as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-VEN_04F3:00/0018:04F3:31D1.0002/input/input8
[  +0.000024] input: VEN_04F3:00 04F3:31D1 as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-VEN_04F3:00/0018:04F3:31D1.0002/input/input10
[  +0.000029] hid-generic 0018:04F3:31D1.0002: input,hidraw1: I2C HID v1.00 Mouse [VEN_04F3:00 04F3:31D1] on i2c-VEN_04F3:00
[  +0.012523] nvme nvme0: pci function 10000:e1:00.0
[  +0.000006] pcieport 10000:e0:06.0: can't derive routing for PCI INT A
[  +0.000001] nvme 10000:e1:00.0: PCI INT A: not connected
[  +0.005182] dw-apb-uart.2: ttyS4 at MMIO 0x4017002000 (irq = 16, base_baud = 6250000) is a 16550A
[  +0.006132] input: LXT2021:00 29BD:3303 as /devices/pci0000:00/0000:00:15.0/i2c_designware.0/i2c-0/i2c-LXT2021:00/0018:29BD:3303.0001/input/input11
[  +0.000062] hid-multitouch 0018:29BD:3303.0001: input,hidraw0: I2C HID v1.00 Device [LXT2021:00 29BD:3303] on i2c-LXT2021:00
[  +0.000689] nvme nvme0: 16/0/0 default/read/poll queues
[  +0.002796]  nvme0n1: p1 p2 p3
[  +0.021081] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[  +0.012504] usb 2-1: New USB device found, idVendor=8087, idProduct=0b40, bcdDevice=12.34
[  +0.000003] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000001] usb 2-1: Product: USB3.0 Hub
[  +0.000001] usb 2-1: Manufacturer: Intel Corporation.
[  +0.000493] hub 2-1:1.0: USB hub found
[  +0.000012] hub 2-1:1.0: 4 ports detected
[  +0.025681] input: VEN_04F3:00 04F3:31D1 Mouse as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-VEN_04F3:00/0018:04F3:31D1.0002/input/input13
[  +0.000056] input: VEN_04F3:00 04F3:31D1 Touchpad as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-VEN_04F3:00/0018:04F3:31D1.0002/input/input14
[  +0.000023] input: VEN_04F3:00 04F3:31D1 UNKNOWN as /devices/pci0000:00/0000:00:15.1/i2c_designware.1/i2c-1/i2c-VEN_04F3:00/0018:04F3:31D1.0002/input/input16
[  +0.000052] hid-multitouch 0018:04F3:31D1.0002: input,hidraw1: I2C HID v1.00 Mouse [VEN_04F3:00 04F3:31D1] on i2c-VEN_04F3:00
[  +0.007484] usb 3-1: New USB device found, idVendor=1d5c, idProduct=5801, bcdDevice= 1.01
[  +0.000005] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000002] usb 3-1: Product: USB2.0 Hub
[  +0.000001] usb 3-1: Manufacturer: Fresco Logic, Inc.
[  +0.001207] hub 3-1:1.0: USB hub found
[  +0.000036] hub 3-1:1.0: 6 ports detected
[  +0.115431] usb 3-8: new full-speed USB device number 3 using xhci_hcd
[  +0.037718] i915 0000:00:02.0: [drm] GT0: GuC firmware i915/adlp_guc_70.bin version 70.20.0
[  +0.000004] i915 0000:00:02.0: [drm] GT0: HuC firmware i915/tgl_huc.bin version 7.9.3
[  +0.013989] i915 0000:00:02.0: [drm] GT0: HuC: authenticated for all workloads
[  +0.000345] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
[  +0.000001] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
[  +0.000487] i915 0000:00:02.0: [drm] GT0: GUC: RC enabled
[  +0.000534] i915 0000:00:02.0: [drm] Protected Xe Path (PXP) protected content support initialized
[  +0.010903] [drm] Initialized i915 1.6.0 20230929 for 0000:00:02.0 on minor 1
[  +0.005326] ACPI: video: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[  +0.004524] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input17
[  +0.054573] usb 3-8: New USB device found, idVendor=8086, idProduct=0b63, bcdDevice=10.01
[  +0.000012] usb 3-8: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000005] usb 3-8: Product: USB Bridge
[  +0.000003] usb 3-8: Manufacturer: MCHP
[  +0.035035] fbcon: i915drmfb (fb0) is primary device
[  +0.000052] Console: switching to colour frame buffer device 240x67
[  +0.000007] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[  +0.029605] ish-hid {33AECD58-B679-4E54-9BD9-A04D34F0C226}: [hid-ish]: enum_devices_done OK, num_hid_devices=2
[  +0.010922] hid-generic 001F:8087:0AC2.0003: hidraw2: SENSOR HUB HID v2.00 Device [hid-ishtp 8087:0AC2] on 
[  +0.006773] hid-generic 001F:8087:0AC2.0004: hidraw3: SENSOR HUB HID v2.00 Device [hid-ishtp 8087:0AC2] on 
[  +0.007481] hid-sensor-hub 001F:8087:0AC2.0003: hidraw2: SENSOR HUB HID v2.00 Device [hid-ishtp 8087:0AC2] on 
[  +0.001268] hid-sensor-hub 001F:8087:0AC2.0004: hidraw3: SENSOR HUB HID v2.00 Device [hid-ishtp 8087:0AC2] on 
[  +0.025404] usb 3-9: new full-speed USB device number 4 using xhci_hcd
[  +0.040329] input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input4
[  +0.087676] usb 3-9: New USB device found, idVendor=27c6, idProduct=63bc, bcdDevice= 1.00
[  +0.000006] usb 3-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000002] usb 3-9: Product: Goodix USB2.0 MISC
[  +0.000001] usb 3-9: Manufacturer: Goodix Technology Co., Ltd.
[  +0.000002] usb 3-9: SerialNumber: UIDBC032E31_XXXX_MOC_B0
[  +0.077981] usb 3-1.3: new full-speed USB device number 5 using xhci_hcd
[  +0.041006] EXT4-fs (nvme0n1p2): mounted filesystem aa97c5c2-c3cf-4b82-8773-5970f490a90b r/w with ordered data mode. Quota mode: none.
[  +0.051165] usb 3-1.3: New USB device found, idVendor=1050, idProduct=0407, bcdDevice= 5.43
[  +0.000006] usb 3-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000002] usb 3-1.3: Product: YubiKey OTP+FIDO+CCID
[  +0.000002] usb 3-1.3: Manufacturer: Yubico
[  +0.112965] usb 3-10: new full-speed USB device number 6 using xhci_hcd
[  +0.128340] usb 3-10: New USB device found, idVendor=8087, idProduct=0033, bcdDevice= 0.00
[  +0.000005] usb 3-10: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  +0.074646] usb 3-1.5: new full-speed USB device number 7 using xhci_hcd
[  +0.095298] usb 3-1.5: New USB device found, idVendor=047d, idProduct=80dc, bcdDevice=17.46
[  +0.000005] usb 3-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000002] usb 3-1.5: Product: Kensington TBT4 Nano Dock
[  +0.000002] usb 3-1.5: Manufacturer: Kensington
[  +0.000001] usb 3-1.5: SerialNumber: 11AD1D0AA0113F110F0A0B00
[  +0.082672] usb 3-1.6: new high-speed USB device number 8 using xhci_hcd
[  +0.094968] usb 3-1.6: New USB device found, idVendor=1d5c, idProduct=5530, bcdDevice= 1.01
[  +0.000005] usb 3-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000002] usb 3-1.6: Product: Frescologic VENDOR HID
[  +0.000002] usb 3-1.6: Manufacturer: Frescologic
[  +0.631331] i915 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A
[  +0.248230] systemd-journald[223]: Received SIGTERM from PID 1 (systemd).
[  +0.056975] systemd[1]: systemd 256rc3-1-arch-ga3680a4^ running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP -SYSVINIT +LIBARCHIVE)
[  +0.000004] systemd[1]: Detected architecture x86-64.
[  +0.092935] systemd[1]: bpf-restrict-fs: LSM BPF program attached
[  +0.017880] systemd-sslh-generator: Configuration directory '/etc/sslh/' does not exist! No units generated.
[  +0.128280] systemd[1]: run-credentials-systemd\x2djournald.service.mount: Deactivated successfully.
[  +0.000196] systemd[1]: initrd-switch-root.service: Deactivated successfully.
[  +0.000077] systemd[1]: Stopped Switch Root.
[  +0.000416] systemd[1]: systemd-journald.service: Scheduled restart job, restart counter is at 1.
[  +0.000236] systemd[1]: Created slice Slice /system/getty.
[  +0.000171] systemd[1]: Created slice Encrypted Volume Units Service Slice.
[  +0.000161] systemd[1]: Created slice Slice /system/systemd-fsck.
[  +0.000103] systemd[1]: Created slice User and Session Slice.
[  +0.000016] systemd[1]: Dispatch Password Requests to Console Directory Watch was skipped because of an unmet condition check (ConditionPathExists=!/run/plymouth/pid).
[  +0.000027] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[  +0.000086] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[  +0.000012] systemd[1]: Expecting device /dev/disk/by-uuid/54B1-665A...
[  +0.000005] systemd[1]: Expecting device /dev/disk/by-uuid/789e9dda-442b-4cfd-9427-f670c5727ae1...
[  +0.000008] systemd[1]: Expecting device /dev/disk/by-uuid/813d99a7-9dd7-4485-b757-7834ecb57fc9...
[  +0.000009] systemd[1]: Reached target Login Prompts.
[  +0.000012] systemd[1]: Stopped target Switch Root.
[  +0.000011] systemd[1]: Stopped target Initrd File Systems.
[  +0.000008] systemd[1]: Stopped target Initrd Root File System.
[  +0.000012] systemd[1]: Reached target Local Integrity Protected Volumes.
[  +0.000022] systemd[1]: Reached target Slice Units.
[  +0.000015] systemd[1]: Reached target Swaps.
[  +0.000013] systemd[1]: Reached target Local Verity Protected Volumes.
[  +0.000043] systemd[1]: Listening on Device-mapper event daemon FIFOs.
[  +0.000036] systemd[1]: Listening on LVM2 poll daemon socket.
[  +0.000697] systemd[1]: Listening on Process Core Dump Socket.
[  +0.000376] systemd[1]: Listening on Credential Encryption/Decryption.
[  +0.000028] systemd[1]: TPM PCR Measurements was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[  +0.000009] systemd[1]: Make TPM PCR Policy was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[  +0.000031] systemd[1]: Listening on udev Control Socket.
[  +0.000029] systemd[1]: Listening on udev Kernel Socket.
[  +0.000487] systemd[1]: Mounting Huge Pages File System...
[  +0.000509] systemd[1]: Mounting POSIX Message Queue File System...
[  +0.000746] systemd[1]: Mounting Kernel Debug File System...
[  +0.000806] systemd[1]: Mounting Kernel Trace File System...
[  +0.012503] systemd[1]: Mounting Temporary Directory /tmp...
[  +0.000068] systemd[1]: Kernel Module supporting RPCSEC_GSS was skipped because of an unmet condition check (ConditionPathExists=/etc/krb5.keytab).
[  +0.000724] systemd[1]: Starting Create List of Static Device Nodes...
[  +0.000643] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling...
[  +0.000545] systemd[1]: Starting Load Kernel Module configfs...
[  +0.000473] systemd[1]: Starting Load Kernel Module dm_mod...
[  +0.000687] systemd[1]: Starting Load Kernel Module drm...
[  +0.000740] systemd[1]: Starting Load Kernel Module fuse...
[  +0.000494] systemd[1]: Starting Load Kernel Module loop...
[  +0.000053] systemd[1]: plymouth-switch-root.service: Deactivated successfully.
[  +0.000052] systemd[1]: Stopped Plymouth switch root service.
[  +0.000120] systemd[1]: Clear Stale Hibernate Storage Info was skipped because of an unmet condition check (ConditionPathExists=/sys/firmware/efi/efivars/HibernateLocation-8cf2644b-4b0b-428f-9387-6d876050dc67).
[  +0.001236] systemd[1]: Starting Journal Service...
[  +0.000886] systemd[1]: Starting Load Kernel Modules...
[  +0.000022] systemd[1]: TPM PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[  +0.000472] systemd[1]: Starting Remount Root and Kernel File Systems...
[  +0.000076] systemd[1]: Early TPM SRK Setup was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[  +0.000781] systemd[1]: Starting Load udev Rules from Credentials...
[  +0.000707] systemd[1]: Starting Coldplug All udev Devices...
[  +0.001055] systemd[1]: Mounted Huge Pages File System.
[  +0.000066] systemd[1]: Mounted POSIX Message Queue File System.
[  +0.000044] systemd[1]: Mounted Kernel Debug File System.
[  +0.000041] systemd[1]: Mounted Kernel Trace File System.
[  +0.000043] systemd[1]: Mounted Temporary Directory /tmp.
[  +0.000154] systemd[1]: Finished Create List of Static Device Nodes.
[  +0.000125] systemd[1]: modprobe@configfs.service: Deactivated successfully.
[  +0.000095] systemd[1]: Finished Load Kernel Module configfs.
[  +0.000118] systemd[1]: modprobe@drm.service: Deactivated successfully.
[  +0.000083] systemd[1]: Finished Load Kernel Module drm.
[  +0.000109] systemd[1]: modprobe@loop.service: Deactivated successfully.
[  +0.000078] systemd[1]: Finished Load Kernel Module loop.
[  +0.000694] systemd[1]: Starting Create Static Device Nodes in /dev gracefully...
[  +0.000924] device-mapper: uevent: version 1.0.3
[  +0.000068] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@lists.linux.dev
[  +0.000827] systemd[1]: modprobe@dm_mod.service: Deactivated successfully.
[  +0.000200] systemd[1]: Finished Load Kernel Module dm_mod.
[  +0.000263] systemd[1]: Repartition Root Disk was skipped because no trigger condition checks were met.
[  +0.000250] systemd[1]: Finished Load Kernel Modules.
[  +0.001016] systemd[1]: Starting Apply Kernel Variables...
[  +0.001498] systemd[1]: Finished Load udev Rules from Credentials.
[  +0.001087] fuse: init (API version 7.40)
[  +0.000468] systemd[1]: modprobe@fuse.service: Deactivated successfully.
[  +0.000096] systemd[1]: Finished Load Kernel Module fuse.
[  +0.002741] systemd-journald[533]: Collecting audit messages is disabled.
[  +0.001414] systemd[1]: Started Journal Service.
[  +0.009150] EXT4-fs (nvme0n1p2): re-mounted aa97c5c2-c3cf-4b82-8773-5970f490a90b r/w. Quota mode: none.
[  +0.009186] systemd-journald[533]: Received client request to flush runtime journal.
[  +0.080120] mousedev: PS/2 mouse device common for all mice
[  +0.014954] int3472-discrete INT3472:01: INT3472 seems to have no dependents.
[  +0.003082] mc: Linux media interface: v0.10
[  +0.000469] input: Intel HID events as /devices/platform/INTC1078:00/input/input18
[  +0.001066] intel-hid INTC1078:00: platform supports 5 button array
[  +0.002097] input: Intel HID 5 button array as /devices/platform/INTC1078:00/input/input19
[  +0.009060] Consider using thermal netlink events interface
[  +0.001547] videodev: Linux video capture interface: v2.00
[  +0.002080] int3472-discrete INT3472:06: GPIO type 0x02 unknown; the sensor may not work
[  +0.014534] intel_pmc_core INT33A1:00:  initialized
[  +0.001900] resource: resource sanity check: requesting [mem 0x00000000fedc0000-0x00000000fedcffff], which spans more than pnp 00:05 [mem 0xfedc0000-0xfedc7fff]
[  +0.000006] caller igen6_probe+0x15e/0x7c0 [igen6_edac] mapping multiple BARs
[  +0.007739] ACPI: bus type thunderbolt registered
[  +0.001014] intel-ipu6 0000:00:05.0: enabling device (0000 -> 0002)
[  +0.000469] intel-ipu6 0000:00:05.0: IPU6 in non-secure mode touch 0x0 mask 0xff
[  +0.003709] EDAC MC0: Giving out device to module igen6_edac controller Intel_client_SoC MC#0: DEV 0000:00:00.0 (INTERRUPT)
[  +0.001653] intel-ipu6 0000:00:05.0: FW version: 20230925
[  +0.001905] intel-ipu6 0000:00:05.0: IPU6-v3[a75d] hardware version 5
[  +0.004713] EDAC MC1: Giving out device to module igen6_edac controller Intel_client_SoC MC#1: DEV 0000:00:00.0 (INTERRUPT)
[  +0.000029] EDAC igen6 MC1: HANDLING IBECC MEMORY ERROR
[  +0.000001] EDAC igen6 MC1: ADDR 0x1ffffffffff 
[  +0.000001] EDAC igen6 MC0: HANDLING IBECC MEMORY ERROR
[  +0.000001] EDAC igen6 MC0: ADDR 0x1ffffffffff 
[  +0.001515] EDAC igen6: v2.5.1
[  +0.006861] mei_me 0000:00:16.0: enabling device (0000 -> 0002)
[  +0.009490] i801_smbus 0000:00:1f.4: enabling device (0000 -> 0003)
[  +0.000453] i801_smbus 0000:00:1f.4: SPD Write Disable is set
[  +0.000038] i801_smbus 0000:00:1f.4: SMBus using PCI interrupt
[  +0.018572] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[  +0.001683] usbcore: registered new interface driver ljca
[  +0.001479] input: Yubico YubiKey OTP+FIDO+CCID as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:1050:0407.0005/input/input20
[  +0.000181] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[  +0.000199] Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
[  +0.014102] input: PC Speaker as /devices/platform/pcspkr/input/input21
[  +0.000239] Bluetooth: Core ver 2.22
[  +0.000016] NET: Registered PF_BLUETOOTH protocol family
[  +0.000001] Bluetooth: HCI device and connection manager initialized
[  +0.000003] Bluetooth: HCI socket layer initialized
[  +0.000001] Bluetooth: L2CAP socket layer initialized
[  +0.000003] Bluetooth: SCO socket layer initialized
[  +0.001816] ACPI: battery: new extension: Dell DDV Battery Extension
[  +0.036105] hid-generic 0003:1050:0407.0005: input,hidraw4: USB HID v1.10 Keyboard [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:14.0-1.3/input0
[  +0.000651] hid-generic 0003:1050:0407.0006: hiddev96,hidraw5: USB HID v1.10 Device [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:14.0-1.3/input1
[  +0.000830] hid-generic 0003:1D5C:5530.0007: hiddev97,hidraw6: USB HID v1.01 Device [Frescologic Frescologic VENDOR HID] on usb-0000:00:14.0-1.6/input0
[  +0.000028] usbcore: registered new interface driver usbhid
[  +0.000001] usbhid: USB HID core driver
[  +0.035348] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms ovfl timer
[  +0.000004] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[  +0.000001] RAPL PMU: hw unit of domain package 2^-14 Joules
[  +0.000001] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[  +0.000001] RAPL PMU: hw unit of domain psys 2^-14 Joules
[  +0.282748] i2c i2c-17: Memory type 0x23 not supported yet, not instantiating SPD
[  +0.149236] usb 3-1: USB disconnect, device number 2
[  +0.000004] usb 3-1.3: USB disconnect, device number 5
[  +0.022916] pcieport 0000:00:07.0: pciehp: Slot(3): Link Down
[  +0.000003] pcieport 0000:00:07.0: pciehp: Slot(3): Card not present
[  +0.002366] pcieport 0000:02:03.0: Runtime PM usage count underflow!
[  +0.000495] pcieport 0000:02:02.0: Runtime PM usage count underflow!
[  +0.000195] pcieport 0000:02:01.0: Runtime PM usage count underflow!
[  +0.000135] pci_bus 0000:03: busn_res: [bus 03] is released
[  +0.000105] pci_bus 0000:04: busn_res: [bus 04-16] is released
[  +0.000111] pci_bus 0000:17: busn_res: [bus 17-29] is released
[  +0.000180] pci_bus 0000:2a: busn_res: [bus 2a-3e] is released
[  +0.000047] pci_bus 0000:3f: busn_res: [bus 3f] is released
[  +0.000046] pci_bus 0000:02: busn_res: [bus 02-3f] is released
[  +0.128238] usb 2-1: USB disconnect, device number 2
[  +0.020767] usb 3-1.5: USB disconnect, device number 7
[  +0.000463] usb 3-1.6: USB disconnect, device number 8
[  +0.066428] proc_thermal_pci 0000:00:04.0: enabling device (0000 -> 0002)
[  +0.000175] intel_rapl_common: Found RAPL domain package
[  +0.010928] Intel(R) Wireless WiFi driver for Linux
[  +0.001649] iwlwifi 0000:00:14.3: enabling device (0000 -> 0002)
[  +0.014461] iwlwifi 0000:00:14.3: Detected crf-id 0x400410, cnv-id 0x80400 wfpm id 0x80000020
[  +0.000100] iwlwifi 0000:00:14.3: PCI dev 51f1/4090, rev=0x370, rfid=0x2010d000
[  +0.005968] iwlwifi 0000:00:14.3: TLV_FW_FSEQ_VERSION: FSEQ Version: 0.0.2.42
[  +0.000438] iwlwifi 0000:00:14.3: loaded firmware version 89.e9cec78e.0 so-a0-gf-a0-89.ucode op_mode iwlmvm
[  +0.009139] iTCO_vendor_support: vendor-support=0
[  +0.007741] intel_rapl_msr: PL4 support detected.
[  +0.000918] intel_rapl_common: Found RAPL domain package
[  +0.000002] intel_rapl_common: Found RAPL domain core
[  +0.000001] intel_rapl_common: Found RAPL domain uncore
[  +0.000002] intel_rapl_common: Found RAPL domain psys
[  +0.003499] usbcore: registered new interface driver btusb
[  +0.001111] input: Dell Privacy Driver as /devices/platform/PNP0C14:02/wmi_bus/wmi_bus-PNP0C14:02/6932965F-1671-4CEB-B988-D3AB0A901919/input/input22
[  +0.000890] input: Dell WMI hotkeys as /devices/platform/PNP0C14:02/wmi_bus/wmi_bus-PNP0C14:02/9DBB5994-A997-11DA-B012-B622A1EF5492/input/input23
[  +0.000253] Bluetooth: hci0: Device revision is 0
[  +0.000003] Bluetooth: hci0: Secure boot is enabled
[  +0.000001] Bluetooth: hci0: OTP lock is enabled
[  +0.000001] Bluetooth: hci0: API lock is enabled
[  +0.000001] Bluetooth: hci0: Debug lock is disabled
[  +0.000001] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[  +0.000002] Bluetooth: hci0: Bootloader timestamp 2019.40 buildtype 1 build 38
[  +0.001140] iTCO_wdt iTCO_wdt: Found a Intel PCH TCO device (Version=6, TCOBASE=0x0400)
[  +0.000393] ACPI Warning: \_SB.PC00.XHCI.RHUB.HS10._DSM: Argument #4 type mismatch - Found [Integer], ACPI requires [Package] (20240322/nsarguments-61)
[  +0.000767] iTCO_wdt iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[  +0.001247] Bluetooth: hci0: DSM reset method type: 0x00
[  +0.002611] Creating 1 MTD partitions on "0000:00:1f.5":
[  +0.000005] 0x000000000000-0x000004000000 : "BIOS"
[  +0.002921] Bluetooth: hci0: Found device firmware: intel/ibt-0040-0041.sfi
[  +0.000027] Bluetooth: hci0: Boot Address: 0x100800
[  +0.000001] Bluetooth: hci0: Firmware Version: 46-14.24
[  +0.002332] mei_pxp 0000:00:16.0-fbf6fcf1-96cf-4e2e-a6a6-1bab8cbe36b1: bound 0000:00:02.0 (ops i915_pxp_tee_component_ops [i915])
[  +0.001907] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_ops [i915])
[  +0.071923] ACPI Warning: \_SB.PC00.SPI1.SPFD.CVFD.SID: Insufficient arguments - Caller passed 0, method requires 1 (20240322/nsarguments-232)
[  +0.003684] intel_vsc intel_vsc: silicon stepping version is 0:2
[  +1.439175] Bluetooth: hci0: Waiting for firmware download to complete
[  +0.000934] Bluetooth: hci0: Firmware loaded in 1484353 usecs
[  +0.000077] Bluetooth: hci0: Waiting for device to boot
[  +0.015934] Bluetooth: hci0: Device booted in 15623 usecs
[  +0.000002] Bluetooth: hci0: Malformed MSFT vendor event: 0x02
[  +0.009803] Bluetooth: hci0: Found Intel DDC parameters: intel/ibt-0040-0041.ddc
[  +0.002209] Bluetooth: hci0: Applying Intel DDC parameters completed
[  +0.002930] Bluetooth: hci0: Firmware timestamp 2024.14 buildtype 1 build 81454
[  +0.000014] Bluetooth: hci0: Firmware SHA1: 0xdfd62093
[  +0.003943] Bluetooth: hci0: Fseq status: Success (0x00)
[  +0.000008] Bluetooth: hci0: Fseq executed: 00.00.02.41
[  +0.000008] Bluetooth: hci0: Fseq BT Top: 00.00.02.41
[  +1.763314] usb 3-1: new high-speed USB device number 9 using xhci_hcd
[  +0.174082] thunderbolt 0-0:1.1: new retimer found, vendor=0x8087 device=0x15ee
[  +0.014139] usb 3-1: New USB device found, idVendor=1d5c, idProduct=5801, bcdDevice= 1.01
[  +0.000008] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000002] usb 3-1: Product: USB2.0 Hub
[  +0.000002] usb 3-1: Manufacturer: Fresco Logic, Inc.
[  +0.001102] hub 3-1:1.0: USB hub found
[  +0.000050] hub 3-1:1.0: 6 ports detected
[  +0.025617] thunderbolt 0-1: new device found, vendor=0x1b device=0xb
[  +0.000005] thunderbolt 0-1: Kensington Kensington TBT4 Nano Dock
[  +0.507885] usb 3-1.3: new full-speed USB device number 10 using xhci_hcd
[  +0.090446] usb 3-1.3: New USB device found, idVendor=1050, idProduct=0407, bcdDevice= 5.43
[  +0.000009] usb 3-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000005] usb 3-1.3: Product: YubiKey OTP+FIDO+CCID
[  +0.000003] usb 3-1.3: Manufacturer: Yubico
[  +0.015834] input: Yubico YubiKey OTP+FIDO+CCID as /devices/pci0000:00/0000:00:14.0/usb3/3-1/3-1.3/3-1.3:1.0/0003:1050:0407.0008/input/input24
[  +0.042785] usb 2-1: new SuperSpeed Plus Gen 2x1 USB device number 3 using xhci_hcd
[  +0.010462] hid-generic 0003:1050:0407.0008: input,hidraw4: USB HID v1.10 Keyboard [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:14.0-1.3/input0
[  +0.001173] hid-generic 0003:1050:0407.0009: hiddev96,hidraw5: USB HID v1.10 Device [Yubico YubiKey OTP+FIDO+CCID] on usb-0000:00:14.0-1.3/input1
[  +0.000949] usb 2-1: New USB device found, idVendor=8087, idProduct=0b40, bcdDevice=12.34
[  +0.000008] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000004] usb 2-1: Product: USB3.0 Hub
[  +0.000002] usb 2-1: Manufacturer: Intel Corporation.
[  +0.000739] hub 2-1:1.0: USB hub found
[  +0.000033] hub 2-1:1.0: 4 ports detected
[  +0.075547] usb 3-1.5: new full-speed USB device number 11 using xhci_hcd
[  +0.094490] usb 3-1.5: New USB device found, idVendor=047d, idProduct=80dc, bcdDevice=17.46
[  +0.000014] usb 3-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000005] usb 3-1.5: Product: Kensington TBT4 Nano Dock
[  +0.000004] usb 3-1.5: Manufacturer: Kensington
[  +0.000003] usb 3-1.5: SerialNumber: 11AD1D0AA0113F110F0A0B00
[  +0.084493] usb 3-1.6: new high-speed USB device number 12 using xhci_hcd
[  +0.093564] usb 3-1.6: New USB device found, idVendor=1d5c, idProduct=5530, bcdDevice= 1.01
[  +0.000011] usb 3-1.6: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000006] usb 3-1.6: Product: Frescologic VENDOR HID
[  +0.000003] usb 3-1.6: Manufacturer: Frescologic
[  +0.002623] hid-generic 0003:1D5C:5530.000A: hiddev97,hidraw6: USB HID v1.01 Device [Frescologic Frescologic VENDOR HID] on usb-0000:00:14.0-1.6/input0
[  +5.799788] snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
[  +0.000033] snd_hda_intel 0000:00:1f.3: SoundWire enabled on CannonLake+ platform, using SOF driver
[  +0.002110] Key type trusted registered
[  +0.015476] intel_tcc_cooling: TCC Offset locked
[  +0.004794] iwlwifi 0000:00:14.3: Detected Intel(R) Wi-Fi 6E AX211 160MHz, REV=0x370
[  +0.000044] thermal thermal_zone10: failed to read out thermal zone (-61)
[  +0.008065] iwlwifi 0000:00:14.3: WRT: Invalid buffer destination
[  +0.011804] ------------[ cut here ]------------
[  +0.000001] WARNING: CPU: 1 PID: 588 at drivers/media/pci/intel/ivsc/mei_csi.c:682 mei_csi_probe+0x4de/0x520 [ivsc_csi]
[  +0.000005] Modules linked in: ivsc_ace(+) ivsc_csi(+) snd_soc_avs(+) snd_soc_hda_codec snd_hda_ext_core padlock_aes(-) snd_soc_core intel_tcc_cooling(-) snd_compress cbc encrypted_keys(+) x86_pkg_temp_thermal ac97_bus intel_powerclamp iwlmvm(+) snd_pcm_dmaengine trusted snd_hda_intel coretemp asn1_encoder tee snd_ctl_led mei_vsc snd_intel_dspcfg intel_ipu6_isys mac80211 snd_intel_sdw_acpi kvm_intel videobuf2_dma_contig snd_hda_codec dell_laptop spi_nor iTCO_wdt vfat videobuf2_memops hid_sensor_als hid_sensor_custom_intel_hinge btusb intel_pmc_bxt snd_hda_core dell_wmi videobuf2_v4l2 libarc4 mei_pxp mei_hdcp gpio_ljca mtd hid_sensor_trigger typec_displayport i2c_ljca spi_ljca iTCO_vendor_support btrtl fat videobuf2_common
[  +0.000018] snd_soc_avs 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
[  +0.000001]  intel_rapl_msr snd_hwdep industrialio_triggered_buffer btintel kvm iwlwifi btbcm kfifo_buf dell_smbios processor_thermal_device_pci snd_pcm dell_wmi_sysman processor_thermal_device btmtk hid_sensor_iio_common dcdbas processor_thermal_wt_hint rapl intel_cstate intel_uncore pcspkr dell_wmi_ddv dell_smm_hwmon firmware_attributes_class wmi_bmof bluetooth dell_wmi_descriptor usbhid usb_ljca industrialio snd_timer cfg80211 processor_thermal_rfim i2c_i801 mei_me processor_thermal_rapl i2c_smbus spi_intel_pci snd intel_rapl_common i2c_mux soundcore spi_intel ov01a10 mei processor_thermal_wt_req intel_skl_int3472_tps68470 rfkill intel_ipu6 v4l2_fwnode processor_thermal_power_floor tps68470_regulator thunderbolt igen6_edac ipu_bridge processor_thermal_mbox clk_tps68470
[  +0.000019] snd_soc_avs 0000:00:1f.3: SoundWire enabled on CannonLake+ platform, using SOF driver
[  +0.000001]  v4l2_async
[  +0.000000]  intel_pmc_core int3403_thermal int340x_thermal_zone mei_vsc_hw videodev intel_vsec int3400_thermal mc pmt_telemetry acpi_tad acpi_thermal_rel acpi_pad intel_hid pmt_class intel_skl_int3472_discrete joydev sparse_keymap mousedev mac_hid fuse dm_mod nfnetlink ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 hid_sensor_custom xe hid_sensor_hub drm_ttm_helper intel_ishtp_hid gpu_sched drm_suballoc_helper drm_gpuvm drm_exec nvme nvme_core spi_pxa2xx_platform 8250_dw hid_multitouch dw_dmac i915 crct10dif_pclmul crc32_pclmul crc32c_intel polyval_clmulni psmouse polyval_generic gf128mul ghash_clmulni_intel serio_raw sha512_ssse3 atkbd libps2 sha256_ssse3 vivaldi_fmap i2c_algo_bit sha1_ssse3 drm_buddy aesni_intel ucsi_acpi ttm crypto_simd intel_lpss_pci typec_ucsi intel_gtt cryptd intel_ish_ipc xhci_pci roles intel_lpss drm_display_helper intel_ishtp idma64 xhci_pci_renesas vmd video typec cec i2c_hid_acpi i8042 i2c_hid wmi serio pkcs8_key_parser wireguard curve25519_x86_64 libchacha20poly1305
[  +0.000033]  chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel libcurve25519_generic libchacha loop sg crypto_user
[  +0.000004] CPU: 1 PID: 588 Comm: (udev-worker) Not tainted 6.10.0-rc1-custom-2 #1 94307814a71ed94fef64c6e0d214e9e25710cf4b
[  +0.000002] Hardware name: Dell Inc. XPS 9320/0CR6NC, BIOS 2.11.0 03/06/2024
[  +0.000002] RIP: 0010:mei_csi_probe+0x4de/0x520 [ivsc_csi]
[  +0.000002] Code: 85 c0 78 33 48 89 df 48 c7 c6 c0 f1 4b c1 e8 c9 2e b9 ff 89 c3 85 c0 78 26 48 8b bd 68 ff ff ff e8 57 42 29 dc e9 88 fe ff ff <0f> 0b 41 bf fa ff ff ff e9 7b fe ff ff 41 89 c7 e9 53 fe ff ff 48
[  +0.000001] RSP: 0018:ffffb2afc09b7780 EFLAGS: 00010246
[  +0.000003] RAX: 0000000000000000 RBX: ffffffffc1504688 RCX: 0000000000000000
[  +0.000001] RDX: 0000000000000000 RSI: ffff965d017910e8 RDI: ffff965d0f691c18
[  +0.000000] RBP: ffffb2afc09b7840 R08: 0000000000000228 R09: ffff965d001d6510
[  +0.000001] R10: ffffb2afc09b7860 R11: 0000000000000040 R12: ffff965d0f691c00
[  +0.000001] R13: ffff965d0f691c00 R14: 0000000000000000 R15: 0000000000000000
[  +0.000001] FS:  00007fe412a4d880(0000) GS:ffff96646f280000(0000) knlGS:0000000000000000
[  +0.000001] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000001] CR2: 000055c14171c078 CR3: 000000010ad90000 CR4: 0000000000f50ef0
[  +0.000001] PKRU: 55555554
[  +0.000001] Call Trace:
[  +0.000001]  <TASK>
[  +0.000001]  ? mei_csi_probe+0x4de/0x520 [ivsc_csi 371b3c493d908e2288ade8575acfa61bc3a0692c]
[  +0.000002]  ? __warn.cold+0x8e/0xe8
[  +0.000003]  ? mei_csi_probe+0x4de/0x520 [ivsc_csi 371b3c493d908e2288ade8575acfa61bc3a0692c]
[  +0.000003]  ? report_bug+0xff/0x140
[  +0.000001]  ? handle_bug+0x3c/0x80
[  +0.000002]  ? exc_invalid_op+0x17/0x70
[  +0.000002]  ? asm_exc_invalid_op+0x1a/0x20
[  +0.000002]  ? mei_csi_probe+0x4de/0x520 [ivsc_csi 371b3c493d908e2288ade8575acfa61bc3a0692c]
[  +0.000002]  ? kmalloc_trace_noprof+0x11c/0x310
[  +0.000002]  ? kernfs_activate+0x82/0xd0
[  +0.000002]  ? kernfs_add_one+0x141/0x150
[  +0.000002]  ? mei_cl_device_probe+0x73/0xc0 [mei fa9908d847451d0c808dbf636c1f12642715f9fa]
[  +0.000008]  mei_cl_device_probe+0x73/0xc0 [mei fa9908d847451d0c808dbf636c1f12642715f9fa]
[  +0.000007]  really_probe+0xdb/0x340
[  +0.000003]  ? pm_runtime_barrier+0x54/0x90
[  +0.000002]  ? __pfx___driver_attach+0x10/0x10
[  +0.000002]  __driver_probe_device+0x78/0x110
[  +0.000002]  driver_probe_device+0x1f/0xa0
[  +0.000002]  __driver_attach+0xba/0x1c0
[  +0.000002]  bus_for_each_dev+0x8c/0xe0
[  +0.000002]  bus_add_driver+0x112/0x1f0
[  +0.000002]  driver_register+0x72/0xd0
[  +0.000002]  __mei_cldev_driver_register+0x2c/0x70 [mei fa9908d847451d0c808dbf636c1f12642715f9fa]
[  +0.000007]  ? __pfx_mei_csi_driver_init+0x10/0x10 [ivsc_csi 371b3c493d908e2288ade8575acfa61bc3a0692c]
[  +0.000002]  ? __pfx_mei_csi_driver_init+0x10/0x10 [ivsc_csi 371b3c493d908e2288ade8575acfa61bc3a0692c]
[  +0.000001]  do_one_initcall+0x58/0x310
[  +0.000003]  do_init_module+0x60/0x220
[  +0.000003]  init_module_from_file+0x89/0xe0
[  +0.000003]  idempotent_init_module+0x121/0x2b0
[  +0.000003]  __x64_sys_finit_module+0x5e/0xb0
[  +0.000002]  do_syscall_64+0x82/0x160
[  +0.000002]  ? syscall_exit_to_user_mode+0x75/0x210
[  +0.000001]  ? do_syscall_64+0x8e/0x160
[  +0.000002]  ? vfs_statx+0x93/0x1c0
[  +0.000002]  ? vfs_fstatat+0x94/0xb0
[  +0.000002]  ? __do_sys_newfstatat+0x3c/0x80
[  +0.000002]  ? __seccomp_filter+0x303/0x520
[  +0.000003]  ? syscall_exit_to_user_mode+0x75/0x210
[  +0.000001]  ? do_syscall_64+0x8e/0x160
[  +0.000000]  ? syscall_exit_to_user_mode+0x75/0x210
[  +0.000002]  ? do_syscall_64+0x8e/0x160
[  +0.000000]  ? syscall_exit_to_user_mode+0x75/0x210
[  +0.000002]  ? do_syscall_64+0x8e/0x160
[  +0.000000]  ? do_syscall_64+0x8e/0x160
[  +0.000001]  ? do_user_addr_fault+0x36c/0x620
[  +0.000002]  ? exc_page_fault+0x7e/0x180
[  +0.000001]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  +0.000003] RIP: 0033:0x7fe412527e9d
[  +0.000023] Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 63 de 0c 00 f7 d8 64 89 01 48
[  +0.000001] RSP: 002b:00007ffd75c4b948 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[  +0.000001] RAX: ffffffffffffffda RBX: 000055c1416918e0 RCX: 00007fe412527e9d
[  +0.000001] RDX: 0000000000000004 RSI: 00007fe4122f6376 RDI: 000000000000001b
[  +0.000001] RBP: 00007fe4122f6376 R08: 0000000000000003 R09: 00007ffd75c4b990
[  +0.000000] R10: 0000000000000007 R11: 0000000000000246 R12: 0000000000020000
[  +0.000001] R13: 000055c141690e00 R14: 0000000000000000 R15: 000055c141718920
[  +0.000002]  </TASK>
[  +0.000000] ---[ end trace 0000000000000000 ]---
[  +0.097576] Key type encrypted registered
[  +0.014989] sof-audio-pci-intel-tgl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
[  +0.000033] sof-audio-pci-intel-tgl 0000:00:1f.3: SoundWire enabled on CannonLake+ platform, using SOF driver
[  +0.000026] sof-audio-pci-intel-tgl 0000:00:1f.3: enabling device (0000 -> 0002)
[  +0.000189] sof-audio-pci-intel-tgl 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if 0x040100
[  +0.011777] raid6: skipped pq benchmark and selected avx2x4
[  +0.000002] raid6: using avx2x2 recovery algorithm
[  +0.004843] xor: automatically using best checksumming function   avx       
[  +0.018700] iwlwifi 0000:00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x20
[  +0.000057] iwlwifi 0000:00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
[  +0.000010] iwlwifi 0000:00:14.3: WFPM_AUTH_KEY_0: 0x90
[  +0.000009] iwlwifi 0000:00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x0
[  +0.000520] iwlwifi 0000:00:14.3: loaded PNVM version ce1a5094
[  +0.001057] iwlwifi 0000:00:14.3: RFIm is deactivated, reason = 4
[  +0.009600] sof-audio-pci-intel-tgl 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[  +0.005602] iwlwifi 0000:00:14.3: Detected RF GF, rfid=0x2010d000
[  +0.004555] sof-audio-pci-intel-tgl 0000:00:1f.3: use msi interrupt mode
[  +0.030543] sof-audio-pci-intel-tgl 0000:00:1f.3: hda codecs found, mask 4
[  +0.003449] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware paths/files for ipc type 0:
[  +0.000002] sof-audio-pci-intel-tgl 0000:00:1f.3:  Firmware file:     intel/sof/sof-rpl.ri
[  +0.000000] sof-audio-pci-intel-tgl 0000:00:1f.3:  Topology file:     intel/sof-tplg/sof-rpl-rt1316-l12-rt714-l0.tplg
[  +0.000358] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 2:2:0-57864
[  +0.000002] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
[  +0.000002] sof-audio-pci-intel-tgl 0000:00:1f.3: unknown sof_ext_man header type 3 size 0x30
[  +0.000993] Btrfs loaded, zoned=yes, fsverity=yes
[  +0.028841] iwlwifi 0000:00:14.3: base HW address: 64:49:7d:93:c9:9d
[  +0.005445] BTRFS: device label home devid 1 transid 527866 /dev/mapper/home (254:0) scanned by mount (975)
[  +0.000360] BTRFS info (device dm-0): first mount of filesystem 813d99a7-9dd7-4485-b757-7834ecb57fc9
[  +0.000022] BTRFS info (device dm-0): using crc32c (crc32c-intel) checksum algorithm
[  +0.000023] BTRFS info (device dm-0): using free-space-tree
[  +0.080053] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware info: version 2:2:0-57864
[  +0.000011] sof-audio-pci-intel-tgl 0000:00:1f.3: Firmware: ABI 3:22:1 Kernel ABI 3:23:0
[  +0.031259] sof-audio-pci-intel-tgl 0000:00:1f.3: Topology: ABI 3:22:1 Kernel ABI 3:23:0
[  +0.000184] sof_sdw sof_sdw: ASoC: Parent card not yet available, widget card binding deferred
[  +0.013174] sof_sdw sof_sdw: hda_dsp_hdmi_build_controls: no PCM in topology for HDMI converter 3
[  +0.026499] input: sof-soundwire HDMI/DP,pcm=5 as /devices/pci0000:00/0000:00:1f.3/sof_sdw/sound/card0/input25
[  +0.000104] input: sof-soundwire HDMI/DP,pcm=6 as /devices/pci0000:00/0000:00:1f.3/sof_sdw/sound/card0/input26
[  +0.000051] input: sof-soundwire HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:1f.3/sof_sdw/sound/card0/input27
[  +0.036509] RPC: Registered named UNIX socket transport module.
[  +0.000002] RPC: Registered udp transport module.
[  +0.000001] RPC: Registered tcp transport module.
[  +0.000000] RPC: Registered tcp-with-tls transport module.
[  +0.000000] RPC: Registered tcp NFSv4.1 backchannel transport module.
[  +0.159368] NET: Registered PF_ALG protocol family
[  +0.011486] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[  +0.000003] Bluetooth: BNEP filters: protocol multicast
[  +0.000003] Bluetooth: BNEP socket layer initialized
[  +0.000669] Bluetooth: MGMT ver 1.22
[  +0.000105] Bluetooth: hci0: offload codecs enable 1 changed 1
[  +0.000022] Bluetooth: ISO socket layer initialized
[  +0.138562] iwlwifi 0000:00:14.3: WRT: Invalid buffer destination
[  +0.155270] pcieport 0000:00:07.0: pciehp: Slot(3): Card present
[  +0.000004] pcieport 0000:00:07.0: pciehp: Slot(3): Link Up
[  +0.000011] iwlwifi 0000:00:14.3: WFPM_UMAC_PD_NOTIFICATION: 0x20
[  +0.000056] iwlwifi 0000:00:14.3: WFPM_LMAC2_PD_NOTIFICATION: 0x1f
[  +0.000009] iwlwifi 0000:00:14.3: WFPM_AUTH_KEY_0: 0x90
[  +0.000008] iwlwifi 0000:00:14.3: CNVI_SCU_SEQ_DATA_DW9: 0x0
[  +0.001590] iwlwifi 0000:00:14.3: RFIm is deactivated, reason = 4
[  +0.094043] iwlwifi 0000:00:14.3: Registered PHC clock: iwlwifi-PTP, with index: 0
[  +0.034779] pci 0000:01:00.0: [8086:0b26] type 01 class 0x060400 PCIe Switch Upstream Port
[  +0.000043] pci 0000:01:00.0: PCI bridge to [bus 00]
[  +0.000011] pci 0000:01:00.0:   bridge window [io  0x0000-0x0fff]
[  +0.000005] pci 0000:01:00.0:   bridge window [mem 0x00000000-0x000fffff]
[  +0.000017] pci 0000:01:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[  +0.000019] pci 0000:01:00.0: enabling Extended Tags
[  +0.000186] pci 0000:01:00.0: supports D1 D2
[  +0.000001] pci 0000:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000142] pci 0000:01:00.0: PTM enabled, 4ns granularity
[  +0.000043] pci 0000:01:00.0: 8.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x4 link at 0000:00:07.0 (capable of 31.504 Gb/s with 8.0 GT/s PCIe x4 link)
[  +0.000229] pci 0000:01:00.0: Adding to iommu group 18
[  +0.000060] pcieport 0000:00:07.0: ASPM: current common clock configuration is inconsistent, reconfiguring
[  +0.002242] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[  +0.000126] pci 0000:02:00.0: [8086:0b26] type 01 class 0x060400 PCIe Switch Downstream Port
[  +0.000038] pci 0000:02:00.0: PCI bridge to [bus 00]
[  +0.000011] pci 0000:02:00.0:   bridge window [io  0x0000-0x0fff]
[  +0.000004] pci 0000:02:00.0:   bridge window [mem 0x00000000-0x000fffff]
[  +0.000017] pci 0000:02:00.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[  +0.000021] pci 0000:02:00.0: enabling Extended Tags
[  +0.000176] pci 0000:02:00.0: supports D1 D2
[  +0.000001] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000310] pci 0000:02:00.0: Adding to iommu group 19
[  +0.000084] pci 0000:02:01.0: [8086:0b26] type 01 class 0x060400 PCIe Switch Downstream Port
[  +0.000038] pci 0000:02:01.0: PCI bridge to [bus 00]
[  +0.000009] pci 0000:02:01.0:   bridge window [io  0x0000-0x0fff]
[  +0.000004] pci 0000:02:01.0:   bridge window [mem 0x00000000-0x000fffff]
[  +0.000016] pci 0000:02:01.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[  +0.000021] pci 0000:02:01.0: enabling Extended Tags
[  +0.000172] pci 0000:02:01.0: supports D1 D2
[  +0.000000] pci 0000:02:01.0: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000287] pci 0000:02:01.0: Adding to iommu group 20
[  +0.000073] pci 0000:02:02.0: [8086:0b26] type 01 class 0x060400 PCIe Switch Downstream Port
[  +0.000038] pci 0000:02:02.0: PCI bridge to [bus 00]
[  +0.000009] pci 0000:02:02.0:   bridge window [io  0x0000-0x0fff]
[  +0.000004] pci 0000:02:02.0:   bridge window [mem 0x00000000-0x000fffff]
[  +0.000016] pci 0000:02:02.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[  +0.000020] pci 0000:02:02.0: enabling Extended Tags
[  +0.000167] pci 0000:02:02.0: supports D1 D2
[  +0.000000] pci 0000:02:02.0: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000276] pci 0000:02:02.0: Adding to iommu group 21
[  +0.000082] pci 0000:02:03.0: [8086:0b26] type 01 class 0x060400 PCIe Switch Downstream Port
[  +0.000037] pci 0000:02:03.0: PCI bridge to [bus 00]
[  +0.000009] pci 0000:02:03.0:   bridge window [io  0x0000-0x0fff]
[  +0.000004] pci 0000:02:03.0:   bridge window [mem 0x00000000-0x000fffff]
[  +0.000016] pci 0000:02:03.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[  +0.000021] pci 0000:02:03.0: enabling Extended Tags
[  +0.000166] pci 0000:02:03.0: supports D1 D2
[  +0.000001] pci 0000:02:03.0: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000312] pci 0000:02:03.0: Adding to iommu group 22
[  +0.000071] pci 0000:02:04.0: [8086:0b26] type 01 class 0x060400 PCIe Switch Downstream Port
[  +0.000038] pci 0000:02:04.0: PCI bridge to [bus 00]
[  +0.000009] pci 0000:02:04.0:   bridge window [io  0x0000-0x0fff]
[  +0.000004] pci 0000:02:04.0:   bridge window [mem 0x00000000-0x000fffff]
[  +0.000016] pci 0000:02:04.0:   bridge window [mem 0x00000000-0x000fffff 64bit pref]
[  +0.000020] pci 0000:02:04.0: enabling Extended Tags
[  +0.000165] pci 0000:02:04.0: supports D1 D2
[  +0.000000] pci 0000:02:04.0: PME# supported from D0 D1 D2 D3hot D3cold
[  +0.000292] pci 0000:02:04.0: Adding to iommu group 23
[  +0.000088] pci 0000:01:00.0: PCI bridge to [bus 02-3f]
[  +0.000019] pci 0000:02:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[  +0.000012] pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[  +0.000010] pci 0000:02:02.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[  +0.000011] pci 0000:02:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[  +0.000011] pci 0000:02:04.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[  +0.000081] pci 0000:02:00.0: PCI bridge to [bus 03-3f]
[  +0.000018] pci_bus 0000:03: busn_res: [bus 03-3f] end is updated to 03
[  +0.000071] pci 0000:02:01.0: PCI bridge to [bus 04-3f]
[  +0.000018] pci_bus 0000:04: busn_res: [bus 04-3f] end is updated to 17
[  +0.000085] pci 0000:02:02.0: PCI bridge to [bus 18-3f]
[  +0.000018] pci_bus 0000:18: busn_res: [bus 18-3f] end is updated to 2b
[  +0.000071] pci 0000:02:03.0: PCI bridge to [bus 2c-3f]
[  +0.000017] pci_bus 0000:2c: busn_res: [bus 2c-3f] end is updated to 3e
[  +0.000079] pci 0000:02:04.0: PCI bridge to [bus 3f]
[  +0.000018] pci_bus 0000:3f: busn_res: [bus 3f] end is updated to 3f
[  +0.000006] pci_bus 0000:02: busn_res: [bus 02-3f] end is updated to 3f
[  +0.000007] pci 0000:02:01.0: bridge window [mem 0x00100000-0x001fffff 64bit pref] to [bus 04-17] add_size 100000 add_align 100000
[  +0.000001] pci 0000:02:01.0: bridge window [mem 0x00100000-0x001fffff] to [bus 04-17] add_size 100000 add_align 100000
[  +0.000001] pci 0000:02:02.0: bridge window [mem 0x00100000-0x001fffff 64bit pref] to [bus 18-2b] add_size 100000 add_align 100000
[  +0.000002] pci 0000:02:02.0: bridge window [mem 0x00100000-0x001fffff] to [bus 18-2b] add_size 100000 add_align 100000
[  +0.000001] pci 0000:02:03.0: bridge window [mem 0x00100000-0x001fffff 64bit pref] to [bus 2c-3e] add_size 100000 add_align 100000
[  +0.000001] pci 0000:02:03.0: bridge window [mem 0x00100000-0x001fffff] to [bus 2c-3e] add_size 100000 add_align 100000
[  +0.000001] pci 0000:01:00.0: bridge window [mem 0x00100000-0x005fffff 64bit pref] to [bus 02-3f] add_size 300000 add_align 100000
[  +0.000002] pci 0000:01:00.0: bridge window [mem 0x00100000-0x005fffff] to [bus 02-3f] add_size 300000 add_align 100000
[  +0.000004] pci 0000:01:00.0: bridge window [mem 0x82000000-0x8e1fffff]: assigned
[  +0.000001] pci 0000:01:00.0: bridge window [mem 0x6000000000-0x601bffffff 64bit pref]: assigned
[  +0.000001] pci 0000:01:00.0: bridge window [io  size 0x5000]: can't assign; no space
[  +0.000001] pci 0000:01:00.0: bridge window [io  size 0x5000]: failed to assign
[  +0.000002] pci 0000:02:00.0: bridge window [mem 0x82000000-0x820fffff]: assigned
[  +0.000001] pci 0000:02:00.0: bridge window [mem 0x6000000000-0x60000fffff 64bit pref]: assigned
[  +0.000001] pci 0000:02:01.0: bridge window [mem 0x82100000-0x860fffff]: assigned
[  +0.000001] pci 0000:02:01.0: bridge window [mem 0x6000100000-0x60094fffff 64bit pref]: assigned
[  +0.000001] pci 0000:02:02.0: bridge window [mem 0x86100000-0x8a0fffff]: assigned
[  +0.000001] pci 0000:02:02.0: bridge window [mem 0x6009500000-0x60128fffff 64bit pref]: assigned
[  +0.000000] pci 0000:02:03.0: bridge window [mem 0x8a100000-0x8e0fffff]: assigned
[  +0.000001] pci 0000:02:03.0: bridge window [mem 0x6012900000-0x601bcfffff 64bit pref]: assigned
[  +0.000001] pci 0000:02:04.0: bridge window [mem 0x8e100000-0x8e1fffff]: assigned
[  +0.000001] pci 0000:02:04.0: bridge window [mem 0x601bd00000-0x601bdfffff 64bit pref]: assigned
[  +0.000000] pci 0000:02:00.0: bridge window [io  size 0x1000]: can't assign; no space
[  +0.000001] pci 0000:02:00.0: bridge window [io  size 0x1000]: failed to assign
[  +0.000001] pci 0000:02:01.0: bridge window [io  size 0x1000]: can't assign; no space
[  +0.000000] pci 0000:02:01.0: bridge window [io  size 0x1000]: failed to assign
[  +0.000001] pci 0000:02:02.0: bridge window [io  size 0x1000]: can't assign; no space
[  +0.000001] pci 0000:02:02.0: bridge window [io  size 0x1000]: failed to assign
[  +0.000000] pci 0000:02:03.0: bridge window [io  size 0x1000]: can't assign; no space
[  +0.000001] pci 0000:02:03.0: bridge window [io  size 0x1000]: failed to assign
[  +0.000001] pci 0000:02:04.0: bridge window [io  size 0x1000]: can't assign; no space
[  +0.000000] pci 0000:02:04.0: bridge window [io  size 0x1000]: failed to assign
[  +0.000002] pci 0000:02:00.0: PCI bridge to [bus 03]
[  +0.000005] pci 0000:02:00.0:   bridge window [mem 0x82000000-0x820fffff]
[  +0.000004] pci 0000:02:00.0:   bridge window [mem 0x6000000000-0x60000fffff 64bit pref]
[  +0.000008] pci 0000:02:01.0: PCI bridge to [bus 04-17]
[  +0.000006] pci 0000:02:01.0:   bridge window [mem 0x82100000-0x860fffff]
[  +0.000004] pci 0000:02:01.0:   bridge window [mem 0x6000100000-0x60094fffff 64bit pref]
[  +0.000007] pci 0000:02:02.0: PCI bridge to [bus 18-2b]
[  +0.000006] pci 0000:02:02.0:   bridge window [mem 0x86100000-0x8a0fffff]
[  +0.000004] pci 0000:02:02.0:   bridge window [mem 0x6009500000-0x60128fffff 64bit pref]
[  +0.000007] pci 0000:02:03.0: PCI bridge to [bus 2c-3e]
[  +0.000006] pci 0000:02:03.0:   bridge window [mem 0x8a100000-0x8e0fffff]
[  +0.000004] pci 0000:02:03.0:   bridge window [mem 0x6012900000-0x601bcfffff 64bit pref]
[  +0.000011] pci 0000:02:04.0: PCI bridge to [bus 3f]
[  +0.000006] pci 0000:02:04.0:   bridge window [mem 0x8e100000-0x8e1fffff]
[  +0.000004] pci 0000:02:04.0:   bridge window [mem 0x601bd00000-0x601bdfffff 64bit pref]
[  +0.000007] pci 0000:01:00.0: PCI bridge to [bus 02-3f]
[  +0.000006] pci 0000:01:00.0:   bridge window [mem 0x82000000-0x8e1fffff]
[  +0.000004] pci 0000:01:00.0:   bridge window [mem 0x6000000000-0x601bffffff 64bit pref]
[  +0.000007] pcieport 0000:00:07.0: PCI bridge to [bus 01-3f]
[  +0.000001] pcieport 0000:00:07.0:   bridge window [io  0x4000-0x7fff]
[  +0.000003] pcieport 0000:00:07.0:   bridge window [mem 0x82000000-0x8e1fffff]
[  +0.000002] pcieport 0000:00:07.0:   bridge window [mem 0x6000000000-0x601bffffff 64bit pref]
[  +0.000003] PCI: No. 2 try to assign unassigned res
[  +0.000002] pcieport 0000:00:07.0: resource 13 [io  0x4000-0x7fff] released
[  +0.000001] pcieport 0000:00:07.0: PCI bridge to [bus 01-3f]
[  +0.000005] pcieport 0000:00:07.0: bridge window [io  0x9000-0xdfff]: assigned
[  +0.000001] pci 0000:01:00.0: bridge window [io  0x9000-0xdfff]: assigned
[  +0.000002] pci 0000:02:00.0: bridge window [io  0x9000-0x9fff]: assigned
[  +0.000000] pci 0000:02:01.0: bridge window [io  0xa000-0xafff]: assigned
[  +0.000001] pci 0000:02:02.0: bridge window [io  0xb000-0xbfff]: assigned
[  +0.000001] pci 0000:02:03.0: bridge window [io  0xc000-0xcfff]: assigned
[  +0.000001] pci 0000:02:04.0: bridge window [io  0xd000-0xdfff]: assigned
[  +0.000000] pci 0000:02:00.0: PCI bridge to [bus 03]
[  +0.000003] pci 0000:02:00.0:   bridge window [io  0x9000-0x9fff]
[  +0.000005] pci 0000:02:00.0:   bridge window [mem 0x82000000-0x820fffff]
[  +0.000004] pci 0000:02:00.0:   bridge window [mem 0x6000000000-0x60000fffff 64bit pref]
[  +0.000008] pci 0000:02:01.0: PCI bridge to [bus 04-17]
[  +0.000002] pci 0000:02:01.0:   bridge window [io  0xa000-0xafff]
[  +0.000006] pci 0000:02:01.0:   bridge window [mem 0x82100000-0x860fffff]
[  +0.000004] pci 0000:02:01.0:   bridge window [mem 0x6000100000-0x60094fffff 64bit pref]
[  +0.000007] pci 0000:02:02.0: PCI bridge to [bus 18-2b]
[  +0.000002] pci 0000:02:02.0:   bridge window [io  0xb000-0xbfff]
[  +0.000006] pci 0000:02:02.0:   bridge window [mem 0x86100000-0x8a0fffff]
[  +0.000004] pci 0000:02:02.0:   bridge window [mem 0x6009500000-0x60128fffff 64bit pref]
[  +0.000007] pci 0000:02:03.0: PCI bridge to [bus 2c-3e]
[  +0.000002] pci 0000:02:03.0:   bridge window [io  0xc000-0xcfff]
[  +0.000006] pci 0000:02:03.0:   bridge window [mem 0x8a100000-0x8e0fffff]
[  +0.000004] pci 0000:02:03.0:   bridge window [mem 0x6012900000-0x601bcfffff 64bit pref]
[  +0.000007] pci 0000:02:04.0: PCI bridge to [bus 3f]
[  +0.000003] pci 0000:02:04.0:   bridge window [io  0xd000-0xdfff]
[  +0.000005] pci 0000:02:04.0:   bridge window [mem 0x8e100000-0x8e1fffff]
[  +0.000004] pci 0000:02:04.0:   bridge window [mem 0x601bd00000-0x601bdfffff 64bit pref]
[  +0.000008] pci 0000:01:00.0: PCI bridge to [bus 02-3f]
[  +0.000002] pci 0000:01:00.0:   bridge window [io  0x9000-0xdfff]
[  +0.000006] pci 0000:01:00.0:   bridge window [mem 0x82000000-0x8e1fffff]
[  +0.000003] pci 0000:01:00.0:   bridge window [mem 0x6000000000-0x601bffffff 64bit pref]
[  +0.000008] pcieport 0000:00:07.0: PCI bridge to [bus 01-3f]
[  +0.000001] pcieport 0000:00:07.0:   bridge window [io  0x9000-0xdfff]
[  +0.000002] pcieport 0000:00:07.0:   bridge window [mem 0x82000000-0x8e1fffff]
[  +0.000002] pcieport 0000:00:07.0:   bridge window [mem 0x6000000000-0x601bffffff 64bit pref]
[  +0.000128] pcieport 0000:01:00.0: enabling device (0000 -> 0003)
[  +0.000210] pcieport 0000:02:00.0: enabling device (0000 -> 0003)
[  +0.001075] pcieport 0000:02:01.0: enabling device (0000 -> 0003)
[  +0.000144] pcieport 0000:02:01.0: pciehp: Slot #1 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
[  +0.000305] pcieport 0000:02:02.0: enabling device (0000 -> 0003)
[  +0.000184] pcieport 0000:02:02.0: pciehp: Slot #2 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
[  +0.000205] pcieport 0000:02:03.0: enabling device (0000 -> 0003)
[  +0.000197] pcieport 0000:02:03.0: pciehp: Slot #3 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl+ IbPresDis- LLActRep+
[  +0.000186] pcieport 0000:02:04.0: enabling device (0000 -> 0003)
[  +1.222723] rfkill: input handler disabled
[  +0.089041] wlan0: authenticate with 78:d2:94:be:cb:47 (local address=64:49:7d:93:c9:9d)
[  +0.001157] wlan0: send auth to 78:d2:94:be:cb:47 (try 1/3)
[  +0.045315] wlan0: authenticated
[  +0.000934] wlan0: associate with 78:d2:94:be:cb:47 (try 1/3)
[  +0.002397] wlan0: RX AssocResp from 78:d2:94:be:cb:47 (capab=0x11 status=0 aid=2)
[  +0.011658] wlan0: associated
[  +0.137589] Bluetooth: RFCOMM TTY layer initialized
[  +0.000007] Bluetooth: RFCOMM socket layer initialized
[  +0.000002] Bluetooth: RFCOMM ver 1.11
[May27 07:46] mei intel_vsc-5db76cf6-0a68-4ed6-9b78-0361635e2447: deferred probe pending: (reason unknown)
[  +9.486041] input: MX Anywhere 3B Mouse as /devices/virtual/misc/uhid/0005:046D:B02D.000B/input/input28
[  +0.000642] hid-generic 0005:046D:B02D.000B: input,hidraw7: BLUETOOTH HID v0.11 Mouse [MX Anywhere 3B] on 64:49:7d:93:c9:a1
[  +4.306652] input: MX MCHNCL M Keyboard as /devices/virtual/misc/uhid/0005:046D:B367.000C/input/input30
[  +0.001211] hid-generic 0005:046D:B367.000C: input,hidraw8: BLUETOOTH HID v0.11 Keyboard [MX MCHNCL M] on 64:49:7d:93:c9:a1
[  +8.819861] rfkill: input handler enabled
[  +1.182346] block nvme0n1: No UUID available providing old NGUID
[  +0.058552] rfkill: input handler disabled
[May27 07:49] warning: `ThreadPoolForeg' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211
[May27 08:38] block nvme0n1: the capability attribute has been deprecated.
[May27 11:26] systemd-sslh-generator: Configuration directory '/etc/sslh/' does not exist! No units generated.
[  +0.395639] BTRFS info: devid 1 device path /dev/mapper/home changed to /dev/dm-0 scanned by (udev-worker) (21342)
[  +0.000870] BTRFS info: devid 1 device path /dev/dm-0 changed to /dev/mapper/home scanned by (udev-worker) (21342)
[May27 12:41] BTRFS info: devid 1 device path /dev/mapper/home changed to /dev/dm-0 scanned by (udev-worker) (42682)
[  +0.000932] BTRFS info: devid 1 device path /dev/dm-0 changed to /dev/mapper/home scanned by (udev-worker) (42682)
[May27 14:37] perf: interrupt took too long (2519 > 2500), lowering kernel.perf_event_max_sample_rate to 79000

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[relevance 1%]

* [PATCH v10 01/19] ACPI: processor: Simplify initial onlining to use same path for cold and hotplug
  2024-05-29 13:34  2% ` Jonathan Cameron
@ 2024-05-29 13:34  2%   ` Jonathan Cameron
  -1 siblings, 0 replies; 200+ results
From: Jonathan Cameron @ 2024-05-29 13:34 UTC (permalink / raw)
  To: Marc Zyngier, Will Deacon, Catalin Marinas, linux-acpi,
	linux-arch, linux-kernel, linux-arm-kernel, linux-pm
  Cc: Mark Rutland, Thomas Gleixner, Peter Zijlstra, loongarch, x86,
	Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
	Salil Mehta, Jean-Philippe Brucker, Hanjun Guo, Gavin Shan,
	Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm, justin.he,
	jianyong.wu

Separate code paths, combined with a flag set in acpi_processor.c to
indicate a struct acpi_processor was for a hotplugged CPU ensured that
per CPU data was only set up the first time that a CPU was initialized.
This appears to be unnecessary as the paths can be combined by letting
the online logic also handle any CPUs online at the time of driver load.

Motivation for this change, beyond simplification, is that ARM64
virtual CPU HP uses the same code paths for hotplug and cold path in
acpi_processor.c so had no easy way to set the flag for hotplug only.
Removing this necessity will enable ARM64 vCPU HP to reuse the existing
code paths.

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Miguel Luis <miguel.luis@oracle.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/acpi/acpi_processor.c   |  7 +++---
 drivers/acpi/processor_driver.c | 43 +++++++++------------------------
 include/acpi/processor.h        |  2 +-
 3 files changed, 16 insertions(+), 36 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 7a0dd35d62c9..b2f0b6c19482 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -211,12 +211,11 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
 	}
 
 	/*
-	 * CPU got hot-added, but cpu_data is not initialized yet.  Set a flag
-	 * to delay cpu_idle/throttling initialization and do it when the CPU
-	 * gets online for the first time.
+	 * CPU got hot-added, but cpu_data is not initialized yet. Do
+	 * cpu_idle/throttling initialization when the CPU gets online for
+	 * the first time.
 	 */
 	pr_info("CPU%d has been hot-added\n", pr->id);
-	pr->flags.need_hotplug_init = 1;
 
 out:
 	cpus_write_unlock();
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 67db60eda370..cb52dd000b95 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -33,7 +33,6 @@ MODULE_AUTHOR("Paul Diefenbaugh");
 MODULE_DESCRIPTION("ACPI Processor Driver");
 MODULE_LICENSE("GPL");
 
-static int acpi_processor_start(struct device *dev);
 static int acpi_processor_stop(struct device *dev);
 
 static const struct acpi_device_id processor_device_ids[] = {
@@ -47,7 +46,6 @@ static struct device_driver acpi_processor_driver = {
 	.name = "processor",
 	.bus = &cpu_subsys,
 	.acpi_match_table = processor_device_ids,
-	.probe = acpi_processor_start,
 	.remove = acpi_processor_stop,
 };
 
@@ -115,12 +113,9 @@ static int acpi_soft_cpu_online(unsigned int cpu)
 	 * CPU got physically hotplugged and onlined for the first time:
 	 * Initialize missing things.
 	 */
-	if (pr->flags.need_hotplug_init) {
+	if (!pr->flags.previously_online) {
 		int ret;
 
-		pr_info("Will online and init hotplugged CPU: %d\n",
-			pr->id);
-		pr->flags.need_hotplug_init = 0;
 		ret = __acpi_processor_start(device);
 		WARN(ret, "Failed to start CPU: %d\n", pr->id);
 	} else {
@@ -167,9 +162,6 @@ static int __acpi_processor_start(struct acpi_device *device)
 	if (!pr)
 		return -ENODEV;
 
-	if (pr->flags.need_hotplug_init)
-		return 0;
-
 	result = acpi_cppc_processor_probe(pr);
 	if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FREQ_PSS))
 		dev_dbg(&device->dev, "CPPC data invalid or not present\n");
@@ -185,32 +177,21 @@ static int __acpi_processor_start(struct acpi_device *device)
 
 	status = acpi_install_notify_handler(device->handle, ACPI_DEVICE_NOTIFY,
 					     acpi_processor_notify, device);
-	if (ACPI_SUCCESS(status))
-		return 0;
+	if (!ACPI_SUCCESS(status)) {
+		result = -ENODEV;
+		goto err_thermal_exit;
+	}
+	pr->flags.previously_online = 1;
 
-	result = -ENODEV;
-	acpi_processor_thermal_exit(pr, device);
+	return 0;
 
+err_thermal_exit:
+	acpi_processor_thermal_exit(pr, device);
 err_power_exit:
 	acpi_processor_power_exit(pr);
 	return result;
 }
 
-static int acpi_processor_start(struct device *dev)
-{
-	struct acpi_device *device = ACPI_COMPANION(dev);
-	int ret;
-
-	if (!device)
-		return -ENODEV;
-
-	/* Protect against concurrent CPU hotplug operations */
-	cpu_hotplug_disable();
-	ret = __acpi_processor_start(device);
-	cpu_hotplug_enable();
-	return ret;
-}
-
 static int acpi_processor_stop(struct device *dev)
 {
 	struct acpi_device *device = ACPI_COMPANION(dev);
@@ -279,9 +260,9 @@ static int __init acpi_processor_driver_init(void)
 	if (result < 0)
 		return result;
 
-	result = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
-					   "acpi/cpu-drv:online",
-					   acpi_soft_cpu_online, NULL);
+	result = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
+				   "acpi/cpu-drv:online",
+				   acpi_soft_cpu_online, NULL);
 	if (result < 0)
 		goto err;
 	hp_online = result;
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index 3f34ebb27525..e6f6074eadbf 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -217,7 +217,7 @@ struct acpi_processor_flags {
 	u8 has_lpi:1;
 	u8 power_setup_done:1;
 	u8 bm_rld_set:1;
-	u8 need_hotplug_init:1;
+	u8 previously_online:1;
 };
 
 struct acpi_processor {
-- 
2.39.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 2%]

* Re: [PATCH for-4.19 3/9] xen/cpu: ensure get_cpu_maps() returns false if CPU operations are underway
  @ 2024-05-29 13:35  0%   ` Jan Beulich
  0 siblings, 0 replies; 200+ results
From: Jan Beulich @ 2024-05-29 13:35 UTC (permalink / raw)
  To: Roger Pau Monne
  Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
	xen-devel

On 29.05.2024 11:01, Roger Pau Monne wrote:
> Due to the current rwlock logic, if the CPU calling get_cpu_maps() does so from
> a cpu_hotplug_{begin,done}() region the function will still return success,
> because a CPU taking the rwlock in read mode after having taken it in write
> mode is allowed.  Such behavior however defeats the purpose of get_cpu_maps(),
> as it should always return false when called with a CPU hot{,un}plug operation
> is in progress.

I'm not sure I can agree with this. The CPU doing said operation ought to be
aware of what it is itself doing. And all other CPUs will get back false from
get_cpu_maps().

>  Otherwise the logic in send_IPI_mask() for example is wrong,
> as it could decide to use the shorthand even when a CPU operation is in
> progress.

It's also not becoming clear what's wrong there: As long as a CPU isn't
offline enough to not be in cpu_online_map anymore, it may well need to still
be the target of IPIs, and targeting it with a shorthand then is still fine.

In any event this would again affect only the CPU leading the CPU operation,
which should clearly know at which point(s) it is okay to send IPIs. Are we
actually sending any IPIs from within CPU-online or CPU-offline paths?
Together with the earlier paragraph the critical window would be between the
CPU being taken off of cpu_online_map and the CPU actually going "dead" (i.e.
on x86: its LAPIC becoming unresponsive to other than INIT/SIPI). And even
then the question would be what bad, if any, would happen to that CPU if an
IPI was still targeted at it by way of using the shorthand. I'm pretty sure
it runs with IRQs off at that time, so no ordinary IRQ could be delivered.

> Adjust the logic in get_cpu_maps() to return false when the CPUs lock is
> already hold in write mode by the current CPU, as read_trylock() would
> otherwise return true.
> 
> Fixes: 868a01021c6f ('rwlock: allow recursive read locking when already locked in write mode')

I'm puzzled by this as well: Prior to that and the change referenced by its
Fixes: tag, recursive spin locks were used. For the purposes here that's the
same as permitting read locking even when the write lock is already held by
the local CPU.

Jan


^ permalink raw reply	[relevance 0%]

* [PATCH v10 01/19] ACPI: processor: Simplify initial onlining to use same path for cold and hotplug
@ 2024-05-29 13:34  2%   ` Jonathan Cameron
  0 siblings, 0 replies; 200+ results
From: Jonathan Cameron @ 2024-05-29 13:34 UTC (permalink / raw)
  To: Marc Zyngier, Will Deacon, Catalin Marinas, linux-acpi,
	linux-arch, linux-kernel, linux-arm-kernel, linux-pm
  Cc: Mark Rutland, Thomas Gleixner, Peter Zijlstra, loongarch, x86,
	Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
	Salil Mehta, Jean-Philippe Brucker, Hanjun Guo, Gavin Shan,
	Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm, justin.he,
	jianyong.wu

Separate code paths, combined with a flag set in acpi_processor.c to
indicate a struct acpi_processor was for a hotplugged CPU ensured that
per CPU data was only set up the first time that a CPU was initialized.
This appears to be unnecessary as the paths can be combined by letting
the online logic also handle any CPUs online at the time of driver load.

Motivation for this change, beyond simplification, is that ARM64
virtual CPU HP uses the same code paths for hotplug and cold path in
acpi_processor.c so had no easy way to set the flag for hotplug only.
Removing this necessity will enable ARM64 vCPU HP to reuse the existing
code paths.

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Tested-by: Miguel Luis <miguel.luis@oracle.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Miguel Luis <miguel.luis@oracle.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
---
 drivers/acpi/acpi_processor.c   |  7 +++---
 drivers/acpi/processor_driver.c | 43 +++++++++------------------------
 include/acpi/processor.h        |  2 +-
 3 files changed, 16 insertions(+), 36 deletions(-)

diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c
index 7a0dd35d62c9..b2f0b6c19482 100644
--- a/drivers/acpi/acpi_processor.c
+++ b/drivers/acpi/acpi_processor.c
@@ -211,12 +211,11 @@ static int acpi_processor_hotadd_init(struct acpi_processor *pr)
 	}
 
 	/*
-	 * CPU got hot-added, but cpu_data is not initialized yet.  Set a flag
-	 * to delay cpu_idle/throttling initialization and do it when the CPU
-	 * gets online for the first time.
+	 * CPU got hot-added, but cpu_data is not initialized yet. Do
+	 * cpu_idle/throttling initialization when the CPU gets online for
+	 * the first time.
 	 */
 	pr_info("CPU%d has been hot-added\n", pr->id);
-	pr->flags.need_hotplug_init = 1;
 
 out:
 	cpus_write_unlock();
diff --git a/drivers/acpi/processor_driver.c b/drivers/acpi/processor_driver.c
index 67db60eda370..cb52dd000b95 100644
--- a/drivers/acpi/processor_driver.c
+++ b/drivers/acpi/processor_driver.c
@@ -33,7 +33,6 @@ MODULE_AUTHOR("Paul Diefenbaugh");
 MODULE_DESCRIPTION("ACPI Processor Driver");
 MODULE_LICENSE("GPL");
 
-static int acpi_processor_start(struct device *dev);
 static int acpi_processor_stop(struct device *dev);
 
 static const struct acpi_device_id processor_device_ids[] = {
@@ -47,7 +46,6 @@ static struct device_driver acpi_processor_driver = {
 	.name = "processor",
 	.bus = &cpu_subsys,
 	.acpi_match_table = processor_device_ids,
-	.probe = acpi_processor_start,
 	.remove = acpi_processor_stop,
 };
 
@@ -115,12 +113,9 @@ static int acpi_soft_cpu_online(unsigned int cpu)
 	 * CPU got physically hotplugged and onlined for the first time:
 	 * Initialize missing things.
 	 */
-	if (pr->flags.need_hotplug_init) {
+	if (!pr->flags.previously_online) {
 		int ret;
 
-		pr_info("Will online and init hotplugged CPU: %d\n",
-			pr->id);
-		pr->flags.need_hotplug_init = 0;
 		ret = __acpi_processor_start(device);
 		WARN(ret, "Failed to start CPU: %d\n", pr->id);
 	} else {
@@ -167,9 +162,6 @@ static int __acpi_processor_start(struct acpi_device *device)
 	if (!pr)
 		return -ENODEV;
 
-	if (pr->flags.need_hotplug_init)
-		return 0;
-
 	result = acpi_cppc_processor_probe(pr);
 	if (result && !IS_ENABLED(CONFIG_ACPI_CPU_FREQ_PSS))
 		dev_dbg(&device->dev, "CPPC data invalid or not present\n");
@@ -185,32 +177,21 @@ static int __acpi_processor_start(struct acpi_device *device)
 
 	status = acpi_install_notify_handler(device->handle, ACPI_DEVICE_NOTIFY,
 					     acpi_processor_notify, device);
-	if (ACPI_SUCCESS(status))
-		return 0;
+	if (!ACPI_SUCCESS(status)) {
+		result = -ENODEV;
+		goto err_thermal_exit;
+	}
+	pr->flags.previously_online = 1;
 
-	result = -ENODEV;
-	acpi_processor_thermal_exit(pr, device);
+	return 0;
 
+err_thermal_exit:
+	acpi_processor_thermal_exit(pr, device);
 err_power_exit:
 	acpi_processor_power_exit(pr);
 	return result;
 }
 
-static int acpi_processor_start(struct device *dev)
-{
-	struct acpi_device *device = ACPI_COMPANION(dev);
-	int ret;
-
-	if (!device)
-		return -ENODEV;
-
-	/* Protect against concurrent CPU hotplug operations */
-	cpu_hotplug_disable();
-	ret = __acpi_processor_start(device);
-	cpu_hotplug_enable();
-	return ret;
-}
-
 static int acpi_processor_stop(struct device *dev)
 {
 	struct acpi_device *device = ACPI_COMPANION(dev);
@@ -279,9 +260,9 @@ static int __init acpi_processor_driver_init(void)
 	if (result < 0)
 		return result;
 
-	result = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
-					   "acpi/cpu-drv:online",
-					   acpi_soft_cpu_online, NULL);
+	result = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
+				   "acpi/cpu-drv:online",
+				   acpi_soft_cpu_online, NULL);
 	if (result < 0)
 		goto err;
 	hp_online = result;
diff --git a/include/acpi/processor.h b/include/acpi/processor.h
index 3f34ebb27525..e6f6074eadbf 100644
--- a/include/acpi/processor.h
+++ b/include/acpi/processor.h
@@ -217,7 +217,7 @@ struct acpi_processor_flags {
 	u8 has_lpi:1;
 	u8 power_setup_done:1;
 	u8 bm_rld_set:1;
-	u8 need_hotplug_init:1;
+	u8 previously_online:1;
 };
 
 struct acpi_processor {
-- 
2.39.2


^ permalink raw reply related	[relevance 2%]

* [PATCH v10 00/19] ACPI/arm64: add support for virtual cpu hotplug
@ 2024-05-29 13:34  2% ` Jonathan Cameron
  0 siblings, 0 replies; 200+ results
From: Jonathan Cameron @ 2024-05-29 13:34 UTC (permalink / raw)
  To: Marc Zyngier, Will Deacon, Catalin Marinas, linux-acpi,
	linux-arch, linux-kernel, linux-arm-kernel, linux-pm
  Cc: Mark Rutland, Thomas Gleixner, Peter Zijlstra, loongarch, x86,
	Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
	Salil Mehta, Jean-Philippe Brucker, Hanjun Guo, Gavin Shan,
	Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm, justin.he,
	jianyong.wu

v10:
- Make acpi_processor_set_per_cpu() return 0 / error rather than bool
  to simplify error handling at the call sites.
  (Thanks to both Rafael and Gavin who commented on this)
- Gather tags.
- Rebase on v6.10-rc1

The approach to the GICv3 changes stablized very late in the 6.10 cycle.
Subject to Marc taking a final look at those, I think we are now
in a good state wrt to those and the ACPI parts. The remaining code
that hasn't received review tags from the relevant maintainers
is the arm64 specific arch_register_cpu().  Given I think this will go
through the arm64 tree, hopefully they have just been waiting for
everything else to be ready.

It is only arch specific to the extent that Rafael suggested we limit
the potential impacts of the deferred calling of these functions
to be isolated to ARM64 for now.  This is done by having them return
-EPROBE_DEFER, on ACPI systems, until the ACPI interpreter is
available and can be used to query _STA.

Thanks to everyone who has been involved in development, testing and
review of this series - the complex tag chains reflect some of that.
Fingers crossed we are approaching the end of this particular saga.

Updated version of James' original introduction.

This series adds what looks like cpuhotplug support to arm64 for use in
virtual machines. It does this by moving the cpu_register() calls for
architectures that support ACPI into an arch specific call made from
the ACPI processor driver.
 
The kubernetes folk really want to be able to add CPUs to an existing VM,
in exactly the same way they do on x86. The use-case is pre-booting guests
with one CPU, then adding the number that were actually needed when the
workload is provisioned.

Wait? Doesn't arm64 support cpuhotplug already!?
In the arm world, cpuhotplug gets used to mean removing the power from a CPU.
The CPU is offline, and remains present. For x86, and ACPI, cpuhotplug
has the additional step of physically removing the CPU, so that it isn't
present anymore.
 
Arm64 doesn't support this, and can't support it: CPUs are really a slice
of the SoC, and there is not enough information in the existing ACPI tables
to describe which bits of the slice also got removed. Without a reference
machine: adding this support to the spec is a wild goose chase.
 
Critically: everything described in the firmware tables must remain present.
 
For a virtual machine this is easy as all the other bits of 'virtual SoC'
are emulated, so they can (and do) remain present when a vCPU is 'removed'.

On a system that supports cpuhotplug the MADT has to describe every possible
CPU at boot. Under KVM, the vGIC needs to know about every possible vCPU before
the guest is started.
With these constraints, virtual-cpuhotplug is really just a hypervisor/firmware
policy about which CPUs can be brought online.
 
This series adds support for virtual-cpuhotplug as exactly that: firmware
policy. This may even work on a physical machine too; for a guest the part of
firmware is played by the VMM. (typically Qemu).
 
PSCI support is modified to return 'DENIED' if the CPU can't be brought
online/enabled yet. The CPU object's _STA method's enabled bit is used to
indicate firmware's current disposition. If the CPU has its enabled bit clear,
it will not be registered with sysfs, and attempts to bring it online will
fail. The notifications that _STA has changed its value then work in the same
way as physical hotplug, and firmware can cause the CPU to be registered some
time later, allowing it to be brought online.
 
This creates something that looks like cpuhotplug to user-space and the
kernel beyond arm64 architecture specific code, as the sysfs
files appear and disappear, and the udev notifications look the same.
 
One notable difference is the CPU present mask, which is exposed via sysfs.
Because the CPUs remain present throughout, they can still be seen in that mask.
This value does get used by webbrowsers to estimate the number of CPUs
as the CPU online mask is constantly changed on mobile phones.
 
Linux is tolerant of PSCI returning errors, as its always been allowed to do
that. To avoid confusing OS that can't tolerate this, we needed an additional
bit in the MADT GICC flags. This series copies ACPI_MADT_ONLINE_CAPABLE, which
appears to be for this purpose, but calls it ACPI_MADT_GICC_CPU_CAPABLE as it
has a different bit position in the GICC.
 
This code is unconditionally enabled for all ACPI architectures, though for
now only arm64 will have deferred the cpu_register() calls.

If folk want to play along at home, you'll need a copy of Qemu that supports this.
https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v2

Replace your '-smp' argument with something like:
 | -smp cpus=1,maxcpus=3,cores=3,threads=1,sockets=1
 
 then feed the following to the Qemu montior;
 | (qemu) device_add driver=host-arm-cpu,core-id=1,id=cpu1
 | (qemu) device_del cpu1

James Morse (7):
  ACPI: processor: Register deferred CPUs from acpi_processor_get_info()
  ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug
  arm64: acpi: Move get_cpu_for_acpi_id() to a header
  irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc()
  irqchip/gic-v3: Add support for ACPI's disabled but 'online capable'
    CPUs
  arm64: document virtual CPU hotplug's expectations
  cpumask: Add enabled cpumask for present CPUs that can be brought
    online

Jean-Philippe Brucker (1):
  arm64: psci: Ignore DENIED CPUs

Jonathan Cameron (11):
  ACPI: processor: Simplify initial onlining to use same path for cold
    and hotplug
  cpu: Do not warn on arch_register_cpu() returning -EPROBE_DEFER
  ACPI: processor: Drop duplicated check on _STA (enabled + present)
  ACPI: processor: Return an error if acpi_processor_get_info() fails in
    processor_add()
  ACPI: processor: Fix memory leaks in error paths of processor_add()
  ACPI: processor: Move checks and availability of acpi_processor
    earlier
  ACPI: processor: Add acpi_get_processor_handle() helper
  ACPI: scan: switch to flags for acpi_scan_check_and_detach()
  arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
  arm64: arch_register_cpu() variant to check if an ACPI handle is now
    available.
  arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is
    enabled.

 .../ABI/testing/sysfs-devices-system-cpu      |   6 +
 Documentation/arch/arm64/cpu-hotplug.rst      |  79 ++++++++++
 Documentation/arch/arm64/index.rst            |   1 +
 arch/arm64/Kconfig                            |   1 +
 arch/arm64/include/asm/acpi.h                 |  12 ++
 arch/arm64/kernel/acpi.c                      |  22 +++
 arch/arm64/kernel/acpi_numa.c                 |  11 --
 arch/arm64/kernel/psci.c                      |   2 +-
 arch/arm64/kernel/smp.c                       |  59 +++++++-
 drivers/acpi/acpi_processor.c                 | 141 ++++++++++--------
 drivers/acpi/processor_core.c                 |   3 +-
 drivers/acpi/processor_driver.c               |  43 ++----
 drivers/acpi/scan.c                           |  47 +++++-
 drivers/base/cpu.c                            |  12 +-
 drivers/irqchip/irq-gic-v3.c                  |  57 +++++--
 include/acpi/acpi_bus.h                       |   1 +
 include/acpi/processor.h                      |   2 +-
 include/linux/acpi.h                          |  12 +-
 include/linux/cpumask.h                       |  25 ++++
 kernel/cpu.c                                  |   3 +
 20 files changed, 404 insertions(+), 135 deletions(-)
 create mode 100644 Documentation/arch/arm64/cpu-hotplug.rst

-- 
2.39.2


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 2%]

* [PATCH v10 00/19] ACPI/arm64: add support for virtual cpu hotplug
@ 2024-05-29 13:34  2% ` Jonathan Cameron
  0 siblings, 0 replies; 200+ results
From: Jonathan Cameron @ 2024-05-29 13:34 UTC (permalink / raw)
  To: Marc Zyngier, Will Deacon, Catalin Marinas, linux-acpi,
	linux-arch, linux-kernel, linux-arm-kernel, linux-pm
  Cc: Mark Rutland, Thomas Gleixner, Peter Zijlstra, loongarch, x86,
	Russell King, Rafael J . Wysocki, Miguel Luis, James Morse,
	Salil Mehta, Jean-Philippe Brucker, Hanjun Guo, Gavin Shan,
	Ingo Molnar, Borislav Petkov, Dave Hansen, linuxarm, justin.he,
	jianyong.wu

v10:
- Make acpi_processor_set_per_cpu() return 0 / error rather than bool
  to simplify error handling at the call sites.
  (Thanks to both Rafael and Gavin who commented on this)
- Gather tags.
- Rebase on v6.10-rc1

The approach to the GICv3 changes stablized very late in the 6.10 cycle.
Subject to Marc taking a final look at those, I think we are now
in a good state wrt to those and the ACPI parts. The remaining code
that hasn't received review tags from the relevant maintainers
is the arm64 specific arch_register_cpu().  Given I think this will go
through the arm64 tree, hopefully they have just been waiting for
everything else to be ready.

It is only arch specific to the extent that Rafael suggested we limit
the potential impacts of the deferred calling of these functions
to be isolated to ARM64 for now.  This is done by having them return
-EPROBE_DEFER, on ACPI systems, until the ACPI interpreter is
available and can be used to query _STA.

Thanks to everyone who has been involved in development, testing and
review of this series - the complex tag chains reflect some of that.
Fingers crossed we are approaching the end of this particular saga.

Updated version of James' original introduction.

This series adds what looks like cpuhotplug support to arm64 for use in
virtual machines. It does this by moving the cpu_register() calls for
architectures that support ACPI into an arch specific call made from
the ACPI processor driver.
 
The kubernetes folk really want to be able to add CPUs to an existing VM,
in exactly the same way they do on x86. The use-case is pre-booting guests
with one CPU, then adding the number that were actually needed when the
workload is provisioned.

Wait? Doesn't arm64 support cpuhotplug already!?
In the arm world, cpuhotplug gets used to mean removing the power from a CPU.
The CPU is offline, and remains present. For x86, and ACPI, cpuhotplug
has the additional step of physically removing the CPU, so that it isn't
present anymore.
 
Arm64 doesn't support this, and can't support it: CPUs are really a slice
of the SoC, and there is not enough information in the existing ACPI tables
to describe which bits of the slice also got removed. Without a reference
machine: adding this support to the spec is a wild goose chase.
 
Critically: everything described in the firmware tables must remain present.
 
For a virtual machine this is easy as all the other bits of 'virtual SoC'
are emulated, so they can (and do) remain present when a vCPU is 'removed'.

On a system that supports cpuhotplug the MADT has to describe every possible
CPU at boot. Under KVM, the vGIC needs to know about every possible vCPU before
the guest is started.
With these constraints, virtual-cpuhotplug is really just a hypervisor/firmware
policy about which CPUs can be brought online.
 
This series adds support for virtual-cpuhotplug as exactly that: firmware
policy. This may even work on a physical machine too; for a guest the part of
firmware is played by the VMM. (typically Qemu).
 
PSCI support is modified to return 'DENIED' if the CPU can't be brought
online/enabled yet. The CPU object's _STA method's enabled bit is used to
indicate firmware's current disposition. If the CPU has its enabled bit clear,
it will not be registered with sysfs, and attempts to bring it online will
fail. The notifications that _STA has changed its value then work in the same
way as physical hotplug, and firmware can cause the CPU to be registered some
time later, allowing it to be brought online.
 
This creates something that looks like cpuhotplug to user-space and the
kernel beyond arm64 architecture specific code, as the sysfs
files appear and disappear, and the udev notifications look the same.
 
One notable difference is the CPU present mask, which is exposed via sysfs.
Because the CPUs remain present throughout, they can still be seen in that mask.
This value does get used by webbrowsers to estimate the number of CPUs
as the CPU online mask is constantly changed on mobile phones.
 
Linux is tolerant of PSCI returning errors, as its always been allowed to do
that. To avoid confusing OS that can't tolerate this, we needed an additional
bit in the MADT GICC flags. This series copies ACPI_MADT_ONLINE_CAPABLE, which
appears to be for this purpose, but calls it ACPI_MADT_GICC_CPU_CAPABLE as it
has a different bit position in the GICC.
 
This code is unconditionally enabled for all ACPI architectures, though for
now only arm64 will have deferred the cpu_register() calls.

If folk want to play along at home, you'll need a copy of Qemu that supports this.
https://github.com/salil-mehta/qemu.git virt-cpuhp-armv8/rfc-v2

Replace your '-smp' argument with something like:
 | -smp cpus=1,maxcpus=3,cores=3,threads=1,sockets=1
 
 then feed the following to the Qemu montior;
 | (qemu) device_add driver=host-arm-cpu,core-id=1,id=cpu1
 | (qemu) device_del cpu1

James Morse (7):
  ACPI: processor: Register deferred CPUs from acpi_processor_get_info()
  ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug
  arm64: acpi: Move get_cpu_for_acpi_id() to a header
  irqchip/gic-v3: Don't return errors from gic_acpi_match_gicc()
  irqchip/gic-v3: Add support for ACPI's disabled but 'online capable'
    CPUs
  arm64: document virtual CPU hotplug's expectations
  cpumask: Add enabled cpumask for present CPUs that can be brought
    online

Jean-Philippe Brucker (1):
  arm64: psci: Ignore DENIED CPUs

Jonathan Cameron (11):
  ACPI: processor: Simplify initial onlining to use same path for cold
    and hotplug
  cpu: Do not warn on arch_register_cpu() returning -EPROBE_DEFER
  ACPI: processor: Drop duplicated check on _STA (enabled + present)
  ACPI: processor: Return an error if acpi_processor_get_info() fails in
    processor_add()
  ACPI: processor: Fix memory leaks in error paths of processor_add()
  ACPI: processor: Move checks and availability of acpi_processor
    earlier
  ACPI: processor: Add acpi_get_processor_handle() helper
  ACPI: scan: switch to flags for acpi_scan_check_and_detach()
  arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry
  arm64: arch_register_cpu() variant to check if an ACPI handle is now
    available.
  arm64: Kconfig: Enable hotplug CPU on arm64 if ACPI_PROCESSOR is
    enabled.

 .../ABI/testing/sysfs-devices-system-cpu      |   6 +
 Documentation/arch/arm64/cpu-hotplug.rst      |  79 ++++++++++
 Documentation/arch/arm64/index.rst            |   1 +
 arch/arm64/Kconfig                            |   1 +
 arch/arm64/include/asm/acpi.h                 |  12 ++
 arch/arm64/kernel/acpi.c                      |  22 +++
 arch/arm64/kernel/acpi_numa.c                 |  11 --
 arch/arm64/kernel/psci.c                      |   2 +-
 arch/arm64/kernel/smp.c                       |  59 +++++++-
 drivers/acpi/acpi_processor.c                 | 141 ++++++++++--------
 drivers/acpi/processor_core.c                 |   3 +-
 drivers/acpi/processor_driver.c               |  43 ++----
 drivers/acpi/scan.c                           |  47 +++++-
 drivers/base/cpu.c                            |  12 +-
 drivers/irqchip/irq-gic-v3.c                  |  57 +++++--
 include/acpi/acpi_bus.h                       |   1 +
 include/acpi/processor.h                      |   2 +-
 include/linux/acpi.h                          |  12 +-
 include/linux/cpumask.h                       |  25 ++++
 kernel/cpu.c                                  |   3 +
 20 files changed, 404 insertions(+), 135 deletions(-)
 create mode 100644 Documentation/arch/arm64/cpu-hotplug.rst

-- 
2.39.2


^ permalink raw reply	[relevance 2%]

* [pci:controller/gpio] BUILD SUCCESS 1d38f9d89f85f6c925a1ca128a5eabf62574380d
@ 2024-05-29 13:33  1% kernel test robot
  0 siblings, 0 replies; 200+ results
From: kernel test robot @ 2024-05-29 13:33 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: linux-pci

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git controller/gpio
branch HEAD: 1d38f9d89f85f6c925a1ca128a5eabf62574380d  PCI: kirin: Convert to use agnostic GPIO API

elapsed time: 1232m

configs tested: 149
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                            allyesconfig   gcc  
alpha                               defconfig   gcc  
arc                              allmodconfig   gcc  
arc                               allnoconfig   gcc  
arc                              allyesconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20240529   gcc  
arc                   randconfig-002-20240529   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   clang
arm                              allyesconfig   gcc  
arm                                 defconfig   clang
arm                   randconfig-001-20240529   gcc  
arm                   randconfig-002-20240529   gcc  
arm                   randconfig-003-20240529   gcc  
arm                   randconfig-004-20240529   gcc  
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                               defconfig   gcc  
arm64                 randconfig-001-20240529   clang
arm64                 randconfig-002-20240529   clang
arm64                 randconfig-003-20240529   gcc  
arm64                 randconfig-004-20240529   gcc  
csky                             allmodconfig   gcc  
csky                              allnoconfig   gcc  
csky                             allyesconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20240529   gcc  
csky                  randconfig-002-20240529   gcc  
hexagon                          allmodconfig   clang
hexagon                           allnoconfig   clang
hexagon                          allyesconfig   clang
hexagon                             defconfig   clang
hexagon               randconfig-001-20240529   clang
hexagon               randconfig-002-20240529   clang
i386                             allmodconfig   gcc  
i386                              allnoconfig   gcc  
i386                             allyesconfig   gcc  
i386         buildonly-randconfig-002-20240529   gcc  
i386         buildonly-randconfig-003-20240529   gcc  
i386         buildonly-randconfig-005-20240529   gcc  
i386                                defconfig   clang
i386                  randconfig-002-20240529   gcc  
i386                  randconfig-003-20240529   gcc  
i386                  randconfig-004-20240529   gcc  
i386                  randconfig-014-20240529   gcc  
i386                  randconfig-016-20240529   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20240529   gcc  
loongarch             randconfig-002-20240529   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                              allnoconfig   gcc  
mips                             allyesconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20240529   gcc  
nios2                 randconfig-002-20240529   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20240529   gcc  
parisc                randconfig-002-20240529   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   gcc  
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc               randconfig-001-20240529   clang
powerpc               randconfig-002-20240529   clang
powerpc               randconfig-003-20240529   clang
powerpc64             randconfig-001-20240529   gcc  
powerpc64             randconfig-002-20240529   clang
powerpc64             randconfig-003-20240529   clang
riscv                            allmodconfig   clang
riscv                             allnoconfig   gcc  
riscv                            allyesconfig   clang
riscv                               defconfig   clang
riscv                 randconfig-001-20240529   gcc  
riscv                 randconfig-002-20240529   clang
s390                             allmodconfig   clang
s390                              allnoconfig   clang
s390                             allyesconfig   gcc  
s390                                defconfig   clang
s390                  randconfig-001-20240529   clang
s390                  randconfig-002-20240529   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                                  defconfig   gcc  
sh                    randconfig-001-20240529   gcc  
sh                    randconfig-002-20240529   gcc  
sparc                            allmodconfig   gcc  
sparc                             allnoconfig   gcc  
sparc                               defconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20240529   gcc  
sparc64               randconfig-002-20240529   gcc  
um                               allmodconfig   clang
um                                allnoconfig   clang
um                               allyesconfig   gcc  
um                                  defconfig   clang
um                             i386_defconfig   gcc  
um                    randconfig-001-20240529   clang
um                    randconfig-002-20240529   gcc  
um                           x86_64_defconfig   clang
x86_64                            allnoconfig   clang
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-001-20240529   gcc  
x86_64       buildonly-randconfig-002-20240529   clang
x86_64       buildonly-randconfig-003-20240529   clang
x86_64       buildonly-randconfig-004-20240529   gcc  
x86_64       buildonly-randconfig-005-20240529   clang
x86_64       buildonly-randconfig-006-20240529   gcc  
x86_64                              defconfig   gcc  
x86_64                randconfig-001-20240529   gcc  
x86_64                randconfig-002-20240529   clang
x86_64                randconfig-003-20240529   clang
x86_64                randconfig-004-20240529   clang
x86_64                randconfig-005-20240529   gcc  
x86_64                randconfig-006-20240529   gcc  
x86_64                randconfig-011-20240529   gcc  
x86_64                randconfig-012-20240529   gcc  
x86_64                randconfig-013-20240529   clang
x86_64                randconfig-014-20240529   gcc  
x86_64                randconfig-015-20240529   gcc  
x86_64                randconfig-016-20240529   clang
x86_64                randconfig-071-20240529   clang
x86_64                randconfig-072-20240529   gcc  
x86_64                          rhel-8.3-rust   clang
xtensa                            allnoconfig   gcc  
xtensa                randconfig-001-20240529   gcc  
xtensa                randconfig-002-20240529   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[relevance 1%]

* Re: [PATCH v2 03/10] drm/amdgpu: abort fence poll if reset is started
  2024-05-29 13:22  1%     ` Li, Yunxiang (Teddy)
@ 2024-05-29 13:31  0%       ` Christian König
  0 siblings, 0 replies; 200+ results
From: Christian König @ 2024-05-29 13:31 UTC (permalink / raw)
  To: Li, Yunxiang (Teddy), amd-gfx

Am 29.05.24 um 15:22 schrieb Li, Yunxiang (Teddy):
> [Public]
>
>> It's perfectly possible that the reset has already started before we enter the function.
> Yeah, this could and does happen, but it just means we are back to the old behavior. I guess I could use "can I take the read side lock?" to test if the function is called outside of reset or not, would that be acceptable?
>
> So like:
> Int not_in_reset = read_try_lock(reset sem);
> while (...) {
>    if (not_in_reset && amdgpu_in_reset())
>        break;
> }
> If (not_in_reset)
>     up_read(reset sem)

I don't think trying to add some reset handling here makes sense in the 
first place.

Part of the reset/recovery procedure is to signal all fence and that 
includes the one we are waiting for here.

So this wait should return immediately in a reset anyway.

Regards,
Christian.

^ permalink raw reply	[relevance 0%]

* [PATCH net-next 4/6] net: fman_memac: remove the now unnecessary checking for fixed-link
  2024-05-29 13:28  2% ` Russell King (Oracle)
  (?)
  (?)
@ 2024-05-29 13:29 14% ` Russell King (Oracle)
  -1 siblings, 0 replies; 200+ results
From: Russell King (Oracle) @ 2024-05-29 13:29 UTC (permalink / raw)
  To: Andrew Lunn, Heiner Kallweit
  Cc: Andrew Halaney, Serge Semin, Madalin Bucur, Sean Anderson,
	David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	netdev

Since default_an_inband can be overriden by a fixed-link specification,
there is no need for memac to be checking for this before setting
default_an_inband. Remove this code and update the comment.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
 drivers/net/ethernet/freescale/fman/fman_memac.c | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/net/ethernet/freescale/fman/fman_memac.c b/drivers/net/ethernet/freescale/fman/fman_memac.c
index 9c44a3581950..796e6f4e583d 100644
--- a/drivers/net/ethernet/freescale/fman/fman_memac.c
+++ b/drivers/net/ethernet/freescale/fman/fman_memac.c
@@ -1066,7 +1066,6 @@ int memac_initialization(struct mac_device *mac_dev,
 			 struct fman_mac_params *params)
 {
 	int			 err;
-	struct device_node      *fixed;
 	struct phylink_pcs	*pcs;
 	struct fman_mac		*memac;
 	unsigned long		 capabilities;
@@ -1222,18 +1221,15 @@ int memac_initialization(struct mac_device *mac_dev,
 		memac->rgmii_no_half_duplex = true;
 
 	/* Most boards should use MLO_AN_INBAND, but existing boards don't have
-	 * a managed property. Default to MLO_AN_INBAND if nothing else is
-	 * specified. We need to be careful and not enable this if we have a
-	 * fixed link or if we are using MII or RGMII, since those
-	 * configurations modes don't use in-band autonegotiation.
+	 * a managed property. Default to MLO_AN_INBAND rather than MLO_AN_PHY.
+	 * Phylink will allow this to be overriden by a fixed link. We need to
+	 * be careful and not enable this if we are using MII or RGMII, since
+	 * those configurations modes don't use in-band autonegotiation.
 	 */
-	fixed = of_get_child_by_name(mac_node, "fixed-link");
-	if (!fixed && !of_property_read_bool(mac_node, "fixed-link") &&
-	    !of_property_read_bool(mac_node, "managed") &&
+	if (!of_property_read_bool(mac_node, "managed") &&
 	    mac_dev->phy_if != PHY_INTERFACE_MODE_MII &&
 	    !phy_interface_mode_is_rgmii(mac_dev->phy_if))
 		mac_dev->phylink_config.default_an_inband = true;
-	of_node_put(fixed);
 
 	err = memac_init(mac_dev->fman_mac);
 	if (err < 0)
-- 
2.30.2


^ permalink raw reply related	[relevance 14%]

* [PATCH net-next 2/6] net: phylink: move test for ovr_an_inband
  2024-05-29 13:28  2% ` Russell King (Oracle)
  (?)
@ 2024-05-29 13:29  5% ` Russell King (Oracle)
  -1 siblings, 0 replies; 200+ results
From: Russell King (Oracle) @ 2024-05-29 13:29 UTC (permalink / raw)
  To: Andrew Lunn, Heiner Kallweit
  Cc: Andrew Halaney, Serge Semin, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, netdev

Of the two users of phylink_config->ovr_an_inband, both manually check
for a fixed link before setting this flag (or clearing it if they find
a fixed link.) This is unnecessary complication.

Test ovr_an_inband before checking for the fixed-link properties, which
will allow ovr_an_inband to be overriden by a fixed link specification.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
 drivers/net/phy/phylink.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 5abd12713598..c81f1c1ee675 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -885,14 +885,16 @@ static int phylink_parse_mode(struct phylink *pl,
 	const char *managed;
 	unsigned long caps;
 
+	if (pl->config->ovr_an_inband)
+		pl->cfg_link_an_mode = MLO_AN_INBAND;
+
 	dn = fwnode_get_named_child_node(fwnode, "fixed-link");
 	if (dn || fwnode_property_present(fwnode, "fixed-link"))
 		pl->cfg_link_an_mode = MLO_AN_FIXED;
 	fwnode_handle_put(dn);
 
 	if ((fwnode_property_read_string(fwnode, "managed", &managed) == 0 &&
-	     strcmp(managed, "in-band-status") == 0) ||
-	    pl->config->ovr_an_inband) {
+	     strcmp(managed, "in-band-status") == 0)) {
 		if (pl->cfg_link_an_mode == MLO_AN_FIXED) {
 			phylink_err(pl,
 				    "can't use both fixed-link and in-band-status\n");
-- 
2.30.2


^ permalink raw reply related	[relevance 5%]

* [PATCH net-next 0/6] net: phylink: rearrange ovr_an_inband support
@ 2024-05-29 13:28  2% ` Russell King (Oracle)
  0 siblings, 0 replies; 200+ results
From: Russell King (Oracle) @ 2024-05-29 13:28 UTC (permalink / raw)
  To: Andrew Lunn, Heiner Kallweit
  Cc: Alexandre Torgue, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Jose Abreu, linux-arm-kernel, linux-stm32, Madalin Bucur,
	Maxime Coquelin, netdev, Paolo Abeni, Sean Anderson,
	Andrew Halaney, Serge Semin

Hi,

This series addresses the use of the ovr_an_inband flag, which is used
by two drivers to indicate to phylink that they wish to use inband mode
without firmware specifying inband mode.

The issue with ovr_an_inband is that it overrides not only PHY mode,
but also fixed-link mode. Both of the drivers that set this flag
contain code to detect when fixed-link mode will be used, and then
either avoid setting it or explicitly clear the flag. This is
wasteful when phylink already knows this.

Therefore, the approach taken in this patch set is to replace the
ovr_an_inband flag with a default_an_inband flag which means that
phylink defaults to MLO_AN_INBAND instead of MLO_AN_PHY, and will
allow that default to be overriden if firmware specifies a fixed-link.
This allows users of ovr_an_inband to be simplified.

What's more is this requires minimal changes in phylink to allow this
new mode of operation.

This series changes phylink, and also updates the two drivers
(fman_memac and stmmac), and then removes the unnecessary complexity
from the drivers.

This series may depend on the stmmac cleanup series I've posted
earlier - this is something I have not checked, but I currently have
these patches on top of that series.

 drivers/net/ethernet/freescale/fman/fman_memac.c  | 16 ++++++----------
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 15 ++-------------
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |  4 ++--
 drivers/net/phy/phylink.c                         | 11 ++++++++---
 include/linux/phylink.h                           |  5 +++--
 include/linux/stmmac.h                            |  2 +-
 6 files changed, 22 insertions(+), 31 deletions(-)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 2%]

* [PATCH net-next 0/6] net: phylink: rearrange ovr_an_inband support
@ 2024-05-29 13:28  2% ` Russell King (Oracle)
  0 siblings, 0 replies; 200+ results
From: Russell King (Oracle) @ 2024-05-29 13:28 UTC (permalink / raw)
  To: Andrew Lunn, Heiner Kallweit
  Cc: Alexandre Torgue, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Jose Abreu, linux-arm-kernel, linux-stm32, Madalin Bucur,
	Maxime Coquelin, netdev, Paolo Abeni, Sean Anderson,
	Andrew Halaney, Serge Semin

Hi,

This series addresses the use of the ovr_an_inband flag, which is used
by two drivers to indicate to phylink that they wish to use inband mode
without firmware specifying inband mode.

The issue with ovr_an_inband is that it overrides not only PHY mode,
but also fixed-link mode. Both of the drivers that set this flag
contain code to detect when fixed-link mode will be used, and then
either avoid setting it or explicitly clear the flag. This is
wasteful when phylink already knows this.

Therefore, the approach taken in this patch set is to replace the
ovr_an_inband flag with a default_an_inband flag which means that
phylink defaults to MLO_AN_INBAND instead of MLO_AN_PHY, and will
allow that default to be overriden if firmware specifies a fixed-link.
This allows users of ovr_an_inband to be simplified.

What's more is this requires minimal changes in phylink to allow this
new mode of operation.

This series changes phylink, and also updates the two drivers
(fman_memac and stmmac), and then removes the unnecessary complexity
from the drivers.

This series may depend on the stmmac cleanup series I've posted
earlier - this is something I have not checked, but I currently have
these patches on top of that series.

 drivers/net/ethernet/freescale/fman/fman_memac.c  | 16 ++++++----------
 drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 15 ++-------------
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |  4 ++--
 drivers/net/phy/phylink.c                         | 11 ++++++++---
 include/linux/phylink.h                           |  5 +++--
 include/linux/stmmac.h                            |  2 +-
 6 files changed, 22 insertions(+), 31 deletions(-)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

^ permalink raw reply	[relevance 2%]

* Re: [PATCH 3/3] mm: zswap: proactive shrinking before pool size limit is hit
  @ 2024-05-29 13:27  0%     ` Takero Funaki
  0 siblings, 0 replies; 200+ results
From: Takero Funaki @ 2024-05-29 13:27 UTC (permalink / raw)
  To: Nhat Pham
  Cc: Johannes Weiner, Yosry Ahmed, Chengming Zhou, Jonathan Corbet,
	Andrew Morton, Domenico Cerasuolo, linux-mm, linux-doc,
	linux-kernel

2024年5月29日(水) 1:01 Nhat Pham <nphamcs@gmail.com>:
>
> On Mon, May 27, 2024 at 9:34 PM Takero Funaki <flintglass@gmail.com> wrote:
> >
> > This patch implements proactive shrinking of zswap pool before the max
> > pool size limit is reached. This also changes zswap to accept new pages
> > while the shrinker is running.
> >
> > To prevent zswap from rejecting new pages and incurring latency when
> > zswap is full, this patch queues the global shrinker by a pool usage
> > threshold at the middle of 100% and accept_thr_percent, instead of the
> > max pool size.  The pool size will be controlled between 90% to 95% for
> > the default accept_thr_percent=90.  Since the current global shrinker
> > continues to shrink until accept_thr_percent, we do not need to maintain
> > the hysteresis variable tracking the pool limit overage in
> > zswap_store().
> >
> > Before this patch, zswap rejected pages while the shrinker is running
> > without incrementing zswap_pool_limit_hit counter. It could be a reason
> > why zswap writethrough new pages before writeback old pages.  With this
> > patch, zswap accepts new pages while shrinking, and zswap increments
> > the counter when and only when zswap rejects pages by the max pool size.
> >
> > The name of sysfs tunable accept_thr_percent is unchanged as it is still
> > the stop condition of the shrinker.
> > The respective documentation is updated to describe the new behavior.
>
> I'm a bit unsure about using this tunable. How would the user
> determine the level at which the zswap pool should be kept empty?
>
> I was actually thinking of removing this knob altogether :)
>

If we see a large pool_limit_hit, that indicates we should lower the
accept threshold to make more space proactively, to store new pages
from active processes rather than rejecting.
If not, we can set a higher accept threshold for swapin, s.t.
low-activity background processes.
That depends on one's workload, and can be tuned by the admin, I think.

> >
> > Signed-off-by: Takero Funaki <flintglass@gmail.com>
> > ---
> >  Documentation/admin-guide/mm/zswap.rst | 17 +++++----
> >  mm/zswap.c                             | 49 +++++++++++++++-----------
> >  2 files changed, 37 insertions(+), 29 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/mm/zswap.rst b/Documentation/admin-guide/mm/zswap.rst
> > index 3598dcd7dbe7..a1d8f167a27a 100644
> > --- a/Documentation/admin-guide/mm/zswap.rst
> > +++ b/Documentation/admin-guide/mm/zswap.rst
> > @@ -111,18 +111,17 @@ checked if it is a same-value filled page before compressing it. If true, the
> >  compressed length of the page is set to zero and the pattern or same-filled
> >  value is stored.
> >
> > -To prevent zswap from shrinking pool when zswap is full and there's a high
> > -pressure on swap (this will result in flipping pages in and out zswap pool
> > -without any real benefit but with a performance drop for the system), a
> > -special parameter has been introduced to implement a sort of hysteresis to
> > -refuse taking pages into zswap pool until it has sufficient space if the limit
> > -has been hit. To set the threshold at which zswap would start accepting pages
> > -again after it became full, use the sysfs ``accept_threshold_percent``
> > -attribute, e. g.::
> > +To prevent zswap from rejecting new pages and incurring latency when zswap is
> > +full, zswap initiates a worker called global shrinker that proactively evicts
> > +some pages from the pool to swap devices while the pool is reaching the limit.
> > +The global shrinker continues to evict pages until there is sufficient space to
> > +accept new pages. To control how many pages should remain in the pool, use the
> > +sysfs ``accept_threshold_percent`` attribute as a percentage of the max pool
> > +size, e. g.::
> >
> >         echo 80 > /sys/module/zswap/parameters/accept_threshold_percent
> >
> > -Setting this parameter to 100 will disable the hysteresis.
> > +Setting this parameter to 100 will disable the proactive shrinking.
> >
> >  Some users cannot tolerate the swapping that comes with zswap store failures
> >  and zswap writebacks. Swapping can be disabled entirely (without disabling
> > diff --git a/mm/zswap.c b/mm/zswap.c
> > index 08a6f5a6bf62..0186224be8fc 100644
> > --- a/mm/zswap.c
> > +++ b/mm/zswap.c
> > @@ -71,8 +71,6 @@ static u64 zswap_reject_kmemcache_fail;
> >
> >  /* Shrinker work queue */
> >  static struct workqueue_struct *shrink_wq;
> > -/* Pool limit was hit, we need to calm down */
> > -static bool zswap_pool_reached_full;
> >
> >  /*********************************
> >  * tunables
> > @@ -118,7 +116,10 @@ module_param_cb(zpool, &zswap_zpool_param_ops, &zswap_zpool_type, 0644);
> >  static unsigned int zswap_max_pool_percent = 20;
> >  module_param_named(max_pool_percent, zswap_max_pool_percent, uint, 0644);
> >
> > -/* The threshold for accepting new pages after the max_pool_percent was hit */
> > +/*
> > + * The percentage of pool size that the global shrinker keeps in memory.
> > + * It does not protect old pages from the dynamic shrinker.
> > + */
> >  static unsigned int zswap_accept_thr_percent = 90; /* of max pool size */
> >  module_param_named(accept_threshold_percent, zswap_accept_thr_percent,
> >                    uint, 0644);
> > @@ -487,6 +488,14 @@ static unsigned long zswap_accept_thr_pages(void)
> >         return zswap_max_pages() * zswap_accept_thr_percent / 100;
> >  }
> >
> > +/*
> > + * Returns threshold to start proactive global shrinking.
> > + */
> > +static inline unsigned long zswap_shrink_start_pages(void)
> > +{
> > +       return zswap_max_pages() * (100 - (100 - zswap_accept_thr_percent)/2) / 100;
> > +}
> > +
> >  unsigned long zswap_total_pages(void)
> >  {
> >         struct zswap_pool *pool;
> > @@ -504,21 +513,6 @@ unsigned long zswap_total_pages(void)
> >         return total;
> >  }
> >
> > -static bool zswap_check_limits(void)
> > -{
> > -       unsigned long cur_pages = zswap_total_pages();
> > -       unsigned long max_pages = zswap_max_pages();
> > -
> > -       if (cur_pages >= max_pages) {
> > -               zswap_pool_limit_hit++;
> > -               zswap_pool_reached_full = true;
> > -       } else if (zswap_pool_reached_full &&
> > -                  cur_pages <= zswap_accept_thr_pages()) {
> > -                       zswap_pool_reached_full = false;
> > -       }
> > -       return zswap_pool_reached_full;
> > -}
> > -
> >  /*********************************
> >  * param callbacks
> >  **********************************/
> > @@ -1475,6 +1469,8 @@ bool zswap_store(struct folio *folio)
> >         struct obj_cgroup *objcg = NULL;
> >         struct mem_cgroup *memcg = NULL;
> >         unsigned long value;
> > +       unsigned long cur_pages;
> > +       bool need_global_shrink = false;
> >
> >         VM_WARN_ON_ONCE(!folio_test_locked(folio));
> >         VM_WARN_ON_ONCE(!folio_test_swapcache(folio));
> > @@ -1497,8 +1493,18 @@ bool zswap_store(struct folio *folio)
> >                 mem_cgroup_put(memcg);
> >         }
> >
> > -       if (zswap_check_limits())
> > +       cur_pages = zswap_total_pages();
> > +
> > +       if (cur_pages >= zswap_max_pages()) {
> > +               zswap_pool_limit_hit++;
> > +               need_global_shrink = true;
> >                 goto reject;
> > +       }
> > +
> > +       /* schedule shrink for incoming pages */
> > +       if (cur_pages >= zswap_shrink_start_pages()
> > +                       && !work_pending(&zswap_shrink_work))
> > +               queue_work(shrink_wq, &zswap_shrink_work);
>
> I think work_pending() check here is redundant. If you look at the
> documentation, queue_work only succeeds if zswap_shrink_work is not
> already on the shrink_wq workqueue.
>
> More specifically, if you check the code, queue_work calls
> queue_work_on, which has this check:
>
> if (!test_and_set_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work)) &&
>    !clear_pending_if_disabled(work)) {
>
> This is the same bit-check as work_pending, which is defined as:
>
> #define work_pending(work) \
> test_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work))
>

Thanks for the review and info. I will remove the tests.

>
> >
> >         /* allocate entry */
> >         entry = zswap_entry_cache_alloc(GFP_KERNEL, folio_nid(folio));
> > @@ -1541,6 +1547,9 @@ bool zswap_store(struct folio *folio)
> >
> >                 WARN_ONCE(err != -ENOMEM, "unexpected xarray error: %d\n", err);
> >                 zswap_reject_alloc_fail++;
> > +
> > +               /* reduce entry in array */
> > +               need_global_shrink = true;
> >                 goto store_failed;
> >         }
> >
> > @@ -1590,7 +1599,7 @@ bool zswap_store(struct folio *folio)
> >         zswap_entry_cache_free(entry);
> >  reject:
> >         obj_cgroup_put(objcg);
> > -       if (zswap_pool_reached_full)
> > +       if (need_global_shrink && !work_pending(&zswap_shrink_work))
> >                 queue_work(shrink_wq, &zswap_shrink_work);
> >  check_old:
> >         /*
> > --
> > 2.43.0
> >



-- 

<flintglass@gmail.com>

^ permalink raw reply	[relevance 0%]

* Bad lib symlink in Host SDK
@ 2024-05-29 13:27  1% Lukas Weiß
  0 siblings, 0 replies; 200+ results
From: Lukas Weiß @ 2024-05-29 13:27 UTC (permalink / raw)
  To: yocto

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

Hi together,

i have a question about Yocto SDK generation. We use the Yocto-SDK not only for generation of target binaries outside the Yocto Build process, but also for generation of the same binaries *for the host* (nativesdk). This way we are able to run our applications as Simulations or Unit-Tests in our CI process without the need to install dev- and runtime libs on the host system (also the libs have the same build configuration as on target).

Unfortunately, the SDK doesn't really seem to be designed for this. The BB classes for the native/nativesdk are also missing for most libraries. And last but not least, I still have the feeling that I haven't really found the "right" way to define the SDK. Whatever.

I'm currently trying to add the libudev (yes, i know that its probably not the best idea to add a system lib to host sdk ;-). I added an eudev_%.bbappend file containing
> 
> 
> BBCLASSEXTEND = "native nativesdk"

and appended "nativesdk-eudev" and "nativesdk-eudev-dev" to the RDEPENDS of my nativesdk-packagegroup-sdk-host recipe.

This works, but unfortunately the resulting installed SDK has a wrong symlink for the hosts libudev.so:

> 
> 
> 
> /home/admin/sdk/plat/5.0/sysroots/x86_64-platsdk-linux/usr/lib/libudev.so
> ->
> ../../../../../../home/admin/sdk/plat/5.0/sysroots/x86_64-platsdk-linux/lib/libudev.so.1.6.3
> 
> 
> 

The correct link would be
> 
> /home/admin/sdk/plat/5.0/sysroots/x86_64-platsdk-linux/usr/lib/libudev.so
> -> ../../lib/libudev.so.1.6.3

This must happen on SDK installation, as the install path is not known before. All other links in SDK ( *including the link for target libudev.so* ) are correct.
Do you have any hints for me how i can dig into this? All debug methods i know belong to built process itself, not the install.

My Yocto version is "yocto-5.0" Tag in Repo.

[-- Attachment #2: Type: text/html, Size: 2006 bytes --]

^ permalink raw reply	[relevance 1%]

* Re: NFSD: Unable to initialize client recovery tracking! (-110)
  2024-05-29 13:13  0%         ` Jeff Layton
  2024-05-29 13:16  0%           ` Chuck Lever III
@ 2024-05-29 13:27  0%           ` Paul Menzel
  1 sibling, 0 replies; 200+ results
From: Paul Menzel @ 2024-05-29 13:27 UTC (permalink / raw)
  To: Jeff Layton, Chuck Lever III
  Cc: regressions, linux-nfs, it+linux-nfs, Linus Torvalds

Dear Jeff, dear Chuck, dear Thorsten,


Thank you for your responses, and sorry for not replying earlier.

Am 29.05.24 um 15:13 schrieb Jeff Layton:
> On Fri, 2024-05-24 at 16:09 +0000, Chuck Lever III wrote:

>>> On May 24, 2024, at 7:16 AM, Linux regression tracking (Thorsten
>>> Leemhuis) wrote:
>>>
>>> On 21.05.24 12:01, Jeff Layton wrote:
>>>> On Tue, 2024-05-21 at 11:55 +0200, Paul Menzel wrote:
>>>>> Am 19.04.24 um 18:50 schrieb Paul Menzel:
>>>>>
>>>>>> Since at least Linux 6.8-rc6, Linux logs the warning below:
>>>>>>
>>>>>>      NFSD: Unable to initialize client recovery tracking! (-110)
>>>>>>
>>>>>> I haven’t had time to bisect yet, so if you have an idea,
>>>>>> that’d be great.
>>>>>
>>>>> 74fd48739d0488e39ae18b0168720f449a06690c is the first bad commit
>>>>> commit 74fd48739d0488e39ae18b0168720f449a06690c
>>>>> Author: Jeff Layton <jlayton@kernel.org>
>>>>> Date:   Fri Oct 13 09:03:53 2023 -0400
>>>>>
>>>>>      nfsd: new Kconfig option for legacy client tracking
>>>>>
>>>>>      We've had a number of attempts at different NFSv4 client tracking
>>>>>      methods over the years, but now nfsdcld has emerged as the clear winner
>>>>>      since the others (recoverydir and the usermodehelper upcall) are
>>>>>      problematic.
>>>> [...]
>>>> It sounds like you need to enable nfsdcld in your environment. The old
>>>> recovery tracking methods are deprecated. The only surviving one
>>>> requires the nfsdcld daemon to be running when recovery tracking is
>>>> started. Alternately, you can enable this option in your kernels if you
>>>> want to keep using the deprecated methods in the interim.
>>>
>>> Hmm. Then why didn't this new config option default to "Y" for a while
>>> (say a year or two) before changing the default to off? That would have
>>> prevented people like Paul from running into the problem when running
>>> "olddefconfig". I think that is what Linus would have wanted in a case
>>> like this, but might be totally wrong there (I CCed him, in case he
>>> wants to share his opinion, but maybe he does not care much).
>>
>> That's fair. I recall we believed at the time that very few people
>> if anyone currently use a legacy recovery tracking mechanism, and
>> the workaround, if they do, is easy.
>>
>>> But I guess that's too late now, unless we want to meddle with config
>>> option names. But I guess that might not be worth it after half a year
>>> for something that only causes a warning (aiui).
>>
>> In Paul's case, the default behavior might prevent proper NFSv4
>> state recovery, which is a little more hazardous than a mere
>> warning, IIUC.
>>
>> To my surprise, it often takes quite some time for changes like
>> this to matriculate into mainstream usage, so half a year isn't
>> that long. We might want to change to a more traditional
>> deprecation path (default Y with warning, wait, default N, wait,
>> redact the old code).
> 
> I've no objection if you want to do that.
> 
> I'm more concerned about Paul's setup though. Paul, what distro are you
> running that starts nfsd (and presumably, mountd, etc.), but doesn't
> bother starting nfsdcld?
> 
> Reenabling this for now is an OK workaround, but we need to understand
> where these setups are coming from, and probably do some sort of
> outreach to get them working properly.

Thank you for the explanation. Due to historical reasons we maintain our 
own distribution MarIuX64 [1] and currently run Linux 5.15.x and 6.6.x. 
Installing nfsdcld is no problem, but it would have been nice to make 
this clearer in the error message, so people without being NFSD experts 
getting this message, knew what to do right away. Maybe:

NFSD: Unable to initialize client recovery tracking! (-110) Is nfsdcld 
running? Otherwise enable NFSD_LEGACY_CLIENT_TRACKING.


Kind regards,

Paul


[1]: https://github.molgen.mpg.de/mariux64/bee-files/
[2]: https://github.molgen.mpg.de/mariux64/bee-files/pull/3111

^ permalink raw reply	[relevance 0%]

* Re: [PATCH libgpiod v2 2/4] tools: tests: use "$@" instead of $*
  2024-05-29 13:18  3%           ` Kent Gibson
@ 2024-05-29 13:27  3%             ` Andy Shevchenko
  0 siblings, 0 replies; 200+ results
From: Andy Shevchenko @ 2024-05-29 13:27 UTC (permalink / raw)
  To: Kent Gibson
  Cc: Bartosz Golaszewski, Linus Walleij, Bartosz Golaszewski, linux-gpio

On Wed, May 29, 2024 at 09:18:47PM +0800, Kent Gibson wrote:
> On Wed, May 29, 2024 at 04:08:49PM +0300, Andy Shevchenko wrote:
> > On Tue, May 28, 2024 at 07:39:10AM +0800, Kent Gibson wrote:
> > > On Mon, May 27, 2024 at 07:17:37PM +0300, Andy Shevchenko wrote:
> > > > On Mon, May 27, 2024 at 08:44:20PM +0800, Kent Gibson wrote:
> > > > > On Mon, May 27, 2024 at 02:02:34PM +0200, Bartosz Golaszewski wrote:

...

> > > > > >  assert_fail() {
> > > > > > -	$* || return 0
> > > > > > -	fail " '$*': command did not fail as expected"
> > > > > > +	"$@" || return 0
> > > > > > +	fail " '$@': command did not fail as expected"
> > > > > >  }
> > > > >
> > > > > Ironically, shellcheck doesn't like the '$@' in the fail string[1], so you
> > > > > should use $* there.
> > > >
> > > > But why does it do like this?
> > >
> > > Read the link[1].
> >
> > Okay, this is only for some debug / error messages. Still if one wants to have
> > clear understanding on what has been passed to some function, $* is not a
> > correct option. Also note the single quotes, shouldn't that protect from the
> > arguments loss?
> 
> That's right - I was only referring to this particular case where a
> string is being constructed.  Wasn't that clear?

I meant that if you want to have this knowledge in the debug / error message,
you will fail with $*, that's why I consider shellcheck is incorrect.

Ex.

I have

	foo bar "baz bar2"

and I want

	"ERROR: 'foo bar "baz bar2"' failed"

type of message.

AFAIU this is not what shellcheck wants. It want me to mange this to

	"ERROR: 'foo bar baz bar2' failed"

Thanks, but no thanks to shellcheck.

> The single quotes are within double quotes, so aren't they just part of
> the text in this context?

I don't remember by heard the shell expansion rules. I presumable that it
might affect the inner argument on the recursive expansion.

> > > Because $@ is an array being used to build a string, and that may not
> > > work the way you expect.
> >
> > I think it's the opposite, $* works in a way I do not expect :-)
> 
> When passing arguments, sure.

> Not when constructing strings.

Why not? This is pure puzzle to me why anybody wants the mangled string.

> > > In this case $* is clearer as that has already
> > > been concatenated.
> >
> > ...loosing information about which word refers to which argument, yes.
> 
> It is building a string, so arguments are irrelevant.

See above why I think it's relevant.

> > > [1] https://www.shellcheck.net/wiki/SC2145
> >
> > TL;DR: I consider this is still a bug in shellcheck. But if you rely on the
> > tool as on the ruleset carved in stone, I will not die. Just a remark to
> > myself "even honourable tools may also be broken".
> 
> If you think it is a bug then raise it with shellcheck.
> I think you are conflating cases, and I agree with shellcheck on this one.

Okay.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[relevance 3%]

* Re: [PATCH 10/25] common/idpf: avoid variable 0-init
  @ 2024-05-29 13:26  0% ` Bruce Richardson
  0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2024-05-29 13:26 UTC (permalink / raw)
  To: Soumyadeep Hore; +Cc: jingjing.wu, dev

On Tue, May 28, 2024 at 07:35:50AM +0000, Soumyadeep Hore wrote:
> Dont initialize the variables if not needed.
> 
> Also use 'err' instead of 'status', 'ret_code', 'ret' etc.
> for consistency and change the return label 'sq_send_command_out'
> to 'err_unlock'.

This is consistency of naming within the driver or file, right? If so,
please clarify in commit message.

Also, this patch does not appear to be properly threaded. When sending new
revisions, I'd recommend sending them all in one batch using "git
send-email", so that all patches are in reply to the cover letter. [And
when sending v2, v3, don't forget in-reply-to to thread them all off the v1
cover letter, thanks!]

/Bruce

> 
> Signed-off-by: Soumyadeep Hore <soumyadeep.hore@intel.com>
> ---
>  drivers/common/idpf/base/idpf_controlq.c      | 60 +++++++++----------
>  .../common/idpf/base/idpf_controlq_setup.c    | 16 ++---
>  2 files changed, 37 insertions(+), 39 deletions(-)
>
<snip> 

^ permalink raw reply	[relevance 0%]

* [PATCH 04/14] clk: ti: clk-k3: use IS_ENABLED macro and fix the clock-data order
  2024-05-29 13:24  1% [PATCH 00/14] Add basic U-Boot Support for J722S-EVM Jayesh Choudhary
@ 2024-05-29 13:24  5% ` Jayesh Choudhary
  0 siblings, 0 replies; 200+ results
From: Jayesh Choudhary @ 2024-05-29 13:24 UTC (permalink / raw)
  To: u-boot, trini, jh80.chung, lukma, seanga2, vaishnav.a, n-francis,
	u-kumar1, sumit.garg, afd, j-choudhary
  Cc: vigneshr, nm, bb, rogerq

Use IS_ENABLED macro for the platform clock-data list and add them
in alphabetical order.

Reviewed-by: Bryan Brattlof <bb@ti.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
---
 drivers/clk/ti/clk-k3.c | 41 +++++++++++++++++++++--------------------
 1 file changed, 21 insertions(+), 20 deletions(-)

diff --git a/drivers/clk/ti/clk-k3.c b/drivers/clk/ti/clk-k3.c
index 41e5022ea0..9e17755c24 100644
--- a/drivers/clk/ti/clk-k3.c
+++ b/drivers/clk/ti/clk-k3.c
@@ -59,6 +59,24 @@ static void clk_add_map(struct ti_clk_data *data, struct clk *clk,
 }
 
 static const struct soc_attr ti_k3_soc_clk_data[] = {
+#if IS_ENABLED(CONFIG_SOC_K3_AM625)
+	{
+		.family = "AM62X",
+		.data = &am62x_clk_platdata,
+	},
+#endif
+#if IS_ENABLED(CONFIG_SOC_K3_AM62A7)
+	{
+		.family = "AM62AX",
+		.data = &am62ax_clk_platdata,
+	},
+#endif
+#if IS_ENABLED(CONFIG_SOC_K3_AM62P5)
+	{
+		.family = "AM62PX",
+		.data = &am62px_clk_platdata,
+	},
+#endif
 #if IS_ENABLED(CONFIG_SOC_K3_J721E)
 	{
 		.family = "J721E",
@@ -68,35 +86,18 @@ static const struct soc_attr ti_k3_soc_clk_data[] = {
 		.family = "J7200",
 		.data = &j7200_clk_platdata,
 	},
-#elif CONFIG_SOC_K3_J721S2
+#endif
+#if IS_ENABLED(CONFIG_SOC_K3_J721S2)
 	{
 		.family = "J721S2",
 		.data = &j721s2_clk_platdata,
 	},
 #endif
-#ifdef CONFIG_SOC_K3_AM625
-	{
-		.family = "AM62X",
-		.data = &am62x_clk_platdata,
-	},
-#endif
-#ifdef CONFIG_SOC_K3_AM62A7
-	{
-		.family = "AM62AX",
-		.data = &am62ax_clk_platdata,
-	},
-#endif
-#ifdef CONFIG_SOC_K3_J784S4
+#if IS_ENABLED(CONFIG_SOC_K3_J784S4)
 	{
 		.family = "J784S4",
 		.data = &j784s4_clk_platdata,
 	},
-#endif
-#ifdef CONFIG_SOC_K3_AM62P5
-	{
-		.family = "AM62PX",
-		.data = &am62px_clk_platdata,
-	},
 #endif
 	{ /* sentinel */ }
 };
-- 
2.25.1


^ permalink raw reply related	[relevance 5%]

* Re: Thread for updating minor properties of tracked regressions [consider ignoring it!]
  @ 2024-05-29 13:25  0% ` Linux regression tracking (Thorsten Leemhuis)
  0 siblings, 0 replies; 200+ results
From: Linux regression tracking (Thorsten Leemhuis) @ 2024-05-29 13:25 UTC (permalink / raw)
  To: Linux kernel regressions list



On 09.03.24 11:18, Thorsten Leemhuis wrote:
> Hi! This is the start of a thread I'll use for updating minor properties
> of regressions tracked by regzbot. Consider telling your mailer to
> ignore this thread, the replies are unlikely to be of relevance for you,
> but done here to ensure a public paper trail.

#regzbot report:
https://lore.kernel.org/all/CAHj4cs9KZJc6Wsp9t0fDc4fDBJB1TmwGT7-8peCGLiqW3J_Fqw@mail.gmail.com/
#regzbot introduced: d74169ceb0d2e32438946a2f1f9fc8c803304bd6
#regzbot summary: iommu/vt-d: blktests block/008 lead kerne panic

#regzbot report:
https://lore.kernel.org/all/CABXGCsOkiGxAfA9tPKjYX7wqjBZQxqK2PzTcW-RgLfgo8G74EQ@mail.gmail.com/
#regzbot introduced: 86167183a17e03ec77198897975e9fdfbd53cb0b
#regzbot summary:

#regzbot report: https://bugzilla.kernel.org/show_bug.cgi?id=218895
#regzbot introduced: 0a44dfc07074
#regzbot summary: wifi: mt76: MT7615E doesn't work any more with v6.9
#regzbot relate:
https://lore.kernel.org/all/20240528142308.3f7db1821e68.I531135d7ad76331a50244d6d5288e14aa9668390@changeid/

#regzbot report: https://bugzilla.kernel.org/show_bug.cgi?id=218890
#regzbot introduced: 321da3dc1f3c92
#regzbot summary: scsi: sd: usb_storage: uas: device only accessible
after about 1 minute

#regzbot report: https://bugzilla.kernel.org/show_bug.cgi?id=218896
#regzbot introduced: b8b8b4e0c052b
#regzbot summary: ata: ahci: SATA devices on Alder-Lake S not recognized

^ permalink raw reply	[relevance 0%]

* [PATCH 00/14] Add basic U-Boot Support for J722S-EVM
@ 2024-05-29 13:24  1% Jayesh Choudhary
  2024-05-29 13:24  5% ` [PATCH 04/14] clk: ti: clk-k3: use IS_ENABLED macro and fix the clock-data order Jayesh Choudhary
  0 siblings, 1 reply; 200+ results
From: Jayesh Choudhary @ 2024-05-29 13:24 UTC (permalink / raw)
  To: u-boot, trini, jh80.chung, lukma, seanga2, vaishnav.a, n-francis,
	u-kumar1, sumit.garg, afd, j-choudhary
  Cc: vigneshr, nm, bb, rogerq

Hello there,

This series add the U-Boot support for our new platform of K3-SOC
family - J722S-EVM which is a superset of AM62P. It shares the same
memory map and thus the nodes are being reused from AM62P includes
instead of duplicating the definitions.

Some highlights of J722S SoC (in addition to AM62P SoC features) are:

- Two Cortex-R5F for Functional Safety or general-purpose usage and
  two C7x floating point vector DSP with Matrix Multiply Accelerator
  for deep learning.
  
- Vision Processing Accelerator (VPAC) with image signal processor
  and Depth and Motion Processing Accelerator (DMPAC).

- 7xUARTs, 3xSPI, 5xI2C, 2xUSB2, 2xCAN-FD, 3xMMC and SD, GPMC for
  NAND/FPGA connection, OSPI memory controller, 5xMcASP for audio,
  4xCSI-RX for Camera, 1 PCIe Gen3 controller, USB3.0 eCAP/eQEP,
  ePWM, among other peripherals.
  
TRM: <https://www.ti.com/lit/zip/sprujb3>
Schematics: <https://www.ti.com/lit/zip/sprr495>

Boot test log:
<https://gist.github.com/Jayesh2000/838fe1b6f69cb3a6e44c56d07c835c65>

RFC series that was posted before this:
<https://lore.kernel.org/all/20240404090039.87458-1-j-choudhary@ti.com/>

Changes from RFC series to this series:
- Remove main_pktdma node and k3_sysreset node from
  k3-j722s-evm-u-boot.dtsi as suggested by Andrew[0]
  k3_sysreset will be taken care of in [1] which is not
  a real dependency for this series
- Fix documentation according to comments here[2]
- Pick up R-by for 2 patches from RFC series[3][4]
- Pick the binman change for optional DM[5]
- Move init code according to [6]


[0]: https://lore.kernel.org/all/d738eaaf-6f13-4502-98a1-ef1bfe82d2ff@ti.com/
[1]: https://lore.kernel.org/all/20240402160908.508974-3-afd@ti.com/
[2]: https://lore.kernel.org/all/ac5780c5-f1ca-4138-a027-d3ed65911733@ti.com/
[3]: https://lore.kernel.org/all/20240404163641.6qmcierya6svcgfb@bryanbrattlof.com/
[4]: https://lore.kernel.org/all/20240404163714.p2wonpenkiz44cnd@bryanbrattlof.com/
[5]: https://lore.kernel.org/all/20240529074849.363281-1-n-francis@ti.com/
[6]: https://lore.kernel.org/all/20240510202124.794448-1-afd@ti.com/

Jayesh Choudhary (14):
  arm: mach-k3: Sort CONFIG_SOC* and K3_SOC_ID entries
  soc: ti: k3-socinfo: Fix SOC JTAG entry order
  soc: add info to identify the J722S SoC family
  clk: ti: clk-k3: use IS_ENABLED macro and fix the clock-data order
  power: domain: ti: Fix the order for platform data entries
  arm: mach-k3: r5: Makefile: Fix the order for entries
  arm: mach-k3: j722s: introduce clock and device files for wkup spl
  ram: k3-ddrss: Enable the am62ax's DDR controller for J722S
  arch: mach-k3: Introduce basic files to support J722S SoC family
  board: ti: Introduce basic board files for the J722S family
  firmware: ti_sci_static_data: Add static DMA channel
  arm: dts: Introduce J722S U-Boot dts files
  configs: introduce configs needed for the J722S
  doc: board: ti: Add J722S-EVM documentation

 arch/arm/dts/Makefile                         |    2 +
 arch/arm/dts/k3-j722s-binman.dtsi             |  172 +
 arch/arm/dts/k3-j722s-ddr-lp4-50-3733.dtsi    | 2795 +++++++++++++++++
 arch/arm/dts/k3-j722s-evm-u-boot.dtsi         |   18 +
 arch/arm/dts/k3-j722s-r5-evm.dts              |   82 +
 arch/arm/mach-k3/Kconfig                      |    7 +-
 arch/arm/mach-k3/Makefile                     |    1 +
 arch/arm/mach-k3/include/mach/hardware.h      |   43 +-
 .../arm/mach-k3/include/mach/j722s_hardware.h |   83 +
 arch/arm/mach-k3/include/mach/j722s_spl.h     |   49 +
 arch/arm/mach-k3/include/mach/spl.h           |    4 +
 arch/arm/mach-k3/j722s/Kconfig                |   32 +
 arch/arm/mach-k3/j722s/Makefile               |    6 +
 arch/arm/mach-k3/j722s/j722s_init.c           |  277 ++
 arch/arm/mach-k3/r5/Makefile                  |    7 +-
 arch/arm/mach-k3/r5/j722s/Makefile            |    6 +
 arch/arm/mach-k3/r5/j722s/clk-data.c          |  312 ++
 arch/arm/mach-k3/r5/j722s/dev-data.c          |   69 +
 board/ti/j722s/Kconfig                        |   26 +
 board/ti/j722s/MAINTAINERS                    |    9 +
 board/ti/j722s/Makefile                       |    7 +
 board/ti/j722s/board-cfg.yaml                 |   36 +
 board/ti/j722s/evm.c                          |   29 +
 board/ti/j722s/j722s.env                      |   15 +
 board/ti/j722s/pm-cfg.yaml                    |   12 +
 board/ti/j722s/rm-cfg.yaml                    | 1119 +++++++
 board/ti/j722s/sec-cfg.yaml                   |  379 +++
 board/ti/j722s/tifs-rm-cfg.yaml               |  981 ++++++
 configs/j722s_evm_a53_defconfig               |  177 ++
 configs/j722s_evm_r5_defconfig                |  137 +
 doc/board/ti/j722s_evm.rst                    |  260 ++
 doc/board/ti/k3.rst                           |    1 +
 drivers/clk/ti/clk-k3.c                       |   41 +-
 drivers/firmware/ti_sci_static_data.h         |    2 +-
 drivers/power/domain/ti-power-domain.c        |   36 +-
 drivers/ram/Kconfig                           |    2 +-
 drivers/soc/soc_ti_k3.c                       |   29 +-
 include/configs/j722s_evm.h                   |   14 +
 include/k3-clk.h                              |    1 +
 include/k3-dev.h                              |    1 +
 40 files changed, 7210 insertions(+), 69 deletions(-)
 create mode 100644 arch/arm/dts/k3-j722s-binman.dtsi
 create mode 100644 arch/arm/dts/k3-j722s-ddr-lp4-50-3733.dtsi
 create mode 100644 arch/arm/dts/k3-j722s-evm-u-boot.dtsi
 create mode 100644 arch/arm/dts/k3-j722s-r5-evm.dts
 create mode 100644 arch/arm/mach-k3/include/mach/j722s_hardware.h
 create mode 100644 arch/arm/mach-k3/include/mach/j722s_spl.h
 create mode 100644 arch/arm/mach-k3/j722s/Kconfig
 create mode 100644 arch/arm/mach-k3/j722s/Makefile
 create mode 100644 arch/arm/mach-k3/j722s/j722s_init.c
 create mode 100644 arch/arm/mach-k3/r5/j722s/Makefile
 create mode 100644 arch/arm/mach-k3/r5/j722s/clk-data.c
 create mode 100644 arch/arm/mach-k3/r5/j722s/dev-data.c
 create mode 100644 board/ti/j722s/Kconfig
 create mode 100644 board/ti/j722s/MAINTAINERS
 create mode 100644 board/ti/j722s/Makefile
 create mode 100644 board/ti/j722s/board-cfg.yaml
 create mode 100644 board/ti/j722s/evm.c
 create mode 100644 board/ti/j722s/j722s.env
 create mode 100644 board/ti/j722s/pm-cfg.yaml
 create mode 100644 board/ti/j722s/rm-cfg.yaml
 create mode 100644 board/ti/j722s/sec-cfg.yaml
 create mode 100644 board/ti/j722s/tifs-rm-cfg.yaml
 create mode 100644 configs/j722s_evm_a53_defconfig
 create mode 100644 configs/j722s_evm_r5_defconfig
 create mode 100644 doc/board/ti/j722s_evm.rst
 create mode 100644 include/configs/j722s_evm.h

-- 
2.25.1


^ permalink raw reply	[relevance 1%]

* RE: [PATCH v2 03/10] drm/amdgpu: abort fence poll if reset is started
  @ 2024-05-29 13:22  1%     ` Li, Yunxiang (Teddy)
  2024-05-29 13:31  0%       ` Christian König
  0 siblings, 1 reply; 200+ results
From: Li, Yunxiang (Teddy) @ 2024-05-29 13:22 UTC (permalink / raw)
  To: Koenig, Christian, amd-gfx

[Public]

> It's perfectly possible that the reset has already started before we enter the function.

Yeah, this could and does happen, but it just means we are back to the old behavior. I guess I could use "can I take the read side lock?" to test if the function is called outside of reset or not, would that be acceptable?

So like:
Int not_in_reset = read_try_lock(reset sem);
while (...) {
  if (not_in_reset && amdgpu_in_reset())
      break;
}
If (not_in_reset)
   up_read(reset sem)

^ permalink raw reply	[relevance 1%]

* Re: [PATCH 1/2] Revert "monitor: use aio_co_reschedule_self()"
  @ 2024-05-29 13:20  3%     ` Kevin Wolf
  0 siblings, 0 replies; 200+ results
From: Kevin Wolf @ 2024-05-29 13:20 UTC (permalink / raw)
  To: Fiona Ebner
  Cc: Stefan Hajnoczi, qemu-devel, Markus Armbruster, Michael Roth,
	Hanna Czenczek, qemu-block, Fam Zheng, qemu-stable

Am 29.05.2024 um 12:33 hat Fiona Ebner geschrieben:
> CC-ing stable since 1f25c172f83704e350c0829438d832384084a74d is in 9.0.0

Good point, I'm also updating the commit message in my tree to add
a Cc: line. Thanks for catching this, Fiona!

Kevin



^ permalink raw reply	[relevance 3%]

* Re: [PATCH v2 3/3] mctp pcc: Implement MCTP over PCC Transport
  @ 2024-05-29 13:21  1% ` kernel test robot
  0 siblings, 0 replies; 200+ results
From: kernel test robot @ 2024-05-29 13:21 UTC (permalink / raw)
  To: admiyo, Jeremy Kerr, Matt Johnston, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni
  Cc: oe-kbuild-all, netdev, linux-kernel

Hi,

kernel test robot noticed the following build errors:

[auto build test ERROR on rafael-pm/linux-next]
[also build test ERROR on rafael-pm/bleeding-edge linus/master v6.10-rc1 next-20240529]
[cannot apply to horms-ipvs/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/admiyo-os-amperecomputing-com/mctp-pcc-Check-before-sending-MCTP-PCC-response-ACK/20240529-072116
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link:    https://lore.kernel.org/r/20240528191823.17775-4-admiyo%40os.amperecomputing.com
patch subject: [PATCH v2 3/3] mctp pcc: Implement MCTP over PCC Transport
config: loongarch-allmodconfig (https://download.01.org/0day-ci/archive/20240529/202405292136.ZyuCa1Fc-lkp@intel.com/config)
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240529/202405292136.ZyuCa1Fc-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405292136.ZyuCa1Fc-lkp@intel.com/

All errors (new ones prefixed by >>):

   drivers/net/mctp/mctp-pcc.c:331:10: error: 'struct acpi_driver' has no member named 'owner'
     331 |         .owner = THIS_MODULE,
         |          ^~~~~
   In file included from include/linux/printk.h:6,
                    from include/asm-generic/bug.h:22,
                    from arch/loongarch/include/asm/bug.h:60,
                    from include/linux/bug.h:5,
                    from include/linux/thread_info.h:13,
                    from include/asm-generic/preempt.h:5,
                    from ./arch/loongarch/include/generated/asm/preempt.h:1,
                    from include/linux/preempt.h:79,
                    from include/linux/spinlock.h:56,
                    from include/linux/mmzone.h:8,
                    from include/linux/gfp.h:7,
                    from include/linux/slab.h:16,
                    from include/linux/resource_ext.h:11,
                    from include/linux/acpi.h:13,
                    from drivers/net/mctp/mctp-pcc.c:7:
>> include/linux/init.h:180:21: error: initialization of 'const char *' from incompatible pointer type 'struct module *' [-Werror=incompatible-pointer-types]
     180 | #define THIS_MODULE (&__this_module)
         |                     ^
   drivers/net/mctp/mctp-pcc.c:331:18: note: in expansion of macro 'THIS_MODULE'
     331 |         .owner = THIS_MODULE,
         |                  ^~~~~~~~~~~
   include/linux/init.h:180:21: note: (near initialization for 'mctp_pcc_driver.drv.name')
     180 | #define THIS_MODULE (&__this_module)
         |                     ^
   drivers/net/mctp/mctp-pcc.c:331:18: note: in expansion of macro 'THIS_MODULE'
     331 |         .owner = THIS_MODULE,
         |                  ^~~~~~~~~~~
   drivers/net/mctp/mctp-pcc.c:322:45: warning: missing braces around initializer [-Wmissing-braces]
     322 | static struct acpi_driver mctp_pcc_driver = {
         |                                             ^
   drivers/net/mctp/mctp-pcc.c: In function 'mctp_pcc_mod_init':
   drivers/net/mctp/mctp-pcc.c:343:80: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
     343 |                 ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Error registering driver\n"));
         |                                                                                ^
   cc1: some warnings being treated as errors


vim +180 include/linux/init.h

f2511774863487e Arjan van de Ven 2009-12-13  177  
5b20755b7780464 Masahiro Yamada  2023-11-26  178  #ifdef MODULE
5b20755b7780464 Masahiro Yamada  2023-11-26  179  extern struct module __this_module;
5b20755b7780464 Masahiro Yamada  2023-11-26 @180  #define THIS_MODULE (&__this_module)
5b20755b7780464 Masahiro Yamada  2023-11-26  181  #else
5b20755b7780464 Masahiro Yamada  2023-11-26  182  #define THIS_MODULE ((struct module *)0)
5b20755b7780464 Masahiro Yamada  2023-11-26  183  #endif
5b20755b7780464 Masahiro Yamada  2023-11-26  184  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[relevance 1%]

* [PATCH v2 0/3] gpiolib: cdev: tidy up kfifo handling
@ 2024-05-29 13:19  1% Kent Gibson
  0 siblings, 0 replies; 200+ results
From: Kent Gibson @ 2024-05-29 13:19 UTC (permalink / raw)
  To: linux-kernel, linux-gpio, brgl, linus.walleij; +Cc: Kent Gibson

This series is a follow up to my recent kfifo initialisation fix[1].

Patch 1 adds calling INIT_KFIFO() on the event kfifo in order to induce
an oops if the kfifo is accessed prior to being allocated.  Not calling
INIT_KFIFO() could be considered an abuse of the kfifo API. I don't
recall, but it is possible that it was not being called as we also make
use of kfifo_initialized(), and the assumption was that it would return
true after the INIT_KFIFO() call. In fact it only returns true once
the kfifo has been allocated.

Patch 2 adds a helper to perform the allocation of the kfifo to reduce
code duplication.

Patch 3 tidies up the handling of kfifo_out() errors, making them
visible where they may currently be obscured.  These errors are not
expected to ever happen, so this should not produce any visible
difference, but if they do occur it will now be more obvious.

Cheers,
Kent.

Changes v1 -> v2:
 - add WARN() to patch 3.

Kent Gibson (3):
  gpiolib: cdev: Add INIT_KFIFO() for linereq events
  gpiolib: cdev: Refactor allocation of linereq events kfifo
  gpiolib: cdev: Cleanup kfifo_out() error handling

 drivers/gpio/gpiolib-cdev.c | 80 +++++++++++++++++++------------------
 1 file changed, 41 insertions(+), 39 deletions(-)

--
2.39.2


^ permalink raw reply	[relevance 1%]

* Re: [PATCH v2] regulator: gpio: Correct default GPIO state to LOW
  2024-05-29 13:15  0% ` Mark Brown
@ 2024-05-29 13:19  0%   ` Geert Uytterhoeven
  0 siblings, 0 replies; 200+ results
From: Geert Uytterhoeven @ 2024-05-29 13:19 UTC (permalink / raw)
  To: Mark Brown
  Cc: Liam Girdwood, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Marek Szyprowski, devicetree, linux-gpio,
	linux-kernel

Hi Mark,

On Wed, May 29, 2024 at 3:15 PM Mark Brown <broonie@kernel.org> wrote:
> On Wed, May 29, 2024 at 11:49:51AM +0200, Geert Uytterhoeven wrote:
> > According to the GPIO regulator DT bindings[1], the default GPIO state
> > is LOW.  However, the driver defaults to HIGH.
>
> > Before the conversion to descriptors in commit d6cd33ad71029a3f
> > ("regulator: gpio: Convert to use descriptors"), the default state used
> > by the driver was rather ill-defined, too:
>
> That was 4 years ago...
>
> > I have no idea if this has any impact.
> > I guess most/all DTS files have proper gpios-states properties?
>
> That seems optimistic, and a grep in mainline shows some users but not
> really as many as I'd intuitively expect.
>
> > -                     /* Default to high per specification */
> > +                     /* Default to low per specification */
> >                       if (ret)
> > -                             config->gflags[i] = GPIOD_OUT_HIGH;
> > +                             config->gflags[i] = GPIOD_OUT_LOW;
> >                       else
>
> The risk here is that we start glitching the power where previously we
> didn't.  This does make me nervous.

/me too

The alternative is to change the GPIO regulator DT bindings document
to match the code...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[relevance 0%]

* Re: [PATCH libgpiod v2 2/4] tools: tests: use "$@" instead of $*
  2024-05-29 13:08  3%         ` Andy Shevchenko
@ 2024-05-29 13:18  3%           ` Kent Gibson
  2024-05-29 13:27  3%             ` Andy Shevchenko
  0 siblings, 1 reply; 200+ results
From: Kent Gibson @ 2024-05-29 13:18 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: Bartosz Golaszewski, Linus Walleij, Bartosz Golaszewski, linux-gpio

On Wed, May 29, 2024 at 04:08:49PM +0300, Andy Shevchenko wrote:
> On Tue, May 28, 2024 at 07:39:10AM +0800, Kent Gibson wrote:
> > On Mon, May 27, 2024 at 07:17:37PM +0300, Andy Shevchenko wrote:
> > > On Mon, May 27, 2024 at 08:44:20PM +0800, Kent Gibson wrote:
> > > > On Mon, May 27, 2024 at 02:02:34PM +0200, Bartosz Golaszewski wrote:
>
> ...
>
> > > > >  assert_fail() {
> > > > > -	$* || return 0
> > > > > -	fail " '$*': command did not fail as expected"
> > > > > +	"$@" || return 0
> > > > > +	fail " '$@': command did not fail as expected"
> > > > >  }
> > > >
> > > > Ironically, shellcheck doesn't like the '$@' in the fail string[1], so you
> > > > should use $* there.
> > >
> > > But why does it do like this?
> >
> > Read the link[1].
>
> Okay, this is only for some debug / error messages. Still if one wants to have
> clear understanding on what has been passed to some function, $* is not a
> correct option. Also note the single quotes, shouldn't that protect from the
> arguments loss?
>

That's right - I was only referring to this particular case where a
string is being constructed.  Wasn't that clear?

The single quotes are within double quotes, so aren't they just part of
the text in this context?

> > Because $@ is an array being used to build a string, and that may not
> > work the way you expect.
>
> I think it's the opposite, $* works in a way I do not expect :-)
>

When passing arguments, sure.  Not when constructing strings.

> > In this case $* is clearer as that has already
> > been concatenated.
>
> ...loosing information about which word refers to which argument, yes.
>

It is building a string, so arguments are irrelevant.


> > [1] https://www.shellcheck.net/wiki/SC2145
>
> TL;DR: I consider this is still a bug in shellcheck. But if you rely on the
> tool as on the ruleset carved in stone, I will not die. Just a remark to
> myself "even honourable tools may also be broken".
>

If you think it is a bug then raise it with shellcheck.
I think you are conflating cases, and I agree with shellcheck on this one.

Cheers,
Kent.

^ permalink raw reply	[relevance 3%]

* Re: [PATCH 2/2] HID: intel-ish-hid: fix endian-conversion
  @ 2024-05-29 13:18  0%     ` Arnd Bergmann
  0 siblings, 0 replies; 200+ results
From: Arnd Bergmann @ 2024-05-29 13:18 UTC (permalink / raw)
  To: Lixu Zhang, Arnd Bergmann, srinivas.pandruvada, Jiri Kosina,
	Benjamin Tissoires
  Cc: linux-input, linux-kernel

On Wed, May 29, 2024, at 09:05, Zhang, Lixu wrote:

>>
>> 	for (i = 0; i < fragment->fragment_cnt && offset < ish_fw->size; i++) {
> You added a parameter fragment_count, but you didn't use it. Did you 
> intend to use it here?
>

My mistake, that was again broken in my incorrect
rebase.

     Arnd

^ permalink raw reply	[relevance 0%]

* [scarthgap][PATCH] libdeflate: fix build with -mcpu=cortex-a76+crypto without -march=armv8.2-a+crypto
@ 2024-05-29 13:16 14% Martin Jansa
  0 siblings, 0 replies; 200+ results
From: Martin Jansa @ 2024-05-29 13:16 UTC (permalink / raw)
  To: openembedded-devel; +Cc: Martin Jansa, Khem Raj

* fixes:
  https://github.com/ebiggers/libdeflate/issues/369

Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 ...e-explicit-armv8.2-a-on-gcc-13.2-and.patch | 57 +++++++++++++++++++
 .../libdeflate/libdeflate_1.20.bb             |  5 +-
 2 files changed, 60 insertions(+), 2 deletions(-)
 create mode 100644 meta-oe/recipes-extended/libdeflate/libdeflate/0001-lib-arm-don-t-use-explicit-armv8.2-a-on-gcc-13.2-and.patch

diff --git a/meta-oe/recipes-extended/libdeflate/libdeflate/0001-lib-arm-don-t-use-explicit-armv8.2-a-on-gcc-13.2-and.patch b/meta-oe/recipes-extended/libdeflate/libdeflate/0001-lib-arm-don-t-use-explicit-armv8.2-a-on-gcc-13.2-and.patch
new file mode 100644
index 0000000000..e87972af27
--- /dev/null
+++ b/meta-oe/recipes-extended/libdeflate/libdeflate/0001-lib-arm-don-t-use-explicit-armv8.2-a-on-gcc-13.2-and.patch
@@ -0,0 +1,57 @@
+From 684ebc7f8eb44558219d4b5be52add1250b3c0ca Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Tue, 30 Apr 2024 11:27:55 -0700
+Subject: [PATCH] lib/arm: don't use explicit armv8.2-a on gcc 13.2 and later
+
+Resolves https://github.com/ebiggers/libdeflate/issues/369
+---
+Upstream-Status: Backport [https://github.com/ebiggers/libdeflate/pull/370]
+
+ lib/arm/adler32_impl.h | 10 ++++++----
+ lib/arm/crc32_impl.h   | 10 ++++++----
+ 2 files changed, 12 insertions(+), 8 deletions(-)
+
+diff --git a/lib/arm/adler32_impl.h b/lib/arm/adler32_impl.h
+index 6453b8e..6144afb 100644
+--- a/lib/arm/adler32_impl.h
++++ b/lib/arm/adler32_impl.h
+@@ -214,11 +214,13 @@ adler32_arm_neon(u32 adler, const u8 *p, size_t len)
+ #  ifdef __clang__
+ #    define ATTRIBUTES	_target_attribute("dotprod")
+    /*
+-    * With gcc, arch=armv8.2-a is needed for dotprod intrinsics, unless the
+-    * default target is armv8.3-a or later in which case it must be omitted.
+-    * armv8.3-a or later can be detected by checking for __ARM_FEATURE_JCVT.
++    * With gcc 13.1 and earlier (before gcc commit 73d3bc348190 or 9aac37ab8a7b,
++    * "aarch64: Remove architecture dependencies from intrinsics"),
++    * arch=armv8.2-a is needed for the dotprod intrinsics, unless the default
++    * target is armv8.3-a or later in which case it must be omitted.  armv8.3-a
++    * or later can be detected by checking for __ARM_FEATURE_JCVT.
+     */
+-#  elif defined(__ARM_FEATURE_JCVT)
++#  elif GCC_PREREQ(13, 2) || defined(__ARM_FEATURE_JCVT)
+ #    define ATTRIBUTES	_target_attribute("+dotprod")
+ #  else
+ #    define ATTRIBUTES	_target_attribute("arch=armv8.2-a+dotprod")
+diff --git a/lib/arm/crc32_impl.h b/lib/arm/crc32_impl.h
+index 3c4bec7..5363041 100644
+--- a/lib/arm/crc32_impl.h
++++ b/lib/arm/crc32_impl.h
+@@ -551,11 +551,13 @@ crc32_arm_pmullx4(u32 crc, const u8 *p, size_t len)
+ #  ifdef __clang__
+ #    define ATTRIBUTES	_target_attribute("aes,crc,sha3")
+    /*
+-    * With gcc, arch=armv8.2-a is needed for the sha3 intrinsics, unless the
+-    * default target is armv8.3-a or later in which case it must be omitted.
+-    * armv8.3-a or later can be detected by checking for __ARM_FEATURE_JCVT.
++    * With gcc 13.1 and earlier (before gcc commit 73d3bc348190 or 9aac37ab8a7b,
++    * "aarch64: Remove architecture dependencies from intrinsics"),
++    * arch=armv8.2-a is needed for the sha3 intrinsics, unless the default
++    * target is armv8.3-a or later in which case it must be omitted.  armv8.3-a
++    * or later can be detected by checking for __ARM_FEATURE_JCVT.
+     */
+-#  elif defined(__ARM_FEATURE_JCVT)
++#  elif GCC_PREREQ(13, 2) || defined(__ARM_FEATURE_JCVT)
+ #    define ATTRIBUTES	_target_attribute("+crypto,+crc,+sha3")
+ #  else
+ #    define ATTRIBUTES	_target_attribute("arch=armv8.2-a+crypto+crc+sha3")
diff --git a/meta-oe/recipes-extended/libdeflate/libdeflate_1.20.bb b/meta-oe/recipes-extended/libdeflate/libdeflate_1.20.bb
index f0a966f2b4..e3de8aca62 100644
--- a/meta-oe/recipes-extended/libdeflate/libdeflate_1.20.bb
+++ b/meta-oe/recipes-extended/libdeflate/libdeflate_1.20.bb
@@ -6,10 +6,11 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=7b6977026437092191e9da699ed9f780"
 
 DEPENDS += "gzip zlib"
 
-SRC_URI = "git://github.com/ebiggers/libdeflate.git;protocol=https;branch=master"
+SRC_URI = "git://github.com/ebiggers/libdeflate.git;protocol=https;branch=master \
+    file://0001-lib-arm-don-t-use-explicit-armv8.2-a-on-gcc-13.2-and.patch \
+"
 
 S = "${WORKDIR}/git"
 SRCREV = "275aa5141db6eda3587214e0f1d3a134768f557d"
 
 inherit cmake pkgconfig
-
-- 
2.45.1



^ permalink raw reply related	[relevance 14%]

* Re: [PATCH v9 06/10] math.h: Add macros for rounding to closest value
  @ 2024-05-29 13:17  0%       ` Andy Shevchenko
  0 siblings, 0 replies; 200+ results
From: Andy Shevchenko @ 2024-05-29 13:17 UTC (permalink / raw)
  To: Devarsh Thakkar
  Cc: mchehab, hverkuil-cisco, linux-media, linux-kernel,
	benjamin.gaignard, sebastian.fricke, akpm, gregkh, adobriyan,
	jani.nikula, p.zabel, airlied, daniel, dri-devel,
	laurent.pinchart, praneeth, nm, vigneshr, a-bhatia1, j-luthra,
	b-brnich, detheridge, p-mantena, vijayp, andrzej.p, nicolas,
	davidgow, dlatypov

On Tue, May 28, 2024 at 04:02:30PM +0530, Devarsh Thakkar wrote:
> On 28/05/24 02:02, Andy Shevchenko wrote:
> > On Sun, May 26, 2024 at 11:38:56PM +0530, Devarsh Thakkar wrote:

...

> >> +/**
> >> + * round_closest_up - round closest to be multiple of specified value (which is
> >> + *                    power of 2) with preference to rounding up
> >> +
> > 
> > Not that big deal, but missing '*' here. Personally I would not even put
> > a blank line between Summary and Field Descriptions.
> 
> My bad. Yes I would remove the blank line here. This is picked up as warning
> from kernel-doc too.
> 
> >> + * @x: the value to round
> >> + * @y: multiple to round closest to (must be a power of 2)
> >> + *
> >> + * Rounds @x to closest multiple of @y (which must be a power of 2).
> >> + * The value can be either rounded up or rounded down depending upon rounded
> >> + * value's closeness to the specified value. If there are two closest possible
> >> + * values, i.e. the difference between the specified value and it's rounded up
> >> + * and rounded down values is same then preference is given to rounded up
> >> + * value.
> >> + *
> >> + * To perform arbitrary rounding to closest value (not multiple of 2), use
> >> + * roundclosest().
> >> + *
> >> + * Examples :
> > 
> > What is this suppose to be rendered to?
> 
> The file math.h is not rendered as part of kernel-doc right now. I can put
> this under Documentation/core-api/kernel-api.rst perhaps I can create a new
> section as below:
> 
> Rounding, absolute diff and 32bit division macros
> -------------------------------------------------
> 
> under the section:
> CRC and Math Functions in Linux
> 
> ===============================
> 
> is that okay ?

This is up to you, but what I meant is that you always can render manually
yourself. And I was asking about the result you got when you tried (and you
did, right?) to render to man, html, and pdf.

> >> + * round_closest_up(17, 4) = 16
> >> + * round_closest_up(15, 4) = 16
> >> + * round_closest_up(14, 4) = 16
> > 
> > Btw, is kernel-doc validator happy about all kernel docs you added?
> 
> Yes, except the aforementioned blank line.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[relevance 0%]

* Re: NFSD: Unable to initialize client recovery tracking! (-110)
  2024-05-29 13:13  0%         ` Jeff Layton
@ 2024-05-29 13:16  0%           ` Chuck Lever III
  2024-05-29 13:27  0%           ` Paul Menzel
  1 sibling, 0 replies; 200+ results
From: Chuck Lever III @ 2024-05-29 13:16 UTC (permalink / raw)
  To: Jeff Layton
  Cc: Linux regressions mailing list, Paul Menzel,
	Linux NFS Mailing List, it+linux-nfs, Linus Torvalds



> On May 29, 2024, at 9:13 AM, Jeff Layton <jlayton@kernel.org> wrote:
> 
> On Fri, 2024-05-24 at 16:09 +0000, Chuck Lever III wrote:
>> 
>> 
>>> On May 24, 2024, at 7:16 AM, Linux regression tracking (Thorsten
>>> Leemhuis) <regressions@leemhuis.info> wrote:
>>> 
>>> On 21.05.24 12:01, Jeff Layton wrote:
>>>> On Tue, 2024-05-21 at 11:55 +0200, Paul Menzel wrote:
>>>>> Am 19.04.24 um 18:50 schrieb Paul Menzel:
>>>>> 
>>>>>> Since at least Linux 6.8-rc6, Linux logs the warning below:
>>>>>> 
>>>>>>     NFSD: Unable to initialize client recovery tracking! (-
>>>>>> 110)
>>>>>> 
>>>>>> I haven’t had time to bisect yet, so if you have an idea,
>>>>>> that’d be great.
>>>>> 
>>>>> 74fd48739d0488e39ae18b0168720f449a06690c is the first bad
>>>>> commit
>>>>> commit 74fd48739d0488e39ae18b0168720f449a06690c
>>>>> Author: Jeff Layton <jlayton@kernel.org>
>>>>> Date:   Fri Oct 13 09:03:53 2023 -0400
>>>>> 
>>>>>     nfsd: new Kconfig option for legacy client tracking
>>>>> 
>>>>>     We've had a number of attempts at different NFSv4 client
>>>>> tracking
>>>>>     methods over the years, but now nfsdcld has emerged as the
>>>>> clear winner
>>>>>     since the others (recoverydir and the usermodehelper
>>>>> upcall) are
>>>>>     problematic.
>>>> [...]
>>>> It sounds like you need to enable nfsdcld in your environment.
>>>> The old
>>>> recovery tracking methods are deprecated. The only surviving one
>>>> requires the nfsdcld daemon to be running when recovery tracking
>>>> is
>>>> started. Alternately, you can enable this option in your kernels
>>>> if you
>>>> want to keep using the deprecated methods in the interim.
>>> 
>>> Hmm. Then why didn't this new config option default to "Y" for a
>>> while
>>> (say a year or two) before changing the default to off? That would
>>> have
>>> prevented people like Paul from running into the problem when
>>> running
>>> "olddefconfig". I think that is what Linus would have wanted in a
>>> case
>>> like this, but might be totally wrong there (I CCed him, in case he
>>> wants to share his opinion, but maybe he does not care much).
>> 
>> That's fair. I recall we believed at the time that very few people
>> if anyone currently use a legacy recovery tracking mechanism, and
>> the workaround, if they do, is easy.
>> 
>> 
>>> But I guess that's too late now, unless we want to meddle with
>>> config
>>> option names. But I guess that might not be worth it after half a
>>> year
>>> for something that only causes a warning (aiui).
>> 
>> In Paul's case, the default behavior might prevent proper NFSv4
>> state recovery, which is a little more hazardous than a mere
>> warning, IIUC.
>> 
>> To my surprise, it often takes quite some time for changes like
>> this to matriculate into mainstream usage, so half a year isn't
>> that long. We might want to change to a more traditional
>> deprecation path (default Y with warning, wait, default N, wait,
>> redact the old code).
>> 
> 
> I've no objection if you want to do that.
> 
> I'm more concerned about Paul's setup though. Paul, what distro are you
> running that starts nfsd (and presumably, mountd, etc.), but doesn't
> bother starting nfsdcld?
> 
> Reenabling this for now is an OK workaround, but we need to understand
> where these setups are coming from, and probably do some sort of
> outreach to get them working properly.

Getting a root cause first seems prudent. I will hold off changes
for a bit.


--
Chuck Lever



^ permalink raw reply	[relevance 0%]

* Re: [PATCH] xilinx: versal: Do not prioritize boot device if driver is not enabled
  @ 2024-05-29 13:15  0% ` Michal Simek
  0 siblings, 0 replies; 200+ results
From: Michal Simek @ 2024-05-29 13:15 UTC (permalink / raw)
  To: u-boot, git
  Cc: Venkatesh Yadav Abbarapu, Polak, Leszek, Stefan Roese, Tom Rini



On 5/10/24 08:22, Michal Simek wrote:
> From: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
> 
> SOC can boot out of the device which is not accessible from APU and running
> this is detected as a warning, as the device is not accessible.For example
> getting below warning when the boot mode is OSPI and OSPI is not enabled in
> device tree.
> Invalid bus 0 (err=-19)
> Failed to initialize SPI flash at 0:0 (error -19)
> 
> Ignoring the prioritization of the boot device which driver is not enabled
> and continue with the default boot_targets. Recommendation is to use custom
> boot_targets via environment file as is done for example for Kria via
> zynqmp_kria.env file.
> 
> Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
> Signed-off-by: Michal Simek <michal.simek@amd.com>
> ---
> 
>   board/xilinx/versal/board.c | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
> 
> diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
> index 4f6d56119db1..f00605da7825 100644
> --- a/board/xilinx/versal/board.c
> +++ b/board/xilinx/versal/board.c
> @@ -151,14 +151,29 @@ static int boot_targets_setup(void)
>   		break;
>   	case QSPI_MODE_24BIT:
>   		puts("QSPI_MODE_24\n");
> +		if (uclass_get_device_by_name(UCLASS_SPI,
> +					      "spi@f1030000", &dev)) {
> +			debug("QSPI driver for QSPI device is not present\n");
> +			break;
> +		}
>   		mode = "xspi0";
>   		break;
>   	case QSPI_MODE_32BIT:
>   		puts("QSPI_MODE_32\n");
> +		if (uclass_get_device_by_name(UCLASS_SPI,
> +					      "spi@f1030000", &dev)) {
> +			debug("QSPI driver for QSPI device is not present\n");
> +			break;
> +		}
>   		mode = "xspi0";
>   		break;
>   	case OSPI_MODE:
>   		puts("OSPI_MODE\n");
> +		if (uclass_get_device_by_name(UCLASS_SPI,
> +					      "spi@f1010000", &dev)) {
> +			debug("OSPI driver for OSPI device is not present\n");
> +			break;
> +		}
>   		mode = "xspi0";
>   		break;
>   	case EMMC_MODE:

Applied.

M

^ permalink raw reply	[relevance 0%]

* Re: [PATCH wireless-next 4/8] wifi: wlcore: pass "status" to wlcore_hw_convert_fw_status()
  @ 2024-05-29 13:15  0%   ` Nemanov, Michael
  0 siblings, 0 replies; 200+ results
From: Nemanov, Michael @ 2024-05-29 13:15 UTC (permalink / raw)
  To: Russell King (Oracle), Kalle Valo
  Cc: Johannes Berg, linux-kernel, linux-wireless


On 5/28/2024 12:17 PM, Russell King (Oracle) wrote:
> wlcore_fw_status() is passed a pointer to the struct wl_fw_status to
> decode the status into, which is always wl->fw_status. Rather than
> referencing wl->fw_status within wlcore_fw_status(), use the supplied
> argument so that we access this member in a consistent manner.
>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> ---
>    drivers/net/wireless/ti/wlcore/main.c | 2 +-
>    1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
> index a98b26dc3cb8..3defe49c5120 100644
> --- a/drivers/net/wireless/ti/wlcore/main.c
> +++ b/drivers/net/wireless/ti/wlcore/main.c
> @@ -392,7 +392,7 @@ static int wlcore_fw_status(struct wl1271 *wl, struct wl_fw_status *status)
>    	if (ret < 0)
>    		return ret;
>    
> -	wlcore_hw_convert_fw_status(wl, wl->raw_fw_status, wl->fw_status);
> +	wlcore_hw_convert_fw_status(wl, wl->raw_fw_status, status);
>    
>    	wl1271_debug(DEBUG_IRQ, "intr: 0x%x (fw_rx_counter = %d, "
>    		     "drv_rx_counter = %d, tx_results_counter = %d)",
> -- 
> 2.30.2

Agree this is more consistent. Maybe *status shouldn't be an argument to 
wlcore_fw_status at all? It's called only in one place with 
wl->fw_status anyway.

Michael.


^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2] regulator: gpio: Correct default GPIO state to LOW
  @ 2024-05-29 13:15  0% ` Mark Brown
  2024-05-29 13:19  0%   ` Geert Uytterhoeven
  0 siblings, 1 reply; 200+ results
From: Mark Brown @ 2024-05-29 13:15 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Liam Girdwood, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Marek Szyprowski, devicetree, linux-gpio,
	linux-kernel

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

On Wed, May 29, 2024 at 11:49:51AM +0200, Geert Uytterhoeven wrote:
> According to the GPIO regulator DT bindings[1], the default GPIO state
> is LOW.  However, the driver defaults to HIGH.

> Before the conversion to descriptors in commit d6cd33ad71029a3f
> ("regulator: gpio: Convert to use descriptors"), the default state used
> by the driver was rather ill-defined, too:

That was 4 years ago...

> I have no idea if this has any impact.
> I guess most/all DTS files have proper gpios-states properties?

That seems optimistic, and a grep in mainline shows some users but not
really as many as I'd intuitively expect.

> -			/* Default to high per specification */
> +			/* Default to low per specification */
>  			if (ret)
> -				config->gflags[i] = GPIOD_OUT_HIGH;
> +				config->gflags[i] = GPIOD_OUT_LOW;
>  			else

The risk here is that we start glitching the power where previously we
didn't.  This does make me nervous.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[relevance 0%]

* [RESEND PATCH v2 1/3] clk: stm32mp2: use of STM32 access controller
  2024-05-29 13:13  6% ` gabriel.fernandez
@ 2024-05-29 13:13  2%   ` gabriel.fernandez
  -1 siblings, 0 replies; 200+ results
From: gabriel.fernandez @ 2024-05-29 13:13 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
	Alexandre Torgue, Michael Turquette, Stephen Boyd, Maxime Ripard,
	Gabriel Fernandez, Dan Carpenter
  Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel, linux-clk

From: Gabriel Fernandez <gabriel.fernandez@foss.st.com>

Use an STM32 access controller to filter the registration of clocks.
If a clock is used by the security world, then it must not registered.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
---
Changes in v2:
  Depends on the stm32_firewall framework (merged since next-20240419 tag)
  - replace linux/of_address.h include by linux/io.h
  - manage the case if the property 'access-controllers' is not present
    (allow registering of all clocks).

 drivers/clk/stm32/clk-stm32-core.c |   2 +-
 drivers/clk/stm32/clk-stm32-core.h |   2 +-
 drivers/clk/stm32/clk-stm32mp13.c  |   2 +-
 drivers/clk/stm32/clk-stm32mp25.c  | 482 +++++++++++++++++------------
 4 files changed, 290 insertions(+), 198 deletions(-)

diff --git a/drivers/clk/stm32/clk-stm32-core.c b/drivers/clk/stm32/clk-stm32-core.c
index 1721a3ed7386..933e3cde0795 100644
--- a/drivers/clk/stm32/clk-stm32-core.c
+++ b/drivers/clk/stm32/clk-stm32-core.c
@@ -46,7 +46,7 @@ static int stm32_rcc_clock_init(struct device *dev,
 		struct clk_hw *hw = ERR_PTR(-ENOENT);
 
 		if (data->check_security &&
-		    data->check_security(base, cfg_clock))
+		    data->check_security(dev->of_node, base, cfg_clock))
 			continue;
 
 		if (cfg_clock->func)
diff --git a/drivers/clk/stm32/clk-stm32-core.h b/drivers/clk/stm32/clk-stm32-core.h
index bb5aa19a792d..4be103710e12 100644
--- a/drivers/clk/stm32/clk-stm32-core.h
+++ b/drivers/clk/stm32/clk-stm32-core.h
@@ -71,7 +71,7 @@ struct stm32_rcc_match_data {
 	unsigned int			maxbinding;
 	struct clk_stm32_clock_data	*clock_data;
 	struct clk_stm32_reset_data	*reset_data;
-	int (*check_security)(void __iomem *base,
+	int (*check_security)(struct device_node *np, void __iomem *base,
 			      const struct clock_config *cfg);
 	int (*multi_mux)(void __iomem *base, const struct clock_config *cfg);
 };
diff --git a/drivers/clk/stm32/clk-stm32mp13.c b/drivers/clk/stm32/clk-stm32mp13.c
index bf81d7491708..9bc94c3c5df8 100644
--- a/drivers/clk/stm32/clk-stm32mp13.c
+++ b/drivers/clk/stm32/clk-stm32mp13.c
@@ -1458,7 +1458,7 @@ static const struct clock_config stm32mp13_clock_cfg[] = {
 	STM32_COMPOSITE_CFG(CK_MCO2, ck_mco2, SECF_MCO2),
 };
 
-static int stm32mp13_clock_is_provided_by_secure(void __iomem *base,
+static int stm32mp13_clock_is_provided_by_secure(struct device_node *np, void __iomem *base,
 						 const struct clock_config *cfg)
 {
 	int sec_id = cfg->sec_id;
diff --git a/drivers/clk/stm32/clk-stm32mp25.c b/drivers/clk/stm32/clk-stm32mp25.c
index 210b75b39e50..65a2d6bac271 100644
--- a/drivers/clk/stm32/clk-stm32mp25.c
+++ b/drivers/clk/stm32/clk-stm32mp25.c
@@ -4,7 +4,9 @@
  * Author: Gabriel Fernandez <gabriel.fernandez@foss.st.com> for STMicroelectronics.
  */
 
+#include <linux/bus/stm32_firewall_device.h>
 #include <linux/clk-provider.h>
+#include <linux/io.h>
 #include <linux/platform_device.h>
 
 #include "clk-stm32-core.h"
@@ -14,6 +16,31 @@
 #include <dt-bindings/clock/st,stm32mp25-rcc.h>
 #include <dt-bindings/reset/st,stm32mp25-rcc.h>
 
+/* Clock security definition */
+#define SECF_NONE		-1
+
+#define RCC_REG_SIZE	32
+#define RCC_SECCFGR(x)	(((x) / RCC_REG_SIZE) * 0x4 + RCC_SECCFGR0)
+#define RCC_CIDCFGR(x)	((x) * 0x8 + RCC_R0CIDCFGR)
+#define RCC_SEMCR(x)	((x) * 0x8 + RCC_R0SEMCR)
+#define RCC_CID1	1
+
+/* Register: RIFSC_CIDCFGR */
+#define RCC_CIDCFGR_CFEN	BIT(0)
+#define RCC_CIDCFGR_SEM_EN	BIT(1)
+#define RCC_CIDCFGR_SEMWLC1_EN	BIT(17)
+#define RCC_CIDCFGR_SCID_MASK	GENMASK(6, 4)
+
+/* Register: RIFSC_SEMCR */
+#define RCC_SEMCR_SEMCID_MASK	GENMASK(6, 4)
+
+#define MP25_RIF_RCC_IS2M	107
+#define MP25_RIF_RCC_MCO1	108
+#define MP25_RIF_RCC_MCO2	109
+
+#define SEC_RIFSC_FLAG		BIT(31)
+#define SEC_RIFSC(_id)		((_id) | SEC_RIFSC_FLAG)
+
 enum {
 	HSE,
 	HSI,
@@ -1507,203 +1534,262 @@ static struct clk_stm32_gate ck_icn_p_wwdg2 = {
 	.hw.init = CLK_HW_INIT_INDEX("ck_icn_p_wwdg2", ICN_LS_MCU, &clk_stm32_gate_ops, 0),
 };
 
-#define SECF_NONE -1
+static struct stm32_firewall firewall;
+
+static int stm32_rcc_get_access(void __iomem *base, u32 index)
+{
+	u32 seccfgr, cidcfgr, semcr;
+	int bit, cid;
+
+	bit = index % RCC_REG_SIZE;
+
+	seccfgr = readl(base + RCC_SECCFGR(index));
+	if (seccfgr & BIT(bit))
+		return -EACCES;
+
+	cidcfgr = readl(base + RCC_CIDCFGR(index));
+	if (!(cidcfgr & RCC_CIDCFGR_CFEN))
+		/* CID filtering is turned off: access granted */
+		return 0;
+
+	if (!(cidcfgr & RCC_CIDCFGR_SEM_EN)) {
+		/* Static CID mode */
+		cid = FIELD_GET(RCC_CIDCFGR_SCID_MASK, cidcfgr);
+		if (cid != RCC_CID1)
+			return -EACCES;
+		return 0;
+	}
+
+	/* Pass-list with semaphore mode */
+	if (!(cidcfgr & RCC_CIDCFGR_SEMWLC1_EN))
+		return -EACCES;
+
+	semcr = readl(base + RCC_SEMCR(index));
+
+	cid = FIELD_GET(RCC_SEMCR_SEMCID_MASK, semcr);
+	if (cid != RCC_CID1)
+		return -EACCES;
+
+	return 0;
+}
+
+static int stm32mp25_check_security(struct device_node *np, void __iomem *base,
+				    const struct clock_config *cfg)
+{
+	int ret = 0;
+
+	if (cfg->sec_id != SECF_NONE) {
+		u32 index = (u32)cfg->sec_id;
+
+		if (index & SEC_RIFSC_FLAG) {
+			ret = stm32_firewall_grant_access_by_id(&firewall, index & ~SEC_RIFSC_FLAG);
+
+			/* If firewall is not present, assume that we have access */
+			if (ret == -ENODEV)
+				return 0;
+		} else {
+			ret = stm32_rcc_get_access(base, cfg->sec_id & ~SEC_RIFSC_FLAG);
+		}
+	}
+
+	return ret;
+}
 
 static const struct clock_config stm32mp25_clock_cfg[] = {
-	STM32_GATE_CFG(CK_BUS_ETH1,		ck_icn_p_eth1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ETH2,		ck_icn_p_eth2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_PCIE,		ck_icn_p_pcie,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ETHSW,		ck_icn_p_ethsw,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ADC12,		ck_icn_p_adc12,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ADC3,		ck_icn_p_adc3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_CCI,		ck_icn_p_cci,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_CRC,		ck_icn_p_crc,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_MDF1,		ck_icn_p_mdf1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_OSPIIOM,		ck_icn_p_ospiiom,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_HASH,		ck_icn_p_hash,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_CRYP1,		ck_icn_p_cryp1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_CRYP2,		ck_icn_p_cryp2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ADF1,		ck_icn_p_adf1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI8,		ck_icn_p_spi8,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LPUART1,		ck_icn_p_lpuart1,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C8,		ck_icn_p_i2c8,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LPTIM3,		ck_icn_p_lptim3,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LPTIM4,		ck_icn_p_lptim4,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LPTIM5,		ck_icn_p_lptim5,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_IWDG5,		ck_icn_p_iwdg5,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_WWDG2,		ck_icn_p_wwdg2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I3C4,		ck_icn_p_i3c4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SDMMC1,		ck_icn_m_sdmmc1,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SDMMC2,		ck_icn_m_sdmmc2,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SDMMC3,		ck_icn_m_sdmmc3,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USB2OHCI,		ck_icn_m_usb2ohci,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USB2EHCI,		ck_icn_m_usb2ehci,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USB3DR,		ck_icn_m_usb3dr,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM2,		ck_icn_p_tim2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM3,		ck_icn_p_tim3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM4,		ck_icn_p_tim4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM5,		ck_icn_p_tim5,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM6,		ck_icn_p_tim6,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM7,		ck_icn_p_tim7,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM10,		ck_icn_p_tim10,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM11,		ck_icn_p_tim11,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM12,		ck_icn_p_tim12,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM13,		ck_icn_p_tim13,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM14,		ck_icn_p_tim14,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LPTIM1,		ck_icn_p_lptim1,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LPTIM2,		ck_icn_p_lptim2,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI2,		ck_icn_p_spi2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI3,		ck_icn_p_spi3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPDIFRX,		ck_icn_p_spdifrx,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USART2,		ck_icn_p_usart2,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USART3,		ck_icn_p_usart3,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_UART4,		ck_icn_p_uart4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_UART5,		ck_icn_p_uart5,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C1,		ck_icn_p_i2c1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C2,		ck_icn_p_i2c2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C3,		ck_icn_p_i2c3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C4,		ck_icn_p_i2c4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C5,		ck_icn_p_i2c5,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C6,		ck_icn_p_i2c6,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C7,		ck_icn_p_i2c7,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I3C1,		ck_icn_p_i3c1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I3C2,		ck_icn_p_i3c2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I3C3,		ck_icn_p_i3c3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM1,		ck_icn_p_tim1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM8,		ck_icn_p_tim8,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM15,		ck_icn_p_tim15,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM16,		ck_icn_p_tim16,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM17,		ck_icn_p_tim17,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM20,		ck_icn_p_tim20,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SAI1,		ck_icn_p_sai1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SAI2,		ck_icn_p_sai2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SAI3,		ck_icn_p_sai3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SAI4,		ck_icn_p_sai4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USART1,		ck_icn_p_usart1,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USART6,		ck_icn_p_usart6,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_UART7,		ck_icn_p_uart7,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_UART8,		ck_icn_p_uart8,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_UART9,		ck_icn_p_uart9,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_FDCAN,		ck_icn_p_fdcan,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI1,		ck_icn_p_spi1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI4,		ck_icn_p_spi4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI5,		ck_icn_p_spi5,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI6,		ck_icn_p_spi6,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI7,		ck_icn_p_spi7,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_IWDG2,		ck_icn_p_iwdg2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_IWDG3,		ck_icn_p_iwdg3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_IWDG4,		ck_icn_p_iwdg4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_WWDG1,		ck_icn_p_wwdg1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_VREF,		ck_icn_p_vref,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_HDP,		ck_icn_p_hdp,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_IS2M,		ck_icn_p_is2m,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_DSI,		ck_icn_p_dsi,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LTDC,		ck_icn_p_ltdc,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_CSI,		ck_icn_p_csi,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_DCMIPP,		ck_icn_p_dcmipp,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LVDS,		ck_icn_p_lvds,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USBTC,		ck_icn_p_usbtc,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USB3PCIEPHY,	ck_icn_p_usb3pciephy,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_VDEC,		ck_icn_p_vdec,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_VENC,		ck_icn_p_venc,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM2,		ck_ker_tim2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM3,		ck_ker_tim3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM4,		ck_ker_tim4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM5,		ck_ker_tim5,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM6,		ck_ker_tim6,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM7,		ck_ker_tim7,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM10,		ck_ker_tim10,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM11,		ck_ker_tim11,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM12,		ck_ker_tim12,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM13,		ck_ker_tim13,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM14,		ck_ker_tim14,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM1,		ck_ker_tim1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM8,		ck_ker_tim8,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM15,		ck_ker_tim15,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM16,		ck_ker_tim16,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM17,		ck_ker_tim17,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM20,		ck_ker_tim20,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LPTIM1,		ck_ker_lptim1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LPTIM2,		ck_ker_lptim2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_USART2,		ck_ker_usart2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_UART4,		ck_ker_uart4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_USART3,		ck_ker_usart3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_UART5,		ck_ker_uart5,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI2,		ck_ker_spi2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI3,		ck_ker_spi3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPDIFRX,		ck_ker_spdifrx,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C1,		ck_ker_i2c1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C2,		ck_ker_i2c2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I3C1,		ck_ker_i3c1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I3C2,		ck_ker_i3c2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C3,		ck_ker_i2c3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C5,		ck_ker_i2c5,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I3C3,		ck_ker_i3c3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C4,		ck_ker_i2c4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C6,		ck_ker_i2c6,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C7,		ck_ker_i2c7,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI1,		ck_ker_spi1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI4,		ck_ker_spi4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI5,		ck_ker_spi5,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI6,		ck_ker_spi6,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI7,		ck_ker_spi7,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_USART1,		ck_ker_usart1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_USART6,		ck_ker_usart6,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_UART7,		ck_ker_uart7,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_UART8,		ck_ker_uart8,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_UART9,		ck_ker_uart9,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_MDF1,		ck_ker_mdf1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SAI1,		ck_ker_sai1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SAI2,		ck_ker_sai2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SAI3,		ck_ker_sai3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SAI4,		ck_ker_sai4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_FDCAN,		ck_ker_fdcan,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_CSI,		ck_ker_csi,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_CSITXESC,		ck_ker_csitxesc,	SECF_NONE),
-	STM32_GATE_CFG(CK_KER_CSIPHY,		ck_ker_csiphy,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_USBTC,		ck_ker_usbtc,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I3C4,		ck_ker_i3c4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI8,		ck_ker_spi8,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C8,		ck_ker_i2c8,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LPUART1,		ck_ker_lpuart1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LPTIM3,		ck_ker_lptim3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LPTIM4,		ck_ker_lptim4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LPTIM5,		ck_ker_lptim5,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ADF1,		ck_ker_adf1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SDMMC1,		ck_ker_sdmmc1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SDMMC2,		ck_ker_sdmmc2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SDMMC3,		ck_ker_sdmmc3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ETH1,		ck_ker_eth1,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH1_STP,		ck_ker_eth1stp,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ETHSW,		ck_ker_ethsw,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ETH2,		ck_ker_eth2,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH2_STP,		ck_ker_eth2stp,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ETH1PTP,		ck_ker_eth1ptp,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ETH2PTP,		ck_ker_eth2ptp,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_GPU,		ck_icn_m_gpu,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_GPU,		ck_ker_gpu,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ETHSWREF,		ck_ker_ethswref,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ETHSWACMCFG,	ck_icn_p_ethsw_acm_cfg,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ETHSWACMMSG, ck_icn_p_ethsw_acm_msg,	SECF_NONE),
-	STM32_GATE_CFG(CK_ETH1_MAC,		ck_ker_eth1mac,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH1_TX,		ck_ker_eth1tx,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH1_RX,		ck_ker_eth1rx,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH2_MAC,		ck_ker_eth2mac,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH2_TX,		ck_ker_eth2tx,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH2_RX,		ck_ker_eth2rx,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_MCO1,		ck_mco1,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_MCO2,		ck_mco2,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_ADC12,	ck_ker_adc12,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_ADC3,	ck_ker_adc3,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_USB2PHY1,	ck_ker_usb2phy1,	SECF_NONE),
-	STM32_GATE_CFG(CK_KER_USB2PHY2,		ck_ker_usb2phy2,	SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_USB2PHY2EN,	ck_ker_usb2phy2_en,	SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_USB3PCIEPHY,	ck_ker_usb3pciephy,	SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_DSIBLANE,	clk_lanebyte,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_DSIPHY,	clk_phy_dsi,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_LVDSPHY,	ck_ker_lvdsphy,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_DTS,		ck_ker_dts,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LTDC,		ck_ker_ltdc,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ETH1,		ck_icn_p_eth1,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_BUS_ETH2,		ck_icn_p_eth2,		SEC_RIFSC(61)),
+	STM32_GATE_CFG(CK_BUS_PCIE,		ck_icn_p_pcie,		SEC_RIFSC(68)),
+	STM32_GATE_CFG(CK_BUS_ETHSW,		ck_icn_p_ethsw,		SEC_RIFSC(70)),
+	STM32_GATE_CFG(CK_BUS_ADC12,		ck_icn_p_adc12,		SEC_RIFSC(58)),
+	STM32_GATE_CFG(CK_BUS_ADC3,		ck_icn_p_adc3,		SEC_RIFSC(59)),
+	STM32_GATE_CFG(CK_BUS_CCI,		ck_icn_p_cci,		SEC_RIFSC(88)),
+	STM32_GATE_CFG(CK_BUS_CRC,		ck_icn_p_crc,		SEC_RIFSC(109)),
+	STM32_GATE_CFG(CK_BUS_MDF1,		ck_icn_p_mdf1,		SEC_RIFSC(54)),
+	STM32_GATE_CFG(CK_BUS_OSPIIOM,		ck_icn_p_ospiiom,	SEC_RIFSC(111)),
+	STM32_GATE_CFG(CK_BUS_HASH,		ck_icn_p_hash,		SEC_RIFSC(95)),
+	STM32_GATE_CFG(CK_BUS_CRYP1,		ck_icn_p_cryp1,		SEC_RIFSC(96)),
+	STM32_GATE_CFG(CK_BUS_CRYP2,		ck_icn_p_cryp2,		SEC_RIFSC(97)),
+	STM32_GATE_CFG(CK_BUS_ADF1,		ck_icn_p_adf1,		SEC_RIFSC(55)),
+	STM32_GATE_CFG(CK_BUS_SPI8,		ck_icn_p_spi8,		SEC_RIFSC(29)),
+	STM32_GATE_CFG(CK_BUS_LPUART1,		ck_icn_p_lpuart1,	SEC_RIFSC(40)),
+	STM32_GATE_CFG(CK_BUS_I2C8,		ck_icn_p_i2c8,		SEC_RIFSC(48)),
+	STM32_GATE_CFG(CK_BUS_LPTIM3,		ck_icn_p_lptim3,	SEC_RIFSC(19)),
+	STM32_GATE_CFG(CK_BUS_LPTIM4,		ck_icn_p_lptim4,	SEC_RIFSC(20)),
+	STM32_GATE_CFG(CK_BUS_LPTIM5,		ck_icn_p_lptim5,	SEC_RIFSC(21)),
+	STM32_GATE_CFG(CK_BUS_IWDG5,		ck_icn_p_iwdg5,		SEC_RIFSC(102)),
+	STM32_GATE_CFG(CK_BUS_WWDG2,		ck_icn_p_wwdg2,		SEC_RIFSC(104)),
+	STM32_GATE_CFG(CK_BUS_I3C4,		ck_icn_p_i3c4,		SEC_RIFSC(117)),
+	STM32_GATE_CFG(CK_BUS_SDMMC1,		ck_icn_m_sdmmc1,	SEC_RIFSC(76)),
+	STM32_GATE_CFG(CK_BUS_SDMMC2,		ck_icn_m_sdmmc2,	SEC_RIFSC(77)),
+	STM32_GATE_CFG(CK_BUS_SDMMC3,		ck_icn_m_sdmmc3,	SEC_RIFSC(78)),
+	STM32_GATE_CFG(CK_BUS_USB2OHCI,		ck_icn_m_usb2ohci,	SEC_RIFSC(63)),
+	STM32_GATE_CFG(CK_BUS_USB2EHCI,		ck_icn_m_usb2ehci,	SEC_RIFSC(63)),
+	STM32_GATE_CFG(CK_BUS_USB3DR,		ck_icn_m_usb3dr,	SEC_RIFSC(66)),
+	STM32_GATE_CFG(CK_BUS_TIM2,		ck_icn_p_tim2,		SEC_RIFSC(1)),
+	STM32_GATE_CFG(CK_BUS_TIM3,		ck_icn_p_tim3,		SEC_RIFSC(2)),
+	STM32_GATE_CFG(CK_BUS_TIM4,		ck_icn_p_tim4,		SEC_RIFSC(3)),
+	STM32_GATE_CFG(CK_BUS_TIM5,		ck_icn_p_tim5,		SEC_RIFSC(4)),
+	STM32_GATE_CFG(CK_BUS_TIM6,		ck_icn_p_tim6,		SEC_RIFSC(5)),
+	STM32_GATE_CFG(CK_BUS_TIM7,		ck_icn_p_tim7,		SEC_RIFSC(6)),
+	STM32_GATE_CFG(CK_BUS_TIM10,		ck_icn_p_tim10,		SEC_RIFSC(8)),
+	STM32_GATE_CFG(CK_BUS_TIM11,		ck_icn_p_tim11,		SEC_RIFSC(9)),
+	STM32_GATE_CFG(CK_BUS_TIM12,		ck_icn_p_tim12,		SEC_RIFSC(10)),
+	STM32_GATE_CFG(CK_BUS_TIM13,		ck_icn_p_tim13,		SEC_RIFSC(11)),
+	STM32_GATE_CFG(CK_BUS_TIM14,		ck_icn_p_tim14,		SEC_RIFSC(12)),
+	STM32_GATE_CFG(CK_BUS_LPTIM1,		ck_icn_p_lptim1,	SEC_RIFSC(17)),
+	STM32_GATE_CFG(CK_BUS_LPTIM2,		ck_icn_p_lptim2,	SEC_RIFSC(18)),
+	STM32_GATE_CFG(CK_BUS_SPI2,		ck_icn_p_spi2,		SEC_RIFSC(23)),
+	STM32_GATE_CFG(CK_BUS_SPI3,		ck_icn_p_spi3,		SEC_RIFSC(24)),
+	STM32_GATE_CFG(CK_BUS_SPDIFRX,		ck_icn_p_spdifrx,	SEC_RIFSC(30)),
+	STM32_GATE_CFG(CK_BUS_USART2,		ck_icn_p_usart2,	SEC_RIFSC(32)),
+	STM32_GATE_CFG(CK_BUS_USART3,		ck_icn_p_usart3,	SEC_RIFSC(33)),
+	STM32_GATE_CFG(CK_BUS_UART4,		ck_icn_p_uart4,		SEC_RIFSC(34)),
+	STM32_GATE_CFG(CK_BUS_UART5,		ck_icn_p_uart5,		SEC_RIFSC(35)),
+	STM32_GATE_CFG(CK_BUS_I2C1,		ck_icn_p_i2c1,		SEC_RIFSC(41)),
+	STM32_GATE_CFG(CK_BUS_I2C2,		ck_icn_p_i2c2,		SEC_RIFSC(42)),
+	STM32_GATE_CFG(CK_BUS_I2C3,		ck_icn_p_i2c3,		SEC_RIFSC(43)),
+	STM32_GATE_CFG(CK_BUS_I2C4,		ck_icn_p_i2c4,		SEC_RIFSC(44)),
+	STM32_GATE_CFG(CK_BUS_I2C5,		ck_icn_p_i2c5,		SEC_RIFSC(45)),
+	STM32_GATE_CFG(CK_BUS_I2C6,		ck_icn_p_i2c6,		SEC_RIFSC(46)),
+	STM32_GATE_CFG(CK_BUS_I2C7,		ck_icn_p_i2c7,		SEC_RIFSC(47)),
+	STM32_GATE_CFG(CK_BUS_I3C1,		ck_icn_p_i3c1,		SEC_RIFSC(114)),
+	STM32_GATE_CFG(CK_BUS_I3C2,		ck_icn_p_i3c2,		SEC_RIFSC(115)),
+	STM32_GATE_CFG(CK_BUS_I3C3,		ck_icn_p_i3c3,		SEC_RIFSC(116)),
+	STM32_GATE_CFG(CK_BUS_TIM1,		ck_icn_p_tim1,		SEC_RIFSC(0)),
+	STM32_GATE_CFG(CK_BUS_TIM8,		ck_icn_p_tim8,		SEC_RIFSC(7)),
+	STM32_GATE_CFG(CK_BUS_TIM15,		ck_icn_p_tim15,		SEC_RIFSC(13)),
+	STM32_GATE_CFG(CK_BUS_TIM16,		ck_icn_p_tim16,		SEC_RIFSC(14)),
+	STM32_GATE_CFG(CK_BUS_TIM17,		ck_icn_p_tim17,		SEC_RIFSC(15)),
+	STM32_GATE_CFG(CK_BUS_TIM20,		ck_icn_p_tim20,		SEC_RIFSC(16)),
+	STM32_GATE_CFG(CK_BUS_SAI1,		ck_icn_p_sai1,		SEC_RIFSC(49)),
+	STM32_GATE_CFG(CK_BUS_SAI2,		ck_icn_p_sai2,		SEC_RIFSC(50)),
+	STM32_GATE_CFG(CK_BUS_SAI3,		ck_icn_p_sai3,		SEC_RIFSC(51)),
+	STM32_GATE_CFG(CK_BUS_SAI4,		ck_icn_p_sai4,		SEC_RIFSC(52)),
+	STM32_GATE_CFG(CK_BUS_USART1,		ck_icn_p_usart1,	SEC_RIFSC(31)),
+	STM32_GATE_CFG(CK_BUS_USART6,		ck_icn_p_usart6,	SEC_RIFSC(36)),
+	STM32_GATE_CFG(CK_BUS_UART7,		ck_icn_p_uart7,		SEC_RIFSC(37)),
+	STM32_GATE_CFG(CK_BUS_UART8,		ck_icn_p_uart8,		SEC_RIFSC(38)),
+	STM32_GATE_CFG(CK_BUS_UART9,		ck_icn_p_uart9,		SEC_RIFSC(39)),
+	STM32_GATE_CFG(CK_BUS_FDCAN,		ck_icn_p_fdcan,		SEC_RIFSC(56)),
+	STM32_GATE_CFG(CK_BUS_SPI1,		ck_icn_p_spi1,		SEC_RIFSC(22)),
+	STM32_GATE_CFG(CK_BUS_SPI4,		ck_icn_p_spi4,		SEC_RIFSC(25)),
+	STM32_GATE_CFG(CK_BUS_SPI5,		ck_icn_p_spi5,		SEC_RIFSC(26)),
+	STM32_GATE_CFG(CK_BUS_SPI6,		ck_icn_p_spi6,		SEC_RIFSC(27)),
+	STM32_GATE_CFG(CK_BUS_SPI7,		ck_icn_p_spi7,		SEC_RIFSC(28)),
+	STM32_GATE_CFG(CK_BUS_IWDG2,		ck_icn_p_iwdg2,		SEC_RIFSC(99)),
+	STM32_GATE_CFG(CK_BUS_IWDG3,		ck_icn_p_iwdg3,		SEC_RIFSC(100)),
+	STM32_GATE_CFG(CK_BUS_IWDG4,		ck_icn_p_iwdg4,		SEC_RIFSC(101)),
+	STM32_GATE_CFG(CK_BUS_WWDG1,		ck_icn_p_wwdg1,		SEC_RIFSC(103)),
+	STM32_GATE_CFG(CK_BUS_VREF,		ck_icn_p_vref,		SEC_RIFSC(106)),
+	STM32_GATE_CFG(CK_BUS_HDP,		ck_icn_p_hdp,		SEC_RIFSC(57)),
+	STM32_GATE_CFG(CK_BUS_IS2M,		ck_icn_p_is2m,		MP25_RIF_RCC_IS2M),
+	STM32_GATE_CFG(CK_BUS_DSI,		ck_icn_p_dsi,		SEC_RIFSC(81)),
+	STM32_GATE_CFG(CK_BUS_LTDC,		ck_icn_p_ltdc,		SEC_RIFSC(80)),
+	STM32_GATE_CFG(CK_BUS_CSI,		ck_icn_p_csi,		SEC_RIFSC(86)),
+	STM32_GATE_CFG(CK_BUS_DCMIPP,		ck_icn_p_dcmipp,	SEC_RIFSC(87)),
+	STM32_GATE_CFG(CK_BUS_LVDS,		ck_icn_p_lvds,		SEC_RIFSC(84)),
+	STM32_GATE_CFG(CK_BUS_USBTC,		ck_icn_p_usbtc,		SEC_RIFSC(69)),
+	STM32_GATE_CFG(CK_BUS_USB3PCIEPHY,	ck_icn_p_usb3pciephy,	SEC_RIFSC(67)),
+	STM32_GATE_CFG(CK_BUS_VDEC,		ck_icn_p_vdec,		SEC_RIFSC(89)),
+	STM32_GATE_CFG(CK_BUS_VENC,		ck_icn_p_venc,		SEC_RIFSC(90)),
+	STM32_GATE_CFG(CK_KER_TIM2,		ck_ker_tim2,		SEC_RIFSC(1)),
+	STM32_GATE_CFG(CK_KER_TIM3,		ck_ker_tim3,		SEC_RIFSC(2)),
+	STM32_GATE_CFG(CK_KER_TIM4,		ck_ker_tim4,		SEC_RIFSC(3)),
+	STM32_GATE_CFG(CK_KER_TIM5,		ck_ker_tim5,		SEC_RIFSC(4)),
+	STM32_GATE_CFG(CK_KER_TIM6,		ck_ker_tim6,		SEC_RIFSC(5)),
+	STM32_GATE_CFG(CK_KER_TIM7,		ck_ker_tim7,		SEC_RIFSC(6)),
+	STM32_GATE_CFG(CK_KER_TIM10,		ck_ker_tim10,		SEC_RIFSC(8)),
+	STM32_GATE_CFG(CK_KER_TIM11,		ck_ker_tim11,		SEC_RIFSC(9)),
+	STM32_GATE_CFG(CK_KER_TIM12,		ck_ker_tim12,		SEC_RIFSC(10)),
+	STM32_GATE_CFG(CK_KER_TIM13,		ck_ker_tim13,		SEC_RIFSC(11)),
+	STM32_GATE_CFG(CK_KER_TIM14,		ck_ker_tim14,		SEC_RIFSC(12)),
+	STM32_GATE_CFG(CK_KER_TIM1,		ck_ker_tim1,		SEC_RIFSC(0)),
+	STM32_GATE_CFG(CK_KER_TIM8,		ck_ker_tim8,		SEC_RIFSC(7)),
+	STM32_GATE_CFG(CK_KER_TIM15,		ck_ker_tim15,		SEC_RIFSC(13)),
+	STM32_GATE_CFG(CK_KER_TIM16,		ck_ker_tim16,		SEC_RIFSC(14)),
+	STM32_GATE_CFG(CK_KER_TIM17,		ck_ker_tim17,		SEC_RIFSC(15)),
+	STM32_GATE_CFG(CK_KER_TIM20,		ck_ker_tim20,		SEC_RIFSC(16)),
+	STM32_GATE_CFG(CK_KER_LPTIM1,		ck_ker_lptim1,		SEC_RIFSC(17)),
+	STM32_GATE_CFG(CK_KER_LPTIM2,		ck_ker_lptim2,		SEC_RIFSC(18)),
+	STM32_GATE_CFG(CK_KER_USART2,		ck_ker_usart2,		SEC_RIFSC(32)),
+	STM32_GATE_CFG(CK_KER_UART4,		ck_ker_uart4,		SEC_RIFSC(34)),
+	STM32_GATE_CFG(CK_KER_USART3,		ck_ker_usart3,		SEC_RIFSC(33)),
+	STM32_GATE_CFG(CK_KER_UART5,		ck_ker_uart5,		SEC_RIFSC(35)),
+	STM32_GATE_CFG(CK_KER_SPI2,		ck_ker_spi2,		SEC_RIFSC(23)),
+	STM32_GATE_CFG(CK_KER_SPI3,		ck_ker_spi3,		SEC_RIFSC(24)),
+	STM32_GATE_CFG(CK_KER_SPDIFRX,		ck_ker_spdifrx,		SEC_RIFSC(30)),
+	STM32_GATE_CFG(CK_KER_I2C1,		ck_ker_i2c1,		SEC_RIFSC(41)),
+	STM32_GATE_CFG(CK_KER_I2C2,		ck_ker_i2c2,		SEC_RIFSC(42)),
+	STM32_GATE_CFG(CK_KER_I3C1,		ck_ker_i3c1,		SEC_RIFSC(114)),
+	STM32_GATE_CFG(CK_KER_I3C2,		ck_ker_i3c2,		SEC_RIFSC(115)),
+	STM32_GATE_CFG(CK_KER_I2C3,		ck_ker_i2c3,		SEC_RIFSC(43)),
+	STM32_GATE_CFG(CK_KER_I2C5,		ck_ker_i2c5,		SEC_RIFSC(45)),
+	STM32_GATE_CFG(CK_KER_I3C3,		ck_ker_i3c3,		SEC_RIFSC(116)),
+	STM32_GATE_CFG(CK_KER_I2C4,		ck_ker_i2c4,		SEC_RIFSC(44)),
+	STM32_GATE_CFG(CK_KER_I2C6,		ck_ker_i2c6,		SEC_RIFSC(46)),
+	STM32_GATE_CFG(CK_KER_I2C7,		ck_ker_i2c7,		SEC_RIFSC(47)),
+	STM32_GATE_CFG(CK_KER_SPI1,		ck_ker_spi1,		SEC_RIFSC(22)),
+	STM32_GATE_CFG(CK_KER_SPI4,		ck_ker_spi4,		SEC_RIFSC(25)),
+	STM32_GATE_CFG(CK_KER_SPI5,		ck_ker_spi5,		SEC_RIFSC(26)),
+	STM32_GATE_CFG(CK_KER_SPI6,		ck_ker_spi6,		SEC_RIFSC(27)),
+	STM32_GATE_CFG(CK_KER_SPI7,		ck_ker_spi7,		SEC_RIFSC(28)),
+	STM32_GATE_CFG(CK_KER_USART1,		ck_ker_usart1,		SEC_RIFSC(31)),
+	STM32_GATE_CFG(CK_KER_USART6,		ck_ker_usart6,		SEC_RIFSC(36)),
+	STM32_GATE_CFG(CK_KER_UART7,		ck_ker_uart7,		SEC_RIFSC(37)),
+	STM32_GATE_CFG(CK_KER_UART8,		ck_ker_uart8,		SEC_RIFSC(38)),
+	STM32_GATE_CFG(CK_KER_UART9,		ck_ker_uart9,		SEC_RIFSC(39)),
+	STM32_GATE_CFG(CK_KER_MDF1,		ck_ker_mdf1,		SEC_RIFSC(54)),
+	STM32_GATE_CFG(CK_KER_SAI1,		ck_ker_sai1,		SEC_RIFSC(49)),
+	STM32_GATE_CFG(CK_KER_SAI2,		ck_ker_sai2,		SEC_RIFSC(50)),
+	STM32_GATE_CFG(CK_KER_SAI3,		ck_ker_sai3,		SEC_RIFSC(51)),
+	STM32_GATE_CFG(CK_KER_SAI4,		ck_ker_sai4,		SEC_RIFSC(52)),
+	STM32_GATE_CFG(CK_KER_FDCAN,		ck_ker_fdcan,		SEC_RIFSC(56)),
+	STM32_GATE_CFG(CK_KER_CSI,		ck_ker_csi,		SEC_RIFSC(86)),
+	STM32_GATE_CFG(CK_KER_CSITXESC,		ck_ker_csitxesc,	SEC_RIFSC(86)),
+	STM32_GATE_CFG(CK_KER_CSIPHY,		ck_ker_csiphy,		SEC_RIFSC(86)),
+	STM32_GATE_CFG(CK_KER_USBTC,		ck_ker_usbtc,		SEC_RIFSC(69)),
+	STM32_GATE_CFG(CK_KER_I3C4,		ck_ker_i3c4,		SEC_RIFSC(117)),
+	STM32_GATE_CFG(CK_KER_SPI8,		ck_ker_spi8,		SEC_RIFSC(29)),
+	STM32_GATE_CFG(CK_KER_I2C8,		ck_ker_i2c8,		SEC_RIFSC(48)),
+	STM32_GATE_CFG(CK_KER_LPUART1,		ck_ker_lpuart1,		SEC_RIFSC(40)),
+	STM32_GATE_CFG(CK_KER_LPTIM3,		ck_ker_lptim3,		SEC_RIFSC(19)),
+	STM32_GATE_CFG(CK_KER_LPTIM4,		ck_ker_lptim4,		SEC_RIFSC(20)),
+	STM32_GATE_CFG(CK_KER_LPTIM5,		ck_ker_lptim5,		SEC_RIFSC(21)),
+	STM32_GATE_CFG(CK_KER_ADF1,		ck_ker_adf1,		SEC_RIFSC(55)),
+	STM32_GATE_CFG(CK_KER_SDMMC1,		ck_ker_sdmmc1,		SEC_RIFSC(76)),
+	STM32_GATE_CFG(CK_KER_SDMMC2,		ck_ker_sdmmc2,		SEC_RIFSC(77)),
+	STM32_GATE_CFG(CK_KER_SDMMC3,		ck_ker_sdmmc3,		SEC_RIFSC(78)),
+	STM32_GATE_CFG(CK_KER_ETH1,		ck_ker_eth1,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_ETH1_STP,		ck_ker_eth1stp,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_KER_ETHSW,		ck_ker_ethsw,		SEC_RIFSC(70)),
+	STM32_GATE_CFG(CK_KER_ETH2,		ck_ker_eth2,		SEC_RIFSC(61)),
+	STM32_GATE_CFG(CK_ETH2_STP,		ck_ker_eth2stp,		SEC_RIFSC(61)),
+	STM32_GATE_CFG(CK_KER_ETH1PTP,		ck_ker_eth1ptp,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_KER_ETH2PTP,		ck_ker_eth2ptp,		SEC_RIFSC(61)),
+	STM32_GATE_CFG(CK_BUS_GPU,		ck_icn_m_gpu,		SEC_RIFSC(79)),
+	STM32_GATE_CFG(CK_KER_GPU,		ck_ker_gpu,		SEC_RIFSC(79)),
+	STM32_GATE_CFG(CK_KER_ETHSWREF,		ck_ker_ethswref,	SEC_RIFSC(70)),
+	STM32_GATE_CFG(CK_BUS_ETHSWACMCFG,	ck_icn_p_ethsw_acm_cfg,	SEC_RIFSC(71)),
+	STM32_GATE_CFG(CK_BUS_ETHSWACMMSG,	ck_icn_p_ethsw_acm_msg,	SEC_RIFSC(72)),
+	STM32_GATE_CFG(CK_ETH1_MAC,		ck_ker_eth1mac,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_ETH1_TX,		ck_ker_eth1tx,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_ETH1_RX,		ck_ker_eth1rx,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_ETH2_MAC,		ck_ker_eth2mac,		SEC_RIFSC(61)),
+	STM32_GATE_CFG(CK_ETH2_TX,		ck_ker_eth2tx,		SEC_RIFSC(61)),
+	STM32_GATE_CFG(CK_ETH2_RX,		ck_ker_eth2rx,		SEC_RIFSC(61)),
+	STM32_COMPOSITE_CFG(CK_MCO1,		ck_mco1,		MP25_RIF_RCC_MCO1),
+	STM32_COMPOSITE_CFG(CK_MCO2,		ck_mco2,		MP25_RIF_RCC_MCO1),
+	STM32_COMPOSITE_CFG(CK_KER_ADC12,	ck_ker_adc12,		SEC_RIFSC(58)),
+	STM32_COMPOSITE_CFG(CK_KER_ADC3,	ck_ker_adc3,		SEC_RIFSC(59)),
+	STM32_COMPOSITE_CFG(CK_KER_USB2PHY1,	ck_ker_usb2phy1,	SEC_RIFSC(63)),
+	STM32_GATE_CFG(CK_KER_USB2PHY2,		ck_ker_usb2phy2,	SEC_RIFSC(63)),
+	STM32_COMPOSITE_CFG(CK_KER_USB2PHY2EN,	ck_ker_usb2phy2_en,	SEC_RIFSC(63)),
+	STM32_COMPOSITE_CFG(CK_KER_USB3PCIEPHY,	ck_ker_usb3pciephy,	SEC_RIFSC(67)),
+	STM32_COMPOSITE_CFG(CK_KER_DSIBLANE,	clk_lanebyte,		SEC_RIFSC(81)),
+	STM32_COMPOSITE_CFG(CK_KER_DSIPHY,	clk_phy_dsi,		SEC_RIFSC(81)),
+	STM32_COMPOSITE_CFG(CK_KER_LVDSPHY,	ck_ker_lvdsphy,		SEC_RIFSC(84)),
+	STM32_COMPOSITE_CFG(CK_KER_DTS,		ck_ker_dts,		SEC_RIFSC(107)),
+	STM32_GATE_CFG(CK_KER_LTDC,		ck_ker_ltdc,		SEC_RIFSC(80)),
 };
 
 #define RESET_MP25(id, _offset, _bit_idx, _set_clr)	\
@@ -1839,6 +1925,7 @@ static const struct stm32_rcc_match_data stm32mp25_data = {
 	.maxbinding	= STM32MP25_LAST_CLK,
 	.clock_data	= &stm32mp25_clock_data,
 	.reset_data	= &stm32mp25_reset_data,
+	.check_security = &stm32mp25_check_security,
 };
 
 static const struct of_device_id stm32mp25_match_data[] = {
@@ -1851,11 +1938,16 @@ static int stm32mp25_rcc_clocks_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	void __iomem *base;
+	int ret;
 
 	base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(base))
 		return PTR_ERR(base);
 
+	ret = stm32_firewall_get_firewall(dev->of_node, &firewall, 1);
+	if (ret)
+		return ret;
+
 	return stm32_rcc_init(dev, stm32mp25_match_data, base);
 }
 
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 2%]

* [PATCH v2 3/3] arm64: dts: st: enable STM32 access controller for RCC
  2024-05-29 13:13  6% ` gabriel.fernandez
@ 2024-05-29 13:13  1%   ` gabriel.fernandez
  -1 siblings, 0 replies; 200+ results
From: gabriel.fernandez @ 2024-05-29 13:13 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
	Alexandre Torgue, Michael Turquette, Stephen Boyd, Maxime Ripard,
	Gabriel Fernandez, Dan Carpenter
  Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel, linux-clk

From: Gabriel Fernandez <gabriel.fernandez@foss.st.com>

Use an STM32 access controller to filter the registration of clocks.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index dcd0656d67a8..602d02efc202 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -441,6 +441,7 @@ rcc: clock-controller@44200000 {
 				<&scmi_clk CK_SCMI_TIMG2>,
 				<&scmi_clk CK_SCMI_PLL3>,
 				<&clk_dsi_txbyte>;
+				access-controllers = <&rifsc 156>;
 		};
 
 		exti1: interrupt-controller@44220000 {
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 1%]

* [RESEND PATCH v2 0/3] Use STM32 access controller for STM32MP25 clocks
@ 2024-05-29 13:13  6% ` gabriel.fernandez
  0 siblings, 0 replies; 200+ results
From: gabriel.fernandez @ 2024-05-29 13:13 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
	Alexandre Torgue, Michael Turquette, Stephen Boyd, Maxime Ripard,
	Gabriel Fernandez, Dan Carpenter
  Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel, linux-clk

From: Gabriel Fernandez <gabriel.fernandez@foss.st.com>

Use an STM32 access controller to filter the registration of clocks.
Don't register a clock if this clock is secured or declared as shared (this
clock is generally managed by the security world).

This series depends on the stm32_firewall framework (merged since
next-20240419) notably for the include file 'linux/bus/stm32_firewall_device.h'.

Changes in v2:
  - rebased on next-20240514
  - YAML patch was apllied on next
  - use appropriate include
  - manage the case if 'access-contoller' property is not present in the DT
  - rename DT patch (RCC support part was merged)

Gabriel Fernandez (3):
  clk: stm32mp2: use of STM32 access controller
  clk: stm32mp25: add security clocks
  arm64: dts: st: enable STM32 access controller for RCC

 arch/arm64/boot/dts/st/stm32mp251.dtsi |   1 +
 drivers/clk/stm32/clk-stm32-core.c     |   2 +-
 drivers/clk/stm32/clk-stm32-core.h     |   2 +-
 drivers/clk/stm32/clk-stm32mp13.c      |   2 +-
 drivers/clk/stm32/clk-stm32mp25.c      | 516 +++++++++++++++----------
 5 files changed, 325 insertions(+), 198 deletions(-)

-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 6%]

* [RESEND PATCH v2 0/3] Use STM32 access controller for STM32MP25 clocks
@ 2024-05-29 13:13  6% ` gabriel.fernandez
  0 siblings, 0 replies; 200+ results
From: gabriel.fernandez @ 2024-05-29 13:13 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
	Alexandre Torgue, Michael Turquette, Stephen Boyd, Maxime Ripard,
	Gabriel Fernandez, Dan Carpenter
  Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel, linux-clk

From: Gabriel Fernandez <gabriel.fernandez@foss.st.com>

Use an STM32 access controller to filter the registration of clocks.
Don't register a clock if this clock is secured or declared as shared (this
clock is generally managed by the security world).

This series depends on the stm32_firewall framework (merged since
next-20240419) notably for the include file 'linux/bus/stm32_firewall_device.h'.

Changes in v2:
  - rebased on next-20240514
  - YAML patch was apllied on next
  - use appropriate include
  - manage the case if 'access-contoller' property is not present in the DT
  - rename DT patch (RCC support part was merged)

Gabriel Fernandez (3):
  clk: stm32mp2: use of STM32 access controller
  clk: stm32mp25: add security clocks
  arm64: dts: st: enable STM32 access controller for RCC

 arch/arm64/boot/dts/st/stm32mp251.dtsi |   1 +
 drivers/clk/stm32/clk-stm32-core.c     |   2 +-
 drivers/clk/stm32/clk-stm32-core.h     |   2 +-
 drivers/clk/stm32/clk-stm32mp13.c      |   2 +-
 drivers/clk/stm32/clk-stm32mp25.c      | 516 +++++++++++++++----------
 5 files changed, 325 insertions(+), 198 deletions(-)

-- 
2.25.1


^ permalink raw reply	[relevance 6%]

* [RESEND PATCH v2 1/3] clk: stm32mp2: use of STM32 access controller
@ 2024-05-29 13:13  2%   ` gabriel.fernandez
  0 siblings, 0 replies; 200+ results
From: gabriel.fernandez @ 2024-05-29 13:13 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
	Alexandre Torgue, Michael Turquette, Stephen Boyd, Maxime Ripard,
	Gabriel Fernandez, Dan Carpenter
  Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel, linux-clk

From: Gabriel Fernandez <gabriel.fernandez@foss.st.com>

Use an STM32 access controller to filter the registration of clocks.
If a clock is used by the security world, then it must not registered.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
---
Changes in v2:
  Depends on the stm32_firewall framework (merged since next-20240419 tag)
  - replace linux/of_address.h include by linux/io.h
  - manage the case if the property 'access-controllers' is not present
    (allow registering of all clocks).

 drivers/clk/stm32/clk-stm32-core.c |   2 +-
 drivers/clk/stm32/clk-stm32-core.h |   2 +-
 drivers/clk/stm32/clk-stm32mp13.c  |   2 +-
 drivers/clk/stm32/clk-stm32mp25.c  | 482 +++++++++++++++++------------
 4 files changed, 290 insertions(+), 198 deletions(-)

diff --git a/drivers/clk/stm32/clk-stm32-core.c b/drivers/clk/stm32/clk-stm32-core.c
index 1721a3ed7386..933e3cde0795 100644
--- a/drivers/clk/stm32/clk-stm32-core.c
+++ b/drivers/clk/stm32/clk-stm32-core.c
@@ -46,7 +46,7 @@ static int stm32_rcc_clock_init(struct device *dev,
 		struct clk_hw *hw = ERR_PTR(-ENOENT);
 
 		if (data->check_security &&
-		    data->check_security(base, cfg_clock))
+		    data->check_security(dev->of_node, base, cfg_clock))
 			continue;
 
 		if (cfg_clock->func)
diff --git a/drivers/clk/stm32/clk-stm32-core.h b/drivers/clk/stm32/clk-stm32-core.h
index bb5aa19a792d..4be103710e12 100644
--- a/drivers/clk/stm32/clk-stm32-core.h
+++ b/drivers/clk/stm32/clk-stm32-core.h
@@ -71,7 +71,7 @@ struct stm32_rcc_match_data {
 	unsigned int			maxbinding;
 	struct clk_stm32_clock_data	*clock_data;
 	struct clk_stm32_reset_data	*reset_data;
-	int (*check_security)(void __iomem *base,
+	int (*check_security)(struct device_node *np, void __iomem *base,
 			      const struct clock_config *cfg);
 	int (*multi_mux)(void __iomem *base, const struct clock_config *cfg);
 };
diff --git a/drivers/clk/stm32/clk-stm32mp13.c b/drivers/clk/stm32/clk-stm32mp13.c
index bf81d7491708..9bc94c3c5df8 100644
--- a/drivers/clk/stm32/clk-stm32mp13.c
+++ b/drivers/clk/stm32/clk-stm32mp13.c
@@ -1458,7 +1458,7 @@ static const struct clock_config stm32mp13_clock_cfg[] = {
 	STM32_COMPOSITE_CFG(CK_MCO2, ck_mco2, SECF_MCO2),
 };
 
-static int stm32mp13_clock_is_provided_by_secure(void __iomem *base,
+static int stm32mp13_clock_is_provided_by_secure(struct device_node *np, void __iomem *base,
 						 const struct clock_config *cfg)
 {
 	int sec_id = cfg->sec_id;
diff --git a/drivers/clk/stm32/clk-stm32mp25.c b/drivers/clk/stm32/clk-stm32mp25.c
index 210b75b39e50..65a2d6bac271 100644
--- a/drivers/clk/stm32/clk-stm32mp25.c
+++ b/drivers/clk/stm32/clk-stm32mp25.c
@@ -4,7 +4,9 @@
  * Author: Gabriel Fernandez <gabriel.fernandez@foss.st.com> for STMicroelectronics.
  */
 
+#include <linux/bus/stm32_firewall_device.h>
 #include <linux/clk-provider.h>
+#include <linux/io.h>
 #include <linux/platform_device.h>
 
 #include "clk-stm32-core.h"
@@ -14,6 +16,31 @@
 #include <dt-bindings/clock/st,stm32mp25-rcc.h>
 #include <dt-bindings/reset/st,stm32mp25-rcc.h>
 
+/* Clock security definition */
+#define SECF_NONE		-1
+
+#define RCC_REG_SIZE	32
+#define RCC_SECCFGR(x)	(((x) / RCC_REG_SIZE) * 0x4 + RCC_SECCFGR0)
+#define RCC_CIDCFGR(x)	((x) * 0x8 + RCC_R0CIDCFGR)
+#define RCC_SEMCR(x)	((x) * 0x8 + RCC_R0SEMCR)
+#define RCC_CID1	1
+
+/* Register: RIFSC_CIDCFGR */
+#define RCC_CIDCFGR_CFEN	BIT(0)
+#define RCC_CIDCFGR_SEM_EN	BIT(1)
+#define RCC_CIDCFGR_SEMWLC1_EN	BIT(17)
+#define RCC_CIDCFGR_SCID_MASK	GENMASK(6, 4)
+
+/* Register: RIFSC_SEMCR */
+#define RCC_SEMCR_SEMCID_MASK	GENMASK(6, 4)
+
+#define MP25_RIF_RCC_IS2M	107
+#define MP25_RIF_RCC_MCO1	108
+#define MP25_RIF_RCC_MCO2	109
+
+#define SEC_RIFSC_FLAG		BIT(31)
+#define SEC_RIFSC(_id)		((_id) | SEC_RIFSC_FLAG)
+
 enum {
 	HSE,
 	HSI,
@@ -1507,203 +1534,262 @@ static struct clk_stm32_gate ck_icn_p_wwdg2 = {
 	.hw.init = CLK_HW_INIT_INDEX("ck_icn_p_wwdg2", ICN_LS_MCU, &clk_stm32_gate_ops, 0),
 };
 
-#define SECF_NONE -1
+static struct stm32_firewall firewall;
+
+static int stm32_rcc_get_access(void __iomem *base, u32 index)
+{
+	u32 seccfgr, cidcfgr, semcr;
+	int bit, cid;
+
+	bit = index % RCC_REG_SIZE;
+
+	seccfgr = readl(base + RCC_SECCFGR(index));
+	if (seccfgr & BIT(bit))
+		return -EACCES;
+
+	cidcfgr = readl(base + RCC_CIDCFGR(index));
+	if (!(cidcfgr & RCC_CIDCFGR_CFEN))
+		/* CID filtering is turned off: access granted */
+		return 0;
+
+	if (!(cidcfgr & RCC_CIDCFGR_SEM_EN)) {
+		/* Static CID mode */
+		cid = FIELD_GET(RCC_CIDCFGR_SCID_MASK, cidcfgr);
+		if (cid != RCC_CID1)
+			return -EACCES;
+		return 0;
+	}
+
+	/* Pass-list with semaphore mode */
+	if (!(cidcfgr & RCC_CIDCFGR_SEMWLC1_EN))
+		return -EACCES;
+
+	semcr = readl(base + RCC_SEMCR(index));
+
+	cid = FIELD_GET(RCC_SEMCR_SEMCID_MASK, semcr);
+	if (cid != RCC_CID1)
+		return -EACCES;
+
+	return 0;
+}
+
+static int stm32mp25_check_security(struct device_node *np, void __iomem *base,
+				    const struct clock_config *cfg)
+{
+	int ret = 0;
+
+	if (cfg->sec_id != SECF_NONE) {
+		u32 index = (u32)cfg->sec_id;
+
+		if (index & SEC_RIFSC_FLAG) {
+			ret = stm32_firewall_grant_access_by_id(&firewall, index & ~SEC_RIFSC_FLAG);
+
+			/* If firewall is not present, assume that we have access */
+			if (ret == -ENODEV)
+				return 0;
+		} else {
+			ret = stm32_rcc_get_access(base, cfg->sec_id & ~SEC_RIFSC_FLAG);
+		}
+	}
+
+	return ret;
+}
 
 static const struct clock_config stm32mp25_clock_cfg[] = {
-	STM32_GATE_CFG(CK_BUS_ETH1,		ck_icn_p_eth1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ETH2,		ck_icn_p_eth2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_PCIE,		ck_icn_p_pcie,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ETHSW,		ck_icn_p_ethsw,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ADC12,		ck_icn_p_adc12,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ADC3,		ck_icn_p_adc3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_CCI,		ck_icn_p_cci,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_CRC,		ck_icn_p_crc,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_MDF1,		ck_icn_p_mdf1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_OSPIIOM,		ck_icn_p_ospiiom,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_HASH,		ck_icn_p_hash,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_CRYP1,		ck_icn_p_cryp1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_CRYP2,		ck_icn_p_cryp2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ADF1,		ck_icn_p_adf1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI8,		ck_icn_p_spi8,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LPUART1,		ck_icn_p_lpuart1,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C8,		ck_icn_p_i2c8,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LPTIM3,		ck_icn_p_lptim3,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LPTIM4,		ck_icn_p_lptim4,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LPTIM5,		ck_icn_p_lptim5,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_IWDG5,		ck_icn_p_iwdg5,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_WWDG2,		ck_icn_p_wwdg2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I3C4,		ck_icn_p_i3c4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SDMMC1,		ck_icn_m_sdmmc1,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SDMMC2,		ck_icn_m_sdmmc2,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SDMMC3,		ck_icn_m_sdmmc3,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USB2OHCI,		ck_icn_m_usb2ohci,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USB2EHCI,		ck_icn_m_usb2ehci,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USB3DR,		ck_icn_m_usb3dr,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM2,		ck_icn_p_tim2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM3,		ck_icn_p_tim3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM4,		ck_icn_p_tim4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM5,		ck_icn_p_tim5,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM6,		ck_icn_p_tim6,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM7,		ck_icn_p_tim7,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM10,		ck_icn_p_tim10,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM11,		ck_icn_p_tim11,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM12,		ck_icn_p_tim12,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM13,		ck_icn_p_tim13,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM14,		ck_icn_p_tim14,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LPTIM1,		ck_icn_p_lptim1,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LPTIM2,		ck_icn_p_lptim2,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI2,		ck_icn_p_spi2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI3,		ck_icn_p_spi3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPDIFRX,		ck_icn_p_spdifrx,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USART2,		ck_icn_p_usart2,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USART3,		ck_icn_p_usart3,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_UART4,		ck_icn_p_uart4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_UART5,		ck_icn_p_uart5,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C1,		ck_icn_p_i2c1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C2,		ck_icn_p_i2c2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C3,		ck_icn_p_i2c3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C4,		ck_icn_p_i2c4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C5,		ck_icn_p_i2c5,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C6,		ck_icn_p_i2c6,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I2C7,		ck_icn_p_i2c7,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I3C1,		ck_icn_p_i3c1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I3C2,		ck_icn_p_i3c2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_I3C3,		ck_icn_p_i3c3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM1,		ck_icn_p_tim1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM8,		ck_icn_p_tim8,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM15,		ck_icn_p_tim15,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM16,		ck_icn_p_tim16,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM17,		ck_icn_p_tim17,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_TIM20,		ck_icn_p_tim20,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SAI1,		ck_icn_p_sai1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SAI2,		ck_icn_p_sai2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SAI3,		ck_icn_p_sai3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SAI4,		ck_icn_p_sai4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USART1,		ck_icn_p_usart1,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USART6,		ck_icn_p_usart6,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_UART7,		ck_icn_p_uart7,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_UART8,		ck_icn_p_uart8,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_UART9,		ck_icn_p_uart9,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_FDCAN,		ck_icn_p_fdcan,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI1,		ck_icn_p_spi1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI4,		ck_icn_p_spi4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI5,		ck_icn_p_spi5,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI6,		ck_icn_p_spi6,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_SPI7,		ck_icn_p_spi7,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_IWDG2,		ck_icn_p_iwdg2,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_IWDG3,		ck_icn_p_iwdg3,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_IWDG4,		ck_icn_p_iwdg4,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_WWDG1,		ck_icn_p_wwdg1,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_VREF,		ck_icn_p_vref,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_HDP,		ck_icn_p_hdp,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_IS2M,		ck_icn_p_is2m,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_DSI,		ck_icn_p_dsi,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LTDC,		ck_icn_p_ltdc,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_CSI,		ck_icn_p_csi,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_DCMIPP,		ck_icn_p_dcmipp,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_LVDS,		ck_icn_p_lvds,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USBTC,		ck_icn_p_usbtc,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_USB3PCIEPHY,	ck_icn_p_usb3pciephy,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_VDEC,		ck_icn_p_vdec,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_VENC,		ck_icn_p_venc,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM2,		ck_ker_tim2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM3,		ck_ker_tim3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM4,		ck_ker_tim4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM5,		ck_ker_tim5,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM6,		ck_ker_tim6,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM7,		ck_ker_tim7,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM10,		ck_ker_tim10,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM11,		ck_ker_tim11,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM12,		ck_ker_tim12,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM13,		ck_ker_tim13,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM14,		ck_ker_tim14,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM1,		ck_ker_tim1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM8,		ck_ker_tim8,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM15,		ck_ker_tim15,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM16,		ck_ker_tim16,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM17,		ck_ker_tim17,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_TIM20,		ck_ker_tim20,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LPTIM1,		ck_ker_lptim1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LPTIM2,		ck_ker_lptim2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_USART2,		ck_ker_usart2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_UART4,		ck_ker_uart4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_USART3,		ck_ker_usart3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_UART5,		ck_ker_uart5,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI2,		ck_ker_spi2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI3,		ck_ker_spi3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPDIFRX,		ck_ker_spdifrx,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C1,		ck_ker_i2c1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C2,		ck_ker_i2c2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I3C1,		ck_ker_i3c1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I3C2,		ck_ker_i3c2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C3,		ck_ker_i2c3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C5,		ck_ker_i2c5,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I3C3,		ck_ker_i3c3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C4,		ck_ker_i2c4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C6,		ck_ker_i2c6,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C7,		ck_ker_i2c7,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI1,		ck_ker_spi1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI4,		ck_ker_spi4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI5,		ck_ker_spi5,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI6,		ck_ker_spi6,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI7,		ck_ker_spi7,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_USART1,		ck_ker_usart1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_USART6,		ck_ker_usart6,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_UART7,		ck_ker_uart7,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_UART8,		ck_ker_uart8,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_UART9,		ck_ker_uart9,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_MDF1,		ck_ker_mdf1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SAI1,		ck_ker_sai1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SAI2,		ck_ker_sai2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SAI3,		ck_ker_sai3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SAI4,		ck_ker_sai4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_FDCAN,		ck_ker_fdcan,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_CSI,		ck_ker_csi,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_CSITXESC,		ck_ker_csitxesc,	SECF_NONE),
-	STM32_GATE_CFG(CK_KER_CSIPHY,		ck_ker_csiphy,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_USBTC,		ck_ker_usbtc,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I3C4,		ck_ker_i3c4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SPI8,		ck_ker_spi8,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_I2C8,		ck_ker_i2c8,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LPUART1,		ck_ker_lpuart1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LPTIM3,		ck_ker_lptim3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LPTIM4,		ck_ker_lptim4,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LPTIM5,		ck_ker_lptim5,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ADF1,		ck_ker_adf1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SDMMC1,		ck_ker_sdmmc1,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SDMMC2,		ck_ker_sdmmc2,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_SDMMC3,		ck_ker_sdmmc3,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ETH1,		ck_ker_eth1,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH1_STP,		ck_ker_eth1stp,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ETHSW,		ck_ker_ethsw,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ETH2,		ck_ker_eth2,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH2_STP,		ck_ker_eth2stp,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ETH1PTP,		ck_ker_eth1ptp,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ETH2PTP,		ck_ker_eth2ptp,		SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_GPU,		ck_icn_m_gpu,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_GPU,		ck_ker_gpu,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_ETHSWREF,		ck_ker_ethswref,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ETHSWACMCFG,	ck_icn_p_ethsw_acm_cfg,	SECF_NONE),
-	STM32_GATE_CFG(CK_BUS_ETHSWACMMSG, ck_icn_p_ethsw_acm_msg,	SECF_NONE),
-	STM32_GATE_CFG(CK_ETH1_MAC,		ck_ker_eth1mac,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH1_TX,		ck_ker_eth1tx,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH1_RX,		ck_ker_eth1rx,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH2_MAC,		ck_ker_eth2mac,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH2_TX,		ck_ker_eth2tx,		SECF_NONE),
-	STM32_GATE_CFG(CK_ETH2_RX,		ck_ker_eth2rx,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_MCO1,		ck_mco1,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_MCO2,		ck_mco2,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_ADC12,	ck_ker_adc12,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_ADC3,	ck_ker_adc3,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_USB2PHY1,	ck_ker_usb2phy1,	SECF_NONE),
-	STM32_GATE_CFG(CK_KER_USB2PHY2,		ck_ker_usb2phy2,	SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_USB2PHY2EN,	ck_ker_usb2phy2_en,	SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_USB3PCIEPHY,	ck_ker_usb3pciephy,	SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_DSIBLANE,	clk_lanebyte,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_DSIPHY,	clk_phy_dsi,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_LVDSPHY,	ck_ker_lvdsphy,		SECF_NONE),
-	STM32_COMPOSITE_CFG(CK_KER_DTS,		ck_ker_dts,		SECF_NONE),
-	STM32_GATE_CFG(CK_KER_LTDC,		ck_ker_ltdc,		SECF_NONE),
+	STM32_GATE_CFG(CK_BUS_ETH1,		ck_icn_p_eth1,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_BUS_ETH2,		ck_icn_p_eth2,		SEC_RIFSC(61)),
+	STM32_GATE_CFG(CK_BUS_PCIE,		ck_icn_p_pcie,		SEC_RIFSC(68)),
+	STM32_GATE_CFG(CK_BUS_ETHSW,		ck_icn_p_ethsw,		SEC_RIFSC(70)),
+	STM32_GATE_CFG(CK_BUS_ADC12,		ck_icn_p_adc12,		SEC_RIFSC(58)),
+	STM32_GATE_CFG(CK_BUS_ADC3,		ck_icn_p_adc3,		SEC_RIFSC(59)),
+	STM32_GATE_CFG(CK_BUS_CCI,		ck_icn_p_cci,		SEC_RIFSC(88)),
+	STM32_GATE_CFG(CK_BUS_CRC,		ck_icn_p_crc,		SEC_RIFSC(109)),
+	STM32_GATE_CFG(CK_BUS_MDF1,		ck_icn_p_mdf1,		SEC_RIFSC(54)),
+	STM32_GATE_CFG(CK_BUS_OSPIIOM,		ck_icn_p_ospiiom,	SEC_RIFSC(111)),
+	STM32_GATE_CFG(CK_BUS_HASH,		ck_icn_p_hash,		SEC_RIFSC(95)),
+	STM32_GATE_CFG(CK_BUS_CRYP1,		ck_icn_p_cryp1,		SEC_RIFSC(96)),
+	STM32_GATE_CFG(CK_BUS_CRYP2,		ck_icn_p_cryp2,		SEC_RIFSC(97)),
+	STM32_GATE_CFG(CK_BUS_ADF1,		ck_icn_p_adf1,		SEC_RIFSC(55)),
+	STM32_GATE_CFG(CK_BUS_SPI8,		ck_icn_p_spi8,		SEC_RIFSC(29)),
+	STM32_GATE_CFG(CK_BUS_LPUART1,		ck_icn_p_lpuart1,	SEC_RIFSC(40)),
+	STM32_GATE_CFG(CK_BUS_I2C8,		ck_icn_p_i2c8,		SEC_RIFSC(48)),
+	STM32_GATE_CFG(CK_BUS_LPTIM3,		ck_icn_p_lptim3,	SEC_RIFSC(19)),
+	STM32_GATE_CFG(CK_BUS_LPTIM4,		ck_icn_p_lptim4,	SEC_RIFSC(20)),
+	STM32_GATE_CFG(CK_BUS_LPTIM5,		ck_icn_p_lptim5,	SEC_RIFSC(21)),
+	STM32_GATE_CFG(CK_BUS_IWDG5,		ck_icn_p_iwdg5,		SEC_RIFSC(102)),
+	STM32_GATE_CFG(CK_BUS_WWDG2,		ck_icn_p_wwdg2,		SEC_RIFSC(104)),
+	STM32_GATE_CFG(CK_BUS_I3C4,		ck_icn_p_i3c4,		SEC_RIFSC(117)),
+	STM32_GATE_CFG(CK_BUS_SDMMC1,		ck_icn_m_sdmmc1,	SEC_RIFSC(76)),
+	STM32_GATE_CFG(CK_BUS_SDMMC2,		ck_icn_m_sdmmc2,	SEC_RIFSC(77)),
+	STM32_GATE_CFG(CK_BUS_SDMMC3,		ck_icn_m_sdmmc3,	SEC_RIFSC(78)),
+	STM32_GATE_CFG(CK_BUS_USB2OHCI,		ck_icn_m_usb2ohci,	SEC_RIFSC(63)),
+	STM32_GATE_CFG(CK_BUS_USB2EHCI,		ck_icn_m_usb2ehci,	SEC_RIFSC(63)),
+	STM32_GATE_CFG(CK_BUS_USB3DR,		ck_icn_m_usb3dr,	SEC_RIFSC(66)),
+	STM32_GATE_CFG(CK_BUS_TIM2,		ck_icn_p_tim2,		SEC_RIFSC(1)),
+	STM32_GATE_CFG(CK_BUS_TIM3,		ck_icn_p_tim3,		SEC_RIFSC(2)),
+	STM32_GATE_CFG(CK_BUS_TIM4,		ck_icn_p_tim4,		SEC_RIFSC(3)),
+	STM32_GATE_CFG(CK_BUS_TIM5,		ck_icn_p_tim5,		SEC_RIFSC(4)),
+	STM32_GATE_CFG(CK_BUS_TIM6,		ck_icn_p_tim6,		SEC_RIFSC(5)),
+	STM32_GATE_CFG(CK_BUS_TIM7,		ck_icn_p_tim7,		SEC_RIFSC(6)),
+	STM32_GATE_CFG(CK_BUS_TIM10,		ck_icn_p_tim10,		SEC_RIFSC(8)),
+	STM32_GATE_CFG(CK_BUS_TIM11,		ck_icn_p_tim11,		SEC_RIFSC(9)),
+	STM32_GATE_CFG(CK_BUS_TIM12,		ck_icn_p_tim12,		SEC_RIFSC(10)),
+	STM32_GATE_CFG(CK_BUS_TIM13,		ck_icn_p_tim13,		SEC_RIFSC(11)),
+	STM32_GATE_CFG(CK_BUS_TIM14,		ck_icn_p_tim14,		SEC_RIFSC(12)),
+	STM32_GATE_CFG(CK_BUS_LPTIM1,		ck_icn_p_lptim1,	SEC_RIFSC(17)),
+	STM32_GATE_CFG(CK_BUS_LPTIM2,		ck_icn_p_lptim2,	SEC_RIFSC(18)),
+	STM32_GATE_CFG(CK_BUS_SPI2,		ck_icn_p_spi2,		SEC_RIFSC(23)),
+	STM32_GATE_CFG(CK_BUS_SPI3,		ck_icn_p_spi3,		SEC_RIFSC(24)),
+	STM32_GATE_CFG(CK_BUS_SPDIFRX,		ck_icn_p_spdifrx,	SEC_RIFSC(30)),
+	STM32_GATE_CFG(CK_BUS_USART2,		ck_icn_p_usart2,	SEC_RIFSC(32)),
+	STM32_GATE_CFG(CK_BUS_USART3,		ck_icn_p_usart3,	SEC_RIFSC(33)),
+	STM32_GATE_CFG(CK_BUS_UART4,		ck_icn_p_uart4,		SEC_RIFSC(34)),
+	STM32_GATE_CFG(CK_BUS_UART5,		ck_icn_p_uart5,		SEC_RIFSC(35)),
+	STM32_GATE_CFG(CK_BUS_I2C1,		ck_icn_p_i2c1,		SEC_RIFSC(41)),
+	STM32_GATE_CFG(CK_BUS_I2C2,		ck_icn_p_i2c2,		SEC_RIFSC(42)),
+	STM32_GATE_CFG(CK_BUS_I2C3,		ck_icn_p_i2c3,		SEC_RIFSC(43)),
+	STM32_GATE_CFG(CK_BUS_I2C4,		ck_icn_p_i2c4,		SEC_RIFSC(44)),
+	STM32_GATE_CFG(CK_BUS_I2C5,		ck_icn_p_i2c5,		SEC_RIFSC(45)),
+	STM32_GATE_CFG(CK_BUS_I2C6,		ck_icn_p_i2c6,		SEC_RIFSC(46)),
+	STM32_GATE_CFG(CK_BUS_I2C7,		ck_icn_p_i2c7,		SEC_RIFSC(47)),
+	STM32_GATE_CFG(CK_BUS_I3C1,		ck_icn_p_i3c1,		SEC_RIFSC(114)),
+	STM32_GATE_CFG(CK_BUS_I3C2,		ck_icn_p_i3c2,		SEC_RIFSC(115)),
+	STM32_GATE_CFG(CK_BUS_I3C3,		ck_icn_p_i3c3,		SEC_RIFSC(116)),
+	STM32_GATE_CFG(CK_BUS_TIM1,		ck_icn_p_tim1,		SEC_RIFSC(0)),
+	STM32_GATE_CFG(CK_BUS_TIM8,		ck_icn_p_tim8,		SEC_RIFSC(7)),
+	STM32_GATE_CFG(CK_BUS_TIM15,		ck_icn_p_tim15,		SEC_RIFSC(13)),
+	STM32_GATE_CFG(CK_BUS_TIM16,		ck_icn_p_tim16,		SEC_RIFSC(14)),
+	STM32_GATE_CFG(CK_BUS_TIM17,		ck_icn_p_tim17,		SEC_RIFSC(15)),
+	STM32_GATE_CFG(CK_BUS_TIM20,		ck_icn_p_tim20,		SEC_RIFSC(16)),
+	STM32_GATE_CFG(CK_BUS_SAI1,		ck_icn_p_sai1,		SEC_RIFSC(49)),
+	STM32_GATE_CFG(CK_BUS_SAI2,		ck_icn_p_sai2,		SEC_RIFSC(50)),
+	STM32_GATE_CFG(CK_BUS_SAI3,		ck_icn_p_sai3,		SEC_RIFSC(51)),
+	STM32_GATE_CFG(CK_BUS_SAI4,		ck_icn_p_sai4,		SEC_RIFSC(52)),
+	STM32_GATE_CFG(CK_BUS_USART1,		ck_icn_p_usart1,	SEC_RIFSC(31)),
+	STM32_GATE_CFG(CK_BUS_USART6,		ck_icn_p_usart6,	SEC_RIFSC(36)),
+	STM32_GATE_CFG(CK_BUS_UART7,		ck_icn_p_uart7,		SEC_RIFSC(37)),
+	STM32_GATE_CFG(CK_BUS_UART8,		ck_icn_p_uart8,		SEC_RIFSC(38)),
+	STM32_GATE_CFG(CK_BUS_UART9,		ck_icn_p_uart9,		SEC_RIFSC(39)),
+	STM32_GATE_CFG(CK_BUS_FDCAN,		ck_icn_p_fdcan,		SEC_RIFSC(56)),
+	STM32_GATE_CFG(CK_BUS_SPI1,		ck_icn_p_spi1,		SEC_RIFSC(22)),
+	STM32_GATE_CFG(CK_BUS_SPI4,		ck_icn_p_spi4,		SEC_RIFSC(25)),
+	STM32_GATE_CFG(CK_BUS_SPI5,		ck_icn_p_spi5,		SEC_RIFSC(26)),
+	STM32_GATE_CFG(CK_BUS_SPI6,		ck_icn_p_spi6,		SEC_RIFSC(27)),
+	STM32_GATE_CFG(CK_BUS_SPI7,		ck_icn_p_spi7,		SEC_RIFSC(28)),
+	STM32_GATE_CFG(CK_BUS_IWDG2,		ck_icn_p_iwdg2,		SEC_RIFSC(99)),
+	STM32_GATE_CFG(CK_BUS_IWDG3,		ck_icn_p_iwdg3,		SEC_RIFSC(100)),
+	STM32_GATE_CFG(CK_BUS_IWDG4,		ck_icn_p_iwdg4,		SEC_RIFSC(101)),
+	STM32_GATE_CFG(CK_BUS_WWDG1,		ck_icn_p_wwdg1,		SEC_RIFSC(103)),
+	STM32_GATE_CFG(CK_BUS_VREF,		ck_icn_p_vref,		SEC_RIFSC(106)),
+	STM32_GATE_CFG(CK_BUS_HDP,		ck_icn_p_hdp,		SEC_RIFSC(57)),
+	STM32_GATE_CFG(CK_BUS_IS2M,		ck_icn_p_is2m,		MP25_RIF_RCC_IS2M),
+	STM32_GATE_CFG(CK_BUS_DSI,		ck_icn_p_dsi,		SEC_RIFSC(81)),
+	STM32_GATE_CFG(CK_BUS_LTDC,		ck_icn_p_ltdc,		SEC_RIFSC(80)),
+	STM32_GATE_CFG(CK_BUS_CSI,		ck_icn_p_csi,		SEC_RIFSC(86)),
+	STM32_GATE_CFG(CK_BUS_DCMIPP,		ck_icn_p_dcmipp,	SEC_RIFSC(87)),
+	STM32_GATE_CFG(CK_BUS_LVDS,		ck_icn_p_lvds,		SEC_RIFSC(84)),
+	STM32_GATE_CFG(CK_BUS_USBTC,		ck_icn_p_usbtc,		SEC_RIFSC(69)),
+	STM32_GATE_CFG(CK_BUS_USB3PCIEPHY,	ck_icn_p_usb3pciephy,	SEC_RIFSC(67)),
+	STM32_GATE_CFG(CK_BUS_VDEC,		ck_icn_p_vdec,		SEC_RIFSC(89)),
+	STM32_GATE_CFG(CK_BUS_VENC,		ck_icn_p_venc,		SEC_RIFSC(90)),
+	STM32_GATE_CFG(CK_KER_TIM2,		ck_ker_tim2,		SEC_RIFSC(1)),
+	STM32_GATE_CFG(CK_KER_TIM3,		ck_ker_tim3,		SEC_RIFSC(2)),
+	STM32_GATE_CFG(CK_KER_TIM4,		ck_ker_tim4,		SEC_RIFSC(3)),
+	STM32_GATE_CFG(CK_KER_TIM5,		ck_ker_tim5,		SEC_RIFSC(4)),
+	STM32_GATE_CFG(CK_KER_TIM6,		ck_ker_tim6,		SEC_RIFSC(5)),
+	STM32_GATE_CFG(CK_KER_TIM7,		ck_ker_tim7,		SEC_RIFSC(6)),
+	STM32_GATE_CFG(CK_KER_TIM10,		ck_ker_tim10,		SEC_RIFSC(8)),
+	STM32_GATE_CFG(CK_KER_TIM11,		ck_ker_tim11,		SEC_RIFSC(9)),
+	STM32_GATE_CFG(CK_KER_TIM12,		ck_ker_tim12,		SEC_RIFSC(10)),
+	STM32_GATE_CFG(CK_KER_TIM13,		ck_ker_tim13,		SEC_RIFSC(11)),
+	STM32_GATE_CFG(CK_KER_TIM14,		ck_ker_tim14,		SEC_RIFSC(12)),
+	STM32_GATE_CFG(CK_KER_TIM1,		ck_ker_tim1,		SEC_RIFSC(0)),
+	STM32_GATE_CFG(CK_KER_TIM8,		ck_ker_tim8,		SEC_RIFSC(7)),
+	STM32_GATE_CFG(CK_KER_TIM15,		ck_ker_tim15,		SEC_RIFSC(13)),
+	STM32_GATE_CFG(CK_KER_TIM16,		ck_ker_tim16,		SEC_RIFSC(14)),
+	STM32_GATE_CFG(CK_KER_TIM17,		ck_ker_tim17,		SEC_RIFSC(15)),
+	STM32_GATE_CFG(CK_KER_TIM20,		ck_ker_tim20,		SEC_RIFSC(16)),
+	STM32_GATE_CFG(CK_KER_LPTIM1,		ck_ker_lptim1,		SEC_RIFSC(17)),
+	STM32_GATE_CFG(CK_KER_LPTIM2,		ck_ker_lptim2,		SEC_RIFSC(18)),
+	STM32_GATE_CFG(CK_KER_USART2,		ck_ker_usart2,		SEC_RIFSC(32)),
+	STM32_GATE_CFG(CK_KER_UART4,		ck_ker_uart4,		SEC_RIFSC(34)),
+	STM32_GATE_CFG(CK_KER_USART3,		ck_ker_usart3,		SEC_RIFSC(33)),
+	STM32_GATE_CFG(CK_KER_UART5,		ck_ker_uart5,		SEC_RIFSC(35)),
+	STM32_GATE_CFG(CK_KER_SPI2,		ck_ker_spi2,		SEC_RIFSC(23)),
+	STM32_GATE_CFG(CK_KER_SPI3,		ck_ker_spi3,		SEC_RIFSC(24)),
+	STM32_GATE_CFG(CK_KER_SPDIFRX,		ck_ker_spdifrx,		SEC_RIFSC(30)),
+	STM32_GATE_CFG(CK_KER_I2C1,		ck_ker_i2c1,		SEC_RIFSC(41)),
+	STM32_GATE_CFG(CK_KER_I2C2,		ck_ker_i2c2,		SEC_RIFSC(42)),
+	STM32_GATE_CFG(CK_KER_I3C1,		ck_ker_i3c1,		SEC_RIFSC(114)),
+	STM32_GATE_CFG(CK_KER_I3C2,		ck_ker_i3c2,		SEC_RIFSC(115)),
+	STM32_GATE_CFG(CK_KER_I2C3,		ck_ker_i2c3,		SEC_RIFSC(43)),
+	STM32_GATE_CFG(CK_KER_I2C5,		ck_ker_i2c5,		SEC_RIFSC(45)),
+	STM32_GATE_CFG(CK_KER_I3C3,		ck_ker_i3c3,		SEC_RIFSC(116)),
+	STM32_GATE_CFG(CK_KER_I2C4,		ck_ker_i2c4,		SEC_RIFSC(44)),
+	STM32_GATE_CFG(CK_KER_I2C6,		ck_ker_i2c6,		SEC_RIFSC(46)),
+	STM32_GATE_CFG(CK_KER_I2C7,		ck_ker_i2c7,		SEC_RIFSC(47)),
+	STM32_GATE_CFG(CK_KER_SPI1,		ck_ker_spi1,		SEC_RIFSC(22)),
+	STM32_GATE_CFG(CK_KER_SPI4,		ck_ker_spi4,		SEC_RIFSC(25)),
+	STM32_GATE_CFG(CK_KER_SPI5,		ck_ker_spi5,		SEC_RIFSC(26)),
+	STM32_GATE_CFG(CK_KER_SPI6,		ck_ker_spi6,		SEC_RIFSC(27)),
+	STM32_GATE_CFG(CK_KER_SPI7,		ck_ker_spi7,		SEC_RIFSC(28)),
+	STM32_GATE_CFG(CK_KER_USART1,		ck_ker_usart1,		SEC_RIFSC(31)),
+	STM32_GATE_CFG(CK_KER_USART6,		ck_ker_usart6,		SEC_RIFSC(36)),
+	STM32_GATE_CFG(CK_KER_UART7,		ck_ker_uart7,		SEC_RIFSC(37)),
+	STM32_GATE_CFG(CK_KER_UART8,		ck_ker_uart8,		SEC_RIFSC(38)),
+	STM32_GATE_CFG(CK_KER_UART9,		ck_ker_uart9,		SEC_RIFSC(39)),
+	STM32_GATE_CFG(CK_KER_MDF1,		ck_ker_mdf1,		SEC_RIFSC(54)),
+	STM32_GATE_CFG(CK_KER_SAI1,		ck_ker_sai1,		SEC_RIFSC(49)),
+	STM32_GATE_CFG(CK_KER_SAI2,		ck_ker_sai2,		SEC_RIFSC(50)),
+	STM32_GATE_CFG(CK_KER_SAI3,		ck_ker_sai3,		SEC_RIFSC(51)),
+	STM32_GATE_CFG(CK_KER_SAI4,		ck_ker_sai4,		SEC_RIFSC(52)),
+	STM32_GATE_CFG(CK_KER_FDCAN,		ck_ker_fdcan,		SEC_RIFSC(56)),
+	STM32_GATE_CFG(CK_KER_CSI,		ck_ker_csi,		SEC_RIFSC(86)),
+	STM32_GATE_CFG(CK_KER_CSITXESC,		ck_ker_csitxesc,	SEC_RIFSC(86)),
+	STM32_GATE_CFG(CK_KER_CSIPHY,		ck_ker_csiphy,		SEC_RIFSC(86)),
+	STM32_GATE_CFG(CK_KER_USBTC,		ck_ker_usbtc,		SEC_RIFSC(69)),
+	STM32_GATE_CFG(CK_KER_I3C4,		ck_ker_i3c4,		SEC_RIFSC(117)),
+	STM32_GATE_CFG(CK_KER_SPI8,		ck_ker_spi8,		SEC_RIFSC(29)),
+	STM32_GATE_CFG(CK_KER_I2C8,		ck_ker_i2c8,		SEC_RIFSC(48)),
+	STM32_GATE_CFG(CK_KER_LPUART1,		ck_ker_lpuart1,		SEC_RIFSC(40)),
+	STM32_GATE_CFG(CK_KER_LPTIM3,		ck_ker_lptim3,		SEC_RIFSC(19)),
+	STM32_GATE_CFG(CK_KER_LPTIM4,		ck_ker_lptim4,		SEC_RIFSC(20)),
+	STM32_GATE_CFG(CK_KER_LPTIM5,		ck_ker_lptim5,		SEC_RIFSC(21)),
+	STM32_GATE_CFG(CK_KER_ADF1,		ck_ker_adf1,		SEC_RIFSC(55)),
+	STM32_GATE_CFG(CK_KER_SDMMC1,		ck_ker_sdmmc1,		SEC_RIFSC(76)),
+	STM32_GATE_CFG(CK_KER_SDMMC2,		ck_ker_sdmmc2,		SEC_RIFSC(77)),
+	STM32_GATE_CFG(CK_KER_SDMMC3,		ck_ker_sdmmc3,		SEC_RIFSC(78)),
+	STM32_GATE_CFG(CK_KER_ETH1,		ck_ker_eth1,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_ETH1_STP,		ck_ker_eth1stp,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_KER_ETHSW,		ck_ker_ethsw,		SEC_RIFSC(70)),
+	STM32_GATE_CFG(CK_KER_ETH2,		ck_ker_eth2,		SEC_RIFSC(61)),
+	STM32_GATE_CFG(CK_ETH2_STP,		ck_ker_eth2stp,		SEC_RIFSC(61)),
+	STM32_GATE_CFG(CK_KER_ETH1PTP,		ck_ker_eth1ptp,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_KER_ETH2PTP,		ck_ker_eth2ptp,		SEC_RIFSC(61)),
+	STM32_GATE_CFG(CK_BUS_GPU,		ck_icn_m_gpu,		SEC_RIFSC(79)),
+	STM32_GATE_CFG(CK_KER_GPU,		ck_ker_gpu,		SEC_RIFSC(79)),
+	STM32_GATE_CFG(CK_KER_ETHSWREF,		ck_ker_ethswref,	SEC_RIFSC(70)),
+	STM32_GATE_CFG(CK_BUS_ETHSWACMCFG,	ck_icn_p_ethsw_acm_cfg,	SEC_RIFSC(71)),
+	STM32_GATE_CFG(CK_BUS_ETHSWACMMSG,	ck_icn_p_ethsw_acm_msg,	SEC_RIFSC(72)),
+	STM32_GATE_CFG(CK_ETH1_MAC,		ck_ker_eth1mac,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_ETH1_TX,		ck_ker_eth1tx,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_ETH1_RX,		ck_ker_eth1rx,		SEC_RIFSC(60)),
+	STM32_GATE_CFG(CK_ETH2_MAC,		ck_ker_eth2mac,		SEC_RIFSC(61)),
+	STM32_GATE_CFG(CK_ETH2_TX,		ck_ker_eth2tx,		SEC_RIFSC(61)),
+	STM32_GATE_CFG(CK_ETH2_RX,		ck_ker_eth2rx,		SEC_RIFSC(61)),
+	STM32_COMPOSITE_CFG(CK_MCO1,		ck_mco1,		MP25_RIF_RCC_MCO1),
+	STM32_COMPOSITE_CFG(CK_MCO2,		ck_mco2,		MP25_RIF_RCC_MCO1),
+	STM32_COMPOSITE_CFG(CK_KER_ADC12,	ck_ker_adc12,		SEC_RIFSC(58)),
+	STM32_COMPOSITE_CFG(CK_KER_ADC3,	ck_ker_adc3,		SEC_RIFSC(59)),
+	STM32_COMPOSITE_CFG(CK_KER_USB2PHY1,	ck_ker_usb2phy1,	SEC_RIFSC(63)),
+	STM32_GATE_CFG(CK_KER_USB2PHY2,		ck_ker_usb2phy2,	SEC_RIFSC(63)),
+	STM32_COMPOSITE_CFG(CK_KER_USB2PHY2EN,	ck_ker_usb2phy2_en,	SEC_RIFSC(63)),
+	STM32_COMPOSITE_CFG(CK_KER_USB3PCIEPHY,	ck_ker_usb3pciephy,	SEC_RIFSC(67)),
+	STM32_COMPOSITE_CFG(CK_KER_DSIBLANE,	clk_lanebyte,		SEC_RIFSC(81)),
+	STM32_COMPOSITE_CFG(CK_KER_DSIPHY,	clk_phy_dsi,		SEC_RIFSC(81)),
+	STM32_COMPOSITE_CFG(CK_KER_LVDSPHY,	ck_ker_lvdsphy,		SEC_RIFSC(84)),
+	STM32_COMPOSITE_CFG(CK_KER_DTS,		ck_ker_dts,		SEC_RIFSC(107)),
+	STM32_GATE_CFG(CK_KER_LTDC,		ck_ker_ltdc,		SEC_RIFSC(80)),
 };
 
 #define RESET_MP25(id, _offset, _bit_idx, _set_clr)	\
@@ -1839,6 +1925,7 @@ static const struct stm32_rcc_match_data stm32mp25_data = {
 	.maxbinding	= STM32MP25_LAST_CLK,
 	.clock_data	= &stm32mp25_clock_data,
 	.reset_data	= &stm32mp25_reset_data,
+	.check_security = &stm32mp25_check_security,
 };
 
 static const struct of_device_id stm32mp25_match_data[] = {
@@ -1851,11 +1938,16 @@ static int stm32mp25_rcc_clocks_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	void __iomem *base;
+	int ret;
 
 	base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(base))
 		return PTR_ERR(base);
 
+	ret = stm32_firewall_get_firewall(dev->of_node, &firewall, 1);
+	if (ret)
+		return ret;
+
 	return stm32_rcc_init(dev, stm32mp25_match_data, base);
 }
 
-- 
2.25.1


^ permalink raw reply related	[relevance 2%]

* [PATCH v2 3/3] arm64: dts: st: enable STM32 access controller for RCC
@ 2024-05-29 13:13  1%   ` gabriel.fernandez
  0 siblings, 0 replies; 200+ results
From: gabriel.fernandez @ 2024-05-29 13:13 UTC (permalink / raw)
  To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
	Alexandre Torgue, Michael Turquette, Stephen Boyd, Maxime Ripard,
	Gabriel Fernandez, Dan Carpenter
  Cc: devicetree, linux-stm32, linux-arm-kernel, linux-kernel, linux-clk

From: Gabriel Fernandez <gabriel.fernandez@foss.st.com>

Use an STM32 access controller to filter the registration of clocks.

Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com>
---
 arch/arm64/boot/dts/st/stm32mp251.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/boot/dts/st/stm32mp251.dtsi b/arch/arm64/boot/dts/st/stm32mp251.dtsi
index dcd0656d67a8..602d02efc202 100644
--- a/arch/arm64/boot/dts/st/stm32mp251.dtsi
+++ b/arch/arm64/boot/dts/st/stm32mp251.dtsi
@@ -441,6 +441,7 @@ rcc: clock-controller@44200000 {
 				<&scmi_clk CK_SCMI_TIMG2>,
 				<&scmi_clk CK_SCMI_PLL3>,
 				<&clk_dsi_txbyte>;
+				access-controllers = <&rifsc 156>;
 		};
 
 		exti1: interrupt-controller@44220000 {
-- 
2.25.1


^ permalink raw reply related	[relevance 1%]

* Re: [PATCH 1/3] kexec_load: Use new kexec flag for hotplug support
  @ 2024-05-29 13:13  3%   ` Sourabh Jain
  0 siblings, 0 replies; 200+ results
From: Sourabh Jain @ 2024-05-29 13:13 UTC (permalink / raw)
  To: Aditya Gupta; +Cc: kexec, Baoquan He, Coiby Xu, Hari Bathini, Mahesh Salgaonkar

Hello Aditya,


On 28/05/24 17:03, Aditya Gupta wrote:
> Hello sourabh,
>
> On Wed, May 22, 2024 at 06:43:51PM GMT, Sourabh Jain wrote:
>> Kernel commit 79365026f869 (crash: add a new kexec flag for hotplug
>> support) has introduced a new kexec flag to generalize hotplug support.
>> The newly introduced kexec flags for hotplug allow architectures to
>> exclude all the required kexec segments from SHA calculation so that
>> the kernel can update them on hotplug events. This was not possible
>> earlier with the KEXEC_UPDATE_ELFCOREHDR kexec flags since it was added
>> only for the elfcorehdr segment.
>>
>> To enable architectures to control the list of kexec segments to exclude
>> when hotplug support is enabled, add a new architecture-specific
>> function named arch_do_exclude_segment. During the SHA calculation, this
>> function gets called to let the architecture decide whether a specific
>> kexec segment should be considered for SHA calculation or not.
>>
>> Given that the KEXEC_UPDATE_ELFCOREHDR is no longer required and was
>> colliding with the KEXEC_LIVE_UPDATE update flag, it is removed.
>>
>> Cc: Aditya Gupta <adityag@linux.ibm.com>
>> Cc: Baoquan He <bhe@redhat.com>
>> Cc: Coiby Xu <coxu@redhat.com>
>> Cc: Hari Bathini <hbathini@linux.ibm.com>
>> Cc: Mahesh Salgaonkar <mahesh@linux.ibm.com>
>> Signed-off-by: Sourabh Jain <sourabhjain@linux.ibm.com>
>> ---
>>   kexec/arch/arm/kexec-arm.c             |  5 +++++
>>   kexec/arch/arm64/kexec-arm64.c         |  4 ++++
>>   kexec/arch/cris/kexec-cris.c           |  4 ++++
>>   kexec/arch/hppa/kexec-hppa.c           |  5 +++++
>>   kexec/arch/i386/kexec-x86.c            |  8 ++++++++
>>   kexec/arch/ia64/kexec-ia64.c           |  4 ++++
>>   kexec/arch/loongarch/kexec-loongarch.c |  5 +++++
>>   kexec/arch/m68k/kexec-m68k.c           |  5 +++++
>>   kexec/arch/mips/kexec-mips.c           |  4 ++++
>>   kexec/arch/ppc/kexec-ppc.c             |  4 ++++
>>   kexec/arch/ppc64/kexec-ppc64.c         |  5 +++++
>>   kexec/arch/s390/kexec-s390.c           |  5 +++++
>>   kexec/arch/sh/kexec-sh.c               |  5 +++++
>>   kexec/arch/x86_64/kexec-x86_64.c       |  5 +++++
>>   kexec/kexec-syscall.h                  |  2 +-
>>   kexec/kexec.c                          | 14 ++++++++------
>>   kexec/kexec.h                          |  2 ++
>>   17 files changed, 79 insertions(+), 7 deletions(-)
>>
>> diff --git a/kexec/arch/arm/kexec-arm.c b/kexec/arch/arm/kexec-arm.c
>> index 49f35b1..34531f9 100644
>> --- a/kexec/arch/arm/kexec-arm.c
>> +++ b/kexec/arch/arm/kexec-arm.c
>> @@ -148,3 +148,8 @@ int have_sysfs_fdt(void)
>>   {
>>   	return !access(SYSFS_FDT, F_OK);
>>   }
>> +
>> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
>> index 4a67b0d..9d052b0 100644
>> --- a/kexec/arch/arm64/kexec-arm64.c
>> +++ b/kexec/arch/arm64/kexec-arm64.c
>> @@ -1363,3 +1363,7 @@ void arch_reuse_initrd(void)
>>   void arch_update_purgatory(struct kexec_info *UNUSED(info))
>>   {
>>   }
>> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/cris/kexec-cris.c b/kexec/arch/cris/kexec-cris.c
>> index 3b69709..7f09121 100644
>> --- a/kexec/arch/cris/kexec-cris.c
>> +++ b/kexec/arch/cris/kexec-cris.c
>> @@ -109,3 +109,7 @@ unsigned long add_buffer(struct kexec_info *info, const void *buf,
>>                                       buf_min, buf_max, buf_end, 1);
>>   }
>>   
>> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/hppa/kexec-hppa.c b/kexec/arch/hppa/kexec-hppa.c
>> index 77c9739..a64dc3d 100644
>> --- a/kexec/arch/hppa/kexec-hppa.c
>> +++ b/kexec/arch/hppa/kexec-hppa.c
>> @@ -146,3 +146,8 @@ unsigned long virt_to_phys(unsigned long addr)
>>   {
>>   	return addr - phys_offset;
>>   }
>> +
>> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/i386/kexec-x86.c b/kexec/arch/i386/kexec-x86.c
>> index 444cb69..b4947a0 100644
>> --- a/kexec/arch/i386/kexec-x86.c
>> +++ b/kexec/arch/i386/kexec-x86.c
>> @@ -208,3 +208,11 @@ void arch_update_purgatory(struct kexec_info *info)
>>   	elf_rel_set_symbol(&info->rhdr, "panic_kernel",
>>   		&panic_kernel, sizeof(panic_kernel));
>>   }
>> +
>> +int arch_do_exclude_segment(struct kexec_segment *seg_ptr, struct kexec_info *info)
>> +{
>> +	if (info->elfcorehdr == (unsigned long) seg_ptr->mem)
>> +		return 1;
>> +
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/ia64/kexec-ia64.c b/kexec/arch/ia64/kexec-ia64.c
>> index 418d997..8d9c1f3 100644
>> --- a/kexec/arch/ia64/kexec-ia64.c
>> +++ b/kexec/arch/ia64/kexec-ia64.c
>> @@ -245,3 +245,7 @@ void arch_update_purgatory(struct kexec_info *UNUSED(info))
>>   {
>>   }
>>   
>> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/loongarch/kexec-loongarch.c b/kexec/arch/loongarch/kexec-loongarch.c
>> index 32a42d2..9a50ff6 100644
>> --- a/kexec/arch/loongarch/kexec-loongarch.c
>> +++ b/kexec/arch/loongarch/kexec-loongarch.c
>> @@ -378,3 +378,8 @@ unsigned long add_buffer(struct kexec_info *info, const void *buf,
>>   	return add_buffer_phys_virt(info, buf, bufsz, memsz, buf_align,
>>   				    buf_min, buf_max, buf_end, 1);
>>   }
>> +
>> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/m68k/kexec-m68k.c b/kexec/arch/m68k/kexec-m68k.c
>> index cb54927..0c7dbaf 100644
>> --- a/kexec/arch/m68k/kexec-m68k.c
>> +++ b/kexec/arch/m68k/kexec-m68k.c
>> @@ -108,3 +108,8 @@ void add_segment(struct kexec_info *info, const void *buf, size_t bufsz,
>>   {
>>   	add_segment_phys_virt(info, buf, bufsz, base, memsz, 1);
>>   }
>> +
>> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/mips/kexec-mips.c b/kexec/arch/mips/kexec-mips.c
>> index d8cbea8..94224ee 100644
>> --- a/kexec/arch/mips/kexec-mips.c
>> +++ b/kexec/arch/mips/kexec-mips.c
>> @@ -189,3 +189,7 @@ unsigned long add_buffer(struct kexec_info *info, const void *buf,
>>   				    buf_min, buf_max, buf_end, 1);
>>   }
>>   
>> +int arch_do_exclude_segment(const void *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/ppc/kexec-ppc.c b/kexec/arch/ppc/kexec-ppc.c
>> index 03bec36..c8af870 100644
>> --- a/kexec/arch/ppc/kexec-ppc.c
>> +++ b/kexec/arch/ppc/kexec-ppc.c
>> @@ -966,3 +966,7 @@ void arch_update_purgatory(struct kexec_info *UNUSED(info))
>>   {
>>   }
>>   
>> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/ppc64/kexec-ppc64.c b/kexec/arch/ppc64/kexec-ppc64.c
>> index bd5274c..fb27b6b 100644
>> --- a/kexec/arch/ppc64/kexec-ppc64.c
>> +++ b/kexec/arch/ppc64/kexec-ppc64.c
>> @@ -967,3 +967,8 @@ int arch_compat_trampoline(struct kexec_info *UNUSED(info))
>>   void arch_update_purgatory(struct kexec_info *UNUSED(info))
>>   {
>>   }
>> +
>> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/s390/kexec-s390.c b/kexec/arch/s390/kexec-s390.c
>> index 33ba6b9..0561ee7 100644
>> --- a/kexec/arch/s390/kexec-s390.c
>> +++ b/kexec/arch/s390/kexec-s390.c
>> @@ -267,3 +267,8 @@ int get_crash_kernel_load_range(uint64_t *start, uint64_t *end)
>>   {
>>   	return parse_iomem_single("Crash kernel\n", start, end);
>>   }
>> +
>> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/sh/kexec-sh.c b/kexec/arch/sh/kexec-sh.c
>> index ce341c8..f84c40c 100644
>> --- a/kexec/arch/sh/kexec-sh.c
>> +++ b/kexec/arch/sh/kexec-sh.c
>> @@ -257,3 +257,8 @@ unsigned long add_buffer(struct kexec_info *info, const void *buf,
>>   	return add_buffer_phys_virt(info, buf, bufsz, memsz, buf_align,
>>   				    buf_min, buf_max, buf_end, 1);
>>   }
>> +
>> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
>> diff --git a/kexec/arch/x86_64/kexec-x86_64.c b/kexec/arch/x86_64/kexec-x86_64.c
>> index ffd84f0..42af90a 100644
>> --- a/kexec/arch/x86_64/kexec-x86_64.c
>> +++ b/kexec/arch/x86_64/kexec-x86_64.c
>> @@ -188,3 +188,8 @@ void arch_update_purgatory(struct kexec_info *info)
>>   	elf_rel_set_symbol(&info->rhdr, "panic_kernel",
>>   				&panic_kernel, sizeof(panic_kernel));
>>   }
>> +
>> +int arch_do_exclude_segment(struct kexec_segment *UNUSED(seg_ptr), struct kexec_info *UNUSED(info))
>> +{
>> +	return 0;
>> +}
> Should all arch_do_exclude_segment return 1 for elfcorehdr ? Please
> refer my below comment.

No they shouldn't until they have CRASH_HTOPLUG support in the kernel.


>
>> diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h
>> index 73e5254..4675c46 100644
>> --- a/kexec/kexec-syscall.h
>> +++ b/kexec/kexec-syscall.h
>> @@ -112,7 +112,7 @@ static inline long kexec_file_load(int kernel_fd, int initrd_fd,
>>   
>>   #define KEXEC_ON_CRASH		0x00000001
>>   #define KEXEC_PRESERVE_CONTEXT	0x00000002
>> -#define KEXEC_UPDATE_ELFCOREHDR	0x00000004
>> +#define KEXEC_CRASH_HOTPLUG_SUPPORT	0x00000008
>>   #define KEXEC_ARCH_MASK		0xffff0000
>>   
>>   /* Flags for kexec file based system call */
>> diff --git a/kexec/kexec.c b/kexec/kexec.c
>> index 222f79e..034cea6 100644
>> --- a/kexec/kexec.c
>> +++ b/kexec/kexec.c
>> @@ -701,10 +701,13 @@ static void update_purgatory(struct kexec_info *info)
>>   			continue;
>>   		}
>>   
>> -		/* Don't include elfcorehdr in the checksum, if hotplug
>> -		 * support enabled.
>> +		/*
>> +		 * Let architecture decide which segments to exclude from checksum
>> +		 * if hotplug support is enabled.
>>   		 */
>> -		if (do_hotplug && (info->segment[i].mem == (void *)info->elfcorehdr)) {
>> +		if (do_hotplug && arch_do_exclude_segment(&info->segment[i], info)) {
>> +			dbgprintf("Skipping segment mem: 0x%lx from SHA calculation\n",
>> +				  (unsigned long)info->segment[i].mem);
>>   			continue;
>>   		}
> Current behaviour seems to skip elfcorehdr segment in all architectures.
>
> But now as all architectures are returning 0 in arch_do_exclude_segment,
> will elfcorehdr still be skipped ?

Skipping elfcorehdr for architectures that don't support CRASH_HOTPLUG 
is, I think, incorrect.
Therefore, I believe the proposed approach in this patch, which asks the 
architecture which
segments to exclude, is better.

> Rest all looks good to me.

Thanks for the review.


- Sourabh Jain

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[relevance 3%]

* Re: NFSD: Unable to initialize client recovery tracking! (-110)
    2024-05-29 12:51  0%         ` Linux regression tracking (Thorsten Leemhuis)
@ 2024-05-29 13:13  0%         ` Jeff Layton
  2024-05-29 13:16  0%           ` Chuck Lever III
  2024-05-29 13:27  0%           ` Paul Menzel
  1 sibling, 2 replies; 200+ results
From: Jeff Layton @ 2024-05-29 13:13 UTC (permalink / raw)
  To: Chuck Lever III, Linux regressions mailing list
  Cc: Paul Menzel, Linux NFS Mailing List, it+linux-nfs, Linus Torvalds

On Fri, 2024-05-24 at 16:09 +0000, Chuck Lever III wrote:
> 
> 
> > On May 24, 2024, at 7:16 AM, Linux regression tracking (Thorsten
> > Leemhuis) <regressions@leemhuis.info> wrote:
> > 
> > On 21.05.24 12:01, Jeff Layton wrote:
> > > On Tue, 2024-05-21 at 11:55 +0200, Paul Menzel wrote:
> > > > Am 19.04.24 um 18:50 schrieb Paul Menzel:
> > > > 
> > > > > Since at least Linux 6.8-rc6, Linux logs the warning below:
> > > > > 
> > > > >     NFSD: Unable to initialize client recovery tracking! (-
> > > > > 110)
> > > > > 
> > > > > I haven’t had time to bisect yet, so if you have an idea,
> > > > > that’d be great.
> > > > 
> > > > 74fd48739d0488e39ae18b0168720f449a06690c is the first bad
> > > > commit
> > > > commit 74fd48739d0488e39ae18b0168720f449a06690c
> > > > Author: Jeff Layton <jlayton@kernel.org>
> > > > Date:   Fri Oct 13 09:03:53 2023 -0400
> > > > 
> > > >     nfsd: new Kconfig option for legacy client tracking
> > > > 
> > > >     We've had a number of attempts at different NFSv4 client
> > > > tracking
> > > >     methods over the years, but now nfsdcld has emerged as the
> > > > clear winner
> > > >     since the others (recoverydir and the usermodehelper
> > > > upcall) are
> > > >     problematic.
> > > [...]
> > > It sounds like you need to enable nfsdcld in your environment.
> > > The old
> > > recovery tracking methods are deprecated. The only surviving one
> > > requires the nfsdcld daemon to be running when recovery tracking
> > > is
> > > started. Alternately, you can enable this option in your kernels
> > > if you
> > > want to keep using the deprecated methods in the interim.
> > 
> > Hmm. Then why didn't this new config option default to "Y" for a
> > while
> > (say a year or two) before changing the default to off? That would
> > have
> > prevented people like Paul from running into the problem when
> > running
> > "olddefconfig". I think that is what Linus would have wanted in a
> > case
> > like this, but might be totally wrong there (I CCed him, in case he
> > wants to share his opinion, but maybe he does not care much).
> 
> That's fair. I recall we believed at the time that very few people
> if anyone currently use a legacy recovery tracking mechanism, and
> the workaround, if they do, is easy.
> 
> 
> > But I guess that's too late now, unless we want to meddle with
> > config
> > option names. But I guess that might not be worth it after half a
> > year
> > for something that only causes a warning (aiui).
> 
> In Paul's case, the default behavior might prevent proper NFSv4
> state recovery, which is a little more hazardous than a mere
> warning, IIUC.
> 
> To my surprise, it often takes quite some time for changes like
> this to matriculate into mainstream usage, so half a year isn't
> that long. We might want to change to a more traditional
> deprecation path (default Y with warning, wait, default N, wait,
> redact the old code).
> 

I've no objection if you want to do that.

I'm more concerned about Paul's setup though. Paul, what distro are you
running that starts nfsd (and presumably, mountd, etc.), but doesn't
bother starting nfsdcld?

Reenabling this for now is an OK workaround, but we need to understand
where these setups are coming from, and probably do some sort of
outreach to get them working properly.
-- 
Jeff Layton <jlayton@kernel.org>

^ permalink raw reply	[relevance 0%]

* Re: [PATCH 1/1] arm/sbsa-ref: move to Neoverse-N2 as default
  @ 2024-05-29 13:11  0% ` Leif Lindholm
  0 siblings, 0 replies; 200+ results
From: Leif Lindholm @ 2024-05-29 13:11 UTC (permalink / raw)
  To: Marcin Juszkiewicz, qemu-devel
  Cc: Peter Maydell, Radoslaw Biernacki, qemu-arm

On 2024-05-23 17:53, Marcin Juszkiewicz wrote:
> Moving to Neoverse-N2 gives us several cpu features to use for expanding
> our platform:
> 
> - branch target identification
> - pointer authentication
> - RME for confidential computing
> - RNG for EFI_PROTOCOL_RNG
> - SVE being enabled by default
> 
> We do not go for "max" as default to have stable set of features enabled
> by default. It is still supported and can be selected with "--cpu"
> argument.

I still want to move to max at some point :)
But this is a good improvement for now.

Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>

> Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
> ---
>   hw/arm/sbsa-ref.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/hw/arm/sbsa-ref.c b/hw/arm/sbsa-ref.c
> index 57c337fd92..e884692f07 100644
> --- a/hw/arm/sbsa-ref.c
> +++ b/hw/arm/sbsa-ref.c
> @@ -891,7 +891,7 @@ static void sbsa_ref_class_init(ObjectClass *oc, void *data)
>   
>       mc->init = sbsa_ref_init;
>       mc->desc = "QEMU 'SBSA Reference' ARM Virtual Machine";
> -    mc->default_cpu_type = ARM_CPU_TYPE_NAME("neoverse-n1");
> +    mc->default_cpu_type = ARM_CPU_TYPE_NAME("neoverse-n2");
>       mc->valid_cpu_types = valid_cpu_types;
>       mc->max_cpus = 512;
>       mc->pci_allow_0_address = true;



^ permalink raw reply	[relevance 0%]

* Re: [Intel-wired-lan] [PATCH iwl-next v6 11/12] iavf: handle SIOCSHWTSTAMP and SIOCGHWTSTAMP
  @ 2024-05-29 13:12  0%         ` Mateusz Polchlopek
  0 siblings, 0 replies; 200+ results
From: Mateusz Polchlopek @ 2024-05-29 13:12 UTC (permalink / raw)
  To: Keller, Jacob E, Jakub Kicinski
  Cc: Drewek, Wojciech, netdev, Rahul Rameshbabu, intel-wired-lan

On 5/29/2024 1:54 AM, Keller, Jacob E wrote:
> 
> 
>> -----Original Message-----
>> From: Jakub Kicinski <kuba@kernel.org>
>> Sent: Tuesday, May 28, 2024 1:01 PM
>> To: Polchlopek, Mateusz <mateusz.polchlopek@intel.com>
>> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; Keller, Jacob E
>> <jacob.e.keller@intel.com>; Drewek, Wojciech <wojciech.drewek@intel.com>;
>> Rahul Rameshbabu <rrameshbabu@nvidia.com>
>> Subject: Re: [Intel-wired-lan] [PATCH iwl-next v6 11/12] iavf: handle
>> SIOCSHWTSTAMP and SIOCGHWTSTAMP
>>
>> On Tue, 28 May 2024 07:23:00 -0400 Mateusz Polchlopek wrote:
>>> +	.ndo_eth_ioctl		= iavf_do_ioctl,
>>
>> Please use the new ndos:
>>
>>   * int (*ndo_hwtstamp_get)(struct net_device *dev,
>>   *			   struct kernel_hwtstamp_config *kernel_config);
>>   *	Get the currently configured hardware timestamping parameters for the
>>   *	NIC device.
>>   *
>>   * int (*ndo_hwtstamp_set)(struct net_device *dev,
>>   *			   struct kernel_hwtstamp_config *kernel_config,
>>   *			   struct netlink_ext_ack *extack);
>>   *	Change the hardware timestamping parameters for NIC device.
> 
> +1, this is an excellent cleanup.
> 
> Thanks,
> Jake

Hmmm... sounds good :) Thanks for pointing that, I will take a look
and will try to prepare solution in next version

^ permalink raw reply	[relevance 0%]

* Re: [Intel-wired-lan] [PATCH iwl-next v6 11/12] iavf: handle SIOCSHWTSTAMP and SIOCGHWTSTAMP
@ 2024-05-29 13:12  0%         ` Mateusz Polchlopek
  0 siblings, 0 replies; 200+ results
From: Mateusz Polchlopek @ 2024-05-29 13:12 UTC (permalink / raw)
  To: Keller, Jacob E, Jakub Kicinski
  Cc: intel-wired-lan, netdev, Drewek, Wojciech, Rahul Rameshbabu

On 5/29/2024 1:54 AM, Keller, Jacob E wrote:
> 
> 
>> -----Original Message-----
>> From: Jakub Kicinski <kuba@kernel.org>
>> Sent: Tuesday, May 28, 2024 1:01 PM
>> To: Polchlopek, Mateusz <mateusz.polchlopek@intel.com>
>> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; Keller, Jacob E
>> <jacob.e.keller@intel.com>; Drewek, Wojciech <wojciech.drewek@intel.com>;
>> Rahul Rameshbabu <rrameshbabu@nvidia.com>
>> Subject: Re: [Intel-wired-lan] [PATCH iwl-next v6 11/12] iavf: handle
>> SIOCSHWTSTAMP and SIOCGHWTSTAMP
>>
>> On Tue, 28 May 2024 07:23:00 -0400 Mateusz Polchlopek wrote:
>>> +	.ndo_eth_ioctl		= iavf_do_ioctl,
>>
>> Please use the new ndos:
>>
>>   * int (*ndo_hwtstamp_get)(struct net_device *dev,
>>   *			   struct kernel_hwtstamp_config *kernel_config);
>>   *	Get the currently configured hardware timestamping parameters for the
>>   *	NIC device.
>>   *
>>   * int (*ndo_hwtstamp_set)(struct net_device *dev,
>>   *			   struct kernel_hwtstamp_config *kernel_config,
>>   *			   struct netlink_ext_ack *extack);
>>   *	Change the hardware timestamping parameters for NIC device.
> 
> +1, this is an excellent cleanup.
> 
> Thanks,
> Jake

Hmmm... sounds good :) Thanks for pointing that, I will take a look
and will try to prepare solution in next version

^ permalink raw reply	[relevance 0%]

* [PATCH V1 5/5] Add support for Awinic sar sensor.
    2024-05-29 13:06  3% ` [PATCH V1 1/5] dt-bindings: input: Add YAML to Awinic sar sensor wangshuaijie
  2024-05-29 13:06  2% ` [PATCH V1 2/5] Add universal interface for the aw_sar driver wangshuaijie
@ 2024-05-29 13:06  2% ` wangshuaijie
  2 siblings, 0 replies; 200+ results
From: wangshuaijie @ 2024-05-29 13:06 UTC (permalink / raw)
  To: dmitry.torokhov, robh, krzk+dt, conor+dt, jeff, linux-input,
	devicetree, linux-kernel
  Cc: wangshuaijie, liweilei, kangjiajun

From: shuaijie wang <wangshuaijie@awinic.com>

Signed-off-by: shuaijie wang <wangshuaijie@awinic.com>
---
 drivers/input/misc/Kconfig         |    9 +
 drivers/input/misc/Makefile        |    1 +
 drivers/input/misc/aw_sar/Makefile |    2 +
 drivers/input/misc/aw_sar/aw_sar.c | 2039 ++++++++++++++++++++++++++++
 drivers/input/misc/aw_sar/aw_sar.h |   15 +
 5 files changed, 2066 insertions(+)
 create mode 100644 drivers/input/misc/aw_sar/Makefile
 create mode 100644 drivers/input/misc/aw_sar/aw_sar.c
 create mode 100644 drivers/input/misc/aw_sar/aw_sar.h

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 6ba984d7f0b1..ac56fdd21839 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -939,4 +939,13 @@ config INPUT_STPMIC1_ONKEY
 	  To compile this driver as a module, choose M here: the
 	  module will be called stpmic1_onkey.
 
+config AWINIC_SAR
+	tristate "Awinic sar sensor support"
+	depends on I2C
+	help
+	  Say Y to enable support for the Awinic sar sensor driver.
+
+	  To compile this driver as a module, choose M here: the
+	  module will be called awinic_sar.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 04296a4abe8e..6ee1870ea677 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -90,3 +90,4 @@ obj-$(CONFIG_INPUT_WM831X_ON)		+= wm831x-on.o
 obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)	+= xen-kbdfront.o
 obj-$(CONFIG_INPUT_YEALINK)		+= yealink.o
 obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR)	+= ideapad_slidebar.o
+obj-$(CONFIG_AWINIC_SAR)		+= aw_sar/
diff --git a/drivers/input/misc/aw_sar/Makefile b/drivers/input/misc/aw_sar/Makefile
new file mode 100644
index 000000000000..c357ecaa4f98
--- /dev/null
+++ b/drivers/input/misc/aw_sar/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_AWINIC_SAR) += awinic_sar.o
+awinic_sar-objs := ./comm/aw_sar_comm_interface.o aw_sar.o ./aw9610x/aw9610x.o ./aw963xx/aw963xx.o
diff --git a/drivers/input/misc/aw_sar/aw_sar.c b/drivers/input/misc/aw_sar/aw_sar.c
new file mode 100644
index 000000000000..c0c37658a482
--- /dev/null
+++ b/drivers/input/misc/aw_sar/aw_sar.c
@@ -0,0 +1,2039 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AWINIC sar sensor driver
+ *
+ * Author: Shuaijie Wang<wangshuaijie@awinic.com>
+ *
+ * Copyright (c) 2024 awinic Technology CO., LTD
+ */
+#include "./comm/aw_sar_chip_interface.h"
+#include "aw_sar.h"
+
+#define AW_SAR_I2C_NAME		"awinic_sar"
+
+/*
+ * Please check which power_supply on your platform
+ * can get the charger insertion information, then select it.
+ * eg: "usb"/"charger"/"mtk-master-charger"/"mtk_charger_type"
+ */
+#define USB_POWER_SUPPLY_NAME   "charger"
+/*
+ * Check which of your power_supply properties is available
+ * for the charger insertion information and select it.
+ * eg: POWER_SUPPLY_PROP_ONLINE/POWER_SUPPLY_PROP_PRESENT
+ */
+#define AW_USB_PROP_ONLINE	POWER_SUPPLY_PROP_ONLINE
+
+#define AW_I2C_RW_RETRY_TIME_MIN		(2000)
+#define AW_I2C_RW_RETRY_TIME_MAX		(3000)
+#define AW_RETRIES				(5)
+
+#define AW_SAR_AWRW_OffSET			(20)
+#define AW_SAR_AWRW_DATA_WIDTH			(5)
+#define AW_DATA_OffSET_2			(2)
+#define AW_DATA_OffSET_3			(3)
+#define AW_POWER_ON_SYSFS_DELAY_MS		(5000)
+#define AW_SAR_MONITOR_ESD_DELAY_MS		(5000)
+#define AW_SAR_OFFSET_LEN			(15)
+#define AW_SAR_VCC_MIN_UV			(1700000)
+#define AW_SAR_VCC_MAX_UV			(3600000)
+
+static struct mutex aw_sar_lock;
+
+static int32_t aw_sar_get_chip_info(struct aw_sar *p_sar);
+static void aw_sar_sensor_free(struct aw_sar *p_sar);
+
+//Because disable/enable_irq api Therefore, IRQ is embedded
+void aw_sar_disable_irq(struct aw_sar *p_sar)
+{
+	if (p_sar->irq_init.host_irq_stat == IRQ_ENABLE) {
+		disable_irq(p_sar->irq_init.to_irq);
+		p_sar->irq_init.host_irq_stat = IRQ_DISABLE;
+	}
+}
+
+void aw_sar_enable_irq(struct aw_sar *p_sar)
+{
+	if (p_sar->irq_init.host_irq_stat == IRQ_DISABLE) {
+		enable_irq(p_sar->irq_init.to_irq);
+		p_sar->irq_init.host_irq_stat = IRQ_ENABLE;
+	}
+}
+
+//Chip logic part start
+//Load default array function
+static int32_t
+aw_sar_para_loaded_func(struct i2c_client *i2c, const struct aw_sar_para_load_t *para_load)
+{
+	int32_t ret;
+	int32_t i;
+
+	for (i = 0; i < para_load->reg_arr_len; i = i + 2) {
+		ret = aw_sar_i2c_write(i2c, (uint16_t)para_load->reg_arr[i],
+						para_load->reg_arr[i + 1]);
+		if (ret != 0)
+			return ret;
+	}
+
+	return 0;
+}
+
+//Mode setting function
+static void aw_sar_mode_set_func(struct i2c_client *i2c, int to_irq,
+		struct aw_sar_mode_set_t *mode_set_para,
+		const struct aw_sar_mode_set_t *mode_set, uint8_t len)
+{
+	uint8_t i;
+
+	for (i = 0; i < len; i++) {
+		if ((mode_set[i].chip_mode.curr_mode == mode_set_para->chip_mode.curr_mode) &&
+				(mode_set[i].chip_mode.last_mode == mode_set_para->chip_mode.last_mode) &&
+				((mode_set[i].chip_id == AW_SAR_NONE_CHECK_CHIP) ||
+				 ((mode_set[i].chip_id & mode_set_para->chip_id) != 0))) {
+			if (mode_set[i].mode_switch_ops.enable_clock != NULL)
+				mode_set[i].mode_switch_ops.enable_clock(i2c);
+			if (mode_set[i].mode_switch_ops.rc_irqscr != NULL)
+				mode_set[i].mode_switch_ops.rc_irqscr(i2c);
+			if (mode_set[i].mode_switch_ops.mode_update != NULL)
+				mode_set[i].mode_switch_ops.mode_update(i2c);
+			break;
+		}
+	}
+}
+
+static int32_t aw_sar_check_init_over_irq_func(struct i2c_client *i2c,
+					const struct aw_sar_init_over_irq_t *p_check_irq)
+{
+	int16_t cnt = p_check_irq->wait_times;
+	uint32_t irq_stat;
+	int32_t ret;
+
+	do {
+		ret = aw_sar_i2c_read(i2c, p_check_irq->reg_irqsrc, &irq_stat);
+		if (ret < 0)
+			return ret;
+		if (((irq_stat >> p_check_irq->irq_offset_bit) & p_check_irq->irq_mask) ==
+				p_check_irq->irq_flag)
+			return 0;
+		mdelay(1);
+	} while (cnt--);
+
+	if (cnt < 0)
+		dev_err(&i2c->dev, "init over irq error!");
+
+	return AW_ERR_IRQ_INIT_OVER;
+}
+
+static int32_t
+aw_sar_soft_reset_func(struct i2c_client *i2c, const struct aw_sar_soft_rst_t *p_soft_rst)
+{
+	int32_t ret;
+
+	ret = aw_sar_i2c_write(i2c, p_soft_rst->reg_rst, p_soft_rst->reg_rst_val);
+	if (ret < 0) {
+		dev_err(&i2c->dev, "soft_reset error: %d", ret);
+		return ret;
+	}
+
+	msleep(p_soft_rst->delay_ms);
+
+	return 0;
+}
+//Chip logic part end
+
+static int32_t aw_sar_parse_bin(const struct firmware *cont, struct aw_sar *p_sar)
+{
+	enum aw_bin_err_val bin_ret;
+	struct aw_bin *aw_bin;
+	int32_t ret;
+
+	if (!cont) {
+		dev_err(p_sar->dev, "def_reg_bin request error!");
+		return -EINVAL;
+	}
+
+	dev_dbg(p_sar->dev, "Bin file size: %d", (uint32_t)cont->size);
+
+	aw_bin = devm_kzalloc(p_sar->dev, cont->size + sizeof(struct aw_bin), GFP_KERNEL);
+	if (!aw_bin) {
+		release_firmware(cont);
+		dev_err(p_sar->dev, "failed to allcating memory!");
+		return -ENOMEM;
+	}
+
+	aw_bin->info.len = cont->size;
+	memcpy(aw_bin->info.data, cont->data, cont->size);
+
+	bin_ret = aw_sar_parsing_bin_file(aw_bin);
+	if (bin_ret < 0) {
+		dev_err(p_sar->dev, "parse bin fail! bin_ret = %d", bin_ret);
+		goto err;
+	}
+
+	//Write bin file execution process
+	if (p_sar->load_bin.bin_opera_func != NULL) {
+		ret = p_sar->load_bin.bin_opera_func(aw_bin, p_sar);
+		if (ret != 0) {
+			dev_err(p_sar->dev, "load_bin_to_chip error!");
+			if (p_sar->load_bin.bin_load_fail_opera_func != NULL) {
+				ret = p_sar->load_bin.bin_load_fail_opera_func(aw_bin, p_sar);
+				if (ret != 0) {
+					dev_err(p_sar->dev, "bin_load_fail_opera_func error!");
+					goto err;
+				}
+			} else {
+				goto err;
+			}
+		}
+	} else {
+		dev_err(p_sar->dev, "bin_opera_func is null error!");
+	}
+
+	if (aw_bin != NULL)
+		devm_kfree(p_sar->dev, aw_bin);
+
+	return 0;
+err:
+	if (aw_bin != NULL)
+		devm_kfree(p_sar->dev, aw_bin);
+
+	return -EINVAL;
+}
+
+static int32_t aw_sar_load_bin_comm(struct aw_sar *p_sar)
+{
+	const struct firmware *fw;
+	int32_t ret;
+
+	ret = request_firmware(&fw, p_sar->load_bin.bin_name, p_sar->dev);
+	if (ret != 0) {
+		dev_err(p_sar->dev, "parse %s error!", p_sar->load_bin.bin_name);
+		return ret;
+	}
+
+	ret = aw_sar_parse_bin(fw, p_sar);
+	if (ret != 0) {
+		dev_err(p_sar->dev, "reg_bin %s load error!", p_sar->load_bin.bin_name);
+		return ret;
+	}
+	release_firmware(fw);
+
+	return 0;
+}
+
+static int32_t aw_sar_parse_dts_comm(struct device *dev, struct device_node *np,
+		struct aw_sar_dts_info *p_dts_info)
+{
+	int32_t val;
+
+	val = of_property_read_u32(np, "sar-num", &p_dts_info->sar_num);
+	dev_info(dev, "sar num = %d", p_dts_info->sar_num);
+	if (val != 0) {
+		dev_err(dev, "multiple sar failed!");
+		return -EINVAL;
+	}
+
+	p_dts_info->irq_gpio = of_get_named_gpio(np, "irq-gpio", 0);
+	if (p_dts_info->irq_gpio < 0) {
+		p_dts_info->irq_gpio = -1;
+		dev_err(dev, "no irq gpio provided.");
+		return -EINVAL;
+	}
+
+	val = of_property_read_u32(np, "channel_use_flag", &p_dts_info->channel_use_flag);
+	if (val != 0) {
+		dev_err(dev, "channel_use_flag failed!");
+		return -EINVAL;
+	}
+
+	//GPIO is set as internal pull-up input
+	p_dts_info->use_inter_pull_up = of_property_read_bool(np, "aw_sar,pin_set_inter_pull-up");
+	p_dts_info->use_pm = of_property_read_bool(np, "aw_sar,using_pm_ops");
+	p_dts_info->update_fw_flag = of_property_read_bool(np, "aw_sar,update_fw");
+	p_dts_info->use_plug_cail_flag = of_property_read_bool(np, "aw_sar,use_plug_cail");
+	p_dts_info->monitor_esd_flag = of_property_read_bool(np, "aw_sar,monitor_esd");
+
+	return 0;
+}
+
+static int32_t aw_sar_parse_dts(struct aw_sar *p_sar)
+{
+	int32_t ret;
+
+	ret = aw_sar_parse_dts_comm(p_sar->dev, p_sar->i2c->dev.of_node, &p_sar->dts_info);
+
+	//Special requirements of SAR chip
+	if (p_sar->p_sar_para->p_platform_config->p_add_parse_dts_fn != NULL)
+		ret |= p_sar->p_sar_para->p_platform_config->p_add_parse_dts_fn(p_sar);
+
+	return ret;
+}
+
+static irqreturn_t aw_sar_irq(int32_t irq, void *data)
+{
+	struct aw_sar *p_sar = (struct aw_sar *)data;
+	uint32_t irq_status;
+
+	//step1: read clear interrupt
+	if (p_sar->p_sar_para->p_platform_config->p_irq_init->rc_irq_fn != NULL)
+		irq_status = p_sar->p_sar_para->p_platform_config->p_irq_init->rc_irq_fn(p_sar->i2c);
+
+	//step2: Read the status register for status reporting
+	if (p_sar->p_sar_para->p_platform_config->p_irq_init->irq_spec_handler_fn != NULL)
+		p_sar->p_sar_para->p_platform_config->p_irq_init->irq_spec_handler_fn(irq_status,
+				p_sar);
+
+	//step3: The chip
+
+	if ((!p_sar->dts_info.monitor_esd_flag) && (p_sar->fault_flag == AW_SAR_UNHEALTHY)) {
+		p_sar->fault_flag = AW_SAR_HEALTHY;
+		disable_irq_nosync(p_sar->irq_init.to_irq);
+		p_sar->irq_init.host_irq_stat = IRQ_DISABLE;
+		//aw_sar_soft_reset(p_sar);
+		schedule_delayed_work(&p_sar->update_work, msecs_to_jiffies(500));
+	}
+
+	return IRQ_HANDLED;
+}
+
+static int32_t aw_sar_irq_init_comm(struct aw_sar *p_sar, const struct aw_sar_irq_init_t *p_irq_init)
+{
+	irq_handler_t thread_fn = p_irq_init->thread_fn;
+	int32_t ret;
+
+	snprintf(p_sar->irq_init.label, sizeof(p_sar->irq_init.label),
+				"aw_sar%u_gpio", p_sar->dts_info.sar_num);
+	snprintf(p_sar->irq_init.dev_id, sizeof(p_sar->irq_init.dev_id),
+				"aw_sar%u_irq", p_sar->dts_info.sar_num);
+
+	if (gpio_is_valid(p_sar->dts_info.irq_gpio)) {
+		p_sar->irq_init.to_irq = gpio_to_irq(p_sar->dts_info.irq_gpio);
+		ret = devm_gpio_request_one(p_sar->dev,
+						p_sar->dts_info.irq_gpio,
+						p_irq_init->flags,
+						p_sar->irq_init.label);
+		if (ret) {
+			dev_err(p_sar->dev,
+				"request irq gpio failed, ret = %d", ret);
+			return ret;
+		}
+		if (!thread_fn)
+			thread_fn = aw_sar_irq;
+		ret = devm_request_threaded_irq(p_sar->dev,
+				p_sar->irq_init.to_irq,
+				p_irq_init->handler,
+				thread_fn,
+				p_irq_init->irq_flags,
+				p_sar->irq_init.dev_id,
+				p_sar);
+		if (ret != 0) {
+			dev_err(p_sar->dev,
+					"failed to request IRQ %d: %d",
+					p_sar->irq_init.to_irq, ret);
+			return ret;
+		}
+	} else {
+		dev_err(p_sar->dev, "irq gpio invalid!");
+		return -EINVAL;
+	}
+
+	p_sar->irq_init.host_irq_stat = IRQ_DISABLE;
+	disable_irq(p_sar->irq_init.to_irq);
+
+	return 0;
+}
+
+static int32_t aw_sar_irq_init(struct aw_sar *p_sar)
+{
+
+	if (!p_sar->p_sar_para->p_platform_config->p_irq_init) {
+		dev_err(p_sar->dev, "AW_INVALID_PARA");
+		return -EINVAL;
+	}
+
+	if (p_sar->p_sar_para->p_platform_config->p_irq_init->p_irq_init_fn != NULL) {
+		dev_err(p_sar->dev, "p_irq_init_fn");
+		return p_sar->p_sar_para->p_platform_config->p_irq_init->p_irq_init_fn(p_sar);
+	}
+
+	return aw_sar_irq_init_comm(p_sar, p_sar->p_sar_para->p_platform_config->p_irq_init);
+}
+
+static void aw_sar_irq_free(struct aw_sar *p_sar)
+{
+	if ((p_sar->p_sar_para->p_platform_config != NULL) &&
+		(p_sar->p_sar_para->p_platform_config->p_irq_init != NULL) &&
+		(p_sar->p_sar_para->p_platform_config->p_irq_init->p_irq_deinit_fn != NULL)) {
+		p_sar->p_sar_para->p_platform_config->p_irq_init->p_irq_deinit_fn(p_sar);
+		dev_err(p_sar->dev, "AW_INVALID_PARA");
+		return;
+	}
+}
+
+static int32_t aw_sar_input_init_comm(struct aw_sar *p_sar)
+{
+	int32_t ret;
+	uint32_t i;
+
+	p_sar->channels_arr = devm_kzalloc(p_sar->dev,
+				sizeof(struct aw_channels_info) *
+				p_sar->p_sar_para->ch_num_max,
+				GFP_KERNEL);
+	if (!p_sar->channels_arr) {
+		dev_err(p_sar->dev, "devm_kzalloc err");
+		return -ENOMEM;
+	}
+
+	for (i = 0; i < p_sar->p_sar_para->ch_num_max; i++) {
+		snprintf(p_sar->channels_arr[i].name,
+				sizeof(p_sar->channels_arr->name),
+				"aw_sar%u_ch%ud",
+				p_sar->dts_info.sar_num, i);
+
+		p_sar->channels_arr[i].last_channel_info = 0;
+
+		if ((p_sar->dts_info.channel_use_flag >> i) & 0x01) {
+			p_sar->channels_arr[i].used = AW_TRUE;
+			p_sar->channels_arr[i].input = devm_input_allocate_device(p_sar->dev);
+			if (!p_sar->channels_arr[i].input)
+				return -EINVAL;
+			p_sar->channels_arr[i].input->name = p_sar->channels_arr[i].name;
+			input_set_abs_params(p_sar->channels_arr[i].input,
+						ABS_DISTANCE, -1, 100, 0, 0);
+			ret = input_register_device(p_sar->channels_arr[i].input);
+			if (ret) {
+				dev_err(p_sar->dev, "failed to register input device");
+				return ret;
+			}
+		} else {
+			p_sar->channels_arr[i].used = AW_FALSE;
+			p_sar->channels_arr[i].input = NULL;
+		}
+	}
+
+	return 0;
+}
+
+static int32_t aw_sar_input_init(struct aw_sar *p_sar)
+{
+	if (p_sar->p_sar_para->p_platform_config->p_input_init_fn != NULL)
+		return p_sar->p_sar_para->p_platform_config->p_input_init_fn(p_sar);
+
+	return aw_sar_input_init_comm(p_sar);
+}
+
+static void aw_sar_input_free(struct aw_sar *p_sar)
+{
+	if ((p_sar->p_sar_para->p_platform_config != NULL) &&
+		(p_sar->p_sar_para->p_platform_config->p_input_deinit_fn != NULL)) {
+		p_sar->p_sar_para->p_platform_config->p_input_deinit_fn(p_sar);
+	}
+}
+
+static int32_t aw_sar_check_init_over_irq_comm(struct aw_sar *p_sar)
+{
+	int32_t ret;
+
+	if (!p_sar->p_sar_para->p_init_over_irq)
+		return -EINVAL;
+
+	ret = aw_sar_check_init_over_irq_func(p_sar->i2c, p_sar->p_sar_para->p_init_over_irq);
+	if (ret == AW_ERR_IRQ_INIT_OVER) {
+		if (p_sar->p_sar_para->p_init_over_irq->p_get_err_type_fn != NULL) {
+			//Consider the abnormality reasonable
+			if (p_sar->p_sar_para->p_init_over_irq->p_get_err_type_fn(p_sar) == 0) {
+				p_sar->fw_fail_flag = AW_TRUE;
+				return 0;
+			}
+		}
+		return -EINVAL;
+	}
+
+	return ret;
+}
+
+//If there is no special operation on the chip, execute the common process
+int32_t aw_sar_check_init_over_irq(struct aw_sar *p_sar)
+{
+	if (!p_sar->p_sar_para->p_init_over_irq)
+		return -EINVAL;
+
+	if (p_sar->p_sar_para->p_init_over_irq->p_check_init_over_irq_fn != NULL)
+		return p_sar->p_sar_para->p_init_over_irq->p_check_init_over_irq_fn(p_sar);
+
+	return aw_sar_check_init_over_irq_comm(p_sar);
+}
+
+static int32_t aw_sar_chip_other_operation(struct aw_sar *p_sar)
+{
+	if (p_sar->p_sar_para->p_other_operation != NULL)
+		return p_sar->p_sar_para->p_other_operation(p_sar);
+
+	return 0;
+}
+
+static void aw_sar_chip_other_operation_free(struct aw_sar *p_sar)
+{
+	if (p_sar->p_sar_para->p_other_opera_free != NULL)
+		p_sar->p_sar_para->p_other_opera_free(p_sar);
+}
+
+int32_t aw_sar_soft_reset(struct aw_sar *p_sar)
+{
+	if (!p_sar->p_sar_para->p_soft_rst)
+		return -EINVAL;
+
+	//If a private interface is defined, the private interface is used
+	if (p_sar->p_sar_para->p_soft_rst->p_soft_reset_fn != NULL)
+		return p_sar->p_sar_para->p_soft_rst->p_soft_reset_fn(p_sar);
+
+	return aw_sar_soft_reset_func(p_sar->i2c, p_sar->p_sar_para->p_soft_rst);
+}
+
+static int32_t aw_sar_check_chipid(struct aw_sar *p_sar)
+{
+	if (!p_sar->p_sar_para)
+		return -EINVAL;
+
+	if (p_sar->p_sar_para->p_check_chipid != NULL) {
+		if (p_sar->p_sar_para->p_check_chipid->p_check_chipid_fn != NULL)
+			return p_sar->p_sar_para->p_check_chipid->p_check_chipid_fn(p_sar);
+	}
+
+	return -EINVAL;
+}
+
+int32_t aw_sar_load_def_reg_bin(struct aw_sar *p_sar)
+{
+	if ((!p_sar->p_sar_para->p_reg_bin) ||
+		(!p_sar->p_sar_para->p_reg_bin->bin_name)) {
+		dev_err(p_sar->dev, "p_reg_bin is NULL or bin_name is NULL error");
+		p_sar->ret_val = AW_BIN_PARA_INVALID;
+		return -EINVAL;
+	}
+
+	snprintf(p_sar->load_bin.bin_name, sizeof(p_sar->load_bin.bin_name),
+			"%s_%u.bin", p_sar->p_sar_para->p_reg_bin->bin_name,
+			p_sar->dts_info.sar_num);
+
+	p_sar->load_bin.bin_opera_func = p_sar->p_sar_para->p_reg_bin->bin_opera_func;
+
+	return aw_sar_load_bin_comm(p_sar);
+}
+
+static int32_t aw_sar_para_loaded(struct aw_sar *p_sar)
+{
+	if (!p_sar->p_sar_para->p_reg_arr)
+		return -EINVAL;
+
+	aw_sar_para_loaded_func(p_sar->i2c, p_sar->p_sar_para->p_reg_arr);
+
+	return 0;
+}
+
+static int32_t aw_sar_reg_update_boot_work(struct aw_sar *p_sar)
+{
+	if ((!p_sar->p_sar_para->p_boot_bin) || (!p_sar->p_sar_para->p_boot_bin->bin_name))
+		return -EINVAL;
+
+	snprintf(p_sar->load_bin.bin_name, sizeof(p_sar->load_bin.bin_name),
+			"%s_%u.bin", p_sar->p_sar_para->p_boot_bin->bin_name,
+			p_sar->dts_info.sar_num);
+
+	p_sar->load_bin.bin_opera_func = p_sar->p_sar_para->p_boot_bin->bin_opera_func;
+
+	return aw_sar_load_bin_comm(p_sar);
+}
+
+static int32_t aw_sar_update_fw_para(struct aw_sar *p_sar, const struct aw_sar_load_bin_t *p_bin)
+{
+	if ((!p_bin) || (!p_bin->bin_name))
+		return -EINVAL;
+
+	p_sar->load_bin.bin_opera_func = p_bin->bin_opera_func;
+	p_sar->load_bin.bin_load_fail_opera_func = p_bin->bin_load_fail_opera;
+
+	snprintf(p_sar->load_bin.bin_name, sizeof(p_sar->load_bin.bin_name),
+			"%s_%u.bin", p_bin->bin_name, p_sar->dts_info.sar_num);
+
+	return 0;
+}
+
+int32_t aw_sar_update_fw(struct aw_sar *p_sar)
+{
+	if (aw_sar_update_fw_para(p_sar, p_sar->p_sar_para->p_fw_bin) != 0)
+		return -EINVAL;
+
+	return aw_sar_load_bin_comm(p_sar);
+}
+
+static int32_t aw_sar_node_prox_update_fw(struct aw_sar *p_sar)
+{
+	if (aw_sar_update_fw_para(p_sar, p_sar->p_sar_para->p_prox_fw) != 0)
+		return -EINVAL;
+
+	return aw_sar_load_bin_comm(p_sar);
+}
+
+static int32_t aw_sar_node_reg_update_fw(struct aw_sar *p_sar)
+{
+	if (aw_sar_update_fw_para(p_sar, p_sar->p_sar_para->p_reg_fw))
+		return -EINVAL;
+
+	return aw_sar_load_bin_comm(p_sar);
+}
+
+static int32_t aw_sar_awrw_data_analysis(struct aw_sar *p_sar, const char *buf, uint8_t len)
+{
+	uint32_t theory_len = len * AW_SAR_AWRW_DATA_WIDTH + AW_SAR_AWRW_OffSET;
+	uint32_t actual_len = strlen(buf);
+	uint8_t data_temp[2] = { 0 };
+	uint32_t tranfar_data_temp;
+	uint8_t index = 0;
+	uint32_t i;
+
+	if (theory_len != actual_len) {
+		dev_err(p_sar->dev, "error theory_len = %d actual_len = %d",
+				theory_len, actual_len);
+		return -EINVAL;
+	}
+
+	for (i = 0; i < len * AW_SAR_AWRW_DATA_WIDTH; i += AW_SAR_AWRW_DATA_WIDTH) {
+		data_temp[0] = buf[AW_SAR_AWRW_OffSET + i + AW_DATA_OffSET_2];
+		data_temp[1] = buf[AW_SAR_AWRW_OffSET + i + AW_DATA_OffSET_3];
+
+		if (sscanf(data_temp, "%02x", &tranfar_data_temp) == 1)
+			p_sar->awrw_info.p_i2c_tranfar_data[index] = (uint8_t)tranfar_data_temp;
+		index++;
+	}
+
+	return 0;
+}
+
+static int32_t aw_sar_awrw_write(struct aw_sar *p_sar, const char *buf)
+{
+	int32_t ret;
+
+	ret = aw_sar_awrw_data_analysis(p_sar, buf, p_sar->awrw_info.i2c_tranfar_data_len);
+	if (ret == 0)
+		aw_sar_i2c_write_seq(p_sar->i2c, p_sar->awrw_info.p_i2c_tranfar_data,
+					p_sar->awrw_info.i2c_tranfar_data_len);
+
+	return ret;
+}
+
+static int32_t aw_sar_awrw_read(struct aw_sar *p_sar, const char *buf)
+{
+	int32_t ret = 0;
+	uint8_t *p_buf = p_sar->awrw_info.p_i2c_tranfar_data + p_sar->awrw_info.addr_len;
+	uint32_t len = (uint16_t)(p_sar->awrw_info.data_len * p_sar->awrw_info.reg_num);
+
+	ret = aw_sar_awrw_data_analysis(p_sar, buf, p_sar->awrw_info.addr_len);
+	if (ret == 0) {
+		ret = aw_sar_i2c_read_seq(p_sar->i2c,
+				p_sar->awrw_info.p_i2c_tranfar_data,
+				p_sar->awrw_info.addr_len,
+				p_sar->awrw_info.p_i2c_tranfar_data + p_sar->awrw_info.addr_len,
+				(uint16_t)(p_sar->awrw_info.data_len * p_sar->awrw_info.reg_num));
+		if (ret != 0)
+			memset(p_buf, 0xff, len);
+	}
+
+	return ret;
+}
+
+static int32_t aw_sar_awrw_get_func(struct aw_sar *p_sar, char *buf)
+{
+	uint32_t len = 0;
+	uint32_t i;
+
+	if (!p_sar->awrw_info.p_i2c_tranfar_data) {
+		dev_err(p_sar->dev, "p_i2c_tranfar_data is NULL");
+		return len;
+	}
+
+	if (p_sar->awrw_info.rw_flag == AW_SAR_PACKAGE_RD) {
+		for (i = 0; i < p_sar->awrw_info.i2c_tranfar_data_len; i++) {
+			len += snprintf(buf + len, PAGE_SIZE - len, "0x%02x,",
+				p_sar->awrw_info.p_i2c_tranfar_data[i]);
+		}
+	} else {
+		for (i = 0; i < (p_sar->awrw_info.data_len) * (p_sar->awrw_info.reg_num); i++) {
+			len += snprintf(buf + len, PAGE_SIZE - len, "0x%02x,",
+				p_sar->awrw_info.p_i2c_tranfar_data[p_sar->awrw_info.addr_len + i]);
+		}
+	}
+	snprintf(buf + len - 1, PAGE_SIZE - len, "\n");
+
+	devm_kfree(p_sar->dev, p_sar->awrw_info.p_i2c_tranfar_data);
+	p_sar->awrw_info.p_i2c_tranfar_data = NULL;
+
+	return len;
+}
+
+//Function: continuous read register interface
+static ssize_t awrw_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+	ssize_t ret;
+
+	mutex_lock(&aw_sar_lock);
+	if ((p_sar->p_sar_para->p_aw_sar_awrw != NULL) &&
+		(p_sar->p_sar_para->p_aw_sar_awrw->p_get_awrw_node_fn != NULL)) {
+		ret = (ssize_t)p_sar->p_sar_para->p_aw_sar_awrw->p_get_awrw_node_fn(p_sar, buf);
+		mutex_unlock(&aw_sar_lock);
+		return ret;
+	}
+
+	ret = (ssize_t)aw_sar_awrw_get_func(p_sar, buf);
+
+	mutex_unlock(&aw_sar_lock);
+
+	return ret;
+}
+
+static int32_t aw_sar_awrw_handle(struct aw_sar *p_sar, const char *buf)
+{
+	int32_t ret;
+
+	p_sar->awrw_info.i2c_tranfar_data_len = p_sar->awrw_info.addr_len +
+						p_sar->awrw_info.data_len *
+						p_sar->awrw_info.reg_num;
+
+	if (p_sar->awrw_info.p_i2c_tranfar_data != NULL) {
+		devm_kfree(p_sar->dev, p_sar->awrw_info.p_i2c_tranfar_data);
+		p_sar->awrw_info.p_i2c_tranfar_data = NULL;
+	}
+
+	p_sar->awrw_info.p_i2c_tranfar_data = devm_kzalloc(p_sar->dev,
+			p_sar->awrw_info.i2c_tranfar_data_len, GFP_KERNEL);
+	if (!p_sar->awrw_info.p_i2c_tranfar_data)
+		return -ENOMEM;
+
+	if (p_sar->awrw_info.rw_flag == AW_SAR_I2C_WR) {
+		ret = aw_sar_awrw_write(p_sar, buf);
+		if (ret != 0)
+			dev_err(p_sar->dev, "awrw_write error");
+		if (p_sar->awrw_info.p_i2c_tranfar_data != NULL) {
+			devm_kfree(p_sar->dev, p_sar->awrw_info.p_i2c_tranfar_data);
+			p_sar->awrw_info.p_i2c_tranfar_data = NULL;
+		}
+	} else if (p_sar->awrw_info.rw_flag == AW_SAR_I2C_RD) {
+		ret = aw_sar_awrw_read(p_sar, buf);
+		if (ret != 0)
+			dev_err(p_sar->dev, "awrw_read error");
+	} else {
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+static int32_t aw_sar_awrw_set_func(struct aw_sar *p_sar, const char *buf)
+{
+	uint32_t rw_flag;
+	uint32_t addr_bytes;
+	uint32_t data_bytes;
+	uint32_t package_nums;
+	uint32_t addr_tmp;
+	uint32_t buf_index0;
+	uint32_t buf_index1;
+	uint32_t r_buf_len = 0;
+	uint32_t tr_offset = 0;
+	uint8_t addr[4] = { 0 };
+	uint32_t theory_len;
+	uint32_t actual_len;
+	uint32_t reg_num;
+	uint32_t i;
+	uint32_t j;
+
+	//step1: Parse frame header
+	if (sscanf(buf, "0x%02x 0x%02x 0x%02x ", &rw_flag, &addr_bytes, &data_bytes) != 3) {
+		dev_err(p_sar->dev, "sscanf0 parse error!");
+		return -EINVAL;
+	}
+	p_sar->awrw_info.rw_flag = (uint8_t)rw_flag;
+	p_sar->awrw_info.addr_len = (uint8_t)addr_bytes;
+	p_sar->awrw_info.data_len = (uint8_t)data_bytes;
+
+	if (addr_bytes > 4) {
+		dev_err(p_sar->dev, "para error!");
+		return -EINVAL;
+	}
+
+	if ((rw_flag == AW_SAR_I2C_WR) || (rw_flag == AW_SAR_I2C_RD)) {
+		if (sscanf(buf + AW_SAR_OFFSET_LEN, "0x%02x ", &reg_num) != 1) {
+			dev_err(p_sar->dev, "sscanf1 parse error!");
+			return -EINVAL;
+		}
+		p_sar->awrw_info.reg_num = (uint8_t)reg_num;
+		aw_sar_awrw_handle(p_sar, buf);
+	} else if (rw_flag == AW_SAR_PACKAGE_RD) {
+		//step2: Get number of packages
+		if (sscanf(buf + AW_SAR_OFFSET_LEN, "0x%02x ", &package_nums) != 1) {
+			dev_err(p_sar->dev, "sscanf2 parse error!");
+			return -EINVAL;
+		}
+		theory_len = AW_SAR_OFFSET_LEN + AW_SAR_AWRW_DATA_WIDTH +
+				package_nums * (AW_SAR_AWRW_DATA_WIDTH +
+				AW_SAR_AWRW_DATA_WIDTH * addr_bytes);
+		actual_len = strlen(buf);
+		if (theory_len != actual_len) {
+			dev_err(p_sar->dev, "theory_len:%d, actual_len:%d error!",
+					theory_len, actual_len);
+			return -EINVAL;
+		}
+
+		//step3: Get the size of read data and apply for space
+		for (i = 0; i < package_nums; i++) {
+			buf_index0 = AW_SAR_OFFSET_LEN + AW_SAR_AWRW_DATA_WIDTH +
+				(AW_SAR_AWRW_DATA_WIDTH * addr_bytes +
+				 AW_SAR_AWRW_DATA_WIDTH) * i;
+			if (sscanf(buf + buf_index0, "0x%02x", &reg_num) != 1) {
+				dev_err(p_sar->dev, "sscanf3 parse error!");
+				return -EINVAL;
+			}
+			r_buf_len += reg_num * data_bytes;
+		}
+
+		p_sar->awrw_info.i2c_tranfar_data_len = r_buf_len;
+
+		if (p_sar->awrw_info.p_i2c_tranfar_data != NULL) {
+			devm_kfree(p_sar->dev, p_sar->awrw_info.p_i2c_tranfar_data);
+			p_sar->awrw_info.p_i2c_tranfar_data = NULL;
+		}
+		p_sar->awrw_info.p_i2c_tranfar_data = devm_kzalloc(p_sar->dev,
+								r_buf_len, GFP_KERNEL);
+		if (!p_sar->awrw_info.p_i2c_tranfar_data)
+			return -ENOMEM;
+
+		//step3: Resolve register address and read data in packets
+		for (i = 0; i < package_nums; i++) {
+			buf_index0 = AW_SAR_OFFSET_LEN + AW_SAR_AWRW_DATA_WIDTH +
+				(AW_SAR_AWRW_DATA_WIDTH * addr_bytes + AW_SAR_AWRW_DATA_WIDTH) * i;
+			if (sscanf(buf + buf_index0, "0x%02x", &reg_num) != 1) {
+				dev_err(p_sar->dev, "sscanf4 parse error!");
+				return -EINVAL;
+			}
+
+			for (j = 0; j < addr_bytes; j += 1) {
+				buf_index1 = buf_index0 + AW_SAR_AWRW_DATA_WIDTH +
+					(j * AW_SAR_AWRW_DATA_WIDTH);
+				if (sscanf(buf + buf_index1, "0x%02x", &addr_tmp) == 1) {
+					addr[j] = (uint8_t)addr_tmp;
+				} else {
+					dev_err(p_sar->dev, "sscanf5 parse error!");
+					return -EINVAL;
+				}
+			}
+			aw_sar_i2c_read_seq(p_sar->i2c,
+					addr,
+					addr_bytes,
+					p_sar->awrw_info.p_i2c_tranfar_data + tr_offset,
+					(uint16_t)(data_bytes * reg_num));
+			tr_offset += data_bytes * reg_num;
+		}
+	}
+
+	return 0;
+}
+
+//Function: continuous write register interface
+static ssize_t
+awrw_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+
+	mutex_lock(&aw_sar_lock);
+
+	if ((p_sar->p_sar_para->p_aw_sar_awrw != NULL) &&
+		(p_sar->p_sar_para->p_aw_sar_awrw->p_set_awrw_node_fn != NULL)) {
+		p_sar->p_sar_para->p_aw_sar_awrw->p_set_awrw_node_fn(p_sar, buf, count);
+		mutex_unlock(&aw_sar_lock);
+		return count;
+	}
+
+	aw_sar_awrw_set_func(p_sar, buf);
+
+	mutex_unlock(&aw_sar_lock);
+
+	return count;
+}
+//Print all readable register values
+static ssize_t reg_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+	uint8_t reg_rd_access;
+	uint32_t reg_data;
+	ssize_t len = 0;
+	int32_t ret;
+	uint16_t i;
+
+	if (!p_sar->p_sar_para->p_reg_list)
+		return len;
+
+	reg_rd_access = p_sar->p_sar_para->p_reg_list->reg_rd_access;
+
+	for (i = 0; i < p_sar->p_sar_para->p_reg_list->reg_num; i++) {
+		if (p_sar->p_sar_para->p_reg_list->reg_perm[i].rw & reg_rd_access) {
+			ret = aw_sar_i2c_read(p_sar->i2c,
+					p_sar->p_sar_para->p_reg_list->reg_perm[i].reg, &reg_data);
+			if (ret < 0)
+				len += snprintf(buf + len, PAGE_SIZE - len,
+						"i2c read error ret = %d\n", ret);
+			len += snprintf(buf + len, PAGE_SIZE - len,
+						"%x,%x\n",
+						p_sar->p_sar_para->p_reg_list->reg_perm[i].reg,
+						reg_data);
+		}
+	}
+
+	return len;
+}
+
+//Write register interface with write permission
+static ssize_t
+reg_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+	uint32_t databuf[2] = { 0, 0 };
+	uint8_t reg_wd_access;
+	uint16_t i;
+
+	if (!p_sar->p_sar_para->p_reg_list) {
+		dev_err(p_sar->dev, "AW_INVALID_PARA");
+		return count;
+	}
+
+	reg_wd_access = p_sar->p_sar_para->p_reg_list->reg_wd_access;
+
+	if (sscanf(buf, "%x %x", &databuf[0], &databuf[1]) != 2)
+		return count;
+
+	for (i = 0; i < p_sar->p_sar_para->p_reg_list->reg_num; i++) {
+		if ((uint16_t)databuf[0] == p_sar->p_sar_para->p_reg_list->reg_perm[i].reg) {
+			if (p_sar->p_sar_para->p_reg_list->reg_perm[i].rw & reg_wd_access) {
+				aw_sar_i2c_write(p_sar->i2c,
+					(uint16_t)databuf[0], (uint32_t)databuf[1]);
+			}
+			break;
+		}
+	}
+
+	return count;
+}
+
+//set chip Soft reset
+static ssize_t
+soft_rst_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+	uint32_t flag;
+
+	if (kstrtouint(buf, 0, &flag) != 0) {
+		dev_err(p_sar->dev, "kstrtouint parse err");
+		return count;
+	}
+
+	if (flag == AW_TRUE)
+		aw_sar_soft_reset(p_sar);
+
+	return count;
+}
+
+static int32_t aw_sar_aot(struct aw_sar *p_sar)
+{
+	if (!p_sar->p_sar_para->p_aot)
+		return -EINVAL;
+
+	if (p_sar->p_sar_para->p_aot->p_set_aot_node_fn != NULL)
+		return p_sar->p_sar_para->p_aot->p_set_aot_node_fn(p_sar);
+
+	return aw_sar_i2c_write_bits(p_sar->i2c, p_sar->p_sar_para->p_aot->aot_reg,
+					p_sar->p_sar_para->p_aot->aot_mask,
+					p_sar->p_sar_para->p_aot->aot_flag);
+}
+
+//Perform Auto-Offset-Tuning (AOT)
+static ssize_t
+aot_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+	uint32_t cali_flag;
+
+	if (kstrtouint(buf, 0, &cali_flag) != 0)
+		return count;
+
+	if (cali_flag == AW_TRUE)
+		aw_sar_aot(p_sar);
+	else
+		dev_err(p_sar->dev, "fail to set aot cali");
+
+	return count;
+}
+
+//update Register configuration and set the chip active mode
+int32_t aw_sar_update_reg_set_func(struct aw_sar *p_sar)
+{
+	aw_sar_load_def_reg_bin(p_sar);
+	aw_sar_mode_set(p_sar, p_sar->p_sar_para->p_chip_mode->active);
+
+	return 0;
+}
+
+//Update register configuration
+static ssize_t
+update_reg_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+	uint32_t flag;
+
+	if (kstrtouint(buf, 0, &flag) != 0) {
+		dev_err(p_sar->dev, "kstrtouint parse error");
+		return count;
+	}
+
+	if (flag == AW_TRUE) {
+		mutex_lock(&aw_sar_lock);
+		aw_sar_soft_reset(p_sar);
+		aw_sar_update_reg_set_func(p_sar);
+		mutex_unlock(&aw_sar_lock);
+	}
+
+	return count;
+}
+
+//get chip diff val
+static ssize_t aw_sar_get_diff(struct aw_sar *p_sar, char *buf)
+{
+	const struct aw_sar_diff_t *diff = p_sar->p_sar_para->p_diff;
+	int32_t diff_val;
+	ssize_t len = 0;
+	uint32_t data;
+	int32_t ret;
+	uint32_t i;
+
+	if (!p_sar->p_sar_para->p_diff)
+		return -EINVAL;
+
+	//If a private interface is defined, the private interface is used
+	if (p_sar->p_sar_para->p_diff->p_get_diff_node_fn != NULL)
+		return p_sar->p_sar_para->p_diff->p_get_diff_node_fn(p_sar, buf);
+
+	for (i = 0; i < p_sar->p_sar_para->ch_num_max; i++) {
+		ret = aw_sar_i2c_read(p_sar->i2c, diff->diff0_reg + i * diff->diff_step, &data);
+		if (ret != 0) {
+			dev_err(p_sar->dev, "read diff err: %d", ret);
+			return ret;
+		}
+		diff_val = (int32_t)data / (int32_t)diff->rm_float;
+		len += snprintf(buf + len, PAGE_SIZE - len, "DIFF_CH%u = %d\n", i, diff_val);
+	}
+
+	return len;
+}
+
+
+//Print diff values of all channels of the chip.
+static ssize_t diff_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+
+	return aw_sar_get_diff(p_sar, buf);
+}
+
+void aw_sar_mode_set(struct aw_sar *p_sar, uint8_t curr_mode)
+{
+	struct aw_sar_mode_set_t mode_set_para;
+
+	if (!p_sar->p_sar_para->p_mode)
+		return;
+
+	//If a private interface is defined, the private interface is used
+	if (p_sar->p_sar_para->p_mode->p_set_mode_node_fn != NULL) {
+		p_sar->p_sar_para->p_mode->p_set_mode_node_fn(p_sar, curr_mode);
+		return;
+	}
+
+	mode_set_para.chip_id = p_sar->chip_type;
+	mode_set_para.chip_mode.curr_mode = curr_mode;
+	mode_set_para.chip_mode.last_mode = p_sar->last_mode;
+
+	aw_sar_mode_set_func(p_sar->i2c, p_sar->irq_init.to_irq, &mode_set_para,
+		p_sar->p_sar_para->p_mode->mode_set_arr,
+		p_sar->p_sar_para->p_mode->mode_set_arr_len);
+	p_sar->last_mode = curr_mode;
+}
+
+//Set the chip to enter different modes
+static ssize_t mode_operation_store(struct device *dev, struct device_attribute *attr,
+						const char *buf, size_t count)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+	uint32_t mode;
+
+	if (kstrtouint(buf, 0, &mode) != 0) {
+		dev_err(p_sar->dev, "kstrtouint parse err");
+		return count;
+	}
+	aw_sar_mode_set(p_sar, mode);
+
+	return count;
+}
+
+//Get the current mode of the chip
+static ssize_t mode_operation_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+	ssize_t len = 0;
+
+	if (!p_sar->p_sar_para->p_mode)
+		return len;
+
+	if (p_sar->p_sar_para->p_mode->p_get_mode_node_fn != NULL)
+		len = p_sar->p_sar_para->p_mode->p_get_mode_node_fn(p_sar, buf);
+
+	return len;
+}
+
+//Print information related information
+static ssize_t chip_info_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+	ssize_t len = 0;
+
+	len += snprintf(buf + len, PAGE_SIZE - len, "reg_load_state: %d\n", p_sar->ret_val);
+
+	if ((p_sar->p_sar_para->p_get_chip_info != NULL) &&
+		(p_sar->p_sar_para->p_get_chip_info->p_get_chip_info_node_fn != NULL)) {
+		p_sar->p_sar_para->p_get_chip_info->p_get_chip_info_node_fn(p_sar, buf, &len);
+	}
+
+	return len;
+}
+
+static ssize_t offset_show(struct device *dev, struct device_attribute *attr, char *buf)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+	ssize_t len = 0;
+
+	if ((p_sar->p_sar_para->p_offset != NULL) &&
+		(p_sar->p_sar_para->p_offset->p_get_offset_node_fn != NULL))
+		len = (ssize_t)p_sar->p_sar_para->p_offset->p_get_offset_node_fn(p_sar, buf);
+
+	return len;
+}
+
+static DEVICE_ATTR_RW(awrw);
+static DEVICE_ATTR_RW(reg);
+static DEVICE_ATTR_WO(soft_rst);
+static DEVICE_ATTR_WO(aot);
+static DEVICE_ATTR_WO(update_reg);
+static DEVICE_ATTR_RO(diff);
+static DEVICE_ATTR_RW(mode_operation);
+static DEVICE_ATTR_RO(chip_info);
+static DEVICE_ATTR_RO(offset);
+
+static struct attribute *aw_sar_attributes[] = {
+	&dev_attr_awrw.attr,
+	&dev_attr_reg.attr,
+	&dev_attr_soft_rst.attr,
+	&dev_attr_aot.attr,
+	&dev_attr_update_reg.attr,
+	&dev_attr_diff.attr,
+	&dev_attr_mode_operation.attr,
+	&dev_attr_chip_info.attr,
+	&dev_attr_offset.attr,
+	NULL
+};
+
+static const struct attribute_group aw_sar_attribute_group = {
+	.attrs = aw_sar_attributes,
+};
+
+//firmware upgrade through write register mode, and the operation is supported by flash chip
+static ssize_t prot_update_fw_store(struct device *dev,
+						struct device_attribute *attr,
+						const char *buf, size_t count)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+
+
+	mutex_lock(&aw_sar_lock);
+	aw_sar_disable_irq(p_sar);
+
+	p_sar->prot_update_state = aw_sar_node_prox_update_fw(p_sar);
+
+	aw_sar_enable_irq(p_sar);
+	mutex_unlock(&aw_sar_lock);
+
+	return count;
+}
+
+//firmware upgrade throughr Write register mode,and the operation is supported by flash chip
+static ssize_t reg_update_fw_store(struct device *dev,
+						struct device_attribute *attr,
+						const char *buf, size_t count)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+
+	mutex_lock(&aw_sar_lock);
+	aw_sar_disable_irq(p_sar);
+
+	aw_sar_node_reg_update_fw(p_sar);
+
+	aw_sar_enable_irq(p_sar);
+	mutex_unlock(&aw_sar_lock);
+
+	return count;
+}
+
+//boot upgrade throughr Write register mode,and the operation is supported by flash chip
+static ssize_t reg_update_boot_store(struct device *dev,
+						struct device_attribute *attr,
+						const char *buf, size_t count)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+
+	if (!p_sar->p_sar_para->p_boot_bin)
+		return count;
+
+	mutex_lock(&aw_sar_lock);
+	aw_sar_disable_irq(p_sar);
+
+	aw_sar_reg_update_boot_work(p_sar);
+
+	aw_sar_enable_irq(p_sar);
+	mutex_unlock(&aw_sar_lock);
+
+	return count;
+}
+
+//Print the protocol upgrade status. 0 is success, Not 0 is failure
+//Print the current firmware version number
+static ssize_t prot_update_fw_show(struct device *dev,
+				struct device_attribute *attr, char *buf)
+{
+	struct aw_sar *p_sar = dev_get_drvdata(dev);
+	ssize_t len = 0;
+
+	len += snprintf(buf + len, PAGE_SIZE - len,
+		"protocol update state:%s!\n",
+		(p_sar->prot_update_state == 0) ? "ok" : "error");
+	if ((p_sar->p_sar_para->p_prox_fw != NULL) &&
+		(p_sar->p_sar_para->p_prox_fw->p_get_prot_update_fw_node_fn != NULL))
+		p_sar->p_sar_para->p_prox_fw->p_get_prot_update_fw_node_fn(p_sar, buf, &len);
+
+	return len;
+}
+
+static DEVICE_ATTR_RW(prot_update_fw);
+static DEVICE_ATTR_WO(reg_update_fw);
+static DEVICE_ATTR_WO(reg_update_boot);
+
+static struct attribute *aw_sar_update_attributes[] = {
+	&dev_attr_prot_update_fw.attr,
+	&dev_attr_reg_update_fw.attr,
+	&dev_attr_reg_update_boot.attr,
+	NULL
+};
+
+static const struct attribute_group aw_sar_update_attribute_group = {
+	.attrs = aw_sar_update_attributes,
+};
+
+static void aw_sar_update_work(struct work_struct *work)
+{
+	struct aw_sar *p_sar = container_of(work, struct aw_sar, update_work.work);
+	int32_t ret;
+
+	mutex_lock(&aw_sar_lock);
+
+	if (p_sar->dts_info.update_fw_flag == true) {
+		ret = aw_sar_update_fw(p_sar);
+		if (ret != 0) {
+			dev_err(p_sar->dev, "protocol upgrade firmware error!");
+			p_sar->ret_val = AW_PROT_UPDATE_ERR;
+		}
+	}
+
+	//2.Parse the bin file and load the register configuration
+	ret = aw_sar_load_def_reg_bin(p_sar);
+	if (ret != 0) {
+		p_sar->ret_val = AW_REG_LOAD_ERR;
+		dev_err(p_sar->dev, "reg_bin load err!");
+		aw_sar_para_loaded(p_sar);
+	}
+
+	//3.active chip
+	aw_sar_mode_set(p_sar, p_sar->p_sar_para->p_chip_mode->init_mode);
+	if (p_sar->irq_init.host_irq_stat == IRQ_DISABLE) {
+		enable_irq(p_sar->irq_init.to_irq);
+		p_sar->irq_init.host_irq_stat = IRQ_ENABLE;
+	}
+	p_sar->driver_code_initover_flag = 1;
+	mutex_unlock(&aw_sar_lock);
+}
+
+static void aw_sar_update(struct aw_sar *p_sar)
+{
+	if (!p_sar->p_sar_para->p_reg_bin)
+		return;
+
+	if (p_sar->p_sar_para->p_reg_bin->p_update_fn != NULL)
+		p_sar->p_sar_para->p_reg_bin->p_update_fn(p_sar);
+
+	if (p_sar->driver_code_initover_flag) {
+		schedule_delayed_work(&p_sar->update_work, msecs_to_jiffies(0));
+	} else {
+		INIT_DELAYED_WORK(&p_sar->update_work, aw_sar_update_work);
+		schedule_delayed_work(&p_sar->update_work,
+				msecs_to_jiffies(AW_POWER_ON_SYSFS_DELAY_MS));
+	}
+}
+
+static int32_t aw_sar_create_node(struct aw_sar *p_sar)
+{
+	int32_t ret;
+
+	i2c_set_clientdata(p_sar->i2c, p_sar);
+
+	ret = sysfs_create_group(&p_sar->i2c->dev.kobj, &aw_sar_attribute_group);
+
+	if (p_sar->dts_info.update_fw_flag == true)
+		ret |= sysfs_create_group(&p_sar->i2c->dev.kobj, &aw_sar_update_attribute_group);
+
+	//Special requirements of SAR chip
+	if (p_sar->p_sar_para->p_platform_config->p_add_node_create_fn != NULL)
+		ret |= p_sar->p_sar_para->p_platform_config->p_add_node_create_fn(p_sar);
+
+	return ret;
+}
+
+static void aw_sar_node_free(struct aw_sar *p_sar)
+{
+	sysfs_remove_group(&p_sar->i2c->dev.kobj, &aw_sar_attribute_group);
+
+	if (p_sar->dts_info.update_fw_flag == true)
+		sysfs_remove_group(&p_sar->i2c->dev.kobj, &aw_sar_update_attribute_group);
+
+	//Special requirements of SAR chip
+	if ((p_sar->p_sar_para->p_platform_config != NULL) &&
+		(p_sar->p_sar_para->p_platform_config->p_add_node_free_fn != NULL))
+		p_sar->p_sar_para->p_platform_config->p_add_node_free_fn(p_sar);
+}
+
+//The interrupt pin is set to internal pull-up start
+static void aw_sar_int_output(struct aw_sar *p_sar, int32_t level)
+{
+	if (level == 0) {
+		if (p_sar->pinctrl.pinctrl)
+			pinctrl_select_state(p_sar->pinctrl.pinctrl, p_sar->pinctrl.int_out_low);
+		else
+			dev_err(p_sar->dev, "Failed set int pin output low\n");
+	} else if (level == 1) {
+		if (p_sar->pinctrl.pinctrl)
+			pinctrl_select_state(p_sar->pinctrl.pinctrl, p_sar->pinctrl.int_out_high);
+		else
+			dev_err(p_sar->dev, "Failed set int pin output high\n");
+	}
+}
+
+static int32_t aw_sar_pinctrl_init(struct aw_sar *p_sar)
+{
+	struct aw_sar_pinctrl *pinctrl = &p_sar->pinctrl;
+	uint8_t pin_default_name[50] = { 0 };
+	uint8_t pin_output_low_name[50] = { 0 };
+	uint8_t pin_output_high_name[50] = { 0 };
+
+	pinctrl->pinctrl = devm_pinctrl_get(p_sar->dev);
+	if (IS_ERR_OR_NULL(pinctrl->pinctrl)) {
+		dev_err(p_sar->dev, "No pinctrl found\n");
+		pinctrl->pinctrl = NULL;
+		return -EINVAL;
+	}
+
+	snprintf(pin_default_name, sizeof(pin_default_name),
+					"aw_default_sar%u", p_sar->dts_info.sar_num);
+	pinctrl->default_sta = pinctrl_lookup_state(pinctrl->pinctrl, pin_default_name);
+	if (IS_ERR_OR_NULL(pinctrl->default_sta)) {
+		dev_err(p_sar->dev, "Failed get pinctrl state:default state");
+		goto exit_pinctrl_init;
+	}
+
+	snprintf(pin_output_high_name, sizeof(pin_output_high_name),
+				"aw_int_output_high_sar%u", p_sar->dts_info.sar_num);
+	pinctrl->int_out_high = pinctrl_lookup_state(pinctrl->pinctrl, pin_output_high_name);
+	if (IS_ERR_OR_NULL(pinctrl->int_out_high)) {
+		dev_err(p_sar->dev, "Failed get pinctrl state:output_high");
+		goto exit_pinctrl_init;
+	}
+
+	snprintf(pin_output_low_name, sizeof(pin_output_low_name),
+				"aw_int_output_low_sar%u", p_sar->dts_info.sar_num);
+	pinctrl->int_out_low = pinctrl_lookup_state(pinctrl->pinctrl, pin_output_low_name);
+	if (IS_ERR_OR_NULL(pinctrl->int_out_low)) {
+		dev_err(p_sar->dev, "Failed get pinctrl state:output_low");
+		goto exit_pinctrl_init;
+	}
+
+	return 0;
+
+exit_pinctrl_init:
+	devm_pinctrl_put(pinctrl->pinctrl);
+	pinctrl->pinctrl = NULL;
+
+	return -EINVAL;
+}
+
+static void aw_sar_pinctrl_deinit(struct aw_sar *p_sar)
+{
+	if (p_sar->pinctrl.pinctrl)
+		devm_pinctrl_put(p_sar->pinctrl.pinctrl);
+}
+//The interrupt pin is set to internal pull-up end
+
+//AW_SAR_REGULATOR_POWER_ON start
+static int32_t aw_sar_regulator_power_init(struct aw_sar *p_sar)
+{
+	uint8_t vcc_name[20] = { 0 };
+	int32_t rc;
+
+	snprintf(vcc_name, sizeof(vcc_name), "vcc%u", p_sar->dts_info.sar_num);
+	p_sar->vcc = regulator_get(p_sar->dev, vcc_name);
+	if (IS_ERR(p_sar->vcc)) {
+		rc = PTR_ERR(p_sar->vcc);
+		dev_err(p_sar->dev, "regulator get failed vcc rc = %d", rc);
+		return rc;
+	}
+
+	if (regulator_count_voltages(p_sar->vcc) > 0) {
+		rc = regulator_set_voltage(p_sar->vcc, AW_SAR_VCC_MIN_UV, AW_SAR_VCC_MAX_UV);
+		if (rc) {
+			dev_err(p_sar->dev, "regulator set vol failed rc = %d", rc);
+			goto reg_vcc_put;
+		}
+	}
+
+	return 0;
+
+reg_vcc_put:
+	regulator_put(p_sar->vcc);
+	return rc;
+}
+
+static void aw_sar_power_deinit(struct aw_sar *p_sar)
+{
+	if (p_sar->power_enable) {
+		//Turn off the power output. However,
+		//it may not be turned off immediately
+		//There are scenes where power sharing can exist
+		regulator_disable(p_sar->vcc);
+		regulator_put(p_sar->vcc);
+	}
+}
+
+static void aw_sar_power_enable(struct aw_sar *p_sar, bool on)
+{
+	int32_t rc;
+
+	if (on) {
+		rc = regulator_enable(p_sar->vcc);
+		if (rc) {
+			dev_err(p_sar->dev, "regulator_enable vol failed rc = %d", rc);
+		} else {
+			p_sar->power_enable = AW_TRUE;
+			msleep(20);
+		}
+	} else {
+		rc = regulator_disable(p_sar->vcc);
+		if (rc)
+			dev_err(p_sar->dev, "regulator_disable vol failed rc = %d", rc);
+		else
+			p_sar->power_enable = AW_FALSE;
+	}
+}
+
+static int32_t regulator_is_get_voltage(struct aw_sar *p_sar)
+{
+	uint32_t cnt = 10;
+	int32_t voltage_val;
+
+	while (cnt--) {
+		voltage_val = regulator_get_voltage(p_sar->vcc);
+		if (voltage_val >= AW_SAR_VCC_MIN_UV)
+			return 0;
+		mdelay(1);
+	}
+	//Ensure that the chip initialization is completed
+	msleep(20);
+
+	return -EINVAL;
+}
+//AW_SAR_REGULATOR_POWER_ON end
+
+static void aw_sar_init_lock(struct aw_sar *p_sar)
+{
+	//Initialize lock, To protect the thread safety of updating bin file
+	mutex_init(&aw_sar_lock);
+	//Required for mode setting
+	p_sar->last_mode = p_sar->p_sar_para->p_chip_mode->pre_init_mode;
+	p_sar->fw_fail_flag = AW_FALSE;
+	p_sar->ret_val = 0;
+}
+
+// AW_SAR_USB_PLUG_CAIL start
+static void aw_sar_ps_notify_callback_work(struct work_struct *work)
+{
+	struct aw_sar *p_sar = container_of(work, struct aw_sar, ps_notify_work);
+
+	aw_sar_aot(p_sar);
+}
+
+static int aw_sar_ps_get_state(struct aw_sar *p_sar, struct power_supply *psy, bool *present)
+{
+	union power_supply_propval pval = { 0 };
+	int retval;
+
+	retval = power_supply_get_property(psy, AW_USB_PROP_ONLINE, &pval);
+	if (retval) {
+		dev_err(p_sar->dev, "%s psy get property failed", psy->desc->name);
+		return retval;
+	}
+	*present = (pval.intval) ? true : false;
+
+	return 0;
+}
+
+static int aw_sar_ps_notify_callback(struct notifier_block *self,
+		unsigned long event, void *p)
+{
+	struct aw_sar *p_sar = container_of(self, struct aw_sar, ps_notif);
+	struct power_supply *psy = p;
+	bool present;
+	int retval;
+
+	if (event == PSY_EVENT_PROP_CHANGED
+		&& psy && psy->desc->get_property && psy->desc->name &&
+		!strncmp(psy->desc->name, USB_POWER_SUPPLY_NAME,
+			sizeof(USB_POWER_SUPPLY_NAME))) {
+		retval = aw_sar_ps_get_state(p_sar, psy, &present);
+		if (retval) {
+			dev_err(p_sar->dev, "psy get property failed");
+			return retval;
+		}
+		if (event == PSY_EVENT_PROP_CHANGED) {
+			if (p_sar->ps_is_present == present)
+				return 0;
+		}
+		p_sar->ps_is_present = present;
+		schedule_work(&p_sar->ps_notify_work);
+	}
+	return 0;
+}
+
+static int aw_sar_ps_notify_init(struct aw_sar *p_sar)
+{
+	struct power_supply *psy;
+	int ret;
+
+	INIT_WORK(&p_sar->ps_notify_work, aw_sar_ps_notify_callback_work);
+	p_sar->ps_notif.notifier_call = (notifier_fn_t)aw_sar_ps_notify_callback;
+	ret = power_supply_reg_notifier(&p_sar->ps_notif);
+	if (ret) {
+		dev_err(p_sar->dev, "Unable to register ps_notifier: %d", ret);
+		return ret;
+	}
+	psy = power_supply_get_by_name(USB_POWER_SUPPLY_NAME);
+	if (!psy) {
+		dev_err(p_sar->dev, "Unable to get power_supply: %s", USB_POWER_SUPPLY_NAME);
+		goto free_ps_notifier;
+	}
+	ret = aw_sar_ps_get_state(p_sar, psy, &p_sar->ps_is_present);
+	if (ret) {
+		dev_err(p_sar->dev, "psy get property failed rc=%d", ret);
+		goto free_ps_notifier;
+	}
+	return 0;
+
+free_ps_notifier:
+	power_supply_unreg_notifier(&p_sar->ps_notif);
+
+	return -EINVAL;
+}
+// AW_SAR_USB_PLUG_CAIL end
+
+static int32_t aw_sar_platform_rsc_init(struct aw_sar *p_sar)
+{
+	int32_t ret;
+
+	if (!p_sar->p_sar_para->p_platform_config)
+		return -EINVAL;
+
+	//step 1.parsing dts data
+	ret = aw_sar_parse_dts(p_sar);
+	if (ret != 0) {
+		dev_err(p_sar->dev, "parse dts error!");
+		return ret;
+	}
+
+	//Initialization lock and some variables
+	aw_sar_init_lock(p_sar);
+
+	//Configure whether to use USB plug-in calibration in DTS according to customer requirements
+	if (p_sar->dts_info.use_plug_cail_flag == true) {
+		ret = aw_sar_ps_notify_init(p_sar);
+		if (ret < 0) {
+			dev_err(p_sar->dev, "error creating power supply notify");
+			goto err_ps_notify_init;
+		}
+	}
+
+	//The interrupt pin is set to internal pull-up and configured by DTS
+	if (p_sar->dts_info.use_inter_pull_up == true) {
+		ret = aw_sar_pinctrl_init(p_sar);
+		if (ret < 0) {
+			/* if define pinctrl must define the following state
+			 * to let int-pin work normally: default, int_output_high,
+			 * int_output_low, int_input
+			 */
+			dev_err(p_sar->dev, "Failed get wanted pinctrl state");
+			goto err_pinctrl_init;
+		}
+		aw_sar_int_output(p_sar, 1);
+	}
+
+	//step 2.Create debug file node
+	ret = aw_sar_create_node(p_sar);
+	if (ret != 0) {
+		dev_err(p_sar->dev, "create node error!");
+		goto err_sysfs_nodes;
+	}
+
+	//step 3.Initialization interrupt
+	ret = aw_sar_irq_init(p_sar);
+	if (ret != 0) {
+		dev_err(p_sar->dev, "interrupt initialization error!");
+		goto err_irq_init;
+	}
+
+	//step 4.Initialization input Subsystem
+	ret = aw_sar_input_init(p_sar);
+	if (ret != 0) {
+		dev_err(p_sar->dev, "input_init error!");
+		goto err_input_init;
+	}
+
+	return 0;
+
+err_input_init:
+	aw_sar_input_free(p_sar);
+	aw_sar_irq_free(p_sar);
+err_irq_init:
+	aw_sar_node_free(p_sar);
+err_sysfs_nodes:
+	if (p_sar->dts_info.use_inter_pull_up == true)
+		aw_sar_pinctrl_deinit(p_sar);
+err_pinctrl_init:
+	if (p_sar->dts_info.use_plug_cail_flag == true)
+		power_supply_unreg_notifier(&p_sar->ps_notif);
+err_ps_notify_init:
+	mutex_destroy(&aw_sar_lock);
+
+	return ret;
+}
+
+/**
+ * @brief sar sensor initialization logic.
+ *
+ * @param p_sar  data stored in type 'struct aw_sar *'.
+ * @return 0 if init succeeded. others if unpack error.
+ */
+static int32_t aw_sar_chip_init(struct aw_sar *p_sar)
+{
+	int32_t ret;
+
+	//step 1.check chipid,Verify whether the chip communication is successful
+	ret = aw_sar_check_chipid(p_sar);
+	if (ret != 0) {
+		dev_err(p_sar->dev, "check_chipid error!");
+		goto communication_fail;
+	}
+
+	//step 2.Check chip initialization completed,
+	ret = aw_sar_soft_reset(p_sar);
+	if (ret != 0) {
+		dev_err(p_sar->dev, "soft_reset error!");
+		goto communication_fail;
+	}
+
+	ret = aw_sar_check_init_over_irq(p_sar);
+	if (ret != 0) {
+		dev_err(p_sar->dev, "check_init_over_irqt error!");
+		goto communication_fail;
+	}
+
+	//step 3.chip other operation
+	ret = aw_sar_chip_other_operation(p_sar);
+	if (ret != 0) {
+		dev_err(p_sar->dev, "chip_other_operation error!");
+		goto free_other_opera;
+	}
+
+	//step 4.Parse the bin file, upgrade the firmware, and load the register prize
+	aw_sar_update(p_sar);
+
+	return 0;
+
+free_other_opera:
+	aw_sar_chip_other_operation_free(p_sar);
+communication_fail:
+
+	return ret;
+}
+
+static int32_t aw_sar_init(struct aw_sar *p_sar)
+{
+	int32_t ret;
+
+	//step 1: Platform resource initialization
+	ret = aw_sar_platform_rsc_init(p_sar);
+	if (ret != 0) {
+		dev_err(p_sar->dev, "platform_rsc_init error!");
+		return ret;
+	}
+
+	//step 2: Chip initialization
+	ret = aw_sar_chip_init(p_sar);
+	if (ret != 0) {
+		aw_sar_input_free(p_sar);
+		aw_sar_irq_free(p_sar);
+		aw_sar_node_free(p_sar);
+		if (p_sar->dts_info.use_inter_pull_up == true)
+			aw_sar_pinctrl_deinit(p_sar);
+		if (p_sar->dts_info.use_plug_cail_flag == true)
+			power_supply_unreg_notifier(&p_sar->ps_notif);
+		mutex_destroy(&aw_sar_lock);
+		return ret;
+	}
+
+	return 0;
+}
+
+static int32_t aw_sar_regulator_power(struct aw_sar *p_sar)
+{
+	struct aw_sar_dts_info *p_dts_info = &p_sar->dts_info;
+	int32_t ret = 0;
+
+	p_dts_info->use_regulator_flag =
+		of_property_read_bool(p_sar->i2c->dev.of_node, "aw_sar,regulator-power-supply");
+
+	//Configure the use of regulator power supply in DTS
+	if (p_sar->dts_info.use_regulator_flag == true) {
+		ret = aw_sar_regulator_power_init(p_sar);
+		if (ret != 0) {
+			dev_err(p_sar->dev, "power init failed");
+			return ret;
+		}
+		aw_sar_power_enable(p_sar, AW_TRUE);
+		ret = regulator_is_get_voltage(p_sar);
+		if (ret != 0) {
+			dev_err(p_sar->dev, "get_voltage failed");
+			aw_sar_power_deinit(p_sar);
+		}
+	}
+
+	return ret;
+}
+
+/**
+ * @brief Distinguish different chips by chip name and obtain relevant chip information
+ *
+ * @param p_sar Structure to be filled
+ * @return 0 if init succeeded.
+ */
+static int32_t aw_sar_get_chip_info(struct aw_sar *p_sar)
+{
+	int32_t ret;
+	uint8_t i;
+
+	for (i = 0; i < AW_SAR_DRIVER_MAX; i++) {
+		if (g_aw_sar_driver_list[i].p_who_am_i != NULL) {
+			ret = g_aw_sar_driver_list[i].p_who_am_i(p_sar);
+			if (ret == 0) {
+				p_sar->curr_use_driver_type = g_aw_sar_driver_list[i].driver_type;
+				if (!g_aw_sar_driver_list[i].p_chip_init) {
+					dev_err(p_sar->dev,
+							"drvier:%d p_chip_init is null  error!", i);
+					continue;
+				}
+				g_aw_sar_driver_list[i].p_chip_init(p_sar);
+				dev_info(p_sar->dev, "current use drvier is :%d",
+						g_aw_sar_driver_list[i].driver_type);
+				return 0;
+			}
+		}
+	}
+
+	return -EINVAL;
+}
+
+static void aw_sar_monitor_work(struct work_struct *aw_work)
+{
+	struct aw_sar *p_sar = container_of(aw_work, struct aw_sar, monitor_work.work);
+	uint32_t data;
+	int32_t ret;
+
+	ret = aw_sar_i2c_read(p_sar->i2c, 0x0000, &data);
+	if (ret != 0) {
+		dev_err(p_sar->dev, "read 0x0000 err: %d", ret);
+		return;
+	}
+	if (data == 0 && p_sar->driver_code_initover_flag) {
+		dev_err(p_sar->dev, "aw_chip may reset");
+		aw_sar_disable_irq(p_sar);
+		ret = aw_sar_chip_init(p_sar);
+		if (ret != 0)
+			return;
+	}
+	queue_delayed_work(p_sar->monitor_wq, &p_sar->monitor_work,
+			msecs_to_jiffies(AW_SAR_MONITOR_ESD_DELAY_MS));
+}
+
+static int32_t aw_sar_monitor_esd_init(struct aw_sar *p_sar)
+{
+	p_sar->monitor_wq = create_singlethread_workqueue("aw_sar_workqueue");
+	if (!p_sar->monitor_wq) {
+		dev_err(&p_sar->i2c->dev, "aw_sar_workqueue error");
+		return -EINVAL;
+	}
+	INIT_DELAYED_WORK(&p_sar->monitor_work, aw_sar_monitor_work);
+	queue_delayed_work(p_sar->monitor_wq, &p_sar->monitor_work,
+			msecs_to_jiffies(AW_SAR_MONITOR_ESD_DELAY_MS));
+
+	return 0;
+}
+
+static void aw_sar_sensor_free(struct aw_sar *p_sar)
+{
+	if (g_aw_sar_driver_list[p_sar->curr_use_driver_type].p_chip_deinit != NULL)
+		g_aw_sar_driver_list[p_sar->curr_use_driver_type].p_chip_deinit(p_sar);
+}
+
+
+/**
+ * @brief Drive logic entry
+ *
+ */
+static int32_t aw_sar_i2c_probe(struct i2c_client *i2c)
+{
+	struct aw_sar *p_sar;
+	int32_t ret;
+
+	if (!i2c_check_functionality(i2c->adapter, I2C_FUNC_I2C)) {
+		pr_err("check_functionality failed!\n");
+		return -EIO;
+	}
+
+	p_sar = devm_kzalloc(&i2c->dev, sizeof(struct aw_sar), GFP_KERNEL);
+	if (!p_sar) {
+		ret = -ENOMEM;
+		goto err_malloc;
+	}
+
+	p_sar->dev = &i2c->dev;
+	p_sar->i2c = i2c;
+	i2c_set_clientdata(i2c, p_sar);
+
+	//1.Judge whether to use regular power supply. If yes, supply power
+	ret = aw_sar_regulator_power(p_sar);
+	if (ret != 0) {
+		dev_err(&i2c->dev, "regulator_power error!");
+		goto err_malloc;
+	}
+
+	//2.Get chip initialization resources
+	ret = aw_sar_get_chip_info(p_sar);
+	if (ret != 0) {
+		dev_err(&i2c->dev, "chip_init error!");
+		goto err_chip_init;
+	}
+
+	//3.Chip initialization process
+	ret = aw_sar_init(p_sar);
+	if (ret != 0) {
+		dev_err(&i2c->dev, "sar_init error!");
+		goto err_sar_init;
+	}
+
+	if (p_sar->dts_info.monitor_esd_flag) {
+		ret = aw_sar_monitor_esd_init(p_sar);
+		if (ret != 0) {
+			dev_err(&i2c->dev, "monitor_esd_init error!");
+			goto err_esd_init;
+		}
+	}
+
+	dev_dbg(&i2c->dev, "probe success!");
+
+	return 0;
+
+err_esd_init:
+	aw_sar_input_free(p_sar);
+	aw_sar_irq_free(p_sar);
+	aw_sar_node_free(p_sar);
+	if (p_sar->dts_info.use_inter_pull_up == true)
+		aw_sar_pinctrl_deinit(p_sar);
+	if (p_sar->dts_info.use_plug_cail_flag == true)
+		power_supply_unreg_notifier(&p_sar->ps_notif);
+	mutex_destroy(&aw_sar_lock);
+err_sar_init:
+	aw_sar_sensor_free(p_sar);
+err_chip_init:
+if (p_sar->dts_info.use_regulator_flag == true)
+	aw_sar_power_deinit(p_sar);
+err_malloc:
+	return ret;
+}
+
+static void aw_sar_i2c_remove(struct i2c_client *i2c)
+{
+	struct aw_sar *p_sar  = i2c_get_clientdata(i2c);
+
+	aw_sar_chip_other_operation_free(p_sar);
+
+	aw_sar_node_free(p_sar);
+
+	aw_sar_irq_free(p_sar);
+
+	aw_sar_input_free(p_sar);
+
+	if (p_sar->dts_info.use_inter_pull_up == true)
+		aw_sar_pinctrl_deinit(p_sar);
+
+	if (p_sar->dts_info.use_regulator_flag == true)
+		aw_sar_power_deinit(p_sar);
+
+	if (p_sar->dts_info.use_plug_cail_flag == true)
+		power_supply_unreg_notifier(&p_sar->ps_notif);
+
+	aw_sar_sensor_free(p_sar);
+}
+
+static int aw_sar_suspend(struct device *dev)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct aw_sar *p_sar = i2c_get_clientdata(client);
+
+	if (p_sar->dts_info.use_pm == true) {
+		if ((!p_sar->p_sar_para->p_platform_config) ||
+			(!p_sar->p_sar_para->p_platform_config->p_pm_chip_mode))
+			return 0;
+		if (p_sar->p_sar_para->p_platform_config->p_pm_chip_mode->p_suspend_fn) {
+			p_sar->p_sar_para->p_platform_config->p_pm_chip_mode->p_suspend_fn(p_sar);
+			return 0;
+		}
+		aw_sar_mode_set(p_sar,
+			p_sar->p_sar_para->p_platform_config->p_pm_chip_mode->suspend_set_mode);
+	}
+
+	if (p_sar->dts_info.monitor_esd_flag)
+		cancel_delayed_work_sync(&p_sar->monitor_work);
+
+	return 0;
+}
+
+static int aw_sar_resume(struct device *dev)
+{
+	struct i2c_client *client = to_i2c_client(dev);
+	struct aw_sar *p_sar = i2c_get_clientdata(client);
+
+	if (p_sar->dts_info.use_pm == true) {
+		if ((!p_sar->p_sar_para->p_platform_config) ||
+			(!p_sar->p_sar_para->p_platform_config->p_pm_chip_mode))
+			return 0;
+		if (p_sar->p_sar_para->p_platform_config->p_pm_chip_mode->p_resume_fn) {
+			p_sar->p_sar_para->p_platform_config->p_pm_chip_mode->p_resume_fn(p_sar);
+			return 0;
+		}
+		aw_sar_mode_set(p_sar,
+			p_sar->p_sar_para->p_platform_config->p_pm_chip_mode->resume_set_mode);
+	}
+
+	if (p_sar->dts_info.monitor_esd_flag)
+		queue_delayed_work(p_sar->monitor_wq, &p_sar->monitor_work,
+				msecs_to_jiffies(AW_SAR_MONITOR_ESD_DELAY_MS));
+
+	return 0;
+}
+
+static void aw_sar_i2c_shutdown(struct i2c_client *i2c)
+{
+	struct aw_sar *p_sar  = i2c_get_clientdata(i2c);
+
+	if ((!p_sar->p_sar_para->p_platform_config) ||
+		(!p_sar->p_sar_para->p_platform_config->p_pm_chip_mode))
+		return;
+
+	if (p_sar->p_sar_para->p_platform_config->p_pm_chip_mode->p_shutdown_fn) {
+		p_sar->p_sar_para->p_platform_config->p_pm_chip_mode->p_shutdown_fn(p_sar);
+		return;
+	}
+
+	aw_sar_mode_set(p_sar,
+		p_sar->p_sar_para->p_platform_config->p_pm_chip_mode->shutdown_set_mode);
+}
+
+static const struct dev_pm_ops aw_sar_pm_ops = {
+	.suspend = aw_sar_suspend,
+	.resume = aw_sar_resume,
+};
+
+static const struct of_device_id aw_sar_dt_match[] = {
+	{ .compatible = "awinic,aw96103" },
+	{ .compatible = "awinic,aw96105" },
+	{ .compatible = "awinic,aw96303" },
+	{ .compatible = "awinic,aw96305" },
+	{ .compatible = "awinic,aw96308" },
+};
+
+static const struct i2c_device_id aw_sar_i2c_id[] = {
+	{ AW_SAR_I2C_NAME, 0 },
+	{ },
+};
+MODULE_DEVICE_TABLE(i2c, aw_sar_i2c_id);
+
+static struct i2c_driver aw_sar_i2c_driver = {
+	.driver = {
+		.name = AW_SAR_I2C_NAME,
+		.owner = THIS_MODULE,
+		.of_match_table = of_match_ptr(aw_sar_dt_match),
+		.pm = &aw_sar_pm_ops,
+	},
+	.probe = aw_sar_i2c_probe,
+	.remove = aw_sar_i2c_remove,
+	.shutdown = aw_sar_i2c_shutdown,
+	.id_table = aw_sar_i2c_id,
+};
+
+static int32_t __init aw_sar_i2c_init(void)
+{
+	int32_t ret;
+
+	ret = i2c_add_driver(&aw_sar_i2c_driver);
+	if (ret) {
+		pr_err("fail to add aw_sar device into i2c\n");
+		return ret;
+	}
+
+	return 0;
+}
+
+module_init(aw_sar_i2c_init);
+static void __exit aw_sar_i2c_exit(void)
+{
+	i2c_del_driver(&aw_sar_i2c_driver);
+}
+module_exit(aw_sar_i2c_exit);
+MODULE_DESCRIPTION("AWINIC SAR Driver");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/input/misc/aw_sar/aw_sar.h b/drivers/input/misc/aw_sar/aw_sar.h
new file mode 100644
index 000000000000..7a139f56e9c3
--- /dev/null
+++ b/drivers/input/misc/aw_sar/aw_sar.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef AW_SAR_H_
+#define AW_SAR_H_
+
+void aw_sar_disable_irq(struct aw_sar *p_sar);
+void aw_sar_enable_irq(struct aw_sar *p_sar);
+
+int32_t aw_sar_soft_reset(struct aw_sar *p_sar);
+int32_t aw_sar_check_init_over_irq(struct aw_sar *p_sar);
+int32_t aw_sar_update_fw(struct aw_sar *p_sar);
+int32_t aw_sar_load_def_reg_bin(struct aw_sar *p_sar);
+void aw_sar_mode_set(struct aw_sar *p_sar, uint8_t curr_mode);
+int32_t aw_sar_update_reg_set_func(struct aw_sar *p_sar);
+
+#endif
-- 
2.45.1


^ permalink raw reply related	[relevance 2%]

* Re: [PATCH] btrfs: qgroup: delete a todo about using kmem cache to alloc structure
  @ 2024-05-29 13:11  0%   ` JunChao Sun
  0 siblings, 0 replies; 200+ results
From: JunChao Sun @ 2024-05-29 13:11 UTC (permalink / raw)
  To: Qu Wenruo; +Cc: linux-btrfs, clm, josef, dsterba

Qu Wenruo <quwenruo.btrfs@gmx.com> 于2024年5月28日周二 14:42写道:
>
>
>
> 在 2024/5/28 15:53, Junchao Sun 写道:
> > Generic slub works fine so far. And it's not necessary to create a
> > dedicated kmem cache and leave it unused if quotas are disabled.
> > So let's delete the todo line.
> >
> > Signed-off-by: Junchao Sun <sunjunchao2870@gmail.com>
>
> Reviewed-by: Qu Wenruo <wqu@suse.com>
>
> My bad, at the time of writing I didn't notice that qgroup is not always
> enabled.
>
> > Furthermore nowadays squota won't utilize that structure either, making
> > it less meaningful to go kmemcache.
Thank you for your further explanation. By the way, is there anything
meaningful todo? I saw some in code, but I can't ensure if they are
still meaningful. I'd like to try contributing to btrfs and improve my
understanding of it.
Also, is it a meaningful to view the contents of snapshots without
rolling them back? The company I work for is considering implementing
it recently...
>
> Thanks,
> Qu
> > ---
> >   fs/btrfs/qgroup.h | 1 -
> >   1 file changed, 1 deletion(-)
> >
> > diff --git a/fs/btrfs/qgroup.h b/fs/btrfs/qgroup.h
> > index 706640be0ec2..7874c972029c 100644
> > --- a/fs/btrfs/qgroup.h
> > +++ b/fs/btrfs/qgroup.h
> > @@ -123,7 +123,6 @@ struct btrfs_inode;
> >
> >   /*
> >    * Record a dirty extent, and info qgroup to update quota on it
> > - * TODO: Use kmem cache to alloc it.
> >    */
> >   struct btrfs_qgroup_extent_record {
> >       struct rb_node node;

^ permalink raw reply	[relevance 0%]

* Re: [PATCH libgpiod v2 2/4] tools: tests: use "$@" instead of $*
  @ 2024-05-29 13:11  3%         ` Andy Shevchenko
  0 siblings, 0 replies; 200+ results
From: Andy Shevchenko @ 2024-05-29 13:11 UTC (permalink / raw)
  To: Kent Gibson
  Cc: Bartosz Golaszewski, Linus Walleij, Bartosz Golaszewski, linux-gpio

On Tue, May 28, 2024 at 07:54:26AM +0800, Kent Gibson wrote:
> On Mon, May 27, 2024 at 07:20:01PM +0300, Andy Shevchenko wrote:
> > On Mon, May 27, 2024 at 08:44:20PM +0800, Kent Gibson wrote:
> > > On Mon, May 27, 2024 at 02:02:34PM +0200, Bartosz Golaszewski wrote:

...

> > > It also doesn't like looping on find results in patch 4[2], though that
> > > is not related to your change, so leave it and I'll fix it later?
> >
> > Does it really mean _to fix_ rather than _to "fix"_? I mean how do we know that
> > shellcheck is 100% correct tool and has no bugs?
> 
> How do we know anything?
> 
> In this case you can read the description of the faults, which I had linked,
> and see if that makes sense to you.  And we test the fixed code to ensure
> it still works as intended.
> 
> I'm not claiming shellcheck is fool-proof, or 100% correct, or 100% complete,
> but it is more available and repeatable than Andy's Eyeballs.
> And if we do find bugs in it we can always fix those too.

Sure, any tool has its own limitations. Esp. Andy's Eyeballs!

> As I stated earlier, if you have a better metric to use then I'm more than
> happy to compare, but so far shellcheck seems a reasonable option to me.

No problem!

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[relevance 3%]

* Re: [PATCH 1/3] mctp pcc: Implement MCTP over PCC Transport
  @ 2024-05-29 13:10  2% ` kernel test robot
  0 siblings, 0 replies; 200+ results
From: kernel test robot @ 2024-05-29 13:10 UTC (permalink / raw)
  To: admiyo, Jeremy Kerr, Matt Johnston, David S. Miller,
	Eric Dumazet, Jakub Kicinski, Paolo Abeni
  Cc: oe-kbuild-all, netdev, linux-kernel, Adam Young

Hi,

kernel test robot noticed the following build errors:

[auto build test ERROR on rafael-pm/linux-next]
[also build test ERROR on rafael-pm/bleeding-edge linus/master v6.10-rc1 next-20240529]
[cannot apply to horms-ipvs/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/admiyo-os-amperecomputing-com/mctp-pcc-Implement-MCTP-over-PCC-Transport/20240529-072115
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link:    https://lore.kernel.org/r/20240513173546.679061-2-admiyo%40os.amperecomputing.com
patch subject: [PATCH 1/3] mctp pcc: Implement MCTP over PCC Transport
config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20240529/202405292029.IXat0564-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240529/202405292029.IXat0564-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202405292029.IXat0564-lkp@intel.com/

All errors (new ones prefixed by >>):

   In file included from drivers/net/mctp/mctp-pcc.c:17:
   include/acpi/acpi_drivers.h:72:43: warning: 'struct acpi_pci_root' declared inside parameter list will not be visible outside of this definition or declaration
      72 | struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root);
         |                                           ^~~~~~~~~~~~~
   drivers/net/mctp/mctp-pcc.c: In function 'mctp_pcc_client_rx_callback':
   drivers/net/mctp/mctp-pcc.c:96:23: warning: variable 'buf_ptr_val' set but not used [-Wunused-but-set-variable]
      96 |         unsigned long buf_ptr_val;
         |                       ^~~~~~~~~~~
   drivers/net/mctp/mctp-pcc.c: In function 'mctp_pcc_tx':
   drivers/net/mctp/mctp-pcc.c:122:24: warning: variable 'buffer' set but not used [-Wunused-but-set-variable]
     122 |         unsigned char *buffer;
         |                        ^~~~~~
   In file included from include/linux/device.h:15,
                    from include/linux/acpi.h:14,
                    from drivers/net/mctp/mctp-pcc.c:7:
   drivers/net/mctp/mctp-pcc.c: In function 'mctp_pcc_driver_add':
>> drivers/net/mctp/mctp-pcc.c:287:23: error: invalid use of undefined type 'struct acpi_device'
     287 |         dev_info(&adev->dev, "Adding mctp_pcc device for HID  %s\n", acpi_device_hid(adev));
         |                       ^~
   include/linux/dev_printk.h:110:25: note: in definition of macro 'dev_printk_index_wrap'
     110 |                 _p_func(dev, fmt, ##__VA_ARGS__);                       \
         |                         ^~~
   drivers/net/mctp/mctp-pcc.c:287:9: note: in expansion of macro 'dev_info'
     287 |         dev_info(&adev->dev, "Adding mctp_pcc device for HID  %s\n", acpi_device_hid(adev));
         |         ^~~~~~~~
>> drivers/net/mctp/mctp-pcc.c:287:70: error: implicit declaration of function 'acpi_device_hid'; did you mean 'acpi_device_dep'? [-Werror=implicit-function-declaration]
     287 |         dev_info(&adev->dev, "Adding mctp_pcc device for HID  %s\n", acpi_device_hid(adev));
         |                                                                      ^~~~~~~~~~~~~~~
   include/linux/dev_printk.h:110:37: note: in definition of macro 'dev_printk_index_wrap'
     110 |                 _p_func(dev, fmt, ##__VA_ARGS__);                       \
         |                                     ^~~~~~~~~~~
   drivers/net/mctp/mctp-pcc.c:287:9: note: in expansion of macro 'dev_info'
     287 |         dev_info(&adev->dev, "Adding mctp_pcc device for HID  %s\n", acpi_device_hid(adev));
         |         ^~~~~~~~
>> drivers/net/mctp/mctp-pcc.c:288:22: error: implicit declaration of function 'acpi_device_handle'; did you mean 'acpi_device_dep'? [-Werror=implicit-function-declaration]
     288 |         dev_handle = acpi_device_handle(adev);
         |                      ^~~~~~~~~~~~~~~~~~
         |                      acpi_device_dep
   drivers/net/mctp/mctp-pcc.c:288:20: warning: assignment to 'acpi_handle' {aka 'void *'} from 'int' makes pointer from integer without a cast [-Wint-conversion]
     288 |         dev_handle = acpi_device_handle(adev);
         |                    ^
   drivers/net/mctp/mctp-pcc.c:293:58: error: invalid use of undefined type 'struct acpi_device'
     293 |                 return create_mctp_pcc_netdev(adev, &adev->dev, inbox_index, outbox_index);
         |                                                          ^~
   drivers/net/mctp/mctp-pcc.c:295:22: error: invalid use of undefined type 'struct acpi_device'
     295 |         dev_err(&adev->dev, "FAILURE to lookup PCC indexes from CRS");
         |                      ^~
   include/linux/dev_printk.h:110:25: note: in definition of macro 'dev_printk_index_wrap'
     110 |                 _p_func(dev, fmt, ##__VA_ARGS__);                       \
         |                         ^~~
   drivers/net/mctp/mctp-pcc.c:295:9: note: in expansion of macro 'dev_err'
     295 |         dev_err(&adev->dev, "FAILURE to lookup PCC indexes from CRS");
         |         ^~~~~~~
   drivers/net/mctp/mctp-pcc.c: At top level:
>> drivers/net/mctp/mctp-pcc.c:329:15: error: variable 'mctp_pcc_driver' has initializer but incomplete type
     329 | static struct acpi_driver mctp_pcc_driver = {
         |               ^~~~~~~~~~~
>> drivers/net/mctp/mctp-pcc.c:330:10: error: 'struct acpi_driver' has no member named 'name'
     330 |         .name = "mctp_pcc",
         |          ^~~~
   drivers/net/mctp/mctp-pcc.c:330:17: warning: excess elements in struct initializer
     330 |         .name = "mctp_pcc",
         |                 ^~~~~~~~~~
   drivers/net/mctp/mctp-pcc.c:330:17: note: (near initialization for 'mctp_pcc_driver')
>> drivers/net/mctp/mctp-pcc.c:331:10: error: 'struct acpi_driver' has no member named 'class'
     331 |         .class = "Unknown",
         |          ^~~~~
   drivers/net/mctp/mctp-pcc.c:331:18: warning: excess elements in struct initializer
     331 |         .class = "Unknown",
         |                  ^~~~~~~~~
   drivers/net/mctp/mctp-pcc.c:331:18: note: (near initialization for 'mctp_pcc_driver')
>> drivers/net/mctp/mctp-pcc.c:332:10: error: 'struct acpi_driver' has no member named 'ids'
     332 |         .ids = mctp_pcc_device_ids,
         |          ^~~
   drivers/net/mctp/mctp-pcc.c:332:16: warning: excess elements in struct initializer
     332 |         .ids = mctp_pcc_device_ids,
         |                ^~~~~~~~~~~~~~~~~~~
   drivers/net/mctp/mctp-pcc.c:332:16: note: (near initialization for 'mctp_pcc_driver')
>> drivers/net/mctp/mctp-pcc.c:333:10: error: 'struct acpi_driver' has no member named 'ops'
     333 |         .ops = {
         |          ^~~
>> drivers/net/mctp/mctp-pcc.c:333:16: error: extra brace group at end of initializer
     333 |         .ops = {
         |                ^
   drivers/net/mctp/mctp-pcc.c:333:16: note: (near initialization for 'mctp_pcc_driver')
   drivers/net/mctp/mctp-pcc.c:333:16: warning: excess elements in struct initializer
   drivers/net/mctp/mctp-pcc.c:333:16: note: (near initialization for 'mctp_pcc_driver')
>> drivers/net/mctp/mctp-pcc.c:338:10: error: 'struct acpi_driver' has no member named 'owner'
     338 |         .owner = THIS_MODULE,
         |          ^~~~~
   In file included from include/linux/printk.h:6,
                    from include/asm-generic/bug.h:22,
                    from arch/alpha/include/asm/bug.h:23,
                    from include/linux/bug.h:5,
                    from include/linux/thread_info.h:13,
                    from include/asm-generic/preempt.h:5,
                    from ./arch/alpha/include/generated/asm/preempt.h:1,
                    from include/linux/preempt.h:79,
                    from include/linux/spinlock.h:56,
                    from include/linux/mmzone.h:8,
                    from include/linux/gfp.h:7,
                    from include/linux/slab.h:16,
                    from include/linux/resource_ext.h:11,
                    from include/linux/acpi.h:13:
   include/linux/init.h:182:21: warning: excess elements in struct initializer
     182 | #define THIS_MODULE ((struct module *)0)
         |                     ^
   drivers/net/mctp/mctp-pcc.c:338:18: note: in expansion of macro 'THIS_MODULE'
     338 |         .owner = THIS_MODULE,
         |                  ^~~~~~~~~~~
   include/linux/init.h:182:21: note: (near initialization for 'mctp_pcc_driver')
     182 | #define THIS_MODULE ((struct module *)0)
         |                     ^
   drivers/net/mctp/mctp-pcc.c:338:18: note: in expansion of macro 'THIS_MODULE'
     338 |         .owner = THIS_MODULE,
         |                  ^~~~~~~~~~~
   drivers/net/mctp/mctp-pcc.c: In function 'mctp_pcc_mod_init':
>> drivers/net/mctp/mctp-pcc.c:348:14: error: implicit declaration of function 'acpi_bus_register_driver' [-Werror=implicit-function-declaration]
     348 |         rc = acpi_bus_register_driver(&mctp_pcc_driver);
         |              ^~~~~~~~~~~~~~~~~~~~~~~~
   drivers/net/mctp/mctp-pcc.c:350:80: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
     350 |                 ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Error registering driver\n"));
         |                                                                                ^
   drivers/net/mctp/mctp-pcc.c: In function 'mctp_pcc_mod_exit':
>> drivers/net/mctp/mctp-pcc.c:358:9: error: implicit declaration of function 'acpi_bus_unregister_driver'; did you mean 'platform_unregister_drivers'? [-Werror=implicit-function-declaration]
     358 |         acpi_bus_unregister_driver(&mctp_pcc_driver);
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~~
         |         platform_unregister_drivers
   drivers/net/mctp/mctp-pcc.c: At top level:
>> drivers/net/mctp/mctp-pcc.c:329:27: error: storage size of 'mctp_pcc_driver' isn't known
     329 | static struct acpi_driver mctp_pcc_driver = {
         |                           ^~~~~~~~~~~~~~~
   cc1: some warnings being treated as errors


vim +287 drivers/net/mctp/mctp-pcc.c

   278	
   279	static int mctp_pcc_driver_add(struct acpi_device *adev)
   280	{
   281		int inbox_index;
   282		int outbox_index;
   283		acpi_handle dev_handle;
   284		acpi_status status;
   285		struct lookup_context context = {0, 0, 0};
   286	
 > 287		dev_info(&adev->dev, "Adding mctp_pcc device for HID  %s\n", acpi_device_hid(adev));
 > 288		dev_handle = acpi_device_handle(adev);
   289		status = acpi_walk_resources(dev_handle, "_CRS", lookup_pcct_indices, &context);
   290		if (ACPI_SUCCESS(status)) {
   291			inbox_index = context.inbox_index;
   292			outbox_index = context.outbox_index;
   293			return create_mctp_pcc_netdev(adev, &adev->dev, inbox_index, outbox_index);
   294		}
   295		dev_err(&adev->dev, "FAILURE to lookup PCC indexes from CRS");
   296		return -EINVAL;
   297	};
   298	
   299	/* pass in adev=NULL to remove all devices
   300	 */
   301	static void mctp_pcc_driver_remove(struct acpi_device *adev)
   302	{
   303		struct mctp_pcc_ndev *mctp_pcc_dev = NULL;
   304		struct list_head *ptr;
   305		struct list_head *tmp;
   306	
   307		list_for_each_safe(ptr, tmp, &mctp_pcc_ndevs) {
   308			mctp_pcc_dev = list_entry(ptr, struct mctp_pcc_ndev, head);
   309			if (!adev || mctp_pcc_dev->acpi_device == adev) {
   310				struct net_device *ndev;
   311	
   312				mctp_pcc_dev->cleanup_channel(mctp_pcc_dev->out_chan);
   313				mctp_pcc_dev->cleanup_channel(mctp_pcc_dev->in_chan);
   314				ndev = mctp_pcc_dev->mdev.dev;
   315				if (ndev)
   316					mctp_unregister_netdev(ndev);
   317				list_del(ptr);
   318				if (adev)
   319					break;
   320			}
   321		}
   322	};
   323	
   324	static const struct acpi_device_id mctp_pcc_device_ids[] = {
   325		{ "DMT0001", 0},
   326		{ "", 0},
   327	};
   328	
 > 329	static struct acpi_driver mctp_pcc_driver = {
 > 330		.name = "mctp_pcc",
 > 331		.class = "Unknown",
 > 332		.ids = mctp_pcc_device_ids,
 > 333		.ops = {
   334			.add = mctp_pcc_driver_add,
   335			.remove = mctp_pcc_driver_remove,
   336			.notify = NULL,
   337		},
 > 338		.owner = THIS_MODULE,
   339	
   340	};
   341	
   342	static int __init mctp_pcc_mod_init(void)
   343	{
   344		int rc;
   345	
   346		pr_info("initializing MCTP over PCC\n");
   347		INIT_LIST_HEAD(&mctp_pcc_ndevs);
 > 348		rc = acpi_bus_register_driver(&mctp_pcc_driver);
   349		if (rc < 0)
   350			ACPI_DEBUG_PRINT((ACPI_DB_ERROR, "Error registering driver\n"));
   351		return rc;
   352	}
   353	
   354	static __exit void mctp_pcc_mod_exit(void)
   355	{
   356		pr_info("Removing MCTP over PCC transport driver\n");
   357		mctp_pcc_driver_remove(NULL);
 > 358		acpi_bus_unregister_driver(&mctp_pcc_driver);
   359	}
   360	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[relevance 2%]

* Re: [PATCH libgpiod v2 2/4] tools: tests: use "$@" instead of $*
  @ 2024-05-29 13:08  3%         ` Andy Shevchenko
  2024-05-29 13:18  3%           ` Kent Gibson
  0 siblings, 1 reply; 200+ results
From: Andy Shevchenko @ 2024-05-29 13:08 UTC (permalink / raw)
  To: Kent Gibson
  Cc: Bartosz Golaszewski, Linus Walleij, Bartosz Golaszewski, linux-gpio

On Tue, May 28, 2024 at 07:39:10AM +0800, Kent Gibson wrote:
> On Mon, May 27, 2024 at 07:17:37PM +0300, Andy Shevchenko wrote:
> > On Mon, May 27, 2024 at 08:44:20PM +0800, Kent Gibson wrote:
> > > On Mon, May 27, 2024 at 02:02:34PM +0200, Bartosz Golaszewski wrote:

...

> > > >  assert_fail() {
> > > > -	$* || return 0
> > > > -	fail " '$*': command did not fail as expected"
> > > > +	"$@" || return 0
> > > > +	fail " '$@': command did not fail as expected"
> > > >  }
> > >
> > > Ironically, shellcheck doesn't like the '$@' in the fail string[1], so you
> > > should use $* there.
> >
> > But why does it do like this?
> 
> Read the link[1].

Okay, this is only for some debug / error messages. Still if one wants to have
clear understanding on what has been passed to some function, $* is not a
correct option. Also note the single quotes, shouldn't that protect from the
arguments loss?

> Because $@ is an array being used to build a string, and that may not
> work the way you expect.

I think it's the opposite, $* works in a way I do not expect :-)

> In this case $* is clearer as that has already
> been concatenated.

...loosing information about which word refers to which argument, yes.

> [1] https://www.shellcheck.net/wiki/SC2145

TL;DR: I consider this is still a bug in shellcheck. But if you rely on the
tool as on the ruleset carved in stone, I will not die. Just a remark to
myself "even honourable tools may also be broken".

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[relevance 3%]

* Re: [meta-virtualization][PATCH 1/4] meta-virt: adjust for UNPACKDIR and GO_SRCURI_DESTSUFFIX
  @ 2024-05-29 13:08  1% ` Bruce Ashfield
  0 siblings, 0 replies; 200+ results
From: Bruce Ashfield @ 2024-05-29 13:08 UTC (permalink / raw)
  To: Qi.Chen; +Cc: meta-virtualization

As I mentioned on the list earlier this week, I've already dealt with
these issues.

I'm just finalizing a few runtime issues and everything will be pushed
to master-next.

Bruce

On Wed, May 29, 2024 at 5:31 AM Chen Qi via lists.yoctoproject.org
<Qi.Chen=windriver.com@lists.yoctoproject.org> wrote:
>
> From: Chen Qi <Qi.Chen@windriver.com>
>
> The patch is generated by the following commands:
>
>   grep -rl WORKDIR * | xargs sed -i -e 's#${WORKDIR}/${BP}/src/import#${GO_SRCURI_DESTSUFFIX}#g'
>   grep -rl WORKDIR * | xargs sed -i -e 's#${UNPACKDIR}#${UNPACKDIR}#g'
>   grep -rEl 'inherit.* go( |$)' * | xargs sed -i -e '/destsuffix/!s/protocol=https/protocol=https;destsuffix=${GO_SRCURI_DESTSUFFIX}/g'
>   grep -rl destsuffix * | xargs sed -i -e 's#destsuffix=${S}/#destsuffix=${GO_SRCURI_DESTSUFFIX}/../../#g'
>   grep -rl UNPACKDIR * | xargs sed -i -e 's#S = "${UNPACKDIR}#S = "${WORKDIR}#g'
>   grep -rl GOPATH * | xargs sed -i -e '/GOPATH/ s#UNPACKDIR#WORKDIR#g'
>   grep -rl '\${UNPACKDIR}/git' * | xargs sed -i -e 's#${UNPACKDIR}/git#${WORKDIR}/git#g'
>   grep -rl 'toolchain.cmake' * | xargs sed -i -e 's#${UNPACKDIR}/toolchain.cmake#${WORKDIR}/toolchain.cmake#g'
>
> What these commands do is:
> 1) use GO_SRCURI_DESTSUFFIX to adapt to latest oe-core change
> 2) avoid absolute path in destsuffix
>    This will unnecessarily create ${S} diretory, causing a chaos when doing shutil.move.
>    The unpack codes in base.bbclass remove ${S} in most cases and then does a move.
> 3) Use UNPACKDIR to replace WORKDIR.
>
> Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
> ---
>  .../xen-rpi-u-boot-scr/xen-rpi-u-boot-scr.bb  |   4 +-
>  recipes-containers/buildah/buildah_git.bb     |   2 +-
>  .../cgroup-lite/cgroup-lite_1.15.bb           |   2 +-
>  .../container-host-config.bb                  |   6 +-
>  recipes-containers/cri-o/cri-o_git.bb         |   4 +-
>  recipes-containers/cri-tools/cri-tools_git.bb |   2 +-
>  .../docker-compose/docker-compose_git.bb      |   4 +-
>  recipes-containers/docker-compose/src_uri.inc | 372 ++++----
>  .../docker-distribution_git.bb                |   2 +-
>  recipes-containers/docker/docker.inc          |   2 +-
>  recipes-containers/k3s/k3s_git.bb             |  16 +-
>  recipes-containers/k3s/src_uri.inc            | 860 +++++++++---------
>  .../kubernetes/kubernetes_git.bb              |  10 +-
>  recipes-containers/lxc/lxc_git.bb             |   4 +-
>  recipes-containers/nerdctl/nerdctl_git.bb     |   4 +-
>  recipes-containers/nerdctl/src_uri.inc        | 270 +++---
>  .../podman-tui/podman-tui_git.bb              |   2 +-
>  recipes-containers/podman/podman_git.bb       |   4 +-
>  .../kata-containers/kata-agent_git.bb         |   2 +-
>  .../kata-containers/kata-proxy_git.bb         |   2 +-
>  .../kata-containers/kata-runtime_git.bb       |   2 +-
>  recipes-core/kata-containers/kata-shim_git.bb |   2 +-
>  recipes-core/runv/runv_git.bb                 |   2 +-
>  recipes-core/runx/runx_git.bb                 |   8 +-
>  .../helloworld-flask/helloworld-flask_0.1.bb  |  18 +-
>  recipes-devtools/go/go-build_git.bb           |   2 +-
>  recipes-devtools/go/go-md2man_git.bb          |   2 +-
>  recipes-devtools/yq/yq_git.bb                 |   4 +-
>  recipes-extended/ceph/ceph_18.2.2.bb          |   6 +-
>  recipes-extended/diod/diod_1.0.24.bb          |   4 +-
>  recipes-extended/images/xtf-image.bb          |   4 +-
>  recipes-extended/libvirt/libvirt-python.inc   |   4 +-
>  recipes-extended/libvirt/libvirt_10.0.0.bb    |  30 +-
>  recipes-extended/nagios/nagios-core_4.4.6.bb  |   6 +-
>  recipes-extended/nagios/nagios-nrpe_4.0.2.bb  |   4 +-
>  recipes-extended/nagios/nagios-nsca_2.9.2.bb  |   4 +-
>  .../uxen/uxen-guest-tools_4.1.8.bb            |   2 +-
>  .../virt-viewer/virt-viewer_11.0.bb           |   2 +-
>  recipes-extended/xen/xen.inc                  |   6 +-
>  recipes-networking/cni/cni_git.bb             |   8 +-
>  recipes-networking/cni/src_uri.inc            |  26 +-
>  recipes-networking/netns/netns_git.bb         |   2 +-
>  .../openvswitch/openvswitch.inc               |   8 +-
>  scripts/oe-go-mod-autogen.py                  |  12 +-
>  44 files changed, 871 insertions(+), 871 deletions(-)
>
> diff --git a/dynamic-layers/raspberrypi/recipes-bsp/xen-rpi-u-boot-scr/xen-rpi-u-boot-scr.bb b/dynamic-layers/raspberrypi/recipes-bsp/xen-rpi-u-boot-scr/xen-rpi-u-boot-scr.bb
> index 87619d01..f1d3189d 100644
> --- a/dynamic-layers/raspberrypi/recipes-bsp/xen-rpi-u-boot-scr/xen-rpi-u-boot-scr.bb
> +++ b/dynamic-layers/raspberrypi/recipes-bsp/xen-rpi-u-boot-scr/xen-rpi-u-boot-scr.bb
> @@ -17,9 +17,9 @@ do_compile() {
>          -e 's/@@KERNEL_BOOTCMD@@/${KERNEL_BOOTCMD}/' \
>          -e 's/@@RPI_DOM0_MEM@@/${RPI_DOM0_MEM}/' \
>          -e 's/@@RPI_DEBUG_XEN_ARGS@@/${RPI_DEBUG_XEN_ARGS}/' \
> -        "${WORKDIR}/boot.cmd.xen.in" > "${WORKDIR}/boot.cmd"
> +        "${UNPACKDIR}/boot.cmd.xen.in" > "${UNPACKDIR}/boot.cmd"
>
> -    mkimage -A ${UBOOT_ARCH} -T script -C none -n "Boot script" -d "${WORKDIR}/boot.cmd" boot.scr
> +    mkimage -A ${UBOOT_ARCH} -T script -C none -n "Boot script" -d "${UNPACKDIR}/boot.cmd" boot.scr
>  }
>
>  inherit kernel-arch deploy nopackages
> diff --git a/recipes-containers/buildah/buildah_git.bb b/recipes-containers/buildah/buildah_git.bb
> index 64ee4f7d..40950fa9 100644
> --- a/recipes-containers/buildah/buildah_git.bb
> +++ b/recipes-containers/buildah/buildah_git.bb
> @@ -32,7 +32,7 @@ SRCREV_buildah = "dbeb097c6fbf4bfd643f096992da572a97a8ec12"
>  SRCREV_storage = "246ba3062e8b551026aef2708eee747014ce5c52"
>
>  SRC_URI = " \
> -    git://github.com/containers/buildah;branch=release-1.34;name=buildah;protocol=https \
> +    git://github.com/containers/buildah;branch=release-1.34;name=buildah;protocol=https;destsuffix=${GO_SRCURI_DESTSUFFIX} \
>      "
>
>  DEPENDS = "libdevmapper btrfs-tools gpgme"
> diff --git a/recipes-containers/cgroup-lite/cgroup-lite_1.15.bb b/recipes-containers/cgroup-lite/cgroup-lite_1.15.bb
> index 23ecfa4a..7d1ca23d 100644
> --- a/recipes-containers/cgroup-lite/cgroup-lite_1.15.bb
> +++ b/recipes-containers/cgroup-lite/cgroup-lite_1.15.bb
> @@ -27,7 +27,7 @@ do_install() {
>         install -m 0755 ${S}/scripts/cgroups-umount ${D}/${base_bindir}
>
>         install -d ${D}${sysconfdir}/init.d
> -       install -m 0755 ${WORKDIR}/cgroups-init ${D}${sysconfdir}/init.d/cgroups-init
> +       install -m 0755 ${UNPACKDIR}/cgroups-init ${D}${sysconfdir}/init.d/cgroups-init
>
>         install -d ${D}${systemd_unitdir}/system
>         ln -sf /dev/null ${D}${systemd_unitdir}/system/cgroups-init.service
> diff --git a/recipes-containers/container-host-config/container-host-config.bb b/recipes-containers/container-host-config/container-host-config.bb
> index 80abddf0..3d962ffc 100644
> --- a/recipes-containers/container-host-config/container-host-config.bb
> +++ b/recipes-containers/container-host-config/container-host-config.bb
> @@ -14,9 +14,9 @@ SRC_URI = " \
>  do_install() {
>         install -d ${D}/${sysconfdir}/containers
>
> -       install ${WORKDIR}/storage.conf ${D}/${sysconfdir}/containers/storage.conf
> -       install ${WORKDIR}/registries.conf ${D}/${sysconfdir}/containers/registries.conf
> -       install ${WORKDIR}/policy.json ${D}/${sysconfdir}/containers/policy.json
> +       install ${UNPACKDIR}/storage.conf ${D}/${sysconfdir}/containers/storage.conf
> +       install ${UNPACKDIR}/registries.conf ${D}/${sysconfdir}/containers/registries.conf
> +       install ${UNPACKDIR}/policy.json ${D}/${sysconfdir}/containers/policy.json
>  }
>
>  BBCLASSEXTEND = "native nativesdk"
> diff --git a/recipes-containers/cri-o/cri-o_git.bb b/recipes-containers/cri-o/cri-o_git.bb
> index 4e17a7cd..0255aa0a 100644
> --- a/recipes-containers/cri-o/cri-o_git.bb
> +++ b/recipes-containers/cri-o/cri-o_git.bb
> @@ -16,7 +16,7 @@ At a high level, we expect the scope of cri-o to be restricted to the following
>
>  SRCREV_cri-o = "5aff11c7c1afdc785adafd7da3c3f2a6ac51b88d"
>  SRC_URI = "\
> -       git://github.com/kubernetes-sigs/cri-o.git;branch=release-1.30;name=cri-o;protocol=https \
> +       git://github.com/kubernetes-sigs/cri-o.git;branch=release-1.30;name=cri-o;protocol=https;destsuffix=${GO_SRCURI_DESTSUFFIX} \
>          file://crio.conf \
>         "
>
> @@ -83,7 +83,7 @@ do_install() {
>      install -d ${D}${systemd_unitdir}/system/
>      install -d ${D}/usr/share/containers/oci/hooks.d
>
> -    install ${WORKDIR}/crio.conf ${D}/${sysconfdir}/crio/crio.conf
> +    install ${UNPACKDIR}/crio.conf ${D}/${sysconfdir}/crio/crio.conf
>
>      # sample config files, they'll go in the ${PN}-config below
>      install -d ${D}/${sysconfdir}/crio/config/
> diff --git a/recipes-containers/cri-tools/cri-tools_git.bb b/recipes-containers/cri-tools/cri-tools_git.bb
> index e0caf740..f9b60bbf 100644
> --- a/recipes-containers/cri-tools/cri-tools_git.bb
> +++ b/recipes-containers/cri-tools/cri-tools_git.bb
> @@ -18,7 +18,7 @@ What is not in scope for this project? \
>
>  SRCREV_cri-tools = "17b4dd65d660fec94d7a5a070e3e89ef640f1087"
>  SRC_URI = "\
> -       git://github.com/kubernetes-sigs/cri-tools.git;branch=master;name=cri-tools;protocol=https \
> +       git://github.com/kubernetes-sigs/cri-tools.git;branch=master;name=cri-tools;protocol=https;destsuffix=${GO_SRCURI_DESTSUFFIX} \
>          file://0001-build-allow-environmental-CGO-settings-and-pass-dont.patch \
>         "
>
> diff --git a/recipes-containers/docker-compose/docker-compose_git.bb b/recipes-containers/docker-compose/docker-compose_git.bb
> index 07650126..316bf29d 100644
> --- a/recipes-containers/docker-compose/docker-compose_git.bb
> +++ b/recipes-containers/docker-compose/docker-compose_git.bb
> @@ -11,7 +11,7 @@ DEPENDS = " \
>  SRCREV_FORMAT="compose_survey"
>  SRCREV_compose = "3371227794f5f3645f4f19829c60a741635ed329"
>
> -SRC_URI = "git://github.com/docker/compose;name=compose;branch=main;protocol=https"
> +SRC_URI = "git://github.com/docker/compose;name=compose;branch=main;protocol=https;destsuffix=${GO_SRCURI_DESTSUFFIX}"
>
>  include src_uri.inc
>
> @@ -55,7 +55,7 @@ do_compile() {
>         # our copied .go files are to be used for the build
>         ln -sf vendor.copy vendor
>         # inform go that we know what we are doing
> -       cp ${WORKDIR}/modules.txt vendor/
> +       cp ${UNPACKDIR}/modules.txt vendor/
>
>         GO_LDFLAGS="-s -w -X internal.Version=${PV} -X ${COMPOSE_PKG}/internal.Version=${PV}"
>         GO_BUILDTAGS=""
> diff --git a/recipes-containers/docker-compose/src_uri.inc b/recipes-containers/docker-compose/src_uri.inc
> index 1978abc7..8327cb0e 100644
> --- a/recipes-containers/docker-compose/src_uri.inc
> +++ b/recipes-containers/docker-compose/src_uri.inc
> @@ -1,930 +1,930 @@
>  #       k8s.io/api v0.29.2
>  # [1] git ls-remote https://github.com/kubernetes/api d47313059888ec984bf8432ed155fae5be935c31
>  SRCREV_k8s.io-api="d47313059888ec984bf8432ed155fae5be935c31"
> -SRC_URI += "git://github.com/kubernetes/api;name=k8s.io-api;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/k8s.io/api"
> +SRC_URI += "git://github.com/kubernetes/api;name=k8s.io-api;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/k8s.io/api"
>
>  #       k8s.io/utils v0.0.0-20230726121419-3b25d923346b
>  # [1] git ls-remote https://github.com/kubernetes/utils 3b25d923346b3814e0898684c97390092f31a61e
>  SRCREV_utils="3b25d923346b3814e0898684c97390092f31a61e"
> -SRC_URI += "git://github.com/kubernetes/utils;name=utils;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/k8s.io/utils"
> +SRC_URI += "git://github.com/kubernetes/utils;name=utils;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/k8s.io/utils"
>
>  #       k8s.io/klog/v2 v2.110.1
>  # [1] git ls-remote https://github.com/kubernetes/klog e3f75b8af2707d64b5dd4c440ae8384ed2f2c386
>  SRCREV_klog-v2="e3f75b8af2707d64b5dd4c440ae8384ed2f2c386"
> -SRC_URI += "git://github.com/kubernetes/klog;name=klog-v2;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/k8s.io/klog/v2"
> +SRC_URI += "git://github.com/kubernetes/klog;name=klog-v2;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/k8s.io/klog/v2"
>
>  #       gotest.tools/v3 v3.5.1
>  # [1] git ls-remote https://github.com/gotestyourself/gotest.tools 81cea1abc596b025bf2573c7fdf97740512e4c6c
>  SRCREV_v3="81cea1abc596b025bf2573c7fdf97740512e4c6c"
> -SRC_URI += "git://github.com/gotestyourself/gotest.tools;name=v3;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/gotest.tools/v3"
> +SRC_URI += "git://github.com/gotestyourself/gotest.tools;name=v3;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/gotest.tools/v3"
>
>  #       dario.cat/mergo v1.0.0
>  # [1] git ls-remote https://github.com/imdario/mergo 131de815afc35a77c41ae99da6c8f4288b6cb513
>  SRCREV_mergo="131de815afc35a77c41ae99da6c8f4288b6cb513"
> -SRC_URI += "git://github.com/imdario/mergo;name=mergo;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/dario.cat/mergo"
> +SRC_URI += "git://github.com/imdario/mergo;name=mergo;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/dario.cat/mergo"
>
>  #       gopkg.in/inf.v0 v0.9.1
>  # [1] git ls-remote https://github.com/go-inf/inf d2d2541c53f18d2a059457998ce2876cc8e67cbf
>  SRCREV_inf.v0="d2d2541c53f18d2a059457998ce2876cc8e67cbf"
> -SRC_URI += "git://github.com/go-inf/inf;name=inf.v0;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/gopkg.in/inf.v0"
> +SRC_URI += "git://github.com/go-inf/inf;name=inf.v0;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/gopkg.in/inf.v0"
>
>  #       go.uber.org/mock v0.4.0
>  # [1] git ls-remote https://github.com/uber/mock 74a29c6e6c2cbb8ccee94db061c1604ff33fd188
>  SRCREV_mock="74a29c6e6c2cbb8ccee94db061c1604ff33fd188"
> -SRC_URI += "git://github.com/uber/mock;name=mock;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/go.uber.org/mock"
> +SRC_URI += "git://github.com/uber/mock;name=mock;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/go.uber.org/mock"
>
>  #       golang.org/x/exp v0.0.0-20240112132812-db7319d0e0e3
>  # [1] git ls-remote https://go.googlesource.com/exp db7319d0e0e361ccef5c449b760df8e5f2d5087c
>  SRCREV_exp="db7319d0e0e361ccef5c449b760df8e5f2d5087c"
> -SRC_URI += "git://go.googlesource.com/exp;name=exp;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/golang.org/x/exp"
> +SRC_URI += "git://go.googlesource.com/exp;name=exp;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/golang.org/x/exp"
>
>  #       golang.org/x/sys v0.16.0
>  # [1] git ls-remote https://go.googlesource.com/sys 0829ab15b6946f47c40012db2e0c04772730317d
>  SRCREV_sys="0829ab15b6946f47c40012db2e0c04772730317d"
> -SRC_URI += "git://go.googlesource.com/sys;name=sys;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/golang.org/x/sys"
> +SRC_URI += "git://go.googlesource.com/sys;name=sys;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/golang.org/x/sys"
>
>  #       gopkg.in/yaml.v3 v3.0.1
>  # [1] git ls-remote https://github.com/go-yaml/yaml f6f7691b1fdeb513f56608cd2c32c51f8194bf51
>  SRCREV_yaml.v3="f6f7691b1fdeb513f56608cd2c32c51f8194bf51"
> -SRC_URI += "git://github.com/go-yaml/yaml;name=yaml.v3;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/gopkg.in/yaml.v3"
> +SRC_URI += "git://github.com/go-yaml/yaml;name=yaml.v3;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/gopkg.in/yaml.v3"
>
>  #       golang.org/x/mod v0.14.0
>  # [1] git ls-remote https://go.googlesource.com/mod 6e58e47c7bd6672665dc35cce7b1f325d2addd67
>  SRCREV_mod="6e58e47c7bd6672665dc35cce7b1f325d2addd67"
> -SRC_URI += "git://go.googlesource.com/mod;name=mod;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/golang.org/x/mod"
> +SRC_URI += "git://go.googlesource.com/mod;name=mod;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/golang.org/x/mod"
>
>  #       golang.org/x/net v0.20.0
>  # [1] git ls-remote https://go.googlesource.com/net cb5b10f0bbc51089bf49030ce3bd43bbfee08c23
>  SRCREV_net="cb5b10f0bbc51089bf49030ce3bd43bbfee08c23"
> -SRC_URI += "git://go.googlesource.com/net;name=net;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/golang.org/x/net"
> +SRC_URI += "git://go.googlesource.com/net;name=net;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/golang.org/x/net"
>
>  #       gopkg.in/yaml.v2 v2.4.0
>  # [1] git ls-remote https://github.com/go-yaml/yaml 7649d4548cb53a614db133b2a8ac1f31859dda8c
>  SRCREV_yaml.v2="7649d4548cb53a614db133b2a8ac1f31859dda8c"
> -SRC_URI += "git://github.com/go-yaml/yaml;name=yaml.v2;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/gopkg.in/yaml.v2"
> +SRC_URI += "git://github.com/go-yaml/yaml;name=yaml.v2;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/gopkg.in/yaml.v2"
>
>  #       k8s.io/apiserver v0.29.2
>  # [1] git ls-remote https://github.com/kubernetes/apiserver 4c39f36a732cfb11f3fc75110c7301336b6b64e3
>  SRCREV_apiserver="4c39f36a732cfb11f3fc75110c7301336b6b64e3"
> -SRC_URI += "git://github.com/kubernetes/apiserver;name=apiserver;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/k8s.io/apiserver"
> +SRC_URI += "git://github.com/kubernetes/apiserver;name=apiserver;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/k8s.io/apiserver"
>
>  #       k8s.io/client-go v0.29.2
>  # [1] git ls-remote https://github.com/kubernetes/client-go 62c5e9e7b4bd09d2b43dcad1464376322398e994
>  SRCREV_client-go="62c5e9e7b4bd09d2b43dcad1464376322398e994"
> -SRC_URI += "git://github.com/kubernetes/client-go;name=client-go;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/k8s.io/client-go"
> +SRC_URI += "git://github.com/kubernetes/client-go;name=client-go;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/k8s.io/client-go"
>
>  #       sigs.k8s.io/json v0.0.0-20221116044647-bc3834ca7abd
>  # [1] git ls-remote https://github.com/kubernetes-sigs/json bc3834ca7abd3a90f03ef00a27ad80cb892f9c21
>  SRCREV_json="bc3834ca7abd3a90f03ef00a27ad80cb892f9c21"
> -SRC_URI += "git://github.com/kubernetes-sigs/json;name=json;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/sigs.k8s.io/json"
> +SRC_URI += "git://github.com/kubernetes-sigs/json;name=json;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/sigs.k8s.io/json"
>
>  #       sigs.k8s.io/yaml v1.3.0
>  # [1] git ls-remote https://github.com/kubernetes-sigs/yaml 9535b3b1e2893fe44efb37c5c9f5665e245d786a
>  SRCREV_yaml="9535b3b1e2893fe44efb37c5c9f5665e245d786a"
> -SRC_URI += "git://github.com/kubernetes-sigs/yaml;name=yaml;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/sigs.k8s.io/yaml"
> +SRC_URI += "git://github.com/kubernetes-sigs/yaml;name=yaml;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/sigs.k8s.io/yaml"
>
>  #       golang.org/x/sync v0.6.0
>  # [1] git ls-remote https://go.googlesource.com/sync 59c1ca1e4661ed4452be4069ceea3c233f4deec1
>  SRCREV_sync="59c1ca1e4661ed4452be4069ceea3c233f4deec1"
> -SRC_URI += "git://go.googlesource.com/sync;name=sync;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/golang.org/x/sync"
> +SRC_URI += "git://go.googlesource.com/sync;name=sync;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/golang.org/x/sync"
>
>  #       golang.org/x/term v0.16.0
>  # [1] git ls-remote https://go.googlesource.com/term ae941452f58ff9bf62f7e9dca3ea6ae3d214a68b
>  SRCREV_x-term="ae941452f58ff9bf62f7e9dca3ea6ae3d214a68b"
> -SRC_URI += "git://go.googlesource.com/term;name=x-term;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/golang.org/x/term"
> +SRC_URI += "git://go.googlesource.com/term;name=x-term;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/golang.org/x/term"
>
>  #       golang.org/x/text v0.14.0
>  # [1] git ls-remote https://go.googlesource.com/text 6c97a165dd661335ff7bce6104a008558123c353
>  SRCREV_text="6c97a165dd661335ff7bce6104a008558123c353"
> -SRC_URI += "git://go.googlesource.com/text;name=text;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/golang.org/x/text"
> +SRC_URI += "git://go.googlesource.com/text;name=text;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/golang.org/x/text"
>
>  #       golang.org/x/time v0.3.0
>  # [1] git ls-remote https://go.googlesource.com/time 2c09566ef13fb5556401ddff3c53c3dbc2a42dac
>  SRCREV_time="2c09566ef13fb5556401ddff3c53c3dbc2a42dac"
> -SRC_URI += "git://go.googlesource.com/time;name=time;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/golang.org/x/time"
> +SRC_URI += "git://go.googlesource.com/time;name=time;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/golang.org/x/time"
>
>  #       go.uber.org/goleak v1.3.0
>  # [1] git ls-remote https://github.com/uber-go/goleak 31095c657c34bba405a8d480db27989aa5f60b9c
>  SRCREV_goleak="31095c657c34bba405a8d480db27989aa5f60b9c"
> -SRC_URI += "git://github.com/uber-go/goleak;name=goleak;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/go.uber.org/goleak"
> +SRC_URI += "git://github.com/uber-go/goleak;name=goleak;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/go.uber.org/goleak"
>
>  #       golang.org/x/tools v0.17.0
>  # [1] git ls-remote https://go.googlesource.com/tools 0b1f1d4bc227cc2e610854f23e14696becb9e46c
>  SRCREV_tools="0b1f1d4bc227cc2e610854f23e14696becb9e46c"
> -SRC_URI += "git://go.googlesource.com/tools;name=tools;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/golang.org/x/tools"
> +SRC_URI += "git://go.googlesource.com/tools;name=tools;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/golang.org/x/tools"
>
>  #       golang.org/x/crypto v0.18.0
>  # [1] git ls-remote https://go.googlesource.com/crypto dbb6ec16ecef7a66638d8514be54b13660551b0a
>  SRCREV_crypto="dbb6ec16ecef7a66638d8514be54b13660551b0a"
> -SRC_URI += "git://go.googlesource.com/crypto;name=crypto;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/golang.org/x/crypto"
> +SRC_URI += "git://go.googlesource.com/crypto;name=crypto;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/golang.org/x/crypto"
>
>  #       golang.org/x/oauth2 v0.11.0
>  # [1] git ls-remote https://go.googlesource.com/oauth2 2e4a4e2bfb69ca7609cb423438c55caa131431c1
>  SRCREV_oauth2="2e4a4e2bfb69ca7609cb423438c55caa131431c1"
> -SRC_URI += "git://go.googlesource.com/oauth2;name=oauth2;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/golang.org/x/oauth2"
> +SRC_URI += "git://go.googlesource.com/oauth2;name=oauth2;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/golang.org/x/oauth2"
>
>  #       k8s.io/apimachinery v0.29.2
>  # [1] git ls-remote https://github.com/kubernetes/apimachinery dc7e034c86479d49be4b0eefad307621e10caa0e
>  SRCREV_apimachinery="dc7e034c86479d49be4b0eefad307621e10caa0e"
> -SRC_URI += "git://github.com/kubernetes/apimachinery;name=apimachinery;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/k8s.io/apimachinery"
> +SRC_URI += "git://github.com/kubernetes/apimachinery;name=apimachinery;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/k8s.io/apimachinery"
>
>  #       k8s.io/kube-openapi v0.0.0-20231010175941-2dd684a91f00
>  # [1] git ls-remote https://github.com/kubernetes/kube-openapi 2dd684a91f00351087fe2f4ed5408d4d2f3775ab
>  SRCREV_kube-openapi="2dd684a91f00351087fe2f4ed5408d4d2f3775ab"
> -SRC_URI += "git://github.com/kubernetes/kube-openapi;name=kube-openapi;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/k8s.io/kube-openapi"
> +SRC_URI += "git://github.com/kubernetes/kube-openapi;name=kube-openapi;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/k8s.io/kube-openapi"
>
>  #       github.com/moby/term v0.5.0
>  # [1] git ls-remote https://github.com/moby/term 9c3c875fad924eb6c9dd32a361b5fc0a49a4feb9
>  SRCREV_term="9c3c875fad924eb6c9dd32a361b5fc0a49a4feb9"
> -SRC_URI += "git://github.com/moby/term;name=term;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/github.com/moby/term"
> +SRC_URI += "git://github.com/moby/term;name=term;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/github.com/moby/term"
>
>  #       github.com/docker/go v1.5.1-1.0.20160303222718-d30aec9fd63c
>  # [1] git ls-remote https://github.com/docker/go d30aec9fd63c35133f8f79c3412ad91a3b08be06
>  SRCREV_go="d30aec9fd63c35133f8f79c3412ad91a3b08be06"
> -SRC_URI += "git://github.com/docker/go;name=go;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/github.com/docker/go"
> +SRC_URI += "git://github.com/docker/go;name=go;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/github.com/docker/go"
>
>  #       github.com/docker/cli v26.0.0+incompatible
>  # [1] git ls-remote https://github.com/docker/cli 2ae903e86cab51f694c819721cdfdf5eec693720
>  SRCREV_cli="2ae903e86cab51f694c819721cdfdf5eec693720"
> -SRC_URI += "git://github.com/docker/cli;name=cli;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/github.com/docker/cli"
> +SRC_URI += "git://github.com/docker/cli;name=cli;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/github.com/docker/cli"
>
>  #       github.com/r3labs/sse v0.0.0-20210224172625-26fe804710bc
>  # [1] git ls-remote https://github.com/r3labs/sse 26fe804710bc39ea7ea6636d36f27c438bd2c06f
>  SRCREV_sse="26fe804710bc39ea7ea6636d36f27c438bd2c06f"
> -SRC_URI += "git://github.com/r3labs/sse;name=sse;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/github.com/r3labs/sse"
> +SRC_URI += "git://github.com/r3labs/sse;name=sse;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/github.com/r3labs/sse"
>
>  #       github.com/mgutz/ansi v0.0.0-20170206155736-9520e82c474b
>  # [1] git ls-remote https://github.com/mgutz/ansi 9520e82c474b0a04dd04f8a40959027271bab992
>  SRCREV_ansi="9520e82c474b0a04dd04f8a40959027271bab992"
> -SRC_URI += "git://github.com/mgutz/ansi;name=ansi;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/github.com/mgutz/ansi"
> +SRC_URI += "git://github.com/mgutz/ansi;name=ansi;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/github.com/mgutz/ansi"
>
>  #       github.com/pkg/errors v0.9.1
>  # [1] git ls-remote https://github.com/pkg/errors 614d223910a179a466c1767a985424175c39b465
>  SRCREV_errors="614d223910a179a466c1767a985424175c39b465"
> -SRC_URI += "git://github.com/pkg/errors;name=errors;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/github.com/pkg/errors"
> +SRC_URI += "git://github.com/pkg/errors;name=errors;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/github.com/pkg/errors"
>
>  #       github.com/spf13/cobra v1.8.0
>  # [1] git ls-remote https://github.com/spf13/cobra a0a6ae020bb3899ff0276067863e50523f897370
>  SRCREV_cobra="a0a6ae020bb3899ff0276067863e50523f897370"
> -SRC_URI += "git://github.com/spf13/cobra;name=cobra;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/github.com/spf13/cobra"
> +SRC_URI += "git://github.com/spf13/cobra;name=cobra;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/github.com/spf13/cobra"
>
>  #       github.com/spf13/pflag v1.0.5
>  # [1] git ls-remote https://github.com/spf13/pflag 2e9d26c8c37aae03e3f9d4e90b7116f5accb7cab
>  SRCREV_pflag="2e9d26c8c37aae03e3f9d4e90b7116f5accb7cab"
> -SRC_URI += "git://github.com/spf13/pflag;name=pflag;protocol=https;nobranch=1;destsuffix=${WORKDIR}/${BP}/src/import/vendor.fetch/github.com/spf13/pflag"
> +SRC_URI += "git://github.com/spf13/pflag;name=pflag;protocol=https;nobranch=1;destsuffix=${GO_SRCURI_DESTSUFFIX}/vendor.fetch/github.com/spf13/pflag"
>
>  #       google.golang.org/grpc v1.59.0
>  # [1] git ls-remote https://github.com/grpc/grpc-go 7765221f4bf6104973db7946d56936cf838cad46
>  SRCREV_grpc="7765221f4bf6104973db7946d56936cf838cad46"
> -SRC_URI += "git://



-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


^ permalink raw reply	[relevance 1%]

* RE: Request for updating device dictionaries
  @ 2024-05-29 13:07  0%                 ` Chris Paterson
  0 siblings, 0 replies; 200+ results
From: Chris Paterson @ 2024-05-29 13:07 UTC (permalink / raw)
  To: Sai.Sathujoda; +Cc: cip-dev, kazuhiro3.hayashi

Hello Sai,

> From: Sai.Sathujoda@toshiba-tsip.com <Sai.Sathujoda@toshiba-tsip.com>
> Sent: Wednesday, May 29, 2024 1:56 AM
> 
> Hi Chris,
> 
> Thanks a lot for your support. I apologize for not including changes to
> install swtpm and ovmf packages to the slaves. Thank you for creating an
> MR for that.
> 
> I agree that we must work on this limitation that only one QEMU device
> will be able to run these jobs in each lab. The problem is if the image
> boots on a QEMU device in a lab, it acquires the below socket.
> 
> swtpm socket -d --tpmstate dir=/home/######/XXXXXX/isar-cip-
> core/build/tmp/deploy/images/qemu-amd64/cip-core-image-security-cip-core-
> bookworm-qemu-amd64.swtpm --ctrl type=unixio,path=/tmp/qemu-swtpm.sock --
> tpm2.
> 
> Then if the other QEMU device in that slave also starts booting, we will
> have some conflicts to due to which there are high chances that both the
> jobs can fail. Let me investigate on how to overcome this limitation and
> make the both the QEMU devices ready to run these swtpm related jobs.

Yes, it's a problem.
We'll also face problems when you start running this testing on non-qemu machines in addition.
I've not thought of a solution yet.

Chris

> 
> Thanks and regards,
> Sai Ashrith Sathujoda (T S I P)
> 
> 
> 
> -----Original Message-----
> From: Chris Paterson <Chris.Paterson2@renesas.com>
> Sent: Wednesday, May 29, 2024 4:43 AM
> To: ashrith sai(TSIP) <Sai.Sathujoda@toshiba-tsip.com>
> Cc: cip-dev@lists.cip-project.org; hayashi kazuhiro(林 和宏 DME
> ○DIG□MPS○MP4) <kazuhiro3.hayashi@toshiba.co.jp>
> Subject: RE: Request for updating device dictionaries
> 
> Hello Sai,
> 
> > From: Sai.Sathujoda@toshiba-tsip.com <Sai.Sathujoda@toshiba-tsip.com>
> > Sent: Tuesday, May 28, 2024 7:23 PM
> >
> > Hi Chris,
> >
> >
> >
> > Today while I was testing isar-cip-core LAVA job trigger pipeline, I
> > noticed that the one and only device (qemu-renesas-01) which has
> > custom device dictionary changes to use swtpm related scripts to boot
> > CIP security image are gone. LAVA | Scheduler | Devices |
> > qemu-renesas-01 | dictionary (ciplatform.org)
> > <https://lava.ciplatform.org/scheduler/device/qemu-renesas-01/devicedi
> > ct> . Because of this none of the QEMU devices present will be able to
> > test Swupdate, secure boot and IEC layer.
> >
> >
> >
> > Chris, I am about to send patches to isar-cip-core to trigger LAVA jobs.
> > For every pipeline it must run 11 jobs on CIP LAVA QEMU devices. So, I
> > request you to please update device dictionaries of only one QEMU
> > device in each lab so that we can have 3 to 4 QEMU devices able to run
> > CIP Core jobs and this also makes test stage runs faster in
> > isar-cip-core pipelines.
> >
> >
> >
> > I have already created an MR https://gitlab.com/cip-project/cip-
> > testing/lava-docker/-/merge_requests/35 <https://gitlab.com/cip-
> > project/cip-testing/lava-docker/-/merge_requests/35>  to include
> > required scripts in all CIP LAVA workers. I mentioned the reason why
> > we need to manually update the dictionaries instead of updating the
> > dictionaries of all the available QEMU devices here
> > https://gitlab.com/cip-project/cip-
> > testing/lava-docker/-/merge_requests/35#note_1921132805
> > <https://gitlab.com/cip-project/cip-testing/lava-docker/-
> > /merge_requests/35#note_1921132805>  . Please have a look at this.
> 
> I'm still not happy with the approach this MR is taking, but as you need
> this functionality working, I've merged it for now.
> I've created a follow up issue and assigned it to you to look at when you
> have time.
> 
> I've also created an additional MR to add the functionality missing from
> your own (we need to add packages to the LAVA slave Dockerfile).
> This too has been merged.
> 
> >
> >
> >
> > I request you to consider this as high priority because we are working
> > to enable this LAVA job triggers from isar-cip-core as soon as
> > possible. We will not be able to test if none of the QEMU devices are
> > able to run any of the CIP Core jobs.
> 
> Lab-cip-renesas and lab-patersonc have both been updated to the latest
> cip-lava-docker version.
> One qemu machine from each lab should now work okay for your testing, but
> please double check for me.
> 
> I will ask the other lab maintainers to make similar changes their end.
> Once done there will be four qemu devices available to you.
> 
> Kind regards, Chris
> 
> >
> >
> >
> > Thanks and regards,
> >
> > Sai Ashrith Sathujoda (T S I P)
> >
> >
> >
> > From: ashrith sai(TSIP)
> > Sent: Friday, May 24, 2024 1:15 PM
> > To: Chris Paterson <Chris.Paterson2@renesas.com>
> > Cc: cip-dev@lists.cip-project.org
> > Subject: RE: Request for updating device dictionaries
> >
> >
> >
> >
> >
> > Hi Chris,
> >
> >
> >
> > I updated the corresponding MR lava-slave/scripts: Add scripts needed
> > to run for booting CIP QEMU security target (!35) ・ Merge requests ・
> > cip- project / cip-testing / lava-docker ・ GitLab
> > <https://gitlab.com/cip-
> > project/cip-testing/lava-docker/-
> > /merge_requests/35?commit_id=6642a2390ead758ecbb8b096c62c4c5d4fd504b3>
> >
> >
> >
> > This MR only adds the scripts in the workers. Updating device
> > dictionaries on only one QEMU device in each worker has to be done
> manually.
> >
> >
> >
> > If you have further review comments, please provide them in the MR.
> >
> >
> >
> > Thanks and regards,
> >
> > Sai Ashrith Sathujoda (T S I P)
> >
> > From: Chris Paterson <Chris.Paterson2@renesas.com
> > <mailto:Chris.Paterson2@renesas.com> >
> > Sent: Thursday, May 23, 2024 8:04 PM
> > To: ashrith sai(TSIP) <Sai.Sathujoda@toshiba-tsip.com
> > <mailto:Sai.Sathujoda@toshiba-tsip.com> >
> > Cc: dinesh kumar(TSIP TMIEC ODG Porting)
> > <dinesh.kumar@toshiba-tsip.com <mailto:dinesh.kumar@toshiba-tsip.com>
> > >; hayashi kazuhiro(林 和宏 DME
> > ○DIG□MPS○MP4) <kazuhiro3.hayashi@toshiba.co.jp
> > <mailto:kazuhiro3.hayashi@toshiba.co.jp> >; jan.kiszka@siemens.com
> > <mailto:jan.kiszka@siemens.com>
> > Subject: RE: Request for updating device dictionaries
> >
> >
> >
> > Hello Sai,
> >
> >
> >
> > I can update the device dictionaries, however each lab would need to
> > update it’s worker docker image to include the swtpm*.sh scripts.
> >
> > Before we do this, we should really finish and merge the corresponding
> MR:
> > https://gitlab.com/cip-project/cip-testing/lava-docker/-
> > /merge_requests/35/ <https://gitlab.com/cip-project/cip-testing/lava-
> > docker/-/merge_requests/35/>
> >
> > Please could you check the remaining threads?
> >
> > Once merged I’ll ask for each of the workers to be upgraded (I only
> > have access to my own worker).
> >
> >
> >
> > I’ll remove the swtpm-jobs tags I added the other day, so at least
> > your pipelines don’t fail ? they’ll just run slower.
> >
> >
> >
> > Thanks, Chris
> >
> >
> >
> > From: Sai.Sathujoda@toshiba-tsip.com <mailto:Sai.Sathujoda@toshiba-
> > tsip.com>  <Sai.Sathujoda@toshiba-tsip.com
> > <mailto:Sai.Sathujoda@toshiba- tsip.com> >
> > Sent: Tuesday, May 21, 2024 12:05 PM
> > To: Chris Paterson <Chris.Paterson2@renesas.com
> > <mailto:Chris.Paterson2@renesas.com> >
> > Cc: dinesh.kumar@toshiba-tsip.com
> > <mailto:dinesh.kumar@toshiba-tsip.com> ;
> > kazuhiro3.hayashi@toshiba.co.jp
> > <mailto:kazuhiro3.hayashi@toshiba.co.jp> ; jan.kiszka@siemens.com
> > <mailto:jan.kiszka@siemens.com>
> > Subject: RE: Request for updating device dictionaries
> >
> >
> >
> > Hi Chris,
> >
> >
> >
> > Thank you so much for adding the tags to one qemu for each worker. But
> > the device dictionaries for these tagged devices need to be updated
> > with the below snippet. Without these changes we cannot boot the
> > security image in LAVA.
> >
> >
> >
> > {% set user_commands = {'start_tpm': {'do':'"/usr/bin/sh
> > /usr/local/bin/swtpm_start.sh"',
> >
> >
> >
> >                                       'undo':'"/usr/bin/sh
> > /usr/local/bin/swtpm_finish.sh"' },
> >
> >
> >
> >                         'manual_kill': {'do':'"/usr/bin/pkill -15
> > swtpm"'}} %}
> >
> >
> >
> > Just like it is updated for this device LAVA | Scheduler | Devices |
> > qemu-
> > renesas-01 | dictionary (ciplatform.org)
> > <https://lava.ciplatform.org/scheduler/device/qemu-renesas-01/devicedi
> > ct>
> > .
> >
> >
> >
> > Can you kindly update the device dictionaries for the below “swtpm-jobs”
> > tagged devices ?
> >
> >
> >
> > *	https://lava.ciplatform.org/scheduler/device/qemu-03
> > *	https://lava.ciplatform.org/scheduler/device/qemu-cip-siemens-muc
> > *	https://lava.ciplatform.org/scheduler/device/qemu-patersonc-01
> >
> >
> >
> > I will contact the maintainers of isar-cip-core project regarding
> > CI/CD variables.
> >
> >
> >
> > Thanks and regards,
> >
> > Sai Ashrith Sathujoda (T S I P)
> >
> >
> >
> >
> >
> >
> >
> > From: Chris Paterson <Chris.Paterson2@renesas.com
> > <mailto:Chris.Paterson2@renesas.com> >
> > Sent: Tuesday, May 21, 2024 4:24 PM
> > To: ashrith sai(TSIP) <Sai.Sathujoda@toshiba-tsip.com
> > <mailto:Sai.Sathujoda@toshiba-tsip.com> >
> > Cc: dinesh kumar(TSIP TMIEC ODG Porting)
> > <dinesh.kumar@toshiba-tsip.com <mailto:dinesh.kumar@toshiba-tsip.com>
> > >; hayashi kazuhiro(林 和宏 DME
> > ○DIG□MPS○MP4) <kazuhiro3.hayashi@toshiba.co.jp
> > <mailto:kazuhiro3.hayashi@toshiba.co.jp> >; jan.kiszka@siemens.com
> > <mailto:jan.kiszka@siemens.com>
> > Subject: RE: Request for updating device dictionaries
> >
> >
> >
> > Hello Sai,
> >
> >
> >
> > You need to talk to the maintainers of the isar-cip-core project to
> > get CI/CD variables set there. It’s not my project so I shouldn’t make
> > such changes.
> >
> >
> >
> > I’ve added the swtpm-jobs tag to one qemu from each worker. Check the
> > “green eye” on the right of this page:
> > https://lava.ciplatform.org/scheduler/device_type/qemu
> > <https://lava.ciplatform.org/scheduler/device_type/qemu>
> >
> >
> >
> > Kind regards, Chris
> >
> >
> >
> > From: Sai.Sathujoda@toshiba-tsip.com <mailto:Sai.Sathujoda@toshiba-
> > tsip.com>  <Sai.Sathujoda@toshiba-tsip.com
> > <mailto:Sai.Sathujoda@toshiba- tsip.com> >
> > Sent: Monday, May 20, 2024 11:23 AM
> > To: Chris Paterson <Chris.Paterson2@renesas.com
> > <mailto:Chris.Paterson2@renesas.com> >
> > Cc: cip-dev@lists.cip-project.org
> > <mailto:cip-dev@lists.cip-project.org> ; dinesh.kumar@toshiba-tsip.com
> > <mailto:dinesh.kumar@toshiba-tsip.com> ;
> > kazuhiro3.hayashi@toshiba.co.jp
> > <mailto:kazuhiro3.hayashi@toshiba.co.jp>
> > Subject: RE: Request for updating device dictionaries
> >
> >
> >
> > Hello Chris,
> >
> >
> >
> > Any updates on 2nd and 3rd requests I made in the below mail ?
> >
> >
> >
> > Thanks and regards,
> >
> > Sai Ashrith Sathujoda (T S I P)
> >
> >
> >
> > From: ashrith sai(TSIP)
> > Sent: Wednesday, May 15, 2024 4:41 PM
> > To: Chris Paterson <Chris.Paterson2@renesas.com
> > <mailto:Chris.Paterson2@renesas.com> >
> > Cc: cip-dev@lists.cip-project.org
> > <mailto:cip-dev@lists.cip-project.org> ; dinesh kumar(TSIP TMIEC ODG
> > Porting) <dinesh.kumar@toshiba-tsip.com
> > <mailto:dinesh.kumar@toshiba-tsip.com> >; hayashi kazuhiro(林 和宏 DME
> > ○DIG□MPS○MP4) <kazuhiro3.hayashi@toshiba.co.jp
> > <mailto:kazuhiro3.hayashi@toshiba.co.jp> >
> > Subject: Request for updating device dictionaries
> >
> >
> >
> > Hello Chris,
> >
> >
> >
> > Hope you are doing well.
> >
> >
> >
> > Sorry to disturb you with these extra things I need on CIP LAVA Lab.
> > Let me consolidate my requests in this mail.
> >
> >
> >
> > I am preparing a patch to trigger LAVA job definitions from isar-cip-
> core.
> > Currently I am working on that in a custom branch. Before sending that
> > patch, I have created an MR to update the cip-core-ci repository which
> > is required to run the test jobs in isar-cip-core. I will assign it
> > for your review soon.
> >
> >
> >
> > I will be able to send the patch to add test jobs in isar-cip-core
> > once the below mentioned things are done.
> >
> > 1.	This MR needs to merge build-bookworm.Dockerfile: Include lava.sh
> > and templates in the docker image. (!3) ・ Merge requests ・
> > cip-playground / cip-core-ci ・ GitLab
> > <https://gitlab.com/cip-playground/cip-core-ci/-
> > /merge_requests/3>  which I shall assign to you soon after some
> > internal review.
> > 2.	I need some variables in isar-cip-core CI/CD setting section like
> > LAVA_USER, LAVA_TOKEN and SQUAD_TOKEN. We don’t have the privilege to
> > do that. I will mail them to you personally. Please hide them in
> > isar-cip- core Gitlab CI/CD section so that I can use them while
> > running lava.sh script.
> > 3.	Since we need to run these LAVA jobs when pipelines are triggered in
> > isar-cip-core, I am making changes in such a way that pipeline keeps
> > running until all the jobs are done and we report the health as a
> result.
> > It will take around 120 mins to run all the jobs. We have only device
> > (qemu-renesa-01) under lab-cip-renesas. So, I request you to please
> > add the swtpm device dictionary changes and swtpm-jobs tag to only one
> > QEMU device in every LAVA lab you can access. By this will be able to
> > reduce the pipeline run-time due to simultaneous runs.
> >
> >
> >
> > It will be very helpful if you provide your support with the above-
> > mentioned items.
> >
> >
> >
> > Thanks and regards,
> >
> > Sai Ashrith Sathujoda (T S I P)
> 



^ permalink raw reply	[relevance 0%]

* [PATCH V1 1/5] dt-bindings: input: Add YAML to Awinic sar sensor.
  @ 2024-05-29 13:06  3% ` wangshuaijie
  2024-05-29 13:06  2% ` [PATCH V1 2/5] Add universal interface for the aw_sar driver wangshuaijie
  2024-05-29 13:06  2% ` [PATCH V1 5/5] Add support for Awinic sar sensor wangshuaijie
  2 siblings, 0 replies; 200+ results
From: wangshuaijie @ 2024-05-29 13:06 UTC (permalink / raw)
  To: dmitry.torokhov, robh, krzk+dt, conor+dt, jeff, linux-input,
	devicetree, linux-kernel
  Cc: wangshuaijie, liweilei, kangjiajun

From: shuaijie wang <wangshuaijie@awinic.com>

Add the awinic,aw_sar.yaml file to adapt to the awinic sar sensor driver.

Signed-off-by: shuaijie wang <wangshuaijie@awinic.com>
---
 .../bindings/input/awinic,aw_sar.yaml         | 110 ++++++++++++++++++
 1 file changed, 110 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/awinic,aw_sar.yaml

diff --git a/Documentation/devicetree/bindings/input/awinic,aw_sar.yaml b/Documentation/devicetree/bindings/input/awinic,aw_sar.yaml
new file mode 100644
index 000000000000..ed4ec29c9b4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/awinic,aw_sar.yaml
@@ -0,0 +1,110 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/awinic,aw_sar.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Awinic sar sensor driver family
+
+maintainers:
+  - Shuaijie Wang <wangshuaijie@awinic.com>
+
+properties:
+  compatible:
+    enum:
+      - awinic,aw_aw96103
+      - awinic,aw_aw96105
+      - awinic,aw_aw96303
+      - awinic,aw_aw96305
+      - awinic,aw_aw96308
+
+  reg:
+    maxItems: 1
+
+  interrupts:
+    maxItems: 1
+
+  sar-num:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      set the index of the sar sensor.
+
+  vcc0-supply:
+    description:
+      Optional regulator for chip, 1.7V-3.6V.
+
+  channel_use_flag:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      The flag of channels used.
+      Configure according to the specific chip channel used.
+      Bit[31:0] Each bit represents a channel.
+      If the customer uses ch0 and ch2, then channel_use_flag=<0x05>
+
+  aw_sar,update_fw:
+    type: boolean
+    description:
+      Choose if you want to update the firmware.
+
+  aw_sar,monitor_esd:
+    type: boolean
+    description:
+      Choose if you want to monitor ESD.
+
+  aw_sar,pin_set_inter_pull-up:
+    type: boolean
+    description:
+      Choose if you want to set the interrupt pin to internal pull-up.
+
+  aw_sar,using_pm_ops:
+    type: boolean
+    description:
+      Choose if you want to use suspend and resume related function.
+
+  aw_sar,use_plug_cail:
+    type: boolean
+    description:
+      Choose If you want to perform calibration when plugging and unplugging the charger.
+
+  start-mode:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      When connecting to aw963xx, select the location where the firmware starts.
+      set 0 if start in rom.
+      set 1 if start in ram
+
+  irq-mux:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description:
+      set csx as irq pin. config this field when connect to aw96308/aw96305BFOR
+
+required:
+  - compatible
+  - reg
+  - sar-num
+  - interrupts
+  - channel_use_flag
+
+unevaluatedProperties: false
+
+examples:
+  - |
+    #include <dt-bindings/gpio/gpio.h>
+    #include <dt-bindings/interrupt-controller/irq.h>
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        awinic_sar@12 {
+            compatible = "awinic,aw_sar";
+            reg = <0x12>;
+            sar-num = < 0 >;
+            interrupt-parent = < &tlmm >;
+            interrupts = <72 0>;
+            //vcc0-supply = <&pm660l_l4>;
+            channel_use_flag = <0xff>;
+            aw_sar,update_fw;
+            //aw_sar,monitor_esd;
+            start-mode = < 1 >;
+            irq-mux = < 2 >;
+        };
+    };
-- 
2.45.1


^ permalink raw reply related	[relevance 3%]

* [PATCH V1 2/5] Add universal interface for the aw_sar driver.
    2024-05-29 13:06  3% ` [PATCH V1 1/5] dt-bindings: input: Add YAML to Awinic sar sensor wangshuaijie
@ 2024-05-29 13:06  2% ` wangshuaijie
  2024-05-29 13:06  2% ` [PATCH V1 5/5] Add support for Awinic sar sensor wangshuaijie
  2 siblings, 0 replies; 200+ results
From: wangshuaijie @ 2024-05-29 13:06 UTC (permalink / raw)
  To: dmitry.torokhov, robh, krzk+dt, conor+dt, jeff, linux-input,
	devicetree, linux-kernel
  Cc: wangshuaijie, liweilei, kangjiajun

From: shuaijie wang <wangshuaijie@awinic.com>

Add i2c read-write interfaces and interfaces for parsing bin files.

Signed-off-by: shuaijie wang <wangshuaijie@awinic.com>
---
 .../misc/aw_sar/comm/aw_sar_chip_interface.h  |  27 +
 .../misc/aw_sar/comm/aw_sar_comm_interface.c  | 656 ++++++++++++++++++
 .../misc/aw_sar/comm/aw_sar_comm_interface.h  | 172 +++++
 drivers/input/misc/aw_sar/comm/aw_sar_type.h  | 396 +++++++++++
 4 files changed, 1251 insertions(+)
 create mode 100644 drivers/input/misc/aw_sar/comm/aw_sar_chip_interface.h
 create mode 100644 drivers/input/misc/aw_sar/comm/aw_sar_comm_interface.c
 create mode 100644 drivers/input/misc/aw_sar/comm/aw_sar_comm_interface.h
 create mode 100644 drivers/input/misc/aw_sar/comm/aw_sar_type.h

diff --git a/drivers/input/misc/aw_sar/comm/aw_sar_chip_interface.h b/drivers/input/misc/aw_sar/comm/aw_sar_chip_interface.h
new file mode 100644
index 000000000000..d406e48e8136
--- /dev/null
+++ b/drivers/input/misc/aw_sar/comm/aw_sar_chip_interface.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef _SAR_SUPPORT_CHIP_H_
+#define _SAR_SUPPORT_CHIP_H_
+#include "aw_sar_type.h"
+
+enum aw_sar_driver_list_t {
+	AW_SAR_AW9610X,
+	AW_SAR_AW963XX,
+
+	AW_SAR_DRIVER_MAX,
+};
+
+int32_t aw9610x_check_chipid(void *data);
+int32_t aw9610x_init(struct aw_sar *p_sar);
+void aw9610x_deinit(struct aw_sar *p_sar);
+
+int32_t aw963xx_check_chipid(void *data);
+int32_t aw963xx_init(struct aw_sar *p_sar);
+void aw963xx_deinit(struct aw_sar *p_sar);
+
+
+static const struct aw_sar_driver_type g_aw_sar_driver_list[] = {
+	{ AW_SAR_AW9610X, aw9610x_check_chipid, aw9610x_init, aw9610x_deinit },
+	{ AW_SAR_AW963XX, aw963xx_check_chipid, aw963xx_init, aw963xx_deinit },
+};
+
+#endif
diff --git a/drivers/input/misc/aw_sar/comm/aw_sar_comm_interface.c b/drivers/input/misc/aw_sar/comm/aw_sar_comm_interface.c
new file mode 100644
index 000000000000..1d62ebb60acc
--- /dev/null
+++ b/drivers/input/misc/aw_sar/comm/aw_sar_comm_interface.c
@@ -0,0 +1,656 @@
+// SPDX-License-Identifier: GPL-2.0
+#include "aw_sar_comm_interface.h"
+
+#define AW_I2C_RW_RETRY_TIME_MIN		(2000)
+#define AW_I2C_RW_RETRY_TIME_MAX		(3000)
+#define AW_RETRIES				(5)
+
+static int32_t awinic_i2c_write(struct i2c_client *i2c, uint8_t *tr_data, uint16_t len)
+{
+	struct i2c_msg msg;
+
+	msg.addr = i2c->addr;
+	msg.flags = 0;
+	msg.len = len;
+	msg.buf = tr_data;
+
+	return i2c_transfer(i2c->adapter, &msg, 1);
+}
+
+static int32_t awinic_i2c_read(struct i2c_client *i2c, uint8_t *addr,
+				uint8_t addr_len, uint8_t *data, uint16_t data_len)
+{
+	struct i2c_msg msg[2];
+
+	msg[0].addr = i2c->addr;
+	msg[0].flags = 0;
+	msg[0].len = addr_len;
+	msg[0].buf = addr;
+
+	msg[1].addr = i2c->addr;
+	msg[1].flags = 1;
+	msg[1].len = data_len;
+	msg[1].buf = data;
+
+	return i2c_transfer(i2c->adapter, msg, 2);
+}
+
+/**
+ * @brief Read register interface
+ *
+ * @param i2c: i2c client.
+ * @param reg_addr16: 16 bit register address.
+ * @param *reg_data32: 32 bit register data.
+ * @return 0 if init succeeded.
+ */
+int32_t aw_sar_i2c_read(struct i2c_client *i2c, uint16_t reg_addr16,  uint32_t *reg_data32)
+{
+	uint8_t r_buf[6] = { 0 };
+	int8_t cnt = 5;
+	int32_t ret;
+
+	if (!i2c)
+		return -EINVAL;
+
+	r_buf[0] = (unsigned char)(reg_addr16 >> OFFSET_BIT_8);
+	r_buf[1] = (unsigned char)(reg_addr16);
+
+	do {
+		ret = awinic_i2c_read(i2c, r_buf, 2, &r_buf[2], 4);
+		if (ret < 0)
+			dev_err(&i2c->dev, "i2c read error reg: 0x%04x, ret= %d cnt= %d",
+					reg_addr16, ret, cnt);
+		else
+			break;
+		usleep_range(2000, 3000);
+	} while (cnt--);
+
+	if (cnt < 0) {
+		dev_err(&i2c->dev, "i2c read error!");
+		return ret;
+	}
+
+	*reg_data32 = ((uint32_t)r_buf[5] << OFFSET_BIT_0) | ((uint32_t)r_buf[4] << OFFSET_BIT_8) |
+		      ((uint32_t)r_buf[3] << OFFSET_BIT_16) | ((uint32_t)r_buf[2] << OFFSET_BIT_24);
+
+	return 0;
+}
+
+/**
+ * @brief write register interface
+ *
+ * @param i2c: i2c client.
+ * @param reg_addr16: 16 bit register address.
+ * @param reg_data32: 32 bit register data.
+ * @return 0 if init succeeded.
+ */
+int32_t aw_sar_i2c_write(struct i2c_client *i2c, uint16_t reg_addr16, uint32_t reg_data32)
+{
+	uint8_t w_buf[6] = { 0 };
+	int8_t cnt = 5;
+	int32_t ret;
+
+	if (!i2c)
+		return -EINVAL;
+
+	/*reg_addr*/
+	w_buf[0] = (uint8_t)(reg_addr16 >> OFFSET_BIT_8);
+	w_buf[1] = (uint8_t)(reg_addr16);
+	/*data*/
+	w_buf[2] = (uint8_t)(reg_data32 >> OFFSET_BIT_24);
+	w_buf[3] = (uint8_t)(reg_data32 >> OFFSET_BIT_16);
+	w_buf[4] = (uint8_t)(reg_data32 >> OFFSET_BIT_8);
+	w_buf[5] = (uint8_t)(reg_data32);
+
+	do {
+		ret = awinic_i2c_write(i2c, w_buf, ARRAY_SIZE(w_buf));
+		if (ret < 0) {
+			dev_err(&i2c->dev,
+					"i2c write error reg: 0x%04x data: 0x%08x, ret= %d cnt= %d",
+					reg_addr16, reg_data32, ret, cnt);
+		} else {
+			break;
+		}
+	} while (cnt--);
+
+	if (cnt < 0) {
+		dev_err(&i2c->dev, "i2c write error!");
+		return ret;
+	}
+
+	return 0;
+}
+
+/**
+ * @brief Write the corresponding bit of the register
+ *
+ * @param i2c:i2c client.
+ * @param reg_addr16: 16 bit register address.
+ * @param mask: Write the corresponding bit as 0
+ * @param val: Write corresponding data to the register
+ * @return 0 if init succeeded.
+ */
+int32_t
+aw_sar_i2c_write_bits(struct i2c_client *i2c, uint16_t reg_addr16, uint32_t mask, uint32_t val)
+{
+	uint32_t reg_val;
+
+	aw_sar_i2c_read(i2c, reg_addr16, &reg_val);
+	reg_val &= mask;
+	reg_val |= (val & (~mask));
+	aw_sar_i2c_write(i2c, reg_addr16, reg_val);
+
+	return 0;
+}
+
+/**
+ * @brief Continuously write data to the chip
+ *
+ * @param i2c:i2c client.
+ * @param *tr_data: Data written
+ * @param len: Length of data written
+ * @return 0 if init succeeded.
+ */
+int32_t aw_sar_i2c_write_seq(struct i2c_client *i2c, uint8_t *tr_data, uint16_t len)
+{
+	int8_t cnt = AW_RETRIES;
+	int32_t ret;
+
+	do {
+		ret = awinic_i2c_write(i2c, tr_data, len);
+		if (ret < 0)
+			dev_err(&i2c->dev, "awinic i2c write seq error %d", ret);
+		else
+			break;
+		usleep_range(AW_I2C_RW_RETRY_TIME_MIN, AW_I2C_RW_RETRY_TIME_MAX);
+	} while (cnt--);
+
+	if (cnt < 0) {
+		dev_err(&i2c->dev, "awinic i2c write error!");
+		return ret;
+	}
+
+	return 0;
+}
+
+/**
+ * @brief Continuously Read data from chip
+ *
+ * @param i2c:i2c client.
+ * @param *addr: Read address
+ * @param addr_len: Length of read address (byte)
+ * @param *data: Data written
+ * @param data_len: Length of data written
+ * @return 0 if init succeeded.
+ */
+int32_t aw_sar_i2c_read_seq(struct i2c_client *i2c, uint8_t *addr,
+				uint8_t addr_len, uint8_t *data, uint16_t data_len)
+{
+	int8_t cnt = AW_RETRIES;
+	int32_t ret;
+
+	do {
+		ret = awinic_i2c_read(i2c, addr, addr_len, data, data_len);
+		if (ret < 0)
+			dev_err(&i2c->dev, "awinic sar i2c write error %d", ret);
+		else
+			break;
+		usleep_range(AW_I2C_RW_RETRY_TIME_MIN, AW_I2C_RW_RETRY_TIME_MAX);
+	} while (cnt--);
+
+	if (cnt < 0) {
+		dev_err(&i2c->dev, "awinic sar i2c read error!");
+		return ret;
+	}
+
+	return 0;
+}
+
+/******************************Parse bin file code start****************************************/
+
+#define AWINIC_CODE_VERSION "V0.0.7-V1.0.4"  /* "code version"-"excel version" */
+
+enum bin_header_version_enum {
+	HEADER_VERSION_1_0_0 = 0x01000000,
+};
+
+enum data_type_enum {
+	DATA_TYPE_REGISTER = 0x00000000,
+	DATA_TYPE_DSP_REG = 0x00000010,
+	DATA_TYPE_DSP_CFG = 0x00000011,
+	DATA_TYPE_SOC_REG = 0x00000020,
+	DATA_TYPE_SOC_APP = 0x00000021,
+	DATA_TYPE_MULTI_BINS = 0x00002000,
+};
+
+#define BigLittleSwap16(A)	((((unsigned short int)(A) & 0xff00) >> 8) | \
+				(((unsigned short int)(A) & 0x00ff) << 8))
+
+#define BigLittleSwap32(A)	((((unsigned long)(A) & 0xff000000) >> 24) | \
+				(((unsigned long)(A) & 0x00ff0000) >> 8) | \
+				(((unsigned long)(A) & 0x0000ff00) << 8) | \
+				(((unsigned long)(A) & 0x000000ff) << 24))
+
+static int aw_parse_bin_header_1_0_0(struct aw_bin *bin);
+
+/**
+ *
+ * Interface function
+ *
+ * return value:
+ *       value = 0 :success;
+ *       value = -1 :check bin header version
+ *       value = -2 :check bin data type
+ *       value = -3 :check sum or check bin data len error
+ *       value = -4 :check data version
+ *       value = -5 :check register num
+ *       value = -6 :check dsp reg num
+ *       value = -7 :check soc app num
+ *       value = -8 :bin is NULL point
+ *
+ **/
+
+/********************************************************
+ *
+ * check sum data
+ *
+ ********************************************************/
+static enum aw_bin_err_val aw_check_sum(struct aw_bin *bin, int bin_num)
+{
+	unsigned char *p_check_sum;
+	unsigned int sum_data = 0;
+	unsigned int check_sum;
+	unsigned int i;
+
+	p_check_sum = &(bin->info.data[(bin->header_info[bin_num].valid_data_addr -
+			bin->header_info[bin_num].header_len)]);
+	check_sum = AW_SAR_GET_32_DATA(*(p_check_sum + 3), *(p_check_sum + 2),
+				*(p_check_sum + 1), *(p_check_sum));
+
+	for (i = 4; i < bin->header_info[bin_num].bin_data_len +
+			bin->header_info[bin_num].header_len; i++)
+		sum_data += *(p_check_sum + i);
+
+	if (sum_data != check_sum) {
+		p_check_sum = NULL;
+		return AW_BIN_ERROR_SUM_OR_DATA_LEN;
+	}
+	p_check_sum = NULL;
+
+	return AW_BIN_ERROR_NONE;
+}
+
+static enum aw_bin_err_val aw_check_register_num_v1(struct aw_bin *bin, int bin_num)
+{
+	unsigned int check_register_num;
+	unsigned int parse_register_num;
+	char *p_check_sum;
+
+	p_check_sum =
+	    &(bin->info.data[(bin->header_info[bin_num].valid_data_addr)]);
+	parse_register_num = AW_SAR_GET_32_DATA(*(p_check_sum + 3), *(p_check_sum + 2),
+					*(p_check_sum + 1), *(p_check_sum));
+	check_register_num = (bin->header_info[bin_num].bin_data_len - 4) /
+				(bin->header_info[bin_num].reg_byte_len +
+				bin->header_info[bin_num].data_byte_len);
+	if (parse_register_num != check_register_num) {
+		p_check_sum = NULL;
+		return AW_BIN_ERROR_REGISTER_NUM;
+	}
+	bin->header_info[bin_num].reg_num = parse_register_num;
+	bin->header_info[bin_num].valid_data_len = bin->header_info[bin_num].bin_data_len - 4;
+	p_check_sum = NULL;
+	bin->header_info[bin_num].valid_data_addr =
+	    bin->header_info[bin_num].valid_data_addr + 4;
+
+	return AW_BIN_ERROR_NONE;
+}
+
+static enum aw_bin_err_val aw_check_dsp_reg_num_v1(struct aw_bin *bin, int bin_num)
+{
+	unsigned int check_dsp_reg_num;
+	unsigned int parse_dsp_reg_num;
+	char *p_check_sum;
+
+	p_check_sum =
+	    &(bin->info.data[(bin->header_info[bin_num].valid_data_addr)]);
+	parse_dsp_reg_num = AW_SAR_GET_32_DATA(*(p_check_sum + 7),
+					*(p_check_sum + 6),
+					*(p_check_sum + 5),
+					*(p_check_sum + 4));
+	bin->header_info[bin_num].reg_data_byte_len =
+	    AW_SAR_GET_32_DATA(*(p_check_sum + 11), *(p_check_sum + 10),
+			*(p_check_sum + 9), *(p_check_sum + 8));
+	check_dsp_reg_num = (bin->header_info[bin_num].bin_data_len -
+				12) / bin->header_info[bin_num].reg_data_byte_len;
+	if (parse_dsp_reg_num != check_dsp_reg_num) {
+		p_check_sum = NULL;
+		return AW_BIN_ERROR_DSP_REG_NUM;
+	}
+	bin->header_info[bin_num].download_addr =
+	    AW_SAR_GET_32_DATA(*(p_check_sum + 3), *(p_check_sum + 2),
+			*(p_check_sum + 1), *(p_check_sum));
+	bin->header_info[bin_num].reg_num = parse_dsp_reg_num;
+	bin->header_info[bin_num].valid_data_len = bin->header_info[bin_num].bin_data_len - 12;
+	p_check_sum = NULL;
+	bin->header_info[bin_num].valid_data_addr =
+	    bin->header_info[bin_num].valid_data_addr + 12;
+
+	return AW_BIN_ERROR_NONE;
+}
+
+static enum aw_bin_err_val aw_check_soc_app_num_v1(struct aw_bin *bin, int bin_num)
+{
+	unsigned int check_soc_app_num;
+	unsigned int parse_soc_app_num;
+	char *p_check_sum;
+
+	p_check_sum = &(bin->info.data[(bin->header_info[bin_num].valid_data_addr)]);
+	bin->header_info[bin_num].app_version = AW_SAR_GET_32_DATA(*(p_check_sum + 3),
+							    *(p_check_sum + 2),
+							    *(p_check_sum + 1),
+							    *(p_check_sum));
+	parse_soc_app_num = AW_SAR_GET_32_DATA(*(p_check_sum + 11), *(p_check_sum + 10),
+					*(p_check_sum + 9), *(p_check_sum + 8));
+	check_soc_app_num = bin->header_info[bin_num].bin_data_len - 12;
+	if (parse_soc_app_num != check_soc_app_num) {
+		p_check_sum = NULL;
+		return AW_BIN_ERROR_SOC_APP_NUM;
+	}
+	bin->header_info[bin_num].reg_num = parse_soc_app_num;
+	bin->header_info[bin_num].download_addr =
+	    AW_SAR_GET_32_DATA(*(p_check_sum + 7), *(p_check_sum + 6),
+			*(p_check_sum + 5), *(p_check_sum + 4));
+	bin->header_info[bin_num].valid_data_len =
+	    bin->header_info[bin_num].bin_data_len - 12;
+	p_check_sum = NULL;
+	bin->header_info[bin_num].valid_data_addr =
+	    bin->header_info[bin_num].valid_data_addr + 12;
+
+	return AW_BIN_ERROR_NONE;
+}
+
+/************************
+ *
+ ***bin header 1_0_0
+ ***
+ ************************/
+static void aw_get_single_bin_header_1_0_0(struct aw_bin *bin)
+{
+	int i;
+
+	bin->header_info[bin->all_bin_parse_num].header_len = 60;
+	bin->header_info[bin->all_bin_parse_num].check_sum =
+	    AW_SAR_GET_32_DATA(*(bin->p_addr + 3), *(bin->p_addr + 2),
+			*(bin->p_addr + 1), *(bin->p_addr));
+	bin->header_info[bin->all_bin_parse_num].header_ver =
+	    AW_SAR_GET_32_DATA(*(bin->p_addr + 7), *(bin->p_addr + 6),
+			*(bin->p_addr + 5), *(bin->p_addr + 4));
+	bin->header_info[bin->all_bin_parse_num].bin_data_type =
+	    AW_SAR_GET_32_DATA(*(bin->p_addr + 11), *(bin->p_addr + 10),
+			*(bin->p_addr + 9), *(bin->p_addr + 8));
+	bin->header_info[bin->all_bin_parse_num].bin_data_ver =
+	    AW_SAR_GET_32_DATA(*(bin->p_addr + 15), *(bin->p_addr + 14),
+			*(bin->p_addr + 13), *(bin->p_addr + 12));
+	bin->header_info[bin->all_bin_parse_num].bin_data_len =
+	    AW_SAR_GET_32_DATA(*(bin->p_addr + 19), *(bin->p_addr + 18),
+			*(bin->p_addr + 17), *(bin->p_addr + 16));
+	bin->header_info[bin->all_bin_parse_num].ui_ver =
+	    AW_SAR_GET_32_DATA(*(bin->p_addr + 23), *(bin->p_addr + 22),
+			*(bin->p_addr + 21), *(bin->p_addr + 20));
+	bin->header_info[bin->all_bin_parse_num].reg_byte_len =
+	    AW_SAR_GET_32_DATA(*(bin->p_addr + 35), *(bin->p_addr + 34),
+			*(bin->p_addr + 33), *(bin->p_addr + 32));
+	bin->header_info[bin->all_bin_parse_num].data_byte_len =
+	    AW_SAR_GET_32_DATA(*(bin->p_addr + 39), *(bin->p_addr + 38),
+			*(bin->p_addr + 37), *(bin->p_addr + 36));
+	bin->header_info[bin->all_bin_parse_num].device_addr =
+	    AW_SAR_GET_32_DATA(*(bin->p_addr + 43), *(bin->p_addr + 42),
+			*(bin->p_addr + 41), *(bin->p_addr + 40));
+	for (i = 0; i < 8; i++) {
+		bin->header_info[bin->all_bin_parse_num].chip_type[i] =
+		    *(bin->p_addr + 24 + i);
+	}
+//	bin->header_info[bin->all_bin_parse_num].chip_type[i] = '\0';
+//	DBG("enter chip_type is %s\n", bin->header_info[bin->all_bin_parse_num].chip_type);
+
+	bin->header_info[bin->all_bin_parse_num].reg_num = 0x00000000;
+	bin->header_info[bin->all_bin_parse_num].reg_data_byte_len = 0x00000000;
+	bin->header_info[bin->all_bin_parse_num].download_addr = 0x00000000;
+	bin->header_info[bin->all_bin_parse_num].app_version = 0x00000000;
+	bin->header_info[bin->all_bin_parse_num].valid_data_len = 0x00000000;
+	bin->all_bin_parse_num += 1;
+}
+
+static enum aw_bin_err_val aw_parse_each_of_multi_bins_1_0_0(unsigned int bin_num,
+		int bin_serial_num, struct aw_bin *bin)
+{
+	unsigned int bin_start_addr;
+	unsigned int valid_data_len;
+	enum aw_bin_err_val ret;
+
+	if (!bin_serial_num) {
+		bin_start_addr = AW_SAR_GET_32_DATA(*(bin->p_addr + 67),
+					     *(bin->p_addr + 66),
+					     *(bin->p_addr + 65),
+					     *(bin->p_addr + 64));
+		bin->p_addr += (60 + bin_start_addr);
+		bin->header_info[bin->all_bin_parse_num].valid_data_addr =
+		    bin->header_info[bin->all_bin_parse_num -
+				     1].valid_data_addr + 4 + 8 * bin_num + 60;
+	} else {
+		valid_data_len =
+		    bin->header_info[bin->all_bin_parse_num - 1].bin_data_len;
+		bin->p_addr += (60 + valid_data_len);
+		bin->header_info[bin->all_bin_parse_num].valid_data_addr =
+		    bin->header_info[bin->all_bin_parse_num -
+				     1].valid_data_addr +
+		    bin->header_info[bin->all_bin_parse_num - 1].bin_data_len +
+		    60;
+	}
+
+	ret = aw_parse_bin_header_1_0_0(bin);
+	return ret;
+}
+
+/* Get the number of bins in multi bins, and set a for loop, loop processing each bin data */
+static enum aw_bin_err_val aw_get_multi_bin_header_1_0_0(struct aw_bin *bin)
+{
+	unsigned int bin_num;
+	enum aw_bin_err_val ret;
+	int i;
+
+	bin_num = AW_SAR_GET_32_DATA(*(bin->p_addr + 63),
+			      *(bin->p_addr + 62),
+			      *(bin->p_addr + 61), *(bin->p_addr + 60));
+	if (bin->multi_bin_parse_num == 1)
+		bin->header_info[bin->all_bin_parse_num].valid_data_addr = 60;
+	aw_get_single_bin_header_1_0_0(bin);
+
+	for (i = 0; i < bin_num; i++) {
+		ret = aw_parse_each_of_multi_bins_1_0_0(bin_num, i, bin);
+		if (ret < 0)
+			return ret;
+	}
+	return AW_BIN_ERROR_NONE;
+}
+
+/********************************************************
+ *
+ * If the bin framework header version is 1.0.0,
+ * determine the data type of bin, and then perform different processing
+ * according to the data type
+ * If it is a single bin data type, write the data directly into the structure array
+ * If it is a multi-bin data type, first obtain the number of bins,
+ * and then recursively call the bin frame header processing function
+ * according to the bin number to process the frame header information of each bin separately
+ *
+ ********************************************************/
+static enum aw_bin_err_val aw_parse_bin_header_1_0_0(struct aw_bin *bin)
+{
+	unsigned int bin_data_type;
+	enum aw_bin_err_val ret;
+
+	bin_data_type = AW_SAR_GET_32_DATA(*(bin->p_addr + 11),
+				    *(bin->p_addr + 10),
+				    *(bin->p_addr + 9), *(bin->p_addr + 8));
+	switch (bin_data_type) {
+	case DATA_TYPE_REGISTER:
+	case DATA_TYPE_DSP_REG:
+	case DATA_TYPE_SOC_APP:
+		// Divided into two processing methods,
+		// one is single bin processing,
+		// and the other is single bin processing in multi bin
+		bin->single_bin_parse_num += 1;
+		if (!bin->multi_bin_parse_num)
+			bin->header_info[bin->all_bin_parse_num].valid_data_addr = 60;
+		aw_get_single_bin_header_1_0_0(bin);
+		break;
+	case DATA_TYPE_MULTI_BINS:
+		/* Get the number of times to enter multi bins */
+		bin->multi_bin_parse_num += 1;
+		ret = aw_get_multi_bin_header_1_0_0(bin);
+		if (ret < 0)
+			return ret;
+		break;
+	default:
+		return AW_BIN_ERROR_DATA_TYPE;
+	}
+	return AW_BIN_ERROR_NONE;
+}
+
+/* get the bin's header version */
+static enum aw_bin_err_val aw_check_bin_header_version(struct aw_bin *bin)
+{
+	unsigned int header_version;
+	enum aw_bin_err_val ret;
+
+	header_version = AW_SAR_GET_32_DATA(*(bin->p_addr + 7), *(bin->p_addr + 6),
+				     *(bin->p_addr + 5), *(bin->p_addr + 4));
+
+
+	// Write data to the corresponding structure array
+	// according to different formats of the bin frame header version
+	switch (header_version) {
+	case HEADER_VERSION_1_0_0:
+		ret = aw_parse_bin_header_1_0_0(bin);
+		return ret;
+	default:
+		return AW_BIN_ERROR_HEADER_VERSION;
+	}
+}
+
+/**
+ * @brief Parse bin file
+ *
+ * @param bin: Store the contents of the parsed bin file
+ * @return 0 if init succeeded, other if error
+ */
+enum aw_bin_err_val aw_sar_parsing_bin_file(struct aw_bin *bin)
+{
+	enum aw_bin_err_val ret;
+	int i;
+
+	if (!bin)
+		return AW_BIN_ERROR_NULL_POINT;
+	bin->p_addr = bin->info.data;
+	bin->all_bin_parse_num = 0;
+	bin->multi_bin_parse_num = 0;
+	bin->single_bin_parse_num = 0;
+
+	/* filling bins header info */
+	ret = aw_check_bin_header_version(bin);
+	if (ret < 0)
+		return ret;
+	bin->p_addr = NULL;
+
+	/* check bin header info */
+	for (i = 0; i < bin->all_bin_parse_num; i++) {
+		/* check sum */
+		ret = aw_check_sum(bin, i);
+		if (ret < 0)
+			return ret;
+
+		/* check register num */
+		if (bin->header_info[i].bin_data_type == DATA_TYPE_REGISTER) {
+			ret = aw_check_register_num_v1(bin, i);
+			if (ret < 0)
+				return ret;
+			/* check dsp reg num */
+		} else if (bin->header_info[i].bin_data_type == DATA_TYPE_DSP_REG) {
+			ret = aw_check_dsp_reg_num_v1(bin, i);
+			if (ret < 0)
+				return ret;
+			/* check soc app num */
+		} else if (bin->header_info[i].bin_data_type == DATA_TYPE_SOC_APP) {
+			ret = aw_check_soc_app_num_v1(bin, i);
+			if (ret < 0)
+				return ret;
+		} else {
+			bin->header_info[i].valid_data_len = bin->header_info[i].bin_data_len;
+		}
+	}
+
+	return AW_BIN_ERROR_NONE;
+}
+/*********************************Parse bin file code end************************************/
+
+/**
+ * @brief Calculate the second power
+ *
+ * @param cnt: ifrequency
+ * @return the second power
+ */
+uint32_t aw_sar_pow2(uint32_t cnt)
+{
+	uint32_t sum = 1;
+	uint32_t i;
+
+	if (cnt == 0) {
+		sum = 1;
+	} else {
+		for (i = 0; i < cnt; i++)
+			sum *= 2;
+	}
+
+	return sum;
+}
+
+/**
+ * @brief Calculate the second power
+ *
+ * @param *aw_bin: Information after parsing bin file
+ * @param *i2c: i2c client.
+ * @return 0 if init succeeded.
+ */
+int32_t aw_sar_load_reg(struct aw_bin *aw_bin, struct i2c_client *i2c)
+{
+	uint32_t start_addr = aw_bin->header_info[0].valid_data_addr;
+	uint16_t reg_addr;
+	uint32_t reg_data;
+	int32_t ret;
+	uint32_t i;
+
+	for (i = 0; i < aw_bin->header_info[0].valid_data_len; i += 6, start_addr += 6) {
+		reg_addr = (aw_bin->info.data[start_addr]) |
+				aw_bin->info.data[start_addr + 1] << OFFSET_BIT_8;
+		reg_data = aw_bin->info.data[start_addr + 2] |
+			(aw_bin->info.data[start_addr + 3] << OFFSET_BIT_8) |
+			(aw_bin->info.data[start_addr + 4] << OFFSET_BIT_16) |
+			(aw_bin->info.data[start_addr + 5] << OFFSET_BIT_24);
+
+		ret = aw_sar_i2c_write(i2c, reg_addr, reg_data);
+		if (ret < 0) {
+			dev_err(&i2c->dev, "i2c write err");
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+void aw_sar_delay_ms(uint32_t ms)
+{
+	mdelay(ms);
+}
+
diff --git a/drivers/input/misc/aw_sar/comm/aw_sar_comm_interface.h b/drivers/input/misc/aw_sar/comm/aw_sar_comm_interface.h
new file mode 100644
index 000000000000..6f35193f2aee
--- /dev/null
+++ b/drivers/input/misc/aw_sar/comm/aw_sar_comm_interface.h
@@ -0,0 +1,172 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef _AW_SAR_PLAT_HW_INTERFACE_H_
+#define _AW_SAR_PLAT_HW_INTERFACE_H_
+#include <linux/delay.h>
+#include <linux/firmware.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/of_gpio.h>
+#include <linux/power_supply.h>
+#include <linux/pinctrl/consumer.h>
+#include <linux/regulator/consumer.h>
+#include <linux/slab.h>
+
+enum aw_sar_chip_list_t {
+	AW_SAR_NONE_CHECK_CHIP,
+
+	SAR_AW9610X = 1 << 1,
+	SAR_AW9610XA = 1 << 2,
+
+	SAR_AW96303 = 1 << 6,
+	SAR_AW96305 = 1 << 7,
+	SAR_AW96308 = 1 << 8,
+	SAR_AW96310 = 1 << 9,
+	SAR_AW96312 = 1 << 10,
+};
+
+enum AW_SAR_UPDATE_FW_MODE {
+	PROT_UPDATE_FW,
+	REG_UPDATE_FW,
+};
+
+#ifndef AW_TRUE
+#define AW_TRUE					(1)
+#endif
+
+#ifndef AW_FALSE
+#define AW_FALSE				(0)
+#endif
+
+#define AW_ERR_IRQ_INIT_OVER			(0xAA)
+
+enum aw_sar_rst_val {
+	AW_OK,
+	AW_BIN_PARA_INVALID,
+	AW_PROT_UPDATE_ERR,
+	AW_REG_LOAD_ERR,
+};
+
+#ifndef OFFSET_BIT_0
+#define OFFSET_BIT_0				(0)
+#endif
+
+#ifndef OFFSET_BIT_8
+#define OFFSET_BIT_8				(8)
+#endif
+
+#ifndef OFFSET_BIT_16
+#define OFFSET_BIT_16				(16)
+#endif
+
+#ifndef OFFSET_BIT_24
+#define OFFSET_BIT_24				(24)
+#endif
+
+#define AW_SAR_GET_32_DATA(w, x, y, z)	((unsigned int)(((w) << 24) | ((x) << 16) | ((y) << 8) | (z)))
+
+enum AW_SAR_HOST_IRQ_STAT {
+	IRQ_ENABLE,
+	IRQ_DISABLE,
+};
+
+#define AW_SAR_BIN_NUM_MAX   100
+
+enum aw_bin_err_val {
+	AW_BIN_ERROR_NONE = 0,
+	AW_BIN_ERROR_HEADER_VERSION = -1,
+	AW_BIN_ERROR_DATA_TYPE = -2,
+	AW_BIN_ERROR_SUM_OR_DATA_LEN = -3,
+	AW_BIN_ERROR_DATA_VERSION = -4,
+	AW_BIN_ERROR_REGISTER_NUM = -5,
+	AW_BIN_ERROR_DSP_REG_NUM = -6,
+	AW_BIN_ERROR_SOC_APP_NUM = -7,
+	AW_BIN_ERROR_NULL_POINT = -8,
+};
+
+/**
+ * struct bin_header_info -
+ * @header_len: Frame header length
+ * @check_sum: Frame header information-Checksum
+ * @header_ver: Frame header information-Frame header version
+ * @bin_data_type: Frame header information-Data type
+ * @bin_data_ver: Frame header information-Data version
+ * @bin_data_len: Frame header information-Data length
+ * @ui_ver: Frame header information-ui version
+ * @chip_type: Frame header information-chip type
+ * @reg_byte_len: Frame header information-reg byte len
+ * @data_byte_len: Frame header information-data byte len
+ * @device_addr: Frame header information-device addr
+ * @valid_data_len: Length of valid data obtained after parsing
+ * @valid_data_addr: The offset address of the valid data obtained
+ *    after parsing relative to info
+ * @reg_num: The number of registers obtained after parsing
+ * @reg_data_byte_len: The byte length of the register obtained after parsing
+ * @download_addr: The starting address or download address obtained after parsing
+ * @app_version: The software version number obtained after parsing
+ */
+struct bin_header_info {
+	unsigned int header_len;
+	unsigned int check_sum;
+	unsigned int header_ver;
+	unsigned int bin_data_type;
+	unsigned int bin_data_ver;
+	unsigned int bin_data_len;
+	unsigned int ui_ver;
+	unsigned char chip_type[8];
+	unsigned int reg_byte_len;
+	unsigned int data_byte_len;
+	unsigned int device_addr;
+	unsigned int valid_data_len;
+	unsigned int valid_data_addr;
+	unsigned int reg_num;
+	unsigned int reg_data_byte_len;
+	unsigned int download_addr;
+	unsigned int app_version;
+};
+
+/**
+ * struct bin_container -
+ * @len: The size of the bin file obtained from the firmware
+ * @data: Store the bin file obtained from the firmware
+ */
+struct bin_container {
+	unsigned int len;
+	unsigned char data[];
+};
+
+/**
+ * struct aw_bin -
+ * @p_addr: Offset pointer (backward offset pointer to obtain frame header information and
+ *    important information)
+ * @all_bin_parse_num: The number of all bin files
+ * @multi_bin_parse_num: The number of single bin files
+ * @single_bin_parse_num: The number of multiple bin files
+ * @header_info: Frame header information and
+ *    other important data obtained after parsing
+ * @info: Obtained bin file data that needs to be parsed
+ */
+struct aw_bin {
+	char *p_addr;
+	unsigned int all_bin_parse_num;
+	unsigned int multi_bin_parse_num;
+	unsigned int single_bin_parse_num;
+	struct bin_header_info header_info[AW_SAR_BIN_NUM_MAX];
+	struct bin_container info;
+};
+
+//I2C communication API
+extern int32_t aw_sar_i2c_read(struct i2c_client *i2c, uint16_t reg_addr16,  uint32_t *reg_data32);
+extern int32_t aw_sar_i2c_write(struct i2c_client *i2c, uint16_t reg_addr16, uint32_t reg_data32);
+extern int32_t aw_sar_i2c_write_bits(struct i2c_client *i2c, uint16_t reg_addr16,
+		uint32_t mask, uint32_t val);
+extern int32_t aw_sar_i2c_write_seq(struct i2c_client *i2c, uint8_t *tr_data, uint16_t len);
+extern int32_t aw_sar_i2c_read_seq(struct i2c_client *i2c, uint8_t *addr,
+		uint8_t addr_len, uint8_t *data, uint16_t data_len);
+extern void aw_sar_delay_ms(uint32_t ms);
+
+extern enum aw_bin_err_val aw_sar_parsing_bin_file(struct aw_bin *bin);
+extern uint32_t aw_sar_pow2(uint32_t cnt);
+extern int32_t aw_sar_load_reg(struct aw_bin *aw_bin, struct i2c_client *i2c);
+
+#endif
diff --git a/drivers/input/misc/aw_sar/comm/aw_sar_type.h b/drivers/input/misc/aw_sar/comm/aw_sar_type.h
new file mode 100644
index 000000000000..8f217f8e21dd
--- /dev/null
+++ b/drivers/input/misc/aw_sar/comm/aw_sar_type.h
@@ -0,0 +1,396 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+#ifndef _SAR_TYPE_H_
+#define _SAR_TYPE_H_
+
+#include "aw_sar_comm_interface.h"
+
+typedef int32_t (*aw_sar_chip_other_operation_t)(void *data);
+typedef void (*aw_sar_chip_other_opera_free_t)(void *data);
+
+enum aw_i2c_flags {
+	AW_SAR_I2C_WR,
+	AW_SAR_I2C_RD,
+	AW_SAR_PACKAGE_RD,
+};
+
+enum sar_health_check {
+	AW_SAR_HEALTHY = 0,
+	AW_SAR_UNHEALTHY = 1,
+};
+typedef int32_t (*aw_sar_bin_opera_t)(struct aw_bin *aw_bin, void *load_bin_para);
+typedef int32_t (*aw_sar_bin_load_fail_opera_t)(struct aw_bin *aw_bin, void *load_bin_para);
+
+struct aw_sar_get_chip_info_t {
+	void (*p_get_chip_info_node_fn)(void *data, char *buf, ssize_t *p_len);
+};
+
+struct aw_sar_load_bin_t {
+	const uint8_t *bin_name;
+	aw_sar_bin_opera_t bin_opera_func;
+	aw_sar_bin_load_fail_opera_t bin_load_fail_opera;
+
+	void (*p_get_prot_update_fw_node_fn)(void *data, char *buf, ssize_t *p_len);
+
+	/*Perform different operations to update parameters*/
+	int32_t (*p_update_fn)(void *data);
+};
+
+struct aw_sar_reg_data {
+	unsigned char rw;
+	unsigned short reg;
+};
+
+struct aw_sar_awrw_t {
+	ssize_t (*p_set_awrw_node_fn)(void *data, const char *buf, size_t count);
+	ssize_t (*p_get_awrw_node_fn)(void *data, char *buf);
+};
+
+struct aw_sar_reg_list_t {
+	uint8_t reg_none_access;
+	uint8_t reg_rd_access;
+	uint8_t reg_wd_access;
+	const struct aw_sar_reg_data *reg_perm;
+	uint32_t reg_num;
+};
+
+typedef void (*aw_sar_update_work_t)(struct work_struct *work);
+struct aw_sar_update_static_t {
+	aw_sar_update_work_t update_work_func;
+	uint32_t delay_ms;
+};
+
+typedef irqreturn_t (*aw_sar_irq_t)(int irq, void *data);
+typedef uint32_t (*sar_rc_irqscr_t)(void *i2c);
+/*
+ * If the return value is 1, there is an initialization completion interrupt;
+ * if the return value is 0, there is no
+ */
+typedef uint32_t (*aw_sar_is_init_over_irq)(uint32_t irq_status);
+typedef void (*aw_sar_irq_spec_handler_t)(uint32_t irq_status, void *data);
+
+struct aw_sar_check_chipid_t {
+	/*Read chipid and check chipid, Must be implemented externally*/
+	int32_t (*p_check_chipid_fn)(void *data);
+};
+
+struct aw_sar_irq_init_t {
+	unsigned long flags;
+	unsigned long irq_flags;
+	irq_handler_t handler;
+	irq_handler_t thread_fn;
+	/*Interrupt processing parameters*/
+	sar_rc_irqscr_t rc_irq_fn;
+	//aw_sar_is_init_over_irq is_init_over_irq_fn;
+	aw_sar_irq_spec_handler_t irq_spec_handler_fn;
+
+	/*Use a different initialization interrupt to initialize the operation*/
+	int32_t (*p_irq_init_fn)(void *data);
+	/*Release interrupt resource*/
+//	void const (*p_irq_deinit_fn)(void *data);
+	int (*p_irq_deinit_fn)(void *data);
+};
+
+struct aw_sar_pm_t {
+	uint32_t suspend_set_mode;
+	uint32_t resume_set_mode;
+	uint32_t shutdown_set_mode;
+	//system api
+	int32_t (*p_suspend_fn)(void *data);
+	int32_t (*p_resume_fn)(void *data);
+	int32_t (*p_shutdown_fn)(void *data);
+};
+
+struct aw_sar_chip_mode_t {
+	uint32_t init_mode;
+	uint32_t active;
+	uint32_t pre_init_mode;
+};
+
+struct aw_sar_regulator_config_t {
+	//Note that "_sar_num" after VCC name is defined by SAR C auto add
+	const uint8_t *vcc_name;
+	int32_t min_uV;
+	int32_t max_uV;
+};
+
+struct aw_channels_info {
+	uint16_t used;
+	uint32_t last_channel_info;
+	struct input_dev *input;
+	uint8_t name[20];
+};
+
+struct aw_sar_dts_info {
+	uint32_t sar_num;
+	int32_t irq_gpio;
+	uint32_t channel_use_flag;
+	bool use_regulator_flag;
+	bool use_inter_pull_up;
+	bool use_pm;
+	bool update_fw_flag;
+	bool use_plug_cail_flag;
+	bool monitor_esd_flag;
+};
+
+struct aw_sar_irq_init_comm_t {
+	int32_t to_irq;
+	uint8_t host_irq_stat;
+	void *data;
+	uint8_t label[30];
+	uint8_t dev_id[30];
+};
+
+struct aw_sar_load_bin_comm_t {
+	uint8_t bin_name[30];
+	uint32_t bin_data_ver;
+	aw_sar_bin_opera_t bin_opera_func;
+	aw_sar_bin_load_fail_opera_t bin_load_fail_opera_func;
+};
+
+struct aw_awrw_info {
+	uint8_t rw_flag;
+	uint8_t addr_len;
+	uint8_t data_len;
+	uint8_t reg_num;
+	uint32_t i2c_tranfar_data_len;
+	uint8_t *p_i2c_tranfar_data;
+};
+
+/****************mode set start******************/
+typedef void (*sar_enable_clock_t)(void *i2c);
+typedef void (*sar_operation_irq_t)(int to_irq);
+typedef void (*sar_mode_update_t)(void *i2c);
+
+struct aw_sar_mode_switch_ops {
+	sar_enable_clock_t enable_clock;
+	sar_rc_irqscr_t rc_irqscr;
+	sar_mode_update_t mode_update;
+};
+
+struct aw_sar_chip_mode {
+	uint8_t curr_mode;
+	uint8_t last_mode;
+};
+
+struct aw_sar_mode_set_t {
+	uint8_t chip_id;
+	struct aw_sar_chip_mode chip_mode;
+	struct aw_sar_mode_switch_ops mode_switch_ops;
+};
+
+struct aw_sar_mode_t {
+	const struct aw_sar_mode_set_t *mode_set_arr;
+	uint8_t mode_set_arr_len;
+	ssize_t (*p_set_mode_node_fn)(void *data, uint8_t curr_mode);
+	ssize_t (*p_get_mode_node_fn)(void *data, char *buf);
+};
+/********************mode set end****************/
+
+struct aw_sar_init_over_irq_t {
+	int16_t wait_times;
+	uint8_t daley_step;
+	uint32_t reg_irqsrc;
+	uint32_t irq_offset_bit;
+	uint32_t irq_mask;
+	uint32_t irq_flag;
+	/*
+	 * Perform different verification initialization
+	 * to complete the interrupt operation
+	 */
+	int32_t (*p_check_init_over_irq_fn)(void *data);
+	/*
+	 * When initialization fails, get the corresponding error type and
+	 * apply it to the chip with flash
+	 */
+	int32_t (*p_get_err_type_fn)(void *data);
+};
+
+struct aw_sar_soft_rst_t {
+	uint16_t reg_rst;
+	uint32_t reg_rst_val;
+	uint32_t delay_ms;
+	/*Perform different soft reset operations*/
+	int32_t (*p_soft_reset_fn)(void *data);
+};
+
+struct aw_sar_aot_t {
+	uint32_t aot_reg;
+	uint32_t aot_mask;
+	uint32_t aot_flag;
+	ssize_t (*p_set_aot_node_fn)(void *data);
+};
+
+struct aw_sar_diff_t {
+	uint16_t diff0_reg;
+	uint16_t diff_step;
+	//Data format:S21.10, Floating point types generally need to be removed
+	uint32_t rm_float;
+	ssize_t (*p_get_diff_node_fn)(void *data, char *buf);
+};
+
+struct aw_sar_offset_t {
+	ssize_t (*p_get_offset_node_fn)(void *data, char *buf);
+};
+
+struct aw_sar_pinctrl {
+	struct pinctrl *pinctrl;
+	struct pinctrl_state *default_sta;
+	struct pinctrl_state *int_out_high;
+	struct pinctrl_state *int_out_low;
+};
+
+//update reg node
+struct aw_sar_para_load_t {
+	const uint32_t *reg_arr;
+	uint32_t reg_arr_len;
+};
+
+struct aw_sar_platform_config {
+	/*The chip needs to parse more DTS contents for addition*/
+	int32_t (*p_add_parse_dts_fn)(void *data);
+
+	const struct aw_sar_regulator_config_t *p_regulator_config;
+
+	/*The chip needs to add more nodes*/
+	int32_t (*p_add_node_create_fn)(void *data);
+	/*Release the added node*/
+	int32_t (*p_add_node_free_fn)(void *data);
+
+	/*Use a different initialization interrupt to initialize the operation*/
+	int32_t (*p_input_init_fn)(void *data);
+	/*Release input resource*/
+	int32_t (*p_input_deinit_fn)(void *data);
+
+	//The parameters passed in are required for interrupt initialization
+	const struct aw_sar_irq_init_t *p_irq_init;
+
+	//The chip is set to different modes in different power management interfaces
+	const struct aw_sar_pm_t *p_pm_chip_mode;
+};
+
+struct aw_sar_power_on_prox_detection_t {
+	//en_flag is true enable
+	void (*p_power_on_prox_detection_en_fn)(void *data, uint8_t en_flag);
+	uint32_t irq_en_cali_bit;
+	uint8_t power_on_prox_en_flag;
+};
+
+
+/*Parameter passed in by different SAR sensors.
+ *It must be implemented in each sensor code.
+ *If it is not necessary that some members can be assigned null,
+ *the corresponding function will not be implemented
+ */
+struct aw_sar_chip_config {
+	uint8_t ch_num_max; //Number of channels of the chip
+
+	//Chip related platform content configuration
+	const struct aw_sar_platform_config *p_platform_config;
+	//Parameters required for verification of chipid
+	const struct aw_sar_check_chipid_t *p_check_chipid;
+	//Parameters required for soft reset
+	const struct aw_sar_soft_rst_t *p_soft_rst;
+	//Verify the parameters required to initialize a complete interrupt
+	const struct aw_sar_init_over_irq_t *p_init_over_irq;
+	//Parameters required for load boot bin file,
+	//If the chip does not have flash, please ignore and assign the value to null
+	const struct aw_sar_load_bin_t *p_fw_bin;
+	//Parameters required for load register bin file
+	const struct aw_sar_load_bin_t *p_reg_bin;
+	//The mode set before and after the initialization of the chip
+	const struct aw_sar_chip_mode_t *p_chip_mode;
+
+	//Node usage parameters
+	//Register permission table
+	const struct aw_sar_reg_list_t *p_reg_list;
+	//Default register table
+	const struct aw_sar_para_load_t *p_reg_arr;
+	//Parameters required for set Auto-Offset-Tuning(aot)
+	const struct aw_sar_aot_t *p_aot;
+	//Parameters required for get chip diff val
+	const struct aw_sar_diff_t *p_diff;
+	//Parameters required for get chip offset val
+	const struct aw_sar_offset_t *p_offset;
+	//Set the parameters of different working modes of the chip
+	const struct aw_sar_mode_t *p_mode;
+	//Upgrading firmware using the debug node protocol
+	const struct aw_sar_load_bin_t *p_prox_fw;
+	//Upgrading firmware using the debug node reg
+	const struct aw_sar_load_bin_t *p_reg_fw;
+	//Obtain the necessary information of the chip
+	const struct aw_sar_get_chip_info_t *p_get_chip_info;
+	//Continuous read/write register interface
+	const struct aw_sar_awrw_t *p_aw_sar_awrw;
+	//Parameters required for load boot bin file,
+	//If the chip does not have flash, please ignore and assign the value to null
+	const struct aw_sar_load_bin_t *p_boot_bin;
+
+	/*Other operations during initialization, Add according to different usage*/
+	aw_sar_chip_other_operation_t p_other_operation;
+	/*If requested by resources, please release*/
+	aw_sar_chip_other_opera_free_t p_other_opera_free;
+
+	const struct aw_sar_power_on_prox_detection_t *power_on_prox_detection;
+};
+
+struct aw_sar {
+	struct i2c_client *i2c;
+	struct device *dev;
+	struct regulator *vcc;
+	struct delayed_work update_work;
+	//Set pin pull-up mode
+	struct aw_sar_pinctrl pinctrl;
+	/* eds work */
+	struct delayed_work monitor_work;
+	struct workqueue_struct *monitor_wq;
+
+	uint8_t chip_type;
+	uint8_t chip_name[20];
+
+	bool power_enable;
+	bool fw_fail_flag;
+	uint8_t last_mode;
+
+	/*handler_anomalies*/
+	uint8_t fault_flag;
+	uint8_t driver_code_initover_flag;
+	/*handler_anomalies*/
+
+	uint8_t ret_val;
+	uint8_t curr_use_driver_type;
+	int32_t prot_update_state;
+
+	uint8_t aot_irq_num;
+	uint8_t enter_irq_handle_num;
+	uint8_t exit_power_on_prox_detection;
+
+	struct work_struct ps_notify_work;
+	struct notifier_block ps_notif;
+	bool ps_is_present;
+
+	//Parameters related to platform logic
+	struct aw_sar_dts_info dts_info;
+	struct aw_sar_load_bin_comm_t load_bin;
+	struct aw_sar_irq_init_comm_t irq_init;
+	struct aw_awrw_info awrw_info;
+	struct aw_channels_info *channels_arr;
+
+	//Private arguments required for public functions
+	const struct aw_sar_chip_config *p_sar_para;
+	//Private arguments required for private functions
+	void *priv_data;
+};
+
+//Determine whether the chip exists by verifying chipid
+typedef int32_t (*aw_sar_who_am_i_t)(void *data);
+typedef int32_t (*aw_sar_chip_init_t)(struct aw_sar *p_sar);
+typedef void (*aw_sar_chip_deinit_t)(struct aw_sar *p_sar);
+
+struct aw_sar_driver_type {
+	uint8_t driver_type;
+	aw_sar_who_am_i_t p_who_am_i;
+	aw_sar_chip_init_t p_chip_init;
+	aw_sar_chip_deinit_t p_chip_deinit;
+};
+
+#endif
-- 
2.45.1


^ permalink raw reply related	[relevance 2%]

* Re: [PATCH for-4.19 2/9] xen/cpu: do not get the CPU map in stop_machine_run()
  @ 2024-05-29 13:04  2%   ` Jan Beulich
  0 siblings, 0 replies; 200+ results
From: Jan Beulich @ 2024-05-29 13:04 UTC (permalink / raw)
  To: Roger Pau Monne
  Cc: Andrew Cooper, George Dunlap, Julien Grall, Stefano Stabellini,
	xen-devel, Michal Orzel, Bertrand Marquis

On 29.05.2024 11:01, Roger Pau Monne wrote:
> The current callers of stop_machine_run() outside of init code already have the
> CPU maps locked, and hence there's no reason for stop_machine_run() to attempt
> to lock again.

While purely from a description perspective this is okay, ...

> --- a/xen/common/stop_machine.c
> +++ b/xen/common/stop_machine.c
> @@ -82,9 +82,15 @@ int stop_machine_run(int (*fn)(void *data), void *data, unsigned int cpu)
>      BUG_ON(!local_irq_is_enabled());
>      BUG_ON(!is_idle_vcpu(current));
>  
> -    /* cpu_online_map must not change. */
> -    if ( !get_cpu_maps() )
> +    /*
> +     * cpu_online_map must not change.  The only two callers of
> +     * stop_machine_run() outside of init code already have the CPU map locked.
> +     */

... the "two" here is not unlikely to quickly go stale; who knows what PPC
and RISC-V will have as their code becomes more complete?

I'm also unconvinced that requiring ...

> +    if ( system_state >= SYS_STATE_active && !cpu_map_locked() )

... this for all future (post-init) uses of stop_machine_run() is a good
idea. It is quite a bit more natural, to me at least, for the function to
effect this itself, as is the case prior to your change.

In fact I'm puzzled by Arm's (init-time) use: They use it twice, for errata
workaround and feature enabling. They do that after bringing up secondary
CPUs, but still from start_xen(). How's that going to work for CPUs brought
offline and then back online later on? __cpu_up() isn't __init, so there's
no obvious sign that soft-{off,on}lining isn't possible on Arm. Cc-ing Arm
maintainers.

Jan

> +    {
> +        ASSERT_UNREACHABLE();
>          return -EBUSY;
> +    }
>  
>      nr_cpus = num_online_cpus();
>      if ( cpu_online(this) )
> @@ -92,10 +98,7 @@ int stop_machine_run(int (*fn)(void *data), void *data, unsigned int cpu)
>  
>      /* Must not spin here as the holder will expect us to be descheduled. */
>      if ( !spin_trylock(&stopmachine_lock) )
> -    {
> -        put_cpu_maps();
>          return -EBUSY;
> -    }
>  
>      stopmachine_data.fn = fn;
>      stopmachine_data.fn_data = data;
> @@ -136,8 +139,6 @@ int stop_machine_run(int (*fn)(void *data), void *data, unsigned int cpu)
>  
>      spin_unlock(&stopmachine_lock);
>  
> -    put_cpu_maps();
> -
>      return ret;
>  }
>  
> diff --git a/xen/include/xen/cpu.h b/xen/include/xen/cpu.h
> index e1d4eb59675c..d8c8264c58b0 100644
> --- a/xen/include/xen/cpu.h
> +++ b/xen/include/xen/cpu.h
> @@ -13,6 +13,8 @@ void put_cpu_maps(void);
>  void cpu_hotplug_begin(void);
>  void cpu_hotplug_done(void);
>  
> +bool cpu_map_locked(void);
> +
>  /* Receive notification of CPU hotplug events. */
>  void register_cpu_notifier(struct notifier_block *nb);
>  



^ permalink raw reply	[relevance 2%]

* Re: [PATCH 7/7] riscv: Add qspinlock support based on Zabha extension
  @ 2024-05-29 13:03  1%       ` Alexandre Ghiti
  0 siblings, 0 replies; 200+ results
From: Alexandre Ghiti @ 2024-05-29 13:03 UTC (permalink / raw)
  To: Guo Ren
  Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long,
	Boqun Feng, Arnd Bergmann, Leonardo Bras, linux-doc,
	linux-kernel, linux-riscv, linux-arch

Hi Guo,

On Wed, May 29, 2024 at 11:24 AM Guo Ren <guoren@kernel.org> wrote:
>
> On Tue, May 28, 2024 at 11:18 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> >
> > In order to produce a generic kernel, a user can select
> > CONFIG_QUEUED_SPINLOCKS which will fallback at runtime to the ticket
> > spinlock implementation if Zabha is not present.
> >
> > Note that we can't use alternatives here because the discovery of
> > extensions is done too late and we need to start with the qspinlock
> > implementation because the ticket spinlock implementation would pollute
> > the spinlock value, so let's use static keys.
> >
> > This is largely based on Guo's work and Leonardo reviews at [1].
> >
> > Link: https://lore.kernel.org/linux-riscv/20231225125847.2778638-1-guoren@kernel.org/ [1]
> > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
> > ---
> >  .../locking/queued-spinlocks/arch-support.txt |  2 +-
> >  arch/riscv/Kconfig                            |  1 +
> >  arch/riscv/include/asm/Kbuild                 |  4 +-
> >  arch/riscv/include/asm/spinlock.h             | 39 +++++++++++++++++++
> >  arch/riscv/kernel/setup.c                     | 18 +++++++++
> >  include/asm-generic/qspinlock.h               |  2 +
> >  include/asm-generic/ticket_spinlock.h         |  2 +
> >  7 files changed, 66 insertions(+), 2 deletions(-)
> >  create mode 100644 arch/riscv/include/asm/spinlock.h
> >
> > diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt
> > index 22f2990392ff..cf26042480e2 100644
> > --- a/Documentation/features/locking/queued-spinlocks/arch-support.txt
> > +++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt
> > @@ -20,7 +20,7 @@
> >      |    openrisc: |  ok  |
> >      |      parisc: | TODO |
> >      |     powerpc: |  ok  |
> > -    |       riscv: | TODO |
> > +    |       riscv: |  ok  |
> >      |        s390: | TODO |
> >      |          sh: | TODO |
> >      |       sparc: |  ok  |
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 184a9edb04e0..ccf1703edeb9 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -59,6 +59,7 @@ config RISCV
> >         select ARCH_SUPPORTS_SHADOW_CALL_STACK if HAVE_SHADOW_CALL_STACK
> >         select ARCH_USE_MEMTEST
> >         select ARCH_USE_QUEUED_RWLOCKS
> > +       select ARCH_USE_QUEUED_SPINLOCKS if TOOLCHAIN_HAS_ZABHA
> Using qspinlock or not depends on real hardware capabilities, not the
> compiler flag. That's why I introduced combo-spinlock, ticket-spinlock
> & qspinlock three Kconfigs, and the combo-spinlock would compat all
> hardware platforms but waste some qspinlock code size.

You're right, and I think your comment matches what Conor mentioned
about the lack of clarity with some extensions: TOOLCHAIN_HAS_ZABHA
will allow a platform with Zabha capability to use qspinlocks. But if
the hardware does not, it will fallback to the ticket spinlocks.

But I agree that looking at the config alone may be misleading, even
though it will work as expected at runtime. So I agree with you:
unless anyone is strongly against the combo spinlocks, I will do what
you suggest and add them.

Thanks again for your initial work,

Alex

>
> >         select ARCH_USES_CFI_TRAPS if CFI_CLANG
> >         select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH if SMP && MMU
> >         select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
> > diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild
> > index 504f8b7e72d4..ad72f2bd4cc9 100644
> > --- a/arch/riscv/include/asm/Kbuild
> > +++ b/arch/riscv/include/asm/Kbuild
> > @@ -2,10 +2,12 @@
> >  generic-y += early_ioremap.h
> >  generic-y += flat.h
> >  generic-y += kvm_para.h
> > +generic-y += mcs_spinlock.h
> >  generic-y += parport.h
> > -generic-y += spinlock.h
> >  generic-y += spinlock_types.h
> > +generic-y += ticket_spinlock.h
> >  generic-y += qrwlock.h
> >  generic-y += qrwlock_types.h
> > +generic-y += qspinlock.h
> >  generic-y += user.h
> >  generic-y += vmlinux.lds.h
> > diff --git a/arch/riscv/include/asm/spinlock.h b/arch/riscv/include/asm/spinlock.h
> > new file mode 100644
> > index 000000000000..e00429ac20ed
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/spinlock.h
> > @@ -0,0 +1,39 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +
> > +#ifndef __ASM_RISCV_SPINLOCK_H
> > +#define __ASM_RISCV_SPINLOCK_H
> > +
> > +#ifdef CONFIG_QUEUED_SPINLOCKS
> > +#define _Q_PENDING_LOOPS       (1 << 9)
> > +
> > +#define __no_arch_spinlock_redefine
> > +#include <asm/ticket_spinlock.h>
> > +#include <asm/qspinlock.h>
> > +#include <asm/alternative.h>
> > +
> > +DECLARE_STATIC_KEY_TRUE(qspinlock_key);
> > +
> > +#define SPINLOCK_BASE_DECLARE(op, type, type_lock)                     \
> > +static __always_inline type arch_spin_##op(type_lock lock)             \
> > +{                                                                      \
> > +       if (static_branch_unlikely(&qspinlock_key))                     \
> > +               return queued_spin_##op(lock);                          \
> > +       return ticket_spin_##op(lock);                                  \
> > +}
> > +
> > +SPINLOCK_BASE_DECLARE(lock, void, arch_spinlock_t *)
> > +SPINLOCK_BASE_DECLARE(unlock, void, arch_spinlock_t *)
> > +SPINLOCK_BASE_DECLARE(is_locked, int, arch_spinlock_t *)
> > +SPINLOCK_BASE_DECLARE(is_contended, int, arch_spinlock_t *)
> > +SPINLOCK_BASE_DECLARE(trylock, bool, arch_spinlock_t *)
> > +SPINLOCK_BASE_DECLARE(value_unlocked, int, arch_spinlock_t)
> > +
> > +#else
> > +
> > +#include <asm/ticket_spinlock.h>
> > +
> > +#endif
> > +
> > +#include <asm/qrwlock.h>
> > +
> > +#endif /* __ASM_RISCV_SPINLOCK_H */
> > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> > index 4f73c0ae44b2..31ce75522fd4 100644
> > --- a/arch/riscv/kernel/setup.c
> > +++ b/arch/riscv/kernel/setup.c
> > @@ -244,6 +244,23 @@ static void __init parse_dtb(void)
> >  #endif
> >  }
> >
> > +DEFINE_STATIC_KEY_TRUE(qspinlock_key);
> > +EXPORT_SYMBOL(qspinlock_key);
> > +
> > +static void __init riscv_spinlock_init(void)
> > +{
> > +       asm goto(ALTERNATIVE("nop", "j %[qspinlock]", 0, RISCV_ISA_EXT_ZABHA, 1)
> > +                : : : : qspinlock);
> > +
> > +       static_branch_disable(&qspinlock_key);
> > +       pr_info("Ticket spinlock: enabled\n");
> > +
> > +       return;
> > +
> > +qspinlock:
> > +       pr_info("Queued spinlock: enabled\n");
> > +}
> > +
> >  extern void __init init_rt_signal_env(void);
> >
> >  void __init setup_arch(char **cmdline_p)
> > @@ -295,6 +312,7 @@ void __init setup_arch(char **cmdline_p)
> >         riscv_set_dma_cache_alignment();
> >
> >         riscv_user_isa_enable();
> > +       riscv_spinlock_init();
> >  }
> >
> >  bool arch_cpu_is_hotpluggable(int cpu)
> > diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
> > index 0655aa5b57b2..bf47cca2c375 100644
> > --- a/include/asm-generic/qspinlock.h
> > +++ b/include/asm-generic/qspinlock.h
> > @@ -136,6 +136,7 @@ static __always_inline bool virt_spin_lock(struct qspinlock *lock)
> >  }
> >  #endif
> >
> > +#ifndef __no_arch_spinlock_redefine
> >  /*
> >   * Remapping spinlock architecture specific functions to the corresponding
> >   * queued spinlock functions.
> > @@ -146,5 +147,6 @@ static __always_inline bool virt_spin_lock(struct qspinlock *lock)
> >  #define arch_spin_lock(l)              queued_spin_lock(l)
> >  #define arch_spin_trylock(l)           queued_spin_trylock(l)
> >  #define arch_spin_unlock(l)            queued_spin_unlock(l)
> > +#endif
> >
> >  #endif /* __ASM_GENERIC_QSPINLOCK_H */
> > diff --git a/include/asm-generic/ticket_spinlock.h b/include/asm-generic/ticket_spinlock.h
> > index cfcff22b37b3..325779970d8a 100644
> > --- a/include/asm-generic/ticket_spinlock.h
> > +++ b/include/asm-generic/ticket_spinlock.h
> > @@ -89,6 +89,7 @@ static __always_inline int ticket_spin_is_contended(arch_spinlock_t *lock)
> >         return (s16)((val >> 16) - (val & 0xffff)) > 1;
> >  }
> >
> > +#ifndef __no_arch_spinlock_redefine
> >  /*
> >   * Remapping spinlock architecture specific functions to the corresponding
> >   * ticket spinlock functions.
> > @@ -99,5 +100,6 @@ static __always_inline int ticket_spin_is_contended(arch_spinlock_t *lock)
> >  #define arch_spin_lock(l)              ticket_spin_lock(l)
> >  #define arch_spin_trylock(l)           ticket_spin_trylock(l)
> >  #define arch_spin_unlock(l)            ticket_spin_unlock(l)
> > +#endif
> >
> >  #endif /* __ASM_GENERIC_TICKET_SPINLOCK_H */
> > --
> > 2.39.2
> >
>
>
> --
> Best Regards
>  Guo Ren

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[relevance 1%]

* Re: [PATCH 7/7] riscv: Add qspinlock support based on Zabha extension
@ 2024-05-29 13:03  1%       ` Alexandre Ghiti
  0 siblings, 0 replies; 200+ results
From: Alexandre Ghiti @ 2024-05-29 13:03 UTC (permalink / raw)
  To: Guo Ren
  Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long,
	Boqun Feng, Arnd Bergmann, Leonardo Bras, linux-doc,
	linux-kernel, linux-riscv, linux-arch

Hi Guo,

On Wed, May 29, 2024 at 11:24 AM Guo Ren <guoren@kernel.org> wrote:
>
> On Tue, May 28, 2024 at 11:18 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote:
> >
> > In order to produce a generic kernel, a user can select
> > CONFIG_QUEUED_SPINLOCKS which will fallback at runtime to the ticket
> > spinlock implementation if Zabha is not present.
> >
> > Note that we can't use alternatives here because the discovery of
> > extensions is done too late and we need to start with the qspinlock
> > implementation because the ticket spinlock implementation would pollute
> > the spinlock value, so let's use static keys.
> >
> > This is largely based on Guo's work and Leonardo reviews at [1].
> >
> > Link: https://lore.kernel.org/linux-riscv/20231225125847.2778638-1-guoren@kernel.org/ [1]
> > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
> > ---
> >  .../locking/queued-spinlocks/arch-support.txt |  2 +-
> >  arch/riscv/Kconfig                            |  1 +
> >  arch/riscv/include/asm/Kbuild                 |  4 +-
> >  arch/riscv/include/asm/spinlock.h             | 39 +++++++++++++++++++
> >  arch/riscv/kernel/setup.c                     | 18 +++++++++
> >  include/asm-generic/qspinlock.h               |  2 +
> >  include/asm-generic/ticket_spinlock.h         |  2 +
> >  7 files changed, 66 insertions(+), 2 deletions(-)
> >  create mode 100644 arch/riscv/include/asm/spinlock.h
> >
> > diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt
> > index 22f2990392ff..cf26042480e2 100644
> > --- a/Documentation/features/locking/queued-spinlocks/arch-support.txt
> > +++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt
> > @@ -20,7 +20,7 @@
> >      |    openrisc: |  ok  |
> >      |      parisc: | TODO |
> >      |     powerpc: |  ok  |
> > -    |       riscv: | TODO |
> > +    |       riscv: |  ok  |
> >      |        s390: | TODO |
> >      |          sh: | TODO |
> >      |       sparc: |  ok  |
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 184a9edb04e0..ccf1703edeb9 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -59,6 +59,7 @@ config RISCV
> >         select ARCH_SUPPORTS_SHADOW_CALL_STACK if HAVE_SHADOW_CALL_STACK
> >         select ARCH_USE_MEMTEST
> >         select ARCH_USE_QUEUED_RWLOCKS
> > +       select ARCH_USE_QUEUED_SPINLOCKS if TOOLCHAIN_HAS_ZABHA
> Using qspinlock or not depends on real hardware capabilities, not the
> compiler flag. That's why I introduced combo-spinlock, ticket-spinlock
> & qspinlock three Kconfigs, and the combo-spinlock would compat all
> hardware platforms but waste some qspinlock code size.

You're right, and I think your comment matches what Conor mentioned
about the lack of clarity with some extensions: TOOLCHAIN_HAS_ZABHA
will allow a platform with Zabha capability to use qspinlocks. But if
the hardware does not, it will fallback to the ticket spinlocks.

But I agree that looking at the config alone may be misleading, even
though it will work as expected at runtime. So I agree with you:
unless anyone is strongly against the combo spinlocks, I will do what
you suggest and add them.

Thanks again for your initial work,

Alex

>
> >         select ARCH_USES_CFI_TRAPS if CFI_CLANG
> >         select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH if SMP && MMU
> >         select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
> > diff --git a/arch/riscv/include/asm/Kbuild b/arch/riscv/include/asm/Kbuild
> > index 504f8b7e72d4..ad72f2bd4cc9 100644
> > --- a/arch/riscv/include/asm/Kbuild
> > +++ b/arch/riscv/include/asm/Kbuild
> > @@ -2,10 +2,12 @@
> >  generic-y += early_ioremap.h
> >  generic-y += flat.h
> >  generic-y += kvm_para.h
> > +generic-y += mcs_spinlock.h
> >  generic-y += parport.h
> > -generic-y += spinlock.h
> >  generic-y += spinlock_types.h
> > +generic-y += ticket_spinlock.h
> >  generic-y += qrwlock.h
> >  generic-y += qrwlock_types.h
> > +generic-y += qspinlock.h
> >  generic-y += user.h
> >  generic-y += vmlinux.lds.h
> > diff --git a/arch/riscv/include/asm/spinlock.h b/arch/riscv/include/asm/spinlock.h
> > new file mode 100644
> > index 000000000000..e00429ac20ed
> > --- /dev/null
> > +++ b/arch/riscv/include/asm/spinlock.h
> > @@ -0,0 +1,39 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +
> > +#ifndef __ASM_RISCV_SPINLOCK_H
> > +#define __ASM_RISCV_SPINLOCK_H
> > +
> > +#ifdef CONFIG_QUEUED_SPINLOCKS
> > +#define _Q_PENDING_LOOPS       (1 << 9)
> > +
> > +#define __no_arch_spinlock_redefine
> > +#include <asm/ticket_spinlock.h>
> > +#include <asm/qspinlock.h>
> > +#include <asm/alternative.h>
> > +
> > +DECLARE_STATIC_KEY_TRUE(qspinlock_key);
> > +
> > +#define SPINLOCK_BASE_DECLARE(op, type, type_lock)                     \
> > +static __always_inline type arch_spin_##op(type_lock lock)             \
> > +{                                                                      \
> > +       if (static_branch_unlikely(&qspinlock_key))                     \
> > +               return queued_spin_##op(lock);                          \
> > +       return ticket_spin_##op(lock);                                  \
> > +}
> > +
> > +SPINLOCK_BASE_DECLARE(lock, void, arch_spinlock_t *)
> > +SPINLOCK_BASE_DECLARE(unlock, void, arch_spinlock_t *)
> > +SPINLOCK_BASE_DECLARE(is_locked, int, arch_spinlock_t *)
> > +SPINLOCK_BASE_DECLARE(is_contended, int, arch_spinlock_t *)
> > +SPINLOCK_BASE_DECLARE(trylock, bool, arch_spinlock_t *)
> > +SPINLOCK_BASE_DECLARE(value_unlocked, int, arch_spinlock_t)
> > +
> > +#else
> > +
> > +#include <asm/ticket_spinlock.h>
> > +
> > +#endif
> > +
> > +#include <asm/qrwlock.h>
> > +
> > +#endif /* __ASM_RISCV_SPINLOCK_H */
> > diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
> > index 4f73c0ae44b2..31ce75522fd4 100644
> > --- a/arch/riscv/kernel/setup.c
> > +++ b/arch/riscv/kernel/setup.c
> > @@ -244,6 +244,23 @@ static void __init parse_dtb(void)
> >  #endif
> >  }
> >
> > +DEFINE_STATIC_KEY_TRUE(qspinlock_key);
> > +EXPORT_SYMBOL(qspinlock_key);
> > +
> > +static void __init riscv_spinlock_init(void)
> > +{
> > +       asm goto(ALTERNATIVE("nop", "j %[qspinlock]", 0, RISCV_ISA_EXT_ZABHA, 1)
> > +                : : : : qspinlock);
> > +
> > +       static_branch_disable(&qspinlock_key);
> > +       pr_info("Ticket spinlock: enabled\n");
> > +
> > +       return;
> > +
> > +qspinlock:
> > +       pr_info("Queued spinlock: enabled\n");
> > +}
> > +
> >  extern void __init init_rt_signal_env(void);
> >
> >  void __init setup_arch(char **cmdline_p)
> > @@ -295,6 +312,7 @@ void __init setup_arch(char **cmdline_p)
> >         riscv_set_dma_cache_alignment();
> >
> >         riscv_user_isa_enable();
> > +       riscv_spinlock_init();
> >  }
> >
> >  bool arch_cpu_is_hotpluggable(int cpu)
> > diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
> > index 0655aa5b57b2..bf47cca2c375 100644
> > --- a/include/asm-generic/qspinlock.h
> > +++ b/include/asm-generic/qspinlock.h
> > @@ -136,6 +136,7 @@ static __always_inline bool virt_spin_lock(struct qspinlock *lock)
> >  }
> >  #endif
> >
> > +#ifndef __no_arch_spinlock_redefine
> >  /*
> >   * Remapping spinlock architecture specific functions to the corresponding
> >   * queued spinlock functions.
> > @@ -146,5 +147,6 @@ static __always_inline bool virt_spin_lock(struct qspinlock *lock)
> >  #define arch_spin_lock(l)              queued_spin_lock(l)
> >  #define arch_spin_trylock(l)           queued_spin_trylock(l)
> >  #define arch_spin_unlock(l)            queued_spin_unlock(l)
> > +#endif
> >
> >  #endif /* __ASM_GENERIC_QSPINLOCK_H */
> > diff --git a/include/asm-generic/ticket_spinlock.h b/include/asm-generic/ticket_spinlock.h
> > index cfcff22b37b3..325779970d8a 100644
> > --- a/include/asm-generic/ticket_spinlock.h
> > +++ b/include/asm-generic/ticket_spinlock.h
> > @@ -89,6 +89,7 @@ static __always_inline int ticket_spin_is_contended(arch_spinlock_t *lock)
> >         return (s16)((val >> 16) - (val & 0xffff)) > 1;
> >  }
> >
> > +#ifndef __no_arch_spinlock_redefine
> >  /*
> >   * Remapping spinlock architecture specific functions to the corresponding
> >   * ticket spinlock functions.
> > @@ -99,5 +100,6 @@ static __always_inline int ticket_spin_is_contended(arch_spinlock_t *lock)
> >  #define arch_spin_lock(l)              ticket_spin_lock(l)
> >  #define arch_spin_trylock(l)           ticket_spin_trylock(l)
> >  #define arch_spin_unlock(l)            ticket_spin_unlock(l)
> > +#endif
> >
> >  #endif /* __ASM_GENERIC_TICKET_SPINLOCK_H */
> > --
> > 2.39.2
> >
>
>
> --
> Best Regards
>  Guo Ren

^ permalink raw reply	[relevance 1%]

* Re: [REGRESSION][BISECTED] Scheduling errors with the AMD FX 8300 CPU
  @ 2024-05-29 13:02  1%                   ` Tim Teichmann
  0 siblings, 0 replies; 200+ results
From: Tim Teichmann @ 2024-05-29 13:02 UTC (permalink / raw)
  To: Niklas Cassel
  Cc: Thomas Gleixner, Christian Heusel, regressions, x86, stable,
	Hans de Goede, linux-ide, Damien Le Moal, Jens Axboe


[-- Attachment #1.1: Type: text/plain, Size: 5016 bytes --]

Hello Niklas,

On 24/05/28 10:19pm, Niklas Cassel wrote:
> Hello Tim,
> 
> On Tue, May 28, 2024 at 01:17:51PM -0600, Jens Axboe wrote:
> > (Adding Damien, he's the ATA guy these days - leaving the below intact)
> > 
> > On 5/28/24 1:15 PM, Thomas Gleixner wrote:
> > > Tim!
> > > 
> > > On Tue, May 28 2024 at 17:43, Tim Teichmann wrote:
> > >> On 24/05/27 07:17pm, Thomas Gleixner wrote:
> > >> I've just tested the fix you've provided in the previous email.
> > >> The exact patches are attached to the ticket in the archlinux bugtracker[0].
> > > 
> > > Thanks! I will write a proper changelog and ship it.
> > > 
> > >> The error regarding CPU scheduling disappeared for both kernel verions[0].
> > >> However, the ATA bus error still occurs.
> > >>
> > >> Also, I suppose that the ATA bus error is the same as the previous one,
> > >> because the only value that changes in the exception message is SAct.
> > >>
> > >> This is the message of the ATA error before the patch:
> > >>
> > >>>> May 23 23:36:49 archlinux kernel: smpboot: x86: Booting SMP configuration:
> > >>>> May 23 23:36:49 archlinux kernel: .... node  #0, CPUs:      #2 #4 #6
> > >>>> May 23 23:36:49 archlinux kernel: __common_interrupt: 2.55 No irq handler for vector
> > >>>> May 23 23:36:49 archlinux kernel: __common_interrupt: 4.55 No irq handler for vector
> > >>>> May 23 23:36:49 archlinux kernel: __common_interrupt: 6.55 No irq handler for vector
> > >>>>
> > >>>> ATA stuff:
> > >>>>
> > >>>> May 23 23:36:59 archlinux kernel: ata2.00: exception Emask 0x10 SAct 0x1fffe000 SErr 0x40d0002 action 0xe frozen
> > >>>
> > >>> That's probably just the fallout of the above.
> > > 
> > > It's in reality not related and I saw some other AHCI fallout fly by.
> > > 
> > >> And that's the message after the patch:
> > >>
> > >> [    4.877584] ata2.00: exception Emask 0x10 SAct 0x80000000 SErr 0x40d0002 action 0xe frozen
> > >>
> > >> The full dmesg outputs are in the attachments.
> > > 
> > > Cc'ed the AHCI people and left the info around for them.
> 
> We recently (kernel v6.9) enabled LPM for all AHCI controllers if:
> -The AHCI controller reports that it supports LPM, and
> -The drive reports that it supports LPM (DIPM), and
> -CONFIG_SATA_MOBILE_LPM_POLICY=3, and
> -The port is not defined as external in the per port PxCMD register, and
> -The port is not defined as hotplug capable in the per port PxCMD register.
> 
> However, there appears to be some drives (usually cheap ones that we've never
> heard about) that reports that they support DIPM, but when actually turning
> it on, they stop working.
> 
> Looking at the dmesg, you seem to have two SATA drives:
> 
> > >> [    0.957220] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> > >> [    0.957984] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> > >> [    0.958027] ata3.00: ATA-8: TOSHIBA HDWD110, MS2OA8J0, max UDMA/133
> > >> [    0.958069] ata2.00: ATA-11: Apacer AS340 120GB, AP612PE0, max UDMA/133
> 
> 
> ata3 (TOSHIBA HDWD110) appears to work correctly.
> 
> ata2 (Apacer AS340 120GB) results in command timeouts and
> "a change in device presence has been detected" being set in PxSERR.DIAG.X.
> 
> > >> [    2.964262] ata2.00: exception Emask 0x10 SAct 0x80 SErr 0x40d0002 action 0xe frozen
> > >> [    2.964274] ata2.00: irq_stat 0x00000040, connection status changed
> > >> [    2.964279] ata2: SError: { RecovComm PHYRdyChg CommWake 10B8B DevExch }
> > >> [    2.964288] ata2.00: failed command: READ FPDMA QUEUED
> > >> [    2.964291] ata2.00: cmd 60/08:38:80:ff:f1/00:00:0d:00:00/40 tag 7 ncq dma 4096 in
> > >>                         res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x10 (ATA bus error)
> > >> [    2.964307] ata2.00: status: { DRDY }
> > >> [    2.964318] ata2: hard resetting link
> 
> 
> Could you please try the following patch (quirk):
> 
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index c449d60d9bb9..24ebcad65b65 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -4199,6 +4199,9 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>                                                 ATA_HORKAGE_ZERO_AFTER_TRIM |
>                                                 ATA_HORKAGE_NOLPM },
>  
> +       /* Apacer models with LPM issues */
> +       { "Apacer AS340*",              NULL,   ATA_HORKAGE_NOLPM },
> +
>         /* These specific Samsung models/firmware-revs do not handle LPM well */
>         { "SAMSUNG MZMPC128HBFU-000MV", "CXM14M1Q", ATA_HORKAGE_NOLPM },
>         { "SAMSUNG SSD PM830 mSATA *",  "CXM13D1Q", ATA_HORKAGE_NOLPM },
> 
> 
> 
> Kind regards,
> Niklas

I've just tested the patch you've provided [0] and it works without
throwing ATA exceptions.

The full dmesg output is attached below.

Thank you,
Tim

[0]: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/56#note_188819

[-- Attachment #1.2: dmesg_6.9.2-arch1-1.3.log --]
[-- Type: text/plain, Size: 71228 bytes --]

[    0.000000] Linux version 6.9.2-arch1-1.3 (linux@archlinux) (gcc (GCC) 14.1.1 20240522, GNU ld (GNU Binutils) 2.42.0) #1 SMP PREEMPT_DYNAMIC Tue, 28 May 2024 21:16:00 +0000
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=963daeed-0888-4658-9f17-18bd343dfb2a rw zswap.enabled=0 rootfstype=ext4 loglevel=3 quiet
[    0.000000] BIOS-provided physical RAM map:
[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable
[    0.000000] BIOS-e820: [mem 0x000000000009f800-0x000000000009ffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000000f0000-0x00000000000fffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000bfdeffff] usable
[    0.000000] BIOS-e820: [mem 0x00000000bfdf0000-0x00000000bfdf2fff] ACPI NVS
[    0.000000] BIOS-e820: [mem 0x00000000bfdf3000-0x00000000bfdfffff] ACPI data
[    0.000000] BIOS-e820: [mem 0x00000000bfe00000-0x00000000bfefffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000ffffffff] reserved
[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000043effffff] usable
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] APIC: Static calls initialized
[    0.000000] SMBIOS 2.4 present.
[    0.000000] DMI: Gigabyte Technology Co., Ltd. GA-78LMT-USB3 R2/GA-78LMT-USB3 R2, BIOS F1 11/08/2017
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] tsc: Detected 3322.009 MHz processor
[    0.002928] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
[    0.002932] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.002938] last_pfn = 0x43f000 max_arch_pfn = 0x400000000
[    0.002947] total RAM covered: 3070M
[    0.003245] Found optimal setting for mtrr clean up
[    0.003246]  gran_size: 64K 	chunk_size: 4M 	num_reg: 3  	lose cover RAM: 0G
[    0.003251] MTRR map: 7 entries (4 fixed + 3 variable; max 21), built from 9 variable MTRRs
[    0.003253] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[    0.004118] e820: update [mem 0xbfe00000-0xffffffff] usable ==> reserved
[    0.004128] last_pfn = 0xbfdf0 max_arch_pfn = 0x400000000
[    0.007039] found SMP MP-table at [mem 0x000f5ea0-0x000f5eaf]
[    0.007060] Using GB pages for direct mapping
[    0.007180] RAMDISK: [mem 0x31c9f000-0x34e46fff]
[    0.007303] ACPI: Early table checksum verification disabled
[    0.007308] ACPI: RSDP 0x00000000000F78B0 000014 (v00 GBT   )
[    0.007312] ACPI: RSDT 0x00000000BFDF3000 000040 (v01 GBT    GBTUACPI 42302E31 GBTU 01010101)
[    0.007319] ACPI: FACP 0x00000000BFDF3080 000074 (v01 GBT    GBTUACPI 42302E31 GBTU 01010101)
[    0.007325] ACPI: DSDT 0x00000000BFDF3100 0069E7 (v01 GBT    GBTUACPI 00001000 MSFT 03000000)
[    0.007330] ACPI: FACS 0x00000000BFDF0000 000040
[    0.007334] ACPI: MSDM 0x00000000BFDF9BC0 000055 (v03 GBT    GBTUACPI 42302E31 GBTU 01010101)
[    0.007338] ACPI: HPET 0x00000000BFDF9C40 000038 (v01 GBT    GBTUACPI 42302E31 GBTU 00000098)
[    0.007342] ACPI: MCFG 0x00000000BFDF9C80 00003C (v01 GBT    GBTUACPI 42302E31 GBTU 01010101)
[    0.007346] ACPI: TAMG 0x00000000BFDF9CC0 000022 (v01 GBT    GBT   B0 5455312E BG?? 00000101)
[    0.007350] ACPI: APIC 0x00000000BFDF9B00 0000BC (v01 GBT    GBTUACPI 42302E31 GBTU 01010101)
[    0.007354] ACPI: SSDT 0x00000000BFDF9D60 001714 (v01 AMD    POWERNOW 00000001 AMD  00000001)
[    0.007358] ACPI: Reserving FACP table memory at [mem 0xbfdf3080-0xbfdf30f3]
[    0.007359] ACPI: Reserving DSDT table memory at [mem 0xbfdf3100-0xbfdf9ae6]
[    0.007361] ACPI: Reserving FACS table memory at [mem 0xbfdf0000-0xbfdf003f]
[    0.007362] ACPI: Reserving MSDM table memory at [mem 0xbfdf9bc0-0xbfdf9c14]
[    0.007364] ACPI: Reserving HPET table memory at [mem 0xbfdf9c40-0xbfdf9c77]
[    0.007365] ACPI: Reserving MCFG table memory at [mem 0xbfdf9c80-0xbfdf9cbb]
[    0.007366] ACPI: Reserving TAMG table memory at [mem 0xbfdf9cc0-0xbfdf9ce1]
[    0.007367] ACPI: Reserving APIC table memory at [mem 0xbfdf9b00-0xbfdf9bbb]
[    0.007368] ACPI: Reserving SSDT table memory at [mem 0xbfdf9d60-0xbfdfb473]
[    0.007432] No NUMA configuration found
[    0.007433] Faking a node at [mem 0x0000000000000000-0x000000043effffff]
[    0.007436] NODE_DATA(0) allocated [mem 0x43effb000-0x43effffff]
[    0.007477] Zone ranges:
[    0.007478]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
[    0.007480]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
[    0.007482]   Normal   [mem 0x0000000100000000-0x000000043effffff]
[    0.007484]   Device   empty
[    0.007485] Movable zone start for each node
[    0.007486] Early memory node ranges
[    0.007487]   node   0: [mem 0x0000000000001000-0x000000000009efff]
[    0.007488]   node   0: [mem 0x0000000000100000-0x00000000bfdeffff]
[    0.007490]   node   0: [mem 0x0000000100000000-0x000000043effffff]
[    0.007493] Initmem setup node 0 [mem 0x0000000000001000-0x000000043effffff]
[    0.007499] On node 0, zone DMA: 1 pages in unavailable ranges
[    0.007539] On node 0, zone DMA: 97 pages in unavailable ranges
[    0.055138] On node 0, zone Normal: 528 pages in unavailable ranges
[    0.055214] On node 0, zone Normal: 4096 pages in unavailable ranges
[    0.055397] ACPI: PM-Timer IO Port: 0x4008
[    0.055409] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
[    0.055411] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
[    0.055413] ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
[    0.055414] ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
[    0.055415] ACPI: LAPIC_NMI (acpi_id[0x04] dfl dfl lint[0x1])
[    0.055416] ACPI: LAPIC_NMI (acpi_id[0x05] dfl dfl lint[0x1])
[    0.055417] ACPI: LAPIC_NMI (acpi_id[0x06] dfl dfl lint[0x1])
[    0.055418] ACPI: LAPIC_NMI (acpi_id[0x07] dfl dfl lint[0x1])
[    0.055431] IOAPIC[0]: apic_id 2, version 33, address 0xfec00000, GSI 0-23
[    0.055434] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.055436] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
[    0.055441] ACPI: Using ACPI (MADT) for SMP configuration information
[    0.055442] ACPI: HPET id: 0x10b9a201 base: 0xfed00000
[    0.055452] CPU topo: Max. logical packages:   1
[    0.055453] CPU topo: Max. logical dies:       1
[    0.055454] CPU topo: Max. dies per package:   1
[    0.055459] CPU topo: Max. threads per core:   1
[    0.055460] CPU topo: Num. cores per package:     8
[    0.055461] CPU topo: Num. threads per package:   8
[    0.055462] CPU topo: Allowing 8 present CPUs plus 0 hotplug CPUs
[    0.055475] PM: hibernation: Registered nosave memory: [mem 0x00000000-0x00000fff]
[    0.055477] PM: hibernation: Registered nosave memory: [mem 0x0009f000-0x0009ffff]
[    0.055478] PM: hibernation: Registered nosave memory: [mem 0x000a0000-0x000effff]
[    0.055479] PM: hibernation: Registered nosave memory: [mem 0x000f0000-0x000fffff]
[    0.055481] PM: hibernation: Registered nosave memory: [mem 0xbfdf0000-0xbfdf2fff]
[    0.055482] PM: hibernation: Registered nosave memory: [mem 0xbfdf3000-0xbfdfffff]
[    0.055483] PM: hibernation: Registered nosave memory: [mem 0xbfe00000-0xbfefffff]
[    0.055484] PM: hibernation: Registered nosave memory: [mem 0xbff00000-0xdfffffff]
[    0.055485] PM: hibernation: Registered nosave memory: [mem 0xe0000000-0xefffffff]
[    0.055487] PM: hibernation: Registered nosave memory: [mem 0xf0000000-0xfebfffff]
[    0.055488] PM: hibernation: Registered nosave memory: [mem 0xfec00000-0xffffffff]
[    0.055490] [mem 0xbff00000-0xdfffffff] available for PCI devices
[    0.055491] Booting paravirtualized kernel on bare hardware
[    0.055494] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370452778343963 ns
[    0.061413] setup_percpu: NR_CPUS:320 nr_cpumask_bits:8 nr_cpu_ids:8 nr_node_ids:1
[    0.062339] percpu: Embedded 66 pages/cpu s233472 r8192 d28672 u524288
[    0.062348] pcpu-alloc: s233472 r8192 d28672 u524288 alloc=1*2097152
[    0.062351] pcpu-alloc: [0] 0 1 2 3 [0] 4 5 6 7 
[    0.062373] Kernel command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=963daeed-0888-4658-9f17-18bd343dfb2a rw zswap.enabled=0 rootfstype=ext4 loglevel=3 quiet
[    0.062455] Unknown kernel command line parameters "BOOT_IMAGE=/vmlinuz-linux", will be passed to user space.
[    0.065336] Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes, linear)
[    0.066737] Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear)
[    0.066821] Fallback order for Node 0: 0 
[    0.066827] Built 1 zonelists, mobility grouping on.  Total pages: 4123960
[    0.066829] Policy zone: Normal
[    0.067262] mem auto-init: stack:all(zero), heap alloc:on, heap free:off
[    0.067268] software IO TLB: area num 8.
[    0.153647] Memory: 16301808K/16758328K available (18432K kernel code, 2164K rwdata, 13296K rodata, 3412K init, 3624K bss, 456260K reserved, 0K cma-reserved)
[    0.161802] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
[    0.161996] ftrace: allocating 49852 entries in 195 pages
[    0.173225] ftrace: allocated 195 pages with 4 groups
[    0.173386] Dynamic Preempt: full
[    0.173613] rcu: Preemptible hierarchical RCU implementation.
[    0.173614] rcu: 	RCU restricting CPUs from NR_CPUS=320 to nr_cpu_ids=8.
[    0.173616] rcu: 	RCU priority boosting: priority 1 delay 500 ms.
[    0.173617] 	Trampoline variant of Tasks RCU enabled.
[    0.173618] 	Rude variant of Tasks RCU enabled.
[    0.173619] 	Tracing variant of Tasks RCU enabled.
[    0.173620] rcu: RCU calculated value of scheduler-enlistment delay is 30 jiffies.
[    0.173621] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8
[    0.173629] RCU Tasks: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
[    0.173631] RCU Tasks Rude: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
[    0.173633] RCU Tasks Trace: Setting shift to 3 and lim to 1 rcu_task_cb_adjust=1.
[    0.179214] NR_IRQS: 20736, nr_irqs: 488, preallocated irqs: 16
[    0.179427] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[    0.179520] kfence: initialized - using 2097152 bytes for 255 objects at 0x(____ptrval____)-0x(____ptrval____)
[    0.179595] spurious 8259A interrupt: IRQ7.
[    0.179615] Console: colour dummy device 80x25
[    0.179618] printk: legacy console [tty0] enabled
[    0.180017] ACPI: Core revision 20230628
[    0.180243] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484873504 ns
[    0.180277] APIC: Switch to symmetric I/O mode setup
[    0.180782] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[    0.196930] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2fe2839811f, max_idle_ns: 440795276340 ns
[    0.196936] Calibrating delay loop (skipped), value calculated using timer frequency.. 6646.85 BogoMIPS (lpj=11073363)
[    0.196960] LVT offset 1 assigned for vector 0xf9
[    0.196965] Last level iTLB entries: 4KB 512, 2MB 1024, 4MB 512
[    0.196967] Last level dTLB entries: 4KB 1024, 2MB 1024, 4MB 512, 1GB 0
[    0.196972] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[    0.196974] Spectre V2 : Mitigation: Retpolines
[    0.196975] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[    0.196976] Spectre V2 : Spectre v2 / SpectreRSB : Filling RSB on VMEXIT
[    0.196977] Spectre V2 : Enabling Speculation Barrier for firmware calls
[    0.196978] RETBleed: Mitigation: untrained return thunk
[    0.196980] Spectre V2 : mitigation: Enabling conditional Indirect Branch Prediction Barrier
[    0.196982] Speculative Store Bypass: Mitigation: Speculative Store Bypass disabled via prctl
[    0.196986] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.196988] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.196989] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.196991] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.196993] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[    0.220801] Freeing SMP alternatives memory: 40K
[    0.220807] pid_max: default: 32768 minimum: 301
[    0.221538] LSM: initializing lsm=capability,landlock,lockdown,yama,bpf
[    0.222378] landlock: Up and running.
[    0.222380] Yama: becoming mindful.
[    0.222387] LSM support for eBPF active
[    0.222633] Mount-cache hash table entries: 32768 (order: 6, 262144 bytes, linear)
[    0.222673] Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes, linear)
[    0.230401] APIC calibration not consistent with PM-Timer: 0ms instead of 100ms
[    0.230407] APIC delta adjusted to PM-Timer: 1257428 (1507)
[    0.230416] smpboot: CPU0: AMD FX(tm)-8300 Eight-Core Processor (family: 0x15, model: 0x2, stepping: 0x0)
[    0.230808] Performance Events: Fam15h core perfctr, AMD PMU driver.
[    0.230814] ... version:                0
[    0.230815] ... bit width:              48
[    0.230816] ... generic registers:      6
[    0.230817] ... value mask:             0000ffffffffffff
[    0.230818] ... max period:             00007fffffffffff
[    0.230819] ... fixed-purpose events:   0
[    0.230820] ... event mask:             000000000000003f
[    0.230932] signal: max sigframe size: 1776
[    0.230983] rcu: Hierarchical SRCU implementation.
[    0.230985] rcu: 	Max phase no-delay instances is 1000.
[    0.233293] MCE: In-kernel MCE decoding enabled.
[    0.233373] NMI watchdog: Enabled. Permanently consumes one hw-PMU counter.
[    0.233505] smp: Bringing up secondary CPUs ...
[    0.233600] smpboot: x86: Booting SMP configuration:
[    0.233600] .... node  #0, CPUs:      #1 #2 #3 #4 #5 #6 #7
[    0.000814] __common_interrupt: 1.55 No irq handler for vector
[    0.000814] __common_interrupt: 2.55 No irq handler for vector
[    0.000814] __common_interrupt: 3.55 No irq handler for vector
[    0.000814] __common_interrupt: 4.55 No irq handler for vector
[    0.000814] __common_interrupt: 5.55 No irq handler for vector
[    0.000814] __common_interrupt: 6.55 No irq handler for vector
[    0.000814] __common_interrupt: 7.55 No irq handler for vector
[    0.263642] smp: Brought up 1 node, 8 CPUs
[    0.263647] smpboot: Total of 8 processors activated (53173.81 BogoMIPS)
[    0.270270] devtmpfs: initialized
[    0.270315] x86/mm: Memory block size: 128MB
[    0.272131] ACPI: PM: Registering ACPI NVS region [mem 0xbfdf0000-0xbfdf2fff] (12288 bytes)
[    0.272131] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370867519511994 ns
[    0.272131] futex hash table entries: 2048 (order: 5, 131072 bytes, linear)
[    0.272131] pinctrl core: initialized pinctrl subsystem
[    0.272131] PM: RTC time: 12:42:29, date: 2024-05-29
[    0.272188] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.272620] DMA: preallocated 2048 KiB GFP_KERNEL pool for atomic allocations
[    0.272907] DMA: preallocated 2048 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
[    0.273800] DMA: preallocated 2048 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
[    0.273814] audit: initializing netlink subsys (disabled)
[    0.273827] audit: type=2000 audit(1716986548.096:1): state=initialized audit_enabled=0 res=1
[    0.273827] thermal_sys: Registered thermal governor 'fair_share'
[    0.273827] thermal_sys: Registered thermal governor 'bang_bang'
[    0.273827] thermal_sys: Registered thermal governor 'step_wise'
[    0.273827] thermal_sys: Registered thermal governor 'user_space'
[    0.273827] thermal_sys: Registered thermal governor 'power_allocator'
[    0.273827] cpuidle: using governor ladder
[    0.273827] cpuidle: using governor menu
[    0.273827] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[    0.274016] PCI: ECAM [mem 0xe0000000-0xefffffff] (base 0xe0000000) for domain 0000 [bus 00-ff]
[    0.274021] PCI: ECAM [mem 0xe0000000-0xefffffff] reserved as E820 entry
[    0.274034] PCI: Using configuration type 1 for base access
[    0.274129] kprobes: kprobe jump-optimization is enabled. All kprobes are optimized if possible.
[    0.277003] HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages
[    0.277003] HugeTLB: 16380 KiB vmemmap can be freed for a 1.00 GiB page
[    0.277003] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
[    0.277003] HugeTLB: 28 KiB vmemmap can be freed for a 2.00 MiB page
[    0.277018] Demotion targets for Node 0: null
[    0.277135] fbcon: Taking over console
[    0.277135] ACPI: Added _OSI(Module Device)
[    0.277135] ACPI: Added _OSI(Processor Device)
[    0.277135] ACPI: Added _OSI(3.0 _SCP Extensions)
[    0.277135] ACPI: Added _OSI(Processor Aggregator Device)
[    0.281946] ACPI: 2 ACPI AML tables successfully acquired and loaded
[    0.282248] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20230628/dspkginit-438)
[    0.282255] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKD (20230628/dspkginit-438)
[    0.282262] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKA (20230628/dspkginit-438)
[    0.282268] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKB (20230628/dspkginit-438)
[    0.282281] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKD (20230628/dspkginit-438)
[    0.282288] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKA (20230628/dspkginit-438)
[    0.282294] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKB (20230628/dspkginit-438)
[    0.282300] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20230628/dspkginit-438)
[    0.282313] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKA (20230628/dspkginit-438)
[    0.282319] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKB (20230628/dspkginit-438)
[    0.282325] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20230628/dspkginit-438)
[    0.282331] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKD (20230628/dspkginit-438)
[    0.282343] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKB (20230628/dspkginit-438)
[    0.282349] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20230628/dspkginit-438)
[    0.282355] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKD (20230628/dspkginit-438)
[    0.282361] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKA (20230628/dspkginit-438)
[    0.282374] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20230628/dspkginit-438)
[    0.282380] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKD (20230628/dspkginit-438)
[    0.282386] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKA (20230628/dspkginit-438)
[    0.282392] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKB (20230628/dspkginit-438)
[    0.282405] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKD (20230628/dspkginit-438)
[    0.282411] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKA (20230628/dspkginit-438)
[    0.282417] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKB (20230628/dspkginit-438)
[    0.282423] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20230628/dspkginit-438)
[    0.282435] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKB (20230628/dspkginit-438)
[    0.282441] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20230628/dspkginit-438)
[    0.282447] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKD (20230628/dspkginit-438)
[    0.282453] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKA (20230628/dspkginit-438)
[    0.282465] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20230628/dspkginit-438)
[    0.282471] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKD (20230628/dspkginit-438)
[    0.282477] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKA (20230628/dspkginit-438)
[    0.282482] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKB (20230628/dspkginit-438)
[    0.282495] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKD (20230628/dspkginit-438)
[    0.282501] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKA (20230628/dspkginit-438)
[    0.282507] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKB (20230628/dspkginit-438)
[    0.282512] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20230628/dspkginit-438)
[    0.282525] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKA (20230628/dspkginit-438)
[    0.282531] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKB (20230628/dspkginit-438)
[    0.282536] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKC (20230628/dspkginit-438)
[    0.282542] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - LNKD (20230628/dspkginit-438)
[    0.287045] ACPI: _OSC evaluation for CPUs failed, trying _PDC
[    0.287206] ACPI: Interpreter enabled
[    0.287226] ACPI: PM: (supports S0 S3 S4 S5)
[    0.287228] ACPI: Using IOAPIC for interrupt routing
[    0.287550] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug
[    0.287552] PCI: Using E820 reservations for host bridge windows
[    0.287705] ACPI: Enabled 5 GPEs in block 00 to 1F
[    0.294800] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.294808] acpi PNP0A03:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
[    0.295182] PCI host bridge to bus 0000:00
[    0.295184] pci_bus 0000:00: root bus resource [io  0x0000-0x0cf7 window]
[    0.295187] pci_bus 0000:00: root bus resource [io  0x0d00-0xffff window]
[    0.295190] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000dffff window]
[    0.295192] pci_bus 0000:00: root bus resource [mem 0xc0000000-0xfebfffff window]
[    0.295195] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.295212] pci 0000:00:00.0: [1022:9600] type 00 class 0x060000 conventional PCI endpoint
[    0.295224] pci 0000:00:00.0: [Firmware Bug]: BAR 3: invalid; can't size
[    0.295301] pci 0000:00:02.0: [1022:9603] type 01 class 0x060400 PCIe Root Port
[    0.295314] pci 0000:00:02.0: PCI bridge to [bus 01]
[    0.295318] pci 0000:00:02.0:   bridge window [io  0xe000-0xefff]
[    0.295321] pci 0000:00:02.0:   bridge window [mem 0xfb000000-0xfcffffff]
[    0.295327] pci 0000:00:02.0:   bridge window [mem 0xc0000000-0xdfffffff 64bit pref]
[    0.295333] pci 0000:00:02.0: enabling Extended Tags
[    0.295361] pci 0000:00:02.0: PME# supported from D0 D3hot D3cold
[    0.295467] pci 0000:00:04.0: [1022:9604] type 01 class 0x060400 PCIe Root Port
[    0.295480] pci 0000:00:04.0: PCI bridge to [bus 02]
[    0.295484] pci 0000:00:04.0:   bridge window [io  0xd000-0xdfff]
[    0.295487] pci 0000:00:04.0:   bridge window [mem 0xfda00000-0xfdafffff]
[    0.295492] pci 0000:00:04.0:   bridge window [mem 0xfdf00000-0xfdffffff 64bit pref]
[    0.295498] pci 0000:00:04.0: enabling Extended Tags
[    0.295524] pci 0000:00:04.0: PME# supported from D0 D3hot D3cold
[    0.295624] pci 0000:00:06.0: [1022:9606] type 01 class 0x060400 PCIe Root Port
[    0.295637] pci 0000:00:06.0: PCI bridge to [bus 03]
[    0.295641] pci 0000:00:06.0:   bridge window [io  0xc000-0xcfff]
[    0.295643] pci 0000:00:06.0:   bridge window [mem 0xfde00000-0xfdefffff]
[    0.295649] pci 0000:00:06.0:   bridge window [mem 0xfdd00000-0xfddfffff 64bit pref]
[    0.295655] pci 0000:00:06.0: enabling Extended Tags
[    0.295681] pci 0000:00:06.0: PME# supported from D0 D3hot D3cold
[    0.295804] pci 0000:00:11.0: [1002:4390] type 00 class 0x01018f conventional PCI endpoint
[    0.295821] pci 0000:00:11.0: BAR 0 [io  0xff00-0xff07]
[    0.295830] pci 0000:00:11.0: BAR 1 [io  0xfe00-0xfe03]
[    0.295840] pci 0000:00:11.0: BAR 2 [io  0xfd00-0xfd07]
[    0.295849] pci 0000:00:11.0: BAR 3 [io  0xfc00-0xfc03]
[    0.295858] pci 0000:00:11.0: BAR 4 [io  0xfb00-0xfb0f]
[    0.295867] pci 0000:00:11.0: BAR 5 [mem 0xfe02f000-0xfe02f3ff]
[    0.295889] pci 0000:00:11.0: set SATA to AHCI mode
[    0.295993] pci 0000:00:12.0: [1002:4397] type 00 class 0x0c0310 conventional PCI endpoint
[    0.296010] pci 0000:00:12.0: BAR 0 [mem 0xfe02e000-0xfe02efff]
[    0.296140] pci 0000:00:12.1: [1002:4398] type 00 class 0x0c0310 conventional PCI endpoint
[    0.296157] pci 0000:00:12.1: BAR 0 [mem 0xfe02d000-0xfe02dfff]
[    0.296297] pci 0000:00:12.2: [1002:4396] type 00 class 0x0c0320 conventional PCI endpoint
[    0.296314] pci 0000:00:12.2: BAR 0 [mem 0xfe02c000-0xfe02c0ff]
[    0.296393] pci 0000:00:12.2: supports D1 D2
[    0.296395] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
[    0.296483] pci 0000:00:13.0: [1002:4397] type 00 class 0x0c0310 conventional PCI endpoint
[    0.296500] pci 0000:00:13.0: BAR 0 [mem 0xfe02b000-0xfe02bfff]
[    0.296627] pci 0000:00:13.1: [1002:4398] type 00 class 0x0c0310 conventional PCI endpoint
[    0.296643] pci 0000:00:13.1: BAR 0 [mem 0xfe02a000-0xfe02afff]
[    0.296776] pci 0000:00:13.2: [1002:4396] type 00 class 0x0c0320 conventional PCI endpoint
[    0.296793] pci 0000:00:13.2: BAR 0 [mem 0xfe029000-0xfe0290ff]
[    0.296872] pci 0000:00:13.2: supports D1 D2
[    0.296874] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
[    0.296974] pci 0000:00:14.0: [1002:4385] type 00 class 0x0c0500 conventional PCI endpoint
[    0.297129] pci 0000:00:14.1: [1002:439c] type 00 class 0x01018a conventional PCI endpoint
[    0.297146] pci 0000:00:14.1: BAR 0 [io  0x0000-0x0007]
[    0.297155] pci 0000:00:14.1: BAR 1 [io  0x0000-0x0003]
[    0.297164] pci 0000:00:14.1: BAR 2 [io  0x0000-0x0007]
[    0.297173] pci 0000:00:14.1: BAR 3 [io  0x0000-0x0003]
[    0.297182] pci 0000:00:14.1: BAR 4 [io  0xfa00-0xfa0f]
[    0.297202] pci 0000:00:14.1: BAR 0 [io  0x01f0-0x01f7]: legacy IDE quirk
[    0.297204] pci 0000:00:14.1: BAR 1 [io  0x03f6]: legacy IDE quirk
[    0.297206] pci 0000:00:14.1: BAR 2 [io  0x0170-0x0177]: legacy IDE quirk
[    0.297207] pci 0000:00:14.1: BAR 3 [io  0x0376]: legacy IDE quirk
[    0.297315] pci 0000:00:14.2: [1002:4383] type 00 class 0x040300 conventional PCI endpoint
[    0.297336] pci 0000:00:14.2: BAR 0 [mem 0xfe024000-0xfe027fff 64bit]
[    0.297403] pci 0000:00:14.2: PME# supported from D0 D3hot D3cold
[    0.297482] pci 0000:00:14.3: [1002:439d] type 00 class 0x060100 conventional PCI endpoint
[    0.297648] pci 0000:00:14.4: [1002:4384] type 01 class 0x060401 conventional PCI bridge
[    0.297679] pci 0000:00:14.4: PCI bridge to [bus 04] (subtractive decode)
[    0.297685] pci 0000:00:14.4:   bridge window [io  0xb000-0xbfff]
[    0.297689] pci 0000:00:14.4:   bridge window [mem 0xfdc00000-0xfdcfffff]
[    0.297694] pci 0000:00:14.4:   bridge window [mem 0xfdb00000-0xfdbfffff pref]
[    0.297779] pci 0000:00:14.5: [1002:4399] type 00 class 0x0c0310 conventional PCI endpoint
[    0.297796] pci 0000:00:14.5: BAR 0 [mem 0xfe028000-0xfe028fff]
[    0.297926] pci 0000:00:18.0: [1022:1600] type 00 class 0x060000 conventional PCI endpoint
[    0.297976] pci 0000:00:18.1: [1022:1601] type 00 class 0x060000 conventional PCI endpoint
[    0.298023] pci 0000:00:18.2: [1022:1602] type 00 class 0x060000 conventional PCI endpoint
[    0.298073] pci 0000:00:18.3: [1022:1603] type 00 class 0x060000 conventional PCI endpoint
[    0.298121] pci 0000:00:18.4: [1022:1604] type 00 class 0x060000 conventional PCI endpoint
[    0.298170] pci 0000:00:18.5: [1022:1605] type 00 class 0x060000 conventional PCI endpoint
[    0.298277] pci 0000:01:00.0: [10de:1c82] type 00 class 0x030000 PCIe Legacy Endpoint
[    0.298291] pci 0000:01:00.0: BAR 0 [mem 0xfb000000-0xfbffffff]
[    0.298302] pci 0000:01:00.0: BAR 1 [mem 0xc0000000-0xcfffffff 64bit pref]
[    0.298313] pci 0000:01:00.0: BAR 3 [mem 0xde000000-0xdfffffff 64bit pref]
[    0.298320] pci 0000:01:00.0: BAR 5 [io  0xef00-0xef7f]
[    0.298328] pci 0000:01:00.0: ROM [mem 0x00000000-0x0007ffff pref]
[    0.298355] pci 0000:01:00.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
[    0.298444] pci 0000:01:00.0: 32.000 Gb/s available PCIe bandwidth, limited by 2.5 GT/s PCIe x16 link at 0000:00:02.0 (capable of 126.016 Gb/s with 8.0 GT/s PCIe x16 link)
[    0.298520] pci 0000:01:00.1: [10de:0fb9] type 00 class 0x040300 PCIe Endpoint
[    0.298533] pci 0000:01:00.1: BAR 0 [mem 0xfcffc000-0xfcffffff]
[    0.298683] pci 0000:00:02.0: PCI bridge to [bus 01]
[    0.298724] pci 0000:02:00.0: [1106:3483] type 00 class 0x0c0330 PCIe Endpoint
[    0.298739] pci 0000:02:00.0: BAR 0 [mem 0xfdaff000-0xfdafffff 64bit]
[    0.298800] pci 0000:02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.298870] pci 0000:00:04.0: PCI bridge to [bus 02]
[    0.298918] pci 0000:03:00.0: [10ec:8168] type 00 class 0x020000 PCIe Endpoint
[    0.298934] pci 0000:03:00.0: BAR 0 [io  0xce00-0xceff]
[    0.298954] pci 0000:03:00.0: BAR 2 [mem 0xfdeff000-0xfdefffff 64bit]
[    0.298967] pci 0000:03:00.0: BAR 4 [mem 0xfddfc000-0xfddfffff 64bit pref]
[    0.299049] pci 0000:03:00.0: supports D1 D2
[    0.299051] pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.299175] pci 0000:00:06.0: PCI bridge to [bus 03]
[    0.299190] pci_bus 0000:04: extended config space not accessible
[    0.299252] pci 0000:00:14.4: PCI bridge to [bus 04] (subtractive decode)
[    0.299261] pci 0000:00:14.4:   bridge window [io  0x0000-0x0cf7 window] (subtractive decode)
[    0.299263] pci 0000:00:14.4:   bridge window [io  0x0d00-0xffff window] (subtractive decode)
[    0.299265] pci 0000:00:14.4:   bridge window [mem 0x000a0000-0x000dffff window] (subtractive decode)
[    0.299267] pci 0000:00:14.4:   bridge window [mem 0xc0000000-0xfebfffff window] (subtractive decode)
[    0.299551] ACPI: PCI: Interrupt link LNKA configured for IRQ 0
[    0.299553] ACPI: PCI: Interrupt link LNKA disabled
[    0.299609] ACPI: PCI: Interrupt link LNKB configured for IRQ 0
[    0.299611] ACPI: PCI: Interrupt link LNKB disabled
[    0.299666] ACPI: PCI: Interrupt link LNKC configured for IRQ 0
[    0.299668] ACPI: PCI: Interrupt link LNKC disabled
[    0.299722] ACPI: PCI: Interrupt link LNKD configured for IRQ 0
[    0.299723] ACPI: PCI: Interrupt link LNKD disabled
[    0.299777] ACPI: PCI: Interrupt link LNKE configured for IRQ 0
[    0.299779] ACPI: PCI: Interrupt link LNKE disabled
[    0.299832] ACPI: PCI: Interrupt link LNKF configured for IRQ 0
[    0.299834] ACPI: PCI: Interrupt link LNKF disabled
[    0.299887] ACPI: PCI: Interrupt link LNK0 configured for IRQ 0
[    0.299889] ACPI: PCI: Interrupt link LNK0 disabled
[    0.299942] ACPI: PCI: Interrupt link LNK1 configured for IRQ 0
[    0.299944] ACPI: PCI: Interrupt link LNK1 disabled
[    0.300718] iommu: Default domain type: Translated
[    0.300718] iommu: DMA domain TLB invalidation policy: lazy mode
[    0.300718] SCSI subsystem initialized
[    0.300718] libata version 3.00 loaded.
[    0.300718] ACPI: bus type USB registered
[    0.300718] usbcore: registered new interface driver usbfs
[    0.300718] usbcore: registered new interface driver hub
[    0.300718] usbcore: registered new device driver usb
[    0.300718] EDAC MC: Ver: 3.0.0
[    0.300718] NetLabel: Initializing
[    0.300718] NetLabel:  domain hash size = 128
[    0.300718] NetLabel:  protocols = UNLABELED CIPSOv4 CALIPSO
[    0.300718] NetLabel:  unlabeled traffic allowed by default
[    0.300718] mctp: management component transport protocol core
[    0.300718] NET: Registered PF_MCTP protocol family
[    0.300718] PCI: Using ACPI for IRQ routing
[    0.310072] PCI: pci_cache_line_size set to 64 bytes
[    0.310124] e820: reserve RAM buffer [mem 0x0009f800-0x0009ffff]
[    0.310127] e820: reserve RAM buffer [mem 0xbfdf0000-0xbfffffff]
[    0.310128] e820: reserve RAM buffer [mem 0x43f000000-0x43fffffff]
[    0.310315] pci 0000:01:00.0: vgaarb: setting as boot VGA device
[    0.310315] pci 0000:01:00.0: vgaarb: bridge control possible
[    0.310315] pci 0000:01:00.0: vgaarb: VGA device added: decodes=io+mem,owns=io+mem,locks=none
[    0.310315] vgaarb: loaded
[    0.310317] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[    0.310317] hpet0: 4 comparators, 32-bit 14.318180 MHz counter
[    0.313604] clocksource: Switched to clocksource tsc-early
[    0.313620] VFS: Disk quotas dquot_6.6.0
[    0.313620] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
[    0.313620] pnp: PnP ACPI init
[    0.313620] system 00:00: [io  0x04d0-0x04d1] has been reserved
[    0.313620] system 00:00: [io  0x0220-0x0225] has been reserved
[    0.313620] system 00:00: [io  0x0290-0x0294] has been reserved
[    0.314919] system 00:01: [io  0x4100-0x411f] has been reserved
[    0.314927] system 00:01: [io  0x0228-0x022f] has been reserved
[    0.314929] system 00:01: [io  0x040b] has been reserved
[    0.314931] system 00:01: [io  0x04d6] has been reserved
[    0.314934] system 00:01: [io  0x0c00-0x0c01] has been reserved
[    0.314936] system 00:01: [io  0x0c14] has been reserved
[    0.314938] system 00:01: [io  0x0c50-0x0c52] has been reserved
[    0.314940] system 00:01: [io  0x0c6c-0x0c6d] has been reserved
[    0.314941] system 00:01: [io  0x0c6f] has been reserved
[    0.314943] system 00:01: [io  0x0cd0-0x0cd1] has been reserved
[    0.314945] system 00:01: [io  0x0cd2-0x0cd3] has been reserved
[    0.314947] system 00:01: [io  0x0cd4-0x0cdf] has been reserved
[    0.314949] system 00:01: [io  0x4000-0x40fe] has been reserved
[    0.314951] system 00:01: [io  0x4210-0x4217] has been reserved
[    0.314952] system 00:01: [io  0x0b00-0x0b0f] has been reserved
[    0.314954] system 00:01: [io  0x0b10-0x0b1f] has been reserved
[    0.314956] system 00:01: [io  0x0b20-0x0b3f] has been reserved
[    0.314958] system 00:01: [mem 0x00000000-0x00000fff window] could not be reserved
[    0.314961] system 00:01: [mem 0xfee00400-0xfee00fff window] has been reserved
[    0.315981] system 00:05: [mem 0xe0000000-0xefffffff] has been reserved
[    0.316207] pnp 00:06: disabling [mem 0x000ce600-0x000cffff] because it overlaps 0000:01:00.0 BAR 6 [mem 0x000c0000-0x000dffff]
[    0.316230] system 00:06: [mem 0x000f0000-0x000f7fff] could not be reserved
[    0.316232] system 00:06: [mem 0x000f8000-0x000fbfff] could not be reserved
[    0.316235] system 00:06: [mem 0x000fc000-0x000fffff] could not be reserved
[    0.316237] system 00:06: [mem 0xbfdf0000-0xbfdfffff] could not be reserved
[    0.316239] system 00:06: [mem 0xffff0000-0xffffffff] has been reserved
[    0.316241] system 00:06: [mem 0x00000000-0x0009ffff] could not be reserved
[    0.316243] system 00:06: [mem 0x00100000-0xbfdeffff] could not be reserved
[    0.316246] system 00:06: [mem 0xbfe00000-0xbfefffff] has been reserved
[    0.316248] system 00:06: [mem 0xbff00000-0xbfffffff] could not be reserved
[    0.316250] system 00:06: [mem 0xfec00000-0xfec00fff] could not be reserved
[    0.316252] system 00:06: [mem 0xfee00000-0xfee00fff] could not be reserved
[    0.316254] system 00:06: [mem 0xfff80000-0xfffeffff] has been reserved
[    0.316278] pnp: PnP ACPI: found 7 devices
[    0.322952] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    0.323236] NET: Registered PF_INET protocol family
[    0.323560] IP idents hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    0.341101] tcp_listen_portaddr_hash hash table entries: 8192 (order: 5, 131072 bytes, linear)
[    0.341146] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)
[    0.341306] TCP established hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.341785] TCP bind hash table entries: 65536 (order: 9, 2097152 bytes, linear)
[    0.342107] TCP: Hash tables configured (established 131072 bind 65536)
[    0.342329] MPTCP token hash table entries: 16384 (order: 6, 393216 bytes, linear)
[    0.342432] UDP hash table entries: 8192 (order: 6, 262144 bytes, linear)
[    0.342495] UDP-Lite hash table entries: 8192 (order: 6, 262144 bytes, linear)
[    0.342592] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.342609] NET: Registered PF_XDP protocol family
[    0.342625] pci 0000:00:02.0: PCI bridge to [bus 01]
[    0.342634] pci 0000:00:02.0:   bridge window [io  0xe000-0xefff]
[    0.342638] pci 0000:00:02.0:   bridge window [mem 0xfb000000-0xfcffffff]
[    0.342641] pci 0000:00:02.0:   bridge window [mem 0xc0000000-0xdfffffff 64bit pref]
[    0.342645] pci 0000:00:04.0: PCI bridge to [bus 02]
[    0.342648] pci 0000:00:04.0:   bridge window [io  0xd000-0xdfff]
[    0.342651] pci 0000:00:04.0:   bridge window [mem 0xfda00000-0xfdafffff]
[    0.342653] pci 0000:00:04.0:   bridge window [mem 0xfdf00000-0xfdffffff 64bit pref]
[    0.342657] pci 0000:00:06.0: PCI bridge to [bus 03]
[    0.342659] pci 0000:00:06.0:   bridge window [io  0xc000-0xcfff]
[    0.342662] pci 0000:00:06.0:   bridge window [mem 0xfde00000-0xfdefffff]
[    0.342665] pci 0000:00:06.0:   bridge window [mem 0xfdd00000-0xfddfffff 64bit pref]
[    0.342669] pci 0000:00:14.4: PCI bridge to [bus 04]
[    0.342672] pci 0000:00:14.4:   bridge window [io  0xb000-0xbfff]
[    0.342677] pci 0000:00:14.4:   bridge window [mem 0xfdc00000-0xfdcfffff]
[    0.342681] pci 0000:00:14.4:   bridge window [mem 0xfdb00000-0xfdbfffff pref]
[    0.342688] pci_bus 0000:00: resource 4 [io  0x0000-0x0cf7 window]
[    0.342691] pci_bus 0000:00: resource 5 [io  0x0d00-0xffff window]
[    0.342693] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000dffff window]
[    0.342695] pci_bus 0000:00: resource 7 [mem 0xc0000000-0xfebfffff window]
[    0.342697] pci_bus 0000:01: resource 0 [io  0xe000-0xefff]
[    0.342699] pci_bus 0000:01: resource 1 [mem 0xfb000000-0xfcffffff]
[    0.342701] pci_bus 0000:01: resource 2 [mem 0xc0000000-0xdfffffff 64bit pref]
[    0.342703] pci_bus 0000:02: resource 0 [io  0xd000-0xdfff]
[    0.342705] pci_bus 0000:02: resource 1 [mem 0xfda00000-0xfdafffff]
[    0.342707] pci_bus 0000:02: resource 2 [mem 0xfdf00000-0xfdffffff 64bit pref]
[    0.342709] pci_bus 0000:03: resource 0 [io  0xc000-0xcfff]
[    0.342711] pci_bus 0000:03: resource 1 [mem 0xfde00000-0xfdefffff]
[    0.342713] pci_bus 0000:03: resource 2 [mem 0xfdd00000-0xfddfffff 64bit pref]
[    0.342715] pci_bus 0000:04: resource 0 [io  0xb000-0xbfff]
[    0.342716] pci_bus 0000:04: resource 1 [mem 0xfdc00000-0xfdcfffff]
[    0.342718] pci_bus 0000:04: resource 2 [mem 0xfdb00000-0xfdbfffff pref]
[    0.342720] pci_bus 0000:04: resource 4 [io  0x0000-0x0cf7 window]
[    0.342722] pci_bus 0000:04: resource 5 [io  0x0d00-0xffff window]
[    0.342724] pci_bus 0000:04: resource 6 [mem 0x000a0000-0x000dffff window]
[    0.342725] pci_bus 0000:04: resource 7 [mem 0xc0000000-0xfebfffff window]
[    0.361533] pci 0000:00:12.0: quirk_usb_early_handoff+0x0/0x730 took 18301 usecs
[    0.378188] pci 0000:00:12.1: quirk_usb_early_handoff+0x0/0x730 took 16251 usecs
[    0.394839] pci 0000:00:13.0: quirk_usb_early_handoff+0x0/0x730 took 16052 usecs
[    0.411492] pci 0000:00:13.1: quirk_usb_early_handoff+0x0/0x730 took 16252 usecs
[    0.428146] pci 0000:00:14.5: quirk_usb_early_handoff+0x0/0x730 took 16044 usecs
[    0.428177] pci 0000:01:00.1: extending delay after power-on from D3hot to 20 msec
[    0.428212] pci 0000:01:00.1: D0 power state depends on 0000:01:00.0
[    0.428421] PCI: CLS 64 bytes, default 64
[    0.428434] PCI-DMA: Using software bounce buffering for IO (SWIOTLB)
[    0.428436] software IO TLB: mapped [mem 0x00000000bbdf0000-0x00000000bfdf0000] (64MB)
[    0.428477] LVT offset 0 assigned for vector 0x400
[    0.428514] Trying to unpack rootfs image as initramfs...
[    0.433810] perf: AMD IBS detected (0x000000ff)
[    0.435368] Initialise system trusted keyrings
[    0.435382] Key type blacklist registered
[    0.435423] workingset: timestamp_bits=41 max_order=22 bucket_order=0
[    0.435432] zbud: loaded
[    0.435825] fuse: init (API version 7.40)
[    0.436328] integrity: Platform Keyring initialized
[    0.436335] integrity: Machine keyring initialized
[    0.451147] Key type asymmetric registered
[    0.451149] Asymmetric key parser 'x509' registered
[    0.451237] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 246)
[    0.451317] io scheduler mq-deadline registered
[    0.451320] io scheduler kyber registered
[    0.451386] io scheduler bfq registered
[    0.452277] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[    0.452401] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
[    0.452438] ACPI: button: Power Button [PWRB]
[    0.452491] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
[    0.455780] ACPI: button: Power Button [PWRF]
[    0.455827] ACPI: \_PR_.C000: Found 2 idle states
[    0.455903] ACPI: \_PR_.C001: Found 2 idle states
[    0.455974] ACPI: \_PR_.C002: Found 2 idle states
[    0.456038] ACPI: \_PR_.C003: Found 2 idle states
[    0.456103] ACPI: \_PR_.C004: Found 2 idle states
[    0.456167] ACPI: \_PR_.C005: Found 2 idle states
[    0.456230] ACPI: \_PR_.C006: Found 2 idle states
[    0.456293] ACPI: \_PR_.C007: Found 2 idle states
[    0.456574] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
[    0.456760] 00:03: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 16550A
[    0.459791] Non-volatile memory driver v1.3
[    0.459793] Linux agpgart interface v0.103
[    0.459841] ACPI: bus type drm_connector registered
[    0.460708] ahci 0000:00:11.0: version 3.0
[    0.460951] ahci 0000:00:11.0: AHCI vers 0001.0100, 32 command slots, 3 Gbps, SATA mode
[    0.460955] ahci 0000:00:11.0: 4/4 ports implemented (port mask 0xf)
[    0.460958] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck pm led clo pmp pio slum part ccc 
[    0.461546] scsi host0: ahci
[    0.461736] scsi host1: ahci
[    0.461867] scsi host2: ahci
[    0.461987] scsi host3: ahci
[    0.462034] ata1: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f100 irq 22 lpm-pol 3
[    0.462037] ata2: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f180 irq 22 lpm-pol 3
[    0.462040] ata3: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f200 irq 22 lpm-pol 3
[    0.462043] ata4: SATA max UDMA/133 abar m1024@0xfe02f000 port 0xfe02f280 irq 22 lpm-pol 3
[    0.462257] ohci-pci 0000:00:12.0: OHCI PCI host controller
[    0.462263] ohci-pci 0000:00:12.0: new USB bus registered, assigned bus number 1
[    0.462305] ohci-pci 0000:00:12.0: irq 16, io mem 0xfe02e000
[    0.520463] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 6.09
[    0.520470] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.520473] usb usb1: Product: OHCI PCI host controller
[    0.520475] usb usb1: Manufacturer: Linux 6.9.2-arch1-1.3 ohci_hcd
[    0.520477] usb usb1: SerialNumber: 0000:00:12.0
[    0.520657] hub 1-0:1.0: USB hub found
[    0.520669] hub 1-0:1.0: 3 ports detected
[    0.520900] ehci-pci 0000:00:12.2: EHCI Host Controller
[    0.520907] ehci-pci 0000:00:12.2: new USB bus registered, assigned bus number 2
[    0.520912] ehci-pci 0000:00:12.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[    0.520923] ehci-pci 0000:00:12.2: debug port 1
[    0.520989] ehci-pci 0000:00:12.2: irq 17, io mem 0xfe02c000
[    0.528005] Freeing initrd memory: 50848K
[    0.533015] ehci-pci 0000:00:12.2: USB 2.0 started, EHCI 1.00
[    0.533088] usb usb2: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.09
[    0.533091] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.533094] usb usb2: Product: EHCI Host Controller
[    0.533096] usb usb2: Manufacturer: Linux 6.9.2-arch1-1.3 ehci_hcd
[    0.533097] usb usb2: SerialNumber: 0000:00:12.2
[    0.533252] hub 2-0:1.0: USB hub found
[    0.533261] hub 2-0:1.0: 6 ports detected
[    0.599674] hub 1-0:1.0: USB hub found
[    0.599686] hub 1-0:1.0: 3 ports detected
[    0.599839] ehci-pci 0000:00:13.2: EHCI Host Controller
[    0.599845] ehci-pci 0000:00:13.2: new USB bus registered, assigned bus number 3
[    0.599849] ehci-pci 0000:00:13.2: applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround
[    0.599866] ehci-pci 0000:00:13.2: debug port 1
[    0.599919] ehci-pci 0000:00:13.2: irq 19, io mem 0xfe029000
[    0.612952] ehci-pci 0000:00:13.2: USB 2.0 started, EHCI 1.00
[    0.613009] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.09
[    0.613013] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.613015] usb usb3: Product: EHCI Host Controller
[    0.613017] usb usb3: Manufacturer: Linux 6.9.2-arch1-1.3 ehci_hcd
[    0.613019] usb usb3: SerialNumber: 0000:00:13.2
[    0.613140] hub 3-0:1.0: USB hub found
[    0.613148] hub 3-0:1.0: 6 ports detected
[    0.613330] ohci-pci 0000:00:12.1: OHCI PCI host controller
[    0.613334] ohci-pci 0000:00:12.1: new USB bus registered, assigned bus number 4
[    0.613352] ohci-pci 0000:00:12.1: irq 16, io mem 0xfe02d000
[    0.673662] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 6.09
[    0.673667] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.673669] usb usb4: Product: OHCI PCI host controller
[    0.673671] usb usb4: Manufacturer: Linux 6.9.2-arch1-1.3 ohci_hcd
[    0.673673] usb usb4: SerialNumber: 0000:00:12.1
[    0.673843] hub 4-0:1.0: USB hub found
[    0.673854] hub 4-0:1.0: 3 ports detected
[    0.674209] ohci-pci 0000:00:13.0: OHCI PCI host controller
[    0.674217] ohci-pci 0000:00:13.0: new USB bus registered, assigned bus number 5
[    0.674260] ohci-pci 0000:00:13.0: irq 18, io mem 0xfe02b000
[    0.733607] usb usb5: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 6.09
[    0.733611] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.733614] usb usb5: Product: OHCI PCI host controller
[    0.733616] usb usb5: Manufacturer: Linux 6.9.2-arch1-1.3 ohci_hcd
[    0.733617] usb usb5: SerialNumber: 0000:00:13.0
[    0.733795] hub 5-0:1.0: USB hub found
[    0.733805] hub 5-0:1.0: 3 ports detected
[    0.734126] ohci-pci 0000:00:13.1: OHCI PCI host controller
[    0.734132] ohci-pci 0000:00:13.1: new USB bus registered, assigned bus number 6
[    0.734155] ohci-pci 0000:00:13.1: irq 18, io mem 0xfe02a000
[    0.777835] ata4: SATA link down (SStatus 0 SControl 300)
[    0.778006] ata1: SATA link down (SStatus 0 SControl 300)
[    0.784485] usb 2-1: new high-speed USB device number 2 using ehci-pci
[    0.793557] usb usb6: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 6.09
[    0.793561] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.793563] usb usb6: Product: OHCI PCI host controller
[    0.793565] usb usb6: Manufacturer: Linux 6.9.2-arch1-1.3 ohci_hcd
[    0.793566] usb usb6: SerialNumber: 0000:00:13.1
[    0.793784] hub 6-0:1.0: USB hub found
[    0.793794] hub 6-0:1.0: 3 ports detected
[    0.794124] ohci-pci 0000:00:14.5: OHCI PCI host controller
[    0.794130] ohci-pci 0000:00:14.5: new USB bus registered, assigned bus number 7
[    0.794149] ohci-pci 0000:00:14.5: irq 18, io mem 0xfe028000
[    0.853510] usb usb7: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 6.09
[    0.853514] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.853516] usb usb7: Product: OHCI PCI host controller
[    0.853518] usb usb7: Manufacturer: Linux 6.9.2-arch1-1.3 ohci_hcd
[    0.853519] usb usb7: SerialNumber: 0000:00:14.5
[    0.853737] hub 7-0:1.0: USB hub found
[    0.853747] hub 7-0:1.0: 2 ports detected
[    0.853995] usbcore: registered new interface driver usbserial_generic
[    0.854003] usbserial: USB Serial support registered for generic
[    0.854106] rtc_cmos 00:02: RTC can wake from S4
[    0.854346] rtc_cmos 00:02: registered as rtc0
[    0.854374] rtc_cmos 00:02: setting system clock to 2024-05-29T12:42:30 UTC (1716986550)
[    0.854408] rtc_cmos 00:02: alarms up to one month, 242 bytes nvram, hpet irqs
[    0.854453] amd_pstate: the _CPC object is not present in SBIOS or ACPI disabled
[    0.854657] ledtrig-cpu: registered to indicate activity on CPUs
[    0.855141] [drm] Initialized simpledrm 1.0.0 20200625 for simple-framebuffer.0 on minor 0
[    0.860055] Console: switching to colour frame buffer device 160x64
[    0.863471] simple-framebuffer simple-framebuffer.0: [drm] fb0: simpledrmdrmfb frame buffer device
[    0.863541] hid: raw HID events driver (C) Jiri Kosina
[    0.863645] drop_monitor: Initializing network drop monitor service
[    0.863986] NET: Registered PF_INET6 protocol family
[    0.871573] Segment Routing with IPv6
[    0.871576] RPL Segment Routing with IPv6
[    0.871596] In-situ OAM (IOAM) with IPv6
[    0.871637] NET: Registered PF_PACKET protocol family
[    0.871698] x86/pm: family 0x15 cpu detected, MSR saving is needed during suspending.
[    0.872216] microcode: Current revision: 0x06000852
[    0.872218] microcode: Updated early from: 0x06000822
[    0.872363] IPI shorthand broadcast: enabled
[    0.875084] sched_clock: Marking stable (875210984, -2518685)->(1777722556, -905030257)
[    0.875272] Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
[    0.875373] registered taskstats version 1
[    0.875705] Loading compiled-in X.509 certificates
[    0.880257] Loaded X.509 cert 'Build time autogenerated kernel key: 792580fa945f304d2a9a419b9cee8195831e651e'
[    0.882915] Key type .fscrypt registered
[    0.882917] Key type fscrypt-provisioning registered
[    0.883423] PM:   Magic number: 8:131:735
[    0.887139] RAS: Correctable Errors collector initialized.
[    0.900662] clk: Disabling unused clocks
[    0.900666] PM: genpd: Disabling unused power domains
[    0.932113] usb 2-1: New USB device found, idVendor=0bda, idProduct=b812, bcdDevice= 2.10
[    0.932119] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    0.932121] usb 2-1: Product: USB3.0 802.11ac 1200M Adapter
[    0.932123] usb 2-1: Manufacturer: Realtek
[    0.932124] usb 2-1: SerialNumber: 123456
[    0.941464] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    0.942251] ata3.00: ATA-8: TOSHIBA HDWD110, MS2OA8J0, max UDMA/133
[    0.942490] ata3.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[    0.943452] ata3.00: configured for UDMA/133
[    0.944601] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    0.944732] ata2.00: LPM support broken, forcing max_power
[    0.944760] ata2.00: ATA-11: Apacer AS340 120GB, AP612PE0, max UDMA/133
[    0.944790] ata2.00: 234441648 sectors, multi 16: LBA48 NCQ (depth 32), AA
[    0.945126] ata2.00: LPM support broken, forcing max_power
[    0.945429] ata2.00: configured for UDMA/133
[    0.958193] scsi 1:0:0:0: Direct-Access     ATA      Apacer AS340 120 2PE0 PQ: 0 ANSI: 5
[    0.958598] sd 1:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 GiB)
[    0.958602] scsi 2:0:0:0: Direct-Access     ATA      TOSHIBA HDWD110  A8J0 PQ: 0 ANSI: 5
[    0.958611] sd 1:0:0:0: [sda] Write Protect is off
[    0.958614] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    0.958630] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    0.958661] sd 1:0:0:0: [sda] Preferred minimum I/O size 512 bytes
[    0.958942] sd 2:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/932 GiB)
[    0.958945] sd 2:0:0:0: [sdb] 4096-byte physical blocks
[    0.958956] sd 2:0:0:0: [sdb] Write Protect is off
[    0.958958] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    0.958977] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    0.959011] sd 2:0:0:0: [sdb] Preferred minimum I/O size 4096 bytes
[    0.959334]  sda: sda1 sda2
[    0.959434] sd 1:0:0:0: [sda] Attached SCSI disk
[    0.985590]  sdb: sdb1 sdb2
[    0.985834] sd 2:0:0:0: [sdb] Attached SCSI disk
[    0.987971] Freeing unused decrypted memory: 2028K
[    0.988653] Freeing unused kernel image (initmem) memory: 3412K
[    0.988657] Write protecting the kernel read-only data: 32768k
[    0.989141] Freeing unused kernel image (rodata/data gap) memory: 1040K
[    1.032417] x86/mm: Checked W+X mappings: passed, no W+X pages found.
[    1.032421] rodata_test: all tests were successful
[    1.032425] Run /init as init process
[    1.032427]   with arguments:
[    1.032428]     /init
[    1.032429]   with environment:
[    1.032430]     HOME=/
[    1.032431]     TERM=linux
[    1.032432]     BOOT_IMAGE=/vmlinuz-linux
[    1.200858] xhci_hcd 0000:02:00.0: xHCI Host Controller
[    1.200869] xhci_hcd 0000:02:00.0: new USB bus registered, assigned bus number 8
[    1.200961] xhci_hcd 0000:02:00.0: hcc params 0x002841eb hci version 0x100 quirks 0x0000000000000890
[    1.201144] xhci_hcd 0000:02:00.0: xHCI Host Controller
[    1.201149] xhci_hcd 0000:02:00.0: new USB bus registered, assigned bus number 9
[    1.201153] xhci_hcd 0000:02:00.0: Host supports USB 3.0 SuperSpeed
[    1.201247] scsi host4: pata_atiixp
[    1.201335] usb usb8: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.09
[    1.201339] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.201342] usb usb8: Product: xHCI Host Controller
[    1.201358] usb usb8: Manufacturer: Linux 6.9.2-arch1-1.3 xhci-hcd
[    1.201361] usb usb8: SerialNumber: 0000:02:00.0
[    1.201406] scsi host5: pata_atiixp
[    1.201452] ata5: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xfa00 irq 14 lpm-pol 0
[    1.201455] ata6: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xfa08 irq 15 lpm-pol 0
[    1.201679] hub 8-0:1.0: USB hub found
[    1.201691] hub 8-0:1.0: 1 port detected
[    1.201851] usb usb9: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.09
[    1.201856] usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    1.201859] usb usb9: Product: xHCI Host Controller
[    1.201861] usb usb9: Manufacturer: Linux 6.9.2-arch1-1.3 xhci-hcd
[    1.201863] usb usb9: SerialNumber: 0000:02:00.0
[    1.202220] hub 9-0:1.0: USB hub found
[    1.202234] hub 9-0:1.0: 4 ports detected
[    1.267571] usb 1-3: new low-speed USB device number 2 using ohci-pci
[    1.454222] usb 8-1: new high-speed USB device number 2 using xhci_hcd
[    1.457506] tsc: Refined TSC clocksource calibration: 3322.063 MHz
[    1.457523] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2fe2b689782, max_idle_ns: 440795272807 ns
[    1.457602] clocksource: Switched to clocksource tsc
[    1.457630] usb 1-3: New USB device found, idVendor=0c45, idProduct=7603, bcdDevice= 1.06
[    1.457636] usb 1-3: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[    1.457639] usb 1-3: Product: USB Keyboard
[    1.481139] usbcore: registered new interface driver usbhid
[    1.481142] usbhid: USB HID core driver
[    1.486931] input: USB Keyboard as /devices/pci0000:00/0000:00:12.0/usb1/1-3/1-3:1.0/0003:0C45:7603.0001/input/input2
[    1.541271] hid-generic 0003:0C45:7603.0001: input,hidraw0: USB HID v1.11 Keyboard [USB Keyboard] on usb-0000:00:12.0-3/input0
[    1.541717] input: USB Keyboard Consumer Control as /devices/pci0000:00/0000:00:12.0/usb1/1-3/1-3:1.1/0003:0C45:7603.0002/input/input3
[    1.595598] usb 8-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20
[    1.595602] usb 8-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[    1.595604] usb 8-1: Product: USB2.0 Hub
[    1.596308] hub 8-1:1.0: USB hub found
[    1.596496] hub 8-1:1.0: 4 ports detected
[    1.597725] input: USB Keyboard System Control as /devices/pci0000:00/0000:00:12.0/usb1/1-3/1-3:1.1/0003:0C45:7603.0002/input/input4
[    1.597805] input: USB Keyboard as /devices/pci0000:00/0000:00:12.0/usb1/1-3/1-3:1.1/0003:0C45:7603.0002/input/input6
[    1.597946] hid-generic 0003:0C45:7603.0002: input,hiddev96,hidraw1: USB HID v1.11 Keyboard [USB Keyboard] on usb-0000:00:12.0-3/input1
[    2.087564] usb 4-1: new full-speed USB device number 2 using ohci-pci
[    2.282353] usb 4-1: New USB device found, idVendor=04d9, idProduct=a088, bcdDevice= 1.00
[    2.282365] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.282370] usb 4-1: Product: USB Gaming Mouse
[    2.282375] usb 4-1: Manufacturer: RH
[    2.289761] input: RH USB Gaming Mouse as /devices/pci0000:00/0000:00:12.1/usb4/4-1/4-1:1.0/0003:04D9:A088.0003/input/input7
[    2.344621] hid-generic 0003:04D9:A088.0003: input,hidraw2: USB HID v1.10 Keyboard [RH USB Gaming Mouse] on usb-0000:00:12.1-1/input0
[    2.352021] input: RH USB Gaming Mouse as /devices/pci0000:00/0000:00:12.1/usb4/4-1/4-1:1.1/0003:04D9:A088.0004/input/input8
[    2.352086] input: RH USB Gaming Mouse System Control as /devices/pci0000:00/0000:00:12.1/usb4/4-1/4-1:1.1/0003:04D9:A088.0004/input/input9
[    2.407892] input: RH USB Gaming Mouse Consumer Control as /devices/pci0000:00/0000:00:12.1/usb4/4-1/4-1:1.1/0003:04D9:A088.0004/input/input10
[    2.408041] hid-generic 0003:04D9:A088.0004: input,hiddev97,hidraw3: USB HID v1.10 Mouse [RH USB Gaming Mouse] on usb-0000:00:12.1-1/input1
[    2.411712] hid-generic 0003:04D9:A088.0005: hiddev98,hidraw4: USB HID v1.10 Device [RH USB Gaming Mouse] on usb-0000:00:12.1-1/input2
[    3.035241] EXT4-fs (sda2): mounted filesystem 963daeed-0888-4658-9f17-18bd343dfb2a r/w with ordered data mode. Quota mode: none.
[    3.204415] systemd[1]: systemd 255.7-1-arch running in system mode (+PAM +AUDIT -SELINUX -APPARMOR -IMA +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +XKBCOMMON +UTMP -SYSVINIT default-hierarchy=unified)
[    3.204423] systemd[1]: Detected architecture x86-64.
[    3.704252] systemd[1]: bpf-lsm: LSM BPF program attached
[    3.755371] systemd-fstab-generator[269]: Mount point  is not a valid path, ignoring.
[    3.755953] systemd-fstab-generator[269]: Mount point  is not a valid path, ignoring.
[    4.457554] random: crng init done
[    4.472946] zram: Added device: zram0
[    4.637985] systemd[1]: Queued start job for default target Graphical Interface.
[    4.678959] systemd[1]: Created slice Slice /system/dirmngr.
[    4.679369] systemd[1]: Created slice Slice /system/getty.
[    4.679736] systemd[1]: Created slice Slice /system/gpg-agent.
[    4.680110] systemd[1]: Created slice Slice /system/gpg-agent-browser.
[    4.680482] systemd[1]: Created slice Slice /system/gpg-agent-extra.
[    4.680878] systemd[1]: Created slice Slice /system/gpg-agent-ssh.
[    4.681254] systemd[1]: Created slice Slice /system/keyboxd.
[    4.681618] systemd[1]: Created slice Slice /system/modprobe.
[    4.681937] systemd[1]: Created slice Slice /system/systemd-fsck.
[    4.682266] systemd[1]: Created slice Slice /system/systemd-zram-setup.
[    4.682496] systemd[1]: Created slice User and Session Slice.
[    4.682557] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[    4.682603] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[    4.682749] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[    4.682768] systemd[1]: Expecting device /dev/disk/by-uuid/03ce297b-4be8-4886-953d-2d2cc4bd0862...
[    4.682776] systemd[1]: Expecting device /dev/disk/by-uuid/6BB1-1CFA...
[    4.682783] systemd[1]: Expecting device /dev/zram0...
[    4.682795] systemd[1]: Reached target Local Encrypted Volumes.
[    4.682813] systemd[1]: Reached target Local Integrity Protected Volumes.
[    4.682837] systemd[1]: Reached target Path Units.
[    4.682851] systemd[1]: Reached target Remote File Systems.
[    4.682861] systemd[1]: Reached target Slice Units.
[    4.682890] systemd[1]: Reached target Local Verity Protected Volumes.
[    4.682963] systemd[1]: Listening on Device-mapper event daemon FIFOs.
[    4.683296] systemd[1]: Listening on LVM2 poll daemon socket.
[    4.684820] systemd[1]: Listening on Process Core Dump Socket.
[    4.684936] systemd[1]: Listening on Journal Socket (/dev/log).
[    4.685041] systemd[1]: Listening on Journal Socket.
[    4.685173] systemd[1]: Listening on Network Service Netlink Socket.
[    4.685190] systemd[1]: TPM2 PCR Extension (Varlink) was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[    4.685489] systemd[1]: Listening on udev Control Socket.
[    4.685574] systemd[1]: Listening on udev Kernel Socket.
[    4.687027] systemd[1]: Mounting Huge Pages File System...
[    4.687760] systemd[1]: Mounting POSIX Message Queue File System...
[    4.688524] systemd[1]: Mounting Kernel Debug File System...
[    4.689247] systemd[1]: Mounting Kernel Trace File System...
[    4.690393] systemd[1]: Starting Create List of Static Device Nodes...
[    4.691389] systemd[1]: Starting Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling...
[    4.692560] systemd[1]: Starting Load Kernel Module configfs...
[    4.694984] systemd[1]: Starting Load Kernel Module dm_mod...
[    4.697704] systemd[1]: Starting Load Kernel Module drm...
[    4.698928] systemd[1]: Starting Load Kernel Module fuse...
[    4.699880] systemd[1]: Starting Load Kernel Module loop...
[    4.699948] systemd[1]: File System Check on Root Device was skipped because of an unmet condition check (ConditionPathIsReadWrite=!/).
[    4.702243] systemd[1]: Starting Journal Service...
[    4.705201] systemd[1]: Starting Load Kernel Modules...
[    4.706206] systemd[1]: Starting Generate network units from Kernel command line...
[    4.706241] systemd[1]: TPM2 PCR Machine ID Measurement was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[    4.707349] systemd[1]: Starting Remount Root and Kernel File Systems...
[    4.707431] systemd[1]: TPM2 SRK Setup (Early) was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[    4.709289] systemd[1]: Starting Coldplug All udev Devices...
[    4.711777] systemd[1]: Mounted Huge Pages File System.
[    4.711955] systemd[1]: Mounted POSIX Message Queue File System.
[    4.712065] systemd[1]: Mounted Kernel Debug File System.
[    4.712184] systemd[1]: Mounted Kernel Trace File System.
[    4.712458] systemd[1]: Finished Create List of Static Device Nodes.
[    4.712869] systemd[1]: modprobe@configfs.service: Deactivated successfully.
[    4.713131] systemd[1]: Finished Load Kernel Module configfs.
[    4.713552] systemd[1]: modprobe@drm.service: Deactivated successfully.
[    4.713739] systemd[1]: Finished Load Kernel Module drm.
[    4.714168] systemd[1]: modprobe@fuse.service: Deactivated successfully.
[    4.714388] systemd[1]: Finished Load Kernel Module fuse.
[    4.715895] systemd[1]: Mounting FUSE Control File System...
[    4.719435] systemd[1]: Mounting Kernel Configuration File System...
[    4.722528] systemd[1]: Starting Create Static Device Nodes in /dev gracefully...
[    4.722962] systemd[1]: Finished Generate network units from Kernel command line.
[    4.726581] loop: module loaded
[    4.726666] device-mapper: uevent: version 1.0.3
[    4.726785] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@lists.linux.dev
[    4.727625] systemd[1]: modprobe@dm_mod.service: Deactivated successfully.
[    4.727806] systemd[1]: Finished Load Kernel Module dm_mod.
[    4.728143] systemd[1]: modprobe@loop.service: Deactivated successfully.
[    4.728294] systemd[1]: Finished Load Kernel Module loop.
[    4.728436] systemd[1]: Mounted FUSE Control File System.
[    4.728536] systemd[1]: Mounted Kernel Configuration File System.
[    4.730091] systemd[1]: Repartition Root Disk was skipped because no trigger condition checks were met.
[    4.737696] EXT4-fs (sda2): re-mounted 963daeed-0888-4658-9f17-18bd343dfb2a r/w. Quota mode: none.
[    4.738458] systemd-journald[293]: Collecting audit messages is disabled.
[    4.738774] systemd[1]: Finished Remount Root and Kernel File Systems.
[    4.739317] sd 1:0:0:0: Attached scsi generic sg0 type 0
[    4.739357] sd 2:0:0:0: Attached scsi generic sg1 type 0
[    4.740284] systemd[1]: Rebuild Hardware Database was skipped because no trigger condition checks were met.
[    4.741389] systemd[1]: Starting Load/Save OS Random Seed...
[    4.741419] systemd[1]: TPM2 SRK Setup was skipped because of an unmet condition check (ConditionSecurity=measured-uki).
[    4.747471] Asymmetric key parser 'pkcs8' registered
[    4.748531] systemd[1]: Finished Load Kernel Modules.
[    4.749793] systemd[1]: Starting Apply Kernel Variables...
[    4.762719] systemd[1]: Finished Load/Save OS Random Seed.
[    4.766178] systemd[1]: Finished Apply Kernel Variables.
[    4.775775] systemd[1]: Finished Create Static Device Nodes in /dev gracefully.
[    4.776951] systemd[1]: Starting Create System Users...
[    4.799839] systemd[1]: Finished Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.
[    4.804706] systemd[1]: Started Journal Service.
[    4.816414] systemd-journald[293]: Received client request to flush runtime journal.
[    4.824979] systemd-journald[293]: /var/log/journal/ca3d73a04dc345538c9904a96756e41e/system.journal: Journal file uses a different sequence number ID, rotating.
[    4.824986] systemd-journald[293]: Rotating system journal.
[    4.984536] zram0: detected capacity change from 0 to 8388608
[    5.028103] mousedev: PS/2 mouse device common for all mice
[    5.029341] parport_pc 00:04: reported by Plug and Play ACPI
[    5.029425] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
[    5.049222] cryptd: max_cpu_qlen set to 1000
[    5.050369] ACPI Warning: SystemIO range 0x0000000000000B00-0x0000000000000B08 conflicts with OpRegion 0x0000000000000B00-0x0000000000000B0F (\SOR1) (20230628/utaddress-204)
[    5.050382] ACPI: OSL: Resource conflict; ACPI support missing from driver?
[    5.051092] acpi_cpufreq: overriding BIOS provided _PSD data
[    5.051936] input: PC Speaker as /devices/platform/pcspkr/input/input12
[    5.067613] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver
[    5.067731] sp5100-tco sp5100-tco: Failed to reserve MMIO or alternate MMIO region
[    5.067735] sp5100-tco sp5100-tco: probe with driver sp5100-tco failed with error -16
[    5.080852] AVX version of gcm_enc/dec engaged.
[    5.083989] AES CTR mode by8 optimization enabled
[    5.090062] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[    5.105231] r8169 0000:03:00.0 eth0: RTL8168g/8111g, e0:d5:5e:3b:15:1f, XID 4c0, IRQ 28
[    5.105238] r8169 0000:03:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[    5.109703] r8169 0000:03:00.0 enp3s0: renamed from eth0
[    5.134683] ppdev: user-space parallel port driver
[    5.162871] snd_hda_intel 0000:01:00.1: Disabling MSI
[    5.162884] snd_hda_intel 0000:01:00.1: Handle vga_switcheroo audio client
[    5.171548] Adding 4194300k swap on /dev/zram0.  Priority:100 extents:1 across:4194300k SSDsc
[    5.214513] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card1/input13
[    5.214589] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card1/input14
[    5.214658] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card1/input15
[    5.214726] input: HDA NVidia HDMI/DP,pcm=9 as /devices/pci0000:00/0000:00:02.0/0000:01:00.1/sound/card1/input16
[    5.308685] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC892: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:line
[    5.308693] snd_hda_codec_realtek hdaudioC0D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
[    5.308696] snd_hda_codec_realtek hdaudioC0D0:    hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
[    5.308698] snd_hda_codec_realtek hdaudioC0D0:    mono: mono_out=0x0
[    5.308700] snd_hda_codec_realtek hdaudioC0D0:    dig-out=0x11/0x0
[    5.308702] snd_hda_codec_realtek hdaudioC0D0:    inputs:
[    5.308704] snd_hda_codec_realtek hdaudioC0D0:      Front Mic=0x19
[    5.308706] snd_hda_codec_realtek hdaudioC0D0:      Rear Mic=0x18
[    5.308708] snd_hda_codec_realtek hdaudioC0D0:      Line=0x1a
[    5.326722] input: HDA ATI SB Front Mic as /devices/pci0000:00/0000:00:14.2/sound/card0/input17
[    5.326807] input: HDA ATI SB Rear Mic as /devices/pci0000:00/0000:00:14.2/sound/card0/input18
[    5.326871] input: HDA ATI SB Line as /devices/pci0000:00/0000:00:14.2/sound/card0/input19
[    5.329070] input: HDA ATI SB Line Out as /devices/pci0000:00/0000:00:14.2/sound/card0/input20
[    5.329531] input: HDA ATI SB Front Headphone as /devices/pci0000:00/0000:00:14.2/sound/card0/input21
[    5.340116] kvm_amd: TSC scaling supported
[    5.340120] kvm_amd: Nested Virtualization enabled
[    5.340121] kvm_amd: Nested Paging enabled
[    5.340128] kvm_amd: LBR virtualization supported
[    5.894238] EXT4-fs (sdb1): mounted filesystem 03ce297b-4be8-4886-953d-2d2cc4bd0862 r/w with ordered data mode. Quota mode: none.
[    6.784621] NET: Registered PF_ALG protocol family
[    6.847510] Generic FE-GE Realtek PHY r8169-0-300:00: attached PHY driver (mii_bus:phy_addr=r8169-0-300:00, irq=MAC)
[    7.037662] r8169 0000:03:00.0 enp3s0: Link is Down
[   12.862299] systemd-journald[293]: /var/log/journal/ca3d73a04dc345538c9904a96756e41e/user-1000.journal: Journal file uses a different sequence number ID, rotating.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply	[relevance 1%]

* Re: [PATCH v2 2/3] rust: block: add rnull, Rust null_blk implementation
  @ 2024-05-29 13:00  0%     ` Andreas Hindborg
  0 siblings, 0 replies; 200+ results
From: Andreas Hindborg @ 2024-05-29 13:00 UTC (permalink / raw)
  To: Benno Lossin
  Cc: Jens Axboe, Christoph Hellwig, Keith Busch, Damien Le Moal,
	Bart Van Assche, Hannes Reinecke, Ming Lei, linux-block,
	Andreas Hindborg, Greg KH, Matthew Wilcox, Miguel Ojeda,
	Alex Gaynor, Wedson Almeida Filho, Boqun Feng, Gary Guo,
	Björn Roy Baron, Alice Ryhl, Chaitanya Kulkarni,
	Luis Chamberlain, Yexuan Yang, Sergio González Collado,
	Joel Granados, Pankaj Raghav (Samsung),
	Daniel Gomez, Niklas Cassel, Philipp Stanner, Conor Dooley,
	Johannes Thumshirn, Matias Bjørling, open list,
	rust-for-linux, lsf-pc, gost.dev

Benno Lossin <benno.lossin@proton.me> writes:

> On 21.05.24 16:03, Andreas Hindborg wrote:
>> From: Andreas Hindborg <a.hindborg@samsung.com>
>> 
>> This patch adds an initial version of the Rust null block driver.
>> 
>> Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com>
>> ---
>>  drivers/block/Kconfig   |  9 +++++
>>  drivers/block/Makefile  |  3 ++
>>  drivers/block/rnull.rs  | 86 +++++++++++++++++++++++++++++++++++++++++
>>  rust/kernel/block/mq.rs |  4 +-
>>  4 files changed, 101 insertions(+), 1 deletion(-)
>>  create mode 100644 drivers/block/rnull.rs
>> 
>> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
>> index 5b9d4aaebb81..ed209f4f2798 100644
>> --- a/drivers/block/Kconfig
>> +++ b/drivers/block/Kconfig
>> @@ -354,6 +354,15 @@ config VIRTIO_BLK
>>  	  This is the virtual block driver for virtio.  It can be used with
>>            QEMU based VMMs (like KVM or Xen).  Say Y or M.
>> 
>> +config BLK_DEV_RUST_NULL
>> +	tristate "Rust null block driver (Experimental)"
>> +	depends on RUST
>> +	help
>> +	  This is the Rust implementation of the null block driver. For now it
>> +	  is only a minimal stub.
>> +
>> +	  If unsure, say N.
>> +
>>  config BLK_DEV_RBD
>>  	tristate "Rados block device (RBD)"
>>  	depends on INET && BLOCK
>> diff --git a/drivers/block/Makefile b/drivers/block/Makefile
>> index 101612cba303..1105a2d4fdcb 100644
>> --- a/drivers/block/Makefile
>> +++ b/drivers/block/Makefile
>> @@ -9,6 +9,9 @@
>>  # needed for trace events
>>  ccflags-y				+= -I$(src)
>> 
>> +obj-$(CONFIG_BLK_DEV_RUST_NULL) += rnull_mod.o
>> +rnull_mod-y := rnull.o
>> +
>>  obj-$(CONFIG_MAC_FLOPPY)	+= swim3.o
>>  obj-$(CONFIG_BLK_DEV_SWIM)	+= swim_mod.o
>>  obj-$(CONFIG_BLK_DEV_FD)	+= floppy.o
>> diff --git a/drivers/block/rnull.rs b/drivers/block/rnull.rs
>> new file mode 100644
>> index 000000000000..1d6ab6f0f26f
>> --- /dev/null
>> +++ b/drivers/block/rnull.rs
>> @@ -0,0 +1,86 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +//! This is a Rust implementation of the C null block driver.
>> +//!
>> +//! Supported features:
>> +//!
>> +//! - blk-mq interface
>> +//! - direct completion
>> +//! - block size 4k
>> +//!
>> +//! The driver is not configurable.
>> +
>> +use kernel::{
>> +    alloc::flags,
>> +    block::mq::{
>> +        self,
>> +        gen_disk::{self, GenDisk},
>> +        Operations, TagSet,
>> +    },
>> +    error::Result,
>> +    new_mutex, pr_info,
>> +    prelude::*,
>> +    sync::{Arc, Mutex},
>> +    types::ARef,
>> +};
>> +
>> +module! {
>> +    type: NullBlkModule,
>> +    name: "rnull_mod",
>> +    author: "Andreas Hindborg",
>> +    license: "GPL v2",
>> +}
>> +
>> +struct NullBlkModule {
>> +    _disk: Pin<Box<Mutex<GenDisk<NullBlkDevice, gen_disk::Added>>>>,
>> +}
>> +
>> +fn add_disk(tagset: Arc<TagSet<NullBlkDevice>>) -> Result<GenDisk<NullBlkDevice, gen_disk::Added>> {
>
> Any reason that this is its own function and not in the
> `NullBlkModule::init` function?

Would you embed it inside the `init` function? To what end? I don't
think that would read well.

>
>> +    let block_size: u16 = 4096;
>> +    if block_size % 512 != 0 || !(512..=4096).contains(&block_size) {
>> +        return Err(kernel::error::code::EINVAL);
>> +    }
>> +
>> +    let mut disk = gen_disk::try_new(tagset)?;
>> +    disk.set_name(format_args!("rnullb{}", 0))?;
>> +    disk.set_capacity_sectors(4096 << 11);
>> +    disk.set_queue_logical_block_size(block_size.into());
>> +    disk.set_queue_physical_block_size(block_size.into());
>> +    disk.set_rotational(false);
>> +    disk.add()
>> +}
>> +
>> +impl kernel::Module for NullBlkModule {
>> +    fn init(_module: &'static ThisModule) -> Result<Self> {
>> +        pr_info!("Rust null_blk loaded\n");
>> +        let tagset = Arc::pin_init(TagSet::try_new(1, 256, 1), flags::GFP_KERNEL)?;
>> +        let disk = Box::pin_init(
>> +            new_mutex!(add_disk(tagset)?, "nullb:disk"),
>> +            flags::GFP_KERNEL,
>> +        )?;
>> +
>> +        Ok(Self { _disk: disk })
>> +    }
>> +}
>> +
>> +struct NullBlkDevice;
>> +
>> +#[vtable]
>> +impl Operations for NullBlkDevice {
>> +    #[inline(always)]
>> +    fn queue_rq(rq: ARef<mq::Request<Self>>, _is_last: bool) -> Result {
>> +        mq::Request::end_ok(rq)
>> +            .map_err(|_e| kernel::error::code::EIO)
>> +            .expect("Failed to complete request");
>
> This error would only happen if `rq` is not the only ARef to that
> request, right?

Yes, it should never happen. If it happens, something is seriously
broken and panic is adequate.

Other drivers might want to retry later or something, but in this case
it should just work.

>
>> +
>> +        Ok(())
>> +    }
>> +
>> +    fn commit_rqs() {}
>> +
>> +    fn complete(rq: ARef<mq::Request<Self>>) {
>
> Am I correct in thinking that this function is never actually called,
> since all requests that are queued are immediately ended?

Yes, re my other email. It is a callback that cannot be triggered for
now. I will move it to a later patch where it belongs.

>
>> +        mq::Request::end_ok(rq)
>> +            .map_err(|_e| kernel::error::code::EIO)
>> +            .expect("Failed to complete request")
>> +    }
>> +}
>> diff --git a/rust/kernel/block/mq.rs b/rust/kernel/block/mq.rs
>> index efbd2588791b..54e032bbdffd 100644
>> --- a/rust/kernel/block/mq.rs
>> +++ b/rust/kernel/block/mq.rs
>> @@ -51,6 +51,7 @@
>>  //!
>>  //! ```rust
>>  //! use kernel::{
>> +//!     alloc::flags,
>>  //!     block::mq::*,
>>  //!     new_mutex,
>>  //!     prelude::*,
>> @@ -77,7 +78,8 @@
>>  //!     }
>>  //! }
>>  //!
>> -//! let tagset: Arc<TagSet<MyBlkDevice>> = Arc::pin_init(TagSet::try_new(1, 256, 1))?;
>> +//! let tagset: Arc<TagSet<MyBlkDevice>> =
>> +//!     Arc::pin_init(TagSet::try_new(1, 256, 1), flags::GFP_KERNEL)?;
>
> This change should probably be in the patch before (seems like an
> artifact from rebasing).

Yes, thank you for spotting that. I thought I checked that this was
building, so this is strange to me. Maybe I failed to build the
doctests between the two patches. It is weird that kernel robot did not
pick this up. Maybe it is not building doctests?


Best regards,
Andreas

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v5 02/23] hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine
  @ 2024-05-29 12:58  0%   ` Igor Mammedov
  0 siblings, 0 replies; 200+ results
From: Igor Mammedov @ 2024-05-29 12:58 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: qemu-devel, Thomas Huth, Paolo Bonzini, Michael S. Tsirkin,
	Daniel P . Berrangé,
	Zhao Liu

On Wed, 29 May 2024 07:15:18 +0200
Philippe Mathieu-Daudé <philmd@linaro.org> wrote:

> The pc-i440fx-2.0 machine was deprecated for the 8.2
> release (see commit c7437f0ddb "docs/about: Mark the
> old pc-i440fx-2.0 - 2.3 machine types as deprecated"),
> time to remove it.
> 
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

Reviewed-by: Igor Mammedov <imammedo@redhat.com>

> ---
>  docs/about/deprecated.rst       |  2 +-
>  docs/about/removed-features.rst |  2 +-
>  include/hw/i386/pc.h            |  3 ---
>  hw/i386/pc.c                    | 15 -------------
>  hw/i386/pc_piix.c               | 37 ---------------------------------
>  5 files changed, 2 insertions(+), 57 deletions(-)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 7ff52bdd8e..629f6a1566 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -228,7 +228,7 @@ deprecated; use the new name ``dtb-randomness`` instead. The new name
>  better reflects the way this property affects all random data within
>  the device tree blob, not just the ``kaslr-seed`` node.
>  
> -``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up to ``pc-i440fx-2.12`` (since 9.1)
> +``pc-i440fx-2.1`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up to ``pc-i440fx-2.12`` (since 9.1)
>  ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>  
>  These old machine types are quite neglected nowadays and thus might have
> diff --git a/docs/about/removed-features.rst b/docs/about/removed-features.rst
> index fba0cfb0b0..5f0c2d8ec2 100644
> --- a/docs/about/removed-features.rst
> +++ b/docs/about/removed-features.rst
> @@ -925,7 +925,7 @@ mips ``fulong2e`` machine alias (removed in 6.0)
>  
>  This machine has been renamed ``fuloong2e``.
>  
> -``pc-0.10`` up to ``pc-i440fx-1.7`` (removed in 4.0 up to 8.2)
> +``pc-0.10`` up to ``pc-i440fx-2.0`` (removed in 4.0 up to 9.0)
>  ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>  
>  These machine types were very old and likely could not be used for live
> diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
> index ad9c3d9ba8..7347636d47 100644
> --- a/include/hw/i386/pc.h
> +++ b/include/hw/i386/pc.h
> @@ -290,9 +290,6 @@ extern const size_t pc_compat_2_2_len;
>  extern GlobalProperty pc_compat_2_1[];
>  extern const size_t pc_compat_2_1_len;
>  
> -extern GlobalProperty pc_compat_2_0[];
> -extern const size_t pc_compat_2_0_len;
> -
>  #define DEFINE_PC_MACHINE(suffix, namestr, initfn, optsfn) \
>      static void pc_machine_##suffix##_class_init(ObjectClass *oc, void *data) \
>      { \
> diff --git a/hw/i386/pc.c b/hw/i386/pc.c
> index 7b638da7aa..11182e09ce 100644
> --- a/hw/i386/pc.c
> +++ b/hw/i386/pc.c
> @@ -319,21 +319,6 @@ GlobalProperty pc_compat_2_1[] = {
>  };
>  const size_t pc_compat_2_1_len = G_N_ELEMENTS(pc_compat_2_1);
>  
> -GlobalProperty pc_compat_2_0[] = {
> -    PC_CPU_MODEL_IDS("2.0.0")
> -    { "virtio-scsi-pci", "any_layout", "off" },
> -    { "PIIX4_PM", "memory-hotplug-support", "off" },
> -    { "apic", "version", "0x11" },
> -    { "nec-usb-xhci", "superspeed-ports-first", "off" },
> -    { "nec-usb-xhci", "force-pcie-endcap", "on" },
> -    { "pci-serial", "prog_if", "0" },
> -    { "pci-serial-2x", "prog_if", "0" },
> -    { "pci-serial-4x", "prog_if", "0" },
> -    { "virtio-net-pci", "guest_announce", "off" },
> -    { "ICH9-LPC", "memory-hotplug-support", "off" },
> -};
> -const size_t pc_compat_2_0_len = G_N_ELEMENTS(pc_compat_2_0);
> -
>  GSIState *pc_gsi_create(qemu_irq **irqs, bool pci_enabled)
>  {
>      GSIState *s;
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index 02878060d0..a750a0e6ab 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -441,11 +441,6 @@ static void pc_compat_2_1_fn(MachineState *machine)
>      x86_cpu_change_kvm_default("svm", NULL);
>  }
>  
> -static void pc_compat_2_0_fn(MachineState *machine)
> -{
> -    pc_compat_2_1_fn(machine);
> -}
> -
>  #ifdef CONFIG_ISAPC
>  static void pc_init_isa(MachineState *machine)
>  {
> @@ -887,38 +882,6 @@ static void pc_i440fx_2_1_machine_options(MachineClass *m)
>  DEFINE_I440FX_MACHINE(v2_1, "pc-i440fx-2.1", pc_compat_2_1_fn,
>                        pc_i440fx_2_1_machine_options);
>  
> -static void pc_i440fx_2_0_machine_options(MachineClass *m)
> -{
> -    PCMachineClass *pcmc = PC_MACHINE_CLASS(m);
> -
> -    pc_i440fx_2_1_machine_options(m);
> -    m->hw_version = "2.0.0";
> -    compat_props_add(m->compat_props, pc_compat_2_0, pc_compat_2_0_len);
> -    pcmc->smbios_legacy_mode = true;
> -    pcmc->has_reserved_memory = false;
> -    /* This value depends on the actual DSDT and SSDT compiled into
> -     * the source QEMU; unfortunately it depends on the binary and
> -     * not on the machine type, so we cannot make pc-i440fx-1.7 work on
> -     * both QEMU 1.7 and QEMU 2.0.
> -     *
> -     * Large variations cause migration to fail for more than one
> -     * consecutive value of the "-smp" maxcpus option.
> -     *
> -     * For small variations of the kind caused by different iasl versions,
> -     * the 4k rounding usually leaves slack.  However, there could be still
> -     * one or two values that break.  For QEMU 1.7 and QEMU 2.0 the
> -     * slack is only ~10 bytes before one "-smp maxcpus" value breaks!
> -     *
> -     * 6652 is valid for QEMU 2.0, the right value for pc-i440fx-1.7 on
> -     * QEMU 1.7 it is 6414.  For RHEL/CentOS 7.0 it is 6418.
> -     */
> -    pcmc->legacy_acpi_table_size = 6652;
> -    pcmc->acpi_data_size = 0x10000;
> -}
> -
> -DEFINE_I440FX_MACHINE(v2_0, "pc-i440fx-2.0", pc_compat_2_0_fn,
> -                      pc_i440fx_2_0_machine_options);
> -
>  #ifdef CONFIG_ISAPC
>  static void isapc_machine_options(MachineClass *m)
>  {



^ permalink raw reply	[relevance 0%]

* Re: [PATCH v12 06/10] drm/ttm/tests: Add tests with mock resource managers
  @ 2024-05-29 12:58  2%   ` Thomas Hellström
  0 siblings, 0 replies; 200+ results
From: Thomas Hellström @ 2024-05-29 12:58 UTC (permalink / raw)
  To: Karolina Stolarek, dri-devel
  Cc: Christian König, Matthew Auld, Amaranath Somalapuram

On Wed, 2024-05-15 at 13:24 +0200, Karolina Stolarek wrote:
> Add mock resource manager to test ttm_bo_validate() with non-system
> placements. Update KConfig entry to enable DRM Buddy allocator, used
> by the mock manager. Update move function to do more than just assign
> a resource.
> 
> Signed-off-by: Karolina Stolarek <karolina.stolarek@intel.com>
> Tested-by: Somalapuram, Amaranath <asomalap@amd.com>
> ---
>  drivers/gpu/drm/Kconfig                       |   1 +
>  drivers/gpu/drm/ttm/tests/.kunitconfig        |   1 +
>  drivers/gpu/drm/ttm/tests/Makefile            |   1 +
>  .../gpu/drm/ttm/tests/ttm_bo_validate_test.c  | 274
> ++++++++++++++++++
>  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  38 ++-
>  drivers/gpu/drm/ttm/tests/ttm_mock_manager.c  | 207 +++++++++++++
>  drivers/gpu/drm/ttm/tests/ttm_mock_manager.h  |  31 ++
>  7 files changed, 551 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.c
>  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_mock_manager.h
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index 026444eeb5c6..4ba16501dbf7 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -234,6 +234,7 @@ config DRM_TTM_KUNIT_TEST
>          default n
>          depends on DRM && KUNIT && MMU && (UML || COMPILE_TEST)
>          select DRM_TTM
> +        select DRM_BUDDY
>          select DRM_EXPORT_FOR_TESTS if m
>          select DRM_KUNIT_TEST_HELPERS
>          default KUNIT_ALL_TESTS
> diff --git a/drivers/gpu/drm/ttm/tests/.kunitconfig
> b/drivers/gpu/drm/ttm/tests/.kunitconfig
> index 1ae1ffabd51e..772f0e1f4103 100644
> --- a/drivers/gpu/drm/ttm/tests/.kunitconfig
> +++ b/drivers/gpu/drm/ttm/tests/.kunitconfig
> @@ -1,3 +1,4 @@
>  CONFIG_KUNIT=y
>  CONFIG_DRM=y
>  CONFIG_DRM_TTM_KUNIT_TEST=y
> +CONFIG_DRM_BUDDY=y

Is this strictly needed when CONFIG_DRM_TTM_KUNIT_TEST is selected?
Wouldn't that be enabled implicitly?

> diff --git a/drivers/gpu/drm/ttm/tests/Makefile
> b/drivers/gpu/drm/ttm/tests/Makefile
> index 2e5ed63fb414..f3149de77541 100644
> --- a/drivers/gpu/drm/ttm/tests/Makefile
> +++ b/drivers/gpu/drm/ttm/tests/Makefile
> @@ -7,4 +7,5 @@ obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
>          ttm_tt_test.o \
>          ttm_bo_test.o \
>          ttm_bo_validate_test.o \
> +        ttm_mock_manager.o \
>          ttm_kunit_helpers.o
> diff --git a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
> b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
> index a5520b0631a3..8b62d95b8ab8 100644
> --- a/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
> +++ b/drivers/gpu/drm/ttm/tests/ttm_bo_validate_test.c
> @@ -8,12 +8,15 @@
>  #include <drm/ttm/ttm_tt.h>
>  
>  #include "ttm_kunit_helpers.h"
> +#include "ttm_mock_manager.h"
>  
>  #define BO_SIZE		SZ_4K
> +#define MANAGER_SIZE	SZ_1M
>  
>  struct ttm_bo_validate_test_case {
>  	const char *description;
>  	enum ttm_bo_type bo_type;
> +	uint32_t mem_type;

Please use u32 instead of unit32_t in new code. The unit32_t usage in
TTM is a remnant from when much of the drm- and ttm code was shared
with *bsd. Same in a couple of places below.

>  	bool with_ttm;
>  };
>  
> @@ -102,6 +105,49 @@ static void ttm_bo_init_reserved_sys_man(struct
> kunit *test)
>  	ttm_bo_put(bo);
>  }
>  
> +static void ttm_bo_init_reserved_mock_man(struct kunit *test)
> +{
> +	const struct ttm_bo_validate_test_case *params = test-
> >param_value;
> +	enum ttm_bo_type bo_type = params->bo_type;
> +	struct ttm_test_devices *priv = test->priv;
> +	uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
> +	struct ttm_operation_ctx ctx = { };
> +	struct ttm_placement *placement;
> +	uint32_t mem_type = TTM_PL_VRAM;
> +	struct ttm_buffer_object *bo;
> +	struct ttm_place *place;
> +	int err;
> +
> +	ttm_mock_manager_init(priv->ttm_dev, mem_type,
> MANAGER_SIZE);
> +
> +	bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
> +	KUNIT_ASSERT_NOT_NULL(test, bo);
> +
> +	place = ttm_place_kunit_init(test, mem_type, 0);
> +	placement = ttm_placement_kunit_init(test, place, 1);
> +
> +	drm_gem_private_object_init(priv->drm, &bo->base, size);
> +
> +	err = ttm_bo_init_reserved(priv->ttm_dev, bo, bo_type,
> placement,
> +				   PAGE_SIZE, &ctx, NULL, NULL,
> +				   &dummy_ttm_bo_destroy);
> +	dma_resv_unlock(bo->base.resv);
> +
> +	KUNIT_EXPECT_EQ(test, err, 0);
> +	KUNIT_EXPECT_EQ(test, kref_read(&bo->kref), 1);
> +	KUNIT_EXPECT_PTR_EQ(test, bo->bdev, priv->ttm_dev);
> +	KUNIT_EXPECT_EQ(test, bo->type, bo_type);
> +	KUNIT_EXPECT_EQ(test, ctx.bytes_moved, size);
> +
> +	if (bo_type != ttm_bo_type_kernel)
> +		KUNIT_EXPECT_TRUE(test,
> +				  drm_mm_node_allocated(&bo-
> >base.vma_node.vm_node));
> +
> +	ttm_resource_free(bo, &bo->resource);
> +	ttm_bo_put(bo);
> +	ttm_mock_manager_fini(priv->ttm_dev, mem_type);
> +}
> +
>  static void ttm_bo_init_reserved_resv(struct kunit *test)
>  {
>  	enum ttm_bo_type bo_type = ttm_bo_type_device;
> @@ -136,6 +182,51 @@ static void ttm_bo_init_reserved_resv(struct
> kunit *test)
>  	ttm_bo_put(bo);
>  }
>  
> +static void ttm_bo_validate_basic(struct kunit *test)
> +{
> +	const struct ttm_bo_validate_test_case *params = test-
> >param_value;
> +	uint32_t fst_mem = TTM_PL_SYSTEM, snd_mem = TTM_PL_VRAM;
> +	struct ttm_operation_ctx ctx_init = { }, ctx_val = { };
> +	struct ttm_placement *fst_placement, *snd_placement;
> +	struct ttm_test_devices *priv = test->priv;
> +	struct ttm_place *fst_place, *snd_place;
> +	uint32_t size = ALIGN(SZ_8K, PAGE_SIZE);
> +	struct ttm_buffer_object *bo;
> +	int err;
> +
> +	ttm_mock_manager_init(priv->ttm_dev, snd_mem, MANAGER_SIZE);
> +
> +	fst_place = ttm_place_kunit_init(test, fst_mem, 0);
> +	fst_placement = ttm_placement_kunit_init(test, fst_place,
> 1);
> +
> +	bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
> +	KUNIT_ASSERT_NOT_NULL(test, bo);
> +
> +	drm_gem_private_object_init(priv->drm, &bo->base, size);
> +
> +	err = ttm_bo_init_reserved(priv->ttm_dev, bo, params-
> >bo_type,
> +				   fst_placement, PAGE_SIZE,
> &ctx_init, NULL,
> +				   NULL, &dummy_ttm_bo_destroy);
> +	KUNIT_EXPECT_EQ(test, err, 0);
> +
> +	snd_place = ttm_place_kunit_init(test, snd_mem,
> DRM_BUDDY_TOPDOWN_ALLOCATION);
> +	snd_placement = ttm_placement_kunit_init(test, snd_place,
> 1);
> +
> +	err = ttm_bo_validate(bo, snd_placement, &ctx_val);
> +	dma_resv_unlock(bo->base.resv);
> +
> +	KUNIT_EXPECT_EQ(test, err, 0);
> +	KUNIT_EXPECT_EQ(test, ctx_val.bytes_moved, bo->base.size);
> +	KUNIT_EXPECT_NOT_NULL(test, bo->ttm);
> +	KUNIT_EXPECT_TRUE(test, ttm_tt_is_populated(bo->ttm));
> +	KUNIT_EXPECT_EQ(test, bo->resource->mem_type, snd_mem);
> +	KUNIT_EXPECT_EQ(test, bo->resource->placement,
> +			DRM_BUDDY_TOPDOWN_ALLOCATION);
> +
> +	ttm_bo_put(bo);
> +	ttm_mock_manager_fini(priv->ttm_dev, snd_mem);
> +}
> +
>  static void ttm_bo_validate_invalid_placement(struct kunit *test)
>  {
>  	enum ttm_bo_type bo_type = ttm_bo_type_device;
> @@ -162,6 +253,36 @@ static void
> ttm_bo_validate_invalid_placement(struct kunit *test)
>  	ttm_bo_put(bo);
>  }
>  
> +static void ttm_bo_validate_failed_alloc(struct kunit *test)
> +{
> +	enum ttm_bo_type bo_type = ttm_bo_type_device;
> +	struct ttm_test_devices *priv = test->priv;
> +	uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
> +	struct ttm_operation_ctx ctx = { };
> +	struct ttm_placement *placement;
> +	uint32_t mem_type = TTM_PL_VRAM;
> +	struct ttm_buffer_object *bo;
> +	struct ttm_place *place;
> +	int err;
> +
> +	bo = ttm_bo_kunit_init(test, test->priv, size, NULL);
> +	bo->type = bo_type;
> +
> +	ttm_bad_manager_init(priv->ttm_dev, mem_type, MANAGER_SIZE);
> +
> +	place = ttm_place_kunit_init(test, mem_type, 0);
> +	placement = ttm_placement_kunit_init(test, place, 1);
> +
> +	ttm_bo_reserve(bo, false, false, NULL);
> +	err = ttm_bo_validate(bo, placement, &ctx);
> +	dma_resv_unlock(bo->base.resv);
> +
> +	KUNIT_EXPECT_EQ(test, err, -ENOMEM);
> +
> +	ttm_bo_put(bo);
> +	ttm_bad_manager_fini(priv->ttm_dev, mem_type);
> +}
> +
>  static void ttm_bo_validate_pinned(struct kunit *test)
>  {
>  	enum ttm_bo_type bo_type = ttm_bo_type_device;
> @@ -193,11 +314,164 @@ static void ttm_bo_validate_pinned(struct
> kunit *test)
>  	ttm_bo_put(bo);
>  }
>  
> +static const struct ttm_bo_validate_test_case ttm_mem_type_cases[] =
> {
> +	{
> +		.description = "System manager",
> +		.mem_type = TTM_PL_SYSTEM,
> +	},
> +	{
> +		.description = "VRAM manager",
> +		.mem_type = TTM_PL_VRAM,
> +	},
> +};
> +
> +KUNIT_ARRAY_PARAM(ttm_bo_validate_mem, ttm_mem_type_cases,
> +		  ttm_bo_validate_case_desc);
> +
> +static void ttm_bo_validate_same_placement(struct kunit *test)
> +{
> +	const struct ttm_bo_validate_test_case *params = test-
> >param_value;
> +	struct ttm_operation_ctx ctx_init = { }, ctx_val = { };
> +	struct ttm_test_devices *priv = test->priv;
> +	uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
> +	struct ttm_placement *placement;
> +	struct ttm_buffer_object *bo;
> +	struct ttm_place *place;
> +	int err;
> +
> +	place = ttm_place_kunit_init(test, params->mem_type, 0);
> +	placement = ttm_placement_kunit_init(test, place, 1);
> +
> +	if (params->mem_type != TTM_PL_SYSTEM)
> +		ttm_mock_manager_init(priv->ttm_dev, params-
> >mem_type, MANAGER_SIZE);
> +
> +	bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
> +	KUNIT_ASSERT_NOT_NULL(test, bo);
> +
> +	drm_gem_private_object_init(priv->drm, &bo->base, size);
> +
> +	err = ttm_bo_init_reserved(priv->ttm_dev, bo, params-
> >bo_type,
> +				   placement, PAGE_SIZE, &ctx_init,
> NULL,
> +				   NULL, &dummy_ttm_bo_destroy);
> +	KUNIT_EXPECT_EQ(test, err, 0);
> +
> +	err = ttm_bo_validate(bo, placement, &ctx_val);
> +	dma_resv_unlock(bo->base.resv);
> +
> +	KUNIT_EXPECT_EQ(test, err, 0);
> +	KUNIT_EXPECT_EQ(test, ctx_val.bytes_moved, 0);
> +
> +	ttm_bo_put(bo);
> +
> +	if (params->mem_type != TTM_PL_SYSTEM)
> +		ttm_mock_manager_fini(priv->ttm_dev, params-
> >mem_type);
> +}
> +
> +static void ttm_bo_validate_busy_placement(struct kunit *test)
> +{
> +	uint32_t fst_mem = TTM_PL_VRAM, snd_mem = TTM_PL_VRAM + 1;
> +	struct ttm_operation_ctx ctx_init = { }, ctx_val = { };
> +	struct ttm_placement *placement_init, *placement_val;
> +	enum ttm_bo_type bo_type = ttm_bo_type_device;
> +	struct ttm_test_devices *priv = test->priv;
> +	uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
> +	struct ttm_place *init_place, places[2];
> +	struct ttm_resource_manager *man;
> +	struct ttm_buffer_object *bo;
> +	int err;
> +
> +	ttm_bad_manager_init(priv->ttm_dev, fst_mem, MANAGER_SIZE);
> +	ttm_mock_manager_init(priv->ttm_dev, snd_mem, MANAGER_SIZE);
> +
> +	init_place = ttm_place_kunit_init(test, TTM_PL_SYSTEM, 0);
> +	placement_init = ttm_placement_kunit_init(test, init_place,
> 1);
> +
> +	bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
> +	KUNIT_ASSERT_NOT_NULL(test, bo);
> +
> +	drm_gem_private_object_init(priv->drm, &bo->base, size);
> +
> +	err = ttm_bo_init_reserved(priv->ttm_dev, bo, bo_type,
> placement_init,
> +				   PAGE_SIZE, &ctx_init, NULL, NULL,
> +				   &dummy_ttm_bo_destroy);
> +	KUNIT_EXPECT_EQ(test, err, 0);
> +
> +	places[0] = (struct ttm_place){ .mem_type = fst_mem, .flags
> = TTM_PL_FLAG_DESIRED };
> +	places[1] = (struct ttm_place){ .mem_type = snd_mem, .flags
> = TTM_PL_FLAG_FALLBACK };
> +	placement_val = ttm_placement_kunit_init(test, places, 2);
> +
> +	err = ttm_bo_validate(bo, placement_val, &ctx_val);
> +	dma_resv_unlock(bo->base.resv);
> +
> +	man = ttm_manager_type(priv->ttm_dev, snd_mem);
> +
> +	KUNIT_EXPECT_EQ(test, err, 0);
> +	KUNIT_EXPECT_EQ(test, ctx_val.bytes_moved, bo->base.size);
> +	KUNIT_EXPECT_EQ(test, bo->resource->mem_type, snd_mem);
> +	KUNIT_ASSERT_TRUE(test, list_is_singular(&man->lru[bo-
> >priority]));
> +
> +	ttm_bo_put(bo);
> +	ttm_bad_manager_fini(priv->ttm_dev, fst_mem);
> +	ttm_mock_manager_fini(priv->ttm_dev, snd_mem);
> +}
> +
> +static void ttm_bo_validate_multihop(struct kunit *test)
> +{
> +	const struct ttm_bo_validate_test_case *params = test-
> >param_value;
> +	struct ttm_operation_ctx ctx_init = { }, ctx_val = { };
> +	struct ttm_placement *placement_init, *placement_val;
> +	uint32_t fst_mem = TTM_PL_VRAM, tmp_mem = TTM_PL_TT,
> +		 final_mem = TTM_PL_SYSTEM;
> +	struct ttm_test_devices *priv = test->priv;
> +	struct ttm_place *fst_place, *final_place;
> +	uint32_t size = ALIGN(BO_SIZE, PAGE_SIZE);
> +	struct ttm_buffer_object *bo;
> +	int err;
> +
> +	ttm_mock_manager_init(priv->ttm_dev, fst_mem, MANAGER_SIZE);
> +	ttm_mock_manager_init(priv->ttm_dev, tmp_mem, MANAGER_SIZE);
> +
> +	fst_place = ttm_place_kunit_init(test, fst_mem, 0);
> +	placement_init = ttm_placement_kunit_init(test, fst_place,
> 1);
> +
> +	bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
> +	KUNIT_ASSERT_NOT_NULL(test, bo);
> +
> +	drm_gem_private_object_init(priv->drm, &bo->base, size);
> +
> +	err = ttm_bo_init_reserved(priv->ttm_dev, bo, params-
> >bo_type,
> +				   placement_init, PAGE_SIZE,
> &ctx_init, NULL,
> +				   NULL, &dummy_ttm_bo_destroy);
> +	KUNIT_EXPECT_EQ(test, err, 0);
> +
> +	final_place = ttm_place_kunit_init(test, final_mem, 0);
> +	placement_val = ttm_placement_kunit_init(test, final_place,
> 1);
> +
> +	err = ttm_bo_validate(bo, placement_val, &ctx_val);
> +	dma_resv_unlock(bo->base.resv);
> +
> +	KUNIT_EXPECT_EQ(test, err, 0);
> +	KUNIT_EXPECT_EQ(test, ctx_val.bytes_moved, size * 2);
> +	KUNIT_EXPECT_EQ(test, bo->resource->mem_type, final_mem);
> +
> +	ttm_bo_put(bo);
> +
> +	ttm_mock_manager_fini(priv->ttm_dev, fst_mem);
> +	ttm_mock_manager_fini(priv->ttm_dev, tmp_mem);
> +}
> +
>  static struct kunit_case ttm_bo_validate_test_cases[] = {
>  	KUNIT_CASE_PARAM(ttm_bo_init_reserved_sys_man,
> ttm_bo_types_gen_params),
> +	KUNIT_CASE_PARAM(ttm_bo_init_reserved_mock_man,
> ttm_bo_types_gen_params),
>  	KUNIT_CASE(ttm_bo_init_reserved_resv),
> +	KUNIT_CASE_PARAM(ttm_bo_validate_basic,
> ttm_bo_types_gen_params),
>  	KUNIT_CASE(ttm_bo_validate_invalid_placement),
> +	KUNIT_CASE_PARAM(ttm_bo_validate_same_placement,
> +			 ttm_bo_validate_mem_gen_params),
> +	KUNIT_CASE(ttm_bo_validate_failed_alloc),
>  	KUNIT_CASE(ttm_bo_validate_pinned),
> +	KUNIT_CASE(ttm_bo_validate_busy_placement),
> +	KUNIT_CASE_PARAM(ttm_bo_validate_multihop,
> ttm_bo_types_gen_params),
>  	{}
>  };
>  
> diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
> b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
> index 2f590bae53f8..2a2585b37118 100644
> --- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
> +++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
> @@ -27,8 +27,42 @@ static int mock_move(struct ttm_buffer_object *bo,
> bool evict,
>  		     struct ttm_resource *new_mem,
>  		     struct ttm_place *hop)
>  {
> -	bo->resource = new_mem;
> -	return 0;
> +	struct ttm_resource *old_mem = bo->resource;
> +	int ret;
> +
> +	if (!old_mem || (old_mem->mem_type == TTM_PL_SYSTEM && !bo-
> >ttm)) {
> +		ttm_bo_move_null(bo, new_mem);
> +		return 0;
> +	}
> +
> +	if (bo->resource->mem_type == TTM_PL_VRAM &&
> +	    new_mem->mem_type == TTM_PL_SYSTEM) {
> +		hop->mem_type = TTM_PL_TT;
> +		hop->flags = TTM_PL_FLAG_TEMPORARY;
> +		hop->fpfn = 0;
> +		hop->lpfn = 0;
> +		return -EMULTIHOP;
> +	}
> +
> +	if (old_mem->mem_type == TTM_PL_SYSTEM &&
> +	    new_mem->mem_type == TTM_PL_TT) {
> +		ttm_bo_move_null(bo, new_mem);
> +		return 0;
> +	}
> +
> +	if (old_mem->mem_type == TTM_PL_TT &&
> +	    new_mem->mem_type == TTM_PL_SYSTEM) {
> +		ret = ttm_bo_wait_ctx(bo, ctx);

We're not doing any accelerated move here, so ttm_bo_move_null() should
be sufficient also in this case?

> +
> +		if (ret)
> +			return ret;
> +
> +		ttm_resource_free(bo, &bo->resource);
> +		ttm_bo_assign_mem(bo, new_mem);
> +		return 0;
> +	}
> +
> +	return ttm_bo_move_memcpy(bo, ctx, new_mem);

Do we hit this move_memcpy()? Since the mock manager doesn't actually
reserve any memory to manager, I'd expect this to run into problems?



>  }
>  
>  struct ttm_device_funcs ttm_dev_funcs = {
> diff --git a/drivers/gpu/drm/ttm/tests/ttm_mock_manager.c
> b/drivers/gpu/drm/ttm/tests/ttm_mock_manager.c
> new file mode 100644
> index 000000000000..eb9dca1de1a2
> --- /dev/null
> +++ b/drivers/gpu/drm/ttm/tests/ttm_mock_manager.c
> @@ -0,0 +1,207 @@
> +// SPDX-License-Identifier: GPL-2.0 AND MIT
> +/*
> + * Copyright © 2023 Intel Corporation
> + */
> +#include <drm/ttm/ttm_resource.h>
> +#include <drm/ttm/ttm_device.h>
> +#include <drm/ttm/ttm_placement.h>
> +
> +#include "ttm_mock_manager.h"
> +
> +static inline struct ttm_mock_manager *
> +to_mock_mgr(struct ttm_resource_manager *man)
> +{
> +	return container_of(man, struct ttm_mock_manager, man);
> +}
> +
> +static inline struct ttm_mock_resource *
> +to_mock_mgr_resource(struct ttm_resource *res)
> +{
> +	return container_of(res, struct ttm_mock_resource, base);
> +}
> +
> +static int ttm_mock_manager_alloc(struct ttm_resource_manager *man,
> +				  struct ttm_buffer_object *bo,
> +				  const struct ttm_place *place,
> +				  struct ttm_resource **res)
> +{
> +	struct ttm_mock_manager *manager = to_mock_mgr(man);
> +	struct ttm_mock_resource *mock_res;
> +	struct drm_buddy *mm = &manager->mm;
> +	uint64_t lpfn, fpfn, alloc_size;
> +	int err;
> +
> +	mock_res = kzalloc(sizeof(*mock_res), GFP_KERNEL);
> +
> +	if (!mock_res)
> +		return -ENOMEM;
> +
> +	fpfn = 0;
> +	lpfn = man->size;
> +
> +	ttm_resource_init(bo, place, &mock_res->base);
> +	INIT_LIST_HEAD(&mock_res->blocks);
> +
> +	if (place->flags & TTM_PL_FLAG_TOPDOWN)
> +		mock_res->flags |= DRM_BUDDY_TOPDOWN_ALLOCATION;
> +
> +	if (place->flags & TTM_PL_FLAG_CONTIGUOUS)
> +		mock_res->flags |= DRM_BUDDY_CONTIGUOUS_ALLOCATION;
> +
> +	alloc_size = (uint64_t)mock_res->base.size;
> +	mutex_lock(&manager->lock);
> +	err = drm_buddy_alloc_blocks(mm, fpfn, lpfn, alloc_size,
> +				     manager->default_page_size,
> +				     &mock_res->blocks,
> +				     mock_res->flags);
> +
> +	if (err)
> +		goto error_free_blocks;
> +	mutex_unlock(&manager->lock);
> +
> +	*res = &mock_res->base;
> +	return 0;
> +
> +error_free_blocks:
> +	drm_buddy_free_list(mm, &mock_res->blocks, 0);
> +	ttm_resource_fini(man, &mock_res->base);
> +	mutex_unlock(&manager->lock);
> +
> +	return err;
> +}
> +
> +static void ttm_mock_manager_free(struct ttm_resource_manager *man,
> +				  struct ttm_resource *res)
> +{
> +	struct ttm_mock_manager *manager = to_mock_mgr(man);
> +	struct ttm_mock_resource *mock_res =
> to_mock_mgr_resource(res);
> +	struct drm_buddy *mm = &manager->mm;
> +
> +	mutex_lock(&manager->lock);
> +	drm_buddy_free_list(mm, &mock_res->blocks, 0);
> +	mutex_unlock(&manager->lock);
> +
> +	ttm_resource_fini(man, res);
> +	kfree(mock_res);
> +}
> +
> +static const struct ttm_resource_manager_func ttm_mock_manager_funcs
> = {
> +	.alloc = ttm_mock_manager_alloc,
> +	.free = ttm_mock_manager_free,
> +};
> +
> +int ttm_mock_manager_init(struct ttm_device *bdev, uint32_t
> mem_type, uint32_t size)
> +{
> +	struct ttm_mock_manager *manager;
> +	struct ttm_resource_manager *base;
> +	int err;
> +
> +	manager = kzalloc(sizeof(*manager), GFP_KERNEL);
> +	if (!manager)
> +		return -ENOMEM;
> +
> +	mutex_init(&manager->lock);
> +
> +	err = drm_buddy_init(&manager->mm, size, PAGE_SIZE);
> +
> +	if (err) {
> +		kfree(manager);
> +		return err;
> +	}
> +
> +	manager->default_page_size = PAGE_SIZE;
> +	base = &manager->man;
> +	base->func = &ttm_mock_manager_funcs;
> +	base->use_tt = true;
> +
> +	ttm_resource_manager_init(base, bdev, size);
> +	ttm_set_driver_manager(bdev, mem_type, base);
> +	ttm_resource_manager_set_used(base, true);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(ttm_mock_manager_init);
> +
> +void ttm_mock_manager_fini(struct ttm_device *bdev, uint32_t
> mem_type)
> +{
> +	struct ttm_resource_manager *man;
> +	struct ttm_mock_manager *mock_man;
> +	int err;
> +
> +	man = ttm_manager_type(bdev, mem_type);
> +	mock_man = to_mock_mgr(man);
> +
> +	err = ttm_resource_manager_evict_all(bdev, man);
> +	if (err)
> +		return;
> +
> +	ttm_resource_manager_set_used(man, false);
> +
> +	mutex_lock(&mock_man->lock);
> +	drm_buddy_fini(&mock_man->mm);
> +	mutex_unlock(&mock_man->lock);
> +
> +	ttm_set_driver_manager(bdev, mem_type, NULL);
> +}
> +EXPORT_SYMBOL_GPL(ttm_mock_manager_fini);
> +
> +static int ttm_bad_manager_alloc(struct ttm_resource_manager *man,
> +				 struct ttm_buffer_object *bo,
> +				 const struct ttm_place *place,
> +				 struct ttm_resource **res)
> +{
> +	return -ENOSPC;
> +}
> +
> +static void ttm_bad_manager_free(struct ttm_resource_manager *man,
> +				 struct ttm_resource *res)
> +{
> +}
> +
> +static bool ttm_bad_manager_compatible(struct ttm_resource_manager
> *man,
> +				       struct ttm_resource *res,
> +				       const struct ttm_place
> *place,
> +				       size_t size)
> +{
> +	return true;
> +}
> +
> +static const struct ttm_resource_manager_func ttm_bad_manager_funcs
> = {
> +	.alloc = ttm_bad_manager_alloc,
> +	.free = ttm_bad_manager_free,
> +	.compatible = ttm_bad_manager_compatible
> +};
> +
> +int ttm_bad_manager_init(struct ttm_device *bdev, uint32_t mem_type,
> +			 uint32_t size)
> +{
> +	struct ttm_resource_manager *man;
> +
> +	man = kzalloc(sizeof(*man), GFP_KERNEL);
> +	if (!man)
> +		return -ENOMEM;
> +
> +	man->func = &ttm_bad_manager_funcs;
> +
> +	ttm_resource_manager_init(man, bdev, size);
> +	ttm_set_driver_manager(bdev, mem_type, man);
> +	ttm_resource_manager_set_used(man, true);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(ttm_bad_manager_init);
> +
> +void ttm_bad_manager_fini(struct ttm_device *bdev, uint32_t
> mem_type)
> +{
> +	struct ttm_resource_manager *man;
> +
> +	man = ttm_manager_type(bdev, mem_type);
> +
> +	ttm_resource_manager_set_used(man, false);
> +	ttm_set_driver_manager(bdev, mem_type, NULL);
> +
> +	kfree(man);
> +}
> +EXPORT_SYMBOL_GPL(ttm_bad_manager_fini);
> +
> +MODULE_LICENSE("GPL");

When the module is dual-licensed IIRC the correct option to use here is
"GPL and additional rights"

> diff --git a/drivers/gpu/drm/ttm/tests/ttm_mock_manager.h
> b/drivers/gpu/drm/ttm/tests/ttm_mock_manager.h
> new file mode 100644
> index 000000000000..d2db9de9d876
> --- /dev/null
> +++ b/drivers/gpu/drm/ttm/tests/ttm_mock_manager.h
> @@ -0,0 +1,31 @@
> +/* SPDX-License-Identifier: GPL-2.0 AND MIT */
> +/*
> + * Copyright © 2023 Intel Corporation
> + */
> +#ifndef TTM_MOCK_MANAGER_H
> +#define TTM_MOCK_MANAGER_H
> +
> +#include <drm/drm_buddy.h>
> +
> +struct ttm_mock_manager {
> +	struct ttm_resource_manager man;
> +	struct drm_buddy mm;
> +	uint64_t default_page_size;
> +	/* protects allocations of mock buffer objects */
> +	struct mutex lock;
> +};
> +
> +struct ttm_mock_resource {
> +	struct ttm_resource base;
> +	struct list_head blocks;
> +	unsigned long flags;
> +};
> +
> +int ttm_mock_manager_init(struct ttm_device *bdev, uint32_t
> mem_type,
> +			  uint32_t size);
> +int ttm_bad_manager_init(struct ttm_device *bdev, uint32_t mem_type,
> +			 uint32_t size);
> +void ttm_mock_manager_fini(struct ttm_device *bdev, uint32_t
> mem_type);
> +void ttm_bad_manager_fini(struct ttm_device *bdev, uint32_t
> mem_type);
> +
> +#endif // TTM_MOCK_MANAGER_H

Thanks,
Thomas


^ permalink raw reply	[relevance 2%]

* RE: [PATCH v2] net/af_xdp: fix umem map size for zero copy
  @ 2024-05-29 12:57  0%               ` Loftus, Ciara
  0 siblings, 0 replies; 200+ results
From: Loftus, Ciara @ 2024-05-29 12:57 UTC (permalink / raw)
  To: Du, Frank, Morten Brørup
  Cc: Ferruh Yigit, dev, Andrew Rybchenko, Burakov, Anatoly



> -----Original Message-----
> From: Du, Frank <frank.du@intel.com>
> Sent: Thursday, May 23, 2024 8:56 AM
> To: Morten Brørup <mb@smartsharesystems.com>; Ferruh Yigit
> <ferruh.yigit@amd.com>; dev@dpdk.org; Andrew Rybchenko
> <andrew.rybchenko@oktetlabs.ru>; Burakov, Anatoly
> <anatoly.burakov@intel.com>
> Cc: Loftus, Ciara <ciara.loftus@intel.com>
> Subject: RE: [PATCH v2] net/af_xdp: fix umem map size for zero copy
> 
> > -----Original Message-----
> > From: Morten Brørup <mb@smartsharesystems.com>
> > Sent: Thursday, May 23, 2024 3:41 PM
> > To: Du, Frank <frank.du@intel.com>; Ferruh Yigit <ferruh.yigit@amd.com>;
> > dev@dpdk.org; Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>;
> Burakov,
> > Anatoly <anatoly.burakov@intel.com>
> > Cc: Loftus, Ciara <ciara.loftus@intel.com>
> > Subject: RE: [PATCH v2] net/af_xdp: fix umem map size for zero copy
> >
> > > From: Du, Frank [mailto:frank.du@intel.com]
> > > Sent: Thursday, 23 May 2024 08.56
> > >
> > > > From: Morten Brørup <mb@smartsharesystems.com>
> > > > Sent: Wednesday, May 22, 2024 3:27 PM
> > > >
> > > > > From: Du, Frank [mailto:frank.du@intel.com]
> > > > > Sent: Wednesday, 22 May 2024 03.25
> > > > >
> > > > > > From: Ferruh Yigit <ferruh.yigit@amd.com>
> > > > > > Sent: Wednesday, May 22, 2024 1:58 AM
> > > > > >
> > > > > > On 5/11/2024 6:26 AM, Frank Du wrote:
> > > > > > > The current calculation assumes that the mbufs are contiguous.
> > > > > > > However, this assumption is incorrect when the memory spans
> > > > > > > across a huge
> > > > > > page.
> >
> > What does "the memory spans across a huge page" mean?
> >
> > Should it be "the memory spans across multiple memory chunks"?
> 
> This does not pertain to multiple memory chunks but rather to mbuf memory.
> The scenario involves a single memory chunk utilizing multiple 2M pages. To
> ensure that each mbuf resides exclusively within a single page, there are
> deliberate spacing gaps when allocating mbufs across the 2M page
> boundaries.
> 
> >
> > > > > > > Correct to directly read the size from the mempool memory chunks.
> > > > > > >
> > > > > > > Signed-off-by: Frank Du <frank.du@intel.com>
> > > > > > >
> > > > > > > ---
> > > > > > > v2:
> > > > > > > * Add virtual contiguous detect for for multiple memhdrs.
> > > > > > > ---
> > > > > > >  drivers/net/af_xdp/rte_eth_af_xdp.c | 34
> > > > > > > ++++++++++++++++++++++++-----
> > > > > > >  1 file changed, 28 insertions(+), 6 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/net/af_xdp/rte_eth_af_xdp.c
> > > > > > > b/drivers/net/af_xdp/rte_eth_af_xdp.c
> > > > > > > index 268a130c49..7456108d6d 100644
> > > > > > > --- a/drivers/net/af_xdp/rte_eth_af_xdp.c
> > > > > > > +++ b/drivers/net/af_xdp/rte_eth_af_xdp.c
> > > > > > > @@ -1039,16 +1039,35 @@ eth_link_update(struct rte_eth_dev
> > > > > > > *dev __rte_unused,  }
> > > > > > >
> > > > > > >  #if defined(XDP_UMEM_UNALIGNED_CHUNK_FLAG)
> > > > > > > -static inline uintptr_t get_base_addr(struct rte_mempool *mp,
> > > > > > > uint64_t *align)
> > > > > > > +static inline uintptr_t get_memhdr_info(struct rte_mempool
> > > > > > > +*mp, uint64_t *align, size_t *len)
> > > > > > >  {
> > > > > > > -	struct rte_mempool_memhdr *memhdr;
> > > > > > > +	struct rte_mempool_memhdr *memhdr, *next;
> > > > > > >  	uintptr_t memhdr_addr, aligned_addr;
> > > > > > > +	size_t memhdr_len = 0;
> > > > > > >
> > > > > > > +	/* get the mempool base addr and align */
> > > > > > >  	memhdr = STAILQ_FIRST(&mp->mem_list);
> > > > > > >  	memhdr_addr = (uintptr_t)memhdr->addr;
> > > >
> > > > This is not a new bug; but if the mempool is not populated, memhdr
> > > > is NULL
> > > here.
> > >
> > > Thanks, will add a check later.
> > >
> > > >
> > > > > > >  	aligned_addr = memhdr_addr & ~(getpagesize() - 1);
> > > > > > >  	*align = memhdr_addr - aligned_addr;
> > > > > > >
> > > > > >
> > > > > > I am aware this is not part of this patch, but as note, can't we
> > > > > > use 'RTE_ALIGN_FLOOR' to calculate aligned address.
> > > > >
> > > > > Sure, will use RTE_ALIGN_FLOOR in next version.
> > > > >
> > > > > >
> > > > > >
> > > > > > > +	memhdr_len += memhdr->len;
> > > > > > > +
> > > > > > > +	/* check if virtual contiguous memory for multiple memhdrs
> */
> > > > > > > +	next = STAILQ_NEXT(memhdr, next);
> > > > > > > +	while (next != NULL) {
> > > > > > > +		if ((uintptr_t)next->addr != (uintptr_t)memhdr->addr
> +
> > > memhdr-
> > > > > > >len) {
> > > > > > > +			AF_XDP_LOG(ERR, "memory chunks not
> virtual
> > > > > > contiguous, "
> > > > > > > +					"next: %p, cur: %p(len: %"
> > PRId64
> > > > > > " )\n",
> > > > > > > +					next->addr, memhdr->addr,
> > memhdr-
> > > > > > >len);
> > > > > > > +			return 0;
> > > > > > > +		}
> > > > > > >
> > > > > >
> > > > > > Isn't there a mempool flag that can help us figure out mempool
> > > > > > is not IOVA contiguous? Isn't it sufficient on its own?
> > > > >
> > > > > Indeed, what we need to ascertain is whether it's contiguous in
> > > > > CPU virtual space, not IOVA. I haven't come across a flag
> > > > > specifically for CPU virtual contiguity. The major limitation in
> > > > > XDP is XSK UMEM only supports registering a single contiguous virtual
> > memory area.
> > > >
> > > > I would assume that the EAL memory manager merges free memory into
> > > > contiguous chunks whenever possible.
> > > > @Anatoly, please confirm?
> > > >
> > > > If my assumption is correct, it means that if mp->nb_mem_chunks !=
> > > > 1, then
> > > the
> > > > mempool is not virtual contiguous. And if mp->nb_mem_chunks == 1,
> > > > then it
> > > is;
> > > > there is no need to iterate through the memhdr list.
> > >
> > > If this's true now, however, this assumption may not hold true in the
> > > future code change, iterating through the list may is a safer way as
> > > it carefully checks the virtual address without relying on any condition.
> >
> > If there is exactly one memory chunk, it is virtual contiguous. It has one
> address
> > and one length, so it must be.
> >
> > If there are more than one memory chunk, I consider it unlikely that they are
> > contiguous.
> > Have you ever observed the opposite, i.e. a mempool with multiple memory
> > chunks being virtual contiguous?
> >
> > Iterating through the list does not seem safer to me, quite the opposite.
> > Which future change are you trying to prepare for?
> >
> > Keeping it simple is more likely to not break with future changes.
> 
> No, I haven't encountered a mempool with multiple memory chunks actually,
> not know how to construct such mempool. The initial approach was to return
> an error if multiple chunks were detected, and the iteration method was
> introduced later. I can revert to the original, simpler way.

The mempool created in my (virtualized) test environment always has multiple memory chunks and the iterative check for virtual contiguity in v2 of this patch succeeds for me.
However in v4, since mp->nb_mem_chunks != 1, it will fail for me.
So it appears that virtual contiguity is possible even if mp->nb_mem_chunks != 1 so I don't think we can rely on that value for determining virtual contiguity.


^ permalink raw reply	[relevance 0%]

* Re: [DO NOT MERGE v8 08/36] clocksource: sh_tmu: CLOCKSOURCE support.
  @ 2024-05-29 12:55  1%   ` Andy Shevchenko
  0 siblings, 0 replies; 200+ results
From: Andy Shevchenko @ 2024-05-29 12:55 UTC (permalink / raw)
  To: Yoshinori Sato
  Cc: linux-sh, Damien Le Moal, Niklas Cassel, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
	Michael Turquette, Stephen Boyd, David Airlie, Daniel Vetter,
	Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
	Thomas Gleixner, Bjorn Helgaas, Lorenzo Pieralisi,
	Krzysztof Wilczyński, Greg Kroah-Hartman, Jiri Slaby,
	Magnus Damm, Daniel Lezcano, Rich Felker,
	John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
	Heiko Stuebner, Neil Armstrong, Chris Morgan, Sebastian Reichel,
	Linus Walleij, Arnd Bergmann, Masahiro Yamada, Baoquan He,
	Andrew Morton, Guenter Roeck, Kefeng Wang, Stephen Rothwell,
	Azeem Shaikh, Guo Ren, Max Filippov, Jernej Skrabec,
	Herve Codina, Anup Patel, Jacky Huang, Hugo Villeneuve,
	Jonathan Corbet, Wolfram Sang, Uwe Kleine-König,
	Christophe JAILLET, Sam Ravnborg, Javier Martinez Canillas,
	Sergey Shtylyov, Laurent Pinchart, linux-ide, devicetree,
	linux-kernel, linux-renesas-soc, linux-clk, dri-devel, linux-pci,
	linux-serial, linux-fbdev

On Wed, May 29, 2024 at 05:00:54PM +0900, Yoshinori Sato wrote:
> Allows initialization as CLOCKSOURCE.

...

> -	dev_info(&ch->tmu->pdev->dev, "ch%u: used for %s clock events\n",
> -		 ch->index, periodic ? "periodic" : "oneshot");
> +	pr_info("%s ch%u: used for %s clock events\n",
> +		ch->tmu->name, ch->index, periodic ? "periodic" : "oneshot");

This is a step back change. We should use dev_*() if we have a device
available. And I believe this is the case (at least for the previous boards),
no?

...

> -	ch->irq = platform_get_irq(tmu->pdev, index);
> +	if (tmu->np)
> +		ch->irq = of_irq_get(tmu->np, index);
> +	else if (tmu->pdev)
> +		ch->irq = platform_get_irq(tmu->pdev, index);

I found these changes counterproductive. Instead better to have up to three
files to cover:
- the common code (library)
- the platform device support
- the pure OF support.

...

> -	res = platform_get_resource(tmu->pdev, IORESOURCE_MEM, 0);
> -	if (!res) {
> -		dev_err(&tmu->pdev->dev, "failed to get I/O memory\n");
> -		return -ENXIO;
> +	if (tmu->pdev) {
> +		res = platform_get_resource(tmu->pdev, IORESOURCE_MEM, 0);
> +		if (!res) {
> +			pr_err("sh_tmu failed to get I/O memory\n");
> +			return -ENXIO;
> +		}
> +
> +		tmu->mapbase = ioremap(res->start, resource_size(res));

devm_platform_ioremap_resource() should be good to have.
Again, consider proper splitting.

>  	}
> +	if (tmu->np)
> +		tmu->mapbase = of_iomap(tmu->np, 0);

So, how many boards are non-OF compatible? Maybe makes sense to move them to OF
and drop these platform code entirely from everywhere?

...

> +	tmu->name = dev_name(&pdev->dev);
> +	tmu->clk = clk_get(&tmu->pdev->dev, "fck");

devm_ approach can help a lot in case of platform device code.

> +	if (IS_ERR(tmu->clk)) {
> +		dev_err(&tmu->pdev->dev, "cannot get clock\n");
> +		return PTR_ERR(tmu->clk);

		return dev_err_probe() ?

> +	}

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[relevance 1%]

* Re: [PATCH i-g-t] CONTRIBUTING: Add more guidelines
  2024-05-29 12:48  7% [PATCH i-g-t] CONTRIBUTING: Add more guidelines Kamil Konieczny
@ 2024-05-29 12:55  0% ` Louis Chauvet
  0 siblings, 0 replies; 200+ results
From: Louis Chauvet @ 2024-05-29 12:55 UTC (permalink / raw)
  To: Kamil Konieczny
  Cc: igt-dev, Arthur Grillo, Ashutosh Dixit, Bhanuprakash Modem,
	Jani Nikula, Juha-Pekka Heikkila, Katarzyna Piecielska,
	Mauro Carvalho Chehab, Petri Latvala, Zbigniew Kempczyński

Thanks for this update, it is better than my initial wording.

Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>

Thanks,
Louis Chauvet

Le 29/05/24 - 14:48, Kamil Konieczny a écrit :
> Add few more guidelines for submitting patches:
> - encourage use of checkpatch.pl script from Linux kernel
> - add guide for good subject for a patch
> - add links to guides about how to create a good patch
> - add guide for responding to CI failure letters
> 
> v1: expand patch from Louis on checkpatch,
>   also take a hint from Jani about checkpatch options
>   add a guide for checking test results from CI
> 
> Cc: Arthur Grillo <arthurgrillo@riseup.net>
> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
> Cc: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
> Cc: Jani Nikula <jani.nikula@intel.com>
> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
> Cc: Katarzyna Piecielska <katarzyna.piecielska@intel.com>
> Cc: Louis Chauvet <louis.chauvet@bootlin.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Petri Latvala <adrinael@adrinael.net>
> Cc: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
> Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
> Signed-off-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
> ---
>  CONTRIBUTING.md | 22 +++++++++++++++++++++-
>  1 file changed, 21 insertions(+), 1 deletion(-)
> 
> diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
> index 2ab8a48f6..23cf0df11 100644
> --- a/CONTRIBUTING.md
> +++ b/CONTRIBUTING.md
> @@ -63,6 +63,17 @@ Sending Patches
>  
>    on its first invocation.
>  
> +- Place relevant prefix in subject, for example when your change is in one
> +  testfile, use its name without '.c' nor '.h' suffix, like:
> +  tests/simple_test: short description
> +  Consider sending cover letter with your patch, so if you decide to change
> +  subject it can still be linked into same patchseries on patchwork.
> +
> +- Look into some guides from Linux and Open Source community:
> +  https://kernelnewbies.org/PatchPhilosophy
> +  https://www.kernel.org/doc/html/latest/process/submitting-patches.html
> +  https://www.kernel.org/doc/html/latest/process/submit-checklist.html
> +
>  - Patches need to be reviewed on the mailing list. Exceptions only apply for
>    testcases and tooling for drivers with just a single contributor (e.g. vc4).
>    In this case patches must still be submitted to the mailing list first.
> @@ -75,8 +86,17 @@ Sending Patches
>    contact one of the maintainers (listed in the MAINTAINERS file) and cc the
>    igt-dev mailing list.
>  
> +- Before sending use Linux kernel script 'checkpatch.pl' for checking your
> +  patchset. You could ignore some of them like 'line too long' or 'typdef'
> +  but most of the time its log is accurate. Useful options you could use:
> +  --emacs --strict --show-types --max-line-length=100 \
> +  --ignore=BIT_MACRO,SPLIT_STRING,LONG_LINE_STRING,BOOL_MEMBER
> +
>  - Changes to the testcases are automatically tested. Take the results into
> -  account before merging.
> +  account before merging.  Please also reply to CI failures if you think they
> +  are unrelated, add also to Cc CI e-mail which is present in message.  This
> +  can help our bug-filing team. When replying, you can cut a message after
> +  'Known bugs' to keep it in reasonable size.
>  
>  
>  Commit Rights
> -- 
> 2.43.0
> 

-- 
Louis Chauvet, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] tests/qtest/migrate-test: Add a postcopy memfile test
  @ 2024-05-29 12:54  0% ` Fabiano Rosas
  0 siblings, 0 replies; 200+ results
From: Fabiano Rosas @ 2024-05-29 12:54 UTC (permalink / raw)
  To: Nicholas Piggin, qemu-devel
  Cc: Nicholas Piggin, Peter Xu, Thomas Huth, Laurent Vivier, Paolo Bonzini

Nicholas Piggin <npiggin@gmail.com> writes:

> Postcopy requires userfaultfd support, which requires tmpfs if a memory
> file is used.
>
> This adds back support for /dev/shm memory files, but adds preallocation
> to skip environments where that mount is limited in size.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
>
> How about this? This goes on top of the reset of the patches
> (I'll re-send them all as a series if we can get to some agreement).
>
> This adds back the /dev/shm option with preallocation and adds a test
> case that requires tmpfs.

Peter has stronger opinions on this than I do. I'll leave it to him to
decide.

Just note that now we're making the CI less deterministic in relation to
the migration tests. When a test that uses shmem fails, we'll not be
able to consistently reproduce because the test might not even run
depending on what has consumed the shmem first.

Let's also take care that the other consumers of shmem (I think just
ivshmem-test) are able to cope with the migration-test taking all the
space, otherwise the CI will still break.

>
> Thanks,
> Nick
>
>  tests/qtest/migration-test.c | 63 +++++++++++++++++++++++++++++++-----
>  1 file changed, 55 insertions(+), 8 deletions(-)
>
> diff --git a/tests/qtest/migration-test.c b/tests/qtest/migration-test.c
> index 86eace354e..7fd9bbdc18 100644
> --- a/tests/qtest/migration-test.c
> +++ b/tests/qtest/migration-test.c
> @@ -11,6 +11,7 @@
>   */
>  
>  #include "qemu/osdep.h"
> +#include "qemu/cutils.h"
>  
>  #include "libqtest.h"
>  #include "qapi/qmp/qdict.h"
> @@ -553,6 +554,7 @@ typedef struct {
>       */
>      bool hide_stderr;
>      bool use_memfile;
> +    bool use_uffd_memfile;
>      /* only launch the target process */
>      bool only_target;
>      /* Use dirty ring if true; dirty logging otherwise */
> @@ -739,7 +741,48 @@ static int test_migrate_start(QTestState **from, QTestState **to,
>          ignore_stderr = "";
>      }
>  
> -    if (args->use_memfile) {
> +    if (!qtest_has_machine(machine_alias)) {
> +        g_autofree char *msg = g_strdup_printf("machine %s not supported",
> +                                               machine_alias);
> +        g_test_skip(msg);
> +        return -1;
> +    }
> +
> +    if (args->use_uffd_memfile) {
> +#if defined(__NR_userfaultfd) && defined(__linux__)
> +        int fd;
> +        uint64_t size;
> +
> +        if (!g_file_test("/dev/shm", G_FILE_TEST_IS_DIR)) {
> +            g_test_skip("/dev/shm does not exist or is not a directory");
> +            return -1;
> +        }
> +
> +        /*
> +         * Pre-create and allocate the file here, because /dev/shm/
> +         * is known to be limited in size in some places (e.g., Gitlab CI).
> +         */
> +        memfile_path = g_strdup_printf("/dev/shm/qemu-%d", getpid());
> +        fd = open(memfile_path, O_WRONLY | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR);
> +        if (fd == -1) {
> +            g_test_skip("/dev/shm file could not be created");
> +            return -1;
> +        }
> +
> +        g_assert(qemu_strtosz(memory_size, NULL, &size) == 0);
> +        size += 64*1024; /* QEMU may map a bit more memory for a guard page */
> +
> +        if (fallocate(fd, 0, 0, size) == -1) {
> +            unlink(memfile_path);
> +            perror("could not alloc"); exit(1);
> +            g_test_skip("Could not allocate machine memory in /dev/shm");
> +            return -1;
> +        }
> +        close(fd);
> +#else
> +        g_test_skip("userfaultfd is not supported");
> +#endif
> +    } else if (args->use_memfile) {
>          memfile_path = g_strdup_printf("/%s/qemu-%d", tmpfs, getpid());
>          memfile_opts = g_strdup_printf(
>              "-object memory-backend-file,id=mem0,size=%s"
> @@ -751,12 +794,6 @@ static int test_migrate_start(QTestState **from, QTestState **to,
>          kvm_opts = ",dirty-ring-size=4096";
>      }
>  
> -    if (!qtest_has_machine(machine_alias)) {
> -        g_autofree char *msg = g_strdup_printf("machine %s not supported", machine_alias);
> -        g_test_skip(msg);
> -        return -1;
> -    }
> -
>      machine = resolve_machine_version(machine_alias, QEMU_ENV_SRC,
>                                        QEMU_ENV_DST);
>  
> @@ -807,7 +844,7 @@ static int test_migrate_start(QTestState **from, QTestState **to,
>       * Remove shmem file immediately to avoid memory leak in test failed case.
>       * It's valid because QEMU has already opened this file
>       */
> -    if (args->use_memfile) {
> +    if (args->use_memfile || args->use_uffd_memfile) {
>          unlink(memfile_path);
>      }
>  
> @@ -1275,6 +1312,15 @@ static void test_postcopy(void)
>      test_postcopy_common(&args);
>  }
>  
> +static void test_postcopy_memfile(void)
> +{
> +    MigrateCommon args = {
> +        .start.use_uffd_memfile = true,
> +    };
> +
> +    test_postcopy_common(&args);
> +}
> +
>  static void test_postcopy_suspend(void)
>  {
>      MigrateCommon args = {
> @@ -3441,6 +3487,7 @@ int main(int argc, char **argv)
>  
>      if (has_uffd) {
>          migration_test_add("/migration/postcopy/plain", test_postcopy);
> +        migration_test_add("/migration/postcopy/memfile", test_postcopy_memfile);
>          migration_test_add("/migration/postcopy/recovery/plain",
>                             test_postcopy_recovery);
>          migration_test_add("/migration/postcopy/preempt/plain",


^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 1/3] rust: block: introduce `kernel::block::mq` module
  @ 2024-05-29 12:52  1%     ` Andreas Hindborg
  0 siblings, 0 replies; 200+ results
From: Andreas Hindborg @ 2024-05-29 12:52 UTC (permalink / raw)
  To: Benno Lossin
  Cc: Jens Axboe, Christoph Hellwig, Keith Busch, Damien Le Moal,
	Bart Van Assche, Hannes Reinecke, Ming Lei, linux-block,
	Andreas Hindborg, Wedson Almeida Filho, Greg KH, Matthew Wilcox,
	Miguel Ojeda, Alex Gaynor, Boqun Feng, Gary Guo,
	Björn Roy Baron, Alice Ryhl, Chaitanya Kulkarni,
	Luis Chamberlain, Yexuan Yang, Sergio González Collado,
	Joel Granados, Pankaj Raghav (Samsung),
	Daniel Gomez, Niklas Cassel, Philipp Stanner, Conor Dooley,
	Johannes Thumshirn, Matias Bjørling, open list,
	rust-for-linux, lsf-pc, gost.dev

Benno Lossin <benno.lossin@proton.me> writes:

> On 21.05.24 16:03, Andreas Hindborg wrote:
>> From: Andreas Hindborg <a.hindborg@samsung.com>

[...]

>> >> +
>> +//! This module provides types for implementing block drivers that interface the
>> +//! blk-mq subsystem.
>> +//!
>> +//! To implement a block device driver, a Rust module must do the following:
>> +//!
>> +//! - Implement [`Operations`] for a type `T`
>> +//! - Create a [`TagSet<T>`]
>> +//! - Create a [`gen_disk::GenDisk<T>`], passing in the `TagSet` reference
>
> I would use short links [`GenDisk<T>`].

`GenDisk` is not in scope, so short link is not working. But I can do
whatever this is called:


//! - Create a [`GenDisk<T>`], passing in the `TagSet` reference
...
//! [`GenDisk<T>`]: gen_disk::GenDisk

Would you prefer that?

>
>> +//! - Add the disk to the system by calling [`gen_disk::GenDisk::add`]
>> +//!
>> +//! The types available in this module that have direct C counterparts are:
>> +//!
>> +//! - The `TagSet` type that abstracts the C type `struct tag_set`.
>
> Missing link? (also below)

`TagSet` was linked above. Would you link it on each mention?

[...]

>> +//!
>> +//!     fn commit_rqs(
>> +//!     ) {
>> +//!     }
>
> Formatting.

I would love if `rustfmt` would do this. But I think it is both unstable
and broken for examples like this [1]. I'll fix it up by hand.

How do you manage formatting in examples? By hand?

[...]

>> +/// A generic block device.
>> +///
>> +/// # Invariants
>> +///
>> +///  - `gendisk` must always point to an initialized and valid `struct gendisk`.
>> +pub struct GenDisk<T: Operations, S: GenDiskState> {
>
> Does it make sense to do `S: GenDiskState = Added`?

Yes, that would make sense.

>
>> +    _tagset: Arc<TagSet<T>>,
>
> Does this really need a leading underscore?

It does not.

>
>> +    gendisk: *mut bindings::gendisk,
>> +    _phantom: core::marker::PhantomData<S>,
>> +}
>> +
>> +// SAFETY: `GenDisk` is an owned pointer to a `struct gendisk` and an `Arc` to a
>> +// `TagSet` It is safe to send this to other threads as long as T is Send.
>> +unsafe impl<T: Operations + Send, S: GenDiskState> Send for GenDisk<T, S> {}
>> +
>> +/// Disks in this state are allocated and initialized, but are not yet
>> +/// accessible from the kernel VFS.
>> +pub enum Initialized {}
>> +
>> +/// Disks in this state have been attached to the kernel VFS and may receive IO
>> +/// requests.
>> +pub enum Added {}
>> +
>> +/// Typestate representing states of a `GenDisk`.
>> +pub trait GenDiskState {}
>
> Should this trait be sealed?

Yes.

>
>> +
>> +impl GenDiskState for Initialized {}
>> +impl GenDiskState for Added {}
>> +
>> +impl<T: Operations> GenDisk<T, Initialized> {
>> +    /// Register the device with the kernel. When this function returns, the
>> +    /// device is accessible from VFS. The kernel may issue reads to the device
>> +    /// during registration to discover partition information.
>> +    pub fn add(self) -> Result<GenDisk<T, Added>> {
>> +        crate::error::to_result(
>> +            // SAFETY: By type invariant, `self.gendisk` points to a valid and
>> +            // initialized instance of `struct gendisk`
>> +            unsafe {
>> +                bindings::device_add_disk(
>> +                    core::ptr::null_mut(),
>> +                    self.gendisk,
>> +                    core::ptr::null_mut(),
>> +                )
>> +            },
>> +        )?;
>> +
>> +        // We don't want to run the destuctor and remove the device from the VFS
>> +        // when `disk` is dropped.
>> +        let mut old = core::mem::ManuallyDrop::new(self);
>> +
>> +        let new = GenDisk {
>> +            _tagset: old._tagset.clone(),
>> +            gendisk: old.gendisk,
>> +            _phantom: PhantomData,
>> +        };
>> +
>> +        // But we have to drop the `Arc` or it will leak.
>> +        // SAFETY: `old._tagset` is valid for write, aligned, non-null, and we
>> +        // have exclusive access. We are not accessing the value again after it
>> +        // is dropped.
>> +        unsafe { core::ptr::drop_in_place(&mut old._tagset) };
>> +
>> +        Ok(new)
>
> Instead of using `ManuallyDrop` and `drop_in_place` why not use
> `transmute`? I feel like that would be a lot simpler.

I was considering the layout not being deterministic for `repr(Rust)`. I
think that in practice it will be the case that the two types will have
the same layout, but I could not find the documentation that states
this. Nomicon does not talk about zero sized types [2].

[...]

>> +impl<T: Operations, S: GenDiskState> GenDisk<T, S> {
>> +    /// Call to tell the block layer the capacity of the device in sectors (512
>> +    /// bytes).
>> +    pub fn set_capacity_sectors(&self, sectors: u64) {
>> +        // SAFETY: By type invariant, `self.gendisk` points to a valid and
>> +        // initialized instance of `struct gendisk`. Callee takes a lock to
>
> By `Callee`, do you mean `set_capacity`? If so, I would prefer that.

Yes. I will update.

[...]

>> +impl<T: Operations, S: GenDiskState> Drop for GenDisk<T, S> {
>> +    fn drop(&mut self) {
>> +        // TODO: This will `WARN` if the disk was not added. Since we cannot
>> +        // specialize drop, we have to call it, or track state with a flag.
>
> You could add an associated constant to GenDiskState and then write the
> following:
>
>     if <S as GenDiskState>::DELETE_ON_DROP {
>         /* del_gendisk ... */
>     }
>
> Then the check is essentially done at compile-time.

Thanks, this is very useful. I will add it.

>
>> +
>> +        // SAFETY: By type invariant, `self.gendisk` points to a valid and
>> +        // initialized instance of `struct gendisk`
>> +        unsafe { bindings::del_gendisk(self.gendisk) };
>> +    }
>> +}
>> +
>> +/// Try to create a new `GenDisk`.
>> +pub fn try_new<T: Operations>(tagset: Arc<TagSet<T>>) -> Result<GenDisk<T, Initialized>> {
>
> Why is this not inside of an `impl` block of `GenDisk<T, Initialized>`?

No particular reason. I should probably move it.

[...]

>> diff --git a/rust/kernel/block/mq/operations.rs b/rust/kernel/block/mq/operations.rs
>> new file mode 100644
>> index 000000000000..3bd1af2c2260
>> --- /dev/null
>> +++ b/rust/kernel/block/mq/operations.rs
>> @@ -0,0 +1,245 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +//! This module provides an interface for blk-mq drivers to implement.
>> +//!
>> +//! C header: [`include/linux/blk-mq.h`](srctree/include/linux/blk-mq.h)
>> +
>> +use crate::{
>> +    bindings,
>> +    block::mq::request::RequestDataWrapper,
>> +    block::mq::Request,
>> +    error::{from_result, Result},
>> +    types::ARef,
>> +};
>> +use core::{marker::PhantomData, sync::atomic::AtomicU64, sync::atomic::Ordering};
>> +
>> +/// Implement this trait to interface blk-mq as block devices.
>> +///
>> +/// To implement a block device driver, implement this trait as described in the
>> +/// [module level documentation]. The kernel will use the implementation of the
>> +/// functions defined in this trait to interface a block device driver. Note:
>> +/// There is no need for an exit_request() implementation, because the `drop`
>> +/// implementation of the [`Request`] type will be invoked by automatically by
>> +/// the C/Rust glue logic.
>
> This text is wrapped to 80 columns, but our usual wrapping is 100.

This had me scratch my head for a bit. I run `make rustfmt` and `make
rustfmtcheck`, so I had no idea why my code would be formatted
incorrect. It took me a while to figure out that we are not enabling
`comment_width = 100`, presumably because it is an unstable `rustfmt`
feature. I am not sure what the correct way to enable it but I hacked
the Makefile and enabled it. It gives a huge diff all across the kernel
crate.

So, it seems we _are_ in fact using 80 line fill column, since that is
what much of our existing code is using, and that is what the build
system is configured to use.

Where did you come across the 100 character fill column?

Anyways, we should configure our tools to the standard we want. I don't
care if it's 80 or 100, as long as I can have the tools do the job for
me.

Let's discuss this at next meeting.

>
>> +///
>> +/// [module level documentation]: kernel::block::mq
>> +#[macros::vtable]
>> +pub trait Operations: Sized {
>> +    /// Called by the kernel to queue a request with the driver. If `is_last` is
>> +    /// `false`, the driver is allowed to defer committing the request.
>> +    fn queue_rq(rq: ARef<Request<Self>>, is_last: bool) -> Result;
>> +
>> +    /// Called by the kernel to indicate that queued requests should be submitted.
>> +    fn commit_rqs();
>> +
>> +    /// Called by the kernel when the request is completed.
>> +    fn complete(_rq: ARef<Request<Self>>);
>
> Is there a reason for the `_`?

Copy pasta probably. Will remove.

>
> To me it seems this is called when the given request is already done, so
> would it make more sense to name it `completed` or `on_completion`?

I would agree. But we had a bit of discussion at LSF about naming things
differently in Rust vs C. C people prefer if we keep the C names, even
if they do not make sense to the people who write the new Rust code.

In C, the vtable entry is called `complete_callback` and the called
symbol is usually `my_driver_complete_rq`.

We could go with `completed`, `completed_callback`, or `complete_rq`.
Although `completed` sounds like it should return a bool indicating
whether the request was already completed.

I think I'll leave it for now, and we can always change it if we come up
with a really good name.

>
>> +
>> +    /// Called by the kernel to poll the device for completed requests. Only
>> +    /// used for poll queues.
>> +    fn poll() -> bool {
>> +        crate::build_error(crate::error::VTABLE_DEFAULT_ERROR)
>> +    }
>> +}
>> +
>> +/// A vtable for blk-mq to interact with a block device driver.
>> +///
>> +/// A `bindings::blk_mq_opa` vtable is constructed from pointers to the `extern
>> +/// "C"` functions of this struct, exposed through the `OperationsVTable::VTABLE`.
>> +///
>> +/// For general documentation of these methods, see the kernel source
>> +/// documentation related to `struct blk_mq_operations` in
>> +/// [`include/linux/blk-mq.h`].
>> +///
>> +/// [`include/linux/blk-mq.h`]: srctree/include/linux/blk-mq.h
>> +pub(crate) struct OperationsVTable<T: Operations>(PhantomData<T>);
>> +
>> +impl<T: Operations> OperationsVTable<T> {
>> +    /// This function is called by the C kernel. A pointer to this function is
>> +    /// installed in the `blk_mq_ops` vtable for the driver.
>> +    ///
>> +    /// # Safety
>> +    ///
>> +    /// - The caller of this function must ensure `bd` is valid
>> +    ///   and initialized. The pointees must outlive this function.
>> +    /// - This function must not be called with a `hctx` for which
>> +    ///   `Self::exit_hctx_callback()` has been called.
>> +    /// - (*bd).rq must point to a valid `bindings:request` for which
>> +    ///   `OperationsVTable<T>::init_request_callback` was called
>> +    unsafe extern "C" fn queue_rq_callback(
>> +        _hctx: *mut bindings::blk_mq_hw_ctx,
>> +        bd: *const bindings::blk_mq_queue_data,
>> +    ) -> bindings::blk_status_t {
>> +        // SAFETY: `bd.rq` is valid as required by the safety requirement for
>> +        // this function.
>> +        let request = unsafe { &*(*bd).rq.cast::<Request<T>>() };
>> +
>> +        // One refcount for the ARef, one for being in flight
>> +        request.wrapper_ref().refcount().store(2, Ordering::Relaxed);
>> +
>> +        let rq =
>> +        // SAFETY: We own a refcount that we took above. We pass that to `ARef`.
>> +        // By the safety requirements of this function, `request` is a valid
>> +        // `struct request` and the private data is properly initialized.
>> +            unsafe {Request::aref_from_raw((*bd).rq)};
>
> Can you put the SAFETY comment above the line, then the formatting is
> more natural.

Yes.

>
>> +
>> +        // SAFETY: We have exclusive access and we just set the refcount above.
>> +        unsafe { Request::start_unchecked(&rq) };
>> +
>> +        let ret = T::queue_rq(
>> +            rq,
>> +            // SAFETY: `bd` is valid as required by the safety requirement for this function.
>> +            unsafe { (*bd).last },
>> +        );
>> +
>> +        if let Err(e) = ret {
>> +            e.to_blk_status()
>> +        } else {
>> +            bindings::BLK_STS_OK as _
>> +        }
>> +    }
>> +
>> +    /// This function is called by the C kernel. A pointer to this function is
>> +    /// installed in the `blk_mq_ops` vtable for the driver.
>> +    ///
>> +    /// # Safety
>> +    ///
>> +    /// This function may only be called by blk-mq C infrastructure.
>> +    unsafe extern "C" fn commit_rqs_callback(_hctx: *mut bindings::blk_mq_hw_ctx) {
>> +        T::commit_rqs()
>> +    }
>> +
>> +    /// This function is called by the C kernel. A pointer to this function is
>> +    /// installed in the `blk_mq_ops` vtable for the driver.
>> +    ///
>> +    /// # Safety
>> +    ///
>> +    /// This function may only be called by blk-mq C infrastructure. `rq` must
>> +    /// point to a valid request that has been marked as completed. The pointee
>> +    /// of `rq` must be valid for write for the duration of this function.
>> +    unsafe extern "C" fn complete_callback(rq: *mut bindings::request) {
>> +        // SAFETY: This function can only be dispatched through
>> +        // `Request::complete`. We leaked a refcount then which we pick back up
>> +        // now.
>
> What do you mean by the first sentence? Where was this refcount leaked?

I can understand why you are confused. `Request::complete` is in my
outgoing patch queue. There is no way to call this function in this
patch. I will move it to a later patch. Thanks.

[...]

>> diff --git a/rust/kernel/block/mq/raw_writer.rs b/rust/kernel/block/mq/raw_writer.rs
>> new file mode 100644
>> index 000000000000..4f7e4692b592
>> --- /dev/null
>> +++ b/rust/kernel/block/mq/raw_writer.rs
>> @@ -0,0 +1,55 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +use core::fmt::{self, Write};
>> +
>> +use crate::error::Result;
>> +use crate::prelude::EINVAL;
>> +
>> +/// A mutable reference to a byte buffer where a string can be written into.
>> +///
>> +/// # Invariants
>> +///
>> +/// `buffer` is always null terminated.
>
> I don't know how valuable this would be, but you could only ask for this
> invariant, if `buffer` is non-empty. Then you could have the `new` and
> `from_array` functions return a `RawWriter` without result.

I think guaranteeing at least a null character is always written by
`write_str` is a good thing. It is used for writing C strings to device
name fields. `write_str` with a zero size buffer would give undesirable
results, and is probably not what the caller wants.

>
>> +pub(crate) struct RawWriter<'a> {
>> +    buffer: &'a mut [u8],
>> +    pos: usize,
>> +}
>> +
>> +impl<'a> RawWriter<'a> {
>> +    /// Create a new `RawWriter` instance.
>> +    fn new(buffer: &'a mut [u8]) -> Result<RawWriter<'a>> {
>> +        *(buffer.last_mut().ok_or(EINVAL)?) = 0;
>> +
>> +        // INVARIANT: We null terminated the buffer above
>
> Missing `.`.

👍

[...]

>> +impl<T: Operations> Request<T> {
>> +    /// Create an `ARef<Request>` from a `struct request` pointer.
>> +    ///
>> +    /// # Safety
>> +    ///
>> +    /// * The caller must own a refcount on `ptr` that is transferred to the
>> +    ///   returned `ARef`.
>> +    /// * The type invariants for `Request` must hold for the pointee of `ptr`.
>> +    pub(crate) unsafe fn aref_from_raw(ptr: *mut bindings::request) -> ARef<Self> {
>> +        // INVARIANTS: By the safety requirements of this function, invariants are upheld.
>
> Typo: INVARIANTS -> INVARIANT

👍

>
>> +        // SAFETY: By the safety requirement of this function, we own a
>> +        // reference count that we can pass to `ARef`.
>> +        unsafe { ARef::from_raw(NonNull::new_unchecked(ptr as *const Self as *mut Self)) }
>> +    }
>> +
>> +    /// Notify the block layer that a request is going to be processed now.
>> +    ///
>> +    /// The block layer uses this hook to do proper initializations such as
>> +    /// starting the timeout timer. It is a requirement that block device
>> +    /// drivers call this function when starting to process a request.
>> +    ///
>> +    /// # Safety
>> +    ///
>> +    /// The caller must have exclusive ownership of `self`, that is
>> +    /// `self.wrapper_ref().refcount() == 2`.
>> +    pub(crate) unsafe fn start_unchecked(this: &ARef<Self>) {
>> +        // SAFETY: By type invariant, `self.0` is a valid `struct request`. By
>> +        // existence of `&mut self` we have exclusive access.
>> +        unsafe { bindings::blk_mq_start_request(this.0.get()) };
>> +    }
>> +
>> +    fn try_set_end(this: ARef<Self>) -> Result<ARef<Self>, ARef<Self>> {
>> +        // We can race with `TagSet::tag_to_rq`
>> +        match this.wrapper_ref().refcount().compare_exchange(
>> +            2,
>> +            0,
>> +            Ordering::Relaxed,
>> +            Ordering::Relaxed,
>> +        ) {
>> +            Err(_old) => Err(this),
>> +            Ok(_) => Ok(this),
>> +        }
>> +    }
>> +
>> +    /// Notify the block layer that the request has been completed without errors.
>> +    ///
>> +    /// This function will return `Err` if `this` is not the only `ARef`
>> +    /// referencing the request.
>> +    pub fn end_ok(this: ARef<Self>) -> Result<(), ARef<Self>> {
>
> I am not yet fully convinced that this is the way we should go. I think
> I would have to see a more complex usage of `Request` with that id <->
> request mapping that you mentioned. Because with how rnull uses this
> API, it could also have a `URef<Self>` parameter (URef := unique ARef).

I considered a `UniqueARef` but it would just move the error handing to
`ARef::into_unique` and then make `end_ok` infallible.

There are four states for a request that we need to track:

A) Request is owned by block layer (refcount 0)
B) Request is owned by driver but with zero `ARef`s in existence
   (refcount 1)
C) Request is owned by driver with exactly one `ARef` in existence
   (refcount 2)
D) Request is owned by driver with more than one `ARef` in existence
   (refcount > 2)

It is in the doc comments for `RequestDataWrapper` as well.

We need A and B to ensure we fail tag to request conversions for
requests that are not owned by the driver.

We need C and D to ensure that it is safe to end the request and hand back
ownership to the block layer.

I will ping you when I hook up the NVMe driver with this.

>
>> +        let this = Self::try_set_end(this)?;
>> +        let request_ptr = this.0.get();
>> +        core::mem::forget(this);
>
> Would be a good idea to mention who is going to own this refcount.

The refcount is zero after `try_set_end`, so there is no owner of the
count. The request will be in state A and thus block layer owns the
request. Block layer does not honor this refcount, it is only for the
driver to know.

Perhaps I should move the explanation up into the docs for `Request`.

>
>> +
>> +        // SAFETY: By type invariant, `self.0` is a valid `struct request`. By
>> +        // existence of `&mut self` we have exclusive access.
>> +        unsafe { bindings::blk_mq_end_request(request_ptr, bindings::BLK_STS_OK as _) };
>> +
>> +        Ok(())
>> +    }
>> +
>> +    /// Return a pointer to the `RequestDataWrapper` stored in the private area
>> +    /// of the request structure.
>> +    ///
>> +    /// # Safety
>> +    ///
>> +    /// - `this` must point to a valid allocation.
>> +    pub(crate) unsafe fn wrapper_ptr(this: *mut Self) -> NonNull<RequestDataWrapper> {
>> +        let request_ptr = this.cast::<bindings::request>();
>> +        let wrapper_ptr =
>> +            // SAFETY: By safety requirements for this function, `this` is a
>> +            // valid allocation.
>> +            unsafe { bindings::blk_mq_rq_to_pdu(request_ptr).cast::<RequestDataWrapper>() };
>> +        // SAFETY: By C api contract, wrapper_ptr points to a valid allocation
>> +        // and is not null.
>> +        unsafe { NonNull::new_unchecked(wrapper_ptr) }
>> +    }
>> +
>> +    /// Return a reference to the `RequestDataWrapper` stored in the private
>> +    /// area of the request structure.
>> +    pub(crate) fn wrapper_ref(&self) -> &RequestDataWrapper {
>> +        // SAFETY: By type invariant, `self.0` is a valid alocation. Further,
>> +        // the private data associated with this request is initialized and
>> +        // valid. The existence of `&self` guarantees that the private data is
>> +        // valid as a shared reference.
>> +        unsafe { Self::wrapper_ptr(self as *const Self as *mut Self).as_ref() }
>> +    }
>> +}
>> +
>> +/// A wrapper around data stored in the private area of the C `struct request`.
>> +pub(crate) struct RequestDataWrapper {
>
> Why is this called `Wrapper`? It doesn't really wrap anything,
> `RequestData` seems fine.

It will eventually wrap private data associated with the request. Those
patches will be submitted later. Should I change the name in the
meanwhile?

>
>> +    /// The Rust request refcount has the following states:
>> +    ///
>> +    /// - 0: The request is owned by C block layer.
>> +    /// - 1: The request is owned by Rust abstractions but there are no ARef references to it.
>> +    /// - 2+: There are `ARef` references to the request.
>> +    refcount: AtomicU64,
>> +}
>> +
>> +impl RequestDataWrapper {
>> +    /// Return a reference to the refcount of the request that is embedding
>> +    /// `self`.
>> +    pub(crate) fn refcount(&self) -> &AtomicU64 {
>> +        &self.refcount
>> +    }
>> +
>> +    /// Return a pointer to the refcount of the request that is embedding the
>> +    /// pointee of `this`.
>> +    ///
>> +    /// # Safety
>> +    ///
>> +    /// - `this` must point to a live allocation of at least the size of `Self`.
>> +    pub(crate) unsafe fn refcount_ptr(this: *mut Self) -> *mut AtomicU64 {
>> +        // SAFETY: Because of the safety requirements of this function, the
>> +        // field projection is safe.
>> +        unsafe { addr_of_mut!((*this).refcount) }
>> +    }
>> +}
>> +
>> +// SAFETY: Exclusive access is thread-safe for `Request`. `Request` has no `&mut
>> +// self` methods and `&self` methods that mutate `self` are internally
>> +// synchronzied.
>> +unsafe impl<T: Operations> Send for Request<T> {}
>> +
>> +// SAFETY: Shared access is thread-safe for `Request`. `&self` methods that
>> +// mutate `self` are internally synchronized`
>> +unsafe impl<T: Operations> Sync for Request<T> {}
>> +
>> +/// Store the result of `op(target.load())` in target, returning new value of
>> +/// taret.
>> +fn atomic_relaxed_op_return(target: &AtomicU64, op: impl Fn(u64) -> u64) -> u64 {
>> +    let mut old = target.load(Ordering::Relaxed);
>> +    loop {
>> +        match target.compare_exchange_weak(old, op(old), Ordering::Relaxed, Ordering::Relaxed) {
>> +            Ok(_) => break,
>> +            Err(x) => {
>> +                old = x;
>> +            }
>> +        }
>> +    }
>
> This seems like a reimplementation of `AtomicU64::fetch_update` to me.

It looks like it! Except this function is returning the updated value,
`fetch_update` is returning the old value.

Would you rather that I rewrite in terms of the library function?

>
>> +
>> +    op(old)
>> +}
>> +
>> +/// Store the result of `op(target.load)` in `target` if `target.load() !=
>> +/// pred`, returning previous value of target
>> +fn atomic_relaxed_op_unless(target: &AtomicU64, op: impl Fn(u64) -> u64, pred: u64) -> bool {
>> +    let x = target.load(Ordering::Relaxed);
>> +    loop {
>> +        if x == pred {
>> +            break;
>> +        }
>> +        if target
>> +            .compare_exchange_weak(x, op(x), Ordering::Relaxed, Ordering::Relaxed)
>> +            .is_ok()
>> +        {
>> +            break;
>> +        }
>> +    }
>> +
>> +    x == pred
>> +}
>> +
>> +// SAFETY: All instances of `Request<T>` are reference counted. This
>> +// implementation of `AlwaysRefCounted` ensure that increments to the ref count
>> +// keeps the object alive in memory at least until a matching reference count
>> +// decrement is executed.
>> +unsafe impl<T: Operations> AlwaysRefCounted for Request<T> {
>> +    fn inc_ref(&self) {
>> +        let refcount = &self.wrapper_ref().refcount();
>> +
>> +        #[cfg_attr(not(CONFIG_DEBUG_MISC), allow(unused_variables))]
>
> Another option would be to use `_updated` as the name of the variable. I
> personally would prefer that. What do you guys think?

Either way is fine by me.

[...]

>> diff --git a/rust/kernel/block/mq/tag_set.rs b/rust/kernel/block/mq/tag_set.rs
>> new file mode 100644
>> index 000000000000..4217c2b03ff3
>> --- /dev/null
>> +++ b/rust/kernel/block/mq/tag_set.rs
>> @@ -0,0 +1,93 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +//! This module provides the `TagSet` struct to wrap the C `struct blk_mq_tag_set`.
>> +//!
>> +//! C header: [`include/linux/blk-mq.h`](srctree/include/linux/blk-mq.h)
>> +
>> +use core::pin::Pin;
>> +
>> +use crate::{
>> +    bindings,
>> +    block::mq::request::RequestDataWrapper,
>> +    block::mq::{operations::OperationsVTable, Operations},
>> +    error::{self, Error, Result},
>> +    prelude::PinInit,
>> +    try_pin_init,
>> +    types::Opaque,
>> +};
>> +use core::{convert::TryInto, marker::PhantomData};
>> +use macros::{pin_data, pinned_drop};
>> +
>> +/// A wrapper for the C `struct blk_mq_tag_set`.
>> +///
>> +/// `struct blk_mq_tag_set` contains a `struct list_head` and so must be pinned.
>> +#[pin_data(PinnedDrop)]
>> +#[repr(transparent)]
>> +pub struct TagSet<T: Operations> {
>> +    #[pin]
>> +    inner: Opaque<bindings::blk_mq_tag_set>,
>> +    _p: PhantomData<T>,
>> +}
>> +
>> +impl<T: Operations> TagSet<T> {
>> +    /// Try to create a new tag set
>> +    pub fn try_new(
>> +        nr_hw_queues: u32,
>> +        num_tags: u32,
>> +        num_maps: u32,
>> +    ) -> impl PinInit<Self, error::Error> {
>> +        try_pin_init!( TagSet {
>> +            inner <- unsafe {kernel::init::pin_init_from_closure(move |place: *mut Opaque<bindings::blk_mq_tag_set>| -> Result<()> {
>
> We currently do not have `Opaque::try_ffi_init`, I vaguely remember that
> we talked about it. Do you mind adding it? Otherwise I can also send a
> patch.

I have a `try_ffi_init` patch queued. I removed it from here to cut
dependencies. I will submit it soon after this is in.

>
>> +                let place = place.cast::<bindings::blk_mq_tag_set>();
>> +
>> +                // SAFETY: try_ffi_init promises that `place` is writable, and
>> +                // zeroes is a valid bit pattern for this structure.
>> +                core::ptr::write_bytes(place, 0, 1);
>> +
>> +                /// For a raw pointer to a struct, write a struct field without
>> +                /// creating a reference to the field
>> +                macro_rules! write_ptr_field {
>> +                    ($target:ident, $field:ident, $value:expr) => {
>> +                        ::core::ptr::write(::core::ptr::addr_of_mut!((*$target).$field), $value)
>> +                    };
>> +                }
>> +
>> +                // SAFETY: try_ffi_init promises that `place` is writable
>> +                    write_ptr_field!(place, ops, OperationsVTable::<T>::build());
>> +                    write_ptr_field!(place, nr_hw_queues , nr_hw_queues);
>> +                    write_ptr_field!(place, timeout , 0); // 0 means default which is 30 * HZ in C
>> +                    write_ptr_field!(place, numa_node , bindings::NUMA_NO_NODE);
>> +                    write_ptr_field!(place, queue_depth , num_tags);
>> +                    write_ptr_field!(place, cmd_size , core::mem::size_of::<RequestDataWrapper>().try_into()?);
>> +                    write_ptr_field!(place, flags , bindings::BLK_MQ_F_SHOULD_MERGE);
>> +                    write_ptr_field!(place, driver_data , core::ptr::null_mut::<core::ffi::c_void>());
>> +                    write_ptr_field!(place, nr_maps , num_maps);
>
> I think that there is some way for pinned-init to do a better job here.
> I feel like we ought to be able to just write:
>
>     Opaque::init(
>         try_init!(bindings::blk_mq_tag_set {
>             ops: OperationsVTable::<T>::build(),
>             nr_hw_queues,
>             timeout: 0, // 0 means default, which is 30Hz
>             numa_node: bindings::NUMA_NO_NODE,
>             queue_depth: num_tags,
>             cmd_size: size_of::<RequestDataWrapper>().try_into()?,
>             flags: bindings::BLK_MQ_F_SHOULD_MERGE,
>             driver_data: null_mut(),
>             nr_maps: num_maps,
>             ..Zeroable::zeroed()
>         }? Error)
>         .chain(|tag_set| to_result(bindings::blk_mq_alloc_tag_set(tag_set)))
>     )
>
> But we don't have `Opaque::init` (shouldn't be difficult) and
> `bindings::blk_mq_tag_set` doesn't implement `Zeroable`. We would need
> bindgen to put `derive(Zeroable)` on certain structs...
>
> Another option would be to just list the fields explicitly, since there
> aren't that many. What do you think?

Both options sound good. Ofc the first one sounds more user friendly
while the latter one sounds easier to implement. Getting rid of the
unsafe blocks here would be really nice.

>
>> +
>> +                // SAFETY: Relevant fields of `place` are initialised above
>> +                let ret = bindings::blk_mq_alloc_tag_set(place);
>> +                if ret < 0 {
>> +                    return Err(Error::from_errno(ret));
>> +                }
>> +
>> +                Ok(())
>> +            })},
>> +            _p: PhantomData,
>> +        })
>> +    }
>> +
>> +    /// Return the pointer to the wrapped `struct blk_mq_tag_set`
>> +    pub(crate) fn raw_tag_set(&self) -> *mut bindings::blk_mq_tag_set {
>> +        self.inner.get()
>> +    }
>> +}
>> +
>> +#[pinned_drop]
>> +impl<T: Operations> PinnedDrop for TagSet<T> {
>> +    fn drop(self: Pin<&mut Self>) {
>> +        // SAFETY: We are not moving self below
>> +        let this = unsafe { Pin::into_inner_unchecked(self) };
>
> You don't need to unwrap the `Pin`, since you only need access to `&Self`
> and `Pin` always allows you to do that. (so just use `self` instead of
> `this` below)

Thanks 👍

>
>> +
>> +        // SAFETY: `inner` is valid and has been properly initialised during construction.
>
> Should be an invariant.

Ok 👍

Thanks for the review! I will send a new version.


Best regards,
Andreas


[1] https://github.com/rust-lang/rustfmt/issues/3348
[2] https://doc.rust-lang.org/nomicon/repr-rust.html#reprrust

^ permalink raw reply	[relevance 1%]

* Re: [PATCH v5 01/23] hw/i386/pc: Deprecate 2.4 to 2.12 pc-i440fx machines
  @ 2024-05-29 12:51  0%   ` Igor Mammedov
  0 siblings, 0 replies; 200+ results
From: Igor Mammedov @ 2024-05-29 12:51 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: qemu-devel, Thomas Huth, Paolo Bonzini, Michael S. Tsirkin,
	Daniel P . Berrangé,
	Zhao Liu

On Wed, 29 May 2024 07:15:17 +0200
Philippe Mathieu-Daudé <philmd@linaro.org> wrote:

> Similarly to the commit c7437f0ddb "docs/about: Mark the
> old pc-i440fx-2.0 - 2.3 machine types as deprecated",
> deprecate the 2.4 to 2.12 machines.
> 
> Suggested-by: Thomas Huth <thuth@redhat.com>
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> Reviewed-by: Thomas Huth <thuth@redhat.com>
> Reviewed-by: Zhao Liu <zhao1.liu@intel.com>

Reviewed-by: Igor Mammedov <imammedo@redhat.com>

> ---
>  docs/about/deprecated.rst | 4 ++--
>  hw/i386/pc_piix.c         | 2 +-
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
> index 40585ca7d5..7ff52bdd8e 100644
> --- a/docs/about/deprecated.rst
> +++ b/docs/about/deprecated.rst
> @@ -228,8 +228,8 @@ deprecated; use the new name ``dtb-randomness`` instead. The new name
>  better reflects the way this property affects all random data within
>  the device tree blob, not just the ``kaslr-seed`` node.
>  
> -``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2)
> -'''''''''''''''''''''''''''''''''''''''''''''''''''''
> +``pc-i440fx-2.0`` up to ``pc-i440fx-2.3`` (since 8.2) and ``pc-i440fx-2.4`` up to ``pc-i440fx-2.12`` (since 9.1)
> +''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
>  
>  These old machine types are quite neglected nowadays and thus might have
>  various pitfalls with regards to live migration. Use a newer machine type
> diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
> index ebb51de380..02878060d0 100644
> --- a/hw/i386/pc_piix.c
> +++ b/hw/i386/pc_piix.c
> @@ -742,6 +742,7 @@ DEFINE_I440FX_MACHINE(v3_0, "pc-i440fx-3.0", NULL,
>  static void pc_i440fx_2_12_machine_options(MachineClass *m)
>  {
>      pc_i440fx_3_0_machine_options(m);
> +    m->deprecation_reason = "old and unattended - use a newer version instead";
>      compat_props_add(m->compat_props, hw_compat_2_12, hw_compat_2_12_len);
>      compat_props_add(m->compat_props, pc_compat_2_12, pc_compat_2_12_len);
>  }
> @@ -847,7 +848,6 @@ static void pc_i440fx_2_3_machine_options(MachineClass *m)
>  {
>      pc_i440fx_2_4_machine_options(m);
>      m->hw_version = "2.3.0";
> -    m->deprecation_reason = "old and unattended - use a newer version instead";
>      compat_props_add(m->compat_props, hw_compat_2_3, hw_compat_2_3_len);
>      compat_props_add(m->compat_props, pc_compat_2_3, pc_compat_2_3_len);
>  }



^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2] reboot: Add timeout for device shutdown
  @ 2024-05-29 12:51  1% ` Greg KH
  0 siblings, 0 replies; 200+ results
From: Greg KH @ 2024-05-29 12:51 UTC (permalink / raw)
  To: Soumya Khasnis
  Cc: rafael, linux-kernel, daniel.lezcano, festevam, lee,
	benjamin.bara, dmitry.osipenko, ldmldm05, srinavasa.nagaraju,
	Madhusudan.Bobbili, shingo.takeuchi, keita.aihara,
	masaya.takahashi

On Wed, May 29, 2024 at 11:00:49AM +0000, Soumya Khasnis wrote:
> The device shutdown callbacks invoked during shutdown/reboot
> are prone to errors depending on the device state or mishandling
> by one or more driver.

Why not fix those drivers?  A release callback should not stall, and if
it does, that's a bug that should be fixed there.

Or use a watchdog and just reboot if that triggers at shutdown time.

> In order to prevent a device hang in such
> scenarios, we bail out after a timeout while dumping a meaningful
> call trace of the shutdown callback which blocks the shutdown or
> reboot process.

Dump it where?


> 
> Signed-off-by: Soumya Khasnis <soumya.khasnis@sony.com>
> Signed-off-by: Srinavasa Nagaraju <Srinavasa.Nagaraju@sony.com>
> ---
>  drivers/base/Kconfig | 15 +++++++++++++++
>  kernel/reboot.c      | 46 +++++++++++++++++++++++++++++++++++++++++++-
>  2 files changed, 60 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 2b8fd6bb7da0..d06e379b6281 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -243,3 +243,18 @@ config FW_DEVLINK_SYNC_STATE_TIMEOUT
>  	  work on.
>  
>  endmenu
> +
> +config DEVICE_SHUTDOWN_TIMEOUT
> +	bool "device shutdown timeout"
> +	default n

That is the default, so no need for this.


> +	help
> +	   Enable timeout for device shutdown. Helps in case device shutdown
> +	   is hung during shoutdonw and reboot.
> +
> +
> +config DEVICE_SHUTDOWN_TIMEOUT_SEC
> +	int "device shutdown timeout in seconds"
> +	default 5
> +	depends on DEVICE_SHUTDOWN_TIMEOUT
> +	help
> +	  sets time for device shutdown timeout in seconds

You need much more help text for all of these.

And why are these in the drivers/base/Kconfig file?  It has nothing to
do with "devices", or the driver core, it's all core kernel reboot
logic.


> diff --git a/kernel/reboot.c b/kernel/reboot.c
> index 22c16e2564cc..8460bd24563b 100644
> --- a/kernel/reboot.c
> +++ b/kernel/reboot.c
> @@ -18,7 +18,7 @@
>  #include <linux/syscalls.h>
>  #include <linux/syscore_ops.h>
>  #include <linux/uaccess.h>
> -
> +#include <linux/sched/debug.h>

Why remove the blank line?

>  /*
>   * this indicates whether you can reboot with ctrl-alt-del: the default is yes
>   */
> @@ -48,6 +48,14 @@ int reboot_cpu;
>  enum reboot_type reboot_type = BOOT_ACPI;
>  int reboot_force;
>  
> +#ifdef CONFIG_DEVICE_SHUTDOWN_TIMEOUT
> +struct device_shutdown_timeout {
> +	struct timer_list timer;
> +	struct task_struct *task;
> +} devs_shutdown;
> +#define SHUTDOWN_TIMEOUT CONFIG_DEVICE_SHUTDOWN_TIMEOUT_SEC
> +#endif

#ifdefs should not be in .c files, please put this in a .h file where it
belongs.  Same for the other #ifdefs.



> +
>  struct sys_off_handler {
>  	struct notifier_block nb;
>  	int (*sys_off_cb)(struct sys_off_data *data);
> @@ -88,12 +96,46 @@ void emergency_restart(void)
>  }
>  EXPORT_SYMBOL_GPL(emergency_restart);
>  
> +#ifdef CONFIG_DEVICE_SHUTDOWN_TIMEOUT
> +static void device_shutdown_timeout_handler(struct timer_list *t)
> +{
> +	pr_emerg("**** device shutdown timeout ****\n");

What does this have to do with "devices"?  This is a whole-system issue,
or really a "broken driver" issue.

> +	show_stack(devs_shutdown.task, NULL, KERN_EMERG);

How do you know this is the 'device shutdown' stack?  What is a "device
shutdown"?

> +	if (system_state == SYSTEM_RESTART)
> +		emergency_restart();
> +	else
> +		machine_power_off();
> +}
> +
> +static void device_shutdown_timer_set(void)
> +{
> +	devs_shutdown.task = current;

It's just the normal shutdown stack/process, why call it a device?

> +	timer_setup(&devs_shutdown.timer, device_shutdown_timeout_handler, 0);
> +	devs_shutdown.timer.expires = jiffies + SHUTDOWN_TIMEOUT * HZ;
> +	add_timer(&devs_shutdown.timer);
> +}
> +
> +static void device_shutdown_timer_clr(void)
> +{
> +	del_timer(&devs_shutdown.timer);
> +}
> +#else
> +static inline void device_shutdown_timer_set(void)
> +{
> +}
> +static inline void device_shutdown_timer_clr(void)
> +{
> +}
> +#endif
> +
>  void kernel_restart_prepare(char *cmd)
>  {
>  	blocking_notifier_call_chain(&reboot_notifier_list, SYS_RESTART, cmd);
>  	system_state = SYSTEM_RESTART;
>  	usermodehelper_disable();
> +	device_shutdown_timer_set();
>  	device_shutdown();
> +	device_shutdown_timer_clr();

Why isn't all of this done in device_shutdown() if you think it is a
device issue?  Why put it in reboot.c?

thanks,

greg k-h

^ permalink raw reply	[relevance 1%]

* Re: NFSD: Unable to initialize client recovery tracking! (-110)
  @ 2024-05-29 12:51  0%         ` Linux regression tracking (Thorsten Leemhuis)
  2024-05-29 13:13  0%         ` Jeff Layton
  1 sibling, 0 replies; 200+ results
From: Linux regression tracking (Thorsten Leemhuis) @ 2024-05-29 12:51 UTC (permalink / raw)
  To: Chuck Lever III, Linux regressions mailing list
  Cc: Jeff Layton, Paul Menzel, Linux NFS Mailing List, it+linux-nfs,
	Linus Torvalds

On 24.05.24 18:09, Chuck Lever III wrote:
>> On May 24, 2024, at 7:16 AM, Linux regression tracking (Thorsten Leemhuis) <regressions@leemhuis.info> wrote:
>> On 21.05.24 12:01, Jeff Layton wrote:
>>> On Tue, 2024-05-21 at 11:55 +0200, Paul Menzel wrote:
>>>> Am 19.04.24 um 18:50 schrieb Paul Menzel:
>>>>
>>>>> Since at least Linux 6.8-rc6, Linux logs the warning below:
>>>>>
>>>>>     NFSD: Unable to initialize client recovery tracking! (-110)
>>>>>
>>>>> I haven’t had time to bisect yet, so if you have an idea, that’d be great.
>>>>
>>>> 74fd48739d0488e39ae18b0168720f449a06690c is the first bad commit
>>>> commit 74fd48739d0488e39ae18b0168720f449a06690c
>>>> Author: Jeff Layton <jlayton@kernel.org>
>>>> Date:   Fri Oct 13 09:03:53 2023 -0400
>>>>
>>>>     nfsd: new Kconfig option for legacy client tracking
>>>>
>>>>     We've had a number of attempts at different NFSv4 client tracking
>>>>     methods over the years, but now nfsdcld has emerged as the clear winner
>>>>     since the others (recoverydir and the usermodehelper upcall) are
>>>>     problematic.
>>> [...]
>>> It sounds like you need to enable nfsdcld in your environment. The old
>>> recovery tracking methods are deprecated. The only surviving one
>>> requires the nfsdcld daemon to be running when recovery tracking is
>>> started. Alternately, you can enable this option in your kernels if you
>>> want to keep using the deprecated methods in the interim.
>>
>> Hmm. Then why didn't this new config option default to "Y" for a while
>> (say a year or two) before changing the default to off? That would have
>> prevented people like Paul from running into the problem when running
>> "olddefconfig". I think that is what Linus would have wanted in a case
>> like this, but might be totally wrong there (I CCed him, in case he
>> wants to share his opinion, but maybe he does not care much).
> 
> That's fair. I recall we believed at the time that very few people
> if anyone currently use a legacy recovery tracking mechanism, and
> the workaround, if they do, is easy.
> 
>> But I guess that's too late now, unless we want to meddle with config
>> option names. But I guess that might not be worth it after half a year
>> for something that only causes a warning (aiui).
> 
> In Paul's case, the default behavior might prevent proper NFSv4
> state recovery, which is a little more hazardous than a mere
> warning, IIUC.
> 
> To my surprise, it often takes quite some time for changes like
> this to matriculate into mainstream usage, so half a year isn't
> that long. We might want to change to a more traditional
> deprecation path (default Y with warning, wait, default N, wait,
> redact the old code).

Well, that would help anybody that already ran "make olddefconfig" with
a kernel that has 74fd48739d04, as they now have
NFSD_LEGACY_CLIENT_TRACKING unset in their .config -- at least unless we
rename that option and make it default to Y; but it would help everybody
that updates from the latest longterm kernel to a future kernel that
would contain a change like you outlined.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

^ permalink raw reply	[relevance 0%]

* [PATCH] thunderbolt: Mention Thunderbolt/USB4 debugging tools in Kconfig
@ 2024-05-29 12:50  4% Mika Westerberg
  0 siblings, 0 replies; 200+ results
From: Mika Westerberg @ 2024-05-29 12:50 UTC (permalink / raw)
  To: linux-usb
  Cc: Yehezkel Bernat, Michael Jamet, Lukas Wunner, Andreas Noever,
	Mario Limonciello, Mika Westerberg

This allows the interested parties to find the Thunderbolt/USB4
debugging tools (aka tbtools) easier in case they need to look at the
information under debugfs entries.

Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Suggested-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
---
 drivers/thunderbolt/Kconfig | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/thunderbolt/Kconfig b/drivers/thunderbolt/Kconfig
index 448fd2ec8f6e..3e01f41e9d66 100644
--- a/drivers/thunderbolt/Kconfig
+++ b/drivers/thunderbolt/Kconfig
@@ -22,7 +22,11 @@ config USB4_DEBUGFS_WRITE
 	bool "Enable write by debugfs to configuration spaces (DANGEROUS)"
 	help
 	  Enables writing to device configuration registers through
-	  debugfs interface.
+	  debugfs interface. You can use tools such as Thunderbolt/USB4
+	  debugging tools to access these registers. For more
+	  information see:
+
+	    https://github.com/intel/tbtools
 
 	  Only enable this if you know what you are doing! Never enable
 	  this for production systems or distro kernels.
-- 
2.43.0


^ permalink raw reply related	[relevance 4%]

* Re: [PATCH 2/7] riscv: Implement cmpxchg8/16() using Zabha
  @ 2024-05-29 12:49  0%       ` Alexandre Ghiti
  0 siblings, 0 replies; 200+ results
From: Alexandre Ghiti @ 2024-05-29 12:49 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long,
	Boqun Feng, Arnd Bergmann, Leonardo Bras, Guo Ren, linux-doc,
	linux-kernel, linux-riscv, linux-arch, llvm

Hi Nathan,

On Tue, May 28, 2024 at 9:31 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Hi Alexandre,
>
> On Tue, May 28, 2024 at 05:10:47PM +0200, Alexandre Ghiti wrote:
> > This adds runtime support for Zabha in cmpxchg8/16 operations.
> >
> > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
> > ---
> >  arch/riscv/Kconfig               | 16 ++++++++++++++++
> >  arch/riscv/Makefile              | 10 ++++++++++
> >  arch/riscv/include/asm/cmpxchg.h | 26 ++++++++++++++++++++++++--
> >  3 files changed, 50 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index b443def70139..05597719bb1c 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -579,6 +579,22 @@ config RISCV_ISA_V_PREEMPTIVE
> >         preemption. Enabling this config will result in higher memory
> >         consumption due to the allocation of per-task's kernel Vector context.
> >
> > +config TOOLCHAIN_HAS_ZABHA
> > +     bool
> > +     default y
> > +     depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zabha)
> > +     depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zabha)
>
> This test does not take into account the need for
> '-menable-experimental-extensions' and '1p0' in the '-march=' value with
> clang 19, so it can never be enabled even if it is available.

Then I missed that, I should have checked the generated code. Is the
extension version "1p0" in '-march=' only required for experimental
extensions?

>
> I am not really sure how to succinctly account for this though, other
> than duplicating and modifying the cc-option checks with a dependency on
> either CC_IS_GCC or CC_IS_CLANG. Another option is taking the same
> approach as the _SUPPORTS_DYNAMIC_FTRACE symbols and introduce
> CLANG_HAS_ZABHA and GCC_HAS_ZABHA? That might not make it too ugly.
>
> I think the ZACAS patch has a similar issue, it just isn't noticeable
> with clang 19 but it should be with clang 17 and 18.

But from Conor comment here [1], we should not enable extensions that
are only experimental. In that case, we should be good with this.

[1] https://lore.kernel.org/linux-riscv/20240528151052.313031-1-alexghiti@rivosinc.com/T/#mefb283477bce852f3713cbbb4ff002252281c9d5

>
> > +     depends on AS_HAS_OPTION_ARCH
> > +
> > +config RISCV_ISA_ZABHA
> > +     bool "Zabha extension support for atomic byte/half-word operations"
> > +     depends on TOOLCHAIN_HAS_ZABHA
> > +     default y
> > +     help
> > +       Adds support to use atomic byte/half-word operations in the kernel.
> > +
> > +       If you don't know what to do here, say Y.
> > +
> >  config TOOLCHAIN_HAS_ZACAS
> >       bool
> >       default y
> > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > index d5b60b87998c..f58ac921dece 100644
> > --- a/arch/riscv/Makefile
> > +++ b/arch/riscv/Makefile
> > @@ -89,6 +89,16 @@ else
> >  riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZACAS) := $(riscv-march-y)_zacas
> >  endif
> >
> > +# Check if the toolchain supports Zabha
> > +ifdef CONFIG_AS_IS_LLVM
> > +# Support for experimental Zabha was merged in LLVM 19.
> > +KBUILD_CFLAGS += -menable-experimental-extensions
> > +KBUILD_AFLAGS += -menable-experimental-extensions
> > +riscv-march-y := $(riscv-march-y)_zabha1p0
>
> This block should have some dependency on CONFIG_TOOLCHAIN_HAS_ZABHA as
> well right? Otherwise, the build breaks with LLVM toolchains that do not
> support zabha, like LLVM 18.1.x:
>
>   clang: error: invalid arch name 'rv64imac_zihintpause_zacas1p0_zabha1p0', unsupported version number 1.0 for extension 'zabha'
>
> I think the zacas patch has the same bug.

Ok, I will fix that, thanks.

>
> I think that it would be good to consolidate the adding of
> '-menable-experimental-extensions' to the compiler and assembler flags
> to perhaps having a hidden symbol like CONFIG_EXPERIMENTAL_EXTENSIONS
> that is selected by any extension that is experimental for the
> particular toolchain version.
>
> config EXPERIMENTAL_EXTENSIONS
>     bool
>
> config TOOLCHAIN_HAS_ZABHA
>     def_bool y
>     select EXPERIMENTAL_EXETNSIONS if CC_IS_CLANG
>     ...
>
> config TOOLCHAIN_HAS_ZACAS
>     def_bool_y
>     # ZACAS was experimental until Clang 19: https://github.com/llvm/llvm-project/commit/95aab69c109adf29e183090c25dc95c773215746
>     select EXPERIMENTAL_EXETNSIONS if CC_IS_CLANG && CLANG_VERSION < 190000
>     ...
>
> Then in the Makefile:
>
> ifdef CONFIG_EXPERIMENTAL_EXTENSIONS
> KBUILD_AFLAGS += -menable-experimental-extensions
> KBUILD_CFLAGS += -menable-experimental-extensions
> endif

That's a good idea to me, let's see what Conor thinks [2]

[2] https://lore.kernel.org/linux-riscv/20240528151052.313031-1-alexghiti@rivosinc.com/T/#m1d798dfc4c27e5b6d9e14117d81b577ace123322

>
> > +else
> > +riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZABHA) := $(riscv-march-y)_zabha
> > +endif
> > +
> >  # Remove F,D,V from isa string for all. Keep extensions between "fd" and "v" by
> >  # matching non-v and non-multi-letter extensions out with the filter ([^v_]*)
> >  KBUILD_CFLAGS += -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)fd([^v_]*)v?/\1\2/')
> > diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
> > index 1c50b4821ac8..65de9771078e 100644
> > --- a/arch/riscv/include/asm/cmpxchg.h
> > +++ b/arch/riscv/include/asm/cmpxchg.h
> > @@ -103,8 +103,14 @@
> >   * indicated by comparing RETURN with OLD.
> >   */
> >
> > -#define __arch_cmpxchg_masked(sc_sfx, prepend, append, r, p, o, n)   \
> > +#define __arch_cmpxchg_masked(sc_sfx, cas_sfx, prepend, append, r, p, o, n)  \
> >  ({                                                                   \
> > +     __label__ zabha, end;                                           \
> > +                                                                     \
> > +     asm goto(ALTERNATIVE("nop", "j %[zabha]", 0,                    \
> > +                          RISCV_ISA_EXT_ZABHA, 1)                    \
> > +                     : : : : zabha);                                 \
> > +                                                                     \
> >       u32 *__ptr32b = (u32 *)((ulong)(p) & ~0x3);                     \
> >       ulong __s = ((ulong)(p) & (0x4 - sizeof(*p))) * BITS_PER_BYTE;  \
> >       ulong __mask = GENMASK(((sizeof(*p)) * BITS_PER_BYTE) - 1, 0)   \
> > @@ -131,6 +137,17 @@
> >               : "memory");                                            \
> >                                                                       \
> >       r = (__typeof__(*(p)))((__retx & __mask) >> __s);               \
> > +     goto end;                                                       \
> > +                                                                     \
> > +zabha:                                                                       \
> > +     __asm__ __volatile__ (                                          \
> > +             prepend                                                 \
> > +             "       amocas" cas_sfx " %0, %z2, %1\n"                \
>
> This should probably have some dependency on CONFIG_RISCV_ISA_ZABHA? I get the
> following with GCC 13.2.0:
>
>   include/linux/atomic/atomic-arch-fallback.h: Assembler messages:
>   include/linux/atomic/atomic-arch-fallback.h:2108: Error: unrecognized opcode `amocas.w a4,a3,0(s1)'

Indeed, my test setup lacks a few things apparently, I will fix that, thanks.

>
> > +             append                                                  \
> > +             : "+&r" (r), "+A" (*(p))                                \
> > +             : "rJ" (n)                                              \
> > +             : "memory");                                            \
> > +end:                                                                 \
>
> I get a lot of warnings from this statement and the one added by the
> previous patch for zacas, which is a C23 extension:
>
>   include/linux/atomic/atomic-arch-fallback.h:4234:9: warning: label at end of compound statement is a C23 extension [-Wc23-extensions]
>   include/linux/atomic/atomic-arch-fallback.h:89:29: note: expanded from macro 'raw_cmpxchg_relaxed'
>      89 | #define raw_cmpxchg_relaxed arch_cmpxchg_relaxed
>         |                             ^
>   arch/riscv/include/asm/cmpxchg.h:219:2: note: expanded from macro 'arch_cmpxchg_relaxed'
>     219 |         _arch_cmpxchg((ptr), (o), (n), "", "", "")
>         |         ^
>   arch/riscv/include/asm/cmpxchg.h:200:3: note: expanded from macro '_arch_cmpxchg'
>     200 |                 __arch_cmpxchg_masked(sc_sfx, ".h" sc_sfx,              \
>         |                 ^
>   arch/riscv/include/asm/cmpxchg.h:150:14: note: expanded from macro '__arch_cmpxchg_masked'
>     150 | end:                                                                    \
>         |                                                                         ^
>
> This resolves it:
>
> diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
> index ba3ffc2fcdd0..57aa4a554278 100644
> --- a/arch/riscv/include/asm/cmpxchg.h
> +++ b/arch/riscv/include/asm/cmpxchg.h
> @@ -147,7 +147,7 @@ zabha:                                                                      \
>                 : "+&r" (r), "+A" (*(p))                                \
>                 : "rJ" (n)                                              \
>                 : "memory");                                            \
> -end:                                                                   \
> +end:;                                                                  \
>  })
>
>  #define __arch_cmpxchg(lr_sfx, sc_cas_sfx, prepend, append, r, p, co, o, n)    \
> @@ -180,7 +180,7 @@ zacas:                                                                      \
>                 : "+&r" (r), "+A" (*(p))                                \
>                 : "rJ" (n)                                              \
>                 : "memory");                                            \
> -end:                                                                   \
> +end:;                                                                  \
>  })
>
>  #define _arch_cmpxchg(ptr, old, new, sc_sfx, prepend, append)          \

Weird, I missed this too, I will fix that, thanks.

>
> >  })
> >
> >  #define __arch_cmpxchg(lr_sfx, sc_cas_sfx, prepend, append, r, p, co, o, n)  \
> > @@ -175,8 +192,13 @@ end:                                                                     \
> >                                                                       \
> >       switch (sizeof(*__ptr)) {                                       \
> >       case 1:                                                         \
> > +             __arch_cmpxchg_masked(sc_sfx, ".b" sc_sfx,              \
> > +                                     prepend, append,                \
> > +                                     __ret, __ptr, __old, __new);    \
> > +             break;                                                  \
> >       case 2:                                                         \
> > -             __arch_cmpxchg_masked(sc_sfx, prepend, append,          \
> > +             __arch_cmpxchg_masked(sc_sfx, ".h" sc_sfx,              \
> > +                                     prepend, append,                \
> >                                       __ret, __ptr, __old, __new);    \
> >               break;                                                  \
> >       case 4:                                                         \
> > --
> > 2.39.2
> >
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv

Thanks for your thorough review!

Alex

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[relevance 0%]

* Re: [cocci] Looking at guard usage (with SmPL)
  2024-05-29 12:10  0%   ` [cocci] Looking at guard usage (with SmPL) Markus Elfring
@ 2024-05-29 12:50  0%     ` Dr. David Alan Gilbert
  0 siblings, 0 replies; 200+ results
From: Dr. David Alan Gilbert @ 2024-05-29 12:50 UTC (permalink / raw)
  To: Markus Elfring; +Cc: Julia Lawall, cocci, kernel-janitors

* Markus Elfring (Markus.Elfring@web.de) wrote:
> > I'm not the one to decide whether we should use cleanup for mutex locks.
> 
> Would you get further development ideas from another bit of source code analysis
> which can be performed also with the help of the following small script variant
> for the semantic patch language?

Is there a way to look for functions that have a lock, followed by unlocks on
multiple error paths?
IMHO the nicest thing with guard is simplifying lots of error paths, and
innevitably someone forgets to unlock in one of them.

Dave

> 
> @initialize:python@
> @@
> import sys
> delimiter = "|"
> 
> def format_data(places, item, input):
>    for place in places:
>       sys.stdout.write(delimiter.join([item,
>                                        str(input),
>                                        place.current_element,
>                                        place.file,
>                                        place.line,
>                                        str(int(place.column) + 1)
>                                       ]))
>       sys.stdout.write("\n")
> 
> @find@
> expression list el;
> identifier item;
> position p;
> @@
>  guard@p (item) (el);
> 
> @script:python output@
> input << find.el;
> item << find.item;
> places << find.p;
> @@
> format_data(places, item, input)
> 
> 
> 
> Thus it seems that special “guards” are used at 678 source code places
> of the software “Linux next-20240529”.
> https://elixir.bootlin.com/linux/v6.10-rc1/source/include/linux/cleanup.h#L124
> 
> Will interests accordingly grow for further collateral evolution?
> 
> Regards,
> Markus
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/

^ permalink raw reply	[relevance 0%]

* Re: [PATCH 2/7] riscv: Implement cmpxchg8/16() using Zabha
@ 2024-05-29 12:49  0%       ` Alexandre Ghiti
  0 siblings, 0 replies; 200+ results
From: Alexandre Ghiti @ 2024-05-29 12:49 UTC (permalink / raw)
  To: Nathan Chancellor
  Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long,
	Boqun Feng, Arnd Bergmann, Leonardo Bras, Guo Ren, linux-doc,
	linux-kernel, linux-riscv, linux-arch, llvm

Hi Nathan,

On Tue, May 28, 2024 at 9:31 PM Nathan Chancellor <nathan@kernel.org> wrote:
>
> Hi Alexandre,
>
> On Tue, May 28, 2024 at 05:10:47PM +0200, Alexandre Ghiti wrote:
> > This adds runtime support for Zabha in cmpxchg8/16 operations.
> >
> > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
> > ---
> >  arch/riscv/Kconfig               | 16 ++++++++++++++++
> >  arch/riscv/Makefile              | 10 ++++++++++
> >  arch/riscv/include/asm/cmpxchg.h | 26 ++++++++++++++++++++++++--
> >  3 files changed, 50 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index b443def70139..05597719bb1c 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -579,6 +579,22 @@ config RISCV_ISA_V_PREEMPTIVE
> >         preemption. Enabling this config will result in higher memory
> >         consumption due to the allocation of per-task's kernel Vector context.
> >
> > +config TOOLCHAIN_HAS_ZABHA
> > +     bool
> > +     default y
> > +     depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zabha)
> > +     depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zabha)
>
> This test does not take into account the need for
> '-menable-experimental-extensions' and '1p0' in the '-march=' value with
> clang 19, so it can never be enabled even if it is available.

Then I missed that, I should have checked the generated code. Is the
extension version "1p0" in '-march=' only required for experimental
extensions?

>
> I am not really sure how to succinctly account for this though, other
> than duplicating and modifying the cc-option checks with a dependency on
> either CC_IS_GCC or CC_IS_CLANG. Another option is taking the same
> approach as the _SUPPORTS_DYNAMIC_FTRACE symbols and introduce
> CLANG_HAS_ZABHA and GCC_HAS_ZABHA? That might not make it too ugly.
>
> I think the ZACAS patch has a similar issue, it just isn't noticeable
> with clang 19 but it should be with clang 17 and 18.

But from Conor comment here [1], we should not enable extensions that
are only experimental. In that case, we should be good with this.

[1] https://lore.kernel.org/linux-riscv/20240528151052.313031-1-alexghiti@rivosinc.com/T/#mefb283477bce852f3713cbbb4ff002252281c9d5

>
> > +     depends on AS_HAS_OPTION_ARCH
> > +
> > +config RISCV_ISA_ZABHA
> > +     bool "Zabha extension support for atomic byte/half-word operations"
> > +     depends on TOOLCHAIN_HAS_ZABHA
> > +     default y
> > +     help
> > +       Adds support to use atomic byte/half-word operations in the kernel.
> > +
> > +       If you don't know what to do here, say Y.
> > +
> >  config TOOLCHAIN_HAS_ZACAS
> >       bool
> >       default y
> > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > index d5b60b87998c..f58ac921dece 100644
> > --- a/arch/riscv/Makefile
> > +++ b/arch/riscv/Makefile
> > @@ -89,6 +89,16 @@ else
> >  riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZACAS) := $(riscv-march-y)_zacas
> >  endif
> >
> > +# Check if the toolchain supports Zabha
> > +ifdef CONFIG_AS_IS_LLVM
> > +# Support for experimental Zabha was merged in LLVM 19.
> > +KBUILD_CFLAGS += -menable-experimental-extensions
> > +KBUILD_AFLAGS += -menable-experimental-extensions
> > +riscv-march-y := $(riscv-march-y)_zabha1p0
>
> This block should have some dependency on CONFIG_TOOLCHAIN_HAS_ZABHA as
> well right? Otherwise, the build breaks with LLVM toolchains that do not
> support zabha, like LLVM 18.1.x:
>
>   clang: error: invalid arch name 'rv64imac_zihintpause_zacas1p0_zabha1p0', unsupported version number 1.0 for extension 'zabha'
>
> I think the zacas patch has the same bug.

Ok, I will fix that, thanks.

>
> I think that it would be good to consolidate the adding of
> '-menable-experimental-extensions' to the compiler and assembler flags
> to perhaps having a hidden symbol like CONFIG_EXPERIMENTAL_EXTENSIONS
> that is selected by any extension that is experimental for the
> particular toolchain version.
>
> config EXPERIMENTAL_EXTENSIONS
>     bool
>
> config TOOLCHAIN_HAS_ZABHA
>     def_bool y
>     select EXPERIMENTAL_EXETNSIONS if CC_IS_CLANG
>     ...
>
> config TOOLCHAIN_HAS_ZACAS
>     def_bool_y
>     # ZACAS was experimental until Clang 19: https://github.com/llvm/llvm-project/commit/95aab69c109adf29e183090c25dc95c773215746
>     select EXPERIMENTAL_EXETNSIONS if CC_IS_CLANG && CLANG_VERSION < 190000
>     ...
>
> Then in the Makefile:
>
> ifdef CONFIG_EXPERIMENTAL_EXTENSIONS
> KBUILD_AFLAGS += -menable-experimental-extensions
> KBUILD_CFLAGS += -menable-experimental-extensions
> endif

That's a good idea to me, let's see what Conor thinks [2]

[2] https://lore.kernel.org/linux-riscv/20240528151052.313031-1-alexghiti@rivosinc.com/T/#m1d798dfc4c27e5b6d9e14117d81b577ace123322

>
> > +else
> > +riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZABHA) := $(riscv-march-y)_zabha
> > +endif
> > +
> >  # Remove F,D,V from isa string for all. Keep extensions between "fd" and "v" by
> >  # matching non-v and non-multi-letter extensions out with the filter ([^v_]*)
> >  KBUILD_CFLAGS += -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)fd([^v_]*)v?/\1\2/')
> > diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
> > index 1c50b4821ac8..65de9771078e 100644
> > --- a/arch/riscv/include/asm/cmpxchg.h
> > +++ b/arch/riscv/include/asm/cmpxchg.h
> > @@ -103,8 +103,14 @@
> >   * indicated by comparing RETURN with OLD.
> >   */
> >
> > -#define __arch_cmpxchg_masked(sc_sfx, prepend, append, r, p, o, n)   \
> > +#define __arch_cmpxchg_masked(sc_sfx, cas_sfx, prepend, append, r, p, o, n)  \
> >  ({                                                                   \
> > +     __label__ zabha, end;                                           \
> > +                                                                     \
> > +     asm goto(ALTERNATIVE("nop", "j %[zabha]", 0,                    \
> > +                          RISCV_ISA_EXT_ZABHA, 1)                    \
> > +                     : : : : zabha);                                 \
> > +                                                                     \
> >       u32 *__ptr32b = (u32 *)((ulong)(p) & ~0x3);                     \
> >       ulong __s = ((ulong)(p) & (0x4 - sizeof(*p))) * BITS_PER_BYTE;  \
> >       ulong __mask = GENMASK(((sizeof(*p)) * BITS_PER_BYTE) - 1, 0)   \
> > @@ -131,6 +137,17 @@
> >               : "memory");                                            \
> >                                                                       \
> >       r = (__typeof__(*(p)))((__retx & __mask) >> __s);               \
> > +     goto end;                                                       \
> > +                                                                     \
> > +zabha:                                                                       \
> > +     __asm__ __volatile__ (                                          \
> > +             prepend                                                 \
> > +             "       amocas" cas_sfx " %0, %z2, %1\n"                \
>
> This should probably have some dependency on CONFIG_RISCV_ISA_ZABHA? I get the
> following with GCC 13.2.0:
>
>   include/linux/atomic/atomic-arch-fallback.h: Assembler messages:
>   include/linux/atomic/atomic-arch-fallback.h:2108: Error: unrecognized opcode `amocas.w a4,a3,0(s1)'

Indeed, my test setup lacks a few things apparently, I will fix that, thanks.

>
> > +             append                                                  \
> > +             : "+&r" (r), "+A" (*(p))                                \
> > +             : "rJ" (n)                                              \
> > +             : "memory");                                            \
> > +end:                                                                 \
>
> I get a lot of warnings from this statement and the one added by the
> previous patch for zacas, which is a C23 extension:
>
>   include/linux/atomic/atomic-arch-fallback.h:4234:9: warning: label at end of compound statement is a C23 extension [-Wc23-extensions]
>   include/linux/atomic/atomic-arch-fallback.h:89:29: note: expanded from macro 'raw_cmpxchg_relaxed'
>      89 | #define raw_cmpxchg_relaxed arch_cmpxchg_relaxed
>         |                             ^
>   arch/riscv/include/asm/cmpxchg.h:219:2: note: expanded from macro 'arch_cmpxchg_relaxed'
>     219 |         _arch_cmpxchg((ptr), (o), (n), "", "", "")
>         |         ^
>   arch/riscv/include/asm/cmpxchg.h:200:3: note: expanded from macro '_arch_cmpxchg'
>     200 |                 __arch_cmpxchg_masked(sc_sfx, ".h" sc_sfx,              \
>         |                 ^
>   arch/riscv/include/asm/cmpxchg.h:150:14: note: expanded from macro '__arch_cmpxchg_masked'
>     150 | end:                                                                    \
>         |                                                                         ^
>
> This resolves it:
>
> diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
> index ba3ffc2fcdd0..57aa4a554278 100644
> --- a/arch/riscv/include/asm/cmpxchg.h
> +++ b/arch/riscv/include/asm/cmpxchg.h
> @@ -147,7 +147,7 @@ zabha:                                                                      \
>                 : "+&r" (r), "+A" (*(p))                                \
>                 : "rJ" (n)                                              \
>                 : "memory");                                            \
> -end:                                                                   \
> +end:;                                                                  \
>  })
>
>  #define __arch_cmpxchg(lr_sfx, sc_cas_sfx, prepend, append, r, p, co, o, n)    \
> @@ -180,7 +180,7 @@ zacas:                                                                      \
>                 : "+&r" (r), "+A" (*(p))                                \
>                 : "rJ" (n)                                              \
>                 : "memory");                                            \
> -end:                                                                   \
> +end:;                                                                  \
>  })
>
>  #define _arch_cmpxchg(ptr, old, new, sc_sfx, prepend, append)          \

Weird, I missed this too, I will fix that, thanks.

>
> >  })
> >
> >  #define __arch_cmpxchg(lr_sfx, sc_cas_sfx, prepend, append, r, p, co, o, n)  \
> > @@ -175,8 +192,13 @@ end:                                                                     \
> >                                                                       \
> >       switch (sizeof(*__ptr)) {                                       \
> >       case 1:                                                         \
> > +             __arch_cmpxchg_masked(sc_sfx, ".b" sc_sfx,              \
> > +                                     prepend, append,                \
> > +                                     __ret, __ptr, __old, __new);    \
> > +             break;                                                  \
> >       case 2:                                                         \
> > -             __arch_cmpxchg_masked(sc_sfx, prepend, append,          \
> > +             __arch_cmpxchg_masked(sc_sfx, ".h" sc_sfx,              \
> > +                                     prepend, append,                \
> >                                       __ret, __ptr, __old, __new);    \
> >               break;                                                  \
> >       case 4:                                                         \
> > --
> > 2.39.2
> >
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv

Thanks for your thorough review!

Alex

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3 3/6] iio: adc: ad7173: refactor ain and vref selection
  2024-05-29 12:27  0%   ` Nuno Sá
@ 2024-05-29 12:49  1%     ` Nuno Sá
  0 siblings, 0 replies; 200+ results
From: Nuno Sá @ 2024-05-29 12:49 UTC (permalink / raw)
  To: dumitru.ceclan
  Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Lechner,
	linux-iio, devicetree, linux-kernel, Dumitru Ceclan

On Wed, 2024-05-29 at 14:27 +0200, Nuno Sá wrote:
> On Mon, 2024-05-27 at 20:02 +0300, Dumitru Ceclan via B4 Relay wrote:
> > From: Dumitru Ceclan <dumitru.ceclan@analog.com>
> > 
> > Move validation of analog inputs and reference voltage selection to
> > separate functions to reduce the size of the channel config parsing
> > function and improve readability.
> > 
> > Reviewed-by: David Lechner <dlechner@baylibre.com>
> > Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
> > ---
> >  drivers/iio/adc/ad7173.c | 62 ++++++++++++++++++++++++++++++++++--------------
> >  1 file changed, 44 insertions(+), 18 deletions(-)
> > 
> > diff --git a/drivers/iio/adc/ad7173.c b/drivers/iio/adc/ad7173.c
> > index 9e507e2c66f0..8a53821c8e58 100644
> > --- a/drivers/iio/adc/ad7173.c
> > +++ b/drivers/iio/adc/ad7173.c
> > @@ -906,6 +906,44 @@ static int ad7173_register_clk_provider(struct iio_dev
> > *indio_dev)
> >  					   &st->int_clk_hw);
> >  }
> >  
> > +static int ad7173_validate_voltage_ain_inputs(struct ad7173_state *st,
> > +					      unsigned int ain[2])

Pass the pointer and size of it... Also, it should be made 'const'

> > +{
> > +	struct device *dev = &st->sd.spi->dev;
> > +
> > +	for (int i = 0; i < 2; i++) {

Use the size in here... At the very least, ARRAY_SIZE() if you keep it like this.

> > +		if (ain[i] < st->info->num_inputs)
> > +			continue;
> > +
> > +		return dev_err_probe(dev, -EINVAL,
> > +			"Input pin number out of range for pair (%d %d).\n",
> > +			ain[0], ain[1]);
> > +	}
> > +
> > +	return 0;
> > +}
> > +
> > +static int ad7173_validate_reference(struct ad7173_state *st, int ref_sel)
> > +{
> > +	struct device *dev = &st->sd.spi->dev;
> > +	int ret;
> > +
> > +	if (ref_sel == AD7173_SETUP_REF_SEL_INT_REF && !st->info->has_int_ref)
> > +		return dev_err_probe(dev, -EINVAL,
> > +			"Internal reference is not available on current
> > model.\n");
> > +
> > +	if (ref_sel == AD7173_SETUP_REF_SEL_EXT_REF2 && !st->info->has_ref2)
> > +		return dev_err_probe(dev, -EINVAL,
> > +			"External reference 2 is not available on current
> > model.\n");
> > +
> > +	ret = ad7173_get_ref_voltage_milli(st, ref_sel);
> > +	if (ret < 0)
> > +		return dev_err_probe(dev, ret, "Cannot use reference %u\n",
> > +				     ref_sel);
> > +
> > +	return 0;
> 
> If you need a v4, I would just 'return ad7173_get_ref_voltage_milli(...)'. Any
> error
> log needed should be done inside ad7173_get_ref_voltage_milli(). Anyways:
> 
> Reviewed-by: Nuno Sa <nuno.sa@analog.com>
> 

In fact, no tag :). Just realized the above in another patch..

- Nuno Sá


^ permalink raw reply	[relevance 1%]

* [PATCH i-g-t] CONTRIBUTING: Add more guidelines
@ 2024-05-29 12:48  7% Kamil Konieczny
  2024-05-29 12:55  0% ` Louis Chauvet
  0 siblings, 1 reply; 200+ results
From: Kamil Konieczny @ 2024-05-29 12:48 UTC (permalink / raw)
  To: igt-dev
  Cc: Kamil Konieczny, Arthur Grillo, Ashutosh Dixit,
	Bhanuprakash Modem, Jani Nikula, Juha-Pekka Heikkila,
	Katarzyna Piecielska, Louis Chauvet, Mauro Carvalho Chehab,
	Petri Latvala, Zbigniew Kempczyński

Add few more guidelines for submitting patches:
- encourage use of checkpatch.pl script from Linux kernel
- add guide for good subject for a patch
- add links to guides about how to create a good patch
- add guide for responding to CI failure letters

v1: expand patch from Louis on checkpatch,
  also take a hint from Jani about checkpatch options
  add a guide for checking test results from CI

Cc: Arthur Grillo <arthurgrillo@riseup.net>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Cc: Bhanuprakash Modem <bhanuprakash.modem@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Katarzyna Piecielska <katarzyna.piecielska@intel.com>
Cc: Louis Chauvet <louis.chauvet@bootlin.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Petri Latvala <adrinael@adrinael.net>
Cc: "Zbigniew Kempczyński" <zbigniew.kempczynski@intel.com>
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
Signed-off-by: Kamil Konieczny <kamil.konieczny@linux.intel.com>
---
 CONTRIBUTING.md | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 2ab8a48f6..23cf0df11 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -63,6 +63,17 @@ Sending Patches
 
   on its first invocation.
 
+- Place relevant prefix in subject, for example when your change is in one
+  testfile, use its name without '.c' nor '.h' suffix, like:
+  tests/simple_test: short description
+  Consider sending cover letter with your patch, so if you decide to change
+  subject it can still be linked into same patchseries on patchwork.
+
+- Look into some guides from Linux and Open Source community:
+  https://kernelnewbies.org/PatchPhilosophy
+  https://www.kernel.org/doc/html/latest/process/submitting-patches.html
+  https://www.kernel.org/doc/html/latest/process/submit-checklist.html
+
 - Patches need to be reviewed on the mailing list. Exceptions only apply for
   testcases and tooling for drivers with just a single contributor (e.g. vc4).
   In this case patches must still be submitted to the mailing list first.
@@ -75,8 +86,17 @@ Sending Patches
   contact one of the maintainers (listed in the MAINTAINERS file) and cc the
   igt-dev mailing list.
 
+- Before sending use Linux kernel script 'checkpatch.pl' for checking your
+  patchset. You could ignore some of them like 'line too long' or 'typdef'
+  but most of the time its log is accurate. Useful options you could use:
+  --emacs --strict --show-types --max-line-length=100 \
+  --ignore=BIT_MACRO,SPLIT_STRING,LONG_LINE_STRING,BOOL_MEMBER
+
 - Changes to the testcases are automatically tested. Take the results into
-  account before merging.
+  account before merging.  Please also reply to CI failures if you think they
+  are unrelated, add also to Cc CI e-mail which is present in message.  This
+  can help our bug-filing team. When replying, you can cut a message after
+  'Known bugs' to keep it in reasonable size.
 
 
 Commit Rights
-- 
2.43.0


^ permalink raw reply related	[relevance 7%]

* Re: [PATCH 4/5] drm/xe: Rename internal vram helper function
  2024-05-29 11:50  1%         ` Jani Nikula
@ 2024-05-29 12:45  0%           ` Michal Wajdeczko
  0 siblings, 0 replies; 200+ results
From: Michal Wajdeczko @ 2024-05-29 12:45 UTC (permalink / raw)
  To: Jani Nikula, Matthew Brost, Matt Roper, Thomas Hellström,
	Lucas De Marchi
  Cc: intel-xe



On 29.05.2024 13:50, Jani Nikula wrote:
> On Wed, 29 May 2024, Michal Wajdeczko <michal.wajdeczko@intel.com> wrote:
>> ++ maintainers
>>
>> On 29.05.2024 00:15, Matthew Brost wrote:
>>> We have talked about this before and I think the consensous was "xe_"
>>> prefixes for static functions are fine, perhaps even desired. I can't
>>
>> IMO use of "xe_foo" prefix for static functions is inconsistent (as its
>> name suggests that it is public function while OTOH it is declared as
>> static) and may mislead that it could be used in other compilation unit.
>>
>> thus use of "xe_" (for static) should be rather discouraged but also at
>> the same time it shouldn't be treated as showstopper (with the hope
>> better name will be provided later)
>>
>>> find a reference but I do recall a discussion on the list about this.
>>>
>>> I think the maintainers should make / document a rule wrt to "xe_"
>>> prefixes before we start making changes in this area as it is not clear.
> 
> IMO the prefix is useful even for static functions for a few reasons:
> 
> - C has no namespaces. The use of prefixes in the kernel global
>   functions and macros is inconsistent at best. Prefixes avoid clashes.

good point but I guess any new global function will be named in a way
that will minimize risk of clash

> 
> - It's quite handy to be able to just glance at a backtrace to see where
>   it's originating from. With a bunch of generic non-prefixed functions
>   in there, you kind of lose track, and have to look at the source.

if you are unlucky and not all static functions were inlined then still
the backtrace shall include top level public xe_foo() function

> 
> - During refactoring, it's not uncommon to make functions
>   static/non-static, and having to rename at that point is a bit
>   tedious.

another good reason to avoid refactoring and come with good design in
the first place ;)

> 
> That said, we haven't required this in i915. Also platform acronym
> prefixes are common especially in display code. Some people have started
> adding single underscore prefixes for static functions in a few places,
> but I pretty much frown on that.

and sometimes static functions names are defined/added to clarify the
flow or function logic, and strict adhere to rules to have a prefix
might make it less clear, so some room for common sense is still needed

> 
>> before we start writing rules for static functions, better to focus only
>> on rules for public naming convention for the components, like:
>>
>> files:
>> 	GOOD
>> 		xe_foo.ch
>> 		xe_foo_types.h
>> 		xe_foo_helpers.h
>> 	FINE
>> 		xe_gt_foo.ch
>> 	BAD
>> 		foo.ch
>>
>> types:
>> 	GOOD
>> 		struct xe_foo_xxx
>> 		enum xe_foo_yyy
>> 		typedef xe_foo_zzz
>> 	BAD
>> 		struct foo
>> 		struct xe_bar
>>
>> functions:
>> 	GOOD
>> 		xe_foo_bar(struct xe_foo *foo, ...)
>> 	FINE
>> 		xe_foo_bar(struct xe_device *xe, ...)
>> 		xe_gt_foo_bar(struct xe_gt *gt, ...)
>> 	BAD
>> 		xe_foo_bar(..., struct xe_foo *foo)
>> 		xe_bar_foo(struct xe_foo *foo, ...)
> 
> And sometimes you want to prefer names that are easy to pronounce and
> make sense over names that strictly adhere to rules...

but then it should be treated as an exception, to be approved by the
maintainer, from general guidelines that maintainers can still document

> 
> BR,
> Jani.
> 
> 

^ permalink raw reply	[relevance 0%]

* [PATCH 12/19] remote-curl: avoid assigning string constant to non-const variable
    2024-05-29 12:44  1% ` [PATCH 02/19] global: assign non-const strings as required Patrick Steinhardt
@ 2024-05-29 12:44  1% ` Patrick Steinhardt
  1 sibling, 0 replies; 200+ results
From: Patrick Steinhardt @ 2024-05-29 12:44 UTC (permalink / raw)
  To: git; +Cc: Jeff King

[-- Attachment #1: Type: text/plain, Size: 7794 bytes --]

When processing remote options, we split the option line into two by
searching for a space. If there is one, we replace the space with '\0',
otherwise we implicitly assume that the value is "true" and thus assign
a string constant.

As the return value of strchr(3P) weirdly enough is a `char *` even
though it gets a `const char *` as input, the assigned-to variable also
is a non-constant. This is fine though because the argument is in fact
an allocated string, and thus we are allowed to modify it. But this will
break once we enable `-Wwrite-strings`.

Refactor the code stop splitting the fields with '\0' altogether.
Instead, we can pass the length of the option name to `set_option()` and
then use strncmp(3P) instead of strcmp(3P).

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 remote-curl.c | 58 +++++++++++++++++++++++++++------------------------
 1 file changed, 31 insertions(+), 27 deletions(-)

diff --git a/remote-curl.c b/remote-curl.c
index cae98384da..ac185d4f88 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -58,9 +58,9 @@ struct options {
 static struct options options;
 static struct string_list cas_options = STRING_LIST_INIT_DUP;
 
-static int set_option(const char *name, const char *value)
+static int set_option(const char *name, size_t namelen, const char *value)
 {
-	if (!strcmp(name, "verbosity")) {
+	if (!strncmp(name, "verbosity", namelen)) {
 		char *end;
 		int v = strtol(value, &end, 10);
 		if (value == end || *end)
@@ -68,7 +68,7 @@ static int set_option(const char *name, const char *value)
 		options.verbosity = v;
 		return 0;
 	}
-	else if (!strcmp(name, "progress")) {
+	else if (!strncmp(name, "progress", namelen)) {
 		if (!strcmp(value, "true"))
 			options.progress = 1;
 		else if (!strcmp(value, "false"))
@@ -77,7 +77,7 @@ static int set_option(const char *name, const char *value)
 			return -1;
 		return 0;
 	}
-	else if (!strcmp(name, "depth")) {
+	else if (!strncmp(name, "depth", namelen)) {
 		char *end;
 		unsigned long v = strtoul(value, &end, 10);
 		if (value == end || *end)
@@ -85,15 +85,15 @@ static int set_option(const char *name, const char *value)
 		options.depth = v;
 		return 0;
 	}
-	else if (!strcmp(name, "deepen-since")) {
+	else if (!strncmp(name, "deepen-since", namelen)) {
 		options.deepen_since = xstrdup(value);
 		return 0;
 	}
-	else if (!strcmp(name, "deepen-not")) {
+	else if (!strncmp(name, "deepen-not", namelen)) {
 		string_list_append(&options.deepen_not, value);
 		return 0;
 	}
-	else if (!strcmp(name, "deepen-relative")) {
+	else if (!strncmp(name, "deepen-relative", namelen)) {
 		if (!strcmp(value, "true"))
 			options.deepen_relative = 1;
 		else if (!strcmp(value, "false"))
@@ -102,7 +102,7 @@ static int set_option(const char *name, const char *value)
 			return -1;
 		return 0;
 	}
-	else if (!strcmp(name, "followtags")) {
+	else if (!strncmp(name, "followtags", namelen)) {
 		if (!strcmp(value, "true"))
 			options.followtags = 1;
 		else if (!strcmp(value, "false"))
@@ -111,7 +111,7 @@ static int set_option(const char *name, const char *value)
 			return -1;
 		return 0;
 	}
-	else if (!strcmp(name, "dry-run")) {
+	else if (!strncmp(name, "dry-run", namelen)) {
 		if (!strcmp(value, "true"))
 			options.dry_run = 1;
 		else if (!strcmp(value, "false"))
@@ -120,7 +120,7 @@ static int set_option(const char *name, const char *value)
 			return -1;
 		return 0;
 	}
-	else if (!strcmp(name, "check-connectivity")) {
+	else if (!strncmp(name, "check-connectivity", namelen)) {
 		if (!strcmp(value, "true"))
 			options.check_self_contained_and_connected = 1;
 		else if (!strcmp(value, "false"))
@@ -129,7 +129,7 @@ static int set_option(const char *name, const char *value)
 			return -1;
 		return 0;
 	}
-	else if (!strcmp(name, "cas")) {
+	else if (!strncmp(name, "cas", namelen)) {
 		struct strbuf val = STRBUF_INIT;
 		strbuf_addstr(&val, "--force-with-lease=");
 		if (*value != '"')
@@ -139,7 +139,7 @@ static int set_option(const char *name, const char *value)
 		string_list_append(&cas_options, val.buf);
 		strbuf_release(&val);
 		return 0;
-	} else if (!strcmp(name, TRANS_OPT_FORCE_IF_INCLUDES)) {
+	} else if (!strncmp(name, TRANS_OPT_FORCE_IF_INCLUDES, namelen)) {
 		if (!strcmp(value, "true"))
 			options.force_if_includes = 1;
 		else if (!strcmp(value, "false"))
@@ -147,7 +147,7 @@ static int set_option(const char *name, const char *value)
 		else
 			return -1;
 		return 0;
-	} else if (!strcmp(name, "cloning")) {
+	} else if (!strncmp(name, "cloning", namelen)) {
 		if (!strcmp(value, "true"))
 			options.cloning = 1;
 		else if (!strcmp(value, "false"))
@@ -155,7 +155,7 @@ static int set_option(const char *name, const char *value)
 		else
 			return -1;
 		return 0;
-	} else if (!strcmp(name, "update-shallow")) {
+	} else if (!strncmp(name, "update-shallow", namelen)) {
 		if (!strcmp(value, "true"))
 			options.update_shallow = 1;
 		else if (!strcmp(value, "false"))
@@ -163,7 +163,7 @@ static int set_option(const char *name, const char *value)
 		else
 			return -1;
 		return 0;
-	} else if (!strcmp(name, "pushcert")) {
+	} else if (!strncmp(name, "pushcert", namelen)) {
 		if (!strcmp(value, "true"))
 			options.push_cert = SEND_PACK_PUSH_CERT_ALWAYS;
 		else if (!strcmp(value, "false"))
@@ -173,7 +173,7 @@ static int set_option(const char *name, const char *value)
 		else
 			return -1;
 		return 0;
-	} else if (!strcmp(name, "atomic")) {
+	} else if (!strncmp(name, "atomic", namelen)) {
 		if (!strcmp(value, "true"))
 			options.atomic = 1;
 		else if (!strcmp(value, "false"))
@@ -181,7 +181,7 @@ static int set_option(const char *name, const char *value)
 		else
 			return -1;
 		return 0;
-	} else if (!strcmp(name, "push-option")) {
+	} else if (!strncmp(name, "push-option", namelen)) {
 		if (*value != '"')
 			string_list_append(&options.push_options, value);
 		else {
@@ -192,7 +192,7 @@ static int set_option(const char *name, const char *value)
 						 strbuf_detach(&unquoted, NULL));
 		}
 		return 0;
-	} else if (!strcmp(name, "family")) {
+	} else if (!strncmp(name, "family", namelen)) {
 		if (!strcmp(value, "ipv4"))
 			git_curl_ipresolve = CURL_IPRESOLVE_V4;
 		else if (!strcmp(value, "ipv6"))
@@ -202,16 +202,16 @@ static int set_option(const char *name, const char *value)
 		else
 			return -1;
 		return 0;
-	} else if (!strcmp(name, "from-promisor")) {
+	} else if (!strncmp(name, "from-promisor", namelen)) {
 		options.from_promisor = 1;
 		return 0;
-	} else if (!strcmp(name, "refetch")) {
+	} else if (!strncmp(name, "refetch", namelen)) {
 		options.refetch = 1;
 		return 0;
-	} else if (!strcmp(name, "filter")) {
+	} else if (!strncmp(name, "filter", namelen)) {
 		options.filter = xstrdup(value);
 		return 0;
-	} else if (!strcmp(name, "object-format")) {
+	} else if (!strncmp(name, "object-format", namelen)) {
 		options.object_format = 1;
 		if (strcmp(value, "true"))
 			die(_("unknown value for object-format: %s"), value);
@@ -1588,15 +1588,19 @@ int cmd_main(int argc, const char **argv)
 			parse_push(&buf);
 
 		} else if (skip_prefix(buf.buf, "option ", &arg)) {
-			char *value = strchr(arg, ' ');
+			const char *value = strchr(arg, ' ');
+			size_t arglen;
 			int result;
 
-			if (value)
-				*value++ = '\0';
-			else
+			if (value) {
+				arglen = value - arg;
+				value++;
+			} else {
+				arglen = strlen(arg);
 				value = "true";
+			}
 
-			result = set_option(arg, value);
+			result = set_option(arg, arglen, value);
 			if (!result)
 				printf("ok\n");
 			else if (result < 0)
-- 
2.45.1.313.g3a57aa566a.dirty


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply related	[relevance 1%]

* Re: [PATCH v4] mc146818rtc: add a way to generate RTC interrupts via QMP
  2024-05-29 12:36  1%   ` Philippe Mathieu-Daudé
@ 2024-05-29 12:43  0%     ` Daniil Tatianin
  2024-05-29 13:39  0%       ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 200+ results
From: Daniil Tatianin @ 2024-05-29 12:43 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé, Markus Armbruster
  Cc: Michael S. Tsirkin, Paolo Bonzini, Eric Blake, qemu-devel

On 5/29/24 3:36 PM, Philippe Mathieu-Daudé wrote:

> On 29/5/24 14:03, Markus Armbruster wrote:
>> Daniil Tatianin <d-tatianin@yandex-team.ru> writes:
>>
>>> This can be used to force-synchronize the time in guest after a long
>>> stop-cont pause, which can be useful for serverless-type workload.
>>>
>>> Also add a comment to highlight the fact that this (and one other QMP
>>> command) only works for the MC146818 RTC controller.
>>>
>>> Acked-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>>> Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
>>> ---
>>>
>>> Changes since v0:
>>> - Rename to rtc-inject-irq to match other similar API
>>> - Add a comment to highlight that this only works for the I386 RTC
>>>
>>> Changes since v1:
>>> - Added a description below the QMP command to explain how it can be
>>>    used and what it does.
>>>
>>> Changes since v2:
>>> - Add a 'broadcast' suffix.
>>> - Change the comments to explain the flags we're setting.
>>> - Change the command description to fix styling & explain that it's 
>>> a broadcast command.
>>>
>>> Changes since v3:
>>> - Fix checkpatch complaints about usage of C99 comments
>>>
>>> ---
>>>   hw/rtc/mc146818rtc.c         | 20 ++++++++++++++++++++
>>>   include/hw/rtc/mc146818rtc.h |  1 +
>>>   qapi/misc-target.json        | 19 +++++++++++++++++++
>>>   3 files changed, 40 insertions(+)
>>>
>>> diff --git a/hw/rtc/mc146818rtc.c b/hw/rtc/mc146818rtc.c
>>> index 3379f92748..96ecd43036 100644
>>> --- a/hw/rtc/mc146818rtc.c
>>> +++ b/hw/rtc/mc146818rtc.c
>>> @@ -107,6 +107,11 @@ static void 
>>> rtc_coalesced_timer_update(MC146818RtcState *s)
>>>   static QLIST_HEAD(, MC146818RtcState) rtc_devices =
>>>       QLIST_HEAD_INITIALIZER(rtc_devices);
>>>   +/*
>>> + * NOTE:
>>> + * The two QMP functions below are _only_ implemented for the 
>>> MC146818.
>>> + * All other RTC devices ignore this.
>>> + */
>>>   void qmp_rtc_reset_reinjection(Error **errp)
>>>   {
>>>       MC146818RtcState *s;
>>> @@ -116,6 +121,21 @@ void qmp_rtc_reset_reinjection(Error **errp)
>>>       }
>>>   }
>>>   +void qmp_rtc_inject_irq_broadcast(Error **errp)
>>> +{
>>> +    MC146818RtcState *s;
>>> +
>>> +    QLIST_FOREACH(s, &rtc_devices, link) {
>>> +        /* Update-ended interrupt enable */
>>> +        s->cmos_data[RTC_REG_B] |= REG_B_UIE;
>>> +
>>> +        /* Interrupt request flag | update interrupt flag */
>>> +        s->cmos_data[RTC_REG_C] |= REG_C_IRQF | REG_C_UF;
>>> +
>>> +        qemu_irq_raise(s->irq);
>>> +    }
>>> +}
>>> +
>>>   static bool rtc_policy_slew_deliver_irq(MC146818RtcState *s)
>>>   {
>>>       kvm_reset_irq_delivered();
>>> diff --git a/include/hw/rtc/mc146818rtc.h 
>>> b/include/hw/rtc/mc146818rtc.h
>>> index 97cec0b3e8..e9dd0f9c72 100644
>>> --- a/include/hw/rtc/mc146818rtc.h
>>> +++ b/include/hw/rtc/mc146818rtc.h
>>> @@ -56,5 +56,6 @@ MC146818RtcState *mc146818_rtc_init(ISABus *bus, 
>>> int base_year,
>>>   void mc146818rtc_set_cmos_data(MC146818RtcState *s, int addr, int 
>>> val);
>>>   int mc146818rtc_get_cmos_data(MC146818RtcState *s, int addr);
>>>   void qmp_rtc_reset_reinjection(Error **errp);
>>> +void qmp_rtc_inject_irq_broadcast(Error **errp);
>>>     #endif /* HW_RTC_MC146818RTC_H */
>>> diff --git a/qapi/misc-target.json b/qapi/misc-target.json
>>> index 4e0a6492a9..7d388a3753 100644
>>> --- a/qapi/misc-target.json
>>> +++ b/qapi/misc-target.json
>>> @@ -19,6 +19,25 @@
>>>   { 'command': 'rtc-reset-reinjection',
>>>     'if': 'TARGET_I386' }
>>>   +##
>>> +# @rtc-inject-irq-broadcast:
>>> +#
>>> +# Inject an RTC interrupt for all existing RTCs on the system.
>>> +# The interrupt forces the guest to synchronize the time with RTC.
>>> +# This is useful after a long stop-cont pause, which is common for
>>> +# serverless-type workload.
>
> In previous version you said:
>
>   > This isn't really related to migration though. Serverless is based
>   > on constantly stopping and resuming the VM on e.g. every HTTP
>   > request to an endpoint.
>
> Which made some sense. Maybe mention HTTP? And point to that use case
> (possibly with QMP commands) in the commit description?

Hmm, maybe it would be helpful for people who don't know what serverless 
means.

How about:
     This is useful after a long stop-const pause, which is common for 
serverless-type workloads,
     e.g. stopping/resuming the VM on every HTTP request to an endpoint, 
which might involve
     a long pause in between the requests, causing time drift in the guest.

>> Make that "workloads".
>>
>> "For all existing RTCs" is a lie.  It's really just all mc146818s.  The
>> command works as documented only as long as the VM has no other RTCs.
>
> @rtc-mc146818-force-sync-broadcast sounds clearer & safer;
> IIUC the command goal, mentioning IRQ injection is irrelevant
> (implementation detail).
>
I like this if Markus is okay with that. If we go with this, would it 
make sense to drop the "Bug" clause?

> (I'm trying to not spread the problems we already have with
> @rtc-reset-reinjection).
>
>>> +#
>>> +# Since: 9.1
>>> +#
>>> +# Example:
>>> +#
>>> +#     -> { "execute": "rtc-inject-irq-broadcast" }
>>> +#     <- { "return": {} }
>>> +#
>>> +##
>>> +{ 'command': 'rtc-inject-irq-broadcast',
>>> +  'if': 'TARGET_I386' }
>>
>> The conditional kind-of-sort-of ensures "VM has no other RTCs":
>> TARGET_I386 compiles only this file in hw/rtc/, and therefore can't have
>> other RTCs (unless they're hiding in some other directory). Brittle.
>>
>> When we move to single binary, we will compile in other RTCs. How can
>> we ensure "VM has no nother RTCs" then?  What if one of these other RTCs
>> can be added with -device or device_add?
>>
>> When this falls apart because the VM does have other RTCs, it can only
>> do so silently: the command can't tell us for which RTCs it actually
>> injected an interrupt.
>>
>> Documentation making promises the implementation doesn't actually
>> deliver can only end in tears.  The only reason I'm not rejecting this
>> patch out of hand is the existing and similarly broken
>> rtc-reset-reinjection.
>>
>> I'm willing to reluctantly accept it with honest documentation.
>> Perhaps: "Bug: RTCs other than mc146818rtc are silently ignored."
>>
>> Much, much better would be an interface that's actually usable with
>> multiple RTCs.  We'd have to talk how interrupt injection could be used
>> with such a machine.
>>
>> Anything less will likely need to be replaced later on.
>>
>>> +
>>>   ##
>>>   # @SevState:
>>>   #
>>
>


^ permalink raw reply	[relevance 0%]

* Re: [PATCH 8/8] gpio: tqmx86: fix broken IRQ_TYPE_EDGE_BOTH interrupt type
  2024-05-29 12:37  1%   ` Andrew Lunn
@ 2024-05-29 12:44  1%     ` Matthias Schiffer
  0 siblings, 0 replies; 200+ results
From: Matthias Schiffer @ 2024-05-29 12:44 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Linus Walleij, Bartosz Golaszewski, linux-gpio, linux-kernel,
	Gregor Herburger, linux

On Wed, 2024-05-29 at 14:37 +0200, Andrew Lunn wrote:
> On Wed, May 29, 2024 at 09:45:20AM +0200, Matthias Schiffer wrote:
> > The TQMx86 GPIO controller only supports falling and rising edge
> > triggers, but not both. Fix this by implementing a software both-edge
> > mode that toggles the edge type after every interrupt.
> 
> Do you have a real use case for this, one that will handle lost
> interrupts because it cannot swap edge quick enough?
> 
> I personally would not do this, because it is dangerous, it gives the
> impression the device can do both, when in fact it cannot reliably.
> 
> For me, the correct fix is to return EOPNOTSUPP or EINVAL for BOTH.
> 

This was the first thing I tried as well, but it seems that supporting IRQ_TYPE_EDGE_BOTH is
mandatory for all GPIO drivers (not doing so results in various error messages when attemting to use
*any* type of interrupt for the GPIO; I don't remember the exact errors). For this reason, several
drivers implement a similar software solution when the hardware doesn't support it.

Many drivers implement this in a fragile way that will easily break when an edge is missed. On the
TQMx86 we are lucky, and this software implementation is actually robust and will not stop reporting
edges when one is missed. The reason is explained in detail in the long comment added by this patch.

Matthias



^ permalink raw reply	[relevance 1%]

* [PATCH] bpf: Use an UNUSED id for bpf_session_cookie without FPROBE
@ 2024-05-29 12:44  5% Sebastian Andrzej Siewior
  0 siblings, 0 replies; 200+ results
From: Sebastian Andrzej Siewior @ 2024-05-29 12:44 UTC (permalink / raw)
  To: bpf
  Cc: Jiri Olsa, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
	Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
	KP Singh, Stanislav Fomichev, Hao Luo, Viktor Malik,
	Masami Hiramatsu (Google),
	Thomas Gleixner

bpf_session_cookie() is only available with CONFIG_FPROBE=y leading to
an unresolved symbol otherwise.

Use BTF_ID_UNUSED instead of bpf_session_cookie for CONFIG_FPROBE=n.

Fixes: 5c919acef8514 ("bpf: Add support for kprobe session cookie")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 kernel/bpf/verifier.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 77da1f438becc..436f72bfcb9b9 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -11124,7 +11124,11 @@ BTF_ID(func, bpf_iter_css_task_new)
 #else
 BTF_ID_UNUSED
 #endif
+#ifdef CONFIG_FPROBE
 BTF_ID(func, bpf_session_cookie)
+#else
+BTF_ID_UNUSED
+#endif
 
 static bool is_kfunc_ret_null(struct bpf_kfunc_call_arg_meta *meta)
 {
-- 
2.45.1


^ permalink raw reply related	[relevance 5%]

* [PATCH 02/19] global: assign non-const strings as required
  @ 2024-05-29 12:44  1% ` Patrick Steinhardt
  2024-05-29 12:44  1% ` [PATCH 12/19] remote-curl: avoid assigning string constant to non-const variable Patrick Steinhardt
  1 sibling, 0 replies; 200+ results
From: Patrick Steinhardt @ 2024-05-29 12:44 UTC (permalink / raw)
  To: git; +Cc: Jeff King

[-- Attachment #1: Type: text/plain, Size: 6556 bytes --]

There are several cases where we initialize non-const fields with string
constants. This is invalid and will cause warnings once we enable the
`-Wwrite-strings` warning. Adapt those cases to instead use string
arrays.

Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 builtin/remote.c        | 3 ++-
 diff.c                  | 3 ++-
 entry.c                 | 7 ++++---
 ident.c                 | 9 +++++++--
 line-log.c              | 3 ++-
 object-file.c           | 3 ++-
 pretty.c                | 5 +++--
 refs/reftable-backend.c | 5 +++--
 8 files changed, 25 insertions(+), 13 deletions(-)

diff --git a/builtin/remote.c b/builtin/remote.c
index d52b1c0e10..0324a5d48d 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -494,11 +494,12 @@ static int get_head_names(const struct ref *remote_refs, struct ref_states *stat
 	struct ref *ref, *matches;
 	struct ref *fetch_map = NULL, **fetch_map_tail = &fetch_map;
 	struct refspec_item refspec;
+	char refspec_str[] = "refs/heads/*";
 
 	memset(&refspec, 0, sizeof(refspec));
 	refspec.force = 0;
 	refspec.pattern = 1;
-	refspec.src = refspec.dst = "refs/heads/*";
+	refspec.src = refspec.dst = refspec_str;
 	get_fetch_map(remote_refs, &refspec, &fetch_map_tail, 0);
 	matches = guess_remote_head(find_ref_by_name(remote_refs, "HEAD"),
 				    fetch_map, 1);
diff --git a/diff.c b/diff.c
index ffd867ef6c..1439a5a01d 100644
--- a/diff.c
+++ b/diff.c
@@ -7231,11 +7231,12 @@ size_t fill_textconv(struct repository *r,
 		     struct diff_filespec *df,
 		     char **outbuf)
 {
+	static char empty_str[] = "";
 	size_t size;
 
 	if (!driver) {
 		if (!DIFF_FILE_VALID(df)) {
-			*outbuf = "";
+			*outbuf = empty_str;
 			return 0;
 		}
 		if (diff_populate_filespec(r, df, NULL))
diff --git a/entry.c b/entry.c
index b8c257f6f9..2fc06ac90c 100644
--- a/entry.c
+++ b/entry.c
@@ -175,6 +175,7 @@ int finish_delayed_checkout(struct checkout *state, int show_progress)
 	struct string_list_item *filter, *path;
 	struct progress *progress = NULL;
 	struct delayed_checkout *dco = state->delayed_checkout;
+	char empty_str[] = "";
 
 	if (!state->delayed_checkout)
 		return errs;
@@ -189,7 +190,7 @@ int finish_delayed_checkout(struct checkout *state, int show_progress)
 			if (!async_query_available_blobs(filter->string, &available_paths)) {
 				/* Filter reported an error */
 				errs = 1;
-				filter->string = "";
+				filter->string = empty_str;
 				continue;
 			}
 			if (available_paths.nr <= 0) {
@@ -199,7 +200,7 @@ int finish_delayed_checkout(struct checkout *state, int show_progress)
 				 * filter from the list (see
 				 * "string_list_remove_empty_items" call below).
 				 */
-				filter->string = "";
+				filter->string = empty_str;
 				continue;
 			}
 
@@ -225,7 +226,7 @@ int finish_delayed_checkout(struct checkout *state, int show_progress)
 					 * Do not ask the filter for available blobs,
 					 * again, as the filter is likely buggy.
 					 */
-					filter->string = "";
+					filter->string = empty_str;
 					continue;
 				}
 				ce = index_file_exists(state->istate, path->string,
diff --git a/ident.c b/ident.c
index cc7afdbf81..df7aa42802 100644
--- a/ident.c
+++ b/ident.c
@@ -46,9 +46,14 @@ static struct passwd *xgetpwuid_self(int *is_bogus)
 	pw = getpwuid(getuid());
 	if (!pw) {
 		static struct passwd fallback;
-		fallback.pw_name = "unknown";
+		static char fallback_name[] = "unknown";
 #ifndef NO_GECOS_IN_PWENT
-		fallback.pw_gecos = "Unknown";
+		static char fallback_gcos[] = "Unknown";
+#endif
+
+		fallback.pw_name = fallback_name;
+#ifndef NO_GECOS_IN_PWENT
+		fallback.pw_gecos = fallback_gcos;
 #endif
 		pw = &fallback;
 		if (is_bogus)
diff --git a/line-log.c b/line-log.c
index 8ff6ccb772..d9bf2c8120 100644
--- a/line-log.c
+++ b/line-log.c
@@ -1032,6 +1032,7 @@ static int process_diff_filepair(struct rev_info *rev,
 	struct range_set tmp;
 	struct diff_ranges diff;
 	mmfile_t file_parent, file_target;
+	char empty_str[] = "";
 
 	assert(pair->two->path);
 	while (rg) {
@@ -1056,7 +1057,7 @@ static int process_diff_filepair(struct rev_info *rev,
 		file_parent.ptr = pair->one->data;
 		file_parent.size = pair->one->size;
 	} else {
-		file_parent.ptr = "";
+		file_parent.ptr = empty_str;
 		file_parent.size = 0;
 	}
 
diff --git a/object-file.c b/object-file.c
index 610b1f465c..c9e374e57e 100644
--- a/object-file.c
+++ b/object-file.c
@@ -282,12 +282,13 @@ static struct cached_object {
 } *cached_objects;
 static int cached_object_nr, cached_object_alloc;
 
+static char empty_tree_buf[] = "";
 static struct cached_object empty_tree = {
 	.oid = {
 		.hash = EMPTY_TREE_SHA1_BIN_LITERAL,
 	},
 	.type = OBJ_TREE,
-	.buf = "",
+	.buf = empty_tree_buf,
 };
 
 static struct cached_object *find_cached_object(const struct object_id *oid)
diff --git a/pretty.c b/pretty.c
index ec05db5655..1a0030b32a 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1583,9 +1583,10 @@ static size_t format_commit_one(struct strbuf *sb, /* in UTF-8 */
 		return 1;
 	case 'D':
 		{
+			char empty_str[] = "";
 			const struct decoration_options opts = {
-				.prefix = "",
-				.suffix = ""
+				.prefix = empty_str,
+				.suffix = empty_str,
 			};
 
 			format_decorations(sb, commit, c->auto_color, &opts);
diff --git a/refs/reftable-backend.c b/refs/reftable-backend.c
index 1af86bbdec..1908e74dea 100644
--- a/refs/reftable-backend.c
+++ b/refs/reftable-backend.c
@@ -1285,6 +1285,7 @@ static int write_copy_table(struct reftable_writer *writer, void *cb_data)
 	struct strbuf errbuf = STRBUF_INIT;
 	size_t logs_nr = 0, logs_alloc = 0, i;
 	const char *committer_info;
+	char head[] = "HEAD";
 	int ret;
 
 	committer_info = git_committer_info(0);
@@ -1387,7 +1388,7 @@ static int write_copy_table(struct reftable_writer *writer, void *cb_data)
 		if (append_head_reflog) {
 			ALLOC_GROW(logs, logs_nr + 1, logs_alloc);
 			logs[logs_nr] = logs[logs_nr - 1];
-			logs[logs_nr].refname = "HEAD";
+			logs[logs_nr].refname = head;
 			logs_nr++;
 		}
 	}
@@ -1463,7 +1464,7 @@ static int write_copy_table(struct reftable_writer *writer, void *cb_data)
 	string_list_clear(&skip, 0);
 	strbuf_release(&errbuf);
 	for (i = 0; i < logs_nr; i++) {
-		if (!strcmp(logs[i].refname, "HEAD"))
+		if (logs[i].refname == head)
 			continue;
 		logs[i].refname = NULL;
 		reftable_log_record_release(&logs[i]);
-- 
2.45.1.313.g3a57aa566a.dirty


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply related	[relevance 1%]

* Re: [PATCH 1/3] mm: zswap: fix global shrinker memcg iteration
  @ 2024-05-29 12:42  0%     ` Takero Funaki
  0 siblings, 0 replies; 200+ results
From: Takero Funaki @ 2024-05-29 12:42 UTC (permalink / raw)
  To: Nhat Pham
  Cc: Johannes Weiner, Yosry Ahmed, Chengming Zhou, Jonathan Corbet,
	Andrew Morton, Domenico Cerasuolo, linux-mm, linux-doc,
	linux-kernel

2024年5月29日(水) 0:10 Nhat Pham <nphamcs@gmail.com>:
>
> On Mon, May 27, 2024 at 9:34 PM Takero Funaki <flintglass@gmail.com> wrote:
> >
> > This patch fixes an issue where the zswap global shrinker stopped
> > iterating through the memcg tree.
>
> Did you observe this problem in practice?

Thank you for your comments.

I think this situation is rare, but I need to address this to ensure
patch 2 will not stop at the offline memcg.
The main issue I am seeing in version 6.9.0 to 6.10.0rc1 is that the
shrinker did not shrink until accept_thr_percent, and the
written_back_pages is smaller than max_limit_hit.
This can be explained by the shrinker stopping too early or looping
over only part of the tree.

> >
> > The problem was that `shrink_worker()` would stop iterating when a memcg
> > was being offlined and restart from the tree root.  Now, it properly
> > handles the offlining memcg and continues shrinking with the next memcg.
> >
> > Fixes: a65b0e7607cc ("zswap: make shrinking memcg-aware")
> > Signed-off-by: Takero Funaki <flintglass@gmail.com>
> > ---
> >  mm/zswap.c | 76 ++++++++++++++++++++++++++++++++++++++++--------------
> >  1 file changed, 56 insertions(+), 20 deletions(-)
> >
> > diff --git a/mm/zswap.c b/mm/zswap.c
> > index a50e2986cd2f..0b1052cee36c 100644
> > --- a/mm/zswap.c
> > +++ b/mm/zswap.c
> > @@ -775,12 +775,27 @@ void zswap_folio_swapin(struct folio *folio)
> >         }
> >  }
> >
> > +/*
> > + * This function should be called when a memcg is being offlined.
> > + *
> > + * Since the global shrinker shrink_worker() may hold a reference
> > + * of the memcg, we must check and release the reference in
> > + * zswap_next_shrink.
> > + *
> > + * shrink_worker() must handle the case where this function releases
> > + * the reference of memcg being shrunk.
> > + */
> >  void zswap_memcg_offline_cleanup(struct mem_cgroup *memcg)
> >  {
> >         /* lock out zswap shrinker walking memcg tree */
> >         spin_lock(&zswap_shrink_lock);
> > -       if (zswap_next_shrink == memcg)
> > -               zswap_next_shrink = mem_cgroup_iter(NULL, zswap_next_shrink, NULL);
> > +
> > +       if (READ_ONCE(zswap_next_shrink) == memcg) {
> > +               /* put back reference and advance the cursor */
> > +               memcg = mem_cgroup_iter(NULL, memcg, NULL);
> > +               WRITE_ONCE(zswap_next_shrink, memcg);
> > +       }
>
> Hmm could you expand on how your version differs from what's existing?
> What's the point of all these extra steps? The whole thing is done
> under a big spin lock anyway.

I agree that the code is not necessary. These ONCE are for clarifying
what is expected and to align with shrink_worker(), where READ_ONCE is
required to reload the shared variable.
It can be a safeguard for me, sometimes forgetting that we must not
read zswap_next_shrink before acquiring the lock.

> > +
> >         spin_unlock(&zswap_shrink_lock);
> >  }
> >
> > @@ -1312,25 +1327,38 @@ static int shrink_memcg(struct mem_cgroup *memcg)
> >
> >  static void shrink_worker(struct work_struct *w)
> >  {
> > -       struct mem_cgroup *memcg;
> > +       struct mem_cgroup *memcg = NULL;
> > +       struct mem_cgroup *next_memcg;
> >         int ret, failures = 0;
> >         unsigned long thr;
> >
> >         /* Reclaim down to the accept threshold */
> >         thr = zswap_accept_thr_pages();
> >
> > -       /* global reclaim will select cgroup in a round-robin fashion. */
> > +       /* global reclaim will select cgroup in a round-robin fashion.
> > +        *
> > +        * We save iteration cursor memcg into zswap_next_shrink,
> > +        * which can be modified by the offline memcg cleaner
> > +        * zswap_memcg_offline_cleanup().
> > +        */
>
> I feel like the only difference between this loop and the old loop, is
> that if we fail to get an online reference to memcg, we're trying from
> the next one (given by mem_cgroup_iter()) rather than from the top
> (NULL).
>
> For instance, consider the first two steps:
>
> 1. First, we check if memcg is the same as zswap_next_shrink. if not,
> then reset it to zswap_next_shrink.
> 2. Advance memcg, then store the result at zswap_next_shrink.
>
> Under the big zswap_shrink_lock, this is the same as:
>
> 1. Advance zswap_next_shrink.
> 2. Look up zswap_next_shrink, then store it under the local memcg variable.
>
> which is what we were previously doing.
>
> The next step is shared - check for null memcg (which again, is the
> same as zswap_next_shrink now), and attempt to get an online
> reference.
> The only difference is when we fail to get the online reference -
> instead of starting from the top, we advance memcg again.
>
> Can't we just drop the lock, then add a continue statement? That will
> reacquire the lock, advance zswap_next_shrink, look up the result and
> store it at memcg, which is what you're trying to achieve?
>

If I understand correctly, in this offlining pattern, we are not
allowed to leave an offline memcg in zswap_next_shrink more than once.
While offline memcg can appear in memcg_iter_next repeatedly, the
cleaner is called only once per an offline memcg. (or is there some
retry logic?)

If the shrink_worker finds an offline memcg in iteration AFTER the
cleaner was called, we must put back the offline memcg reference
inside shrink_worker() BEFORE going to return/sleep.
Otherwise, the offline memcg reference will be kept in
zswap_next_shrink until the next shrink_worker() is requeued. There is
no rescue chance from the cleaner again.

This means the shrink_worker has to check:
1. We get a lock. Check if the memcg is online while locked.
2a. If online, it can be offlined while we have the lock. But the lock
assures us that the cleaner is waiting for the lock just behind us. We
can rely on this.
2b. If offline, we cannot determine if the cleaner has already been
called or is being called. We have to put back the offline memcg
reference, assuming no cleaner is available.

If we get offline memcg AND abort the shrinker by the max failure
limit, that breaks condition 2b. Thus we need to unconditionally
restart from the beginning of the do block.
I will add these expected situations to the comments.

For unlocking, should we rewrite,

goto iternext;

to

spin_unlock();
goto before_spin_lock; /* just after do{ */

I think that will minimize the critical section and satisfy the condition 2b.

For the memcg iteration,
> 2. Advance memcg, then store the result at zswap_next_shrink.
should be done only if `(memcg == zswap_next_shrink)`.

Say iterating A -> B -> C and A is being offlined.
While we have memcg=A and drop the lock, the cleaner may advance
zswap_next_shrink=A to B.
If we do not check `memcg != next_memcg`, we advance
zswap_next_shrink=B to C again, forgetting B.

That is the reason I added  `(memcg != next_memcg)` check.
Although It can be negligible as it only ignores one memcg per one
cleaner callback.

This is my understanding. Am I missing any crucial points? Any
comments or advice would be greatly appreciated.

> >         do {
> >                 spin_lock(&zswap_shrink_lock);
> > -               zswap_next_shrink = mem_cgroup_iter(NULL, zswap_next_shrink, NULL);
> > -               memcg = zswap_next_shrink;
> > +               next_memcg = READ_ONCE(zswap_next_shrink);
> > +
> > +               if (memcg != next_memcg) {
> > +                       /*
> > +                        * Ours was released by offlining.
> > +                        * Use the saved memcg reference.
> > +                        */
> > +                       memcg = next_memcg;
> > +               } else {
> > +iternext:
> > +                       /* advance cursor */
> > +                       memcg = mem_cgroup_iter(NULL, memcg, NULL);
> > +                       WRITE_ONCE(zswap_next_shrink, memcg);
> > +               }
> >
> >                 /*
> > -                * We need to retry if we have gone through a full round trip, or if we
> > -                * got an offline memcg (or else we risk undoing the effect of the
> > -                * zswap memcg offlining cleanup callback). This is not catastrophic
> > -                * per se, but it will keep the now offlined memcg hostage for a while.
> > -                *
>
> Why are we removing this comment?

The existing comment about aborting the loop on the offlining memcg,
is not valid on  this patch. The offline memcg will just be skipped.
I think the new behavior is commented at the beginning of the loop and
in the !mem_cgroup_tryget_online branch. Please let me know if you
have any suggestions.


> >                  * Note that if we got an online memcg, we will keep the extra
> >                  * reference in case the original reference obtained by mem_cgroup_iter
> >                  * is dropped by the zswap memcg offlining callback, ensuring that the
> > @@ -1345,16 +1373,18 @@ static void shrink_worker(struct work_struct *w)
> >                 }
> >
> >                 if (!mem_cgroup_tryget_online(memcg)) {
> > -                       /* drop the reference from mem_cgroup_iter() */
> > -                       mem_cgroup_iter_break(NULL, memcg);
> > -                       zswap_next_shrink = NULL;
> > -                       spin_unlock(&zswap_shrink_lock);
> > -
> > -                       if (++failures == MAX_RECLAIM_RETRIES)
> > -                               break;
> > -
> > -                       goto resched;
>
> I think we should still increment the failure counter, to guard
> against long running/infinite loops.

Since we skip the offline memcg instead of restarting from the root,
the new iteration will be terminated when it reaches tree root in
finite steps.  I am afraid that counting this as a failure will
terminate the shrinker too easily.

I think shrinker_worker() running longer is not an issue because the
amount of work per the while loop is limited by rescheduling. As it
has a dedicated WQ_MEM_RECLAIM workqueue, returning from the function
is not necessary. cond_resched() should allow the other workqueue to
run.
The next patch also adds a progress check per walking.


> > +                       /*
> > +                        * It is an offline memcg which we cannot shrink
> > +                        * until its pages are reparented.
> > +                        * Put back the memcg reference before cleanup
> > +                        * function reads it from zswap_next_shrink.
> > +                        */
> > +                       goto iternext;
> >                 }
> > +               /*
> > +                * We got an extra memcg reference before unlocking.
> > +                * The cleaner cannot free it using zswap_next_shrink.
> > +                */
> >                 spin_unlock(&zswap_shrink_lock);
> >
> >                 ret = shrink_memcg(memcg);
> > @@ -1368,6 +1398,12 @@ static void shrink_worker(struct work_struct *w)
> >  resched:
> >                 cond_resched();
> >         } while (zswap_total_pages() > thr);
> > +
> > +       /*
> > +        * We can still hold the original memcg reference.
> > +        * The reference is stored in zswap_next_shrink, and then reused
> > +        * by the next shrink_worker().
> > +        */
> >  }
> >
> >  /*********************************
> > --
> > 2.43.0
> >



--

<flintglass@gmail.com>

^ permalink raw reply	[relevance 0%]

* [PATCH v2 2/2] powerpc/uaccess: Use YZ asm constraint for ld
  2024-05-29 12:30  1% [PATCH v2 1/2] powerpc/uaccess: Fix build errors seen with GCC 13/14 Michael Ellerman
@ 2024-05-29 12:30  5% ` Michael Ellerman
  0 siblings, 0 replies; 200+ results
From: Michael Ellerman @ 2024-05-29 12:30 UTC (permalink / raw)
  To: linuxppc-dev

The 'ld' instruction requires a 4-byte aligned displacement because it
is a DS-form instruction. But the "m" asm constraint doesn't enforce
that.

Add a special case of __get_user_asm2_goto() so that the "YZ" constraint
can be used for "ld".

The "Z" constraint is documented in the GCC manual PowerPC machine
constraints, and specifies a "memory operand accessed with indexed or
indirect addressing". "Y" is not documented in the manual but specifies
a "memory operand for a DS-form instruction". Using both allows the
compiler to generate a DS-form "ld" or X-form "ldx" as appropriate.

The change has to be conditional on CONFIG_PPC_KERNEL_PREFIXED because
the "Y" constraint does not guarantee 4-byte alignment when prefixed
instructions are enabled.

No build errors have been reported due to this, but the possibility is
there depending on compiler code generation decisions.

Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 arch/powerpc/include/asm/uaccess.h | 11 +++++++++++
 1 file changed, 11 insertions(+)

v2: Unchanged.

diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index 4cba724c8899..fd594bf6c6a9 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -181,8 +181,19 @@ do {								\
 #endif
 
 #ifdef __powerpc64__
+#ifdef CONFIG_PPC_KERNEL_PREFIXED
 #define __get_user_asm2_goto(x, addr, label)			\
 	__get_user_asm_goto(x, addr, label, "ld")
+#else
+#define __get_user_asm2_goto(x, addr, label)			\
+	asm_goto_output(					\
+		"1:	ld%U1%X1 %0, %1	# get_user\n"		\
+		EX_TABLE(1b, %l2)				\
+		: "=r" (x)					\
+		: DS_FORM_CONSTRAINT (*addr)			\
+		:						\
+		: label)
+#endif // CONFIG_PPC_KERNEL_PREFIXED
 #else /* __powerpc64__ */
 #define __get_user_asm2_goto(x, addr, label)			\
 	asm_goto_output(					\
-- 
2.45.1


^ permalink raw reply related	[relevance 5%]

* Re: [PATCH for-4.19 1/9] x86/irq: remove offline CPUs from old CPU mask when adjusting move_cleanup_count
  @ 2024-05-29 12:40  1%   ` Jan Beulich
  0 siblings, 0 replies; 200+ results
From: Jan Beulich @ 2024-05-29 12:40 UTC (permalink / raw)
  To: Roger Pau Monne; +Cc: Andrew Cooper, xen-devel

On 29.05.2024 11:01, Roger Pau Monne wrote:
> When adjusting move_cleanup_count to account for CPUs that are offline also
> adjust old_cpu_mask, otherwise further calls to fixup_irqs() could subtract
> those again creating and create an imbalance in move_cleanup_count.

I'm in trouble with "creating"; I can't seem to be able to guess what you may
have meant.

> Fixes: 472e0b74c5c4 ('x86/IRQ: deal with move cleanup count state in fixup_irqs()')
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>

With the above clarified (adjustment can be done while committing)
Reviewed-by: Jan Beulich <jbeulich@suse.com>

> --- a/xen/arch/x86/irq.c
> +++ b/xen/arch/x86/irq.c
> @@ -2572,6 +2572,14 @@ void fixup_irqs(const cpumask_t *mask, bool verbose)
>              desc->arch.move_cleanup_count -= cpumask_weight(affinity);
>              if ( !desc->arch.move_cleanup_count )
>                  release_old_vec(desc);
> +            else
> +                /*
> +                 * Adjust old_cpu_mask to account for the offline CPUs,
> +                 * otherwise further calls to fixup_irqs() could subtract those
> +                 * again and possibly underflow the counter.
> +                 */
> +                cpumask_and(desc->arch.old_cpu_mask, desc->arch.old_cpu_mask,
> +                            &cpu_online_map);
>          }

While functionality-wise okay, imo it would be slightly better to use
"affinity" here as well, so that even without looking at context beyond
what's shown here there is a direct connection to the cpumask_weight()
call. I.e.

                cpumask_andnot(desc->arch.old_cpu_mask, desc->arch.old_cpu_mask,
                               affinity);

Thoughts?

Jan


^ permalink raw reply	[relevance 1%]

* Re: [PATCH v3 6/6] ARM64: mt8195: Use thermal aggregation for big and little cpu
  @ 2024-05-29 12:39  3%       ` Krzysztof Kozlowski
  0 siblings, 0 replies; 200+ results
From: Krzysztof Kozlowski @ 2024-05-29 12:39 UTC (permalink / raw)
  To: Alexandre Bailon, rafael, daniel.lezcano, robh+dt,
	krzysztof.kozlowski+dt, conor+dt
  Cc: rui.zhang, lukasz.luba, linux-pm, devicetree, linux-kernel

On 29/05/2024 10:19, Alexandre Bailon wrote:
> 
> 
> On 5/27/24 08:56, Krzysztof Kozlowski wrote:
>> On 24/05/2024 16:31, Alexandre Bailon wrote:
>>> This uses the thermal aggregation for the mt8195 to get the maximal
>>> temperature of big and little cpu clusters.
>>>
>>> Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
>>> ---
>>>   arch/arm64/boot/dts/mediatek/mt8195.dtsi | 212 +++--------------------
>>>   1 file changed, 27 insertions(+), 185 deletions(-)
>>>
>>> diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
>>> index 5d8b68f86ce4..8aa2bf142622 100644
>>> --- a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
>>> +++ b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
>>> @@ -3600,50 +3600,31 @@ dp_tx: dp-tx@1c600000 {
>>>   	};
>>>   
>>>   	thermal_zones: thermal-zones {
>>> -		cpu0-thermal {
>>> +		cpu-little {
>>
>> How is it related to the commit?
> To aggregate all thermal sensors which are in same performance domain, 
> we removes each individual nodes to create only two: cpu-little and cpu-big.

OK...

> We need to remove the other nodes because their trips points and cooling 
> devices would conflict with those we define for the multi sensor thermal 
> zone.
> 
> Best Regards,
> Alexandre
>>
>> Does not look tested. You just introduced warnings.

Yet still I claim it wasn't tested. See SoC maintainer profile documents
and/or writing-schema.

Best regards,
Krzysztof


^ permalink raw reply	[relevance 3%]

* Re: [PATCH 03/25] common/idpf: update ADD QUEUE GROUPS offset
  @ 2024-05-29 12:38  0%   ` Bruce Richardson
  0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2024-05-29 12:38 UTC (permalink / raw)
  To: Soumyadeep Hore; +Cc: yuying.zhang, jingjing.wu, dev

On Tue, May 28, 2024 at 07:28:33AM +0000, Soumyadeep Hore wrote:
> Some compilers will use 64-bit addressing and compiler will detect
> such loss of data
> 
> virtchnl2.h(1890,40): warning C4244: '=': conversion from '__int64' to
> '__le32', possible loss of data
> 
> on line 1890
> offset = (u8 *)(&groups->groups[0]) - (u8 *)groups;
> 
> Removed unnecessary zero init
> 
> Signed-off-by: Soumyadeep Hore <soumyadeep.hore@intel.com>

There seems to be lots of whitespace changes here unrelated to the actual
change in the patch description. Please try and keep the patches "clean"
with only changes described in the commit log present, as far as is
possible.

Thanks,
/Bruce

> ---
>  drivers/common/idpf/base/virtchnl2.h | 21 +++++++++++----------
>  1 file changed, 11 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/common/idpf/base/virtchnl2.h b/drivers/common/idpf/base/virtchnl2.h
> index 3900b784d0..f44c0965b4 100644
> --- a/drivers/common/idpf/base/virtchnl2.h
> +++ b/drivers/common/idpf/base/virtchnl2.h
> @@ -1,5 +1,5 @@
>  /* SPDX-License-Identifier: BSD-3-Clause
> - * Copyright(c) 2001-2023 Intel Corporation
> + * Copyright(c) 2001-2024 Intel Corporation
>   */
>  
>  #ifndef _VIRTCHNL2_H_
> @@ -47,9 +47,9 @@
>   * that is never used.
>   */
>  #define VIRTCHNL2_CHECK_STRUCT_LEN(n, X) enum virtchnl2_static_assert_enum_##X \
> -	{ virtchnl2_static_assert_##X = (n)/((sizeof(struct X) == (n)) ? 1 : 0) }
> +        { virtchnl2_static_assert_##X = (n)/((sizeof(struct X) == (n)) ? 1 : 0) }
>  #define VIRTCHNL2_CHECK_UNION_LEN(n, X) enum virtchnl2_static_asset_enum_##X \
> -	{ virtchnl2_static_assert_##X = (n)/((sizeof(union X) == (n)) ? 1 : 0) }
> +        { virtchnl2_static_assert_##X = (n)/((sizeof(union X) == (n)) ? 1 : 0) }
>  
>  /* New major set of opcodes introduced and so leaving room for
>   * old misc opcodes to be added in future. Also these opcodes may only
> @@ -471,8 +471,8 @@
>   * error regardless of version mismatch.
>   */
>  struct virtchnl2_version_info {
> -	u32 major;
> -	u32 minor;
> +        u32 major;
> +        u32 minor;
>  };
>  
>  VIRTCHNL2_CHECK_STRUCT_LEN(8, virtchnl2_version_info);
> @@ -1414,9 +1414,9 @@ VIRTCHNL2_CHECK_STRUCT_LEN(16, virtchnl2_mac_addr_list);
>   * and returns the status.
>   */
>  struct virtchnl2_promisc_info {
> -	__le32 vport_id;
> +        __le32 vport_id;
>  	/* see VIRTCHNL2_PROMISC_FLAGS definitions */
> -	__le16 flags;
> +        __le16 flags;
>  	u8 pad[2];
>  };
>  
> @@ -1733,7 +1733,8 @@ virtchnl2_vc_validate_vf_msg(__rte_unused struct virtchnl2_version_info *ver, u3
>  	case VIRTCHNL2_OP_ADD_QUEUE_GROUPS:
>  		valid_len = sizeof(struct virtchnl2_add_queue_groups);
>  		if (msglen != valid_len) {
> -			__le32 i = 0, offset = 0;
> +			__le64 offset;
> +			__le32 i;
>  			struct virtchnl2_add_queue_groups *add_queue_grp =
>  				(struct virtchnl2_add_queue_groups *)msg;
>  			struct virtchnl2_queue_groups *groups = &(add_queue_grp->qg_info);
> @@ -1904,8 +1905,8 @@ virtchnl2_vc_validate_vf_msg(__rte_unused struct virtchnl2_version_info *ver, u3
>  	/* These are always errors coming from the VF. */
>  	case VIRTCHNL2_OP_EVENT:
>  	case VIRTCHNL2_OP_UNKNOWN:
> -	default:
> -		return VIRTCHNL2_STATUS_ERR_ESRCH;
> +        default:
> +                return VIRTCHNL2_STATUS_ERR_ESRCH;
>  	}
>  	/* few more checks */
>  	if (err_msg_format || valid_len != msglen)
> -- 
> 2.43.0
> 

^ permalink raw reply	[relevance 0%]

* Re: [PATCH 8/8] gpio: tqmx86: fix broken IRQ_TYPE_EDGE_BOTH interrupt type
  @ 2024-05-29 12:37  1%   ` Andrew Lunn
  2024-05-29 12:44  1%     ` Matthias Schiffer
  0 siblings, 1 reply; 200+ results
From: Andrew Lunn @ 2024-05-29 12:37 UTC (permalink / raw)
  To: Matthias Schiffer
  Cc: Linus Walleij, Bartosz Golaszewski, linux-gpio, linux-kernel,
	Gregor Herburger, linux

On Wed, May 29, 2024 at 09:45:20AM +0200, Matthias Schiffer wrote:
> The TQMx86 GPIO controller only supports falling and rising edge
> triggers, but not both. Fix this by implementing a software both-edge
> mode that toggles the edge type after every interrupt.

Do you have a real use case for this, one that will handle lost
interrupts because it cannot swap edge quick enough?

I personally would not do this, because it is dangerous, it gives the
impression the device can do both, when in fact it cannot reliably.

For me, the correct fix is to return EOPNOTSUPP or EINVAL for BOTH.

	   Andrew

^ permalink raw reply	[relevance 1%]

* Re: [PATCH] tools/memory-model: Document herd7 (internal) representation
  @ 2024-05-29 12:37  1%         ` Jonas Oberhauser
  0 siblings, 0 replies; 200+ results
From: Jonas Oberhauser @ 2024-05-29 12:37 UTC (permalink / raw)
  To: Boqun Feng
  Cc: Andrea Parri, Hernan Ponce de Leon, stern, will, peterz, npiggin,
	dhowells, j.alglave, luc.maranget, paulmck, akiyks, dlustig,
	joel, linux-kernel, linux-arch



Am 5/28/2024 um 7:58 PM schrieb Boqun Feng:
> On Mon, May 27, 2024 at 03:40:13PM +0200, Jonas Oberhauser wrote:
>>
>>
>> Am 5/27/2024 um 3:28 PM schrieb Andrea Parri:
>>>>> +    |                smp_store_mb | W[once] ->po F[mb]                        |
>>>>
>>>> I expect this one to be hard-coded in herd7 source code, but I cannot find
>>>> it. Can you give me a pointer?
>>>
>>> smp_store_mb() is currently mapped to { __store{once}(X,V); __fence{mb}; } in
>>> the .def file, so it's semantically equivalent to "WRITE_ONCE(); smp_mb();".
>>
>> By the way, I experimented a little with these kind of mappings to see if we
>> can just explicitly encode the mapping there. E.g., I had an idea to use
>>      { __fence{mb-successful-rmw}; __cmpxchg{once}...;
>> __fence{mb-successful-rmw}; }
>>
>> for defining (almost) the current mapping of cmpxchg explicitly.
>>
>> But none of the changes I made were accepted by herd7.
>>
>> Do you know how the syntax works?
>>
> 
> This may not be trivial. Note that cmpxchg() is an expression (it has a
> value), so in .def, we want to define it as an expression. However, the
> C-like multiple-statement expression is not supported by herd parser, in
> other words we want:
> 
> 	{
> 		__fence{mb-successful-rmw};
> 		int tmp = __cmpxchg{once}(...);
> 		__fence{mb-successful-rmw};
> 		tmp;
> 	}

Oh, you're right. Then probably the rule I was violating is that 
value-returning macros can not be defined with {} at all.

Given herd's other syntactic limitations, perhaps the best way would be 
to introduce these macros as

	x = cmpxchg(...) {
		__fence{mb-successful-rmw};
  		x = __cmpxchg{once}(...);
  		__fence{mb-successful-rmw};
	}

since I think x = M(...) is the only way we are allowed to use these 
macros anyways.


^ permalink raw reply	[relevance 1%]

* Re: [PATCH v4] mc146818rtc: add a way to generate RTC interrupts via QMP
  @ 2024-05-29 12:36  1%   ` Philippe Mathieu-Daudé
  2024-05-29 12:43  0%     ` Daniil Tatianin
  0 siblings, 1 reply; 200+ results
From: Philippe Mathieu-Daudé @ 2024-05-29 12:36 UTC (permalink / raw)
  To: Markus Armbruster, Daniil Tatianin
  Cc: Michael S. Tsirkin, Paolo Bonzini, Eric Blake, qemu-devel

On 29/5/24 14:03, Markus Armbruster wrote:
> Daniil Tatianin <d-tatianin@yandex-team.ru> writes:
> 
>> This can be used to force-synchronize the time in guest after a long
>> stop-cont pause, which can be useful for serverless-type workload.
>>
>> Also add a comment to highlight the fact that this (and one other QMP
>> command) only works for the MC146818 RTC controller.
>>
>> Acked-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>> Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
>> ---
>>
>> Changes since v0:
>> - Rename to rtc-inject-irq to match other similar API
>> - Add a comment to highlight that this only works for the I386 RTC
>>
>> Changes since v1:
>> - Added a description below the QMP command to explain how it can be
>>    used and what it does.
>>
>> Changes since v2:
>> - Add a 'broadcast' suffix.
>> - Change the comments to explain the flags we're setting.
>> - Change the command description to fix styling & explain that it's a broadcast command.
>>
>> Changes since v3:
>> - Fix checkpatch complaints about usage of C99 comments
>>
>> ---
>>   hw/rtc/mc146818rtc.c         | 20 ++++++++++++++++++++
>>   include/hw/rtc/mc146818rtc.h |  1 +
>>   qapi/misc-target.json        | 19 +++++++++++++++++++
>>   3 files changed, 40 insertions(+)
>>
>> diff --git a/hw/rtc/mc146818rtc.c b/hw/rtc/mc146818rtc.c
>> index 3379f92748..96ecd43036 100644
>> --- a/hw/rtc/mc146818rtc.c
>> +++ b/hw/rtc/mc146818rtc.c
>> @@ -107,6 +107,11 @@ static void rtc_coalesced_timer_update(MC146818RtcState *s)
>>   static QLIST_HEAD(, MC146818RtcState) rtc_devices =
>>       QLIST_HEAD_INITIALIZER(rtc_devices);
>>   
>> +/*
>> + * NOTE:
>> + * The two QMP functions below are _only_ implemented for the MC146818.
>> + * All other RTC devices ignore this.
>> + */
>>   void qmp_rtc_reset_reinjection(Error **errp)
>>   {
>>       MC146818RtcState *s;
>> @@ -116,6 +121,21 @@ void qmp_rtc_reset_reinjection(Error **errp)
>>       }
>>   }
>>   
>> +void qmp_rtc_inject_irq_broadcast(Error **errp)
>> +{
>> +    MC146818RtcState *s;
>> +
>> +    QLIST_FOREACH(s, &rtc_devices, link) {
>> +        /* Update-ended interrupt enable */
>> +        s->cmos_data[RTC_REG_B] |= REG_B_UIE;
>> +
>> +        /* Interrupt request flag | update interrupt flag */
>> +        s->cmos_data[RTC_REG_C] |= REG_C_IRQF | REG_C_UF;
>> +
>> +        qemu_irq_raise(s->irq);
>> +    }
>> +}
>> +
>>   static bool rtc_policy_slew_deliver_irq(MC146818RtcState *s)
>>   {
>>       kvm_reset_irq_delivered();
>> diff --git a/include/hw/rtc/mc146818rtc.h b/include/hw/rtc/mc146818rtc.h
>> index 97cec0b3e8..e9dd0f9c72 100644
>> --- a/include/hw/rtc/mc146818rtc.h
>> +++ b/include/hw/rtc/mc146818rtc.h
>> @@ -56,5 +56,6 @@ MC146818RtcState *mc146818_rtc_init(ISABus *bus, int base_year,
>>   void mc146818rtc_set_cmos_data(MC146818RtcState *s, int addr, int val);
>>   int mc146818rtc_get_cmos_data(MC146818RtcState *s, int addr);
>>   void qmp_rtc_reset_reinjection(Error **errp);
>> +void qmp_rtc_inject_irq_broadcast(Error **errp);
>>   
>>   #endif /* HW_RTC_MC146818RTC_H */
>> diff --git a/qapi/misc-target.json b/qapi/misc-target.json
>> index 4e0a6492a9..7d388a3753 100644
>> --- a/qapi/misc-target.json
>> +++ b/qapi/misc-target.json
>> @@ -19,6 +19,25 @@
>>   { 'command': 'rtc-reset-reinjection',
>>     'if': 'TARGET_I386' }
>>   
>> +##
>> +# @rtc-inject-irq-broadcast:
>> +#
>> +# Inject an RTC interrupt for all existing RTCs on the system.
>> +# The interrupt forces the guest to synchronize the time with RTC.
>> +# This is useful after a long stop-cont pause, which is common for
>> +# serverless-type workload.

In previous version you said:

   > This isn't really related to migration though. Serverless is based
   > on constantly stopping and resuming the VM on e.g. every HTTP
   > request to an endpoint.

Which made some sense. Maybe mention HTTP? And point to that use case
(possibly with QMP commands) in the commit description?

> Make that "workloads".
> 
> "For all existing RTCs" is a lie.  It's really just all mc146818s.  The
> command works as documented only as long as the VM has no other RTCs.

@rtc-mc146818-force-sync-broadcast sounds clearer & safer;
IIUC the command goal, mentioning IRQ injection is irrelevant
(implementation detail).

(I'm trying to not spread the problems we already have with
@rtc-reset-reinjection).

>> +#
>> +# Since: 9.1
>> +#
>> +# Example:
>> +#
>> +#     -> { "execute": "rtc-inject-irq-broadcast" }
>> +#     <- { "return": {} }
>> +#
>> +##
>> +{ 'command': 'rtc-inject-irq-broadcast',
>> +  'if': 'TARGET_I386' }
> 
> The conditional kind-of-sort-of ensures "VM has no other RTCs":
> TARGET_I386 compiles only this file in hw/rtc/, and therefore can't have
> other RTCs (unless they're hiding in some other directory).  Brittle.
> 
> When we move to single binary, we will compile in other RTCs.  How can
> we ensure "VM has no nother RTCs" then?  What if one of these other RTCs
> can be added with -device or device_add?
> 
> When this falls apart because the VM does have other RTCs, it can only
> do so silently: the command can't tell us for which RTCs it actually
> injected an interrupt.
> 
> Documentation making promises the implementation doesn't actually
> deliver can only end in tears.  The only reason I'm not rejecting this
> patch out of hand is the existing and similarly broken
> rtc-reset-reinjection.
> 
> I'm willing to reluctantly accept it with honest documentation.
> Perhaps: "Bug: RTCs other than mc146818rtc are silently ignored."
> 
> Much, much better would be an interface that's actually usable with
> multiple RTCs.  We'd have to talk how interrupt injection could be used
> with such a machine.
> 
> Anything less will likely need to be replaced later on.
> 
>> +
>>   ##
>>   # @SevState:
>>   #
> 



^ permalink raw reply	[relevance 1%]

* [PATCH v2 1/2] powerpc/uaccess: Fix build errors seen with GCC 13/14
@ 2024-05-29 12:30  1% Michael Ellerman
  2024-05-29 12:30  5% ` [PATCH v2 2/2] powerpc/uaccess: Use YZ asm constraint for ld Michael Ellerman
  0 siblings, 1 reply; 200+ results
From: Michael Ellerman @ 2024-05-29 12:30 UTC (permalink / raw)
  To: linuxppc-dev

Building ppc64le_defconfig with GCC 14 fails with assembler errors:

    CC      fs/readdir.o
  /tmp/ccdQn0mD.s: Assembler messages:
  /tmp/ccdQn0mD.s:212: Error: operand out of domain (18 is not a multiple of 4)
  /tmp/ccdQn0mD.s:226: Error: operand out of domain (18 is not a multiple of 4)
  ... [6 lines]
  /tmp/ccdQn0mD.s:1699: Error: operand out of domain (18 is not a multiple of 4)

A snippet of the asm shows:

  # ../fs/readdir.c:210:         unsafe_copy_dirent_name(dirent->d_name, name, namlen, efault_end);
         ld 9,0(29)       # MEM[(u64 *)name_38(D) + _88 * 1], MEM[(u64 *)name_38(D) + _88 * 1]
  # 210 "../fs/readdir.c" 1
         1:      std 9,18(8)     # put_user       # *__pus_addr_52, MEM[(u64 *)name_38(D) + _88 * 1]

The 'std' instruction requires a 4-byte aligned displacement because
it is a DS-form instruction, and as the assembler says, 18 is not a
multiple of 4.

A similar error is seen with GCC 13 and CONFIG_UBSAN_SIGNED_WRAP=y.

The fix is to change the constraint on the memory operand to put_user(),
from "m" which is a general memory reference to "YZ".

The "Z" constraint is documented in the GCC manual PowerPC machine
constraints, and specifies a "memory operand accessed with indexed or
indirect addressing". "Y" is not documented in the manual but specifies
a "memory operand for a DS-form instruction". Using both allows the
compiler to generate a DS-form "std" or X-form "stdx" as appropriate.

The change has to be conditional on CONFIG_PPC_KERNEL_PREFIXED because
the "Y" constraint does not guarantee 4-byte alignment when prefixed
instructions are enabled.

Unfortunately clang doesn't support the "Y" constraint so that has to be
behind an ifdef.

Although the build error is only seen with GCC 13/14, that appears
to just be luck. The constraint has been incorrect since it was first
added.

Fixes: c20beffeec3c ("powerpc/uaccess: Use flexible addressing with __put_user()/__get_user()")
Cc: stable@vger.kernel.org # v5.10+
Suggested-by: Kewen Lin <linkw@gcc.gnu.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 arch/powerpc/include/asm/uaccess.h | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

v2: Update changelog to mention breakage with GCC 13 and UBSAN.

diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index de10437fd206..4cba724c8899 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -92,9 +92,25 @@ __pu_failed:							\
 		: label)
 #endif
 
+#ifdef CONFIG_CC_IS_CLANG
+#define DS_FORM_CONSTRAINT "Z<>"
+#else
+#define DS_FORM_CONSTRAINT "YZ<>"
+#endif
+
 #ifdef __powerpc64__
+#ifdef CONFIG_PPC_KERNEL_PREFIXED
 #define __put_user_asm2_goto(x, ptr, label)			\
 	__put_user_asm_goto(x, ptr, label, "std")
+#else
+#define __put_user_asm2_goto(x, addr, label)			\
+	asm goto ("1: std%U1%X1 %0,%1	# put_user\n"		\
+		EX_TABLE(1b, %l2)				\
+		:						\
+		: "r" (x), DS_FORM_CONSTRAINT (*addr)		\
+		:						\
+		: label)
+#endif // CONFIG_PPC_KERNEL_PREFIXED
 #else /* __powerpc64__ */
 #define __put_user_asm2_goto(x, addr, label)			\
 	asm goto(					\
-- 
2.45.1


^ permalink raw reply related	[relevance 1%]

* Re: [External] /var/log as persistent
  @ 2024-05-29 12:29  1%   ` Patrick Williams
  0 siblings, 0 replies; 200+ results
From: Patrick Williams @ 2024-05-29 12:29 UTC (permalink / raw)
  To: Lei Yu; +Cc: OpenBMC List

[-- Attachment #1: Type: text/plain, Size: 5244 bytes --]

On Wed, May 29, 2024 at 11:49:15AM +0800, Lei Yu wrote:
> On Wed, May 29, 2024 at 1:41 AM Patrick Williams <patrick@stwcx.xyz> wrote:
> >
> > Hello,
> >
> > It was pointed out that I did not do a good job of broadcasting a change
> > I made back in March, so I am sending this out for awareness now.
> >
> > https://gerrit.openbmc.org/c/openbmc/openbmc/+/69959
> >
> > A default setting from bitbake (to VOLATILE_LOG_DIR) was causing some
> > platforms to not be able to persist `/var/log` and instead it was
> > mounted as a temporary directory.  This meant that even if you
> > explicitly configured journald to use `/var/log` (instead of the
> > `/run/log` it uses by default) you would not get persistent journalling.
> > It also meant that applications like `obmc-console` log files were not
> > persistent and would be lost in a BMC reboot.
> >
> 
> 1. VOLATILE_LOG_DIR is defaulted to `yes` in poky/meta/conf/bitbake.conf
> 2. With static layout, the above config makes the `/var/log` a
> volatile dir linked to `/var/volatile/log`, where `/var/volatile` is a
> tmpfs.
> 
> Be noted that it's the default for OpenBMC machines with static flash layouts.
> So the journal log and obmc-console were volatile **by default**.

I was still surprised that the journal was being persisted for you with
this change.  I'm looking now in more detail at the journald.conf because
there are only a few platforms that explicitly set `Storage=persistent`.

The primary reason I made this change was because setting the journal
config had **no effect**, which is, I think very unintuitive.

It seems that the default journal config is `Storage=auto` which means
that it will be volatile only if `/var/log/journal` exists.  This might
be why you are now seeing it persist.

> Users should not expect the above logs to be persistent, and if they
> do, they could config `VOLATILE_LOG_DIR` to `no`, which is done in
> `mtjade` and `mtmitchell` layer.

Conversely we could have machines that want it to be non-persistent to
set VOLATILE_LOG_DIR, right?  It isn't obvious why one default is
"better" than another.

My impression is that VOLATILE_LOG_DIR is default partially because
syslog is also the default.  As I said, with VOLATILE_LOG_DIR,
`Storage=persistent` has no affect.

If the only discussion here is really about the systemd-journal, we can
add a PACKAGECONFIG that chooses between `Storage=volatile` and
`Storage=persistent`.  It seems we already have 3 different meta-layers
with a custom journald-config to trigger this, so we might as well
consolidate those.

> The change `https://gerrit.openbmc.org/c/openbmc/openbmc/+/69959`
> makes `VOLATILE_LOG_DIR` to `yes` by default in `meta-phosphor` layer,
> which effectively affects all OpenBMC builds.
> 
> > I had asked a few machine owners and most of them either had it set to
> > explicitly unset `VOLATILE_LOG_DIR` in their meta-layer or through some
> > downstream changes had overwritten it.  So, I made this the default.
> >
> > I thought this only affected:
> >    - machines that explicitly set `Storage=persistent` in the journald
> >      config.
> >    - everyone's obmc-console logs.
> >
> > Based on the report from a downstream user, it seems like there might be
> > more effects?  I'm not sure at this point, but advertising it wider.
> 
> As above information, OpenBMC users were expecting "volatile" logs
> before, and we should keep it default.
> So I would suggest we revert the change to keep the consistency about
> the default volatile log dir.

Were they "expecting"?  This is where I did ask a few of the machine
owners who have upstream systems in production.  All of them told me
they overwrite this already.

I highly suspect that any commercial system is going to want
persistence.  I can understand what you have referred to with rsyslog
for cloud systems.  I think this is one of those cases where whatever
the default is, it won't satisfy everyone.  (We would be considered a
"cloud" style system but don't want to rely exclusively on rsyslog
because you then don't get visibility to debug network issues.)

> And for the reasons why I prefer the volatile log directory:
> * In most OpenBMC machine builds we see 32/64/128 SPI flashes are
> used, so the `rwfs` is limited and the frequent "writes" to the SPI
> flash costs the lifespan.

Are you seeing lifetime issues with SPI-NOR?  Aren't they rated for at
least 1 million erase cycles?  Even with the static layout, where all
writes are going to the same location, that should give you 32 years of
use at 1 erase per second (assuming only 4MiB of rwfs space).

> * To collect the logs, we could either use rsyslog or the host-logger
> (which were "already there") to send the logs to remote servers. So
> there is no strong requirement to make the logs persistent.

Are you really wanting obmc-console to *not* persist?  Do you think most
people want this?  This is a bit surprising to me because obmc-console
already has configuration limiting the size of the log files and it has
a rotate functionality; the amount of space (and erase cycles) used by it
is probably low.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[relevance 1%]

* Re: [PATCHv11 05/19] x86/relocate_kernel: Use named labels for less confusion
  2024-05-29 11:28  3%         ` Borislav Petkov
@ 2024-05-29 12:33  3%           ` Andrew Cooper
  -1 siblings, 0 replies; 200+ results
From: Andrew Cooper @ 2024-05-29 12:33 UTC (permalink / raw)
  To: Borislav Petkov, Kirill A. Shutemov
  Cc: Nikolay Borisov, Thomas Gleixner, Ingo Molnar, Dave Hansen, x86,
	Rafael J. Wysocki, Peter Zijlstra, Adrian Hunter,
	Kuppuswamy Sathyanarayanan, Elena Reshetova, Jun Nakajima,
	Rick Edgecombe, Tom Lendacky, Kalra, Ashish, Sean Christopherson,
	Huang, Kai, Ard Biesheuvel, Baoquan He, H. Peter Anvin,
	K. Y. Srinivasan, Haiyang Zhang, kexec, linux-hyperv, linux-acpi,
	linux-coco, linux-kernel

On 29/05/2024 12:28 pm, Borislav Petkov wrote:
> On Wed, May 29, 2024 at 02:17:29PM +0300, Kirill A. Shutemov wrote:
>>> That jmp 1f becomes redundant now as it simply jumps 1 line below.
>>>
>> Nothing changed wrt this jump. It dates back to initial kexec
>> implementation.
>>
>> See 5234f5eb04ab ("[PATCH] kexec: x86_64 kexec implementation").
>>
>> But I don't see functional need in it.
>>
>> Anyway, it is outside of the scope of the patch.
> Yap, Kirill did what Nikolay should've done - git archeology. Please
> don't forget to do that next time.
>
> And back in the day they didn't comment non-obvious things because
> commenting is for losers. :-\
>
> So that unconditional forward jump either flushes branch prediction on
> some old uarch or something else weird, uarch-special.
>
> I doubt we can remove it just like that.
>
> Lemme add Andy - he should know.

Seems I've gained a reputation...

jmp 1f dates back to ye olde 8086, which started the whole trend of the
instruction pointer just being a figment of the ISA's imagination[1].

Hardware maintains the pointer to the next byte to fetch (the prefetch
queue was up to 6 bytes), and there was a micro-op to subtract the
current length of the prefetch queue from the accumulator.

In those days, the prefetch queue was not coherent with main memory, and
jumps (being a discontinuity in the instruction stream) simply flushed
the prefetch queue.

This was necessary after modifying executable code, because otherwise
you could end up executing stale bytes from the prefetch queue and then
non-stale bytes thereafter.  (Otherwise known as the way to distinguish
the 8086 from the 8088 because the latter only had a 4 byte prefetch queue.)

Anyway.  It's how you used to spell "serialising operation" before that
term ever entered the architecture.  Linux still supports CPUs prior to
the Pentium, so still needs to care about prefetch queues in the 486.

However, this example appears to be in 64bit code and following a write
to CR4 which will be fully serialising, so it's probably copy&paste from
32bit code where it would be necessary in principle.

~Andrew

[1]
https://www.righto.com/2023/01/inside-8086-processors-instruction.html#fn:pc

In fact, anyone who hasn't should read the entire series on the 8086,
https://www.righto.com/p/index.html

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[relevance 3%]

* Re: [PATCHv11 05/19] x86/relocate_kernel: Use named labels for less confusion
@ 2024-05-29 12:33  3%           ` Andrew Cooper
  0 siblings, 0 replies; 200+ results
From: Andrew Cooper @ 2024-05-29 12:33 UTC (permalink / raw)
  To: Borislav Petkov, Kirill A. Shutemov
  Cc: Nikolay Borisov, Thomas Gleixner, Ingo Molnar, Dave Hansen, x86,
	Rafael J. Wysocki, Peter Zijlstra, Adrian Hunter,
	Kuppuswamy Sathyanarayanan, Elena Reshetova, Jun Nakajima,
	Rick Edgecombe, Tom Lendacky, Kalra, Ashish, Sean Christopherson,
	Huang, Kai, Ard Biesheuvel, Baoquan He, H. Peter Anvin,
	K. Y. Srinivasan, Haiyang Zhang, kexec, linux-hyperv, linux-acpi,
	linux-coco, linux-kernel

On 29/05/2024 12:28 pm, Borislav Petkov wrote:
> On Wed, May 29, 2024 at 02:17:29PM +0300, Kirill A. Shutemov wrote:
>>> That jmp 1f becomes redundant now as it simply jumps 1 line below.
>>>
>> Nothing changed wrt this jump. It dates back to initial kexec
>> implementation.
>>
>> See 5234f5eb04ab ("[PATCH] kexec: x86_64 kexec implementation").
>>
>> But I don't see functional need in it.
>>
>> Anyway, it is outside of the scope of the patch.
> Yap, Kirill did what Nikolay should've done - git archeology. Please
> don't forget to do that next time.
>
> And back in the day they didn't comment non-obvious things because
> commenting is for losers. :-\
>
> So that unconditional forward jump either flushes branch prediction on
> some old uarch or something else weird, uarch-special.
>
> I doubt we can remove it just like that.
>
> Lemme add Andy - he should know.

Seems I've gained a reputation...

jmp 1f dates back to ye olde 8086, which started the whole trend of the
instruction pointer just being a figment of the ISA's imagination[1].

Hardware maintains the pointer to the next byte to fetch (the prefetch
queue was up to 6 bytes), and there was a micro-op to subtract the
current length of the prefetch queue from the accumulator.

In those days, the prefetch queue was not coherent with main memory, and
jumps (being a discontinuity in the instruction stream) simply flushed
the prefetch queue.

This was necessary after modifying executable code, because otherwise
you could end up executing stale bytes from the prefetch queue and then
non-stale bytes thereafter.  (Otherwise known as the way to distinguish
the 8086 from the 8088 because the latter only had a 4 byte prefetch queue.)

Anyway.  It's how you used to spell "serialising operation" before that
term ever entered the architecture.  Linux still supports CPUs prior to
the Pentium, so still needs to care about prefetch queues in the 486.

However, this example appears to be in 64bit code and following a write
to CR4 which will be fully serialising, so it's probably copy&paste from
32bit code where it would be necessary in principle.

~Andrew

[1]
https://www.righto.com/2023/01/inside-8086-processors-instruction.html#fn:pc

In fact, anyone who hasn't should read the entire series on the 8086,
https://www.righto.com/p/index.html

^ permalink raw reply	[relevance 3%]

* Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Swap Abstraction "the pony"
  @ 2024-05-29 12:33  0%             ` Matthew Wilcox
  0 siblings, 0 replies; 200+ results
From: Matthew Wilcox @ 2024-05-29 12:33 UTC (permalink / raw)
  To: Chris Li
  Cc: Karim Manaouil, Jan Kara, Chuanhua Han, linux-mm, lsf-pc,
	ryan.roberts, 21cnbao, david

On Tue, May 28, 2024 at 11:50:47PM -0700, Chris Li wrote:
> On Tue, May 28, 2024 at 8:57 PM Matthew Wilcox <willy@infradead.org> wrote:
> >
> > On Tue, May 21, 2024 at 01:40:56PM -0700, Chris Li wrote:
> > > > Filesystems already implemented a lot of solutions for fragmentation
> > > > avoidance that are more apropriate for slow storage media.
> > >
> > > Swap and file systems have very different requirements and usage
> > > patterns and IO patterns.
> >
> > Should they, though?  Filesystems noticed that handling pages in LRU
> > order was inefficient and so they stopped doing that (see the removal
> > of aops->writepage in favour of ->writepages, along with where each are
> > called from).  Maybe it's time for swap to start doing writes in the order
> > of virtual addresses within a VMA, instead of LRU order.
> 
> Well, swap has one fundamental difference than file system:
> the dirty file system cache will need to eventually write to file
> backing at least once, otherwise machine reboots you lose the data.

Yes, that's why we write back data from the page cache every 30 seconds
or so.  It's still important to not write back too early, otherwise
you need to write the same block multiple times.  The differences aren't
as stark as you're implying.

> Where the anonymous memory case, the dirty page does not have to write
> to swap. It is optional, so which page you choose to swap out is
> critical, you want to swap out the coldest page, the page that is
> least likely to get swapin. Therefore, the LRU makes sense.

Disagree.  There are two things you want and the LRU serves neither
particularly well.  One is that when you want to reclaim memory, you
want to find some memory that is likely to not be accessed in the next
few seconds/minutes/hours.  It doesn't need to be the coldest, just in
(say) the coldest 10% or so of memory.  And it needs to already be clean,
otherwise you have to wait for it to writeback, and you can't afford that.

The second thing you need to be able to do is find pages which are
already dirty, and not likely to be written to soon, and write those
back so they join the pool of clean pages which are eligible for reclaim.
Again, the LRU isn't really the best tool for the job.

> In VMA swap out, the question is, which VMA you choose from first? To
> make things more complicated, the same page can map into different
> processes in more than one VMA as well.

This is why we have the anon_vma, to handle the same pages mapped from
multiple VMAs.

> > Indeed, if we're open to radical ideas, the LRU sucks.  A physical scan
> > is 40x faster:
> > https://lore.kernel.org/linux-mm/ZTc7SHQ4RbPkD3eZ@casper.infradead.org/
> 
> That simulation assumes the page struct has access to information already.
> On the physical CPU level, the access bit is from the PTE. If you scan
> from physical page order, you need to use rmap to find the PTE to
> check the access bit. It is not a simple pfn page order walk. You need
> to scan the PTE first then move the access information into page
> struct.

We already maintain the dirty bit on the folio when we take a write-fault
for file memory.  If we do that for anon memory as well, we don't need
to do an rmap walk at scan time.

> > > One challenging aspect is that the current swap back end has a very
> > > low per swap entry memory overhead. It is about 1 byte (swap_map), 2
> > > byte (swap cgroup), 8 byte(swap cache pointer). The inode struct is
> > > more than 64 bytes per file. That is a big jump if you map a swap
> > > entry to a file. If you map more than one swap entry to a file, then
> > > you need to track the mapping of file offset to swap entry, and the
> > > reverse lookup of swap entry to a file with offset. Whichever way you
> > > cut it, it will significantly increase the per swap entry memory
> > > overhead.
> >
> > Not necessarily, no.  If your workload uses a lot of order-2, order-4
> > and order-9 folios, then the current scheme is using 11 bytes per page,
> > so 44 bytes per order-2 folio, 176 per order-4 folio and 5632 per
> > order-9 folio.  That's a lot of bytes we can use for an extent-based
> > scheme.
> 
> Yes, if we allow dynamic allocation of swap entry, the 24B option.
> Then sub entries inside the compound swap entry structure can share
> the same compound swap struct pointer.
> 
> >
> > Also, why would you compare the size of an inode to the size of an
> > inode?  inode is ~equivalent to an anon_vma, not to a swap entry.
> 
> I am not assigning inode to one swap entry. That is covered in my
> description of "if you map more than one swap entry to a file". If you
> want to map each inode to anon_vma, you need to have a way to map
> inode  and file offset into swap entry encoding. In your anon_vma as
> inode world, how do you deal with two different vma containing the
> same page? Once we have more detail of the swap entry mapping scheme,
> we can analyse the pros and cons.

Are you confused between an anon_vma and an anon vma?  The naming in
this area is terrible.  Maybe we should call it an mnode instead of an
anon_vma.  The parallel with inode would be more obvious ...


^ permalink raw reply	[relevance 0%]

* Re: [PATCH 01/25] common/idpf: added NVME CPF specific code with defines
  @ 2024-05-29 12:32  0%   ` Bruce Richardson
  0 siblings, 0 replies; 200+ results
From: Bruce Richardson @ 2024-05-29 12:32 UTC (permalink / raw)
  To: Soumyadeep Hore; +Cc: yuying.zhang, jingjing.wu, dev

On Tue, May 28, 2024 at 07:28:31AM +0000, Soumyadeep Hore wrote:
> The aim of the changes is to remove NVME dependency on

Hi,

The intro words "The aim of the changes" is unnecessary. Just shorten the
commit log by stating what the patch is for without any intro:

"Remove NVME dependency on memory allocations..."

If rewording, it would be worth including detail about when the define is
expected to be used - will it be defined/configured in a later patch, or is
it expected that it's a build-time setting set by user? If latter case, we
need a doc update here.

One further minor nit below too.

/Bruce



> memory allocations, and to use a prepared buffer instead.
> 
> The changes do not affect other components.
> 
> Signed-off-by: Soumyadeep Hore <soumyadeep.hore@intel.com>
> ---
>  drivers/common/idpf/base/idpf_controlq.c     | 27 +++++++++++++++++---
>  drivers/common/idpf/base/idpf_controlq_api.h |  9 +++++--
>  2 files changed, 31 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/common/idpf/base/idpf_controlq.c b/drivers/common/idpf/base/idpf_controlq.c
> index a82ca628de..0ba7281a45 100644
> --- a/drivers/common/idpf/base/idpf_controlq.c
> +++ b/drivers/common/idpf/base/idpf_controlq.c
> @@ -1,5 +1,5 @@
>  /* SPDX-License-Identifier: BSD-3-Clause
> - * Copyright(c) 2001-2023 Intel Corporation
> + * Copyright(c) 2001-2024 Intel Corporation
>   */
>  
>  #include "idpf_controlq.h"
> @@ -145,8 +145,12 @@ int idpf_ctlq_add(struct idpf_hw *hw,
>  	    qinfo->buf_size > IDPF_CTLQ_MAX_BUF_LEN)
>  		return -EINVAL;
>  
> +#ifndef NVME_CPF
>  	cq = (struct idpf_ctlq_info *)
>  	     idpf_calloc(hw, 1, sizeof(struct idpf_ctlq_info));
> +#else
> +	cq = *cq_out;
> +#endif
>  	if (!cq)
>  		return -ENOMEM;
>  
> @@ -172,10 +176,15 @@ int idpf_ctlq_add(struct idpf_hw *hw,
>  	}
>  
>  	if (status)
> +#ifdef NVME_CPF
> +		return status;
> +#else
>  		goto init_free_q;
> +#endif
>  
>  	if (is_rxq) {
>  		idpf_ctlq_init_rxq_bufs(cq);
> +#ifndef NVME_CPF
>  	} else {
>  		/* Allocate the array of msg pointers for TX queues */
>  		cq->bi.tx_msg = (struct idpf_ctlq_msg **)
> @@ -185,6 +194,7 @@ int idpf_ctlq_add(struct idpf_hw *hw,
>  			status = -ENOMEM;
>  			goto init_dealloc_q_mem;
>  		}
> +#endif
>  	}
>  
>  	idpf_ctlq_setup_regs(cq, qinfo);
> @@ -195,6 +205,7 @@ int idpf_ctlq_add(struct idpf_hw *hw,
>  
>  	LIST_INSERT_HEAD(&hw->cq_list_head, cq, cq_list);
>  
> +#ifndef NVME_CPF
>  	*cq_out = cq;
>  	return status;
>  
> @@ -205,6 +216,7 @@ int idpf_ctlq_add(struct idpf_hw *hw,
>  	idpf_free(hw, cq);
>  	cq = NULL;
>  
> +#endif
>  	return status;
>  }
>  
> @@ -232,8 +244,13 @@ void idpf_ctlq_remove(struct idpf_hw *hw,
>   * destroyed. This must be called prior to using the individual add/remove
>   * APIs.
>   */
> +#ifdef NVME_CPF
> +int idpf_ctlq_init(struct idpf_hw *hw, u8 num_q,
> +                   struct idpf_ctlq_create_info *q_info, struct idpf_ctlq_info **ctlq)
> +#else
>  int idpf_ctlq_init(struct idpf_hw *hw, u8 num_q,
>  		   struct idpf_ctlq_create_info *q_info)
> +#endif
>  {
>  	struct idpf_ctlq_info *cq = NULL, *tmp = NULL;
>  	int ret_code = 0;
> @@ -244,6 +261,10 @@ int idpf_ctlq_init(struct idpf_hw *hw, u8 num_q,
>  	for (i = 0; i < num_q; i++) {
>  		struct idpf_ctlq_create_info *qinfo = q_info + i;
>  
> +#ifdef NVME_CPF
> +		cq = *(ctlq + i);
> +
> +#endif	
>  		ret_code = idpf_ctlq_add(hw, qinfo, &cq);
>  		if (ret_code)
>  			goto init_destroy_qs;
> @@ -398,7 +419,7 @@ int idpf_ctlq_send(struct idpf_hw *hw, struct idpf_ctlq_info *cq,
>   * ctlq_msgs and free or reuse the DMA buffers.
>   */
>  static int __idpf_ctlq_clean_sq(struct idpf_ctlq_info *cq, u16 *clean_count,
> -				struct idpf_ctlq_msg *msg_status[], bool force)
> +		                struct idpf_ctlq_msg *msg_status[], bool force)
>  {
>  	struct idpf_ctlq_desc *desc;
>  	u16 i = 0, num_to_clean;
> @@ -469,7 +490,7 @@ static int __idpf_ctlq_clean_sq(struct idpf_ctlq_info *cq, u16 *clean_count,
>   * ctlq_msgs and free or reuse the DMA buffers.
>   */
>  int idpf_ctlq_clean_sq_force(struct idpf_ctlq_info *cq, u16 *clean_count,
> -			     struct idpf_ctlq_msg *msg_status[])
> +		             struct idpf_ctlq_msg *msg_status[])
>  {
>  	return __idpf_ctlq_clean_sq(cq, clean_count, msg_status, true);
>  }
> diff --git a/drivers/common/idpf/base/idpf_controlq_api.h b/drivers/common/idpf/base/idpf_controlq_api.h
> index 38f5d2df3c..bce5187981 100644
> --- a/drivers/common/idpf/base/idpf_controlq_api.h
> +++ b/drivers/common/idpf/base/idpf_controlq_api.h
> @@ -1,5 +1,5 @@
>  /* SPDX-License-Identifier: BSD-3-Clause
> - * Copyright(c) 2001-2023 Intel Corporation
> + * Copyright(c) 2001-2024 Intel Corporation
>   */
>  
>  #ifndef _IDPF_CONTROLQ_API_H_
> @@ -158,8 +158,13 @@ enum idpf_mbx_opc {
>  /* Will init all required q including default mb.  "q_info" is an array of
>   * create_info structs equal to the number of control queues to be created.
>   */
> +#ifdef NVME_CPF
> +int idpf_ctlq_init(struct idpf_hw *hw, u8 num_q,
> +                   struct idpf_ctlq_create_info *q_info, struct idpf_ctlq_info **ctlq);
> +#else
>  int idpf_ctlq_init(struct idpf_hw *hw, u8 num_q,
>  		   struct idpf_ctlq_create_info *q_info);
> +#endif
>  
>  /* Allocate and initialize a single control queue, which will be added to the
>   * control queue list; returns a handle to the created control queue
> @@ -186,7 +191,7 @@ int idpf_ctlq_recv(struct idpf_ctlq_info *cq, u16 *num_q_msg,
>  
>  /* Reclaims all descriptors on HW write back */
>  int idpf_ctlq_clean_sq_force(struct idpf_ctlq_info *cq, u16 *clean_count,
> -			     struct idpf_ctlq_msg *msg_status[]);
> +		             struct idpf_ctlq_msg *msg_status[]);

This is a whitespace change that has slipped in unrelated to the rest of
the patch. Not a big deal, just keep an eye out for such things. If there
are a few like this, you can consider just putting them in a misc patch at
the end.

>  
>  /* Reclaims send descriptors on HW write back */
>  int idpf_ctlq_clean_sq(struct idpf_ctlq_info *cq, u16 *clean_count,
> -- 
> 2.43.0
> 

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3 10/12] KVM: arm64: nVHE: Support CONFIG_CFI_CLANG at EL2
  @ 2024-05-29 12:30  0%       ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:30 UTC (permalink / raw)
  To: Will Deacon
  Cc: kvmarm, linux-arm-kernel, kvm, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Hi Will,

On Mon, May 13, 2024 at 06:30:05PM +0100, Will Deacon wrote:
> On Fri, May 10, 2024 at 12:26:39PM +0100, Pierre-Clément Tosi wrote:
> > [...]
> > 
> > Use SYM_TYPED_FUNC_START() for __pkvm_init_switch_pgd, as nVHE can't
> > call it directly and must use a PA function pointer from C (because it
> > is part of the idmap page), which would trigger a kCFI failure if the
> > type ID wasn't present.
> > 
> > Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
> > ---
> >  arch/arm64/include/asm/esr.h       |  6 ++++++
> >  arch/arm64/kvm/handle_exit.c       | 11 +++++++++++
> >  arch/arm64/kvm/hyp/nvhe/Makefile   |  6 +++---
> >  arch/arm64/kvm/hyp/nvhe/hyp-init.S |  6 +++++-
> >  4 files changed, 25 insertions(+), 4 deletions(-)
> > 
> >  [...]
> > 
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> > index 5a15737b4233..33fb5732ab83 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> > @@ -5,6 +5,7 @@
> >   */
> >  
> >  #include <linux/arm-smccc.h>
> > +#include <linux/cfi_types.h>
> >  #include <linux/linkage.h>
> >  
> >  #include <asm/alternative.h>
> > @@ -268,8 +269,11 @@ SYM_CODE_END(__kvm_handle_stub_hvc)
> >  /*
> >   * void __pkvm_init_switch_pgd(struct kvm_nvhe_init_params *params,
> >   *                             void (*finalize_fn)(void));
> > + *
> > + * SYM_TYPED_FUNC_START() allows C to call this ID-mapped function indirectly
> > + * using a physical pointer without triggering a kCFI failure.
> >   */
> > -SYM_FUNC_START(__pkvm_init_switch_pgd)
> > +SYM_TYPED_FUNC_START(__pkvm_init_switch_pgd)
> >  	/* Load the inputs from the VA pointer before turning the MMU off */
> >  	ldr	x5, [x0, #NVHE_INIT_PGD_PA]
> >  	ldr	x0, [x0, #NVHE_INIT_STACK_HYP_VA]
> 
> Unrelated hunk?

No, this is needed to prevent a kCFI failure at EL2.

Please let me know if the comment and commit message aren't clear enough.

> 
> Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 resend 2/8] hwtracing: use for_each_endpoint_of_node()
  @ 2024-05-29 12:30  3%       ` James Clark
  0 siblings, 0 replies; 200+ results
From: James Clark @ 2024-05-29 12:30 UTC (permalink / raw)
  To: Laurent Pinchart, Kuninori Morimoto, coresight
  Cc: Alexandre Belloni, Alexander Shishkin, Tomi Valkeinen,
	linux-fbdev, dri-devel, prabhakar.csengg, Krzysztof Kozlowski,
	David Airlie, Helge Deller, linux-staging, linux-media,
	Daniel Vetter, Suzuki K Poulose, Maarten Lankhorst,
	Eugen Hristev, Rob Herring, Maxime Ripard, Mauro Carvalho Chehab,
	Michal Simek, linux-arm-kernel, Greg Kroah-Hartman,
	Claudiu Beznea, Thomas Zimmermann



On 29/05/2024 01:40, Laurent Pinchart wrote:
> Hi Morimoto-san,
> 
> Thank you for the patch.
> 
> On Tue, May 28, 2024 at 11:55:32PM +0000, Kuninori Morimoto wrote:
>> We already have for_each_endpoint_of_node(), don't use
>> of_graph_get_next_endpoint() directly. Replace it.
>>
>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>>  drivers/hwtracing/coresight/coresight-platform.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
>> index 9d550f5697fa8..e9683e613d520 100644
>> --- a/drivers/hwtracing/coresight/coresight-platform.c
>> +++ b/drivers/hwtracing/coresight/coresight-platform.c
>> @@ -275,7 +275,7 @@ static int of_get_coresight_platform_data(struct device *dev,
>>  	 */
>>  	if (!parent) {
>>  		/*
>> -		 * Avoid warnings in of_graph_get_next_endpoint()
>> +		 * Avoid warnings in for_each_endpoint_of_node()
>>  		 * if the device doesn't have any graph connections
>>  		 */
>>  		if (!of_graph_is_present(node))
>> @@ -286,7 +286,7 @@ static int of_get_coresight_platform_data(struct device *dev,
>>  	}
>>  
>>  	/* Iterate through each output port to discover topology */
>> -	while ((ep = of_graph_get_next_endpoint(parent, ep))) {
>> +	for_each_endpoint_of_node(parent, ep) {
>>  		/*
>>  		 * Legacy binding mixes input/output ports under the
>>  		 * same parent. So, skip the input ports if we are dealing
> 
> I think there's a bug below. The loop contains
> 
> 		ret = of_coresight_parse_endpoint(dev, ep, pdata);
> 		if (ret)
> 			return ret;
> 
> which leaks the reference to ep. This is not introduced by this patch,
> so
> 

Nice catch, I will send a patch.

Also:

Reviewed-by: James Clark <james.clark@arm.com>

> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 3%]

* Re: [PATCH v3 10/12] KVM: arm64: nVHE: Support CONFIG_CFI_CLANG at EL2
@ 2024-05-29 12:30  0%       ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:30 UTC (permalink / raw)
  To: Will Deacon
  Cc: kvmarm, linux-arm-kernel, kvm, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Hi Will,

On Mon, May 13, 2024 at 06:30:05PM +0100, Will Deacon wrote:
> On Fri, May 10, 2024 at 12:26:39PM +0100, Pierre-Clément Tosi wrote:
> > [...]
> > 
> > Use SYM_TYPED_FUNC_START() for __pkvm_init_switch_pgd, as nVHE can't
> > call it directly and must use a PA function pointer from C (because it
> > is part of the idmap page), which would trigger a kCFI failure if the
> > type ID wasn't present.
> > 
> > Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
> > ---
> >  arch/arm64/include/asm/esr.h       |  6 ++++++
> >  arch/arm64/kvm/handle_exit.c       | 11 +++++++++++
> >  arch/arm64/kvm/hyp/nvhe/Makefile   |  6 +++---
> >  arch/arm64/kvm/hyp/nvhe/hyp-init.S |  6 +++++-
> >  4 files changed, 25 insertions(+), 4 deletions(-)
> > 
> >  [...]
> > 
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> > index 5a15737b4233..33fb5732ab83 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
> > @@ -5,6 +5,7 @@
> >   */
> >  
> >  #include <linux/arm-smccc.h>
> > +#include <linux/cfi_types.h>
> >  #include <linux/linkage.h>
> >  
> >  #include <asm/alternative.h>
> > @@ -268,8 +269,11 @@ SYM_CODE_END(__kvm_handle_stub_hvc)
> >  /*
> >   * void __pkvm_init_switch_pgd(struct kvm_nvhe_init_params *params,
> >   *                             void (*finalize_fn)(void));
> > + *
> > + * SYM_TYPED_FUNC_START() allows C to call this ID-mapped function indirectly
> > + * using a physical pointer without triggering a kCFI failure.
> >   */
> > -SYM_FUNC_START(__pkvm_init_switch_pgd)
> > +SYM_TYPED_FUNC_START(__pkvm_init_switch_pgd)
> >  	/* Load the inputs from the VA pointer before turning the MMU off */
> >  	ldr	x5, [x0, #NVHE_INIT_PGD_PA]
> >  	ldr	x0, [x0, #NVHE_INIT_STACK_HYP_VA]
> 
> Unrelated hunk?

No, this is needed to prevent a kCFI failure at EL2.

Please let me know if the comment and commit message aren't clear enough.

> 
> Will

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v2 resend 2/8] hwtracing: use for_each_endpoint_of_node()
@ 2024-05-29 12:30  3%       ` James Clark
  0 siblings, 0 replies; 200+ results
From: James Clark @ 2024-05-29 12:30 UTC (permalink / raw)
  To: Laurent Pinchart, Kuninori Morimoto, coresight
  Cc: Alexandre Belloni, Alexander Shishkin, Tomi Valkeinen,
	linux-fbdev, dri-devel, prabhakar.csengg, Krzysztof Kozlowski,
	David Airlie, Helge Deller, linux-staging, linux-media,
	Daniel Vetter, Suzuki K Poulose, Maarten Lankhorst,
	Eugen Hristev, Rob Herring, Maxime Ripard, Mauro Carvalho Chehab,
	Michal Simek, linux-arm-kernel, Greg Kroah-Hartman,
	Claudiu Beznea, Thomas Zimmermann



On 29/05/2024 01:40, Laurent Pinchart wrote:
> Hi Morimoto-san,
> 
> Thank you for the patch.
> 
> On Tue, May 28, 2024 at 11:55:32PM +0000, Kuninori Morimoto wrote:
>> We already have for_each_endpoint_of_node(), don't use
>> of_graph_get_next_endpoint() directly. Replace it.
>>
>> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> ---
>>  drivers/hwtracing/coresight/coresight-platform.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-platform.c b/drivers/hwtracing/coresight/coresight-platform.c
>> index 9d550f5697fa8..e9683e613d520 100644
>> --- a/drivers/hwtracing/coresight/coresight-platform.c
>> +++ b/drivers/hwtracing/coresight/coresight-platform.c
>> @@ -275,7 +275,7 @@ static int of_get_coresight_platform_data(struct device *dev,
>>  	 */
>>  	if (!parent) {
>>  		/*
>> -		 * Avoid warnings in of_graph_get_next_endpoint()
>> +		 * Avoid warnings in for_each_endpoint_of_node()
>>  		 * if the device doesn't have any graph connections
>>  		 */
>>  		if (!of_graph_is_present(node))
>> @@ -286,7 +286,7 @@ static int of_get_coresight_platform_data(struct device *dev,
>>  	}
>>  
>>  	/* Iterate through each output port to discover topology */
>> -	while ((ep = of_graph_get_next_endpoint(parent, ep))) {
>> +	for_each_endpoint_of_node(parent, ep) {
>>  		/*
>>  		 * Legacy binding mixes input/output ports under the
>>  		 * same parent. So, skip the input ports if we are dealing
> 
> I think there's a bug below. The loop contains
> 
> 		ret = of_coresight_parse_endpoint(dev, ep, pdata);
> 		if (ret)
> 			return ret;
> 
> which leaks the reference to ep. This is not introduced by this patch,
> so
> 

Nice catch, I will send a patch.

Also:

Reviewed-by: James Clark <james.clark@arm.com>

> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 

^ permalink raw reply	[relevance 3%]

* Re: [PATCH v3 3/6] iio: adc: ad7173: refactor ain and vref selection
  @ 2024-05-29 12:27  0%   ` Nuno Sá
  2024-05-29 12:49  1%     ` Nuno Sá
  0 siblings, 1 reply; 200+ results
From: Nuno Sá @ 2024-05-29 12:27 UTC (permalink / raw)
  To: dumitru.ceclan
  Cc: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, David Lechner,
	linux-iio, devicetree, linux-kernel, Dumitru Ceclan

On Mon, 2024-05-27 at 20:02 +0300, Dumitru Ceclan via B4 Relay wrote:
> From: Dumitru Ceclan <dumitru.ceclan@analog.com>
> 
> Move validation of analog inputs and reference voltage selection to
> separate functions to reduce the size of the channel config parsing
> function and improve readability.
> 
> Reviewed-by: David Lechner <dlechner@baylibre.com>
> Signed-off-by: Dumitru Ceclan <dumitru.ceclan@analog.com>
> ---
>  drivers/iio/adc/ad7173.c | 62 ++++++++++++++++++++++++++++++++++--------------
>  1 file changed, 44 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/iio/adc/ad7173.c b/drivers/iio/adc/ad7173.c
> index 9e507e2c66f0..8a53821c8e58 100644
> --- a/drivers/iio/adc/ad7173.c
> +++ b/drivers/iio/adc/ad7173.c
> @@ -906,6 +906,44 @@ static int ad7173_register_clk_provider(struct iio_dev
> *indio_dev)
>  					   &st->int_clk_hw);
>  }
>  
> +static int ad7173_validate_voltage_ain_inputs(struct ad7173_state *st,
> +					      unsigned int ain[2])
> +{
> +	struct device *dev = &st->sd.spi->dev;
> +
> +	for (int i = 0; i < 2; i++) {
> +		if (ain[i] < st->info->num_inputs)
> +			continue;
> +
> +		return dev_err_probe(dev, -EINVAL,
> +			"Input pin number out of range for pair (%d %d).\n",
> +			ain[0], ain[1]);
> +	}
> +
> +	return 0;
> +}
> +
> +static int ad7173_validate_reference(struct ad7173_state *st, int ref_sel)
> +{
> +	struct device *dev = &st->sd.spi->dev;
> +	int ret;
> +
> +	if (ref_sel == AD7173_SETUP_REF_SEL_INT_REF && !st->info->has_int_ref)
> +		return dev_err_probe(dev, -EINVAL,
> +			"Internal reference is not available on current
> model.\n");
> +
> +	if (ref_sel == AD7173_SETUP_REF_SEL_EXT_REF2 && !st->info->has_ref2)
> +		return dev_err_probe(dev, -EINVAL,
> +			"External reference 2 is not available on current
> model.\n");
> +
> +	ret = ad7173_get_ref_voltage_milli(st, ref_sel);
> +	if (ret < 0)
> +		return dev_err_probe(dev, ret, "Cannot use reference %u\n",
> +				     ref_sel);
> +
> +	return 0;

If you need a v4, I would just 'return ad7173_get_ref_voltage_milli(...)'. Any error
log needed should be done inside ad7173_get_ref_voltage_milli(). Anyways:

Reviewed-by: Nuno Sa <nuno.sa@analog.com>

- Nuno Sá



^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3 09/12] KVM: arm64: VHE: Add test module for hyp kCFI
  @ 2024-05-29 12:26  0%       ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:26 UTC (permalink / raw)
  To: Will Deacon
  Cc: kvmarm, linux-arm-kernel, kvm, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Hi Will,

Thanks for the review!

I've addressed all your comments in v4, except for the one below.

On Mon, May 13, 2024 at 06:21:21PM +0100, Will Deacon wrote:
> On Fri, May 10, 2024 at 12:26:38PM +0100, Pierre-Clément Tosi wrote:
> > In order to easily periodically (and potentially automatically) validate
> > that the hypervisor kCFI feature doesn't bitrot, introduce a way to
> > trigger hypervisor kCFI faults from userspace on test builds of KVM.
> > 
> > Add hooks in the hypervisor code to call registered callbacks (intended
> > to trigger kCFI faults either for the callback call itself of from
> > within the callback function) when running with guest or host VBAR_EL2.
> > As the calls are issued from the KVM_RUN ioctl handling path, userspace
> > gains control over when the actual triggering of the fault happens
> > without needing to modify the KVM uAPI.
> > 
> > Export kernel functions to register these callbacks from modules and
> > introduce a kernel module intended to contain any testing logic. By
> > limiting the changes to the core kernel to a strict minimum, this
> > architectural split allows tests to be updated (within the module)
> > without the need to redeploy (or recompile) the kernel (hyp) under test.
> > 
> > Use the module parameters as the uAPI for configuring the fault
> > condition being tested (i.e. either at insertion or post-insertion
> > using /sys/module/.../parameters), which naturally makes it impossible
> > for userspace to test kCFI without the module (and, inversely, makes
> > the module only - not KVM - responsible for exposing said uAPI).
> > 
> > As kCFI is implemented with a caller-side check of a callee-side value,
> > make the module support 4 tests based on the location of the caller and
> > callee (built-in or in-module), for each of the 2 hypervisor contexts
> > (host & guest), selected by userspace using the 'guest' or 'host' module
> > parameter. For this purpose, export symbols which the module can use to
> > configure the callbacks for in-kernel and module-to-built-in kCFI
> > faulting calls.
> > 
> > Define the module-to-kernel API to allow the module to detect that it
> > was loaded on a kernel built with support for it but which is running
> > without a hypervisor (-ENXIO) or with one that doesn't use the VHE CPU
> > feature (-EOPNOTSUPP), which is currently the only mode for which KVM
> > supports hypervisor kCFI.
> > 
> > Allow kernel build configs to set CONFIG_HYP_CFI_TEST to only support
> > the in-kernel hooks (=y) or also build the test module (=m). Use
> > intermediate internal Kconfig flags (CONFIG_HYP_SUPPORTS_CFI_TEST and
> > CONFIG_HYP_CFI_TEST_MODULE) to simplify the Makefiles and #ifdefs. As
> > the symbols for callback registration are only exported to modules when
> > CONFIG_HYP_CFI_TEST != n, it is impossible for the test module to be
> > non-forcefully inserted on a kernel that doesn't support it.
> > 
> > Note that this feature must NOT result in any noticeable change
> > (behavioral or binary size) when HYP_CFI_TEST_MODULE = n.
> > 
> > CONFIG_HYP_CFI_TEST is intentionally independent of CONFIG_CFI_CLANG, to
> > avoid arbitrarily limiting the number of flag combinations that can be
> > tested with the module.
> > 
> > Also note that, as VHE aliases VBAR_EL1 to VBAR_EL2 for the host,
> > testing hypervisor kCFI in VHE and in host context is equivalent to
> > testing kCFI support of the kernel itself i.e. EL1 in non-VHE and/or in
> > non-virtualized environments. For this reason, CONFIG_CFI_PERMISSIVE
> > **will** prevent the test module from triggering a hyp panic (although a
> > warning still gets printed) in that context.
> > 
> > Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
> > ---
> >  arch/arm64/include/asm/kvm_cfi.h     |  36 ++++++++
> >  arch/arm64/kvm/Kconfig               |  22 +++++
> >  arch/arm64/kvm/Makefile              |   3 +
> >  arch/arm64/kvm/hyp/include/hyp/cfi.h |  47 ++++++++++
> >  arch/arm64/kvm/hyp/vhe/Makefile      |   1 +
> >  arch/arm64/kvm/hyp/vhe/cfi.c         |  37 ++++++++
> >  arch/arm64/kvm/hyp/vhe/switch.c      |   7 ++
> >  arch/arm64/kvm/hyp_cfi_test.c        |  43 +++++++++
> >  arch/arm64/kvm/hyp_cfi_test_module.c | 133 +++++++++++++++++++++++++++
> >  9 files changed, 329 insertions(+)
> >  create mode 100644 arch/arm64/include/asm/kvm_cfi.h
> >  create mode 100644 arch/arm64/kvm/hyp/include/hyp/cfi.h
> >  create mode 100644 arch/arm64/kvm/hyp/vhe/cfi.c
> >  create mode 100644 arch/arm64/kvm/hyp_cfi_test.c
> >  create mode 100644 arch/arm64/kvm/hyp_cfi_test_module.c
> > 
> > diff --git a/arch/arm64/include/asm/kvm_cfi.h b/arch/arm64/include/asm/kvm_cfi.h
> > new file mode 100644
> > index 000000000000..13cc7b19d838
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/kvm_cfi.h
> > @@ -0,0 +1,36 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Copyright (C) 2024 - Google Inc
> > + * Author: Pierre-Clément Tosi <ptosi@google.com>
> > + */
> > +
> > +#ifndef __ARM64_KVM_CFI_H__
> > +#define __ARM64_KVM_CFI_H__
> > +
> > +#include <asm/kvm_asm.h>
> > +#include <linux/errno.h>
> > +
> > +#ifdef CONFIG_HYP_SUPPORTS_CFI_TEST
> > +
> > +int kvm_cfi_test_register_host_ctxt_cb(void (*cb)(void));
> > +int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void));
> 
> Hmm, I tend to think this indirection is a little over the top for a test
> module that only registers a small handful of handlers:
> 
> > +static int set_param_mode(const char *val, const struct kernel_param *kp,
> > +			 int (*register_cb)(void (*)(void)))
> > +{
> > +	unsigned int *mode = kp->arg;
> > +	int err;
> > +
> > +	err = param_set_uint(val, kp);
> > +	if (err)
> > +		return err;
> > +
> > +	switch (*mode) {
> > +	case 0:
> > +		return register_cb(NULL);
> > +	case 1:
> > +		return register_cb(hyp_trigger_builtin_cfi_fault);
> > +	case 2:
> > +		return register_cb((void *)hyp_cfi_builtin2module_test_target);
> > +	case 3:
> > +		return register_cb(trigger_module2builtin_cfi_fault);
> > +	case 4:
> > +		return register_cb(trigger_module2module_cfi_fault);
> > +	default:
> > +		return -EINVAL;
> > +	}
> > +}
> 
> Why not just have a hyp selftest that runs through all of this behind a
> static key? I think it would simplify the code quite a bit, and you could
> move the registration and indirection logic.

I agree that the code would be simpler but note that the resulting tests would
have a more limited coverage compared to what this currently implements. In
particular, they would likely miss issues with the failure path itself (e.g.
[1]) as the synchronous exception would need to be "handled" to let the selftest
complete. OTOH, that would have the benefit of not triggering a kernel panic,
making the test easier to integrate into existing CI suites.

However, as the original request for those tests [2] was specifically about
testing the failure path, I've held off from modifying the test module (in v4)
until I get confirmation that Marc would be happy with your suggestion.

[1]: https://lore.kernel.org/kvmarm/20240529121251.1993135-2-ptosi@google.com/
[2]: https://lore.kernel.org/kvmarm/867ci10zv6.wl-maz@kernel.org/

Thanks,

Pierre

> 
> Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3 09/12] KVM: arm64: VHE: Add test module for hyp kCFI
@ 2024-05-29 12:26  0%       ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:26 UTC (permalink / raw)
  To: Will Deacon
  Cc: kvmarm, linux-arm-kernel, kvm, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Hi Will,

Thanks for the review!

I've addressed all your comments in v4, except for the one below.

On Mon, May 13, 2024 at 06:21:21PM +0100, Will Deacon wrote:
> On Fri, May 10, 2024 at 12:26:38PM +0100, Pierre-Clément Tosi wrote:
> > In order to easily periodically (and potentially automatically) validate
> > that the hypervisor kCFI feature doesn't bitrot, introduce a way to
> > trigger hypervisor kCFI faults from userspace on test builds of KVM.
> > 
> > Add hooks in the hypervisor code to call registered callbacks (intended
> > to trigger kCFI faults either for the callback call itself of from
> > within the callback function) when running with guest or host VBAR_EL2.
> > As the calls are issued from the KVM_RUN ioctl handling path, userspace
> > gains control over when the actual triggering of the fault happens
> > without needing to modify the KVM uAPI.
> > 
> > Export kernel functions to register these callbacks from modules and
> > introduce a kernel module intended to contain any testing logic. By
> > limiting the changes to the core kernel to a strict minimum, this
> > architectural split allows tests to be updated (within the module)
> > without the need to redeploy (or recompile) the kernel (hyp) under test.
> > 
> > Use the module parameters as the uAPI for configuring the fault
> > condition being tested (i.e. either at insertion or post-insertion
> > using /sys/module/.../parameters), which naturally makes it impossible
> > for userspace to test kCFI without the module (and, inversely, makes
> > the module only - not KVM - responsible for exposing said uAPI).
> > 
> > As kCFI is implemented with a caller-side check of a callee-side value,
> > make the module support 4 tests based on the location of the caller and
> > callee (built-in or in-module), for each of the 2 hypervisor contexts
> > (host & guest), selected by userspace using the 'guest' or 'host' module
> > parameter. For this purpose, export symbols which the module can use to
> > configure the callbacks for in-kernel and module-to-built-in kCFI
> > faulting calls.
> > 
> > Define the module-to-kernel API to allow the module to detect that it
> > was loaded on a kernel built with support for it but which is running
> > without a hypervisor (-ENXIO) or with one that doesn't use the VHE CPU
> > feature (-EOPNOTSUPP), which is currently the only mode for which KVM
> > supports hypervisor kCFI.
> > 
> > Allow kernel build configs to set CONFIG_HYP_CFI_TEST to only support
> > the in-kernel hooks (=y) or also build the test module (=m). Use
> > intermediate internal Kconfig flags (CONFIG_HYP_SUPPORTS_CFI_TEST and
> > CONFIG_HYP_CFI_TEST_MODULE) to simplify the Makefiles and #ifdefs. As
> > the symbols for callback registration are only exported to modules when
> > CONFIG_HYP_CFI_TEST != n, it is impossible for the test module to be
> > non-forcefully inserted on a kernel that doesn't support it.
> > 
> > Note that this feature must NOT result in any noticeable change
> > (behavioral or binary size) when HYP_CFI_TEST_MODULE = n.
> > 
> > CONFIG_HYP_CFI_TEST is intentionally independent of CONFIG_CFI_CLANG, to
> > avoid arbitrarily limiting the number of flag combinations that can be
> > tested with the module.
> > 
> > Also note that, as VHE aliases VBAR_EL1 to VBAR_EL2 for the host,
> > testing hypervisor kCFI in VHE and in host context is equivalent to
> > testing kCFI support of the kernel itself i.e. EL1 in non-VHE and/or in
> > non-virtualized environments. For this reason, CONFIG_CFI_PERMISSIVE
> > **will** prevent the test module from triggering a hyp panic (although a
> > warning still gets printed) in that context.
> > 
> > Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
> > ---
> >  arch/arm64/include/asm/kvm_cfi.h     |  36 ++++++++
> >  arch/arm64/kvm/Kconfig               |  22 +++++
> >  arch/arm64/kvm/Makefile              |   3 +
> >  arch/arm64/kvm/hyp/include/hyp/cfi.h |  47 ++++++++++
> >  arch/arm64/kvm/hyp/vhe/Makefile      |   1 +
> >  arch/arm64/kvm/hyp/vhe/cfi.c         |  37 ++++++++
> >  arch/arm64/kvm/hyp/vhe/switch.c      |   7 ++
> >  arch/arm64/kvm/hyp_cfi_test.c        |  43 +++++++++
> >  arch/arm64/kvm/hyp_cfi_test_module.c | 133 +++++++++++++++++++++++++++
> >  9 files changed, 329 insertions(+)
> >  create mode 100644 arch/arm64/include/asm/kvm_cfi.h
> >  create mode 100644 arch/arm64/kvm/hyp/include/hyp/cfi.h
> >  create mode 100644 arch/arm64/kvm/hyp/vhe/cfi.c
> >  create mode 100644 arch/arm64/kvm/hyp_cfi_test.c
> >  create mode 100644 arch/arm64/kvm/hyp_cfi_test_module.c
> > 
> > diff --git a/arch/arm64/include/asm/kvm_cfi.h b/arch/arm64/include/asm/kvm_cfi.h
> > new file mode 100644
> > index 000000000000..13cc7b19d838
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/kvm_cfi.h
> > @@ -0,0 +1,36 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +/*
> > + * Copyright (C) 2024 - Google Inc
> > + * Author: Pierre-Clément Tosi <ptosi@google.com>
> > + */
> > +
> > +#ifndef __ARM64_KVM_CFI_H__
> > +#define __ARM64_KVM_CFI_H__
> > +
> > +#include <asm/kvm_asm.h>
> > +#include <linux/errno.h>
> > +
> > +#ifdef CONFIG_HYP_SUPPORTS_CFI_TEST
> > +
> > +int kvm_cfi_test_register_host_ctxt_cb(void (*cb)(void));
> > +int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void));
> 
> Hmm, I tend to think this indirection is a little over the top for a test
> module that only registers a small handful of handlers:
> 
> > +static int set_param_mode(const char *val, const struct kernel_param *kp,
> > +			 int (*register_cb)(void (*)(void)))
> > +{
> > +	unsigned int *mode = kp->arg;
> > +	int err;
> > +
> > +	err = param_set_uint(val, kp);
> > +	if (err)
> > +		return err;
> > +
> > +	switch (*mode) {
> > +	case 0:
> > +		return register_cb(NULL);
> > +	case 1:
> > +		return register_cb(hyp_trigger_builtin_cfi_fault);
> > +	case 2:
> > +		return register_cb((void *)hyp_cfi_builtin2module_test_target);
> > +	case 3:
> > +		return register_cb(trigger_module2builtin_cfi_fault);
> > +	case 4:
> > +		return register_cb(trigger_module2module_cfi_fault);
> > +	default:
> > +		return -EINVAL;
> > +	}
> > +}
> 
> Why not just have a hyp selftest that runs through all of this behind a
> static key? I think it would simplify the code quite a bit, and you could
> move the registration and indirection logic.

I agree that the code would be simpler but note that the resulting tests would
have a more limited coverage compared to what this currently implements. In
particular, they would likely miss issues with the failure path itself (e.g.
[1]) as the synchronous exception would need to be "handled" to let the selftest
complete. OTOH, that would have the benefit of not triggering a kernel panic,
making the test easier to integrate into existing CI suites.

However, as the original request for those tests [2] was specifically about
testing the failure path, I've held off from modifying the test module (in v4)
until I get confirmation that Marc would be happy with your suggestion.

[1]: https://lore.kernel.org/kvmarm/20240529121251.1993135-2-ptosi@google.com/
[2]: https://lore.kernel.org/kvmarm/867ci10zv6.wl-maz@kernel.org/

Thanks,

Pierre

> 
> Will

^ permalink raw reply	[relevance 0%]

* Re: [PATCH 4/8] gpio: tqmx86: introduce _tqmx86_gpio_update_bits() helper
  2024-05-29 12:19  1%   ` Andrew Lunn
@ 2024-05-29 12:25  0%     ` Matthias Schiffer
  0 siblings, 0 replies; 200+ results
From: Matthias Schiffer @ 2024-05-29 12:25 UTC (permalink / raw)
  To: Andrew Lunn
  Cc: Linus Walleij, Bartosz Golaszewski, linux-gpio, linux-kernel,
	Gregor Herburger, linux

On Wed, 2024-05-29 at 14:19 +0200, Andrew Lunn wrote:
> 
> On Wed, May 29, 2024 at 09:45:16AM +0200, Matthias Schiffer wrote:
> > Simplify a lot of code in the driver by introducing helpers for the
> > common RMW pattern. No tqmx86_gpio_update_bits() function with builtin
> > locking is added, as it would become redundant with the following fixes,
> > which further consolidate interrupt configuration register setup.
> > 
> > No functional change intended.
> > 
> > Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")
> > Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> > ---
> >  drivers/gpio/gpio-tqmx86.c | 40 ++++++++++++++++++++++----------------
> >  1 file changed, 23 insertions(+), 17 deletions(-)
> > 
> > diff --git a/drivers/gpio/gpio-tqmx86.c b/drivers/gpio/gpio-tqmx86.c
> > index 613ab9ef2e744..7a851e1730dd1 100644
> > --- a/drivers/gpio/gpio-tqmx86.c
> > +++ b/drivers/gpio/gpio-tqmx86.c
> > @@ -54,6 +54,17 @@ static void tqmx86_gpio_write(struct tqmx86_gpio_data *gd, unsigned int reg,
> >  	iowrite8(val, gd->io_base + reg);
> >  }
> >  
> > +static void _tqmx86_gpio_update_bits(struct tqmx86_gpio_data *gd,
> > +				     unsigned int reg, u8 mask, u8 val)
> 
> Why the _ prefix? This is a local function, it is static, so you don't
> have name space issues. Functions starting with _ are those you should
> not call without a good reason, there is generally a version without
> the _ prefix which is the real function to use. So i would drop the _.

My intention was to mark functions that need to be called while holding the spinlock with a _
prefix. Should I just remove the prefix and add a comment instead?

Matthias


> 
> This is also not a fix. Please read:
> 
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
> 
> and stick to the rules described there.
> 
> I don't know how the GPIO tree works, but for netdev, about a week
> after fixes are merged, they appear in net-next. So you can then build
> on top of them for development work.
> 
> 	Andrew

-- 
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
https://www.tq-group.com/

^ permalink raw reply	[relevance 0%]

* Re: [PATCH 3/8] gpio: tqmx86: change tqmx86_gpio_write() order of arguments to match regmap API
  2024-05-29 12:11  0%     ` Andrew Lunn
@ 2024-05-29 12:23  0%       ` Matthias Schiffer
  0 siblings, 0 replies; 200+ results
From: Matthias Schiffer @ 2024-05-29 12:23 UTC (permalink / raw)
  To: Andrew Lunn, Bartosz Golaszewski
  Cc: Linus Walleij, linux-gpio, linux-kernel, Gregor Herburger, linux

On Wed, 2024-05-29 at 14:11 +0200, Andrew Lunn wrote:
> 
> On Wed, May 29, 2024 at 02:03:35PM +0200, Bartosz Golaszewski wrote:
> > On Wed, May 29, 2024 at 9:46 AM Matthias Schiffer
> > <matthias.schiffer@ew.tq-group.com> wrote:
> > > 
> > > Conversion to actually use regmap does not seem useful for this driver,
> > > as regmap can't properly represent separate read-only and write-only
> > > registers at the same address, but we can at least match the API to make
> > > the code clearer.
> > > 
> > > No functional change intended.
> > > 
> > > Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")
> > 
> > This is not a fix.
> 
> Agreed.
> 
> I'm somewhat conflicted by this patch. It is a step towards using
> regmap, but then says regmap does not make sense. So why make that
> step?
> 
> Changing the order of parameters like this seems like it is will make
> back porting bug fixes harder, unless all supported versions are
> changed, which is why fixes make sense. Does the compiler at least
> issue a warning if the parameters are used the wrong way around?
> 
> Overall, i'm leaning towards just dropping it.
> 
> 	 Andrew



Okay, will drop this patch.

Matthias

^ permalink raw reply	[relevance 0%]

* Re: [RFC PATCH] arm64: dts: rockchip: Make preparations for per-RK3588-variant OPPs
  2024-05-29 12:04  1%       ` Alexey Charkov
  (?)
@ 2024-05-29 12:22  1%         ` Dragan Simic
  -1 siblings, 0 replies; 200+ results
From: Dragan Simic @ 2024-05-29 12:22 UTC (permalink / raw)
  To: Alexey Charkov
  Cc: linux-rockchip, heiko, linux-arm-kernel, devicetree, robh+dt,
	krzk+dt, conor+dt, linux-kernel, quentin.schulz, wens,
	daniel.lezcano, didi.debian, krzysztof.kozlowski+dt,
	viresh.kumar

On 2024-05-29 14:04, Alexey Charkov wrote:
> On Wed, May 29, 2024 at 2:45 PM Dragan Simic <dsimic@manjaro.org> 
> wrote:
>> On 2024-05-29 11:57, Alexey Charkov wrote:
>> > On Wed, May 29, 2024 at 6:14 AM Dragan Simic <dsimic@manjaro.org>
>> > wrote:
>> >>
>> >> Rename and modify the RK3588 dtsi files a bit, to make preparations
>> >> for
>> >> the ability to specify different CPU and GPU OPPs for each of the
>> >> supported
>> >> RK3588 SoC variants, including the RK3588J.
>> >>
>> >> As already discussed, [1][2][3] some of the different RK3588 SoC
>> >> variants
>> >> require different OPPs, and it makes more sense to have the OPPs
>> >> already
>> >> defined when a board dts includes one of the SoC dtsi files
>> >> (rk3588.dtsi,
>> >> rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts
>> >> file to
>> >> also include a separate rk3588*-opp.dtsi file.  The choice of the SoC
>> >> variant
>> >> is already made by the inclusion of the SoC dtsi file, and it doesn't
>> >> make
>> >> much sense to, effectively, allow the board dts file to include and
>> >> use an
>> >> incompatible set of OPPs for the already selected SoC variant.
>> >
>> > Indeed, including just one .dtsi for the correct SoC variant and not
>> > having to bother about what other bits and pieces are required to use
>> > the full SoC functionality sounds great! Thanks for putting this
>> > together so promptly!
>> 
>> You're welcome. :)
>> 
>> > Some considerations below.
>> >
>> >> No intended functional changes are introduced.  (Still to be
>> >> additionally
>> >> verified if the patch moves forward from the RFC state.)
>> >>
>> >> [1]
>> >> https://lore.kernel.org/linux-rockchip/646a33e0-5c1b-471c-8183-2c0df40ea51a@cherry.de/
>> >> [2]
>> >> https://lore.kernel.org/linux-rockchip/CABjd4Yxi=+3gkNnH3BysUzzYsji-=-yROtzEc8jM_g0roKB0-w@mail.gmail.com/
>> >> [3]
>> >> https://lore.kernel.org/linux-rockchip/035a274be262528012173d463e25b55f@manjaro.org/
>> >>
>> >> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
>> >> ---
>> >>  ...inctrl.dtsi => rk3588-common-pinctrl.dtsi} |    0
>> >
>> > Renaming the pinctrl includes seems superfluous - maybe keep them as
>> > they were to minimize churn?
>> 
>> Believe it or not, the same thoughts crossed my mind.  However,
>> after thinking a bit about it, I concluded that renaming the pinctrl
>> .dtsi files as well makes the overall naming of the reworked RK3588
>> .dtsi files more consistent.
>> 
>> It's also rather neat to have the "common" and "fullfat" file pairs
>> together in the arch/arm64/boot/dts/rockchip directory listing, when
>> it's sorted by the file name, which is the default in most (if not
>> all) environments.
>> 
>> >>  .../{rk3588s.dtsi => rk3588-common.dtsi}      |    2 +-
>> >>  ...nctrl.dtsi => rk3588-fullfat-pinctrl.dtsi} |    0
>> >>  .../{rk3588.dtsi => rk3588-fullfat.dtsi}      |    4 +-
>> >
>> > To me, "fullfat" doesn't look super descriptive, albeit fun :)
>> 
>> Yeah, I resorted to "fullfat" as some kind of a funny option. :)
>> That's for the "beefy" SoC variants, so it kind of fits well. :)
>> 
>> > How about we rename the existing rk3588.dtsi and rk3588s.dtsi to
>> > something like rk3588-devices.dtsi and rk3588s-devices.dtsi
>> > (preserving the inheritance between them), and then I add
>> > rk3588s-opp.dtsi and rk3588j-opp.dtsi in a follow-up patch?
>> 
>> The trouble with including "devices" into the filenames is, well,
>> the fact that those files isn't about any devices, but about the
>> SoC variants.  Thus, "devices" simply wouldn't fit there.
> 
> My thinking was along the lines of "here is the file that contains all
> DT nodes for built-in _devices_ (as in on-chip IP blocks) on RK3588 -
> thus it's called rk3588-devices.dtsi", and "here's the file that
> contains operating parameters that distinguish RK3588 and RK3588s from
> RK3588j - it's called rk3588s-opp.dtsi"

Hmm...  I see, but a device is usually though of as some standalone
computer, at least in this context.  Surely, an SoC is also some kind
of a device, for example, but I'm pretty sure we'll very rarely call
an SoC a device.  It's always good to adhere to the usual meaning of
the words in a particular lingo.

When it comes to rk3588s-opp.dtsi, it would be more of a file that
completes the rk3588s.dtsi by adding the OPPs, but we can in fact
add the OPPs directly into rk3588s.dtsi, because in the new layout
rk3588s.dtsi isn't a parent to any other file.

>> Moreover, in the envisioned scheme there should be no separate
>> OPP .dtsi files;  the OPP data should go directly into the new
>> rk3588.dtsi, rk3588s.dtsi and rk3588j.dtsi files, where it actually
>> belongs.  That's why those .dtsi files exist and are mostly empty,
>> at least the way I see it.  I'll get back to this below.
>> 
>> > Then we keep "thin" versions of rk3588.dtsi, rk3588s.dtsi and
>> > rk3588j.dtsi for board files to include. The mix-and-match of
>> > different on-chip devices and different OPPs then gets transparently
>> > represented within those "thin" .dtsi, something like this:
>> >
>> > rk3588.dtsi:
>> > #include "rk3588-devices.dtsi"
>> > #include "rk3588s-opp.dtsi"
>> >
>> > rk3588s.dtsi:
>> > #include "rk3588s-devices.dtsi"
>> > #include "rk3588s-opp.dtsi"
>> >
>> > rk3588j.dtsi:
>> > #include "rk3588-devices.dtsi"
>> > #include "rk3588j-opp.dtsi"
>> 
>> Such a layout, in general, has also crossed my mind, but my conclusion
>> was that having the per-SoC-variant OPP data specified directly in the
>> reworked rk3588.dtsi, rk3588s.dtsi and rk3588j.dtsi files is a better
>> option in the long term, even if we end up that way with rk3588.dtsi 
>> and
>> rk3588s.dtsi repeating most (if not all) of the same OPP data.
> 
> From all the info we have available so far, RK3588 and RK3588s share
> identical OPPs, so having one file with OPPs that both variants refer
> to should be more maintainable (and fewer lines of DT code).

Hmm.  Perhaps we can have rk3588-opp.dtsi as a separate file with the
OPPs shared between the RK3588 and the RK3588S, which would be included
from rk3588.dtsi and rk3588s.dtsi.

Though, the OPPs for the RK3588J should go directly into rk3588j.dtsi;
if we ever split the OPPs for the RK3588 and the RK3588S, the new OPPs
should also go directly into rk3588.dtsi and rk3588s.dtsi.

> All in all, it appears that RK3588 and RK3588j have an identical set
> of built-in devices, but different OPPs due to RK3588j being spec'd
> for industrial use which apparently has different requirements. At the
> same time, RK3588s uses an identical set of OPPs as RK3588 but a
> reduced set of built-in devices. The combination of includes I
> proposed above makes this explicit.

Again, calling IP blocks devices is, AFAIK, very uncommon.

> As for RK3588m, it seems to include all the same devices as RK3588 and
> RK3588j, but a slightly modified set of OPPs compared to RK3588j. We
> don't have any boards using that variant in the mainline tree right
> now, but it would be easy, when the need arises, to add something
> along the lines of:
> 
> rk3588m.dtsi:
> #include "rk3588-devices.dtsi"
> #include "rk3588m-opp.dtsi"
> 
> rk3588m-opp.dtsi:
> #include "rk3588j-opp.dtsi"
> &cluster0_opp_table {
>         /delete-node/ opp-1296000000;
> };

I don't think that deleting nodes that way is a good option.  It's
rather error-prone and hard to track, so it would be better to have
the OPPs for RK3588M specified directly (and fully) in the future
rk3588m.dtsi file, just like in rk3588j.dtsi.

>> That way we'll have no roadblocks if, at some point, we end up with
>> having
>> different OPPs defined for the RK3588 and the RK3588S variants.  Or
>> maybe
>> even for the RK3582, which we don't know much about yet.
> 
> Guess we'll deal with that one once we stumble upon an actual RK3582
> board out in the wild and heading to the mainline kernel tree :)

Of course, that was just an example for the future use.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

^ permalink raw reply	[relevance 1%]

* Re: [RFC PATCH] arm64: dts: rockchip: Make preparations for per-RK3588-variant OPPs
@ 2024-05-29 12:22  1%         ` Dragan Simic
  0 siblings, 0 replies; 200+ results
From: Dragan Simic @ 2024-05-29 12:22 UTC (permalink / raw)
  To: Alexey Charkov
  Cc: linux-rockchip, heiko, linux-arm-kernel, devicetree, robh+dt,
	krzk+dt, conor+dt, linux-kernel, quentin.schulz, wens,
	daniel.lezcano, didi.debian, krzysztof.kozlowski+dt,
	viresh.kumar

On 2024-05-29 14:04, Alexey Charkov wrote:
> On Wed, May 29, 2024 at 2:45 PM Dragan Simic <dsimic@manjaro.org> 
> wrote:
>> On 2024-05-29 11:57, Alexey Charkov wrote:
>> > On Wed, May 29, 2024 at 6:14 AM Dragan Simic <dsimic@manjaro.org>
>> > wrote:
>> >>
>> >> Rename and modify the RK3588 dtsi files a bit, to make preparations
>> >> for
>> >> the ability to specify different CPU and GPU OPPs for each of the
>> >> supported
>> >> RK3588 SoC variants, including the RK3588J.
>> >>
>> >> As already discussed, [1][2][3] some of the different RK3588 SoC
>> >> variants
>> >> require different OPPs, and it makes more sense to have the OPPs
>> >> already
>> >> defined when a board dts includes one of the SoC dtsi files
>> >> (rk3588.dtsi,
>> >> rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts
>> >> file to
>> >> also include a separate rk3588*-opp.dtsi file.  The choice of the SoC
>> >> variant
>> >> is already made by the inclusion of the SoC dtsi file, and it doesn't
>> >> make
>> >> much sense to, effectively, allow the board dts file to include and
>> >> use an
>> >> incompatible set of OPPs for the already selected SoC variant.
>> >
>> > Indeed, including just one .dtsi for the correct SoC variant and not
>> > having to bother about what other bits and pieces are required to use
>> > the full SoC functionality sounds great! Thanks for putting this
>> > together so promptly!
>> 
>> You're welcome. :)
>> 
>> > Some considerations below.
>> >
>> >> No intended functional changes are introduced.  (Still to be
>> >> additionally
>> >> verified if the patch moves forward from the RFC state.)
>> >>
>> >> [1]
>> >> https://lore.kernel.org/linux-rockchip/646a33e0-5c1b-471c-8183-2c0df40ea51a@cherry.de/
>> >> [2]
>> >> https://lore.kernel.org/linux-rockchip/CABjd4Yxi=+3gkNnH3BysUzzYsji-=-yROtzEc8jM_g0roKB0-w@mail.gmail.com/
>> >> [3]
>> >> https://lore.kernel.org/linux-rockchip/035a274be262528012173d463e25b55f@manjaro.org/
>> >>
>> >> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
>> >> ---
>> >>  ...inctrl.dtsi => rk3588-common-pinctrl.dtsi} |    0
>> >
>> > Renaming the pinctrl includes seems superfluous - maybe keep them as
>> > they were to minimize churn?
>> 
>> Believe it or not, the same thoughts crossed my mind.  However,
>> after thinking a bit about it, I concluded that renaming the pinctrl
>> .dtsi files as well makes the overall naming of the reworked RK3588
>> .dtsi files more consistent.
>> 
>> It's also rather neat to have the "common" and "fullfat" file pairs
>> together in the arch/arm64/boot/dts/rockchip directory listing, when
>> it's sorted by the file name, which is the default in most (if not
>> all) environments.
>> 
>> >>  .../{rk3588s.dtsi => rk3588-common.dtsi}      |    2 +-
>> >>  ...nctrl.dtsi => rk3588-fullfat-pinctrl.dtsi} |    0
>> >>  .../{rk3588.dtsi => rk3588-fullfat.dtsi}      |    4 +-
>> >
>> > To me, "fullfat" doesn't look super descriptive, albeit fun :)
>> 
>> Yeah, I resorted to "fullfat" as some kind of a funny option. :)
>> That's for the "beefy" SoC variants, so it kind of fits well. :)
>> 
>> > How about we rename the existing rk3588.dtsi and rk3588s.dtsi to
>> > something like rk3588-devices.dtsi and rk3588s-devices.dtsi
>> > (preserving the inheritance between them), and then I add
>> > rk3588s-opp.dtsi and rk3588j-opp.dtsi in a follow-up patch?
>> 
>> The trouble with including "devices" into the filenames is, well,
>> the fact that those files isn't about any devices, but about the
>> SoC variants.  Thus, "devices" simply wouldn't fit there.
> 
> My thinking was along the lines of "here is the file that contains all
> DT nodes for built-in _devices_ (as in on-chip IP blocks) on RK3588 -
> thus it's called rk3588-devices.dtsi", and "here's the file that
> contains operating parameters that distinguish RK3588 and RK3588s from
> RK3588j - it's called rk3588s-opp.dtsi"

Hmm...  I see, but a device is usually though of as some standalone
computer, at least in this context.  Surely, an SoC is also some kind
of a device, for example, but I'm pretty sure we'll very rarely call
an SoC a device.  It's always good to adhere to the usual meaning of
the words in a particular lingo.

When it comes to rk3588s-opp.dtsi, it would be more of a file that
completes the rk3588s.dtsi by adding the OPPs, but we can in fact
add the OPPs directly into rk3588s.dtsi, because in the new layout
rk3588s.dtsi isn't a parent to any other file.

>> Moreover, in the envisioned scheme there should be no separate
>> OPP .dtsi files;  the OPP data should go directly into the new
>> rk3588.dtsi, rk3588s.dtsi and rk3588j.dtsi files, where it actually
>> belongs.  That's why those .dtsi files exist and are mostly empty,
>> at least the way I see it.  I'll get back to this below.
>> 
>> > Then we keep "thin" versions of rk3588.dtsi, rk3588s.dtsi and
>> > rk3588j.dtsi for board files to include. The mix-and-match of
>> > different on-chip devices and different OPPs then gets transparently
>> > represented within those "thin" .dtsi, something like this:
>> >
>> > rk3588.dtsi:
>> > #include "rk3588-devices.dtsi"
>> > #include "rk3588s-opp.dtsi"
>> >
>> > rk3588s.dtsi:
>> > #include "rk3588s-devices.dtsi"
>> > #include "rk3588s-opp.dtsi"
>> >
>> > rk3588j.dtsi:
>> > #include "rk3588-devices.dtsi"
>> > #include "rk3588j-opp.dtsi"
>> 
>> Such a layout, in general, has also crossed my mind, but my conclusion
>> was that having the per-SoC-variant OPP data specified directly in the
>> reworked rk3588.dtsi, rk3588s.dtsi and rk3588j.dtsi files is a better
>> option in the long term, even if we end up that way with rk3588.dtsi 
>> and
>> rk3588s.dtsi repeating most (if not all) of the same OPP data.
> 
> From all the info we have available so far, RK3588 and RK3588s share
> identical OPPs, so having one file with OPPs that both variants refer
> to should be more maintainable (and fewer lines of DT code).

Hmm.  Perhaps we can have rk3588-opp.dtsi as a separate file with the
OPPs shared between the RK3588 and the RK3588S, which would be included
from rk3588.dtsi and rk3588s.dtsi.

Though, the OPPs for the RK3588J should go directly into rk3588j.dtsi;
if we ever split the OPPs for the RK3588 and the RK3588S, the new OPPs
should also go directly into rk3588.dtsi and rk3588s.dtsi.

> All in all, it appears that RK3588 and RK3588j have an identical set
> of built-in devices, but different OPPs due to RK3588j being spec'd
> for industrial use which apparently has different requirements. At the
> same time, RK3588s uses an identical set of OPPs as RK3588 but a
> reduced set of built-in devices. The combination of includes I
> proposed above makes this explicit.

Again, calling IP blocks devices is, AFAIK, very uncommon.

> As for RK3588m, it seems to include all the same devices as RK3588 and
> RK3588j, but a slightly modified set of OPPs compared to RK3588j. We
> don't have any boards using that variant in the mainline tree right
> now, but it would be easy, when the need arises, to add something
> along the lines of:
> 
> rk3588m.dtsi:
> #include "rk3588-devices.dtsi"
> #include "rk3588m-opp.dtsi"
> 
> rk3588m-opp.dtsi:
> #include "rk3588j-opp.dtsi"
> &cluster0_opp_table {
>         /delete-node/ opp-1296000000;
> };

I don't think that deleting nodes that way is a good option.  It's
rather error-prone and hard to track, so it would be better to have
the OPPs for RK3588M specified directly (and fully) in the future
rk3588m.dtsi file, just like in rk3588j.dtsi.

>> That way we'll have no roadblocks if, at some point, we end up with
>> having
>> different OPPs defined for the RK3588 and the RK3588S variants.  Or
>> maybe
>> even for the RK3582, which we don't know much about yet.
> 
> Guess we'll deal with that one once we stumble upon an actual RK3582
> board out in the wild and heading to the mainline kernel tree :)

Of course, that was just an example for the future use.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 1%]

* Re: [RFC PATCH] arm64: dts: rockchip: Make preparations for per-RK3588-variant OPPs
@ 2024-05-29 12:22  1%         ` Dragan Simic
  0 siblings, 0 replies; 200+ results
From: Dragan Simic @ 2024-05-29 12:22 UTC (permalink / raw)
  To: Alexey Charkov
  Cc: linux-rockchip, heiko, linux-arm-kernel, devicetree, robh+dt,
	krzk+dt, conor+dt, linux-kernel, quentin.schulz, wens,
	daniel.lezcano, didi.debian, krzysztof.kozlowski+dt,
	viresh.kumar

On 2024-05-29 14:04, Alexey Charkov wrote:
> On Wed, May 29, 2024 at 2:45 PM Dragan Simic <dsimic@manjaro.org> 
> wrote:
>> On 2024-05-29 11:57, Alexey Charkov wrote:
>> > On Wed, May 29, 2024 at 6:14 AM Dragan Simic <dsimic@manjaro.org>
>> > wrote:
>> >>
>> >> Rename and modify the RK3588 dtsi files a bit, to make preparations
>> >> for
>> >> the ability to specify different CPU and GPU OPPs for each of the
>> >> supported
>> >> RK3588 SoC variants, including the RK3588J.
>> >>
>> >> As already discussed, [1][2][3] some of the different RK3588 SoC
>> >> variants
>> >> require different OPPs, and it makes more sense to have the OPPs
>> >> already
>> >> defined when a board dts includes one of the SoC dtsi files
>> >> (rk3588.dtsi,
>> >> rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts
>> >> file to
>> >> also include a separate rk3588*-opp.dtsi file.  The choice of the SoC
>> >> variant
>> >> is already made by the inclusion of the SoC dtsi file, and it doesn't
>> >> make
>> >> much sense to, effectively, allow the board dts file to include and
>> >> use an
>> >> incompatible set of OPPs for the already selected SoC variant.
>> >
>> > Indeed, including just one .dtsi for the correct SoC variant and not
>> > having to bother about what other bits and pieces are required to use
>> > the full SoC functionality sounds great! Thanks for putting this
>> > together so promptly!
>> 
>> You're welcome. :)
>> 
>> > Some considerations below.
>> >
>> >> No intended functional changes are introduced.  (Still to be
>> >> additionally
>> >> verified if the patch moves forward from the RFC state.)
>> >>
>> >> [1]
>> >> https://lore.kernel.org/linux-rockchip/646a33e0-5c1b-471c-8183-2c0df40ea51a@cherry.de/
>> >> [2]
>> >> https://lore.kernel.org/linux-rockchip/CABjd4Yxi=+3gkNnH3BysUzzYsji-=-yROtzEc8jM_g0roKB0-w@mail.gmail.com/
>> >> [3]
>> >> https://lore.kernel.org/linux-rockchip/035a274be262528012173d463e25b55f@manjaro.org/
>> >>
>> >> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
>> >> ---
>> >>  ...inctrl.dtsi => rk3588-common-pinctrl.dtsi} |    0
>> >
>> > Renaming the pinctrl includes seems superfluous - maybe keep them as
>> > they were to minimize churn?
>> 
>> Believe it or not, the same thoughts crossed my mind.  However,
>> after thinking a bit about it, I concluded that renaming the pinctrl
>> .dtsi files as well makes the overall naming of the reworked RK3588
>> .dtsi files more consistent.
>> 
>> It's also rather neat to have the "common" and "fullfat" file pairs
>> together in the arch/arm64/boot/dts/rockchip directory listing, when
>> it's sorted by the file name, which is the default in most (if not
>> all) environments.
>> 
>> >>  .../{rk3588s.dtsi => rk3588-common.dtsi}      |    2 +-
>> >>  ...nctrl.dtsi => rk3588-fullfat-pinctrl.dtsi} |    0
>> >>  .../{rk3588.dtsi => rk3588-fullfat.dtsi}      |    4 +-
>> >
>> > To me, "fullfat" doesn't look super descriptive, albeit fun :)
>> 
>> Yeah, I resorted to "fullfat" as some kind of a funny option. :)
>> That's for the "beefy" SoC variants, so it kind of fits well. :)
>> 
>> > How about we rename the existing rk3588.dtsi and rk3588s.dtsi to
>> > something like rk3588-devices.dtsi and rk3588s-devices.dtsi
>> > (preserving the inheritance between them), and then I add
>> > rk3588s-opp.dtsi and rk3588j-opp.dtsi in a follow-up patch?
>> 
>> The trouble with including "devices" into the filenames is, well,
>> the fact that those files isn't about any devices, but about the
>> SoC variants.  Thus, "devices" simply wouldn't fit there.
> 
> My thinking was along the lines of "here is the file that contains all
> DT nodes for built-in _devices_ (as in on-chip IP blocks) on RK3588 -
> thus it's called rk3588-devices.dtsi", and "here's the file that
> contains operating parameters that distinguish RK3588 and RK3588s from
> RK3588j - it's called rk3588s-opp.dtsi"

Hmm...  I see, but a device is usually though of as some standalone
computer, at least in this context.  Surely, an SoC is also some kind
of a device, for example, but I'm pretty sure we'll very rarely call
an SoC a device.  It's always good to adhere to the usual meaning of
the words in a particular lingo.

When it comes to rk3588s-opp.dtsi, it would be more of a file that
completes the rk3588s.dtsi by adding the OPPs, but we can in fact
add the OPPs directly into rk3588s.dtsi, because in the new layout
rk3588s.dtsi isn't a parent to any other file.

>> Moreover, in the envisioned scheme there should be no separate
>> OPP .dtsi files;  the OPP data should go directly into the new
>> rk3588.dtsi, rk3588s.dtsi and rk3588j.dtsi files, where it actually
>> belongs.  That's why those .dtsi files exist and are mostly empty,
>> at least the way I see it.  I'll get back to this below.
>> 
>> > Then we keep "thin" versions of rk3588.dtsi, rk3588s.dtsi and
>> > rk3588j.dtsi for board files to include. The mix-and-match of
>> > different on-chip devices and different OPPs then gets transparently
>> > represented within those "thin" .dtsi, something like this:
>> >
>> > rk3588.dtsi:
>> > #include "rk3588-devices.dtsi"
>> > #include "rk3588s-opp.dtsi"
>> >
>> > rk3588s.dtsi:
>> > #include "rk3588s-devices.dtsi"
>> > #include "rk3588s-opp.dtsi"
>> >
>> > rk3588j.dtsi:
>> > #include "rk3588-devices.dtsi"
>> > #include "rk3588j-opp.dtsi"
>> 
>> Such a layout, in general, has also crossed my mind, but my conclusion
>> was that having the per-SoC-variant OPP data specified directly in the
>> reworked rk3588.dtsi, rk3588s.dtsi and rk3588j.dtsi files is a better
>> option in the long term, even if we end up that way with rk3588.dtsi 
>> and
>> rk3588s.dtsi repeating most (if not all) of the same OPP data.
> 
> From all the info we have available so far, RK3588 and RK3588s share
> identical OPPs, so having one file with OPPs that both variants refer
> to should be more maintainable (and fewer lines of DT code).

Hmm.  Perhaps we can have rk3588-opp.dtsi as a separate file with the
OPPs shared between the RK3588 and the RK3588S, which would be included
from rk3588.dtsi and rk3588s.dtsi.

Though, the OPPs for the RK3588J should go directly into rk3588j.dtsi;
if we ever split the OPPs for the RK3588 and the RK3588S, the new OPPs
should also go directly into rk3588.dtsi and rk3588s.dtsi.

> All in all, it appears that RK3588 and RK3588j have an identical set
> of built-in devices, but different OPPs due to RK3588j being spec'd
> for industrial use which apparently has different requirements. At the
> same time, RK3588s uses an identical set of OPPs as RK3588 but a
> reduced set of built-in devices. The combination of includes I
> proposed above makes this explicit.

Again, calling IP blocks devices is, AFAIK, very uncommon.

> As for RK3588m, it seems to include all the same devices as RK3588 and
> RK3588j, but a slightly modified set of OPPs compared to RK3588j. We
> don't have any boards using that variant in the mainline tree right
> now, but it would be easy, when the need arises, to add something
> along the lines of:
> 
> rk3588m.dtsi:
> #include "rk3588-devices.dtsi"
> #include "rk3588m-opp.dtsi"
> 
> rk3588m-opp.dtsi:
> #include "rk3588j-opp.dtsi"
> &cluster0_opp_table {
>         /delete-node/ opp-1296000000;
> };

I don't think that deleting nodes that way is a good option.  It's
rather error-prone and hard to track, so it would be better to have
the OPPs for RK3588M specified directly (and fully) in the future
rk3588m.dtsi file, just like in rk3588j.dtsi.

>> That way we'll have no roadblocks if, at some point, we end up with
>> having
>> different OPPs defined for the RK3588 and the RK3588S variants.  Or
>> maybe
>> even for the RK3582, which we don't know much about yet.
> 
> Guess we'll deal with that one once we stumble upon an actual RK3582
> board out in the wild and heading to the mainline kernel tree :)

Of course, that was just an example for the future use.

^ permalink raw reply	[relevance 1%]

* Re: [PATCH 1/7] riscv: Implement cmpxchg32/64() using Zacas
  @ 2024-05-29 12:20  1%       ` Alexandre Ghiti
  0 siblings, 0 replies; 200+ results
From: Alexandre Ghiti @ 2024-05-29 12:20 UTC (permalink / raw)
  To: Conor Dooley
  Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long,
	Boqun Feng, Arnd Bergmann, Leonardo Bras, Guo Ren, linux-doc,
	linux-kernel, linux-riscv, linux-arch

Hi Conor,

On Tue, May 28, 2024 at 5:34 PM Conor Dooley <conor@kernel.org> wrote:
>
> On Tue, May 28, 2024 at 05:10:46PM +0200, Alexandre Ghiti wrote:
> > This adds runtime support for Zacas in cmpxchg operations.
> >
> > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
> > ---
> >  arch/riscv/Kconfig               | 17 +++++++++++++++++
> >  arch/riscv/Makefile              | 11 +++++++++++
> >  arch/riscv/include/asm/cmpxchg.h | 23 ++++++++++++++++++++---
> >  3 files changed, 48 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 8a0f403432e8..b443def70139 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -579,6 +579,23 @@ config RISCV_ISA_V_PREEMPTIVE
> >         preemption. Enabling this config will result in higher memory
> >         consumption due to the allocation of per-task's kernel Vector context.
> >
> > +config TOOLCHAIN_HAS_ZACAS
> > +     bool
> > +     default y
> > +     depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zacas)
> > +     depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zacas)
> > +     depends on AS_HAS_OPTION_ARCH
> > +
> > +config RISCV_ISA_ZACAS
> > +     bool "Zacas extension support for atomic CAS"
> > +     depends on TOOLCHAIN_HAS_ZACAS
> > +     default y
> > +     help
> > +       Adds support to use atomic CAS instead of LR/SC to implement kernel
> > +       atomic cmpxchg operation.
>
> If you were a person compiling a kernel, would you be able to read this
> and realise that this is safe to enable when their system does not
> support atomic CAS? Please take a look at other how other extensions
> handle this, or the patch that I have been sending that tries to make
> things clearer:
> https://patchwork.kernel.org/project/linux-riscv/patch/20240528-varnish-status-9c22973093a0@spud/

Ok, I will go for: "Enable the use of the Zacas ISA-extension to
implement atomic cmpxchg operations when it is detected at boot."
And I will do the same for Zabha.

>
> > +
> > +       If you don't know what to do here, say Y.
> > +
> >  config TOOLCHAIN_HAS_ZBB
> >       bool
> >       default y
> > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > index 5b3115a19852..d5b60b87998c 100644
> > --- a/arch/riscv/Makefile
> > +++ b/arch/riscv/Makefile
> > @@ -78,6 +78,17 @@ endif
> >  # Check if the toolchain supports Zihintpause extension
> >  riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE) := $(riscv-march-y)_zihintpause
> >
> > +# Check if the toolchain supports Zacas
> > +ifdef CONFIG_AS_IS_LLVM
> > +# Support for experimental Zacas was merged in LLVM 17, but the removal of
> > +# the "experimental" was merged in LLVM 19.
> > +KBUILD_CFLAGS += -menable-experimental-extensions
> > +KBUILD_AFLAGS += -menable-experimental-extensions
> > +riscv-march-y := $(riscv-march-y)_zacas1p0
> > +else
> > +riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZACAS) := $(riscv-march-y)_zacas
> > +endif
>
> I'm almost certain that we discussed this before for vector and it was
> decided to not enable experimental extensions (particularly as it is a
> global option), and instead require the non-experimental versions.
> This isn't even consistent with your TOOLCHAIN_HAS_ZACAS checks, that
> will only enable the option for the ratified version.

Zacas was ratified, hence the removal of "experimental" in LLVM 19.
But unfortunately Zabha lacks such changes in LLVM, so that will make
this inconsistent (ratified extension but still experimental).

I'll remove the enablement of the experimental extensions then so that
will fail for LLVM < 19. And for Zabha, I'll try to push the removal
of experimental from LLVM.

> I think we should
> continue to avoid enabling experimental extensions, even if that imposes
> a requirement of having a bleeding edge toolchain to actually use the
> extension.

Would it make sense to have a
CONFIG_RISCV_LLVM_ENABLE_EXPERIMENTAL_EXTENSIONS or similar? So that
people who want to play with those extensions will still be able to do
so without patching the kernel?

Thanks,

Alex

>
> Thanks,
> Conor.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[relevance 1%]

* Re: [PATCH 1/7] riscv: Implement cmpxchg32/64() using Zacas
@ 2024-05-29 12:20  1%       ` Alexandre Ghiti
  0 siblings, 0 replies; 200+ results
From: Alexandre Ghiti @ 2024-05-29 12:20 UTC (permalink / raw)
  To: Conor Dooley
  Cc: Jonathan Corbet, Paul Walmsley, Palmer Dabbelt, Albert Ou,
	Peter Zijlstra, Ingo Molnar, Will Deacon, Waiman Long,
	Boqun Feng, Arnd Bergmann, Leonardo Bras, Guo Ren, linux-doc,
	linux-kernel, linux-riscv, linux-arch

Hi Conor,

On Tue, May 28, 2024 at 5:34 PM Conor Dooley <conor@kernel.org> wrote:
>
> On Tue, May 28, 2024 at 05:10:46PM +0200, Alexandre Ghiti wrote:
> > This adds runtime support for Zacas in cmpxchg operations.
> >
> > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
> > ---
> >  arch/riscv/Kconfig               | 17 +++++++++++++++++
> >  arch/riscv/Makefile              | 11 +++++++++++
> >  arch/riscv/include/asm/cmpxchg.h | 23 ++++++++++++++++++++---
> >  3 files changed, 48 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 8a0f403432e8..b443def70139 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -579,6 +579,23 @@ config RISCV_ISA_V_PREEMPTIVE
> >         preemption. Enabling this config will result in higher memory
> >         consumption due to the allocation of per-task's kernel Vector context.
> >
> > +config TOOLCHAIN_HAS_ZACAS
> > +     bool
> > +     default y
> > +     depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zacas)
> > +     depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zacas)
> > +     depends on AS_HAS_OPTION_ARCH
> > +
> > +config RISCV_ISA_ZACAS
> > +     bool "Zacas extension support for atomic CAS"
> > +     depends on TOOLCHAIN_HAS_ZACAS
> > +     default y
> > +     help
> > +       Adds support to use atomic CAS instead of LR/SC to implement kernel
> > +       atomic cmpxchg operation.
>
> If you were a person compiling a kernel, would you be able to read this
> and realise that this is safe to enable when their system does not
> support atomic CAS? Please take a look at other how other extensions
> handle this, or the patch that I have been sending that tries to make
> things clearer:
> https://patchwork.kernel.org/project/linux-riscv/patch/20240528-varnish-status-9c22973093a0@spud/

Ok, I will go for: "Enable the use of the Zacas ISA-extension to
implement atomic cmpxchg operations when it is detected at boot."
And I will do the same for Zabha.

>
> > +
> > +       If you don't know what to do here, say Y.
> > +
> >  config TOOLCHAIN_HAS_ZBB
> >       bool
> >       default y
> > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > index 5b3115a19852..d5b60b87998c 100644
> > --- a/arch/riscv/Makefile
> > +++ b/arch/riscv/Makefile
> > @@ -78,6 +78,17 @@ endif
> >  # Check if the toolchain supports Zihintpause extension
> >  riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZIHINTPAUSE) := $(riscv-march-y)_zihintpause
> >
> > +# Check if the toolchain supports Zacas
> > +ifdef CONFIG_AS_IS_LLVM
> > +# Support for experimental Zacas was merged in LLVM 17, but the removal of
> > +# the "experimental" was merged in LLVM 19.
> > +KBUILD_CFLAGS += -menable-experimental-extensions
> > +KBUILD_AFLAGS += -menable-experimental-extensions
> > +riscv-march-y := $(riscv-march-y)_zacas1p0
> > +else
> > +riscv-march-$(CONFIG_TOOLCHAIN_HAS_ZACAS) := $(riscv-march-y)_zacas
> > +endif
>
> I'm almost certain that we discussed this before for vector and it was
> decided to not enable experimental extensions (particularly as it is a
> global option), and instead require the non-experimental versions.
> This isn't even consistent with your TOOLCHAIN_HAS_ZACAS checks, that
> will only enable the option for the ratified version.

Zacas was ratified, hence the removal of "experimental" in LLVM 19.
But unfortunately Zabha lacks such changes in LLVM, so that will make
this inconsistent (ratified extension but still experimental).

I'll remove the enablement of the experimental extensions then so that
will fail for LLVM < 19. And for Zabha, I'll try to push the removal
of experimental from LLVM.

> I think we should
> continue to avoid enabling experimental extensions, even if that imposes
> a requirement of having a bleeding edge toolchain to actually use the
> extension.

Would it make sense to have a
CONFIG_RISCV_LLVM_ENABLE_EXPERIMENTAL_EXTENSIONS or similar? So that
people who want to play with those extensions will still be able to do
so without patching the kernel?

Thanks,

Alex

>
> Thanks,
> Conor.

^ permalink raw reply	[relevance 1%]

* Re: [PATCH v7 2/5] KEYS: trusted: Change -EINVAL to -E2BIG
  @ 2024-05-29 12:20  1%     ` Jarkko Sakkinen
  0 siblings, 0 replies; 200+ results
From: Jarkko Sakkinen @ 2024-05-29 12:20 UTC (permalink / raw)
  To: Stefan Berger, Herbert Xu
  Cc: linux-integrity, keyrings, Andreas.Fuchs, James Prestwood,
	David Woodhouse, Eric Biggers, James Bottomley, linux-crypto,
	Lennart Poettering, David S. Miller, open list, Mimi Zohar,
	David Howells, Paul Moore, James Morris, Serge E. Hallyn,
	open list:SECURITY SUBSYSTEM

On Wed May 29, 2024 at 4:50 AM EEST, Stefan Berger wrote:
>
>
> On 5/28/24 17:08, Jarkko Sakkinen wrote:
> > Report -E2BIG instead of -EINVAL when too large size for the key blob is
> > requested.
> > 
> > Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
>
> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>

Thank you.

Hmm... I'd like to add even:

Cc: stable@vger.kernel.org # v5.13+
Fixes: f2219745250f ("security: keys: trusted: use ASN.1 TPM2 key format for the blobs")

It turned out to be useful error message and would be useful also for
stable kernels. So if no decent counter-arguments, I'll just pick it
to my master branch.

BR, Jarkko

^ permalink raw reply	[relevance 1%]

* Re: [PATCH 4/8] gpio: tqmx86: introduce _tqmx86_gpio_update_bits() helper
  @ 2024-05-29 12:19  1%   ` Andrew Lunn
  2024-05-29 12:25  0%     ` Matthias Schiffer
  0 siblings, 1 reply; 200+ results
From: Andrew Lunn @ 2024-05-29 12:19 UTC (permalink / raw)
  To: Matthias Schiffer
  Cc: Linus Walleij, Bartosz Golaszewski, linux-gpio, linux-kernel,
	Gregor Herburger, linux

On Wed, May 29, 2024 at 09:45:16AM +0200, Matthias Schiffer wrote:
> Simplify a lot of code in the driver by introducing helpers for the
> common RMW pattern. No tqmx86_gpio_update_bits() function with builtin
> locking is added, as it would become redundant with the following fixes,
> which further consolidate interrupt configuration register setup.
> 
> No functional change intended.
> 
> Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")
> Signed-off-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> ---
>  drivers/gpio/gpio-tqmx86.c | 40 ++++++++++++++++++++++----------------
>  1 file changed, 23 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-tqmx86.c b/drivers/gpio/gpio-tqmx86.c
> index 613ab9ef2e744..7a851e1730dd1 100644
> --- a/drivers/gpio/gpio-tqmx86.c
> +++ b/drivers/gpio/gpio-tqmx86.c
> @@ -54,6 +54,17 @@ static void tqmx86_gpio_write(struct tqmx86_gpio_data *gd, unsigned int reg,
>  	iowrite8(val, gd->io_base + reg);
>  }
>  
> +static void _tqmx86_gpio_update_bits(struct tqmx86_gpio_data *gd,
> +				     unsigned int reg, u8 mask, u8 val)

Why the _ prefix? This is a local function, it is static, so you don't
have name space issues. Functions starting with _ are those you should
not call without a good reason, there is generally a version without
the _ prefix which is the real function to use. So i would drop the _.

This is also not a fix. Please read:

https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

and stick to the rules described there.

I don't know how the GPIO tree works, but for netdev, about a week
after fixes are merged, they appear in net-next. So you can then build
on top of them for development work.

	Andrew

^ permalink raw reply	[relevance 1%]

* Re: [PATCH 0/2] Revert defense-in-depth patches breaking Git LFS
  @ 2024-05-29 12:17  0%             ` Johannes Schindelin
  0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2024-05-29 12:17 UTC (permalink / raw)
  To: Jeff King; +Cc: Joey Hess, brian m. carlson, git, Junio C Hamano

Hi Jeff,

On Wed, 29 May 2024, Jeff King wrote:

> [...] But of course most sites just use the defaults, so all warnings
> are effectively errors.

I wish that had been pointed out on the git-security mailing list when I
offered this patch up for review.

> In the meantime, we also have an "INFO" severity which gets reported but
> not upgraded via strict. It sounds like that's what was intended here.

Precisely.

So this is what the fix-up patch would look like to make the code match my
intention:

-- snipsnap --
Subject: [PATCH] fsck: demote the newly-introduced symlink issues from WARN -> IGNORE

The idea of the symlink check to prevent overly-long symlink targets and
targets inside the `.git/` directory was to _warn_, but not to prevent
any operation.

However, that's not how Git works, I was confused by the label `WARN`.
What we need instead is the `IGNORE` label, which still warns
(confusingly so ;-)), but does not prevent any operations from
continuing.

Adjust t1450 accordingly, documenting that `git fsck` unfortunately no
longer warns about these issues by default.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/fsck-msgids.txt |  4 ++--
 fsck.h                        |  4 ++--
 t/t1450-fsck.sh               | 13 ++++++++++++-
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/Documentation/fsck-msgids.txt b/Documentation/fsck-msgids.txt
index b06ec385aff..f5016ecda6a 100644
--- a/Documentation/fsck-msgids.txt
+++ b/Documentation/fsck-msgids.txt
@@ -158,13 +158,13 @@
 	(WARN) Tree contains entries pointing to a null sha1.

 `symlinkPointsToGitDir`::
-	(WARN) Symbolic link points inside a gitdir.
+	(INFO) Symbolic link points inside a gitdir.

 `symlinkTargetBlob`::
 	(ERROR) A non-blob found instead of a symbolic link's target.

 `symlinkTargetLength`::
-	(WARN) Symbolic link target longer than maximum path length.
+	(INFO) Symbolic link target longer than maximum path length.

 `symlinkTargetMissing`::
 	(ERROR) Unable to read symbolic link target's blob.
diff --git a/fsck.h b/fsck.h
index 130fa8d8f91..d41ec98064b 100644
--- a/fsck.h
+++ b/fsck.h
@@ -74,8 +74,6 @@ enum fsck_msg_type {
 	FUNC(NULL_SHA1, WARN) \
 	FUNC(ZERO_PADDED_FILEMODE, WARN) \
 	FUNC(NUL_IN_COMMIT, WARN) \
-	FUNC(SYMLINK_TARGET_LENGTH, WARN) \
-	FUNC(SYMLINK_POINTS_TO_GIT_DIR, WARN) \
 	/* infos (reported as warnings, but ignored by default) */ \
 	FUNC(BAD_FILEMODE, INFO) \
 	FUNC(GITMODULES_PARSE, INFO) \
@@ -84,6 +82,8 @@ enum fsck_msg_type {
 	FUNC(MAILMAP_SYMLINK, INFO) \
 	FUNC(BAD_TAG_NAME, INFO) \
 	FUNC(MISSING_TAGGER_ENTRY, INFO) \
+	FUNC(SYMLINK_TARGET_LENGTH, INFO) \
+	FUNC(SYMLINK_POINTS_TO_GIT_DIR, INFO) \
 	/* ignored (elevated when requested) */ \
 	FUNC(EXTRA_HEADER_ENTRY, IGNORE)

diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index 5669872bc80..8339e60efb2 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -1032,7 +1032,18 @@ test_expect_success 'fsck warning on symlink target with excessive length' '
 	warning in blob $symlink_target: symlinkTargetLength: symlink target too long
 	EOF
 	git fsck --no-dangling >actual 2>&1 &&
-	test_cmp expected actual
+	test_cmp expected actual &&
+
+	test_when_finished "git tag -d symlink-target-length" &&
+	git tag symlink-target-length $tree &&
+	test_when_finished "rm -rf throwaway.git" &&
+	git init --bare throwaway.git &&
+	git --git-dir=throwaway.git config receive.fsckObjects true &&
+	git --git-dir=throwaway.git config receive.fsck.symlinkTargetLength error &&
+	test_must_fail git push throwaway.git symlink-target-length &&
+	git --git-dir=throwaway.git config --unset receive.fsck.symlinkTargetLength &&
+	git push throwaway.git symlink-target-length 2>err &&
+	grep "warning.*symlinkTargetLength" err
 '

 test_expect_success 'fsck warning on symlink target pointing inside git dir' '

^ permalink raw reply related	[relevance 0%]

* Re: [PATCH v2] docs: dt: Update overlay file extension
  @ 2024-05-29 12:17  0% ` Alex Shi
  0 siblings, 0 replies; 200+ results
From: Alex Shi @ 2024-05-29 12:17 UTC (permalink / raw)
  To: Geert Uytterhoeven, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Alex Shi, Yanteng Si, Jonathan Corbet,
	Andrew Davis, Masahiro Yamada, Andy Shevchenko
  Cc: devicetree, linux-doc, linux-kernel

LGTM.

On 5/29/24 6:00 PM, Geert Uytterhoeven wrote:
> Building DTB overlays from .dts files is no longer supported.
> Update the documentation to reflect this.
> 
> Fixes: 81d362732bac05f6 ("kbuild: Disallow DTB overlays to built from .dts named source files")
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Andrew Davis <afd@ti.com>
> Reviewed-by: Yanteng Si <siyanteng@loongson.cn>
> ---
> v2:
>   - Add Acked-by, Reviewed-by.
> ---
>  Documentation/devicetree/overlay-notes.rst           | 12 ++++++------
>  .../translations/zh_CN/devicetree/overlay-notes.rst  | 12 ++++++------
>  2 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/Documentation/devicetree/overlay-notes.rst b/Documentation/devicetree/overlay-notes.rst
> index e139f22b363e9f36..35e79242af9a928d 100644
> --- a/Documentation/devicetree/overlay-notes.rst
> +++ b/Documentation/devicetree/overlay-notes.rst
> @@ -38,10 +38,10 @@ Lets take an example where we have a foo board with the following base tree::
>  	};
>      ---- foo.dts ---------------------------------------------------------------
>  
> -The overlay bar.dts,
> +The overlay bar.dtso,
>  ::
>  
> -    ---- bar.dts - overlay target location by label ----------------------------
> +    ---- bar.dtso - overlay target location by label ---------------------------
>  	/dts-v1/;
>  	/plugin/;
>  	&ocp {
> @@ -51,7 +51,7 @@ The overlay bar.dts,
>  			... /* various properties and child nodes */
>  		};
>  	};
> -    ---- bar.dts ---------------------------------------------------------------
> +    ---- bar.dtso --------------------------------------------------------------
>  
>  when loaded (and resolved as described in [1]) should result in foo+bar.dts::
>  
> @@ -88,9 +88,9 @@ in the base DT. In this case, the target path can be provided. The target
>  location by label syntax is preferred because the overlay can be applied to
>  any base DT containing the label, no matter where the label occurs in the DT.
>  
> -The above bar.dts example modified to use target path syntax is::
> +The above bar.dtso example modified to use target path syntax is::
>  
> -    ---- bar.dts - overlay target location by explicit path --------------------
> +    ---- bar.dtso - overlay target location by explicit path -------------------
>  	/dts-v1/;
>  	/plugin/;
>  	&{/ocp} {
> @@ -100,7 +100,7 @@ The above bar.dts example modified to use target path syntax is::
>  			... /* various properties and child nodes */
>  		}
>  	};
> -    ---- bar.dts ---------------------------------------------------------------
> +    ---- bar.dtso --------------------------------------------------------------
>  
>  
>  Overlay in-kernel API
> diff --git a/Documentation/translations/zh_CN/devicetree/overlay-notes.rst b/Documentation/translations/zh_CN/devicetree/overlay-notes.rst
> index 43e3c0bc5a9f8235..ba5edd05dc1e7fd2 100644
> --- a/Documentation/translations/zh_CN/devicetree/overlay-notes.rst
> +++ b/Documentation/translations/zh_CN/devicetree/overlay-notes.rst
> @@ -43,10 +43,10 @@ Documentation/devicetree/dynamic-resolution-notes.rst[1]的配套文档。
>  	};
>      ---- foo.dts ---------------------------------------------------------------
>  
> -覆盖bar.dts,
> +覆盖bar.dtso,
>  ::
>  
> -    ---- bar.dts - 按标签覆盖目标位置 ----------------------------
> +    ---- bar.dtso - 按标签覆盖目标位置 ---------------------------
>  	/dts-v1/;
>  	/插件/;
>  	&ocp {
> @@ -56,7 +56,7 @@ Documentation/devicetree/dynamic-resolution-notes.rst[1]的配套文档。
>  			... /* 各种属性和子节点 */
>  		};
>  	};
> -    ---- bar.dts ---------------------------------------------------------------
> +    ---- bar.dtso --------------------------------------------------------------
>  
>  当加载(并按照[1]中描述的方式解决)时,应该产生foo+bar.dts::
>  
> @@ -90,9 +90,9 @@ Documentation/devicetree/dynamic-resolution-notes.rst[1]的配套文档。
>  DT中的适当位置。在这种情况下,可以提供目标路径。通过标签的目标位置的语法是比
>  较好的,因为不管标签在DT中出现在哪里,覆盖都可以被应用到任何包含标签的基础DT上。
>  
> -上面的bar.dts例子被修改为使用目标路径语法,即为::
> +上面的bar.dtso例子被修改为使用目标路径语法,即为::
>  
> -    ---- bar.dts - 通过明确的路径覆盖目标位置 --------------------
> +    ---- bar.dtso - 通过明确的路径覆盖目标位置 -------------------
>  	/dts-v1/;
>  	/插件/;
>  	&{/ocp} {
> @@ -102,7 +102,7 @@ DT中的适当位置。在这种情况下,可以提供目标路径。通过标
>  			... /* 各种外围设备和子节点 */
>  		}
>  	};
> -    ---- bar.dts ---------------------------------------------------------------
> +    ---- bar.dtso --------------------------------------------------------------
>  
>  
>  内核中关于覆盖的API

^ permalink raw reply	[relevance 0%]

* [PATCH v4 11/13] KVM: arm64: Improve CONFIG_CFI_CLANG error message
  @ 2024-05-29 12:12  1%   ` Pierre-Clément Tosi
  2024-05-29 12:12  2%   ` Pierre-Clément Tosi
                     ` (7 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

For kCFI, the compiler encodes in the immediate of the BRK (which the
CPU places in ESR_ELx) the indices of the two registers it used to hold
(resp.) the function pointer and expected type. Therefore, the kCFI
handler must be able to parse the contents of the register file at the
point where the exception was triggered.

To achieve this, introduce a new hypervisor panic path that first stores
the CPU context in the per-CPU kvm_hyp_ctxt before calling (directly or
indirectly) hyp_panic() and execute it from all EL2 synchronous
exception handlers i.e.

- call it directly in host_el2_sync_vect (__kvm_hyp_host_vector, EL2t&h)
- call it directly in el2t_sync_invalid (__kvm_hyp_vector, EL2t)
- set ELR_EL2 to it in el2_sync (__kvm_hyp_vector, EL2h), which ERETs

Teach hyp_panic() to decode the kCFI ESR and extract the target and type
from the saved CPU context. In VHE, use that information to panic() with
a specialized error message. In nVHE, only report it if the host (EL1)
has access to the saved CPU context i.e. iff CONFIG_NVHE_EL2_DEBUG=y,
which aligns with the behavior of CONFIG_PROTECTED_NVHE_STACKTRACE.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/kvm/handle_exit.c            | 30 +++++++++++++++++++++++--
 arch/arm64/kvm/hyp/entry.S              | 24 +++++++++++++++++++-
 arch/arm64/kvm/hyp/hyp-entry.S          |  2 +-
 arch/arm64/kvm/hyp/include/hyp/switch.h |  4 ++--
 arch/arm64/kvm/hyp/nvhe/host.S          |  2 +-
 arch/arm64/kvm/hyp/vhe/switch.c         | 26 +++++++++++++++++++--
 6 files changed, 79 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 69b08ac7322d..2fac3be3db00 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -26,6 +26,8 @@
 #define CREATE_TRACE_POINTS
 #include "trace_handle_exit.h"
 
+DECLARE_KVM_NVHE_PER_CPU(struct kvm_cpu_context, kvm_hyp_ctxt);
+
 typedef int (*exit_handle_fn)(struct kvm_vcpu *);
 
 static void kvm_handle_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
@@ -417,10 +419,34 @@ static void print_nvhe_hyp_panic(const char *name, u64 panic_addr)
 		(void *)(panic_addr + kaslr_offset()));
 }
 
-static void kvm_nvhe_report_cfi_failure(u64 panic_addr)
+static void kvm_nvhe_report_cfi_target(struct user_pt_regs *regs, u64 esr,
+				       u64 hyp_offset)
+{
+	u64 va_mask = GENMASK_ULL(vabits_actual - 1, 0);
+	u8 type_idx = FIELD_GET(CFI_BRK_IMM_TYPE, esr);
+	u8 target_idx = FIELD_GET(CFI_BRK_IMM_TARGET, esr);
+	u32 expected_type = (u32)regs->regs[type_idx];
+	u64 target_addr = (regs->regs[target_idx] & va_mask) + hyp_offset;
+
+	kvm_err(" (target: [<%016llx>] %ps, expected type: 0x%08x)\n",
+		target_addr, (void *)(target_addr + kaslr_offset()),
+		expected_type);
+}
+
+static void kvm_nvhe_report_cfi_failure(u64 panic_addr, u64 esr, u64 hyp_offset)
 {
+	struct user_pt_regs *regs = NULL;
+
 	print_nvhe_hyp_panic("CFI failure", panic_addr);
 
+	if (IS_ENABLED(CONFIG_NVHE_EL2_DEBUG) || !is_protected_kvm_enabled())
+		regs = &this_cpu_ptr_nvhe_sym(kvm_hyp_ctxt)->regs;
+
+	if (regs)
+		kvm_nvhe_report_cfi_target(regs, esr, hyp_offset);
+	else
+		kvm_err(" (no target information: !CONFIG_NVHE_EL2_DEBUG)\n");
+
 	if (IS_ENABLED(CONFIG_CFI_PERMISSIVE))
 		kvm_err(" (CONFIG_CFI_PERMISSIVE ignored for hyp failures)\n");
 }
@@ -455,7 +481,7 @@ void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
 		else
 			print_nvhe_hyp_panic("BUG", panic_addr);
 	} else if (IS_ENABLED(CONFIG_CFI_CLANG) && esr_is_cfi_brk(esr)) {
-		kvm_nvhe_report_cfi_failure(panic_addr);
+		kvm_nvhe_report_cfi_failure(panic_addr, esr, hyp_offset);
 	} else {
 		print_nvhe_hyp_panic("panic", panic_addr);
 	}
diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
index 343851c17373..8965dbc75972 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -83,7 +83,7 @@ alternative_else_nop_endif
 	eret
 	sb
 
-SYM_INNER_LABEL(__hyp_restore_elr_and_panic, SYM_L_GLOBAL)
+SYM_INNER_LABEL(__hyp_restore_elr_save_context_and_panic, SYM_L_GLOBAL)
 	// x2-x29,lr: vcpu regs
 	// vcpu x0-x1 on the stack
 
@@ -91,6 +91,28 @@ SYM_INNER_LABEL(__hyp_restore_elr_and_panic, SYM_L_GLOBAL)
 	ldr	x0, [x0, #CPU_ELR_EL2]
 	msr	elr_el2, x0
 
+SYM_INNER_LABEL(__hyp_save_context_and_panic, SYM_L_GLOBAL)
+	// x0-x29,lr: hyp regs
+
+	stp	x0, x1, [sp, #-16]!
+
+	adr_this_cpu x0, kvm_hyp_ctxt, x1
+
+	stp	x2, x3,   [x0, #CPU_XREG_OFFSET(2)]
+
+	ldp	x2, x3, [sp], #16
+
+	stp	x2, x3,   [x0, #CPU_XREG_OFFSET(0)]
+	stp	x4, x5,   [x0, #CPU_XREG_OFFSET(4)]
+	stp	x6, x7,   [x0, #CPU_XREG_OFFSET(6)]
+	stp	x8, x9,   [x0, #CPU_XREG_OFFSET(8)]
+	stp	x10, x11, [x0, #CPU_XREG_OFFSET(10)]
+	stp	x12, x13, [x0, #CPU_XREG_OFFSET(12)]
+	stp	x14, x15, [x0, #CPU_XREG_OFFSET(14)]
+	stp	x16, x17, [x0, #CPU_XREG_OFFSET(16)]
+
+	save_callee_saved_regs x0
+
 SYM_INNER_LABEL(__hyp_panic, SYM_L_GLOBAL)
 	// x2-x29,lr: vcpu regs
 	// vcpu x0-x1 on the stack
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index 7e65ef738ec9..d0d90d598338 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -130,7 +130,7 @@ SYM_CODE_END(\label)
 .endm
 
 	/* None of these should ever happen */
-	invalid_vector	el2t_sync_invalid
+	invalid_vector	el2t_sync_invalid, __hyp_save_context_and_panic
 	invalid_vector	el2t_irq_invalid
 	invalid_vector	el2t_fiq_invalid
 	invalid_vector	el2t_error_invalid
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index d9931abf14c2..77783dbc1833 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -689,7 +689,7 @@ static inline bool fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
 
 static inline void __kvm_unexpected_el2_exception(void)
 {
-	extern char __hyp_restore_elr_and_panic[];
+	extern char __hyp_restore_elr_save_context_and_panic[];
 	unsigned long addr, fixup;
 	struct kvm_exception_table_entry *entry, *end;
 	unsigned long elr_el2 = read_sysreg(elr_el2);
@@ -712,7 +712,7 @@ static inline void __kvm_unexpected_el2_exception(void)
 
 	/* Trigger a panic after restoring the hyp context. */
 	this_cpu_ptr(&kvm_hyp_ctxt)->sys_regs[ELR_EL2] = elr_el2;
-	write_sysreg(__hyp_restore_elr_and_panic, elr_el2);
+	write_sysreg(__hyp_restore_elr_save_context_and_panic, elr_el2);
 }
 
 #endif /* __ARM64_KVM_HYP_SWITCH_H__ */
diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index a7db40a51e4a..9343160f5357 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -214,7 +214,7 @@ SYM_FUNC_END(__host_hvc)
 .endm
 
 .macro host_el2_sync_vect
-	__host_el2_vect __hyp_panic
+	__host_el2_vect __hyp_save_context_and_panic
 .endm
 
 .macro invalid_host_el1_vect
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index 0550b9f6317f..6c64783c3e00 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -17,6 +17,7 @@
 
 #include <asm/barrier.h>
 #include <asm/cpufeature.h>
+#include <asm/esr.h>
 #include <asm/kprobes.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_emulate.h>
@@ -384,7 +385,24 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
 	return ret;
 }
 
-static void __noreturn __hyp_call_panic(u64 spsr, u64 elr, u64 par)
+static void __noreturn __hyp_call_panic_for_cfi(u64 elr, u64 esr)
+{
+	struct user_pt_regs *regs = &this_cpu_ptr(&kvm_hyp_ctxt)->regs;
+	u8 type_idx = FIELD_GET(CFI_BRK_IMM_TYPE, esr);
+	u8 target_idx = FIELD_GET(CFI_BRK_IMM_TARGET, esr);
+	u32 expected_type = (u32)regs->regs[type_idx];
+	u64 target = regs->regs[target_idx];
+
+	panic("VHE hyp CFI failure at: [<%016llx>] %pB (target: [<%016llx>] %ps, expected type: 0x%08x)\n"
+#ifdef CONFIG_CFI_PERMISSIVE
+	      " (CONFIG_CFI_PERMISSIVE ignored for hyp failures)\n"
+#endif
+	      ,
+	      elr, (void *)elr, target, (void *)target, expected_type);
+}
+NOKPROBE_SYMBOL(__hyp_call_panic_for_cfi);
+
+static void __noreturn __hyp_call_panic(u64 spsr, u64 elr, u64 par, u64 esr)
 {
 	struct kvm_cpu_context *host_ctxt;
 	struct kvm_vcpu *vcpu;
@@ -395,6 +413,9 @@ static void __noreturn __hyp_call_panic(u64 spsr, u64 elr, u64 par)
 	__deactivate_traps(vcpu);
 	sysreg_restore_host_state_vhe(host_ctxt);
 
+	if (IS_ENABLED(CONFIG_CFI_CLANG) && esr_is_cfi_brk(esr))
+		__hyp_call_panic_for_cfi(elr, esr);
+
 	panic("HYP panic:\nPS:%08llx PC:%016llx ESR:%08llx\nFAR:%016llx HPFAR:%016llx PAR:%016llx\nVCPU:%p\n",
 	      spsr, elr,
 	      read_sysreg_el2(SYS_ESR), read_sysreg_el2(SYS_FAR),
@@ -407,8 +428,9 @@ void __noreturn hyp_panic(void)
 	u64 spsr = read_sysreg_el2(SYS_SPSR);
 	u64 elr = read_sysreg_el2(SYS_ELR);
 	u64 par = read_sysreg_par();
+	u64 esr = read_sysreg_el2(SYS_ESR);
 
-	__hyp_call_panic(spsr, elr, par);
+	__hyp_call_panic(spsr, elr, par, esr);
 }
 
 asmlinkage void kvm_unexpected_el2_exception(void)
-- 
2.45.1.288.g0e0cd299f1-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 1%]

* [PATCH v4 13/13] KVM: arm64: nVHE: Support test module for hyp kCFI
  @ 2024-05-29 12:12  2%   ` Pierre-Clément Tosi
  2024-05-29 12:12  2%   ` Pierre-Clément Tosi
                     ` (7 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Extend support for the kCFI test module to nVHE by replicating the hooks
on the KVM_RUN handler path currently existing in VHE in the nVHE code,
exporting the equivalent callback targets for triggering built-in hyp
kCFI faults, and exposing a new CONFIG_HYP_CFI_TEST-only host HVC to
implement callback registration.

Update the test module to register the nVHE equivalent callback for test
case '1' (i.e. both EL2 hyp caller and callee are built-in) and document
that other cases are not supported outside of VHE, as they require EL2
symbols in the module, which is not currently supported for nVHE.

Note that a kernel in protected mode that doesn't support HYP_CFI_TEST
will prevent the module from registering nVHE callbacks both by not
exporting the necessary symbols (similar to VHE) but also by rejecting
the corresponding HVC, if the module tries to issue it directly.

Also note that the test module will run in pKVM (with HYP_CFI_TEST)
independently of other debug Kconfig flags but that not stacktrace will
be printed without PROTECTED_NVHE_STACKTRACE. This allows testing kCFI
under conditions closer to release builds, if desired.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/include/asm/kvm_asm.h     |  3 ++
 arch/arm64/include/asm/kvm_cfi.h     |  6 ++--
 arch/arm64/kvm/Kconfig               |  2 --
 arch/arm64/kvm/hyp/{vhe => }/cfi.c   |  0
 arch/arm64/kvm/hyp/nvhe/Makefile     |  1 +
 arch/arm64/kvm/hyp/nvhe/hyp-main.c   | 19 ++++++++++++
 arch/arm64/kvm/hyp/nvhe/switch.c     |  7 +++++
 arch/arm64/kvm/hyp/vhe/Makefile      |  2 +-
 arch/arm64/kvm/hyp_cfi_test.c        | 44 ++++++++++++++++++++++++----
 arch/arm64/kvm/hyp_cfi_test_module.c | 24 ++++++++-------
 10 files changed, 86 insertions(+), 22 deletions(-)
 rename arch/arm64/kvm/hyp/{vhe => }/cfi.c (100%)

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index a6330460d9e5..791054492920 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -79,6 +79,9 @@ enum __kvm_host_smccc_func {
 	__KVM_HOST_SMCCC_FUNC___pkvm_init_vm,
 	__KVM_HOST_SMCCC_FUNC___pkvm_init_vcpu,
 	__KVM_HOST_SMCCC_FUNC___pkvm_teardown_vm,
+#ifdef CONFIG_HYP_SUPPORTS_CFI_TEST
+	__KVM_HOST_SMCCC_FUNC___kvm_register_cfi_test_cb,
+#endif
 };
 
 #define DECLARE_KVM_VHE_SYM(sym)	extern char sym[]
diff --git a/arch/arm64/include/asm/kvm_cfi.h b/arch/arm64/include/asm/kvm_cfi.h
index 13cc7b19d838..ed6422eebce5 100644
--- a/arch/arm64/include/asm/kvm_cfi.h
+++ b/arch/arm64/include/asm/kvm_cfi.h
@@ -12,8 +12,8 @@
 
 #ifdef CONFIG_HYP_SUPPORTS_CFI_TEST
 
-int kvm_cfi_test_register_host_ctxt_cb(void (*cb)(void));
-int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void));
+int kvm_cfi_test_register_host_ctxt_cb(void (*vhe_cb)(void), void *nvhe_cb);
+int kvm_cfi_test_register_guest_ctxt_cb(void (*vhe_cb)(void), void *nvhe_cb);
 
 #else
 
@@ -31,6 +31,8 @@ static inline int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void))
 
 /* Symbols which the host can register as hyp callbacks; see <hyp/cfi.h>. */
 void hyp_trigger_builtin_cfi_fault(void);
+DECLARE_KVM_NVHE_SYM(hyp_trigger_builtin_cfi_fault);
 void hyp_builtin_cfi_fault_target(int unused);
+DECLARE_KVM_NVHE_SYM(hyp_builtin_cfi_fault_target);
 
 #endif /* __ARM64_KVM_CFI_H__ */
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index 5daa8079a120..715c85088c06 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -75,8 +75,6 @@ config HYP_CFI_TEST
 	  Say M here to also build a module which registers callbacks triggering
 	  faults and selected by userspace through its parameters.
 
-	  Note that this feature is currently only supported in VHE mode.
-
 	  If unsure, say N.
 
 config HYP_SUPPORTS_CFI_TEST
diff --git a/arch/arm64/kvm/hyp/vhe/cfi.c b/arch/arm64/kvm/hyp/cfi.c
similarity index 100%
rename from arch/arm64/kvm/hyp/vhe/cfi.c
rename to arch/arm64/kvm/hyp/cfi.c
diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index 782b34b004be..115aa8880260 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -25,6 +25,7 @@ hyp-obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o
 	 cache.o setup.o mm.o mem_protect.o sys_regs.o pkvm.o stacktrace.o ffa.o
 hyp-obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
 	 ../fpsimd.o ../hyp-entry.o ../exception.o ../pgtable.o
+hyp-obj-$(CONFIG_HYP_SUPPORTS_CFI_TEST) += ../cfi.o
 hyp-obj-$(CONFIG_LIST_HARDENED) += list_debug.o
 hyp-obj-y += $(lib-objs)
 
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index d5c48dc98f67..39ed06fbb190 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -5,6 +5,7 @@
  */
 
 #include <hyp/adjust_pc.h>
+#include <hyp/cfi.h>
 
 #include <asm/pgtable-types.h>
 #include <asm/kvm_asm.h>
@@ -13,6 +14,8 @@
 #include <asm/kvm_hyp.h>
 #include <asm/kvm_mmu.h>
 
+#include <linux/compiler.h>
+
 #include <nvhe/ffa.h>
 #include <nvhe/mem_protect.h>
 #include <nvhe/mm.h>
@@ -301,6 +304,19 @@ static void handle___pkvm_teardown_vm(struct kvm_cpu_context *host_ctxt)
 	cpu_reg(host_ctxt, 1) = __pkvm_teardown_vm(handle);
 }
 
+#ifndef CONFIG_HYP_SUPPORTS_CFI_TEST
+__always_unused
+#endif
+static void handle___kvm_register_cfi_test_cb(struct kvm_cpu_context *host_ctxt)
+{
+	DECLARE_REG(phys_addr_t, cb_phys, host_ctxt, 1);
+	DECLARE_REG(bool, in_host_ctxt, host_ctxt, 2);
+
+	void (*cb)(void) = cb_phys ? __hyp_va(cb_phys) : NULL;
+
+	cpu_reg(host_ctxt, 1) = __kvm_register_cfi_test_cb(cb, in_host_ctxt);
+}
+
 typedef void (*hcall_t)(struct kvm_cpu_context *);
 
 #define HANDLE_FUNC(x)	[__KVM_HOST_SMCCC_FUNC_##x] = (hcall_t)handle_##x
@@ -333,6 +349,9 @@ static const hcall_t host_hcall[] = {
 	HANDLE_FUNC(__pkvm_init_vm),
 	HANDLE_FUNC(__pkvm_init_vcpu),
 	HANDLE_FUNC(__pkvm_teardown_vm),
+#ifdef CONFIG_HYP_SUPPORTS_CFI_TEST
+	HANDLE_FUNC(__kvm_register_cfi_test_cb),
+#endif
 };
 
 static void handle_host_hcall(struct kvm_cpu_context *host_ctxt)
diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
index 6758cd905570..52d2fada9e19 100644
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@ -4,6 +4,7 @@
  * Author: Marc Zyngier <marc.zyngier@arm.com>
  */
 
+#include <hyp/cfi.h>
 #include <hyp/switch.h>
 #include <hyp/sysreg-sr.h>
 
@@ -249,6 +250,9 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
 	bool pmu_switch_needed;
 	u64 exit_code;
 
+	if (IS_ENABLED(CONFIG_HYP_SUPPORTS_CFI_TEST) && unlikely(hyp_test_host_ctxt_cfi))
+		hyp_test_host_ctxt_cfi();
+
 	/*
 	 * Having IRQs masked via PMR when entering the guest means the GIC
 	 * will not signal the CPU of interrupts of lower priority, and the
@@ -309,6 +313,9 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
 
 	__debug_switch_to_guest(vcpu);
 
+	if (IS_ENABLED(CONFIG_HYP_SUPPORTS_CFI_TEST) && unlikely(hyp_test_guest_ctxt_cfi))
+		hyp_test_guest_ctxt_cfi();
+
 	do {
 		/* Jump in the fire! */
 		exit_code = __guest_enter(vcpu);
diff --git a/arch/arm64/kvm/hyp/vhe/Makefile b/arch/arm64/kvm/hyp/vhe/Makefile
index 19ca584cc21e..951c8c00a685 100644
--- a/arch/arm64/kvm/hyp/vhe/Makefile
+++ b/arch/arm64/kvm/hyp/vhe/Makefile
@@ -9,4 +9,4 @@ ccflags-y := -D__KVM_VHE_HYPERVISOR__
 obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o
 obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
 	 ../fpsimd.o ../hyp-entry.o ../exception.o
-obj-$(CONFIG_HYP_SUPPORTS_CFI_TEST) += cfi.o
+obj-$(CONFIG_HYP_SUPPORTS_CFI_TEST) += ../cfi.o
diff --git a/arch/arm64/kvm/hyp_cfi_test.c b/arch/arm64/kvm/hyp_cfi_test.c
index da7b25ca1b1f..6a02b43c45f6 100644
--- a/arch/arm64/kvm/hyp_cfi_test.c
+++ b/arch/arm64/kvm/hyp_cfi_test.c
@@ -6,6 +6,7 @@
 #include <asm/kvm_asm.h>
 #include <asm/kvm_cfi.h>
 #include <asm/kvm_host.h>
+#include <asm/kvm_mmu.h>
 #include <asm/virt.h>
 
 #include <linux/export.h>
@@ -15,29 +16,60 @@
 /* For calling directly into the VHE hypervisor; see <hyp/cfi.h>. */
 int __kvm_register_cfi_test_cb(void (*)(void), bool);
 
-static int kvm_register_cfi_test_cb(void (*vhe_cb)(void), bool in_host_ctxt)
+static int kvm_register_nvhe_cfi_test_cb(void *cb, bool in_host_ctxt)
+{
+	extern void *kvm_nvhe_sym(hyp_test_host_ctxt_cfi);
+	extern void *kvm_nvhe_sym(hyp_test_guest_ctxt_cfi);
+
+	if (is_protected_kvm_enabled()) {
+		phys_addr_t cb_phys = cb ? virt_to_phys(cb) : 0;
+
+		/* Use HVC as only the hyp can modify its callback pointers. */
+		return kvm_call_hyp_nvhe(__kvm_register_cfi_test_cb, cb_phys,
+					 in_host_ctxt);
+	}
+
+	/*
+	 * In non-protected nVHE, the pKVM HVC is not available but the
+	 * hyp callback pointers can be accessed and modified directly.
+	 */
+	if (cb)
+		cb = kern_hyp_va(kvm_ksym_ref(cb));
+
+	if (in_host_ctxt)
+		kvm_nvhe_sym(hyp_test_host_ctxt_cfi) = cb;
+	else
+		kvm_nvhe_sym(hyp_test_guest_ctxt_cfi) = cb;
+
+	return 0;
+}
+
+static int kvm_register_cfi_test_cb(void (*vhe_cb)(void), void *nvhe_cb,
+				    bool in_host_ctxt)
 {
 	if (!is_hyp_mode_available())
 		return -ENXIO;
 
 	if (is_hyp_nvhe())
-		return -EOPNOTSUPP;
+		return kvm_register_nvhe_cfi_test_cb(nvhe_cb, in_host_ctxt);
 
 	return __kvm_register_cfi_test_cb(vhe_cb, in_host_ctxt);
 }
 
-int kvm_cfi_test_register_host_ctxt_cb(void (*cb)(void))
+int kvm_cfi_test_register_host_ctxt_cb(void (*vhe_cb)(void), void *nvhe_cb)
 {
-	return kvm_register_cfi_test_cb(cb, true);
+	return kvm_register_cfi_test_cb(vhe_cb, nvhe_cb, true);
 }
 EXPORT_SYMBOL(kvm_cfi_test_register_host_ctxt_cb);
 
-int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void))
+int kvm_cfi_test_register_guest_ctxt_cb(void (*vhe_cb)(void), void *nvhe_cb)
 {
-	return kvm_register_cfi_test_cb(cb, false);
+	return kvm_register_cfi_test_cb(vhe_cb, nvhe_cb, false);
 }
 EXPORT_SYMBOL(kvm_cfi_test_register_guest_ctxt_cb);
 
 /* Hypervisor callbacks for the test module to register. */
 EXPORT_SYMBOL(hyp_trigger_builtin_cfi_fault);
+EXPORT_SYMBOL(kvm_nvhe_sym(hyp_trigger_builtin_cfi_fault));
 EXPORT_SYMBOL(hyp_builtin_cfi_fault_target);
+EXPORT_SYMBOL(kvm_nvhe_sym(hyp_builtin_cfi_fault_target));
diff --git a/arch/arm64/kvm/hyp_cfi_test_module.c b/arch/arm64/kvm/hyp_cfi_test_module.c
index eeda4be4d3ef..63a5e99cb164 100644
--- a/arch/arm64/kvm/hyp_cfi_test_module.c
+++ b/arch/arm64/kvm/hyp_cfi_test_module.c
@@ -20,9 +20,9 @@ static int set_guest_mode(const char *val, const struct kernel_param *kp);
 #define M_DESC \
 	"\n\t0: none" \
 	"\n\t1: built-in caller & built-in callee" \
-	"\n\t2: built-in caller & module callee" \
-	"\n\t3: module caller & built-in callee" \
-	"\n\t4: module caller & module callee"
+	"\n\t2: built-in caller & module callee (VHE only)" \
+	"\n\t3: module caller & built-in callee (VHE only)" \
+	"\n\t4: module caller & module callee (VHE only)"
 
 static unsigned int host_mode;
 module_param_call(host, set_host_mode, param_get_uint, &host_mode, 0644);
@@ -40,7 +40,7 @@ static void hyp_cfi_module2module_test_target(int);
 static void hyp_cfi_builtin2module_test_target(int);
 
 static int set_param_mode(const char *val, const struct kernel_param *kp,
-			 int (*register_cb)(void (*)(void)))
+			 int (*register_cb)(void (*)(void), void *))
 {
 	unsigned int *mode = kp->arg;
 	int err;
@@ -51,15 +51,17 @@ static int set_param_mode(const char *val, const struct kernel_param *kp,
 
 	switch (*mode) {
 	case 0:
-		return register_cb(NULL);
+		return register_cb(NULL, NULL);
 	case 1:
-		return register_cb(hyp_trigger_builtin_cfi_fault);
+		return register_cb(hyp_trigger_builtin_cfi_fault,
+				   kvm_nvhe_sym(hyp_trigger_builtin_cfi_fault));
 	case 2:
-		return register_cb((void *)hyp_cfi_builtin2module_test_target);
+		return register_cb((void *)hyp_cfi_builtin2module_test_target,
+				   NULL);
 	case 3:
-		return register_cb(trigger_module2builtin_cfi_fault);
+		return register_cb(trigger_module2builtin_cfi_fault, NULL);
 	case 4:
-		return register_cb(trigger_module2module_cfi_fault);
+		return register_cb(trigger_module2module_cfi_fault, NULL);
 	default:
 		return -EINVAL;
 	}
@@ -79,11 +81,11 @@ static void __exit exit_hyp_cfi_test(void)
 {
 	int err;
 
-	err = kvm_cfi_test_register_host_ctxt_cb(NULL);
+	err = kvm_cfi_test_register_host_ctxt_cb(NULL, NULL);
 	if (err)
 		pr_err("Failed to unregister host context trigger: %d\n", err);
 
-	err = kvm_cfi_test_register_guest_ctxt_cb(NULL);
+	err = kvm_cfi_test_register_guest_ctxt_cb(NULL, NULL);
 	if (err)
 		pr_err("Failed to unregister guest context trigger: %d\n", err);
 }
-- 
2.45.1.288.g0e0cd299f1-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 2%]

* [PATCH v4 10/13] KVM: arm64: nVHE: Support CONFIG_CFI_CLANG at EL2
  @ 2024-05-29 12:12  2%   ` Pierre-Clément Tosi
  2024-05-29 12:12  2%   ` Pierre-Clément Tosi
                     ` (7 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

The compiler implements kCFI by adding type information (u32) above
every function that might be indirectly called and, whenever a function
pointer is called, injects a read-and-compare of that u32 against the
value corresponding to the expected type. In case of a mismatch, a BRK
instruction gets executed. When the hypervisor triggers such an
exception in nVHE, it panics and triggers and exception return to EL1.

Therefore, teach nvhe_hyp_panic_handler() to detect kCFI errors from the
ESR and report them. If necessary, remind the user that EL2 kCFI is not
affected by CONFIG_CFI_PERMISSIVE.

Pass $(CC_FLAGS_CFI) to the compiler when building the nVHE hyp code.

Use SYM_TYPED_FUNC_START() for __pkvm_init_switch_pgd, as nVHE can't
call it directly and must use a PA function pointer from C (because it
is part of the idmap page), which would trigger a kCFI failure if the
type ID wasn't present.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/kvm/handle_exit.c       | 10 ++++++++++
 arch/arm64/kvm/hyp/nvhe/Makefile   |  6 +++---
 arch/arm64/kvm/hyp/nvhe/hyp-init.S |  6 +++++-
 3 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index b3d6657a259d..69b08ac7322d 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -417,6 +417,14 @@ static void print_nvhe_hyp_panic(const char *name, u64 panic_addr)
 		(void *)(panic_addr + kaslr_offset()));
 }
 
+static void kvm_nvhe_report_cfi_failure(u64 panic_addr)
+{
+	print_nvhe_hyp_panic("CFI failure", panic_addr);
+
+	if (IS_ENABLED(CONFIG_CFI_PERMISSIVE))
+		kvm_err(" (CONFIG_CFI_PERMISSIVE ignored for hyp failures)\n");
+}
+
 void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
 					      u64 elr_virt, u64 elr_phys,
 					      u64 par, uintptr_t vcpu,
@@ -446,6 +454,8 @@ void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
 			kvm_err("nVHE hyp BUG at: %s:%u!\n", file, line);
 		else
 			print_nvhe_hyp_panic("BUG", panic_addr);
+	} else if (IS_ENABLED(CONFIG_CFI_CLANG) && esr_is_cfi_brk(esr)) {
+		kvm_nvhe_report_cfi_failure(panic_addr);
 	} else {
 		print_nvhe_hyp_panic("panic", panic_addr);
 	}
diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index 50fa0ffb6b7e..782b34b004be 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -89,9 +89,9 @@ quiet_cmd_hyprel = HYPREL  $@
 quiet_cmd_hypcopy = HYPCOPY $@
       cmd_hypcopy = $(OBJCOPY) --prefix-symbols=__kvm_nvhe_ $< $@
 
-# Remove ftrace, Shadow Call Stack, and CFI CFLAGS.
-# This is equivalent to the 'notrace', '__noscs', and '__nocfi' annotations.
-KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_FTRACE) $(CC_FLAGS_SCS) $(CC_FLAGS_CFI), $(KBUILD_CFLAGS))
+# Remove ftrace and Shadow Call Stack CFLAGS.
+# This is equivalent to the 'notrace' and '__noscs' annotations.
+KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_FTRACE) $(CC_FLAGS_SCS), $(KBUILD_CFLAGS))
 # Starting from 13.0.0 llvm emits SHT_REL section '.llvm.call-graph-profile'
 # when profile optimization is applied. gen-hyprel does not support SHT_REL and
 # causes a build failure. Remove profile optimization flags.
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index d859c4de06b6..b1c8977e2812 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -5,6 +5,7 @@
  */
 
 #include <linux/arm-smccc.h>
+#include <linux/cfi_types.h>
 #include <linux/linkage.h>
 
 #include <asm/alternative.h>
@@ -267,8 +268,11 @@ SYM_CODE_END(__kvm_handle_stub_hvc)
 
 /*
  * void __pkvm_init_switch_pgd(phys_addr_t pgd, void *sp, void (*fn)(void));
+ *
+ * SYM_TYPED_FUNC_START() allows C to call this ID-mapped function indirectly
+ * using a physical pointer without triggering a kCFI failure.
  */
-SYM_FUNC_START(__pkvm_init_switch_pgd)
+SYM_TYPED_FUNC_START(__pkvm_init_switch_pgd)
 	/* Turn the MMU off */
 	pre_disable_mmu_workaround
 	mrs	x9, sctlr_el2
-- 
2.45.1.288.g0e0cd299f1-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 2%]

* [PATCH v4 12/13] KVM: arm64: VHE: Add test module for hyp kCFI
  @ 2024-05-29 12:12  4%   ` Pierre-Clément Tosi
  2024-05-29 12:12  2%   ` Pierre-Clément Tosi
                     ` (7 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

In order to easily periodically (and potentially automatically) validate
that the hypervisor kCFI feature doesn't bitrot, introduce a way to
trigger hypervisor kCFI faults from userspace on test builds of KVM.

Add hooks in the hypervisor code to call registered callbacks (intended
to trigger kCFI faults either for the callback call itself of from
within the callback function) when running with guest or host VBAR_EL2.
As the calls are issued from the KVM_RUN ioctl handling path, userspace
gains control over when the actual triggering of the fault happens
without needing to modify the KVM uAPI.

Export kernel functions to register these callbacks from modules and
introduce a kernel module intended to contain any testing logic. By
limiting the changes to the core kernel to a strict minimum, this
architectural split allows tests to be updated (within the module)
without the need to redeploy (or recompile) the kernel (hyp) under test.

Use the module parameters as the uAPI for configuring the fault
condition being tested (i.e. either at insertion or post-insertion
using /sys/module/.../parameters), which naturally makes it impossible
for userspace to test kCFI without the module (and, inversely, makes
the module only - not KVM - responsible for exposing said uAPI).

As kCFI is implemented with a caller-side check of a callee-side value,
make the module support 4 tests based on the location of the caller and
callee (built-in or in-module), for each of the 2 hypervisor contexts
(host & guest), selected by userspace using the 'guest' or 'host' module
parameter. For this purpose, export symbols which the module can use to
configure the callbacks for in-kernel and module-to-built-in kCFI
faulting calls.

Define the module-to-kernel API to allow the module to detect that it
was loaded on a kernel built with support for it but which is running
without a hypervisor (-ENXIO) or with one that doesn't use the VHE CPU
feature (-EOPNOTSUPP), which is currently the only mode for which KVM
supports hypervisor kCFI.

Allow kernel build configs to set CONFIG_HYP_CFI_TEST to only support
the in-kernel hooks (=y) or also build the test module (=m). Use
intermediate internal Kconfig flags (CONFIG_HYP_SUPPORTS_CFI_TEST and
CONFIG_HYP_CFI_TEST_MODULE) to simplify the Makefiles and #ifdefs. As
the symbols for callback registration are only exported to modules when
CONFIG_HYP_CFI_TEST != n, it is impossible for the test module to be
non-forcefully inserted on a kernel that doesn't support it.

Note that this feature must NOT result in any noticeable change
(behavioral or binary size) when HYP_CFI_TEST_MODULE = n.

CONFIG_HYP_CFI_TEST is intentionally independent of CONFIG_CFI_CLANG, to
avoid arbitrarily limiting the number of flag combinations that can be
tested with the module.

Also note that, as VHE aliases VBAR_EL1 to VBAR_EL2 for the host,
testing hypervisor kCFI in VHE and in host context is equivalent to
testing kCFI support of the kernel itself i.e. EL1 in non-VHE and/or in
non-virtualized environments. For this reason, CONFIG_CFI_PERMISSIVE
**will** prevent the test module from triggering a hyp panic (although a
warning still gets printed) in that context.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/include/asm/kvm_cfi.h     |  36 ++++++++
 arch/arm64/kvm/Kconfig               |  22 +++++
 arch/arm64/kvm/Makefile              |   3 +
 arch/arm64/kvm/hyp/include/hyp/cfi.h |  47 ++++++++++
 arch/arm64/kvm/hyp/vhe/Makefile      |   1 +
 arch/arm64/kvm/hyp/vhe/cfi.c         |  37 ++++++++
 arch/arm64/kvm/hyp/vhe/switch.c      |   7 ++
 arch/arm64/kvm/hyp_cfi_test.c        |  43 +++++++++
 arch/arm64/kvm/hyp_cfi_test_module.c | 133 +++++++++++++++++++++++++++
 9 files changed, 329 insertions(+)
 create mode 100644 arch/arm64/include/asm/kvm_cfi.h
 create mode 100644 arch/arm64/kvm/hyp/include/hyp/cfi.h
 create mode 100644 arch/arm64/kvm/hyp/vhe/cfi.c
 create mode 100644 arch/arm64/kvm/hyp_cfi_test.c
 create mode 100644 arch/arm64/kvm/hyp_cfi_test_module.c

diff --git a/arch/arm64/include/asm/kvm_cfi.h b/arch/arm64/include/asm/kvm_cfi.h
new file mode 100644
index 000000000000..13cc7b19d838
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_cfi.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024 - Google Inc
+ * Author: Pierre-Clément Tosi <ptosi@google.com>
+ */
+
+#ifndef __ARM64_KVM_CFI_H__
+#define __ARM64_KVM_CFI_H__
+
+#include <asm/kvm_asm.h>
+#include <linux/errno.h>
+
+#ifdef CONFIG_HYP_SUPPORTS_CFI_TEST
+
+int kvm_cfi_test_register_host_ctxt_cb(void (*cb)(void));
+int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void));
+
+#else
+
+static inline int kvm_cfi_test_register_host_ctxt_cb(void (*cb)(void))
+{
+	return -EOPNOTSUPP;
+}
+
+static inline int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void))
+{
+	return -EOPNOTSUPP;
+}
+
+#endif /* CONFIG_HYP_SUPPORTS_CFI_TEST */
+
+/* Symbols which the host can register as hyp callbacks; see <hyp/cfi.h>. */
+void hyp_trigger_builtin_cfi_fault(void);
+void hyp_builtin_cfi_fault_target(int unused);
+
+#endif /* __ARM64_KVM_CFI_H__ */
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index 58f09370d17e..5daa8079a120 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -65,4 +65,26 @@ config PROTECTED_NVHE_STACKTRACE
 
 	  If unsure, or not using protected nVHE (pKVM), say N.
 
+config HYP_CFI_TEST
+	tristate "KVM hypervisor kCFI test support"
+	depends on KVM
+	help
+	  Say Y or M here to build KVM with test hooks to support intentionally
+	  triggering hypervisor kCFI faults in guest or host context.
+
+	  Say M here to also build a module which registers callbacks triggering
+	  faults and selected by userspace through its parameters.
+
+	  Note that this feature is currently only supported in VHE mode.
+
+	  If unsure, say N.
+
+config HYP_SUPPORTS_CFI_TEST
+	def_bool y
+	depends on HYP_CFI_TEST
+
+config HYP_CFI_TEST_MODULE
+	def_tristate m if HYP_CFI_TEST = m
+	depends on HYP_CFI_TEST
+
 endif # VIRTUALIZATION
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index a6497228c5a8..303be42ad90a 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -22,6 +22,7 @@ kvm-y += arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
 	 vgic/vgic-mmio-v3.o vgic/vgic-kvm-device.o \
 	 vgic/vgic-its.o vgic/vgic-debug.o
 
+kvm-$(CONFIG_HYP_SUPPORTS_CFI_TEST) += hyp_cfi_test.o
 kvm-$(CONFIG_HW_PERF_EVENTS)  += pmu-emul.o pmu.o
 kvm-$(CONFIG_ARM64_PTR_AUTH)  += pauth.o
 
@@ -40,3 +41,5 @@ $(obj)/hyp_constants.h: $(obj)/hyp-constants.s FORCE
 
 obj-kvm := $(addprefix $(obj)/, $(kvm-y))
 $(obj-kvm): $(obj)/hyp_constants.h
+
+obj-$(CONFIG_HYP_CFI_TEST_MODULE) += hyp_cfi_test_module.o
diff --git a/arch/arm64/kvm/hyp/include/hyp/cfi.h b/arch/arm64/kvm/hyp/include/hyp/cfi.h
new file mode 100644
index 000000000000..c6536040bc06
--- /dev/null
+++ b/arch/arm64/kvm/hyp/include/hyp/cfi.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024 - Google Inc
+ * Author: Pierre-Clément Tosi <ptosi@google.com>
+ */
+
+#ifndef __ARM64_KVM_HYP_CFI_H__
+#define __ARM64_KVM_HYP_CFI_H__
+
+#include <asm/bug.h>
+#include <asm/errno.h>
+
+#include <linux/compiler.h>
+
+#ifdef CONFIG_HYP_SUPPORTS_CFI_TEST
+
+int __kvm_register_cfi_test_cb(void (*cb)(void), bool in_host_ctxt);
+
+extern void (*hyp_test_host_ctxt_cfi)(void);
+extern void (*hyp_test_guest_ctxt_cfi)(void);
+
+/* Hypervisor callbacks for the host to register. */
+void hyp_trigger_builtin_cfi_fault(void);
+void hyp_builtin_cfi_fault_target(int unused);
+
+#else
+
+static inline
+int __kvm_register_cfi_test_cb(void (*cb)(void), bool in_host_ctxt)
+{
+	return -EOPNOTSUPP;
+}
+
+#define hyp_test_host_ctxt_cfi ((void(*)(void))(NULL))
+#define hyp_test_guest_ctxt_cfi ((void(*)(void))(NULL))
+
+static inline void hyp_trigger_builtin_cfi_fault(void)
+{
+}
+
+static inline void hyp_builtin_cfi_fault_target(int __always_unused unused)
+{
+}
+
+#endif /* CONFIG_HYP_SUPPORTS_CFI_TEST */
+
+#endif /* __ARM64_KVM_HYP_CFI_H__ */
diff --git a/arch/arm64/kvm/hyp/vhe/Makefile b/arch/arm64/kvm/hyp/vhe/Makefile
index 3b9e5464b5b3..19ca584cc21e 100644
--- a/arch/arm64/kvm/hyp/vhe/Makefile
+++ b/arch/arm64/kvm/hyp/vhe/Makefile
@@ -9,3 +9,4 @@ ccflags-y := -D__KVM_VHE_HYPERVISOR__
 obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o
 obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
 	 ../fpsimd.o ../hyp-entry.o ../exception.o
+obj-$(CONFIG_HYP_SUPPORTS_CFI_TEST) += cfi.o
diff --git a/arch/arm64/kvm/hyp/vhe/cfi.c b/arch/arm64/kvm/hyp/vhe/cfi.c
new file mode 100644
index 000000000000..5849f239e27f
--- /dev/null
+++ b/arch/arm64/kvm/hyp/vhe/cfi.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2024 - Google Inc
+ * Author: Pierre-Clément Tosi <ptosi@google.com>
+ */
+#include <asm/rwonce.h>
+
+#include <hyp/cfi.h>
+
+void (*hyp_test_host_ctxt_cfi)(void);
+void (*hyp_test_guest_ctxt_cfi)(void);
+
+int __kvm_register_cfi_test_cb(void (*cb)(void), bool in_host_ctxt)
+{
+	if (in_host_ctxt)
+		hyp_test_host_ctxt_cfi = cb;
+	else
+		hyp_test_guest_ctxt_cfi = cb;
+
+	return 0;
+}
+
+void hyp_builtin_cfi_fault_target(int __always_unused unused)
+{
+}
+
+void hyp_trigger_builtin_cfi_fault(void)
+{
+	/* Intentional UB cast & dereference, to trigger a kCFI fault. */
+	void (*target)(void) = (void *)&hyp_builtin_cfi_fault_target;
+
+	/*
+	 * READ_ONCE() prevents this indirect call from being optimized out,
+	 * forcing the compiler to generate the kCFI check before the branch.
+	 */
+	READ_ONCE(target)();
+}
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index 6c64783c3e00..fe70220876b4 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -4,6 +4,7 @@
  * Author: Marc Zyngier <marc.zyngier@arm.com>
  */
 
+#include <hyp/cfi.h>
 #include <hyp/switch.h>
 
 #include <linux/arm-smccc.h>
@@ -311,6 +312,9 @@ static int __kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
 	struct kvm_cpu_context *guest_ctxt;
 	u64 exit_code;
 
+	if (IS_ENABLED(CONFIG_HYP_SUPPORTS_CFI_TEST) && unlikely(hyp_test_host_ctxt_cfi))
+		hyp_test_host_ctxt_cfi();
+
 	host_ctxt = host_data_ptr(host_ctxt);
 	guest_ctxt = &vcpu->arch.ctxt;
 
@@ -329,6 +333,9 @@ static int __kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
 	sysreg_restore_guest_state_vhe(guest_ctxt);
 	__debug_switch_to_guest(vcpu);
 
+	if (IS_ENABLED(CONFIG_HYP_SUPPORTS_CFI_TEST) && unlikely(hyp_test_guest_ctxt_cfi))
+		hyp_test_guest_ctxt_cfi();
+
 	do {
 		/* Jump in the fire! */
 		exit_code = __guest_enter(vcpu);
diff --git a/arch/arm64/kvm/hyp_cfi_test.c b/arch/arm64/kvm/hyp_cfi_test.c
new file mode 100644
index 000000000000..da7b25ca1b1f
--- /dev/null
+++ b/arch/arm64/kvm/hyp_cfi_test.c
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2024 - Google Inc
+ * Author: Pierre-Clément Tosi <ptosi@google.com>
+ */
+#include <asm/kvm_asm.h>
+#include <asm/kvm_cfi.h>
+#include <asm/kvm_host.h>
+#include <asm/virt.h>
+
+#include <linux/export.h>
+#include <linux/stddef.h>
+#include <linux/types.h>
+
+/* For calling directly into the VHE hypervisor; see <hyp/cfi.h>. */
+int __kvm_register_cfi_test_cb(void (*)(void), bool);
+
+static int kvm_register_cfi_test_cb(void (*vhe_cb)(void), bool in_host_ctxt)
+{
+	if (!is_hyp_mode_available())
+		return -ENXIO;
+
+	if (is_hyp_nvhe())
+		return -EOPNOTSUPP;
+
+	return __kvm_register_cfi_test_cb(vhe_cb, in_host_ctxt);
+}
+
+int kvm_cfi_test_register_host_ctxt_cb(void (*cb)(void))
+{
+	return kvm_register_cfi_test_cb(cb, true);
+}
+EXPORT_SYMBOL(kvm_cfi_test_register_host_ctxt_cb);
+
+int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void))
+{
+	return kvm_register_cfi_test_cb(cb, false);
+}
+EXPORT_SYMBOL(kvm_cfi_test_register_guest_ctxt_cb);
+
+/* Hypervisor callbacks for the test module to register. */
+EXPORT_SYMBOL(hyp_trigger_builtin_cfi_fault);
+EXPORT_SYMBOL(hyp_builtin_cfi_fault_target);
diff --git a/arch/arm64/kvm/hyp_cfi_test_module.c b/arch/arm64/kvm/hyp_cfi_test_module.c
new file mode 100644
index 000000000000..eeda4be4d3ef
--- /dev/null
+++ b/arch/arm64/kvm/hyp_cfi_test_module.c
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2024 - Google Inc
+ * Author: Pierre-Clément Tosi <ptosi@google.com>
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <asm/kvm_asm.h>
+#include <asm/kvm_cfi.h>
+#include <asm/rwonce.h>
+
+#include <linux/init.h>
+#include <linux/kstrtox.h>
+#include <linux/module.h>
+#include <linux/printk.h>
+
+static int set_host_mode(const char *val, const struct kernel_param *kp);
+static int set_guest_mode(const char *val, const struct kernel_param *kp);
+
+#define M_DESC \
+	"\n\t0: none" \
+	"\n\t1: built-in caller & built-in callee" \
+	"\n\t2: built-in caller & module callee" \
+	"\n\t3: module caller & built-in callee" \
+	"\n\t4: module caller & module callee"
+
+static unsigned int host_mode;
+module_param_call(host, set_host_mode, param_get_uint, &host_mode, 0644);
+MODULE_PARM_DESC(host,
+		 "Hypervisor kCFI fault test case in host context:" M_DESC);
+
+static unsigned int guest_mode;
+module_param_call(guest, set_guest_mode, param_get_uint, &guest_mode, 0644);
+MODULE_PARM_DESC(guest,
+		 "Hypervisor kCFI fault test case in guest context:" M_DESC);
+
+static void trigger_module2module_cfi_fault(void);
+static void trigger_module2builtin_cfi_fault(void);
+static void hyp_cfi_module2module_test_target(int);
+static void hyp_cfi_builtin2module_test_target(int);
+
+static int set_param_mode(const char *val, const struct kernel_param *kp,
+			 int (*register_cb)(void (*)(void)))
+{
+	unsigned int *mode = kp->arg;
+	int err;
+
+	err = param_set_uint(val, kp);
+	if (err)
+		return err;
+
+	switch (*mode) {
+	case 0:
+		return register_cb(NULL);
+	case 1:
+		return register_cb(hyp_trigger_builtin_cfi_fault);
+	case 2:
+		return register_cb((void *)hyp_cfi_builtin2module_test_target);
+	case 3:
+		return register_cb(trigger_module2builtin_cfi_fault);
+	case 4:
+		return register_cb(trigger_module2module_cfi_fault);
+	default:
+		return -EINVAL;
+	}
+}
+
+static int set_host_mode(const char *val, const struct kernel_param *kp)
+{
+	return set_param_mode(val, kp, kvm_cfi_test_register_host_ctxt_cb);
+}
+
+static int set_guest_mode(const char *val, const struct kernel_param *kp)
+{
+	return set_param_mode(val, kp, kvm_cfi_test_register_guest_ctxt_cb);
+}
+
+static void __exit exit_hyp_cfi_test(void)
+{
+	int err;
+
+	err = kvm_cfi_test_register_host_ctxt_cb(NULL);
+	if (err)
+		pr_err("Failed to unregister host context trigger: %d\n", err);
+
+	err = kvm_cfi_test_register_guest_ctxt_cb(NULL);
+	if (err)
+		pr_err("Failed to unregister guest context trigger: %d\n", err);
+}
+module_exit(exit_hyp_cfi_test);
+
+static void trigger_module2builtin_cfi_fault(void)
+{
+	/* Intentional UB cast & dereference, to trigger a kCFI fault. */
+	void (*target)(void) = (void *)&hyp_builtin_cfi_fault_target;
+
+	/*
+	 * READ_ONCE() prevents this indirect call from being optimized out,
+	 * forcing the compiler to generate the kCFI check before the branch.
+	 */
+	READ_ONCE(target)();
+
+	pr_err_ratelimited("%s: Survived a kCFI violation\n", __func__);
+}
+
+static void trigger_module2module_cfi_fault(void)
+{
+	/* Intentional UB cast & dereference, to trigger a kCFI fault. */
+	void (*target)(void) = (void *)&hyp_cfi_module2module_test_target;
+
+	/*
+	 * READ_ONCE() prevents this indirect call from being optimized out,
+	 * forcing the compiler to generate the kCFI check before the branch.
+	 */
+	READ_ONCE(target)();
+
+	pr_err_ratelimited("%s: Survived a kCFI violation\n", __func__);
+}
+
+/* Use different functions, for clearer symbols in kCFI panic reports. */
+static noinline
+void hyp_cfi_module2module_test_target(int __always_unused unused)
+{
+}
+
+static noinline
+void hyp_cfi_builtin2module_test_target(int __always_unused unused)
+{
+}
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Pierre-Clément Tosi <ptosi@google.com>");
+MODULE_DESCRIPTION("KVM hypervisor kCFI test module");
-- 
2.45.1.288.g0e0cd299f1-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 4%]

* [PATCH v4 08/13] arm64: Introduce esr_comment() & esr_is_cfi_brk()
  @ 2024-05-29 12:12  5%   ` Pierre-Clément Tosi
  2024-05-29 12:12  2%   ` Pierre-Clément Tosi
                     ` (7 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

As it is already used in two places, move esr_comment() to a header for
re-use, with a clearer name.

Introduce esr_is_cfi_brk() to detect kCFI BRK syndromes, currently used
by early_brk64() but soon to be also used by hypervisor code.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/include/asm/esr.h       | 11 +++++++++++
 arch/arm64/kernel/debug-monitors.c |  4 +---
 arch/arm64/kernel/traps.c          |  8 +++-----
 arch/arm64/kvm/handle_exit.c       |  2 +-
 4 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 7abf09df7033..77569d207ecf 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -379,6 +379,11 @@
 #ifndef __ASSEMBLY__
 #include <asm/types.h>
 
+static inline unsigned long esr_brk_comment(unsigned long esr)
+{
+	return esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
+}
+
 static inline bool esr_is_data_abort(unsigned long esr)
 {
 	const unsigned long ec = ESR_ELx_EC(esr);
@@ -386,6 +391,12 @@ static inline bool esr_is_data_abort(unsigned long esr)
 	return ec == ESR_ELx_EC_DABT_LOW || ec == ESR_ELx_EC_DABT_CUR;
 }
 
+static inline bool esr_is_cfi_brk(unsigned long esr)
+{
+	return ESR_ELx_EC(esr) == ESR_ELx_EC_BRK64 &&
+	       (esr_brk_comment(esr) & ~CFI_BRK_IMM_MASK) == CFI_BRK_IMM_BASE;
+}
+
 static inline bool esr_fsc_is_translation_fault(unsigned long esr)
 {
 	/* Translation fault, level -1 */
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 64f2ecbdfe5c..024a7b245056 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -312,9 +312,7 @@ static int call_break_hook(struct pt_regs *regs, unsigned long esr)
 	 * entirely not preemptible, and we can use rcu list safely here.
 	 */
 	list_for_each_entry_rcu(hook, list, node) {
-		unsigned long comment = esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
-
-		if ((comment & ~hook->mask) == hook->imm)
+		if ((esr_brk_comment(esr) & ~hook->mask) == hook->imm)
 			fn = hook->fn;
 	}
 
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 215e6d7f2df8..9e22683aa921 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -1105,8 +1105,6 @@ static struct break_hook ubsan_break_hook = {
 };
 #endif
 
-#define esr_comment(esr) ((esr) & ESR_ELx_BRK64_ISS_COMMENT_MASK)
-
 /*
  * Initial handler for AArch64 BRK exceptions
  * This handler only used until debug_traps_init().
@@ -1115,15 +1113,15 @@ int __init early_brk64(unsigned long addr, unsigned long esr,
 		struct pt_regs *regs)
 {
 #ifdef CONFIG_CFI_CLANG
-	if ((esr_comment(esr) & ~CFI_BRK_IMM_MASK) == CFI_BRK_IMM_BASE)
+	if (esr_is_cfi_brk(esr))
 		return cfi_handler(regs, esr) != DBG_HOOK_HANDLED;
 #endif
 #ifdef CONFIG_KASAN_SW_TAGS
-	if ((esr_comment(esr) & ~KASAN_BRK_MASK) == KASAN_BRK_IMM)
+	if ((esr_brk_comment(esr) & ~KASAN_BRK_MASK) == KASAN_BRK_IMM)
 		return kasan_handler(regs, esr) != DBG_HOOK_HANDLED;
 #endif
 #ifdef CONFIG_UBSAN_TRAP
-	if ((esr_comment(esr) & ~UBSAN_BRK_MASK) == UBSAN_BRK_IMM)
+	if ((esr_brk_comment(esr) & ~UBSAN_BRK_MASK) == UBSAN_BRK_IMM)
 		return ubsan_handler(regs, esr) != DBG_HOOK_HANDLED;
 #endif
 	return bug_handler(regs, esr) != DBG_HOOK_HANDLED;
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index b037f0a0e27e..d41447193e13 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -423,7 +423,7 @@ void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
 	if (mode != PSR_MODE_EL2t && mode != PSR_MODE_EL2h) {
 		kvm_err("Invalid host exception to nVHE hyp!\n");
 	} else if (ESR_ELx_EC(esr) == ESR_ELx_EC_BRK64 &&
-		   (esr & ESR_ELx_BRK64_ISS_COMMENT_MASK) == BUG_BRK_IMM) {
+		   esr_brk_comment(esr) == BUG_BRK_IMM) {
 		const char *file = NULL;
 		unsigned int line = 0;
 
-- 
2.45.1.288.g0e0cd299f1-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 5%]

* [PATCH v4 07/13] KVM: arm64: VHE: Mark __hyp_call_panic __noreturn
  @ 2024-05-29 12:12  1%   ` Pierre-Clément Tosi
  2024-05-29 12:12  2%   ` Pierre-Clément Tosi
                     ` (7 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Given that the sole purpose of __hyp_call_panic() is to call panic(), a
__noreturn function, give it the __noreturn attribute, removing the need
for its caller to use unreachable().

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/kvm/hyp/vhe/switch.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index d7af5f46f22a..0550b9f6317f 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -384,7 +384,7 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
 	return ret;
 }
 
-static void __hyp_call_panic(u64 spsr, u64 elr, u64 par)
+static void __noreturn __hyp_call_panic(u64 spsr, u64 elr, u64 par)
 {
 	struct kvm_cpu_context *host_ctxt;
 	struct kvm_vcpu *vcpu;
@@ -409,7 +409,6 @@ void __noreturn hyp_panic(void)
 	u64 par = read_sysreg_par();
 
 	__hyp_call_panic(spsr, elr, par);
-	unreachable();
 }
 
 asmlinkage void kvm_unexpected_el2_exception(void)
-- 
2.45.1.288.g0e0cd299f1-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 1%]

* [PATCH v4 05/13] KVM: arm64: Rename __guest_exit_panic __hyp_panic
  @ 2024-05-29 12:12  2%   ` Pierre-Clément Tosi
  2024-05-29 12:12  2%   ` Pierre-Clément Tosi
                     ` (7 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Use a name that expresses the fact that the routine might not exit
through the guest but will always (directly or indirectly) end up
executing hyp_panic().

Use CPU_LR_OFFSET to clarify that the routine returns to hyp_panic().

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/kvm/hyp/entry.S              | 6 +++---
 arch/arm64/kvm/hyp/hyp-entry.S          | 2 +-
 arch/arm64/kvm/hyp/include/hyp/switch.h | 4 ++--
 arch/arm64/kvm/hyp/nvhe/host.S          | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
index 4433a234aa9b..343851c17373 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -83,7 +83,7 @@ alternative_else_nop_endif
 	eret
 	sb
 
-SYM_INNER_LABEL(__guest_exit_restore_elr_and_panic, SYM_L_GLOBAL)
+SYM_INNER_LABEL(__hyp_restore_elr_and_panic, SYM_L_GLOBAL)
 	// x2-x29,lr: vcpu regs
 	// vcpu x0-x1 on the stack
 
@@ -91,7 +91,7 @@ SYM_INNER_LABEL(__guest_exit_restore_elr_and_panic, SYM_L_GLOBAL)
 	ldr	x0, [x0, #CPU_ELR_EL2]
 	msr	elr_el2, x0
 
-SYM_INNER_LABEL(__guest_exit_panic, SYM_L_GLOBAL)
+SYM_INNER_LABEL(__hyp_panic, SYM_L_GLOBAL)
 	// x2-x29,lr: vcpu regs
 	// vcpu x0-x1 on the stack
 
@@ -109,7 +109,7 @@ SYM_INNER_LABEL(__guest_exit_panic, SYM_L_GLOBAL)
 	// accurate if the guest had been completely restored.
 	adr_this_cpu x0, kvm_hyp_ctxt, x1
 	adr_l	x1, hyp_panic
-	str	x1, [x0, #CPU_XREG_OFFSET(30)]
+	str	x1, [x0, #CPU_LR_OFFSET]
 
 	get_vcpu_ptr	x1, x0
 
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index 03f97d71984c..7e65ef738ec9 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -122,7 +122,7 @@ el2_error:
 	eret
 	sb
 
-.macro invalid_vector	label, target = __guest_exit_panic
+.macro invalid_vector	label, target = __hyp_panic
 	.align	2
 SYM_CODE_START_LOCAL(\label)
 	b \target
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index ed9a63f1f7bf..d9931abf14c2 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -689,7 +689,7 @@ static inline bool fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
 
 static inline void __kvm_unexpected_el2_exception(void)
 {
-	extern char __guest_exit_restore_elr_and_panic[];
+	extern char __hyp_restore_elr_and_panic[];
 	unsigned long addr, fixup;
 	struct kvm_exception_table_entry *entry, *end;
 	unsigned long elr_el2 = read_sysreg(elr_el2);
@@ -712,7 +712,7 @@ static inline void __kvm_unexpected_el2_exception(void)
 
 	/* Trigger a panic after restoring the hyp context. */
 	this_cpu_ptr(&kvm_hyp_ctxt)->sys_regs[ELR_EL2] = elr_el2;
-	write_sysreg(__guest_exit_restore_elr_and_panic, elr_el2);
+	write_sysreg(__hyp_restore_elr_and_panic, elr_el2);
 }
 
 #endif /* __ARM64_KVM_HYP_SWITCH_H__ */
diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index bc0a73d9fcd0..a7db40a51e4a 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -214,7 +214,7 @@ SYM_FUNC_END(__host_hvc)
 .endm
 
 .macro host_el2_sync_vect
-	__host_el2_vect __guest_exit_panic
+	__host_el2_vect __hyp_panic
 .endm
 
 .macro invalid_host_el1_vect
@@ -227,7 +227,7 @@ SYM_FUNC_END(__host_hvc)
 .endm
 
 .macro invalid_host_el2_vect
-	__host_el2_vect __guest_exit_panic
+	__host_el2_vect __hyp_panic
 .endm
 
 /*
-- 
2.45.1.288.g0e0cd299f1-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 2%]

* [PATCH v4 06/13] KVM: arm64: nVHE: gen-hyprel: Skip R_AARCH64_ABS32
  @ 2024-05-29 12:12  1%   ` Pierre-Clément Tosi
  2024-05-29 12:12  2%   ` Pierre-Clément Tosi
                     ` (7 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Ignore R_AARCH64_ABS32 relocations, instead of panicking, when emitting
the relocation table of the hypervisor. The toolchain might produce them
when generating function calls with kCFI to represent the 32-bit type ID
which can then be resolved across compilation units at link time.  These
are NOT actual 32-bit addresses and are therefore not needed in the
final (runtime) relocation table (which is unlikely to use 32-bit
absolute addresses for arm64 anyway).

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/kvm/hyp/nvhe/gen-hyprel.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c b/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
index 6bc88a756cb7..b63f4e1c1033 100644
--- a/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
+++ b/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
@@ -50,6 +50,9 @@
 #ifndef R_AARCH64_ABS64
 #define R_AARCH64_ABS64			257
 #endif
+#ifndef R_AARCH64_ABS32
+#define R_AARCH64_ABS32			258
+#endif
 #ifndef R_AARCH64_PREL64
 #define R_AARCH64_PREL64		260
 #endif
@@ -383,6 +386,9 @@ static void emit_rela_section(Elf64_Shdr *sh_rela)
 		case R_AARCH64_ABS64:
 			emit_rela_abs64(rela, sh_orig_name);
 			break;
+		/* Allow 32-bit absolute relocation, for kCFI type hashes. */
+		case R_AARCH64_ABS32:
+			break;
 		/* Allow position-relative data relocations. */
 		case R_AARCH64_PREL64:
 		case R_AARCH64_PREL32:
-- 
2.45.1.288.g0e0cd299f1-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 1%]

* [PATCH v4 04/13] KVM: arm64: nVHE: Add EL2h sync exception handler
  @ 2024-05-29 12:12  4%   ` Pierre-Clément Tosi
  2024-05-29 12:12  2%   ` Pierre-Clément Tosi
                     ` (7 subsequent siblings)
  8 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Introduce a handler for EL2h synchronous exceptions distinct from
handlers for other "invalid" exceptions when running with the nVHE host
vector. This will allow a future patch to handle kCFI (synchronous)
errors without affecting other classes of exceptions.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/kvm/hyp/nvhe/host.S | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index 71fb311b4c0e..bc0a73d9fcd0 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -183,7 +183,7 @@ SYM_FUNC_END(__host_hvc)
 .endif
 .endm
 
-.macro invalid_host_el2_vect
+.macro __host_el2_vect handler:req
 	.align 7
 
 	/*
@@ -203,7 +203,7 @@ SYM_FUNC_END(__host_hvc)
 	 * been partially clobbered by __host_enter.
 	 */
 	stp	x0, x1, [sp, #-16]!
-	b	__guest_exit_panic
+	b	\handler
 
 .L__hyp_sp_overflow\@:
 	/* Switch to the overflow stack */
@@ -213,6 +213,10 @@ SYM_FUNC_END(__host_hvc)
 	ASM_BUG()
 .endm
 
+.macro host_el2_sync_vect
+	__host_el2_vect __guest_exit_panic
+.endm
+
 .macro invalid_host_el1_vect
 	.align 7
 	mov	x0, xzr		/* restore_host = false */
@@ -222,6 +226,10 @@ SYM_FUNC_END(__host_hvc)
 	b	__hyp_do_panic
 .endm
 
+.macro invalid_host_el2_vect
+	__host_el2_vect __guest_exit_panic
+.endm
+
 /*
  * The host vector does not use an ESB instruction in order to avoid consuming
  * SErrors that should only be consumed by the host. Guest entry is deferred by
@@ -239,7 +247,7 @@ SYM_CODE_START(__kvm_hyp_host_vector)
 	invalid_host_el2_vect			// FIQ EL2t
 	invalid_host_el2_vect			// Error EL2t
 
-	invalid_host_el2_vect			// Synchronous EL2h
+	host_el2_sync_vect			// Synchronous EL2h
 	invalid_host_el2_vect			// IRQ EL2h
 	invalid_host_el2_vect			// FIQ EL2h
 	invalid_host_el2_vect			// Error EL2h
-- 
2.45.1.288.g0e0cd299f1-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related	[relevance 4%]

* [PATCH v4 13/13] KVM: arm64: nVHE: Support test module for hyp kCFI
@ 2024-05-29 12:12  2%   ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Extend support for the kCFI test module to nVHE by replicating the hooks
on the KVM_RUN handler path currently existing in VHE in the nVHE code,
exporting the equivalent callback targets for triggering built-in hyp
kCFI faults, and exposing a new CONFIG_HYP_CFI_TEST-only host HVC to
implement callback registration.

Update the test module to register the nVHE equivalent callback for test
case '1' (i.e. both EL2 hyp caller and callee are built-in) and document
that other cases are not supported outside of VHE, as they require EL2
symbols in the module, which is not currently supported for nVHE.

Note that a kernel in protected mode that doesn't support HYP_CFI_TEST
will prevent the module from registering nVHE callbacks both by not
exporting the necessary symbols (similar to VHE) but also by rejecting
the corresponding HVC, if the module tries to issue it directly.

Also note that the test module will run in pKVM (with HYP_CFI_TEST)
independently of other debug Kconfig flags but that not stacktrace will
be printed without PROTECTED_NVHE_STACKTRACE. This allows testing kCFI
under conditions closer to release builds, if desired.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/include/asm/kvm_asm.h     |  3 ++
 arch/arm64/include/asm/kvm_cfi.h     |  6 ++--
 arch/arm64/kvm/Kconfig               |  2 --
 arch/arm64/kvm/hyp/{vhe => }/cfi.c   |  0
 arch/arm64/kvm/hyp/nvhe/Makefile     |  1 +
 arch/arm64/kvm/hyp/nvhe/hyp-main.c   | 19 ++++++++++++
 arch/arm64/kvm/hyp/nvhe/switch.c     |  7 +++++
 arch/arm64/kvm/hyp/vhe/Makefile      |  2 +-
 arch/arm64/kvm/hyp_cfi_test.c        | 44 ++++++++++++++++++++++++----
 arch/arm64/kvm/hyp_cfi_test_module.c | 24 ++++++++-------
 10 files changed, 86 insertions(+), 22 deletions(-)
 rename arch/arm64/kvm/hyp/{vhe => }/cfi.c (100%)

diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index a6330460d9e5..791054492920 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -79,6 +79,9 @@ enum __kvm_host_smccc_func {
 	__KVM_HOST_SMCCC_FUNC___pkvm_init_vm,
 	__KVM_HOST_SMCCC_FUNC___pkvm_init_vcpu,
 	__KVM_HOST_SMCCC_FUNC___pkvm_teardown_vm,
+#ifdef CONFIG_HYP_SUPPORTS_CFI_TEST
+	__KVM_HOST_SMCCC_FUNC___kvm_register_cfi_test_cb,
+#endif
 };
 
 #define DECLARE_KVM_VHE_SYM(sym)	extern char sym[]
diff --git a/arch/arm64/include/asm/kvm_cfi.h b/arch/arm64/include/asm/kvm_cfi.h
index 13cc7b19d838..ed6422eebce5 100644
--- a/arch/arm64/include/asm/kvm_cfi.h
+++ b/arch/arm64/include/asm/kvm_cfi.h
@@ -12,8 +12,8 @@
 
 #ifdef CONFIG_HYP_SUPPORTS_CFI_TEST
 
-int kvm_cfi_test_register_host_ctxt_cb(void (*cb)(void));
-int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void));
+int kvm_cfi_test_register_host_ctxt_cb(void (*vhe_cb)(void), void *nvhe_cb);
+int kvm_cfi_test_register_guest_ctxt_cb(void (*vhe_cb)(void), void *nvhe_cb);
 
 #else
 
@@ -31,6 +31,8 @@ static inline int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void))
 
 /* Symbols which the host can register as hyp callbacks; see <hyp/cfi.h>. */
 void hyp_trigger_builtin_cfi_fault(void);
+DECLARE_KVM_NVHE_SYM(hyp_trigger_builtin_cfi_fault);
 void hyp_builtin_cfi_fault_target(int unused);
+DECLARE_KVM_NVHE_SYM(hyp_builtin_cfi_fault_target);
 
 #endif /* __ARM64_KVM_CFI_H__ */
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index 5daa8079a120..715c85088c06 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -75,8 +75,6 @@ config HYP_CFI_TEST
 	  Say M here to also build a module which registers callbacks triggering
 	  faults and selected by userspace through its parameters.
 
-	  Note that this feature is currently only supported in VHE mode.
-
 	  If unsure, say N.
 
 config HYP_SUPPORTS_CFI_TEST
diff --git a/arch/arm64/kvm/hyp/vhe/cfi.c b/arch/arm64/kvm/hyp/cfi.c
similarity index 100%
rename from arch/arm64/kvm/hyp/vhe/cfi.c
rename to arch/arm64/kvm/hyp/cfi.c
diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index 782b34b004be..115aa8880260 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -25,6 +25,7 @@ hyp-obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o
 	 cache.o setup.o mm.o mem_protect.o sys_regs.o pkvm.o stacktrace.o ffa.o
 hyp-obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
 	 ../fpsimd.o ../hyp-entry.o ../exception.o ../pgtable.o
+hyp-obj-$(CONFIG_HYP_SUPPORTS_CFI_TEST) += ../cfi.o
 hyp-obj-$(CONFIG_LIST_HARDENED) += list_debug.o
 hyp-obj-y += $(lib-objs)
 
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index d5c48dc98f67..39ed06fbb190 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -5,6 +5,7 @@
  */
 
 #include <hyp/adjust_pc.h>
+#include <hyp/cfi.h>
 
 #include <asm/pgtable-types.h>
 #include <asm/kvm_asm.h>
@@ -13,6 +14,8 @@
 #include <asm/kvm_hyp.h>
 #include <asm/kvm_mmu.h>
 
+#include <linux/compiler.h>
+
 #include <nvhe/ffa.h>
 #include <nvhe/mem_protect.h>
 #include <nvhe/mm.h>
@@ -301,6 +304,19 @@ static void handle___pkvm_teardown_vm(struct kvm_cpu_context *host_ctxt)
 	cpu_reg(host_ctxt, 1) = __pkvm_teardown_vm(handle);
 }
 
+#ifndef CONFIG_HYP_SUPPORTS_CFI_TEST
+__always_unused
+#endif
+static void handle___kvm_register_cfi_test_cb(struct kvm_cpu_context *host_ctxt)
+{
+	DECLARE_REG(phys_addr_t, cb_phys, host_ctxt, 1);
+	DECLARE_REG(bool, in_host_ctxt, host_ctxt, 2);
+
+	void (*cb)(void) = cb_phys ? __hyp_va(cb_phys) : NULL;
+
+	cpu_reg(host_ctxt, 1) = __kvm_register_cfi_test_cb(cb, in_host_ctxt);
+}
+
 typedef void (*hcall_t)(struct kvm_cpu_context *);
 
 #define HANDLE_FUNC(x)	[__KVM_HOST_SMCCC_FUNC_##x] = (hcall_t)handle_##x
@@ -333,6 +349,9 @@ static const hcall_t host_hcall[] = {
 	HANDLE_FUNC(__pkvm_init_vm),
 	HANDLE_FUNC(__pkvm_init_vcpu),
 	HANDLE_FUNC(__pkvm_teardown_vm),
+#ifdef CONFIG_HYP_SUPPORTS_CFI_TEST
+	HANDLE_FUNC(__kvm_register_cfi_test_cb),
+#endif
 };
 
 static void handle_host_hcall(struct kvm_cpu_context *host_ctxt)
diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
index 6758cd905570..52d2fada9e19 100644
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@ -4,6 +4,7 @@
  * Author: Marc Zyngier <marc.zyngier@arm.com>
  */
 
+#include <hyp/cfi.h>
 #include <hyp/switch.h>
 #include <hyp/sysreg-sr.h>
 
@@ -249,6 +250,9 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
 	bool pmu_switch_needed;
 	u64 exit_code;
 
+	if (IS_ENABLED(CONFIG_HYP_SUPPORTS_CFI_TEST) && unlikely(hyp_test_host_ctxt_cfi))
+		hyp_test_host_ctxt_cfi();
+
 	/*
 	 * Having IRQs masked via PMR when entering the guest means the GIC
 	 * will not signal the CPU of interrupts of lower priority, and the
@@ -309,6 +313,9 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
 
 	__debug_switch_to_guest(vcpu);
 
+	if (IS_ENABLED(CONFIG_HYP_SUPPORTS_CFI_TEST) && unlikely(hyp_test_guest_ctxt_cfi))
+		hyp_test_guest_ctxt_cfi();
+
 	do {
 		/* Jump in the fire! */
 		exit_code = __guest_enter(vcpu);
diff --git a/arch/arm64/kvm/hyp/vhe/Makefile b/arch/arm64/kvm/hyp/vhe/Makefile
index 19ca584cc21e..951c8c00a685 100644
--- a/arch/arm64/kvm/hyp/vhe/Makefile
+++ b/arch/arm64/kvm/hyp/vhe/Makefile
@@ -9,4 +9,4 @@ ccflags-y := -D__KVM_VHE_HYPERVISOR__
 obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o
 obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
 	 ../fpsimd.o ../hyp-entry.o ../exception.o
-obj-$(CONFIG_HYP_SUPPORTS_CFI_TEST) += cfi.o
+obj-$(CONFIG_HYP_SUPPORTS_CFI_TEST) += ../cfi.o
diff --git a/arch/arm64/kvm/hyp_cfi_test.c b/arch/arm64/kvm/hyp_cfi_test.c
index da7b25ca1b1f..6a02b43c45f6 100644
--- a/arch/arm64/kvm/hyp_cfi_test.c
+++ b/arch/arm64/kvm/hyp_cfi_test.c
@@ -6,6 +6,7 @@
 #include <asm/kvm_asm.h>
 #include <asm/kvm_cfi.h>
 #include <asm/kvm_host.h>
+#include <asm/kvm_mmu.h>
 #include <asm/virt.h>
 
 #include <linux/export.h>
@@ -15,29 +16,60 @@
 /* For calling directly into the VHE hypervisor; see <hyp/cfi.h>. */
 int __kvm_register_cfi_test_cb(void (*)(void), bool);
 
-static int kvm_register_cfi_test_cb(void (*vhe_cb)(void), bool in_host_ctxt)
+static int kvm_register_nvhe_cfi_test_cb(void *cb, bool in_host_ctxt)
+{
+	extern void *kvm_nvhe_sym(hyp_test_host_ctxt_cfi);
+	extern void *kvm_nvhe_sym(hyp_test_guest_ctxt_cfi);
+
+	if (is_protected_kvm_enabled()) {
+		phys_addr_t cb_phys = cb ? virt_to_phys(cb) : 0;
+
+		/* Use HVC as only the hyp can modify its callback pointers. */
+		return kvm_call_hyp_nvhe(__kvm_register_cfi_test_cb, cb_phys,
+					 in_host_ctxt);
+	}
+
+	/*
+	 * In non-protected nVHE, the pKVM HVC is not available but the
+	 * hyp callback pointers can be accessed and modified directly.
+	 */
+	if (cb)
+		cb = kern_hyp_va(kvm_ksym_ref(cb));
+
+	if (in_host_ctxt)
+		kvm_nvhe_sym(hyp_test_host_ctxt_cfi) = cb;
+	else
+		kvm_nvhe_sym(hyp_test_guest_ctxt_cfi) = cb;
+
+	return 0;
+}
+
+static int kvm_register_cfi_test_cb(void (*vhe_cb)(void), void *nvhe_cb,
+				    bool in_host_ctxt)
 {
 	if (!is_hyp_mode_available())
 		return -ENXIO;
 
 	if (is_hyp_nvhe())
-		return -EOPNOTSUPP;
+		return kvm_register_nvhe_cfi_test_cb(nvhe_cb, in_host_ctxt);
 
 	return __kvm_register_cfi_test_cb(vhe_cb, in_host_ctxt);
 }
 
-int kvm_cfi_test_register_host_ctxt_cb(void (*cb)(void))
+int kvm_cfi_test_register_host_ctxt_cb(void (*vhe_cb)(void), void *nvhe_cb)
 {
-	return kvm_register_cfi_test_cb(cb, true);
+	return kvm_register_cfi_test_cb(vhe_cb, nvhe_cb, true);
 }
 EXPORT_SYMBOL(kvm_cfi_test_register_host_ctxt_cb);
 
-int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void))
+int kvm_cfi_test_register_guest_ctxt_cb(void (*vhe_cb)(void), void *nvhe_cb)
 {
-	return kvm_register_cfi_test_cb(cb, false);
+	return kvm_register_cfi_test_cb(vhe_cb, nvhe_cb, false);
 }
 EXPORT_SYMBOL(kvm_cfi_test_register_guest_ctxt_cb);
 
 /* Hypervisor callbacks for the test module to register. */
 EXPORT_SYMBOL(hyp_trigger_builtin_cfi_fault);
+EXPORT_SYMBOL(kvm_nvhe_sym(hyp_trigger_builtin_cfi_fault));
 EXPORT_SYMBOL(hyp_builtin_cfi_fault_target);
+EXPORT_SYMBOL(kvm_nvhe_sym(hyp_builtin_cfi_fault_target));
diff --git a/arch/arm64/kvm/hyp_cfi_test_module.c b/arch/arm64/kvm/hyp_cfi_test_module.c
index eeda4be4d3ef..63a5e99cb164 100644
--- a/arch/arm64/kvm/hyp_cfi_test_module.c
+++ b/arch/arm64/kvm/hyp_cfi_test_module.c
@@ -20,9 +20,9 @@ static int set_guest_mode(const char *val, const struct kernel_param *kp);
 #define M_DESC \
 	"\n\t0: none" \
 	"\n\t1: built-in caller & built-in callee" \
-	"\n\t2: built-in caller & module callee" \
-	"\n\t3: module caller & built-in callee" \
-	"\n\t4: module caller & module callee"
+	"\n\t2: built-in caller & module callee (VHE only)" \
+	"\n\t3: module caller & built-in callee (VHE only)" \
+	"\n\t4: module caller & module callee (VHE only)"
 
 static unsigned int host_mode;
 module_param_call(host, set_host_mode, param_get_uint, &host_mode, 0644);
@@ -40,7 +40,7 @@ static void hyp_cfi_module2module_test_target(int);
 static void hyp_cfi_builtin2module_test_target(int);
 
 static int set_param_mode(const char *val, const struct kernel_param *kp,
-			 int (*register_cb)(void (*)(void)))
+			 int (*register_cb)(void (*)(void), void *))
 {
 	unsigned int *mode = kp->arg;
 	int err;
@@ -51,15 +51,17 @@ static int set_param_mode(const char *val, const struct kernel_param *kp,
 
 	switch (*mode) {
 	case 0:
-		return register_cb(NULL);
+		return register_cb(NULL, NULL);
 	case 1:
-		return register_cb(hyp_trigger_builtin_cfi_fault);
+		return register_cb(hyp_trigger_builtin_cfi_fault,
+				   kvm_nvhe_sym(hyp_trigger_builtin_cfi_fault));
 	case 2:
-		return register_cb((void *)hyp_cfi_builtin2module_test_target);
+		return register_cb((void *)hyp_cfi_builtin2module_test_target,
+				   NULL);
 	case 3:
-		return register_cb(trigger_module2builtin_cfi_fault);
+		return register_cb(trigger_module2builtin_cfi_fault, NULL);
 	case 4:
-		return register_cb(trigger_module2module_cfi_fault);
+		return register_cb(trigger_module2module_cfi_fault, NULL);
 	default:
 		return -EINVAL;
 	}
@@ -79,11 +81,11 @@ static void __exit exit_hyp_cfi_test(void)
 {
 	int err;
 
-	err = kvm_cfi_test_register_host_ctxt_cb(NULL);
+	err = kvm_cfi_test_register_host_ctxt_cb(NULL, NULL);
 	if (err)
 		pr_err("Failed to unregister host context trigger: %d\n", err);
 
-	err = kvm_cfi_test_register_guest_ctxt_cb(NULL);
+	err = kvm_cfi_test_register_guest_ctxt_cb(NULL, NULL);
 	if (err)
 		pr_err("Failed to unregister guest context trigger: %d\n", err);
 }
-- 
2.45.1.288.g0e0cd299f1-goog


^ permalink raw reply related	[relevance 2%]

* [PATCH v4 12/13] KVM: arm64: VHE: Add test module for hyp kCFI
@ 2024-05-29 12:12  4%   ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

In order to easily periodically (and potentially automatically) validate
that the hypervisor kCFI feature doesn't bitrot, introduce a way to
trigger hypervisor kCFI faults from userspace on test builds of KVM.

Add hooks in the hypervisor code to call registered callbacks (intended
to trigger kCFI faults either for the callback call itself of from
within the callback function) when running with guest or host VBAR_EL2.
As the calls are issued from the KVM_RUN ioctl handling path, userspace
gains control over when the actual triggering of the fault happens
without needing to modify the KVM uAPI.

Export kernel functions to register these callbacks from modules and
introduce a kernel module intended to contain any testing logic. By
limiting the changes to the core kernel to a strict minimum, this
architectural split allows tests to be updated (within the module)
without the need to redeploy (or recompile) the kernel (hyp) under test.

Use the module parameters as the uAPI for configuring the fault
condition being tested (i.e. either at insertion or post-insertion
using /sys/module/.../parameters), which naturally makes it impossible
for userspace to test kCFI without the module (and, inversely, makes
the module only - not KVM - responsible for exposing said uAPI).

As kCFI is implemented with a caller-side check of a callee-side value,
make the module support 4 tests based on the location of the caller and
callee (built-in or in-module), for each of the 2 hypervisor contexts
(host & guest), selected by userspace using the 'guest' or 'host' module
parameter. For this purpose, export symbols which the module can use to
configure the callbacks for in-kernel and module-to-built-in kCFI
faulting calls.

Define the module-to-kernel API to allow the module to detect that it
was loaded on a kernel built with support for it but which is running
without a hypervisor (-ENXIO) or with one that doesn't use the VHE CPU
feature (-EOPNOTSUPP), which is currently the only mode for which KVM
supports hypervisor kCFI.

Allow kernel build configs to set CONFIG_HYP_CFI_TEST to only support
the in-kernel hooks (=y) or also build the test module (=m). Use
intermediate internal Kconfig flags (CONFIG_HYP_SUPPORTS_CFI_TEST and
CONFIG_HYP_CFI_TEST_MODULE) to simplify the Makefiles and #ifdefs. As
the symbols for callback registration are only exported to modules when
CONFIG_HYP_CFI_TEST != n, it is impossible for the test module to be
non-forcefully inserted on a kernel that doesn't support it.

Note that this feature must NOT result in any noticeable change
(behavioral or binary size) when HYP_CFI_TEST_MODULE = n.

CONFIG_HYP_CFI_TEST is intentionally independent of CONFIG_CFI_CLANG, to
avoid arbitrarily limiting the number of flag combinations that can be
tested with the module.

Also note that, as VHE aliases VBAR_EL1 to VBAR_EL2 for the host,
testing hypervisor kCFI in VHE and in host context is equivalent to
testing kCFI support of the kernel itself i.e. EL1 in non-VHE and/or in
non-virtualized environments. For this reason, CONFIG_CFI_PERMISSIVE
**will** prevent the test module from triggering a hyp panic (although a
warning still gets printed) in that context.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/include/asm/kvm_cfi.h     |  36 ++++++++
 arch/arm64/kvm/Kconfig               |  22 +++++
 arch/arm64/kvm/Makefile              |   3 +
 arch/arm64/kvm/hyp/include/hyp/cfi.h |  47 ++++++++++
 arch/arm64/kvm/hyp/vhe/Makefile      |   1 +
 arch/arm64/kvm/hyp/vhe/cfi.c         |  37 ++++++++
 arch/arm64/kvm/hyp/vhe/switch.c      |   7 ++
 arch/arm64/kvm/hyp_cfi_test.c        |  43 +++++++++
 arch/arm64/kvm/hyp_cfi_test_module.c | 133 +++++++++++++++++++++++++++
 9 files changed, 329 insertions(+)
 create mode 100644 arch/arm64/include/asm/kvm_cfi.h
 create mode 100644 arch/arm64/kvm/hyp/include/hyp/cfi.h
 create mode 100644 arch/arm64/kvm/hyp/vhe/cfi.c
 create mode 100644 arch/arm64/kvm/hyp_cfi_test.c
 create mode 100644 arch/arm64/kvm/hyp_cfi_test_module.c

diff --git a/arch/arm64/include/asm/kvm_cfi.h b/arch/arm64/include/asm/kvm_cfi.h
new file mode 100644
index 000000000000..13cc7b19d838
--- /dev/null
+++ b/arch/arm64/include/asm/kvm_cfi.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024 - Google Inc
+ * Author: Pierre-Clément Tosi <ptosi@google.com>
+ */
+
+#ifndef __ARM64_KVM_CFI_H__
+#define __ARM64_KVM_CFI_H__
+
+#include <asm/kvm_asm.h>
+#include <linux/errno.h>
+
+#ifdef CONFIG_HYP_SUPPORTS_CFI_TEST
+
+int kvm_cfi_test_register_host_ctxt_cb(void (*cb)(void));
+int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void));
+
+#else
+
+static inline int kvm_cfi_test_register_host_ctxt_cb(void (*cb)(void))
+{
+	return -EOPNOTSUPP;
+}
+
+static inline int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void))
+{
+	return -EOPNOTSUPP;
+}
+
+#endif /* CONFIG_HYP_SUPPORTS_CFI_TEST */
+
+/* Symbols which the host can register as hyp callbacks; see <hyp/cfi.h>. */
+void hyp_trigger_builtin_cfi_fault(void);
+void hyp_builtin_cfi_fault_target(int unused);
+
+#endif /* __ARM64_KVM_CFI_H__ */
diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig
index 58f09370d17e..5daa8079a120 100644
--- a/arch/arm64/kvm/Kconfig
+++ b/arch/arm64/kvm/Kconfig
@@ -65,4 +65,26 @@ config PROTECTED_NVHE_STACKTRACE
 
 	  If unsure, or not using protected nVHE (pKVM), say N.
 
+config HYP_CFI_TEST
+	tristate "KVM hypervisor kCFI test support"
+	depends on KVM
+	help
+	  Say Y or M here to build KVM with test hooks to support intentionally
+	  triggering hypervisor kCFI faults in guest or host context.
+
+	  Say M here to also build a module which registers callbacks triggering
+	  faults and selected by userspace through its parameters.
+
+	  Note that this feature is currently only supported in VHE mode.
+
+	  If unsure, say N.
+
+config HYP_SUPPORTS_CFI_TEST
+	def_bool y
+	depends on HYP_CFI_TEST
+
+config HYP_CFI_TEST_MODULE
+	def_tristate m if HYP_CFI_TEST = m
+	depends on HYP_CFI_TEST
+
 endif # VIRTUALIZATION
diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
index a6497228c5a8..303be42ad90a 100644
--- a/arch/arm64/kvm/Makefile
+++ b/arch/arm64/kvm/Makefile
@@ -22,6 +22,7 @@ kvm-y += arm.o mmu.o mmio.o psci.o hypercalls.o pvtime.o \
 	 vgic/vgic-mmio-v3.o vgic/vgic-kvm-device.o \
 	 vgic/vgic-its.o vgic/vgic-debug.o
 
+kvm-$(CONFIG_HYP_SUPPORTS_CFI_TEST) += hyp_cfi_test.o
 kvm-$(CONFIG_HW_PERF_EVENTS)  += pmu-emul.o pmu.o
 kvm-$(CONFIG_ARM64_PTR_AUTH)  += pauth.o
 
@@ -40,3 +41,5 @@ $(obj)/hyp_constants.h: $(obj)/hyp-constants.s FORCE
 
 obj-kvm := $(addprefix $(obj)/, $(kvm-y))
 $(obj-kvm): $(obj)/hyp_constants.h
+
+obj-$(CONFIG_HYP_CFI_TEST_MODULE) += hyp_cfi_test_module.o
diff --git a/arch/arm64/kvm/hyp/include/hyp/cfi.h b/arch/arm64/kvm/hyp/include/hyp/cfi.h
new file mode 100644
index 000000000000..c6536040bc06
--- /dev/null
+++ b/arch/arm64/kvm/hyp/include/hyp/cfi.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2024 - Google Inc
+ * Author: Pierre-Clément Tosi <ptosi@google.com>
+ */
+
+#ifndef __ARM64_KVM_HYP_CFI_H__
+#define __ARM64_KVM_HYP_CFI_H__
+
+#include <asm/bug.h>
+#include <asm/errno.h>
+
+#include <linux/compiler.h>
+
+#ifdef CONFIG_HYP_SUPPORTS_CFI_TEST
+
+int __kvm_register_cfi_test_cb(void (*cb)(void), bool in_host_ctxt);
+
+extern void (*hyp_test_host_ctxt_cfi)(void);
+extern void (*hyp_test_guest_ctxt_cfi)(void);
+
+/* Hypervisor callbacks for the host to register. */
+void hyp_trigger_builtin_cfi_fault(void);
+void hyp_builtin_cfi_fault_target(int unused);
+
+#else
+
+static inline
+int __kvm_register_cfi_test_cb(void (*cb)(void), bool in_host_ctxt)
+{
+	return -EOPNOTSUPP;
+}
+
+#define hyp_test_host_ctxt_cfi ((void(*)(void))(NULL))
+#define hyp_test_guest_ctxt_cfi ((void(*)(void))(NULL))
+
+static inline void hyp_trigger_builtin_cfi_fault(void)
+{
+}
+
+static inline void hyp_builtin_cfi_fault_target(int __always_unused unused)
+{
+}
+
+#endif /* CONFIG_HYP_SUPPORTS_CFI_TEST */
+
+#endif /* __ARM64_KVM_HYP_CFI_H__ */
diff --git a/arch/arm64/kvm/hyp/vhe/Makefile b/arch/arm64/kvm/hyp/vhe/Makefile
index 3b9e5464b5b3..19ca584cc21e 100644
--- a/arch/arm64/kvm/hyp/vhe/Makefile
+++ b/arch/arm64/kvm/hyp/vhe/Makefile
@@ -9,3 +9,4 @@ ccflags-y := -D__KVM_VHE_HYPERVISOR__
 obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o
 obj-y += ../vgic-v3-sr.o ../aarch32.o ../vgic-v2-cpuif-proxy.o ../entry.o \
 	 ../fpsimd.o ../hyp-entry.o ../exception.o
+obj-$(CONFIG_HYP_SUPPORTS_CFI_TEST) += cfi.o
diff --git a/arch/arm64/kvm/hyp/vhe/cfi.c b/arch/arm64/kvm/hyp/vhe/cfi.c
new file mode 100644
index 000000000000..5849f239e27f
--- /dev/null
+++ b/arch/arm64/kvm/hyp/vhe/cfi.c
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2024 - Google Inc
+ * Author: Pierre-Clément Tosi <ptosi@google.com>
+ */
+#include <asm/rwonce.h>
+
+#include <hyp/cfi.h>
+
+void (*hyp_test_host_ctxt_cfi)(void);
+void (*hyp_test_guest_ctxt_cfi)(void);
+
+int __kvm_register_cfi_test_cb(void (*cb)(void), bool in_host_ctxt)
+{
+	if (in_host_ctxt)
+		hyp_test_host_ctxt_cfi = cb;
+	else
+		hyp_test_guest_ctxt_cfi = cb;
+
+	return 0;
+}
+
+void hyp_builtin_cfi_fault_target(int __always_unused unused)
+{
+}
+
+void hyp_trigger_builtin_cfi_fault(void)
+{
+	/* Intentional UB cast & dereference, to trigger a kCFI fault. */
+	void (*target)(void) = (void *)&hyp_builtin_cfi_fault_target;
+
+	/*
+	 * READ_ONCE() prevents this indirect call from being optimized out,
+	 * forcing the compiler to generate the kCFI check before the branch.
+	 */
+	READ_ONCE(target)();
+}
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index 6c64783c3e00..fe70220876b4 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -4,6 +4,7 @@
  * Author: Marc Zyngier <marc.zyngier@arm.com>
  */
 
+#include <hyp/cfi.h>
 #include <hyp/switch.h>
 
 #include <linux/arm-smccc.h>
@@ -311,6 +312,9 @@ static int __kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
 	struct kvm_cpu_context *guest_ctxt;
 	u64 exit_code;
 
+	if (IS_ENABLED(CONFIG_HYP_SUPPORTS_CFI_TEST) && unlikely(hyp_test_host_ctxt_cfi))
+		hyp_test_host_ctxt_cfi();
+
 	host_ctxt = host_data_ptr(host_ctxt);
 	guest_ctxt = &vcpu->arch.ctxt;
 
@@ -329,6 +333,9 @@ static int __kvm_vcpu_run_vhe(struct kvm_vcpu *vcpu)
 	sysreg_restore_guest_state_vhe(guest_ctxt);
 	__debug_switch_to_guest(vcpu);
 
+	if (IS_ENABLED(CONFIG_HYP_SUPPORTS_CFI_TEST) && unlikely(hyp_test_guest_ctxt_cfi))
+		hyp_test_guest_ctxt_cfi();
+
 	do {
 		/* Jump in the fire! */
 		exit_code = __guest_enter(vcpu);
diff --git a/arch/arm64/kvm/hyp_cfi_test.c b/arch/arm64/kvm/hyp_cfi_test.c
new file mode 100644
index 000000000000..da7b25ca1b1f
--- /dev/null
+++ b/arch/arm64/kvm/hyp_cfi_test.c
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2024 - Google Inc
+ * Author: Pierre-Clément Tosi <ptosi@google.com>
+ */
+#include <asm/kvm_asm.h>
+#include <asm/kvm_cfi.h>
+#include <asm/kvm_host.h>
+#include <asm/virt.h>
+
+#include <linux/export.h>
+#include <linux/stddef.h>
+#include <linux/types.h>
+
+/* For calling directly into the VHE hypervisor; see <hyp/cfi.h>. */
+int __kvm_register_cfi_test_cb(void (*)(void), bool);
+
+static int kvm_register_cfi_test_cb(void (*vhe_cb)(void), bool in_host_ctxt)
+{
+	if (!is_hyp_mode_available())
+		return -ENXIO;
+
+	if (is_hyp_nvhe())
+		return -EOPNOTSUPP;
+
+	return __kvm_register_cfi_test_cb(vhe_cb, in_host_ctxt);
+}
+
+int kvm_cfi_test_register_host_ctxt_cb(void (*cb)(void))
+{
+	return kvm_register_cfi_test_cb(cb, true);
+}
+EXPORT_SYMBOL(kvm_cfi_test_register_host_ctxt_cb);
+
+int kvm_cfi_test_register_guest_ctxt_cb(void (*cb)(void))
+{
+	return kvm_register_cfi_test_cb(cb, false);
+}
+EXPORT_SYMBOL(kvm_cfi_test_register_guest_ctxt_cb);
+
+/* Hypervisor callbacks for the test module to register. */
+EXPORT_SYMBOL(hyp_trigger_builtin_cfi_fault);
+EXPORT_SYMBOL(hyp_builtin_cfi_fault_target);
diff --git a/arch/arm64/kvm/hyp_cfi_test_module.c b/arch/arm64/kvm/hyp_cfi_test_module.c
new file mode 100644
index 000000000000..eeda4be4d3ef
--- /dev/null
+++ b/arch/arm64/kvm/hyp_cfi_test_module.c
@@ -0,0 +1,133 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2024 - Google Inc
+ * Author: Pierre-Clément Tosi <ptosi@google.com>
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <asm/kvm_asm.h>
+#include <asm/kvm_cfi.h>
+#include <asm/rwonce.h>
+
+#include <linux/init.h>
+#include <linux/kstrtox.h>
+#include <linux/module.h>
+#include <linux/printk.h>
+
+static int set_host_mode(const char *val, const struct kernel_param *kp);
+static int set_guest_mode(const char *val, const struct kernel_param *kp);
+
+#define M_DESC \
+	"\n\t0: none" \
+	"\n\t1: built-in caller & built-in callee" \
+	"\n\t2: built-in caller & module callee" \
+	"\n\t3: module caller & built-in callee" \
+	"\n\t4: module caller & module callee"
+
+static unsigned int host_mode;
+module_param_call(host, set_host_mode, param_get_uint, &host_mode, 0644);
+MODULE_PARM_DESC(host,
+		 "Hypervisor kCFI fault test case in host context:" M_DESC);
+
+static unsigned int guest_mode;
+module_param_call(guest, set_guest_mode, param_get_uint, &guest_mode, 0644);
+MODULE_PARM_DESC(guest,
+		 "Hypervisor kCFI fault test case in guest context:" M_DESC);
+
+static void trigger_module2module_cfi_fault(void);
+static void trigger_module2builtin_cfi_fault(void);
+static void hyp_cfi_module2module_test_target(int);
+static void hyp_cfi_builtin2module_test_target(int);
+
+static int set_param_mode(const char *val, const struct kernel_param *kp,
+			 int (*register_cb)(void (*)(void)))
+{
+	unsigned int *mode = kp->arg;
+	int err;
+
+	err = param_set_uint(val, kp);
+	if (err)
+		return err;
+
+	switch (*mode) {
+	case 0:
+		return register_cb(NULL);
+	case 1:
+		return register_cb(hyp_trigger_builtin_cfi_fault);
+	case 2:
+		return register_cb((void *)hyp_cfi_builtin2module_test_target);
+	case 3:
+		return register_cb(trigger_module2builtin_cfi_fault);
+	case 4:
+		return register_cb(trigger_module2module_cfi_fault);
+	default:
+		return -EINVAL;
+	}
+}
+
+static int set_host_mode(const char *val, const struct kernel_param *kp)
+{
+	return set_param_mode(val, kp, kvm_cfi_test_register_host_ctxt_cb);
+}
+
+static int set_guest_mode(const char *val, const struct kernel_param *kp)
+{
+	return set_param_mode(val, kp, kvm_cfi_test_register_guest_ctxt_cb);
+}
+
+static void __exit exit_hyp_cfi_test(void)
+{
+	int err;
+
+	err = kvm_cfi_test_register_host_ctxt_cb(NULL);
+	if (err)
+		pr_err("Failed to unregister host context trigger: %d\n", err);
+
+	err = kvm_cfi_test_register_guest_ctxt_cb(NULL);
+	if (err)
+		pr_err("Failed to unregister guest context trigger: %d\n", err);
+}
+module_exit(exit_hyp_cfi_test);
+
+static void trigger_module2builtin_cfi_fault(void)
+{
+	/* Intentional UB cast & dereference, to trigger a kCFI fault. */
+	void (*target)(void) = (void *)&hyp_builtin_cfi_fault_target;
+
+	/*
+	 * READ_ONCE() prevents this indirect call from being optimized out,
+	 * forcing the compiler to generate the kCFI check before the branch.
+	 */
+	READ_ONCE(target)();
+
+	pr_err_ratelimited("%s: Survived a kCFI violation\n", __func__);
+}
+
+static void trigger_module2module_cfi_fault(void)
+{
+	/* Intentional UB cast & dereference, to trigger a kCFI fault. */
+	void (*target)(void) = (void *)&hyp_cfi_module2module_test_target;
+
+	/*
+	 * READ_ONCE() prevents this indirect call from being optimized out,
+	 * forcing the compiler to generate the kCFI check before the branch.
+	 */
+	READ_ONCE(target)();
+
+	pr_err_ratelimited("%s: Survived a kCFI violation\n", __func__);
+}
+
+/* Use different functions, for clearer symbols in kCFI panic reports. */
+static noinline
+void hyp_cfi_module2module_test_target(int __always_unused unused)
+{
+}
+
+static noinline
+void hyp_cfi_builtin2module_test_target(int __always_unused unused)
+{
+}
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Pierre-Clément Tosi <ptosi@google.com>");
+MODULE_DESCRIPTION("KVM hypervisor kCFI test module");
-- 
2.45.1.288.g0e0cd299f1-goog


^ permalink raw reply related	[relevance 4%]

* [PATCH v4 11/13] KVM: arm64: Improve CONFIG_CFI_CLANG error message
@ 2024-05-29 12:12  1%   ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

For kCFI, the compiler encodes in the immediate of the BRK (which the
CPU places in ESR_ELx) the indices of the two registers it used to hold
(resp.) the function pointer and expected type. Therefore, the kCFI
handler must be able to parse the contents of the register file at the
point where the exception was triggered.

To achieve this, introduce a new hypervisor panic path that first stores
the CPU context in the per-CPU kvm_hyp_ctxt before calling (directly or
indirectly) hyp_panic() and execute it from all EL2 synchronous
exception handlers i.e.

- call it directly in host_el2_sync_vect (__kvm_hyp_host_vector, EL2t&h)
- call it directly in el2t_sync_invalid (__kvm_hyp_vector, EL2t)
- set ELR_EL2 to it in el2_sync (__kvm_hyp_vector, EL2h), which ERETs

Teach hyp_panic() to decode the kCFI ESR and extract the target and type
from the saved CPU context. In VHE, use that information to panic() with
a specialized error message. In nVHE, only report it if the host (EL1)
has access to the saved CPU context i.e. iff CONFIG_NVHE_EL2_DEBUG=y,
which aligns with the behavior of CONFIG_PROTECTED_NVHE_STACKTRACE.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/kvm/handle_exit.c            | 30 +++++++++++++++++++++++--
 arch/arm64/kvm/hyp/entry.S              | 24 +++++++++++++++++++-
 arch/arm64/kvm/hyp/hyp-entry.S          |  2 +-
 arch/arm64/kvm/hyp/include/hyp/switch.h |  4 ++--
 arch/arm64/kvm/hyp/nvhe/host.S          |  2 +-
 arch/arm64/kvm/hyp/vhe/switch.c         | 26 +++++++++++++++++++--
 6 files changed, 79 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index 69b08ac7322d..2fac3be3db00 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -26,6 +26,8 @@
 #define CREATE_TRACE_POINTS
 #include "trace_handle_exit.h"
 
+DECLARE_KVM_NVHE_PER_CPU(struct kvm_cpu_context, kvm_hyp_ctxt);
+
 typedef int (*exit_handle_fn)(struct kvm_vcpu *);
 
 static void kvm_handle_guest_serror(struct kvm_vcpu *vcpu, u64 esr)
@@ -417,10 +419,34 @@ static void print_nvhe_hyp_panic(const char *name, u64 panic_addr)
 		(void *)(panic_addr + kaslr_offset()));
 }
 
-static void kvm_nvhe_report_cfi_failure(u64 panic_addr)
+static void kvm_nvhe_report_cfi_target(struct user_pt_regs *regs, u64 esr,
+				       u64 hyp_offset)
+{
+	u64 va_mask = GENMASK_ULL(vabits_actual - 1, 0);
+	u8 type_idx = FIELD_GET(CFI_BRK_IMM_TYPE, esr);
+	u8 target_idx = FIELD_GET(CFI_BRK_IMM_TARGET, esr);
+	u32 expected_type = (u32)regs->regs[type_idx];
+	u64 target_addr = (regs->regs[target_idx] & va_mask) + hyp_offset;
+
+	kvm_err(" (target: [<%016llx>] %ps, expected type: 0x%08x)\n",
+		target_addr, (void *)(target_addr + kaslr_offset()),
+		expected_type);
+}
+
+static void kvm_nvhe_report_cfi_failure(u64 panic_addr, u64 esr, u64 hyp_offset)
 {
+	struct user_pt_regs *regs = NULL;
+
 	print_nvhe_hyp_panic("CFI failure", panic_addr);
 
+	if (IS_ENABLED(CONFIG_NVHE_EL2_DEBUG) || !is_protected_kvm_enabled())
+		regs = &this_cpu_ptr_nvhe_sym(kvm_hyp_ctxt)->regs;
+
+	if (regs)
+		kvm_nvhe_report_cfi_target(regs, esr, hyp_offset);
+	else
+		kvm_err(" (no target information: !CONFIG_NVHE_EL2_DEBUG)\n");
+
 	if (IS_ENABLED(CONFIG_CFI_PERMISSIVE))
 		kvm_err(" (CONFIG_CFI_PERMISSIVE ignored for hyp failures)\n");
 }
@@ -455,7 +481,7 @@ void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
 		else
 			print_nvhe_hyp_panic("BUG", panic_addr);
 	} else if (IS_ENABLED(CONFIG_CFI_CLANG) && esr_is_cfi_brk(esr)) {
-		kvm_nvhe_report_cfi_failure(panic_addr);
+		kvm_nvhe_report_cfi_failure(panic_addr, esr, hyp_offset);
 	} else {
 		print_nvhe_hyp_panic("panic", panic_addr);
 	}
diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
index 343851c17373..8965dbc75972 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -83,7 +83,7 @@ alternative_else_nop_endif
 	eret
 	sb
 
-SYM_INNER_LABEL(__hyp_restore_elr_and_panic, SYM_L_GLOBAL)
+SYM_INNER_LABEL(__hyp_restore_elr_save_context_and_panic, SYM_L_GLOBAL)
 	// x2-x29,lr: vcpu regs
 	// vcpu x0-x1 on the stack
 
@@ -91,6 +91,28 @@ SYM_INNER_LABEL(__hyp_restore_elr_and_panic, SYM_L_GLOBAL)
 	ldr	x0, [x0, #CPU_ELR_EL2]
 	msr	elr_el2, x0
 
+SYM_INNER_LABEL(__hyp_save_context_and_panic, SYM_L_GLOBAL)
+	// x0-x29,lr: hyp regs
+
+	stp	x0, x1, [sp, #-16]!
+
+	adr_this_cpu x0, kvm_hyp_ctxt, x1
+
+	stp	x2, x3,   [x0, #CPU_XREG_OFFSET(2)]
+
+	ldp	x2, x3, [sp], #16
+
+	stp	x2, x3,   [x0, #CPU_XREG_OFFSET(0)]
+	stp	x4, x5,   [x0, #CPU_XREG_OFFSET(4)]
+	stp	x6, x7,   [x0, #CPU_XREG_OFFSET(6)]
+	stp	x8, x9,   [x0, #CPU_XREG_OFFSET(8)]
+	stp	x10, x11, [x0, #CPU_XREG_OFFSET(10)]
+	stp	x12, x13, [x0, #CPU_XREG_OFFSET(12)]
+	stp	x14, x15, [x0, #CPU_XREG_OFFSET(14)]
+	stp	x16, x17, [x0, #CPU_XREG_OFFSET(16)]
+
+	save_callee_saved_regs x0
+
 SYM_INNER_LABEL(__hyp_panic, SYM_L_GLOBAL)
 	// x2-x29,lr: vcpu regs
 	// vcpu x0-x1 on the stack
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index 7e65ef738ec9..d0d90d598338 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -130,7 +130,7 @@ SYM_CODE_END(\label)
 .endm
 
 	/* None of these should ever happen */
-	invalid_vector	el2t_sync_invalid
+	invalid_vector	el2t_sync_invalid, __hyp_save_context_and_panic
 	invalid_vector	el2t_irq_invalid
 	invalid_vector	el2t_fiq_invalid
 	invalid_vector	el2t_error_invalid
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index d9931abf14c2..77783dbc1833 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -689,7 +689,7 @@ static inline bool fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
 
 static inline void __kvm_unexpected_el2_exception(void)
 {
-	extern char __hyp_restore_elr_and_panic[];
+	extern char __hyp_restore_elr_save_context_and_panic[];
 	unsigned long addr, fixup;
 	struct kvm_exception_table_entry *entry, *end;
 	unsigned long elr_el2 = read_sysreg(elr_el2);
@@ -712,7 +712,7 @@ static inline void __kvm_unexpected_el2_exception(void)
 
 	/* Trigger a panic after restoring the hyp context. */
 	this_cpu_ptr(&kvm_hyp_ctxt)->sys_regs[ELR_EL2] = elr_el2;
-	write_sysreg(__hyp_restore_elr_and_panic, elr_el2);
+	write_sysreg(__hyp_restore_elr_save_context_and_panic, elr_el2);
 }
 
 #endif /* __ARM64_KVM_HYP_SWITCH_H__ */
diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index a7db40a51e4a..9343160f5357 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -214,7 +214,7 @@ SYM_FUNC_END(__host_hvc)
 .endm
 
 .macro host_el2_sync_vect
-	__host_el2_vect __hyp_panic
+	__host_el2_vect __hyp_save_context_and_panic
 .endm
 
 .macro invalid_host_el1_vect
diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index 0550b9f6317f..6c64783c3e00 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -17,6 +17,7 @@
 
 #include <asm/barrier.h>
 #include <asm/cpufeature.h>
+#include <asm/esr.h>
 #include <asm/kprobes.h>
 #include <asm/kvm_asm.h>
 #include <asm/kvm_emulate.h>
@@ -384,7 +385,24 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
 	return ret;
 }
 
-static void __noreturn __hyp_call_panic(u64 spsr, u64 elr, u64 par)
+static void __noreturn __hyp_call_panic_for_cfi(u64 elr, u64 esr)
+{
+	struct user_pt_regs *regs = &this_cpu_ptr(&kvm_hyp_ctxt)->regs;
+	u8 type_idx = FIELD_GET(CFI_BRK_IMM_TYPE, esr);
+	u8 target_idx = FIELD_GET(CFI_BRK_IMM_TARGET, esr);
+	u32 expected_type = (u32)regs->regs[type_idx];
+	u64 target = regs->regs[target_idx];
+
+	panic("VHE hyp CFI failure at: [<%016llx>] %pB (target: [<%016llx>] %ps, expected type: 0x%08x)\n"
+#ifdef CONFIG_CFI_PERMISSIVE
+	      " (CONFIG_CFI_PERMISSIVE ignored for hyp failures)\n"
+#endif
+	      ,
+	      elr, (void *)elr, target, (void *)target, expected_type);
+}
+NOKPROBE_SYMBOL(__hyp_call_panic_for_cfi);
+
+static void __noreturn __hyp_call_panic(u64 spsr, u64 elr, u64 par, u64 esr)
 {
 	struct kvm_cpu_context *host_ctxt;
 	struct kvm_vcpu *vcpu;
@@ -395,6 +413,9 @@ static void __noreturn __hyp_call_panic(u64 spsr, u64 elr, u64 par)
 	__deactivate_traps(vcpu);
 	sysreg_restore_host_state_vhe(host_ctxt);
 
+	if (IS_ENABLED(CONFIG_CFI_CLANG) && esr_is_cfi_brk(esr))
+		__hyp_call_panic_for_cfi(elr, esr);
+
 	panic("HYP panic:\nPS:%08llx PC:%016llx ESR:%08llx\nFAR:%016llx HPFAR:%016llx PAR:%016llx\nVCPU:%p\n",
 	      spsr, elr,
 	      read_sysreg_el2(SYS_ESR), read_sysreg_el2(SYS_FAR),
@@ -407,8 +428,9 @@ void __noreturn hyp_panic(void)
 	u64 spsr = read_sysreg_el2(SYS_SPSR);
 	u64 elr = read_sysreg_el2(SYS_ELR);
 	u64 par = read_sysreg_par();
+	u64 esr = read_sysreg_el2(SYS_ESR);
 
-	__hyp_call_panic(spsr, elr, par);
+	__hyp_call_panic(spsr, elr, par, esr);
 }
 
 asmlinkage void kvm_unexpected_el2_exception(void)
-- 
2.45.1.288.g0e0cd299f1-goog


^ permalink raw reply related	[relevance 1%]

* [PATCH v4 10/13] KVM: arm64: nVHE: Support CONFIG_CFI_CLANG at EL2
@ 2024-05-29 12:12  2%   ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

The compiler implements kCFI by adding type information (u32) above
every function that might be indirectly called and, whenever a function
pointer is called, injects a read-and-compare of that u32 against the
value corresponding to the expected type. In case of a mismatch, a BRK
instruction gets executed. When the hypervisor triggers such an
exception in nVHE, it panics and triggers and exception return to EL1.

Therefore, teach nvhe_hyp_panic_handler() to detect kCFI errors from the
ESR and report them. If necessary, remind the user that EL2 kCFI is not
affected by CONFIG_CFI_PERMISSIVE.

Pass $(CC_FLAGS_CFI) to the compiler when building the nVHE hyp code.

Use SYM_TYPED_FUNC_START() for __pkvm_init_switch_pgd, as nVHE can't
call it directly and must use a PA function pointer from C (because it
is part of the idmap page), which would trigger a kCFI failure if the
type ID wasn't present.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/kvm/handle_exit.c       | 10 ++++++++++
 arch/arm64/kvm/hyp/nvhe/Makefile   |  6 +++---
 arch/arm64/kvm/hyp/nvhe/hyp-init.S |  6 +++++-
 3 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index b3d6657a259d..69b08ac7322d 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -417,6 +417,14 @@ static void print_nvhe_hyp_panic(const char *name, u64 panic_addr)
 		(void *)(panic_addr + kaslr_offset()));
 }
 
+static void kvm_nvhe_report_cfi_failure(u64 panic_addr)
+{
+	print_nvhe_hyp_panic("CFI failure", panic_addr);
+
+	if (IS_ENABLED(CONFIG_CFI_PERMISSIVE))
+		kvm_err(" (CONFIG_CFI_PERMISSIVE ignored for hyp failures)\n");
+}
+
 void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
 					      u64 elr_virt, u64 elr_phys,
 					      u64 par, uintptr_t vcpu,
@@ -446,6 +454,8 @@ void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
 			kvm_err("nVHE hyp BUG at: %s:%u!\n", file, line);
 		else
 			print_nvhe_hyp_panic("BUG", panic_addr);
+	} else if (IS_ENABLED(CONFIG_CFI_CLANG) && esr_is_cfi_brk(esr)) {
+		kvm_nvhe_report_cfi_failure(panic_addr);
 	} else {
 		print_nvhe_hyp_panic("panic", panic_addr);
 	}
diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile b/arch/arm64/kvm/hyp/nvhe/Makefile
index 50fa0ffb6b7e..782b34b004be 100644
--- a/arch/arm64/kvm/hyp/nvhe/Makefile
+++ b/arch/arm64/kvm/hyp/nvhe/Makefile
@@ -89,9 +89,9 @@ quiet_cmd_hyprel = HYPREL  $@
 quiet_cmd_hypcopy = HYPCOPY $@
       cmd_hypcopy = $(OBJCOPY) --prefix-symbols=__kvm_nvhe_ $< $@
 
-# Remove ftrace, Shadow Call Stack, and CFI CFLAGS.
-# This is equivalent to the 'notrace', '__noscs', and '__nocfi' annotations.
-KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_FTRACE) $(CC_FLAGS_SCS) $(CC_FLAGS_CFI), $(KBUILD_CFLAGS))
+# Remove ftrace and Shadow Call Stack CFLAGS.
+# This is equivalent to the 'notrace' and '__noscs' annotations.
+KBUILD_CFLAGS := $(filter-out $(CC_FLAGS_FTRACE) $(CC_FLAGS_SCS), $(KBUILD_CFLAGS))
 # Starting from 13.0.0 llvm emits SHT_REL section '.llvm.call-graph-profile'
 # when profile optimization is applied. gen-hyprel does not support SHT_REL and
 # causes a build failure. Remove profile optimization flags.
diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-init.S b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
index d859c4de06b6..b1c8977e2812 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-init.S
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-init.S
@@ -5,6 +5,7 @@
  */
 
 #include <linux/arm-smccc.h>
+#include <linux/cfi_types.h>
 #include <linux/linkage.h>
 
 #include <asm/alternative.h>
@@ -267,8 +268,11 @@ SYM_CODE_END(__kvm_handle_stub_hvc)
 
 /*
  * void __pkvm_init_switch_pgd(phys_addr_t pgd, void *sp, void (*fn)(void));
+ *
+ * SYM_TYPED_FUNC_START() allows C to call this ID-mapped function indirectly
+ * using a physical pointer without triggering a kCFI failure.
  */
-SYM_FUNC_START(__pkvm_init_switch_pgd)
+SYM_TYPED_FUNC_START(__pkvm_init_switch_pgd)
 	/* Turn the MMU off */
 	pre_disable_mmu_workaround
 	mrs	x9, sctlr_el2
-- 
2.45.1.288.g0e0cd299f1-goog


^ permalink raw reply related	[relevance 2%]

* [PATCH v4 08/13] arm64: Introduce esr_comment() & esr_is_cfi_brk()
@ 2024-05-29 12:12  5%   ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

As it is already used in two places, move esr_comment() to a header for
re-use, with a clearer name.

Introduce esr_is_cfi_brk() to detect kCFI BRK syndromes, currently used
by early_brk64() but soon to be also used by hypervisor code.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/include/asm/esr.h       | 11 +++++++++++
 arch/arm64/kernel/debug-monitors.c |  4 +---
 arch/arm64/kernel/traps.c          |  8 +++-----
 arch/arm64/kvm/handle_exit.c       |  2 +-
 4 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
index 7abf09df7033..77569d207ecf 100644
--- a/arch/arm64/include/asm/esr.h
+++ b/arch/arm64/include/asm/esr.h
@@ -379,6 +379,11 @@
 #ifndef __ASSEMBLY__
 #include <asm/types.h>
 
+static inline unsigned long esr_brk_comment(unsigned long esr)
+{
+	return esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
+}
+
 static inline bool esr_is_data_abort(unsigned long esr)
 {
 	const unsigned long ec = ESR_ELx_EC(esr);
@@ -386,6 +391,12 @@ static inline bool esr_is_data_abort(unsigned long esr)
 	return ec == ESR_ELx_EC_DABT_LOW || ec == ESR_ELx_EC_DABT_CUR;
 }
 
+static inline bool esr_is_cfi_brk(unsigned long esr)
+{
+	return ESR_ELx_EC(esr) == ESR_ELx_EC_BRK64 &&
+	       (esr_brk_comment(esr) & ~CFI_BRK_IMM_MASK) == CFI_BRK_IMM_BASE;
+}
+
 static inline bool esr_fsc_is_translation_fault(unsigned long esr)
 {
 	/* Translation fault, level -1 */
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 64f2ecbdfe5c..024a7b245056 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -312,9 +312,7 @@ static int call_break_hook(struct pt_regs *regs, unsigned long esr)
 	 * entirely not preemptible, and we can use rcu list safely here.
 	 */
 	list_for_each_entry_rcu(hook, list, node) {
-		unsigned long comment = esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
-
-		if ((comment & ~hook->mask) == hook->imm)
+		if ((esr_brk_comment(esr) & ~hook->mask) == hook->imm)
 			fn = hook->fn;
 	}
 
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 215e6d7f2df8..9e22683aa921 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -1105,8 +1105,6 @@ static struct break_hook ubsan_break_hook = {
 };
 #endif
 
-#define esr_comment(esr) ((esr) & ESR_ELx_BRK64_ISS_COMMENT_MASK)
-
 /*
  * Initial handler for AArch64 BRK exceptions
  * This handler only used until debug_traps_init().
@@ -1115,15 +1113,15 @@ int __init early_brk64(unsigned long addr, unsigned long esr,
 		struct pt_regs *regs)
 {
 #ifdef CONFIG_CFI_CLANG
-	if ((esr_comment(esr) & ~CFI_BRK_IMM_MASK) == CFI_BRK_IMM_BASE)
+	if (esr_is_cfi_brk(esr))
 		return cfi_handler(regs, esr) != DBG_HOOK_HANDLED;
 #endif
 #ifdef CONFIG_KASAN_SW_TAGS
-	if ((esr_comment(esr) & ~KASAN_BRK_MASK) == KASAN_BRK_IMM)
+	if ((esr_brk_comment(esr) & ~KASAN_BRK_MASK) == KASAN_BRK_IMM)
 		return kasan_handler(regs, esr) != DBG_HOOK_HANDLED;
 #endif
 #ifdef CONFIG_UBSAN_TRAP
-	if ((esr_comment(esr) & ~UBSAN_BRK_MASK) == UBSAN_BRK_IMM)
+	if ((esr_brk_comment(esr) & ~UBSAN_BRK_MASK) == UBSAN_BRK_IMM)
 		return ubsan_handler(regs, esr) != DBG_HOOK_HANDLED;
 #endif
 	return bug_handler(regs, esr) != DBG_HOOK_HANDLED;
diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
index b037f0a0e27e..d41447193e13 100644
--- a/arch/arm64/kvm/handle_exit.c
+++ b/arch/arm64/kvm/handle_exit.c
@@ -423,7 +423,7 @@ void __noreturn __cold nvhe_hyp_panic_handler(u64 esr, u64 spsr,
 	if (mode != PSR_MODE_EL2t && mode != PSR_MODE_EL2h) {
 		kvm_err("Invalid host exception to nVHE hyp!\n");
 	} else if (ESR_ELx_EC(esr) == ESR_ELx_EC_BRK64 &&
-		   (esr & ESR_ELx_BRK64_ISS_COMMENT_MASK) == BUG_BRK_IMM) {
+		   esr_brk_comment(esr) == BUG_BRK_IMM) {
 		const char *file = NULL;
 		unsigned int line = 0;
 
-- 
2.45.1.288.g0e0cd299f1-goog


^ permalink raw reply related	[relevance 5%]

* [PATCH v4 07/13] KVM: arm64: VHE: Mark __hyp_call_panic __noreturn
@ 2024-05-29 12:12  1%   ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Given that the sole purpose of __hyp_call_panic() is to call panic(), a
__noreturn function, give it the __noreturn attribute, removing the need
for its caller to use unreachable().

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/kvm/hyp/vhe/switch.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
index d7af5f46f22a..0550b9f6317f 100644
--- a/arch/arm64/kvm/hyp/vhe/switch.c
+++ b/arch/arm64/kvm/hyp/vhe/switch.c
@@ -384,7 +384,7 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
 	return ret;
 }
 
-static void __hyp_call_panic(u64 spsr, u64 elr, u64 par)
+static void __noreturn __hyp_call_panic(u64 spsr, u64 elr, u64 par)
 {
 	struct kvm_cpu_context *host_ctxt;
 	struct kvm_vcpu *vcpu;
@@ -409,7 +409,6 @@ void __noreturn hyp_panic(void)
 	u64 par = read_sysreg_par();
 
 	__hyp_call_panic(spsr, elr, par);
-	unreachable();
 }
 
 asmlinkage void kvm_unexpected_el2_exception(void)
-- 
2.45.1.288.g0e0cd299f1-goog


^ permalink raw reply related	[relevance 1%]

* [PATCH v4 06/13] KVM: arm64: nVHE: gen-hyprel: Skip R_AARCH64_ABS32
@ 2024-05-29 12:12  1%   ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Ignore R_AARCH64_ABS32 relocations, instead of panicking, when emitting
the relocation table of the hypervisor. The toolchain might produce them
when generating function calls with kCFI to represent the 32-bit type ID
which can then be resolved across compilation units at link time.  These
are NOT actual 32-bit addresses and are therefore not needed in the
final (runtime) relocation table (which is unlikely to use 32-bit
absolute addresses for arm64 anyway).

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/kvm/hyp/nvhe/gen-hyprel.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c b/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
index 6bc88a756cb7..b63f4e1c1033 100644
--- a/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
+++ b/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
@@ -50,6 +50,9 @@
 #ifndef R_AARCH64_ABS64
 #define R_AARCH64_ABS64			257
 #endif
+#ifndef R_AARCH64_ABS32
+#define R_AARCH64_ABS32			258
+#endif
 #ifndef R_AARCH64_PREL64
 #define R_AARCH64_PREL64		260
 #endif
@@ -383,6 +386,9 @@ static void emit_rela_section(Elf64_Shdr *sh_rela)
 		case R_AARCH64_ABS64:
 			emit_rela_abs64(rela, sh_orig_name);
 			break;
+		/* Allow 32-bit absolute relocation, for kCFI type hashes. */
+		case R_AARCH64_ABS32:
+			break;
 		/* Allow position-relative data relocations. */
 		case R_AARCH64_PREL64:
 		case R_AARCH64_PREL32:
-- 
2.45.1.288.g0e0cd299f1-goog


^ permalink raw reply related	[relevance 1%]

* [PATCH v4 05/13] KVM: arm64: Rename __guest_exit_panic __hyp_panic
@ 2024-05-29 12:12  2%   ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Use a name that expresses the fact that the routine might not exit
through the guest but will always (directly or indirectly) end up
executing hyp_panic().

Use CPU_LR_OFFSET to clarify that the routine returns to hyp_panic().

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/kvm/hyp/entry.S              | 6 +++---
 arch/arm64/kvm/hyp/hyp-entry.S          | 2 +-
 arch/arm64/kvm/hyp/include/hyp/switch.h | 4 ++--
 arch/arm64/kvm/hyp/nvhe/host.S          | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
index 4433a234aa9b..343851c17373 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -83,7 +83,7 @@ alternative_else_nop_endif
 	eret
 	sb
 
-SYM_INNER_LABEL(__guest_exit_restore_elr_and_panic, SYM_L_GLOBAL)
+SYM_INNER_LABEL(__hyp_restore_elr_and_panic, SYM_L_GLOBAL)
 	// x2-x29,lr: vcpu regs
 	// vcpu x0-x1 on the stack
 
@@ -91,7 +91,7 @@ SYM_INNER_LABEL(__guest_exit_restore_elr_and_panic, SYM_L_GLOBAL)
 	ldr	x0, [x0, #CPU_ELR_EL2]
 	msr	elr_el2, x0
 
-SYM_INNER_LABEL(__guest_exit_panic, SYM_L_GLOBAL)
+SYM_INNER_LABEL(__hyp_panic, SYM_L_GLOBAL)
 	// x2-x29,lr: vcpu regs
 	// vcpu x0-x1 on the stack
 
@@ -109,7 +109,7 @@ SYM_INNER_LABEL(__guest_exit_panic, SYM_L_GLOBAL)
 	// accurate if the guest had been completely restored.
 	adr_this_cpu x0, kvm_hyp_ctxt, x1
 	adr_l	x1, hyp_panic
-	str	x1, [x0, #CPU_XREG_OFFSET(30)]
+	str	x1, [x0, #CPU_LR_OFFSET]
 
 	get_vcpu_ptr	x1, x0
 
diff --git a/arch/arm64/kvm/hyp/hyp-entry.S b/arch/arm64/kvm/hyp/hyp-entry.S
index 03f97d71984c..7e65ef738ec9 100644
--- a/arch/arm64/kvm/hyp/hyp-entry.S
+++ b/arch/arm64/kvm/hyp/hyp-entry.S
@@ -122,7 +122,7 @@ el2_error:
 	eret
 	sb
 
-.macro invalid_vector	label, target = __guest_exit_panic
+.macro invalid_vector	label, target = __hyp_panic
 	.align	2
 SYM_CODE_START_LOCAL(\label)
 	b \target
diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
index ed9a63f1f7bf..d9931abf14c2 100644
--- a/arch/arm64/kvm/hyp/include/hyp/switch.h
+++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
@@ -689,7 +689,7 @@ static inline bool fixup_guest_exit(struct kvm_vcpu *vcpu, u64 *exit_code)
 
 static inline void __kvm_unexpected_el2_exception(void)
 {
-	extern char __guest_exit_restore_elr_and_panic[];
+	extern char __hyp_restore_elr_and_panic[];
 	unsigned long addr, fixup;
 	struct kvm_exception_table_entry *entry, *end;
 	unsigned long elr_el2 = read_sysreg(elr_el2);
@@ -712,7 +712,7 @@ static inline void __kvm_unexpected_el2_exception(void)
 
 	/* Trigger a panic after restoring the hyp context. */
 	this_cpu_ptr(&kvm_hyp_ctxt)->sys_regs[ELR_EL2] = elr_el2;
-	write_sysreg(__guest_exit_restore_elr_and_panic, elr_el2);
+	write_sysreg(__hyp_restore_elr_and_panic, elr_el2);
 }
 
 #endif /* __ARM64_KVM_HYP_SWITCH_H__ */
diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index bc0a73d9fcd0..a7db40a51e4a 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -214,7 +214,7 @@ SYM_FUNC_END(__host_hvc)
 .endm
 
 .macro host_el2_sync_vect
-	__host_el2_vect __guest_exit_panic
+	__host_el2_vect __hyp_panic
 .endm
 
 .macro invalid_host_el1_vect
@@ -227,7 +227,7 @@ SYM_FUNC_END(__host_hvc)
 .endm
 
 .macro invalid_host_el2_vect
-	__host_el2_vect __guest_exit_panic
+	__host_el2_vect __hyp_panic
 .endm
 
 /*
-- 
2.45.1.288.g0e0cd299f1-goog


^ permalink raw reply related	[relevance 2%]

* [PATCH v4 04/13] KVM: arm64: nVHE: Add EL2h sync exception handler
@ 2024-05-29 12:12  4%   ` Pierre-Clément Tosi
  0 siblings, 0 replies; 200+ results
From: Pierre-Clément Tosi @ 2024-05-29 12:12 UTC (permalink / raw)
  To: kvmarm, linux-arm-kernel, kvm
  Cc: Pierre-Clément Tosi, Marc Zyngier, Oliver Upton,
	Suzuki K Poulose, Vincent Donnefort

Introduce a handler for EL2h synchronous exceptions distinct from
handlers for other "invalid" exceptions when running with the nVHE host
vector. This will allow a future patch to handle kCFI (synchronous)
errors without affecting other classes of exceptions.

Signed-off-by: Pierre-Clément Tosi <ptosi@google.com>
---
 arch/arm64/kvm/hyp/nvhe/host.S | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe/host.S
index 71fb311b4c0e..bc0a73d9fcd0 100644
--- a/arch/arm64/kvm/hyp/nvhe/host.S
+++ b/arch/arm64/kvm/hyp/nvhe/host.S
@@ -183,7 +183,7 @@ SYM_FUNC_END(__host_hvc)
 .endif
 .endm
 
-.macro invalid_host_el2_vect
+.macro __host_el2_vect handler:req
 	.align 7
 
 	/*
@@ -203,7 +203,7 @@ SYM_FUNC_END(__host_hvc)
 	 * been partially clobbered by __host_enter.
 	 */
 	stp	x0, x1, [sp, #-16]!
-	b	__guest_exit_panic
+	b	\handler
 
 .L__hyp_sp_overflow\@:
 	/* Switch to the overflow stack */
@@ -213,6 +213,10 @@ SYM_FUNC_END(__host_hvc)
 	ASM_BUG()
 .endm
 
+.macro host_el2_sync_vect
+	__host_el2_vect __guest_exit_panic
+.endm
+
 .macro invalid_host_el1_vect
 	.align 7
 	mov	x0, xzr		/* restore_host = false */
@@ -222,6 +226,10 @@ SYM_FUNC_END(__host_hvc)
 	b	__hyp_do_panic
 .endm
 
+.macro invalid_host_el2_vect
+	__host_el2_vect __guest_exit_panic
+.endm
+
 /*
  * The host vector does not use an ESB instruction in order to avoid consuming
  * SErrors that should only be consumed by the host. Guest entry is deferred by
@@ -239,7 +247,7 @@ SYM_CODE_START(__kvm_hyp_host_vector)
 	invalid_host_el2_vect			// FIQ EL2t
 	invalid_host_el2_vect			// Error EL2t
 
-	invalid_host_el2_vect			// Synchronous EL2h
+	host_el2_sync_vect			// Synchronous EL2h
 	invalid_host_el2_vect			// IRQ EL2h
 	invalid_host_el2_vect			// FIQ EL2h
 	invalid_host_el2_vect			// Error EL2h
-- 
2.45.1.288.g0e0cd299f1-goog


^ permalink raw reply related	[relevance 4%]

* Re: [PATCH v2 1/3] dt-bindings: i2c: gpio: Add 'transition-delay-us' property
  @ 2024-05-29 12:13  1%   ` Peter Rosin
  0 siblings, 0 replies; 200+ results
From: Peter Rosin @ 2024-05-29 12:13 UTC (permalink / raw)
  To: Bastien Curutchet, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Peter Korsgaard, Wolfram Sang
  Cc: linux-i2c, devicetree, linux-kernel, Thomas Petazzoni,
	Herve Codina, Christopher Cordahi

Hi!

2024-05-29 at 11:17, Bastien Curutchet wrote:
> I2C MUXes described by the i2c-gpio-mux sometimes need a significant
> amount of time to switch from a bus to another. When a new bus is
> selected, the first I2C transfer can fail if it occurs too early. There
> is no way to describe this transition delay that has to be waited before
> starting the first I2C transfer.
> 
> Add a 'transition-delay-us' property that indicates the delay to be
> respected before doing the first i2c transfer.

The io-channel-mux has a property with very similar intent named
settle-time-us [1]. I think we should use the same name here.

[1] Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml

Cheers,
Peter

^ permalink raw reply	[relevance 1%]

* Re: [PATCH 3/8] gpio: tqmx86: change tqmx86_gpio_write() order of arguments to match regmap API
  2024-05-29 12:03  0%   ` Bartosz Golaszewski
@ 2024-05-29 12:11  0%     ` Andrew Lunn
  2024-05-29 12:23  0%       ` Matthias Schiffer
  0 siblings, 1 reply; 200+ results
From: Andrew Lunn @ 2024-05-29 12:11 UTC (permalink / raw)
  To: Bartosz Golaszewski
  Cc: Matthias Schiffer, Linus Walleij, linux-gpio, linux-kernel,
	Gregor Herburger, linux

On Wed, May 29, 2024 at 02:03:35PM +0200, Bartosz Golaszewski wrote:
> On Wed, May 29, 2024 at 9:46 AM Matthias Schiffer
> <matthias.schiffer@ew.tq-group.com> wrote:
> >
> > Conversion to actually use regmap does not seem useful for this driver,
> > as regmap can't properly represent separate read-only and write-only
> > registers at the same address, but we can at least match the API to make
> > the code clearer.
> >
> > No functional change intended.
> >
> > Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")
> 
> This is not a fix.

Agreed.

I'm somewhat conflicted by this patch. It is a step towards using
regmap, but then says regmap does not make sense. So why make that
step?

Changing the order of parameters like this seems like it is will make
back porting bug fixes harder, unless all supported versions are
changed, which is why fixes make sense. Does the compiler at least
issue a warning if the parameters are used the wrong way around?

Overall, i'm leaning towards just dropping it.

	 Andrew

^ permalink raw reply	[relevance 0%]

* Re: [cocci] Looking at guard usage (with SmPL)
  @ 2024-05-29 12:10  0%   ` Markus Elfring
  2024-05-29 12:50  0%     ` Dr. David Alan Gilbert
  0 siblings, 1 reply; 200+ results
From: Markus Elfring @ 2024-05-29 12:10 UTC (permalink / raw)
  To: Julia Lawall, cocci, kernel-janitors

> I'm not the one to decide whether we should use cleanup for mutex locks.

Would you get further development ideas from another bit of source code analysis
which can be performed also with the help of the following small script variant
for the semantic patch language?


@initialize:python@
@@
import sys
delimiter = "|"

def format_data(places, item, input):
   for place in places:
      sys.stdout.write(delimiter.join([item,
                                       str(input),
                                       place.current_element,
                                       place.file,
                                       place.line,
                                       str(int(place.column) + 1)
                                      ]))
      sys.stdout.write("\n")

@find@
expression list el;
identifier item;
position p;
@@
 guard@p (item) (el);

@script:python output@
input << find.el;
item << find.item;
places << find.p;
@@
format_data(places, item, input)



Thus it seems that special “guards” are used at 678 source code places
of the software “Linux next-20240529”.
https://elixir.bootlin.com/linux/v6.10-rc1/source/include/linux/cleanup.h#L124

Will interests accordingly grow for further collateral evolution?

Regards,
Markus

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v6 4/6] arm64: dts: mediatek: mt8186: add default thermal zones
  @ 2024-05-29 12:06  1%           ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 200+ results
From: AngeloGioacchino Del Regno @ 2024-05-29 12:06 UTC (permalink / raw)
  To: Julien Panis, Chen-Yu Tsai
  Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
	Daniel Lezcano, Nicolas Pitre, Rafael J. Wysocki, Zhang Rui,
	Lukasz Luba, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek, linux-pm, Krzysztof Kozlowski

Il 29/05/24 11:12, Julien Panis ha scritto:
> On 5/29/24 10:33, Chen-Yu Tsai wrote:
>> On Wed, May 29, 2024 at 4:17 PM AngeloGioacchino Del Regno
>> <angelogioacchino.delregno@collabora.com> wrote:
>>> Il 29/05/24 07:57, Julien Panis ha scritto:
>>>> From: Nicolas Pitre <npitre@baylibre.com>
>>>>
>>>> Inspired by the vendor kernel but adapted to the upstream thermal
>>>> driver version.
>>>>
>>>> Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
>>>> Signed-off-by: Julien Panis <jpanis@baylibre.com>
>>> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>> I'm getting some crazy readings which would cause the machine to
>> immediately shutdown during boot. Anyone else see this? Or maybe
>> my device has bad calibration data?
>>
>> gpu_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       +229.7 C
>>
>> nna_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       +229.7 C
>>
>> cpu_big0_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:         -7.2 C
>>
>> cpu_little2_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       +157.2 C
>>
>> cpu_little0_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       -277.1 C
>>
>> adsp_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       +229.7 C
>>
>> cpu_big1_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       +229.7 C
>>
>> cam_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +45.4 C
>>
>> cpu_little1_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       -241.8 C
> 
> It's likely that your device has bad calibration data indeed. We observed the same
> behavior on the mt8186 device we used (a Corsola) and finally realized that the
> golden temperature was 0 (device not properly calibrated).
> 
> To make a comparison, we run chromiumos v5.15 and dmesg output was:
> 'This sample is not calibrated, fake !!'
> Additional debugging revealed that the golden temp was actually 0. As a result,
> chromiumos v5.15 does not use the calibration data. It uses some default values
> instead. That's why you can observe good temperatures with chromiumos v5.15
> even with a device that is not calibrated.
> 
> This feature is not implemented in the driver upstream, so you need a device
> properly calibrated to get good temperatures with it. When we forced this
> driver using the default values used by chromiumos v5.15 instead of real calib
> data (temporarily, just for testing), the temperatures were good.
> 
> Please make sure your device is properly calibrated: 0 < golden temp < 62.
> 

Wait wait wait wait.

What's up with that calibration data stuff?

If there's any device that cannot use the calibration data, we need a way to
recognize whether the provided data (read from efuse, of course) is valid,
otherwise we're creating an important regression here.

"This device is unlucky" is not a good reason to have this kind of regression.

Since - as far as I understand - downstream can recognize that, upstream should
do the same.
I'd be okay with refusing to even probe this driver on such devices for the
moment being, as those are things that could be eventually handled on a second
part series, even though I would prefer a kind of on-the-fly calibration or
anyway something that would still make the unlucky ones to actually have good
readings *right now*.

Though, the fact that you assert that you observed this behavior on one of your
devices and *still decided to send that upstream* is, in my opinion, unacceptable.

Regards,
Angelo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 1%]

* Re: [PATCH net v2] ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound
  @ 2024-05-29 12:06  3% ` Eric Dumazet
  0 siblings, 0 replies; 200+ results
From: Eric Dumazet @ 2024-05-29 12:06 UTC (permalink / raw)
  To: Yue Haibing; +Cc: davem, kuba, pabeni, maheshb, netdev, linux-kernel

On Wed, May 29, 2024 at 11:52 AM Yue Haibing <yuehaibing@huawei.com> wrote:
>
> Raw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device will
> hit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.
>
> WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70
> Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helper
> CPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> RIP: 0010:sk_mc_loop+0x2d/0x70
> Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1c
> RSP: 0018:ffffa9584015cd78 EFLAGS: 00010212
> RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001
> RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000
> RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00
> R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000
> R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000
> FS:  0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
> <IRQ>
>  ? __warn (kernel/panic.c:693)
>  ? sk_mc_loop (net/core/sock.c:760)
>  ? report_bug (lib/bug.c:201 lib/bug.c:219)
>  ? handle_bug (arch/x86/kernel/traps.c:239)
>  ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))
>  ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)
>  ? sk_mc_loop (net/core/sock.c:760)
>  ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1))
>  ? nf_hook_slow (net/netfilter/core.c:626)
>  ip6_finish_output (net/ipv6/ip6_output.c:222)
>  ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215)
>  ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan
>  ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan
>  dev_hard_start_xmit (net/core/dev.c:3594)
>  sch_direct_xmit (net/sched/sch_generic.c:343)
>  __qdisc_run (net/sched/sch_generic.c:416)
>  net_tx_action (net/core/dev.c:5286)
>  handle_softirqs (kernel/softirq.c:555)
>  __irq_exit_rcu (kernel/softirq.c:589)
>  sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)
>
> The warning triggers as this:
> packet_sendmsg
>    packet_snd //skb->sk is packet sk
>       __dev_queue_xmit
>          __dev_xmit_skb //q->enqueue is not NULL
>              __qdisc_run
>                sch_direct_xmit
>                  dev_hard_start_xmit
>                    ipvlan_start_xmit
>                       ipvlan_xmit_mode_l3 //l3 mode
>                         ipvlan_process_outbound //vepa flag
>                           ipvlan_process_v6_outbound
>                             ip6_local_out
>                                 __ip6_finish_output
>                                   ip6_finish_output2 //multicast packet
>                                     sk_mc_loop //sk->sk_family is AF_PACKET
>
> Call ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.
>
> Fixes: 2ad7bf363841 ("ipvlan: Initial check-in of the IPVLAN driver.")
> Suggested-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
> ---

Reviewed-by: Eric Dumazet <edumazet@google.com>

^ permalink raw reply	[relevance 3%]

* Re: [PATCH v6 4/6] arm64: dts: mediatek: mt8186: add default thermal zones
@ 2024-05-29 12:06  1%           ` AngeloGioacchino Del Regno
  0 siblings, 0 replies; 200+ results
From: AngeloGioacchino Del Regno @ 2024-05-29 12:06 UTC (permalink / raw)
  To: Julien Panis, Chen-Yu Tsai
  Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
	Daniel Lezcano, Nicolas Pitre, Rafael J. Wysocki, Zhang Rui,
	Lukasz Luba, devicetree, linux-kernel, linux-arm-kernel,
	linux-mediatek, linux-pm, Krzysztof Kozlowski

Il 29/05/24 11:12, Julien Panis ha scritto:
> On 5/29/24 10:33, Chen-Yu Tsai wrote:
>> On Wed, May 29, 2024 at 4:17 PM AngeloGioacchino Del Regno
>> <angelogioacchino.delregno@collabora.com> wrote:
>>> Il 29/05/24 07:57, Julien Panis ha scritto:
>>>> From: Nicolas Pitre <npitre@baylibre.com>
>>>>
>>>> Inspired by the vendor kernel but adapted to the upstream thermal
>>>> driver version.
>>>>
>>>> Signed-off-by: Nicolas Pitre <npitre@baylibre.com>
>>>> Signed-off-by: Julien Panis <jpanis@baylibre.com>
>>> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
>> I'm getting some crazy readings which would cause the machine to
>> immediately shutdown during boot. Anyone else see this? Or maybe
>> my device has bad calibration data?
>>
>> gpu_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       +229.7 C
>>
>> nna_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       +229.7 C
>>
>> cpu_big0_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:         -7.2 C
>>
>> cpu_little2_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       +157.2 C
>>
>> cpu_little0_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       -277.1 C
>>
>> adsp_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       +229.7 C
>>
>> cpu_big1_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       +229.7 C
>>
>> cam_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:        +45.4 C
>>
>> cpu_little1_thermal-virtual-0
>> Adapter: Virtual device
>> temp1:       -241.8 C
> 
> It's likely that your device has bad calibration data indeed. We observed the same
> behavior on the mt8186 device we used (a Corsola) and finally realized that the
> golden temperature was 0 (device not properly calibrated).
> 
> To make a comparison, we run chromiumos v5.15 and dmesg output was:
> 'This sample is not calibrated, fake !!'
> Additional debugging revealed that the golden temp was actually 0. As a result,
> chromiumos v5.15 does not use the calibration data. It uses some default values
> instead. That's why you can observe good temperatures with chromiumos v5.15
> even with a device that is not calibrated.
> 
> This feature is not implemented in the driver upstream, so you need a device
> properly calibrated to get good temperatures with it. When we forced this
> driver using the default values used by chromiumos v5.15 instead of real calib
> data (temporarily, just for testing), the temperatures were good.
> 
> Please make sure your device is properly calibrated: 0 < golden temp < 62.
> 

Wait wait wait wait.

What's up with that calibration data stuff?

If there's any device that cannot use the calibration data, we need a way to
recognize whether the provided data (read from efuse, of course) is valid,
otherwise we're creating an important regression here.

"This device is unlucky" is not a good reason to have this kind of regression.

Since - as far as I understand - downstream can recognize that, upstream should
do the same.
I'd be okay with refusing to even probe this driver on such devices for the
moment being, as those are things that could be eventually handled on a second
part series, even though I would prefer a kind of on-the-fly calibration or
anyway something that would still make the unlucky ones to actually have good
readings *right now*.

Though, the fact that you assert that you observed this behavior on one of your
devices and *still decided to send that upstream* is, in my opinion, unacceptable.

Regards,
Angelo

^ permalink raw reply	[relevance 1%]

* Re: [RFC PATCH] arm64: dts: rockchip: Make preparations for per-RK3588-variant OPPs
    2024-05-29 12:04  1%       ` Alexey Charkov
@ 2024-05-29 12:04  1%       ` Alexey Charkov
  0 siblings, 0 replies; 200+ results
From: Alexey Charkov @ 2024-05-29 12:04 UTC (permalink / raw)
  To: Dragan Simic
  Cc: linux-rockchip, heiko, linux-arm-kernel, devicetree, robh+dt,
	krzk+dt, conor+dt, linux-kernel, quentin.schulz, wens,
	daniel.lezcano, didi.debian, krzysztof.kozlowski+dt,
	viresh.kumar

On Wed, May 29, 2024 at 2:45 PM Dragan Simic <dsimic@manjaro.org> wrote:
>
> Hello Alexey.
>
> On 2024-05-29 11:57, Alexey Charkov wrote:
> > On Wed, May 29, 2024 at 6:14 AM Dragan Simic <dsimic@manjaro.org>
> > wrote:
> >>
> >> Rename and modify the RK3588 dtsi files a bit, to make preparations
> >> for
> >> the ability to specify different CPU and GPU OPPs for each of the
> >> supported
> >> RK3588 SoC variants, including the RK3588J.
> >>
> >> As already discussed, [1][2][3] some of the different RK3588 SoC
> >> variants
> >> require different OPPs, and it makes more sense to have the OPPs
> >> already
> >> defined when a board dts includes one of the SoC dtsi files
> >> (rk3588.dtsi,
> >> rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts
> >> file to
> >> also include a separate rk3588*-opp.dtsi file.  The choice of the SoC
> >> variant
> >> is already made by the inclusion of the SoC dtsi file, and it doesn't
> >> make
> >> much sense to, effectively, allow the board dts file to include and
> >> use an
> >> incompatible set of OPPs for the already selected SoC variant.
> >
> > Indeed, including just one .dtsi for the correct SoC variant and not
> > having to bother about what other bits and pieces are required to use
> > the full SoC functionality sounds great! Thanks for putting this
> > together so promptly!
>
> You're welcome. :)
>
> > Some considerations below.
> >
> >> No intended functional changes are introduced.  (Still to be
> >> additionally
> >> verified if the patch moves forward from the RFC state.)
> >>
> >> [1]
> >> https://lore.kernel.org/linux-rockchip/646a33e0-5c1b-471c-8183-2c0df40ea51a@cherry.de/
> >> [2]
> >> https://lore.kernel.org/linux-rockchip/CABjd4Yxi=+3gkNnH3BysUzzYsji-=-yROtzEc8jM_g0roKB0-w@mail.gmail.com/
> >> [3]
> >> https://lore.kernel.org/linux-rockchip/035a274be262528012173d463e25b55f@manjaro.org/
> >>
> >> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
> >> ---
> >>  ...inctrl.dtsi => rk3588-common-pinctrl.dtsi} |    0
> >
> > Renaming the pinctrl includes seems superfluous - maybe keep them as
> > they were to minimize churn?
>
> Believe it or not, the same thoughts crossed my mind.  However,
> after thinking a bit about it, I concluded that renaming the pinctrl
> .dtsi files as well makes the overall naming of the reworked RK3588
> .dtsi files more consistent.
>
> It's also rather neat to have the "common" and "fullfat" file pairs
> together in the arch/arm64/boot/dts/rockchip directory listing, when
> it's sorted by the file name, which is the default in most (if not
> all) environments.
>
> >>  .../{rk3588s.dtsi => rk3588-common.dtsi}      |    2 +-
> >>  ...nctrl.dtsi => rk3588-fullfat-pinctrl.dtsi} |    0
> >>  .../{rk3588.dtsi => rk3588-fullfat.dtsi}      |    4 +-
> >
> > To me, "fullfat" doesn't look super descriptive, albeit fun :)
>
> Yeah, I resorted to "fullfat" as some kind of a funny option. :)
> That's for the "beefy" SoC variants, so it kind of fits well. :)
>
> > How about we rename the existing rk3588.dtsi and rk3588s.dtsi to
> > something like rk3588-devices.dtsi and rk3588s-devices.dtsi
> > (preserving the inheritance between them), and then I add
> > rk3588s-opp.dtsi and rk3588j-opp.dtsi in a follow-up patch?
>
> The trouble with including "devices" into the filenames is, well,
> the fact that those files isn't about any devices, but about the
> SoC variants.  Thus, "devices" simply wouldn't fit there.

My thinking was along the lines of "here is the file that contains all
DT nodes for built-in _devices_ (as in on-chip IP blocks) on RK3588 -
thus it's called rk3588-devices.dtsi", and "here's the file that
contains operating parameters that distinguish RK3588 and RK3588s from
RK3588j - it's called rk3588s-opp.dtsi"

> Moreover, in the envisioned scheme there should be no separate
> OPP .dtsi files;  the OPP data should go directly into the new
> rk3588.dtsi, rk3588s.dtsi and rk3588j.dtsi files, where it actually
> belongs.  That's why those .dtsi files exist and are mostly empty,
> at least the way I see it.  I'll get back to this below.
>
> > Then we keep "thin" versions of rk3588.dtsi, rk3588s.dtsi and
> > rk3588j.dtsi for board files to include. The mix-and-match of
> > different on-chip devices and different OPPs then gets transparently
> > represented within those "thin" .dtsi, something like this:
> >
> > rk3588.dtsi:
> > #include "rk3588-devices.dtsi"
> > #include "rk3588s-opp.dtsi"
> >
> > rk3588s.dtsi:
> > #include "rk3588s-devices.dtsi"
> > #include "rk3588s-opp.dtsi"
> >
> > rk3588j.dtsi:
> > #include "rk3588-devices.dtsi"
> > #include "rk3588j-opp.dtsi"
>
> Such a layout, in general, has also crossed my mind, but my conclusion
> was that having the per-SoC-variant OPP data specified directly in the
> reworked rk3588.dtsi, rk3588s.dtsi and rk3588j.dtsi files is a better
> option in the long term, even if we end up that way with rk3588.dtsi and
> rk3588s.dtsi repeating most (if not all) of the same OPP data.

From all the info we have available so far, RK3588 and RK3588s share
identical OPPs, so having one file with OPPs that both variants refer
to should be more maintainable (and fewer lines of DT code).

All in all, it appears that RK3588 and RK3588j have an identical set
of built-in devices, but different OPPs due to RK3588j being spec'd
for industrial use which apparently has different requirements. At the
same time, RK3588s uses an identical set of OPPs as RK3588 but a
reduced set of built-in devices. The combination of includes I
proposed above makes this explicit.

As for RK3588m, it seems to include all the same devices as RK3588 and
RK3588j, but a slightly modified set of OPPs compared to RK3588j. We
don't have any boards using that variant in the mainline tree right
now, but it would be easy, when the need arises, to add something
along the lines of:

rk3588m.dtsi:
#include "rk3588-devices.dtsi"
#include "rk3588m-opp.dtsi"

rk3588m-opp.dtsi:
#include "rk3588j-opp.dtsi"
&cluster0_opp_table {
        /delete-node/ opp-1296000000;
};
...

> That way we'll have no roadblocks if, at some point, we end up with
> having
> different OPPs defined for the RK3588 and the RK3588S variants.  Or
> maybe
> even for the RK3582, which we don't know much about yet.

Guess we'll deal with that one once we stumble upon an actual RK3582
board out in the wild and heading to the mainline kernel tree :)

Best regards,
Alexey

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 1%]

* Re: [RFC PATCH] arm64: dts: rockchip: Make preparations for per-RK3588-variant OPPs
@ 2024-05-29 12:04  1%       ` Alexey Charkov
  0 siblings, 0 replies; 200+ results
From: Alexey Charkov @ 2024-05-29 12:04 UTC (permalink / raw)
  To: Dragan Simic
  Cc: linux-rockchip, heiko, linux-arm-kernel, devicetree, robh+dt,
	krzk+dt, conor+dt, linux-kernel, quentin.schulz, wens,
	daniel.lezcano, didi.debian, krzysztof.kozlowski+dt,
	viresh.kumar

On Wed, May 29, 2024 at 2:45 PM Dragan Simic <dsimic@manjaro.org> wrote:
>
> Hello Alexey.
>
> On 2024-05-29 11:57, Alexey Charkov wrote:
> > On Wed, May 29, 2024 at 6:14 AM Dragan Simic <dsimic@manjaro.org>
> > wrote:
> >>
> >> Rename and modify the RK3588 dtsi files a bit, to make preparations
> >> for
> >> the ability to specify different CPU and GPU OPPs for each of the
> >> supported
> >> RK3588 SoC variants, including the RK3588J.
> >>
> >> As already discussed, [1][2][3] some of the different RK3588 SoC
> >> variants
> >> require different OPPs, and it makes more sense to have the OPPs
> >> already
> >> defined when a board dts includes one of the SoC dtsi files
> >> (rk3588.dtsi,
> >> rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts
> >> file to
> >> also include a separate rk3588*-opp.dtsi file.  The choice of the SoC
> >> variant
> >> is already made by the inclusion of the SoC dtsi file, and it doesn't
> >> make
> >> much sense to, effectively, allow the board dts file to include and
> >> use an
> >> incompatible set of OPPs for the already selected SoC variant.
> >
> > Indeed, including just one .dtsi for the correct SoC variant and not
> > having to bother about what other bits and pieces are required to use
> > the full SoC functionality sounds great! Thanks for putting this
> > together so promptly!
>
> You're welcome. :)
>
> > Some considerations below.
> >
> >> No intended functional changes are introduced.  (Still to be
> >> additionally
> >> verified if the patch moves forward from the RFC state.)
> >>
> >> [1]
> >> https://lore.kernel.org/linux-rockchip/646a33e0-5c1b-471c-8183-2c0df40ea51a@cherry.de/
> >> [2]
> >> https://lore.kernel.org/linux-rockchip/CABjd4Yxi=+3gkNnH3BysUzzYsji-=-yROtzEc8jM_g0roKB0-w@mail.gmail.com/
> >> [3]
> >> https://lore.kernel.org/linux-rockchip/035a274be262528012173d463e25b55f@manjaro.org/
> >>
> >> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
> >> ---
> >>  ...inctrl.dtsi => rk3588-common-pinctrl.dtsi} |    0
> >
> > Renaming the pinctrl includes seems superfluous - maybe keep them as
> > they were to minimize churn?
>
> Believe it or not, the same thoughts crossed my mind.  However,
> after thinking a bit about it, I concluded that renaming the pinctrl
> .dtsi files as well makes the overall naming of the reworked RK3588
> .dtsi files more consistent.
>
> It's also rather neat to have the "common" and "fullfat" file pairs
> together in the arch/arm64/boot/dts/rockchip directory listing, when
> it's sorted by the file name, which is the default in most (if not
> all) environments.
>
> >>  .../{rk3588s.dtsi => rk3588-common.dtsi}      |    2 +-
> >>  ...nctrl.dtsi => rk3588-fullfat-pinctrl.dtsi} |    0
> >>  .../{rk3588.dtsi => rk3588-fullfat.dtsi}      |    4 +-
> >
> > To me, "fullfat" doesn't look super descriptive, albeit fun :)
>
> Yeah, I resorted to "fullfat" as some kind of a funny option. :)
> That's for the "beefy" SoC variants, so it kind of fits well. :)
>
> > How about we rename the existing rk3588.dtsi and rk3588s.dtsi to
> > something like rk3588-devices.dtsi and rk3588s-devices.dtsi
> > (preserving the inheritance between them), and then I add
> > rk3588s-opp.dtsi and rk3588j-opp.dtsi in a follow-up patch?
>
> The trouble with including "devices" into the filenames is, well,
> the fact that those files isn't about any devices, but about the
> SoC variants.  Thus, "devices" simply wouldn't fit there.

My thinking was along the lines of "here is the file that contains all
DT nodes for built-in _devices_ (as in on-chip IP blocks) on RK3588 -
thus it's called rk3588-devices.dtsi", and "here's the file that
contains operating parameters that distinguish RK3588 and RK3588s from
RK3588j - it's called rk3588s-opp.dtsi"

> Moreover, in the envisioned scheme there should be no separate
> OPP .dtsi files;  the OPP data should go directly into the new
> rk3588.dtsi, rk3588s.dtsi and rk3588j.dtsi files, where it actually
> belongs.  That's why those .dtsi files exist and are mostly empty,
> at least the way I see it.  I'll get back to this below.
>
> > Then we keep "thin" versions of rk3588.dtsi, rk3588s.dtsi and
> > rk3588j.dtsi for board files to include. The mix-and-match of
> > different on-chip devices and different OPPs then gets transparently
> > represented within those "thin" .dtsi, something like this:
> >
> > rk3588.dtsi:
> > #include "rk3588-devices.dtsi"
> > #include "rk3588s-opp.dtsi"
> >
> > rk3588s.dtsi:
> > #include "rk3588s-devices.dtsi"
> > #include "rk3588s-opp.dtsi"
> >
> > rk3588j.dtsi:
> > #include "rk3588-devices.dtsi"
> > #include "rk3588j-opp.dtsi"
>
> Such a layout, in general, has also crossed my mind, but my conclusion
> was that having the per-SoC-variant OPP data specified directly in the
> reworked rk3588.dtsi, rk3588s.dtsi and rk3588j.dtsi files is a better
> option in the long term, even if we end up that way with rk3588.dtsi and
> rk3588s.dtsi repeating most (if not all) of the same OPP data.

From all the info we have available so far, RK3588 and RK3588s share
identical OPPs, so having one file with OPPs that both variants refer
to should be more maintainable (and fewer lines of DT code).

All in all, it appears that RK3588 and RK3588j have an identical set
of built-in devices, but different OPPs due to RK3588j being spec'd
for industrial use which apparently has different requirements. At the
same time, RK3588s uses an identical set of OPPs as RK3588 but a
reduced set of built-in devices. The combination of includes I
proposed above makes this explicit.

As for RK3588m, it seems to include all the same devices as RK3588 and
RK3588j, but a slightly modified set of OPPs compared to RK3588j. We
don't have any boards using that variant in the mainline tree right
now, but it would be easy, when the need arises, to add something
along the lines of:

rk3588m.dtsi:
#include "rk3588-devices.dtsi"
#include "rk3588m-opp.dtsi"

rk3588m-opp.dtsi:
#include "rk3588j-opp.dtsi"
&cluster0_opp_table {
        /delete-node/ opp-1296000000;
};
...

> That way we'll have no roadblocks if, at some point, we end up with
> having
> different OPPs defined for the RK3588 and the RK3588S variants.  Or
> maybe
> even for the RK3582, which we don't know much about yet.

Guess we'll deal with that one once we stumble upon an actual RK3582
board out in the wild and heading to the mainline kernel tree :)

Best regards,
Alexey

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

^ permalink raw reply	[relevance 1%]

* Re: [RFC PATCH] arm64: dts: rockchip: Make preparations for per-RK3588-variant OPPs
@ 2024-05-29 12:04  1%       ` Alexey Charkov
  0 siblings, 0 replies; 200+ results
From: Alexey Charkov @ 2024-05-29 12:04 UTC (permalink / raw)
  To: Dragan Simic
  Cc: linux-rockchip, heiko, linux-arm-kernel, devicetree, robh+dt,
	krzk+dt, conor+dt, linux-kernel, quentin.schulz, wens,
	daniel.lezcano, didi.debian, krzysztof.kozlowski+dt,
	viresh.kumar

On Wed, May 29, 2024 at 2:45 PM Dragan Simic <dsimic@manjaro.org> wrote:
>
> Hello Alexey.
>
> On 2024-05-29 11:57, Alexey Charkov wrote:
> > On Wed, May 29, 2024 at 6:14 AM Dragan Simic <dsimic@manjaro.org>
> > wrote:
> >>
> >> Rename and modify the RK3588 dtsi files a bit, to make preparations
> >> for
> >> the ability to specify different CPU and GPU OPPs for each of the
> >> supported
> >> RK3588 SoC variants, including the RK3588J.
> >>
> >> As already discussed, [1][2][3] some of the different RK3588 SoC
> >> variants
> >> require different OPPs, and it makes more sense to have the OPPs
> >> already
> >> defined when a board dts includes one of the SoC dtsi files
> >> (rk3588.dtsi,
> >> rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts
> >> file to
> >> also include a separate rk3588*-opp.dtsi file.  The choice of the SoC
> >> variant
> >> is already made by the inclusion of the SoC dtsi file, and it doesn't
> >> make
> >> much sense to, effectively, allow the board dts file to include and
> >> use an
> >> incompatible set of OPPs for the already selected SoC variant.
> >
> > Indeed, including just one .dtsi for the correct SoC variant and not
> > having to bother about what other bits and pieces are required to use
> > the full SoC functionality sounds great! Thanks for putting this
> > together so promptly!
>
> You're welcome. :)
>
> > Some considerations below.
> >
> >> No intended functional changes are introduced.  (Still to be
> >> additionally
> >> verified if the patch moves forward from the RFC state.)
> >>
> >> [1]
> >> https://lore.kernel.org/linux-rockchip/646a33e0-5c1b-471c-8183-2c0df40ea51a@cherry.de/
> >> [2]
> >> https://lore.kernel.org/linux-rockchip/CABjd4Yxi=+3gkNnH3BysUzzYsji-=-yROtzEc8jM_g0roKB0-w@mail.gmail.com/
> >> [3]
> >> https://lore.kernel.org/linux-rockchip/035a274be262528012173d463e25b55f@manjaro.org/
> >>
> >> Signed-off-by: Dragan Simic <dsimic@manjaro.org>
> >> ---
> >>  ...inctrl.dtsi => rk3588-common-pinctrl.dtsi} |    0
> >
> > Renaming the pinctrl includes seems superfluous - maybe keep them as
> > they were to minimize churn?
>
> Believe it or not, the same thoughts crossed my mind.  However,
> after thinking a bit about it, I concluded that renaming the pinctrl
> .dtsi files as well makes the overall naming of the reworked RK3588
> .dtsi files more consistent.
>
> It's also rather neat to have the "common" and "fullfat" file pairs
> together in the arch/arm64/boot/dts/rockchip directory listing, when
> it's sorted by the file name, which is the default in most (if not
> all) environments.
>
> >>  .../{rk3588s.dtsi => rk3588-common.dtsi}      |    2 +-
> >>  ...nctrl.dtsi => rk3588-fullfat-pinctrl.dtsi} |    0
> >>  .../{rk3588.dtsi => rk3588-fullfat.dtsi}      |    4 +-
> >
> > To me, "fullfat" doesn't look super descriptive, albeit fun :)
>
> Yeah, I resorted to "fullfat" as some kind of a funny option. :)
> That's for the "beefy" SoC variants, so it kind of fits well. :)
>
> > How about we rename the existing rk3588.dtsi and rk3588s.dtsi to
> > something like rk3588-devices.dtsi and rk3588s-devices.dtsi
> > (preserving the inheritance between them), and then I add
> > rk3588s-opp.dtsi and rk3588j-opp.dtsi in a follow-up patch?
>
> The trouble with including "devices" into the filenames is, well,
> the fact that those files isn't about any devices, but about the
> SoC variants.  Thus, "devices" simply wouldn't fit there.

My thinking was along the lines of "here is the file that contains all
DT nodes for built-in _devices_ (as in on-chip IP blocks) on RK3588 -
thus it's called rk3588-devices.dtsi", and "here's the file that
contains operating parameters that distinguish RK3588 and RK3588s from
RK3588j - it's called rk3588s-opp.dtsi"

> Moreover, in the envisioned scheme there should be no separate
> OPP .dtsi files;  the OPP data should go directly into the new
> rk3588.dtsi, rk3588s.dtsi and rk3588j.dtsi files, where it actually
> belongs.  That's why those .dtsi files exist and are mostly empty,
> at least the way I see it.  I'll get back to this below.
>
> > Then we keep "thin" versions of rk3588.dtsi, rk3588s.dtsi and
> > rk3588j.dtsi for board files to include. The mix-and-match of
> > different on-chip devices and different OPPs then gets transparently
> > represented within those "thin" .dtsi, something like this:
> >
> > rk3588.dtsi:
> > #include "rk3588-devices.dtsi"
> > #include "rk3588s-opp.dtsi"
> >
> > rk3588s.dtsi:
> > #include "rk3588s-devices.dtsi"
> > #include "rk3588s-opp.dtsi"
> >
> > rk3588j.dtsi:
> > #include "rk3588-devices.dtsi"
> > #include "rk3588j-opp.dtsi"
>
> Such a layout, in general, has also crossed my mind, but my conclusion
> was that having the per-SoC-variant OPP data specified directly in the
> reworked rk3588.dtsi, rk3588s.dtsi and rk3588j.dtsi files is a better
> option in the long term, even if we end up that way with rk3588.dtsi and
> rk3588s.dtsi repeating most (if not all) of the same OPP data.

From all the info we have available so far, RK3588 and RK3588s share
identical OPPs, so having one file with OPPs that both variants refer
to should be more maintainable (and fewer lines of DT code).

All in all, it appears that RK3588 and RK3588j have an identical set
of built-in devices, but different OPPs due to RK3588j being spec'd
for industrial use which apparently has different requirements. At the
same time, RK3588s uses an identical set of OPPs as RK3588 but a
reduced set of built-in devices. The combination of includes I
proposed above makes this explicit.

As for RK3588m, it seems to include all the same devices as RK3588 and
RK3588j, but a slightly modified set of OPPs compared to RK3588j. We
don't have any boards using that variant in the mainline tree right
now, but it would be easy, when the need arises, to add something
along the lines of:

rk3588m.dtsi:
#include "rk3588-devices.dtsi"
#include "rk3588m-opp.dtsi"

rk3588m-opp.dtsi:
#include "rk3588j-opp.dtsi"
&cluster0_opp_table {
        /delete-node/ opp-1296000000;
};
...

> That way we'll have no roadblocks if, at some point, we end up with
> having
> different OPPs defined for the RK3588 and the RK3588S variants.  Or
> maybe
> even for the RK3582, which we don't know much about yet.

Guess we'll deal with that one once we stumble upon an actual RK3582
board out in the wild and heading to the mainline kernel tree :)

Best regards,
Alexey

^ permalink raw reply	[relevance 1%]

* Re: [PATCH 3/8] gpio: tqmx86: change tqmx86_gpio_write() order of arguments to match regmap API
  @ 2024-05-29 12:03  0%   ` Bartosz Golaszewski
  2024-05-29 12:11  0%     ` Andrew Lunn
  0 siblings, 1 reply; 200+ results
From: Bartosz Golaszewski @ 2024-05-29 12:03 UTC (permalink / raw)
  To: Matthias Schiffer
  Cc: Linus Walleij, Andrew Lunn, linux-gpio, linux-kernel,
	Gregor Herburger, linux

On Wed, May 29, 2024 at 9:46 AM Matthias Schiffer
<matthias.schiffer@ew.tq-group.com> wrote:
>
> Conversion to actually use regmap does not seem useful for this driver,
> as regmap can't properly represent separate read-only and write-only
> registers at the same address, but we can at least match the API to make
> the code clearer.
>
> No functional change intended.
>
> Fixes: b868db94a6a7 ("gpio: tqmx86: Add GPIO from for this IO controller")

This is not a fix.

Bart

^ permalink raw reply	[relevance 0%]

* Re: [PATCH 00/20] iommu: Refactoring domain allocation interface
  @ 2024-05-29 12:02  0%   ` Baolu Lu
  0 siblings, 0 replies; 200+ results
From: Baolu Lu @ 2024-05-29 12:02 UTC (permalink / raw)
  To: Yi Liu, Joerg Roedel, Will Deacon, Robin Murphy, Jason Gunthorpe,
	Kevin Tian
  Cc: baolu.lu, David Airlie, Daniel Vetter, Kalle Valo,
	Bjorn Andersson, Mathieu Poirier, Alex Williamson, mst,
	Jason Wang, Thierry Reding, Jonathan Hunter, Mikko Perttunen,
	iommu, dri-devel, linux-kernel

On 2024/5/29 17:03, Yi Liu wrote:
> On 2024/5/29 13:32, Lu Baolu wrote:
>> The IOMMU subsystem has undergone some changes, including the removal
>> of iommu_ops from the bus structure. Consequently, the existing domain
>> allocation interface, which relies on a bus type argument, is no longer
>> relevant:
>>
>>      struct iommu_domain *iommu_domain_alloc(struct bus_type *bus)
>>
>> This series is designed to refactor the use of this interface. It
>> proposes two new interfaces to replace iommu_domain_alloc():
>>
>> - iommu_user_domain_alloc(): This interface is intended for allocating
>>    iommu domains managed by userspace for device passthrough scenarios,
>>    such as those used by iommufd, vfio, and vdpa. It clearly indicates
>>    that the domain is for user-managed device DMA.
> 
> user paging domain? It looks to me user domain includes the nested domains
> as well.

Yes, nested domain is a user domain. The iommu driver should implement
iommu_ops->domain_alloc_user for nested domain allocation.

> 
>>    If an IOMMU driver does not implement iommu_ops->domain_alloc_user,
>>    this interface will rollback to the generic paging domain allocation.
>>
>> - iommu_paging_domain_alloc(): This interface is for allocating iommu
>>    domains managed by kernel drivers for kernel DMA purposes. It takes a
>>    device pointer as a parameter, which better reflects the current
>>    design of the IOMMU subsystem.
>>
>> The majority of device drivers currently using iommu_domain_alloc() do
>> so to allocate a domain for a specific device and then attach that
>> domain to the device. These cases can be straightforwardly migrated to
>> the new interfaces.
>>
>> However, there are some drivers with more complex use cases that do
>> not fit neatly into this new scheme. For example:
>>
>> $ git grep "= iommu_domain_alloc"
>> arch/arm/mm/dma-mapping.c:      mapping->domain = 
>> iommu_domain_alloc(bus);
>> drivers/gpu/drm/rockchip/rockchip_drm_drv.c:    private->domain = 
>> iommu_domain_alloc(private->iommu_dev->bus);
>> drivers/gpu/drm/tegra/drm.c:            tegra->domain = 
>> iommu_domain_alloc(&platform_bus_type);
>> drivers/infiniband/hw/usnic/usnic_uiom.c:       pd->domain = domain = 
>> iommu_domain_alloc(dev->bus);
>>
>> This series leave those cases unchanged and keep iommu_domain_alloc()
>> for their usage. But new drivers should not use it anymore.
> 
> does it mean there is still domains allocated via iommu_domain_alloc()
> on VT-d platform?

I think the drivers mentioned above do not run on x86 platforms, or do
they?

Best regards,
baolu

^ permalink raw reply	[relevance 0%]

* Re: [syzbot] [ntfs3?] KASAN: slab-use-after-free Read in chrdev_open
  2024-05-29 11:49  3% ` Hillf Danton
@ 2024-05-29 12:02  4%   ` syzbot
  0 siblings, 0 replies; 200+ results
From: syzbot @ 2024-05-29 12:02 UTC (permalink / raw)
  To: hdanton, linux-kernel, syzkaller-bugs

Hello,

syzbot has tested the proposed patch but the reproducer is still triggering an issue:
KASAN: slab-use-after-free Read in chrdev_open

loop0: detected capacity change from 0 to 4096
==================================================================
BUG: KASAN: slab-use-after-free in __list_add_valid_or_report+0x4c/0xf0 lib/list_debug.c:29
Read of size 8 at addr ffff888063833a48 by task syz-executor.0/5470

CPU: 1 PID: 5470 Comm: syz-executor.0 Not tainted 6.10.0-rc1-syzkaller-00021-ge0cce98fe279-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Call Trace:
 <TASK>
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x169/0x550 mm/kasan/report.c:488
 kasan_report+0x143/0x180 mm/kasan/report.c:601
 __list_add_valid_or_report+0x4c/0xf0 lib/list_debug.c:29
 __list_add_valid include/linux/list.h:88 [inline]
 __list_add include/linux/list.h:150 [inline]
 list_add include/linux/list.h:169 [inline]
 chrdev_open+0x2a9/0x630 fs/char_dev.c:396
 do_dentry_open+0x96d/0x1700 fs/open.c:959
 do_open fs/namei.c:3650 [inline]
 path_openat+0x289f/0x3280 fs/namei.c:3807
 do_filp_open+0x235/0x490 fs/namei.c:3834
 do_sys_openat2+0x13e/0x1d0 fs/open.c:1409
 do_sys_open fs/open.c:1424 [inline]
 __do_sys_openat fs/open.c:1440 [inline]
 __se_sys_openat fs/open.c:1435 [inline]
 __x64_sys_openat+0x247/0x2a0 fs/open.c:1435
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f94f7c7dea9
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f94f89bf0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
RAX: ffffffffffffffda RBX: 00007f94f7dabf80 RCX: 00007f94f7c7dea9
RDX: 0000000000000000 RSI: 0000000020002140 RDI: ffffffffffffff9c
RBP: 00007f94f7cca4a4 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f94f7dabf80 R15: 00007ffda7828a58
 </TASK>

Allocated by task 5456:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 unpoison_slab_object mm/kasan/common.c:312 [inline]
 __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
 kasan_slab_alloc include/linux/kasan.h:201 [inline]
 slab_post_alloc_hook mm/slub.c:3940 [inline]
 slab_alloc_node mm/slub.c:4000 [inline]
 kmem_cache_alloc_lru_noprof+0x139/0x2b0 mm/slub.c:4019
 ntfs_alloc_inode+0x28/0x80 fs/ntfs3/super.c:563
 alloc_inode fs/inode.c:261 [inline]
 new_inode_pseudo+0x69/0x1e0 fs/inode.c:1007
 new_inode+0x22/0x1d0 fs/inode.c:1033
 ntfs_new_inode+0x45/0x100 fs/ntfs3/fsntfs.c:1688
 ntfs_create_inode+0x5f1/0x3680 fs/ntfs3/inode.c:1347
 ntfs_mknod+0x3c/0x50 fs/ntfs3/namei.c:122
 vfs_mknod+0x36d/0x3b0 fs/namei.c:4009
 do_mknodat+0x3ec/0x5b0
 __do_sys_mknodat fs/namei.c:4087 [inline]
 __se_sys_mknodat fs/namei.c:4084 [inline]
 __x64_sys_mknodat+0xa9/0xc0 fs/namei.c:4084
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Freed by task 5389:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
 kasan_slab_free include/linux/kasan.h:184 [inline]
 slab_free_hook mm/slub.c:2195 [inline]
 slab_free mm/slub.c:4436 [inline]
 kmem_cache_free+0x145/0x350 mm/slub.c:4511
 rcu_do_batch kernel/rcu/tree.c:2535 [inline]
 rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2809
 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554
 __do_softirq kernel/softirq.c:588 [inline]
 invoke_softirq kernel/softirq.c:428 [inline]
 __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637
 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649
 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
 sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702

Last potentially related work creation:
 kasan_save_stack+0x3f/0x60 mm/kasan/common.c:47
 __kasan_record_aux_stack+0xac/0xc0 mm/kasan/generic.c:541
 __call_rcu_common kernel/rcu/tree.c:3072 [inline]
 call_rcu+0x167/0xa70 kernel/rcu/tree.c:3176
 __dentry_kill+0x20d/0x630 fs/dcache.c:603
 shrink_kill+0xa9/0x2c0 fs/dcache.c:1048
 shrink_dentry_list+0x2c0/0x5b0 fs/dcache.c:1075
 shrink_dcache_parent+0xcb/0x3b0
 do_one_tree+0x23/0xe0 fs/dcache.c:1538
 shrink_dcache_for_umount+0x7d/0x130 fs/dcache.c:1555
 generic_shutdown_super+0x6a/0x2d0 fs/super.c:620
 kill_block_super+0x44/0x90 fs/super.c:1676
 ntfs3_kill_sb+0x44/0x1b0 fs/ntfs3/super.c:1798
 deactivate_locked_super+0xc4/0x130 fs/super.c:473
 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1267
 task_work_run+0x24f/0x310 kernel/task_work.c:180
 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:114 [inline]
 exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]
 __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
 syscall_exit_to_user_mode+0x168/0x370 kernel/entry/common.c:218
 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

The buggy address belongs to the object at ffff8880638333a0
 which belongs to the cache ntfs_inode_cache of size 1760
The buggy address is located 1704 bytes inside of
 freed 1760-byte region [ffff8880638333a0, ffff888063833a80)

The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x63830
head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0
memcg:ffff88801f2d5c01
flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffefff(slab)
raw: 00fff00000000040 ffff888016f46500 dead000000000122 0000000000000000
raw: 0000000000000000 0000000000110011 00000001ffffefff ffff88801f2d5c01
head: 00fff00000000040 ffff888016f46500 dead000000000122 0000000000000000
head: 0000000000000000 0000000000110011 00000001ffffefff ffff88801f2d5c01
head: 00fff00000000003 ffffea00018e0c01 ffffffffffffffff 0000000000000000
head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
page last allocated via order 3, migratetype Reclaimable, gfp_mask 0x1d2050(__GFP_IO|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_RECLAIMABLE), pid 5456, tgid 5455 (syz-executor.0), ts 83649077084, free_ts 15607625487
 set_page_owner include/linux/page_owner.h:32 [inline]
 post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1468
 prep_new_page mm/page_alloc.c:1476 [inline]
 get_page_from_freelist+0x2e2d/0x2ee0 mm/page_alloc.c:3402
 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4660
 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline]
 alloc_pages_node_noprof include/linux/gfp.h:296 [inline]
 alloc_slab_page+0x5f/0x120 mm/slub.c:2264
 allocate_slab+0x5a/0x2e0 mm/slub.c:2427
 new_slab mm/slub.c:2480 [inline]
 ___slab_alloc+0xcd1/0x14b0 mm/slub.c:3666
 __slab_alloc+0x58/0xa0 mm/slub.c:3756
 __slab_alloc_node mm/slub.c:3809 [inline]
 slab_alloc_node mm/slub.c:3988 [inline]
 kmem_cache_alloc_lru_noprof+0x1c5/0x2b0 mm/slub.c:4019
 ntfs_alloc_inode+0x28/0x80 fs/ntfs3/super.c:563
 alloc_inode fs/inode.c:261 [inline]
 iget5_locked+0xa4/0x280 fs/inode.c:1235
 ntfs_iget5+0xd5/0x3b10 fs/ntfs3/inode.c:532
 ntfs_security_init+0x110/0xcc0 fs/ntfs3/fsntfs.c:1882
 ntfs_fill_super+0x4329/0x4a20 fs/ntfs3/super.c:1530
 get_tree_bdev+0x3f7/0x570 fs/super.c:1615
 vfs_get_tree+0x90/0x2a0 fs/super.c:1780
 do_new_mount+0x2be/0xb40 fs/namespace.c:3352
page last free pid 1 tgid 1 stack trace:
 reset_page_owner include/linux/page_owner.h:25 [inline]
 free_pages_prepare mm/page_alloc.c:1088 [inline]
 free_unref_page+0xd19/0xea0 mm/page_alloc.c:2565
 free_contig_range+0x9e/0x160 mm/page_alloc.c:6619
 destroy_args+0x8a/0x890 mm/debug_vm_pgtable.c:1038
 debug_vm_pgtable+0x4be/0x550 mm/debug_vm_pgtable.c:1418
 do_one_initcall+0x248/0x880 init/main.c:1267
 do_initcall_level+0x157/0x210 init/main.c:1329
 do_initcalls+0x3f/0x80 init/main.c:1345
 kernel_init_freeable+0x435/0x5d0 init/main.c:1578
 kernel_init+0x1d/0x2b0 init/main.c:1467
 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Memory state around the buggy address:
 ffff888063833900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 ffff888063833980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff888063833a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                                              ^
 ffff888063833a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff888063833b00: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================


Tested on:

commit:         e0cce98f Merge tag 'tpmdd-next-6.10-rc2' of git://git...
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
console output: https://syzkaller.appspot.com/x/log.txt?x=10edb0f2980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=47d282ddffae809f
dashboard link: https://syzkaller.appspot.com/bug?extid=5d34cc6474499a5ff516
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
patch:          https://syzkaller.appspot.com/x/patch.diff?x=12fbe90c980000


^ permalink raw reply	[relevance 4%]

* Re: [PATCH 1/1] RDMA/mlx5: Release CPU for other processes in mlx5_free_cmd_msg()
  @ 2024-05-29 12:01  2%     ` Anand Khoje
  0 siblings, 0 replies; 200+ results
From: Anand Khoje @ 2024-05-29 12:01 UTC (permalink / raw)
  To: Shay Drori, linux-rdma, linux-kernel, moshe
  Cc: rama.nichanamatlu, manjunath.b.patil, netdev


On 5/26/24 20:53, Shay Drori wrote:
> Hi Anand.
>
> First, the correct Mailing list for this patch is
> netdev@vger.kernel.org, please send there the next version.
>
> On 22/05/2024 6:32, Anand Khoje wrote:
>> In non FLR context, at times CX-5 requests release of ~8 million 
>> device pages.
>> This needs humongous number of cmd mailboxes, which to be released once
>> the pages are reclaimed. Release of humongous number of cmd mailboxes
>> consuming cpu time running into many secs, with non preemptable kernels
>> is leading to critical process starving on that cpu’s RQ. To alleviate
>> this, this patch relinquishes cpu periodically but conditionally.
>>
>> Orabug: 36275016
>
> this doesn't seem relevant
>
>>
>> Signed-off-by: Anand Khoje <anand.a.khoje@oracle.com>
>> ---
>>   drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c 
>> b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
>> index 9c21bce..9fbf25d 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
>> @@ -1336,16 +1336,23 @@ static struct mlx5_cmd_msg 
>> *mlx5_alloc_cmd_msg(struct mlx5_core_dev *dev,
>>       return ERR_PTR(err);
>>   }
>>   +#define RESCHED_MSEC 2
>
>
> What if you add cond_resched() on every iteration of the loop ? Does it
> take much more time to finish 8 Million pages or same ?
> If it does matter, maybe 2 ms is too high freq ? 20 ms ? 200 ms ?
>
Shay,


There is no rule we could use, but can use only guidance/suggestions here.
Delay if too short/often relinquish leads to thrashing and high context 
switch costs,
while keeping it long/infrequent relinquish leads to RQ starvation.
This observation is based  on our applications / workload, using which a 
middle ground was chosen as 2 msecs.
But your suggestions are also very viable. Hence we are reconsidering it.

This was very helpful. thank you! I will resend a v2 after more testing.

Thanks,

Anand


> Thanks
>
>>   static void mlx5_free_cmd_msg(struct mlx5_core_dev *dev,
>>                     struct mlx5_cmd_msg *msg)
>>   {
>>       struct mlx5_cmd_mailbox *head = msg->next;
>>       struct mlx5_cmd_mailbox *next;
>> +    unsigned long start_time = jiffies;
>>         while (head) {
>>           next = head->next;
>>           free_cmd_box(dev, head);
>>           head = next;
>> +        if (time_after(jiffies, start_time + 
>> msecs_to_jiffies(RESCHED_MSEC))) {
>> +            mlx5_core_warn_rl(dev, "Spent more than %d msecs, 
>> yielding CPU\n", RESCHED_MSEC);
>> +            cond_resched();
>> +            start_time = jiffies;
>> +        }
>>       }
>>       kfree(msg);
>>   }

^ permalink raw reply	[relevance 2%]

* Re: [PATCH] of: property: Fix fw_devlink handling of interrupt-map
  2024-05-29 11:28  0%           ` Anup Patel
  (?)
@ 2024-05-29 12:00  0%             ` Marc Zyngier
  -1 siblings, 0 replies; 200+ results
From: Marc Zyngier @ 2024-05-29 12:00 UTC (permalink / raw)
  To: Anup Patel
  Cc: devicetree, linux-kernel, linux-arm-kernel, linux-riscv,
	Saravana Kannan, Rob Herring

On Wed, 29 May 2024 12:28:34 +0100,
Anup Patel <apatel@ventanamicro.com> wrote:
> 
> On Wed, May 29, 2024 at 4:15 PM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Wed, 29 May 2024 11:16:30 +0100,
> > Anup Patel <apatel@ventanamicro.com> wrote:
> > >
> > > On Wed, May 29, 2024 at 12:03 PM Marc Zyngier <maz@kernel.org> wrote:
> > > >
> > > > On Wed, 29 May 2024 06:15:52 +0100,
> > > > Anup Patel <apatel@ventanamicro.com> wrote:
> > > > >
> > > > > On Tue, May 28, 2024 at 10:11 PM Marc Zyngier <maz@kernel.org> wrote:
> > > > > >
> > > > > > Commit d976c6f4b32c ("of: property: Add fw_devlink support for
> > > > > > interrupt-map property") tried to do what it says on the tin,
> > > > > > but failed on a couple of points:
> > > > > >
> > > > > > - it confuses bytes and cells. Not a huge deal, except when it
> > > > > >   comes to pointer arithmetic
> > > > > >
> > > > > > - it doesn't really handle anything but interrupt-maps that have
> > > > > >   their parent #address-cells set to 0
> > > > > >
> > > > > > The combinations of the two leads to some serious fun on my M1
> > > > > > box, with plenty of WARN-ON() firing all over the shop, and
> > > > > > amusing values being generated for interrupt specifiers.
> > > > > >
> > > > > > Address both issues so that I can boot my machines again.
> > > > > >
> > > > > > Fixes: d976c6f4b32c ("of: property: Add fw_devlink support for interrupt-map property")
> > > > > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > > > > Cc: Anup Patel <apatel@ventanamicro.com>
> > > > > > Cc: Saravana Kannan <saravanak@google.com>
> > > > > > Cc: Rob Herring (Arm) <robh@kernel.org>
> > > > >
> > > > > Thanks for the fix patch but unfortunately it breaks for RISC-V.
> > > > >
> > > > > > ---
> > > > > >  drivers/of/property.c | 16 ++++++++++++++--
> > > > > >  1 file changed, 14 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > > > > > index 1c83e68f805b..9adebc63bea9 100644
> > > > > > --- a/drivers/of/property.c
> > > > > > +++ b/drivers/of/property.c
> > > > > > @@ -1322,7 +1322,13 @@ static struct device_node *parse_interrupt_map(struct device_node *np,
> > > > > >         addrcells = of_bus_n_addr_cells(np);
> > > > > >
> > > > > >         imap = of_get_property(np, "interrupt-map", &imaplen);
> > > > > > -       if (!imap || imaplen <= (addrcells + intcells))
> > > > > > +       imaplen /= sizeof(*imap);
> > > > > > +
> > > > > > +       /*
> > > > > > +        * Check that we have enough runway for the child unit interrupt
> > > > > > +        * specifier and a phandle. That's the bare minimum we can expect.
> > > > > > +        */
> > > > > > +       if (!imap || imaplen <= (addrcells + intcells + 1))
> > > > > >                 return NULL;
> > > > > >         imap_end = imap + imaplen;
> > > > > >
> > > > > > @@ -1346,8 +1352,14 @@ static struct device_node *parse_interrupt_map(struct device_node *np,
> > > > > >                 if (!index)
> > > > > >                         return sup_args.np;
> > > > > >
> > > > > > -               of_node_put(sup_args.np);
> > > > > > +               /*
> > > > > > +                * Account for the full parent unit interrupt specifier
> > > > > > +                * (address cells, interrupt cells, and phandle).
> > > > > > +                */
> > > > > > +               imap += of_bus_n_addr_cells(sup_args.np);
> > > > >
> > > > > This breaks for RISC-V because we don't have "#address-cells"
> > > > > property in interrupt controller DT node and of_bus_n_addr_cells()
> > > > > retrieves "#address-cells" from the parent of interrupt controller.
> > > >
> > > > That's a feature, not a bug. #address-cells, AFAICT, applies to all
> > > > child nodes until you set it otherwise.
> > > >
> > > > >
> > > > > The of_irq_parse_raw() looks for "#address-cells" property
> > > > > in the interrupt controller DT node only so we should do a
> > > > > similar thing here as well.
> > > >
> > > > This looks more like a of_irq_parse_raw() bug than anything else.
> > >
> > > If we change of_irq_parse_raw() to use of_bus_n_addr_cells()
> > > then it would still break for RISC-V.
> >
> > I'm not trying to "fix" riscv. I'm merely outlining that you are
> > relying on both broken DTs and a buggy OS.
> >
> > >
> > > Using of_bus_n_addr_cells() over here forces interrupt controller
> > > DT nodes to have a "#address-cells" DT property. There are many
> > > interrupt controller (e.g. RISC-V PLIC or RISC-V APLIC) where the
> > > DT bindings don't require "#address-cells" DT property and existing
> > > DTS files with such interrupt controllers don't have it either.
> >
> > It forces you to set #address-cells *if you rely on a different
> > value in a child node*. It's not like the semantics are new.
> 
> We don't have child nodes under the interrupt controller DT node
> (for both RISC-V PLIC and APLIC) so we certainly don't require the
> "#address-cells" property in the interrupt controller DT node.

You keep missing the point.

You *do* require it if the parent node has an #address-cells value
that doesn't apply to its children nodes. Basic property inheritance.
Interrupt controller nodes are not special in this regard (and please
allow me to think that I know a thing or two about those).

So it's not that "you don't need it". It's that "you're relying on
something that is broken".

But in your defence, the DT spec is amusingly self-contradictory:

<quote>
2.3.5. #address-cells and #size-cells

The #address-cells and #size-cells properties may be used in any
device node that has children in the devicetree hierarchy and
describes how child device nodes should be addressed. The
#address-cells property defines the number of <u32> cells used to
encode the address field in a child node’s reg property. The
#size-cells property defines the number of <u32> cells used to encode
the size field in a child node’s reg property.

The #address-cells and #size-cells properties are not inherited from
ancestors in the devicetree. They shall be explicitly defined.
</quote>

Followed by:

<quote>
2.4.3.1. interrupt-map

Note

Both the child node and the interrupt parent node are required to have
#address-cells and #interrupt-cells properties defined. If a unit
address component is not required, #address-cells shall be explicitly
defined to be zero.
</quote>

which says one thing and then the other about property inheritance,
but then asserts that #address-cells isn't optional.

> >
> > >
> > > In the RISC-V world, there have been quite a few QEMU releases
> > > where the generated DT node of the interrupt controller does not
> > > have the "#address-cells" property. This patch breaks the kernel
> > > for all such QEMU releases.
> >
> > Congratulations, you've forked DT. News at 11.
> 
> Can you elaborate how ?

You've stated it yourself. You are relying on a behaviour that
deviates from the standard by having DTs with missing properties

And since we can't travel back it time to fix this, the only solution
I can see is to support both behaviours by quirking it.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] Makefile: Fix include directory for OF_UPSTREAM
  @ 2024-05-29 12:00  0%     ` Sumit Garg
  0 siblings, 0 replies; 200+ results
From: Sumit Garg @ 2024-05-29 12:00 UTC (permalink / raw)
  To: Patrick Barsanti
  Cc: u-boot, trini, sjg, xypron.glpk, afd, marek.vasut+renesas, bb,
	mr.bossman075, leon, linux-amarula

On Wed, 29 May 2024 at 14:45, Patrick Barsanti
<patrick.barsanti@amarulasolutions.com> wrote:
>
> Hi Sumit,
>
> On Wed, 29 May 2024 at 08:57, Sumit Garg <sumit.garg@linaro.org> wrote:
>>
>> Hi Patrick,
>>
>> On Tue, 28 May 2024 at 14:16, Patrick Barsanti
>> <patrick.barsanti@amarulasolutions.com> wrote:
>> >
>> > Always prioritizing u-boot includes causes problems when trying to
>> > migrate boards to OF_UPSTREAM that have divergent devicetree files with
>> > respect to the upstream ones.
>> >
>> > For example, migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
>> > breaks it, as there are some missing defines in the local dtsi file;
>> > the solutions would be to either patch it, which defeats the purpose of
>> > OF_UPSTREAM, or delete it entirely. This last option would then break all
>> > the other boards which have not yet been migrated to OF_UPSTREAM.
>>
>> Can you elaborate more here regarding which dt-bindings headers
>> conflict? Also, is it only the DTS files consumer for those headers or
>> there are U-Boot drivers depending on them too?
>>
>> -Sumit
>
>
> Sorry, I think I have worded my commit message wrong. I should
> have used differ instead of diverge, which is slightly misleading.
>
> The specific case I am talking about can be found in:
> include/dt-bindings/clock/imx6ul-clock.h
> dts/upstream/include/dt-bindings/clock/imx6ul-clock.h
>
> The local header is missing the last commit from the kernel, which is
> 4e197ee880c2 ("clk: imx6ul: add ethernet refclock mux support").
> This added some new defines, which are not present in the u-boot
> header.
> Following this commit, the `imx6ul.dtsi` was patched in the kernel to
> use one of the new defines.
>
> Because of this, at the current state, migrating a board which is
> somehow based on `imx6ul.dtsi` will give a dtc error given by a value
> being used in the upstream dtsi which is not defined in the local
> header, because local includes always have priority with respect
> to upstream ones even when setting OF_UPSTREAM.

So you should just drop the local DT bindings header:
include/dt-bindings/clock/imx6ul-clock.h and that should resolve the
problem for you, right?

-Sumit

>
> Regards,
> Patrick
>
>>
>> >
>> > The opposite problem also exists: by always prioritizing upstream
>> > includes, if changes are made in the kernel headers and devicetree
>> > files that are not backwards compatible, again all boards which have not
>> > been migrated to OF_UPSTREAM will break.
>> >
>> > This patch fixes this problem by prioritizing upstream includes when
>> > `CONFIG_OF_UPSTREAM=y`, while keeping current prioritization when
>> > it is not.
>> >
>> > Signed-off-by: Patrick Barsanti <patrick.barsanti@amarulasolutions.com>
>> > ---
>> >  Makefile | 14 ++++++++++++++
>> >  1 file changed, 14 insertions(+)
>> >
>> > diff --git a/Makefile b/Makefile
>> > index 79b28c2d81..899ae664ca 100644
>> > --- a/Makefile
>> > +++ b/Makefile
>> > @@ -826,6 +826,19 @@ KBUILD_HOSTCFLAGS += $(if $(CONFIG_TOOLS_DEBUG),-g)
>> >
>> >  # Use UBOOTINCLUDE when you must reference the include/ directory.
>> >  # Needed to be compatible with the O= option
>> > +ifeq ($(CONFIG_OF_UPSTREAM),y)
>> > +UBOOTINCLUDE    := \
>> > +       -I$(srctree)/dts/upstream/include \
>> > +       -Iinclude \
>> > +       $(if $(KBUILD_SRC), -I$(srctree)/include) \
>> > +       $(if $(CONFIG_$(SPL_)SYS_THUMB_BUILD), \
>> > +               $(if $(CONFIG_HAS_THUMB2), \
>> > +                       $(if $(CONFIG_CPU_V7M), \
>> > +                               -I$(srctree)/arch/arm/thumb1/include), \
>> > +                       -I$(srctree)/arch/arm/thumb1/include)) \
>> > +       -I$(srctree)/arch/$(ARCH)/include \
>> > +       -include $(srctree)/include/linux/kconfig.h
>> > +else
>> >  UBOOTINCLUDE    := \
>> >         -Iinclude \
>> >         $(if $(KBUILD_SRC), -I$(srctree)/include) \
>> > @@ -837,6 +850,7 @@ UBOOTINCLUDE    := \
>> >         -I$(srctree)/arch/$(ARCH)/include \
>> >         -include $(srctree)/include/linux/kconfig.h \
>> >         -I$(srctree)/dts/upstream/include
>> > +endif
>> >
>> >  NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
>> >
>> > --
>> > 2.43.0
>> >

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] of: property: Fix fw_devlink handling of interrupt-map
@ 2024-05-29 12:00  0%             ` Marc Zyngier
  0 siblings, 0 replies; 200+ results
From: Marc Zyngier @ 2024-05-29 12:00 UTC (permalink / raw)
  To: Anup Patel
  Cc: devicetree, linux-kernel, linux-arm-kernel, linux-riscv,
	Saravana Kannan, Rob Herring

On Wed, 29 May 2024 12:28:34 +0100,
Anup Patel <apatel@ventanamicro.com> wrote:
> 
> On Wed, May 29, 2024 at 4:15 PM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Wed, 29 May 2024 11:16:30 +0100,
> > Anup Patel <apatel@ventanamicro.com> wrote:
> > >
> > > On Wed, May 29, 2024 at 12:03 PM Marc Zyngier <maz@kernel.org> wrote:
> > > >
> > > > On Wed, 29 May 2024 06:15:52 +0100,
> > > > Anup Patel <apatel@ventanamicro.com> wrote:
> > > > >
> > > > > On Tue, May 28, 2024 at 10:11 PM Marc Zyngier <maz@kernel.org> wrote:
> > > > > >
> > > > > > Commit d976c6f4b32c ("of: property: Add fw_devlink support for
> > > > > > interrupt-map property") tried to do what it says on the tin,
> > > > > > but failed on a couple of points:
> > > > > >
> > > > > > - it confuses bytes and cells. Not a huge deal, except when it
> > > > > >   comes to pointer arithmetic
> > > > > >
> > > > > > - it doesn't really handle anything but interrupt-maps that have
> > > > > >   their parent #address-cells set to 0
> > > > > >
> > > > > > The combinations of the two leads to some serious fun on my M1
> > > > > > box, with plenty of WARN-ON() firing all over the shop, and
> > > > > > amusing values being generated for interrupt specifiers.
> > > > > >
> > > > > > Address both issues so that I can boot my machines again.
> > > > > >
> > > > > > Fixes: d976c6f4b32c ("of: property: Add fw_devlink support for interrupt-map property")
> > > > > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > > > > Cc: Anup Patel <apatel@ventanamicro.com>
> > > > > > Cc: Saravana Kannan <saravanak@google.com>
> > > > > > Cc: Rob Herring (Arm) <robh@kernel.org>
> > > > >
> > > > > Thanks for the fix patch but unfortunately it breaks for RISC-V.
> > > > >
> > > > > > ---
> > > > > >  drivers/of/property.c | 16 ++++++++++++++--
> > > > > >  1 file changed, 14 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > > > > > index 1c83e68f805b..9adebc63bea9 100644
> > > > > > --- a/drivers/of/property.c
> > > > > > +++ b/drivers/of/property.c
> > > > > > @@ -1322,7 +1322,13 @@ static struct device_node *parse_interrupt_map(struct device_node *np,
> > > > > >         addrcells = of_bus_n_addr_cells(np);
> > > > > >
> > > > > >         imap = of_get_property(np, "interrupt-map", &imaplen);
> > > > > > -       if (!imap || imaplen <= (addrcells + intcells))
> > > > > > +       imaplen /= sizeof(*imap);
> > > > > > +
> > > > > > +       /*
> > > > > > +        * Check that we have enough runway for the child unit interrupt
> > > > > > +        * specifier and a phandle. That's the bare minimum we can expect.
> > > > > > +        */
> > > > > > +       if (!imap || imaplen <= (addrcells + intcells + 1))
> > > > > >                 return NULL;
> > > > > >         imap_end = imap + imaplen;
> > > > > >
> > > > > > @@ -1346,8 +1352,14 @@ static struct device_node *parse_interrupt_map(struct device_node *np,
> > > > > >                 if (!index)
> > > > > >                         return sup_args.np;
> > > > > >
> > > > > > -               of_node_put(sup_args.np);
> > > > > > +               /*
> > > > > > +                * Account for the full parent unit interrupt specifier
> > > > > > +                * (address cells, interrupt cells, and phandle).
> > > > > > +                */
> > > > > > +               imap += of_bus_n_addr_cells(sup_args.np);
> > > > >
> > > > > This breaks for RISC-V because we don't have "#address-cells"
> > > > > property in interrupt controller DT node and of_bus_n_addr_cells()
> > > > > retrieves "#address-cells" from the parent of interrupt controller.
> > > >
> > > > That's a feature, not a bug. #address-cells, AFAICT, applies to all
> > > > child nodes until you set it otherwise.
> > > >
> > > > >
> > > > > The of_irq_parse_raw() looks for "#address-cells" property
> > > > > in the interrupt controller DT node only so we should do a
> > > > > similar thing here as well.
> > > >
> > > > This looks more like a of_irq_parse_raw() bug than anything else.
> > >
> > > If we change of_irq_parse_raw() to use of_bus_n_addr_cells()
> > > then it would still break for RISC-V.
> >
> > I'm not trying to "fix" riscv. I'm merely outlining that you are
> > relying on both broken DTs and a buggy OS.
> >
> > >
> > > Using of_bus_n_addr_cells() over here forces interrupt controller
> > > DT nodes to have a "#address-cells" DT property. There are many
> > > interrupt controller (e.g. RISC-V PLIC or RISC-V APLIC) where the
> > > DT bindings don't require "#address-cells" DT property and existing
> > > DTS files with such interrupt controllers don't have it either.
> >
> > It forces you to set #address-cells *if you rely on a different
> > value in a child node*. It's not like the semantics are new.
> 
> We don't have child nodes under the interrupt controller DT node
> (for both RISC-V PLIC and APLIC) so we certainly don't require the
> "#address-cells" property in the interrupt controller DT node.

You keep missing the point.

You *do* require it if the parent node has an #address-cells value
that doesn't apply to its children nodes. Basic property inheritance.
Interrupt controller nodes are not special in this regard (and please
allow me to think that I know a thing or two about those).

So it's not that "you don't need it". It's that "you're relying on
something that is broken".

But in your defence, the DT spec is amusingly self-contradictory:

<quote>
2.3.5. #address-cells and #size-cells

The #address-cells and #size-cells properties may be used in any
device node that has children in the devicetree hierarchy and
describes how child device nodes should be addressed. The
#address-cells property defines the number of <u32> cells used to
encode the address field in a child node’s reg property. The
#size-cells property defines the number of <u32> cells used to encode
the size field in a child node’s reg property.

The #address-cells and #size-cells properties are not inherited from
ancestors in the devicetree. They shall be explicitly defined.
</quote>

Followed by:

<quote>
2.4.3.1. interrupt-map

Note

Both the child node and the interrupt parent node are required to have
#address-cells and #interrupt-cells properties defined. If a unit
address component is not required, #address-cells shall be explicitly
defined to be zero.
</quote>

which says one thing and then the other about property inheritance,
but then asserts that #address-cells isn't optional.

> >
> > >
> > > In the RISC-V world, there have been quite a few QEMU releases
> > > where the generated DT node of the interrupt controller does not
> > > have the "#address-cells" property. This patch breaks the kernel
> > > for all such QEMU releases.
> >
> > Congratulations, you've forked DT. News at 11.
> 
> Can you elaborate how ?

You've stated it yourself. You are relying on a behaviour that
deviates from the standard by having DTs with missing properties

And since we can't travel back it time to fix this, the only solution
I can see is to support both behaviours by quirking it.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] of: property: Fix fw_devlink handling of interrupt-map
@ 2024-05-29 12:00  0%             ` Marc Zyngier
  0 siblings, 0 replies; 200+ results
From: Marc Zyngier @ 2024-05-29 12:00 UTC (permalink / raw)
  To: Anup Patel
  Cc: devicetree, linux-kernel, linux-arm-kernel, linux-riscv,
	Saravana Kannan, Rob Herring

On Wed, 29 May 2024 12:28:34 +0100,
Anup Patel <apatel@ventanamicro.com> wrote:
> 
> On Wed, May 29, 2024 at 4:15 PM Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Wed, 29 May 2024 11:16:30 +0100,
> > Anup Patel <apatel@ventanamicro.com> wrote:
> > >
> > > On Wed, May 29, 2024 at 12:03 PM Marc Zyngier <maz@kernel.org> wrote:
> > > >
> > > > On Wed, 29 May 2024 06:15:52 +0100,
> > > > Anup Patel <apatel@ventanamicro.com> wrote:
> > > > >
> > > > > On Tue, May 28, 2024 at 10:11 PM Marc Zyngier <maz@kernel.org> wrote:
> > > > > >
> > > > > > Commit d976c6f4b32c ("of: property: Add fw_devlink support for
> > > > > > interrupt-map property") tried to do what it says on the tin,
> > > > > > but failed on a couple of points:
> > > > > >
> > > > > > - it confuses bytes and cells. Not a huge deal, except when it
> > > > > >   comes to pointer arithmetic
> > > > > >
> > > > > > - it doesn't really handle anything but interrupt-maps that have
> > > > > >   their parent #address-cells set to 0
> > > > > >
> > > > > > The combinations of the two leads to some serious fun on my M1
> > > > > > box, with plenty of WARN-ON() firing all over the shop, and
> > > > > > amusing values being generated for interrupt specifiers.
> > > > > >
> > > > > > Address both issues so that I can boot my machines again.
> > > > > >
> > > > > > Fixes: d976c6f4b32c ("of: property: Add fw_devlink support for interrupt-map property")
> > > > > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > > > > Cc: Anup Patel <apatel@ventanamicro.com>
> > > > > > Cc: Saravana Kannan <saravanak@google.com>
> > > > > > Cc: Rob Herring (Arm) <robh@kernel.org>
> > > > >
> > > > > Thanks for the fix patch but unfortunately it breaks for RISC-V.
> > > > >
> > > > > > ---
> > > > > >  drivers/of/property.c | 16 ++++++++++++++--
> > > > > >  1 file changed, 14 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > > > > > index 1c83e68f805b..9adebc63bea9 100644
> > > > > > --- a/drivers/of/property.c
> > > > > > +++ b/drivers/of/property.c
> > > > > > @@ -1322,7 +1322,13 @@ static struct device_node *parse_interrupt_map(struct device_node *np,
> > > > > >         addrcells = of_bus_n_addr_cells(np);
> > > > > >
> > > > > >         imap = of_get_property(np, "interrupt-map", &imaplen);
> > > > > > -       if (!imap || imaplen <= (addrcells + intcells))
> > > > > > +       imaplen /= sizeof(*imap);
> > > > > > +
> > > > > > +       /*
> > > > > > +        * Check that we have enough runway for the child unit interrupt
> > > > > > +        * specifier and a phandle. That's the bare minimum we can expect.
> > > > > > +        */
> > > > > > +       if (!imap || imaplen <= (addrcells + intcells + 1))
> > > > > >                 return NULL;
> > > > > >         imap_end = imap + imaplen;
> > > > > >
> > > > > > @@ -1346,8 +1352,14 @@ static struct device_node *parse_interrupt_map(struct device_node *np,
> > > > > >                 if (!index)
> > > > > >                         return sup_args.np;
> > > > > >
> > > > > > -               of_node_put(sup_args.np);
> > > > > > +               /*
> > > > > > +                * Account for the full parent unit interrupt specifier
> > > > > > +                * (address cells, interrupt cells, and phandle).
> > > > > > +                */
> > > > > > +               imap += of_bus_n_addr_cells(sup_args.np);
> > > > >
> > > > > This breaks for RISC-V because we don't have "#address-cells"
> > > > > property in interrupt controller DT node and of_bus_n_addr_cells()
> > > > > retrieves "#address-cells" from the parent of interrupt controller.
> > > >
> > > > That's a feature, not a bug. #address-cells, AFAICT, applies to all
> > > > child nodes until you set it otherwise.
> > > >
> > > > >
> > > > > The of_irq_parse_raw() looks for "#address-cells" property
> > > > > in the interrupt controller DT node only so we should do a
> > > > > similar thing here as well.
> > > >
> > > > This looks more like a of_irq_parse_raw() bug than anything else.
> > >
> > > If we change of_irq_parse_raw() to use of_bus_n_addr_cells()
> > > then it would still break for RISC-V.
> >
> > I'm not trying to "fix" riscv. I'm merely outlining that you are
> > relying on both broken DTs and a buggy OS.
> >
> > >
> > > Using of_bus_n_addr_cells() over here forces interrupt controller
> > > DT nodes to have a "#address-cells" DT property. There are many
> > > interrupt controller (e.g. RISC-V PLIC or RISC-V APLIC) where the
> > > DT bindings don't require "#address-cells" DT property and existing
> > > DTS files with such interrupt controllers don't have it either.
> >
> > It forces you to set #address-cells *if you rely on a different
> > value in a child node*. It's not like the semantics are new.
> 
> We don't have child nodes under the interrupt controller DT node
> (for both RISC-V PLIC and APLIC) so we certainly don't require the
> "#address-cells" property in the interrupt controller DT node.

You keep missing the point.

You *do* require it if the parent node has an #address-cells value
that doesn't apply to its children nodes. Basic property inheritance.
Interrupt controller nodes are not special in this regard (and please
allow me to think that I know a thing or two about those).

So it's not that "you don't need it". It's that "you're relying on
something that is broken".

But in your defence, the DT spec is amusingly self-contradictory:

<quote>
2.3.5. #address-cells and #size-cells

The #address-cells and #size-cells properties may be used in any
device node that has children in the devicetree hierarchy and
describes how child device nodes should be addressed. The
#address-cells property defines the number of <u32> cells used to
encode the address field in a child node’s reg property. The
#size-cells property defines the number of <u32> cells used to encode
the size field in a child node’s reg property.

The #address-cells and #size-cells properties are not inherited from
ancestors in the devicetree. They shall be explicitly defined.
</quote>

Followed by:

<quote>
2.4.3.1. interrupt-map

Note

Both the child node and the interrupt parent node are required to have
#address-cells and #interrupt-cells properties defined. If a unit
address component is not required, #address-cells shall be explicitly
defined to be zero.
</quote>

which says one thing and then the other about property inheritance,
but then asserts that #address-cells isn't optional.

> >
> > >
> > > In the RISC-V world, there have been quite a few QEMU releases
> > > where the generated DT node of the interrupt controller does not
> > > have the "#address-cells" property. This patch breaks the kernel
> > > for all such QEMU releases.
> >
> > Congratulations, you've forked DT. News at 11.
> 
> Can you elaborate how ?

You've stated it yourself. You are relying on a behaviour that
deviates from the standard by having DTs with missing properties

And since we can't travel back it time to fix this, the only solution
I can see is to support both behaviours by quirking it.

	M.

-- 
Without deviation from the norm, progress is not possible.

^ permalink raw reply	[relevance 0%]

* [poky][meta-clang][musl][kirkstone] Poky with clang coverage using musl
       [not found]     <17D34F5B4A354ADD.28935@lists.yoctoproject.org>
@ 2024-05-29 11:59  1% ` Hope Sneddon
  0 siblings, 0 replies; 200+ results
From: Hope Sneddon @ 2024-05-29 11:59 UTC (permalink / raw)
  To: poky

[-- Attachment #1: Type: text/plain, Size: 3302 bytes --]


Hi Poky community,
This is a pretty edge-case poky setup, I am trying to implement poky with clang (including code coverage flags) as the compiler and musl as the standard C library. With this setup on kirkstone (current release distro -1), I am getting the following consistent error:
| /home/user/dev/poky/build/tmp/work/cortexa57-poky-linux-musl/musl/1.2.3+gitAUTOINC+7a43f6fea9-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux-musl/aarch64-poky-linux-musl-ld: cannot find /home/user/dev/poky/build/tmp/work/cortexa57-poky-linux-musl/musl/1.2.3+gitAUTOINC+7a43f6fea9-r0/recipe-sysroot/usr/lib/clang/14.0.6/lib/linux/libclang_rt.profile-aarch64.a: No such file or directory
| clang-14: error: linker command failed with exit code 1 (use -v to see invocation)
| make: *** [Makefile:163: lib/libc.so] Error 1
| ERROR: oe_runmake failed
| WARNING: /home/user/dev/poky/build/tmp/work/cortexa57-poky-linux-musl/musl/1.2.3+gitAUTOINC+7a43f6fea9-r0/temp/run.do_compile.97139:168 exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
|       #1: bbfatal_log, /home/user/dev/poky/build/tmp/work/cortexa57-poky-linux-musl/musl/1.2.3+gitAUTOINC+7a43f6fea9-r0/temp/run.do_compile.97139, line 168
|       #2: die, /home/user/dev/poky/build/tmp/work/cortexa57-poky-linux-musl/musl/1.2.3+gitAUTOINC+7a43f6fea9-r0/temp/run.do_compile.97139, line 152
|       #3: oe_runmake, /home/user/dev/poky/build/tmp/work/cortexa57-poky-linux-musl/musl/1.2.3+gitAUTOINC+7a43f6fea9-r0/temp/run.do_compile.97139, line 147
|       #4: do_compile, /home/user/dev/poky/build/tmp/work/cortexa57-poky-linux-musl/musl/1.2.3+gitAUTOINC+7a43f6fea9-r0/temp/run.do_compile.97139, line 142
|       #5: main, /home/user/dev/poky/build/tmp/work/cortexa57-poky-linux-musl/musl/1.2.3+gitAUTOINC+7a43f6fea9-r0/temp/run.do_compile.97139, line 181
ERROR: Task (/home/user/dev/poky/build/../meta/recipes-core/musl/musl_git.bb:do_compile) failed with exit code '1'
It appears that the clang build is not making it into the target directory from the native host… I have searched the internet for what configuration element I am missing and have yet to find anything that progresses beyond this oe_runmake error. I have included my configuration above the standard poky setup below:
/home/user/dev/poky/build/conf/local.conf:
MACHINE = "qemuarm64"
SDKMACHINE = "x86_64"
TCLIBC ?= "musl"

TOOLCHAIN = "clang"
TARGET_CPPFLAGS:prepend:class-target:toolchain-clang = "-fprofile-instr-generate -fcoverage-mapping -v "
RUNTIME = "llvm"
CLANGSDK = "1"
/home/user/poky/meta/conf/bblayer.conf:
BBLAYERS += "${TOPDIR}/../meta-clang"
/home/user/dev/poky/meta-clang/recipes-devtools/clang/llvm-project-source.inc
CLANG_EXTRA_OE_VENDORS ?= "${TARGET_VENDOR} ${SDK_VENDOR} -poky"
/home/user/dev/poky/musl/configure
wrapper=yes
gcc_wrapper=no
clang_wrapper=yes
/home/user/dev/poky/musl/INSTALL
CC=musl-clang ./configure ...
Performing this setup with glibc largely works except for missing a runtime library. But the linking/ compatibility error with musl seems to be more severe than glibc.
Even some guidance on getting more logging information on the error would be helpful as invoking clang with -v doesn’t seem to produce more useful information on the source of the linking error either.
Thank you,
Hope

[-- Attachment #2: Type: text/html, Size: 6912 bytes --]

^ permalink raw reply	[relevance 1%]

* Re: [PATCH net-next v4 3/3] net/smc: Introduce IPPROTO_SMC
  @ 2024-05-29 11:58  1%   ` Wenjia Zhang
  0 siblings, 0 replies; 200+ results
From: Wenjia Zhang @ 2024-05-29 11:58 UTC (permalink / raw)
  To: D. Wythe, kgraul, jaka, wintera, guwen
  Cc: kuba, davem, netdev, linux-s390, linux-rdma, tonylu, pabeni, edumazet



On 29.05.24 05:59, D. Wythe wrote:
> From: "D. Wythe" <alibuda@linux.alibaba.com>
> 
> This patch allows to create smc socket via AF_INET,
> similar to the following code,
> 
> /* create v4 smc sock */
> v4 = socket(AF_INET, SOCK_STREAM, IPPROTO_SMC);
> 
> /* create v6 smc sock */
> v6 = socket(AF_INET6, SOCK_STREAM, IPPROTO_SMC);
> 
> There are several reasons why we believe it is appropriate here:
> 
> 1. For smc sockets, it actually use IPv4 (AF-INET) or IPv6 (AF-INET6)
> address. There is no AF_SMC address at all.
> 
> 2. Create smc socket in the AF_INET(6) path, which allows us to reuse
> the infrastructure of AF_INET(6) path, such as common ebpf hooks.
> Otherwise, smc have to implement it again in AF_SMC path.
> 
> Signed-off-by: D. Wythe <alibuda@linux.alibaba.com>
> ---
>   include/uapi/linux/in.h |   2 +
>   net/smc/Makefile        |   2 +-
>   net/smc/af_smc.c        |  36 ++++++++++++++++
>   net/smc/inet_smc.c      | 108 ++++++++++++++++++++++++++++++++++++++++++++++++
>   net/smc/inet_smc.h      |  34 +++++++++++++++
>   5 files changed, 181 insertions(+), 1 deletion(-)
>   create mode 100644 net/smc/inet_smc.c
>   create mode 100644 net/smc/inet_smc.h
> 
> diff --git a/include/uapi/linux/in.h b/include/uapi/linux/in.h
> index e682ab6..0c6322b 100644
> --- a/include/uapi/linux/in.h
> +++ b/include/uapi/linux/in.h
> @@ -83,6 +83,8 @@ enum {
>   #define IPPROTO_RAW		IPPROTO_RAW
>     IPPROTO_MPTCP = 262,		/* Multipath TCP connection		*/
>   #define IPPROTO_MPTCP		IPPROTO_MPTCP
> +  IPPROTO_SMC = 263,		/* Shared Memory Communications		*/
> +#define IPPROTO_SMC		IPPROTO_SMC
>     IPPROTO_MAX
>   };
>   #endif
> diff --git a/net/smc/Makefile b/net/smc/Makefile
> index 2c510d54..472b9ee 100644
> --- a/net/smc/Makefile
> +++ b/net/smc/Makefile
> @@ -4,6 +4,6 @@ obj-$(CONFIG_SMC)	+= smc.o
>   obj-$(CONFIG_SMC_DIAG)	+= smc_diag.o
>   smc-y := af_smc.o smc_pnet.o smc_ib.o smc_clc.o smc_core.o smc_wr.o smc_llc.o
>   smc-y += smc_cdc.o smc_tx.o smc_rx.o smc_close.o smc_ism.o smc_netlink.o smc_stats.o
> -smc-y += smc_tracepoint.o
> +smc-y += smc_tracepoint.o inet_smc.o
>   smc-$(CONFIG_SYSCTL) += smc_sysctl.o
>   smc-$(CONFIG_SMC_LO) += smc_loopback.o
> diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
> index 8e3ce76..320624c 100644
> --- a/net/smc/af_smc.c
> +++ b/net/smc/af_smc.c
> @@ -54,6 +54,7 @@
>   #include "smc_tracepoint.h"
>   #include "smc_sysctl.h"
>   #include "smc_loopback.h"
> +#include "inet_smc.h"
>   
>   static DEFINE_MUTEX(smc_server_lgr_pending);	/* serialize link group
>   						 * creation on server
> @@ -3594,9 +3595,31 @@ static int __init smc_init(void)
>   		goto out_lo;
>   	}
>   
> +	rc = proto_register(&smc_inet_prot, 1);
> +	if (rc) {
> +		pr_err("%s: proto_register smc_inet_prot fails with %d\n", __func__, rc);
> +		goto out_ulp;
> +	}
> +	inet_register_protosw(&smc_inet_protosw);
> +#if IS_ENABLED(CONFIG_IPV6)
> +	rc = proto_register(&smc_inet6_prot, 1);
> +	if (rc) {
> +		pr_err("%s: proto_register smc_inet6_prot fails with %d\n", __func__, rc);
> +		goto out_inet_prot;
> +	}
> +	inet6_register_protosw(&smc_inet6_protosw);

Comparing to inet_register_protosw(), the inet6_register_protosw() 
returns an integer. Thus, making error check and direct corresponding 
housekeeping here looks IMO much cleaner.

> +#endif
> +
>   	static_branch_enable(&tcp_have_smc);
>   	return 0;
>   
> +#if IS_ENABLED(CONFIG_IPV6)
> +out_inet_prot:
> +	inet_unregister_protosw(&smc_inet_protosw);
> +	proto_unregister(&smc_inet_prot);
> +#endif
> +out_ulp:
> +	tcp_unregister_ulp(&smc_ulp_ops);
>   out_lo:
>   	smc_loopback_exit();
>   out_ib:
> @@ -3633,6 +3656,10 @@ static int __init smc_init(void)
>   static void __exit smc_exit(void)
>   {
>   	static_branch_disable(&tcp_have_smc);
> +	inet_unregister_protosw(&smc_inet_protosw);
> +#if IS_ENABLED(CONFIG_IPV6)
> +	inet6_unregister_protosw(&smc_inet6_protosw);
> +#endif
>   	tcp_unregister_ulp(&smc_ulp_ops);
>   	sock_unregister(PF_SMC);
>   	smc_core_exit();
> @@ -3644,6 +3671,10 @@ static void __exit smc_exit(void)
>   	destroy_workqueue(smc_hs_wq);
>   	proto_unregister(&smc_proto6);
>   	proto_unregister(&smc_proto);
> +	proto_unregister(&smc_inet_prot);
> +#if IS_ENABLED(CONFIG_IPV6)
> +	proto_unregister(&smc_inet6_prot);
> +#end

Since there is already inet_smc.c, I'd recommend to group these register 
and unregister stuff respectively in functions like e.g. smc_inet_init() 
and smc_inet_exit() in inet_smc.c

>   	smc_pnet_exit();
>   	smc_nl_exit();
>   	smc_clc_exit();
> @@ -3660,4 +3691,9 @@ static void __exit smc_exit(void)
>   MODULE_LICENSE("GPL");
>   MODULE_ALIAS_NETPROTO(PF_SMC);
>   MODULE_ALIAS_TCP_ULP("smc");
> +/* 263 for IPPROTO_SMC and 1 for SOCK_STREAM */
> +MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_INET, 263, 1);
> +#if IS_ENABLED(CONFIG_IPV6)
> +MODULE_ALIAS_NET_PF_PROTO_TYPE(PF_INET6, 263, 1);
> +#endif
>   MODULE_ALIAS_GENL_FAMILY(SMC_GENL_FAMILY_NAME);
> diff --git a/net/smc/inet_smc.c b/net/smc/inet_smc.c
> new file mode 100644
> index 00000000..1ba73d7
> --- /dev/null
> +++ b/net/smc/inet_smc.c

In order to keep the consistency with the structure and function names 
in the files, I'm wondering why not to use smc_inet.h and smc_inet.c
instead of inet_smc.h and inet_smc.c respectively

> @@ -0,0 +1,108 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + *  Shared Memory Communications over RDMA (SMC-R) and RoCE
> + *
> + *  Definitions for the IPPROTO_SMC (socket related)
> + *
> + *  Copyright IBM Corp. 2016, 2018
> + *  Copyright (c) 2024, Alibaba Inc.
> + *
> + *  Author: D. Wythe <alibuda@linux.alibaba.com>
> + */
> +
> +#include "inet_smc.h"
> +#include "smc.h"
> +
> +struct proto smc_inet_prot = {
> +	.name		= "INET_SMC",
> +	.owner		= THIS_MODULE,
> +	.init		= smc_inet_init_sock,
> +	.hash		= smc_hash_sk,
> +	.unhash		= smc_unhash_sk,
> +	.release_cb	= smc_release_cb,
> +	.obj_size	= sizeof(struct smc_sock),
> +	.h.smc_hash	= &smc_v4_hashinfo,
> +	.slab_flags	= SLAB_TYPESAFE_BY_RCU,
> +};
> +
> +const struct proto_ops smc_inet_stream_ops = {
> +	.family		= PF_INET,
> +	.owner		= THIS_MODULE,
> +	.release	= smc_release,
> +	.bind		= smc_bind,
> +	.connect	= smc_connect,
> +	.socketpair	= sock_no_socketpair,
> +	.accept		= smc_accept,
> +	.getname	= smc_getname,
> +	.poll		= smc_poll,
> +	.ioctl		= smc_ioctl,
> +	.listen		= smc_listen,
> +	.shutdown	= smc_shutdown,
> +	.setsockopt	= smc_setsockopt,
> +	.getsockopt	= smc_getsockopt,
> +	.sendmsg	= smc_sendmsg,
> +	.recvmsg	= smc_recvmsg,
> +	.mmap		= sock_no_mmap,
> +	.splice_read	= smc_splice_read,
> +};
> +
> +struct inet_protosw smc_inet_protosw = {
> +	.type		= SOCK_STREAM,
> +	.protocol	= IPPROTO_SMC,
> +	.prot		= &smc_inet_prot,
> +	.ops		= &smc_inet_stream_ops,
> +	.flags		= INET_PROTOSW_ICSK,
> +};
> +
> +#if IS_ENABLED(CONFIG_IPV6)
> +struct proto smc_inet6_prot = {
> +	.name		= "INET6_SMC",
> +	.owner		= THIS_MODULE,
> +	.init		= smc_inet_init_sock,
> +	.hash		= smc_hash_sk,
> +	.unhash		= smc_unhash_sk,
> +	.release_cb	= smc_release_cb,
> +	.obj_size	= sizeof(struct smc_sock),
> +	.h.smc_hash	= &smc_v6_hashinfo,
> +	.slab_flags	= SLAB_TYPESAFE_BY_RCU,
> +};
> +
> +const struct proto_ops smc_inet6_stream_ops = {
> +	.family		= PF_INET6,
> +	.owner		= THIS_MODULE,
> +	.release	= smc_release,
> +	.bind		= smc_bind,
> +	.connect	= smc_connect,
> +	.socketpair	= sock_no_socketpair,
> +	.accept		= smc_accept,
> +	.getname	= smc_getname,
> +	.poll		= smc_poll,
> +	.ioctl		= smc_ioctl,
> +	.listen		= smc_listen,
> +	.shutdown	= smc_shutdown,
> +	.setsockopt	= smc_setsockopt,
> +	.getsockopt	= smc_getsockopt,
> +	.sendmsg	= smc_sendmsg,
> +	.recvmsg	= smc_recvmsg,
> +	.mmap		= sock_no_mmap,
> +	.splice_read	= smc_splice_read,
> +};
> +
> +struct inet_protosw smc_inet6_protosw = {
> +	.type		= SOCK_STREAM,
> +	.protocol	= IPPROTO_SMC,
> +	.prot		= &smc_inet6_prot,
> +	.ops		= &smc_inet6_stream_ops,
> +	.flags		= INET_PROTOSW_ICSK,
> +};
> +#endif
> +
> +int smc_inet_init_sock(struct sock *sk)
> +{
> +	struct net *net = sock_net(sk);
> +
> +	/* init common smc sock */
> +	smc_sk_init(net, sk, IPPROTO_SMC);
> +	/* create clcsock */
> +	return smc_create_clcsk(net, sk, sk->sk_family);
> +}
> diff --git a/net/smc/inet_smc.h b/net/smc/inet_smc.h
> new file mode 100644
> index 00000000..c55345d
> --- /dev/null
> +++ b/net/smc/inet_smc.h
> @@ -0,0 +1,34 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + *  Shared Memory Communications over RDMA (SMC-R) and RoCE
> + *
> + *  Definitions for the IPPROTO_SMC (socket related)
> +
> + *  Copyright IBM Corp. 2016
> + *  Copyright (c) 2024, Alibaba Inc.
> + *
> + *  Author: D. Wythe <alibuda@linux.alibaba.com>
> + */
> +#ifndef __INET_SMC
> +#define __INET_SMC
> +
> +#include <net/protocol.h>
> +#include <net/sock.h>
> +#include <net/tcp.h>
> +
> +extern struct proto smc_inet_prot;
> +extern const struct proto_ops smc_inet_stream_ops;
> +extern struct inet_protosw smc_inet_protosw;
> +
> +#if IS_ENABLED(CONFIG_IPV6)
> +#include <net/ipv6.h>
> +/* MUST after net/tcp.h or warning */
> +#include <net/transp_v6.h>
> +extern struct proto smc_inet6_prot;
> +extern const struct proto_ops smc_inet6_stream_ops;
> +extern struct inet_protosw smc_inet6_protosw;
> +#endif
> +
> +int smc_inet_init_sock(struct sock *sk);
> +
> +#endif /* __INET_SMC */

^ permalink raw reply	[relevance 1%]

* Re: [yocto] GPL License Compliance - Automatically detect linking against GPL libraries
  2024-05-29 11:34  0%   ` Alexander Kanavin
@ 2024-05-29 11:58  0%     ` Stephen John Smoogen
  0 siblings, 0 replies; 200+ results
From: Stephen John Smoogen @ 2024-05-29 11:58 UTC (permalink / raw)
  To: Alexander Kanavin; +Cc: yocto, fabian.hanke

[-- Attachment #1: Type: text/plain, Size: 2901 bytes --]

On Wed, 29 May 2024 at 07:34, Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> On Wed, 29 May 2024 at 13:18, Stephen John Smoogen via
> lists.yoctoproject.org <smooge=gmail.com@lists.yoctoproject.org>
> wrote:
> > I wanted to bring up a nuance because you are saying 'GPL based
> library'. There are several different GPL licenses which need to be
> evaluated when linking to. The lawyers at Bosch can give the best advice,
> but this following rule of thumb may be useful:
> > Linking to licenses with AGPL -> must be a compatible source license
> (aka source must be available and modifiable by user) and must meet
> additional requirements for delivery
> > Linking to licenses with GPL -> must be a compatible source license (aka
> source must be available and modifiable by user)
> > Linking to licenses with LGPL -> can be a closed source library in many
> cases. [again get a lawyer's review]
> >
> > Then there are the GPL and LGPL with exception licenses. Those
> exceptions might be something 'slight' so that licenses incompatibilities
> between the OpenSSL or Apache can be still 'excepted' for use. And then
> there are the exceptions which basically allow any closed source to link
> against it. Those need a lawyer's review. There are also differences
> between version 2 and version 3 of the licenses that again need lawyer's
> advice.
> >
> > On many Linux operating systems the libc is based off of glibc which is
> LGPL2+ with exceptions and GPL2+ with exceptions for various binaries.
> Other libraries that are in common use may also be. There are also example
> layer's like the one that Etienne Cordonnier brought up which can help cut
> down potential conflicts.
> >
> > And my apologies for bringing up 'lawyers review' so much. Various parts
> of Bosch have worked in this space for a long time so I figured there was a
> dedicated counsel who can help guide engineering projects through GPL and
> other license linking and compliance.
> >
>
> The question was how to figure out programmatically what actually
> links with gpl pieces without doing a laborious manual review of every
> component in the product. And doing it at the yocto integration point
>

Yes, I misread the intent of the original question and went on a tangent. I
have had several times had to explain the differentiation because people
try to remove all GPL without understanding that LGPL can be used for most
things. I should have reread and engaged only after that.


> where the problem is introduced, and not after the fact in legal
> review where the cost of correcting that mistake is going to be 10x or
> 100x.
>
> Sounds like this could be a test in package_qa task? I'm not aware of
> anything in oe-core that does it, but experiments in that direction
> welcome.
>
> Alex
>


-- 
Stephen J Smoogen.
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren

[-- Attachment #2: Type: text/html, Size: 4104 bytes --]

^ permalink raw reply	[relevance 0%]

* ✗ Fi.CI.CHECKPATCH: warning for Region Early Transport debugfs support
  @ 2024-05-29 11:58  1% ` Patchwork
  0 siblings, 0 replies; 200+ results
From: Patchwork @ 2024-05-29 11:58 UTC (permalink / raw)
  To: Jouni Högander; +Cc: intel-gfx

== Series Details ==

Series: Region Early Transport debugfs support
URL   : https://patchwork.freedesktop.org/series/134181/
State : warning

== Summary ==

Error: dim checkpatch failed
1ce79fc570e6 drm/i915/psr: Add Early Transport status boolean into intel_psr
a0c2ac8d1420 drm/i915/psr: Get Early Transport status in intel_psr_pipe_get_config
1ec1eab810ad drm/i915/psr: Use enable boolean from intel_crtc_state for Early Transport
0b8bb162a78a drm/i915/display: Selective fetch Y position on Region Early Transport
94c0045daeb1 drm/i915/psr: Allow setting I915_PSR_DEBUG_SU_REGION_ET_DISABLE via debugfs
b3f24730d566 drm/i915/psr: Add Early Transport into psr debugfs interface
-:28: WARNING:PREFER_SEQ_PUTS: Prefer seq_puts to seq_printf
#28: FILE: drivers/gpu/drm/i915/display/intel_psr.c:3615:
+		seq_printf(m, " (Early Transport)");

-:34: WARNING:PREFER_SEQ_PUTS: Prefer seq_puts to seq_printf
#34: FILE: drivers/gpu/drm/i915/display/intel_psr.c:3620:
+		seq_printf(m, " (Early Transport)");

-:35: WARNING:PREFER_SEQ_PUTS: Prefer seq_puts to seq_printf
#35: FILE: drivers/gpu/drm/i915/display/intel_psr.c:3621:
+	seq_printf(m, "\n");

total: 0 errors, 3 warnings, 0 checks, 52 lines checked



^ permalink raw reply	[relevance 1%]

* Re: [syzbot] [ntfs3?] KASAN: slab-use-after-free Read in chrdev_open
  @ 2024-05-29 11:49  3% ` Hillf Danton
  2024-05-29 12:02  4%   ` syzbot
  0 siblings, 1 reply; 200+ results
From: Hillf Danton @ 2024-05-29 11:49 UTC (permalink / raw)
  To: syzbot; +Cc: linux-kernel, syzkaller-bugs

#syz test https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git  master

--- x/fs/open.c
+++ y/fs/open.c
@@ -906,9 +906,13 @@ static int do_dentry_open(struct file *f
 {
 	static const struct file_operations empty_fops = {};
 	struct inode *inode = f->f_path.dentry->d_inode;
+	struct dentry *d = f->f_path.dentry;
 	int error;
 
+	if (!lockref_get_not_zero(&d->d_lockref))
+		return -ENODEV;
 	path_get(&f->f_path);
+	dput(d);
 	f->f_inode = inode;
 	f->f_mapping = inode->i_mapping;
 	f->f_wb_err = filemap_sample_wb_err(f->f_mapping);
--

^ permalink raw reply	[relevance 3%]

* Re: [PATCH v2 3/3] Bluetooth: btusb: mediatek: add MediaTek ISO data transmission function
  @ 2024-05-29 11:52  1%     ` Chris Lu (陸稚泓)
  0 siblings, 0 replies; 200+ results
From: Chris Lu (陸稚泓) @ 2024-05-29 11:52 UTC (permalink / raw)
  To: pmenzel
  Cc: marcel, linux-kernel, linux-mediatek,
	Deren Wu (武德仁),
	linux-bluetooth, johan.hedberg,
	Steve Lee (李視誠),
	Sean Wang, Aaron Hou (侯俊仰),
	luiz.dentz

Dear Paul,

Thanks for your suggestion. I'll correct those typo and add more
descriptions in v3.

On Wed, 2024-05-29 at 09:10 +0200, Paul Menzel wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  Dear Chris,
> 
> 
> Thank you for your patch. Some minor comments. It’d be great if you 
> started the description with a motivation for the patch, that means, 
> what problem is going to be solved?
> 
> Am 29.05.24 um 08:29 schrieb Chris Lu:
> > This patch implement function for ISO data send and receive in
> btusb
> 
> implement*s*
> 
> I’d recommend to use imperative moot though: Implement function
> 
> Would functionality or feature be more accurate?
> 
> > driver for MediaTek Controller.
> > 
> > MediaTek define a specific interrupt endpoint for ISO data
> 
> MediaTek devices …
> 
> All of them?

Previous generation(MT7663/7668) are not able to support ISO
transmission. For MT79xx generation, support will be determined by
vendor command in driver. Currently, We're focusing on MT7922, the rest
MT79XX series will support ISO data in the future.

> 
> > transmission because the characteristics of interrupt are
> > similar to the application of ISO data which can ensure bandwidth,
> > has enough data length and support error check.
> 
> What do you mean by “ensure bandwidth”?

Interrup and isochronous are scheduled to provide guaranteed bandwidth.
I'll update the description to avoid misunderstanding.

> 
> > Driver setup ISO interface in btusb_mtk_setup after download patch
> and
> > submit interrtupt urb to handle ISO data send and receive.
> 
> 1.  Driver sets up interface
> 2.  download*ing*
> 3.  interrupt
> 4.  submit*s*
> 
> Please elaborate, how you tested this.

Google ChromeOS project provides an environment that supports ISO data
send and receive. MediaTek use such environment to develop and verify
ISO data transmission between BT host and driver/controller.
Currently, we've verified create connection, send/receive ISO data
works as expected with ear buds which support LE audio feature.

> 
> > Signed-off-by: Chris Lu <chris.lu@mediatek.com>
> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> > ---
> >   drivers/bluetooth/btmtk.c |  35 +++++
> >   drivers/bluetooth/btmtk.h |  23 +++
> >   drivers/bluetooth/btusb.c | 295
> +++++++++++++++++++++++++++++++++++++-
> >   3 files changed, 352 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
> > index a27c251bf56e..f0aecd319911 100644
> > --- a/drivers/bluetooth/btmtk.c
> > +++ b/drivers/bluetooth/btmtk.c
> > @@ -4,6 +4,7 @@
> >    */
> >   #include <linux/module.h>
> >   #include <linux/firmware.h>
> > +#include <linux/usb.h>
> >   
> >   #include <net/bluetooth/bluetooth.h>
> >   #include <net/bluetooth/hci_core.h>
> > @@ -19,6 +20,9 @@
> >   #define MTK_SEC_MAP_COMMON_SIZE12
> >   #define MTK_SEC_MAP_NEED_SEND_SIZE52
> >   
> > +/* It is for mt79xx iso data transmission setting */
> 
> Just: For mt79xx iso data transmission setting
> 
> Maybe reference some section from the data sheet? Will future
> devices 
> support it?
> 

Currently, btusb driver in kernel supports MT7961, 7922, 7925. We're
focusing on the development of MT7922 for LE audio feature, the rest
MT79XX series will support ISO data in the future. The driver ISO setup
flow should be the same for all MT79xx series(including chip in
future).

> > +#define MTK_ISO_THRESHOLD264
> > +
> >   struct btmtk_patch_header {
> >   u8 datetime[16];
> >   u8 platform[4];
> > @@ -431,6 +435,37 @@ int btmtk_process_coredump(struct hci_dev
> *hdev, struct sk_buff *skb)
> >   }
> >   EXPORT_SYMBOL_GPL(btmtk_process_coredump);
> >   
> > +int btmtk_isointf_setup(struct hci_dev *hdev)
> > +{
> > +u8 iso_param[2] = { 0x08, 0x01 };
> > +struct sk_buff *skb;
> > +
> > +skb = __hci_cmd_sync(hdev, 0xfd98, sizeof(iso_param), iso_param,
> > +     HCI_INIT_TIMEOUT);
> > +if (IS_ERR(skb)) {
> > +bt_dev_err(hdev, "Failed to apply iso setting (%ld)",
> PTR_ERR(skb));
> > +return PTR_ERR(skb);
> > +}
> > +kfree_skb(skb);
> > +
> > +return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(btmtk_isointf_setup);
> > +
> > +int btmtk_isopkt_pad(struct hci_dev *hdev, struct sk_buff *skb)
> > +{
> > +if (skb->len > MTK_ISO_THRESHOLD)
> > +return -EINVAL;
> > +
> > +if (skb_pad(skb, MTK_ISO_THRESHOLD - skb->len))
> > +return -ENOMEM;
> > +
> > +__skb_put(skb, MTK_ISO_THRESHOLD - skb->len);
> > +
> > +return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(btmtk_isopkt_pad);
> > +
> >   MODULE_AUTHOR("Sean Wang <sean.wang@mediatek.com>");
> >   MODULE_AUTHOR("Mark Chen <mark-yw.chen@mediatek.com>");
> >   MODULE_DESCRIPTION("Bluetooth support for MediaTek devices ver "
> VERSION);
> > diff --git a/drivers/bluetooth/btmtk.h b/drivers/bluetooth/btmtk.h
> > index 6a0697a22b16..afc914e921dd 100644
> > --- a/drivers/bluetooth/btmtk.h
> > +++ b/drivers/bluetooth/btmtk.h
> > @@ -129,6 +129,8 @@ struct btmtk_hci_wmt_params {
> >   typedef int (*btmtk_reset_sync_func_t)(struct hci_dev *, void *);
> >   
> >   enum {
> > +BTMTK_ISOPKT_OVER_INTR,
> > +
> >   __BTMTK_NUM_FLAGS,
> >   };
> >   
> > @@ -139,12 +141,19 @@ struct btmtk_coredump_info {
> >   int state;
> >   };
> >   
> > +struct btmtk_isopkt_info {
> > +struct usb_interface *isopkt_intf;
> > +struct usb_endpoint_descriptor *isopkt_tx_ep;
> > +struct usb_endpoint_descriptor *isopkt_rx_ep;
> > +};
> > +
> >   struct btmediatek_data {
> >   DECLARE_BITMAP(flags, __BTMTK_NUM_FLAGS);
> >   
> >   u32 dev_id;
> >   btmtk_reset_sync_func_t reset_sync;
> >   struct btmtk_coredump_info cd_info;
> > +struct btmtk_isopkt_info isopkt_info;
> >   };
> >   
> >   #define btmtk_set_flag(hdev, nr)\
> > @@ -186,6 +195,10 @@ int btmtk_process_coredump(struct hci_dev
> *hdev, struct sk_buff *skb);
> >   
> >   void btmtk_fw_get_filename(char *buf, size_t size, u32 dev_id,
> u32 fw_ver,
> >      u32 fw_flavor);
> > +
> > +int btmtk_isointf_setup(struct hci_dev *hdev);
> > +
> > +int btmtk_isopkt_pad(struct hci_dev *hdev, struct sk_buff *skb);
> >   #else
> >   
> >   static inline int btmtk_set_bdaddr(struct hci_dev *hdev,
> > @@ -225,4 +238,14 @@ static void btmtk_fw_get_filename(char *buf,
> size_t size, u32 dev_id,
> >     u32 fw_ver, u32 fw_flavor)
> >   {
> >   }
> > +
> > +static int btmtk_isointf_setup(struct hci_dev *hdev)
> > +{
> > +return -EOPNOTSUPP;
> > +}
> > +
> > +static int btmtk_isopkt_pad(struct hci_dev *hdev, struct sk_buff
> *skb)
> > +{
> > +return -EOPNOTSUPP;
> > +}
> >   #endif
> > diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> > index 79aefdb3324d..592be71a7c45 100644
> > --- a/drivers/bluetooth/btusb.c
> > +++ b/drivers/bluetooth/btusb.c
> > @@ -831,6 +831,7 @@ struct qca_dump_info {
> >   #define BTUSB_USE_ALT3_FOR_WBS15
> >   #define BTUSB_ALT6_CONTINUOUS_TX16
> >   #define BTUSB_HW_SSR_ACTIVE17
> > +#define BTUSB_ISOPKT_RUNNING18
> >   
> >   struct btusb_data {
> >   struct hci_dev       *hdev;
> > @@ -860,11 +861,13 @@ struct btusb_data {
> >   struct usb_anchor isoc_anchor;
> >   struct usb_anchor diag_anchor;
> >   struct usb_anchor ctrl_anchor;
> > +struct usb_anchor isopkt_anchor;
> >   spinlock_t rxlock;
> >   
> >   struct sk_buff *evt_skb;
> >   struct sk_buff *acl_skb;
> >   struct sk_buff *sco_skb;
> > +struct sk_buff *isopkt_skb;
> >   
> >   struct usb_endpoint_descriptor *intr_ep;
> >   struct usb_endpoint_descriptor *bulk_tx_ep;
> > @@ -1099,6 +1102,9 @@ static inline void btusb_free_frags(struct
> btusb_data *data)
> >   dev_kfree_skb_irq(data->sco_skb);
> >   data->sco_skb = NULL;
> >   
> > +dev_kfree_skb_irq(data->isopkt_skb);
> > +data->isopkt_skb = NULL;
> > +
> >   spin_unlock_irqrestore(&data->rxlock, flags);
> >   }
> >   
> > @@ -1327,6 +1333,64 @@ static int btusb_recv_isoc(struct btusb_data
> *data, void *buffer, int count)
> >   return err;
> >   }
> >   
> > +static int btusb_recv_isopkt(struct btusb_data *data, void
> *buffer, int count)
> 
> Make count `size_t` or `unsigned int`? Though the other function do
> use 
> `int`, so ignore.
> 
> > +{
> > +struct sk_buff *skb;
> > +unsigned long flags;
> > +int err = 0;
> > +
> > +spin_lock_irqsave(&data->rxlock, flags);
> > +skb = data->isopkt_skb;
> > +
> > +while (count) {
> > +int len;
> > +
> > +if (!skb) {
> > +skb = bt_skb_alloc(HCI_MAX_ISO_SIZE, GFP_ATOMIC);
> > +if (!skb) {
> > +err = -ENOMEM;
> > +break;
> > +}
> > +
> > +hci_skb_pkt_type(skb) = HCI_ISODATA_PKT;
> > +hci_skb_expect(skb) = HCI_ISO_HDR_SIZE;
> > +}
> > +
> > +len = min_t(uint, hci_skb_expect(skb), count);
> > +skb_put_data(skb, buffer, len);
> > +
> > +count -= len;
> > +buffer += len;
> > +hci_skb_expect(skb) -= len;
> > +
> > +if (skb->len == HCI_ISO_HDR_SIZE) {
> > +__le16 dlen = hci_iso_hdr(skb)->dlen;
> > +
> > +/* Complete ISO header */
> > +hci_skb_expect(skb) = __le16_to_cpu(dlen);
> > +
> > +if (skb_tailroom(skb) < hci_skb_expect(skb)) {
> > +kfree_skb(skb);
> > +skb = NULL;
> > +
> > +err = -EILSEQ;
> > +break;
> > +}
> > +}
> > +
> > +if (!hci_skb_expect(skb)) {
> > +/* Complete frame */
> > +hci_recv_frame(data->hdev, skb);
> > +skb = NULL;
> > +}
> > +}
> > +
> > +data->isopkt_skb = skb;
> > +spin_unlock_irqrestore(&data->rxlock, flags);
> > +
> > +return err;
> > +}
> > +
> >   static void btusb_intr_complete(struct urb *urb)
> >   {
> >   struct hci_dev *hdev = urb->context;
> > @@ -1784,6 +1848,101 @@ static int btusb_submit_diag_urb(struct
> hci_dev *hdev, gfp_t mem_flags)
> >   return err;
> >   }
> >   
> > +static void btusb_mtk_intr_complete(struct urb *urb)
> > +{
> > +struct hci_dev *hdev = urb->context;
> > +struct btusb_data *data = hci_get_drvdata(hdev);
> > +int err;
> > +
> > +BT_DBG("%s urb %p status %d count %d", hdev->name, urb, urb-
> >status,
> > +       urb->actual_length);
> > +
> > +if (!test_bit(HCI_RUNNING, &hdev->flags))
> > +return;
> > +
> > +if (urb->status == 0) {
> > +hdev->stat.byte_rx += urb->actual_length;
> > +
> > +if (btusb_recv_isopkt(data, urb->transfer_buffer,
> > +      urb->actual_length) < 0) {
> > +bt_dev_err(hdev, "corrupted iso packet");
> > +hdev->stat.err_rx++;
> > +}
> > +} else if (urb->status == -ENOENT) {
> > +/* Avoid suspend failed when usb_kill_urb */
> 
> Could you please elaborate?

This part references other urb complete function.
btusb_suspend stop all traffic, judge the urb status and return to
prevent data from waking up the host.

> 
> > +return;
> > +}
> > +
> > +if (!test_bit(BTUSB_ISOPKT_RUNNING, &data->flags))
> > +return;
> > +
> > +usb_mark_last_busy(data->udev);
> > +usb_anchor_urb(urb, &data->isopkt_anchor);
> > +
> > +err = usb_submit_urb(urb, GFP_ATOMIC);
> > +if (err < 0) {
> > +/* -EPERM: urb is being killed;
> > + * -ENODEV: device got disconnected
> > + */
> > +if (err != -EPERM && err != -ENODEV)
> > +bt_dev_err(hdev, "urb %p failed to resubmit (%d)",
> > +   urb, -err);
> > +if (err != -EPERM)
> > +hci_cmd_sync_cancel(hdev, -err);
> > +usb_unanchor_urb(urb);
> > +}
> > +}
> > +
> > +static int btusb_mtk_submit_intr_urb(struct hci_dev *hdev, gfp_t
> mem_flags)
> > +{
> > +struct btmediatek_data *btmtk_data = hci_get_priv(hdev);
> > +struct btusb_data *data = hci_get_drvdata(hdev);
> > +unsigned char *buf;
> > +unsigned int pipe;
> > +struct urb *urb;
> > +int err, size;
> > +
> > +BT_DBG("%s", hdev->name);
> > +
> > +if (!btmtk_data->isopkt_info.isopkt_rx_ep)
> > +return -ENODEV;
> > +
> > +urb = usb_alloc_urb(0, mem_flags);
> > +if (!urb)
> > +return -ENOMEM;
> > +size = le16_to_cpu(btmtk_data->isopkt_info.isopkt_rx_ep-
> >wMaxPacketSize);
> > +
> > +buf = kmalloc(size, mem_flags);
> > +if (!buf) {
> > +usb_free_urb(urb);
> > +return -ENOMEM;
> > +}
> > +
> > +pipe = usb_rcvintpipe(data->udev,
> > +      btmtk_data->isopkt_info.isopkt_rx_ep->bEndpointAddress);
> > +
> > +usb_fill_int_urb(urb, data->udev, pipe, buf, size,
> > + btusb_mtk_intr_complete, hdev,
> > + btmtk_data->isopkt_info.isopkt_rx_ep->bInterval);
> > +
> > +urb->transfer_flags |= URB_FREE_BUFFER;
> > +
> > +usb_mark_last_busy(data->udev);
> > +usb_anchor_urb(urb, &data->isopkt_anchor);
> > +
> > +err = usb_submit_urb(urb, mem_flags);
> > +if (err < 0) {
> > +if (err != -EPERM && err != -ENODEV)
> > +bt_dev_err(hdev, "urb %p submission failed (%d)",
> > +   urb, -err);
> > +usb_unanchor_urb(urb);
> > +}
> > +
> > +usb_free_urb(urb);
> > +
> > +return err;
> > +}
> > +
> >   static void btusb_tx_complete(struct urb *urb)
> >   {
> >   struct sk_buff *skb = urb->context;
> > @@ -1898,6 +2057,7 @@ static void btusb_stop_traffic(struct
> btusb_data *data)
> >   usb_kill_anchored_urbs(&data->isoc_anchor);
> >   usb_kill_anchored_urbs(&data->diag_anchor);
> >   usb_kill_anchored_urbs(&data->ctrl_anchor);
> > +usb_kill_anchored_urbs(&data->isopkt_anchor);
> >   }
> >   
> >   static int btusb_close(struct hci_dev *hdev)
> > @@ -1917,6 +2077,7 @@ static int btusb_close(struct hci_dev *hdev)
> >   clear_bit(BTUSB_BULK_RUNNING, &data->flags);
> >   clear_bit(BTUSB_INTR_RUNNING, &data->flags);
> >   clear_bit(BTUSB_DIAG_RUNNING, &data->flags);
> > +clear_bit(BTUSB_ISOPKT_RUNNING, &data->flags);
> >   
> >   btusb_stop_traffic(data);
> >   btusb_free_frags(data);
> > @@ -2043,6 +2204,81 @@ static struct urb *alloc_isoc_urb(struct
> hci_dev *hdev, struct sk_buff *skb)
> >   return urb;
> >   }
> >   
> > +static inline int __set_mtk_intr_interface(struct hci_dev *hdev,
> unsigned int ifnum)
> > +{
> > +struct btusb_data *data = hci_get_drvdata(hdev);
> > +struct btmediatek_data *btmtk_data = hci_get_priv(hdev);
> > +struct usb_interface *intf = btmtk_data->isopkt_info.isopkt_intf;
> > +int i, err;
> > +
> > +if (!btmtk_data->isopkt_info.isopkt_intf)
> > +return -ENODEV;
> > +
> > +err = usb_set_interface(data->udev, ifnum, 1);
> > +if (err < 0) {
> > +bt_dev_err(hdev, "setting interface failed (%d)", -err);
> > +return err;
> > +}
> > +
> > +btmtk_data->isopkt_info.isopkt_tx_ep = NULL;
> > +btmtk_data->isopkt_info.isopkt_rx_ep = NULL;
> > +
> > +for (i = 0; i < intf->cur_altsetting->desc.bNumEndpoints; i++) {
> > +struct usb_endpoint_descriptor *ep_desc;
> > +
> > +ep_desc = &intf->cur_altsetting->endpoint[i].desc;
> > +
> > +if (!btmtk_data->isopkt_info.isopkt_tx_ep &&
> > +    usb_endpoint_is_int_out(ep_desc)) {
> > +btmtk_data->isopkt_info.isopkt_tx_ep = ep_desc;
> > +continue;
> > +}
> > +
> > +if (!btmtk_data->isopkt_info.isopkt_rx_ep &&
> > +    usb_endpoint_is_int_in(ep_desc)) {
> > +btmtk_data->isopkt_info.isopkt_rx_ep = ep_desc;
> > +continue;
> > +}
> > +}
> > +
> > +if (!btmtk_data->isopkt_info.isopkt_tx_ep ||
> > +    !btmtk_data->isopkt_info.isopkt_rx_ep) {
> > +bt_dev_err(hdev, "invalid interrupt descriptors");
> > +return -ENODEV;
> > +}
> > +
> > +return 0;
> > +}
> > +
> > +static struct urb *alloc_mtk_intr_urb(struct hci_dev *hdev, struct
> sk_buff *skb)
> > +{
> > +struct btusb_data *data = hci_get_drvdata(hdev);
> > +struct btmediatek_data *btmtk_data = hci_get_priv(hdev);
> > +struct urb *urb;
> > +unsigned int pipe;
> > +
> > +if (!btmtk_data->isopkt_info.isopkt_tx_ep)
> > +return ERR_PTR(-ENODEV);
> > +
> > +urb = usb_alloc_urb(0, GFP_KERNEL);
> > +if (!urb)
> > +return ERR_PTR(-ENOMEM);
> > +
> > +if (btmtk_isopkt_pad(hdev, skb))
> > +return ERR_PTR(-EINVAL);
> > +
> > +pipe = usb_sndintpipe(data->udev,
> > +      btmtk_data->isopkt_info.isopkt_tx_ep->bEndpointAddress);
> > +
> > +usb_fill_int_urb(urb, data->udev, pipe,
> > + skb->data, skb->len, btusb_tx_complete,
> > + skb, btmtk_data->isopkt_info.isopkt_tx_ep->bInterval);
> > +
> > +skb->dev = (void *)hdev;
> > +
> > +return urb;
> > +}
> > +
> >   static int submit_tx_urb(struct hci_dev *hdev, struct urb *urb)
> >   {
> >   struct btusb_data *data = hci_get_drvdata(hdev);
> > @@ -2122,7 +2358,10 @@ static int btusb_send_frame(struct hci_dev
> *hdev, struct sk_buff *skb)
> >   return submit_tx_urb(hdev, urb);
> >   
> >   case HCI_ISODATA_PKT:
> > -urb = alloc_bulk_urb(hdev, skb);
> > +if (btmtk_test_flag(hdev, BTMTK_ISOPKT_OVER_INTR))
> > +urb = alloc_mtk_intr_urb(hdev, skb);
> > +else
> > +urb = alloc_bulk_urb(hdev, skb);
> >   if (IS_ERR(urb))
> >   return PTR_ERR(urb);
> >   
> > @@ -2650,6 +2889,8 @@ static int btusb_recv_event_realtek(struct
> hci_dev *hdev, struct sk_buff *skb)
> >   #define MTK_BT_RESET_REG_CONNV30x70028610
> >   #define MTK_BT_READ_DEV_ID0x70010200
> >   
> > +/* MediaTek ISO interface number */
> > +#define MTK_ISO_IFNUM2
> >   
> >   static void btusb_mtk_wmt_recv(struct urb *urb)
> >   {
> > @@ -3126,6 +3367,28 @@ static int btusb_mtk_reset(struct hci_dev
> *hdev, void *rst_data)
> >   return err;
> >   }
> >   
> > +static int btusb_mtk_claim_iso_intf(struct btusb_data *data,
> struct usb_interface *intf)
> > +{
> > +int err;
> > +
> > +err = usb_driver_claim_interface(&btusb_driver, intf, data);
> > +if (err < 0)
> > +return err;
> > +
> > +__set_mtk_intr_interface(data->hdev, MTK_ISO_IFNUM);
> > +
> > +err = btusb_mtk_submit_intr_urb(data->hdev, GFP_KERNEL);
> > +if (err < 0) {
> > +usb_kill_anchored_urbs(&data->isopkt_anchor);
> > +bt_dev_err(data->hdev, "ISO intf not support (%d)", err);
> > +return err;
> > +}
> > +
> > +btmtk_set_flag(data->hdev, BTMTK_ISOPKT_OVER_INTR);
> > +
> > +return 0;
> > +}
> > +
> >   static int btusb_mtk_setup(struct hci_dev *hdev)
> >   {
> >   struct btusb_data *data = hci_get_drvdata(hdev);
> > @@ -3210,6 +3473,12 @@ static int btusb_mtk_setup(struct hci_dev
> *hdev)
> >   /* It's Device EndPoint Reset Option Register */
> >   btusb_mtk_uhw_reg_write(data, MTK_EP_RST_OPT,
> MTK_EP_RST_IN_OUT_OPT);
> >   
> > +/* Claim USB interface and EndPoint for ISO data */
> > +mediatek->isopkt_info.isopkt_intf = usb_ifnum_to_if(data->udev,
> MTK_ISO_IFNUM);
> > +err = btusb_mtk_claim_iso_intf(data, mediatek-
> >isopkt_info.isopkt_intf);
> > +if (err < 0)
> > +mediatek->isopkt_info.isopkt_intf = NULL;
> > +
> >   /* Enable Bluetooth protocol */
> >   param = 1;
> >   wmt_params.op = BTMTK_WMT_FUNC_CTRL;
> > @@ -3226,6 +3495,13 @@ static int btusb_mtk_setup(struct hci_dev
> *hdev)
> >   
> >   hci_set_msft_opcode(hdev, 0xFD30);
> >   hci_set_aosp_capable(hdev);
> > +
> > +/* Setup ISO interface after protocol enabled */
> 
> The verb is spelled with a space: Set up.
> 
> > +if (btmtk_test_flag(hdev, BTMTK_ISOPKT_OVER_INTR)) {
> > +btmtk_isointf_setup(hdev);
> > +set_bit(BTUSB_ISOPKT_RUNNING, &data->flags);
> > +}
> > +
> >   goto done;
> >   default:
> >   bt_dev_err(hdev, "Unsupported hardware variant (%08x)",
> > @@ -4347,6 +4623,7 @@ static int btusb_probe(struct usb_interface
> *intf,
> >   init_usb_anchor(&data->isoc_anchor);
> >   init_usb_anchor(&data->diag_anchor);
> >   init_usb_anchor(&data->ctrl_anchor);
> > +init_usb_anchor(&data->isopkt_anchor);
> >   spin_lock_init(&data->rxlock);
> >   
> >   priv_size = 0;
> > @@ -4663,6 +4940,17 @@ static void btusb_disconnect(struct
> usb_interface *intf)
> >   if (data->diag)
> >   usb_set_intfdata(data->diag, NULL);
> >   
> > +if (btmtk_test_flag(hdev, BTMTK_ISOPKT_OVER_INTR)) {
> > +struct btmediatek_data *btmtk_data = hci_get_priv(hdev);
> > +
> > +if (btmtk_data->isopkt_info.isopkt_intf) {
> > +usb_set_intfdata(btmtk_data->isopkt_info.isopkt_intf, NULL);
> > +usb_driver_release_interface(&btusb_driver,
> > +     btmtk_data->isopkt_info.isopkt_intf);
> > +}
> > +btmtk_clear_flag(hdev, BTMTK_ISOPKT_OVER_INTR);
> > +}
> > +
> >   hci_unregister_dev(hdev);
> >   
> >   if (intf == data->intf) {
> > @@ -4818,6 +5106,11 @@ static int btusb_resume(struct usb_interface
> *intf)
> >   btusb_submit_isoc_urb(hdev, GFP_NOIO);
> >   }
> >   
> > +if (test_bit(BTUSB_ISOPKT_RUNNING, &data->flags)) {
> > +if (btusb_mtk_submit_intr_urb(hdev, GFP_NOIO) < 0)
> > +clear_bit(BTUSB_ISOPKT_RUNNING, &data->flags);
> > +}
> > +
> >   spin_lock_irq(&data->txlock);
> >   play_deferred(data);
> >   clear_bit(BTUSB_SUSPENDING, &data->flags);
> 
> 
> Kind regards,
> 
> 

Thanks a lot,

Chris Lu
> Paul

^ permalink raw reply	[relevance 1%]

* Re: [PATCH 4/5] drm/xe: Rename internal vram helper function
  2024-05-29 11:25  2%       ` Michal Wajdeczko
@ 2024-05-29 11:50  1%         ` Jani Nikula
  2024-05-29 12:45  0%           ` Michal Wajdeczko
  0 siblings, 1 reply; 200+ results
From: Jani Nikula @ 2024-05-29 11:50 UTC (permalink / raw)
  To: Michal Wajdeczko, Matthew Brost, Matt Roper,
	Thomas Hellström, Lucas De Marchi
  Cc: intel-xe

On Wed, 29 May 2024, Michal Wajdeczko <michal.wajdeczko@intel.com> wrote:
> ++ maintainers
>
> On 29.05.2024 00:15, Matthew Brost wrote:
>> We have talked about this before and I think the consensous was "xe_"
>> prefixes for static functions are fine, perhaps even desired. I can't
>
> IMO use of "xe_foo" prefix for static functions is inconsistent (as its
> name suggests that it is public function while OTOH it is declared as
> static) and may mislead that it could be used in other compilation unit.
>
> thus use of "xe_" (for static) should be rather discouraged but also at
> the same time it shouldn't be treated as showstopper (with the hope
> better name will be provided later)
>
>> find a reference but I do recall a discussion on the list about this.
>> 
>> I think the maintainers should make / document a rule wrt to "xe_"
>> prefixes before we start making changes in this area as it is not clear.

IMO the prefix is useful even for static functions for a few reasons:

- C has no namespaces. The use of prefixes in the kernel global
  functions and macros is inconsistent at best. Prefixes avoid clashes.

- It's quite handy to be able to just glance at a backtrace to see where
  it's originating from. With a bunch of generic non-prefixed functions
  in there, you kind of lose track, and have to look at the source.

- During refactoring, it's not uncommon to make functions
  static/non-static, and having to rename at that point is a bit
  tedious.

That said, we haven't required this in i915. Also platform acronym
prefixes are common especially in display code. Some people have started
adding single underscore prefixes for static functions in a few places,
but I pretty much frown on that.

> before we start writing rules for static functions, better to focus only
> on rules for public naming convention for the components, like:
>
> files:
> 	GOOD
> 		xe_foo.ch
> 		xe_foo_types.h
> 		xe_foo_helpers.h
> 	FINE
> 		xe_gt_foo.ch
> 	BAD
> 		foo.ch
>
> types:
> 	GOOD
> 		struct xe_foo_xxx
> 		enum xe_foo_yyy
> 		typedef xe_foo_zzz
> 	BAD
> 		struct foo
> 		struct xe_bar
>
> functions:
> 	GOOD
> 		xe_foo_bar(struct xe_foo *foo, ...)
> 	FINE
> 		xe_foo_bar(struct xe_device *xe, ...)
> 		xe_gt_foo_bar(struct xe_gt *gt, ...)
> 	BAD
> 		xe_foo_bar(..., struct xe_foo *foo)
> 		xe_bar_foo(struct xe_foo *foo, ...)

And sometimes you want to prefer names that are easy to pronounce and
make sense over names that strictly adhere to rules...

BR,
Jani.


-- 
Jani Nikula, Intel

^ permalink raw reply	[relevance 1%]

* Re: [PATCH v5 3/3] virtio-net: Annotate virtio_net_hdr as field
  @ 2024-05-29 11:48  0%   ` Xuan Zhuo
  0 siblings, 0 replies; 200+ results
From: Xuan Zhuo @ 2024-05-29 11:48 UTC (permalink / raw)
  To: Parav Pandit
  Cc: shahafs, xuanzhuo, yuri.benditovich, Parav Pandit,
	virtio-comment, mst, cohuck

On Tue, 21 May 2024 15:23:03 +0300, Parav Pandit <parav@nvidia.com> wrote:
> At several places struct virtio_net_hdr missed out the field
> annotation. Add it.
>
> Signed-off-by: Parav Pandit <parav@nvidia.com>

Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>


> ---
>  device-types/net/description.tex | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> index 38992b0..e65cdd5 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -437,11 +437,11 @@ \subsection{Device Operation}\label{sec:Device Types / Network Device / Device O
>
>  \subsubsection{Legacy Interface: Device Operation}\label{sec:Device Types / Network Device / Device Operation / Legacy Interface: Device Operation}
>  When using the legacy interface, transitional devices and drivers
> -MUST format the fields in struct virtio_net_hdr
> +MUST format the fields in \field{struct virtio_net_hdr}
>  according to the native endian of the guest rather than
>  (necessarily when not using the legacy interface) little-endian.
>
> -The legacy driver only presented \field{num_buffers} in the struct virtio_net_hdr
> +The legacy driver only presented \field{num_buffers} in the \field{struct virtio_net_hdr}
>  when VIRTIO_NET_F_MRG_RXBUF was negotiated; without that feature the
>  structure was 2 bytes shorter.
>
> @@ -735,7 +735,7 @@ \subsubsection{Processing of Incoming Packets}\label{sec:Device Types / Network
>    chains them together to form a single packet in a way similar to
>    how it would store it in a single buffer spread over multiple
>    descriptors.
> -  The other buffers will not begin with a struct virtio_net_hdr.
> +  The other buffers will not begin with a \field{struct virtio_net_hdr}.
>
>  \item If
>    \field{num_buffers} is one, then the entire packet will be
> @@ -2416,7 +2416,7 @@ \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
>
>  When using legacy interfaces, transitional drivers which have not
>  negotiated VIRTIO_F_ANY_LAYOUT MUST use a single descriptor for the
> -struct virtio_net_hdr on both transmit and receive, with the
> +\field{struct virtio_net_hdr} on both transmit and receive, with the
>  network data in the following descriptors.
>
>  Additionally, when using the control virtqueue (see \ref{sec:Device
> --
> 2.34.1
>

^ permalink raw reply	[relevance 0%]

* Re: [f2fs-dev] [syzbot] [f2fs?] KASAN: slab-use-after-free Read in sanity_check_extent_cache
  2024-05-29 11:26  3%   ` Chao Yu
@ 2024-05-29 11:48  2%     ` syzbot
  -1 siblings, 0 replies; 200+ results
From: syzbot @ 2024-05-29 11:48 UTC (permalink / raw)
  To: chao, jaegeuk, linux-f2fs-devel, linux-fsdevel, linux-kernel,
	syzkaller-bugs

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

42][    T1] usbcore: registered new interface driver dln2
[    7.576709][    T1] usbcore: registered new interface driver pn533_usb
[    7.583988][    T1] nfcsim 0.2 initialized
[    7.586139][    T1] usbcore: registered new interface driver port100
[    7.587701][    T1] usbcore: registered new interface driver nfcmrvl
[    7.594256][    T1] Loading iSCSI transport class v2.0-870.
[    7.612218][    T1] virtio_scsi virtio0: 1/0/0 default/read/poll queues
[    7.621827][    T1] ------------[ cut here ]------------
[    7.622778][    T1] refcount_t: decrement hit 0; leaking memory.
[    7.626782][    T1] WARNING: CPU: 0 PID: 1 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0
[    7.628293][    T1] Modules linked in:
[    7.628860][    T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc1-syzkaller-00060-g889914b5c209 #0
[    7.630401][    T1] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
[    7.632495][    T1] RIP: 0010:refcount_warn_saturate+0xfa/0x1d0
[    7.634119][    T1] Code: b2 00 00 00 e8 67 52 f2 fc 5b 5d c3 cc cc cc cc e8 5b 52 f2 fc c6 05 51 cc ce 0a 01 90 48 c7 c7 a0 54 fe 8b e8 b7 d0 b4 fc 90 <0f> 0b 90 90 eb d9 e8 3b 52 f2 fc c6 05 2e cc ce 0a 01 90 48 c7 c7
[    7.638094][    T1] RSP: 0000:ffffc90000066e18 EFLAGS: 00010246
[    7.639044][    T1] RAX: 343580cc97689700 RBX: ffff8881401bf06c RCX: ffff8880166c8000
[    7.640552][    T1] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[    7.642175][    T1] RBP: 0000000000000004 R08: ffffffff8157ffe2 R09: fffffbfff1bf96e0
[    7.643575][    T1] R10: dffffc0000000000 R11: fffffbfff1bf96e0 R12: ffffea000501cdc0
[    7.645089][    T1] R13: ffffea000501cdc8 R14: 1ffffd4000a039b9 R15: 0000000000000000
[    7.646458][    T1] FS:  0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
[    7.647850][    T1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    7.648816][    T1] CR2: ffff88823ffff000 CR3: 000000000df32000 CR4: 00000000003506f0
[    7.650069][    T1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    7.651660][    T1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    7.653255][    T1] Call Trace:
[    7.653955][    T1]  <TASK>
[    7.655231][    T1]  ? __warn+0x163/0x4e0
[    7.656060][    T1]  ? refcount_warn_saturate+0xfa/0x1d0
[    7.657004][    T1]  ? report_bug+0x2b3/0x500
[    7.657697][    T1]  ? refcount_warn_saturate+0xfa/0x1d0
[    7.658659][    T1]  ? handle_bug+0x3e/0x70
[    7.659735][    T1]  ? exc_invalid_op+0x1a/0x50
[    7.660993][    T1]  ? asm_exc_invalid_op+0x1a/0x20
[    7.661819][    T1]  ? __warn_printk+0x292/0x360
[    7.662573][    T1]  ? refcount_warn_saturate+0xfa/0x1d0
[    7.663589][    T1]  ? refcount_warn_saturate+0xf9/0x1d0
[    7.664642][    T1]  __free_pages_ok+0xc54/0xd80
[    7.665381][    T1]  make_alloc_exact+0xa3/0xf0
[    7.666771][    T1]  vring_alloc_queue_split+0x20a/0x600
[    7.667714][    T1]  ? __pfx_vring_alloc_queue_split+0x10/0x10
[    7.668766][    T1]  ? vp_find_vqs+0x4c/0x4e0
[    7.669540][    T1]  ? virtscsi_probe+0x3ea/0xf60
[    7.670758][    T1]  ? virtio_dev_probe+0x991/0xaf0
[    7.671577][    T1]  ? really_probe+0x2b8/0xad0
[    7.672570][    T1]  ? driver_probe_device+0x50/0x430
[    7.673427][    T1]  vring_create_virtqueue_split+0xc6/0x310
[    7.674713][    T1]  ? ret_from_fork+0x4b/0x80
[    7.675577][    T1]  ? __pfx_vring_create_virtqueue_split+0x10/0x10
[    7.676513][    T1]  vring_create_virtqueue+0xca/0x110
[    7.677483][    T1]  ? __pfx_vp_notify+0x10/0x10
[    7.678536][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.679645][    T1]  setup_vq+0xe9/0x2d0
[    7.680389][    T1]  ? __pfx_vp_notify+0x10/0x10
[    7.681211][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.682323][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.683391][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.684728][    T1]  vp_setup_vq+0xbf/0x330
[    7.685412][    T1]  ? __pfx_vp_config_changed+0x10/0x10
[    7.686599][    T1]  ? ioread16+0x2f/0x90
[    7.687219][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.688543][    T1]  vp_find_vqs_msix+0x8b2/0xc80
[    7.689396][    T1]  vp_find_vqs+0x4c/0x4e0
[    7.690066][    T1]  virtscsi_init+0x8db/0xd00
[    7.690768][    T1]  ? __pfx_virtscsi_init+0x10/0x10
[    7.691800][    T1]  ? __pfx_default_calc_sets+0x10/0x10
[    7.692645][    T1]  ? scsi_host_alloc+0xa57/0xea0
[    7.693496][    T1]  ? vp_get+0xfd/0x140
[    7.694109][    T1]  virtscsi_probe+0x3ea/0xf60
[    7.695276][    T1]  ? __pfx_virtscsi_probe+0x10/0x10
[    7.696256][    T1]  ? kernfs_add_one+0x156/0x8b0
[    7.697276][    T1]  ? virtio_no_restricted_mem_acc+0x9/0x10
[    7.698400][    T1]  ? virtio_features_ok+0x10c/0x270
[    7.699300][    T1]  virtio_dev_probe+0x991/0xaf0
[    7.700143][    T1]  ? __pfx_virtio_dev_probe+0x10/0x10
[    7.700985][    T1]  really_probe+0x2b8/0xad0
[    7.702196][    T1]  __driver_probe_device+0x1a2/0x390
[    7.703259][    T1]  driver_probe_device+0x50/0x430
[    7.704075][    T1]  __driver_attach+0x45f/0x710
[    7.704819][    T1]  ? __pfx___driver_attach+0x10/0x10
[    7.705601][    T1]  bus_for_each_dev+0x239/0x2b0
[    7.706514][    T1]  ? __pfx___driver_attach+0x10/0x10
[    7.707442][    T1]  ? __pfx_bus_for_each_dev+0x10/0x10
[    7.708680][    T1]  ? do_raw_spin_unlock+0x13c/0x8b0
[    7.710058][    T1]  bus_add_driver+0x347/0x620
[    7.711073][    T1]  driver_register+0x23a/0x320
[    7.712178][    T1]  ? __pfx_virtio_scsi_init+0x10/0x10
[    7.713450][    T1]  virtio_scsi_init+0x65/0xe0
[    7.714571][    T1]  ? __pfx_virtio_scsi_init+0x10/0x10
[    7.715692][    T1]  do_one_initcall+0x248/0x880
[    7.716533][    T1]  ? __pfx_virtio_scsi_init+0x10/0x10
[    7.717409][    T1]  ? __pfx_do_one_initcall+0x10/0x10
[    7.718599][    T1]  ? lockdep_hardirqs_on_prepare+0x43d/0x780
[    7.719639][    T1]  ? __pfx_parse_args+0x10/0x10
[    7.720523][    T1]  ? do_initcalls+0x1c/0x80
[    7.721261][    T1]  ? rcu_is_watching+0x15/0xb0
[    7.722428][    T1]  do_initcall_level+0x157/0x210
[    7.723278][    T1]  do_initcalls+0x3f/0x80
[    7.723962][    T1]  kernel_init_freeable+0x435/0x5d0
[    7.725035][    T1]  ? __pfx_kernel_init_freeable+0x10/0x10
[    7.726103][    T1]  ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10
[    7.727205][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.728033][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.729046][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.729731][    T1]  kernel_init+0x1d/0x2b0
[    7.730411][    T1]  ret_from_fork+0x4b/0x80
[    7.731117][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.731836][    T1]  ret_from_fork_asm+0x1a/0x30
[    7.732580][    T1]  </TASK>
[    7.733103][    T1] Kernel panic - not syncing: kernel: panic_on_warn set ...
[    7.734198][    T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc1-syzkaller-00060-g889914b5c209 #0
[    7.734971][    T1] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
[    7.734971][    T1] Call Trace:
[    7.734971][    T1]  <TASK>
[    7.734971][    T1]  dump_stack_lvl+0x241/0x360
[    7.734971][    T1]  ? __pfx_dump_stack_lvl+0x10/0x10
[    7.734971][    T1]  ? __pfx__printk+0x10/0x10
[    7.734971][    T1]  ? _printk+0xd5/0x120
[    7.734971][    T1]  ? vscnprintf+0x5d/0x90
[    7.734971][    T1]  panic+0x349/0x860
[    7.734971][    T1]  ? __warn+0x172/0x4e0
[    7.734971][    T1]  ? __pfx_panic+0x10/0x10
[    7.734971][    T1]  ? show_trace_log_lvl+0x4e6/0x520
[    7.734971][    T1]  ? ret_from_fork_asm+0x1a/0x30
[    7.734971][    T1]  __warn+0x346/0x4e0
[    7.734971][    T1]  ? refcount_warn_saturate+0xfa/0x1d0
[    7.734971][    T1]  report_bug+0x2b3/0x500
[    7.734971][    T1]  ? refcount_warn_saturate+0xfa/0x1d0
[    7.734971][    T1]  handle_bug+0x3e/0x70
[    7.734971][    T1]  exc_invalid_op+0x1a/0x50
[    7.734971][    T1]  asm_exc_invalid_op+0x1a/0x20
[    7.734971][    T1] RIP: 0010:refcount_warn_saturate+0xfa/0x1d0
[    7.734971][    T1] Code: b2 00 00 00 e8 67 52 f2 fc 5b 5d c3 cc cc cc cc e8 5b 52 f2 fc c6 05 51 cc ce 0a 01 90 48 c7 c7 a0 54 fe 8b e8 b7 d0 b4 fc 90 <0f> 0b 90 90 eb d9 e8 3b 52 f2 fc c6 05 2e cc ce 0a 01 90 48 c7 c7
[    7.734971][    T1] RSP: 0000:ffffc90000066e18 EFLAGS: 00010246
[    7.734971][    T1] RAX: 343580cc97689700 RBX: ffff8881401bf06c RCX: ffff8880166c8000
[    7.734971][    T1] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[    7.734971][    T1] RBP: 0000000000000004 R08: ffffffff8157ffe2 R09: fffffbfff1bf96e0
[    7.734971][    T1] R10: dffffc0000000000 R11: fffffbfff1bf96e0 R12: ffffea000501cdc0
[    7.734971][    T1] R13: ffffea000501cdc8 R14: 1ffffd4000a039b9 R15: 0000000000000000
[    7.734971][    T1]  ? __warn_printk+0x292/0x360
[    7.734971][    T1]  ? refcount_warn_saturate+0xf9/0x1d0
[    7.734971][    T1]  __free_pages_ok+0xc54/0xd80
[    7.734971][    T1]  make_alloc_exact+0xa3/0xf0
[    7.734971][    T1]  vring_alloc_queue_split+0x20a/0x600
[    7.734971][    T1]  ? __pfx_vring_alloc_queue_split+0x10/0x10
[    7.734971][    T1]  ? vp_find_vqs+0x4c/0x4e0
[    7.734971][    T1]  ? virtscsi_probe+0x3ea/0xf60
[    7.734971][    T1]  ? virtio_dev_probe+0x991/0xaf0
[    7.734971][    T1]  ? really_probe+0x2b8/0xad0
[    7.734971][    T1]  ? driver_probe_device+0x50/0x430
[    7.734971][    T1]  vring_create_virtqueue_split+0xc6/0x310
[    7.734971][    T1]  ? ret_from_fork+0x4b/0x80
[    7.734971][    T1]  ? __pfx_vring_create_virtqueue_split+0x10/0x10
[    7.734971][    T1]  vring_create_virtqueue+0xca/0x110
[    7.734971][    T1]  ? __pfx_vp_notify+0x10/0x10
[    7.734971][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.734971][    T1]  setup_vq+0xe9/0x2d0
[    7.734971][    T1]  ? __pfx_vp_notify+0x10/0x10
[    7.734971][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.784590][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.784590][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.784590][    T1]  vp_setup_vq+0xbf/0x330
[    7.784590][    T1]  ? __pfx_vp_config_changed+0x10/0x10
[    7.784590][    T1]  ? ioread16+0x2f/0x90
[    7.784590][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.784590][    T1]  vp_find_vqs_msix+0x8b2/0xc80
[    7.784590][    T1]  vp_find_vqs+0x4c/0x4e0
[    7.784590][    T1]  virtscsi_init+0x8db/0xd00
[    7.784590][    T1]  ? __pfx_virtscsi_init+0x10/0x10
[    7.784590][    T1]  ? __pfx_default_calc_sets+0x10/0x10
[    7.784590][    T1]  ? scsi_host_alloc+0xa57/0xea0
[    7.784590][    T1]  ? vp_get+0xfd/0x140
[    7.784590][    T1]  virtscsi_probe+0x3ea/0xf60
[    7.784590][    T1]  ? __pfx_virtscsi_probe+0x10/0x10
[    7.784590][    T1]  ? kernfs_add_one+0x156/0x8b0
[    7.784590][    T1]  ? virtio_no_restricted_mem_acc+0x9/0x10
[    7.784590][    T1]  ? virtio_features_ok+0x10c/0x270
[    7.784590][    T1]  virtio_dev_probe+0x991/0xaf0
[    7.784590][    T1]  ? __pfx_virtio_dev_probe+0x10/0x10
[    7.784590][    T1]  really_probe+0x2b8/0xad0
[    7.784590][    T1]  __driver_probe_device+0x1a2/0x390
[    7.784590][    T1]  driver_probe_device+0x50/0x430
[    7.784590][    T1]  __driver_attach+0x45f/0x710
[    7.784590][    T1]  ? __pfx___driver_attach+0x10/0x10
[    7.784590][    T1]  bus_for_each_dev+0x239/0x2b0
[    7.784590][    T1]  ? __pfx___driver_attach+0x10/0x10
[    7.784590][    T1]  ? __pfx_bus_for_each_dev+0x10/0x10
[    7.784590][    T1]  ? do_raw_spin_unlock+0x13c/0x8b0
[    7.784590][    T1]  bus_add_driver+0x347/0x620
[    7.784590][    T1]  driver_register+0x23a/0x320
[    7.784590][    T1]  ? __pfx_virtio_scsi_init+0x10/0x10
[    7.784590][    T1]  virtio_scsi_init+0x65/0xe0
[    7.784590][    T1]  ? __pfx_virtio_scsi_init+0x10/0x10
[    7.784590][    T1]  do_one_initcall+0x248/0x880
[    7.784590][    T1]  ? __pfx_virtio_scsi_init+0x10/0x10
[    7.784590][    T1]  ? __pfx_do_one_initcall+0x10/0x10
[    7.784590][    T1]  ? lockdep_hardirqs_on_prepare+0x43d/0x780
[    7.784590][    T1]  ? __pfx_parse_args+0x10/0x10
[    7.784590][    T1]  ? do_initcalls+0x1c/0x80
[    7.784590][    T1]  ? rcu_is_watching+0x15/0xb0
[    7.784590][    T1]  do_initcall_level+0x157/0x210
[    7.784590][    T1]  do_initcalls+0x3f/0x80
[    7.784590][    T1]  kernel_init_freeable+0x435/0x5d0
[    7.784590][    T1]  ? __pfx_kernel_init_freeable+0x10/0x10
[    7.784590][    T1]  ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10
[    7.784590][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.784590][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.784590][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.784590][    T1]  kernel_init+0x1d/0x2b0
[    7.784590][    T1]  ret_from_fork+0x4b/0x80
[    7.784590][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.784590][    T1]  ret_from_fork_asm+0x1a/0x30
[    7.834581][    T1]  </TASK>
[    7.834581][    T1] Kernel Offset: disabled
[    7.834581][    T1] Rebooting in 86400 seconds..


syzkaller build log:
go env (err=<nil>)
GO111MODULE='auto'
GOARCH='amd64'
GOBIN=''
GOCACHE='/syzkaller/.cache/go-build'
GOENV='/syzkaller/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/syzkaller/jobs-2/linux/gopath/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/syzkaller/jobs-2/linux/gopath'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.4'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/syzkaller/jobs-2/linux/gopath/src/github.com/google/syzkaller/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build686088701=/tmp/go-build -gno-record-gcc-switches'

git status (err=<nil>)
HEAD detached at 610f2a54d
nothing to commit, working tree clean


tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
go list -f '{{.Stale}}' ./sys/syz-sysgen | grep -q false || go install ./sys/syz-sysgen
make .descriptions
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
bin/syz-sysgen
touch .descriptions
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=610f2a54d02f8cf4f2454c03bf679b602e6e59b6 -X 'github.com/google/syzkaller/prog.gitRevisionDate=20240503-155746'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-fuzzer github.com/google/syzkaller/syz-fuzzer
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=610f2a54d02f8cf4f2454c03bf679b602e6e59b6 -X 'github.com/google/syzkaller/prog.gitRevisionDate=20240503-155746'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-execprog github.com/google/syzkaller/tools/syz-execprog
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=610f2a54d02f8cf4f2454c03bf679b602e6e59b6 -X 'github.com/google/syzkaller/prog.gitRevisionDate=20240503-155746'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-stress github.com/google/syzkaller/tools/syz-stress
mkdir -p ./bin/linux_amd64
gcc -o ./bin/linux_amd64/syz-executor executor/executor.cc \
	-m64 -std=c++11 -I. -Ivendor -O2 -pthread -Wall -Werror -Wparentheses -Wunused-const-variable -Wframe-larger-than=16384 -Wno-stringop-overflow -Wno-array-bounds -Wno-format-overflow -Wno-unused-but-set-variable -Wno-unused-command-line-argument -static-pie -fpermissive -w -DGOOS_linux=1 -DGOARCH_amd64=1 \
	-DHOSTGOOS_linux=1 -DGIT_REVISION=\"610f2a54d02f8cf4f2454c03bf679b602e6e59b6\"


Error text is too large and was truncated, full error text is at:
https://syzkaller.appspot.com/x/error.txt?x=1233c3ec980000


Tested on:

commit:         889914b5 f2fs: fix to cover read extent cache access w..
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git wip
kernel config:  https://syzkaller.appspot.com/x/.config?x=1ace29459a0a1915
dashboard link: https://syzkaller.appspot.com/bug?extid=74ebe2104433e9dc610d
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

Note: no patches were applied.


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[relevance 2%]

* Re: [PATCH v5 2/3] virtio-net: Clarify the size of the struct virtio_net_hdr for tx
  @ 2024-05-29 11:47  0%   ` Xuan Zhuo
  0 siblings, 0 replies; 200+ results
From: Xuan Zhuo @ 2024-05-29 11:47 UTC (permalink / raw)
  To: Parav Pandit
  Cc: shahafs, xuanzhuo, yuri.benditovich, Parav Pandit,
	virtio-comment, mst, cohuck

On Tue, 21 May 2024 15:23:02 +0300, Parav Pandit <parav@nvidia.com> wrote:
> The feature VIRTIO_NET_F_HASH_REPORT only applies to the receive side.
> However, when VIRTIO_NET_F_HASH_REPORT feature was introduced, it was
> not clarified that the size of the struct virtio_net_hdr on the packet
> transmission also uses higher size when VIRTIO_NET_F_HASH_REPORT is
> negotiated.
>
> Explicitly clarify this.
>
> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/183
> Signed-off-by: Parav Pandit <parav@nvidia.com>

Reviewed-by: Xuan Zhuo <xuanzhuo@linux.alibaba.com>


>
> ---
> changelog:
> v2->v3:
> - rephrase tx to refer to the rx side virtio_net_hdr consideration
> - addressed comments from Xuan
> - replaced 'field' with 'structure'
> v0->v1:
> - addressed comments from Xuan to rewrite tx normative
> ---
>  device-types/net/description.tex | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/device-types/net/description.tex b/device-types/net/description.tex
> index 0753ba8..38992b0 100644
> --- a/device-types/net/description.tex
> +++ b/device-types/net/description.tex
> @@ -531,6 +531,9 @@ \subsubsection{Packet Transmission}\label{sec:Device Types / Network Device / De
>
>  \drivernormative{\paragraph}{Packet Transmission}{Device Types / Network Device / Device Operation / Packet Transmission}
>
> +For the transmit packet buffer, the driver MUST use the size of the
> +structure \field{struct virtio_net_hdr} same as the receive packet buffer.
> +
>  The driver MUST set \field{num_buffers} to zero.
>
>  If VIRTIO_NET_F_CSUM is not negotiated, the driver MUST set
> --
> 2.34.1
>

^ permalink raw reply	[relevance 0%]

* Re: [syzbot] [f2fs?] KASAN: slab-use-after-free Read in sanity_check_extent_cache
@ 2024-05-29 11:48  2%     ` syzbot
  0 siblings, 0 replies; 200+ results
From: syzbot @ 2024-05-29 11:48 UTC (permalink / raw)
  To: chao, jaegeuk, linux-f2fs-devel, linux-fsdevel, linux-kernel,
	syzkaller-bugs

Hello,

syzbot tried to test the proposed patch but the build/boot failed:

42][    T1] usbcore: registered new interface driver dln2
[    7.576709][    T1] usbcore: registered new interface driver pn533_usb
[    7.583988][    T1] nfcsim 0.2 initialized
[    7.586139][    T1] usbcore: registered new interface driver port100
[    7.587701][    T1] usbcore: registered new interface driver nfcmrvl
[    7.594256][    T1] Loading iSCSI transport class v2.0-870.
[    7.612218][    T1] virtio_scsi virtio0: 1/0/0 default/read/poll queues
[    7.621827][    T1] ------------[ cut here ]------------
[    7.622778][    T1] refcount_t: decrement hit 0; leaking memory.
[    7.626782][    T1] WARNING: CPU: 0 PID: 1 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0
[    7.628293][    T1] Modules linked in:
[    7.628860][    T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc1-syzkaller-00060-g889914b5c209 #0
[    7.630401][    T1] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
[    7.632495][    T1] RIP: 0010:refcount_warn_saturate+0xfa/0x1d0
[    7.634119][    T1] Code: b2 00 00 00 e8 67 52 f2 fc 5b 5d c3 cc cc cc cc e8 5b 52 f2 fc c6 05 51 cc ce 0a 01 90 48 c7 c7 a0 54 fe 8b e8 b7 d0 b4 fc 90 <0f> 0b 90 90 eb d9 e8 3b 52 f2 fc c6 05 2e cc ce 0a 01 90 48 c7 c7
[    7.638094][    T1] RSP: 0000:ffffc90000066e18 EFLAGS: 00010246
[    7.639044][    T1] RAX: 343580cc97689700 RBX: ffff8881401bf06c RCX: ffff8880166c8000
[    7.640552][    T1] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[    7.642175][    T1] RBP: 0000000000000004 R08: ffffffff8157ffe2 R09: fffffbfff1bf96e0
[    7.643575][    T1] R10: dffffc0000000000 R11: fffffbfff1bf96e0 R12: ffffea000501cdc0
[    7.645089][    T1] R13: ffffea000501cdc8 R14: 1ffffd4000a039b9 R15: 0000000000000000
[    7.646458][    T1] FS:  0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
[    7.647850][    T1] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    7.648816][    T1] CR2: ffff88823ffff000 CR3: 000000000df32000 CR4: 00000000003506f0
[    7.650069][    T1] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[    7.651660][    T1] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[    7.653255][    T1] Call Trace:
[    7.653955][    T1]  <TASK>
[    7.655231][    T1]  ? __warn+0x163/0x4e0
[    7.656060][    T1]  ? refcount_warn_saturate+0xfa/0x1d0
[    7.657004][    T1]  ? report_bug+0x2b3/0x500
[    7.657697][    T1]  ? refcount_warn_saturate+0xfa/0x1d0
[    7.658659][    T1]  ? handle_bug+0x3e/0x70
[    7.659735][    T1]  ? exc_invalid_op+0x1a/0x50
[    7.660993][    T1]  ? asm_exc_invalid_op+0x1a/0x20
[    7.661819][    T1]  ? __warn_printk+0x292/0x360
[    7.662573][    T1]  ? refcount_warn_saturate+0xfa/0x1d0
[    7.663589][    T1]  ? refcount_warn_saturate+0xf9/0x1d0
[    7.664642][    T1]  __free_pages_ok+0xc54/0xd80
[    7.665381][    T1]  make_alloc_exact+0xa3/0xf0
[    7.666771][    T1]  vring_alloc_queue_split+0x20a/0x600
[    7.667714][    T1]  ? __pfx_vring_alloc_queue_split+0x10/0x10
[    7.668766][    T1]  ? vp_find_vqs+0x4c/0x4e0
[    7.669540][    T1]  ? virtscsi_probe+0x3ea/0xf60
[    7.670758][    T1]  ? virtio_dev_probe+0x991/0xaf0
[    7.671577][    T1]  ? really_probe+0x2b8/0xad0
[    7.672570][    T1]  ? driver_probe_device+0x50/0x430
[    7.673427][    T1]  vring_create_virtqueue_split+0xc6/0x310
[    7.674713][    T1]  ? ret_from_fork+0x4b/0x80
[    7.675577][    T1]  ? __pfx_vring_create_virtqueue_split+0x10/0x10
[    7.676513][    T1]  vring_create_virtqueue+0xca/0x110
[    7.677483][    T1]  ? __pfx_vp_notify+0x10/0x10
[    7.678536][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.679645][    T1]  setup_vq+0xe9/0x2d0
[    7.680389][    T1]  ? __pfx_vp_notify+0x10/0x10
[    7.681211][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.682323][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.683391][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.684728][    T1]  vp_setup_vq+0xbf/0x330
[    7.685412][    T1]  ? __pfx_vp_config_changed+0x10/0x10
[    7.686599][    T1]  ? ioread16+0x2f/0x90
[    7.687219][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.688543][    T1]  vp_find_vqs_msix+0x8b2/0xc80
[    7.689396][    T1]  vp_find_vqs+0x4c/0x4e0
[    7.690066][    T1]  virtscsi_init+0x8db/0xd00
[    7.690768][    T1]  ? __pfx_virtscsi_init+0x10/0x10
[    7.691800][    T1]  ? __pfx_default_calc_sets+0x10/0x10
[    7.692645][    T1]  ? scsi_host_alloc+0xa57/0xea0
[    7.693496][    T1]  ? vp_get+0xfd/0x140
[    7.694109][    T1]  virtscsi_probe+0x3ea/0xf60
[    7.695276][    T1]  ? __pfx_virtscsi_probe+0x10/0x10
[    7.696256][    T1]  ? kernfs_add_one+0x156/0x8b0
[    7.697276][    T1]  ? virtio_no_restricted_mem_acc+0x9/0x10
[    7.698400][    T1]  ? virtio_features_ok+0x10c/0x270
[    7.699300][    T1]  virtio_dev_probe+0x991/0xaf0
[    7.700143][    T1]  ? __pfx_virtio_dev_probe+0x10/0x10
[    7.700985][    T1]  really_probe+0x2b8/0xad0
[    7.702196][    T1]  __driver_probe_device+0x1a2/0x390
[    7.703259][    T1]  driver_probe_device+0x50/0x430
[    7.704075][    T1]  __driver_attach+0x45f/0x710
[    7.704819][    T1]  ? __pfx___driver_attach+0x10/0x10
[    7.705601][    T1]  bus_for_each_dev+0x239/0x2b0
[    7.706514][    T1]  ? __pfx___driver_attach+0x10/0x10
[    7.707442][    T1]  ? __pfx_bus_for_each_dev+0x10/0x10
[    7.708680][    T1]  ? do_raw_spin_unlock+0x13c/0x8b0
[    7.710058][    T1]  bus_add_driver+0x347/0x620
[    7.711073][    T1]  driver_register+0x23a/0x320
[    7.712178][    T1]  ? __pfx_virtio_scsi_init+0x10/0x10
[    7.713450][    T1]  virtio_scsi_init+0x65/0xe0
[    7.714571][    T1]  ? __pfx_virtio_scsi_init+0x10/0x10
[    7.715692][    T1]  do_one_initcall+0x248/0x880
[    7.716533][    T1]  ? __pfx_virtio_scsi_init+0x10/0x10
[    7.717409][    T1]  ? __pfx_do_one_initcall+0x10/0x10
[    7.718599][    T1]  ? lockdep_hardirqs_on_prepare+0x43d/0x780
[    7.719639][    T1]  ? __pfx_parse_args+0x10/0x10
[    7.720523][    T1]  ? do_initcalls+0x1c/0x80
[    7.721261][    T1]  ? rcu_is_watching+0x15/0xb0
[    7.722428][    T1]  do_initcall_level+0x157/0x210
[    7.723278][    T1]  do_initcalls+0x3f/0x80
[    7.723962][    T1]  kernel_init_freeable+0x435/0x5d0
[    7.725035][    T1]  ? __pfx_kernel_init_freeable+0x10/0x10
[    7.726103][    T1]  ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10
[    7.727205][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.728033][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.729046][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.729731][    T1]  kernel_init+0x1d/0x2b0
[    7.730411][    T1]  ret_from_fork+0x4b/0x80
[    7.731117][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.731836][    T1]  ret_from_fork_asm+0x1a/0x30
[    7.732580][    T1]  </TASK>
[    7.733103][    T1] Kernel panic - not syncing: kernel: panic_on_warn set ...
[    7.734198][    T1] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc1-syzkaller-00060-g889914b5c209 #0
[    7.734971][    T1] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
[    7.734971][    T1] Call Trace:
[    7.734971][    T1]  <TASK>
[    7.734971][    T1]  dump_stack_lvl+0x241/0x360
[    7.734971][    T1]  ? __pfx_dump_stack_lvl+0x10/0x10
[    7.734971][    T1]  ? __pfx__printk+0x10/0x10
[    7.734971][    T1]  ? _printk+0xd5/0x120
[    7.734971][    T1]  ? vscnprintf+0x5d/0x90
[    7.734971][    T1]  panic+0x349/0x860
[    7.734971][    T1]  ? __warn+0x172/0x4e0
[    7.734971][    T1]  ? __pfx_panic+0x10/0x10
[    7.734971][    T1]  ? show_trace_log_lvl+0x4e6/0x520
[    7.734971][    T1]  ? ret_from_fork_asm+0x1a/0x30
[    7.734971][    T1]  __warn+0x346/0x4e0
[    7.734971][    T1]  ? refcount_warn_saturate+0xfa/0x1d0
[    7.734971][    T1]  report_bug+0x2b3/0x500
[    7.734971][    T1]  ? refcount_warn_saturate+0xfa/0x1d0
[    7.734971][    T1]  handle_bug+0x3e/0x70
[    7.734971][    T1]  exc_invalid_op+0x1a/0x50
[    7.734971][    T1]  asm_exc_invalid_op+0x1a/0x20
[    7.734971][    T1] RIP: 0010:refcount_warn_saturate+0xfa/0x1d0
[    7.734971][    T1] Code: b2 00 00 00 e8 67 52 f2 fc 5b 5d c3 cc cc cc cc e8 5b 52 f2 fc c6 05 51 cc ce 0a 01 90 48 c7 c7 a0 54 fe 8b e8 b7 d0 b4 fc 90 <0f> 0b 90 90 eb d9 e8 3b 52 f2 fc c6 05 2e cc ce 0a 01 90 48 c7 c7
[    7.734971][    T1] RSP: 0000:ffffc90000066e18 EFLAGS: 00010246
[    7.734971][    T1] RAX: 343580cc97689700 RBX: ffff8881401bf06c RCX: ffff8880166c8000
[    7.734971][    T1] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
[    7.734971][    T1] RBP: 0000000000000004 R08: ffffffff8157ffe2 R09: fffffbfff1bf96e0
[    7.734971][    T1] R10: dffffc0000000000 R11: fffffbfff1bf96e0 R12: ffffea000501cdc0
[    7.734971][    T1] R13: ffffea000501cdc8 R14: 1ffffd4000a039b9 R15: 0000000000000000
[    7.734971][    T1]  ? __warn_printk+0x292/0x360
[    7.734971][    T1]  ? refcount_warn_saturate+0xf9/0x1d0
[    7.734971][    T1]  __free_pages_ok+0xc54/0xd80
[    7.734971][    T1]  make_alloc_exact+0xa3/0xf0
[    7.734971][    T1]  vring_alloc_queue_split+0x20a/0x600
[    7.734971][    T1]  ? __pfx_vring_alloc_queue_split+0x10/0x10
[    7.734971][    T1]  ? vp_find_vqs+0x4c/0x4e0
[    7.734971][    T1]  ? virtscsi_probe+0x3ea/0xf60
[    7.734971][    T1]  ? virtio_dev_probe+0x991/0xaf0
[    7.734971][    T1]  ? really_probe+0x2b8/0xad0
[    7.734971][    T1]  ? driver_probe_device+0x50/0x430
[    7.734971][    T1]  vring_create_virtqueue_split+0xc6/0x310
[    7.734971][    T1]  ? ret_from_fork+0x4b/0x80
[    7.734971][    T1]  ? __pfx_vring_create_virtqueue_split+0x10/0x10
[    7.734971][    T1]  vring_create_virtqueue+0xca/0x110
[    7.734971][    T1]  ? __pfx_vp_notify+0x10/0x10
[    7.734971][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.734971][    T1]  setup_vq+0xe9/0x2d0
[    7.734971][    T1]  ? __pfx_vp_notify+0x10/0x10
[    7.734971][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.784590][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.784590][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.784590][    T1]  vp_setup_vq+0xbf/0x330
[    7.784590][    T1]  ? __pfx_vp_config_changed+0x10/0x10
[    7.784590][    T1]  ? ioread16+0x2f/0x90
[    7.784590][    T1]  ? __pfx_virtscsi_ctrl_done+0x10/0x10
[    7.784590][    T1]  vp_find_vqs_msix+0x8b2/0xc80
[    7.784590][    T1]  vp_find_vqs+0x4c/0x4e0
[    7.784590][    T1]  virtscsi_init+0x8db/0xd00
[    7.784590][    T1]  ? __pfx_virtscsi_init+0x10/0x10
[    7.784590][    T1]  ? __pfx_default_calc_sets+0x10/0x10
[    7.784590][    T1]  ? scsi_host_alloc+0xa57/0xea0
[    7.784590][    T1]  ? vp_get+0xfd/0x140
[    7.784590][    T1]  virtscsi_probe+0x3ea/0xf60
[    7.784590][    T1]  ? __pfx_virtscsi_probe+0x10/0x10
[    7.784590][    T1]  ? kernfs_add_one+0x156/0x8b0
[    7.784590][    T1]  ? virtio_no_restricted_mem_acc+0x9/0x10
[    7.784590][    T1]  ? virtio_features_ok+0x10c/0x270
[    7.784590][    T1]  virtio_dev_probe+0x991/0xaf0
[    7.784590][    T1]  ? __pfx_virtio_dev_probe+0x10/0x10
[    7.784590][    T1]  really_probe+0x2b8/0xad0
[    7.784590][    T1]  __driver_probe_device+0x1a2/0x390
[    7.784590][    T1]  driver_probe_device+0x50/0x430
[    7.784590][    T1]  __driver_attach+0x45f/0x710
[    7.784590][    T1]  ? __pfx___driver_attach+0x10/0x10
[    7.784590][    T1]  bus_for_each_dev+0x239/0x2b0
[    7.784590][    T1]  ? __pfx___driver_attach+0x10/0x10
[    7.784590][    T1]  ? __pfx_bus_for_each_dev+0x10/0x10
[    7.784590][    T1]  ? do_raw_spin_unlock+0x13c/0x8b0
[    7.784590][    T1]  bus_add_driver+0x347/0x620
[    7.784590][    T1]  driver_register+0x23a/0x320
[    7.784590][    T1]  ? __pfx_virtio_scsi_init+0x10/0x10
[    7.784590][    T1]  virtio_scsi_init+0x65/0xe0
[    7.784590][    T1]  ? __pfx_virtio_scsi_init+0x10/0x10
[    7.784590][    T1]  do_one_initcall+0x248/0x880
[    7.784590][    T1]  ? __pfx_virtio_scsi_init+0x10/0x10
[    7.784590][    T1]  ? __pfx_do_one_initcall+0x10/0x10
[    7.784590][    T1]  ? lockdep_hardirqs_on_prepare+0x43d/0x780
[    7.784590][    T1]  ? __pfx_parse_args+0x10/0x10
[    7.784590][    T1]  ? do_initcalls+0x1c/0x80
[    7.784590][    T1]  ? rcu_is_watching+0x15/0xb0
[    7.784590][    T1]  do_initcall_level+0x157/0x210
[    7.784590][    T1]  do_initcalls+0x3f/0x80
[    7.784590][    T1]  kernel_init_freeable+0x435/0x5d0
[    7.784590][    T1]  ? __pfx_kernel_init_freeable+0x10/0x10
[    7.784590][    T1]  ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10
[    7.784590][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.784590][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.784590][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.784590][    T1]  kernel_init+0x1d/0x2b0
[    7.784590][    T1]  ret_from_fork+0x4b/0x80
[    7.784590][    T1]  ? __pfx_kernel_init+0x10/0x10
[    7.784590][    T1]  ret_from_fork_asm+0x1a/0x30
[    7.834581][    T1]  </TASK>
[    7.834581][    T1] Kernel Offset: disabled
[    7.834581][    T1] Rebooting in 86400 seconds..


syzkaller build log:
go env (err=<nil>)
GO111MODULE='auto'
GOARCH='amd64'
GOBIN=''
GOCACHE='/syzkaller/.cache/go-build'
GOENV='/syzkaller/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/syzkaller/jobs-2/linux/gopath/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/syzkaller/jobs-2/linux/gopath'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.4'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/syzkaller/jobs-2/linux/gopath/src/github.com/google/syzkaller/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build686088701=/tmp/go-build -gno-record-gcc-switches'

git status (err=<nil>)
HEAD detached at 610f2a54d
nothing to commit, working tree clean


tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
go list -f '{{.Stale}}' ./sys/syz-sysgen | grep -q false || go install ./sys/syz-sysgen
make .descriptions
tput: No value for $TERM and no -T specified
tput: No value for $TERM and no -T specified
Makefile:31: run command via tools/syz-env for best compatibility, see:
Makefile:32: https://github.com/google/syzkaller/blob/master/docs/contributing.md#using-syz-env
bin/syz-sysgen
touch .descriptions
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=610f2a54d02f8cf4f2454c03bf679b602e6e59b6 -X 'github.com/google/syzkaller/prog.gitRevisionDate=20240503-155746'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-fuzzer github.com/google/syzkaller/syz-fuzzer
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=610f2a54d02f8cf4f2454c03bf679b602e6e59b6 -X 'github.com/google/syzkaller/prog.gitRevisionDate=20240503-155746'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-execprog github.com/google/syzkaller/tools/syz-execprog
GOOS=linux GOARCH=amd64 go build "-ldflags=-s -w -X github.com/google/syzkaller/prog.GitRevision=610f2a54d02f8cf4f2454c03bf679b602e6e59b6 -X 'github.com/google/syzkaller/prog.gitRevisionDate=20240503-155746'" "-tags=syz_target syz_os_linux syz_arch_amd64 " -o ./bin/linux_amd64/syz-stress github.com/google/syzkaller/tools/syz-stress
mkdir -p ./bin/linux_amd64
gcc -o ./bin/linux_amd64/syz-executor executor/executor.cc \
	-m64 -std=c++11 -I. -Ivendor -O2 -pthread -Wall -Werror -Wparentheses -Wunused-const-variable -Wframe-larger-than=16384 -Wno-stringop-overflow -Wno-array-bounds -Wno-format-overflow -Wno-unused-but-set-variable -Wno-unused-command-line-argument -static-pie -fpermissive -w -DGOOS_linux=1 -DGOARCH_amd64=1 \
	-DHOSTGOOS_linux=1 -DGIT_REVISION=\"610f2a54d02f8cf4f2454c03bf679b602e6e59b6\"


Error text is too large and was truncated, full error text is at:
https://syzkaller.appspot.com/x/error.txt?x=1233c3ec980000


Tested on:

commit:         889914b5 f2fs: fix to cover read extent cache access w..
git tree:       https://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git wip
kernel config:  https://syzkaller.appspot.com/x/.config?x=1ace29459a0a1915
dashboard link: https://syzkaller.appspot.com/bug?extid=74ebe2104433e9dc610d
compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

Note: no patches were applied.

^ permalink raw reply	[relevance 2%]

* Re: [PATCH v9 3/8] drm/i915: Compute CMRR and calculate vtotal
  @ 2024-05-29 11:43  0%     ` Nautiyal, Ankit K
  0 siblings, 0 replies; 200+ results
From: Nautiyal, Ankit K @ 2024-05-29 11:43 UTC (permalink / raw)
  To: Mitul Golani, intel-gfx


On 5/28/2024 3:04 PM, Nautiyal, Ankit K wrote:
>
> On 5/24/2024 3:54 PM, Mitul Golani wrote:
>> Compute Fixed Average Vtotal/CMRR with resepect to
>> userspace VRR enablement. Also calculate required
>> parameters in case of CMRR is  enabled. During
>> intel_vrr_compute_config, CMRR is getting enabled
>> based on userspace has enabled Variable refresh mode
>> with VRR timing generator or not. Make CMRR as small subset of
>> FAVT mode, when Panel is running on Fixed refresh rate
>> and on VRR framework then only enable CMRR to match with
>> actual refresh rate.
>>
>> --v2:
>> - Update is_cmrr_frac_required function return as bool, not int. [Jani]
>> - Use signed int math instead of unsigned in cmrr_get_vtotal2. [Jani]
>> - Fix typo and usage of camel case in cmrr_get_vtotal. [Jani]
>> - Use do_div in cmrr_get_vtotalwhile calculating cmrr_m. [ Jani]
>> - Simplify cmrr and vrr compute config in intel_vrr_compute_config. 
>> [Jani]
>> - Correct valiable name usage in is_cmrr_frac_required. [Ville]
>>
>> --v3:
>> - Removing RFC tag.
>>
>> --v4:
>> - Added edp check to address edp usecase for now. (ville)
>> - Updated is_cmrr_fraction_required to more simplified calculation.
>> - on longterm goal to be worked upon uapi as suggestion from ville.
>>
>> --v5:
>> - Correct vtotal paramas accuracy and add 2 digit precision.
>> - Avoid using DIV_ROUND_UP and improve scanline precision.
>>
>> --v6:
>> - Make CMRR a small subset of FAVT mode.
>>
>> --v7:
>> - Update commit message to avoid confusion with Legacy VRR (Ankit).
>> - Add cmrr.enable in last, so remove from this patch.
>>
>> Signed-off-by: Mitul Golani <mitulkumar.ajitkumar.golani@intel.com>
>> ---
>>   drivers/gpu/drm/i915/display/intel_display.c  |  1 +
>>   .../drm/i915/display/intel_display_device.h   |  1 +
>>   drivers/gpu/drm/i915/display/intel_vrr.c      | 99 ++++++++++++++++---
>>   3 files changed, 89 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index 803360fcb0cc..f7e82d1e2bf9 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -5437,6 +5437,7 @@ intel_pipe_config_compare(const struct 
>> intel_crtc_state *current_config,
>>           PIPE_CONF_CHECK_I(vrr.vsync_end);
>>           PIPE_CONF_CHECK_LLI(cmrr.cmrr_m);
>>           PIPE_CONF_CHECK_LLI(cmrr.cmrr_n);
>> +        PIPE_CONF_CHECK_BOOL(cmrr.enable);
>>       }
>>     #undef PIPE_CONF_CHECK_X
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_device.h 
>> b/drivers/gpu/drm/i915/display/intel_display_device.h
>> index 17ddf82f0b6e..b372b1acc19b 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_device.h
>> +++ b/drivers/gpu/drm/i915/display/intel_display_device.h
>> @@ -71,6 +71,7 @@ struct drm_printer;
>>                         BIT(trans)) != 0)
>>   #define HAS_VRR(i915)            (DISPLAY_VER(i915) >= 11)
>>   #define HAS_AS_SDP(i915)        (DISPLAY_VER(i915) >= 13)
>> +#define HAS_CMRR(i915)            (DISPLAY_VER(i915) >= 20)
>>   #define INTEL_NUM_PIPES(i915) 
>> (hweight8(DISPLAY_RUNTIME_INFO(i915)->pipe_mask))
>>   #define I915_HAS_HOTPLUG(i915) (DISPLAY_INFO(i915)->has_hotplug)
>>   #define OVERLAY_NEEDS_PHYSICAL(i915) 
>> (DISPLAY_INFO(i915)->overlay_needs_physical)
>> diff --git a/drivers/gpu/drm/i915/display/intel_vrr.c 
>> b/drivers/gpu/drm/i915/display/intel_vrr.c
>> index 3b250e92af98..3fbedd7366bb 100644
>> --- a/drivers/gpu/drm/i915/display/intel_vrr.c
>> +++ b/drivers/gpu/drm/i915/display/intel_vrr.c
>> @@ -12,6 +12,9 @@
>>   #include "intel_vrr_reg.h"
>>   #include "intel_dp.h"
>>   +#define FIXED_POINT_PRECISION        100
>> +#define CMRR_PRECISION_TOLERANCE    10
>> +
>>   bool intel_vrr_is_capable(struct intel_connector *connector)
>>   {
>>       const struct drm_display_info *info = 
>> &connector->base.display_info;
>> @@ -107,6 +110,59 @@ int intel_vrr_vmax_vblank_start(const struct 
>> intel_crtc_state *crtc_state)
>>       return crtc_state->vrr.vmax - 
>> intel_vrr_vblank_exit_length(crtc_state);
>>   }
>>   +static bool
>> +is_cmrr_frac_required(struct intel_crtc_state *crtc_state, bool is_edp)
>> +{
>> +    int calculated_refresh_k, actual_refresh_k, pixel_clock_per_line;
>> +    struct drm_display_mode *adjusted_mode = 
>> &crtc_state->hw.adjusted_mode;
>> +    struct drm_i915_private *i915 = 
>> to_i915(crtc_state->uapi.crtc->dev);
>> +
>> +    if (!(HAS_CMRR(i915) && is_edp))
>> +        return false;
>> +
>> +    actual_refresh_k =
>> +        drm_mode_vrefresh(adjusted_mode) * FIXED_POINT_PRECISION;
>> +    pixel_clock_per_line =
>> +        adjusted_mode->crtc_clock * 1000 / adjusted_mode->crtc_htotal;
>> +    calculated_refresh_k =
>> +        pixel_clock_per_line * FIXED_POINT_PRECISION / 
>> adjusted_mode->crtc_vtotal;
>> +
>> +    if ((actual_refresh_k - calculated_refresh_k) < 
>> CMRR_PRECISION_TOLERANCE)
>> +        return false;
>> +
>> +    return true;
>> +}
>> +
>> +static unsigned int
>> +cmrr_get_vtotal(struct intel_crtc_state *crtc_state)
>> +{
>> +    int multiplier_m = 1, multiplier_n = 1, vtotal;
>> +    int actual_refresh_rate, desired_refresh_rate;
>> +    long long actual_pixel_rate, adjusted_pixel_rate, 
>> pixel_clock_per_line;
>> +    struct drm_display_mode *adjusted_mode = 
>> &crtc_state->hw.adjusted_mode;
>> +
>> +    pixel_clock_per_line =
>> +        adjusted_mode->crtc_clock * 1000 / adjusted_mode->crtc_htotal;
>> +    actual_refresh_rate =
>> +        pixel_clock_per_line * FIXED_POINT_PRECISION / 
>> adjusted_mode->crtc_vtotal;
>> +    desired_refresh_rate = drm_mode_vrefresh(adjusted_mode);
>> +    actual_pixel_rate = actual_refresh_rate * 
>> adjusted_mode->crtc_vtotal;
>> +    actual_pixel_rate =
>> +        (actual_pixel_rate * adjusted_mode->crtc_htotal) / 
>> FIXED_POINT_PRECISION;
> I am still not clear about this part. isnt actual_pixel_rate simply 
> adjusted_mode->crtc_clock?
>> +
>> +    multiplier_m = 1001;
>> +    multiplier_n = 1000;

I think multiplier_m and multiplier should be 1 as initialized above.

AFAIU the multipliers 1001 and 1000 are used in videomodes with 59.94, 
71.928Hz etc.


Regards,

Ankit

>> +
>> +    crtc_state->cmrr.cmrr_n =
>> +        ((desired_refresh_rate * adjusted_mode->crtc_htotal * 
>> multiplier_n) / multiplier_m);
>> +    crtc_state->cmrr.cmrr_n *= multiplier_n;
>
>
> This seems wrong: As per bspec:68925 this should be just: 
> crtc_state->cmrr.cmrr_n = ((desired_refresh_rate * 
> adjusted_mode->crtc_htotal * multiplier_n);
>
>
>> +    vtotal = (actual_pixel_rate * multiplier_n) / 
>> crtc_state->cmrr.cmrr_n;
>> +    adjusted_pixel_rate = actual_pixel_rate * multiplier_m;
>> +    crtc_state->cmrr.cmrr_m = do_div(adjusted_pixel_rate, 
>> crtc_state->cmrr.cmrr_n);
>> +
>> +    return vtotal;
>> +}
>> +
>>   void
>>   intel_vrr_compute_config(struct intel_crtc_state *crtc_state,
>>                struct drm_connector_state *conn_state)
>> @@ -116,6 +172,7 @@ intel_vrr_compute_config(struct intel_crtc_state 
>> *crtc_state,
>>       struct intel_connector *connector =
>>           to_intel_connector(conn_state->connector);
>>       struct intel_dp *intel_dp = intel_attached_dp(connector);
>> +    bool is_edp = intel_dp_is_edp(intel_dp);
>>       struct drm_display_mode *adjusted_mode = 
>> &crtc_state->hw.adjusted_mode;
>>       const struct drm_display_info *info = 
>> &connector->base.display_info;
>>       int vmin, vmax;
>> @@ -160,18 +217,10 @@ intel_vrr_compute_config(struct 
>> intel_crtc_state *crtc_state,
>>       crtc_state->vrr.flipline = crtc_state->vrr.vmin + 1;
>>         /*
>> -     * For XE_LPD+, we use guardband and pipeline override
>> -     * is deprecated.
>> +     * When panel is VRR capable and userspace has
>> +     * not enabled adaptive sync mode then Fixed Average
>> +     * Vtotal mode should be enabled.
>>        */
>> -    if (DISPLAY_VER(i915) >= 13) {
>> -        crtc_state->vrr.guardband =
>> -            crtc_state->vrr.vmin + 1 - 
>> adjusted_mode->crtc_vblank_start;
>> -    } else {
>> -        crtc_state->vrr.pipeline_full =
>> -            min(255, crtc_state->vrr.vmin - 
>> adjusted_mode->crtc_vblank_start -
>> -                crtc_state->framestart_delay - 1);
>> -    }
>> -
>>       if (crtc_state->uapi.vrr_enabled) {
>>           crtc_state->vrr.enable = true;
>>           crtc_state->mode_flags |= I915_MODE_FLAG_VRR;
>> @@ -183,6 +232,25 @@ intel_vrr_compute_config(struct intel_crtc_state 
>> *crtc_state,
>>                   (crtc_state->hw.adjusted_mode.crtc_vtotal -
>> crtc_state->hw.adjusted_mode.vsync_end);
>>           }
>> +    } else if (is_cmrr_frac_required(crtc_state, is_edp)) {
>> +        crtc_state->vrr.enable = true;
>
> I think it will be better to add crtc_state->cmrr.enable = true; here 
> instead of a separate patch.
>
>
>> +        crtc_state->vrr.vmax = cmrr_get_vtotal(crtc_state);
>> +        crtc_state->vrr.vmin = crtc_state->vrr.vmax;
>> +        crtc_state->vrr.flipline = crtc_state->vrr.vmin;
>> +        crtc_state->mode_flags |= I915_MODE_FLAG_VRR;
>> +    }
>> +
>> +    /*
>> +     * For XE_LPD+, we use guardband and pipeline override
>> +     * is deprecated.
>> +     */
>> +    if (DISPLAY_VER(i915) >= 13) {
>> +        crtc_state->vrr.guardband =
>> +            crtc_state->vrr.vmin + 1 - 
>> adjusted_mode->crtc_vblank_start;
>> +    } else {
>> +        crtc_state->vrr.pipeline_full =
>> +            min(255, crtc_state->vrr.vmin - 
>> adjusted_mode->crtc_vblank_start -
>> +                crtc_state->framestart_delay - 1);
>>       }
>>   }
>>   @@ -323,7 +391,14 @@ void intel_vrr_get_config(struct 
>> intel_crtc_state *crtc_state)
>>       trans_vrr_ctl = intel_de_read(dev_priv,
>>                         TRANS_VRR_CTL(dev_priv, cpu_transcoder));
>>   -    crtc_state->vrr.enable = trans_vrr_ctl & VRR_CTL_VRR_ENABLE;
>> +    if (HAS_CMRR(dev_priv)) {
>> +        crtc_state->cmrr.enable = (trans_vrr_ctl & 
>> VRR_CTL_CMRR_ENABLE) &&
>> +                      (trans_vrr_ctl & VRR_CTL_VRR_ENABLE);
>> +        crtc_state->vrr.enable = trans_vrr_ctl & VRR_CTL_VRR_ENABLE &&
>> +                     !(trans_vrr_ctl & VRR_CTL_CMRR_ENABLE);
>
>
> Since vrr.enable and cmrr.enable are not mutually exclusive, this 
> simple can be:
>
> crtc_state->vrr.enable = trans_vrr_ctl & VRR_CTL_VRR_ENABLE;
>
> if (HAS_CMRR(dev_priv)
>
>      crtc_state->cmrr.enable = trans_vrr_ctl & VRR_CTL_CMRR_ENABLE;
>
>
> Regards,
>
> Ankit
>
>> +    } else {
>> +        crtc_state->vrr.enable = trans_vrr_ctl & VRR_CTL_VRR_ENABLE;
>> +    }
>>         if (crtc_state->cmrr.enable) {
>>           crtc_state->cmrr.cmrr_n =

^ permalink raw reply	[relevance 0%]

* [pci:controller/exynos] BUILD SUCCESS 6b11143f9344ddfb6f27559743db36b85e8e6a89
@ 2024-05-29 11:42  1% kernel test robot
  0 siblings, 0 replies; 200+ results
From: kernel test robot @ 2024-05-29 11:42 UTC (permalink / raw)
  To: Bjorn Helgaas; +Cc: linux-pci

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git controller/exynos
branch HEAD: 6b11143f9344ddfb6f27559743db36b85e8e6a89  PCI: exynos: Adapt to use bulk clock APIs

elapsed time: 1121m

configs tested: 159
configs skipped: 3

The following configs have been built successfully.
More configs may be tested in the coming days.

tested configs:
alpha                             allnoconfig   gcc  
alpha                            allyesconfig   gcc  
alpha                               defconfig   gcc  
arc                              allmodconfig   gcc  
arc                               allnoconfig   gcc  
arc                              allyesconfig   gcc  
arc                                 defconfig   gcc  
arc                   randconfig-001-20240529   gcc  
arc                   randconfig-002-20240529   gcc  
arm                              allmodconfig   gcc  
arm                               allnoconfig   clang
arm                              allyesconfig   gcc  
arm                        clps711x_defconfig   clang
arm                                 defconfig   clang
arm                            hisi_defconfig   gcc  
arm                             mxs_defconfig   clang
arm                   randconfig-001-20240529   gcc  
arm                   randconfig-002-20240529   gcc  
arm                   randconfig-003-20240529   gcc  
arm                   randconfig-004-20240529   gcc  
arm                           sama7_defconfig   clang
arm64                            allmodconfig   clang
arm64                             allnoconfig   gcc  
arm64                            allyesconfig   clang
arm64                               defconfig   gcc  
arm64                 randconfig-003-20240529   gcc  
arm64                 randconfig-004-20240529   gcc  
csky                             alldefconfig   gcc  
csky                             allmodconfig   gcc  
csky                              allnoconfig   gcc  
csky                             allyesconfig   gcc  
csky                                defconfig   gcc  
csky                  randconfig-001-20240529   gcc  
csky                  randconfig-002-20240529   gcc  
hexagon                          allmodconfig   clang
hexagon                           allnoconfig   clang
hexagon                          allyesconfig   clang
hexagon                             defconfig   clang
i386                             allmodconfig   gcc  
i386                              allnoconfig   gcc  
i386                             allyesconfig   gcc  
i386         buildonly-randconfig-001-20240529   clang
i386         buildonly-randconfig-002-20240529   gcc  
i386         buildonly-randconfig-003-20240529   gcc  
i386         buildonly-randconfig-004-20240529   clang
i386         buildonly-randconfig-005-20240529   gcc  
i386         buildonly-randconfig-006-20240529   clang
i386                                defconfig   clang
i386                  randconfig-001-20240529   clang
i386                  randconfig-002-20240529   gcc  
i386                  randconfig-003-20240529   gcc  
i386                  randconfig-004-20240529   gcc  
i386                  randconfig-005-20240529   clang
i386                  randconfig-006-20240529   clang
i386                  randconfig-011-20240529   clang
i386                  randconfig-012-20240529   clang
i386                  randconfig-013-20240529   clang
i386                  randconfig-014-20240529   gcc  
i386                  randconfig-015-20240529   clang
i386                  randconfig-016-20240529   gcc  
loongarch                        allmodconfig   gcc  
loongarch                         allnoconfig   gcc  
loongarch                           defconfig   gcc  
loongarch             randconfig-001-20240529   gcc  
loongarch             randconfig-002-20240529   gcc  
m68k                             allmodconfig   gcc  
m68k                              allnoconfig   gcc  
m68k                             allyesconfig   gcc  
m68k                                defconfig   gcc  
m68k                        mvme147_defconfig   gcc  
microblaze                       allmodconfig   gcc  
microblaze                        allnoconfig   gcc  
microblaze                       allyesconfig   gcc  
microblaze                          defconfig   gcc  
mips                              allnoconfig   gcc  
mips                             allyesconfig   gcc  
mips                          malta_defconfig   gcc  
nios2                            allmodconfig   gcc  
nios2                             allnoconfig   gcc  
nios2                            allyesconfig   gcc  
nios2                               defconfig   gcc  
nios2                 randconfig-001-20240529   gcc  
nios2                 randconfig-002-20240529   gcc  
openrisc                          allnoconfig   gcc  
openrisc                         allyesconfig   gcc  
openrisc                            defconfig   gcc  
parisc                           allmodconfig   gcc  
parisc                            allnoconfig   gcc  
parisc                           allyesconfig   gcc  
parisc                              defconfig   gcc  
parisc                randconfig-001-20240529   gcc  
parisc                randconfig-002-20240529   gcc  
parisc64                            defconfig   gcc  
powerpc                          allmodconfig   gcc  
powerpc                           allnoconfig   gcc  
powerpc                          allyesconfig   clang
powerpc                      ep88xc_defconfig   gcc  
powerpc                      katmai_defconfig   clang
powerpc                     kmeter1_defconfig   gcc  
powerpc                 linkstation_defconfig   clang
powerpc                       ppc64_defconfig   clang
powerpc64             randconfig-001-20240529   gcc  
riscv                            allmodconfig   clang
riscv                             allnoconfig   gcc  
riscv                            allyesconfig   clang
riscv                               defconfig   clang
riscv                    nommu_k210_defconfig   clang
riscv                 randconfig-001-20240529   gcc  
s390                             allmodconfig   clang
s390                              allnoconfig   clang
s390                             allyesconfig   gcc  
s390                                defconfig   clang
s390                  randconfig-002-20240529   gcc  
sh                               allmodconfig   gcc  
sh                                allnoconfig   gcc  
sh                               allyesconfig   gcc  
sh                         apsh4a3a_defconfig   gcc  
sh                                  defconfig   gcc  
sh                ecovec24-romimage_defconfig   gcc  
sh                          polaris_defconfig   gcc  
sh                    randconfig-001-20240529   gcc  
sh                    randconfig-002-20240529   gcc  
sh                  sh7785lcr_32bit_defconfig   gcc  
sparc                            allmodconfig   gcc  
sparc                             allnoconfig   gcc  
sparc                               defconfig   gcc  
sparc64                          allmodconfig   gcc  
sparc64                          allyesconfig   gcc  
sparc64                             defconfig   gcc  
sparc64               randconfig-001-20240529   gcc  
sparc64               randconfig-002-20240529   gcc  
um                               alldefconfig   clang
um                               allmodconfig   clang
um                                allnoconfig   clang
um                               allyesconfig   gcc  
um                                  defconfig   clang
um                             i386_defconfig   gcc  
um                    randconfig-002-20240529   gcc  
um                           x86_64_defconfig   clang
x86_64                            allnoconfig   clang
x86_64                           allyesconfig   clang
x86_64       buildonly-randconfig-002-20240529   clang
x86_64       buildonly-randconfig-003-20240529   clang
x86_64       buildonly-randconfig-005-20240529   clang
x86_64                              defconfig   gcc  
x86_64                randconfig-002-20240529   clang
x86_64                randconfig-003-20240529   clang
x86_64                randconfig-004-20240529   clang
x86_64                randconfig-013-20240529   clang
x86_64                randconfig-016-20240529   clang
x86_64                randconfig-071-20240529   clang
x86_64                randconfig-074-20240529   clang
x86_64                randconfig-075-20240529   clang
x86_64                randconfig-076-20240529   clang
x86_64                          rhel-8.3-rust   clang
x86_64                               rhel-8.3   gcc  
xtensa                            allnoconfig   gcc  
xtensa                randconfig-001-20240529   gcc  
xtensa                randconfig-002-20240529   gcc  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[relevance 1%]

* Re: [PATCH 2/2] mempool: use rte constant macro instead of GCC builtin
  @ 2024-05-29 11:42  3%     ` Andrew Rybchenko
  0 siblings, 0 replies; 200+ results
From: Andrew Rybchenko @ 2024-05-29 11:42 UTC (permalink / raw)
  To: Morten Brørup, Tyler Retzlaff, dev

On 3/26/24 12:57, Morten Brørup wrote:
>> From: Tyler Retzlaff [mailto:roretzla@linux.microsoft.com]
>> Sent: Wednesday, 20 March 2024 22.34
>>
>> Use newly introduced __rte_constant(e) macro instead of directly using
>> __builtin_constant_p() allowing mempool to be built by MSVC.
>>
>> Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
>> ---
> 
> Reviewed-by: Morten Brørup <mb@smartsharesystems.com>
> 

Reviewed-by: Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>

^ permalink raw reply	[relevance 3%]

* Re: [PATCH 2/2] dts: clean up config types
  @ 2024-05-29 11:41  0%   ` Juraj Linkeš
  0 siblings, 0 replies; 200+ results
From: Juraj Linkeš @ 2024-05-29 11:41 UTC (permalink / raw)
  To: Luca Vizzarro; +Cc: dev, Jeremy Spewock, Paul Szczepanek

On Thu, May 9, 2024 at 12:57 PM Luca Vizzarro <luca.vizzarro@arm.com> wrote:
>
> Clean up types used with the configuration classes, and use Self from
> the newly added typing_extensions module.
>
> Methods that instantiate their own class should be @classmethod instead
> of @staticmethod.
>
> Bugzilla ID: 1433
>
> Signed-off-by: Luca Vizzarro <luca.vizzarro@arm.com>
> Reviewed-by: Paul Szczepanek <paul.szczepanek@arm.com>

Reviewed-by: Juraj Linkeš <juraj.linkes@pantheon.tech>

^ permalink raw reply	[relevance 0%]

* RE: [EXTERNAL] [PATCH v1] crypto: fix build issues on crypto callbacks macro undefined
  @ 2024-05-29 11:40  0%     ` Akhil Goyal
  0 siblings, 0 replies; 200+ results
From: Akhil Goyal @ 2024-05-29 11:40 UTC (permalink / raw)
  To: Kundapura, Ganapati, dev, Ferruh Yigit, thomas, Richardson, Bruce
  Cc: Gujjar, Abhinandan S, ciara.power, fanzhang.oss

> > Subject: RE: [EXTERNAL] [PATCH v1] crypto: fix build issues on crypto callbacks
> > macro undefined
> >
> > > Crypto callbacks macro is defined with value 1 and being used with
> > > ifdef, on config value is changed to 0 to disable, crypto callback
> > > changes still being compiled.
> >
> > I believe we can use #if instead of ifdefs.
> > It seems convenient to enable/disable in my opinion.
> > We can use both, but whatever we use should be same as that for ethdev
> > callbacks.
> >
> Using #if requires check for equality like
> #if RTE_CRYPTO_CALLBACKS == 1 for a macro defined with value 1

No

If it is set as 0, it will be disabled, else for any other value it will be enabled.
No need for check. Right?

> 
> > The same issue would be for ethdev callbacks too.
> > Ferruh, can you check?

^ permalink raw reply	[relevance 0%]

* [PATCH v3 2/3] vfio/pci: Tolerate oversized BARs by disallowing mmap
  2024-05-29 11:36  2% [PATCH v3 0/3] vfio/pci: s390: Fix issues preventing VFIO_PCI_MMAP=y for s390 and enable it Niklas Schnelle
@ 2024-05-29 11:36  1% ` Niklas Schnelle
  0 siblings, 0 replies; 200+ results
From: Niklas Schnelle @ 2024-05-29 11:36 UTC (permalink / raw)
  To: Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
	Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
	Alex Williamson, Gerd Bayer, Matthew Rosato, Jason Gunthorpe
  Cc: linux-s390, linux-kernel, kvm, Niklas Schnelle, Jason Gunthorpe

On s390 there is a virtual PCI device called ISM which has a few rather
annoying oddities. For one it claims to have a 256 TiB PCI BAR (not
a typo) which leads to any attempt to mmap() it failing during vmap.

Even if one tried to map this "BAR" only partially the mapping would not
be usable on systems with MIO support enabled however. This is because
of another oddity in that this virtual PCI device does not support the
newer memory I/O (MIO) PCI instructions and legacy PCI instructions are
not accessible by user-space when MIO is in use. If this device needs to
be accessed by user-space it will thus need a vfio-pci variant driver.
Until then work around both issues by excluding resources which don't
fit between IOREMAP_START and IOREMAP_END in vfio_pci_probe_mmaps().

Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/vfio/pci/vfio_pci_core.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 80cae87fff36..0f1ddf2d3ef2 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -28,6 +28,7 @@
 #include <linux/nospec.h>
 #include <linux/sched/mm.h>
 #include <linux/iommufd.h>
+#include <linux/ioremap.h>
 #if IS_ENABLED(CONFIG_EEH)
 #include <asm/eeh.h>
 #endif
@@ -129,9 +130,12 @@ static void vfio_pci_probe_mmaps(struct vfio_pci_core_device *vdev)
 		/*
 		 * The PCI core shouldn't set up a resource with a
 		 * type but zero size. But there may be bugs that
-		 * cause us to do that.
+		 * cause us to do that. There is also at least one
+		 * device which advertises a resource too large to
+		 * ioremap().
 		 */
-		if (!resource_size(res))
+		if (!resource_size(res) ||
+		    resource_size(res) > (IOREMAP_END + 1 - IOREMAP_START))
 			goto no_mmap;
 
 		if (resource_size(res) >= PAGE_SIZE) {

-- 
2.40.1


^ permalink raw reply related	[relevance 1%]

* [PATCH v3 0/3] vfio/pci: s390: Fix issues preventing VFIO_PCI_MMAP=y for s390 and enable it
@ 2024-05-29 11:36  2% Niklas Schnelle
  2024-05-29 11:36  1% ` [PATCH v3 2/3] vfio/pci: Tolerate oversized BARs by disallowing mmap Niklas Schnelle
  0 siblings, 1 reply; 200+ results
From: Niklas Schnelle @ 2024-05-29 11:36 UTC (permalink / raw)
  To: Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
	Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
	Alex Williamson, Gerd Bayer, Matthew Rosato, Jason Gunthorpe
  Cc: linux-s390, linux-kernel, kvm, Niklas Schnelle, Jason Gunthorpe

With the introduction of memory I/O (MIO) instructions enbaled in commit
71ba41c9b1d9 ("s390/pci: provide support for MIO instructions") s390
gained support for direct user-space access to mapped PCI resources.
Even without those however user-space can access mapped PCI resources
via the s390 specific MMIO syscalls. There is thus nothing fundamentally
preventing s390 from supporting VFIO_PCI_MMAP allowing user-space drivers
to access PCI resources without going through the pread() interface.
To actually enable VFIO_PCI_MMAP a few issues need fixing however.

Firstly the s390 MMIO syscalls do not cause a page fault when
follow_pte() fails due to the page not being present. This breaks
vfio-pci's mmap() handling which lazily maps on first access.

Secondly on s390 there is a virtual PCI device called ISM which has
a few oddities. For one it claims to have a 256 TiB PCI BAR (not a typo)
which leads to any attempt to mmap() it fail with the following message:

    vmap allocation for size 281474976714752 failed: use vmalloc=<size> to increase size

Even if one tried to map this BAR only partially the mapping would not
be usable on systems with MIO support enabled. So just block mapping
BARs which don't fit between IOREMAP_START and IOREMAP_END.

Note:
For your convenience the code is also available in the tagged
b4/vfio_pci_mmap branch on my git.kernel.org site below:
https: //git.kernel.org/pub/scm/linux/kernel/git/niks/linux.git/

Thanks,
Niklas

Link: https://lore.kernel.org/all/c5ba134a1d4f4465b5956027e6a4ea6f6beff969.camel@linux.ibm.com/
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
Changes in v3:
- Rebased on v6.10-rc1 requiring change to follow_pte() call
- Use current->mm for fixup_user_fault() as seems more common
- Collected new trailers
- Link to v2: https://lore.kernel.org/r/20240523-vfio_pci_mmap-v2-0-0dc6c139a4f1@linux.ibm.com

Changes in v2:
- Changed last patch to remove VFIO_PCI_MMAP instead of just enabling it
  for s390 as it is unconditionally true with s390 supporting PCI resource mmap() (Jason)
- Collected R-bs from Jason
- Link to v1: https://lore.kernel.org/r/20240521-vfio_pci_mmap-v1-0-2f6315e0054e@linux.ibm.com

---
Niklas Schnelle (3):
      s390/pci: Fix s390_mmio_read/write syscall page fault handling
      vfio/pci: Tolerate oversized BARs by disallowing mmap
      vfio/pci: Enable PCI resource mmap() on s390 and remove VFIO_PCI_MMAP

 arch/s390/pci/pci_mmio.c         | 18 +++++++++++++-----
 drivers/vfio/pci/Kconfig         |  4 ----
 drivers/vfio/pci/vfio_pci_core.c | 11 ++++++-----
 3 files changed, 19 insertions(+), 14 deletions(-)
---
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
change-id: 20240503-vfio_pci_mmap-1549e3d02ca7

Best regards,
-- 
Niklas Schnelle


^ permalink raw reply	[relevance 2%]

* Re: [PATCH net] net: prevent pulling SKB_GSO_FRAGLIST skb
  @ 2024-05-29 11:35  0%             ` Lena Wang (王娜)
  0 siblings, 0 replies; 200+ results
From: Lena Wang (王娜) @ 2024-05-29 11:35 UTC (permalink / raw)
  To: kuba, willemdebruijn.kernel
  Cc: linux-kernel, netdev, Shiming Cheng (成诗明),
	matthias.bgg, pabeni, edumazet, davem

On Thu, 2024-05-23 at 10:59 -0400, Willem de Bruijn wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  Willem de Bruijn wrote:
> > > The problem now is the ethtool in ubuntu can't support "rx-gro-
> list"
> > > and "rx-udp-gro-forwarding" although it is updated to version 6.7
> from 
> > > https://mirrors.edge.kernel.org/pub/software/network/ethtool. 
> > > 
> > > There is another verison in 
> > > 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net/ethtool
> .
> > >  We download the sourcecode but don't know how to compile for
> ubuntu as
> > > no ./configure there.
> > > 
> > > Is it the one we should use?  If yes, could you please show me
> how to
> > > compile and install this ethtool?
> > 
> > https://git.kernel.org/pub/scm/network/ethtool/ethtool.git is the
> > upstream ethtool repo.
> > 
> > Since you are testing a custom built kernel, there are other hacky
> > ways to configure a feature if you lack a userspace component:
> > 
> > - just hardcode on or off and reboot
> > - use YNL ethtool (but features is not implemented yet?)
> > - write your own netlink helper
> > - abuse some existing kernel API to toggle it, like a rarely uses
> systl
> 
> And as shared off-line, virtme-ng (vng) can be a good option for
> working on tools/testing/selftests too.
> 
> Ideally
> 
> ```
> vng -v -b -f tools/testing/selftests/net
> make headers
> make -C tools/testing/selftests/net
> 
> vng -v -r arch/x86/boot/bzImage --user root
> # inside the VM
> make -C tools/testing/selftests TARGETS=net run_tests
> ```
> 
> Though last time I tried I had to use a slightly more roundabout
> 
> ```
> make defconfig; make kvm_guest.config
> ./scripts/kconfig/merge_config.sh -m .config
> tools/testing/selftests/net/config
> make olddefconfig
> make -j $(nproc) bzImage
> make headers
> make -C tools/testing/selftests/net
> 
> vng -v -r arch/x86/boot/bzImage --user root
> ```
> 
> 
> 
https://lpc.events/event/17/contributions/1506/attachments/1143/2441/virtme-ng.pdf

Dear Willem,
In https://github.com/arighi/virtme-ng it needs kernel 6.5 to setup.
Current our enviroument doesn't support and we prepare to install a PC
with a new ubuntu22.04.

Do you know any request for ubuntu version to run vng, Which version is
more fit for?

Thanks
Lena


^ permalink raw reply	[relevance 0%]

* Re: [yocto] GPL License Compliance - Automatically detect linking against GPL libraries
  @ 2024-05-29 11:34  0%   ` Alexander Kanavin
  2024-05-29 11:58  0%     ` Stephen John Smoogen
  0 siblings, 1 reply; 200+ results
From: Alexander Kanavin @ 2024-05-29 11:34 UTC (permalink / raw)
  To: yocto, smooge; +Cc: fabian.hanke

On Wed, 29 May 2024 at 13:18, Stephen John Smoogen via
lists.yoctoproject.org <smooge=gmail.com@lists.yoctoproject.org>
wrote:
> I wanted to bring up a nuance because you are saying 'GPL based library'. There are several different GPL licenses which need to be evaluated when linking to. The lawyers at Bosch can give the best advice, but this following rule of thumb may be useful:
> Linking to licenses with AGPL -> must be a compatible source license (aka source must be available and modifiable by user) and must meet additional requirements for delivery
> Linking to licenses with GPL -> must be a compatible source license (aka source must be available and modifiable by user)
> Linking to licenses with LGPL -> can be a closed source library in many cases. [again get a lawyer's review]
>
> Then there are the GPL and LGPL with exception licenses. Those exceptions might be something 'slight' so that licenses incompatibilities between the OpenSSL or Apache can be still 'excepted' for use. And then there are the exceptions which basically allow any closed source to link against it. Those need a lawyer's review. There are also differences between version 2 and version 3 of the licenses that again need lawyer's advice.
>
> On many Linux operating systems the libc is based off of glibc which is LGPL2+ with exceptions and GPL2+ with exceptions for various binaries. Other libraries that are in common use may also be. There are also example layer's like the one that Etienne Cordonnier brought up which can help cut down potential conflicts.
>
> And my apologies for bringing up 'lawyers review' so much. Various parts of Bosch have worked in this space for a long time so I figured there was a dedicated counsel who can help guide engineering projects through GPL and other license linking and compliance.
>

The question was how to figure out programmatically what actually
links with gpl pieces without doing a laborious manual review of every
component in the product. And doing it at the yocto integration point
where the problem is introduced, and not after the fact in legal
review where the cost of correcting that mistake is going to be 10x or
100x.

Sounds like this could be a test in package_qa task? I'm not aware of
anything in oe-core that does it, but experiments in that direction
welcome.

Alex


^ permalink raw reply	[relevance 0%]

* Re: [RFC PATCH] arm64: dts: rockchip: Make preparations for per-RK3588-variant OPPs
    2024-05-29 11:33  0%       ` Dragan Simic
@ 2024-05-29 11:33  0%       ` Dragan Simic
  0 siblings, 0 replies; 200+ results
From: Dragan Simic @ 2024-05-29 11:33 UTC (permalink / raw)
  To: Diederik de Haas
  Cc: Alexey Charkov, linux-rockchip, heiko, linux-arm-kernel,
	devicetree, robh+dt, krzk+dt, conor+dt, linux-kernel,
	quentin.schulz, wens, daniel.lezcano, krzysztof.kozlowski+dt,
	viresh.kumar

Hello Diederik,

On 2024-05-29 13:09, Diederik de Haas wrote:
> Hi Dragan,
> 
> I think the idea is very good.
> I do have some remarks about its implementation though.

Thanks for your feedback!

> title: s/Make preparations/Prepare/

Or even better: "Prepare RK3588 SoC dtsi files for per-variant OPPs"

> On Wednesday, 29 May 2024 11:57:45 CEST Alexey Charkov wrote:
>> On Wed, May 29, 2024 at 6:14 AM Dragan Simic <dsimic@manjaro.org> 
>> wrote:
>> > Rename and modify the RK3588 dtsi files a bit, to make preparations for
>> > the ability to specify different CPU and GPU OPPs for each of the
>> > supported RK3588 SoC variants, including the RK3588J.
> 
> "Rename the RK3588 dtsi files in preparation of the ability to specify
> different
> CPU and GPU OPPs combinations for all the supported RK3588 SoC 
> variants."?
> 
> There's no partial renaming of things. That you then also change the 
> include
> files to match, is implied.
> The "modify ... a bit" implies you'll do something else (too), which 
> should be
> in its own separate patch (if that were actually the case).

Oh, the entire description of the patch was cobbled together in a rather
"relaxed" way, because it was past 2 AM over here, :) and because it's 
just
an RFC patch.  For the final version of the patch, if we agree upon 
moving
it forward from the RFC status, I'll prepare a more "formal" description
that will be much more detailed and more accurate.

> If you mention one variant but not (any) others, makes people like me 
> wonder:
> why is RK3588J treated differently then f.e. RK3588M?
> In this case I don't see a reason to single out one variant.

Good remark.  Will be described in the final patch description.

>> > As already discussed, [1][2][3] some of the different RK3588 SoC variants
>> > require different OPPs, and it makes more sense to have the OPPs already
>> > defined when a board dts includes one of the SoC dtsi files (rk3588.dtsi,
>> > rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts file to
>> > also include a separate rk3588*-opp.dtsi file.
>> 
>> Indeed, including just one .dtsi for the correct SoC variant and not
>> having to bother about what other bits and pieces are required to use
>> the full SoC functionality sounds great! Thanks for putting this
>> together so promptly!
> 
> Indeed :)

Thanks. :)

>> > No intended functional changes are introduced.
> 
> ...
> 
>> >  ...inctrl.dtsi => rk3588-common-pinctrl.dtsi} |    0
>> 
>> Renaming the pinctrl includes seems superfluous - maybe keep them as
>> they were to minimize churn?
> 
> The reason for that wasn't clear to me either. If there is a good 
> reason for
> it, then a (git commit) message specify *why* is appreciated.

Another good remark.  Will be addressed in the final patch description.

>> >  .../{rk3588s.dtsi => rk3588-common.dtsi}      |    2 +-
>> >  ...nctrl.dtsi => rk3588-fullfat-pinctrl.dtsi} |    0
>> >  .../{rk3588.dtsi => rk3588-fullfat.dtsi}      |    4 +-
>> 
>> To me, "fullfat" doesn't look super descriptive, albeit fun :)
> 
> Agreed with the non-descriptive part. Please choose a different name.

I'll think about it.  I'm not crazy about "fullfat" either.

> And document in the git commit message why it was renamed and what is 
> expected
> to be in the new dtsi file, but would be incorrect for the old dtsi 
> file.
> 
> That you went from rk3588s.dtsi to rk3588-common.dtsi (I miss the 's') 
> should
> be described (assuming that was intentional and not a typo).

Omitting the "s" wasn't a typo.  It's just that rk3588s.dtsi served as
the base for other .dtsi files before, but it's now called 
rk3588-common.dtsi,
which makes its purpose a bit more self-descriptive, and separates it
from the actual SoC variants (S, J, M), which should also help a bit
with its self-descriptiveness.

Note that "common" is already used in the .dtsi filenames for some other
SoC families, which I actually took inspiration from.

> IOW: let this commit (message) describe what should and should not go 
> in the
> respective dtsi files, which can then be used as reference for future 
> rk3588
> board additions.

Of course.  Again, more material for the final patch description.

>> How about we rename the existing rk3588.dtsi and rk3588s.dtsi to
>> something like rk3588-devices.dtsi and rk3588s-devices.dtsi
> 
> Whether it's '-devices' or '-common', I think it's impossible for a 
> (short)
> name to be fully self-descriptive.
> Thus document what you mean by it in the commit message.

Agreed.  Once again, more material for the final patch description.

> Then we can use those 'rules' to consistently apply them.
> 
>> >  arch/arm64/boot/dts/rockchip/rk3588.dtsi      |  414 +--
>> >  arch/arm64/boot/dts/rockchip/rk3588j.dtsi     |    6 +-
>> >  arch/arm64/boot/dts/rockchip/rk3588s.dtsi     | 2671 +----------------
>> 
>> Rename detection didn't do a particularly great job here - wonder if
>> we can do anything about it to minimize the patch size and ensure that
>> the change history is preserved for git blame...
> 
> +1
> The diff does look awfully big for a rename operation, which was 
> supposed to
> (also only) "modify ... a bit".

I also don't like the size of the patch.  I just tried playing with
specifying different values for the --find-renames and --find-copies
options, but with no good results.  I'll have a look into the Git
source later, to see what's actually going on with those options.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 0%]

* Re: [RFC PATCH] arm64: dts: rockchip: Make preparations for per-RK3588-variant OPPs
@ 2024-05-29 11:33  0%       ` Dragan Simic
  0 siblings, 0 replies; 200+ results
From: Dragan Simic @ 2024-05-29 11:33 UTC (permalink / raw)
  To: Diederik de Haas
  Cc: Alexey Charkov, linux-rockchip, heiko, linux-arm-kernel,
	devicetree, robh+dt, krzk+dt, conor+dt, linux-kernel,
	quentin.schulz, wens, daniel.lezcano, krzysztof.kozlowski+dt,
	viresh.kumar

Hello Diederik,

On 2024-05-29 13:09, Diederik de Haas wrote:
> Hi Dragan,
> 
> I think the idea is very good.
> I do have some remarks about its implementation though.

Thanks for your feedback!

> title: s/Make preparations/Prepare/

Or even better: "Prepare RK3588 SoC dtsi files for per-variant OPPs"

> On Wednesday, 29 May 2024 11:57:45 CEST Alexey Charkov wrote:
>> On Wed, May 29, 2024 at 6:14 AM Dragan Simic <dsimic@manjaro.org> 
>> wrote:
>> > Rename and modify the RK3588 dtsi files a bit, to make preparations for
>> > the ability to specify different CPU and GPU OPPs for each of the
>> > supported RK3588 SoC variants, including the RK3588J.
> 
> "Rename the RK3588 dtsi files in preparation of the ability to specify
> different
> CPU and GPU OPPs combinations for all the supported RK3588 SoC 
> variants."?
> 
> There's no partial renaming of things. That you then also change the 
> include
> files to match, is implied.
> The "modify ... a bit" implies you'll do something else (too), which 
> should be
> in its own separate patch (if that were actually the case).

Oh, the entire description of the patch was cobbled together in a rather
"relaxed" way, because it was past 2 AM over here, :) and because it's 
just
an RFC patch.  For the final version of the patch, if we agree upon 
moving
it forward from the RFC status, I'll prepare a more "formal" description
that will be much more detailed and more accurate.

> If you mention one variant but not (any) others, makes people like me 
> wonder:
> why is RK3588J treated differently then f.e. RK3588M?
> In this case I don't see a reason to single out one variant.

Good remark.  Will be described in the final patch description.

>> > As already discussed, [1][2][3] some of the different RK3588 SoC variants
>> > require different OPPs, and it makes more sense to have the OPPs already
>> > defined when a board dts includes one of the SoC dtsi files (rk3588.dtsi,
>> > rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts file to
>> > also include a separate rk3588*-opp.dtsi file.
>> 
>> Indeed, including just one .dtsi for the correct SoC variant and not
>> having to bother about what other bits and pieces are required to use
>> the full SoC functionality sounds great! Thanks for putting this
>> together so promptly!
> 
> Indeed :)

Thanks. :)

>> > No intended functional changes are introduced.
> 
> ...
> 
>> >  ...inctrl.dtsi => rk3588-common-pinctrl.dtsi} |    0
>> 
>> Renaming the pinctrl includes seems superfluous - maybe keep them as
>> they were to minimize churn?
> 
> The reason for that wasn't clear to me either. If there is a good 
> reason for
> it, then a (git commit) message specify *why* is appreciated.

Another good remark.  Will be addressed in the final patch description.

>> >  .../{rk3588s.dtsi => rk3588-common.dtsi}      |    2 +-
>> >  ...nctrl.dtsi => rk3588-fullfat-pinctrl.dtsi} |    0
>> >  .../{rk3588.dtsi => rk3588-fullfat.dtsi}      |    4 +-
>> 
>> To me, "fullfat" doesn't look super descriptive, albeit fun :)
> 
> Agreed with the non-descriptive part. Please choose a different name.

I'll think about it.  I'm not crazy about "fullfat" either.

> And document in the git commit message why it was renamed and what is 
> expected
> to be in the new dtsi file, but would be incorrect for the old dtsi 
> file.
> 
> That you went from rk3588s.dtsi to rk3588-common.dtsi (I miss the 's') 
> should
> be described (assuming that was intentional and not a typo).

Omitting the "s" wasn't a typo.  It's just that rk3588s.dtsi served as
the base for other .dtsi files before, but it's now called 
rk3588-common.dtsi,
which makes its purpose a bit more self-descriptive, and separates it
from the actual SoC variants (S, J, M), which should also help a bit
with its self-descriptiveness.

Note that "common" is already used in the .dtsi filenames for some other
SoC families, which I actually took inspiration from.

> IOW: let this commit (message) describe what should and should not go 
> in the
> respective dtsi files, which can then be used as reference for future 
> rk3588
> board additions.

Of course.  Again, more material for the final patch description.

>> How about we rename the existing rk3588.dtsi and rk3588s.dtsi to
>> something like rk3588-devices.dtsi and rk3588s-devices.dtsi
> 
> Whether it's '-devices' or '-common', I think it's impossible for a 
> (short)
> name to be fully self-descriptive.
> Thus document what you mean by it in the commit message.

Agreed.  Once again, more material for the final patch description.

> Then we can use those 'rules' to consistently apply them.
> 
>> >  arch/arm64/boot/dts/rockchip/rk3588.dtsi      |  414 +--
>> >  arch/arm64/boot/dts/rockchip/rk3588j.dtsi     |    6 +-
>> >  arch/arm64/boot/dts/rockchip/rk3588s.dtsi     | 2671 +----------------
>> 
>> Rename detection didn't do a particularly great job here - wonder if
>> we can do anything about it to minimize the patch size and ensure that
>> the change history is preserved for git blame...
> 
> +1
> The diff does look awfully big for a rename operation, which was 
> supposed to
> (also only) "modify ... a bit".

I also don't like the size of the patch.  I just tried playing with
specifying different values for the --find-renames and --find-copies
options, but with no good results.  I'll have a look into the Git
source later, to see what's actually going on with those options.

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

^ permalink raw reply	[relevance 0%]

* Re: [RFC PATCH] arm64: dts: rockchip: Make preparations for per-RK3588-variant OPPs
@ 2024-05-29 11:33  0%       ` Dragan Simic
  0 siblings, 0 replies; 200+ results
From: Dragan Simic @ 2024-05-29 11:33 UTC (permalink / raw)
  To: Diederik de Haas
  Cc: Alexey Charkov, linux-rockchip, heiko, linux-arm-kernel,
	devicetree, robh+dt, krzk+dt, conor+dt, linux-kernel,
	quentin.schulz, wens, daniel.lezcano, krzysztof.kozlowski+dt,
	viresh.kumar

Hello Diederik,

On 2024-05-29 13:09, Diederik de Haas wrote:
> Hi Dragan,
> 
> I think the idea is very good.
> I do have some remarks about its implementation though.

Thanks for your feedback!

> title: s/Make preparations/Prepare/

Or even better: "Prepare RK3588 SoC dtsi files for per-variant OPPs"

> On Wednesday, 29 May 2024 11:57:45 CEST Alexey Charkov wrote:
>> On Wed, May 29, 2024 at 6:14 AM Dragan Simic <dsimic@manjaro.org> 
>> wrote:
>> > Rename and modify the RK3588 dtsi files a bit, to make preparations for
>> > the ability to specify different CPU and GPU OPPs for each of the
>> > supported RK3588 SoC variants, including the RK3588J.
> 
> "Rename the RK3588 dtsi files in preparation of the ability to specify
> different
> CPU and GPU OPPs combinations for all the supported RK3588 SoC 
> variants."?
> 
> There's no partial renaming of things. That you then also change the 
> include
> files to match, is implied.
> The "modify ... a bit" implies you'll do something else (too), which 
> should be
> in its own separate patch (if that were actually the case).

Oh, the entire description of the patch was cobbled together in a rather
"relaxed" way, because it was past 2 AM over here, :) and because it's 
just
an RFC patch.  For the final version of the patch, if we agree upon 
moving
it forward from the RFC status, I'll prepare a more "formal" description
that will be much more detailed and more accurate.

> If you mention one variant but not (any) others, makes people like me 
> wonder:
> why is RK3588J treated differently then f.e. RK3588M?
> In this case I don't see a reason to single out one variant.

Good remark.  Will be described in the final patch description.

>> > As already discussed, [1][2][3] some of the different RK3588 SoC variants
>> > require different OPPs, and it makes more sense to have the OPPs already
>> > defined when a board dts includes one of the SoC dtsi files (rk3588.dtsi,
>> > rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts file to
>> > also include a separate rk3588*-opp.dtsi file.
>> 
>> Indeed, including just one .dtsi for the correct SoC variant and not
>> having to bother about what other bits and pieces are required to use
>> the full SoC functionality sounds great! Thanks for putting this
>> together so promptly!
> 
> Indeed :)

Thanks. :)

>> > No intended functional changes are introduced.
> 
> ...
> 
>> >  ...inctrl.dtsi => rk3588-common-pinctrl.dtsi} |    0
>> 
>> Renaming the pinctrl includes seems superfluous - maybe keep them as
>> they were to minimize churn?
> 
> The reason for that wasn't clear to me either. If there is a good 
> reason for
> it, then a (git commit) message specify *why* is appreciated.

Another good remark.  Will be addressed in the final patch description.

>> >  .../{rk3588s.dtsi => rk3588-common.dtsi}      |    2 +-
>> >  ...nctrl.dtsi => rk3588-fullfat-pinctrl.dtsi} |    0
>> >  .../{rk3588.dtsi => rk3588-fullfat.dtsi}      |    4 +-
>> 
>> To me, "fullfat" doesn't look super descriptive, albeit fun :)
> 
> Agreed with the non-descriptive part. Please choose a different name.

I'll think about it.  I'm not crazy about "fullfat" either.

> And document in the git commit message why it was renamed and what is 
> expected
> to be in the new dtsi file, but would be incorrect for the old dtsi 
> file.
> 
> That you went from rk3588s.dtsi to rk3588-common.dtsi (I miss the 's') 
> should
> be described (assuming that was intentional and not a typo).

Omitting the "s" wasn't a typo.  It's just that rk3588s.dtsi served as
the base for other .dtsi files before, but it's now called 
rk3588-common.dtsi,
which makes its purpose a bit more self-descriptive, and separates it
from the actual SoC variants (S, J, M), which should also help a bit
with its self-descriptiveness.

Note that "common" is already used in the .dtsi filenames for some other
SoC families, which I actually took inspiration from.

> IOW: let this commit (message) describe what should and should not go 
> in the
> respective dtsi files, which can then be used as reference for future 
> rk3588
> board additions.

Of course.  Again, more material for the final patch description.

>> How about we rename the existing rk3588.dtsi and rk3588s.dtsi to
>> something like rk3588-devices.dtsi and rk3588s-devices.dtsi
> 
> Whether it's '-devices' or '-common', I think it's impossible for a 
> (short)
> name to be fully self-descriptive.
> Thus document what you mean by it in the commit message.

Agreed.  Once again, more material for the final patch description.

> Then we can use those 'rules' to consistently apply them.
> 
>> >  arch/arm64/boot/dts/rockchip/rk3588.dtsi      |  414 +--
>> >  arch/arm64/boot/dts/rockchip/rk3588j.dtsi     |    6 +-
>> >  arch/arm64/boot/dts/rockchip/rk3588s.dtsi     | 2671 +----------------
>> 
>> Rename detection didn't do a particularly great job here - wonder if
>> we can do anything about it to minimize the patch size and ensure that
>> the change history is preserved for git blame...
> 
> +1
> The diff does look awfully big for a rename operation, which was 
> supposed to
> (also only) "modify ... a bit".

I also don't like the size of the patch.  I just tried playing with
specifying different values for the --find-renames and --find-copies
options, but with no good results.  I'll have a look into the Git
source later, to see what's actually going on with those options.

^ permalink raw reply	[relevance 0%]

* Re: [PATCH v3 00/12] cachefiles: some bugfixes and cleanups for ondemand requests
  @ 2024-05-29 11:23  0%   ` Baokun Li
  0 siblings, 0 replies; 200+ results
From: Baokun Li @ 2024-05-29 11:23 UTC (permalink / raw)
  To: Christian Brauner, netfs, dhowells, jlayton
  Cc: libaokun, yangerkun, linux-kernel, linux-fsdevel, yukuai3, linux-erofs

On 2024/5/29 19:07, Christian Brauner wrote:
> On Wed, 22 May 2024 19:42:56 +0800, libaokun@huaweicloud.com wrote:
>> From: Baokun Li <libaokun1@huawei.com>
>>
>> Hi all!
>>
>> This is the third version of this patch series. The new version has no
>> functional changes compared to the previous one, so I've kept the previous
>> Acked-by and Reviewed-by, so please let me know if you have any objections.
>>
>> [...]
> So I've taken that as a fixes series which should probably make it upstream
> rather sooner than later. Correct?
Yes, I hope this patch set could be upstream soon.
Thank you very much for applying this fixes series!

Regards,
Baokun
> ---
>
> Applied to the vfs.fixes branch of the vfs/vfs.git tree.
> Patches in the vfs.fixes branch should appear in linux-next soon.
>
> Please report any outstanding bugs that were missed during review in a
> new review to the original patch series allowing us to drop it.
>
> It's encouraged to provide Acked-bys and Reviewed-bys even though the
> patch has now been applied. If possible patch trailers will be updated.
>
> Note that commit hashes shown below are subject to change due to rebase,
> trailer updates or similar. If in doubt, please check the listed branch.
>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
> branch: vfs.fixes
>
> [01/12] cachefiles: add output string to cachefiles_obj_[get|put]_ondemand_fd
>          https://git.kernel.org/vfs/vfs/c/cc5ac966f261
> [02/12] cachefiles: remove requests from xarray during flushing requests
>          https://git.kernel.org/vfs/vfs/c/0fc75c5940fa
> [03/12] cachefiles: fix slab-use-after-free in cachefiles_ondemand_get_fd()
>          https://git.kernel.org/vfs/vfs/c/de3e26f9e5b7
> [04/12] cachefiles: fix slab-use-after-free in cachefiles_ondemand_daemon_read()
>          https://git.kernel.org/vfs/vfs/c/da4a82741606
> [05/12] cachefiles: remove err_put_fd label in cachefiles_ondemand_daemon_read()
>          https://git.kernel.org/vfs/vfs/c/3e6d704f02aa
> [06/12] cachefiles: add consistency check for copen/cread
>          https://git.kernel.org/vfs/vfs/c/a26dc49df37e
> [07/12] cachefiles: add spin_lock for cachefiles_ondemand_info
>          https://git.kernel.org/vfs/vfs/c/0a790040838c
> [08/12] cachefiles: never get a new anonymous fd if ondemand_id is valid
>          https://git.kernel.org/vfs/vfs/c/4988e35e95fc
> [09/12] cachefiles: defer exposing anon_fd until after copy_to_user() succeeds
>          https://git.kernel.org/vfs/vfs/c/4b4391e77a6b
> [10/12] cachefiles: Set object to close if ondemand_id < 0 in copen
>          https://git.kernel.org/vfs/vfs/c/4f8703fb3482
> [11/12] cachefiles: flush all requests after setting CACHEFILES_DEAD
>          https://git.kernel.org/vfs/vfs/c/85e833cd7243
> [12/12] cachefiles: make on-demand read killable
>          https://git.kernel.org/vfs/vfs/c/bc9dde615546


^ permalink raw reply	[relevance 0%]

* Re: [PATCHv11 05/19] x86/relocate_kernel: Use named labels for less confusion
  @ 2024-05-29 11:28  3%         ` Borislav Petkov
  0 siblings, 0 replies; 200+ results
From: Borislav Petkov @ 2024-05-29 11:28 UTC (permalink / raw)
  To: Kirill A. Shutemov, Andrew Cooper
  Cc: Nikolay Borisov, Thomas Gleixner, Ingo Molnar, Dave Hansen, x86,
	Rafael J. Wysocki, Peter Zijlstra, Adrian Hunter,
	Kuppuswamy Sathyanarayanan, Elena Reshetova, Jun Nakajima,
	Rick Edgecombe, Tom Lendacky, Kalra, Ashish, Sean Christopherson,
	Huang, Kai, Ard Biesheuvel, Baoquan He, H. Peter Anvin,
	K. Y. Srinivasan, Haiyang Zhang, kexec, linux-hyperv, linux-acpi,
	linux-coco, linux-kernel

On Wed, May 29, 2024 at 02:17:29PM +0300, Kirill A. Shutemov wrote:
> > That jmp 1f becomes redundant now as it simply jumps 1 line below.
> > 
> 
> Nothing changed wrt this jump. It dates back to initial kexec
> implementation.
> 
> See 5234f5eb04ab ("[PATCH] kexec: x86_64 kexec implementation").
> 
> But I don't see functional need in it.
> 
> Anyway, it is outside of the scope of the patch.

Yap, Kirill did what Nikolay should've done - git archeology. Please
don't forget to do that next time.

And back in the day they didn't comment non-obvious things because
commenting is for losers. :-\

So that unconditional forward jump either flushes branch prediction on
some old uarch or something else weird, uarch-special.

I doubt we can remove it just like that.

Lemme add Andy - he should know.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[relevance 3%]

* Re: [PATCHv11 05/19] x86/relocate_kernel: Use named labels for less confusion
@ 2024-05-29 11:28  3%         ` Borislav Petkov
  0 siblings, 0 replies; 200+ results
From: Borislav Petkov @ 2024-05-29 11:28 UTC (permalink / raw)
  To: Kirill A. Shutemov, Andrew Cooper
  Cc: Nikolay Borisov, Thomas Gleixner, Ingo Molnar, Dave Hansen, x86,
	Rafael J. Wysocki, Peter Zijlstra, Adrian Hunter,
	Kuppuswamy Sathyanarayanan, Elena Reshetova, Jun Nakajima,
	Rick Edgecombe, Tom Lendacky, Kalra, Ashish, Sean Christopherson,
	Huang, Kai, Ard Biesheuvel, Baoquan He, H. Peter Anvin,
	K. Y. Srinivasan, Haiyang Zhang, kexec, linux-hyperv, linux-acpi,
	linux-coco, linux-kernel

On Wed, May 29, 2024 at 02:17:29PM +0300, Kirill A. Shutemov wrote:
> > That jmp 1f becomes redundant now as it simply jumps 1 line below.
> > 
> 
> Nothing changed wrt this jump. It dates back to initial kexec
> implementation.
> 
> See 5234f5eb04ab ("[PATCH] kexec: x86_64 kexec implementation").
> 
> But I don't see functional need in it.
> 
> Anyway, it is outside of the scope of the patch.

Yap, Kirill did what Nikolay should've done - git archeology. Please
don't forget to do that next time.

And back in the day they didn't comment non-obvious things because
commenting is for losers. :-\

So that unconditional forward jump either flushes branch prediction on
some old uarch or something else weird, uarch-special.

I doubt we can remove it just like that.

Lemme add Andy - he should know.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[relevance 3%]

* Re: [PATCH] of: property: Fix fw_devlink handling of interrupt-map
    2024-05-29 11:28  0%           ` Anup Patel
@ 2024-05-29 11:28  0%           ` Anup Patel
  0 siblings, 0 replies; 200+ results
From: Anup Patel @ 2024-05-29 11:28 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: devicetree, linux-kernel, linux-arm-kernel, linux-riscv,
	Saravana Kannan, Rob Herring

On Wed, May 29, 2024 at 4:15 PM Marc Zyngier <maz@kernel.org> wrote:
>
> On Wed, 29 May 2024 11:16:30 +0100,
> Anup Patel <apatel@ventanamicro.com> wrote:
> >
> > On Wed, May 29, 2024 at 12:03 PM Marc Zyngier <maz@kernel.org> wrote:
> > >
> > > On Wed, 29 May 2024 06:15:52 +0100,
> > > Anup Patel <apatel@ventanamicro.com> wrote:
> > > >
> > > > On Tue, May 28, 2024 at 10:11 PM Marc Zyngier <maz@kernel.org> wrote:
> > > > >
> > > > > Commit d976c6f4b32c ("of: property: Add fw_devlink support for
> > > > > interrupt-map property") tried to do what it says on the tin,
> > > > > but failed on a couple of points:
> > > > >
> > > > > - it confuses bytes and cells. Not a huge deal, except when it
> > > > >   comes to pointer arithmetic
> > > > >
> > > > > - it doesn't really handle anything but interrupt-maps that have
> > > > >   their parent #address-cells set to 0
> > > > >
> > > > > The combinations of the two leads to some serious fun on my M1
> > > > > box, with plenty of WARN-ON() firing all over the shop, and
> > > > > amusing values being generated for interrupt specifiers.
> > > > >
> > > > > Address both issues so that I can boot my machines again.
> > > > >
> > > > > Fixes: d976c6f4b32c ("of: property: Add fw_devlink support for interrupt-map property")
> > > > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > > > Cc: Anup Patel <apatel@ventanamicro.com>
> > > > > Cc: Saravana Kannan <saravanak@google.com>
> > > > > Cc: Rob Herring (Arm) <robh@kernel.org>
> > > >
> > > > Thanks for the fix patch but unfortunately it breaks for RISC-V.
> > > >
> > > > > ---
> > > > >  drivers/of/property.c | 16 ++++++++++++++--
> > > > >  1 file changed, 14 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > > > > index 1c83e68f805b..9adebc63bea9 100644
> > > > > --- a/drivers/of/property.c
> > > > > +++ b/drivers/of/property.c
> > > > > @@ -1322,7 +1322,13 @@ static struct device_node *parse_interrupt_map(struct device_node *np,
> > > > >         addrcells = of_bus_n_addr_cells(np);
> > > > >
> > > > >         imap = of_get_property(np, "interrupt-map", &imaplen);
> > > > > -       if (!imap || imaplen <= (addrcells + intcells))
> > > > > +       imaplen /= sizeof(*imap);
> > > > > +
> > > > > +       /*
> > > > > +        * Check that we have enough runway for the child unit interrupt
> > > > > +        * specifier and a phandle. That's the bare minimum we can expect.
> > > > > +        */
> > > > > +       if (!imap || imaplen <= (addrcells + intcells + 1))
> > > > >                 return NULL;
> > > > >         imap_end = imap + imaplen;
> > > > >
> > > > > @@ -1346,8 +1352,14 @@ static struct device_node *parse_interrupt_map(struct device_node *np,
> > > > >                 if (!index)
> > > > >                         return sup_args.np;
> > > > >
> > > > > -               of_node_put(sup_args.np);
> > > > > +               /*
> > > > > +                * Account for the full parent unit interrupt specifier
> > > > > +                * (address cells, interrupt cells, and phandle).
> > > > > +                */
> > > > > +               imap += of_bus_n_addr_cells(sup_args.np);
> > > >
> > > > This breaks for RISC-V because we don't have "#address-cells"
> > > > property in interrupt controller DT node and of_bus_n_addr_cells()
> > > > retrieves "#address-cells" from the parent of interrupt controller.
> > >
> > > That's a feature, not a bug. #address-cells, AFAICT, applies to all
> > > child nodes until you set it otherwise.
> > >
> > > >
> > > > The of_irq_parse_raw() looks for "#address-cells" property
> > > > in the interrupt controller DT node only so we should do a
> > > > similar thing here as well.
> > >
> > > This looks more like a of_irq_parse_raw() bug than anything else.
> >
> > If we change of_irq_parse_raw() to use of_bus_n_addr_cells()
> > then it would still break for RISC-V.
>
> I'm not trying to "fix" riscv. I'm merely outlining that you are
> relying on both broken DTs and a buggy OS.
>
> >
> > Using of_bus_n_addr_cells() over here forces interrupt controller
> > DT nodes to have a "#address-cells" DT property. There are many
> > interrupt controller (e.g. RISC-V PLIC or RISC-V APLIC) where the
> > DT bindings don't require "#address-cells" DT property and existing
> > DTS files with such interrupt controllers don't have it either.
>
> It forces you to set #address-cells *if you rely on a different
> value in a child node*. It's not like the semantics are new.

We don't have child nodes under the interrupt controller DT node
(for both RISC-V PLIC and APLIC) so we certainly don't require the
"#address-cells" property in the interrupt controller DT node.

>
> >
> > In the RISC-V world, there have been quite a few QEMU releases
> > where the generated DT node of the interrupt controller does not
> > have the "#address-cells" property. This patch breaks the kernel
> > for all such QEMU releases.
>
> Congratulations, you've forked DT. News at 11.

Can you elaborate how ?

>
> >
> > I think we should align the implementation in parse_interrupt_map()
> > with of_irq_parse_raw() and use of_property_read_u32() instead of
> > of_bus_n_addr_cells().
>
> I think we should fix the kernel and quirk riscv as broken, just like
> PPC or sparc.
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.

Regards,
Anup

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] of: property: Fix fw_devlink handling of interrupt-map
@ 2024-05-29 11:28  0%           ` Anup Patel
  0 siblings, 0 replies; 200+ results
From: Anup Patel @ 2024-05-29 11:28 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: devicetree, linux-kernel, linux-arm-kernel, linux-riscv,
	Saravana Kannan, Rob Herring

On Wed, May 29, 2024 at 4:15 PM Marc Zyngier <maz@kernel.org> wrote:
>
> On Wed, 29 May 2024 11:16:30 +0100,
> Anup Patel <apatel@ventanamicro.com> wrote:
> >
> > On Wed, May 29, 2024 at 12:03 PM Marc Zyngier <maz@kernel.org> wrote:
> > >
> > > On Wed, 29 May 2024 06:15:52 +0100,
> > > Anup Patel <apatel@ventanamicro.com> wrote:
> > > >
> > > > On Tue, May 28, 2024 at 10:11 PM Marc Zyngier <maz@kernel.org> wrote:
> > > > >
> > > > > Commit d976c6f4b32c ("of: property: Add fw_devlink support for
> > > > > interrupt-map property") tried to do what it says on the tin,
> > > > > but failed on a couple of points:
> > > > >
> > > > > - it confuses bytes and cells. Not a huge deal, except when it
> > > > >   comes to pointer arithmetic
> > > > >
> > > > > - it doesn't really handle anything but interrupt-maps that have
> > > > >   their parent #address-cells set to 0
> > > > >
> > > > > The combinations of the two leads to some serious fun on my M1
> > > > > box, with plenty of WARN-ON() firing all over the shop, and
> > > > > amusing values being generated for interrupt specifiers.
> > > > >
> > > > > Address both issues so that I can boot my machines again.
> > > > >
> > > > > Fixes: d976c6f4b32c ("of: property: Add fw_devlink support for interrupt-map property")
> > > > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > > > Cc: Anup Patel <apatel@ventanamicro.com>
> > > > > Cc: Saravana Kannan <saravanak@google.com>
> > > > > Cc: Rob Herring (Arm) <robh@kernel.org>
> > > >
> > > > Thanks for the fix patch but unfortunately it breaks for RISC-V.
> > > >
> > > > > ---
> > > > >  drivers/of/property.c | 16 ++++++++++++++--
> > > > >  1 file changed, 14 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > > > > index 1c83e68f805b..9adebc63bea9 100644
> > > > > --- a/drivers/of/property.c
> > > > > +++ b/drivers/of/property.c
> > > > > @@ -1322,7 +1322,13 @@ static struct device_node *parse_interrupt_map(struct device_node *np,
> > > > >         addrcells = of_bus_n_addr_cells(np);
> > > > >
> > > > >         imap = of_get_property(np, "interrupt-map", &imaplen);
> > > > > -       if (!imap || imaplen <= (addrcells + intcells))
> > > > > +       imaplen /= sizeof(*imap);
> > > > > +
> > > > > +       /*
> > > > > +        * Check that we have enough runway for the child unit interrupt
> > > > > +        * specifier and a phandle. That's the bare minimum we can expect.
> > > > > +        */
> > > > > +       if (!imap || imaplen <= (addrcells + intcells + 1))
> > > > >                 return NULL;
> > > > >         imap_end = imap + imaplen;
> > > > >
> > > > > @@ -1346,8 +1352,14 @@ static struct device_node *parse_interrupt_map(struct device_node *np,
> > > > >                 if (!index)
> > > > >                         return sup_args.np;
> > > > >
> > > > > -               of_node_put(sup_args.np);
> > > > > +               /*
> > > > > +                * Account for the full parent unit interrupt specifier
> > > > > +                * (address cells, interrupt cells, and phandle).
> > > > > +                */
> > > > > +               imap += of_bus_n_addr_cells(sup_args.np);
> > > >
> > > > This breaks for RISC-V because we don't have "#address-cells"
> > > > property in interrupt controller DT node and of_bus_n_addr_cells()
> > > > retrieves "#address-cells" from the parent of interrupt controller.
> > >
> > > That's a feature, not a bug. #address-cells, AFAICT, applies to all
> > > child nodes until you set it otherwise.
> > >
> > > >
> > > > The of_irq_parse_raw() looks for "#address-cells" property
> > > > in the interrupt controller DT node only so we should do a
> > > > similar thing here as well.
> > >
> > > This looks more like a of_irq_parse_raw() bug than anything else.
> >
> > If we change of_irq_parse_raw() to use of_bus_n_addr_cells()
> > then it would still break for RISC-V.
>
> I'm not trying to "fix" riscv. I'm merely outlining that you are
> relying on both broken DTs and a buggy OS.
>
> >
> > Using of_bus_n_addr_cells() over here forces interrupt controller
> > DT nodes to have a "#address-cells" DT property. There are many
> > interrupt controller (e.g. RISC-V PLIC or RISC-V APLIC) where the
> > DT bindings don't require "#address-cells" DT property and existing
> > DTS files with such interrupt controllers don't have it either.
>
> It forces you to set #address-cells *if you rely on a different
> value in a child node*. It's not like the semantics are new.

We don't have child nodes under the interrupt controller DT node
(for both RISC-V PLIC and APLIC) so we certainly don't require the
"#address-cells" property in the interrupt controller DT node.

>
> >
> > In the RISC-V world, there have been quite a few QEMU releases
> > where the generated DT node of the interrupt controller does not
> > have the "#address-cells" property. This patch breaks the kernel
> > for all such QEMU releases.
>
> Congratulations, you've forked DT. News at 11.

Can you elaborate how ?

>
> >
> > I think we should align the implementation in parse_interrupt_map()
> > with of_irq_parse_raw() and use of_property_read_u32() instead of
> > of_bus_n_addr_cells().
>
> I think we should fix the kernel and quirk riscv as broken, just like
> PPC or sparc.
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.

Regards,
Anup

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

^ permalink raw reply	[relevance 0%]

* Re: [PATCH] of: property: Fix fw_devlink handling of interrupt-map
@ 2024-05-29 11:28  0%           ` Anup Patel
  0 siblings, 0 replies; 200+ results
From: Anup Patel @ 2024-05-29 11:28 UTC (permalink / raw)
  To: Marc Zyngier
  Cc: devicetree, linux-kernel, linux-arm-kernel, linux-riscv,
	Saravana Kannan, Rob Herring

On Wed, May 29, 2024 at 4:15 PM Marc Zyngier <maz@kernel.org> wrote:
>
> On Wed, 29 May 2024 11:16:30 +0100,
> Anup Patel <apatel@ventanamicro.com> wrote:
> >
> > On Wed, May 29, 2024 at 12:03 PM Marc Zyngier <maz@kernel.org> wrote:
> > >
> > > On Wed, 29 May 2024 06:15:52 +0100,
> > > Anup Patel <apatel@ventanamicro.com> wrote:
> > > >
> > > > On Tue, May 28, 2024 at 10:11 PM Marc Zyngier <maz@kernel.org> wrote:
> > > > >
> > > > > Commit d976c6f4b32c ("of: property: Add fw_devlink support for
> > > > > interrupt-map property") tried to do what it says on the tin,
> > > > > but failed on a couple of points:
> > > > >
> > > > > - it confuses bytes and cells. Not a huge deal, except when it
> > > > >   comes to pointer arithmetic
> > > > >
> > > > > - it doesn't really handle anything but interrupt-maps that have
> > > > >   their parent #address-cells set to 0
> > > > >
> > > > > The combinations of the two leads to some serious fun on my M1
> > > > > box, with plenty of WARN-ON() firing all over the shop, and
> > > > > amusing values being generated for interrupt specifiers.
> > > > >
> > > > > Address both issues so that I can boot my machines again.
> > > > >
> > > > > Fixes: d976c6f4b32c ("of: property: Add fw_devlink support for interrupt-map property")
> > > > > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > > > > Cc: Anup Patel <apatel@ventanamicro.com>
> > > > > Cc: Saravana Kannan <saravanak@google.com>
> > > > > Cc: Rob Herring (Arm) <robh@kernel.org>
> > > >
> > > > Thanks for the fix patch but unfortunately it breaks for RISC-V.
> > > >
> > > > > ---
> > > > >  drivers/of/property.c | 16 ++++++++++++++--
> > > > >  1 file changed, 14 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/of/property.c b/drivers/of/property.c
> > > > > index 1c83e68f805b..9adebc63bea9 100644
> > > > > --- a/drivers/of/property.c
> > > > > +++ b/drivers/of/property.c
> > > > > @@ -1322,7 +1322,13 @@ static struct device_node *parse_interrupt_map(struct device_node *np,
> > > > >         addrcells = of_bus_n_addr_cells(np);
> > > > >
> > > > >         imap = of_get_property(np, "interrupt-map", &imaplen);
> > > > > -       if (!imap || imaplen <= (addrcells + intcells))
> > > > > +       imaplen /= sizeof(*imap);
> > > > > +
> > > > > +       /*
> > > > > +        * Check that we have enough runway for the child unit interrupt
> > > > > +        * specifier and a phandle. That's the bare minimum we can expect.
> > > > > +        */
> > > > > +       if (!imap || imaplen <= (addrcells + intcells + 1))
> > > > >                 return NULL;
> > > > >         imap_end = imap + imaplen;
> > > > >
> > > > > @@ -1346,8 +1352,14 @@ static struct device_node *parse_interrupt_map(struct device_node *np,
> > > > >                 if (!index)
> > > > >                         return sup_args.np;
> > > > >
> > > > > -               of_node_put(sup_args.np);
> > > > > +               /*
> > > > > +                * Account for the full parent unit interrupt specifier
> > > > > +                * (address cells, interrupt cells, and phandle).
> > > > > +                */
> > > > > +               imap += of_bus_n_addr_cells(sup_args.np);
> > > >
> > > > This breaks for RISC-V because we don't have "#address-cells"
> > > > property in interrupt controller DT node and of_bus_n_addr_cells()
> > > > retrieves "#address-cells" from the parent of interrupt controller.
> > >
> > > That's a feature, not a bug. #address-cells, AFAICT, applies to all
> > > child nodes until you set it otherwise.
> > >
> > > >
> > > > The of_irq_parse_raw() looks for "#address-cells" property
> > > > in the interrupt controller DT node only so we should do a
> > > > similar thing here as well.
> > >
> > > This looks more like a of_irq_parse_raw() bug than anything else.
> >
> > If we change of_irq_parse_raw() to use of_bus_n_addr_cells()
> > then it would still break for RISC-V.
>
> I'm not trying to "fix" riscv. I'm merely outlining that you are
> relying on both broken DTs and a buggy OS.
>
> >
> > Using of_bus_n_addr_cells() over here forces interrupt controller
> > DT nodes to have a "#address-cells" DT property. There are many
> > interrupt controller (e.g. RISC-V PLIC or RISC-V APLIC) where the
> > DT bindings don't require "#address-cells" DT property and existing
> > DTS files with such interrupt controllers don't have it either.
>
> It forces you to set #address-cells *if you rely on a different
> value in a child node*. It's not like the semantics are new.

We don't have child nodes under the interrupt controller DT node
(for both RISC-V PLIC and APLIC) so we certainly don't require the
"#address-cells" property in the interrupt controller DT node.

>
> >
> > In the RISC-V world, there have been quite a few QEMU releases
> > where the generated DT node of the interrupt controller does not
> > have the "#address-cells" property. This patch breaks the kernel
> > for all such QEMU releases.
>
> Congratulations, you've forked DT. News at 11.

Can you elaborate how ?

>
> >
> > I think we should align the implementation in parse_interrupt_map()
> > with of_irq_parse_raw() and use of_property_read_u32() instead of
> > of_bus_n_addr_cells().
>
> I think we should fix the kernel and quirk riscv as broken, just like
> PPC or sparc.
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.

Regards,
Anup

^ permalink raw reply	[relevance 0%]

* Re: [f2fs-dev] [syzbot] [f2fs?] KASAN: slab-use-after-free Read in sanity_check_extent_cache
  @ 2024-05-29 11:26  3%   ` Chao Yu
  0 siblings, 0 replies; 200+ results
From: Chao Yu @ 2024-05-29 11:26 UTC (permalink / raw)
  To: syzbot, jaegeuk, linux-f2fs-devel, linux-fsdevel, linux-kernel,
	syzkaller-bugs

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git wip

On 2024/4/30 2:44, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    e67572cd2204 Linux 6.9-rc6
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=13724f0f180000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=d2f00edef461175
> dashboard link: https://syzkaller.appspot.com/bug?extid=74ebe2104433e9dc610d
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16938440980000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13ae8517180000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/526d150815dd/disk-e67572cd.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/03cba3db92e8/vmlinux-e67572cd.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/ec3f54fc8985/bzImage-e67572cd.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/21aa65da230a/mount_0.gz
> 
> The issue was bisected to:
> 
> commit a53936361330e4c55c0654605178281387d9c761
> Author: Chao Yu <chao@kernel.org>
> Date:   Sun Dec 10 09:20:35 2023 +0000
> 
>      f2fs: delete obsolete FI_FIRST_BLOCK_WRITTEN
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=11b78440980000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=13b78440980000
> console output: https://syzkaller.appspot.com/x/log.txt?x=15b78440980000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+74ebe2104433e9dc610d@syzkaller.appspotmail.com
> Fixes: a53936361330 ("f2fs: delete obsolete FI_FIRST_BLOCK_WRITTEN")
> 
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3b853316dc
> R13: 00007f3b852f8160 R14: 0030656c69662f2e R15: 00007ffdc8faca88
>   </TASK>
> ==================================================================
> BUG: KASAN: slab-use-after-free in sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46
> Read of size 4 at addr ffff8880739ab220 by task syz-executor200/5097
> 
> CPU: 0 PID: 5097 Comm: syz-executor200 Not tainted 6.9.0-rc6-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
> Call Trace:
>   <TASK>
>   __dump_stack lib/dump_stack.c:88 [inline]
>   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
>   print_address_description mm/kasan/report.c:377 [inline]
>   print_report+0x169/0x550 mm/kasan/report.c:488
>   kasan_report+0x143/0x180 mm/kasan/report.c:601
>   sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46
>   do_read_inode fs/f2fs/inode.c:509 [inline]
>   f2fs_iget+0x33e1/0x46e0 fs/f2fs/inode.c:560
>   f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237
>   generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413
>   exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444
>   exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584
>   do_handle_to_path fs/fhandle.c:155 [inline]
>   handle_to_path fs/fhandle.c:210 [inline]
>   do_handle_open+0x495/0x650 fs/fhandle.c:226
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f3b852ab889
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1b 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f3b85239228 EFLAGS: 00000246 ORIG_RAX: 0000000000000130
> RAX: ffffffffffffffda RBX: 00007f3b853316d8 RCX: 00007f3b852ab889
> RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000004
> RBP: 00007f3b853316d0 R08: 00007ffdc8faca87 R09: 00007f3b852396c0
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3b853316dc
> R13: 00007f3b852f8160 R14: 0030656c69662f2e R15: 00007ffdc8faca88
>   </TASK>
> 
> Allocated by task 5092:
>   kasan_save_stack mm/kasan/common.c:47 [inline]
>   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>   unpoison_slab_object mm/kasan/common.c:312 [inline]
>   __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
>   kasan_slab_alloc include/linux/kasan.h:201 [inline]
>   slab_post_alloc_hook mm/slub.c:3798 [inline]
>   slab_alloc_node mm/slub.c:3845 [inline]
>   kmem_cache_alloc+0x174/0x340 mm/slub.c:3852
>   f2fs_kmem_cache_alloc_nofail fs/f2fs/f2fs.h:2817 [inline]
>   f2fs_kmem_cache_alloc fs/f2fs/f2fs.h:2827 [inline]
>   __grab_extent_tree+0x183/0x400 fs/f2fs/extent_cache.c:334
>   f2fs_init_read_extent_tree+0x455/0x910 fs/f2fs/extent_cache.c:405
>   do_read_inode fs/f2fs/inode.c:506 [inline]
>   f2fs_iget+0x33d1/0x46e0 fs/f2fs/inode.c:560
>   f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237
>   generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413
>   exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444
>   exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584
>   do_handle_to_path fs/fhandle.c:155 [inline]
>   handle_to_path fs/fhandle.c:210 [inline]
>   do_handle_open+0x495/0x650 fs/fhandle.c:226
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> Freed by task 5092:
>   kasan_save_stack mm/kasan/common.c:47 [inline]
>   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>   kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
>   poison_slab_object+0xa6/0xe0 mm/kasan/common.c:240
>   __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
>   kasan_slab_free include/linux/kasan.h:184 [inline]
>   slab_free_hook mm/slub.c:2106 [inline]
>   slab_free mm/slub.c:4280 [inline]
>   kmem_cache_free+0x10b/0x2c0 mm/slub.c:4344
>   __destroy_extent_tree+0x307/0x600 fs/f2fs/extent_cache.c:1132
>   f2fs_destroy_extent_tree+0x17/0x30 fs/f2fs/extent_cache.c:1143
>   f2fs_evict_inode+0x44d/0x1550 fs/f2fs/inode.c:831
>   evict+0x2a8/0x630 fs/inode.c:667
>   f2fs_iget+0x1a68/0x46e0 fs/f2fs/inode.c:621
>   f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237
>   generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413
>   exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444
>   exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584
>   do_handle_to_path fs/fhandle.c:155 [inline]
>   handle_to_path fs/fhandle.c:210 [inline]
>   do_handle_open+0x495/0x650 fs/fhandle.c:226
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> The buggy address belongs to the object at ffff8880739ab1a0
>   which belongs to the cache f2fs_extent_tree of size 144
> The buggy address is located 128 bytes inside of
>   freed 144-byte region [ffff8880739ab1a0, ffff8880739ab230)
> 
> The buggy address belongs to the physical page:
> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x739ab
> flags: 0xfff80000000800(slab|node=0|zone=1|lastcpupid=0xfff)
> page_type: 0xffffffff()
> raw: 00fff80000000800 ffff88801afb08c0 dead000000000122 0000000000000000
> raw: 0000000000000000 0000000080130013 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 0, migratetype Reclaimable, gfp_mask 0x12c50(GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_RECLAIMABLE), pid 5076, tgid -326355158 (syz-executor200), ts 5083, free_ts 26740999480
>   set_page_owner include/linux/page_owner.h:32 [inline]
>   post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1534
>   prep_new_page mm/page_alloc.c:1541 [inline]
>   get_page_from_freelist+0x3410/0x35b0 mm/page_alloc.c:3317
>   __alloc_pages+0x256/0x6c0 mm/page_alloc.c:4575
>   __alloc_pages_node include/linux/gfp.h:238 [inline]
>   alloc_pages_node include/linux/gfp.h:261 [inline]
>   alloc_slab_page+0x5f/0x160 mm/slub.c:2175
>   allocate_slab mm/slub.c:2338 [inline]
>   new_slab+0x84/0x2f0 mm/slub.c:2391
>   ___slab_alloc+0xc73/0x1260 mm/slub.c:3525
>   __slab_alloc mm/slub.c:3610 [inline]
>   __slab_alloc_node mm/slub.c:3663 [inline]
>   slab_alloc_node mm/slub.c:3835 [inline]
>   kmem_cache_alloc+0x252/0x340 mm/slub.c:3852
>   f2fs_kmem_cache_alloc_nofail fs/f2fs/f2fs.h:2817 [inline]
>   f2fs_kmem_cache_alloc fs/f2fs/f2fs.h:2827 [inline]
>   __grab_extent_tree+0x183/0x400 fs/f2fs/extent_cache.c:334
>   f2fs_init_read_extent_tree+0x455/0x910 fs/f2fs/extent_cache.c:405
>   do_read_inode fs/f2fs/inode.c:506 [inline]
>   f2fs_iget+0x33d1/0x46e0 fs/f2fs/inode.c:560
>   f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237
>   generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413
>   exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444
>   exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584
>   do_handle_to_path fs/fhandle.c:155 [inline]
>   handle_to_path fs/fhandle.c:210 [inline]
>   do_handle_open+0x495/0x650 fs/fhandle.c:226
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
> page last free pid 1 tgid 1 stack trace:
>   reset_page_owner include/linux/page_owner.h:25 [inline]
>   free_pages_prepare mm/page_alloc.c:1141 [inline]
>   free_unref_page_prepare+0x97b/0xaa0 mm/page_alloc.c:2347
>   free_unref_page+0x37/0x3f0 mm/page_alloc.c:2487
>   free_contig_range+0x9e/0x160 mm/page_alloc.c:6572
>   destroy_args+0x8a/0x890 mm/debug_vm_pgtable.c:1036
>   debug_vm_pgtable+0x4be/0x550 mm/debug_vm_pgtable.c:1416
>   do_one_initcall+0x248/0x880 init/main.c:1245
>   do_initcall_level+0x157/0x210 init/main.c:1307
>   do_initcalls+0x3f/0x80 init/main.c:1323
>   kernel_init_freeable+0x435/0x5d0 init/main.c:1555
>   kernel_init+0x1d/0x2b0 init/main.c:1444
>   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
>   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
> 
> Memory state around the buggy address:
>   ffff8880739ab100: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
>   ffff8880739ab180: fc fc fc fc fa fb fb fb fb fb fb fb fb fb fb fb
>> ffff8880739ab200: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
>                                 ^
>   ffff8880739ab280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>   ffff8880739ab300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
> 
> 
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> 
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
> 
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
> 
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
> 
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
> 
> If you want to undo deduplication, reply with:
> #syz undup
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[relevance 3%]

* Re: [f2fs-dev] [syzbot] [f2fs?] KASAN: slab-use-after-free Read in sanity_check_extent_cache
@ 2024-05-29 11:26  3%   ` Chao Yu
  0 siblings, 0 replies; 200+ results
From: Chao Yu @ 2024-05-29 11:26 UTC (permalink / raw)
  To: syzbot, jaegeuk, linux-f2fs-devel, linux-fsdevel, linux-kernel,
	syzkaller-bugs

#syz test: https://git.kernel.org/pub/scm/linux/kernel/git/chao/linux.git wip

On 2024/4/30 2:44, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    e67572cd2204 Linux 6.9-rc6
> git tree:       upstream
> console+strace: https://syzkaller.appspot.com/x/log.txt?x=13724f0f180000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=d2f00edef461175
> dashboard link: https://syzkaller.appspot.com/bug?extid=74ebe2104433e9dc610d
> compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16938440980000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=13ae8517180000
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/526d150815dd/disk-e67572cd.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/03cba3db92e8/vmlinux-e67572cd.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/ec3f54fc8985/bzImage-e67572cd.xz
> mounted in repro: https://storage.googleapis.com/syzbot-assets/21aa65da230a/mount_0.gz
> 
> The issue was bisected to:
> 
> commit a53936361330e4c55c0654605178281387d9c761
> Author: Chao Yu <chao@kernel.org>
> Date:   Sun Dec 10 09:20:35 2023 +0000
> 
>      f2fs: delete obsolete FI_FIRST_BLOCK_WRITTEN
> 
> bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=11b78440980000
> final oops:     https://syzkaller.appspot.com/x/report.txt?x=13b78440980000
> console output: https://syzkaller.appspot.com/x/log.txt?x=15b78440980000
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+74ebe2104433e9dc610d@syzkaller.appspotmail.com
> Fixes: a53936361330 ("f2fs: delete obsolete FI_FIRST_BLOCK_WRITTEN")
> 
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3b853316dc
> R13: 00007f3b852f8160 R14: 0030656c69662f2e R15: 00007ffdc8faca88
>   </TASK>
> ==================================================================
> BUG: KASAN: slab-use-after-free in sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46
> Read of size 4 at addr ffff8880739ab220 by task syz-executor200/5097
> 
> CPU: 0 PID: 5097 Comm: syz-executor200 Not tainted 6.9.0-rc6-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
> Call Trace:
>   <TASK>
>   __dump_stack lib/dump_stack.c:88 [inline]
>   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
>   print_address_description mm/kasan/report.c:377 [inline]
>   print_report+0x169/0x550 mm/kasan/report.c:488
>   kasan_report+0x143/0x180 mm/kasan/report.c:601
>   sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46
>   do_read_inode fs/f2fs/inode.c:509 [inline]
>   f2fs_iget+0x33e1/0x46e0 fs/f2fs/inode.c:560
>   f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237
>   generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413
>   exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444
>   exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584
>   do_handle_to_path fs/fhandle.c:155 [inline]
>   handle_to_path fs/fhandle.c:210 [inline]
>   do_handle_open+0x495/0x650 fs/fhandle.c:226
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x7f3b852ab889
> Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1b 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48
> RSP: 002b:00007f3b85239228 EFLAGS: 00000246 ORIG_RAX: 0000000000000130
> RAX: ffffffffffffffda RBX: 00007f3b853316d8 RCX: 00007f3b852ab889
> RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000004
> RBP: 00007f3b853316d0 R08: 00007ffdc8faca87 R09: 00007f3b852396c0
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007f3b853316dc
> R13: 00007f3b852f8160 R14: 0030656c69662f2e R15: 00007ffdc8faca88
>   </TASK>
> 
> Allocated by task 5092:
>   kasan_save_stack mm/kasan/common.c:47 [inline]
>   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>   unpoison_slab_object mm/kasan/common.c:312 [inline]
>   __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
>   kasan_slab_alloc include/linux/kasan.h:201 [inline]
>   slab_post_alloc_hook mm/slub.c:3798 [inline]
>   slab_alloc_node mm/slub.c:3845 [inline]
>   kmem_cache_alloc+0x174/0x340 mm/slub.c:3852
>   f2fs_kmem_cache_alloc_nofail fs/f2fs/f2fs.h:2817 [inline]
>   f2fs_kmem_cache_alloc fs/f2fs/f2fs.h:2827 [inline]
>   __grab_extent_tree+0x183/0x400 fs/f2fs/extent_cache.c:334
>   f2fs_init_read_extent_tree+0x455/0x910 fs/f2fs/extent_cache.c:405
>   do_read_inode fs/f2fs/inode.c:506 [inline]
>   f2fs_iget+0x33d1/0x46e0 fs/f2fs/inode.c:560
>   f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237
>   generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413
>   exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444
>   exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584
>   do_handle_to_path fs/fhandle.c:155 [inline]
>   handle_to_path fs/fhandle.c:210 [inline]
>   do_handle_open+0x495/0x650 fs/fhandle.c:226
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> Freed by task 5092:
>   kasan_save_stack mm/kasan/common.c:47 [inline]
>   kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
>   kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
>   poison_slab_object+0xa6/0xe0 mm/kasan/common.c:240
>   __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
>   kasan_slab_free include/linux/kasan.h:184 [inline]
>   slab_free_hook mm/slub.c:2106 [inline]
>   slab_free mm/slub.c:4280 [inline]
>   kmem_cache_free+0x10b/0x2c0 mm/slub.c:4344
>   __destroy_extent_tree+0x307/0x600 fs/f2fs/extent_cache.c:1132
>   f2fs_destroy_extent_tree+0x17/0x30 fs/f2fs/extent_cache.c:1143
>   f2fs_evict_inode+0x44d/0x1550 fs/f2fs/inode.c:831
>   evict+0x2a8/0x630 fs/inode.c:667
>   f2fs_iget+0x1a68/0x46e0 fs/f2fs/inode.c:621
>   f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237
>   generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413
>   exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444
>   exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584
>   do_handle_to_path fs/fhandle.c:155 [inline]
>   handle_to_path fs/fhandle.c:210 [inline]
>   do_handle_open+0x495/0x650 fs/fhandle.c:226
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
> 
> The buggy address belongs to the object at ffff8880739ab1a0
>   which belongs to the cache f2fs_extent_tree of size 144
> The buggy address is located 128 bytes inside of
>   freed 144-byte region [ffff8880739ab1a0, ffff8880739ab230)
> 
> The buggy address belongs to the physical page:
> page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x739ab
> flags: 0xfff80000000800(slab|node=0|zone=1|lastcpupid=0xfff)
> page_type: 0xffffffff()
> raw: 00fff80000000800 ffff88801afb08c0 dead000000000122 0000000000000000
> raw: 0000000000000000 0000000080130013 00000001ffffffff 0000000000000000
> page dumped because: kasan: bad access detected
> page_owner tracks the page as allocated
> page last allocated via order 0, migratetype Reclaimable, gfp_mask 0x12c50(GFP_NOFS|__GFP_NOWARN|__GFP_NORETRY|__GFP_RECLAIMABLE), pid 5076, tgid -326355158 (syz-executor200), ts 5083, free_ts 26740999480
>   set_page_owner include/linux/page_owner.h:32 [inline]
>   post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1534
>   prep_new_page mm/page_alloc.c:1541 [inline]
>   get_page_from_freelist+0x3410/0x35b0 mm/page_alloc.c:3317
>   __alloc_pages+0x256/0x6c0 mm/page_alloc.c:4575
>   __alloc_pages_node include/linux/gfp.h:238 [inline]
>   alloc_pages_node include/linux/gfp.h:261 [inline]
>   alloc_slab_page+0x5f/0x160 mm/slub.c:2175
>   allocate_slab mm/slub.c:2338 [inline]
>   new_slab+0x84/0x2f0 mm/slub.c:2391
>   ___slab_alloc+0xc73/0x1260 mm/slub.c:3525
>   __slab_alloc mm/slub.c:3610 [inline]
>   __slab_alloc_node mm/slub.c:3663 [inline]
>   slab_alloc_node mm/slub.c:3835 [inline]
>   kmem_cache_alloc+0x252/0x340 mm/slub.c:3852
>   f2fs_kmem_cache_alloc_nofail fs/f2fs/f2fs.h:2817 [inline]
>   f2fs_kmem_cache_alloc fs/f2fs/f2fs.h:2827 [inline]
>   __grab_extent_tree+0x183/0x400 fs/f2fs/extent_cache.c:334
>   f2fs_init_read_extent_tree+0x455/0x910 fs/f2fs/extent_cache.c:405
>   do_read_inode fs/f2fs/inode.c:506 [inline]
>   f2fs_iget+0x33d1/0x46e0 fs/f2fs/inode.c:560
>   f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237
>   generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413
>   exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444
>   exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584
>   do_handle_to_path fs/fhandle.c:155 [inline]
>   handle_to_path fs/fhandle.c:210 [inline]
>   do_handle_open+0x495/0x650 fs/fhandle.c:226
>   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
>   do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
> page last free pid 1 tgid 1 stack trace:
>   reset_page_owner include/linux/page_owner.h:25 [inline]
>   free_pages_prepare mm/page_alloc.c:1141 [inline]
>   free_unref_page_prepare+0x97b/0xaa0 mm/page_alloc.c:2347
>   free_unref_page+0x37/0x3f0 mm/page_alloc.c:2487
>   free_contig_range+0x9e/0x160 mm/page_alloc.c:6572
>   destroy_args+0x8a/0x890 mm/debug_vm_pgtable.c:1036
>   debug_vm_pgtable+0x4be/0x550 mm/debug_vm_pgtable.c:1416
>   do_one_initcall+0x248/0x880 init/main.c:1245
>   do_initcall_level+0x157/0x210 init/main.c:1307
>   do_initcalls+0x3f/0x80 init/main.c:1323
>   kernel_init_freeable+0x435/0x5d0 init/main.c:1555
>   kernel_init+0x1d/0x2b0 init/main.c:1444
>   ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
>   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
> 
> Memory state around the buggy address:
>   ffff8880739ab100: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
>   ffff8880739ab180: fc fc fc fc fa fb fb fb fb fb fb fb fb fb fb fb
>> ffff8880739ab200: fb fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc
>                                 ^
>   ffff8880739ab280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>   ffff8880739ab300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
> 
> 
> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
> 
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> 
> If the report is already addressed, let syzbot know by replying with:
> #syz fix: exact-commit-title
> 
> If you want syzbot to run the reproducer, reply with:
> #syz test: git://repo/address.git branch-or-commit-hash
> If you attach or paste a git patch, syzbot will apply it before testing.
> 
> If you want to overwrite report's subsystems, reply with:
> #syz set subsystems: new-subsystem
> (See the list of subsystem names on the web dashboard)
> 
> If the report is a duplicate of another one, reply with:
> #syz dup: exact-subject-of-another-report
> 
> If you want to undo deduplication, reply with:
> #syz undup
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

^ permalink raw reply	[relevance 3%]

* Re: [PATCH 4/5] drm/xe: Rename internal vram helper function
  @ 2024-05-29 11:25  2%       ` Michal Wajdeczko
  2024-05-29 11:50  1%         ` Jani Nikula
  0 siblings, 1 reply; 200+ results
From: Michal Wajdeczko @ 2024-05-29 11:25 UTC (permalink / raw)
  To: Matthew Brost, Matt Roper, Thomas Hellström, Lucas De Marchi
  Cc: intel-xe

++ maintainers

On 29.05.2024 00:15, Matthew Brost wrote:
> On Tue, May 28, 2024 at 02:35:15PM -0700, Matt Roper wrote:
>> On Mon, May 27, 2024 at 07:35:53PM +0200, Michal Wajdeczko wrote:
>>> Drop no longer applicable "xe_mmio_" prefix and downgrade the
>>> existing kernel-doc for internal function to normal comment.
>>
>> As noted on the previous patch, there are several other functions with
>> "xe_" prefixes even though they're static (xe_resize_vram_bar,
>> xe_pci_resource_valid, xe_determine_lmem_bar_size, and the
>> xe_mmio_tile_vram_size you're updating here).  Maybe we should drop the
>> "xe_" prefix from all of them (and "xe_mmio" from this one) before the
>> movement of VRAM code to a new file?

agree on doing all renames for consistency, but this time I just didn't
want to make too many cleanups in one shot, my focus was to do clear
code separation first

>>
> 
> We have talked about this before and I think the consensous was "xe_"
> prefixes for static functions are fine, perhaps even desired. I can't

IMO use of "xe_foo" prefix for static functions is inconsistent (as its
name suggests that it is public function while OTOH it is declared as
static) and may mislead that it could be used in other compilation unit.

thus use of "xe_" (for static) should be rather discouraged but also at
the same time it shouldn't be treated as showstopper (with the hope
better name will be provided later)

> find a reference but I do recall a discussion on the list about this.
> 
> I think the maintainers should make / document a rule wrt to "xe_"
> prefixes before we start making changes in this area as it is not clear.

before we start writing rules for static functions, better to focus only
on rules for public naming convention for the components, like:

files:
	GOOD
		xe_foo.ch
		xe_foo_types.h
		xe_foo_helpers.h
	FINE
		xe_gt_foo.ch
	BAD
		foo.ch

types:
	GOOD
		struct xe_foo_xxx
		enum xe_foo_yyy
		typedef xe_foo_zzz
	BAD
		struct foo
		struct xe_bar

functions:
	GOOD
		xe_foo_bar(struct xe_foo *foo, ...)
	FINE
		xe_foo_bar(struct xe_device *xe, ...)
		xe_gt_foo_bar(struct xe_gt *gt, ...)
	BAD
		xe_foo_bar(..., struct xe_foo *foo)
		xe_bar_foo(struct xe_foo *foo, ...)

> 
> Matt
> 
>>
>> Matt
>>>
>>> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
>>> ---
>>>  drivers/gpu/drm/xe/xe_vram.c | 12 ++++++------
>>>  1 file changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_vram.c b/drivers/gpu/drm/xe/xe_vram.c
>>> index d8b81e4e050c..411e8d23fd4d 100644
>>> --- a/drivers/gpu/drm/xe/xe_vram.c
>>> +++ b/drivers/gpu/drm/xe/xe_vram.c
>>> @@ -192,8 +192,8 @@ static inline u64 get_flat_ccs_offset(struct xe_gt *gt, u64 tile_size)
>>>  	return offset;
>>>  }
>>>  
>>> -/**
>>> - * xe_mmio_tile_vram_size() - Collect vram size and offset information
>>> +/*
>>> + * tile_vram_size() - Collect vram size and offset information
>>>   * @tile: tile to get info for
>>>   * @vram_size: available vram (size - device reserved portions)
>>>   * @tile_size: actual vram size
>>> @@ -211,8 +211,8 @@ static inline u64 get_flat_ccs_offset(struct xe_gt *gt, u64 tile_size)
>>>   * NOTE: multi-tile bases will include the tile offset.
>>>   *
>>>   */
>>> -static int xe_mmio_tile_vram_size(struct xe_tile *tile, u64 *vram_size,
>>> -				  u64 *tile_size, u64 *tile_offset)
>>> +static int tile_vram_size(struct xe_tile *tile, u64 *vram_size,
>>> +			  u64 *tile_size, u64 *tile_offset)
>>>  {
>>>  	struct xe_device *xe = tile_to_xe(tile);
>>>  	struct xe_gt *gt = tile->primary_gt;
>>> @@ -287,7 +287,7 @@ int xe_vram_probe(struct xe_device *xe)
>>>  
>>>  	/* Get the size of the root tile's vram for later accessibility comparison */
>>>  	tile = xe_device_get_root_tile(xe);
>>> -	err = xe_mmio_tile_vram_size(tile, &vram_size, &tile_size, &tile_offset);
>>> +	err = tile_vram_size(tile, &vram_size, &tile_size, &tile_offset);
>>>  	if (err)
>>>  		return err;
>>>  
>>> @@ -302,7 +302,7 @@ int xe_vram_probe(struct xe_device *xe)
>>>  
>>>  	/* tile specific ranges */
>>>  	for_each_tile(tile, xe, id) {
>>> -		err = xe_mmio_tile_vram_size(tile, &vram_size, &tile_size, &tile_offset);
>>> +		err = tile_vram_size(tile, &vram_size, &tile_size, &tile_offset);
>>>  		if (err)
>>>  			return err;
>>>  
>>> -- 
>>> 2.43.0
>>>
>>>
>>
>> -- 
>> Matt Roper
>> Graphics Software Engineer
>> Linux GPU Platform Enablement
>> Intel Corporation

^ permalink raw reply	[relevance 2%]

* Re: [Intel-wired-lan] [PATCH iwl-net v1 1/1] e1000e: Fix S0ix residency on Meteor Lake corporate systems
  @ 2024-05-29 11:23  0%     ` Paul Menzel
  0 siblings, 0 replies; 200+ results
From: Paul Menzel @ 2024-05-29 11:23 UTC (permalink / raw)
  To: Vitaly Lifshits; +Cc: intel-wired-lan, Dima Ruinskiy

Dear Vitaly,


Thank you for your reply.

Am 29.05.24 um 13:13 schrieb Lifshits, Vitaly:

> On 5/28/2024 1:43 PM, Paul Menzel wrote:

>> Am 28.05.24 um 12:33 schrieb Vitaly Lifshits:
>>> From: Dima Ruinskiy <dima.ruinskiy@intel.com>
>>>
>>> On vPro systems,the  configuration of the I219-LM to achieve power
>>
>> s/,the  /, the /
> Thank you for noticing it.
> I will fix it in a v2.
>
>>> gating and S0ix residency is split between the driver and the CSME FW.
>>> It was discovered that in some scenarios, where the network cable is
>>> connected and then disconnected, S0ix residency is not always reached.
>>
>> Disconnected at any point, or just during suspend?
> Yes, at any point.
>
>> Any URL to the reports?
> Yes, https://bugs.launchpad.net/sutton/+bug/2054657

This page does not exist.

     $ curl -I https://bugs.launchpad.net/sutton/+bug/2054657
     HTTP/1.1 404 Not Found
     Date: Wed, 29 May 2024 11:20:52 GMT
     Server: gunicorn
     […]

Please reference the (working) URL in a Link: tag in the footer.

>>> This was root-caused to a subset of I219-LM register writes that are not
>>> performed by the CSME FW. Therefore, the driver should perform these
>>> register writes on corporate setups, regardless of the CSME FW state.
>>
>> Is that documented somewhere?
> Only in an internal documentation.

If you can, it’d be great if you summarized why this is triggered by 
unplugging the network cable.

>> Please add more information about the affected systems, and the test 
>> environment (firmware versions, …).
> It is mentioned at the beginning of the commit, Meteorlake vPro systems.

Please be more specific. If there is a Meteor Lake vPro system, where 
this can *not* be reproduced, it’d be great to know the exact system you 
tested this with. Meteor Lake has been released a long time ago, and not 
remembering a lot of bug reports, I assume, it’s not always reproducible.

(You missed to comment on my previous comments at the end.)

>>> Fixes: cc23f4f0b6b9 ("e1000e: Add support for Meteor Lake")
>>> Signed-off-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
>>> Signed-off-by: Vitaly.Lifshits <vitaly.lifshits@intel.com>
>>
>> The line above with the dot can be removed.
> Will be fixed in a v2.
>>
>>> Signed-off-by: Vitaly Lifshits <vitaly.lifshits@intel.com>
>>> ---
>>>   drivers/net/ethernet/intel/e1000e/netdev.c | 132 ++++++++++-----------
>>>   1 file changed, 66 insertions(+), 66 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c 
>>> b/drivers/net/ethernet/intel/e1000e/netdev.c
>>> index da5c59daf8ba..3cd161c6672b 100644
>>> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
>>> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
>>> @@ -6363,49 +6363,49 @@ static void e1000e_s0ix_entry_flow(struct 
>>> e1000_adapter *adapter)
>>>           mac_data |= E1000_EXTCNF_CTRL_GATE_PHY_CFG;
>>>           ew32(EXTCNF_CTRL, mac_data);
>>> -        /* Enable the Dynamic Power Gating in the MAC */
>>> -        mac_data = er32(FEXTNVM7);
>>> -        mac_data |= BIT(22);
>>> -        ew32(FEXTNVM7, mac_data);
>>> -
>>>           /* Disable disconnected cable conditioning for Power Gating */
>>>           mac_data = er32(DPGFR);
>>>           mac_data |= BIT(2);
>>>           ew32(DPGFR, mac_data);
>>> -        /* Don't wake from dynamic Power Gating with clock request */
>>> -        mac_data = er32(FEXTNVM12);
>>> -        mac_data |= BIT(12);
>>> -        ew32(FEXTNVM12, mac_data);
>>> -
>>> -        /* Ungate PGCB clock */
>>> -        mac_data = er32(FEXTNVM9);
>>> -        mac_data &= ~BIT(28);
>>> -        ew32(FEXTNVM9, mac_data);
>>> -
>>> -        /* Enable K1 off to enable mPHY Power Gating */
>>> -        mac_data = er32(FEXTNVM6);
>>> -        mac_data |= BIT(31);
>>> -        ew32(FEXTNVM6, mac_data);
>>> -
>>> -        /* Enable mPHY power gating for any link and speed */
>>> -        mac_data = er32(FEXTNVM8);
>>> -        mac_data |= BIT(9);
>>> -        ew32(FEXTNVM8, mac_data);
>>> -
>>>           /* Enable the Dynamic Clock Gating in the DMA and MAC */
>>>           mac_data = er32(CTRL_EXT);
>>>           mac_data |= E1000_CTRL_EXT_DMA_DYN_CLK_EN;
>>>           ew32(CTRL_EXT, mac_data);
>>> -
>>> -        /* No MAC DPG gating SLP_S0 in modern standby
>>> -         * Switch the logic of the lanphypc to use PMC counter
>>> -         */
>>> -        mac_data = er32(FEXTNVM5);
>>> -        mac_data |= BIT(7);
>>> -        ew32(FEXTNVM5, mac_data);
>>>       }
>>> +    /* Enable the Dynamic Power Gating in the MAC */
>>> +    mac_data = er32(FEXTNVM7);
>>> +    mac_data |= BIT(22);
>>> +    ew32(FEXTNVM7, mac_data);
>>> +
>>> +    /* Don't wake from dynamic Power Gating with clock request */
>>> +    mac_data = er32(FEXTNVM12);
>>> +    mac_data |= BIT(12);
>>> +    ew32(FEXTNVM12, mac_data);
>>> +
>>> +    /* Ungate PGCB clock */
>>> +    mac_data = er32(FEXTNVM9);
>>> +    mac_data &= ~BIT(28);
>>> +    ew32(FEXTNVM9, mac_data);
>>> +
>>> +    /* Enable K1 off to enable mPHY Power Gating */
>>> +    mac_data = er32(FEXTNVM6);
>>> +    mac_data |= BIT(31);
>>> +    ew32(FEXTNVM6, mac_data);
>>> +
>>> +    /* Enable mPHY power gating for any link and speed */
>>> +    mac_data = er32(FEXTNVM8);
>>> +    mac_data |= BIT(9);
>>> +    ew32(FEXTNVM8, mac_data);
>>> +
>>> +    /* No MAC DPG gating SLP_S0 in modern standby
>>> +     * Switch the logic of the lanphypc to use PMC counter
>>> +     */
>>> +    mac_data = er32(FEXTNVM5);
>>> +    mac_data |= BIT(7);
>>> +    ew32(FEXTNVM5, mac_data);
>>> +
>>>       /* Disable the time synchronization clock */
>>>       mac_data = er32(FEXTNVM7);
>>>       mac_data |= BIT(31);
>>> @@ -6498,33 +6498,6 @@ static void e1000e_s0ix_exit_flow(struct 
>>> e1000_adapter *adapter)
>>>       } else {
>>>           /* Request driver unconfigure the device from S0ix */
>>> -        /* Disable the Dynamic Power Gating in the MAC */
>>> -        mac_data = er32(FEXTNVM7);
>>> -        mac_data &= 0xFFBFFFFF;
>>> -        ew32(FEXTNVM7, mac_data);
>>> -
>>> -        /* Disable mPHY power gating for any link and speed */
>>> -        mac_data = er32(FEXTNVM8);
>>> -        mac_data &= ~BIT(9);
>>> -        ew32(FEXTNVM8, mac_data);
>>> -
>>> -        /* Disable K1 off */
>>> -        mac_data = er32(FEXTNVM6);
>>> -        mac_data &= ~BIT(31);
>>> -        ew32(FEXTNVM6, mac_data);
>>> -
>>> -        /* Disable Ungate PGCB clock */
>>> -        mac_data = er32(FEXTNVM9);
>>> -        mac_data |= BIT(28);
>>> -        ew32(FEXTNVM9, mac_data);
>>> -
>>> -        /* Cancel not waking from dynamic
>>> -         * Power Gating with clock request
>>> -         */
>>> -        mac_data = er32(FEXTNVM12);
>>> -        mac_data &= ~BIT(12);
>>> -        ew32(FEXTNVM12, mac_data);
>>> -
>>>           /* Cancel disable disconnected cable conditioning
>>>            * for Power Gating
>>>            */
>>> @@ -6537,13 +6510,6 @@ static void e1000e_s0ix_exit_flow(struct 
>>> e1000_adapter *adapter)
>>>           mac_data &= 0xFFF7FFFF;
>>>           ew32(CTRL_EXT, mac_data);
>>> -        /* Revert the lanphypc logic to use the internal Gbe counter
>>> -         * and not the PMC counter
>>> -         */
>>> -        mac_data = er32(FEXTNVM5);
>>> -        mac_data &= 0xFFFFFF7F;
>>> -        ew32(FEXTNVM5, mac_data);
>>> -
>>>           /* Enable the periodic inband message,
>>>            * Request PCIe clock in K1 page770_17[10:9] =01b
>>>            */
>>> @@ -6581,6 +6547,40 @@ static void e1000e_s0ix_exit_flow(struct 
>>> e1000_adapter *adapter)
>>>       mac_data &= ~BIT(31);
>>>       mac_data |= BIT(0);
>>>       ew32(FEXTNVM7, mac_data);
>>> +
>>> +    /* Disable the Dynamic Power Gating in the MAC */
>>> +    mac_data = er32(FEXTNVM7);
>>> +    mac_data &= 0xFFBFFFFF;
>>> +    ew32(FEXTNVM7, mac_data);
>>> +
>>> +    /* Disable mPHY power gating for any link and speed */
>>> +    mac_data = er32(FEXTNVM8);
>>> +    mac_data &= ~BIT(9);
>>> +    ew32(FEXTNVM8, mac_data);
>>> +
>>> +    /* Disable K1 off */
>>> +    mac_data = er32(FEXTNVM6);
>>> +    mac_data &= ~BIT(31);
>>> +    ew32(FEXTNVM6, mac_data);
>>> +
>>> +    /* Disable Ungate PGCB clock */
>>> +    mac_data = er32(FEXTNVM9);
>>> +    mac_data |= BIT(28);
>>> +    ew32(FEXTNVM9, mac_data);
>>> +
>>> +    /* Cancel not waking from dynamic
>>> +     * Power Gating with clock request
>>> +     */
>>> +    mac_data = er32(FEXTNVM12);
>>> +    mac_data &= ~BIT(12);
>>> +    ew32(FEXTNVM12, mac_data);
>>> +
>>> +    /* Revert the lanphypc logic to use the internal Gbe counter
>>> +     * and not the PMC counter
>>> +     */
>>> +    mac_data = er32(FEXTNVM5);
>>> +    mac_data &= 0xFFFFFF7F;
>>> +    ew32(FEXTNVM5, mac_data);
>>>   }
>>>   static int e1000e_pm_freeze(struct device *dev)
>>
>> Doesn’t moving this out of the branch and running it unconditionally 
>> affect a lot more systems than Meteor Lake?


Kind regards,

Paul

^ permalink raw reply	[relevance 0%]

* [Intel-wired-lan] [PATCH v2 iwl-net 8/8] ice: xsk: fix txq interrupt mapping
  @ 2024-05-29 11:23  1%   ` Maciej Fijalkowski
  2024-05-29 11:23  1%   ` Maciej Fijalkowski
  2024-05-29 11:23  1%   ` Maciej Fijalkowski
  2 siblings, 0 replies; 200+ results
From: Maciej Fijalkowski @ 2024-05-29 11:23 UTC (permalink / raw)
  To: intel-wired-lan
  Cc: Maciej Fijalkowski, larysa.zaremba, netdev, michal.kubiak,
	anthony.l.nguyen, magnus.karlsson

ice_cfg_txq_interrupt() internally handles XDP Tx ring. Do not use
ice_for_each_tx_ring() in ice_qvec_cfg_msix() as this causing us to
treat XDP ring that belongs to queue vector as Tx ring and therefore
misconfiguring the interrupts.

Fixes: 2d4238f55697 ("ice: Add support for AF_XDP")
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_xsk.c | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_xsk.c b/drivers/net/ethernet/intel/ice/ice_xsk.c
index 693f0e3a37ce..85aa841a16bb 100644
--- a/drivers/net/ethernet/intel/ice/ice_xsk.c
+++ b/drivers/net/ethernet/intel/ice/ice_xsk.c
@@ -111,25 +111,29 @@ ice_qvec_dis_irq(struct ice_vsi *vsi, struct ice_rx_ring *rx_ring,
  * ice_qvec_cfg_msix - Enable IRQ for given queue vector
  * @vsi: the VSI that contains queue vector
  * @q_vector: queue vector
+ * @qid: queue index
  */
 static void
-ice_qvec_cfg_msix(struct ice_vsi *vsi, struct ice_q_vector *q_vector)
+ice_qvec_cfg_msix(struct ice_vsi *vsi, struct ice_q_vector *q_vector, u16 qid)
 {
 	u16 reg_idx = q_vector->reg_idx;
 	struct ice_pf *pf = vsi->back;
 	struct ice_hw *hw = &pf->hw;
-	struct ice_tx_ring *tx_ring;
-	struct ice_rx_ring *rx_ring;
+	int q, _qid = qid;
 
 	ice_cfg_itr(hw, q_vector);
 
-	ice_for_each_tx_ring(tx_ring, q_vector->tx)
-		ice_cfg_txq_interrupt(vsi, tx_ring->reg_idx, reg_idx,
-				      q_vector->tx.itr_idx);
+	for (q = 0; q < q_vector->num_ring_tx; q++) {
+		ice_cfg_txq_interrupt(vsi, _qid, reg_idx, q_vector->tx.itr_idx);
+		_qid++;
+	}
 
-	ice_for_each_rx_ring(rx_ring, q_vector->rx)
-		ice_cfg_rxq_interrupt(vsi, rx_ring->reg_idx, reg_idx,
-				      q_vector->rx.itr_idx);
+	_qid = qid;
+
+	for (q = 0; q < q_vector->num_ring_rx; q++) {
+		ice_cfg_rxq_interrupt(vsi, _qid, reg_idx, q_vector->rx.itr_idx);
+		_qid++;
+	}
 
 	ice_flush(hw);
 }
@@ -241,7 +245,7 @@ static int ice_qp_ena(struct ice_vsi *vsi, u16 q_idx)
 		fail = err;
 
 	q_vector = vsi->rx_rings[q_idx]->q_vector;
-	ice_qvec_cfg_msix(vsi, q_vector);
+	ice_qvec_cfg_msix(vsi, q_vector, q_idx);
 
 	err = ice_vsi_ctrl_one_rx_ring(vsi, true, q_idx, true);
 	if (!fail)
-- 
2.34.1


^ permalink raw reply related	[relevance 1%]

* [Intel-wired-lan] [PATCH v2 iwl-net 7/8] ice: add missing WRITE_ONCE when clearing ice_rx_ring::xdp_prog
  @ 2024-05-29 11:23  1%   ` Maciej Fijalkowski
  2024-05-29 11:23  1%   ` Maciej Fijalkowski
  2024-05-29 11:23  1%   ` Maciej Fijalkowski
  2 siblings, 0 replies; 200+ results
From: Maciej Fijalkowski @ 2024-05-29 11:23 UTC (permalink / raw)
  To: intel-wired-lan
  Cc: Maciej Fijalkowski, larysa.zaremba, netdev, michal.kubiak,
	anthony.l.nguyen, magnus.karlsson

It is read by data path and modified from process context on remote cpu
so it is needed to use WRITE_ONCE to clear the pointer.

Fixes: efc2214b6047 ("ice: Add support for XDP")
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c
index f4b2b1bca234..4c115531beba 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c
@@ -456,7 +456,7 @@ void ice_free_rx_ring(struct ice_rx_ring *rx_ring)
 	if (rx_ring->vsi->type == ICE_VSI_PF)
 		if (xdp_rxq_info_is_reg(&rx_ring->xdp_rxq))
 			xdp_rxq_info_unreg(&rx_ring->xdp_rxq);
-	rx_ring->xdp_prog = NULL;
+	WRITE_ONCE(rx_ring->xdp_prog, NULL);
 	if (rx_ring->xsk_pool) {
 		kfree(rx_ring->xdp_buf);
 		rx_ring->xdp_buf = NULL;
-- 
2.34.1


^ permalink raw reply related	[relevance 1%]

* [Intel-wired-lan] [PATCH v2 iwl-net 6/8] ice: improve updating ice_{t, r}x_ring::xsk_pool
  @ 2024-05-29 11:23  1%   ` Maciej Fijalkowski
  2024-05-29 11:23  1%   ` Maciej Fijalkowski
  2024-05-29 11:23  1%   ` Maciej Fijalkowski
  2 siblings, 0 replies; 200+ results
From: Maciej Fijalkowski @ 2024-05-29 11:23 UTC (permalink / raw)
  To: intel-wired-lan
  Cc: Maciej Fijalkowski, larysa.zaremba, netdev, michal.kubiak,
	anthony.l.nguyen, magnus.karlsson

xsk_buff_pool pointers that ice ring structs hold are updated via
ndo_bpf that is executed in process context while it can be read by
remote CPU at the same time within NAPI poll. Use synchronize_net()
after pointer update and {READ,WRITE}_ONCE() when working with mentioned
pointer.

Fixes: 2d4238f55697 ("ice: Add support for AF_XDP")
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
---
 drivers/net/ethernet/intel/ice/ice.h      |  6 +-
 drivers/net/ethernet/intel/ice/ice_base.c |  4 +-
 drivers/net/ethernet/intel/ice/ice_main.c |  2 +-
 drivers/net/ethernet/intel/ice/ice_txrx.c |  4 +-
 drivers/net/ethernet/intel/ice/ice_xsk.c  | 78 ++++++++++++++---------
 drivers/net/ethernet/intel/ice/ice_xsk.h  |  4 +-
 6 files changed, 59 insertions(+), 39 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
index da8c8afebc93..701a61d791dd 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -771,12 +771,12 @@ static inline struct xsk_buff_pool *ice_get_xp_from_qid(struct ice_vsi *vsi,
  * Returns a pointer to xsk_buff_pool structure if there is a buffer pool
  * present, NULL otherwise.
  */
-static inline struct xsk_buff_pool *ice_xsk_pool(struct ice_rx_ring *ring)
+static inline void ice_xsk_pool(struct ice_rx_ring *ring)
 {
 	struct ice_vsi *vsi = ring->vsi;
 	u16 qid = ring->q_index;
 
-	return ice_get_xp_from_qid(vsi, qid);
+	WRITE_ONCE(ring->xsk_pool, ice_get_xp_from_qid(vsi, qid));
 }
 
 /**
@@ -801,7 +801,7 @@ static inline void ice_tx_xsk_pool(struct ice_vsi *vsi, u16 qid)
 	if (!ring)
 		return;
 
-	ring->xsk_pool = ice_get_xp_from_qid(vsi, qid);
+	WRITE_ONCE(ring->xsk_pool, ice_get_xp_from_qid(vsi, qid));
 }
 
 /**
diff --git a/drivers/net/ethernet/intel/ice/ice_base.c b/drivers/net/ethernet/intel/ice/ice_base.c
index 5d396c1a7731..f3dfce136106 100644
--- a/drivers/net/ethernet/intel/ice/ice_base.c
+++ b/drivers/net/ethernet/intel/ice/ice_base.c
@@ -536,7 +536,7 @@ static int ice_vsi_cfg_rxq(struct ice_rx_ring *ring)
 				return err;
 		}
 
-		ring->xsk_pool = ice_xsk_pool(ring);
+		ice_xsk_pool(ring);
 		if (ring->xsk_pool) {
 			xdp_rxq_info_unreg(&ring->xdp_rxq);
 
@@ -597,7 +597,7 @@ static int ice_vsi_cfg_rxq(struct ice_rx_ring *ring)
 			return 0;
 		}
 
-		ok = ice_alloc_rx_bufs_zc(ring, num_bufs);
+		ok = ice_alloc_rx_bufs_zc(ring, ring->xsk_pool, num_bufs);
 		if (!ok) {
 			u16 pf_q = ring->vsi->rxq_map[ring->q_index];
 
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 1b61ca3a6eb6..15a6805ac2a1 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -2946,7 +2946,7 @@ static void ice_vsi_rx_napi_schedule(struct ice_vsi *vsi)
 	ice_for_each_rxq(vsi, i) {
 		struct ice_rx_ring *rx_ring = vsi->rx_rings[i];
 
-		if (rx_ring->xsk_pool)
+		if (READ_ONCE(rx_ring->xsk_pool))
 			napi_schedule(&rx_ring->q_vector->napi);
 	}
 }
diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c
index 8bb743f78fcb..f4b2b1bca234 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c
@@ -1523,7 +1523,7 @@ int ice_napi_poll(struct napi_struct *napi, int budget)
 	ice_for_each_tx_ring(tx_ring, q_vector->tx) {
 		bool wd;
 
-		if (tx_ring->xsk_pool)
+		if (READ_ONCE(tx_ring->xsk_pool))
 			wd = ice_xmit_zc(tx_ring);
 		else if (ice_ring_is_xdp(tx_ring))
 			wd = true;
@@ -1556,7 +1556,7 @@ int ice_napi_poll(struct napi_struct *napi, int budget)
 		 * comparison in the irq context instead of many inside the
 		 * ice_clean_rx_irq function and makes the codebase cleaner.
 		 */
-		cleaned = rx_ring->xsk_pool ?
+		cleaned = READ_ONCE(rx_ring->xsk_pool) ?
 			  ice_clean_rx_irq_zc(rx_ring, budget_per_ring) :
 			  ice_clean_rx_irq(rx_ring, budget_per_ring);
 		work_done += cleaned;
diff --git a/drivers/net/ethernet/intel/ice/ice_xsk.c b/drivers/net/ethernet/intel/ice/ice_xsk.c
index 8c5006f37310..693f0e3a37ce 100644
--- a/drivers/net/ethernet/intel/ice/ice_xsk.c
+++ b/drivers/net/ethernet/intel/ice/ice_xsk.c
@@ -250,6 +250,8 @@ static int ice_qp_ena(struct ice_vsi *vsi, u16 q_idx)
 	ice_qvec_toggle_napi(vsi, q_vector, true);
 	ice_qvec_ena_irq(vsi, q_vector);
 
+	/* make sure NAPI sees updated ice_{t,x}_ring::xsk_pool */
+	synchronize_net();
 	netif_tx_start_queue(netdev_get_tx_queue(vsi->netdev, q_idx));
 	netif_carrier_on(vsi->netdev);
 	clear_bit(ICE_CFG_BUSY, vsi->state);
@@ -461,6 +463,7 @@ static u16 ice_fill_rx_descs(struct xsk_buff_pool *pool, struct xdp_buff **xdp,
 /**
  * __ice_alloc_rx_bufs_zc - allocate a number of Rx buffers
  * @rx_ring: Rx ring
+ * @xsk_pool: XSK buffer pool to pick buffers to be filled by HW
  * @count: The number of buffers to allocate
  *
  * Place the @count of descriptors onto Rx ring. Handle the ring wrap
@@ -469,7 +472,8 @@ static u16 ice_fill_rx_descs(struct xsk_buff_pool *pool, struct xdp_buff **xdp,
  *
  * Returns true if all allocations were successful, false if any fail.
  */
-static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
+static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring,
+				   struct xsk_buff_pool *xsk_pool, u16 count)
 {
 	u32 nb_buffs_extra = 0, nb_buffs = 0;
 	union ice_32b_rx_flex_desc *rx_desc;
@@ -481,8 +485,7 @@ static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
 	xdp = ice_xdp_buf(rx_ring, ntu);
 
 	if (ntu + count >= rx_ring->count) {
-		nb_buffs_extra = ice_fill_rx_descs(rx_ring->xsk_pool, xdp,
-						   rx_desc,
+		nb_buffs_extra = ice_fill_rx_descs(xsk_pool, xdp, rx_desc,
 						   rx_ring->count - ntu);
 		if (nb_buffs_extra != rx_ring->count - ntu) {
 			ntu += nb_buffs_extra;
@@ -495,7 +498,7 @@ static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
 		ice_release_rx_desc(rx_ring, 0);
 	}
 
-	nb_buffs = ice_fill_rx_descs(rx_ring->xsk_pool, xdp, rx_desc, count);
+	nb_buffs = ice_fill_rx_descs(xsk_pool, xdp, rx_desc, count);
 
 	ntu += nb_buffs;
 	if (ntu == rx_ring->count)
@@ -511,6 +514,7 @@ static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
 /**
  * ice_alloc_rx_bufs_zc - allocate a number of Rx buffers
  * @rx_ring: Rx ring
+ * @xsk_pool: XSK buffer pool to pick buffers to be filled by HW
  * @count: The number of buffers to allocate
  *
  * Wrapper for internal allocation routine; figure out how many tail
@@ -518,7 +522,8 @@ static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
  *
  * Returns true if all calls to internal alloc routine succeeded
  */
-bool ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
+bool ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring,
+			  struct xsk_buff_pool *xsk_pool, u16 count)
 {
 	u16 rx_thresh = ICE_RING_QUARTER(rx_ring);
 	u16 leftover, i, tail_bumps;
@@ -527,9 +532,9 @@ bool ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
 	leftover = count - (tail_bumps * rx_thresh);
 
 	for (i = 0; i < tail_bumps; i++)
-		if (!__ice_alloc_rx_bufs_zc(rx_ring, rx_thresh))
+		if (!__ice_alloc_rx_bufs_zc(rx_ring, xsk_pool, rx_thresh))
 			return false;
-	return __ice_alloc_rx_bufs_zc(rx_ring, leftover);
+	return __ice_alloc_rx_bufs_zc(rx_ring, xsk_pool, leftover);
 }
 
 /**
@@ -650,7 +655,7 @@ static u32 ice_clean_xdp_irq_zc(struct ice_tx_ring *xdp_ring)
 	if (xdp_ring->next_to_clean >= cnt)
 		xdp_ring->next_to_clean -= cnt;
 	if (xsk_frames)
-		xsk_tx_completed(xdp_ring->xsk_pool, xsk_frames);
+		xsk_tx_completed(READ_ONCE(xdp_ring->xsk_pool), xsk_frames);
 
 	return completed_frames;
 }
@@ -702,7 +707,8 @@ static int ice_xmit_xdp_tx_zc(struct xdp_buff *xdp,
 		dma_addr_t dma;
 
 		dma = xsk_buff_xdp_get_dma(xdp);
-		xsk_buff_raw_dma_sync_for_device(xdp_ring->xsk_pool, dma, size);
+		xsk_buff_raw_dma_sync_for_device(READ_ONCE(xdp_ring->xsk_pool),
+						 dma, size);
 
 		tx_buf->xdp = xdp;
 		tx_buf->type = ICE_TX_BUF_XSK_TX;
@@ -760,7 +766,8 @@ ice_run_xdp_zc(struct ice_rx_ring *rx_ring, struct xdp_buff *xdp,
 		err = xdp_do_redirect(rx_ring->netdev, xdp, xdp_prog);
 		if (!err)
 			return ICE_XDP_REDIR;
-		if (xsk_uses_need_wakeup(rx_ring->xsk_pool) && err == -ENOBUFS)
+		if (xsk_uses_need_wakeup(READ_ONCE(rx_ring->xsk_pool)) &&
+		    err == -ENOBUFS)
 			result = ICE_XDP_EXIT;
 		else
 			result = ICE_XDP_CONSUMED;
@@ -829,8 +836,8 @@ ice_add_xsk_frag(struct ice_rx_ring *rx_ring, struct xdp_buff *first,
  */
 int ice_clean_rx_irq_zc(struct ice_rx_ring *rx_ring, int budget)
 {
+	struct xsk_buff_pool *xsk_pool = READ_ONCE(rx_ring->xsk_pool);
 	unsigned int total_rx_bytes = 0, total_rx_packets = 0;
-	struct xsk_buff_pool *xsk_pool = rx_ring->xsk_pool;
 	u32 ntc = rx_ring->next_to_clean;
 	u32 ntu = rx_ring->next_to_use;
 	struct xdp_buff *first = NULL;
@@ -942,7 +949,8 @@ int ice_clean_rx_irq_zc(struct ice_rx_ring *rx_ring, int budget)
 	rx_ring->next_to_clean = ntc;
 	entries_to_alloc = ICE_RX_DESC_UNUSED(rx_ring);
 	if (entries_to_alloc > ICE_RING_QUARTER(rx_ring))
-		failure |= !ice_alloc_rx_bufs_zc(rx_ring, entries_to_alloc);
+		failure |= !ice_alloc_rx_bufs_zc(rx_ring, xsk_pool,
+						 entries_to_alloc);
 
 	ice_finalize_xdp_rx(xdp_ring, xdp_xmit, 0);
 	ice_update_rx_ring_stats(rx_ring, total_rx_packets, total_rx_bytes);
@@ -965,17 +973,19 @@ int ice_clean_rx_irq_zc(struct ice_rx_ring *rx_ring, int budget)
 /**
  * ice_xmit_pkt - produce a single HW Tx descriptor out of AF_XDP descriptor
  * @xdp_ring: XDP ring to produce the HW Tx descriptor on
+ * @xsk_pool: XSK buffer pool to pick buffers to be consumed by HW
  * @desc: AF_XDP descriptor to pull the DMA address and length from
  * @total_bytes: bytes accumulator that will be used for stats update
  */
-static void ice_xmit_pkt(struct ice_tx_ring *xdp_ring, struct xdp_desc *desc,
+static void ice_xmit_pkt(struct ice_tx_ring *xdp_ring,
+			 struct xsk_buff_pool *xsk_pool, struct xdp_desc *desc,
 			 unsigned int *total_bytes)
 {
 	struct ice_tx_desc *tx_desc;
 	dma_addr_t dma;
 
-	dma = xsk_buff_raw_get_dma(xdp_ring->xsk_pool, desc->addr);
-	xsk_buff_raw_dma_sync_for_device(xdp_ring->xsk_pool, dma, desc->len);
+	dma = xsk_buff_raw_get_dma(xsk_pool, desc->addr);
+	xsk_buff_raw_dma_sync_for_device(xsk_pool, dma, desc->len);
 
 	tx_desc = ICE_TX_DESC(xdp_ring, xdp_ring->next_to_use++);
 	tx_desc->buf_addr = cpu_to_le64(dma);
@@ -988,10 +998,13 @@ static void ice_xmit_pkt(struct ice_tx_ring *xdp_ring, struct xdp_desc *desc,
 /**
  * ice_xmit_pkt_batch - produce a batch of HW Tx descriptors out of AF_XDP descriptors
  * @xdp_ring: XDP ring to produce the HW Tx descriptors on
+ * @xsk_pool: XSK buffer pool to pick buffers to be consumed by HW
  * @descs: AF_XDP descriptors to pull the DMA addresses and lengths from
  * @total_bytes: bytes accumulator that will be used for stats update
  */
-static void ice_xmit_pkt_batch(struct ice_tx_ring *xdp_ring, struct xdp_desc *descs,
+static void ice_xmit_pkt_batch(struct ice_tx_ring *xdp_ring,
+			       struct xsk_buff_pool *xsk_pool,
+			       struct xdp_desc *descs,
 			       unsigned int *total_bytes)
 {
 	u16 ntu = xdp_ring->next_to_use;
@@ -1001,8 +1014,8 @@ static void ice_xmit_pkt_batch(struct ice_tx_ring *xdp_ring, struct xdp_desc *de
 	loop_unrolled_for(i = 0; i < PKTS_PER_BATCH; i++) {
 		dma_addr_t dma;
 
-		dma = xsk_buff_raw_get_dma(xdp_ring->xsk_pool, descs[i].addr);
-		xsk_buff_raw_dma_sync_for_device(xdp_ring->xsk_pool, dma, descs[i].len);
+		dma = xsk_buff_raw_get_dma(xsk_pool, descs[i].addr);
+		xsk_buff_raw_dma_sync_for_device(xsk_pool, dma, descs[i].len);
 
 		tx_desc = ICE_TX_DESC(xdp_ring, ntu++);
 		tx_desc->buf_addr = cpu_to_le64(dma);
@@ -1018,21 +1031,24 @@ static void ice_xmit_pkt_batch(struct ice_tx_ring *xdp_ring, struct xdp_desc *de
 /**
  * ice_fill_tx_hw_ring - produce the number of Tx descriptors onto ring
  * @xdp_ring: XDP ring to produce the HW Tx descriptors on
+ * @xsk_pool: XSK buffer pool to pick buffers to be consumed by HW
  * @descs: AF_XDP descriptors to pull the DMA addresses and lengths from
  * @nb_pkts: count of packets to be send
  * @total_bytes: bytes accumulator that will be used for stats update
  */
-static void ice_fill_tx_hw_ring(struct ice_tx_ring *xdp_ring, struct xdp_desc *descs,
-				u32 nb_pkts, unsigned int *total_bytes)
+static void ice_fill_tx_hw_ring(struct ice_tx_ring *xdp_ring,
+				struct xsk_buff_pool *xsk_pool,
+				struct xdp_desc *descs, u32 nb_pkts,
+				unsigned int *total_bytes)
 {
 	u32 batched, leftover, i;
 
 	batched = ALIGN_DOWN(nb_pkts, PKTS_PER_BATCH);
 	leftover = nb_pkts & (PKTS_PER_BATCH - 1);
 	for (i = 0; i < batched; i += PKTS_PER_BATCH)
-		ice_xmit_pkt_batch(xdp_ring, &descs[i], total_bytes);
+		ice_xmit_pkt_batch(xdp_ring, xsk_pool, &descs[i], total_bytes);
 	for (; i < batched + leftover; i++)
-		ice_xmit_pkt(xdp_ring, &descs[i], total_bytes);
+		ice_xmit_pkt(xdp_ring, xsk_pool, &descs[i], total_bytes);
 }
 
 /**
@@ -1043,7 +1059,8 @@ static void ice_fill_tx_hw_ring(struct ice_tx_ring *xdp_ring, struct xdp_desc *d
  */
 bool ice_xmit_zc(struct ice_tx_ring *xdp_ring)
 {
-	struct xdp_desc *descs = xdp_ring->xsk_pool->tx_descs;
+	struct xsk_buff_pool *xsk_pool = READ_ONCE(xdp_ring->xsk_pool);
+	struct xdp_desc *descs = xsk_pool->tx_descs;
 	u32 nb_pkts, nb_processed = 0;
 	unsigned int total_bytes = 0;
 	int budget;
@@ -1057,25 +1074,26 @@ bool ice_xmit_zc(struct ice_tx_ring *xdp_ring)
 	budget = ICE_DESC_UNUSED(xdp_ring);
 	budget = min_t(u16, budget, ICE_RING_QUARTER(xdp_ring));
 
-	nb_pkts = xsk_tx_peek_release_desc_batch(xdp_ring->xsk_pool, budget);
+	nb_pkts = xsk_tx_peek_release_desc_batch(xsk_pool, budget);
 	if (!nb_pkts)
 		return true;
 
 	if (xdp_ring->next_to_use + nb_pkts >= xdp_ring->count) {
 		nb_processed = xdp_ring->count - xdp_ring->next_to_use;
-		ice_fill_tx_hw_ring(xdp_ring, descs, nb_processed, &total_bytes);
+		ice_fill_tx_hw_ring(xdp_ring, xsk_pool, descs, nb_processed,
+				    &total_bytes);
 		xdp_ring->next_to_use = 0;
 	}
 
-	ice_fill_tx_hw_ring(xdp_ring, &descs[nb_processed], nb_pkts - nb_processed,
-			    &total_bytes);
+	ice_fill_tx_hw_ring(xdp_ring, xsk_pool, &descs[nb_processed],
+			    nb_pkts - nb_processed, &total_bytes);
 
 	ice_set_rs_bit(xdp_ring);
 	ice_xdp_ring_update_tail(xdp_ring);
 	ice_update_tx_ring_stats(xdp_ring, nb_pkts, total_bytes);
 
-	if (xsk_uses_need_wakeup(xdp_ring->xsk_pool))
-		xsk_set_tx_need_wakeup(xdp_ring->xsk_pool);
+	if (xsk_uses_need_wakeup(xsk_pool))
+		xsk_set_tx_need_wakeup(xsk_pool);
 
 	return nb_pkts < budget;
 }
@@ -1108,7 +1126,7 @@ ice_xsk_wakeup(struct net_device *netdev, u32 queue_id,
 
 	ring = vsi->rx_rings[queue_id]->xdp_ring;
 
-	if (!ring->xsk_pool)
+	if (!READ_ONCE(ring->xsk_pool))
 		return -EINVAL;
 
 	/* The idea here is that if NAPI is running, mark a miss, so
diff --git a/drivers/net/ethernet/intel/ice/ice_xsk.h b/drivers/net/ethernet/intel/ice/ice_xsk.h
index 6fa181f080ef..4cd2d62a0836 100644
--- a/drivers/net/ethernet/intel/ice/ice_xsk.h
+++ b/drivers/net/ethernet/intel/ice/ice_xsk.h
@@ -22,7 +22,8 @@ int ice_xsk_pool_setup(struct ice_vsi *vsi, struct xsk_buff_pool *pool,
 		       u16 qid);
 int ice_clean_rx_irq_zc(struct ice_rx_ring *rx_ring, int budget);
 int ice_xsk_wakeup(struct net_device *netdev, u32 queue_id, u32 flags);
-bool ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count);
+bool ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring,
+			  struct xsk_buff_pool *xsk_pool, u16 count);
 bool ice_xsk_any_rx_ring_ena(struct ice_vsi *vsi);
 void ice_xsk_clean_rx_ring(struct ice_rx_ring *rx_ring);
 void ice_xsk_clean_xdp_ring(struct ice_tx_ring *xdp_ring);
@@ -51,6 +52,7 @@ ice_clean_rx_irq_zc(struct ice_rx_ring __always_unused *rx_ring,
 
 static inline bool
 ice_alloc_rx_bufs_zc(struct ice_rx_ring __always_unused *rx_ring,
+		     struct xsk_buff_pool __always_unused *xsk_pool,
 		     u16 __always_unused count)
 {
 	return false;
-- 
2.34.1


^ permalink raw reply related	[relevance 1%]

* [PATCH v2 iwl-net 8/8] ice: xsk: fix txq interrupt mapping
@ 2024-05-29 11:23  1%   ` Maciej Fijalkowski
  0 siblings, 0 replies; 200+ results
From: Maciej Fijalkowski @ 2024-05-29 11:23 UTC (permalink / raw)
  To: intel-wired-lan
  Cc: netdev, anthony.l.nguyen, magnus.karlsson, michal.kubiak,
	larysa.zaremba, Maciej Fijalkowski

ice_cfg_txq_interrupt() internally handles XDP Tx ring. Do not use
ice_for_each_tx_ring() in ice_qvec_cfg_msix() as this causing us to
treat XDP ring that belongs to queue vector as Tx ring and therefore
misconfiguring the interrupts.

Fixes: 2d4238f55697 ("ice: Add support for AF_XDP")
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_xsk.c | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_xsk.c b/drivers/net/ethernet/intel/ice/ice_xsk.c
index 693f0e3a37ce..85aa841a16bb 100644
--- a/drivers/net/ethernet/intel/ice/ice_xsk.c
+++ b/drivers/net/ethernet/intel/ice/ice_xsk.c
@@ -111,25 +111,29 @@ ice_qvec_dis_irq(struct ice_vsi *vsi, struct ice_rx_ring *rx_ring,
  * ice_qvec_cfg_msix - Enable IRQ for given queue vector
  * @vsi: the VSI that contains queue vector
  * @q_vector: queue vector
+ * @qid: queue index
  */
 static void
-ice_qvec_cfg_msix(struct ice_vsi *vsi, struct ice_q_vector *q_vector)
+ice_qvec_cfg_msix(struct ice_vsi *vsi, struct ice_q_vector *q_vector, u16 qid)
 {
 	u16 reg_idx = q_vector->reg_idx;
 	struct ice_pf *pf = vsi->back;
 	struct ice_hw *hw = &pf->hw;
-	struct ice_tx_ring *tx_ring;
-	struct ice_rx_ring *rx_ring;
+	int q, _qid = qid;
 
 	ice_cfg_itr(hw, q_vector);
 
-	ice_for_each_tx_ring(tx_ring, q_vector->tx)
-		ice_cfg_txq_interrupt(vsi, tx_ring->reg_idx, reg_idx,
-				      q_vector->tx.itr_idx);
+	for (q = 0; q < q_vector->num_ring_tx; q++) {
+		ice_cfg_txq_interrupt(vsi, _qid, reg_idx, q_vector->tx.itr_idx);
+		_qid++;
+	}
 
-	ice_for_each_rx_ring(rx_ring, q_vector->rx)
-		ice_cfg_rxq_interrupt(vsi, rx_ring->reg_idx, reg_idx,
-				      q_vector->rx.itr_idx);
+	_qid = qid;
+
+	for (q = 0; q < q_vector->num_ring_rx; q++) {
+		ice_cfg_rxq_interrupt(vsi, _qid, reg_idx, q_vector->rx.itr_idx);
+		_qid++;
+	}
 
 	ice_flush(hw);
 }
@@ -241,7 +245,7 @@ static int ice_qp_ena(struct ice_vsi *vsi, u16 q_idx)
 		fail = err;
 
 	q_vector = vsi->rx_rings[q_idx]->q_vector;
-	ice_qvec_cfg_msix(vsi, q_vector);
+	ice_qvec_cfg_msix(vsi, q_vector, q_idx);
 
 	err = ice_vsi_ctrl_one_rx_ring(vsi, true, q_idx, true);
 	if (!fail)
-- 
2.34.1


^ permalink raw reply related	[relevance 1%]

* [PATCH v2 iwl-net 7/8] ice: add missing WRITE_ONCE when clearing ice_rx_ring::xdp_prog
@ 2024-05-29 11:23  1%   ` Maciej Fijalkowski
  0 siblings, 0 replies; 200+ results
From: Maciej Fijalkowski @ 2024-05-29 11:23 UTC (permalink / raw)
  To: intel-wired-lan
  Cc: netdev, anthony.l.nguyen, magnus.karlsson, michal.kubiak,
	larysa.zaremba, Maciej Fijalkowski

It is read by data path and modified from process context on remote cpu
so it is needed to use WRITE_ONCE to clear the pointer.

Fixes: efc2214b6047 ("ice: Add support for XDP")
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
---
 drivers/net/ethernet/intel/ice/ice_txrx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c
index f4b2b1bca234..4c115531beba 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c
@@ -456,7 +456,7 @@ void ice_free_rx_ring(struct ice_rx_ring *rx_ring)
 	if (rx_ring->vsi->type == ICE_VSI_PF)
 		if (xdp_rxq_info_is_reg(&rx_ring->xdp_rxq))
 			xdp_rxq_info_unreg(&rx_ring->xdp_rxq);
-	rx_ring->xdp_prog = NULL;
+	WRITE_ONCE(rx_ring->xdp_prog, NULL);
 	if (rx_ring->xsk_pool) {
 		kfree(rx_ring->xdp_buf);
 		rx_ring->xdp_buf = NULL;
-- 
2.34.1


^ permalink raw reply related	[relevance 1%]

* [PATCH v2 iwl-net 6/8] ice: improve updating ice_{t,r}x_ring::xsk_pool
@ 2024-05-29 11:23  1%   ` Maciej Fijalkowski
  0 siblings, 0 replies; 200+ results
From: Maciej Fijalkowski @ 2024-05-29 11:23 UTC (permalink / raw)
  To: intel-wired-lan
  Cc: netdev, anthony.l.nguyen, magnus.karlsson, michal.kubiak,
	larysa.zaremba, Maciej Fijalkowski

xsk_buff_pool pointers that ice ring structs hold are updated via
ndo_bpf that is executed in process context while it can be read by
remote CPU at the same time within NAPI poll. Use synchronize_net()
after pointer update and {READ,WRITE}_ONCE() when working with mentioned
pointer.

Fixes: 2d4238f55697 ("ice: Add support for AF_XDP")
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
---
 drivers/net/ethernet/intel/ice/ice.h      |  6 +-
 drivers/net/ethernet/intel/ice/ice_base.c |  4 +-
 drivers/net/ethernet/intel/ice/ice_main.c |  2 +-
 drivers/net/ethernet/intel/ice/ice_txrx.c |  4 +-
 drivers/net/ethernet/intel/ice/ice_xsk.c  | 78 ++++++++++++++---------
 drivers/net/ethernet/intel/ice/ice_xsk.h  |  4 +-
 6 files changed, 59 insertions(+), 39 deletions(-)

diff --git a/drivers/net/ethernet/intel/ice/ice.h b/drivers/net/ethernet/intel/ice/ice.h
index da8c8afebc93..701a61d791dd 100644
--- a/drivers/net/ethernet/intel/ice/ice.h
+++ b/drivers/net/ethernet/intel/ice/ice.h
@@ -771,12 +771,12 @@ static inline struct xsk_buff_pool *ice_get_xp_from_qid(struct ice_vsi *vsi,
  * Returns a pointer to xsk_buff_pool structure if there is a buffer pool
  * present, NULL otherwise.
  */
-static inline struct xsk_buff_pool *ice_xsk_pool(struct ice_rx_ring *ring)
+static inline void ice_xsk_pool(struct ice_rx_ring *ring)
 {
 	struct ice_vsi *vsi = ring->vsi;
 	u16 qid = ring->q_index;
 
-	return ice_get_xp_from_qid(vsi, qid);
+	WRITE_ONCE(ring->xsk_pool, ice_get_xp_from_qid(vsi, qid));
 }
 
 /**
@@ -801,7 +801,7 @@ static inline void ice_tx_xsk_pool(struct ice_vsi *vsi, u16 qid)
 	if (!ring)
 		return;
 
-	ring->xsk_pool = ice_get_xp_from_qid(vsi, qid);
+	WRITE_ONCE(ring->xsk_pool, ice_get_xp_from_qid(vsi, qid));
 }
 
 /**
diff --git a/drivers/net/ethernet/intel/ice/ice_base.c b/drivers/net/ethernet/intel/ice/ice_base.c
index 5d396c1a7731..f3dfce136106 100644
--- a/drivers/net/ethernet/intel/ice/ice_base.c
+++ b/drivers/net/ethernet/intel/ice/ice_base.c
@@ -536,7 +536,7 @@ static int ice_vsi_cfg_rxq(struct ice_rx_ring *ring)
 				return err;
 		}
 
-		ring->xsk_pool = ice_xsk_pool(ring);
+		ice_xsk_pool(ring);
 		if (ring->xsk_pool) {
 			xdp_rxq_info_unreg(&ring->xdp_rxq);
 
@@ -597,7 +597,7 @@ static int ice_vsi_cfg_rxq(struct ice_rx_ring *ring)
 			return 0;
 		}
 
-		ok = ice_alloc_rx_bufs_zc(ring, num_bufs);
+		ok = ice_alloc_rx_bufs_zc(ring, ring->xsk_pool, num_bufs);
 		if (!ok) {
 			u16 pf_q = ring->vsi->rxq_map[ring->q_index];
 
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
index 1b61ca3a6eb6..15a6805ac2a1 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -2946,7 +2946,7 @@ static void ice_vsi_rx_napi_schedule(struct ice_vsi *vsi)
 	ice_for_each_rxq(vsi, i) {
 		struct ice_rx_ring *rx_ring = vsi->rx_rings[i];
 
-		if (rx_ring->xsk_pool)
+		if (READ_ONCE(rx_ring->xsk_pool))
 			napi_schedule(&rx_ring->q_vector->napi);
 	}
 }
diff --git a/drivers/net/ethernet/intel/ice/ice_txrx.c b/drivers/net/ethernet/intel/ice/ice_txrx.c
index 8bb743f78fcb..f4b2b1bca234 100644
--- a/drivers/net/ethernet/intel/ice/ice_txrx.c
+++ b/drivers/net/ethernet/intel/ice/ice_txrx.c
@@ -1523,7 +1523,7 @@ int ice_napi_poll(struct napi_struct *napi, int budget)
 	ice_for_each_tx_ring(tx_ring, q_vector->tx) {
 		bool wd;
 
-		if (tx_ring->xsk_pool)
+		if (READ_ONCE(tx_ring->xsk_pool))
 			wd = ice_xmit_zc(tx_ring);
 		else if (ice_ring_is_xdp(tx_ring))
 			wd = true;
@@ -1556,7 +1556,7 @@ int ice_napi_poll(struct napi_struct *napi, int budget)
 		 * comparison in the irq context instead of many inside the
 		 * ice_clean_rx_irq function and makes the codebase cleaner.
 		 */
-		cleaned = rx_ring->xsk_pool ?
+		cleaned = READ_ONCE(rx_ring->xsk_pool) ?
 			  ice_clean_rx_irq_zc(rx_ring, budget_per_ring) :
 			  ice_clean_rx_irq(rx_ring, budget_per_ring);
 		work_done += cleaned;
diff --git a/drivers/net/ethernet/intel/ice/ice_xsk.c b/drivers/net/ethernet/intel/ice/ice_xsk.c
index 8c5006f37310..693f0e3a37ce 100644
--- a/drivers/net/ethernet/intel/ice/ice_xsk.c
+++ b/drivers/net/ethernet/intel/ice/ice_xsk.c
@@ -250,6 +250,8 @@ static int ice_qp_ena(struct ice_vsi *vsi, u16 q_idx)
 	ice_qvec_toggle_napi(vsi, q_vector, true);
 	ice_qvec_ena_irq(vsi, q_vector);
 
+	/* make sure NAPI sees updated ice_{t,x}_ring::xsk_pool */
+	synchronize_net();
 	netif_tx_start_queue(netdev_get_tx_queue(vsi->netdev, q_idx));
 	netif_carrier_on(vsi->netdev);
 	clear_bit(ICE_CFG_BUSY, vsi->state);
@@ -461,6 +463,7 @@ static u16 ice_fill_rx_descs(struct xsk_buff_pool *pool, struct xdp_buff **xdp,
 /**
  * __ice_alloc_rx_bufs_zc - allocate a number of Rx buffers
  * @rx_ring: Rx ring
+ * @xsk_pool: XSK buffer pool to pick buffers to be filled by HW
  * @count: The number of buffers to allocate
  *
  * Place the @count of descriptors onto Rx ring. Handle the ring wrap
@@ -469,7 +472,8 @@ static u16 ice_fill_rx_descs(struct xsk_buff_pool *pool, struct xdp_buff **xdp,
  *
  * Returns true if all allocations were successful, false if any fail.
  */
-static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
+static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring,
+				   struct xsk_buff_pool *xsk_pool, u16 count)
 {
 	u32 nb_buffs_extra = 0, nb_buffs = 0;
 	union ice_32b_rx_flex_desc *rx_desc;
@@ -481,8 +485,7 @@ static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
 	xdp = ice_xdp_buf(rx_ring, ntu);
 
 	if (ntu + count >= rx_ring->count) {
-		nb_buffs_extra = ice_fill_rx_descs(rx_ring->xsk_pool, xdp,
-						   rx_desc,
+		nb_buffs_extra = ice_fill_rx_descs(xsk_pool, xdp, rx_desc,
 						   rx_ring->count - ntu);
 		if (nb_buffs_extra != rx_ring->count - ntu) {
 			ntu += nb_buffs_extra;
@@ -495,7 +498,7 @@ static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
 		ice_release_rx_desc(rx_ring, 0);
 	}
 
-	nb_buffs = ice_fill_rx_descs(rx_ring->xsk_pool, xdp, rx_desc, count);
+	nb_buffs = ice_fill_rx_descs(xsk_pool, xdp, rx_desc, count);
 
 	ntu += nb_buffs;
 	if (ntu == rx_ring->count)
@@ -511,6 +514,7 @@ static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
 /**
  * ice_alloc_rx_bufs_zc - allocate a number of Rx buffers
  * @rx_ring: Rx ring
+ * @xsk_pool: XSK buffer pool to pick buffers to be filled by HW
  * @count: The number of buffers to allocate
  *
  * Wrapper for internal allocation routine; figure out how many tail
@@ -518,7 +522,8 @@ static bool __ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
  *
  * Returns true if all calls to internal alloc routine succeeded
  */
-bool ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
+bool ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring,
+			  struct xsk_buff_pool *xsk_pool, u16 count)
 {
 	u16 rx_thresh = ICE_RING_QUARTER(rx_ring);
 	u16 leftover, i, tail_bumps;
@@ -527,9 +532,9 @@ bool ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count)
 	leftover = count - (tail_bumps * rx_thresh);
 
 	for (i = 0; i < tail_bumps; i++)
-		if (!__ice_alloc_rx_bufs_zc(rx_ring, rx_thresh))
+		if (!__ice_alloc_rx_bufs_zc(rx_ring, xsk_pool, rx_thresh))
 			return false;
-	return __ice_alloc_rx_bufs_zc(rx_ring, leftover);
+	return __ice_alloc_rx_bufs_zc(rx_ring, xsk_pool, leftover);
 }
 
 /**
@@ -650,7 +655,7 @@ static u32 ice_clean_xdp_irq_zc(struct ice_tx_ring *xdp_ring)
 	if (xdp_ring->next_to_clean >= cnt)
 		xdp_ring->next_to_clean -= cnt;
 	if (xsk_frames)
-		xsk_tx_completed(xdp_ring->xsk_pool, xsk_frames);
+		xsk_tx_completed(READ_ONCE(xdp_ring->xsk_pool), xsk_frames);
 
 	return completed_frames;
 }
@@ -702,7 +707,8 @@ static int ice_xmit_xdp_tx_zc(struct xdp_buff *xdp,
 		dma_addr_t dma;
 
 		dma = xsk_buff_xdp_get_dma(xdp);
-		xsk_buff_raw_dma_sync_for_device(xdp_ring->xsk_pool, dma, size);
+		xsk_buff_raw_dma_sync_for_device(READ_ONCE(xdp_ring->xsk_pool),
+						 dma, size);
 
 		tx_buf->xdp = xdp;
 		tx_buf->type = ICE_TX_BUF_XSK_TX;
@@ -760,7 +766,8 @@ ice_run_xdp_zc(struct ice_rx_ring *rx_ring, struct xdp_buff *xdp,
 		err = xdp_do_redirect(rx_ring->netdev, xdp, xdp_prog);
 		if (!err)
 			return ICE_XDP_REDIR;
-		if (xsk_uses_need_wakeup(rx_ring->xsk_pool) && err == -ENOBUFS)
+		if (xsk_uses_need_wakeup(READ_ONCE(rx_ring->xsk_pool)) &&
+		    err == -ENOBUFS)
 			result = ICE_XDP_EXIT;
 		else
 			result = ICE_XDP_CONSUMED;
@@ -829,8 +836,8 @@ ice_add_xsk_frag(struct ice_rx_ring *rx_ring, struct xdp_buff *first,
  */
 int ice_clean_rx_irq_zc(struct ice_rx_ring *rx_ring, int budget)
 {
+	struct xsk_buff_pool *xsk_pool = READ_ONCE(rx_ring->xsk_pool);
 	unsigned int total_rx_bytes = 0, total_rx_packets = 0;
-	struct xsk_buff_pool *xsk_pool = rx_ring->xsk_pool;
 	u32 ntc = rx_ring->next_to_clean;
 	u32 ntu = rx_ring->next_to_use;
 	struct xdp_buff *first = NULL;
@@ -942,7 +949,8 @@ int ice_clean_rx_irq_zc(struct ice_rx_ring *rx_ring, int budget)
 	rx_ring->next_to_clean = ntc;
 	entries_to_alloc = ICE_RX_DESC_UNUSED(rx_ring);
 	if (entries_to_alloc > ICE_RING_QUARTER(rx_ring))
-		failure |= !ice_alloc_rx_bufs_zc(rx_ring, entries_to_alloc);
+		failure |= !ice_alloc_rx_bufs_zc(rx_ring, xsk_pool,
+						 entries_to_alloc);
 
 	ice_finalize_xdp_rx(xdp_ring, xdp_xmit, 0);
 	ice_update_rx_ring_stats(rx_ring, total_rx_packets, total_rx_bytes);
@@ -965,17 +973,19 @@ int ice_clean_rx_irq_zc(struct ice_rx_ring *rx_ring, int budget)
 /**
  * ice_xmit_pkt - produce a single HW Tx descriptor out of AF_XDP descriptor
  * @xdp_ring: XDP ring to produce the HW Tx descriptor on
+ * @xsk_pool: XSK buffer pool to pick buffers to be consumed by HW
  * @desc: AF_XDP descriptor to pull the DMA address and length from
  * @total_bytes: bytes accumulator that will be used for stats update
  */
-static void ice_xmit_pkt(struct ice_tx_ring *xdp_ring, struct xdp_desc *desc,
+static void ice_xmit_pkt(struct ice_tx_ring *xdp_ring,
+			 struct xsk_buff_pool *xsk_pool, struct xdp_desc *desc,
 			 unsigned int *total_bytes)
 {
 	struct ice_tx_desc *tx_desc;
 	dma_addr_t dma;
 
-	dma = xsk_buff_raw_get_dma(xdp_ring->xsk_pool, desc->addr);
-	xsk_buff_raw_dma_sync_for_device(xdp_ring->xsk_pool, dma, desc->len);
+	dma = xsk_buff_raw_get_dma(xsk_pool, desc->addr);
+	xsk_buff_raw_dma_sync_for_device(xsk_pool, dma, desc->len);
 
 	tx_desc = ICE_TX_DESC(xdp_ring, xdp_ring->next_to_use++);
 	tx_desc->buf_addr = cpu_to_le64(dma);
@@ -988,10 +998,13 @@ static void ice_xmit_pkt(struct ice_tx_ring *xdp_ring, struct xdp_desc *desc,
 /**
  * ice_xmit_pkt_batch - produce a batch of HW Tx descriptors out of AF_XDP descriptors
  * @xdp_ring: XDP ring to produce the HW Tx descriptors on
+ * @xsk_pool: XSK buffer pool to pick buffers to be consumed by HW
  * @descs: AF_XDP descriptors to pull the DMA addresses and lengths from
  * @total_bytes: bytes accumulator that will be used for stats update
  */
-static void ice_xmit_pkt_batch(struct ice_tx_ring *xdp_ring, struct xdp_desc *descs,
+static void ice_xmit_pkt_batch(struct ice_tx_ring *xdp_ring,
+			       struct xsk_buff_pool *xsk_pool,
+			       struct xdp_desc *descs,
 			       unsigned int *total_bytes)
 {
 	u16 ntu = xdp_ring->next_to_use;
@@ -1001,8 +1014,8 @@ static void ice_xmit_pkt_batch(struct ice_tx_ring *xdp_ring, struct xdp_desc *de
 	loop_unrolled_for(i = 0; i < PKTS_PER_BATCH; i++) {
 		dma_addr_t dma;
 
-		dma = xsk_buff_raw_get_dma(xdp_ring->xsk_pool, descs[i].addr);
-		xsk_buff_raw_dma_sync_for_device(xdp_ring->xsk_pool, dma, descs[i].len);
+		dma = xsk_buff_raw_get_dma(xsk_pool, descs[i].addr);
+		xsk_buff_raw_dma_sync_for_device(xsk_pool, dma, descs[i].len);
 
 		tx_desc = ICE_TX_DESC(xdp_ring, ntu++);
 		tx_desc->buf_addr = cpu_to_le64(dma);
@@ -1018,21 +1031,24 @@ static void ice_xmit_pkt_batch(struct ice_tx_ring *xdp_ring, struct xdp_desc *de
 /**
  * ice_fill_tx_hw_ring - produce the number of Tx descriptors onto ring
  * @xdp_ring: XDP ring to produce the HW Tx descriptors on
+ * @xsk_pool: XSK buffer pool to pick buffers to be consumed by HW
  * @descs: AF_XDP descriptors to pull the DMA addresses and lengths from
  * @nb_pkts: count of packets to be send
  * @total_bytes: bytes accumulator that will be used for stats update
  */
-static void ice_fill_tx_hw_ring(struct ice_tx_ring *xdp_ring, struct xdp_desc *descs,
-				u32 nb_pkts, unsigned int *total_bytes)
+static void ice_fill_tx_hw_ring(struct ice_tx_ring *xdp_ring,
+				struct xsk_buff_pool *xsk_pool,
+				struct xdp_desc *descs, u32 nb_pkts,
+				unsigned int *total_bytes)
 {
 	u32 batched, leftover, i;
 
 	batched = ALIGN_DOWN(nb_pkts, PKTS_PER_BATCH);
 	leftover = nb_pkts & (PKTS_PER_BATCH - 1);
 	for (i = 0; i < batched; i += PKTS_PER_BATCH)
-		ice_xmit_pkt_batch(xdp_ring, &descs[i], total_bytes);
+		ice_xmit_pkt_batch(xdp_ring, xsk_pool, &descs[i], total_bytes);
 	for (; i < batched + leftover; i++)
-		ice_xmit_pkt(xdp_ring, &descs[i], total_bytes);
+		ice_xmit_pkt(xdp_ring, xsk_pool, &descs[i], total_bytes);
 }
 
 /**
@@ -1043,7 +1059,8 @@ static void ice_fill_tx_hw_ring(struct ice_tx_ring *xdp_ring, struct xdp_desc *d
  */
 bool ice_xmit_zc(struct ice_tx_ring *xdp_ring)
 {
-	struct xdp_desc *descs = xdp_ring->xsk_pool->tx_descs;
+	struct xsk_buff_pool *xsk_pool = READ_ONCE(xdp_ring->xsk_pool);
+	struct xdp_desc *descs = xsk_pool->tx_descs;
 	u32 nb_pkts, nb_processed = 0;
 	unsigned int total_bytes = 0;
 	int budget;
@@ -1057,25 +1074,26 @@ bool ice_xmit_zc(struct ice_tx_ring *xdp_ring)
 	budget = ICE_DESC_UNUSED(xdp_ring);
 	budget = min_t(u16, budget, ICE_RING_QUARTER(xdp_ring));
 
-	nb_pkts = xsk_tx_peek_release_desc_batch(xdp_ring->xsk_pool, budget);
+	nb_pkts = xsk_tx_peek_release_desc_batch(xsk_pool, budget);
 	if (!nb_pkts)
 		return true;
 
 	if (xdp_ring->next_to_use + nb_pkts >= xdp_ring->count) {
 		nb_processed = xdp_ring->count - xdp_ring->next_to_use;
-		ice_fill_tx_hw_ring(xdp_ring, descs, nb_processed, &total_bytes);
+		ice_fill_tx_hw_ring(xdp_ring, xsk_pool, descs, nb_processed,
+				    &total_bytes);
 		xdp_ring->next_to_use = 0;
 	}
 
-	ice_fill_tx_hw_ring(xdp_ring, &descs[nb_processed], nb_pkts - nb_processed,
-			    &total_bytes);
+	ice_fill_tx_hw_ring(xdp_ring, xsk_pool, &descs[nb_processed],
+			    nb_pkts - nb_processed, &total_bytes);
 
 	ice_set_rs_bit(xdp_ring);
 	ice_xdp_ring_update_tail(xdp_ring);
 	ice_update_tx_ring_stats(xdp_ring, nb_pkts, total_bytes);
 
-	if (xsk_uses_need_wakeup(xdp_ring->xsk_pool))
-		xsk_set_tx_need_wakeup(xdp_ring->xsk_pool);
+	if (xsk_uses_need_wakeup(xsk_pool))
+		xsk_set_tx_need_wakeup(xsk_pool);
 
 	return nb_pkts < budget;
 }
@@ -1108,7 +1126,7 @@ ice_xsk_wakeup(struct net_device *netdev, u32 queue_id,
 
 	ring = vsi->rx_rings[queue_id]->xdp_ring;
 
-	if (!ring->xsk_pool)
+	if (!READ_ONCE(ring->xsk_pool))
 		return -EINVAL;
 
 	/* The idea here is that if NAPI is running, mark a miss, so
diff --git a/drivers/net/ethernet/intel/ice/ice_xsk.h b/drivers/net/ethernet/intel/ice/ice_xsk.h
index 6fa181f080ef..4cd2d62a0836 100644
--- a/drivers/net/ethernet/intel/ice/ice_xsk.h
+++ b/drivers/net/ethernet/intel/ice/ice_xsk.h
@@ -22,7 +22,8 @@ int ice_xsk_pool_setup(struct ice_vsi *vsi, struct xsk_buff_pool *pool,
 		       u16 qid);
 int ice_clean_rx_irq_zc(struct ice_rx_ring *rx_ring, int budget);
 int ice_xsk_wakeup(struct net_device *netdev, u32 queue_id, u32 flags);
-bool ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring, u16 count);
+bool ice_alloc_rx_bufs_zc(struct ice_rx_ring *rx_ring,
+			  struct xsk_buff_pool *xsk_pool, u16 count);
 bool ice_xsk_any_rx_ring_ena(struct ice_vsi *vsi);
 void ice_xsk_clean_rx_ring(struct ice_rx_ring *rx_ring);
 void ice_xsk_clean_xdp_ring(struct ice_tx_ring *xdp_ring);
@@ -51,6 +52,7 @@ ice_clean_rx_irq_zc(struct ice_rx_ring __always_unused *rx_ring,
 
 static inline bool
 ice_alloc_rx_bufs_zc(struct ice_rx_ring __always_unused *rx_ring,
+		     struct xsk_buff_pool __always_unused *xsk_pool,
 		     u16 __always_unused count)
 {
 	return false;
-- 
2.34.1


^ permalink raw reply related	[relevance 1%]

Results 1-200 of ~7000000   | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2024-03-01  9:24     [LSF/MM/BPF TOPIC] Swap Abstraction "the pony" Chris Li
2024-03-07  7:56     ` Chuanhua Han
2024-03-07 14:03       ` [Lsf-pc] " Jan Kara
2024-05-17 12:12         ` Karim Manaouil
2024-05-21 20:40           ` Chris Li
2024-05-29  3:57             ` Matthew Wilcox
2024-05-29  6:50               ` Chris Li
2024-05-29 12:33  0%             ` Matthew Wilcox
2024-03-09 10:18     Thread for updating minor properties of tracked regressions [consider ignoring it!] Thorsten Leemhuis
2024-05-29 13:25  0% ` Linux regression tracking (Thorsten Leemhuis)
2024-03-20 21:33     [PATCH 0/2] provide toolchain abstracted __builtin_constant_p Tyler Retzlaff
2024-03-20 21:33     ` [PATCH 2/2] mempool: use rte constant macro instead of GCC builtin Tyler Retzlaff
2024-03-26  9:57       ` Morten Brørup
2024-05-29 11:42  3%     ` Andrew Rybchenko
2024-04-16  8:12     [PATCH v1] crypto: fix build issues on crypto callbacks macro undefined Ganapati Kundapura
2024-05-29  8:35     ` [EXTERNAL] " Akhil Goyal
2024-05-29  9:57       ` Kundapura, Ganapati
2024-05-29 11:40  0%     ` Akhil Goyal
2024-04-18  8:30     [meta-virtualization][PATCH] lxc: update to 6.0.0 Xiangyu Chen
     [not found]     ` <17C75EBD44309AA6.15491@lists.yoctoproject.org>
2024-05-29 13:37  1%   ` Bruce Ashfield
2024-04-19 16:50     NFSD: Unable to initialize client recovery tracking! (-110) Paul Menzel
2024-05-21  9:55     ` Paul Menzel
2024-05-21 10:01       ` Jeff Layton
2024-05-24 11:16         ` Linux regression tracking (Thorsten Leemhuis)
2024-05-24 16:09           ` Chuck Lever III
2024-05-29 12:51  0%         ` Linux regression tracking (Thorsten Leemhuis)
2024-05-29 13:13  0%         ` Jeff Layton
2024-05-29 13:16  0%           ` Chuck Lever III
2024-05-29 13:27  0%           ` Paul Menzel
2024-04-26  0:51     [PATCH] net/af_xdp: fix umem map size for zero copy Frank Du
2024-05-11  5:26     ` [PATCH v2] " Frank Du
2024-05-21 17:57       ` Ferruh Yigit
2024-05-22  1:25         ` Du, Frank
2024-05-22  7:26           ` Morten Brørup
2024-05-23  6:56             ` Du, Frank
2024-05-23  7:40               ` Morten Brørup
2024-05-23  7:56                 ` Du, Frank
2024-05-29 12:57  0%               ` Loftus, Ciara
2024-04-26 12:00     [syzbot] [ntfs3?] KASAN: slab-use-after-free Read in chrdev_open syzbot
2024-05-29 11:49  3% ` Hillf Danton
2024-05-29 12:02  4%   ` syzbot
2024-04-28 14:29     [PATCH net] net: prevent pulling SKB_GSO_FRAGLIST skb shiming.cheng
2024-04-29 13:42     ` Jakub Kicinski
2024-05-15  9:02       ` Lena Wang (王娜)
2024-05-16 15:11         ` Jakub Kicinski
2024-05-23 10:03           ` Lena Wang (王娜)
2024-05-23 12:46             ` Willem de Bruijn
2024-05-23 14:59               ` Willem de Bruijn
2024-05-29 11:35  0%             ` Lena Wang (王娜)
2024-04-29 18:44     [syzbot] [f2fs?] KASAN: slab-use-after-free Read in sanity_check_extent_cache syzbot
2024-05-29 11:26  3% ` [f2fs-dev] " Chao Yu
2024-05-29 11:26  3%   ` Chao Yu
2024-05-29 11:48  2%   ` syzbot
2024-05-29 11:48  2%     ` syzbot
2024-05-06 19:06     [PATCH 0/2] Revert "monitor: use aio_co_reschedule_self()" Stefan Hajnoczi
2024-05-06 19:06     ` [PATCH 1/2] " Stefan Hajnoczi
2024-05-29 10:33       ` Fiona Ebner
2024-05-29 13:20  3%     ` Kevin Wolf
2024-05-09 10:57     [PATCH 0/2] dts: update mypy and clean up Luca Vizzarro
2024-05-09 10:57     ` [PATCH 2/2] dts: clean up config types Luca Vizzarro
2024-05-29 11:41  0%   ` Juraj Linkeš
2024-05-10  6:22     [PATCH] xilinx: versal: Do not prioritize boot device if driver is not enabled Michal Simek
2024-05-29 13:15  0% ` Michal Simek
2024-05-10 11:26     [PATCH v3 00/12] KVM: arm64: Add support for hypervisor kCFI Pierre-Clément Tosi
2024-05-10 11:26     ` [PATCH v3 09/12] KVM: arm64: VHE: Add test module for hyp kCFI Pierre-Clément Tosi
2024-05-13 17:21       ` Will Deacon
2024-05-29 12:26  0%     ` Pierre-Clément Tosi
2024-05-29 12:26  0%       ` Pierre-Clément Tosi
2024-05-10 11:26     ` [PATCH v3 10/12] KVM: arm64: nVHE: Support CONFIG_CFI_CLANG at EL2 Pierre-Clément Tosi
2024-05-13 17:30       ` Will Deacon
2024-05-29 12:30  0%     ` Pierre-Clément Tosi
2024-05-29 12:30  0%       ` Pierre-Clément Tosi
2024-05-13 17:35     [PATCH 1/3] mctp pcc: Implement MCTP over PCC Transport admiyo
2024-05-29 13:10  2% ` kernel test robot
2024-05-14 18:16     [PATCH 0/2] Revert defense-in-depth patches breaking Git LFS brian m. carlson
2024-05-14 19:07     ` Johannes Schindelin
2024-05-14 19:41       ` brian m. carlson
2024-05-22  9:49         ` Joey Hess
2024-05-27 19:35           ` Johannes Schindelin
2024-05-28  2:13             ` Joey Hess
2024-05-29  8:54               ` Jeff King
2024-05-29 12:17  0%             ` Johannes Schindelin
2024-05-15 11:11     Request for updating device dictionaries Sai.Sathujoda
2024-05-20 10:22     ` Sai.Sathujoda
     [not found]       ` <TYWPR01MB11862221FADD6EE25E032DADBB7EA2@TYWPR01MB11862.jpnprd01.prod.outlook.com>
     [not found]         ` <OS3PR01MB610353B51E2D66C802A5104DC2EA2@OS3PR01MB6103.jpnprd01.prod.outlook.com>
     [not found]           ` <TYWPR01MB1186210AA7A8F762825C4BD44B7F42@TYWPR01MB11862.jpnprd01.prod.outlook.com>
2024-05-24  7:44             ` Sai.Sathujoda
2024-05-28 18:22               ` Sai.Sathujoda
2024-05-28 23:13                 ` Chris Paterson
2024-05-29  0:55                   ` Sai.Sathujoda
2024-05-29 13:07  0%                 ` Chris Paterson
2024-05-15 11:24     [PATCH v12 00/10] Improve test coverage of TTM Karolina Stolarek
2024-05-15 11:24     ` [PATCH v12 06/10] drm/ttm/tests: Add tests with mock resource managers Karolina Stolarek
2024-05-29 12:58  2%   ` Thomas Hellström
2024-05-21 12:23     [PATCH v5 0/3] virtio-net: Clarify virtio_net_hdr size and rx buffer size Parav Pandit
2024-05-21 12:23     ` [PATCH v5 2/3] virtio-net: Clarify the size of the struct virtio_net_hdr for tx Parav Pandit
2024-05-29 11:47  0%   ` Xuan Zhuo
2024-05-21 12:23     ` [PATCH v5 3/3] virtio-net: Annotate virtio_net_hdr as field Parav Pandit
2024-05-29 11:48  0%   ` Xuan Zhuo
2024-05-21 14:03     [PATCH v2 0/3] Rust block device driver API and null block driver Andreas Hindborg
2024-05-21 14:03     ` [PATCH v2 1/3] rust: block: introduce `kernel::block::mq` module Andreas Hindborg
2024-05-28 13:24       ` Benno Lossin
2024-05-29 12:52  1%     ` Andreas Hindborg
2024-05-21 14:03     ` [PATCH v2 2/3] rust: block: add rnull, Rust null_blk implementation Andreas Hindborg
2024-05-28 13:27       ` Benno Lossin
2024-05-29 13:00  0%     ` Andreas Hindborg
2024-05-22  3:32     [PATCH 0/1] RDMA/mlx5: Release CPU for other processes in mlx5_free_cmd_msg() Anand Khoje
2024-05-22  3:32     ` [PATCH 1/1] " Anand Khoje
2024-05-26 15:23       ` Shay Drori
2024-05-29 12:01  2%     ` Anand Khoje
2024-05-22 11:42     [PATCH v3 00/12] cachefiles: some bugfixes and cleanups for ondemand requests libaokun
2024-05-29 11:07     ` Christian Brauner
2024-05-29 11:23  0%   ` Baokun Li
2024-05-22 13:13     [PATCH 1/3] kexec_load: Use new kexec flag for hotplug support Sourabh Jain
2024-05-28 11:33     ` Aditya Gupta
2024-05-29 13:13  3%   ` Sourabh Jain
2024-05-23 13:46     [PATCH v2 0/2] drm/i915/display: Add comparison for pipe config for MTL+ > Mika Kahola
2024-05-29 13:38  0% ` Jani Nikula
2024-05-23 16:53     [PATCH 1/1] arm/sbsa-ref: move to Neoverse-N2 as default Marcin Juszkiewicz
2024-05-29 13:11  0% ` Leif Lindholm
2024-05-24 10:24     [PATCH v9 0/8] Implement CMRR Support Mitul Golani
2024-05-24 10:24     ` [PATCH v9 3/8] drm/i915: Compute CMRR and calculate vtotal Mitul Golani
2024-05-28  9:34       ` Nautiyal, Ankit K
2024-05-29 11:43  0%     ` Nautiyal, Ankit K
2024-05-24 14:31     [PATCH v3 0/6] thermal: Add support of multiple sensors Alexandre Bailon
2024-05-24 14:31     ` [PATCH v3 6/6] ARM64: mt8195: Use thermal aggregation for big and little cpu Alexandre Bailon
2024-05-27  6:56       ` Krzysztof Kozlowski
2024-05-29  8:19         ` Alexandre Bailon
2024-05-29 12:39  3%       ` Krzysztof Kozlowski
2024-05-24 15:13     [PATCH] tools/memory-model: Document herd7 (internal) representation Andrea Parri
2024-05-27 12:22     ` Hernan Ponce de Leon
2024-05-27 13:28       ` Andrea Parri
2024-05-27 13:40         ` Jonas Oberhauser
2024-05-28 17:58           ` Boqun Feng
2024-05-29 12:37  1%         ` Jonas Oberhauser
2024-05-24 16:08     Intermittent inability to type in graphical Plymouth on UEFI VMs since kernel 6.9 Adam Williamson
2024-05-27 15:18     ` Genes Lists
2024-05-29 13:01       ` Linux regression tracking (Thorsten Leemhuis)
2024-05-29 13:35  1%     ` Genes Lists
2024-05-25  0:12     [REGRESSION][BISECTED] Scheduling errors with the AMD FX 8300 CPU Christian Heusel
2024-05-27 10:06     ` Thomas Gleixner
2024-05-27 12:35       ` Tim Teichmann
2024-05-27 15:01         ` Thomas Gleixner
2024-05-27 16:36           ` Tim Teichmann
2024-05-27 17:17             ` Thomas Gleixner
2024-05-28 15:43               ` Tim Teichmann
2024-05-28 19:15                 ` Thomas Gleixner
2024-05-28 19:17                   ` Jens Axboe
2024-05-28 20:19                     ` Niklas Cassel
2024-05-29 13:02  1%                   ` Tim Teichmann
2024-05-26 16:34     Increasing usage of mutex guards (with SmPL)? Markus Elfring
2024-05-26 16:49     ` [cocci] " Julia Lawall
2024-05-29 12:10  0%   ` [cocci] Looking at guard usage (with SmPL) Markus Elfring
2024-05-29 12:50  0%     ` Dr. David Alan Gilbert
2024-05-26 17:56     [PATCH v9 00/10] Add V4L2 M2M Driver for E5010 JPEG Encoder Devarsh Thakkar
2024-05-26 18:08     ` [PATCH v9 06/10] math.h: Add macros for rounding to closest value Devarsh Thakkar
2024-05-27 20:32       ` Andy Shevchenko
2024-05-28 10:32         ` Devarsh Thakkar
2024-05-29 13:17  0%       ` Andy Shevchenko
2024-05-27 12:02     [PATCH libgpiod v2 0/4] tools: tests: fix a few issues in bash scripts Bartosz Golaszewski
2024-05-27 12:02     ` [PATCH libgpiod v2 2/4] tools: tests: use "$@" instead of $* Bartosz Golaszewski
2024-05-27 12:44       ` Kent Gibson
2024-05-27 16:17         ` Andy Shevchenko
2024-05-27 23:39           ` Kent Gibson
2024-05-29 13:08  3%         ` Andy Shevchenko
2024-05-29 13:18  3%           ` Kent Gibson
2024-05-29 13:27  3%             ` Andy Shevchenko
2024-05-27 16:20         ` Andy Shevchenko
2024-05-27 23:54           ` Kent Gibson
2024-05-29 13:11  3%         ` Andy Shevchenko
2024-05-27 17:02     [PATCH v3 0/6] Add support for AD411x Dumitru Ceclan via B4 Relay
2024-05-27 17:02     ` [PATCH v3 1/6] dt-bindings: adc: ad7173: add support for ad411x Dumitru Ceclan via B4 Relay
2024-05-27 17:48       ` Conor Dooley
2024-05-28 12:16         ` Ceclan, Dumitru
2024-05-28 17:52           ` Conor Dooley
2024-05-29 13:38  1%         ` Ceclan, Dumitru
2024-05-27 17:02     ` [PATCH v3 3/6] iio: adc: ad7173: refactor ain and vref selection Dumitru Ceclan via B4 Relay
2024-05-29 12:27  0%   ` Nuno Sá
2024-05-29 12:49  1%     ` Nuno Sá
2024-05-27 17:35     [PATCH 0/5] VF: Setup VRAM based on received config data Michal Wajdeczko
2024-05-27 17:35     ` [PATCH 4/5] drm/xe: Rename internal vram helper function Michal Wajdeczko
2024-05-28 21:35       ` Matt Roper
2024-05-28 22:15         ` Matthew Brost
2024-05-29 11:25  2%       ` Michal Wajdeczko
2024-05-29 11:50  1%         ` Jani Nikula
2024-05-29 12:45  0%           ` Michal Wajdeczko
2024-05-28  4:34     [PATCH 0/3] mm: zswap: global shrinker fix and proactive shrink Takero Funaki
2024-05-28  4:34     ` [PATCH 1/3] mm: zswap: fix global shrinker memcg iteration Takero Funaki
2024-05-28 15:09       ` Nhat Pham
2024-05-29 12:42  0%     ` Takero Funaki
2024-05-28  4:34     ` [PATCH 3/3] mm: zswap: proactive shrinking before pool size limit is hit Takero Funaki
2024-05-28 16:01       ` Nhat Pham
2024-05-29 13:27  0%     ` Takero Funaki
2024-05-28  6:23     [PATCH] btrfs: qgroup: delete a todo about using kmem cache to alloc structure Junchao Sun
2024-05-28  6:42     ` Qu Wenruo
2024-05-29 13:11  0%   ` JunChao Sun
2024-05-28  7:22     [PATCH v4] mc146818rtc: add a way to generate RTC interrupts via QMP Daniil Tatianin
2024-05-29 12:03     ` Markus Armbruster
2024-05-29 12:36  1%   ` Philippe Mathieu-Daudé
2024-05-29 12:43  0%     ` Daniil Tatianin
2024-05-29 13:39  0%       ` Philippe Mathieu-Daudé
2024-05-28  7:28     [PATCH 00/25] Update IDPF Base Driver Soumyadeep Hore
2024-05-28  7:28     ` [PATCH 01/25] common/idpf: added NVME CPF specific code with defines Soumyadeep Hore
2024-05-29 12:32  0%   ` Bruce Richardson
2024-05-28  7:28     ` [PATCH 03/25] common/idpf: update ADD QUEUE GROUPS offset Soumyadeep Hore
2024-05-29 12:38  0%   ` Bruce Richardson
2024-05-28  7:35     [PATCH 10/25] common/idpf: avoid variable 0-init Soumyadeep Hore
2024-05-29 13:26  0% ` Bruce Richardson
2024-05-28  8:42     [PATCH] Makefile: Fix include directory for OF_UPSTREAM Patrick Barsanti
2024-05-29  6:57     ` Sumit Garg
2024-05-29  9:15       ` Patrick Barsanti
2024-05-29 12:00  0%     ` Sumit Garg
2024-05-28  9:17     [PATCH wireless-next 0/8] wifi: TI wilink8 updates Russell King (Oracle)
2024-05-28  9:17     ` [PATCH wireless-next 4/8] wifi: wlcore: pass "status" to wlcore_hw_convert_fw_status() Russell King (Oracle)
2024-05-29 13:15  0%   ` Nemanov, Michael
2024-05-28  9:55     [PATCHv11 00/19] x86/tdx: Add kexec support Kirill A. Shutemov
2024-05-28  9:55     ` [PATCHv11 05/19] x86/relocate_kernel: Use named labels for less confusion Kirill A. Shutemov
2024-05-29 10:47       ` Nikolay Borisov
2024-05-29 11:17         ` Kirill A. Shutemov
2024-05-29 11:28  3%       ` Borislav Petkov
2024-05-29 11:28  3%         ` Borislav Petkov
2024-05-29 12:33  3%         ` Andrew Cooper
2024-05-29 12:33  3%           ` Andrew Cooper
2024-05-28 10:33     [Intel-wired-lan] [PATCH iwl-net v1 1/1] e1000e: Fix S0ix residency on Meteor Lake corporate systems Vitaly Lifshits
2024-05-28 10:43     ` Paul Menzel
2024-05-29 11:13       ` Lifshits, Vitaly
2024-05-29 11:23  0%     ` Paul Menzel
2024-05-28 11:22     [Intel-wired-lan] [PATCH iwl-next v6 00/12] Add support for Rx timestamping for both ice and iavf drivers Mateusz Polchlopek
2024-05-28 11:23     ` [Intel-wired-lan] [PATCH iwl-next v6 11/12] iavf: handle SIOCSHWTSTAMP and SIOCGHWTSTAMP Mateusz Polchlopek
2024-05-28 20:00       ` Jakub Kicinski
2024-05-28 23:54         ` Keller, Jacob E
2024-05-29 13:12  0%       ` Mateusz Polchlopek
2024-05-29 13:12  0%         ` Mateusz Polchlopek
2024-05-28 11:57     [PATCH 1/2] HID: intel-ish-hid: fix cache management mistake Arnd Bergmann
2024-05-28 11:57     ` [PATCH 2/2] HID: intel-ish-hid: fix endian-conversion Arnd Bergmann
2024-05-29  7:05       ` Zhang, Lixu
2024-05-29 13:18  0%     ` Arnd Bergmann
2024-05-28 15:10     [PATCH 0/7] Zacas/Zabha support and qspinlocks Alexandre Ghiti
2024-05-28 15:10     ` [PATCH 1/7] riscv: Implement cmpxchg32/64() using Zacas Alexandre Ghiti
2024-05-28 15:34       ` Conor Dooley
2024-05-29 12:20  1%     ` Alexandre Ghiti
2024-05-29 12:20  1%       ` Alexandre Ghiti
2024-05-28 15:10     ` [PATCH 2/7] riscv: Implement cmpxchg8/16() using Zabha Alexandre Ghiti
2024-05-28 19:31       ` Nathan Chancellor
2024-05-29 12:49  0%     ` Alexandre Ghiti
2024-05-29 12:49  0%       ` Alexandre Ghiti
2024-05-28 15:10     ` [PATCH 7/7] riscv: Add qspinlock support based on Zabha extension Alexandre Ghiti
2024-05-29  9:23       ` Guo Ren
2024-05-29 13:03  1%     ` Alexandre Ghiti
2024-05-29 13:03  1%       ` Alexandre Ghiti
2024-05-28 16:41     [PATCH] of: property: Fix fw_devlink handling of interrupt-map Marc Zyngier
2024-05-29  5:15     ` Anup Patel
2024-05-29  6:33       ` Marc Zyngier
2024-05-29 10:16         ` Anup Patel
2024-05-29 10:44           ` Marc Zyngier
2024-05-29 11:28  0%         ` Anup Patel
2024-05-29 11:28  0%           ` Anup Patel
2024-05-29 11:28  0%           ` Anup Patel
2024-05-29 12:00  0%           ` Marc Zyngier
2024-05-29 12:00  0%             ` Marc Zyngier
2024-05-29 12:00  0%             ` Marc Zyngier
2024-05-28 17:23     [PATCH v2 00/10] drm/amdgpu: prevent concurrent GPU access during reset Yunxiang Li
2024-05-28 17:23     ` [PATCH v2 03/10] drm/amdgpu: abort fence poll if reset is started Yunxiang Li
2024-05-29  6:38       ` Christian König
2024-05-29 13:22  1%     ` Li, Yunxiang (Teddy)
2024-05-29 13:31  0%       ` Christian König
2024-05-28 17:31     /var/log as persistent Patrick Williams
2024-05-29  3:49     ` [External] " Lei Yu
2024-05-29 12:29  1%   ` Patrick Williams
2024-05-28 19:03     [PATCH v2 0/4] ADP5585 GPIO expander, PWM and keypad controller support Laurent Pinchart
2024-05-28 19:03     ` [PATCH v2 2/4] mfd: adp5585: Add Analog Devices ADP5585 core support Laurent Pinchart
2024-05-28 19:27       ` Andy Shevchenko
2024-05-28 20:13         ` Laurent Pinchart
2024-05-29  5:44           ` Andy Shevchenko
2024-05-29  9:35             ` Laurent Pinchart
2024-05-29 13:38  1%           ` Andy Shevchenko
2024-05-28 19:18     [PATCH v2 3/3] mctp pcc: Implement MCTP over PCC Transport admiyo
2024-05-29 13:21  1% ` kernel test robot
2024-05-28 21:08     [PATCH v7 0/5] KEYS: asymmetric: tpm2_key_{rsa,ecdsa} Jarkko Sakkinen
2024-05-28 21:08     ` [PATCH v7 2/5] KEYS: trusted: Change -EINVAL to -E2BIG Jarkko Sakkinen
2024-05-29  1:50       ` Stefan Berger
2024-05-29 12:20  1%     ` Jarkko Sakkinen
2024-05-28 23:55     [PATCH v2 resend 0/8] use for_each_endpoint_of_node() Kuninori Morimoto
2024-05-28 23:55     ` [PATCH v2 resend 2/8] hwtracing: " Kuninori Morimoto
2024-05-29  0:40       ` Laurent Pinchart
2024-05-29 12:30  3%     ` James Clark
2024-05-29 12:30  3%       ` James Clark
2024-05-29  2:13     [RFC PATCH] arm64: dts: rockchip: Make preparations for per-RK3588-variant OPPs Dragan Simic
2024-05-29  9:57     ` Alexey Charkov
2024-05-29 10:45       ` Dragan Simic
2024-05-29 12:04  1%     ` Alexey Charkov
2024-05-29 12:04  1%       ` Alexey Charkov
2024-05-29 12:04  1%       ` Alexey Charkov
2024-05-29 12:22  1%       ` Dragan Simic
2024-05-29 12:22  1%         ` Dragan Simic
2024-05-29 12:22  1%         ` Dragan Simic
2024-05-29 11:09       ` Diederik de Haas
2024-05-29 11:33  0%     ` Dragan Simic
2024-05-29 11:33  0%       ` Dragan Simic
2024-05-29 11:33  0%       ` Dragan Simic
2024-05-29  3:59     [PATCH net-next v4 0/3] Introduce IPPROTO_SMC D. Wythe
2024-05-29  3:59     ` [PATCH net-next v4 3/3] net/smc: " D. Wythe
2024-05-29 11:58  1%   ` Wenjia Zhang
2024-05-29  4:13     [PATCH] tests/qtest/migrate-test: Add a postcopy memfile test Nicholas Piggin
2024-05-29 12:54  0% ` Fabiano Rosas
2024-05-29  5:15     [PATCH v5 00/23] hw/i386: Remove deprecated pc-i440fx-2.0 -> 2.3 machines Philippe Mathieu-Daudé
2024-05-29  5:15     ` [PATCH v5 01/23] hw/i386/pc: Deprecate 2.4 to 2.12 pc-i440fx machines Philippe Mathieu-Daudé
2024-05-29 12:51  0%   ` Igor Mammedov
2024-05-29  5:15     ` [PATCH v5 02/23] hw/i386/pc: Remove deprecated pc-i440fx-2.0 machine Philippe Mathieu-Daudé
2024-05-29 12:58  0%   ` Igor Mammedov
2024-05-29  5:32     [PATCH 00/20] iommu: Refactoring domain allocation interface Lu Baolu
2024-05-29  9:03     ` Yi Liu
2024-05-29 12:02  0%   ` Baolu Lu
2024-05-29  5:57     [PATCH v6 0/6] Mediatek thermal sensor driver support for MT8186 and MT8188 Julien Panis
2024-05-29  5:57     ` [PATCH v6 4/6] arm64: dts: mediatek: mt8186: add default thermal zones Julien Panis
2024-05-29  8:17       ` AngeloGioacchino Del Regno
2024-05-29  8:33         ` Chen-Yu Tsai
2024-05-29  9:12           ` Julien Panis
2024-05-29 12:06  1%         ` AngeloGioacchino Del Regno
2024-05-29 12:06  1%           ` AngeloGioacchino Del Regno
2024-05-29  6:29     [PATCH v2 0/3] Bluetooth: btusb: MediaTek ISO data transmission support Chris Lu
2024-05-29  6:29     ` [PATCH v2 3/3] Bluetooth: btusb: mediatek: add MediaTek ISO data transmission function Chris Lu
2024-05-29  7:10       ` Paul Menzel
2024-05-29 11:52  1%     ` Chris Lu (陸稚泓)
2024-05-29  7:45     [PATCH 0/8] gpio-tqmx86 fixes Matthias Schiffer
2024-05-29  7:45     ` [PATCH 3/8] gpio: tqmx86: change tqmx86_gpio_write() order of arguments to match regmap API Matthias Schiffer
2024-05-29 12:03  0%   ` Bartosz Golaszewski
2024-05-29 12:11  0%     ` Andrew Lunn
2024-05-29 12:23  0%       ` Matthias Schiffer
2024-05-29  7:45     ` [PATCH 4/8] gpio: tqmx86: introduce _tqmx86_gpio_update_bits() helper Matthias Schiffer
2024-05-29 12:19  1%   ` Andrew Lunn
2024-05-29 12:25  0%     ` Matthias Schiffer
2024-05-29  7:45     ` [PATCH 8/8] gpio: tqmx86: fix broken IRQ_TYPE_EDGE_BOTH interrupt type Matthias Schiffer
2024-05-29 12:37  1%   ` Andrew Lunn
2024-05-29 12:44  1%     ` Matthias Schiffer
2024-05-29  8:00     [DO NOT MERGE v8 00/36] Device Tree support for SH7751 based board Yoshinori Sato
2024-05-29  8:00     ` [DO NOT MERGE v8 08/36] clocksource: sh_tmu: CLOCKSOURCE support Yoshinori Sato
2024-05-29 12:55  1%   ` Andy Shevchenko
2024-05-29  9:01     [PATCH for-4.19 0/9] x86/irq: fixes for CPU hot{,un}plug Roger Pau Monne
2024-05-29  9:01     ` [PATCH for-4.19 1/9] x86/irq: remove offline CPUs from old CPU mask when adjusting move_cleanup_count Roger Pau Monne
2024-05-29 12:40  1%   ` Jan Beulich
2024-05-29  9:01     ` [PATCH for-4.19 2/9] xen/cpu: do not get the CPU map in stop_machine_run() Roger Pau Monne
2024-05-29 13:04  2%   ` Jan Beulich
2024-05-29  9:01     ` [PATCH for-4.19 3/9] xen/cpu: ensure get_cpu_maps() returns false if CPU operations are underway Roger Pau Monne
2024-05-29 13:35  0%   ` Jan Beulich
2024-05-29  9:06     GPL License Compliance - Automatically detect linking against GPL libraries Hanke Fabian (DC/PAR)
2024-05-29 11:15     ` [yocto] " Stephen John Smoogen
2024-05-29 11:34  0%   ` Alexander Kanavin
2024-05-29 11:58  0%     ` Stephen John Smoogen
2024-05-29  9:17     [PATCH v2 0/3] i2c: mux: gpio: Add 'transition-delay-us' property Bastien Curutchet
2024-05-29  9:17     ` [PATCH v2 1/3] dt-bindings: i2c: " Bastien Curutchet
2024-05-29 12:13  1%   ` Peter Rosin
2024-05-29  9:31     [meta-virtualization][PATCH 1/4] meta-virt: adjust for UNPACKDIR and GO_SRCURI_DESTSUFFIX Qi.Chen
2024-05-29 13:08  1% ` Bruce Ashfield
2024-05-29  9:38     [PATCH 0/6] Region Early Transport debugfs support Jouni Högander
2024-05-29 11:58  1% ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2024-05-29  9:49     [PATCH v2] regulator: gpio: Correct default GPIO state to LOW Geert Uytterhoeven
2024-05-29 13:15  0% ` Mark Brown
2024-05-29 13:19  0%   ` Geert Uytterhoeven
2024-05-29  9:56     [PATCH net v2] ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outbound Yue Haibing
2024-05-29 12:06  3% ` Eric Dumazet
2024-05-29 10:00     [PATCH v2] docs: dt: Update overlay file extension Geert Uytterhoeven
2024-05-29 12:17  0% ` Alex Shi
2024-05-29 11:00     [PATCH v2] reboot: Add timeout for device shutdown Soumya Khasnis
2024-05-29 12:51  1% ` Greg KH
2024-05-29 11:23     [PATCH v2 iwl-net 0/8] ice: fix AF_XDP ZC timeout and concurrency issues Maciej Fijalkowski
2024-05-29 11:23  1% ` [Intel-wired-lan] [PATCH v2 iwl-net 6/8] ice: improve updating ice_{t, r}x_ring::xsk_pool Maciej Fijalkowski
2024-05-29 11:23  1%   ` [PATCH v2 iwl-net 6/8] ice: improve updating ice_{t,r}x_ring::xsk_pool Maciej Fijalkowski
2024-05-29 11:23  1% ` [Intel-wired-lan] [PATCH v2 iwl-net 7/8] ice: add missing WRITE_ONCE when clearing ice_rx_ring::xdp_prog Maciej Fijalkowski
2024-05-29 11:23  1%   ` Maciej Fijalkowski
2024-05-29 11:23  1% ` [Intel-wired-lan] [PATCH v2 iwl-net 8/8] ice: xsk: fix txq interrupt mapping Maciej Fijalkowski
2024-05-29 11:23  1%   ` Maciej Fijalkowski
2024-05-29 11:36  2% [PATCH v3 0/3] vfio/pci: s390: Fix issues preventing VFIO_PCI_MMAP=y for s390 and enable it Niklas Schnelle
2024-05-29 11:36  1% ` [PATCH v3 2/3] vfio/pci: Tolerate oversized BARs by disallowing mmap Niklas Schnelle
2024-05-29 11:42  1% [pci:controller/exynos] BUILD SUCCESS 6b11143f9344ddfb6f27559743db36b85e8e6a89 kernel test robot
     [not found]     <17D34F5B4A354ADD.28935@lists.yoctoproject.org>
2024-05-29 11:59  1% ` [poky][meta-clang][musl][kirkstone] Poky with clang coverage using musl Hope Sneddon
2024-05-29 12:12     [PATCH v4 00/13] KVM: arm64: Add support for hypervisor kCFI Pierre-Clément Tosi
2024-05-29 12:12  4% ` [PATCH v4 04/13] KVM: arm64: nVHE: Add EL2h sync exception handler Pierre-Clément Tosi
2024-05-29 12:12  4%   ` Pierre-Clément Tosi
2024-05-29 12:12  2% ` [PATCH v4 05/13] KVM: arm64: Rename __guest_exit_panic __hyp_panic Pierre-Clément Tosi
2024-05-29 12:12  2%   ` Pierre-Clément Tosi
2024-05-29 12:12  1% ` [PATCH v4 06/13] KVM: arm64: nVHE: gen-hyprel: Skip R_AARCH64_ABS32 Pierre-Clément Tosi
2024-05-29 12:12  1%   ` Pierre-Clément Tosi
2024-05-29 12:12  1% ` [PATCH v4 07/13] KVM: arm64: VHE: Mark __hyp_call_panic __noreturn Pierre-Clément Tosi
2024-05-29 12:12  1%   ` Pierre-Clément Tosi
2024-05-29 12:12  5% ` [PATCH v4 08/13] arm64: Introduce esr_comment() & esr_is_cfi_brk() Pierre-Clément Tosi
2024-05-29 12:12  5%   ` Pierre-Clément Tosi
2024-05-29 12:12  2% ` [PATCH v4 10/13] KVM: arm64: nVHE: Support CONFIG_CFI_CLANG at EL2 Pierre-Clément Tosi
2024-05-29 12:12  2%   ` Pierre-Clément Tosi
2024-05-29 12:12  1% ` [PATCH v4 11/13] KVM: arm64: Improve CONFIG_CFI_CLANG error message Pierre-Clément Tosi
2024-05-29 12:12  1%   ` Pierre-Clément Tosi
2024-05-29 12:12  4% ` [PATCH v4 12/13] KVM: arm64: VHE: Add test module for hyp kCFI Pierre-Clément Tosi
2024-05-29 12:12  4%   ` Pierre-Clément Tosi
2024-05-29 12:12  2% ` [PATCH v4 13/13] KVM: arm64: nVHE: Support " Pierre-Clément Tosi
2024-05-29 12:12  2%   ` Pierre-Clément Tosi
2024-05-29 12:30  1% [PATCH v2 1/2] powerpc/uaccess: Fix build errors seen with GCC 13/14 Michael Ellerman
2024-05-29 12:30  5% ` [PATCH v2 2/2] powerpc/uaccess: Use YZ asm constraint for ld Michael Ellerman
2024-05-29 12:44     [PATCH 00/19] Compile with `-Wwrite-strings` Patrick Steinhardt
2024-05-29 12:44  1% ` [PATCH 02/19] global: assign non-const strings as required Patrick Steinhardt
2024-05-29 12:44  1% ` [PATCH 12/19] remote-curl: avoid assigning string constant to non-const variable Patrick Steinhardt
2024-05-29 12:44  5% [PATCH] bpf: Use an UNUSED id for bpf_session_cookie without FPROBE Sebastian Andrzej Siewior
2024-05-29 12:48  7% [PATCH i-g-t] CONTRIBUTING: Add more guidelines Kamil Konieczny
2024-05-29 12:55  0% ` Louis Chauvet
2024-05-29 12:50  4% [PATCH] thunderbolt: Mention Thunderbolt/USB4 debugging tools in Kconfig Mika Westerberg
2024-05-29 13:06     [PATCH V1 0/5] Add support for Awinic SAR sensor wangshuaijie
2024-05-29 13:06  3% ` [PATCH V1 1/5] dt-bindings: input: Add YAML to Awinic sar sensor wangshuaijie
2024-05-29 13:06  2% ` [PATCH V1 2/5] Add universal interface for the aw_sar driver wangshuaijie
2024-05-29 13:06  2% ` [PATCH V1 5/5] Add support for Awinic sar sensor wangshuaijie
2024-05-29 13:13  6% [RESEND PATCH v2 0/3] Use STM32 access controller for STM32MP25 clocks gabriel.fernandez
2024-05-29 13:13  6% ` gabriel.fernandez
2024-05-29 13:13  2% ` [RESEND PATCH v2 1/3] clk: stm32mp2: use of STM32 access controller gabriel.fernandez
2024-05-29 13:13  2%   ` gabriel.fernandez
2024-05-29 13:13  1% ` [PATCH v2 3/3] arm64: dts: st: enable STM32 access controller for RCC gabriel.fernandez
2024-05-29 13:13  1%   ` gabriel.fernandez
2024-05-29 13:16 14% [scarthgap][PATCH] libdeflate: fix build with -mcpu=cortex-a76+crypto without -march=armv8.2-a+crypto Martin Jansa
2024-05-29 13:19  1% [PATCH v2 0/3] gpiolib: cdev: tidy up kfifo handling Kent Gibson
2024-05-29 13:24  1% [PATCH 00/14] Add basic U-Boot Support for J722S-EVM Jayesh Choudhary
2024-05-29 13:24  5% ` [PATCH 04/14] clk: ti: clk-k3: use IS_ENABLED macro and fix the clock-data order Jayesh Choudhary
2024-05-29 13:27  1% Bad lib symlink in Host SDK Lukas Weiß
2024-05-29 13:28  2% [PATCH net-next 0/6] net: phylink: rearrange ovr_an_inband support Russell King (Oracle)
2024-05-29 13:28  2% ` Russell King (Oracle)
2024-05-29 13:29  5% ` [PATCH net-next 2/6] net: phylink: move test for ovr_an_inband Russell King (Oracle)
2024-05-29 13:29 14% ` [PATCH net-next 4/6] net: fman_memac: remove the now unnecessary checking for fixed-link Russell King (Oracle)
2024-05-29 13:33  1% [pci:controller/gpio] BUILD SUCCESS 1d38f9d89f85f6c925a1ca128a5eabf62574380d kernel test robot
2024-05-29 13:34  2% [PATCH v10 00/19] ACPI/arm64: add support for virtual cpu hotplug Jonathan Cameron
2024-05-29 13:34  2% ` Jonathan Cameron
2024-05-29 13:34  2% ` [PATCH v10 01/19] ACPI: processor: Simplify initial onlining to use same path for cold and hotplug Jonathan Cameron
2024-05-29 13:34  2%   ` Jonathan Cameron
2024-05-29 13:34  3% ` [PATCH v10 06/19] ACPI: processor: Move checks and availability of acpi_processor earlier Jonathan Cameron
2024-05-29 13:34  3%   ` Jonathan Cameron
2024-05-29 13:34  1% ` [PATCH v10 10/19] ACPI: Add post_eject to struct acpi_scan_handler for cpu hotplug Jonathan Cameron
2024-05-29 13:34  1%   ` Jonathan Cameron
2024-05-29 13:34  1% ` [PATCH v10 12/19] arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entry Jonathan Cameron
2024-05-29 13:34  1%   ` Jonathan Cameron
2024-05-29 13:34  4% ` [PATCH v10 14/19] irqchip/gic-v3: Add support for ACPI's disabled but 'online capable' CPUs Jonathan Cameron
2024-05-29 13:34  4%   ` Jonathan Cameron
2024-05-29 13:36  4% [PATCH] doc: Add UEFI supplement document Jiaxun Yang

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.