- Linux-stable-mirror - lists.linaro.org

Re: [Linux-stable-mirror] [PATCH AUTOSEL for-4.9 04/53] spi: imx: adjust watermark level according to transfer length

by Levin, Alexander (Sasha Levin)

On Wed, Nov 08, 2017 at 11:11:11PM +0000, Mark Brown wrote: >On Wed, Nov 08, 2017 at 10:48:14PM +0000, Levin, Alexander (Sasha Levin) wrote: >> On Wed, Nov 08, 2017 at 10:11:02PM +0000, Mark Brown wrote: > >> >expose problems if we start using it. If you look at the history of the >> >driver there's some quirks were added later on for example, and I didn't >> >check the DMA controller drivers or anything and obviously can't see any >> >out of tree code users may have. > >> I'm considering these commits to be on the safer side because they're >> much older than the ones Greg usually grabs. There were no upstream >> fixes to this commit for 10 months now, and given the code changes >> upstream in that subsystem, this patch seemed to be safe to backport. > >Like I say I'm seeing some potentially relevant variant handling added >later and you also have to consider the DMA drivers it might be used >with (imx-dma looks safe but perhaps there's other things, never mind >out of tree code). It just doesn't feel good. > >We have also had problems in the past with SPI performance enhancements >exposing exising problems elsewhere though not so much with this sort of >area so I'm less worried about that. Sure, I'll drop it. Thanks! -- Thanks, Sasha

6 years, 11 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH AUTOSEL for-4.9 04/53] spi: imx: adjust watermark level according to transfer length

by Levin, Alexander (Sasha Levin)

On Wed, Nov 08, 2017 at 10:11:02PM +0000, Mark Brown wrote: >On Wed, Nov 08, 2017 at 09:39:11PM +0000, Levin, Alexander (Sasha Levin) wrote: >> >On Wed, Nov 08, 2017 at 08:49:55PM +0000, Levin, Alexander (Sasha Levin) wrote: >> >This seems like an optimization not a bug fix... > >> Hm, is it? I read it as "DMA is not being used at all even though we >> thought we're using it". > >Yes, that's how I read it too. > >> Yes, the impact is "just" performance, but doesn't it result in quite >> a significat impact? > >Only about double according to the initial commit adding DMA support >which is frankly a bit disappointing although yeah, it's a big win. My >worry is that if there's a problem with DMA on some device for which a >fix wasn't backported (or where we're using a fallback) this could >expose problems if we start using it. If you look at the history of the >driver there's some quirks were added later on for example, and I didn't >check the DMA controller drivers or anything and obviously can't see any >out of tree code users may have. > >*Probably* it doesn't break anything but since it's not fixing anything >and the risk is data corruption I'd be much more comfortable with a more >thorough risk analysis. I'm considering these commits to be on the safer side because they're much older than the ones Greg usually grabs. There were no upstream fixes to this commit for 10 months now, and given the code changes upstream in that subsystem, this patch seemed to be safe to backport. -- Thanks, Sasha

6 years, 11 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH AUTOSEL for-4.9 04/53] spi: imx: adjust watermark level according to transfer length

by Levin, Alexander (Sasha Levin)

On Wed, Nov 08, 2017 at 08:57:52PM +0000, Mark Brown wrote: >On Wed, Nov 08, 2017 at 08:49:55PM +0000, Levin, Alexander (Sasha Levin) wrote: >> From: Jiada Wang <jiada_wang(a)mentor.com> >> >> [ Upstream commit 66459c5a50a787c474b734b586328f7111ab6df0 ] >> >> Previously DMA watermark level is configured to fifosize/2, >> DMA mode can be used only when transfer length can be divided >> by 'watermark level * bpw', which makes DMA mode not pratical. >> >> This patch adjusts watermark level to largest number (no bigger >> than fifosize/2) which can divide 'tranfer length / bpw' for >> each transfer. > >This seems like an optimization not a bug fix... Hm, is it? I read it as "DMA is not being used at all even though we thought we're using it". Yes, the impact is "just" performance, but doesn't it result in quite a significat impact? -- Thanks, Sasha

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] [PATCH 3/3] ASoC: sun8i-codec: Fix left and right channels inversion

by Maxime Ripard

Since its introduction, the codec had an inversion of the left and right channels. It turned out to be pretty simple as it appears that the codec doesn't have the same polarity on the LRCK signal than the I2S block. Fix this by inverting our bit value for the LRCK inversion. Fixes: 36c684936fae ("ASoC: Add sun8i digital audio codec") Cc: <stable(a)vger.kernel.org> Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> --- sound/soc/sunxi/sun8i-codec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c index 522546e6b153..c8dcb1502d74 100644 --- a/sound/soc/sunxi/sun8i-codec.c +++ b/sound/soc/sunxi/sun8i-codec.c @@ -200,7 +200,7 @@ static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) value << SUN8I_AIF1CLK_CTRL_AIF1_BCLK_INV); regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL, BIT(SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV), - value << SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV); + !value << SUN8I_AIF1CLK_CTRL_AIF1_LRCK_INV); /* DAI format */ switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) { -- 2.14.3

6 years, 11 months

3
2
0 0

[Linux-stable-mirror] v4.9.61 build: 0 failures 0 warnings (v4.9.61)

by Build bot for Mark Brown

Tree/Branch: v4.9.61 Git describe: v4.9.61 Commit: 5caae9d141 Linux 4.9.61 Build Time: 82 min 53 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for-3.18 01/27] extcon: palmas: Check the parent instance to prevent the NULL

by Levin, Alexander (Sasha Levin)

From: Roger Quadros <rogerq(a)ti.com> [ Upstream commit 9fe172b9be532acc23e35ba693700383ab775e66 ] extcon-palmas must be child of palmas and expects parent's drvdata to be valid. Check for non NULL parent drvdata and fail if it is NULL. Not doing so will result in a NULL pointer dereference later in the probe() parent drvdata is NULL (e.g. misplaced extcon-palmas node in device tree). Signed-off-by: Roger Quadros <rogerq(a)ti.com> Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- drivers/extcon/extcon-palmas.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c index 230e1220ce48..1cee9f4909db 100644 --- a/drivers/extcon/extcon-palmas.c +++ b/drivers/extcon/extcon-palmas.c @@ -150,6 +150,11 @@ static int palmas_usb_probe(struct platform_device *pdev) struct palmas_usb *palmas_usb; int status; + if (!palmas) { + dev_err(&pdev->dev, "failed to get valid parent\n"); + return -EINVAL; + } + palmas_usb = devm_kzalloc(&pdev->dev, sizeof(*palmas_usb), GFP_KERNEL); if (!palmas_usb) return -ENOMEM; -- 2.11.0

6 years, 11 months

1
26
0 0

[Linux-stable-mirror] [PATCH AUTOSEL for-4.9 01/53] extcon: Remove potential problem when calling extcon_register_notifier()

by Levin, Alexander (Sasha Levin)

From: Chanwoo Choi <cw00.choi(a)samsung.com> [ Upstream commit 01b4c9a1ae07a25d208cad0da7dd288007a22984 ] This patch removes the potential problem of extcon_register_notifier() when edev parameter is NULL. When edev is NULL, this function returns the first extcon device which includes the sepecific external connector of second paramter. But, it don't guarantee the same operation in all cases. To remove this confusion and potential problem, this patch fixes it. Signed-off-by: Chanwoo Choi <cw00.choi(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> --- drivers/extcon/extcon.c | 33 +++++++-------------------------- 1 file changed, 7 insertions(+), 26 deletions(-) diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c index 7c1e3a7b14e0..d0e367959c91 100644 --- a/drivers/extcon/extcon.c +++ b/drivers/extcon/extcon.c @@ -906,35 +906,16 @@ int extcon_register_notifier(struct extcon_dev *edev, unsigned int id, unsigned long flags; int ret, idx = -EINVAL; - if (!nb) + if (!edev || !nb) return -EINVAL; - if (edev) { - idx = find_cable_index_by_id(edev, id); - if (idx < 0) - return idx; - - spin_lock_irqsave(&edev->lock, flags); - ret = raw_notifier_chain_register(&edev->nh[idx], nb); - spin_unlock_irqrestore(&edev->lock, flags); - } else { - struct extcon_dev *extd; - - mutex_lock(&extcon_dev_list_lock); - list_for_each_entry(extd, &extcon_dev_list, entry) { - idx = find_cable_index_by_id(extd, id); - if (idx >= 0) - break; - } - mutex_unlock(&extcon_dev_list_lock); + idx = find_cable_index_by_id(edev, id); + if (idx < 0) + return idx; - if (idx >= 0) { - edev = extd; - return extcon_register_notifier(extd, id, nb); - } else { - ret = -ENODEV; - } - } + spin_lock_irqsave(&edev->lock, flags); + ret = raw_notifier_chain_register(&edev->nh[idx], nb); + spin_unlock_irqrestore(&edev->lock, flags); return ret; } -- 2.11.0

6 years, 11 months

1
52
0 0

Re: [Linux-stable-mirror] [PATCH v2] lib/mpi: call cond_resched() from mpi_powm() loop

by David Howells

Eric Biggers <ebiggers3(a)gmail.com> wrote: > On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the > largest permitted inputs (16384 bits), the kernel spends 10+ seconds > doing modular exponentiation in mpi_powm() without rescheduling. If all > threads do it, it locks up the system. Moreover, it can cause > rcu_sched-stall warnings. Do you want this to go in immediately, or I should I push it to James for the next merge window? David

6 years, 11 months

3
4
0 0

Re: [Linux-stable-mirror] [PATCH] drm/edid: Don't send non-zero YQ in AVI infoframe for HDMI 1.x sinks

by Ville Syrjälä

On Wed, Nov 08, 2017 at 12:17:28PM -0800, Eric Anholt wrote: > Ville Syrjala <ville.syrjala(a)linux.intel.com> writes: > > > From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> > > > > Apparently some sinks look at the YQ bits even when receiving RGB, > > and they get somehow confused when they see a non-zero YQ value. > > So we can't just blindly follow CEA-861-F and set YQ to match the > > RGB range. > > > > Unfortunately there is no good way to tell whether the sink > > designer claims to have read CEA-861-F. The CEA extension block > > revision number has generally been stuck at 3 since forever, > > and even a very recently manufactured sink might be based on > > an old design so the manufacturing date doesn't seem like > > something we can use. In lieu of better information let's > > follow CEA-861-F only for HDMI 2.0 sinks, since HDMI 2.0 is > > based on CEA-861-F. For HDMI 1.x sinks we'll always set YQ=0. > > > > The alternative would of course be to always set YQ=0. And if > > we ever encounter a HDMI 2.0+ sink with this bug that's what > > we'll probably have to do. > > Should vc4 be doing anything special for HDMI2 sinks, if it's an HDMI1.4 > source? As long as you stick to < 340 MHz modes you shouldn't have to do anything. For >=340 MHz you'd need to use some new HDMI 2.0 features. Looks like vc4 crtc .mode_valid() doesn't do much. I presume it's up to bridges/encoders to filter out most things that aren't supported? > > That said, as far as vc4, this patch is > > Acked-by: Eric Anholt <eric(a)anholt.net> Ta. -- Ville Syrjälä Intel OTC

6 years, 11 months

1
0
0 0

[Linux-stable-mirror] v4.4.97 build: 0 failures 0 warnings (v4.4.97)

by Build bot for Mark Brown

Tree/Branch: v4.4.97 Git describe: v4.4.97 Commit: c54d0707aa Linux 4.4.97 Build Time: 71 min 11 sec Passed: 9 / 9 (100.00 %) Failed: 0 / 9 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

6 years, 11 months

1
0
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror