* [RESEND PATCH v2 15/15] arm64: dts: msm8996: db820c: Add sound card support
From: srinivas.kandagatla at linaro.org @ 2017-12-14 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214173402.19074-1-srinivas.kandagatla@linaro.org>
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
This patch adds hdmi sound card support to db820c via qdsp.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
---
arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi | 5 +++++
arch/arm64/boot/dts/qcom/msm8996.dtsi | 33 ++++++++++++++++++++++++++++
2 files changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
index 9769053957af..b955769b100d 100644
--- a/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
+++ b/arch/arm64/boot/dts/qcom/apq8096-db820c.dtsi
@@ -190,6 +190,11 @@
};
};
+ snd {
+ compatible = "qcom,apq8096-sndcard";
+ qcom,model = "DB820c";
+ iommus = <&lpass_q6_smmu 1>;
+ };
gpio_keys {
compatible = "gpio-keys";
diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index a144cec7bb71..25c43fb8ab49 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -1262,6 +1262,7 @@
phys = <&hdmi_phy>;
phy-names = "hdmi_phy";
+ #sound-dai-cells = <0>;
ports {
#address-cells = <1>;
@@ -1297,6 +1298,33 @@
"ref_clk";
};
};
+
+ lpass_q6_smmu: arm,smmu-lpass_q6 at 1600000 {
+ compatible = "qcom,msm8996-smmu-v2";
+ reg = <0x1600000 0x20000>;
+ #iommu-cells = <1>;
+ power-domains = <&gcc HLOS1_VOTE_LPASS_CORE_GDSC>;
+
+ #global-interrupts = <1>;
+ interrupts = <GIC_SPI 404 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 393 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 394 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 395 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 396 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 397 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 398 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 399 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 400 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 402 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_HLOS1_VOTE_LPASS_CORE_SMMU_CLK>,
+ <&gcc GCC_HLOS1_VOTE_LPASS_ADSP_SMMU_CLK>;
+ clock-names = "iface", "bus";
+ status = "okay";
+ };
};
adsp-pil {
@@ -1325,6 +1353,11 @@
qcom,ipc = <&apcs 16 8>;
qcom,smd-edge = <1>;
qcom,remote-pid = <2>;
+
+ apr {
+ compatible = "qcom,apr-msm8996";
+ qcom,smd-channels = "apr_audio_svc";
+ };
};
};
--
2.15.0
^ permalink raw reply related
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Mauro Carvalho Chehab @ 2017-12-14 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513272387.27409.69.camel@perches.com>
Em Thu, 14 Dec 2017 09:26:27 -0800
Joe Perches <joe@perches.com> escreveu:
> On Thu, 2017-12-14 at 15:05 -0200, Mauro Carvalho Chehab wrote:
> > Em Fri, 8 Dec 2017 18:05:37 +0530
> > Dhaval Shah <dhaval23031987@gmail.com> escreveu:
> >
> > > SPDX-License-Identifier is used for the Xilinx Video IP and
> > > related drivers.
> > >
> > > Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
> >
> > Hi Dhaval,
> >
> > You're not listed as one of the Xilinx driver maintainers. I'm afraid that,
> > without their explicit acks, sent to the ML, I can't accept a patch
> > touching at the driver's license tags.
>
> And even a maintainer may not have the sole right
> to modify a license.
Very true. I was actually expecting a patch like that either authored
or explicitly sanctioned by either one of those developers:
Hyun Kwon <hyun.kwon@xilinx.com> (supporter:XILINX VIDEO IP CORES)
Michal Simek <michal.simek@xilinx.com> (supporter:ARM/ZYNQ ARCHITECTURE)
As they own an @xilinx.com, we could assume that an email from
their corporate accounts to be official.
Thanks,
Mauro
^ permalink raw reply
* [PATCH 00/10] arm64: 52-bit physical address support
From: Bob Picco @ 2017-12-14 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513184845-8711-1-git-send-email-kristina.martsenko@arm.com>
Kristina Martsenko wrote: [Wed Dec 13 2017, 12:07:15PM EST]
> Hi,
>
> This series adds 52-bit physical address space support to arm64, up from
> the current 48 bits. This is an ARMv8.2 feature (ARMv8.2-LPA).
>
> The series is based on 4.15-rc3. It has been lightly tested on an ARM
> Fast Model. There's still some cases and areas to think through, as well
> as more testing to do.
>
> Patches for SMMU 52-bit PA support have been sent separately [1]. A GIC
> ITS patch has already been merged [2]. ARMv8.2 also allows 52-bit IPA,
> but support for that is not part of this series.
>
> This version mostly addresses various review comments received.
>
> Changes from RFC:
> - Split kconfig symbol into two patches, to enable 52-bit PA at the end
> - Patch #3: Changed phys_to_ttbr to use a macro, added an #include
> - Patch #4: Changed phys_to_pte to use a macro
> - Patch #6: Replaced __phys_to_pte with __phys_to_pte_val (same for
> pmd/pud/pgd)
> - Patch #6: Changed __phys_to_pte_val, __pte_to_phys, and
> pgtable-hwdef.h macros
> - Patches #5, #6: Removed kvm_extended_idmap_pgd, inlined its code,
> moved the comment
> - Patch #5: Added pfn_pud definition (to make the kernel build on that
> commit)
>
> Thanks,
> Kristina
>
> [1] https://www.spinics.net/lists/arm-kernel/msg619040.html
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=30ae9610d275f8f03f5bf7612ce71d8af6fc400b
>
>
> Kristina Martsenko (10):
> arm64: add kconfig symbol to configure physical address size
> arm64: limit PA size to supported range
> arm64: handle 52-bit addresses in TTBR
> arm64: head.S: handle 52-bit PAs in PTEs in early page table setup
> arm64: don't open code page table entry creation
> arm64: handle 52-bit physical addresses in page table entries
> arm64: increase PHYS_MASK to 52 bits
> arm64: increase sparsemem MAX_PHYSMEM_BITS to 52
> arm64: allow ID map to be extended to 52 bits
> arm64: enable 52-bit physical address support
>
> arch/arm/include/asm/kvm_mmu.h | 7 ++
> arch/arm64/Kconfig | 29 ++++++++
> arch/arm64/include/asm/assembler.h | 31 ++++++++-
> arch/arm64/include/asm/kvm_mmu.h | 21 +++++-
> arch/arm64/include/asm/mmu_context.h | 16 ++++-
> arch/arm64/include/asm/pgalloc.h | 6 +-
> arch/arm64/include/asm/pgtable-hwdef.h | 19 +++++-
> arch/arm64/include/asm/pgtable.h | 53 ++++++++++++---
> arch/arm64/include/asm/sparsemem.h | 2 +-
> arch/arm64/include/asm/sysreg.h | 8 +++
> arch/arm64/kernel/head.S | 118 +++++++++++++++++++++------------
> arch/arm64/kernel/hibernate-asm.S | 12 ++--
> arch/arm64/kernel/hibernate.c | 5 +-
> arch/arm64/kvm/hyp-init.S | 26 ++++----
> arch/arm64/kvm/hyp/s2-setup.c | 2 +
> arch/arm64/mm/mmu.c | 15 +++--
> arch/arm64/mm/pgd.c | 8 +++
> arch/arm64/mm/proc.S | 19 +++---
> virt/kvm/arm/arm.c | 2 +-
> virt/kvm/arm/mmu.c | 12 ++--
> 20 files changed, 302 insertions(+), 109 deletions(-)
>
> --
> 2.1.4
Hi Kristina,
I boot tested but on VM and had a couple issues. I will examine and share
should the issues be of value.
Tested-by: Bob Picco <bob.picco@oracle.com>
I reviewed and thank you. Your effort caused me to return to some code
examined/learned during the last few months.
Reviewed-by: Bob Picco <bob.picco@oracle.com>
bob
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] ARM: exynos_defconfig - enable CONFIG_EXYNOS_IOMMU
From: Krzysztof Kozlowski @ 2017-12-14 18:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d7d38ca9-ca53-8cb1-6c8a-c219ec94f005@samsung.com>
On Wed, Dec 13, 2017 at 10:42:33AM +0100, Marek Szyprowski wrote:
> Hi Shuah,
>
> On 2017-12-12 22:31, Shuah Khan wrote:
> > EXYNOS_IOMMU is disabled in exynos_defconfig since it is known to cause
> > boot failures on Exynos Chrome-books. The recommendation is for IOMMU to
> > be enabled manually on systems as needed.
> >
> > A recent exynos_drm change added a warning message when EXYNOS_IOMMU is
> > disabled. It is necessary to enable it to avoid the warning messages.
> > A few initial tests have shown that enabling EXYNOS_IOMMU might be safe
> > on Exynos Chrome-books.
> >
> > Enable CONFIG_EXYNOS_IOMMU in exynos_defconfig.
> >
> > Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
>
> Due to some other changes in the order of operations during boot process,
> power domains are initialized very early and because of the temporary
> lack of devices (which are not yet added to the system), are turned off.
>
> This practically stops FIMD for scanning framebuffer very early during
> boot, before IOMMU gets initialized and "solves" the issue, which was
> the reason to disable Exynos IOMMU by default.
>
> Like I've already said, I've checked Exynos Snow Chromebook boots fine
> with IOMMU support enabled, both with v4.15-rc3 and linux-next.
>
> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Thanks, applied with rephrased and extended message using Marek's
explanation.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] arm64: dts: Remove leading 0x and 0s from bindings notation
From: Matthias Brugger @ 2017-12-14 18:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214165352.27902-1-malat@debian.org>
On 12/14/2017 05:53 PM, Mathieu Malaterre wrote:
[...]
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index 26396ef53bde..0446b122a6e2 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -249,7 +249,7 @@
> reg = <0 0x10005000 0 0x1000>;
> };
>
> - pio: pinctrl at 0x10005000 {
> + pio: pinctrl at 10005000 {
> compatible = "mediatek,mt8173-pinctrl";
> reg = <0 0x1000b000 0 0x1000>;
> mediatek,pctl-regmap = <&syscfg_pctl_a>;
Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Geert Uytterhoeven @ 2017-12-14 18:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214152431.GC12608@e103592.cambridge.arm.com>
Hi Dave,
On Thu, Dec 14, 2017 at 4:24 PM, Dave P Martin <Dave.Martin@arm.com> wrote:
> On Thu, Dec 14, 2017 at 02:34:50PM +0000, Geert Uytterhoeven wrote:
>> On Tue, Dec 12, 2017 at 11:20 AM, Geert Uytterhoeven
>> <geert@linux-m68k.org> wrote:
>> > During userspace (Debian jessie NFS root) boot on arm64:
>> >
>> > rpcbind[1083]: unhandled level 0 translation fault (11) at 0x00000008,
>> > esr 0x92000004, in dash[aaaaadf77000+1a000]
>> > CPU: 0 PID: 1083 Comm: rpcbind Not tainted
>> > 4.15.0-rc3-arm64-renesas-02176-g14f9a1826e48e355 #51
>> > Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
>>
>> This is a quad Cortex A57.
>>
>> > pstate: 80000000 (Nzcv daif -PAN -UAO)
>> > pc : 0xaaaaadf8a51c
>> > lr : 0xaaaaadf8ac08
>> > sp : 0000ffffcffeac00
>> > x29: 0000ffffcffeac00 x28: 0000aaaaadfa1000
>> > x27: 0000ffffcffebf7c x26: 0000ffffcffead20
>> > x25: 0000aaaacea1c5f0 x24: 0000000000000000
>> > x23: 0000aaaaadfa1000 x22: 0000aaaaadfa1000
>> > x21: 0000000000000000 x20: 0000000000000008
>> > x19: 0000000000000000 x18: 0000ffffcffeb500
>> > x17: 0000ffffa22babfc x16: 0000aaaaadfa1ae8
>> > x15: 0000ffffa2363588 x14: ffffffffffffffff
>> > x13: 0000000000000020 x12: 0000000000000010
>> > x11: 0101010101010101 x10: 0000aaaaadfa1000
>> > x9 : 00000000ffffff81 x8 : 0000aaaaadfa2000
>> > x7 : 0000000000000000 x6 : 0000000000000000
>> > x5 : 0000aaaaadfa2338 x4 : 0000aaaaadfa2000
>> > x3 : 0000aaaaadfa2338 x2 : 0000000000000000
>> > x1 : 0000aaaaadfa28b0 x0 : 0000aaaaadfa4c30
>> >
>> > Sometimes it happens with other processes, but the main address, esr, and
>> > pstate values are always the same.
>> >
>> > I regularly run arm64/for-next/core (through bi-weekly renesas-drivers
>> > releases, so the last time was two weeks ago), but never saw the issue
>> > before until today, so probably v4.15-rc1 is OK.
>> > Unfortunately it doesn't happen during every boot, which makes it
>> > cumbersome to bisect.
>> >
>> > My first guess was UNMAP_KERNEL_AT_EL0, but even after disabling that,
>> > and even without today's arm64/for-next/core merged in, I still managed to
>> > reproduce the issue, so I believe it was introduced in v4.15-rc2 or
>> > v4.15-rc3.
>> >
>> > Once, when the kernel message above wasn't shown, I got an error from
>> > userspace, which may be related:
>> > *** Error in `/bin/sh': free(): invalid pointer: 0x0000aaaadd970988 ***
>>
>> With more boots (10 instead of 6) to declare a kernel good, I bisected this
>> to commit 9de52a755cfb6da5 ("arm64: fpsimd: Fix failure to restore FPSIMD
>> state after signals").
>>
>> Reverting that commit on top of v4.15-rc3 fixed the issue for me.
>
> Good work on the bisect -- I'll need to have a think about this...
>
> That patch fixes a genuine problem so we can't just revert it.
>
> What if you revert _just this function_ back to what it was in v4.14?
With fpsimd_update_current_state() reverted to v4.14, and
- __this_cpu_write(fpsimd_last_state, st);
+ __this_cpu_write(fpsimd_last_state.st, st);
to make it build, the problem seems to be fixed, too.
Thanks!
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 v14 1/4] drivers: jtag: Add JTAG core driver
From: Philippe Ombredanne @ 2017-12-14 18:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513268971-13518-2-git-send-email-oleksandrs@mellanox.com>
Oleksandr,
On Thu, Dec 14, 2017 at 5:29 PM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
> Initial patch for JTAG driver
> JTAG class driver provide infrastructure to support hardware/software
> JTAG platform drivers. It provide user layer API interface for flashing
> and debugging external devices which equipped with JTAG interface
> using standard transactions.
>
> Driver exposes set of IOCTL to user space for:
> - XFER:
> - SIR (Scan Instruction Register, IEEE 1149.1 Data Register scan);
> - SDR (Scan Data Register, IEEE 1149.1 Instruction Register scan);
> - RUNTEST (Forces the IEEE 1149.1 bus to a run state for a specified
> number of clocks).
> - SIOCFREQ/GIOCFREQ for setting and reading JTAG frequency.
>
> Driver core provides set of internal APIs for allocation and
> registration:
> - jtag_register;
> - jtag_unregister;
> - jtag_alloc;
> - jtag_free;
>
> Platform driver on registration with jtag-core creates the next
> entry in dev folder:
> /dev/jtagX
>
> Signed-off-by: Oleksandr Shamray <oleksandrs@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> ---
> v13->v14
> Comments pointed by Philippe Ombredanne <pombredanne@nexb.com>
> - Change style of head block comment from /**/ to //
>
> v12->v13
> Comments pointed by Philippe Ombredanne <pombredanne@nexb.com>
> - Change jtag.c licence type to
> SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
> and reorder line with license in description
> v11->v12
> Comments pointed by Greg KH <gregkh@linuxfoundation.org>
> - Change jtag.h licence type to
> SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
> and reorder line with license in description
Thanks for the SPDX bits: for this part you have my ack:
Acked-by: Philippe Ombredanne <pombredanne@nexB.com?
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* [patch v14 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver
From: Philippe Ombredanne @ 2017-12-14 18:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513268971-13518-3-git-send-email-oleksandrs@mellanox.com>
Oleksandr,
On Thu, Dec 14, 2017 at 5:29 PM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
> Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller.
>
> Driver implements the following jtag ops:
> - freq_get;
> - freq_set;
> - status_get;
> - idle;
> - xfer;
>
> It has been tested on Mellanox system with BMC equipped with
> Aspeed 2520 SoC for programming CPLD devices.
>
> Signed-off-by: Oleksandr Shamray <oleksandrs@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> ---
> v13->v14
> Comments pointed by Philippe Ombredanne <pombredanne@nexb.com>
> - Change style of head block comment from /**/ to //
>
> v12->v13
> Comments pointed by Philippe Ombredanne <pombredanne@nexb.com>
> - Change jtag-aspeed.c licence type to
> SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
> and reorder line with license in description
Thanks for the SPDX tags! for this part you have my ack:
Acked-by: Philippe Ombredanne <pombredanne@nexB.com?
--
Cordially
Philippe Ombredanne
^ permalink raw reply
* DT dtc warnings
From: Rob Herring @ 2017-12-14 18:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
Below is a current list of ARM boards with more than 40 dtc warnings
when building with W=1. There's a treewide patch in flight to fix some
unit-address warnings[1], so those aren't included here. The list is
grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
the top of the list and have been for some time (though having
multiple boards for an SoC can cause lots of duplicated warnings).
Please help fix these. More checks are being added[2].
Rob
[1] https://patchwork.kernel.org/patch/10112725/
[2] https://www.spinics.net/lists/devicetree-compiler/msg01620.html
77 - arch/arm/boot/dts/prima2-evb.dts
50 - arch/arm/boot/dts/exynos5250-arndale.dts
50 - arch/arm/boot/dts/exynos5250-smdk5250.dts
50 - arch/arm/boot/dts/exynos5250-snow.dts
50 - arch/arm/boot/dts/exynos5250-snow-rev5.dts
50 - arch/arm/boot/dts/exynos5250-spring.dts
71 - arch/arm/boot/dts/exynos5420-arndale-octa.dts
71 - arch/arm/boot/dts/exynos5420-peach-pit.dts
71 - arch/arm/boot/dts/exynos5420-smdk5420.dts
71 - arch/arm/boot/dts/exynos5422-odroidhc1.dts
71 - arch/arm/boot/dts/exynos5422-odroidxu3.dts
71 - arch/arm/boot/dts/exynos5422-odroidxu3-lite.dts
71 - arch/arm/boot/dts/exynos5422-odroidxu4.dts
71 - arch/arm/boot/dts/exynos5800-peach-pi.dts
42 - arch/arm/boot/dts/sun5i-gr8-evb.dts
44 - arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
49 - arch/arm/boot/dts/sun7i-a20-icnova-swac.dts
50 - arch/arm/boot/dts/sun7i-a20-itead-ibox.dts
50 - arch/arm/boot/dts/sun7i-a20-m3.dts
51 - arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
51 - arch/arm/boot/dts/sun7i-a20-mk808c.dts
51 - arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts
53 - arch/arm/boot/dts/sun7i-a20-bananapi.dts
53 - arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts
53 - arch/arm/boot/dts/sun7i-a20-hummingbird.dts
53 - arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts
53 - arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts
53 - arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts
53 - arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts
54 - arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
54 - arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
55 - arch/arm/boot/dts/sun7i-a20-bananapro.dts
55 - arch/arm/boot/dts/sun7i-a20-cubietruck.dts
55 - arch/arm/boot/dts/sun7i-a20-orangepi.dts
55 - arch/arm/boot/dts/sun7i-a20-pcduino3.dts
55 - arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts
56 - arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts
61 - arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
61 - arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
61 - arch/arm/boot/dts/sun7i-a20-olinuxino-micro-emmc.dts
46 - arch/arm/boot/dts/at91sam9rlek.dts
48 - arch/arm/boot/dts/at91sam9261ek.dts
50 - arch/arm/boot/dts/at91-kizbox.dts
50 - arch/arm/boot/dts/at91-qil_a9260.dts
51 - arch/arm/boot/dts/at91rm9200ek.dts
52 - arch/arm/boot/dts/at91sam9g20ek.dts
52 - arch/arm/boot/dts/at91-sam9_l9260.dts
53 - arch/arm/boot/dts/at91-foxg20.dts
53 - arch/arm/boot/dts/at91sam9260ek.dts
53 - arch/arm/boot/dts/at91sam9g20ek_2mmc.dts
54 - arch/arm/boot/dts/at91sam9263ek.dts
56 - arch/arm/boot/dts/at91sam9n12ek.dts
61 - arch/arm/boot/dts/at91-cosino_mega2560.dts
61 - arch/arm/boot/dts/at91sam9m10g45ek.dts
62 - arch/arm/boot/dts/at91-ariettag25.dts
63 - arch/arm/boot/dts/at91-ariag25.dts
64 - arch/arm/boot/dts/at91-kizboxmini.dts
64 - arch/arm/boot/dts/at91sam9g15ek.dts
65 - arch/arm/boot/dts/at91sam9g25ek.dts
66 - arch/arm/boot/dts/at91sam9g35ek.dts
69 - arch/arm/boot/dts/at91sam9x25ek.dts
70 - arch/arm/boot/dts/at91sam9x35ek.dts
74 - arch/arm/boot/dts/sama5d33ek.dts
75 - arch/arm/boot/dts/at91-sama5d27_som1_ek.dts
75 - arch/arm/boot/dts/at91-sama5d2_xplained.dts
76 - arch/arm/boot/dts/at91-kizbox2.dts
77 - arch/arm/boot/dts/sama5d31ek.dts
80 - arch/arm/boot/dts/sama5d34ek.dts
81 - arch/arm/boot/dts/sama5d35ek.dts
84 - arch/arm/boot/dts/at91-sama5d3_xplained.dts
84 - arch/arm/boot/dts/sama5d36ek_cmp.dts
84 - arch/arm/boot/dts/sama5d36ek.dts
93 - arch/arm/boot/dts/at91-sama5d4ek.dts
93 - arch/arm/boot/dts/at91-sama5d4_xplained.dts
93 - arch/arm/boot/dts/at91-vinco.dts
94 - arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts
77 - arch/arm/boot/dts/at91-tse850-3.dts
40 - arch/arm/boot/dts/stih410-b2260.dts
43 - arch/arm/boot/dts/stih410-b2120.dts
52 - arch/arm/boot/dts/keystone-k2e-evm.dts
73 - arch/arm/boot/dts/keystone-k2l-evm.dts
97 - arch/arm/boot/dts/keystone-k2hk-evm.dts
Boards with no maintainer:
192 - arch/arm/boot/dts/atlas7-evb.dts
50 - arch/arm/boot/dts/aks-cdu.dts
50 - arch/arm/boot/dts/animeo_ip.dts
50 - arch/arm/boot/dts/ethernut5.dts
50 - arch/arm/boot/dts/evk-pro3.dts
50 - arch/arm/boot/dts/tny_a9260.dts
50 - arch/arm/boot/dts/tny_a9g20.dts
50 - arch/arm/boot/dts/usb_a9260.dts
50 - arch/arm/boot/dts/usb_a9g20.dts
50 - arch/arm/boot/dts/usb_a9g20_lpw.dts
51 - arch/arm/boot/dts/mpa1600.dts
54 - arch/arm/boot/dts/tny_a9263.dts
54 - arch/arm/boot/dts/usb_a9263.dts
60 - arch/arm/boot/dts/pm9g45.dts
75 - arch/arm/boot/dts/ste-nomadik-nhk15.dts
75 - arch/arm/boot/dts/ste-nomadik-s8815.dts
77 - arch/arm/boot/dts/atlas6-evb.dts
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Laurent Pinchart @ 2017-12-14 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214150527.00dca6cc@vento.lan>
Hi Mauro,
On Thursday, 14 December 2017 19:05:27 EET Mauro Carvalho Chehab wrote:
> Em Fri, 8 Dec 2017 18:05:37 +0530 Dhaval Shah escreveu:
> > SPDX-License-Identifier is used for the Xilinx Video IP and
> > related drivers.
> >
> > Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
>
> Hi Dhaval,
>
> You're not listed as one of the Xilinx driver maintainers. I'm afraid that,
> without their explicit acks, sent to the ML, I can't accept a patch
> touching at the driver's license tags.
The patch doesn't change the license, I don't see why it would cause any
issue. Greg isn't listed as the maintainer or copyright holder of any of the
10k+ files to which he added an SPDX license header in the last kernel
release.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] arm64: dts: Remove leading 0x and 0s from bindings notation
From: Joe Perches @ 2017-12-14 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <98a7dc30-e736-eaf8-204f-2ac2b3ea79b9@gmail.com>
On Thu, 2017-12-14 at 19:03 +0100, Matthias Brugger wrote:
>
> On 12/14/2017 05:53 PM, Mathieu Malaterre wrote:
> [...]
> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > index 26396ef53bde..0446b122a6e2 100644
> > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> > @@ -249,7 +249,7 @@
> > reg = <0 0x10005000 0 0x1000>;
> > };
> >
> > - pio: pinctrl at 0x10005000 {
> > + pio: pinctrl at 10005000 {
> > compatible = "mediatek,mt8173-pinctrl";
> > reg = <0 0x1000b000 0 0x1000>;
> > mediatek,pctl-regmap = <&syscfg_pctl_a>;
>
> Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
Should all of these be fixed?
$ git grep -P "^\s*\w+:\s*[\w\-]+ at 0[xX]" -- "*.dts*" | wc -l
69
Is this a pattern that should be added to checkpatch?
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Joe Perches @ 2017-12-14 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7339763.I7jApfYMM6@avalon>
On Thu, 2017-12-14 at 20:28 +0200, Laurent Pinchart wrote:
> Hi Mauro,
>
> On Thursday, 14 December 2017 19:05:27 EET Mauro Carvalho Chehab wrote:
> > Em Fri, 8 Dec 2017 18:05:37 +0530 Dhaval Shah escreveu:
> > > SPDX-License-Identifier is used for the Xilinx Video IP and
> > > related drivers.
> > >
> > > Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
> >
> > Hi Dhaval,
> >
> > You're not listed as one of the Xilinx driver maintainers. I'm afraid that,
> > without their explicit acks, sent to the ML, I can't accept a patch
> > touching at the driver's license tags.
>
> The patch doesn't change the license, I don't see why it would cause any
> issue. Greg isn't listed as the maintainer or copyright holder of any of the
> 10k+ files to which he added an SPDX license header in the last kernel
> release.
Adding a comment line that describes an implicit or
explicit license is different than removing the license
text itself.
^ permalink raw reply
* [PATCH 02/10] arm64: limit PA size to supported range
From: Marc Zyngier @ 2017-12-14 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513184845-8711-3-git-send-email-kristina.martsenko@arm.com>
On 13/12/17 17:07, Kristina Martsenko wrote:
> We currently copy the physical address size from
> ID_AA64MMFR0_EL1.PARange directly into TCR.(I)PS. This will not work for
> 4k and 16k granule kernels on systems that support 52-bit physical
> addresses, since 52-bit addresses are only permitted with the 64k
> granule.
>
> To fix this, fall back to 48 bits when configuring the PA size when the
> kernel does not support 52-bit PAs. When it does, fall back to 52, to
> avoid similar problems in the future if the PA size is ever increased
> above 52.
>
> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
> ---
> arch/arm64/include/asm/assembler.h | 13 +++++++++++++
> arch/arm64/include/asm/sysreg.h | 8 ++++++++
> arch/arm64/kvm/hyp-init.S | 6 ++----
> arch/arm64/kvm/hyp/s2-setup.c | 2 ++
> arch/arm64/mm/proc.S | 6 ++----
> 5 files changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index aef72d886677..6cddf12a0250 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -351,6 +351,19 @@ alternative_endif
> .endm
>
> /*
> + * tcr_set_pa_size - set TCR.(I)PS to the highest supported
> + * ID_AA64MMFR0_EL1.PARange value
It'd be good to document what are the expected parameters here.
> + */
> + .macro tcr_set_pa_size, tcr, pos, tmp0, tmp1
Small nit: "tcr_compute_pa_size" would better describe what this does.
> + mrs \tmp0, ID_AA64MMFR0_EL1
> + ubfx \tmp0, \tmp0, #ID_AA64MMFR0_PARANGE_SHIFT, #3
It'd be good to have a comment explaining that we narrow the PARange to
fit the PS firld in TCR. Who knows what will happen once (if ever) we
get two other PARange extentions... ;-)
> + mov \tmp1, #ID_AA64MMFR0_PARANGE_MAX
> + cmp \tmp0, \tmp1
> + csel \tmp0, \tmp1, \tmp0, hi
> + bfi \tcr, \tmp0, \pos, #3> + .endm
> +
> +/*
> * Macro to perform a data cache maintenance for the interval
> * [kaddr, kaddr + size)
> *
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index 08cc88574659..ec144f480b39 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -471,6 +471,14 @@
> #define ID_AA64MMFR0_TGRAN64_SUPPORTED 0x0
> #define ID_AA64MMFR0_TGRAN16_NI 0x0
> #define ID_AA64MMFR0_TGRAN16_SUPPORTED 0x1
> +#define ID_AA64MMFR0_PARANGE_48 0x5
> +#define ID_AA64MMFR0_PARANGE_52 0x6
> +
> +#ifdef CONFIG_ARM64_PA_BITS_52
> +#define ID_AA64MMFR0_PARANGE_MAX ID_AA64MMFR0_PARANGE_52
> +#else
> +#define ID_AA64MMFR0_PARANGE_MAX ID_AA64MMFR0_PARANGE_48
> +#endif
>
> /* id_aa64mmfr1 */
> #define ID_AA64MMFR1_PAN_SHIFT 20
> diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
> index 3f9615582377..f731a48bd9f1 100644
> --- a/arch/arm64/kvm/hyp-init.S
> +++ b/arch/arm64/kvm/hyp-init.S
> @@ -90,11 +90,9 @@ __do_hyp_init:
> bfi x4, x5, TCR_T0SZ_OFFSET, TCR_TxSZ_WIDTH
> #endif
> /*
> - * Read the PARange bits from ID_AA64MMFR0_EL1 and set the PS bits in
> - * TCR_EL2.
> + * Set the PS bits in TCR_EL2.
> */
> - mrs x5, ID_AA64MMFR0_EL1
> - bfi x4, x5, #16, #3
> + tcr_set_pa_size x4, #16, x5, x6
>
> msr tcr_el2, x4
>
> diff --git a/arch/arm64/kvm/hyp/s2-setup.c b/arch/arm64/kvm/hyp/s2-setup.c
> index a81f5e10fc8c..603e1ee83e89 100644
> --- a/arch/arm64/kvm/hyp/s2-setup.c
> +++ b/arch/arm64/kvm/hyp/s2-setup.c
> @@ -32,6 +32,8 @@ u32 __hyp_text __init_stage2_translation(void)
> * PS is only 3. Fortunately, bit 19 is RES0 in VTCR_EL2...
> */
> parange = read_sysreg(id_aa64mmfr0_el1) & 7;
> + if (parange > ID_AA64MMFR0_PARANGE_MAX)
> + parange = ID_AA64MMFR0_PARANGE_MAX;
> val |= parange << 16;
>
> /* Compute the actual PARange... */
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index 95233dfc4c39..c10c6c180961 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -228,11 +228,9 @@ ENTRY(__cpu_setup)
> tcr_set_idmap_t0sz x10, x9
>
> /*
> - * Read the PARange bits from ID_AA64MMFR0_EL1 and set the IPS bits in
> - * TCR_EL1.
> + * Set the IPS bits in TCR_EL1.
> */
> - mrs x9, ID_AA64MMFR0_EL1
> - bfi x10, x9, #32, #3
> + tcr_set_pa_size x10, #32, x5, x6
> #ifdef CONFIG_ARM64_HW_AFDBM
> /*
> * Hardware update of the Access and Dirty bits.
>
Other than the nits above:
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* DT dtc warnings
From: Alexandre Belloni @ 2017-12-14 18:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJKCzjx3zNigu_0T=Ku=_P2SQEjTx=uVbvr_QxJQR7kYg@mail.gmail.com>
Hi Rob,
On 14/12/2017 at 12:21:06 -0600, Rob Herring wrote:
> Hi all,
>
> Below is a current list of ARM boards with more than 40 dtc warnings
> when building with W=1. There's a treewide patch in flight to fix some
> unit-address warnings[1], so those aren't included here. The list is
> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
> the top of the list and have been for some time (though having
> multiple boards for an SoC can cause lots of duplicated warnings).
>
> Please help fix these. More checks are being added[2].
>
For the at91 ones, IIRC, they are coming from the clock binding and we
will have to break the ABI to fix it. This is not something we wanted to
do before 4.14 but it will happen at some point.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Laurent Pinchart @ 2017-12-14 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513276340.27409.77.camel@perches.com>
Hi Joe,
On Thursday, 14 December 2017 20:32:20 EET Joe Perches wrote:
> On Thu, 2017-12-14 at 20:28 +0200, Laurent Pinchart wrote:
> > On Thursday, 14 December 2017 19:05:27 EET Mauro Carvalho Chehab wrote:
> >> Em Fri, 8 Dec 2017 18:05:37 +0530 Dhaval Shah escreveu:
> >>> SPDX-License-Identifier is used for the Xilinx Video IP and
> >>> related drivers.
> >>>
> >>> Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
> >>
> >> Hi Dhaval,
> >>
> >> You're not listed as one of the Xilinx driver maintainers. I'm afraid
> >> that, without their explicit acks, sent to the ML, I can't accept a patch
> >> touching at the driver's license tags.
> >
> > The patch doesn't change the license, I don't see why it would cause any
> > issue. Greg isn't listed as the maintainer or copyright holder of any of
> > the 10k+ files to which he added an SPDX license header in the last
> > kernel release.
>
> Adding a comment line that describes an implicit or
> explicit license is different than removing the license
> text itself.
The SPDX license header is meant to be equivalent to the license text. The
only reason why the large SPDX patch didn't touch the whole kernel in one go
was that it was easier to split in in multiple chunks. This is no different
than not including the full GPL license in every header file but only pointing
to it through its name and reference, as every kernel source file does.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] arm64: dts: Remove leading 0x and 0s from bindings notation
From: Rob Herring @ 2017-12-14 18:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513276199.27409.75.camel@perches.com>
On Thu, Dec 14, 2017 at 12:29 PM, Joe Perches <joe@perches.com> wrote:
> On Thu, 2017-12-14 at 19:03 +0100, Matthias Brugger wrote:
>>
>> On 12/14/2017 05:53 PM, Mathieu Malaterre wrote:
>> [...]
>> > diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> > index 26396ef53bde..0446b122a6e2 100644
>> > --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> > +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
>> > @@ -249,7 +249,7 @@
>> > reg = <0 0x10005000 0 0x1000>;
>> > };
>> >
>> > - pio: pinctrl at 0x10005000 {
>> > + pio: pinctrl at 10005000 {
>> > compatible = "mediatek,mt8173-pinctrl";
>> > reg = <0 0x1000b000 0 0x1000>;
>> > mediatek,pctl-regmap = <&syscfg_pctl_a>;
>>
>> Acked-by: Matthias Brugger <matthias.bgg@gmail.com>
>
> Should all of these be fixed?
>
> $ git grep -P "^\s*\w+:\s*[\w\-]+ at 0[xX]" -- "*.dts*" | wc -l
> 69
Yes, there's patches for all arches.
>
> Is this a pattern that should be added to checkpatch?
No, because dtc provides the warnings.
Rob
^ permalink raw reply
* [PATCH 03/10] arm64: handle 52-bit addresses in TTBR
From: Marc Zyngier @ 2017-12-14 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513184845-8711-4-git-send-email-kristina.martsenko@arm.com>
On 13/12/17 17:07, Kristina Martsenko wrote:
> The top 4 bits of a 52-bit physical address are positioned at bits 2..5
> in the TTBR registers. Introduce a couple of macros to move the bits
> there, and change all TTBR writers to use them.
>
> Leave TTBR0 PAN code unchanged, to avoid complicating it. A system with
> 52-bit PA will have PAN anyway (because it's ARMv8.1 or later), and a
> system without 52-bit PA can only use up to 48-bit PAs. A later patch in
> this series will add a kconfig dependency to ensure PAN is configured.
>
> In addition, when using 52-bit PA there is a special alignment
> requirement on the top-level table. We don't currently have any VA_BITS
> configuration that would violate the requirement, but one could be added
> in the future, so add a compile-time BUG_ON to check for it.
>
> Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
> ---
> arch/arm/include/asm/kvm_mmu.h | 2 ++
> arch/arm64/include/asm/assembler.h | 16 ++++++++++++++++
> arch/arm64/include/asm/kvm_mmu.h | 2 ++
> arch/arm64/include/asm/mmu_context.h | 2 +-
> arch/arm64/include/asm/pgtable-hwdef.h | 9 +++++++++
> arch/arm64/include/asm/pgtable.h | 6 ++++++
> arch/arm64/kernel/head.S | 6 ++++--
> arch/arm64/kernel/hibernate-asm.S | 12 +++++++-----
> arch/arm64/kernel/hibernate.c | 2 +-
> arch/arm64/kvm/hyp-init.S | 3 ++-
> arch/arm64/mm/pgd.c | 8 ++++++++
> arch/arm64/mm/proc.S | 13 ++++++++-----
> virt/kvm/arm/arm.c | 2 +-
> 13 files changed, 67 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index fa6f2174276b..8dbec683638b 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -221,6 +221,8 @@ static inline unsigned int kvm_get_vmid_bits(void)
> return 8;
> }
>
> +#define kvm_phys_to_vttbr(addr) (addr)
> +
> #endif /* !__ASSEMBLY__ */
>
> #endif /* __ARM_KVM_MMU_H__ */
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index 6cddf12a0250..2058fd864bfb 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -525,4 +525,20 @@ alternative_else_nop_endif
> #endif
> .endm
>
> +/*
> + * Arrange a physical address in a TTBR register, taking care of 52-bit
> + * addresses.
> + *
> + * phys: physical address, preserved
> + * ttbr: returns the TTBR value
> + */
> + .macro phys_to_ttbr, phys, ttbr
> +#ifdef CONFIG_ARM64_PA_BITS_52
> + orr \ttbr, \phys, \phys, lsr #46
> + and \ttbr, \ttbr, #TTBR_BADDR_MASK_52
> +#else
> + mov \ttbr, \phys
> +#endif
> + .endm
> +
> #endif /* __ASM_ASSEMBLER_H */
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index 672c8684d5c2..747bfff92948 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -309,5 +309,7 @@ static inline unsigned int kvm_get_vmid_bits(void)
> return (cpuid_feature_extract_unsigned_field(reg, ID_AA64MMFR1_VMIDBITS_SHIFT) == 2) ? 16 : 8;
> }
>
> +#define kvm_phys_to_vttbr(addr) phys_to_ttbr(addr)
> +
> #endif /* __ASSEMBLY__ */
> #endif /* __ARM64_KVM_MMU_H__ */
> diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> index 9d155fa9a507..accc2ff32a0e 100644
> --- a/arch/arm64/include/asm/mmu_context.h
> +++ b/arch/arm64/include/asm/mmu_context.h
> @@ -51,7 +51,7 @@ static inline void contextidr_thread_switch(struct task_struct *next)
> */
> static inline void cpu_set_reserved_ttbr0(void)
> {
> - unsigned long ttbr = __pa_symbol(empty_zero_page);
> + unsigned long ttbr = phys_to_ttbr(__pa_symbol(empty_zero_page));
>
> write_sysreg(ttbr, ttbr0_el1);
> isb();
> diff --git a/arch/arm64/include/asm/pgtable-hwdef.h b/arch/arm64/include/asm/pgtable-hwdef.h
> index eb0c2bd90de9..2b3104af79d0 100644
> --- a/arch/arm64/include/asm/pgtable-hwdef.h
> +++ b/arch/arm64/include/asm/pgtable-hwdef.h
> @@ -16,6 +16,8 @@
> #ifndef __ASM_PGTABLE_HWDEF_H
> #define __ASM_PGTABLE_HWDEF_H
>
> +#include <asm/memory.h>
> +
> /*
> * Number of page-table levels required to address 'va_bits' wide
> * address, without section mapping. We resolve the top (va_bits - PAGE_SHIFT)
> @@ -277,4 +279,11 @@
> #define TCR_HA (UL(1) << 39)
> #define TCR_HD (UL(1) << 40)
>
> +/*
> + * TTBR
> + */
> +#ifdef CONFIG_ARM64_PA_BITS_52
> +#define TTBR_BADDR_MASK_52 (((UL(1) << 46) - 1) << 2)
This really hurts by brain. How about
#define TTBR_BADDR_MASK_52 GENMASK_UL(47, 2)
instead, together with a comment saying that TTBR[1] is RES0.
> +#endif
> +
> #endif
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 149d05fb9421..93677b9db947 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -733,6 +733,12 @@ static inline void update_mmu_cache(struct vm_area_struct *vma,
> #define kc_vaddr_to_offset(v) ((v) & ~VA_START)
> #define kc_offset_to_vaddr(o) ((o) | VA_START)
>
> +#ifdef CONFIG_ARM64_PA_BITS_52
> +#define phys_to_ttbr(addr) (((addr) | ((addr) >> 46)) & TTBR_BADDR_MASK_52)
> +#else
> +#define phys_to_ttbr(addr) (addr)
> +#endif
> +
> #endif /* !__ASSEMBLY__ */
>
> #endif /* __ASM_PGTABLE_H */
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 67e86a0f57ac..0addea3760a6 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -679,8 +679,10 @@ ENTRY(__enable_mmu)
> update_early_cpu_boot_status 0, x1, x2
> adrp x1, idmap_pg_dir
> adrp x2, swapper_pg_dir
> - msr ttbr0_el1, x1 // load TTBR0
> - msr ttbr1_el1, x2 // load TTBR1
> + phys_to_ttbr x1, x3
> + phys_to_ttbr x2, x4
> + msr ttbr0_el1, x3 // load TTBR0
> + msr ttbr1_el1, x4 // load TTBR1
> isb
> msr sctlr_el1, x0
> isb
> diff --git a/arch/arm64/kernel/hibernate-asm.S b/arch/arm64/kernel/hibernate-asm.S
> index e56d848b6466..84f5d52fddda 100644
> --- a/arch/arm64/kernel/hibernate-asm.S
> +++ b/arch/arm64/kernel/hibernate-asm.S
> @@ -33,12 +33,14 @@
> * Even switching to our copied tables will cause a changed output address at
> * each stage of the walk.
> */
> -.macro break_before_make_ttbr_switch zero_page, page_table
> - msr ttbr1_el1, \zero_page
> +.macro break_before_make_ttbr_switch zero_page, page_table, tmp
> + phys_to_ttbr \zero_page, \tmp
> + msr ttbr1_el1, \tmp
> isb
> tlbi vmalle1
> dsb nsh
> - msr ttbr1_el1, \page_table
> + phys_to_ttbr \page_table, \tmp
> + msr ttbr1_el1, \tmp
> isb
> .endm
>
> @@ -78,7 +80,7 @@ ENTRY(swsusp_arch_suspend_exit)
> * We execute from ttbr0, change ttbr1 to our copied linear map tables
> * with a break-before-make via the zero page
> */
> - break_before_make_ttbr_switch x5, x0
> + break_before_make_ttbr_switch x5, x0, x6
>
> mov x21, x1
> mov x30, x2
> @@ -109,7 +111,7 @@ ENTRY(swsusp_arch_suspend_exit)
> dsb ish /* wait for PoU cleaning to finish */
>
> /* switch to the restored kernels page tables */
> - break_before_make_ttbr_switch x25, x21
> + break_before_make_ttbr_switch x25, x21, x6
>
> ic ialluis
> dsb ish
> diff --git a/arch/arm64/kernel/hibernate.c b/arch/arm64/kernel/hibernate.c
> index 3009b8b80f08..efbf6dbd93c8 100644
> --- a/arch/arm64/kernel/hibernate.c
> +++ b/arch/arm64/kernel/hibernate.c
> @@ -264,7 +264,7 @@ static int create_safe_exec_page(void *src_start, size_t length,
> */
> cpu_set_reserved_ttbr0();
> local_flush_tlb_all();
> - write_sysreg(virt_to_phys(pgd), ttbr0_el1);
> + write_sysreg(phys_to_ttbr(virt_to_phys(pgd)), ttbr0_el1);
> isb();
>
> *phys_dst_addr = virt_to_phys((void *)dst);
> diff --git a/arch/arm64/kvm/hyp-init.S b/arch/arm64/kvm/hyp-init.S
> index f731a48bd9f1..a99718f32af9 100644
> --- a/arch/arm64/kvm/hyp-init.S
> +++ b/arch/arm64/kvm/hyp-init.S
> @@ -63,7 +63,8 @@ __do_hyp_init:
> cmp x0, #HVC_STUB_HCALL_NR
> b.lo __kvm_handle_stub_hvc
>
> - msr ttbr0_el2, x0
> + phys_to_ttbr x0, x4
> + msr ttbr0_el2, x4
>
> mrs x4, tcr_el1
> ldr x5, =TCR_EL2_MASK
> diff --git a/arch/arm64/mm/pgd.c b/arch/arm64/mm/pgd.c
> index 051e71ec3335..289f9113a27a 100644
> --- a/arch/arm64/mm/pgd.c
> +++ b/arch/arm64/mm/pgd.c
> @@ -49,6 +49,14 @@ void __init pgd_cache_init(void)
> if (PGD_SIZE == PAGE_SIZE)
> return;
>
> +#ifdef CONFIG_ARM64_PA_BITS_52
> + /*
> + * With 52-bit physical addresses, the architecture requires the
> + * top-level table to be aligned to at least 64 bytes.
> + */
> + BUILD_BUG_ON(PGD_SIZE < 64);
> +#endif
> +
> /*
> * Naturally aligned pgds required by the architecture.
> */
> diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
> index c10c6c180961..820afe2d0d91 100644
> --- a/arch/arm64/mm/proc.S
> +++ b/arch/arm64/mm/proc.S
> @@ -138,10 +138,11 @@ ENDPROC(cpu_do_resume)
> * - pgd_phys - physical address of new TTB
> */
> ENTRY(cpu_do_switch_mm)
> - pre_ttbr0_update_workaround x0, x2, x3
> + phys_to_ttbr x0, x2
> + pre_ttbr0_update_workaround x2, x3, x4
> mmid x1, x1 // get mm->context.id
> - bfi x0, x1, #48, #16 // set the ASID
> - msr ttbr0_el1, x0 // set TTBR0
> + bfi x2, x1, #48, #16 // set the ASID
> + msr ttbr0_el1, x2 // set TTBR0
> isb
> post_ttbr0_update_workaround
> ret
> @@ -158,14 +159,16 @@ ENTRY(idmap_cpu_replace_ttbr1)
> save_and_disable_daif flags=x2
>
> adrp x1, empty_zero_page
> - msr ttbr1_el1, x1
> + phys_to_ttbr x1, x3
> + msr ttbr1_el1, x3
> isb
>
> tlbi vmalle1
> dsb nsh
> isb
>
> - msr ttbr1_el1, x0
> + phys_to_ttbr x0, x3
> + msr ttbr1_el1, x3
> isb
>
> restore_daif x2
> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
> index 6b60c98a6e22..c8d49879307f 100644
> --- a/virt/kvm/arm/arm.c
> +++ b/virt/kvm/arm/arm.c
> @@ -509,7 +509,7 @@ static void update_vttbr(struct kvm *kvm)
> pgd_phys = virt_to_phys(kvm->arch.pgd);
> BUG_ON(pgd_phys & ~VTTBR_BADDR_MASK);
> vmid = ((u64)(kvm->arch.vmid) << VTTBR_VMID_SHIFT) & VTTBR_VMID_MASK(kvm_vmid_bits);
> - kvm->arch.vttbr = pgd_phys | vmid;
> + kvm->arch.vttbr = kvm_phys_to_vttbr(pgd_phys) | vmid;
>
> spin_unlock(&kvm_vmid_lock);
> }
>
Otherwise:
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Joe Perches @ 2017-12-14 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <16301043.Lbu0ahMgBI@avalon>
On Thu, 2017-12-14 at 20:37 +0200, Laurent Pinchart wrote:
> Hi Joe,
Hi Laurent.
> On Thursday, 14 December 2017 20:32:20 EET Joe Perches wrote:
> > Adding a comment line that describes an implicit or
> > explicit license is different than removing the license
> > text itself.
>
> The SPDX license header is meant to be equivalent to the license text.
I understand that.
At a minimum, removing BSD license text is undesirable
as that license states:
* * Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
etc...
> The only reason why the large SPDX patch didn't touch the whole kernel in one go
> was that it was easier to split in in multiple chunks.
Not really, it was scripted.
> This is no different
> than not including the full GPL license in every header file but only pointing
> to it through its name and reference, as every kernel source file does.
Not every kernel source file had a license text
or a reference to another license file.
^ permalink raw reply
* DT dtc warnings
From: Rob Herring @ 2017-12-14 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214183642.GF2559@piout.net>
On Thu, Dec 14, 2017 at 12:36 PM, Alexandre Belloni
<alexandre.belloni@free-electrons.com> wrote:
> Hi Rob,
>
> On 14/12/2017 at 12:21:06 -0600, Rob Herring wrote:
>> Hi all,
>>
>> Below is a current list of ARM boards with more than 40 dtc warnings
>> when building with W=1. There's a treewide patch in flight to fix some
>> unit-address warnings[1], so those aren't included here. The list is
>> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
>> the top of the list and have been for some time (though having
>> multiple boards for an SoC can cause lots of duplicated warnings).
>>
>> Please help fix these. More checks are being added[2].
>>
>
> For the at91 ones, IIRC, they are coming from the clock binding and we
> will have to break the ABI to fix it. This is not something we wanted to
> do before 4.14 but it will happen at some point.
Looks like they are just missing unit-address. How does adding a
unit-address break the ABI? Though, aren't you planning to change from
a node per clock to clock controller node(s)? If so, then fixing when
doing that is fine.
Rob
^ permalink raw reply
* [PATCH] arm64: fix CONFIG_DEBUG_WX address reporting
From: Laura Abbott @ 2017-12-14 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213115835.pkt3fyqcbk7lgdeb@lakrids.cambridge.arm.com>
On 12/13/2017 03:58 AM, Mark Rutland wrote:
> On Tue, Dec 12, 2017 at 03:30:00PM -0800, Laura Abbott wrote:
>> On 12/12/2017 02:57 PM, Timur Tabi wrote:
>>> We have a 4.10-based kernel that occasionally displays an insecure W+X mapping (courtesy of CONFIG_DEBUG_WX):
>>>
>>> [??? 7.151680] arm64/mm: Found insecure W+X mapping at address 0000345a049d2000/0x345a049d2000
>>> ...
>>> [??? 7.435481] Checked W+X mappings: FAILED, 4 W+X pages found, 0 non-UXN pages found
>>>
>>> The number of actual W+X pages varies, e.g. sometimes it says 6 pages.
>>>
>>> How do I go about debugging this? How do I identify the source of 0000345a049d2000?
>>
>> That's a funny address. The check was written to scan the init_mm
>> page table but that's not a kernel address on arm64. It almost looks
>> like something set up a userspace mapping very early in the boot process?
>
> Whoops; I think we forgot to apply the VA_START offset in
> ptdump_check_wx(), so we report the address wrong.
>
> Does the below (untested) patch result in a sane-looking report?
>
> Thanks,
> Mark.
>
> ---->8----
> From b3021b76b9ea1e65388b38dfe622ea956cb18647 Mon Sep 17 00:00:00 2001
> From: Mark Rutland <mark.rutland@arm.com>
> Date: Wed, 13 Dec 2017 11:45:42 +0000
> Subject: [PATCH] arm64: fix CONFIG_DEBUG_WX address reporting
>
> In ptdump_check_wx(), we pass walk_pgd() a start address of 0 (rather
> than VA_START) for the init_mm. This means that any reported W&X
> addresses are offset by VA_START, which is unexepcted and confusing.
>
> Let's fix this by telling the ptdump code that we're walking init_mm
> starting at VA_START. We don't need to update the addr_markers, since
> these are still valid bounds regardless.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> Cc: Kees Cook <keescook@chromium.org>
> Cc: Laura Abbott <labbott@redhat.com>
> Reported-by: Timur Tabi <timur@codeaurora.org>
> ---
> arch/arm64/mm/dump.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index ca74a2aace42..7b60d62ac593 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -389,7 +389,7 @@ void ptdump_check_wx(void)
> .check_wx = true,
> };
>
> - walk_pgd(&st, &init_mm, 0);
> + walk_pgd(&st, &init_mm, VA_START);
> note_page(&st, 0, 0, 0);
> if (st.wx_pages || st.uxn_pages)
> pr_warn("Checked W+X mappings: FAILED, %lu W+X pages found, %lu non-UXN pages found\n",
>
This looks better from my tests so you are welcome to add
Tested-by: Laura Abbott <labbott@redhat.com>
While we're fixing this up, do you want to drop the %p from the
"Found insecure W+X" message from above since pointer hashing
renders it kind of pointless or switch it to %px?
Thanks,
Laura
^ permalink raw reply
* [PATCH] arm64: fix CONFIG_DEBUG_WX address reporting
From: Timur Tabi @ 2017-12-14 19:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171213115835.pkt3fyqcbk7lgdeb@lakrids.cambridge.arm.com>
On 12/13/2017 05:58 AM, Mark Rutland wrote:
> Whoops; I think we forgot to apply the VA_START offset in
> ptdump_check_wx(), so we report the address wrong.
>
> Does the below (untested) patch result in a sane-looking report?
[ 10.977304] arm64/mm: Found insecure W+X mapping at address
ffff190621232000/0xffff190621232000
I can reproduce the problem after 2-3 reboots. When it happens, I get a
different pair of addresses, but they all look like these.
I'm not sure what to do next, however.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Laurent Pinchart @ 2017-12-14 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513277679.27409.83.camel@perches.com>
Hi Joe,
(CC'ing Greg and adding context for easier understanding)
On Thursday, 14 December 2017 20:54:39 EET Joe Perches wrote:
> On Thu, 2017-12-14 at 20:37 +0200, Laurent Pinchart wrote:
> > On Thursday, 14 December 2017 20:32:20 EET Joe Perches wrote:
> >> On Thu, 2017-12-14 at 20:28 +0200, Laurent Pinchart wrote:
> >>> On Thursday, 14 December 2017 19:05:27 EET Mauro Carvalho Chehab wrote:
> >>>> Em Fri, 8 Dec 2017 18:05:37 +0530 Dhaval Shah escreveu:
> >>>>> SPDX-License-Identifier is used for the Xilinx Video IP and
> >>>>> related drivers.
> >>>>>
> >>>>> Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
> >>>>
> >>>> Hi Dhaval,
> >>>>
> >>>> You're not listed as one of the Xilinx driver maintainers. I'm afraid
> >>>> that, without their explicit acks, sent to the ML, I can't accept a
> >>>> patch touching at the driver's license tags.
> >>>
> >>> The patch doesn't change the license, I don't see why it would cause
> >>> any issue. Greg isn't listed as the maintainer or copyright holder of
> >>> any of the 10k+ files to which he added an SPDX license header in the
> >>> last kernel release.\0\0\0
> >>
> >> Adding a comment line that describes an implicit or
> >> explicit license is different than removing the license
> >> text itself.
> >
> > The SPDX license header is meant to be equivalent to the license text.
>
> I understand that.
> At a minimum, removing BSD license text is undesirable
> as that license states:
>
> * * Redistributions of source code must retain the above copyright
> * notice, this list of conditions and the following disclaimer.
> etc...
But this patch only removes the following text:
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
and replaces it by the corresponding SPDX header.
> > The only reason why the large SPDX patch didn't touch the whole kernel in
> > one go was that it was easier to split in in multiple chunks.
>
> Not really, it was scripted.
But still manually reviewed as far as I know.
> > This is no different than not including the full GPL license in every
> > header file but only pointing to it through its name and reference, as
> > every kernel source file does.
>
> Not every kernel source file had a license text
> or a reference to another license file.
Correct, but the files touched by this patch do.
This issue is in no way specific to linux-media and should be decided upon at
the top level, not on a per-subsystem basis. Greg, could you comment on this ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* DT dtc warnings
From: Alexandre Belloni @ 2017-12-14 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqKqiyCb8s9cyM-LdZv+hyMjv2ZpfGZmyy9_+Wrd7-qF8g@mail.gmail.com>
On 14/12/2017 at 13:00:07 -0600, Rob Herring wrote:
> On Thu, Dec 14, 2017 at 12:36 PM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
> > Hi Rob,
> >
> > On 14/12/2017 at 12:21:06 -0600, Rob Herring wrote:
> >> Hi all,
> >>
> >> Below is a current list of ARM boards with more than 40 dtc warnings
> >> when building with W=1. There's a treewide patch in flight to fix some
> >> unit-address warnings[1], so those aren't included here. The list is
> >> grouped by maintainer. AT91, Exynos, and Allwinner continue to be at
> >> the top of the list and have been for some time (though having
> >> multiple boards for an SoC can cause lots of duplicated warnings).
> >>
> >> Please help fix these. More checks are being added[2].
> >>
> >
> > For the at91 ones, IIRC, they are coming from the clock binding and we
> > will have to break the ABI to fix it. This is not something we wanted to
> > do before 4.14 but it will happen at some point.
>
> Looks like they are just missing unit-address. How does adding a
> unit-address break the ABI? Though, aren't you planning to change from
> a node per clock to clock controller node(s)? If so, then fixing when
> doing that is fine.
Adding the unit-address breaks the lookup of the clocks unless you want
to have nodes named prog0 at 0, prog1 at 1, pck0 at 8, etc...
I don't think it is worth the hassle going through all the dtsi to do
that.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 1/3] dt-bindings: chosen: Add clocksource and clockevent selection
From: Boris Brezillon @ 2017-12-14 20:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqLm5n6s=cr2hBZp4H9pDPKHUOPWs94JMWYFYJ3hsMMxZQ@mail.gmail.com>
Hi Rob,
On Wed, 13 Dec 2017 16:57:50 -0600
Rob Herring <robh+dt@kernel.org> wrote:
> On Wed, Dec 13, 2017 at 12:53 PM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
> > The clocksource and clockevent timer are probed early in the boot process.
> > At that time it is difficult for linux to know whether a particular timer
> > can be used as the clocksource or the clockevent or by another driver,
> > especially when they are all identical or have similar features.
>
> If all identical, then it shouldn't matter. "similar" means some
> difference. Describe those differences.
We had this discussion already. Those timers might be connected to
external pins and may serve the role of PWM generators or capture
devices. We can also chain timers and provide a clocksource with a
better resolution or one that wraps less often. In the end it's all
about how the user plans to use its system, and this has to be
described somehow. Assuming that the software can decide by itself
which timer should be used or how many of them should be chained is
just an utopia.
>
> > Until now, multiple strategies have been used to solve that:
> > - use Kconfig option as MXC_USE_EPIT or ATMEL_TCB_CLKSRC_BLOCK
>
> Compile time probably means only one option is really used.
Compile time selection prevents using the same kernel for different
boards (in other words, no multi-v7), so not really an option here.
>
> > - use a kernel parameter as the "clocksource" early_param in mach-omap2
>
> Yeah, OMAP was one of the previous times this came up and also
> attempted something like this. This parameter predates selecting
> timers based on features described in DT. Look at commit
> 2eb03937df3ebc (ARM: OMAP3: Update clocksource timer selection).
Then, would you accept to have a property saying that a specific timer
is a free-running timer (suitable for clocksource) or a programmable
timer (suitable for clkevent)? Or are you saying that you don't like the
way timers are differentiated on omap?
>
> > - registering the first seen timer as a clockevent and the second one as
> > a clocksource as in rk_timer_init or dw_apb_timer_init
> >
> > Add a linux,clocksource and a linux,clockevent node in chosen with a timer
> > property pointing to the timer to use. Other properties, like the targeted
> > precision may be added later.
>
> Open ended expansion of this does not help convince me it is needed.
It's not an open ended expansion, we're just trying to find a way to
describe which timer blocks should be used as free running timers
(clksource) and which one should be used as programmable timers
(clkevent). Automatically selecting timer blocks to assign to the
clkevent or clocksource is not so easy (as has been explained earlier)
because at the time the system registers its clksource/clkevent devices
we might not have all the necessary information to know which timer
blocks will be reserved for other usage later on. The use case I have
in mind is DT overlays, where one of the overlay is using a timer as a
PWM generator. If the clkevent or clksource has already claimed the
timer connected to the pins the overlay is using, then we're screwed,
and there's no way the system can know that ahead of time except by
pre-assigning a timer to the clksource or clkevent feature.
So really, we need a way to assign a specific timer to a specific
feature. You've refused the different proposals we made so far, so
what's your alternative? I mean a real alternative that solve the "an
auto-selected timer might be claimed by another driver at some point"
problem.
Thanks,
Boris
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Greg KH @ 2017-12-14 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2967655.MWOA0IsQOS@avalon>
On Thu, Dec 14, 2017 at 09:05:27PM +0200, Laurent Pinchart wrote:
> Hi Joe,
>
> (CC'ing Greg and adding context for easier understanding)
>
> On Thursday, 14 December 2017 20:54:39 EET Joe Perches wrote:
> > On Thu, 2017-12-14 at 20:37 +0200, Laurent Pinchart wrote:
> > > On Thursday, 14 December 2017 20:32:20 EET Joe Perches wrote:
> > >> On Thu, 2017-12-14 at 20:28 +0200, Laurent Pinchart wrote:
> > >>> On Thursday, 14 December 2017 19:05:27 EET Mauro Carvalho Chehab wrote:
> > >>>> Em Fri, 8 Dec 2017 18:05:37 +0530 Dhaval Shah escreveu:
> > >>>>> SPDX-License-Identifier is used for the Xilinx Video IP and
> > >>>>> related drivers.
> > >>>>>
> > >>>>> Signed-off-by: Dhaval Shah <dhaval23031987@gmail.com>
> > >>>>
> > >>>> Hi Dhaval,
> > >>>>
> > >>>> You're not listed as one of the Xilinx driver maintainers. I'm afraid
> > >>>> that, without their explicit acks, sent to the ML, I can't accept a
> > >>>> patch touching at the driver's license tags.
> > >>>
> > >>> The patch doesn't change the license, I don't see why it would cause
> > >>> any issue. Greg isn't listed as the maintainer or copyright holder of
> > >>> any of the 10k+ files to which he added an SPDX license header in the
> > >>> last kernel release.
> > >> Adding a comment line that describes an implicit or
> > >> explicit license is different than removing the license
> > >> text itself.
> > >
> > > The SPDX license header is meant to be equivalent to the license text.
> >
> > I understand that.
> > At a minimum, removing BSD license text is undesirable
> > as that license states:
> >
> > * * Redistributions of source code must retain the above copyright
> > * notice, this list of conditions and the following disclaimer.
> > etc...
>
> But this patch only removes the following text:
>
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
>
> and replaces it by the corresponding SPDX header.
>
> > > The only reason why the large SPDX patch didn't touch the whole kernel in
> > > one go was that it was easier to split in in multiple chunks.
> >
> > Not really, it was scripted.
>
> But still manually reviewed as far as I know.
>
> > > This is no different than not including the full GPL license in every
> > > header file but only pointing to it through its name and reference, as
> > > every kernel source file does.
> >
> > Not every kernel source file had a license text
> > or a reference to another license file.
>
> Correct, but the files touched by this patch do.
>
> This issue is in no way specific to linux-media and should be decided upon at
> the top level, not on a per-subsystem basis. Greg, could you comment on this ?
Comment on what exactly? I don't understand the problem here, care to
summarize it?
thanks,
greg k-h
^ 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