iio: dac: driver for MCP4821

Adds driver for the MCP48xx series of DACs.

Device uses a simplex SPI channel. To set the value of an output channel,
a 16-bit data of following format must be written:

Bit field | Description
15 [MSB]  | Channel selection bit
            0 -> Channel A
            1 -> Channel B
13        | Output Gain Selection bit
            0 -> 2x Gain (Vref = 4.096V)
            1 -> 1x Gain (Vref = 2.048V)
12        | Output Shutdown Control bit
            0 -> Shutdown the selected channel
            1 -> Active mode operation
11-0 [LSB]| DAC Input Data bits
            Value's big endian representation is taken as input for the
            selected DAC channel. For devices with a resolution of less
            than 12-bits, only the x most significant bits are considered
            where x is the resolution of the device.
Reference: Page#22 [MCP48x2 Datasheet]

Supported devices:
  +---------+--------------+-------------+
  | Device  |  Resolution  |   Channels  |
  |---------|--------------|-------------|
  | MCP4801 |     8-bit    |      1      |
  | MCP4802 |     8-bit    |      2      |
  | MCP4811 |    10-bit    |      1      |
  | MCP4812 |    10-bit    |      2      |
  | MCP4821 |    12-bit    |      1      |
  | MCP4822 |    12-bit    |      2      |
  +---------+--------------+-------------+

Devices tested:
  MCP4821 [12-bit single channel]
  MCP4802 [8-bit dual channel]

Tested on Raspberry Pi Zero 2W

Datasheet: https://ww1.microchip.com/downloads/en/DeviceDoc/22244B.pdf #MCP48x1
Datasheet: https://ww1.microchip.com/downloads/en/DeviceDoc/20002249B.pdf #MCP48x2
Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
Link: https://lore.kernel.org/r/20231220151954.154595-2-anshulusr@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: dac: add MCP4821

Adds support for MCP48xx series of DACs.

Datasheet: https://ww1.microchip.com/downloads/en/DeviceDoc/22244B.pdf #MCP48x1
Datasheet: https://ww1.microchip.com/downloads/en/DeviceDoc/20002249B.pdf #MCP48x2
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
Link: https://lore.kernel.org/r/20231220151954.154595-1-anshulusr@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: buffer-dma: split iio_dma_buffer_fileio_free() function

This change splits the logic into a separate function, which will be
re-used later.

Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: Alexandru Ardelean <ardeleanalex@gmail.com>
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20231219175009.65482-3-paul@crapouillou.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: buffer-dma: Get rid of outgoing queue

The buffer-dma code was using two queues, incoming and outgoing, to
manage the state of the blocks in use.

While this totally works, it adds some complexity to the code,
especially since the code only manages 2 blocks. It is much easier to
just check each block's state manually, and keep a counter for the next
block to dequeue.

Since the new DMABUF based API wouldn't use the outgoing queue anyway,
getting rid of it now makes the upcoming changes simpler.

With this change, the IIO_BLOCK_STATE_DEQUEUED is now useless, and can
be removed.

Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20231219175009.65482-2-paul@crapouillou.net
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: buffer: Use IIO_SEPARATE instead of a hard-coded 0

Use an explicit IIO_SEPARATE instead of 0 for the 'shared_by' parameter
when calling __iio_add_chan_devattr().

For some reason, commit 3704432fb1fd ("iio: refactor info mask and ext_info
attribute creation.") updated only 1 place out of 4.
Update the remaining ones now.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/1d17f57423172fcb9d9797cfe7c8282f356049c2.1702831285.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

Merge tag 'w1-drv-6.8' of https://git./linux/kernel/git/krzk/linux-w1 into char-misc-next

Krzysztof writes:

1-Wire bus drivers for v6.8

1. Add new AMD AXI 1-wire host driver for AMD programmable logic IP
   core.
2. Add support for Analog Devices DS28EC20 EEPROM to existing DS2433
   driver.
3. Few cleanups in W1 GPIO driver.

* tag 'w1-drv-6.8' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-w1:
  w1: ds2433: add support for ds28ec20 eeprom
  w1: ds2433: use the kernel bitmap implementation
  w1: ds2433: introduce a configuration structure
  w1: ds2433: remove unused definitions
  w1: ds2490: support block sizes larger than 128 bytes in ds_read_block
  w1: amd_axi_w1: Explicitly include correct DT includes
  w1: gpio: rename pointer to driver data from pdata to ddata
  w1: gpio: Drop unused enable_external_pullup from driver data
  w1: gpio: Don't use platform data for driver data
  w1: Add AXI 1-wire host driver for AMD programmable logic IP core
  dt-bindings: w1: Add AMD AXI w1 host and MAINTAINERS entry

Merge tag 'iio-for-6.8a' of https://git./linux/kernel/git/jic23/iio into char-misc-next

Jonathan writes:

1st set of IIO new device support, features and cleanup for 6.8

New device support
------------------

adi,hmc425a
  * Add support for ADRF5740 attenuators.  Minor changes to driver needed
    alongside new IDs.
aosong,ags02ma
  * New driver for this volatile organic compounds sensor.
bosch,bmp280
  * Add BMP390 (small amount of refactoring + ID)
bosch,bmi323
  * New driver to support the BMI323 6-axis IMU.
honeywell,hsc030pa
  * New driver supporting a huge number of SSC and HSC series pressure and
    temperature sensors.
isil,isl76682
  * New driver for this simple Ambient Light sensor.
liteon,ltr390
  * New driver for this ambient and ultraviolet light sensor.
maxim,max34408
  * New driver to support the MAX34408 and MAX34409 current monitoring ADCs.
melexis,mlx90635
  * New driver for this Infrared contactless temperature sensor.
mirochip,mcp9600
  * New driver for this thermocouple EMF convertor.
ti,hdc3020
  * New driver for this integrated relative humidity and temperature
    sensor.
vishay,veml6075
  * New driver for this UVA and UVB light sensor.

General features
----------------

Device properties
  * Add fwnode_property_match_property_string() helper to allow matching
    single value property against an array of predefined strings.
  * Use fwnode_property_string_array_count() inside
    fwnode_property_match_string() instead of open coding the same.
checkpatch.pl
  * Add exclusion of __aligned() from a warning reducing false positives
    on IIO drivers (and hopefully beyond)

IIO Features
------------

core
  * New light channel modifiers for UVA and UVB.
  * Add IIO_CHAN_INFO_TROUGH as counterpart to IIO_CHAN_INFO_PEAK so that
    we can support device that keep running track of the lowest value they
    have seen in similar fashion to the existing peak tracking.
adi,adis library
  * Use spi cs inactive delay even when a burst reading is performed.
    As it's now used every time, can centralize the handling in the SPI
    setup code in the driver.
adi,ad2s1210
  * Support for fixed-mode to this resolver driver where the A0 and A1
    pins are hard wired to config mode in which case position and config
    must be read from appropriate config registers.
  * Support reset GPIO if present.
adi,ad5791
  * Allow configuration of presence of external amplifier in DT binding.
adi,adis16400
  * Add spi-cs-inactive-delay-ns to bindings to allow it to be tweaked
    if default delays are not quite enough for a specific board.
adi,adis16475
  * Add spi-cs-inactive-delay-ns to bindings to allow it to be tweaked
    if default delays are not quite enough for a specific board.
bosch,bmp280
  * Enable multiple chip IDs per family of devices.
rohm,bu27008
  * Add an illuminance channel calculated from RGB and IR data.

Cleanup
-------

Minor white space, typos and tidy up not explicitly called out.

Core
  * Check that the available_scan_masks array passed to the IIO core
    by a driver is sensible by ensuring the entries are ordered so the
    minimum number of channels is enabled in the earlier entries (as they
    will be selected if sufficient for the requested channels).
  * Document that the available_scan_masks infrastructure doesn't currently
    handle masks that don't fit in a long int.
  * Improve intensity documentation to reflect that there is no expectation
    of sensible units (it's dependent on a frequency sensitivity curve)
Various
  * Use new device_property_match_property_string() to replace open coded
    versions of the same thing.
  * Fix a few MAINTAINERS filenames.
  * i2c_get_match_data() and spi_get_device_match_data() pushed into
    more drivers reducing boilerplate handling.
  * Some unnecessary headers removed.
  * ACPI_PTR() removals. It's rarely worth using this.
adi,ad7091r (early part of a series adding device support - useful in
  their own right)
  * Pass iio_dev directly an event handler rather than relying
    on broken use of dev_get_drvdata() as drvdata is never set in this driver.
  * Make sure alert is turned on.
adi,ad9467 (general driver fixing up as precursor to iio-backend proposal
  which is under review for 6.9)
  * Fix reset gpio handling to match expected polarity.
  * Always handle error codes from spi_writes.
  * Add a driver instance local mutex to avoid some races.
  * Fix scale setting to align with available scale values.
  * Split array of chip_info structures up into named individual elements.
  * Convert to regmap.
honeywell,mprls0025pa
  * Drop now unnecessary type references in DT binding for properties in
    pascals.
invensense,mpu6050
  * Don't eat a potentially useful return value from regmap_bulk_write()
invensense,icm42600
  * Use max macro to improve code readability and save a few lines.
liteon,ltrf216a
  * Improve prevision of light intensity.
microchip,mcp3911
  * Use cleanup.h magic.
qcom,spmi*
  * Fix wrong descriptions of SPMI reg fields in bindings.

Other
----

mailmap
  * Update for Matt Ranostay

* tag 'iio-for-6.8a' of https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio: (83 commits)
  iio: adc: ad7091r: Align arguments to function call parenthesis
  iio: adc: ad7091r: Set alert bit in config register
  iio: adc: ad7091r: Pass iio_dev to event handler
  scripts: checkpatch: Add __aligned to the list of attribute notes
  iio: chemical: add support for Aosong AGS02MA
  dt-bindings: iio: chemical: add aosong,ags02ma
  dt-bindings: vendor-prefixes: add aosong
  iio: accel: bmi088: update comments and Kconfig
  dt-bindings: iio: humidity: Add TI HDC302x support
  iio: humidity: Add driver for ti HDC302x humidity sensors
  iio: ABI: document temperature and humidity peak/trough raw attributes
  iio: core: introduce trough info element for minimum values
  iio: light: driver for Lite-On ltr390
  dt-bindings: iio: light: add ltr390
  iio: light: isl76682: remove unreachable code
  iio: pressure: driver for Honeywell HSC/SSC series
  dt-bindings: iio: pressure: add honeywell,hsc030
  doc: iio: Document intensity scale as poorly defined
  dt-bindings: iio: temperature: add MLX90635 device
  iio: temperature: mlx90635 MLX90635 IR Temperature sensor
  ...

w1: ds2433: add support for ds28ec20 eeprom

The ds28ec20 eeprom is (almost) backward compatible with the
ds2433. The only differences are:

- the eeprom size is now 2560 bytes instead of 512;
- the number of pages is now 80 (same page size as the ds2433: 256 bits);
- the programming time has increased from 5ms to 10ms;

This patch adds support for the ds28ec20 to the ds2433 driver. From
the datasheet: The DS28EC20 provides a high degree of backward
compatibility with the DS2433. Besides the different family codes, the
only protocol change that is required on an existing DS2433
implementation is a lengthening of the programming duration (tPROG)
from 5ms to 10ms.

dmesg now returns:

    w1_master_driver w1_bus_master1: Attaching one wire slave 43.000000478756 crc e0

instead of:

    w1_master_driver w1_bus_master1: Attaching one wire slave 43.000000478756 crc e0
    w1_master_driver w1_bus_master1: Family 43 for 43.000000478756.e0 is not registered.

Test script writing/reading random data (CONFIG_W1_SLAVE_DS2433_CRC is
not set):

    #!/bin/sh

    EEPROM=/sys/bus/w1/devices/43-000000478756/eeprom
    BINFILE1=/home/root/file1.bin
    BINFILE2=/home/root/file2.bin

    for BS in 1 2 3 4 8 16 32 64 128 256 512 1024 2560; do
        dd if=/dev/random of=${BINFILE1} bs=${BS} count=1 status=none
        dd if=${BINFILE1} of=${EEPROM} status=none
        dd if=${EEPROM} of=${BINFILE2} bs=${BS} count=1 status=none
        if ! cmp --silent ${BINFILE1} ${BINFILE2}; then
         echo file1
         hexdump ${BINFILE1}
         echo file2
         hexdump ${BINFILE2}
         echo FAIL
         exit 1
        fi
        echo "${BS} OK!"
    done

Results:

    # ./test.sh
    1 OK!
    2 OK!
    3 OK!
    4 OK!
    8 OK!
    16 OK!
    32 OK!
    64 OK!
    128 OK!
    256 OK!
    512 OK!
    1024 OK!
    2560 OK!

Tests with CONFIG_W1_SLAVE_DS2433_CRC=y:

    $ cat /proc/config.gz | gunzip | grep CONFIG_W1_SLAVE_DS2433
    CONFIG_W1_SLAVE_DS2433=m
    CONFIG_W1_SLAVE_DS2433_CRC=y

    # create a 32 bytes block with a crc, i.e.:
    00000000  31 32 33 34 35 36 37 38  39 3a 3b 3c 3d 3e 3f 40  |123456789:;<=>?@|
    00000010  41 42 43 44 45 46 47 48  49 4a 4b 4c 4d 4e ba 63  |ABCDEFGHIJKLMN.c|

    # fill all 80 blocks
    $ dd if=test.bin of=/sys/bus/w1/devices/43-000000478756/eeprom bs=32 count=80

    # read back all blocks, i.e.:
    $ hexdump -C /sys/bus/w1/devices/43-000000478756/eeprom
    00000000  31 32 33 34 35 36 37 38  39 3a 3b 3c 3d 3e 3f 40  |123456789:;<=>?@|
    00000010  41 42 43 44 45 46 47 48  49 4a 4b 4c 4d 4e ba 63  |ABCDEFGHIJKLMN.c|
    00000020  31 32 33 34 35 36 37 38  39 3a 3b 3c 3d 3e 3f 40  |123456789:;<=>?@|
    00000030  41 42 43 44 45 46 47 48  49 4a 4b 4c 4d 4e ba 63  |ABCDEFGHIJKLMN.c|
    ...
    000009e0  31 32 33 34 35 36 37 38  39 3a 3b 3c 3d 3e 3f 40  |123456789:;<=>?@|
    000009f0  41 42 43 44 45 46 47 48  49 4a 4b 4c 4d 4e ba 63  |ABCDEFGHIJKLMN.c|
    00000a00

Note: both memories (ds2433 and ds28ec20) have been tested with the
new driver.

Signed-off-by: Marc Ferland <marc.ferland@sonatest.com>
Co-developed-by: Jean-Francois Dagenais <jeff.dagenais@gmail.com>
Signed-off-by: Jean-Francois Dagenais <jeff.dagenais@gmail.com>
Link: https://lore.kernel.org/r/20231218150230.1992448-6-marc.ferland@sonatest.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

w1: ds2433: use the kernel bitmap implementation

The ds2433 driver uses the 'validcrc' variable to mark out which pages
have been successfully (crc is valid) retrieved from the eeprom and
placed in the internal 'memory' buffer (see CONFIG_W1_SLAVE_DS2433_CRC).

The current implementation assumes that the number of pages will never
go beyond 32 pages (bit field is a u32). This is fine for the ds2433
since it only has 16 pages.

On the ds28ec20 though, the number of pages increases to 80 which will
not fit on a single u32.

As a solution, I replaced the u32 variable with a standard bitmap and
set the number of bits to 32 which is the same size we had before.

Signed-off-by: Marc Ferland <marc.ferland@sonatest.com>
Link: https://lore.kernel.org/r/20231218150230.1992448-5-marc.ferland@sonatest.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

w1: ds2433: introduce a configuration structure

Add a ds2433_config structure for parameters that are different
between the ds2433 and the ds28ec20. The goal is to reuse the same
code for both chips.

A pointer to this config structure is added to w1_f23_data and the
CONFIG_W1_SLAVE_DS2433_CRC ifdefs are adjusted since now both driver
configurations (with or without crc support) will make use of
w1_f23_data.

Also, the 'memory' buffer is now dynamically allocated based on the
size specififed in the config structure to help support memories of
different sizes.

Signed-off-by: Marc Ferland <marc.ferland@sonatest.com>
Link: https://lore.kernel.org/r/20231218150230.1992448-4-marc.ferland@sonatest.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

w1: ds2433: remove unused definitions

Both W1_F23_TIME and W1_PAGE_COUNT are unused, get rid of them.

Signed-off-by: Marc Ferland <marc.ferland@sonatest.com>
Link: https://lore.kernel.org/r/20231218150230.1992448-3-marc.ferland@sonatest.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

w1: ds2490: support block sizes larger than 128 bytes in ds_read_block

The current ds_read_block function only supports block sizes up to
128 bytes, which is the depth of the 'data out' fifo on the ds2490.

Reading larger blocks will fail with a: -110 (ETIMEDOUT) from
usb_control_msg(). Example:

    $ dd if=/sys/bus/w1/devices/43-000000478756/eeprom bs=256 count=1

yields to the following message from the kernel:

    usb 5-1: Failed to write 1-wire data to ep0x2: err=-110.

I discovered this issue while implementing support for the ds28ec20
eeprom in the w1-2433 driver. This driver accepts reading blocks of
sizes up to the size of the entire memory (2560 bytes in the case of
the ds28ec20). Note that this issue _does not_ arise when the kernel
is configured with CONFIG_W1_SLAVE_DS2433_CRC enabled since in this
mode the driver reads one 32 byte block at a time (a single memory
page).

Also, from the ds2490 datasheet (2995.pdf, page 22, BLOCK I/O
command):

     For a block write sequence the EP2 FIFO must be pre-filled with
     data before command execution. Additionally, for block sizes
     greater then the FIFO size, the FIFO content status must be
     monitored by host SW so that additional data can be sent to the
     FIFO when necessary. A similar EP3 FIFO content monitoring
     requirement exists for block read sequences. During a block read
     the number of bytes loaded into the EP3 FIFO must be monitored so
     that the data can be read before the FIFO overflows.

Breaking the block in smaller 128 bytes chunks and simply calling the
original code sequence has solved the issue for me.

Tested with a DS1490F usb<->one-wire adapter and both the DS28EC20 and
DS2433 eeprom memories.

Signed-off-by: Marc Ferland <marc.ferland@sonatest.com>
Link: https://lore.kernel.org/r/20231218150230.1992448-2-marc.ferland@sonatest.com
[krzysztof: fix checkpatch 'spaces preferred around']
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Merge tag 'extcon-next-for-6.8' of git://git./linux/kernel/git/chanwoo/extcon into char-misc-next

Chanwoo writes:

Update extcon next for v6.8

Detailed description for this pull request:
1. Fix possible memory leak of device name in extcon_dev_register()
 : Fix memory leak on error path of extcon_dev_register().

2. Set interrupt polarity based on device-tree for extcon-usbc-tusb320.c
 :Remove 'IRQF_TRIGGER_FALLING' request which is not allowed on
 every interrupt controller (i.e. arm64 GIC). Replace flag by a
 request that depends on the actual device-tree setting.

3. Fix the comment style according to guide on extcon-qcom-spmi-misc.c.

* tag 'extcon-next-for-6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon:
  extcon: qcom-spmi-misc: don't use kernel-doc marker for comment
  extcon: usbc-tusb320: Set interrupt polarity based on device-tree
  extcon: fix possible name leak in extcon_dev_register()

Merge tag 'mhi-for-v6.8' of git://git./linux/kernel/git/mani/mhi into char-misc-next

Manivannan writes:

MHI Host
========

- Added alignment check for event ring read pointer to avoid the potential
  buffer corruption issue.
- Added support for SDX75 modem which takes longer time to enter READY state.
- Added spinlock to protect concurrent access while queuing transfer ring
  elements.
- Dropped the read channel lock before invoking the client callback as the
  client can potentially queue buffers thus ending up wtih soft lockup.

MHI Endpoint
============

- Used kzalloc() to allocate event ring elements instead of allocating the
  elements on the stack, as the endpoint controller trying to queue them may not
  be able to use vmalloc memory (using DMA).
- Used slab allocator for allocting the memory for objects used frequently and
  are of fixed size.
- Added support for interrupt moderation timer feature which is used by the host
  to limit the number of interrupts raised by the device for an event ring.
- Added async read/write DMA support for transferring data between host and the
  endpoint. So far MHI EP stack assumed that the data will be transferred
  synchronously (i.e., it sends completion once the transfer APIs are returned).
  But this impacts the throughput if the controller is using DMA to do the
  transfer.

  So to add async suport, existing sync transfer APIs are renamed to
  {read/write}_sync and also introduced two new APIs {read/write}_async for
  carrying out the async transfer.

  Controllers implementing the async APIs should queue the buffers and return
  immediately without waiting for transfer completion. Once the transfer
  completion happens later, they should invoke the completion callback so that
  the MHI EP stack can send the completion event to the host.

  The controller driver patches (PCI EPF) for this async support are also merged
  to the MHI tree with Acks from PCI maintainers.
- Fixed the DMA channel direction in error path of the PCI EPF driver.

* tag 'mhi-for-v6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/mani/mhi:
  bus: mhi: host: Drop chan lock before queuing buffers
  bus: mhi: host: Add spinlock to protect WP access when queueing TREs
  PCI: epf-mhi: Fix the DMA data direction of dma_unmap_single()
  bus: mhi: ep: Add checks for read/write callbacks while registering controllers
  bus: mhi: ep: Add support for async DMA read operation
  bus: mhi: ep: Add support for async DMA write operation
  PCI: epf-mhi: Enable MHI async read/write support
  PCI: epf-mhi: Add support for DMA async read/write operation
  PCI: epf-mhi: Simulate async read/write using iATU
  bus: mhi: ep: Introduce async read/write callbacks
  bus: mhi: ep: Rename read_from_host() and write_to_host() APIs
  bus: mhi: ep: Pass mhi_ep_buf_info struct to read/write APIs
  bus: mhi: ep: Add support for interrupt moderation timer
  bus: mhi: ep: Use slab allocator where applicable
  bus: mhi: host: Add alignment check for event ring read pointer
  bus: mhi: host: pci_generic: Add SDX75 based modem support
  bus: mhi: host: Add a separate timeout parameter for waiting ready
  bus: mhi: ep: Do not allocate event ring element on stack

Merge tag 'fpga-for-6.8-rc1' of git://git./linux/kernel/git/fpga/linux-fpga into char-misc-next

Xu writes:

FPGA Manager changes for 6.8-rc1

DFL:

- Philipp's change uses memdup_array_user() to do better overflow check

All patches have been reviewed on the mailing list, and have been in the
last linux-next releases (as part of our for-next branch).

Signed-off-by: Xu Yilun <yilun.xu@intel.com>
* tag 'fpga-for-6.8-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/fpga/linux-fpga:
  drivers/fpga: use standard array-copy function

iio: adc: ad7091r: Align arguments to function call parenthesis

Align arguments to function call open parenthesis to comply with the
Linux kernel coding style.

Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
Link: https://lore.kernel.org/r/fc71a82d3b4a6bc6f511f27451dbd7a3280a8c95.1702746240.git.marcelo.schmitt1@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad7091r: Set alert bit in config register

The ad7091r-base driver sets up an interrupt handler for firing events
when inputs are either above or below a certain threshold.
However, for the interrupt signal to come from the device it must be
configured to enable the ALERT/BUSY/GPO pin to be used as ALERT, which
was not being done until now.
Enable interrupt signals on the ALERT/BUSY/GPO pin by setting the proper
bit in the configuration register.

Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
Link: https://lore.kernel.org/r/e8da2ee98d6df88318b14baf3dc9630e20218418.1702746240.git.marcelo.schmitt1@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: adc: ad7091r: Pass iio_dev to event handler

Previous version of ad7091r event handler received the ADC state pointer
and retrieved the iio device from driver data field with dev_get_drvdata().
However, no driver data have ever been set, which led to null pointer
dereference when running the event handler.

Pass the iio device to the event handler and retrieve the ADC state struct
from it so we avoid the null pointer dereference and save the driver from
filling the driver data field.

Fixes: ca69300173b6 ("iio: adc: Add support for AD7091R5 ADC")
Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
Link: https://lore.kernel.org/r/5024b764107463de9578d5b3b0a3d5678e307b1a.1702746240.git.marcelo.schmitt1@gmail.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

scripts: checkpatch: Add __aligned to the list of attribute notes

Checkpatch presumes attributes marked with __aligned(alignment) are part
of a function declaration and throws a warning stating that those
compiler attributes should have an identifier name which is not correct.
Add __aligned compiler attributes to the list of attribute notes
so they don't cause warnings anymore.

Signed-off-by: Marcelo Schmitt <marcelo.schmitt@analog.com>
Acked-by: Joe Perches <joe@perches.com>
Link: https://lore.kernel.org/r/1c5c93ecbd8c46a338b22a4ef52e51648e333c01.1702746240.git.marcelo.schmitt1@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: chemical: add support for Aosong AGS02MA

A simple driver for the TVOC (Total Volatile Organic Compounds)
sensor from Aosong: AGS02MA

Steps in reading the VOC sensor value over i2c:
  1. Read 5 bytes from the register `AGS02MA_TVOC_READ_REG` [0x00]
  2. The first 4 bytes are taken as the big endian sensor data with final
     byte being the CRC
  3. The CRC is verified and the value is returned over an
     `IIO_CHAN_INFO_RAW` channel as percents

Tested on Raspberry Pi Zero 2W

Datasheet: https://asairsensors.com/wp-content/uploads/2021/09/AGS02MA.pdf
Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
Link: https://lore.kernel.org/r/20231215162312.143568-3-anshulusr@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: chemical: add aosong,ags02ma

Add bindings for Aosong AGS02MA TVOC sensor.

The sensor communicates over i2c with the default address 0x1a.
TVOC values can be read in the units of ppb and ug/m^3 at register 0x00.

Datasheet: https://asairsensors.com/wp-content/uploads/2021/09/AGS02MA.pdf
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
Link: https://lore.kernel.org/r/20231215162312.143568-2-anshulusr@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: vendor-prefixes: add aosong

Aosong Electronic Co., LTD. is a supplier for MEMS sensors such as AHT20
temperature and humidity sensor under the brand name Asair

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
Link: https://lore.kernel.org/r/20231215162312.143568-1-anshulusr@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: accel: bmi088: update comments and Kconfig

update the comments and Kconfig file with more descriptive and
accurate information about newly added device: BMI085, BMI090L.

Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

greybus: gb-beagleplay: Remove use of pad bytes

Make gb-beagleplay greybus spec compliant by moving cport information to
transport layer instead of using `header->pad` bytes.

Greybus HDLC frame now has the following payload:
1. le16 cport
2. gb_operation_msg_hdr msg_header
3. u8 *msg_payload

Fixes: ec558bbfea67 ("greybus: Add BeaglePlay Linux Driver")
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
Link: https://lore.kernel.org/r/20231217121133.74703-2-ayushdevel1325@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

bus: mhi: host: Drop chan lock before queuing buffers

Ensure read and write locks for the channel are not taken in succession by
dropping the read lock from parse_xfer_event() such that a callback given
to client can potentially queue buffers and acquire the write lock in that
process. Any queueing of buffers should be done without channel read lock
acquired as it can result in multiple locks and a soft lockup.

Cc: <stable@vger.kernel.org> # 5.7
Fixes: 1d3173a3bae7 ("bus: mhi: core: Add support for processing events from client device")
Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/1702276972-41296-3-git-send-email-quic_qianyu@quicinc.com
[mani: added fixes tag and cc'ed stable]
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: host: Add spinlock to protect WP access when queueing TREs

Protect WP accesses such that multiple threads queueing buffers for
incoming data do not race.

Meanwhile, if CONFIG_TRACE_IRQFLAGS is enabled, irq will be enabled once
__local_bh_enable_ip is called as part of write_unlock_bh. Hence, let's
take irqsave lock after TRE is generated to avoid running write_unlock_bh
when irqsave lock is held.

Cc: stable@vger.kernel.org
Fixes: 189ff97cca53 ("bus: mhi: core: Add support for data transfer")
Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Tested-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/1702276972-41296-2-git-send-email-quic_qianyu@quicinc.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

parport: parport_serial: Add Brainboxes device IDs and geometry

Add device IDs for the Brainboxes UC-203, UC-257, UC-414, UC-475,
IS-300/IS-500 and PX-263/PX-295 and define the relevant "geometry"
for the cards.
This patch requires part 1 of this series.

Cc: <stable@vger.kernel.org>
Signed-off-by: Cameron Williams <cang1@live.co.uk>
Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Link: https://lore.kernel.org/r/AS4PR02MB7903A4094564BE28F1F926A6C4A6A@AS4PR02MB7903.eurprd02.prod.outlook.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

parport: parport_serial: Add Brainboxes BAR details

Add BAR/enum entries for Brainboxes serial/parallel cards.

Cc: <stable@vger.kernel.org>
Signed-off-by: Cameron Williams <cang1@live.co.uk>
Acked-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Link: https://lore.kernel.org/r/AS4PR02MB79035155C2D5C3333AE6FA52C4A6A@AS4PR02MB7903.eurprd02.prod.outlook.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

firmware: xilinx: Remove zynqmp_pm_pinctrl_get_function()

There is no user for this interface that's why remove it.

Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/e52a415a004e28a43e6d08e9e22d9e8fef3737df.1702565618.git.michal.simek@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

firmware: xilinx: Remove clock_setrate and clock_getrate api

As per the current code base, PM_CLOCK_SETRATE and PM_CLOCK_GETRATE
APIs are not supported for the runtime operations. In the case of
ZynqMP returning an error from TF-A when there is any request to
access these APIs and for Versal also it is returning an error like
NO_ACCESS from the firmware. So, just removing the unused code to
avoid the confusion around these APIs.

Also, there is no issue with the backward compatibility as these APIs
were never used since implemented. Hence no need to bump up the
version of the feature check API as well.

Signed-off-by: Ronak Jain <ronak.jain@amd.com>
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/6ccbffbafd1f0f48f6574d5a3bf2db6a5603fdb0.1702565618.git.michal.simek@amd.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

VMCI: Remove VMCI_HANDLE_ARRAY_HEADER_SIZE and VMCI_HANDLE_ARRAY_MAX_CAPACITY

Remove VMCI_HANDLE_ARRAY_HEADER_SIZE and VMCI_HANDLE_ARRAY_MAX_CAPACITY
that are unused.

Suggested-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/00547fe74efe329b266eb8074c41f286758a3c64.1702125347.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

VMCI: Remove handle_arr_calc_size()

Use struct_size() instead of handle_arr_calc_size().
This is much more conventional.

While at it, use size_add() when computing the needed size in
vmci_handle_arr_append_entry(). This prevents from (unlikely) overflow
when computing the new size to reallocate.

Suggested-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/84e7f2d8e7c4c2eab68f958307d56546978f76e3.1702125347.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spmi: mediatek: add device id check

Add device id check for spmi write API.

Signed-off-by: Sen Chu <sen.chu@mediatek.com>
Link: https://lore.kernel.org/r/20230518040729.8789-1-sen.chu@mediatek.com
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20231206231733.4031901-9-sboyd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spmi: Return meaningful errors in spmi_controller_alloc()

spmi_controller_alloc() currently returns NULL to all types of errors,
which can be improved.

Use appropriate error code in returns and pass the errors from used
functions where possible.

Signed-off-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20230824104101.4083400-6-fshao@chromium.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20231206231733.4031901-8-sboyd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spmi: hisi-spmi-controller: Use devm_spmi_controller_add()

Convert to the device-managed version of spmi_controller_add() and
delete the unnecessary driver remove callback.

Signed-off-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20230824104101.4083400-5-fshao@chromium.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20231206231733.4031901-7-sboyd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spmi: mtk-pmif: Reorder driver remove sequence

This driver enables clocks and then adds SPMI controller in probing, so
we expect the reversed sequence in removal.
Fix the order in the remove callback.

Signed-off-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20230824104101.4083400-4-fshao@chromium.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20231206231733.4031901-6-sboyd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spmi: Use devm_spmi_controller_alloc()

Convert to the device-managed version of spmi_controller_alloc() and
simplify the excess error handling code.

Signed-off-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20230824104101.4083400-3-fshao@chromium.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20231206231733.4031901-5-sboyd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spmi: Introduce device-managed functions

Utilize the managed resource (devres) framework and add the following
devm_* helpers for the SPMI driver:

- devm_spmi_controller_alloc()
- devm_spmi_controller_add()

[sboyd@kernel.org: Rename to spmi-devres for module niceness, slap on
GPL module license]

Signed-off-by: Fei Shao <fshao@chromium.org>
Link: https://lore.kernel.org/r/20230824104101.4083400-2-fshao@chromium.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20231206231733.4031901-4-sboyd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spmi: mediatek: Fix UAF on device remove

The pmif driver data that contains the clocks is allocated along with
spmi_controller.
On device remove, spmi_controller will be freed first, and then devres
, including the clocks, will be cleanup.
This leads to UAF because putting the clocks will access the clocks in
the pmif driver data, which is already freed along with spmi_controller.

This can be reproduced by enabling DEBUG_TEST_DRIVER_REMOVE and
building the kernel with KASAN.

Fix the UAF issue by using unmanaged clk_bulk_get() and putting the
clocks before freeing spmi_controller.

Reported-by: Fei Shao <fshao@chromium.org>
Signed-off-by: Yu-Che Cheng <giver@chromium.org>
Link: https://lore.kernel.org/r/20230717173934.1.If004a6e055a189c7f2d0724fa814422c26789839@changeid
Tested-by: Fei Shao <fshao@chromium.org>
Reviewed-by: Fei Shao <fshao@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20231206231733.4031901-3-sboyd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

spmi: mtk-pmif: Serialize PMIF status check and command submission

Before writing the read or write command to the SPMI arbiter through the
PMIF interface, the current status of the channel is checked to ensure
it is idle. However, since the status only changes from idle when the
command is written, it is possible for two concurrent calls to determine
that the channel is idle and simultaneously send their commands. At this
point the PMIF interface hangs, with the status register no longer being
updated, and thus causing all subsequent operations to time out.

This was observed on the mt8195-cherry-tomato-r2 machine, particularly
after commit 46600ab142f8 ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for
drivers between 5.10 and 5.15") was applied, since then the two MT6315
devices present on the SPMI bus would probe assynchronously and
sometimes (during probe or at a later point) read the bus
simultaneously, breaking the PMIF interface and consequently slowing
down the whole system.

To fix the issue at its root cause, introduce locking around the channel
status check and the command write, so that both become an atomic
operation, preventing race conditions between two (or more) SPMI bus
read/write operations. A spinlock is used since this is a fast bus, as
indicated by the usage of the atomic variant of readl_poll, and
'.fast_io = true' being used in the mt6315 driver, so spinlocks are
already used for the regmap access.

Fixes: b45b3ccef8c0 ("spmi: mediatek: Add support for MT6873/8192")
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
Link: https://lore.kernel.org/r/20230724154739.493724-1-nfraprado@collabora.com
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lore.kernel.org/r/20231206231733.4031901-2-sboyd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mmc: rtsx: add rts5264 to support sd express card

rts5264 can support sd express card, so add the id in sd express card init
to do rts5264 register setting when the sd express card insert

Signed-off-by: Ricky Wu <ricky_wu@realtek.com>
Link: https://lore.kernel.org/r/20231208032145.2143580-4-ricky_wu@realtek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

misc: rtsx: add to support new card reader rts5264

in order to support rts5264 in rtsx_pcr add the id in and
determine whether the device is rts5264 to call rts5264
functions and do rts5264 workflows or set rts5264 registers

Signed-off-by: Ricky Wu <ricky_wu@realtek.com>
Link: https://lore.kernel.org/r/20231208032145.2143580-3-ricky_wu@realtek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

misc: rtsx: add to support new card reader rts5264 new definition and function

in order to support NEW chip rts5264, the definitions of some internal
registers are define in new file rts5264.h, and some callback functions
and the workflow for rts5264 are define in new file rts5264.c

also add rts5264.o to Makefile

Signed-off-by: Ricky Wu <ricky_wu@realtek.com>
Link: https://lore.kernel.org/r/20231208032145.2143580-2-ricky_wu@realtek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cdx: Explicitly include correct DT includes, again

The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it was 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.

CDX was fixed once, but commit ("cdx: Remove cdx controller list from cdx
bus system") added another occurrence.

Fixes: 54b406e10f03 ("cdx: Remove cdx controller list from cdx bus system")
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Nikhil Agarwal <Nikhil.agarwal@amd.com>
Link: https://lore.kernel.org/r/20231207163128.2707993-2-robh@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

misc: nsm: remove selecting the non-existing config CBOR

Commit b9873755a6c8 ("misc: Add Nitro Secure Module driver") adds Nitro
Security Module support, which selects the non-existing config CBOR.

In the development of the commit, there was initially some code for CBOR
independent of the driver, and the driver included this code with the line
'select CBOR'. This code for CBOR was later reduced to its bare minimum of
functionality and included into the driver itself. The select CBOR remained
unnoticed and was left behind without having any further purpose.

Remove selecting the non-existing config CBOR.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Alexander Graf <graf@amazon.com>
Link: https://lore.kernel.org/r/20231211074242.22999-1-lukas.bulwahn@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pcmcia: xxs1500_ss: Convert to platform remove callback returning void

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() will be 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/09a89926787cb9f64caa73c510f04d9f04a5136f.1702051073.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pcmcia: sa1100: Convert to platform remove callback returning void

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() will be 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/6473afe67fc5c320a8184d0871a8561f7685e265.1702051073.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pcmcia: pxa2xx: Convert to platform remove callback returning void

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() will be 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/fb750d46ac80b6dfdeaa26053a2cf9d2dc875d4d.1702051073.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pcmcia: omap_cf: Convert to platform remove callback returning void

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() will be 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/9d96646b75b10f7562d4d18010e885b7fc55e0ab.1702051073.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pcmcia: electra_cf: Convert to platform remove callback returning void

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() will be 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/7b07c8624ab53ec90554b7a665bef7662bd94295.1702051073.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pcmcia: db1xxx_ss: Convert to platform remove callback returning void

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() will be 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/3d4c108421f2b1175d3a75ee6854e7772f8a0f82.1702051073.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pcmcia: bcm63xx: Convert to platform remove callback returning void

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() will be 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/33611a4245b4dabc609a75cf0e0db5e06e9a6fc8.1702051073.git.u.kleine-koenig@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

tools/testing/nvdimm: Add compile-test coverage for ndtest

Greg lamented:
"Ick, sorry about that, obviously this test isn't actually built by any
bots :("

A quick and dirty way to prevent this problem going forward is to always
compile ndtest.ko whenever nfit_test is built. While this still does not
expose the test code to any of the known build bots, it at least makes
it the case that anyone that runs the x86 tests also compiles the
powerpc test.

I.e. the Intel NVDIMM maintainers are less likely to fall into this hole
in the future.

Link: http://lore.kernel.org/r/2023112729-aids-drainable-5744@gregkh
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Yi Zhang <yi.zhang@redhat.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Ira Weiny <ira.weiny@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/170191437889.426826.15528612879942432918.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mcb: core: fix kernel-doc warnings

Correct function comments to prevent warnings from
scripts/kernel-doc.

mcb-core.c:270: warning: Function parameter or member 'carrier' not described in 'mcb_alloc_bus'
mcb-core.c:336: warning: expecting prototype for mcb_bus_put(). Prototype was for mcb_bus_get() instead
mcb-core.c:463: warning: Function parameter or member 'mem' not described in 'mcb_release_mem'
mcb-core.c:463: warning: Excess function parameter 'dev' description in 'mcb_release_mem'

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Johannes Thumshirn <morbidrsa@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20231206055821.17284-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

binder: use enum for binder ioctls

All of the other constants in this file are defined using enums, so make
the constants more consistent by defining the ioctls in an enum as well.

This is necessary for Rust Binder since the _IO macros are too
complicated for bindgen to see that they expand to integer constants.
Replacing the #defines with an enum forces bindgen to evaluate them
properly, which allows us to access them from Rust.

I originally intended to include this change in the first patch of the
Rust Binder patchset [1], but at plumbers Carlos Llamas told me that
this change has been discussed previously [2] and suggested that I send
it upstream separately.

Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-1-08ba9197f637@google.com/
Link: https://lore.kernel.org/all/YoIK2l6xbQMPGZHy@kroah.com/
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Carlos Llamas <cmllamas@google.com>
Link: https://lore.kernel.org/r/20231208152801.3425772-1-aliceryhl@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: rework Kconfig dependencies

The dependencies in the mei framework are inconsistent, with some symbols
using 'select INTEL_MEI' to force it being enabled and others using
'depends on INTEL_MEI'.

In general, one should not select user-visible symbols, so change all
of these to normal dependencies, but change the default on INTEL_MEI to
be enabled when building a kernel for an Intel CPU with ME or a generic
x86 kernel.

Having consistent dependencies makes the 'menuconfig' listing more
readable by using proper indentation.

A large if/endif block is just a simpler syntax than repeating the
dependencies for each symbol.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Wentong Wu <wentong.wu@intel.com>
Link: https://lore.kernel.org/r/20231214183946.109124-2-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: fix vsc dependency

CONFIG_INTEL_MEI_VSC_HW can be set to built-in even with CONFIG_MEI=m,
but then the driver is not built because Kbuild never enters the
drivers/misc/mei directory for built-in files, leading to a link
failure:

ERROR: modpost: "vsc_tp_reset" [drivers/misc/mei/mei-vsc.ko] undefined!
ERROR: modpost: "vsc_tp_init" [drivers/misc/mei/mei-vsc.ko] undefined!
ERROR: modpost: "vsc_tp_xfer" [drivers/misc/mei/mei-vsc.ko] undefined!
ERROR: modpost: "vsc_tp_need_read" [drivers/misc/mei/mei-vsc.ko] undefined!
ERROR: modpost: "vsc_tp_intr_enable" [drivers/misc/mei/mei-vsc.ko] undefined!
ERROR: modpost: "vsc_tp_intr_synchronize" [drivers/misc/mei/mei-vsc.ko] undefined!
ERROR: modpost: "vsc_tp_intr_disable" [drivers/misc/mei/mei-vsc.ko] undefined!
ERROR: modpost: "vsc_tp_register_event_cb" [drivers/misc/mei/mei-vsc.ko] undefined!

Add an explicit dependency on CONFIG_MEI that was apparently missing,
to ensure the VSC_HW driver cannot be built-in with MEI itself being
a loadable module.

Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Wentong Wu <wentong.wu@intel.com>
Link: https://lore.kernel.org/r/20231214183946.109124-1-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: vsc: Rework firmware image names

Rework firmware image names with the users in mind---there's no need for
variation between firmware names, apart from connected sensors. All
supported SoCs use the same firmware, too.

Use a single set of firmware binaries and assume they'll be found under
intel/vsc directory.

Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Tested-by: Wentong Wu <wentong.wu@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231213094055.446611-1-sakari.ailus@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: pxp: spdx should be at first line

Remove stray empty line at the beginning of the file
to have SPDX header t the first line.

Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/20231214143752.294008-1-tomas.winkler@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mei: fix spellos in mei.h

For include/uapi/linux/mei.h, correct spellos reported by codespell.

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20231213224014.23187-1-rdunlap@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nvmem: stm32: add support for STM32MP25 BSEC to control OTP data

On STM32MP25, OTP area may be read/written by using BSEC (boot, security
and OTP control). The BSEC internal peripheral is only managed by the
secure world.

The 12 Kbits of OTP (effective) are organized into the following regions:
- lower OTP (OTP0 to OTP127) = 4096 lower OTP bits,
  bitwise (1-bit) programmable
- mid OTP (OTP128 to OTP255) = 4096 middle OTP bits,
  bulk (32-bit) programmable
- upper OTP (OTP256 to OTP383) = 4096 upper OTP bits,
  bulk (32-bit) programmable,
  only accessible when BSEC is in closed state.

As HWKEY and ECIES key are only accessible by ROM code;
only 368 OTP words are managed in this driver (OTP0 to OTP267).

This patch adds the STM32MP25 configuration for reading and writing
the OTP data using the OP-TEE BSEC TA services.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20231215111536.316972-11-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

dt-bindings: nvmem: add new stm32mp25 compatible for stm32-romem

Add a new compatible for stm32mp25 support.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20231215111536.316972-10-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nvmem: core: Expose cells through sysfs

The binary content of nvmem devices is available to the user so in the
easiest cases, finding the content of a cell is rather easy as it is
just a matter of looking at a known and fixed offset. However, nvmem
layouts have been recently introduced to cope with more advanced
situations, where the offset and size of the cells is not known in
advance or is dynamic. When using layouts, more advanced parsers are
used by the kernel in order to give direct access to the content of each
cell, regardless of its position/size in the underlying
device. Unfortunately, these information are not accessible by users,
unless by fully re-implementing the parser logic in userland.

Let's expose the cells and their content through sysfs to avoid these
situations. Of course the relevant NVMEM sysfs Kconfig option must be
enabled for this support to be available.

Not all nvmem devices expose cells. Indeed, the .bin_attrs attribute
group member will be filled at runtime only when relevant and will
remain empty otherwise. In this case, as the cells attribute group will
be empty, it will not lead to any additional folder/file creation.

Exposed cells are read-only. There is, in practice, everything in the
core to support a write path, but as I don't see any need for that, I
prefer to keep the interface simple (and probably safer). The interface
is documented as being in the "testing" state which means we can later
add a write attribute if though relevant.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Rafał Miłecki <rafal@milecki.pl>
Tested-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20231215111536.316972-9-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ABI: sysfs-nvmem-cells: Expose cells through sysfs

The binary content of nvmem devices is available to the user so in the
easiest cases, finding the content of a cell is rather easy as it is
just a matter of looking at a known and fixed offset. However, nvmem
layouts have been recently introduced to cope with more advanced
situations, where the offset and size of the cells is not known in
advance or is dynamic. When using layouts, more advanced parsers are
used by the kernel in order to give direct access to the content of each
cell regardless of their position/size in the underlying device, but
these information were not accessible to the user.

By exposing the nvmem cells to the user through a dedicated cell/ folder
containing one file per cell, we provide a straightforward access to
useful user information without the need for re-writing a userland
parser. Content of nvmem cells is usually: product names, manufacturing
date, MAC addresses, etc,

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20231215111536.316972-8-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nvmem: core: Rework layouts to become regular devices

Current layout support was initially written without modules support in
mind. When the requirement for module support rose, the existing base
was improved to adopt modularization support, but kind of a design flaw
was introduced. With the existing implementation, when a storage device
registers into NVMEM, the core tries to hook a layout (if any) and
populates its cells immediately. This means, if the hardware description
expects a layout to be hooked up, but no driver was provided for that,
the storage medium will fail to probe and try later from
scratch. Even if we consider that the hardware description shall be
correct, we could still probe the storage device (especially if it
contains the rootfs).

One way to overcome this situation is to consider the layouts as
devices, and leverage the native notifier mechanism. When a new NVMEM
device is registered, we can populate its nvmem-layout child, if any,
and wait for the matching to be done in order to get the cells (the
waiting can be easily done with the NVMEM notifiers). If the layout
driver is compiled as a module, it should automatically be loaded. This
way, there is no strong order to enforce, any NVMEM device creation
or NVMEM layout driver insertion will be observed as a new event which
may lead to the creation of additional cells, without disturbing the
probes with costly (and sometimes endless) deferrals.

In order to achieve that goal we create a new bus for the nvmem-layouts
with minimal logic to match nvmem-layout devices with nvmem-layout
drivers. All this infrastructure code is created in the layouts.c file.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20231215111536.316972-7-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nvmem: Move and rename ->fixup_cell_info()

This hook is meant to be used by any provider and instantiating a layout
just for this is useless. Let's instead move this hook to the nvmem
device and add it to the config structure to be easily shared by the
providers.

While at moving this hook, rename it ->fixup_dt_cell_info() to clarify
its main intended purpose.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20231215111536.316972-6-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nvmem: Simplify the ->add_cells() hook

The layout entry is not used and will anyway be made useless by the new
layout bus infrastructure coming next, so drop it. While at it, clarify
the kdoc entry.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20231215111536.316972-5-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nvmem: Create a header for internal sharing

Before adding all the NVMEM layout bus infrastructure to the core, let's
move the main nvmem_device structure in an internal header, only
available to the core. This way all the additional code can be added in
a dedicated file in order to keep the current core file tidy.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20231215111536.316972-4-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nvmem: Move of_nvmem_layout_get_container() in another header

nvmem-consumer.h is included by consumer devices, extracting data from
NVMEM devices whereas nvmem-provider.h is included by devices providing
NVMEM content.

The only users of of_nvmem_layout_get_container() outside of the core
are layout drivers, so better move its prototype to nvmem-provider.h.

While we do so, we also move the kdoc associated with the function to
the header rather than the .c file.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20231215111536.316972-3-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

of: device: Export of_device_make_bus_id()

This helper is really handy to create unique device names based on their
device tree path, we may need it outside of the OF core (in the NVMEM
subsystem) so let's export it. As this helper has nothing patform
specific, let's move it to of/device.c instead of of/platform.c so we
can add its prototype to of_device.h.

Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20231215111536.316972-2-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PCI: epf-mhi: Fix the DMA data direction of dma_unmap_single()

In the error path of pci_epf_mhi_edma_write() function, the DMA data
direction passed (DMA_FROM_DEVICE) doesn't match the actual direction used
for the data transfer. Fix it by passing the correct one (DMA_TO_DEVICE).

Fixes: 7b99aaaddabb ("PCI: epf-mhi: Add eDMA support")
Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
Link: https://lore.kernel.org/r/20231214063328.40657-1-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: ep: Add checks for read/write callbacks while registering controllers

The MHI EP controller drivers has to support both sync and async read/write
callbacks. Hence, add a check for it.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: ep: Add support for async DMA read operation

As like the async DMA write operation, let's add support for async DMA read
operation. In the async path, the data will be read from the transfer ring
continuously and when the controller driver notifies the stack using the
completion callback (mhi_ep_read_completion), then the client driver will
be notified with the read data and the completion event will be sent to the
host for the respective ring element (if requested by the host).

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: ep: Add support for async DMA write operation

In order to optimize the data transfer, let's use the async DMA operation
for writing (queuing) data to the host.

In the async path, the completion event for the transfer ring will only be
sent to the host when the controller driver notifies the MHI stack of the
actual transfer completion using the callback (mhi_ep_skb_completion)
supplied in "struct mhi_ep_buf_info".

Also to accommodate the async operation, the transfer ring read offset
(ring->rd_offset) is cached in the "struct mhi_ep_chan" and updated locally
to let the stack queue further ring items to the controller driver. But the
actual read offset of the transfer ring will only be updated in the
completion callback.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

PCI: epf-mhi: Enable MHI async read/write support

Now that both eDMA and iATU are prepared to support async transfer, let's
enable MHI async read/write by supplying the relevant callbacks.

In the absence of eDMA, iATU will be used for both sync and async
operations.

Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

PCI: epf-mhi: Add support for DMA async read/write operation

The driver currently supports only the sync read/write operation i.e., it
waits for the DMA transfer to complete before returning to the caller
(MHI stack). But it is sub-optimal and defeats the actual purpose of using
DMA.

So let's add support for DMA async read/write operation by skipping the DMA
transfer completion and returning to the caller immediately. When the
completion actually happens later, the driver will be notified using the
DMA completion handler and in turn it will notify the caller using the
newly introduced callback in "struct mhi_ep_buf_info".

Since the DMA completion handler is invoked from the interrupt context, a
separate workqueue (epf_mhi->dma_wq) is used to notify the caller about the
completion of the transfer.

Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

PCI: epf-mhi: Simulate async read/write using iATU

Even though iATU only supports synchronous read/write, the MHI stack may
call async read/write callbacks without knowing the limitations of the
controller driver. So in order to maintain compatibility, let's simulate
async read/write operation with iATU by invoking the completion callback
after memcpy.

Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Krzysztof Wilczyński <kw@linux.com>
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: ep: Introduce async read/write callbacks

These callbacks can be implemented by the controller drivers to perform
async read/write operation that increases the throughput.

For aiding the async operation, a completion callback is also introduced.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: ep: Rename read_from_host() and write_to_host() APIs

In the preparation for adding async API support, let's rename the existing
APIs to read_sync() and write_sync() to make it explicit that these APIs
are used for synchronous read/write.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: ep: Pass mhi_ep_buf_info struct to read/write APIs

In the preparation of DMA async support, let's pass the parameters to
read_from_host() and write_to_host() APIs using mhi_ep_buf_info structure.

No functional change.

Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: ep: Add support for interrupt moderation timer

MHI spec defines the interrupt moderation timer feature using which the
host can limit the number of interrupts being raised for an event ring by
the device. This feature allows the host to process multiple event ring
elements by a single IRQ from the device, thereby eliminating the need to
process IRQ for each element.

The INTMODT field in the event context array provides the value to be used
for delaying the IRQ generation from device. This value, along with the
Block Event Interrupt (BEI) flag of the TRE defines how IRQ is generated to
the host.

Support for interrupt moderation timer is implemented using delayed
workqueue in kernel. And a separate delayed work item is used for each
event ring.

Link: https://lore.kernel.org/r/20231026045513.12981-1-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: ep: Use slab allocator where applicable

Use slab allocator for allocating the memory for objects used frequently
and are of fixed size. This reduces the overheard associated with
kmalloc().

Suggested-by: Alex Elder <elder@linaro.org>
Link: https://lore.kernel.org/r/20231018122812.47261-1-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: host: Add alignment check for event ring read pointer

Though we do check the event ring read pointer by "is_valid_ring_ptr"
to make sure it is in the buffer range, but there is another risk the
pointer may be not aligned.  Since we are expecting event ring elements
are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer
could lead to multiple issues like DoS or ring buffer memory corruption.

So add a alignment check for event ring read pointer.

Fixes: ec32332df764 ("bus: mhi: core: Sanity check values from remote device before use")
cc: stable@vger.kernel.org
Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
Reviewed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/20231031-alignment_check-v2-1-1441db7c5efd@quicinc.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: host: pci_generic: Add SDX75 based modem support

Add generic info for SDX75 based modems. SDX75 takes longer to set ready
during power up. Hence use separate configuration.

Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/1699344890-87076-3-git-send-email-quic_qianyu@quicinc.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: host: Add a separate timeout parameter for waiting ready

Some devices(eg. SDX75) take longer than expected (default, 8 seconds) to
set ready after reboot. Hence add optional ready timeout parameter and pass
the appropriate timeout value to mhi_poll_reg_field() to wait enough for
device ready as part of power up sequence.

Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lore.kernel.org/r/1699344890-87076-2-git-send-email-quic_qianyu@quicinc.com
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

bus: mhi: ep: Do not allocate event ring element on stack

It is possible that the host controller driver would use DMA framework to
write the event ring element. So avoid allocating event ring element on the
stack as DMA cannot work on vmalloc memory.

Cc: stable@vger.kernel.org
Fixes: 961aeb689224 ("bus: mhi: ep: Add support for sending events to the host")
Link: https://lore.kernel.org/r/20230901073502.69385-1-manivannan.sadhasivam@linaro.org
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

Merge tag 'coresight-next-v6.8' of git://git./linux/kernel/git/coresight/linux into char-misc-next

Suzuki writes:

coresight: Updates for Linux v6.8

Updates for the hwtracing subsystem includes :
 - Support for CoreSight TPDM DSB set
 - Support for tuning Cycle count Threshold for CoreSight ETM via perf
 - Support for TRBE on ACPI based systems
 - Support for choosing buffer mode in ETR for sysfs mode
 - Improvements to HiSilicon PTT driver
 - Cleanups to Ultrasoc SMB driver
 - Cleanup .remove callback for various Coresight platform drivers
 - Remove Leo Yan from Reviewers

Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
* tag 'coresight-next-v6.8' of git://git.kernel.org/pub/scm/linux/kernel/git/coresight/linux: (32 commits)
  coresight: ultrasoc-smb: Use guards to cleanup
  coresight: ultrasoc-smb: Convert to platform remove callback returning void
  coresight: trbe: Convert to platform remove callback returning void
  coresight: replicator: Convert to platform remove callback returning void
  coresight: funnel: Convert to platform remove callback returning void
  coresight: etm4x: Convert to platform remove callback returning void
  coresight: dummy: Convert to platform remove callback returning void
  coresight: etm4x: Fix width of CCITMIN field
  coresight-tpdm: Correct the property name of MSR number
  hwtracing: hisi_ptt: Optimize the trace data committing
  hwtracing: hisi_ptt: Disable interrupt after trace end
  Documentation: ABI: coresight-tpdm: Fix Bit[3] description indentation
  coresight-tpdm: Add nodes for dsb msr support
  dt-bindings: arm: Add support for DSB MSR register
  coresight-tpdm: Add nodes for timestamp request
  coresight-tpdm: Add nodes to configure pattern match output
  coresight-tpdm: Add nodes for dsb edge control
  coresight-tpdm: Add node to set dsb programming mode
  coresight-tpdm: Add nodes to set trigger timestamp and type
  coresight-tpdm: Add reset node to TPDM node
  ...

extcon: qcom-spmi-misc: don't use kernel-doc marker for comment

Do not use "/**" for non-kernel-doc comments. This prevents a warning
from scripts/kernel-doc:

warning: expecting prototype for extcon(). Prototype was for USB_ID_DEBOUNCE_MS() instead

Link: https://lore.kernel.org/lkml/20231205231204.1130-1-rdunlap@infradead.org/
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>

dt-bindings: iio: humidity: Add TI HDC302x support

Add device tree bindings for HDC3020/HDC3021/HDC3022 humidity and
temperature sensors.

Signed-off-by: Li peiyu <579lpy@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20231211123101.9868-1-579lpy@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: humidity: Add driver for ti HDC302x humidity sensors

Add support for HDC302x integrated capacitive based relative
humidity (RH) and temperature sensor.
This driver supports reading values, reading the maximum and
minimum of values and controlling the integrated heater of
the sensor.

Co-developed-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Signed-off-by: Li peiyu <579lpy@gmail.com>
Link: https://lore.kernel.org/r/20231211122940.9791-1-579lpy@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: ABI: document temperature and humidity peak/trough raw attributes

The in_temp_peak_raw attribute is already in use, but its documentation
is still missing. The in_humidityrelative_raw must be documented for a
new iio user that supports this attribute. Add temp and humidityrelative
use cases.
When at it, remove an extra blank space in the description.

For users that support minimum values, a new in_<type>_trough_raw
attribute is required. Add this attribute and document the first uses of
it for temp and humidityrelative types.

Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20231211122840.9760-1-579lpy@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: core: introduce trough info element for minimum values

The IIO_CHAN_INFO_PEAK info element is used for maximum values and
currently there is no equivalent for minimum values. Instead of
overloading the existing peak info element, a new info element can
be added.

In principle there is no need to add a _TROUGH_SCALE element as the
scale will be the same as the one required for INFO_PEAK, which in
turn is sometimes omitted if a single scale for peaks and raw values
is required.

Add an IIO_CHAN_INFO_TROUGH info element for minimum values.

Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20231211122747.9723-1-579lpy@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: driver for Lite-On ltr390

Implements driver for the Ambient/UV Light sensor LTR390.
The driver exposes two ways of getting sensor readings:
  1. Raw UV Counts directly from the sensor
  2. The computed UV Index value with a percision of 2 decimal places

[NOTE] Ambient light sensing has not been implemented yet.

Driver tested on RPi Zero 2W

Datasheet: https://optoelectronics.liteon.com/upload/download/DS86-2015-0004/LTR-390UV_Final_%20DS_V1%201.pdf
Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
Link: https://lore.kernel.org/r/20231208102211.413019-2-anshulusr@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: light: add ltr390

Add binding for Lite-On LTR390 which is an Ambient/UV light sensor that
communicates over i2c with an address of 0x53.

Datasheet: https://optoelectronics.liteon.com/upload/download/DS86-2015-0004/LTR-390UV_Final_%20DS_V1%201.pdf
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
Link: https://lore.kernel.org/r/20231208102211.413019-1-anshulusr@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: light: isl76682: remove unreachable code

The function isl76682_read_raw cannot execute return -EINVAL up to 145
lines, delete the invalid code.

drivers/iio/light/isl76682.c:145 isl76682_read_raw() warn: ignoring unreachable code.

Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7698
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20231208021715.32450-1-jiapeng.chong@linux.alibaba.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: pressure: driver for Honeywell HSC/SSC series

Adds driver for digital Honeywell TruStability HSC and SSC series
pressure and temperature sensors.
Communication is one way. The sensor only requires 4 bytes worth of
clock pulses on both i2c and spi in order to push the data out.
The i2c address is hardcoded and depends on the part number.
There is no additional GPIO control.
code is now based on iio/togreg

Datasheet:
https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/trustability-hsc-series/documents/sps-siot-trustability-hsc-series-high-accuracy-board-mount-pressure-sensors-50099148-a-en-ciid-151133.pdf [HSC]
Datasheet:
https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/trustability-ssc-series/documents/sps-siot-trustability-ssc-series-standard-accuracy-board-mount-pressure-sensors-50099533-a-en-ciid-151134.pdf [SSC]

Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20231207164634.11998-2-petre.rodan@subdimension.ro
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: pressure: add honeywell,hsc030

Adds binding for digital Honeywell TruStability HSC and SSC series
pressure and temperature sensors.
Communication is one way. The sensor only requires 4 bytes worth of
clock pulses on both i2c and spi in order to push the data out.
The i2c address is hardcoded and depends on the part number.
There is no additional GPIO control.
driver is based on iio/togreg

Datasheet:
https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/trustability-hsc-series/documents/sps-siot-trustability-hsc-series-high-accuracy-board-mount-pressure-sensors-50099148-a-en-ciid-151133.pdf [HSC]
Datasheet:
https://prod-edam.honeywell.com/content/dam/honeywell-edam/sps/siot/en-us/products/sensors/pressure-sensors/board-mount-pressure-sensors/trustability-ssc-series/documents/sps-siot-trustability-ssc-series-standard-accuracy-board-mount-pressure-sensors-50099533-a-en-ciid-151134.pdf [SSC]

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Petre Rodan <petre.rodan@subdimension.ro>
Link: https://lore.kernel.org/r/20231207164634.11998-1-petre.rodan@subdimension.ro
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

doc: iio: Document intensity scale as poorly defined

Add comment about intensity scale being poorly defined and
having no proper units.

Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20231207134200.329174-1-marex@denx.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

dt-bindings: iio: temperature: add MLX90635 device

Add device tree bindings for MLX90635 Infra Red contactless temperature
sensor.

Signed-off-by: Crt Mori <cmo@melexis.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/0313c3b9f7490c32891627feb5ef35d5e5d9aae9.1701872051.git.cmo@melexis.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>

iio: temperature: mlx90635 MLX90635 IR Temperature sensor

MLX90635 is an Infra Red contactless temperature sensor most suitable
for consumer applications where measured object temperature is in range
between -20 to 100 degrees Celsius. It has improved accuracy for
measurements within temperature range of human body and can operate in
ambient temperature range between -20 to 85 degrees Celsius.

Driver provides simple power management possibility as it returns to
lowest possible power mode (Step sleep mode) in which temperature
measurements can still be performed, yet for continuous measuring it
switches to Continuous power mode where measurements constantly change
without triggering.

Signed-off-by: Crt Mori<cmo@melexis.com>
Link: https://lore.kernel.org/r/c6590e4fb8d993a5317b486a3e45e1bb6e9e3318.1701872051.git.cmo@melexis.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>