* [PATCH v1 0/6] perf cs-etm: Fix tracing packet handling and minor refactoring
From: Arnaldo Carvalho de Melo @ 2018-06-19 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkyxuz+tPrC7wb1omsw+qj=7ZB5t6FRbqZz54994g62q6g@mail.gmail.com>
Em Tue, Jun 19, 2018 at 11:46:02AM -0600, Mathieu Poirier escreveu:
> On Sun, 17 Jun 2018 at 23:10, Leo Yan <leo.yan@linaro.org> wrote:
> >
> > Due the current code is missing to handle cs-etm start tracing packet
> > and CS_ETM_TRACE_ON packet, we fail to generate branch sample for them.
> >
> > This patch series is to fix cs-etm tracing packet handling:
> >
> > Patch 0001 is to add invalid address macro for readable coding;
> >
> > Patch 0002 is one minor fixing to return error code for instruction
> > sample failure;
> >
> > Patches 0003~0006 are fixing patches for start tracing packet
> > and CS_ETM_TRACE_ON packet.
> >
> > This patch series is applied on acme tree [1] on branch perf/core with
> > latest commit: e238cf2e3d2e ("perf intel-pt: Fix packet decoding of CYC
> > packets"). Also applied successfully this patch series on Linus tree
> > on 4.18-rc1.
> >
> > This patch series has been verified on Hikey620 platform with below two
> > commands:
> > perf script --itrace=i10000il128 -F cpu,event,ip,addr,sym -k ./vmlinux
> > perf script -F cpu,event,ip,addr,sym -k ./vmlinux
> >
> > [1] https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> >
> >
> > Leo Yan (6):
> > perf cs-etm: Introduce invalid address macro
> > perf cs-etm: Bail out immediately for instruction sample failure
> > perf cs-etm: Fix start tracing packet handling
> > perf cs-etm: Support dummy address value for CS_ETM_TRACE_ON packet
> > perf cs-etm: Generate branch sample when receiving a CS_ETM_TRACE_ON
> > packet
> > perf cs-etm: Generate branch sample for CS_ETM_TRACE_ON packet
> >
> > tools/perf/util/cs-etm-decoder/cs-etm-decoder.c | 10 ++--
> > tools/perf/util/cs-etm-decoder/cs-etm-decoder.h | 1 +
> > tools/perf/util/cs-etm.c | 71 +++++++++++++++++++++----
> > 3 files changed, 68 insertions(+), 14 deletions(-)
>
> Good day Arnaldo,
>
> I am good with this set:
>
> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>
> Please consider for inclusion in your tree if you are satisfied with the work.
I'll take a look and get it into perf/core, now I'm concentrating on
perf/urgent work.
Thanks,
- Arnaldo
^ permalink raw reply
* [RFC PATCH] ARM: Use logical or instead of addition for badr address calculation
From: Ard Biesheuvel @ 2018-06-19 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu9JTsKEwwKN4OjmNHLf_86s753f2yEdo=7esERdUCaWiQ@mail.gmail.com>
On 19 June 2018 at 20:17, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 19 June 2018 at 19:24, Guenter Roeck <linux@roeck-us.net> wrote:
>> On Tue, Jun 19, 2018 at 03:35:07PM +0200, Ard Biesheuvel wrote:
>>> >>
>>> >> + /* this needs to be a separate macro or \@ does not work correctly
>>> >> */
>>> >> + .macro __badr, c, rd, sym
>>> >> + .eqv .Lsym\@, \sym
>>> >> + adr\c \rd, .Lsym\@ + 1
>>> >
>>> >
>>> > Wild shot, but the following works for me.
>>> >
>>> > .eqv .Lsym\@, \sym + 1
>>> > adr\c \rd, .Lsym\@
>>> >
>>> > Does it make sense ?
>>> >
>>>
>>> Interesting. Do you mean this works with your 2.30 binutils that
>>> triggers the original issue?
>>>
>>
>> Yes, it does. It is also the solution used for some graphics libraries,
>> though of course now I don't find the link anymore.
>>
>> Guess this is going nowhere given Russell's response, so I'll just
>> live with it, like obviously everyone else does already. I built
>> a toolchain using gcc 7.3.0 and binutils 2.28.1 which "solves"
>> the problem for me.
>>
>
> If we can live with using a wide encoding unconditionally, we could
> consider something like below. That forces the symbol references to be
> resolved at link time, which means we completely sidestep the new GAS
> code.
>
> -----------8<----------------
> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Date: Tue, 16 Jan 2018 12:12:45 +0000
> Subject: [PATCH] ARM: assembler: prevent ADR from setting the Thumb bit twice
>
> To work around recent issues where ADR references to Thumb function
> symbols may or may not have the Thumb bit set already when they are
> resolved by GAS, reference the symbol indirectly via a global symbol
> typed as 'function', and emit a relocation that lets the linker fix
> up the reference.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
> index 6ae42ad29518..1a55ce4b245c 100644
> --- a/arch/arm/include/asm/assembler.h
> +++ b/arch/arm/include/asm/assembler.h
> @@ -195,13 +195,22 @@
> .irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
> .macro badr\c, rd, sym
> #ifdef CONFIG_THUMB2_KERNEL
> - adr\c \rd, \sym + 1
> + __badr \c, \rd, \sym
> #else
> adr\c \rd, \sym
> #endif
> .endm
> .endr
>
> + /* this needs to be a separate macro or \@ does not work correctly */
> + .macro __badr, c, rd, sym
> + .globl .Lsym_\sym\()_\@
> + .type .Lsym_\sym\()_\@, %function
> + .set .Lsym_\sym\()_\@, \sym
> + .reloc ., R_ARM_THM_ALU_PREL_11_0, .Lsym_\sym\()_\@
> + adr\c\().w \rd, .
> + .endm
> +
> /*
> * Get current thread_info.
> */
It seems we can drop the .globl btw
^ permalink raw reply
* [RFC PATCH] driver core: add a debugfs entry to show deferred devices
From: Javier Martinez Canillas @ 2018-06-19 18:20 UTC (permalink / raw)
To: linux-arm-kernel
For debugging purposes it may be useful to know what are the devices whose
probe function was deferred. Add a debugfs entry showing that information.
$ cat /sys/kernel/debug/deferred_devices
48070000.i2c:twl at 48:bci
musb-hdrc.0.auto
omapdrm.0
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---
drivers/base/dd.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 1435d7281c6..98a3ab4a852 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -224,6 +224,43 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
}
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+#include <linux/debugfs.h>
+
+static struct dentry *deferred_devices;
+
+/*
+ * deferred_devs_show() - Show the devices in the deferred probe pending list.
+ */
+static int deferred_devs_show(struct seq_file *s, void *data)
+{
+ struct device_private *curr;
+ int ret = 0;
+
+ mutex_lock(&deferred_probe_mutex);
+
+ list_for_each_entry(curr, &deferred_probe_pending_list, deferred_probe)
+ seq_printf(s, "%s\n", dev_name(curr->device));
+
+ mutex_unlock(&deferred_probe_mutex);
+
+ return ret;
+}
+
+static int deferred_devs_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, deferred_devs_show, inode->i_private);
+}
+
+static const struct file_operations deferred_devs_fops = {
+ .owner = THIS_MODULE,
+ .open = deferred_devs_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+#endif /* IS_ENABLED(CONFIG_DEBUG_FS) */
+
/**
* deferred_probe_initcall() - Enable probing of deferred devices
*
@@ -233,6 +270,14 @@ void device_unblock_probing(void)
*/
static int deferred_probe_initcall(void)
{
+ if (IS_ENABLED(CONFIG_DEBUG_FS)) {
+ deferred_devices = debugfs_create_file("deferred_devices",
+ 0444, NULL, NULL,
+ &deferred_devs_fops);
+ if (!deferred_devices)
+ return -ENOMEM;
+ }
+
driver_deferred_probe_enable = true;
driver_deferred_probe_trigger();
/* Sort as many dependencies as possible before exiting initcalls */
--
2.17.1
^ permalink raw reply related
* [PATCH] dt-bindings: Fix unbalanced quotation marks
From: Dmitry Torokhov @ 2018-06-19 18:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617143127.11421-1-j.neuschaefer@gmx.net>
On Sun, Jun 17, 2018 at 04:31:18PM +0200, Jonathan Neusch?fer wrote:
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
> index 121d9b7c79a2..1063c30d53f7 100644
> --- a/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
> +++ b/Documentation/devicetree/bindings/input/touchscreen/hideep.txt
> @@ -32,7 +32,7 @@ i2c at 00000000 {
> reg = <0x6c>;
> interrupt-parent = <&gpx1>;
> interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
> - vdd-supply = <&ldo15_reg>";
> + vdd-supply = <&ldo15_reg>;
> vid-supply = <&ldo18_reg>;
> reset-gpios = <&gpx1 5 0>;
> touchscreen-size-x = <1080>;
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
--
Dmitry
^ permalink raw reply
* [RFC PATCH] ARM: Use logical or instead of addition for badr address calculation
From: Ard Biesheuvel @ 2018-06-19 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-SWaq0s46x_RCQ_TVN2vCBFp_NDmW3jUgUyMrbGoLcbA@mail.gmail.com>
On 19 June 2018 at 20:20, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 19 June 2018 at 20:17, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 19 June 2018 at 19:24, Guenter Roeck <linux@roeck-us.net> wrote:
>>> On Tue, Jun 19, 2018 at 03:35:07PM +0200, Ard Biesheuvel wrote:
>>>> >>
>>>> >> + /* this needs to be a separate macro or \@ does not work correctly
>>>> >> */
>>>> >> + .macro __badr, c, rd, sym
>>>> >> + .eqv .Lsym\@, \sym
>>>> >> + adr\c \rd, .Lsym\@ + 1
>>>> >
>>>> >
>>>> > Wild shot, but the following works for me.
>>>> >
>>>> > .eqv .Lsym\@, \sym + 1
>>>> > adr\c \rd, .Lsym\@
>>>> >
>>>> > Does it make sense ?
>>>> >
>>>>
>>>> Interesting. Do you mean this works with your 2.30 binutils that
>>>> triggers the original issue?
>>>>
>>>
>>> Yes, it does. It is also the solution used for some graphics libraries,
>>> though of course now I don't find the link anymore.
>>>
>>> Guess this is going nowhere given Russell's response, so I'll just
>>> live with it, like obviously everyone else does already. I built
>>> a toolchain using gcc 7.3.0 and binutils 2.28.1 which "solves"
>>> the problem for me.
>>>
>>
>> If we can live with using a wide encoding unconditionally, we could
>> consider something like below. That forces the symbol references to be
>> resolved at link time, which means we completely sidestep the new GAS
>> code.
>>
>> -----------8<----------------
>> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Date: Tue, 16 Jan 2018 12:12:45 +0000
>> Subject: [PATCH] ARM: assembler: prevent ADR from setting the Thumb bit twice
>>
>> To work around recent issues where ADR references to Thumb function
>> symbols may or may not have the Thumb bit set already when they are
>> resolved by GAS, reference the symbol indirectly via a global symbol
>> typed as 'function', and emit a relocation that lets the linker fix
>> up the reference.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>
>> diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
>> index 6ae42ad29518..1a55ce4b245c 100644
>> --- a/arch/arm/include/asm/assembler.h
>> +++ b/arch/arm/include/asm/assembler.h
>> @@ -195,13 +195,22 @@
>> .irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
>> .macro badr\c, rd, sym
>> #ifdef CONFIG_THUMB2_KERNEL
>> - adr\c \rd, \sym + 1
>> + __badr \c, \rd, \sym
>> #else
>> adr\c \rd, \sym
>> #endif
>> .endm
>> .endr
>>
>> + /* this needs to be a separate macro or \@ does not work correctly */
>> + .macro __badr, c, rd, sym
>> + .globl .Lsym_\sym\()_\@
>> + .type .Lsym_\sym\()_\@, %function
>> + .set .Lsym_\sym\()_\@, \sym
>> + .reloc ., R_ARM_THM_ALU_PREL_11_0, .Lsym_\sym\()_\@
>> + adr\c\().w \rd, .
>> + .endm
>> +
>> /*
>> * Get current thread_info.
>> */
>
> It seems we can drop the .globl btw
Another note: this makes the badr unusable for switching from ARM to
Thumb2 mode. I didn't spot this right away because i have this patch
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/commit/?h=arm-badr-cleanup&id=40ac917eef965aae3146e49f7948d1db9c01e968
in my working tree. I will send it out separately if we are ok with
going ahead with this
(That means we should retain the explicit .w suffix rather than using
the W() in this macro since the new code sequence is fundamentally
Thumb2 only)
^ permalink raw reply
* [RFC PATCH v2] driver core: add a debugfs entry to show deferred devices
From: Javier Martinez Canillas @ 2018-06-19 18:33 UTC (permalink / raw)
To: linux-arm-kernel
For debugging purposes it may be useful to know what are the devices whose
probe function was deferred. Add a debugfs entry showing that information.
$ cat /sys/kernel/debug/deferred_devices
48070000.i2c:twl at 48:bci
musb-hdrc.0.auto
omapdrm.0
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
---
Changes in v2:
- Remove unneeded ret variable from deferred_devs_show()
drivers/base/dd.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 1435d7281c6..d95bd4636fc 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -224,6 +224,42 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
}
+#if IS_ENABLED(CONFIG_DEBUG_FS)
+#include <linux/debugfs.h>
+
+static struct dentry *deferred_devices;
+
+/*
+ * deferred_devs_show() - Show the devices in the deferred probe pending list.
+ */
+static int deferred_devs_show(struct seq_file *s, void *data)
+{
+ struct device_private *curr;
+
+ mutex_lock(&deferred_probe_mutex);
+
+ list_for_each_entry(curr, &deferred_probe_pending_list, deferred_probe)
+ seq_printf(s, "%s\n", dev_name(curr->device));
+
+ mutex_unlock(&deferred_probe_mutex);
+
+ return 0;
+}
+
+static int deferred_devs_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, deferred_devs_show, inode->i_private);
+}
+
+static const struct file_operations deferred_devs_fops = {
+ .owner = THIS_MODULE,
+ .open = deferred_devs_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+#endif /* IS_ENABLED(CONFIG_DEBUG_FS) */
+
/**
* deferred_probe_initcall() - Enable probing of deferred devices
*
@@ -233,6 +269,14 @@ void device_unblock_probing(void)
*/
static int deferred_probe_initcall(void)
{
+ if (IS_ENABLED(CONFIG_DEBUG_FS)) {
+ deferred_devices = debugfs_create_file("deferred_devices",
+ 0444, NULL, NULL,
+ &deferred_devs_fops);
+ if (!deferred_devices)
+ return -ENOMEM;
+ }
+
driver_deferred_probe_enable = true;
driver_deferred_probe_trigger();
/* Sort as many dependencies as possible before exiting initcalls */
--
2.17.1
^ permalink raw reply related
* [PATCH 04/11] input: rohm_bu21023: switch to i2c_lock_segment
From: Dmitry Torokhov @ 2018-06-19 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615101506.8012-5-peda@axentia.se>
On Fri, Jun 15, 2018 at 12:14:59PM +0200, Peter Rosin wrote:
> Locking the root adapter for __i2c_transfer will deadlock if the
> device sits behind a mux-locked I2C mux. Switch to the finer-grained
> i2c_lock_segment. If the device does not sit behind a mux-locked mux,
> the two locking variants are equivalent.
>
> Signed-off-by: Peter Rosin <peda@axentia.se>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
I'm OK with it going through Wolfram's tree; I do not think I'd need an
immutable branch for this even...
> ---
> drivers/input/touchscreen/rohm_bu21023.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/input/touchscreen/rohm_bu21023.c b/drivers/input/touchscreen/rohm_bu21023.c
> index bda0500c9b57..22d79db07234 100644
> --- a/drivers/input/touchscreen/rohm_bu21023.c
> +++ b/drivers/input/touchscreen/rohm_bu21023.c
> @@ -304,7 +304,7 @@ static int rohm_i2c_burst_read(struct i2c_client *client, u8 start, void *buf,
> msg[1].len = len;
> msg[1].buf = buf;
>
> - i2c_lock_adapter(adap);
> + i2c_lock_segment(adap);
>
> for (i = 0; i < 2; i++) {
> if (__i2c_transfer(adap, &msg[i], 1) < 0) {
> @@ -313,7 +313,7 @@ static int rohm_i2c_burst_read(struct i2c_client *client, u8 start, void *buf,
> }
> }
>
> - i2c_unlock_adapter(adap);
> + i2c_unlock_segment(adap);
>
> return ret;
> }
> --
> 2.11.0
>
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH 0/2] Make badr macro compatible with newer GAS versions
From: Ard Biesheuvel @ 2018-06-19 19:26 UTC (permalink / raw)
To: linux-arm-kernel
Work around the mindless and backward incompatible change in GAS that
prevents us from using a simple addition to set the Thumb bit in local
symbol references taken using 'adr' instructions (#2)
As a preparatory step, remove badr occurrences in ARM code sequences
contained in Thumb2 kernels.
Ard Biesheuvel (2):
ARM: avoid badr macro for switching to Thumb-2 mode
ARM: assembler: prevent ADR from setting the Thumb bit twice
arch/arm/common/mcpm_head.S | 5 ++---
arch/arm/include/asm/assembler.h | 22 +++++++++++++++++++-
arch/arm/kernel/head-nommu.S | 7 +++----
arch/arm/kernel/head.S | 15 +++++++------
arch/arm/kernel/sleep.S | 7 +++----
5 files changed, 36 insertions(+), 20 deletions(-)
--
2.17.1
^ permalink raw reply
* [PATCH 1/2] ARM: avoid badr macro for switching to Thumb-2 mode
From: Ard Biesheuvel @ 2018-06-19 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619192633.21846-1-ard.biesheuvel@linaro.org>
Switching to Thumb-2 mode can be done using a single 'sub' instruction
so use that instead of the badr macro in various places in the code.
This allows us to reimplement the macro in a way that does not allow
it to be used in ARM code sequences when building a Thumb2 kernel.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/common/mcpm_head.S | 5 ++---
arch/arm/kernel/head-nommu.S | 7 +++----
arch/arm/kernel/head.S | 15 +++++++--------
arch/arm/kernel/sleep.S | 7 +++----
4 files changed, 15 insertions(+), 19 deletions(-)
diff --git a/arch/arm/common/mcpm_head.S b/arch/arm/common/mcpm_head.S
index 08b3bb9bc6a2..4c72314e87a3 100644
--- a/arch/arm/common/mcpm_head.S
+++ b/arch/arm/common/mcpm_head.S
@@ -49,10 +49,9 @@
ENTRY(mcpm_entry_point)
ARM_BE8(setend be)
- THUMB( badr r12, 1f )
- THUMB( bx r12 )
+ THUMB( sub pc, pc, #3 )
THUMB( .thumb )
-1:
+
mrc p15, 0, r0, c0, c0, 5 @ MPIDR
ubfx r9, r0, #0, #8 @ r9 = cpu
ubfx r10, r0, #8, #8 @ r10 = cluster
diff --git a/arch/arm/kernel/head-nommu.S b/arch/arm/kernel/head-nommu.S
index dae8fa2f72c5..406dab0b773c 100644
--- a/arch/arm/kernel/head-nommu.S
+++ b/arch/arm/kernel/head-nommu.S
@@ -47,10 +47,9 @@ ENTRY(stext)
.arm
ENTRY(stext)
- THUMB( badr r9, 1f ) @ Kernel is always entered in ARM.
- THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
- THUMB( .thumb ) @ switch to Thumb now.
- THUMB(1: )
+ THUMB( sub pc, pc, #3 ) @ Kernel is always entered in ARM.
+ THUMB( .thumb ) @ If this is a Thumb-2 kernel,
+ @ switch to Thumb now.
#endif
setmode PSR_F_BIT | PSR_I_BIT | SVC_MODE, r9 @ ensure svc mode
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index 4b815821ec02..1e44ee9b2074 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -80,10 +80,9 @@
ENTRY(stext)
ARM_BE8(setend be ) @ ensure we are in BE8 mode
- THUMB( badr r9, 1f ) @ Kernel is always entered in ARM.
- THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
- THUMB( .thumb ) @ switch to Thumb now.
- THUMB(1: )
+ THUMB( sub pc, pc, #3 ) @ Kernel is always entered in ARM.
+ THUMB( .thumb ) @ If this is a Thumb-2 kernel,
+ @ switch to Thumb now.
#ifdef CONFIG_ARM_VIRT_EXT
bl __hyp_stub_install
@@ -363,10 +362,10 @@ __turn_mmu_on_loc:
.text
.arm
ENTRY(secondary_startup_arm)
- THUMB( badr r9, 1f ) @ Kernel is entered in ARM.
- THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
- THUMB( .thumb ) @ switch to Thumb now.
- THUMB(1: )
+ THUMB( sub pc, pc, #3 ) @ Kernel is entered in ARM.
+ THUMB( .thumb ) @ If this is a Thumb-2 kernel,
+ @ switch to Thumb now.
+
ENTRY(secondary_startup)
/*
* Common entry point for secondary CPUs.
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index a8257fc9cf2a..76b3d7c1c8d0 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -123,10 +123,9 @@ ENDPROC(cpu_resume_after_mmu)
#ifdef CONFIG_MMU
.arm
ENTRY(cpu_resume_arm)
- THUMB( badr r9, 1f ) @ Kernel is entered in ARM.
- THUMB( bx r9 ) @ If this is a Thumb-2 kernel,
- THUMB( .thumb ) @ switch to Thumb now.
- THUMB(1: )
+ THUMB( sub pc, pc, #3 ) @ Kernel is entered in ARM.
+ THUMB( .thumb ) @ If this is a Thumb-2 kernel,
+ @ switch to Thumb now.
#endif
ENTRY(cpu_resume)
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] ARM: assembler: prevent ADR from setting the Thumb bit twice
From: Ard Biesheuvel @ 2018-06-19 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619192633.21846-1-ard.biesheuvel@linaro.org>
To work around recent issues where ADR references to Thumb function
symbols may or may not have the Thumb bit set already when they are
resolved by GAS, reference the symbol indirectly via a local symbol
typed as 'function', and emit the reference in a way that prevents
the assembler from resolving it directly. Instead, it will be fixed
up by the linker, which behaves consistently and according to spec
when it comes to relocations of symbols with function annotation
targetting wide ADR instructions.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/include/asm/assembler.h | 22 +++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 6ae42ad29518..ee2d4eb26318 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -195,13 +195,33 @@
.irp c,,eq,ne,cs,cc,mi,pl,vs,vc,hi,ls,ge,lt,gt,le,hs,lo
.macro badr\c, rd, sym
#ifdef CONFIG_THUMB2_KERNEL
- adr\c \rd, \sym + 1
+ __badr \c, \rd, \sym
#else
adr\c \rd, \sym
#endif
.endm
.endr
+ /*
+ * GAS's behavior with respect to setting the Thumb bit on addresses
+ * of locally defined symbols taken using adr instructions is
+ * inconsistent, and so we are better off letting the linker handle
+ * it instead. So emit the reference as a relocation, and force a
+ * wide encoding so that we can support both forward and backward
+ * references, and avoid the R_ARM_THM_PC8 relocation that operates
+ * on the narrow encoding, which is documented as not taking the
+ * Thumb bit into account. (IHI 0044E ELF for the ARM Architecture)
+ *
+ * Note that this needs to be a separate macro or \@ does not work
+ * correctly.
+ */
+ .macro __badr, c, rd, sym
+ .set .Lsym\@, \sym
+ .type .Lsym\@, %function
+ .reloc ., R_ARM_THM_ALU_PREL_11_0, .Lsym\@
+ adr\c\().w \rd, .
+ .endm
+
/*
* Get current thread_info.
*/
--
2.17.1
^ permalink raw reply related
* [PATCH 0/5] arm64: Initial support Texas Instrument's AM654 Platform
From: Nishanth Menon @ 2018-06-19 19:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is an update from RFC posted earlier:
https://marc.info/?l=linux-arm-kernel&m=152817866312732&w=2
The following series enables support for newest addition in TI's SoC
portfolio - AM654 SoC.
The series is based off v4.18-rc1, also available here:
https://github.com/nmenon/linux-2.6-playground/tree/upstream/v4.18-rc1/k3-1-am6-base
Key changes since RFC are indicated in respective patches:
* dt bindings updates (from review comments)
* device tree is split up to incorporate ranges and bus segments
* Cosmetic fixes including renaming the base dts to prevent confusion
* UART has been split out
Consolidated all patches (including all series) are available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-am6-integ
Full Boot log (integrated of all series) is available here:
https://pastebin.ubuntu.com/p/bBFmnzYtCd/
NOTE: The uart series is seperated out and we get operational console only
after that series is merged.
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
The Linux development follows closely the 66AK2G SoC model in aarch64.
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Nishanth Menon (5):
dt-bindings: arm: ti: Add bindings for AM654 SoC
arm64: Add support for TI's K3 Multicore SoC architecture
arm64: dts: ti: Add Support for AM654 SoC
soc: ti: Add Support for AM654 SoC config option
arm64: dts: ti: Add support for AM654 EVM base board
Documentation/devicetree/bindings/arm/ti/k3.txt | 23 +++++
MAINTAINERS | 9 ++
arch/arm64/Kconfig.platforms | 7 ++
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/ti/Makefile | 9 ++
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 31 +++++++
arch/arm64/boot/dts/ti/k3-am65.dtsi | 87 ++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 36 ++++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 115 ++++++++++++++++++++++++
drivers/soc/ti/Kconfig | 14 +++
10 files changed, 332 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
create mode 100644 arch/arm64/boot/dts/ti/Makefile
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-main.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am65.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
--
2.15.1
^ permalink raw reply
* [PATCH 1/5] dt-bindings: arm: ti: Add bindings for AM654 SoC
From: Nishanth Menon @ 2018-06-19 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194253.27288-1-nm@ti.com>
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subsystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since RFC:
* Dropped the generic terminology for compatibles
previous RFC: https://patchwork.kernel.org/patch/10447643/
Documentation/devicetree/bindings/arm/ti/k3.txt | 23 +++++++++++++++++++++++
MAINTAINERS | 7 +++++++
2 files changed, 30 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/ti/k3.txt
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.txt b/Documentation/devicetree/bindings/arm/ti/k3.txt
new file mode 100644
index 000000000000..6a059cabb2da
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ti/k3.txt
@@ -0,0 +1,23 @@
+Texas Instruments K3 Multicore SoC architecture device tree bindings
+--------------------------------------------------------------------
+
+Platforms based on Texas Instruments K3 Multicore SoC architecture
+shall follow the following scheme:
+
+SoCs
+----
+
+Each device tree root node must specify which exact SoC in K3 Multicore SoC
+architecture it uses, using one of the following compatible values:
+
+- AM654
+ compatible = "ti,am654";
+
+Boards
+------
+
+In addition, each device tree root node must specify which one or more
+of the following board-specific compatible values:
+
+- AM654 EVM
+ compatible = "ti,am654-evm", "ti,am654";
diff --git a/MAINTAINERS b/MAINTAINERS
index 9d5eeff51b5f..fbd93eee41ae 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2087,6 +2087,13 @@ L: linux-kernel at vger.kernel.org
S: Maintained
F: drivers/memory/*emif*
+ARM/TEXAS INSTRUMENTS K3 ARCHITECTURE
+M: Tero Kristo <t-kristo@ti.com>
+M: Nishanth Menon <nm@ti.com>
+L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
+S: Supported
+F: Documentation/devicetree/bindings/arm/ti/k3.txt
+
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
M: Santosh Shilimkar <ssantosh@kernel.org>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
--
2.15.1
^ permalink raw reply related
* [PATCH 2/5] arm64: Add support for TI's K3 Multicore SoC architecture
From: Nishanth Menon @ 2018-06-19 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194253.27288-1-nm@ti.com>
Add support for Texas Instrument's K3 Multicore SoC architecture
processors.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since RFC:
* None
RFC: https://patchwork.kernel.org/patch/10447633/
arch/arm64/Kconfig.platforms | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
index d5aeac351fc3..52df25bf4f8c 100644
--- a/arch/arm64/Kconfig.platforms
+++ b/arch/arm64/Kconfig.platforms
@@ -71,6 +71,13 @@ config ARCH_EXYNOS
help
This enables support for ARMv8 based Samsung Exynos SoC family.
+config ARCH_K3
+ bool "Texas Instruments Inc. K3 multicore SoC architecture"
+ select PM_GENERIC_DOMAINS if PM
+ help
+ This enables support for Texas Instruments' K3 multicore SoC
+ architecture.
+
config ARCH_LAYERSCAPE
bool "ARMv8 based Freescale Layerscape SoC family"
select EDAC_SUPPORT
--
2.15.1
^ permalink raw reply related
* [PATCH 3/5] arm64: dts: ti: Add Support for AM654 SoC
From: Nishanth Menon @ 2018-06-19 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194253.27288-1-nm@ti.com>
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subsystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
NOTE:
1. AM654 is the first of the device variants, hence we introduce a
generic am65.dtsi.
2. We indicate the proper bus topology, the ranges are elaborated in
each bus segment instead of using the top level ranges to make sure
that peripherals in each segment use the address space accurately.
3. Peripherals in each bus segment is maintained in a separate dtsi
allowing for reuse in different bus segment representation from a
different core such as R5. This is also the reason for maintaining a
1-1 address map in the ranges.
4. Cache descriptions follow the ARM64 standard description.
Further tweaks may be necessary as we introduce more complex devices,
but can be introduced in context of the device introduction.
Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since RFC:
* Bus topology representation
* Device nodes underneath a bus segment moved to seperate dtsi (allowing reuse
where applicable)
* Ranges used in the bus segments
* Processor level nodes moved to the root node
* SoC node dropped.
* Default for device nodes is "enabled" instead of explicitly enabling them in
board dts.
* UART patches are spun off into a different series to prevent maintainer
tree level conflicts. (wakeup and mcu domain peripherals to be introduced
there)
* Few addresses had uppercase hexadecimal values, replaced with standard
lowercase hex values
* Commit message updates
* Kconfig was spun out as seperate patch
RFC: https://patchwork.kernel.org/patch/10447719/ , https://patchwork.kernel.org/patch/10453659/
MAINTAINERS | 1 +
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 31 +++++++++
arch/arm64/boot/dts/ti/k3-am65.dtsi | 87 +++++++++++++++++++++++
arch/arm64/boot/dts/ti/k3-am654.dtsi | 115 +++++++++++++++++++++++++++++++
4 files changed, 234 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am65-main.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am65.dtsi
create mode 100644 arch/arm64/boot/dts/ti/k3-am654.dtsi
diff --git a/MAINTAINERS b/MAINTAINERS
index fbd93eee41ae..6785ceaf5b0b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2093,6 +2093,7 @@ M: Nishanth Menon <nm@ti.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/arm/ti/k3.txt
+F: arch/arm64/boot/dts/ti/k3-*
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
M: Santosh Shilimkar <ssantosh@kernel.org>
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
new file mode 100644
index 000000000000..2409344df4fa
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC Family Main Domain peripherals
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+&cbass_main {
+ gic500: interrupt-controller at 1800000 {
+ compatible = "arm,gic-v3";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ reg = <0x01800000 0x10000>, /* GICD */
+ <0x01880000 0x90000>; /* GICR */
+ /*
+ * vcpumntirq:
+ * virtual CPU interface maintenance interrupt
+ */
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH>;
+
+ gic_its: gic-its at 18200000 {
+ compatible = "arm,gic-v3-its";
+ reg = <0x01820000 0x10000>;
+ msi-controller;
+ #msi-cells = <1>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/ti/k3-am65.dtsi b/arch/arm64/boot/dts/ti/k3-am65.dtsi
new file mode 100644
index 000000000000..8c0f78332157
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am65.dtsi
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC Family
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ model = "Texas Instruments K3 AM654 SoC";
+ compatible = "ti,am654";
+ interrupt-parent = <&gic500>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ chosen { };
+
+ firmware {
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+
+ psci: psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+ };
+
+ a53_timer0: timer-cl0-cpu0 {
+ compatible = "arm,armv8-timer";
+ interrupts = <GIC_PPI 13 IRQ_TYPE_LEVEL_LOW>, /* cntpsirq */
+ <GIC_PPI 14 IRQ_TYPE_LEVEL_LOW>, /* cntpnsirq */
+ <GIC_PPI 11 IRQ_TYPE_LEVEL_LOW>, /* cntvirq */
+ <GIC_PPI 10 IRQ_TYPE_LEVEL_LOW>; /* cnthpirq */
+ };
+
+ pmu: pmu {
+ compatible = "arm,armv8-pmuv3";
+ /* Recommendation from GIC500 TRM Table A.3 */
+ interrupts = <GIC_PPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ cbass_main: cbass at 100000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x00100000 0x00 0x00100000 0x00020000>, /* ctrl mmr */
+ <0x00600000 0x00 0x00600000 0x00001100>, /* GPIO */
+ <0x00900000 0x00 0x00900000 0x00012000>, /* serdes */
+ <0x01000000 0x00 0x01000000 0x0af02400>, /* Most peripherals */
+ <0x30800000 0x00 0x30800000 0x0bc00000>, /* MAIN NAVSS */
+ /* MCUSS Range */
+ <0x28380000 0x00 0x28380000 0x03880000>,
+ <0x40200000 0x00 0x40200000 0x00900100>,
+ <0x42040000 0x00 0x42040000 0x03ac2400>,
+ <0x45100000 0x00 0x45100000 0x00c24000>,
+ <0x46000000 0x00 0x46000000 0x00200000>,
+ <0x47000000 0x00 0x47000000 0x00068400>;
+
+ cbass_mcu: cbass at 28380000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x28380000 0x28380000 0x03880000>, /* MCU NAVSS*/
+ <0x40200000 0x40200000 0x00900100>, /* First peripheral window */
+ <0x42040000 0x42040000 0x03ac2400>, /* WKUP */
+ <0x45100000 0x45100000 0x00c24000>, /* MMRs, remaining NAVSS */
+ <0x46000000 0x46000000 0x00200000>, /* CPSW */
+ <0x47000000 0x47000000 0x00068400>; /* OSPI space 1 */
+
+ cbass_wakeup: cbass at 42040000 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ /* WKUP Basic peripherals */
+ ranges = <0x42040000 0x42040000 0x03ac2400>;
+ };
+ };
+ };
+};
+
+/* Now include the peripherals for each bus segments */
+#include "k3-am65-main.dtsi"
diff --git a/arch/arm64/boot/dts/ti/k3-am654.dtsi b/arch/arm64/boot/dts/ti/k3-am654.dtsi
new file mode 100644
index 000000000000..2affa6f6617e
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am654.dtsi
@@ -0,0 +1,115 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for AM6 SoC family in Quad core configuration
+ *
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+#include "k3-am65.dtsi"
+
+/ {
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cpu-map {
+ cluster0: cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+
+ cluster1: cluster1 {
+ core0 {
+ cpu = <&cpu2>;
+ };
+
+ core1 {
+ cpu = <&cpu3>;
+ };
+ };
+ };
+
+ cpu0: cpu at 0 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x000>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu1: cpu at 1 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x001>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_0>;
+ };
+
+ cpu2: cpu at 100 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x100>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_1>;
+ };
+
+ cpu3: cpu at 101 {
+ compatible = "arm,cortex-a53", "arm,armv8";
+ reg = <0x101>;
+ device_type = "cpu";
+ enable-method = "psci";
+ i-cache-size = <0x8000>;
+ i-cache-line-size = <64>;
+ i-cache-sets = <256>;
+ d-cache-size = <0x8000>;
+ d-cache-line-size = <64>;
+ d-cache-sets = <128>;
+ next-level-cache = <&L2_1>;
+ };
+ };
+
+ L2_0: l2-cache0 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-size = <0x80000>;
+ cache-line-size = <64>;
+ cache-sets = <512>;
+ next-level-cache = <&msmc_l3>;
+ };
+
+ L2_1: l2-cache1 {
+ compatible = "cache";
+ cache-level = <2>;
+ cache-size = <0x80000>;
+ cache-line-size = <64>;
+ cache-sets = <512>;
+ next-level-cache = <&msmc_l3>;
+ };
+
+ msmc_l3: l3-cache0 {
+ compatible = "cache";
+ cache-level = <3>;
+ };
+};
--
2.15.1
^ permalink raw reply related
* [PATCH 4/5] soc: ti: Add Support for AM654 SoC config option
From: Nishanth Menon @ 2018-06-19 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194253.27288-1-nm@ti.com>
Add option to build AM6 SoC specific components
Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
(new patch broken out from: https://patchwork.kernel.org/patch/10447719/)
drivers/soc/ti/Kconfig | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/soc/ti/Kconfig b/drivers/soc/ti/Kconfig
index 92770d84a288..be4570baad96 100644
--- a/drivers/soc/ti/Kconfig
+++ b/drivers/soc/ti/Kconfig
@@ -1,3 +1,17 @@
+# 64-bit ARM SoCs from TI
+if ARM64
+
+if ARCH_K3
+
+config ARCH_K3_AM6_SOC
+ bool "K3 AM6 SoC"
+ help
+ Enable support for TI's AM6 SoC Family support
+
+endif
+
+endif
+
#
# TI SOC drivers
#
--
2.15.1
^ permalink raw reply related
* [PATCH 5/5] arm64: dts: ti: Add support for AM654 EVM base board
From: Nishanth Menon @ 2018-06-19 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194253.27288-1-nm@ti.com>
The EValuation Module(EVM) platform for AM654 consists of a
common Base board + one or more of daughter cards, which include:
a) "Personality Modules", which can be specific to a profile, such as
ICSSG enabled or Multi-media (including audio).
b) SERDES modules, which may be 2 lane PCIe or two port PCIe + USB2
c) Camera daughter card
d) various display panels
Among other options. There are two basic configurations defined which
include an "EVM" configuration and "IDK" (Industrial development kit)
which differ in the specific combination of daughter cards that are
used.
To simplify support, we choose to support just the base board as the
core device tree file and all daughter cards would be expected to be
device tree overlays.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since RFC:
* Since defaults are enabled, and uart has been spun off, dropped the
redundant nodes from baseboard dts
RFC: https://patchwork.kernel.org/patch/10447741/
MAINTAINERS | 1 +
arch/arm64/boot/dts/Makefile | 1 +
arch/arm64/boot/dts/ti/Makefile | 9 +++++++
arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 36 ++++++++++++++++++++++++++
4 files changed, 47 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/Makefile
create mode 100644 arch/arm64/boot/dts/ti/k3-am654-base-board.dts
diff --git a/MAINTAINERS b/MAINTAINERS
index 6785ceaf5b0b..e9e916d1fb52 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2093,6 +2093,7 @@ M: Nishanth Menon <nm@ti.com>
L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
S: Supported
F: Documentation/devicetree/bindings/arm/ti/k3.txt
+F: arch/arm64/boot/dts/ti/Makefile
F: arch/arm64/boot/dts/ti/k3-*
ARM/TEXAS INSTRUMENT KEYSTONE ARCHITECTURE
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index 3543bc324553..4690364d584b 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -23,5 +23,6 @@ subdir-y += rockchip
subdir-y += socionext
subdir-y += sprd
subdir-y += synaptics
+subdir-y += ti
subdir-y += xilinx
subdir-y += zte
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
new file mode 100644
index 000000000000..63e619d0b5b8
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# Make file to build device tree binaries for boards based on
+# Texas Instruments Inc processors
+#
+# Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+#
+
+dtb-$(CONFIG_ARCH_K3_AM6_SOC) += k3-am654-base-board.dtb
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
new file mode 100644
index 000000000000..af6956fdc13f
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
+ */
+
+/dts-v1/;
+
+#include "k3-am654.dtsi"
+
+/ {
+ compatible = "ti,am654-evm", "ti,am654";
+ model = "Texas Instruments AM654 Base Board";
+
+ chosen {
+ stdout-path = "serial2:115200n8";
+ bootargs = "earlycon=ns16550a,mmio32,0x02800000";
+ };
+
+ memory at 80000000 {
+ device_type = "memory";
+ /* 4G RAM */
+ reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
+ <0x00000008 0x80000000 0x00000000 0x80000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ secure_ddr: secure_ddr at 9e800000 {
+ reg = <0 0x9e800000 0 0x01800000>; /* for OP-TEE */
+ alignment = <0x1000>;
+ no-map;
+ };
+ };
+};
--
2.15.1
^ permalink raw reply related
* [PATCH 0/2] firmware: ti_sci: Add host-id as an optional parameter
From: Nishanth Menon @ 2018-06-19 19:44 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Please find attached series to enable host-id as an optional dt property.
Changes Since RFC:
* Updated commit message based on feedback from Rob.
The series is based on v4.18-rc1 and is available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-1-am6-tisci
Consolidated all patches (including all series) are available here:
https://github.com/nmenon/linux-2.6-playground/commits/upstream/v4.18-rc1/k3-am6-integ
Full Boot log (integrated of all series for AM654) is available here:
https://pastebin.ubuntu.com/p/bBFmnzYtCd/
Nishanth Menon (2):
Documentation: dt: keystone: ti-sci: Add optional host-id parameter
firmware: ti_sci: Provide host-id as an optional dt parameter
.../devicetree/bindings/arm/keystone/ti,sci.txt | 4 ++++
drivers/firmware/ti_sci.c | 24 ++++++++++++++++++----
2 files changed, 24 insertions(+), 4 deletions(-)
--
2.15.1
^ permalink raw reply
* [PATCH 1/2] Documentation: dt: keystone: ti-sci: Add optional host-id parameter
From: Nishanth Menon @ 2018-06-19 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194421.3432-1-nm@ti.com>
Texas Instrument's System Control Interface (TISCI) permits
the ability for OSs running in virtual machines to be able to
independently communicate with the firmware without the need going
through an hypervisor.
The "host-id" in effect is the hardware representation of the
host (example: VMs locked to a core) as identified to the System
Controller. Hypervisors can either fill in appropriate host-ids in dt
used for each VM instance OR may use prebuilt blobs where the host-ids
are pre-populated, as appropriate for the OS running in the VMs.
This is introduced as an optional parameter to maintain consistency
with legacy device tree blobs.
We call this with a vendor prefix to prevent any possible confusion
with SCSI ID (m68k) kernel option.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since RFC:
* Commit message update to elaborate usage in VM
RFC: https://patchwork.kernel.org/patch/10447753/
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
index 31f5f9a104cc..b56a02c10ae6 100644
--- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
@@ -45,11 +45,15 @@ Optional Properties:
debug_messages - Map the Debug message region
- reg: register space corresponding to the debug_messages
- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
+- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
+ for identification of host processing entities such as virtual
+ machines
Example (K2G):
-------------
pmmc: pmmc {
compatible = "ti,k2g-sci";
+ ti,host-id = <2>;
mbox-names = "rx", "tx";
mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
<&msgmgr &msgmgr_proxy_pmmc_tx>;
--
2.15.1
^ permalink raw reply related
* [PATCH 2/2] firmware: ti_sci: Provide host-id as an optional dt parameter
From: Nishanth Menon @ 2018-06-19 19:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619194421.3432-1-nm@ti.com>
Texas Instrument's System Control Interface (TISCI) permits the
ability for Operating Systems to running in virtual machines to be
able to independently communicate with the firmware without the need
going through an hypervisor.
The "host-id" in effect is the hardware representation of the
host (example: VMs locked to a core) as identified to the System
Controller.
Provide support as an optional parameter implementation and use the
compatible data as default if one is not provided by device tree.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since RFC: None
RFC: https://patchwork.kernel.org/patch/10447715/
drivers/firmware/ti_sci.c | 24 ++++++++++++++++++++----
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 7fa744793bc5..69ed1464175c 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -66,14 +66,14 @@ struct ti_sci_xfers_info {
/**
* struct ti_sci_desc - Description of SoC integration
- * @host_id: Host identifier representing the compute entity
+ * @default_host_id: Host identifier representing the compute entity
* @max_rx_timeout_ms: Timeout for communication with SoC (in Milliseconds)
* @max_msgs: Maximum number of messages that can be pending
* simultaneously in the system
* @max_msg_size: Maximum size of data per message that can be handled.
*/
struct ti_sci_desc {
- u8 host_id;
+ u8 default_host_id;
int max_rx_timeout_ms;
int max_msgs;
int max_msg_size;
@@ -94,6 +94,7 @@ struct ti_sci_desc {
* @chan_rx: Receive mailbox channel
* @minfo: Message info
* @node: list head
+ * @host_id: Host ID
* @users: Number of users of this instance
*/
struct ti_sci_info {
@@ -110,6 +111,7 @@ struct ti_sci_info {
struct mbox_chan *chan_rx;
struct ti_sci_xfers_info minfo;
struct list_head node;
+ u8 host_id;
/* protected by ti_sci_list_mutex */
int users;
@@ -370,7 +372,7 @@ static struct ti_sci_xfer *ti_sci_get_one_xfer(struct ti_sci_info *info,
hdr->seq = xfer_id;
hdr->type = msg_type;
- hdr->host = info->desc->host_id;
+ hdr->host = info->host_id;
hdr->flags = msg_flags;
return xfer;
@@ -1793,7 +1795,7 @@ static int tisci_reboot_handler(struct notifier_block *nb, unsigned long mode,
/* Description for K2G */
static const struct ti_sci_desc ti_sci_pmmc_k2g_desc = {
- .host_id = 2,
+ .default_host_id = 2,
/* Conservative duration */
.max_rx_timeout_ms = 1000,
/* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
@@ -1819,6 +1821,7 @@ static int ti_sci_probe(struct platform_device *pdev)
int ret = -EINVAL;
int i;
int reboot = 0;
+ u32 h_id;
of_id = of_match_device(ti_sci_of_match, dev);
if (!of_id) {
@@ -1833,6 +1836,19 @@ static int ti_sci_probe(struct platform_device *pdev)
info->dev = dev;
info->desc = desc;
+ ret = of_property_read_u32(dev->of_node, "ti,host-id", &h_id);
+ /* if the property is not present in DT, use a default from desc */
+ if (ret < 0) {
+ info->host_id = info->desc->default_host_id;
+ } else {
+ if (!h_id) {
+ dev_warn(dev, "Host ID 0 is reserved for firmware\n");
+ info->host_id = info->desc->default_host_id;
+ } else {
+ info->host_id = h_id;
+ }
+ }
+
reboot = of_property_read_bool(dev->of_node,
"ti,system-reboot-controller");
INIT_LIST_HEAD(&info->node);
--
2.15.1
^ permalink raw reply related
* [PATCH] dt-bindings: Fix unbalanced quotation marks
From: Florian Fainelli @ 2018-06-19 19:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180617143127.11421-1-j.neuschaefer@gmx.net>
On 06/17/2018 07:31 AM, Jonathan Neusch?fer wrote:
> Multiple binding documents have various forms of unbalanced quotation
> marks. Fix them.
>
> Signed-off-by: Jonathan Neusch?fer <j.neuschaefer@gmx.net>
> ---
[snip]
> Documentation/devicetree/bindings/mips/brcm/soc.txt | 2 +-
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [RFC PATCH v2] driver core: add a debugfs entry to show deferred devices
From: Andy Shevchenko @ 2018-06-19 19:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619183356.32106-1-javierm@redhat.com>
On Tue, Jun 19, 2018 at 9:33 PM, Javier Martinez Canillas
<javierm@redhat.com> wrote:
> For debugging purposes it may be useful to know what are the devices whose
> probe function was deferred. Add a debugfs entry showing that information.
>
> $ cat /sys/kernel/debug/deferred_devices
> 48070000.i2c:twl at 48:bci
> musb-hdrc.0.auto
> omapdrm.0
> +#if IS_ENABLED(CONFIG_DEBUG_FS)
> +#include <linux/debugfs.h>
> +
> +static struct dentry *deferred_devices;
> +
> +/*
> + * deferred_devs_show() - Show the devices in the deferred probe pending list.
> + */
> +static int deferred_devs_show(struct seq_file *s, void *data)
> +{
> + struct device_private *curr;
> +
> + mutex_lock(&deferred_probe_mutex);
> +
> + list_for_each_entry(curr, &deferred_probe_pending_list, deferred_probe)
> + seq_printf(s, "%s\n", dev_name(curr->device));
> +
> + mutex_unlock(&deferred_probe_mutex);
> +
> + return 0;
> +}
> +
> +static int deferred_devs_open(struct inode *inode, struct file *file)
> +{
> + return single_open(file, deferred_devs_show, inode->i_private);
> +}
> +
> +static const struct file_operations deferred_devs_fops = {
> + .owner = THIS_MODULE,
> + .open = deferred_devs_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> +};
Isn't this DEFINE_SHOW_ATTRIBUTE() ?
> +#endif /* IS_ENABLED(CONFIG_DEBUG_FS) */
> +
> /**
> * deferred_probe_initcall() - Enable probing of deferred devices
> *
> @@ -233,6 +269,14 @@ void device_unblock_probing(void)
> */
> static int deferred_probe_initcall(void)
> {
> + if (IS_ENABLED(CONFIG_DEBUG_FS)) {
> + deferred_devices = debugfs_create_file("deferred_devices",
> + 0444, NULL, NULL,
> + &deferred_devs_fops);
> + if (!deferred_devices)
> + return -ENOMEM;
> + }
> +
> driver_deferred_probe_enable = true;
> driver_deferred_probe_trigger();
> /* Sort as many dependencies as possible before exiting initcalls */
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [RFC PATCH v2] driver core: add a debugfs entry to show deferred devices
From: Andy Shevchenko @ 2018-06-19 19:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHp75Vcn39N9rZ0UO3szGrODVLxek4X746uWs+RPXwy4i0s1Ug@mail.gmail.com>
On Tue, Jun 19, 2018 at 10:53 PM, Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
> On Tue, Jun 19, 2018 at 9:33 PM, Javier Martinez Canillas
> <javierm@redhat.com> wrote:
>> For debugging purposes it may be useful to know what are the devices whose
>> probe function was deferred. Add a debugfs entry showing that information.
>> +static int deferred_devs_open(struct inode *inode, struct file *file)
>> +{
>> + return single_open(file, deferred_devs_show, inode->i_private);
>> +}
>> +
>> +static const struct file_operations deferred_devs_fops = {
>> + .owner = THIS_MODULE,
>> + .open = deferred_devs_open,
>> + .read = seq_read,
>> + .llseek = seq_lseek,
>> + .release = single_release,
>> +};
>
> Isn't this DEFINE_SHOW_ATTRIBUTE() ?
Besides that, you are summoning Greg's dark side :-)
See below.
>> + if (IS_ENABLED(CONFIG_DEBUG_FS)) {
>> + deferred_devices = debugfs_create_file("deferred_devices",
>> + 0444, NULL, NULL,
>> + &deferred_devs_fops);
>> + if (!deferred_devices)
>> + return -ENOMEM;
This must not prevent the execution. So, the check introduces actually
a regression.
>> + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v2] arm: msm: Add MSM IOMMU support.
From: Stepan Moskovchenko @ 2018-06-19 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20100807135644.GA7318@n2100.arm.linux.org.uk>
Russell,
Tomorrow I will fix the style / iomem / other issues tomorrow and clean up
the failure paths. I have some questions for you, inline.
>> + iommu_drvdata = dev_get_drvdata(ctx_drvdata->pdev->dev.parent);
>
> Please explain what's going on here with parent devices. What device is
> pdev referring to, and what is pdev->dev.parent ? It seems quite dodgy
> to just expect a certain device relationship without checking that the
> device is what is expected (eg, it's non-NULL, it's of the right bus type,
> and it appears to be suitably named) before dereferencing its driver data.
I could see why this seems confusing. pdev->dev.parent is the IOMMU
context's parent device. There is a device hierarchy here. Each IOMMU
device has multiple IOMMU *context* devices as children. These are
physical, actual translation contexts, with their own distinct sets of
registers. The parent device (the IOMMU) also has a number of "global"
registers that are shared among the translation contexts. It is
impractical to lump the global register space and the context bank
registers into one device because the translation contexts are effectively
their own IOMMUs that can be separately managed. Additionally, the number
of translation contexts varies among IOMMUs in the system. So, in this
particular case, the driver needs to know the ioremapped address of the
IOMMU, so it references the driverdata of the parent device (the IOMMU
itself) to get it. There will never be a context "by itself", ie, a
context's parent will always be an IOMMU device, so the operation of
referencing the parent's data will always be safe. But I can put in some
sanity checks for the pointers if you wish.
>> +static void msm_iommu_domain_destroy(struct iommu_domain *domain)
>> +{
>> + struct msm_priv *priv = (struct msm_priv *) domain->priv;
>
> struct msm_priv *priv = domain->priv;
>
> Should this be outside msm_iommu_lock?
domain->priv should always be unchanged if the domain is still "valid".
The contents of domain->priv may change, but domain->priv does not get
reassigned (until being set to null right as domain is being freed), so I
put this outside the spinlock. Arguably, you could have a problem if a
function is trying to use the domain *as it's being freed*, but then
bigger problems will arise. I will make the change, though.
>> + spin_unlock_irqrestore(&msm_iommu_lock, flags);
>> + return;
>> +fail_inval:
>> + spin_unlock_irqrestore(&msm_iommu_lock, flags);
>> + return;
>
> Does this need to be repeated?
I had initially operated under the assumption that unmap() could return a
failure code. I will clean this up.
>> +#ifndef CONFIG_IOMMU_PGTABLES_L2
>
> I think you mean:
> #ifndef CONFIG_IOMMU_PGTABLES_L1
>
> because as I've said to you several times now, flush_cache_all() is about
> flushing data out of the L1 cache only. It does NOT affect L2 cache.
I do mean to flush the L2 cache here (ie, flush the data from whatever
cache it may be in, all the way to RAM). I believed that
v7_flush_cache_all() (and hence, flush_cache_all() as was suggested by you
as a replacement) would flush the L1 and L2. The comment in cache-v7.S
suggests that the function will "Flush the entire cache system." (line 81)
which sounds like L2 ought to be included (and the observed behavior seems
to agree). I just need the pagetable in RAM to reflect the latest changes
made by the driver, so that the IOMMU can get to it if it hasn't been
configured to access the L2 cache on its own. Could you please suggest a
correct way to flush the L2 cache?
>> +static int msm_iommu_unmap(struct iommu_domain *domain, unsigned long
>> va,
>> + int gfp_order)
>
> What does 'gfp_order' have to do with get_free_pages in this function?
> Wouldn't just 'order' be more appropriate?
I called it 'gfp_order' because that is how linux/iommu.h names that
parameter in the IOMMU API. I guess 'order' *is* more appropriate... I'll
fix it.
>> + /* Upper 20 bits from PAR, lower 12 from VA */
>> + spin_unlock_irqrestore(&msm_iommu_lock, flags);
>> + return (par & 0xFFFFF000) | (va & 0x00000FFF);
>> +fail_nodev:
>> + spin_unlock_irqrestore(&msm_iommu_lock, flags);
>> + return -ENODEV;
>
> Hmm, returning -ve numbers and addresses... how do you tell the difference
> between the two in the calling function?
That is a good question. I am not sure how to handle the error conditions
in this case. My first idea was to just return 0 for all iova-to-phys
faults, but 0 too is a legitimate address (although kind of a dodgy one).
But it may be better to return 0 for the error case. Also, the translation
hardware will not generate a fault interrupt if it's doing a translation
at the request of the CPU (as opposed to when it's being addressed by a
client) but I can manually ask the IOMMU to generate a translation fault
interrupt if iova_to_phys results in a fault (at least we'll know
something is wrong). I am not sure which approach is the best, but am
leaning towards just returning 0 on errors. What do you think is best?
> I'm also sure you can do better with these exit paths in a similar way to
> what I've illustrated above.
Yup, I'll fix it. I will try to post a revised patch tomorrow, after I get
some sleep in me (I guess it will be the evening where you are).
Thanks
Steve
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Query: Patches break with Microsoft exchange server.
From: viresh kumar @ 2018-06-19 20:23 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
Mail server in ST has recently changed and now we have Microsoft
exchange server. We are using thunderbird as mail client.
What we observed with this server is that patch are broken now while
sending as well as receiving. Tabs are replaced by spaces and may
be some other too which we haven't observed.
Has anybody found a solution to this kind of issues? Are there any
workarounds possible?
viresh
ST Microelectronics.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Query: Patches break with Microsoft exchange server.
From: Justin P. Mattock @ 2018-06-19 20:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4C5F9B25.8080401@st.com>
On 08/08/2010 11:07 PM, viresh kumar wrote:
> Hello,
>
> Mail server in ST has recently changed and now we have Microsoft
> exchange server. We are using thunderbird as mail client.
> What we observed with this server is that patch are broken now while
> sending as well as receiving. Tabs are replaced by spaces and may
> be some other too which we haven't observed.
>
> Has anybody found a solution to this kind of issues? Are there any
> workarounds possible?
>
> viresh
> ST Microelectronics.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
still trying to figure this out with thunderbird.. but did notice in
Documentation/email-clients.txt and SubmittingPatches
there's info about that(just haven't gotten around to reading use git
send-email for patches)
hope this helps.
Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox