* [PATCH 04/12] arm64: Initialise high_memory global variable earlier
From: Steve Capper @ 2017-12-12 10:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211120022.ujdc37dp3iawzrem@armageddon.cambridge.arm.com>
On Mon, Dec 11, 2017 at 12:00:22PM +0000, Catalin Marinas wrote:
> On Mon, Dec 04, 2017 at 02:13:05PM +0000, Steve Capper wrote:
> > The high_memory global variable is used by
> > cma_declare_contiguous(.) before it is defined.
> >
> > We don't notice this as we compute __pa(high_memory - 1), and it looks
> > like we're processing a VA from the direct linear map.
> >
> > This problem becomes apparent when we flip the kernel virtual address
> > space and the linear map is moved to the bottom of the kernel VA space.
> >
> > This patch moves the initialisation of high_memory before it used.
> >
> > Signed-off-by: Steve Capper <steve.capper@arm.com>
>
> It looks like we've had this bug since 3.18 (f7426b983a6a, "mm: cma:
> adjust address limit to avoid hitting low/high memory boundary"). It may
> be worth adding a cc stable on this patch.
Thanks Catalin,
Will add a fixes and cc stable.
Cheers,
--
Steve
>
> --
> Catalin
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Marek Szyprowski @ 2017-12-12 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ad03e2a8-00eb-464e-6983-374f83b9abf5@collabora.com>
Hi Guillaume,
On 2017-12-12 11:43, Guillaume Tucker wrote:
> On 12/12/17 10:17, Marek Szyprowski wrote:
>> Hi Krzysztof,
>>
>> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski
>>> <krzk@kernel.org> wrote:
>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>> <javierm@redhat.com> wrote:
>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to
>>>>> Exynos 542x
>>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and
>>>>> enabled
>>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it
>>>>> for the
>>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC
>>>>> variant.
>>>>>
>>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to
>>>>> Exynos 542x Mixer nodes")
>>>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - Remove RFT tag.
>>>> Thanks guys! However I still would like to see a tested-by for this on
>>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>>> On the other hand I could just apply it for my for-next branch and
>>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>>> testing but apparently no one has Peach Pi.
>>
>> Frankly, I don't expect that this will solve the boot hang issue on
>> PeachPi.
>> However it should at least hide the unbalanced regulator issue.
>
> We have a peach-pi in our LAVA lab so I've tested it and
> actually, it does fix the hang on v4.15-rc3:
>
> ? https://lava.collabora.co.uk/scheduler/job/1019877
> ? https://lava.collabora.co.uk/scheduler/job/1019878
>
> I ran it twice and it booted both times.? I also ran the same
> boot tests with the same kernel but the dtb from v4.15-rc3
> without the fix to double check and these failed:
>
> ? https://lava.collabora.co.uk/scheduler/job/1019879
> ? https://lava.collabora.co.uk/scheduler/job/1019880
>
>
> Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>
>
> Thanks for the fix!
Well, thanks for the test! It proves that there the boot failure is
caused by an issue somewhere in the error path of Exynos DRM, Analogix
DP, Simple Panel or other drivers.
This patch simply hides it by fixing the source issue of the Exynos
DRM initialization failure. :-)
I hope Javier will be able to investigate the discussed hang issue
later, as fixing it is also imho important.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [RFC PATCH 1/3] dt-bindings: pinctrl: sunxi: document new generic binding
From: Linus Walleij @ 2017-12-12 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <be52417d-9509-f638-65b6-f455fade0c39@arm.com>
On Wed, Dec 6, 2017 at 1:55 AM, Andr? Przywara <andre.przywara@arm.com> wrote:
> On 01/12/17 09:56, Linus Walleij wrote:
>> It is a valid cause. Just
>> has to be weighed with other stuff, like maintainability, debuggability,
>> maintainers viewpoint. ...
>
> So to keep Maxime happy I actually designed this "driver" more like a
> shim: to generate the table the current driver expects from the DT, and
> actually not touching the existing driver at all.
> So maintainability should actually be less of a concern: the driver will
> just work with whatever one throws at it from the DT side, without
> requiring frequent changes or additions.
> In the moment we still need to write, review and merge *data* files for
> each new SoC. And as I mentioned before, Allwinner decided to push for
> new, slightly different chips every few months, so there will be more to
> come. With at least the pinctrl driver out of the way we have one
> problem less to worry about.
I think you need mainly to convince Maxime that this is something that
he wants to maintain, going forward.
I am as subsystem maintainer pretty pleased as long as standard
properties etc are used to encode the data into the devicetree, and
DT maintrainers are not actively vetoing what you do.
If it leads to a conflict between Allwinner maintainers it is not worth the
effort for reasons that are social rather than technical. To me it is a very
nice but as with all volunteer communities also very vulnerable
endavour.
Please make sure not to push your point so hard that it hurts your
our your colleagues feelings.
I know people are passionate about their ideas, which is usally good
but also scare me sometimes because they sometimes become so
passionate that it makes them bad team players.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Krzysztof Kozlowski @ 2017-12-12 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ad03e2a8-00eb-464e-6983-374f83b9abf5@collabora.com>
On Tue, Dec 12, 2017 at 11:43 AM, Guillaume Tucker
<guillaume.tucker@collabora.com> wrote:
> On 12/12/17 10:17, Marek Szyprowski wrote:
>>
>> Hi Krzysztof,
>>
>> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>>>
>>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org>
>>> wrote:
>>>>
>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>> <javierm@redhat.com> wrote:
>>>>>
>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos
>>>>> 542x
>>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and
>>>>> enabled
>>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for
>>>>> the
>>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC
>>>>> variant.
>>>>>
>>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos
>>>>> 542x Mixer nodes")
>>>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - Remove RFT tag.
>>>>
>>>> Thanks guys! However I still would like to see a tested-by for this on
>>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>>>
>>> On the other hand I could just apply it for my for-next branch and
>>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>>> testing but apparently no one has Peach Pi.
>>
>>
>> Frankly, I don't expect that this will solve the boot hang issue on
>> PeachPi.
>> However it should at least hide the unbalanced regulator issue.
>
>
> We have a peach-pi in our LAVA lab so I've tested it and
> actually, it does fix the hang on v4.15-rc3:
>
> https://lava.collabora.co.uk/scheduler/job/1019877
> https://lava.collabora.co.uk/scheduler/job/1019878
>
> I ran it twice and it booted both times. I also ran the same
> boot tests with the same kernel but the dtb from v4.15-rc3
> without the fix to double check and these failed:
>
> https://lava.collabora.co.uk/scheduler/job/1019879
> https://lava.collabora.co.uk/scheduler/job/1019880
>
>
> Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Thank you!
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Javier Martinez Canillas @ 2017-12-12 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ad03e2a8-00eb-464e-6983-374f83b9abf5@collabora.com>
[adding Inki to cc list]
Hello Guillaume,
On 12/12/2017 11:43 AM, Guillaume Tucker wrote:
> On 12/12/17 10:17, Marek Szyprowski wrote:
>> Hi Krzysztof,
>>
>> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>>> <javierm@redhat.com> wrote:
>>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>>>
>>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>>
>>>>> ---
>>>>>
>>>>> Changes in v2:
>>>>> - Remove RFT tag.
>>>> Thanks guys! However I still would like to see a tested-by for this on
>>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>>> On the other hand I could just apply it for my for-next branch and
>>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>>> testing but apparently no one has Peach Pi.
>>
>> Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
>> However it should at least hide the unbalanced regulator issue.
>
> We have a peach-pi in our LAVA lab so I've tested it and
> actually, it does fix the hang on v4.15-rc3:
>
> https://lava.collabora.co.uk/scheduler/job/1019877
> https://lava.collabora.co.uk/scheduler/job/1019878
>
> I ran it twice and it booted both times. I also ran the same
> boot tests with the same kernel but the dtb from v4.15-rc3
> without the fix to double check and these failed:
>
> https://lava.collabora.co.uk/scheduler/job/1019879
> https://lava.collabora.co.uk/scheduler/job/1019880
>
>
> Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
>
>
> Thanks for the fix!
>
Thanks for testing!
Now, I think the exynos-drm driver should cope with an incorrect DTB and
don't crash the machine, the driver should only fail to probe and lead
to a working machine with no display.
But as mentioned, that's a different issue and orthogonal to the DTS fix.
> Guillaume
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
^ permalink raw reply
* [PATCH V2 1/2] arm64: Re-order reserved_ttbr0 in linker script
From: Steve Capper @ 2017-12-12 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-urwMWX-Tj+WPt=GaqXd09O1zrLYYLf1Jf__Lod7VLtg@mail.gmail.com>
On Mon, Dec 04, 2017 at 02:13:38PM +0000, Ard Biesheuvel wrote:
> On 23 November 2017 at 16:40, Steve Capper <steve.capper@arm.com> wrote:
> > Currently one resolves the location of the reserved_ttbr0 for PAN by
> > taking a positive offset from swapper_pg_dir. In a future patch we wish
> > to extend the swapper s.t. its size is determined at link time rather
> > than compile time, rendering SWAPPER_DIR_SIZE unsuitable for such a low
> > level calculation.
> >
> > In this patch we re-arrange the order of the linker script s.t. instead
> > one computes reserved_ttbr0 by subtracting RESERVED_TTBR0_SIZE from
> > swapper_pg_dir.
> >
> > Signed-off-by: Steve Capper <steve.capper@arm.com>
> > Acked-by: Mark Rutland <mark.rutland@arm.com>
> > ---
> > arch/arm64/include/asm/asm-uaccess.h | 6 +++---
> > arch/arm64/include/asm/uaccess.h | 2 +-
> > arch/arm64/kernel/vmlinux.lds.S | 5 ++---
> > 3 files changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/asm-uaccess.h b/arch/arm64/include/asm/asm-uaccess.h
> > index b3da6c886835..e09f02cd3e7a 100644
> > --- a/arch/arm64/include/asm/asm-uaccess.h
> > +++ b/arch/arm64/include/asm/asm-uaccess.h
> > @@ -12,9 +12,9 @@
> > */
> > #ifdef CONFIG_ARM64_SW_TTBR0_PAN
> > .macro __uaccess_ttbr0_disable, tmp1
> > - mrs \tmp1, ttbr1_el1 // swapper_pg_dir
> > - add \tmp1, \tmp1, #SWAPPER_DIR_SIZE // reserved_ttbr0 at the end of swapper_pg_dir
> > - msr ttbr0_el1, \tmp1 // set reserved TTBR0_EL1
> > + mrs \tmp1, ttbr1_el1 // swapper_pg_dir
> > + sub \tmp1, \tmp1, #RESERVED_TTBR0_SIZE // reserved_ttbr0 just before swapper_pg_dir
> > + msr ttbr0_el1, \tmp1 // set reserved TTBR0_EL1
> > isb
> > .endm
> >
> > diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
> > index fc0f9eb66039..66170fd4b58f 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -108,7 +108,7 @@ static inline void __uaccess_ttbr0_disable(void)
> > unsigned long ttbr;
> >
> > /* reserved_ttbr0 placed at the end of swapper_pg_dir */
>
> You missed a comment here ^^^
>
Thanks, I will update this.
> > - ttbr = read_sysreg(ttbr1_el1) + SWAPPER_DIR_SIZE;
> > + ttbr = read_sysreg(ttbr1_el1) - RESERVED_TTBR0_SIZE;
> > write_sysreg(ttbr, ttbr0_el1);
> > isb();
> > }
> > diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> > index 7da3e5c366a0..2a9475733e84 100644
> > --- a/arch/arm64/kernel/vmlinux.lds.S
> > +++ b/arch/arm64/kernel/vmlinux.lds.S
> > @@ -206,13 +206,12 @@ SECTIONS
> > . = ALIGN(PAGE_SIZE);
> > idmap_pg_dir = .;
> > . += IDMAP_DIR_SIZE;
> > - swapper_pg_dir = .;
> > - . += SWAPPER_DIR_SIZE;
> > -
> > #ifdef CONFIG_ARM64_SW_TTBR0_PAN
> > reserved_ttbr0 = .;
> > . += RESERVED_TTBR0_SIZE;
> > #endif
> > + swapper_pg_dir = .;
> > + . += SWAPPER_DIR_SIZE;
> >
> > __pecoff_data_size = ABSOLUTE(. - __initdata_begin);
> > _end = .;
>
> With that fixed,
>
> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Thanks Ard!
Cheers,
--
Steve
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Guillaume Tucker @ 2017-12-12 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a42670aa-b3df-7a53-8ed2-f3acd97fd0d4@samsung.com>
On 12/12/17 10:17, Marek Szyprowski wrote:
> Hi Krzysztof,
>
> On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
>> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>>> <javierm@redhat.com> wrote:
>>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>>
>>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>>
>>>> ---
>>>>
>>>> Changes in v2:
>>>> - Remove RFT tag.
>>> Thanks guys! However I still would like to see a tested-by for this on
>>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>> On the other hand I could just apply it for my for-next branch and
>> we'll see if it fixes kernel-ci boot tests... Not a nice way of
>> testing but apparently no one has Peach Pi.
>
> Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
> However it should at least hide the unbalanced regulator issue.
We have a peach-pi in our LAVA lab so I've tested it and
actually, it does fix the hang on v4.15-rc3:
https://lava.collabora.co.uk/scheduler/job/1019877
https://lava.collabora.co.uk/scheduler/job/1019878
I ran it twice and it booted both times. I also ran the same
boot tests with the same kernel but the dtb from v4.15-rc3
without the fix to double check and these failed:
https://lava.collabora.co.uk/scheduler/job/1019879
https://lava.collabora.co.uk/scheduler/job/1019880
Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Thanks for the fix!
Guillaume
^ permalink raw reply
* [PATCH 4/4] [v4] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Linus Walleij @ 2017-12-12 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512170904-4749-5-git-send-email-timur@codeaurora.org>
On Sat, Dec 2, 2017 at 12:28 AM, Timur Tabi <timur@codeaurora.org> wrote:
> /* Query the number of GPIOs from ACPI */
> ret = device_property_read_u32(&pdev->dev, "num-gpios", &num_gpios);
> if (ret < 0) {
> - dev_warn(&pdev->dev, "missing num-gpios property\n");
> + dev_err(&pdev->dev, "missing 'num-gpios' property\n");
> return ret;
> }
It's unfortunate that this driver uses the undocumented "num-gpios"
when the device tree bindings already has standardized "ngpios"
as the name for this.
Maybe it was not standardized back in 2015 when this driver was merged.
Or we were all sloppy :/
> + /* The number of GPIOs in the approved list */
> + ret = device_property_read_u16_array(&pdev->dev, "gpios",
> + NULL, 0);
> + if (ret < 0) {
> + dev_err(&pdev->dev, "missing 'gpios' property\n");
> + return ret;
> + }
This is in direct conflict with the existing "gpios" binding in device tree.
Where is this name coming from? ACPI standards?
If device tree and ACPI start defining things which are in direct conflict
we can just shut down this device_property() business altogether,
it will never work that way.
I would try to merge a DT bindings doc defining "valid-gpios" or something
like this, can we proceed like that?
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2 2/2] acpi, x86: Use SPCR table for earlycon on x86
From: Ingo Molnar @ 2017-12-12 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171211155059.17062-3-prarit@redhat.com>
* Prarit Bhargava <prarit@redhat.com> wrote:
> The ACPI SPCR code has been used to define an earlycon console for ARM64
> and can be used for x86.
>
> Modify the ACPI SPCR parsing code to account for console behaviour
> differences between ARM64 and x86. Initialize the SPCR code from
> x86 ACPI initialization code.
>
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
> Cc: linux-doc at vger.kernel.org
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-pm at vger.kernel.org
> Cc: linux-acpi at vger.kernel.org
> Cc: linux-serial at vger.kernel.org
> Cc: Bhupesh Sharma <bhsharma@redhat.com>
> Cc: Lv Zheng <lv.zheng@intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86 at kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Timur Tabi <timur@codeaurora.org>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 3 +++
> arch/arm64/kernel/acpi.c | 2 +-
> arch/x86/kernel/acpi/boot.c | 4 ++++
> drivers/acpi/Kconfig | 2 +-
> drivers/acpi/spcr.c | 7 +++++--
> include/linux/acpi.h | 7 +++++--
> 6 files changed, 19 insertions(+), 6 deletions(-)
LGTM from an x86 perspective:
Acked-by: Ingo Molnar <mingo@kernel.org>
(assuming it causes no regressions in linux-next.)
Since patch #1 affects ARM64 significantly, once that patch is acceptable to the
arm64 folks feel free to upstream this second patch via the ARM64 tree as well.
Thanks,
Ingo
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Javier Martinez Canillas @ 2017-12-12 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc1_n2cdgjuFbA9jNdcSXxfr8Zjf=fUx_jt_N3+LP0n8A@mail.gmail.com>
Hello Krzysztof,
On 12/12/2017 11:09 AM, Krzysztof Kozlowski wrote:
> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>> <javierm@redhat.com> wrote:
>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>
>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Remove RFT tag.
I removed the tag because Marek acked it and the patch has merits on its own
regardless of the boot issue (it just introduces a change that was missed in
the mentioned commit).
>>
>> Thanks guys! However I still would like to see a tested-by for this on
>> Peach Pi (AFAIU, Marek's only acked the code/solution).
>
> On the other hand I could just apply it for my for-next branch and
> we'll see if it fixes kernel-ci boot tests... Not a nice way of
As Marek said this probably won't solve the issue, or at best it would just
mask it. Seems the problem is on the probe deferral path in exynos-drm driver.
> testing but apparently no one has Peach Pi.
>
I do have one, but I haven't used it for months and don't have time to setup
a test environment now. I will probably do that this weekend to dig deeper.
> Best regards,
> Krzysztof
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
^ permalink raw reply
* [PATCH v5 15/30] arm64/sve: Signal handling support
From: Will Deacon @ 2017-12-12 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGXu5j+2MNOnAfstr8RyD0Orrt37ewL8uE2N8e3fL--fNPs3TQ@mail.gmail.com>
On Mon, Dec 11, 2017 at 11:23:09AM -0800, Kees Cook wrote:
> On Mon, Dec 11, 2017 at 6:07 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Thu, Dec 07, 2017 at 10:50:38AM -0800, Kees Cook wrote:
> >> My question is mainly: why not just use copy_*() everywhere instead?
> >> Having these things so spread out makes it fragile, and there's very
> >> little performance benefit from using __copy_*() over copy_*().
> >
> > I think that's more of a general question. Why not just remove the __
> > versions from the kernel entirely if they're not worth the perf?
>
> That has been something Linus has strongly suggested in the past, so
> I've kind of been looking for easy places to drop the __copy_*
> versions. :)
Tell you what then: I'll Ack the arm64 patch if it's part of a series
removing the thing entirely :p
I guess we'd still want to the validation of the whole sigframe though,
so we don't end up pushing half a signal stack before running into an
access_ok failure?
Will
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Will Deacon @ 2017-12-12 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXh_6FaV-SFGWxcBb1-NNGYngDrYnnWA=9Y6xmRAkcxqg@mail.gmail.com>
Hi Geert,
On Tue, Dec 12, 2017 at 11:20:09AM +0100, Geert Uytterhoeven 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)
> 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.
Urgh, this looks nasty. Thanks for the report! A few questions:
- Can you share your .config somewhere please?
- What was your last known-good kernel?
- Have you seen it on any other Soc?
- What's the CPU in your SoC?
If I can reproduce the failure here, then I should be able to debug ASAP.
Cheers,
Will
^ permalink raw reply
* [PATCH v2 17/18] arm64: Kconfig: Add CONFIG_UNMAP_KERNEL_AT_EL0
From: Will Deacon @ 2017-12-12 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdXn5vVxrtD=-+X_SQVX9PXcKQ=9Qh3Xx+M1MoCQ-EWRZQ@mail.gmail.com>
On Tue, Dec 12, 2017 at 09:44:09AM +0100, Geert Uytterhoeven wrote:
> Hi Will,
>
> On Thu, Nov 30, 2017 at 5:39 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Add a Kconfig entry to control use of the entry trampoline, which allows
> > us to unmap the kernel whilst running in userspace and improve the
> > robustness of KASLR.
> >
> > Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> This is now commit 084eb77cd3a81134 in arm64/for-next/core.
>
> > ---
> > arch/arm64/Kconfig | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index fdcc7b9bb15d..3af1657fcac3 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -833,6 +833,19 @@ config FORCE_MAX_ZONEORDER
> > However for 4K, we choose a higher default value, 11 as opposed to 10, giving us
> > 4M allocations matching the default size used by generic code.
> >
> > +config UNMAP_KERNEL_AT_EL0
> > + bool "Unmap kernel when running in userspace (aka \"KAISER\")"
>
> But I believe this is no longer called KAISER?
That's right, but KAISER is the original name in the paper and so I figured
it was worth mentioning just here to help people identify what this feature
is. The command line option is "kpti" to align with x86.
Will
^ permalink raw reply
* arm64: unhandled level 0 translation fault
From: Geert Uytterhoeven @ 2017-12-12 10:20 UTC (permalink / raw)
To: linux-arm-kernel
Hi Catalin, Will, et al,
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)
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 ***
Do you have a clue?
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 v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Marek Szyprowski @ 2017-12-12 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc1_n2cdgjuFbA9jNdcSXxfr8Zjf=fUx_jt_N3+LP0n8A@mail.gmail.com>
Hi Krzysztof,
On 2017-12-12 11:09, Krzysztof Kozlowski wrote:
> On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
>> <javierm@redhat.com> wrote:
>>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>>
>>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Remove RFT tag.
>> Thanks guys! However I still would like to see a tested-by for this on
>> Peach Pi (AFAIU, Marek's only acked the code/solution).
> On the other hand I could just apply it for my for-next branch and
> we'll see if it fixes kernel-ci boot tests... Not a nice way of
> testing but apparently no one has Peach Pi.
Frankly, I don't expect that this will solve the boot hang issue on PeachPi.
However it should at least hide the unbalanced regulator issue.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* mainline/master boot bisection: v4.15-rc3 on peach-pi #3228-staging
From: Krzysztof Kozlowski @ 2017-12-12 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <88bebc9d-a889-403b-a742-c11ad6617638@samsung.com>
On Tue, Dec 12, 2017 at 9:47 AM, Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> Hi Javier,
>
> On 2017-12-12 09:00, Javier Martinez Canillas wrote:
>>
>> On Tue, Dec 12, 2017 at 8:54 AM, Marek Szyprowski
>> <m.szyprowski@samsung.com> wrote:
(...)
>>> This warning has been added intentionally, see following discussions:
>>> https://patchwork.kernel.org/patch/10034919/
>>> https://patchwork.kernel.org/patch/10070475/
>>>
>>> This means that your test apps should be updated or you should enable
>>> Exynos
>>> IOMMU support in your config. Maybe it is a good time to finally enable
>>> it
>>> in exynos_defconfig.
>>>
>> Has the issue that the boot-loader keeps the display controller
>> enabled and scanning pages on the Exynos Chromebooks resolved?
>>
>> I think that's that preventing to enable it by default in
>> exynos_defconfig since it caused boot failures when enabled on these
>> machines. I don't follow exynos development too closely nowadays so
>> maybe there's a fix in place now.
>
>
> Not directly. I still didn't find time to properly add support for
> devices, which were left in-working state (with active DMA
> transactions) by bootloader, but due to some other changes in the
> order of operations during boot process, power domains are
> initialized very early and due to temporary lack of devices (which
> are not yet added to the system), are turned off. This practically
> stops FIMD for scanning framebuffer and "solves" this issue.
>
> I've checked now and Exynos Snow Chromebook boots fine with IOMMU
> support enabled, both with v4.15-rc3 and linux-next.
Then it looks like we could give EXYNOS_IOMMU a try. At least only on
exynos_defconfig which would leave multi_v7 as a platform to compare.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Krzysztof Kozlowski @ 2017-12-12 10:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJKOXPc1rJCWABXUuyU2MKxnLY-MptrM9Mm0HyHVCJn870R+sg@mail.gmail.com>
On Tue, Dec 12, 2017 at 10:55 AM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
> <javierm@redhat.com> wrote:
>> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
>> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
>> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
>> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>>
>> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
>> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
>> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>>
>> ---
>>
>> Changes in v2:
>> - Remove RFT tag.
>
> Thanks guys! However I still would like to see a tested-by for this on
> Peach Pi (AFAIU, Marek's only acked the code/solution).
On the other hand I could just apply it for my for-next branch and
we'll see if it fixes kernel-ci boot tests... Not a nice way of
testing but apparently no one has Peach Pi.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 4/4] [v4] pinctrl: qcom: qdf2xxx: add support for new ACPI HID QCOM8002
From: Andy Shevchenko @ 2017-12-12 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512170904-4749-5-git-send-email-timur@codeaurora.org>
On Fri, 2017-12-01 at 17:28 -0600, Timur Tabi wrote:
> Newer versions of the firmware for the Qualcomm Datacenter
> Technologies
> QDF2400 restricts access to a subset of the GPIOs on the TLMM. To
> prevent older kernels from accidentally accessing the restricted
> GPIOs,
> we change the ACPI HID for the TLMM block from QCOM8001 to QCOM8002,
> and introduce a new property "gpios". This property is an array of
> specific GPIOs that are accessible. When an older kernel boots on
> newer (restricted) firmware, it will fail to probe.
>
> To implement the sparse GPIO map, we register all of the GPIOs, but
> set
> the pin count for the unavailable GPIOs to zero. The pinctrl-msm
> driver will block those unavailable GPIOs from being accessed.
>
> To allow newer kernels to support older firmware, the driver retains
> support for QCOM8001.
> +static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
> + {"QCOM8001", QDF2XXX_V1},
> + {"QCOM8002", QDF2XXX_V2},
> + {},
> +};
> +MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
>
> + const struct acpi_device_id *id =
> + acpi_match_device(qdf2xxx_acpi_ids, &pdev->dev);
JFYI: there is no need to move IDs like this.
Use members of struct device_driver wisely.
> -static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
> - {"QCOM8001"},
> - {},
> -};
> -MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH 0/4] Sunxi: Add SMP support on A83T
From: Mylene JOSSERAND @ 2017-12-12 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212104025.0bba3685@dell-desktop.home>
Le Tue, 12 Dec 2017 10:40:25 +0100,
Mylene JOSSERAND <mylene.josserand@free-electrons.com> a ?crit :
[...]
> I have done further tests.
>
> I booted a previous kernel that I know it was working fine (kernel
> v4.13) then, I booted the kernel with this series and it worked just
> fine.
>
> Only after a power cycle, I am able to reproduce the error, otherwise,
> it is working well. See the boot log of this two tests:
> http://code.bulix.org/7kr0e0-239697?raw
I wrote this mail too fast, I am wrong, the error I had/copied is not
the same error than Corentin is having (and I have 8 CPUS up).
--
Myl?ne Josserand, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 2/4] [v2] gpiolib: add bitmask for valid GPIO lines
From: Andy Shevchenko @ 2017-12-12 9:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512170904-4749-3-git-send-email-timur@codeaurora.org>
On Fri, 2017-12-01 at 17:28 -0600, Timur Tabi wrote:
> Add support for specifying that some GPIOs within a range are
> unavailable.
> Some systems have a sparse list of GPIOs, where a range of GPIOs is
> specified (usually 0 to n-1), but some subset within that range is
> absent or unavailable for whatever reason.
>
> To support this, allow drivers to specify a bitmask of GPIOs that
> are present or absent. Gpiolib will then block access to those that
> are absent.
> - status = gpiochip_irqchip_init_valid_mask(chip);
> + status = gpiochip_init_valid_mask(chip);
> if (status)
> goto err_remove_from_list;
>
> + status = gpiochip_irqchip_init_valid_mask(chip);
> + if (status)
> + goto err_remove_valid_mask;
Yes, this way it looks good!
> +static bool gpiochip_available(const struct gpio_chip *gpiochip,
> + unsigned int offset)
> +{
> + pr_info("%s:%u offset=%u\n", __func__, __LINE__, offset);
Debug leftover?
> +
> + /* No mask means all valid */
> + if (likely(!gpiochip->valid_mask))
> + return true;
> +
> + return test_bit(offset, gpiochip->valid_mask);
Not sure which one is better
return test_bit();
or
return !!test_bit();
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* [PATCH v2] ARM: dts: exynos: Enable Mixer node for Exynos5800 Peach Pi machine
From: Krzysztof Kozlowski @ 2017-12-12 9:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212074208.30753-1-javierm@redhat.com>
On Tue, Dec 12, 2017 at 8:42 AM, Javier Martinez Canillas
<javierm@redhat.com> wrote:
> Commit 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x
> Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
> for each Exynos 542x DTS. But unfortunately it missed to enable it for the
> Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.
>
> Fixes: 1cb686c08d12 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
> ---
>
> Changes in v2:
> - Remove RFT tag.
Thanks guys! However I still would like to see a tested-by for this on
Peach Pi (AFAIU, Marek's only acked the code/solution).
Best regards,
Krzysztof
> - Add Marek's Acked-by tag.
> - Add fixes tag.
>
> arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> index b2b95ff205e8..0029ec27819c 100644
> --- a/arch/arm/boot/dts/exynos5800-peach-pi.dts
> +++ b/arch/arm/boot/dts/exynos5800-peach-pi.dts
> @@ -664,6 +664,10 @@
> status = "okay";
> };
>
> +&mixer {
> + status = "okay";
> +};
> +
> /* eMMC flash */
> &mmc_0 {
> status = "okay";
> --
> 2.14.3
>
^ permalink raw reply
* [BUG] atmel_ssc_dai: a possible sleep-in-atomic bug in atmel_ssc_shutdown
From: Jia-Ju Bai @ 2017-12-12 9:52 UTC (permalink / raw)
To: linux-arm-kernel
According to sound/soc/atmel/atmel_ssc_dai.c, the driver may sleep under
a spinlock.
The function call path is:
atmel_ssc_shutdown (acquire the spinlock)
free_irq --> may sleep
I do not find a good way to fix it, so I only report.
This possible bug is found by my static analysis tool (DSAC) and checked
by my code review.
Thanks,
Jia-Ju Bai
^ permalink raw reply
* [PATCH 3/3] arm64: dts: renesas: r8a7796: add reg properties to pciec[01] nodes
From: Geert Uytterhoeven @ 2017-12-12 9:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082436.12210-4-horms+renesas@verge.net.au>
On Tue, Dec 12, 2017 at 9:24 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Add reg properties to pciec[01] placeholder nodes
>
> This is to stop the compiler complaining as follows:
> $ make
> ...
> DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7796-m3ulcb-kf.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
> DTC arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at fe000000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (unit_address_vs_reg): Node /soc/pcie at ee800000 has a unit name, but no reg property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pcie at fe000000 missing or empty reg/ranges property
> arch/arm64/boot/dts/renesas/r8a7796-salvator-xs.dtb: Warning (simple_bus_reg): Node /soc/pcie at ee800000 missing or empty reg/ranges property
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [Patch v6 10/12] [media] v4l2: Add v4l2 control IDs for HEVC encoder
From: Sylwester Nawrocki @ 2017-12-12 9:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513046086.22129.2.camel@smitha-fedora>
On 12/12/2017 03:34 AM, Smitha T Murthy wrote:
>> s/Lay/Layer here and below
>>
> Ok I will change it.
While it's fine to make such change for controls up to V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_QP...
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_QP: return "HEVC Hierarchical Lay 1 QP";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_QP: return "HEVC Hierarchical Lay 2 QP";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_QP: return "HEVC Hierarchical Lay 3 QP";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_QP: return "HEVC Hierarchical Lay 4 QP";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_QP: return "HEVC Hierarchical Lay 5 QP";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_QP: return "HEVC Hierarchical Lay 6 QP";
...for the controls below we may need to replace "Lay" with "L."
to make sure the length of the string don't exceed 31 characters
(32 with terminating NULL). The names below seem to be 1 character
too long and will be truncated when running VIDIOC_QUERY_CTRL ioctl.
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L0_BR: return "HEVC Hierarchical Lay 0 Bit Rate";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L1_BR: return "HEVC Hierarchical Lay 1 Bit Rate";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L2_BR: return "HEVC Hierarchical Lay 2 Bit Rate";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L3_BR: return "HEVC Hierarchical Lay 3 Bit Rate";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L4_BR: return "HEVC Hierarchical Lay 4 Bit Rate";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L5_BR: return "HEVC Hierarchical Lay 5 Bit Rate";
>>> + case V4L2_CID_MPEG_VIDEO_HEVC_HIER_CODING_L6_BR: return "HEVC Hierarchical Lay 6 Bit Rate";
--
Regards,
Sylwester
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r8a7795: sort subnodes of root node alphabetically
From: Geert Uytterhoeven @ 2017-12-12 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171212082752.12806-1-horms+renesas@verge.net.au>
On Tue, Dec 12, 2017 at 9:27 AM, Simon Horman
<horms+renesas@verge.net.au> wrote:
> Sort root sub-nodes alphabetically for allow for easier maintenance
> of this file.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox