* [RFC PATCH 0/2] Add ability to handle nodes with interrupts-extended property
@ 2019-05-02 14:13 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr Tyshchenko @ 2019-05-02 14:13 UTC (permalink / raw)
To: xen-devel; +Cc: Oleksandr Tyshchenko, julien.grall, sstabellini
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Hello, all.
The purpose of this small series is to add minimal required support for Xen to be able to
handle device-tree nodes with "interrupts-extended" property [1].
The reason:
Xen expects to see "interrupts" property when parsing host device-tree.
But, there are cases when some device nodes contain "interrupts-extended" property instead.
The good example here is arch timer node for R-Car Gen3/Gen2 family [2], which is mandatory device
for Xen usage on ARM. And without ability to handle such nodes, Xen fails to operate:
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Timer: Unable to retrieve IRQ 0 from the device tree
(XEN) ****************************************
----------
Preliminary tested on R-Car Gen3 based board. Log (with debug enabled) shows that Xen recognized arch timer
interrupts represented with "interrupts-extended" property:
timer {
compatible = "arm,armv8-timer";
interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
<&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
<&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
<&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
};
...
(XEN) dt_device_get_raw_irq: dev=/timer, index=0
(XEN) intspec=1 intsize=3
(XEN) dt_irq_map_raw: par=/soc/interrupt-controller@f1010000,intspec=[0x00000001 0x0000000d...],ointsize=3
(XEN) dt_irq_map_raw: ipar=/soc/interrupt-controller@f1010000, size=3
(XEN) -> addrsize=0
(XEN) -> got it !
(XEN) dt_device_get_raw_irq: dev=/timer, index=1
(XEN) intspec=1 intsize=3
(XEN) dt_irq_map_raw: par=/soc/interrupt-controller@f1010000,intspec=[0x00000001 0x0000000e...],ointsize=3
(XEN) dt_irq_map_raw: ipar=/soc/interrupt-controller@f1010000, size=3
(XEN) -> addrsize=0
(XEN) -> got it !
(XEN) dt_device_get_raw_irq: dev=/timer, index=2
(XEN) intspec=1 intsize=3
(XEN) dt_irq_map_raw: par=/soc/interrupt-controller@f1010000,intspec=[0x00000001 0x0000000b...],ointsize=3
(XEN) dt_irq_map_raw: ipar=/soc/interrupt-controller@f1010000, size=3
(XEN) -> addrsize=0
(XEN) -> got it !
(XEN) dt_device_get_raw_irq: dev=/timer, index=3
(XEN) intspec=1 intsize=3
(XEN) dt_irq_map_raw: par=/soc/interrupt-controller@f1010000,intspec=[0x00000001 0x0000000a...],ointsize=3
(XEN) dt_irq_map_raw: ipar=/soc/interrupt-controller@f1010000, size=3
(XEN) -> addrsize=0
(XEN) -> got it !
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
...
----------
The first patch had Julien's R-B some time ago, but I dropped it.
[1]
https://elixir.bootlin.com/linux/v5.1-rc7/source/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[2]
https://elixir.bootlin.com/linux/v5.1-rc7/source/arch/arm64/boot/dts/renesas/r8a7795.dtsi#L3185
https://elixir.bootlin.com/linux/v5.1-rc7/source/arch/arm/boot/dts/r8a7790.dtsi#L1856
Oleksandr Tyshchenko (2):
xen/device-tree: Add dt_count_phandle_with_args helper
xen/device-tree: Add ability to handle nodes with interrupts-extended
prop
xen/common/device_tree.c | 39 ++++++++++++++++++++++++++++++++++++---
xen/include/xen/device_tree.h | 19 +++++++++++++++++++
2 files changed, 55 insertions(+), 3 deletions(-)
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Xen-devel] [RFC PATCH 0/2] Add ability to handle nodes with interrupts-extended property
@ 2019-05-02 14:13 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr Tyshchenko @ 2019-05-02 14:13 UTC (permalink / raw)
To: xen-devel; +Cc: Oleksandr Tyshchenko, julien.grall, sstabellini
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Hello, all.
The purpose of this small series is to add minimal required support for Xen to be able to
handle device-tree nodes with "interrupts-extended" property [1].
The reason:
Xen expects to see "interrupts" property when parsing host device-tree.
But, there are cases when some device nodes contain "interrupts-extended" property instead.
The good example here is arch timer node for R-Car Gen3/Gen2 family [2], which is mandatory device
for Xen usage on ARM. And without ability to handle such nodes, Xen fails to operate:
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Timer: Unable to retrieve IRQ 0 from the device tree
(XEN) ****************************************
----------
Preliminary tested on R-Car Gen3 based board. Log (with debug enabled) shows that Xen recognized arch timer
interrupts represented with "interrupts-extended" property:
timer {
compatible = "arm,armv8-timer";
interrupts-extended = <&gic GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
<&gic GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
<&gic GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>,
<&gic GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW)>;
};
...
(XEN) dt_device_get_raw_irq: dev=/timer, index=0
(XEN) intspec=1 intsize=3
(XEN) dt_irq_map_raw: par=/soc/interrupt-controller@f1010000,intspec=[0x00000001 0x0000000d...],ointsize=3
(XEN) dt_irq_map_raw: ipar=/soc/interrupt-controller@f1010000, size=3
(XEN) -> addrsize=0
(XEN) -> got it !
(XEN) dt_device_get_raw_irq: dev=/timer, index=1
(XEN) intspec=1 intsize=3
(XEN) dt_irq_map_raw: par=/soc/interrupt-controller@f1010000,intspec=[0x00000001 0x0000000e...],ointsize=3
(XEN) dt_irq_map_raw: ipar=/soc/interrupt-controller@f1010000, size=3
(XEN) -> addrsize=0
(XEN) -> got it !
(XEN) dt_device_get_raw_irq: dev=/timer, index=2
(XEN) intspec=1 intsize=3
(XEN) dt_irq_map_raw: par=/soc/interrupt-controller@f1010000,intspec=[0x00000001 0x0000000b...],ointsize=3
(XEN) dt_irq_map_raw: ipar=/soc/interrupt-controller@f1010000, size=3
(XEN) -> addrsize=0
(XEN) -> got it !
(XEN) dt_device_get_raw_irq: dev=/timer, index=3
(XEN) intspec=1 intsize=3
(XEN) dt_irq_map_raw: par=/soc/interrupt-controller@f1010000,intspec=[0x00000001 0x0000000a...],ointsize=3
(XEN) dt_irq_map_raw: ipar=/soc/interrupt-controller@f1010000, size=3
(XEN) -> addrsize=0
(XEN) -> got it !
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 8333 KHz
...
----------
The first patch had Julien's R-B some time ago, but I dropped it.
[1]
https://elixir.bootlin.com/linux/v5.1-rc7/source/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[2]
https://elixir.bootlin.com/linux/v5.1-rc7/source/arch/arm64/boot/dts/renesas/r8a7795.dtsi#L3185
https://elixir.bootlin.com/linux/v5.1-rc7/source/arch/arm/boot/dts/r8a7790.dtsi#L1856
Oleksandr Tyshchenko (2):
xen/device-tree: Add dt_count_phandle_with_args helper
xen/device-tree: Add ability to handle nodes with interrupts-extended
prop
xen/common/device_tree.c | 39 ++++++++++++++++++++++++++++++++++++---
xen/include/xen/device_tree.h | 19 +++++++++++++++++++
2 files changed, 55 insertions(+), 3 deletions(-)
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* [RFC PATCH 1/2] xen/device-tree: Add dt_count_phandle_with_args helper
@ 2019-05-02 14:13 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr Tyshchenko @ 2019-05-02 14:13 UTC (permalink / raw)
To: xen-devel; +Cc: Oleksandr Tyshchenko, julien.grall, sstabellini
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
xen/common/device_tree.c | 7 +++++++
xen/include/xen/device_tree.h | 19 +++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 8fc401d..65862b5 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1663,6 +1663,13 @@ int dt_parse_phandle_with_args(const struct dt_device_node *np,
index, out_args);
}
+int dt_count_phandle_with_args(const struct dt_device_node *np,
+ const char *list_name,
+ const char *cells_name)
+{
+ return __dt_parse_phandle_with_args(np, list_name, cells_name, 0, -1, NULL);
+}
+
/**
* unflatten_dt_node - Alloc and populate a device_node from the flat tree
* @fdt: The parent device tree blob
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 7408a6c..8315629 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -738,6 +738,25 @@ int dt_parse_phandle_with_args(const struct dt_device_node *np,
const char *cells_name, int index,
struct dt_phandle_args *out_args);
+/**
+ * dt_count_phandle_with_args() - Find the number of phandles references in a property
+ * @np: pointer to a device tree node containing a list
+ * @list_name: property name that contains a list
+ * @cells_name: property name that specifies phandles' arguments count
+ *
+ * Returns the number of phandle + argument tuples within a property. It
+ * is a typical pattern to encode a list of phandle and variable
+ * arguments into a single property. The number of arguments is encoded
+ * by a property in the phandle-target node. For example, a gpios
+ * property would contain a list of GPIO specifies consisting of a
+ * phandle and 1 or more arguments. The number of arguments are
+ * determined by the #gpio-cells property in the node pointed to by the
+ * phandle.
+ */
+int dt_count_phandle_with_args(const struct dt_device_node *np,
+ const char *list_name,
+ const char *cells_name);
+
#ifdef CONFIG_DEVICE_TREE_DEBUG
#define dt_dprintk(fmt, args...) \
printk(XENLOG_DEBUG fmt, ## args)
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [Xen-devel] [RFC PATCH 1/2] xen/device-tree: Add dt_count_phandle_with_args helper
@ 2019-05-02 14:13 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr Tyshchenko @ 2019-05-02 14:13 UTC (permalink / raw)
To: xen-devel; +Cc: Oleksandr Tyshchenko, julien.grall, sstabellini
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Port Linux helper of_count_phandle_with_args for counting
number of phandles in a property.
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
xen/common/device_tree.c | 7 +++++++
xen/include/xen/device_tree.h | 19 +++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 8fc401d..65862b5 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -1663,6 +1663,13 @@ int dt_parse_phandle_with_args(const struct dt_device_node *np,
index, out_args);
}
+int dt_count_phandle_with_args(const struct dt_device_node *np,
+ const char *list_name,
+ const char *cells_name)
+{
+ return __dt_parse_phandle_with_args(np, list_name, cells_name, 0, -1, NULL);
+}
+
/**
* unflatten_dt_node - Alloc and populate a device_node from the flat tree
* @fdt: The parent device tree blob
diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h
index 7408a6c..8315629 100644
--- a/xen/include/xen/device_tree.h
+++ b/xen/include/xen/device_tree.h
@@ -738,6 +738,25 @@ int dt_parse_phandle_with_args(const struct dt_device_node *np,
const char *cells_name, int index,
struct dt_phandle_args *out_args);
+/**
+ * dt_count_phandle_with_args() - Find the number of phandles references in a property
+ * @np: pointer to a device tree node containing a list
+ * @list_name: property name that contains a list
+ * @cells_name: property name that specifies phandles' arguments count
+ *
+ * Returns the number of phandle + argument tuples within a property. It
+ * is a typical pattern to encode a list of phandle and variable
+ * arguments into a single property. The number of arguments is encoded
+ * by a property in the phandle-target node. For example, a gpios
+ * property would contain a list of GPIO specifies consisting of a
+ * phandle and 1 or more arguments. The number of arguments are
+ * determined by the #gpio-cells property in the node pointed to by the
+ * phandle.
+ */
+int dt_count_phandle_with_args(const struct dt_device_node *np,
+ const char *list_name,
+ const char *cells_name);
+
#ifdef CONFIG_DEVICE_TREE_DEBUG
#define dt_dprintk(fmt, args...) \
printk(XENLOG_DEBUG fmt, ## args)
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [RFC PATCH 2/2] xen/device-tree: Add ability to handle nodes with interrupts-extended prop
@ 2019-05-02 14:13 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr Tyshchenko @ 2019-05-02 14:13 UTC (permalink / raw)
To: xen-devel; +Cc: Oleksandr Tyshchenko, julien.grall, sstabellini
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Xen expects to see "interrupts" property when parsing host
device-tree. But, there are cases when some device nodes contain
"interrupts-extended" property instead.
The good example here is arch timer node for R-Car Gen3/Gen2 family,
which is mandatory device for Xen usage on ARM. And without ability
to handle such nodes, Xen fails to operate:
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Timer: Unable to retrieve IRQ 0 from the device tree
(XEN) ****************************************
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
xen/common/device_tree.c | 32 +++++++++++++++++++++++++++++---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 65862b5..00ada6e 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -987,9 +987,19 @@ unsigned int dt_number_of_irq(const struct dt_device_node *device)
const struct dt_device_node *p;
const __be32 *intspec, *tmp;
u32 intsize, intlen;
+ int intnum;
dt_dprintk("dt_irq_number: dev=%s\n", device->full_name);
+ /* Try the new-style interrupts-extended first */
+ intnum = dt_count_phandle_with_args(device, "interrupts-extended",
+ "#interrupt-cells");
+ if ( intnum > 0 )
+ {
+ dt_dprintk(" intnum=%d\n", intnum);
+ return intnum;
+ }
+
/* Get the interrupts property */
intspec = dt_get_property(device, "interrupts", &intlen);
if ( intspec == NULL )
@@ -1420,10 +1430,29 @@ int dt_device_get_raw_irq(const struct dt_device_node *device,
const __be32 *intspec, *tmp, *addr;
u32 intsize, intlen;
int res = -EINVAL;
+ struct dt_phandle_args args;
+ int i;
dt_dprintk("dt_device_get_raw_irq: dev=%s, index=%u\n",
device->full_name, index);
+ /* Get the reg property (if any) */
+ addr = dt_get_property(device, "reg", NULL);
+
+ /* Try the new-style interrupts-extended first */
+ res = dt_parse_phandle_with_args(device, "interrupts-extended",
+ "#interrupt-cells", index, &args);
+ if ( !res )
+ {
+ dt_dprintk(" intspec=%d intsize=%d\n", args.args[0], args.args_count);
+
+ for ( i = 0; i < args.args_count; i++ )
+ args.args[i] = cpu_to_be32(args.args[i]);
+
+ return dt_irq_map_raw(args.np, args.args, args.args_count,
+ addr, out_irq);
+ }
+
/* Get the interrupts property */
intspec = dt_get_property(device, "interrupts", &intlen);
if ( intspec == NULL )
@@ -1432,9 +1461,6 @@ int dt_device_get_raw_irq(const struct dt_device_node *device,
dt_dprintk(" intspec=%d intlen=%d\n", be32_to_cpup(intspec), intlen);
- /* Get the reg property (if any) */
- addr = dt_get_property(device, "reg", NULL);
-
/* Look for the interrupt parent. */
p = dt_irq_find_parent(device);
if ( p == NULL )
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 26+ messages in thread
* [Xen-devel] [RFC PATCH 2/2] xen/device-tree: Add ability to handle nodes with interrupts-extended prop
@ 2019-05-02 14:13 ` Oleksandr Tyshchenko
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr Tyshchenko @ 2019-05-02 14:13 UTC (permalink / raw)
To: xen-devel; +Cc: Oleksandr Tyshchenko, julien.grall, sstabellini
From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
Xen expects to see "interrupts" property when parsing host
device-tree. But, there are cases when some device nodes contain
"interrupts-extended" property instead.
The good example here is arch timer node for R-Car Gen3/Gen2 family,
which is mandatory device for Xen usage on ARM. And without ability
to handle such nodes, Xen fails to operate:
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) Timer: Unable to retrieve IRQ 0 from the device tree
(XEN) ****************************************
Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
---
xen/common/device_tree.c | 32 +++++++++++++++++++++++++++++---
1 file changed, 29 insertions(+), 3 deletions(-)
diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
index 65862b5..00ada6e 100644
--- a/xen/common/device_tree.c
+++ b/xen/common/device_tree.c
@@ -987,9 +987,19 @@ unsigned int dt_number_of_irq(const struct dt_device_node *device)
const struct dt_device_node *p;
const __be32 *intspec, *tmp;
u32 intsize, intlen;
+ int intnum;
dt_dprintk("dt_irq_number: dev=%s\n", device->full_name);
+ /* Try the new-style interrupts-extended first */
+ intnum = dt_count_phandle_with_args(device, "interrupts-extended",
+ "#interrupt-cells");
+ if ( intnum > 0 )
+ {
+ dt_dprintk(" intnum=%d\n", intnum);
+ return intnum;
+ }
+
/* Get the interrupts property */
intspec = dt_get_property(device, "interrupts", &intlen);
if ( intspec == NULL )
@@ -1420,10 +1430,29 @@ int dt_device_get_raw_irq(const struct dt_device_node *device,
const __be32 *intspec, *tmp, *addr;
u32 intsize, intlen;
int res = -EINVAL;
+ struct dt_phandle_args args;
+ int i;
dt_dprintk("dt_device_get_raw_irq: dev=%s, index=%u\n",
device->full_name, index);
+ /* Get the reg property (if any) */
+ addr = dt_get_property(device, "reg", NULL);
+
+ /* Try the new-style interrupts-extended first */
+ res = dt_parse_phandle_with_args(device, "interrupts-extended",
+ "#interrupt-cells", index, &args);
+ if ( !res )
+ {
+ dt_dprintk(" intspec=%d intsize=%d\n", args.args[0], args.args_count);
+
+ for ( i = 0; i < args.args_count; i++ )
+ args.args[i] = cpu_to_be32(args.args[i]);
+
+ return dt_irq_map_raw(args.np, args.args, args.args_count,
+ addr, out_irq);
+ }
+
/* Get the interrupts property */
intspec = dt_get_property(device, "interrupts", &intlen);
if ( intspec == NULL )
@@ -1432,9 +1461,6 @@ int dt_device_get_raw_irq(const struct dt_device_node *device,
dt_dprintk(" intspec=%d intlen=%d\n", be32_to_cpup(intspec), intlen);
- /* Get the reg property (if any) */
- addr = dt_get_property(device, "reg", NULL);
-
/* Look for the interrupt parent. */
p = dt_irq_find_parent(device);
if ( p == NULL )
--
2.7.4
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply related [flat|nested] 26+ messages in thread
* Re: [RFC PATCH 0/2] Add ability to handle nodes with interrupts-extended property
@ 2019-05-10 15:29 ` Oleksandr
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr @ 2019-05-10 15:29 UTC (permalink / raw)
To: xen-devel; +Cc: Oleksandr Tyshchenko, julien.grall, sstabellini
Hello, all
gentle reminder...
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [RFC PATCH 0/2] Add ability to handle nodes with interrupts-extended property
@ 2019-05-10 15:29 ` Oleksandr
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr @ 2019-05-10 15:29 UTC (permalink / raw)
To: xen-devel; +Cc: Oleksandr Tyshchenko, julien.grall, sstabellini
Hello, all
gentle reminder...
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [RFC PATCH 0/2] Add ability to handle nodes with interrupts-extended property
@ 2019-05-10 15:45 ` Julien Grall
0 siblings, 0 replies; 26+ messages in thread
From: Julien Grall @ 2019-05-10 15:45 UTC (permalink / raw)
To: Oleksandr, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
On 10/05/2019 16:29, Oleksandr wrote:
>
> Hello, all
>
>
> gentle reminder...
This is on my long queue of patches to review. Any help reviewing the on-going
series will help.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [RFC PATCH 0/2] Add ability to handle nodes with interrupts-extended property
@ 2019-05-10 15:45 ` Julien Grall
0 siblings, 0 replies; 26+ messages in thread
From: Julien Grall @ 2019-05-10 15:45 UTC (permalink / raw)
To: Oleksandr, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
On 10/05/2019 16:29, Oleksandr wrote:
>
> Hello, all
>
>
> gentle reminder...
This is on my long queue of patches to review. Any help reviewing the on-going
series will help.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [RFC PATCH 0/2] Add ability to handle nodes with interrupts-extended property
@ 2019-05-10 17:02 ` Oleksandr
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr @ 2019-05-10 17:02 UTC (permalink / raw)
To: Julien Grall, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
On 10.05.19 18:45, Julien Grall wrote:
Hi, Julien
>
>
> On 10/05/2019 16:29, Oleksandr wrote:
>>
>> Hello, all
>>
>>
>> gentle reminder...
>
> This is on my long queue of patches to review. Any help reviewing the
> on-going series will help.
Oh, I see. Fair enough.
>
> Cheers,
>
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [RFC PATCH 0/2] Add ability to handle nodes with interrupts-extended property
@ 2019-05-10 17:02 ` Oleksandr
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr @ 2019-05-10 17:02 UTC (permalink / raw)
To: Julien Grall, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
On 10.05.19 18:45, Julien Grall wrote:
Hi, Julien
>
>
> On 10/05/2019 16:29, Oleksandr wrote:
>>
>> Hello, all
>>
>>
>> gentle reminder...
>
> This is on my long queue of patches to review. Any help reviewing the
> on-going series will help.
Oh, I see. Fair enough.
>
> Cheers,
>
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [RFC PATCH 1/2] xen/device-tree: Add dt_count_phandle_with_args helper
@ 2019-05-20 11:03 ` Julien Grall
0 siblings, 0 replies; 26+ messages in thread
From: Julien Grall @ 2019-05-20 11:03 UTC (permalink / raw)
To: Oleksandr Tyshchenko, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
Hi,
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Port Linux helper of_count_phandle_with_args for counting
> number of phandles in a property.
Linux 5.1 uses a completely different implementation for
of_count_phandle_with_args. So which version of Linux did you port from?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [RFC PATCH 1/2] xen/device-tree: Add dt_count_phandle_with_args helper
@ 2019-05-20 11:03 ` Julien Grall
0 siblings, 0 replies; 26+ messages in thread
From: Julien Grall @ 2019-05-20 11:03 UTC (permalink / raw)
To: Oleksandr Tyshchenko, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
Hi,
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Port Linux helper of_count_phandle_with_args for counting
> number of phandles in a property.
Linux 5.1 uses a completely different implementation for
of_count_phandle_with_args. So which version of Linux did you port from?
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [RFC PATCH 2/2] xen/device-tree: Add ability to handle nodes with interrupts-extended prop
@ 2019-05-20 12:25 ` Julien Grall
0 siblings, 0 replies; 26+ messages in thread
From: Julien Grall @ 2019-05-20 12:25 UTC (permalink / raw)
To: Oleksandr Tyshchenko, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
Hi,
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Xen expects to see "interrupts" property when parsing host
> device-tree. But, there are cases when some device nodes contain
> "interrupts-extended" property instead.
>
> The good example here is arch timer node for R-Car Gen3/Gen2 family,
> which is mandatory device for Xen usage on ARM. And without ability
> to handle such nodes, Xen fails to operate:
Per the binding documentation [1], the interrupts-extend property should only be
used when a device has multiple interrupt parents. This is not the case of the
arch timer, so why is it used there?
Don't get me wrong, I am fine with the idea of adding "interrupts-extend".
However, the commit message should give some ground why a new property has been
introduced/used over the current one.
>
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Timer: Unable to retrieve IRQ 0 from the device tree
> (XEN) ****************************************
>
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> ---
> xen/common/device_tree.c | 32 +++++++++++++++++++++++++++++---
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 65862b5..00ada6e 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -987,9 +987,19 @@ unsigned int dt_number_of_irq(const struct dt_device_node *device)
> const struct dt_device_node *p;
> const __be32 *intspec, *tmp;
> u32 intsize, intlen;
> + int intnum;
>
> dt_dprintk("dt_irq_number: dev=%s\n", device->full_name);
>
> + /* Try the new-style interrupts-extended first */
> + intnum = dt_count_phandle_with_args(device, "interrupts-extended",
> + "#interrupt-cells");
> + if ( intnum > 0 )
IIUC dt_count_phandle_with_args, 0 would means the property is present but
doesn't contain any interrupts. I do agree this is a probably a wrong
device-tree, but technically I am not sure we should try to look for
"#interrupts" if intnum = 0.
> + {
> + dt_dprintk(" intnum=%d\n", intnum);
You are re-using the exact same debug message as for "interrupts". So it would
be difficult for a developer to know exactly which path is used. Could we print
message regarding whether "interrupts-extended" or "interrupts" is used?
> + return intnum;
> + }
> +
> /* Get the interrupts property */
> intspec = dt_get_property(device, "interrupts", &intlen);
> if ( intspec == NULL )
> @@ -1420,10 +1430,29 @@ int dt_device_get_raw_irq(const struct dt_device_node *device,
> const __be32 *intspec, *tmp, *addr;
> u32 intsize, intlen;
> int res = -EINVAL;
> + struct dt_phandle_args args;
> + int i;
>
> dt_dprintk("dt_device_get_raw_irq: dev=%s, index=%u\n",
> device->full_name, index);
>
> + /* Get the reg property (if any) */
> + addr = dt_get_property(device, "reg", NULL);
> +
> + /* Try the new-style interrupts-extended first */
> + res = dt_parse_phandle_with_args(device, "interrupts-extended",
> + "#interrupt-cells", index, &args);
> + if ( !res )
I don't think the check is correct. dt_parse_phandle_with_args may return a
negative value in case of an error. So we likely want "res >= 0" here.
> + {
> + dt_dprintk(" intspec=%d intsize=%d\n", args.args[0], args.args_count);
Same remark for the message here.
> +
> + for ( i = 0; i < args.args_count; i++ )
> + args.args[i] = cpu_to_be32(args.args[i]);
> +
> + return dt_irq_map_raw(args.np, args.args, args.args_count,
> + addr, out_irq);
> + }
> +
> /* Get the interrupts property */
> intspec = dt_get_property(device, "interrupts", &intlen);
> if ( intspec == NULL )
> @@ -1432,9 +1461,6 @@ int dt_device_get_raw_irq(const struct dt_device_node *device,
>
> dt_dprintk(" intspec=%d intlen=%d\n", be32_to_cpup(intspec), intlen);
>
> - /* Get the reg property (if any) */
> - addr = dt_get_property(device, "reg", NULL);
> -
> /* Look for the interrupt parent. */
> p = dt_irq_find_parent(device);
> if ( p == NULL )
>
Cheers,
[1] linux/Documentation/devicetree/bindings/interrupt-controller
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [RFC PATCH 2/2] xen/device-tree: Add ability to handle nodes with interrupts-extended prop
@ 2019-05-20 12:25 ` Julien Grall
0 siblings, 0 replies; 26+ messages in thread
From: Julien Grall @ 2019-05-20 12:25 UTC (permalink / raw)
To: Oleksandr Tyshchenko, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
Hi,
On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>
> Xen expects to see "interrupts" property when parsing host
> device-tree. But, there are cases when some device nodes contain
> "interrupts-extended" property instead.
>
> The good example here is arch timer node for R-Car Gen3/Gen2 family,
> which is mandatory device for Xen usage on ARM. And without ability
> to handle such nodes, Xen fails to operate:
Per the binding documentation [1], the interrupts-extend property should only be
used when a device has multiple interrupt parents. This is not the case of the
arch timer, so why is it used there?
Don't get me wrong, I am fine with the idea of adding "interrupts-extend".
However, the commit message should give some ground why a new property has been
introduced/used over the current one.
>
> (XEN) ****************************************
> (XEN) Panic on CPU 0:
> (XEN) Timer: Unable to retrieve IRQ 0 from the device tree
> (XEN) ****************************************
>
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
> ---
> xen/common/device_tree.c | 32 +++++++++++++++++++++++++++++---
> 1 file changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> index 65862b5..00ada6e 100644
> --- a/xen/common/device_tree.c
> +++ b/xen/common/device_tree.c
> @@ -987,9 +987,19 @@ unsigned int dt_number_of_irq(const struct dt_device_node *device)
> const struct dt_device_node *p;
> const __be32 *intspec, *tmp;
> u32 intsize, intlen;
> + int intnum;
>
> dt_dprintk("dt_irq_number: dev=%s\n", device->full_name);
>
> + /* Try the new-style interrupts-extended first */
> + intnum = dt_count_phandle_with_args(device, "interrupts-extended",
> + "#interrupt-cells");
> + if ( intnum > 0 )
IIUC dt_count_phandle_with_args, 0 would means the property is present but
doesn't contain any interrupts. I do agree this is a probably a wrong
device-tree, but technically I am not sure we should try to look for
"#interrupts" if intnum = 0.
> + {
> + dt_dprintk(" intnum=%d\n", intnum);
You are re-using the exact same debug message as for "interrupts". So it would
be difficult for a developer to know exactly which path is used. Could we print
message regarding whether "interrupts-extended" or "interrupts" is used?
> + return intnum;
> + }
> +
> /* Get the interrupts property */
> intspec = dt_get_property(device, "interrupts", &intlen);
> if ( intspec == NULL )
> @@ -1420,10 +1430,29 @@ int dt_device_get_raw_irq(const struct dt_device_node *device,
> const __be32 *intspec, *tmp, *addr;
> u32 intsize, intlen;
> int res = -EINVAL;
> + struct dt_phandle_args args;
> + int i;
>
> dt_dprintk("dt_device_get_raw_irq: dev=%s, index=%u\n",
> device->full_name, index);
>
> + /* Get the reg property (if any) */
> + addr = dt_get_property(device, "reg", NULL);
> +
> + /* Try the new-style interrupts-extended first */
> + res = dt_parse_phandle_with_args(device, "interrupts-extended",
> + "#interrupt-cells", index, &args);
> + if ( !res )
I don't think the check is correct. dt_parse_phandle_with_args may return a
negative value in case of an error. So we likely want "res >= 0" here.
> + {
> + dt_dprintk(" intspec=%d intsize=%d\n", args.args[0], args.args_count);
Same remark for the message here.
> +
> + for ( i = 0; i < args.args_count; i++ )
> + args.args[i] = cpu_to_be32(args.args[i]);
> +
> + return dt_irq_map_raw(args.np, args.args, args.args_count,
> + addr, out_irq);
> + }
> +
> /* Get the interrupts property */
> intspec = dt_get_property(device, "interrupts", &intlen);
> if ( intspec == NULL )
> @@ -1432,9 +1461,6 @@ int dt_device_get_raw_irq(const struct dt_device_node *device,
>
> dt_dprintk(" intspec=%d intlen=%d\n", be32_to_cpup(intspec), intlen);
>
> - /* Get the reg property (if any) */
> - addr = dt_get_property(device, "reg", NULL);
> -
> /* Look for the interrupt parent. */
> p = dt_irq_find_parent(device);
> if ( p == NULL )
>
Cheers,
[1] linux/Documentation/devicetree/bindings/interrupt-controller
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [RFC PATCH 1/2] xen/device-tree: Add dt_count_phandle_with_args helper
@ 2019-05-20 13:48 ` Oleksandr
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr @ 2019-05-20 13:48 UTC (permalink / raw)
To: Julien Grall, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
On 20.05.19 14:03, Julien Grall wrote:
> Hi,
Hi, Julien
>
> On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Port Linux helper of_count_phandle_with_args for counting
>> number of phandles in a property.
>
> Linux 5.1 uses a completely different implementation for
> of_count_phandle_with_args. So which version of Linux did you port from?
This patch is exactly the same one [1], I did more than 2 years ago in
the context of non-shared IOMMU patch series. Likely, I was based on v4.4.
Sorry for the confusing description.
You are right, current implementation of_count_phandle_with_args is
completely different, and I am afraid, is not easily back-portable to Xen.
If the implementation "v4.4" looks correct and fits in current Xen
codebase, I can recollect an exact version and update the patch
description.
What do you think?
[1] https://patchwork.kernel.org/patch/9862557/
>
> Cheers,
>
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [RFC PATCH 1/2] xen/device-tree: Add dt_count_phandle_with_args helper
@ 2019-05-20 13:48 ` Oleksandr
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr @ 2019-05-20 13:48 UTC (permalink / raw)
To: Julien Grall, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
On 20.05.19 14:03, Julien Grall wrote:
> Hi,
Hi, Julien
>
> On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Port Linux helper of_count_phandle_with_args for counting
>> number of phandles in a property.
>
> Linux 5.1 uses a completely different implementation for
> of_count_phandle_with_args. So which version of Linux did you port from?
This patch is exactly the same one [1], I did more than 2 years ago in
the context of non-shared IOMMU patch series. Likely, I was based on v4.4.
Sorry for the confusing description.
You are right, current implementation of_count_phandle_with_args is
completely different, and I am afraid, is not easily back-portable to Xen.
If the implementation "v4.4" looks correct and fits in current Xen
codebase, I can recollect an exact version and update the patch
description.
What do you think?
[1] https://patchwork.kernel.org/patch/9862557/
>
> Cheers,
>
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [RFC PATCH 1/2] xen/device-tree: Add dt_count_phandle_with_args helper
@ 2019-05-20 14:37 ` Julien Grall
0 siblings, 0 replies; 26+ messages in thread
From: Julien Grall @ 2019-05-20 14:37 UTC (permalink / raw)
To: Oleksandr, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
On 20/05/2019 14:48, Oleksandr wrote:
>
> On 20.05.19 14:03, Julien Grall wrote:
>> Hi,
>
> Hi, Julien
>
>
>>
>> On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>
>>> Port Linux helper of_count_phandle_with_args for counting
>>> number of phandles in a property.
>>
>> Linux 5.1 uses a completely different implementation for
>> of_count_phandle_with_args. So which version of Linux did you port from?
>
> This patch is exactly the same one [1], I did more than 2 years ago in the
> context of non-shared IOMMU patch series. Likely, I was based on v4.4.
>
> Sorry for the confusing description.
>
>
> You are right, current implementation of_count_phandle_with_args is completely
> different, and I am afraid, is not easily back-portable to Xen.
>
> If the implementation "v4.4" looks correct and fits in current Xen codebase, I
> can recollect an exact version and update the patch description.
>
> What do you think?
The current implementation looks correct. So the commit message needs to be updated.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [RFC PATCH 1/2] xen/device-tree: Add dt_count_phandle_with_args helper
@ 2019-05-20 14:37 ` Julien Grall
0 siblings, 0 replies; 26+ messages in thread
From: Julien Grall @ 2019-05-20 14:37 UTC (permalink / raw)
To: Oleksandr, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
On 20/05/2019 14:48, Oleksandr wrote:
>
> On 20.05.19 14:03, Julien Grall wrote:
>> Hi,
>
> Hi, Julien
>
>
>>
>> On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>
>>> Port Linux helper of_count_phandle_with_args for counting
>>> number of phandles in a property.
>>
>> Linux 5.1 uses a completely different implementation for
>> of_count_phandle_with_args. So which version of Linux did you port from?
>
> This patch is exactly the same one [1], I did more than 2 years ago in the
> context of non-shared IOMMU patch series. Likely, I was based on v4.4.
>
> Sorry for the confusing description.
>
>
> You are right, current implementation of_count_phandle_with_args is completely
> different, and I am afraid, is not easily back-portable to Xen.
>
> If the implementation "v4.4" looks correct and fits in current Xen codebase, I
> can recollect an exact version and update the patch description.
>
> What do you think?
The current implementation looks correct. So the commit message needs to be updated.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [RFC PATCH 2/2] xen/device-tree: Add ability to handle nodes with interrupts-extended prop
@ 2019-05-20 16:10 ` Oleksandr
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr @ 2019-05-20 16:10 UTC (permalink / raw)
To: Julien Grall, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
On 20.05.19 15:25, Julien Grall wrote:
> Hi,
Hi, Julien.
>
> On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Xen expects to see "interrupts" property when parsing host
>> device-tree. But, there are cases when some device nodes contain
>> "interrupts-extended" property instead.
>>
>> The good example here is arch timer node for R-Car Gen3/Gen2 family,
>> which is mandatory device for Xen usage on ARM. And without ability
>> to handle such nodes, Xen fails to operate:
>
> Per the binding documentation [1], the interrupts-extend property
> should only be used when a device has multiple interrupt parents. This
> is not the case of the arch timer, so why is it used there?
> Don't get me wrong, I am fine with the idea of adding
> "interrupts-extend". However, the commit message should give some
> ground why a new property has been introduced/used over the current one.
Have just grepped, looks like, R-Car Gen2/Gen3 dtsi files are not the
only single users of "interrupts-extended" property for a device with a
single interrupt parent...
Unfortunately, I don't know the real reason, can guess only that for a
device (with a single interrupt parent) outside "/soc" container the
usage of single "interrupts-extended" property is more simpler/cleaner
than usage of pairs ("interrupt-parent" + "interrupts"). Looks like,
the patch "ARM: dts: r8a7790: add soc node" from this series [1] started
using "interrupts-extended" property for ARCH timer node. I will mention
that in patch description.
>> + /* Try the new-style interrupts-extended first */
>> + intnum = dt_count_phandle_with_args(device, "interrupts-extended",
>> + "#interrupt-cells");
>> + if ( intnum > 0 )
>
> IIUC dt_count_phandle_with_args, 0 would means the property is present
> but doesn't contain any interrupts. I do agree this is a probably a
> wrong device-tree, but technically I am not sure we should try to look
> for "#interrupts" if intnum = 0.
agree, will return 0 if intnum == 0
>
>> + {
>> + dt_dprintk(" intnum=%d\n", intnum);
>
> You are re-using the exact same debug message as for "interrupts". So
> it would be difficult for a developer to know exactly which path is
> used. Could we print message regarding whether "interrupts-extended"
> or "interrupts" is used?
I couldn't find where else the same debug message was used, could you,
please, point me? But, I don't mind to add some indicator. For
"interrupts-extended" path (newly added prints) I can add the
corresponding prefix...
>
>
>> + return intnum;
>> + }
>> +
>> /* Get the interrupts property */
>> intspec = dt_get_property(device, "interrupts", &intlen);
>> if ( intspec == NULL )
>> @@ -1420,10 +1430,29 @@ int dt_device_get_raw_irq(const struct
>> dt_device_node *device,
>> const __be32 *intspec, *tmp, *addr;
>> u32 intsize, intlen;
>> int res = -EINVAL;
>> + struct dt_phandle_args args;
>> + int i;
>> dt_dprintk("dt_device_get_raw_irq: dev=%s, index=%u\n",
>> device->full_name, index);
>> + /* Get the reg property (if any) */
>> + addr = dt_get_property(device, "reg", NULL);
>> +
>> + /* Try the new-style interrupts-extended first */
>> + res = dt_parse_phandle_with_args(device, "interrupts-extended",
>> + "#interrupt-cells", index, &args);
>> + if ( !res )
>
> I don't think the check is correct. dt_parse_phandle_with_args may
> return a negative value in case of an error. So we likely want "res >=
> 0" here.
I am not sure I understand your point correctly. Why do we need to check
for res > 0 as well?
If index is not -1, then function will return either 0 (on success) or
-ERR_XXX.
>
>
>> + {
>> + dt_dprintk(" intspec=%d intsize=%d\n", args.args[0],
>> args.args_count);
>
> Same remark for the message here.
agree.
[1] https://www.spinics.net/lists/linux-renesas-soc/msg22539.html
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [RFC PATCH 2/2] xen/device-tree: Add ability to handle nodes with interrupts-extended prop
@ 2019-05-20 16:10 ` Oleksandr
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr @ 2019-05-20 16:10 UTC (permalink / raw)
To: Julien Grall, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
On 20.05.19 15:25, Julien Grall wrote:
> Hi,
Hi, Julien.
>
> On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>
>> Xen expects to see "interrupts" property when parsing host
>> device-tree. But, there are cases when some device nodes contain
>> "interrupts-extended" property instead.
>>
>> The good example here is arch timer node for R-Car Gen3/Gen2 family,
>> which is mandatory device for Xen usage on ARM. And without ability
>> to handle such nodes, Xen fails to operate:
>
> Per the binding documentation [1], the interrupts-extend property
> should only be used when a device has multiple interrupt parents. This
> is not the case of the arch timer, so why is it used there?
> Don't get me wrong, I am fine with the idea of adding
> "interrupts-extend". However, the commit message should give some
> ground why a new property has been introduced/used over the current one.
Have just grepped, looks like, R-Car Gen2/Gen3 dtsi files are not the
only single users of "interrupts-extended" property for a device with a
single interrupt parent...
Unfortunately, I don't know the real reason, can guess only that for a
device (with a single interrupt parent) outside "/soc" container the
usage of single "interrupts-extended" property is more simpler/cleaner
than usage of pairs ("interrupt-parent" + "interrupts"). Looks like,
the patch "ARM: dts: r8a7790: add soc node" from this series [1] started
using "interrupts-extended" property for ARCH timer node. I will mention
that in patch description.
>> + /* Try the new-style interrupts-extended first */
>> + intnum = dt_count_phandle_with_args(device, "interrupts-extended",
>> + "#interrupt-cells");
>> + if ( intnum > 0 )
>
> IIUC dt_count_phandle_with_args, 0 would means the property is present
> but doesn't contain any interrupts. I do agree this is a probably a
> wrong device-tree, but technically I am not sure we should try to look
> for "#interrupts" if intnum = 0.
agree, will return 0 if intnum == 0
>
>> + {
>> + dt_dprintk(" intnum=%d\n", intnum);
>
> You are re-using the exact same debug message as for "interrupts". So
> it would be difficult for a developer to know exactly which path is
> used. Could we print message regarding whether "interrupts-extended"
> or "interrupts" is used?
I couldn't find where else the same debug message was used, could you,
please, point me? But, I don't mind to add some indicator. For
"interrupts-extended" path (newly added prints) I can add the
corresponding prefix...
>
>
>> + return intnum;
>> + }
>> +
>> /* Get the interrupts property */
>> intspec = dt_get_property(device, "interrupts", &intlen);
>> if ( intspec == NULL )
>> @@ -1420,10 +1430,29 @@ int dt_device_get_raw_irq(const struct
>> dt_device_node *device,
>> const __be32 *intspec, *tmp, *addr;
>> u32 intsize, intlen;
>> int res = -EINVAL;
>> + struct dt_phandle_args args;
>> + int i;
>> dt_dprintk("dt_device_get_raw_irq: dev=%s, index=%u\n",
>> device->full_name, index);
>> + /* Get the reg property (if any) */
>> + addr = dt_get_property(device, "reg", NULL);
>> +
>> + /* Try the new-style interrupts-extended first */
>> + res = dt_parse_phandle_with_args(device, "interrupts-extended",
>> + "#interrupt-cells", index, &args);
>> + if ( !res )
>
> I don't think the check is correct. dt_parse_phandle_with_args may
> return a negative value in case of an error. So we likely want "res >=
> 0" here.
I am not sure I understand your point correctly. Why do we need to check
for res > 0 as well?
If index is not -1, then function will return either 0 (on success) or
-ERR_XXX.
>
>
>> + {
>> + dt_dprintk(" intspec=%d intsize=%d\n", args.args[0],
>> args.args_count);
>
> Same remark for the message here.
agree.
[1] https://www.spinics.net/lists/linux-renesas-soc/msg22539.html
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [RFC PATCH 2/2] xen/device-tree: Add ability to handle nodes with interrupts-extended prop
@ 2019-05-20 16:27 ` Julien Grall
0 siblings, 0 replies; 26+ messages in thread
From: Julien Grall @ 2019-05-20 16:27 UTC (permalink / raw)
To: Oleksandr, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
On 20/05/2019 17:10, Oleksandr wrote:
>
> On 20.05.19 15:25, Julien Grall wrote:
>> Hi,
>
> Hi, Julien.
>
>
>>
>> On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>
>>> Xen expects to see "interrupts" property when parsing host
>>> device-tree. But, there are cases when some device nodes contain
>>> "interrupts-extended" property instead.
>>>
>>> The good example here is arch timer node for R-Car Gen3/Gen2 family,
>>> which is mandatory device for Xen usage on ARM. And without ability
>>> to handle such nodes, Xen fails to operate:
>>
>> Per the binding documentation [1], the interrupts-extend property should only
>> be used when a device has multiple interrupt parents. This is not the case of
>> the arch timer, so why is it used there?
>> Don't get me wrong, I am fine with the idea of adding "interrupts-extend".
>> However, the commit message should give some ground why a new property has
>> been introduced/used over the current one.
>
> Have just grepped, looks like, R-Car Gen2/Gen3 dtsi files are not the only
> single users of "interrupts-extended" property for a device with a single
> interrupt parent...
>
> Unfortunately, I don't know the real reason, can guess only that for a device
> (with a single interrupt parent) outside "/soc" container the usage of single
> "interrupts-extended" property is more simpler/cleaner than usage of pairs
> ("interrupt-parent" + "interrupts"). Looks like, the patch "ARM: dts: r8a7790:
> add soc node" from this series [1] started using "interrupts-extended" property
> for ARCH timer node. I will mention that in patch description.
I don't think it is important to know why Renesas is using it. What matter is
the property allows to describe in DT a device with interrupts coming from
multiple interrupt controllers.
In other words, what I ask is explaining in the commit message what this
property is used for and properly a pointer to the bindings helping the reviewer
to find out what you speak about.
>
>
>>> + /* Try the new-style interrupts-extended first */
>>> + intnum = dt_count_phandle_with_args(device, "interrupts-extended",
>>> + "#interrupt-cells");
>>> + if ( intnum > 0 )
>>
>> IIUC dt_count_phandle_with_args, 0 would means the property is present but
>> doesn't contain any interrupts. I do agree this is a probably a wrong
>> device-tree, but technically I am not sure we should try to look for
>> "#interrupts" if intnum = 0.
>
> agree, will return 0 if intnum == 0
>
>
>>
>>> + {
>>> + dt_dprintk(" intnum=%d\n", intnum);
>>
>> You are re-using the exact same debug message as for "interrupts". So it would
>> be difficult for a developer to know exactly which path is used. Could we
>> print message regarding whether "interrupts-extended" or "interrupts" is used?
>
> I couldn't find where else the same debug message was used, could you, please,
> point me? But, I don't mind to add some indicator. For "interrupts-extended"
> path (newly added prints) I can add the corresponding prefix...
Sorry, I thought the message was duplicated. However, I still think a message
telling which property is used would be useful.
>
>
>>
>>
>>> + return intnum;
>>> + }
>>> +
>>> /* Get the interrupts property */
>>> intspec = dt_get_property(device, "interrupts", &intlen);
>>> if ( intspec == NULL )
>>> @@ -1420,10 +1430,29 @@ int dt_device_get_raw_irq(const struct dt_device_node
>>> *device,
>>> const __be32 *intspec, *tmp, *addr;
>>> u32 intsize, intlen;
>>> int res = -EINVAL;
>>> + struct dt_phandle_args args;
>>> + int i;
>>> dt_dprintk("dt_device_get_raw_irq: dev=%s, index=%u\n",
>>> device->full_name, index);
>>> + /* Get the reg property (if any) */
>>> + addr = dt_get_property(device, "reg", NULL);
>>> +
>>> + /* Try the new-style interrupts-extended first */
>>> + res = dt_parse_phandle_with_args(device, "interrupts-extended",
>>> + "#interrupt-cells", index, &args);
>>> + if ( !res )
>>
>> I don't think the check is correct. dt_parse_phandle_with_args may return a
>> negative value in case of an error. So we likely want "res >= 0" here.
>
> I am not sure I understand your point correctly. Why do we need to check for res
> > 0 as well?
>
> If index is not -1, then function will return either 0 (on success) or -ERR_XXX.
But I misread the code. Sorry for the noise.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [RFC PATCH 2/2] xen/device-tree: Add ability to handle nodes with interrupts-extended prop
@ 2019-05-20 16:27 ` Julien Grall
0 siblings, 0 replies; 26+ messages in thread
From: Julien Grall @ 2019-05-20 16:27 UTC (permalink / raw)
To: Oleksandr, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
On 20/05/2019 17:10, Oleksandr wrote:
>
> On 20.05.19 15:25, Julien Grall wrote:
>> Hi,
>
> Hi, Julien.
>
>
>>
>> On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>
>>> Xen expects to see "interrupts" property when parsing host
>>> device-tree. But, there are cases when some device nodes contain
>>> "interrupts-extended" property instead.
>>>
>>> The good example here is arch timer node for R-Car Gen3/Gen2 family,
>>> which is mandatory device for Xen usage on ARM. And without ability
>>> to handle such nodes, Xen fails to operate:
>>
>> Per the binding documentation [1], the interrupts-extend property should only
>> be used when a device has multiple interrupt parents. This is not the case of
>> the arch timer, so why is it used there?
>> Don't get me wrong, I am fine with the idea of adding "interrupts-extend".
>> However, the commit message should give some ground why a new property has
>> been introduced/used over the current one.
>
> Have just grepped, looks like, R-Car Gen2/Gen3 dtsi files are not the only
> single users of "interrupts-extended" property for a device with a single
> interrupt parent...
>
> Unfortunately, I don't know the real reason, can guess only that for a device
> (with a single interrupt parent) outside "/soc" container the usage of single
> "interrupts-extended" property is more simpler/cleaner than usage of pairs
> ("interrupt-parent" + "interrupts"). Looks like, the patch "ARM: dts: r8a7790:
> add soc node" from this series [1] started using "interrupts-extended" property
> for ARCH timer node. I will mention that in patch description.
I don't think it is important to know why Renesas is using it. What matter is
the property allows to describe in DT a device with interrupts coming from
multiple interrupt controllers.
In other words, what I ask is explaining in the commit message what this
property is used for and properly a pointer to the bindings helping the reviewer
to find out what you speak about.
>
>
>>> + /* Try the new-style interrupts-extended first */
>>> + intnum = dt_count_phandle_with_args(device, "interrupts-extended",
>>> + "#interrupt-cells");
>>> + if ( intnum > 0 )
>>
>> IIUC dt_count_phandle_with_args, 0 would means the property is present but
>> doesn't contain any interrupts. I do agree this is a probably a wrong
>> device-tree, but technically I am not sure we should try to look for
>> "#interrupts" if intnum = 0.
>
> agree, will return 0 if intnum == 0
>
>
>>
>>> + {
>>> + dt_dprintk(" intnum=%d\n", intnum);
>>
>> You are re-using the exact same debug message as for "interrupts". So it would
>> be difficult for a developer to know exactly which path is used. Could we
>> print message regarding whether "interrupts-extended" or "interrupts" is used?
>
> I couldn't find where else the same debug message was used, could you, please,
> point me? But, I don't mind to add some indicator. For "interrupts-extended"
> path (newly added prints) I can add the corresponding prefix...
Sorry, I thought the message was duplicated. However, I still think a message
telling which property is used would be useful.
>
>
>>
>>
>>> + return intnum;
>>> + }
>>> +
>>> /* Get the interrupts property */
>>> intspec = dt_get_property(device, "interrupts", &intlen);
>>> if ( intspec == NULL )
>>> @@ -1420,10 +1430,29 @@ int dt_device_get_raw_irq(const struct dt_device_node
>>> *device,
>>> const __be32 *intspec, *tmp, *addr;
>>> u32 intsize, intlen;
>>> int res = -EINVAL;
>>> + struct dt_phandle_args args;
>>> + int i;
>>> dt_dprintk("dt_device_get_raw_irq: dev=%s, index=%u\n",
>>> device->full_name, index);
>>> + /* Get the reg property (if any) */
>>> + addr = dt_get_property(device, "reg", NULL);
>>> +
>>> + /* Try the new-style interrupts-extended first */
>>> + res = dt_parse_phandle_with_args(device, "interrupts-extended",
>>> + "#interrupt-cells", index, &args);
>>> + if ( !res )
>>
>> I don't think the check is correct. dt_parse_phandle_with_args may return a
>> negative value in case of an error. So we likely want "res >= 0" here.
>
> I am not sure I understand your point correctly. Why do we need to check for res
> > 0 as well?
>
> If index is not -1, then function will return either 0 (on success) or -ERR_XXX.
But I misread the code. Sorry for the noise.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [RFC PATCH 2/2] xen/device-tree: Add ability to handle nodes with interrupts-extended prop
@ 2019-05-20 16:43 ` Oleksandr
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr @ 2019-05-20 16:43 UTC (permalink / raw)
To: Julien Grall, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
Hi, Julien
>>
>>
>>>
>>> On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>
>>>> Xen expects to see "interrupts" property when parsing host
>>>> device-tree. But, there are cases when some device nodes contain
>>>> "interrupts-extended" property instead.
>>>>
>>>> The good example here is arch timer node for R-Car Gen3/Gen2 family,
>>>> which is mandatory device for Xen usage on ARM. And without ability
>>>> to handle such nodes, Xen fails to operate:
>>>
>>> Per the binding documentation [1], the interrupts-extend property
>>> should only be used when a device has multiple interrupt parents.
>>> This is not the case of the arch timer, so why is it used there?
>>> Don't get me wrong, I am fine with the idea of adding
>>> "interrupts-extend". However, the commit message should give some
>>> ground why a new property has been introduced/used over the current
>>> one.
>>
>> Have just grepped, looks like, R-Car Gen2/Gen3 dtsi files are not the
>> only single users of "interrupts-extended" property for a device with
>> a single interrupt parent...
>>
>> Unfortunately, I don't know the real reason, can guess only that for
>> a device (with a single interrupt parent) outside "/soc" container
>> the usage of single "interrupts-extended" property is more
>> simpler/cleaner than usage of pairs ("interrupt-parent" +
>> "interrupts"). Looks like, the patch "ARM: dts: r8a7790: add soc
>> node" from this series [1] started using "interrupts-extended"
>> property for ARCH timer node. I will mention that in patch description.
>
> I don't think it is important to know why Renesas is using it. What
> matter is the property allows to describe in DT a device with
> interrupts coming from multiple interrupt controllers.
>
> In other words, what I ask is explaining in the commit message what
> this property is used for and properly a pointer to the bindings
> helping the reviewer to find out what you speak about.
OK. Sounds reasonable. Will add an information regarding the property
itself with link. Should I retain the original sentences (regarding ARCH
timer on R-Car uses it, etc) as well?
>>
>>
>>>
>>>> + {
>>>> + dt_dprintk(" intnum=%d\n", intnum);
>>>
>>> You are re-using the exact same debug message as for "interrupts".
>>> So it would be difficult for a developer to know exactly which path
>>> is used. Could we print message regarding whether
>>> "interrupts-extended" or "interrupts" is used?
>>
>> I couldn't find where else the same debug message was used, could
>> you, please, point me? But, I don't mind to add some indicator. For
>> "interrupts-extended" path (newly added prints) I can add the
>> corresponding prefix...
>
> Sorry, I thought the message was duplicated. However, I still think a
> message telling which property is used would be useful.
Just to clarify: should I add for the newly added messages
("interrupts-extended" path) only? Or I should modify existing messages
for "interrupts" path also?
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [Xen-devel] [RFC PATCH 2/2] xen/device-tree: Add ability to handle nodes with interrupts-extended prop
@ 2019-05-20 16:43 ` Oleksandr
0 siblings, 0 replies; 26+ messages in thread
From: Oleksandr @ 2019-05-20 16:43 UTC (permalink / raw)
To: Julien Grall, xen-devel; +Cc: Oleksandr Tyshchenko, sstabellini
Hi, Julien
>>
>>
>>>
>>> On 02/05/2019 15:13, Oleksandr Tyshchenko wrote:
>>>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@epam.com>
>>>>
>>>> Xen expects to see "interrupts" property when parsing host
>>>> device-tree. But, there are cases when some device nodes contain
>>>> "interrupts-extended" property instead.
>>>>
>>>> The good example here is arch timer node for R-Car Gen3/Gen2 family,
>>>> which is mandatory device for Xen usage on ARM. And without ability
>>>> to handle such nodes, Xen fails to operate:
>>>
>>> Per the binding documentation [1], the interrupts-extend property
>>> should only be used when a device has multiple interrupt parents.
>>> This is not the case of the arch timer, so why is it used there?
>>> Don't get me wrong, I am fine with the idea of adding
>>> "interrupts-extend". However, the commit message should give some
>>> ground why a new property has been introduced/used over the current
>>> one.
>>
>> Have just grepped, looks like, R-Car Gen2/Gen3 dtsi files are not the
>> only single users of "interrupts-extended" property for a device with
>> a single interrupt parent...
>>
>> Unfortunately, I don't know the real reason, can guess only that for
>> a device (with a single interrupt parent) outside "/soc" container
>> the usage of single "interrupts-extended" property is more
>> simpler/cleaner than usage of pairs ("interrupt-parent" +
>> "interrupts"). Looks like, the patch "ARM: dts: r8a7790: add soc
>> node" from this series [1] started using "interrupts-extended"
>> property for ARCH timer node. I will mention that in patch description.
>
> I don't think it is important to know why Renesas is using it. What
> matter is the property allows to describe in DT a device with
> interrupts coming from multiple interrupt controllers.
>
> In other words, what I ask is explaining in the commit message what
> this property is used for and properly a pointer to the bindings
> helping the reviewer to find out what you speak about.
OK. Sounds reasonable. Will add an information regarding the property
itself with link. Should I retain the original sentences (regarding ARCH
timer on R-Car uses it, etc) as well?
>>
>>
>>>
>>>> + {
>>>> + dt_dprintk(" intnum=%d\n", intnum);
>>>
>>> You are re-using the exact same debug message as for "interrupts".
>>> So it would be difficult for a developer to know exactly which path
>>> is used. Could we print message regarding whether
>>> "interrupts-extended" or "interrupts" is used?
>>
>> I couldn't find where else the same debug message was used, could
>> you, please, point me? But, I don't mind to add some indicator. For
>> "interrupts-extended" path (newly added prints) I can add the
>> corresponding prefix...
>
> Sorry, I thought the message was duplicated. However, I still think a
> message telling which property is used would be useful.
Just to clarify: should I add for the newly added messages
("interrupts-extended" path) only? Or I should modify existing messages
for "interrupts" path also?
--
Regards,
Oleksandr Tyshchenko
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2019-05-20 16:44 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-02 14:13 [RFC PATCH 0/2] Add ability to handle nodes with interrupts-extended property Oleksandr Tyshchenko
2019-05-02 14:13 ` [Xen-devel] " Oleksandr Tyshchenko
2019-05-02 14:13 ` [RFC PATCH 1/2] xen/device-tree: Add dt_count_phandle_with_args helper Oleksandr Tyshchenko
2019-05-02 14:13 ` [Xen-devel] " Oleksandr Tyshchenko
2019-05-20 11:03 ` Julien Grall
2019-05-20 11:03 ` [Xen-devel] " Julien Grall
2019-05-20 13:48 ` Oleksandr
2019-05-20 13:48 ` [Xen-devel] " Oleksandr
2019-05-20 14:37 ` Julien Grall
2019-05-20 14:37 ` [Xen-devel] " Julien Grall
2019-05-02 14:13 ` [RFC PATCH 2/2] xen/device-tree: Add ability to handle nodes with interrupts-extended prop Oleksandr Tyshchenko
2019-05-02 14:13 ` [Xen-devel] " Oleksandr Tyshchenko
2019-05-20 12:25 ` Julien Grall
2019-05-20 12:25 ` [Xen-devel] " Julien Grall
2019-05-20 16:10 ` Oleksandr
2019-05-20 16:10 ` [Xen-devel] " Oleksandr
2019-05-20 16:27 ` Julien Grall
2019-05-20 16:27 ` [Xen-devel] " Julien Grall
2019-05-20 16:43 ` Oleksandr
2019-05-20 16:43 ` [Xen-devel] " Oleksandr
2019-05-10 15:29 ` [RFC PATCH 0/2] Add ability to handle nodes with interrupts-extended property Oleksandr
2019-05-10 15:29 ` [Xen-devel] " Oleksandr
2019-05-10 15:45 ` Julien Grall
2019-05-10 15:45 ` [Xen-devel] " Julien Grall
2019-05-10 17:02 ` Oleksandr
2019-05-10 17:02 ` [Xen-devel] " Oleksandr
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.