Jonathan writes:
1st set of IIO new device support, features and cleanup for 6.6
New device support
* adi,ad8366
- Add support for the HMC792 digital attenuator (mostly chip specific data)
* alwinner,sun20i-gpadc
- New driver for the integrated ADC on a number of allwinner SoCs
including dt-binding documentation.
* microchip,mcp4728
- New driver for this quad channel DAC. Includes dt-bindings.
* miramems, da280
- Add ID for DA217 accelerometer which is compatible with the da280.
* murata,irs-d200
- New driver for this passive infrared sensor typically used for human
detection. Includes bindings and a few pieces of new ABI to
cover a case of needing to count a number of repeats of an event
before reporting it.
* rohm,bu27008
- Add initial support for the BU27010 RGB + flickering sensor to this
driver. Substantial refactoring was needed to enable this.
Features
* adi,admv8818
- Add mode that bypasses the input and output filters.
* amlogic,meson
- Support control of the MUX on channel 7, exposed as multiple channels.
- Support channel labels.
* sensirion,scd4x
- Add pressure compensation. Controlled via an 'output' pressure channel.
* ti,lmp92040
- Add IIO buffered supported (read via chrdev).
* vishay,vcnl4000
- Add proximity interrupt support for vcnl4200.
- Add proximity integration time control for vcnl4200.
- Add illuminance integration time control for vcnl4040 and vcnl4200.
- Add calibration bias, proximity and illuminance event period, and
oversampling ratio control for vcnl4040 and vncl4200.
Cleanup and minor fixes
* core
- Tidy up handling of set_trigger_state() callback return values
to consistently assume no positive return values.
- Use min() rather than min_t() in a case where types were clearly
the same.
- Drop some else statements that follow continue with a loop or
a returns.
- White space and comment format cleanup.
- Use sysfs_match_string() helper to improve readability.
- Use krealloc_array() to make it explicit a krealloc is for an array
of structures, not just one.
* tools
- Tidy up potential overflow in array index.
* tree wide
- Fix up includes for DT related headers.
- Drop some error prints in places where as similar error message
is printed by the function being called.
- Tidy up handling of return value from platform_get_irq() to no longer
take into account 0 as a value that might be returned. Similar for
fwnode_irq_get().
* adi,ad7192
- Add missing error check and improved debug logging.
- Use sysfs_emit_at() rather than open coded variant.
* adi,adis16475
- Drop unused scan element enum entries.
- Specify that a few more devices support burst32 mode.
* adi,admv1013
- Enable all required regulators and document as required in the
dt-binding.
* adi,admv1014
- Make all regulators required in the dt-binding as the device needs
them all enabled.
* adi,adxl313
- Fix wrong enum values being used in the i2c_device_id table.
- Use i2c_get_match_data() to reduce open coded handling of the
various id tables.
* allwinner,gpadc
- Make the kconfig text more specific to make space for separate drivers
for other Allwinner devices.
* amlogic,meson
- Drop unused timestamp channels as no buffer support.
- Various minor reorganizations to enable addition of support channel 7
MUX.
- Initialize some default values to account for potential previous user
since reboot.
* qcom,spmi-adc5
- Add ADC5_GPIO2_100K_PU support to driver to line up with bindings.
* qcom,spmi-adc7
- Use predefined channel ID definitions rather than values.
* invensense, common
- Factor out the timestamp handling to a module used by both mpu6050 and
icm42600.
* invensense,mpu6050
- Read as many FIFO elements as possible in one bus access.
* men,s188
- Drop redundant initialization of driver owner field.
* microchip,mcp4018 and mcp4531
- Use i2c_get_match_data() instead of open coding. Includes making the
data format the same for the i2c_device_id and firmware match
tables.
* semtech,sx9310
- dt-bindings: Add reference to IIO schema to provide the label property.
* semtech,sx9324
- dt-bindings: Add reference to IIO schema to provide the label property.
* st,stm32-adc
- Use devm_platform_get_and_ioremap_resource() instead of open coded
version.
* st,stm-lptimer-trigger
- Drop setting platform drvdata as it wasn't then used.
* ti,ads1015
- Fix wrong dt binding description of ti,datarate for some devices.
* vishay,vcnl4200
- Move to switch statements for channel type checking to make later
additions simpler.
* tag 'iio-for-6.6a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (73 commits)
Documentation: ABI: testing: admv8818: add bypass
drivers: iio: filter: admv8818: add bypass mode
iio: light: bd27008: Support BD27010 RGB
iio: light: bu27008: add chip info
dt-bindings: iio: ROHM BU27010 RGBC + flickering sensor
iio: add MCP4728 I2C DAC driver
dt-bindings: iio: dac: add mcp4728.yaml
drivers: iio: admv1013: add vcc regulators
dt-bindings: iio: admv1013: add vcc regulators
iio: trigger: stm32-lptimer-trigger: remove unneeded platform_set_drvdata()
iio: adc: men_z188_adc: Remove redundant initialization owner in men_z188_driver
dt-bindings: iio: admv1014: make all regs required
iio: cdc: ad7150: relax return value check for IRQ get
iio: mb1232: relax return value check for IRQ get
iio: adc: fix the return value handle for platform_get_irq()
tools: iio: iio_generic_buffer: Fix some integer type and calculation
iio: potentiometer: mcp4531: Use i2c_get_match_data()
iio: potentiometer: mcp4018: Use i2c_get_match_data()
iio: core: Fix issues and style of the comments
iio: core: Switch to krealloc_array()
...
Add filter bypass mode, which bypasses the low pass filter, high pass
filter and disables/unregister the clock rate notifier.
Currently a feature like bypassing the filter is not achievable
straightforward and not very deductive. The user has to look through the
code and call the set_lpf_3db_frequency and set_hpf_3db_frequency iio
attributes from the user interface using the corner cases (freq >
largest lpf supported by the part, respectively freq < smallest hpf
supported by the part). Moreover, in such case of bypassing the filter,
the input clock rate change might mess up things so we want to make sure
that it is disabled. Also, the feature will help emphasizing the filter
behavior, therefore adding it in the userspace will ease the
charcaterization of the filter's effects when active/disabled.
It was requested by users of the driver to ease the interaction with
different configuration modes of the device.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Link: https://lore.kernel.org/r/20230731084928.8302-1-antoniu.miclaus@analog.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ROHM BU27010 is an RGBC sensor with a flickering detection FIFO. The
RGBC+IR sensor functionality is largely similar to what the BU27008 has.
There are some notable things though:
- gain setting is once again new and exotic. Now, there is 6bit gain
setting where 4 of the bits are common to all channels and 2 bits
can be configured separately for each channel. The BU27010 has
similar "1X on other channels vs 2X on IR when selector is 0x0"
gain design as BU27008 had. So, we use same gain setting policy for
BU27010 as we did for BU27008 - driver sets same gain selector for all
channels but shows the gains separately for all channels so users
can (at least in theory) detect this 1X vs 2X madness...
- BU27010 has suffled all the control register bitfields to new
addresses and bit positions while still keeping the register naming
same.
- Some more power/reset control is added.
- FIFO for "flickering detection" is added.
The control register suffling made this slightly nasty. Still, it is
easier for maintenance perspective to add the BU27010 support in BU27008
driver because - even though the bit positions/addresses were changed -
most of the driver structure can be re-used. Writing own driver for
BU27010 would mean plenty of duplicate code albeit a tad more clarity.
The flickering FIFO is not supported by the driver.
Add BU27010 RGBC+IR support to rohm-bu27008 driver.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/111cd217ccece1c1f16ab4287532dc4e1ddb8a3f.1690958450.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Extend Intel Remote System Update (RSU) driver to get SPT
(Sub-Partition Table) addresses. The query SPT address can be used
to determine if the RSU QSPI layout is 32kB or 64kB aligned.
The alignment can be determined by minus the upper with the lower of
the SPT addresses.
This patch depends on patch:
firmware: stratix10-svc: Generic Mailbox Command
Signed-off-by: Radu Bacrau <radu.bacrau@intel.com>
Signed-off-by: Kah Jing Lee <kah.jing.lee@intel.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Link: https://lore.kernel.org/r/20230727192907.982070-2-dinguyen@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The coreboot framebuffer driver registers a "simple-framebuffer" device
based on the information from the firmware, after checking that it's
compatible with the formats listed in simplefb.h. It was added before
simpledrm, and its Kconfig marked as dependent on the simplefb driver.
The simpledrm driver can also handle "simple-framebuffer" devices and
the coreboot framebuffer works fine with it on a 'Lick' Chromebook.
Allow building the coreboot framebuffer driver with simpledrm as well.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Link: https://lore.kernel.org/r/20230725174334.887485-1-alpernebiyasak@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Nipun Gupta <nipun.gupta@amd.com>
Link: https://lore.kernel.org/r/20230717150355.1749845-1-robh@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
As &vk->ctx_lock is acquired by timer bcm_vk_hb_poll() under softirq
context, other process context code should disable irq or bottom-half
before acquire the same lock, otherwise deadlock could happen if the
timer preempt the execution while the lock is held in process context
on the same CPU.
Possible deadlock scenario
bcm_vk_open()
-> bcm_vk_get_ctx()
-> spin_lock(&vk->ctx_lock)
<timer iterrupt>
-> bcm_vk_hb_poll()
-> bcm_vk_blk_drv_access()
-> spin_lock_irqsave(&vk->ctx_lock, flags) (deadlock here)
This flaw was found using an experimental static analysis tool we are
developing for irq-related deadlock, which reported the following
warning when analyzing the linux kernel 6.4-rc7 release.
[Deadlock]: &vk->ctx_lock
[Interrupt]: bcm_vk_hb_poll
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:176
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512
[Locking Unit]: bcm_vk_ioctl
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:1181
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512
[Deadlock]: &vk->ctx_lock
[Interrupt]: bcm_vk_hb_poll
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:176
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512
[Locking Unit]: bcm_vk_ioctl
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:1169
[Deadlock]: &vk->ctx_lock
[Interrupt]: bcm_vk_hb_poll
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:176
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512
[Locking Unit]: bcm_vk_open
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:216
[Deadlock]: &vk->ctx_lock
[Interrupt]: bcm_vk_hb_poll
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:176
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_dev.c:512
[Locking Unit]: bcm_vk_release
-->/root/linux/drivers/misc/bcm-vk/bcm_vk_msg.c:306
As suggested by Arnd, the tentative patch fix the potential deadlocks
by replacing the timer with delay workqueue. x86_64 allyesconfig using
GCC shows no new warning. Note that no runtime testing was performed
due to no device on hand.
Signed-off-by: Chengfeng Ye <dg573847474@gmail.com>
Acked-by: Scott Branden <scott.branden@broadcom.com>
Tested-by: Desmond Yan <desmond.branden@broadcom.com>
Tested-by: Desmond Yan <desmond.yan@broadcom.com>
Link: https://lore.kernel.org/r/20230629182941.13045-1-dg573847474@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On s390 systems (aka mainframes), it has classic channel devices for
networking and permanent storage that are currently even more common
than PCI devices. Hence it could have a fully functional s390 kernel
with CONFIG_PCI=n, then the relevant iomem mapping functions
[including ioremap(), devm_ioremap(), etc.] are not available.
Here let depend PCMCIA on HAS_IOMEM so that it won't be built to
cause below compiling error if PCI is unset.
------
ld: drivers/pcmcia/cistpl.o: in function `set_cis_map':
cistpl.c:(.text+0x1202): undefined reference to `ioremap'
ld: cistpl.c:(.text+0x13b0): undefined reference to `iounmap'
ld: cistpl.c:(.text+0x14a6): undefined reference to `iounmap'
ld: cistpl.c:(.text+0x1544): undefined reference to `ioremap'
ld: drivers/pcmcia/cistpl.o: in function `release_cis_mem':
cistpl.c:(.text+0x3f14): undefined reference to `iounmap'
------
Besides, many other Kconfig option, e.g IPWIRELESS, PCMCIA_PCNET,
PCMCIA_FMVJ18X, PCMCIA_SMC91C92 which depends on PCMCIA also will
cause compiling error if enabled.
------
ERROR: modpost: "iounmap" [drivers/tty/ipwireless/ipwireless.ko] undefined!
ERROR: modpost: "ioremap" [drivers/tty/ipwireless/ipwireless.ko] undefined!
ERROR: modpost: "iounmap" [drivers/net/ethernet/8390/pcnet_cs.ko] undefined!
ERROR: modpost: "ioremap" [drivers/net/ethernet/8390/pcnet_cs.ko] undefined!
ERROR: modpost: "iounmap" [drivers/net/ethernet/fujitsu/fmvj18x_cs.ko] undefined!
ERROR: modpost: "ioremap" [drivers/net/ethernet/fujitsu/fmvj18x_cs.ko] undefined!
ERROR: modpost: "iounmap" [drivers/net/ethernet/smsc/smc91c92_cs.ko] undefined!
ERROR: modpost: "ioremap" [drivers/net/ethernet/smsc/smc91c92_cs.ko] undefined!
ERROR: modpost: "iounmap" [drivers/net/ethernet/xircom/xirc2ps_cs.ko] undefined!
ERROR: modpost: "ioremap" [drivers/net/ethernet/xircom/xirc2ps_cs.ko] undefined!
ERROR: modpost: "devm_ioremap" [drivers/net/ethernet/altera/altera_tse.ko] undefined!
ERROR: modpost: "iounmap" [drivers/net/arcnet/com90xx.ko] undefined!
------
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/
Signed-off-by: Baoquan He <bhe@redhat.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Link: https://lore.kernel.org/r/20230707135852.24292-5-bhe@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On s390 systems (aka mainframes), it has classic channel devices for
networking and permanent storage that are currently even more common
than PCI devices. Hence it could have a fully functional s390 kernel
with CONFIG_PCI=n, then the relevant iomem mapping functions
[including ioremap(), devm_ioremap(), etc.] are not available.
Here let XILLYBUS_OF depend on HAS_IOMEM so that it won't be built
to cause below compiling error if PCI is unset:
------
ERROR: modpost: "devm_platform_ioremap_resource" [drivers/char/xillybus/xillybus_of.ko] undefined!
------
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202306211329.ticOJCSv-lkp@intel.com/
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Eli Billauer <eli.billauer@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20230707135852.24292-3-bhe@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result, there's a pretty much random mix of those include
files used throughout the tree. In order to detangle these headers and
replace the implicit includes with struct declarations, users need to
explicitly include the correct includes.
Acked-by: Andrew Donnellan <ajd@linux.ibm.com> # cxl
Signed-off-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230718143102.1065481-1-robh@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() is renamed to .remove().
There are two calls that can go wrong in tps6594_esm_remove(); for both
there is already an error message. Not returning the error code has the
only side effect of suppressing (another) error message by the core
about the error being ignored. So tps6594_esm_remove() can be converted
to return void without any loss.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230710082311.3474785-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.
To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new() which already returns void. Eventually after all drivers
are converted, .remove_new() is renamed to .remove().
Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20230707073343.3396477-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Printing the line number without the file is of limited usefulness.
Knowing the filename also makes it also easier to relate the logged
information to the controlfile.
Example:
# modprobe test_dynamic_debug
# echo 'file test_dynamic_debug.c =pfsl' > /proc/dynamic_debug/control
# echo 1 > /sys/module/test_dynamic_debug/parameters/do_prints
# dmesg | tail -2
[ 71.802212] do_cats:lib/test_dynamic_debug.c:103: test_dd: doing categories
[ 71.802227] do_levels:lib/test_dynamic_debug.c:123: test_dd: doing levels
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Acked-by: Jim Cromie <jim.cromie@gmail.com>
Acked-by: Jason Baron <jbaron@akamai.com>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/20230709-dyndbg-filename-v2-3-fd83beef0925@weissschuh.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fwnode_irq_get[_byname]() were changed to not return 0 anymore. The
special error case where device-tree based IRQ mapping fails can't no
longer be reliably detected from this return value. This yields a
functional change in the driver where the mapping failure is treated as
an error.
The mapping failure can occur for example when the device-tree IRQ
information translation call-back(s) (xlate) fail, IRQ domain is not
found, IRQ type conflicts, etc. In most cases this indicates an error in
the device-tree and special handling is not really required.
One more thing to note is that ACPI APIs do not return zero for any
failures so this special handling did only apply on device-tree based
systems.
Drop the special handling for DT mapping failures as these can no longer
be separated from other errors at driver side. Change all failures in
IRQ getting to be handled by continuing without the events instead of
aborting the probe upon certain errors.
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/3ad1c6f195ead3dfa8711235e1dead139d27f700.1690890774.git.mazziesaccount@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
