* [PATCH v8 6/7] arm/arm64: vgic: Implement VGICv3 CPU interface access
From: Vijay Kilari @ 2016-11-18 18:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161117160951.GB23588@cbox>
On Thu, Nov 17, 2016 at 9:39 PM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Thu, Nov 17, 2016 at 09:25:59PM +0530, Vijay Kilari wrote:
>> On Thu, Nov 17, 2016 at 12:22 AM, Christoffer Dall
>> <christoffer.dall@linaro.org> wrote:
>> > On Fri, Nov 04, 2016 at 04:43:32PM +0530, vijay.kilari at gmail.com wrote:
>> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >>
>> >> VGICv3 CPU interface registers are accessed using
>> >> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>> >> as 64-bit. The cpu MPIDR value is passed along with register id.
>> >> is used to identify the cpu for registers access.
>> >>
>> >> The version of VGIC v3 specification is define here
>> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>> >>
>> >> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>> >> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >> ---
>> >> arch/arm64/include/uapi/asm/kvm.h | 3 +
>> >> arch/arm64/kvm/Makefile | 1 +
>> >> include/kvm/arm_vgic.h | 9 +
>> >> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 +++
>> >> virt/kvm/arm/vgic/vgic-mmio-v3.c | 19 +++
>> >> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 324 ++++++++++++++++++++++++++++++++++++
>> >> virt/kvm/arm/vgic/vgic-v3.c | 8 +
>> >> virt/kvm/arm/vgic/vgic.h | 4 +
>> >> 8 files changed, 395 insertions(+)
>> >>
>> >> diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
>> >> index 56dc08d..91c7137 100644
>> >> --- a/arch/arm64/include/uapi/asm/kvm.h
>> >> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> >> @@ -206,9 +206,12 @@ struct kvm_arch_memory_slot {
>> >> (0xffffffffULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
>> >> #define KVM_DEV_ARM_VGIC_OFFSET_SHIFT 0
>> >> #define KVM_DEV_ARM_VGIC_OFFSET_MASK (0xffffffffULL << KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>> >> +#define KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0xffff)
>> >> #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
>> >> #define KVM_DEV_ARM_VGIC_GRP_CTRL 4
>> >> #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>> >> +#define KVM_DEV_ARM_VGIC_CPU_SYSREGS 6
>> >> +
>> >> #define KVM_DEV_ARM_VGIC_CTRL_INIT 0
>> >>
>> >> /* Device Control API on vcpu fd */
>> >> diff --git a/arch/arm64/kvm/Makefile b/arch/arm64/kvm/Makefile
>> >> index d50a82a..1a14e29 100644
>> >> --- a/arch/arm64/kvm/Makefile
>> >> +++ b/arch/arm64/kvm/Makefile
>> >> @@ -32,5 +32,6 @@ kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-mmio-v3.o
>> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-kvm-device.o
>> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-its.o
>> >> kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/irqchip.o
>> >> +kvm-$(CONFIG_KVM_ARM_HOST) += $(KVM)/arm/vgic/vgic-sys-reg-v3.o
>> >
>> > Thi is making me wonder: Are we properly handling GICv3 save/restore
>> > for AArch32 now that we have GICv3 support for AArch32? By properly I
>> > mean that either it is clearly only supported on AArch64 systems or it's
>> > supported on both AArch64 and AArch32, but it shouldn't break randomly
>> > on AArch32.
>>
>> It supports both AArch64 and AArch64 in handling of system registers
>> save/restore.
>> All system registers that we save/restore are 32-bit for both aarch64
>> and aarch32.
>> Though opcode op0 should be zero for aarch32, the remaining Op and CRn codes
>> are same. However the codes sent by qemu is matched and register
>> are handled properly irrespective of AArch32 or AArch64.
>>
>> I don't have platform which support AArch32 guests to verify.
>
> Actually this is not about the guest, it's about an ARMv8 AArch32 host
> that has a GICv3.
>
> I just tried to do a v7 compile with your patches, and it results in an
> epic failure, so there's something for you to look at.
>
Could you please share you config file?. I tried with multi_v7 defconfig with
CONFIG KVM and CONFIG_KVM_ARM_HOST enabled. it compiled for me.
^ permalink raw reply
* [PATCH 1/2] mfd: axp20x: Add address extension registers for AXP806 regmap
From: Lee Jones @ 2016-11-18 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161111032953.20849-2-wens@csie.org>
On Fri, 11 Nov 2016, Chen-Yu Tsai wrote:
> The AXP806 supports either master/standalone or slave mode.
> Slave mode allows sharing the serial bus, even with multiple
> AXP806 which all have the same hardware address.
>
> This is done with extra "serial interface address extension",
> or AXP806_BUS_ADDR_EXT, and "register address extension", or
> AXP806_REG_ADDR_EXT, registers. The former is read-only, with
> 1 bit customizable at the factory, and 1 bit depending on the
> state of an external pin. The latter is writable. Only when
> the these device addressing bits (in the upper 4 bits of the
> registers) match, will the device respond to operations on
> its other registers.
>
> Add these 2 registers to the regmap so we can access them.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> drivers/mfd/axp20x.c | 3 ++-
> include/linux/mfd/axp20x.h | 2 ++
> 2 files changed, 4 insertions(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index ba130be32e61..cdaeb34a9a38 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -135,6 +135,7 @@ static const struct regmap_range axp806_writeable_ranges[] = {
> regmap_reg_range(AXP806_PWR_OUT_CTRL1, AXP806_CLDO3_V_CTRL),
> regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ2_EN),
> regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE),
> + regmap_reg_range(AXP806_REG_ADDR_EXT, AXP806_REG_ADDR_EXT),
> };
>
> static const struct regmap_range axp806_volatile_ranges[] = {
> @@ -305,7 +306,7 @@ static const struct regmap_config axp806_regmap_config = {
> .val_bits = 8,
> .wr_table = &axp806_writeable_table,
> .volatile_table = &axp806_volatile_table,
> - .max_register = AXP806_VREF_TEMP_WARN_L,
> + .max_register = AXP806_REG_ADDR_EXT,
> .cache_type = REGCACHE_RBTREE,
> };
>
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index fec597fb34cb..7e85ececcedf 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -115,6 +115,8 @@ enum {
> #define AXP806_CLDO2_V_CTRL 0x25
> #define AXP806_CLDO3_V_CTRL 0x26
> #define AXP806_VREF_TEMP_WARN_L 0xf3
> +#define AXP806_BUS_ADDR_EXT 0xfe
> +#define AXP806_REG_ADDR_EXT 0xff
>
> /* Interrupt */
> #define AXP152_IRQ1_EN 0x40
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 2/6] mfd: dt: Add bindings for the Aspeed SoC Display Controller (GFX)
From: Lee Jones @ 2016-11-18 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478097481-14895-3-git-send-email-andrew@aj.id.au>
On Thu, 03 Nov 2016, Andrew Jeffery wrote:
> The Aspeed SoC Display Controller is presented as a syscon device to
> arbitrate access by display and pinmux drivers. Video pinmux
> configuration on fifth generation SoCs depends on bits in both the
> System Control Unit and the Display Controller.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/mfd/aspeed-gfx.txt | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
Same here.
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> new file mode 100644
> index 000000000000..aea5370efd97
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt
> @@ -0,0 +1,17 @@
> +* Device tree bindings for Aspeed SoC Display Controller (GFX)
> +
> +The Aspeed SoC Display Controller primarily does as its name suggests, but also
> +participates in pinmux requests on the g5 SoCs. It is therefore considered a
> +syscon device.
> +
> +Required properties:
> +- compatible: "aspeed,ast2500-gfx", "syscon"
> +- reg: contains offset/length value of the GFX memory
> + region.
> +
> +Example:
> +
> +gfx: display at 1e6e6000 {
> + compatible = "aspeed,ast2500-gfx", "syscon";
> + reg = <0x1e6e6000 0x1000>;
> +};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 3/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LPCHC)
From: Lee Jones @ 2016-11-18 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118184437.GD19884@dell.home>
[Sending Arnd this time!]
> Arnd,
>
> Do you have a preference?
>
> > The Aspeed LPC Host Controller is presented as a syscon device to
> > arbitrate access by LPC and pinmux drivers. LPC pinmux configuration on
> > fifth generation SoCs depends on bits in both the System Control Unit
> > and the LPC Host Controller.
> >
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > ---
> > Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt | 17 +++++++++++++++++
>
> Create a new directory in bindings/mfd called 'syscon'.
>
> Or perhaps 'bindings/syscon'.
>
> > 1 file changed, 17 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> > new file mode 100644
> > index 000000000000..792651488c3d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> > @@ -0,0 +1,17 @@
> > +* Device tree bindings for the Aspeed LPC Host Controller (LPCHC)
> > +
> > +The LPCHC registers configure LPC behaviour between the BMC and the host
> > +system. The LPCHC also participates in pinmux requests on g5 SoCs and is
> > +therefore considered a syscon device.
> > +
> > +Required properties:
> > +- compatible: "aspeed,ast2500-lpchc", "syscon"
> > +- reg: contains offset/length value of the LPCHC memory
> > + region.
>
> Why not just use a single tab, then you don't have to linewrap?
>
> > +Example:
> > +
> > +lpchc: lpchc at 1e7890a0 {
> > + compatible = "aspeed,ast2500-lpchc", "syscon";
> > + reg = <0x1e7890a0 0xc4>;
> > +};
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH v2 3/6] mfd: dt: Add bindings for the Aspeed LPC Host Controller (LPCHC)
From: Lee Jones @ 2016-11-18 18:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478097481-14895-4-git-send-email-andrew@aj.id.au>
Arnd,
Do you have a preference?
> The Aspeed LPC Host Controller is presented as a syscon device to
> arbitrate access by LPC and pinmux drivers. LPC pinmux configuration on
> fifth generation SoCs depends on bits in both the System Control Unit
> and the LPC Host Controller.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt | 17 +++++++++++++++++
Create a new directory in bindings/mfd called 'syscon'.
Or perhaps 'bindings/syscon'.
> 1 file changed, 17 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> new file mode 100644
> index 000000000000..792651488c3d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpchc.txt
> @@ -0,0 +1,17 @@
> +* Device tree bindings for the Aspeed LPC Host Controller (LPCHC)
> +
> +The LPCHC registers configure LPC behaviour between the BMC and the host
> +system. The LPCHC also participates in pinmux requests on g5 SoCs and is
> +therefore considered a syscon device.
> +
> +Required properties:
> +- compatible: "aspeed,ast2500-lpchc", "syscon"
> +- reg: contains offset/length value of the LPCHC memory
> + region.
Why not just use a single tab, then you don't have to linewrap?
> +Example:
> +
> +lpchc: lpchc at 1e7890a0 {
> + compatible = "aspeed,ast2500-lpchc", "syscon";
> + reg = <0x1e7890a0 0xc4>;
> +};
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCHv3 6/6] arm64: Add support for CONFIG_DEBUG_VIRTUAL
From: Laura Abbott @ 2016-11-18 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161118175327.GE1197@leverpostej>
On 11/18/2016 09:53 AM, Mark Rutland wrote:
> Hi,
>
> On Thu, Nov 17, 2016 at 05:16:56PM -0800, Laura Abbott wrote:
>>
>> x86 has an option CONFIG_DEBUG_VIRTUAL to do additional checks
>> on virt_to_phys calls. The goal is to catch users who are calling
>> virt_to_phys on non-linear addresses immediately. This inclues callers
>> using virt_to_phys on image addresses instead of __pa_symbol. As features
>> such as CONFIG_VMAP_STACK get enabled for arm64, this becomes increasingly
>> important. Add checks to catch bad virt_to_phys usage.
>>
>> Signed-off-by: Laura Abbott <labbott@redhat.com>
>> ---
>> v3: Make use of __pa_symbol required via debug checks. It's a WARN for now but
>> it can become a BUG after wider testing. __virt_to_phys is
>> now for linear addresses only. Dropped the VM_BUG_ON from Catalin's suggested
>> version from the nodebug version since having that in the nodebug version
>> essentially made them the debug version. Changed to KERNEL_START/KERNEL_END
>> for bounds checking. More comments.
>
> I gave this a go with DEBUG_VIRTUAL && KASAN_INLINE selected, and the
> kernel dies somewhere before bringing up earlycon. :(
>
> I mentioned some possible reasons in a reply to pastch 5, and I have
> some more comments below.
>
> [...]
>
>> -#define __virt_to_phys(x) ({ \
>> +
>> +
>> +/*
>> + * This is for translation from the standard linear map to physical addresses.
>> + * It is not to be used for kernel symbols.
>> + */
>> +#define __virt_to_phys_nodebug(x) ({ \
>> phys_addr_t __x = (phys_addr_t)(x); \
>> - __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
>> - (__x - kimage_voffset); })
>> + ((__x & ~PAGE_OFFSET) + PHYS_OFFSET); \
>> +})
>
> Given the KASAN failure, and the strong possibility that there's even
> more stuff lurking in common code, I think we should retain the logic to
> handle kernel image addresses for the timebeing (as x86 does). Once
> we've merged DEBUG_VIRTUAL, it will be easier to track those down.
>
Agreed. I might see about adding another option DEBUG_STRICT_VIRTUAL
for catching bad __pa vs __pa_symbol usage and keep DEBUG_VIRTUAL for
catching addresses that will work in neither case.
> Catalin, I think you suggested removing that logic; are you happy for it
> to be restored?
>
> See below for a refactoring that retains this logic.
>
> [...]
>
>> +/*
>> + * This is for translation from a kernel image/symbol address to a
>> + * physical address.
>> + */
>> +#define __pa_symbol_nodebug(x) ({ \
>> + phys_addr_t __x = (phys_addr_t)(x); \
>> + (__x - kimage_voffset); \
>> +})
>
> We can avoid duplication here (and in physaddr.c) if we factor the logic
> into helpers, e.g.
>
> /*
> * The linear kernel range starts in the middle of the virtual adddress
> * space. Testing the top bit for the start of the region is a
> * sufficient check.
> */
> #define __is_lm_address(addr) (!!((addr) & BIT(VA_BITS - 1)))
>
> #define __lm_to_phys(addr) (((addr) & ~PAGE_OFFSET) + PHYS_OFFSET)
> #define __kimg_to_phys(addr) ((addr) - kimage_voffset)
>
> #define __virt_to_phys_nodebug(x) ({ \
> phys_addr_t __x = (phys_addr_t)(x); \
> __is_lm_address(__x) ? __lm_to_phys(__x) : \
> __kimg_to_phys(__x); \
> })
>
> #define __pa_symbol_nodebug(x) __kimg_to_phys((phys_addr_t)(x))
>
Yes, this is much cleaner
>> +#ifdef CONFIG_DEBUG_VIRTUAL
>> +extern unsigned long __virt_to_phys(unsigned long x);
>> +extern unsigned long __phys_addr_symbol(unsigned long x);
>
> It would be better for both of these to return phys_addr_t.
>
> [...]
>
I was worried this would turn into another warning project but
at first pass this works fine and the type will hopefully catch
some bad uses elsewhere.
>> diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
>> new file mode 100644
>> index 0000000..f8eb781
>> --- /dev/null
>> +++ b/arch/arm64/mm/physaddr.c
>> @@ -0,0 +1,39 @@
>> +#include <linux/mm.h>
>> +
>> +#include <asm/memory.h>
>
> We also need:
>
> #include <linux/bug.h>
> #include <linux/export.h>
> #include <linux/types.h>
> #include <linux/mmdebug.h>
>
>> +unsigned long __virt_to_phys(unsigned long x)
>> +{
>> + phys_addr_t __x = (phys_addr_t)x;
>> +
>> + if (__x & BIT(VA_BITS - 1)) {
>> + /*
>> + * The linear kernel range starts in the middle of the virtual
>> + * adddress space. Testing the top bit for the start of the
>> + * region is a sufficient check.
>> + */
>> + return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
>> + } else {
>> + /*
>> + * __virt_to_phys should not be used on symbol addresses.
>> + * This should be changed to a BUG once all basic bad uses have
>> + * been cleaned up.
>> + */
>> + WARN(1, "Do not use virt_to_phys on symbol addresses");
>> + return __phys_addr_symbol(x);
>> + }
>> +}
>> +EXPORT_SYMBOL(__virt_to_phys);
>
> I think this would be better something like:
>
> phys_addr_t __virt_to_phys(unsigned long x)
> {
> WARN(!__is_lm_address(x),
> "virt_to_phys() used for non-linear address: %pK\n",
> (void*)x);
>
> return __virt_to_phys_nodebug(x);
> }
> EXPORT_SYMBOL(__virt_to_phys);
>
>> +
>> +unsigned long __phys_addr_symbol(unsigned long x)
>> +{
>> + phys_addr_t __x = (phys_addr_t)x;
>> +
>> + /*
>> + * This is bounds checking against the kernel image only.
>> + * __pa_symbol should only be used on kernel symbol addresses.
>> + */
>> + VIRTUAL_BUG_ON(x < (unsigned long) KERNEL_START || x > (unsigned long) KERNEL_END);
>> + return (__x - kimage_voffset);
>> +}
>> +EXPORT_SYMBOL(__phys_addr_symbol);
>
> Similarly:
>
> phys_addr_t __phys_addr_symbol(unsigned long x)
> {
> /*
> * This is bounds checking against the kernel image only.
> * __pa_symbol should only be used on kernel symbol addresses.
> */
> VIRTUAL_BUG_ON(x < (unsigned long) KERNEL_START ||
> x > (unsigned long) KERNEL_END);
>
> return __pa_symbol_nodebug(x);
> }
> EXPORT_SYMBOL(__phys_addr_symbol);
>
> Thanks,
> Mark.
>
Thanks,
Laura
^ permalink raw reply
* [GIT PULL] arm: dts: hisilicon dts updates for v4.10
From: Olof Johansson @ 2016-11-18 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582B333E.2060205@hisilicon.com>
On Tue, Nov 15, 2016 at 04:09:34PM +0000, Wei Xu wrote:
> Hi Arnd, Hi Olof, Hi Kevin,
>
> Please help to pull the following changes.
> Thanks!
>
> Best Regards,
> Wei
>
> ---
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://github.com/hisilicon/linux-hisi.git tags/hisi-armv7-soc-dt-for-4.10
>
> for you to fetch changes up to 3b23aabfcd48988179f7c6c2dde01f3356f68213:
>
> ARM: dts: hisi-x5hd2: Remove skeleton.dtsi inclusion (2016-11-15 11:30:55 +0000)
>
> ----------------------------------------------------------------
> ARM: DT: Hisilicon ARMv7 SoC DT updates for 4.10
>
> - Remove skeleton.dtsi inclusion for the Hip01, Hi3620 and Hix5hd2
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] arm64: dts: hisilicon dts updates for v4.10
From: Olof Johansson @ 2016-11-18 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582B320F.7030206@hisilicon.com>
On Tue, Nov 15, 2016 at 04:04:31PM +0000, Wei Xu wrote:
> Hi Arnd, Hi Olof, Hi Kevin,
>
> Please help to pull the following changes.
> Thanks!
>
> Best Regards,
> Wei
>
> ---
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://github.com/hisilicon/linux-hisi.git tags/hisi-arm64-dt-4.10
>
> for you to fetch changes up to 85f5bd9e771349833602ccdd39b65613ecd11fd1:
>
> arm64: dts: hisi: add refclk node to hip06 dts files for SAS (2016-11-15 10:58:41 +0000)
>
> ----------------------------------------------------------------
> ARM64: DT: Hisilicon SoC DT updates for 4.10
>
> - Correct the hardware pin number of the usb node on the Hip06
> - Add the Hisilicon Hip07 D05 board dts binding
> - Add the initial dts for the Hip07 D05 board
> - Fix the warning for the node without reg propery on the Hip06
> - Fix the sas am max transmissions quirk property on the Hip06
> - Disable the sas0 and sas2 on D03 board
> - Add refclk node for SAS on the Hip06
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL] STM32 DT changes for v4.10 #2
From: Olof Johansson @ 2016-11-18 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2f793efd-01c6-fa28-0332-9e292341c064@st.com>
On Tue, Nov 15, 2016 at 03:40:24PM +0100, Alexandre Torgue wrote:
> Hi Olof, Arnd and Kevin,
>
> Please consider this second round of STM32 DT updates for v4.10:
>
> The following changes since commit f6dbbff4f0af1a5c0d6eaf414572b5eff7a73a8b:
>
> ARM: dts: stm32f429: add LSI and LSE clocks (2016-11-04 15:08:08 +0100)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
> tags/stm32-dt-for-v4.10-2
>
> for you to fetch changes up to 2ecaa477b404d707bac93c56f09a0a6162e04ed7:
>
> ARM: dts: stm32f429: Add QSPI clock (2016-11-15 13:59:11 +0100)
>
> ----------------------------------------------------------------
> STM32 DT updates for v4.10, round 2.
>
> Highlights:
> ----------
> - Add support of STM32F746 MCU and STM32746G-Eval board
> - Add QSPI support for STM32F469-Disco board
>
> ----------------------------------------------------------------
> Alexandre TORGUE (1):
> ARM: dts: Add STM32F746 MCU and STM32746g-EVAL board
>
> Gabriel Fernandez (1):
> ARM: dts: stm32f429: Add QSPI clock
Hi, merged. But here too, please use common prefixes in the future,
please. I'd recommend 'ARM: dts: stm32: <...>'.
Thanks!
-Olof
^ permalink raw reply
* [GIT PULL] STM32 SOC changes for v4.10 #1
From: Olof Johansson @ 2016-11-18 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7e258e38-5ac9-60e8-4bc7-03acedd5e11d@st.com>
Hi,
On Tue, Nov 15, 2016 at 03:22:30PM +0100, Alexandre Torgue wrote:
> Hi Olof, Arnd and Kevin,
>
> Please consider this first round of STM32 SOC updates for v4.10:
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/atorgue/stm32.git
> tags/soc-for-4.10-1
>
> for you to fetch changes up to 6bc18b83c0c3b5d56137a31ce98ca2802036e7a9:
>
> ARM: Kconfig: Introduce MACH_STM32F746 flag (2016-11-15 12:02:59 +0100)
>
> ----------------------------------------------------------------
> STM32 SOC updates for v4.10, round 1.
>
> Highlights:
> ----------
> - Add new MCU SOC STM32F746
>
> ----------------------------------------------------------------
> Alexandre TORGUE (2):
> ARM: mach-stm32: Add a new SOC - STM32F746
> ARM: Kconfig: Introduce MACH_STM32F746 flag
Merged. For future patches, please use the same format as other platforms,
in your case it would be:
ARM: stm32: <..>
I.e. others are leaving out the mach- part.
Also, on the Kconfig change, please consider adding a Kconfig under your
mach directory and include it. We ask most platforms that have suboptions
to do this to avoid conflicts and provide a bit more structure. Feel
free to send a new pull request build on top of this one for that,
since we're merging this one now.
Thanks!
-Olof
^ permalink raw reply
* [GIT PULL 5/5] i.MX defconfig updates for 4.10
From: Olof Johansson @ 2016-11-18 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479200431-1765-5-git-send-email-shawnguo@kernel.org>
On Tue, Nov 15, 2016 at 05:00:31PM +0800, Shawn Guo wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-defconfig-4.10
>
> for you to fetch changes up to 3252e255371ad22c02d5c9d1740d408ce1b10f35:
>
> ARM: imx_v6_v7_defconfig: Select the es8328 codec driver (2016-10-24 19:54:38 +0800)
>
> ----------------------------------------------------------------
> i.MX defconfig updates for 4.10:
> - Increase CMA size to 64 MiB, so that we can use etnaviv driver with
> 1920x1080 display devices.
> - Enable ES8328 codec driver support, which is required by Kosagi
> Novena boards.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 4/5] Freescale arm64 device tree updates for 4.10
From: Olof Johansson @ 2016-11-18 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479200431-1765-4-git-send-email-shawnguo@kernel.org>
On Tue, Nov 15, 2016 at 05:00:30PM +0800, Shawn Guo wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt64-4.10
>
> for you to fetch changes up to 236f794e4463a6b53139702c1b609091f61a17ab:
>
> arm64: dts: ls2080a: Add TMU device tree support for LS2080A (2016-11-15 15:05:36 +0800)
>
> ----------------------------------------------------------------
> Freescale arm64 device tree updates for 4.10:
> - Enable Thermal Monitoring Unit (TMU) for thermal management on
> LS1043A and LS2080A.
> - Add support for LS1046A SoC, which has similar peripherals as
> LS1043A but integrates 4 A72 cores.
> - Add two LS1046A based board support: LS1046A-QDS and LS1046A-RDB.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 3/5] i.MX device tree updates for 4.10
From: Olof Johansson @ 2016-11-18 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479200431-1765-3-git-send-email-shawnguo@kernel.org>
On Tue, Nov 15, 2016 at 05:00:29PM +0800, Shawn Guo wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt-4.10
>
> for you to fetch changes up to c201369d4aa5f05b8a37d6d1eeabf248c7086454:
>
> ARM: dts: imx6ull: add imx6ull support (2016-11-15 08:54:27 +0800)
>
> ----------------------------------------------------------------
> i.MX device tree updates for 4.10:
> - New boards support: i.MX6SX UDOO Neo, Boundary Devices Nitrogen6_SOM2,
> Engicam i.CoreM6, Grinn i.MX6UL liteSOM/liteBoard, Toradex Colibri
> iMX6 module, i.MX6ULL and EVK board.
> - Remove skeleton.dtsi inclusion from all i.MX SoC dts files, as it's
> been deprecated, since commit 9c0da3cc61f1233c ("ARM: dts: explicitly
> mark skeleton.dtsi as deprecated").
> - Misc device addition and enabling: OCOTP for Vybrid, MMDC for i.MX6QP,
> TMU for LS1021A, FEC for imx6qdl-icore, DMA for Vybrid DSPI.
> - A few cleanups: use hyphens for node names, fix white spaces, move
> imx-weim parameters into SoC dtsi, replace gpio-key,wakeup with
> wakeup-source, remove pwm-leds from imx6q-apalis-ixora, remove I2C3
> from vf610-zii-dev-rev-b.
> - Other small random changes: calibrate USB PHY for b650v3 board,
> update TX D_CAL for USBPHY, use enable-gpios for backlight on
> imx6qdl-apalis, etc.
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCHv3 6/6] arm64: Add support for CONFIG_DEBUG_VIRTUAL
From: Mark Rutland @ 2016-11-18 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479431816-5028-7-git-send-email-labbott@redhat.com>
On Thu, Nov 17, 2016 at 05:16:56PM -0800, Laura Abbott wrote:
> diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
> index 54bb209..0d37c19 100644
> --- a/arch/arm64/mm/Makefile
> +++ b/arch/arm64/mm/Makefile
> @@ -5,6 +5,7 @@ obj-y := dma-mapping.o extable.o fault.o init.o \
> obj-$(CONFIG_HUGETLB_PAGE) += hugetlbpage.o
> obj-$(CONFIG_ARM64_PTDUMP) += dump.o
> obj-$(CONFIG_NUMA) += numa.o
> +obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
We'll also need:
KASAN_SANITIZE_physaddr.o := n
... or code prior to KASAN init will cause the kernel to die if
__virt_to_phys() or __phys_addr_symbol() are called.
> obj-$(CONFIG_KASAN) += kasan_init.o
> KASAN_SANITIZE_kasan_init.o := n
Thanks,
Mark,
^ permalink raw reply
* [PATCH] drm/sun4i: Fix a return value in case of error
From: Christophe JAILLET @ 2016-11-18 18:18 UTC (permalink / raw)
To: linux-arm-kernel
If 'sun4i_backend_drm_format_to_layer()' does not return 0, then 'val' is
left unmodified.
As it is not initialized either, the return value can be anything.
It is likely that returning the error code was expected here.
As the only caller of 'sun4i_backend_update_layer_formats()' does not check
the return value, this fix is purely theorical.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
index 7eb2a965f83d..f724b8047bae 100644
--- a/drivers/gpu/drm/sun4i/sun4i_backend.c
+++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
@@ -192,7 +192,7 @@ int sun4i_backend_update_layer_formats(struct sun4i_backend *backend,
ret = sun4i_backend_drm_format_to_layer(plane, fb->pixel_format, &val);
if (ret) {
DRM_DEBUG_DRIVER("Invalid format\n");
- return val;
+ return ret;
}
regmap_update_bits(backend->regs, SUN4I_BACKEND_ATTCTL_REG1(layer),
--
2.9.3
^ permalink raw reply related
* [PATCH v8 13/16] drivers: iommu: arm-smmu: add IORT configuration
From: Lorenzo Pieralisi @ 2016-11-18 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83df7dba-8d04-96ae-f59b-b0d484085e12@arm.com>
On Fri, Nov 18, 2016 at 05:36:46PM +0000, Robin Murphy wrote:
> On 16/11/16 15:29, Lorenzo Pieralisi wrote:
> > In ACPI bases systems, in order to be able to create platform
>
> based?
Ok.
> > devices and initialize them for ARM SMMU components, the IORT
> > kernel implementation requires a set of static functions to be
> > used by the IORT kernel layer to configure platform devices for
> > ARM SMMU components.
> >
> > Add static configuration functions to the IORT kernel layer for
> > the ARM SMMU components, so that the ARM SMMU driver can
> > initialize its respective platform device by relying on the IORT
> > kernel infrastructure and by adding a corresponding ACPI device
> > early probe section entry.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
> > Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
> > Tested-by: Tomasz Nowicki <tn@semihalf.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Robin Murphy <robin.murphy@arm.com>
> > Cc: Joerg Roedel <joro@8bytes.org>
> > ---
> > drivers/acpi/arm64/iort.c | 81 +++++++++++++++++++++++++++++++++++++++++++++
> > drivers/iommu/arm-smmu.c | 83 ++++++++++++++++++++++++++++++++++++++++++++++-
> > include/linux/acpi_iort.h | 3 ++
> > 3 files changed, 166 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index fd52e4c..4708806 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -548,6 +548,78 @@ static bool __init arm_smmu_v3_is_coherent(struct acpi_iort_node *node)
> > return smmu->flags & ACPI_IORT_SMMU_V3_COHACC_OVERRIDE;
> > }
> >
> > +static int __init arm_smmu_count_resources(struct acpi_iort_node *node)
> > +{
> > + struct acpi_iort_smmu *smmu;
> > + int num_irqs;
> > + u64 *glb_irq;
> > +
> > + /* Retrieve SMMU specific data */
> > + smmu = (struct acpi_iort_smmu *)node->node_data;
> > +
> > + glb_irq = ACPI_ADD_PTR(u64, node, smmu->global_interrupt_offset);
> > + if (!IORT_IRQ_MASK(glb_irq[1])) /* 0 means not implemented */
> > + num_irqs = 1;
> > + else
> > + num_irqs = 2;
>
> Do we actually need this - I mean, the configuration access interrupt is
> of somewhat limited utility, implementation-defined, and we don't have
> any handling for it. Nor should it, if present, ever happen anyway,
> since it's not like anyone else should be randomly poking our SMMU in
> invalid ways. Can we simply ignore it?
I added its parsing to bring the same capabilities present in DT to
ACPI, from what you are saying I think that we'd better ignore it
and add its parsing later if we _ever_ need to handle it.
> > +
> > + num_irqs += smmu->context_interrupt_count;
> > +
> > + return num_irqs + 1;
> > +}
> > +
> > +static void __init arm_smmu_init_resources(struct resource *res,
> > + struct acpi_iort_node *node)
> > +{
> > + struct acpi_iort_smmu *smmu;
> > + int i, hw_irq, trigger, num_res = 0;
> > + u64 *ctx_irq, *glb_irq;
> > +
> > + /* Retrieve SMMU specific data */
> > + smmu = (struct acpi_iort_smmu *)node->node_data;
> > +
> > + res[num_res].start = smmu->base_address;
> > + res[num_res].end = smmu->base_address + smmu->span - 1;
> > + res[num_res].flags = IORESOURCE_MEM;
> > + num_res++;
> > +
> > + glb_irq = ACPI_ADD_PTR(u64, node, smmu->global_interrupt_offset);
> > + /* Global IRQs */
> > + hw_irq = IORT_IRQ_MASK(glb_irq[0]);
> > + trigger = IORT_IRQ_TRIGGER_MASK(glb_irq[0]);
> > +
> > + acpi_iort_register_irq(hw_irq, "arm-smmu-global", trigger,
> > + &res[num_res++]);
> > +
> > + /* Global IRQs */
> > + hw_irq = IORT_IRQ_MASK(glb_irq[1]);
> > + if (hw_irq) {
> > + trigger = IORT_IRQ_TRIGGER_MASK(glb_irq[1]);
> > + acpi_iort_register_irq(hw_irq, "arm-smmu-global", trigger,
> > + &res[num_res++]);
> > + }
>
> Related to the above, I think the driver generally assumes these to be
> the global fault interrupt. If we *are* going to claim the config
> interrupt as well, we should probably disambiguate them, although
> admittedly we can't really do that retrospectively on the DT side.
I do not think we are missing functionality if for the time being
we just ignore the configuration access interrupt so that's what
I will do for this first version.
Thanks !
Lorenzo
> > +
> > + /* Context IRQs */
> > + ctx_irq = ACPI_ADD_PTR(u64, node, smmu->context_interrupt_offset);
> > + for (i = 0; i < smmu->context_interrupt_count; i++) {
> > + hw_irq = IORT_IRQ_MASK(ctx_irq[i]);
> > + trigger = IORT_IRQ_TRIGGER_MASK(ctx_irq[i]);
> > +
> > + acpi_iort_register_irq(hw_irq, "arm-smmu-context", trigger,
> > + &res[num_res++]);
> > + }
> > +}
> > +
> > +static bool __init arm_smmu_is_coherent(struct acpi_iort_node *node)
> > +{
> > + struct acpi_iort_smmu *smmu;
> > +
> > + /* Retrieve SMMU specific data */
> > + smmu = (struct acpi_iort_smmu *)node->node_data;
> > +
> > + return smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK;
> > +}
> > +
> > struct iort_iommu_config {
> > const char *name;
> > int (*iommu_init)(struct acpi_iort_node *node);
> > @@ -564,12 +636,21 @@ static const struct iort_iommu_config iort_arm_smmu_v3_cfg __initconst = {
> > .iommu_init_resources = arm_smmu_v3_init_resources
> > };
> >
> > +static const struct iort_iommu_config iort_arm_smmu_cfg __initconst = {
> > + .name = "arm-smmu",
> > + .iommu_is_coherent = arm_smmu_is_coherent,
> > + .iommu_count_resources = arm_smmu_count_resources,
> > + .iommu_init_resources = arm_smmu_init_resources
> > +};
> > +
> > static __init
> > const struct iort_iommu_config *iort_get_iommu_cfg(struct acpi_iort_node *node)
> > {
> > switch (node->type) {
> > case ACPI_IORT_NODE_SMMU_V3:
> > return &iort_arm_smmu_v3_cfg;
> > + case ACPI_IORT_NODE_SMMU:
> > + return &iort_arm_smmu_cfg;
> > default:
> > return NULL;
> > }
> > diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> > index 573b2b6..21d1892 100644
> > --- a/drivers/iommu/arm-smmu.c
> > +++ b/drivers/iommu/arm-smmu.c
> > @@ -28,6 +28,8 @@
> >
> > #define pr_fmt(fmt) "arm-smmu: " fmt
> >
> > +#include <linux/acpi.h>
> > +#include <linux/acpi_iort.h>
> > #include <linux/atomic.h>
> > #include <linux/delay.h>
> > #include <linux/dma-iommu.h>
> > @@ -1904,6 +1906,70 @@ static const struct of_device_id arm_smmu_of_match[] = {
> > };
> > MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
> >
> > +#ifdef CONFIG_ACPI
> > +static int acpi_smmu_get_data(u32 model, u32 *version, u32 *impl)
> > +{
> > + int ret = 0;
> > +
> > + switch (model) {
> > + case ACPI_IORT_SMMU_V1:
> > + case ACPI_IORT_SMMU_CORELINK_MMU400:
> > + *version = ARM_SMMU_V1;
> > + *impl = GENERIC_SMMU;
>
> Further to Will's comment, I'd say just pass the smmu pointer in and set
> the fields explicitly here.
>
> Robin.
>
> > + break;
> > + case ACPI_IORT_SMMU_V2:
> > + *version = ARM_SMMU_V2;
> > + *impl = GENERIC_SMMU;
> > + break;
> > + case ACPI_IORT_SMMU_CORELINK_MMU500:
> > + *version = ARM_SMMU_V2;
> > + *impl = ARM_MMU500;
> > + break;
> > + default:
> > + ret = -ENODEV;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> > + struct arm_smmu_device *smmu)
> > +{
> > + struct device *dev = smmu->dev;
> > + struct acpi_iort_node *node =
> > + *(struct acpi_iort_node **)dev_get_platdata(dev);
> > + struct acpi_iort_smmu *iort_smmu;
> > + u64 *glb_irq;
> > + int ret;
> > +
> > + /* Retrieve SMMU1/2 specific data */
> > + iort_smmu = (struct acpi_iort_smmu *)node->node_data;
> > +
> > + ret = acpi_smmu_get_data(iort_smmu->model, &smmu->version,
> > + &smmu->model);
> > + if (ret < 0)
> > + return ret;
> > +
> > + glb_irq = ACPI_ADD_PTR(u64, node, iort_smmu->global_interrupt_offset);
> > +
> > + if (!IORT_IRQ_MASK(glb_irq[1])) /* 0 means not implemented */
> > + smmu->num_global_irqs = 1;
> > + else
> > + smmu->num_global_irqs = 2;
> > +
> > + if (iort_smmu->flags & ACPI_IORT_SMMU_COHERENT_WALK)
> > + smmu->features |= ARM_SMMU_FEAT_COHERENT_WALK;
> > +
> > + return 0;
> > +}
> > +#else
> > +static inline int arm_smmu_device_acpi_probe(struct platform_device *pdev,
> > + struct arm_smmu_device *smmu)
> > +{
> > + return -ENODEV;
> > +}
> > +#endif
> > +
> > static int arm_smmu_device_dt_probe(struct platform_device *pdev,
> > struct arm_smmu_device *smmu)
> > {
> > @@ -1955,7 +2021,11 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
> > }
> > smmu->dev = dev;
> >
> > - err = arm_smmu_device_dt_probe(pdev, smmu);
> > + if (dev->of_node)
> > + err = arm_smmu_device_dt_probe(pdev, smmu);
> > + else
> > + err = arm_smmu_device_acpi_probe(pdev, smmu);
> > +
> > if (err)
> > return err;
> >
> > @@ -2103,6 +2173,17 @@ IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401", arm_smmu_of_init);
> > IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500", arm_smmu_of_init);
> > IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2", arm_smmu_of_init);
> >
> > +#ifdef CONFIG_ACPI
> > +static int __init arm_smmu_acpi_init(struct acpi_table_header *table)
> > +{
> > + if (iort_node_match(ACPI_IORT_NODE_SMMU))
> > + return arm_smmu_init();
> > +
> > + return 0;
> > +}
> > +IORT_ACPI_DECLARE(arm_smmu, ACPI_SIG_IORT, arm_smmu_acpi_init);
> > +#endif
> > +
> > MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
> > MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
> > MODULE_LICENSE("GPL v2");
> > diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> > index 17bb078..79ba1bb 100644
> > --- a/include/linux/acpi_iort.h
> > +++ b/include/linux/acpi_iort.h
> > @@ -23,6 +23,9 @@
> > #include <linux/fwnode.h>
> > #include <linux/irqdomain.h>
> >
> > +#define IORT_IRQ_MASK(irq) (irq & 0xffffffffULL)
> > +#define IORT_IRQ_TRIGGER_MASK(irq) ((irq >> 32) & 0xffffffffULL)
> > +
> > int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node);
> > void iort_deregister_domain_token(int trans_id);
> > struct fwnode_handle *iort_find_domain_token(int trans_id);
> >
>
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add Macnica Americas vendor prefix
From: Rob Herring @ 2016-11-18 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADhT+wcesJRSf0q+_BDEmtsMTAO2LcAPkqjsRW2mNc1znMp4qg@mail.gmail.com>
On Fri, Nov 18, 2016 at 10:25 AM, Dinh Nguyen <dinh.linux@gmail.com> wrote:
> Hi Rob,
>
> On Tue, Nov 1, 2016 at 10:36 AM, Dinh Nguyen <dinguyen@kernel.org> wrote:
>> Add a vendor prefix for the Macnica company.
>> http://http://www.macnica.com
>>
>> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
>> ---
>> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> index f0a48ea..81674f2 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
>> @@ -158,6 +158,7 @@ lg LG Corporation
>> linux Linux-specific binding
>> lltc Linear Technology Corporation
>> lsi LSI Corp. (LSI Logic)
>> +macnica Macnica Americas
>> marvell Marvell Technology Group Ltd.
>> maxim Maxim Integrated Products
>> meas Measurement Specialties
>> --
>> 2.8.3
>
> Just a gentle ping.
Sorry, didn't send anything out, but the series is already applied if
you look at -next or PW.
Rob
^ permalink raw reply
* [GIT PULL 2/5] i.MX soc updates for 4.10
From: Olof Johansson @ 2016-11-18 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479200431-1765-2-git-send-email-shawnguo@kernel.org>
On Tue, Nov 15, 2016 at 05:00:28PM +0800, Shawn Guo wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-soc-4.10
>
> for you to fetch changes up to 75b832fea2564c547dfd0a2377a5893f41aefec6:
>
> ARM: imx: mach-imx6ul: add imx6ull support (2016-11-15 08:58:43 +0800)
>
> ----------------------------------------------------------------
> i.MX SoC changes for 4.10:
> - Drop PL310_ERRATA_769419 for Vybrid, as it turns out that the SoC
> integrates revision r3p2 of the L2C-310, which is not affected by
> errata 769419.
> - Support perf for i.MX6 Multi-Mode DDR Controller (MMDC), so that we
> can profile memory access performance.
> - Support i.MX6ULL SoC using i.MX6UL base, since it's a derivative of
> i.MX6UL and pin-to-pin compatible with i.MX6UL.
Merged, thanks.
-Olof
^ permalink raw reply
* [GIT PULL 1/5] i.MX non-critical fixes for 4.10
From: Olof Johansson @ 2016-11-18 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479200431-1765-1-git-send-email-shawnguo@kernel.org>
On Tue, Nov 15, 2016 at 05:00:27PM +0800, Shawn Guo wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-fix-nc-4.10
>
> for you to fetch changes up to 72649a46067903d00f46e2ebef6543768224f1a0:
>
> ARM: dts: imx6q-cm-fx6: fix fec pinctrl (2016-11-14 15:31:01 +0800)
>
> ----------------------------------------------------------------
> i.MX non-critical fixes for 4.10:
> - A series from Vladimir to fix broken i.MX31 DT clock initialization.
> As i.MX31 DT support is still not quite complete, the changes are
> tested on qemu kzm target and mx31lite board with simple written DTS
> files.
> - A fix for CompuLab's sbc-fx6 baseboard to remove wrong fec pinctrl
> setting.
> - A DTS correction for i.MX6QP to reflect the change that the gate of
> LDB clock has been moved before the divider.
> - An imx7d-pinfunc fix for UART pinmux defines
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCHv3 0/6] CONFIG_DEBUG_VIRTUAL for arm64
From: Mark Rutland @ 2016-11-18 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479431816-5028-1-git-send-email-labbott@redhat.com>
On Thu, Nov 17, 2016 at 05:16:50PM -0800, Laura Abbott wrote:
> Hi,
Hi,
Thanks again for putting this together.
> This is v3 of the series to add CONFIG_DEBUG_VIRTUAL for arm64.
> The biggest change from v2 is the conversion of more __pa sites
> to __pa_symbol for stricter checks.
Patches 1-4 look good to me, and I've given them a spin in a few
configurations on arm64. For those:
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Patches 5 and 6 look like they're mostly there, but there are still a
few issues which I've commented on. Hopefully those aren't too painful
to sort out; it would be great to have this available.
Thanks,
Mark.
^ permalink raw reply
* [GIT PULL] add #pinctrl-cells for v4.10
From: Olof Johansson @ 2016-11-18 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <582a5813.1bc0620a.e65a9.b2cbSMTPIN_ADDED_BROKEN@mx.google.com>
Hi,
On Mon, Nov 14, 2016 at 04:34:19PM -0800, Tony Lindgren wrote:
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v4.10/pinctrl-cells-signed
>
> for you to fetch changes up to be76fd3197df608e1b010bf5ab90377205f54344:
>
> ARM: dts: Add #pinctrl-cells for pinctrl-single instances (2016-11-07 08:27:49 -0700)
>
> ----------------------------------------------------------------
> Add #pinctrl-cells for pinctrl-single using dts files. This allows
> us to use generic parser later on. Note that the driver supports
> handling the legacy binding also with no #pinctrl-cells so these
> changes can be queued separately from the driver changes.
You forgot to make one commit per file to maximize your patch contribution
count! :-)
Merged, but note that we normally keep arm64 and arm DT updates
separate. I'm gambling on not seeing any conflicts on the hi6220 dtsi
this time around though, and took it in as-is.
-Olof
^ permalink raw reply
* [PATCH] PCI: Add information about describing PCI in ACPI
From: Bjorn Helgaas @ 2016-11-18 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F921A88@lhreml507-mbx>
On Fri, Nov 18, 2016 at 05:17:34PM +0000, Gabriele Paoloni wrote:
> > -----Original Message-----
> > From: linux-kernel-owner at vger.kernel.org [mailto:linux-kernel-
> > owner at vger.kernel.org] On Behalf Of Bjorn Helgaas
> > Sent: 17 November 2016 18:00
> > +Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
> > +reserving address space! The static tables are for things the OS
> > +needs to know early in boot, before it can parse the ACPI namespace.
> > +If a new table is defined, an old OS needs to operate correctly even
> > +though it ignores the table. _CRS allows that because it is generic
> > +and understood by the old OS; a static table does not.
>
> Right so if my understanding is correct you are saying that resources
> described in the MCFG table should also be declared in PNP0C02 devices
> so that the PNP driver can reserve these resources.
Yes.
> On the other side the PCI Root bridge driver should not reserve such
> resources.
>
> Well if my understanding is correct I think we have a problem here:
> http://lxr.free-electrons.com/source/drivers/pci/ecam.c#L74
>
> As you can see pci_ecam_create() will conflict with the pnp driver
> as it will try to reserve the resources from the MCFG table...
>
> Maybe we need to rework pci_ecam_create() ?
I think it's OK as it is.
The pnp/system.c driver does try to reserve PNP0C02 resources, and it
marks them as "not busy". That way they appear in /proc/iomem and
won't be allocated for anything else, but they can still be requested
by drivers, e.g., pci/ecam.c, which will mark them "busy".
This is analogous to what the PCI core does in pci_claim_resource().
This is really a function of the ACPI/PNP *core*, which should reserve
all _CRS resources for all devices (not just PNP0C02 devices). But
it's done by pnp/system.c, and only for PNP0C02, because there's a
bunch of historical baggage there.
You'll also notice that in this case, things are out of order:
logically the pnp/system.c reservation should happen first, but in
fact the pci/ecam.c request happens *before* the pnp/system.c one.
That means the pnp/system.c one might fail and complain "[mem ...]
could not be reserved".
Bjorn
^ permalink raw reply
* [GIT PULL] ARM: at91: dt for 4.10
From: Olof Johansson @ 2016-11-18 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114183923.k5eki5fzzdfsx2j6@piout.net>
On Mon, Nov 14, 2016 at 07:39:23PM +0100, Alexandre Belloni wrote:
> Hi Arnd, Olof
>
> at91 DT changes for 4.10, I don't expect much more this cycle.
>
> The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
>
> Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.10-dt1
>
> for you to fetch changes up to b662a9dd8a1a03e6e2d61e74d3e7a08400edefb7:
>
> ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek (2016-11-14 17:04:24 +0100)
>
> ----------------------------------------------------------------
> DT changes for 4.10:
>
> - Many additions for sama5d2
> - few non urgent fixes for sam9260ek, sama5d4 and sama5d2
Merged, thanks.
-Olof
^ permalink raw reply
* [PATCHv3 6/6] arm64: Add support for CONFIG_DEBUG_VIRTUAL
From: Mark Rutland @ 2016-11-18 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479431816-5028-7-git-send-email-labbott@redhat.com>
Hi,
On Thu, Nov 17, 2016 at 05:16:56PM -0800, Laura Abbott wrote:
>
> x86 has an option CONFIG_DEBUG_VIRTUAL to do additional checks
> on virt_to_phys calls. The goal is to catch users who are calling
> virt_to_phys on non-linear addresses immediately. This inclues callers
> using virt_to_phys on image addresses instead of __pa_symbol. As features
> such as CONFIG_VMAP_STACK get enabled for arm64, this becomes increasingly
> important. Add checks to catch bad virt_to_phys usage.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v3: Make use of __pa_symbol required via debug checks. It's a WARN for now but
> it can become a BUG after wider testing. __virt_to_phys is
> now for linear addresses only. Dropped the VM_BUG_ON from Catalin's suggested
> version from the nodebug version since having that in the nodebug version
> essentially made them the debug version. Changed to KERNEL_START/KERNEL_END
> for bounds checking. More comments.
I gave this a go with DEBUG_VIRTUAL && KASAN_INLINE selected, and the
kernel dies somewhere before bringing up earlycon. :(
I mentioned some possible reasons in a reply to pastch 5, and I have
some more comments below.
[...]
> -#define __virt_to_phys(x) ({ \
> +
> +
> +/*
> + * This is for translation from the standard linear map to physical addresses.
> + * It is not to be used for kernel symbols.
> + */
> +#define __virt_to_phys_nodebug(x) ({ \
> phys_addr_t __x = (phys_addr_t)(x); \
> - __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \
> - (__x - kimage_voffset); })
> + ((__x & ~PAGE_OFFSET) + PHYS_OFFSET); \
> +})
Given the KASAN failure, and the strong possibility that there's even
more stuff lurking in common code, I think we should retain the logic to
handle kernel image addresses for the timebeing (as x86 does). Once
we've merged DEBUG_VIRTUAL, it will be easier to track those down.
Catalin, I think you suggested removing that logic; are you happy for it
to be restored?
See below for a refactoring that retains this logic.
[...]
> +/*
> + * This is for translation from a kernel image/symbol address to a
> + * physical address.
> + */
> +#define __pa_symbol_nodebug(x) ({ \
> + phys_addr_t __x = (phys_addr_t)(x); \
> + (__x - kimage_voffset); \
> +})
We can avoid duplication here (and in physaddr.c) if we factor the logic
into helpers, e.g.
/*
* The linear kernel range starts in the middle of the virtual adddress
* space. Testing the top bit for the start of the region is a
* sufficient check.
*/
#define __is_lm_address(addr) (!!((addr) & BIT(VA_BITS - 1)))
#define __lm_to_phys(addr) (((addr) & ~PAGE_OFFSET) + PHYS_OFFSET)
#define __kimg_to_phys(addr) ((addr) - kimage_voffset)
#define __virt_to_phys_nodebug(x) ({ \
phys_addr_t __x = (phys_addr_t)(x); \
__is_lm_address(__x) ? __lm_to_phys(__x) : \
__kimg_to_phys(__x); \
})
#define __pa_symbol_nodebug(x) __kimg_to_phys((phys_addr_t)(x))
> +#ifdef CONFIG_DEBUG_VIRTUAL
> +extern unsigned long __virt_to_phys(unsigned long x);
> +extern unsigned long __phys_addr_symbol(unsigned long x);
It would be better for both of these to return phys_addr_t.
[...]
> diff --git a/arch/arm64/mm/physaddr.c b/arch/arm64/mm/physaddr.c
> new file mode 100644
> index 0000000..f8eb781
> --- /dev/null
> +++ b/arch/arm64/mm/physaddr.c
> @@ -0,0 +1,39 @@
> +#include <linux/mm.h>
> +
> +#include <asm/memory.h>
We also need:
#include <linux/bug.h>
#include <linux/export.h>
#include <linux/types.h>
#include <linux/mmdebug.h>
> +unsigned long __virt_to_phys(unsigned long x)
> +{
> + phys_addr_t __x = (phys_addr_t)x;
> +
> + if (__x & BIT(VA_BITS - 1)) {
> + /*
> + * The linear kernel range starts in the middle of the virtual
> + * adddress space. Testing the top bit for the start of the
> + * region is a sufficient check.
> + */
> + return (__x & ~PAGE_OFFSET) + PHYS_OFFSET;
> + } else {
> + /*
> + * __virt_to_phys should not be used on symbol addresses.
> + * This should be changed to a BUG once all basic bad uses have
> + * been cleaned up.
> + */
> + WARN(1, "Do not use virt_to_phys on symbol addresses");
> + return __phys_addr_symbol(x);
> + }
> +}
> +EXPORT_SYMBOL(__virt_to_phys);
I think this would be better something like:
phys_addr_t __virt_to_phys(unsigned long x)
{
WARN(!__is_lm_address(x),
"virt_to_phys() used for non-linear address: %pK\n",
(void*)x);
return __virt_to_phys_nodebug(x);
}
EXPORT_SYMBOL(__virt_to_phys);
> +
> +unsigned long __phys_addr_symbol(unsigned long x)
> +{
> + phys_addr_t __x = (phys_addr_t)x;
> +
> + /*
> + * This is bounds checking against the kernel image only.
> + * __pa_symbol should only be used on kernel symbol addresses.
> + */
> + VIRTUAL_BUG_ON(x < (unsigned long) KERNEL_START || x > (unsigned long) KERNEL_END);
> + return (__x - kimage_voffset);
> +}
> +EXPORT_SYMBOL(__phys_addr_symbol);
Similarly:
phys_addr_t __phys_addr_symbol(unsigned long x)
{
/*
* This is bounds checking against the kernel image only.
* __pa_symbol should only be used on kernel symbol addresses.
*/
VIRTUAL_BUG_ON(x < (unsigned long) KERNEL_START ||
x > (unsigned long) KERNEL_END);
return __pa_symbol_nodebug(x);
}
EXPORT_SYMBOL(__phys_addr_symbol);
Thanks,
Mark.
^ permalink raw reply
* [GIT PULL] Integrator DTS and defconfig changes
From: Olof Johansson @ 2016-11-18 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYoornJx1fTN1C5OiR16w9DbTcr9ze4gc9PLkt7LCqqCQ@mail.gmail.com>
On Fri, Nov 18, 2016 at 09:26:56AM +0100, Linus Walleij wrote:
> On Fri, Nov 18, 2016 at 8:25 AM, Olof Johansson <olof@lixom.net> wrote:
>
> > I also sympathize that it's extra annoying having to split just three
> > patches across two branches. So, if it's easier we can just cherry-pick
> > apart the patches here across the branches (your comment about next
> > coverage makes me suspect you have no direct downstream users of this
> > branch). If that's OK, let me know and I'll do that tomorrow.
>
> It's fine to cherry-pick, I can also send two separate branches (or
> just 2+1 stand-alone patches).
>
> Any way you like it :) just tell me what to do, all I want is to get this
> in for v4.10.
Cherry-picking is actually faster on our side than merging, so I've done that
now. Queued into next/dt and next/defconfig for 4.10.
Thanks!
-Olof
^ 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