Re: [PATCH v4] pseries: prevent free CPU ids to be reused on another node

- Add comment about the cpu_add_remove_lock protecting the added CPU mask. > Changes since V1 (no functional changes): > - update the test's output in the commit's description > - node_recorded_ids_map should be static > > Signed-off-by: Laurent Dufour Thanks Laurent. Reviewed-by: Nathan Lynch

Re: [PATCH v3] pseries: prevent free CPU ids to be reused on another node

Laurent Dufour writes: > Changes since V2, addressing Nathan's comments: > - Remove the retry feature > - Reduce the number of local variables (removing 'i') I was more interested in not having two variables for NUMA nodes in the function named 'node' and 'nid', hoping at least one of them

Re: [PATCH v2] pseries: prevent free CPU ids to be reused on another node

Laurent Dufour writes: > Le 02/04/2021 à 15:34, Nathan Lynch a écrit : >> Laurent Dufour writes: >>> When a CPU is hot added, the CPU ids are taken from the available mask from >>> the lower possible set. If that set of values was previously used for CPU >&

Re: [PATCH v2] pseries: prevent free CPU ids to be reused on another node

Hi Laurent, Laurent Dufour writes: > When a CPU is hot added, the CPU ids are taken from the available mask from > the lower possible set. If that set of values was previously used for CPU > attached to a different node, this seems to application like if these CPUs > have migrated from a node to

Re: Build regressions/improvements in v5.10-rc1

Geert Uytterhoeven writes: > On Mon, Oct 26, 2020 at 10:46 AM Geert Uytterhoeven > wrote: >> Below is the list of build error/warning regressions/improvements in >> v5.10-rc1[1] compared to v5.9[2]. >> >> Summarized: >> - build errors: +3/-7 >> - build warnings: +26/-28 >> >> Happy fixing!

Re: [PATCH 1/1] powerpc/rtas: Implement reentrant rtas call

Hi Leonardo, Leonardo Bras writes: > Hello Nathan, thanks for the feedback! > > On Fri, 2020-04-10 at 14:28 -0500, Nathan Lynch wrote: >> Leonardo Bras writes: >> > Implement rtas_call_reentrant() for reentrant rtas-calls: >> > "ibm,int-on", &qu

Re: [PATCH v3 2/2] powerpc/rtas: Implement reentrant rtas call

Hi, Leonardo Bras writes: > +/** > + * rtas_call_reentrant() - Used for reentrant rtas calls > + * @token: Token for desired reentrant RTAS call > + * @nargs: Number of Input Parameters > + * @nret:Number of Output Parameters > + * @outputs: Array of outputs > + * @...: Inputs for

Re: [PATCH 0/2] pseries/hotplug: Change the default behaviour of cede_offline

Gautham R Shenoy writes: > The accounting problem in tools such as lparstat with > "cede_offline=on" is affecting customers who are using these tools for > capacity-planning. That problem needs a fix in the short-term, for > which Patch 1 changes the default behaviour of cede_offline from "on" >

Re: [PATCH 0/2] pseries/hotplug: Change the default behaviour of cede_offline

Gautham R Shenoy writes: > On Thu, Sep 12, 2019 at 10:39:45AM -0500, Nathan Lynch wrote: >> "Gautham R. Shenoy" writes: >> > The patchset also defines a new sysfs attribute >> > "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux gu

Re: [PATCH 0/2] pseries/hotplug: Change the default behaviour of cede_offline

"Gautham R. Shenoy" writes: > The patchset also defines a new sysfs attribute > "/sys/device/system/cpu/cede_offline_enabled" on PSeries Linux guests > to allow userspace programs to change the state into which the > offlined CPU need to be put to at runtime. A boolean sysfs interface will

Re: [PATCH 2/2] powerpc/pseries: Delete an error message for a failed string duplication in dlpar_store()

Markus Elfring writes: > From: Markus Elfring > Date: Tue, 27 Aug 2019 13:37:56 +0200 > > Omit an extra message for a memory allocation failure in this function. > > Signed-off-by: Markus Elfring Acked-by: Nathan Lynch

Re: [PATCH 1/2] powerpc/pseries: Delete an unnecessary kfree() call in dlpar_store()

ll. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring Acked-by: Nathan Lynch

Re: [PATCH] powerpc/vdso32: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE

Christophe Leroy writes: > Hi, > > Le 19/08/2019 à 18:37, Nathan Lynch a écrit : >> Hi, >> >> Christophe Leroy writes: >>> Benchmark from vdsotest: >> >> I assume you also ran the verification/correctness parts of vdsotest...? :-)

Re: [PATCH] powerpc/vdso32: Add support for CLOCK_{REALTIME/MONOTONIC}_COARSE

Hi, Christophe Leroy writes: > Benchmark from vdsotest: I assume you also ran the verification/correctness parts of vdsotest...? :-)

Re: [PATCH v2 03/35] powerpc: Use kmemdup rather than duplicating its implementation

Fuqian Huang writes: > kmemdup is introduced to duplicate a region of memory in a neat way. > Rather than kmalloc/kzalloc + memcpy, which the programmer needs to > write the size twice (sometimes lead to mistakes), kmemdup improves > readability, leads to smaller code and also reduce the chances

Re: [PATCH] dlpar: Fix a missing-check bug in dlpar_parse_cc_property()

; cc_workarea *ccwa) > > name = (char *)ccwa + be32_to_cpu(ccwa->name_offset); > prop->name = kstrdup(name, GFP_KERNEL); > + if (!prop->name) { > + dlpar_free_cc_property(prop); > + return NULL; > + } Acked-by: Nathan Lynch

Re: [PATCH] ARM: VDSO: Drop implicit common-page-size linker flag

p it. >> >> Link: >> https://lkml.kernel.org/r/20181206191231.192355-1-ndesaulni...@google.com >> Signed-off-by: Nick Desaulniers >> --- > > The patch looks good to me, > > Acked-by: Arnd Bergmann > > Adding Nathan Lynch to Cc though for further comments, he

Re: [PATCH v2] ARM: vdso: Define vdso_{start,end} as array

e addresses > as char arrays. > > See also: dbbb08f500d6 ("arm64, vdso: Define vdso_{start,end} as array") > > Suggested-by: Mark Rutland <mark.rutl...@arm.com> > Suggested-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > Signed-off-by: Arnd Bergmann <a...@arndb.de> Acked-by: Nathan Lynch <nathan_ly...@mentor.com> Thanks!

Re: [PATCH v2] ARM: vdso: Define vdso_{start,end} as array

ays. > > See also: dbbb08f500d6 ("arm64, vdso: Define vdso_{start,end} as array") > > Suggested-by: Mark Rutland > Suggested-by: Ard Biesheuvel > Signed-off-by: Arnd Bergmann Acked-by: Nathan Lynch Thanks!

Re: [PATCHv2 1/2] arm64:vdso: Rewrite gettimeofday into C.

Will Deacon writes: > On Tue, May 30, 2017 at 05:34:19PM -0700, Andrew Pinski wrote: >> Note I noticed a bug in the old implementation of __kernel_clock_getres; >> it was checking only the lower 32bits of the pointer; this would work >> for most cases but could fail in a few.

Re: [PATCHv2 1/2] arm64:vdso: Rewrite gettimeofday into C.

Will Deacon writes: > On Tue, May 30, 2017 at 05:34:19PM -0700, Andrew Pinski wrote: >> Note I noticed a bug in the old implementation of __kernel_clock_getres; >> it was checking only the lower 32bits of the pointer; this would work >> for most cases but could fail in a few. >> >> Changes from

Re: [PATCH v3] ARM: VDSO: put RO and RO after init objects into proper sections

o_after_init in mind. :) > > Reviewed-by: Kees Cook <keesc...@chromium.org> Looks fine and nothing goes wrong with my vdso tests. Please send it through Russell. Acked-by: Nathan Lynch <nathan_ly...@mentor.com>

Re: [PATCH v3] ARM: VDSO: put RO and RO after init objects into proper sections

Looks fine and nothing goes wrong with my vdso tests. Please send it through Russell. Acked-by: Nathan Lynch

Re: [PATCH] ARM: VDSO: put read only/mostly objects into proper sections

On 08/10/2016 01:47 PM, Kees Cook wrote: > On Wed, Aug 10, 2016 at 2:59 AM, Jisheng Zhang wrote: >> + Kees >> >> On Wed, 10 Aug 2016 17:09:47 +0800 wrote: >> >>> vdso_data_mapping is never modified, so mark it as const. >>> >>> vdso_data_page and vdso_text_mapping are

Re: [PATCH] ARM: VDSO: put read only/mostly objects into proper sections

On 08/10/2016 01:47 PM, Kees Cook wrote: > On Wed, Aug 10, 2016 at 2:59 AM, Jisheng Zhang wrote: >> + Kees >> >> On Wed, 10 Aug 2016 17:09:47 +0800 wrote: >> >>> vdso_data_mapping is never modified, so mark it as const. >>> >>> vdso_data_page and vdso_text_mapping are initialized by vdso_init(),

Re: [PATCH v4] ARM: fix vdsomunge not to depend on glibc specific byteswap.h

On 10/16/2015 01:38 AM, H. Nikolaus Schaller wrote: > diff --git a/arch/arm/vdso/vdsomunge.c b/arch/arm/vdso/vdsomunge.c > index aedec81..0cebd98 100644 > --- a/arch/arm/vdso/vdsomunge.c > +++ b/arch/arm/vdso/vdsomunge.c > @@ -45,7 +45,6 @@ > * it does. > */ > > -#include > #include >

Re: [PATCH v4] ARM: fix vdsomunge not to depend on glibc specific byteswap.h

On 10/16/2015 01:38 AM, H. Nikolaus Schaller wrote: > diff --git a/arch/arm/vdso/vdsomunge.c b/arch/arm/vdso/vdsomunge.c > index aedec81..0cebd98 100644 > --- a/arch/arm/vdso/vdsomunge.c > +++ b/arch/arm/vdso/vdsomunge.c > @@ -45,7 +45,6 @@ > * it does. > */ > > -#include > #include >

Re: [PATCH v2] ARM: fix vdsomunge not to depend on glibc specific byteswap.h

On 10/15/2015 12:16 PM, H. Nikolaus Schaller wrote: > Does this mean it is ok now in V3 in all cases? I have switched my patch > editor > tool from indirect git imap-send to git send-email (which appears to be more > compatible). v3 applied without issue, so yes, in that respect it is fine. --

Re: [PATCH v2] ARM: fix vdsomunge not to depend on glibc specific byteswap.h

On 10/15/2015 12:52 AM, H. Nikolaus Schaller wrote: > Am 14.10.2015 um 16:16 schrieb Nathan Lynch : >> and it would be easier for me to deal with a patch that isn't >> whitespace-damaged. > > You mean: > > ERROR: space prohibited before that close parenthesis ')'

Re: [PATCH v2] ARM: fix vdsomunge not to depend on glibc specific byteswap.h

On 10/15/2015 12:52 AM, H. Nikolaus Schaller wrote: > Am 14.10.2015 um 16:16 schrieb Nathan Lynch <nathan_ly...@mentor.com>: >> and it would be easier for me to deal with a patch that isn't >> whitespace-damaged. > > You mean: > > ERROR: space prohibited before

Re: [PATCH v2] ARM: fix vdsomunge not to depend on glibc specific byteswap.h

On 10/15/2015 12:16 PM, H. Nikolaus Schaller wrote: > Does this mean it is ok now in V3 in all cases? I have switched my patch > editor > tool from indirect git imap-send to git send-email (which appears to be more > compatible). v3 applied without issue, so yes, in that respect it is fine. --

Re: [PATCH v2] ARM: fix vdsomunge not to depend on glibc specific byteswap.h

On 10/14/2015 07:47 AM, H. Nikolaus Schaller wrote: >> diff --git a/arch/arm/vdso/vdsomunge.c b/arch/arm/vdso/vdsomunge.c >> index aedec81..27a9a0b 100644 >> --- a/arch/arm/vdso/vdsomunge.c >> +++ b/arch/arm/vdso/vdsomunge.c >> @@ -45,7 +45,18 @@ >> * it does. >> */ >> >> -#include >> +#define

Re: [PATCH v2] ARM: fix vdsomunge not to depend on glibc specific byteswap.h

On 10/14/2015 07:47 AM, H. Nikolaus Schaller wrote: >> diff --git a/arch/arm/vdso/vdsomunge.c b/arch/arm/vdso/vdsomunge.c >> index aedec81..27a9a0b 100644 >> --- a/arch/arm/vdso/vdsomunge.c >> +++ b/arch/arm/vdso/vdsomunge.c >> @@ -45,7 +45,18 @@ >> * it does. >> */ >> >> -#include >> +#define

Re: [PATCH] ARM: fix vdsomunge depends on glibc specific byteswap.h

On 09/30/2015 12:47 PM, H. Nikolaus Schaller wrote: > > Am 30.09.2015 um 19:37 schrieb Nathan Lynch : >> Why not just use a generic >> implementation like is found in mips' elf2ecoff? > > Do you have a reference? > I can't find byte swapping in > > https://git

Re: [PATCH] ARM: fix vdsomunge depends on glibc specific byteswap.h

On 09/30/2015 11:17 AM, Ard Biesheuvel wrote: > On 30 September 2015 at 18:13, H. Nikolaus Schaller > wrote: >> >> Am 30.09.2015 um 18:02 schrieb Ard Biesheuvel : >>> >>> Have you tried this? >>> >>> #define bswap_16 __builtin_bswap16 >>> #define bswap_32 __builtin_bswap32 >>> #define bswap_64

Re: [PATCH] ARM: fix vdsomunge depends on glibc specific byteswap.h

On 09/30/2015 12:47 PM, H. Nikolaus Schaller wrote: > > Am 30.09.2015 um 19:37 schrieb Nathan Lynch <nathan_ly...@mentor.com>: >> Why not just use a generic >> implementation like is found in mips' elf2ecoff? > > Do you have a reference? > I can't

Re: [PATCH] ARM: fix vdsomunge depends on glibc specific byteswap.h

On 09/30/2015 11:17 AM, Ard Biesheuvel wrote: > On 30 September 2015 at 18:13, H. Nikolaus Schaller > wrote: >> >> Am 30.09.2015 um 18:02 schrieb Ard Biesheuvel : >>> >>> Have you tried this? >>> >>> #define bswap_16 __builtin_bswap16 >>> #define

Re: [PATCH v5 17/23] arm64:ilp32: add vdso-ilp32 and use for signal return

On 09/29/2015 05:14 PM, Yury Norov wrote: > From: Philipp Tomsich > > Adjusted to move the move data page before code pages in sync with > commit 601255ae3c98fd3a8bb4696425e4f868b4f1 This commit message needs more information about how the ilp32 VDSO uses the existing arm64 code. I had to

Re: [PATCH v5 17/23] arm64:ilp32: add vdso-ilp32 and use for signal return

On 09/29/2015 05:14 PM, Yury Norov wrote: > From: Philipp Tomsich > > Adjusted to move the move data page before code pages in sync with > commit 601255ae3c98fd3a8bb4696425e4f868b4f1 This commit message needs more information about how the ilp32 VDSO

Re: [PATCH v2 3/4] remoteproc: Supply controller driver for ST's Remote Processors

On 08/28/2015 05:31 AM, Lee Jones wrote: > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig > index 28c711f..72e97d7 100644 > --- a/drivers/remoteproc/Kconfig > +++ b/drivers/remoteproc/Kconfig > @@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC > It's safe to say n here if

Re: [PATCH v2 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs

On 08/28/2015 05:31 AM, Lee Jones wrote: > +static ssize_t rproc_state_write(struct file *filp, const char __user > *userbuf, > + size_t count, loff_t *ppos) > +{ > + struct rproc *rproc = filp->private_data; > + char buf[2]; > + int ret; > + > + ret =

Re: [PATCH v2 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs

On 08/28/2015 05:31 AM, Lee Jones wrote: +static ssize_t rproc_state_write(struct file *filp, const char __user *userbuf, + size_t count, loff_t *ppos) +{ + struct rproc *rproc = filp-private_data; + char buf[2]; + int ret; + + ret =

Re: [PATCH v2 3/4] remoteproc: Supply controller driver for ST's Remote Processors

On 08/28/2015 05:31 AM, Lee Jones wrote: diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index 28c711f..72e97d7 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC It's safe to say n here if you're

Re: [PATCH] soc: ti: reset irq affinity before freeing irq

On 08/27/2015 01:23 PM, Murali Karicheri wrote: > On 08/27/2015 12:43 PM, Nathan Lynch wrote: >> On 08/27/2015 10:51 AM, Murali Karicheri wrote: >>> When using accumulator queue for rx side for network driver, following >>> warning is seen when doing a reboot

Re: [PATCH] soc: ti: reset irq affinity before freeing irq

On 08/27/2015 10:51 AM, Murali Karicheri wrote: > When using accumulator queue for rx side for network driver, following > warning is seen when doing a reboot command from Linux console. This > is because, affinity value is not reset before calling free_irq(). This > patch fixes this. > >

Re: [PATCH] soc: ti: reset irq affinity before freeing irq

On 08/27/2015 10:51 AM, Murali Karicheri wrote: When using accumulator queue for rx side for network driver, following warning is seen when doing a reboot command from Linux console. This is because, affinity value is not reset before calling free_irq(). This patch fixes this. Deconfiguring

Re: [PATCH] soc: ti: reset irq affinity before freeing irq

On 08/27/2015 01:23 PM, Murali Karicheri wrote: On 08/27/2015 12:43 PM, Nathan Lynch wrote: On 08/27/2015 10:51 AM, Murali Karicheri wrote: When using accumulator queue for rx side for network driver, following warning is seen when doing a reboot command from Linux console. This is because

Re: [PATCH 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs

On 08/26/2015 08:08 AM, Lee Jones wrote: > Signed-off-by: Lee Jones > --- > drivers/remoteproc/remoteproc_debugfs.c | 25 + > 1 file changed, 25 insertions(+) The commit message should describe why this is needed... > diff --git

Re: [PATCH 2/4] remoteproc: Supply controller driver for ST's Remote Processors

On 08/26/2015 08:08 AM, Lee Jones wrote: > --- /dev/null > +++ b/drivers/remoteproc/st_remoteproc.c > @@ -0,0 +1,300 @@ > +/* > + * ST's Remote Processor Control Driver > + * > + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved > + * > + * Author: Ludovic Barre When submitting code

Re: [PATCH 1/4] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

On 08/26/2015 08:08 AM, Lee Jones wrote: > diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt > b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt > new file mode 100644 > index 000..6a933c1 > --- /dev/null > +++

Re: [PATCH 1/4] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

On 08/26/2015 08:08 AM, Lee Jones wrote: diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt new file mode 100644 index 000..6a933c1 --- /dev/null +++

Re: [PATCH 4/4] remoteproc: debugfs: Add ability to boot remote processor using debugfs

On 08/26/2015 08:08 AM, Lee Jones wrote: Signed-off-by: Lee Jones lee.jo...@linaro.org --- drivers/remoteproc/remoteproc_debugfs.c | 25 + 1 file changed, 25 insertions(+) The commit message should describe why this is needed... diff --git

Re: [PATCH 2/4] remoteproc: Supply controller driver for ST's Remote Processors

On 08/26/2015 08:08 AM, Lee Jones wrote: --- /dev/null +++ b/drivers/remoteproc/st_remoteproc.c @@ -0,0 +1,300 @@ +/* + * ST's Remote Processor Control Driver + * + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved + * + * Author: Ludovic Barre ludovic.ba...@st.com When

[PATCH v2] ARM: VDSO: fix coarse clock monotonicity regression

ernel_time would access the same timekeeper object which had been passed to update_vsyscall. This is no longer the case. Signed-off-by: Nathan Lynch --- Changes since v1: - Add u32 cast to nsec calculation. arch/arm/kernel/vdso.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-)

[PATCH v2] ARM: VDSO: fix coarse clock monotonicity regression

access the same timekeeper object which had been passed to update_vsyscall. This is no longer the case. Signed-off-by: Nathan Lynch nathan_ly...@mentor.com --- Changes since v1: - Add u32 cast to nsec calculation. arch/arm/kernel/vdso.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions

[PATCH 1/2] ARM: VDSO: fix coarse clock monotonicity regression

ernel_time would access the same timekeeper object which had been passed to update_vsyscall. This is no longer the case. Signed-off-by: Nathan Lynch --- arch/arm/kernel/vdso.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vd

[PATCH 0/2] fix vdso coarse clock monotonicity regressions

e bothered if they don't make 4.2 final at this late stage, since only the (seldom-used?) coarse clocks are affected. I'd like to collect review/acks for these now and make sure they at least make it into 4.3-rc1 (and -stable after that). Nathan Lynch (2): ARM: VDSO: fix coarse clock monotonicity

[PATCH 2/2] arm64: VDSO: fix coarse clock monotonicity regression

ernel_time would access the same timekeeper object which had been passed to update_vsyscall. This is no longer the case. Signed-off-by: Nathan Lynch --- arch/arm64/kernel/vdso.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/ker

Re: [PATCH] x86/vdso: Emit a GNU hash

On 08/06/2015 05:52 PM, Andy Lutomirski wrote: > [adding lots of cc's] > > On Thu, Aug 6, 2015 at 2:45 PM, Andy Lutomirski wrote: >> From: Andy Lutomirski >> >> Some dynamic loaders may be slightly faster if a GNU hash is >> available. Strangely, this seems to have no effect at all on the >>

[PATCH 1/2] ARM: VDSO: fix coarse clock monotonicity regression

access the same timekeeper object which had been passed to update_vsyscall. This is no longer the case. Signed-off-by: Nathan Lynch nathan_ly...@mentor.com --- arch/arm/kernel/vdso.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm/kernel/vdso.c b/arch/arm

[PATCH 0/2] fix vdso coarse clock monotonicity regressions

if they don't make 4.2 final at this late stage, since only the (seldom-used?) coarse clocks are affected. I'd like to collect review/acks for these now and make sure they at least make it into 4.3-rc1 (and -stable after that). Nathan Lynch (2): ARM: VDSO: fix coarse clock monotonicity regression arm64

[PATCH 2/2] arm64: VDSO: fix coarse clock monotonicity regression

would access the same timekeeper object which had been passed to update_vsyscall. This is no longer the case. Signed-off-by: Nathan Lynch nathan_ly...@mentor.com --- arch/arm64/kernel/vdso.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/arch/arm64/kernel/vdso.c b/arch

Re: [PATCH] x86/vdso: Emit a GNU hash

On 08/06/2015 05:52 PM, Andy Lutomirski wrote: [adding lots of cc's] On Thu, Aug 6, 2015 at 2:45 PM, Andy Lutomirski l...@kernel.org wrote: From: Andy Lutomirski l...@amacapital.net Some dynamic loaders may be slightly faster if a GNU hash is available. Strangely, this seems to have no

Re: [PATCH v3 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135

On 07/14/2015 12:18 AM, Yingjoe Chen wrote: > Add arch timer node to enable arch-timer support. MT8135 firmware > doesn't correctly setup arch-timer frequency and CNTVOFF, add > properties to workaround this. [...] > > + timer { > + compatible = "arm,armv7-timer"; > +

Re: [PATCH v3 4/5] ARM: dts: mt8135: enable basic SMP bringup for mt8135

On 07/14/2015 12:18 AM, Yingjoe Chen wrote: Add arch timer node to enable arch-timer support. MT8135 firmware doesn't correctly setup arch-timer frequency and CNTVOFF, add properties to workaround this. [...] + timer { + compatible = arm,armv7-timer; +

Re: [PATCH] arm: vdso: .gitignore: ignore generated vdso.so.raw and vdsomunge

On 04/28/2015 03:32 PM, Andrey Skvortsov wrote: > After kernel is built 'git status' reports: > > # Untracked files: > # (use "git add ..." to include in what will be committed) > # > #arch/arm/vdso/vdso.so.raw > #arch/arm/vdso/vdsomunge > > These files are created during

Re: [PATCH 1/2] clocksource: arm_arch_timer: add arch_timer_okay_for_vdso

On 04/27/2015 05:55 AM, Will Deacon wrote: > On Fri, Apr 24, 2015 at 10:43:20PM +0100, Nathan Lynch wrote: >> The 32-bit ARM VDSO needs to know whether a generic timer is present >> and whether it is suitable for use by user space. The VDSO >> initialization code curr

Re: [PATCH 1/2] clocksource: arm_arch_timer: add arch_timer_okay_for_vdso

On 04/27/2015 05:55 AM, Will Deacon wrote: On Fri, Apr 24, 2015 at 10:43:20PM +0100, Nathan Lynch wrote: The 32-bit ARM VDSO needs to know whether a generic timer is present and whether it is suitable for use by user space. The VDSO initialization code currently duplicates some of the logic

Re: [PATCH] arm: vdso: .gitignore: ignore generated vdso.so.raw and vdsomunge

On 04/28/2015 03:32 PM, Andrey Skvortsov wrote: After kernel is built 'git status' reports: # Untracked files: # (use git add file... to include in what will be committed) # #arch/arm/vdso/vdso.so.raw #arch/arm/vdso/vdsomunge These files are created during build

[PATCH 1/2] clocksource: arm_arch_timer: add arch_timer_okay_for_vdso

the VDSO init code whether the arch timer is present and usable. Signed-off-by: Nathan Lynch --- drivers/clocksource/arm_arch_timer.c | 12 include/clocksource/arm_arch_timer.h | 6 ++ 2 files changed, 18 insertions(+) diff --git a/drivers/clocksource/arm_arch_timer.c b

[PATCH 2/2] ARM: VDSO: use arch_timer_okay_for_vdso

Use the facility now provided by the arm_arch_timer driver to determine whether there's a usable virtual counter for the VDSO. Signed-off-by: Nathan Lynch --- arch/arm/kernel/vdso.c | 30 +- 1 file changed, 1 insertion(+), 29 deletions(-) diff --git a/arch/arm

[PATCH 1/2] clocksource: arm_arch_timer: add arch_timer_okay_for_vdso

the VDSO init code whether the arch timer is present and usable. Signed-off-by: Nathan Lynch nathan_ly...@mentor.com --- drivers/clocksource/arm_arch_timer.c | 12 include/clocksource/arm_arch_timer.h | 6 ++ 2 files changed, 18 insertions(+) diff --git a/drivers/clocksource

[PATCH 2/2] ARM: VDSO: use arch_timer_okay_for_vdso

Use the facility now provided by the arm_arch_timer driver to determine whether there's a usable virtual counter for the VDSO. Signed-off-by: Nathan Lynch nathan_ly...@mentor.com --- arch/arm/kernel/vdso.c | 30 +- 1 file changed, 1 insertion(+), 29 deletions(-) diff

Re: linux-next: build failure after merge of the tip tree

On 03/30/2015 10:08 AM, Russell King - ARM Linux wrote: > On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote: >> On 03/30/2015 03:08 AM, Stephen Rothwell wrote: >>> Hi Russell, >>> >>> On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux >

Re: linux-next: build failure after merge of the tip tree

On 03/30/2015 03:08 AM, Stephen Rothwell wrote: > Hi Russell, > > On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux > wrote: >> >> I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep >> it in my tree and keep my tree buildable without dragging in the tip >> tree. >

Re: linux-next: build failure after merge of the tip tree

On 03/30/2015 03:08 AM, Stephen Rothwell wrote: Hi Russell, On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux li...@arm.linux.org.uk wrote: I'll drop the VDSO stuff from the ARM tree; I can't see a way to keep it in my tree and keep my tree buildable without dragging in the tip

Re: linux-next: build failure after merge of the tip tree

On 03/30/2015 10:08 AM, Russell King - ARM Linux wrote: On Mon, Mar 30, 2015 at 09:57:48AM -0500, Nathan Lynch wrote: On 03/30/2015 03:08 AM, Stephen Rothwell wrote: Hi Russell, On Mon, 30 Mar 2015 08:15:37 +0100 Russell King - ARM Linux li...@arm.linux.org.uk wrote: I'll drop the VDSO

Re: [PATCH 2/2] remoteproc: microblaze: Add support for microblaze on Zynq

On 01/19/2015 04:30 AM, Michal Simek wrote: > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig > index 5e343bab9458..3955f42e9e9c 100644 > --- a/drivers/remoteproc/Kconfig > +++ b/drivers/remoteproc/Kconfig > @@ -64,4 +64,15 @@ config DA8XX_REMOTEPROC > It's safe to say

Re: [PATCH 2/2] remoteproc: microblaze: Add support for microblaze on Zynq

On 01/19/2015 04:30 AM, Michal Simek wrote: diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig index 5e343bab9458..3955f42e9e9c 100644 --- a/drivers/remoteproc/Kconfig +++ b/drivers/remoteproc/Kconfig @@ -64,4 +64,15 @@ config DA8XX_REMOTEPROC It's safe to say n

Re: [PATCH] tracing/syscalls: ignore numbers outside NR_syscalls' range

On 10/30/2014 06:35 AM, Russell King - ARM Linux wrote: > On Thu, Oct 30, 2014 at 07:30:28AM -0400, Steven Rostedt wrote: >> On Thu, 30 Oct 2014 11:14:41 + >> Russell King - ARM Linux wrote: >> >> >>> We have always had syscall number range of 0x90 or so. The tracing >>> design does not

Re: [PATCH] tracing/syscalls: ignore numbers outside NR_syscalls' range

On 10/30/2014 06:35 AM, Russell King - ARM Linux wrote: On Thu, Oct 30, 2014 at 07:30:28AM -0400, Steven Rostedt wrote: On Thu, 30 Oct 2014 11:14:41 + Russell King - ARM Linux li...@arm.linux.org.uk wrote: We have always had syscall number range of 0x90 or so. The tracing design

Re: RCU bug with v3.17-rc3 ?

On 10/10/2014 08:44 PM, Nathan Lynch wrote: > On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote: >> >> Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and >> it seems that this has been known about for some time.) > > Looking at http://g

Re: RCU bug with v3.17-rc3 ?

On 10/10/2014 08:44 PM, Nathan Lynch wrote: On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote: Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and it seems that this has been known about for some time.) Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x

Re: RCU bug with v3.17-rc3 ?

On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote: > > Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and > it seems that this has been known about for some time.) Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x for x < 3 are affected, as well as 4.9.0. >

Re: RCU bug with v3.17-rc3 ?

On 10/10/2014 11:25 AM, Russell King - ARM Linux wrote: Right, so GCC 4.8.{1,2} are totally unsuitable for kernel building (and it seems that this has been known about for some time.) Looking at http://gcc.gnu.org/PR58854 it seems that all 4.8.x for x 3 are affected, as well as 4.9.0. We

Re: [PATCH v2 1/3] clocksource: arm_arch_timer: change clocksource name if CP15 unavailable

Hi Daniel, On 09/26/2014 02:04 AM, Daniel Lezcano wrote: > On 09/18/2014 04:59 PM, Nathan Lynch wrote: >> The arm and arm64 VDSOs need CP15 access to the architected counter. >> If this is unavailable (which is allowed by ARM v7), indicate this by >> changing

Re: [PATCH v2 1/3] clocksource: arm_arch_timer: change clocksource name if CP15 unavailable

Hi Daniel, On 09/26/2014 02:04 AM, Daniel Lezcano wrote: On 09/18/2014 04:59 PM, Nathan Lynch wrote: The arm and arm64 VDSOs need CP15 access to the architected counter. If this is unavailable (which is allowed by ARM v7), indicate this by changing the clocksource name to arch_mem_counter

Re: [PATCH v2 0/3] arm_arch_timer: VDSO preparation, code consolidation

On 09/24/2014 09:50 AM, Russell King - ARM Linux wrote: > On Wed, Sep 24, 2014 at 09:32:54AM -0500, Nathan Lynch wrote: >> On 09/24/2014 09:12 AM, Christopher Covington wrote: >>> Hi Nathan, >>> >>> On 09/22/2014 08:28 PM, Nathan Lynch wrote: >>

Re: [PATCH v2 0/3] arm_arch_timer: VDSO preparation, code consolidation

On 09/24/2014 09:12 AM, Christopher Covington wrote: > Hi Nathan, > > On 09/22/2014 08:28 PM, Nathan Lynch wrote: >> On 09/22/2014 05:30 PM, Russell King - ARM Linux wrote: >>> On Mon, Sep 22, 2014 at 04:39:19PM +0100, Will Deacon wrote: >>>> On Thu, Sep 18, 20

Re: [PATCH v2 0/3] arm_arch_timer: VDSO preparation, code consolidation

On 09/24/2014 09:12 AM, Christopher Covington wrote: Hi Nathan, On 09/22/2014 08:28 PM, Nathan Lynch wrote: On 09/22/2014 05:30 PM, Russell King - ARM Linux wrote: On Mon, Sep 22, 2014 at 04:39:19PM +0100, Will Deacon wrote: On Thu, Sep 18, 2014 at 03:59:32PM +0100, Nathan Lynch wrote

Re: [PATCH v2 0/3] arm_arch_timer: VDSO preparation, code consolidation

On 09/24/2014 09:50 AM, Russell King - ARM Linux wrote: On Wed, Sep 24, 2014 at 09:32:54AM -0500, Nathan Lynch wrote: On 09/24/2014 09:12 AM, Christopher Covington wrote: Hi Nathan, On 09/22/2014 08:28 PM, Nathan Lynch wrote: Hmm, this patch set is merely exposing the hardware counter when

Re: [PATCH v2 0/3] arm_arch_timer: VDSO preparation, code consolidation

On 09/22/2014 05:30 PM, Russell King - ARM Linux wrote: > On Mon, Sep 22, 2014 at 04:39:19PM +0100, Will Deacon wrote: >> On Thu, Sep 18, 2014 at 03:59:32PM +0100, Nathan Lynch wrote: >>> This series contains the necessary changes to allow architected timer >>> access fr

Re: [PATCH v2 0/3] arm_arch_timer: VDSO preparation, code consolidation

On 09/22/2014 10:39 AM, Will Deacon wrote: > On Thu, Sep 18, 2014 at 03:59:32PM +0100, Nathan Lynch wrote: >> This series contains the necessary changes to allow architected timer >> access from user-space on 32-bit ARM. This allows the VDSO to support >> high

Re: [PATCH v2 0/3] arm_arch_timer: VDSO preparation, code consolidation

On 09/22/2014 10:39 AM, Will Deacon wrote: On Thu, Sep 18, 2014 at 03:59:32PM +0100, Nathan Lynch wrote: This series contains the necessary changes to allow architected timer access from user-space on 32-bit ARM. This allows the VDSO to support high resolution timestamps for clock_gettime

Re: [PATCH v2 0/3] arm_arch_timer: VDSO preparation, code consolidation

On 09/22/2014 05:30 PM, Russell King - ARM Linux wrote: On Mon, Sep 22, 2014 at 04:39:19PM +0100, Will Deacon wrote: On Thu, Sep 18, 2014 at 03:59:32PM +0100, Nathan Lynch wrote: This series contains the necessary changes to allow architected timer access from user-space on 32-bit ARM

[PATCH v2 3/3] clocksource: arm_arch_timer: consolidate arch_timer_evtstrm_enable

The arch_timer_evtstrm_enable hooks in arm and arm64 are substantially similar, the only difference being a CONFIG_COMPAT-conditional section which is relevant only for arm64. Copy the arm64 version to the driver, removing the arch-specific hooks. Signed-off-by: Nathan Lynch --- arch/arm

[PATCH v2 1/3] clocksource: arm_arch_timer: change clocksource name if CP15 unavailable

The arm and arm64 VDSOs need CP15 access to the architected counter. If this is unavailable (which is allowed by ARM v7), indicate this by changing the clocksource name to "arch_mem_counter" before registering the clocksource. Suggested by Stephen Boyd. Signed-off-by: Nathan Lynch

[PATCH v2 2/3] clocksource: arm_arch_timer: enable counter access for 32-bit ARM

implementations. Signed-off-by: Nathan Lynch --- arch/arm/include/asm/arch_timer.h| 14 -- arch/arm64/include/asm/arch_timer.h | 17 - drivers/clocksource/arm_arch_timer.c | 17 + 3 files changed, 17 insertions(+), 31 deletions(-) diff --git a/arch

[PATCH v2 0/3] arm_arch_timer: VDSO preparation, code consolidation

h slightly different names in one patch, then removed the unused functions in subsequent patches for each of arm and arm64. This seemed kind of awkward to me, so I've reorganized those changes into two patches that should be easier to review. Patch #1 is unchanged. Nathan Lynch (3): c

[PATCH v2 0/3] arm_arch_timer: VDSO preparation, code consolidation

different names in one patch, then removed the unused functions in subsequent patches for each of arm and arm64. This seemed kind of awkward to me, so I've reorganized those changes into two patches that should be easier to review. Patch #1 is unchanged. Nathan Lynch (3): clocksource

  1   2   3   >