Re: [PATCH 05/11] [media] s5p-mfc: Add support for HEVC decoder

[Andrzej Hajda]

On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add support for codec definition and corresponding buffer
> requirements for HEVC decoder.
>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |3 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|8 
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   18 --
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |5 +
>  6 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index 153ee68..a57009a 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -32,6 +32,9 @@
>  #define MFC_VERSION_V10  0xA0
>  #define MFC_NUM_PORTS_V101
>  
> +/* MFCv10 codec defines*/
> +#define S5P_FIMV_CODEC_HEVC_DEC  17
> +
>  /* Encoder buffer size for MFC v10.0 */
>  #define ENC_V100_H264_ME_SIZE(x, y)  \
>   (((x + 3) * (y + 3) * 8)\
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> index b1b1491..76eca67 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> @@ -101,6 +101,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx 
> *ctx)
>   case S5P_MFC_CODEC_VP8_DEC:
>   codec_type = S5P_FIMV_CODEC_VP8_DEC_V6;
>   break;
> + case S5P_MFC_CODEC_HEVC_DEC:
> + codec_type = S5P_FIMV_CODEC_HEVC_DEC;
> + break;
>   case S5P_MFC_CODEC_H264_ENC:
>   codec_type = S5P_FIMV_CODEC_H264_ENC_V6;
>   break;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 998e24b..5c46060 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -79,6 +79,7 @@ static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void 
> *b)
>  #define S5P_MFC_CODEC_H263_DEC   5
>  #define S5P_MFC_CODEC_VC1RCV_DEC 6
>  #define S5P_MFC_CODEC_VP8_DEC7
> +#define S5P_MFC_CODEC_HEVC_DEC   17
>  
>  #define S5P_MFC_CODEC_H264_ENC   20
>  #define S5P_MFC_CODEC_H264_MVC_ENC   21
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 784b28e..9f459b3 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -156,6 +156,14 @@
>   .versions   = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT |
>   MFC_V10_BIT,
>   },
> + {
> + .name   = "HEVC Encoded Stream",
> + .fourcc = V4L2_PIX_FMT_HEVC,
> + .codec_mode = S5P_FIMV_CODEC_HEVC_DEC,
> + .type   = MFC_FMT_DEC,
> + .num_planes = 1,
> + .versions   = MFC_V10_BIT,
> + },
>  };
>  
>  #define NUM_FORMATS ARRAY_SIZE(formats)
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index 369210a..b6cb280 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -220,6 +220,13 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>   S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);
>   ctx->bank1.size = ctx->scratch_buf_size;
>   break;
> + case S5P_MFC_CODEC_HEVC_DEC:
> + mfc_debug(2, "Use min scratch buffer size\n");
> + ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size, 256);

Again alignment of something which should be already aligned, and magic
number instead of S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6.

> + ctx->bank1.size =
> + ctx->scratch_buf_size +
> + (ctx->mv_count * ctx->mv_size);
> + break;
>   case S5P_MFC_CODEC_H264_ENC:
>   if (IS_MFCV10(dev)) {
>   mfc_debug(2, "Use min scratch buffer size\n");
> @@ -322,6 +329,7 @@ static int s5p_mfc_alloc_instance_buffer_v6(struct 
> s5p_mfc_ctx *ctx)
>   switch (ctx->codec_mode) {
>   case S5P_MFC_CODEC_H264_DEC:
>   case S5P_MFC_CODEC_H264_MVC_DEC:
> + case S5P_MFC_CODEC_HEVC_DEC:
>   ctx->ctx.size = buf_size->h264_dec_ctx;
>   break;
>   case S5P_MFC_CODEC_MPEG4_DEC:
> @@ -438,6 +446,10 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct 
> s5p_mfc_ctx *ctx)
>   ctx->img_height);
>   

Re: [PATCH 05/11] [media] s5p-mfc: Add support for HEVC decoder

[Andrzej Hajda]

On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add support for codec definition and corresponding buffer
> requirements for HEVC decoder.
>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v10.h   |3 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3 +++
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_dec.c|8 
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   18 --
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |5 +
>  6 files changed, 36 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index 153ee68..a57009a 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -32,6 +32,9 @@
>  #define MFC_VERSION_V10  0xA0
>  #define MFC_NUM_PORTS_V101
>  
> +/* MFCv10 codec defines*/
> +#define S5P_FIMV_CODEC_HEVC_DEC  17
> +
>  /* Encoder buffer size for MFC v10.0 */
>  #define ENC_V100_H264_ME_SIZE(x, y)  \
>   (((x + 3) * (y + 3) * 8)\
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> index b1b1491..76eca67 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> @@ -101,6 +101,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx 
> *ctx)
>   case S5P_MFC_CODEC_VP8_DEC:
>   codec_type = S5P_FIMV_CODEC_VP8_DEC_V6;
>   break;
> + case S5P_MFC_CODEC_HEVC_DEC:
> + codec_type = S5P_FIMV_CODEC_HEVC_DEC;
> + break;
>   case S5P_MFC_CODEC_H264_ENC:
>   codec_type = S5P_FIMV_CODEC_H264_ENC_V6;
>   break;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 998e24b..5c46060 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -79,6 +79,7 @@ static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void 
> *b)
>  #define S5P_MFC_CODEC_H263_DEC   5
>  #define S5P_MFC_CODEC_VC1RCV_DEC 6
>  #define S5P_MFC_CODEC_VP8_DEC7
> +#define S5P_MFC_CODEC_HEVC_DEC   17
>  
>  #define S5P_MFC_CODEC_H264_ENC   20
>  #define S5P_MFC_CODEC_H264_MVC_ENC   21
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> index 784b28e..9f459b3 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -156,6 +156,14 @@
>   .versions   = MFC_V6_BIT | MFC_V7_BIT | MFC_V8_BIT |
>   MFC_V10_BIT,
>   },
> + {
> + .name   = "HEVC Encoded Stream",
> + .fourcc = V4L2_PIX_FMT_HEVC,
> + .codec_mode = S5P_FIMV_CODEC_HEVC_DEC,
> + .type   = MFC_FMT_DEC,
> + .num_planes = 1,
> + .versions   = MFC_V10_BIT,
> + },
>  };
>  
>  #define NUM_FORMATS ARRAY_SIZE(formats)
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index 369210a..b6cb280 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -220,6 +220,13 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct 
> s5p_mfc_ctx *ctx)
>   S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);
>   ctx->bank1.size = ctx->scratch_buf_size;
>   break;
> + case S5P_MFC_CODEC_HEVC_DEC:
> + mfc_debug(2, "Use min scratch buffer size\n");
> + ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size, 256);

Again alignment of something which should be already aligned, and magic
number instead of S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6.

> + ctx->bank1.size =
> + ctx->scratch_buf_size +
> + (ctx->mv_count * ctx->mv_size);
> + break;
>   case S5P_MFC_CODEC_H264_ENC:
>   if (IS_MFCV10(dev)) {
>   mfc_debug(2, "Use min scratch buffer size\n");
> @@ -322,6 +329,7 @@ static int s5p_mfc_alloc_instance_buffer_v6(struct 
> s5p_mfc_ctx *ctx)
>   switch (ctx->codec_mode) {
>   case S5P_MFC_CODEC_H264_DEC:
>   case S5P_MFC_CODEC_H264_MVC_DEC:
> + case S5P_MFC_CODEC_HEVC_DEC:
>   ctx->ctx.size = buf_size->h264_dec_ctx;
>   break;
>   case S5P_MFC_CODEC_MPEG4_DEC:
> @@ -438,6 +446,10 @@ static void s5p_mfc_dec_calc_dpb_size_v6(struct 
> s5p_mfc_ctx *ctx)
>   ctx->img_height);
>   ctx->mv_size = 

Re: [PATCH] staging: lustre: shut up clang warnings on CLASSERT()

[Dilger, Andreas]

On Feb 1, 2017, at 09:52, Arnd Bergmann  wrote:
> 
> lustre uses a fake switch() statement as a compile-time assert, but 
> unfortunately
> each use of that causes a warning when building with clang:
> 
> drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2907:2: warning: no case 
> matching constant switch condition '42'
> drivers/staging/lustre/lnet/klnds/socklnd/../../../include/linux/libcfs/libcfs_private.h:294:36:
>  note: expanded from macro 'CLASSERT'
> #define CLASSERT(cond) do {switch (42) {case (cond): case 0: break; } } while 
> (0)
> 
> Adding a 'default:' label in there shuts up the warning.
> 
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Andreas Dilger 

> ---
> drivers/staging/lustre/include/linux/libcfs/libcfs_private.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h 
> b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
> index aab15d8112a4..2d5435029185 100644
> --- a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
> +++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
> @@ -291,7 +291,7 @@ do {  
> \
>  *   value  after  conversion...
>  *
>  */
> -#define CLASSERT(cond) do {switch (42) {case (cond): case 0: break; } } 
> while (0)
> +#define CLASSERT(cond) do {switch (42) {case (cond): case 0: default: break; 
> } } while (0)
> 
> /* max value for numeric network address */
> #define MAX_NUMERIC_VALUE 0x
> -- 
> 2.9.0
> 

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Re: [PATCH] staging: lustre: shut up clang warnings on CLASSERT()

[Dilger, Andreas]

On Feb 1, 2017, at 09:52, Arnd Bergmann  wrote:
> 
> lustre uses a fake switch() statement as a compile-time assert, but 
> unfortunately
> each use of that causes a warning when building with clang:
> 
> drivers/staging/lustre/lnet/klnds/socklnd/socklnd.c:2907:2: warning: no case 
> matching constant switch condition '42'
> drivers/staging/lustre/lnet/klnds/socklnd/../../../include/linux/libcfs/libcfs_private.h:294:36:
>  note: expanded from macro 'CLASSERT'
> #define CLASSERT(cond) do {switch (42) {case (cond): case 0: break; } } while 
> (0)
> 
> Adding a 'default:' label in there shuts up the warning.
> 
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Andreas Dilger 

> ---
> drivers/staging/lustre/include/linux/libcfs/libcfs_private.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h 
> b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
> index aab15d8112a4..2d5435029185 100644
> --- a/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
> +++ b/drivers/staging/lustre/include/linux/libcfs/libcfs_private.h
> @@ -291,7 +291,7 @@ do {  
> \
>  *   value  after  conversion...
>  *
>  */
> -#define CLASSERT(cond) do {switch (42) {case (cond): case 0: break; } } 
> while (0)
> +#define CLASSERT(cond) do {switch (42) {case (cond): case 0: default: break; 
> } } while (0)
> 
> /* max value for numeric network address */
> #define MAX_NUMERIC_VALUE 0x
> -- 
> 2.9.0
> 

Cheers, Andreas
--
Andreas Dilger
Lustre Principal Architect
Intel Corporation

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

[Michael Schmitz]

Hi Finn,


Am 01.02.2017 um 21:40 schrieb Finn Thain:
> 
> On Fri, 27 Jan 2017, Michael Schmitz wrote:
> 
>> Am 26.01.2017 um 21:47 schrieb Finn Thain:
>>
>>> This would imply CPU overhead that is half of that which mac_scsi 
>>> incurs. That's the best case, but I see no reason to expect worse 
>>> performance than PDMA gets.
>>
>> But how much more overhead would we have compared to using the SCSI 
>> interrupt to signal DMA completion?
>>
> 
> I imagine that contention for the CPU bus would be a problem if we polled 
> the interrupt flag without any delay between iterations. With a small 
> delay I think the overhead would be comparable with PDMA and therefore 
> tolerable.

The first delay can even be quite long, estimated based on the transfer
size.

>> Since IDE does not use the ST-DMA and does not share any registers with 
>> ST-DMA, peeking at the IDE status register in order to decide whether 
>> the interrupt was raised by the IDE interface won't hurt the running DMA 
>> process (regardless of whether FDC or SCSI started it). Nor will 
>> servicing the IDE interrupt.
>>
> 
> Maybe we can just call the IDE handler from the ST-DMA handler regardless 
> of the status register. For a shared interrupt handler this should work 
> okay. (BTW, where is the IDE status register found anyway?)

We could do that as well, true. Easier to implement on the quick.

>> If at the end of the IDE interrupt processing the interrupt status is 
>> cleared in the IDE interface, the interrupt line should go high again 
>> before the IDE inthandler returns.
>>
> 
> On page 2 of the schematic, MFP pin I5 is wired to the output of the 
> logical OR combination of the IDEIRQ and XDISKINT signals (actually 
> active-low signals fed into an AND gate). The pin is edge-triggered.
> 
> This is just like the wired-OR Nubus slot IRQs connected to the Mac's VIA 
> pin. The handler must ack all asserted IRQs. Otherwise there will be no 
> more edges and no more interrupts.

Quite right - that's why I mentioned monitoring the IRQ signal status in
the GPIO register.

> This means looping over the IDE, FDC/SCSI DMA handlers until they all 
> return IRQ_NONE. (Or equivalently, looping over the IRQ flags in the 
> device registers until they are all de-asserted.)

Looping over the handlers risks stopping the DMA without need (except
for IDE).

> BTW, this makes me think that the stdma.c mechanism is already flawed, 
> since stdma_int() can cause only one of IDEIRQ and XDISKINT to become 
> inactive, but not both. That's fine as long as no device raises IRQ until 
> it's driver acquires the stdma lock -- but we know this is not true for 
> the 5380 bus reset interrupt and it isn't true for IDE devices either 
> (based on Geert's email in this thread).

The initial bus reset code had safeguards against raising an interrupt -
the IRQ was 'turned off' while the bus reset was executed. Maybe we need
something like that, at least in the case where SCSI does not hold the
ST-DMA lock.

>> If we can ensure that the FDC/SCSI interrupt handler runs after the IDE 
>> handler, we can then make that handler check the interrupt line status 
>> and bail out if there's nothing to be done. (For the sake of simplicity, 
>> this check can be done in stdma_int() since we need to retain mutual 
>> locking of the DMA interface by SCSI and FDC anyway.)
>>
>> We can ensure the IDE interrupt is called first by using a special 
>> interrupt controller to register separate IDE and FDC/SCSI interrupts 
>> with (I've done that to provide distinct interrupt numbers and handlers 
>> for the timer D interrupt that's used to poll ethernet and USB interface 
>> status on the ROM port).
>>
>> That way, we can ensure IDE interrupts do not step on the ST-DMA state, 
>> and all that remains are premature SCSI interrupts terminating DMA 
>> transfer (which we already face anyway).
>>
>> Am I missing a potential race here? Does IDE send the next request off 
>> to the disk from inside the interrupt handler so we could see IDE 
>> immediately raise the next interrupt?  In that case, we'd also need to 
>> check the IDE interrupt status in the interface status register, and 
>> bail out for another pass through the IDE/FDC/SCSI handlers until IDE is 
>> no longer posting an interrupt...
>>
> 
> I don't know anything about IDE so I can't comment on this particular 
> scenario (IDE interrupt handler causing IDE interrupt). The race condition 
> may be only theoretical.
> 
> What you seem to be aiming at is an algorithm to ensure that no DMA 
> interrupt is handled whilst an IDE interrupt is pending. Taking into 

Whilst the IDE interrupt is the only one pending, to be precise.

> account the logical OR issue, one could imagine a handler for the 
> IRQ_MFP_FSCSI interrupt something like the following. (This code is 
> probably useless for implementing your interrupt controller, but I hope it 
> illustrates some of the issues.)
> 
>   do {
>   handled = 

Re: [PATCH 0/3] ata: add m68k/Atari Falcon PATA support

[Michael Schmitz]

Hi Finn,


Am 01.02.2017 um 21:40 schrieb Finn Thain:
> 
> On Fri, 27 Jan 2017, Michael Schmitz wrote:
> 
>> Am 26.01.2017 um 21:47 schrieb Finn Thain:
>>
>>> This would imply CPU overhead that is half of that which mac_scsi 
>>> incurs. That's the best case, but I see no reason to expect worse 
>>> performance than PDMA gets.
>>
>> But how much more overhead would we have compared to using the SCSI 
>> interrupt to signal DMA completion?
>>
> 
> I imagine that contention for the CPU bus would be a problem if we polled 
> the interrupt flag without any delay between iterations. With a small 
> delay I think the overhead would be comparable with PDMA and therefore 
> tolerable.

The first delay can even be quite long, estimated based on the transfer
size.

>> Since IDE does not use the ST-DMA and does not share any registers with 
>> ST-DMA, peeking at the IDE status register in order to decide whether 
>> the interrupt was raised by the IDE interface won't hurt the running DMA 
>> process (regardless of whether FDC or SCSI started it). Nor will 
>> servicing the IDE interrupt.
>>
> 
> Maybe we can just call the IDE handler from the ST-DMA handler regardless 
> of the status register. For a shared interrupt handler this should work 
> okay. (BTW, where is the IDE status register found anyway?)

We could do that as well, true. Easier to implement on the quick.

>> If at the end of the IDE interrupt processing the interrupt status is 
>> cleared in the IDE interface, the interrupt line should go high again 
>> before the IDE inthandler returns.
>>
> 
> On page 2 of the schematic, MFP pin I5 is wired to the output of the 
> logical OR combination of the IDEIRQ and XDISKINT signals (actually 
> active-low signals fed into an AND gate). The pin is edge-triggered.
> 
> This is just like the wired-OR Nubus slot IRQs connected to the Mac's VIA 
> pin. The handler must ack all asserted IRQs. Otherwise there will be no 
> more edges and no more interrupts.

Quite right - that's why I mentioned monitoring the IRQ signal status in
the GPIO register.

> This means looping over the IDE, FDC/SCSI DMA handlers until they all 
> return IRQ_NONE. (Or equivalently, looping over the IRQ flags in the 
> device registers until they are all de-asserted.)

Looping over the handlers risks stopping the DMA without need (except
for IDE).

> BTW, this makes me think that the stdma.c mechanism is already flawed, 
> since stdma_int() can cause only one of IDEIRQ and XDISKINT to become 
> inactive, but not both. That's fine as long as no device raises IRQ until 
> it's driver acquires the stdma lock -- but we know this is not true for 
> the 5380 bus reset interrupt and it isn't true for IDE devices either 
> (based on Geert's email in this thread).

The initial bus reset code had safeguards against raising an interrupt -
the IRQ was 'turned off' while the bus reset was executed. Maybe we need
something like that, at least in the case where SCSI does not hold the
ST-DMA lock.

>> If we can ensure that the FDC/SCSI interrupt handler runs after the IDE 
>> handler, we can then make that handler check the interrupt line status 
>> and bail out if there's nothing to be done. (For the sake of simplicity, 
>> this check can be done in stdma_int() since we need to retain mutual 
>> locking of the DMA interface by SCSI and FDC anyway.)
>>
>> We can ensure the IDE interrupt is called first by using a special 
>> interrupt controller to register separate IDE and FDC/SCSI interrupts 
>> with (I've done that to provide distinct interrupt numbers and handlers 
>> for the timer D interrupt that's used to poll ethernet and USB interface 
>> status on the ROM port).
>>
>> That way, we can ensure IDE interrupts do not step on the ST-DMA state, 
>> and all that remains are premature SCSI interrupts terminating DMA 
>> transfer (which we already face anyway).
>>
>> Am I missing a potential race here? Does IDE send the next request off 
>> to the disk from inside the interrupt handler so we could see IDE 
>> immediately raise the next interrupt?  In that case, we'd also need to 
>> check the IDE interrupt status in the interface status register, and 
>> bail out for another pass through the IDE/FDC/SCSI handlers until IDE is 
>> no longer posting an interrupt...
>>
> 
> I don't know anything about IDE so I can't comment on this particular 
> scenario (IDE interrupt handler causing IDE interrupt). The race condition 
> may be only theoretical.
> 
> What you seem to be aiming at is an algorithm to ensure that no DMA 
> interrupt is handled whilst an IDE interrupt is pending. Taking into 

Whilst the IDE interrupt is the only one pending, to be precise.

> account the logical OR issue, one could imagine a handler for the 
> IRQ_MFP_FSCSI interrupt something like the following. (This code is 
> probably useless for implementing your interrupt controller, but I hope it 
> illustrates some of the issues.)
> 
>   do {
>   handled = 

Re: [PATCH 09/33] Input: sun4i-lradc-keys - Drop unnecessary call to platform_set_drvdata and other changes

[Chen-Yu Tsai]

On Thu, Jan 19, 2017 at 1:46 AM, Guenter Roeck  wrote:
> There is no call to platform_get_drvdata() or dev_get_drvdata().
> Drop the unnecessary call to platform_set_drvdata().
> Other relevant changes:
>   Simplify error return
>
> This conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts
> used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Replace 'if (e) return e; return 0;' with 'return e;'
> - Drop platform_set_drvdata()
>
> Signed-off-by: Guenter Roeck 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 09/33] Input: sun4i-lradc-keys - Drop unnecessary call to platform_set_drvdata and other changes

[Chen-Yu Tsai]

On Thu, Jan 19, 2017 at 1:46 AM, Guenter Roeck  wrote:
> There is no call to platform_get_drvdata() or dev_get_drvdata().
> Drop the unnecessary call to platform_set_drvdata().
> Other relevant changes:
>   Simplify error return
>
> This conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts
> used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Replace 'if (e) return e; return 0;' with 'return e;'
> - Drop platform_set_drvdata()
>
> Signed-off-by: Guenter Roeck 

Acked-by: Chen-Yu Tsai 

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

[hpa]

On February 1, 2017 11:16:00 PM PST, Ingo Molnar  wrote:
>
>* Nicolas Iooss  wrote:
>
>> With %Ld, my compiler (gcc 6.3.1 on x86_64) complains:
>> 
>> arch/x86/tools/relocs.c:400:7: error: format ‘%Ld’ expects argument
>of
>> type ‘long long int’, but argument 2 has type ‘Elf64_Off {aka long
>> unsigned int}’ [-Werror=format=]
>
>How did it pick up that type as an 'unsigned long'? We have:
>
>  include/uapi/linux/elf.h:typedef __u64  Elf64_Off;
>
>Even user-space has it as a pure 64-bit type:
>
>  /usr/include/elf.h:typedef uint64_t Elf64_Off;
>
>Thanks,
>
>   Ingo

uint64_t is unsigned long on x86-64.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH 12/33] Input: axp20x-pek - Use devm_add_action_or_reset and other changes

[Chen-Yu Tsai]

On Thu, Jan 19, 2017 at 1:46 AM, Guenter Roeck  wrote:
> Replace devm_add_action() followed by failure action with
> devm_add_action_or_reset()
>
> This conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts
> used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Replace devm_add_action() followed by failure action with
>   devm_add_action_or_reset()
>
> Signed-off-by: Guenter Roeck 

Acked-by: Chen-Yu Tsai 

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

[hpa]

On February 1, 2017 11:16:00 PM PST, Ingo Molnar  wrote:
>
>* Nicolas Iooss  wrote:
>
>> With %Ld, my compiler (gcc 6.3.1 on x86_64) complains:
>> 
>> arch/x86/tools/relocs.c:400:7: error: format ‘%Ld’ expects argument
>of
>> type ‘long long int’, but argument 2 has type ‘Elf64_Off {aka long
>> unsigned int}’ [-Werror=format=]
>
>How did it pick up that type as an 'unsigned long'? We have:
>
>  include/uapi/linux/elf.h:typedef __u64  Elf64_Off;
>
>Even user-space has it as a pure 64-bit type:
>
>  /usr/include/elf.h:typedef uint64_t Elf64_Off;
>
>Thanks,
>
>   Ingo

uint64_t is unsigned long on x86-64.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [PATCH 12/33] Input: axp20x-pek - Use devm_add_action_or_reset and other changes

[Chen-Yu Tsai]

On Thu, Jan 19, 2017 at 1:46 AM, Guenter Roeck  wrote:
> Replace devm_add_action() followed by failure action with
> devm_add_action_or_reset()
>
> This conversion was done automatically with coccinelle using the
> following semantic patches. The semantic patches and the scripts
> used to generate this commit log are available at
> https://github.com/groeck/coccinelle-patches
>
> - Replace devm_add_action() followed by failure action with
>   devm_add_action_or_reset()
>
> Signed-off-by: Guenter Roeck 

Acked-by: Chen-Yu Tsai 

Re: crash in perf_event_read

[David Carrillo-Cisneros]

On Tue, Jan 31, 2017 at 2:27 AM, Peter Zijlstra  wrote:
> On Mon, Jan 30, 2017 at 11:04:08PM -0800, Alexei Starovoitov wrote:
>> Hi Peter,
>>
>> rarely I'm seeing the following crash:
>> [40196.164255] BUG: unable to handle kernel paging request at 
>> a11a
>> [40196.179636] IP: perf_event_read+0xd3/0x1a0
>> [40196.188669] PGD 82e93a067
>> [40196.188670] PUD 7e1ddf067
>> [40196.194629] PMD 0
>> [40196.200589]
>> [40196.208284] Oops:  [#1] SMP
>> [40196.208285] Modules linked in:
>> [40196.208299] CPU: 24 PID: 4423 Comm: dynoKernelMon Not tainted 
>> 4.10.0-rc5-01189-gc6e0ad0ee5b0 #599
>> [40196.208300] Hardware name: Quanta Mono Lake-M.2 SATA 20F20BU0270/Mono 
>> Lake-M.2 SATA, BIOS F20_3A12 10/24/2016
>> [40196.208301] task: 8807e3b65580 task.stack: c90009748000
>> [40196.208302] RIP: 0010:perf_event_read+0xd3/0x1a0
>> [40196.208303] RSP: 0018:c9000974bd48 EFLAGS: 00010202
>> [40196.208304] RAX: a040 RBX: 8807b79fd000 RCX: 
>> 
>> [40196.208304] RDX: 0018 RSI:  RDI: 
>> 
>> [40196.208305] RBP: c9000974bd80 R08:  R09: 
>> 
>> [40196.208305] R10: 8807cf8c7038 R11:  R12: 
>> c9000974bde8
>> [40196.208306] R13:  R14: 8807b79fd000 R15: 
>> 04e0
>> [40196.208307] FS:  7ff1b45ff700() GS:88085f40() 
>> knlGS:
>> [40196.208307] CS:  0010 DS:  ES:  CR0: 80050033
>> [40196.208308] CR2: a11a CR3: 000850298000 CR4: 
>> 003406e0
>> [40196.208308] DR0:  DR1:  DR2: 
>> 
>> [40196.208309] DR3:  DR6: fffe0ff0 DR7: 
>> 0400
>> [40196.208309] Call Trace:
>> [40196.208313]  ? __might_sleep+0x4a/0x80
>> [40196.208316]  perf_event_read_value+0x45/0x130
>> [40196.208318]  perf_read+0x84/0x2d0
>> [40196.208322]  __vfs_read+0x28/0x110
>> [40196.208325]  ? security_file_permission+0x9b/0xc0
>> [40196.208327]  vfs_read+0xa5/0x170
>> [40196.208327]  SyS_read+0x46/0xa0
>> [40196.208329]  do_syscall_64+0x4d/0xb0
>> [40196.208332]  entry_SYSCALL64_slow_path+0x25/0x25
>> [40196.208333] RIP: 0033:0x7ff1b6f5716d
>> [40196.208334] RSP: 002b:7ff1b45fd080 EFLAGS: 0293 ORIG_RAX: 
>> 
>> [40196.208335] RAX: ffda RBX:  RCX: 
>> 7ff1b6f5716d
>> [40196.208335] RDX: 0020 RSI: 7ff1b45fd090 RDI: 
>> 0054
>> [40196.208336] RBP: 7ff1b45fd0e0 R08: 7ff1b65e45c0 R09: 
>> 7ff1b45fc9b1
>> [40196.208336] R10: 0020 R11: 0293 R12: 
>> 
>> [40196.208337] R13: 7ff1b5687000 R14: 0004a817c7fe R15: 
>> 04e0
>> [40196.208337] Code: 60 02 00 00 74 30 48 63 cf 48 c7 c0 40 a0 00 00 48 8b 
>> 34 cd c0 93 d0 81 48 63 ca 48 8b 0c cd c0 93 d0 81 0f b7 8c 08 da 00 00 00 
>> <66> 39 8c 30 da 00 00 00 0f 44 fa 48 8d 55 d0 b9 01 00 00 00 48
>> [40196.208353] RIP: perf_event_read+0xd3/0x1a0 RSP: c9000974bd48
>> [40196.208353] CR2: a11a
>>
>> The RIP points to this asm:
>>0x8115fc9b <+155>:   mov%gs:0x7eeaa486(%rip),%edx# 
>> 0xa128 
>>0x8115fca2 <+162>:   testb  $0x2,0x68(%rbx)
>>0x8115fca6 <+166>:   mov0x260(%rdi),%edi
>>0x8115fcac <+172>:   je 0x8115fcde 
>> 
>>0x8115fcae <+174>:   movslq %edi,%rcx
>>0x8115fcb1 <+177>:   mov$0xa040,%rax
>>0x8115fcb8 <+184>:   mov-0x7e2f6c40(,%rcx,8),%rsi
>>0x8115fcc0 <+192>:   movslq %edx,%rcx
>>0x8115fcc3 <+195>:   mov-0x7e2f6c40(,%rcx,8),%rcx
>>0x8115fccb <+203>:   movzwl 0xda(%rax,%rcx,1),%ecx
>>0x8115fcd3 <+211>:   cmp%cx,0xda(%rax,%rsi,1)
>>
>> which is this C code:
>> perf_event_read():
>>   local_cpu = get_cpu();
>>   cpu_to_read = find_cpu_to_read(event, local_cpu);
>>   put_cpu();
>>
>> find_cpu_to_read():
>>   event_pkg =  topology_physical_package_id(event_cpu);
>>   local_pkg =  topology_physical_package_id(local_cpu);
>>   if (event_pkg == local_pkg)
>>
>> If I read the asm correctly at the time of the crash
>> event_cpu == RDI == 
>> or in other words event->oncpu == -1
>> which I think is technically possible here.
>>
>> Any suggestions how to fix this?
>> Happy to test any patches, though I don't know how to reproduce reliably.
>
> Right you are, that's buggered.
>
> Something like the below (compile tested only) ought to cure things I
> think.
>
> ---
> Subject: perf: Fix crash in perf_event_read()
>
> Alexei had his box explode because doing read() on a package
> (rapl/uncore) event that isn't currently scheduled in ends up doing an
> out-of-bounds load.
>
> Rework the code to more explicitly deal with event->oncpu being -1.
>
Tested-by: David Carrillo-Cisneros 

Re: crash in perf_event_read

[David Carrillo-Cisneros]

On Tue, Jan 31, 2017 at 2:27 AM, Peter Zijlstra  wrote:
> On Mon, Jan 30, 2017 at 11:04:08PM -0800, Alexei Starovoitov wrote:
>> Hi Peter,
>>
>> rarely I'm seeing the following crash:
>> [40196.164255] BUG: unable to handle kernel paging request at 
>> a11a
>> [40196.179636] IP: perf_event_read+0xd3/0x1a0
>> [40196.188669] PGD 82e93a067
>> [40196.188670] PUD 7e1ddf067
>> [40196.194629] PMD 0
>> [40196.200589]
>> [40196.208284] Oops:  [#1] SMP
>> [40196.208285] Modules linked in:
>> [40196.208299] CPU: 24 PID: 4423 Comm: dynoKernelMon Not tainted 
>> 4.10.0-rc5-01189-gc6e0ad0ee5b0 #599
>> [40196.208300] Hardware name: Quanta Mono Lake-M.2 SATA 20F20BU0270/Mono 
>> Lake-M.2 SATA, BIOS F20_3A12 10/24/2016
>> [40196.208301] task: 8807e3b65580 task.stack: c90009748000
>> [40196.208302] RIP: 0010:perf_event_read+0xd3/0x1a0
>> [40196.208303] RSP: 0018:c9000974bd48 EFLAGS: 00010202
>> [40196.208304] RAX: a040 RBX: 8807b79fd000 RCX: 
>> 
>> [40196.208304] RDX: 0018 RSI:  RDI: 
>> 
>> [40196.208305] RBP: c9000974bd80 R08:  R09: 
>> 
>> [40196.208305] R10: 8807cf8c7038 R11:  R12: 
>> c9000974bde8
>> [40196.208306] R13:  R14: 8807b79fd000 R15: 
>> 04e0
>> [40196.208307] FS:  7ff1b45ff700() GS:88085f40() 
>> knlGS:
>> [40196.208307] CS:  0010 DS:  ES:  CR0: 80050033
>> [40196.208308] CR2: a11a CR3: 000850298000 CR4: 
>> 003406e0
>> [40196.208308] DR0:  DR1:  DR2: 
>> 
>> [40196.208309] DR3:  DR6: fffe0ff0 DR7: 
>> 0400
>> [40196.208309] Call Trace:
>> [40196.208313]  ? __might_sleep+0x4a/0x80
>> [40196.208316]  perf_event_read_value+0x45/0x130
>> [40196.208318]  perf_read+0x84/0x2d0
>> [40196.208322]  __vfs_read+0x28/0x110
>> [40196.208325]  ? security_file_permission+0x9b/0xc0
>> [40196.208327]  vfs_read+0xa5/0x170
>> [40196.208327]  SyS_read+0x46/0xa0
>> [40196.208329]  do_syscall_64+0x4d/0xb0
>> [40196.208332]  entry_SYSCALL64_slow_path+0x25/0x25
>> [40196.208333] RIP: 0033:0x7ff1b6f5716d
>> [40196.208334] RSP: 002b:7ff1b45fd080 EFLAGS: 0293 ORIG_RAX: 
>> 
>> [40196.208335] RAX: ffda RBX:  RCX: 
>> 7ff1b6f5716d
>> [40196.208335] RDX: 0020 RSI: 7ff1b45fd090 RDI: 
>> 0054
>> [40196.208336] RBP: 7ff1b45fd0e0 R08: 7ff1b65e45c0 R09: 
>> 7ff1b45fc9b1
>> [40196.208336] R10: 0020 R11: 0293 R12: 
>> 
>> [40196.208337] R13: 7ff1b5687000 R14: 0004a817c7fe R15: 
>> 04e0
>> [40196.208337] Code: 60 02 00 00 74 30 48 63 cf 48 c7 c0 40 a0 00 00 48 8b 
>> 34 cd c0 93 d0 81 48 63 ca 48 8b 0c cd c0 93 d0 81 0f b7 8c 08 da 00 00 00 
>> <66> 39 8c 30 da 00 00 00 0f 44 fa 48 8d 55 d0 b9 01 00 00 00 48
>> [40196.208353] RIP: perf_event_read+0xd3/0x1a0 RSP: c9000974bd48
>> [40196.208353] CR2: a11a
>>
>> The RIP points to this asm:
>>0x8115fc9b <+155>:   mov%gs:0x7eeaa486(%rip),%edx# 
>> 0xa128 
>>0x8115fca2 <+162>:   testb  $0x2,0x68(%rbx)
>>0x8115fca6 <+166>:   mov0x260(%rdi),%edi
>>0x8115fcac <+172>:   je 0x8115fcde 
>> 
>>0x8115fcae <+174>:   movslq %edi,%rcx
>>0x8115fcb1 <+177>:   mov$0xa040,%rax
>>0x8115fcb8 <+184>:   mov-0x7e2f6c40(,%rcx,8),%rsi
>>0x8115fcc0 <+192>:   movslq %edx,%rcx
>>0x8115fcc3 <+195>:   mov-0x7e2f6c40(,%rcx,8),%rcx
>>0x8115fccb <+203>:   movzwl 0xda(%rax,%rcx,1),%ecx
>>0x8115fcd3 <+211>:   cmp%cx,0xda(%rax,%rsi,1)
>>
>> which is this C code:
>> perf_event_read():
>>   local_cpu = get_cpu();
>>   cpu_to_read = find_cpu_to_read(event, local_cpu);
>>   put_cpu();
>>
>> find_cpu_to_read():
>>   event_pkg =  topology_physical_package_id(event_cpu);
>>   local_pkg =  topology_physical_package_id(local_cpu);
>>   if (event_pkg == local_pkg)
>>
>> If I read the asm correctly at the time of the crash
>> event_cpu == RDI == 
>> or in other words event->oncpu == -1
>> which I think is technically possible here.
>>
>> Any suggestions how to fix this?
>> Happy to test any patches, though I don't know how to reproduce reliably.
>
> Right you are, that's buggered.
>
> Something like the below (compile tested only) ought to cure things I
> think.
>
> ---
> Subject: perf: Fix crash in perf_event_read()
>
> Alexei had his box explode because doing read() on a package
> (rapl/uncore) event that isn't currently scheduled in ends up doing an
> out-of-bounds load.
>
> Rework the code to more explicitly deal with event->oncpu being -1.
>
Tested-by: David Carrillo-Cisneros 
> Reported-by: Alexei Starovoitov 
> Cc: David 

Re: [PATCH v2 00/10] serial: st-asc: Allow handling of RTS line

[Lee Jones]

Hi Greg, Jiri,

> When hardware flow-control is disabled, manual toggling of the UART's
> reset line (RTS) using userland applications (e.g. stty) is not
> possible, since the ASC IP does not provide this functionality in the
> same was as some other IPs do.  Thus, we have to do this manually.
> 
> This set ensures the correct Pinctrl groups are configured and
> obtained for both manual toggling of the RTS line and for the IP to
> take over the lines when HW flow-control is requested by the user. 
> 
> Lee Jones (10):
>   serial: st-asc: Ignore the parity error bit if 8-bit mode is enabled
>   serial: st-asc: Provide RTS functionality
>   serial: st-asc: Read in all Pinctrl states
>   serial: st-asc: (De)Register GPIOD and swap Pinctrl profiles
>   serial: st-asc: Use generic DT binding for announcing RTS/CTS lines
>   dt-bindings: serial: Update 'uart-has-rtscts' description
>   ARM: dts: STiH410-b2260: Identify the UART RTS line
>   ARM: dts: STiH407-pinctrl: Add Pinctrl group for HW flow-control
>   ARM: dts: STiH407-family: Use new Pinctrl groups
>   ARM: dts: STiH410-b2260: Enable HW flow-control
> 
>  .../devicetree/bindings/serial/serial.txt  |   3 +-
>  arch/arm/boot/dts/stih407-family.dtsi  |   3 +-
>  arch/arm/boot/dts/stih407-pinctrl.dtsi |  12 ++-
>  arch/arm/boot/dts/stih410-b2260.dts|   5 +
>  drivers/tty/serial/st-asc.c| 101 
> +++--
>  5 files changed, 110 insertions(+), 14 deletions(-)

Looks like everyone is happy with the set.

Are you planning to merge it?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH v2 00/10] serial: st-asc: Allow handling of RTS line

[Lee Jones]

Hi Greg, Jiri,

> When hardware flow-control is disabled, manual toggling of the UART's
> reset line (RTS) using userland applications (e.g. stty) is not
> possible, since the ASC IP does not provide this functionality in the
> same was as some other IPs do.  Thus, we have to do this manually.
> 
> This set ensures the correct Pinctrl groups are configured and
> obtained for both manual toggling of the RTS line and for the IP to
> take over the lines when HW flow-control is requested by the user. 
> 
> Lee Jones (10):
>   serial: st-asc: Ignore the parity error bit if 8-bit mode is enabled
>   serial: st-asc: Provide RTS functionality
>   serial: st-asc: Read in all Pinctrl states
>   serial: st-asc: (De)Register GPIOD and swap Pinctrl profiles
>   serial: st-asc: Use generic DT binding for announcing RTS/CTS lines
>   dt-bindings: serial: Update 'uart-has-rtscts' description
>   ARM: dts: STiH410-b2260: Identify the UART RTS line
>   ARM: dts: STiH407-pinctrl: Add Pinctrl group for HW flow-control
>   ARM: dts: STiH407-family: Use new Pinctrl groups
>   ARM: dts: STiH410-b2260: Enable HW flow-control
> 
>  .../devicetree/bindings/serial/serial.txt  |   3 +-
>  arch/arm/boot/dts/stih407-family.dtsi  |   3 +-
>  arch/arm/boot/dts/stih407-pinctrl.dtsi |  12 ++-
>  arch/arm/boot/dts/stih410-b2260.dts|   5 +
>  drivers/tty/serial/st-asc.c| 101 
> +++--
>  5 files changed, 110 insertions(+), 14 deletions(-)

Looks like everyone is happy with the set.

Are you planning to merge it?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 5/5] ARM: dts: sun9i: Initial support for the Sunchip CX-A99 board

[Chen-Yu Tsai]

Hi,

On Fri, Jan 27, 2017 at 5:27 AM, Rask Ingemann Lambertsen
 wrote:
> The Suncip CX-A99 board is found in at least four brands of media players.
> It features an Allwinner A80 ARM SoC and is found in two models:
>
> 1) 2 GiB DDR3 DRAM and 16 GB eMMC
> 2) 4 GiB DDR3 DRAM and 32 GB eMMC
>
> For details of the board, see the linux-sunxi page
> .
>
> Supported features (+ means tested):
> + One Cortex-A7 CPU core
> + AXP808 power management chip
> + OZ80120 voltage regulator
> + Serial console port (internal)
> + eMMC and SD card slot
> + USB 2.0 host ports on on-board USB hub
> + SATA port on on-board SATA-to-USB bridge *
> + IEEE 802.11 a/b/g/n/ac SDIO Wifi
> + Real-time clock
> + LEDs
> - IR receiver for remote control
>
> * In addition to connecting a SATA device, some unknown magic is necessary
>   after power-up to get the SATA-to-USB bridge to show up on the USB bus.
>   As a workaround, run the vendor U-Boot once after power-up.
>
> So far unsupported features:
> - Using more than one CPU core or any of the Cortex-A15 CPU cores
> - USB 3.0 OTG port (except for supplying 5V power)
> - IEEE 802.3 10/100/1000 megabit Ethernet
> - HDMI connector
> - SPDIF audio output
> - Jack socket with composite video and analog stereo audio
> - Bluetooth
> - FM radio receiver (assuming it is even wired on the board)
>
> Signed-off-by: Rask Ingemann Lambertsen 
> ---
>
> Changes in v5:
> - Switched pinmux modes to generic properties and dropped
>   #include  as a consequence.
> - Dropped pinctrl properties from GPIO nodes and dropped the pinmux
>   nodes for them.
> - AXP808 regulators added.
> - Dropped the now unused #include .
> - Ampak AP6335 SDIO-Wifi added.
> - USB Vbus changes as per v4 comments.
> - Added "broken-cd" to mmc0 because GPIO interrupts don't work.
>
> Changes in v4:
> - Node names had underscores changed to hyphens.
> - Changed formatting of the ac100/rtc node's clock output name list to match
>  that of the same node in the cubieboard4 and a80-optimus device trees.
>
> Changes in v3:
> None.
>
> Changes in v2:
> - Fixed formatting and style issues found by scripts/checkpatch.pl.
>
>  arch/arm/boot/dts/Makefile |   3 +-
>  arch/arm/boot/dts/sun9i-a80-cx-a99.dts | 413 
> +
>  2 files changed, 415 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/sun9i-a80-cx-a99.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index e7994df..d9f47e1 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -859,7 +859,8 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> sun8i-r16-parrot.dtb
>  dtb-$(CONFIG_MACH_SUN9I) += \
> sun9i-a80-optimus.dtb \
> -   sun9i-a80-cubieboard4.dtb
> +   sun9i-a80-cubieboard4.dtb \
> +   sun9i-a80-cx-a99.dtb
>  dtb-$(CONFIG_ARCH_TANGO) += \
> tango4-vantage-1172.dtb
>  dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \
> diff --git a/arch/arm/boot/dts/sun9i-a80-cx-a99.dts 
> b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
> new file mode 100644
> index 000..8925093
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
> @@ -0,0 +1,413 @@
> +/*
> + * sun9i-a80-cx-a99.dts - Device Tree file for the Sunchip CX-A99 board.
> + *
> + * Copyright (C) 2017 Rask Ingemann Lambertsen 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, 

Re: [PATCH 5/5] ARM: dts: sun9i: Initial support for the Sunchip CX-A99 board

[Chen-Yu Tsai]

Hi,

On Fri, Jan 27, 2017 at 5:27 AM, Rask Ingemann Lambertsen
 wrote:
> The Suncip CX-A99 board is found in at least four brands of media players.
> It features an Allwinner A80 ARM SoC and is found in two models:
>
> 1) 2 GiB DDR3 DRAM and 16 GB eMMC
> 2) 4 GiB DDR3 DRAM and 32 GB eMMC
>
> For details of the board, see the linux-sunxi page
> https://linux-sunxi.org/Sunchip_CX-A99>.
>
> Supported features (+ means tested):
> + One Cortex-A7 CPU core
> + AXP808 power management chip
> + OZ80120 voltage regulator
> + Serial console port (internal)
> + eMMC and SD card slot
> + USB 2.0 host ports on on-board USB hub
> + SATA port on on-board SATA-to-USB bridge *
> + IEEE 802.11 a/b/g/n/ac SDIO Wifi
> + Real-time clock
> + LEDs
> - IR receiver for remote control
>
> * In addition to connecting a SATA device, some unknown magic is necessary
>   after power-up to get the SATA-to-USB bridge to show up on the USB bus.
>   As a workaround, run the vendor U-Boot once after power-up.
>
> So far unsupported features:
> - Using more than one CPU core or any of the Cortex-A15 CPU cores
> - USB 3.0 OTG port (except for supplying 5V power)
> - IEEE 802.3 10/100/1000 megabit Ethernet
> - HDMI connector
> - SPDIF audio output
> - Jack socket with composite video and analog stereo audio
> - Bluetooth
> - FM radio receiver (assuming it is even wired on the board)
>
> Signed-off-by: Rask Ingemann Lambertsen 
> ---
>
> Changes in v5:
> - Switched pinmux modes to generic properties and dropped
>   #include  as a consequence.
> - Dropped pinctrl properties from GPIO nodes and dropped the pinmux
>   nodes for them.
> - AXP808 regulators added.
> - Dropped the now unused #include .
> - Ampak AP6335 SDIO-Wifi added.
> - USB Vbus changes as per v4 comments.
> - Added "broken-cd" to mmc0 because GPIO interrupts don't work.
>
> Changes in v4:
> - Node names had underscores changed to hyphens.
> - Changed formatting of the ac100/rtc node's clock output name list to match
>  that of the same node in the cubieboard4 and a80-optimus device trees.
>
> Changes in v3:
> None.
>
> Changes in v2:
> - Fixed formatting and style issues found by scripts/checkpatch.pl.
>
>  arch/arm/boot/dts/Makefile |   3 +-
>  arch/arm/boot/dts/sun9i-a80-cx-a99.dts | 413 
> +
>  2 files changed, 415 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/boot/dts/sun9i-a80-cx-a99.dts
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index e7994df..d9f47e1 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -859,7 +859,8 @@ dtb-$(CONFIG_MACH_SUN8I) += \
> sun8i-r16-parrot.dtb
>  dtb-$(CONFIG_MACH_SUN9I) += \
> sun9i-a80-optimus.dtb \
> -   sun9i-a80-cubieboard4.dtb
> +   sun9i-a80-cubieboard4.dtb \
> +   sun9i-a80-cx-a99.dtb
>  dtb-$(CONFIG_ARCH_TANGO) += \
> tango4-vantage-1172.dtb
>  dtb-$(CONFIG_ARCH_TEGRA_2x_SOC) += \
> diff --git a/arch/arm/boot/dts/sun9i-a80-cx-a99.dts 
> b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
> new file mode 100644
> index 000..8925093
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun9i-a80-cx-a99.dts
> @@ -0,0 +1,413 @@
> +/*
> + * sun9i-a80-cx-a99.dts - Device Tree file for the Sunchip CX-A99 board.
> + *
> + * Copyright (C) 2017 Rask Ingemann Lambertsen 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF 

Re: [PATCH v5 1/4] mm/migration: make isolate_movable_page() return int type

[Minchan Kim]

On Wed, Feb 01, 2017 at 11:00:23AM +0100, Michal Hocko wrote:
> On Wed 01-02-17 18:46:36, Minchan Kim wrote:
> > On Wed, Feb 01, 2017 at 08:59:24AM +0100, Michal Hocko wrote:
> > > On Wed 01-02-17 15:48:21, Minchan Kim wrote:
> > > > Hi Yisheng,
> > > > 
> > > > On Tue, Jan 31, 2017 at 09:06:18PM +0800, ys...@foxmail.com wrote:
> > > > > From: Yisheng Xie 
> > > > > 
> > > > > This patch changes the return type of isolate_movable_page()
> > > > > from bool to int. It will return 0 when isolate movable page
> > > > > successfully, return -EINVAL when the page is not a non-lru movable
> > > > > page, and for other cases it will return -EBUSY.
> > > > > 
> > > > > There is no functional change within this patch but prepare
> > > > > for later patch.
> > > > > 
> > > > > Signed-off-by: Yisheng Xie 
> > > > > Suggested-by: Michal Hocko 
> > > > 
> > > > Sorry for missing this one you guys were discussing.
> > > > I don't understand the patch's goal although I read later patches.
> > > 
> > > The point is that the failed isolation has to propagate error up the
> > > call chain to the userspace which has initiated the migration.
> > > 
> > > > isolate_movable_pages returns success/fail so that's why I selected
> > > > bool rather than int but it seems you guys want to propagate more
> > > > detailed error to the user so added -EBUSY and -EINVAL.
> > > > 
> > > > But the question is why isolate_lru_pages doesn't have -EINVAL?
> > > 
> > > It doesn't have to same as isolate_movable_pages. We should just return
> > > EBUSY when the page is no longer movable.
> > 
> > Why isolate_lru_page is okay to return -EBUSY in case of race while
> > isolate_movable_page should return -EINVAL?
> > What's the logic in your mind? I totally cannot understand.
> 
> Let me rephrase. Both should return EBUSY.

It means it's binary return value(success: 0 fail : -EBUSY) so IMO,
bool is better and caller should return -EBUSY if that functions
returns *false*. No need to make deeper propagation level.
Anyway, it's trivial so I'm not against it if you want to make
isolate_movable_page returns int. Insetad, please remove -EINVAL
in this patch and just return -EBUSY for isolate_movable_page to
be consistent with isolate_lru_page.
Then, we don't need to fix any driver side, either. Even, no need to
update any document because you don't add any new error value.

That's enough.

Re: [PATCH v5 1/4] mm/migration: make isolate_movable_page() return int type

[Minchan Kim]

On Wed, Feb 01, 2017 at 11:00:23AM +0100, Michal Hocko wrote:
> On Wed 01-02-17 18:46:36, Minchan Kim wrote:
> > On Wed, Feb 01, 2017 at 08:59:24AM +0100, Michal Hocko wrote:
> > > On Wed 01-02-17 15:48:21, Minchan Kim wrote:
> > > > Hi Yisheng,
> > > > 
> > > > On Tue, Jan 31, 2017 at 09:06:18PM +0800, ys...@foxmail.com wrote:
> > > > > From: Yisheng Xie 
> > > > > 
> > > > > This patch changes the return type of isolate_movable_page()
> > > > > from bool to int. It will return 0 when isolate movable page
> > > > > successfully, return -EINVAL when the page is not a non-lru movable
> > > > > page, and for other cases it will return -EBUSY.
> > > > > 
> > > > > There is no functional change within this patch but prepare
> > > > > for later patch.
> > > > > 
> > > > > Signed-off-by: Yisheng Xie 
> > > > > Suggested-by: Michal Hocko 
> > > > 
> > > > Sorry for missing this one you guys were discussing.
> > > > I don't understand the patch's goal although I read later patches.
> > > 
> > > The point is that the failed isolation has to propagate error up the
> > > call chain to the userspace which has initiated the migration.
> > > 
> > > > isolate_movable_pages returns success/fail so that's why I selected
> > > > bool rather than int but it seems you guys want to propagate more
> > > > detailed error to the user so added -EBUSY and -EINVAL.
> > > > 
> > > > But the question is why isolate_lru_pages doesn't have -EINVAL?
> > > 
> > > It doesn't have to same as isolate_movable_pages. We should just return
> > > EBUSY when the page is no longer movable.
> > 
> > Why isolate_lru_page is okay to return -EBUSY in case of race while
> > isolate_movable_page should return -EINVAL?
> > What's the logic in your mind? I totally cannot understand.
> 
> Let me rephrase. Both should return EBUSY.

It means it's binary return value(success: 0 fail : -EBUSY) so IMO,
bool is better and caller should return -EBUSY if that functions
returns *false*. No need to make deeper propagation level.
Anyway, it's trivial so I'm not against it if you want to make
isolate_movable_page returns int. Insetad, please remove -EINVAL
in this patch and just return -EBUSY for isolate_movable_page to
be consistent with isolate_lru_page.
Then, we don't need to fix any driver side, either. Even, no need to
update any document because you don't add any new error value.

That's enough.

Re: [PATCH 4/5] regulator: axp20x: Add support for the AXP808 PMIC

[Chen-Yu Tsai]

On Fri, Jan 27, 2017 at 7:42 PM, Mark Brown  wrote:
> On Thu, Jan 26, 2017 at 10:18:11PM +0100, Rask Ingemann Lambertsen wrote:
>> The regulators are the same as on the AXP806.
>
> Acked-by: Mark Brown 

Acked-by: Chen-Yu Tsai 

This probably needs to go in with the mfd patches adding the ID.

Re: [PATCH 4/5] regulator: axp20x: Add support for the AXP808 PMIC

[Chen-Yu Tsai]

On Fri, Jan 27, 2017 at 7:42 PM, Mark Brown  wrote:
> On Thu, Jan 26, 2017 at 10:18:11PM +0100, Rask Ingemann Lambertsen wrote:
>> The regulators are the same as on the AXP806.
>
> Acked-by: Mark Brown 

Acked-by: Chen-Yu Tsai 

This probably needs to go in with the mfd patches adding the ID.

Re: [PATCH 3/5] mfd: axp20x: Add support for the AXP808 PMIC

[Chen-Yu Tsai]

On Fri, Jan 27, 2017 at 5:25 AM, Rask Ingemann Lambertsen
 wrote:
> The X-Powers AXP808 is a PMIC which, like the very similar AXP806, is
> used on boards featuring Allwinner's A80 SoC. Unlike the AXP806, it
> doesn't support address space extension and its associated registers,
> but the two are otherwise identical (including the chip ID).
>
> This patch adds support for the interrupts on the AXP808 and enables
> the regulator sub-device. The next patch in the series adds the actual
> regulator support.
>
> Signed-off-by: Rask Ingemann Lambertsen 

Acked-by: Chen-Yu Tsai 

> ---
>  drivers/mfd/axp20x-rsb.c   |  1 +
>  drivers/mfd/axp20x.c   | 28 
>  include/linux/mfd/axp20x.h |  1 +
>  3 files changed, 30 insertions(+)
>
> diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
> index a732cb5..96ea2e9 100644
> --- a/drivers/mfd/axp20x-rsb.c
> +++ b/drivers/mfd/axp20x-rsb.c
> @@ -62,6 +62,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
>  static const struct of_device_id axp20x_rsb_of_match[] = {
> { .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
> { .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
> +   { .compatible = "x-powers,axp808", .data = (void *)AXP808_ID },
> { .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
> { },
>  };
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 25115fe..2d3383e 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
> "AXP223",
> "AXP288",
> "AXP806",
> +   "AXP808",
> "AXP809",
>  };
>
> @@ -148,6 +149,13 @@ static const struct regmap_range 
> axp806_writeable_ranges[] = {
> regmap_reg_range(AXP806_REG_ADDR_EXT, AXP806_REG_ADDR_EXT),
>  };
>
> +static const struct regmap_range axp808_writeable_ranges[] = {
> +   regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_DATACACHE(3)),
> +   regmap_reg_range(AXP806_PWR_OUT_CTRL1, AXP806_CLDO3_V_CTRL),
> +   regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ2_EN),
> +   regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE),
> +};
> +
>  static const struct regmap_range axp806_volatile_ranges[] = {
> regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE),
>  };
> @@ -162,6 +170,11 @@ static const struct regmap_access_table 
> axp806_volatile_table = {
> .n_yes_ranges   = ARRAY_SIZE(axp806_volatile_ranges),
>  };
>
> +static const struct regmap_access_table axp808_writeable_table = {
> +   .yes_ranges = axp808_writeable_ranges,
> +   .n_yes_ranges   = ARRAY_SIZE(axp808_writeable_ranges),

You could probably get away with using axp806_writeable_ranges,
and pass ARRAY_SIZE(axp808_writeable_ranges) - 1 for .n_yes_ranges.

Or maybe the compiler figures out the 2 arrays share common data.

ChenYu

> +};
> +
>  static struct resource axp152_pek_resources[] = {
> DEFINE_RES_IRQ_NAMED(AXP152_IRQ_PEK_RIS_EDGE, "PEK_DBR"),
> DEFINE_RES_IRQ_NAMED(AXP152_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
> @@ -320,6 +333,15 @@ static const struct regmap_config axp806_regmap_config = 
> {
> .cache_type = REGCACHE_RBTREE,
>  };
>
> +static const struct regmap_config axp808_regmap_config = {
> +   .reg_bits   = 8,
> +   .val_bits   = 8,
> +   .wr_table   = _writeable_table,
> +   .volatile_table = _volatile_table,
> +   .max_register   = AXP806_VREF_TEMP_WARN_L,
> +   .cache_type = REGCACHE_RBTREE,
> +};
> +
>  #define INIT_REGMAP_IRQ(_variant, _irq, _off, _mask)   \
> [_variant##_IRQ_##_irq] = { .reg_offset = (_off), .mask = BIT(_mask) }
>
> @@ -842,6 +864,12 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
> axp20x->regmap_cfg = _regmap_config;
> axp20x->regmap_irq_chip = _regmap_irq_chip;
> break;
> +   case AXP808_ID:
> +   axp20x->nr_cells = ARRAY_SIZE(axp806_cells);
> +   axp20x->cells = axp806_cells;
> +   axp20x->regmap_cfg = _regmap_config;
> +   axp20x->regmap_irq_chip = _regmap_irq_chip;
> +   break;
> case AXP809_ID:
> axp20x->nr_cells = ARRAY_SIZE(axp809_cells);
> axp20x->cells = axp809_cells;
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index 0aa4ef7..b9b7eae 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -21,6 +21,7 @@ enum {
> AXP223_ID,
> AXP288_ID,
> AXP806_ID,
> +   AXP808_ID,
> AXP809_ID,
> NR_AXP20X_VARIANTS,
>  };
> --
> 2.10.2
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] mfd: axp20x: Add support for the AXP808 PMIC

[Chen-Yu Tsai]

On Fri, Jan 27, 2017 at 5:25 AM, Rask Ingemann Lambertsen
 wrote:
> The X-Powers AXP808 is a PMIC which, like the very similar AXP806, is
> used on boards featuring Allwinner's A80 SoC. Unlike the AXP806, it
> doesn't support address space extension and its associated registers,
> but the two are otherwise identical (including the chip ID).
>
> This patch adds support for the interrupts on the AXP808 and enables
> the regulator sub-device. The next patch in the series adds the actual
> regulator support.
>
> Signed-off-by: Rask Ingemann Lambertsen 

Acked-by: Chen-Yu Tsai 

> ---
>  drivers/mfd/axp20x-rsb.c   |  1 +
>  drivers/mfd/axp20x.c   | 28 
>  include/linux/mfd/axp20x.h |  1 +
>  3 files changed, 30 insertions(+)
>
> diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
> index a732cb5..96ea2e9 100644
> --- a/drivers/mfd/axp20x-rsb.c
> +++ b/drivers/mfd/axp20x-rsb.c
> @@ -62,6 +62,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
>  static const struct of_device_id axp20x_rsb_of_match[] = {
> { .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
> { .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
> +   { .compatible = "x-powers,axp808", .data = (void *)AXP808_ID },
> { .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
> { },
>  };
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 25115fe..2d3383e 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
> "AXP223",
> "AXP288",
> "AXP806",
> +   "AXP808",
> "AXP809",
>  };
>
> @@ -148,6 +149,13 @@ static const struct regmap_range 
> axp806_writeable_ranges[] = {
> regmap_reg_range(AXP806_REG_ADDR_EXT, AXP806_REG_ADDR_EXT),
>  };
>
> +static const struct regmap_range axp808_writeable_ranges[] = {
> +   regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_DATACACHE(3)),
> +   regmap_reg_range(AXP806_PWR_OUT_CTRL1, AXP806_CLDO3_V_CTRL),
> +   regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ2_EN),
> +   regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE),
> +};
> +
>  static const struct regmap_range axp806_volatile_ranges[] = {
> regmap_reg_range(AXP20X_IRQ1_STATE, AXP20X_IRQ2_STATE),
>  };
> @@ -162,6 +170,11 @@ static const struct regmap_access_table 
> axp806_volatile_table = {
> .n_yes_ranges   = ARRAY_SIZE(axp806_volatile_ranges),
>  };
>
> +static const struct regmap_access_table axp808_writeable_table = {
> +   .yes_ranges = axp808_writeable_ranges,
> +   .n_yes_ranges   = ARRAY_SIZE(axp808_writeable_ranges),

You could probably get away with using axp806_writeable_ranges,
and pass ARRAY_SIZE(axp808_writeable_ranges) - 1 for .n_yes_ranges.

Or maybe the compiler figures out the 2 arrays share common data.

ChenYu

> +};
> +
>  static struct resource axp152_pek_resources[] = {
> DEFINE_RES_IRQ_NAMED(AXP152_IRQ_PEK_RIS_EDGE, "PEK_DBR"),
> DEFINE_RES_IRQ_NAMED(AXP152_IRQ_PEK_FAL_EDGE, "PEK_DBF"),
> @@ -320,6 +333,15 @@ static const struct regmap_config axp806_regmap_config = 
> {
> .cache_type = REGCACHE_RBTREE,
>  };
>
> +static const struct regmap_config axp808_regmap_config = {
> +   .reg_bits   = 8,
> +   .val_bits   = 8,
> +   .wr_table   = _writeable_table,
> +   .volatile_table = _volatile_table,
> +   .max_register   = AXP806_VREF_TEMP_WARN_L,
> +   .cache_type = REGCACHE_RBTREE,
> +};
> +
>  #define INIT_REGMAP_IRQ(_variant, _irq, _off, _mask)   \
> [_variant##_IRQ_##_irq] = { .reg_offset = (_off), .mask = BIT(_mask) }
>
> @@ -842,6 +864,12 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
> axp20x->regmap_cfg = _regmap_config;
> axp20x->regmap_irq_chip = _regmap_irq_chip;
> break;
> +   case AXP808_ID:
> +   axp20x->nr_cells = ARRAY_SIZE(axp806_cells);
> +   axp20x->cells = axp806_cells;
> +   axp20x->regmap_cfg = _regmap_config;
> +   axp20x->regmap_irq_chip = _regmap_irq_chip;
> +   break;
> case AXP809_ID:
> axp20x->nr_cells = ARRAY_SIZE(axp809_cells);
> axp20x->cells = axp809_cells;
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index 0aa4ef7..b9b7eae 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -21,6 +21,7 @@ enum {
> AXP223_ID,
> AXP288_ID,
> AXP806_ID,
> +   AXP808_ID,
> AXP809_ID,
> NR_AXP20X_VARIANTS,
>  };
> --
> 2.10.2
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

linux-next: Tree for Feb 2

[Stephen Rothwell]

Hi all,

Changes since 20170201:

Dropped tree: vfs-miklos (build failure and out of date)

The vfs-miklos tree still had its build failure, so I just dropped it
again for today.

The v4l-dvb tree still had its build failure so I used the version from
next-20170130.

The net-next tree gained a conflict against Linus' tree.

The block tree gained a conflict against the vfs tree.

The regulator tree gained a build failure so I used the version from
next-20170131.

Non-merge commits (relative to Linus' tree): 6591
 7242 files changed, 275702 insertions(+), 138958 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 36 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (6d04dfc89660 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (566cf877a1fc Linux 4.10-rc6)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (a0615a16f7d0 powerpc/mm: Use the correct pointer 
when setting a 2MB pte)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (6d04dfc89660 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (a47b70ea86bd ravb: unmap descriptors when freeing 
rings)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (115865fa0826 mac80211: don't try to sleep in 
rate_control_rate_init())
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (030305d69fc6 PCI/ASPM: Handle PCI-to-PCIe 
bridges as roots of PCIe hierarchies)
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (a3683e0c1410 Merge tag 'usb-serial-4.10-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (b17c1bba9cec staging: greybus: timesync: 
validate platform state callback)
Mergi

linux-next: Tree for Feb 2

[Stephen Rothwell]

Hi all,

Changes since 20170201:

Dropped tree: vfs-miklos (build failure and out of date)

The vfs-miklos tree still had its build failure, so I just dropped it
again for today.

The v4l-dvb tree still had its build failure so I used the version from
next-20170130.

The net-next tree gained a conflict against Linus' tree.

The block tree gained a conflict against the vfs tree.

The regulator tree gained a build failure so I used the version from
next-20170131.

Non-merge commits (relative to Linus' tree): 6591
 7242 files changed, 275702 insertions(+), 138958 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 254 trees (counting Linus' and 36 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (6d04dfc89660 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (30066ce675d3 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging kbuild-current/rc-fixes (c7858bf16c0b asm-prototypes: Clear any CPP 
defines before declaring the functions)
Merging arc-current/for-curr (566cf877a1fc Linux 4.10-rc6)
Merging arm-current/fixes (228dbbfb5d77 ARM: 8643/3: arm/ptrace: Preserve 
previous registers for short regset write)
Merging m68k-current/for-linus (ad595b77c4a8 m68k/atari: Use seq_puts() in 
atari_get_hardware_list())
Merging metag-fixes/fixes (35d04077ad96 metag: Only define 
atomic_dec_if_positive conditionally)
Merging powerpc-fixes/fixes (a0615a16f7d0 powerpc/mm: Use the correct pointer 
when setting a 2MB pte)
Merging sparc/master (f9a42e0d58cf Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (6d04dfc89660 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging ipsec/master (4e5da369df64 Documentation/networking: fix typo in 
mpls-sysctl)
Merging netfilter/master (a47b70ea86bd ravb: unmap descriptors when freeing 
rings)
Merging ipvs/master (045169816b31 Merge branch 'linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6)
Merging wireless-drivers/master (52f5631a4c05 rtlwifi: rtl8192ce: Fix loading 
of incorrect firmware)
Merging mac80211/master (115865fa0826 mac80211: don't try to sleep in 
rate_control_rate_init())
Merging sound-current/for-linus (6cf4569ce356 Merge tag 'asoc-fix-v4.10-rc3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (030305d69fc6 PCI/ASPM: Handle PCI-to-PCIe 
bridges as roots of PCIe hierarchies)
Merging driver-core.current/driver-core-linus (49def1853334 Linux 4.10-rc4)
Merging tty.current/tty-linus (49def1853334 Linux 4.10-rc4)
Merging usb.current/usb-linus (a3683e0c1410 Merge tag 'usb-serial-4.10-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (efe357f4633a usb: dwc2: host: fix 
Wmaybe-uninitialized warning)
Merging usb-serial-fixes/usb-linus (d07830db1bdb USB: serial: pl2303: add ATEN 
device ID)
Merging usb-chipidea-fixes/ci-for-usb-stable (c7fbb09b2ea1 usb: chipidea: move 
the lock initialization to core file)
Merging phy/fixes (7ce7d89f4883 Linux 4.10-rc1)
Merging staging.current/staging-linus (b17c1bba9cec staging: greybus: timesync: 
validate platform state callback)
Mergi

Re: [PATCH 2/5] DT: mfd: axp20x: Add binding for the AXP808

[Chen-Yu Tsai]

On Wed, Feb 1, 2017 at 9:27 PM, Rob Herring  wrote:
> On Thu, Jan 26, 2017 at 10:16:13PM +0100, Rask Ingemann Lambertsen wrote:
>> The AXP808 does not support address space extension, but is otherwise
>> identical to the AXP806, including the chip ID, so add a compatible
>> string for it to the binding.
>>
>> Signed-off-by: Rask Ingemann Lambertsen 
>> ---
>>  Documentation/devicetree/bindings/mfd/axp20x.txt | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> Acked-by: Rob Herring 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 2/5] DT: mfd: axp20x: Add binding for the AXP808

[Chen-Yu Tsai]

On Wed, Feb 1, 2017 at 9:27 PM, Rob Herring  wrote:
> On Thu, Jan 26, 2017 at 10:16:13PM +0100, Rask Ingemann Lambertsen wrote:
>> The AXP808 does not support address space extension, but is otherwise
>> identical to the AXP806, including the chip ID, so add a compatible
>> string for it to the binding.
>>
>> Signed-off-by: Rask Ingemann Lambertsen 
>> ---
>>  Documentation/devicetree/bindings/mfd/axp20x.txt | 7 ---
>>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> Acked-by: Rob Herring 

Acked-by: Chen-Yu Tsai 

Re: [PATCH 03/11] [media] s5p-mfc: Use min scratch buffer size

[Andrzej Hajda]

On 18.01.2017 11:02, Smitha T Murthy wrote:
> After MFC v8.0, mfc f/w lets the driver know how much scratch buffer
> size is required for decoder. If mfc f/w has the functionality,
> E_MIN_SCRATCH_BUFFER_SIZE, driver can know how much scratch buffer size
> is required for encoder too.

Subject says "Use min scratch buffer size" but it is already used.
Maybe it should be changed to sth like:
Use min scratch buffer size provided by F/W

>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v8.h|2 +
>  drivers/media/platform/s5p-mfc/s5p_mfc.c|2 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|7 ++
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|4 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   68 
> +--
>  6 files changed, 67 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
> index 4d1c375..2cd396b 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
> @@ -17,6 +17,7 @@
>  
>  /* Additional registers for v8 */
>  #define S5P_FIMV_D_MVC_NUM_VIEWS_V8  0xf104
> +#define S5P_FIMV_D_MIN_SCRATCH_BUFFER_SIZE_V80xf108
>  #define S5P_FIMV_D_FIRST_PLANE_DPB_SIZE_V8   0xf144
>  #define S5P_FIMV_D_SECOND_PLANE_DPB_SIZE_V8  0xf148
>  #define S5P_FIMV_D_MV_BUFFER_SIZE_V8 0xf150
> @@ -84,6 +85,7 @@
>  
>  #define S5P_FIMV_E_VBV_BUFFER_SIZE_V80xf78c
>  #define S5P_FIMV_E_VBV_INIT_DELAY_V8 0xf790
> +#define S5P_FIMV_E_MIN_SCRATCH_BUFFER_SIZE_V8   0xf894
>  
>  #define S5P_FIMV_E_ASPECT_RATIO_V8   0xfb4c
>  #define S5P_FIMV_E_EXTENDED_SAR_V8   0xfb50
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index a043cce..b014038 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -520,6 +520,8 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx 
> *ctx,
>   dev);
>   ctx->mv_count = s5p_mfc_hw_call(dev->mfc_ops, get_mv_count,
>   dev);
> + ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
> + get_min_scratch_buf_size, dev);
>   if (ctx->img_width == 0 || ctx->img_height == 0)
>   ctx->state = MFCINST_ERROR;
>   else
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 1941c63..998e24b 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -724,6 +724,7 @@ struct mfc_control {
>  #define IS_MFCV7_PLUS(dev)   (dev->variant->version >= 0x70 ? 1 : 0)
>  #define IS_MFCV8_PLUS(dev)   (dev->variant->version >= 0x80 ? 1 : 0)
>  #define IS_MFCV10(dev)   (dev->variant->version >= 0xA0 ? 1 : 0)
> +#define FW_HAS_E_MIN_SCRATCH_BUF(dev) (IS_MFCV10(dev))
>  
>  #define MFC_V5_BIT   BIT(0)
>  #define MFC_V6_BIT   BIT(1)
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> index 9042378..ef15831 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> @@ -818,6 +818,13 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
>   get_enc_dpb_count, dev);
>   if (ctx->pb_count < enc_pb_count)
>   ctx->pb_count = enc_pb_count;
> + if (FW_HAS_E_MIN_SCRATCH_BUF(dev)) {
> + ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
> + get_e_min_scratch_buf_size, dev);
> + ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size,
> + S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);

Do we really need to align it here? Does firmware return unaligned value?
Even then the alignment (if necessary) should be moved rather to
get_e_min_scratch_buf_size.

> + ctx->bank1.size += ctx->scratch_buf_size;
> + }
>   ctx->state = MFCINST_HEAD_PRODUCED;
>   }
>  
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> index b6ac417..6478f70 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> @@ -169,6 +169,7 @@ struct s5p_mfc_regs {
>   void __iomem *d_decoded_third_addr;/* only v7 */
>   void __iomem *d_used_dpb_flag_upper;/* v7 and v8 */
>   void __iomem *d_used_dpb_flag_lower;/* v7 and v8 */
> + void __iomem *d_min_scratch_buffer_size; /* v10 */
>  
>   /* encoder registers */
>   

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

[Ingo Molnar]

* Nicolas Iooss  wrote:

> With %Ld, my compiler (gcc 6.3.1 on x86_64) complains:
> 
> arch/x86/tools/relocs.c:400:7: error: format ‘%Ld’ expects argument of
> type ‘long long int’, but argument 2 has type ‘Elf64_Off {aka long
> unsigned int}’ [-Werror=format=]

How did it pick up that type as an 'unsigned long'? We have:

  include/uapi/linux/elf.h:typedef __u64  Elf64_Off;

Even user-space has it as a pure 64-bit type:

  /usr/include/elf.h:typedef uint64_t Elf64_Off;

Thanks,

Ingo

Re: [PATCH 03/11] [media] s5p-mfc: Use min scratch buffer size

[Andrzej Hajda]

On 18.01.2017 11:02, Smitha T Murthy wrote:
> After MFC v8.0, mfc f/w lets the driver know how much scratch buffer
> size is required for decoder. If mfc f/w has the functionality,
> E_MIN_SCRATCH_BUFFER_SIZE, driver can know how much scratch buffer size
> is required for encoder too.

Subject says "Use min scratch buffer size" but it is already used.
Maybe it should be changed to sth like:
Use min scratch buffer size provided by F/W

>
> Signed-off-by: Smitha T Murthy 
> ---
>  drivers/media/platform/s5p-mfc/regs-mfc-v8.h|2 +
>  drivers/media/platform/s5p-mfc/s5p_mfc.c|2 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_common.h |1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_enc.c|7 ++
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|4 +
>  drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c |   68 
> +--
>  6 files changed, 67 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h 
> b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
> index 4d1c375..2cd396b 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v8.h
> @@ -17,6 +17,7 @@
>  
>  /* Additional registers for v8 */
>  #define S5P_FIMV_D_MVC_NUM_VIEWS_V8  0xf104
> +#define S5P_FIMV_D_MIN_SCRATCH_BUFFER_SIZE_V80xf108
>  #define S5P_FIMV_D_FIRST_PLANE_DPB_SIZE_V8   0xf144
>  #define S5P_FIMV_D_SECOND_PLANE_DPB_SIZE_V8  0xf148
>  #define S5P_FIMV_D_MV_BUFFER_SIZE_V8 0xf150
> @@ -84,6 +85,7 @@
>  
>  #define S5P_FIMV_E_VBV_BUFFER_SIZE_V80xf78c
>  #define S5P_FIMV_E_VBV_INIT_DELAY_V8 0xf790
> +#define S5P_FIMV_E_MIN_SCRATCH_BUFFER_SIZE_V8   0xf894
>  
>  #define S5P_FIMV_E_ASPECT_RATIO_V8   0xfb4c
>  #define S5P_FIMV_E_EXTENDED_SAR_V8   0xfb50
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> index a043cce..b014038 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -520,6 +520,8 @@ static void s5p_mfc_handle_seq_done(struct s5p_mfc_ctx 
> *ctx,
>   dev);
>   ctx->mv_count = s5p_mfc_hw_call(dev->mfc_ops, get_mv_count,
>   dev);
> + ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
> + get_min_scratch_buf_size, dev);
>   if (ctx->img_width == 0 || ctx->img_height == 0)
>   ctx->state = MFCINST_ERROR;
>   else
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 1941c63..998e24b 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -724,6 +724,7 @@ struct mfc_control {
>  #define IS_MFCV7_PLUS(dev)   (dev->variant->version >= 0x70 ? 1 : 0)
>  #define IS_MFCV8_PLUS(dev)   (dev->variant->version >= 0x80 ? 1 : 0)
>  #define IS_MFCV10(dev)   (dev->variant->version >= 0xA0 ? 1 : 0)
> +#define FW_HAS_E_MIN_SCRATCH_BUF(dev) (IS_MFCV10(dev))
>  
>  #define MFC_V5_BIT   BIT(0)
>  #define MFC_V6_BIT   BIT(1)
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> index 9042378..ef15831 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> @@ -818,6 +818,13 @@ static int enc_post_seq_start(struct s5p_mfc_ctx *ctx)
>   get_enc_dpb_count, dev);
>   if (ctx->pb_count < enc_pb_count)
>   ctx->pb_count = enc_pb_count;
> + if (FW_HAS_E_MIN_SCRATCH_BUF(dev)) {
> + ctx->scratch_buf_size = s5p_mfc_hw_call(dev->mfc_ops,
> + get_e_min_scratch_buf_size, dev);
> + ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_size,
> + S5P_FIMV_SCRATCH_BUFFER_ALIGN_V6);

Do we really need to align it here? Does firmware return unaligned value?
Even then the alignment (if necessary) should be moved rather to
get_e_min_scratch_buf_size.

> + ctx->bank1.size += ctx->scratch_buf_size;
> + }
>   ctx->state = MFCINST_HEAD_PRODUCED;
>   }
>  
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h 
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> index b6ac417..6478f70 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> @@ -169,6 +169,7 @@ struct s5p_mfc_regs {
>   void __iomem *d_decoded_third_addr;/* only v7 */
>   void __iomem *d_used_dpb_flag_upper;/* v7 and v8 */
>   void __iomem *d_used_dpb_flag_lower;/* v7 and v8 */
> + void __iomem *d_min_scratch_buffer_size; /* v10 */
>  
>   /* encoder registers */
>   void __iomem 

Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()

[Ingo Molnar]

* Nicolas Iooss  wrote:

> With %Ld, my compiler (gcc 6.3.1 on x86_64) complains:
> 
> arch/x86/tools/relocs.c:400:7: error: format ‘%Ld’ expects argument of
> type ‘long long int’, but argument 2 has type ‘Elf64_Off {aka long
> unsigned int}’ [-Werror=format=]

How did it pick up that type as an 'unsigned long'? We have:

  include/uapi/linux/elf.h:typedef __u64  Elf64_Off;

Even user-space has it as a pure 64-bit type:

  /usr/include/elf.h:typedef uint64_t Elf64_Off;

Thanks,

Ingo

[tip:x86/mm] x86/mpx: Re-add MPX to selftests Makefile

[tip-bot for Dave Hansen]

Commit-ID:  e64d5fbe56259c94df504af8ce804cfc6a022adb
Gitweb: http://git.kernel.org/tip/e64d5fbe56259c94df504af8ce804cfc6a022adb
Author: Dave Hansen 
AuthorDate: Wed, 1 Feb 2017 14:56:29 -0800
Committer:  Ingo Molnar 
CommitDate: Thu, 2 Feb 2017 08:09:18 +0100

x86/mpx: Re-add MPX to selftests Makefile

Ingo pointed out that the MPX tests were no longer in the selftests
Makefile.  It appears that I shot myself in the foot on this one
and accidentally removed them when I added the pkeys tests, probably
from bungling a merge conflict.

Reported-by: Ingo Molnar 
Signed-off-by: Dave Hansen 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: 5f23f6d082a9 ("x86/pkeys: Add self-tests")
Link: http://lkml.kernel.org/r/20170201225629.c3070...@viggo.jf.intel.com
Signed-off-by: Ingo Molnar 
---
 tools/testing/selftests/x86/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index 8c1cb42..fefd950 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -5,7 +5,7 @@ include ../lib.mk
 .PHONY: all all_32 all_64 warn_32bit_failure clean
 
 TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt 
ptrace_syscall test_mremap_vdso \
-   check_initial_reg_state sigreturn ldt_gdt iopl \
+   check_initial_reg_state sigreturn ldt_gdt iopl 
mpx-mini-test \
protection_keys test_vdso
 TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault test_syscall_vdso 
unwind_vdso \
test_FCMOV test_FCOMI test_FISTTP \

[tip:x86/mm] x86/mpx: Re-add MPX to selftests Makefile

[tip-bot for Dave Hansen]

Commit-ID:  e64d5fbe56259c94df504af8ce804cfc6a022adb
Gitweb: http://git.kernel.org/tip/e64d5fbe56259c94df504af8ce804cfc6a022adb
Author: Dave Hansen 
AuthorDate: Wed, 1 Feb 2017 14:56:29 -0800
Committer:  Ingo Molnar 
CommitDate: Thu, 2 Feb 2017 08:09:18 +0100

x86/mpx: Re-add MPX to selftests Makefile

Ingo pointed out that the MPX tests were no longer in the selftests
Makefile.  It appears that I shot myself in the foot on this one
and accidentally removed them when I added the pkeys tests, probably
from bungling a merge conflict.

Reported-by: Ingo Molnar 
Signed-off-by: Dave Hansen 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Fixes: 5f23f6d082a9 ("x86/pkeys: Add self-tests")
Link: http://lkml.kernel.org/r/20170201225629.c3070...@viggo.jf.intel.com
Signed-off-by: Ingo Molnar 
---
 tools/testing/selftests/x86/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index 8c1cb42..fefd950 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -5,7 +5,7 @@ include ../lib.mk
 .PHONY: all all_32 all_64 warn_32bit_failure clean
 
 TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt 
ptrace_syscall test_mremap_vdso \
-   check_initial_reg_state sigreturn ldt_gdt iopl \
+   check_initial_reg_state sigreturn ldt_gdt iopl 
mpx-mini-test \
protection_keys test_vdso
 TARGETS_C_32BIT_ONLY := entry_from_vm86 syscall_arg_fault test_syscall_vdso 
unwind_vdso \
test_FCMOV test_FCOMI test_FISTTP \

Re: [PATCH v2] ARM: dts: i.MX25: add AIPS control registers

[Sascha Hauer]

Hi Martin,

On Wed, Feb 01, 2017 at 11:16:18PM +0100, Martin Kaiser wrote:
> The i.MX25 contains two AHB to IP bridges (AIPS), each of which has a set of
> control registers. Add the memory regions for the control registers to
> the Device Tree.
> 
> Signed-off-by: Martin Kaiser 
> ---
> v2:
>removed the "fsl,imx53-aipstz" property as per Sascha's request
> 
>  arch/arm/boot/dts/imx25.dtsi |   10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
> index e0ba550..1914858 100644
> --- a/arch/arm/boot/dts/imx25.dtsi
> +++ b/arch/arm/boot/dts/imx25.dtsi
> @@ -93,6 +93,11 @@
>   reg = <0x43f0 0x10>;
>   ranges;
>  
> + aips1: bridge@43f0 {
> + compatible = "fsl,imx25-aips";
> + reg = <0x43f0 0x60>;
> + };

One thing I haven't seen the first time: The size should be the size of
the while register space given to this device, not the position of the
last register, so 0x4000 instead of 0x60 here.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v2] ARM: dts: i.MX25: add AIPS control registers

[Sascha Hauer]

Hi Martin,

On Wed, Feb 01, 2017 at 11:16:18PM +0100, Martin Kaiser wrote:
> The i.MX25 contains two AHB to IP bridges (AIPS), each of which has a set of
> control registers. Add the memory regions for the control registers to
> the Device Tree.
> 
> Signed-off-by: Martin Kaiser 
> ---
> v2:
>removed the "fsl,imx53-aipstz" property as per Sascha's request
> 
>  arch/arm/boot/dts/imx25.dtsi |   10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
> index e0ba550..1914858 100644
> --- a/arch/arm/boot/dts/imx25.dtsi
> +++ b/arch/arm/boot/dts/imx25.dtsi
> @@ -93,6 +93,11 @@
>   reg = <0x43f0 0x10>;
>   ranges;
>  
> + aips1: bridge@43f0 {
> + compatible = "fsl,imx25-aips";
> + reg = <0x43f0 0x60>;
> + };

One thing I haven't seen the first time: The size should be the size of
the while register space given to this device, not the position of the
last register, so 0x4000 instead of 0x60 here.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] x86, mpx: re-add MPX to selftests Makefile

[Ingo Molnar]

* Dave Hansen  wrote:

> 
> From: Dave Hansen 
> 
> Ingo pointed out that the MPX tests were no longer in the selftests
> Makefile.  It appears that I shot myself in the foot on this one
> and accidentally removed them when I added the pkeys tests, probably
> from bungling a merge conflict.

Note, we still have these ugly warnings when building the pkeys testcase with 
GCC 
5.4.0:

gcc -m32 -o protection_keys_32 -O2 -g -std=gnu99 -pthread -Wall  
protection_keys.c -lrt -ldl -lm
protection_keys.c: In function ‘setup_hugetlbfs’:
protection_keys.c:816:6: warning: unused variable ‘i’ [-Wunused-variable]
  int i;
  ^
protection_keys.c:815:6: warning: unused variable ‘validated_nr_pages’ 
[-Wunused-variable]
  int validated_nr_pages;
  ^
protection_keys.c: In function ‘test_pkey_syscalls_bad_args’:
protection_keys.c:1136:6: warning: unused variable ‘bad_flag’ 
[-Wunused-variable]
  int bad_flag = (PKEY_DISABLE_ACCESS | PKEY_DISABLE_WRITE) + 1;
  ^
protection_keys.c: In function ‘test_pkey_alloc_exhaust’:
protection_keys.c:1153:16: warning: unused variable ‘init_val’ 
[-Wunused-variable]
  unsigned long init_val;
^
protection_keys.c:1152:16: warning: unused variable ‘flags’ [-Wunused-variable]
  unsigned long flags;
^
In file included from protection_keys.c:45:0:
pkey-helpers.h: In function ‘sigsafe_printf’:
pkey-helpers.h:41:3: warning: ignoring return value of ‘write’, declared with 
attribute warn_unused_result [-Wunused-result]
   write(1, dprint_in_signal_buffer, len);
   ^
protection_keys.c: In function ‘dumpit’:
protection_keys.c:407:3: warning: ignoring return value of ‘write’, declared 
with attribute warn_unused_result [-Wunused-result]
   write(1, buf, nr_read);
   ^
protection_keys.c: In function ‘pkey_disable_set’:
protection_keys.c:68:5: warning: ‘orig_pkru’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  if (!(condition)) {   \
 ^
protection_keys.c:465:6: note: ‘orig_pkru’ was declared here
  u32 orig_pkru;
  ^

Thanks,

Ingo

Re: [PATCH] x86, mpx: re-add MPX to selftests Makefile

[Ingo Molnar]

* Dave Hansen  wrote:

> 
> From: Dave Hansen 
> 
> Ingo pointed out that the MPX tests were no longer in the selftests
> Makefile.  It appears that I shot myself in the foot on this one
> and accidentally removed them when I added the pkeys tests, probably
> from bungling a merge conflict.

Note, we still have these ugly warnings when building the pkeys testcase with 
GCC 
5.4.0:

gcc -m32 -o protection_keys_32 -O2 -g -std=gnu99 -pthread -Wall  
protection_keys.c -lrt -ldl -lm
protection_keys.c: In function ‘setup_hugetlbfs’:
protection_keys.c:816:6: warning: unused variable ‘i’ [-Wunused-variable]
  int i;
  ^
protection_keys.c:815:6: warning: unused variable ‘validated_nr_pages’ 
[-Wunused-variable]
  int validated_nr_pages;
  ^
protection_keys.c: In function ‘test_pkey_syscalls_bad_args’:
protection_keys.c:1136:6: warning: unused variable ‘bad_flag’ 
[-Wunused-variable]
  int bad_flag = (PKEY_DISABLE_ACCESS | PKEY_DISABLE_WRITE) + 1;
  ^
protection_keys.c: In function ‘test_pkey_alloc_exhaust’:
protection_keys.c:1153:16: warning: unused variable ‘init_val’ 
[-Wunused-variable]
  unsigned long init_val;
^
protection_keys.c:1152:16: warning: unused variable ‘flags’ [-Wunused-variable]
  unsigned long flags;
^
In file included from protection_keys.c:45:0:
pkey-helpers.h: In function ‘sigsafe_printf’:
pkey-helpers.h:41:3: warning: ignoring return value of ‘write’, declared with 
attribute warn_unused_result [-Wunused-result]
   write(1, dprint_in_signal_buffer, len);
   ^
protection_keys.c: In function ‘dumpit’:
protection_keys.c:407:3: warning: ignoring return value of ‘write’, declared 
with attribute warn_unused_result [-Wunused-result]
   write(1, buf, nr_read);
   ^
protection_keys.c: In function ‘pkey_disable_set’:
protection_keys.c:68:5: warning: ‘orig_pkru’ may be used uninitialized in this 
function [-Wmaybe-uninitialized]
  if (!(condition)) {   \
 ^
protection_keys.c:465:6: note: ‘orig_pkru’ was declared here
  u32 orig_pkru;
  ^

Thanks,

Ingo

Re: [PATCH] pinctrl: samsung: mark PM functions as __maybe_unused

[Marek Szyprowski]

Hi Arnd,

On 2017-02-01 17:16, Arnd Bergmann wrote:

The rework of the suspend/resume handling uses the wrong #ifdef check, leading
to a build warning without CONFIG_PM_SLEEP:

drivers/pinctrl/samsung/pinctrl-samsung.c:1142:12: error: 
'samsung_pinctrl_resume' defined but not used [-Werror=unused-function]
drivers/pinctrl/samsung/pinctrl-samsung.c:1092:12: error: 
'samsung_pinctrl_suspend' defined but not used [-Werror=unused-function]

Using a __maybe_unused annotation instead of the #ifdef is a simple way to
avoid this problem class.

Fixes: 2b24efa8e5c5 ("pinctrl: samsung: Replace syscore ops with standard platform 
device pm_ops")
Signed-off-by: Arnd Bergmann 


Thanks for the fix!

Acked-by: Marek Szyprowski 


---
  drivers/pinctrl/samsung/pinctrl-samsung.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c 
b/drivers/pinctrl/samsung/pinctrl-samsung.c
index d79eadad6c5f..d601b5303e73 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1083,13 +1083,12 @@ static int samsung_pinctrl_probe(struct platform_device 
*pdev)
return 0;
  }
  
-#ifdef CONFIG_PM

  /**
   * samsung_pinctrl_suspend - save pinctrl state for suspend
   *
   * Save data for all banks handled by this device.
   */
-static int samsung_pinctrl_suspend(struct device *dev)
+static int __maybe_unused samsung_pinctrl_suspend(struct device *dev)
  {
struct samsung_pinctrl_drv_data *drvdata = dev_get_drvdata(dev);
int i;
@@ -1139,7 +1138,7 @@ static int samsung_pinctrl_suspend(struct device *dev)
   * We don't bother doing anything complicated to avoid glitching lines since
   * we're called before pad retention is turned off.
   */
-static int samsung_pinctrl_resume(struct device *dev)
+static int __maybe_unused samsung_pinctrl_resume(struct device *dev)
  {
struct samsung_pinctrl_drv_data *drvdata = dev_get_drvdata(dev);
int i;
@@ -1183,7 +1182,6 @@ static int samsung_pinctrl_resume(struct device *dev)
  
  	return 0;

  }
-#endif
  
  static const struct of_device_id samsung_pinctrl_dt_match[] = {

  #ifdef CONFIG_PINCTRL_EXYNOS


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

Re: [PATCH] pinctrl: samsung: mark PM functions as __maybe_unused

[Marek Szyprowski]

Hi Arnd,

On 2017-02-01 17:16, Arnd Bergmann wrote:

The rework of the suspend/resume handling uses the wrong #ifdef check, leading
to a build warning without CONFIG_PM_SLEEP:

drivers/pinctrl/samsung/pinctrl-samsung.c:1142:12: error: 
'samsung_pinctrl_resume' defined but not used [-Werror=unused-function]
drivers/pinctrl/samsung/pinctrl-samsung.c:1092:12: error: 
'samsung_pinctrl_suspend' defined but not used [-Werror=unused-function]

Using a __maybe_unused annotation instead of the #ifdef is a simple way to
avoid this problem class.

Fixes: 2b24efa8e5c5 ("pinctrl: samsung: Replace syscore ops with standard platform 
device pm_ops")
Signed-off-by: Arnd Bergmann 


Thanks for the fix!

Acked-by: Marek Szyprowski 


---
  drivers/pinctrl/samsung/pinctrl-samsung.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c 
b/drivers/pinctrl/samsung/pinctrl-samsung.c
index d79eadad6c5f..d601b5303e73 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1083,13 +1083,12 @@ static int samsung_pinctrl_probe(struct platform_device 
*pdev)
return 0;
  }
  
-#ifdef CONFIG_PM

  /**
   * samsung_pinctrl_suspend - save pinctrl state for suspend
   *
   * Save data for all banks handled by this device.
   */
-static int samsung_pinctrl_suspend(struct device *dev)
+static int __maybe_unused samsung_pinctrl_suspend(struct device *dev)
  {
struct samsung_pinctrl_drv_data *drvdata = dev_get_drvdata(dev);
int i;
@@ -1139,7 +1138,7 @@ static int samsung_pinctrl_suspend(struct device *dev)
   * We don't bother doing anything complicated to avoid glitching lines since
   * we're called before pad retention is turned off.
   */
-static int samsung_pinctrl_resume(struct device *dev)
+static int __maybe_unused samsung_pinctrl_resume(struct device *dev)
  {
struct samsung_pinctrl_drv_data *drvdata = dev_get_drvdata(dev);
int i;
@@ -1183,7 +1182,6 @@ static int samsung_pinctrl_resume(struct device *dev)
  
  	return 0;

  }
-#endif
  
  static const struct of_device_id samsung_pinctrl_dt_match[] = {

  #ifdef CONFIG_PINCTRL_EXYNOS


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig and x86_64 allmodconfig) produced this warning:

fs/ext4/file.c:279:1: warning: 'ext4_dax_huge_fault' defined but not used 
[-Wunused-function]
 ext4_dax_huge_fault(struct vm_fault *vmf)
 ^

Introduced by commit

  80a841811260 ("mm,fs,dax: change ->pmd_fault to ->huge_fault")

Looks like the replacement in ext4_dax_vm_ops may be incorrect?

-- 
Cheers,
Stephen Rothwell

linux-next: build warning after merge of the akpm-current tree

[Stephen Rothwell]

Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig and x86_64 allmodconfig) produced this warning:

fs/ext4/file.c:279:1: warning: 'ext4_dax_huge_fault' defined but not used 
[-Wunused-function]
 ext4_dax_huge_fault(struct vm_fault *vmf)
 ^

Introduced by commit

  80a841811260 ("mm,fs,dax: change ->pmd_fault to ->huge_fault")

Looks like the replacement in ext4_dax_vm_ops may be incorrect?

-- 
Cheers,
Stephen Rothwell

Re: [PATCH v2 3/4] phy: Add USB3 PHY support for Broadcom NSP SoC

[Rafał Miłecki]

[Resending with fixed/complete Cc-s]

On Tue, 17 Jan 2017 11:14:29 -0500, Yendapally Reddy Dhananjaya Reddy 
 wrote:> This patch adds support for Broadcom 
NSP USB3 PHY
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy 


Seriously?! I really dislike what you did there.

NACK.

You are aware this block is common for both: Northstar and Northstar Plus and
we already have phy-bcm-ns-usb3.c! In fact Jon told me to rewrite my initial
driver to make is possible to reuse it on NSP and I did that!

This is old comment from Jon:

In 30 March 2016 at 23:31, Jon Mason  wrote:
> On Mon, Mar 28, 2016 at 9:46 PM, Florian Fainelli 
> wrote:
>>
>> CC: bcm-kernel-feedback-list, Jon
>
>
> This is a common IP block with NSP.  I believe with some minor changes it
> can support both.  Please allow me 1-2 days to look at these in more detail
> and see if I can get these patches working on NSP.

Please start using existing code instead of inventing everything from the
scratch internally at Broadcom. You did the same thing with (Q)SPI driver.


This driver duplicates phy-bcm-ns-usb3.c and should have not been accepted. I
strongly suggest *reverting* it and adjusting existing driver if needed.

Re: [PATCH v2 3/4] phy: Add USB3 PHY support for Broadcom NSP SoC

[Rafał Miłecki]

[Resending with fixed/complete Cc-s]

On Tue, 17 Jan 2017 11:14:29 -0500, Yendapally Reddy Dhananjaya Reddy 
 wrote:> This patch adds support for Broadcom 
NSP USB3 PHY
>
> Signed-off-by: Yendapally Reddy Dhananjaya Reddy 


Seriously?! I really dislike what you did there.

NACK.

You are aware this block is common for both: Northstar and Northstar Plus and
we already have phy-bcm-ns-usb3.c! In fact Jon told me to rewrite my initial
driver to make is possible to reuse it on NSP and I did that!

This is old comment from Jon:

In 30 March 2016 at 23:31, Jon Mason  wrote:
> On Mon, Mar 28, 2016 at 9:46 PM, Florian Fainelli 
> wrote:
>>
>> CC: bcm-kernel-feedback-list, Jon
>
>
> This is a common IP block with NSP.  I believe with some minor changes it
> can support both.  Please allow me 1-2 days to look at these in more detail
> and see if I can get these patches working on NSP.

Please start using existing code instead of inventing everything from the
scratch internally at Broadcom. You did the same thing with (Q)SPI driver.


This driver duplicates phy-bcm-ns-usb3.c and should have not been accepted. I
strongly suggest *reverting* it and adjusting existing driver if needed.

[PATCH 3/4] tools lib feature: Do not redefine compiler configuration

[David Carrillo-Cisneros]

Feature detection redefines CC, CCX and PKG_CONFIG, making the
output of feature detection inconsistent with the actual features
available during compilation when the above variables are used.

Fix it by using conditional assignment.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/build/feature/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 3dd2c600d250..d39e76f3a063 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -52,9 +52,9 @@ FILES=  \
 
 FILES := $(addprefix $(OUTPUT),$(FILES))
 
-CC := $(CROSS_COMPILE)gcc -MD
-CXX := $(CROSS_COMPILE)g++ -MD
-PKG_CONFIG := $(CROSS_COMPILE)pkg-config
+CC ?= $(CROSS_COMPILE)gcc -MD
+CXX ?= $(CROSS_COMPILE)g++ -MD
+PKG_CONFIG ?= $(CROSS_COMPILE)pkg-config
 LLVM_CONFIG ?= llvm-config
 
 all: $(FILES)
-- 
2.11.0.483.g087da7b7c-goog

[PATCH 3/4] tools lib feature: Do not redefine compiler configuration

[David Carrillo-Cisneros]

Feature detection redefines CC, CCX and PKG_CONFIG, making the
output of feature detection inconsistent with the actual features
available during compilation when the above variables are used.

Fix it by using conditional assignment.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/build/feature/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 3dd2c600d250..d39e76f3a063 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -52,9 +52,9 @@ FILES=  \
 
 FILES := $(addprefix $(OUTPUT),$(FILES))
 
-CC := $(CROSS_COMPILE)gcc -MD
-CXX := $(CROSS_COMPILE)g++ -MD
-PKG_CONFIG := $(CROSS_COMPILE)pkg-config
+CC ?= $(CROSS_COMPILE)gcc -MD
+CXX ?= $(CROSS_COMPILE)g++ -MD
+PKG_CONFIG ?= $(CROSS_COMPILE)pkg-config
 LLVM_CONFIG ?= llvm-config
 
 all: $(FILES)
-- 
2.11.0.483.g087da7b7c-goog

[PATCH 1/4] perf tools: pass PYTHON config to feature detection

[David Carrillo-Cisneros]

Python's CC and link Makefile variables were not passed to feature
detection, causing feature detection to use system's Python rather than
PYTHON_CONFIG's one. This created a mismatch between the detected Python
support and the one actually used by perf when PYTHON_CONFIG is specified.

Fix it by moving Python's variable initialization to before feature
detection and pass FLAGS_PYTHON_EMBED to Python's feature detection's
build target.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/build/feature/Makefile |  2 +-
 tools/perf/Makefile.config   | 23 ++-
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index b564a2eea039..3dd2c600d250 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -171,7 +171,7 @@ $(OUTPUT)test-libperl.bin:
$(BUILD) $(FLAGS_PERL_EMBED)
 
 $(OUTPUT)test-libpython.bin:
-   $(BUILD)
+   $(BUILD) $(FLAGS_PYTHON_EMBED)
 
 $(OUTPUT)test-libpython-version.bin:
$(BUILD)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 03cf947755b9..41f5c41c5660 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -166,10 +166,18 @@ PYTHON2_CONFIG := \
 override PYTHON_CONFIG := \
   $(call get-executable-or-default,PYTHON_CONFIG,$(PYTHON2_CONFIG))
 
+grep-libs  = $(filter -l%,$(1))
+strip-libs  = $(filter-out -l%,$(1))
+
 PYTHON_CONFIG_SQ := $(call shell-sq,$(PYTHON_CONFIG))
 
-PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
-PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
+ifdef PYTHON_CONFIG
+  PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
+  PYTHON_EMBED_LDFLAGS := $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
+  PYTHON_EMBED_LIBADD := $(call grep-libs,$(PYTHON_EMBED_LDOPTS)) -lutil
+  PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
+  FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
+endif
 
 FEATURE_CHECK_CFLAGS-libpython := $(PYTHON_EMBED_CCOPTS)
 FEATURE_CHECK_LDFLAGS-libpython := $(PYTHON_EMBED_LDOPTS)
@@ -542,8 +550,6 @@ ifndef NO_GTK2
   endif
 endif
 
-grep-libs  = $(filter -l%,$(1))
-strip-libs = $(filter-out -l%,$(1))
 
 ifdef NO_LIBPERL
   CFLAGS += -DNO_LIBPERL
@@ -591,18 +597,9 @@ else
   $(call disable-python,No 'python-config' tool was found: disables Python 
support - please install python-devel/python-dev)
 else
 
-  PYTHON_CONFIG_SQ := $(call shell-sq,$(PYTHON_CONFIG))
-
-  PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
-  PYTHON_EMBED_LDFLAGS := $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
-  PYTHON_EMBED_LIBADD := $(call grep-libs,$(PYTHON_EMBED_LDOPTS)) -lutil
-  PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
-  FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
-
   ifneq ($(feature-libpython), 1)
 $(call disable-python,No 'Python.h' (for Python 2.x support) was 
found: disables Python support - please install python-devel/python-dev)
   else
-
 ifneq ($(feature-libpython-version), 1)
   $(warning Python 3 is not yet supported; please set)
   $(warning PYTHON and/or PYTHON_CONFIG appropriately.)
-- 
2.11.0.483.g087da7b7c-goog

[PATCH 1/4] perf tools: pass PYTHON config to feature detection

[David Carrillo-Cisneros]

Python's CC and link Makefile variables were not passed to feature
detection, causing feature detection to use system's Python rather than
PYTHON_CONFIG's one. This created a mismatch between the detected Python
support and the one actually used by perf when PYTHON_CONFIG is specified.

Fix it by moving Python's variable initialization to before feature
detection and pass FLAGS_PYTHON_EMBED to Python's feature detection's
build target.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/build/feature/Makefile |  2 +-
 tools/perf/Makefile.config   | 23 ++-
 2 files changed, 11 insertions(+), 14 deletions(-)

diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index b564a2eea039..3dd2c600d250 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -171,7 +171,7 @@ $(OUTPUT)test-libperl.bin:
$(BUILD) $(FLAGS_PERL_EMBED)
 
 $(OUTPUT)test-libpython.bin:
-   $(BUILD)
+   $(BUILD) $(FLAGS_PYTHON_EMBED)
 
 $(OUTPUT)test-libpython-version.bin:
$(BUILD)
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index 03cf947755b9..41f5c41c5660 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -166,10 +166,18 @@ PYTHON2_CONFIG := \
 override PYTHON_CONFIG := \
   $(call get-executable-or-default,PYTHON_CONFIG,$(PYTHON2_CONFIG))
 
+grep-libs  = $(filter -l%,$(1))
+strip-libs  = $(filter-out -l%,$(1))
+
 PYTHON_CONFIG_SQ := $(call shell-sq,$(PYTHON_CONFIG))
 
-PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
-PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
+ifdef PYTHON_CONFIG
+  PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
+  PYTHON_EMBED_LDFLAGS := $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
+  PYTHON_EMBED_LIBADD := $(call grep-libs,$(PYTHON_EMBED_LDOPTS)) -lutil
+  PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
+  FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
+endif
 
 FEATURE_CHECK_CFLAGS-libpython := $(PYTHON_EMBED_CCOPTS)
 FEATURE_CHECK_LDFLAGS-libpython := $(PYTHON_EMBED_LDOPTS)
@@ -542,8 +550,6 @@ ifndef NO_GTK2
   endif
 endif
 
-grep-libs  = $(filter -l%,$(1))
-strip-libs = $(filter-out -l%,$(1))
 
 ifdef NO_LIBPERL
   CFLAGS += -DNO_LIBPERL
@@ -591,18 +597,9 @@ else
   $(call disable-python,No 'python-config' tool was found: disables Python 
support - please install python-devel/python-dev)
 else
 
-  PYTHON_CONFIG_SQ := $(call shell-sq,$(PYTHON_CONFIG))
-
-  PYTHON_EMBED_LDOPTS := $(shell $(PYTHON_CONFIG_SQ) --ldflags 2>/dev/null)
-  PYTHON_EMBED_LDFLAGS := $(call strip-libs,$(PYTHON_EMBED_LDOPTS))
-  PYTHON_EMBED_LIBADD := $(call grep-libs,$(PYTHON_EMBED_LDOPTS)) -lutil
-  PYTHON_EMBED_CCOPTS := $(shell $(PYTHON_CONFIG_SQ) --cflags 2>/dev/null)
-  FLAGS_PYTHON_EMBED := $(PYTHON_EMBED_CCOPTS) $(PYTHON_EMBED_LDOPTS)
-
   ifneq ($(feature-libpython), 1)
 $(call disable-python,No 'Python.h' (for Python 2.x support) was 
found: disables Python support - please install python-devel/python-dev)
   else
-
 ifneq ($(feature-libpython-version), 1)
   $(warning Python 3 is not yet supported; please set)
   $(warning PYTHON and/or PYTHON_CONFIG appropriately.)
-- 
2.11.0.483.g087da7b7c-goog

[PATCH 4/4] tools include: Fix include path for uapi/asm-generic/mman.h

[David Carrillo-Cisneros]

commit f3539c12d819 ("tools include: Add uapi mman.h for each architecture")

copied include/uapi/linux/mman.h into tools/include/uapi/linux/mman.h
but did not update the include path for uapi/asm-generic/mman.h. Fix it.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/include/uapi/linux/mman.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/include/uapi/linux/mman.h b/tools/include/uapi/linux/mman.h
index 81d8edf11789..74a19ae15cd1 100644
--- a/tools/include/uapi/linux/mman.h
+++ b/tools/include/uapi/linux/mman.h
@@ -1,7 +1,7 @@
 #ifndef _UAPI_LINUX_MMAN_H
 #define _UAPI_LINUX_MMAN_H
 
-#include 
+#include 
 
 #define MREMAP_MAYMOVE 1
 #define MREMAP_FIXED   2
-- 
2.11.0.483.g087da7b7c-goog

[PATCH 4/4] tools include: Fix include path for uapi/asm-generic/mman.h

[David Carrillo-Cisneros]

commit f3539c12d819 ("tools include: Add uapi mman.h for each architecture")

copied include/uapi/linux/mman.h into tools/include/uapi/linux/mman.h
but did not update the include path for uapi/asm-generic/mman.h. Fix it.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/include/uapi/linux/mman.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/include/uapi/linux/mman.h b/tools/include/uapi/linux/mman.h
index 81d8edf11789..74a19ae15cd1 100644
--- a/tools/include/uapi/linux/mman.h
+++ b/tools/include/uapi/linux/mman.h
@@ -1,7 +1,7 @@
 #ifndef _UAPI_LINUX_MMAN_H
 #define _UAPI_LINUX_MMAN_H
 
-#include 
+#include 
 
 #define MREMAP_MAYMOVE 1
 #define MREMAP_FIXED   2
-- 
2.11.0.483.g087da7b7c-goog

[PATCH 0/4] Fixes for perf build and feature detection

[David Carrillo-Cisneros]

Fixes for minor problems with Makefiles and libs that I found while
building perf.

David Carrillo-Cisneros (4):
  perf tools: pass PYTHON config to feature detection
  tools lib traceevent: Robustify do_generate_dynamic_list_file
  tools lib feature: Do not redefine compiler configuration
  tools include: Fix include path for uapi/asm-generic/mman.h

 tools/build/feature/Makefile|  8 
 tools/include/uapi/linux/mman.h |  2 +-
 tools/lib/traceevent/Makefile   | 13 +
 tools/perf/Makefile.config  | 23 ++-
 4 files changed, 24 insertions(+), 22 deletions(-)

-- 
2.11.0.483.g087da7b7c-goog

[PATCH 2/4] tools lib traceevent: Robustify do_generate_dynamic_list_file

[David Carrillo-Cisneros]

The dynamic-list-file used to export dynamic symbols introduced in

commit e3d09ec8126f ("tools lib traceevent: Export dynamic symbols
used by traceevent plugins")

is generated without any sort of error checking.

I experienced problems due to an old version of nm (v 0.158) that outputs
in a format distinct from the assumed by the script.

Robustify this by enforcing that the second column in the symbol output
is an "U" (Undefined) as it should be since we are calling $(NM) -u ...
and print an error message otherwise.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/lib/traceevent/Makefile | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/lib/traceevent/Makefile b/tools/lib/traceevent/Makefile
index 2616c66e10c1..1b6e146429d0 100644
--- a/tools/lib/traceevent/Makefile
+++ b/tools/lib/traceevent/Makefile
@@ -257,10 +257,15 @@ define do_install_plugins
 endef
 
 define do_generate_dynamic_list_file
-   (echo '{';  \
-   $(NM) -u -D $1 | awk 'NF>1 {print "\t"$$2";"}' | sort -u;   \
-   echo '};';  \
-   ) > $2
+   symbol_type=`$(NM) -u -D $1 | awk 'NF>1 {print $$1}' | sort -u`;\
+   if [ "$$symbol_type" == "U" ];then  \
+   (echo '{';  \
+   $(NM) -u -D $1 | awk 'NF>1 {print "\t"$$2";"}' | sort -u;\
+   echo '};';  \
+   ) > $2; \
+   else\
+   (echo Either missing one of [$1] or bad version of $(NM)) 1>&2;\
+   fi
 endef
 
 install_lib: all_cmd install_plugins
-- 
2.11.0.483.g087da7b7c-goog

[PATCH 0/4] Fixes for perf build and feature detection

[David Carrillo-Cisneros]

Fixes for minor problems with Makefiles and libs that I found while
building perf.

David Carrillo-Cisneros (4):
  perf tools: pass PYTHON config to feature detection
  tools lib traceevent: Robustify do_generate_dynamic_list_file
  tools lib feature: Do not redefine compiler configuration
  tools include: Fix include path for uapi/asm-generic/mman.h

 tools/build/feature/Makefile|  8 
 tools/include/uapi/linux/mman.h |  2 +-
 tools/lib/traceevent/Makefile   | 13 +
 tools/perf/Makefile.config  | 23 ++-
 4 files changed, 24 insertions(+), 22 deletions(-)

-- 
2.11.0.483.g087da7b7c-goog

[PATCH 2/4] tools lib traceevent: Robustify do_generate_dynamic_list_file

[David Carrillo-Cisneros]

The dynamic-list-file used to export dynamic symbols introduced in

commit e3d09ec8126f ("tools lib traceevent: Export dynamic symbols
used by traceevent plugins")

is generated without any sort of error checking.

I experienced problems due to an old version of nm (v 0.158) that outputs
in a format distinct from the assumed by the script.

Robustify this by enforcing that the second column in the symbol output
is an "U" (Undefined) as it should be since we are calling $(NM) -u ...
and print an error message otherwise.

Signed-off-by: David Carrillo-Cisneros 
---
 tools/lib/traceevent/Makefile | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/tools/lib/traceevent/Makefile b/tools/lib/traceevent/Makefile
index 2616c66e10c1..1b6e146429d0 100644
--- a/tools/lib/traceevent/Makefile
+++ b/tools/lib/traceevent/Makefile
@@ -257,10 +257,15 @@ define do_install_plugins
 endef
 
 define do_generate_dynamic_list_file
-   (echo '{';  \
-   $(NM) -u -D $1 | awk 'NF>1 {print "\t"$$2";"}' | sort -u;   \
-   echo '};';  \
-   ) > $2
+   symbol_type=`$(NM) -u -D $1 | awk 'NF>1 {print $$1}' | sort -u`;\
+   if [ "$$symbol_type" == "U" ];then  \
+   (echo '{';  \
+   $(NM) -u -D $1 | awk 'NF>1 {print "\t"$$2";"}' | sort -u;\
+   echo '};';  \
+   ) > $2; \
+   else\
+   (echo Either missing one of [$1] or bad version of $(NM)) 1>&2;\
+   fi
 endef
 
 install_lib: all_cmd install_plugins
-- 
2.11.0.483.g087da7b7c-goog

Re: [PATCH] drm/amdgpu: shut up #warning for compile testing

[Michel Dänzer]

On 02/02/17 12:59 AM, Arnd Bergmann wrote:
> My randconfig tests on linux-next showed a newly introduced warning:
> 
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function 
> 'amdgpu_bo_create_restricted':
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:377:2: error: #warning Please 
> enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to 
> write-combining [-Werror=cpp]
> 
> Generally speaking, warnings about bad kernel configuration are not 
> particularly
> helpful. We could enforce the selection of X86_PAT through Kconfig, so the 
> driver
> cannot even be used unless it is enabled,

Making AMDGPU depend on X86_PAT would be wrong I think, and any fancier
Kconfig solution might be overkill.


> or we could just rely on the runtime warning that is also there.

That might make sense, since the runtime warning is only triggered when
the lack of PAT actually makes a difference.

OTOH the people running the kernel aren't always the same people
building it, so the downside is that this would potentially delay
getting X86_PAT enabled.


> In this version, I'm making the warning conditional on CONFIG_COMPILE_TEST, 
> which
> shuts it up for me, but not people that may actually want to run the kernel
> as a compromize.

This is fine with me as well.


Whichever way we end up going for this, it should be applied to the
radeon driver as well.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [PATCH] drm/amdgpu: shut up #warning for compile testing

[Michel Dänzer]

On 02/02/17 12:59 AM, Arnd Bergmann wrote:
> My randconfig tests on linux-next showed a newly introduced warning:
> 
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function 
> 'amdgpu_bo_create_restricted':
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:377:2: error: #warning Please 
> enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to 
> write-combining [-Werror=cpp]
> 
> Generally speaking, warnings about bad kernel configuration are not 
> particularly
> helpful. We could enforce the selection of X86_PAT through Kconfig, so the 
> driver
> cannot even be used unless it is enabled,

Making AMDGPU depend on X86_PAT would be wrong I think, and any fancier
Kconfig solution might be overkill.


> or we could just rely on the runtime warning that is also there.

That might make sense, since the runtime warning is only triggered when
the lack of PAT actually makes a difference.

OTOH the people running the kernel aren't always the same people
building it, so the downside is that this would potentially delay
getting X86_PAT enabled.


> In this version, I'm making the warning conditional on CONFIG_COMPILE_TEST, 
> which
> shuts it up for me, but not people that may actually want to run the kernel
> as a compromize.

This is fine with me as well.


Whichever way we end up going for this, it should be applied to the
radeon driver as well.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [PATCH v2] staging: rtl8188eu: remove not necessary braces {} (checkpatch fix)

[Martin Karamihov]

On 02/01/2017 08:11 PM, Joe Perches wrote:

...and clarifying the code for a
human reader is much more important than making a
file not have any checkpatch warnings.


I agree. I respect the developers' own coding style and believe that 
some things (>80 characters long lines, name conventions, etc) should be 
fixed by themselves (if they want to do that). I selected several TODOs 
with requests for code cleanups and chose a fix in attempt to accomplish 
my task with minimal inconvenience for the maintainers. I failed in my 
first attempts breaking some basic rules, sorry about that.


Martin

Re: [PATCH v2] staging: rtl8188eu: remove not necessary braces {} (checkpatch fix)

[Martin Karamihov]

On 02/01/2017 08:11 PM, Joe Perches wrote:

...and clarifying the code for a
human reader is much more important than making a
file not have any checkpatch warnings.


I agree. I respect the developers' own coding style and believe that 
some things (>80 characters long lines, name conventions, etc) should be 
fixed by themselves (if they want to do that). I selected several TODOs 
with requests for code cleanups and chose a fix in attempt to accomplish 
my task with minimal inconvenience for the maintainers. I failed in my 
first attempts breaking some basic rules, sorry about that.


Martin

Re: [PATCHv7 4/8] printk: always use deferred printk when flush printk_safe lines

[Sergey Senozhatsky]

On (02/01/17 11:06), Steven Rostedt wrote:
[..]
> >  static void printk_safe_flush_line(const char *text, int len)
> >  {
> > /*
> > -* The buffers are flushed in NMI only on panic.  The messages must
> > -* go only into the ring buffer at this stage.  Consoles will get
> > -* explicitly called later when a crashdump is not generated.
> > +* Avoid any console drivers calls from here, because we may be
> > +* in NMI or printk_safe context (when in panic). The messages
> > +* must go only into the ring buffer at this stage.  Consoles will
> > +* get explicitly called later when a crashdump is not generated.
> >  */
> > -   if (in_nmi())
> > -   printk_deferred("%.*s", len, text);
> > -   else
> > -   printk("%.*s", len, text);
> > +   printk_deferred("%.*s", len, text);
> >  }
> 
> The helper function was there because of the if statement. Just nuke
> this function and call printk_deferred() directly. You can move the
> comment to the caller.

indeed. thanks.

Petr, how would you prefer to handle this?

-ss

Re: [PATCHv7 4/8] printk: always use deferred printk when flush printk_safe lines

[Sergey Senozhatsky]

On (02/01/17 11:06), Steven Rostedt wrote:
[..]
> >  static void printk_safe_flush_line(const char *text, int len)
> >  {
> > /*
> > -* The buffers are flushed in NMI only on panic.  The messages must
> > -* go only into the ring buffer at this stage.  Consoles will get
> > -* explicitly called later when a crashdump is not generated.
> > +* Avoid any console drivers calls from here, because we may be
> > +* in NMI or printk_safe context (when in panic). The messages
> > +* must go only into the ring buffer at this stage.  Consoles will
> > +* get explicitly called later when a crashdump is not generated.
> >  */
> > -   if (in_nmi())
> > -   printk_deferred("%.*s", len, text);
> > -   else
> > -   printk("%.*s", len, text);
> > +   printk_deferred("%.*s", len, text);
> >  }
> 
> The helper function was there because of the if statement. Just nuke
> this function and call printk_deferred() directly. You can move the
> comment to the caller.

indeed. thanks.

Petr, how would you prefer to handle this?

-ss

Re: [PATCH 3/6] async_tx: Handle DMA devices having support for fewer PQ coefficients

[Dan Williams]

On Wed, Feb 1, 2017 at 8:47 PM, Anup Patel  wrote:
> The DMAENGINE framework assumes that if PQ offload is supported by a
> DMA device then all 256 PQ coefficients are supported. This assumption
> does not hold anymore because we now have BCM-SBA-RAID offload engine
> which supports PQ offload with limited number of PQ coefficients.
>
> This patch extends async_tx APIs to handle DMA devices with support
> for fewer PQ coefficients.
>
> Signed-off-by: Anup Patel 
> Reviewed-by: Scott Branden 
> ---
>  crypto/async_tx/async_pq.c  |  3 +++
>  crypto/async_tx/async_raid6_recov.c | 12 ++--
>  include/linux/dmaengine.h   | 19 +++
>  include/linux/raid/pq.h |  3 +++
>  4 files changed, 35 insertions(+), 2 deletions(-)

So, I hate the way async_tx does these checks on each operation, and
it's ok for me to say that because it's my fault. Really it's md that
should be validating engine offload capabilities once at the beginning
of time. I'd rather we move in that direction than continue to pile
onto a bad design.

Re: [PATCH 3/6] async_tx: Handle DMA devices having support for fewer PQ coefficients

[Dan Williams]

On Wed, Feb 1, 2017 at 8:47 PM, Anup Patel  wrote:
> The DMAENGINE framework assumes that if PQ offload is supported by a
> DMA device then all 256 PQ coefficients are supported. This assumption
> does not hold anymore because we now have BCM-SBA-RAID offload engine
> which supports PQ offload with limited number of PQ coefficients.
>
> This patch extends async_tx APIs to handle DMA devices with support
> for fewer PQ coefficients.
>
> Signed-off-by: Anup Patel 
> Reviewed-by: Scott Branden 
> ---
>  crypto/async_tx/async_pq.c  |  3 +++
>  crypto/async_tx/async_raid6_recov.c | 12 ++--
>  include/linux/dmaengine.h   | 19 +++
>  include/linux/raid/pq.h |  3 +++
>  4 files changed, 35 insertions(+), 2 deletions(-)

So, I hate the way async_tx does these checks on each operation, and
it's ok for me to say that because it's my fault. Really it's md that
should be validating engine offload capabilities once at the beginning
of time. I'd rather we move in that direction than continue to pile
onto a bad design.

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi,

> Am 01.02.2017 um 23:28 schrieb Dmitry Torokhov :
> 
> On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas wrote:
>> Hello Nikolaus,
>> 
>> On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote:
>>> Hi Dmitry, Javier,
>>> 
 Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller :
 
 Hi Dmitry,
 
> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov 
> :
> 
> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov 
>>> :
>>> 
>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
 Fix module table so that the driver is loaded if compiled
 as module and requested by DT.
 
>>> 
>>> I believe I already replied to a similar patch: we alreadyhave necessary
>>> aliases in this driver, we need to fix module loading to use it.
>> 
>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>> 
 We really need to fix it between spi/i23c core and module utils instead
 of keeping adding duplicate IDs all over drivers. We already have OF
 module device table containing the same data, we should be able to use
 it.
>> 
>> And Javier Martinez Canillas replied (23 Nov 2016):
>> 
>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
>>> report OF modaliases, we will have to keep adding these duplicated IDs.
>>> 
>>> And changing the I2C and SPI core isn't trivial since it could break a
>>> lot of drivers that rely on a platform modalias being reported (i.e: no
>>> OF device IDs present in the drivers even when are registered via DT).
>> 
>> Therefore I didn't see a need to change it.
> 
> I agree that changing I2C and SPI core is not trivial, however this is
> no reason for piling up workarounds in all drivers. Are you seriously
> advocating going though *every* driver and copying OF data into I2C/SPI
> instead of doing the right thing and fixing the root of the issue?
 
 If you prefer to have this done (and I agree it would be a tiny 
 improvement),
 please do it for us all. But please after merging this workaround.
>>> 
>>> Have we been lucky to find someone who is able and willing to work on this?
>>> 
>> 
>> As said, changing the core is trivial. A RFC patch is [0].
>> 
>> The problem is how to make sure that this change won't cause regressions
>> in existing drivers.
> 
> If the concern with drivers having I2C or SPI device table, but not OF
> device table, then I think cocinnelle could be used to scan and find
> them.
> 
>> 
>> There was particularly tricky for the spi-nor driver, it doesn't help that
>> a lot of DT are using undocumented compatible strings (sometimes with no
>> vendor prefix). You can see the discussion here [1].
>> 
>> In the same thread Mark Brown said that it wasn't that bad to have the
>> information in the OF device ID table duplicated in a SPI device table.
>> 
>> Certainly isn't the best approach but IMHO is better than the module not
>> loading.
> 
> You can always build the module into kernel or load it by hand if it is
> that important.

Well, it is the only exception on the OpenPandora that does NOT yet load
automatically from the DT.

And sure we can always find a hack or workaround in user-space for everything
the kernel isn't doing well.

> Module autoloading does not work anyway if you have
> several compatible strings, like
> 
>   compatible = "vendor,new-device", "vendor,generic-device";

We don't use that mechanism here since there is only one ads7846 installed
and it won't change.

BR,
Nikolaus

Re: [PATCH v9 6/8] drivers:input:ads7846(+tsc2046): fix spi module table

[H. Nikolaus Schaller]

Hi,

> Am 01.02.2017 um 23:28 schrieb Dmitry Torokhov :
> 
> On Wed, Feb 01, 2017 at 06:14:39PM -0300, Javier Martinez Canillas wrote:
>> Hello Nikolaus,
>> 
>> On 02/01/2017 05:20 PM, H. Nikolaus Schaller wrote:
>>> Hi Dmitry, Javier,
>>> 
 Am 29.01.2017 um 19:25 schrieb H. Nikolaus Schaller :
 
 Hi Dmitry,
 
> Am 29.01.2017 um 19:01 schrieb Dmitry Torokhov 
> :
> 
> On Sun, Jan 29, 2017 at 09:39:39AM +0100, H. Nikolaus Schaller wrote:
>> Hi Dmitry,
>> 
>>> Am 28.01.2017 um 20:35 schrieb Dmitry Torokhov 
>>> :
>>> 
>>> On Wed, Dec 28, 2016 at 03:53:21PM +0100, H. Nikolaus Schaller wrote:
 Fix module table so that the driver is loaded if compiled
 as module and requested by DT.
 
>>> 
>>> I believe I already replied to a similar patch: we alreadyhave necessary
>>> aliases in this driver, we need to fix module loading to use it.
>> 
>> Yes, you did comment on [PATCH v6 7/8] (19 Nov 2016):
>> 
 We really need to fix it between spi/i23c core and module utils instead
 of keeping adding duplicate IDs all over drivers. We already have OF
 module device table containing the same data, we should be able to use
 it.
>> 
>> And Javier Martinez Canillas replied (23 Nov 2016):
>> 
>>> Agreed, unfortunately until the I2C and SPI core are changed to properly
>>> report OF modaliases, we will have to keep adding these duplicated IDs.
>>> 
>>> And changing the I2C and SPI core isn't trivial since it could break a
>>> lot of drivers that rely on a platform modalias being reported (i.e: no
>>> OF device IDs present in the drivers even when are registered via DT).
>> 
>> Therefore I didn't see a need to change it.
> 
> I agree that changing I2C and SPI core is not trivial, however this is
> no reason for piling up workarounds in all drivers. Are you seriously
> advocating going though *every* driver and copying OF data into I2C/SPI
> instead of doing the right thing and fixing the root of the issue?
 
 If you prefer to have this done (and I agree it would be a tiny 
 improvement),
 please do it for us all. But please after merging this workaround.
>>> 
>>> Have we been lucky to find someone who is able and willing to work on this?
>>> 
>> 
>> As said, changing the core is trivial. A RFC patch is [0].
>> 
>> The problem is how to make sure that this change won't cause regressions
>> in existing drivers.
> 
> If the concern with drivers having I2C or SPI device table, but not OF
> device table, then I think cocinnelle could be used to scan and find
> them.
> 
>> 
>> There was particularly tricky for the spi-nor driver, it doesn't help that
>> a lot of DT are using undocumented compatible strings (sometimes with no
>> vendor prefix). You can see the discussion here [1].
>> 
>> In the same thread Mark Brown said that it wasn't that bad to have the
>> information in the OF device ID table duplicated in a SPI device table.
>> 
>> Certainly isn't the best approach but IMHO is better than the module not
>> loading.
> 
> You can always build the module into kernel or load it by hand if it is
> that important.

Well, it is the only exception on the OpenPandora that does NOT yet load
automatically from the DT.

And sure we can always find a hack or workaround in user-space for everything
the kernel isn't doing well.

> Module autoloading does not work anyway if you have
> several compatible strings, like
> 
>   compatible = "vendor,new-device", "vendor,generic-device";

We don't use that mechanism here since there is only one ads7846 installed
and it won't change.

BR,
Nikolaus

Re: [PATCH] gpio: aspeed: Remove dependence on GPIOF_* macros

[Joel Stanley]

On Thu, Feb 2, 2017 at 2:58 PM, Andrew Jeffery  wrote:
> 1736f75d35e47409ad776273133d0f558a4c8253 is a (v2) patch which had
> unresolved review comments[1]. Address the comments by removing the use
> of macros from the consumer header (this patch represents the diff
> between v2 and v3[2]).
>
> [1] https://lkml.org/lkml/2017/1/26/337
> [2] https://lkml.org/lkml/2017/1/26/786
>
> Fixes: 1736f75d35e4 ("gpio: aspeed: Add banks Y, Z, AA, AB and AC")
> Signed-off-by: Andrew Jeffery 

Acked-by: Joel Stanley 

Cheers,

Joel

> ---
>
> Note: This should be applied to pinctrl/devel where the linked GPIO patches
> have landed. See discussion at https://lkml.org/lkml/2017/2/1/390
>
>  drivers/gpio/gpio-aspeed.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
> index 6e4b278a82f1..fb16cc771c0d 100644
> --- a/drivers/gpio/gpio-aspeed.c
> +++ b/drivers/gpio/gpio-aspeed.c
> @@ -15,7 +15,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>
> @@ -259,10 +258,10 @@ static int aspeed_gpio_get_direction(struct gpio_chip 
> *gc, unsigned int offset)
> u32 val;
>
> if (!have_input(gpio, offset))
> -   return GPIOF_DIR_OUT;
> +   return 0;
>
> if (!have_output(gpio, offset))
> -   return GPIOF_DIR_IN;
> +   return 1;
>
> spin_lock_irqsave(>lock, flags);
>
> --
> 2.9.3
>

Re: [PATCH] gpio: aspeed: Remove dependence on GPIOF_* macros

[Joel Stanley]

On Thu, Feb 2, 2017 at 2:58 PM, Andrew Jeffery  wrote:
> 1736f75d35e47409ad776273133d0f558a4c8253 is a (v2) patch which had
> unresolved review comments[1]. Address the comments by removing the use
> of macros from the consumer header (this patch represents the diff
> between v2 and v3[2]).
>
> [1] https://lkml.org/lkml/2017/1/26/337
> [2] https://lkml.org/lkml/2017/1/26/786
>
> Fixes: 1736f75d35e4 ("gpio: aspeed: Add banks Y, Z, AA, AB and AC")
> Signed-off-by: Andrew Jeffery 

Acked-by: Joel Stanley 

Cheers,

Joel

> ---
>
> Note: This should be applied to pinctrl/devel where the linked GPIO patches
> have landed. See discussion at https://lkml.org/lkml/2017/2/1/390
>
>  drivers/gpio/gpio-aspeed.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
> index 6e4b278a82f1..fb16cc771c0d 100644
> --- a/drivers/gpio/gpio-aspeed.c
> +++ b/drivers/gpio/gpio-aspeed.c
> @@ -15,7 +15,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>
> @@ -259,10 +258,10 @@ static int aspeed_gpio_get_direction(struct gpio_chip 
> *gc, unsigned int offset)
> u32 val;
>
> if (!have_input(gpio, offset))
> -   return GPIOF_DIR_OUT;
> +   return 0;
>
> if (!have_output(gpio, offset))
> -   return GPIOF_DIR_IN;
> +   return 1;
>
> spin_lock_irqsave(>lock, flags);
>
> --
> 2.9.3
>

Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

[Jens Axboe]

On 02/01/2017 04:56 AM, Paolo Valente wrote:
>> +/*
>> + * add rq to rbtree and fifo
>> + */
>> +static void dd_insert_request(struct blk_mq_hw_ctx *hctx, struct request 
>> *rq,
>> +  bool at_head)
>> +{
>> +struct request_queue *q = hctx->queue;
>> +struct deadline_data *dd = q->elevator->elevator_data;
>> +const int data_dir = rq_data_dir(rq);
>> +
>> +if (blk_mq_sched_try_insert_merge(q, rq))
>> +return;
>> +
> 
> A related doubt: shouldn't blk_mq_sched_try_insert_merge be invoked
> with the scheduler lock held too, as blk_mq_sched_try_merge, to
> protect (at least) q->last_merge?
>
> In bfq this function is invoked with the lock held.

It doesn't matter which lock you use, as long as:

1) You use the same one consistently
2) It has the same scope as the queue lock (the one you call the
   scheduler lock)

mq-deadline sets up a per-queue structure, deadline_data, and it has a
lock embedded in that structure. This is what mq-deadline uses to
serialize access to its data structures, as well as those in the queue
(like last_merge).

-- 
Jens Axboe

Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

[Jens Axboe]

On 02/01/2017 04:56 AM, Paolo Valente wrote:
>> +/*
>> + * add rq to rbtree and fifo
>> + */
>> +static void dd_insert_request(struct blk_mq_hw_ctx *hctx, struct request 
>> *rq,
>> +  bool at_head)
>> +{
>> +struct request_queue *q = hctx->queue;
>> +struct deadline_data *dd = q->elevator->elevator_data;
>> +const int data_dir = rq_data_dir(rq);
>> +
>> +if (blk_mq_sched_try_insert_merge(q, rq))
>> +return;
>> +
> 
> A related doubt: shouldn't blk_mq_sched_try_insert_merge be invoked
> with the scheduler lock held too, as blk_mq_sched_try_merge, to
> protect (at least) q->last_merge?
>
> In bfq this function is invoked with the lock held.

It doesn't matter which lock you use, as long as:

1) You use the same one consistently
2) It has the same scope as the queue lock (the one you call the
   scheduler lock)

mq-deadline sets up a per-queue structure, deadline_data, and it has a
lock embedded in that structure. This is what mq-deadline uses to
serialize access to its data structures, as well as those in the queue
(like last_merge).

-- 
Jens Axboe

Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

[Jens Axboe]

On 02/01/2017 04:11 AM, Paolo Valente wrote:
>> +static bool dd_bio_merge(struct blk_mq_hw_ctx *hctx, struct bio *bio)
>> +{
>> +struct request_queue *q = hctx->queue;
>> +struct deadline_data *dd = q->elevator->elevator_data;
>> +int ret;
>> +
>> +spin_lock(>lock);
>> +ret = blk_mq_sched_try_merge(q, bio);
>> +spin_unlock(>lock);
>> +
> 
> Hi Jens,
> first, good news, bfq is passing my first sanity checks.  Still, I
> need a little more help for the following issue.  There is a case that
> would be impossible to handle without modifying code outside bfq.  But
> so far such a case never occurred, and I hope that it can never occur.
> I'll try to briefly list all relevant details on this concern of mine,
> so that you can quickly confirm my hope, or highlight where or what I
> am missing.

Remember my earlier advice - it's not a problem to change anything in
the core, in fact I would be surprised if you did not need to. My
foresight isn't THAT good! It's much better to fix up an inconsistency
there, rather than work around it in the consumer of that API.

> First, as done above for mq-deadline, invoking blk_mq_sched_try_merge
> with the scheduler lock held is of course necessary (for example, to
> protect q->last_merge).  This may lead to put_rq_private invoked
> with the lock held, in case of successful merge.

Right, or some other lock with the same scope, as per my other email.

> As a consequence, put_rq_private may be invoked:
> (1) in IRQ context, no scheduler lock held, because of a completion:
> can be handled by deferring work and lock grabbing, because the
> completed request is not queued in the scheduler any more;
> (2) in process context, scheduler lock held, because of the above
> successful merge: must be handled immediately, for consistency,
> because the request is still queued in the scheduler;
> (3) in process context, no scheduler lock held, for some other reason:
> some path apparently may lead to this case, although I've never seen
> it to happen.  Immediate handling, and hence locking, may be needed,
> depending on whether the request is still queued in the scheduler.
> 
> So, my main question is: is case (3) actually impossible?  Should it
> be possible, I guess we would have a problem, because of the
> different lock state with respect to (2).

I agree, there's some inconsistency there, if you potentially need to
grab the lock in your put_rq_private handler. The problem case is #2,
when we have the merge. I would probably suggest that the best way to
handle that is to pass back the dropped request so we can put it outside
of holding the lock.

Let me see if I can come up with a good solution for this. We have to be
consistent in how we invoke the scheduler functions, we can't have hooks
that are called in unknown lock states. I also don't want you to have to
add defer work handling in that kind of path, that will impact your
performance and overhead.

> Finally, I hope that it is certainly impossible to have a case (4): in
> IRQ context, no lock held, but with the request in the scheduler.

That should not be possible.

Edit: since I'm on a flight and email won't send, I had a few minutes to
hack this up. Totally untested, but something like the below should do
it. Not super pretty... I'll play with this a bit more tomorrow.


diff --git a/block/blk-core.c b/block/blk-core.c
index c142de090c41..530a9a3f60c9 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1609,7 +1609,7 @@ static blk_qc_t blk_queue_bio(struct request_queue *q, 
struct bio *bio)
 {
struct blk_plug *plug;
int el_ret, where = ELEVATOR_INSERT_SORT;
-   struct request *req;
+   struct request *req, *free;
unsigned int request_count = 0;
unsigned int wb_acct;
 
@@ -1650,15 +1650,21 @@ static blk_qc_t blk_queue_bio(struct request_queue *q, 
struct bio *bio)
if (el_ret == ELEVATOR_BACK_MERGE) {
if (bio_attempt_back_merge(q, req, bio)) {
elv_bio_merged(q, req, bio);
-   if (!attempt_back_merge(q, req))
+   free = attempt_back_merge(q, req);
+   if (!free)
elv_merged_request(q, req, el_ret);
+   else
+   __blk_put_request(q, free);
goto out_unlock;
}
} else if (el_ret == ELEVATOR_FRONT_MERGE) {
if (bio_attempt_front_merge(q, req, bio)) {
elv_bio_merged(q, req, bio);
-   if (!attempt_front_merge(q, req))
+   free = attempt_front_merge(q, req);
+   if (!free)
elv_merged_request(q, req, el_ret);
+   else
+   __blk_put_request(q, free);
goto out_unlock;
}
}
diff --git a/block/blk-merge.c 

Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler

[Jens Axboe]

On 02/01/2017 04:11 AM, Paolo Valente wrote:
>> +static bool dd_bio_merge(struct blk_mq_hw_ctx *hctx, struct bio *bio)
>> +{
>> +struct request_queue *q = hctx->queue;
>> +struct deadline_data *dd = q->elevator->elevator_data;
>> +int ret;
>> +
>> +spin_lock(>lock);
>> +ret = blk_mq_sched_try_merge(q, bio);
>> +spin_unlock(>lock);
>> +
> 
> Hi Jens,
> first, good news, bfq is passing my first sanity checks.  Still, I
> need a little more help for the following issue.  There is a case that
> would be impossible to handle without modifying code outside bfq.  But
> so far such a case never occurred, and I hope that it can never occur.
> I'll try to briefly list all relevant details on this concern of mine,
> so that you can quickly confirm my hope, or highlight where or what I
> am missing.

Remember my earlier advice - it's not a problem to change anything in
the core, in fact I would be surprised if you did not need to. My
foresight isn't THAT good! It's much better to fix up an inconsistency
there, rather than work around it in the consumer of that API.

> First, as done above for mq-deadline, invoking blk_mq_sched_try_merge
> with the scheduler lock held is of course necessary (for example, to
> protect q->last_merge).  This may lead to put_rq_private invoked
> with the lock held, in case of successful merge.

Right, or some other lock with the same scope, as per my other email.

> As a consequence, put_rq_private may be invoked:
> (1) in IRQ context, no scheduler lock held, because of a completion:
> can be handled by deferring work and lock grabbing, because the
> completed request is not queued in the scheduler any more;
> (2) in process context, scheduler lock held, because of the above
> successful merge: must be handled immediately, for consistency,
> because the request is still queued in the scheduler;
> (3) in process context, no scheduler lock held, for some other reason:
> some path apparently may lead to this case, although I've never seen
> it to happen.  Immediate handling, and hence locking, may be needed,
> depending on whether the request is still queued in the scheduler.
> 
> So, my main question is: is case (3) actually impossible?  Should it
> be possible, I guess we would have a problem, because of the
> different lock state with respect to (2).

I agree, there's some inconsistency there, if you potentially need to
grab the lock in your put_rq_private handler. The problem case is #2,
when we have the merge. I would probably suggest that the best way to
handle that is to pass back the dropped request so we can put it outside
of holding the lock.

Let me see if I can come up with a good solution for this. We have to be
consistent in how we invoke the scheduler functions, we can't have hooks
that are called in unknown lock states. I also don't want you to have to
add defer work handling in that kind of path, that will impact your
performance and overhead.

> Finally, I hope that it is certainly impossible to have a case (4): in
> IRQ context, no lock held, but with the request in the scheduler.

That should not be possible.

Edit: since I'm on a flight and email won't send, I had a few minutes to
hack this up. Totally untested, but something like the below should do
it. Not super pretty... I'll play with this a bit more tomorrow.


diff --git a/block/blk-core.c b/block/blk-core.c
index c142de090c41..530a9a3f60c9 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1609,7 +1609,7 @@ static blk_qc_t blk_queue_bio(struct request_queue *q, 
struct bio *bio)
 {
struct blk_plug *plug;
int el_ret, where = ELEVATOR_INSERT_SORT;
-   struct request *req;
+   struct request *req, *free;
unsigned int request_count = 0;
unsigned int wb_acct;
 
@@ -1650,15 +1650,21 @@ static blk_qc_t blk_queue_bio(struct request_queue *q, 
struct bio *bio)
if (el_ret == ELEVATOR_BACK_MERGE) {
if (bio_attempt_back_merge(q, req, bio)) {
elv_bio_merged(q, req, bio);
-   if (!attempt_back_merge(q, req))
+   free = attempt_back_merge(q, req);
+   if (!free)
elv_merged_request(q, req, el_ret);
+   else
+   __blk_put_request(q, free);
goto out_unlock;
}
} else if (el_ret == ELEVATOR_FRONT_MERGE) {
if (bio_attempt_front_merge(q, req, bio)) {
elv_bio_merged(q, req, bio);
-   if (!attempt_front_merge(q, req))
+   free = attempt_front_merge(q, req);
+   if (!free)
elv_merged_request(q, req, el_ret);
+   else
+   __blk_put_request(q, free);
goto out_unlock;
}
}
diff --git a/block/blk-merge.c 

Re: [RFC 0/6]mm: add new LRU list for MADV_FREE pages

[Minchan Kim]

Hi Johannes,

On Tue, Jan 31, 2017 at 04:38:10PM -0500, Johannes Weiner wrote:
> On Tue, Jan 31, 2017 at 11:45:47AM -0800, Shaohua Li wrote:
> > On Tue, Jan 31, 2017 at 01:59:49PM -0500, Johannes Weiner wrote:
> > > Hi Shaohua,
> > > 
> > > On Sun, Jan 29, 2017 at 09:51:17PM -0800, Shaohua Li wrote:
> > > > We are trying to use MADV_FREE in jemalloc. Several issues are found. 
> > > > Without
> > > > solving the issues, jemalloc can't use the MADV_FREE feature.
> > > > - Doesn't support system without swap enabled. Because if swap is off, 
> > > > we can't
> > > >   or can't efficiently age anonymous pages. And since MADV_FREE pages 
> > > > are mixed
> > > >   with other anonymous pages, we can't reclaim MADV_FREE pages. In 
> > > > current
> > > >   implementation, MADV_FREE will fallback to MADV_DONTNEED without swap 
> > > > enabled.
> > > >   But in our environment, a lot of machines don't enable swap. This 
> > > > will prevent
> > > >   our setup using MADV_FREE.
> > > > - Increases memory pressure. page reclaim bias file pages reclaim 
> > > > against
> > > >   anonymous pages. This doesn't make sense for MADV_FREE pages, because 
> > > > those
> > > >   pages could be freed easily and refilled with very slight penality. 
> > > > Even page
> > > >   reclaim doesn't bias file pages, there is still an issue, because 
> > > > MADV_FREE
> > > >   pages and other anonymous pages are mixed together. To reclaim a 
> > > > MADV_FREE
> > > >   page, we probably must scan a lot of other anonymous pages, which is
> > > >   inefficient. In our test, we usually see oom with MADV_FREE enabled 
> > > > and nothing
> > > >   without it.
> > > 
> > > Fully agreed, the anon LRU is a bad place for these pages.
> > > 
> > > > For the first two issues, introducing a new LRU list for MADV_FREE 
> > > > pages could
> > > > solve the issues. We can directly reclaim MADV_FREE pages without 
> > > > writting them
> > > > out to swap, so the first issue could be fixed. If only MADV_FREE pages 
> > > > are in
> > > > the new list, page reclaim can easily reclaim such pages without 
> > > > interference
> > > > of file or anonymous pages. The memory pressure issue will disappear.
> > > 
> > > Do we actually need a new page flag and a special LRU for them? These
> > > pages are basically like clean cache pages at that point. What do you
> > > think about clearing their PG_swapbacked flag on MADV_FREE and moving
> > > them to the inactive file list? The way isolate+putback works should
> > > not even need much modification, something like clear_page_mlock().
> > > 
> > > When the reclaim scanner finds anon && dirty && !swapbacked, it can
> > > again set PG_swapbacked and goto keep_locked to move the page back
> > > into the anon LRU to get reclaimed according to swapping rules.
> > 
> > Interesting idea! Not sure though, the MADV_FREE pages are actually 
> > anonymous
> > pages, this will introduce confusion. On the other hand, if the MADV_FREE 
> > pages
> > are mixed with inactive file pages, page reclaim need to reclaim a lot of 
> > file
> > pages first before reclaim the MADV_FREE pages. This doesn't look good. The
> > point of a separate LRU is to avoid scan other anon/file pages.
> 
> The LRU code and the rest of VM already use independent page type
> distinctions. That's because shmem pages are !PageAnon - they have a
> page->mapping that points to a real address space, not an anon_vma -
> but they are swapbacked and thus go through the anon LRU. This would
> just do the reverse: put PageAnon pages on the file LRU when they
> don't contain valid data and are thus not swapbacked.
> 
> As far as mixing with inactive file pages goes, it'd be possible to
> link the MADV_FREE pages to the tail of the inactive list, rather than
> the head. That said, I'm not sure reclaiming use-once filesystem cache
> before MADV_FREE is such a bad policy. MADV_FREE retains the vmas for
> the sole purpose of reusing them in the (near) future. That is
> actually a stronger reuse signal than we have for use-once file pages.
> If somebody does continuous writes to a logfile or a one-off search
> through one or more files, we should actually reclaim that cache
> before we go after MADV_FREE pages that are temporarily invalidated.

Yes, we should be careful on this issue. It was main arguable point.
How about moving them to head of inactive file, not tail if we want to
go with inactive file LRU?

With that, VM try to reclaim file pages first from the tail of list
and if pages reclaimed were workingset, it could be activated by
workingset_refault. Otherwise, we can discard use-once pages without
puring *madv_free* pages so I think it's good compromise.

What do you think?

Re: [RFC 0/6]mm: add new LRU list for MADV_FREE pages

[Minchan Kim]

Hi Johannes,

On Tue, Jan 31, 2017 at 04:38:10PM -0500, Johannes Weiner wrote:
> On Tue, Jan 31, 2017 at 11:45:47AM -0800, Shaohua Li wrote:
> > On Tue, Jan 31, 2017 at 01:59:49PM -0500, Johannes Weiner wrote:
> > > Hi Shaohua,
> > > 
> > > On Sun, Jan 29, 2017 at 09:51:17PM -0800, Shaohua Li wrote:
> > > > We are trying to use MADV_FREE in jemalloc. Several issues are found. 
> > > > Without
> > > > solving the issues, jemalloc can't use the MADV_FREE feature.
> > > > - Doesn't support system without swap enabled. Because if swap is off, 
> > > > we can't
> > > >   or can't efficiently age anonymous pages. And since MADV_FREE pages 
> > > > are mixed
> > > >   with other anonymous pages, we can't reclaim MADV_FREE pages. In 
> > > > current
> > > >   implementation, MADV_FREE will fallback to MADV_DONTNEED without swap 
> > > > enabled.
> > > >   But in our environment, a lot of machines don't enable swap. This 
> > > > will prevent
> > > >   our setup using MADV_FREE.
> > > > - Increases memory pressure. page reclaim bias file pages reclaim 
> > > > against
> > > >   anonymous pages. This doesn't make sense for MADV_FREE pages, because 
> > > > those
> > > >   pages could be freed easily and refilled with very slight penality. 
> > > > Even page
> > > >   reclaim doesn't bias file pages, there is still an issue, because 
> > > > MADV_FREE
> > > >   pages and other anonymous pages are mixed together. To reclaim a 
> > > > MADV_FREE
> > > >   page, we probably must scan a lot of other anonymous pages, which is
> > > >   inefficient. In our test, we usually see oom with MADV_FREE enabled 
> > > > and nothing
> > > >   without it.
> > > 
> > > Fully agreed, the anon LRU is a bad place for these pages.
> > > 
> > > > For the first two issues, introducing a new LRU list for MADV_FREE 
> > > > pages could
> > > > solve the issues. We can directly reclaim MADV_FREE pages without 
> > > > writting them
> > > > out to swap, so the first issue could be fixed. If only MADV_FREE pages 
> > > > are in
> > > > the new list, page reclaim can easily reclaim such pages without 
> > > > interference
> > > > of file or anonymous pages. The memory pressure issue will disappear.
> > > 
> > > Do we actually need a new page flag and a special LRU for them? These
> > > pages are basically like clean cache pages at that point. What do you
> > > think about clearing their PG_swapbacked flag on MADV_FREE and moving
> > > them to the inactive file list? The way isolate+putback works should
> > > not even need much modification, something like clear_page_mlock().
> > > 
> > > When the reclaim scanner finds anon && dirty && !swapbacked, it can
> > > again set PG_swapbacked and goto keep_locked to move the page back
> > > into the anon LRU to get reclaimed according to swapping rules.
> > 
> > Interesting idea! Not sure though, the MADV_FREE pages are actually 
> > anonymous
> > pages, this will introduce confusion. On the other hand, if the MADV_FREE 
> > pages
> > are mixed with inactive file pages, page reclaim need to reclaim a lot of 
> > file
> > pages first before reclaim the MADV_FREE pages. This doesn't look good. The
> > point of a separate LRU is to avoid scan other anon/file pages.
> 
> The LRU code and the rest of VM already use independent page type
> distinctions. That's because shmem pages are !PageAnon - they have a
> page->mapping that points to a real address space, not an anon_vma -
> but they are swapbacked and thus go through the anon LRU. This would
> just do the reverse: put PageAnon pages on the file LRU when they
> don't contain valid data and are thus not swapbacked.
> 
> As far as mixing with inactive file pages goes, it'd be possible to
> link the MADV_FREE pages to the tail of the inactive list, rather than
> the head. That said, I'm not sure reclaiming use-once filesystem cache
> before MADV_FREE is such a bad policy. MADV_FREE retains the vmas for
> the sole purpose of reusing them in the (near) future. That is
> actually a stronger reuse signal than we have for use-once file pages.
> If somebody does continuous writes to a logfile or a one-off search
> through one or more files, we should actually reclaim that cache
> before we go after MADV_FREE pages that are temporarily invalidated.

Yes, we should be careful on this issue. It was main arguable point.
How about moving them to head of inactive file, not tail if we want to
go with inactive file LRU?

With that, VM try to reclaim file pages first from the tail of list
and if pages reclaimed were workingset, it could be activated by
workingset_refault. Otherwise, we can discard use-once pages without
puring *madv_free* pages so I think it's good compromise.

What do you think?

Re: [PATCH v5 1/3] dt: bindings: add documentation for zx2967 family thermal sensor

[Eduardo Valentin]

Hey Bao,

On Wed, Jan 18, 2017 at 12:42:00PM +0800, Baoyou Xie wrote:
> This patch adds dt-binding documentation for zx2967 family thermal sensor.
> 
> Signed-off-by: Baoyou Xie 
> Acked-by: Rob Herring 
> Reviewed-by: Shawn Guo 
> ---
>  .../devicetree/bindings/thermal/zx2967-thermal.txt | 109 
> +
>  1 file changed, 109 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
> 
> diff --git a/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
> new file mode 100644
> index 000..a96c8b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
> @@ -0,0 +1,109 @@
> +* ZTE zx2967 family Thermal
> +
> +Required Properties:
> +- compatible: should be one of the following.
> +* zte,zx296718-thermal
> +- reg: physical base address of the controller and length of memory mapped
> +region.
> +- clocks : Pairs of phandle and specifier referencing the controller's 
> clocks.
> +- clock-names: "gate" for the topcrm clock.
> +"pclk" for the apb clock.
> +- #thermal-sensor-cells: must be 0.
> +
> +Example for tempsensor:
> +
> + tempsensor: tempsensor@148a000 {
> + compatible = "zte,zx296718-thermal";
> + reg = <0x0148a000 0x20>;
> + clocks = < TEMPSENSOR_GATE>, < AUDIO_TS_PCLK>;
> + clock-names = "gate", "pclk";
> + #thermal-sensor-cells = <0>;
> + };
> +
> +Example for cooling device:
> +
> + cooling_dev: cooling_dev {
> + cluster0_cooling_dev: cluster0-cooling-dev {
> + #cooling-cells = <2>;
> + cpumask = <0xf>;
> + capacitance = <1500>;
> + };
> +
> + cluster1_cooling_dev: cluster1-cooling-dev {
> + #cooling-cells = <2>;
> + cpumask = <0x30>;
> + capacitance = <2000>;
> + };
> + };
> +
> +Example for thermal zones:
> +
> + thermal-zones {
> + zx296718_thermal: zx296718_thermal {
> + polling-delay-passive = <500>;
> + polling-delay = <1000>;
> + sustainable-power = <6500>;
> +
> + thermal-sensors = < 0>;

You may want to also add here:
coefficients = <1951  -922>;

Those will be populated in your tz->tzp->slope and tz->tz->offset.
Then you can read the already parsed data in your driver
in your .get_temp() callback, for example.

Can you please check if the above works for you?


BR,

Eduardo

Re: [PATCH v5 1/3] dt: bindings: add documentation for zx2967 family thermal sensor

[Eduardo Valentin]

Hey Bao,

On Wed, Jan 18, 2017 at 12:42:00PM +0800, Baoyou Xie wrote:
> This patch adds dt-binding documentation for zx2967 family thermal sensor.
> 
> Signed-off-by: Baoyou Xie 
> Acked-by: Rob Herring 
> Reviewed-by: Shawn Guo 
> ---
>  .../devicetree/bindings/thermal/zx2967-thermal.txt | 109 
> +
>  1 file changed, 109 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
> 
> diff --git a/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt 
> b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
> new file mode 100644
> index 000..a96c8b3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/thermal/zx2967-thermal.txt
> @@ -0,0 +1,109 @@
> +* ZTE zx2967 family Thermal
> +
> +Required Properties:
> +- compatible: should be one of the following.
> +* zte,zx296718-thermal
> +- reg: physical base address of the controller and length of memory mapped
> +region.
> +- clocks : Pairs of phandle and specifier referencing the controller's 
> clocks.
> +- clock-names: "gate" for the topcrm clock.
> +"pclk" for the apb clock.
> +- #thermal-sensor-cells: must be 0.
> +
> +Example for tempsensor:
> +
> + tempsensor: tempsensor@148a000 {
> + compatible = "zte,zx296718-thermal";
> + reg = <0x0148a000 0x20>;
> + clocks = < TEMPSENSOR_GATE>, < AUDIO_TS_PCLK>;
> + clock-names = "gate", "pclk";
> + #thermal-sensor-cells = <0>;
> + };
> +
> +Example for cooling device:
> +
> + cooling_dev: cooling_dev {
> + cluster0_cooling_dev: cluster0-cooling-dev {
> + #cooling-cells = <2>;
> + cpumask = <0xf>;
> + capacitance = <1500>;
> + };
> +
> + cluster1_cooling_dev: cluster1-cooling-dev {
> + #cooling-cells = <2>;
> + cpumask = <0x30>;
> + capacitance = <2000>;
> + };
> + };
> +
> +Example for thermal zones:
> +
> + thermal-zones {
> + zx296718_thermal: zx296718_thermal {
> + polling-delay-passive = <500>;
> + polling-delay = <1000>;
> + sustainable-power = <6500>;
> +
> + thermal-sensors = < 0>;

You may want to also add here:
coefficients = <1951  -922>;

Those will be populated in your tz->tzp->slope and tz->tz->offset.
Then you can read the already parsed data in your driver
in your .get_temp() callback, for example.

Can you please check if the above works for you?


BR,

Eduardo

Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures

[Andy Lutomirski]

On Wed, Feb 1, 2017 at 3:12 PM, James Bottomley
 wrote:
> On Tue, 2017-01-31 at 16:26 -0800, Andrew Morton wrote:
>> On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller 
>> wrote:
>>
>> > The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but
>> > implemented for PowerPC only. This trivial patch adds support for
>> > this syscall for all other architectures.
>>
>> Seems reasonable.  I guess.  Why is this needed?
>
> I don't think it is other than for PPC.  If you're not variable endian
> (which is only PPC to date), then you should know a priori what endian
> you are from the #defines in userspace.

I find it vaguely odd even on PPC.  Surely you can tell what your
endianness is directly.  (An API to query the endianness of another
task would be useful, though.)

Re: [PATCH] prctl: implement PR_GET_ENDIAN for all architectures

[Andy Lutomirski]

On Wed, Feb 1, 2017 at 3:12 PM, James Bottomley
 wrote:
> On Tue, 2017-01-31 at 16:26 -0800, Andrew Morton wrote:
>> On Sat, 28 Jan 2017 12:13:10 +0100 Helge Deller 
>> wrote:
>>
>> > The prctl(PR_GET_ENDIAN) syscall was added to Kernel 2.6.18, but
>> > implemented for PowerPC only. This trivial patch adds support for
>> > this syscall for all other architectures.
>>
>> Seems reasonable.  I guess.  Why is this needed?
>
> I don't think it is other than for PPC.  If you're not variable endian
> (which is only PPC to date), then you should know a priori what endian
> you are from the #defines in userspace.

I find it vaguely odd even on PPC.  Surely you can tell what your
endianness is directly.  (An API to query the endianness of another
task would be useful, though.)

Re: [PATCH v5 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family

[Eduardo Valentin]

Hey Bao,

On Wed, Jan 18, 2017 at 12:42:02PM +0800, Baoyou Xie wrote:
> This patch adds thermal driver for ZTE's zx2967 family.
> 
> Signed-off-by: Baoyou Xie 



> +
> + /*
> +  * Calculate temperature
> +  *   922initial value of calibration cure
> +  *   1.951  slope of calibration cure
> +  */
> + *temp = DIV_ROUND_CLOSEST((val - 922) * 1000, 1951);

You can describe the offset and slope using DT and avoid this to be hard
coded in your driver. Besides, if you read offset and slope from DT,
your driver will be ready for any upcoming sensor addition that you may
want to support in future, given that would required slope and offset
change, per sensor, per chip version.

Can you please check if you can move these to DT?

BR,
> -- 
> 2.7.4
> 

Re: [PATCH v5 3/3] thermal: zx2967: add thermal driver for ZTE's zx2967 family

[Eduardo Valentin]

Hey Bao,

On Wed, Jan 18, 2017 at 12:42:02PM +0800, Baoyou Xie wrote:
> This patch adds thermal driver for ZTE's zx2967 family.
> 
> Signed-off-by: Baoyou Xie 



> +
> + /*
> +  * Calculate temperature
> +  *   922initial value of calibration cure
> +  *   1.951  slope of calibration cure
> +  */
> + *temp = DIV_ROUND_CLOSEST((val - 922) * 1000, 1951);

You can describe the offset and slope using DT and avoid this to be hard
coded in your driver. Besides, if you read offset and slope from DT,
your driver will be ready for any upcoming sensor addition that you may
want to support in future, given that would required slope and offset
change, per sensor, per chip version.

Can you please check if you can move these to DT?

BR,
> -- 
> 2.7.4
> 

Re: [PATCH] printk: fix printk.devkmsg sysctl

[Sergey Senozhatsky]

Hello,

sorry, catching up with the emails.

there seems to be two independent patches. I'll just comment in one
thread.



On (01/31/17 14:55), Petr Mladek wrote:
[..]
> From 0ce6125caf314270cb48202390d8a0938fdf316e Mon Sep 17 00:00:00 2001
> From: Petr Mladek 
> Date: Tue, 31 Jan 2017 12:00:13 +0100
> Subject: [PATCH] printk: Fix printk.devkmsg sysctl
> 
> The code handling write into /proc/sys/kernel/printk_devkmsg expects
> a new line at the end of the string but does not check it. As a result
> it allows:
> 
>  # echo -n offX > /proc/sys/kernel/printk_devkmsg
>  #
> 
> while at the same time it rejects legitimate uses:
> 
>  # echo -n off > /proc/sys/kernel/printk_devkmsg
>  -sh: echo: write error: Invalid argument
> 

for these cases (echo/echo -n/echo -e/etc. etc.) I usually use
sysfs_streq() from lib/string.c

wouldn't sysfs_streq() do the trick here?

-ss

Re: [PATCH] printk: fix printk.devkmsg sysctl

[Sergey Senozhatsky]

Hello,

sorry, catching up with the emails.

there seems to be two independent patches. I'll just comment in one
thread.



On (01/31/17 14:55), Petr Mladek wrote:
[..]
> From 0ce6125caf314270cb48202390d8a0938fdf316e Mon Sep 17 00:00:00 2001
> From: Petr Mladek 
> Date: Tue, 31 Jan 2017 12:00:13 +0100
> Subject: [PATCH] printk: Fix printk.devkmsg sysctl
> 
> The code handling write into /proc/sys/kernel/printk_devkmsg expects
> a new line at the end of the string but does not check it. As a result
> it allows:
> 
>  # echo -n offX > /proc/sys/kernel/printk_devkmsg
>  #
> 
> while at the same time it rejects legitimate uses:
> 
>  # echo -n off > /proc/sys/kernel/printk_devkmsg
>  -sh: echo: write error: Invalid argument
> 

for these cases (echo/echo -n/echo -e/etc. etc.) I usually use
sysfs_streq() from lib/string.c

wouldn't sysfs_streq() do the trick here?

-ss

[PATCH 4/6] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()

[Anup Patel]

The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output
of Tx descriptor is to be used by next/dependent Tx descriptor.

The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome()
when calling dma->device_prep_dma_pq() under following conditions:
1. ASYNC_TX_FENCE not set in submit->flags
2. DMA_PREP_FENCE not set in dma_flags
3. src_cnt (= (disks - 2)) is greater than dma_maxpq(dma, dma_flags)

This patch fixes DMA_PREP_FENCE usage in do_async_gen_syndrome() taking
inspiration from do_async_xor() implementation.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 crypto/async_tx/async_pq.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index 16c6526..947cf35 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -62,9 +62,6 @@ do_async_gen_syndrome(struct dma_chan *chan,
dma_addr_t dma_dest[2];
int src_off = 0;
 
-   if (submit->flags & ASYNC_TX_FENCE)
-   dma_flags |= DMA_PREP_FENCE;
-
while (src_cnt > 0) {
submit->flags = flags_orig;
pq_src_cnt = min(src_cnt, dma_maxpq(dma, dma_flags));
@@ -83,6 +80,8 @@ do_async_gen_syndrome(struct dma_chan *chan,
if (cb_fn_orig)
dma_flags |= DMA_PREP_INTERRUPT;
}
+   if (submit->flags & ASYNC_TX_FENCE)
+   dma_flags |= DMA_PREP_FENCE;
 
/* Drivers force forward progress in case they can not provide
 * a descriptor
-- 
2.7.4

[PATCH 6/6] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

[Anup Patel]

This patch adds the DT bindings document for newly added Broadcom
SBA RAID driver.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt

diff --git a/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt 
b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
new file mode 100644
index 000..092913a
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
@@ -0,0 +1,29 @@
+* Broadcom SBA RAID engine
+
+Required properties:
+- compatible: Should be one of the following
+ "brcm,iproc-sba"
+ "brcm,iproc-sba-v2"
+  The "brcm,iproc-sba" has support for only 6 PQ coefficients
+  The "brcm,iproc-sba-v2" has support for only 30 PQ coefficients
+- mboxes: List of phandle and mailbox channel specifiers
+
+Example:
+
+raid_mbox: mbox@6740 {
+   ...
+   #mbox-cells = <3>;
+   ...
+};
+
+raid0 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 0 0x1 0x>,
+<_mbox 1 0x1 0x>,
+<_mbox 2 0x1 0x>,
+<_mbox 3 0x1 0x>,
+<_mbox 4 0x1 0x>,
+<_mbox 5 0x1 0x>,
+<_mbox 6 0x1 0x>,
+<_mbox 7 0x1 0x>;
+};
-- 
2.7.4

[PATCH 6/6] dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

[Anup Patel]

This patch adds the DT bindings document for newly added Broadcom
SBA RAID driver.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 .../devicetree/bindings/dma/brcm,iproc-sba.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt

diff --git a/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt 
b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
new file mode 100644
index 000..092913a
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
@@ -0,0 +1,29 @@
+* Broadcom SBA RAID engine
+
+Required properties:
+- compatible: Should be one of the following
+ "brcm,iproc-sba"
+ "brcm,iproc-sba-v2"
+  The "brcm,iproc-sba" has support for only 6 PQ coefficients
+  The "brcm,iproc-sba-v2" has support for only 30 PQ coefficients
+- mboxes: List of phandle and mailbox channel specifiers
+
+Example:
+
+raid_mbox: mbox@6740 {
+   ...
+   #mbox-cells = <3>;
+   ...
+};
+
+raid0 {
+   compatible = "brcm,iproc-sba-v2";
+   mboxes = <_mbox 0 0x1 0x>,
+<_mbox 1 0x1 0x>,
+<_mbox 2 0x1 0x>,
+<_mbox 3 0x1 0x>,
+<_mbox 4 0x1 0x>,
+<_mbox 5 0x1 0x>,
+<_mbox 6 0x1 0x>,
+<_mbox 7 0x1 0x>;
+};
-- 
2.7.4

[PATCH 4/6] async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()

[Anup Patel]

The DMA_PREP_FENCE is to be used when preparing Tx descriptor if output
of Tx descriptor is to be used by next/dependent Tx descriptor.

The DMA_PREP_FENSE will not be set correctly in do_async_gen_syndrome()
when calling dma->device_prep_dma_pq() under following conditions:
1. ASYNC_TX_FENCE not set in submit->flags
2. DMA_PREP_FENCE not set in dma_flags
3. src_cnt (= (disks - 2)) is greater than dma_maxpq(dma, dma_flags)

This patch fixes DMA_PREP_FENCE usage in do_async_gen_syndrome() taking
inspiration from do_async_xor() implementation.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 crypto/async_tx/async_pq.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index 16c6526..947cf35 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -62,9 +62,6 @@ do_async_gen_syndrome(struct dma_chan *chan,
dma_addr_t dma_dest[2];
int src_off = 0;
 
-   if (submit->flags & ASYNC_TX_FENCE)
-   dma_flags |= DMA_PREP_FENCE;
-
while (src_cnt > 0) {
submit->flags = flags_orig;
pq_src_cnt = min(src_cnt, dma_maxpq(dma, dma_flags));
@@ -83,6 +80,8 @@ do_async_gen_syndrome(struct dma_chan *chan,
if (cb_fn_orig)
dma_flags |= DMA_PREP_INTERRUPT;
}
+   if (submit->flags & ASYNC_TX_FENCE)
+   dma_flags |= DMA_PREP_FENCE;
 
/* Drivers force forward progress in case they can not provide
 * a descriptor
-- 
2.7.4

[PATCH 5/6] dmaengine: Add Broadcom SBA RAID driver

[Anup Patel]

The Broadcom stream buffer accelerator (SBA) provides offloading
capabilities for RAID operations. This SBA offload engine is
accessible via Broadcom SoC specific ring manager.

This patch adds Broadcom SBA RAID driver which provides one
DMA device with RAID capabilities using one or more Broadcom
SoC specific ring manager channels. The SBA RAID driver in its
current shape implements memcpy, xor, and pq operations.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/dma/Kconfig|   13 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1309 
 3 files changed, 1323 insertions(+)
 create mode 100644 drivers/dma/bcm-sba-raid.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 263495d..58d0463 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -99,6 +99,19 @@ config AXI_DMAC
  controller is often used in Analog Device's reference designs for FPGA
  platforms.
 
+config BCM_SBA_RAID
+tristate "Broadcom SBA RAID engine support"
+depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
+select DMA_ENGINE
+select DMA_ENGINE_RAID
+   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
+   default ARCH_BCM_IPROC
+help
+ Enable support for Broadcom SBA RAID Engine. The SBA RAID
+ engine is available on most of the Broadcom iProc SoCs. It
+ has the capability to offload memcpy, xor and pq computation
+ for raid5/6.
+
 config COH901318
bool "ST-Ericsson COH901318 DMA support"
select DMA_ENGINE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index a4fa336..ba96bdd 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
 obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
 obj-$(CONFIG_AT_XDMAC) += at_xdmac.o
 obj-$(CONFIG_AXI_DMAC) += dma-axi-dmac.o
+obj-$(CONFIG_BCM_SBA_RAID) += bcm-sba-raid.o
 obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
 obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
new file mode 100644
index 000..bf39f3f
--- /dev/null
+++ b/drivers/dma/bcm-sba-raid.c
@@ -0,0 +1,1309 @@
+/*
+ * Copyright (C) 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Broadcom SBA RAID Driver
+ *
+ * The Broadcom stream buffer accelerator (SBA) provides offloading
+ * capabilities for RAID operations. The SBA offload engine is accessible
+ * via Broadcom SoC specific ring manager. Two or more offload engines
+ * can share same Broadcom SoC specific ring manager due to this Broadcom
+ * SoC specific ring manager driver is implemented as a mailbox controller
+ * driver and offload engine drivers are implemented as mallbox clients.
+ *
+ * Typically, Broadcom SoC specific ring manager will implement larger
+ * number of hardware rings over one or more SBA hardware devices. By
+ * design, the internal buffer size of SBA hardware device is limited
+ * but all offload operations supported by SBA can be broken down into
+ * multiple small size requests and executed parallely on multiple SBA
+ * hardware devices for achieving high through-put.
+ *
+ * The Broadcom SBA RAID driver does not require any register programming
+ * except submitting request to SBA hardware device via mailbox channels.
+ * This driver implements a DMA device with one DMA channel using a set
+ * of mailbox channels provided by Broadcom SoC specific ring manager
+ * driver. To exploit parallelism (as described above), all DMA request
+ * coming to SBA RAID DMA channel are broken down to smaller requests
+ * and submitted to multiple mailbox channels in round-robin fashion.
+ * For having more SBA DMA channels, we can create more SBA device nodes
+ * in Broadcom SoC specific DTS based on number of hardware rings supported
+ * by Broadcom SoC ring manager.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+
+/* SBA command helper macros */
+#define SBA_DEC(_d, _s, _m)(((_d) >> (_s)) & (_m))
+#define SBA_ENC(_d, _v, _s, _m)\
+   do {\
+   (_d) &= ~((u64)(_m) << (_s));   \
+   (_d) |= (((u64)(_v) & (_m)) << (_s));   \
+   } while (0)
+
+/* SBA command related defines */
+#define SBA_TYPE_SHIFT 48
+#define SBA_TYPE_MASK  0x3
+#define SBA_TYPE_A 0x0
+#define SBA_TYPE_B

[PATCH 5/6] dmaengine: Add Broadcom SBA RAID driver

[Anup Patel]

The Broadcom stream buffer accelerator (SBA) provides offloading
capabilities for RAID operations. This SBA offload engine is
accessible via Broadcom SoC specific ring manager.

This patch adds Broadcom SBA RAID driver which provides one
DMA device with RAID capabilities using one or more Broadcom
SoC specific ring manager channels. The SBA RAID driver in its
current shape implements memcpy, xor, and pq operations.

Signed-off-by: Anup Patel 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 
---
 drivers/dma/Kconfig|   13 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1309 
 3 files changed, 1323 insertions(+)
 create mode 100644 drivers/dma/bcm-sba-raid.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 263495d..58d0463 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -99,6 +99,19 @@ config AXI_DMAC
  controller is often used in Analog Device's reference designs for FPGA
  platforms.
 
+config BCM_SBA_RAID
+tristate "Broadcom SBA RAID engine support"
+depends on (ARM64 && MAILBOX && RAID6_PQ) || COMPILE_TEST
+select DMA_ENGINE
+select DMA_ENGINE_RAID
+   select ASYNC_TX_ENABLE_CHANNEL_SWITCH
+   default ARCH_BCM_IPROC
+help
+ Enable support for Broadcom SBA RAID Engine. The SBA RAID
+ engine is available on most of the Broadcom iProc SoCs. It
+ has the capability to offload memcpy, xor and pq computation
+ for raid5/6.
+
 config COH901318
bool "ST-Ericsson COH901318 DMA support"
select DMA_ENGINE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index a4fa336..ba96bdd 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_AMCC_PPC440SPE_ADMA) += ppc4xx/
 obj-$(CONFIG_AT_HDMAC) += at_hdmac.o
 obj-$(CONFIG_AT_XDMAC) += at_xdmac.o
 obj-$(CONFIG_AXI_DMAC) += dma-axi-dmac.o
+obj-$(CONFIG_BCM_SBA_RAID) += bcm-sba-raid.o
 obj-$(CONFIG_COH901318) += coh901318.o coh901318_lli.o
 obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
 obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
diff --git a/drivers/dma/bcm-sba-raid.c b/drivers/dma/bcm-sba-raid.c
new file mode 100644
index 000..bf39f3f
--- /dev/null
+++ b/drivers/dma/bcm-sba-raid.c
@@ -0,0 +1,1309 @@
+/*
+ * Copyright (C) 2017 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/*
+ * Broadcom SBA RAID Driver
+ *
+ * The Broadcom stream buffer accelerator (SBA) provides offloading
+ * capabilities for RAID operations. The SBA offload engine is accessible
+ * via Broadcom SoC specific ring manager. Two or more offload engines
+ * can share same Broadcom SoC specific ring manager due to this Broadcom
+ * SoC specific ring manager driver is implemented as a mailbox controller
+ * driver and offload engine drivers are implemented as mallbox clients.
+ *
+ * Typically, Broadcom SoC specific ring manager will implement larger
+ * number of hardware rings over one or more SBA hardware devices. By
+ * design, the internal buffer size of SBA hardware device is limited
+ * but all offload operations supported by SBA can be broken down into
+ * multiple small size requests and executed parallely on multiple SBA
+ * hardware devices for achieving high through-put.
+ *
+ * The Broadcom SBA RAID driver does not require any register programming
+ * except submitting request to SBA hardware device via mailbox channels.
+ * This driver implements a DMA device with one DMA channel using a set
+ * of mailbox channels provided by Broadcom SoC specific ring manager
+ * driver. To exploit parallelism (as described above), all DMA request
+ * coming to SBA RAID DMA channel are broken down to smaller requests
+ * and submitted to multiple mailbox channels in round-robin fashion.
+ * For having more SBA DMA channels, we can create more SBA device nodes
+ * in Broadcom SoC specific DTS based on number of hardware rings supported
+ * by Broadcom SoC ring manager.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+
+/* SBA command helper macros */
+#define SBA_DEC(_d, _s, _m)(((_d) >> (_s)) & (_m))
+#define SBA_ENC(_d, _v, _s, _m)\
+   do {\
+   (_d) &= ~((u64)(_m) << (_s));   \
+   (_d) |= (((u64)(_v) & (_m)) << (_s));   \
+   } while (0)
+
+/* SBA command related defines */
+#define SBA_TYPE_SHIFT 48
+#define SBA_TYPE_MASK  0x3
+#define SBA_TYPE_A 0x0
+#define SBA_TYPE_B 0x2
+#define SBA_TYPE_C   

[PATCH 0/6] Broadcom SBA RAID support

[Anup Patel]

The Broadcom SBA RAID is a stream-based device which provides
RAID5/6 offload.

It requires a SoC specific ring manager (such as Broadcom FlexRM
ring manager) to provide ring-based programming interface. Due to
this, the Broadcom SBA RAID driver (mailbox client) implements
DMA device having one DMA channel using a set of mailbox channels
provided by Broadcom SoC specific ring manager driver (mailbox
controller).

Important limitations of Broadcom SBA RAID hardware are:
1. Requires disk position instead of disk coefficient 
2. Supports only 30 PQ disk coefficients

To address limitation #1, we have added raid_gflog table which
will help driver convert disk coefficient to disk position. To
address limitation #2, we have extended Linux Async Tx APIs to
check for available PQ coefficients before doing PQ offload.

This patchset is based on Linux-4.10-rc6 and depends on patchset
"[PATCH v4 0/2] Broadcom FlexRM ring manager support"

It is also available at sba-raid-v1 branch of
https://github.com/Broadcom/arm64-linux.git

Anup Patel (6):
  mailbox: Add new API mbox_channel_device() for clients
  lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position
  async_tx: Handle DMA devices having support for fewer PQ coefficients
  async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
  dmaengine: Add Broadcom SBA RAID driver
  dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

 .../devicetree/bindings/dma/brcm,iproc-sba.txt |   29 +
 crypto/async_tx/async_pq.c |8 +-
 crypto/async_tx/async_raid6_recov.c|   12 +-
 drivers/dma/Kconfig|   13 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1309 
 drivers/mailbox/mailbox.c  |   21 +
 include/linux/dmaengine.h  |   19 +
 include/linux/mailbox_client.h |1 +
 include/linux/raid/pq.h|4 +
 lib/raid6/mktables.c   |   20 +
 11 files changed, 1432 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
 create mode 100644 drivers/dma/bcm-sba-raid.c

-- 
2.7.4

[PATCH 0/6] Broadcom SBA RAID support

[Anup Patel]

The Broadcom SBA RAID is a stream-based device which provides
RAID5/6 offload.

It requires a SoC specific ring manager (such as Broadcom FlexRM
ring manager) to provide ring-based programming interface. Due to
this, the Broadcom SBA RAID driver (mailbox client) implements
DMA device having one DMA channel using a set of mailbox channels
provided by Broadcom SoC specific ring manager driver (mailbox
controller).

Important limitations of Broadcom SBA RAID hardware are:
1. Requires disk position instead of disk coefficient 
2. Supports only 30 PQ disk coefficients

To address limitation #1, we have added raid_gflog table which
will help driver convert disk coefficient to disk position. To
address limitation #2, we have extended Linux Async Tx APIs to
check for available PQ coefficients before doing PQ offload.

This patchset is based on Linux-4.10-rc6 and depends on patchset
"[PATCH v4 0/2] Broadcom FlexRM ring manager support"

It is also available at sba-raid-v1 branch of
https://github.com/Broadcom/arm64-linux.git

Anup Patel (6):
  mailbox: Add new API mbox_channel_device() for clients
  lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position
  async_tx: Handle DMA devices having support for fewer PQ coefficients
  async_tx: Fix DMA_PREP_FENCE usage in do_async_gen_syndrome()
  dmaengine: Add Broadcom SBA RAID driver
  dt-bindings: Add DT bindings document for Broadcom SBA RAID driver

 .../devicetree/bindings/dma/brcm,iproc-sba.txt |   29 +
 crypto/async_tx/async_pq.c |8 +-
 crypto/async_tx/async_raid6_recov.c|   12 +-
 drivers/dma/Kconfig|   13 +
 drivers/dma/Makefile   |1 +
 drivers/dma/bcm-sba-raid.c | 1309 
 drivers/mailbox/mailbox.c  |   21 +
 include/linux/dmaengine.h  |   19 +
 include/linux/mailbox_client.h |1 +
 include/linux/raid/pq.h|4 +
 lib/raid6/mktables.c   |   20 +
 11 files changed, 1432 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/brcm,iproc-sba.txt
 create mode 100644 drivers/dma/bcm-sba-raid.c

-- 
2.7.4

[PATCH 3/6] async_tx: Handle DMA devices having support for fewer PQ coefficients

[Anup Patel]

The DMAENGINE framework assumes that if PQ offload is supported by a
DMA device then all 256 PQ coefficients are supported. This assumption
does not hold anymore because we now have BCM-SBA-RAID offload engine
which supports PQ offload with limited number of PQ coefficients.

This patch extends async_tx APIs to handle DMA devices with support
for fewer PQ coefficients.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
---
 crypto/async_tx/async_pq.c  |  3 +++
 crypto/async_tx/async_raid6_recov.c | 12 ++--
 include/linux/dmaengine.h   | 19 +++
 include/linux/raid/pq.h |  3 +++
 4 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index f83de99..16c6526 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -187,6 +187,9 @@ async_gen_syndrome(struct page **blocks, unsigned int 
offset, int disks,
 
BUG_ON(disks > 255 || !(P(blocks, disks) || Q(blocks, disks)));
 
+   if (device && dma_maxpqcoef(device) < src_cnt)
+   device = NULL;
+
if (device)
unmap = dmaengine_get_unmap_data(device->dev, disks, 
GFP_NOWAIT);
 
diff --git a/crypto/async_tx/async_raid6_recov.c 
b/crypto/async_tx/async_raid6_recov.c
index 8fab627..2916f95 100644
--- a/crypto/async_tx/async_raid6_recov.c
+++ b/crypto/async_tx/async_raid6_recov.c
@@ -352,6 +352,7 @@ async_raid6_2data_recov(int disks, size_t bytes, int faila, 
int failb,
 {
void *scribble = submit->scribble;
int non_zero_srcs, i;
+   struct dma_chan *chan = async_dma_find_channel(DMA_PQ);
 
BUG_ON(faila == failb);
if (failb < faila)
@@ -359,12 +360,15 @@ async_raid6_2data_recov(int disks, size_t bytes, int 
faila, int failb,
 
pr_debug("%s: disks: %d len: %zu\n", __func__, disks, bytes);
 
+   if (chan && dma_maxpqcoef(chan->device) < RAID6_PQ_MAX_COEF)
+   chan = NULL;
+
/* if a dma resource is not available or a scribble buffer is not
 * available punt to the synchronous path.  In the 'dma not
 * available' case be sure to use the scribble buffer to
 * preserve the content of 'blocks' as the caller intended.
 */
-   if (!async_dma_find_channel(DMA_PQ) || !scribble) {
+   if (!chan || !scribble) {
void **ptrs = scribble ? scribble : (void **) blocks;
 
async_tx_quiesce(>depend_tx);
@@ -432,15 +436,19 @@ async_raid6_datap_recov(int disks, size_t bytes, int 
faila,
void *scribble = submit->scribble;
int good_srcs, good, i;
struct page *srcs[2];
+   struct dma_chan *chan = async_dma_find_channel(DMA_PQ);
 
pr_debug("%s: disks: %d len: %zu\n", __func__, disks, bytes);
 
+   if (chan && dma_maxpqcoef(chan->device) < RAID6_PQ_MAX_COEF)
+   chan = NULL;
+
/* if a dma resource is not available or a scribble buffer is not
 * available punt to the synchronous path.  In the 'dma not
 * available' case be sure to use the scribble buffer to
 * preserve the content of 'blocks' as the caller intended.
 */
-   if (!async_dma_find_channel(DMA_PQ) || !scribble) {
+   if (!chan || !scribble) {
void **ptrs = scribble ? scribble : (void **) blocks;
 
async_tx_quiesce(>depend_tx);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index feee6ec..d938a8b 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /**
@@ -668,6 +669,7 @@ struct dma_filter {
  * @cap_mask: one or more dma_capability flags
  * @max_xor: maximum number of xor sources, 0 if no capability
  * @max_pq: maximum number of PQ sources and PQ-continue capability
+ * @max_pqcoef: maximum number of PQ coefficients, 0 if all supported
  * @copy_align: alignment shift for memcpy operations
  * @xor_align: alignment shift for xor operations
  * @pq_align: alignment shift for pq operations
@@ -727,11 +729,13 @@ struct dma_device {
dma_cap_mask_t  cap_mask;
unsigned short max_xor;
unsigned short max_pq;
+   unsigned short max_pqcoef;
enum dmaengine_alignment copy_align;
enum dmaengine_alignment xor_align;
enum dmaengine_alignment pq_align;
enum dmaengine_alignment fill_align;
#define DMA_HAS_PQ_CONTINUE (1 << 15)
+   #define DMA_HAS_FEWER_PQ_COEF (1 << 15)
 
int dev_id;
struct device *dev;
@@ -1122,6 +1126,21 @@ static inline int dma_maxpq(struct dma_device *dma, enum 
dma_ctrl_flags flags)
BUG();
 }
 
+static inline void dma_set_maxpqcoef(struct dma_device *dma,
+unsigned short max_pqcoef)
+{
+   if (max_pqcoef < RAID6_PQ_MAX_COEF) {
+   dma->max_pqcoef = max_pqcoef;
+  

[PATCH 2/6] lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position

[Anup Patel]

The raid6_gfexp table represents {2}^n values for 0 <= n < 256. The
Linux async_tx framework pass values from raid6_gfexp as coefficients
for each source to prep_dma_pq() callback of DMA channel with PQ
capability. This creates problem for RAID6 offload engines (such as
Broadcom SBA) which take disk position (i.e. log of {2}) instead of
multiplicative cofficients from raid6_gfexp table.

This patch adds raid6_gflog table having log-of-2 value for any given
x such that 0 <= x < 256. For any given disk coefficient x, the
corresponding disk position is given by raid6_gflog[x]. The RAID6
offload engine driver can use this newly added raid6_gflog table to
get disk position from multiplicative coefficient.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
Reviewed-by: Ray Jui 
---
 include/linux/raid/pq.h |  1 +
 lib/raid6/mktables.c| 20 
 2 files changed, 21 insertions(+)

diff --git a/include/linux/raid/pq.h b/include/linux/raid/pq.h
index 4d57bba..30f9453 100644
--- a/include/linux/raid/pq.h
+++ b/include/linux/raid/pq.h
@@ -142,6 +142,7 @@ int raid6_select_algo(void);
 extern const u8 raid6_gfmul[256][256] __attribute__((aligned(256)));
 extern const u8 raid6_vgfmul[256][32] __attribute__((aligned(256)));
 extern const u8 raid6_gfexp[256]  __attribute__((aligned(256)));
+extern const u8 raid6_gflog[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfinv[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfexi[256]  __attribute__((aligned(256)));
 
diff --git a/lib/raid6/mktables.c b/lib/raid6/mktables.c
index 39787db..e824d08 100644
--- a/lib/raid6/mktables.c
+++ b/lib/raid6/mktables.c
@@ -125,6 +125,26 @@ int main(int argc, char *argv[])
printf("EXPORT_SYMBOL(raid6_gfexp);\n");
printf("#endif\n");
 
+   /* Compute log-of-2 table */
+   printf("\nconst u8 __attribute__((aligned(256)))\n"
+  "raid6_gflog[256] =\n" "{\n");
+   for (i = 0; i < 256; i += 8) {
+   printf("\t");
+   for (j = 0; j < 8; j++) {
+   v = 255;
+   for (k = 0; k < 256; k++)
+   if (exptbl[k] == (i + j)) {
+   v = k;
+   break;
+   }
+   printf("0x%02x,%c", v, (j == 7) ? '\n' : ' ');
+   }
+   }
+   printf("};\n");
+   printf("#ifdef __KERNEL__\n");
+   printf("EXPORT_SYMBOL(raid6_gflog);\n");
+   printf("#endif\n");
+
/* Compute inverse table x^-1 == x^254 */
printf("\nconst u8 __attribute__((aligned(256)))\n"
   "raid6_gfinv[256] =\n" "{\n");
-- 
2.7.4

[PATCH 3/6] async_tx: Handle DMA devices having support for fewer PQ coefficients

[Anup Patel]

The DMAENGINE framework assumes that if PQ offload is supported by a
DMA device then all 256 PQ coefficients are supported. This assumption
does not hold anymore because we now have BCM-SBA-RAID offload engine
which supports PQ offload with limited number of PQ coefficients.

This patch extends async_tx APIs to handle DMA devices with support
for fewer PQ coefficients.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
---
 crypto/async_tx/async_pq.c  |  3 +++
 crypto/async_tx/async_raid6_recov.c | 12 ++--
 include/linux/dmaengine.h   | 19 +++
 include/linux/raid/pq.h |  3 +++
 4 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/crypto/async_tx/async_pq.c b/crypto/async_tx/async_pq.c
index f83de99..16c6526 100644
--- a/crypto/async_tx/async_pq.c
+++ b/crypto/async_tx/async_pq.c
@@ -187,6 +187,9 @@ async_gen_syndrome(struct page **blocks, unsigned int 
offset, int disks,
 
BUG_ON(disks > 255 || !(P(blocks, disks) || Q(blocks, disks)));
 
+   if (device && dma_maxpqcoef(device) < src_cnt)
+   device = NULL;
+
if (device)
unmap = dmaengine_get_unmap_data(device->dev, disks, 
GFP_NOWAIT);
 
diff --git a/crypto/async_tx/async_raid6_recov.c 
b/crypto/async_tx/async_raid6_recov.c
index 8fab627..2916f95 100644
--- a/crypto/async_tx/async_raid6_recov.c
+++ b/crypto/async_tx/async_raid6_recov.c
@@ -352,6 +352,7 @@ async_raid6_2data_recov(int disks, size_t bytes, int faila, 
int failb,
 {
void *scribble = submit->scribble;
int non_zero_srcs, i;
+   struct dma_chan *chan = async_dma_find_channel(DMA_PQ);
 
BUG_ON(faila == failb);
if (failb < faila)
@@ -359,12 +360,15 @@ async_raid6_2data_recov(int disks, size_t bytes, int 
faila, int failb,
 
pr_debug("%s: disks: %d len: %zu\n", __func__, disks, bytes);
 
+   if (chan && dma_maxpqcoef(chan->device) < RAID6_PQ_MAX_COEF)
+   chan = NULL;
+
/* if a dma resource is not available or a scribble buffer is not
 * available punt to the synchronous path.  In the 'dma not
 * available' case be sure to use the scribble buffer to
 * preserve the content of 'blocks' as the caller intended.
 */
-   if (!async_dma_find_channel(DMA_PQ) || !scribble) {
+   if (!chan || !scribble) {
void **ptrs = scribble ? scribble : (void **) blocks;
 
async_tx_quiesce(>depend_tx);
@@ -432,15 +436,19 @@ async_raid6_datap_recov(int disks, size_t bytes, int 
faila,
void *scribble = submit->scribble;
int good_srcs, good, i;
struct page *srcs[2];
+   struct dma_chan *chan = async_dma_find_channel(DMA_PQ);
 
pr_debug("%s: disks: %d len: %zu\n", __func__, disks, bytes);
 
+   if (chan && dma_maxpqcoef(chan->device) < RAID6_PQ_MAX_COEF)
+   chan = NULL;
+
/* if a dma resource is not available or a scribble buffer is not
 * available punt to the synchronous path.  In the 'dma not
 * available' case be sure to use the scribble buffer to
 * preserve the content of 'blocks' as the caller intended.
 */
-   if (!async_dma_find_channel(DMA_PQ) || !scribble) {
+   if (!chan || !scribble) {
void **ptrs = scribble ? scribble : (void **) blocks;
 
async_tx_quiesce(>depend_tx);
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index feee6ec..d938a8b 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /**
@@ -668,6 +669,7 @@ struct dma_filter {
  * @cap_mask: one or more dma_capability flags
  * @max_xor: maximum number of xor sources, 0 if no capability
  * @max_pq: maximum number of PQ sources and PQ-continue capability
+ * @max_pqcoef: maximum number of PQ coefficients, 0 if all supported
  * @copy_align: alignment shift for memcpy operations
  * @xor_align: alignment shift for xor operations
  * @pq_align: alignment shift for pq operations
@@ -727,11 +729,13 @@ struct dma_device {
dma_cap_mask_t  cap_mask;
unsigned short max_xor;
unsigned short max_pq;
+   unsigned short max_pqcoef;
enum dmaengine_alignment copy_align;
enum dmaengine_alignment xor_align;
enum dmaengine_alignment pq_align;
enum dmaengine_alignment fill_align;
#define DMA_HAS_PQ_CONTINUE (1 << 15)
+   #define DMA_HAS_FEWER_PQ_COEF (1 << 15)
 
int dev_id;
struct device *dev;
@@ -1122,6 +1126,21 @@ static inline int dma_maxpq(struct dma_device *dma, enum 
dma_ctrl_flags flags)
BUG();
 }
 
+static inline void dma_set_maxpqcoef(struct dma_device *dma,
+unsigned short max_pqcoef)
+{
+   if (max_pqcoef < RAID6_PQ_MAX_COEF) {
+   dma->max_pqcoef = max_pqcoef;
+   dma->max_pqcoef |= DMA_HAS_FEWER_PQ_COEF;
+ 

[PATCH 2/6] lib/raid6: Add log-of-2 table for RAID6 HW requiring disk position

[Anup Patel]

The raid6_gfexp table represents {2}^n values for 0 <= n < 256. The
Linux async_tx framework pass values from raid6_gfexp as coefficients
for each source to prep_dma_pq() callback of DMA channel with PQ
capability. This creates problem for RAID6 offload engines (such as
Broadcom SBA) which take disk position (i.e. log of {2}) instead of
multiplicative cofficients from raid6_gfexp table.

This patch adds raid6_gflog table having log-of-2 value for any given
x such that 0 <= x < 256. For any given disk coefficient x, the
corresponding disk position is given by raid6_gflog[x]. The RAID6
offload engine driver can use this newly added raid6_gflog table to
get disk position from multiplicative coefficient.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
Reviewed-by: Ray Jui 
---
 include/linux/raid/pq.h |  1 +
 lib/raid6/mktables.c| 20 
 2 files changed, 21 insertions(+)

diff --git a/include/linux/raid/pq.h b/include/linux/raid/pq.h
index 4d57bba..30f9453 100644
--- a/include/linux/raid/pq.h
+++ b/include/linux/raid/pq.h
@@ -142,6 +142,7 @@ int raid6_select_algo(void);
 extern const u8 raid6_gfmul[256][256] __attribute__((aligned(256)));
 extern const u8 raid6_vgfmul[256][32] __attribute__((aligned(256)));
 extern const u8 raid6_gfexp[256]  __attribute__((aligned(256)));
+extern const u8 raid6_gflog[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfinv[256]  __attribute__((aligned(256)));
 extern const u8 raid6_gfexi[256]  __attribute__((aligned(256)));
 
diff --git a/lib/raid6/mktables.c b/lib/raid6/mktables.c
index 39787db..e824d08 100644
--- a/lib/raid6/mktables.c
+++ b/lib/raid6/mktables.c
@@ -125,6 +125,26 @@ int main(int argc, char *argv[])
printf("EXPORT_SYMBOL(raid6_gfexp);\n");
printf("#endif\n");
 
+   /* Compute log-of-2 table */
+   printf("\nconst u8 __attribute__((aligned(256)))\n"
+  "raid6_gflog[256] =\n" "{\n");
+   for (i = 0; i < 256; i += 8) {
+   printf("\t");
+   for (j = 0; j < 8; j++) {
+   v = 255;
+   for (k = 0; k < 256; k++)
+   if (exptbl[k] == (i + j)) {
+   v = k;
+   break;
+   }
+   printf("0x%02x,%c", v, (j == 7) ? '\n' : ' ');
+   }
+   }
+   printf("};\n");
+   printf("#ifdef __KERNEL__\n");
+   printf("EXPORT_SYMBOL(raid6_gflog);\n");
+   printf("#endif\n");
+
/* Compute inverse table x^-1 == x^254 */
printf("\nconst u8 __attribute__((aligned(256)))\n"
   "raid6_gfinv[256] =\n" "{\n");
-- 
2.7.4

[PATCH 1/6] mailbox: Add new API mbox_channel_device() for clients

[Anup Patel]

The remote processor can have DMAENGINE capabilities and client
can pass data to be processed via main memory. In such cases,
the client will require DMAble memory for remote processor.

This patch adds new API mbox_channel_device() which can be
used by clients to get struct device pointer of underlying
mailbox controller. This struct device pointer of mailbox
controller can be used by clients to allocate DMAble memory
for remote processor.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
Reviewed-by: Ray Jui 
---
 drivers/mailbox/mailbox.c  | 21 +
 include/linux/mailbox_client.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 4671f8a..d4380fc 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -281,6 +281,27 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
 EXPORT_SYMBOL_GPL(mbox_send_message);
 
 /**
+ * mbox_channel_device - Get device pointer of a mailbox channel.
+ * @chan: Mailbox channel assigned to this client.
+ *
+ * The remote processor can have DMAENGINE capabilities and client
+ * can pass data to be processed via main memory. In such cases,
+ * the client will require struct device pointer of the mailbox
+ * channel to map/unmap/allocate/free DMAble memory.
+ *
+ * Return: Pointer to the struct device of mailbox channel.
+ *ERR_PTR on failure.
+ */
+struct device *mbox_channel_device(struct mbox_chan *chan)
+{
+   if (!chan || !chan->cl)
+   return ERR_PTR(-EINVAL);
+
+   return chan->mbox->dev;
+}
+EXPORT_SYMBOL_GPL(mbox_channel_device);
+
+/**
  * mbox_request_channel - Request a mailbox channel.
  * @cl: Identity of the client requesting the channel.
  * @index: Index of mailbox specifier in 'mboxes' property.
diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h
index 4434871..3daffad 100644
--- a/include/linux/mailbox_client.h
+++ b/include/linux/mailbox_client.h
@@ -40,6 +40,7 @@ struct mbox_client {
void (*tx_done)(struct mbox_client *cl, void *mssg, int r);
 };
 
+struct device *mbox_channel_device(struct mbox_chan *chan);
 struct mbox_chan *mbox_request_channel_byname(struct mbox_client *cl,
  const char *name);
 struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index);
-- 
2.7.4

[PATCH 1/6] mailbox: Add new API mbox_channel_device() for clients

[Anup Patel]

The remote processor can have DMAENGINE capabilities and client
can pass data to be processed via main memory. In such cases,
the client will require DMAble memory for remote processor.

This patch adds new API mbox_channel_device() which can be
used by clients to get struct device pointer of underlying
mailbox controller. This struct device pointer of mailbox
controller can be used by clients to allocate DMAble memory
for remote processor.

Signed-off-by: Anup Patel 
Reviewed-by: Scott Branden 
Reviewed-by: Ray Jui 
---
 drivers/mailbox/mailbox.c  | 21 +
 include/linux/mailbox_client.h |  1 +
 2 files changed, 22 insertions(+)

diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 4671f8a..d4380fc 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -281,6 +281,27 @@ int mbox_send_message(struct mbox_chan *chan, void *mssg)
 EXPORT_SYMBOL_GPL(mbox_send_message);
 
 /**
+ * mbox_channel_device - Get device pointer of a mailbox channel.
+ * @chan: Mailbox channel assigned to this client.
+ *
+ * The remote processor can have DMAENGINE capabilities and client
+ * can pass data to be processed via main memory. In such cases,
+ * the client will require struct device pointer of the mailbox
+ * channel to map/unmap/allocate/free DMAble memory.
+ *
+ * Return: Pointer to the struct device of mailbox channel.
+ *ERR_PTR on failure.
+ */
+struct device *mbox_channel_device(struct mbox_chan *chan)
+{
+   if (!chan || !chan->cl)
+   return ERR_PTR(-EINVAL);
+
+   return chan->mbox->dev;
+}
+EXPORT_SYMBOL_GPL(mbox_channel_device);
+
+/**
  * mbox_request_channel - Request a mailbox channel.
  * @cl: Identity of the client requesting the channel.
  * @index: Index of mailbox specifier in 'mboxes' property.
diff --git a/include/linux/mailbox_client.h b/include/linux/mailbox_client.h
index 4434871..3daffad 100644
--- a/include/linux/mailbox_client.h
+++ b/include/linux/mailbox_client.h
@@ -40,6 +40,7 @@ struct mbox_client {
void (*tx_done)(struct mbox_client *cl, void *mssg, int r);
 };
 
+struct device *mbox_channel_device(struct mbox_chan *chan);
 struct mbox_chan *mbox_request_channel_byname(struct mbox_client *cl,
  const char *name);
 struct mbox_chan *mbox_request_channel(struct mbox_client *cl, int index);
-- 
2.7.4

Re: ibmvtpm byteswapping inconsistency

[Vicky]

> On Jan 26, 2017, at 5:58 PM, Ashley Lai  wrote:
> 
> Adding Vicky from IBM.
> 
> 
> On 01/26/2017 04:05 PM, Jason Gunthorpe wrote:
>> On Thu, Jan 26, 2017 at 09:22:48PM +0100, Michal Such??nek wrote:
>> 
>>> This is repeated a few times in the driver so I added memset to quiet
>>> gcc and make behavior deterministic in case the unused fields get some
>>> meaning in the future.
>> Yep, reserved certainly needs to be zeroed.. Can you send a patch?
>> memset is overkill...
>> 
>>> However, in tpm_ibmvtpm_send the structure is initialized as
>>> 
>>> struct ibmvtpm_crq crq;
>>> __be64 *word = (__be64 *)
>>> ...
>>> crq.valid = (u8)IBMVTPM_VALID_CMD;
>>> crq.msg = (u8)VTPM_TPM_COMMAND;
>>> crq.len = cpu_to_be16(count);
>>> crq.data = cpu_to_be32(ibmvtpm->rtce_dma_handle);
>>> 
>>> and submitted with
>>> 
>>> rc = ibmvtpm_send_crq(ibmvtpm->vdev, be64_to_cpu(word[0]),
>>>   be64_to_cpu(word[1]));
>>> meaning it is swapped twice.
>> No idea, Nayna may know.
>> 
>> My guess is that '__be64 *word' should be 'u64 *word'...
>> 
>> Jason
> 

I don’t think we want ‘word' to be changed back to be of type ‘u64’.   Please 
see commit 62dfd912ab3b5405b6fe72d0135c37e9648071f1


Vicky

Re: ibmvtpm byteswapping inconsistency

[Vicky]

> On Jan 26, 2017, at 5:58 PM, Ashley Lai  wrote:
> 
> Adding Vicky from IBM.
> 
> 
> On 01/26/2017 04:05 PM, Jason Gunthorpe wrote:
>> On Thu, Jan 26, 2017 at 09:22:48PM +0100, Michal Such??nek wrote:
>> 
>>> This is repeated a few times in the driver so I added memset to quiet
>>> gcc and make behavior deterministic in case the unused fields get some
>>> meaning in the future.
>> Yep, reserved certainly needs to be zeroed.. Can you send a patch?
>> memset is overkill...
>> 
>>> However, in tpm_ibmvtpm_send the structure is initialized as
>>> 
>>> struct ibmvtpm_crq crq;
>>> __be64 *word = (__be64 *)
>>> ...
>>> crq.valid = (u8)IBMVTPM_VALID_CMD;
>>> crq.msg = (u8)VTPM_TPM_COMMAND;
>>> crq.len = cpu_to_be16(count);
>>> crq.data = cpu_to_be32(ibmvtpm->rtce_dma_handle);
>>> 
>>> and submitted with
>>> 
>>> rc = ibmvtpm_send_crq(ibmvtpm->vdev, be64_to_cpu(word[0]),
>>>   be64_to_cpu(word[1]));
>>> meaning it is swapped twice.
>> No idea, Nayna may know.
>> 
>> My guess is that '__be64 *word' should be 'u64 *word'...
>> 
>> Jason
> 

I don’t think we want ‘word' to be changed back to be of type ‘u64’.   Please 
see commit 62dfd912ab3b5405b6fe72d0135c37e9648071f1


Vicky

[GIT PULL] Thermal-SoC management updates for v4.10-rc7

[Eduardo Valentin]

Hello Rui,

Please consider the following four small fixes on TI and MTK thermal
drivers.

BR,
Eduardo

The following changes since commit a4685d2f58e2230d4e27fb2ee581d7ea35e5d046:

  Merge branch 'stable' of 
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile (2017-01-23 
13:51:59 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes

for you to fetch changes up to fd8e146de4837462b84a0cbf279bd73138f91991:

  thermal: mtk_thermal: Staticise a number of data variables (2017-01-24 
02:13:17 -0800)


Keerthy (3):
  thermal: ti-soc-thermal: Remove CPU_THERMAL Dependency from TI_THERMAL
  thermal: arm: dra752: Remove TSHUT configuration
  thermal: arm: dra752: Remove all TSHUT related definitions

Vivek Gautam (1):
  thermal: mtk_thermal: Staticise a number of data variables

 drivers/thermal/mtk_thermal.c  | 16 ++---
 drivers/thermal/ti-soc-thermal/Kconfig |  1 -
 drivers/thermal/ti-soc-thermal/dra752-bandgap.h| 19 ---
 .../thermal/ti-soc-thermal/dra752-thermal-data.c   | 28 +-
 4 files changed, 9 insertions(+), 55 deletions(-)

[GIT PULL] Thermal-SoC management updates for v4.10-rc7

[Eduardo Valentin]

Hello Rui,

Please consider the following four small fixes on TI and MTK thermal
drivers.

BR,
Eduardo

The following changes since commit a4685d2f58e2230d4e27fb2ee581d7ea35e5d046:

  Merge branch 'stable' of 
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile (2017-01-23 
13:51:59 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes

for you to fetch changes up to fd8e146de4837462b84a0cbf279bd73138f91991:

  thermal: mtk_thermal: Staticise a number of data variables (2017-01-24 
02:13:17 -0800)


Keerthy (3):
  thermal: ti-soc-thermal: Remove CPU_THERMAL Dependency from TI_THERMAL
  thermal: arm: dra752: Remove TSHUT configuration
  thermal: arm: dra752: Remove all TSHUT related definitions

Vivek Gautam (1):
  thermal: mtk_thermal: Staticise a number of data variables

 drivers/thermal/mtk_thermal.c  | 16 ++---
 drivers/thermal/ti-soc-thermal/Kconfig |  1 -
 drivers/thermal/ti-soc-thermal/dra752-bandgap.h| 19 ---
 .../thermal/ti-soc-thermal/dra752-thermal-data.c   | 28 +-
 4 files changed, 9 insertions(+), 55 deletions(-)

[PATCH] gpio: aspeed: Remove dependence on GPIOF_* macros

[Andrew Jeffery]

1736f75d35e47409ad776273133d0f558a4c8253 is a (v2) patch which had
unresolved review comments[1]. Address the comments by removing the use
of macros from the consumer header (this patch represents the diff
between v2 and v3[2]).

[1] https://lkml.org/lkml/2017/1/26/337
[2] https://lkml.org/lkml/2017/1/26/786

Fixes: 1736f75d35e4 ("gpio: aspeed: Add banks Y, Z, AA, AB and AC")
Signed-off-by: Andrew Jeffery 
---

Note: This should be applied to pinctrl/devel where the linked GPIO patches
have landed. See discussion at https://lkml.org/lkml/2017/2/1/390

 drivers/gpio/gpio-aspeed.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 6e4b278a82f1..fb16cc771c0d 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -259,10 +258,10 @@ static int aspeed_gpio_get_direction(struct gpio_chip 
*gc, unsigned int offset)
u32 val;
 
if (!have_input(gpio, offset))
-   return GPIOF_DIR_OUT;
+   return 0;
 
if (!have_output(gpio, offset))
-   return GPIOF_DIR_IN;
+   return 1;
 
spin_lock_irqsave(>lock, flags);
 
-- 
2.9.3

[PATCH] gpio: aspeed: Remove dependence on GPIOF_* macros

[Andrew Jeffery]

1736f75d35e47409ad776273133d0f558a4c8253 is a (v2) patch which had
unresolved review comments[1]. Address the comments by removing the use
of macros from the consumer header (this patch represents the diff
between v2 and v3[2]).

[1] https://lkml.org/lkml/2017/1/26/337
[2] https://lkml.org/lkml/2017/1/26/786

Fixes: 1736f75d35e4 ("gpio: aspeed: Add banks Y, Z, AA, AB and AC")
Signed-off-by: Andrew Jeffery 
---

Note: This should be applied to pinctrl/devel where the linked GPIO patches
have landed. See discussion at https://lkml.org/lkml/2017/2/1/390

 drivers/gpio/gpio-aspeed.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 6e4b278a82f1..fb16cc771c0d 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -15,7 +15,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -259,10 +258,10 @@ static int aspeed_gpio_get_direction(struct gpio_chip 
*gc, unsigned int offset)
u32 val;
 
if (!have_input(gpio, offset))
-   return GPIOF_DIR_OUT;
+   return 0;
 
if (!have_output(gpio, offset))
-   return GPIOF_DIR_IN;
+   return 1;
 
spin_lock_irqsave(>lock, flags);
 
-- 
2.9.3