* [PATCH] ARM: dts: imx7d-sdb: Remove duplicate regulator-can2-3v3
From: Shawn Guo @ 2018-06-19 2:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <abacbb7485b0c9b908eae8ae87be9d8e0eab87b3.1529327283.git.leonard.crestez@nxp.com>
On Mon, Jun 18, 2018 at 04:11:09PM +0300, Leonard Crestez wrote:
> Two different regulators are defined with the same name and label but
> distinct properties.
>
> The first definition was added with the first board dts and the second
> was added when upstream added flexcan support.
>
> Looking at schematics it is indeed gpio2 14 connected to the STB pin of
> the CAN transceiver so remove the first definition.
>
> The second definition entirely overrides the first so this already
> worked and this patch results in no DTB change, just a cleanup.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH] arm64/mm: Introduce a variable to hold base address of linear region
From: Jin, Yanjiang @ 2018-06-19 3:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <92ff5220-f863-4edc-bc9f-bd802d2efa9c@arm.com>
> -----Original Message-----
> From: kexec [mailto:kexec-bounces at lists.infradead.org] On Behalf Of James
> Morse
> Sent: 2018?6?15? 0:17
> To: Bhupesh Sharma <bhsharma@redhat.com>
> Cc: Mark Rutland <mark.rutland@arm.com>; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>; Catalin Marinas <catalin.marinas@arm.com>;
> Kexec Mailing List <kexec@lists.infradead.org>; Will Deacon
> <will.deacon@arm.com>; AKASHI Takahiro <takahiro.akashi@linaro.org>;
> Bhupesh SHARMA <bhupesh.linux@gmail.com>; linux-arm-kernel <linux-arm-
> kernel at lists.infradead.org>
> Subject: Re: [PATCH] arm64/mm: Introduce a variable to hold base address of
> linear region
>
> Hi Bhupesh,
>
> On 14/06/18 08:53, Bhupesh Sharma wrote:
> > On Wed, Jun 13, 2018 at 3:59 PM, James Morse <james.morse@arm.com>
> wrote:
> >> On 13/06/18 06:16, Bhupesh Sharma wrote:
> >>> On Tue, Jun 12, 2018 at 3:42 PM, James Morse <james.morse@arm.com>
> wrote:
> >>>> If I've followed this properly: the problem is that to generate the
> >>>> ELF headers in the post-kdump vmcore, at kdump-load-time
> >>>> kexec-tools has to guess the virtual addresses of the 'System RAM' regions
> it can see in /proc/iomem.
> >>>>
> >>>> The problem you are hitting is an invisible hole at the beginning
> >>>> of RAM, meaning user-space's guess_phys_to_virt() is off by the size of this
> hole.
> >>>>
> >>>> Isn't KASLR a special case for this? You must have to correct for
> >>>> that after kdump has happened, based on an elf-note in the vmcore. Can't
> we always do this?
> >>>
> >>> No, I hit this issue both for the KASLR and non-KASLR boot cases.
> >>
> >> Because in both cases there is a hole at the beginning of the
> >> linear-map. KASLR is a special-case of this as the kernel adds a
> >> variable sized hole to do the randomization.
> >>
> >> Surely treating this as one case makes your user-space code simpler.
> >
> > Ok.
> >
> >>> Fixing this in kernel space seems better to me as the definition of
> >>
> >> Is there a kernel bug? Changing the definitions of internal kernel
> >> variables for the benefit of code digging in /proc/kcore|/dev/mem isn't going
> to fly.
> >
> > Indeed, I am not advocating to change the kernel space code just to
> > suit the user-space tools. However in this particular case the
> > 'memstart_addr' and PHY_OFFSET value are computed as 0 which IMO
>
> (What is PHY_OFFSET? I assume you mean PHYS_OFFSET, which is the same as
> memstart_addr ... why do you quote them together?)
>
>
> > is
> > not the real representation of the start of System RAM as the 1st
> > memory block available in Linux starts from 2MB [as confirmed by the
> > 'memblock_start_of_DRAM()' value of 0x200000] and indicated by
> > '/proc/iomem':
> >
> > # head -1 /proc/iomem
> > 00200000-0021ffff : reserved
>
> You have assumptions about what memstart_addr is based on its name. Names
> of kernel variables get further from their actual use over time.
>
> The purpose of this variable isn't to store where a hypothetical-lowest-page of
> memory would be in the linear map. The kernel doesn't have a handy variable for
> this, because on-one needs to know.
>
>
> > I think reading the kernel code and finding 'memstart_addr' and
> > PHY_OFFSET as 0, one gets the notion
>
> notion -> assumption based on the name
>
> It's just a name. Anyone reading this should grep for how the value is used.
> It's added/subtracted from addresses as part of phys_to_virt()/virt_to_phs(). It
> must be some kind of offset. What does it mean on its own? Probably nothing.
>
>
> > that the base of System RAM starts from 0, which is incorrect in the
> > above case as it starts from 2MB as the 1st block is of the type
> > EfiReservedMemType
>
> What will they assume if the value is negative?
>
> [...]
>
> > So, either we should have a uniform way of representing the virtual
> > base of the linear range
>
> What needs to know this? RAM will be somewhere between PAGE_OFFSET and
> the top of the address space. Anyone who wants to know where has a specific
> page in mind, phys_to_virt() or page_address() tell them where their page is.
>
>
> > or we should rather look at removing the PAGE_OFFSET usage from the
> > kernel (or atleast the confusing comment from 'memory.h')
>
> This?:
> | PAGE_OFFSET - the virtual address of the start of the linear map
>
> Nothing here says its the virtual address of any particular physical page. Its the
> start of the region of VA space that holds the 1:1 mapping of RAM. Its value is
> generated at compile time, we have no idea where RAM will be until we boot,
> how could this be the address of any particular page?
>
>
> > BTW adding 'p2v_offset' as an elf-note seems like a good idea. If this
> > seems suitable, I can try and spin patch(es) using this approach (both
> > for the kernel and user-space tools).
>
> You seem to be using this for user-space phys_to_virt() based on values found in
> /proc/iomem. This should give you what you want, and isolate your user-space
> from the kernel's unexpected naming of variables.
I don't know could I simplify this problem?
Let's ignore what memstart_addr represents here, we just want to implement phys_to_virt() in an userspace applications(kexec-tools or others).
ARM64 Kernel has a below definition:
#define __phys_to_virt(x) ((unsigned long)((x) - PHYS_OFFSET) | PAGE_OFFSET)
So userspace app must know PHYS_OFFSET(equal to memstart_addr now). Seems this is very simple, but memstart_addr has gone through several operations in arm64_memblock_init() depends on different Kernel configurations, so userspace app needs to know many additional definitions as following:
memblock_start_of_DRAM(), (ifdef CONFIG_SPARSEMEM_VMEMMAP), ARM64_MEMSTART_SHIFT, SECTION_SIZE_BITS, PAGE_OFFSET, memblock_end_of_DRAM(),
IS_ENABLED(CONFIG_RANDOMIZE_BASE), memstart_offset_seed.
It is hard to know all above in kexec-tools now. Originally I planned to read memstart_addr's value from "/dev/mem", but someone thought not all Kernels enable "/dev/mem", we'd better find a more generic approach. So we want to get some suggestions from ARM kernel community.
Can we export this variable in Kernel side through sysconf() or other similar methods? Or someone can provide an effect way to get memstart_addr's value?
Thanks,
Yanjiang
>
> I'd suggest a 64bit offset that is added to a physical address to get where in the
> linear map this page would be, if its mapped.
>
>
> Thanks,
>
> James
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
This email is intended only for the named addressee. It may contain information that is confidential/private, legally privileged, or copyright-protected, and you should handle it accordingly. If you are not the intended recipient, you do not have legal rights to retain, copy, or distribute this email or its contents, and should promptly delete the email and all electronic copies in your system; do not retain copies in any media. If you have received this email in error, please notify the sender promptly. Thank you.
^ permalink raw reply
* [PATCH] arm64: dts: freescale: Update to use SPDX identifiers
From: Shawn Guo @ 2018-06-19 3:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528828122-9276-1-git-send-email-leoyang.li@nxp.com>
On Tue, Jun 12, 2018 at 01:28:42PM -0500, Li Yang wrote:
> Replace license text with corresponding SPDX identifiers and update the
> format of existing SPDX identifiers to follow the new guideline
> Documentation/process/license-rules.rst.
>
> Note that some of the files mentioned X11 license previously but the
> license text actually matches MIT license.
>
> Signed-off-by: Li Yang <leoyang.li@nxp.com>
Applied, thanks.
^ permalink raw reply
* [PATCH 1/2] arm64: dts: uniphier: add headphone detect gpio for LD20 global board
From: Katsuhiro Suzuki @ 2018-06-19 4:11 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds GPIO for headphone detection on LD20 global board.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
index 6a074a20c924..38b75998e2dd 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
@@ -60,6 +60,7 @@
&i2s_port4
&spdif_port0
&comp_spdif_port0>;
+ hp-det-gpio = <&gpio UNIPHIER_GPIO_PORT(15, 0) GPIO_ACTIVE_LOW>;
};
spdif-out {
--
2.17.1
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: uniphier: add headphone detect gpio for LD11 global board
From: Katsuhiro Suzuki @ 2018-06-19 4:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619041153.6668-1-suzuki.katsuhiro@socionext.com>
This patch adds GPIO for headphone detection on LD11 global board.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
index 798882cccbd6..e5bda40b3ec6 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
@@ -60,6 +60,7 @@
&i2s_port4
&spdif_port0
&comp_spdif_port0>;
+ hp-det-gpio = <&gpio UNIPHIER_GPIO_PORT(15, 0) GPIO_ACTIVE_LOW>;
};
spdif-out {
--
2.17.1
^ permalink raw reply related
* [PATCH] arm64: dts: uniphier: fix widget name of headphone for LD11/LD20 boards
From: Katsuhiro Suzuki @ 2018-06-19 4:12 UTC (permalink / raw)
To: linux-arm-kernel
This patch fixes wrong name of headphone widget for receiving events
of insert/remove headphone plug from simple-card or audio-graph-card.
If we use wrong widget name then we get warning messages such as
"asoc-audio-graph-card sound: ASoC: DAPM unknown pin Headphones"
when the plug is inserted or removed from headphone jack.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
---
arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts | 2 +-
arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
index e5bda40b3ec6..7cc3f6dd93d9 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld11-global.dts
@@ -54,7 +54,7 @@
sound {
compatible = "audio-graph-card";
label = "UniPhier LD11";
- widgets = "Headphone", "Headphone Jack";
+ widgets = "Headphone", "Headphones";
dais = <&i2s_port2
&i2s_port3
&i2s_port4
diff --git a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
index 38b75998e2dd..575be4ab0072 100644
--- a/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
+++ b/arch/arm64/boot/dts/socionext/uniphier-ld20-global.dts
@@ -54,7 +54,7 @@
sound {
compatible = "audio-graph-card";
label = "UniPhier LD20";
- widgets = "Headphone", "Headphone Jack";
+ widgets = "Headphone", "Headphones";
dais = <&i2s_port2
&i2s_port3
&i2s_port4
--
2.17.1
^ permalink raw reply related
* [PATCH v2] dmaengine: ti: omap-dma: Fix OMAP1510 incorrect residue_granularity
From: Vinod @ 2018-06-19 4:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180605165957.29616-1-jmkrzyszt@gmail.com>
On 05-06-18, 18:59, Janusz Krzysztofik wrote:
> Commit 0198d7bb8a0c ("ASoC: omap-mcbsp: Convert to use the sdma-pcm
> instead of omap-pcm") resulted in broken audio playback on OMAP1510
> (discovered on Amstrad Delta).
>
> When running on OMAP1510, omap-pcm used to obtain DMA offset from
> snd_dmaengine_pcm_pointer_no_residue() based on DMA interrupt triggered
> software calculations instead of snd_dmaengine_pcm_pointer() which
> depended on residue value calculated from omap_dma_get_src_pos().
> Similar code path is still available in now used
> sound/soc/soc-generic-dmaengine-pcm.c but it is not triggered.
>
> It was verified already before that omap_get_dma_src_pos() from
> arch/arm/plat-omap/dma.c didn't work correctly for OMAP1510 - see
> commit 1bdd7419910c ("ASoC: OMAP: fix OMAP1510 broken PCM pointer
> callback") for details. Apparently the same applies to its successor,
> omap_dma_get_src_pos() from drivers/dma/ti/omap-dma.c.
>
> On the other hand, snd_dmaengine_pcm_pointer_no_residue() is described
> as depreciated and discouraged for use in new drivers because of its
> unreliable accuracy. However, it seems the only working option for
> OPAM1510 now, as long as a software calculated residue is not
> implemented as OMAP1510 fallback in omap-dma.
>
> Using snd_dmaengine_pcm_pointer_no_residue() code path instead of
> snd_dmaengine_pcm_pointer() in sound/soc/soc-generic-dmaengine-pcm.c
> can be triggered in two ways:
> - by passing pcm->flags |= SND_DMAENGINE_PCM_FLAG_NO_RESIDUE from
> sound/soc/omap/sdma-pcm.c,
> - by passing dma_caps.residue_granularity =
> DMA_RESIDUE_GRANULARITY_DESCRIPTOR from DMA engine.
>
> Let's do the latter.
>
> Created and tested against next-20180531 tag from linux-next tree.
This is not useful for log.
I have stripped this and applied
--
~Vinod
^ permalink raw reply
* [PATCH] MAINTAINERS: Update email-id of Sinan Kaya
From: Vinod @ 2018-06-19 4:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1528983482-31028-1-git-send-email-okaya@codeaurora.org>
On 14-06-18, 09:37, Sinan Kaya wrote:
> I'm no longer with QCOM. I am still interested in maintaining or reviewing
> PCI/DMA engine patches. Update email-id to an active one.
Applied, thanks
--
~Vinod
^ permalink raw reply
* [PATCH] serial: mps2-uart: Initialize early console
From: Guenter Roeck @ 2018-06-19 4:54 UTC (permalink / raw)
To: linux-arm-kernel
The early console code for mps2-uart assumes that the serial hardware is
enabled for transmit when the system boots. However, this is not the case
after reset. This results in a hang in mps2_early_putchar() if the serial
transmitter is not enabled by a boot loader or ROM monitor.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
drivers/tty/serial/mps2-uart.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/tty/serial/mps2-uart.c b/drivers/tty/serial/mps2-uart.c
index 9f8f63719126..0743a0551ce1 100644
--- a/drivers/tty/serial/mps2-uart.c
+++ b/drivers/tty/serial/mps2-uart.c
@@ -448,6 +448,14 @@ static struct console mps2_uart_console = {
#define MPS2_SERIAL_CONSOLE (&mps2_uart_console)
+static void mps2_early_init(struct uart_port *port)
+{
+ u8 control = readb(port->membase + UARTn_CTRL);
+
+ control |= UARTn_CTRL_TX_ENABLE;
+ writeb(control, port->membase + UARTn_CTRL);
+}
+
static void mps2_early_putchar(struct uart_port *port, int ch)
{
while (readb(port->membase + UARTn_STATE) & UARTn_STATE_TX_FULL)
@@ -469,6 +477,7 @@ static int __init mps2_early_console_setup(struct earlycon_device *device,
if (!device->port.membase)
return -ENODEV;
+ mps2_early_init(&device->port);
device->con->write = mps2_early_write;
return 0;
--
2.7.4
^ permalink raw reply related
* [RFC PATCH] ARM: Use logical or instead of addition for badr address calculation
From: Guenter Roeck @ 2018-06-19 5:07 UTC (permalink / raw)
To: linux-arm-kernel
Modern assemblers may take the ISA into account when resolving local
symbols. This can result in bad address calculations when using badr
in the wrong location since the offset + 1 may be added twice, resulting
in an even address target for THUMB instructions. This in turn results
in an exception at (destination address + 2).
Unhandled exception: IPSR = 00000006 LR = fffffff1
CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00026-gf773e5bdf0c9 #15
Hardware name: MPS2 (Device Tree Support)
PC is at ret_fast_syscall+0x2/0x58
LR is at tty_ioctl+0x2a5/0x528
pc : [<21009002>] lr : [<210d1535>] psr: 4000000b
sp : 21825fa8 ip : 0000001c fp : 21a95892
r10: 00000000 r9 : 21824000 r8 : 210091c0
r7 : 00000036 r6 : 21ae1ee0 r5 : 00000000 r4 : 21ae1f3c
r3 : 00000000 r2 : 3d9adc25 r1 : 00000000 r0 : 00000000
xPSR: 4000000b
CPU: 0 PID: 1 Comm: init Not tainted 4.18.0-rc1-00026-gf773e5bdf0c9 #15
Hardware name: MPS2 (Device Tree Support)
[<2100bd8d>] (unwind_backtrace) from [<2100b13b>] (show_stack+0xb/0xc)
[<2100b13b>] (show_stack) from [<2100b87b>] (__invalid_entry+0x4b/0x4c)
Fix the problem by using a logical or instead of an addition. This is
less efficient but guaranteed to work.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
---
RFC: I don't really like this, but my ARM assembler knowledge is quite
limited. Just dropping the "+ 1" from badr doesn't work because some
other code needs it (the image hangs completely if I try that).
Ultimately I don't even know if the invoke_syscall macro should just
have used adr instead of badr (but then how did this ever work ?).
Seen with various toolchains based on gcc 7.x and binutils 2.30 when
building and testing MPS2 images.
arch/arm/include/asm/assembler.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 0cd4dccbae78..24c87ff2060f 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -195,7 +195,8 @@
.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
+ adr\c \rd, \sym
+ orr \rd, #1
#else
adr\c \rd, \sym
#endif
--
2.7.4
^ permalink raw reply related
* [PATCH 2/5] net: emaclite: Balance braces in else statement
From: Radhey Shyam Pandey @ 2018-06-19 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <644296b273a76469baf641dd712c7a5451cd34fe.camel@perches.com>
> -----Original Message-----
> From: Joe Perches [mailto:joe at perches.com]
> Sent: Monday, June 18, 2018 9:33 PM
> To: Radhey Shyam Pandey <radheys@xilinx.com>; davem at davemloft.net;
> andrew at lunn.ch; Michal Simek <michals@xilinx.com>
> Cc: netdev at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org
> Subject: Re: [PATCH 2/5] net: emaclite: Balance braces in else statement
>
> On Mon, 2018-06-18 at 17:20 +0530, Radhey Shyam Pandey wrote:
> > Remove else as it is not required with if doing a return.
> > Fixes below checkpatch warning.
>
> > WARNING: else is not generally useful after a break or return
>
> checkpatch is stupid and doesn't understand code flow.
> Always try to improve code flow instead of merely
> following brainless instructions from a script.
>
> So:
>
> > diff --git a/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> b/drivers/net/ethernet/xilinx/xilinx_emaclite.c
> []
> > @@ -569,13 +569,11 @@ static void xemaclite_tx_handler(struct net_device
> *dev)
> > (u8 *) lp->deferred_skb->data,
> > lp->deferred_skb->len) != 0)
> > return;
> > - else {
> > - dev->stats.tx_bytes += lp->deferred_skb->len;
> > - dev_kfree_skb_irq(lp->deferred_skb);
> > - lp->deferred_skb = NULL;
> > - netif_trans_update(dev); /* prevent tx timeout */
> > - netif_wake_queue(dev);
> > - }
> > + dev->stats.tx_bytes += lp->deferred_skb->len;
> > + dev_kfree_skb_irq(lp->deferred_skb);
> > + lp->deferred_skb = NULL;
> > + netif_trans_update(dev); /* prevent tx timeout */
> > + netif_wake_queue(dev);
> > }
> > }
>
> If you really want to redo this function, perhaps something like:
Thanks for the review. Yes, In v2 I will refactor the code to have
failure path return early.
>
> static void xemaclite_tx_handler(struct net_device *dev)
> {
> struct net_local *lp = netdev_priv(dev);
>
> dev->stats.tx_packets++;
>
> if (!lp->deferred_skb)
> return;
>
> if (xemaclite_send_data(lp, (u8 *)lp->deferred_skb->data,
> lp->deferred_skb->len))
> return;
>
> dev->stats.tx_bytes += lp->deferred_skb->len;
> dev_kfree_skb_irq(lp->deferred_skb);
> lp->deferred_skb = NULL;
> netif_trans_update(dev); /* prevent tx timeout */
> netif_wake_queue(dev);
> }
>
> > @@ -1052,13 +1050,13 @@ static bool get_bool(struct platform_device
> *ofdev, const char *s)
> > {
> > u32 *p = (u32 *)of_get_property(ofdev->dev.of_node, s, NULL);
> >
> > - if (p) {
> > + if (p)
> > return (bool)*p;
> > - } else {
> > - dev_warn(&ofdev->dev, "Parameter %s not found,"
> > +
> > + dev_warn(&ofdev->dev, "Parameter %s not found,"
> > "defaulting to false\n", s);
> > - return false;
> > - }
> > +
> > + return false;
> > }
>
> And this function has backward logic as the failure paths
> are the ones that should return early or use a goto.
>
> Perhaps something like:
Yes, will change it.
>
> static bool get_bool(struct platform_device *ofdev, const char *s)
> {
> u32 *p = (u32 *)of_get_property(ofdev->dev.of_node, s, NULL);
>
> if (!p) {
> dev_warn(&ofdev->dev,
> "Parameter '%s' not found, defaulting to false\n", s);
> return false;
> }
>
> return *p;
> }
^ permalink raw reply
* [PATCH] crypto: arm/speck - fix building in Thumb2 mode
From: Ard Biesheuvel @ 2018-06-19 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618223323.130072-1-ebiggers@google.com>
On 19 June 2018 at 00:33, Eric Biggers <ebiggers@google.com> wrote:
> Building the kernel with CONFIG_THUMB2_KERNEL=y and
> CONFIG_CRYPTO_SPECK_NEON set fails with the following errors:
>
> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>
> arch/arm/crypto/speck-neon-core.S:419: Error: r13 not allowed here -- `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:423: Error: r13 not allowed here -- `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:427: Error: r13 not allowed here -- `bic sp,#0xf'
> arch/arm/crypto/speck-neon-core.S:431: Error: r13 not allowed here -- `bic sp,#0xf'
>
> The problem is that the 'bic' instruction can't operate on the 'sp'
> register in Thumb2 mode. Fix it by using a temporary register. This
> isn't in the main loop, so the performance difference is negligible.
> This also matches what aes-neonbs-core.S does.
>
> Reported-by: Stefan Agner <stefan@agner.ch>
> Fixes: ede9622162fa ("crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS")
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
> arch/arm/crypto/speck-neon-core.S | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/crypto/speck-neon-core.S b/arch/arm/crypto/speck-neon-core.S
> index 3c1e203e53b9..57caa742016e 100644
> --- a/arch/arm/crypto/speck-neon-core.S
> +++ b/arch/arm/crypto/speck-neon-core.S
> @@ -272,9 +272,11 @@
> * Allocate stack space to store 128 bytes worth of tweaks. For
> * performance, this space is aligned to a 16-byte boundary so that we
> * can use the load/store instructions that declare 16-byte alignment.
> + * For Thumb2 compatibility, don't do the 'bic' directly on 'sp'.
> */
> - sub sp, #128
> - bic sp, #0xf
> + sub r12, sp, #128
> + bic r12, #0xf
> + mov sp, r12
>
> .if \n == 64
> // Load first tweak
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
^ permalink raw reply
* [PATCH v2] ARM: dts: imx6sx: fix irq for pcie bridge
From: Shawn Guo @ 2018-06-19 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180615074129.16931-1-o.rempel@pengutronix.de>
On Fri, Jun 15, 2018 at 09:41:29AM +0200, Oleksij Rempel wrote:
> Use the correct IRQ line for the MSI controller in the PCIe host
> controller. Apparently a different IRQ line is used compared to other
> i.MX6 variants. Without this change MSI IRQs aren't properly propagated
> to the upstream interrupt controller.
>
> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Added the following Fixes tag and applied as a fix.
Fixes: b1d17f68e5c5 ("ARM: dts: imx: add initial imx6sx device tree source")
Shawn
^ permalink raw reply
* [PATCH v2 0/4] arm64: kexec, kdump: fix boot failures on acpi-only system
From: AKASHI Takahiro @ 2018-06-19 6:44 UTC (permalink / raw)
To: linux-arm-kernel
This patch series is a set of bug fixes to address kexec/kdump
failures which are sometimes observed on ACPI-only system and reported
in LAK-ML before.
In short, the phenomena are:
1. kexec'ed kernel can fail to boot because some ACPI table is corrupted
by a new kernel (or other data) being loaded into System RAM. Currently
kexec may possibly allocate space ignoring such "reserved" regions.
We will see no messages after "Bye!"
2. crash dump (kdump) kernel can fail to boot and get into panic due to
an alignment fault when accessing ACPI tables. This can happen because
those tables are not always properly aligned while they are mapped
non-cacheable (ioremap'ed) as they are not recognized as part of System
RAM under the current implementation.
After discussing several possibilities to address those issues,
the agreed approach, in my understanding, is
* to add resource entries for every "reserved", i.e. memblock_reserve(),
regions to /proc/iomem.
(NOMAP regions, also marked as "reserved," remains at top-level for
backward compatibility. User-space can tell the difference between
reserved-system-ram and reserved-address-space.)
* For case (1), user space (kexec-tools) should rule out such regions
in searching for free space for loaded data.
* For case (2), the kernel should access ACPI tables by mapping
them with appropriate memory attributes described in UEFI memory map.
(This means that it doesn't require any changes in /proc/iomem, and
hence user space.)
Please find past discussions about /proc/iomem in [1].
--- more words from James ---
Our attempts to fix this just in the kernel reached a dead end, because Kdump
needs to include reserved-system-ram, whereas kexec has to avoid it. User-space
needs to be able to tell reserved-system-ram and reserved-address-space apart.
Hence we need to expose that information, and pick it up in user-space.
Patched-kernel and unpatch-user-space will work the same way it does today, as
the additional reserved regions are ignored by user-space.
Unpatched-kernel and patched-user-space will also work the same way it does
today as the additional reserved regions are missing.
--->8---
Patch#1 addresses kexec case, for which you are also required to update
user space. See necessary patches in [2]. If you want to review Patch#1,
please also take a look at and review [2].
Patch#2 to #4 addresses kdump case. This is a revised version after
Ard's comments.[3]
Changes in v2 (2018, June 19, 2018)
* re-organise v1's patch#2 and #3 into v2's #2, #3 and #4
not to break bisect
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/565980.html
[2] https://git.linaro.org/people/takahiro.akashi/kexec-tools.git arm64/resv_mem
[3] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/573655.html
AKASHI Takahiro (3):
efi/arm: map UEFI memory map even w/o runtime services enabled
efi/arm: map UEFI memory map earlier on boot
arm64: acpi: fix alignment fault in accessing ACPI
James Morse (1):
arm64: export memblock_reserve()d regions via /proc/iomem
arch/arm64/include/asm/acpi.h | 23 ++++++++++++------
arch/arm64/kernel/acpi.c | 11 +++------
arch/arm64/kernel/setup.c | 38 ++++++++++++++++++++++++++++++
drivers/firmware/efi/arm-runtime.c | 27 ++++++++++-----------
init/main.c | 3 +++
5 files changed, 72 insertions(+), 30 deletions(-)
--
2.17.0
^ permalink raw reply
* [PATCH v2 1/4] arm64: export memblock_reserve()d regions via /proc/iomem
From: AKASHI Takahiro @ 2018-06-19 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619064424.6642-1-takahiro.akashi@linaro.org>
From: James Morse <james.morse@arm.com>
There has been some confusion around what is necessary to prevent kexec
overwriting important memory regions. memblock: reserve, or nomap?
Only memblock nomap regions are reported via /proc/iomem, kexec's
user-space doesn't know about memblock_reserve()d regions.
Until commit f56ab9a5b73ca ("efi/arm: Don't mark ACPI reclaim memory
as MEMBLOCK_NOMAP") the ACPI tables were nomap, now they are reserved
and thus possible for kexec to overwrite with the new kernel or initrd.
But this was always broken, as the UEFI memory map is also reserved
and not marked as nomap.
Exporting both nomap and reserved memblock types is a nuisance as
they live in different memblock structures which we can't walk at
the same time.
Take a second walk over memblock.reserved and add new 'reserved'
subnodes for the memblock_reserved() regions that aren't already
described by the existing code. (e.g. Kernel Code)
We use reserve_region_with_split() to find the gaps in existing named
regions. This handles the gap between 'kernel code' and 'kernel data'
which is memblock_reserve()d, but already partially described by
request_standard_resources(). e.g.:
| 80000000-dfffffff : System RAM
| 80080000-80ffffff : Kernel code
| 81000000-8158ffff : reserved
| 81590000-8237efff : Kernel data
| a0000000-dfffffff : Crash kernel
| e00f0000-f949ffff : System RAM
reserve_region_with_split needs kzalloc() which isn't available when
request_standard_resources() is called, use an initcall.
Reported-by: Bhupesh Sharma <bhsharma@redhat.com>
Reported-by: Tyler Baicar <tbaicar@codeaurora.org>
Suggested-by: Akashi Takahiro <takahiro.akashi@linaro.org>
Signed-off-by: James Morse <james.morse@arm.com>
Fixes: d28f6df1305a ("arm64/kexec: Add core kexec support")
CC: Ard Biesheuvel <ard.biesheuvel@linaro.org>
CC: Mark Rutland <mark.rutland@arm.com>
---
arch/arm64/kernel/setup.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 30ad2f085d1f..5b4fac434c84 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -241,6 +241,44 @@ static void __init request_standard_resources(void)
}
}
+static int __init reserve_memblock_reserved_regions(void)
+{
+ phys_addr_t start, end, roundup_end = 0;
+ struct resource *mem, *res;
+ u64 i;
+
+ for_each_reserved_mem_region(i, &start, &end) {
+ if (end <= roundup_end)
+ continue; /* done already */
+
+ start = __pfn_to_phys(PFN_DOWN(start));
+ end = __pfn_to_phys(PFN_UP(end)) - 1;
+ roundup_end = end;
+
+ res = kzalloc(sizeof(*res), GFP_ATOMIC);
+ if (WARN_ON(!res))
+ return -ENOMEM;
+ res->start = start;
+ res->end = end;
+ res->name = "reserved";
+ res->flags = IORESOURCE_MEM;
+
+ mem = request_resource_conflict(&iomem_resource, res);
+ /*
+ * We expected memblock_reserve() regions to conflict with
+ * memory created by request_standard_resources().
+ */
+ if (WARN_ON_ONCE(!mem))
+ continue;
+ kfree(res);
+
+ reserve_region_with_split(mem, start, end, "reserved");
+ }
+
+ return 0;
+}
+arch_initcall(reserve_memblock_reserved_regions);
+
u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
void __init setup_arch(char **cmdline_p)
--
2.17.0
^ permalink raw reply related
* [PATCH v2 2/4] efi/arm: map UEFI memory map even w/o runtime services enabled
From: AKASHI Takahiro @ 2018-06-19 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619064424.6642-1-takahiro.akashi@linaro.org>
Under the current implementation, UEFI memory map will be mapped and made
available in virtual mappings only if runtime services are enabled.
But in a later patch, we want to use UEFI memory map in acpi_os_ioremap()
to create mappings of ACPI tables using memory attributes described in
UEFI memory map.
So, as a first step, arm_enter_runtime_services() will be modified
so that UEFI memory map will be always accessible.
See a relevant commit:
arm64: acpi: fix alignment fault in accessing ACPI tables
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
drivers/firmware/efi/arm-runtime.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 5889cbea60b8..30ac5c82051e 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -115,6 +115,13 @@ static int __init arm_enable_runtime_services(void)
return 0;
}
+ mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
+
+ if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
+ pr_err("Failed to remap EFI memory map\n");
+ return 0;
+ }
+
if (efi_runtime_disabled()) {
pr_info("EFI runtime services will be disabled.\n");
return 0;
@@ -127,13 +134,6 @@ static int __init arm_enable_runtime_services(void)
pr_info("Remapping and enabling EFI services.\n");
- mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
-
- if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
- pr_err("Failed to remap EFI memory map\n");
- return -ENOMEM;
- }
-
if (!efi_virtmap_init()) {
pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n");
return -ENOMEM;
--
2.17.0
^ permalink raw reply related
* [PATCH v2 3/4] efi/arm: map UEFI memory map earlier on boot
From: AKASHI Takahiro @ 2018-06-19 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619064424.6642-1-takahiro.akashi@linaro.org>
Since arm_enter_runtime_services() was modified to always create a virtual
mapping of UEFI memory map in the previous patch, it is now renamed to
efi_enter_virtual_mode() and called earlier before acpi_load_tables()
in acpi_early_init().
This will allow us to use UEFI memory map in acpi_os_ioremap() to create
mappings of ACPI tables using memory attributes described in UEFI memory
map.
See a relevant commit:
arm64: acpi: fix alignment fault in accessing ACPI tables
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
drivers/firmware/efi/arm-runtime.c | 15 ++++++---------
init/main.c | 3 +++
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 30ac5c82051e..566ef0a9edb5 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -106,46 +106,43 @@ static bool __init efi_virtmap_init(void)
* non-early mapping of the UEFI system table and virtual mappings for all
* EFI_MEMORY_RUNTIME regions.
*/
-static int __init arm_enable_runtime_services(void)
+void __init efi_enter_virtual_mode(void)
{
u64 mapsize;
if (!efi_enabled(EFI_BOOT)) {
pr_info("EFI services will not be available.\n");
- return 0;
+ return;
}
mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
pr_err("Failed to remap EFI memory map\n");
- return 0;
+ return;
}
if (efi_runtime_disabled()) {
pr_info("EFI runtime services will be disabled.\n");
- return 0;
+ return;
}
if (efi_enabled(EFI_RUNTIME_SERVICES)) {
pr_info("EFI runtime services access via paravirt.\n");
- return 0;
+ return;
}
pr_info("Remapping and enabling EFI services.\n");
if (!efi_virtmap_init()) {
pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n");
- return -ENOMEM;
+ return;
}
/* Set up runtime services function pointers */
efi_native_runtime_setup();
set_bit(EFI_RUNTIME_SERVICES, &efi.flags);
-
- return 0;
}
-early_initcall(arm_enable_runtime_services);
void efi_virtmap_load(void)
{
diff --git a/init/main.c b/init/main.c
index 3b4ada11ed52..532fc0d02353 100644
--- a/init/main.c
+++ b/init/main.c
@@ -694,6 +694,9 @@ asmlinkage __visible void __init start_kernel(void)
debug_objects_mem_init();
setup_per_cpu_pageset();
numa_policy_init();
+ if (IS_ENABLED(CONFIG_EFI) &&
+ (IS_ENABLED(CONFIG_ARM64) || IS_ENABLED(CONFIG_ARM)))
+ efi_enter_virtual_mode();
acpi_early_init();
if (late_time_init)
late_time_init();
--
2.17.0
^ permalink raw reply related
* [PATCH v2 4/4] arm64: acpi: fix alignment fault in accessing ACPI
From: AKASHI Takahiro @ 2018-06-19 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180619064424.6642-1-takahiro.akashi@linaro.org>
This is a fix against the issue that crash dump kernel may hang up
during booting, which can happen on any ACPI-based system with "ACPI
Reclaim Memory."
(kernel messages after panic kicked off kdump)
(snip...)
Bye!
(snip...)
ACPI: Core revision 20170728
pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
Internal error: Oops: 96000021 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
task: ffff000008d05180 task.stack: ffff000008cc0000
PC is at acpi_ns_lookup+0x25c/0x3c0
LR is at acpi_ds_load1_begin_op+0xa4/0x294
(snip...)
Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
Call trace:
(snip...)
[<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
[<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
[<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
[<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
[<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
[<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
[<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
[<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
[<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
[<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
[<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
[<ffff000008badc20>] acpi_early_init+0x9c/0xd0
[<ffff000008b70d50>] start_kernel+0x3b4/0x43c
Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
---[ end trace c46ed37f9651c58e ]---
Kernel panic - not syncing: Fatal exception
Rebooting in 10 seconds..
(diagnosis)
* This fault is a data abort, alignment fault (ESR=0x96000021)
during reading out ACPI table.
* Initial ACPI tables are normally stored in system ram and marked as
"ACPI Reclaim memory" by the firmware.
* After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim
memory as MEMBLOCK_NOMAP"), those regions are differently handled
as they are "memblock-reserved", without NOMAP bit.
* So they are now excluded from device tree's "usable-memory-range"
which kexec-tools determines based on a current view of /proc/iomem.
* When crash dump kernel boots up, it tries to accesses ACPI tables by
mapping them with ioremap(), not ioremap_cache(), in acpi_os_ioremap()
since they are no longer part of mapped system ram.
* Given that ACPI accessor/helper functions are compiled in without
unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED),
any unaligned access to ACPI tables can cause a fatal panic.
With this patch, acpi_os_ioremap() always honors memory attribute
information provided by the firmware (EFI) and retaining cacheability
allows the kernel safe access to ACPI tables.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Suggested-by: James Morse <james.morse@arm.com>
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by and Tested-by: Bhupesh Sharma <bhsharma@redhat.com>
---
arch/arm64/include/asm/acpi.h | 23 ++++++++++++++++-------
arch/arm64/kernel/acpi.c | 11 +++--------
2 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 0db62a4cbce2..68bc18cb2b85 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -12,10 +12,12 @@
#ifndef _ASM_ACPI_H
#define _ASM_ACPI_H
+#include <linux/efi.h>
#include <linux/memblock.h>
#include <linux/psci.h>
#include <asm/cputype.h>
+#include <asm/io.h>
#include <asm/smp_plat.h>
#include <asm/tlbflush.h>
@@ -29,18 +31,22 @@
/* Basic configuration for ACPI */
#ifdef CONFIG_ACPI
+pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
+
/* ACPI table mapping after acpi_permanent_mmap is set */
static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
{
+ /* For normal memory we already have a cacheable mapping. */
+ if (memblock_is_map_memory(phys))
+ return (void __iomem *)__phys_to_virt(phys);
+
/*
- * EFI's reserve_regions() call adds memory with the WB attribute
- * to memblock via early_init_dt_add_memory_arch().
+ * We should still honor the memory's attribute here because
+ * crash dump kernel possibly excludes some ACPI (reclaim)
+ * regions from memblock list.
*/
- if (!memblock_is_memory(phys))
- return ioremap(phys, size);
-
- return ioremap_cache(phys, size);
+ return __ioremap(phys, size, __acpi_get_mem_attribute(phys));
}
#define acpi_os_ioremap acpi_os_ioremap
@@ -129,7 +135,10 @@ static inline const char *acpi_get_enable_method(int cpu)
* for compatibility.
*/
#define acpi_disable_cmcff 1
-pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
+static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+{
+ return __acpi_get_mem_attribute(addr);
+}
#endif /* CONFIG_ACPI_APEI */
#ifdef CONFIG_ACPI_NUMA
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 7b09487ff8fb..ed46dc188b22 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -18,6 +18,7 @@
#include <linux/acpi.h>
#include <linux/bootmem.h>
#include <linux/cpumask.h>
+#include <linux/efi.h>
#include <linux/efi-bgrt.h>
#include <linux/init.h>
#include <linux/irq.h>
@@ -29,13 +30,9 @@
#include <asm/cputype.h>
#include <asm/cpu_ops.h>
+#include <asm/pgtable.h>
#include <asm/smp_plat.h>
-#ifdef CONFIG_ACPI_APEI
-# include <linux/efi.h>
-# include <asm/pgtable.h>
-#endif
-
int acpi_noirq = 1; /* skip ACPI IRQ initialization */
int acpi_disabled = 1;
EXPORT_SYMBOL(acpi_disabled);
@@ -239,8 +236,7 @@ void __init acpi_boot_table_init(void)
}
}
-#ifdef CONFIG_ACPI_APEI
-pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+pgprot_t __acpi_get_mem_attribute(phys_addr_t addr)
{
/*
* According to "Table 8 Map: EFI memory types to AArch64 memory
@@ -261,4 +257,3 @@ pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
return __pgprot(PROT_NORMAL_NC);
return __pgprot(PROT_DEVICE_nGnRnE);
}
-#endif
--
2.17.0
^ permalink raw reply related
* [PATCH 01/10] ARM: OMAP1: ams-delta: drop GPIO lookup table for serio device
From: Tony Lindgren @ 2018-06-19 6:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180613044152.GB112168@atomide.com>
* Tony Lindgren <tony@atomide.com> [180613 04:44]:
> * Janusz Krzysztofik <jmkrzyszt@gmail.com> [180613 01:18]:
> > On Wednesday, June 13, 2018 12:23:56 AM CEST Dmitry Torokhov wrote:
> > > Hi Janusz,
> > >
> > > On Sat, Jun 09, 2018 at 04:02:15PM +0200, Janusz Krzysztofik wrote:
> > > > GPIO lookup table for ams-delta-serio device was introduced by commit
> > > > 0486738928bf ("ARM: OMAP1: ams-delta: add GPIO lookup tables").
> > > > Unfortunately, a follow up patch "Input: ams_delta_serio: use GPIO
> > > > lookup table" was not accepted by subystem maintainer who requested
> > > > conversion of the driver to a platform driver, replacepemnt of IRQ GPIO
> > > > pin with IRQ resource, replacement of GPIO pin providing keyboard power
> > > > with a regulator and removal of remaining GPIO pins from the driver as
> > > > not handled by it.
> > > >
> > > > Let's start with removal of no the longer needed GPIO lookup table from
> > > > the board init file.
> > > >
> > > > Series created and tested on top of next-20180608 tag from linux-next
> > > > tree.
> > >
> > > This all is really nice (modulo a couple of questions), thank you for
> > > implementing this. How do you want to merge this? Through OMAP tree or
> > > input?
> >
> > Hi Dmitry,
> >
> > If Tony doesn't mind, I would prefer it merged through OMAP tree as I still
> > have a few board patches built on top of it in my queue.
>
> Works for me once Dmitry is happy with the patches.
And please repost the whole series with acks collected so
I know what I need to apply :)
Regards,
Tony
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: misc: Aspeed coprocessor interrupt controller
From: Joel Stanley @ 2018-06-19 6:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618045902.11453-3-benh@kernel.crashing.org>
On 18 June 2018 at 14:29, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> Add the device-tree binding definition for the AST2400
> and AST2500 coprocessor interrupt controller
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
> .../devicetree/bindings/misc/aspeed,cvic.txt | 35 +++++++++++++++++++
> 1 file changed, 35 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/misc/aspeed,cvic.txt
>
> diff --git a/Documentation/devicetree/bindings/misc/aspeed,cvic.txt b/Documentation/devicetree/bindings/misc/aspeed,cvic.txt
> new file mode 100644
> index 000000000000..2562e2991e4d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/aspeed,cvic.txt
Is there a reason you didn't put this in bindings/interrupt-controller?
Aside from that this looks good.
> @@ -0,0 +1,35 @@
> +* Aspeed AST2400 and AST2500 coprocessor interrupt controller
> +
> +This file describes the bindings for the interrupt controller present
> +in the AST2400 and AST2500 BMC SoCs which provides interrupt to the
> +ColdFire coprocessor.
> +
> +It is not a normal interrupt controller and it would be rather
> +inconvenient to create an interrupt tree for it as it somewhat shares
> +some of the same sources as the main ARM interrupt controller but with
> +different numbers.
> +
> +The AST2500 supports a SW generated interrupt
> +
> +Required properties:
> +- reg: address and length of the register for the device.
> +- compatible: "aspeed,cvic" and one of:
> + "aspeed,ast2400-cvic"
> + or
> + "aspeed,ast2500-cvic"
> +
> +- valid-sources: One cell, bitmap of supported sources for the implementation
> +
> +Optional properties;
> +- copro-sw-interrupts: List of interrupt numbers that can be used as
> + SW interrupts from the ARM to the coprocessor.
> + (AST2500 only)
> +
> +Example:
> +
> + cvic: copro-interrupt-controller at 1e6c2000 {
> + compatible = "aspeed,ast2500-cvic";
> + valid-sources = <0xffffffff>;
> + copro-sw-interrupts = <1>;
> + reg = <0x1e6c2000 0x80>;
> + };
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: misc: Aspeed coprocessor interrupt controller
From: Benjamin Herrenschmidt @ 2018-06-19 6:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACPK8XfCZA7m++KeJ1GyPAbBXPmyhebEkvb+R41Xy1iuGvkbLw@mail.gmail.com>
On Tue, 2018-06-19 at 16:26 +0930, Joel Stanley wrote:
> On 18 June 2018 at 14:29, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > Add the device-tree binding definition for the AST2400
> > and AST2500 coprocessor interrupt controller
> >
> > Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > ---
> > .../devicetree/bindings/misc/aspeed,cvic.txt | 35 +++++++++++++++++++
> > 1 file changed, 35 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/misc/aspeed,cvic.txt
> >
> > diff --git a/Documentation/devicetree/bindings/misc/aspeed,cvic.txt b/Documentation/devicetree/bindings/misc/aspeed,cvic.txt
> > new file mode 100644
> > index 000000000000..2562e2991e4d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/misc/aspeed,cvic.txt
>
> Is there a reason you didn't put this in bindings/interrupt-controller?
Well, I don't call it interrupt-controller anymore, it's not an
interrupt controller for the main CPU so I decided to leave it out.
If you (or somebody) has strong feeling about it, I can call it
interrupt-controller again and move it back there :)
> Aside from that this looks good.
>
> > @@ -0,0 +1,35 @@
> > +* Aspeed AST2400 and AST2500 coprocessor interrupt controller
> > +
> > +This file describes the bindings for the interrupt controller present
> > +in the AST2400 and AST2500 BMC SoCs which provides interrupt to the
> > +ColdFire coprocessor.
> > +
> > +It is not a normal interrupt controller and it would be rather
> > +inconvenient to create an interrupt tree for it as it somewhat shares
> > +some of the same sources as the main ARM interrupt controller but with
> > +different numbers.
> > +
> > +The AST2500 supports a SW generated interrupt
> > +
> > +Required properties:
> > +- reg: address and length of the register for the device.
> > +- compatible: "aspeed,cvic" and one of:
> > + "aspeed,ast2400-cvic"
> > + or
> > + "aspeed,ast2500-cvic"
> > +
> > +- valid-sources: One cell, bitmap of supported sources for the implementation
> > +
> > +Optional properties;
> > +- copro-sw-interrupts: List of interrupt numbers that can be used as
> > + SW interrupts from the ARM to the coprocessor.
> > + (AST2500 only)
> > +
> > +Example:
> > +
> > + cvic: copro-interrupt-controller at 1e6c2000 {
> > + compatible = "aspeed,ast2500-cvic";
> > + valid-sources = <0xffffffff>;
> > + copro-sw-interrupts = <1>;
> > + reg = <0x1e6c2000 0x80>;
> > + };
> > --
> > 2.17.1
> >
^ permalink raw reply
* [PATCH 2/2] arm64: dts: exynos: Remove unneeded DSI and DECON address/size cells in Exynos5433
From: Andrzej Hajda @ 2018-06-19 7:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618174216.24801-2-krzk@kernel.org>
On 18.06.2018 19:42, Krzysztof Kozlowski wrote:
> The decon, decon_tv and dsi nodes have only one child port so
> address/size mappings are not necessary. This fixes DTC warnings like:
>
> Warning (graph_child_address): /soc/decon at 13800000/ports:
> graph node has single child node 'port at 0', #address-cells/#size-cells are not necessary
DECON nodes according to documentation have only one port so it is OK.
DSI has two ports, but since on all Exynos platforms DSI panels/bridges
are subnodes of ExynosDSI the 2nd port is not used.
So if there will be a platform with DSI panel/bridge controlled via I2C,
it should be reverted., but this is theoretical problem.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
?--
Regards
Andrzej
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 +-----
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 12 ++----------
> 2 files changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> index a1e3194b7483..0a15ee513f5c 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -321,11 +321,7 @@
> status = "okay";
>
> ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port at 0 {
> - reg = <0>;
> + port {
> tv_to_hdmi: endpoint {
> remote-endpoint = <&hdmi_to_tv>;
> };
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 3a9b4c4b9c63..e4367fd39120 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -850,11 +850,7 @@
> iommu-names = "m0", "m1";
>
> ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port at 0 {
> - reg = <0>;
> + port {
> decon_to_mic: endpoint {
> remote-endpoint =
> <&mic_to_decon>;
> @@ -914,11 +910,7 @@
> #size-cells = <0>;
>
> ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port at 0 {
> - reg = <0>;
> + port {
> dsi_to_mic: endpoint {
> remote-endpoint = <&mic_to_dsi>;
> };
^ permalink raw reply
* [PATCH 2/2] arm64: dts: exynos: Remove unneeded DSI and DECON address/size cells in Exynos5433
From: Marek Szyprowski @ 2018-06-19 7:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180618174216.24801-2-krzk@kernel.org>
Hi Krzysztof,
On 2018-06-18 19:42, Krzysztof Kozlowski wrote:
> The decon, decon_tv and dsi nodes have only one child port so
> address/size mappings are not necessary. This fixes DTC warnings like:
>
> Warning (graph_child_address): /soc/decon at 13800000/ports:
> graph node has single child node 'port at 0', #address-cells/#size-cells are not necessary
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Works fine with current Exynos DRM Decon/MIC/DSI drivers.
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 6 +-----
> arch/arm64/boot/dts/exynos/exynos5433.dtsi | 12 ++----------
> 2 files changed, 3 insertions(+), 15 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> index a1e3194b7483..0a15ee513f5c 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
> @@ -321,11 +321,7 @@
> status = "okay";
>
> ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port at 0 {
> - reg = <0>;
> + port {
> tv_to_hdmi: endpoint {
> remote-endpoint = <&hdmi_to_tv>;
> };
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> index 3a9b4c4b9c63..e4367fd39120 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
> @@ -850,11 +850,7 @@
> iommu-names = "m0", "m1";
>
> ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port at 0 {
> - reg = <0>;
> + port {
> decon_to_mic: endpoint {
> remote-endpoint =
> <&mic_to_decon>;
> @@ -914,11 +910,7 @@
> #size-cells = <0>;
>
> ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port at 0 {
> - reg = <0>;
> + port {
> dsi_to_mic: endpoint {
> remote-endpoint = <&mic_to_dsi>;
> };
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 0/2] Add support for the ConnectCore 6UL SOM and SBC Express
From: Alex Gonzalez @ 2018-06-19 7:32 UTC (permalink / raw)
To: linux-arm-kernel
This patchset adds a device tree include for the ConnectCore 6UL
System-On-Module and a device tree for the ConnectCore 6UL SBC Express board
that includes it.
Not all the SOM hardware is supported in this initial patchset, specifically
the 802.11 WiFi and BT chipset and the extended functionality provided by
the on module NXP Kinetis KL03 are not supported.
The SOM is based on NXP's i.MX6UL SoC, and the patchset is tested against
v4.18-rc1.
More information about the hardware can be found at:
ConnectCore 6UL SOM:
https://www.digi.com/products/embedded-systems/system-on-modules/connectcore-for-i-mx6ul
ConnectCore 6UL SBC Express board:
https://www.digi.com/products/embedded-systems/single-board-computers/connectcore-for-i-mx6ul-sbc-express
Alex Gonzalez (2):
ARM: dts: imx6ul: Add DTS for ConnectCore 6UL System-On-Module (SOM)
ARM: dts: imx6ul: Add DTS for ConnectCore 6UL SBC Express
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6ul-ccimx6ulsbcexpress.dts | 205 ++++++++++++++++++++++++
arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi | 199 +++++++++++++++++++++++
3 files changed, 405 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-ccimx6ulsbcexpress.dts
create mode 100644 arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi
^ permalink raw reply
* [PATCH 1/2] ARM: dts: imx6ul: Add DTS for ConnectCore 6UL System-On-Module (SOM)
From: Alex Gonzalez @ 2018-06-19 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1529393534-7827-1-git-send-email-alex.gonzalez@digi.com>
The ConnectCore 6UL System-On-Module has the following hardware
specification:
* Based on a NXP i.MX6UL SoC
* Industrial temperature ranges (-40?C to +85?C)
* Up to 1GB DDR3 memory
* Up to 2GB NAND flash
* Dual Ethernet
* On module 802.11 WiFi and Bluetooth 4.2 (QCA6564)
* On module NXP Kinetis KL03
* On module Microchip ATECC508A crypto element
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
---
arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi | 199 ++++++++++++++++++++++++++++++
1 file changed, 199 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi
diff --git a/arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi b/arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi
new file mode 100644
index 000000000000..23484a48f6e0
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-ccimx6ulsom.dtsi
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Digi International's ConnectCore 6UL System-On-Module device tree source
+ *
+ * Copyright 2018 Digi International, Inc.
+ *
+ */
+
+/ {
+ reserved-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0x4000000>;
+ linux,cma-default;
+ };
+ };
+};
+
+&adc1 {
+ vref-supply = <&vdda_adc_3v3>;
+ max-channel = <9>;
+};
+
+&gpmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpmi_nand>;
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+
+ pmic: pfuze3000 at 8 {
+ compatible = "fsl,pfuze3000";
+ reg = <0x08>;
+
+ regulators {
+ int_3v3: sw1a {
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <6250>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_arm_soc_in: sw1b {
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1475000>;
+ regulator-ramp-delay = <6250>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <925000>;
+ };
+ };
+
+ ext_3v3: sw2 {
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-ramp-delay = <6250>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr3: sw3 {
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1650000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <1300000>;
+ };
+ };
+
+ swbst_reg: swbst {
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5150000>;
+ };
+
+ vdd_snvs_3v3: vsnvs {
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vrefddr: vrefddr {
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vdda_adc_3v3: vldo1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-adc-3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ ldo2_ext: vldo2 {
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1550000>;
+ };
+
+ vdda_wlan: vccsd {
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_high_in: v33 {
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3_int: vldo3 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ ldo4_ext: vldo4 {
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ vcoin_chg: vcoin {
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+ };
+};
+
+&iomuxc {
+ imx6ul-ccimx6ul {
+ pinctrl_gpmi_nand: gpmigrp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_CE0_B__RAWNAND_CE0_B 0xb0b1
+ MX6UL_PAD_NAND_RE_B__RAWNAND_RE_B 0xb0b1
+ MX6UL_PAD_NAND_WE_B__RAWNAND_WE_B 0xb0b1
+ MX6UL_PAD_NAND_WP_B__RAWNAND_WP_B 0xb0b1
+ MX6UL_PAD_NAND_ALE__RAWNAND_ALE 0xb0b1
+ MX6UL_PAD_NAND_CLE__RAWNAND_CLE 0xb0b1
+ MX6UL_PAD_NAND_DATA00__RAWNAND_DATA00 0xb0b1
+ MX6UL_PAD_NAND_DATA01__RAWNAND_DATA01 0xb0b1
+ MX6UL_PAD_NAND_DATA02__RAWNAND_DATA02 0xb0b1
+ MX6UL_PAD_NAND_DATA03__RAWNAND_DATA03 0xb0b1
+ MX6UL_PAD_NAND_DATA04__RAWNAND_DATA04 0xb0b1
+ MX6UL_PAD_NAND_DATA05__RAWNAND_DATA05 0xb0b1
+ MX6UL_PAD_NAND_DATA06__RAWNAND_DATA06 0xb0b1
+ MX6UL_PAD_NAND_DATA07__RAWNAND_DATA07 0xb0b1
+ MX6UL_PAD_NAND_READY_B__RAWNAND_READY_B 0xb0b1
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART4_TX_DATA__I2C1_SCL 0x4001b8b0
+ MX6UL_PAD_UART4_RX_DATA__I2C1_SDA 0x4001b8b0
+ >;
+ };
+ };
+};
+
+®_arm {
+ vin-supply = <&vdd_arm_soc_in>;
+ regulator-allow-bypass;
+};
+
+®_soc {
+ vin-supply = <&vdd_arm_soc_in>;
+ regulator-allow-bypass;
+};
+
^ permalink raw reply related
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