* [PATCH v3 4/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LHC)
From: Rob Herring @ 2016-12-12 15:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206025321.1792-5-andrew@aj.id.au>
On Tue, Dec 06, 2016 at 01:53:19PM +1100, Andrew Jeffery wrote:
> The LPC bus pinmux configuration on fifth generation Aspeed SoCs depends
> on bits in both the System Control Unit and the LPC Host Controller.
>
> The Aspeed LPC Host Controller is described as a child node of the
> LPC host-range syscon device for arbitration of access by the host
> controller and pinmux drivers.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> .../devicetree/bindings/mfd/aspeed-lpc.txt | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> index a97131aba446..9de318ef72da 100644
> --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
> @@ -109,3 +109,25 @@ lpc: lpc at 1e789000 {
> };
> };
>
> +Host Node Children
> +==================
> +
> +LPC Host Controller
> +-------------------
> +
> +The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour
> +between the host and the baseboard management controller. The registers exist
> +in the "host" portion of the Aspeed LPC controller, which must be the parent of
> +the LPC host controller node.
> +
> +Required properties:
> +- compatible: "aspeed,ast2500-lhc";
> +- reg: contains offset/length value of the LHC memory
> + region.
How many regions? Looks like 2.
> +
> +Example:
> +
> +lhc: lhc at 20 {
> + compatible = "aspeed,ast2500-lhc";
> + reg = <0x20 0x24 0x48 0x8>;
> +};
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v3 3/6] mfd: dt: Add Aspeed Low Pin Count Controller bindings
From: Rob Herring @ 2016-12-12 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206025321.1792-4-andrew@aj.id.au>
On Tue, Dec 06, 2016 at 01:53:18PM +1100, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> .../devicetree/bindings/mfd/aspeed-lpc.txt | 111 +++++++++++++++++++++
> 1 file changed, 111 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpc.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 1/1] arm/module: maximum utilization of module area.
From: Nicolas Pitre @ 2016-12-12 15:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212112230epcms5p6af05aef34f72eab15061a166d18cff00@epcms5p6>
On Mon, 12 Dec 2016, Vaneet Narang wrote:
> Hi,
>
> >A PC24 relocation has a range of +/-32MB. This means that where-ever
> >the module is placed, it must be capable of reaching any function
> >within the kernel text, which may itself be quite large (eg, 8MB, or
> >possibly larger). The module area exists to allow modules to be
> >located in an area where PC24 relocations are able to reach all of the
> >kernel text on sensibly configured kernels, thereby allowing for
> >optimal performance.
> >
> >If you wish to load large modules, then enable ARM_MODULE_PLTS, which
> >will use the less efficient PLT method (which is basically an indirect
> >function call) for relocations that PC24 can't handle, and will allow
> >the module to be loaded into the vmalloc area.
> >
> >Growing the module area so that smaller modules also get penalised by
> >the PLT indirection is not sane.
>
> This is exactly what i am saying. These changes are useful to accomdate
> 22MB modules without enabling ARM_MODULE_PLTS.
I think you need to figure out why you need such a huge module in the
first place. That is very uncommon indeed.
Nicolas
^ permalink raw reply
* [PATCH] arm64: Re-enable PAN on uaccess_enable
From: Marc Zyngier @ 2016-12-12 15:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212151432.GB3203@e104818-lin.cambridge.arm.com>
On 12/12/16 15:14, Catalin Marinas wrote:
> On Mon, Dec 12, 2016 at 04:06:36PM +0100, Christoffer Dall wrote:
>> On Mon, Dec 12, 2016 at 01:50:26PM +0000, Marc Zyngier wrote:
>>> Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
>>> functionality based on TTBR0_EL1") added conditional PAN
>>> enable/disable. Unfortunately, a typo prevents PAN from being
>>> re-enabled once it has been disabled.
>>>
>>> Restore the PAN functionnality by adding the missing '!'.
>>>
>>> Fixes: b65a5db3627 ("arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1")
>>> Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
>>> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
>>> ---
>>> Christoffer, any chance you could give this a go and let me know
>>> if that fixes your issues?
>>
>> Yep, fixes the issue. Thanks!
>
> Thanks for confirming. I merged this with a slightly updated commit log:
>
> ------8<-----------------
> Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
> functionality based on TTBR0_EL1") added conditional user access
> enable/disable. Unfortunately, a typo prevents the PAN bit from being
> cleared for user access functions.
That looks indeed much better. Thanks!
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] arm64: Re-enable PAN on uaccess_enable
From: Catalin Marinas @ 2016-12-12 15:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212150636.GA7070@cbox>
On Mon, Dec 12, 2016 at 04:06:36PM +0100, Christoffer Dall wrote:
> On Mon, Dec 12, 2016 at 01:50:26PM +0000, Marc Zyngier wrote:
> > Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
> > functionality based on TTBR0_EL1") added conditional PAN
> > enable/disable. Unfortunately, a typo prevents PAN from being
> > re-enabled once it has been disabled.
> >
> > Restore the PAN functionnality by adding the missing '!'.
> >
> > Fixes: b65a5db3627 ("arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1")
> > Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
> > Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> > ---
> > Christoffer, any chance you could give this a go and let me know
> > if that fixes your issues?
>
> Yep, fixes the issue. Thanks!
Thanks for confirming. I merged this with a slightly updated commit log:
------8<-----------------
Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
functionality based on TTBR0_EL1") added conditional user access
enable/disable. Unfortunately, a typo prevents the PAN bit from being
cleared for user access functions.
--
Catalin
^ permalink raw reply
* [PATCH] arm64: Re-enable PAN on uaccess_enable
From: Christoffer Dall @ 2016-12-12 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481550626-30956-1-git-send-email-marc.zyngier@arm.com>
On Mon, Dec 12, 2016 at 01:50:26PM +0000, Marc Zyngier wrote:
> Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
> functionality based on TTBR0_EL1") added conditional PAN
> enable/disable. Unfortunately, a typo prevents PAN from being
> re-enabled once it has been disabled.
>
> Restore the PAN functionnality by adding the missing '!'.
>
> Fixes: b65a5db3627 ("arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1")
> Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> Christoffer, any chance you could give this a go and let me know
> if that fixes your issues?
Yep, fixes the issue. Thanks!
-Christoffer
>
> arch/arm64/include/asm/uaccess.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> index 6986f56..d26750c 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -188,7 +188,7 @@ do { \
>
> #define __uaccess_enable(alt) \
> do { \
> - if (uaccess_ttbr0_enable()) \
> + if (!uaccess_ttbr0_enable()) \
> asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt, \
> CONFIG_ARM64_PAN)); \
> } while (0)
> --
> 2.1.4
>
^ permalink raw reply
* [Xen-devel] [PATCH v2 4/4] Explicitly clean linux-system.axf and xen-system.axf
From: Andre Przywara @ 2016-12-12 14:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161212144729.GD1686@char.us.oracle.com>
Hi Konrad,
On 12/12/16 14:47, Konrad Rzeszutek Wilk wrote:
> On Tue, Nov 22, 2016 at 03:09:17PM +0000, Andre Przywara wrote:
>> From: Christoffer Dall <christoffer.dall@linaro.org>
>>
>> When doing a make clean, only the output image currently configured to
>> build is being removed. However, one would expect all build artifacts
>> to be removed when doing a 'make clean' and when switching between Xen
>> and Linux builds, it is easy to accidentally run an older build than
>> intended. Simply hardcode the axf image file names.
>>
>> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
>> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
>> Reviewed-by: Julien Grall <julien.grall@arm.com>
>
> Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Thanks a lot!
I will try to poke Mark to see if we can get this merged eventually.
Cheers,
Andre.
>> ---
>> Makefile.am | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index db97f9c..506a1d9 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -130,7 +130,7 @@ OFILES += $(addprefix $(ARCH_SRC),boot.o stack.o $(BOOTMETHOD) utils.o)
>>
>> all: $(IMAGE)
>>
>> -CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
>> +CLEANFILES = $(IMAGE) linux-system.axf xen-system.axf $(OFILES) model.lds fdt.dtb
>>
>> $(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
>> $(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds
>> --
>> 2.9.0
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel at lists.xen.org
>> https://lists.xen.org/xen-devel
^ permalink raw reply
* [Xen-devel] [PATCH v2 4/4] Explicitly clean linux-system.axf and xen-system.axf
From: Konrad Rzeszutek Wilk @ 2016-12-12 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122150917.16524-5-andre.przywara@arm.com>
On Tue, Nov 22, 2016 at 03:09:17PM +0000, Andre Przywara wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> When doing a make clean, only the output image currently configured to
> build is being removed. However, one would expect all build artifacts
> to be removed when doing a 'make clean' and when switching between Xen
> and Linux builds, it is easy to accidentally run an older build than
> intended. Simply hardcode the axf image file names.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Julien Grall <julien.grall@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> Makefile.am | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index db97f9c..506a1d9 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -130,7 +130,7 @@ OFILES += $(addprefix $(ARCH_SRC),boot.o stack.o $(BOOTMETHOD) utils.o)
>
> all: $(IMAGE)
>
> -CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
> +CLEANFILES = $(IMAGE) linux-system.axf xen-system.axf $(OFILES) model.lds fdt.dtb
>
> $(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
> $(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds
> --
> 2.9.0
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> https://lists.xen.org/xen-devel
^ permalink raw reply
* [Xen-devel] [PATCH v2 3/4] Xen: Select correct dom0 console
From: Konrad Rzeszutek Wilk @ 2016-12-12 14:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122150917.16524-4-andre.przywara@arm.com>
On Tue, Nov 22, 2016 at 03:09:16PM +0000, Andre Przywara wrote:
> From: Ian Campbell <ian.campbell@citrix.com>
>
> If Xen is enabled, tell Dom0 to use the 'hvc0' console, and fall back to
> the usual ttyAMA0 otherwise.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Reviewed-by: Julien Grall <julien.grall@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> configure.ac | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index aff4aad..c959ab8 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -92,7 +92,8 @@ AC_ARG_WITH([initrd],
> AC_SUBST([FILESYSTEM], [$USE_INITRD])
> AM_CONDITIONAL([INITRD], [test "x$USE_INITRD" != "x"])
>
> -C_CMDLINE="console=ttyAMA0 earlyprintk=pl011,0x1c090000"
> +AS_IF([test "x$X_IMAGE" = "x"],[C_CONSOLE="ttyAMA0"],[C_CONSOLE="hvc0"])
> +C_CMDLINE="console=$C_CONSOLE earlyprintk=pl011,0x1c090000"
> AC_ARG_WITH([cmdline],
> AS_HELP_STRING([--with-cmdline], [set a command line for the kernel]),
> [C_CMDLINE=$withval])
> --
> 2.9.0
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> https://lists.xen.org/xen-devel
^ permalink raw reply
* [Xen-devel] [PATCH v2 2/4] Xen: Support adding DT nodes
From: Konrad Rzeszutek Wilk @ 2016-12-12 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122150917.16524-3-andre.przywara@arm.com>
On Tue, Nov 22, 2016 at 03:09:15PM +0000, Andre Przywara wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Support adding xen,xen-bootargs node via --with-xen-bootargs to the
> configure script and automatically add the Dom0 node to the DT as well.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> Makefile.am | 23 +++++++++++++++--------
> configure.ac | 9 +++++++++
> 2 files changed, 24 insertions(+), 8 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index f8b9ec9..db97f9c 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -96,21 +96,28 @@ FDT_OFFSET := 0x08000000
> if XEN
> XEN := -DXEN=$(XEN_IMAGE)
> XEN_OFFSET := 0x08200000
> +KERNEL_SIZE := $(shell stat -Lc %s $(KERNEL_IMAGE) 2>/dev/null || echo 0)
> +DOM0_OFFSET := $(shell echo $$(($(PHYS_OFFSET) + $(KERNEL_OFFSET))))
> +XEN_BOOTARGS := xen,xen-bootargs = \"$(XEN_CMDLINE)\"; \
> + \#address-cells = <2>; \
> + \#size-cells = <2>; \
> + module at 1 { \
> + compatible = \"xen,linux-zimage\", \"xen,multiboot-module\"; \
> + reg = <0x0 $(DOM0_OFFSET) 0x0 $(KERNEL_SIZE)>; \
> + };
> endif
>
> if INITRD
> INITRD_FLAGS := -DUSE_INITRD
> +INITRD_CHOSEN := linux,initrd-start = <$(FILESYSTEM_START)>; \
> + linux,initrd-end = <$(FILESYSTEM_END)>;
> +endif
> +
> CHOSEN_NODE := chosen { \
> bootargs = \"$(CMDLINE)\"; \
> - linux,initrd-start = <$(FILESYSTEM_START)>; \
> - linux,initrd-end = <$(FILESYSTEM_END)>; \
> - };
> -else
> -INITRD_FLAGS :=
> -CHOSEN_NODE := chosen { \
> - bootargs = \"$(CMDLINE)\"; \
> + $(INITRD_CHOSEN) \
> + $(XEN_BOOTARGS) \
> };
> -endif
>
> CPPFLAGS += $(INITRD_FLAGS)
> CFLAGS += -Iinclude/ -I$(ARCH_SRC)/include/
> diff --git a/configure.ac b/configure.ac
> index f7e24c7..aff4aad 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -98,6 +98,12 @@ AC_ARG_WITH([cmdline],
> [C_CMDLINE=$withval])
> AC_SUBST([CMDLINE], [$C_CMDLINE])
>
> +X_CMDLINE="console=dtuart dtuart=serial0 no-bootscrub"
> +AC_ARG_WITH([xen-cmdline],
> + AS_HELP_STRING([--with-xen-cmdline], [set Xen command line]),
> + [X_CMDLINE=$withval])
> +AC_SUBST([XEN_CMDLINE], [$X_CMDLINE])
> +
> # Allow a user to pass --enable-gicv3
> AC_ARG_ENABLE([gicv3],
> AS_HELP_STRING([--enable-gicv3], [enable GICv3 instead of GICv2]),
> @@ -136,4 +142,7 @@ echo " Use GICv3? ${USE_GICV3}"
> echo " Boot-wrapper execution state: AArch${BOOTWRAPPER_ES}"
> echo " Kernel execution state: AArch${KERNEL_ES}"
> echo " Xen image ${XEN_IMAGE:-NONE}"
> +if test "x${XEN_IMAGE}" != "x"; then
> +echo " Xen command line: ${XEN_CMDLINE}"
> +fi
> echo ""
> --
> 2.9.0
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> https://lists.xen.org/xen-devel
^ permalink raw reply
* [Xen-devel] [PATCH v2 1/4] Support for building in a Xen binary
From: Konrad Rzeszutek Wilk @ 2016-12-12 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161122150917.16524-2-andre.przywara@arm.com>
On Tue, Nov 22, 2016 at 03:09:14PM +0000, Andre Przywara wrote:
> From: Christoffer Dall <christoffer.dall@linaro.org>
>
> Add support for building a Xen binary which includes a Dom0 image and
> the Dom0 command-line.
>
> If the user specifies --with-xen=<Xen>, where Xen is an appropriate
> AArch64 Xen binary, the build system will generate a xen-system.axf
> instead of a linux-system.axf.
>
> Original patch from Ian Campbell, but I modified most of it so all bugs
> are probably mine.
> [Andre: adapt to newest boot-wrapper branch, increase load address,
> fixup Xen image file test]
>
> Cc: Ian Campbell <ijc@hellion.org.uk>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
And also
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> ---
> .gitignore | 1 +
> Makefile.am | 10 +++++++---
> boot_common.c | 4 ++--
> configure.ac | 17 +++++++++++++++++
> model.lds.S | 14 ++++++++++++++
> 5 files changed, 41 insertions(+), 5 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index 8653852..80770c0 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -14,6 +14,7 @@ configure
> dtc
> fdt.dtb
> Image
> +Xen
> install-sh
> Makefile
> Makefile.in
> diff --git a/Makefile.am b/Makefile.am
> index 692d2cc..f8b9ec9 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -85,7 +85,6 @@ TEXT_LIMIT := 0x80080000
> endif
>
> LD_SCRIPT := model.lds.S
> -IMAGE := linux-system.axf
>
> FS_OFFSET := 0x10000000
> FILESYSTEM_START:= $(shell echo $$(($(PHYS_OFFSET) + $(FS_OFFSET))))
> @@ -94,6 +93,11 @@ FILESYSTEM_END := $(shell echo $$(($(FILESYSTEM_START) + $(FILESYSTEM_SIZE))))
>
> FDT_OFFSET := 0x08000000
>
> +if XEN
> +XEN := -DXEN=$(XEN_IMAGE)
> +XEN_OFFSET := 0x08200000
> +endif
> +
> if INITRD
> INITRD_FLAGS := -DUSE_INITRD
> CHOSEN_NODE := chosen { \
> @@ -121,7 +125,7 @@ all: $(IMAGE)
>
> CLEANFILES = $(IMAGE) $(OFILES) model.lds fdt.dtb
>
> -$(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM)
> +$(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM) $(XEN_IMAGE)
> $(LD) $(LDFLAGS) $(OFILES) -o $@ --script=model.lds
>
> %.o: %.S Makefile
> @@ -131,7 +135,7 @@ $(IMAGE): $(OFILES) model.lds fdt.dtb $(KERNEL_IMAGE) $(FILESYSTEM)
> $(CC) $(CPPFLAGS) $(CFLAGS) $(DEFINES) -c -o $@ $<
>
> model.lds: $(LD_SCRIPT) Makefile
> - $(CPP) $(CPPFLAGS) -ansi -DPHYS_OFFSET=$(PHYS_OFFSET) -DMBOX_OFFSET=$(MBOX_OFFSET) -DKERNEL_OFFSET=$(KERNEL_OFFSET) -DFDT_OFFSET=$(FDT_OFFSET) -DFS_OFFSET=$(FS_OFFSET) -DKERNEL=$(KERNEL_IMAGE) -DFILESYSTEM=$(FILESYSTEM) -DTEXT_LIMIT=$(TEXT_LIMIT) -P -C -o $@ $<
> + $(CPP) $(CPPFLAGS) -ansi -DPHYS_OFFSET=$(PHYS_OFFSET) -DMBOX_OFFSET=$(MBOX_OFFSET) -DKERNEL_OFFSET=$(KERNEL_OFFSET) -DFDT_OFFSET=$(FDT_OFFSET) -DFS_OFFSET=$(FS_OFFSET) $(XEN) -DXEN_OFFSET=$(XEN_OFFSET) -DKERNEL=$(KERNEL_IMAGE) -DFILESYSTEM=$(FILESYSTEM) -DTEXT_LIMIT=$(TEXT_LIMIT) -P -C -o $@ $<
>
> fdt.dtb: $(KERNEL_DTB) Makefile gen-cpu-nodes.sh
> ( $(DTC) -O dts -I dtb $(KERNEL_DTB) ; echo "/ { $(CHOSEN_NODE) $(PSCI_NODE) $(CPUS_NODE) };" ) | $(DTC) -O dtb -o $@ -
> diff --git a/boot_common.c b/boot_common.c
> index 4947fe3..e7b8e1d 100644
> --- a/boot_common.c
> +++ b/boot_common.c
> @@ -9,7 +9,7 @@
> #include <cpu.h>
> #include <spin.h>
>
> -extern unsigned long kernel;
> +extern unsigned long entrypoint;
> extern unsigned long dtb;
>
> void init_platform(void);
> @@ -67,7 +67,7 @@ void __noreturn first_spin(unsigned int cpu, unsigned long *mbox,
> if (cpu == 0) {
> init_platform();
>
> - *mbox = (unsigned long)&kernel;
> + *mbox = (unsigned long)&entrypoint;
> sevl();
> spin(mbox, invalid, 1);
> } else {
> diff --git a/configure.ac b/configure.ac
> index ab8f5b3..f7e24c7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -40,6 +40,18 @@ AC_ARG_WITH([dtb],
> AS_HELP_STRING([--with-dtb], [Specify a particular DTB to use]),
> [KERN_DTB="$withval"])
>
> +AC_ARG_WITH([xen],
> + AS_HELP_STRING([--with-xen], [Compile for Xen, and Specify a particular Xen to use]),
> + X_IMAGE=$withval)
> +
> +AS_IF([test "x$X_IMAGE" == "x"], [],
> + [AS_IF([test ! -f "$X_IMAGE"],
> + [AC_MSG_ERROR([Could not find Xen hypervisor binary: $X_IMAGE])]
> + )]
> +)
> +AC_SUBST([XEN_IMAGE], [$X_IMAGE])
> +AM_CONDITIONAL([XEN], [test "x$X_IMAGE" != "x"])
> +
> # Ensure that the user has provided us with a sane kernel dir.
> m4_define([CHECKFILES], [KERN_DIR,
> KERN_DTB,
> @@ -50,6 +62,10 @@ m4_foreach([checkfile], [CHECKFILES],
>
> AC_SUBST([KERNEL_IMAGE], [$KERN_IMAGE])
> AC_SUBST([KERNEL_DTB], [$KERN_DTB])
> +AS_IF([test "x$X_IMAGE" != "x"],
> + [AC_SUBST([IMAGE], ["xen-system.axf"])],
> + [AC_SUBST([IMAGE], ["linux-system.axf"])]
> +)
>
> # Allow a user to pass --enable-psci
> AC_ARG_ENABLE([psci],
> @@ -119,4 +135,5 @@ echo " CPU IDs: ${CPU_IDS}"
> echo " Use GICv3? ${USE_GICV3}"
> echo " Boot-wrapper execution state: AArch${BOOTWRAPPER_ES}"
> echo " Kernel execution state: AArch${KERNEL_ES}"
> +echo " Xen image ${XEN_IMAGE:-NONE}"
> echo ""
> diff --git a/model.lds.S b/model.lds.S
> index 51c5684..511f552 100644
> --- a/model.lds.S
> +++ b/model.lds.S
> @@ -16,6 +16,9 @@ OUTPUT_ARCH(aarch64)
> #endif
> TARGET(binary)
>
> +#ifdef XEN
> +INPUT(XEN)
> +#endif
> INPUT(KERNEL)
> INPUT(./fdt.dtb)
>
> @@ -36,6 +39,17 @@ SECTIONS
> KERNEL
> }
>
> +#ifdef XEN
> + .xen (PHYS_OFFSET + XEN_OFFSET): {
> + xen = .;
> + XEN
> + }
> +
> + entrypoint = xen;
> +#else
> + entrypoint = kernel;
> +#endif
> +
> .dtb (PHYS_OFFSET + FDT_OFFSET): {
> dtb = .;
> ./fdt.dtb
> --
> 2.9.0
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel at lists.xen.org
> https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH] watchdog: bcm2835_wdt: set WDOG_HW_RUNNING bit when appropriate
From: Guenter Roeck @ 2016-12-12 14:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481536123-9279-1-git-send-email-rasmus.villemoes@prevas.dk>
On 12/12/2016 01:48 AM, Rasmus Villemoes wrote:
> A bootloader may start the watchdog device before handing control to
> the kernel - in that case, we should tell the kernel about it so the
> watchdog framework can keep it alive until userspace opens
> /dev/watchdog0.
>
> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
> ---
> drivers/watchdog/bcm2835_wdt.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
> index 4dddd82..c32c45b 100644
> --- a/drivers/watchdog/bcm2835_wdt.c
> +++ b/drivers/watchdog/bcm2835_wdt.c
> @@ -55,6 +55,15 @@ struct bcm2835_wdt {
> static unsigned int heartbeat;
> static bool nowayout = WATCHDOG_NOWAYOUT;
>
> +static bool bcm2835_wdt_is_running(struct bcm2835_wdt *wdt)
> +{
> + uint32_t cur;
> +
> + cur = readl(wdt->base + PM_RSTC);
> +
> + return !!(cur & PM_RSTC_WRCFG_FULL_RESET);
> +}
> +
> static int bcm2835_wdt_start(struct watchdog_device *wdog)
> {
> struct bcm2835_wdt *wdt = watchdog_get_drvdata(wdog);
> @@ -181,6 +190,17 @@ static int bcm2835_wdt_probe(struct platform_device *pdev)
> watchdog_init_timeout(&bcm2835_wdt_wdd, heartbeat, dev);
> watchdog_set_nowayout(&bcm2835_wdt_wdd, nowayout);
> bcm2835_wdt_wdd.parent = &pdev->dev;
> + if (bcm2835_wdt_is_running(wdt)) {
> + /*
> + * The currently active timeout value (set by the
> + * bootloader) may be different from the module
> + * heartbeat parameter or the value in device
> + * tree. But we just need to set WDOG_HW_RUNNING,
> + * because then the framework will "immediately" ping
> + * the device, updating the timeout.
> + */
> + set_bit(WDOG_HW_RUNNING, &bcm2835_wdt_wdd.status);
> + }
> err = watchdog_register_device(&bcm2835_wdt_wdd);
> if (err) {
> dev_err(dev, "Failed to register watchdog device");
>
^ permalink raw reply
* [PATCH renesas/devel 10/13] ARM: dts: r8a7790: Use R-Car Gen 2 fallback binding for i2c nodes
From: Simon Horman @ 2016-12-12 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0db5b88e-41fb-03db-fa61-48e754356901@cogentembedded.com>
On Mon, Dec 12, 2016 at 01:28:30PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 12/12/2016 12:11 PM, Simon Horman wrote:
>
> >Use recently added R-Car Gen 2 fallback binding for iii nodes in
>
> s/iii/iic/?
Yes, thanks for noticing that.
> >DT for r8a7790 SoC.
> >
> >This has no run-time effect for the current driver as the initialisation
> >sequence is the same for the SoC-specific binding for r8a7790 and the
> >fallback binding for R-Car Gen 2.
> >
> >Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
> [...]
>
> MBR, Sergei
>
On Mon, Dec 12, 2016 at 02:42:29PM +0100, Geert Uytterhoeven wrote:
> Hi SImon,
>
> On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
> <horms+renesas@verge.net.au> wrote:
> > Use recently added R-Car Gen 2 fallback binding for iii nodes in
>
> As Sergei already pointed out: s/iii/iic/.
>
> You may also want to s/i2c/iic/ in the one-line summary, to avoid having
> multiple different patches with the same one-line summary (initially I was a
> bit confused by this, as Gmail grouped them together).
Yes, I meant to differentiate the subjects as you suggest.
I'll fix things up.
> These two comments apply to all iic DT patches in this series.
Got it.
^ permalink raw reply
* [RESEND PATCH] arm: assabet_defconfig: disable IDE subsystem
From: Sekhar Nori @ 2016-12-12 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5370936.ZbqF1HU8Jz@amdc3058>
Hi Bartlomiej,
On Monday 12 December 2016 06:15 PM, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> On Monday, July 18, 2016 08:15:08 PM Sekhar Nori wrote:
>> On Friday 15 July 2016 08:45 PM, Kevin Hilman wrote:
>>> Arnd Bergmann <arnd@arndb.de> writes:
>>>
>>>> On Wednesday, July 13, 2016 12:59:23 PM CEST Bartlomiej Zolnierkiewicz wrote:
>>>>>
>>>>> On Friday, July 08, 2016 10:23:48 PM Arnd Bergmann wrote:
>>>>>> On Friday, July 8, 2016 5:24:41 PM CEST Bartlomiej Zolnierkiewicz wrote:
>>>>>>> This patch disables deprecated IDE subsystem in assabet_defconfig
>>>>>>> (no IDE host drivers are selected in this config so there is no
>>>>>>> valid reason to enable IDE subsystem itself).
>>>>>>>
>>>>>>> Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>>>>>>> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
>>>>>>
>>>>>> I think the series makes a lot of sense. I have checked your assertions
>>>>>> in the changelogs and found no flaws in your logic, so I think we should
>>>>>> take them all through arm-soc unless there are other concerns.
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Should I resend everything or just patches that were not reposted yet
>>>>> (the ones that were marked as RFT initially and got no feedback)?
>>>>
>>>> I'd be fine with just getting a pull request with all the patches that
>>>> had no negative feedback and that were not already applied (if any).
>>>>
>>>>>> Do you have a list of ARM defconfigs that keep using CONFIG_IDE and
>>>>>> how you determined that they need it?
>>>>>
>>>>> The only such defconfig is davinci_all_defconfig which uses
>>>>> palm_bk3710 host driver (CONFIG_BLK_DEV_PALMCHIP_BK3710).
>>>>>
>>>>>> I know that ARCH_RPC/ARCH_ACORN has a couple of special drivers that
>>>>>> have no libata replacement, are there any others like that, or are
>>>>>> they all platforms that should in theory work with libata but need
>>>>>> testing?
>>>>>
>>>>> All platforms except ARCH_ACORN, ARCH_DAVINCI & ARCH_RPC should work
>>>>> with libata.
>>>>
>>>> Adding Sekhar and Kevin for DaVinci: At first sight, palm_bk3710 looks
>>>> fairly straightforward (meaning someone has to do a few day's work)
>>>> to convert into a libata driver.
>>>>
>>>> As this is on on-chip controller that is part of a dm644x and dm646x,
>>>> it should also not be hard to test (as long as someone can find
>>>> a hard drive to plug in).
>>>
>>> I have a hard drive, but don't have any dm64xx hardware anymore to test
>>> this. My last working dm644x board died last year.
>>
>> I have a working DM6446 EVM. I was able to connect a hard drive to it
>> and do some basic tests with v4.6 kernel.
>>
>> I will look into converting the driver to libata. Might take some time
>> because this is unfamiliar territory for me.
>
> Do you need some help with it?
>
> I can provide you with draft driver patch if you want.
A draft driver patch will really help. I can test/debug. Otherwise, not
sure when I will really be able to get to this.
Regards,
Sekhar
^ permalink raw reply
* [PATCH] arm64: Re-enable PAN on uaccess_enable
From: Marc Zyngier @ 2016-12-12 13:50 UTC (permalink / raw)
To: linux-arm-kernel
Commit 4b65a5db3627 ("arm64: Introduce uaccess_{disable,enable}
functionality based on TTBR0_EL1") added conditional PAN
enable/disable. Unfortunately, a typo prevents PAN from being
re-enabled once it has been disabled.
Restore the PAN functionnality by adding the missing '!'.
Fixes: b65a5db3627 ("arm64: Introduce uaccess_{disable,enable} functionality based on TTBR0_EL1")
Reported-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
---
Christoffer, any chance you could give this a go and let me know
if that fixes your issues?
arch/arm64/include/asm/uaccess.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 6986f56..d26750c 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -188,7 +188,7 @@ do { \
#define __uaccess_enable(alt) \
do { \
- if (uaccess_ttbr0_enable()) \
+ if (!uaccess_ttbr0_enable()) \
asm(ALTERNATIVE("nop", SET_PSTATE_PAN(0), alt, \
CONFIG_ARM64_PAN)); \
} while (0)
--
2.1.4
^ permalink raw reply related
* EXT: imx-sdma UART series failed for i.MX51
From: Han, Nandor (GE Healthcare) @ 2016-12-12 13:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481538186.727700380@f399.i.mail.ru>
Hi Alexander,
Thanks for info. I have already posted a patch that probably will
fix this issue.
https://lkml.org/lkml/2016/10/11/319
It was already tested on imx6 and imx53. Let me know how it works.
Reference:
http://lists-archives.com/linux-kernel/28679793-ext-pre-4-9-rc-dma-regression-imx6-sound-etc.html
On 12/12/2016 12:23, Alexander Shiyan wrote:
> Hello all.
>
> Upgrading the kernel from version 4.7 (to latest) has resulted in inoperable for i.MX51 DMA.
> It appears on sound playback (fsl_ssi with DMA). The sound is intermittent and a feeling that
> the each sound channel eats a part of buffer from another channel.
> Git-bisect found a first bad commit "first bad commit: [5881826ded79cf3c3314ee2d84c3bfa94e111b42]
> dmaengine: imx-sdma - update the residue calculation for cyclic channels" and after revert this commit,
> the problem has gone.
>
> Additionally, I had to disable DMA for the UART, because the revert the patch above led to the
> inoperability of the UART receiving part, although even before the series of all UART-SDMA
> patches still functioned normally (with imx6q check commented out).
>
> Any ideas?
>
> Thanks.
>
> shc at shc /home/ARM/linux $ git bisect log
> git bisect start
> # good: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3] Linux 4.8
> git bisect good c8d2bc9bc39ebea8437fd974fdbc21847bb897a3
> # bad: [2e972325da7a2984b9045844d4185f4406e7a4b0] Revert "USB debug"
> git bisect bad 2e972325da7a2984b9045844d4185f4406e7a4b0
> # bad: [41844e36206be90cd4d962ea49b0abc3612a99d0] Merge tag 'staging-4.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
<snip>
--
Regards,
Nandi
^ permalink raw reply
* [PATCH renesas/devel 13/13] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-14-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
> DT for r8a7794 SoC.
iic etc...
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7794 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 12/13] ARM: dts: r8a7793: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-13-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
> DT for r8a7793 SoC.
iic etc...
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7793 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 11/13] ARM: dts: r8a7791: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-12-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for iii nodes in
> DT for r8a7791 SoC.
iic etc...
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7791 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 1/7] ARM: EXYNOS: Constify list of retention registers
From: Bartlomiej Zolnierkiewicz @ 2016-12-12 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481377658-22603-1-git-send-email-krzk@kernel.org>
Hi,
On Saturday, December 10, 2016 03:47:32 PM Krzysztof Kozlowski wrote:
> The list of retention registers (release_ret_regs field of struct
> exynos_pm_data and arrays with values) are not modified and can be made
> const to improve the const safeness.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
for patches #1-7
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH renesas/devel 09/13] arm64: dts: r8a7796: Use R-Car Gen 3 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-10-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 3 fallback binding for i2c nodes in
> DT for r8a7796 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7796 and the
> fallback binding for R-Car Gen 3.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 08/13] arm64: dts: r8a7795: Use R-Car Gen 3 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-9-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 3 fallback binding for i2c nodes in
> DT for r8a7795 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7795 and the
> fallback binding for R-Car Gen 3.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH renesas/devel 07/13] ARM: dts: r8a7794: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-8-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7794 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7794 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH] ASoC: samsung: Remove tests of member address
From: Bartlomiej Zolnierkiewicz @ 2016-12-12 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481363471-21364-1-git-send-email-krzk@kernel.org>
Hi,
On Saturday, December 10, 2016 11:51:11 AM Krzysztof Kozlowski wrote:
> The driver was checking for non-NULL address of struct's members:
> - s3c_audio_pdata->type (union),
> - s3c_audio_pdata->type.i2s (embedded struct).
>
> This is pointless as these will be always non-NULL. The 's3c_audio_pdata'
> is always initialized in static memory so it will be zeroed.
> Additionally the 'type' member was an union with only one member.
>
> It is safe to reorganize the structures to get rid of useless union and
> checks for addresses to fix the coccinelle warning:
> >> sound/soc/samsung/i2s.c:1270:2-4: ERROR: test of a variable/field address
>
> Reported-by: kbuild test robot <fengguang.wu@intel.com>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
^ permalink raw reply
* [PATCH renesas/devel 05/13] ARM: dts: r8a7792: Use R-Car Gen 2 fallback binding for i2c nodes
From: Geert Uytterhoeven @ 2016-12-12 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1481533902-14789-6-git-send-email-horms+renesas@verge.net.au>
On Mon, Dec 12, 2016 at 10:11 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Use recently added R-Car Gen 2 fallback binding for i2c nodes in
> DT for r8a7792 SoC.
>
> This has no run-time effect for the current driver as the initialisation
> sequence is the same for the SoC-specific binding for r8a7792 and the
> fallback binding for R-Car Gen 2.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ 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