Re: [PATCH] libnvdimm, namespace: do not delete namespace-id 0
On Wed, Feb 01, 2017 at 10:35:21AM -0800, Dan Williams wrote:
> Given that the naming of pmem devices changes from the pmemX form to the
> pmemX.Y form when namespace id is greater than 0, arrange for namespaces
> with id-0 to be exempt from deletion. Otherwise a simple reconfiguration
> of an existing namespace to a new mode results in a name change of the
> resulting block device:
>
> # ndctl list --namespace=namespace1.0
> {
> "dev":"namespace1.0",
> "mode":"raw",
> "size":2147483648,
> "uuid":"3dadf3dc-89b9-4b24-b20e-abc8a4707ce3",
> "blockdev":"pmem1"
> }
>
> # ndctl create-namespace --reconfig=namespace1.0 --mode=memory --force
> {
> "dev":"namespace1.1",
> "mode":"memory",
> "size":2111832064,
> "uuid":"7b4a6341-7318-4219-a02c-fb57c0bbf613",
> "blockdev":"pmem1.1"
> }
>
> This change does require tooling changes to explicitly look for
> namespaceX.0 if the seed has already advanced to another namespace.
>
> Cc:
> Fixes: 98a29c39dc68 ("libnvdimm, namespace: allow creation of multiple
> pmem-namespaces per region")
> Signed-off-by: Dan Williams
> ---
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850
Re: [PATCH 0/2] pinctrl: sunxi: Merge A31s pinctrl driver with A31
On Thu, Feb 02, 2017 at 12:25:45AM +0800, Chen-Yu Tsai wrote: > Hi everyone, > > This series merges support for the A31s' pin controller into the A31 > driver, using the new sunxi variants support code. The A31s is a trimmed > down version of the A31, with some hardware blocks removed, and some > pin functions or pins removed. Thus it is easy to support the A31s > using the A31 driver by marking the extra pins/functions as A31 only. > > Patch 1 does exactly this. > > Patch 2 removes the original A31s driver, which is now redundant. > > I opted not to rename sun6i-a31 to sun6i in various places. Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH] pinctrl: sunxi: Remove stray printk call in sun5i driver's probe function
On Thu, Feb 02, 2017 at 12:02:09AM +0800, Chen-Yu Tsai wrote: > There is a stray printk call in the new sun5i pinctrl driver's probe > function. > > Remove it. > > Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v3] scsi, block: fix duplicate bdi name registration crashes
Looks good, Reviewed-by: Christoph Hellwig
Re: [PATCH v3 1/1] x86, relocs: add printf attribute to die()
On 02/02/17 02:39, h...@zytor.com wrote:
> On January 31, 2017 10:52:11 AM PST, Nicolas Iooss
> wrote:
>> Hello,
>>
>> As I have not received any comment on the patch I sent in December, I
>> am
>> wondering whether I did anything wrong with it. How can I get it queued
>> for the next merge window?
>>
>> Thanks,
>> Nicolas
>>
>> On 18/12/16 20:47, Nicolas Iooss wrote:
>>> Adding such an attribute helps to detect errors in the format string
>> at
>>> build time. After doing this, the compiler complains about such
>> issues:
>>>
>>> arch/x86/tools/relocs.c:460:5: error: format specifies type 'int'
>>> but the argument has type 'Elf64_Xword' (aka 'unsigned long')
>>> [-Werror,-Wformat]
>>> sec->shdr.sh_size);
>>> ^
>>> arch/x86/tools/relocs.c:464:5: error: format specifies type 'int'
>>> but the argument has type 'Elf64_Off' (aka 'unsigned long')
>>> [-Werror,-Wformat]
>>> sec->shdr.sh_offset,
>> strerror(errno));
>>> ^~~
>>>
>>> When relocs.c is included by relocs_32.c, sec->shdr.sh_size and
>>> sec->shdr.sh_offset are 32-bit unsigned integers. When the file is
>>> included by relocs_64.c, these expressions are 64-bit unsigned
>> integers.
>>>
>>> Introduce a PRIuELF macro to define the right format to use when
>>> printing sh_size and sh_offset values.
>>>
>>> While at it, constify the format attribute of die().
>>>
>>> Signed-off-by: Nicolas Iooss
>>> ---
>>> I sent the first versions of this patch in September (cf.
>>> https://patchwork.kernel.org/patch/9312665/) but it has not been
>>> applied.
>>>
>>> As commit adee8705d251 ("x86/build: Annotate die() with noreturn to
>> fix
>>> build warning on clang") introduced the noreturn attribute to die(),
>>> this patch now only adds the printf attribute.
>>>
>>> arch/x86/tools/relocs.c| 14 +++---
>>> arch/x86/tools/relocs.h| 3 ++-
>>> arch/x86/tools/relocs_32.c | 3 +++
>>> arch/x86/tools/relocs_64.c | 3 +++
>>> arch/x86/tools/relocs_common.c | 2 +-
>>> 5 files changed, 16 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/arch/x86/tools/relocs.c b/arch/x86/tools/relocs.c
>>> index 0c2fae8d929d..4cad603b8d58 100644
>>> --- a/arch/x86/tools/relocs.c
>>> +++ b/arch/x86/tools/relocs.c
>>> @@ -397,7 +397,7 @@ static void read_shdrs(FILE *fp)
>>> ehdr.e_shnum);
>>> }
>>> if (fseek(fp, ehdr.e_shoff, SEEK_SET) < 0) {
>>> - die("Seek to %d failed: %s\n",
>>> + die("Seek to %"PRIuELF" failed: %s\n",
>>> ehdr.e_shoff, strerror(errno));
>>> }
>>> for (i = 0; i < ehdr.e_shnum; i++) {
>>> @@ -431,11 +431,11 @@ static void read_strtabs(FILE *fp)
>>> }
>>> sec->strtab = malloc(sec->shdr.sh_size);
>>> if (!sec->strtab) {
>>> - die("malloc of %d bytes for strtab failed\n",
>>> + die("malloc of %"PRIuELF" bytes for strtab failed\n",
>>> sec->shdr.sh_size);
>>> }
>>> if (fseek(fp, sec->shdr.sh_offset, SEEK_SET) < 0) {
>>> - die("Seek to %d failed: %s\n",
>>> + die("Seek to %"PRIuELF" failed: %s\n",
>>> sec->shdr.sh_offset, strerror(errno));
>>> }
>>> if (fread(sec->strtab, 1, sec->shdr.sh_size, fp)
>>> @@ -456,11 +456,11 @@ static void read_symtabs(FILE *fp)
>>> }
>>> sec->symtab = malloc(sec->shdr.sh_size);
>>> if (!sec->symtab) {
>>> - die("malloc of %d bytes for symtab failed\n",
>>> + die("malloc of %"PRIuELF" bytes for symtab failed\n",
>>> sec->shdr.sh_size);
>>> }
>>> if (fseek(fp, sec->shdr.sh_offset, SEEK_SET) < 0) {
>>> - die("Seek to %d failed: %s\n",
>>> + die("Seek to %"PRIuELF" failed: %s\n",
>>> sec->shdr.sh_offset, strerror(errno));
>>> }
>>> if (fread(sec->symtab, 1, sec->shdr.sh_size, fp)
>>> @@ -489,11 +489,11 @@ static void read_relocs(FILE *fp)
>>> }
>>> sec->reltab = malloc(sec->shdr.sh_size);
>>> if (!sec->reltab) {
>>> - die("malloc of %d bytes for relocs failed\n",
>>> + die("malloc of %"PRIuELF" bytes for relocs failed\n",
>>> sec->shdr.sh_size);
>>> }
>>> if (fseek(fp, sec->shdr.sh_offset, SEEK_SET) < 0) {
>>> - die("Seek to %d failed: %s\n",
>>> + die("Seek to %"PRIuELF" failed: %s\n",
>>> sec->shdr.sh_offset, strerror(errno));
>>> }
>>> if (fread(sec->reltab, 1, sec->shdr.sh_size, fp)
>>> diff --git a/arch/x86/tools/r
Re: [PATCH 05/11] [media] s5p-mfc: Add support for HEVC decoder
On 02.02.2017 08:58, Andrzej Hajda wrote:
> 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_V10 1
>>
>> +/* 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_DEC6
>> #define S5P_MFC_CODEC_VP8_DEC 7
>> +#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)
>>
Re: [PATCH 04/11] [media] s5p-mfc: Support MFCv10.10 buffer requirements
Hi Smitha,
Ups, I have missed this patch, I hope it wont influence the review :)
On 18.01.2017 11:02, Smitha T Murthy wrote:
> Aligning the luma_dpb_size, chroma_dpb_size, mv_size and me_buffer_size
> for MFCv10.10.
>
> Signed-off-by: Smitha T Murthy
> ---
> drivers/media/platform/s5p-mfc/regs-mfc-v10.h | 13 +++
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 97
> ++-
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |2 +
> 3 files changed, 91 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index bd671a5..153ee68 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -32,5 +32,18 @@
> #define MFC_VERSION_V10 0xA0
> #define MFC_NUM_PORTS_V101
>
> +/* Encoder buffer size for MFC v10.0 */
> +#define ENC_V100_H264_ME_SIZE(x, y) \
> + (((x + 3) * (y + 3) * 8)\
> + + x * y) + 63) / 64) * 32) \
> + + (((y * 64) + 1280) * (x + 7) / 8))
> +#define ENC_V100_MPEG4_ME_SIZE(x, y) \
> + (((x + 3) * (y + 3) * 8)\
> + + x * y) + 127) / 128) * 16) \
> + + (((y * 64) + 1280) * (x + 7) / 8))
> +#define ENC_V100_VP8_ME_SIZE(x, y) \
> + (((x + 3) * (y + 3) * 8)\
> + + (((y * 64) + 1280) * (x + 7) / 8))
> +
Crazy, cryptic math here, I guess you can make it more readable by using
DIV_ROUND_UP macro and abstracting out common parts, for example:
#define ENC_V100_BASE_SIZE(x, y) \
(((x + 3) * (y + 3) * 8) \
+ ((y * 64) + 1280) * DIV_ROUND_UP(x, 8))
#define ENC_V100_H264_ME_SIZE(x, y) \
(ENC_V100_BASE_SIZE(x, y)
+ DIV_ROUND_UP(x * y, 64) * 32)
#define ENC_V100_MPEG4_ME_SIZE(x, y) \
(ENC_V100_BASE_SIZE(x, y)
+ DIV_ROUND_UP(x * y, 128) * 16)
#define ENC_V100_VP8_ME_SIZE(x, y) \
ENC_V100_BASE_SIZE(x, y)
> #endif /*_REGS_MFC_V10_H*/
>
> 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 faceee6..369210a 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -64,6 +64,7 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
> s5p_mfc_ctx *ctx)
> {
> struct s5p_mfc_dev *dev = ctx->dev;
> unsigned int mb_width, mb_height;
> + unsigned int lcu_width = 0, lcu_height = 0;
> int ret;
>
> mb_width = MB_WIDTH(ctx->img_width);
> @@ -74,7 +75,9 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
> s5p_mfc_ctx *ctx)
> ctx->luma_size, ctx->chroma_size, ctx->mv_size);
> mfc_debug(2, "Totals bufs: %d\n", ctx->total_dpb_count);
> } else if (ctx->type == MFCINST_ENCODER) {
> - if (IS_MFCV8_PLUS(dev))
> + if (IS_MFCV10(dev)) {
> + ctx->tmv_buffer_size = 0;
> + } else if (IS_MFCV8_PLUS(dev))
> ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
> ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V8(mb_width, mb_height),
> S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> @@ -82,13 +85,36 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
> s5p_mfc_ctx *ctx)
> ctx->tmv_buffer_size = S5P_FIMV_NUM_TMV_BUFFERS_V6 *
> ALIGN(S5P_FIMV_TMV_BUFFER_SIZE_V6(mb_width, mb_height),
> S5P_FIMV_TMV_BUFFER_ALIGN_V6);
> -
> - ctx->luma_dpb_size = ALIGN((mb_width * mb_height) *
> - S5P_FIMV_LUMA_MB_TO_PIXEL_V6,
> - S5P_FIMV_LUMA_DPB_BUFFER_ALIGN_V6);
> - ctx->chroma_dpb_size = ALIGN((mb_width * mb_height) *
> - S5P_FIMV_CHROMA_MB_TO_PIXEL_V6,
> - S5P_FIMV_CHROMA_DPB_BUFFER_ALIGN_V6);
> + if (IS_MFCV10(dev)) {
> + lcu_width = enc_lcu_width(ctx->img_width);
> + lcu_height = enc_lcu_height(ctx->img_height);
> + if (ctx->codec_mode != S5P_FIMV_CODEC_HEVC_ENC) {
> + ctx->luma_dpb_size =
> + ALIGNmb_width * 16) + 63) / 64)
> + * 64 * (((mb_height * 16) + 31)
> + / 32) * 32 + 64, 64);
> + ctx->chroma_dpb_size =
> + ALIGNmb_width * 16) + 63) / 64)
> + * 64 * (mb_height * 8)
> + + 64, 64);
> + } else {
> + ctx->luma_dpb_size =
> + ALIGNlcu_width * 32) + 63) / 64)
> + * 64 * (((
[char-misc-next 0/2] mei: reset flow fix
These patches should fix possible stall after device reset. The patches should be applied to the stable kernels 4.4 and newer as well, however, they do not apply cleanly hence a separate patch will be sent after are applied upstream. Alexander Usyskin (2): mei: me: add a wrapper to set host generated data interrupt mei: me: generate an interrupt if the hw indicates reset. drivers/misc/mei/hw-me.c | 37 +++-- 1 file changed, 31 insertions(+), 6 deletions(-) -- 2.7.4
[char-misc-next 2/2] mei: me: generate an interrupt if the hw indicates reset.
From: Alexander Usyskin
In rare case the driver may lose connection with the device after device
reset due to a missed interrupt. The driver will unlock the flow by
generating an interrupt towards the firmware (HIG) when the device is in
the resetting state. The FW is able to ignore the interrupt during
orderly flow. The effected platforms are skylake and newer.
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/hw-me.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index 23294b845c42..71216affcab1 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -394,6 +394,19 @@ static bool mei_me_hw_is_ready(struct mei_device *dev)
}
/**
+ * mei_me_hw_is_resetting - check whether the me(hw) is in reset
+ *
+ * @dev: mei device
+ * Return: bool
+ */
+static bool mei_me_hw_is_resetting(struct mei_device *dev)
+{
+ u32 mecsr = mei_me_mecsr_read(dev);
+
+ return (mecsr & ME_RST_HRA) == ME_RST_HRA;
+}
+
+/**
* mei_me_hw_ready_wait - wait until the me(hw) has turned ready
* or timeout is reached
*
@@ -1219,6 +1232,9 @@ irqreturn_t mei_me_irq_thread_handler(int irq, void
*dev_id)
goto end;
}
+ if (mei_me_hw_is_resetting(dev))
+ mei_hcsr_set_hig(dev);
+
mei_me_pg_intr(dev, me_intr_src(hcsr));
/* check if we need to start the dev */
--
2.7.4
[char-misc-next 1/2] mei: me: add a wrapper to set host generated data interrupt
From: Alexander Usyskin
Consolidate setting H_IG, an interrupt from host towards hw,
into a wrapper to eliminate code duplication.
Signed-off-by: Alexander Usyskin
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/hw-me.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/mei/hw-me.c b/drivers/misc/mei/hw-me.c
index befeac52c349..23294b845c42 100644
--- a/drivers/misc/mei/hw-me.c
+++ b/drivers/misc/mei/hw-me.c
@@ -140,6 +140,19 @@ static inline void mei_hcsr_set(struct mei_device *dev,
u32 reg)
}
/**
+ * mei_hcsr_set_hig - set host interrupt (set H_IG)
+ *
+ * @dev: the device structure
+ */
+static inline void mei_hcsr_set_hig(struct mei_device *dev)
+{
+ u32 hcsr;
+
+ hcsr = mei_hcsr_read(dev) | H_IG;
+ mei_hcsr_set(dev, hcsr);
+}
+
+/**
* mei_me_d0i3c_read - Reads 32bit data from the D0I3C register
*
* @dev: the device structure
@@ -505,7 +518,6 @@ static int mei_me_hbuf_write(struct mei_device *dev,
unsigned long rem;
unsigned long length = header->length;
u32 *reg_buf = (u32 *)buf;
- u32 hcsr;
u32 dw_cnt;
int i;
int empty_slots;
@@ -532,8 +544,7 @@ static int mei_me_hbuf_write(struct mei_device *dev,
mei_me_hcbww_write(dev, reg);
}
- hcsr = mei_hcsr_read(dev) | H_IG;
- mei_hcsr_set(dev, hcsr);
+ mei_hcsr_set_hig(dev);
if (!mei_me_hw_is_ready(dev))
return -EIO;
@@ -580,7 +591,6 @@ static int mei_me_read_slots(struct mei_device *dev,
unsigned char *buffer,
unsigned long buffer_length)
{
u32 *reg_buf = (u32 *)buffer;
- u32 hcsr;
for (; buffer_length >= sizeof(u32); buffer_length -= sizeof(u32))
*reg_buf++ = mei_me_mecbrw_read(dev);
@@ -591,8 +601,7 @@ static int mei_me_read_slots(struct mei_device *dev,
unsigned char *buffer,
memcpy(reg_buf, ®, buffer_length);
}
- hcsr = mei_hcsr_read(dev) | H_IG;
- mei_hcsr_set(dev, hcsr);
+ mei_hcsr_set_hig(dev);
return 0;
}
--
2.7.4
Re: [PATCH] drm: change connector disconnected debug message to an error
On Thu, 02 Feb 2017, Shuah Khan wrote:
> Change drm_helper_probe_single_connector_modes() to print an error to
> report connector disconnected status instead of a debug message.
>
> When this condition occurs, application doesn't know the real error and
> reports it as driver lacking support for mode setting. Change it to an
> error to make it easier to debug.
Please explain what makes this condition an error. Connectors get
connected and disconnected, business as usual, why should this be an
error?
BR,
Jani.
>
> Signed-off-by: Shuah Khan
> ---
> drivers/gpu/drm/drm_probe_helper.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index ac953f0..6472b7f 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -282,8 +282,8 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> dev->mode_config.poll_running = drm_kms_helper_poll;
>
> if (connector->status == connector_status_disconnected) {
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
> - connector->base.id, connector->name);
> + DRM_ERROR("[CONNECTOR:%d:%s] disconnected\n",
> + connector->base.id, connector->name);
> drm_mode_connector_update_edid_property(connector, NULL);
> verbose_prune = false;
> goto prune;
--
Jani Nikula, Intel Open Source Technology Center
Re: [PATCH 06/11] [media] videodev2.h: Add v4l2 definition for HEVC
On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add V4L2 definition for HEVC compressed format
>
> Signed-off-by: Smitha T Murthy
Beside small nitpick.
Reviewed-by: Andrzej Hajda
> ---
> include/uapi/linux/videodev2.h |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 46e8a2e3..620e941 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -630,6 +630,7 @@ struct v4l2_pix_format {
> #define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L') /* SMPTE
> 421M Annex L compliant stream */
> #define V4L2_PIX_FMT_VP8 v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
> #define V4L2_PIX_FMT_VP9 v4l2_fourcc('V', 'P', '9', '0') /* VP9 */
> +#define V4L2_PIX_FMT_HEVC v4l2_fourcc('H', 'E', 'V', 'C') /* HEVC */
I am not sure if it shouldn't be sorted alphabetically in compressed
formats stanza.
--
Regards
Andrzej
>
> /* Vendor-specific formats */
> #define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
Re: [RESENT PATCH] ARM: bcm2835: Add devicetree for the Raspberry Pi 3, for arm (32)
On Wed, 2017-02-01 at 13:20 +0100, Gerd Hoffmann wrote: > > > I think just having links from > > > arch/arm64/boot/dts/broadcom/bcm2837*.dts* to arch/arm/boot/dts/ > > > would > > > be the solution, then this Makefile could just reference > > > bcm2837-rpi-3-b.dtb. > > > > I suspect it is not that easy, last time I tried it didn't work. > > Will try again though. > > Yep, dtbs_install fails: > > [ ... ] > INSTALL arch/arm/boot/dts/bcm2835-rpi-b-plus.dtb > INSTALL arch/arm/boot/dts/bcm2835-rpi-a-plus.dtb > INSTALL arch/arm/boot/dts/bcm2836-rpi-2-b.dtb > INSTALL > cp: missing destination file operand after '/boot/dtbs/4.10.0-rc5+' > Try 'cp --help' for more information. > /root/linux/scripts/Makefile.dtbinst:41: recipe for target > 'bcm2837-rpi-3-b.dts' failed > make[3]: *** [bcm2837-rpi-3-b.dts] Error 1 > arch/arm/Makefile:348: recipe for target 'dtbs_install' failed > make[2]: *** [dtbs_install] Error 2 > Makefile:150: recipe for target 'sub-make' failed > make[1]: *** [sub-make] Error 2 > Makefile:24: recipe for target '__sub-make' failed This is actually a problem I had to deal with way in the begging of ARM64. What was done in the github tree was to have the one of the DTS files(in this case 64) #include the 32 bit dts. That way it's not needed to have the symbolic link and install should work. I know it's ulgy, but it works... Take a look at: https://github.com/raspberrypi/linux/blob/rpi-4.10.y/arch/arm64/boot/dt s/broadcom/bcm2710-rpi-3-b.dts Here is what the file contains: #define RPI364 #include "../../../../arm/boot/dts/bcm2710-rpi-3-b.dts"
Re: [PATCH 08/11] [media] s5p-mfc: Add VP9 decoder support
On 18.01.2017 11:02, Smitha T Murthy wrote:
> Add support for codec definition and corresponding buffer
> requirements for VP9 decoder.
>
> Signed-off-by: Smitha T Murthy
> ---
> drivers/media/platform/s5p-mfc/regs-mfc-v10.h |6 +
> 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.h|2 +
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 28
> +++
> 6 files changed, 48 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> index a57009a..81a0a96 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
> @@ -18,6 +18,8 @@
> /* MFCv10 register definitions*/
> #define S5P_FIMV_MFC_CLOCK_OFF_V10 0x7120
> #define S5P_FIMV_MFC_STATE_V10 0x7124
> +#define S5P_FIMV_D_STATIC_BUFFER_ADDR_V100xF570
> +#define S5P_FIMV_D_STATIC_BUFFER_SIZE_V100xF574
>
> /* MFCv10 Context buffer sizes */
> #define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K)/* 30KB */
> @@ -34,6 +36,10 @@
>
> /* MFCv10 codec defines*/
> #define S5P_FIMV_CODEC_HEVC_DEC 17
> +#define S5P_FIMV_CODEC_VP9_DEC 18
> +
> +/* Decoder buffer size for MFC v10 */
> +#define DEC_VP9_STATIC_BUFFER_SIZE 20480
>
> /* Encoder buffer size for MFC v10.0 */
> #define ENC_V100_H264_ME_SIZE(x, y) \
> 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 76eca67..102b47e 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c
> @@ -104,6 +104,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx
> *ctx)
> case S5P_MFC_CODEC_HEVC_DEC:
> codec_type = S5P_FIMV_CODEC_HEVC_DEC;
> break;
> + case S5P_MFC_CODEC_VP9_DEC:
> + codec_type = S5P_FIMV_CODEC_VP9_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 5c46060..e720ce6 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -80,6 +80,7 @@ static inline dma_addr_t s5p_mfc_mem_cookie(void *a, void
> *b)
> #define S5P_MFC_CODEC_VC1RCV_DEC 6
> #define S5P_MFC_CODEC_VP8_DEC7
> #define S5P_MFC_CODEC_HEVC_DEC 17
> +#define S5P_MFC_CODEC_VP9_DEC18
>
> #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 9f459b3..93626ed 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c
> @@ -164,6 +164,14 @@
> .num_planes = 1,
> .versions = MFC_V10_BIT,
> },
> + {
> + .name = "VP9 Encoded Stream",
> + .fourcc = V4L2_PIX_FMT_VP9,
> + .codec_mode = S5P_FIMV_CODEC_VP9_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.h
> b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> index 6478f70..565decf 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr.h
> @@ -170,6 +170,8 @@ struct s5p_mfc_regs {
> 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 */
> + void __iomem *d_static_buffer_addr; /* v10 */
> + void __iomem *d_static_buffer_size; /* v10 */
>
> /* encoder registers */
> void __iomem *e_frame_width;
> 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 b6cb280..da4202f 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -227,6 +227,13 @@ static int s5p_mfc_alloc_codec_buffers_v6(struct
> s5p_mfc_ctx *ctx)
> ctx->scratch_buf_size +
> (ctx->mv_count * ctx->mv_size);
> break;
> + case S5P_MFC_CODEC_VP9_DEC:
> + mfc_debug(2, "Use min scratch buffer size\n");
> + ctx->scratch_buf_size = ALIGN(ctx->scratch_buf_si
RE: linux-next: manual merge of the net-next tree with Linus' tree
>-Original Message-
>From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
>Behalf Of Stephen Rothwell
>Sent: Thursday, February 02, 2017 3:50 AM
>To: David Miller ; Networking
>Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Yotam Gigi
>
>Subject: linux-next: manual merge of the net-next tree with Linus' tree
>
>Hi all,
>
>Today's linux-next merge of the net-next tree got a conflict in:
>
> net/sched/cls_matchall.c
>
>between commit:
>
> fd62d9f5c575 ("net/sched: matchall: Fix configuration race")
>
>from Linus' tree and commit:
>
> ec2507d2a306 ("net/sched: cls_matchall: Fix error path")
>
>from the net-next tree.
>
>I fixed it up (see below) and can carry the fix as necessary. This
>is now fixed as far as linux-next is concerned, but any non trivial
>conflicts should be mentioned to your upstream maintainer when your tree
>is submitted for merging. You may also want to consider cooperating
>with the maintainer of the conflicting tree to minimise any particularly
>complex conflicts.
Looks good. Thanks!
>
>--
>Cheers,
>Stephen Rothwell
>
>diff --cc net/sched/cls_matchall.c
>index b12bc2abea93,fcecf5aac666..
>--- a/net/sched/cls_matchall.c
>+++ b/net/sched/cls_matchall.c
>@@@ -118,19 -141,24 +118,24 @@@ static int mall_set_parms(struct net *n
> struct tcf_exts e;
> int err;
>
>- tcf_exts_init(&e, TCA_MATCHALL_ACT, 0);
>+ err = tcf_exts_init(&e, TCA_MATCHALL_ACT, 0);
>+ if (err)
>+ return err;
> err = tcf_exts_validate(net, tp, tb, est, &e, ovr);
> if (err < 0)
>- return err;
>+ goto errout;
>
> if (tb[TCA_MATCHALL_CLASSID]) {
> - f->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
> - tcf_bind_filter(tp, &f->res, base);
> + head->res.classid = nla_get_u32(tb[TCA_MATCHALL_CLASSID]);
> + tcf_bind_filter(tp, &head->res, base);
> }
>
> - tcf_exts_change(tp, &f->exts, &e);
> + tcf_exts_change(tp, &head->exts, &e);
>
> return 0;
>+ errout:
>+ tcf_exts_destroy(&e);
>+ return err;
> }
>
> static int mall_change(struct net *net, struct sk_buff *in_skb,
>@@@ -162,39 -194,43 +167,44 @@@
> return -EINVAL;
> }
>
> - f = kzalloc(sizeof(*f), GFP_KERNEL);
> - if (!f)
> + new = kzalloc(sizeof(*new), GFP_KERNEL);
> + if (!new)
> return -ENOBUFS;
>
>- tcf_exts_init(&new->exts, TCA_MATCHALL_ACT, 0);
> - err = tcf_exts_init(&f->exts, TCA_MATCHALL_ACT, 0);
>++ err = tcf_exts_init(&new->exts, TCA_MATCHALL_ACT, 0);
>+ if (err)
>+ goto err_exts_init;
>
> if (!handle)
> handle = 1;
> - f->handle = handle;
> - f->flags = flags;
> + new->handle = handle;
> + new->flags = flags;
>
> - err = mall_set_parms(net, tp, f, base, tb, tca[TCA_RATE], ovr);
> + err = mall_set_parms(net, tp, new, base, tb, tca[TCA_RATE], ovr);
> if (err)
>- goto errout;
>+ goto err_set_parms;
>
> if (tc_should_offload(dev, tp, flags)) {
> - err = mall_replace_hw_filter(tp, f, (unsigned long) f);
> + err = mall_replace_hw_filter(tp, new, (unsigned long) new);
> if (err) {
> if (tc_skip_sw(flags))
>- goto errout;
>+ goto err_replace_hw_filter;
> else
> err = 0;
> }
> }
>
> - *arg = (unsigned long) f;
> - rcu_assign_pointer(head->filter, f);
> -
> + *arg = (unsigned long) head;
> + rcu_assign_pointer(tp->root, new);
> + if (head)
> + call_rcu(&head->rcu, mall_destroy_rcu);
> return 0;
>
>- errout:
>+ err_replace_hw_filter:
>+ err_set_parms:
> - tcf_exts_destroy(&f->exts);
>++ tcf_exts_destroy(&new->exts);
>+ err_exts_init:
> - kfree(f);
> + kfree(new);
> return err;
> }
>
Re: [PATCH 09/11] [media] s5p-mfc: Add support for HEVC encoder
On 18.01.2017 11:02, Smitha T Murthy wrote: > Add HEVC encoder support and necessary registers, V4L2 CIDs, > and hevc encoder parameters > > Signed-off-by: Smitha T Murthy > --- > drivers/media/platform/s5p-mfc/regs-mfc-v10.h | 28 +- > drivers/media/platform/s5p-mfc/s5p_mfc.c|1 + > drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c |3 + > drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 55 ++- > drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 595 > +++ > drivers/media/platform/s5p-mfc/s5p_mfc_opr.h|8 + > drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 200 > drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.h |7 + > 8 files changed, 895 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 81a0a96..914ffec 100644 > --- a/drivers/media/platform/s5p-mfc/regs-mfc-v10.h > +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h > @@ -20,13 +20,35 @@ > #define S5P_FIMV_MFC_STATE_V10 0x7124 > #define S5P_FIMV_D_STATIC_BUFFER_ADDR_V100xF570 > #define S5P_FIMV_D_STATIC_BUFFER_SIZE_V100xF574 > +#define S5P_FIMV_E_NUM_T_LAYER_V10 0xFBAC > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER0_V100xFBB0 > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER1_V100xFBB4 > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER2_V100xFBB8 > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER3_V100xFBBC > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER4_V100xFBC0 > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER5_V100xFBC4 > +#define S5P_FIMV_E_HIERARCHICAL_QP_LAYER6_V100xFBC8 > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER0_V10 0xFD18 > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER1_V10 0xFD1C > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER2_V10 0xFD20 > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER3_V10 0xFD24 > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER4_V10 0xFD28 > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER5_V10 0xFD2C > +#define S5P_FIMV_E_HIERARCHICAL_BIT_RATE_LAYER6_V10 0xFD30 > +#define S5P_FIMV_E_HEVC_OPTIONS_V10 0xFDD4 > +#define S5P_FIMV_E_HEVC_REFRESH_PERIOD_V10 0xFDD8 > +#define S5P_FIMV_E_HEVC_CHROMA_QP_OFFSET_V10 0xFDDC > +#define S5P_FIMV_E_HEVC_LF_BETA_OFFSET_DIV2_V10 0xFDE0 > +#define S5P_FIMV_E_HEVC_LF_TC_OFFSET_DIV2_V100xFDE4 > +#define S5P_FIMV_E_HEVC_NAL_CONTROL_V10 0xFDE8 > > /* MFCv10 Context buffer sizes */ > #define MFC_CTX_BUF_SIZE_V10 (30 * SZ_1K)/* 30KB */ > #define MFC_H264_DEC_CTX_BUF_SIZE_V10(2 * SZ_1M) /* 2MB */ > #define MFC_OTHER_DEC_CTX_BUF_SIZE_V10 (20 * SZ_1K)/* 20KB */ > #define MFC_H264_ENC_CTX_BUF_SIZE_V10(100 * SZ_1K) /* 100KB */ > -#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10 (15 * SZ_1K)/* 15KB */ > +#define MFC_HEVC_ENC_CTX_BUF_SIZE_V10(30 * SZ_1K)/* 30KB */ > +#define MFC_OTHER_ENC_CTX_BUF_SIZE_V10 (15 * SZ_1K) /* 15KB */ > > /* MFCv10 variant defines */ > #define MAX_FW_SIZE_V10 (SZ_1M) /* 1MB */ > @@ -37,6 +59,7 @@ > /* MFCv10 codec defines*/ > #define S5P_FIMV_CODEC_HEVC_DEC 17 > #define S5P_FIMV_CODEC_VP9_DEC 18 > +#define S5P_FIMV_CODEC_HEVC_ENC 26 > > /* Decoder buffer size for MFC v10 */ > #define DEC_VP9_STATIC_BUFFER_SIZE 20480 > @@ -53,6 +76,9 @@ > #define ENC_V100_VP8_ME_SIZE(x, y) \ > (((x + 3) * (y + 3) * 8)\ >+ (((y * 64) + 1280) * (x + 7) / 8)) > +#define ENC_V100_HEVC_ME_SIZE(x, y) \ > + (((x + 3) * (y + 3) * 32) \ > + + (((y * 128) + 1280) * (x + 3) / 4)) Use DIV_ROUND_UP. > > #endif /*_REGS_MFC_V10_H*/ > > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c > b/drivers/media/platform/s5p-mfc/s5p_mfc.c > index b014038..b01c556 100644 > --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c > @@ -1549,6 +1549,7 @@ static int s5p_mfc_resume(struct device *dev) > .h264_dec_ctx = MFC_H264_DEC_CTX_BUF_SIZE_V10, > .other_dec_ctx = MFC_OTHER_DEC_CTX_BUF_SIZE_V10, > .h264_enc_ctx = MFC_H264_ENC_CTX_BUF_SIZE_V10, > + .hevc_enc_ctx = MFC_HEVC_ENC_CTX_BUF_SIZE_V10, > .other_enc_ctx = MFC_OTHER_ENC_CTX_BUF_SIZE_V10, > }; > > 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 102b47e..7521fce 100644 > --- a/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v6.c > @@ -122,6 +122,9 @@ static int s5p_mfc_open_inst_cmd_v6(struct s5p_mfc_ctx > *ctx) > case S5P_MFC_CODEC_VP8_ENC: > codec_type = S5P_FIMV_CODEC_VP8_ENC_V7; > break; > + case S5P_MFC_CODEC_HEVC_ENC:
Re: Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness
On Wed, Feb 01, 2017 at 11:04:54AM -0800, Joe Perches wrote: > > +#define order_base_2(n)\ > > +( \ > > + __builtin_constant_p(n) ? ( \ > > + ((n) < 2) ? (n) : \ > > + ilog2((n) - 1) + 1) : \ > > + __order_base_2(n) \ > > + ) > > Does this work properly when n is a signed negative value? Do you see it returning a complex number?
Re: net/tcp: warning in tcp_try_coalesce/skb_try_coalesce
On Tue, Jan 31, 2017 at 3:27 PM, 'Eric Dumazet' via syzkaller wrote: > On Tue, Jan 31, 2017 at 5:17 AM, Andrey Konovalov > wrote: >> Hi, >> >> I've got the following error report while running the syzkaller fuzzer. >> >> On commit 566cf877a1fcb6d6dc0126b076aad062054c2637 (4.10-rc6). >> >> The fuzzer hits this issue quite often, but I don't have a working >> reproducer. >> >> WARNING: CPU: 3 PID: 7091 at net/core/skbuff.c:4331 >> skb_try_coalesce+0x14b1/0x1f80 net/core/skbuff.c:4331 >> Kernel panic - not syncing: panic_on_warn set ... ... > Have you tried the patch we added recently into net-next ? > > https://git.kernel.org/cgit/linux/kernel/git/davem/net-next.git/commit/?id=158f323b9868b59967ad96957c4ca388161be321 I've tried this patch, and it does _not_ help. I am currently on a2ca3d617944417e9dd5f09fc8a4549cda115f4f, and I applied the patch on top (had to do a little merging in af_netlink.c): https://gist.githubusercontent.com/dvyukov/b4fd206f7dde763b3113a4543c57e7bb/raw/784c5b1bcb06f2a22c55eb4c4f8f83d627cd1ab9/gistfile1.txt Still getting the same warning. But now I have a repro: https://gist.githubusercontent.com/dvyukov/88fdb6d93507b36f81377191b0694f9b/raw/81cc11e8b78b6bbc5cffc79b442ce998c49af226/gistfile1.txt WARNING: CPU: 2 PID: 2958 at net/core/skbuff.c:4339 skb_try_coalesce+0x154c/0x2020 net/core/skbuff.c:4339 Kernel panic - not syncing: panic_on_warn set ... CPU: 2 PID: 2958 Comm: a.out Not tainted 4.10.0-rc6+ #206 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 panic+0x1fb/0x412 kernel/panic.c:179 __warn+0x1c4/0x1e0 kernel/panic.c:539 warn_slowpath_null+0x2c/0x40 kernel/panic.c:582 skb_try_coalesce+0x154c/0x2020 net/core/skbuff.c:4339 tcp_try_coalesce+0x16f/0x560 net/ipv4/tcp_input.c:4337 tcp_queue_rcv+0x12d/0x790 net/ipv4/tcp_input.c:4572 tcp_data_queue+0x96f/0x46b0 net/ipv4/tcp_input.c:4681 tcp_rcv_state_process+0xd92/0x42c0 net/ipv4/tcp_input.c:6130 tcp_v4_do_rcv+0x56b/0x940 net/ipv4/tcp_ipv4.c:1426 sk_backlog_rcv include/net/sock.h:893 [inline] __release_sock+0x126/0x3a0 net/core/sock.c:2053 release_sock+0xa5/0x2b0 net/core/sock.c:2540 inet_shutdown+0x1a8/0x350 net/ipv4/af_inet.c:833 SYSC_shutdown net/socket.c:1840 [inline] SyS_shutdown+0x23d/0x2d0 net/socket.c:1831 entry_SYSCALL_64_fastpath+0x1f/0xc2 RIP: 0033:0x443b39 RSP: 002b:7ffcfd0814f8 EFLAGS: 0206 ORIG_RAX: 0030 RAX: ffda RBX: 004031d0 RCX: 00443b39 RDX: RSI: 0001 RDI: 0003 RBP: R08: R09: R10: R11: 0206 R12: 004002b0 R13: 004031d0 R14: 00403260 R15: Kernel Offset: disabled Rebooting in 86400 seconds..
[PATCH V2] Add devicetree for the Raspberry Pi 3, for arm (32)
Signed-off-by: Michael Zoran --- arch/arm/boot/dts/Makefile| 3 ++- arch/arm/boot/dts/bcm2837-rpi-3-b.dts | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/bcm2837-rpi-3-b.dts diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 8bd8878efe7b..72ba524df912 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -72,7 +72,8 @@ dtb-$(CONFIG_ARCH_BCM2835) += \ bcm2835-rpi-b-plus.dtb \ bcm2835-rpi-a-plus.dtb \ bcm2836-rpi-2-b.dtb \ - bcm2835-rpi-zero.dtb + bcm2835-rpi-zero.dtb \ + bcm2837-rpi-3-b.dtb dtb-$(CONFIG_ARCH_BCM_5301X) += \ bcm4708-asus-rt-ac56u.dtb \ bcm4708-asus-rt-ac68u.dtb \ diff --git a/arch/arm/boot/dts/bcm2837-rpi-3-b.dts b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts new file mode 100644 index ..48ad20f83255 --- /dev/null +++ b/arch/arm/boot/dts/bcm2837-rpi-3-b.dts @@ -0,0 +1,2 @@ +#include "../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts" + -- 2.11.0
Re: [PATCHv7 6/8] printk: use printk_safe buffers in printk
On Thu, Feb 02, 2017 at 11:11:34AM +0900, Sergey Senozhatsky wrote: > On (02/01/17 16:39), Petr Mladek wrote: > [..] > > I guess that you are talking about the introduction of > > #define SCHED_WARN_ON(x)WARN_ONCE(x, #x) > > my guess would be that Jan was talking about printk_deferred() patch. > it's on my TODO list. > > I want to entirely remove console_sem and scheduler out of printk() path. > that's the only way to make printk() deadlock safe. And useless.. if you never get around to the 'later' part where you print the content. This way you still mostly get the output. And no, its not the only way, see my printk->early_printk patches. early serial console only does a loop over outb, impossible to mess that up.
[PATCH v7 1/3] dt: bindings: add documentation for zx2967 family watchdog controller
This patch adds dt-binding documentation for zx2967 family
watchdog controller.
Signed-off-by: Baoyou Xie
Acked-by: Rob Herring
---
.../bindings/watchdog/zte,zx2967-wdt.txt | 32 ++
1 file changed, 32 insertions(+)
create mode 100644
Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
new file mode 100644
index 000..06ce677
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt
@@ -0,0 +1,32 @@
+ZTE zx2967 Watchdog timer
+
+Required properties:
+
+- compatible : should be one of the following.
+ * zte,zx296718-wdt
+- reg : Specifies base physical address and size of the registers.
+- clocks : Pairs of phandle and specifier referencing the controller's clocks.
+- resets : Reference to the reset controller controlling the watchdog
+ controller.
+
+Optional properties:
+
+- timeout-sec : Contains the watchdog timeout in seconds.
+- zte,wdt-reset-sysctrl : Directs how to reset system by the watchdog.
+ if we don't want to restart system when watchdog been triggered,
+ it's not required, vice versa.
+ It should include following fields.
+ * phandle of aon-sysctrl.
+ * offset of register that be written, should be 0xb0.
+ * configure value that be written to aon-sysctrl.
+ * bit mask, corresponding bits will be affected.
+
+Example:
+
+wdt: watchdog@1465000 {
+ compatible = "zte,zx296718-wdt";
+ reg = <0x1465000 0x1000>;
+ clocks = <&topcrm WDT_WCLK>;
+ resets = <&toprst 35>;
+ zte,wdt-reset-sysctrl = <&aon_sysctrl 0xb0 1 0x115>;
+};
--
2.7.4
[PATCH v7 2/3] MAINTAINERS: add zx2967 watchdog controller driver to ARM ZTE architecture
Add the zx2967 watchdog controller driver as maintained by ARM ZTE architecture maintainers, as they're parts of the core IP. Signed-off-by: Baoyou Xie --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index edfdea3..275c434 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1990,11 +1990,13 @@ F: drivers/clk/zte/ F: drivers/reset/reset-zx2967.c F: drivers/soc/zte/ F: drivers/thermal/zx* +F: drivers/watchdog/zx2967_wdt.c F: Documentation/devicetree/bindings/arm/zte.txt F: Documentation/devicetree/bindings/clock/zx296702-clk.txt F: Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt F: Documentation/devicetree/bindings/soc/zte/ F: Documentation/devicetree/bindings/thermal/zx* +F: Documentation/devicetree/bindings/watchdog/zte,zx2967-wdt.txt F: include/dt-bindings/soc/zx*.h ARM/ZYNQ ARCHITECTURE -- 2.7.4
Re: [PATCH v2 2/5] userfaultfd: non-cooperative: add event for memory unmaps
On Fri 27-01-17 20:44:30, Mike Rapoport wrote:
> When a non-cooperative userfaultfd monitor copies pages in the background,
> it may encounter regions that were already unmapped. Addition of
> UFFD_EVENT_UNMAP allows the uffd monitor to track precisely changes in the
> virtual memory layout.
>
> Since there might be different uffd contexts for the affected VMAs, we
> first should create a temporary representation for the unmap event for each
> uffd context and then notify them one by one to the appropriate userfault
> file descriptors.
>
> The event notification occurs after the mmap_sem has been released.
>
> Signed-off-by: Mike Rapoport
> Acked-by: Hillf Danton
This breaks NOMMU compilation
---
>From 510948533b059f4f5033464f9f4a0c32d4ab0c08 Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Thu, 2 Feb 2017 10:08:47 +0100
Subject: [PATCH] mmotm:
userfaultfd-non-cooperative-add-event-for-memory-unmaps-fix
This breaks compilation on nommu configs.
mm/nommu.c:1201:15: error: conflicting types for 'do_mmap'
unsigned long do_mmap(struct file *file,
^
In file included from mm/nommu.c:19:0:
./include/linux/mm.h:2089:22: note: previous declaration of 'do_mmap' was here
extern unsigned long do_mmap(struct file *file, unsigned long addr,
^
mm/nommu.c:1580:5: error: conflicting types for 'do_munmap'
int do_munmap(struct mm_struct *mm, unsigned long start, size_t len)
^
In file included from mm/nommu.c:19:0:
./include/linux/mm.h:2093:12: note: previous declaration of 'do_munmap' was here
extern int do_munmap(struct mm_struct *, unsigned long, size_t,
^
make[1]: *** [mm/nommu.o] Error 1
CONFIG_USERFAULTFD depends on CONFIG_MMU so I guess we are OK to just ignore the
argument.
Signed-off-by: Michal Hocko
---
mm/nommu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index d35088a4b73d..f78d06459ba4 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1205,7 +1205,8 @@ unsigned long do_mmap(struct file *file,
unsigned long flags,
vm_flags_t vm_flags,
unsigned long pgoff,
- unsigned long *populate)
+ unsigned long *populate,
+ struct list_head *uf_unused)
{
struct vm_area_struct *vma;
struct vm_region *region;
@@ -1577,7 +1578,7 @@ static int shrink_vma(struct mm_struct *mm,
* - under NOMMU conditions the chunk to be unmapped must be backed by a single
* VMA, though it need not cover the whole VMA
*/
-int do_munmap(struct mm_struct *mm, unsigned long start, size_t len)
+int do_munmap(struct mm_struct *mm, unsigned long start, size_t len, struct
list_head *uf)
{
struct vm_area_struct *vma;
unsigned long end;
@@ -1643,7 +1644,7 @@ int vm_munmap(unsigned long addr, size_t len)
int ret;
down_write(&mm->mmap_sem);
- ret = do_munmap(mm, addr, len);
+ ret = do_munmap(mm, addr, len, NULL);
up_write(&mm->mmap_sem);
return ret;
}
--
2.11.0
--
Michal Hocko
SUSE Labs
[PATCH v7 3/3] watchdog: zx2967: add watchdog controller driver for ZTE's zx2967 family
This patch adds watchdog controller driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie
---
drivers/watchdog/Kconfig | 10 ++
drivers/watchdog/Makefile | 1 +
drivers/watchdog/zx2967_wdt.c | 274 ++
3 files changed, 285 insertions(+)
create mode 100644 drivers/watchdog/zx2967_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index acb00b5..05093a2 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -714,6 +714,16 @@ config ASPEED_WATCHDOG
To compile this driver as a module, choose M here: the
module will be called aspeed_wdt.
+config ZX2967_WATCHDOG
+ tristate "ZTE zx2967 SoCs watchdog support"
+ depends on ARCH_ZX
+ select WATCHDOG_CORE
+ help
+ Say Y here to include support for the watchdog timer
+ in ZTE zx2967 SoCs.
+ To compile this driver as a module, choose M here: the
+ module will be called zx2967_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 0c3d35e..bf2d296 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_BCM7038_WDT) += bcm7038_wdt.o
obj-$(CONFIG_ATLAS7_WATCHDOG) += atlas7_wdt.o
obj-$(CONFIG_RENESAS_WDT) += renesas_wdt.o
obj-$(CONFIG_ASPEED_WATCHDOG) += aspeed_wdt.o
+obj-$(CONFIG_ZX2967_WATCHDOG) += zx2967_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/zx2967_wdt.c b/drivers/watchdog/zx2967_wdt.c
new file mode 100644
index 000..818f17e
--- /dev/null
+++ b/drivers/watchdog/zx2967_wdt.c
@@ -0,0 +1,274 @@
+/*
+ * watchdog driver for ZTE's zx2967 family
+ *
+ * Copyright (C) 2017 ZTE Ltd.
+ *
+ * Author: Baoyou Xie
+ *
+ * License terms: GNU General Public License (GPL) version 2
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define ZX2967_WDT_CFG_REG 0x4
+#define ZX2967_WDT_LOAD_REG0x8
+#define ZX2967_WDT_REFRESH_REG 0x18
+#define ZX2967_WDT_START_REG 0x1c
+
+#define ZX2967_WDT_REFRESH_MASK0x3f
+
+#define ZX2967_WDT_CFG_DIV(n) n) & 0xff) - 1) << 8)
+#define ZX2967_WDT_START_EN0x1
+
+#define ZX2967_WDT_WRITEKEY0x1234
+
+#define ZX2967_WDT_DIV_DEFAULT 16
+#define ZX2967_WDT_DEFAULT_TIMEOUT 32
+#define ZX2967_WDT_MIN_TIMEOUT 1
+#define ZX2967_WDT_MAX_TIMEOUT 524
+#define ZX2967_WDT_MAX_COUNT 0x
+
+#define ZX2967_WDT_CLK_FREQ0x8000
+
+#define ZX2967_WDT_FLAG_REBOOT_MON BIT(0)
+
+struct zx2967_wdt {
+ struct watchdog_device wdt_device;
+ void __iomem*reg_base;
+ struct clk *clock;
+};
+
+static inline u32 zx2967_wdt_readl(struct zx2967_wdt *wdt, u16 reg)
+{
+ return readl_relaxed(wdt->reg_base + reg);
+}
+
+static inline void zx2967_wdt_writel(struct zx2967_wdt *wdt, u16 reg, u32 val)
+{
+ writel_relaxed(val | ZX2967_WDT_WRITEKEY, wdt->reg_base + reg);
+}
+
+static void zx2967_wdt_refresh(struct zx2967_wdt *wdt)
+{
+ u32 val;
+
+ val = zx2967_wdt_readl(wdt, ZX2967_WDT_REFRESH_REG);
+ val ^= ZX2967_WDT_REFRESH_MASK;
+ zx2967_wdt_writel(wdt, ZX2967_WDT_REFRESH_REG, val);
+}
+
+static int
+zx2967_wdt_set_timeout(struct watchdog_device *wdd, unsigned int timeout)
+{
+ struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
+ unsigned int divisor = ZX2967_WDT_DIV_DEFAULT;
+ unsigned int count;
+
+ count = timeout * ZX2967_WDT_CLK_FREQ;
+ if (count > divisor * ZX2967_WDT_MAX_COUNT)
+ divisor = DIV_ROUND_UP(count, ZX2967_WDT_MAX_COUNT);
+ count = DIV_ROUND_UP(count, divisor);
+ zx2967_wdt_writel(wdt, ZX2967_WDT_CFG_REG, ZX2967_WDT_CFG_DIV(divisor));
+ zx2967_wdt_writel(wdt, ZX2967_WDT_LOAD_REG, count);
+ zx2967_wdt_refresh(wdt);
+ wdd->timeout = (count * divisor) / ZX2967_WDT_CLK_FREQ;
+
+ return 0;
+}
+
+static void __zx2967_wdt_start(struct zx2967_wdt *wdt)
+{
+ u32 val;
+
+ val = zx2967_wdt_readl(wdt, ZX2967_WDT_START_REG);
+ val |= ZX2967_WDT_START_EN;
+ zx2967_wdt_writel(wdt, ZX2967_WDT_START_REG, val);
+}
+
+static void __zx2967_wdt_stop(struct zx2967_wdt *wdt)
+{
+ u32 val;
+
+ val = zx2967_wdt_readl(wdt, ZX2967_WDT_START_REG);
+ val &= ~ZX2967_WDT_START_EN;
+ zx2967_wdt_writel(wdt, ZX2967_WDT_START_REG, val);
+}
+
+static int zx2967_wdt_start(struct watchdog_device *wdd)
+{
+ struct zx2967_wdt *wdt = watchdog_get_drvdata(wdd);
+
+ zx2967_wdt_set_timeout(wdd, wdd->timeout);
+ __zx2967_wdt_start(wdt);
+
+ return 0;
+}
+
+static int zx2967_wdt_stop(struct watchdog_de
Re: Build failure with v4.9-rc1 and GCC trunk -- compiler weirdness
On 1 February 2017 at 21:50, Laura Abbott wrote:
> On 02/01/2017 09:36 AM, Ard Biesheuvel wrote:
>> On 1 February 2017 at 16:58, Laura Abbott wrote:
>>> On 10/19/2016 09:22 AM, Will Deacon wrote:
On Wed, Oct 19, 2016 at 09:01:33AM -0700, Linus Torvalds wrote:
> On Wed, Oct 19, 2016 at 8:56 AM, Markus Trippelsdorf
> wrote:
>> On 2016.10.19 at 08:55 -0700, Linus Torvalds wrote:
>>>
>>> Well, in the meantime we apparently have to live with it. Unless Will
>>> is using some unreleased gcc version that nobody else is using and we
>>> can just ignore it?
>>
>> Yes, he is using gcc-7 that is unreleased. (It will be released April
>> next year.)
>
> Ahh, self-built? So it's not part of some experimental ARM distro
> setup and this will be annoying lots of people?
Our friendly compiler guys built it, but it's just a snapshot of trunk,
so it's all heading towards GCC 7.0. AFAIU, the problematic optimisation
is also a mid-end pass, so it would affect other architectures too.
> If so, still think that we could just get rid of the ilog2_NaN()
> thing as it's not _that_ important, but it's certainly not very
> high-priority. Will can do it in his tree too for testing, and it can
> remind people to get the gcc problem fixed.
I'm carrying the diff below, which fixes arm64 defconfig, but I'm worried
that we might be relying on this trick elsewhere. The arm __bad_cmpxchg
function, for example.
Will
--->8
diff --git a/include/linux/log2.h b/include/linux/log2.h
index fd7ff3d91e6a..9cf5ad69065d 100644
--- a/include/linux/log2.h
+++ b/include/linux/log2.h
@@ -16,12 +16,6 @@
#include
/*
- * deal with unrepresentable constant logarithms
- */
-extern __attribute__((const, noreturn))
-int ilog2_NaN(void);
-
-/*
* non-constant log of base 2 calculators
* - the arch may override these in asm/bitops.h if they can be
implemented
* more efficiently than using fls() and fls64()
@@ -85,7 +79,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
#define ilog2(n) \
(\
__builtin_constant_p(n) ? ( \
- (n) < 1 ? ilog2_NaN() : \
+ (n) < 1 ? 0 : \
(n) & (1ULL << 63) ? 63 : \
(n) & (1ULL << 62) ? 62 : \
(n) & (1ULL << 61) ? 61 : \
@@ -149,9 +143,7 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
(n) & (1ULL << 3) ? 3 : \
(n) & (1ULL << 2) ? 2 : \
(n) & (1ULL << 1) ? 1 : \
- (n) & (1ULL << 0) ? 0 : \
- ilog2_NaN() \
-) : \
+ 0) :\
(sizeof(n) <= 4) ? \
__ilog2_u32(n) :\
__ilog2_u64(n) \
@@ -194,7 +186,6 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
* @n: parameter
*
* The first few values calculated by this routine:
- * ob2(0) = 0
* ob2(1) = 0
* ob2(2) = 1
* ob2(3) = 2
>>>
>>> Reviving this thread as gcc 7 has now hit Fedora rawhide and has this
>>> same issue. I pulled in the above patch from Will as a temporary work
>>> around for building. It didn't look like there was consensus on a
>>> permanent solution though from the thread.
>>>
>>
>> I still think order_base_2() is broken, since it may invoke
>> roundup_pow_of_two() with an input value that is documented as
>> producing undefined output. I would argue that the below is the
>> correct fix.
>>
>> diff --git a/include/linux/log2.h b/include/linux/log2.h
>> index fd7ff3d91e6a..46523731bec0 100644
>> --- a/include/linux/log2.h
>> +++ b/include/linux/log2.h
>> @@ -203,6 +203,18 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
>> * ... and so on.
>> */
>>
>> -#define order_base_2(n) ilog2(roundup_pow_of_two(n))
>> +static inline __attribute__((__const__))
>> +unsigned long __order_base_2(unsigned long n)
>> +{
>> + return n ? 1UL << fls_long(n - 1) : 1;
>> +}
>> +
>> +#define order_base_2(n)\
>> +( \
>> + __builtin_constant_p(n) ? ( \
>> + ((n) < 2) ? (n) : \
>> + ilog2((n) - 1) + 1) : \
>> + ilog2(__order_base_2(n))\
>> + )
>>
>> #endif /* _LINUX_LOG2_H */
>>
>
> This fixes the problem although the comments should be updated
> as well.
This brings order_base_2() in line with the comments, so I am
[RESEND PATCH V5 7/8] thermal: da9062/61: Thermal junction temperature monitoring driver
From: Steve Twiss
Add junction temperature monitoring supervisor device driver, compatible
with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is added.
If the PMIC's internal junction temperature rises above T_WARN (125 degC)
an interrupt is issued. This T_WARN level is defined as the
THERMAL_TRIP_HOT trip-wire inside the device driver.
The thermal triggering mechanism is interrupt based and happens when the
temperature rises above a given threshold level. The component cannot
return an exact temperature, it only has knowledge if the temperature is
above or below a given threshold value. A status bit must be polled to
detect when the temperature falls below that threshold level again. A
kernel work queue is configured to repeatedly poll and detect when the
temperature falls below this trip-wire, between 1 and 10 second intervals
(defaulting at 3 seconds).
This scheme is provided as an example. It would be expected that any
final implementation will also include a notify() function and any of these
settings could be altered to match the application where appropriate.
When over-temperature is reached, the interrupt from the DA9061/2 will be
repeatedly triggered. The IRQ is therefore disabled when the first
over-temperature event happens and the status bit is polled using a
work-queue until it becomes false.
This strategy is designed to allow the periodic transmission of uevents
(HOT trip point) as the first level of temperature supervision method. It
is intended for non-invasive temperature control, where the necessary
measures for cooling the system down are left to the host software. Once
the temperature falls again, the IRQ is re-enabled so a new critical
over-temperature event can be detected.
Reviewed-by: Lukasz Luba
Signed-off-by: Steve Twiss
---
This patch applies against linux-next and v4.9
v4 -> v5
- Rebased from v4.8 to v4.9
- Updates from comments by Eduardo Valentin
- Replace vendor defined dlg,tjunc-temp-polling-period-ms with standard
thermal core polling-delay-passive as part of the device tree
initialisation
- Change to the commit message content and device driver source code to
include an explanation of the repeated uevent strategy for monitoring
over-temperature
- Rename warning threshold name from TEMP_WARN to T_WARN to match the
latest datasheet naming convention
- Added reviewed-by Lukasz Luba to commit message
v3 -> v4
- Patch renamed from [PATCH V3 8/9] to [PATCH V4 7/8]
- Reordering of cancel_delayed_work_sync() in remove function
- dev_warn() message for out-of-range polling period requests
- Explanatory comment for expected values defined for
DEFAULT_POLLING_MS_PERIOD, MAX_POLLING_MS_PERIOD and
MIN_POLLING_MS_PERIOD
v2 -> v3
- Patch renamed from [PATCH V2 09/10] to [PATCH V3 8/9]
- Addition of MODULE_DEVICE_TABLE macro to allow modinfo additions
v1 -> v2
- Patch renamed from [PATCH V1 05/10] to [PATCH V2 09/10] -- these
changes were made to fix checkpatch warnings caused by the patch
set dependency order
- List the header files in alphabetical order
- Remove "GPL v2" and replace with MODULE_LICENSE("GPL") to match the
copyright "GNU Public License v2 or later" option in the header
comment for this file. See the allowed identifiers in the file
include/linux/module.h +170
- Remove notify function "da9062_thermal_notify" function.
- MODULE_AUTHOR() macros removes Company Name and just gives Name in
accordance with include/linux/module.h +200
- Remove the compatible "dlg,da9061-thermal" option in the of_device_id
struct table. This patch now assumes the use of a DA9062 fallback
compatible string in the DTS when using the DA9061 thermal component
of the DA9061 device.
- Re-ordered some assignments earlier in the probe() for thermal->hw,
thermal->polling_period, thermal->mode, thermal->dev
- Added further information in the patch description to explain the use
of the device driver's built-in work-queue.
Regards,
Steve Twiss, Dialog Semiconductor Ltd.
drivers/thermal/Kconfig | 10 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/da9062-thermal.c | 314 +++
3 files changed, 325 insertions(+)
create mode 100644 drivers/thermal/da9062-thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index a13541b..400d15c 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -292,6 +292,16 @@ config DB8500_CPUFREQ_COOLING
bound cpufreq cooling device turns active to set CPU frequency low to
cool down the CPU.
+config DA9062_THERMAL
+ tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
+ depends on MFD_DA9062
+ depends on OF
+ help
+ Enable this for the Dialog Semiconductor thermal sensor driver.
+ This will report PMIC junction over-temperature for one thermal trip
+ zone.
+ Compatible with the DA9062 and DA9061 PMICs.
+
Re: [PATCH] net: phy: dp83867: Port mirroring support in the DP83867 TI's PHY driver
Hi Andrew, > On Wed, Feb 01, 2017 at 11:13:23PM +0100, Lukasz Majewski wrote: > > Hi Andrew, > > > > > > We would need a tri-state device tree properly: > > > > > > > > 1. Not defined - do nothing > > > > 2. Defined as 0 -> explicitly disable port mirroring > > > > 3. Defined as 1 -> explicitly enable port mirriring > > > > > > > > The "net-phy-lane-swap" only fulfills points 1 and 3 above. > > > > > > > > In my use case I do need point 2. > > > > > > Looking at the datasheet, PORT_MIRROR_EN defaults to 0. So it > > > seems reasonable to unconditionally set it to 0 when the PHY > > > driver loads. Any device which needs a value of 1 can set > > > "net-phy-lane-swap" > > > > Unconditionally setting this field to 0 (as we expect the reset > > default setting) seems to me like a good solution. > > > > However, I was not sure if such approach is acceptable by the > > community. > > So the issue here is, are there boards with bootloaders which set this > "lane swap" bit, The bootstrapping process in the PHY sets this bit. This is wrong since the board lane layout is not "swapped" The bootloader (u-boot) fixes this, since we need to support networking (tftp, ping). > and rely on Linux not changing it, When we boot Linux everything is OK, until the dp83867 driver comes into play and performs reset (including register reset). Then the "bootstrap", initial line swap is setup again (wrongly). So we need a way in Linux to make things correct again. > because the > hardware design has such a swap? > > It seems the bootloader you are using does this. The bootloader fixes things, but then in Linux the PHY driver (dp83867.c) performs "RESET" which breaks networking again. > But in your case, it > does it wrongly. The bootloader does its job correctly. > I'm guessing you have a vendor bootloader? And no > easy access to the sources? Mainline u-boot (all vendor code will be upstreamed). > Otherwise you would of fixed the > bootloader. So can we assume there are vendor designed boards which > require the swap? Do they run a mainline kernel? Or only the vendor > kernel? All stuff is going to run mainline kernel (LTS - v4.9 ?). > > If we know of mainline boards which are going to break, we should not > do this. > > If however we do decide to reset it to default value, i think it would > be good to implement net-phy-lane-swap as well, so giving people an > easier path towards mainline. I have thought a bit about that and I think that we should define complementary "net-phy-lane-no-swap" as suggested by Florian. Then affected boards could define it and use. > >Andrew Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Re: [PATCH 7/8] mq-deadline: add blk-mq adaptation of the deadline IO scheduler
> Il giorno 02 feb 2017, alle ore 06:19, Jens Axboe ha scritto:
>
> 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(&dd->lock);
>>> + ret = blk_mq_sched_try_merge(q, bio);
>>> + spin_unlock(&dd->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.
>
I'll try to learn from your solution, because, as of now, I don't see
how to avoid deferred work for the case where put_rq_private is
invoked in interrupt context. In fact, for this case, we cannot grab
the lock, unless we turn all spin_lock into spin_lock_irq*.
>> 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.
>
>
The scheme is clear. One comment, in case it could make sense and
avoid more complexity: since put_rq_priv is invoked in two different
contexts, process or interrupt, I didn't feel so confusing that, when
put_rq_priv is invoked in the context where the lock cannot be held
(unless one is willing to pay with irq disabling all the times), the
lock is not held, while, when invoked in the context where the lock
can be held, the lock is actually held, or must be taken.
Thanks,
Paolo
> 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);
> -
Re: [PATCH 3/5] Documentation: dt: iio: document stm32 exti trigger
On 02/01/2017 05:35 PM, Rob Herring wrote:
On Mon, Jan 30, 2017 at 02:57:41PM +0100, Fabrice Gasnier wrote:
Add dt documentation for st,stm32-exti-trigger.
EXTi gpio signal can be routed internally as trigger source for various
s/gpio/GPIO/
IPs (e.g. for ADC or DAC conversions).
Please use "dt-bindings: iio:" for the subject prefix.
Hi Rob,
I'll fix this in V2.
Signed-off-by: Fabrice Gasnier
---
.../bindings/iio/trigger/st,stm32-exti-trigger.txt | 17 +
1 file changed, 17 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/trigger/st,stm32-exti-trigger.txt
diff --git
a/Documentation/devicetree/bindings/iio/trigger/st,stm32-exti-trigger.txt
b/Documentation/devicetree/bindings/iio/trigger/st,stm32-exti-trigger.txt
new file mode 100644
index 000..ebf2645
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/trigger/st,stm32-exti-trigger.txt
@@ -0,0 +1,17 @@
+STMicroelectronics STM32 EXTI trigger bindings
+
+EXTi gpio signal can be routed internally as trigger source for various
s/gpio/GPIO/
+IPs (e.g. for ADC or DAC conversions).
+
+Contents of a stm32 exti trigger root node:
Drop "root"
I'll fix these in V2.
+---
+Required properties:
+- compatible: Should be "st,stm32-exti-trigger"
This whole binding looks a bit suspicious. Is this actually a h/w block?
What makes it stm32 specific? Seems like the gpio properties should just
be part of the ADC or DAC that they trigger.
Please let me explain in more details.
I think best is I add following documentation in binding. Something like:
GPIO + EXTI controller side | ADC side (input trigger MUX, same for DAC)
|
IIO trigger ---> IIO device
| __
| inX --| \
| ... --| SAR ADC |-->
__ | __ |__/
PA11 --| \ | TIMx --| \ trigger ^
PB11 --| | ... --| }--->'
... --| } EXTI11 -->--|__/
--| ||
PJ11 --|__/ |
In fact, this driver configures GPIO and EXTI controllers (left side of
above scheme), and it registers corresponding trigger in IIO. Then it
can be used by other IPs registered as IIO devices.
I think this should be outside of ADC or DAC IIO device drivers, to live
in separate IIO trigger driver. It will avoid duplicating code (e.g.
PATCH 4) into several IIO device drivers.
Is it ok to declare this as separate IIO trigger driver?
Maybe Jonathan could also advise on this ?
As I see it, this is stm32 specific, as any GPIO bank, (e.g. PA11,
PB11...) can be selected to generate (EXTI11) hardware trigger signal.
+- extiN-gpio: optional gpio line that may be used as external trigger source
-gpios is the preferred form.
I apologize, I didn't make it clear in the first place. Please let me
rephrase. Is bellow description more suitable ?
- extiN-gpio: One or several named GPIO lines that may be used as
external trigger source by STM32 ADC, DAC. N may be 0..15.
For example, on stm32f4, exti11-gpio can trig ADC, exti9-gpio can
trig DAC.
+ (e.g. N may be 0..15. For example, exti11-gpio can trig ADC on stm32f4).
+
+Example:
+ triggers {
+ compatible = "st,stm32-exti-trigger";
+ exti11-gpio=<&gpioa 11 0>;
spaces around the "=".
I'll fix it in V2, and also add example for more that one EXTI trigger:
triggers {
compatible = "st,stm32-exti-trigger";
exti9-gpio = <&gpioa 9 0>;
exti11-gpio = <&gpioa 11 0>;
...
};
Above binding can typically be used in board dt, in case on-board gpio
is connected/used as trigger source for IIO device (STM32 ADC/DAC).
Please let me know if this clarifies, so I'll do necessary changes in V2.
Many thanks for your review.
Best Regards,
Fabrice
+ };
--
1.9.1
Re: [PATCH/RFC] arm64: defconfig: Enlarge CMA alignment to 2 MiB
On Wed, Feb 01, 2017 at 02:06:45PM +, Robin Murphy wrote: > On 01/02/17 13:45, Magnus Damm wrote: > > Hi Geert, > > > > On Sat, Jan 28, 2017 at 1:03 AM, Geert Uytterhoeven > > wrote: > >> Some IOMMUs (e.g. Renesas IPMMU/VMSA) support only page sizes of 4 KiB, > >> 2 MiB, and 1 GiB. > >> > >> With the default setting of CONFIG_CMA_ALIGNMENT = 8, allocations larger > >> than 1 MiB are aligned to a 1 MiB boundary only. Hence a 2 MiB > >> allocation may not be aligned, leading to a mapping of 512 4 KiB pages. > >> > >> Increase CONFIG_CMA_ALIGNMENT to allow mapping a 2 MiB buffer using a > >> single PTE, decreasing memory usage and TLB pressure. > >> > >> Signed-off-by: Geert Uytterhoeven > >> --- > >> Is this useful? > >> > >> Should there instead be different defaults in Kconfig, depending on > >> enabled platform support? > > > > I think there is a dependency on the kernel page size configuration as > > well. In case of 16 KiB or 64 KiB page size configuration other large > > page sizes may be required. > > I don't see the original patch (linux-arm-kernel doesn't look to have it > archived either), but I think bumping the default up to 2MB to match our > normal section size sounds generally reasonable - users can still > override it manually in their config, right? For 16KB and 64KB granules, > it is at least the size covered by contiguous-hinted pages; the actual > section sizes there are far too big to be practical for alignment > purposes anyway (32MB and 512MB respectively). I am happy to take this patch on the strength of the above but an Ack or similar tag from Robin would be nice. Geert, perhaps you could repost the patch with Robin CCed?
[PATCH v4 2/8] ASoC: sun4i-i2s: Add quirks to handle a31 compatible
Some SoCs have a reset line that must be asserted/deasserted.
This patch adds a quirk to handle the new compatible
"allwinner,sun6i-a31-i2s" which will deassert the reset
line on probe function and assert it on remove's one.
This new compatible is useful in case of A33 codec driver, for example.
Signed-off-by: Mylène Josserand
Acked-by: Maxime Ripard
---
sound/soc/sunxi/sun4i-i2s.c | 57 +++--
1 file changed, 55 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 4237323ef594..3635bbc72cbc 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -14,9 +14,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
@@ -92,6 +94,7 @@ struct sun4i_i2s {
struct clk *bus_clk;
struct clk *mod_clk;
struct regmap *regmap;
+ struct reset_control *rst;
unsigned intmclk_freq;
@@ -651,9 +654,22 @@ static int sun4i_i2s_runtime_suspend(struct device *dev)
return 0;
}
+struct sun4i_i2s_quirks {
+ bool has_reset;
+};
+
+static const struct sun4i_i2s_quirks sun4i_a10_i2s_quirks = {
+ .has_reset = false,
+};
+
+static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
+ .has_reset = true,
+};
+
static int sun4i_i2s_probe(struct platform_device *pdev)
{
struct sun4i_i2s *i2s;
+ const struct sun4i_i2s_quirks *quirks;
struct resource *res;
void __iomem *regs;
int irq, ret;
@@ -674,6 +690,12 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
return irq;
}
+ quirks = of_device_get_match_data(&pdev->dev);
+ if (!quirks) {
+ dev_err(&pdev->dev, "Failed to determine the quirks to use\n");
+ return -ENODEV;
+ }
+
i2s->bus_clk = devm_clk_get(&pdev->dev, "apb");
if (IS_ERR(i2s->bus_clk)) {
dev_err(&pdev->dev, "Can't get our bus clock\n");
@@ -692,7 +714,24 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "Can't get our mod clock\n");
return PTR_ERR(i2s->mod_clk);
}
-
+
+ if (quirks->has_reset) {
+ i2s->rst = devm_reset_control_get(&pdev->dev, NULL);
+ if (IS_ERR(i2s->rst)) {
+ dev_err(&pdev->dev, "Failed to get reset control\n");
+ return PTR_ERR(i2s->rst);
+ }
+ }
+
+ if (!IS_ERR(i2s->rst)) {
+ ret = reset_control_deassert(i2s->rst);
+ if (ret) {
+ dev_err(&pdev->dev,
+ "Failed to deassert the reset control\n");
+ return -EINVAL;
+ }
+ }
+
i2s->playback_dma_data.addr = res->start + SUN4I_I2S_FIFO_TX_REG;
i2s->playback_dma_data.maxburst = 8;
@@ -727,23 +766,37 @@ static int sun4i_i2s_probe(struct platform_device *pdev)
sun4i_i2s_runtime_suspend(&pdev->dev);
err_pm_disable:
pm_runtime_disable(&pdev->dev);
+ if (!IS_ERR(i2s->rst))
+ reset_control_assert(i2s->rst);
return ret;
}
static int sun4i_i2s_remove(struct platform_device *pdev)
{
+ struct sun4i_i2s *i2s = dev_get_drvdata(&pdev->dev);
+
snd_dmaengine_pcm_unregister(&pdev->dev);
pm_runtime_disable(&pdev->dev);
if (!pm_runtime_status_suspended(&pdev->dev))
sun4i_i2s_runtime_suspend(&pdev->dev);
+ if (!IS_ERR(i2s->rst))
+ reset_control_assert(i2s->rst);
+
return 0;
}
static const struct of_device_id sun4i_i2s_match[] = {
- { .compatible = "allwinner,sun4i-a10-i2s", },
+ {
+ .compatible = "allwinner,sun4i-a10-i2s",
+ .data = &sun4i_a10_i2s_quirks,
+ },
+ {
+ .compatible = "allwinner,sun6i-a31-i2s",
+ .data = &sun6i_a31_i2s_quirks,
+ },
{}
};
MODULE_DEVICE_TABLE(of, sun4i_i2s_match);
--
2.11.0
[PATCH v4 6/8] ARM: dts: sun8i: Add audio codec, dai and card for A33
Add the audio codec, dai and a simple card to be able to use the
audio stream of the builtin codec on sun8i SoC.
This commit adds also an audio-routing for the sound card node to link
the analog DAPM widgets (Right/Left DAC) and the digital one's as they
are created in different drivers.
Signed-off-by: Mylène Josserand
---
arch/arm/boot/dts/sun8i-a33.dtsi | 45
1 file changed, 45 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
index fd1e1cddd4a8..4e34ec6613a0 100644
--- a/arch/arm/boot/dts/sun8i-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a33.dtsi
@@ -69,6 +69,28 @@
reg = <0x4000 0x8000>;
};
+ sound: sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "sun8i-a33-audio";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&link_codec>;
+ simple-audio-card,bitclock-master = <&link_codec>;
+ simple-audio-card,mclk-fs = <512>;
+ simple-audio-card,aux-devs = <&codec_analog>;
+ simple-audio-card,routing =
+ "Left DAC", "Digital Left DAC",
+ "Right DAC", "Digital Right DAC";
+ status = "disabled";
+
+ simple-audio-card,cpu {
+ sound-dai = <&dai>;
+ };
+
+ link_codec: simple-audio-card,codec {
+ sound-dai = <&codec>;
+ };
+ };
+
soc@01c0 {
tcon0: lcd-controller@01c0c000 {
compatible = "allwinner,sun8i-a33-tcon";
@@ -116,6 +138,29 @@
reset-names = "ahb";
};
+ dai: dai@01c22c00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun6i-a31-i2s";
+ reg = <0x01c22c00 0x200>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
+ clock-names = "apb", "mod";
+ resets = <&ccu RST_BUS_CODEC>;
+ dmas = <&dma 15>, <&dma 15>;
+ dma-names = "rx", "tx";
+ status = "disabled";
+ };
+
+ codec: codec@01c22e00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a33-codec";
+ reg = <0x01c22e00 0x400>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
+ clock-names = "bus", "mod";
+ status = "disabled";
+ };
+
fe0: display-frontend@01e0 {
compatible = "allwinner,sun8i-a33-display-frontend";
reg = <0x01e0 0x2>;
--
2.11.0
[PATCH v4 0/8] Add sun8i A33 audio driver
Hello everyone,
This a V4 of my Allwinner A33 (sun8i) audio codec driver.
Tested on "for-next" branch of ASoC repository with some patches
to apply before this series:
https://patchwork.kernel.org/patch/9447631/
https://patchwork.kernel.org/patch/9423999/
and one of my previous patch (from V2):
https://patchwork.kernel.org/patch/9521121/
Changes since V3:
- Rebased my patches under Mark Brown's repo on "for-next" branch.
- Removed the .owner from sun8i-codec driver, reported by KBuild robot
- Updated patch 05/08 according to Rob Herring's review.
Changes since V2:
- Removed patches from v2 already merged:
commit ebad64d193779 ("ASoC: sun4i-i2s: Increase DMA max burst to 8")
commit 603a0c8af9cb2 ("clk: sunxi-ng: a33: Add CLK_SET_RATE_PARENT to
ac-dig")
- Removed "reset-names" from sun4i-i2s driver
- Fixed the build warning from sun8i-codec
- Fixed some various topics such as subject line
for dt bindings patch, renamed the simple-card
and disabled the simple-card.
Changes since V1:
- Remove the analog codec driver as a better version has been
committed by Chen-Yu Tsai and is already merged.
- Remove the audio-card as simple-card can be used
- The DMA maxburst is set to 8 in the sun4i-i2s instead of
adding the maxburst of 4 in Sun6i dma engine.
- Create a new compatible for sun4i-i2s to handle the reset
line.
- Fix various problems in sun8i-codec driver according to V1's
reviews
- Add the pm_runtime hooks in sun8i-codec driver to prepare/
unprepare clocks.
- Update the DTS according to Chen-Yu's analog codec driver.
- Rename sun8i-codec's clocks to "bus" and "mod"
- The first "delay" issue from V1 is fixed by using a delay
when enabling the headphone amplifier to let the amplifier
being up.
Patches 1 and 2 add a new compatible "allwinner,sun6i-a31-i2s"
to handle the reset line for sun4i-i2s driver. It uses a quirk to
use a version with or without reset lines.
Patch 3 adds the sun8i codec driver which represents the digital part
of the A33 codec. It supports only playback features.
Path 4 fixes the previous issue of a "first time delay" in V1 (see cover
letter). Do not hesitate if you have comments on this patch.
Patches 5 adds the dt-bindings documentation for new audio driver
added in this serie (sun8i-codec).
Patch 6 adds the cpu DAI, codec and audio nodes to sun8i-a33 device tree.
Patches 7 and 8 enable the audio on Parrot and Sinlinx's boards.
The DAI for this A33 codec is the same than for A20: "sun4i-i2s".
Currently, the sun8i-a33 codec driver handles only the playback feature.
The other ones (such as capture) and all other interfaces except
headphone are not supported. I will send a patch to handle the
capture with microphones in next few weeks.
Examples of amixer commands:
amixer set 'Headphone' 75%
amixer set 'Headphone' on
amixer set 'DAC' on
amixer set 'Right DAC Mixer RSlot 0' on
amixer set 'Left DAC Mixer LSlot 0' on
It was tested on Parrot and Sinlinx boards.
Let me know if you have any comments on this serie.
Thank you in advance,
Best regards,
Mylène Josserand (8):
ASoC: sun4i-i2s: Update binding documentation to include A31
ASoC: sun4i-i2s: Add quirks to handle a31 compatible
ASoC: Add sun8i digital audio codec
ASoC: sun8i-codec-analog: Add amplifier event to fix first delay
ASoC: codecs: Add sun8i-a33 binding documentation
ARM: dts: sun8i: Add audio codec, dai and card for A33
ARM: dts: sun8i: parrot: Enable audio nodes
ARM: dts: sun8i: sinlinx: Enable audio nodes
.../devicetree/bindings/sound/sun4i-i2s.txt| 5 +
.../devicetree/bindings/sound/sun8i-a33-codec.txt | 63 +++
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 12 +
arch/arm/boot/dts/sun8i-a33.dtsi | 45 ++
arch/arm/boot/dts/sun8i-r16-parrot.dts | 12 +
sound/soc/sunxi/Kconfig| 11 +
sound/soc/sunxi/Makefile | 1 +
sound/soc/sunxi/sun4i-i2s.c| 57 ++-
sound/soc/sunxi/sun8i-codec-analog.c | 30 +-
sound/soc/sunxi/sun8i-codec.c | 498 +
10 files changed, 730 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
create mode 100644 sound/soc/sunxi/sun8i-codec.c
--
2.11.0
[PATCH v4 4/8] ASoC: sun8i-codec-analog: Add amplifier event to fix first delay
When playing a sound for the first time, a short delay, where the audio
file is not played, can be noticed.
On a second play (right after), the sound is played correctly.
If we wait a short time (~5 sec which corresponds to the aplay
timeout), the delay is back.
This patch fixes it by using an event on headphone amplifier.
It allows to keep the amplifier enable while playing a sound.
A delay of 700ms allows to wait that the amplifier is powered-up
before playing the sound.
Signed-off-by: Mylène Josserand
Acked-by: Maxime Ripard
---
sound/soc/sunxi/sun8i-codec-analog.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/sound/soc/sunxi/sun8i-codec-analog.c
b/sound/soc/sunxi/sun8i-codec-analog.c
index af02290ebe49..72331332b72e 100644
--- a/sound/soc/sunxi/sun8i-codec-analog.c
+++ b/sound/soc/sunxi/sun8i-codec-analog.c
@@ -398,11 +398,37 @@ static const struct snd_kcontrol_new sun8i_codec_hp_src[]
= {
sun8i_codec_hp_src_enum),
};
+static int sun8i_headphone_amp_event(struct snd_soc_dapm_widget *w,
+struct snd_kcontrol *k, int event)
+{
+ struct snd_soc_component *component =
snd_soc_dapm_to_component(w->dapm);
+
+ if (SND_SOC_DAPM_EVENT_ON(event)) {
+ snd_soc_component_update_bits(component,
SUN8I_ADDA_PAEN_HP_CTRL,
+
BIT(SUN8I_ADDA_PAEN_HP_CTRL_HPPAEN),
+
BIT(SUN8I_ADDA_PAEN_HP_CTRL_HPPAEN));
+ /*
+* Need a delay to have the amplifier up. 700ms seems the best
+* compromise between the time to let the amplifier up and the
+* time not to feel this delay while playing a sound.
+*/
+ msleep(700);
+ } else if (SND_SOC_DAPM_EVENT_OFF(event)) {
+ snd_soc_component_update_bits(component,
SUN8I_ADDA_PAEN_HP_CTRL,
+
BIT(SUN8I_ADDA_PAEN_HP_CTRL_HPPAEN),
+ 0x0);
+ }
+
+ return 0;
+}
+
static const struct snd_soc_dapm_widget sun8i_codec_headphone_widgets[] = {
SND_SOC_DAPM_MUX("Headphone Source Playback Route",
SND_SOC_NOPM, 0, 0, sun8i_codec_hp_src),
- SND_SOC_DAPM_OUT_DRV("Headphone Amp", SUN8I_ADDA_PAEN_HP_CTRL,
-SUN8I_ADDA_PAEN_HP_CTRL_HPPAEN, 0, NULL, 0),
+ SND_SOC_DAPM_OUT_DRV_E("Headphone Amp", SUN8I_ADDA_PAEN_HP_CTRL,
+ SUN8I_ADDA_PAEN_HP_CTRL_HPPAEN, 0, NULL, 0,
+ sun8i_headphone_amp_event,
+ SND_SOC_DAPM_PRE_PMU | SND_SOC_DAPM_PRE_PMD),
SND_SOC_DAPM_SUPPLY("HPCOM Protection", SUN8I_ADDA_PAEN_HP_CTRL,
SUN8I_ADDA_PAEN_HP_CTRL_COMPTEN, 0, NULL, 0),
SND_SOC_DAPM_REG(snd_soc_dapm_supply, "HPCOM", SUN8I_ADDA_PAEN_HP_CTRL,
--
2.11.0
[PATCH v4 8/8] ARM: dts: sun8i: sinlinx: Enable audio nodes
Enable the audio codec and the audio dai for the sun8i A33 sinlinx board.
Signed-off-by: Mylène Josserand
---
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 71bb9418c5f9..53a3bb23b35c 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -63,6 +63,14 @@
};
};
+&codec {
+ status = "okay";
+};
+
+&dai {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -207,6 +215,10 @@
regulator-name = "vcc-rtc";
};
+&sound {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_b>;
--
2.11.0
[PATCH v4 3/8] ASoC: Add sun8i digital audio codec
Add the sun8i audio codec which handles the digital register of A33 codec. The driver handles only the basic playback from the DAC to headphones. All other features (microphone, capture, etc) will be added later. Signed-off-by: Mylène Josserand Acked-by: Maxime Ripard --- sound/soc/sunxi/Kconfig | 11 + sound/soc/sunxi/Makefile | 1 + sound/soc/sunxi/sun8i-codec.c | 498 ++ 3 files changed, 510 insertions(+) create mode 100644 sound/soc/sunxi/sun8i-codec.c diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig index 6c344e16aca4..13a8267f17c7 100644 --- a/sound/soc/sunxi/Kconfig +++ b/sound/soc/sunxi/Kconfig @@ -9,6 +9,17 @@ config SND_SUN4I_CODEC Select Y or M to add support for the Codec embedded in the Allwinner A10 and affiliated SoCs. +config SND_SUN8I_CODEC + tristate "Allwinner SUN8I audio codec" + depends on OF + depends on MACH_SUN8I || COMPILE_TEST + select REGMAP_MMIO + help + This option enables the digital part of the internal audio codec for + Allwinner sun8i SoC (and particularly A33). + + Say Y or M if you want to add sun8i digital audio codec support. + config SND_SUN8I_CODEC_ANALOG tristate "Allwinner sun8i Codec Analog Controls Support" depends on MACH_SUN8I || COMPILE_TEST diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile index 241c0df9ca0c..1f1af6271731 100644 --- a/sound/soc/sunxi/Makefile +++ b/sound/soc/sunxi/Makefile @@ -2,3 +2,4 @@ obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o obj-$(CONFIG_SND_SUN4I_I2S) += sun4i-i2s.o obj-$(CONFIG_SND_SUN4I_SPDIF) += sun4i-spdif.o obj-$(CONFIG_SND_SUN8I_CODEC_ANALOG) += sun8i-codec-analog.o +obj-$(CONFIG_SND_SUN8I_CODEC) += sun8i-codec.o diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c new file mode 100644 index ..b92bdc8361af --- /dev/null +++ b/sound/soc/sunxi/sun8i-codec.c @@ -0,0 +1,498 @@ +/* + * This driver supports the digital controls for the internal codec + * found in Allwinner's A33 SoCs. + * + * (C) Copyright 2010-2016 + * Reuuimlla Technology Co., Ltd. + * huangxin + * Mylène Josserand + * + * This program 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 program 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. + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#define SUN8I_SYSCLK_CTL 0x00c +#define SUN8I_SYSCLK_CTL_AIF1CLK_ENA 11 +#define SUN8I_SYSCLK_CTL_AIF1CLK_SRC_PLL 9 +#define SUN8I_SYSCLK_CTL_AIF1CLK_SRC 8 +#define SUN8I_SYSCLK_CTL_SYSCLK_ENA3 +#define SUN8I_SYSCLK_CTL_SYSCLK_SRC0 +#define SUN8I_MOD_CLK_ENA 0x010 +#define SUN8I_MOD_CLK_ENA_AIF1 15 +#define SUN8I_MOD_CLK_ENA_DAC 2 +#define SUN8I_MOD_RST_CTL 0x014 +#define SUN8I_MOD_RST_CTL_AIF1 15 +#define SUN8I_MOD_RST_CTL_DAC 2 +#define SUN8I_SYS_SR_CTRL 0x018 +#define SUN8I_SYS_SR_CTRL_AIF1_FS 12 +#define SUN8I_SYS_SR_CTRL_AIF2_FS 8 +#define SUN8I_AIF1CLK_CTRL 0x040 +#define SUN8I_AIF1CLK_CTRL_AIF1_MSTR_MOD 15 +#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV 14 +#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV 13 +#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV 9 +#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV 6 +#define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_16(1 << 6) +#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ 4 +#define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16(1 << 4) +#define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT 2 +#define SUN8I_AIF1_DACDAT_CTRL 0x048 +#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA 15 +#define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA 14 +#define SUN8I_DAC_DIG_CTRL 0x120 +#define SUN8I_DAC_DIG_CTRL_ENDA15 +#define SUN8I_DAC_MXR_SRC 0x130 +#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA0L15 +#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF1DA1L14 +#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_AIF2DACL13 +#define SUN8I_DAC_MXR_SRC_DACL_MXR_SRC_ADCL12 +#define SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_AIF1DA0R11 +#define SUN
[PATCH v4 5/8] ASoC: codecs: Add sun8i-a33 binding documentation
Add the documentation for dt-binding of the digital audio codec driver
and the audio card driver for Sun8i-a33 SoCs.
Signed-off-by: Mylène Josserand
Acked-by: Maxime Ripard
---
.../devicetree/bindings/sound/sun8i-a33-codec.txt | 63 ++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
diff --git a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
b/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
new file mode 100644
index ..399b1b4bae22
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt
@@ -0,0 +1,63 @@
+Allwinner SUN8I audio codec
+
+
+On Sun8i-A33 SoCs, the audio is separated in different parts:
+ - A DAI driver. It uses the "sun4i-i2s" driver which is
+ documented here:
+ Documentation/devicetree/bindings/sound/sun4i-i2s.txt
+ - An analog part of the codec which is handled as PRCM registers.
+ See Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
+ - An digital part of the codec which is documented in this current
+ binding documentation.
+ - And finally, an audio card which links all the above components.
+ The simple-audio card will be used.
+ See Documentation/devicetree/bindings/sound/simple-card.txt
+
+This bindings documentation exposes Sun8i codec (digital part).
+
+Required properties:
+- compatible: must be "allwinner,sun8i-a33-codec"
+- reg: must contain the registers location and length
+- interrupts: must contain the codec interrupt
+- clocks: a list of phandle + clock-specifer pairs, one for each entry
+ in clock-names.
+- clock-names: should contain followings:
+ - "bus": the parent APB clock for this controller
+ - "mod": the parent module clock
+
+Here is an example to add a sound card and the codec binding on sun8i SoCs that
+are similar to A33 using simple-card:
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "sun8i-a33-audio";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&link_codec>;
+ simple-audio-card,bitclock-master = <&link_codec>;
+ simple-audio-card,mclk-fs = <512>;
+ simple-audio-card,aux-devs = <&codec_analog>;
+ simple-audio-card,routing =
+ "Left DAC", "Digital Left DAC",
+ "Right DAC", "Digital Right DAC";
+
+ simple-audio-card,cpu {
+ sound-dai = <&dai>;
+ };
+
+ link_codec: simple-audio-card,codec {
+ sound-dai = <&codec>;
+ };
+
+ soc@01c0 {
+ [...]
+
+ audio-codec@1c22e00 {
+ #sound-dai-cells = <0>;
+ compatible = "allwinner,sun8i-a33-codec";
+ reg = <0x01c22e00 0x400>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>;
+ clock-names = "bus", "mod";
+ };
+ };
+
--
2.11.0
Re: [PATCH] modules: mark __inittest/__exittest as __maybe_unused
Arnd Bergmann writes:
> clang warns about unused inline functions by default:
>
> arch/arm/crypto/aes-cipher-glue.c:68:1: warning: unused function '__inittest'
> [-Wunused-function]
> arch/arm/crypto/aes-cipher-glue.c:69:1: warning: unused function '__exittest'
> [-Wunused-function]
>
> As these appear in every single module, let's just disable the warnings by
> marking the
> two functions as __maybe_unused.
Um, won't you have to do that to hundreds of kernel headers? Why
module.h?
Confused,
Rusty.
> Signed-off-by: Arnd Bergmann
> ---
> include/linux/module.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/module.h b/include/linux/module.h
> index 38b4b2c754c8..48a5c57c858e 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -126,13 +126,13 @@ extern void cleanup_module(void);
>
> /* Each module must use one module_init(). */
> #define module_init(initfn) \
> - static inline initcall_t __inittest(void) \
> + static inline initcall_t __maybe_unused __inittest(void)
> \
> { return initfn; } \
> int init_module(void) __attribute__((alias(#initfn)));
>
> /* This is only required if you want to be unloadable. */
> #define module_exit(exitfn) \
> - static inline exitcall_t __exittest(void) \
> + static inline exitcall_t __maybe_unused __exittest(void)
> \
> { return exitfn; } \
> void cleanup_module(void) __attribute__((alias(#exitfn)));
>
> --
> 2.9.0
[PATCH v4 7/8] ARM: dts: sun8i: parrot: Enable audio nodes
Enable the audio codec and the audio dai for the sun8i R16 Parrot board.
Signed-off-by: Mylène Josserand
---
arch/arm/boot/dts/sun8i-r16-parrot.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-r16-parrot.dts
b/arch/arm/boot/dts/sun8i-r16-parrot.dts
index 47553e522982..f3dc413e8624 100644
--- a/arch/arm/boot/dts/sun8i-r16-parrot.dts
+++ b/arch/arm/boot/dts/sun8i-r16-parrot.dts
@@ -84,6 +84,14 @@
};
+&codec {
+ status = "okay";
+};
+
+&dai {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
@@ -325,6 +333,10 @@
status = "okay";
};
+&sound {
+ status = "okay";
+};
+
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_b>;
--
2.11.0
[PATCH v4 1/8] ASoC: sun4i-i2s: Update binding documentation to include A31
Add a new compatible for sun4i-i2s driver to handle some
SoCs that have a reset line that must be asserted/deasserted.
This new compatible, "allwinner,sun6i-a31-i2s", requires the
property "resets" which should be a phandle to the reset line.
Except these differences, the compatible is identical to previous one
which will not handle a reset line.
Signed-off-by: Mylène Josserand
Acked-by: Maxime Ripard
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/sound/sun4i-i2s.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
index 7b526ec64991..f4adc58f82ba 100644
--- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt
@@ -7,6 +7,7 @@ Required properties:
- compatible: should be one of the followings
- "allwinner,sun4i-a10-i2s"
+ - "allwinner,sun6i-a31-i2s"
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: should contain the I2S interrupt.
@@ -19,6 +20,10 @@ Required properties:
- "mod" : module clock for the I2S controller
- #sound-dai-cells : Must be equal to 0
+Required properties for the following compatibles:
+ - "allwinner,sun6i-a31-i2s"
+- resets: phandle to the reset line for this codec
+
Example:
i2s0: i2s@01c22400 {
--
2.11.0
Re: [PATCH] drm/amdgpu: shut up #warning for compile testing
Am 02.02.2017 um 07:09 schrieb Michel Dänzer: [SNIP] 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. And exactly for this reason I would rather like to keep the warning. Regards, Christian.
Re: [PATCH] mtd: spi-nor: cqspi: remove redundant dead code on error return check
Le 31/01/2017 à 16:53, Colin King a écrit : > From: Colin Ian King > > Checking for ret < 0 is redundant because a previous check on ret > being non-zero already handles the ret < 0 case. Remove the redundant > code. Found by CoverityScan, CID#1398863, CID#1398864 > > Signed-off-by: Colin Ian King Applied to the github spi-nor tree. Thanks! > --- > drivers/mtd/spi-nor/cadence-quadspi.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c > b/drivers/mtd/spi-nor/cadence-quadspi.c > index 3fb7be8..9f8102d 100644 > --- a/drivers/mtd/spi-nor/cadence-quadspi.c > +++ b/drivers/mtd/spi-nor/cadence-quadspi.c > @@ -893,7 +893,7 @@ static ssize_t cqspi_write(struct spi_nor *nor, loff_t to, > if (ret) > return ret; > > - return (ret < 0) ? ret : len; > + return len; > } > > static ssize_t cqspi_read(struct spi_nor *nor, loff_t from, > @@ -913,7 +913,7 @@ static ssize_t cqspi_read(struct spi_nor *nor, loff_t > from, > if (ret) > return ret; > > - return (ret < 0) ? ret : len; > + return len; > } > > static int cqspi_erase(struct spi_nor *nor, loff_t offs) >
[PATCH] drm/i915: fix i915 running as dom0 under Xen
Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
disposable private objects") introduced a regression for the kernel
running as Xen dom0: when switching to graphics mode a GPU HANG
occurred.
Reason seems to be a missing adaption similar to that done in
commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
to i915_gem_object_get_pages_internal().
So limit the maximum page order to be used according to the maximum
swiotlb segment size instead to the complete swiotlb size.
Signed-off-by: Juergen Gross
---
Please consider for 4.10 as otherwise 4.10 will be unusable as Xen dom0
with i915 graphics.
---
drivers/gpu/drm/i915/i915_gem_internal.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c
b/drivers/gpu/drm/i915/i915_gem_internal.c
index 4b3ff3e..d09c749 100644
--- a/drivers/gpu/drm/i915/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/i915_gem_internal.c
@@ -66,8 +66,16 @@ i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
max_order = MAX_ORDER;
#ifdef CONFIG_SWIOTLB
- if (swiotlb_nr_tbl()) /* minimum max swiotlb size is IO_TLB_SEGSIZE */
- max_order = min(max_order, ilog2(IO_TLB_SEGPAGES));
+ if (swiotlb_nr_tbl()) {
+ unsigned int max_segment;
+
+ max_segment = swiotlb_max_segment();
+ if (max_segment) {
+ max_segment = max_t(unsigned int, max_segment,
+ PAGE_SIZE) >> PAGE_SHIFT;
+ max_order = min(max_order, ilog2(max_segment));
+ }
+ }
#endif
gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
--
2.10.2
Re: [PATCH 1/2] net: ethernet: bgmac: init sequence bug
Hello!
On 2/2/2017 1:39 AM, Jon Mason wrote:
From: Zac Schroff
Fix a bug in the 'bgmac' driver init sequence that blind writes for init
sequence where it should preserve most bits other than the ones it is
deliberately manipulating.
Signed-off-by: Zac Schroff
Signed-off-by: Jon Mason
Fixes: f6a95a24957 ("net: ethernet: bgmac: Add platform device support")
---
drivers/net/ethernet/broadcom/bgmac-platform.c | 10 +++---
include/linux/bcma/bcma_regs.h | 1 +
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac-platform.c
b/drivers/net/ethernet/broadcom/bgmac-platform.c
index 6f736c1..9bbe05c 100644
--- a/drivers/net/ethernet/broadcom/bgmac-platform.c
+++ b/drivers/net/ethernet/broadcom/bgmac-platform.c
@@ -61,15 +61,19 @@ static bool platform_bgmac_clk_enabled(struct bgmac *bgmac)
static void platform_bgmac_clk_enable(struct bgmac *bgmac, u32 flags)
{
- bgmac_idm_write(bgmac, BCMA_IOCTL,
- (BCMA_IOCTL_CLK | BCMA_IOCTL_FGC | flags));
+ u32 regval;
+
+ /* Some bits of BCMA_IOCTL set by HW/ATF & should not change */
+ regval = bgmac_idm_read(bgmac, BCMA_IOCTL) & BCMA_IOCTL_DO_NOT_MODIFY;
+ regval |= ((flags & (~BCMA_IOCTL_DO_NOT_MODIFY)) | BCMA_IOCTL_CLK);
The innermost parens aren't necessary. And the outermost as well.
[...]
MBR, Sergei
[PATCH 1/2] drm: meson: rename module name to meson-drm
The module is currently names "meson.ko" which can lead to some confusion, this patches renames it "meson-drm.ko" Signed-off-by: Neil Armstrong --- drivers/gpu/drm/meson/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/meson/Makefile b/drivers/gpu/drm/meson/Makefile index 2591978..92cf845 100644 --- a/drivers/gpu/drm/meson/Makefile +++ b/drivers/gpu/drm/meson/Makefile @@ -1,4 +1,4 @@ -meson-y := meson_drv.o meson_plane.o meson_crtc.o meson_venc_cvbs.o -meson-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o meson_canvas.o +meson-drm-y := meson_drv.o meson_plane.o meson_crtc.o meson_venc_cvbs.o +meson-drm-y += meson_viu.o meson_vpp.o meson_venc.o meson_vclk.o meson_canvas.o -obj-$(CONFIG_DRM_MESON) += meson.o +obj-$(CONFIG_DRM_MESON) += meson-drm.o -- 1.9.1
[PATCH 2/2] drm: meson: rename driver name to meson-drm
The platform driver name is currently "meson" which can lead to some
confusion, this patch renames it to "meson-drm" and removes the owner
attribute.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_drv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index ff1f601..380bde7 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -329,8 +329,7 @@ static int meson_drv_remove(struct platform_device *pdev)
.probe = meson_drv_probe,
.remove = meson_drv_remove,
.driver = {
- .owner = THIS_MODULE,
- .name = DRIVER_NAME,
+ .name = "meson-drm",
.of_match_table = dt_match,
},
};
--
1.9.1
[PATCH 0/2] drm: meson: Fixup driver and module name
This patchset is a simple fixup to rename the confusion possible module and driver name "meson" to a more explicit "meson-drm" name. Neil Armstrong (2): drm: meson: rename module name to meson-drm drm: meson: rename driver name to meson-drm drivers/gpu/drm/meson/Makefile| 6 +++--- drivers/gpu/drm/meson/meson_drv.c | 3 +-- 2 files changed, 4 insertions(+), 5 deletions(-) -- 1.9.1
Re: [PATCH 2/2] net: ethernet: bgmac: mac address change bug
On 2/2/2017 1:39 AM, Jon Mason wrote:
From: Hari Vyas
ndo_set_mac_address() passes struct sockaddr * as 2nd parameter to
bgmac_set_mac_address() but code assumed u8 *. This caused two bytes
chopping and the wrong mac address was configured.
Signed-off-by: Hari Vyas
Signed-off-by: Jon Mason
Fixes: 4e209001b86 ("bgmac: write mac address to hardware in
ndo_set_mac_address")
---
drivers/net/ethernet/broadcom/bgmac.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c
b/drivers/net/ethernet/broadcom/bgmac.c
index 0e066dc6..ea24072 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -1222,11 +1222,15 @@ static int bgmac_set_mac_address(struct net_device
*net_dev, void *addr)
{
struct bgmac *bgmac = netdev_priv(net_dev);
int ret;
+ struct sockaddr *sa = addr;
DaveM prefers the declarations to be arranged from longest to shortest.
[...]
MBR, Sergei
Re: [PATCH] vfio: Fix build break when SPAPR_TCE_IOMMU=n
Michael Ellerman writes: > Currently the kconfig logic for VFIO_IOMMU_SPAPR_TCE and VFIO_SPAPR_EEH > is broken when SPAPR_TCE_IOMMU=n. Leading to: > > warning: (VFIO) selects VFIO_IOMMU_SPAPR_TCE which has unmet direct > dependencies (VFIO && SPAPR_TCE_IOMMU) > warning: (VFIO) selects VFIO_IOMMU_SPAPR_TCE which has unmet direct > dependencies (VFIO && SPAPR_TCE_IOMMU) > drivers/vfio/vfio_iommu_spapr_tce.c:113:8: error: implicit declaration of > function 'mm_iommu_find' > > This stems from the fact that VFIO selects VFIO_IOMMU_SPAPR_TCE, and > although it has an if clause, the condition is not correct. > > We could fix it by doing select VFIO_IOMMU_SPAPR_TCE if SPAPR_TCE_IOMMU, > but the cleaner fix is to drop the selects and tie VFIO_IOMMU_SPAPR_TCE > to the value of VFIO, and express the dependencies in only once place. > > Do the same for VFIO_SPAPR_EEH. > > The end result is that the values of VFIO_IOMMU_SPAPR_TCE and > VFIO_SPAPR_EEH follow the value of VFIO, except when SPAPR_TCE_IOMMU=n > and/or EEH=n. Which is exactly what we want to happen. Ping? There was a bit of discussion on this patch but I think we decided it was correct in the end. cheers
Re: [RESENT PATCH] ARM: bcm2835: Add devicetree for the Raspberry Pi 3, for arm (32)
Am 02.02.2017 um 09:37 schrieb Michael Zoran: This is actually a problem I had to deal with way in the begging of ARM64. What was done in the github tree was to have the one of the DTS files(in this case 64) #include the 32 bit dts. That way it's not needed to have the symbolic link and install should work. I know it's ulgy, but it works... Take a look at: https://github.com/raspberrypi/linux/blob/rpi-4.10.y/arch/arm64/boot/dt s/broadcom/bcm2710-rpi-3-b.dts Here is what the file contains: #define RPI364 #include "../../../../arm/boot/dts/bcm2710-rpi-3-b.dts" This do not work in the context of the split device-tree repository [0] (where the directory structure differs). [0] https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/
Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call
On Wed, Jan 25, 2017 at 08:32:03AM -0500, Jeff Layton wrote:
> Small respin of the patch that I sent yesterday for the same thing.
>
> This moves the maxsize handling into iov_iter_pvec_size, so that we don't
> end up iterating past the max size we'll use anyway when trying to
> determine the pagevec length.
>
> Also, a respun patch to make ceph use iov_iter_get_pages_alloc instead of
> trying to do it via its own routine.
>
> Al, if these look ok, do you want to pick these up or shall I ask
> Ilya to merge them via the ceph tree?
I'd rather have that kind of work go through the vfs tree; said that,
I really wonder if this is the right approach. Most of the users of
iov_iter_get_pages()/iov_iter_get_pages_alloc() look like they want
something like
iov_iter_for_each_page(iter, size, f, data)
with int (*f)(struct page *page, size_t from, size_t size, void *data)
passed as callback. Not everything fits that model, but there's a whole
lot of things that do.
Examples:
* fs/direct_io.c:do_direct_IO(). We loop through the pages
returned by dio_get_page(). For each of those we find the subrange
of page (from/to) and handle IO on that range. Then we drop the reference
to page and move on to the next one. dio_get_page() uses dio->pages and
sdio->{head,tail,from,to} to avoid calling iov_iter_get_pages() on each
page - iov_iter_get_pages() is called for bigger chunks (up to 64 pages,
AFAICS) and results are kept in dio->pages for subsequent calls of
dio_get_page(). Unconsumed references are dropped by dio_cleanup();
AFAICS, it could've been called unconditionally right after the call
of do_direct_IO() (or from it, for that matter) - all remaining references
to pages are never looked at after do_direct_IO(). As it is, we call
it immediately on failure return from do_direct_IO() and then unconditionally
after blk_finish_plug().
That oddity aside (and AFAICS it's really pointless - all pages
we'd done something with in do_direct_IO() won't be affected by
dio_cleanup()), there's potentially more interesting issue. If
iov_iter_get_pages() fails on write at the moment when we have pending
mapped blocks, we treat that as write from zero page. Once that has
happened, we remember to stop mapping new blocks and arrange for having
the error eventually treated as if it had come from IO failure. I'm not
sure if this sucker handles all cases correctly, BTW - can we end up with
a few pages worth of pending mapped blocks?
But aside of that, it's really a "loop through all page subranges"
kind of code. The inner loop in do_direct_IO() could be converted into
a callback quite easily
* nfs_direct_read_schedule_iovec(): same kind of batching, only there
we have an outer loop calling iov_iter_get_pages_alloc() and then the
inner loop goes through the page subranges, with the same work done for
each. In this case we grab a reference inside the would-be callback and
drop all references from iov_iter_get_pages_alloc() after the inner loop
is done. Could've gotten rid of grabbing extra refs - that would mean dropping
only the unused ones if the 'callback' (== inner loop body) has told us
to bugger off early. IMO that would be a better model. Incidentally, we
keep allocating/freeing the array used to store page references for each batch.
* nfs_direct_write_schedule_iovec(): very similar to the read side.
* zerocopy_sg_from_iter(): similar loop, batch size is MAX_SKB_FRAGS
(i.e. 16 or 17, depending upon the PAGE_SIZE; unless somebody has done
a port with 2Kb pages it shouldn't be greater than 17). Array of references
is on stack, skb_fill_page_desc(skb, frag++, page, from, size) should
become the callback. References are consumed by it and it can't fail, so
there's nothing left to drop.
* af_alg_make_sg(). Looks like it might be massaged to the same
model; the tricky part is af_alg_free_sg() users. We keep references to
pages in sgl->pages[] *and* store them in sgl->sg[...] (via sg_set_page()).
af_alg_free_sg() drops them using ->pages[] instead of sg_page(...->sg + ...).
Might or might not be a problem - I'm not familiar with that code.
* fuse_get_user_pages(). It pretty much fills an equivalent of
bio_vec array; the difference is, array of struct page * and arrays of
(start, len) pairs are kept separately. The only benefit is using the
first array as destination of iov_iter_get_pages(); might as well work
into a separate batching array instead - copying struct page * is noise
compared to storing (and calculating) start/len pairs we have to do there.
Again, what we do there is a pure loop over page subranges.
* fuse_copy_fill(). I'm not at all sure that iov_iter_get_pages()
is a good idea there - fuse_copy_do() could bloody well just use
copy_{to,from}_iter().
* fs/splice.c:iter_to_pipe(). Loop over page subranges, consuming
page references. Unused ones are dropped.
* bio_iov_iter_get_pages(). Wants to populate
Re: Cherryview wake up events
Hi Mika,
On Tue, Jan 31, 2017 at 03:37:40PM +0100, Johannes Stezenbach wrote:
> - Powerbutton driver seems simple enough, the only specialty
> of the TI dcove PB driver is the workarond for lost button
> press event after resume. However, I still don't see how
> the PB would cause thermal event irqs on E200HA and how the
> PMIC driver would change it?
In ProductionKernelQuilts I found
DC-TI-PMIC-disable-power-button-support.patch so I guess it
might not be needed because it's probably handled by ACPI.
> I think the mfd driver would be similar to intel_soc_pmic_crc.c,
> the dollar_cove_ti_powerbtn.c I would keep instead of merging
> it into intel_mid_powerbtn.c. I guess what we need is in
> drivers/acpi/pmic/ something similar to intel_pmic_crc.c,
> the ProductionKernelQuilts has
> 0001-ACPI-Adding-support-for-TI-pmic-opregion.patch.
I have preliminary versions of the mfd and opregion driver,
while testing I found the GPIO opregion is not registered:
Excerpt from DSDT:
https://linuxtv.org/~js/e200ha/dsdt.dsl
Device (PMI2)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "INT33F5" /* TI PMIC Controller */) // _HID:
Hardware ID
Name (_CID, "INT33F5" /* TI PMIC Controller */) // _CID:
Compatible ID
Name (_DDN, "TI PMIC Controller") // _DDN: DOS Device Name
Name (_HRV, 0x03) // _HRV: Hardware Revision
Name (_UID, One) // _UID: Unique ID
Name (_DEP, Package (0x02) // _DEP: Dependencies
{
I2C7,
GPO1
})
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource
Settings
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBusV2 (0x005E, ControllerInitiated, 0x000F4240,
AddressingMode7Bit, "\\_SB.PCI0.I2C7",
0x00, ResourceConsumer, , Exclusive,
)
GpioInt (Level, ActiveHigh, Shared, PullDefault, 0x,
"\\_SB.GPO1", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x000F
}
})
Return (SBUF) /* \_SB_.PCI0.I2C7.PMI2._CRS.SBUF */
}
...
Name (AVBL, Zero)
Name (AVBD, Zero)
Name (AVBG, Zero)
Method (_REG, 2, NotSerialized) // _REG: Region Availability
{
If (Arg0 == 0x08)
{
AVBG = Arg1
}
If (Arg0 == 0x8D)
{
AVBL = Arg1
}
If (Arg0 == 0x8C)
{
AVBD = Arg1
}
}
acpidbg:
\_SB.PCI0.I2C7.PMI2.AVBL Integer 8be7b74d97a8 01 =
0001
\_SB.PCI0.I2C7.PMI2.AVBD Integer 8be7b74d94d8 01 =
0001
\_SB.PCI0.I2C7.PMI2.AVBG Integer 8be7b74d9be0 01 =
Any idea about it?
devm_gpiochip_add_data() in chv_gpio_probe() indirectly calls
acpi_gpiochip_add()
which should use _DEP to figure out to call _REG, right?
Also PMI2 has
OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0100)
Field (GPOP, ByteAcc, NoLock, Preserve)
{
Connection (
GpioIo (Exclusive, PullDefault, 0x, 0x,
IoRestrictionOutputOnly,
"\\_SB.PCI0.I2C7.PMI2", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0020
}
),
GMP0, 1,
...
(repeat for many more pins)
I guess it means it uses chv_gpio pins and can't work
if the GPIO opregion is not registered?
FWIW, with the mfd driver, /proc/interrupts has
180: 0 0 0 0 chv-gpio9 TI Dollar Cove
I guess the 9 refers to the 10th pin in north_pins[] which is pin 0x000F, right?
I boot with "dyndbg=file gpiolib* +p" and get
[ +0.012798] acpi INT33F5:00: GPIO: looking up 0 in _CRS
[ +0.000214] intel_soc_pmic_i2c i2c-INT33F5:00: GPIO lookup for consumer
intel_soc_pmic
[ +0.03] intel_soc_pmic_i2c i2c-INT33F5:00: using ACPI for GPIO lookup
[ +0.05] acpi INT33F5:00: GPIO: looking up intel_soc_pmic-gpios
[ +0.05] acpi INT33F5:00: GPIO: looking up intel_soc_pmic-gpio
[ +0.05] acpi INT33F5:00: GPIO: looking up 0 in _CRS
[ +0.91] cherryview-pinctrl INT33FF:01: request pin 15 (GPIO_SUS0) for
INT33FF:01:406
but so
Re: [PATCH] staging: lustre: shut up clang warnings on CLASSERT()
On Thu, Feb 02, 2017 at 07:50:24AM +, Dilger, Andreas wrote:
> 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)
Ugh, why not just use the in-kernel ASSERT macro instead?
thanks,
greg k-h
Re: [PATCH v2 00/10] serial: st-asc: Allow handling of RTS line
On Thu, Feb 02, 2017 at 07:42:36AM +, Lee Jones wrote: > 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? I'll take it in my next round of patches, give me a few days to sync up, I normally do serial patches once a week or so. thanks, greg k-h
Re: [PATCH V7 3/4] drm/bridge: Add driver for GE B850v3 LVDS/DP++ Bridge
On 02/01/2017 05:51 PM, Peter Senna Tschudin wrote:
On 01 February, 2017 12:35 CET, Daniel Vetter wrote:
On Wed, Feb 01, 2017 at 10:58:43AM +, Peter Senna Tschudin wrote:
Hi Archit,
On 01 February, 2017 10:44 CET, Archit Taneja wrote:
On 01/30/2017 10:35 PM, Jani Nikula wrote:
On Sat, 28 Jan 2017, Peter Senna Tschudin wrote:
On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote:
Hi Archit,
Thank you for the comments!
[...]
+ total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH;
+ if (total_size > EDID_LENGTH) {
+ kfree(block);
+ block = kmalloc(total_size, GFP_KERNEL);
+ if (!block)
+ return NULL;
+
+ /* Yes, read the entire buffer, and do not skip the first
+* EDID_LENGTH bytes.
+*/
Is this the reason why you aren't using drm_do_get_edid()?
Yes, for some hw specific reason, it is necessary to read the entire
EDID buffer starting from 0, not block by block.
Hrmh, I'm planning on moving the edid override and firmware edid
mechanisms at the drm_do_get_edid() level to be able to truly and
transparently use a different edid. Currently, they're only used for
modes, really, and lead to some info retrieved from overrides, some from
the real edid. This kind of hacks will bypass the override/firmware edid
mechanisms then too. :(
It seems like there is a HW issue which prevents them from reading EDID
from an offset. So, I'm not sure if it is a hack or a HW limitation.
One way around this would be to hide the HW requirement in the
get_edid_block func pointer passed to drm_do_get_edid(). This
would, however, result in more i2c reads (equal to # of extension
blocks) than what the patch currently does.
Peter, if you think doing extra EDID reads isn't too costly on your
platform, you could consider using drm_do_get_edid(). If not, I guess
you'll miss out on the additional functionality Jani is going to add
in the future.
My concern is that for almost one year now, every time I fix something
one or two new requests are made. I'm happy to fix the driver, but I
want a list of the changes that are required to get it upstream, before
I make more changes. Can we agree on exactly what is preventing this
driver to get upstream? Then I'll fix it.
I think addressing this edid reading question post-merge is perfectly
fine. Aside, want to keep maintaing your stuff as part of the drm-misc
group, with the drivers-in-misc experiment?
The edid thing was only a suggestion. As Daniel said, it's okay to work on
it post merge.
Please do fix the minor comments I mentioned in the latest patch set. I'll
pull in the first 3 patches once Rob H gives an Ack on the DT bindings
patch. The 4th patch needs to go through the SoC maintainer.
Thanks,
Archit
Yes, sure!
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Re: [PATCHv7 6/8] printk: use printk_safe buffers in printk
On (02/02/17 10:07), Peter Zijlstra wrote: > On Thu, Feb 02, 2017 at 11:11:34AM +0900, Sergey Senozhatsky wrote: > > On (02/01/17 16:39), Petr Mladek wrote: > > [..] > > > I guess that you are talking about the introduction of > > > #define SCHED_WARN_ON(x) WARN_ONCE(x, #x) > > > > my guess would be that Jan was talking about printk_deferred() patch. > > it's on my TODO list. > > > > I want to entirely remove console_sem and scheduler out of printk() path. > > that's the only way to make printk() deadlock safe. > > And useless.. if you never get around to the 'later' part where you > print the content. This way you still mostly get the output. well, I wouldn't say that printk_deferred() has less chances. I see your point, of course. but with printk_deferred() we, at least, will have messages in logbuf (or printk_safe buffers), so they can appear in crash dump, for instance. that "later" part can be sysrq, for example, or panic->flush_on_panic(), etc. if "normal" printk->queue irq_work doesn't work. needless to say, that in this particular case (WARN from sched), if the first printk() out of N printk()-s, which sched core calls to dump_stack(), deadlocks, then we got nothing to print/dump. > And no, its not the only way, see my printk->early_printk patches. early > serial console only does a loop over outb, impossible to mess that up. certainly :) -ss
Re: [RFC v3 02/10] KVM: arm/arm64: Move cntvoff to each timer context
On Wed, Feb 01, 2017 at 12:43:02PM -0500, Jintack Lim wrote: > Make cntvoff per each timer context. This is helpful to abstract kvm > timer functions to work with timer context without considering timer > types (e.g. physical timer or virtual timer). > > This also would pave the way for ever doing adjustments of the cntvoff > on a per-CPU basis if that should ever make sense. > > Signed-off-by: Jintack Lim Acked-by: Christoffer Dall
Re: [RFC v3 03/10] KVM: arm/arm64: Decouple kvm timer functions from virtual timer
On Wed, Feb 01, 2017 at 12:43:03PM -0500, Jintack Lim wrote: > Now that we have a separate structure for timer context, make functions > generic so that they can work with any timer context, not just the > virtual timer context. This does not change the virtual timer > functionality. > > Signed-off-by: Jintack Lim > Acked-by: Marc Zyngier Acked-by: Christoffer Dall
Re: [PATCH 1/2] gpio: Rename devm_get_gpiod_from_child()
On Wed, Feb 01, 2017 at 03:51:06PM +0100, Linus Walleij wrote: > fwnode_get_named_gpiod() > devm_get_gpiod_from_child() > > Both are taking a fwnode as argument and the naming is as > inconsistent as it can be. > > Some more churn should be expected as a side > effect of naming this function wrong in the first place. > The fwnode API change was on fast-forward and mistakes > were made, also by me, mea culpa. The name fwnode_get_named_gpiod() tries to follow of_get_named_gpio() so that we can easily convert a driver to use fwnodes instead. The other function is named so because we look child fwnodes under a device. For that, yes certainly we could have invented a better name ;-)
Business proposal
Dear Friend, I would like to discuss a very important issue with you. I am writing to find out if this is your valid email. Please, let me know if this email is valid Kind regards Adrien Saif Attorney to Qatif Group of Companies
Re: [PATCH v3 3/4] driver property: constify property arrays values
On Wed, Feb 01, 2017 at 09:31:24AM -0800, Dmitry Torokhov wrote: > Data that is fed into property arrays should not be modified, so let's mark > relevant pointers as const. This will allow us making source arrays as > const/__initconst. > > Also fix memory leaks on errors in property_entry_copy(). > > Signed-off-by: Dmitry Torokhov Reviewed-by: Mika Westerberg
Linux 4.9.7
I'm announcing the release of the 4.9.7 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arc/include/asm/delay.h |4 arch/arc/kernel/unaligned.c |3 arch/parisc/include/asm/bitops.h |8 + arch/parisc/include/uapi/asm/bitsperlong.h |2 arch/parisc/include/uapi/asm/swab.h |5 arch/s390/kernel/ptrace.c|8 + arch/s390/mm/pgtable.c |7 - arch/tile/kernel/ptrace.c|2 arch/x86/platform/mellanox/mlx-platform.c|2 drivers/base/memory.c|4 drivers/gpu/drm/drm_atomic_helper.c |2 drivers/gpu/drm/drm_modes.c |7 + drivers/gpu/drm/drm_probe_helper.c | 12 +- drivers/gpu/drm/i915/i915_drv.c |2 drivers/gpu/drm/i915/i915_gem_evict.c|1 drivers/gpu/drm/i915/intel_crt.c |9 - drivers/gpu/drm/i915/intel_display.c | 14 ++ drivers/gpu/drm/i915/intel_fbdev.c |3 drivers/gpu/drm/i915/intel_lrc.c |3 drivers/gpu/drm/i915/intel_ringbuffer.c |8 - drivers/gpu/drm/radeon/radeon_drv.c |7 - drivers/gpu/drm/vc4/vc4_crtc.c |2 drivers/gpu/drm/vc4/vc4_gem.c|4 drivers/gpu/drm/vc4/vc4_render_cl.c |2 drivers/infiniband/core/cma.c|3 drivers/infiniband/core/umem.c |2 drivers/infiniband/hw/cxgb4/device.c |9 + drivers/infiniband/hw/cxgb4/iw_cxgb4.h | 18 +++ drivers/infiniband/hw/cxgb4/provider.c | 20 ++- drivers/infiniband/hw/cxgb4/qp.c | 35 -- drivers/infiniband/sw/rxe/rxe_net.c |2 drivers/infiniband/sw/rxe/rxe_qp.c |3 drivers/infiniband/ulp/iser/iscsi_iser.c |7 - drivers/infiniband/ulp/srp/ib_srp.c | 15 ++ drivers/isdn/hardware/eicon/message.c|3 drivers/media/i2c/Kconfig|1 drivers/media/i2c/tvp5150.c | 56 ++--- drivers/media/i2c/tvp5150_reg.h |9 + drivers/media/usb/dvb-usb/pctv452e.c | 133 --- drivers/net/can/c_can/c_can_pci.c|1 drivers/net/can/ti_hecc.c| 16 ++ drivers/pinctrl/intel/pinctrl-baytrail.c | 28 ++-- drivers/pinctrl/intel/pinctrl-broxton.c |2 drivers/pinctrl/uniphier/pinctrl-uniphier-ld20.c |2 drivers/platform/x86/intel_mid_powerbtn.c|2 drivers/video/fbdev/core/fbcmap.c| 26 ++-- drivers/virtio/virtio_mmio.c | 20 +++ drivers/virtio/virtio_ring.c |7 + fs/btrfs/inode.c |8 - fs/nfs/nfs4proc.c|4 fs/xfs/xfs_qm.c |3 include/linux/memory_hotplug.h |4 include/linux/mmzone.h |6 - include/linux/nfs4.h |3 include/linux/sunrpc/clnt.h |1 include/uapi/rdma/cxgb3-abi.h|2 kernel/events/core.c | 58 +- kernel/sysctl.c |1 kernel/ucount.c | 14 +- mm/huge_memory.c | 18 ++- mm/memcontrol.c |4 mm/memory_hotplug.c | 28 ++-- mm/mempolicy.c |2 mm/page_alloc.c | 68 --- net/sunrpc/clnt.c|5 net/sunrpc/sunrpc_syms.c |1 67 files changed, 534 insertions(+), 239 deletions(-) Alex Deucher (1): Revert "drm/radeon: always apply pci shutdown callbacks" Ander Conselvan de Oliveira (4): drm/i915: Don't leak edid in intel_crt_detect_ddc() drm/i915: Don't init hpd polling for vlv and chv from runtime_suspend() drm/i915: Fix calculation of rotated x and y offsets for planar formats drm/i915: Check for NULL atomic state in intel_crtc_disable_noatomic() Andy Shevchenko (2): pinctrl: baytrail: Rectify debounce support platform/x86: intel_mid_powerbtn: Set IRQ_ONESHOT Ar
Re: Linux 4.9.7
diff --git a/Makefile b/Makefile
index ef95231d1625..da704d903321 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 6
+SUBLEVEL = 7
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arc/include/asm/delay.h b/arch/arc/include/asm/delay.h
index a36e8601114d..d5da2115d78a 100644
--- a/arch/arc/include/asm/delay.h
+++ b/arch/arc/include/asm/delay.h
@@ -26,7 +26,9 @@ static inline void __delay(unsigned long loops)
" lp 1f \n"
" nop \n"
"1: \n"
- : : "r"(loops));
+ :
+: "r"(loops)
+: "lp_count");
}
extern void __bad_udelay(void);
diff --git a/arch/arc/kernel/unaligned.c b/arch/arc/kernel/unaligned.c
index abd961f3e763..91ebe382147f 100644
--- a/arch/arc/kernel/unaligned.c
+++ b/arch/arc/kernel/unaligned.c
@@ -241,8 +241,9 @@ int misaligned_fixup(unsigned long address, struct pt_regs
*regs,
if (state.fault)
goto fault;
+ /* clear any remanants of delay slot */
if (delay_mode(regs)) {
- regs->ret = regs->bta;
+ regs->ret = regs->bta ~1U;
regs->status32 &= ~STATUS_DE_MASK;
} else {
regs->ret += state.instr_len;
diff --git a/arch/parisc/include/asm/bitops.h b/arch/parisc/include/asm/bitops.h
index 3f9406d9b9d6..da87943328a5 100644
--- a/arch/parisc/include/asm/bitops.h
+++ b/arch/parisc/include/asm/bitops.h
@@ -6,7 +6,7 @@
#endif
#include
-#include /* for BITS_PER_LONG/SHIFT_PER_LONG */
+#include
#include
#include
#include
@@ -17,6 +17,12 @@
* to include/asm-i386/bitops.h or kerneldoc
*/
+#if __BITS_PER_LONG == 64
+#define SHIFT_PER_LONG 6
+#else
+#define SHIFT_PER_LONG 5
+#endif
+
#define CHOP_SHIFTCOUNT(x) (((unsigned long) (x)) & (BITS_PER_LONG - 1))
diff --git a/arch/parisc/include/uapi/asm/bitsperlong.h
b/arch/parisc/include/uapi/asm/bitsperlong.h
index e0a23c7bdd43..07fa7e50bdc0 100644
--- a/arch/parisc/include/uapi/asm/bitsperlong.h
+++ b/arch/parisc/include/uapi/asm/bitsperlong.h
@@ -3,10 +3,8 @@
#if defined(__LP64__)
#define __BITS_PER_LONG 64
-#define SHIFT_PER_LONG 6
#else
#define __BITS_PER_LONG 32
-#define SHIFT_PER_LONG 5
#endif
#include
diff --git a/arch/parisc/include/uapi/asm/swab.h
b/arch/parisc/include/uapi/asm/swab.h
index e78403b129ef..928e1bbac98f 100644
--- a/arch/parisc/include/uapi/asm/swab.h
+++ b/arch/parisc/include/uapi/asm/swab.h
@@ -1,6 +1,7 @@
#ifndef _PARISC_SWAB_H
#define _PARISC_SWAB_H
+#include
#include
#include
@@ -38,7 +39,7 @@ static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
}
#define __arch_swab32 __arch_swab32
-#if BITS_PER_LONG > 32
+#if __BITS_PER_LONG > 32
/*
** From "PA-RISC 2.0 Architecture", HP Professional Books.
** See Appendix I page 8 , "Endian Byte Swapping".
@@ -61,6 +62,6 @@ static inline __attribute_const__ __u64 __arch_swab64(__u64 x)
return x;
}
#define __arch_swab64 __arch_swab64
-#endif /* BITS_PER_LONG > 32 */
+#endif /* __BITS_PER_LONG > 32 */
#endif /* _PARISC_SWAB_H */
diff --git a/arch/s390/kernel/ptrace.c b/arch/s390/kernel/ptrace.c
index 9336e824e2db..fc2974b929c3 100644
--- a/arch/s390/kernel/ptrace.c
+++ b/arch/s390/kernel/ptrace.c
@@ -963,6 +963,11 @@ static int s390_fpregs_set(struct task_struct *target,
if (target == current)
save_fpu_regs();
+ if (MACHINE_HAS_VX)
+ convert_vx_to_fp(fprs, target->thread.fpu.vxrs);
+ else
+ memcpy(&fprs, target->thread.fpu.fprs, sizeof(fprs));
+
/* If setting FPC, must validate it first. */
if (count > 0 && pos < offsetof(s390_fp_regs, fprs)) {
u32 ufpc[2] = { target->thread.fpu.fpc, 0 };
@@ -1067,6 +1072,9 @@ static int s390_vxrs_low_set(struct task_struct *target,
if (target == current)
save_fpu_regs();
+ for (i = 0; i < __NUM_VXRS_LOW; i++)
+ vxrs[i] = *((__u64 *)(target->thread.fpu.vxrs + i) + 1);
+
rc = user_regset_copyin(&pos, &count, &kbuf, &ubuf, vxrs, 0, -1);
if (rc == 0)
for (i = 0; i < __NUM_VXRS_LOW; i++)
diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
index 7a1897c51c54..d56ef26d4681 100644
--- a/arch/s390/mm/pgtable.c
+++ b/arch/s390/mm/pgtable.c
@@ -202,7 +202,7 @@ static inline pgste_t ptep_xchg_start(struct mm_struct *mm,
return pgste;
}
-static inline void ptep_xchg_commit(struct mm_struct *mm,
+static inline pte_t ptep_xchg_commit(struct mm_struct *mm,
unsigned long addr, pte_t *ptep,
pgste_t pgste, pte_t old, pte_t new)
{
@@ -220,6 +220,7 @@ static inline void ptep_xchg_commit(struct mm_struct *mm,
} else {
*ptep = new;
}
+ return old;
}
pte_t ptep_xchg_direct(struct mm_struct *mm, unsigned long addr,
@@ -23
Linux 4.4.46
I'm announcing the release of the 4.4.46 kernel. All users of the 4.4 kernel series must upgrade. The updated 4.4.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Makefile |2 arch/arc/include/asm/delay.h |4 + arch/arc/kernel/unaligned.c|3 - arch/parisc/include/asm/bitops.h |8 +++ arch/parisc/include/uapi/asm/bitsperlong.h |2 arch/parisc/include/uapi/asm/swab.h|5 +- arch/s390/kernel/ptrace.c |8 +++ arch/tile/kernel/ptrace.c |2 drivers/gpu/drm/drm_modes.c|7 +++ drivers/gpu/drm/i915/intel_crt.c |9 ++-- drivers/infiniband/core/cma.c |3 - drivers/infiniband/core/umem.c |2 drivers/infiniband/ulp/ipoib/ipoib.h | 20 ++--- drivers/infiniband/ulp/ipoib/ipoib_cm.c| 15 +++--- drivers/infiniband/ulp/ipoib/ipoib_ib.c| 12 ++--- drivers/infiniband/ulp/ipoib/ipoib_main.c | 54 +++-- drivers/infiniband/ulp/ipoib/ipoib_multicast.c |6 +- drivers/isdn/hardware/eicon/message.c |3 - drivers/media/i2c/Kconfig |1 drivers/net/can/c_can/c_can_pci.c |1 drivers/net/can/ti_hecc.c | 16 +-- drivers/pinctrl/intel/pinctrl-broxton.c|2 drivers/platform/x86/intel_mid_powerbtn.c |2 drivers/video/fbdev/core/fbcmap.c | 26 ++-- fs/nfs/nfs4proc.c |3 - include/linux/nfs4.h |3 - include/linux/sunrpc/clnt.h|1 kernel/sysctl.c|1 mm/memcontrol.c|4 - mm/mempolicy.c |2 net/sunrpc/clnt.c |5 ++ net/sunrpc/sunrpc_syms.c |1 32 files changed, 152 insertions(+), 81 deletions(-) Ander Conselvan de Oliveira (1): drm/i915: Don't leak edid in intel_crt_detect_ddc() Andy Shevchenko (1): platform/x86: intel_mid_powerbtn: Set IRQ_ONESHOT Arnd Bergmann (2): ISDN: eicon: silence misleading array-bounds warning s5k4ecgx: select CRC32 helper Benjamin Coddington (1): NFSv4.0: always send mode in SETATTR after EXCLUSIVE4 Chuck Lever (1): nfs: Don't increment lock sequence ID after NFS4ERR_MOVED Dave Martin (1): tile/ptrace: Preserve previous registers for short regset write David Rientjes (1): mm, memcg: do not retry precharge charges Einar Jón (1): can: c_can_pci: fix null-pointer-deref in c_can_start() - set device pointer Eric Dumazet (1): sysctl: fix proc_doulongvec_ms_jiffies_minmax() Greg Kroah-Hartman (1): Linux 4.4.46 Helge Deller (1): parisc: Don't use BITS_PER_LONG in userspace-exported swab.h header Jack Morgenstein (1): RDMA/cma: Fix unknown symbol when CONFIG_IPV6 is not enabled Kees Cook (1): fbdev: color map copying bounds checking Kenneth Lee (1): IB/umem: Release pid in error and ODP flow Kinglong Mee (1): SUNRPC: cleanup ida information when removing sunrpc module Martin Schwidefsky (1): s390/ptrace: Preserve previous registers for short regset write Mika Westerberg (1): pinctrl: broxton: Use correct PADCFGLOCK offset Paolo Abeni (1): IB/ipoib: move back IB LL address into the hard header Takashi Iwai (1): drm: Fix broken VT switch with video=1366x768 option Vineet Gupta (2): ARC: udelay: fix inline assembler by adding LP_COUNT to clobber list ARC: [arcompact] handle unaligned access delay slot corner case Vlastimil Babka (1): mm/mempolicy.c: do not put mempolicy before using its nodemask Yegor Yefremov (1): can: ti_hecc: add missing prepare and unprepare of the clock signature.asc Description: PGP signature
Re: Linux 4.4.46
diff --git a/Makefile b/Makefile
index a3dfc73da722..2dd5cb2fe182 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 45
+SUBLEVEL = 46
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/arc/include/asm/delay.h b/arch/arc/include/asm/delay.h
index a36e8601114d..d5da2115d78a 100644
--- a/arch/arc/include/asm/delay.h
+++ b/arch/arc/include/asm/delay.h
@@ -26,7 +26,9 @@ static inline void __delay(unsigned long loops)
" lp 1f \n"
" nop \n"
"1: \n"
- : : "r"(loops));
+ :
+: "r"(loops)
+: "lp_count");
}
extern void __bad_udelay(void);
diff --git a/arch/arc/kernel/unaligned.c b/arch/arc/kernel/unaligned.c
index abd961f3e763..91ebe382147f 100644
--- a/arch/arc/kernel/unaligned.c
+++ b/arch/arc/kernel/unaligned.c
@@ -241,8 +241,9 @@ int misaligned_fixup(unsigned long address, struct pt_regs
*regs,
if (state.fault)
goto fault;
+ /* clear any remanants of delay slot */
if (delay_mode(regs)) {
- regs->ret = regs->bta;
+ regs->ret = regs->bta ~1U;
regs->status32 &= ~STATUS_DE_MASK;
} else {
regs->ret += state.instr_len;
diff --git a/arch/parisc/include/asm/bitops.h b/arch/parisc/include/asm/bitops.h
index 3f9406d9b9d6..da87943328a5 100644
--- a/arch/parisc/include/asm/bitops.h
+++ b/arch/parisc/include/asm/bitops.h
@@ -6,7 +6,7 @@
#endif
#include
-#include /* for BITS_PER_LONG/SHIFT_PER_LONG */
+#include
#include
#include
#include
@@ -17,6 +17,12 @@
* to include/asm-i386/bitops.h or kerneldoc
*/
+#if __BITS_PER_LONG == 64
+#define SHIFT_PER_LONG 6
+#else
+#define SHIFT_PER_LONG 5
+#endif
+
#define CHOP_SHIFTCOUNT(x) (((unsigned long) (x)) & (BITS_PER_LONG - 1))
diff --git a/arch/parisc/include/uapi/asm/bitsperlong.h
b/arch/parisc/include/uapi/asm/bitsperlong.h
index e0a23c7bdd43..07fa7e50bdc0 100644
--- a/arch/parisc/include/uapi/asm/bitsperlong.h
+++ b/arch/parisc/include/uapi/asm/bitsperlong.h
@@ -3,10 +3,8 @@
#if defined(__LP64__)
#define __BITS_PER_LONG 64
-#define SHIFT_PER_LONG 6
#else
#define __BITS_PER_LONG 32
-#define SHIFT_PER_LONG 5
#endif
#include
diff --git a/arch/parisc/include/uapi/asm/swab.h
b/arch/parisc/include/uapi/asm/swab.h
index e78403b129ef..928e1bbac98f 100644
--- a/arch/parisc/include/uapi/asm/swab.h
+++ b/arch/parisc/include/uapi/asm/swab.h
@@ -1,6 +1,7 @@
#ifndef _PARISC_SWAB_H
#define _PARISC_SWAB_H
+#include
#include
#include
@@ -38,7 +39,7 @@ static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
}
#define __arch_swab32 __arch_swab32
-#if BITS_PER_LONG > 32
+#if __BITS_PER_LONG > 32
/*
** From "PA-RISC 2.0 Architecture", HP Professional Books.
** See Appendix I page 8 , "Endian Byte Swapping".
@@ -61,6 +62,6 @@ static inline __attribute_const__ __u64 __arch_swab64(__u64 x)
return x;
}
#define __arch_swab64 __arch_swab64
-#endif /* BITS_PER_LONG > 32 */
+#endif /* __BITS_PER_LONG > 32 */
#endif /* _PARISC_SWAB_H */
diff --git a/arch/s390/kernel/ptrace.c b/arch/s390/kernel/ptrace.c
index 01c37b36caf9..02bd587b610b 100644
--- a/arch/s390/kernel/ptrace.c
+++ b/arch/s390/kernel/ptrace.c
@@ -963,6 +963,11 @@ static int s390_fpregs_set(struct task_struct *target,
if (target == current)
save_fpu_regs();
+ if (MACHINE_HAS_VX)
+ convert_vx_to_fp(fprs, target->thread.fpu.vxrs);
+ else
+ memcpy(&fprs, target->thread.fpu.fprs, sizeof(fprs));
+
/* If setting FPC, must validate it first. */
if (count > 0 && pos < offsetof(s390_fp_regs, fprs)) {
u32 ufpc[2] = { target->thread.fpu.fpc, 0 };
@@ -1067,6 +1072,9 @@ static int s390_vxrs_low_set(struct task_struct *target,
if (target == current)
save_fpu_regs();
+ for (i = 0; i < __NUM_VXRS_LOW; i++)
+ vxrs[i] = *((__u64 *)(target->thread.fpu.vxrs + i) + 1);
+
rc = user_regset_copyin(&pos, &count, &kbuf, &ubuf, vxrs, 0, -1);
if (rc == 0)
for (i = 0; i < __NUM_VXRS_LOW; i++)
diff --git a/arch/tile/kernel/ptrace.c b/arch/tile/kernel/ptrace.c
index bdc126faf741..6239aa155f6d 100644
--- a/arch/tile/kernel/ptrace.c
+++ b/arch/tile/kernel/ptrace.c
@@ -111,7 +111,7 @@ static int tile_gpr_set(struct task_struct *target,
const void *kbuf, const void __user *ubuf)
{
int ret;
- struct pt_regs regs;
+ struct pt_regs regs = *task_pt_regs(target);
ret = user_regset_copyin(&pos, &count, &kbuf, &ubuf, ®s, 0,
sizeof(regs));
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 39e30abddf08..71a10f08522e 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1401,6 +1401,13 @@ drm_mode_create_from_cm
net: heap out-of-bounds in ip6_fragment
Hello, The following program triggers heap out-of-bounds in ip6_fragment: https://gist.githubusercontent.com/dvyukov/2596659b7a950d5f56f1eedfb30e2c7f/raw/b12afd119d960f7d179d220238257ba9666c6fdc/gistfile1.txt BUG: KASAN: slab-out-of-bounds in skb_copy_from_linear_data include/linux/skbuff.h:3165 [inline] at addr 8800696a7098 BUG: KASAN: slab-out-of-bounds in ip6_fragment+0x168e/0x38c0 net/ipv6/ip6_output.c:819 at addr 8800696a7098 Read of size 920 by task a.out/2924 CPU: 2 PID: 2924 Comm: a.out Not tainted 4.10.0-rc6+ #206 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:15 [inline] dump_stack+0x2ee/0x3ef lib/dump_stack.c:51 kasan_object_err+0x1c/0x70 mm/kasan/report.c:165 print_address_description mm/kasan/report.c:203 [inline] kasan_report_error+0x17b/0x430 mm/kasan/report.c:287 kasan_report+0x35/0x40 mm/kasan/report.c:307 check_memory_region_inline mm/kasan/kasan.c:315 [inline] check_memory_region+0x139/0x190 mm/kasan/kasan.c:322 memcpy+0x23/0x50 mm/kasan/kasan.c:357 skb_copy_from_linear_data include/linux/skbuff.h:3165 [inline] ip6_fragment+0x168e/0x38c0 net/ipv6/ip6_output.c:819 ip6_finish_output+0x319/0x950 net/ipv6/ip6_output.c:146 NF_HOOK_COND include/linux/netfilter.h:246 [inline] ip6_output+0x1cb/0x8c0 net/ipv6/ip6_output.c:162 dst_output include/net/dst.h:501 [inline] ip6_local_out+0x95/0x170 net/ipv6/output_core.c:172 ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722 ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742 rawv6_push_pending_frames net/ipv6/raw.c:613 [inline] rawv6_sendmsg+0x2d1a/0x3ec0 net/ipv6/raw.c:927 inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744 sock_sendmsg_nosec net/socket.c:635 [inline] sock_sendmsg+0xca/0x110 net/socket.c:645 ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985 __sys_sendmsg+0x138/0x300 net/socket.c:2019 SYSC_sendmsg net/socket.c:2030 [inline] SyS_sendmsg+0x2d/0x50 net/socket.c:2026 entry_SYSCALL_64_fastpath+0x1f/0xc2 RIP: 0033:0x435059 RSP: 002b:7ffe2884c958 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 00401db0 RCX: 00435059 RDX: 00040040 RSI: 200c4000 RDI: 0003 RBP: R08: R09: R10: R11: 0246 R12: 004002b0 R13: 00401db0 R14: 00401e40 R15: Object at 8800696a7080, in cache kmalloc-512 size: 512 Allocated: PID = 2924 [] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57 [] save_stack+0x43/0xd0 mm/kasan/kasan.c:502 [] set_track mm/kasan/kasan.c:514 [inline] [] kasan_kmalloc+0xaa/0xd0 mm/kasan/kasan.c:605 [] __do_kmalloc_node mm/slab.c:3691 [inline] [] __kmalloc_node_track_caller+0x47/0x70 mm/slab.c:3705 [] __kmalloc_reserve.isra.36+0x41/0xd0 net/core/skbuff.c:138 [] __alloc_skb+0x159/0x7e0 net/core/skbuff.c:231 [] alloc_skb include/linux/skbuff.h:926 [inline] [] sock_wmalloc+0x14d/0x1e0 net/core/sock.c:1766 [] __ip6_append_data.isra.43+0x28ba/0x3c00 net/ipv6/ip6_output.c:1460 [] ip6_append_data+0x1aa/0x2b0 net/ipv6/ip6_output.c:1616 [] rawv6_sendmsg+0x1efd/0x3ec0 net/ipv6/raw.c:920 [] inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744 [] sock_sendmsg_nosec net/socket.c:635 [inline] [] sock_sendmsg+0xca/0x110 net/socket.c:645 [] ___sys_sendmsg+0x8fa/0x9f0 net/socket.c:1985 [] __sys_sendmsg+0x138/0x300 net/socket.c:2019 [] SYSC_sendmsg net/socket.c:2030 [inline] [] SyS_sendmsg+0x2d/0x50 net/socket.c:2026 [] entry_SYSCALL_64_fastpath+0x1f/0xc2 Memory state around the buggy address: 8800696a7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8800696a7200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >8800696a7280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ 8800696a7300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 8800696a7380: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 == On commit a2ca3d617944417e9dd5f09fc8a4549cda115f4f.
Re: [RFC PATCH 1/2] mm, vmscan: account the number of isolated pages per zone
On Mon 30-01-17 09:55:46, Michal Hocko wrote: > On Sun 29-01-17 00:27:27, Tetsuo Handa wrote: [...] > > Regarding [1], it helped avoiding the too_many_isolated() issue. I can't > > tell whether it has any negative effect, but I got on the first trial that > > all allocating threads are blocked on wait_for_completion() from > > flush_work() > > in drain_all_pages() introduced by "mm, page_alloc: drain per-cpu pages from > > workqueue context". There was no warn_alloc() stall warning message > > afterwords. > > That patch is buggy and there is a follow up [1] which is not sitting in the > mmotm (and thus linux-next) yet. I didn't get to review it properly and > I cannot say I would be too happy about using WQ from the page > allocator. I believe even the follow up needs to have WQ_RECLAIM WQ. > > [1] > http://lkml.kernel.org/r/20170125083038.rzb5f43nptmk7...@techsingularity.net Did you get chance to test with this follow up patch? It would be interesting to see whether OOM situation can still starve the waiter. The current linux-next should contain this patch. Thanks! -- Michal Hocko SUSE Labs
Re: [RFC v3 05/10] KVM: arm/arm64: Initialize the emulated EL1 physical timer
On Wed, Feb 01, 2017 at 12:43:05PM -0500, Jintack Lim wrote:
> Initialize the emulated EL1 physical timer with the default irq number.
>
> Signed-off-by: Jintack Lim
We really need to do something about that IRQ number thing. I'll add
this to my todo list.
Since this is no worse than what we already do and doesn't place any
restrictions on future ABI to let userspace decide on the IRQ numbers:
Reviewed-by: Christoffer Dall
> ---
> arch/arm/kvm/reset.c | 9 -
> arch/arm64/kvm/reset.c | 9 -
> include/kvm/arm_arch_timer.h | 3 ++-
> virt/kvm/arm/arch_timer.c| 9 +++--
> 4 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/kvm/reset.c b/arch/arm/kvm/reset.c
> index 4b5e802..1da8b2d 100644
> --- a/arch/arm/kvm/reset.c
> +++ b/arch/arm/kvm/reset.c
> @@ -37,6 +37,11 @@
> .usr_regs.ARM_cpsr = SVC_MODE | PSR_A_BIT | PSR_I_BIT | PSR_F_BIT,
> };
>
> +static const struct kvm_irq_level cortexa_ptimer_irq = {
> + { .irq = 30 },
> + .level = 1,
> +};
> +
> static const struct kvm_irq_level cortexa_vtimer_irq = {
> { .irq = 27 },
> .level = 1,
> @@ -58,6 +63,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> {
> struct kvm_regs *reset_regs;
> const struct kvm_irq_level *cpu_vtimer_irq;
> + const struct kvm_irq_level *cpu_ptimer_irq;
>
> switch (vcpu->arch.target) {
> case KVM_ARM_TARGET_CORTEX_A7:
> @@ -65,6 +71,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> reset_regs = &cortexa_regs_reset;
> vcpu->arch.midr = read_cpuid_id();
> cpu_vtimer_irq = &cortexa_vtimer_irq;
> + cpu_ptimer_irq = &cortexa_ptimer_irq;
> break;
> default:
> return -ENODEV;
> @@ -77,5 +84,5 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> kvm_reset_coprocs(vcpu);
>
> /* Reset arch_timer context */
> - return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
> + return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq, cpu_ptimer_irq);
> }
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index e95d4f6..d9e9697 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -46,6 +46,11 @@
> COMPAT_PSR_I_BIT | COMPAT_PSR_F_BIT),
> };
>
> +static const struct kvm_irq_level default_ptimer_irq = {
> + .irq= 30,
> + .level = 1,
> +};
> +
> static const struct kvm_irq_level default_vtimer_irq = {
> .irq= 27,
> .level = 1,
> @@ -104,6 +109,7 @@ int kvm_arch_dev_ioctl_check_extension(struct kvm *kvm,
> long ext)
> int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> {
> const struct kvm_irq_level *cpu_vtimer_irq;
> + const struct kvm_irq_level *cpu_ptimer_irq;
> const struct kvm_regs *cpu_reset;
>
> switch (vcpu->arch.target) {
> @@ -117,6 +123,7 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> }
>
> cpu_vtimer_irq = &default_vtimer_irq;
> + cpu_ptimer_irq = &default_ptimer_irq;
> break;
> }
>
> @@ -130,5 +137,5 @@ int kvm_reset_vcpu(struct kvm_vcpu *vcpu)
> kvm_pmu_vcpu_reset(vcpu);
>
> /* Reset timer */
> - return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq);
> + return kvm_timer_vcpu_reset(vcpu, cpu_vtimer_irq, cpu_ptimer_irq);
> }
> diff --git a/include/kvm/arm_arch_timer.h b/include/kvm/arm_arch_timer.h
> index 6445a3d..f1d2fba0 100644
> --- a/include/kvm/arm_arch_timer.h
> +++ b/include/kvm/arm_arch_timer.h
> @@ -58,7 +58,8 @@ struct arch_timer_cpu {
> int kvm_timer_hyp_init(void);
> int kvm_timer_enable(struct kvm_vcpu *vcpu);
> int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> - const struct kvm_irq_level *irq);
> + const struct kvm_irq_level *virt_irq,
> + const struct kvm_irq_level *phys_irq);
> void kvm_timer_vcpu_init(struct kvm_vcpu *vcpu);
> void kvm_timer_flush_hwstate(struct kvm_vcpu *vcpu);
> void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu);
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index c42bca5..ae38703 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -327,9 +327,11 @@ void kvm_timer_sync_hwstate(struct kvm_vcpu *vcpu)
> }
>
> int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
> - const struct kvm_irq_level *irq)
> + const struct kvm_irq_level *virt_irq,
> + const struct kvm_irq_level *phys_irq)
> {
> struct arch_timer_context *vtimer = vcpu_vtimer(vcpu);
> + struct arch_timer_context *ptimer = vcpu_ptimer(vcpu);
>
> /*
>* The vcpu timer irq number cannot be determined in
> @@ -337,7 +339,8 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu,
>* kvm_vcpu_set_target(). To handle this, we determine
>* vcpu timer irq number when the vcpu is reset.
>*/
> - vtimer->irq.irq = irq->irq;
> + vtimer
Re: [RFC v3 04/10] KVM: arm/arm64: Add the EL1 physical timer context
On Wed, Feb 01, 2017 at 12:43:04PM -0500, Jintack Lim wrote: > Add the EL1 physical timer context. > > Signed-off-by: Jintack Lim Acked-by: Christoffer Dall
Re: [PATCH v3 4/4] i2c: allow specify device properties in i2c_board_info
On Wed, Feb 01, 2017 at 09:31:25AM -0800, Dmitry Torokhov wrote: > With many drivers converting to using generic device properties, it is > useful to provide array of device properties when instantiating new i2c > client via i2c_board_info and have them automatically added to the device > in question. > > Signed-off-by: Dmitry Torokhov Reviewed-by: Mika Westerberg
Re: [RFC v3 06/10] KVM: arm/arm64: Update the physical timer interrupt level
On Wed, Feb 01, 2017 at 12:43:06PM -0500, Jintack Lim wrote: > Now that we maintain the EL1 physical timer register states of VMs, > update the physical timer interrupt level along with the virtual one. > > Signed-off-by: Jintack Lim Acked-by: Christoffer Dall
Re: [RESENT PATCH] ARM: bcm2835: Add devicetree for the Raspberry Pi 3, for arm (32)
On Thu, 2017-02-02 at 10:50 +0100, Stefan Wahren wrote: > Am 02.02.2017 um 09:37 schrieb Michael Zoran: > > This is actually a problem I had to deal with way in the begging of > > ARM64. What was done in the github tree was to have the one of the > > DTS > > files(in this case 64) #include the 32 bit dts. That way it's > > not > > needed to have the symbolic link and install should work. > > > > I know it's ulgy, but it works... > > > > Take a look at: > > https://github.com/raspberrypi/linux/blob/rpi-4.10.y/arch/arm64/boo > > t/dt > > s/broadcom/bcm2710-rpi-3-b.dts > > > > Here is what the file contains: > > #define RPI364 > > > > #include "../../../../arm/boot/dts/bcm2710-rpi-3-b.dts" > > > > > > > > This do not work in the context of the split device-tree repository > [0] > (where the directory structure differs). > > [0] > https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-re > basing.git/ Well, two other options would be to simply duplicate the device tree files. I know that's a pain... The other option is choose one or the other(arm64 vs. arm32), I would guess pick arm32. It works... And at this time, arm64 doesn't have a whole bunch of benefit on the RPI 3. Perhaps maybe a RPI 4 will come out someday and we will see more of a gain.
Re: [PATCH 2/2] perf/x86/intel/pt: Allow disabling branch tracing
Alexander Shishkin writes:
> @@ -72,12 +77,14 @@ static struct pt_cap_desc {
> PT_CAP(mtc_periods, 1, CPUID_EAX, 0x),
> PT_CAP(cycle_thresholds,1, CPUID_EBX, 0x),
> PT_CAP(psb_periods, 1, CPUID_EBX, 0x),
> + PT_CAP(passthrough, PT_SW_CAP, 0, 1),
Thinking some more: we don't actually need this as the format string
already serves this purpose.
Regards,
--
Alex
Re: [PATCH] modules: mark __inittest/__exittest as __maybe_unused
On Thu, Feb 2, 2017 at 10:25 AM, Rusty Russell wrote: > Arnd Bergmann writes: >> clang warns about unused inline functions by default: >> >> arch/arm/crypto/aes-cipher-glue.c:68:1: warning: unused function >> '__inittest' [-Wunused-function] >> arch/arm/crypto/aes-cipher-glue.c:69:1: warning: unused function >> '__exittest' [-Wunused-function] >> >> As these appear in every single module, let's just disable the warnings by >> marking the >> two functions as __maybe_unused. > > Um, won't you have to do that to hundreds of kernel headers? Why > module.h? clang specifically warns about inline functions that are defined in a .c file but not used there, but it is sensible enough to not warn about unused inline functions that are defined in a header. In an ARM allmodconfig build, I currently see 178 .c files[1] that have unused inline functions. The proper way to deal with them is probably to move the warning into the "make W=1" level to hide it by default and then do one driver at a time. The module.h definitions are special because the inline function is defined through a macro that gets evaluated by almost every loadable module, and we get a warning for every one of them, which the subsystem maintainers cannot deal with by changing their code locally. Arnd [1] http://pastebin.com/pnHvbHQ3
[PATCH 1/3] ath10k: remove ath10k_vif_to_arvif()
it adds unnecessary level of indirection, while we just access structure
field
Signed-off-by: Amadeusz Sławiński
---
drivers/net/wireless/ath/ath10k/mac.c | 68 +--
drivers/net/wireless/ath/ath10k/mac.h | 7 +---
drivers/net/wireless/ath/ath10k/p2p.c | 2 +-
drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
4 files changed, 37 insertions(+), 42 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index aa545a1..9cb96f6 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1954,7 +1954,7 @@ static void ath10k_mac_handle_beacon_iter(void *data, u8
*mac,
{
struct sk_buff *skb = data;
struct ieee80211_mgmt *mgmt = (void *)skb->data;
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
if (vif->type != NL80211_IFTYPE_STATION)
return;
@@ -1977,7 +1977,7 @@ static void ath10k_mac_handle_beacon_miss_iter(void
*data, u8 *mac,
struct ieee80211_vif *vif)
{
u32 *vdev_id = data;
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
struct ath10k *ar = arvif->ar;
struct ieee80211_hw *hw = ar->hw;
@@ -2044,7 +2044,7 @@ static void ath10k_peer_assoc_h_basic(struct ath10k *ar,
struct ieee80211_sta *sta,
struct wmi_peer_assoc_complete_arg *arg)
{
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
u32 aid;
lockdep_assert_held(&ar->conf_mutex);
@@ -2120,7 +2120,7 @@ static void ath10k_peer_assoc_h_rates(struct ath10k *ar,
struct ieee80211_sta *sta,
struct wmi_peer_assoc_complete_arg *arg)
{
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
struct wmi_rate_set_arg *rateset = &arg->peer_legacy_rates;
struct cfg80211_chan_def def;
const struct ieee80211_supported_band *sband;
@@ -2183,7 +2183,7 @@ static void ath10k_peer_assoc_h_ht(struct ath10k *ar,
struct wmi_peer_assoc_complete_arg *arg)
{
const struct ieee80211_sta_ht_cap *ht_cap = &sta->ht_cap;
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
struct cfg80211_chan_def def;
enum nl80211_band band;
const u8 *ht_mcs_mask;
@@ -2407,7 +2407,7 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
struct wmi_peer_assoc_complete_arg *arg)
{
const struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
struct cfg80211_chan_def def;
enum nl80211_band band;
const u16 *vht_mcs_mask;
@@ -2465,7 +2465,7 @@ static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
struct ieee80211_sta *sta,
struct wmi_peer_assoc_complete_arg *arg)
{
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
switch (arvif->vdev_type) {
case WMI_VDEV_TYPE_AP:
@@ -2505,7 +2505,7 @@ static void ath10k_peer_assoc_h_phymode(struct ath10k *ar,
struct ieee80211_sta *sta,
struct wmi_peer_assoc_complete_arg *arg)
{
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
struct cfg80211_chan_def def;
enum nl80211_band band;
const u8 *ht_mcs_mask;
@@ -2625,7 +2625,7 @@ static int ath10k_mac_vif_recalc_txbf(struct ath10k *ar,
struct ieee80211_vif *vif,
struct ieee80211_sta_vht_cap vht_cap)
{
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
int ret;
u32 param;
u32 value;
@@ -2692,7 +2692,7 @@ static void ath10k_bss_assoc(struct ieee80211_hw *hw,
struct ieee80211_bss_conf *bss_conf)
{
struct ath10k *ar = hw->priv;
- struct ath10k_vif *arvif = ath10k_vif_to_arvif(vif);
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
struct ieee80211_sta_ht_cap ht_cap;
struct ieee80211_sta_vht_cap vht_cap;
struct wmi_peer_assoc_complete_arg peer_arg;
@@ -2785,7 +2785,7 @@ static void ath10k_bss_disassoc(struct ieee80211_hw *hw,
st
[PATCH 2/3] ath10k: use size_t for len variables
cleanup to consolidate type used for len variables
Signed-off-by: Amadeusz Sławiński
---
drivers/net/wireless/ath/ath10k/core.c | 2 +-
drivers/net/wireless/ath/ath10k/debug.c| 49 +++---
drivers/net/wireless/ath/ath10k/spectral.c | 7 +++--
3 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 749e381..2aa6bc7 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -349,7 +349,7 @@ void ath10k_core_get_fw_features_str(struct ath10k *ar,
char *buf,
size_t buf_len)
{
- unsigned int len = 0;
+ size_t len = 0;
int i;
for (i = 0; i < ATH10K_FW_FEATURE_COUNT; i++) {
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 82a4c67..f649236 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -235,7 +235,7 @@ static ssize_t ath10k_read_wmi_services(struct file *file,
{
struct ath10k *ar = file->private_data;
char *buf;
- unsigned int len = 0, buf_len = 4096;
+ size_t len = 0, buf_len = 4096;
const char *name;
ssize_t ret_cnt;
bool enabled;
@@ -524,7 +524,7 @@ static ssize_t ath10k_fw_stats_read(struct file *file, char
__user *user_buf,
size_t count, loff_t *ppos)
{
const char *buf = file->private_data;
- unsigned int len = strlen(buf);
+ size_t len = strlen(buf);
return simple_read_from_buffer(user_buf, count, ppos, buf, len);
}
@@ -542,17 +542,16 @@ static ssize_t ath10k_debug_fw_reset_stats_read(struct
file *file,
size_t count, loff_t *ppos)
{
struct ath10k *ar = file->private_data;
- int ret, len, buf_len;
+ int ret;
+ size_t len = 0, buf_len = 500;
char *buf;
- buf_len = 500;
buf = kmalloc(buf_len, GFP_KERNEL);
if (!buf)
return -ENOMEM;
spin_lock_bh(&ar->data_lock);
- len = 0;
len += scnprintf(buf + len, buf_len - len,
"fw_crash_counter\t\t%d\n",
ar->stats.fw_crash_counter);
len += scnprintf(buf + len, buf_len - len,
@@ -691,7 +690,7 @@ static ssize_t ath10k_read_chip_id(struct file *file, char
__user *user_buf,
size_t count, loff_t *ppos)
{
struct ath10k *ar = file->private_data;
- unsigned int len;
+ size_t len;
char buf[50];
len = scnprintf(buf, sizeof(buf), "0x%08x\n", ar->chip_id);
@@ -726,8 +725,8 @@ static struct ath10k_dump_file_data
*ath10k_build_dump_file(struct ath10k *ar)
struct ath10k_fw_crash_data *crash_data = ar->debug.fw_crash_data;
struct ath10k_dump_file_data *dump_data;
struct ath10k_tlv_dump_data *dump_tlv;
- int hdr_len = sizeof(*dump_data);
- unsigned int len, sofar = 0;
+ size_t hdr_len = sizeof(*dump_data);
+ size_t len, sofar = 0;
unsigned char *buf;
len = hdr_len;
@@ -844,7 +843,7 @@ static ssize_t ath10k_reg_addr_read(struct file *file,
{
struct ath10k *ar = file->private_data;
u8 buf[32];
- unsigned int len = 0;
+ size_t len = 0;
u32 reg_addr;
mutex_lock(&ar->conf_mutex);
@@ -892,7 +891,7 @@ static ssize_t ath10k_reg_value_read(struct file *file,
{
struct ath10k *ar = file->private_data;
u8 buf[48];
- unsigned int len;
+ size_t len;
u32 reg_addr, reg_val;
int ret;
@@ -1115,7 +1114,7 @@ static ssize_t ath10k_read_htt_stats_mask(struct file
*file,
{
struct ath10k *ar = file->private_data;
char buf[32];
- unsigned int len;
+ size_t len;
len = scnprintf(buf, sizeof(buf), "%lu\n", ar->debug.htt_stats_mask);
@@ -1169,7 +1168,7 @@ static ssize_t ath10k_read_htt_max_amsdu_ampdu(struct
file *file,
struct ath10k *ar = file->private_data;
char buf[64];
u8 amsdu, ampdu;
- unsigned int len;
+ size_t len;
mutex_lock(&ar->conf_mutex);
@@ -1229,7 +1228,7 @@ static ssize_t ath10k_read_fw_dbglog(struct file *file,
size_t count, loff_t *ppos)
{
struct ath10k *ar = file->private_data;
- unsigned int len;
+ size_t len;
char buf[96];
len = scnprintf(buf, sizeof(buf), "0x%16llx %u\n",
@@ -1555,11 +1554,10 @@ static ssize_t ath10k_read_ani_enable(struct file
*file, char __user *user_buf,
size_t count, loff_t *ppos)
{
struct ath10k *ar = file->private_data;
- int len = 0;
+ size_t len;
char buf[32];
- len = scnprintf(buf, sizeof(buf) - len, "%d\n",
-
[PATCH 3/3] ath10k: fix comment
I wanted to take a look and it's apparently in other header
Signed-off-by: Amadeusz Sławiński
---
drivers/net/wireless/ath/ath10k/wmi.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
b/drivers/net/wireless/ath/ath10k/wmi.h
index 5d3dff9..bf8dcbe 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -75,7 +75,7 @@ struct wmi_cmd_hdr {
/*
* There is no signed version of __le32, so for a temporary solution come
- * up with our own version. The idea is from fs/ntfs/types.h.
+ * up with our own version. The idea is from fs/ntfs/endian.h.
*
* Use a_ prefix so that it doesn't conflict if we get proper support to
* linux/types.h.
--
1.9.1
Re: [RFC v3 07/10] KVM: arm/arm64: Set a background timer to the earliest timer expiration
On Wed, Feb 01, 2017 at 12:43:07PM -0500, Jintack Lim wrote: > When scheduling a background timer, consider both of the virtual and > physical timer and pick the earliest expiration time. > > Signed-off-by: Jintack Lim Reviewed-by: Christoffer Dall
Re: [RFC v3 10/10] KVM: arm/arm64: Emulate the EL1 phys timer registers
On Wed, Feb 01, 2017 at 12:43:10PM -0500, Jintack Lim wrote: > Emulate read and write operations to CNTP_TVAL, CNTP_CVAL and CNTP_CTL. > Now VMs are able to use the EL1 physical timer. > > Signed-off-by: Jintack Lim Reviewed-by: Christoffer Dall
Re: [RFC v3 08/10] KVM: arm/arm64: Set up a background timer for the physical timer emulation
On Wed, Feb 01, 2017 at 12:43:08PM -0500, Jintack Lim wrote: > Set a background timer for the EL1 physical timer emulation while VMs > are running, so that VMs get the physical timer interrupts in a timely > manner. > > Schedule the background timer on entry to the VM and cancel it on exit. > This would not have any performance impact to the guest OSes that > currently use the virtual timer since the physical timer is always not > enabled. > > Signed-off-by: Jintack Lim Reviewed-by: Christoffer Dall
Re: [RFC v3 09/10] KVM: arm64: Add the EL1 physical timer access handler
On Wed, Feb 01, 2017 at 12:43:09PM -0500, Jintack Lim wrote: > KVM traps on the EL1 phys timer accesses from VMs, but it doesn't handle > those traps. This results in terminating VMs. Instead, set a handler for > the EL1 phys timer access, and inject an undefined exception as an > intermediate step. > > Signed-off-by: Jintack Lim Reviewed-by: Christoffer Dall
Re: Cherryview wake up events
On Thu, Feb 02, 2017 at 10:52:00AM +0100, Johannes Stezenbach wrote:
> Hi Mika,
>
> On Tue, Jan 31, 2017 at 03:37:40PM +0100, Johannes Stezenbach wrote:
> > - Powerbutton driver seems simple enough, the only specialty
> > of the TI dcove PB driver is the workarond for lost button
> > press event after resume. However, I still don't see how
> > the PB would cause thermal event irqs on E200HA and how the
> > PMIC driver would change it?
>
> In ProductionKernelQuilts I found
> DC-TI-PMIC-disable-power-button-support.patch so I guess it
> might not be needed because it's probably handled by ACPI.
>
> > I think the mfd driver would be similar to intel_soc_pmic_crc.c,
> > the dollar_cove_ti_powerbtn.c I would keep instead of merging
> > it into intel_mid_powerbtn.c. I guess what we need is in
> > drivers/acpi/pmic/ something similar to intel_pmic_crc.c,
> > the ProductionKernelQuilts has
> > 0001-ACPI-Adding-support-for-TI-pmic-opregion.patch.
>
> I have preliminary versions of the mfd and opregion driver,
> while testing I found the GPIO opregion is not registered:
Cool, I take it that you started working on that ;-)
> Excerpt from DSDT:
> https://linuxtv.org/~js/e200ha/dsdt.dsl
>
> Device (PMI2)
> {
> Name (_ADR, Zero) // _ADR: Address
> Name (_HID, "INT33F5" /* TI PMIC Controller */) // _HID:
> Hardware ID
> Name (_CID, "INT33F5" /* TI PMIC Controller */) // _CID:
> Compatible ID
> Name (_DDN, "TI PMIC Controller") // _DDN: DOS Device Name
> Name (_HRV, 0x03) // _HRV: Hardware Revision
> Name (_UID, One) // _UID: Unique ID
> Name (_DEP, Package (0x02) // _DEP: Dependencies
> {
> I2C7,
> GPO1
> })
> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource
> Settings
> {
> Name (SBUF, ResourceTemplate ()
> {
> I2cSerialBusV2 (0x005E, ControllerInitiated,
> 0x000F4240,
> AddressingMode7Bit, "\\_SB.PCI0.I2C7",
> 0x00, ResourceConsumer, , Exclusive,
> )
> GpioInt (Level, ActiveHigh, Shared, PullDefault,
> 0x,
> "\\_SB.GPO1", 0x00, ResourceConsumer, ,
> )
> { // Pin list
> 0x000F
> }
> })
> Return (SBUF) /* \_SB_.PCI0.I2C7.PMI2._CRS.SBUF */
> }
> ...
> Name (AVBL, Zero)
> Name (AVBD, Zero)
> Name (AVBG, Zero)
> Method (_REG, 2, NotSerialized) // _REG: Region Availability
> {
> If (Arg0 == 0x08)
> {
> AVBG = Arg1
> }
>
> If (Arg0 == 0x8D)
> {
> AVBL = Arg1
> }
>
> If (Arg0 == 0x8C)
> {
> AVBD = Arg1
> }
> }
>
>
> acpidbg:
> \_SB.PCI0.I2C7.PMI2.AVBL Integer 8be7b74d97a8 01 =
> 0001
> \_SB.PCI0.I2C7.PMI2.AVBD Integer 8be7b74d94d8 01 =
> 0001
> \_SB.PCI0.I2C7.PMI2.AVBG Integer 8be7b74d9be0 01 =
>
>
> Any idea about it?
> devm_gpiochip_add_data() in chv_gpio_probe() indirectly calls
> acpi_gpiochip_add()
> which should use _DEP to figure out to call _REG, right?
Actually no, we don't support all _DEP in Linux yet. But that's not the
problem though. See below.
> Also PMI2 has
>
> OperationRegion (GPOP, GeneralPurposeIo, Zero, 0x0100)
> Field (GPOP, ByteAcc, NoLock, Preserve)
> {
> Connection (
> GpioIo (Exclusive, PullDefault, 0x, 0x,
> IoRestrictionOutputOnly,
> "\\_SB.PCI0.I2C7.PMI2", 0x00, ResourceConsumer, ,
> )
> { // Pin list
> 0x0020
> }
> ),
> GMP0, 1,
> ...
> (repeat for many more pins)
>
> I guess it means it uses chv_gpio pins and can't work
> if the GPIO opregion is not registered?
That is using GPIO pins of the PMI2 device - the PMIC GPIO driver, I
suppose.
So in addition to the PMIC MFD driver, you need to have a GPIO driver
for Dollar Cove (I guess the quilt patch series included that as well?).
If you look under the /sys/bus/acpi/devices/DEVICE, it should include
bunch of physical_nodeX links.
[PATCH v2 0/2] drm: Support framebuffer panning
Hi, This is a respin of the previous serie called "Support fast framebuffer panning for i.MX6" made by Stefan 6 monthes ago. The imx6 bits have been removed, and the comments that were made at that time fixed (hopefully). Let me know what you think, Maxime Changes from v1: - Added drm_fb_helper_ioctl to DRM_FB_HELPER_DEFAULT_OPS - Expanded a bit the kerneldoc for drm_fb_helper_ioctl - Added some locking to drm_fb_helper_ioctl - Checked that the framebuffer is indeed attached before allowing ioctl - Added a module parameter to specify the number of framebuffers to allocate Initial cover letter: Support fast framebuffer panning for i.MX6 im currently working on supporting double/tripple buffering for the framebuffer emulation on the i.MX6. While working on it I noticed that the mainline kernel does not support some features in the generic drm framebuffer emulation for framebuffer panning and vsync synchronisation. They are needed for simple framebuffer applications and some OpenGL libraries using double buffering with FBIOPUT_VSCREENINFO, FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY. Stefan Christ (1): drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC Xinliang Liu (1): drm/cma-helper: Add multi buffer support for cma fbdev drivers/gpu/drm/Kconfig | 8 - drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++- drivers/gpu/drm/drm_fb_helper.c | 55 ++- include/drm/drm_fb_helper.h | 5 ++- 4 files changed, 74 insertions(+), 2 deletions(-) base-commit: 8b394ae674998d4ade6cb48aec3fca5445908dfe -- git-series 0.8.11
[PATCH v2 2/2] drm/fb_helper: implement ioctl FBIO_WAITFORVSYNC
From: Stefan Christ
Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
framebuffer emulation driver. Legacy framebuffer users like non kms/drm
based OpenGL(ES)/EGL implementations may require the ioctl to
synchronize drawing or buffer flip for double buffering. It is tested on
the i.MX6.
Code is based on
https://github.com/Xilinx/linux-xlnx/blob/master/drivers/gpu/drm/xilinx/xilinx_drm_fb.c#L196
Signed-off-by: Stefan Christ
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_fb_helper.c | 55 ++-
include/drm/drm_fb_helper.h | 5 ++-
2 files changed, 59 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index e934b541feea..39a3532e311c 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1234,6 +1234,61 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct
fb_info *info)
EXPORT_SYMBOL(drm_fb_helper_setcmap);
/**
+ * drm_fb_helper_ioctl - legacy ioctl implementation
+ * @info: fbdev registered by the helper
+ * @cmd: ioctl command
+ * @arg: ioctl argument
+ *
+ * A helper to implement the standard fbdev ioctl. Only
+ * FBIO_WAITFORVSYNC is implemented for now.
+ */
+int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long
arg)
+{
+ struct drm_fb_helper *fb_helper = info->par;
+ struct drm_device *dev = fb_helper->dev;
+ unsigned int i;
+ int ret = 0;
+
+ drm_modeset_lock_all(dev);
+ if (!drm_fb_helper_is_bound(fb_helper)) {
+ drm_modeset_unlock_all(dev);
+ return -EBUSY;
+ }
+
+ switch (cmd) {
+ case FBIO_WAITFORVSYNC:
+ for (i = 0; i < fb_helper->crtc_count; i++) {
+ struct drm_mode_set *mode_set;
+ struct drm_crtc *crtc;
+
+ mode_set = &fb_helper->crtc_info[i].mode_set;
+ crtc = mode_set->crtc;
+
+ /*
+* Only call drm_crtc_wait_one_vblank for crtcs that
+* are currently enabled.
+*/
+ if (!crtc->enabled)
+ continue;
+
+ ret = drm_crtc_vblank_get(crtc);
+ if (!ret) {
+ drm_crtc_wait_one_vblank(crtc);
+ drm_crtc_vblank_put(crtc);
+ }
+ }
+ goto unlock;
+ default:
+ ret = -ENOTTY;
+ }
+
+unlock:
+ drm_modeset_unlock_all(dev);
+ return ret;
+}
+EXPORT_SYMBOL(drm_fb_helper_ioctl);
+
+/**
* drm_fb_helper_check_var - implementation for ->fb_check_var
* @var: screeninfo to check
* @info: fbdev registered by the helper
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 975deedd593e..460be9d9fa98 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -230,7 +230,8 @@ struct drm_fb_helper {
.fb_blank = drm_fb_helper_blank, \
.fb_pan_display = drm_fb_helper_pan_display, \
.fb_debug_enter = drm_fb_helper_debug_enter, \
- .fb_debug_leave = drm_fb_helper_debug_leave
+ .fb_debug_leave = drm_fb_helper_debug_leave, \
+ .fb_ioctl = drm_fb_helper_ioctl
#ifdef CONFIG_DRM_FBDEV_EMULATION
void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper
*helper,
@@ -286,6 +287,8 @@ void drm_fb_helper_set_suspend_unlocked(struct
drm_fb_helper *fb_helper,
int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info);
+int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long
arg);
+
int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper);
int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel);
int drm_fb_helper_single_add_all_connectors(struct drm_fb_helper *fb_helper);
--
git-series 0.8.11
[PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev
From: Xinliang Liu This patch add a config to support to create multi buffer for cma fbdev. Such as double buffer and triple buffer. Cma fbdev is convient to add a legency fbdev. And still many Android devices use fbdev now and at least double buffer is needed for these Android devices, so that a buffer flip can be operated. It will need some time for Android device vendors to abondon legency fbdev. So multi buffer for fbdev is needed. Signed-off-by: Xinliang Liu [s.chr...@phytec.de: Picking patch from https://lkml.org/lkml/2015/9/14/188] Signed-off-by: Stefan Christ Signed-off-by: Maxime Ripard --- drivers/gpu/drm/Kconfig | 8 drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++- 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index ebfe8404c25f..2ca9bb26a4e4 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER help Choose this if you need the KMS CMA helper functions +config DRM_CMA_FBDEV_BUFFER_NUM + int "Cma Fbdev Buffer Number" + depends on DRM_KMS_CMA_HELPER + default 1 + help + Defines the buffer number of cma fbdev. Default is one buffer. + For double buffer please set to 2 and 3 for triple buffer. + source "drivers/gpu/drm/i2c/Kconfig" source "drivers/gpu/drm/arm/Kconfig" diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c b/drivers/gpu/drm/drm_fb_cma_helper.c index 81b3558302b5..e3f8b9e720a0 100644 --- a/drivers/gpu/drm/drm_fb_cma_helper.c +++ b/drivers/gpu/drm/drm_fb_cma_helper.c @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info *fbi) kfree(fbi->fbops); } +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM; +module_param(fbdev_num_buffers, int, 0444); +MODULE_PARM_DESC(fbdev_num_buffers, +"Number of frame buffers to allocate [default=" +__MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]"); + /* * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function that * needs custom struct drm_framebuffer_funcs, like dirty() for deferred_io use. @@ -437,7 +443,7 @@ int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper, bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8); mode_cmd.width = sizes->surface_width; - mode_cmd.height = sizes->surface_height; + mode_cmd.height = sizes->surface_height * fbdev_num_buffers; mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel; mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp, sizes->surface_depth); -- git-series 0.8.11
Re: [PATCH v3 22/24] media: imx: Add MIPI CSI-2 OV5640 sensor subdev driver
Hi Steve,
Thank you for the patch. Many of the comments below apply to the ov5642 driver
too, please take them into account when reworking patch 23/24.
On Friday 06 Jan 2017 18:11:40 Steve Longerbeam wrote:
> This driver is based on ov5640_mipi.c from Freescale imx_3.10.17_1.0.0_beta
> branch, modified heavily to bring forward to latest interfaces and code
> cleanup.
>
> Signed-off-by: Steve Longerbeam
> ---
> drivers/staging/media/imx/Kconfig |8 +
> drivers/staging/media/imx/Makefile |2 +
> drivers/staging/media/imx/ov5640-mipi.c | 2348
You're missing DT bindings.
The driver should go to drivers/media/i2c/ as it should not be specific to the
i.MX6, and you can just call it ov5640.c.
> 3 files changed, 2358 insertions(+)
> create mode 100644 drivers/staging/media/imx/ov5640-mipi.c
>
> diff --git a/drivers/staging/media/imx/Kconfig
> b/drivers/staging/media/imx/Kconfig index ce2d2c8..09f373d 100644
> --- a/drivers/staging/media/imx/Kconfig
> +++ b/drivers/staging/media/imx/Kconfig
> @@ -17,5 +17,13 @@ config VIDEO_IMX_CAMERA
> ---help---
> A video4linux camera capture driver for i.MX5/6.
>
> +config IMX_OV5640_MIPI
> + tristate "OmniVision OV5640 MIPI CSI-2 camera support"
> + depends on GPIOLIB && VIDEO_IMX_CAMERA
The sensor driver is generic, it shouldn't depend on IMX. It should however
depend on at least I2C and OF by the look of it.
> + select IMX_MIPI_CSI2
> + default y
> + ---help---
> + MIPI CSI-2 OV5640 Camera support.
> +
> endmenu
> endif
[snip]
> diff --git a/drivers/staging/media/imx/ov5640-mipi.c
> b/drivers/staging/media/imx/ov5640-mipi.c new file mode 100644
> index 000..54647a7
> --- /dev/null
> +++ b/drivers/staging/media/imx/ov5640-mipi.c
> @@ -0,0 +1,2348 @@
> +/*
> + * Copyright (c) 2014 Mentor Graphics Inc.
> + * Copyright (C) 2011-2013 Freescale Semiconductor, Inc. All Rights
> Reserved.
> + *
> + * This program 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.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
Pet peeve of mine, please sort the headers alphabetically. It makes it easier
to locate duplicated.
> +
> +#define OV5640_VOLTAGE_ANALOG 280
> +#define OV5640_VOLTAGE_DIGITAL_CORE 150
> +#define OV5640_VOLTAGE_DIGITAL_IO 180
> +
> +#define MIN_FPS 15
> +#define MAX_FPS 30
> +#define DEFAULT_FPS 30
> +
> +/* min/typical/max system clock (xclk) frequencies */
> +#define OV5640_XCLK_MIN 600
> +#define OV5640_XCLK_TYP 2400
> +#define OV5640_XCLK_MAX 5400
> +
> +/* min/typical/max pixel clock (mclk) frequencies */
> +#define OV5640_MCLK_MIN 4800
> +#define OV5640_MCLK_TYP 4800
> +#define OV5640_MCLK_MAX 9600
> +
> +#define OV5640_CHIP_ID 0x300A
> +#define OV5640_SLAVE_ID 0x3100
> +#define OV5640_DEFAULT_SLAVE_ID 0x3c
You're mixing lower-case and upper-case hex constants. Let's pick one. Kernel
code usually favours lower-case.
Please define macros for all the other numerical constants you use in the
driver (register addresses and values). The large registers tables can be an
exception if you don't have access to the information, but for registers
written manually, hardcoding numerical values isn't good.
> +
> +#define OV5640_MAX_CONTROLS 64
> +
> +enum ov5640_mode {
> + ov5640_mode_MIN = 0,
> + ov5640_mode_QCIF_176_144 = 0,
> + ov5640_mode_QVGA_320_240,
> + ov5640_mode_VGA_640_480,
> + ov5640_mode_NTSC_720_480,
> + ov5640_mode_PAL_720_576,
> + ov5640_mode_XGA_1024_768,
> + ov5640_mode_720P_1280_720,
> + ov5640_mode_1080P_1920_1080,
> + ov5640_mode_QSXGA_2592_1944,
> + ov5640_num_modes,
> + ov5640_mode_INIT = 0xff, /*only for sensor init*/
Please add spaces after /* and before */.
Enumerated values should be all upper-case.
> +};
> +
> +enum ov5640_frame_rate {
> + ov5640_15_fps,
> + ov5640_30_fps
> +};
> +
> +static int ov5640_framerates[] = {
> + [ov5640_15_fps] = 15,
> + [ov5640_30_fps] = 30,
> +};
> +#define ov5640_num_framerates ARRAY_SIZE(ov5640_framerates)
> +
> +/* image size under 1280 * 960 are SUBSAMPLING
> + * image size upper 1280 * 960 are SCALING
> + */
The kernel multi-line comment style is
/*
* text
* text
*/
> +enum ov5640_downsize_mode {
> + SUBSAMPLING,
> + SCALING,
> +};
> +
> +struct reg_value {
> + u16 reg_addr;
> + u8 val;
> + u8 mask;
> + u32 delay_ms;
> +};
> +
> +struct ov5640_mode_info {
> + enum ov5640_mode mode;
> + enum ov5640_downsize_mode dn_mode;
> +
Re: [PATCH] staging: lustre: shut up clang warnings on CLASSERT()
On Thu, Feb 2, 2017 at 10:54 AM, Greg Kroah-Hartman
wrote:
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)
>
> Ugh, why not just use the in-kernel ASSERT macro instead?
We don't have one ;-)
I've done a semi-automated patch to replace CLASSERT() with the respective
BUILD_BUG_ON() now, but that patch is quite large.
Arnd
Re: [PATCH] staging: lustre: shut up clang warnings on CLASSERT()
On Thu, Feb 02, 2017 at 11:40:32AM +0100, Arnd Bergmann wrote:
> On Thu, Feb 2, 2017 at 10:54 AM, Greg Kroah-Hartman
> wrote:
> 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)
> >
> > Ugh, why not just use the in-kernel ASSERT macro instead?
>
> We don't have one ;-)
Oh nice!
> I've done a semi-automated patch to replace CLASSERT() with the respective
> BUILD_BUG_ON() now, but that patch is quite large.
Should be easy to script, I missed that this was a build-time check.
Heck, I'll take a script to do this, or I can just do it in my end.
thanks,
greg k-h
Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure
On Tue 31-01-17 14:32:08, Vinayak Menon wrote:
> During global reclaim, the nr_reclaimed passed to vmpressure
> includes the pages reclaimed from slab. But the corresponding
> scanned slab pages is not passed. This can cause total reclaimed
> pages to be greater than scanned, causing an unsigned underflow
> in vmpressure resulting in a critical event being sent to root
> cgroup. So do not consider reclaimed slab pages for vmpressure
> calculation. The reclaimed pages from slab can be excluded because
> the freeing of a page by slab shrinking depends on each slab's
> object population, making the cost model (i.e. scan:free) different
> from that of LRU.
This might be true but what happens if the slab reclaim contributes
significantly to the overal reclaim? This would be quite rare but not
impossible.
I am wondering why we cannot simply make cap nr_reclaimed to nr_scanned
and be done with this all? Sure it will be imprecise but the same will
be true with this approach.
> Also, not every shrinker accounts the pages it
> reclaims. This is a regression introduced by commit 6b4f7799c6a5
> ("mm: vmscan: invoke slab shrinkers from shrink_zone()").
We usually refer to the culprit comment as
Fixes: 6b4f7799c6a5 ("mm: vmscan: invoke slab shrinkers from shrink_zone()")
> Signed-off-by: Vinayak Menon
> ---
> mm/vmscan.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 947ab6f..8969f8e 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -2594,16 +2594,23 @@ static bool shrink_node(pg_data_t *pgdat, struct
> scan_control *sc)
> sc->nr_scanned - nr_scanned,
> node_lru_pages);
>
> + /*
> + * Record the subtree's reclaim efficiency. The reclaimed
> + * pages from slab is excluded here because the corresponding
> + * scanned pages is not accounted. Moreover, freeing a page
> + * by slab shrinking depends on each slab's object population,
> + * making the cost model (i.e. scan:free) different from that
> + * of LRU.
> + */
> + vmpressure(sc->gfp_mask, sc->target_mem_cgroup, true,
> +sc->nr_scanned - nr_scanned,
> +sc->nr_reclaimed - nr_reclaimed);
> +
> if (reclaim_state) {
> sc->nr_reclaimed += reclaim_state->reclaimed_slab;
> reclaim_state->reclaimed_slab = 0;
> }
>
> - /* Record the subtree's reclaim efficiency */
> - vmpressure(sc->gfp_mask, sc->target_mem_cgroup, true,
> -sc->nr_scanned - nr_scanned,
> -sc->nr_reclaimed - nr_reclaimed);
> -
> if (sc->nr_reclaimed - nr_reclaimed)
> reclaimable = true;
>
> --
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
> member of the Code Aurora Forum, hosted by The Linux Foundation
>
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/3] perf, pt, coresight: Clean up address filter structure
Mathieu Poirier writes: > Do we have two different syntax to specify the same behaviour? > > For example we have: > > --filter 'start 0x80082570/0x644' > > and > > --filter 'filter 0x80082570/0x644' > > Both will end up with filter->filter == 1 and filter->range == 1. This is another reason why enum action is needed. The difference between 'start' and 'filter' is that the former means "start tracing when you enter this region until something else stops it"; the latter means "trace only inside this region" (that is, start tracing when you branch inside this region and stop when you branch outside). They cannot be treated interchangeably as I originally though. PT supports 'filter', CS supports 'start', if I remember right. So we should make sure to -EOPNOTSUPP things that we don't actually support. Regards, -- Alex
Re: [PATCH 2/2] drm: meson: rename driver name to meson-drm
On Thu, Feb 02, 2017 at 10:47:44AM +0100, Neil Armstrong wrote:
> The platform driver name is currently "meson" which can lead to some
> confusion, this patch renames it to "meson-drm" and removes the owner
> attribute.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/gpu/drm/meson/meson_drv.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index ff1f601..380bde7 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -329,8 +329,7 @@ static int meson_drv_remove(struct platform_device *pdev)
> .probe = meson_drv_probe,
> .remove = meson_drv_remove,
> .driver = {
> - .owner = THIS_MODULE,
I don't get why you remove this, generally that will lead to trouble of
being able to unload code that's still in use ...
Otherwise ack.
Now, do you want to get this landed as part of the small drivers in
drm-mis experiment?
-Daniel
> - .name = DRIVER_NAME,
> + .name = "meson-drm",
> .of_match_table = dt_match,
> },
> };
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen
On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote:
> Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> disposable private objects") introduced a regression for the kernel
> running as Xen dom0: when switching to graphics mode a GPU HANG
> occurred.
>
> Reason seems to be a missing adaption similar to that done in
> commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
> to i915_gem_object_get_pages_internal().
>
> So limit the maximum page order to be used according to the maximum
> swiotlb segment size instead to the complete swiotlb size.
>
> Signed-off-by: Juergen Gross
Fixes: 920cf4194954 ("drm/i915: Introduce an internal allocator for disposable
private objects")
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: intel-...@lists.freedesktop.org
Cc: # v4.10-rc1+
We have a nice script for these :-)
-Daniel
> ---
> Please consider for 4.10 as otherwise 4.10 will be unusable as Xen dom0
> with i915 graphics.
> ---
> drivers/gpu/drm/i915/i915_gem_internal.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_internal.c
> b/drivers/gpu/drm/i915/i915_gem_internal.c
> index 4b3ff3e..d09c749 100644
> --- a/drivers/gpu/drm/i915/i915_gem_internal.c
> +++ b/drivers/gpu/drm/i915/i915_gem_internal.c
> @@ -66,8 +66,16 @@ i915_gem_object_get_pages_internal(struct
> drm_i915_gem_object *obj)
>
> max_order = MAX_ORDER;
> #ifdef CONFIG_SWIOTLB
> - if (swiotlb_nr_tbl()) /* minimum max swiotlb size is IO_TLB_SEGSIZE */
> - max_order = min(max_order, ilog2(IO_TLB_SEGPAGES));
> + if (swiotlb_nr_tbl()) {
> + unsigned int max_segment;
> +
> + max_segment = swiotlb_max_segment();
> + if (max_segment) {
> + max_segment = max_t(unsigned int, max_segment,
> + PAGE_SIZE) >> PAGE_SHIFT;
> + max_order = min(max_order, ilog2(max_segment));
> + }
> + }
> #endif
>
> gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
> --
> 2.10.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [PATCH 1/2 v3] mm: vmscan: do not pass reclaimed slab to vmpressure
On Thu 02-02-17 11:44:22, Michal Hocko wrote: > On Tue 31-01-17 14:32:08, Vinayak Menon wrote: > > During global reclaim, the nr_reclaimed passed to vmpressure > > includes the pages reclaimed from slab. But the corresponding > > scanned slab pages is not passed. This can cause total reclaimed > > pages to be greater than scanned, causing an unsigned underflow > > in vmpressure resulting in a critical event being sent to root > > cgroup. So do not consider reclaimed slab pages for vmpressure > > calculation. The reclaimed pages from slab can be excluded because > > the freeing of a page by slab shrinking depends on each slab's > > object population, making the cost model (i.e. scan:free) different > > from that of LRU. > > This might be true but what happens if the slab reclaim contributes > significantly to the overal reclaim? This would be quite rare but not > impossible. > > I am wondering why we cannot simply make cap nr_reclaimed to nr_scanned > and be done with this all? Sure it will be imprecise but the same will > be true with this approach. In other words something as "beautiful" as the following: diff --git a/mm/vmpressure.c b/mm/vmpressure.c index 149fdf6c5c56..abea42817dd0 100644 --- a/mm/vmpressure.c +++ b/mm/vmpressure.c @@ -236,6 +236,15 @@ void vmpressure(gfp_t gfp, struct mem_cgroup *memcg, bool tree, return; /* +* Due to accounting issues - e.g. THP contributing 1 to scanned but +* potentially much more to reclaimed or SLAB pages not contributing +* to scanned at all - we have to skew reclaimed to prevent from +* wrong pressure levels due to overflows. +*/ + if (reclaimed > scanned) + reclaimed = scanned; + + /* * If we got here with no pages scanned, then that is an indicator * that reclaimer was unable to find any shrinkable LRUs at the * current scanning depth. But it does not mean that we should -- Michal Hocko SUSE Labs
Re: [PATCH 2/2] drm: meson: rename driver name to meson-drm
On 02/02/2017 11:45 AM, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 10:47:44AM +0100, Neil Armstrong wrote:
>> The platform driver name is currently "meson" which can lead to some
>> confusion, this patch renames it to "meson-drm" and removes the owner
>> attribute.
>>
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_drv.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_drv.c
>> b/drivers/gpu/drm/meson/meson_drv.c
>> index ff1f601..380bde7 100644
>> --- a/drivers/gpu/drm/meson/meson_drv.c
>> +++ b/drivers/gpu/drm/meson/meson_drv.c
>> @@ -329,8 +329,7 @@ static int meson_drv_remove(struct platform_device *pdev)
>> .probe = meson_drv_probe,
>> .remove = meson_drv_remove,
>> .driver = {
>> -.owner = THIS_MODULE,
Hi Daniel,
> I don't get why you remove this, generally that will lead to trouble of
> being able to unload code that's still in use ...
Indeed, but since a (long ?) time, the owner field is now populated by the
platform_driver_register() core code.
>
> Otherwise ack.
>
> Now, do you want to get this landed as part of the small drivers in
> drm-mis experiment?
I have a PR ready, but it can go through this experiment, yes.
> -Daniel
>
>> -.name = DRIVER_NAME,
>> +.name = "meson-drm",
>> .of_match_table = dt_match,
>> },
>> };
>> --
Thanks,
Neil
Re: [PATCH 1/2] gpio: Rename devm_get_gpiod_from_child()
On Mon, Jan 30, 2017 at 4:41 PM, Boris Brezillon wrote: > Rename devm_get_gpiod_from_child() into > devm_fwnode_get_gpiod_from_child() to reflect the fact that this > function is operating on a fwnode object. > > Signed-off-by: Boris Brezillon All right! So we settled we're gonna merge this and the other patch and we have the necessary ACKs. This is unfortunately not applying because I have a bunch of other patches touching the same files (that's why I think it's a good opportunity to rename it now, as mentioned IIRC). Could you rebase this on the following branch: https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-gpio.git/log/?h=ib-gpiod-flags Then I will apply it on top of that immutable branch and pull it into the devel branch of gpio so that we get it in and also have an immutable branch with all changes if some other subsystem maintainer needs it because of clashes. Yours, Linus Walleij
Re: [Intel-gfx] [PATCH] drm/i915: fix i915 running as dom0 under Xen
On Thu, Feb 02, 2017 at 11:48:21AM +0100, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 10:47:11AM +0100, Juergen Gross wrote:
> > Commit 920cf4194954ec ("drm/i915: Introduce an internal allocator for
> > disposable private objects") introduced a regression for the kernel
> > running as Xen dom0: when switching to graphics mode a GPU HANG
> > occurred.
> >
> > Reason seems to be a missing adaption similar to that done in
> > commit 7453c549f5f648 ("swiotlb: Export swiotlb_max_segment to users")
> > to i915_gem_object_get_pages_internal().
> >
> > So limit the maximum page order to be used according to the maximum
> > swiotlb segment size instead to the complete swiotlb size.
> >
> > Signed-off-by: Juergen Gross
> Fixes: 920cf4194954 ("drm/i915: Introduce an internal allocator for
> disposable private objects")
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: intel-...@lists.freedesktop.org
> Cc: # v4.10-rc1+
>
> We have a nice script for these :-)
Pffifle. 7453c549f5f648 allowed Xen to change it and silently conflicted
with those that already used the previous limits, which didn't land in
our tree until v4.10-rc3.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Re: ibmvtpm byteswapping inconsistency
Vicky writes: >> 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; ... 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 The type of word is basically irrelevant. Unless you're running sparse and actually checking the errors, which it seems you're not doing: drivers/char/tpm/tpm_ibmvtpm.c:90:30: warning: cast removes address space of expression drivers/char/tpm/tpm_ibmvtpm.c:91:23: warning: incorrect type in argument 1 (different address spaces) drivers/char/tpm/tpm_ibmvtpm.c:91:23:expected void * drivers/char/tpm/tpm_ibmvtpm.c:91:23:got void [noderef] *rtce_buf drivers/char/tpm/tpm_ibmvtpm.c:136:17: warning: cast removes address space of expression drivers/char/tpm/tpm_ibmvtpm.c:188:46: warning: incorrect type in argument 2 (different base types) drivers/char/tpm/tpm_ibmvtpm.c:188:46:expected unsigned long long [unsigned] [usertype] w1 drivers/char/tpm/tpm_ibmvtpm.c:188:46:got restricted __be64 [usertype] drivers/char/tpm/tpm_ibmvtpm.c:189:31: warning: incorrect type in argument 3 (different base types) drivers/char/tpm/tpm_ibmvtpm.c:189:31:expected unsigned long long [unsigned] [usertype] w2 drivers/char/tpm/tpm_ibmvtpm.c:189:31:got restricted __be64 [usertype] drivers/char/tpm/tpm_ibmvtpm.c:215:46: warning: incorrect type in argument 2 (different base types) drivers/char/tpm/tpm_ibmvtpm.c:215:46:expected unsigned long long [unsigned] [usertype] w1 drivers/char/tpm/tpm_ibmvtpm.c:215:46:got restricted __be64 [usertype] drivers/char/tpm/tpm_ibmvtpm.c:216:31: warning: incorrect type in argument 3 (different base types) drivers/char/tpm/tpm_ibmvtpm.c:216:31:expected unsigned long long [unsigned] [usertype] w2 drivers/char/tpm/tpm_ibmvtpm.c:216:31:got restricted __be64 [usertype] drivers/char/tpm/tpm_ibmvtpm.c:294:30: warning: incorrect type in argument 1 (different address spaces) drivers/char/tpm/tpm_ibmvtpm.c:294:30:expected void const * drivers/char/tpm/tpm_ibmvtpm.c:294:30:got void [noderef] *rtce_buf drivers/char/tpm/tpm_ibmvtpm.c:342:46: warning: incorrect type in argument 2 (different base types) drivers/char/tpm/tpm_ibmvtpm.c:342:46:expected unsigned long long [unsigned] [usertype] w1 drivers/char/tpm/tpm_ibmvtpm.c:342:46:got restricted __be64 [usertype] drivers/char/tpm/tpm_ibmvtpm.c:343:31: warning: incorrect type in argument 3 (different base types) drivers/char/tpm/tpm_ibmvtpm.c:343:31:expected unsigned long long [unsigned] [usertype] w2 drivers/char/tpm/tpm_ibmvtpm.c:343:31:got restricted __be64 [usertype] drivers/char/tpm/tpm_ibmvtpm.c:494:43: warning: incorrect type in assignment (different address spaces) drivers/char/tpm/tpm_ibmvtpm.c:494:43:expected void [noderef] *rtce_buf drivers/char/tpm/tpm_ibmvtpm.c:494:43:got void * drivers/char/tpm/tpm_ibmvtpm.c:501:52: warning: incorrect type in argument 2 (different address spaces) drivers/char/tpm/tpm_ibmvtpm.c:501:52:expected void *ptr drivers/char/tpm/tpm_ibmvtpm.c:501:52:got void [noderef] *rtce_buf drivers/char/tpm/tpm_ibmvtpm.c:507:46: warning: incorrect type in argument 1 (different address spaces) drivers/char/tpm/tpm_ibmvtpm.c:507:46:expected void const * drivers/char/tpm/tpm_ibmvtpm.c:507:46:got void [noderef] *rtce_buf What matters is how you actually do the byte swaps. cheers
Re: [PATCH v3 0/2] iov_iter: allow iov_iter_get_pages_alloc to allocate more pages per call
On Thu, Feb 02, 2017 at 09:51:25AM +, Al Viro wrote: > On Wed, Jan 25, 2017 at 08:32:03AM -0500, Jeff Layton wrote: > > Small respin of the patch that I sent yesterday for the same thing. > > > > This moves the maxsize handling into iov_iter_pvec_size, so that we don't > > end up iterating past the max size we'll use anyway when trying to > > determine the pagevec length. > > > > Also, a respun patch to make ceph use iov_iter_get_pages_alloc instead of > > trying to do it via its own routine. > > > > Al, if these look ok, do you want to pick these up or shall I ask > > Ilya to merge them via the ceph tree? > > I'd rather have that kind of work go through the vfs tree; said that, > I really wonder if this is the right approach. Most of the users of > iov_iter_get_pages()/iov_iter_get_pages_alloc() look like they want > something like > iov_iter_for_each_page(iter, size, f, data) > with int (*f)(struct page *page, size_t from, size_t size, void *data) > passed as callback. Not everything fits that model, but there's a whole > lot of things that do. I was planning to do that, mostly because of the iomap dio code that would not only get a lot cleaner with this, but also support multi-page bvecs that we hope to have in the block layer soon. The issue with it is that we need to touch all the arch get_user_pages_fast implementations, so it's going to be a relatively invasive change that I didn't want to fix with just introducing the new direct I/O code.
Re: crypto: NULL deref in sha512_mb_mgr_get_comp_job_avx2
On Wed, Feb 1, 2017 at 7:45 PM, Tim Chen wrote: > On Tue, Jan 31, 2017 at 02:16:31PM +0100, Dmitry Vyukov wrote: >> Hello, >> >> I am getting the following reports with low frequency while running >> syzkaller fuzzer. Unfortunately they are not reproducible and happen >> in a background thread, so it is difficult to extract any context on >> my side. I see only few such crashes per week, so most likely it is >> some hard to trigger data race. The following reports are from mmotm >> tree, commits 00e20cfc2bf04a0cbe1f5405f61c8426f43eee84 and >> fff7e71eac7788904753136f09bcad7471f7799e. Any ideas as to how this can >> happen? >> >> BUG: unable to handle kernel NULL pointer dereference at 0060 >> IP: [] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee >> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251 >> PGD 1d2395067 [ 220.874864] PUD 1d2860067 >> Oops: 0002 [#1] SMP KASAN >> Dumping ftrace buffer: >>(ftrace buffer empty) >> Modules linked in: >> CPU: 0 PID: 516 Comm: kworker/0:1 Not tainted 4.9.0 #4 >> Hardware name: Google Google Compute Engine/Google Compute Engine, >> BIOS Google 01/01/2011 >> Workqueue: crypto mcryptd_queue_worker >> task: 8801d9f346c0 task.stack: 8801d9f08000 >> RIP: 0010:[] [] >> sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee >> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251 >> RSP: 0018:8801d9f0eef8 EFLAGS: 00010202 >> RAX: RBX: 8801d7db1190 RCX: 0006 >> RDX: 0001 RSI: 8801d9f34ee8 RDI: 8801d7db1040 >> RBP: 8801d9f0f258 R08: 0001 R09: 0001 >> R10: 0002 R11: 0003 R12: 8801d9f0f230 >> R13: 8801c8bbc4e0 R14: 8801c8bbc530 R15: 8801d9f0ef70 >> FS: () GS:8801dc00() knlGS: >> CS: 0010 DS: ES: CR0: 80050033 >> CR2: 0060 CR3: 0001cc15a000 CR4: 001406f0 >> DR0: DR1: DR2: >> DR3: DR6: fffe0ff0 DR7: 0400 >> Stack: >> 8801d7db1040 813fa207 dc00 e8c0f238 >> 0002 11003b3e1dea e8c0f218 8801d9f0f190 >> 0282 e8c0f140 e8c0f220 41b58ab3 >> Call Trace: >> [] sha512_mb_update+0x2f7/0x4e0 >> arch/x86/crypto/sha512-mb/sha512_mb.c:588 >> [] crypto_ahash_update include/crypto/hash.h:512 [inline] >> [] ahash_mcryptd_update crypto/mcryptd.c:627 [inline] >> [] mcryptd_hash_update+0xcd/0x1c0 crypto/mcryptd.c:373 >> [] mcryptd_queue_worker+0xff/0x6a0 crypto/mcryptd.c:181 >> [] process_one_work+0xbd0/0x1c10 kernel/workqueue.c:2096 >> [] worker_thread+0x223/0x1990 kernel/workqueue.c:2230 >> [] kthread+0x323/0x3e0 kernel/kthread.c:209 >> [] ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:433 >> Code: 49 0f 42 d3 48 f7 c2 f0 ff ff ff 0f 85 9a 00 00 00 48 83 e2 0f >> 48 6b da 08 48 8d 9c 1f 48 01 00 00 48 8b 03 48 c7 03 00 00 00 00 >> 40 60 02 00 00 00 48 8b 9f 40 01 00 00 48 c1 e3 08 48 09 d3 >> RIP [] sha512_mb_mgr_get_comp_job_avx2+0x6e/0xee >> arch/x86/crypto/sha512-mb/sha512_mb_mgr_flush_avx2.S:251 >> RSP >> CR2: 0060 >> ---[ end trace 139fd4cda5dfe2c4 ]--- >> > > Dmitry, > > One theory that Mehga and I have is that perhaps the flusher > and regular computaion updates are stepping on each other. > Can you try this patch and see if it helps? No, for this one I can't. Sorry. It happens with very low frequency and only one fuzzer that tests mmotm tree. If/when this is committed, I can keep an eye on these reports and notify if I still see them. If you have a hypothesis as to how it happens, perhaps you could write a test that provokes the crash and maybe add some sleeps to kernel code or alter timeouts to increase probability. > --->8--- > > From: Tim Chen > Subject: [PATCH] crypto/sha512-mb: Protect sha512 mb ctx mgr access > To: Herbert Xu , Dmitry Vyukov > > Cc: Tim Chen , David Miller > , linux-cry...@vger.kernel.org, LKML > , megha@linux.intel.com, > fenghua...@intel.com > > The flusher and regular multi-buffer computation via mcryptd may race with > another. > Add here a lock and turn off interrupt to to access multi-buffer > computation state cstate->mgr before a round of computation. This should > prevent the flusher code jumping in. > > Signed-off-by: Tim Chen > --- > arch/x86/crypto/sha512-mb/sha512_mb.c | 64 > +++ > 1 file changed, 42 insertions(+), 22 deletions(-) > > diff --git a/arch/x86/crypto/sha512-mb/sha512_mb.c > b/arch/x86/crypto/sha512-mb/sha512_mb.c > index d210174..f3c1c21 100644 > --- a/arch/x86/crypto/sha512-mb/sha512_mb.c > +++ b/arch/x86/crypto/sha512-mb/sha512_mb.c > @@ -221,7 +221,7 @@ static struct sha512_hash_ctx *sha512_ctx_mgr_resubmit > } > > static struct sha512_hash_ctx > - *sha512_ctx_mgr_get_comp_ctx(struct sha512_ctx_mgr *mgr) > + *sha512_ct
[PATCH 1/5] perf/sdt: Show proper hint
All events from 'perf list', except SDT events, can be directly
recorded with 'perf record'. But, the flow is little different
for SDT events. User has to probe on SDT events before recording
them. Perf is showing misleading message when user tries to
record SDT event without probing it. Show proper hint there.
Before patch:
$ perf record -a -e sdt_glib:idle__add
event syntax error: 'sdt_glib:idle__add'
\___ unknown tracepoint
Error: File /sys/kernel/debug/tracing/events/sdt_glib/idle__add ...
Hint: Perhaps this kernel misses some CONFIG_ setting to enable...
...
After patch:
$ perf record -e sdt_glib:main__after_check
event syntax error: 'sdt_glib:idle__add'
\___ unknown tracepoint
Error: File /sys/kernel/debug/tracing/events/sdt_glib/idle__add ...
Hint: SDT event has to be probed before recording it.
Suggested-by: Ingo Molnar
Signed-off-by: Ravi Bangoria
---
tools/lib/api/fs/tracing_path.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/tools/lib/api/fs/tracing_path.c b/tools/lib/api/fs/tracing_path.c
index 251b7c3..a0e85df 100644
--- a/tools/lib/api/fs/tracing_path.c
+++ b/tools/lib/api/fs/tracing_path.c
@@ -99,10 +99,18 @@ static int strerror_open(int err, char *buf, size_t size,
const char *filename)
* - jirka
*/
if (debugfs__configured() || tracefs__configured()) {
- snprintf(buf, size,
-"Error:\tFile %s/%s not found.\n"
-"Hint:\tPerhaps this kernel misses some
CONFIG_ setting to enable this feature?.\n",
-tracing_events_path, filename);
+ /* sdt markers */
+ if (!strncmp(filename, "sdt_", 4)) {
+ snprintf(buf, size,
+ "Error:\tFile %s/%s not found.\n"
+ "Hint:\tSDT event has to be probed
before recording it.\n",
+ tracing_events_path, filename);
+ } else {
+ snprintf(buf, size,
+"Error:\tFile %s/%s not found.\n"
+"Hint:\tPerhaps this kernel misses
some CONFIG_ setting to enable this feature?.\n",
+tracing_events_path, filename);
+ }
break;
}
snprintf(buf, size, "%s",
--
2.9.3
