Fix the following gcc warning:

drivers/input/serio/apbps2.c:106:16: warning: variable ‘tmp’ set but not
used [-Wunused-but-set-variable].
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/1617958859-64707-1-git-send-email-jiapeng.chong@linux.alibaba.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The Melfas MMS136 is similar to the other MMS variants but
has event packages of 6 bytes rather than 8 as the others.

The define is named FINGER_EVENT_SZ in the vendor drivers
so I renamed it from MMS*_PACKET_SZ to MMS*_EVENT_SZ.

After this patch, the touchscreen on the Samsung GT-I8530
works fine with PostmarketOS.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210404232619.3092682-1-linus.walleij@linaro.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This converts the Melfas MMS114 bindings and extend like this:

- Require nodename touchscreen@ (this seems to be the case for
  all in-tree DTS files)
- Add the mms134s and mms136 compatibles
- Add the avdd and vdd power supplies
- Define the I2C clock frequency property
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210330201233.2360006-1-linus.walleij@linaro.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Add support for ILITEK Lego series of touch devices.
Lego series includes ILITEK 213X/23XX/25XX.

Tested/passed with evaluation board with ILI2520/2322 IC.
Signed-off-by: Joe Hung <joe_hung@ilitek.com>
Link: https://lore.kernel.org/r/20210324122601.125873-2-joe_hung@ilitek.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Add binding documentation for ILITEK touch devices.
Signed-off-by: Joe Hung <joe_hung@ilitek.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210324122601.125873-1-joe_hung@ilitek.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Add support for the msg2638 touchscreen IC from MStar.
Firmware handling, wakeup gestures and other specialties are not supported.
This driver reuses zinitix.c structure, while the checksum and irq handler
functions are based on out-of-tree driver for Alcatel Idol 3 (4.7").
Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210305153815.126937-2-vincent.knecht@mailoo.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This adds dts bindings for the mstar msg2638 touchscreen.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210305153815.126937-1-vincent.knecht@mailoo.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Some buggy BIOS-es bring up the touchscreen-controller in a stuck
state where it blocks the I2C bus. Specifically this happens on
the Jumper EZpad 7 tablet model.

After much poking at this problem I have found that the following steps
are necessary to unstuck the chip / bus:

1. Turn off the Silead chip.
2. Try to do an I2C transfer with the chip, this will fail in response to
   which the I2C-bus-driver will call: i2c_recover_bus() which will unstuck
   the I2C-bus. Note the unstuck-ing of the I2C bus only works if we first
   drop the chip of the bus by turning it off.
3. Turn the chip back on.

On the x86/ACPI systems were this problem is seen, step 1. and 3. require
making ACPI calls and dealing with ACPI Power Resources. This commit adds
a workaround which runtime-suspends the chip to turn it off, leaving it up
to the ACPI subsystem to deal with all the ACPI specific details.

There is no good way to detect this bug, so the workaround gets activated
by a new "silead,stuck-controller-bug" boolean device-property. Since this
is only used on x86/ACPI, this will be set by model specific device-props
set by drivers/platform/x86/touchscreen_dmi.c. Therefor this new
device-property is not documented in the DT-bindings.

Dmesg will contain the following messages on systems where the workaround
is activated:

[   54.309029] silead_ts i2c-MSSL1680:00: [Firmware Bug]: Stuck I2C bus: please ignore the next 'controller timed out' error
[   55.373593] i2c_designware 808622C1:04: controller timed out
[   55.582186] silead_ts i2c-MSSL1680:00: Silead chip ID: 0x80360000
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210405202745.16777-1-hdegoede@redhat.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Several users have been reporting that elants_i2c gives several errors
during probe and that their touchscreen does not work on their Lenovo AMD
based laptops with a touchscreen with a ELAN0001 ACPI hardware-id:

[    0.550596] elants_i2c i2c-ELAN0001:00: i2c-ELAN0001:00 supply vcc33 not found, using dummy regulator
[    0.551836] elants_i2c i2c-ELAN0001:00: i2c-ELAN0001:00 supply vccio not found, using dummy regulator
[    0.560932] elants_i2c i2c-ELAN0001:00: elants_i2c_send failed (77 77 77 77): -121
[    0.562427] elants_i2c i2c-ELAN0001:00: software reset failed: -121
[    0.595925] elants_i2c i2c-ELAN0001:00: elants_i2c_send failed (77 77 77 77): -121
[    0.597974] elants_i2c i2c-ELAN0001:00: software reset failed: -121
[    0.621893] elants_i2c i2c-ELAN0001:00: elants_i2c_send failed (77 77 77 77): -121
[    0.622504] elants_i2c i2c-ELAN0001:00: software reset failed: -121
[    0.632650] elants_i2c i2c-ELAN0001:00: elants_i2c_send failed (4d 61 69 6e): -121
[    0.634256] elants_i2c i2c-ELAN0001:00: boot failed: -121
[    0.699212] elants_i2c i2c-ELAN0001:00: invalid 'hello' packet: 00 00 ff ff
[    1.630506] elants_i2c i2c-ELAN0001:00: Failed to read fw id: -121
[    1.645508] elants_i2c i2c-ELAN0001:00: unknown packet 00 00 ff ff

Despite these errors, the elants_i2c driver stays bound to the device
(it returns 0 from its probe method despite the errors), blocking the
i2c-hid driver from binding.

Manually unbinding the elants_i2c driver and binding the i2c-hid driver
makes the touchscreen work.

Check if the ACPI-fwnode for the touchscreen contains one of the i2c-hid
compatiblity-id strings and if it has the I2C-HID spec's DSM to get the
HID descriptor address, If it has both then make elants_i2c not bind,
so that the i2c-hid driver can bind.

This assumes that non of the (older) elan touchscreens which actually
need the elants_i2c driver falsely advertise an i2c-hid compatiblity-id
+ DSM in their ACPI-fwnodes. If some of them actually do have this
false advertising, then this change may lead to regressions.

While at it also drop the unnecessary DEVICE_NAME prefixing of the
"I2C check functionality error", dev_err already outputs the driver-name.

BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207759Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210405202756.16830-1-hdegoede@redhat.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

My brain-damaged adjustments to Paul's patch caused crashes in
gpio_keys_disable_button() when driver is used in GPIO-less (i.e.
purely interrupt-driven) setups, because I mixed together debounce and
release timers when they are in fact separate:

Unable to handle kernel NULL pointer dereference at virtual address 0000000c
...
PC is at hrtimer_active+0xc/0x98
LR is at hrtimer_try_to_cancel+0x24/0x140
...
[<c01c43b8>] (hrtimer_active) from [<c01c50f4>] (hrtimer_try_to_cancel+0x24/0x140)
[<c01c50f4>] (hrtimer_try_to_cancel) from [<c01c5224>] (hrtimer_cancel+0x14/0x4c)
[<c01c5224>] (hrtimer_cancel) from [<bf1cae24>] (gpio_keys_attr_store_helper+0x1b8/0x1d8 [gpio_keys])
[<bf1cae24>] (gpio_keys_attr_store_helper [gpio_keys]) from [<bf1cae80>] (gpio_keys_store_disabled_keys+0x18/0x24 [gpio_keys])
[<bf1cae80>] (gpio_keys_store_disabled_keys [gpio_keys]) from [<c038ec7c>] (kernfs_fop_write_iter+0x10c/0x1cc)
[<c038ec7c>] (kernfs_fop_write_iter) from [<c02df858>] (vfs_write+0x2ac/0x404)
[<c02df858>] (vfs_write) from [<c02dfaf4>] (ksys_write+0x64/0xdc)
[<c02dfaf4>] (ksys_write) from [<c0100080>] (ret_fast_syscall+0x0/0x58)

Let's fix it up.

Fixes: c9efb0ba ("Input: gpio-keys - use hrtimer for software debounce, if possible")
Reported-by: Tony Lindgren <tony@atomide.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/YG1DFFgojSVfdpaz@google.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

i.MX has been converted to a DT-only platform, so make the
adjustments to the driver to convert it to a DT-only driver.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20210327194307.541248-1-festevam@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

s/max_baseliune/max_baseline/
Signed-off-by: Nikolai Kostrigin <nickel@altlinux.org>
Link: https://lore.kernel.org/r/20210311114146.1977616-1-nickel@altlinux.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

disable_irq() after request_irq() still has a time gap in which
interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will
disable IRQ auto-enable because of requesting.

On the other hand, request_irq() after setting IRQ_NOAUTOEN as
below
irq_set_status_flags(irq, IRQ_NOAUTOEN);
request_irq(dev, irq...);
can also be replaced by request_irq() with IRQF_NO_AUTOEN flag.
Signed-off-by: Barry Song <song.bao.hua@hisilicon.com>
Link: https://lore.kernel.org/r/20210302224916.13980-3-song.bao.hua@hisilicon.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge tag 'irq-no-autoen-2021-03-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip into next

Sync up with the tip tree to pick up IRQF_NO_AUTOEN.

Sync up with the mainline to bring in newest APIs.

The first thing the Cypress driver does when starting
up is to try a soft reset. This is the first point where
the driver SPI/I2C communication can fail, so put out some
nice debug text:

  cyttsp-spi spi2.0: failed to send soft reset

Instead of just:

  cyttsp-spi: probe of spi2.0 failed with error -5

This is more helpful.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210322221349.1116666-1-linus.walleij@linaro.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This patch converts the legacy text-based binding document to YAML
format. Extraneous details and touchscreen properties that weren't
actually supported have been dropped.

The reset GPIO has since been made optional in the driver; this is
now reflected here as well.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210323021006.367-2-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The device's hardware reset pin is only required if the platform
must be able to update the device's firmware.

As such, demote the reset GPIO to optional in support of devices
that ship with pre-programmed firmware and don't route the reset
pin back to the SoC.

In that case, the 'fw_file' attribute is hidden because there is
no way to open the bootloader. The logic is extended to the case
in which the device does not advertise bootloader support in the
first place.

Last but not least, remove the hardware reset performed at probe
because there is no reason to reset the device manually. A power
on reset function already ensures a clean reset at start-up.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20210323021006.367-1-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This patch adds support for the Azoteq IQS626A capacitive touch
controller.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20210301234928.4298-5-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This patch adds device tree bindings for the Azoteq IQS626A
capacitive touch controller.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210301234928.4298-4-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Now that the helper functions have been moved to drivers/input/ so
that all input devices may use them, the introductory comments can
be updated to remove any implication that the helper functions are
solely limited to touchscreens.

This patch also scrubs any remaining use of 'DT' since there isn't
any actual dependency on OF. A minor spelling error is resolved as
well ('setups' -> 'sets up').
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20210301234928.4298-3-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Some devices outside of drivers/input/touchscreen/ can still make
use of the touchscreen helper functions. Therefore, it was agreed
in [1] to move them outside of drivers/input/touchscreen/ so that
other devices can call them without INPUT_TOUCHSCREEN being set.

As part of this change, 'of' is dropped from the filename because
the helpers no longer actually use OF. No changes are made to the
file contents whatsoever.

Based on the feedback in [2], the corresponding binding documents
(touchscreen.yaml and touchscreen.txt) are left in their original
locations.

[1] https://patchwork.kernel.org/patch/11924029/
[2] https://patchwork.kernel.org/patch/12042037/Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20210301234928.4298-2-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

This simplifies error unwinding path and allows us to get rid of
remove() method.
Reviewed-by: Alistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20210321220043.318239-2-dmitry.torokhov@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Instead of forcing interrupt trigger to "level low" rely on the
platform to set it up according to how it is wired on the given
board.
Reviewed-by: Alistair Francis <alistair@alistair23.me>
Link: https://lore.kernel.org/r/20210321220043.318239-1-dmitry.torokhov@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The bootloader can be closed using the 'execute' command (0x02) or
hardware reset. Rather than using the former option for successful
firmware update procedures and reserving the latter for recovering
the device upon failure, simply use hardware reset for all cases.

The post-bootloader initialization delay increases marginally when
triggered by a hardware reset, so increase the wait time to ensure
the device does not subsequently fail to respond.

As part of this change, refactor the return path to avoid an extra
assignment and to make the logic a bit smaller.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20210313191236.4366-6-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The vendor-assigned firmware project number is restricted to the
generic project number (15); however the vendor may assign other
project numbers to specific applications and customers.

These custom project numbers may be based on forwards-compatible
firmware revision 1.x. However, the driver unnecessarily rejects
anything older than firmware revision 2.0.

To support other applications, remove these unnecessarily strict
checks and enter the bootloader only for truly incompatible A000
devices.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20210313191236.4366-5-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Add the read-only 'fw_info' attribute which reports information
about the device's firmware in the following format:

a.b.c.d:e.f

Where:

a = Product number (e.g. 40 for IQS550)
b = Project number (e.g. 15)
c = Firmware revision (major)
d = Firmware revision (minor)
e = Customer-assigned exported file version (major)
f = Customer-assigned exported file version (minor)

As part of the corresponding rework to uses of 'bl_status', the
IQS5XX_BL_STATUS_RESET definition is dropped with 0 used in its
place instead.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20210313191236.4366-4-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Set the maximum ABS_MT_PRESSURE value and use the existing U16_MAX
definition instead of a magic number to validate ABS_MT_POSITION_X
and ABS_MT_POSITION_Y.

Also use input_set_abs_params() rather than input_abs_set_max() to
avoid having to call input_set_capability() separately.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20210313191236.4366-3-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Replace 'http' with 'https' and correct the spelling of the nearby
word 'datasheet'.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
Link: https://lore.kernel.org/r/20210313191236.4366-2-jeff@labundy.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

s/subsytem/subsystem/
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20210322022030.3857089-1-unixbhaskar@gmail.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

We want to be able to report the input event as soon as the debounce
delay elapsed. However, the current code does not really ensure that,
as it uses the jiffies-based schedule_delayed_work() API. With a small
enough HZ value (HZ <= 100), this results in some input events being
lost, when a key is quickly pressed then released (on a human's time
scale).

Switching to hrtimers fixes this issue, and will work even on extremely
low HZ values (tested at HZ=24). This is however only possible if
reading the GPIO is possible without sleeping. If this condition is not
met, the previous approach of using a jiffies-based timer is taken.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210307222240.380583-3-paul@crapouillou.netSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Dealing with input, timing is important; if the button should be
released in one millisecond, then it should be done in one millisecond
and not a hundred milliseconds.

Therefore, the standard timer API is not really suitable for this task.

Convert the gpio-keys driver to use a hrtimer instead of the standard
timer to address this issue.

Note that by using a hard IRQ for the hrtimer callback, we can get rid
of the spin_lock_irqsave() and spin_unlock_irqrestore().
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210307222240.380583-2-paul@crapouillou.netSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The input_sync() function is already called after the loop in
gpio_keys_report_state(), so it does not need to be called after each
iteration within gpio_keys_gpio_report_event().
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Link: https://lore.kernel.org/r/20210307222240.380583-1-paul@crapouillou.netSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The old device property API is about to be removed, so
explaing how to use complete software nodes instead.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://lore.kernel.org/r/20210304090948.27014-1-heikki.krogerus@linux.intel.comSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The touchscreen can be a wake up source and it's being used in DTS:

  arch/arm/boot/dts/exynos5250-spring.dt.yaml:
    trackpad@4b: 'wakeup-source' does not match any of the regexes: 'pinctrl-[0-9]+'
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210212163806.69996-1-krzk@kernel.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

The for loop is just a complicate way to express a division. Replace it
by the actual division which is both simpler to understand for a human
and more efficient for a CPU to calculate.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Link: https://lore.kernel.org/r/20210316212233.50765-1-uwe@kleine-koenig.orgSigned-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Pull ext4 fixes from Ted Ts'o:
 "Miscellaneous ext4 bug fixes for v5.12"

* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  ext4: initialize ret to suppress smatch warning
  ext4: stop inode update before return
  ext4: fix rename whiteout with fast commit
  ext4: fix timer use-after-free on failed mount
  ext4: fix potential error in ext4_do_update_inode
  ext4: do not try to set xattr into ea_inode if value is empty
  ext4: do not iput inode under running transaction in ext4_rename()
  ext4: find old entry again if failed to rename whiteout
  ext4: fix error handling in ext4_end_enable_verity()
  ext4: fix bh ref count on error paths
  fs/ext4: fix integer overflow in s_log_groups_per_flex
  ext4: add reclaim checks to xattr code
  ext4: shrink race window in ext4_should_retry_alloc()

Pull io_uring followup fixes from Jens Axboe:

 - The SIGSTOP change from Eric, so we properly ignore that for
   PF_IO_WORKER threads.

 - Disallow sending signals to PF_IO_WORKER threads in general, we're
   not interested in having them funnel back to the io_uring owning
   task.

 - Stable fix from Stefan, ensuring we properly break links for short
   send/sendmsg recv/recvmsg if MSG_WAITALL is set.

 - Catch and loop when needing to run task_work before a PF_IO_WORKER
   threads goes to sleep.

* tag 'io_uring-5.12-2021-03-21' of git://git.kernel.dk/linux-block:
  io_uring: call req_set_fail_links() on short send[msg]()/recv[msg]() with MSG_WAITALL
  io-wq: ensure task is running before processing task_work
  signal: don't allow STOP on PF_IO_WORKER threads
  signal: don't allow sending any signals to PF_IO_WORKER threads

Pull staging and IIO driver fixes from Greg KH:
 "Some small staging and IIO driver fixes:

   - MAINTAINERS changes for the move of the staging mailing list

   - comedi driver fixes to get request_irq() to work correctly

   - counter driver fixes for reported issues with iio devices

   - tiny iio driver fixes for reported issues.

  All of these have been in linux-next with no reported problems"

* tag 'staging-5.12-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging: vt665x: fix alignment constraints
  staging: comedi: cb_pcidas64: fix request_irq() warn
  staging: comedi: cb_pcidas: fix request_irq() warn
  MAINTAINERS: move the staging subsystem to lists.linux.dev
  MAINTAINERS: move some real subsystems off of the staging mailing list
  iio: gyro: mpu3050: Fix error handling in mpu3050_trigger_handler
  iio: hid-sensor-temperature: Fix issues of timestamp channel
  iio: hid-sensor-humidity: Fix alignment issue of timestamp channel
  counter: stm32-timer-cnt: fix ceiling miss-alignment with reload register
  counter: stm32-timer-cnt: fix ceiling write max value
  counter: stm32-timer-cnt: Report count function when SLAVE_MODE_DISABLED
  iio: adc: ab8500-gpadc: Fix off by 10 to 3
  iio:adc:stm32-adc: Add HAS_IOMEM dependency
  iio: adis16400: Fix an error code in adis16400_initial_setup()
  iio: adc: adi-axi-adc: add proper Kconfig dependencies
  iio: adc: ad7949: fix wrong ADC result due to incorrect bit mask
  iio: hid-sensor-prox: Fix scale not correct issue
  iio:adc:qcom-spmi-vadc: add default scale to LR_MUX2_BAT_ID channel