Re: [PATCH][RESEND 2] component: enhance handling of devres group for master

On Wed, Jul 25, 2018 at 11:06:28PM -0700, bgosw...@codeaurora.org wrote: > From: Banajit Goswami > > The devres group opened for a master is left open-ended (without > devres_group_close) even after bind() is complete. Similarly, while > releasing the devres resources for master, the most

Re: [PATCH] arm: enable RapidIO config options in Kconfig

On Tue, Jul 24, 2018 at 09:41:26AM -0400, Alexei Colin wrote: > ARM SoCs with a PCI bus offer the RapiodIO config menu; SoCs with > RapidIO IP blocks but without a PCI bus, need to add "select > HAS_RAPIDIO" to the Kconfig entry for that SoC (e.g. ARCH_*). > > HAS_RAPIDIO was chosen over

Re: [PATCH] arm: enable RapidIO config options in Kconfig

On Tue, Jul 24, 2018 at 09:41:26AM -0400, Alexei Colin wrote: > ARM SoCs with a PCI bus offer the RapiodIO config menu; SoCs with > RapidIO IP blocks but without a PCI bus, need to add "select > HAS_RAPIDIO" to the Kconfig entry for that SoC (e.g. ARCH_*). > > HAS_RAPIDIO was chosen over

Re: Enquiry on unbalanced memory throughput for dual-Cortex A9 core.

On Fri, Jul 20, 2018 at 08:49:47AM +, Ooi, Tzy Way wrote: > Hi Russell, > > I am trying the memory write operation with the LM benchmark test. I > tried to execute the memory write operation here > > twice to get both Cortex A9

Re: Enquiry on unbalanced memory throughput for dual-Cortex A9 core.

On Fri, Jul 20, 2018 at 08:49:47AM +, Ooi, Tzy Way wrote: > Hi Russell, > > I am trying the memory write operation with the LM benchmark test. I > tried to execute the memory write operation here > > twice to get both Cortex A9

Re: [PATCH] ARM64: smp: Fix cpu_up() racing with sys_reboot

On Thu, Jul 19, 2018 at 03:18:46PM -0700, Venkata Narendra Kumar Gutta wrote: > Nothing stops a process from hotplugging in a CPU concurrently > with a sys_reboot() call. In such a situation we could have > ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the > fact that the CPU is not

Re: [PATCH] ARM64: smp: Fix cpu_up() racing with sys_reboot

On Thu, Jul 19, 2018 at 03:18:46PM -0700, Venkata Narendra Kumar Gutta wrote: > Nothing stops a process from hotplugging in a CPU concurrently > with a sys_reboot() call. In such a situation we could have > ipi_cpu_stop() mark a cpu as 'offline' and _cpu_up() ignore the > fact that the CPU is not

Re: arm: v4.18-rc5 with cpuidle on TC2 (A7 boot) spectre v2 issue

On Thu, Jul 19, 2018 at 11:01:10AM +0100, Russell King - ARM Linux wrote: > On Thu, Jul 19, 2018 at 11:42:50AM +0200, Dietmar Eggemann wrote: > > Hi, > > > > running v4.18-rc5 (plus still missing "power: vexpress: fix corruption in > > notifier registration",

Re: arm: v4.18-rc5 with cpuidle on TC2 (A7 boot) spectre v2 issue

On Thu, Jul 19, 2018 at 11:01:10AM +0100, Russell King - ARM Linux wrote: > On Thu, Jul 19, 2018 at 11:42:50AM +0200, Dietmar Eggemann wrote: > > Hi, > > > > running v4.18-rc5 (plus still missing "power: vexpress: fix corruption in > > notifier registration",

Re: arm: v4.18-rc5 with cpuidle on TC2 (A7 boot) spectre v2 issue

On Thu, Jul 19, 2018 at 11:39:19AM +0100, Morten Rasmussen wrote: > On Thu, Jul 19, 2018 at 11:01:10AM +0100, Russell King - ARM Linux wrote: > > On Thu, Jul 19, 2018 at 11:42:50AM +0200, Dietmar Eggemann wrote: > > > Hi, > > > > > > running v4.18-rc5 (plus

Re: arm: v4.18-rc5 with cpuidle on TC2 (A7 boot) spectre v2 issue

On Thu, Jul 19, 2018 at 11:39:19AM +0100, Morten Rasmussen wrote: > On Thu, Jul 19, 2018 at 11:01:10AM +0100, Russell King - ARM Linux wrote: > > On Thu, Jul 19, 2018 at 11:42:50AM +0200, Dietmar Eggemann wrote: > > > Hi, > > > > > > running v4.18-rc5 (plus

Re: arm: v4.18-rc5 with cpuidle on TC2 (A7 boot) spectre v2 issue

On Thu, Jul 19, 2018 at 11:42:50AM +0200, Dietmar Eggemann wrote: > Hi, > > running v4.18-rc5 (plus still missing "power: vexpress: fix corruption in > notifier registration", otherwise I get this rcu_sched stall issue) on TC2 > (A7 boot) with vanilla multi_v7_defconfig plus >

Re: arm: v4.18-rc5 with cpuidle on TC2 (A7 boot) spectre v2 issue

On Thu, Jul 19, 2018 at 11:42:50AM +0200, Dietmar Eggemann wrote: > Hi, > > running v4.18-rc5 (plus still missing "power: vexpress: fix corruption in > notifier registration", otherwise I get this rcu_sched stall issue) on TC2 > (A7 boot) with vanilla multi_v7_defconfig plus >

Re: [PATCH] clk: Add functions to get optional clocks

On Wed, Jul 18, 2018 at 01:57:38PM +0100, Phil Edworthy wrote: > Behaves the same as (devm_)clk_get except where there is no clock > producer. In this case, instead of returning -ENOENT, the function > returns NULL. This makes error checking simpler and allows > clk_prepare_enable, etc to be

Re: [PATCH] clk: Add functions to get optional clocks

On Wed, Jul 18, 2018 at 01:57:38PM +0100, Phil Edworthy wrote: > Behaves the same as (devm_)clk_get except where there is no clock > producer. In this case, instead of returning -ENOENT, the function > returns NULL. This makes error checking simpler and allows > clk_prepare_enable, etc to be

Re: [PATCH v1 1/1] clk: npcm7xx: get fixed clocks from DT

On Mon, Jul 16, 2018 at 01:10:07PM +0300, Tali Perry wrote: > Nuvoton NPCM7XX Clock Controller > fix base address and of_clk_get_by_name error handling. > Also update error messages to be more informative. > > In case clk_base allocation is erronoeous the return value is null. >

Re: [PATCH v1 1/1] clk: npcm7xx: get fixed clocks from DT

On Mon, Jul 16, 2018 at 01:10:07PM +0300, Tali Perry wrote: > Nuvoton NPCM7XX Clock Controller > fix base address and of_clk_get_by_name error handling. > Also update error messages to be more informative. > > In case clk_base allocation is erronoeous the return value is null. >

Re: linux-next: Signed-off-by missing for commits in the arm-soc tree

On Mon, Jul 16, 2018 at 05:24:08PM +0800, Chen-Yu Tsai wrote: > On Mon, Jul 16, 2018 at 5:13 PM, Florian Fainelli > wrote: > > > > > > On 07/15/2018 03:50 PM, Olof Johansson wrote: > >> Thanks Stephen, I keep saying every time you catch these that I need > >> to run the same script. :( > >> > >>

Re: linux-next: Signed-off-by missing for commits in the arm-soc tree

On Mon, Jul 16, 2018 at 05:24:08PM +0800, Chen-Yu Tsai wrote: > On Mon, Jul 16, 2018 at 5:13 PM, Florian Fainelli > wrote: > > > > > > On 07/15/2018 03:50 PM, Olof Johansson wrote: > >> Thanks Stephen, I keep saying every time you catch these that I need > >> to run the same script. :( > >> > >>

Re: [PATCH v2 3/6] ARM: trusted_foundations: do not use naked function

On Thu, Jul 12, 2018 at 03:43:10PM -0700, Kees Cook wrote: > On Tue, Apr 17, 2018 at 1:11 AM, Thierry Reding wrote: > > On Mon, Apr 16, 2018 at 08:21:09PM +0200, Stefan Agner wrote: > >> On 16.04.2018 18:08, Stephen Warren wrote: > >> > On 04/16/2018 09:56 AM, Stefan Agner wrote: > >> >> On

Re: [PATCH v2 3/6] ARM: trusted_foundations: do not use naked function

On Thu, Jul 12, 2018 at 03:43:10PM -0700, Kees Cook wrote: > On Tue, Apr 17, 2018 at 1:11 AM, Thierry Reding wrote: > > On Mon, Apr 16, 2018 at 08:21:09PM +0200, Stefan Agner wrote: > >> On 16.04.2018 18:08, Stephen Warren wrote: > >> > On 04/16/2018 09:56 AM, Stefan Agner wrote: > >> >> On

Re: [PATCH v2 3/6] ARM: trusted_foundations: do not use naked function

On Sun, Mar 25, 2018 at 08:09:56PM +0200, Stefan Agner wrote: > As documented in GCC naked functions should only use Basic asm > syntax. The Extended asm or mixture of Basic asm and "C" code is > not guaranteed. Currently this works because it was hard coded > to follow and check GCC behavior for

Re: [PATCH v2 3/6] ARM: trusted_foundations: do not use naked function

On Sun, Mar 25, 2018 at 08:09:56PM +0200, Stefan Agner wrote: > As documented in GCC naked functions should only use Basic asm > syntax. The Extended asm or mixture of Basic asm and "C" code is > not guaranteed. Currently this works because it was hard coded > to follow and check GCC behavior for

Re: [RFC PATCH for 4.18 3/5] rseq: uapi: declare rseq_cs field as union, update includes

On Fri, Jul 06, 2018 at 12:56:58PM -0700, Linus Torvalds wrote: > On Fri, Jul 6, 2018 at 12:38 PM Mathieu Desnoyers > wrote: > > > > Should I change all 4 bytes __get_user()/__put_user() in kernel/rseq.c > > for get_user()/put_user() to ensure consistency ? > > Probably. > > *If* this actually

Re: [RFC PATCH for 4.18 3/5] rseq: uapi: declare rseq_cs field as union, update includes

On Fri, Jul 06, 2018 at 12:56:58PM -0700, Linus Torvalds wrote: > On Fri, Jul 6, 2018 at 12:38 PM Mathieu Desnoyers > wrote: > > > > Should I change all 4 bytes __get_user()/__put_user() in kernel/rseq.c > > for get_user()/put_user() to ensure consistency ? > > Probably. > > *If* this actually

Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes

On Fri, Jul 06, 2018 at 07:33:14PM +0300, Dmitry Osipenko wrote: > On Friday, 6 July 2018 18:40:27 MSK Russell King - ARM Linux wrote: > > On Fri, Jul 06, 2018 at 05:58:50PM +0300, Dmitry Osipenko wrote: > > > On Friday, 6 July 2018 17:10:10 MSK Ville Syrjälä wrote: > >

Re: [RFC PATCH v3 1/2] drm: Add generic colorkey properties for DRM planes

On Fri, Jul 06, 2018 at 07:33:14PM +0300, Dmitry Osipenko wrote: > On Friday, 6 July 2018 18:40:27 MSK Russell King - ARM Linux wrote: > > On Fri, Jul 06, 2018 at 05:58:50PM +0300, Dmitry Osipenko wrote: > > > On Friday, 6 July 2018 17:10:10 MSK Ville Syrjälä wrote: > >

Re: [PATCH] ARM: module: fix modsign build error

On Fri, Jul 06, 2018 at 02:48:47PM +0200, Arnd Bergmann wrote: > The asm/module.h header file can not be included standalone, which > breaks the module signing code after a recent change: > > In file included from kernel/module-internal.h:13, > from kernel/module_signing.c:17: >

Re: [PATCH] ARM: module: fix modsign build error

On Fri, Jul 06, 2018 at 02:48:47PM +0200, Arnd Bergmann wrote: > The asm/module.h header file can not be included standalone, which > breaks the module signing code after a recent change: > > In file included from kernel/module-internal.h:13, > from kernel/module_signing.c:17: >

Re: [PATCH] [RFC] arm: Replace "multiple platforms" by "common platform"

On Fri, Jun 22, 2018 at 01:41:37PM +0200, Geert Uytterhoeven wrote: > Hi Russell, > > Thanks for your comments! > > On Fri, Jun 22, 2018 at 11:23 AM Russell King - ARM Linux > wrote: > > On Thu, Jun 21, 2018 at 05:59:06PM +0200, Geert Uytterhoeven wrote: > > >

Re: [PATCH] [RFC] arm: Replace "multiple platforms" by "common platform"

On Fri, Jun 22, 2018 at 01:41:37PM +0200, Geert Uytterhoeven wrote: > Hi Russell, > > Thanks for your comments! > > On Fri, Jun 22, 2018 at 11:23 AM Russell King - ARM Linux > wrote: > > On Thu, Jun 21, 2018 at 05:59:06PM +0200, Geert Uytterhoeven wrote: > > >

Re: [PATCH] [RFC] arm: Replace "multiple platforms" by "common platform"

On Thu, Jun 21, 2018 at 05:59:06PM +0200, Geert Uytterhoeven wrote: > "ARM multiplatform" has actually two meanings: >   1. It groups platforms that follow the "ARM multiplatform" software > framework, >   2. It allows to build a single kernel that can be booted on multiple >      platforms.

Re: [PATCH] [RFC] arm: Replace "multiple platforms" by "common platform"

On Thu, Jun 21, 2018 at 05:59:06PM +0200, Geert Uytterhoeven wrote: > "ARM multiplatform" has actually two meanings: >   1. It groups platforms that follow the "ARM multiplatform" software > framework, >   2. It allows to build a single kernel that can be booted on multiple >      platforms.

Re: [RFC PATCH] ARM: Use logical or instead of addition for badr address calculation

On Tue, Jun 19, 2018 at 10:14:24AM -0700, Guenter Roeck wrote: > On Tue, Jun 19, 2018 at 04:12:35PM +0100, Russell King - ARM Linux wrote: > > > > So, I'm going to continue sitting on the fence on this, and basically > > take the attitude that it's better that peo

Re: [RFC PATCH] ARM: Use logical or instead of addition for badr address calculation

On Tue, Jun 19, 2018 at 10:14:24AM -0700, Guenter Roeck wrote: > On Tue, Jun 19, 2018 at 04:12:35PM +0100, Russell King - ARM Linux wrote: > > > > So, I'm going to continue sitting on the fence on this, and basically > > take the attitude that it's better that peo

Re: [RFC PATCH] ARM: Use logical or instead of addition for badr address calculation

On Tue, Jun 19, 2018 at 03:35:07PM +0200, Ard Biesheuvel wrote: > On 19 June 2018 at 15:29, Guenter Roeck wrote: > > Hi Ard, > > > > > > On 06/19/2018 12:48 AM, Ard Biesheuvel wrote: > >> > >> On 19 June 2018 at 07:07, Guenter Roeck wrote: > >>> > >>> Modern assemblers may take the ISA into

Re: [RFC PATCH] ARM: Use logical or instead of addition for badr address calculation

On Tue, Jun 19, 2018 at 03:35:07PM +0200, Ard Biesheuvel wrote: > On 19 June 2018 at 15:29, Guenter Roeck wrote: > > Hi Ard, > > > > > > On 06/19/2018 12:48 AM, Ard Biesheuvel wrote: > >> > >> On 19 June 2018 at 07:07, Guenter Roeck wrote: > >>> > >>> Modern assemblers may take the ISA into

Re: [PATCH] ARM: DRA7/OMAP5: Enable ACTLR[0] (Enable invalidates of BTB) for secondary cores

On Tue, Jun 12, 2018 at 04:36:11PM -0500, Nishanth Menon wrote: > Call secure services to enable ACTLR[0] (Enable invalidates of BTB with > ICIALLU) when branch hardening is enabled for kernel. As mentioned elsewhere, I don't think this is a good idea - if the secure world is not implementing the

Re: [PATCH] ARM: DRA7/OMAP5: Enable ACTLR[0] (Enable invalidates of BTB) for secondary cores

On Tue, Jun 12, 2018 at 04:36:11PM -0500, Nishanth Menon wrote: > Call secure services to enable ACTLR[0] (Enable invalidates of BTB with > ICIALLU) when branch hardening is enabled for kernel. As mentioned elsewhere, I don't think this is a good idea - if the secure world is not implementing the

Re: [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available

On Tue, May 29, 2018 at 04:41:20PM +0100, Will Deacon wrote: > Hi Russell, > > On Tue, May 29, 2018 at 04:33:24PM +0100, Russell King - ARM Linux wrote: > > On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote: > > > Hi Arnd, Russell, [+Nico and Robin] > >

Re: [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available

On Tue, May 29, 2018 at 04:41:20PM +0100, Will Deacon wrote: > Hi Russell, > > On Tue, May 29, 2018 at 04:33:24PM +0100, Russell King - ARM Linux wrote: > > On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote: > > > Hi Arnd, Russell, [+Nico and Robin] > >

Re: [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available

On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote: > Hi Arnd, Russell, [+Nico and Robin] > > On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote: > > Now that the ARM CCI PMU driver can be built as a loadable module, > > we get a link failure when MCPM is enabled: > > > >

Re: [PATCH] ARM: mcpm, perf/arm-cci: export mcpm_is_available

On Tue, May 29, 2018 at 04:30:14PM +0100, Will Deacon wrote: > Hi Arnd, Russell, [+Nico and Robin] > > On Mon, May 28, 2018 at 05:44:36PM +0200, Arnd Bergmann wrote: > > Now that the ARM CCI PMU driver can be built as a loadable module, > > we get a link failure when MCPM is enabled: > > > >

Re: [PATCH] ARM; fix cpu_v7_bugs_init reference

On Tue, May 29, 2018 at 12:46:00PM +0200, Arnd Bergmann wrote: > On Tue, May 29, 2018 at 12:25 PM, Russell King - ARM Linux > wrote: > > Please revalidate against the latest patches, this area has changed. > > Ok. I assume they will be in tomorrow's linux-next kernel

Re: [PATCH] ARM; fix cpu_v7_bugs_init reference

On Tue, May 29, 2018 at 12:46:00PM +0200, Arnd Bergmann wrote: > On Tue, May 29, 2018 at 12:25 PM, Russell King - ARM Linux > wrote: > > Please revalidate against the latest patches, this area has changed. > > Ok. I assume they will be in tomorrow's linux-next kernel

Re: [PATCH] ARM; fix cpu_v7_bugs_init reference

Please revalidate against the latest patches, this area has changed. On Tue, May 29, 2018 at 12:22:06PM +0200, Arnd Bergmann wrote: > The cpu_v7_bugs_init() function is referenced by the ARMv7 processor > implementation, but is defined conditionally, leading to a link error when >

Re: [PATCH] ARM; fix cpu_v7_bugs_init reference

Please revalidate against the latest patches, this area has changed. On Tue, May 29, 2018 at 12:22:06PM +0200, Arnd Bergmann wrote: > The cpu_v7_bugs_init() function is referenced by the ARMv7 processor > implementation, but is defined conditionally, leading to a link error when >

Re: uImage target support on arm64

On Thu, May 24, 2018 at 11:17:19PM +0300, Ramon Fried wrote: > On Thu, May 24, 2018 at 10:34 PM, Baruch Siach wrote: > > Hi Ramon, > > > > On Thu, May 24, 2018 at 10:05:15PM +0300, Ramon Fried wrote: > >> I've noticed that it's not supported. > >> Is it on purpose ? > > > >

Re: uImage target support on arm64

On Thu, May 24, 2018 at 11:17:19PM +0300, Ramon Fried wrote: > On Thu, May 24, 2018 at 10:34 PM, Baruch Siach wrote: > > Hi Ramon, > > > > On Thu, May 24, 2018 at 10:05:15PM +0300, Ramon Fried wrote: > >> I've noticed that it's not supported. > >> Is it on purpose ? > > > > Yes. The 32bit load

Re: [PATCH] cpufreq: Add Kryo CPU scaling driver

On Wed, May 23, 2018 at 12:05:24PM +0300, Ilia Lin wrote: > + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev); > + if (IS_ERR(np)) > + return PTR_ERR(np); ... > + > + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0); > + if (!IS_ERR(pdev)) Do you need to

Re: [PATCH] cpufreq: Add Kryo CPU scaling driver

On Wed, May 23, 2018 at 12:05:24PM +0300, Ilia Lin wrote: > + np = dev_pm_opp_of_get_opp_desc_node(cpu_dev); > + if (IS_ERR(np)) > + return PTR_ERR(np); ... > + > + pdev = platform_device_register_simple("cpufreq-dt", -1, NULL, 0); > + if (!IS_ERR(pdev)) Do you need to

Re: [PATCH] cpufreq: Add Kryo CPU scaling driver

On Mon, May 21, 2018 at 03:35:07PM +0300, ilia...@codeaurora.org wrote: > There are 2 CPU clusters in the Kryo, CPU 0 and 1 are called Silver Cluster > and CPU 2 and 3 - Gold Cluster. Each cluster has single clock. The clusters > differ in terms of speed capabilities, computing power and power >

Re: [PATCH] cpufreq: Add Kryo CPU scaling driver

On Mon, May 21, 2018 at 03:35:07PM +0300, ilia...@codeaurora.org wrote: > There are 2 CPU clusters in the Kryo, CPU 0 and 1 are called Silver Cluster > and CPU 2 and 3 - Gold Cluster. Each cluster has single clock. The clusters > differ in terms of speed capabilities, computing power and power >

Re: [PATCH] cpufreq: Add Kryo CPU scaling driver

On Mon, May 21, 2018 at 02:05:41PM +0300, ilia...@codeaurora.org wrote: > You are right. > cpu_dev_silver != cpu_dev_gold, and I found this with my tests as well. > Thank you. > > > -Original Message- > > From: Russell King - ARM Linux <li...@armlinux.org.u

Re: [PATCH] cpufreq: Add Kryo CPU scaling driver

On Mon, May 21, 2018 at 02:05:41PM +0300, ilia...@codeaurora.org wrote: > You are right. > cpu_dev_silver != cpu_dev_gold, and I found this with my tests as well. > Thank you. > > > -Original Message- > > From: Russell King - ARM Linux > > Sent: Monday, M

Re: [PATCH] cpufreq: Add Kryo CPU scaling driver

On Mon, May 21, 2018 at 01:31:30PM +0300, Ilia Lin wrote: > +#define SILVER_LEAD 0 > +#define GOLD_LEAD2 Okay, two different values here, but "GOLD_LEAD" appears unused. > + cpu_dev_silver = get_cpu_device(SILVER_LEAD); > + if (NULL == cpu_dev_silver) > + return -ENODEV;

Re: [PATCH] cpufreq: Add Kryo CPU scaling driver

On Mon, May 21, 2018 at 01:31:30PM +0300, Ilia Lin wrote: > +#define SILVER_LEAD 0 > +#define GOLD_LEAD2 Okay, two different values here, but "GOLD_LEAD" appears unused. > + cpu_dev_silver = get_cpu_device(SILVER_LEAD); > + if (NULL == cpu_dev_silver) > + return -ENODEV;

Re: [PATCH v1 1/5] ARM: trusted_foundations: Implement L2 cache initialization callback

On Sun, May 20, 2018 at 01:15:38PM +0300, Dmitry Osipenko wrote: > Implement L2 cache initialization firmware callback that should be invoked > early in boot to enable cache HW. > > Signed-off-by: Dmitry Osipenko > --- > arch/arm/firmware/trusted_foundations.c | 23

Re: [PATCH v1 1/5] ARM: trusted_foundations: Implement L2 cache initialization callback

On Sun, May 20, 2018 at 01:15:38PM +0300, Dmitry Osipenko wrote: > Implement L2 cache initialization firmware callback that should be invoked > early in boot to enable cache HW. > > Signed-off-by: Dmitry Osipenko > --- > arch/arm/firmware/trusted_foundations.c | 23 +++ > 1

Re: [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver

On Sat, May 19, 2018 at 02:09:24PM +0300, ilia...@codeaurora.org wrote: > +static int __init qcom_cpufreq_kryo_driver_init(void) > +{ > + struct device *cpu_dev_silver, *cpu_dev_gold; > + struct opp_table *opp_silver, *opp_gold; > + enum _msm8996_version msm8996_version; > +

Re: [PATCH v8 10/15] cpufreq: Add Kryo CPU scaling driver

On Sat, May 19, 2018 at 02:09:24PM +0300, ilia...@codeaurora.org wrote: > +static int __init qcom_cpufreq_kryo_driver_init(void) > +{ > + struct device *cpu_dev_silver, *cpu_dev_gold; > + struct opp_table *opp_silver, *opp_gold; > + enum _msm8996_version msm8996_version; > +

Re: [PATCHv2] drm/i2c: tda998x: Remove VLA usage

On Fri, May 18, 2018 at 11:01:55AM -0700, Kees Cook wrote: > On Tue, Apr 10, 2018 at 6:03 PM, Laura Abbott wrote: > > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > > turn on -Wvla. The vla in reg_write_range is based on the length of data > >

Re: [PATCHv2] drm/i2c: tda998x: Remove VLA usage

On Fri, May 18, 2018 at 11:01:55AM -0700, Kees Cook wrote: > On Tue, Apr 10, 2018 at 6:03 PM, Laura Abbott wrote: > > There's an ongoing effort to remove VLAs[1] from the kernel to eventually > > turn on -Wvla. The vla in reg_write_range is based on the length of data > > passed. The one use of a

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 01:35:08PM -0700, Vineet Gupta wrote: > On 05/18/2018 10:50 AM, Russell King - ARM Linux wrote: > >On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: > >>I never understood the need for this direction. And if memory serves me > >>right

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 01:35:08PM -0700, Vineet Gupta wrote: > On 05/18/2018 10:50 AM, Russell King - ARM Linux wrote: > >On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: > >>I never understood the need for this direction. And if memory serves me > >>right

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 07:57:34PM +, Alexey Brodkin wrote: > Hi Russel, That's Russell. > On Fri, 2018-05-18 at 18:50 +0100, Russell King - ARM Linux wrote: > > It's necessary. Take a moment to think carefully about this: > > > >

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 07:57:34PM +, Alexey Brodkin wrote: > Hi Russel, That's Russell. > On Fri, 2018-05-18 at 18:50 +0100, Russell King - ARM Linux wrote: > > It's necessary. Take a moment to think carefully about this: > > > >

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: > I never understood the need for this direction. And if memory serves me > right, at that time I was seeing twice the amount of cache flushing ! It's necessary. Take a moment to think carefully about this: dma_map_single(,

Re: dma_sync_*_for_cpu and direction=TO_DEVICE (was Re: [PATCH 02/20] dma-mapping: provide a generic dma-noncoherent implementation)

On Fri, May 18, 2018 at 10:20:02AM -0700, Vineet Gupta wrote: > I never understood the need for this direction. And if memory serves me > right, at that time I was seeing twice the amount of cache flushing ! It's necessary. Take a moment to think carefully about this: dma_map_single(,

Re: [PATCH net-next 1/2] net: phy: sfp: make the i2c-bus property really optional

On Thu, May 17, 2018 at 03:04:06PM +0200, Andrew Lunn wrote: > On Thu, May 17, 2018 at 02:56:48PM +0200, Antoine Tenart wrote: > > Hi Andrew, > > > > On Thu, May 17, 2018 at 02:41:28PM +0200, Andrew Lunn wrote: > > > On Thu, May 17, 2018 at 10:29:06AM +0200, Antoine Tenart wrote: > > > > The

Re: [PATCH net-next 1/2] net: phy: sfp: make the i2c-bus property really optional

On Thu, May 17, 2018 at 03:04:06PM +0200, Andrew Lunn wrote: > On Thu, May 17, 2018 at 02:56:48PM +0200, Antoine Tenart wrote: > > Hi Andrew, > > > > On Thu, May 17, 2018 at 02:41:28PM +0200, Andrew Lunn wrote: > > > On Thu, May 17, 2018 at 10:29:06AM +0200, Antoine Tenart wrote: > > > > The

Re: [PATCH net-next 1/2] net: phy: sfp: make the i2c-bus property really optional

On Thu, May 17, 2018 at 02:41:28PM +0200, Andrew Lunn wrote: > On Thu, May 17, 2018 at 10:29:06AM +0200, Antoine Tenart wrote: > > The SFF,SFP documentation is clear about making all the DT properties, > > with the exception of the compatible, optional. In practice this is not > > the case and

Re: [PATCH net-next 1/2] net: phy: sfp: make the i2c-bus property really optional

On Thu, May 17, 2018 at 02:41:28PM +0200, Andrew Lunn wrote: > On Thu, May 17, 2018 at 10:29:06AM +0200, Antoine Tenart wrote: > > The SFF,SFP documentation is clear about making all the DT properties, > > with the exception of the compatible, optional. In practice this is not > > the case and

Re: [PATCH net-next v3 00/10] net: mvpp2: phylink conversion

On Thu, May 17, 2018 at 10:29:29AM +0200, Antoine Tenart wrote: > Since v2: > - Removed the SFP description from the DB boards, as their SFP cages > are wired properly. We now use fixed-link. I think you mean "improperly" here. -- RMK's Patch system:

Re: [PATCH net-next v3 00/10] net: mvpp2: phylink conversion

On Thu, May 17, 2018 at 10:29:29AM +0200, Antoine Tenart wrote: > Since v2: > - Removed the SFP description from the DB boards, as their SFP cages > are wired properly. We now use fixed-link. I think you mean "improperly" here. -- RMK's Patch system:

Re: [PATCH 1/4] amba: Export amba_bustype

On Wed, May 16, 2018 at 12:16:28PM +0300, Andy Shevchenko wrote: > On Tue, May 8, 2018 at 10:06 PM, Kim Phillips wrote: > > This patch is provided in the context of allowing the Coresight driver > > subsystem to be loaded as modules. Coresight uses amba_bus in its call > >

Re: [PATCH 1/4] amba: Export amba_bustype

On Wed, May 16, 2018 at 12:16:28PM +0300, Andy Shevchenko wrote: > On Tue, May 8, 2018 at 10:06 PM, Kim Phillips wrote: > > This patch is provided in the context of allowing the Coresight driver > > subsystem to be loaded as modules. Coresight uses amba_bus in its call > > to bus_find_device()

Re: [PATCH 1/4] amba: Export amba_bustype

On Tue, May 15, 2018 at 08:15:19AM -0500, Kim Phillips wrote: > On Tue, 15 May 2018 08:59:02 +0200 > Ulf Hansson wrote: > > > On 8 May 2018 at 21:06, Kim Phillips wrote: > > > This patch is provided in the context of allowing the Coresight driver >

Re: [PATCH 1/4] amba: Export amba_bustype

On Tue, May 15, 2018 at 08:15:19AM -0500, Kim Phillips wrote: > On Tue, 15 May 2018 08:59:02 +0200 > Ulf Hansson wrote: > > > On 8 May 2018 at 21:06, Kim Phillips wrote: > > > This patch is provided in the context of allowing the Coresight driver > > > subsystem to be loaded as modules.

Re: [PATCH 1/4] amba: Export amba_bustype

On Tue, May 15, 2018 at 08:59:02AM +0200, Ulf Hansson wrote: > On 8 May 2018 at 21:06, Kim Phillips wrote: > > This patch is provided in the context of allowing the Coresight driver > > subsystem to be loaded as modules. Coresight uses amba_bus in its call > > to

Re: [PATCH 1/4] amba: Export amba_bustype

On Tue, May 15, 2018 at 08:59:02AM +0200, Ulf Hansson wrote: > On 8 May 2018 at 21:06, Kim Phillips wrote: > > This patch is provided in the context of allowing the Coresight driver > > subsystem to be loaded as modules. Coresight uses amba_bus in its call > > to bus_find_device() in

Re: Difference between IOVA and bus address when SMMU is enabled

On Sat, May 12, 2018 at 06:25:13PM +0530, valmiki wrote: > Hi All, > > What is the difference between IOVA address and bus address > when SMMU is enabled ? > > Is IOVA address term used only when hypervisor is present ? IOVA = IO virtual address. IOVA is the term normally used to describe the

Re: Difference between IOVA and bus address when SMMU is enabled

On Sat, May 12, 2018 at 06:25:13PM +0530, valmiki wrote: > Hi All, > > What is the difference between IOVA address and bus address > when SMMU is enabled ? > > Is IOVA address term used only when hypervisor is present ? IOVA = IO virtual address. IOVA is the term normally used to describe the

Re: [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions

ed to end up in mainline before they can go anywhere near stable trees as per stable tree rules. For more information on stable trees and their rules, please see: Documentation/process/stable-kernel-rules.rst > > Thank you, > > On Tue, 8 May 2018 12:25:03 +0100 > Russ

Re: [BUGFIX PATCH v3 0/4] arm: kprobes: Fix to prohibit probing on unsafe functions

ed to end up in mainline before they can go anywhere near stable trees as per stable tree rules. For more information on stable trees and their rules, please see: Documentation/process/stable-kernel-rules.rst > > Thank you, > > On Tue, 8 May 2018 12:25:03 +0100 > Russell

Re: Delivery Status Notification (Failure)

On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote: > Hi, > > I need one help. > I am using i.MX7 Sabre board with kernel version 4.1.15 > > Let's say I am interested in GPIO number: 21 > I wanted to set CPU affinity for particular GPIO->IRQ number, so I > tried the below steps: >

Re: Delivery Status Notification (Failure)

On Fri, May 11, 2018 at 05:07:37PM +0530, Pintu Kumar wrote: > Hi, > > I need one help. > I am using i.MX7 Sabre board with kernel version 4.1.15 > > Let's say I am interested in GPIO number: 21 > I wanted to set CPU affinity for particular GPIO->IRQ number, so I > tried the below steps: >

Re: [PATCH v2] gpu: drm: armada: Adding new typedef vm_fault_t

On Thu, May 10, 2018 at 08:34:48PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler in > struct vm_operations_struct. For now, this is just > documenting that the function returns a VM_FAULT > value rather than an errno. Once all instances are > converted,

Re: [PATCH v2] gpu: drm: armada: Adding new typedef vm_fault_t

On Thu, May 10, 2018 at 08:34:48PM +0530, Souptick Joarder wrote: > Use new return type vm_fault_t for fault handler in > struct vm_operations_struct. For now, this is just > documenting that the function returns a VM_FAULT > value rather than an errno. Once all instances are > converted,

Re: [PATCH 04/20] arm-nommu: use generic dma_noncoherent_ops

On Fri, May 11, 2018 at 09:59:29AM +0200, Christoph Hellwig wrote: > Switch to the generic noncoherent direct mapping implementation for > the nommu dma map implementation. > > Signed-off-by: Christoph Hellwig > --- > arch/arc/Kconfig| 1 + > arch/arm/Kconfig

Re: [PATCH 04/20] arm-nommu: use generic dma_noncoherent_ops

On Fri, May 11, 2018 at 09:59:29AM +0200, Christoph Hellwig wrote: > Switch to the generic noncoherent direct mapping implementation for > the nommu dma map implementation. > > Signed-off-by: Christoph Hellwig > --- > arch/arc/Kconfig| 1 + > arch/arm/Kconfig|

Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules

On Thu, May 10, 2018 at 01:39:18PM -0600, Mathieu Poirier wrote: > Hi Russell, > > On 10 May 2018 at 02:40, Russell King - ARM Linux <li...@armlinux.org.uk> > wrote: > > This does not leak information from other namespaces because of the > > uniqueness of the glob

Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules

On Thu, May 10, 2018 at 01:39:18PM -0600, Mathieu Poirier wrote: > Hi Russell, > > On 10 May 2018 at 02:40, Russell King - ARM Linux > wrote: > > This does not leak information from other namespaces because of the > > uniqueness of the global PID. However, what i

Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules

On Wed, May 09, 2018 at 09:35:07PM -0500, Eric W. Biederman wrote: > Mathieu Poirier writes: > > > On Tue, May 08, 2018 at 11:59:38PM -0500, Eric W. Biederman wrote: > >> Kim Phillips writes: > >> > >> > This patch is in the context of allowing

Re: [PATCH 2/4] pid: Export find_task_by_vpid for use in external modules

On Wed, May 09, 2018 at 09:35:07PM -0500, Eric W. Biederman wrote: > Mathieu Poirier writes: > > > On Tue, May 08, 2018 at 11:59:38PM -0500, Eric W. Biederman wrote: > >> Kim Phillips writes: > >> > >> > This patch is in the context of allowing the Coresight h/w > >> > trace driver suite to be

Re: [PATCH] bpf, arm32: Correct check_imm24

On Thu, May 10, 2018 at 11:20:13AM +0800, Wang YanQing wrote: > imm24 is signed, so the right range is: > [-(2<<(24 - 1)), (2<<(24 - 1)) - 1] 2 << (24 - 1) is the same as 1 << 24. > -#define check_imm(bits, imm) do {\ > - if imm) > 0) && ((imm) >> (bits))) ||

Re: [PATCH] bpf, arm32: Correct check_imm24

On Thu, May 10, 2018 at 11:20:13AM +0800, Wang YanQing wrote: > imm24 is signed, so the right range is: > [-(2<<(24 - 1)), (2<<(24 - 1)) - 1] 2 << (24 - 1) is the same as 1 << 24. > -#define check_imm(bits, imm) do {\ > - if imm) > 0) && ((imm) >> (bits))) ||

Re: [PATCH v2 2/4] ARM: amba: Fix race condition with driver_override

On Thu, Apr 26, 2018 at 10:45:49AM +0200, Geert Uytterhoeven wrote: > Hi Greg, > > On Thu, Apr 26, 2018 at 10:35 AM, Greg Kroah-Hartman > wrote: > > On Thu, Apr 26, 2018 at 09:40:08AM +0200, Geert Uytterhoeven wrote: > >> On Thu, Apr 26, 2018 at 9:04 AM, Greg

Re: [PATCH v2 2/4] ARM: amba: Fix race condition with driver_override

On Thu, Apr 26, 2018 at 10:45:49AM +0200, Geert Uytterhoeven wrote: > Hi Greg, > > On Thu, Apr 26, 2018 at 10:35 AM, Greg Kroah-Hartman > wrote: > > On Thu, Apr 26, 2018 at 09:40:08AM +0200, Geert Uytterhoeven wrote: > >> On Thu, Apr 26, 2018 at 9:04 AM, Greg Kroah-Hartman > >> wrote: > >> > On

Re: [PATCH v6 2/6] ARM: imx6: register pm_power_off handler if "fsl,pmic-stby-poweroff" is set

On Wed, May 09, 2018 at 07:06:28AM +0200, Oleksij Rempel wrote: > On Tue, May 08, 2018 at 01:40:33PM +0100, Russell King - ARM Linux wrote: > > On Mon, Mar 05, 2018 at 11:25:19AM +0100, Oleksij Rempel wrote: > > > One of the Freescale recommended sequences for power off with e

<    6   7   8   9   10   11   12   13   14   15   >