Re: [PATCH] drm: fourcc byteorder: brings header file comments in line with reality.

Thanks, Christian for adding me. On 2017-04-21 09:27 AM, Christian König wrote: Adding Harry to this mail thread as well, cause is one of the people really affected by this. Christian. Am 21.04.2017 um 15:21 schrieb Christian König: Am 21.04.2017 um 15:12 schrieb Gerd Hoffmann: Hi,

Re: [PATCH] bus: fsl-mc: dpio: fix alter FQ state command

On Fri, Apr 21, 2017 at 01:50:24PM +, Horia Geantă wrote: > Let me know whether keeping code similar would be preferred or not. > Keeping the code similar to the surrounding is never a valid argument but especially not in staging/. If only 1 line is nice in the whole file, at least that's

[PATCH v1 2/8] ASoC: Intel: Skylake: Use recently introduced uuid_le_cmp_p{p}()

Recently introduced helpers take pointers to uuid_{be|le} instead of reference. Using them makes code less ugly. Cc: Liam Girdwood Cc: Mark Brown Cc: Vinod Koul Signed-off-by: Andy Shevchenko

[PATCH v1 2/8] ASoC: Intel: Skylake: Use recently introduced uuid_le_cmp_p{p}()

Recently introduced helpers take pointers to uuid_{be|le} instead of reference. Using them makes code less ugly. Cc: Liam Girdwood Cc: Mark Brown Cc: Vinod Koul Signed-off-by: Andy Shevchenko --- sound/soc/intel/skylake/skl-pcm.c | 2 +- sound/soc/intel/skylake/skl-sst-utils.c | 4

Re: [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

On 21/04/17 16:24, Boris Ostrovsky wrote: > >> +static bool __init xen_check_xsave(void) >> { >> -unsigned int ax, bx, cx, dx; >> -unsigned int xsave_mask; >> +unsigned int err, eax, edx; >> >> -ax = 1; >> -cx = 0; >> -cpuid(1, , , , ); >> +/* Test OSXSAVE

Re: [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

On 21/04/17 16:24, Boris Ostrovsky wrote: > >> +static bool __init xen_check_xsave(void) >> { >> -unsigned int ax, bx, cx, dx; >> -unsigned int xsave_mask; >> +unsigned int err, eax, edx; >> >> -ax = 1; >> -cx = 0; >> -cpuid(1, , , , ); >> +/* Test OSXSAVE

Re: mtip32xx: add a status field to struct mtip_cmd

On Fri, Apr 21, 2017 at 08:14:03AM -0600, Jens Axboe wrote: > From: Jens Axboe > Subject: [PATCH] mtip32xx: fix dereference of stack garbage > > We need to get the command payload from the request before > we attempt to dereference it. > > Fixes: 4dda4735c581 ("mtip32xx: add a

Re: [PATCH 2/3] bus: fsl-mc: dpio: enable qbman CENA portal memory access

On Thu, Apr 20, 2017 at 03:34:17PM -0400, Haiying Wang wrote: > Once we enable the cacheable portal memory, we need to do > cache flush for enqueue, vdq, buffer release, and management > commands, as well as invalidate and prefetch for the valid bit > of management command response and next index

Re: mtip32xx: add a status field to struct mtip_cmd

On Fri, Apr 21, 2017 at 08:14:03AM -0600, Jens Axboe wrote: > From: Jens Axboe > Subject: [PATCH] mtip32xx: fix dereference of stack garbage > > We need to get the command payload from the request before > we attempt to dereference it. > > Fixes: 4dda4735c581 ("mtip32xx: add a status field to

Re: [PATCH 2/3] bus: fsl-mc: dpio: enable qbman CENA portal memory access

On Thu, Apr 20, 2017 at 03:34:17PM -0400, Haiying Wang wrote: > Once we enable the cacheable portal memory, we need to do > cache flush for enqueue, vdq, buffer release, and management > commands, as well as invalidate and prefetch for the valid bit > of management command response and next index

Re: [PATCH] scsi: BusLogic: fix incorrect spelling of adatper_reset_req

On 02/21/2017 09:27 AM, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake, adatper_reset_req should > be adapter_reset_req. Also break up very long seq_printf statement > into multiple lines. > > Signed-off-by: Colin Ian King

Re: [PATCH] scsi: BusLogic: fix incorrect spelling of adatper_reset_req

Khalid, >> trivial fix to spelling mistake, adatper_reset_req should be >> adapter_reset_req. Also break up very long seq_printf statement into >> multiple lines. Applied to 4.12/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH] scsi: BusLogic: fix incorrect spelling of adatper_reset_req

On 02/21/2017 09:27 AM, Colin King wrote: > From: Colin Ian King > > trivial fix to spelling mistake, adatper_reset_req should > be adapter_reset_req. Also break up very long seq_printf statement > into multiple lines. > > Signed-off-by: Colin Ian King > --- > drivers/scsi/BusLogic.c | 14

Re: [PATCH] scsi: BusLogic: fix incorrect spelling of adatper_reset_req

Khalid, >> trivial fix to spelling mistake, adatper_reset_req should be >> adapter_reset_req. Also break up very long seq_printf statement into >> multiple lines. Applied to 4.12/scsi-queue. Thanks! -- Martin K. Petersen Oracle Linux Engineering

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

On 2017-04-21 16:23, Philipp Zabel wrote: > On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote: > [...] >> +int mux_chip_register(struct mux_chip *mux_chip) >> +{ >> +int i; >> +int ret; >> + >> +for (i = 0; i < mux_chip->controllers; ++i) { >> +struct mux_control *mux =

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

On 2017-04-21 16:23, Philipp Zabel wrote: > On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote: > [...] >> +int mux_chip_register(struct mux_chip *mux_chip) >> +{ >> +int i; >> +int ret; >> + >> +for (i = 0; i < mux_chip->controllers; ++i) { >> +struct mux_control *mux =

Re: [PATCH 3/5] KEYS: encrypted: sanitize all key material

Eric Biggers wrote: > - memzero_explicit(epayload->decrypted_data, epayload->decrypted_datalen); > - kfree(key->payload.data[0]); > + kzfree(key->payload.data[0]); Should kzfree() be using memzero_explicit() rather than memset()? David

Re: [PATCH 3/5] KEYS: encrypted: sanitize all key material

Eric Biggers wrote: > - memzero_explicit(epayload->decrypted_data, epayload->decrypted_datalen); > - kfree(key->payload.data[0]); > + kzfree(key->payload.data[0]); Should kzfree() be using memzero_explicit() rather than memset()? David

Re: [PATCH 1/3] arm64: extend ioremap for cacheable non-shareable memory

These transactions are done in HW via an ACP port which if I remember correctly only supports non coherent transactions. I will need to go back and check through email conversations I had with Catalin last year when debugging an issue using this mechanism (cacheable/nonshareable mapping) but

Re: [PATCH 1/3] arm64: extend ioremap for cacheable non-shareable memory

These transactions are done in HW via an ACP port which if I remember correctly only supports non coherent transactions. I will need to go back and check through email conversations I had with Catalin last year when debugging an issue using this mechanism (cacheable/nonshareable mapping) but

Re: [PATCH] x86/mpx: Correctly report do_mpx_bt_fault() failures to user-space

On 04/21/2017 05:19 AM, Joerg Roedel wrote: > On Thu, Apr 20, 2017 at 08:45:28AM -0700, Dave Hansen wrote: >> How about doing X86_TRAP_PF? That would at least be consistent with >> SIGBUS, which is probably the closest thing to a generic error code that >> we have. > Correct me if I am wrong, but

Re: [PATCH] x86/mpx: Correctly report do_mpx_bt_fault() failures to user-space

On 04/21/2017 05:19 AM, Joerg Roedel wrote: > On Thu, Apr 20, 2017 at 08:45:28AM -0700, Dave Hansen wrote: >> How about doing X86_TRAP_PF? That would at least be consistent with >> SIGBUS, which is probably the closest thing to a generic error code that >> we have. > Correct me if I am wrong, but

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

On 4/20/17 10:09 AM, Andrey Konovalov wrote: > On Thu, Apr 20, 2017 at 5:39 PM, Andrey Konovalov > wrote: >> On Thu, Apr 20, 2017 at 5:35 PM, David Ahern >> wrote: >>> On 4/20/17 9:28 AM, Andrey Konovalov wrote: This one seems to be much

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

On 4/20/17 10:09 AM, Andrey Konovalov wrote: > On Thu, Apr 20, 2017 at 5:39 PM, Andrey Konovalov > wrote: >> On Thu, Apr 20, 2017 at 5:35 PM, David Ahern >> wrote: >>> On 4/20/17 9:28 AM, Andrey Konovalov wrote: This one seems to be much closer to what Dmitry reported intially. >>> does

Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver

Hi Andy, thanks for respond. My comments are inlined below. On Tue, 2017-04-18 at 15:31 +0300, Andy Shevchenko wrote: > On Fri, 2017-04-07 at 17:04 +0300, Eugeniy Paltsev wrote: > > This patch adds support for the DW AXI DMAC controller. > > > > DW AXI DMAC is a part of upcoming development board

Re: [PATCH v2 2/2] dmaengine: Add DW AXI DMAC driver

Hi Andy, thanks for respond. My comments are inlined below. On Tue, 2017-04-18 at 15:31 +0300, Andy Shevchenko wrote: > On Fri, 2017-04-07 at 17:04 +0300, Eugeniy Paltsev wrote: > > This patch adds support for the DW AXI DMAC controller. > > > > DW AXI DMAC is a part of upcoming development board

Re: [PATCH v17 2/3] usb: USB Type-C connector class

On Fri, Apr 21, 2017 at 1:16 AM, Badhri Jagan Sridharan wrote: > Thanks for the responses :) > > So seems like we have a plan. > > In Type-C connector class the checks for TYPEC_PWR_MODE_PD > and pd_revision for both the port and the partner will be removed in >

Re: [PATCH v17 2/3] usb: USB Type-C connector class

On Fri, Apr 21, 2017 at 1:16 AM, Badhri Jagan Sridharan wrote: > Thanks for the responses :) > > So seems like we have a plan. > > In Type-C connector class the checks for TYPEC_PWR_MODE_PD > and pd_revision for both the port and the partner will be removed in > power_role_store and the

Re: [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

> +static bool __init xen_check_xsave(void) > { > - unsigned int ax, bx, cx, dx; > - unsigned int xsave_mask; > + unsigned int err, eax, edx; > > - ax = 1; > - cx = 0; > - cpuid(1, , , , ); > + /* Test OSXSAVE capability via xgetbv instruction. */ > + asm

Re: [PATCH v3 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

> +static bool __init xen_check_xsave(void) > { > - unsigned int ax, bx, cx, dx; > - unsigned int xsave_mask; > + unsigned int err, eax, edx; > > - ax = 1; > - cx = 0; > - cpuid(1, , , , ); > + /* Test OSXSAVE capability via xgetbv instruction. */ > + asm

[PATCH v3 02/29] x86_32: boot, extract efi_pe_entry from startup_32

efi_pe_entry body is somehow squashed into startup_32. In the old days, we forced startup_32 to start at offset 0x00 and efi_pe_entry to start at 0x10. But this requirement was removed in 99f857db8857 ("x86, build: Dynamically find entry points in compressed startup code") long time ago. The way

[PATCH v3 02/29] x86_32: boot, extract efi_pe_entry from startup_32

efi_pe_entry body is somehow squashed into startup_32. In the old days, we forced startup_32 to start at offset 0x00 and efi_pe_entry to start at 0x10. But this requirement was removed in 99f857db8857 ("x86, build: Dynamically find entry points in compressed startup code") long time ago. The way

[PATCH v3 05/29] x86: assembly, add ENDPROC to functions

Some functions are annotated as ENTRY or GLOBAL, but their ends are not annotated at all. This means: * the annotations are not paired and we cannot deal with such functions e.g. in objtool * the symbols are not marked as functions in the object file * there are no sizes of the functions in the

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote: [...] > +int mux_chip_register(struct mux_chip *mux_chip) > +{ > + int i; > + int ret; > + > + for (i = 0; i < mux_chip->controllers; ++i) { > + struct mux_control *mux = _chip->mux[i]; > + > + if

[PATCH v3 05/29] x86: assembly, add ENDPROC to functions

Some functions are annotated as ENTRY or GLOBAL, but their ends are not annotated at all. This means: * the annotations are not paired and we cannot deal with such functions e.g. in objtool * the symbols are not marked as functions in the object file * there are no sizes of the functions in the

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote: [...] > +int mux_chip_register(struct mux_chip *mux_chip) > +{ > + int i; > + int ret; > + > + for (i = 0; i < mux_chip->controllers; ++i) { > + struct mux_control *mux = _chip->mux[i]; > + > + if

Re: [PATCH v2 00/11] Documentation: Add ABI to the admin guide

Em Fri, 21 Apr 2017 08:37:45 +0200 Markus Heiser escreveu: > Am 21.04.2017 um 01:21 schrieb Mauro Carvalho Chehab > : > > > - I'm not a python programmer ;-) I just took Markus "generic" kernel-cmd > > code, hardcoding there a call to the

[PATCH v3 06/29] x86: assembly, annotate functions by ENTRY, not GLOBAL

GLOBAL is meant for global symbols, but not functions. Use ENTRY which is dedicated for global functions: * it aligns the functions properly * it is expected to have a corresponding ENDPROC too. startup_64, which uses .globl explicitly, is converted too. Besides that, x86's custom GLOBAL macro

[PATCH v3 06/29] x86: assembly, annotate functions by ENTRY, not GLOBAL

GLOBAL is meant for global symbols, but not functions. Use ENTRY which is dedicated for global functions: * it aligns the functions properly * it is expected to have a corresponding ENDPROC too. startup_64, which uses .globl explicitly, is converted too. Besides that, x86's custom GLOBAL macro

Re: [PATCH v2 00/11] Documentation: Add ABI to the admin guide

Em Fri, 21 Apr 2017 08:37:45 +0200 Markus Heiser escreveu: > Am 21.04.2017 um 01:21 schrieb Mauro Carvalho Chehab > : > > > - I'm not a python programmer ;-) I just took Markus "generic" kernel-cmd > > code, hardcoding there a call to the script. > > > > With (a lot of) time, I would likely

[PATCH v3 04/29] x86: assembly, use ENDPROC for functions

Somewhere END was used to end a function. It is not intended to be used for functions, because it does not mark the actual symbols as functions. Use ENDPROC in such cases which does the right job. Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar

[PATCH v3 11/29] x86: entry, annotate THUNKs

Place SYM_FUNC_START and SYM_FUNC_END around the THUNK macro body, given it generates functions. Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: ---

[PATCH v3 04/29] x86: assembly, use ENDPROC for functions

Somewhere END was used to end a function. It is not intended to be used for functions, because it does not mark the actual symbols as functions. Use ENDPROC in such cases which does the right job. Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: Cc:

[PATCH v3 11/29] x86: entry, annotate THUNKs

Place SYM_FUNC_START and SYM_FUNC_END around the THUNK macro body, given it generates functions. Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: --- arch/x86/entry/thunk_32.S | 4 ++-- arch/x86/entry/thunk_64.S | 5 ++--- 2 files changed, 4

[PATCH v3 10/29] x86: assembly, annotate relocate_kernel

Annotate all functions in relocate_kernel by SYM_FUNC_START, SYM_FUNC_START_LOCAL, and SYM_FUNC_END properly. We get in return: 108 FUNCGLOBAL DEFAULT1 relocate_kernel 0070 165 FUNCLOCAL DEFAULT1 identity_mapped 012053 FUNCLOCAL DEFAULT1 virtual_mapped

[PATCH v3 10/29] x86: assembly, annotate relocate_kernel

Annotate all functions in relocate_kernel by SYM_FUNC_START, SYM_FUNC_START_LOCAL, and SYM_FUNC_END properly. We get in return: 108 FUNCGLOBAL DEFAULT1 relocate_kernel 0070 165 FUNCLOCAL DEFAULT1 identity_mapped 012053 FUNCLOCAL DEFAULT1 virtual_mapped

[PATCH v3 08/29] linkage: new macros for assembler symbols

Introduce new C macros for annotations of functions and data in assembly. There is a long-term mess in macros like ENTRY, END, ENDPROC and similar. They are used in different manners and sometimes incorrectly. So introduce macros with clear use to annotate assembly as follows: a) Support macros

[PATCH v3 08/29] linkage: new macros for assembler symbols

Introduce new C macros for annotations of functions and data in assembly. There is a long-term mess in macros like ENTRY, END, ENDPROC and similar. They are used in different manners and sometimes incorrectly. So introduce macros with clear use to annotate assembly as follows: a) Support macros

[PATCH v3 09/29] x86: assembly, use DATA_SIMPLE for data

This is a start of series to cleanup macros used for starting functions, data, globals etc. across x86. When we have all this sorted out, this will help to inject DWARF unwinding info by objtool later. The goal is forcing SYM_FUNC_START to emit .cfi_startproc and SYM_FUNC_END to emit

[PATCH v3 09/29] x86: assembly, use DATA_SIMPLE for data

This is a start of series to cleanup macros used for starting functions, data, globals etc. across x86. When we have all this sorted out, this will help to inject DWARF unwinding info by objtool later. The goal is forcing SYM_FUNC_START to emit .cfi_startproc and SYM_FUNC_END to emit

[PATCH v3 07/29] x86: bpf_jit, use ENTRY+ENDPROC

Do not use a custom macro FUNC for starts of the global functions, use ENTRY instead. And while at it, annotate also ends of the functions by ENDPROC. Signed-off-by: Jiri Slaby Cc: "David S. Miller" Cc: Alexey Kuznetsov Cc: James

[PATCH v3 07/29] x86: bpf_jit, use ENTRY+ENDPROC

Do not use a custom macro FUNC for starts of the global functions, use ENTRY instead. And while at it, annotate also ends of the functions by ENDPROC. Signed-off-by: Jiri Slaby Cc: "David S. Miller" Cc: Alexey Kuznetsov Cc: James Morris Cc: Hideaki YOSHIFUJI Cc: Patrick McHardy Cc: Thomas

[PATCH v3 13/29] x86: crypto, annotate local functions

Use the newly added SYM_FUNC_START_LOCAL to annotate starts of all functions which do not have ".globl" annotation, but their ends are annotated by ENDPROC. This is needed to balance ENDPROC for tools that are about to generate debuginfo. We also convert their ENDPROCs to the new SYM_FUNC_END.

[PATCH v3 13/29] x86: crypto, annotate local functions

Use the newly added SYM_FUNC_START_LOCAL to annotate starts of all functions which do not have ".globl" annotation, but their ends are annotated by ENDPROC. This is needed to balance ENDPROC for tools that are about to generate debuginfo. We also convert their ENDPROCs to the new SYM_FUNC_END.

[PATCH v3 14/29] x86: boot, annotate local functions

relocated and no_longmode are self-standing local functions, annotate them as such. Signed-off-by: Jiri Slaby Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: x...@kernel.org ---

[PATCH v3 14/29] x86: boot, annotate local functions

relocated and no_longmode are self-standing local functions, annotate them as such. Signed-off-by: Jiri Slaby Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar Cc: x...@kernel.org --- arch/x86/boot/compressed/head_32.S | 3 ++- arch/x86/boot/compressed/head_64.S | 7 +-- 2 files

[PATCH v3 12/29] x86: assembly, annotate local functions

Use the newly added SYM_FUNC_START_LOCAL to annotate starts of all functions which do not have ".globl" annotation. This is needed to balance SYM_FUNC_END for tools that are about to generate debuginfo. Note that some functions already had ENDPROC -- switch to the new SYM_FUNC_END too. [v3]

[PATCH v3 12/29] x86: assembly, annotate local functions

Use the newly added SYM_FUNC_START_LOCAL to annotate starts of all functions which do not have ".globl" annotation. This is needed to balance SYM_FUNC_END for tools that are about to generate debuginfo. Note that some functions already had ENDPROC -- switch to the new SYM_FUNC_END too. [v3]

[PATCH v3 29/29] x86: assembly, replace WEAK uses

Use the new SYM_FUNC_INNER_LABEL for WEAK entries in the middle of x86 assembly functions. And make sure WEAK is not defined for X86. Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc:

[PATCH v3 29/29] x86: assembly, replace WEAK uses

Use the new SYM_FUNC_INNER_LABEL for WEAK entries in the middle of x86 assembly functions. And make sure WEAK is not defined for X86. Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org --- arch/x86/kernel/ftrace_32.S | 2 +-

[PATCH v3 26/29] x86_64: assembly, change all ENTRY to SYM_FUNC_START

These are all functions which are invoked from elsewhere, so we annotate them as global using the new SYM_FUNC_START (and their ENDPROC's by SYM_FUNC_END.) And make sure ENTRY/ENDPROC is not defined on X86_64. Signed-off-by: Jiri Slaby Cc: "H. Peter Anvin" Cc:

[PATCH v3 26/29] x86_64: assembly, change all ENTRY to SYM_FUNC_START

These are all functions which are invoked from elsewhere, so we annotate them as global using the new SYM_FUNC_START (and their ENDPROC's by SYM_FUNC_END.) And make sure ENTRY/ENDPROC is not defined on X86_64. Signed-off-by: Jiri Slaby Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc: Ingo Molnar

[PATCH] nfs/filelayout: fix NULL pointer dereference in fl_pnfs_update_layout()

Calling pnfs_put_lset on an IS_ERR pointer results in a NULL pointer dereference like the one below. fl_pnfs_update_layout()'s output is checked after each call so it doesn't seem that it should try to handle these errors on it's own. [ 3000.636161] BUG: unable to handle kernel NULL pointer

[PATCH] nfs/filelayout: fix NULL pointer dereference in fl_pnfs_update_layout()

Calling pnfs_put_lset on an IS_ERR pointer results in a NULL pointer dereference like the one below. fl_pnfs_update_layout()'s output is checked after each call so it doesn't seem that it should try to handle these errors on it's own. [ 3000.636161] BUG: unable to handle kernel NULL pointer

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

Hi Peter, On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote: [...] > +int mux_control_select(struct mux_control *mux, int state) state could be unsigned int for the consumer facing API. > +{ > + int ret; And mux_control_select should check that (0 <= state < mux->states). regards

Re: [PATCH v13 03/10] mux: minimal mux subsystem and gpio-based mux controller

Hi Peter, On Thu, 2017-04-13 at 18:43 +0200, Peter Rosin wrote: [...] > +int mux_control_select(struct mux_control *mux, int state) state could be unsigned int for the consumer facing API. > +{ > + int ret; And mux_control_select should check that (0 <= state < mux->states). regards

[PATCH v3 24/29] x86: assembly, remove GLOBAL macro

Convert the remaining 32bit users and remove GLOBAL macro finally. In particular, this means to use SYM_ENTRY for the singlestepping hack region. Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin"

Re: [PATCH 1/1] fs: Allows for xattr support to be compiled out

Hi Brian, [auto build test WARNING on linus/master] [also build test WARNING on v4.11-rc7 next-20170421] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Brian-Ashworth/fs-Allows-for-xattr

[PATCH v3 24/29] x86: assembly, remove GLOBAL macro

Convert the remaining 32bit users and remove GLOBAL macro finally. In particular, this means to use SYM_ENTRY for the singlestepping hack region. Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org --- arch/x86/entry/entry_32.S | 4 ++--

Re: [PATCH 1/1] fs: Allows for xattr support to be compiled out

Hi Brian, [auto build test WARNING on linus/master] [also build test WARNING on v4.11-rc7 next-20170421] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Brian-Ashworth/fs-Allows-for-xattr

Re: [PATCH v1] net: phy: fix auto-negotiation stall due to unavailable interrupt

On 20/04/17 14:00, Alexander Kochetkov wrote: > The Ethernet link on an interrupt driven PHY was not coming up if the Ethernet > cable was plugged before the Ethernet interface was brought up. > > The patch trigger PHY state machine to update link state if PHY was requested > to > do

Re: [PATCH v1] net: phy: fix auto-negotiation stall due to unavailable interrupt

On 20/04/17 14:00, Alexander Kochetkov wrote: > The Ethernet link on an interrupt driven PHY was not coming up if the Ethernet > cable was plugged before the Ethernet interface was brought up. > > The patch trigger PHY state machine to update link state if PHY was requested > to > do

[PATCH v3 23/29] x86: realmode, use SYM_DATA_* instead of GLOBAL

GLOBAL had several meanings and is going away. In this patch, convert all the data marked using GLOBAL to use SYM_DATA_START or SYM_DATA_SIMPLE instead. Notes: * SYM_DATA_END_LABEL is used to generate tr_gdt_end too. * wakeup_idt is marked as LOCAL now as it is used only locally. Since we

[PATCH v3 23/29] x86: realmode, use SYM_DATA_* instead of GLOBAL

GLOBAL had several meanings and is going away. In this patch, convert all the data marked using GLOBAL to use SYM_DATA_START or SYM_DATA_SIMPLE instead. Notes: * SYM_DATA_END_LABEL is used to generate tr_gdt_end too. * wakeup_idt is marked as LOCAL now as it is used only locally. Since we

[PATCH v3 22/29] x86: assembly, use SYM_FUNC_INNER_LABEL instead of GLOBAL

GLOBAL had several meanings and is going away. In this patch, convert all the inner functions labels marked with GLOBAL to use SYM_FUNC_INNER_LABEL instead. Note that retint_user needs not be global, perhaps since commit 2ec67971facc ("x86/entry/64/compat: Remove most of the fast system call

[PATCH v3 22/29] x86: assembly, use SYM_FUNC_INNER_LABEL instead of GLOBAL

GLOBAL had several meanings and is going away. In this patch, convert all the inner functions labels marked with GLOBAL to use SYM_FUNC_INNER_LABEL instead. Note that retint_user needs not be global, perhaps since commit 2ec67971facc ("x86/entry/64/compat: Remove most of the fast system call

[PATCH v3 20/29] x86: xen-pvh, annotate data appropriatelly

Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros: 8 OBJECT LOCAL DEFAULT6 gdt 000832 OBJECT LOCAL DEFAULT6 gdt_start 0028 0 OBJECT LOCAL DEFAULT6 gdt_end 0028 256 OBJECT LOCAL DEFAULT6 early_stack 0128 0 OBJECT LOCAL DEFAULT6

[PATCH v3 20/29] x86: xen-pvh, annotate data appropriatelly

Use the new SYM_DATA_START_LOCAL, and SYM_DATA_END* macros: 8 OBJECT LOCAL DEFAULT6 gdt 000832 OBJECT LOCAL DEFAULT6 gdt_start 0028 0 OBJECT LOCAL DEFAULT6 gdt_end 0028 256 OBJECT LOCAL DEFAULT6 early_stack 0128 0 OBJECT LOCAL DEFAULT6

[PATCH v3 21/29] x86: purgatory, start using annotations

purgatory used no annotations. So include linux/linkage.h and annotate everything: * functions by SYM_FUNC_* * data by SYM_DATA_* Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc:

[PATCH v3 25/29] x86: assembly, make some functions local

There is couple of assembly functions, which are invoked only locally in a file they are defined. In C, we mark them "static". Annotate them here using SYM_FUNC_START_LOCAL (and switch their ENDPROC to SYM_FUNC_END too). Signed-off-by: Jiri Slaby Cc: "H. Peter Anvin"

[PATCH v3 21/29] x86: purgatory, start using annotations

purgatory used no annotations. So include linux/linkage.h and annotate everything: * functions by SYM_FUNC_* * data by SYM_DATA_* Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: x...@kernel.org --- arch/x86/purgatory/entry64.S | 21

[PATCH v3 25/29] x86: assembly, make some functions local

There is couple of assembly functions, which are invoked only locally in a file they are defined. In C, we mark them "static". Annotate them here using SYM_FUNC_START_LOCAL (and switch their ENDPROC to SYM_FUNC_END too). Signed-off-by: Jiri Slaby Cc: "H. Peter Anvin" Cc: Thomas Gleixner Cc:

Re: [tip:x86/mm] x86/mm/gup: Switch GUP to the generic get_user_page_fast() implementation

On Thu, Apr 20, 2017 at 02:46:51PM -0700, Dan Williams wrote: > On Sat, Mar 18, 2017 at 2:52 AM, tip-bot for Kirill A. Shutemov > wrote: > > Commit-ID: 2947ba054a4dabbd82848728d765346886050029 > > Gitweb: > >

Re: [tip:x86/mm] x86/mm/gup: Switch GUP to the generic get_user_page_fast() implementation

On Thu, Apr 20, 2017 at 02:46:51PM -0700, Dan Williams wrote: > On Sat, Mar 18, 2017 at 2:52 AM, tip-bot for Kirill A. Shutemov > wrote: > > Commit-ID: 2947ba054a4dabbd82848728d765346886050029 > > Gitweb: > > http://git.kernel.org/tip/2947ba054a4dabbd82848728d765346886050029 > > Author:

[PATCH v3 16/29] x86: entry, annotate interrupt symbols properly

* annotate local functions properly by SYM_FUNC_START_LOCAL and SYM_FUNC_END * use SYM_FUNC_INNER_LABEL for functions being in the middle of others * mark the end of common_interrupt by SYM_FUNC_END Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo

[PATCH v3 16/29] x86: entry, annotate interrupt symbols properly

* annotate local functions properly by SYM_FUNC_START_LOCAL and SYM_FUNC_END * use SYM_FUNC_INNER_LABEL for functions being in the middle of others * mark the end of common_interrupt by SYM_FUNC_END Signed-off-by: Jiri Slaby Cc: Thomas Gleixner Cc: Ingo Molnar Cc: "H. Peter Anvin" Cc: ---

Re: [PATCH v3] scsi/bfa: use designated initializers

Kees Cook writes: Kees, > Prepare to mark sensitive kernel structures for randomization by > making sure they're using designated initializers. This also > initializes the array members using the enum used to look up > __port_action entries. Applied to 4.12/scsi-queue.

Re: [PATCH v3] scsi/bfa: use designated initializers

Kees Cook writes: Kees, > Prepare to mark sensitive kernel structures for randomization by > making sure they're using designated initializers. This also > initializes the array members using the enum used to look up > __port_action entries. Applied to 4.12/scsi-queue. Thanks! -- Martin K.

RE: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

> >On 4/21/2017 3:46 AM, Patel, Mayurkumar wrote: >> If we want to follow above approach then shall we consider having something >> similar as following? > >Do you see this problem if you boot with pcie_aspm.policy=powersave option? > No problems. with pcie_aspm.policy=powersave(L1SS are not

[PATCH v2 3/3] rtmutex: remove unnecessary adjust prio

We don't need to adjust prio before new pi_waiter adding. The prio only need update after pi_waiter change or task priority change. Signed-off-by: Alex Shi Cc: Steven Rostedt Cc: Sebastian Siewior To: linux-kernel@vger.kernel.org

RE: [PATCH V8 4/5] PCI/ASPM: save power on values during bridge init

> >On 4/21/2017 3:46 AM, Patel, Mayurkumar wrote: >> If we want to follow above approach then shall we consider having something >> similar as following? > >Do you see this problem if you boot with pcie_aspm.policy=powersave option? > No problems. with pcie_aspm.policy=powersave(L1SS are not

[PATCH v2 3/3] rtmutex: remove unnecessary adjust prio

We don't need to adjust prio before new pi_waiter adding. The prio only need update after pi_waiter change or task priority change. Signed-off-by: Alex Shi Cc: Steven Rostedt Cc: Sebastian Siewior To: linux-kernel@vger.kernel.org To: Ingo Molnar To: Peter Zijlstra Cc: Thomas Gleixner ---

[PATCH v3 17/29] x86: head, annotate data appropriatelly

Use the new SYM_DATA_SIMPLE and SYM_DATA_END in both 32 and 64 bit heads. In the 64-bit version, define also SYM_DATA_START_PAGE_ALIGNED locally using the new SYM_START. It is used in the code instead of NEXT_PAGE() which was defined in this file and has been using the obsolete macro GLOBAL().

[PATCH v3 17/29] x86: head, annotate data appropriatelly

Use the new SYM_DATA_SIMPLE and SYM_DATA_END in both 32 and 64 bit heads. In the 64-bit version, define also SYM_DATA_START_PAGE_ALIGNED locally using the new SYM_START. It is used in the code instead of NEXT_PAGE() which was defined in this file and has been using the obsolete macro GLOBAL().

Re: mtip32xx: add a status field to struct mtip_cmd

On 04/21/2017 08:06 AM, Colin Ian King wrote: > Hi, > > CoverityScan found an issue with the following part of the patch: > > - if (likely(!reserv)) > - blk_mq_complete_request(rq, -ENODEV); > - else if (test_bit(MTIP_PF_IC_ACTIVE_BIT, >port->flags)) { > + if

Re: mtip32xx: add a status field to struct mtip_cmd

On 04/21/2017 08:06 AM, Colin Ian King wrote: > Hi, > > CoverityScan found an issue with the following part of the patch: > > - if (likely(!reserv)) > - blk_mq_complete_request(rq, -ENODEV); > - else if (test_bit(MTIP_PF_IC_ACTIVE_BIT, >port->flags)) { > + if

[PATCH v2 1/3] rtmutex: update rt-mutex-design

The rt-mutex-design documents didn't gotten meaningful update from its first version. Even after owner's pending bit was removed in commit 8161239a8bcc ("rtmutex: Simplify PI algorithm and make highest prio task get lock") and priority list 'plist' changed to rbtree. So the documents are far late

[PATCH v2 1/3] rtmutex: update rt-mutex-design

The rt-mutex-design documents didn't gotten meaningful update from its first version. Even after owner's pending bit was removed in commit 8161239a8bcc ("rtmutex: Simplify PI algorithm and make highest prio task get lock") and priority list 'plist' changed to rbtree. So the documents are far late

[PATCH v2 2/3] rtmutex: update rt-mutex

The rtmutex remove a pending owner bit in in rt_mutex::owner, in commit 8161239a8bcc ("rtmutex: Simplify PI algorithm and make highest prio task get lock") But the document was changed accordingly. Updating it to a meaningful state. BTW, as 'Steven Rostedt' mentioned: There is still technically

[PATCH v2 2/3] rtmutex: update rt-mutex

The rtmutex remove a pending owner bit in in rt_mutex::owner, in commit 8161239a8bcc ("rtmutex: Simplify PI algorithm and make highest prio task get lock") But the document was changed accordingly. Updating it to a meaningful state. BTW, as 'Steven Rostedt' mentioned: There is still technically

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