From: Kane-Chen-AS <kane_chen@aspeedtech.com>
Connect the AST1700 interrupt lines to the GIC in AST27X0, enabling
the propagation of AST1700-originated interrupts to the host SoC.
This patch does not implement interrupt sources in AST1700 itself,
only the wiring into AST27X0.
Signed-off-by: Kane-Chen-AS <kane_chen@aspeedtech.com>
---
include/hw/arm/aspeed_soc.h | 6 +++-
include/hw/intc/aspeed_intc.h | 2 ++
hw/arm/aspeed_ast27x0.c | 37 +++++++++++++++++++++
hw/intc/aspeed_intc.c | 60 +++++++++++++++++++++++++++++++++++
4 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
index f19bab3457..b051d0eb3a 100644
--- a/include/hw/arm/aspeed_soc.h
+++ b/include/hw/arm/aspeed_soc.h
@@ -58,6 +58,7 @@
#define ASPEED_UARTS_NUM 13
#define ASPEED_JTAG_NUM 2
#define ASPEED_PCIE_NUM 3
+#define ASPEED_INTC_NUM 2
#define ASPEED_IOEXP_NUM 2
struct AspeedSoCState {
@@ -146,7 +147,8 @@ struct Aspeed27x0SoCState {
AspeedSoCState parent;
ARMCPU cpu[ASPEED_CPUS_NUM];
- AspeedINTCState intc[2];
+ AspeedINTCState intc[ASPEED_INTC_NUM];
+ AspeedINTCState intcioexp[ASPEED_IOEXP_NUM];
GICv3State gic;
MemoryRegion dram_empty;
};
@@ -288,6 +290,8 @@ enum {
ASPEED_DEV_LTPI_CTRL2,
ASPEED_DEV_LTPI_IO0,
ASPEED_DEV_LTPI_IO1,
+ ASPEED_DEV_IOEXP0_INTCIO,
+ ASPEED_DEV_IOEXP1_INTCIO,
};
const char *aspeed_soc_cpu_type(const char * const *valid_cpu_types);
diff --git a/include/hw/intc/aspeed_intc.h b/include/hw/intc/aspeed_intc.h
index 51288384a5..4565bbab84 100644
--- a/include/hw/intc/aspeed_intc.h
+++ b/include/hw/intc/aspeed_intc.h
@@ -15,6 +15,8 @@
#define TYPE_ASPEED_INTC "aspeed.intc"
#define TYPE_ASPEED_2700_INTC TYPE_ASPEED_INTC "-ast2700"
#define TYPE_ASPEED_2700_INTCIO TYPE_ASPEED_INTC "io-ast2700"
+#define TYPE_ASPEED_2700_INTCIOEXP1 TYPE_ASPEED_INTC "ast2700-ioexp1"
+#define TYPE_ASPEED_2700_INTCIOEXP2 TYPE_ASPEED_INTC "ast2700-ioexp2"
#define TYPE_ASPEED_2700SSP_INTC TYPE_ASPEED_INTC "-ast2700ssp"
#define TYPE_ASPEED_2700SSP_INTCIO TYPE_ASPEED_INTC "io-ast2700ssp"
#define TYPE_ASPEED_2700TSP_INTC TYPE_ASPEED_INTC "-ast2700tsp"
diff --git a/hw/arm/aspeed_ast27x0.c b/hw/arm/aspeed_ast27x0.c
index de39a3e7eb..678d4eb6d9 100644
--- a/hw/arm/aspeed_ast27x0.c
+++ b/hw/arm/aspeed_ast27x0.c
@@ -91,7 +91,9 @@ static const hwaddr aspeed_soc_ast2700_memmap[] = {
[ASPEED_DEV_LTPI_CTRL2] = 0x14C35000,
[ASPEED_DEV_WDT] = 0x14C37000,
[ASPEED_DEV_LTPI_IO0] = 0x30000000,
+ [ASPEED_DEV_IOEXP0_INTCIO] = 0x30C18000,
[ASPEED_DEV_LTPI_IO1] = 0x50000000,
+ [ASPEED_DEV_IOEXP1_INTCIO] = 0x50C18000,
[ASPEED_DEV_PCIE_MMIO0] = 0x60000000,
[ASPEED_DEV_PCIE_MMIO1] = 0x80000000,
[ASPEED_DEV_PCIE_MMIO2] = 0xA0000000,
@@ -511,6 +513,10 @@ static void aspeed_soc_ast2700_init(Object *obj)
object_initialize_child(obj, "intc", &a->intc[0], TYPE_ASPEED_2700_INTC);
object_initialize_child(obj, "intcio", &a->intc[1],
TYPE_ASPEED_2700_INTCIO);
+ object_initialize_child(obj, "intcioexp0", &a->intcioexp[0],
+ TYPE_ASPEED_2700_INTCIOEXP1);
+ object_initialize_child(obj, "intcioexp1", &a->intcioexp[1],
+ TYPE_ASPEED_2700_INTCIOEXP2);
snprintf(typename, sizeof(typename), "aspeed.adc-%s", socname);
object_initialize_child(obj, "adc", &s->adc, typename);
@@ -755,6 +761,22 @@ static void aspeed_soc_ast2700_realize(DeviceState *dev, Error **errp)
aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intc[1]), 0,
sc->memmap[ASPEED_DEV_INTCIO]);
+ /* INTCIOEXP0 */
+ if (!sysbus_realize(SYS_BUS_DEVICE(&a->intcioexp[0]), errp)) {
+ return;
+ }
+
+ aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intcioexp[0]), 0,
+ sc->memmap[ASPEED_DEV_IOEXP0_INTCIO]);
+
+ /* INTCIOEXP1 */
+ if (!sysbus_realize(SYS_BUS_DEVICE(&a->intcioexp[1]), errp)) {
+ return;
+ }
+
+ aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intcioexp[1]), 0,
+ sc->memmap[ASPEED_DEV_IOEXP1_INTCIO]);
+
/* irq sources -> orgates -> INTC */
for (i = 0; i < ic->num_inpins; i++) {
qdev_connect_gpio_out(DEVICE(&a->intc[0].orgates[i]), 0,
@@ -1079,6 +1101,21 @@ static void aspeed_soc_ast2700_realize(DeviceState *dev, Error **errp)
}
sysbus_mmio_map(SYS_BUS_DEVICE(&s->ioexp[i]), 0,
sc->memmap[ASPEED_DEV_LTPI_IO0 + i]);
+
+ icio = ASPEED_INTC_GET_CLASS(&a->intcioexp[i]);
+ /* INTC_IOEXP internal: orgate[i] -> input[i] */
+ for (int j = 0; j < icio->num_inpins; j++) {
+ irq = qdev_get_gpio_in(DEVICE(&a->intcioexp[i]), j);
+ qdev_connect_gpio_out(DEVICE(&a->intcioexp[i].orgates[j]), 0,
+ irq);
+ }
+
+ /* INTC_IOEXP output[i] -> INTC0.orgate[0].input[i] */
+ for (int j = 0; j < icio->num_outpins; j++) {
+ irq = qdev_get_gpio_in(DEVICE(&a->intc[0].orgates[0]), j);
+ sysbus_connect_irq(SYS_BUS_DEVICE(&a->intcioexp[i]), j,
+ irq);
+ }
}
aspeed_mmio_map_unimplemented(s->memory, SYS_BUS_DEVICE(&s->dpmcu),
diff --git a/hw/intc/aspeed_intc.c b/hw/intc/aspeed_intc.c
index 5cd786dee6..a04005ee7c 100644
--- a/hw/intc/aspeed_intc.c
+++ b/hw/intc/aspeed_intc.c
@@ -924,6 +924,64 @@ static const TypeInfo aspeed_2700_intc_info = {
.class_init = aspeed_2700_intc_class_init,
};
+static AspeedINTCIRQ aspeed_2700_intcioexp2_irqs[ASPEED_INTC_MAX_INPINS] = {
+ {0, 8, 1, R_GICINT192_EN, R_GICINT192_STATUS},
+ {1, 9, 1, R_GICINT193_EN, R_GICINT193_STATUS},
+};
+
+static void aspeed_2700_intcioexp2_class_init(ObjectClass *klass,
+ const void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ AspeedINTCClass *aic = ASPEED_INTC_CLASS(klass);
+
+ dc->desc = "ASPEED 2700 IOEXP2 INTC Controller";
+ aic->num_lines = 32;
+ aic->num_inpins = 2;
+ aic->num_outpins = 10;
+ aic->mem_size = 0x400;
+ aic->nr_regs = 0x58 >> 2;
+ aic->reg_offset = 0x100;
+ aic->reg_ops = &aspeed_intcio_ops;
+ aic->irq_table = aspeed_2700_intcioexp2_irqs;
+ aic->irq_table_count = ARRAY_SIZE(aspeed_2700_intcioexp2_irqs);
+}
+
+static const TypeInfo aspeed_2700_intcioexp2_info = {
+ .name = TYPE_ASPEED_2700_INTCIOEXP2,
+ .parent = TYPE_ASPEED_INTC,
+ .class_init = aspeed_2700_intcioexp2_class_init,
+};
+
+static AspeedINTCIRQ aspeed_2700_intcioexp1_irqs[ASPEED_INTC_MAX_INPINS] = {
+ {0, 6, 1, R_GICINT192_EN, R_GICINT192_STATUS},
+ {1, 7, 1, R_GICINT193_EN, R_GICINT193_STATUS},
+};
+
+static void aspeed_2700_intcioexp1_class_init(ObjectClass *klass,
+ const void *data)
+{
+ DeviceClass *dc = DEVICE_CLASS(klass);
+ AspeedINTCClass *aic = ASPEED_INTC_CLASS(klass);
+
+ dc->desc = "ASPEED 2700 IOEXP1 INTC Controller";
+ aic->num_lines = 32;
+ aic->num_inpins = 2;
+ aic->num_outpins = 10;
+ aic->mem_size = 0x400;
+ aic->nr_regs = 0x58 >> 2;
+ aic->reg_offset = 0x100;
+ aic->reg_ops = &aspeed_intcio_ops;
+ aic->irq_table = aspeed_2700_intcioexp1_irqs;
+ aic->irq_table_count = ARRAY_SIZE(aspeed_2700_intcioexp1_irqs);
+}
+
+static const TypeInfo aspeed_2700_intcioexp1_info = {
+ .name = TYPE_ASPEED_2700_INTCIOEXP1,
+ .parent = TYPE_ASPEED_INTC,
+ .class_init = aspeed_2700_intcioexp1_class_init,
+};
+
static AspeedINTCIRQ aspeed_2700_intcio_irqs[ASPEED_INTC_MAX_INPINS] = {
{0, 0, 1, R_GICINT192_EN, R_GICINT192_STATUS},
{1, 1, 1, R_GICINT193_EN, R_GICINT193_STATUS},
@@ -1099,6 +1157,8 @@ static void aspeed_intc_register_types(void)
type_register_static(&aspeed_intc_info);
type_register_static(&aspeed_2700_intc_info);
type_register_static(&aspeed_2700_intcio_info);
+ type_register_static(&aspeed_2700_intcioexp1_info);
+ type_register_static(&aspeed_2700_intcioexp2_info);
type_register_static(&aspeed_2700ssp_intc_info);
type_register_static(&aspeed_2700ssp_intcio_info);
type_register_static(&aspeed_2700tsp_intc_info);
--
2.43.0On 12/24/25 02:41, Kane Chen via wrote:
> From: Kane-Chen-AS <kane_chen@aspeedtech.com>
>
> Connect the AST1700 interrupt lines to the GIC in AST27X0, enabling
> the propagation of AST1700-originated interrupts to the host SoC.
>
> This patch does not implement interrupt sources in AST1700 itself,
> only the wiring into AST27X0.
>
> Signed-off-by: Kane-Chen-AS <kane_chen@aspeedtech.com>
> ---
> include/hw/arm/aspeed_soc.h | 6 +++-
> include/hw/intc/aspeed_intc.h | 2 ++
> hw/arm/aspeed_ast27x0.c | 37 +++++++++++++++++++++
> hw/intc/aspeed_intc.c | 60 +++++++++++++++++++++++++++++++++++
> 4 files changed, 104 insertions(+), 1 deletion(-)
>
> diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
> index f19bab3457..b051d0eb3a 100644
> --- a/include/hw/arm/aspeed_soc.h
> +++ b/include/hw/arm/aspeed_soc.h
> @@ -58,6 +58,7 @@
> #define ASPEED_UARTS_NUM 13
> #define ASPEED_JTAG_NUM 2
> #define ASPEED_PCIE_NUM 3
> +#define ASPEED_INTC_NUM 2
> #define ASPEED_IOEXP_NUM 2
>
> struct AspeedSoCState {
> @@ -146,7 +147,8 @@ struct Aspeed27x0SoCState {
> AspeedSoCState parent;
>
> ARMCPU cpu[ASPEED_CPUS_NUM];
> - AspeedINTCState intc[2];
> + AspeedINTCState intc[ASPEED_INTC_NUM];
> + AspeedINTCState intcioexp[ASPEED_IOEXP_NUM];
> GICv3State gic;
> MemoryRegion dram_empty;
> };
> @@ -288,6 +290,8 @@ enum {
> ASPEED_DEV_LTPI_CTRL2,
> ASPEED_DEV_LTPI_IO0,
> ASPEED_DEV_LTPI_IO1,
> + ASPEED_DEV_IOEXP0_INTCIO,
> + ASPEED_DEV_IOEXP1_INTCIO,
> };
>
> const char *aspeed_soc_cpu_type(const char * const *valid_cpu_types);
> diff --git a/include/hw/intc/aspeed_intc.h b/include/hw/intc/aspeed_intc.h
> index 51288384a5..4565bbab84 100644
> --- a/include/hw/intc/aspeed_intc.h
> +++ b/include/hw/intc/aspeed_intc.h
> @@ -15,6 +15,8 @@
> #define TYPE_ASPEED_INTC "aspeed.intc"
> #define TYPE_ASPEED_2700_INTC TYPE_ASPEED_INTC "-ast2700"
> #define TYPE_ASPEED_2700_INTCIO TYPE_ASPEED_INTC "io-ast2700"
> +#define TYPE_ASPEED_2700_INTCIOEXP1 TYPE_ASPEED_INTC "ast2700-ioexp1"
Adding a leading dash would improve readability
... TYPE_ASPEED_INTC "-ast2700-ioexp1"
> +#define TYPE_ASPEED_2700_INTCIOEXP2 TYPE_ASPEED_INTC "ast2700-ioexp2"
same here ^
> #define TYPE_ASPEED_2700SSP_INTC TYPE_ASPEED_INTC "-ast2700ssp"
> #define TYPE_ASPEED_2700SSP_INTCIO TYPE_ASPEED_INTC "io-ast2700ssp"
> #define TYPE_ASPEED_2700TSP_INTC TYPE_ASPEED_INTC "-ast2700tsp"
> diff --git a/hw/arm/aspeed_ast27x0.c b/hw/arm/aspeed_ast27x0.c
> index de39a3e7eb..678d4eb6d9 100644
> --- a/hw/arm/aspeed_ast27x0.c
> +++ b/hw/arm/aspeed_ast27x0.c
> @@ -91,7 +91,9 @@ static const hwaddr aspeed_soc_ast2700_memmap[] = {
> [ASPEED_DEV_LTPI_CTRL2] = 0x14C35000,
> [ASPEED_DEV_WDT] = 0x14C37000,
> [ASPEED_DEV_LTPI_IO0] = 0x30000000,
> + [ASPEED_DEV_IOEXP0_INTCIO] = 0x30C18000,
> [ASPEED_DEV_LTPI_IO1] = 0x50000000,
> + [ASPEED_DEV_IOEXP1_INTCIO] = 0x50C18000,
> [ASPEED_DEV_PCIE_MMIO0] = 0x60000000,
> [ASPEED_DEV_PCIE_MMIO1] = 0x80000000,
> [ASPEED_DEV_PCIE_MMIO2] = 0xA0000000,
> @@ -511,6 +513,10 @@ static void aspeed_soc_ast2700_init(Object *obj)
> object_initialize_child(obj, "intc", &a->intc[0], TYPE_ASPEED_2700_INTC);
> object_initialize_child(obj, "intcio", &a->intc[1],
> TYPE_ASPEED_2700_INTCIO);
> + object_initialize_child(obj, "intcioexp0", &a->intcioexp[0],
"intc-ioexp0" reads better,
> + TYPE_ASPEED_2700_INTCIOEXP1);
> + object_initialize_child(obj, "intcioexp1", &a->intcioexp[1],
and "intc-ioexp1" too.
I can fix the naming if you agree.
Thanks,
C.
> + TYPE_ASPEED_2700_INTCIOEXP2);
>
> snprintf(typename, sizeof(typename), "aspeed.adc-%s", socname);
> object_initialize_child(obj, "adc", &s->adc, typename);
> @@ -755,6 +761,22 @@ static void aspeed_soc_ast2700_realize(DeviceState *dev, Error **errp)
> aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intc[1]), 0,
> sc->memmap[ASPEED_DEV_INTCIO]);
>
> + /* INTCIOEXP0 */
> + if (!sysbus_realize(SYS_BUS_DEVICE(&a->intcioexp[0]), errp)) {
> + return;
> + }
> +
> + aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intcioexp[0]), 0,
> + sc->memmap[ASPEED_DEV_IOEXP0_INTCIO]);
> +
> + /* INTCIOEXP1 */
> + if (!sysbus_realize(SYS_BUS_DEVICE(&a->intcioexp[1]), errp)) {
> + return;
> + }
> +
> + aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intcioexp[1]), 0,
> + sc->memmap[ASPEED_DEV_IOEXP1_INTCIO]);
> +
> /* irq sources -> orgates -> INTC */
> for (i = 0; i < ic->num_inpins; i++) {
> qdev_connect_gpio_out(DEVICE(&a->intc[0].orgates[i]), 0,
> @@ -1079,6 +1101,21 @@ static void aspeed_soc_ast2700_realize(DeviceState *dev, Error **errp)
> }
> sysbus_mmio_map(SYS_BUS_DEVICE(&s->ioexp[i]), 0,
> sc->memmap[ASPEED_DEV_LTPI_IO0 + i]);
> +
> + icio = ASPEED_INTC_GET_CLASS(&a->intcioexp[i]);
> + /* INTC_IOEXP internal: orgate[i] -> input[i] */
> + for (int j = 0; j < icio->num_inpins; j++) {
> + irq = qdev_get_gpio_in(DEVICE(&a->intcioexp[i]), j);
> + qdev_connect_gpio_out(DEVICE(&a->intcioexp[i].orgates[j]), 0,
> + irq);
> + }
> +
> + /* INTC_IOEXP output[i] -> INTC0.orgate[0].input[i] */
> + for (int j = 0; j < icio->num_outpins; j++) {
> + irq = qdev_get_gpio_in(DEVICE(&a->intc[0].orgates[0]), j);
> + sysbus_connect_irq(SYS_BUS_DEVICE(&a->intcioexp[i]), j,
> + irq);
> + }
> }
>
> aspeed_mmio_map_unimplemented(s->memory, SYS_BUS_DEVICE(&s->dpmcu),
> diff --git a/hw/intc/aspeed_intc.c b/hw/intc/aspeed_intc.c
> index 5cd786dee6..a04005ee7c 100644
> --- a/hw/intc/aspeed_intc.c
> +++ b/hw/intc/aspeed_intc.c
> @@ -924,6 +924,64 @@ static const TypeInfo aspeed_2700_intc_info = {
> .class_init = aspeed_2700_intc_class_init,
> };
>
> +static AspeedINTCIRQ aspeed_2700_intcioexp2_irqs[ASPEED_INTC_MAX_INPINS] = {
> + {0, 8, 1, R_GICINT192_EN, R_GICINT192_STATUS},
> + {1, 9, 1, R_GICINT193_EN, R_GICINT193_STATUS},
> +};
> +
> +static void aspeed_2700_intcioexp2_class_init(ObjectClass *klass,
> + const void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> + AspeedINTCClass *aic = ASPEED_INTC_CLASS(klass);
> +
> + dc->desc = "ASPEED 2700 IOEXP2 INTC Controller";
> + aic->num_lines = 32;
> + aic->num_inpins = 2;
> + aic->num_outpins = 10;
> + aic->mem_size = 0x400;
> + aic->nr_regs = 0x58 >> 2;
> + aic->reg_offset = 0x100;
> + aic->reg_ops = &aspeed_intcio_ops;
> + aic->irq_table = aspeed_2700_intcioexp2_irqs;
> + aic->irq_table_count = ARRAY_SIZE(aspeed_2700_intcioexp2_irqs);
> +}
> +
> +static const TypeInfo aspeed_2700_intcioexp2_info = {
> + .name = TYPE_ASPEED_2700_INTCIOEXP2,
> + .parent = TYPE_ASPEED_INTC,
> + .class_init = aspeed_2700_intcioexp2_class_init,
> +};
> +
> +static AspeedINTCIRQ aspeed_2700_intcioexp1_irqs[ASPEED_INTC_MAX_INPINS] = {
> + {0, 6, 1, R_GICINT192_EN, R_GICINT192_STATUS},
> + {1, 7, 1, R_GICINT193_EN, R_GICINT193_STATUS},
> +};
> +
> +static void aspeed_2700_intcioexp1_class_init(ObjectClass *klass,
> + const void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> + AspeedINTCClass *aic = ASPEED_INTC_CLASS(klass);
> +
> + dc->desc = "ASPEED 2700 IOEXP1 INTC Controller";
> + aic->num_lines = 32;
> + aic->num_inpins = 2;
> + aic->num_outpins = 10;
> + aic->mem_size = 0x400;
> + aic->nr_regs = 0x58 >> 2;
> + aic->reg_offset = 0x100;
> + aic->reg_ops = &aspeed_intcio_ops;
> + aic->irq_table = aspeed_2700_intcioexp1_irqs;
> + aic->irq_table_count = ARRAY_SIZE(aspeed_2700_intcioexp1_irqs);
> +}
> +
> +static const TypeInfo aspeed_2700_intcioexp1_info = {
> + .name = TYPE_ASPEED_2700_INTCIOEXP1,
> + .parent = TYPE_ASPEED_INTC,
> + .class_init = aspeed_2700_intcioexp1_class_init,
> +};
> +
> static AspeedINTCIRQ aspeed_2700_intcio_irqs[ASPEED_INTC_MAX_INPINS] = {
> {0, 0, 1, R_GICINT192_EN, R_GICINT192_STATUS},
> {1, 1, 1, R_GICINT193_EN, R_GICINT193_STATUS},
> @@ -1099,6 +1157,8 @@ static void aspeed_intc_register_types(void)
> type_register_static(&aspeed_intc_info);
> type_register_static(&aspeed_2700_intc_info);
> type_register_static(&aspeed_2700_intcio_info);
> + type_register_static(&aspeed_2700_intcioexp1_info);
> + type_register_static(&aspeed_2700_intcioexp2_info);
> type_register_static(&aspeed_2700ssp_intc_info);
> type_register_static(&aspeed_2700ssp_intcio_info);
> type_register_static(&aspeed_2700tsp_intc_info);
> -----Original Message-----
> From: Cédric Le Goater <clg@kaod.org>
> Sent: Wednesday, December 24, 2025 6:58 PM
> To: Kane Chen <kane_chen@aspeedtech.com>; Peter Maydell
> <peter.maydell@linaro.org>; Steven Lee <steven_lee@aspeedtech.com>; Troy
> Lee <leetroy@gmail.com>; Jamin Lin <jamin_lin@aspeedtech.com>; Andrew
> Jeffery <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>;
> open list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC
> here <qemu-devel@nongnu.org>
> Cc: Troy Lee <troy_lee@aspeedtech.com>; nabihestefan@google.com
> Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt controller
> for AST1700
>
> On 12/24/25 02:41, Kane Chen via wrote:
> > From: Kane-Chen-AS <kane_chen@aspeedtech.com>
> >
> > Connect the AST1700 interrupt lines to the GIC in AST27X0, enabling
> > the propagation of AST1700-originated interrupts to the host SoC.
> >
> > This patch does not implement interrupt sources in AST1700 itself,
> > only the wiring into AST27X0.
> >
> > Signed-off-by: Kane-Chen-AS <kane_chen@aspeedtech.com>
> > ---
> > include/hw/arm/aspeed_soc.h | 6 +++-
> > include/hw/intc/aspeed_intc.h | 2 ++
> > hw/arm/aspeed_ast27x0.c | 37 +++++++++++++++++++++
> > hw/intc/aspeed_intc.c | 60
> +++++++++++++++++++++++++++++++++++
> > 4 files changed, 104 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
> > index f19bab3457..b051d0eb3a 100644
> > --- a/include/hw/arm/aspeed_soc.h
> > +++ b/include/hw/arm/aspeed_soc.h
> > @@ -58,6 +58,7 @@
> > #define ASPEED_UARTS_NUM 13
> > #define ASPEED_JTAG_NUM 2
> > #define ASPEED_PCIE_NUM 3
> > +#define ASPEED_INTC_NUM 2
> > #define ASPEED_IOEXP_NUM 2
> >
> > struct AspeedSoCState {
> > @@ -146,7 +147,8 @@ struct Aspeed27x0SoCState {
> > AspeedSoCState parent;
> >
> > ARMCPU cpu[ASPEED_CPUS_NUM];
> > - AspeedINTCState intc[2];
> > + AspeedINTCState intc[ASPEED_INTC_NUM];
> > + AspeedINTCState intcioexp[ASPEED_IOEXP_NUM];
> > GICv3State gic;
> > MemoryRegion dram_empty;
> > };
> > @@ -288,6 +290,8 @@ enum {
> > ASPEED_DEV_LTPI_CTRL2,
> > ASPEED_DEV_LTPI_IO0,
> > ASPEED_DEV_LTPI_IO1,
> > + ASPEED_DEV_IOEXP0_INTCIO,
> > + ASPEED_DEV_IOEXP1_INTCIO,
> > };
> >
> > const char *aspeed_soc_cpu_type(const char * const
> > *valid_cpu_types); diff --git a/include/hw/intc/aspeed_intc.h
> > b/include/hw/intc/aspeed_intc.h index 51288384a5..4565bbab84 100644
> > --- a/include/hw/intc/aspeed_intc.h
> > +++ b/include/hw/intc/aspeed_intc.h
> > @@ -15,6 +15,8 @@
> > #define TYPE_ASPEED_INTC "aspeed.intc"
> > #define TYPE_ASPEED_2700_INTC TYPE_ASPEED_INTC "-ast2700"
> > #define TYPE_ASPEED_2700_INTCIO TYPE_ASPEED_INTC "io-ast2700"
> > +#define TYPE_ASPEED_2700_INTCIOEXP1 TYPE_ASPEED_INTC
> "ast2700-ioexp1"
>
> Adding a leading dash would improve readability
>
> ... TYPE_ASPEED_INTC "-ast2700-ioexp1"
>
> > +#define TYPE_ASPEED_2700_INTCIOEXP2 TYPE_ASPEED_INTC
> "ast2700-ioexp2"
>
> same here ^
>
>
> > #define TYPE_ASPEED_2700SSP_INTC TYPE_ASPEED_INTC "-ast2700ssp"
> > #define TYPE_ASPEED_2700SSP_INTCIO TYPE_ASPEED_INTC
> "io-ast2700ssp"
> > #define TYPE_ASPEED_2700TSP_INTC TYPE_ASPEED_INTC "-ast2700tsp"
> > diff --git a/hw/arm/aspeed_ast27x0.c b/hw/arm/aspeed_ast27x0.c index
> > de39a3e7eb..678d4eb6d9 100644
> > --- a/hw/arm/aspeed_ast27x0.c
> > +++ b/hw/arm/aspeed_ast27x0.c
> > @@ -91,7 +91,9 @@ static const hwaddr aspeed_soc_ast2700_memmap[]
> = {
> > [ASPEED_DEV_LTPI_CTRL2] = 0x14C35000,
> > [ASPEED_DEV_WDT] = 0x14C37000,
> > [ASPEED_DEV_LTPI_IO0] = 0x30000000,
> > + [ASPEED_DEV_IOEXP0_INTCIO] = 0x30C18000,
> > [ASPEED_DEV_LTPI_IO1] = 0x50000000,
> > + [ASPEED_DEV_IOEXP1_INTCIO] = 0x50C18000,
> > [ASPEED_DEV_PCIE_MMIO0] = 0x60000000,
> > [ASPEED_DEV_PCIE_MMIO1] = 0x80000000,
> > [ASPEED_DEV_PCIE_MMIO2] = 0xA0000000, @@ -511,6 +513,10
> @@
> > static void aspeed_soc_ast2700_init(Object *obj)
> > object_initialize_child(obj, "intc", &a->intc[0],
> TYPE_ASPEED_2700_INTC);
> > object_initialize_child(obj, "intcio", &a->intc[1],
> > TYPE_ASPEED_2700_INTCIO);
> > + object_initialize_child(obj, "intcioexp0", &a->intcioexp[0],
>
> "intc-ioexp0" reads better,
>
> > + TYPE_ASPEED_2700_INTCIOEXP1);
> > + object_initialize_child(obj, "intcioexp1", &a->intcioexp[1],
>
> and "intc-ioexp1" too.
>
> I can fix the naming if you agree.
>
> Thanks,
>
> C.
Hi Cédric,
Thank you for the suggestion. Since I need to submit a v5 patch to split the I2C
code changes anyway, I will handle the naming adjustments and other minor fixes
myself in that version.
Thanks again for your feedback and review!
Best Regards,
Kane
>
> > + TYPE_ASPEED_2700_INTCIOEXP2);
> >
> > snprintf(typename, sizeof(typename), "aspeed.adc-%s", socname);
> > object_initialize_child(obj, "adc", &s->adc, typename); @@
> > -755,6 +761,22 @@ static void aspeed_soc_ast2700_realize(DeviceState
> *dev, Error **errp)
> > aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intc[1]), 0,
> > sc->memmap[ASPEED_DEV_INTCIO]);
> >
> > + /* INTCIOEXP0 */
> > + if (!sysbus_realize(SYS_BUS_DEVICE(&a->intcioexp[0]), errp)) {
> > + return;
> > + }
> > +
> > + aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intcioexp[0]),
> 0,
> > + sc->memmap[ASPEED_DEV_IOEXP0_INTCIO]);
> > +
> > + /* INTCIOEXP1 */
> > + if (!sysbus_realize(SYS_BUS_DEVICE(&a->intcioexp[1]), errp)) {
> > + return;
> > + }
> > +
> > + aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intcioexp[1]),
> 0,
> > + sc->memmap[ASPEED_DEV_IOEXP1_INTCIO]);
> > +
> > /* irq sources -> orgates -> INTC */
> > for (i = 0; i < ic->num_inpins; i++) {
> > qdev_connect_gpio_out(DEVICE(&a->intc[0].orgates[i]), 0, @@
> > -1079,6 +1101,21 @@ static void aspeed_soc_ast2700_realize(DeviceState
> *dev, Error **errp)
> > }
> > sysbus_mmio_map(SYS_BUS_DEVICE(&s->ioexp[i]), 0,
> > sc->memmap[ASPEED_DEV_LTPI_IO0 + i]);
> > +
> > + icio = ASPEED_INTC_GET_CLASS(&a->intcioexp[i]);
> > + /* INTC_IOEXP internal: orgate[i] -> input[i] */
> > + for (int j = 0; j < icio->num_inpins; j++) {
> > + irq = qdev_get_gpio_in(DEVICE(&a->intcioexp[i]), j);
> > + qdev_connect_gpio_out(DEVICE(&a->intcioexp[i].orgates[j]),
> 0,
> > + irq);
> > + }
> > +
> > + /* INTC_IOEXP output[i] -> INTC0.orgate[0].input[i] */
> > + for (int j = 0; j < icio->num_outpins; j++) {
> > + irq = qdev_get_gpio_in(DEVICE(&a->intc[0].orgates[0]), j);
> > + sysbus_connect_irq(SYS_BUS_DEVICE(&a->intcioexp[i]), j,
> > + irq);
> > + }
> > }
> >
> > aspeed_mmio_map_unimplemented(s->memory,
> > SYS_BUS_DEVICE(&s->dpmcu), diff --git a/hw/intc/aspeed_intc.c
> > b/hw/intc/aspeed_intc.c index 5cd786dee6..a04005ee7c 100644
> > --- a/hw/intc/aspeed_intc.c
> > +++ b/hw/intc/aspeed_intc.c
> > @@ -924,6 +924,64 @@ static const TypeInfo aspeed_2700_intc_info = {
> > .class_init = aspeed_2700_intc_class_init,
> > };
> >
> > +static AspeedINTCIRQ
> aspeed_2700_intcioexp2_irqs[ASPEED_INTC_MAX_INPINS] = {
> > + {0, 8, 1, R_GICINT192_EN, R_GICINT192_STATUS},
> > + {1, 9, 1, R_GICINT193_EN, R_GICINT193_STATUS}, };
> > +
> > +static void aspeed_2700_intcioexp2_class_init(ObjectClass *klass,
> > + const void *data)
> {
> > + DeviceClass *dc = DEVICE_CLASS(klass);
> > + AspeedINTCClass *aic = ASPEED_INTC_CLASS(klass);
> > +
> > + dc->desc = "ASPEED 2700 IOEXP2 INTC Controller";
> > + aic->num_lines = 32;
> > + aic->num_inpins = 2;
> > + aic->num_outpins = 10;
> > + aic->mem_size = 0x400;
> > + aic->nr_regs = 0x58 >> 2;
> > + aic->reg_offset = 0x100;
> > + aic->reg_ops = &aspeed_intcio_ops;
> > + aic->irq_table = aspeed_2700_intcioexp2_irqs;
> > + aic->irq_table_count = ARRAY_SIZE(aspeed_2700_intcioexp2_irqs);
> > +}
> > +
> > +static const TypeInfo aspeed_2700_intcioexp2_info = {
> > + .name = TYPE_ASPEED_2700_INTCIOEXP2,
> > + .parent = TYPE_ASPEED_INTC,
> > + .class_init = aspeed_2700_intcioexp2_class_init,
> > +};
> > +
> > +static AspeedINTCIRQ
> aspeed_2700_intcioexp1_irqs[ASPEED_INTC_MAX_INPINS] = {
> > + {0, 6, 1, R_GICINT192_EN, R_GICINT192_STATUS},
> > + {1, 7, 1, R_GICINT193_EN, R_GICINT193_STATUS}, };
> > +
> > +static void aspeed_2700_intcioexp1_class_init(ObjectClass *klass,
> > + const void *data)
> {
> > + DeviceClass *dc = DEVICE_CLASS(klass);
> > + AspeedINTCClass *aic = ASPEED_INTC_CLASS(klass);
> > +
> > + dc->desc = "ASPEED 2700 IOEXP1 INTC Controller";
> > + aic->num_lines = 32;
> > + aic->num_inpins = 2;
> > + aic->num_outpins = 10;
> > + aic->mem_size = 0x400;
> > + aic->nr_regs = 0x58 >> 2;
> > + aic->reg_offset = 0x100;
> > + aic->reg_ops = &aspeed_intcio_ops;
> > + aic->irq_table = aspeed_2700_intcioexp1_irqs;
> > + aic->irq_table_count = ARRAY_SIZE(aspeed_2700_intcioexp1_irqs);
> > +}
> > +
> > +static const TypeInfo aspeed_2700_intcioexp1_info = {
> > + .name = TYPE_ASPEED_2700_INTCIOEXP1,
> > + .parent = TYPE_ASPEED_INTC,
> > + .class_init = aspeed_2700_intcioexp1_class_init,
> > +};
> > +
> > static AspeedINTCIRQ
> aspeed_2700_intcio_irqs[ASPEED_INTC_MAX_INPINS] = {
> > {0, 0, 1, R_GICINT192_EN, R_GICINT192_STATUS},
> > {1, 1, 1, R_GICINT193_EN, R_GICINT193_STATUS}, @@ -1099,6
> > +1157,8 @@ static void aspeed_intc_register_types(void)
> > type_register_static(&aspeed_intc_info);
> > type_register_static(&aspeed_2700_intc_info);
> > type_register_static(&aspeed_2700_intcio_info);
> > + type_register_static(&aspeed_2700_intcioexp1_info);
> > + type_register_static(&aspeed_2700_intcioexp2_info);
> > type_register_static(&aspeed_2700ssp_intc_info);
> > type_register_static(&aspeed_2700ssp_intcio_info);
> > type_register_static(&aspeed_2700tsp_intc_info);
Hello Kane, > Thank you for the suggestion. Since I need to submit a v5 patch to split the I2C > code changes anyway, Can you please introduce the bus label property at the end of the patch series ? Please consider adding a functional test and updating the documentation too. > I will handle the naming adjustments and other minor fixes > myself in that version. Thanks, C.
> -----Original Message----- > From: Cédric Le Goater <clg@kaod.org> > Sent: Sunday, December 28, 2025 1:51 AM > To: Kane Chen <kane_chen@aspeedtech.com>; Peter Maydell > <peter.maydell@linaro.org>; Steven Lee <steven_lee@aspeedtech.com>; Troy > Lee <leetroy@gmail.com>; Jamin Lin <jamin_lin@aspeedtech.com>; Andrew > Jeffery <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>; > open list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC > here <qemu-devel@nongnu.org> > Cc: Troy Lee <troy_lee@aspeedtech.com>; nabihestefan@google.com > Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt controller > for AST1700 > > Hello Kane, > > > Thank you for the suggestion. Since I need to submit a v5 patch to > > split the I2C code changes anyway, > > Can you please introduce the bus label property at the end of the patch series ? > Please consider adding a functional test and updating the documentation too. > > > I will handle the naming adjustments and other minor fixes myself in > > that version. > > Thanks, > > C. Hi Cédric, If I move the bus label property to the end of this patch series, it will trigger a test failure in the current patch series. To avoid this, I plan to move the bus label changes into a separate patch series and submit it before the AST1700 series. I believe this approach ensures both series pass the tests properly. What are your thoughts on this? Best Regards, Kane
On 12/29/25 11:00, Kane Chen wrote: >> -----Original Message----- >> From: Cédric Le Goater <clg@kaod.org> >> Sent: Sunday, December 28, 2025 1:51 AM >> To: Kane Chen <kane_chen@aspeedtech.com>; Peter Maydell >> <peter.maydell@linaro.org>; Steven Lee <steven_lee@aspeedtech.com>; Troy >> Lee <leetroy@gmail.com>; Jamin Lin <jamin_lin@aspeedtech.com>; Andrew >> Jeffery <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>; >> open list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC >> here <qemu-devel@nongnu.org> >> Cc: Troy Lee <troy_lee@aspeedtech.com>; nabihestefan@google.com >> Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt controller >> for AST1700 >> >> Hello Kane, >> >>> Thank you for the suggestion. Since I need to submit a v5 patch to >>> split the I2C code changes anyway, >> >> Can you please introduce the bus label property at the end of the patch series ? >> Please consider adding a functional test and updating the documentation too. >> >>> I will handle the naming adjustments and other minor fixes myself in >>> that version. >> >> Thanks, >> >> C. > > Hi Cédric, > > If I move the bus label property to the end of this patch series, it will trigger > a test failure in the current patch series. Which test ? > To avoid this, I plan to move the bus > label changes into a separate patch series and submit it before the AST1700 > series. I believe this approach ensures both series pass the tests properly. > What are your thoughts on this? I would like to understand the issue first. Thanks, C.
+phil
On 12/29/25 12:41, Cédric Le Goater wrote:
> On 12/29/25 11:00, Kane Chen wrote:
>>> -----Original Message-----
>>> From: Cédric Le Goater <clg@kaod.org>
>>> Sent: Sunday, December 28, 2025 1:51 AM
>>> To: Kane Chen <kane_chen@aspeedtech.com>; Peter Maydell
>>> <peter.maydell@linaro.org>; Steven Lee <steven_lee@aspeedtech.com>; Troy
>>> Lee <leetroy@gmail.com>; Jamin Lin <jamin_lin@aspeedtech.com>; Andrew
>>> Jeffery <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>;
>>> open list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC
>>> here <qemu-devel@nongnu.org>
>>> Cc: Troy Lee <troy_lee@aspeedtech.com>; nabihestefan@google.com
>>> Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt controller
>>> for AST1700
>>>
>>> Hello Kane,
>>>
>>>> Thank you for the suggestion. Since I need to submit a v5 patch to
>>>> split the I2C code changes anyway,
>>>
>>> Can you please introduce the bus label property at the end of the patch series ?
>>> Please consider adding a functional test and updating the documentation too.
>>>
>>>> I will handle the naming adjustments and other minor fixes myself in
>>>> that version.
>>>
>>> Thanks,
>>>
>>> C.
>>
>> Hi Cédric,
>>
>> If I move the bus label property to the end of this patch series, it will trigger
>> a test failure in the current patch series.
>
> Which test ?
>
>> To avoid this, I plan to move the bus
>> label changes into a separate patch series and submit it before the AST1700
>> series. I believe this approach ensures both series pass the tests properly.
>> What are your thoughts on this?
>
> I would like to understand the issue first.
I see.
The AST2700 functional tests fail :
self.vm.add_args('-device',
'tmp105,bus=aspeed.i2c.bus.1,address=0x4d,id=tmp-test')
The "bus label" proposal renames the IO expander I2C buses (32) to avoid
the name conflicts :
/aspeed.ioexp0.i2c.bus.0 (i2c-bus)
...
/aspeed.ioexp0.i2c.bus.15 (i2c-bus)
/aspeed.ioexp1.i2c.bus.0 (i2c-bus)
...
/aspeed.ioexp1.i2c.bus.15 (i2c-bus)
Since this will be exposed in the user API, it would be best to avoid
introducing poorly chosen names. Having so many I2C buses (48) in a
single machine is somewhat new in QEMU and I am not aware of any naming
convention for this.
May be others do ?
Thanks,
C.
On Mon, Dec 29, 2025 at 8:51 AM Cédric Le Goater <clg@kaod.org> wrote:
>
> +phil
>
> On 12/29/25 12:41, Cédric Le Goater wrote:
> > On 12/29/25 11:00, Kane Chen wrote:
> >>> -----Original Message-----
> >>> From: Cédric Le Goater <clg@kaod.org>
> >>> Sent: Sunday, December 28, 2025 1:51 AM
> >>> To: Kane Chen <kane_chen@aspeedtech.com>; Peter Maydell
> >>> <peter.maydell@linaro.org>; Steven Lee <steven_lee@aspeedtech.com>; Troy
> >>> Lee <leetroy@gmail.com>; Jamin Lin <jamin_lin@aspeedtech.com>; Andrew
> >>> Jeffery <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>;
> >>> open list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC
> >>> here <qemu-devel@nongnu.org>
> >>> Cc: Troy Lee <troy_lee@aspeedtech.com>; nabihestefan@google.com
> >>> Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt controller
> >>> for AST1700
> >>>
> >>> Hello Kane,
> >>>
> >>>> Thank you for the suggestion. Since I need to submit a v5 patch to
> >>>> split the I2C code changes anyway,
> >>>
> >>> Can you please introduce the bus label property at the end of the patch series ?
> >>> Please consider adding a functional test and updating the documentation too.
> >>>
> >>>> I will handle the naming adjustments and other minor fixes myself in
> >>>> that version.
> >>>
> >>> Thanks,
> >>>
> >>> C.
> >>
> >> Hi Cédric,
> >>
> >> If I move the bus label property to the end of this patch series, it will trigger
> >> a test failure in the current patch series.
> >
> > Which test ?
> >
> >> To avoid this, I plan to move the bus
> >> label changes into a separate patch series and submit it before the AST1700
> >> series. I believe this approach ensures both series pass the tests properly.
> >> What are your thoughts on this?
> >
> > I would like to understand the issue first.
> I see.
>
> The AST2700 functional tests fail :
>
> self.vm.add_args('-device',
> 'tmp105,bus=aspeed.i2c.bus.1,address=0x4d,id=tmp-test')
>
> The "bus label" proposal renames the IO expander I2C buses (32) to avoid
> the name conflicts :
>
> /aspeed.ioexp0.i2c.bus.0 (i2c-bus)
> ...
> /aspeed.ioexp0.i2c.bus.15 (i2c-bus)
>
> /aspeed.ioexp1.i2c.bus.0 (i2c-bus)
> ...
> /aspeed.ioexp1.i2c.bus.15 (i2c-bus)
>
> Since this will be exposed in the user API, it would be best to avoid
> introducing poorly chosen names. Having so many I2C buses (48) in a
> single machine is somewhat new in QEMU and I am not aware of any naming
> convention for this.
>
> May be others do ?
>
> Thanks,
>
> C.
I'm not aware of any convention, but I'd argue the current naming with
the bus label makes sense. A i2c bus on the main machine is
"aspeed.i2c.bus.%d" which clearly makes it easy to differenciate but
see that the two busses are somehow related. Maybe it'd be worth
changing the `aspeed_i2c_class_init` to make this relation more
obvious by not using TYPE_ASPEED_I2C_BUS but use the string
explicitly?
Thanks,
Nabih
> -----Original Message-----
> From: Nabih Estefan <nabihestefan@google.com>
> Sent: Tuesday, December 30, 2025 3:36 AM
> To: Cédric Le Goater <clg@kaod.org>
> Cc: Kane Chen <kane_chen@aspeedtech.com>; Peter Maydell
> <peter.maydell@linaro.org>; Steven Lee <steven_lee@aspeedtech.com>; Troy
> Lee <leetroy@gmail.com>; Jamin Lin <jamin_lin@aspeedtech.com>; Andrew
> Jeffery <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>;
> open list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC
> here <qemu-devel@nongnu.org>; Troy Lee <troy_lee@aspeedtech.com>;
> Philippe Mathieu-Daudé <philmd@linaro.org>
> Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt controller
> for AST1700
>
> On Mon, Dec 29, 2025 at 8:51 AM Cédric Le Goater <clg@kaod.org> wrote:
> >
> > +phil
> >
> > On 12/29/25 12:41, Cédric Le Goater wrote:
> > > On 12/29/25 11:00, Kane Chen wrote:
> > >>> -----Original Message-----
> > >>> From: Cédric Le Goater <clg@kaod.org>
> > >>> Sent: Sunday, December 28, 2025 1:51 AM
> > >>> To: Kane Chen <kane_chen@aspeedtech.com>; Peter Maydell
> > >>> <peter.maydell@linaro.org>; Steven Lee
> > >>> <steven_lee@aspeedtech.com>; Troy Lee <leetroy@gmail.com>; Jamin
> > >>> Lin <jamin_lin@aspeedtech.com>; Andrew Jeffery
> > >>> <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>; open
> > >>> list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC
> > >>> here <qemu-devel@nongnu.org>
> > >>> Cc: Troy Lee <troy_lee@aspeedtech.com>; nabihestefan@google.com
> > >>> Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt
> > >>> controller for AST1700
> > >>>
> > >>> Hello Kane,
> > >>>
> > >>>> Thank you for the suggestion. Since I need to submit a v5 patch
> > >>>> to split the I2C code changes anyway,
> > >>>
> > >>> Can you please introduce the bus label property at the end of the patch
> series ?
> > >>> Please consider adding a functional test and updating the documentation
> too.
> > >>>
> > >>>> I will handle the naming adjustments and other minor fixes myself
> > >>>> in that version.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> C.
> > >>
> > >> Hi Cédric,
> > >>
> > >> If I move the bus label property to the end of this patch series,
> > >> it will trigger a test failure in the current patch series.
> > >
> > > Which test ?
> > >
> > >> To avoid this, I plan to move the bus label changes into a separate
> > >> patch series and submit it before the AST1700 series. I believe
> > >> this approach ensures both series pass the tests properly.
> > >> What are your thoughts on this?
> > >
> > > I would like to understand the issue first.
> > I see.
> >
> > The AST2700 functional tests fail :
> >
> > self.vm.add_args('-device',
> >
> > 'tmp105,bus=aspeed.i2c.bus.1,address=0x4d,id=tmp-test')
> >
> > The "bus label" proposal renames the IO expander I2C buses (32) to
> > avoid the name conflicts :
> >
> > /aspeed.ioexp0.i2c.bus.0 (i2c-bus)
> > ...
> > /aspeed.ioexp0.i2c.bus.15 (i2c-bus)
> >
> > /aspeed.ioexp1.i2c.bus.0 (i2c-bus)
> > ...
> > /aspeed.ioexp1.i2c.bus.15 (i2c-bus)
> >
> > Since this will be exposed in the user API, it would be best to avoid
> > introducing poorly chosen names. Having so many I2C buses (48) in a
> > single machine is somewhat new in QEMU and I am not aware of any
> > naming convention for this.
> >
> > May be others do ?
> >
> > Thanks,
> >
> > C.
>
> I'm not aware of any convention, but I'd argue the current naming with the bus
> label makes sense. A i2c bus on the main machine is "aspeed.i2c.bus.%d"
> which clearly makes it easy to differenciate but see that the two busses are
> somehow related. Maybe it'd be worth changing the `aspeed_i2c_class_init` to
> make this relation more obvious by not using TYPE_ASPEED_I2C_BUS but use
> the string explicitly?
>
> Thanks,
> Nabih
Hi Cédric,
Thanks for the additional information.
Hi all,
Currently, three devices in our setup support I2C.
1. BMC
2. IO expander 1
3. IO expander 2
Each device supports 16 I2C buses, and the bus indices for each device all start
from 0. This leads to naming conflicts under the current naming convention. While
we could extend the bus IDs from 16 to 47, doing so would require significant code
changes to handle different ID ranges, making the code harder to maintain.
Therefore, I believe using readable bus labels would be more intuitive for the user API.
If there are any existing conventions for this use case or if you have any concerns
regarding the use of bus labels, please let me know.
Best Regards,
Kane
Hello Kane, > Currently, three devices in our setup support I2C. > 1. BMC > 2. IO expander 1 > 3. IO expander 2 > > Each device supports 16 I2C buses, and the bus indices for each device all start > from 0. This leads to naming conflicts under the current naming convention. While > we could extend the bus IDs from 16 to 47, doing so would require significant code > changes to handle different ID ranges, making the code harder to maintain. > > Therefore, I believe using readable bus labels would be more intuitive for the user API. I tend to agree. > If there are any existing conventions for this use case or if you have any concerns > regarding the use of bus labels, please let me know. Could you please send us the contents of directory : /sys/bus/i2c/devices/ on a system with such IO expanders? preferably with some devices attached to the I2C buses. Thanks, C.
> -----Original Message----- > From: Cédric Le Goater <clg@kaod.org> > Sent: Tuesday, December 30, 2025 10:29 PM > To: Kane Chen <kane_chen@aspeedtech.com>; Nabih Estefan > <nabihestefan@google.com> > Cc: Peter Maydell <peter.maydell@linaro.org>; Steven Lee > <steven_lee@aspeedtech.com>; Troy Lee <leetroy@gmail.com>; Jamin Lin > <jamin_lin@aspeedtech.com>; Andrew Jeffery > <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>; open > list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC here > <qemu-devel@nongnu.org>; Troy Lee <troy_lee@aspeedtech.com>; Philippe > Mathieu-Daudé <philmd@linaro.org> > Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt controller > for AST1700 > > Hello Kane, > > > Currently, three devices in our setup support I2C. > > 1. BMC > > 2. IO expander 1 > > 3. IO expander 2 > > > > Each device supports 16 I2C buses, and the bus indices for each device > > all start from 0. This leads to naming conflicts under the current > > naming convention. While we could extend the bus IDs from 16 to 47, > > doing so would require significant code changes to handle different ID ranges, > making the code harder to maintain. > > > > Therefore, I believe using readable bus labels would be more intuitive for the > user API. > > I tend to agree. > > > If there are any existing conventions for this use case or if you have > > any concerns regarding the use of bus labels, please let me know. > > Could you please send us the contents of directory : > > /sys/bus/i2c/devices/ > > on a system with such IO expanders? preferably with some devices attached > to the I2C buses. > > Thanks, > > C. Hi Cédric, I'm afraid I cannot provide data from a physical platform on such short notice. Currently, my AST1700 board is malfunctioning, and our other unit is occupied with different tests. I am reaching out to colleagues to see if a spare is available. I've attached logs from a QEMU simulation, as the results are expected to be consistent with the actual hardware.. Since our EVB does not have I2C devices connected to these specific buses, I typically use the following command to create a dummy device for testing: echo slave-24c02 0x106c > /sys/bus/i2c/devices/i2c-16/new_device" System info: ls -l /sys/bus/i2c/devices/ lrwxrwxrwx 1 root root 0 Apr 3 2025 10-1010 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fb00.i2c-bus/i2c-10/10-1010 lrwxrwxrwx 1 root root 0 Dec 31 09:43 16-106c -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f100.i2c-bus/i2c-16/16-106c lrwxrwxrwx 1 root root 0 Apr 3 2025 8-1010 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0f900.i2c-bus/i2c-8/8-1010 lrwxrwxrwx 1 root root 0 Apr 3 2025 9-0050 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fa00.i2c-bus/i2c-9/9-0050 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-10 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fb00.i2c-bus/i2c-10 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-16 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f100.i2c-bus/i2c-16 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-17 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f200.i2c-bus/i2c-17 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-18 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f300.i2c-bus/i2c-18 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-19 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f400.i2c-bus/i2c-19 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-20 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f500.i2c-bus/i2c-20 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-21 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f600.i2c-bus/i2c-21 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-22 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f700.i2c-bus/i2c-22 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-23 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f800.i2c-bus/i2c-23 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-24 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f900.i2c-bus/i2c-24 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-25 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fa00.i2c-bus/i2c-25 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-26 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fb00.i2c-bus/i2c-26 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-27 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fc00.i2c-bus/i2c-27 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-28 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fd00.i2c-bus/i2c-28 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-29 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fe00.i2c-bus/i2c-29 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-30 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0ff00.i2c-bus/i2c-30 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-31 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c10000.i2c-bus/i2c-31 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-32 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f100.i2c-bus/i2c-32 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-33 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f200.i2c-bus/i2c-33 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-34 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f300.i2c-bus/i2c-34 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-35 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f400.i2c-bus/i2c-35 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-36 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f500.i2c-bus/i2c-36 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-37 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f600.i2c-bus/i2c-37 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-38 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f700.i2c-bus/i2c-38 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-39 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f800.i2c-bus/i2c-39 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-40 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f900.i2c-bus/i2c-40 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-41 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fa00.i2c-bus/i2c-41 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-42 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fb00.i2c-bus/i2c-42 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-43 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fc00.i2c-bus/i2c-43 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-44 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fd00.i2c-bus/i2c-44 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-45 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fe00.i2c-bus/i2c-45 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-46 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0ff00.i2c-bus/i2c-46 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-47 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c10000.i2c-bus/i2c-47 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-8 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0f900.i2c-bus/i2c-8 lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-9 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fa00.i2c-bus/i2c-9 Best Regards, Kane
Hello Kane, On 12/31/25 11:15, Kane Chen wrote: >> -----Original Message----- >> From: Cédric Le Goater <clg@kaod.org> >> Sent: Tuesday, December 30, 2025 10:29 PM >> To: Kane Chen <kane_chen@aspeedtech.com>; Nabih Estefan >> <nabihestefan@google.com> >> Cc: Peter Maydell <peter.maydell@linaro.org>; Steven Lee >> <steven_lee@aspeedtech.com>; Troy Lee <leetroy@gmail.com>; Jamin Lin >> <jamin_lin@aspeedtech.com>; Andrew Jeffery >> <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>; open >> list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC here >> <qemu-devel@nongnu.org>; Troy Lee <troy_lee@aspeedtech.com>; Philippe >> Mathieu-Daudé <philmd@linaro.org> >> Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt controller >> for AST1700 >> >> Hello Kane, >> >>> Currently, three devices in our setup support I2C. >>> 1. BMC >>> 2. IO expander 1 >>> 3. IO expander 2 >>> >>> Each device supports 16 I2C buses, and the bus indices for each device >>> all start from 0. This leads to naming conflicts under the current >>> naming convention. While we could extend the bus IDs from 16 to 47, >>> doing so would require significant code changes to handle different ID ranges, >> making the code harder to maintain. >>> >>> Therefore, I believe using readable bus labels would be more intuitive for the >> user API. >> >> I tend to agree. >> >>> If there are any existing conventions for this use case or if you have >>> any concerns regarding the use of bus labels, please let me know. >> >> Could you please send us the contents of directory : >> >> /sys/bus/i2c/devices/ >> >> on a system with such IO expanders? preferably with some devices attached >> to the I2C buses. >> >> Thanks, >> >> C. > > Hi Cédric, > > I'm afraid I cannot provide data from a physical platform on such short notice. > Currently, my AST1700 board is malfunctioning, and our other unit is occupied > with different tests. I am reaching out to colleagues to see if a spare is available. > > I've attached logs from a QEMU simulation, as the results are expected to be > consistent with the actual hardware.. Since our EVB does not have I2C devices > connected to these specific buses, I typically use the following command to > create a dummy device for testing: > echo slave-24c02 0x106c > /sys/bus/i2c/devices/i2c-16/new_device" Which command line did you use for the I2C backing device in QEMU ? Is there a specific FW image to use to enable the IO expanders ? > System info: > ls -l /sys/bus/i2c/devices/ > lrwxrwxrwx 1 root root 0 Apr 3 2025 10-1010 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fb00.i2c-bus/i2c-10/10-1010 > lrwxrwxrwx 1 root root 0 Dec 31 09:43 16-106c -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f100.i2c-bus/i2c-16/16-106c > lrwxrwxrwx 1 root root 0 Apr 3 2025 8-1010 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0f900.i2c-bus/i2c-8/8-1010 > lrwxrwxrwx 1 root root 0 Apr 3 2025 9-0050 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fa00.i2c-bus/i2c-9/9-0050 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-10 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fb00.i2c-bus/i2c-10 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-16 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f100.i2c-bus/i2c-16 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-17 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f200.i2c-bus/i2c-17 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-18 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f300.i2c-bus/i2c-18 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-19 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f400.i2c-bus/i2c-19 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-20 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f500.i2c-bus/i2c-20 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-21 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f600.i2c-bus/i2c-21 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-22 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f700.i2c-bus/i2c-22 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-23 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f800.i2c-bus/i2c-23 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-24 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f900.i2c-bus/i2c-24 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-25 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fa00.i2c-bus/i2c-25 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-26 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fb00.i2c-bus/i2c-26 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-27 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fc00.i2c-bus/i2c-27 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-28 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fd00.i2c-bus/i2c-28 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-29 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fe00.i2c-bus/i2c-29 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-30 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0ff00.i2c-bus/i2c-30 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-31 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c10000.i2c-bus/i2c-31 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-32 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f100.i2c-bus/i2c-32 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-33 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f200.i2c-bus/i2c-33 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-34 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f300.i2c-bus/i2c-34 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-35 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f400.i2c-bus/i2c-35 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-36 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f500.i2c-bus/i2c-36 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-37 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f600.i2c-bus/i2c-37 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-38 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f700.i2c-bus/i2c-38 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-39 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f800.i2c-bus/i2c-39 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-40 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f900.i2c-bus/i2c-40 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-41 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fa00.i2c-bus/i2c-41 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-42 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fb00.i2c-bus/i2c-42 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-43 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fc00.i2c-bus/i2c-43 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-44 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fd00.i2c-bus/i2c-44 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-45 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fe00.i2c-bus/i2c-45 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-46 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0ff00.i2c-bus/i2c-46 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-47 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c10000.i2c-bus/i2c-47 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-8 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0f900.i2c-bus/i2c-8 > lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-9 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fa00.i2c-bus/i2c-9 Could we order the I2C buses the same way in QEMU ? Thanks, C.
On 12/31/25 12:49, Cédric Le Goater wrote:
> Hello Kane,
>
> On 12/31/25 11:15, Kane Chen wrote:
>>> -----Original Message-----
>>> From: Cédric Le Goater <clg@kaod.org>
>>> Sent: Tuesday, December 30, 2025 10:29 PM
>>> To: Kane Chen <kane_chen@aspeedtech.com>; Nabih Estefan
>>> <nabihestefan@google.com>
>>> Cc: Peter Maydell <peter.maydell@linaro.org>; Steven Lee
>>> <steven_lee@aspeedtech.com>; Troy Lee <leetroy@gmail.com>; Jamin Lin
>>> <jamin_lin@aspeedtech.com>; Andrew Jeffery
>>> <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>; open
>>> list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC here
>>> <qemu-devel@nongnu.org>; Troy Lee <troy_lee@aspeedtech.com>; Philippe
>>> Mathieu-Daudé <philmd@linaro.org>
>>> Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt controller
>>> for AST1700
>>>
>>> Hello Kane,
>>>
>>>> Currently, three devices in our setup support I2C.
>>>> 1. BMC
>>>> 2. IO expander 1
>>>> 3. IO expander 2
>>>>
>>>> Each device supports 16 I2C buses, and the bus indices for each device
>>>> all start from 0. This leads to naming conflicts under the current
>>>> naming convention. While we could extend the bus IDs from 16 to 47,
>>>> doing so would require significant code changes to handle different ID ranges,
>>> making the code harder to maintain.
>>>>
>>>> Therefore, I believe using readable bus labels would be more intuitive for the
>>> user API.
>>>
>>> I tend to agree.
>>>
>>>> If there are any existing conventions for this use case or if you have
>>>> any concerns regarding the use of bus labels, please let me know.
>>>
>>> Could you please send us the contents of directory :
>>>
>>> /sys/bus/i2c/devices/
>>>
>>> on a system with such IO expanders? preferably with some devices attached
>>> to the I2C buses.
>>>
>>> Thanks,
>>>
>>> C.
>>
>> Hi Cédric,
>>
>> I'm afraid I cannot provide data from a physical platform on such short notice.
>> Currently, my AST1700 board is malfunctioning, and our other unit is occupied
>> with different tests. I am reaching out to colleagues to see if a spare is available.
>>
>> I've attached logs from a QEMU simulation, as the results are expected to be
>> consistent with the actual hardware.. Since our EVB does not have I2C devices
>> connected to these specific buses, I typically use the following command to
>> create a dummy device for testing:
>> echo slave-24c02 0x106c > /sys/bus/i2c/devices/i2c-16/new_device"
>
> Which command line did you use for the I2C backing device in QEMU ?
>
> Is there a specific FW image to use to enable the IO expanders ?
>
>> System info:
>> ls -l /sys/bus/i2c/devices/
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 10-1010 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fb00.i2c-bus/i2c-10/10-1010
>> lrwxrwxrwx 1 root root 0 Dec 31 09:43 16-106c -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f100.i2c-bus/i2c-16/16-106c
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 8-1010 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0f900.i2c-bus/i2c-8/8-1010
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 9-0050 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fa00.i2c-bus/i2c-9/9-0050
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-10 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fb00.i2c-bus/i2c-10
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-16 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f100.i2c-bus/i2c-16
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-17 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f200.i2c-bus/i2c-17
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-18 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f300.i2c-bus/i2c-18
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-19 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f400.i2c-bus/i2c-19
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-20 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f500.i2c-bus/i2c-20
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-21 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f600.i2c-bus/i2c-21
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-22 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f700.i2c-bus/i2c-22
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-23 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f800.i2c-bus/i2c-23
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-24 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f900.i2c-bus/i2c-24
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-25 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fa00.i2c-bus/i2c-25
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-26 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fb00.i2c-bus/i2c-26
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-27 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fc00.i2c-bus/i2c-27
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-28 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fd00.i2c-bus/i2c-28
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-29 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fe00.i2c-bus/i2c-29
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-30 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0ff00.i2c-bus/i2c-30
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-31 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c10000.i2c-bus/i2c-31
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-32 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f100.i2c-bus/i2c-32
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-33 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f200.i2c-bus/i2c-33
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-34 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f300.i2c-bus/i2c-34
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-35 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f400.i2c-bus/i2c-35
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-36 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f500.i2c-bus/i2c-36
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-37 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f600.i2c-bus/i2c-37
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-38 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f700.i2c-bus/i2c-38
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-39 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f800.i2c-bus/i2c-39
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-40 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f900.i2c-bus/i2c-40
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-41 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fa00.i2c-bus/i2c-41
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-42 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fb00.i2c-bus/i2c-42
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-43 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fc00.i2c-bus/i2c-43
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-44 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fd00.i2c-bus/i2c-44
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-45 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fe00.i2c-bus/i2c-45
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-46 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0ff00.i2c-bus/i2c-46
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-47 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c10000.i2c-bus/i2c-47
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-8 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0f900.i2c-bus/i2c-8
>> lrwxrwxrwx 1 root root 0 Apr 3 2025 i2c-9 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fa00.i2c-bus/i2c-9
>
> Could we order the I2C buses the same way in QEMU ?
We would need to modify the bus creation in aspeed_i2c_bus_realize()
as follows :
s->bus = i2c_init_bus(dev, NULL);
and fix all tests.
Hmm, I am pondering the possible solutions.
C.
> -----Original Message----- > From: Cédric Le Goater <clg@kaod.org> > Sent: Saturday, January 3, 2026 12:32 AM > To: Kane Chen <kane_chen@aspeedtech.com>; Nabih Estefan > <nabihestefan@google.com> > Cc: Peter Maydell <peter.maydell@linaro.org>; Steven Lee > <steven_lee@aspeedtech.com>; Troy Lee <leetroy@gmail.com>; Jamin Lin > <jamin_lin@aspeedtech.com>; Andrew Jeffery > <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>; open > list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC here > <qemu-devel@nongnu.org>; Troy Lee <troy_lee@aspeedtech.com>; Philippe > Mathieu-Daudé <philmd@linaro.org> > Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt controller > for AST1700 > > On 12/31/25 12:49, Cédric Le Goater wrote: > > Hello Kane, > > > > On 12/31/25 11:15, Kane Chen wrote: > >>> -----Original Message----- > >>> From: Cédric Le Goater <clg@kaod.org> > >>> Sent: Tuesday, December 30, 2025 10:29 PM > >>> To: Kane Chen <kane_chen@aspeedtech.com>; Nabih Estefan > >>> <nabihestefan@google.com> > >>> Cc: Peter Maydell <peter.maydell@linaro.org>; Steven Lee > >>> <steven_lee@aspeedtech.com>; Troy Lee <leetroy@gmail.com>; Jamin > Lin > >>> <jamin_lin@aspeedtech.com>; Andrew Jeffery > >>> <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>; open > >>> list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC > >>> here <qemu-devel@nongnu.org>; Troy Lee <troy_lee@aspeedtech.com>; > >>> Philippe Mathieu-Daudé <philmd@linaro.org> > >>> Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt > >>> controller for AST1700 > >>> > >>> Hello Kane, > >>> > >>>> Currently, three devices in our setup support I2C. > >>>> 1. BMC > >>>> 2. IO expander 1 > >>>> 3. IO expander 2 > >>>> > >>>> Each device supports 16 I2C buses, and the bus indices for each > >>>> device all start from 0. This leads to naming conflicts under the > >>>> current naming convention. While we could extend the bus IDs from > >>>> 16 to 47, doing so would require significant code changes to handle > >>>> different ID ranges, > >>> making the code harder to maintain. > >>>> > >>>> Therefore, I believe using readable bus labels would be more > >>>> intuitive for the > >>> user API. > >>> > >>> I tend to agree. > >>> > >>>> If there are any existing conventions for this use case or if you > >>>> have any concerns regarding the use of bus labels, please let me know. > >>> > >>> Could you please send us the contents of directory : > >>> > >>> /sys/bus/i2c/devices/ > >>> > >>> on a system with such IO expanders? preferably with some devices > >>> attached to the I2C buses. > >>> > >>> Thanks, > >>> > >>> C. > >> > >> Hi Cédric, > >> > >> I'm afraid I cannot provide data from a physical platform on such short > notice. > >> Currently, my AST1700 board is malfunctioning, and our other unit is > >> occupied with different tests. I am reaching out to colleagues to see if a > spare is available. > >> > >> I've attached logs from a QEMU simulation, as the results are > >> expected to be consistent with the actual hardware.. Since our EVB > >> does not have I2C devices connected to these specific buses, I > >> typically use the following command to create a dummy device for testing: > >> echo slave-24c02 0x106c > /sys/bus/i2c/devices/i2c-16/new_device" > > > > Which command line did you use for the I2C backing device in QEMU ? I used the following command to test the LTPI feature. Note that no additional options were added specifically for the I2C devices; I am relying on the default machine model configuration: ./qemu-system-aarch64 -M ast2700a1-evb -nographic \ -device loader,addr=0x400000000,file=2700-img/u-boot.bin,force-raw=on \ -device loader,addr=0x430000000,file=2700-img/bl31.bin,force-raw=on \ -device loader,addr=0x430080000,file=2700-img/optee/tee-raw.bin,force-raw=on \ -device loader,addr=0x430000000,cpu-num=0 \ -device loader,addr=0x430000000,cpu-num=1 \ -device loader,addr=0x430000000,cpu-num=2 \ -device loader,addr=0x430000000,cpu-num=3 \ -drive file=2700-img/image-bmc,format=raw,if=mtd \ -net nic,macaddr=32:27:a1:12:01:01 \ -net nic,macaddr=32:27:a1:12:02:02 \ -net nic,macaddr=32:27:a1:12:03:03 \ -net user,hostfwd=:127.0.0.1:12222-:22,hostfwd=:127.0.0.1:12443-:443,hostfwd=udp:127.0.0.1:12623-:623,hostname=qemu \ -serial mon:stdio > > > > Is there a specific FW image to use to enable the IO expanders ? To enable the IO expanders, users could use the below DTS file to build the image https://github.com/AspeedTech-BMC/linux/blob/aspeed-master-v6.6/arch/arm64/boot/dts/aspeed/ast2700-dcscm_ast1700-evb.dts Or user could use the below image and switch the DTB in the uboot stage for enabling IO expanders. https://github.com/AspeedTech-BMC/openbmc/releases/download/v10.00/ast2700-a1-dcscm-obmc.tar.gz > > > >> System info: > >> ls -l /sys/bus/i2c/devices/ > >> lrwxrwxrwx 1 root root 0 Apr 3 2025 > 10-1010 -> > >> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/1 > 4c0 > >> fb00.i2c-bus/i2c-10/10-1010 lrwxrwxrwx 1 > root root > >> 0 Dec 31 09:43 16-106c -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0f100.i2c-bus/i2c-16/16-106c > >> lrwxrwxrwx 1 root root 0 Apr 3 2025 > 8-1010 -> > >> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/1 > 4c0 > >> f900.i2c-bus/i2c-8/8-1010 lrwxrwxrwx 1 > root root 0 > >> Apr 3 2025 9-0050 -> > >> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/1 > 4c0 > >> fa00.i2c-bus/i2c-9/9-0050 lrwxrwxrwx 1 > root root 0 > >> Apr 3 2025 i2c-10 -> > >> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/1 > 4c0 > >> fb00.i2c-bus/i2c-10 lrwxrwxrwx 1 > root root 0 Apr > >> 3 2025 i2c-16 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0f100.i2c-bus/i2c-16 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-17 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0f200.i2c-bus/i2c-17 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-18 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0f300.i2c-bus/i2c-18 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-19 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0f400.i2c-bus/i2c-19 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-20 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0f500.i2c-bus/i2c-20 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-21 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0f600.i2c-bus/i2c-21 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-22 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0f700.i2c-bus/i2c-22 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-23 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0f800.i2c-bus/i2c-23 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-24 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0f900.i2c-bus/i2c-24 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-25 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0fa00.i2c-bus/i2c-25 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-26 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0fb00.i2c-bus/i2c-26 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-27 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0fc00.i2c-bus/i2c-27 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-28 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0fd00.i2c-bus/i2c-28 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-29 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0fe00.i2c-bus/i2c-29 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-30 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c0ff00.i2c-bus/i2c-30 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-31 -> > >> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 3 > >> 0c0f000/30c10000.i2c-bus/i2c-31 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-32 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0f100.i2c-bus/i2c-32 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-33 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0f200.i2c-bus/i2c-33 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-34 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0f300.i2c-bus/i2c-34 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-35 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0f400.i2c-bus/i2c-35 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-36 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0f500.i2c-bus/i2c-36 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-37 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0f600.i2c-bus/i2c-37 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-38 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0f700.i2c-bus/i2c-38 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-39 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0f800.i2c-bus/i2c-39 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-40 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0f900.i2c-bus/i2c-40 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-41 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0fa00.i2c-bus/i2c-41 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-42 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0fb00.i2c-bus/i2c-42 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-43 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0fc00.i2c-bus/i2c-43 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-44 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0fd00.i2c-bus/i2c-44 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-45 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0fe00.i2c-bus/i2c-45 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-46 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c0ff00.i2c-bus/i2c-46 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-47 -> > >> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 5 > >> 0c0f000/50c10000.i2c-bus/i2c-47 lrwxrwxrwx 1 > root root > >> 0 Apr 3 2025 i2c-8 -> > >> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/1 > 4c0 > >> f900.i2c-bus/i2c-8 lrwxrwxrwx 1 root root 0 > Apr 3 > >> 2025 i2c-9 -> > >> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/1 > 4c0 > >> fa00.i2c-bus/i2c-9 > > > > Could we order the I2C buses the same way in QEMU ? Regarding your question about ordering the I2C buses in QEMU: if you mean aligning the QEMU object paths with the i2c-X naming convention used in the kernel, I believe that would be the most intuitive approach. I was able to access a functional AST1700 platform today and captured the actual bus states. Below is the output from the real hardware (using the same image as my previous QEMU log): ls -l /sys/bus/i2c/devices/ lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-12 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fd00.i2c-bus/i2c-12 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-13 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fe00.i2c-bus/i2c-13 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-16 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f100.i2c-bus/i2c-16 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-17 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f200.i2c-bus/i2c-17 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-18 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f300.i2c-bus/i2c-18 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-19 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f400.i2c-bus/i2c-19 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-20 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f500.i2c-bus/i2c-20 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-21 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f600.i2c-bus/i2c-21 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-22 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f700.i2c-bus/i2c-22 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-23 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f800.i2c-bus/i2c-23 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-24 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f900.i2c-bus/i2c-24 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-25 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fa00.i2c-bus/i2c-25 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-26 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fb00.i2c-bus/i2c-26 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-27 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fc00.i2c-bus/i2c-27 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-28 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fd00.i2c-bus/i2c-28 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-29 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fe00.i2c-bus/i2c-29 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-30 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0ff00.i2c-bus/i2c-30 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-31 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c10000.i2c-bus/i2c-31 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-32 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f100.i2c-bus/i2c-32 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-33 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f200.i2c-bus/i2c-33 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-34 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f300.i2c-bus/i2c-34 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-35 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f400.i2c-bus/i2c-35 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-36 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f500.i2c-bus/i2c-36 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-37 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f600.i2c-bus/i2c-37 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-38 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f700.i2c-bus/i2c-38 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-39 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f800.i2c-bus/i2c-39 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-40 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f900.i2c-bus/i2c-40 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-41 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fa00.i2c-bus/i2c-41 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-42 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fb00.i2c-bus/i2c-42 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-43 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fc00.i2c-bus/i2c-43 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-44 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fd00.i2c-bus/i2c-44 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-45 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fe00.i2c-bus/i2c-45 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-46 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0ff00.i2c-bus/i2c-46 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-47 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c10000.i2c-bus/i2c-47 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-48 -> ../../../devices/platform/soc@14000000/14c21000.i3c1/i2c-48 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-49 -> ../../../devices/platform/soc@14000000/14c23000.i3c3/i2c-49 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-50 -> ../../../devices/platform/soc@14000000/14c25000.i3c5/i2c-50 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-51 -> ../../../devices/platform/soc@14000000/14c27000.i3c7/i2c-51 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-52 -> ../../../devices/platform/soc@14000000/14c29000.i3c9/i2c-52 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-53 -> ../../../devices/platform/soc@14000000/14c2b000.i3c11/i2c-53 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-54 -> ../../../devices/platform/soc@14000000/14c2d000.i3c13/i2c-54 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-55 -> ../../../devices/platform/soc@14000000/14c2f000.i3c15/i2c-55 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-56 -> ../../../devices/platform/ltpi0_bus@30000000/30c21000.i3c1/i2c-56 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-57 -> ../../../devices/platform/ltpi0_bus@30000000/30c23000.i3c3/i2c-57 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-58 -> ../../../devices/platform/ltpi0_bus@30000000/30c25000.i3c5/i2c-58 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-59 -> ../../../devices/platform/ltpi0_bus@30000000/30c27000.i3c7/i2c-59 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-60 -> ../../../devices/platform/ltpi0_bus@30000000/30c29000.i3c9/i2c-60 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-61 -> ../../../devices/platform/ltpi0_bus@30000000/30c2b000.i3c11/i2c-61 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-62 -> ../../../devices/platform/ltpi0_bus@30000000/30c2d000.i3c13/i2c-62 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-63 -> ../../../devices/platform/ltpi0_bus@30000000/30c2f000.i3c15/i2c-63 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-64 -> ../../../devices/platform/ltpi1_bus@50000000/50c21000.i3c1/i2c-64 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-65 -> ../../../devices/platform/ltpi1_bus@50000000/50c23000.i3c3/i2c-65 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-66 -> ../../../devices/platform/ltpi1_bus@50000000/50c25000.i3c5/i2c-66 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-67 -> ../../../devices/platform/ltpi1_bus@50000000/50c27000.i3c7/i2c-67 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-68 -> ../../../devices/platform/ltpi1_bus@50000000/50c29000.i3c9/i2c-68 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-69 -> ../../../devices/platform/ltpi1_bus@50000000/50c2b000.i3c11/i2c-69 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-70 -> ../../../devices/platform/ltpi1_bus@50000000/50c2d000.i3c13/i2c-70 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-71 -> ../../../devices/platform/ltpi1_bus@50000000/50c2f000.i3c15/i2c-71 lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-8 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0f900.i2c-bus/i2c-8 As shown above, the real platform incorporates I2C buses via the LTPI (IO expander) and even through I3C controllers. Using a consistent i2c-X naming style across the model should sufficiently cover these use cases. > > We would need to modify the bus creation in aspeed_i2c_bus_realize() as > follows : > > s->bus = i2c_init_bus(dev, NULL); > > and fix all tests. Regarding your suggestion to modify aspeed_i2c_bus_realize() by passing NULL as the second argument to i2c_init_bus(): I have tested this change. It results in the following object hierarchy: BMC I2C: /i2c/bus[0]/i2c-bus.0 IOEXP0 (LTPI0): /ioexp[0]/ioexp-i2c[0]/bus[0]/i2c-bus.16 IOEXP1 (LTPI1): /ioexp[1]/ioexp-i2c[0]/bus[0]/i2c-bus.32 By adjusting the I2C object names this way, the naming conflicts are resolved, and the automated tests now pass correctly. Does this structure look acceptable to you, or would you prefer a different approach to bus indexing? > > Hmm, I am pondering the possible solutions. > > C.
Hello Kane, + Joe (for I3C) > I was able to access a functional AST1700 platform today and captured the actual > bus states. Below is the output from the real hardware (using the same image as > my previous QEMU log): > > ls -l /sys/bus/i2c/devices/ > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-12 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fd00.i2c-bus/i2c-12 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-13 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0fe00.i2c-bus/i2c-13 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-16 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f100.i2c-bus/i2c-16 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-17 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f200.i2c-bus/i2c-17 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-18 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f300.i2c-bus/i2c-18 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-19 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f400.i2c-bus/i2c-19 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-20 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f500.i2c-bus/i2c-20 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-21 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f600.i2c-bus/i2c-21 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-22 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f700.i2c-bus/i2c-22 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-23 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f800.i2c-bus/i2c-23 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-24 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0f900.i2c-bus/i2c-24 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-25 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fa00.i2c-bus/i2c-25 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-26 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fb00.i2c-bus/i2c-26 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-27 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fc00.i2c-bus/i2c-27 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-28 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fd00.i2c-bus/i2c-28 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-29 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0fe00.i2c-bus/i2c-29 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-30 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c0ff00.i2c-bus/i2c-30 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-31 -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@30c0f000/30c10000.i2c-bus/i2c-31 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-32 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f100.i2c-bus/i2c-32 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-33 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f200.i2c-bus/i2c-33 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-34 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f300.i2c-bus/i2c-34 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-35 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f400.i2c-bus/i2c-35 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-36 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f500.i2c-bus/i2c-36 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-37 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f600.i2c-bus/i2c-37 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-38 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f700.i2c-bus/i2c-38 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-39 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f800.i2c-bus/i2c-39 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-40 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0f900.i2c-bus/i2c-40 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-41 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fa00.i2c-bus/i2c-41 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-42 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fb00.i2c-bus/i2c-42 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-43 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fc00.i2c-bus/i2c-43 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-44 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fd00.i2c-bus/i2c-44 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-45 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0fe00.i2c-bus/i2c-45 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-46 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c0ff00.i2c-bus/i2c-46 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-47 -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@50c0f000/50c10000.i2c-bus/i2c-47 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-48 -> ../../../devices/platform/soc@14000000/14c21000.i3c1/i2c-48 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-49 -> ../../../devices/platform/soc@14000000/14c23000.i3c3/i2c-49 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-50 -> ../../../devices/platform/soc@14000000/14c25000.i3c5/i2c-50 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-51 -> ../../../devices/platform/soc@14000000/14c27000.i3c7/i2c-51 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-52 -> ../../../devices/platform/soc@14000000/14c29000.i3c9/i2c-52 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-53 -> ../../../devices/platform/soc@14000000/14c2b000.i3c11/i2c-53 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-54 -> ../../../devices/platform/soc@14000000/14c2d000.i3c13/i2c-54 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-55 -> ../../../devices/platform/soc@14000000/14c2f000.i3c15/i2c-55 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-56 -> ../../../devices/platform/ltpi0_bus@30000000/30c21000.i3c1/i2c-56 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-57 -> ../../../devices/platform/ltpi0_bus@30000000/30c23000.i3c3/i2c-57 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-58 -> ../../../devices/platform/ltpi0_bus@30000000/30c25000.i3c5/i2c-58 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-59 -> ../../../devices/platform/ltpi0_bus@30000000/30c27000.i3c7/i2c-59 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-60 -> ../../../devices/platform/ltpi0_bus@30000000/30c29000.i3c9/i2c-60 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-61 -> ../../../devices/platform/ltpi0_bus@30000000/30c2b000.i3c11/i2c-61 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-62 -> ../../../devices/platform/ltpi0_bus@30000000/30c2d000.i3c13/i2c-62 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-63 -> ../../../devices/platform/ltpi0_bus@30000000/30c2f000.i3c15/i2c-63 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-64 -> ../../../devices/platform/ltpi1_bus@50000000/50c21000.i3c1/i2c-64 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-65 -> ../../../devices/platform/ltpi1_bus@50000000/50c23000.i3c3/i2c-65 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-66 -> ../../../devices/platform/ltpi1_bus@50000000/50c25000.i3c5/i2c-66 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-67 -> ../../../devices/platform/ltpi1_bus@50000000/50c27000.i3c7/i2c-67 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-68 -> ../../../devices/platform/ltpi1_bus@50000000/50c29000.i3c9/i2c-68 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-69 -> ../../../devices/platform/ltpi1_bus@50000000/50c2b000.i3c11/i2c-69 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-70 -> ../../../devices/platform/ltpi1_bus@50000000/50c2d000.i3c13/i2c-70 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-71 -> ../../../devices/platform/ltpi1_bus@50000000/50c2f000.i3c15/i2c-71 > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-8 -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/14c0f900.i2c-bus/i2c-8 > > As shown above, the real platform incorporates I2C buses via the LTPI (IO expander) > and even through I3C controllers. Using a consistent i2c-X naming style across the > model should sufficiently cover these use cases. > >> >> We would need to modify the bus creation in aspeed_i2c_bus_realize() as >> follows : >> >> s->bus = i2c_init_bus(dev, NULL); >> >> and fix all tests. > > Regarding your suggestion to modify aspeed_i2c_bus_realize() by passing NULL as > the second argument to i2c_init_bus(): > I have tested this change. It results in the following object hierarchy: > > BMC I2C: /i2c/bus[0]/i2c-bus.0 > IOEXP0 (LTPI0): /ioexp[0]/ioexp-i2c[0]/bus[0]/i2c-bus.16 > IOEXP1 (LTPI1): /ioexp[1]/ioexp-i2c[0]/bus[0]/i2c-bus.32 > > By adjusting the I2C object names this way, the naming conflicts are resolved, and > the automated tests now pass correctly. Linux doesn’t order the I2C buses in a logical or physical sense. It numbers them dynamically as adapters are registered. The I3C device will add another group (SOC, LTPI0, LTP1, I3C) of I2C buses and devices. So, we need to find a way to distinguish these groups at the QEMU machine level to add devices on the right bus. Adding a "label" to the I2C bus model seems to be a step in the right direction. The idea needs time to mature. Insights are welcome. Thanks, C.
> -----Original Message----- > From: Cédric Le Goater <clg@kaod.org> > Sent: Monday, January 5, 2026 7:19 PM > To: Kane Chen <kane_chen@aspeedtech.com>; Nabih Estefan > <nabihestefan@google.com> > Cc: Peter Maydell <peter.maydell@linaro.org>; Steven Lee > <steven_lee@aspeedtech.com>; Troy Lee <leetroy@gmail.com>; Jamin Lin > <jamin_lin@aspeedtech.com>; Andrew Jeffery > <andrew@codeconstruct.com.au>; Joel Stanley <joel@jms.id.au>; open > list:ASPEED BMCs <qemu-arm@nongnu.org>; open list:All patches CC here > <qemu-devel@nongnu.org>; Troy Lee <troy_lee@aspeedtech.com>; Philippe > Mathieu-Daudé <philmd@linaro.org>; Joe Komlodi <komlodi@google.com> > Subject: Re: [PATCH v4 06/19] hw/arm/aspeed: Integrate interrupt controller > for AST1700 > > Hello Kane, > > + Joe (for I3C) > > > I was able to access a functional AST1700 platform today and captured > > the actual bus states. Below is the output from the real hardware > > (using the same image as my previous QEMU log): > > > > ls -l /sys/bus/i2c/devices/ > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-12 > -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/1 > 4c0fd00.i2c-bus/i2c-12 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-13 > -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/1 > 4c0fe00.i2c-bus/i2c-13 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-16 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0f100.i2c-bus/i2c-16 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-17 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0f200.i2c-bus/i2c-17 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-18 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0f300.i2c-bus/i2c-18 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-19 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0f400.i2c-bus/i2c-19 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-20 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0f500.i2c-bus/i2c-20 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-21 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0f600.i2c-bus/i2c-21 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-22 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0f700.i2c-bus/i2c-22 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-23 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0f800.i2c-bus/i2c-23 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-24 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0f900.i2c-bus/i2c-24 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-25 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0fa00.i2c-bus/i2c-25 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-26 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0fb00.i2c-bus/i2c-26 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-27 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0fc00.i2c-bus/i2c-27 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-28 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0fd00.i2c-bus/i2c-28 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-29 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0fe00.i2c-bus/i2c-29 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-30 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c0ff00.i2c-bus/i2c-30 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-31 > -> ../../../devices/platform/ltpi0_bus@30000000/ltpi0_bus@30000000:bus@ > 30c0f000/30c10000.i2c-bus/i2c-31 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-32 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0f100.i2c-bus/i2c-32 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-33 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0f200.i2c-bus/i2c-33 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-34 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0f300.i2c-bus/i2c-34 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-35 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0f400.i2c-bus/i2c-35 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-36 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0f500.i2c-bus/i2c-36 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-37 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0f600.i2c-bus/i2c-37 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-38 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0f700.i2c-bus/i2c-38 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-39 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0f800.i2c-bus/i2c-39 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-40 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0f900.i2c-bus/i2c-40 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-41 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0fa00.i2c-bus/i2c-41 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-42 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0fb00.i2c-bus/i2c-42 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-43 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0fc00.i2c-bus/i2c-43 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-44 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0fd00.i2c-bus/i2c-44 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-45 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0fe00.i2c-bus/i2c-45 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-46 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c0ff00.i2c-bus/i2c-46 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-47 > -> ../../../devices/platform/ltpi1_bus@50000000/ltpi1_bus@50000000:bus@ > 50c0f000/50c10000.i2c-bus/i2c-47 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-48 > -> ../../../devices/platform/soc@14000000/14c21000.i3c1/i2c-48 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-49 > -> ../../../devices/platform/soc@14000000/14c23000.i3c3/i2c-49 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-50 > -> ../../../devices/platform/soc@14000000/14c25000.i3c5/i2c-50 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-51 > -> ../../../devices/platform/soc@14000000/14c27000.i3c7/i2c-51 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-52 > -> ../../../devices/platform/soc@14000000/14c29000.i3c9/i2c-52 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-53 > -> ../../../devices/platform/soc@14000000/14c2b000.i3c11/i2c-53 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-54 > -> ../../../devices/platform/soc@14000000/14c2d000.i3c13/i2c-54 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-55 > -> ../../../devices/platform/soc@14000000/14c2f000.i3c15/i2c-55 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-56 > -> ../../../devices/platform/ltpi0_bus@30000000/30c21000.i3c1/i2c-56 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-57 > -> ../../../devices/platform/ltpi0_bus@30000000/30c23000.i3c3/i2c-57 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-58 > -> ../../../devices/platform/ltpi0_bus@30000000/30c25000.i3c5/i2c-58 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-59 > -> ../../../devices/platform/ltpi0_bus@30000000/30c27000.i3c7/i2c-59 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-60 > -> ../../../devices/platform/ltpi0_bus@30000000/30c29000.i3c9/i2c-60 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-61 > -> ../../../devices/platform/ltpi0_bus@30000000/30c2b000.i3c11/i2c-61 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-62 > -> ../../../devices/platform/ltpi0_bus@30000000/30c2d000.i3c13/i2c-62 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-63 > -> ../../../devices/platform/ltpi0_bus@30000000/30c2f000.i3c15/i2c-63 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-64 > -> ../../../devices/platform/ltpi1_bus@50000000/50c21000.i3c1/i2c-64 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-65 > -> ../../../devices/platform/ltpi1_bus@50000000/50c23000.i3c3/i2c-65 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-66 > -> ../../../devices/platform/ltpi1_bus@50000000/50c25000.i3c5/i2c-66 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-67 > -> ../../../devices/platform/ltpi1_bus@50000000/50c27000.i3c7/i2c-67 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-68 > -> ../../../devices/platform/ltpi1_bus@50000000/50c29000.i3c9/i2c-68 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-69 > -> ../../../devices/platform/ltpi1_bus@50000000/50c2b000.i3c11/i2c-69 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-70 > -> ../../../devices/platform/ltpi1_bus@50000000/50c2d000.i3c13/i2c-70 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-71 > -> ../../../devices/platform/ltpi1_bus@50000000/50c2f000.i3c15/i2c-71 > > lrwxrwxrwx 1 root root 0 Jan 5 07:24 i2c-8 > -> ../../../devices/platform/soc@14000000/soc@14000000:bus@14c0f000/1 > 4c0f900.i2c-bus/i2c-8 > > > > As shown above, the real platform incorporates I2C buses via the LTPI > > (IO expander) and even through I3C controllers. Using a consistent > > i2c-X naming style across the model should sufficiently cover these use > cases. > > > >> > >> We would need to modify the bus creation in aspeed_i2c_bus_realize() > >> as follows : > >> > >> s->bus = i2c_init_bus(dev, NULL); > >> > >> and fix all tests. > > > > Regarding your suggestion to modify aspeed_i2c_bus_realize() by > > passing NULL as the second argument to i2c_init_bus(): > > I have tested this change. It results in the following object hierarchy: > > > > BMC I2C: /i2c/bus[0]/i2c-bus.0 > > IOEXP0 (LTPI0): /ioexp[0]/ioexp-i2c[0]/bus[0]/i2c-bus.16 > > IOEXP1 (LTPI1): /ioexp[1]/ioexp-i2c[0]/bus[0]/i2c-bus.32 > > > > By adjusting the I2C object names this way, the naming conflicts are > > resolved, and the automated tests now pass correctly. > > Linux doesn’t order the I2C buses in a logical or physical sense. It numbers > them dynamically as adapters are registered. The I3C device will add another > group (SOC, LTPI0, LTP1, I3C) of I2C buses and devices. > > So, we need to find a way to distinguish these groups at the QEMU machine > level to add devices on the right bus. Adding a "label" to the I2C bus model > seems to be a step in the right direction. The idea needs time to mature. > Insights are welcome. > > Thanks, > > C. Hi Cédric, After syncing with the I3C driver owner, I've confirmed that i2c-56 is indeed a virtual adapter bridged via the I3C bus, as indicated by the sysfs entry: i2c-56 -> ../../../devices/platform/ltpi0_bus@30000000/30c21000.i3c1/i2c-56 This adapter is not a standalone I2C hardware controller. It is a virtual interface created by the I3C subsystem to forward I2C transactions to the I3C master driver, which then processes them using I3C-native logic and interrupts. This is standard Linux I3C framework behavior, where the virtual device is initialized via i3c_master_i2c_adapter_init during i3c_master_register. Given that these nodes are software-defined extensions rather than physical IP blocks, we can likely exclude this "I3C-virtual-I2C" case from the QEMU grouping logic. By focusing on the primary SOC and LTPI0/1 hardware groups instead, we can significantly simplify bus identification at the machine level. Best Regards, Kane
On 12/24/25 02:41, Kane Chen via wrote:
> From: Kane-Chen-AS <kane_chen@aspeedtech.com>
>
> Connect the AST1700 interrupt lines to the GIC in AST27X0, enabling
> the propagation of AST1700-originated interrupts to the host SoC.
>
> This patch does not implement interrupt sources in AST1700 itself,
> only the wiring into AST27X0.
>
> Signed-off-by: Kane-Chen-AS <kane_chen@aspeedtech.com>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Thanks,
C.
> ---
> include/hw/arm/aspeed_soc.h | 6 +++-
> include/hw/intc/aspeed_intc.h | 2 ++
> hw/arm/aspeed_ast27x0.c | 37 +++++++++++++++++++++
> hw/intc/aspeed_intc.c | 60 +++++++++++++++++++++++++++++++++++
> 4 files changed, 104 insertions(+), 1 deletion(-)
>
> diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
> index f19bab3457..b051d0eb3a 100644
> --- a/include/hw/arm/aspeed_soc.h
> +++ b/include/hw/arm/aspeed_soc.h
> @@ -58,6 +58,7 @@
> #define ASPEED_UARTS_NUM 13
> #define ASPEED_JTAG_NUM 2
> #define ASPEED_PCIE_NUM 3
> +#define ASPEED_INTC_NUM 2
> #define ASPEED_IOEXP_NUM 2
>
> struct AspeedSoCState {
> @@ -146,7 +147,8 @@ struct Aspeed27x0SoCState {
> AspeedSoCState parent;
>
> ARMCPU cpu[ASPEED_CPUS_NUM];
> - AspeedINTCState intc[2];
> + AspeedINTCState intc[ASPEED_INTC_NUM];
> + AspeedINTCState intcioexp[ASPEED_IOEXP_NUM];
> GICv3State gic;
> MemoryRegion dram_empty;
> };
> @@ -288,6 +290,8 @@ enum {
> ASPEED_DEV_LTPI_CTRL2,
> ASPEED_DEV_LTPI_IO0,
> ASPEED_DEV_LTPI_IO1,
> + ASPEED_DEV_IOEXP0_INTCIO,
> + ASPEED_DEV_IOEXP1_INTCIO,
> };
>
> const char *aspeed_soc_cpu_type(const char * const *valid_cpu_types);
> diff --git a/include/hw/intc/aspeed_intc.h b/include/hw/intc/aspeed_intc.h
> index 51288384a5..4565bbab84 100644
> --- a/include/hw/intc/aspeed_intc.h
> +++ b/include/hw/intc/aspeed_intc.h
> @@ -15,6 +15,8 @@
> #define TYPE_ASPEED_INTC "aspeed.intc"
> #define TYPE_ASPEED_2700_INTC TYPE_ASPEED_INTC "-ast2700"
> #define TYPE_ASPEED_2700_INTCIO TYPE_ASPEED_INTC "io-ast2700"
> +#define TYPE_ASPEED_2700_INTCIOEXP1 TYPE_ASPEED_INTC "ast2700-ioexp1"
> +#define TYPE_ASPEED_2700_INTCIOEXP2 TYPE_ASPEED_INTC "ast2700-ioexp2"
> #define TYPE_ASPEED_2700SSP_INTC TYPE_ASPEED_INTC "-ast2700ssp"
> #define TYPE_ASPEED_2700SSP_INTCIO TYPE_ASPEED_INTC "io-ast2700ssp"
> #define TYPE_ASPEED_2700TSP_INTC TYPE_ASPEED_INTC "-ast2700tsp"
> diff --git a/hw/arm/aspeed_ast27x0.c b/hw/arm/aspeed_ast27x0.c
> index de39a3e7eb..678d4eb6d9 100644
> --- a/hw/arm/aspeed_ast27x0.c
> +++ b/hw/arm/aspeed_ast27x0.c
> @@ -91,7 +91,9 @@ static const hwaddr aspeed_soc_ast2700_memmap[] = {
> [ASPEED_DEV_LTPI_CTRL2] = 0x14C35000,
> [ASPEED_DEV_WDT] = 0x14C37000,
> [ASPEED_DEV_LTPI_IO0] = 0x30000000,
> + [ASPEED_DEV_IOEXP0_INTCIO] = 0x30C18000,
> [ASPEED_DEV_LTPI_IO1] = 0x50000000,
> + [ASPEED_DEV_IOEXP1_INTCIO] = 0x50C18000,
> [ASPEED_DEV_PCIE_MMIO0] = 0x60000000,
> [ASPEED_DEV_PCIE_MMIO1] = 0x80000000,
> [ASPEED_DEV_PCIE_MMIO2] = 0xA0000000,
> @@ -511,6 +513,10 @@ static void aspeed_soc_ast2700_init(Object *obj)
> object_initialize_child(obj, "intc", &a->intc[0], TYPE_ASPEED_2700_INTC);
> object_initialize_child(obj, "intcio", &a->intc[1],
> TYPE_ASPEED_2700_INTCIO);
> + object_initialize_child(obj, "intcioexp0", &a->intcioexp[0],
> + TYPE_ASPEED_2700_INTCIOEXP1);
> + object_initialize_child(obj, "intcioexp1", &a->intcioexp[1],
> + TYPE_ASPEED_2700_INTCIOEXP2);
>
> snprintf(typename, sizeof(typename), "aspeed.adc-%s", socname);
> object_initialize_child(obj, "adc", &s->adc, typename);
> @@ -755,6 +761,22 @@ static void aspeed_soc_ast2700_realize(DeviceState *dev, Error **errp)
> aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intc[1]), 0,
> sc->memmap[ASPEED_DEV_INTCIO]);
>
> + /* INTCIOEXP0 */
> + if (!sysbus_realize(SYS_BUS_DEVICE(&a->intcioexp[0]), errp)) {
> + return;
> + }
> +
> + aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intcioexp[0]), 0,
> + sc->memmap[ASPEED_DEV_IOEXP0_INTCIO]);
> +
> + /* INTCIOEXP1 */
> + if (!sysbus_realize(SYS_BUS_DEVICE(&a->intcioexp[1]), errp)) {
> + return;
> + }
> +
> + aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intcioexp[1]), 0,
> + sc->memmap[ASPEED_DEV_IOEXP1_INTCIO]);
> +
> /* irq sources -> orgates -> INTC */
> for (i = 0; i < ic->num_inpins; i++) {
> qdev_connect_gpio_out(DEVICE(&a->intc[0].orgates[i]), 0,
> @@ -1079,6 +1101,21 @@ static void aspeed_soc_ast2700_realize(DeviceState *dev, Error **errp)
> }
> sysbus_mmio_map(SYS_BUS_DEVICE(&s->ioexp[i]), 0,
> sc->memmap[ASPEED_DEV_LTPI_IO0 + i]);
> +
> + icio = ASPEED_INTC_GET_CLASS(&a->intcioexp[i]);
> + /* INTC_IOEXP internal: orgate[i] -> input[i] */
> + for (int j = 0; j < icio->num_inpins; j++) {
> + irq = qdev_get_gpio_in(DEVICE(&a->intcioexp[i]), j);
> + qdev_connect_gpio_out(DEVICE(&a->intcioexp[i].orgates[j]), 0,
> + irq);
> + }
> +
> + /* INTC_IOEXP output[i] -> INTC0.orgate[0].input[i] */
> + for (int j = 0; j < icio->num_outpins; j++) {
> + irq = qdev_get_gpio_in(DEVICE(&a->intc[0].orgates[0]), j);
> + sysbus_connect_irq(SYS_BUS_DEVICE(&a->intcioexp[i]), j,
> + irq);
> + }
> }
>
> aspeed_mmio_map_unimplemented(s->memory, SYS_BUS_DEVICE(&s->dpmcu),
> diff --git a/hw/intc/aspeed_intc.c b/hw/intc/aspeed_intc.c
> index 5cd786dee6..a04005ee7c 100644
> --- a/hw/intc/aspeed_intc.c
> +++ b/hw/intc/aspeed_intc.c
> @@ -924,6 +924,64 @@ static const TypeInfo aspeed_2700_intc_info = {
> .class_init = aspeed_2700_intc_class_init,
> };
>
> +static AspeedINTCIRQ aspeed_2700_intcioexp2_irqs[ASPEED_INTC_MAX_INPINS] = {
> + {0, 8, 1, R_GICINT192_EN, R_GICINT192_STATUS},
> + {1, 9, 1, R_GICINT193_EN, R_GICINT193_STATUS},
> +};
> +
> +static void aspeed_2700_intcioexp2_class_init(ObjectClass *klass,
> + const void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> + AspeedINTCClass *aic = ASPEED_INTC_CLASS(klass);
> +
> + dc->desc = "ASPEED 2700 IOEXP2 INTC Controller";
> + aic->num_lines = 32;
> + aic->num_inpins = 2;
> + aic->num_outpins = 10;
> + aic->mem_size = 0x400;
> + aic->nr_regs = 0x58 >> 2;
> + aic->reg_offset = 0x100;
> + aic->reg_ops = &aspeed_intcio_ops;
> + aic->irq_table = aspeed_2700_intcioexp2_irqs;
> + aic->irq_table_count = ARRAY_SIZE(aspeed_2700_intcioexp2_irqs);
> +}
> +
> +static const TypeInfo aspeed_2700_intcioexp2_info = {
> + .name = TYPE_ASPEED_2700_INTCIOEXP2,
> + .parent = TYPE_ASPEED_INTC,
> + .class_init = aspeed_2700_intcioexp2_class_init,
> +};
> +
> +static AspeedINTCIRQ aspeed_2700_intcioexp1_irqs[ASPEED_INTC_MAX_INPINS] = {
> + {0, 6, 1, R_GICINT192_EN, R_GICINT192_STATUS},
> + {1, 7, 1, R_GICINT193_EN, R_GICINT193_STATUS},
> +};
> +
> +static void aspeed_2700_intcioexp1_class_init(ObjectClass *klass,
> + const void *data)
> +{
> + DeviceClass *dc = DEVICE_CLASS(klass);
> + AspeedINTCClass *aic = ASPEED_INTC_CLASS(klass);
> +
> + dc->desc = "ASPEED 2700 IOEXP1 INTC Controller";
> + aic->num_lines = 32;
> + aic->num_inpins = 2;
> + aic->num_outpins = 10;
> + aic->mem_size = 0x400;
> + aic->nr_regs = 0x58 >> 2;
> + aic->reg_offset = 0x100;
> + aic->reg_ops = &aspeed_intcio_ops;
> + aic->irq_table = aspeed_2700_intcioexp1_irqs;
> + aic->irq_table_count = ARRAY_SIZE(aspeed_2700_intcioexp1_irqs);
> +}
> +
> +static const TypeInfo aspeed_2700_intcioexp1_info = {
> + .name = TYPE_ASPEED_2700_INTCIOEXP1,
> + .parent = TYPE_ASPEED_INTC,
> + .class_init = aspeed_2700_intcioexp1_class_init,
> +};
> +
> static AspeedINTCIRQ aspeed_2700_intcio_irqs[ASPEED_INTC_MAX_INPINS] = {
> {0, 0, 1, R_GICINT192_EN, R_GICINT192_STATUS},
> {1, 1, 1, R_GICINT193_EN, R_GICINT193_STATUS},
> @@ -1099,6 +1157,8 @@ static void aspeed_intc_register_types(void)
> type_register_static(&aspeed_intc_info);
> type_register_static(&aspeed_2700_intc_info);
> type_register_static(&aspeed_2700_intcio_info);
> + type_register_static(&aspeed_2700_intcioexp1_info);
> + type_register_static(&aspeed_2700_intcioexp2_info);
> type_register_static(&aspeed_2700ssp_intc_info);
> type_register_static(&aspeed_2700ssp_intcio_info);
> type_register_static(&aspeed_2700tsp_intc_info);
On Wed, Dec 24, 2025 at 2:39 AM Cédric Le Goater <clg@kaod.org> wrote:
>
> On 12/24/25 02:41, Kane Chen via wrote:
> > From: Kane-Chen-AS <kane_chen@aspeedtech.com>
> >
> > Connect the AST1700 interrupt lines to the GIC in AST27X0, enabling
> > the propagation of AST1700-originated interrupts to the host SoC.
> >
> > This patch does not implement interrupt sources in AST1700 itself,
> > only the wiring into AST27X0.
> >
> > Signed-off-by: Kane-Chen-AS <kane_chen@aspeedtech.com>
>
> Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Nabih Estefan <nabihestefan@google.com>
Tested-by: Nabih Estefan <nabihestefan@google.com>
I agree with the readability notes from Cedric, as for the bus naming,
I feel like that applied to patch 14 more than it does to this one.
>
> Thanks,
>
> C.
>
>
> > ---
> > include/hw/arm/aspeed_soc.h | 6 +++-
> > include/hw/intc/aspeed_intc.h | 2 ++
> > hw/arm/aspeed_ast27x0.c | 37 +++++++++++++++++++++
> > hw/intc/aspeed_intc.c | 60 +++++++++++++++++++++++++++++++++++
> > 4 files changed, 104 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/hw/arm/aspeed_soc.h b/include/hw/arm/aspeed_soc.h
> > index f19bab3457..b051d0eb3a 100644
> > --- a/include/hw/arm/aspeed_soc.h
> > +++ b/include/hw/arm/aspeed_soc.h
> > @@ -58,6 +58,7 @@
> > #define ASPEED_UARTS_NUM 13
> > #define ASPEED_JTAG_NUM 2
> > #define ASPEED_PCIE_NUM 3
> > +#define ASPEED_INTC_NUM 2
> > #define ASPEED_IOEXP_NUM 2
> >
> > struct AspeedSoCState {
> > @@ -146,7 +147,8 @@ struct Aspeed27x0SoCState {
> > AspeedSoCState parent;
> >
> > ARMCPU cpu[ASPEED_CPUS_NUM];
> > - AspeedINTCState intc[2];
> > + AspeedINTCState intc[ASPEED_INTC_NUM];
> > + AspeedINTCState intcioexp[ASPEED_IOEXP_NUM];
> > GICv3State gic;
> > MemoryRegion dram_empty;
> > };
> > @@ -288,6 +290,8 @@ enum {
> > ASPEED_DEV_LTPI_CTRL2,
> > ASPEED_DEV_LTPI_IO0,
> > ASPEED_DEV_LTPI_IO1,
> > + ASPEED_DEV_IOEXP0_INTCIO,
> > + ASPEED_DEV_IOEXP1_INTCIO,
> > };
> >
> > const char *aspeed_soc_cpu_type(const char * const *valid_cpu_types);
> > diff --git a/include/hw/intc/aspeed_intc.h b/include/hw/intc/aspeed_intc.h
> > index 51288384a5..4565bbab84 100644
> > --- a/include/hw/intc/aspeed_intc.h
> > +++ b/include/hw/intc/aspeed_intc.h
> > @@ -15,6 +15,8 @@
> > #define TYPE_ASPEED_INTC "aspeed.intc"
> > #define TYPE_ASPEED_2700_INTC TYPE_ASPEED_INTC "-ast2700"
> > #define TYPE_ASPEED_2700_INTCIO TYPE_ASPEED_INTC "io-ast2700"
> > +#define TYPE_ASPEED_2700_INTCIOEXP1 TYPE_ASPEED_INTC "ast2700-ioexp1"
> > +#define TYPE_ASPEED_2700_INTCIOEXP2 TYPE_ASPEED_INTC "ast2700-ioexp2"
> > #define TYPE_ASPEED_2700SSP_INTC TYPE_ASPEED_INTC "-ast2700ssp"
> > #define TYPE_ASPEED_2700SSP_INTCIO TYPE_ASPEED_INTC "io-ast2700ssp"
> > #define TYPE_ASPEED_2700TSP_INTC TYPE_ASPEED_INTC "-ast2700tsp"
> > diff --git a/hw/arm/aspeed_ast27x0.c b/hw/arm/aspeed_ast27x0.c
> > index de39a3e7eb..678d4eb6d9 100644
> > --- a/hw/arm/aspeed_ast27x0.c
> > +++ b/hw/arm/aspeed_ast27x0.c
> > @@ -91,7 +91,9 @@ static const hwaddr aspeed_soc_ast2700_memmap[] = {
> > [ASPEED_DEV_LTPI_CTRL2] = 0x14C35000,
> > [ASPEED_DEV_WDT] = 0x14C37000,
> > [ASPEED_DEV_LTPI_IO0] = 0x30000000,
> > + [ASPEED_DEV_IOEXP0_INTCIO] = 0x30C18000,
> > [ASPEED_DEV_LTPI_IO1] = 0x50000000,
> > + [ASPEED_DEV_IOEXP1_INTCIO] = 0x50C18000,
> > [ASPEED_DEV_PCIE_MMIO0] = 0x60000000,
> > [ASPEED_DEV_PCIE_MMIO1] = 0x80000000,
> > [ASPEED_DEV_PCIE_MMIO2] = 0xA0000000,
> > @@ -511,6 +513,10 @@ static void aspeed_soc_ast2700_init(Object *obj)
> > object_initialize_child(obj, "intc", &a->intc[0], TYPE_ASPEED_2700_INTC);
> > object_initialize_child(obj, "intcio", &a->intc[1],
> > TYPE_ASPEED_2700_INTCIO);
> > + object_initialize_child(obj, "intcioexp0", &a->intcioexp[0],
> > + TYPE_ASPEED_2700_INTCIOEXP1);
> > + object_initialize_child(obj, "intcioexp1", &a->intcioexp[1],
> > + TYPE_ASPEED_2700_INTCIOEXP2);
> >
> > snprintf(typename, sizeof(typename), "aspeed.adc-%s", socname);
> > object_initialize_child(obj, "adc", &s->adc, typename);
> > @@ -755,6 +761,22 @@ static void aspeed_soc_ast2700_realize(DeviceState *dev, Error **errp)
> > aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intc[1]), 0,
> > sc->memmap[ASPEED_DEV_INTCIO]);
> >
> > + /* INTCIOEXP0 */
> > + if (!sysbus_realize(SYS_BUS_DEVICE(&a->intcioexp[0]), errp)) {
> > + return;
> > + }
> > +
> > + aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intcioexp[0]), 0,
> > + sc->memmap[ASPEED_DEV_IOEXP0_INTCIO]);
> > +
> > + /* INTCIOEXP1 */
> > + if (!sysbus_realize(SYS_BUS_DEVICE(&a->intcioexp[1]), errp)) {
> > + return;
> > + }
> > +
> > + aspeed_mmio_map(s->memory, SYS_BUS_DEVICE(&a->intcioexp[1]), 0,
> > + sc->memmap[ASPEED_DEV_IOEXP1_INTCIO]);
> > +
> > /* irq sources -> orgates -> INTC */
> > for (i = 0; i < ic->num_inpins; i++) {
> > qdev_connect_gpio_out(DEVICE(&a->intc[0].orgates[i]), 0,
> > @@ -1079,6 +1101,21 @@ static void aspeed_soc_ast2700_realize(DeviceState *dev, Error **errp)
> > }
> > sysbus_mmio_map(SYS_BUS_DEVICE(&s->ioexp[i]), 0,
> > sc->memmap[ASPEED_DEV_LTPI_IO0 + i]);
> > +
> > + icio = ASPEED_INTC_GET_CLASS(&a->intcioexp[i]);
> > + /* INTC_IOEXP internal: orgate[i] -> input[i] */
> > + for (int j = 0; j < icio->num_inpins; j++) {
> > + irq = qdev_get_gpio_in(DEVICE(&a->intcioexp[i]), j);
> > + qdev_connect_gpio_out(DEVICE(&a->intcioexp[i].orgates[j]), 0,
> > + irq);
> > + }
> > +
> > + /* INTC_IOEXP output[i] -> INTC0.orgate[0].input[i] */
> > + for (int j = 0; j < icio->num_outpins; j++) {
> > + irq = qdev_get_gpio_in(DEVICE(&a->intc[0].orgates[0]), j);
> > + sysbus_connect_irq(SYS_BUS_DEVICE(&a->intcioexp[i]), j,
> > + irq);
> > + }
> > }
> >
> > aspeed_mmio_map_unimplemented(s->memory, SYS_BUS_DEVICE(&s->dpmcu),
> > diff --git a/hw/intc/aspeed_intc.c b/hw/intc/aspeed_intc.c
> > index 5cd786dee6..a04005ee7c 100644
> > --- a/hw/intc/aspeed_intc.c
> > +++ b/hw/intc/aspeed_intc.c
> > @@ -924,6 +924,64 @@ static const TypeInfo aspeed_2700_intc_info = {
> > .class_init = aspeed_2700_intc_class_init,
> > };
> >
> > +static AspeedINTCIRQ aspeed_2700_intcioexp2_irqs[ASPEED_INTC_MAX_INPINS] = {
> > + {0, 8, 1, R_GICINT192_EN, R_GICINT192_STATUS},
> > + {1, 9, 1, R_GICINT193_EN, R_GICINT193_STATUS},
> > +};
> > +
> > +static void aspeed_2700_intcioexp2_class_init(ObjectClass *klass,
> > + const void *data)
> > +{
> > + DeviceClass *dc = DEVICE_CLASS(klass);
> > + AspeedINTCClass *aic = ASPEED_INTC_CLASS(klass);
> > +
> > + dc->desc = "ASPEED 2700 IOEXP2 INTC Controller";
> > + aic->num_lines = 32;
> > + aic->num_inpins = 2;
> > + aic->num_outpins = 10;
> > + aic->mem_size = 0x400;
> > + aic->nr_regs = 0x58 >> 2;
> > + aic->reg_offset = 0x100;
> > + aic->reg_ops = &aspeed_intcio_ops;
> > + aic->irq_table = aspeed_2700_intcioexp2_irqs;
> > + aic->irq_table_count = ARRAY_SIZE(aspeed_2700_intcioexp2_irqs);
> > +}
> > +
> > +static const TypeInfo aspeed_2700_intcioexp2_info = {
> > + .name = TYPE_ASPEED_2700_INTCIOEXP2,
> > + .parent = TYPE_ASPEED_INTC,
> > + .class_init = aspeed_2700_intcioexp2_class_init,
> > +};
> > +
> > +static AspeedINTCIRQ aspeed_2700_intcioexp1_irqs[ASPEED_INTC_MAX_INPINS] = {
> > + {0, 6, 1, R_GICINT192_EN, R_GICINT192_STATUS},
> > + {1, 7, 1, R_GICINT193_EN, R_GICINT193_STATUS},
> > +};
> > +
> > +static void aspeed_2700_intcioexp1_class_init(ObjectClass *klass,
> > + const void *data)
> > +{
> > + DeviceClass *dc = DEVICE_CLASS(klass);
> > + AspeedINTCClass *aic = ASPEED_INTC_CLASS(klass);
> > +
> > + dc->desc = "ASPEED 2700 IOEXP1 INTC Controller";
> > + aic->num_lines = 32;
> > + aic->num_inpins = 2;
> > + aic->num_outpins = 10;
> > + aic->mem_size = 0x400;
> > + aic->nr_regs = 0x58 >> 2;
> > + aic->reg_offset = 0x100;
> > + aic->reg_ops = &aspeed_intcio_ops;
> > + aic->irq_table = aspeed_2700_intcioexp1_irqs;
> > + aic->irq_table_count = ARRAY_SIZE(aspeed_2700_intcioexp1_irqs);
> > +}
> > +
> > +static const TypeInfo aspeed_2700_intcioexp1_info = {
> > + .name = TYPE_ASPEED_2700_INTCIOEXP1,
> > + .parent = TYPE_ASPEED_INTC,
> > + .class_init = aspeed_2700_intcioexp1_class_init,
> > +};
> > +
> > static AspeedINTCIRQ aspeed_2700_intcio_irqs[ASPEED_INTC_MAX_INPINS] = {
> > {0, 0, 1, R_GICINT192_EN, R_GICINT192_STATUS},
> > {1, 1, 1, R_GICINT193_EN, R_GICINT193_STATUS},
> > @@ -1099,6 +1157,8 @@ static void aspeed_intc_register_types(void)
> > type_register_static(&aspeed_intc_info);
> > type_register_static(&aspeed_2700_intc_info);
> > type_register_static(&aspeed_2700_intcio_info);
> > + type_register_static(&aspeed_2700_intcioexp1_info);
> > + type_register_static(&aspeed_2700_intcioexp2_info);
> > type_register_static(&aspeed_2700ssp_intc_info);
> > type_register_static(&aspeed_2700ssp_intcio_info);
> > type_register_static(&aspeed_2700tsp_intc_info);
>
© 2016 - 2026 Red Hat, Inc.