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
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
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
>
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
>
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 +
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 +
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=]
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=]
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
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
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,
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:
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
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:
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
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:
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
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
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
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(-)
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
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
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
>
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
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
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
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
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
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
---
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
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.
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.
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
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
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
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
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 ---
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
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}
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}
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
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
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
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
>>
> >> 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
> >> 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
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
---
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
---
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
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
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
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
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
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
---
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
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
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
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:
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
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
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
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:
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
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
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
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
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
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
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
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
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':
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':
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
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
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
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
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
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
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=]
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
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=]
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
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.
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.
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
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
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
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
+++ 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
+++ 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
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
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
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
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
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
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
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
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
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
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
801 - 900 of 1740 matches
Mail list logo