* Re: [PATCH 12/12] [PROBABLY WRONG] s390: void '0' constraint in inline assembly
From: Martin Schwidefsky @ 2019-04-10 13:55 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Heiko Carstens, clang-built-linux, Nick Desaulniers,
Nathan Chancellor, linux-s390, Vasily Gorbik, linux-kernel
In-Reply-To: <20190408212648.2407234-12-arnd@arndb.de>
On Mon, 8 Apr 2019 23:26:25 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> clang does not understand the contraint "0" in the CALL_ON_STACK()
> macro:
>
> ../arch/s390/mm/maccess.c:117:10: error: invalid input constraint '0' in asm
> return CALL_ON_STACK(_memcpy_real, S390_lowcore.nodat_stack,
> ^
> ../arch/s390/include/asm/processor.h:292:20: note: expanded from macro 'CALL_ON_STACK'
> [_fn] "X" (fn) CALL_FMT_##nr : CALL_CLOBBER_##nr); \
> ^
> <scratch space>:207:1: note: expanded from here
> CALL_FMT_3
> ^
> ../arch/s390/include/asm/processor.h:267:20: note: expanded from macro 'CALL_FMT_3'
> #define CALL_FMT_3 CALL_FMT_2, "d" (r4)
> ^
> ../arch/s390/include/asm/processor.h:266:20: note: expanded from macro 'CALL_FMT_2'
> #define CALL_FMT_2 CALL_FMT_1, "d" (r3)
> ^
> ../arch/s390/include/asm/processor.h:265:32: note: expanded from macro 'CALL_FMT_1'
> #define CALL_FMT_1 CALL_FMT_0, "0" (r2)
> ^
>
> I don't know what the correct fix here would be, changing it to "d" made
> it build, since clang does understand this one.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/s390/include/asm/processor.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h
> index 700c650ffd4f..84c59c99668a 100644
> --- a/arch/s390/include/asm/processor.h
> +++ b/arch/s390/include/asm/processor.h
> @@ -262,7 +262,7 @@ static __no_kasan_or_inline unsigned short stap(void)
> register unsigned long r4 asm("6") = (unsigned long)(arg5)
>
> #define CALL_FMT_0
> -#define CALL_FMT_1 CALL_FMT_0, "0" (r2)
> +#define CALL_FMT_1 CALL_FMT_0, "d" (r2)
> #define CALL_FMT_2 CALL_FMT_1, "d" (r3)
> #define CALL_FMT_3 CALL_FMT_2, "d" (r4)
> #define CALL_FMT_4 CALL_FMT_3, "d" (r5)
This is (slightly) wrong. %r2 is used as the input register for the first argument
and the result value for the call. With your patch you force the compiler to load
the first argument in two registers. One solution would be to CALL_FMT1 as
#define CALL_FMT1 CALL_FMT_0
It still is not optimal though as for CALL_FMT_0 the "+&d" (r2) indicates an
input but CALL_ARGS_0 does not initialize r2.
I am thinking about the following patch to cover all cases:
--
From 91a4abbec91a9f26f84f7386f2c0f96de669b0eb Mon Sep 17 00:00:00 2001
From: Martin Schwidefsky <schwidefsky@de.ibm.com>
Date: Wed, 10 Apr 2019 15:48:43 +0200
Subject: [PATCH] s390: fine-tune stack switch helper
The CALL_ON_STACK helper currently does not work with clang and for
calls without arguments it does not initialize r2 although the contraint
is "+&d". Rework the CALL_FMT_x and the CALL_ON_STACK macros to work
with clang and produce optimal code in all cases.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
---
arch/s390/include/asm/processor.h | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/s390/include/asm/processor.h b/arch/s390/include/asm/processor.h
index 81038ab357ce..0ee022247580 100644
--- a/arch/s390/include/asm/processor.h
+++ b/arch/s390/include/asm/processor.h
@@ -261,12 +261,12 @@ static __no_kasan_or_inline unsigned short stap(void)
CALL_ARGS_4(arg1, arg2, arg3, arg4); \
register unsigned long r4 asm("6") = (unsigned long)(arg5)
-#define CALL_FMT_0
-#define CALL_FMT_1 CALL_FMT_0, "0" (r2)
-#define CALL_FMT_2 CALL_FMT_1, "d" (r3)
-#define CALL_FMT_3 CALL_FMT_2, "d" (r4)
-#define CALL_FMT_4 CALL_FMT_3, "d" (r5)
-#define CALL_FMT_5 CALL_FMT_4, "d" (r6)
+#define CALL_FMT_0 "=&d" (r2) :
+#define CALL_FMT_1 "+&d" (r2) :
+#define CALL_FMT_2 CALL_FMT_1 "d" (r3),
+#define CALL_FMT_3 CALL_FMT_2 "d" (r4),
+#define CALL_FMT_4 CALL_FMT_3 "d" (r5),
+#define CALL_FMT_5 CALL_FMT_4 "d" (r6),
#define CALL_CLOBBER_5 "0", "1", "14", "cc", "memory"
#define CALL_CLOBBER_4 CALL_CLOBBER_5
@@ -286,10 +286,10 @@ static __no_kasan_or_inline unsigned short stap(void)
" stg %[_prev],%[_bc](15)\n" \
" brasl 14,%[_fn]\n" \
" la 15,0(%[_prev])\n" \
- : "+&d" (r2), [_prev] "=&a" (prev) \
- : [_stack] "a" (stack), \
+ : [_prev] "=&a" (prev), CALL_FMT_##nr \
+ [_stack] "a" (stack), \
[_bc] "i" (offsetof(struct stack_frame, back_chain)), \
- [_fn] "X" (fn) CALL_FMT_##nr : CALL_CLOBBER_##nr); \
+ [_fn] "X" (fn) : CALL_CLOBBER_##nr); \
r2; \
})
--
2.16.4
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply related
* Re: [PATCH BUGFIX V2] block, bfq: fix use after free in bfq_bfqq_expire
From: Jens Axboe @ 2019-04-10 13:55 UTC (permalink / raw)
To: Paolo Valente
Cc: linux-block, linux-kernel, ulf.hansson, linus.walleij, broonie,
bfq-iosched, oleksandr, Dmitrii Tcvetkov, Douglas Anderson
In-Reply-To: <20190410083833.14462-1-paolo.valente@linaro.org>
On 4/10/19 2:38 AM, Paolo Valente wrote:
> The function bfq_bfqq_expire() invokes the function
> __bfq_bfqq_expire(), and the latter may free the in-service bfq-queue.
> If this happens, then no other instruction of bfq_bfqq_expire() must
> be executed, or a use-after-free will occur.
>
> Basing on the assumption that __bfq_bfqq_expire() invokes
> bfq_put_queue() on the in-service bfq-queue exactly once, the queue is
> assumed to be freed if its refcounter is equal to one right before
> invoking __bfq_bfqq_expire().
>
> But, since commit 9dee8b3b057e ("block, bfq: fix queue removal from
> weights tree") this assumption is false. __bfq_bfqq_expire() may also
> invoke bfq_weights_tree_remove() and, since commit 9dee8b3b057e
> ("block, bfq: fix queue removal from weights tree"), also
> the latter function may invoke bfq_put_queue(). So __bfq_bfqq_expire()
> may invoke bfq_put_queue() twice, and this is the actual case where
> the in-service queue may happen to be freed.
>
> To address this issue, this commit moves the check on the refcounter
> of the queue right around the last bfq_put_queue() that may be invoked
> on the queue.
Applied, thanks.
--
Jens Axboe
^ permalink raw reply
* [PATCH] tpm/tpm_crb: Avoid unaligned reads in crb_recv()
From: Jarkko Sakkinen @ 2019-04-10 13:54 UTC (permalink / raw)
To: stable; +Cc: Jarkko Sakkinen, James Morris, Tomas Winkler, Jerry Snitselaar
commit 3d7a850fdc1a2e4d2adbc95cc0fc962974725e88 upstream
The current approach to read first 6 bytes from the response and then tail
of the response, can cause the 2nd memcpy_fromio() to do an unaligned read
(e.g. read 32-bit word from address aligned to a 16-bits), depending on how
memcpy_fromio() is implemented. If this happens, the read will fail and the
memory controller will fill the read with 1's.
This was triggered by 170d13ca3a2f, which should be probably refined to
check and react to the address alignment. Before that commit, on x86
memcpy_fromio() turned out to be memcpy(). By a luck GCC has done the right
thing (from tpm_crb's perspective) for us so far, but we should not rely on
that. Thus, it makes sense to fix this also in tpm_crb, not least because
the fix can be then backported to stable kernels and make them more robust
when compiled in differing environments.
Cc: stable@vger.kernel.org
Cc: James Morris <jmorris@namei.org>
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Jerry Snitselaar <jsnitsel@redhat.com>
Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
---
backport v4.4.178
drivers/char/tpm/tpm_crb.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/char/tpm/tpm_crb.c b/drivers/char/tpm/tpm_crb.c
index 35308dfff754..8226e3b6dc1f 100644
--- a/drivers/char/tpm/tpm_crb.c
+++ b/drivers/char/tpm/tpm_crb.c
@@ -109,19 +109,29 @@ static int crb_recv(struct tpm_chip *chip, u8 *buf, size_t count)
struct crb_priv *priv = chip->vendor.priv;
unsigned int expected;
- /* sanity check */
- if (count < 6)
+ /* A sanity check that the upper layer wants to get at least the header
+ * as that is the minimum size for any TPM response.
+ */
+ if (count < TPM_HEADER_SIZE)
return -EIO;
+ /* If this bit is set, according to the spec, the TPM is in
+ * unrecoverable condition.
+ */
if (le32_to_cpu(ioread32(&priv->cca->sts)) & CRB_CA_STS_ERROR)
return -EIO;
- memcpy_fromio(buf, priv->rsp, 6);
- expected = be32_to_cpup((__be32 *) &buf[2]);
- if (expected > count || expected < 6)
+ /* Read the first 8 bytes in order to get the length of the response.
+ * We read exactly a quad word in order to make sure that the remaining
+ * reads will be aligned.
+ */
+ memcpy_fromio(buf, priv->rsp, 8);
+
+ expected = be32_to_cpup((__be32 *)&buf[2]);
+ if (expected > count || expected < TPM_HEADER_SIZE)
return -EIO;
- memcpy_fromio(&buf[6], &priv->rsp[6], expected - 6);
+ memcpy_fromio(&buf[8], &priv->rsp[8], expected - 8);
return expected;
}
--
2.19.1
^ permalink raw reply related
* Re: [PATCH] ARM: dts: stm32: add power supply of otm8009a on stm32mp157c-dk2
From: Alexandre Torgue @ 2019-04-10 13:54 UTC (permalink / raw)
To: Yannick Fertré, Maxime Coquelin, Rob Herring, Mark Rutland,
linux-stm32, linux-arm-kernel, devicetree, linux-kernel,
Benjamin Gaignard, Philippe Cornu
In-Reply-To: <1553854406-28992-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 3/29/19 11:13 AM, Yannick Fertré wrote:
> This patch adds a new property (power-supply) to panel otm8009a (orisetech)
> on stm32mp157c-dk2 & regulator v3v3 which is always set on until the
> implementation of regulator driver.
>
> Signed-off-by: Yannick Fertré <yannick.fertre@st.com>
> ---
> arch/arm/boot/dts/stm32mp157c-dk2.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/stm32mp157c-dk2.dts b/arch/arm/boot/dts/stm32mp157c-dk2.dts
> index 363aeb9..20ea601 100644
> --- a/arch/arm/boot/dts/stm32mp157c-dk2.dts
> +++ b/arch/arm/boot/dts/stm32mp157c-dk2.dts
> @@ -50,6 +50,7 @@
> compatible = "orisetech,otm8009a";
> reg = <0>;
> reset-gpios = <&gpioe 4 GPIO_ACTIVE_LOW>;
> + power-supply = <&v3v3>;
> status = "okay";
>
> port {
>
Applied on stm32-next. I just updated the commit message as regulator
fixed hook is no more used due to stpmic1 merge.
Thanks.
Alex
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 1/2] acl: remove use of weak functions
From: Aaron Conole @ 2019-04-10 13:54 UTC (permalink / raw)
To: Bruce Richardson; +Cc: konstantin.ananyev, dev
In-Reply-To: <20190410134517.63896-2-bruce.richardson@intel.com>
Bruce Richardson <bruce.richardson@intel.com> writes:
> Weak functions don't work well with static libraries and require the use of
> "whole-archive" flag to ensure that the correct function is used when
> linking. Since the weak functions are only used as placeholders within
> this library alone, we can replace them with non-weak functions using
> preprocessor ifdefs.
>
> Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> ---
> lib/librte_acl/meson.build | 7 ++++++-
> lib/librte_acl/rte_acl.c | 18 ++++++++++++++----
> mk/rte.app.mk | 3 ---
> 3 files changed, 20 insertions(+), 8 deletions(-)
>
> diff --git a/lib/librte_acl/meson.build b/lib/librte_acl/meson.build
> index 2207dbafe..98ece7d85 100644
> --- a/lib/librte_acl/meson.build
> +++ b/lib/librte_acl/meson.build
> @@ -6,7 +6,7 @@ sources = files('acl_bld.c', 'acl_gen.c', 'acl_run_scalar.c',
> 'rte_acl.c', 'tb_mem.c')
> headers = files('rte_acl.h', 'rte_acl_osdep.h')
>
> -if arch_subdir == 'x86'
> +if dpdk_conf.has('RTE_ARCH_X86')
> sources += files('acl_run_sse.c')
>
> # compile AVX2 version if either:
> @@ -28,4 +28,9 @@ if arch_subdir == 'x86'
> cflags += '-DCC_AVX2_SUPPORT'
> endif
>
> +elif dpdk_conf.has('RTE_ARCH_ARM') or dpdk_conf.has('RTE_ARCH_ARM64')
> + cflags += '-flax-vector-conversions'
> + sources += files('acl_run_neon.c')
This will also need -Wno-uninitialized (otherwise it will generate
warnings about the search_neon_4 and search_neon_8 functions).
But I don't like papering over these conversions. I'd prefer instead
the patches I posted at:
http://mails.dpdk.org/archives/dev/2019-April/129540.html
and
http://mails.dpdk.org/archives/dev/2019-April/129541.html
Are you opposed to merging those?
> +elif dpdk_conf.has('RTE_ARCH_PPC_64')
> + sources += files('acl_run_altivec.c')
> endif
> diff --git a/lib/librte_acl/rte_acl.c b/lib/librte_acl/rte_acl.c
> index c436a9bfd..fd5bd5e4e 100644
> --- a/lib/librte_acl/rte_acl.c
> +++ b/lib/librte_acl/rte_acl.c
> @@ -13,11 +13,13 @@ static struct rte_tailq_elem rte_acl_tailq = {
> };
> EAL_REGISTER_TAILQ(rte_acl_tailq)
>
> +#ifndef RTE_ARCH_X86
> +#ifndef CC_AVX2_SUPPORT
> /*
> * If the compiler doesn't support AVX2 instructions,
> * then the dummy one would be used instead for AVX2 classify method.
> */
> -__rte_weak int
> +int
> rte_acl_classify_avx2(__rte_unused const struct rte_acl_ctx *ctx,
> __rte_unused const uint8_t **data,
> __rte_unused uint32_t *results,
> @@ -26,8 +28,9 @@ rte_acl_classify_avx2(__rte_unused const struct rte_acl_ctx *ctx,
> {
> return -ENOTSUP;
> }
> +#endif
>
> -__rte_weak int
> +int
> rte_acl_classify_sse(__rte_unused const struct rte_acl_ctx *ctx,
> __rte_unused const uint8_t **data,
> __rte_unused uint32_t *results,
> @@ -36,8 +39,11 @@ rte_acl_classify_sse(__rte_unused const struct rte_acl_ctx *ctx,
> {
> return -ENOTSUP;
> }
> +#endif
>
> -__rte_weak int
> +#ifndef RTE_ARCH_ARM
> +#ifndef RTE_ARCH_ARM64
> +int
> rte_acl_classify_neon(__rte_unused const struct rte_acl_ctx *ctx,
> __rte_unused const uint8_t **data,
> __rte_unused uint32_t *results,
> @@ -46,8 +52,11 @@ rte_acl_classify_neon(__rte_unused const struct rte_acl_ctx *ctx,
> {
> return -ENOTSUP;
> }
> +#endif
> +#endif
>
> -__rte_weak int
> +#ifndef RTE_ARCH_PPC_64
> +int
> rte_acl_classify_altivec(__rte_unused const struct rte_acl_ctx *ctx,
> __rte_unused const uint8_t **data,
> __rte_unused uint32_t *results,
> @@ -56,6 +65,7 @@ rte_acl_classify_altivec(__rte_unused const struct rte_acl_ctx *ctx,
> {
> return -ENOTSUP;
> }
> +#endif
>
> static const rte_acl_classify_t classify_fns[] = {
> [RTE_ACL_CLASSIFY_DEFAULT] = rte_acl_classify_scalar,
> diff --git a/mk/rte.app.mk b/mk/rte.app.mk
> index 7d994bece..fdec636b4 100644
> --- a/mk/rte.app.mk
> +++ b/mk/rte.app.mk
> @@ -46,10 +46,7 @@ _LDLIBS-$(CONFIG_RTE_LIBRTE_DISTRIBUTOR) += -lrte_distributor
> _LDLIBS-$(CONFIG_RTE_LIBRTE_IP_FRAG) += -lrte_ip_frag
> _LDLIBS-$(CONFIG_RTE_LIBRTE_METER) += -lrte_meter
> _LDLIBS-$(CONFIG_RTE_LIBRTE_LPM) += -lrte_lpm
> -# librte_acl needs --whole-archive because of weak functions
> -_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL) += --whole-archive
> _LDLIBS-$(CONFIG_RTE_LIBRTE_ACL) += -lrte_acl
> -_LDLIBS-$(CONFIG_RTE_LIBRTE_ACL) += --no-whole-archive
> _LDLIBS-$(CONFIG_RTE_LIBRTE_TELEMETRY) += --no-as-needed
> _LDLIBS-$(CONFIG_RTE_LIBRTE_TELEMETRY) += --whole-archive
> _LDLIBS-$(CONFIG_RTE_LIBRTE_TELEMETRY) += -lrte_telemetry -ljansson
I think I have a solution for this that can use the weak aliasing and
not require the use of the whole-archive flag. Would you prefer that?
^ permalink raw reply
* Re: [PATCH 2/7] drm/i915/icl: Apply a recommended rc6 threshold
From: Michal Wajdeczko @ 2019-04-10 13:53 UTC (permalink / raw)
To: intel-gfx, Mika Kuoppala
In-Reply-To: <20190410105923.18546-2-mika.kuoppala@linux.intel.com>
On Wed, 10 Apr 2019 12:59:18 +0200, Mika Kuoppala
<mika.kuoppala@linux.intel.com> wrote:
> On gen11 the recommended rc6 threshold differs from previous
> gens, apply it. Move the write to a correct spot in sequence.
>
> v2: do write in 2b, fix bspec ref (Michal)
>
> Bspec: 33149
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Full sequence still slightly differs compared to the spec,
but that's other story.
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
~Michal
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH 10/10] media: coda: require all decoder command flags to be cleared
From: Hans Verkuil @ 2019-04-10 13:53 UTC (permalink / raw)
To: Philipp Zabel, linux-media; +Cc: kernel
In-Reply-To: <1554829061.5799.7.camel@pengutronix.de>
On 4/9/19 6:57 PM, Philipp Zabel wrote:
> On Mon, 2019-04-08 at 14:32 +0200, Philipp Zabel wrote:
>> The memory-to-memory stateful video decoder interface documentation
>> requires the decoder stop command initiating the drain sequence to have
>> flags set to zero.
>> Stop to black makes no sense as stopped memory-to-memory decoders do not
>> produce any frames, and stopping immediately can be achieved by stopping
>> the output video queue with VIDIOC_STREAMOFF.
>>
>> The mute audio start command flag serves no purpose as the coda driver
>> does not handle any audio formats, and does not support playback at
>> non-standard speeds.
>>
>> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
>> ---
>> drivers/media/platform/coda/coda-common.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c
>> index 318f0be103bb..96798f98734a 100644
>> --- a/drivers/media/platform/coda/coda-common.c
>> +++ b/drivers/media/platform/coda/coda-common.c
>> @@ -1050,10 +1050,10 @@ static int coda_try_decoder_cmd(struct file *file, void *fh,
>> if (dc->cmd != V4L2_DEC_CMD_STOP)
>> return -EINVAL;
>>
>> - if (dc->flags & V4L2_DEC_CMD_STOP_TO_BLACK)
>> + if (dc->stop.pts != 0)
>> return -EINVAL;
>>
>> - if (!(dc->flags & V4L2_DEC_CMD_STOP_IMMEDIATELY) && (dc->stop.pts != 0))
>> + if (dc->flags != 0)
>> return -EINVAL;
>
> This change currently causes a v4l2-compliance failure
>
> fail: v4l2-test-codecs.cpp(104): ret != 0
> test VIDIOC_(TRY_)DECODER_CMD: FAIL
>
> because it still expects V4L2_DEC_CMD_STOP_IMMEDIATELY to be supported.
I've fixed this in my v4l-utils work-in-progress branch:
https://git.linuxtv.org/hverkuil/v4l-utils.git/log/?h=vicodec
But I want to hold off on this patch a little bit.
I think we need to add helpers for the try_en/decoder_cmd ioctls
to v4l2-mem2mem.c since it will be the same for all codecs.
I also had to fix vicodec since the checks it did weren't complete:
https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=vicodec&id=4e95bff9a15b63179fab20ac2113c238dc20665b
Regards,
Hans
^ permalink raw reply
* Re: [PATCH RESEND V11 4/4] arm64: dts: imx: add i.MX8QXP thermal support
From: Rob Herring @ 2019-04-10 13:52 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland@arm.com, ulf.hansson@linaro.org, heiko@sntech.de,
maxime.ripard@bootlin.com, catalin.marinas@arm.com,
will.deacon@arm.com, Peng Fan, bjorn.andersson@linaro.org,
festevam@gmail.com, stefan.wahren@i2se.com,
ezequiel@collabora.com, daniel.lezcano@linaro.org,
jagan@amarulasolutions.com, Andy Gross, rui.zhang@intel.com,
dl-linux-imx, devicetree@vger.kernel.org, marc.w.gonzalez@free.fr,
s.hauer@pengutronix.de, edubezval@gmail.com, olof@lixom.net,
robh+dt@kernel.org, horms+renesas@verge.net.au, Daniel Baluta,
linux-arm-kernel@lists.infradead.org, Aisheng Dong,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@pengutronix.de, enric.balletbo@collabora.com,
shawnguo@kernel.org
In-Reply-To: <1554881866-26333-4-git-send-email-Anson.Huang@nxp.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 262 bytes --]
:u?w]\0?????;?}??M4? ??q?jx0??^\x01?b1\x7f\x10\??R?^?f?Ή޲?i??R? ?v??o '??ǹ??\x02{(?{?? ???&
\x16???,?w\x1eW]+zj/z??????)???좺޲??q??jwi??Ö?(??\x1e 8??'^y?!?\x17???lz{(??ajwey???g???܇ö«›®?n?-??l???z?\x1a????\x1f*Æ—m?-????????????????????????_?W????y???{\x1e?ب?Ï‘z????[?\x1a^[\x1d???x+??dz?Þ–?
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RESEND V11 4/4] arm64: dts: imx: add i.MX8QXP thermal support
From: Rob Herring @ 2019-04-10 13:52 UTC (permalink / raw)
To: Anson Huang
Cc: robh+dt@kernel.org, mark.rutland@arm.com, shawnguo@kernel.org,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
catalin.marinas@arm.com, will.deacon@arm.com, rui.zhang@intel.com,
edubezval@gmail.com, daniel.lezcano@linaro.org, Aisheng Dong,
ulf.hansson@linaro.org, Peng Fan, Daniel Baluta,
horms+renesas@verge.net.au, heiko@sntech.de, Andy Gross,
maxime.ripard@bootlin.com, bjorn.andersson@linaro.org,
jagan@amarulasolutions.com, enric.balletbo@collabora.com,
ezequiel@collabora.com, stefan.wahren@i2se.com,
marc.w.gonzalez@free.fr, olof@lixom.net,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
dl-linux-imx
In-Reply-To: <1554881866-26333-4-git-send-email-Anson.Huang@nxp.com>
:u?w]\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
^ permalink raw reply
* Re: [PATCH RESEND V11 4/4] arm64: dts: imx: add i.MX8QXP thermal support
From: Rob Herring @ 2019-04-10 13:52 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland@arm.com, ulf.hansson@linaro.org, heiko@sntech.de,
maxime.ripard@bootlin.com, catalin.marinas@arm.com,
will.deacon@arm.com, Peng Fan, bjorn.andersson@linaro.org,
festevam@gmail.com, stefan.wahren@i2se.com,
ezequiel@collabora.com, daniel.lezcano@linaro.org,
jagan@amarulasolutions.com, Andy Gross, rui.zhang@intel.com,
dl-linux-imx, devicetree@vger.kernel.org, marc.w.gonzalez@free.fr,
s.hauer
In-Reply-To: <1554881866-26333-4-git-send-email-Anson.Huang@nxp.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 262 bytes --]
:u?w]\0?????;?}??M4? ??q?jx0??^\x01?b1\x7f\x10\??R?^?f?Ή޲?i??R? ?v??o '??ǹ??\x02{(?{?? ???&
\x16???,?w\x1eW]+zj/z??????)???좺޲??q??jwi??Ö?(??\x1e 8??'^y?!?\x17???lz{(??ajwey???g???܇ö«›®?n?-??l???z?\x1a????\x1f*Æ—m?-????????????????????????_?W????y???{\x1e?ب?Ï‘z????[?\x1a^[\x1d???x+??dz?Þ–?
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* BCM4335 though sdio is not fully restarted after rmmod and modprobe
From: Mohammad Rasim @ 2019-04-10 13:51 UTC (permalink / raw)
To: brcm80211-dev-list, brcm80211-dev-list.pdl, netdev,
linux-wireless
Hi,
I'm running mainline linux (5.1.0-rc2 to be precise) on an amlogic
board, the board comes with Ampak AP6335 combo (so the wifi is BCM4335 over SDIO).
The firmware for this chip is already shipped by linux-firmware as brcmfmac4335-sdio.bin
but one thing that's missing is the nvram settings so I grapped the
nvram txt file from the vendor package(it can be found in [0]) and
placed it in the path that the driver is expecting, and the dongle is
working and I can scan for APs, the problem I have now is when run rmmod
followed by modprobe, the chip is not restarted and I get errors and no
wlan0 interface
after running `rmmod brcmfmac` I get these errors:
[ 745.955312] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[ 745.958211] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[ 745.968443] ieee80211 phy0: brcmf_fil_cmd_data: bus is down. we have nothing to do.
[ 745.973286] ieee80211 phy0: brcmf_cfg80211_get_channel: chanspec failed (-5)
and after that I run `modprobe brcmfmac` I get these errors:
[ 781.529964] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4335-sdio for chip BCM4335/1
[ 784.355265] brcmfmac: brcmf_sdio_bus_rxctl: resumed on timeout
[ 784.361630] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110
[ 784.364787] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[ 784.370677] brcmfmac: brcmf_sdio_readshared: unable to obtain sdpcm_shared info: rv=-110 (addr=0x0)
[ 784.379667] ieee80211 phy1: brcmf_bus_started: failed: -110
[ 784.385174] ieee80211 phy1: brcmf_attach: dongle is not responding: err=-110
[ 784.429042] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110
[ 784.432217] brcmfmac: brcmf_sdio_firmware_callback: brcmf_attach failed
[ 784.443484] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110
[ 784.446325] brcmfmac: brcmf_sdiod_ramrw: membytes transfer failed
[ 784.452322] brcmfmac: brcmf_sdio_readshared: unable to obtain sdpcm_shared info: rv=-110 (addr=0x0)
Any idea what's causing this ?
[0] https://github.com/kszaq/brcmfmac_sdio-firmware-aml/blob/master/firmware/brcm/nvram_bcm4335.txt
^ permalink raw reply
* [U-Boot] [PATCH] imx: Extend PCL063 support for phyCORE-i.MX6ULL SOM
From: Martyn Welch @ 2019-04-10 13:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <34178a52-44e3-6a45-60a4-a4c619a94ee2@gmail.com>
On Wed, 2019-04-10 at 15:23 +0200, Parthiban Nallathambi wrote:
> Hello Wadim,
>
> Thanks for sharing the details.
>
> On 4/10/19 10:35 AM, Wadim Egorov wrote:
> > Martyn,
> >
> > On 09.04.19 12:46, Martyn Welch wrote:
> > > On Tue, 2019-04-09 at 11:30 +0200, Parthiban Nallathambi wrote:
> > > > Hello Martyn,
> > > >
> > > > On 4/9/19 10:49 AM, Martyn Welch wrote:
> > > > > On Mon, 2019-04-08 at 20:04 +0200, Parthiban wrote:
> > > > > > Hello Martyn,
> > > > > >
> > > > > > On 4/8/19 7:45 PM, Martyn Welch wrote:
> > > > > > > On Sun, 2019-04-07 at 19:56 +0200, Parthiban Nallathambi
> > > > > > > wrote:
> > > > > > > > diff --git a/board/phytec/pcl063/spl.c
> > > > > > > > b/board/phytec/pcl063/spl.c
> > > > > > > > index b93cd493f2..73a774645d 100644
> > > > > > > > --- a/board/phytec/pcl063/spl.c
> > > > > > > > +++ b/board/phytec/pcl063/spl.c
> > > > > > > > @@ -13,6 +13,7 @@
> > > > > > > > #include <asm/arch/mx6-ddr.h>
> > > > > > > > #include <asm/arch/mx6-pins.h>
> > > > > > > > #include <asm/arch/crm_regs.h>
> > > > > > > > +#include <asm/arch/sys_proto.h>
> > > > > > > > #include <fsl_esdhc.h>
> > > > > > > >
> > > > > > > > /* Configuration for Micron MT41K256M16TW-107 IT:P,
> > > > > > > > 32M x
> > > > > > > > 16 x 8
> > > > > > > > ->
> > > > > > > > 256MiB */
> > > > > > > > @@ -117,11 +118,32 @@ static iomux_v3_cfg_t const
> > > > > > > > usdhc1_pads[] =
> > > > > > > > {
> > > > > > > > MX6_PAD_UART1_RTS_B__USDHC1_CD_B |
> > > > > > > > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > > > > > > > };
> > > > > > > >
> > > > > > > > +#ifndef CONFIG_NAND_MXS
> > > > > > > > +static iomux_v3_cfg_t const usdhc2_pads[] = {
> > > > > > > > + MX6_PAD_NAND_RE_B__USDHC2_CLK |
> > > > > > > > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > > > > > > > + MX6_PAD_NAND_WE_B__USDHC2_CMD |
> > > > > > > > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > > > > > > > + MX6_PAD_NAND_DATA00__USDHC2_DATA0 |
> > > > > > > > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > > > > > > > + MX6_PAD_NAND_DATA01__USDHC2_DATA1 |
> > > > > > > > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > > > > > > > + MX6_PAD_NAND_DATA02__USDHC2_DATA2 |
> > > > > > > > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > > > > > > > + MX6_PAD_NAND_DATA03__USDHC2_DATA3 |
> > > > > > > > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > > > > > > > + MX6_PAD_NAND_DATA04__USDHC2_DATA4 |
> > > > > > > > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > > > > > > > + MX6_PAD_NAND_DATA05__USDHC2_DATA5 |
> > > > > > > > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > > > > > > > + MX6_PAD_NAND_DATA06__USDHC2_DATA6 |
> > > > > > > > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > > > > > > > + MX6_PAD_NAND_DATA07__USDHC2_DATA7 |
> > > > > > > > MUX_PAD_CTRL(USDHC_PAD_CTRL),
> > > > > > > > +};
> > > > > > > > +#endif
> > > > > > > > +
> > > > > > > Umm, these pins are already used a few lines up for the
> > > > > > > NAND,
> > > > > > > via
> > > > > > > gpmi:
> > > > > > I understand. But pcl063 can't co-exit with NAND and eMMC
> > > > > > together. I
> > > > > > comes
> > > > > > either with eMMC or NAND.
> > > > > Opps, sorry, just realised that I added this comment in the
> > > > > wrong
> > > > > place. This is in relation to the following being added to
> > > > > pcl063-common.dtsi:
> > > > >
> > > > > +
> > > > > + pinctrl_usdhc2: usdhc2grp {
> > > > > + fsl,pins = <
> > > > > + MX6UL_PAD_NAND_WE_B__USDHC2_CMD
> > > > > 0x1
> > > > > 70f9
> > > > > + MX6UL_PAD_NAND_RE_B__USDHC2_CLK
> > > > > 0x1
> > > > > 00f9
> > > > > + MX6UL_PAD_NAND_DATA00__USDHC2_DATA0
> > > > > 0x1
> > > > > 70f9
> > > > > + MX6UL_PAD_NAND_DATA01__USDHC2_DATA1
> > > > > 0x1
> > > > > 70f9
> > > > > + MX6UL_PAD_NAND_DATA02__USDHC2_DATA2
> > > > > 0x1
> > > > > 70f9
> > > > > + MX6UL_PAD_NAND_DATA03__USDHC2_DATA3
> > > > > 0x1
> > > > > 70f9
> > > > > + MX6UL_PAD_NAND_DATA04__USDHC2_DATA4
> > > > > 0x1
> > > > > 70f9
> > > > > + MX6UL_PAD_NAND_DATA05__USDHC2_DATA5
> > > > > 0x1
> > > > > 70f9
> > > > > + MX6UL_PAD_NAND_DATA06__USDHC2_DATA6
> > > > > 0x1
> > > > > 70f9
> > > > > + MX6UL_PAD_NAND_DATA07__USDHC2_DATA7
> > > > > 0x1
> > > > > 70f9
> > > > > + >;
> > > > > + };
> > > > >
> > > > > If there exists pcl063 modules that have eMMC and others that
> > > > > have
> > > > > NAND
> > > > > using the same pins, then this configuration is not common
> > > > > and
> > > > > therefore shouldn't be in pcl063-common.dtsi. Is it dependent
> > > > > on
> > > > > the
> > > > > flavour of i.MX used? If so I'd suggest the gpmi config needs
> > > > > to be
> > > > > pulled out into imx6ul-phycore-segin.dts and the usdhc2
> > > > > config
> > > > > needs to
> > > > > be in imx6ull-phycore-segin.dts.
> > > > From phytec I understand that pcl063 SoM is a common platform
> > > > for
> > > > imx6UL
> > > > and imx6ULL. This can either be shipped with eMMC or NAND, but
> > > > not
> > > > both.
> >
> > This is correct. There are PCL-063 SOMs with eMMC or NAND. And each
> > PCL-063 can be a 6UL or 6ULL.
> >
> >
> > > Looking a bit deeper, this seems a little odd as the product
> > > description suggests that NAND is provided onboard and 2
> > > SD/SDIO/MMC
> > > connections are provided to the edge connector of the pcl063 for
> > > expansion.
> > >
> > > The schematic suggests the only way they could achieve eMMC
> > > onboard
> > > would be with an eMMC that is pin compatible with the NAND they
> > > use.
> >
> > eMMC is connected via usdhc2. The usdhc2 pins conflict with the
> > gpmi pins.
> >
> >
> > > Additionally, looking at the DTBs for this board in Phytec's own
> > > kernel
> > > tree, the only use of usdhc2 that I can see is for their WLAN
> > > expansion
> > > board[1] and I would have expected their tree to have supported
> > > such an
> > > option if it was available (they seem to have gone to some length
> > > to
> > > support a lot of configurations there).
> > >
> > > Are you sure that the eMMC is provided on the pcl063 and not off
> > > board?
> >
> > eMMC is on the PCL-063 and not on a carrier board.
> >
> >
> > > (CCing Wadim who might be able to shed some light on this)
> > >
> > > > So there exist a possibility that phytec can provide imx6UL
> > > > with eMMC
> > > > as
> > > > well. IMO, both pinmux detailing for NAND and eMMC should still
> > > > reside
> > > > in common.dtsi.
> > > >
> > > Assuming Phytec do in fact sell a pcl0063 with eMMC on board, the
> > > DTB
> > > describes the hardware. You've said Phytec provide the board
> > > either with eMMC *or* NAND. The device tree, as used on a
> > > specific
> > > board, should show either the existence of NAND or eMMC.
> >
> > AFAIK, the idea was to put the muxing for both flash devices in the
> > pcl063-som.dtsi and keep them disabled. eMMC or NAND will be then
> > enabled in a higher level carrier board dts file. The handling of
> > the
> > SOM variant is designed by the carrier board dts file name, e.g.
> > imx6ul-phytec-segin-ff-rdk-nand.dts and in theory a
> > imx6ul-phytec-segin-ff-rdk-emmc.dts (Right now there is no 6UL eMMC
> > SOM
> > variant, so you can not find it in our kernel repository).
>
> I agree to place both gpmi and eMMC pinmux details in common.dtsi
> with
> default "disabled" and enable them only in board dts.
>
> @Martyn, please advise.
>
Yes, that seems sensible.
Martyn
> Thanks,
> Parthiban N
>
> > I agree, that this does not describe the SOM hardware. This is just
> > the
> > way we handle the SOM variants.
> >
> > It seems the upstream situation for kernel and u-boot differs to
> > what we
> > did quite a lot at the moment. I am just curious how you want to
> > handle
> > this now. Unfortunately, we did no had the time to bring our 6UL
> > boards
> > upstream and clarify the situation. But we can talk about it now
> > and
> > find out a way to handle the variants properly.
> >
> > CC'ed Stefan who is maintaining the imx6 boards at Phytec.
> >
> > I hope this helps :)
> >
> > Regards,
> > Wadim
> >
> > > I suspect having both options in the common file is going to lead
> > > to
> > > issues with the pinmuxing for one or the other option. The pins
> > > can't
> > > be muxed for both simultaneously, hence these need to be
> > > described in
> > > separate files.
> > >
> > > > Creating multiple common.dtsi based on these variants is not
> > > > friendly.
> > > > So I suggest to keep these changes in common.dtsi as such and
> > > > decide
> > > > in
> > > > board dts whether to enable or disable usdhc1, usdhc2
> > > > explicitly.
> > > This isn't about the selection of usdhc1 or usdhc2, it's whether
> > > gpmi
> > > or usdhc2 is using the pins of the SOC.
> > >
> > > Martyn
> > >
> > > [1]
> > > https://git.phytec.de/linux-mainline/tree/arch/arm/boot/dts/imx6ul-phytec-peb-wlbt-01.dtsi?h=v4.14.39-phy#n51
> > >
> > >
> > > > > > > pinctrl_gpmi_nand: gpminandgrp {
> > > > > > > fsl,pins = <
> > > > > > > MX6UL_PAD_NAND_CLE__RAWNAND_CLE
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_ALE__RAWNAND_ALE
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_WP_B__RAWNAND_WP
> > > > > > > _B
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_READY_B__RAWNAND
> > > > > > > _READY_
> > > > > > > B
> > > > > > > 0x0b000
> > > > > > > MX6UL_PAD_NAND_CE0_B__RAWNAND_C
> > > > > > > E0_B
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_RE_B__RAWNAND_RE
> > > > > > > _B
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_WE_B__RAWNAND_WE
> > > > > > > _B
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_DATA00__RAWNAND_
> > > > > > > DATA00
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_DATA01__RAWNAND_
> > > > > > > DATA01
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_DATA02__RAWNAND_
> > > > > > > DATA02
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_DATA03__RAWNAND_
> > > > > > > DATA03
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_DATA04__RAWNAND_
> > > > > > > DATA04
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_DATA05__RAWNAND_
> > > > > > > DATA05
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_DATA06__RAWNAND_
> > > > > > > DATA06
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > MX6UL_PAD_NAND_DATA07__RAWNAND_
> > > > > > > DATA07
> > > > > > > 0x0
> > > > > > > b0b1
> > > > > > > >;
> > > > > > > };
> > > > > > >
^ permalink raw reply
* Re: WARN_ON_ONCE() hit at kernel/events/core.c:330
From: Thomas-Mich Richter @ 2019-04-10 13:51 UTC (permalink / raw)
To: Mark Rutland, Peter Zijlstra
Cc: Kees Cook, acme, Linux Kernel Mailing List, Heiko Carstens,
Hendrik Brueckner, Martin Schwidefsky, jolsa
In-Reply-To: <20190409085327.GA21979@lakrids.cambridge.arm.com>
On 4/9/19 10:53 AM, Mark Rutland wrote:
> On Mon, Apr 08, 2019 at 11:50:31AM +0200, Peter Zijlstra wrote:
>> On Mon, Apr 08, 2019 at 10:22:29AM +0200, Peter Zijlstra wrote:
>>> On Mon, Apr 08, 2019 at 09:12:28AM +0200, Thomas-Mich Richter wrote:
>>
.....
>>
>> Instead encode the CPU number in @pending_disable, such that we can
>> tell which CPU requested the disable. This then allows us to detect
>> the above scenario and even redirect the IPI to make up for the failed
>> queue.
>>
>> Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
>> Cc: Kees Cook <keescook@chromium.org>
>> Cc: Hendrik Brueckner <brueckner@linux.ibm.com>
>> Cc: acme@redhat.com
>> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: Jiri Olsa <jolsa@redhat.com>
>> Reported-by: Thomas-Mich Richter <tmricht@linux.ibm.com>
>> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>
> I can't think of a nicer way of handling this, so FWIW:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
>
> Mark.
>
>> ---
Thanks for the fix with commit id 86071b11317550d994b55ce5e31aa06bcad783b5.
However doing an fgrep on the pending_disable member of struct perf_event
reveals two more hits in file kernel/events/ringbuffer.c when events
have auxiliary data.
Not sure if this needs to be addresses too, just wanted to let you know.
--
Thomas Richter, Dept 3252, IBM s390 Linux Development, Boeblingen, Germany
--
Vorsitzender des Aufsichtsrats: Matthias Hartmann
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294
^ permalink raw reply
* [PATCH] iw: Add new command to support tid specific configuration
From: Tamizh chelvam @ 2019-04-10 13:50 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Tamizh chelvam
Add "set tid_config" command to support tid specific configurations.
This command accepts multiple tid configurations
like retry, ampdu, rtscts, noack and tx bitrate at a time.
Format:
iw dev <interface> set tid_config <configuration>
Example:
Noack configuration :
iw <interface> set tid_config tid <tid_number> peer <MAC_addr> noack enable|disable
Retry count :
iw <interface> set tid_config tid <tid_number> peer <MAC_addr> retry_count long <retry_value>
Aggregation :
iw <interface> set tid_config tid <tid_number> peer <MAC_addr> ampdu enable|disable
RTSCTS configuration :
iw <interface> set tid_config tid <tid_number> peer <MAC_addr> rtscts enable|disable
Bitrates configuration :
iw <interface> set tid_config tid <tid_number> peer <MAC_addr> bitrates <[auto] [fixed] [limit]> [legacy-<2.4|5> <legacy rate in Mbps>*] [ht-mcs-<2.4|5> <MCS index>] [vht-mcs-<2.4|5> <NSS:MCSx]]
Signed-off-by: Tamizh chelvam <tamizhr@codeaurora.org>
---
Makefile | 2 +-
bitrate.c | 40 +++++++++--
iw.h | 3 +
tid_config.c | 230 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 267 insertions(+), 8 deletions(-)
create mode 100644 tid_config.c
diff --git a/Makefile b/Makefile
index 33aaf6a..ecb5df8 100644
--- a/Makefile
+++ b/Makefile
@@ -24,7 +24,7 @@ OBJS = iw.o genl.o event.o info.o phy.o \
reason.o status.o connect.o link.o offch.o ps.o cqm.o \
bitrate.o wowlan.o coalesce.o roc.o p2p.o vendor.o mgmt.o \
ap.o sha256.o nan.o bloom.o \
- measurements.o ftm.o
+ measurements.o ftm.o tid_config.o
OBJS += sections.o
OBJS-$(HWSIM) += hwsim.o
diff --git a/bitrate.c b/bitrate.c
index 4a026a4..e287b13 100644
--- a/bitrate.c
+++ b/bitrate.c
@@ -76,10 +76,9 @@ static int setup_vht(struct nl80211_txrate_vht *txrate_vht,
#define VHT_ARGC_MAX 100
-static int handle_bitrates(struct nl80211_state *state,
- struct nl_msg *msg,
- int argc, char **argv,
- enum id_input id)
+int set_bitrates(struct nl_msg *msg,
+ int argc, char **argv,
+ int arg_idx, enum nl80211_attrs attr)
{
struct nlattr *nl_rates, *nl_band;
int i;
@@ -110,7 +109,7 @@ static int handle_bitrates(struct nl80211_state *state,
S_GI,
} parser_state = S_NONE;
- for (i = 0; i < argc; i++) {
+ for (i = arg_idx; i < argc; i++) {
char *end;
double tmpd;
long tmpl;
@@ -195,10 +194,14 @@ static int handle_bitrates(struct nl80211_state *state,
case S_GI:
break;
default:
+ if (attr != NL80211_ATTR_TX_RATES)
+ goto next;
+
return 1;
}
}
+next:
if (have_vht_mcs_24)
if(!setup_vht(&txrate_vht_24, vht_argc_24, vht_argv_24))
return -EINVAL;
@@ -213,7 +216,7 @@ static int handle_bitrates(struct nl80211_state *state,
if (sgi_24 && lgi_24)
return 1;
- nl_rates = nla_nest_start(msg, NL80211_ATTR_TX_RATES);
+ nl_rates = nla_nest_start(msg, attr);
if (!nl_rates)
goto nla_put_failure;
@@ -253,11 +256,34 @@ static int handle_bitrates(struct nl80211_state *state,
nla_nest_end(msg, nl_rates);
- return 0;
+ return i;
nla_put_failure:
return -ENOBUFS;
}
+static int handle_bitrates(struct nl80211_state *state,
+ struct nl_msg *msg,
+ int argc, char **argv,
+ enum id_input id)
+{
+ int ret;
+ struct nl_msg *rate;
+
+ rate = nlmsg_alloc();
+ if (!rate) {
+ ret = -ENOMEM;
+ goto nla_put_failure;
+ }
+
+ ret = set_bitrates(rate, argc, argv, 0, NL80211_ATTR_TX_RATES);
+ if (ret < argc)
+ return 1;
+
+ return 0;
+nla_put_failure:
+ return -ENOBUFS;
+}
+
#define DESCR_LEGACY "[legacy-<2.4|5> <legacy rate in Mbps>*]"
#define DESCR DESCR_LEGACY " [ht-mcs-<2.4|5> <MCS index>*] [vht-mcs-<2.4|5> <NSS:MCSx,MCSy... | NSS:MCSx-MCSy>*] [sgi-2.4|lgi-2.4] [sgi-5|lgi-5]"
diff --git a/iw.h b/iw.h
index 16ff076..274f02c 100644
--- a/iw.h
+++ b/iw.h
@@ -242,4 +242,7 @@ void nan_bf(uint8_t idx, uint8_t *bf, uint16_t bf_len, const uint8_t *buf,
char *hex2bin(const char *hex, char *buf);
+int set_bitrates(struct nl_msg *msg, int argc, char **argv, int arg_idx,
+ enum nl80211_attrs attr);
+
#endif /* __IW_H */
diff --git a/tid_config.c b/tid_config.c
new file mode 100644
index 0000000..4b225c6
--- /dev/null
+++ b/tid_config.c
@@ -0,0 +1,230 @@
+#include <errno.h>
+#include <string.h>
+#include <stdbool.h>
+
+#include <netlink/genl/genl.h>
+#include <netlink/genl/family.h>
+#include <netlink/genl/ctrl.h>
+#include <netlink/msg.h>
+#include <netlink/attr.h>
+
+#include "nl80211.h"
+#include "iw.h"
+
+static int handle_tid_config(struct nl80211_state *state,
+ struct nl_msg *msg,
+ int argc, char **argv,
+ enum id_input id)
+{
+ struct nl_msg *tid;
+ struct nlattr *nl_tid;
+ unsigned char mac_addr[ETH_ALEN];
+ bool have_retry = false, have_ampdu = false;
+ bool have_noack = false, have_rtscts = false, have_bitrate = false;
+ int retry_short = -1, retry_long = -1;
+ bool nest_start = true;
+ uint8_t ampdu = 0, rtscts = 0, noack = 0;
+ enum nl80211_tx_rate_setting type = 0;
+ int tid_no = -1, i = 0;
+ char *end;
+ int ret = -ENOSPC;
+
+ if (argc < 4)
+ return 1;
+
+ tid = nlmsg_alloc();
+ if (!tid)
+ return -ENOMEM;
+
+ while (argc) {
+ if (strcmp(argv[0], "tid") == 0) {
+ if (argc < 2)
+ return 1;
+
+ tid_no = strtoul(argv[1], &end, 16);
+ if (*end)
+ return 1;
+
+ goto next;
+ } else if (strcmp(argv[0], "peer") == 0) {
+ if (argc < 2)
+ return 1;
+
+ if (mac_addr_a2n(mac_addr, argv[1])) {
+ fprintf(stderr, "invalid mac address\n");
+ return 2;
+ }
+
+ NLA_PUT(msg, NL80211_ATTR_MAC, ETH_ALEN, mac_addr);
+ goto next;
+ } else if (strcmp(argv[0], "retry_count") == 0) {
+ have_retry = true;
+ argv++;
+ argc--;
+ if (argc) {
+ if (strcmp(argv[0], "short") == 0) {
+ if (argc < 2)
+ return 1;
+
+ retry_short = strtoul(argv[1], &end, 0);
+ if (*end)
+ return 1;
+ argv += 2;
+ argc -= 2;
+ }
+ if (argc && strcmp(argv[0], "long") == 0) {
+ if (argc < 2)
+ return 1;
+ retry_long = strtoul(argv[1], &end, 0);
+ if (*end)
+ return 1;
+ }
+ }
+ } else if (strcmp(argv[0], "rtscts") == 0) {
+ have_rtscts = true;
+ if (argc < 2) {
+ argc--;
+ argv++;
+ rtscts = NL80211_TID_CONFIG_DEFAULT;
+ } else {
+ if (strcmp(argv[1], "enable") == 0)
+ rtscts = NL80211_TID_CONFIG_ENABLE;
+ else if (strcmp(argv[1], "disable") == 0)
+ rtscts = NL80211_TID_CONFIG_DISABLE;
+ else
+ rtscts = NL80211_TID_CONFIG_DEFAULT;
+ }
+ } else if (strcmp(argv[0], "ampdu") == 0) {
+ have_ampdu = true;
+ if (argc < 2) {
+ argc--;
+ argv++;
+ ampdu = NL80211_TID_CONFIG_DEFAULT;
+ } else {
+ if (strcmp(argv[1], "enable") == 0)
+ ampdu = NL80211_TID_CONFIG_ENABLE;
+ else if (strcmp(argv[1], "disable") == 0)
+ ampdu = NL80211_TID_CONFIG_DISABLE;
+ else
+ ampdu = NL80211_TID_CONFIG_DEFAULT;
+ }
+ } else if (strcmp(argv[0], "noack") == 0) {
+ have_noack = true;
+ if (argc < 2) {
+ argc--;
+ argv++;
+ noack = NL80211_TID_CONFIG_DEFAULT;
+ } else {
+ if (strcmp(argv[1], "enable") == 0)
+ noack = NL80211_TID_CONFIG_ENABLE;
+ else if (strcmp(argv[1], "disable") == 0)
+ noack = NL80211_TID_CONFIG_DISABLE;
+ else
+ noack = NL80211_TID_CONFIG_DEFAULT;
+ }
+ } else if (strcmp(argv[0], "bitrates") == 0) {
+ have_bitrate = true;
+ if (argc < 2)
+ return 1;
+ if (!strcmp(argv[1], "auto"))
+ type = NL80211_TX_RATE_AUTOMATIC;
+ else if (!strcmp(argv[1], "fixed"))
+ type = NL80211_TX_RATE_FIXED;
+ else if (!strcmp(argv[1], "limit"))
+ type = NL80211_TX_RATE_LIMITED;
+ else {
+ printf("Invalid parameter: %s\n", argv[i]);
+ return 2;
+ }
+ argc -= 2;
+ argv += 2;
+ } else {
+ return 1;
+ }
+
+ if (tid_no == -1)
+ return 1;
+ if (have_retry || have_rtscts || have_bitrate || have_ampdu ||
+ have_noack) {
+ nl_tid = nla_nest_start(tid, i);
+ if (!nl_tid) {
+ ret = -ENOBUFS;
+ goto nla_put_failure;
+ }
+ nest_start = true;
+ NLA_PUT_U8(tid, NL80211_ATTR_TID_CONFIG_TID, tid_no);
+ } else {
+ goto next;
+ }
+
+ if (have_retry) {
+ NLA_PUT_FLAG(tid, NL80211_ATTR_TID_CONFIG_RETRY);
+ if (retry_short != -1) {
+ NLA_PUT_U8(tid, NL80211_ATTR_TID_CONFIG_RETRY_SHORT,
+ retry_short);
+ }
+ if (retry_long != -1) {
+ NLA_PUT_U8(tid, NL80211_ATTR_TID_CONFIG_RETRY_LONG,
+ retry_long);
+ }
+
+ retry_short = retry_long = -1;
+ have_retry = false;
+ }
+
+ if (have_rtscts) {
+ NLA_PUT_U8(tid, NL80211_ATTR_TID_CONFIG_RTSCTS_CTRL,
+ rtscts);
+ rtscts = 0;
+ have_rtscts = false;
+ }
+
+ if (have_ampdu) {
+ NLA_PUT_U8(tid, NL80211_ATTR_TID_CONFIG_AMPDU_CTRL,
+ ampdu);
+ ampdu = 0;
+ have_ampdu = false;
+ }
+
+ if (have_noack) {
+ NLA_PUT_U8(tid, NL80211_ATTR_TID_CONFIG_NOACK, noack);
+ noack = 0;
+ have_noack = false;
+ }
+
+ if (have_bitrate) {
+ NLA_PUT_U8(tid, NL80211_ATTR_TID_CONFIG_TX_RATES_TYPE, type);
+ if (type != NL80211_TX_RATE_AUTOMATIC) {
+ ret = set_bitrates(tid, argc, argv, 0,
+ NL80211_ATTR_TID_CONFIG_TX_RATES);
+ if (ret < 2)
+ return 1;
+
+ argc -= (ret - 2);
+ argv += (ret - 2);
+ }
+ have_bitrate = false;
+ type = 0;
+ }
+
+ if (nest_start) {
+ nla_nest_end(tid, nl_tid);
+ nest_start = false;
+ }
+next:
+ if (argc) {
+ argc -= 2;
+ argv += 2;
+ }
+ }
+
+ nla_put_nested(msg, NL80211_ATTR_TID_CONFIG, tid);
+
+ ret = 0;
+
+nla_put_failure:
+ return ret;
+}
+COMMAND(set, tid_config, "tid <tid> [peer <MAC address>] [<retry_count> short <limit> long <limit>] [rtscts enable|disable] [ampdu enable|disable] [noack enable|disable] bitrates <[auto] [fixed] [limited]> [peer <addr>] [legacy-<2.4|5> <legacy rate in Mbps>*] [ht-mcs-<2.4|5> <MCS index>] [vht-mcs-<2.4|5> <NSS:MCSx]",
+ NL80211_CMD_SET_TID_CONFIG, 0, CIB_NETDEV, handle_tid_config,
+ "Set the retry count for the TIDs ");
--
1.9.1
^ permalink raw reply related
* Re: Bug: VHCI + USB 3.0
From: Bollinger, Seth @ 2019-04-10 13:50 UTC (permalink / raw)
To: Alan Stern; +Cc: Ming Lei, Jens Axboe, USB list, linux-block
In-Reply-To: <6FA377F5-595C-4197-850C-5DD8C1B172D5@digi.com>
> On Apr 9, 2019, at 2:13 PM, Bollinger, Seth <Seth.Bollinger@digi.com<mailto:Seth.Bollinger@digi.com>> wrote:
>
> > Seth, you can try adding:
> >
> > blk_queue_virt_boundary(sdev->request_queue, 1024 - 1)
> >
> > in drivers/usb/storage/scsiglue.c:slave_alloc(), just after the call to
> > blk_queue_update_dma_alignment(). Perhaps that will help
> >
>
> I will do that as a test. However, I’m concerned that we’re solving only a specific case. Won’t it fail in a similar way if a different subsystem does the same thing (USB modem or > video drivers, etc.)?
Just to follow up, this does seem to solve the specific problem.
Seth
^ permalink raw reply
* Re: [PATCH v1 0/5] Add supply property for DSI controller
From: Alexandre Torgue @ 2019-04-10 13:48 UTC (permalink / raw)
To: Yannick Fertré, Philippe Cornu, Benjamin Gaignard,
Vincent Abriou, David Airlie, Daniel Vetter, Rob Herring,
Mark Rutland, Maxime Coquelin, dri-devel, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <1554279389-27377-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 4/3/19 10:16 AM, Yannick Fertré wrote:
> The DSI controller needs a new property that powers its physical layer.
> Binding has been updated to documented this property.
> Device tree of stm32mp157c soc.
> Move reg18 & reg11 to stm32mp157c device tree file.
> Remove property phy-dsi-supply property to stm32mp157c-dk2.dts file.
>
> Yannick Fertré (5):
...
> ARM: dts: stm32: add phy-dsi-supply property on stm32mp157c
> ARM: dts: stm32: move fixe regulators reg11 & reg18
> ARM: dts: stm32: remove phy-dsi-supply property on stm32mp157c-dk2
> board
>
For ARM part:
Another series is currently under review: "Add support for STM32MP1
power regulators" (https://lkml.org/lkml/2019/4/8/614).
As soon I'll merge it I'll take your patches without patch
"ARM: dts: stm32: move fixe regulators reg11 & reg18" as it will be no
longer relevant.
regards
Alexandre
> .../devicetree/bindings/display/st,stm32-ltdc.txt | 3 +++
> arch/arm/boot/dts/stm32mp157c-dk2.dts | 9 ---------
> arch/arm/boot/dts/stm32mp157c-ed1.dts | 16 ----------------
> arch/arm/boot/dts/stm32mp157c.dtsi | 17 +++++++++++++++++
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 20 ++++++++++++++++++++
> 5 files changed, 40 insertions(+), 25 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC patch 41/41] lib/stackdepot: Remove obsolete functions
From: Alexander Potapenko @ 2019-04-10 13:49 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Josh Poimboeuf, x86, Andy Lutomirski, Steven Rostedt,
Alexander Potapenko
In-Reply-To: <20190410103647.294241460@linutronix.de>
On Wed, Apr 10, 2019 at 1:06 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> No more users of the struct stack_trace based interfaces.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Alexander Potapenko <glider@google.com>
> ---
> include/linux/stackdepot.h | 4 ----
> lib/stackdepot.c | 20 --------------------
> 2 files changed, 24 deletions(-)
>
> --- a/include/linux/stackdepot.h
> +++ b/include/linux/stackdepot.h
> @@ -23,13 +23,9 @@
>
> typedef u32 depot_stack_handle_t;
>
> -struct stack_trace;
> -
> -depot_stack_handle_t depot_save_stack(struct stack_trace *trace, gfp_t flags);
> depot_stack_handle_t stack_depot_save(unsigned long *entries,
> unsigned int nr_entries, gfp_t gfp_flags);
>
> -void depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace *trace);
> unsigned int stack_depot_fetch(depot_stack_handle_t handle,
> unsigned long **entries);
>
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -212,14 +212,6 @@ unsigned int stack_depot_fetch(depot_sta
> }
> EXPORT_SYMBOL_GPL(stack_depot_fetch);
>
> -void depot_fetch_stack(depot_stack_handle_t handle, struct stack_trace *trace)
> -{
> - unsigned int nent = stack_depot_fetch(handle, &trace->entries);
> -
> - trace->max_entries = trace->nr_entries = nent;
> -}
> -EXPORT_SYMBOL_GPL(depot_fetch_stack);
> -
> /**
> * stack_depot_save - Save a stack trace from an array
> *
> @@ -314,15 +306,3 @@ depot_stack_handle_t stack_depot_save(un
> return retval;
> }
> EXPORT_SYMBOL_GPL(stack_depot_save);
> -
> -/**
> - * depot_save_stack - save stack in a stack depot.
> - * @trace - the stacktrace to save.
> - * @alloc_flags - flags for allocating additional memory if required.
> - */
> -depot_stack_handle_t depot_save_stack(struct stack_trace *trace,
> - gfp_t alloc_flags)
> -{
> - return stack_depot_save(trace->entries, trace->nr_entries, alloc_flags);
> -}
> -EXPORT_SYMBOL_GPL(depot_save_stack);
>
>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* Re: [PATCH 08/10] media: coda: allow encoder to set colorimetry on the output queue
From: Hans Verkuil @ 2019-04-10 13:48 UTC (permalink / raw)
To: Philipp Zabel, linux-media; +Cc: kernel
In-Reply-To: <20190408123256.22868-8-p.zabel@pengutronix.de>
On 4/8/19 2:32 PM, Philipp Zabel wrote:
> v4l2-compliance sets colorimetry on the output queue and then verifies
> that querying colorimetry on the capture queue returns the same
> configuration. For this to work, the encoder must allow setting context
> colorimetry parameters on the output queue.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> drivers/media/platform/coda/coda-common.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/platform/coda/coda-common.c b/drivers/media/platform/coda/coda-common.c
> index 2966eb1c4d2d..7b89dbae938d 100644
> --- a/drivers/media/platform/coda/coda-common.c
> +++ b/drivers/media/platform/coda/coda-common.c
> @@ -819,6 +819,11 @@ static int coda_s_fmt_vid_out(struct file *file, void *priv,
> if (ret)
> return ret;
>
> + ctx->colorspace = f->fmt.pix.colorspace;
> + ctx->xfer_func = f->fmt.pix.xfer_func;
> + ctx->ycbcr_enc = f->fmt.pix.ycbcr_enc;
> + ctx->quantization = f->fmt.pix.quantization;
> +
> if (ctx->inst_type != CODA_INST_DECODER)
> return 0;
>
> @@ -831,11 +836,6 @@ static int coda_s_fmt_vid_out(struct file *file, void *priv,
> }
> ctx->codec = codec;
>
> - ctx->colorspace = f->fmt.pix.colorspace;
> - ctx->xfer_func = f->fmt.pix.xfer_func;
> - ctx->ycbcr_enc = f->fmt.pix.ycbcr_enc;
> - ctx->quantization = f->fmt.pix.quantization;
> -
> dst_vq = v4l2_m2m_get_vq(ctx->fh.m2m_ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
> if (!dst_vq)
> return -EINVAL;
>
Isn't the colorimetry information encoded in the stream's metadata? So should
it be set in an encoder register so it ends up in the right place in the bitstream?
And for decoders it should then be read back from a register.
Just curious how this would work for this codec and if it is even possible.
For now this patch is OK, but I think more work is needed.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH v1 0/5] Add supply property for DSI controller
From: Alexandre Torgue @ 2019-04-10 13:48 UTC (permalink / raw)
To: Yannick Fertré, Philippe Cornu, Benjamin Gaignard,
Vincent Abriou, David Airlie, Daniel Vetter, Rob Herring,
Mark Rutland, Maxime Coquelin, dri-devel, devicetree, linux-stm32,
linux-arm-kernel, linux-kernel
In-Reply-To: <1554279389-27377-1-git-send-email-yannick.fertre@st.com>
Hi Yannick
On 4/3/19 10:16 AM, Yannick Fertré wrote:
> The DSI controller needs a new property that powers its physical layer.
> Binding has been updated to documented this property.
> Device tree of stm32mp157c soc.
> Move reg18 & reg11 to stm32mp157c device tree file.
> Remove property phy-dsi-supply property to stm32mp157c-dk2.dts file.
>
> Yannick Fertré (5):
...
> ARM: dts: stm32: add phy-dsi-supply property on stm32mp157c
> ARM: dts: stm32: move fixe regulators reg11 & reg18
> ARM: dts: stm32: remove phy-dsi-supply property on stm32mp157c-dk2
> board
>
For ARM part:
Another series is currently under review: "Add support for STM32MP1
power regulators" (https://lkml.org/lkml/2019/4/8/614).
As soon I'll merge it I'll take your patches without patch
"ARM: dts: stm32: move fixe regulators reg11 & reg18" as it will be no
longer relevant.
regards
Alexandre
> .../devicetree/bindings/display/st,stm32-ltdc.txt | 3 +++
> arch/arm/boot/dts/stm32mp157c-dk2.dts | 9 ---------
> arch/arm/boot/dts/stm32mp157c-ed1.dts | 16 ----------------
> arch/arm/boot/dts/stm32mp157c.dtsi | 17 +++++++++++++++++
> drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 20 ++++++++++++++++++++
> 5 files changed, 40 insertions(+), 25 deletions(-)
>
^ permalink raw reply
* Re: [RFC patch 29/41] btrfs: ref-verify: Simplify stack trace retrieval
From: Alexander Potapenko @ 2019-04-10 13:47 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Josh Poimboeuf, x86, Andy Lutomirski, Steven Rostedt,
Alexander Potapenko, David Sterba, Chris Mason, Josef Bacik,
linux-btrfs
In-Reply-To: <20190410103646.221275815@linutronix.de>
On Wed, Apr 10, 2019 at 1:06 PM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Replace the indirection through struct stack_trace with an invocation of
> the storage array based interface.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Cc: David Sterba <dsterba@suse.com>
> Cc: Chris Mason <clm@fb.com>
> Cc: Josef Bacik <josef@toxicpanda.com>
> Cc: linux-btrfs@vger.kernel.org
> ---
> fs/btrfs/ref-verify.c | 15 ++-------------
> 1 file changed, 2 insertions(+), 13 deletions(-)
>
> --- a/fs/btrfs/ref-verify.c
> +++ b/fs/btrfs/ref-verify.c
> @@ -205,28 +205,17 @@ static struct root_entry *lookup_root_en
> #ifdef CONFIG_STACKTRACE
> static void __save_stack_trace(struct ref_action *ra)
> {
> - struct stack_trace stack_trace;
> -
> - stack_trace.max_entries = MAX_TRACE;
> - stack_trace.nr_entries = 0;
> - stack_trace.entries = ra->trace;
> - stack_trace.skip = 2;
> - save_stack_trace(&stack_trace);
> - ra->trace_len = stack_trace.nr_entries;
> + ra->trace_len = stack_trace_save(ra->trace, MAX_TRACE, 2);
Now that stack_trace.skip is gone, it's unclear what this "2" stands for.
Maybe add an inline comment saying it's skipnr?
(This is probably valid for all other stack_trace_save() callsites)
> }
>
> static void __print_stack_trace(struct btrfs_fs_info *fs_info,
> struct ref_action *ra)
> {
> - struct stack_trace trace;
> -
> if (ra->trace_len == 0) {
> btrfs_err(fs_info, " ref-verify: no stacktrace");
> return;
> }
> - trace.nr_entries = ra->trace_len;
> - trace.entries = ra->trace;
> - print_stack_trace(&trace, 2);
> + stack_trace_print(ra->trace, ra->trace_len, 2);
> }
> #else
> static void inline __save_stack_trace(struct ref_action *ra)
>
>
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 3/3] acl: adjust the tests
From: Bruce Richardson @ 2019-04-10 13:46 UTC (permalink / raw)
To: Aaron Conole
Cc: Ananyev, Konstantin, dev@dpdk.org, Jerin Jacob, Gavin Hu,
Michael Santana
In-Reply-To: <20190410132456.GB718@bricha3-MOBL.ger.corp.intel.com>
On Wed, Apr 10, 2019 at 02:24:56PM +0100, Bruce Richardson wrote:
> On Wed, Apr 10, 2019 at 09:10:25AM -0400, Aaron Conole wrote:
> >
> > Okay - I'll look at this part more. I think I went down the path of
> > explicitly setting these because the comments didn't match with what was
> > occuring (for example, in the section that I changed that loops through
> > all versions, only the AVX2 and Scalar were being tested on my system,
> > while the comment implied SSE).
> >
> > I also believe that I split out the functions because of the linking
> > issue (I guess the way the linker resolves the functions works properly
> > when the weak versions are in a different translation unit)? I'll spend
> > some time trying to get it working in a different way.
> >
> > Regardless, this wasn't ready for posting as 'PATCH' - I meant it as
> > RFC. I don't intend to change the first two patches, though.
> >
> > And thank you for the all the feedback!
> >
> I've dug into this a bit, and I'm doing up a patch to remove the use of
> weak symbols in our libraries (note, just libs, not drivers) entirely.
> That's fairly easy to do, and not a big change, but should make this
> problem go away.
>
> /Bruce
Ref: http://patches.dpdk.org/project/dpdk/list/?series=4242
^ permalink raw reply
* Re: [PATCH RESEND V11 1/4] dt-bindings: fsl: scu: add thermal binding
From: Rob Herring @ 2019-04-10 13:46 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland@arm.com, ulf.hansson@linaro.org, heiko@sntech.de,
maxime.ripard@bootlin.com, catalin.marinas@arm.com,
will.deacon@arm.com, Peng Fan, bjorn.andersson@linaro.org,
festevam@gmail.com, stefan.wahren@i2se.com,
ezequiel@collabora.com, daniel.lezcano@linaro.org,
jagan@amarulasolutions.com, Andy Gross, rui.zhang@intel.com,
dl-linux-imx, devicetree@vger.kernel.org, marc.w.gonzalez@free.fr,
s.hauer@pengutronix.de, edubezval@gmail.com, olof@lixom.net,
horms+renesas@verge.net.au, Daniel Baluta,
linux-arm-kernel@lists.infradead.org, Aisheng Dong,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel@pengutronix.de, enric.balletbo@collabora.com,
shawnguo@kernel.org
In-Reply-To: <1554881866-26333-1-git-send-email-Anson.Huang@nxp.com>
On Wed, Apr 10, 2019 at 07:43:04AM +0000, Anson Huang wrote:
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
> system controller, the system controller is in charge of system
> power, clock and thermal sensors etc. management, Linux kernel
> has to communicate with system controller via MU (message unit)
> IPC to get temperature from thermal sensors, this patch adds
> binding doc for i.MX system controller thermal driver.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V10:
> - remove property "imx,sensor-resource-id".
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH RESEND V11 1/4] dt-bindings: fsl: scu: add thermal binding
From: Rob Herring @ 2019-04-10 13:46 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland@arm.com, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
catalin.marinas@arm.com, will.deacon@arm.com, rui.zhang@intel.com,
edubezval@gmail.com, daniel.lezcano@linaro.org, Aisheng Dong,
ulf.hansson@linaro.org, Peng Fan, Daniel Baluta,
horms+renesas@verge.net.au, heiko@sntech.de, Andy Gross,
maxime.ripard@bootlin.com, bjorn.andersson@linaro.org,
jagan@amarulasolutions.com, enric.balletbo@collabora.com,
ezequiel@collabora.com, stefan.wahren@i2se.com,
marc.w.gonzalez@free.fr, olof@lixom.net,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-pm@vger.kernel.org,
dl-linux-imx
In-Reply-To: <1554881866-26333-1-git-send-email-Anson.Huang@nxp.com>
On Wed, Apr 10, 2019 at 07:43:04AM +0000, Anson Huang wrote:
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
> system controller, the system controller is in charge of system
> power, clock and thermal sensors etc. management, Linux kernel
> has to communicate with system controller via MU (message unit)
> IPC to get temperature from thermal sensors, this patch adds
> binding doc for i.MX system controller thermal driver.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V10:
> - remove property "imx,sensor-resource-id".
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH for-next 1/2] PCI/AER: Helper function for configuring AER registers
From: Andriy Shevchenko @ 2019-04-10 13:46 UTC (permalink / raw)
To: Dennis Dalessandro
Cc: bhelgaas, Mike Marciniszyn, jgg, linux-rdma, linux-pci,
Michael J. Ruhl, dledford, Kamenee Arumugam
In-Reply-To: <20190410123440.26818.67664.stgit@scvm10.sc.intel.com>
On Wed, Apr 10, 2019 at 05:34:50AM -0700, Dennis Dalessandro wrote:
> From: Kamenee Arumugam <kamenee.arumugam@intel.com>
>
> In some use cases, drivers may need to change the default
> AER settings. Introduce a helper function for setting
> and clearing the AER configuration registers.
>
> Access to the AER registers is not serialized. If multiple
> access is required, correct locking must be done.
>
FWIW,
Reviewed-by: Andriy Shevchenko <andriy.shevchenko@intel.com>
Thanks.
> Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
> Reviewed-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
> Cc: Andriy Shevchenko <andriy.shevchenko@intel.com>
> Signed-off-by: Kamenee Arumugam <kamenee.arumugam@intel.com>
> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
> ---
> drivers/pci/pcie/aer.c | 33 +++++++++++++++++++++++++++++++++
> include/linux/aer.h | 17 +++++++++++++++++
> 2 files changed, 50 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index f8fc211..b0435f9 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -353,6 +353,39 @@ int pci_enable_pcie_error_reporting(struct pci_dev *dev)
> }
> EXPORT_SYMBOL_GPL(pci_enable_pcie_error_reporting);
>
> +/**
> + * pcie_aer_clear_and_set_dword - Set or clear AER registers
> + * @dev: pci dev data
> + * @pos: The offset of AER registers
> + * @clear: The bits to clear
> + * @set: The bits to set
> + *
> + * This function must only be used by the driver owning the device.
> + * Return:
> + * * 0 - on success
> + * * Negative error code - on generic failures
> + * * Positive error code - on PCI access errors
> + */
> +int pcie_aer_clear_and_set_dword(struct pci_dev *dev, int pos,
> + u32 clear, u32 set)
> +{
> + u32 data;
> + int ret;
> +
> + if (!dev->aer_cap)
> + return -EIO;
> +
> + ret = pci_read_config_dword(dev, dev->aer_cap + pos, &data);
> + if (!ret) {
> + data &= ~clear;
> + data |= set;
> + return pci_write_config_dword(dev, dev->aer_cap + pos, data);
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(pcie_aer_clear_and_set_dword);
> +
> int pci_disable_pcie_error_reporting(struct pci_dev *dev)
> {
> if (pcie_aer_get_firmware_first(dev))
> diff --git a/include/linux/aer.h b/include/linux/aer.h
> index 514bffa..e21d65c 100644
> --- a/include/linux/aer.h
> +++ b/include/linux/aer.h
> @@ -46,6 +46,8 @@ struct aer_capability_regs {
> int pci_disable_pcie_error_reporting(struct pci_dev *dev);
> int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev);
> int pci_cleanup_aer_error_status_regs(struct pci_dev *dev);
> +int pcie_aer_clear_and_set_dword(struct pci_dev *dev, int pos,
> + u32 clear, u32 set);
> #else
> static inline int pci_enable_pcie_error_reporting(struct pci_dev *dev)
> {
> @@ -63,6 +65,12 @@ static inline int pci_cleanup_aer_error_status_regs(struct pci_dev *dev)
> {
> return -EINVAL;
> }
> +
> +static inline int pcie_aer_clear_and_set_dword(struct pci_dev *dev, int pos,
> + u32 clear, u32 set)
> +{
> + return -EINVAL;
> +}
> #endif
>
> void cper_print_aer(struct pci_dev *dev, int aer_severity,
> @@ -70,5 +78,14 @@ void cper_print_aer(struct pci_dev *dev, int aer_severity,
> int cper_severity_to_aer(int cper_severity);
> void aer_recover_queue(int domain, unsigned int bus, unsigned int devfn,
> int severity, struct aer_capability_regs *aer_regs);
> +static inline int pcie_aer_set_dword(struct pci_dev *dev, int pos, u32 set)
> +{
> + return pcie_aer_clear_and_set_dword(dev, pos, 0, set);
> +}
> +
> +static inline int pcie_aer_clear_dword(struct pci_dev *dev, int pos, u32 clear)
> +{
> + return pcie_aer_clear_and_set_dword(dev, pos, clear, 0);
> +}
> #endif //_AER_H_
>
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH RESEND V11 1/4] dt-bindings: fsl: scu: add thermal binding
From: Rob Herring @ 2019-04-10 13:46 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland@arm.com, shawnguo@kernel.org, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
catalin.marinas@arm.com, will.deacon@arm.com, rui.zhang@intel.com,
edubezval@gmail.com, daniel.lezcano@linaro.org, Aisheng Dong,
ulf.hansson@linaro.org, Peng Fan, Daniel Baluta,
horms+renesas@verge.net.au, heiko@sntech.de, Andy Gross
In-Reply-To: <1554881866-26333-1-git-send-email-Anson.Huang@nxp.com>
On Wed, Apr 10, 2019 at 07:43:04AM +0000, Anson Huang wrote:
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
> system controller, the system controller is in charge of system
> power, clock and thermal sensors etc. management, Linux kernel
> has to communicate with system controller via MU (message unit)
> IPC to get temperature from thermal sensors, this patch adds
> binding doc for i.MX system controller thermal driver.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V10:
> - remove property "imx,sensor-resource-id".
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.