[PATCH] arm64: dts: rockchip: add mipi_dsi1 support for rk3399

From: Nickey Yang This patch adds the information for the secondary MIPI DSI controller, e.g., interrupts, grf, clocks, ports and so on. Mirrors the existing definition for dsi0. Signed-off-by: Nickey Yang Signed-off-by: Brian Norris

[PATCH] arm64: dts: rockchip: add mipi_dsi1 support for rk3399

From: Nickey Yang This patch adds the information for the secondary MIPI DSI controller, e.g., interrupts, grf, clocks, ports and so on. Mirrors the existing definition for dsi0. Signed-off-by: Nickey Yang Signed-off-by: Brian Norris --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 45

RE: [Patch v13 0/4] This patchset is to remove PPCisms for QEIC

Hi Thomas and Marc, Is there any feedback? Thank you! Best Regards Qiang Zhao > -Original Message- > From: Zhao Qiang [mailto:qiang.z...@nxp.com] > Sent: Friday, November 10, 2017 11:31 AM > To: t...@linutronix.de; marc.zyng...@arm.com; ja...@lakedaemon.net > Cc:

RE: [Patch v13 0/4] This patchset is to remove PPCisms for QEIC

Hi Thomas and Marc, Is there any feedback? Thank you! Best Regards Qiang Zhao > -Original Message- > From: Zhao Qiang [mailto:qiang.z...@nxp.com] > Sent: Friday, November 10, 2017 11:31 AM > To: t...@linutronix.de; marc.zyng...@arm.com; ja...@lakedaemon.net > Cc:

Re: [PATCH] arm64: dts: rockchip: add rk3399 DSI0 reset

On Wed, Nov 29, 2017 at 05:07:27PM -0800, Brian Norris wrote: Sorry, I got the wrong $subject, will resend :(

Re: [PATCH] arm64: dts: rockchip: add rk3399 DSI0 reset

On Wed, Nov 29, 2017 at 05:07:27PM -0800, Brian Norris wrote: Sorry, I got the wrong $subject, will resend :(

[PATCH] arm64: dts: rockchip: add rk3399 DSI0 reset

From: Nickey Yang This patch adds the information for the secondary MIPI DSI controller, e.g., interrupts, grf, clocks, ports and so on. Mirrors the existing definition for dsi0. Signed-off-by: Nickey Yang Signed-off-by: Brian Norris

[PATCH] arm64: dts: rockchip: add rk3399 DSI0 reset

From: Nickey Yang This patch adds the information for the secondary MIPI DSI controller, e.g., interrupts, grf, clocks, ports and so on. Mirrors the existing definition for dsi0. Signed-off-by: Nickey Yang Signed-off-by: Brian Norris --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 45

Re: [RFC PATCH v2 0/8] Introduct cpu idle prediction functionality

Hi, Thanks Rafael's comments against V2. I'd like to ping here to see which direction this proposal should go and what fundamental change this proposal should make. I'm also open to any suggestions if my proposal is not on the right way. Thanks, -Aubrey On 2017/9/30 15:20, Aubrey Li wrote: >

Re: [RFC PATCH v2 0/8] Introduct cpu idle prediction functionality

Hi, Thanks Rafael's comments against V2. I'd like to ping here to see which direction this proposal should go and what fundamental change this proposal should make. I'm also open to any suggestions if my proposal is not on the right way. Thanks, -Aubrey On 2017/9/30 15:20, Aubrey Li wrote: >

mmotm 2017-11-29-16-58 uploaded

The mm-of-the-moment snapshot 2017-11-29-16-58 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

mmotm 2017-11-29-16-58 uploaded

The mm-of-the-moment snapshot 2017-11-29-16-58 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You

add_wait_queue() (unintentional?) behavior change in v4.13

Hi, Ingo, Commit 50816c48997a ("sched/wait: Standardize internal naming of wait-queue entries") changed the behavior of add_wait_queue() from inserting the wait entry at the head of the wait queue to the tail of the wait queue. This is the relevant hunk: -void add_wait_queue(wait_queue_head_t

Re: [RFC 0/2] of: Add whitelist

On 11/29/17 04:20, Frank Rowand wrote: > On 11/27/17 15:58, Alan Tull wrote: >> Here's a proposal for a whitelist to lock down the dynamic device tree. >> >> For an overlay to be accepted, all of its targets are required to be >> on a target node whitelist. >> >> Currently the only way I have to

add_wait_queue() (unintentional?) behavior change in v4.13

Hi, Ingo, Commit 50816c48997a ("sched/wait: Standardize internal naming of wait-queue entries") changed the behavior of add_wait_queue() from inserting the wait entry at the head of the wait queue to the tail of the wait queue. This is the relevant hunk: -void add_wait_queue(wait_queue_head_t

Re: [RFC 0/2] of: Add whitelist

On 11/29/17 04:20, Frank Rowand wrote: > On 11/27/17 15:58, Alan Tull wrote: >> Here's a proposal for a whitelist to lock down the dynamic device tree. >> >> For an overlay to be accepted, all of its targets are required to be >> on a target node whitelist. >> >> Currently the only way I have to

Re: [PATCH v18 01/10] idr: add #include

On Wed, Nov 29, 2017 at 09:55:17PM +0800, Wei Wang wrote: > The was removed from radix-tree.h by the following commit: > f5bba9d11a256ad2a1c2f8e7fc6aabe6416b7890. > > Since that commit, tools/testing/radix-tree/ couldn't pass compilation > due to: tools/testing/radix-tree/idr.c:17: undefined

Re: [PATCH v18 01/10] idr: add #include

On Wed, Nov 29, 2017 at 09:55:17PM +0800, Wei Wang wrote: > The was removed from radix-tree.h by the following commit: > f5bba9d11a256ad2a1c2f8e7fc6aabe6416b7890. > > Since that commit, tools/testing/radix-tree/ couldn't pass compilation > due to: tools/testing/radix-tree/idr.c:17: undefined

RE: [PATCH 0/4] hv_balloon: fixes for num_pages_onlined accounting and misc improvements

> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Tuesday, November 28, 2017 8:30 AM > To: Alex Ng ; KY Srinivasan > Cc: linux-kernel@vger.kernel.org; Haiyang Zhang ; > Stephen Hemminger

RE: [PATCH 0/4] hv_balloon: fixes for num_pages_onlined accounting and misc improvements

> -Original Message- > From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com] > Sent: Tuesday, November 28, 2017 8:30 AM > To: Alex Ng ; KY Srinivasan > Cc: linux-kernel@vger.kernel.org; Haiyang Zhang ; > Stephen Hemminger ; Dexuan Cui > ; de...@linuxdriverproject.org > Subject: Re: [PATCH

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

Hello, On Wed, Nov 29, 2017 at 09:17:34AM -0500, Waiman Long wrote: > The list_lru_del() function removes the given item from the LRU list. > The operation looks simple, but it involves writing into the cachelines > of the two neighboring list entries in order to get the deletion done. > That can

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

Hello, On Wed, Nov 29, 2017 at 09:17:34AM -0500, Waiman Long wrote: > The list_lru_del() function removes the given item from the LRU list. > The operation looks simple, but it involves writing into the cachelines > of the two neighboring list entries in order to get the deletion done. > That can

Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

On 11/28, Ulf Hansson wrote: > On 2 November 2017 at 10:00, Viresh Kumar wrote: > > On 02-11-17, 00:15, Stephen Boyd wrote: > >> Sorry I'm not following. We're going to need to have platform > >> specific code that understands platform specific bindings that > >> aren't

Re: [RFC V7 2/2] OPP: Allow "opp-hz" and "opp-microvolt" to contain magic values

On 11/28, Ulf Hansson wrote: > On 2 November 2017 at 10:00, Viresh Kumar wrote: > > On 02-11-17, 00:15, Stephen Boyd wrote: > >> Sorry I'm not following. We're going to need to have platform > >> specific code that understands platform specific bindings that > >> aren't shoved into the generic

[ANNOUNCE] 4.9.65-rt56

Dear RT Folks, I'm pleased to announce the 4.9.65-rt56 stable release. This release is just an update to the new stable 4.9.65 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 4.4.102-rt116

Dear RT Folks, I'm pleased to announce the 4.4.102-rt116 stable release. This release is just an update to the new stable 4.4.102 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 4.9.65-rt56

Dear RT Folks, I'm pleased to announce the 4.9.65-rt56 stable release. This release is just an update to the new stable 4.9.65 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 4.4.102-rt116

Dear RT Folks, I'm pleased to announce the 4.4.102-rt116 stable release. This release is just an update to the new stable 4.4.102 version and no RT specific changes have been made. You can get this release via the git tree at:

Re: Very Early boot time stamps support

Pavel Tatashin a écrit : Hi Abderrahmane, I'm implementing a feature in ftrace to enable very early function tracing, I'm using tsc when x86_tsc feature is available, but it seems that you did similar work in your patch "[PATCH v9 0/6] Early boot time stamps for

Re: Very Early boot time stamps support

Pavel Tatashin a écrit : Hi Abderrahmane, I'm implementing a feature in ftrace to enable very early function tracing, I'm using tsc when x86_tsc feature is available, but it seems that you did similar work in your patch "[PATCH v9 0/6] Early boot time stamps for x86". I need to record

Re: WARNING: suspicious RCU usage (3)

On Tue, Nov 28, 2017 at 09:06:06PM -0800, Eric Biggers wrote: > On Tue, Nov 28, 2017 at 01:30:26PM -0800, Andrew Morton wrote: > > > > It looks like blkcipher_walk_done() passed a bad address to kfree(). > > > > Indeed, it's freeing uninitialized memory because the Salsa20 algorithms are >

Re: WARNING: suspicious RCU usage (3)

On Tue, Nov 28, 2017 at 09:06:06PM -0800, Eric Biggers wrote: > On Tue, Nov 28, 2017 at 01:30:26PM -0800, Andrew Morton wrote: > > > > It looks like blkcipher_walk_done() passed a bad address to kfree(). > > > > Indeed, it's freeing uninitialized memory because the Salsa20 algorithms are >

[PATCH v3 3/6] ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept parameters

This commit extend the ts72xx_register_flash() to accept passed parameters, which makes it more reusable. Now it is possible to accept ep93xx flash start address and partitions. Signed-off-by: Lukasz Majewski Acked-by: Alexander Sverdlin --- Changes

[PATCH v3 3/6] ARM: ep93xx: ts72xx: Rewrite ts72xx_register_flash() to accept parameters

This commit extend the ts72xx_register_flash() to accept passed parameters, which makes it more reusable. Now it is possible to accept ep93xx flash start address and partitions. Signed-off-by: Lukasz Majewski Acked-by: Alexander Sverdlin --- Changes for v2: - New patch Changes for v3: - None

Re: [PATCH v4 6/6] ARM: configs: Add missing config for DART-MX6 SoM

On Wed, Nov 29, 2017 at 11:20:57AM +0100, Neil Armstrong wrote: > This patch adds the missing configs for the DART-MX6 SoM support : > - SERDEV bluetooth driver + SERIAL_DEV_BUS configs > - WL18XX driver > - DEFAULT_ON Led Trigger > > Reviewed-by: Fabio Estevam >

Re: [PATCH v4 6/6] ARM: configs: Add missing config for DART-MX6 SoM

On Wed, Nov 29, 2017 at 11:20:57AM +0100, Neil Armstrong wrote: > This patch adds the missing configs for the DART-MX6 SoM support : > - SERDEV bluetooth driver + SERIAL_DEV_BUS configs > - WL18XX driver > - DEFAULT_ON Led Trigger > > Reviewed-by: Fabio Estevam > Signed-off-by: Neil Armstrong

[PATCH v3 2/6] ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file

This commit adds include file guards to ts72xx.h Signed-off-by: Lukasz Majewski Acked-by: Alexander Sverdlin --- Changes for v2: - None Changes for v3: - None --- arch/arm/mach-ep93xx/ts72xx.h | 4 1 file changed, 4 insertions(+) diff --git

[PATCH v3 0/6] ARM: ep93xx: ts72xx: Add support for BK3 board

This patch series adds support for Liebherr's BK3 board, being a derivative of TS72XX design. This patchset consists of following patches: - ts72xx.[c|h] cosmetic cleanup/improvement - Rewrite ts72xx.c to be reusable by bk3 - The Liebherr's BK3 board has been added with re-using code of

[PATCH v3 2/6] ARM: ep93xx: ts72xx: Provide include guards for ts72xx.h file

This commit adds include file guards to ts72xx.h Signed-off-by: Lukasz Majewski Acked-by: Alexander Sverdlin --- Changes for v2: - None Changes for v3: - None --- arch/arm/mach-ep93xx/ts72xx.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-ep93xx/ts72xx.h

[PATCH v3 0/6] ARM: ep93xx: ts72xx: Add support for BK3 board

This patch series adds support for Liebherr's BK3 board, being a derivative of TS72XX design. This patchset consists of following patches: - ts72xx.[c|h] cosmetic cleanup/improvement - Rewrite ts72xx.c to be reusable by bk3 - The Liebherr's BK3 board has been added with re-using code of

[PATCH v3 1/6] ARM: ep93xx: ts72xx: Use DEFINE_RES_MEM macros where applicable

This commit cleans up the code by using dedicated macros instead of full definitions. Signed-off-by: Lukasz Majewski Acked-by: Alexander Sverdlin --- Changes for v2: - None Changes for v3: - None --- arch/arm/mach-ep93xx/ts72xx.c | 18

[PATCH v3 1/6] ARM: ep93xx: ts72xx: Use DEFINE_RES_MEM macros where applicable

This commit cleans up the code by using dedicated macros instead of full definitions. Signed-off-by: Lukasz Majewski Acked-by: Alexander Sverdlin --- Changes for v2: - None Changes for v3: - None --- arch/arm/mach-ep93xx/ts72xx.c | 18 +++--- 1 file changed, 3 insertions(+), 15

[PATCH v3 4/6] ARM: ep93xx: ts72xx: Rewrite map IO code to be reusable

The map IO common code has been excluded to be reused by other ts72xx clones. Signed-off-by: Lukasz Majewski Acked-by: Alexander Sverdlin --- Changes for v2: - New patch Changes for v3: - None --- arch/arm/mach-ep93xx/ts72xx.c | 23

[PATCH v3 6/6] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative

The BK3 board is a derivative of the ts72xx reference design. Signed-off-by: Lukasz Majewski --- Changes for v2: - Place bk3 support code to the ts72xx.c file Changes for v3: - Add SD card support (via SPI) for BK3 - Remove definition of apb:i2s bus - Remove board registration of

[PATCH v3 5/6] ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code

This patch extends readability of ts72xx.c code. Signed-off-by: Lukasz Majewski --- Changes for v2: - New patch --- arch/arm/mach-ep93xx/ts72xx.c | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c index

[PATCH v3 4/6] ARM: ep93xx: ts72xx: Rewrite map IO code to be reusable

The map IO common code has been excluded to be reused by other ts72xx clones. Signed-off-by: Lukasz Majewski Acked-by: Alexander Sverdlin --- Changes for v2: - New patch Changes for v3: - None --- arch/arm/mach-ep93xx/ts72xx.c | 23 --- 1 file changed, 16 insertions(+), 7

[PATCH v3 6/6] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative

The BK3 board is a derivative of the ts72xx reference design. Signed-off-by: Lukasz Majewski --- Changes for v2: - Place bk3 support code to the ts72xx.c file Changes for v3: - Add SD card support (via SPI) for BK3 - Remove definition of apb:i2s bus - Remove board registration of CPLD WDT

[PATCH v3 5/6] ARM: ep93xx: ts72xx: cosmetic: Add some description to ts72xx code

This patch extends readability of ts72xx.c code. Signed-off-by: Lukasz Majewski --- Changes for v2: - New patch --- arch/arm/mach-ep93xx/ts72xx.c | 12 1 file changed, 12 insertions(+) diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c index

Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.

Hi, On Thu, Nov 16, 2017 at 6:11 AM, Enric Balletbo i Serra wrote: > When you want to change the brightness using a PWM signal, one thing you > need to consider is how human perceive the brightness. Human perceive the > brightness change non-linearly, we have better

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 2:14 PM, Linus Torvalds wrote: > On Wed, Nov 29, 2017 at 1:17 PM, Kees Cook wrote: >> 1) Add request_module_cap(required_cap, module_name_prefix, fmt, fmt_args...) >> >> 2) Convert known

Re: [RFC v2 2/2] backlight: pwm_bl: compute brightness of LED linearly to human eye.

Hi, On Thu, Nov 16, 2017 at 6:11 AM, Enric Balletbo i Serra wrote: > When you want to change the brightness using a PWM signal, one thing you > need to consider is how human perceive the brightness. Human perceive the > brightness change non-linearly, we have better sensitivity at low >

Re: [kernel-hardening] Re: [PATCH v5 next 5/5] net: modules: use request_module_cap() to load 'netdev-%s' modules

On Wed, Nov 29, 2017 at 2:14 PM, Linus Torvalds wrote: > On Wed, Nov 29, 2017 at 1:17 PM, Kees Cook wrote: >> 1) Add request_module_cap(required_cap, module_name_prefix, fmt, fmt_args...) >> >> 2) Convert known privileged-but-not-CAP_SYS_MODULE request_module() >> callers to

Re: [PATCH v4 5/6] ARM: dts: imx6q: Add Variscite DART-MX6 Carrier-board support

On Wed, Nov 29, 2017 at 11:20:56AM +0100, Neil Armstrong wrote: > This patch adds support for the i.MX6 Quad variant of the Variscite DART-MX6 > SoM Carrier-Board. > > This Carrier-Board has the following : > - LVDS interface for the VLCD-CAP-GLD-LVDS 7" LCD 800 x 480 touch display > - HDMI

Re: [PATCH v4 5/6] ARM: dts: imx6q: Add Variscite DART-MX6 Carrier-board support

On Wed, Nov 29, 2017 at 11:20:56AM +0100, Neil Armstrong wrote: > This patch adds support for the i.MX6 Quad variant of the Variscite DART-MX6 > SoM Carrier-Board. > > This Carrier-Board has the following : > - LVDS interface for the VLCD-CAP-GLD-LVDS 7" LCD 800 x 480 touch display > - HDMI

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

On Wed, Nov 29, 2017 at 01:53:19PM -0800, Andrew Morton wrote: > On Wed, 29 Nov 2017 09:17:34 -0500 Waiman Long wrote: > > > The list_lru_del() function removes the given item from the LRU list. > > The operation looks simple, but it involves writing into the cachelines > >

Re: [PATCH] list_lru: Prefetch neighboring list entries before acquiring lock

On Wed, Nov 29, 2017 at 01:53:19PM -0800, Andrew Morton wrote: > On Wed, 29 Nov 2017 09:17:34 -0500 Waiman Long wrote: > > > The list_lru_del() function removes the given item from the LRU list. > > The operation looks simple, but it involves writing into the cachelines > > of the two

Re: [PATCH v4 4/6] ARM: dts: imx6qdl: Add Variscite DART-MX6 SoM support

On Wed, Nov 29, 2017 at 11:20:55AM +0100, Neil Armstrong wrote: > This patch adds support for the Variscite DART-MX6 SoM with : > - i.MX6 Quad or Dual Lite SoC > - 1Gb/2Gb LPDDR2 > - 4-64 GB eMMC > - Camera Interface > - HDMI+CEC interface > - LVDS / DSI / Parallel RGB interfaces > - Ethernet

Re: [PATCH v4 4/6] ARM: dts: imx6qdl: Add Variscite DART-MX6 SoM support

On Wed, Nov 29, 2017 at 11:20:55AM +0100, Neil Armstrong wrote: > This patch adds support for the Variscite DART-MX6 SoM with : > - i.MX6 Quad or Dual Lite SoC > - 1Gb/2Gb LPDDR2 > - 4-64 GB eMMC > - Camera Interface > - HDMI+CEC interface > - LVDS / DSI / Parallel RGB interfaces > - Ethernet

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Wed, Nov 29, 2017 at 11:28:52AM -0600, Serge E. Hallyn wrote: > > Just to be clear, module loading requires - and must always continue to > require - CAP_SYS_MODULE against the initial user namespace. Containers > in user namespaces do not have that. > > I don't believe anyone has ever

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Wed, Nov 29, 2017 at 11:28:52AM -0600, Serge E. Hallyn wrote: > > Just to be clear, module loading requires - and must always continue to > require - CAP_SYS_MODULE against the initial user namespace. Containers > in user namespaces do not have that. > > I don't believe anyone has ever

linux-next: build warning after merge of the mfd tree

Hi Lee, After merging the mfd tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/leds/leds-pm8058.c: In function 'pm8058_led_probe': drivers/leds/leds-pm8058.c:109:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] led->ledtype

linux-next: build warning after merge of the mfd tree

Hi Lee, After merging the mfd tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/leds/leds-pm8058.c: In function 'pm8058_led_probe': drivers/leds/leds-pm8058.c:109:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] led->ledtype

Re: [PATCH 1/7] kbuild: add ld-name macro and support for GNU gold

On Wed, Nov 29, 2017 at 3:44 PM, Sami Tolvanen wrote: > GNU gold may require different flags than GNU ld. Add a macro for > detecting the linker and conditionally add gold specific flags from > LDFLAGS_GOLD. Right, but you're still only ever using one linker per build,

Re: [PATCH 1/7] kbuild: add ld-name macro and support for GNU gold

On Wed, Nov 29, 2017 at 3:44 PM, Sami Tolvanen wrote: > GNU gold may require different flags than GNU ld. Add a macro for > detecting the linker and conditionally add gold specific flags from > LDFLAGS_GOLD. Right, but you're still only ever using one linker per build, correct? Can we get away

Re: [PATCH 6/7] arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold

On Wed, Nov 29, 2017 at 3:44 PM, Sami Tolvanen wrote: > @@ -26,10 +26,19 @@ ifeq ($(CONFIG_ARM64_ERRATUM_843419),y) >ifeq ($(call ld-option, --fix-cortex-a53-843419),) > $(warning ld does not support --fix-cortex-a53-843419; kernel may be > susceptible to erratum) >

Re: [PATCH 6/7] arm64: explicitly pass --no-fix-cortex-a53-843419 to GNU gold

On Wed, Nov 29, 2017 at 3:44 PM, Sami Tolvanen wrote: > @@ -26,10 +26,19 @@ ifeq ($(CONFIG_ARM64_ERRATUM_843419),y) >ifeq ($(call ld-option, --fix-cortex-a53-843419),) > $(warning ld does not support --fix-cortex-a53-843419; kernel may be > susceptible to erratum) >else > +ifeq

Re: [v2] arm: dts: ls1021a: fix the value of TMR_FIPER1

On Wed, Nov 29, 2017 at 02:54:58PM +0800, Yangbo Lu wrote: > The timer fixed interval period pulse generator register > is used to generate periodic pulses. The down count > register loads the value programmed in the fixed period > interval (FIPER). At every tick of the timer accumulator >

Re: [v2] arm: dts: ls1021a: fix the value of TMR_FIPER1

On Wed, Nov 29, 2017 at 02:54:58PM +0800, Yangbo Lu wrote: > The timer fixed interval period pulse generator register > is used to generate periodic pulses. The down count > register loads the value programmed in the fixed period > interval (FIPER). At every tick of the timer accumulator >

Re: [PATCH] mm: Make count list_lru_one::nr_items lockless

On Fri, Sep 29, 2017 at 1:15 AM, Kirill Tkhai wrote: > On 29.09.2017 00:02, Andrew Morton wrote: >> On Thu, 28 Sep 2017 10:48:55 +0300 Kirill Tkhai wrote: >> > This patch aims to make super_cache_count() (and other functions, > which count LRU

Re: [PATCH] mm: Make count list_lru_one::nr_items lockless

On Fri, Sep 29, 2017 at 1:15 AM, Kirill Tkhai wrote: > On 29.09.2017 00:02, Andrew Morton wrote: >> On Thu, 28 Sep 2017 10:48:55 +0300 Kirill Tkhai wrote: >> > This patch aims to make super_cache_count() (and other functions, > which count LRU nr_items) more effective. > It allows

Re: [PATCH v2 6/6] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative

On Wed, 29 Nov 2017 23:07:04 +0100 Lukasz Majewski wrote: > Hi Alexander, > > > Hello Lukasz, > > > > some nitpicking below... > > > > On 21/11/17 15:32, Lukasz Majewski wrote: > > > The BK3 board is a derivative of the ts72xx reference design. > > > > > > Signed-off-by:

Re: [PATCH v2 6/6] ARM: ep93xx: ts72xx: Add support for BK3 board - ts72xx derivative

On Wed, 29 Nov 2017 23:07:04 +0100 Lukasz Majewski wrote: > Hi Alexander, > > > Hello Lukasz, > > > > some nitpicking below... > > > > On 21/11/17 15:32, Lukasz Majewski wrote: > > > The BK3 board is a derivative of the ts72xx reference design. > > > > > > Signed-off-by: Lukasz Majewski >

Re: Very Early boot time stamps support

Hi Abderrahmane, > I'm implementing a feature in ftrace to enable very early function tracing, > I'm using tsc when x86_tsc feature is available, but it seems that you did > similar work in your patch "[PATCH v9 0/6] Early boot time stamps for x86". > > I need to record timestamps at the start of

Re: Very Early boot time stamps support

Hi Abderrahmane, > I'm implementing a feature in ftrace to enable very early function tracing, > I'm using tsc when x86_tsc feature is available, but it seems that you did > similar work in your patch "[PATCH v9 0/6] Early boot time stamps for x86". > > I need to record timestamps at the start of

[RFC] bpf: offload: report device information for offloaded programs

Report to the user ifindex and namespace information of offloaded programs. Always set dev_bound to true if program was loaded for a device which has been since removed. Specify the namespace using dev/inode combination. Signed-off-by: Jakub Kicinski Reviewed-by:

[RFC] bpf: offload: report device information for offloaded programs

Report to the user ifindex and namespace information of offloaded programs. Always set dev_bound to true if program was loaded for a device which has been since removed. Specify the namespace using dev/inode combination. Signed-off-by: Jakub Kicinski Reviewed-by: Simon Horman Reviewed-by:

Re: [PATCH 05/11] fs: add iterate_supers_excl() and iterate_supers_reverse_excl()

On Thu, Nov 30, 2017 at 12:48:15AM +0100, Rafael J. Wysocki wrote: > On Thu, Nov 30, 2017 at 12:23 AM, Luis R. Rodriguez wrote: > > +int iterate_supers_excl(int (*f)(struct super_block *, void *), void *arg) > > +{ > > + struct super_block *sb, *p = NULL; > > + int

Re: [PATCH 05/11] fs: add iterate_supers_excl() and iterate_supers_reverse_excl()

On Thu, Nov 30, 2017 at 12:48:15AM +0100, Rafael J. Wysocki wrote: > On Thu, Nov 30, 2017 at 12:23 AM, Luis R. Rodriguez wrote: > > +int iterate_supers_excl(int (*f)(struct super_block *, void *), void *arg) > > +{ > > + struct super_block *sb, *p = NULL; > > + int error = 0; > > + >

Re: [PATCH] x86/syscalls: Mark expected switch fall-throughs

On Wed, Nov 29, 2017 at 7:14 AM, Thomas Gleixner wrote: > On Wed, 29 Nov 2017, Gustavo A. R. Silva wrote: >> Quoting Thomas Gleixner : >> >> > >> > So I have to ask WHY this information was not in the changelog of the patch >> > in question: >> > >> > 1)

Re: [PATCH] x86/syscalls: Mark expected switch fall-throughs

On Wed, Nov 29, 2017 at 7:14 AM, Thomas Gleixner wrote: > On Wed, 29 Nov 2017, Gustavo A. R. Silva wrote: >> Quoting Thomas Gleixner : >> >> > >> > So I have to ask WHY this information was not in the changelog of the patch >> > in question: >> > >> > 1) How it works >> > >> > 2) Why comments

Re: [PATCH v3 00/11] perf stat: Enable '--per-thread' on all thread

On 11/29/2017 11:16 PM, Jiri Olsa wrote: On Wed, Nov 29, 2017 at 08:05:47PM +0800, Jin Yao wrote: v3: --- Update according to Jiri's comments. The major modifications are: 1. Fix the crash issue when performing the git bisect. Move the removing of runtime_saved_values to the switching

Re: [PATCH v3 00/11] perf stat: Enable '--per-thread' on all thread

On 11/29/2017 11:16 PM, Jiri Olsa wrote: On Wed, Nov 29, 2017 at 08:05:47PM +0800, Jin Yao wrote: v3: --- Update according to Jiri's comments. The major modifications are: 1. Fix the crash issue when performing the git bisect. Move the removing of runtime_saved_values to the switching

Re: [RFC 1/3] kallsyms: don't leak address when symbol not found

I reordered the To's and CC's, I hope this doesn't break threading. (clearly I haven't groked email yet :( ) On Tue, Nov 28, 2017 at 09:30:17AM +1100, Tobin C. Harding wrote: > Currently if kallsyms_lookup() fails to find the symbol then the address > is printed. This potentially leaks sensitive

Re: [RFC 1/3] kallsyms: don't leak address when symbol not found

I reordered the To's and CC's, I hope this doesn't break threading. (clearly I haven't groked email yet :( ) On Tue, Nov 28, 2017 at 09:30:17AM +1100, Tobin C. Harding wrote: > Currently if kallsyms_lookup() fails to find the symbol then the address > is printed. This potentially leaks sensitive

RE: [PATCH] sched/deadline: fix one-bit signed bitfields to be unsigned

> -Original Message- > From: Jakub Kicinski [mailto:kubak...@wp.pl] > Sent: Tuesday, November 28, 2017 8:08 PM > To: Kirsher, Jeffrey T > Cc: mi...@redhat.com; pet...@infradead.org; Keller, Jacob E > ; linux-kernel@vger.kernel.org; >

RE: [PATCH] sched/deadline: fix one-bit signed bitfields to be unsigned

> -Original Message- > From: Jakub Kicinski [mailto:kubak...@wp.pl] > Sent: Tuesday, November 28, 2017 8:08 PM > To: Kirsher, Jeffrey T > Cc: mi...@redhat.com; pet...@infradead.org; Keller, Jacob E > ; linux-kernel@vger.kernel.org; > net...@vger.kernel.org; nhor...@redhat.com;

Re: [PATCH 0/2] userns: automount cleanups

On 30/11/17 08:01, Eric W. Biederman wrote: > > While reviewing some code I realized that in getting d_automount working > with s_user_ns I had left behind some unnecessary relics of the blind > path I started down. Here are two patches that remove those relics. > > Unless someone has another

Re: [PATCH 0/2] userns: automount cleanups

On 30/11/17 08:01, Eric W. Biederman wrote: > > While reviewing some code I realized that in getting d_automount working > with s_user_ns I had left behind some unnecessary relics of the blind > path I started down. Here are two patches that remove those relics. > > Unless someone has another

[RFC 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox

Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block in ZynqMP SoC used for the communication between various processor systems. Signed-off-by: Wendy Liang --- .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 113 + 1 file changed, 113

[RFC 2/2] dt-bindings: mailbox: Add Xilinx IPI Mailbox

Xilinx ZynqMP IPI(Inter Processor Interrupt) is a hardware block in ZynqMP SoC used for the communication between various processor systems. Signed-off-by: Wendy Liang --- .../bindings/mailbox/xlnx,zynqmp-ipi-mailbox.txt | 113 + 1 file changed, 113 insertions(+) create

[RFC 0/2] Xilinx ZynqMP IPI Mailbox Controller Driver

Introduce mailbox controller driver for ZynqMP IPI(Inter-processor interrupt) IP core. There is previous discussion on the DT bindings: https://patchwork.kernel.org/patch/10012755/ Wendy Liang (2): mailbox: ZynqMP IPI mailbox controller dt-bindings: mailbox: Add Xilinx IPI Mailbox

[RFC 0/2] Xilinx ZynqMP IPI Mailbox Controller Driver

Introduce mailbox controller driver for ZynqMP IPI(Inter-processor interrupt) IP core. There is previous discussion on the DT bindings: https://patchwork.kernel.org/patch/10012755/ Wendy Liang (2): mailbox: ZynqMP IPI mailbox controller dt-bindings: mailbox: Add Xilinx IPI Mailbox

[RFC 1/2] mailbox: ZynqMP IPI mailbox controller

This patch is to introduce ZynqMP IPI mailbox controller driver to use the ZynqMP IPI block as mailboxes. Signed-off-by: Wendy Liang --- drivers/mailbox/Kconfig| 8 + drivers/mailbox/Makefile | 2 +

[RFC 1/2] mailbox: ZynqMP IPI mailbox controller

This patch is to introduce ZynqMP IPI mailbox controller driver to use the ZynqMP IPI block as mailboxes. Signed-off-by: Wendy Liang --- drivers/mailbox/Kconfig| 8 + drivers/mailbox/Makefile | 2 + drivers/mailbox/zynqmp-ipi-mailbox.c | 633

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Wed, Nov 29, 2017 at 2:45 PM, Linus Torvalds wrote: > On Wed, Nov 29, 2017 at 7:58 AM, David Miller wrote: >> >> We're talking about making sure that loading "ppp.ko" really gets >> ppp.ko rather than some_other_module.ko renamed to ppp.ko

Re: [PATCH v5 next 1/5] modules:capabilities: add request_module_cap()

On Wed, Nov 29, 2017 at 2:45 PM, Linus Torvalds wrote: > On Wed, Nov 29, 2017 at 7:58 AM, David Miller wrote: >> >> We're talking about making sure that loading "ppp.ko" really gets >> ppp.ko rather than some_other_module.ko renamed to ppp.ko via some >> other mechanism. >> >> Both modules have

[PATCH 1/2] userns: Don't fail follow_automount based on s_user_ns

When vfs_submount was added the test to limit automounts from filesystems that with s_user_ns != _user_ns accidentially left in follow_automount. The test was never about any security concerns and was always about how do we implement this for filesystems whose s_user_ns != _user_ns. At the

[PATCH 1/2] userns: Don't fail follow_automount based on s_user_ns

When vfs_submount was added the test to limit automounts from filesystems that with s_user_ns != _user_ns accidentially left in follow_automount. The test was never about any security concerns and was always about how do we implement this for filesystems whose s_user_ns != _user_ns. At the

[PATCH 2/2] autofs4: Modify autofs_wait to use current_uid() and current_gid()

The code used to do that and then I mucked with it and never quite put the code back. Today the code references current_cred()->uid and current_cred()->gid which is equivalent but more wordy, and not idiomatic. Fixes: 93faccbbfa95 ("fs: Better permission checking for submounts") Fixes:

[PATCH 2/2] autofs4: Modify autofs_wait to use current_uid() and current_gid()

The code used to do that and then I mucked with it and never quite put the code back. Today the code references current_cred()->uid and current_cred()->gid which is equivalent but more wordy, and not idiomatic. Fixes: 93faccbbfa95 ("fs: Better permission checking for submounts") Fixes:

<    1   2   3   4   5   6   7   8   9   10   >