This is a note to let you know that I've just added the patch titled
iio: chemical: ccs811: Corrected firmware boot/application mode transition
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iio-chemical-ccs811-corrected-firmware-boot-application-mode-transition.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b91e146c38b003c899710ede6d05fc824675e386 Mon Sep 17 00:00:00 2001
From: Richard Lai <richard(a)richardman.com>
Date: Sat, 17 Feb 2018 16:28:24 +0000
Subject: iio: chemical: ccs811: Corrected firmware boot/application mode transition
From: Richard Lai <richard(a)richardman.com>
commit b91e146c38b003c899710ede6d05fc824675e386 upstream.
CCS811 has different I2C register maps in boot and application mode. When
CCS811 is in boot mode, register APP_START (0xF4) is used to transit the
firmware state from boot to application mode. However, APP_START is not a
valid register location when CCS811 is in application mode (refer to
"CCS811 Bootloader Register Map" and "CCS811 Application Register Map" in
CCS811 datasheet). The driver should not attempt to perform a write to
APP_START while CCS811 is in application mode, as this is not a valid or
documented register location.
When prob function is being called, the driver assumes the CCS811 sensor
is in boot mode, and attempts to perform a write to APP_START. Although
CCS811 powers-up in boot mode, it may have already been transited to
application mode by previous instances, e.g. unload and reload device
driver by the system, or explicitly by user. Depending on the system
design, CCS811 sensor may be permanently connected to system power source
rather than power controlled by GPIO, hence it is possible that the sensor
is never power reset, thus the firmware could be in either boot or
application mode at any given time when driver prob function is being
called.
This patch checks the STATUS register before attempting to send a write to
APP_START. Only if the firmware is not in application mode and has valid
firmware application loaded, then it will continue to start transiting the
firmware boot to application mode.
Signed-off-by: Richard Lai <richard(a)richardman.com>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/chemical/ccs811.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/iio/chemical/ccs811.c
+++ b/drivers/iio/chemical/ccs811.c
@@ -133,6 +133,9 @@ static int ccs811_start_sensor_applicati
if (ret < 0)
return ret;
+ if ((ret & CCS811_STATUS_FW_MODE_APPLICATION))
+ return 0;
+
if ((ret & CCS811_STATUS_APP_VALID_MASK) !=
CCS811_STATUS_APP_VALID_LOADED)
return -EIO;
Patches currently in stable-queue which might be from richard(a)richardman.com are
queue-4.15/iio-chemical-ccs811-corrected-firmware-boot-application-mode-transition.patch
This is a note to let you know that I've just added the patch titled
iio: adc: meson-saradc: unlock on error in meson_sar_adc_lock()
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
iio-adc-meson-saradc-unlock-on-error-in-meson_sar_adc_lock.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 3c3e4b3a708a9d6451052e348981f37d2b3e92b0 Mon Sep 17 00:00:00 2001
From: Dan Carpenter <dan.carpenter(a)oracle.com>
Date: Thu, 8 Mar 2018 12:31:53 +0300
Subject: iio: adc: meson-saradc: unlock on error in meson_sar_adc_lock()
From: Dan Carpenter <dan.carpenter(a)oracle.com>
commit 3c3e4b3a708a9d6451052e348981f37d2b3e92b0 upstream.
The meson_sar_adc_lock() function is not supposed to hold the
"indio_dev->mlock" on the error path.
Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs")
Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com>
Cc: <Stable(a)vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/iio/adc/meson_saradc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/iio/adc/meson_saradc.c
+++ b/drivers/iio/adc/meson_saradc.c
@@ -462,8 +462,10 @@ static int meson_sar_adc_lock(struct iio
regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val);
} while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--);
- if (timeout < 0)
+ if (timeout < 0) {
+ mutex_unlock(&indio_dev->mlock);
return -ETIMEDOUT;
+ }
}
return 0;
Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are
queue-4.15/iio-adc-meson-saradc-unlock-on-error-in-meson_sar_adc_lock.patch
This is a note to let you know that I've just added the patch titled
Drivers: hv: vmbus: Fix ring buffer signaling
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drivers-hv-vmbus-fix-ring-buffer-signaling.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 655296c8bbeffcf020558c4455305d597a73bde1 Mon Sep 17 00:00:00 2001
From: Michael Kelley <mhkelley(a)outlook.com>
Date: Sun, 4 Mar 2018 22:24:08 -0700
Subject: Drivers: hv: vmbus: Fix ring buffer signaling
From: Michael Kelley <mhkelley(a)outlook.com>
commit 655296c8bbeffcf020558c4455305d597a73bde1 upstream.
Fix bugs in signaling the Hyper-V host when freeing space in the
host->guest ring buffer:
1. The interrupt_mask must not be used to determine whether to signal
on the host->guest ring buffer
2. The ring buffer write_index must be read (via hv_get_bytes_to_write)
*after* pending_send_sz is read in order to avoid a race condition
3. Comparisons with pending_send_sz must treat the "equals" case as
not-enough-space
4. Don't signal if the pending_send_sz feature is not present. Older
versions of Hyper-V that don't implement this feature will poll.
Fixes: 03bad714a161 ("vmbus: more host signalling avoidance")
Cc: Stable <stable(a)vger.kernel.org> # 4.14 and above
Signed-off-by: Michael Kelley <mhkelley(a)outlook.com>
Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hv/ring_buffer.c | 54 +++++++++++++++++++++++++++++++----------------
1 file changed, 36 insertions(+), 18 deletions(-)
--- a/drivers/hv/ring_buffer.c
+++ b/drivers/hv/ring_buffer.c
@@ -394,13 +394,24 @@ __hv_pkt_iter_next(struct vmbus_channel
}
EXPORT_SYMBOL_GPL(__hv_pkt_iter_next);
+/* How many bytes were read in this iterator cycle */
+static u32 hv_pkt_iter_bytes_read(const struct hv_ring_buffer_info *rbi,
+ u32 start_read_index)
+{
+ if (rbi->priv_read_index >= start_read_index)
+ return rbi->priv_read_index - start_read_index;
+ else
+ return rbi->ring_datasize - start_read_index +
+ rbi->priv_read_index;
+}
+
/*
* Update host ring buffer after iterating over packets.
*/
void hv_pkt_iter_close(struct vmbus_channel *channel)
{
struct hv_ring_buffer_info *rbi = &channel->inbound;
- u32 orig_write_sz = hv_get_bytes_to_write(rbi);
+ u32 curr_write_sz, pending_sz, bytes_read, start_read_index;
/*
* Make sure all reads are done before we update the read index since
@@ -408,8 +419,12 @@ void hv_pkt_iter_close(struct vmbus_chan
* is updated.
*/
virt_rmb();
+ start_read_index = rbi->ring_buffer->read_index;
rbi->ring_buffer->read_index = rbi->priv_read_index;
+ if (!rbi->ring_buffer->feature_bits.feat_pending_send_sz)
+ return;
+
/*
* Issue a full memory barrier before making the signaling decision.
* Here is the reason for having this barrier:
@@ -423,26 +438,29 @@ void hv_pkt_iter_close(struct vmbus_chan
*/
virt_mb();
- /* If host has disabled notifications then skip */
- if (rbi->ring_buffer->interrupt_mask)
+ pending_sz = READ_ONCE(rbi->ring_buffer->pending_send_sz);
+ if (!pending_sz)
return;
- if (rbi->ring_buffer->feature_bits.feat_pending_send_sz) {
- u32 pending_sz = READ_ONCE(rbi->ring_buffer->pending_send_sz);
+ /*
+ * Ensure the read of write_index in hv_get_bytes_to_write()
+ * happens after the read of pending_send_sz.
+ */
+ virt_rmb();
+ curr_write_sz = hv_get_bytes_to_write(rbi);
+ bytes_read = hv_pkt_iter_bytes_read(rbi, start_read_index);
+
+ /*
+ * If there was space before we began iteration,
+ * then host was not blocked.
+ */
- /*
- * If there was space before we began iteration,
- * then host was not blocked. Also handles case where
- * pending_sz is zero then host has nothing pending
- * and does not need to be signaled.
- */
- if (orig_write_sz > pending_sz)
- return;
-
- /* If pending write will not fit, don't give false hope. */
- if (hv_get_bytes_to_write(rbi) < pending_sz)
- return;
- }
+ if (curr_write_sz - bytes_read > pending_sz)
+ return;
+
+ /* If pending write will not fit, don't give false hope. */
+ if (curr_write_sz <= pending_sz)
+ return;
vmbus_setevent(channel);
}
Patches currently in stable-queue which might be from mhkelley(a)outlook.com are
queue-4.15/drivers-hv-vmbus-fix-ring-buffer-signaling.patch
This is a note to let you know that I've just added the patch titled
clk: sunxi-ng: a31: Fix CLK_OUT_* clock ops
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-sunxi-ng-a31-fix-clk_out_-clock-ops.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 5682e268350f9eccdbb04006605c1b7068a7b323 Mon Sep 17 00:00:00 2001
From: Chen-Yu Tsai <wens(a)csie.org>
Date: Sat, 17 Feb 2018 21:05:04 +0800
Subject: clk: sunxi-ng: a31: Fix CLK_OUT_* clock ops
From: Chen-Yu Tsai <wens(a)csie.org>
commit 5682e268350f9eccdbb04006605c1b7068a7b323 upstream.
When support for the A31/A31s CCU was first added, the clock ops for
the CLK_OUT_* clocks was set to the wrong type. The clocks are MP-type,
but the ops was set for div (M) clocks. This went unnoticed until now.
This was because while they are different clocks, their data structures
aligned in a way that ccu_div_ops would access the second ccu_div_internal
and ccu_mux_internal structures, which were valid, if not incorrect.
Furthermore, the use of these CLK_OUT_* was for feeding a precise 32.768
kHz clock signal to the WiFi chip. This was achievable by using the parent
with the same clock rate and no divider. So the incorrect divider setting
did not affect this usage.
Commit 946797aa3f08 ("clk: sunxi-ng: Support fixed post-dividers on MP
style clocks") added a new field to the ccu_mp structure, which broke
the aforementioned alignment. Now the system crashes as div_ops tries
to look up a nonexistent table.
Reported-by: Philipp Rossak <embed3d(a)gmail.com>
Tested-by: Philipp Rossak <embed3d(a)gmail.com>
Fixes: c6e6c96d8fa6 ("clk: sunxi-ng: Add A31/A31s clocks")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Chen-Yu Tsai <wens(a)csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard(a)bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/sunxi-ng/ccu-sun6i-a31.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-a31.c
@@ -762,7 +762,7 @@ static struct ccu_mp out_a_clk = {
.features = CCU_FEATURE_FIXED_PREDIV,
.hw.init = CLK_HW_INIT_PARENTS("out-a",
clk_out_parents,
- &ccu_div_ops,
+ &ccu_mp_ops,
0),
},
};
@@ -783,7 +783,7 @@ static struct ccu_mp out_b_clk = {
.features = CCU_FEATURE_FIXED_PREDIV,
.hw.init = CLK_HW_INIT_PARENTS("out-b",
clk_out_parents,
- &ccu_div_ops,
+ &ccu_mp_ops,
0),
},
};
@@ -804,7 +804,7 @@ static struct ccu_mp out_c_clk = {
.features = CCU_FEATURE_FIXED_PREDIV,
.hw.init = CLK_HW_INIT_PARENTS("out-c",
clk_out_parents,
- &ccu_div_ops,
+ &ccu_mp_ops,
0),
},
};
Patches currently in stable-queue which might be from wens(a)csie.org are
queue-4.15/clk-sunxi-ng-a31-fix-clk_out_-clock-ops.patch
This is a note to let you know that I've just added the patch titled
clk: bcm2835: Protect sections updating shared registers
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-bcm2835-protect-sections-updating-shared-registers.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 7997f3b2df751aab0b8e60149b226a32966c41ac Mon Sep 17 00:00:00 2001
From: Boris Brezillon <boris.brezillon(a)bootlin.com>
Date: Thu, 8 Feb 2018 14:43:36 +0100
Subject: clk: bcm2835: Protect sections updating shared registers
From: Boris Brezillon <boris.brezillon(a)bootlin.com>
commit 7997f3b2df751aab0b8e60149b226a32966c41ac upstream.
CM_PLLx and A2W_XOSC_CTRL registers are accessed by different clock
handlers and must be accessed with ->regs_lock held.
Update the sections where this protection is missing.
Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Reviewed-by: Eric Anholt <eric(a)anholt.net>
Signed-off-by: Stephen Boyd <sboyd(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/bcm/clk-bcm2835.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -623,8 +623,10 @@ static int bcm2835_pll_on(struct clk_hw
~A2W_PLL_CTRL_PWRDN);
/* Take the PLL out of reset. */
+ spin_lock(&cprman->regs_lock);
cprman_write(cprman, data->cm_ctrl_reg,
cprman_read(cprman, data->cm_ctrl_reg) & ~CM_PLL_ANARST);
+ spin_unlock(&cprman->regs_lock);
/* Wait for the PLL to lock. */
timeout = ktime_add_ns(ktime_get(), LOCK_TIMEOUT_NS);
@@ -701,9 +703,11 @@ static int bcm2835_pll_set_rate(struct c
}
/* Unmask the reference clock from the oscillator. */
+ spin_lock(&cprman->regs_lock);
cprman_write(cprman, A2W_XOSC_CTRL,
cprman_read(cprman, A2W_XOSC_CTRL) |
data->reference_enable_mask);
+ spin_unlock(&cprman->regs_lock);
if (do_ana_setup_first)
bcm2835_pll_write_ana(cprman, data->ana_reg_base, ana);
Patches currently in stable-queue which might be from boris.brezillon(a)bootlin.com are
queue-4.15/clk-bcm2835-protect-sections-updating-shared-registers.patch
queue-4.15/clk-bcm2835-fix-ana-maskx-definitions.patch
This is a note to let you know that I've just added the patch titled
clk: bcm2835: Fix ana->maskX definitions
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
clk-bcm2835-fix-ana-maskx-definitions.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 49012d1bf5f78782d398adb984a080a88ba42965 Mon Sep 17 00:00:00 2001
From: Boris Brezillon <boris.brezillon(a)bootlin.com>
Date: Thu, 8 Feb 2018 14:43:35 +0100
Subject: clk: bcm2835: Fix ana->maskX definitions
From: Boris Brezillon <boris.brezillon(a)bootlin.com>
commit 49012d1bf5f78782d398adb984a080a88ba42965 upstream.
ana->maskX values are already '~'-ed in bcm2835_pll_set_rate(). Remove
the '~' in the definition to fix ANA setup.
Note that this commit fixes a long standing bug preventing one from
using an HDMI display if it's plugged after the FW has booted Linux.
This is because PLLH is used by the HDMI encoder to generate the pixel
clock.
Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks")
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com>
Reviewed-by: Eric Anholt <eric(a)anholt.net>
Signed-off-by: Stephen Boyd <sboyd(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/clk/bcm/clk-bcm2835.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -449,17 +449,17 @@ struct bcm2835_pll_ana_bits {
static const struct bcm2835_pll_ana_bits bcm2835_ana_default = {
.mask0 = 0,
.set0 = 0,
- .mask1 = (u32)~(A2W_PLL_KI_MASK | A2W_PLL_KP_MASK),
+ .mask1 = A2W_PLL_KI_MASK | A2W_PLL_KP_MASK,
.set1 = (2 << A2W_PLL_KI_SHIFT) | (8 << A2W_PLL_KP_SHIFT),
- .mask3 = (u32)~A2W_PLL_KA_MASK,
+ .mask3 = A2W_PLL_KA_MASK,
.set3 = (2 << A2W_PLL_KA_SHIFT),
.fb_prediv_mask = BIT(14),
};
static const struct bcm2835_pll_ana_bits bcm2835_ana_pllh = {
- .mask0 = (u32)~(A2W_PLLH_KA_MASK | A2W_PLLH_KI_LOW_MASK),
+ .mask0 = A2W_PLLH_KA_MASK | A2W_PLLH_KI_LOW_MASK,
.set0 = (2 << A2W_PLLH_KA_SHIFT) | (2 << A2W_PLLH_KI_LOW_SHIFT),
- .mask1 = (u32)~(A2W_PLLH_KI_HIGH_MASK | A2W_PLLH_KP_MASK),
+ .mask1 = A2W_PLLH_KI_HIGH_MASK | A2W_PLLH_KP_MASK,
.set1 = (6 << A2W_PLLH_KP_SHIFT),
.mask3 = 0,
.set3 = 0,
Patches currently in stable-queue which might be from boris.brezillon(a)bootlin.com are
queue-4.15/clk-bcm2835-protect-sections-updating-shared-registers.patch
queue-4.15/clk-bcm2835-fix-ana-maskx-definitions.patch
This is a note to let you know that I've just added the patch titled
ALSA: usb-audio: Fix parsing descriptor of UAC2 processing unit
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-usb-audio-fix-parsing-descriptor-of-uac2-processing-unit.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a6618f4aedb2b60932d766bd82ae7ce866e842aa Mon Sep 17 00:00:00 2001
From: Kirill Marinushkin <k.marinushkin(a)gmail.com>
Date: Mon, 19 Mar 2018 07:11:08 +0100
Subject: ALSA: usb-audio: Fix parsing descriptor of UAC2 processing unit
From: Kirill Marinushkin <k.marinushkin(a)gmail.com>
commit a6618f4aedb2b60932d766bd82ae7ce866e842aa upstream.
Currently, the offsets in the UAC2 processing unit descriptor are
calculated incorrectly. It causes an issue when connecting the device which
provides such a feature:
~~~~
[84126.724420] usb 1-1.3.1: invalid Processing Unit descriptor (id 18)
~~~~
After this patch is applied, the UAC2 processing unit inits w/o this error.
Fixes: 23caaf19b11e ("ALSA: usb-mixer: Add support for Audio Class v2.0")
Signed-off-by: Kirill Marinushkin <k.marinushkin(a)gmail.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
include/uapi/linux/usb/audio.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/include/uapi/linux/usb/audio.h
+++ b/include/uapi/linux/usb/audio.h
@@ -370,7 +370,7 @@ static inline __u8 uac_processing_unit_b
{
return (protocol == UAC_VERSION_1) ?
desc->baSourceID[desc->bNrInPins + 4] :
- desc->baSourceID[desc->bNrInPins + 6];
+ 2; /* in UAC2, this value is constant */
}
static inline __u8 *uac_processing_unit_bmControls(struct uac_processing_unit_descriptor *desc,
@@ -378,7 +378,7 @@ static inline __u8 *uac_processing_unit_
{
return (protocol == UAC_VERSION_1) ?
&desc->baSourceID[desc->bNrInPins + 5] :
- &desc->baSourceID[desc->bNrInPins + 7];
+ &desc->baSourceID[desc->bNrInPins + 6];
}
static inline __u8 uac_processing_unit_iProcessing(struct uac_processing_unit_descriptor *desc,
Patches currently in stable-queue which might be from k.marinushkin(a)gmail.com are
queue-4.15/alsa-usb-audio-fix-parsing-descriptor-of-uac2-processing-unit.patch
This is a note to let you know that I've just added the patch titled
ALSA: hda/realtek - Fix speaker no sound after system resume
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-hda-realtek-fix-speaker-no-sound-after-system-resume.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 88d42b2b45d7208cc872c2c9dec0b1ae6c6008d7 Mon Sep 17 00:00:00 2001
From: Kailang Yang <kailang(a)realtek.com>
Date: Wed, 14 Mar 2018 16:08:57 +0800
Subject: ALSA: hda/realtek - Fix speaker no sound after system resume
From: Kailang Yang <kailang(a)realtek.com>
commit 88d42b2b45d7208cc872c2c9dec0b1ae6c6008d7 upstream.
It will have a chance speaker no sound after system resume.
To toggle NID 0x53 index 0x2 bit 15 will solve this issue.
This usage will also suitable with ALC256.
Fixes: 4a219ef8f370 ("ALSA: hda/realtek - Add ALC256 HP depop function")
Signed-off-by: Kailang Yang <kailang(a)realtek.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -3130,6 +3130,8 @@ static void alc256_init(struct hda_codec
alc_update_coef_idx(codec, 0x46, 3 << 12, 0);
alc_update_coefex_idx(codec, 0x57, 0x04, 0x0007, 0x4); /* Hight power */
+ alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 1 << 15); /* Clear bit */
+ alc_update_coefex_idx(codec, 0x53, 0x02, 0x8000, 0 << 15);
}
static void alc256_shutup(struct hda_codec *codec)
@@ -7032,6 +7034,8 @@ static int patch_alc269(struct hda_codec
break;
case 0x10ec0257:
spec->codec_variant = ALC269_TYPE_ALC257;
+ spec->shutup = alc256_shutup;
+ spec->init_hook = alc256_init;
spec->gen.mixer_nid = 0;
break;
case 0x10ec0215:
Patches currently in stable-queue which might be from kailang(a)realtek.com are
queue-4.15/alsa-hda-realtek-fix-speaker-no-sound-after-system-resume.patch
queue-4.15/alsa-hda-realtek-fix-dell-headset-mic-can-t-record.patch
This is a note to let you know that I've just added the patch titled
ALSA: hda/realtek - Fix Dell headset Mic can't record
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-hda-realtek-fix-dell-headset-mic-can-t-record.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f0ba9d699e5ca2bcd07f70185d18720c4f1b597c Mon Sep 17 00:00:00 2001
From: Kailang Yang <kailang(a)realtek.com>
Date: Fri, 16 Mar 2018 11:46:08 +0800
Subject: ALSA: hda/realtek - Fix Dell headset Mic can't record
From: Kailang Yang <kailang(a)realtek.com>
commit f0ba9d699e5ca2bcd07f70185d18720c4f1b597c upstream.
This platform was hardware fixed type for CTIA type for headset port.
Assigned 0x19 verb will fix can't record issue.
Signed-off-by: Kailang Yang <kailang(a)realtek.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 10 ++++++++++
1 file changed, 10 insertions(+)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -5377,6 +5377,7 @@ enum {
ALC274_FIXUP_DELL_AIO_LINEOUT_VERB,
ALC298_FIXUP_TPT470_DOCK,
ALC255_FIXUP_DUMMY_LINEOUT_VERB,
+ ALC255_FIXUP_DELL_HEADSET_MIC,
};
static const struct hda_fixup alc269_fixups[] = {
@@ -6237,6 +6238,13 @@ static const struct hda_fixup alc269_fix
.chained = true,
.chain_id = ALC255_FIXUP_DELL1_MIC_NO_PRESENCE
},
+ [ALC255_FIXUP_DELL_HEADSET_MIC] = {
+ .type = HDA_FIXUP_PINS,
+ .v.pins = (const struct hda_pintbl[]) {
+ { 0x19, 0x01a1913c }, /* use as headset mic, without its own jack detect */
+ { }
+ },
+ },
};
static const struct snd_pci_quirk alc269_fixup_tbl[] = {
@@ -6291,6 +6299,8 @@ static const struct snd_pci_quirk alc269
SND_PCI_QUIRK(0x1028, 0x082a, "Dell XPS 13 9360", ALC256_FIXUP_DELL_XPS_13_HEADPHONE_NOISE),
SND_PCI_QUIRK(0x1028, 0x084b, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB),
SND_PCI_QUIRK(0x1028, 0x084e, "Dell", ALC274_FIXUP_DELL_AIO_LINEOUT_VERB),
+ SND_PCI_QUIRK(0x1028, 0x0871, "Dell Precision 3630", ALC255_FIXUP_DELL_HEADSET_MIC),
+ SND_PCI_QUIRK(0x1028, 0x0872, "Dell Precision 3630", ALC255_FIXUP_DELL_HEADSET_MIC),
SND_PCI_QUIRK(0x1028, 0x0873, "Dell Precision 3930", ALC255_FIXUP_DUMMY_LINEOUT_VERB),
SND_PCI_QUIRK(0x1028, 0x164a, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
SND_PCI_QUIRK(0x1028, 0x164b, "Dell", ALC293_FIXUP_DELL1_MIC_NO_PRESENCE),
Patches currently in stable-queue which might be from kailang(a)realtek.com are
queue-4.15/alsa-hda-realtek-fix-speaker-no-sound-after-system-resume.patch
queue-4.15/alsa-hda-realtek-fix-dell-headset-mic-can-t-record.patch
This is a note to let you know that I've just added the patch titled
ALSA: hda/realtek - Always immediately update mute LED with pin VREF
to the 4.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
alsa-hda-realtek-always-immediately-update-mute-led-with-pin-vref.patch
and it can be found in the queue-4.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From e40bdb03d3cd7da66bd0bc1e40cbcfb49351265c Mon Sep 17 00:00:00 2001
From: Takashi Iwai <tiwai(a)suse.de>
Date: Sat, 17 Mar 2018 22:40:18 +0100
Subject: ALSA: hda/realtek - Always immediately update mute LED with pin VREF
From: Takashi Iwai <tiwai(a)suse.de>
commit e40bdb03d3cd7da66bd0bc1e40cbcfb49351265c upstream.
Some HP laptops have a mute mute LED controlled by a pin VREF. The
Realtek codec driver updates the VREF via vmaster hook by calling
snd_hda_set_pin_ctl_cache().
This works fine as long as the driver is running in a normal mode.
However, when the VREF change happens during the codec being in
runtime PM suspend, the regmap access will skip and postpone the
actual register change. This ends up with the unchanged LED status
until the next runtime PM resume even if you change the Master mute
switch. (Interestingly, the machine keeps the LED status even after
the codec goes into D3 -- but it's another story.)
For improving this usability, let the driver temporarily powering up /
down only during the pin VREF change. This can be achieved easily by
wrapping the call with snd_hda_power_up_pm() / *_down_pm().
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai(a)suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
sound/pci/hda/patch_realtek.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
--- a/sound/pci/hda/patch_realtek.c
+++ b/sound/pci/hda/patch_realtek.c
@@ -3511,8 +3511,12 @@ static void alc269_fixup_mic_mute_hook(v
pinval = snd_hda_codec_get_pin_target(codec, spec->mute_led_nid);
pinval &= ~AC_PINCTL_VREFEN;
pinval |= enabled ? AC_PINCTL_VREF_HIZ : AC_PINCTL_VREF_80;
- if (spec->mute_led_nid)
+ if (spec->mute_led_nid) {
+ /* temporarily power up/down for setting VREF */
+ snd_hda_power_up_pm(codec);
snd_hda_set_pin_ctl_cache(codec, spec->mute_led_nid, pinval);
+ snd_hda_power_down_pm(codec);
+ }
}
/* Make sure the led works even in runtime suspend */
Patches currently in stable-queue which might be from tiwai(a)suse.de are
queue-4.15/alsa-aloop-fix-access-to-not-yet-ready-substream-via-cable.patch
queue-4.15/alsa-hda-realtek-fix-speaker-no-sound-after-system-resume.patch
queue-4.15/alsa-hda-realtek-fix-dell-headset-mic-can-t-record.patch
queue-4.15/alsa-hda-realtek-always-immediately-update-mute-led-with-pin-vref.patch
queue-4.15/alsa-usb-audio-fix-parsing-descriptor-of-uac2-processing-unit.patch
queue-4.15/alsa-aloop-sync-stale-timer-before-release.patch
queue-4.15/alsa-hda-force-polling-mode-on-cfl-for-fixing-codec-communication.patch