The patch
ASoC: topology: Fix kcontrol name string handling
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 267e2c6fd7ca3d4076d20f9d52d49dc91addfe9d Mon Sep 17 00:00:00 2001
From: Liam Girdwood <liam.r.girdwood(a)linux.intel.com>
Date: Tue, 27 Mar 2018 12:04:04 +0100
Subject: [PATCH] ASoC: topology: Fix kcontrol name string handling
Fix the topology kcontrol string handling so that string pointer
references are strdup()ed instead of being copied. This fixes issues
with kcontrol templates on the stack or ones that are freed. Remember
and free the strings too when topology is unloaded.
Signed-off-by: Liam Girdwood <liam.r.girdwood(a)linux.intel.com>
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Cc: stable(a)vger.kernel.org
---
sound/soc/soc-topology.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/sound/soc/soc-topology.c b/sound/soc/soc-topology.c
index 01a50413c66f..782c580b7aa3 100644
--- a/sound/soc/soc-topology.c
+++ b/sound/soc/soc-topology.c
@@ -523,6 +523,7 @@ static void remove_widget(struct snd_soc_component *comp,
kfree(se->dobj.control.dtexts[j]);
kfree(se);
+ kfree(w->kcontrol_news[i].name);
}
kfree(w->kcontrol_news);
} else {
@@ -540,6 +541,7 @@ static void remove_widget(struct snd_soc_component *comp,
*/
kfree((void *)kcontrol->private_value);
snd_ctl_remove(card, kcontrol);
+ kfree(w->kcontrol_news[i].name);
}
kfree(w->kcontrol_news);
}
@@ -1233,7 +1235,9 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dmixer_create(
dev_dbg(tplg->dev, " adding DAPM widget mixer control %s at %d\n",
mc->hdr.name, i);
- kc[i].name = mc->hdr.name;
+ kc[i].name = kstrdup(mc->hdr.name, GFP_KERNEL);
+ if (kc[i].name == NULL)
+ goto err_str;
kc[i].private_value = (long)sm;
kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER;
kc[i].access = mc->hdr.access;
@@ -1278,8 +1282,10 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dmixer_create(
err_str:
kfree(sm);
err:
- for (--i; i >= 0; i--)
+ for (--i; i >= 0; i--) {
kfree((void *)kc[i].private_value);
+ kfree(kc[i].name);
+ }
kfree(kc);
return NULL;
}
@@ -1310,7 +1316,9 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_denum_create(
dev_dbg(tplg->dev, " adding DAPM widget enum control %s\n",
ec->hdr.name);
- kc[i].name = ec->hdr.name;
+ kc[i].name = kstrdup(ec->hdr.name, GFP_KERNEL);
+ if (kc[i].name == NULL)
+ goto err_se;
kc[i].private_value = (long)se;
kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER;
kc[i].access = ec->hdr.access;
@@ -1386,6 +1394,7 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_denum_create(
kfree(se->dobj.control.dtexts[j]);
kfree(se);
+ kfree(kc[i].name);
}
err:
kfree(kc);
@@ -1424,7 +1433,9 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dbytes_create(
"ASoC: adding bytes kcontrol %s with access 0x%x\n",
be->hdr.name, be->hdr.access);
- kc[i].name = be->hdr.name;
+ kc[i].name = kstrdup(be->hdr.name, GFP_KERNEL);
+ if (kc[i].name == NULL)
+ goto err;
kc[i].private_value = (long)sbe;
kc[i].iface = SNDRV_CTL_ELEM_IFACE_MIXER;
kc[i].access = be->hdr.access;
@@ -1454,8 +1465,10 @@ static struct snd_kcontrol_new *soc_tplg_dapm_widget_dbytes_create(
return kc;
err:
- for (--i; i >= 0; i--)
+ for (--i; i >= 0; i--) {
kfree((void *)kc[i].private_value);
+ kfree(kc[i].name);
+ }
kfree(kc);
return NULL;
--
2.16.2
On Fri, Mar 2, 2018 at 5:44 AM, Jerome Brunet <jbrunet(a)baylibre.com> wrote:
> Different modules maybe installed by the user on the eMMC connector
> of the odroid-c2. While the red modules are working without an issue,
> it seems some black modules (apparently Samsung based) are having
> issue at 200MHz
>
> While the tuning algorithm introduced in v4.14 enables high speed modes
> on every other tested designs, it seems a problem remains for this
> particular combination of board and eMMC module.
>
> Lowering the maximum frequency of the eMMC on this board until we can
> figure out a better solution.
>
> Fixes: d341ca88eead ("mmc: meson-gx: rework tuning function")
> Suggested-by: Ellie Reeves <ellierevves(a)gmail.com>
> Signed-off-by: Jerome Brunet <jbrunet(a)baylibre.com>
Now in mainline as commit c04ffa71ff49 upstream.
The mainline patch has "Cc: stable(a)vger.kernel.org", but it doesn't
seem to have appeared in stable yet, and I've verified that it applies
cleanly to linux-4.15.y and linux-4.14.y.
Kevin
> ---
> arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 73a030a5ecf3..43475139576c 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -311,7 +311,7 @@
> pinctrl-names = "default", "clk-gate";
>
> bus-width = <8>;
> - max-frequency = <200000000>;
> + max-frequency = <100000000>;
> non-removable;
> disable-wp;
> cap-mmc-highspeed;
> --
> 2.14.3
>
From: Ryo Kodama <ryo.kodama.vz(a)renesas.com>
This patch fixes an issue that is possible to set mismatch value
to duty for R-Car PWM if we input the following commands:
# cd /sys/class/pwm/<pwmchip>/
# echo 0 > export
# cd pwm0
# echo 30 > period
# echo 30 > duty_cycle
# echo 0 > duty_cycle
# cat duty_cycle
0
# echo 1 > enable
--> Then, the actual duty_cycle is 30, not 0.
So, this patch adds a condition into rcar_pwm_config() to fix
this issue.
Signed-off-by: Ryo Kodama <ryo.kodama.vz(a)renesas.com>
[shimoda: revise the commit log and add Fixes and Cc tags]
Fixes: ed6c1476bf7f ("pwm: Add support for R-Car PWM Timer")
Cc: Cc: <stable(a)vger.kernel.org> # v4.4+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com>
---
drivers/pwm/pwm-rcar.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index 1c85ecc..0fcf94f 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -156,8 +156,12 @@ static int rcar_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
if (div < 0)
return div;
- /* Let the core driver set pwm->period if disabled and duty_ns == 0 */
- if (!pwm_is_enabled(pwm) && !duty_ns)
+ /*
+ * Let the core driver set pwm->period if disabled and duty_ns == 0.
+ * But, this driver should prevent to set the new duty_ns if current
+ * duty_cycle is not set
+ */
+ if (!pwm_is_enabled(pwm) && !duty_ns && !pwm->state.duty_cycle)
return 0;
rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
--
1.9.1
The patch titled
Subject: task_struct: only use anon struct under randstruct plugin
has been added to the -mm tree. Its filename is
task_struct-only-use-anon-struct-under-randstruct-plugin.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/task_struct-only-use-anon-struct-u…
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/task_struct-only-use-anon-struct-u…
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Kees Cook <keescook(a)chromium.org>
Subject: task_struct: only use anon struct under randstruct plugin
The original intent for always adding the anonymous struct in task_struct
was to make sure we had compiler coverage. However, this caused
pathological padding of 40 bytes at the start of task_struct. Instead,
move the anonymous struct to being only used when struct layout
randomization is enabled.
Link: http://lkml.kernel.org/r/20180327213609.GA2964@beast
Fixes: 29e48ce87f1e ("task_struct: Allow randomized")
Signed-off-by: Kees Cook <keescook(a)chromium.org>
Reported-by: Peter Zijlstra <peterz(a)infradead.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Ingo Molnar <mingo(a)kernel.org>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
include/linux/compiler-clang.h | 3 ---
include/linux/compiler-gcc.h | 12 +++---------
2 files changed, 3 insertions(+), 12 deletions(-)
diff -puN include/linux/compiler-clang.h~task_struct-only-use-anon-struct-under-randstruct-plugin include/linux/compiler-clang.h
--- a/include/linux/compiler-clang.h~task_struct-only-use-anon-struct-under-randstruct-plugin
+++ a/include/linux/compiler-clang.h
@@ -17,9 +17,6 @@
*/
#define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__)
-#define randomized_struct_fields_start struct {
-#define randomized_struct_fields_end };
-
/* all clang versions usable with the kernel support KASAN ABI version 5 */
#define KASAN_ABI_VERSION 5
diff -puN include/linux/compiler-gcc.h~task_struct-only-use-anon-struct-under-randstruct-plugin include/linux/compiler-gcc.h
--- a/include/linux/compiler-gcc.h~task_struct-only-use-anon-struct-under-randstruct-plugin
+++ a/include/linux/compiler-gcc.h
@@ -242,6 +242,9 @@
#if defined(RANDSTRUCT_PLUGIN) && !defined(__CHECKER__)
#define __randomize_layout __attribute__((randomize_layout))
#define __no_randomize_layout __attribute__((no_randomize_layout))
+/* This anon struct can add padding, so only enable it under randstruct. */
+#define randomized_struct_fields_start struct {
+#define randomized_struct_fields_end } __randomize_layout;
#endif
#endif /* GCC_VERSION >= 40500 */
@@ -256,15 +259,6 @@
*/
#define __visible __attribute__((externally_visible))
-/*
- * RANDSTRUCT_PLUGIN wants to use an anonymous struct, but it is only
- * possible since GCC 4.6. To provide as much build testing coverage
- * as possible, this is used for all GCC 4.6+ builds, and not just on
- * RANDSTRUCT_PLUGIN builds.
- */
-#define randomized_struct_fields_start struct {
-#define randomized_struct_fields_end } __randomize_layout;
-
#endif /* GCC_VERSION >= 40600 */
_
Patches currently in -mm which might be from keescook(a)chromium.org are
taint-convert-to-indexed-initialization.patch
taint-consolidate-documentation.patch
taint-add-taint-for-randstruct.patch
kernelh-introduce-const_max-for-vla-removal.patch
remove-false-positive-vlas-when-using-max.patch
task_struct-only-use-anon-struct-under-randstruct-plugin.patch
test_bitmap-do-not-accidentally-use-stack-vla.patch
fork-unconditionally-clear-stack-on-fork.patch
exec-pass-stack-rlimit-into-mm-layout-functions.patch
exec-introduce-finalize_exec-before-start_thread.patch
exec-pin-stack-limit-during-exec.patch
exofs-avoid-vla-in-structures.patch
On Fri, 2018-03-02 at 11:57 +0100, Thierry Reding wrote:
> On Thu, Mar 01, 2018 at 04:19:12PM +0800, sean.wang(a)mediatek.com wrote:
> > From: Sean Wang <sean.wang(a)mediatek.com>
> >
> > Since the offset for both registers, PWMDWIDTH and PWMTHRES, used to
> > control PWM4 or PWM5 are distinct from the other PWMs, whose wrong
> > programming on PWM hardware causes waveform cannot be output as expected.
> > Thus, the patch adds the extra condition for fixing up the weird case to
> > let PWM4 or PWM5 able to work on MT7623.
> >
> > v1 -> v2: use pwm45_fixup naming instead of pwm45_quirk
> > v2 -> v3: add more tags for Reviewed-by, Fixes, and Cc stable
> >
> > Cc: stable(a)vger.kernel.org
> > Fixes: caf065f8fd58 ("pwm: Add MediaTek PWM support")
> > Signed-off-by: Sean Wang <sean.wang(a)mediatek.com>
> > Reviewed-by: Matthias Brugger <matthias.bgg(a)gmail.com>
> > Cc: Zhi Mao <zhi.mao(a)mediatek.com>
> > Cc: John Crispin <john(a)phrozen.org>
> > Cc: Matthias Brugger <matthias.bgg(a)gmail.com>
> > ---
> > drivers/pwm/pwm-mediatek.c | 24 +++++++++++++++++++++---
> > 1 file changed, 21 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-mediatek.c b/drivers/pwm/pwm-mediatek.c
> [...]
> > @@ -151,9 +156,18 @@ static int mtk_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
> > return -EINVAL;
> > }
> >
> > + if (pc->soc->pwm45_fixup && pwm->hwpwm > 2) {
> > + /*
> > + * PWM[4,5] has distinct offset for PWMDWIDTH and PWMTHRES
> > + * from the other PWMs on MT7623.
> > + */
> > + reg_width = PWM45DWIDTH_FIXUP;
> > + reg_thres = PWM45THRES_FIXUP;
> > + }
>
> I don't understand this. According to the condition above the above
> would also use the PWM[4,5] "fixup" register offsets with PWM[3]. Should
> the condition be pwm->hwpwm > 3?
>
> Thierry
PWM[4,5] are the naming specified in datasheet and kept it as is here
and driver or userspace would use index 3 and 4 to have a reference to
them respectively.