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

[PATCH v4 0/3] virtio-balloon: tweak config_changed

by Wei Wang

Since virtio-ccw doesn't work with accessing to the config space inside an interrupt context, this patch series avoids that issue by moving the config register accesses to the related workqueue contexts. v3->v4 ChangeLog: - change virtio32_to_cpu to cpu_to_virtio_32 in send_cmd_id_start; v2->v3 ChangeLog: - rename cmd_id_received to cmd_id_received_cache, and have call sites read the latest value via virtio_balloon_cmd_id_received. (Still kept Cornelia and Halil's reviewed-by as it's a minor change) - remove zeroing vb->num_free_page_blocks in probe since vb is allocated via kzalloc. v1->v2 ChangeLog: - add config_read_bitmap to indicate to the workqueue callbacks about the necessity of reading the related config fields. Wei Wang (3): virtio-balloon: tweak config_changed implementation virtio-balloon: improve update_balloon_size_func virtio_balloon: remove the unnecessary 0-initialization drivers/virtio/virtio_balloon.c | 104 ++++++++++++++++++++++++++-------------- 1 file changed, 69 insertions(+), 35 deletions(-) -- 2.7.4

6 years, 9 months

2
6
0 0

[PATCH 2/3] drm/amdgpu: Don't fail resume process if resuming atomic state fails

by Lyude Paul

This is an ugly one unfortunately. Currently, all DRM drivers supporting atomic modesetting will save the state that userspace had set before suspending, then attempt to restore that state on resume. This probably worked very well at one point, like many other things, until DP MST came into the picture. While it's easy to restore state on normal display connectors that were disconnected during suspend regardless of their state post-resume, this can't really be done with MST because of the fact that setting up a downstream sink requires performing sideband transactions between the source and the MST hub, sending out the ACT packets, etc. Because of this, there isn't really a guarantee that we can restore the atomic state we had before suspend once we've resumed. This sucks pretty bad, but so far I haven't run into any compositors that this actually causes serious issues with. Most compositors will notice the hotplug we send afterwards, and then reprobe state. Since nouveau and i915 also don't fail the suspend/resume process due to failing to restore the atomic state, let's make amdgpu match this behavior. Better to resume the GPU properly, then to stop the process half way because of a potentially unavoidable atomic commit failure. Eventually, we'll have a real fix for this problem on the DRM level. But we've got some more important low-hanging fruit to deal with first. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Jerry Zuo <Jerry.Zuo(a)amd.com> Cc: <stable(a)vger.kernel.org> # v4.15+ --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 3f326a2c513b..a3e65e457348 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -912,7 +912,6 @@ static int dm_resume(void *handle) struct drm_plane_state *new_plane_state; struct dm_plane_state *dm_new_plane_state; enum dc_connection_type new_connection_type = dc_connection_none; - int ret; int i; /* power on hardware */ @@ -985,13 +984,13 @@ static int dm_resume(void *handle) } } - ret = drm_atomic_helper_resume(ddev, dm->cached_state); + drm_atomic_helper_resume(ddev, dm->cached_state); dm->cached_state = NULL; amdgpu_dm_irq_resume_late(adev); - return ret; + return 0; } /** -- 2.20.1

6 years, 9 months

1
0
0 0

[PATCH 1/3] drm/amdgpu: Don't ignore rc from drm_dp_mst_topology_mgr_resume()

by Lyude Paul

drm_dp_mst_topology_mgr_resume() returns whether or not it managed to find the topology in question after a suspend resume cycle, and the driver is supposed to check this value and disable MST accordingly if it's gone-in addition to sending a hotplug in order to notify userspace that something changed during suspend. Currently, amdgpu just makes the mistake of ignoring the return code from drm_dp_mst_topology_mgr_resume() which means that if a topology was removed in suspend, amdgpu never notices and assumes it's still connected which leads to all sorts of problems. So, fix this by actually checking the rc from drm_dp_mst_topology_mgr_resume(). Also, reformat the rest of the function while we're at it to fix the over-indenting. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: Jerry Zuo <Jerry.Zuo(a)amd.com> Cc: <stable(a)vger.kernel.org> # v4.15+ --- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 32 +++++++++++++------ 1 file changed, 23 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 8a626d16e8e3..3f326a2c513b 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -699,22 +699,36 @@ static void s3_handle_mst(struct drm_device *dev, bool suspend) { struct amdgpu_dm_connector *aconnector; struct drm_connector *connector; + struct drm_dp_mst_topology_mgr *mgr; + int ret; + bool need_hotplug = false; drm_modeset_lock(&dev->mode_config.connection_mutex, NULL); - list_for_each_entry(connector, &dev->mode_config.connector_list, head) { - aconnector = to_amdgpu_dm_connector(connector); - if (aconnector->dc_link->type == dc_connection_mst_branch && - !aconnector->mst_port) { + list_for_each_entry(connector, &dev->mode_config.connector_list, + head) { + aconnector = to_amdgpu_dm_connector(connector); + if (aconnector->dc_link->type != dc_connection_mst_branch || + aconnector->mst_port) + continue; + + mgr = &aconnector->mst_mgr; - if (suspend) - drm_dp_mst_topology_mgr_suspend(&aconnector->mst_mgr); - else - drm_dp_mst_topology_mgr_resume(&aconnector->mst_mgr); - } + if (suspend) { + drm_dp_mst_topology_mgr_suspend(mgr); + } else { + ret = drm_dp_mst_topology_mgr_resume(mgr); + if (ret < 0) { + drm_dp_mst_topology_mgr_set_mst(mgr, false); + need_hotplug = true; + } + } } drm_modeset_unlock(&dev->mode_config.connection_mutex); + + if (need_hotplug) + drm_kms_helper_hotplug_event(dev); } /** -- 2.20.1

6 years, 9 months

1
0
0 0

stable-rc/linux-4.9.y boot: 99 boots: 0 failed, 98 passed with 1 offline (v4.9.148-69-gd1d800b1ed7a)

by kernelci.org bot

stable-rc/linux-4.9.y boot: 99 boots: 0 failed, 98 passed with 1 offline (v4.9.148-69-gd1d800b1ed7a) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.148-69-… Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.148-69-gd1d800b1ed7a Git Commit: d1d800b1ed7ab74a26df74ce1f95d5f49f36d717 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 48 unique boards, 20 SoC families, 13 builds out of 193 Offline Platforms: arm64: defconfig: meson-gxbb-odroidc2: 1 offline lab --- For more info write to <info(a)kernelci.org>

6 years, 9 months

1
0
0 0

[PATCH for-rc] RDMA/vmw_pvrdma: Return the correct opcode when creating WR

by Adit Ranadive

From: Adit Ranadive <aditr(a)vmware.com> Since the IB_WR_REG_MR opcode value changed, set some of the PVRDMA device opcodes explicitly. Reported-by: Ruishuang Wang <ruishuangw(a)vmware.com> Fixes: 9a59739bd01f ("IB/rxe: Revise the ib_wr_opcode enum") Cc: stable(a)vger.kernel.org Reviewed-by: Bryan Tan <bryantan(a)vmware.com> Reviewed-by: Ruishuang Wang <ruishuangw(a)vmware.com> Reviewed-by: Vishnu Dasa <vdasa(a)vmware.com> Signed-off-by: Adit Ranadive <aditr(a)vmware.com> --- drivers/infiniband/hw/vmw_pvrdma/pvrdma.h | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/vmw_pvrdma/pvrdma.h b/drivers/infiniband/hw/vmw_pvrdma/pvrdma.h index 42b8685c997e..c2ed09e66d2b 100644 --- a/drivers/infiniband/hw/vmw_pvrdma/pvrdma.h +++ b/drivers/infiniband/hw/vmw_pvrdma/pvrdma.h @@ -427,7 +427,26 @@ static inline enum ib_qp_state pvrdma_qp_state_to_ib(enum pvrdma_qp_state state) static inline enum pvrdma_wr_opcode ib_wr_opcode_to_pvrdma(enum ib_wr_opcode op) { - return (enum pvrdma_wr_opcode)op; + switch (op) { + case IB_WR_LSO: + return PVRDMA_WR_LSO; + case IB_WR_SEND_WITH_INV: + return PVRDMA_WR_SEND_WITH_INV; + case IB_WR_RDMA_READ_WITH_INV: + return PVRDMA_WR_RDMA_READ_WITH_INV; + case IB_WR_LOCAL_INV: + return PVRDMA_WR_LOCAL_INV; + case IB_WR_REG_MR: + return PVRDMA_WR_FAST_REG_MR; + case IB_WR_MASKED_ATOMIC_CMP_AND_SWP: + return PVRDMA_WR_MASKED_ATOMIC_CMP_AND_SWP; + case IB_WR_MASKED_ATOMIC_FETCH_AND_ADD: + return PVRDMA_WR_MASKED_ATOMIC_FETCH_AND_ADD; + case IB_WR_REG_SIG_MR: + return PVRDMA_WR_REG_SIG_MR; + default: + return (enum pvrdma_wr_opcode)op; + } } static inline enum ib_wc_status pvrdma_wc_status_to_ib( -- 1.8.3.1

6 years, 9 months

2
4
0 0

stable-rc/linux-4.14.y boot: 115 boots: 1 failed, 112 passed with 1 offline, 1 conflict (v4.14.91-100-g31e3578310df)

by kernelci.org bot

stable-rc/linux-4.14.y boot: 115 boots: 1 failed, 112 passed with 1 offline, 1 conflict (v4.14.91-100-g31e3578310df) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.1… Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.91-10… Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.91-100-g31e3578310df Git Commit: 31e3578310df91929c04f756c7829b6c551604c3 Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 61 unique boards, 22 SoC families, 12 builds out of 197 Boot Failure Detected: arm64: defconfig rk3399-firefly: 1 failed lab Offline Platforms: arm64: defconfig: meson-gxbb-odroidc2: 1 offline lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm64: defconfig: meson-gxl-s905x-libretech-cc: lab-baylibre-seattle: FAIL lab-baylibre: PASS --- For more info write to <info(a)kernelci.org>

6 years, 9 months

1
0
0 0

Applied "ASoC: tlv320aic32x4: Kernel OOPS while entering DAPM standby mode" to the asoc tree

by Mark Brown

The patch ASoC: tlv320aic32x4: Kernel OOPS while entering DAPM standby mode 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 667e9334fa64da2273e36ce131b05ac9e47c5769 Mon Sep 17 00:00:00 2001 From: b-ak <anur.bhargav(a)gmail.com> Date: Mon, 7 Jan 2019 22:30:22 +0530 Subject: [PATCH] ASoC: tlv320aic32x4: Kernel OOPS while entering DAPM standby mode During the bootup of the kernel, the DAPM bias level is in the OFF state. As soon as the DAPM framework kicks in it pushes the codec into STANDBY state. The probe function doesn't prepare the clock, and STANDBY state does a clk_disable_unprepare() without checking the previous state. This leads to an OOPS. Not transitioning from an OFF state to the STANDBY state fixes the problem. Signed-off-by: b-ak <anur.bhargav(a)gmail.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- sound/soc/codecs/tlv320aic32x4.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/sound/soc/codecs/tlv320aic32x4.c b/sound/soc/codecs/tlv320aic32x4.c index e2b5a11b16d1..f03195d2ab2e 100644 --- a/sound/soc/codecs/tlv320aic32x4.c +++ b/sound/soc/codecs/tlv320aic32x4.c @@ -822,6 +822,10 @@ static int aic32x4_set_bias_level(struct snd_soc_component *component, case SND_SOC_BIAS_PREPARE: break; case SND_SOC_BIAS_STANDBY: + /* Initial cold start */ + if (snd_soc_component_get_bias_level(component) == SND_SOC_BIAS_OFF) + break; + /* Switch off BCLK_N Divider */ snd_soc_component_update_bits(component, AIC32X4_BCLKN, AIC32X4_BCLKEN, 0); -- 2.20.1

6 years, 9 months

1
0
0 0

Applied "ASoC: atom: fix a missing check of snd_pcm_lib_malloc_pages" to the asoc tree

by Mark Brown

The patch ASoC: atom: fix a missing check of snd_pcm_lib_malloc_pages 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 44fabd8cdaaa3acb80ad2bb3b5c61ae2136af661 Mon Sep 17 00:00:00 2001 From: Kangjie Lu <kjlu(a)umn.edu> Date: Tue, 25 Dec 2018 20:29:48 -0600 Subject: [PATCH] ASoC: atom: fix a missing check of snd_pcm_lib_malloc_pages snd_pcm_lib_malloc_pages() may fail, so let's check its status and return its error code upstream. Signed-off-by: Kangjie Lu <kjlu(a)umn.edu> Acked-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- sound/soc/intel/atom/sst-mfld-platform-pcm.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/sound/soc/intel/atom/sst-mfld-platform-pcm.c b/sound/soc/intel/atom/sst-mfld-platform-pcm.c index afc559866095..91a2436ce952 100644 --- a/sound/soc/intel/atom/sst-mfld-platform-pcm.c +++ b/sound/soc/intel/atom/sst-mfld-platform-pcm.c @@ -399,7 +399,13 @@ static int sst_media_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params, struct snd_soc_dai *dai) { - snd_pcm_lib_malloc_pages(substream, params_buffer_bytes(params)); + int ret; + + ret = + snd_pcm_lib_malloc_pages(substream, + params_buffer_bytes(params)); + if (ret) + return ret; memset(substream->runtime->dma_area, 0, params_buffer_bytes(params)); return 0; } -- 2.20.1

6 years, 9 months

1
0
0 0

Re: [PATCH v2] Bluetooth: Fix locking in bt_accept_enqueue() for BH context

by Doug Anderson

Hi, On Wed, Jan 2, 2019 at 4:11 PM Matthias Kaehlcke <mka(a)chromium.org> wrote: > > With commit e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket > atomically") lock_sock[_nested]() is used to acquire the socket lock > before manipulating the socket. lock_sock[_nested]() may block, which > is problematic since bt_accept_enqueue() can be called in bottom half > context (e.g. from rfcomm_connect_ind()): > > [<ffffff80080d81ec>] __might_sleep+0x4c/0x80 > [<ffffff800876c7b0>] lock_sock_nested+0x24/0x58 > [<ffffff8000d7c27c>] bt_accept_enqueue+0x48/0xd4 [bluetooth] > [<ffffff8000e67d8c>] rfcomm_connect_ind+0x190/0x218 [rfcomm] > > Add a parameter to bt_accept_enqueue() to indicate whether the > function is called from BH context, and acquire the socket lock > with bh_lock_sock_nested() if that's the case. > > Also adapt all callers of bt_accept_enqueue() to pass the new > parameter: > > - l2cap_sock_new_connection_cb() > - uses lock_sock() to lock the parent socket => process context > > - rfcomm_connect_ind() > - acquires the parent socket lock with bh_lock_sock() => BH > context > > - __sco_chan_add() > - called from sco_chan_add(), which is called from sco_connect(). > parent is NULL, hence bt_accept_enqueue() isn't called in this > code path and we can ignore it > - also called from sco_conn_ready(). uses bh_lock_sock() to acquire > the parent lock => BH context > > Fixes: e16337622016 ("Bluetooth: Handle bt_accept_enqueue() socket atomically") > Signed-off-by: Matthias Kaehlcke <mka(a)chromium.org> > --- > Changes in v2: > - use parameter in bt_accept_enqueue() to decide which lock to > acquire and adapt all callers > - updated commit message > --- > include/net/bluetooth/bluetooth.h | 2 +- > net/bluetooth/af_bluetooth.c | 16 +++++++++++++--- > net/bluetooth/l2cap_sock.c | 2 +- > net/bluetooth/rfcomm/sock.c | 2 +- > net/bluetooth/sco.c | 2 +- > 5 files changed, 17 insertions(+), 7 deletions(-) This looks nice to me, thanks! Cc: stable(a)vger.kernel.org Reviewed-by: Douglas Anderson <dianders(a)chromium.org>

6 years, 9 months

1
0
0 0

[git:media_tree/master] media: lgdt330x: fix lock status reporting

by Mauro Carvalho Chehab

This is an automatic generated email to let you know that the following patch were queued: Subject: media: lgdt330x: fix lock status reporting Author: French, Nicholas A <naf(a)ou.edu> Date: Sun Dec 9 02:11:18 2018 -0500 A typo in code cleanup commit db9c1007bc07 ("media: lgdt330x: do some cleanups at status logic") broke the FE_HAS_LOCK reporting for 3303 chips by inadvertently modifying the register mask. The broken lock status is critial as it prevents video capture cards from reporting signal strength, scanning for channels, and capturing video. Fix regression by reverting mask change. Cc: stable(a)vger.kernel.org # Kernel 4.17+ Fixes: db9c1007bc07 ("media: lgdt330x: do some cleanups at status logic") Signed-off-by: Nick French <naf(a)ou.edu> Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Tested-by: Adam Stylinski <kungfujesus06(a)gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung(a)kernel.org> drivers/media/dvb-frontends/lgdt330x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- diff --git a/drivers/media/dvb-frontends/lgdt330x.c b/drivers/media/dvb-frontends/lgdt330x.c index 96807e134886..8abb1a510a81 100644 --- a/drivers/media/dvb-frontends/lgdt330x.c +++ b/drivers/media/dvb-frontends/lgdt330x.c @@ -783,7 +783,7 @@ static int lgdt3303_read_status(struct dvb_frontend *fe, if ((buf[0] & 0x02) == 0x00) *status |= FE_HAS_SYNC; - if ((buf[0] & 0xfd) == 0x01) + if ((buf[0] & 0x01) == 0x01) *status |= FE_HAS_VITERBI | FE_HAS_LOCK; break; default:

6 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror