[PATCH] MAINTAINERS: fix incorrect directory reference
the below-mentioned commit moved headers to inlucde/linux/soc/mmp. MAINTAINERS
was updated, but include/ was omitted.
Fixes: 32adcaa010 ("ARM: mmp: move cputype.h to include/linux/soc/")
Signed-off-by: Ralf Ramsauer
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 68f21d46614c..20d897b5be4b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11492,7 +11492,7 @@ S: Odd Fixes
T: git git://git.kernel.org/pub/scm/linux/kernel/git/lkundrak/linux-mmp.git
F: arch/arm/boot/dts/mmp*
F: arch/arm/mach-mmp/
-F: linux/soc/mmp/
+F: include/linux/soc/mmp/
MMP USB PHY DRIVERS
R: Lubomir Rintel
--
2.27.0
[tip: x86/platform] x86/jailhouse: Only enable platform UARTs if available
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 7a56b81c474619fa84c60d07eaa287c8fc33ac3c
Gitweb:
https://git.kernel.org/tip/7a56b81c474619fa84c60d07eaa287c8fc33ac3c
Author:Ralf Ramsauer
AuthorDate:Thu, 10 Oct 2019 12:21:02 +02:00
Committer: Borislav Petkov
CommitterDate: Thu, 10 Oct 2019 15:43:59 +02:00
x86/jailhouse: Only enable platform UARTs if available
ACPI tables aren't available if Linux runs as guest of the hypervisor
Jailhouse. This makes the 8250 driver probe for all platform UARTs as it
assumes that all UARTs are present in case of !ACPI. Jailhouse will stop
execution of Linux guest due to port access violation.
So far, these access violations were solved by tuning the 8250.nr_uarts
cmdline parameter, but this has limitations: Only consecutive platform
UARTs can be mapped to Linux, and only in the sequence 0x3f8, 0x2f8,
0x3e8, 0x2e8.
Beginning from setup_data version 2, Jailhouse will place information of
available platform UARTs in setup_data. This allows for selective
activation of platform UARTs.
Query setup_data version and only activate available UARTS. This
patch comes with backward compatibility, and will still support older
setup_data versions. In case of older setup_data versions, Linux falls
back to the old behaviour.
Signed-off-by: Ralf Ramsauer
Signed-off-by: Borislav Petkov
Reviewed-by: Jan Kiszka
Cc: Baoquan He
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: jailhouse-...@googlegroups.com
Cc: Juergen Gross
Cc: "Kirill A. Shutemov"
Cc: Thomas Gleixner
Cc: x86-ml
Link:
https://lkml.kernel.org/r/20191010102102.421035-3-ralf.ramsa...@oth-regensburg.de
---
arch/x86/include/uapi/asm/bootparam.h | 3 +-
arch/x86/kernel/jailhouse.c | 85 ++
2 files changed, 75 insertions(+), 13 deletions(-)
diff --git a/arch/x86/include/uapi/asm/bootparam.h
b/arch/x86/include/uapi/asm/bootparam.h
index 43be437..db1e24e 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -152,6 +152,9 @@ struct jailhouse_setup_data {
__u8standard_ioapic;
__u8cpu_ids[255];
} __attribute__((packed)) v1;
+ struct {
+ __u32 flags;
+ } __attribute__((packed)) v2;
} __attribute__((packed));
/* The so-called "zeropage" */
diff --git a/arch/x86/kernel/jailhouse.c b/arch/x86/kernel/jailhouse.c
index cf4eb37..6eb8b50 100644
--- a/arch/x86/kernel/jailhouse.c
+++ b/arch/x86/kernel/jailhouse.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -21,11 +22,24 @@
#include
#include
-static __initdata struct jailhouse_setup_data setup_data;
+static struct jailhouse_setup_data setup_data;
#define SETUP_DATA_V1_LEN (sizeof(setup_data.hdr) + sizeof(setup_data.v1))
+#define SETUP_DATA_V2_LEN (SETUP_DATA_V1_LEN + sizeof(setup_data.v2))
static unsigned int precalibrated_tsc_khz;
+static void jailhouse_setup_irq(unsigned int irq)
+{
+ struct mpc_intsrc mp_irq = {
+ .type = MP_INTSRC,
+ .irqtype= mp_INT,
+ .irqflag= MP_IRQPOL_ACTIVE_HIGH | MP_IRQTRIG_EDGE,
+ .srcbusirq = irq,
+ .dstirq = irq,
+ };
+ mp_save_irq(_irq);
+}
+
static uint32_t jailhouse_cpuid_base(void)
{
if (boot_cpu_data.cpuid_level < 0 ||
@@ -79,11 +93,6 @@ static void __init jailhouse_get_smp_config(unsigned int
early)
.type = IOAPIC_DOMAIN_STRICT,
.ops = _ioapic_irqdomain_ops,
};
- struct mpc_intsrc mp_irq = {
- .type = MP_INTSRC,
- .irqtype = mp_INT,
- .irqflag = MP_IRQPOL_ACTIVE_HIGH | MP_IRQTRIG_EDGE,
- };
unsigned int cpu;
jailhouse_x2apic_init();
@@ -100,12 +109,12 @@ static void __init jailhouse_get_smp_config(unsigned int
early)
if (setup_data.v1.standard_ioapic) {
mp_register_ioapic(0, 0xfec0, gsi_top, _cfg);
- /* Register 1:1 mapping for legacy UART IRQs 3 and 4 */
- mp_irq.srcbusirq = mp_irq.dstirq = 3;
- mp_save_irq(_irq);
-
- mp_irq.srcbusirq = mp_irq.dstirq = 4;
- mp_save_irq(_irq);
+ if (IS_ENABLED(CONFIG_SERIAL_8250) &&
+ setup_data.hdr.version < 2) {
+ /* Register 1:1 mapping for legacy UART IRQs 3 and 4 */
+ jailhouse_setup_irq(3);
+ jailhouse_setup_irq(4);
+ }
}
}
@@ -138,6 +147,53 @@ static int __init jailhouse_pci_arch_init(void)
return 0;
}
+#ifdef CONFIG_SERIAL_8250
+static inline bool jailhouse_uart_enabled(unsigned int uart_nr)
+{
+ return setup_data.v2.flags & BIT(uart_nr);
+}
+
+static void jailh
[tip:x86/cpu] x86/cpuid: Switch to 'static const' specifier
Commit-ID: 52586b089cc12d4878e56ee98a4d110fa801758a
Gitweb: https://git.kernel.org/tip/52586b089cc12d4878e56ee98a4d110fa801758a
Author: Ralf Ramsauer <ralf.ramsa...@oth-regensburg.de>
AuthorDate: Wed, 7 Mar 2018 17:07:34 +0100
Committer: Thomas Gleixner <t...@linutronix.de>
CommitDate: Thu, 8 Mar 2018 12:23:42 +0100
x86/cpuid: Switch to 'static const' specifier
This is the only spot where the 'const static' specifier is used;
everywhere else 'static const' is preferred, as static should be the
first specifier.
This is just a cosmetic fix that aligns this, no functional change.
Signed-off-by: Ralf Ramsauer <ralf.ramsa...@oth-regensburg.de>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Andi Kleen <a...@linux.intel.com>
Cc: Gayatri Kammela <gayatri.kamm...@intel.com>
Link:
https://lkml.kernel.org/r/20180307160734.6691-1-ralf.ramsa...@oth-regensburg.de
---
arch/x86/kernel/cpu/cpuid-deps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 904b0a3c4e53..2c0bd38a44ab 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -19,7 +19,7 @@ struct cpuid_dep {
* called from cpu hotplug. It shouldn't do anything in this case,
* but it's difficult to tell that to the init reference checker.
*/
-const static struct cpuid_dep cpuid_deps[] = {
+static const struct cpuid_dep cpuid_deps[] = {
{ X86_FEATURE_XSAVEOPT, X86_FEATURE_XSAVE },
{ X86_FEATURE_XSAVEC, X86_FEATURE_XSAVE },
{ X86_FEATURE_XSAVES, X86_FEATURE_XSAVE },
[tip:x86/cpu] x86/cpuid: Switch to 'static const' specifier
Commit-ID: 52586b089cc12d4878e56ee98a4d110fa801758a
Gitweb: https://git.kernel.org/tip/52586b089cc12d4878e56ee98a4d110fa801758a
Author: Ralf Ramsauer
AuthorDate: Wed, 7 Mar 2018 17:07:34 +0100
Committer: Thomas Gleixner
CommitDate: Thu, 8 Mar 2018 12:23:42 +0100
x86/cpuid: Switch to 'static const' specifier
This is the only spot where the 'const static' specifier is used;
everywhere else 'static const' is preferred, as static should be the
first specifier.
This is just a cosmetic fix that aligns this, no functional change.
Signed-off-by: Ralf Ramsauer
Signed-off-by: Thomas Gleixner
Cc: Andi Kleen
Cc: Gayatri Kammela
Link:
https://lkml.kernel.org/r/20180307160734.6691-1-ralf.ramsa...@oth-regensburg.de
---
arch/x86/kernel/cpu/cpuid-deps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 904b0a3c4e53..2c0bd38a44ab 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -19,7 +19,7 @@ struct cpuid_dep {
* called from cpu hotplug. It shouldn't do anything in this case,
* but it's difficult to tell that to the init reference checker.
*/
-const static struct cpuid_dep cpuid_deps[] = {
+static const struct cpuid_dep cpuid_deps[] = {
{ X86_FEATURE_XSAVEOPT, X86_FEATURE_XSAVE },
{ X86_FEATURE_XSAVEC, X86_FEATURE_XSAVE },
{ X86_FEATURE_XSAVES, X86_FEATURE_XSAVE },
[PATCH] x86/cpuid: Switch to 'static const' specifier
This is the only spot where the 'const static' specifier is used;
everywhere else 'static const' is preferred, as static should be the
first specifier.
This is just a cosmetic fix that aligns this, no functional change.
Signed-off-by: Ralf Ramsauer <ralf.ramsa...@oth-regensburg.de>
---
arch/x86/kernel/cpu/cpuid-deps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 904b0a3c4e53..2c0bd38a44ab 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -19,7 +19,7 @@ struct cpuid_dep {
* called from cpu hotplug. It shouldn't do anything in this case,
* but it's difficult to tell that to the init reference checker.
*/
-const static struct cpuid_dep cpuid_deps[] = {
+static const struct cpuid_dep cpuid_deps[] = {
{ X86_FEATURE_XSAVEOPT, X86_FEATURE_XSAVE },
{ X86_FEATURE_XSAVEC, X86_FEATURE_XSAVE },
{ X86_FEATURE_XSAVES, X86_FEATURE_XSAVE },
--
2.16.2
[PATCH] x86/cpuid: Switch to 'static const' specifier
This is the only spot where the 'const static' specifier is used;
everywhere else 'static const' is preferred, as static should be the
first specifier.
This is just a cosmetic fix that aligns this, no functional change.
Signed-off-by: Ralf Ramsauer
---
arch/x86/kernel/cpu/cpuid-deps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c
index 904b0a3c4e53..2c0bd38a44ab 100644
--- a/arch/x86/kernel/cpu/cpuid-deps.c
+++ b/arch/x86/kernel/cpu/cpuid-deps.c
@@ -19,7 +19,7 @@ struct cpuid_dep {
* called from cpu hotplug. It shouldn't do anything in this case,
* but it's difficult to tell that to the init reference checker.
*/
-const static struct cpuid_dep cpuid_deps[] = {
+static const struct cpuid_dep cpuid_deps[] = {
{ X86_FEATURE_XSAVEOPT, X86_FEATURE_XSAVE },
{ X86_FEATURE_XSAVEC, X86_FEATURE_XSAVE },
{ X86_FEATURE_XSAVES, X86_FEATURE_XSAVE },
--
2.16.2
Re: [PATCH v2 2/2] i2c: mark device nodes only in case of successful instantiation
On 10/17/2016 04:16 PM, Geert Uytterhoeven wrote:
> On Mon, Oct 17, 2016 at 3:59 PM, Ralf Ramsauer
> <r...@ramses-pyramidenbau.de> wrote:
>> Instantiated I2C device nodes are marked with OF_POPULATE. This was
>> introduced in 4f001fd. On unloading, loaded device nodes will of course
>> be unmarked. The problem are nodes that fail during initialisation: If a
>> node fails, it won't be unloaded and hence not be unmarked.
>>
>> If a I2C driver module is unloaded and reloaded, it will skip nodes that
>> failed before.
>>
>> Skip device nodes that are already populated and mark them only in case
>> of success.
>>
>> Note that the same issue exists for SPI.
>>
>> Fixes: 4f001fd ("i2c: Mark instantiated device nodes with OF_POPULATE")
>> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
>
> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
>
>> --- a/drivers/i2c/i2c-core.c
>> +++ b/drivers/i2c/i2c-core.c
>
>> @@ -1695,7 +1696,14 @@ static void of_i2c_register_devices(struct
>> i2c_adapter *adap)
>> for_each_available_child_of_node(bus, node) {
>> if (of_node_test_and_set_flag(node, OF_POPULATED))
>> continue;
>> - of_i2c_register_device(adap, node);
>> +
>> + client = of_i2c_register_device(adap, node);
>> + if (IS_ERR(client)) {
>> + dev_warn(>dev,
>> +"Failed to create I2C device for %s\n",
>> +node->full_name);
>
> I don't think there's a need to add this warning, as of_i2c_register_device()
> already prints messages in all failure paths.
So does of_register_spi_device(). And there's a dev_warn() in
of_spi_register_devices() as well...
But yes, I was also thinking of this.
Nevertheless, I added it as I thought this would keep both drivers
somehow consistent. And it's a very rare error case, though.
Ralf
>
>> + of_node_clear_flag(node, OF_POPULATED);
>> + }
>> }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
--
Ralf Ramsauer
PGP: 0x8F10049B
Re: [PATCH v2 2/2] i2c: mark device nodes only in case of successful instantiation
On 10/17/2016 04:16 PM, Geert Uytterhoeven wrote:
> On Mon, Oct 17, 2016 at 3:59 PM, Ralf Ramsauer
> wrote:
>> Instantiated I2C device nodes are marked with OF_POPULATE. This was
>> introduced in 4f001fd. On unloading, loaded device nodes will of course
>> be unmarked. The problem are nodes that fail during initialisation: If a
>> node fails, it won't be unloaded and hence not be unmarked.
>>
>> If a I2C driver module is unloaded and reloaded, it will skip nodes that
>> failed before.
>>
>> Skip device nodes that are already populated and mark them only in case
>> of success.
>>
>> Note that the same issue exists for SPI.
>>
>> Fixes: 4f001fd ("i2c: Mark instantiated device nodes with OF_POPULATE")
>> Signed-off-by: Ralf Ramsauer
>
> Reviewed-by: Geert Uytterhoeven
>
>> --- a/drivers/i2c/i2c-core.c
>> +++ b/drivers/i2c/i2c-core.c
>
>> @@ -1695,7 +1696,14 @@ static void of_i2c_register_devices(struct
>> i2c_adapter *adap)
>> for_each_available_child_of_node(bus, node) {
>> if (of_node_test_and_set_flag(node, OF_POPULATED))
>> continue;
>> - of_i2c_register_device(adap, node);
>> +
>> + client = of_i2c_register_device(adap, node);
>> + if (IS_ERR(client)) {
>> + dev_warn(>dev,
>> +"Failed to create I2C device for %s\n",
>> +node->full_name);
>
> I don't think there's a need to add this warning, as of_i2c_register_device()
> already prints messages in all failure paths.
So does of_register_spi_device(). And there's a dev_warn() in
of_spi_register_devices() as well...
But yes, I was also thinking of this.
Nevertheless, I added it as I thought this would keep both drivers
somehow consistent. And it's a very rare error case, though.
Ralf
>
>> + of_node_clear_flag(node, OF_POPULATED);
>> + }
>> }
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
--
Ralf Ramsauer
PGP: 0x8F10049B
[PATCH v2 0/2] spi, i2c: mark device nodes only in case of successful instantiation
Hi, this one fixes initialisation of I2C/SPI nodes. Upon failure during intialisation, nodes were erroneously populated and never unmarked. This lead to the problem that re-loaded drivers will never probe those devices again and can easily be fixed by clearing the OF_POPULATE flag when the node doesn't successfully initialise. For the discussion of v1, see https://lkml.org/lkml/2016/10/14/483 Ralf changes since v1: - also fix I2C core driver - keep the atomic test-and-set, as Geert suggested Ralf Ramsauer (2): spi: mark device nodes only in case of successful instantiation i2c: mark device nodes only in case of successful instantiation drivers/i2c/i2c-core.c | 11 ++- drivers/spi/spi.c | 5 - 2 files changed, 14 insertions(+), 2 deletions(-) -- 2.10.1
[PATCH v2 0/2] spi, i2c: mark device nodes only in case of successful instantiation
Hi, this one fixes initialisation of I2C/SPI nodes. Upon failure during intialisation, nodes were erroneously populated and never unmarked. This lead to the problem that re-loaded drivers will never probe those devices again and can easily be fixed by clearing the OF_POPULATE flag when the node doesn't successfully initialise. For the discussion of v1, see https://lkml.org/lkml/2016/10/14/483 Ralf changes since v1: - also fix I2C core driver - keep the atomic test-and-set, as Geert suggested Ralf Ramsauer (2): spi: mark device nodes only in case of successful instantiation i2c: mark device nodes only in case of successful instantiation drivers/i2c/i2c-core.c | 11 ++- drivers/spi/spi.c | 5 - 2 files changed, 14 insertions(+), 2 deletions(-) -- 2.10.1
[PATCH v2 2/2] i2c: mark device nodes only in case of successful instantiation
Instantiated I2C device nodes are marked with OF_POPULATE. This was
introduced in 4f001fd. On unloading, loaded device nodes will of course
be unmarked. The problem are nodes that fail during initialisation: If a
node fails, it won't be unloaded and hence not be unmarked.
If a I2C driver module is unloaded and reloaded, it will skip nodes that
failed before.
Skip device nodes that are already populated and mark them only in case
of success.
Note that the same issue exists for SPI.
Fixes: 4f001fd ("i2c: Mark instantiated device nodes with OF_POPULATE")
Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
---
drivers/i2c/i2c-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 5ab6721..1704fc8 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1681,6 +1681,7 @@ static struct i2c_client *of_i2c_register_device(struct
i2c_adapter *adap,
static void of_i2c_register_devices(struct i2c_adapter *adap)
{
struct device_node *bus, *node;
+ struct i2c_client *client;
/* Only register child devices if the adapter has a node pointer set */
if (!adap->dev.of_node)
@@ -1695,7 +1696,14 @@ static void of_i2c_register_devices(struct i2c_adapter
*adap)
for_each_available_child_of_node(bus, node) {
if (of_node_test_and_set_flag(node, OF_POPULATED))
continue;
- of_i2c_register_device(adap, node);
+
+ client = of_i2c_register_device(adap, node);
+ if (IS_ERR(client)) {
+ dev_warn(>dev,
+"Failed to create I2C device for %s\n",
+node->full_name);
+ of_node_clear_flag(node, OF_POPULATED);
+ }
}
of_node_put(bus);
@@ -2299,6 +2307,7 @@ static int of_i2c_notify(struct notifier_block *nb,
unsigned long action,
if (IS_ERR(client)) {
dev_err(>dev, "failed to create client for
'%s'\n",
rd->dn->full_name);
+ of_node_clear_flag(rd->dn, OF_POPULATED);
return notifier_from_errno(PTR_ERR(client));
}
break;
--
2.10.1
[PATCH v2 1/2] spi: mark device nodes only in case of successful instantiation
Instantiated SPI device nodes are marked with OF_POPULATE. This was
introduced in bd6c164. On unloading, loaded device nodes will of course
be unmarked. The problem are nodes that fail during initialisation: If a
node fails, it won't be unloaded and hence not be unmarked.
If a SPI driver module is unloaded and reloaded, it will skip nodes that
failed before.
Skip device nodes that are already populated and mark them only in case
of success.
Note that the same issue exists for I2C.
Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
---
drivers/spi/spi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 5787b72..838783c 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1618,9 +1618,11 @@ static void of_register_spi_devices(struct spi_master
*master)
if (of_node_test_and_set_flag(nc, OF_POPULATED))
continue;
spi = of_register_spi_device(master, nc);
- if (IS_ERR(spi))
+ if (IS_ERR(spi)) {
dev_warn(>dev, "Failed to create SPI device for
%s\n",
nc->full_name);
+ of_node_clear_flag(nc, OF_POPULATED);
+ }
}
}
#else
@@ -3131,6 +3133,7 @@ static int of_spi_notify(struct notifier_block *nb,
unsigned long action,
if (IS_ERR(spi)) {
pr_err("%s: failed to create for '%s'\n",
__func__, rd->dn->full_name);
+ of_node_clear_flag(rd->dn, OF_POPULATED);
return notifier_from_errno(PTR_ERR(spi));
}
break;
--
2.10.1
[PATCH v2 2/2] i2c: mark device nodes only in case of successful instantiation
Instantiated I2C device nodes are marked with OF_POPULATE. This was
introduced in 4f001fd. On unloading, loaded device nodes will of course
be unmarked. The problem are nodes that fail during initialisation: If a
node fails, it won't be unloaded and hence not be unmarked.
If a I2C driver module is unloaded and reloaded, it will skip nodes that
failed before.
Skip device nodes that are already populated and mark them only in case
of success.
Note that the same issue exists for SPI.
Fixes: 4f001fd ("i2c: Mark instantiated device nodes with OF_POPULATE")
Signed-off-by: Ralf Ramsauer
---
drivers/i2c/i2c-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 5ab6721..1704fc8 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -1681,6 +1681,7 @@ static struct i2c_client *of_i2c_register_device(struct
i2c_adapter *adap,
static void of_i2c_register_devices(struct i2c_adapter *adap)
{
struct device_node *bus, *node;
+ struct i2c_client *client;
/* Only register child devices if the adapter has a node pointer set */
if (!adap->dev.of_node)
@@ -1695,7 +1696,14 @@ static void of_i2c_register_devices(struct i2c_adapter
*adap)
for_each_available_child_of_node(bus, node) {
if (of_node_test_and_set_flag(node, OF_POPULATED))
continue;
- of_i2c_register_device(adap, node);
+
+ client = of_i2c_register_device(adap, node);
+ if (IS_ERR(client)) {
+ dev_warn(>dev,
+"Failed to create I2C device for %s\n",
+node->full_name);
+ of_node_clear_flag(node, OF_POPULATED);
+ }
}
of_node_put(bus);
@@ -2299,6 +2307,7 @@ static int of_i2c_notify(struct notifier_block *nb,
unsigned long action,
if (IS_ERR(client)) {
dev_err(>dev, "failed to create client for
'%s'\n",
rd->dn->full_name);
+ of_node_clear_flag(rd->dn, OF_POPULATED);
return notifier_from_errno(PTR_ERR(client));
}
break;
--
2.10.1
[PATCH v2 1/2] spi: mark device nodes only in case of successful instantiation
Instantiated SPI device nodes are marked with OF_POPULATE. This was
introduced in bd6c164. On unloading, loaded device nodes will of course
be unmarked. The problem are nodes that fail during initialisation: If a
node fails, it won't be unloaded and hence not be unmarked.
If a SPI driver module is unloaded and reloaded, it will skip nodes that
failed before.
Skip device nodes that are already populated and mark them only in case
of success.
Note that the same issue exists for I2C.
Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
Signed-off-by: Ralf Ramsauer
---
drivers/spi/spi.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 5787b72..838783c 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1618,9 +1618,11 @@ static void of_register_spi_devices(struct spi_master
*master)
if (of_node_test_and_set_flag(nc, OF_POPULATED))
continue;
spi = of_register_spi_device(master, nc);
- if (IS_ERR(spi))
+ if (IS_ERR(spi)) {
dev_warn(>dev, "Failed to create SPI device for
%s\n",
nc->full_name);
+ of_node_clear_flag(nc, OF_POPULATED);
+ }
}
}
#else
@@ -3131,6 +3133,7 @@ static int of_spi_notify(struct notifier_block *nb,
unsigned long action,
if (IS_ERR(spi)) {
pr_err("%s: failed to create for '%s'\n",
__func__, rd->dn->full_name);
+ of_node_clear_flag(rd->dn, OF_POPULATED);
return notifier_from_errno(PTR_ERR(spi));
}
break;
--
2.10.1
Re: [PATCH] spi: mark device nodes only in case of successful instantiation
Hi Geert,
On 10/16/2016 10:49 AM, Geert Uytterhoeven wrote:
> Hi Ralf,
>
> (Cc i2c)
>
> On Fri, Oct 14, 2016 at 9:31 PM, Ralf Ramsauer
> <r...@ramses-pyramidenbau.de> wrote:
>> Instantiated SPI device nodes are marked with OF_POPULATE. This was
>> introduced in bd6c164. On unloading, loaded device nodes will of course
>> be unmarked. The problem are nodes the fail during initialisation: If a
>> node failed during registration, it won't be unloaded and hence never be
>> unmarked again.
>>
>> So if a SPI driver module is unloaded and reloaded, it will skip nodes
>> that failed before.
>>
>> Skip device nodes that are already populated and mark them only in case
>> of success.
>>
>> Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
>> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
>> Cc: Geert Uytterhoeven <geert+rene...@glider.be>
>> ---
>> Hi,
>>
>> imagine the following situation: you loaded a spi driver as module, but
>> it fails to instantiate, because of some reasons (e.g. some resources,
>> like gpios, might be in use in userspace).
>>
>> When reloading the driver, _all_ nodes, including previously failed
>> ones, should be probed again. This is not the case at the moment.
>> Current behaviour only re-registers nodes that were previously
>> successfully loaded.
>>
>> This small patches fixes this behaviour. I stumbled over this while
>> working on a spi driver.
>
> Thanks for your patch!
>
>> drivers/spi/spi.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
>> index 200ca22..f96a04e 100644
>> --- a/drivers/spi/spi.c
>> +++ b/drivers/spi/spi.c
>> @@ -1604,12 +1604,15 @@ static void of_register_spi_devices(struct
>> spi_master *master)
>> return;
>>
>> for_each_available_child_of_node(master->dev.of_node, nc) {
>> - if (of_node_test_and_set_flag(nc, OF_POPULATED))
>> + if (of_node_check_flag(nc, OF_POPULATED))
>> continue;
>> spi = of_register_spi_device(master, nc);
>> - if (IS_ERR(spi))
>> + if (IS_ERR(spi)) {
>> dev_warn(>dev, "Failed to create SPI device
>> for %s\n",
>> nc->full_name);
>> + continue;
>> + }
>> + of_node_set_flag(nc, OF_POPULATED);
>
> I think it's safer to keep the atomic test-and-set, but clear the flag on
> failure, cfr. of_platform_device_create_pdata() and of_amba_device_create().
Ack, no prob. Let me change this in the next version.
>
> Shouldn't of_spi_notify() be fixed, too?
Right, that's almost the same path.
>
> The same issue exists for i2c in of_i2c_register_devices() and
> of_i2c_notify(),
> which is what I had used as an example.
Good old c ;-)
I'll fix and test that tomorrow and come back with two patches, as it
touches different subsystems.
Best
Ralf
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
--
Ralf Ramsauer
GPG: 0x8F10049B
Re: [PATCH] spi: mark device nodes only in case of successful instantiation
Hi Geert,
On 10/16/2016 10:49 AM, Geert Uytterhoeven wrote:
> Hi Ralf,
>
> (Cc i2c)
>
> On Fri, Oct 14, 2016 at 9:31 PM, Ralf Ramsauer
> wrote:
>> Instantiated SPI device nodes are marked with OF_POPULATE. This was
>> introduced in bd6c164. On unloading, loaded device nodes will of course
>> be unmarked. The problem are nodes the fail during initialisation: If a
>> node failed during registration, it won't be unloaded and hence never be
>> unmarked again.
>>
>> So if a SPI driver module is unloaded and reloaded, it will skip nodes
>> that failed before.
>>
>> Skip device nodes that are already populated and mark them only in case
>> of success.
>>
>> Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
>> Signed-off-by: Ralf Ramsauer
>> Cc: Geert Uytterhoeven
>> ---
>> Hi,
>>
>> imagine the following situation: you loaded a spi driver as module, but
>> it fails to instantiate, because of some reasons (e.g. some resources,
>> like gpios, might be in use in userspace).
>>
>> When reloading the driver, _all_ nodes, including previously failed
>> ones, should be probed again. This is not the case at the moment.
>> Current behaviour only re-registers nodes that were previously
>> successfully loaded.
>>
>> This small patches fixes this behaviour. I stumbled over this while
>> working on a spi driver.
>
> Thanks for your patch!
>
>> drivers/spi/spi.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
>> index 200ca22..f96a04e 100644
>> --- a/drivers/spi/spi.c
>> +++ b/drivers/spi/spi.c
>> @@ -1604,12 +1604,15 @@ static void of_register_spi_devices(struct
>> spi_master *master)
>> return;
>>
>> for_each_available_child_of_node(master->dev.of_node, nc) {
>> - if (of_node_test_and_set_flag(nc, OF_POPULATED))
>> + if (of_node_check_flag(nc, OF_POPULATED))
>> continue;
>> spi = of_register_spi_device(master, nc);
>> - if (IS_ERR(spi))
>> + if (IS_ERR(spi)) {
>> dev_warn(>dev, "Failed to create SPI device
>> for %s\n",
>> nc->full_name);
>> + continue;
>> + }
>> + of_node_set_flag(nc, OF_POPULATED);
>
> I think it's safer to keep the atomic test-and-set, but clear the flag on
> failure, cfr. of_platform_device_create_pdata() and of_amba_device_create().
Ack, no prob. Let me change this in the next version.
>
> Shouldn't of_spi_notify() be fixed, too?
Right, that's almost the same path.
>
> The same issue exists for i2c in of_i2c_register_devices() and
> of_i2c_notify(),
> which is what I had used as an example.
Good old c ;-)
I'll fix and test that tomorrow and come back with two patches, as it
touches different subsystems.
Best
Ralf
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
>
--
Ralf Ramsauer
GPG: 0x8F10049B
[PATCH] spi: mark device nodes only in case of successful instantiation
Instantiated SPI device nodes are marked with OF_POPULATE. This was
introduced in bd6c164. On unloading, loaded device nodes will of course
be unmarked. The problem are nodes the fail during initialisation: If a
node failed during registration, it won't be unloaded and hence never be
unmarked again.
So if a SPI driver module is unloaded and reloaded, it will skip nodes
that failed before.
Skip device nodes that are already populated and mark them only in case
of success.
Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
Cc: Geert Uytterhoeven <geert+rene...@glider.be>
---
Hi,
imagine the following situation: you loaded a spi driver as module, but
it fails to instantiate, because of some reasons (e.g. some resources,
like gpios, might be in use in userspace).
When reloading the driver, _all_ nodes, including previously failed
ones, should be probed again. This is not the case at the moment.
Current behaviour only re-registers nodes that were previously
successfully loaded.
This small patches fixes this behaviour. I stumbled over this while
working on a spi driver.
Ralf
drivers/spi/spi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 200ca22..f96a04e 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1604,12 +1604,15 @@ static void of_register_spi_devices(struct spi_master
*master)
return;
for_each_available_child_of_node(master->dev.of_node, nc) {
- if (of_node_test_and_set_flag(nc, OF_POPULATED))
+ if (of_node_check_flag(nc, OF_POPULATED))
continue;
spi = of_register_spi_device(master, nc);
- if (IS_ERR(spi))
+ if (IS_ERR(spi)) {
dev_warn(>dev, "Failed to create SPI device for
%s\n",
nc->full_name);
+ continue;
+ }
+ of_node_set_flag(nc, OF_POPULATED);
}
}
#else
--
2.10.1
[PATCH] spi: mark device nodes only in case of successful instantiation
Instantiated SPI device nodes are marked with OF_POPULATE. This was
introduced in bd6c164. On unloading, loaded device nodes will of course
be unmarked. The problem are nodes the fail during initialisation: If a
node failed during registration, it won't be unloaded and hence never be
unmarked again.
So if a SPI driver module is unloaded and reloaded, it will skip nodes
that failed before.
Skip device nodes that are already populated and mark them only in case
of success.
Fixes: bd6c164 ("spi: Mark instantiated device nodes with OF_POPULATE")
Signed-off-by: Ralf Ramsauer
Cc: Geert Uytterhoeven
---
Hi,
imagine the following situation: you loaded a spi driver as module, but
it fails to instantiate, because of some reasons (e.g. some resources,
like gpios, might be in use in userspace).
When reloading the driver, _all_ nodes, including previously failed
ones, should be probed again. This is not the case at the moment.
Current behaviour only re-registers nodes that were previously
successfully loaded.
This small patches fixes this behaviour. I stumbled over this while
working on a spi driver.
Ralf
drivers/spi/spi.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 200ca22..f96a04e 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1604,12 +1604,15 @@ static void of_register_spi_devices(struct spi_master
*master)
return;
for_each_available_child_of_node(master->dev.of_node, nc) {
- if (of_node_test_and_set_flag(nc, OF_POPULATED))
+ if (of_node_check_flag(nc, OF_POPULATED))
continue;
spi = of_register_spi_device(master, nc);
- if (IS_ERR(spi))
+ if (IS_ERR(spi)) {
dev_warn(>dev, "Failed to create SPI device for
%s\n",
nc->full_name);
+ continue;
+ }
+ of_node_set_flag(nc, OF_POPULATED);
}
}
#else
--
2.10.1
Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts
Hi all,
may I *poke* you again?
We're close to the release of 4.8, and this patch (b5c86b749 upstream)
should still be reverted on mainline
Ralf
On 08/10/2016 10:46 PM, Arnd Bergmann wrote:
> On Monday, July 18, 2016 11:58:02 AM CEST Thierry Reding wrote:
>> On Mon, Jul 18, 2016 at 11:46:48AM +0200, Ralf Ramsauer wrote:
>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
>>> quirk, wrong addresses were introduced. Fix it and use the correct
>>> addresses.
>>>
>>> Thierry let me know, that there is another patch (b5896f67ab3c in
>>> linux-next) in preparation which removes all the '0,' prefixes of unit
>>> addresses on Tegra124 and is planned to go upstream in 4.8, so
>>> this patch will get reverted then.
>>>
>>> But for the moment, this patch is necessary to fix current misbehaviour.
>>>
>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device
>>> tree")
>>> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
>>> Acked-by: Thierry Reding <thierry.red...@gmail.com>
>>> Cc: linux-te...@vger.kernel.org
>>> ---
>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> ARM-SoC maintainers,
>>
>> Just to clarify, this is targetted at v4.7 because the offending patch
>> was merged in v4.7-rc1. If at all possible it'd be great to get this in,
>> even if this is terribly last minute.
>>
>
> I just notice this was still missing in v4.8-rc1, so I added it to
> the fixes branch now, with a stable tag for v4.7
>
> Arnd
>
--
Ralf Ramsauer
PGP: 0x8F10049B
Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts
Hi all,
may I *poke* you again?
We're close to the release of 4.8, and this patch (b5c86b749 upstream)
should still be reverted on mainline
Ralf
On 08/10/2016 10:46 PM, Arnd Bergmann wrote:
> On Monday, July 18, 2016 11:58:02 AM CEST Thierry Reding wrote:
>> On Mon, Jul 18, 2016 at 11:46:48AM +0200, Ralf Ramsauer wrote:
>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
>>> quirk, wrong addresses were introduced. Fix it and use the correct
>>> addresses.
>>>
>>> Thierry let me know, that there is another patch (b5896f67ab3c in
>>> linux-next) in preparation which removes all the '0,' prefixes of unit
>>> addresses on Tegra124 and is planned to go upstream in 4.8, so
>>> this patch will get reverted then.
>>>
>>> But for the moment, this patch is necessary to fix current misbehaviour.
>>>
>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device
>>> tree")
>>> Signed-off-by: Ralf Ramsauer
>>> Acked-by: Thierry Reding
>>> Cc: linux-te...@vger.kernel.org
>>> ---
>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> ARM-SoC maintainers,
>>
>> Just to clarify, this is targetted at v4.7 because the offending patch
>> was merged in v4.7-rc1. If at all possible it'd be great to get this in,
>> even if this is terribly last minute.
>>
>
> I just notice this was still missing in v4.8-rc1, so I added it to
> the fixes branch now, with a stable tag for v4.7
>
> Arnd
>
--
Ralf Ramsauer
PGP: 0x8F10049B
Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts
Hi,
may I poke you again?
Could you please revert this one (b5c86b7 upstream)? It was only
required for 4.7.x where it got already applied.
Thanks
Ralf
On 08/12/2016 07:26 PM, Ralf Ramsauer wrote:
> On 08/10/2016 10:46 PM, Arnd Bergmann wrote:
>> On Monday, July 18, 2016 11:58:02 AM CEST Thierry Reding wrote:
>>> On Mon, Jul 18, 2016 at 11:46:48AM +0200, Ralf Ramsauer wrote:
>>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
>>>> quirk, wrong addresses were introduced. Fix it and use the correct
>>>> addresses.
>>>>
>>>> Thierry let me know, that there is another patch (b5896f67ab3c in
>>>> linux-next) in preparation which removes all the '0,' prefixes of unit
>>>> addresses on Tegra124 and is planned to go upstream in 4.8, so
>>>> this patch will get reverted then.
>>>>
>>>> But for the moment, this patch is necessary to fix current misbehaviour.
>>>>
>>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device
>>>> tree")
>>>> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
>>>> Acked-by: Thierry Reding <thierry.red...@gmail.com>
>>>> Cc: linux-te...@vger.kernel.org
>>>> ---
>>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> ARM-SoC maintainers,
>>>
>>> Just to clarify, this is targetted at v4.7 because the offending patch
>>> was merged in v4.7-rc1. If at all possible it'd be great to get this in,
>>> even if this is terribly last minute.
>>>
>>
>> I just notice this was still missing in v4.8-rc1, so I added it to
>> the fixes branch now, with a stable tag for v4.7
> Hi Arnd,
>
> Ahm - this patch should have only be applied if it would have been
> possible to commit it before the release of v4.7.
>
> Mainline Patch b5896f6 ("ARM: tegra: Remove commas from unit addresses
> on Tegra124") which was introduced during the merge window of v4.8 makes
> this patch superfluous and introduces the same error again that we
> initially wanted to fix :-)
>
> This patch is only required for stable v4.7.x.
>
> I think the best is to revert it on mainline, as long as stabilization
> window is still open.
>
> Ralf
>>
>> Arnd
>>
>
Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts
Hi,
may I poke you again?
Could you please revert this one (b5c86b7 upstream)? It was only
required for 4.7.x where it got already applied.
Thanks
Ralf
On 08/12/2016 07:26 PM, Ralf Ramsauer wrote:
> On 08/10/2016 10:46 PM, Arnd Bergmann wrote:
>> On Monday, July 18, 2016 11:58:02 AM CEST Thierry Reding wrote:
>>> On Mon, Jul 18, 2016 at 11:46:48AM +0200, Ralf Ramsauer wrote:
>>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
>>>> quirk, wrong addresses were introduced. Fix it and use the correct
>>>> addresses.
>>>>
>>>> Thierry let me know, that there is another patch (b5896f67ab3c in
>>>> linux-next) in preparation which removes all the '0,' prefixes of unit
>>>> addresses on Tegra124 and is planned to go upstream in 4.8, so
>>>> this patch will get reverted then.
>>>>
>>>> But for the moment, this patch is necessary to fix current misbehaviour.
>>>>
>>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device
>>>> tree")
>>>> Signed-off-by: Ralf Ramsauer
>>>> Acked-by: Thierry Reding
>>>> Cc: linux-te...@vger.kernel.org
>>>> ---
>>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> ARM-SoC maintainers,
>>>
>>> Just to clarify, this is targetted at v4.7 because the offending patch
>>> was merged in v4.7-rc1. If at all possible it'd be great to get this in,
>>> even if this is terribly last minute.
>>>
>>
>> I just notice this was still missing in v4.8-rc1, so I added it to
>> the fixes branch now, with a stable tag for v4.7
> Hi Arnd,
>
> Ahm - this patch should have only be applied if it would have been
> possible to commit it before the release of v4.7.
>
> Mainline Patch b5896f6 ("ARM: tegra: Remove commas from unit addresses
> on Tegra124") which was introduced during the merge window of v4.8 makes
> this patch superfluous and introduces the same error again that we
> initially wanted to fix :-)
>
> This patch is only required for stable v4.7.x.
>
> I think the best is to revert it on mainline, as long as stabilization
> window is still open.
>
> Ralf
>>
>> Arnd
>>
>
Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts
On 08/10/2016 10:46 PM, Arnd Bergmann wrote:
> On Monday, July 18, 2016 11:58:02 AM CEST Thierry Reding wrote:
>> On Mon, Jul 18, 2016 at 11:46:48AM +0200, Ralf Ramsauer wrote:
>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
>>> quirk, wrong addresses were introduced. Fix it and use the correct
>>> addresses.
>>>
>>> Thierry let me know, that there is another patch (b5896f67ab3c in
>>> linux-next) in preparation which removes all the '0,' prefixes of unit
>>> addresses on Tegra124 and is planned to go upstream in 4.8, so
>>> this patch will get reverted then.
>>>
>>> But for the moment, this patch is necessary to fix current misbehaviour.
>>>
>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device
>>> tree")
>>> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
>>> Acked-by: Thierry Reding <thierry.red...@gmail.com>
>>> Cc: linux-te...@vger.kernel.org
>>> ---
>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> ARM-SoC maintainers,
>>
>> Just to clarify, this is targetted at v4.7 because the offending patch
>> was merged in v4.7-rc1. If at all possible it'd be great to get this in,
>> even if this is terribly last minute.
>>
>
> I just notice this was still missing in v4.8-rc1, so I added it to
> the fixes branch now, with a stable tag for v4.7
Hi Arnd,
Ahm - this patch should have only be applied if it would have been
possible to commit it before the release of v4.7.
Mainline Patch b5896f6 ("ARM: tegra: Remove commas from unit addresses
on Tegra124") which was introduced during the merge window of v4.8 makes
this patch superfluous and introduces the same error again that we
initially wanted to fix :-)
This patch is only required for stable v4.7.x.
I think the best is to revert it on mainline, as long as stabilization
window is still open.
Ralf
>
> Arnd
>
--
Ralf Ramsauer
PGP: 0x8F10049B
Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts
On 08/10/2016 10:46 PM, Arnd Bergmann wrote:
> On Monday, July 18, 2016 11:58:02 AM CEST Thierry Reding wrote:
>> On Mon, Jul 18, 2016 at 11:46:48AM +0200, Ralf Ramsauer wrote:
>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
>>> quirk, wrong addresses were introduced. Fix it and use the correct
>>> addresses.
>>>
>>> Thierry let me know, that there is another patch (b5896f67ab3c in
>>> linux-next) in preparation which removes all the '0,' prefixes of unit
>>> addresses on Tegra124 and is planned to go upstream in 4.8, so
>>> this patch will get reverted then.
>>>
>>> But for the moment, this patch is necessary to fix current misbehaviour.
>>>
>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device
>>> tree")
>>> Signed-off-by: Ralf Ramsauer
>>> Acked-by: Thierry Reding
>>> Cc: linux-te...@vger.kernel.org
>>> ---
>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> ARM-SoC maintainers,
>>
>> Just to clarify, this is targetted at v4.7 because the offending patch
>> was merged in v4.7-rc1. If at all possible it'd be great to get this in,
>> even if this is terribly last minute.
>>
>
> I just notice this was still missing in v4.8-rc1, so I added it to
> the fixes branch now, with a stable tag for v4.7
Hi Arnd,
Ahm - this patch should have only be applied if it would have been
possible to commit it before the release of v4.7.
Mainline Patch b5896f6 ("ARM: tegra: Remove commas from unit addresses
on Tegra124") which was introduced during the merge window of v4.8 makes
this patch superfluous and introduces the same error again that we
initially wanted to fix :-)
This patch is only required for stable v4.7.x.
I think the best is to revert it on mainline, as long as stabilization
window is still open.
Ralf
>
> Arnd
>
--
Ralf Ramsauer
PGP: 0x8F10049B
[PATCH] ARM: tegra: fix erroneous address in dts
c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
quirk, wrong addresses were introduced. Fix it and use the correct
addresses.
This patch is only required for 4.7.x, as there is another patch in the
queue for 4.8 that will remove all '0,' prefixes (b5896f67ab3c in
linux-next).
Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device tree")
Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
Acked-by: Thierry Reding <thierry.red...@gmail.com>
Cc: sta...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
---
Stable maintainers,
this is targetted at v4.7 only, the offending patch was merged in 4.7-rc1.
We tried to get this in via ARM-SoC maintainers, but it was too late for 4.7.
Only 4.7.x is affected, as there is another patch in the queue that will fix
this
issue in 4.8.
Ralf
---
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 941f362..f4d8125 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1386,7 +1386,7 @@
* Pin 41: BR_UART1_TXD
* Pin 44: BR_UART1_RXD
*/
- serial@70006000 {
+ serial@0,70006000 {
compatible = "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart";
status = "okay";
};
@@ -1398,7 +1398,7 @@
* Pin 71: UART2_CTS_L
* Pin 74: UART2_RTS_L
*/
- serial@70006040 {
+ serial@0,70006040 {
compatible = "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart";
status = "okay";
};
--
2.7.3
[PATCH] ARM: tegra: fix erroneous address in dts
c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
quirk, wrong addresses were introduced. Fix it and use the correct
addresses.
This patch is only required for 4.7.x, as there is another patch in the
queue for 4.8 that will remove all '0,' prefixes (b5896f67ab3c in
linux-next).
Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device tree")
Signed-off-by: Ralf Ramsauer
Acked-by: Thierry Reding
Cc: sta...@vger.kernel.org
Cc: linux-te...@vger.kernel.org
---
Stable maintainers,
this is targetted at v4.7 only, the offending patch was merged in 4.7-rc1.
We tried to get this in via ARM-SoC maintainers, but it was too late for 4.7.
Only 4.7.x is affected, as there is another patch in the queue that will fix
this
issue in 4.8.
Ralf
---
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 941f362..f4d8125 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1386,7 +1386,7 @@
* Pin 41: BR_UART1_TXD
* Pin 44: BR_UART1_RXD
*/
- serial@70006000 {
+ serial@0,70006000 {
compatible = "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart";
status = "okay";
};
@@ -1398,7 +1398,7 @@
* Pin 71: UART2_CTS_L
* Pin 74: UART2_RTS_L
*/
- serial@70006040 {
+ serial@0,70006040 {
compatible = "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart";
status = "okay";
};
--
2.7.3
Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts
On 07/21/2016 02:28 PM, Arnd Bergmann wrote:
> On Monday, July 18, 2016 11:58:02 AM CEST Thierry Reding wrote:
>> On Mon, Jul 18, 2016 at 11:46:48AM +0200, Ralf Ramsauer wrote:
>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
>>> quirk, wrong addresses were introduced. Fix it and use the correct
>>> addresses.
>>>
>>> Thierry let me know, that there is another patch (b5896f67ab3c in
>>> linux-next) in preparation which removes all the '0,' prefixes of unit
>>> addresses on Tegra124 and is planned to go upstream in 4.8, so
>>> this patch will get reverted then.
>>>
>>> But for the moment, this patch is necessary to fix current misbehaviour.
>>>
>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device
>>> tree")
>>> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
>>> Acked-by: Thierry Reding <thierry.red...@gmail.com>
>>> Cc: linux-te...@vger.kernel.org
>>> ---
>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> ARM-SoC maintainers,
>>
>> Just to clarify, this is targetted at v4.7 because the offending patch
>> was merged in v4.7-rc1. If at all possible it'd be great to get this in,
>> even if this is terribly last minute.
>>
>
> I've applied it to the fixes branch, but as Linus is currently offline
> and hasn't pulled the previous set of fixes, I suspect it's not
> going to make it.
Yep, didn't make it. I'll resend the fix with stable in Cc tomorrow.
Keep you also in Cc.
Thierry, this fix is only required for 4.7.x and gets superfluous when
b5896f67ab3c is applied. So I guess there is no need to fix mainline, right?
Ralf
>
> Olof, do you think we should send an amended pull request, or are
> we at the point where nothing gets pulled anyway?
>
> Arnd
>
--
Ralf Ramsauer
GPG: 0x8F10049B
Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts
On 07/21/2016 02:28 PM, Arnd Bergmann wrote:
> On Monday, July 18, 2016 11:58:02 AM CEST Thierry Reding wrote:
>> On Mon, Jul 18, 2016 at 11:46:48AM +0200, Ralf Ramsauer wrote:
>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
>>> quirk, wrong addresses were introduced. Fix it and use the correct
>>> addresses.
>>>
>>> Thierry let me know, that there is another patch (b5896f67ab3c in
>>> linux-next) in preparation which removes all the '0,' prefixes of unit
>>> addresses on Tegra124 and is planned to go upstream in 4.8, so
>>> this patch will get reverted then.
>>>
>>> But for the moment, this patch is necessary to fix current misbehaviour.
>>>
>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device
>>> tree")
>>> Signed-off-by: Ralf Ramsauer
>>> Acked-by: Thierry Reding
>>> Cc: linux-te...@vger.kernel.org
>>> ---
>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> ARM-SoC maintainers,
>>
>> Just to clarify, this is targetted at v4.7 because the offending patch
>> was merged in v4.7-rc1. If at all possible it'd be great to get this in,
>> even if this is terribly last minute.
>>
>
> I've applied it to the fixes branch, but as Linus is currently offline
> and hasn't pulled the previous set of fixes, I suspect it's not
> going to make it.
Yep, didn't make it. I'll resend the fix with stable in Cc tomorrow.
Keep you also in Cc.
Thierry, this fix is only required for 4.7.x and gets superfluous when
b5896f67ab3c is applied. So I guess there is no need to fix mainline, right?
Ralf
>
> Olof, do you think we should send an amended pull request, or are
> we at the point where nothing gets pulled anyway?
>
> Arnd
>
--
Ralf Ramsauer
GPG: 0x8F10049B
Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts
On 07/21/2016 02:28 PM, Arnd Bergmann wrote:
> On Monday, July 18, 2016 11:58:02 AM CEST Thierry Reding wrote:
>> On Mon, Jul 18, 2016 at 11:46:48AM +0200, Ralf Ramsauer wrote:
>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
>>> quirk, wrong addresses were introduced. Fix it and use the correct
>>> addresses.
>>>
>>> Thierry let me know, that there is another patch (b5896f67ab3c in
>>> linux-next) in preparation which removes all the '0,' prefixes of unit
>>> addresses on Tegra124 and is planned to go upstream in 4.8, so
>>> this patch will get reverted then.
>>>
>>> But for the moment, this patch is necessary to fix current misbehaviour.
>>>
>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device
>>> tree")
>>> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
>>> Acked-by: Thierry Reding <thierry.red...@gmail.com>
>>> Cc: linux-te...@vger.kernel.org
>>> ---
>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> ARM-SoC maintainers,
>>
>> Just to clarify, this is targetted at v4.7 because the offending patch
>> was merged in v4.7-rc1. If at all possible it'd be great to get this in,
>> even if this is terribly last minute.
>>
>
Arnd,
> I've applied it to the fixes branch, but as Linus is currently offline
> and hasn't pulled the previous set of fixes, I suspect it's not
> going to make it.
thank you very much. If it's not merged in 4.7 then I'll follow up with
a revert patch with stable in Cc.
Ralf
>
> Olof, do you think we should send an amended pull request, or are
> we at the point where nothing gets pulled anyway?
>
> Arnd
>
--
Ralf Ramsauer
PGP: 0x8F10049B
signature.asc
Description: OpenPGP digital signature
Re: [RESEND PATCH] ARM: tegra: fix erroneous address in dts
On 07/21/2016 02:28 PM, Arnd Bergmann wrote:
> On Monday, July 18, 2016 11:58:02 AM CEST Thierry Reding wrote:
>> On Mon, Jul 18, 2016 at 11:46:48AM +0200, Ralf Ramsauer wrote:
>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
>>> quirk, wrong addresses were introduced. Fix it and use the correct
>>> addresses.
>>>
>>> Thierry let me know, that there is another patch (b5896f67ab3c in
>>> linux-next) in preparation which removes all the '0,' prefixes of unit
>>> addresses on Tegra124 and is planned to go upstream in 4.8, so
>>> this patch will get reverted then.
>>>
>>> But for the moment, this patch is necessary to fix current misbehaviour.
>>>
>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device
>>> tree")
>>> Signed-off-by: Ralf Ramsauer
>>> Acked-by: Thierry Reding
>>> Cc: linux-te...@vger.kernel.org
>>> ---
>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> ARM-SoC maintainers,
>>
>> Just to clarify, this is targetted at v4.7 because the offending patch
>> was merged in v4.7-rc1. If at all possible it'd be great to get this in,
>> even if this is terribly last minute.
>>
>
Arnd,
> I've applied it to the fixes branch, but as Linus is currently offline
> and hasn't pulled the previous set of fixes, I suspect it's not
> going to make it.
thank you very much. If it's not merged in 4.7 then I'll follow up with
a revert patch with stable in Cc.
Ralf
>
> Olof, do you think we should send an amended pull request, or are
> we at the point where nothing gets pulled anyway?
>
> Arnd
>
--
Ralf Ramsauer
PGP: 0x8F10049B
signature.asc
Description: OpenPGP digital signature
[RESEND PATCH] ARM: tegra: fix erroneous address in dts
c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
quirk, wrong addresses were introduced. Fix it and use the correct
addresses.
Thierry let me know, that there is another patch (b5896f67ab3c in
linux-next) in preparation which removes all the '0,' prefixes of unit
addresses on Tegra124 and is planned to go upstream in 4.8, so
this patch will get reverted then.
But for the moment, this patch is necessary to fix current misbehaviour.
Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device tree")
Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
Acked-by: Thierry Reding <thierry.red...@gmail.com>
Cc: linux-te...@vger.kernel.org
---
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 941f362..f4d8125 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1386,7 +1386,7 @@
* Pin 41: BR_UART1_TXD
* Pin 44: BR_UART1_RXD
*/
- serial@70006000 {
+ serial@0,70006000 {
compatible = "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart";
status = "okay";
};
@@ -1398,7 +1398,7 @@
* Pin 71: UART2_CTS_L
* Pin 74: UART2_RTS_L
*/
- serial@70006040 {
+ serial@0,70006040 {
compatible = "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart";
status = "okay";
};
--
2.7.3
[RESEND PATCH] ARM: tegra: fix erroneous address in dts
c90bb7b enabled the high speed UARTs of the Jetson TK1. Due to a merge
quirk, wrong addresses were introduced. Fix it and use the correct
addresses.
Thierry let me know, that there is another patch (b5896f67ab3c in
linux-next) in preparation which removes all the '0,' prefixes of unit
addresses on Tegra124 and is planned to go upstream in 4.8, so
this patch will get reverted then.
But for the moment, this patch is necessary to fix current misbehaviour.
Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device tree")
Signed-off-by: Ralf Ramsauer
Acked-by: Thierry Reding
Cc: linux-te...@vger.kernel.org
---
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 941f362..f4d8125 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1386,7 +1386,7 @@
* Pin 41: BR_UART1_TXD
* Pin 44: BR_UART1_RXD
*/
- serial@70006000 {
+ serial@0,70006000 {
compatible = "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart";
status = "okay";
};
@@ -1398,7 +1398,7 @@
* Pin 71: UART2_CTS_L
* Pin 74: UART2_RTS_L
*/
- serial@70006040 {
+ serial@0,70006040 {
compatible = "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart";
status = "okay";
};
--
2.7.3
Re: [PATCH] ARM: tegra: fix erroneous address in dts
On 07/18/2016 08:01 AM, Thierry Reding wrote:
> On Fri, Jul 15, 2016 at 06:18:03PM +0200, Ralf Ramsauer wrote:
>> On 07/15/2016 06:01 PM, Stephen Warren wrote:
>>> On 07/15/2016 03:37 AM, Ralf Ramsauer wrote:
>>>> On 07/15/2016 12:02 AM, Thierry Reding wrote:
>>>>> On Thu, Jul 14, 2016 at 06:48:57PM +0200, Ralf Ramsauer wrote:
>>>>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. The address
>>>>>> specification inside the dts is wrong. Fix it and use the correct
>>>>>> address.
>>>>>>
>>>>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1
>>>>>> device tree")
>>>>>> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
>>>>>> ---
>>>>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> These addresses are correct. The 0, prefix was dropped from the unit
>>>>> address in commit b5896f67ab3c ("ARM: tegra: Remove commas from unit
>>>>> addresses on Tegra124").
>>>>>
>>>>> What's the problem that you're seeing? What's not working for you?
>>>>
>>>> I cannot find b5896f67ab3c neither in swarren's tree nor in linux
>>>> upstream. But there's d0bc5aaf890 in swarren's linux-tegra tree that
>>>> matches your described changes and was committed on 1st of July. But
>>>> this patch is not upstream yet, while the other patch is.
>>>
>>> The fix is in linux-next, and will be in mainline soon I expect.
>> Ah okay, but I still wonder how my original patch got changed on its
>> way... The original version on the mailinglist was not buggy.
>
> It's most likely my fault. My recollection is that we used to have an
> earlier patch that removed all 0, prefixes from unit addresses and what
> happens is probably that I applied your patch on top, adjusted it to
> omit the 0, prefix and then we noticed that removing the 0, prefix does
> not work for the GPU (because U-Boot looks it up by node name to enable
> it), so the patch that removes the 0, prefix was dropped and I forgot
> to adjust your patch to compensate.
Ok, i see.
>
>>> My github linux-tegra.git isn't relevant since it's just my own personal
>>> dev branch, but for reference, the commit is there since it's based on
>>> linux-next.
>>>
>>>> Have a look at mainline tegra124-jetson-tk1.dts, there the addresses are
>>>> erroneous as they still use the 0, annotation. And I just realised, that
>>>> somehow, upstream patch c90bb7b slightly differs from my initial patch
>>>> [1] on the mailing list.
>>>
>>> Your patch should probably be CC: stable so that existing kernel
>>> versions get fixed. That said, I'd argue that since the original patch
>>> never actually had any effect since it applied to the wrong node, the
>>> best fix for stable kernels is simply to revert it rather than fixing
>>> it, to avoid the potential for behaviour changes and regressions.
>>> Starting with kernel 4.8 (I think), that patch will begin to have actual
>>> effect.
>> There is no current existing stable kernel that is affected, as it went
>> in during the last merge window in 4.6-rc1. So no need for fixing
>> stable. Maybe it's still possible to fix it as the stabilisation window
>> is still open and 4.7 is not released yet?
>
> Unfortunately a patch to remove the 0, prefix from all nodes except the
> GPU was now merged into the arm-soc tree, which means that if we try to
> get this into v4.7, then we'll have to make sure to patch up the unit
> address again for v4.8.
>
> I have no objections to doing that, so feel free to add my Acked-by and
> resend this to a...@kernel.org. When you do, please keep linux-tegra in
> Cc so that we can track it, and maybe mention that you want this to go
> into v4.7 and how this came about to be, so that the arm-soc maintainers
> won't be surprised when the patch to revert this shows up in a couple of
> days for v4.8.
Alright, I'll prepare it and add a RESEND as well as your Acked-by.
Thank you.
>
> Can you take care of sending out the second patch as well? Probably best
> to send it the same way as this, with a mention that it's targetted at
> v4.8 and a revert of this one.
Yep, I'll take care of it. I'm tracking this patch since January in any
case :-)
Ralf
>
> Thanks,
> Thierry
>
--
Ralf Ramsauer
PGP: 0x8F10049B
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ARM: tegra: fix erroneous address in dts
On 07/18/2016 08:01 AM, Thierry Reding wrote:
> On Fri, Jul 15, 2016 at 06:18:03PM +0200, Ralf Ramsauer wrote:
>> On 07/15/2016 06:01 PM, Stephen Warren wrote:
>>> On 07/15/2016 03:37 AM, Ralf Ramsauer wrote:
>>>> On 07/15/2016 12:02 AM, Thierry Reding wrote:
>>>>> On Thu, Jul 14, 2016 at 06:48:57PM +0200, Ralf Ramsauer wrote:
>>>>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. The address
>>>>>> specification inside the dts is wrong. Fix it and use the correct
>>>>>> address.
>>>>>>
>>>>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1
>>>>>> device tree")
>>>>>> Signed-off-by: Ralf Ramsauer
>>>>>> ---
>>>>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> These addresses are correct. The 0, prefix was dropped from the unit
>>>>> address in commit b5896f67ab3c ("ARM: tegra: Remove commas from unit
>>>>> addresses on Tegra124").
>>>>>
>>>>> What's the problem that you're seeing? What's not working for you?
>>>>
>>>> I cannot find b5896f67ab3c neither in swarren's tree nor in linux
>>>> upstream. But there's d0bc5aaf890 in swarren's linux-tegra tree that
>>>> matches your described changes and was committed on 1st of July. But
>>>> this patch is not upstream yet, while the other patch is.
>>>
>>> The fix is in linux-next, and will be in mainline soon I expect.
>> Ah okay, but I still wonder how my original patch got changed on its
>> way... The original version on the mailinglist was not buggy.
>
> It's most likely my fault. My recollection is that we used to have an
> earlier patch that removed all 0, prefixes from unit addresses and what
> happens is probably that I applied your patch on top, adjusted it to
> omit the 0, prefix and then we noticed that removing the 0, prefix does
> not work for the GPU (because U-Boot looks it up by node name to enable
> it), so the patch that removes the 0, prefix was dropped and I forgot
> to adjust your patch to compensate.
Ok, i see.
>
>>> My github linux-tegra.git isn't relevant since it's just my own personal
>>> dev branch, but for reference, the commit is there since it's based on
>>> linux-next.
>>>
>>>> Have a look at mainline tegra124-jetson-tk1.dts, there the addresses are
>>>> erroneous as they still use the 0, annotation. And I just realised, that
>>>> somehow, upstream patch c90bb7b slightly differs from my initial patch
>>>> [1] on the mailing list.
>>>
>>> Your patch should probably be CC: stable so that existing kernel
>>> versions get fixed. That said, I'd argue that since the original patch
>>> never actually had any effect since it applied to the wrong node, the
>>> best fix for stable kernels is simply to revert it rather than fixing
>>> it, to avoid the potential for behaviour changes and regressions.
>>> Starting with kernel 4.8 (I think), that patch will begin to have actual
>>> effect.
>> There is no current existing stable kernel that is affected, as it went
>> in during the last merge window in 4.6-rc1. So no need for fixing
>> stable. Maybe it's still possible to fix it as the stabilisation window
>> is still open and 4.7 is not released yet?
>
> Unfortunately a patch to remove the 0, prefix from all nodes except the
> GPU was now merged into the arm-soc tree, which means that if we try to
> get this into v4.7, then we'll have to make sure to patch up the unit
> address again for v4.8.
>
> I have no objections to doing that, so feel free to add my Acked-by and
> resend this to a...@kernel.org. When you do, please keep linux-tegra in
> Cc so that we can track it, and maybe mention that you want this to go
> into v4.7 and how this came about to be, so that the arm-soc maintainers
> won't be surprised when the patch to revert this shows up in a couple of
> days for v4.8.
Alright, I'll prepare it and add a RESEND as well as your Acked-by.
Thank you.
>
> Can you take care of sending out the second patch as well? Probably best
> to send it the same way as this, with a mention that it's targetted at
> v4.8 and a revert of this one.
Yep, I'll take care of it. I'm tracking this patch since January in any
case :-)
Ralf
>
> Thanks,
> Thierry
>
--
Ralf Ramsauer
PGP: 0x8F10049B
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ARM: tegra: fix erroneous address in dts
On 07/15/2016 06:01 PM, Stephen Warren wrote:
> On 07/15/2016 03:37 AM, Ralf Ramsauer wrote:
>> On 07/15/2016 12:02 AM, Thierry Reding wrote:
>>> On Thu, Jul 14, 2016 at 06:48:57PM +0200, Ralf Ramsauer wrote:
>>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. The address
>>>> specification inside the dts is wrong. Fix it and use the correct
>>>> address.
>>>>
>>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1
>>>> device tree")
>>>> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
>>>> ---
>>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> These addresses are correct. The 0, prefix was dropped from the unit
>>> address in commit b5896f67ab3c ("ARM: tegra: Remove commas from unit
>>> addresses on Tegra124").
>>>
>>> What's the problem that you're seeing? What's not working for you?
>>
>> I cannot find b5896f67ab3c neither in swarren's tree nor in linux
>> upstream. But there's d0bc5aaf890 in swarren's linux-tegra tree that
>> matches your described changes and was committed on 1st of July. But
>> this patch is not upstream yet, while the other patch is.
>
> The fix is in linux-next, and will be in mainline soon I expect.
Ah okay, but I still wonder how my original patch got changed on its
way... The original version on the mailinglist was not buggy.
>
> My github linux-tegra.git isn't relevant since it's just my own personal
> dev branch, but for reference, the commit is there since it's based on
> linux-next.
>
>> Have a look at mainline tegra124-jetson-tk1.dts, there the addresses are
>> erroneous as they still use the 0, annotation. And I just realised, that
>> somehow, upstream patch c90bb7b slightly differs from my initial patch
>> [1] on the mailing list.
>
> Your patch should probably be CC: stable so that existing kernel
> versions get fixed. That said, I'd argue that since the original patch
> never actually had any effect since it applied to the wrong node, the
> best fix for stable kernels is simply to revert it rather than fixing
> it, to avoid the potential for behaviour changes and regressions.
> Starting with kernel 4.8 (I think), that patch will begin to have actual
> effect.
There is no current existing stable kernel that is affected, as it went
in during the last merge window in 4.6-rc1. So no need for fixing
stable. Maybe it's still possible to fix it as the stabilisation window
is still open and 4.7 is not released yet?
Ralf
--
Ralf Ramsauer
PGP: 0x8F10049B
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ARM: tegra: fix erroneous address in dts
On 07/15/2016 06:01 PM, Stephen Warren wrote:
> On 07/15/2016 03:37 AM, Ralf Ramsauer wrote:
>> On 07/15/2016 12:02 AM, Thierry Reding wrote:
>>> On Thu, Jul 14, 2016 at 06:48:57PM +0200, Ralf Ramsauer wrote:
>>>> c90bb7b enabled the high speed UARTs of the Jetson TK1. The address
>>>> specification inside the dts is wrong. Fix it and use the correct
>>>> address.
>>>>
>>>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1
>>>> device tree")
>>>> Signed-off-by: Ralf Ramsauer
>>>> ---
>>>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> These addresses are correct. The 0, prefix was dropped from the unit
>>> address in commit b5896f67ab3c ("ARM: tegra: Remove commas from unit
>>> addresses on Tegra124").
>>>
>>> What's the problem that you're seeing? What's not working for you?
>>
>> I cannot find b5896f67ab3c neither in swarren's tree nor in linux
>> upstream. But there's d0bc5aaf890 in swarren's linux-tegra tree that
>> matches your described changes and was committed on 1st of July. But
>> this patch is not upstream yet, while the other patch is.
>
> The fix is in linux-next, and will be in mainline soon I expect.
Ah okay, but I still wonder how my original patch got changed on its
way... The original version on the mailinglist was not buggy.
>
> My github linux-tegra.git isn't relevant since it's just my own personal
> dev branch, but for reference, the commit is there since it's based on
> linux-next.
>
>> Have a look at mainline tegra124-jetson-tk1.dts, there the addresses are
>> erroneous as they still use the 0, annotation. And I just realised, that
>> somehow, upstream patch c90bb7b slightly differs from my initial patch
>> [1] on the mailing list.
>
> Your patch should probably be CC: stable so that existing kernel
> versions get fixed. That said, I'd argue that since the original patch
> never actually had any effect since it applied to the wrong node, the
> best fix for stable kernels is simply to revert it rather than fixing
> it, to avoid the potential for behaviour changes and regressions.
> Starting with kernel 4.8 (I think), that patch will begin to have actual
> effect.
There is no current existing stable kernel that is affected, as it went
in during the last merge window in 4.6-rc1. So no need for fixing
stable. Maybe it's still possible to fix it as the stabilisation window
is still open and 4.7 is not released yet?
Ralf
--
Ralf Ramsauer
PGP: 0x8F10049B
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ARM: tegra: fix erroneous address in dts
On 07/15/2016 12:02 AM, Thierry Reding wrote:
> On Thu, Jul 14, 2016 at 06:48:57PM +0200, Ralf Ramsauer wrote:
>> c90bb7b enabled the high speed UARTs of the Jetson TK1. The address
>> specification inside the dts is wrong. Fix it and use the correct
>> address.
>>
>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device
>> tree")
>> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
>> ---
>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> These addresses are correct. The 0, prefix was dropped from the unit
> address in commit b5896f67ab3c ("ARM: tegra: Remove commas from unit
> addresses on Tegra124").
>
> What's the problem that you're seeing? What's not working for you?
I cannot find b5896f67ab3c neither in swarren's tree nor in linux
upstream. But there's d0bc5aaf890 in swarren's linux-tegra tree that
matches your described changes and was committed on 1st of July. But
this patch is not upstream yet, while the other patch is.
Have a look at mainline tegra124-jetson-tk1.dts, there the addresses are
erroneous as they still use the 0, annotation. And I just realised, that
somehow, upstream patch c90bb7b slightly differs from my initial patch
[1] on the mailing list.
Ralf
[1] http://permalink.gmane.org/gmane.linux.ports.tegra/24779
>
> Thierry
>
--
Ralf Ramsauer
PGP: 0x8F10049B
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] ARM: tegra: fix erroneous address in dts
On 07/15/2016 12:02 AM, Thierry Reding wrote:
> On Thu, Jul 14, 2016 at 06:48:57PM +0200, Ralf Ramsauer wrote:
>> c90bb7b enabled the high speed UARTs of the Jetson TK1. The address
>> specification inside the dts is wrong. Fix it and use the correct
>> address.
>>
>> Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device
>> tree")
>> Signed-off-by: Ralf Ramsauer
>> ---
>> arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> These addresses are correct. The 0, prefix was dropped from the unit
> address in commit b5896f67ab3c ("ARM: tegra: Remove commas from unit
> addresses on Tegra124").
>
> What's the problem that you're seeing? What's not working for you?
I cannot find b5896f67ab3c neither in swarren's tree nor in linux
upstream. But there's d0bc5aaf890 in swarren's linux-tegra tree that
matches your described changes and was committed on 1st of July. But
this patch is not upstream yet, while the other patch is.
Have a look at mainline tegra124-jetson-tk1.dts, there the addresses are
erroneous as they still use the 0, annotation. And I just realised, that
somehow, upstream patch c90bb7b slightly differs from my initial patch
[1] on the mailing list.
Ralf
[1] http://permalink.gmane.org/gmane.linux.ports.tegra/24779
>
> Thierry
>
--
Ralf Ramsauer
PGP: 0x8F10049B
signature.asc
Description: OpenPGP digital signature
[PATCH] ARM: tegra: fix erroneous address in dts
c90bb7b enabled the high speed UARTs of the Jetson TK1. The address
specification inside the dts is wrong. Fix it and use the correct
address.
Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device tree")
Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
---
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 941f362..f4d8125 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1386,7 +1386,7 @@
* Pin 41: BR_UART1_TXD
* Pin 44: BR_UART1_RXD
*/
- serial@70006000 {
+ serial@0,70006000 {
compatible = "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart";
status = "okay";
};
@@ -1398,7 +1398,7 @@
* Pin 71: UART2_CTS_L
* Pin 74: UART2_RTS_L
*/
- serial@70006040 {
+ serial@0,70006040 {
compatible = "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart";
status = "okay";
};
--
2.7.3
[PATCH] ARM: tegra: fix erroneous address in dts
c90bb7b enabled the high speed UARTs of the Jetson TK1. The address
specification inside the dts is wrong. Fix it and use the correct
address.
Fixes: c90bb7b9b9 ("ARM: tegra: Add high speed UARTs to Jetson TK1 device tree")
Signed-off-by: Ralf Ramsauer
---
arch/arm/boot/dts/tegra124-jetson-tk1.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
index 941f362..f4d8125 100644
--- a/arch/arm/boot/dts/tegra124-jetson-tk1.dts
+++ b/arch/arm/boot/dts/tegra124-jetson-tk1.dts
@@ -1386,7 +1386,7 @@
* Pin 41: BR_UART1_TXD
* Pin 44: BR_UART1_RXD
*/
- serial@70006000 {
+ serial@0,70006000 {
compatible = "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart";
status = "okay";
};
@@ -1398,7 +1398,7 @@
* Pin 71: UART2_CTS_L
* Pin 74: UART2_RTS_L
*/
- serial@70006040 {
+ serial@0,70006040 {
compatible = "nvidia,tegra124-hsuart", "nvidia,tegra30-hsuart";
status = "okay";
};
--
2.7.3
Re: [PATCH] ARM, ARM64: Un-inlined and exported symbols of is_hyp_mode_available() and related functions
Hello Marc,
On 10/01/2015 11:03 AM, Marc Zyngier wrote:
> On 30/09/15 22:40, Ralf Ramsauer wrote:
>> Hypervisors may be available as modules, but need to check if
>> HYP mode is enabled. Functions are provided for these means, but
>> are not exported to modules; in particular since __boot_cpu_mode
>> is not accessible.
>>
>> Instead of exporting symbol __boot_cpu_mode, un-inline
>> is_hyp_mode_available() and related functions. This has no negative
>> impact since they are never called in hot paths.
>>
>> Though all modified files are licensed under GPLv2, for ARM we use
>> EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL to be consistent with the
>> rest of the exports in arch/arm/kernel/setup.c.
> I think that's for the authors of the original code to decide.
>
>> Signed-off-by: Ralf Ramsauer
>> Signed-off-by: Wolfgang Mauerer
>> ---
>> arch/arm/include/asm/virt.h | 21 +++--
>> arch/arm/kernel/setup.c | 29 +
>> arch/arm64/include/asm/virt.h | 11 ++-
>> arch/arm64/kernel/setup.c | 14 ++
>> 4 files changed, 48 insertions(+), 27 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
>> index 4371f45..37d970d 100644
>> --- a/arch/arm/include/asm/virt.h
>> +++ b/arch/arm/include/asm/virt.h
>> @@ -42,15 +42,7 @@
>> */
>> extern int __boot_cpu_mode;
>>
>> -static inline void sync_boot_mode(void)
>> -{
>> -/*
>> - * As secondaries write to __boot_cpu_mode with caches disabled, we
>> - * must flush the corresponding cache entries to ensure the visibility
>> - * of their writes.
>> - */
>> -sync_cache_r(&__boot_cpu_mode);
>> -}
>> +void sync_boot_mode(void);
>>
>> void __hyp_set_vectors(unsigned long phys_vector_base);
>> unsigned long __hyp_get_vectors(void);
>> @@ -63,17 +55,10 @@ unsigned long __hyp_get_vectors(void);
>> void hyp_mode_check(void);
>>
>> /* Reports the availability of HYP mode */
>> -static inline bool is_hyp_mode_available(void)
>> -{
>> -return ((__boot_cpu_mode & MODE_MASK) == HYP_MODE &&
>> -!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH));
>> -}
>> +bool is_hyp_mode_available(void);
>>
>> /* Check if the bootloader has booted CPUs in different modes */
>> -static inline bool is_hyp_mode_mismatched(void)
>> -{
>> -return !!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH);
>> -}
>> +bool is_hyp_mode_mismatched(void);
>> #endif
>>
>> #endif /* __ASSEMBLY__ */
>> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> index 20edd34..c2c39f1 100644
>> --- a/arch/arm/kernel/setup.c
>> +++ b/arch/arm/kernel/setup.c
>> @@ -915,6 +915,35 @@ static void __init reserve_crashkernel(void)
>> static inline void reserve_crashkernel(void) {}
>> #endif /* CONFIG_KEXEC */
>>
>> +#ifdef CONFIG_ARM_VIRT_EXT
>> +void sync_boot_mode(void)
> Why is this function global? As far as I can see, it is only called from
> that very same file.
I un-inlined all inlined static functions as they are visible but not
callable from modules. sync_boot_mode() is defined in a global visible
header and callable from any part of the kernel that includes
. As it is only used in setup.c (and in fact it only makes
sense to use it there), wouldn't it be better to move its definition to
setup.c?
>
>> +{
>> +/*
>> +* As secondaries write to __boot_cpu_mode with caches disabled, we
>> +* must flush the corresponding cache entries to ensure the visibility
>> +* of their writes.
>> +*/
>> +sync_cache_r(&__boot_cpu_mode);
>> +}
>> +#endif
>> +
>> +#ifndef ZIMAGE
> What is the point of this #ifndef? setup.c is not part of the decompressor.
Ok, I see, this #ifndef is not necessary inside setup.c.
>
>> +/* Reports the availability of HYP mode */
>> +bool is_hyp_mode_available(void)
>> +{
>> +return ((__boot_cpu_mode & MODE_MASK) == HYP_MODE &&
>> +!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH));
>> +}
>> +EXPORT_SYMBOL(is_hyp_mode_available);
>> +
>> +/* Check if the bootloader has booted CPUs in different modes */
>> +bool is_hyp_mode_mismatched(void)
>> +{
>> +return !!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH);
>> +}
>> +EXPORT_SYMBOL(is_hyp_mode_mismatched);
>> +#endif
>> +
>> void __init hyp_mode_check(void)
>> {
>> #ifdef CONFIG_AR
Re: [PATCH] ARM, ARM64: Un-inlined and exported symbols of is_hyp_mode_available() and related functions
Hello Marc,
On 10/01/2015 11:03 AM, Marc Zyngier wrote:
> On 30/09/15 22:40, Ralf Ramsauer wrote:
>> Hypervisors may be available as modules, but need to check if
>> HYP mode is enabled. Functions are provided for these means, but
>> are not exported to modules; in particular since __boot_cpu_mode
>> is not accessible.
>>
>> Instead of exporting symbol __boot_cpu_mode, un-inline
>> is_hyp_mode_available() and related functions. This has no negative
>> impact since they are never called in hot paths.
>>
>> Though all modified files are licensed under GPLv2, for ARM we use
>> EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL to be consistent with the
>> rest of the exports in arch/arm/kernel/setup.c.
> I think that's for the authors of the original code to decide.
>
>> Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
>> Signed-off-by: Wolfgang Mauerer <wolfgang.maue...@oth-regensburg.de>
>> ---
>> arch/arm/include/asm/virt.h | 21 +++--
>> arch/arm/kernel/setup.c | 29 +
>> arch/arm64/include/asm/virt.h | 11 ++-
>> arch/arm64/kernel/setup.c | 14 ++
>> 4 files changed, 48 insertions(+), 27 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
>> index 4371f45..37d970d 100644
>> --- a/arch/arm/include/asm/virt.h
>> +++ b/arch/arm/include/asm/virt.h
>> @@ -42,15 +42,7 @@
>> */
>> extern int __boot_cpu_mode;
>>
>> -static inline void sync_boot_mode(void)
>> -{
>> -/*
>> - * As secondaries write to __boot_cpu_mode with caches disabled, we
>> - * must flush the corresponding cache entries to ensure the visibility
>> - * of their writes.
>> - */
>> -sync_cache_r(&__boot_cpu_mode);
>> -}
>> +void sync_boot_mode(void);
>>
>> void __hyp_set_vectors(unsigned long phys_vector_base);
>> unsigned long __hyp_get_vectors(void);
>> @@ -63,17 +55,10 @@ unsigned long __hyp_get_vectors(void);
>> void hyp_mode_check(void);
>>
>> /* Reports the availability of HYP mode */
>> -static inline bool is_hyp_mode_available(void)
>> -{
>> -return ((__boot_cpu_mode & MODE_MASK) == HYP_MODE &&
>> -!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH));
>> -}
>> +bool is_hyp_mode_available(void);
>>
>> /* Check if the bootloader has booted CPUs in different modes */
>> -static inline bool is_hyp_mode_mismatched(void)
>> -{
>> -return !!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH);
>> -}
>> +bool is_hyp_mode_mismatched(void);
>> #endif
>>
>> #endif /* __ASSEMBLY__ */
>> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> index 20edd34..c2c39f1 100644
>> --- a/arch/arm/kernel/setup.c
>> +++ b/arch/arm/kernel/setup.c
>> @@ -915,6 +915,35 @@ static void __init reserve_crashkernel(void)
>> static inline void reserve_crashkernel(void) {}
>> #endif /* CONFIG_KEXEC */
>>
>> +#ifdef CONFIG_ARM_VIRT_EXT
>> +void sync_boot_mode(void)
> Why is this function global? As far as I can see, it is only called from
> that very same file.
I un-inlined all inlined static functions as they are visible but not
callable from modules. sync_boot_mode() is defined in a global visible
header and callable from any part of the kernel that includes
. As it is only used in setup.c (and in fact it only makes
sense to use it there), wouldn't it be better to move its definition to
setup.c?
>
>> +{
>> +/*
>> +* As secondaries write to __boot_cpu_mode with caches disabled, we
>> +* must flush the corresponding cache entries to ensure the visibility
>> +* of their writes.
>> +*/
>> +sync_cache_r(&__boot_cpu_mode);
>> +}
>> +#endif
>> +
>> +#ifndef ZIMAGE
> What is the point of this #ifndef? setup.c is not part of the decompressor.
Ok, I see, this #ifndef is not necessary inside setup.c.
>
>> +/* Reports the availability of HYP mode */
>> +bool is_hyp_mode_available(void)
>> +{
>> +return ((__boot_cpu_mode & MODE_MASK) == HYP_MODE &&
>> +!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH));
>> +}
>> +EXPORT_SYMBOL(is_hyp_mode_available);
>> +
>> +/* Check if the bootloader has booted CPUs in different modes */
>> +bool is_hyp_mode_mismatched(void)
>> +{
>> +return !!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH);
>> +}
>> +EXPORT_SYMBOL(is_hyp_mode_mismatched);
>> +#endif
>> +
>> void __in
[PATCH] ARM, ARM64: Un-inlined and exported symbols of is_hyp_mode_available() and related functions
Hypervisors may be available as modules, but need to check if
HYP mode is enabled. Functions are provided for these means, but
are not exported to modules; in particular since __boot_cpu_mode
is not accessible.
Instead of exporting symbol __boot_cpu_mode, un-inline
is_hyp_mode_available() and related functions. This has no negative
impact since they are never called in hot paths.
Though all modified files are licensed under GPLv2, for ARM we use
EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL to be consistent with the
rest of the exports in arch/arm/kernel/setup.c.
Signed-off-by: Ralf Ramsauer
Signed-off-by: Wolfgang Mauerer
---
arch/arm/include/asm/virt.h | 21 +++--
arch/arm/kernel/setup.c | 29 +
arch/arm64/include/asm/virt.h | 11 ++-
arch/arm64/kernel/setup.c | 14 ++
4 files changed, 48 insertions(+), 27 deletions(-)
diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
index 4371f45..37d970d 100644
--- a/arch/arm/include/asm/virt.h
+++ b/arch/arm/include/asm/virt.h
@@ -42,15 +42,7 @@
*/
extern int __boot_cpu_mode;
-static inline void sync_boot_mode(void)
-{
- /*
-* As secondaries write to __boot_cpu_mode with caches disabled, we
-* must flush the corresponding cache entries to ensure the visibility
-* of their writes.
-*/
- sync_cache_r(&__boot_cpu_mode);
-}
+void sync_boot_mode(void);
void __hyp_set_vectors(unsigned long phys_vector_base);
unsigned long __hyp_get_vectors(void);
@@ -63,17 +55,10 @@ unsigned long __hyp_get_vectors(void);
void hyp_mode_check(void);
/* Reports the availability of HYP mode */
-static inline bool is_hyp_mode_available(void)
-{
- return ((__boot_cpu_mode & MODE_MASK) == HYP_MODE &&
- !(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH));
-}
+bool is_hyp_mode_available(void);
/* Check if the bootloader has booted CPUs in different modes */
-static inline bool is_hyp_mode_mismatched(void)
-{
- return !!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH);
-}
+bool is_hyp_mode_mismatched(void);
#endif
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 20edd34..c2c39f1 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -915,6 +915,35 @@ static void __init reserve_crashkernel(void)
static inline void reserve_crashkernel(void) {}
#endif /* CONFIG_KEXEC */
+#ifdef CONFIG_ARM_VIRT_EXT
+void sync_boot_mode(void)
+{
+ /*
+ * As secondaries write to __boot_cpu_mode with caches disabled, we
+ * must flush the corresponding cache entries to ensure the visibility
+ * of their writes.
+ */
+ sync_cache_r(&__boot_cpu_mode);
+}
+#endif
+
+#ifndef ZIMAGE
+/* Reports the availability of HYP mode */
+bool is_hyp_mode_available(void)
+{
+ return ((__boot_cpu_mode & MODE_MASK) == HYP_MODE &&
+ !(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH));
+}
+EXPORT_SYMBOL(is_hyp_mode_available);
+
+/* Check if the bootloader has booted CPUs in different modes */
+bool is_hyp_mode_mismatched(void)
+{
+ return !!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH);
+}
+EXPORT_SYMBOL(is_hyp_mode_mismatched);
+#endif
+
void __init hyp_mode_check(void)
{
#ifdef CONFIG_ARM_VIRT_EXT
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 7a5df52..48c6170 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -38,17 +38,10 @@ void __hyp_set_vectors(phys_addr_t phys_vector_base);
phys_addr_t __hyp_get_vectors(void);
/* Reports the availability of HYP mode */
-static inline bool is_hyp_mode_available(void)
-{
- return (__boot_cpu_mode[0] == BOOT_CPU_MODE_EL2 &&
- __boot_cpu_mode[1] == BOOT_CPU_MODE_EL2);
-}
+bool is_hyp_mode_available(void);
/* Check if the bootloader has booted CPUs in different modes */
-static inline bool is_hyp_mode_mismatched(void)
-{
- return __boot_cpu_mode[0] != __boot_cpu_mode[1];
-}
+bool is_hyp_mode_mismatched(void);
/* The section containing the hypervisor text */
extern char __hyp_text_start[];
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 6bab21f..6442d70 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -62,6 +62,7 @@
#include
#include
#include
+#include
#include
unsigned long elf_hwcap __read_mostly;
@@ -195,6 +196,19 @@ static void __init smp_build_mpidr_hash(void)
__flush_dcache_area(_hash, sizeof(struct mpidr_hash));
}
+bool is_hyp_mode_available(void)
+{
+ return (__boot_cpu_mode[0] == BOOT_CPU_MODE_EL2 &&
+ __boot_cpu_mode[1] == BOOT_CPU_MODE_EL2);
+}
+EXPORT_SYMBOL_GPL(is_hyp_mode_available);
+
+bool is_hyp_mode_mismatched(void)
+{
+ return __boot_cpu_mode[0] != __boot_cpu_mode[1];
+}
+EXPORT_SYMBOL_GPL(is_hyp_mode_mismatched);
+
static void
[PATCH] ARM, ARM64: Un-inlined and exported symbols of is_hyp_mode_available() and related functions
Hypervisors may be available as modules, but need to check if
HYP mode is enabled. Functions are provided for these means, but
are not exported to modules; in particular since __boot_cpu_mode
is not accessible.
Instead of exporting symbol __boot_cpu_mode, un-inline
is_hyp_mode_available() and related functions. This has no negative
impact since they are never called in hot paths.
Though all modified files are licensed under GPLv2, for ARM we use
EXPORT_SYMBOL instead of EXPORT_SYMBOL_GPL to be consistent with the
rest of the exports in arch/arm/kernel/setup.c.
Signed-off-by: Ralf Ramsauer <r...@ramses-pyramidenbau.de>
Signed-off-by: Wolfgang Mauerer <wolfgang.maue...@oth-regensburg.de>
---
arch/arm/include/asm/virt.h | 21 +++--
arch/arm/kernel/setup.c | 29 +
arch/arm64/include/asm/virt.h | 11 ++-
arch/arm64/kernel/setup.c | 14 ++
4 files changed, 48 insertions(+), 27 deletions(-)
diff --git a/arch/arm/include/asm/virt.h b/arch/arm/include/asm/virt.h
index 4371f45..37d970d 100644
--- a/arch/arm/include/asm/virt.h
+++ b/arch/arm/include/asm/virt.h
@@ -42,15 +42,7 @@
*/
extern int __boot_cpu_mode;
-static inline void sync_boot_mode(void)
-{
- /*
-* As secondaries write to __boot_cpu_mode with caches disabled, we
-* must flush the corresponding cache entries to ensure the visibility
-* of their writes.
-*/
- sync_cache_r(&__boot_cpu_mode);
-}
+void sync_boot_mode(void);
void __hyp_set_vectors(unsigned long phys_vector_base);
unsigned long __hyp_get_vectors(void);
@@ -63,17 +55,10 @@ unsigned long __hyp_get_vectors(void);
void hyp_mode_check(void);
/* Reports the availability of HYP mode */
-static inline bool is_hyp_mode_available(void)
-{
- return ((__boot_cpu_mode & MODE_MASK) == HYP_MODE &&
- !(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH));
-}
+bool is_hyp_mode_available(void);
/* Check if the bootloader has booted CPUs in different modes */
-static inline bool is_hyp_mode_mismatched(void)
-{
- return !!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH);
-}
+bool is_hyp_mode_mismatched(void);
#endif
#endif /* __ASSEMBLY__ */
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 20edd34..c2c39f1 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -915,6 +915,35 @@ static void __init reserve_crashkernel(void)
static inline void reserve_crashkernel(void) {}
#endif /* CONFIG_KEXEC */
+#ifdef CONFIG_ARM_VIRT_EXT
+void sync_boot_mode(void)
+{
+ /*
+ * As secondaries write to __boot_cpu_mode with caches disabled, we
+ * must flush the corresponding cache entries to ensure the visibility
+ * of their writes.
+ */
+ sync_cache_r(&__boot_cpu_mode);
+}
+#endif
+
+#ifndef ZIMAGE
+/* Reports the availability of HYP mode */
+bool is_hyp_mode_available(void)
+{
+ return ((__boot_cpu_mode & MODE_MASK) == HYP_MODE &&
+ !(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH));
+}
+EXPORT_SYMBOL(is_hyp_mode_available);
+
+/* Check if the bootloader has booted CPUs in different modes */
+bool is_hyp_mode_mismatched(void)
+{
+ return !!(__boot_cpu_mode & BOOT_CPU_MODE_MISMATCH);
+}
+EXPORT_SYMBOL(is_hyp_mode_mismatched);
+#endif
+
void __init hyp_mode_check(void)
{
#ifdef CONFIG_ARM_VIRT_EXT
diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
index 7a5df52..48c6170 100644
--- a/arch/arm64/include/asm/virt.h
+++ b/arch/arm64/include/asm/virt.h
@@ -38,17 +38,10 @@ void __hyp_set_vectors(phys_addr_t phys_vector_base);
phys_addr_t __hyp_get_vectors(void);
/* Reports the availability of HYP mode */
-static inline bool is_hyp_mode_available(void)
-{
- return (__boot_cpu_mode[0] == BOOT_CPU_MODE_EL2 &&
- __boot_cpu_mode[1] == BOOT_CPU_MODE_EL2);
-}
+bool is_hyp_mode_available(void);
/* Check if the bootloader has booted CPUs in different modes */
-static inline bool is_hyp_mode_mismatched(void)
-{
- return __boot_cpu_mode[0] != __boot_cpu_mode[1];
-}
+bool is_hyp_mode_mismatched(void);
/* The section containing the hypervisor text */
extern char __hyp_text_start[];
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 6bab21f..6442d70 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -62,6 +62,7 @@
#include
#include
#include
+#include
#include
unsigned long elf_hwcap __read_mostly;
@@ -195,6 +196,19 @@ static void __init smp_build_mpidr_hash(void)
__flush_dcache_area(_hash, sizeof(struct mpidr_hash));
}
+bool is_hyp_mode_available(void)
+{
+ return (__boot_cpu_mode[0] == BOOT_CPU_MODE_EL2 &&
+ __boot_cpu_mode[1] == BOOT_CPU_MODE_EL2);
+}
+EXPORT_SYMBOL_GPL(is_hyp_mode_available);
+
+bool is_hyp_mode_mismatched(void)
+{
+ return __boot_cpu_mode[0] != __boo
