Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

On Wed, Mar 01, 2017 at 01:28:43PM +0100, Peter Zijlstra wrote: > On Wed, Mar 01, 2017 at 02:43:23PM +0900, Byungchul Park wrote: > > It's an optimization, but very essential and important optimization. Since its not for correctness, please put it in a separate patch with a good Changelog, the

Re: [PATCH v5 06/13] lockdep: Implement crossrelease feature

On Wed, Mar 01, 2017 at 01:28:43PM +0100, Peter Zijlstra wrote: > On Wed, Mar 01, 2017 at 02:43:23PM +0900, Byungchul Park wrote: > > It's an optimization, but very essential and important optimization. Since its not for correctness, please put it in a separate patch with a good Changelog, the

Re: [RFC PATCH v2 19/32] crypto: ccp: Introduce the AMD Secure Processor device

On Thu, Mar 02, 2017 at 10:16:15AM -0500, Brijesh Singh wrote: > The CCP device is part of the AMD Secure Processor. In order to expand the > usage of the AMD Secure Processor, create a framework that allows functional > components of the AMD Secure Processor to be initialized and handled >

Re: [RFC PATCH v2 19/32] crypto: ccp: Introduce the AMD Secure Processor device

On Thu, Mar 02, 2017 at 10:16:15AM -0500, Brijesh Singh wrote: > The CCP device is part of the AMD Secure Processor. In order to expand the > usage of the AMD Secure Processor, create a framework that allows functional > components of the AMD Secure Processor to be initialized and handled >

[PATCH 06/11] drm/meson: Add support for HDMI venc modes and settings

This patch adds support for the supported HDMI Venc modes and add the VPP mux value to switch to ENCP encoder. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_venc.c | 1245 +++- drivers/gpu/drm/meson/meson_venc.h |7 +

[PATCH 06/11] drm/meson: Add support for HDMI venc modes and settings

This patch adds support for the supported HDMI Venc modes and add the VPP mux value to switch to ENCP encoder. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_venc.c | 1245 +++- drivers/gpu/drm/meson/meson_venc.h |7 +

[PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with KASAN

Enabling CONFIG_KASAN can lead to an instant stack overflow: drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_generic_mmio_info': drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 30464 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

[PATCH 22/26] drm/i915/gvt: don't overflow the kernel stack with KASAN

Enabling CONFIG_KASAN can lead to an instant stack overflow: drivers/gpu/drm/i915/gvt/handlers.c: In function 'init_generic_mmio_info': drivers/gpu/drm/i915/gvt/handlers.c:2200:1: error: the frame size of 30464 bytes is larger than 3072 bytes [-Werror=frame-larger-than=]

Re: [PATCH 2/2] arc: axs10x: Fix ARC PGU default clock frequency

Hi Jose, On Wed, 2017-02-22 at 18:19 +, Jose Abreu wrote: > Default clock frequency for ARC PGU does not match any > existing HDMI mode, instead the default value matches a > DVI mode. Change the clock frequency to 74.25MHz so that > it matches HDMI mode 1280x720@60Hz > > Signed-off-by: Jose

Re: [PATCH 2/2] arc: axs10x: Fix ARC PGU default clock frequency

Hi Jose, On Wed, 2017-02-22 at 18:19 +, Jose Abreu wrote: > Default clock frequency for ARC PGU does not match any > existing HDMI mode, instead the default value matches a > DVI mode. Change the clock frequency to 74.25MHz so that > it matches HDMI mode 1280x720@60Hz > > Signed-off-by: Jose

Re: [Outreachy kernel] [PATCH 1/6] staging: wlan-ng: Fix sparse warning of restricted __le16

On Thu, Mar 02, 2017 at 12:14:40PM +0100, Julia Lawall wrote: > > > On Thu, 2 Mar 2017, SIMRAN SINGHAL wrote: > > > On Thu, Mar 2, 2017 at 3:20 PM, Julia Lawall wrote: > > > > > > > > > On Thu, 2 Mar 2017, Julia Lawall wrote: > > > > > >> > > >> > > >> On Thu, 2 Mar 2017,

Re: [Outreachy kernel] [PATCH 1/6] staging: wlan-ng: Fix sparse warning of restricted __le16

On Thu, Mar 02, 2017 at 12:14:40PM +0100, Julia Lawall wrote: > > > On Thu, 2 Mar 2017, SIMRAN SINGHAL wrote: > > > On Thu, Mar 2, 2017 at 3:20 PM, Julia Lawall wrote: > > > > > > > > > On Thu, 2 Mar 2017, Julia Lawall wrote: > > > > > >> > > >> > > >> On Thu, 2 Mar 2017, simran singhal wrote:

Re: [PATCH 0/6] cpufreq: schedutil: fixes for flags updates

On 02-Mar 17:09, Vincent Guittot wrote: > On 2 March 2017 at 16:45, Patrick Bellasi wrote: > > The current version of schedutil has some issues related to the management > > of update flags used by systems with frequency domains spawning multiple > > CPUs. > > > > Each

Re: [PATCH 14/20] PCI: hisi: update PCI config space remap function

Hi Gabriele, On Thu, Mar 02, 2017 at 10:56:16AM +, Gabriele Paoloni wrote: > Hi Lorenzo > > Many thanks for putting all of this together. > > > -Original Message- > > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com] > > Sent: 27 February 2017 15:14 > > To:

Re: [PATCH 0/6] cpufreq: schedutil: fixes for flags updates

On 02-Mar 17:09, Vincent Guittot wrote: > On 2 March 2017 at 16:45, Patrick Bellasi wrote: > > The current version of schedutil has some issues related to the management > > of update flags used by systems with frequency domains spawning multiple > > CPUs. > > > > Each time a CPU utilisation

Re: [PATCH 14/20] PCI: hisi: update PCI config space remap function

Hi Gabriele, On Thu, Mar 02, 2017 at 10:56:16AM +, Gabriele Paoloni wrote: > Hi Lorenzo > > Many thanks for putting all of this together. > > > -Original Message- > > From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com] > > Sent: 27 February 2017 15:14 > > To:

[PATCH v9 07/11] btrfs_tree.h: fix include from userland

This patch prepares the uapi export by fixing the following errors: .../linux/btrfs_tree.h:283:2: error: #error "UUID items require BTRFS_UUID_SIZE == 16!" #error "UUID items require BTRFS_UUID_SIZE == 16!" .../linux/btrfs_tree.h:390:12: error: ‘BTRFS_UUID_SIZE’ undeclared here (not in a

[PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check

Since we cannot always generate exactly requested pixel clock there's not much sense in checking requested_clock == clk_round_rate(). In that case for quite some modes we'll be getting -EINVAL and no video output at all. But given there's some tolerance to real pixel clock in TVs/monitors we may

Re: [PATCH v2 2/3] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy

On Wed, Mar 1, 2017 at 12:09 AM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > If the current P-state selection algorithm is set to "performance" > in intel_pstate_set_policy(), the limits may be initialized from > scratch, but only if

[PATCH v9 01/11] h8300: put bitsperlong.h in uapi

This header file is exported, thus move it to uapi. Signed-off-by: Nicolas Dichtel --- arch/h8300/include/asm/bitsperlong.h | 14 -- arch/h8300/include/uapi/asm/bitsperlong.h | 14 ++ 2 files changed, 14 insertions(+), 14 deletions(-)

[PATCH v9 07/11] btrfs_tree.h: fix include from userland

This patch prepares the uapi export by fixing the following errors: .../linux/btrfs_tree.h:283:2: error: #error "UUID items require BTRFS_UUID_SIZE == 16!" #error "UUID items require BTRFS_UUID_SIZE == 16!" .../linux/btrfs_tree.h:390:12: error: ‘BTRFS_UUID_SIZE’ undeclared here (not in a

[PATCH] drm/arcpgu: use .mode_fixup instead of .atomic_check

Since we cannot always generate exactly requested pixel clock there's not much sense in checking requested_clock == clk_round_rate(). In that case for quite some modes we'll be getting -EINVAL and no video output at all. But given there's some tolerance to real pixel clock in TVs/monitors we may

Re: [PATCH v2 2/3] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy

On Wed, Mar 1, 2017 at 12:09 AM, Rafael J. Wysocki wrote: > From: Rafael J. Wysocki > > If the current P-state selection algorithm is set to "performance" > in intel_pstate_set_policy(), the limits may be initialized from > scratch, but only if no_turbo is not set and the maximum frequency >

[PATCH v9 01/11] h8300: put bitsperlong.h in uapi

This header file is exported, thus move it to uapi. Signed-off-by: Nicolas Dichtel --- arch/h8300/include/asm/bitsperlong.h | 14 -- arch/h8300/include/uapi/asm/bitsperlong.h | 14 ++ 2 files changed, 14 insertions(+), 14 deletions(-) delete mode 100644

[PATCH v9 00/11] uapi: export all headers under uapi directories

Patches #1 and #2 are just cleanup: some exported headers were still under a non-uapi directory. Patch #3 is a fix to avoid exporting a file that was not under an uapi directory. After these three patches, all exported headers are under an uapi directory: path #4 stops searching files in non uapi

[PATCH v9 00/11] uapi: export all headers under uapi directories

Patches #1 and #2 are just cleanup: some exported headers were still under a non-uapi directory. Patch #3 is a fix to avoid exporting a file that was not under an uapi directory. After these three patches, all exported headers are under an uapi directory: path #4 stops searching files in non uapi

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On Thu 02-03-17 09:23:15, Brian Foster wrote: > On Thu, Mar 02, 2017 at 02:50:01PM +0100, Michal Hocko wrote: > > On Thu 02-03-17 08:41:58, Brian Foster wrote: > > > On Thu, Mar 02, 2017 at 02:27:55PM +0100, Michal Hocko wrote: > > [...] > > > > I see your argument about being in sync with other

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On Thu 02-03-17 09:23:15, Brian Foster wrote: > On Thu, Mar 02, 2017 at 02:50:01PM +0100, Michal Hocko wrote: > > On Thu 02-03-17 08:41:58, Brian Foster wrote: > > > On Thu, Mar 02, 2017 at 02:27:55PM +0100, Michal Hocko wrote: > > [...] > > > > I see your argument about being in sync with other

[PATCH v9 04/11] Makefile.headersinst: cleanup input files

After the last four patches, all exported headers are under uapi/, thus input-files2 are not needed anymore. The side effect is that input-files1-name is exactly header-y. Note also that input-files3-name is genhdr-y. Signed-off-by: Nicolas Dichtel ---

[PATCH v9 04/11] Makefile.headersinst: cleanup input files

After the last four patches, all exported headers are under uapi/, thus input-files2 are not needed anymore. The side effect is that input-files1-name is exactly header-y. Note also that input-files3-name is genhdr-y. Signed-off-by: Nicolas Dichtel --- scripts/Makefile.headersinst | 34

Re: [RFC 04/11] mm: remove SWAP_MLOCK check for SWAP_SUCCESS in ttu

On 03/02/2017 12:09 PM, Minchan Kim wrote: > If the page is mapped and rescue in ttuo, page_mapcount(page) == 0 cannot Nit: "ttuo" is very cryptic. Please expand it. > be true so page_mapcount check in ttu is enough to return SWAP_SUCCESS. > IOW, SWAP_MLOCK check is redundant so remove it.

Re: [RFC 04/11] mm: remove SWAP_MLOCK check for SWAP_SUCCESS in ttu

On 03/02/2017 12:09 PM, Minchan Kim wrote: > If the page is mapped and rescue in ttuo, page_mapcount(page) == 0 cannot Nit: "ttuo" is very cryptic. Please expand it. > be true so page_mapcount check in ttu is enough to return SWAP_SUCCESS. > IOW, SWAP_MLOCK check is redundant so remove it.

[PATCH v9 11/11] uapi: export all arch specifics directories

This patch removes the need of subdir-y. Now all files/directories under arch//include/uapi/ are exported. The only change for userland is the layout of the command 'make headers_install_all': directories asm- are replaced by arch-/. Those new directories contains all files/directories of the

[PATCH v9 11/11] uapi: export all arch specifics directories

This patch removes the need of subdir-y. Now all files/directories under arch//include/uapi/ are exported. The only change for userland is the layout of the command 'make headers_install_all': directories asm- are replaced by arch-/. Those new directories contains all files/directories of the

Re: [PATCH] clk: core: Copy connection id

On Tue, 2017-02-28 at 00:05 -0800, sb...@codeaurora.org wrote: > On 02/25, Leonard Crestez wrote: > > > > On Fri, 2017-02-24 at 12:44 -0800, Stephen Boyd wrote: > > > > > > On 02/20, Leonard Crestez wrote: > > > > > > > > Some drivers use sprintf to build clk connection id names but > > > > the

Re: [PATCH] clk: core: Copy connection id

On Tue, 2017-02-28 at 00:05 -0800, sb...@codeaurora.org wrote: > On 02/25, Leonard Crestez wrote: > > > > On Fri, 2017-02-24 at 12:44 -0800, Stephen Boyd wrote: > > > > > > On 02/20, Leonard Crestez wrote: > > > > > > > > Some drivers use sprintf to build clk connection id names but > > > > the

[PATCH v9 05/11] Makefile.headersinst: remove destination-y option

This option was added in commit c7bb349e7c25 ("kbuild: introduce destination-y for exported headers") but never used in-tree. Signed-off-by: Nicolas Dichtel Acked-by: Paul Bolle --- Documentation/kbuild/makefiles.txt | 23 ---

[PATCH v9 05/11] Makefile.headersinst: remove destination-y option

This option was added in commit c7bb349e7c25 ("kbuild: introduce destination-y for exported headers") but never used in-tree. Signed-off-by: Nicolas Dichtel Acked-by: Paul Bolle --- Documentation/kbuild/makefiles.txt | 23 --- scripts/Makefile.headersinst | 2 +- 2

[PATCH v9 06/11] uapi: includes linux/types.h before exporting files

Some files will be exported after the next patch. 0-day tests report the following warning/error: ./usr/include/linux/bcache.h:8: include of is preferred over ./usr/include/linux/bcache.h:11: found __[us]{8,16,32,64} type without #include ./usr/include/linux/qrtr.h:8: found __[us]{8,16,32,64}

[PATCH v9 06/11] uapi: includes linux/types.h before exporting files

Some files will be exported after the next patch. 0-day tests report the following warning/error: ./usr/include/linux/bcache.h:8: include of is preferred over ./usr/include/linux/bcache.h:11: found __[us]{8,16,32,64} type without #include ./usr/include/linux/qrtr.h:8: found __[us]{8,16,32,64}

[PATCH] staging: speakup: replace simple_strtoul with kstrtou8

Replace simple_strtoul with kstrtou8. simple_strtoul is marked for obsoletion. Signed-off-by: Marcin Ciupak --- drivers/staging/speakup/varhandlers.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/staging/speakup/varhandlers.c

Re: [PATCH v2 2/3] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy

On Thu, Mar 2, 2017 at 6:18 PM, Rafael J. Wysocki wrote: > On Wed, Mar 1, 2017 at 12:09 AM, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> If the current P-state selection algorithm is set to "performance" >> in

[PATCH] staging: speakup: replace simple_strtoul with kstrtou8

Replace simple_strtoul with kstrtou8. simple_strtoul is marked for obsoletion. Signed-off-by: Marcin Ciupak --- drivers/staging/speakup/varhandlers.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/staging/speakup/varhandlers.c

Re: [PATCH v2 2/3] cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy

On Thu, Mar 2, 2017 at 6:18 PM, Rafael J. Wysocki wrote: > On Wed, Mar 1, 2017 at 12:09 AM, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> If the current P-state selection algorithm is set to "performance" >> in intel_pstate_set_policy(), the limits may be initialized from >>

Re: [tpmdd-devel] [PATCH v2] tpm: Apply a sane minimum adapterlimit value for retransmission.

> >> Hi Enric > >> > >> Maybe you should remember that you need to use smaller transfers? If > >> you don't remember, but use the full size message every time and only > >> drop back on error, the i2c core is going to log rate limited > >> messages. By remembering, there will only be one such

Re: [tpmdd-devel] [PATCH v2] tpm: Apply a sane minimum adapterlimit value for retransmission.

> >> Hi Enric > >> > >> Maybe you should remember that you need to use smaller transfers? If > >> you don't remember, but use the full size message every time and only > >> drop back on error, the i2c core is going to log rate limited > >> messages. By remembering, there will only be one such

[PATCH 10/26] brcmsmac: reindent split functions

In the previous commit I left the indentation alone to help reviewing the patch, this one now runs the three new functions through 'indent -kr -8' with some manual fixups to avoid silliness. No changes other than whitespace are intended here. Signed-off-by: Arnd Bergmann ---

[PATCH 10/26] brcmsmac: reindent split functions

In the previous commit I left the indentation alone to help reviewing the patch, this one now runs the three new functions through 'indent -kr -8' with some manual fixups to avoid silliness. No changes other than whitespace are intended here. Signed-off-by: Arnd Bergmann ---

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu, 2 Mar 2017 15:28:16 +0100 Michal Hocko wrote: > On Thu 02-03-17 14:53:48, Igor Mammedov wrote: > [...] > > When trying to support memory unplug on guest side in RHEL7, > > experience shows otherwise. Simplistic udev rule which onlines > > added block doesn't work in

Re: [RFC PATCH] mm, hotplug: get rid of auto_online_blocks

On Thu, 2 Mar 2017 15:28:16 +0100 Michal Hocko wrote: > On Thu 02-03-17 14:53:48, Igor Mammedov wrote: > [...] > > When trying to support memory unplug on guest side in RHEL7, > > experience shows otherwise. Simplistic udev rule which onlines > > added block doesn't work in case one wants to

[PATCH 11/26] rtlwifi: reduce stack usage for KASAN

When CONFIG_KASAN is set, we use a large amount of stack in the btcoexist code, presumably due to lots of inlining of functions that each add to the kernel stack. net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c:3762:1: error: the frame size of 4032 bytes is larger than 3072 bytes

[PATCH 11/26] rtlwifi: reduce stack usage for KASAN

When CONFIG_KASAN is set, we use a large amount of stack in the btcoexist code, presumably due to lots of inlining of functions that each add to the kernel stack. net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c:3762:1: error: the frame size of 4032 bytes is larger than 3072 bytes

[PATCH 2/4] Staging:wilc1000:wilc_spi: Fixed alignment to match parenthesis

Fixed alignment to match parenthesis. Signed-off-by: Georgios Emmanouil --- drivers/staging/wilc1000/wilc_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/wilc_spi.c b/drivers/staging/wilc1000/wilc_spi.c index

[PATCH 2/4] Staging:wilc1000:wilc_spi: Fixed alignment to match parenthesis

Fixed alignment to match parenthesis. Signed-off-by: Georgios Emmanouil --- drivers/staging/wilc1000/wilc_spi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/wilc_spi.c b/drivers/staging/wilc1000/wilc_spi.c index 6bd4047..b48cb1c8 100644 ---

[PATCH 16/26] [media] i2c: adv7604: mark register access as noinline_for_kasan

When building with KASAN, we get a stack frame size warning about a function that could potentially cause a stack overflow: drivers/media/i2c/adv7604.c: In function 'adv76xx_log_status': drivers/media/i2c/adv7604.c:2615:1: error: the frame size of 3248 bytes is larger than 3072 bytes

[PATCH 16/26] [media] i2c: adv7604: mark register access as noinline_for_kasan

When building with KASAN, we get a stack frame size warning about a function that could potentially cause a stack overflow: drivers/media/i2c/adv7604.c: In function 'adv76xx_log_status': drivers/media/i2c/adv7604.c:2615:1: error: the frame size of 3248 bytes is larger than 3072 bytes

[PATCH 12/26] wl3501_cs: reduce stack size for KASAN

Inlining functions with local variables can lead to excessive stack usage with KASAN: drivers/net/wireless/wl3501_cs.c: In function 'wl3501_rx_interrupt': drivers/net/wireless/wl3501_cs.c:1103:1: error: the frame size of 2232 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] Marking

[PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size

With KASAN and a couple of other patches applied, this driver is one of the few remaining ones that actually use more than 2048 bytes of kernel stack: broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_gainctrl': broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1:

[PATCH 00/26] bring back stack frame warning with KASAN

It took a long while to get this done, but I'm finally ready to send the first half of the KASAN stack size patches that I did in response to the kernelci.org warnings. As before, it's worth mentioning that things are generally worse with gcc-7.0.1 because of the addition of

[PATCH 04/26] tty: kbd: reduce stack size with KASAN

As reported by kernelci, some functions in the VT code use significant amounts of kernel stack when local variables get inlined into the caller multiple times: drivers/tty/vt/keyboard.c: In function 'kbd_keycode': drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is larger

[PATCH 12/26] wl3501_cs: reduce stack size for KASAN

Inlining functions with local variables can lead to excessive stack usage with KASAN: drivers/net/wireless/wl3501_cs.c: In function 'wl3501_rx_interrupt': drivers/net/wireless/wl3501_cs.c:1103:1: error: the frame size of 2232 bytes is larger than 1536 bytes [-Werror=frame-larger-than=] Marking

[PATCH 08/26] brcmsmac: make some local variables 'static const' to reduce stack size

With KASAN and a couple of other patches applied, this driver is one of the few remaining ones that actually use more than 2048 bytes of kernel stack: broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy_gainctrl': broadcom/brcm80211/brcmsmac/phy/phy_n.c:16065:1:

[PATCH 00/26] bring back stack frame warning with KASAN

It took a long while to get this done, but I'm finally ready to send the first half of the KASAN stack size patches that I did in response to the kernelci.org warnings. As before, it's worth mentioning that things are generally worse with gcc-7.0.1 because of the addition of

[PATCH 04/26] tty: kbd: reduce stack size with KASAN

As reported by kernelci, some functions in the VT code use significant amounts of kernel stack when local variables get inlined into the caller multiple times: drivers/tty/vt/keyboard.c: In function 'kbd_keycode': drivers/tty/vt/keyboard.c:1452:1: error: the frame size of 2240 bytes is larger

[PATCH 1/4] Staging:wilc1000:wilc_spi: Fixed comment style to the preferred kernel comment style

Fixed comment style to the preferred kernel comment style. Signed-off-by: Georgios Emmanouil --- drivers/staging/wilc1000/wilc_spi.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/staging/wilc1000/wilc_spi.c

[PATCH 05/26] netlink: mark nla_put_{u8,u16,u32} noinline_for_kasan

When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large stack frames in some functions. This goes unnoticed normally because CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit 3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with

[PATCH 1/4] Staging:wilc1000:wilc_spi: Fixed comment style to the preferred kernel comment style

Fixed comment style to the preferred kernel comment style. Signed-off-by: Georgios Emmanouil --- drivers/staging/wilc1000/wilc_spi.c | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/drivers/staging/wilc1000/wilc_spi.c b/drivers/staging/wilc1000/wilc_spi.c

[PATCH 05/26] netlink: mark nla_put_{u8,u16,u32} noinline_for_kasan

When CONFIG_KASAN is enabled, the "--param asan-stack=1" causes rather large stack frames in some functions. This goes unnoticed normally because CONFIG_FRAME_WARN is disabled with CONFIG_KASAN by default as of commit 3f181b4d8652 ("lib/Kconfig.debug: disable -Wframe-larger-than warnings with

Re: [PATCH 00/11] drm/meson: Initial support for HDMI Output

On Thu, Mar 02, 2017 at 04:39:56PM +0100, Neil Armstrong wrote: > The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller > in combination with a very custom PHY. > > This patchset depends on Laurent Pinchart v4 patchset at [1] and my v2 > patchset at [2] to permit PHY control

Re: [PATCH 00/11] drm/meson: Initial support for HDMI Output

On Thu, Mar 02, 2017 at 04:39:56PM +0100, Neil Armstrong wrote: > The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller > in combination with a very custom PHY. > > This patchset depends on Laurent Pinchart v4 patchset at [1] and my v2 > patchset at [2] to permit PHY control

[PATCH 07/26] brcmsmac: reduce stack size with KASAN

The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an object on the stack, which will each require a redzone with KASAN and lead to possible stack overflow: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':

[PATCH 07/26] brcmsmac: reduce stack size with KASAN

The wlc_phy_table_write_nphy/wlc_phy_table_read_nphy functions always put an object on the stack, which will each require a redzone with KASAN and lead to possible stack overflow: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c: In function 'wlc_phy_workarounds_nphy':

[PATCH 06/26] rocker: mark rocker_tlv_put_* functions as noinline_for_kasan

Inlining these functions creates lots of stack variables when KASAN is enabled, leading to this warning about potential stack overflow: drivers/net/ethernet/rocker/rocker_ofdpa.c: In function 'ofdpa_cmd_flow_tbl_add': drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of

[PATCH 06/26] rocker: mark rocker_tlv_put_* functions as noinline_for_kasan

Inlining these functions creates lots of stack variables when KASAN is enabled, leading to this warning about potential stack overflow: drivers/net/ethernet/rocker/rocker_ofdpa.c: In function 'ofdpa_cmd_flow_tbl_add': drivers/net/ethernet/rocker/rocker_ofdpa.c:621:1: error: the frame size of

[PATCH 03/26] typecheck.h: avoid local variables in typecheck() macro

With KASAN enabled, the typecheck macro leads to some serious stack memory, as seen in the rt2xxx drivers: drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function 'rt2800_init_registers': drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5068:1: error: the frame size of 23768 bytes is larger

[PATCH 03/26] typecheck.h: avoid local variables in typecheck() macro

With KASAN enabled, the typecheck macro leads to some serious stack memory, as seen in the rt2xxx drivers: drivers/net/wireless/ralink/rt2x00/rt2800lib.c: In function 'rt2800_init_registers': drivers/net/wireless/ralink/rt2x00/rt2800lib.c:5068:1: error: the frame size of 23768 bytes is larger

[PATCH 01/26] compiler: introduce noinline_for_kasan annotation

When CONFIG_KASAN is set, we can run into some code that uses incredible amounts of kernel stack: drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame

[PATCH 01/26] compiler: introduce noinline_for_kasan annotation

When CONFIG_KASAN is set, we can run into some code that uses incredible amounts of kernel stack: drivers/staging/dgnc/dgnc_neo.c:1056:1: error: the frame size of 2 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] drivers/media/i2c/cx25840/cx25840-core.c:4960:1: error: the frame

[PATCH 15/26] [media] tuners: i2c: reduce stack usage for tuner_i2c_xfer_*

When CONFIG_KASAN is enabled, we see very large stack usage in some functions, e.g.: drivers/media/tuners/tda8290.c: In function 'tda8290_set_params': drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 3184 bytes is larger than 1024 bytes [-Wframe-larger-than=]

[PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy

The stack consumption in this driver is still relatively high, with one remaining warning if the warning level is lowered to 1536 bytes: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: the frame size of 1880 bytes is larger than 1536 bytes

[PATCH 15/26] [media] tuners: i2c: reduce stack usage for tuner_i2c_xfer_*

When CONFIG_KASAN is enabled, we see very large stack usage in some functions, e.g.: drivers/media/tuners/tda8290.c: In function 'tda8290_set_params': drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 3184 bytes is larger than 1024 bytes [-Wframe-larger-than=]

[PATCH 09/26] brcmsmac: split up wlc_phy_workarounds_nphy

The stack consumption in this driver is still relatively high, with one remaining warning if the warning level is lowered to 1536 bytes: drivers/net/wireless/broadcom/brcm80211/brcmsmac/phy/phy_n.c:17135:1: error: the frame size of 1880 bytes is larger than 1536 bytes

Re: Kernel bio layer is sending bio size more than our block device is capable of handling

Hi Umesh, it's linux-bl...@vger.kernel.org, and the place where all block layer and driver development happens, you can subsribe to it using the same way you subscribed to linux-kernel, just replacing the list name. The latest released vesion at this point is Linux 4.10.

Re: Kernel bio layer is sending bio size more than our block device is capable of handling

Hi Umesh, it's linux-bl...@vger.kernel.org, and the place where all block layer and driver development happens, you can subsribe to it using the same way you subscribed to linux-kernel, just replacing the list name. The latest released vesion at this point is Linux 4.10.

Re: [RFC PATCH v4 19/28] swiotlb: Add warnings for use of bounce buffers with SME

On 17/02/2017 17:51, Tom Lendacky wrote: > > It's meant just to notify the user about the condition. The user could > then decide to use an alternative device that supports a greater DMA > range (I can probably change it to a dev_warn_once() so that a device > is identified). I would be nice

Re: [RFC PATCH v4 19/28] swiotlb: Add warnings for use of bounce buffers with SME

On 17/02/2017 17:51, Tom Lendacky wrote: > > It's meant just to notify the user about the condition. The user could > then decide to use an alternative device that supports a greater DMA > range (I can probably change it to a dev_warn_once() so that a device > is identified). I would be nice

[PATCH 4/4] Staging:wilc1000:wilc_spi: Added blank line after function and modified comment style

Added blank line after function and modified comment style. Signed-off-by: Georgios Emmanouil --- drivers/staging/wilc1000/wilc_spi.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/staging/wilc1000/wilc_spi.c

[PATCH 4/4] Staging:wilc1000:wilc_spi: Added blank line after function and modified comment style

Added blank line after function and modified comment style. Signed-off-by: Georgios Emmanouil --- drivers/staging/wilc1000/wilc_spi.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/staging/wilc1000/wilc_spi.c b/drivers/staging/wilc1000/wilc_spi.c index

Re: [PATCHv2 11/14] module: Use set_memory.h header

+++ Laura Abbott [01/03/17 16:15 -0800]: set_memory_* functions have moved to set_memory.h. Switch to this explicitly. Signed-off-by: Laura Abbott Acked-by: Jessica Yu Thanks, Jessica --- kernel/module.c | 1 + 1 file changed, 1 insertion(+) diff

Re: [PATCHv2 11/14] module: Use set_memory.h header

+++ Laura Abbott [01/03/17 16:15 -0800]: set_memory_* functions have moved to set_memory.h. Switch to this explicitly. Signed-off-by: Laura Abbott Acked-by: Jessica Yu Thanks, Jessica --- kernel/module.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/module.c

[PATCH 20/26] [media] em28xx: split up em28xx_dvb_init to reduce stack size

With CONFIG_KASAN, the init function uses a large amount of kernel stack: drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init': drivers/media/usb/em28xx/em28xx-dvb.c:2069:1: error: the frame size of 4280 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] By splitting

[PATCH 20/26] [media] em28xx: split up em28xx_dvb_init to reduce stack size

With CONFIG_KASAN, the init function uses a large amount of kernel stack: drivers/media/usb/em28xx/em28xx-dvb.c: In function 'em28xx_dvb_init': drivers/media/usb/em28xx/em28xx-dvb.c:2069:1: error: the frame size of 4280 bytes is larger than 3072 bytes [-Werror=frame-larger-than=] By splitting

Re: [Outreachy kernel] [PATCH 1/4] staging: speakup: Placed Logical on the previous line

On Thu, Mar 02, 2017 at 09:05:57PM +0530, Arushi Singhal wrote: > Placed Logical continuations on the previous line as reported by > checkpatch.pl. > > Signed-off-by: Arushi Singhal Hi Arushi, I'm not seeing the patch cover letter for this one. That would be

Re: [Outreachy kernel] [PATCH 1/4] staging: speakup: Placed Logical on the previous line

On Thu, Mar 02, 2017 at 09:05:57PM +0530, Arushi Singhal wrote: > Placed Logical continuations on the previous line as reported by > checkpatch.pl. > > Signed-off-by: Arushi Singhal Hi Arushi, I'm not seeing the patch cover letter for this one. That would be your [PATCH 0/4] and would come

Re: [PATCH V3 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

On Thu, Mar 02, 2017 at 02:22:07PM +0800, Chunyan Zhang wrote: > From: Orson Zhai > > SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum. > > According to regular hierarchy of sprd dts, whale2.dtsi contains SoC > peripherals IP nodes, sc9860.dtsi

[PATCH 04/11] drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available

Since this is managed now by the components code, if CVBS is not available and HDMI neither, the drm driver won't bind anyway. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH V3 1/4] arm64: dts: Add basic DT to support Spreadtrum's SP9860G

On Thu, Mar 02, 2017 at 02:22:07PM +0800, Chunyan Zhang wrote: > From: Orson Zhai > > SC9860G is a 8 cores of A53 SoC with 4G LTE support SoC from Spreadtrum. > > According to regular hierarchy of sprd dts, whale2.dtsi contains SoC > peripherals IP nodes, sc9860.dtsi contains stuff related to

[PATCH 04/11] drm/meson: venc_cvbs: no more return -ENODEV if CVBS is not available

Since this is managed now by the components code, if CVBS is not available and HDMI neither, the drm driver won't bind anyway. Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/meson_venc_cvbs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [PATCH] Drivers: hv: util: move waiting for release to hv_utils_transport itself

On Thu, 2 Mar 2017 10:47:49 +0100 Vitaly Kuznetsov wrote: > Waiting for release_event in all three drivers introduced issues on release > as on_reset() hook is not always called. E.g. if the device was never > opened we will never get the completion. > > Move the waiting

Re: [PATCH] Drivers: hv: util: move waiting for release to hv_utils_transport itself

On Thu, 2 Mar 2017 10:47:49 +0100 Vitaly Kuznetsov wrote: > Waiting for release_event in all three drivers introduced issues on release > as on_reset() hook is not always called. E.g. if the device was never > opened we will never get the completion. > > Move the waiting code to

<    4   5   6   7   8   9   10   11   12   13   >