* Re: [PATCH -next 25/36] spi: s3c24xx: use devm_platform_ioremap_resource() to simplify code
From: Mark Brown @ 2019-09-04 16:13 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: tmaimon77, palmer, tali.perry1, eric, ldewangan, linux-riscv,
festevam, f.fainelli, benjaminfair, shc_work, khilman, openbmc,
YueHaibing, michal.simek, jonathanh, yuenn, wens, agross,
bcm-kernel-feedback-list, linux-imx, linux-arm-msm, linux-tegra,
Andi Shyti, rjui, s.hauer, mripard,
linux-samsung-soc@vger.kernel.org, linux-mediatek,
linux-rpi-kernel, paul.walmsley, matthias.bgg, linux-amlogic,
linux-arm-kernel, baohua, sbranden, yamada.masahiro, avifishman70,
venture, linux-kernel@vger.kernel.org, linux-spi, thierry.reding,
wahrenst, kernel, kgene, shawnguo
In-Reply-To: <CAJKOXPeRtbAvmR-=8Qa8ukGXt-cCj3ud_7y1Z4LgRpX3YCeumg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1366 bytes --]
On Wed, Sep 04, 2019 at 05:09:45PM +0200, Krzysztof Kozlowski wrote:
> On Wed, 4 Sep 2019 at 16:39, Mark Brown <broonie@kernel.org> wrote:
> > I think it's reasonable, it's giving credit to the automated system
> > they've got running coccinelle (which they do mention in their commit
> > logs). It doesn't really hurt anyone and lets people see their system
> > is finding stuff.
> Running internally coccinelle is already credited with commit author.
> The credits are coming with "From:" field.
I guess if other people look at the same CI and send patches as well
then there's some use tying them all together.
> Otherwise for commits I send I could use:
> From: krzk
> ...
> Reported-by: www.krzk.eu
> Signed-off-by: krzk
> To me it is ridiculous.
Sure, on the other hand it doesn't really cost anyone anything if you do
that.
> Different thing is that Reported-by is for fixing bugs or issues.
> There is no bug here. There is no problem solved except making the
> code smaller. That's not what is Reported-by for.
That is true, this one isn't fixing any bug but then the line does get a
bit fuzzy all round with things like warnings and coccinelle output -
even just having the warning pop up is noise for people looking at the
output even if there's no concrete problem. Again I don't see it as
something that's worth getting worked up over.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 09/11] coresight: etm4x: docs: Update ABI doc for sysfs features added.
From: Greg KH @ 2019-09-04 16:17 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Jon Corbet, Coresight ML, open list:DOCUMENTATION,
linux-arm-kernel, Suzuki K. Poulose, Mike Leach
In-Reply-To: <CANLsYkySX_3fGi4WLKHr7bv2=_j2UMyaTXCrwHSnzR-oH1V_ZQ@mail.gmail.com>
On Wed, Sep 04, 2019 at 10:05:51AM -0600, Mathieu Poirier wrote:
> On Tue, 3 Sep 2019 at 23:48, Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Sep 03, 2019 at 04:51:40PM -0600, Mathieu Poirier wrote:
> > > On Tue, 3 Sep 2019 at 13:59, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > >
> > > > On Thu, Aug 29, 2019 at 10:33:19PM +0100, Mike Leach wrote:
> > > > > Update document to include the new sysfs features added during this
> > > > > patchset.
> > > > >
> > > > > Updated to reflect the new sysfs component nameing schema.
> > > > >
> > > > > Signed-off-by: Mike Leach <mike.leach@linaro.org>
> > > > > ---
> > > > > .../testing/sysfs-bus-coresight-devices-etm4x | 183 +++++++++++-------
> > > > > 1 file changed, 115 insertions(+), 68 deletions(-)
> > > > >
> > > > > diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > > index 36258bc1b473..112c50ae9986 100644
> > > > > --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > > +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
> > > > > @@ -1,4 +1,4 @@
> > > > > -What: /sys/bus/coresight/devices/<memory_map>.etm/enable_source
> > > > > +What: /sys/bus/coresight/devices/etm<N>/enable_source
> > > >
> > > > You are renaming sysfs directories that have been around since:
> > > >
> > > > > Date: April 2015
> > > >
> > > > ???
> > > >
> > > > Really?
> > > >
> > > > That's brave.
> > >
> > >
> > > When I worked on the coresight sysfs ABI a while back I specifically
> > > added it at the "testing" level as I was well aware that things could
> > > change in the future. According to the guidelines in the
> > > documentation userspace can rely on it which was accurate since the
> > > interface didn't change for 4 years. But the guidelines also mention
> > > that changes can occur before the interfaces are move to stables, and
> > > that programs are encouraged to manifest their interest by adding
> > > their name to the "users" field.
> > >
> > > The interface was changed in 5.2 to support coresight from ACPI and
> > > make things easier to understand for users. It is a lot more
> > > intuitive to associate an ETM tracer with the CPU it belongs to by
> > > referring to the CPU number than the memory mapped address. Given the
> > > "testing" status of the interface and the absence of registered users
> > > I decided to move forward with the change. If "testing" is too strict
> > > for that I suggest to add an "experimental" category where it would be
> > > more acceptable to change things as subsystems mature.
> >
> > "testing" is not really "testing" if you have userspace tools/programs
> > assuming the location and contents of specific files in sysfs.
> >
> > You can change things in sysfs by creating new files, but to do
> > wholesale renaming like you did here can be very dangerous as you might
> > be breaking things.
>
> Yes, something I have definitely considered.
>
> > Usually new files are created, not existing ones
> > moved.
>
> In this case it would have meant a new symbolic link for every
> coresight device, so twice a many entries under
> $(SYS)/bus/coresight/device/. That would have been a lot of clutter
> and an increasing source of problems as the number of CPU and sinks
> increases. To me, and given the permissive definition of "testing"
> found in the documentation, a clean break was a better option.
Well, "testing" doesn't really matter in the end, if a tool/user relies
on it, we have to keep it working properly.
> > What tools use these today? What is going to break?
>
> Other than local shell scripts I am not aware of any tools using these
> today. I am certainly open to discuss a better alternative but right
> now, I just don't see one.
Be aware that you might have to change this back if there is any
objections.
thanks,
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v18 15/15] selftests, arm64: add a selftest for passing tagged pointers to kernel
From: Cristian Marussi @ 2019-09-04 16:22 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Mark Rutland, kvm, Szabolcs Nagy, Catalin Marinas, Will Deacon,
dri-devel, Linux Memory Management List, Khalid Aziz,
open list:KERNEL SELFTEST FRAMEWORK, Felix Kuehling,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Dave Martin, Evgeniy Stepanov, linux-media, Kevin Brodsky,
Kees Cook, Ruben Ayrapetyan, Ramana Radhakrishnan,
Alex Williamson, Mauro Carvalho Chehab, Linux ARM,
Kostya Serebryany, Greg Kroah-Hartman, Yishai Hadas, LKML,
Jens Wiklander, Lee Smith, Alexander Deucher, Andrew Morton, enh,
Robin Murphy, Christian Koenig, Luc Van Oostenryck
In-Reply-To: <CAAeHK+xXN_oHt0rAcWdTs0XhkYRhWqf3iv-n+dYmY075xosJnw@mail.gmail.com>
Hi Andrey !
On 04/09/2019 15:52, Andrey Konovalov wrote:
> On Fri, Aug 23, 2019 at 7:49 PM Cristian Marussi
> <cristian.marussi@arm.com> wrote:
>>
>>
>> Hi
>>
>> On 23/08/2019 18:16, Andrey Konovalov wrote:
>>> On Fri, Aug 23, 2019 at 3:56 PM Cristian Marussi
>>> <cristian.marussi@arm.com> wrote:
>>>>
>>>> Hi Andrey
>>>>
>>>> On 24/06/2019 15:33, Andrey Konovalov wrote:
>>>>> This patch is a part of a series that extends kernel ABI to allow to pass
>>>>> tagged user pointers (with the top byte set to something else other than
>>>>> 0x00) as syscall arguments.
>>>>>
>>>>> This patch adds a simple test, that calls the uname syscall with a
>>>>> tagged user pointer as an argument. Without the kernel accepting tagged
>>>>> user pointers the test fails with EFAULT.
>>>>>
>>>>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
>>>>> ---
>>>>> tools/testing/selftests/arm64/.gitignore | 1 +
>>>>> tools/testing/selftests/arm64/Makefile | 11 +++++++
>>>>> .../testing/selftests/arm64/run_tags_test.sh | 12 ++++++++
>>>>> tools/testing/selftests/arm64/tags_test.c | 29 +++++++++++++++++++
>>>>> 4 files changed, 53 insertions(+)
>>>>> create mode 100644 tools/testing/selftests/arm64/.gitignore
>>>>> create mode 100644 tools/testing/selftests/arm64/Makefile
>>>>> create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
>>>>> create mode 100644 tools/testing/selftests/arm64/tags_test.c
>>>>
>>>> After building a fresh Kernel from arm64/for-next-core from scratch at:
>>>>
>>>> commit 239ab658bea3b387424501e7c416640d6752dc0c
>>>> Merge: 6bfa3134bd3a 42d038c4fb00 1243cb6a676f d55c5f28afaf d06fa5a118f1 34b5560db40d
>>>> Author: Will Deacon <will@kernel.org>
>>>> Date: Thu Aug 22 18:23:53 2019 +0100
>>>>
>>>> Merge branches 'for-next/error-injection', 'for-next/tbi', 'for-next/psci-cpuidle', 'for-next/cpu-topology' and 'for-next/52-bit-kva' into for-next/core
>>>>
>>>>
>>>> KSFT arm64 tests build is broken for me, both setting or not KBUILD_OUTPUT=
>>>>
>>>> 13:30 $ make TARGETS=arm64 kselftest-clean
>>>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>>>> rm -f -r /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
>>>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>>>>
>>>> ✔ ~/ARM/dev/src/pdsw/linux [arm64_for_next_core|…8⚑ 23]
>>>>
>>>> 13:30 $ make TARGETS=arm64 kselftest
>>>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>>>> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
>>>> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
>>>> ARCH=arm64 -C ../../.. headers_install
>>>> HOSTCC scripts/basic/fixdep
>>>> HOSTCC scripts/unifdef
>>>> ...
>>>> ...
>>>> HDRINST usr/include/asm/msgbuf.h
>>>> HDRINST usr/include/asm/shmbuf.h
>>>> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/usr/include
>>>> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
>>>> tags_test.c: In function ‘main’:
>>>> tags_test.c:21:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
>>>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>>>> ^~~~~~~~~~~~~~~~~~~~~~~
>>>> PR_GET_TID_ADDRESS
>>>> tags_test.c:21:12: note: each undeclared identifier is reported only once for each function it appears in
>>>> tags_test.c:21:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
>>>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>>>> ^~~~~~~~~~~~~~~~~~~~~
>>>> PR_GET_DUMPABLE
>>>> ../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test' failed
>>>> make[3]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test] Error 1
>>>> Makefile:136: recipe for target 'all' failed
>>>> make[2]: *** [all] Error 2
>>>> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1237: recipe for target 'kselftest' failed
>>>> make[1]: *** [kselftest] Error 2
>>>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>>>> Makefile:179: recipe for target 'sub-make' failed
>>>> make: *** [sub-make] Error 2
>>>>
>>>> Despite seeing KSFT installing Kernel Headers, they cannot be found.
>>>>
>>>> Fixing this patch like this make it work for me:
>>>>
>>>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
>>>> index a61b2e743e99..f9f79fb272f0 100644
>>>> --- a/tools/testing/selftests/arm64/Makefile
>>>> +++ b/tools/testing/selftests/arm64/Makefile
>>>> @@ -4,6 +4,7 @@
>>>> ARCH ?= $(shell uname -m 2>/dev/null || echo not)
>>>>
>>>> ifneq (,$(filter $(ARCH),aarch64 arm64))
>>>> +CFLAGS += -I../../../../usr/include/
>>>> TEST_GEN_PROGS := tags_test
>>>> TEST_PROGS := run_tags_test.sh
>>>> endif
>>>>
>>>> but is not really a proper fix since it does NOT account for case in which you have
>>>> installed the Kernel Headers in a non standard location like when you use KBUILD_OUTPUT.
>>>>
>>>> Am I missing something ?
>>>
>>> Hm, PR_SET_TAGGED_ADDR_CTRL is defined in include/uapi/linux/prctl.h,
>>> and the test has #include <sys/prctl.h> so as long as you've updated
>>> your kernel headers this should work.
>>>
>>> (I'm OOO next week, I'll see if I can reproduce this once I'm back).
>>
>> Ok. Thanks for the reply.
>>
>> I think I've got it in my local tree having cloned arm64/for-next-core:
>>
>> 18:32 $ egrep -A 10 PR_SET_TAG ./include/uapi/linux/prctl.h
>> #define PR_SET_TAGGED_ADDR_CTRL 55
>> #define PR_GET_TAGGED_ADDR_CTRL 56
>> # define PR_TAGGED_ADDR_ENABLE (1UL << 0)
>>
>> #endif /* _LINUX_PRCTL_H */
>>
>> and Kernel header are locally installed in my kernel src dir (by KSFT indeed)
>>
>> 18:34 $ egrep -RA 10 PR_SET_TAG usr/include/
>> usr/include/linux/prctl.h:#define PR_SET_TAGGED_ADDR_CTRL 55
>> usr/include/linux/prctl.h-#define PR_GET_TAGGED_ADDR_CTRL 56
>> usr/include/linux/prctl.h-# define PR_TAGGED_ADDR_ENABLE (1UL << 0)
>> usr/include/linux/prctl.h-
>> usr/include/linux/prctl.h-#endif /* _LINUX_PRCTL_H */
>>
>> but how are they supposed to be found if nor the test Makefile
>> neither the KSFT Makefile who installs them pass any -I options to the
>> compiler ?
>> I suppose <sys/prctl.h> tries to include arch specific headers from the regular system path,
>> but when you are cross-compiling ?
>>
>> 18:34 $ make TARGETS=arm64 kselftest
>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
>> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
>> ARCH=arm64 -C ../../.. headers_install
>> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/usr/include
>> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -Wall -O2 -g tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test
>> tags_test.c: In function ‘main’:
>> tags_test.c:20:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>> ^~~~~~~~~~~~~~~~~~~~~~~
>> PR_GET_TID_ADDRESS
>> tags_test.c:20:12: note: each undeclared identifier is reported only once for each function it appears in
>> tags_test.c:20:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>> ^~~~~~~~~~~~~~~~~~~~~
>> PR_GET_DUMPABLE
>> ../../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test' failed
>> make[4]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test] Error 1
>> Makefile:19: recipe for target 'all' failed
>> make[3]: *** [all] Error 2
>> Makefile:137: recipe for target 'all' failed
>> make[2]: *** [all] Error 2
>> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1236: recipe for target 'kselftest' failed
>> make[1]: *** [kselftest] Error 2
>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
>> Makefile:179: recipe for target 'sub-make' failed
>> make: *** [sub-make] Error 2
>>
>>
>> In fact many KSFT testcases seems to brutally add default headers path:
>>
>> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/uapi/
>> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/
>> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../usr/include/
>> tools/testing/selftests/net/Makefile:CFLAGS += -I../../../../usr/include/
>> tools/testing/selftests/membarrier/Makefile:CFLAGS += -g -I../../../../usr/include/
>> ...
>
> Hi Cristian!
>
> Indeed, I can reproduce the issue. I don't know what's the proper way
> to resolve this. Adding "CFLAGS += -I../../../../usr/include/" looks
> good to me. AFAICS your series resolves this issue in a similar way,
> but I think we should fix this before the current rc is released. Do
> you want to submit a patch that adds this simple fix or should I do
> that?
>
Please feel free to post the single line patch above to quickly fix this before
release, so we don't have a broken build straight away. (our CI is already beating me...:D)
On my side (01/11) in the meantime I'll fix the top level KSFT arm64 makefile so as to calculate
and propagate once for all the headers search path down to all KSFT arm64/ in one go,
trying to guess where they are; this is needed because the above fix works fine as long
as you don't have KBUILD_OUTPUT set, once you set it, KSFT installs kheaders in a different
place and the above -I fix is fooled again....but this is a general problem also in other
KSFT tests as I can see now so I think this fix is good enough for now
(and the fix on my side, even if trivial, is not going to go into this release for sure)
Thanks !
Cheers
Cristian
> Thanks!
>
>>
>> Cheers
>>
>> Cristian
>>>
>>>
>>>
>>>>
>>>> Thanks
>>>>
>>>> Cristian
>>>>
>>>>>
>>>>> diff --git a/tools/testing/selftests/arm64/.gitignore b/tools/testing/selftests/arm64/.gitignore
>>>>> new file mode 100644
>>>>> index 000000000000..e8fae8d61ed6
>>>>> --- /dev/null
>>>>> +++ b/tools/testing/selftests/arm64/.gitignore
>>>>> @@ -0,0 +1 @@
>>>>> +tags_test
>>>>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
>>>>> new file mode 100644
>>>>> index 000000000000..a61b2e743e99
>>>>> --- /dev/null
>>>>> +++ b/tools/testing/selftests/arm64/Makefile
>>>>> @@ -0,0 +1,11 @@
>>>>> +# SPDX-License-Identifier: GPL-2.0
>>>>> +
>>>>> +# ARCH can be overridden by the user for cross compiling
>>>>> +ARCH ?= $(shell uname -m 2>/dev/null || echo not)
>>>>> +
>>>>> +ifneq (,$(filter $(ARCH),aarch64 arm64))
>>>>> +TEST_GEN_PROGS := tags_test
>>>>> +TEST_PROGS := run_tags_test.sh
>>>>> +endif
>>>>> +
>>>>> +include ../lib.mk
>>>>> diff --git a/tools/testing/selftests/arm64/run_tags_test.sh b/tools/testing/selftests/arm64/run_tags_test.sh
>>>>> new file mode 100755
>>>>> index 000000000000..745f11379930
>>>>> --- /dev/null
>>>>> +++ b/tools/testing/selftests/arm64/run_tags_test.sh
>>>>> @@ -0,0 +1,12 @@
>>>>> +#!/bin/sh
>>>>> +# SPDX-License-Identifier: GPL-2.0
>>>>> +
>>>>> +echo "--------------------"
>>>>> +echo "running tags test"
>>>>> +echo "--------------------"
>>>>> +./tags_test
>>>>> +if [ $? -ne 0 ]; then
>>>>> + echo "[FAIL]"
>>>>> +else
>>>>> + echo "[PASS]"
>>>>> +fi
>>>>> diff --git a/tools/testing/selftests/arm64/tags_test.c b/tools/testing/selftests/arm64/tags_test.c
>>>>> new file mode 100644
>>>>> index 000000000000..22a1b266e373
>>>>> --- /dev/null
>>>>> +++ b/tools/testing/selftests/arm64/tags_test.c
>>>>> @@ -0,0 +1,29 @@
>>>>> +// SPDX-License-Identifier: GPL-2.0
>>>>> +
>>>>> +#include <stdio.h>
>>>>> +#include <stdlib.h>
>>>>> +#include <unistd.h>
>>>>> +#include <stdint.h>
>>>>> +#include <sys/prctl.h>
>>>>> +#include <sys/utsname.h>
>>>>> +
>>>>> +#define SHIFT_TAG(tag) ((uint64_t)(tag) << 56)
>>>>> +#define SET_TAG(ptr, tag) (((uint64_t)(ptr) & ~SHIFT_TAG(0xff)) | \
>>>>> + SHIFT_TAG(tag))
>>>>> +
>>>>> +int main(void)
>>>>> +{
>>>>> + static int tbi_enabled = 0;
>>>>> + struct utsname *ptr, *tagged_ptr;
>>>>> + int err;
>>>>> +
>>>>> + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
>>>>> + tbi_enabled = 1;
>>>>> + ptr = (struct utsname *)malloc(sizeof(*ptr));
>>>>> + if (tbi_enabled)
>>>>> + tagged_ptr = (struct utsname *)SET_TAG(ptr, 0x42);
>>>>> + err = uname(tagged_ptr);
>>>>> + free(ptr);
>>>>> +
>>>>> + return err;
>>>>> +}
>>>>>
>>>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/4] gpio/aspeed: Fix incorrect number of banks
From: Andy Shevchenko @ 2019-09-04 16:27 UTC (permalink / raw)
To: Rashmica Gupta
Cc: linux-aspeed, Bartosz Golaszewski, Andrew Jeffery, Linus Walleij,
Linux Kernel Mailing List, open list:GPIO SUBSYSTEM, Joel Stanley,
linux-arm Mailing List
In-Reply-To: <20190904061245.30770-1-rashmica.g@gmail.com>
On Wed, Sep 4, 2019 at 9:14 AM Rashmica Gupta <rashmica.g@gmail.com> wrote:
>
> Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver')
>
> Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
> /* Allocate a cache of the output registers */
> - banks = gpio->config->nr_gpios >> 5;
> + banks = (gpio->config->nr_gpios >> 5) + 1;
Shouldn't be rather DIV_ROUND_UP(nr_gpios, sizeof(u32)) ?
> gpio->dcache = devm_kcalloc(&pdev->dev,
> banks, sizeof(u32), GFP_KERNEL);
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 3/4] gpio: Add in ast2600 details to Aspeed driver
From: Andy Shevchenko @ 2019-09-04 16:30 UTC (permalink / raw)
To: Rashmica Gupta
Cc: linux-aspeed, Bartosz Golaszewski, Andrew Jeffery, Linus Walleij,
Linux Kernel Mailing List, open list:GPIO SUBSYSTEM, Joel Stanley,
linux-arm Mailing List
In-Reply-To: <20190904061245.30770-3-rashmica.g@gmail.com>
On Wed, Sep 4, 2019 at 9:14 AM Rashmica Gupta <rashmica.g@gmail.com> wrote:
>
> The ast2600 has two gpio controllers, one for 3.6V GPIOS and one for 1.8V GPIOS.
>
> Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
> - for (i = 0; i < ARRAY_SIZE(aspeed_gpio_banks); i++) {
> + banks = (gpio->config->nr_gpios >> 5) + 1;
Same comment as per the other patch.
> + for (i = 0; i < banks; i++) {
> +static const struct aspeed_bank_props ast2600_bank_props[] = {
> + /* input output */
> + {5, 0xffffffff, 0x0000ffff}, /* U/V/W/X */
> + {6, 0xffff0000, 0x0fff0000}, /* Y/Z */
Perhaps GENMASK() for all values?
> + { },
Comma is not needed here.
> +};
> +
> +static const struct aspeed_gpio_config ast2600_config =
> + /* 208 3.6V GPIOs */
> + { .nr_gpios = 208, .props = ast2600_bank_props, };
Seems curly braces missed their places.
> +static const struct aspeed_bank_props ast2600_1_8v_bank_props[] = {
> + /* input output */
> + {1, 0x0000000f, 0x0000000f}, /* E */
GENMASK()?
> + { },
No comma.
> +};
> +static const struct aspeed_gpio_config ast2600_1_8v_config =
> + /* 36 1.8V GPIOs */
> + { .nr_gpios = 36, .props = ast2600_1_8v_bank_props, };
Location of the curly braces?
--
With Best Regards,
Andy Shevchenko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] Bitmain changes for v5.4
From: Manivannan Sadhasivam @ 2019-09-04 16:33 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Olof Johansson, arm-soc, Linux ARM
In-Reply-To: <CAK8P3a2gVsy8Do8Wrpu9wCTTBSb1qx-+mNtyCKKUA=hQVfDwSw@mail.gmail.com>
Hi Arnd,
On 4 September 2019 6:17:59 PM IST, Arnd Bergmann <arnd@arndb.de> wrote:
>On Sat, Aug 3, 2019 at 2:44 PM Manivannan Sadhasivam
><manivannan.sadhasivam@linaro.org> wrote:
>>
>> Hi Arnd, Olof,
>>
>> Please consider pulling the Bitmain SoC changes for v5.4. These
>changes
>> are supposed to be pulled in for 5.3 but I was waiting for the common
>> clock driver to be reviewed (still not), hence missing the timeline.
>> Details of the changes are in the signed tag.
>
>I just found this while going through old emails, it seems I never
>pulled it
>so far and did that now.
>
>Please note that our address has changed, and new pull requests and
>patches should go to soc@kernel.org so they end up in the patchwork
>at https://patchwork.kernel.org/project/linux-soc/list/ where you can
>see the status.
>
Okay, will use this address for future PR's.
Thanks,
Mani
>Sorry for missing this earlier.
>
> Arnd
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 1/2] ti-sysc driver changes for v5.3
From: Tony Lindgren @ 2019-09-04 16:36 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: SoC Team, arm-soc, Linux ARM, linux-omap
In-Reply-To: <CAK8P3a1Hh8nFe7h0Jr7tf_aoarvwr3utD7LrFf9rV_OePL-+Zg@mail.gmail.com>
* Arnd Bergmann <arnd@arndb.de> [190904 15:27]:
> On Sat, Aug 24, 2019 at 12:24 AM Tony Lindgren <tony@atomide.com> wrote:
> > Driver changes for ti-sysc for v5.4
> >
> > Few changes to prepare for using a reset driver for PRM rstctrl mostly
> > to deal with the clocks for reset. Then few minor clean-up patches and
> > SPDX license identifier changes, and add a MAINTAINERs file entry.
>
> Pulled this one into an arm/late branch, together with the three
> other pull requests that depend on this one.
>
> Don't worry about the arm/late name, I expect to send this off
> together with the other branches, it's just easier for me to
> describe what's in each of the top-level branches this way.
OK sure thanks.
Tony
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH ARM64] selftests, arm64: add kernel headers path for tags_test
From: Andrey Konovalov @ 2019-09-04 16:41 UTC (permalink / raw)
To: linux-arm-kernel, linux-kselftest, linux-kernel, Will Deacon
Cc: Mark Rutland, Catalin Marinas, Evgeniy Stepanov,
Kostya Serebryany, Cristian Marussi, Andrey Konovalov,
Amit Kachhap, Vincenzo Frascino, Dmitry Vyukov
tags_test.c relies on PR_SET_TAGGED_ADDR_CTRL/PR_TAGGED_ADDR_ENABLE being
present in system headers. When this is not the case the build of this
test fails with undeclared identifier errors.
Fix by providing the path to the KSFT installed kernel headers in CFLAGS.
Reported-by: Cristian Marussi <cristian.marussi@arm.com>
Suggested-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
tools/testing/selftests/arm64/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
index a61b2e743e99..f9f79fb272f0 100644
--- a/tools/testing/selftests/arm64/Makefile
+++ b/tools/testing/selftests/arm64/Makefile
@@ -4,6 +4,7 @@
ARCH ?= $(shell uname -m 2>/dev/null || echo not)
ifneq (,$(filter $(ARCH),aarch64 arm64))
+CFLAGS += -I../../../../usr/include/
TEST_GEN_PROGS := tags_test
TEST_PROGS := run_tags_test.sh
endif
--
2.23.0.187.g17f5b7556c-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v18 15/15] selftests, arm64: add a selftest for passing tagged pointers to kernel
From: Andrey Konovalov @ 2019-09-04 16:42 UTC (permalink / raw)
To: Cristian Marussi
Cc: Mark Rutland, kvm, Szabolcs Nagy, Catalin Marinas, Will Deacon,
dri-devel, Linux Memory Management List, Khalid Aziz,
open list:KERNEL SELFTEST FRAMEWORK, Felix Kuehling,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Dmitry Vyukov,
Dave Martin, Evgeniy Stepanov, linux-media, Kevin Brodsky,
Kees Cook, Ruben Ayrapetyan, Ramana Radhakrishnan,
Alex Williamson, Mauro Carvalho Chehab, Linux ARM,
Kostya Serebryany, Greg Kroah-Hartman, Yishai Hadas, LKML,
Jens Wiklander, Lee Smith, Alexander Deucher, Andrew Morton, enh,
Robin Murphy, Christian Koenig, Luc Van Oostenryck
In-Reply-To: <92ca7fd1-2aa7-3bec-384d-52033b6496c1@arm.com>
On Wed, Sep 4, 2019 at 6:22 PM Cristian Marussi
<cristian.marussi@arm.com> wrote:
>
> Hi Andrey !
>
> On 04/09/2019 15:52, Andrey Konovalov wrote:
> > On Fri, Aug 23, 2019 at 7:49 PM Cristian Marussi
> > <cristian.marussi@arm.com> wrote:
> >>
> >>
> >> Hi
> >>
> >> On 23/08/2019 18:16, Andrey Konovalov wrote:
> >>> On Fri, Aug 23, 2019 at 3:56 PM Cristian Marussi
> >>> <cristian.marussi@arm.com> wrote:
> >>>>
> >>>> Hi Andrey
> >>>>
> >>>> On 24/06/2019 15:33, Andrey Konovalov wrote:
> >>>>> This patch is a part of a series that extends kernel ABI to allow to pass
> >>>>> tagged user pointers (with the top byte set to something else other than
> >>>>> 0x00) as syscall arguments.
> >>>>>
> >>>>> This patch adds a simple test, that calls the uname syscall with a
> >>>>> tagged user pointer as an argument. Without the kernel accepting tagged
> >>>>> user pointers the test fails with EFAULT.
> >>>>>
> >>>>> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> >>>>> ---
> >>>>> tools/testing/selftests/arm64/.gitignore | 1 +
> >>>>> tools/testing/selftests/arm64/Makefile | 11 +++++++
> >>>>> .../testing/selftests/arm64/run_tags_test.sh | 12 ++++++++
> >>>>> tools/testing/selftests/arm64/tags_test.c | 29 +++++++++++++++++++
> >>>>> 4 files changed, 53 insertions(+)
> >>>>> create mode 100644 tools/testing/selftests/arm64/.gitignore
> >>>>> create mode 100644 tools/testing/selftests/arm64/Makefile
> >>>>> create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh
> >>>>> create mode 100644 tools/testing/selftests/arm64/tags_test.c
> >>>>
> >>>> After building a fresh Kernel from arm64/for-next-core from scratch at:
> >>>>
> >>>> commit 239ab658bea3b387424501e7c416640d6752dc0c
> >>>> Merge: 6bfa3134bd3a 42d038c4fb00 1243cb6a676f d55c5f28afaf d06fa5a118f1 34b5560db40d
> >>>> Author: Will Deacon <will@kernel.org>
> >>>> Date: Thu Aug 22 18:23:53 2019 +0100
> >>>>
> >>>> Merge branches 'for-next/error-injection', 'for-next/tbi', 'for-next/psci-cpuidle', 'for-next/cpu-topology' and 'for-next/52-bit-kva' into for-next/core
> >>>>
> >>>>
> >>>> KSFT arm64 tests build is broken for me, both setting or not KBUILD_OUTPUT=
> >>>>
> >>>> 13:30 $ make TARGETS=arm64 kselftest-clean
> >>>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >>>> rm -f -r /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
> >>>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >>>>
> >>>> ✔ ~/ARM/dev/src/pdsw/linux [arm64_for_next_core|…8⚑ 23]
> >>>>
> >>>> 13:30 $ make TARGETS=arm64 kselftest
> >>>> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >>>> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
> >>>> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
> >>>> ARCH=arm64 -C ../../.. headers_install
> >>>> HOSTCC scripts/basic/fixdep
> >>>> HOSTCC scripts/unifdef
> >>>> ...
> >>>> ...
> >>>> HDRINST usr/include/asm/msgbuf.h
> >>>> HDRINST usr/include/asm/shmbuf.h
> >>>> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/usr/include
> >>>> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test
> >>>> tags_test.c: In function ‘main’:
> >>>> tags_test.c:21:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
> >>>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >>>> ^~~~~~~~~~~~~~~~~~~~~~~
> >>>> PR_GET_TID_ADDRESS
> >>>> tags_test.c:21:12: note: each undeclared identifier is reported only once for each function it appears in
> >>>> tags_test.c:21:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
> >>>> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >>>> ^~~~~~~~~~~~~~~~~~~~~
> >>>> PR_GET_DUMPABLE
> >>>> ../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test' failed
> >>>> make[3]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux//kselftest/arm64/tags_test] Error 1
> >>>> Makefile:136: recipe for target 'all' failed
> >>>> make[2]: *** [all] Error 2
> >>>> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1237: recipe for target 'kselftest' failed
> >>>> make[1]: *** [kselftest] Error 2
> >>>> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >>>> Makefile:179: recipe for target 'sub-make' failed
> >>>> make: *** [sub-make] Error 2
> >>>>
> >>>> Despite seeing KSFT installing Kernel Headers, they cannot be found.
> >>>>
> >>>> Fixing this patch like this make it work for me:
> >>>>
> >>>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
> >>>> index a61b2e743e99..f9f79fb272f0 100644
> >>>> --- a/tools/testing/selftests/arm64/Makefile
> >>>> +++ b/tools/testing/selftests/arm64/Makefile
> >>>> @@ -4,6 +4,7 @@
> >>>> ARCH ?= $(shell uname -m 2>/dev/null || echo not)
> >>>>
> >>>> ifneq (,$(filter $(ARCH),aarch64 arm64))
> >>>> +CFLAGS += -I../../../../usr/include/
> >>>> TEST_GEN_PROGS := tags_test
> >>>> TEST_PROGS := run_tags_test.sh
> >>>> endif
> >>>>
> >>>> but is not really a proper fix since it does NOT account for case in which you have
> >>>> installed the Kernel Headers in a non standard location like when you use KBUILD_OUTPUT.
> >>>>
> >>>> Am I missing something ?
> >>>
> >>> Hm, PR_SET_TAGGED_ADDR_CTRL is defined in include/uapi/linux/prctl.h,
> >>> and the test has #include <sys/prctl.h> so as long as you've updated
> >>> your kernel headers this should work.
> >>>
> >>> (I'm OOO next week, I'll see if I can reproduce this once I'm back).
> >>
> >> Ok. Thanks for the reply.
> >>
> >> I think I've got it in my local tree having cloned arm64/for-next-core:
> >>
> >> 18:32 $ egrep -A 10 PR_SET_TAG ./include/uapi/linux/prctl.h
> >> #define PR_SET_TAGGED_ADDR_CTRL 55
> >> #define PR_GET_TAGGED_ADDR_CTRL 56
> >> # define PR_TAGGED_ADDR_ENABLE (1UL << 0)
> >>
> >> #endif /* _LINUX_PRCTL_H */
> >>
> >> and Kernel header are locally installed in my kernel src dir (by KSFT indeed)
> >>
> >> 18:34 $ egrep -RA 10 PR_SET_TAG usr/include/
> >> usr/include/linux/prctl.h:#define PR_SET_TAGGED_ADDR_CTRL 55
> >> usr/include/linux/prctl.h-#define PR_GET_TAGGED_ADDR_CTRL 56
> >> usr/include/linux/prctl.h-# define PR_TAGGED_ADDR_ENABLE (1UL << 0)
> >> usr/include/linux/prctl.h-
> >> usr/include/linux/prctl.h-#endif /* _LINUX_PRCTL_H */
> >>
> >> but how are they supposed to be found if nor the test Makefile
> >> neither the KSFT Makefile who installs them pass any -I options to the
> >> compiler ?
> >> I suppose <sys/prctl.h> tries to include arch specific headers from the regular system path,
> >> but when you are cross-compiling ?
> >>
> >> 18:34 $ make TARGETS=arm64 kselftest
> >> make[1]: Entering directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >> arch/arm64/Makefile:56: CROSS_COMPILE_COMPAT not defined or empty, the compat vDSO will not be built
> >> make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
> >> ARCH=arm64 -C ../../.. headers_install
> >> INSTALL /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/usr/include
> >> /opt/toolchains/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc -Wall -O2 -g tags_test.c -o /home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test
> >> tags_test.c: In function ‘main’:
> >> tags_test.c:20:12: error: ‘PR_SET_TAGGED_ADDR_CTRL’ undeclared (first use in this function); did you mean ‘PR_GET_TID_ADDRESS’?
> >> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >> ^~~~~~~~~~~~~~~~~~~~~~~
> >> PR_GET_TID_ADDRESS
> >> tags_test.c:20:12: note: each undeclared identifier is reported only once for each function it appears in
> >> tags_test.c:20:37: error: ‘PR_TAGGED_ADDR_ENABLE’ undeclared (first use in this function); did you mean ‘PR_GET_DUMPABLE’?
> >> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >> ^~~~~~~~~~~~~~~~~~~~~
> >> PR_GET_DUMPABLE
> >> ../../lib.mk:138: recipe for target '/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test' failed
> >> make[4]: *** [/home/crimar01/ARM/dev/src/pdsw/out_linux/kselftest/arm64/tags/tags_test] Error 1
> >> Makefile:19: recipe for target 'all' failed
> >> make[3]: *** [all] Error 2
> >> Makefile:137: recipe for target 'all' failed
> >> make[2]: *** [all] Error 2
> >> /home/crimar01/ARM/dev/src/pdsw/linux/Makefile:1236: recipe for target 'kselftest' failed
> >> make[1]: *** [kselftest] Error 2
> >> make[1]: Leaving directory '/home/crimar01/ARM/dev/src/pdsw/out_linux'
> >> Makefile:179: recipe for target 'sub-make' failed
> >> make: *** [sub-make] Error 2
> >>
> >>
> >> In fact many KSFT testcases seems to brutally add default headers path:
> >>
> >> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/uapi/
> >> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../include/
> >> tools/testing/selftests/memfd/Makefile:CFLAGS += -I../../../../usr/include/
> >> tools/testing/selftests/net/Makefile:CFLAGS += -I../../../../usr/include/
> >> tools/testing/selftests/membarrier/Makefile:CFLAGS += -g -I../../../../usr/include/
> >> ...
> >
> > Hi Cristian!
> >
> > Indeed, I can reproduce the issue. I don't know what's the proper way
> > to resolve this. Adding "CFLAGS += -I../../../../usr/include/" looks
> > good to me. AFAICS your series resolves this issue in a similar way,
> > but I think we should fix this before the current rc is released. Do
> > you want to submit a patch that adds this simple fix or should I do
> > that?
> >
>
> Please feel free to post the single line patch above to quickly fix this before
> release, so we don't have a broken build straight away. (our CI is already beating me...:D)
Done.
>
> On my side (01/11) in the meantime I'll fix the top level KSFT arm64 makefile so as to calculate
> and propagate once for all the headers search path down to all KSFT arm64/ in one go,
> trying to guess where they are; this is needed because the above fix works fine as long
> as you don't have KBUILD_OUTPUT set, once you set it, KSFT installs kheaders in a different
> place and the above -I fix is fooled again....but this is a general problem also in other
> KSFT tests as I can see now so I think this fix is good enough for now
> (and the fix on my side, even if trivial, is not going to go into this release for sure)
Ah, I see.
Thanks for the report!
>
> Thanks !
>
> Cheers
>
> Cristian
>
> > Thanks!
> >
> >>
> >> Cheers
> >>
> >> Cristian
> >>>
> >>>
> >>>
> >>>>
> >>>> Thanks
> >>>>
> >>>> Cristian
> >>>>
> >>>>>
> >>>>> diff --git a/tools/testing/selftests/arm64/.gitignore b/tools/testing/selftests/arm64/.gitignore
> >>>>> new file mode 100644
> >>>>> index 000000000000..e8fae8d61ed6
> >>>>> --- /dev/null
> >>>>> +++ b/tools/testing/selftests/arm64/.gitignore
> >>>>> @@ -0,0 +1 @@
> >>>>> +tags_test
> >>>>> diff --git a/tools/testing/selftests/arm64/Makefile b/tools/testing/selftests/arm64/Makefile
> >>>>> new file mode 100644
> >>>>> index 000000000000..a61b2e743e99
> >>>>> --- /dev/null
> >>>>> +++ b/tools/testing/selftests/arm64/Makefile
> >>>>> @@ -0,0 +1,11 @@
> >>>>> +# SPDX-License-Identifier: GPL-2.0
> >>>>> +
> >>>>> +# ARCH can be overridden by the user for cross compiling
> >>>>> +ARCH ?= $(shell uname -m 2>/dev/null || echo not)
> >>>>> +
> >>>>> +ifneq (,$(filter $(ARCH),aarch64 arm64))
> >>>>> +TEST_GEN_PROGS := tags_test
> >>>>> +TEST_PROGS := run_tags_test.sh
> >>>>> +endif
> >>>>> +
> >>>>> +include ../lib.mk
> >>>>> diff --git a/tools/testing/selftests/arm64/run_tags_test.sh b/tools/testing/selftests/arm64/run_tags_test.sh
> >>>>> new file mode 100755
> >>>>> index 000000000000..745f11379930
> >>>>> --- /dev/null
> >>>>> +++ b/tools/testing/selftests/arm64/run_tags_test.sh
> >>>>> @@ -0,0 +1,12 @@
> >>>>> +#!/bin/sh
> >>>>> +# SPDX-License-Identifier: GPL-2.0
> >>>>> +
> >>>>> +echo "--------------------"
> >>>>> +echo "running tags test"
> >>>>> +echo "--------------------"
> >>>>> +./tags_test
> >>>>> +if [ $? -ne 0 ]; then
> >>>>> + echo "[FAIL]"
> >>>>> +else
> >>>>> + echo "[PASS]"
> >>>>> +fi
> >>>>> diff --git a/tools/testing/selftests/arm64/tags_test.c b/tools/testing/selftests/arm64/tags_test.c
> >>>>> new file mode 100644
> >>>>> index 000000000000..22a1b266e373
> >>>>> --- /dev/null
> >>>>> +++ b/tools/testing/selftests/arm64/tags_test.c
> >>>>> @@ -0,0 +1,29 @@
> >>>>> +// SPDX-License-Identifier: GPL-2.0
> >>>>> +
> >>>>> +#include <stdio.h>
> >>>>> +#include <stdlib.h>
> >>>>> +#include <unistd.h>
> >>>>> +#include <stdint.h>
> >>>>> +#include <sys/prctl.h>
> >>>>> +#include <sys/utsname.h>
> >>>>> +
> >>>>> +#define SHIFT_TAG(tag) ((uint64_t)(tag) << 56)
> >>>>> +#define SET_TAG(ptr, tag) (((uint64_t)(ptr) & ~SHIFT_TAG(0xff)) | \
> >>>>> + SHIFT_TAG(tag))
> >>>>> +
> >>>>> +int main(void)
> >>>>> +{
> >>>>> + static int tbi_enabled = 0;
> >>>>> + struct utsname *ptr, *tagged_ptr;
> >>>>> + int err;
> >>>>> +
> >>>>> + if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> >>>>> + tbi_enabled = 1;
> >>>>> + ptr = (struct utsname *)malloc(sizeof(*ptr));
> >>>>> + if (tbi_enabled)
> >>>>> + tagged_ptr = (struct utsname *)SET_TAG(ptr, 0x42);
> >>>>> + err = uname(tagged_ptr);
> >>>>> + free(ptr);
> >>>>> +
> >>>>> + return err;
> >>>>> +}
> >>>>>
> >>>>
> >>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] include: mdio: Add driver data helpers
From: Andrew Lunn @ 2019-09-04 16:46 UTC (permalink / raw)
To: Harini Katakam
Cc: f.fainelli, netdev, radhey.shyam.pandey, michal.simek,
harinikatakamlinux, linux-kernel, davem, linux-arm-kernel,
hkallweit1
In-Reply-To: <1567605621-6818-2-git-send-email-harini.katakam@xilinx.com>
On Wed, Sep 04, 2019 at 07:30:20PM +0530, Harini Katakam wrote:
> Add set/get drv_data helpers for mdio device.
>
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] net: phy: gmii2rgmii: Dont use priv field in phy device
From: Andrew Lunn @ 2019-09-04 16:47 UTC (permalink / raw)
To: Harini Katakam
Cc: f.fainelli, netdev, radhey.shyam.pandey, michal.simek,
harinikatakamlinux, linux-kernel, davem, linux-arm-kernel,
hkallweit1
In-Reply-To: <1567605621-6818-3-git-send-email-harini.katakam@xilinx.com>
On Wed, Sep 04, 2019 at 07:30:21PM +0530, Harini Katakam wrote:
> Use set/get drv data in phydev's mdio device instead. Phy device priv
> field maybe used by the external phy driver and should not be
> overwritten.
>
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/1] arm64: dts: qcom: Add Lenovo Yoga C630
From: Sudeep Holla @ 2019-09-04 16:52 UTC (permalink / raw)
To: Lee Jones
Cc: mark.rutland, devicetree, linux-arm-msm, linux-kernel, robh+dt,
bjorn.andersson, agross, Sudeep Holla, linux-arm-kernel
In-Reply-To: <20190904161247.GP26880@dell>
On Wed, Sep 04, 2019 at 05:12:47PM +0100, Lee Jones wrote:
> On Wed, 04 Sep 2019, Sudeep Holla wrote:
>
> > On Wed, Sep 04, 2019 at 01:16:06PM +0100, Lee Jones wrote:
> > > From: Bjorn Andersson <bjorn.andersson@linaro.org>
> > >
> > > The Lenovo Yoga C630 is built on the SDM850 from Qualcomm, but this seem
> > > to be similar enough to the SDM845 that we can reuse the sdm845.dtsi.
> > >
> > > Supported by this patch is: keyboard, battery monitoring, UFS storage,
> > > USB host and Bluetooth.
> > >
> >
> > Just curious to know if the idea of booting using ACPI is completely
> > dropped as it's extremely difficult(because the firmware is so hacked
> > up and may violate spec, just my opinion) for whatever reasons.
>
> Once [0] is applied, we can boot Mainline using ACPI.
>
Good to know.
> > We just made ACPI table version checking more lenient for this platform
> > and would be good to know if we continue to run ACPI on that or will
> > abandon and just use DT.
>
> Which patch are you referring to? If you mean the ACPI v5.0 vs v5.1
> patch authored by Ard, then yes I know, I instigated it's existence
> due to these devices.
>
Yes exactly that one.
> DT will *always* be more enabled than ACPI, so it's advised that you
> use DT for anything useful. ACPI booting is ideal for things like
> installing distros however, since they do not tend to provide DTBs in
> their installers.
>
OK, as along as it gets tested/used in some form, that's fine. I do agree
that DT will be more useful on that platform as it was derived from mobile
based SoC SDM845 rather than solely designed for Laptops and with more
alignment with ACPI spec. The way whole power/clock management is done
with ACPI on this pulls me towards DT ;)
--
Regards,
Sudeep
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 03/15] thermal: brcmstb: use devm_platform_ioremap_resource() to simplify code
From: Florian Fainelli @ 2019-09-04 17:00 UTC (permalink / raw)
To: YueHaibing, miquel.raynal, rui.zhang, edubezval, daniel.lezcano,
amit.kucheria, eric, wahrenst, f.fainelli, rjui, sbranden, mmayer,
computersforpeace, gregory.0xf0, matthias.bgg, agross, heiko,
mcoquelin.stm32, alexandre.torgue, marc.w.gonzalez, mans, talel,
jun.nie, shawnguo, phil, gregkh, david.hernandezsanchez,
horms+renesas, wsa+renesas
Cc: linux-pm, linux-arm-msm, linux-kernel, linux-rockchip,
linux-mediatek, linux-rpi-kernel, bcm-kernel-feedback-list,
linux-stm32, linux-arm-kernel
In-Reply-To: <20190904122939.23780-4-yuehaibing@huawei.com>
On 9/4/19 5:29 AM, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/3] perf cs-etm: Refactor instruction size handling
From: Mathieu Poirier @ 2019-09-04 17:06 UTC (permalink / raw)
To: Leo Yan
Cc: Suzuki K Poulose, Alexander Shishkin, Linux Kernel Mailing List,
Arnaldo Carvalho de Melo, Adrian Hunter, Namhyung Kim,
Robert Walker, Jiri Olsa, linux-arm-kernel, Mike Leach
In-Reply-To: <20190904091916.GB27922@leoy-ThinkPad-X240s>
On Wed, 4 Sep 2019 at 03:19, Leo Yan <leo.yan@linaro.org> wrote:
>
> Hi Mathieu,
>
> On Tue, Sep 03, 2019 at 04:22:15PM -0600, Mathieu Poirier wrote:
> > On Fri, Aug 30, 2019 at 02:24:19PM +0800, Leo Yan wrote:
> > > There has several code pieces need to know the instruction size, but
> > > now every place calculates the instruction size separately.
> > >
> > > This patch refactors to create a new function cs_etm__instr_size() as
> > > a central place to analyze the instruction length based on ISA type
> > > and instruction value.
> > >
> > > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > > ---
> > > tools/perf/util/cs-etm.c | 44 +++++++++++++++++++++++++++-------------
> > > 1 file changed, 30 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > > index b3a5daaf1a8f..882a0718033d 100644
> > > --- a/tools/perf/util/cs-etm.c
> > > +++ b/tools/perf/util/cs-etm.c
> > > @@ -914,6 +914,26 @@ static inline int cs_etm__t32_instr_size(struct cs_etm_queue *etmq,
> > > return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2;
> > > }
> > >
> > > +static inline int cs_etm__instr_size(struct cs_etm_queue *etmq,
> > > + u8 trace_chan_id,
> > > + enum cs_etm_isa isa,
> > > + u64 addr)
> > > +{
> > > + int insn_len;
> > > +
> > > + /*
> > > + * T32 instruction size might be 32-bit or 16-bit, decide by calling
> > > + * cs_etm__t32_instr_size().
> > > + */
> > > + if (isa == CS_ETM_ISA_T32)
> > > + insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id, addr);
> > > + /* Otherwise, A64 and A32 instruction size are always 32-bit. */
> > > + else
> > > + insn_len = 4;
> > > +
> > > + return insn_len;
> > > +}
> > > +
> > > static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
> > > {
> > > /* Returns 0 for the CS_ETM_DISCONTINUITY packet */
> > > @@ -938,19 +958,23 @@ static inline u64 cs_etm__instr_addr(struct cs_etm_queue *etmq,
> > > const struct cs_etm_packet *packet,
> > > u64 offset)
> > > {
> > > + int insn_len;
> > > +
> > > if (packet->isa == CS_ETM_ISA_T32) {
> > > u64 addr = packet->start_addr;
> > >
> > > while (offset > 0) {
> > > - addr += cs_etm__t32_instr_size(etmq,
> > > - trace_chan_id, addr);
> > > + addr += cs_etm__instr_size(etmq, trace_chan_id,
> > > + packet->isa, addr);
> > > offset--;
> > > }
> > > return addr;
> > > }
> > >
> > > - /* Assume a 4 byte instruction size (A32/A64) */
> > > - return packet->start_addr + offset * 4;
> > > + /* Return instruction size for A32/A64 */
> > > + insn_len = cs_etm__instr_size(etmq, trace_chan_id,
> > > + packet->isa, packet->start_addr);
> > > + return packet->start_addr + offset * insn_len;
> >
> > This patch will work but from where I stand it makes things difficult to
> > understand more than anything else. It is also adding coupling between function
> > cs_etm__instr_addr() and cs_etm__instr_size(), meaning the code needs to be
> > carefully inspected in order to make changes to either one.
>
> My purpose is to use a same place to calculate the instruction
> size, rather than to spread the duplicate codes in several different
> functions.
>
> > Last but not least function cs_etm__instr_size() isn't used in the upcoming
> > patches. I really don't see what is gained here.
>
> Sorry that I forgot to commit my final change into patch 02.
>
> I planed to use cs_etm__instr_size() in patch 02; patch 02 has
> function cs_etm__add_stack_event(), which also needs to get the
> instruction size when it sends stack event.
>
> After apply patch 02, tools/perf/util/cs-etm.c will have below three
> functions to caculate instruction size; this is the main reason I want
> to refactor the code for instruction size.
>
> cs_etm__instr_addr()
> cs_etm__copy_insn()
> cs_etm__add_stack_event()
>
> If this lets code more difficult to understand, will drop it.
>
I agree with the consolidation but for that to work function
cs_etm__instr_addr() needs to be refactored. Since
cs_etm__instr_size() is already taking care of checking the ISA type
the while() loop in cs_etm__instr_addr() can be done regardless of the
operation mode. That way cs_etm__instr_size() can be changed at will
without breaking anything.
The downside is that we are doing a few more iterations... Which isn't
that big a deal considering we are in user space. We can think about
some optimisation if it is ever proven to be a bottleneck.
Let me know if you see a problem with that approach.
Regards,
Mathieu
> Thanks,
> Leo Yan
>
> > > }
> > >
> > > static void cs_etm__update_last_branch_rb(struct cs_etm_queue *etmq,
> > > @@ -1090,16 +1114,8 @@ static void cs_etm__copy_insn(struct cs_etm_queue *etmq,
> > > return;
> > > }
> > >
> > > - /*
> > > - * T32 instruction size might be 32-bit or 16-bit, decide by calling
> > > - * cs_etm__t32_instr_size().
> > > - */
> > > - if (packet->isa == CS_ETM_ISA_T32)
> > > - sample->insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id,
> > > - sample->ip);
> > > - /* Otherwise, A64 and A32 instruction size are always 32-bit. */
> > > - else
> > > - sample->insn_len = 4;
> > > + sample->insn_len = cs_etm__instr_size(etmq, trace_chan_id,
> > > + packet->isa, sample->ip);
> > >
> > > cs_etm__mem_access(etmq, trace_chan_id, sample->ip,
> > > sample->insn_len, (void *)sample->insn);
> > > --
> > > 2.17.1
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/2] include: mdio: Add driver data helpers
From: Florian Fainelli @ 2019-09-04 17:07 UTC (permalink / raw)
To: Harini Katakam, andrew, hkallweit1, davem
Cc: netdev, radhey.shyam.pandey, michal.simek, harinikatakamlinux,
linux-kernel, linux-arm-kernel
In-Reply-To: <1567605621-6818-2-git-send-email-harini.katakam@xilinx.com>
On 9/4/19 7:00 AM, Harini Katakam wrote:
> Add set/get drv_data helpers for mdio device.
>
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/1] arm64: dts: qcom: Add Lenovo Yoga C630
From: Lee Jones @ 2019-09-04 17:07 UTC (permalink / raw)
To: Sudeep Holla
Cc: mark.rutland, devicetree, linux-arm-msm, linux-kernel, robh+dt,
bjorn.andersson, agross, linux-arm-kernel
In-Reply-To: <20190904165246.GA25356@bogus>
On Wed, 04 Sep 2019, Sudeep Holla wrote:
> On Wed, Sep 04, 2019 at 05:12:47PM +0100, Lee Jones wrote:
> > On Wed, 04 Sep 2019, Sudeep Holla wrote:
> >
> > > On Wed, Sep 04, 2019 at 01:16:06PM +0100, Lee Jones wrote:
> > > > From: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > >
> > > > The Lenovo Yoga C630 is built on the SDM850 from Qualcomm, but this seem
> > > > to be similar enough to the SDM845 that we can reuse the sdm845.dtsi.
> > > >
> > > > Supported by this patch is: keyboard, battery monitoring, UFS storage,
> > > > USB host and Bluetooth.
> > > >
> > >
> > > Just curious to know if the idea of booting using ACPI is completely
> > > dropped as it's extremely difficult(because the firmware is so hacked
> > > up and may violate spec, just my opinion) for whatever reasons.
> >
> > Once [0] is applied, we can boot Mainline using ACPI.
> >
>
> Good to know.
>
> > > We just made ACPI table version checking more lenient for this platform
> > > and would be good to know if we continue to run ACPI on that or will
> > > abandon and just use DT.
> >
> > Which patch are you referring to? If you mean the ACPI v5.0 vs v5.1
> > patch authored by Ard, then yes I know, I instigated it's existence
> > due to these devices.
> >
>
> Yes exactly that one.
>
> > DT will *always* be more enabled than ACPI, so it's advised that you
> > use DT for anything useful. ACPI booting is ideal for things like
> > installing distros however, since they do not tend to provide DTBs in
> > their installers.
>
> OK, as along as it gets tested/used in some form, that's fine. I do agree
> that DT will be more useful on that platform as it was derived from mobile
> based SoC SDM845 rather than solely designed for Laptops and with more
> alignment with ACPI spec. The way whole power/clock management is done
> with ACPI on this pulls me towards DT ;)
Exactly. For Power Management on ACPI, we need to re-implement the
"Windows-compatible System Power Management Controller" (PEP), which
considering there isn't any documentation and/or source, would be a
mammoth challenge, if at all possible.
Feel free to provide your {Ack,Review)ed-by for this patch. :)
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 1/3] Broadcom defconfig changes for 5.4
From: Florian Fainelli @ 2019-09-04 17:07 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Stefan Wahren, Kevin Hilman, arm-soc, bcm-kernel-feedback-list,
Stefan Wahren, Olof Johansson, Nicolas Saenz Julienne, Linux ARM
In-Reply-To: <CAK8P3a2mWkW_R7Dqd5nJgd=phEF2YLzkTO7JsD9dLYcF9zF6iQ@mail.gmail.com>
On 9/4/19 5:59 AM, Arnd Bergmann wrote:
> On Mon, Aug 19, 2019 at 9:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>>
>> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>>
>> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>>
>> are available in the Git repository at:
>>
>> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.4/defconfig
>>
>> for you to fetch changes up to c474106e1e8a8f335b1bd3e79e868943689ae74d:
>>
>> Merge tag 'tags/bcm2835-defconfig-next-2019-08-15' into defconfig/next (2019-08-15 11:37:54 -0700)
>>
>> ----------------------------------------------------------------
>> This pull request contains Broadcom ARM-based SoCs defconfig updates for
>> 5.4, please pull the following:
>>
>> - Nicolas enables the Raspberry Pi CPUFREQ driver in both
>> bcm2835_defconfig and multi_v7_defconfig
>
> Pulled into arm/defconfig now.
>
> Please remember to use the new soc@kernel.org address as recipient for
> pull requests in the future to make it work with the patchwork at
> https://patchwork.kernel.org/project/linux-soc/list/
Oh yes, thanks, I updated my script to included that address now.
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] net: phy: gmii2rgmii: Dont use priv field in phy device
From: Florian Fainelli @ 2019-09-04 17:11 UTC (permalink / raw)
To: Harini Katakam, andrew, hkallweit1, davem
Cc: netdev, radhey.shyam.pandey, michal.simek, harinikatakamlinux,
linux-kernel, linux-arm-kernel
In-Reply-To: <1567605621-6818-3-git-send-email-harini.katakam@xilinx.com>
On 9/4/19 7:00 AM, Harini Katakam wrote:
> Use set/get drv data in phydev's mdio device instead. Phy device priv
> field maybe used by the external phy driver and should not be
> overwritten.
>
> Signed-off-by: Harini Katakam <harini.katakam@xilinx.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 2/3] Broadcom defconfig-arm64 changes for 5.4
From: Stefan Wahren @ 2019-09-04 17:06 UTC (permalink / raw)
To: Arnd Bergmann, Florian Fainelli
Cc: Stefan Wahren, Kevin Hilman, arm-soc, bcm-kernel-feedback-list,
Nicolas Saenz Julienne, Olof Johansson, Linux ARM
In-Reply-To: <CAK8P3a2XbU0s0S7wsX5s+UDNc5tfDkqs2KZw+7qXNZ5RuYW8MA@mail.gmail.com>
Hi Arnd,
Am 04.09.19 um 15:02 schrieb Arnd Bergmann:
> On Mon, Aug 19, 2019 at 9:06 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>> The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
>>
>> Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
>>
>> are available in the Git repository at:
>>
>> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-5.4/defconfig-arm64
>>
>> for you to fetch changes up to d6cc9ddd23f8b113797152896462b27e2b213ece:
>>
>> Merge tag 'tags/bcm2835-defconfig-64-next-2019-08-15' into defconfig-arm64/next (2019-08-15 11:38:29 -0700)
>>
>> ----------------------------------------------------------------
>> This pull request contains Broadcom ARM64-based SoCs defconfig updates
>> for 5.4, please pull the following:
>>
>> - Nicolas enables the Raspberry Pi CPUFREQ driver in the ARM64 defconfig file
> Pulled into arm/defconfig.
>
> The way we work at the moment, there is no real need to split changes
> to the arm32 and arm64 defconfig files into separate pull requests or even
> separate patches.
this is new to me. My understanding was to separate all changes between
arm32 and arm64 changes.
So this isn't necessary for the DT arm/arm64 changes, too?
> Since this is the same change as the previous pull
> request, having a single patch to enable cpufreq everywhere would have
> been easier.
>
> Arnd
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 0/6] PAXB INTx support with proper model
From: Florian Fainelli @ 2019-09-04 17:16 UTC (permalink / raw)
To: Srinath Mannam, Lorenzo Pieralisi, Bjorn Helgaas, Rob Herring,
Mark Rutland, Andy Shevchenko, Arnd Bergmann
Cc: linux-pci, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel, devicetree
In-Reply-To: <1566982488-9673-1-git-send-email-srinath.mannam@broadcom.com>
On 8/28/19 1:54 AM, Srinath Mannam wrote:
> This patch series adds PCIe legacy interrupt (INTx) support to the iProc
> PCIe driver by modeling it with its own IRQ domain. All 4 interrupts INTA,
> INTB, INTC, INTD share the same interrupt line connected to the GIC
> in the system. This is now modeled by using its own IRQ domain.
>
> Also update all relevant devicetree files to adapt to the new model.
>
> This patch set is based on Linux-5.2-rc4.
>
> Changes from v1:
> - Addressed Rob, Lorenzo, Arnd's comments
> - Used child node for interrupt controller.
> - Addressed Andy Shevchenko's comments
> - Replaced while loop with do-while.
Lorenzo, Bjorn, if you are good with the binding and PCI host driver
changes, you can take patches 1-2 through your tree, and I will queue up
the others through the Broadcom ARM SoC pull requests. If not, please
feel free to add a:
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
>
> Ray Jui (6):
> dt-bindings: pci: Update iProc PCI binding for INTx support
> PCI: iproc: Add INTx support with better modeling
> arm: dts: Change PCIe INTx mapping for Cygnus
> arm: dts: Change PCIe INTx mapping for NSP
> arm: dts: Change PCIe INTx mapping for HR2
> arm64: dts: Change PCIe INTx mapping for NS2
>
> .../devicetree/bindings/pci/brcm,iproc-pcie.txt | 48 ++++++++--
> arch/arm/boot/dts/bcm-cygnus.dtsi | 30 ++++++-
> arch/arm/boot/dts/bcm-hr2.dtsi | 30 ++++++-
> arch/arm/boot/dts/bcm-nsp.dtsi | 45 ++++++++--
> arch/arm64/boot/dts/broadcom/northstar2/ns2.dtsi | 28 +++++-
> drivers/pci/controller/pcie-iproc.c | 100 ++++++++++++++++++++-
> drivers/pci/controller/pcie-iproc.h | 6 ++
> 7 files changed, 260 insertions(+), 27 deletions(-)
>
--
Florian
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH -next 15/15] thermal: rcar: use devm_platform_ioremap_resource() to simplify code
From: Wolfram Sang @ 2019-09-04 17:25 UTC (permalink / raw)
To: YueHaibing
Cc: mans, mmayer, eric, miquel.raynal, linux-stm32, heiko,
amit.kucheria, f.fainelli, daniel.lezcano, phil, linux-rockchip,
agross, bcm-kernel-feedback-list, linux-arm-msm, rui.zhang,
david.hernandezsanchez, alexandre.torgue, marc.w.gonzalez, rjui,
edubezval, linux-mediatek, linux-rpi-kernel, gregory.0xf0,
matthias.bgg, horms+renesas, talel, linux-arm-kernel, sbranden,
wsa+renesas, gregkh, linux-pm, linux-kernel, wahrenst,
mcoquelin.stm32, jun.nie, computersforpeace, shawnguo
In-Reply-To: <20190904122939.23780-16-yuehaibing@huawei.com>
[-- Attachment #1.1: Type: text/plain, Size: 472 bytes --]
On Wed, Sep 04, 2019 at 08:29:39PM +0800, YueHaibing wrote:
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
I think for such straightforward (and manifold) conversions, one patch
per subsystem is better than one patch per driver. But this is not my
subsystem, so I'll leave it to the thermal maintainers.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 03/10] arm64: atomics: avoid out-of-line ll/sc atomics
From: Nick Desaulniers @ 2019-09-04 17:28 UTC (permalink / raw)
To: Andrew Murray
Cc: Mark Rutland, Peter Zijlstra, Catalin Marinas, Robin Murphy,
Ard.Biesheuvel, Nathan Chancellor, Will Deacon, Linux ARM
In-Reply-To: <20190903220412.GU9720@e119886-lin.cambridge.arm.com>
On Tue, Sep 3, 2019 at 3:04 PM Andrew Murray <andrew.murray@arm.com> wrote:
>
> On Tue, Sep 03, 2019 at 05:37:55PM +0100, Will Deacon wrote:
> > On Tue, Sep 03, 2019 at 04:31:20PM +0100, Andrew Murray wrote:
> > > On Tue, Sep 03, 2019 at 04:15:44PM +0100, Andrew Murray wrote:
> > > > On Tue, Sep 03, 2019 at 03:45:34PM +0100, Will Deacon wrote:
> > > > > Does it work if the only thing you change is the toolchain, and use GCC
> > > > > instead?
> > > >
> > > > Yup.
> > >
> > > Also this is Clang generation:
> > >
> > > ffff8000100f2700 <__ptrace_link>:
> > > ffff8000100f2700: f9426009 ldr x9, [x0, #1216]
> > > ffff8000100f2704: 91130008 add x8, x0, #0x4c0
> > > ffff8000100f2708: eb09011f cmp x8, x9
> > > ffff8000100f270c: 540002a1 b.ne ffff8000100f2760 <__ptrace_link+0x60> // b.any
> > > ffff8000100f2710: f9425829 ldr x9, [x1, #1200]
> > > ffff8000100f2714: 9112c02a add x10, x1, #0x4b0
> > > ffff8000100f2718: f9000528 str x8, [x9, #8]
> > > ffff8000100f271c: f9026009 str x9, [x0, #1216]
> > > ffff8000100f2720: f902640a str x10, [x0, #1224]
> > > ffff8000100f2724: f9025828 str x8, [x1, #1200]
> > > ffff8000100f2728: f9024001 str x1, [x0, #1152]
> > > ffff8000100f272c: b4000162 cbz x2, ffff8000100f2758 <__ptrace_link+0x58>
> > > ffff8000100f2730: b900985f str wzr, [x2, #152]
> > > ffff8000100f2734: 14000004 b ffff8000100f2744 <__ptrace_link+0x44>
> > > ffff8000100f2738: 14000001 b ffff8000100f273c <__ptrace_link+0x3c>
> > > ffff8000100f273c: 14000006 b ffff8000100f2754 <__ptrace_link+0x54>
> > > ffff8000100f2740: 14000001 b ffff8000100f2744 <__ptrace_link+0x44>
> > > ffff8000100f2744: 52800028 mov w8, #0x1 // #1
> > > ffff8000100f2748: b828005f stadd w8, [x2]
> > > ffff8000100f274c: f9030002 str x2, [x0, #1536]
> > > ffff8000100f2750: d65f03c0 ret
> > > ffff8000100f2754: 140007fd b ffff8000100f4748 <ptrace_check_attach+0xf8>
> > > ...
> > >
> > > This looks like the default path (before we write over it) will take you to
> > > the LSE code (e.g. ffff8000100f2734). I'm pretty sure this is wrong, or at
> > > least not what we expected to see. Also why 4 branches?
> >
> > So I reproduced this with a silly atomic_inc wrapper:
> >
> > void will_atomic_inc(atomic_t *v)
> > {
> > atomic_inc(v);
> > }
> >
> > Compiles to:
> >
> > 0000000000000018 <will_atomic_inc>:
> > 18: 14000004 b 28 <will_atomic_inc+0x10>
> > 1c: 14000001 b 20 <will_atomic_inc+0x8>
> > 20: 14000005 b 34 <will_atomic_inc+0x1c>
> > 24: 14000001 b 28 <will_atomic_inc+0x10>
> > 28: 52800028 mov w8, #0x1 // #1
> > 2c: b828001f stadd w8, [x0]
> > 30: d65f03c0 ret
> > 34: 14000027 b d0 <dump_kernel_offset+0x60>
> > 38: d65f03c0 ret
> >
> > which is going to explode.
>
> I've come up with a simple reproducer for this issue:
>
> static bool branch_jump()
> {
> asm_volatile_goto(
> "1: b %l[l_yes2]"
> : : : : l_yes2);
>
> return false;
> l_yes2:
> return true;
> }
>
> static bool branch_test()
> {
> return (!branch_jump() && !branch_jump());
> }
>
> void andy_test(int *v)
> {
> if (branch_test())
> *v = 0xff;
> }
>
> This leads to the following (it shouldn't do anything):
>
> 0000000000000000 <andy_test>:
> 0: 14000004 b 10 <andy_test+0x10>
> 4: 14000001 b 8 <andy_test+0x8>
> 8: 14000004 b 18 <andy_test+0x18>
> c: 14000001 b 10 <andy_test+0x10>
> 10: 52801fe8 mov w8, #0xff // #255
> 14: b9000008 str w8, [x0]
> 18: d65f03c0 ret
>
> The issue goes away with any of the following hunks:
>
>
> @@ -55,7 +55,7 @@ static bool branch_jump()
>
> static bool branch_test()
> {
> - return (!branch_jump() && !branch_jump());
> + return (!branch_jump());
> }
>
> void andy_test(int *v)
>
>
> or:
>
>
> @@ -53,14 +53,10 @@ static bool branch_jump()
> return true;
> }
>
> -static bool branch_test()
> -{
> - return (!branch_jump() && !branch_jump());
> -}
>
> void andy_test(int *v)
> {
> - if (branch_test())
> + if (!branch_jump() && !branch_jump())
> *v = 0xff;
> }
Indeed, playing with the definition of `__lse_ll_sc_body`, I can get
the kernel to boot again.
So I think your very helpful test cases are illustrating two different problems:
https://godbolt.org/z/dMf7x-
See the disassembly of `andy_test2`. Reference to the correct label
is emitted in the inline asm, but there's some silly unconditional
branches to the next instruction. That's issue #1 and part of the
reason you see superfluous branches. With that fixed, `andy_test2`
would match between GCC and Clang. I think that can be a very late
peephole optimization (and further, we could probably combine labels
that refer to the same location, oh and .Lfunc_endX could just use
`.`, too!). LLVM devs noted that the x86 backend doesn't have this
issue, but this is a curiously recurring pattern I'm noticing in LLVM
where some arch agnostic optimization is only implemented for x86...
I'm reading through our Branch Folding pass which I think should
handle this, but I'll need to fire up a debugger.
Issue #2 is the more critical issue, but may be conflated with issue
#1. Issue #2 is the nonsensical control flow with one level of
inlining. See how in the disassembly of `andy_test`, the first label
referenced from inline assembly is *before* the mov/str when it should
have been *after*. Not sure where we could be going wrong, but it's
straightforward for me to observe the code change as its transformed
through LLVM, and I've debugged and fixed issues related to inlining
asm goto before.
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] SOC: TI soc updates for 5.4
From: santosh.shilimkar @ 2019-09-04 17:35 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Olof Johansson, arm-soc, linux-kernel@vger.kernel.org, Linux ARM,
Kevin Hilman
In-Reply-To: <CAK8P3a3_NWWBFrpNpbPH9+47Segi_EaYx2jx5jvPhYJJqR+a7A@mail.gmail.com>
On 9/4/19 6:13 AM, Arnd Bergmann wrote:
> On Tue, Aug 27, 2019 at 5:12 AM Santosh Shilimkar
> <santosh.shilimkar@oracle.com> wrote:
>
>> ----------------------------------------------------------------
>> soc: TI soc updates for 5.4
>>
>> - Update firmware to support PM domain shared and exclusive support
>> - Update driver and dt binding docs for the same.
>>
>> ----------------------------------------------------------------
>>
>> Lokesh Vutla (3):
>> firmware: ti_sci: Allow for device shared and exclusive requests
>> dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared
>> access
>> soc: ti: ti_sci_pm_domains: Add support for exclusive and shared
>> access
>
> Hi Santosh,
>
> I noticed that your branch is based on top of v5.3-rc2, while my
> arm/drivers branch started out from -rc1.
>
> Do you have any dependencies on -rc2 in your changes? If not,
> could you please resubmit after rebasing? I can also just
> cherry-pick those three commits if that's easier.
>
No dependencies. Can you please cherry pick them this time ?
Will use rc1 for future pull request(s). Thanks !!
Regards,
Santosh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 0/5] arm: exynos: Second round of pulls for v5.4
From: Krzysztof Kozlowski @ 2019-09-04 17:49 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel
Hi,
Notes:
1. One patch for soc64 sent directly, not as pull req.
2. Drivers and DTS pulls are on top of previous.
3. mach/soc pull replaces previous pull (I see it was not merged).
No dependencies between pulls.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL 1/5] ARM: defconfig: exynos for v5.4
From: Krzysztof Kozlowski @ 2019-09-04 17:49 UTC (permalink / raw)
To: Olof Johansson, Arnd Bergmann, arm, soc
Cc: linux-samsung-soc, Kukjin Kim, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel
In-Reply-To: <20190904175002.10487-1-krzk@kernel.org>
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-defconfig-5.4
for you to fetch changes up to 86759eeb32f70193ca7ebd50cc9b70ccb73d3d89:
ARM: multi_v7_defconfig: Make MAX77802 regulator driver built-in (2019-09-02 17:38:20 +0200)
----------------------------------------------------------------
Samsung defconfig changes for v5.4
1. Enable AHCI platform driver on exynos defconfig for Exynos5250-based
Arndale board,
2. Make Max77802 PMIC regulator driver a built-in on multi_v7 defconfig
as it is essential early during boot.
----------------------------------------------------------------
Marek Szyprowski (2):
ARM: exynos_defconfig: Enable AHCI-platform SATA driver
ARM: multi_v7_defconfig: Make MAX77802 regulator driver built-in
arch/arm/configs/exynos_defconfig | 5 ++++-
arch/arm/configs/multi_v7_defconfig | 2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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