04 Jan, 2021
1 commit
-
This is the 5.10.4 stable release
* tag 'v5.10.4': (717 commits)
Linux 5.10.4
x86/CPU/AMD: Save AMD NodeId as cpu_die_id
drm/edid: fix objtool warning in drm_cvt_modes()
...Signed-off-by: Jason Liu
Conflicts:
drivers/gpu/drm/imx/dcss/dcss-plane.c
drivers/media/i2c/ov5640.c
30 Dec, 2020
14 commits
-
commit 1e405bc2512f80a903ddd6ba8740cee885238d7f upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc() so no
data can leak apart from previous readings.In this driver the timestamp can end up in various different locations
depending on what other channels are enabled. As a result, we don't
use a structure to specify it's position as that would be misleading.Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Reviewed-by: Alexandru Ardelean
Cc: Dan Murphy
Cc:
Link: https://lore.kernel.org/r/20200920112742.170751-9-jic23@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit b0bd27f02d768e3a861c4e6c27f8e369720e6c25 upstream.
The buffer is expressed as a u32 array, yet the extra space for
the s64 timestamp was expressed as sizeof(s64)/sizeof(u16).
This will result in 2 extra u32 elements.
Fix by dividing by sizeof(u32).Fixes: e717f8c6dfec ("iio: adc: Add the TI ads124s08 ADC code")
Signed-off-by: Jonathan Cameron
Reviewed-by: Alexandru Ardelean
Cc: Dan Murphy
Cc:
Link: https://lore.kernel.org/r/20200920112742.170751-8-jic23@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 7b6b51234df6cd8b04fe736b0b89c25612d896b8 upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable array in the iio_priv() data with alignment
explicitly requested. This data is allocated with kzalloc() so no
data can leak apart from previous readings.In this driver, depending on which channels are enabled, the timestamp
can be in a number of locations. Hence we cannot use a structure
to specify the data layout without it being misleading.Fixes: 77c4ad2d6a9b ("iio: imu: Add initial support for Bosch BMI160")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Reviewed-by: Alexandru Ardelean
Cc: Daniel Baluta
Cc: Daniel Baluta
Cc:
Link: https://lore.kernel.org/r/20200920112742.170751-6-jic23@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit dc7de42d6b50a07b37feeba4c6b5136290fcee81 upstream.
The comment implies this device has 3 sensor types, but it only
has an accelerometer and a gyroscope (both 3D). As such the
buffer does not need to be as long as stated.Note I've separated this from the following patch which fixes
the alignment for passing to iio_push_to_buffers_with_timestamp()
as they are different issues even if they affect the same line
of code.Signed-off-by: Jonathan Cameron
Reviewed-by: Alexandru Ardelean
Cc: Daniel Baluta
Cc:
Link: https://lore.kernel.org/r/20200920112742.170751-5-jic23@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 198cf32f0503d2ad60d320b95ef6fb8243db857f upstream.
Whilst this is another case of the issue Lars reported with
an array of elements of smaller than 8 bytes being passed
to iio_push_to_buffers_with_timestamp(), the solution here is
a bit different from the other cases and relies on __aligned
working on the stack (true since 4.6?)This one is unusual. We have to do an explicit memset() each time
as we are reading 3 bytes into a potential 4 byte channel which
may sometimes be a 2 byte channel depending on what is enabled.
As such, moving the buffer to the heap in the iio_priv structure
doesn't save us much. We can't use a nice explicit structure
on the stack either as the data channels have different storage
sizes and are all separately controlled.Fixes: cc26ad455f57 ("iio: Add Freescale MPL3115A2 pressure / temperature sensor driver")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Reviewed-by: Andy Shevchenko
Reviewed-by: Alexandru Ardelean
Cc: Peter Meerwald
Cc:
Link: https://lore.kernel.org/r/20200920112742.170751-7-jic23@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 89deb1334252ea4a8491d47654811e28b0790364 upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv() data.
This data is allocated with kzalloc() so no data can leak apart from
previous readings.The explicit alignment of ts is not necessary in this case but
does make the code slightly less fragile so I have included it.Fixes: 39631b5f9584 ("iio: Add Freescale mag3110 magnetometer driver")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Reviewed-by: Alexandru Ardelean
Cc:
Link: https://lore.kernel.org/r/20200920112742.170751-4-jic23@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit d837a996f57c29a985177bc03b0e599082047f27 upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv()This data is allocated with kzalloc() so no data can leak apart
from previous readings.A local unsigned int variable is used for the regmap call so it
is clear there is no potential issue with writing into the padding
of the structure.Fixes: 3025c8688c1e ("iio: light: add support for UVIS25 sensor")
Reported-by: Lars-Peter Clausen
Signed-off-by: Jonathan Cameron
Reviewed-by: Alexandru Ardelean
Acked-by: Lorenzo Bianconi
Cc:
Link: https://lore.kernel.org/r/20200920112742.170751-3-jic23@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit a61817216bcc755eabbcb1cf281d84ccad267ed1 upstream.
One of a class of bugs pointed out by Lars in a recent review.
iio_push_to_buffers_with_timestamp() assumes the buffer used is aligned
to the size of the timestamp (8 bytes). This is not guaranteed in
this driver which uses an array of smaller elements on the stack.
As Lars also noted this anti pattern can involve a leak of data to
userspace and that indeed can happen here. We close both issues by
moving to a suitable structure in the iio_priv().
This data is allocated with kzalloc() so no data can leak apart
from previous readings and in this case the status byte from the device.The forced alignment of ts is not necessary in this case but it
potentially makes the code less fragile.>From personal communications with Mikko:
We could probably split the reading of the int register, but it
would mean a significant performance cost of 20 i2c clock cycles.Fixes: e12ffd241c00 ("iio: light: rpr0521 triggered buffer")
Signed-off-by: Jonathan Cameron
Reviewed-by: Alexandru Ardelean
Cc: Mikko Koivunen
Cc:
Link: https://lore.kernel.org/r/20200920112742.170751-2-jic23@kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 3f9bce7a22a3f8ac9d885c9d75bc45569f24ac8b upstream.
If we are using edge IRQs, new samples can arrive while processing
current interrupt since there are no hw guarantees the irq line
stays "low" long enough to properly detect the new interrupt.
In this case the new sample will be missed.
Polling FIFO status register in st_lsm6dsx_handler_thread routine
allow us to read new samples even if the interrupt arrives while
processing previous data and the timeslot where the line is "low"
is too short to be properly detected.Fixes: 89ca88a7cdf2 ("iio: imu: st_lsm6dsx: support active-low interrupts")
Fixes: 290a6ce11d93 ("iio: imu: add support to lsm6dsx driver")
Signed-off-by: Lorenzo Bianconi
Link: https://lore.kernel.org/r/5e93cda7dc1e665f5685c53ad8e9ea71dbae782d.1605378871.git.lorenzo@kernel.org
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 560c6b914c6ec7d9d9a69fddbb5bf3bf71433e8b upstream.
Fix the missing clk_disable_unprepare() of info->pclk
before return from rockchip_saradc_resume in the error
handling case when fails to prepare and enable info->clk.Suggested-by: Robin Murphy
Fixes: 44d6f2ef94f9 ("iio: adc: add driver for Rockchip saradc")
Signed-off-by: Qinglang Miao
Cc:
Link: https://lore.kernel.org/r/20201103120743.110662-1-miaoqinglang@huawei.com
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 19ef7b70ca9487773c29b449adf0c70f540a0aab upstream.
When updating the buffer demux, we will skip a scan element from the
device in the case `in_ind != out_ind` and we enter the while loop.
in_ind should only be refreshed with `find_next_bit()` in the end of the
loop.Note, to cause problems we need a situation where we are skippig over
an element (channel not enabled) that happens to not have the same size
as the next element. Whilst this is a possible situation we haven't
actually identified any cases in mainline where it happens as most drivers
have consistent channel storage sizes with the exception of the timestamp
which is the last element and hence never skipped over.Fixes: 5ada4ea9be16 ("staging:iio: add demux optionally to path from device to buffer")
Signed-off-by: Nuno Sá
Link: https://lore.kernel.org/r/20201112144323.28887-1-nuno.sa@analog.com
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
commit 0fb6ee8d0b5e90b72f870f76debc8bd31a742014 upstream.
Use a heap allocated memory for the SPI transfer buffer. Using stack memory
can corrupt stack memory when using DMA on some systems.This change moves the buffer from the stack of the trigger handler call to
the heap of the buffer of the state struct. The size increases takes into
account the alignment for the timestamp, which is 8 bytes.The 'data' buffer is split into 'tx_buf' and 'rx_buf', to make a clearer
separation of which part of the buffer should be used for TX & RX.Fixes: af3008485ea03 ("iio:adc: Add common code for ADI Sigma Delta devices")
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Alexandru Ardelean
Link: https://lore.kernel.org/r/20201124123807.19717-1-alexandru.ardelean@analog.com
Cc:
Signed-off-by: Jonathan Cameron
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 0178297c1e6898e2197fe169ef3be723e019b971 ]
On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft
interrupt expiry mode by default.The IIO hrtimer-trigger needs to run in hard interrupt context since it
will end up calling generic_handle_irq() which has the requirement to run
in hard interrupt context.Explicitly specify that the timer needs to run in hard interrupt context by
using the HRTIMER_MODE_REL_HARD flag.Fixes: f5c2f0215e36 ("hrtimer: Move unmarked hrtimers to soft interrupt expiry on RT")
Reported-by: Christian Eggers
Signed-off-by: Lars-Peter Clausen
Acked-by: Sebastian Andrzej Siewior
Link: https://lore.kernel.org/r/20201117103751.16131-1-lars@metafoo.de
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin -
[ Upstream commit f091d7c5fe6cc39e916b50f90e3cac67a032d0be ]
This tries to solve a warning reported by the lkp bot:
>> drivers/iio/adc/at91_adc.c:1439:34: warning: unused variable
>> 'at91_adc_dt_ids' [-Wunused-const-variable]
static const struct of_device_id at91_adc_dt_ids[] = {
^
1 warning generated.This warning has appeared after the AT91_ADC driver compilation has been
enabled via the COMPILE_TEST symbol dependency.The warning is caused by the 'of_match_ptr()' helper which returns NULL if
OF is undefined. This driver should build only for device-tree context, so
a dependency on the OF Kconfig symbol has been added.
Also, the usage of of_match_ptr() helper has been removed since it
shouldn't ever return NULL (because the driver should not be built for the
non-OF context).Fixes: 4027860dcc4c ("iio: Kconfig: at91_adc: add COMPILE_TEST dependency to driver")
Reported-by: kernel test robot
Signed-off-by: Alexandru Ardelean
Reviewed-by: Alexandre Belloni
Link: https://lore.kernel.org/r/20200930135048.11530-4-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
14 Dec, 2020
2 commits
-
i.MX8QXP B0 and i.MX8QM has the same ADC IP, so add the
adc driver to support it.Signed-off-by: Haibo Chen
-
Enable i.MX6SX adc driver. ADC driver will try getting ADC controller
channel number via device tree, because i.MX chip enable 4 channels
on each controller.Signed-off-by: Luwei Zhou
Signed-off-by: Fugang Duan
(cherry picked from commit 14a6a98f64e26702b1c0ecfc7d58a45ee5752d54)
Signed-off-by: Arulpandiyan Vadivel
15 Nov, 2020
2 commits
-
Some 360 degree hinges (yoga) style 2-in-1 devices use 2 KXCJ91008-s
to allow the OS to determine the angle between the display and the base
of the device, so that the OS can determine if the 2-in-1 is in laptop
or in tablet-mode.On Windows both accelerometers are read by a special HingeAngleService
process; and this process calls a DSM (Device Specific Method) on the
ACPI KIOX010A device node for the sensor in the display, to let the
embedded-controller (EC) know about the mode so that it can disable the
kbd and touchpad to avoid spurious input while folded into tablet-mode.This notifying of the EC is problematic because sometimes the EC comes up
thinking that device is in tablet-mode and the kbd and touchpad do not
work. This happens for example on Irbis NB111 devices after a suspend /
resume cycle (after a complete battery drain / hard reset without having
booted Windows at least once). Other 2-in-1s which are likely affected
too are e.g. the Teclast F5 and F6 series.The kxcjk-1013 driver may seem like a strange place to deal with this,
but since it is *the* driver for the ACPI KIOX010A device, it is also
the driver which has access to the ACPI handle needed by the DSM.Add support for calling the DSM and on probe unconditionally tell the
EC that the device is laptop mode, fixing the kbd and touchpad sometimes
not working.Fixes: 7f6232e69539 ("iio: accel: kxcjk1013: Add KIOX010A ACPI Hardware-ID")
Reported-and-tested-by: russianneuromancer
Signed-off-by: Hans de Goede
Cc:
Link: https://lore.kernel.org/r/20201110133835.129080-3-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron -
Replace the boolean is_smo8500_device variable with an acpi_type enum.
For now this can be either ACPI_GENERIC or ACPI_SMO8500, this is a
preparation patch for adding special handling for the KIOX010A ACPI HID,
which will add a ACPI_KIOX010A acpi_type to the introduced enum.For stable as needed as precursor for next patch.
Signed-off-by: Hans de Goede
Fixes: 7f6232e69539 ("iio: accel: kxcjk1013: Add KIOX010A ACPI Hardware-ID")
Cc:
Link: https://lore.kernel.org/r/20201110133835.129080-2-hdegoede@redhat.com
Signed-off-by: Jonathan Cameron
08 Nov, 2020
3 commits
-
When VCNL4035 is enabled and IIO_BUFFER is disabled, it results in the
following Kbuild warning:WARNING: unmet direct dependencies detected for IIO_TRIGGERED_BUFFER
Depends on [n]: IIO [=y] && IIO_BUFFER [=n]
Selected by [y]:
- VCNL4035 [=y] && IIO [=y] && I2C [=y]The reason is that VCNL4035 selects IIO_TRIGGERED_BUFFER without depending
on or selecting IIO_BUFFER while IIO_TRIGGERED_BUFFER depends on
IIO_BUFFER. This can also fail building the kernel.Honor the kconfig dependency to remove unmet direct dependency warnings
and avoid any potential build failures.Fixes: 55707294c4eb ("iio: light: Add support for vishay vcnl4035")
Signed-off-by: Necip Fazil Yildiran
Link: https://bugzilla.kernel.org/show_bug.cgi?id=209883
Link: https://lore.kernel.org/r/20201102223523.572461-1-fazilyildiran@gmail.com
Cc:
Signed-off-by: Jonathan Cameron -
When the command feature of the ADC is used, it is possible to program
the ADC, and specify at each step what input should be processed, and in
comparison to what reference.This broke the AUX and battery readings when the touchscreen was
enabled, most likely because the CMD feature would change the VREF all
the time.Now, when AUX or battery are read, we temporarily disable the CMD
feature, which means that we won't get touchscreen readings in that time
frame. But it now gives correct values for AUX / battery, and the
touchscreen isn't disabled for long enough to be an actual issue.Fixes: b96952f498db ("IIO: Ingenic JZ47xx: Add touchscreen mode.")
Signed-off-by: Paul Cercueil
Acked-by: Artur Rojek
Cc:
Link: https://lore.kernel.org/r/20201103201238.161083-1-paul@crapouillou.net
Signed-off-by: Jonathan Cameron -
The reference voltage for the battery is clearly marked as 1.2V in the
programming manual. With this fixed, the battery channel now returns
correct values.Fixes: a515d6488505 ("IIO: Ingenic JZ47xx: Add support for JZ4770 SoC ADC.")
Signed-off-by: Paul Cercueil
Acked-by: Artur Rojek
Cc:
Link: https://lore.kernel.org/r/20201104192843.67187-1-paul@crapouillou.net
Signed-off-by: Jonathan Cameron
02 Nov, 2020
2 commits
-
Set 10ms as minimum i2c slave configuration timeout since st_lsm6dsx
relies on accel ODR for i2c master clock and at high sample rates
(e.g. 833Hz or 416Hz) the slave sensor occasionally may need more cycles
than i2c master timeout (2s/833Hz + 1 ~ 3ms) to apply the configuration
resulting in an uncomplete slave configuration and a constant reading
from the i2c slave connected to st_lsm6dsx i2c master.Fixes: 8f9a5249e3d9 ("iio: imu: st_lsm6dsx: enable 833Hz sample frequency for tagged sensors")
Fixes: c91c1c844ebd ("iio: imu: st_lsm6dsx: add i2c embedded controller support")
Signed-off-by: Lorenzo Bianconi
Cc:
Link: https://lore.kernel.org/r/a69c8236bf16a1569966815ed71710af2722ed7d.1604247274.git.lorenzo@kernel.org
Signed-off-by: Jonathan Cameron -
Since overrun interrupt support has been added, there's a regression when
two ADCs are used at the same time, with:
- an ADC configured to use IRQs. EOCIE bit is set. The handler is normally
called in this case.
- an ADC configured to use DMA. EOCIE bit isn't set. EOC triggers the DMA
request. It's then automatically cleared by DMA read. But the handler
gets called due to status bit is temporarily set (IRQ triggered by the
other ADC).This is a regression as similar issue had been fixed earlier by
commit dcb10920179a ("iio: adc: stm32-adc:
fix a race when using several adcs with dma and irq").
Issue is that stm32_adc_eoc_enabled() returns non-zero value (always)
since OVR bit has been added and enabled for both DMA and IRQ case.Remove OVR mask in IER register, and rely only on CSR status for overrun.
To avoid subsequent calls to interrupt routine on overrun, CSR OVR bit has
to be cleared. CSR OVR bit cannot be cleared directly by software.
To do this ADC must be stopped first, and OVR bit in ADC ISR has
to be cleared.
Also add a check in ADC IRQ handler to report spurious IRQs.Fixes: cc06e67d8fa5 ("iio: adc: stm32-adc: Add check on overrun interrupt")
Signed-off-by: Olivier Moysan
Signed-off-by: Fabrice Gasnier
Cc:
Link: https://lore.kernel.org/r/20201021085313.5335-1-olivier.moysan@st.com
Signed-off-by: Jonathan Cameron
01 Nov, 2020
2 commits
-
dev_comp field is used in a couple of places but it is never set. This
results in kernel oops when dereferencing a NULL pointer. Set the
`dev_comp` field correctly in the probe function.Fixes: 6d97024dce23 ("iio: adc: mediatek: mt6577-auxadc, add mt6765 support")
Signed-off-by: Fabien Parent
Reviewed-by: Matthias Brugger
Cc:
Link: https://lore.kernel.org/r/20201018194644.3366846-1-fparent@baylibre.com
Signed-off-by: Jonathan Cameron -
Minimal and maximal frequencies supported by a sensor is queried.
On some older machines, these frequencies are not returned properly and
the EC returns 0 instead.
When returned maximal frequency is 0, ignore the information and use
default frequencies instead.Fixes: ae7b02ad2f32 ("iio: common: cros_ec_sensors: Expose cros_ec_sensors frequency range via iio sysfs")
Signed-off-by: Gwendal Grignou
Reviewed-by: Enric Balletbo i Serra
Link: https://lore.kernel.org/r/20200630153730.3302889-1-gwendal@chromium.org
CC:
Signed-off-by: Jonathan Cameron
24 Oct, 2020
1 commit
-
…kernel/git/chrome-platform/linux
Pull chrome platform updates from Benson Leung:
"cros-ec:
- Error code cleanup across cros-ec by Guenter
- Remove cros_ec_cmd_xfer in favor of cros_ec_cmd_xfer_statuscros_ec_typec:
- Landed initial USB4 support in typec connector class driver for
cros_ec
- Role switch bugfix on disconnect, and reordering configuration
stepscros_ec_lightbar:
- Fix buffer outsize and result for get_lightbar_versionmisc:
- Remove config MFD_CROS_EC, now that transition from MFD is complete
- Enable KEY_LEFTMETA in new location on arm based cros-ec-keyboard
keymap"* tag 'tag-chrome-platform-for-v5.10' of git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux:
ARM: dts: cros-ec-keyboard: Add alternate keymap for KEY_LEFTMETA
platform/chrome: Use kobj_to_dev() instead of container_of()
platform/chrome: cros_ec_proto: Drop cros_ec_cmd_xfer()
platform/chrome: cros_ec_proto: Update cros_ec_cmd_xfer() call-sites
platform/chrome: Kconfig: Remove the transitional MFD_CROS_EC config
platform/chrome: cros_ec_lightbar: Reduce ligthbar get version command
platform/chrome: cros_ec_trace: Add fields to command traces
platform/chrome: cros_ec_typec: Re-order connector configuration steps
platform/chrome: cros_ec_typec: Avoid setting usb role twice during disconnect
platform/chrome: cros_ec_typec: Send enum values to usb_role_switch_set_role()
platform/chrome: cros_ec_typec: USB4 support
pwm: cros-ec: Simplify EC error handling
platform/chrome: cros_ec_proto: Convert EC error codes to Linux error codes
platform/input: cros_ec: Replace -ENOTSUPP with -ENOPROTOOPT
pwm: cros-ec: Accept more error codes from cros_ec_cmd_xfer_status
platform/chrome: cros_ec_sysfs: Report range of error codes from EC
cros_ec_lightbar: Accept more error codes from cros_ec_cmd_xfer_status
iio: cros_ec: Accept -EOPNOTSUPP as 'not supported' error code
16 Oct, 2020
2 commits
-
Pull sound updates from Takashi Iwai:
"The amount of changes is smaller at this round (what a surprise), but
lots of activity is seen. Most of changes are about ASoC driver
development, especially Intel platforms. Here are some highlights:General:
- Replace all tasklet usages with other alternatives
- Cleanup of the ASoC error unwinding code
- Fixes for trivial issues caught by static checker
- Spell fixes allover the placesALSA Core:
- Lockdep fix for control devices
- Fix for potential OSS sequencer mutex stallsHD-audio and USB-audio:
- SoundBlaster AE-7 support
- Changes in quirk table for the rename handling
- Quirks for HP and ASUS machines, Pioneer DJ DJM-250MK2.ASoC:
- Lots of updates for Intel SOF and SoundWire enablement
- Replacement of the DSP driver for some older x86 systems; the new
code was written from scratch, better maintenance expected
- Helpers for parsing auxiluary devices from the device tree
- New support for AllWinner A64, Cirrus Logic CS4234, Mediatek MT6359
Microchip S/PDIF TX and RX controllers, Realtek RT1015P, and Texas
Instruments J721E, TAS2110, TAS2564 and TAS2764"* tag 'sound-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (498 commits)
ALSA: hda/hdmi: fix incorrect locking in hdmi_pcm_close
ALSA: hda: fix jack detection with Realtek codecs when in D3
ALSA: fireworks: use semicolons rather than commas to separate statements
ALSA: hda: use semicolons rather than commas to separate statements
ALSA: hda/i915 - fix list corruption with concurrent probes
ASoC: dmaengine: Document support for TX only or RX only streams
ASoC: mchp-spdiftx: remove 'TX' from playback stream name
ASoC: ti: davinci-mcasp: Use &pdev->dev for early dev_warn
ASoC: tas2764: Add the driver for the TAS2764
dt-bindings: tas2764: Add the TAS2764 binding doc
ASoC: Intel: catpt: Add explicit DMADEVICES kconfig dependency
ASoC: Intel: catpt: Fix compilation when CONFIG_MODULES is disabled
ASoC: stm32: dfsdm: add actual resolution trace
ASoC: stm32: dfsdm: change rate limits
ASoC: qcom: sc7180: Add support for audio over DP
Asoc: qcom: lpass-platform : Increase buffer size
ASoC: qcom: Add support for lpass hdmi driver
Asoc: qcom: lpass:Update lpaif_dmactl members order
Asoc:qcom:lpass-cpu:Update dts property read API
ASoC: dt-bindings: Add dt binding for lpass hdmi
... -
Pull staging / IIO driver updates from Greg KH:
"Here is the large set of staging and IIO driver updates for 5.10-rc1.Included in here are:
- new IIO drivers
- new IIO driver frameworks
- various IIO driver fixes and updates
- IIO device tree conversions to yaml
- so many minor staging driver coding style cleanups
- most cdev driver moved out of staging
- no staging drivers added or removed
Full details are in the shortlog.
All of these have been in linux-next for a while with no reported
issues"* tag 'staging-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (476 commits)
staging: comedi: check validity of wMaxPacketSize of usb endpoints found
staging: wfx: improve robustness of wfx_get_hw_rate()
staging: wfx: drop unicode characters from strings
staging: wfx: gpiod_get_value() can return an error
staging: wfx: increase robustness of hif_generic_confirm()
staging: wfx: wfx_init_common() returns NULL on error
staging: wfx: standardize the error when vif does not exist
staging: wfx: check memory allocation
staging: wfx: improve error handling of hif_join()
staging: dpaa2-switch: add a dpaa2_switch prefix to all functions in ethsw.c
staging: dpaa2-switch: add a dpaa2_switch_ prefix to all functions in ethsw-ethtool.c
staging: rtl8188eu: Fix long lines
dt-bindings: staging: wfx: silabs,wfx yaml conversion
staging: wfx: update copyrights dates
staging: wfx: fix QoS priority for slow buses
staging: wfx: fix BA sessions for older firmwares
staging: wfx: remove remaining code of 'secure link' feature
staging: wfx: fix handling of MMIC error
staging: vchiq: Fix list_for_each exit tests
staging: greybus: use __force when assigning __u8 value to snd_ctl_elem_type_t
...
15 Oct, 2020
1 commit
-
Pull driver core updates from Greg KH:
"Here is the "big" set of driver core patches for 5.10-rc1They include a lot of different things, all related to the driver core
and/or some driver logic:- sysfs common write functions to make it easier to audit sysfs
attributes- device connection cleanups and fixes
- devm helpers for a few functions
- NOIO allocations for when devices are being removed
- minor cleanups and fixes
All have been in linux-next for a while with no reported issues"
* tag 'driver-core-5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (31 commits)
regmap: debugfs: use semicolons rather than commas to separate statements
platform/x86: intel_pmc_core: do not create a static struct device
drivers core: node: Use a more typical macro definition style for ACCESS_ATTR
drivers core: Use sysfs_emit for shared_cpu_map_show and shared_cpu_list_show
mm: and drivers core: Convert hugetlb_report_node_meminfo to sysfs_emit
drivers core: Miscellaneous changes for sysfs_emit
drivers core: Reindent a couple uses around sysfs_emit
drivers core: Remove strcat uses around sysfs_emit and neaten
drivers core: Use sysfs_emit and sysfs_emit_at for show(device *...) functions
sysfs: Add sysfs_emit and sysfs_emit_at to format sysfs output
dyndbg: use keyword, arg varnames for query term pairs
driver core: force NOIO allocations during unplug
platform_device: switch to simpler IDA interface
driver core: platform: Document return type of more functions
Revert "driver core: Annotate dev_err_probe() with __must_check"
Revert "test_firmware: Test platform fw loading on non-EFI systems"
iio: adc: xilinx-xadc: use devm_krealloc()
hwmon: pmbus: use more devres helpers
devres: provide devm_krealloc()
syscore: Use pm_pr_dbg() for syscore_{suspend,resume}()
...
09 Oct, 2020
2 commits
-
Add a trace to report actual resolution of audio samples.
Signed-off-by: Olivier Moysan
Link: https://lore.kernel.org/r/20201007153459.22155-3-olivier.moysan@st.com
Signed-off-by: Mark Brown
05 Oct, 2020
1 commit
-
We need the IIO fixes in here as well.
Signed-off-by: Greg Kroah-Hartman
30 Sep, 2020
7 commits
-
Add missing of_node_put calls when exiting the for_each_child_of_node
loop in rcar_gyroadc_parse_subdevs early.Also add goto-exception handling for the error paths in that loop.
Fixes: 059c53b32329 ("iio: adc: Add Renesas GyroADC driver")
Signed-off-by: Tobias Jordan
Link: https://lore.kernel.org/r/20200926161946.GA10240@agrajag.zerfleddert.de
Cc:
Signed-off-by: Jonathan Cameron -
When the ADC is runtime suspended and starting a conversion, the stm32-adc
driver calls pm_runtime_get_sync() that gets cascaded to the parent
(e.g. runtime resume of stm32-adc-core driver). This also kicks the
autosuspend delay (e.g. 2s) of the parent.
Once the ADC is active, calling pm_runtime_get_sync() again (upon a new
capture) won't kick the autosuspend delay for the parent (stm32-adc-core
driver) as already active.Currently, this makes the stm32-adc-core driver go in suspend state
every 2s when doing slow polling. As an example, doing a capture, e.g.
cat in_voltageY_raw at a 0.2s rate, the auto suspend delay for the parent
isn't refreshed. Once it expires, the parent immediately falls into
runtime suspended state, in between two captures, as soon as the child
driver falls into runtime suspend state:
- e.g. after 2s, + child calls pm_runtime_put_autosuspend() + 100ms
autosuspend delay of the child.
- stm32-adc-core switches off regulators, clocks and so on.
- They get switched on back again 100ms later in this example (at 2.2s).So, use runtime_idle() callback in stm32-adc-core driver to call
pm_runtime_mark_last_busy() for the parent driver (stm32-adc-core),
to avoid this.Fixes: 9bdbb1139ca1 ("iio: adc: stm32-adc: add power management support")
Signed-off-by: Fabrice Gasnier
Reviewed-by: Ulf Hansson
Link: https://lore.kernel.org/r/1593615328-5180-1-git-send-email-fabrice.gasnier@st.com
Signed-off-by: Jonathan Cameron -
After the move of the postenable code to preenable, the DMA start was
done before the DMA init, which is not correct.
The DMA is initialized in set_watermark. Because of this, we need to call
the DMA start functions in set_watermark, after the DMA init, instead of
preenable hook, when the DMA is not properly setup yet.Fixes: f3c034f61775 ("iio: at91-sama5d2_adc: adjust iio_triggered_buffer_{predisable,postenable} positions")
Signed-off-by: Eugen Hristev
Link: https://lore.kernel.org/r/20200923121748.49384-1-eugen.hristev@microchip.com
Cc:
Signed-off-by: Jonathan Cameron -
When returning or breaking early from a
`for_each_available_child_of_node()` loop, we need to explicitly call
`of_node_put()` on the child node to possibly release the node.Fixes: 506d2e317a0a0 ("iio: adc: Add driver support for AD7292")
Signed-off-by: Nuno Sá
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200925091045.302-2-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron -
When returning or breaking early from a
`for_each_available_child_of_node()` loop, we need to explicitly call
`of_node_put()` on the child node to possibly release the node.Fixes: f110f3188e563 ("iio: temperature: Add support for LTC2983")
Signed-off-by: Nuno Sá
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200925091045.302-1-nuno.sa@analog.com
Signed-off-by: Jonathan Cameron -
For some embedded systems, a workflow involving external kernel modules
that implement IIO devices is more practical than working with in-tree
sources.Kconfig symbols without any titles do not show up in menuconfig, and as
such are more difficult to configure granularly, as they need to be
selected by potentially unused/un-needed drivers.This change adds a title to the IIO_TRIGGERED_BUFFER Kconfig symbol.
Signed-off-by: Alexandru Ardelean
Link: https://lore.kernel.org/r/20200924111758.196367-4-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron -
For some embedded systems, a workflow involving external kernel modules
that implement IIO devices is more practical than working with in-tree
sources.Kconfig symbols without any titles do not show up in menuconfig, and as
such are more difficult to configure granularly, as they need to be
selected by potentially unused/un-needed drivers.Albeit, the IIO_TRIGGERED_EVENT is used by a single mainline driver, this
could allow for some out-of-tree drivers to use this kmod.This change adds a title to the IIO_TRIGGERED_EVENT Kconfig symbol.
Signed-off-by: Alexandru Ardelean
Link: https://lore.kernel.org/r/20200924111758.196367-3-alexandru.ardelean@analog.com
Signed-off-by: Jonathan Cameron
