* [PATCH v2 19/19] ARM: dts: aspeed-plametto: Add flash layout
From: Cédric Le Goater @ 2017-12-18 9:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215062443.23059-20-joel@jms.id.au>
On 12/15/2017 07:24 AM, Joel Stanley wrote:
> The OpenBMC flash layout is used by Palmetto systems.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: C?dric Le Goater <clg@kaod.org>
> ---
> arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> index a8f0c046e83e..cc18137386f2 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> @@ -34,6 +34,7 @@
> status = "okay";
> m25p,fast-read;
> label = "bmc";
> +#include "openbmc-flash-layout.dtsi"
> };
> };
>
>
^ permalink raw reply
* [PATCH v2 11/19] ARM: dts: aspeed: Remove skeleton.dtsi
From: Cédric Le Goater @ 2017-12-18 9:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215062443.23059-12-joel@jms.id.au>
On 12/15/2017 07:24 AM, Joel Stanley wrote:
> We don't require it for any of the ASPEED systems.
Reviewed-by: C?dric Le Goater <clg@kaod.org>
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 1 -
> arch/arm/boot/dts/aspeed-g5.dtsi | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index b3580f37f507..2d7ac577d6b5 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -1,5 +1,4 @@
> // SPDX-License-Identifier: GPL-2.0
> -#include "skeleton.dtsi"
> #include <dt-bindings/clock/aspeed-clock.h>
> #include <dt-bindings/gpio/aspeed-gpio.h>
>
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 50766f0629f8..030a760696fd 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -1,5 +1,4 @@
> // SPDX-License-Identifier: GPL-2.0
> -#include "skeleton.dtsi"
> #include <dt-bindings/clock/aspeed-clock.h>
> #include <dt-bindings/gpio/aspeed-gpio.h>
>
>
^ permalink raw reply
* [PATCH v2 14/19] ARM: dts: aspeed: Sort ASPEED entries in makefile
From: Cédric Le Goater @ 2017-12-18 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215062443.23059-15-joel@jms.id.au>
On 12/15/2017 07:24 AM, Joel Stanley wrote:
> In preperation for adding more boards.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: C?dric Le Goater <clg@kaod.org>
> ---
> arch/arm/boot/dts/Makefile | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d0381e9caf21..5d1e9d37bf3a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1101,7 +1101,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> mt8127-moose.dtb \
> mt8135-evbp1.dtb
> dtb-$(CONFIG_ARCH_ZX) += zx296702-ad1.dtb
> -dtb-$(CONFIG_ARCH_ASPEED) += aspeed-bmc-opp-palmetto.dtb \
> - aspeed-bmc-opp-romulus.dtb \
> - aspeed-ast2500-evb.dtb
> +dtb-$(CONFIG_ARCH_ASPEED) += \
> + aspeed-ast2500-evb.dtb \
> + aspeed-bmc-opp-palmetto.dtb \
> + aspeed-bmc-opp-romulus.dtb
> endif
>
^ permalink raw reply
* [PATCH v2 12/19] ARM: dts: aspeed: Update license headers
From: Cédric Le Goater @ 2017-12-18 9:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215062443.23059-13-joel@jms.id.au>
On 12/15/2017 07:24 AM, Joel Stanley wrote:
> In b24413180f56 ("License cleanup: add SPDX GPL-2.0 license identifier
> to files with no license") these files had the GPL-2.0 licence added
> automatically. Update them to be GPL 2.0+ in line with other IBM kernel
> contributions.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: C?dric Le Goater <clg@kaod.org>
> ---
> arch/arm/boot/dts/aspeed-ast2500-evb.dts | 2 +-
> arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts | 2 +-
> arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts | 2 +-
> arch/arm/boot/dts/aspeed-g4.dtsi | 2 +-
> arch/arm/boot/dts/aspeed-g5.dtsi | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-ast2500-evb.dts b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> index 602bc10fdaf4..3e6f38e5d5d0 100644
> --- a/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> +++ b/arch/arm/boot/dts/aspeed-ast2500-evb.dts
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
> /dts-v1/;
>
> #include "aspeed-g5.dtsi"
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> index c786bc2f2919..a8f0c046e83e 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-palmetto.dts
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
> /dts-v1/;
>
> #include "aspeed-g4.dtsi"
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> index 8067793129ea..a7a9386f964d 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-romulus.dts
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
> /dts-v1/;
>
> #include "aspeed-g5.dtsi"
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 2d7ac577d6b5..9c175832babc 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
> #include <dt-bindings/clock/aspeed-clock.h>
> #include <dt-bindings/gpio/aspeed-gpio.h>
>
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 030a760696fd..360329eab7c3 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -1,4 +1,4 @@
> -// SPDX-License-Identifier: GPL-2.0
> +// SPDX-License-Identifier: GPL-2.0+
> #include <dt-bindings/clock/aspeed-clock.h>
> #include <dt-bindings/gpio/aspeed-gpio.h>
>
>
^ permalink raw reply
* [PATCH v2 13/19] ARM: dts: Add OpenBMC flash layout
From: Cédric Le Goater @ 2017-12-18 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215062443.23059-14-joel@jms.id.au>
On 12/15/2017 07:24 AM, Joel Stanley wrote:
> This is a layout used by OpenBMC systems. It describes the fixed flash
> layout of a 32MB mtd device.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: C?dric Le Goater <clg@kaod.org>
> ---
> arch/arm/boot/dts/openbmc-flash-layout.dtsi | 32 +++++++++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
> create mode 100644 arch/arm/boot/dts/openbmc-flash-layout.dtsi
>
> diff --git a/arch/arm/boot/dts/openbmc-flash-layout.dtsi b/arch/arm/boot/dts/openbmc-flash-layout.dtsi
> new file mode 100644
> index 000000000000..63ad8db7a431
> --- /dev/null
> +++ b/arch/arm/boot/dts/openbmc-flash-layout.dtsi
> @@ -0,0 +1,32 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + u-boot at 0 {
> + reg = <0x0 0x60000>;
> + label = "u-boot";
> + };
> +
> + u-boot-env at 60000 {
> + reg = <0x60000 0x20000>;
> + label = "u-boot-env";
> + };
> +
> + kernel at 80000 {
> + reg = <0x80000 0x440000>;
> + label = "kernel";
> + };
> +
> + rofs at 0c0000 {
> + reg = <0x4c0000 0x1740000>;
> + label = "rofs";
> + };
> +
> + rwfs at 1c00000 {
> + reg = <0x1c00000 0x400000>;
> + label = "rwfs";
> + };
> +};
>
^ permalink raw reply
* [PATCH v2 07/19] ARM: dts: aspeed: Add flash controller clocks
From: Cédric Le Goater @ 2017-12-18 9:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215062443.23059-8-joel@jms.id.au>
On 12/15/2017 07:24 AM, Joel Stanley wrote:
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: C?dric Le Goater <clg@kaod.org>
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 2 ++
> arch/arm/boot/dts/aspeed-g5.dtsi | 3 +++
> 2 files changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 2e3666d4fbeb..afac0ca0cb10 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -56,6 +56,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "aspeed,ast2400-fmc";
> + clocks = <&syscon ASPEED_CLK_AHB>;
> status = "disabled";
> interrupts = <19>;
> flash at 0 {
> @@ -71,6 +72,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "aspeed,ast2400-spi";
> + clocks = <&syscon ASPEED_CLK_AHB>;
> status = "disabled";
> flash at 0 {
> reg = < 0 >;
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> index 24bb2d16b900..f3689caf6fe2 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -56,6 +56,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "aspeed,ast2500-fmc";
> + clocks = <&syscon ASPEED_CLK_AHB>;
> status = "disabled";
> interrupts = <19>;
> flash at 0 {
> @@ -81,6 +82,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "aspeed,ast2500-spi";
> + clocks = <&syscon ASPEED_CLK_AHB>;
> status = "disabled";
> flash at 0 {
> reg = < 0 >;
> @@ -100,6 +102,7 @@
> #address-cells = <1>;
> #size-cells = <0>;
> compatible = "aspeed,ast2500-spi";
> + clocks = <&syscon ASPEED_CLK_AHB>;
> status = "disabled";
> flash at 0 {
> reg = < 0 >;
>
^ permalink raw reply
* [PATCH v2 06/19] ARM: dts: aspeed: Add watchdog clocks
From: Cédric Le Goater @ 2017-12-18 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215062443.23059-7-joel@jms.id.au>
On 12/15/2017 07:24 AM, Joel Stanley wrote:
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: C?dric Le Goater <clg@kaod.org>
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 2 ++
> arch/arm/boot/dts/aspeed-g5.dtsi | 3 +++
> 2 files changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index cf407b4db630..2e3666d4fbeb 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -177,11 +177,13 @@
> wdt1: watchdog at 1e785000 {
> compatible = "aspeed,ast2400-wdt";
> reg = <0x1e785000 0x1c>;
> + clocks = <&syscon ASPEED_CLK_APB>;
> };
>
> wdt2: watchdog at 1e785020 {
> compatible = "aspeed,ast2400-wdt";
> reg = <0x1e785020 0x1c>;
> + clocks = <&syscon ASPEED_CLK_APB>;
> };
>
> vuart: serial at 1e787000 {
> diff --git a/arch/arm/boot/dts/aspeed-g5.dtsi b/arch/arm/boot/dts/aspeed-g5.dtsi
> index ab26156d6822..24bb2d16b900 100644
> --- a/arch/arm/boot/dts/aspeed-g5.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g5.dtsi
> @@ -219,16 +219,19 @@
> wdt1: watchdog at 1e785000 {
> compatible = "aspeed,ast2500-wdt";
> reg = <0x1e785000 0x20>;
> + clocks = <&syscon ASPEED_CLK_APB>;
> };
>
> wdt2: watchdog at 1e785020 {
> compatible = "aspeed,ast2500-wdt";
> reg = <0x1e785020 0x20>;
> + clocks = <&syscon ASPEED_CLK_APB>;
> };
>
> wdt3: watchdog at 1e785040 {
> compatible = "aspeed,ast2500-wdt";
> reg = <0x1e785040 0x20>;
> + clocks = <&syscon ASPEED_CLK_APB>;
> status = "disabled";
> };
>
>
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: usb: add DT binding for RK3328 dwc3 controller
From: Felipe Balbi @ 2017-12-18 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1863083.H0I2rMmhUr@phil>
Hi,
Heiko Stuebner <heiko@sntech.de> writes:
> Hi Greg, Felipe,
>
> Am Montag, 4. Dezember 2017, 10:40:38 CET schrieb Heiko Stuebner:
>> From: William Wu <william.wu@rock-chips.com>
>>
>> Adds the device tree bindings description for RK3328 and
>> compatible USB DWC3 controller.
>>
>> Signed-off-by: William Wu <william.wu@rock-chips.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
>
> do you want to pick this patch with only the small dt-binding
> change or Ack it for me to pick up together with the actual
> devicetree changes in the other patches?
it seems best if you carry this one:
Acked-by: Felipe Balbi <felipe.balbi@linux.intel.com>
--
balbi
^ permalink raw reply
* [PATCH] ARM: dts: aspeed-g4: Correct VUART IRQ number
From: Cédric Le Goater @ 2017-12-18 9:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215053332.31690-1-joel@jms.id.au>
On 12/15/2017 06:33 AM, Joel Stanley wrote:
> This should have always been 8.
>
> Fixes: db4d6d9d80fa ("ARM: dts: aspeed: Correctly order UART nodes")
> Cc: stable at vger.kernel.org
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: C?dric Le Goater <clg@kaod.org>
> ---
> ARM maintainers, please include this fix for 4.15
>
> arch/arm/boot/dts/aspeed-g4.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index 45d815a86d42..de08d9045cb8 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -219,7 +219,7 @@
> compatible = "aspeed,ast2400-vuart";
> reg = <0x1e787000 0x40>;
> reg-shift = <2>;
> - interrupts = <10>;
> + interrupts = <8>;
> clocks = <&clk_uart>;
> no-loopback-test;
> status = "disabled";
>
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: Bhupesh SHARMA @ 2017-12-18 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218055356.mq4coiibh3frii54@fireball>
On Mon, Dec 18, 2017 at 11:24 AM, AKASHI Takahiro
<takahiro.akashi@linaro.org> wrote:
> On Mon, Dec 18, 2017 at 01:16:57PM +0800, Dave Young wrote:
>> kexec at fedoraproject... is for Fedora kexec scripts discussion, changed it
>> to kexec at lists.infradead.org
>>
>> Also add linux-acpi list
>
> Thank you.
>
>> On 12/18/17 at 02:31am, Bhupesh Sharma wrote:
>> > On Fri, Dec 15, 2017 at 3:05 PM, Ard Biesheuvel
>> > <ard.biesheuvel@linaro.org> wrote:
>> > > On 15 December 2017 at 09:59, AKASHI Takahiro
>> > > <takahiro.akashi@linaro.org> wrote:
>> > >> On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
>> > >>> On 13 December 2017 at 12:16, AKASHI Takahiro
>> > >>> <takahiro.akashi@linaro.org> wrote:
>> > >>> > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
>> > >>> >> On 13 December 2017 at 10:26, AKASHI Takahiro
>> > >>> >> <takahiro.akashi@linaro.org> wrote:
>> > >>> >> > Bhupesh, Ard,
>> > >>> >> >
>> > >>> >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
>> > >>> >> >> Hi Ard, Akashi
>> > >>> >> >>
>> > >>> >> > (snip)
>> > >>> >> >
>> > >>> >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
>> > >>> >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
>> > >>> >> >> identify its own usable memory and exclude, at its boot time, any
>> > >>> >> >> other memory areas that are part of the panicked kernel's memory.
>> > >>> >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
>> > >>> >> >> , for details)
>> > >>> >> >
>> > >>> >> > Right.
>> > >>> >> >
>> > >>> >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
>> > >>> >> >> with the crashkernel memory range:
>> > >>> >> >>
>> > >>> >> >> /* add linux,usable-memory-range */
>> > >>> >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
>> > >>> >> >> result = fdt_setprop_range(new_buf, nodeoffset,
>> > >>> >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
>> > >>> >> >> address_cells, size_cells);
>> > >>> >> >>
>> > >>> >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
>> > >>> >> >> , for details)
>> > >>> >> >>
>> > >>> >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
>> > >>> >> >> they are marked as System RAM or as RESERVED. As,
>> > >>> >> >> 'linux,usable-memory-range' dt node is patched up only with
>> > >>> >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
>> > >>> >> >>
>> > >>> >> >> 3). As a result when the crashkernel boots up it doesn't find this
>> > >>> >> >> ACPI memory and crashes while trying to access the same:
>> > >>> >> >>
>> > >>> >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
>> > >>> >> >> -r`.img --reuse-cmdline -d
>> > >>> >> >>
>> > >>> >> >> [snip..]
>> > >>> >> >>
>> > >>> >> >> Reserved memory range
>> > >>> >> >> 000000000e800000-000000002e7fffff (0)
>> > >>> >> >>
>> > >>> >> >> Coredump memory ranges
>> > >>> >> >> 0000000000000000-000000000e7fffff (0)
>> > >>> >> >> 000000002e800000-000000003961ffff (0)
>> > >>> >> >> 0000000039d40000-000000003ed2ffff (0)
>> > >>> >> >> 000000003ed60000-000000003fbfffff (0)
>> > >>> >> >> 0000001040000000-0000001ffbffffff (0)
>> > >>> >> >> 0000002000000000-0000002ffbffffff (0)
>> > >>> >> >> 0000009000000000-0000009ffbffffff (0)
>> > >>> >> >> 000000a000000000-000000affbffffff (0)
>> > >>> >> >>
>> > >>> >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
>> > >>> >> >> memory cap'ing passed to the crash kernel inside
>> > >>> >> >> 'arch/arm64/mm/init.c' (see below):
>> > >>> >> >>
>> > >>> >> >> static void __init fdt_enforce_memory_region(void)
>> > >>> >> >> {
>> > >>> >> >> struct memblock_region reg = {
>> > >>> >> >> .size = 0,
>> > >>> >> >> };
>> > >>> >> >>
>> > >>> >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
>> > >>> >> >>
>> > >>> >> >> if (reg.size)
>> > >>> >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
>> > >>> >> >> comment this out */
>> > >>> >> >> }
>> > >>> >> >
>> > >>> >> > Please just don't do that. It can cause a fatal damage on
>> > >>> >> > memory contents of the *crashed* kernel.
>> > >>> >> >
>> > >>> >> >> 5). Both the above temporary solutions fix the problem.
>> > >>> >> >>
>> > >>> >> >> 6). However exposing all System RAM regions to the crashkernel is not
>> > >>> >> >> advisable and may cause the crashkernel or some crashkernel drivers to
>> > >>> >> >> fail.
>> > >>> >> >>
>> > >>> >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
>> > >>> >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
>> > >>> >> >> kernel code and on the other hand the user-space 'kexec-tools' will
>> > >>> >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
>> > >>> >> >> dt node 'linux,usable-memory-range'
>> > >>> >> >
>> > >>> >> > I still don't understand why we need to carry over the information
>> > >>> >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
>> > >>> >> > such regions are free to be reused by the kernel after some point of
>> > >>> >> > initialization. Why does crash dump kernel need to know about them?
>> > >>> >> >
>> > >>> >>
>> > >>> >> Not really. According to the UEFI spec, they can be reclaimed after
>> > >>> >> the OS has initialized, i.e., when it has consumed the ACPI tables and
>> > >>> >> no longer needs them. Of course, in order to be able to boot a kexec
>> > >>> >> kernel, those regions needs to be preserved, which is why they are
>> > >>> >> memblock_reserve()'d now.
>> > >>> >
>> > >>> > For my better understandings, who is actually accessing such regions
>> > >>> > during boot time, uefi itself or efistub?
>> > >>> >
>> > >>>
>> > >>> No, only the kernel. This is where the ACPI tables are stored. For
>> > >>> instance, on QEMU we have
>> > >>>
>> > >>> ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
>> > >>> ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
>> > >>> 01000013)
>> > >>> ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
>> > >>> BXPC 00000001)
>> > >>> ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
>> > >>> BXPC 00000001)
>> > >>> ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
>> > >>> BXPC 00000001)
>> > >>> ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
>> > >>> BXPC 00000001)
>> > >>> ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
>> > >>> BXPC 00000001)
>> > >>> ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
>> > >>> BXPC 00000001)
>> > >>> ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
>> > >>> BXPC 00000001)
>> > >>>
>> > >>> covered by
>> > >>>
>> > >>> efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
>> > >>> ...
>> > >>> efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
>> > >>
>> > >> OK. I mistakenly understood those regions could be freed after exiting
>> > >> UEFI boot services.
>> > >>
>> > >>>
>> > >>> >> So it seems that kexec does not honour the memblock_reserve() table
>> > >>> >> when booting the next kernel.
>> > >>> >
>> > >>> > not really.
>> > >>> >
>> > >>> >> > (In other words, can or should we skip some part of ACPI-related init code
>> > >>> >> > on crash dump kernel?)
>> > >>> >> >
>> > >>> >>
>> > >>> >> I don't think so. And the change to the handling of ACPI reclaim
>> > >>> >> regions only revealed the bug, not created it (given that other
>> > >>> >> memblock_reserve regions may be affected as well)
>> > >>> >
>> > >>> > As whether we should honor such reserved regions over kexec'ing
>> > >>> > depends on each one's specific nature, we will have to take care one-by-one.
>> > >>> > As a matter of fact, no information about "reserved" memblocks is
>> > >>> > exposed to user space (via proc/iomem).
>> > >>> >
>> > >>>
>> > >>> That is why I suggested (somewhere in this thread?) to not expose them
>> > >>> as 'System RAM'. Do you think that could solve this?
>> > >>
>> > >> Memblock-reserv'ing them is necessary to prevent their corruption and
>> > >> marking them under another name in /proc/iomem would also be good in order
>> > >> not to allocate them as part of crash kernel's memory.
>> > >>
>> > >
>> > > I agree. However, this may not be entirely trivial, since iterating
>> > > over the memblock_reserved table and creating iomem entries may result
>> > > in collisions.
>> >
>> > I found a method (using the patch I shared earlier in this thread) to mark these
>> > entries as 'ACPI reclaim memory' ranges rather than System RAM or
>> > reserved regions.
>> >
>> > >> But I'm not still convinced that we should export them in useable-
>> > >> memory-range to crash dump kernel. They will be accessed through
>> > >> acpi_os_map_memory() and so won't be required to be part of system ram
>> > >> (or memblocks), I guess.
>> > >
>> > > Agreed. They will be covered by the linear mapping in the boot kernel,
>> > > and be mapped explicitly via ioremap_cache() in the kexec kernel,
>> > > which is exactly what we want in this case.
>> >
>> > Now this is what is confusing me. I don't see the above happening.
>> >
>> > I see that the primary kernel boots up and adds the ACPI regions via:
>> > acpi_os_ioremap
>> > -> ioremap_cache
>> >
>> > But during the crashkernel boot, ''acpi_os_ioremap' calls
>> > 'ioremap' for the ACPI Reclaim Memory regions and not the _cache
>> > variant.
>
> It is natural if that region is out of memblocks.
Thanks for the confirmation. This was my understanding as well.
>> > And it fails while accessing the ACPI tables:
>> >
>> > [ 0.039205] ACPI: Core revision 20170728
>> > pud=000000002e7d0003, *pmd=000000002e7c0003, *pte=00e8000039710707
>> > [ 0.095098] Internal error: Oops: 96000021 [#1] SMP
>
> this (ESR = 0x96000021) means that Data Abort and Alignment fault happened.
> As ioremap() makes the mapping as "Device memory", unaligned memory
> access won't be allowed.
>
>> > [ 0.100022] Modules linked in:
>> > [ 0.103102] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
>> > [ 0.109432] task: ffff000008d05180 task.stack: ffff000008cc0000
>> > [ 0.115414] PC is at acpi_ns_lookup+0x25c/0x3c0
>> > [ 0.119987] LR is at acpi_ds_load1_begin_op+0xa4/0x294
>> > [ 0.125175] pc : [<ffff0000084a6764>] lr : [<ffff00000849b4f8>]
>> > pstate: 60000045
>> > [ 0.132647] sp : ffff000008ccfb40
>> > [ 0.135989] x29: ffff000008ccfb40 x28: ffff000008a9f2a4
>> > [ 0.141354] x27: ffff0000088be820 x26: 0000000000000000
>> > [ 0.146718] x25: 000000000000001b x24: 0000000000000001
>> > [ 0.152083] x23: 0000000000000001 x22: ffff000009710027
>> > [ 0.157447] x21: ffff000008ccfc50 x20: 0000000000000001
>> > [ 0.162812] x19: 000000000000001b x18: 0000000000000005
>> > [ 0.168176] x17: 0000000000000000 x16: 0000000000000000
>> > [ 0.173541] x15: 0000000000000000 x14: 000000000000038e
>> > [ 0.178905] x13: ffffffff00000000 x12: ffffffffffffffff
>> > [ 0.184270] x11: 0000000000000006 x10: 00000000ffffff76
>> > [ 0.189634] x9 : 000000000000005f x8 : ffff8000126d0140
>> > [ 0.194998] x7 : 0000000000000000 x6 : ffff000008ccfc50
>> > [ 0.200362] x5 : ffff80000fe62c00 x4 : 0000000000000001
>> > [ 0.205727] x3 : ffff000008ccfbe0 x2 : ffff0000095e3980
>> > [ 0.211091] x1 : ffff000009710027 x0 : 0000000000000000
>> > [ 0.216456] Process swapper/0 (pid: 0, stack limit = 0xffff000008cc0000)
>> > [ 0.223224] Call trace:
>> > [ 0.225688] Exception stack(0xffff000008ccfa00 to 0xffff000008ccfb40)
>> > [ 0.232194] fa00: 0000000000000000 ffff000009710027
>> > ffff0000095e3980 ffff000008ccfbe0
>> > [ 0.240106] fa20: 0000000000000001 ffff80000fe62c00
>> > ffff000008ccfc50 0000000000000000
>> > [ 0.248018] fa40: ffff8000126d0140 000000000000005f
>> > 00000000ffffff76 0000000000000006
>> > [ 0.255931] fa60: ffffffffffffffff ffffffff00000000
>> > 000000000000038e 0000000000000000
>> > [ 0.263843] fa80: 0000000000000000 0000000000000000
>> > 0000000000000005 000000000000001b
>> > [ 0.271754] faa0: 0000000000000001 ffff000008ccfc50
>> > ffff000009710027 0000000000000001
>> > [ 0.279667] fac0: 0000000000000001 000000000000001b
>> > 0000000000000000 ffff0000088be820
>> > [ 0.287579] fae0: ffff000008a9f2a4 ffff000008ccfb40
>> > ffff00000849b4f8 ffff000008ccfb40
>> > [ 0.295491] fb00: ffff0000084a6764 0000000060000045
>> > ffff000008ccfb40 ffff000008260a18
>> > [ 0.303403] fb20: ffffffffffffffff ffff0000087f3fb0
>> > ffff000008ccfb40 ffff0000084a6764
>> > [ 0.311316] [<ffff0000084a6764>] acpi_ns_lookup+0x25c/0x3c0
>> > [ 0.316943] [<ffff00000849b4f8>] acpi_ds_load1_begin_op+0xa4/0x294
>> > [ 0.323186] [<ffff0000084ad4ac>] acpi_ps_build_named_op+0xc4/0x198
>> > [ 0.329428] [<ffff0000084ad6cc>] acpi_ps_create_op+0x14c/0x270
>> > [ 0.335319] [<ffff0000084acfa8>] acpi_ps_parse_loop+0x188/0x5c8
>> > [ 0.341298] [<ffff0000084ae048>] acpi_ps_parse_aml+0xb0/0x2b8
>> > [ 0.347101] [<ffff0000084a8e10>] acpi_ns_one_complete_parse+0x144/0x184
>> > [ 0.353783] [<ffff0000084a8e98>] acpi_ns_parse_table+0x48/0x68
>> > [ 0.359675] [<ffff0000084a82cc>] acpi_ns_load_table+0x4c/0xdc
>> > [ 0.365479] [<ffff0000084b32f8>] acpi_tb_load_namespace+0xe4/0x264
>> > [ 0.371723] [<ffff000008baf9b4>] acpi_load_tables+0x48/0xc0
>> > [ 0.377350] [<ffff000008badc20>] acpi_early_init+0x9c/0xd0
>> > [ 0.382891] [<ffff000008b70d50>] start_kernel+0x3b4/0x43c
>> > [ 0.388343] Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
>> > [ 0.394500] ---[ end trace c46ed37f9651c58e ]---
>> > [ 0.399160] Kernel panic - not syncing: Fatal exception
>> > [ 0.404437] Rebooting in 10 seconds.
>> >
>> > So, I think the linear mapping done by the primary kernel does not
>> > make these accessible in the crash kernel directly.
>> >
>> > Any pointers?
>>
>> Can you get the code line number for acpi_ns_lookup+0x25c?
>
> So should we always avoid ioremap() in acpi_os_ioremap() entirely, or
> modify acpi_ns_lookup() (or any acpi functions') to prevent unaligned
> accesses?
> (I didn't find out how unaligned accesses could happen there.)
>
Right. Like I captured somewhere in this thread (perhaps the first
email on this subject),
this is indeed an unaligned address access.
Now, modifying acpi_os_ioremap() to not ioremap() and thus avoiding
assigning this memory range
as device memory doesn't seem a neat solution as it means we are not
marking some thing with the right memory attribute and we can fall in
similar/related issues later.
Regarding the later suggestion, what I am seeing now is that the acpi
table access functions are perhaps reused from the earlier x86
implementation, but on the arm64 (or even arm) arch we should not be
allowing unaligned accesses which might cause UNDEFINED behaviour and
resultant crash.
So I can try going this approach and see if it works for me.
However, I am still not very sure as to why the crashkernel ranges
historically do not include the System RAM regions (which may include
the ACPI regions as well). These regions are available for the kernel
usage and perhaps should be exported to the crashkernel as well.
I am not fully aware of the previous discussions on capp'ing the
crashkernel memory being passed to the kdump kernel, but did we run
into any issues while doing so?
Also, even if I extend the kexec-tools to modify the
linux,usable-memory-range and add the ACPI regions to it, the
crashkernel fails to boot with the below message (I have added some
logic to print the DTB on the crash kernel boot start):
[ 0.000000] chosen {
[ 0.000000] linux,usable-memory-range
[ 0.000000] = <
[ 0.000000] 0x00000000
[ 0.000000] 0x0e800000
[ 0.000000] 0x00000000
[ 0.000000] 0x20000000
[ 0.000000] 0x00000000
[ 0.000000] 0x396c0000
[ 0.000000] 0x00000000
[ 0.000000] 0x000a0000
[ 0.000000] 0x00000000
[ 0.000000] 0x39770000
[ 0.000000] 0x00000000
[ 0.000000] 0x00040000
[ 0.000000] 0x00000000
[ 0.000000] 0x398a0000
[ 0.000000] 0x00000000
[ 0.000000] 0x00020000
[ 0.000000] >
[ 0.000000] ;
[snip..]
[ 0.000000] linux,usable-memory-range base e800000, size 20000000
[ 0.000000] - e800000 , 20000000
[ 0.000000] linux,usable-memory-range base 396c0000, size a0000
[ 0.000000] - 396c0000 , a0000
[ 0.000000] linux,usable-memory-range base 39770000, size 40000
[ 0.000000] - 39770000 , 40000
[ 0.000000] linux,usable-memory-range base 398a0000, size 20000
[ 0.000000] - 398a0000 , 20000
[ 0.000000] initrd not fully accessible via the linear mapping --
please check your bootloader ...
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: CPU: 0 PID: 0 at arch/arm64/mm/init.c:597
arm64_memblock_init+0x210/0x484
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.14.0+ #7
[ 0.000000] task: ffff000008d05580 task.stack: ffff000008cc0000
[ 0.000000] PC is at arm64_memblock_init+0x210/0x484
[ 0.000000] LR is at arm64_memblock_init+0x210/0x484
[ 0.000000] pc : [<ffff000008b76984>] lr : [<ffff000008b76984>]
pstate: 600000c5
[ 0.000000] sp : ffff000008ccfe80
[ 0.000000] x29: ffff000008ccfe80 x28: 000000000f370018
[ 0.000000] x27: 0000000011230000 x26: 00000000013b0000
[ 0.000000] x25: 000000000fe80000 x24: ffff000008cf3000
[ 0.000000] x23: ffff000008ec0000 x22: ffff000009680000
[ 0.000000] x21: ffff000008afa000 x20: ffff000008080000
[ 0.000000] x19: ffff000008afa000 x18: 000000000c283806
[ 0.000000] x17: 0000000000000000 x16: ffff000008d05580
[ 0.000000] x15: 000000002be00842 x14: 79206b6365686320
[ 0.000000] x13: 657361656c70202d x12: 2d20676e69707061
[ 0.000000] x11: 6d207261656e696c x10: 2065687420616976
[ 0.000000] x9 : 00000000000000f4 x8 : ffff000008517414
[ 0.000000] x7 : 746f6f622072756f x6 : 000000000000000d
[ 0.000000] x5 : ffff000008c96360 x4 : 0000000000000001
[ 0.000000] x3 : 0000000000000000 x2 : 0000000000000000
[ 0.000000] x1 : 0000000000000000 x0 : 0000000000000056
[ 0.000000] Call trace:
[ 0.000000] Exception stack(0xffff000008ccfd40 to 0xffff000008ccfe80)
[ 0.000000] fd40: 0000000000000056 0000000000000000
0000000000000000 0000000000000000
[ 0.000000] fd60: 0000000000000001 ffff000008c96360
000000000000000d 746f6f622072756f
[ 0.000000] fd80: ffff000008517414 00000000000000f4
2065687420616976 6d207261656e696c
[ 0.000000] fda0: 2d20676e69707061 657361656c70202d
79206b6365686320 000000002be00842
[ 0.000000] fdc0: ffff000008d05580 0000000000000000
000000000c283806 ffff000008afa000
[ 0.000000] fde0: ffff000008080000 ffff000008afa000
ffff000009680000 ffff000008ec0000
[ 0.000000] fe00: ffff000008cf3000 000000000fe80000
00000000013b0000 0000000011230000
[ 0.000000] fe20: 000000000f370018 ffff000008ccfe80
ffff000008b76984 ffff000008ccfe80
[ 0.000000] fe40: ffff000008b76984 00000000600000c5
ffff00000959b7a8 ffff000008ec0000
[ 0.000000] fe60: ffffffffffffffff 0000000000000005
ffff000008ccfe80 ffff000008b76984
[ 0.000000] [<ffff000008b76984>] arm64_memblock_init+0x210/0x484
[ 0.000000] [<ffff000008b7398c>] setup_arch+0x1b8/0x5f4
[ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
[ 0.000000] random: get_random_bytes called from
print_oops_end_marker+0x50/0x6c with crng_init=0
[ 0.000000] ---[ end trace 0000000000000000 ]---
[ 0.000000] Reserving 4KB of memory at 0x2e7f0000 for elfcorehdr
[ 0.000000] cma: Failed to reserve 512 MiB
[ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate
0x0000000000010000 bytes below 0x0000000000000000.
[ 0.000000]
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Tainted: G W
------------ 4.14.0+ #7
[ 0.000000] Call trace:
[ 0.000000] [<ffff000008088da8>] dump_backtrace+0x0/0x23c
[ 0.000000] [<ffff000008089008>] show_stack+0x24/0x2c
[ 0.000000] [<ffff0000087f647c>] dump_stack+0x84/0xa8
[ 0.000000] [<ffff0000080cfd44>] panic+0x138/0x2a0
[ 0.000000] [<ffff000008b95c88>] memblock_alloc_base+0x44/0x4c
[ 0.000000] [<ffff000008b95cbc>] memblock_alloc+0x2c/0x38
[ 0.000000] [<ffff000008b772dc>] early_pgtable_alloc+0x20/0x74
[ 0.000000] [<ffff000008b7755c>] paging_init+0x28/0x544
[ 0.000000] [<ffff000008b73990>] setup_arch+0x1bc/0x5f4
[ 0.000000] [<ffff000008b70a10>] start_kernel+0x74/0x43c
[ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to
allocate 0x0000000000010000 bytes below 0x0000000000000000.
[ 0.000000]
I guess it is because of the 1G alignment requirement between the
kernel image and the initrd and how we populate the holes between the
kernel image, segments (including dtb) and the initrd from the
kexec-tools.
Akashi, any pointers on this will be helpful as well.
Regards,
Bhupesh
>> >
>> > Regards,
>> > Bhupesh
>> >
>> > >> Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
>> > >> via a kernel command line parameter, "memmap=".
>> > >>
>> > _______________________________________________
>> > kexec mailing list -- kexec at lists.fedoraproject.org
>> > To unsubscribe send an email to kexec-leave at lists.fedoraproject.org
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Michal Simek @ 2017-12-18 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <10027244.ph2cysS4nt@avalon>
Hi Laurent,
On 18.12.2017 09:32, Laurent Pinchart wrote:
> Hi Michal,
>
> On Monday, 18 December 2017 09:32:12 EET Michal Simek wrote:
>> On 15.12.2017 10:27, Mauro Carvalho Chehab wrote:
>>> Em Fri, 15 Dec 2017 10:55:26 +0530 Dhaval Shah escreveu:
>>>> On Fri, Dec 15, 2017 at 3:32 AM, Laurent Pinchart wrote:
>>>>> On Thursday, 14 December 2017 23:50:03 EET Mauro Carvalho Chehab wrote:
>>>>>> Em Thu, 14 Dec 2017 21:57:06 +0100 Greg KH escreveu:
>>>>>>> On Thu, Dec 14, 2017 at 10:44:16PM +0200, Laurent Pinchart wrote:
>>>>>>>> On Thursday, 14 December 2017 22:08:51 EET Greg KH wrote:
>>>>>>>>> On Thu, Dec 14, 2017 at 09:05:27PM +0200, Laurent Pinchart wrote:
>>>>>>>>>> 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?
>>>>>>>>
>>>>>>>> In a nutshell (if I understand it correctly), Dhaval Shah submitted
>>>>>>>> https:// patchwork.kernel.org/patch/10102451/ which replaces
>>>>>>>>
>>>>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>>>>> [...]
>>>>>>>> - *
>>>>>>>> - * 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.
>>>>>>>>
>>>>>>>> in all .c and .h files of the Xilinx V4L2 driver
>>>>>>>> (drivers/media/platform/
>>>>>>>> xilinx). I have reviewed the patch and acked it. Mauro then rejected
>>>>>>>> it, stating that he can't accept a change to license text without an
>>>>>>>> explicit ack from the official driver's maintainers. My position is
>>>>>>>> that such a change doesn't change the license and thus doesn't need
>>>>>>>> to track all copyright holders, and can be merged without an explicit
>>>>>>>> ack from the respective maintainers.
>>>>>>>
>>>>>>> Yes, I agree with you, no license is being changed here, and no
>>>>>>> copyright is either.
>>>>>>>
>>>>>>> BUT, I know that most major companies are reviewing this process right
>>>>>>> now. We have gotten approval from almost all of the major kernel
>>>>>>> developer companies to do this, which is great, and supports this work
>>>>>>> as being acceptable.
>>>>>>>
>>>>>>> So it's nice to ask Xilinx if they object to this happening, which I
>>>>>>> guess Mauro is trying to say here (in not so many words...) To at
>>>>>>> least give them the heads-up that this is what is going to be going on
>>>>>>> throughout the kernel tree soon, and if they object, it would be good
>>>>>>> to speak up as to why (and if they do, I can put their lawyers in
>>>>>>> contact with some lawyers to explain it all to them.)
>>>>>>
>>>>>> Yes, that's basically what I'm saying.
>>>>>>
>>>>>> I don't feel comfortable on signing a patch changing the license text
>>>>>> without giving the copyright owners an opportunity and enough time
>>>>>> to review it and approve, or otherwise comment about such changes.
>>>>>
>>>>> If I understand you and Greg correctly, you would like to get a general
>>>>> approval from Xilinx for SPDX-related changes, but that would be a
>>>>> blanket approval that would cover this and all subsequent similar
>>>>> patches. Is that correct ? That is reasonable for me.
>>>>>
>>>>> In that case, could the fact that commit
>>>>>
>>>>> commit 5fd54ace4721fc5ce2bb5aef6318fcf17f421460
>>>>> Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>>>> Date: Fri Nov 3 11:28:30 2017 +0100
>>>>>
>>>>> USB: add SPDX identifiers to all remaining files in drivers/usb/
>>>>>
>>>>> add SPDX headers to several Xilinx-authored source files constitute such
>>>>> a blanket approval ?
>>>>
>>>> I have to do anything here or Once, we get approval from the Michal
>>>> Simek(michal.simek at xilinx.com) and Hyun.kwon at xilinx.com ACK this patch
>>>> then it will go into mainline?
>>>
>>> I would wait for their feedback.
>>
>> Please do not apply this patch till I get approval from legal. I have
>> already discussed things about SPDX some weeks ago.
>
> Could you ask them to approve this kind of change globally for all Xilinx
> sources files (or reject it globally if they want to do so) ? I don't want to
> go through the same hassle for every single driver.
>
> On a side note, SPDX headers have been added to several Xilinx-owned files
> already, you can use that information in your internal discussions if it
> helps.
As was said in this thread. One thing is if you simply add that one line
or if you add and remove. We are waiting for response from Legal to know
their opinion.
Anyway Xilinx is using SPDX license header in U-Boot project for years
already. This change started there in 2013 and I have never heard about
any problem connected to this.
>From my point of view it is good that this process finally started.
I have touched it in past here
https://lkml.org/lkml/2014/2/21/21
and I hope that there won't be any problem with this but let's see.
Thanks,
Michal
^ permalink raw reply
* [PATCH v5 0/5] misc serdev: new serdev based driver for Wi2Wi w2sg00x4 GPS module
From: H. Nikolaus Schaller @ 2017-12-18 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1512114576.git.hns@goldelico.com>
Hi,
unfortunately I had lost to include Andrew Davis' address who had provided
very valuable comments for v5. Sorry, Andrew!
There has only been one more comment by Andreas F?rber in the past 14 days.
So how to proceed? Who is taking care of deciding/merging towards linux-next?
BR and thanks,
Nikolaus
> Am 01.12.2017 um 08:49 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
> Changes V5:
> * clarified to keep it in drivers/misc and not create a new group drivers/gps
> * fix formatting of new entry in omap3-gta04.dtsi (suggested by Tony Lindgren)
> * removed MODULE_ALIAS (suggested by Andrew F. Davis)
> * some more formatting, code&style fixes (suggested by Andrew F. Davis)
> * apply __maybe_unused for PM (suggested by Andrew F. Davis)
> * fixed copyright and author records (suggested by Andrew F. Davis)
>
> 2017-11-15 22:38:01: Changes V4:
> * removed all pdata remains (suggested by Arnd Bergmann and Rob Herring)
> * fixed minor issues and subject/commit messages (suggested by Rob Herring)
> * added one missing Signed-off-By: (suggested by Andreas F?rber)
> * added SPDX header (suggested by Rob Herring)
>
> 2017-11-15 16:19:17: Changes V3:
> * worked in suggestions by kbuild test robot
> * added misc+serdev to the subject
>
> 2017-11-12 22:00:02: Changes V2:
> * reduced to submit only w2sg00x4 GPS driver code
> * add DT node for GTA04 device to make use of the driver
> * split into base code and a debugging Kconfig option (brings device into false power state after boot)
> * worked in comments by kbuild robot and Rob Herring
>
> 2017-05-21 12:44:07: RFC V1
> * RFC concerning new serdev based drivers for Wi2Wi w2sg00x4 GPS module and w2cbw003 bluetooth
>
> Years long history of getting this devices supported (original work by Neil Brown).
>
> H. Nikolaus Schaller (5):
> dt-bindings: define vendor prefix for Wi2Wi, Inc.
> dt-bindings: gps: add w2sg00x4 bindings documentation (GPS module with
> UART))
> misc serdev: Add w2sg0004 (gps receiver) power control driver
> DTS: gta04: add uart2 child node for w2sg00x4
> misc serdev: w2sg0004: add debugging code and Kconfig
>
> .../devicetree/bindings/gps/wi2wi,w2sg0004.txt | 24 +
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> arch/arm/boot/dts/omap3-gta04.dtsi | 7 +
> drivers/misc/Kconfig | 18 +
> drivers/misc/Makefile | 1 +
> drivers/misc/w2sg0004.c | 590 +++++++++++++++++++++
> 6 files changed, 641 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gps/wi2wi,w2sg0004.txt
> create mode 100644 drivers/misc/w2sg0004.c
>
> --
> 2.12.2
>
^ permalink raw reply
* [PATCH 2/4 v5] drm/bridge: Provide a way to embed timing info in bridges
From: Laurent Pinchart @ 2017-12-18 8:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215121047.3650-3-linus.walleij@linaro.org>
Hello Linus,
Thank you for the patch.
On Friday, 15 December 2017 14:10:45 EET Linus Walleij wrote:
> After some discussion and failed patch sets trying to convey
> the right timing information between the display engine and
> a bridge using the connector, I try instead to use an optional
> timing information container in the bridge itself, so that
> display engines can retrieve it from any bridge and use it to
> determine how to drive outputs.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog ->v5:
> - New patch
> ---
> include/drm/drm_bridge.h | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> index 682d01ba920c..3bf34f7c90d4 100644
> --- a/include/drm/drm_bridge.h
> +++ b/include/drm/drm_bridge.h
> @@ -30,6 +30,7 @@
>
> struct drm_bridge;
> struct drm_panel;
> +struct drm_bridge_timings;
Could you keep these alphabetically sorted ?
>
> /**
> * struct drm_bridge_funcs - drm_bridge control functions
> @@ -222,6 +223,22 @@ struct drm_bridge_funcs {
> void (*enable)(struct drm_bridge *bridge);
> };
>
> +/**
> + * struct drm_bridge_timings - timing information for the bridge
> + * @sampling_edge: whether the bridge samples the digital input signal from
> the
> + * display engine on the positive or negative edge of the clock - false
> means
> + * negative edge, true means positive edge.
Would it be clearer to reuse the DRM_BUS_FLAG_PIXDATA_*EDGE flags here ?
> + * @setup_time_ps: the time in picoseconds the input data lines must be
> stable
> + * before the clock edge
> + * @hold_time_ps: the time in picoseconds taken for the bridge to sample
> the
> + * input signal after the rising or falling edge
I'd write s/rising or falling edge/clock edge/ to be consistent with the
setup_time_ps description (and because that's also clearer in my opinion). If
you want to explicitly tell which clock edge, you could write "the clock
sampling edge" for both.
The rest of the patch looks good to me.
> + */
> +struct drm_bridge_timings {
> + bool sampling_edge;
> + u32 setup_time_ps;
> + u32 hold_time_ps;
> +};
> +
> /**
> * struct drm_bridge - central DRM bridge control structure
> * @dev: DRM device this bridge belongs to
> @@ -229,6 +246,8 @@ struct drm_bridge_funcs {
> * @next: the next bridge in the encoder chain
> * @of_node: device node pointer to the bridge
> * @list: to keep track of all added bridges
> + * @timings: the timing specification for the bridge, if any (may
> + * be NULL)
> * @funcs: control functions
> * @driver_private: pointer to the bridge driver's internal context
> */
> @@ -240,6 +259,7 @@ struct drm_bridge {
> struct device_node *of_node;
> #endif
> struct list_head list;
> + const struct drm_bridge_timings *timings;
>
> const struct drm_bridge_funcs *funcs;
> void *driver_private;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [linux-sunxi] [PATCH v3 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Yong @ 2017-12-18 8:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67JhMfba8Ao7WyrYikkxvTxX8WaBRqu3GkrhOCWndresg@mail.gmail.com>
On Mon, 18 Dec 2017 16:35:51 +0800
Chen-Yu Tsai <wens@csie.org> wrote:
> On Mon, Nov 13, 2017 at 3:32 PM, Yong Deng <yong.deng@magewell.com> wrote:
> > Add binding documentation for Allwinner V3s CSI.
> >
> > Signed-off-by: Yong Deng <yong.deng@magewell.com>
> > ---
> > .../devicetree/bindings/media/sun6i-csi.txt | 51 ++++++++++++++++++++++
> > 1 file changed, 51 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
> >
> > diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > new file mode 100644
> > index 0000000..f3916a2
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> > @@ -0,0 +1,51 @@
> > +Allwinner V3s Camera Sensor Interface
> > +------------------------------
> > +
> > +Required properties:
> > + - compatible: value must be "allwinner,sun8i-v3s-csi"
> > + - reg: base address and size of the memory-mapped region.
> > + - interrupts: interrupt associated to this IP
> > + - clocks: phandles to the clocks feeding the CSI
> > + * bus: the CSI interface clock
> > + * mod: the CSI module clock
> > + * ram: the CSI DRAM clock
> > + - clock-names: the clock names mentioned above
> > + - resets: phandles to the reset line driving the CSI
> > +
> > +- ports: A ports node with endpoint definitions as defined in
> > + Documentation/devicetree/bindings/media/video-interfaces.txt.
> > + Currently, the driver only support the parallel interface. So, a single port
> > + node with one endpoint and parallel bus is supported.
> > +
> > +Example:
> > +
> > + csi1: csi at 01cb4000 {
>
> Drop the leading zero in the address part.
OK.
>
> > + compatible = "allwinner,sun8i-v3s-csi";
> > + reg = <0x01cb4000 0x1000>;
> > + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_CSI>,
> > + <&ccu CLK_CSI1_SCLK>,
>
> CSI also has an MCLK. Do you need that one?
MCLK is not needed if the front end is not a sensor (like adv7611).
I will add it as an option.
>
> ChenYu
>
> > + <&ccu CLK_DRAM_CSI>;
> > + clock-names = "bus", "mod", "ram";
> > + resets = <&ccu RST_BUS_CSI>;
> > +
> > + port {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + /* Parallel bus endpoint */
> > + csi1_ep: endpoint {
> > + remote-endpoint = <&adv7611_ep>;
> > + bus-width = <16>;
> > + data-shift = <0>;
> > +
> > + /* If hsync-active/vsync-active are missing,
> > + embedded BT.656 sync is used */
> > + hsync-active = <0>; /* Active low */
> > + vsync-active = <0>; /* Active low */
> > + data-active = <1>; /* Active high */
> > + pclk-sample = <1>; /* Rising */
> > + };
> > + };
> > + };
> > +
> > --
> > 1.8.3.1
> >
> > --
> > You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
Thanks,
Yong
^ permalink raw reply
* [PATCH 1/4 v5] drm/bridge: Add bindings for TI THS8134
From: Laurent Pinchart @ 2017-12-18 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215121047.3650-2-linus.walleij@linaro.org>
Hello Linus,
Thank you for the patch.
On Friday, 15 December 2017 14:10:44 EET Linus Walleij wrote:
> This adds device tree bindings for the Texas Instruments
> THS8134, THS8134A and THS8134B VGA DACs by extending and
> renaming the existing bindings for THS8135.
>
> These DACs are used for the VGA outputs on the ARM reference
> designs such as Integrator, Versatile and RealView.
>
> Cc: devicetree at vger.kernel.org
> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v2->v5:
> - Dropped the "ti,ths813x" as it turns out we need precise info
> about the sub-variant anyways as they all very in timings.
> - Refine the THS8134 variants, it turns out ths8134, ths8134a
> and ths8134b are three different variants of ths8134.
> ChangeLog v1->v2:
> - Introduce specific-to-general compatible string:
> compatible = "ti,ths8134a", "ti,ths813x";
> so drivers can handle the whole family the same way.
> - Collected Rob's ACK.
> ---
> .../display/bridge/{ti,ths8135.txt => ti,ths813x.txt} | 13 +++++++--
> 1 file changed, 9 insertions(+), 4 deletions(-)
> rename Documentation/devicetree/bindings/display/bridge/{ti,ths8135.txt =>
> ti,ths813x.txt} (69%)
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
> similarity index 69%
> rename from Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> rename to Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
> index 6ec1a880ac18..49f155467f00 100644
> --- a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths813x.txt
> @@ -1,11 +1,16 @@
> -THS8135 Video DAC
> ------------------
> +THS8134 and THS8135 Video DAC
> +-----------------------------
>
> -This is the binding for Texas Instruments THS8135 Video DAC bridge.
> +This is the binding for Texas Instruments THS8134, THS8134A, THS8134B and
> +THS8135 Video DAC bridge.
There's more than one no, so s/bridge/bridges/. Or just s/DAC bridge/DACs/ as
bridge refers to the software implementation.
With this and Rob's comment about the compatible string ordering
("ti,ths8134[ab]", "ti,ths8134" instead of "ti,ths8134[ab]", "ti,ths8134"),
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Required properties:
>
> -- compatible: Must be "ti,ths8135"
> +- compatible: Must be one of
> + "ti,ths8134"
> + "ti,ths8134", "ti,ths8134a"
> + "ti,ths8134", "ti,ths8134b"
> + "ti,ths8135"
>
> Required nodes:
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 0/4 v5] Support bridge timings
From: Andrzej Hajda @ 2017-12-18 8:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215155415.GT26573@phenom.ffwll.local>
On 15.12.2017 16:54, Daniel Vetter wrote:
> On Fri, Dec 15, 2017 at 01:30:24PM +0100, Linus Walleij wrote:
>> On Fri, Dec 15, 2017 at 1:10 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>>> - The connector is apparently not the right abstraction to carry
>>> the detailed timings specification between DRI drivers and bridge
>>> drivers.
>>>
>>> - Instead put detailed timing data into the bridge itself as an
>>> optional information pointer.
>> Notice that this is just my fumbling attempts to deal with the situation.
>>
>> Laurent made me understand what the actual technical problem was,
>> how come my pixels were flickering.
>>
>> Both Laurent and DVetter mentioned that we may need to convey
>> information between the bridge and the display engine in some
>> way.
>>
>> Alternatively I could go and hack on adding this to e.g. drm_display_info
>> which was used in the previous patch sets by setting the negede flag
>> in bus_formats.
>>
>> I don't know. struct drm_display_info is getting a bit heavy as
>> container of misc settings related to "some kind of display".
>> The bridge isn't even a display itself, that is on the other side
>> of it. So using the connector and treating a bridge as "some kind
>> of display" seems wrong too.
>>
>> Is there a third way?
> If you don't plan to nest bridges too deeply, there is. Atm we have 2
> modes in drm_crtc_state:
>
> - mode, which is what userspace requested, and what it expects logically
> to be the actual real thing. I.e. timing, resolution and all that that
> userspace can observe (through plane positioning and vblank timestamps)
> should match this mode. For external screens this should also match
> what's physically going over the cable.
>
> - adjusted_mode, which is something entirely undefined and to be used by
> drivers internally. Most drivers use it as the thing that's actually
> transported between the CRTC and the encoder.
>
> There's a few common reasons for adjusted mode to be different:
> - integrated panel, and your CRTC has a scaler. In that case the
> userspace-requested mode is what you feed into into the scaler, and the
> adjusted mode is what comes out of your scaler and then goes down the
> wire to the panel.
>
> - your encoder is funky, and e.g. transcodes to the output mode itself,
> but expects that you program the input mode always the same. Usual
> reasons for this are transcoders that always want non-interlaced mode
> (and do the interlacing themselves), if the transcoder has some scaler
> itself (some TV-out transcoders had that), or if it has a strict
> expectation about signalling edges and stuff (and then transcodes the
> signal again). DACs are common doing that.
>
> Anyway, sounds like your bridge is of the 2nd kind, so all you have to do
> is
> - in your bridge->mode_fixup function, adjust the adjusted_mode as needed
> - in your pl111 driver, program the adjusted mode, not the originally
> requested mode
>
> adjusted mode is set to be a copy of the requested mode by atomic helpers,
> so this should keep working as-is on any other bridge driver.
>
> No idea why I didn't tell you this right away, or maybe I'm missing
> something this time around.
Using adjusted_mode will probably help here, fortunately the pipeline is
short in this case and one adjusted_mode per pipeline should be enough.
But there is more fundamental problem here - drm core does not provide a
way to interact between adjacent components of the pipeline. So they are
not able to negotiate/exchange parameters specific for the video link
between them.
adjusted_mode is one per pipeline and will note scale without hacks.
Anyway I remember multiple attempts to somehow workaround this issue,
for example:
- passing DSI specific settings (currently performed via DSI control bus),
- passing info about panel command mode parameters(by adding these
properties to crtc node),
- passing bus flags from panel to encoder/bridge (via drm_display_mode,
nacked if I remember, I do not know if/how it is solved actually).
Another concern is that adjusted_mode used inside drm driver (ie.
between encoder and crtc) is something private per drm driver. In this
case we have bridge which theoretically should work with ANY video
source with compatible video bus: encoder, or another bridge before it.
So adjusted_mode is not private anymore, and will be problematic if two
different bridges/encoders will use it differently.
Regards
Andrzej
>
>> I'm just a bit lost.
> Once your un-lost, pls review the docs for drm_crtc_state and the various
> mode_fixup functions, to make sure they're clear on how this is supposed
> to work. Might need a new overview DOC: comment that ties it all together.
>
> Cheers, Daniel
^ permalink raw reply
* [linux-sunxi] [PATCH v3 2/3] dt-bindings: media: Add Allwinner V3s Camera Sensor Interface (CSI)
From: Chen-Yu Tsai @ 2017-12-18 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1510558344-45402-1-git-send-email-yong.deng@magewell.com>
On Mon, Nov 13, 2017 at 3:32 PM, Yong Deng <yong.deng@magewell.com> wrote:
> Add binding documentation for Allwinner V3s CSI.
>
> Signed-off-by: Yong Deng <yong.deng@magewell.com>
> ---
> .../devicetree/bindings/media/sun6i-csi.txt | 51 ++++++++++++++++++++++
> 1 file changed, 51 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/sun6i-csi.txt
>
> diff --git a/Documentation/devicetree/bindings/media/sun6i-csi.txt b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> new file mode 100644
> index 0000000..f3916a2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/sun6i-csi.txt
> @@ -0,0 +1,51 @@
> +Allwinner V3s Camera Sensor Interface
> +------------------------------
> +
> +Required properties:
> + - compatible: value must be "allwinner,sun8i-v3s-csi"
> + - reg: base address and size of the memory-mapped region.
> + - interrupts: interrupt associated to this IP
> + - clocks: phandles to the clocks feeding the CSI
> + * bus: the CSI interface clock
> + * mod: the CSI module clock
> + * ram: the CSI DRAM clock
> + - clock-names: the clock names mentioned above
> + - resets: phandles to the reset line driving the CSI
> +
> +- ports: A ports node with endpoint definitions as defined in
> + Documentation/devicetree/bindings/media/video-interfaces.txt.
> + Currently, the driver only support the parallel interface. So, a single port
> + node with one endpoint and parallel bus is supported.
> +
> +Example:
> +
> + csi1: csi at 01cb4000 {
Drop the leading zero in the address part.
> + compatible = "allwinner,sun8i-v3s-csi";
> + reg = <0x01cb4000 0x1000>;
> + interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_CSI>,
> + <&ccu CLK_CSI1_SCLK>,
CSI also has an MCLK. Do you need that one?
ChenYu
> + <&ccu CLK_DRAM_CSI>;
> + clock-names = "bus", "mod", "ram";
> + resets = <&ccu RST_BUS_CSI>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* Parallel bus endpoint */
> + csi1_ep: endpoint {
> + remote-endpoint = <&adv7611_ep>;
> + bus-width = <16>;
> + data-shift = <0>;
> +
> + /* If hsync-active/vsync-active are missing,
> + embedded BT.656 sync is used */
> + hsync-active = <0>; /* Active low */
> + vsync-active = <0>; /* Active low */
> + data-active = <1>; /* Active high */
> + pclk-sample = <1>; /* Rising */
> + };
> + };
> + };
> +
> --
> 1.8.3.1
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Laurent Pinchart @ 2017-12-18 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9614a2cb-66bf-6689-e6ac-abd24a71bb04@xilinx.com>
Hi Michal,
On Monday, 18 December 2017 09:32:12 EET Michal Simek wrote:
> On 15.12.2017 10:27, Mauro Carvalho Chehab wrote:
> > Em Fri, 15 Dec 2017 10:55:26 +0530 Dhaval Shah escreveu:
> >> On Fri, Dec 15, 2017 at 3:32 AM, Laurent Pinchart wrote:
> >>> On Thursday, 14 December 2017 23:50:03 EET Mauro Carvalho Chehab wrote:
> >>>> Em Thu, 14 Dec 2017 21:57:06 +0100 Greg KH escreveu:
> >>>>> On Thu, Dec 14, 2017 at 10:44:16PM +0200, Laurent Pinchart wrote:
> >>>>>> On Thursday, 14 December 2017 22:08:51 EET Greg KH wrote:
> >>>>>>> On Thu, Dec 14, 2017 at 09:05:27PM +0200, Laurent Pinchart wrote:
> >>>>>>>> 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?
> >>>>>>
> >>>>>> In a nutshell (if I understand it correctly), Dhaval Shah submitted
> >>>>>> https:// patchwork.kernel.org/patch/10102451/ which replaces
> >>>>>>
> >>>>>> +// SPDX-License-Identifier: GPL-2.0
> >>>>>> [...]
> >>>>>> - *
> >>>>>> - * 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.
> >>>>>>
> >>>>>> in all .c and .h files of the Xilinx V4L2 driver
> >>>>>> (drivers/media/platform/
> >>>>>> xilinx). I have reviewed the patch and acked it. Mauro then rejected
> >>>>>> it, stating that he can't accept a change to license text without an
> >>>>>> explicit ack from the official driver's maintainers. My position is
> >>>>>> that such a change doesn't change the license and thus doesn't need
> >>>>>> to track all copyright holders, and can be merged without an explicit
> >>>>>> ack from the respective maintainers.
> >>>>>
> >>>>> Yes, I agree with you, no license is being changed here, and no
> >>>>> copyright is either.
> >>>>>
> >>>>> BUT, I know that most major companies are reviewing this process right
> >>>>> now. We have gotten approval from almost all of the major kernel
> >>>>> developer companies to do this, which is great, and supports this work
> >>>>> as being acceptable.
> >>>>>
> >>>>> So it's nice to ask Xilinx if they object to this happening, which I
> >>>>> guess Mauro is trying to say here (in not so many words...) To at
> >>>>> least give them the heads-up that this is what is going to be going on
> >>>>> throughout the kernel tree soon, and if they object, it would be good
> >>>>> to speak up as to why (and if they do, I can put their lawyers in
> >>>>> contact with some lawyers to explain it all to them.)
> >>>>
> >>>> Yes, that's basically what I'm saying.
> >>>>
> >>>> I don't feel comfortable on signing a patch changing the license text
> >>>> without giving the copyright owners an opportunity and enough time
> >>>> to review it and approve, or otherwise comment about such changes.
> >>>
> >>> If I understand you and Greg correctly, you would like to get a general
> >>> approval from Xilinx for SPDX-related changes, but that would be a
> >>> blanket approval that would cover this and all subsequent similar
> >>> patches. Is that correct ? That is reasonable for me.
> >>>
> >>> In that case, could the fact that commit
> >>>
> >>> commit 5fd54ace4721fc5ce2bb5aef6318fcf17f421460
> >>> Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>> Date: Fri Nov 3 11:28:30 2017 +0100
> >>>
> >>> USB: add SPDX identifiers to all remaining files in drivers/usb/
> >>>
> >>> add SPDX headers to several Xilinx-authored source files constitute such
> >>> a blanket approval ?
> >>
> >> I have to do anything here or Once, we get approval from the Michal
> >> Simek(michal.simek at xilinx.com) and Hyun.kwon at xilinx.com ACK this patch
> >> then it will go into mainline?
> >
> > I would wait for their feedback.
>
> Please do not apply this patch till I get approval from legal. I have
> already discussed things about SPDX some weeks ago.
Could you ask them to approve this kind of change globally for all Xilinx
sources files (or reject it globally if they want to do so) ? I don't want to
go through the same hassle for every single driver.
On a side note, SPDX headers have been added to several Xilinx-owned files
already, you can use that information in your internal discussions if it
helps.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH 1/2] serial: stm32: add default console
From: Ludovic BARRE @ 2017-12-18 8:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215192517.GA27395@kroah.com>
hi Greg
Yes, the machine could be boot without console. but our
boards has a console by default. it is just to simplified the
configuration.
you can abandoned this patch, if you prefer.
BR
Ludo
On 12/15/2017 08:25 PM, Greg Kroah-Hartman wrote:
> On Fri, Dec 01, 2017 at 05:36:50PM +0100, Ludovic Barre wrote:
>> From: Ludovic Barre <ludovic.barre@st.com>
>>
>> This patch adds by default the console support
>> on stm32.
>
> Why? 'default y' should only mean "machine will not boot without this".
> And I think your machine will boot without the console, right? :)
>
> thanks,
>
> greg k-h
>
^ permalink raw reply
* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Miquel RAYNAL @ 2017-12-18 8:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <877etkecig.fsf@belgarion.home>
Hello Robert,
On Mon, 18 Dec 2017 08:11:35 +0100
Robert Jarzmik <robert.jarzmik@free.fr> wrote:
> Boris Brezillon <boris.brezillon@free-electrons.com> writes:
>
> >> Robert, it would be great if you could also do more testing on PXA
> >> and validate this driver. If needed, a branch ready to be tested is
> >> available at [3]. It is based on nand/next and has all the changes
> >> brought by the previously mentionned series as well as this one.
> >
> > Robert, do you think you'll have some time to test Miquel's branch
> > on your PXA boards? Miquel already tested on one of these boards
> > (CM-X300), but we'd like to have other testers. Also feel free to
> > review the driver if have the time.
> >
> > Thanks,
> >
> > Boris
>
> Hi Boris and Miquel,
>
> I have applied the whole serie to linux-next yesterday.
>
> A boot attempt on my zylonite with my old defconfig (with the new
> Marvell NAND config activated) yields to :
> - this message
> [ 3.136818] marvell-nfc pxa3xx-nand: could not identify the nand
> chip [ 3.143874] marvell-nfc: probe of pxa3xx-nand failed with
> error -22
> - then my board hangs
>
> Is there something to be done to improve the trace level so that you
> can guess what's happening ?
Thank you very much for testing this.
Could you please try this branch [1] instead of linux-next + the
patches?
Also, can you please add #define DEBUG in marvell_nand.c + nand_base.c,
it should help us figuring out what is wrong.
Thank you,
Miqu?l
[1] https://github.com/miquelraynal/linux/tree/marvell/nand-next/nfc
^ permalink raw reply
* [PATCH] arch/arm64: elfcorehdr should be the first allocation
From: Poonam Aggrwal @ 2017-12-18 8:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171218053318.2lnoouuiewkwwnmf@fireball>
> -----Original Message-----
> From: AKASHI Takahiro [mailto:takahiro.akashi at linaro.org]
> Sent: Monday, December 18, 2017 11:03 AM
> To: Poonam Aggrwal <poonam.aggrwal@nxp.com>
> Cc: Abhimanyu Saini <abhimanyu.saini@nxp.com>; Will Deacon
> <will.deacon@arm.com>; Prabhakar Kushwaha
> <prabhakar.kushwaha@nxp.com>; linux-arm-kernel at lists.infradead.org; G.h.
> Gao <guanhua.gao@nxp.com>; james.morse at arm.com
> Subject: Re: [PATCH] arch/arm64: elfcorehdr should be the first allocation
>
> On Fri, Dec 15, 2017 at 02:20:15PM +0000, Poonam Aggrwal wrote:
> > Thanks Takahiro and Will,
> >
> > Please find responses below.
> >
> > Regards
> > Poonam
> > > -----Original Message-----
> > > From: AKASHI Takahiro [mailto:takahiro.akashi at linaro.org]
> > > Sent: Wednesday, December 13, 2017 4:17 PM
> > > To: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> > > Cc: Will Deacon <will.deacon@arm.com>; Prabhakar Kushwaha
> > > <prabhakar.kushwaha@nxp.com>; linux-arm-kernel at lists.infradead.org;
> > > Poonam Aggrwal <poonam.aggrwal@nxp.com>; G.h. Gao
> > > <guanhua.gao@nxp.com>; james.morse at arm.com
> > > Subject: Re: [PATCH] arch/arm64: elfcorehdr should be the first
> > > allocation
> > >
> > > On Mon, Dec 11, 2017 at 02:07:14PM +0000, Will Deacon wrote:
> > > > On Mon, Dec 11, 2017 at 11:03:32AM +0530, Prabhakar Kushwaha wrote:
> > > > > From: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> > > > >
> > > > > elfcorehdr_addr is assigned by kexec-utils and device tree of
> > > > > dump kernel is fixed in chosen node with parameter "linux,elfcorehdr".
> > > > > So, memory should be first reserved for elfcorehdr, otherwise
> > > > > overlaps may happen with other memory allocations which were
> > > > > done before the allocation of elcorehdr in the crash kernel
> > > >
> > > > What happens in that case? Do you have a crash log we can include
> > > > in the commit message?
> > >
> > > In private discussions with Poonam, he said:
> > > | The overlap here I observed was for the reserved-mem areas in the dtb.
> > > | And they were specific to NXP device.
> > Thanks Takahiro for providing this information.
> > Yes the memory overlap happens because when the dump-capture kernel tries
> to reserve elfcoreheader at the specific address, it finds that the address has
> already been reserved for some other use by
> early_init_fdt_scan_reserved_mem().
> > Based on the "reserved-memory" node entries in the dts file , the overlap is
> seen to happen with one of the below alocations:
>
> So the point is that reserve_elfcorehdr() should be placed before
> early_init_fdt_scan_reserved_mem() which may allocate memory dynamically,
> isn't it. I think it makes sense.
>
> Lisewise, reserve_crashkernel(), which can also allocate memory statically in
> case of "crashkernel=SIZE at ADDRESS", should be.
> (Even if an overrap might happen, this wouldn't prevent the system from booting
> though. We just can't use kdump in this case.)
>
Right, so probably both the allocations (elfcorehdr and crash kernel) should go before the early_init_fdt_scan_reserved_mem.
Should I send a re-spin?
> Thanks,
> -Takahiro AKASHI
>
> > [ 0.000000] Reserved memory: created DMA memory pool at
> 0x00000000fb800000, size 4 MiB
> > [ 0.000000] Reserved memory: initialized node qman-fqd, compatible id
> shared-dma-pool
> > [ 0.000000] Reserved memory: created DMA memory pool at
> 0x00000000f8000000, size 32 MiB
> > [ 0.000000] Reserved memory: initialized node qman-pfdr, compatible id
> shared-dma-pool
> > >
> > > Since I have not got any details since then, I'm not sure whether
> > > your patch is the way to go.
> > > (I suspect that we might better fix the issue on kexec-tools side.)
> > >
> > I may not have full understanding of kexec-tools, but I am not sure how will
> kexec tools be able to know what addresses will get assigned for the reserved-
> memory regions in the device tree.
> > > Thanks,
> > > -Takahiro AKASHI
> > >
> > > > > Signed-off-by: Guanhua <guanhua.gao@nxp.com>
> > > > > Signed-off-by: Poonam Aggrwal <poonam.aggrwal@nxp.com>
> > > > > Signed-off-by: Abhimanyu Saini <abhimanyu.saini@nxp.com>
> > > > > ---
> > > >
> > > > Really? How on Earth did you get three people co-developing this patch?
> > : )Contribution was from all in terms of reproducing, testing on various
> platforms including the debug experiments. Just wanted to acknowledge the
> effort.
> > > >
> > > > > arch/arm64/mm/init.c | 6 ++++--
> > > > > 1 file changed, 4 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index
> > > > > 5960bef0170d..551048cfcfff 100644
> > > > > --- a/arch/arm64/mm/init.c
> > > > > +++ b/arch/arm64/mm/init.c
> > > > > @@ -453,6 +453,10 @@ void __init arm64_memblock_init(void)
> > > > > * Register the kernel text, kernel data, initrd, and initial
> > > > > * pagetables with memblock.
> > > > > */
> > > > > +
> > > > > + /* make this the first reservation so that there are no chances
> of
> > > > > + * overlap */
> > > > > + reserve_elfcorehdr();
> > > > > memblock_reserve(__pa_symbol(_text), _end - _text); #ifdef
> > > > > CONFIG_BLK_DEV_INITRD
> > > > > if (initrd_start) {
> > > > > @@ -474,8 +478,6 @@ void __init arm64_memblock_init(void)
> > > > >
> > > > > reserve_crashkernel();
> > > > >
> > > > > - reserve_elfcorehdr();
> > > >
> > > > Why isn't this also a problem for reserve_crashkernel() or any
> > > > other static reservations?
> > Thanks, for raising this. Yes looking at the code flow this may also cause a
> problem, definitely when the start address of the crash kernel is specified in the
> bootargs. We mostly tested with just the size, so it was an allocation without a
> specific address.
> >
> > > >
> > > > Will
^ permalink raw reply
* [PATCH 4/5] arm: dts: sun8i: a83t: Add support for the ir interface
From: Maxime Ripard @ 2017-12-18 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-5-embed3d@gmail.com>
On Sun, Dec 17, 2017 at 11:45:46PM +0100, Philipp Rossak wrote:
> The ir interface is like on the H3 located at 0x01f02000 and is exactly
> the same. This patch adds support for the ir interface on the A83T.
>
> Signed-off-by: Philipp Rossak <embed3d@gmail.com>
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 954c2393325f..9e7ed3b9a6b8 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -503,6 +503,16 @@
> #reset-cells = <1>;
> };
>
> + ir: ir at 01f02000 {
> + compatible = "allwinner,sun5i-a13-ir";
> + clocks = <&r_ccu CLK_APB0_IR>, <&r_ccu CLK_IR>;
> + clock-names = "apb", "ir";
> + resets = <&r_ccu RST_APB0_IR>;
> + interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
> + reg = <0x01f02000 0x40>;
The size should be the size of the whole memory block, not just the
registers you need.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171218/f0fc4225/attachment-0001.sig>
^ permalink raw reply
* [PATCH 2/5] media: dt: bindings: Update binding documentation for sunxi IR controller
From: Maxime Ripard @ 2017-12-18 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171217224547.21481-3-embed3d@gmail.com>
Hi,
On Sun, Dec 17, 2017 at 11:45:44PM +0100, Philipp Rossak wrote:
> This patch updates documentation for Device-Tree bindings for sunxi IR
> controller and adds the new optional property for the base clock
> frequency.
>
> Signed-off-by: Philipp Rossak <embed3d@gmail.com>
> ---
> Documentation/devicetree/bindings/media/sunxi-ir.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt b/Documentation/devicetree/bindings/media/sunxi-ir.txt
> index 91648c569b1e..9f45bab07d6e 100644
> --- a/Documentation/devicetree/bindings/media/sunxi-ir.txt
> +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
> @@ -11,6 +11,7 @@ Required properties:
> Optional properties:
> - linux,rc-map-name: see rc.txt file in the same directory.
> - resets : phandle + reset specifier pair
> +- clock-frequency : overrides the default base clock frequency (8 MHz)
You're at least missing the unit one needs to use, but something like:
IR Receiver clock frequency, in Hertz. Defaults to 8MHz if missing.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171218/b30f0dbc/attachment.sig>
^ permalink raw reply
* [PATCH] media: v4l: xilinx: Use SPDX-License-Identifier
From: Michal Simek @ 2017-12-18 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171215072734.6180613b@vento.lan>
Hi guys,
On 15.12.2017 10:27, Mauro Carvalho Chehab wrote:
> Em Fri, 15 Dec 2017 10:55:26 +0530
> Dhaval Shah <dhaval23031987@gmail.com> escreveu:
>
>> Hi Laurent/Mauro/Greg,
>>
>> On Fri, Dec 15, 2017 at 3:32 AM, Laurent Pinchart
>> <laurent.pinchart@ideasonboard.com> wrote:
>>> Hi Mauro,
>>>
>>> On Thursday, 14 December 2017 23:50:03 EET Mauro Carvalho Chehab wrote:
>>>> Em Thu, 14 Dec 2017 21:57:06 +0100 Greg KH escreveu:
>>>>> On Thu, Dec 14, 2017 at 10:44:16PM +0200, Laurent Pinchart wrote:
>>>>>> On Thursday, 14 December 2017 22:08:51 EET Greg KH wrote:
>>>>>>> On Thu, Dec 14, 2017 at 09:05:27PM +0200, Laurent Pinchart wrote:
>>>>>>>> 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?
>>>>>>
>>>>>> In a nutshell (if I understand it correctly), Dhaval Shah submitted
>>>>>> https:// patchwork.kernel.org/patch/10102451/ which replaces
>>>>>>
>>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>>> [...]
>>>>>> - *
>>>>>> - * 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.
>>>>>>
>>>>>> in all .c and .h files of the Xilinx V4L2 driver
>>>>>> (drivers/media/platform/
>>>>>> xilinx). I have reviewed the patch and acked it. Mauro then rejected it,
>>>>>> stating that he can't accept a change to license text without an
>>>>>> explicit ack from the official driver's maintainers. My position is
>>>>>> that such a change doesn't change the license and thus doesn't need to
>>>>>> track all copyright holders, and can be merged without an explicit ack
>>>>>> from the respective maintainers.
>>>>>
>>>>> Yes, I agree with you, no license is being changed here, and no
>>>>> copyright is either.
>>>>>
>>>>> BUT, I know that most major companies are reviewing this process right
>>>>> now. We have gotten approval from almost all of the major kernel
>>>>> developer companies to do this, which is great, and supports this work
>>>>> as being acceptable.
>>>>>
>>>>> So it's nice to ask Xilinx if they object to this happening, which I
>>>>> guess Mauro is trying to say here (in not so many words...) To at least
>>>>> give them the heads-up that this is what is going to be going on
>>>>> throughout the kernel tree soon, and if they object, it would be good to
>>>>> speak up as to why (and if they do, I can put their lawyers in contact
>>>>> with some lawyers to explain it all to them.)
>>>>
>>>> Yes, that's basically what I'm saying.
>>>>
>>>> I don't feel comfortable on signing a patch changing the license text
>>>> without giving the copyright owners an opportunity and enough time
>>>> to review it and approve, or otherwise comment about such changes.
>>>
>>> If I understand you and Greg correctly, you would like to get a general
>>> approval from Xilinx for SPDX-related changes, but that would be a blanket
>>> approval that would cover this and all subsequent similar patches. Is that
>>> correct ? That is reasonable for me.
>>>
>>> In that case, could the fact that commit
>>>
>>> commit 5fd54ace4721fc5ce2bb5aef6318fcf17f421460
>>> Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Date: Fri Nov 3 11:28:30 2017 +0100
>>>
>>> USB: add SPDX identifiers to all remaining files in drivers/usb/
>>>
>>> add SPDX headers to several Xilinx-authored source files constitute such a
>>> blanket approval ?
>>>
>> I have to do anything here or Once, we get approval from the Michal
>> Simek(michal.simek at xilinx.com) and Hyun.kwon at xilinx.com ACK this patch
>> then it will go into mainline?
>
> I would wait for their feedback.
Please do not apply this patch till I get approval from legal. I have
already discussed things about SPDX some weeks ago.
Thanks,
Michal
^ permalink raw reply
* [PATCH 00/12] Marvell NAND controller rework with ->exec_op()
From: Robert Jarzmik @ 2017-12-18 7:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171214070930.0b885f6d@bbrezillon>
Boris Brezillon <boris.brezillon@free-electrons.com> writes:
>> Robert, it would be great if you could also do more testing on PXA and
>> validate this driver. If needed, a branch ready to be tested is
>> available at [3]. It is based on nand/next and has all the changes
>> brought by the previously mentionned series as well as this one.
>
> Robert, do you think you'll have some time to test Miquel's branch on
> your PXA boards? Miquel already tested on one of these boards (CM-X300),
> but we'd like to have other testers. Also feel free to review the
> driver if have the time.
>
> Thanks,
>
> Boris
Hi Boris and Miquel,
I have applied the whole serie to linux-next yesterday.
A boot attempt on my zylonite with my old defconfig (with the new Marvell NAND
config activated) yields to :
- this message
[ 3.136818] marvell-nfc pxa3xx-nand: could not identify the nand chip
[ 3.143874] marvell-nfc: probe of pxa3xx-nand failed with error -22
- then my board hangs
Is there something to be done to improve the trace level so that you can guess
what's happening ?
Cheers.
--
Robert
^ 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