The regulator_lock_two() function could be made clearer in the case of
lock contention by having a local variable for each of the held and
contended locks. Let's do that. At the same time, let's use the swap()
function instead of open coding it.

This change is expected to be a no-op and simply improves code
clarity.
Suggested-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/CAE-0n53Eb1BeDPmjBycXUaQAF4ppiAM6UDWje_jiB9GAmR8MMw@mail.gmail.comSigned-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230413173359.1.I1ae92b25689bd6579952e6d458b79f5f8054a0c9@changeidSigned-off-by: Mark Brown <broonie@kernel.org>

PM8550 is different than PM8550VE/VS, because the latter has much
smaller amount of supplies (l1-3 and s1-6) and regulators.  The PM8550
has on the other hand one pin for vdd-l1-l4-l10 supplies.  Correct the
if:then: clause with their supplies.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20230327080626.24200-1-krzysztof.kozlowski@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Benjamin Bara <bbara93@gmail.com>:

Follow-up for my initial patch regarding the disabling of unused
voltage monitors. We use the PWR_OK functionality, which asserts GP_FB2
if every monitored voltage is in range. This patch should provide the
possibility to deactivate a voltage monitor from the DT if the regulator
might be disabled during run time. For this purpose, the regulator
notification support is used:
https://lore.kernel.org/all/cover.1622628333.git.matti.vaittinen@fi.rohmeurope.com/

Smatch reports:
drivers/regulator/stm32-pwr.c:166 stm32_pwr_regulator_probe() warn:
'base' from of_iomap() not released on lines: 151,166.

In stm32_pwr_regulator_probe(), base is not released
when devm_kzalloc() fails to allocate memory or
devm_regulator_register() fails to register a new regulator device,
which may cause a leak.

To fix this issue, replace of_iomap() with
devm_platform_ioremap_resource(). devm_platform_ioremap_resource()
is a specialized function for platform devices.
It allows 'base' to be automatically released whether the probe
function succeeds or fails.

Besides, use IS_ERR(base) instead of !base
as the return value of devm_platform_ioremap_resource()
can either be a pointer to the remapped memory or
an ERR_PTR() encoded error code if the operation fails.

Fixes: dc62f951 ("regulator: stm32-pwr: Fix return value check in stm32_pwr_regulator_probe()")
Signed-off-by: YAN SHI <m202071378@hust.edu.cn>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/oe-kbuild-all/202304111750.o2643eJN-lkp@intel.com/Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn>
Link: https://lore.kernel.org/r/20230412033529.18890-1-m202071378@hust.edu.cnSigned-off-by: Mark Brown <broonie@kernel.org>

Document that the da9063 only provides under- *and* over-voltage
monitoring in one, and therefore requires both to be configured with the
same severity and value. Add an example for clarification.
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com>
Link: https://lore.kernel.org/r/20230403-da9063-disable-unused-v3-3-cc4dc698864c@skidata.comSigned-off-by: Mark Brown <broonie@kernel.org>

Allow to en- and disable voltage monitoring from the device tree.
Consider that the da9063 only monitors under- *and* over-voltage
together, so both must be set to the same severity and value.
Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com>
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Link: https://lore.kernel.org/r/20230403-da9063-disable-unused-v3-2-cc4dc698864c@skidata.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add the definitions for the registers responsible for voltage
monitoring. Add a voltage monitor enable bitfield per regulator.
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Adam Ward <DLG-Adam.Ward.opensource@dm.renesas.com>
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Link: https://lore.kernel.org/r/20230403-da9063-disable-unused-v3-1-cc4dc698864c@skidata.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from Cristian Ciocaltea <cristian.ciocaltea@collabora.com>:

This patch series introduces support for the Rockchip RK860X regulators,
while also providing a few fixes and improvements to the existing fan53555
driver.

RK8600/RK8601 are quite similar to the FAN53555 regulators.

RK8602/RK8603 are a bit different, having a wider output voltage
selection range, from 0.5 V to 1.5 V in 6.25 mV steps. They are used
in the Rock 5B board to power the ARM Cortex-A76 cores and the NPU.

Extend the existing fan53555 driver to support the Rockchip RK860X
regulators.

RK8600/RK8601 are pretty similar to the FAN53555 regulators.

RK8602/RK8603 are a bit different, having a wider output voltage
selection range, from 0.5 V to 1.5 V in 6.25 mV steps. They also use
additional VSEL0/VSEL1 registers for the voltage selector, but the
enable and mode bits are still located in the original FAN53555 specific
VSEL0/VSEL1 registers.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230406194158.963352-9-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

Use dev_err_probe() instead of dev_err() in the probe function, which
ensures the error code is always printed and, additionally, simplifies
the code a bit.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230406194158.963352-8-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

In preparation for introducing support for additional regulators which
do not use the maximum number of voltage selectors available for a given
mask, improve the mask computation formula by using fls().

Note fls() requires the bitops header, hence include it explicitly and
drop bits.h which is already pulled by bitops.h.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230406194158.963352-7-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

For consistency and improved clarity, use BIT() and GENMASK() macros for
defining the bitfields inside the registers. No functional changes
intended.

While here, also fix DIE_{ID,REV} inconsistent indentation.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230406194158.963352-6-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

Commit b61ac767 ("regulator: fan53555: Convert to use
regulator_set_ramp_delay_regmap") removed the slew_shift member from
struct fan53555_device_info, hence the {CTL,TCS}_SLEW_SHIFT definitions
remained unused.  Drop them.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230406194158.963352-5-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add compatibles to support Rockchip RK860X regulators.

RK8600/RK8601 are pretty similar to the FAN53555 regulators, while
RK8602/RK8603 are a bit different, having a wider voltage selection
range.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230406194158.963352-2-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

Adding support for MP5496 S1 regulator on IPQ9574 SoC.
Co-developed-by: Praveenkumar I <quic_ipkumar@quicinc.com>
Signed-off-by: Praveenkumar I <quic_ipkumar@quicinc.com>
Signed-off-by: Devi Priya <quic_devipriy@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230407155727.20615-3-quic_devipriy@quicinc.comSigned-off-by: Mark Brown <broonie@kernel.org>

Adding s1 sub-node entry to mp5496 regulator node.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Devi Priya <quic_devipriy@quicinc.com>
Link: https://lore.kernel.org/r/20230407155727.20615-2-quic_devipriy@quicinc.comSigned-off-by: Mark Brown <broonie@kernel.org>

The support for TCS4525 regulator has been introduced with a wrong
ramp-rate mask, which has been defined as a logical expression instead
of a bit shift operation.

For clarity, fix it using GENMASK() macro.

Fixes: 914df8fa ("regulator: fan53555: Add TCS4525 DCDC support")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230406171806.948290-4-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

Since commit f2a9eb97 ("regulator: fan53555: Add support for
FAN53526") the driver makes use of the BIT() macro, but relies on the
bits header being implicitly included.

Explicitly pull the header in to avoid potential build failures in some
configurations.

While here, reorder include directives alphabetically.

Fixes: f2a9eb97 ("regulator: fan53555: Add support for FAN53526")
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://lore.kernel.org/r/20230406171806.948290-3-cristian.ciocaltea@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add the compatible for the pmm8654au RPMH regulators present on the
sa8775p-ride development board.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20230406192811.460888-2-brgl@bgdev.plSigned-off-by: Mark Brown <broonie@kernel.org>

Add the RPMH regulators exposed by the PMM8654au PMIC and its variants.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20230406192811.460888-3-brgl@bgdev.plSigned-off-by: Mark Brown <broonie@kernel.org>

An automated bot told me that there was a potential lockdep problem
with regulators. This was on the chromeos-5.15 kernel, but I see
nothing that would be different downstream compared to upstream. The
bot said:
  ============================================
  WARNING: possible recursive locking detected
  5.15.104-lockdep-17461-gc1e499ed6604 #1 Not tainted
  --------------------------------------------
  kworker/u16:4/115 is trying to acquire lock:
  ffffff8083110170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: create_regulator+0x398/0x7ec

  but task is already holding lock:
  ffffff808378e170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_trylock+0x3c/0x7b8

  other info that might help us debug this:
   Possible unsafe locking scenario:

         CPU0
         ----
    lock(regulator_ww_class_mutex);
    lock(regulator_ww_class_mutex);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  4 locks held by kworker/u16:4/115:
   #0: ffffff808006a948 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x520/0x1348
   #1: ffffffc00e0a7cc0 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x55c/0x1348
   #2: ffffff80828a2260 (&dev->mutex){....}-{3:3}, at: __device_attach_async_helper+0xd0/0x2a4
   #3: ffffff808378e170 (regulator_ww_class_mutex){+.+.}-{3:3}, at: ww_mutex_trylock+0x3c/0x7b8

  stack backtrace:
  CPU: 2 PID: 115 Comm: kworker/u16:4 Not tainted 5.15.104-lockdep-17461-gc1e499ed6604 #1 9292e52fa83c0e23762b2b3aa1bacf5787a4d5da
  Hardware name: Google Quackingstick (rev0+) (DT)
  Workqueue: events_unbound async_run_entry_fn
  Call trace:
   dump_backtrace+0x0/0x4ec
   show_stack+0x34/0x50
   dump_stack_lvl+0xdc/0x11c
   dump_stack+0x1c/0x48
   __lock_acquire+0x16d4/0x6c74
   lock_acquire+0x208/0x750
   __mutex_lock_common+0x11c/0x11f8
   ww_mutex_lock+0xc0/0x440
   create_regulator+0x398/0x7ec
   regulator_resolve_supply+0x654/0x7c4
   regulator_register_resolve_supply+0x30/0x120
   class_for_each_device+0x1b8/0x230
   regulator_register+0x17a4/0x1f40
   devm_regulator_register+0x60/0xd0
   reg_fixed_voltage_probe+0x728/0xaec
   platform_probe+0x150/0x1c8
   really_probe+0x274/0xa20
   __driver_probe_device+0x1dc/0x3f4
   driver_probe_device+0x78/0x1c0
   __device_attach_driver+0x1ac/0x2c8
   bus_for_each_drv+0x11c/0x190
   __device_attach_async_helper+0x1e4/0x2a4
   async_run_entry_fn+0xa0/0x3ac
   process_one_work+0x638/0x1348
   worker_thread+0x4a8/0x9c4
   kthread+0x2e4/0x3a0
   ret_from_fork+0x10/0x20

The problem was first reported soon after we made many of the
regulators probe asynchronously, though nothing I've seen implies that
the problems couldn't have also happened even without that.

I haven't personally been able to reproduce the lockdep issue, but the
issue does look somewhat legitimate. Specifically, it looks like in
regulator_resolve_supply() we are holding a "rdev" lock while calling
set_supply() -> create_regulator() which grabs the lock of a
_different_ "rdev" (the one for our supply). This is not necessarily
safe from a lockdep perspective since there is no documented ordering
between these two locks.

In reality, we should always be locking a regulator before the
supplying regulator, so I don't expect there to be any real deadlocks
in practice. However, the regulator framework in general doesn't
express this to lockdep.

Let's fix the issue by simply grabbing the two locks involved in the
same way we grab multiple locks elsewhere in the regulator framework:
using the "wound/wait" mechanisms.

Fixes: eaa7995c ("regulator: core: avoid regulator_resolve_supply() race condition")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230329143317.RFC.v2.2.I30d8e1ca10cfbe5403884cdd192253a2e063eb9e@changeidSigned-off-by: Mark Brown <broonie@kernel.org>

When a codepath locks a rdev using ww_mutex_lock_slow() directly then
that codepath is responsible for incrementing the "ref_cnt" and also
setting the "mutex_owner" to "current".

The regulator core consistently got that right for "ref_cnt" but
didn't always get it right for "mutex_owner". Let's fix this.

It's unlikely that this truly matters because the "mutex_owner" is
only needed if we're going to do subsequent locking of the same
rdev. However, even though it's not truly needed it seems less
surprising if we consistently set "mutex_owner" properly.

Fixes: f8702f9e ("regulator: core: Use ww_mutex for regulators locking")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20230329143317.RFC.v2.1.I4e9d433ea26360c06dd1381d091c82bb1a4ce843@changeidSigned-off-by: Mark Brown <broonie@kernel.org>

Commit 71ca776a ("regulator: qcom-rpmh: Add pmc8180 and pmc8180c")
introduced these compatible's but the yaml conversion commit
7255f98d ("regulator: Convert RPMh regulator bindings to YAML")
seems to have dropped it

So bring it back!
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230325122444.249507-9-vkoul@kernel.orgSigned-off-by: Mark Brown <broonie@kernel.org>

Pull btrfs fixes from David Sterba:

 - scan block devices in non-exclusive mode to avoid temporary mkfs
   failures

 - fix race between quota disable and quota assign ioctls

 - fix deadlock when aborting transaction during relocation with scrub

 - ignore fiemap path cache when there are multiple paths for a node

* tag 'for-6.3-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
  btrfs: ignore fiemap path cache when there are multiple paths for a node
  btrfs: fix deadlock when aborting transaction during relocation with scrub
  btrfs: scan device in non-exclusive mode
  btrfs: fix race between quota disable and quota assign ioctls

This reverts commit a837e516, which broke probing of the venus
driver, at least on the SC7180 SoC HP X2 Chromebook:

  qcom-venus aa00000.video-codec: Adding to iommu group 11
  qcom-venus aa00000.video-codec: non legacy binding
  qcom-venus aa00000.video-codec: failed to reset venus core
  qcom-venus: probe of aa00000.video-codec failed with error -110

Matthias Kaehlcke also reported that the same change caused a regression
in SC7180 and sc7280, that prevents AOSS from entering sleep mode during
system suspend.  So let's revert this commit for now to fix both issues.

Fixes: a837e516 ("venus: firmware: Correct non-pix start and end addresses")
Reported-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull driver core fixes from Greg KH:
 "Here are three small changes for 6.3-rc5 semi-related to driver core
  stuff:

   - documentation update where we move the security_bugs file to a more
     relevant location.

   - mdt/spi-nor debugfs memory leak fix that's been floating around for
     a long time and acked by the maintainer

   - cacheinfo bugfix for a regression in 6.3-rc1

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

* tag 'driver-core-6.3-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
  cacheinfo: Fix LLC is not exported through sysfs
  Documentation/security-bugs: move from admin-guide/ to process/
  mtd: spi-nor: fix memory leak when using debugfs_lookup()

Pull powerpc fixes from Michael Ellerman:

 - Fix a false positive warning in __pte_needs_flush() (with DEBUG_VM=y)

 - Fix oops when a PF_IO_WORKER thread tries to core dump

 - Don't try to reconfigure VAS when it's disabled

Thanks to Benjamin Gray, Haren Myneni, Jens Axboe, Nathan Lynch, and
Russell Currey.

* tag 'powerpc-6.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/pseries/vas: Ignore VAS update for DLPAR if copy/paste is not enabled
  powerpc: Don't try to copy PPR for task with NULL pt_regs
  powerpc/64s: Fix __pte_needs_flush() false positive warning

Pull cifs client fixes from Steve French:
 "Four cifs/smb3 client (reconnect and DFS related) fixes, including two
  for stable:

   - DFS oops fix

   - DFS reconnect recursion fix

   - An SMB1 parallel reconnect fix

   - Trivial dead code removal in smb2_reconnect"

* tag '6.3-rc4-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6:
  cifs: get rid of dead check in smb2_reconnect()
  cifs: prevent infinite recursion in CIFSGetDFSRefer()
  cifs: avoid races in parallel reconnects in smb1
  cifs: fix DFS traversal oops without CONFIG_CIFS_DFS_UPCALL

Pull input fixes from Dmitry Torokhov:

 - fixes to ALPS and Focaltech PS/2 drivers dealing with the breakage of
   switching to -funsigned-char

 - quirks to i8042 to better handle Lifebook A574/H and TUXEDO devices

 - a quirk to Goodix touchscreen driver to handle Yoga Book X90F

 - a fix for incorrectly merged patch to xpad game controller driver

* tag 'input-for-v6.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: i8042 - add TUXEDO devices to i8042 quirk tables for partial fix
  Input: alps - fix compatibility with -funsigned-char
  Input: focaltech - use explicitly signed char type
  Input: xpad - fix incorrectly applied patch for MAP_PROFILE_BUTTON
  Input: goodix - add Lenovo Yoga Book X90F to nine_bytes_report DMI table
  Input: i8042 - add quirk for Fujitsu Lifebook A574/H

Pull pin control fixes from Linus Walleij:
 "Some pin control fixes for the v6.3 series.

  The most notable and urgent one is probably the AMD fix which affects
  AMD laptops, found by the Chromium people.

  Summary:

   - Fix up the Kconfig options for MediaTek MT7981

   - Fix the irq domain name in the AT91-PIO4 driver

   - Fix some alternative muxing modes in the Ocelot driver

   - Allocate the GPIO numbers dynamically in the STM32 driver

   - Disable and mask interrupts on resume in the AMD driver

   - Fix a typo in the Qualcomm SM8550 pin control device tree bindings"

* tag 'pinctrl-v6.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
  dt-bindings: pinctrl: qcom,sm8550-lpass-lpi: allow input-enabled and bias-bus-hold
  pinctrl: amd: Disable and mask interrupts on resume
  pinctrl: stm32: use dynamic allocation of GPIO base
  pinctrl: ocelot: Fix alt mode for ocelot
  pinctrl: at91-pio4: fix domain name assignment
  pinctrl: mediatek: fix naming inconsistency
  pinctrl: mediatek: add missing options to PINCTRL_MT7981

Merge tag 'kbuild-fixes-v6.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

Pull Kbuild fixes from Masahiro Yamada:

 - Fix linux-headers debian package

 - Fix a merge_config.sh error due to a misspelled variable

 - Fix modversion for 32-bit build machines

* tag 'kbuild-fixes-v6.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
  modpost: Fix processing of CRCs on 32-bit build machines
  scripts: merge_config: Fix typo in variable name.
  kbuild: deb-pkg: set version for linux-headers paths

Pull iommu fixes from Joerg Roedel:

 - Maintainer update for S390 IOMMU driver

 - A fix for the set_platform_dma_ops() call-back in the Exynos
   IOMMU driver

 - Intel VT-d fixes from Lu Baolu:
    - Fix a lockdep splat
    - Fix a supplement of the specification
    - Fix a warning in perfmon code

* tag 'iommu-fixes-6.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu:
  iommu/vt-d: Fix an IOMMU perfmon warning when CPU hotplug
  iommu/vt-d: Allow zero SAGAW if second-stage not supported
  iommu/vt-d: Remove unnecessary locking in intel_irq_remapping_alloc()
  iommu/exynos: Fix set_platform_dma_ops() callback
  MAINTAINERS: Update s390-iommu driver maintainer information

The runtime suspend/resume functions are only referenced from the
dev_pm_ops, but they use the old SET_RUNTIME_PM_OPS() helper that
requires a __maybe_unused annotation to avoid a warning:

  drivers/media/i2c/imx290.c:1082:12: error: unused function 'imx290_runtime_resume' [-Werror,-Wunused-function]
  static int imx290_runtime_resume(struct device *dev)
             ^
  drivers/media/i2c/imx290.c:1090:12: error: unused function 'imx290_runtime_suspend' [-Werror,-Wunused-function]
  static int imx290_runtime_suspend(struct device *dev)
             ^

Convert this to the new RUNTIME_PM_OPS() helper that so this is not
required.  To improve this further, also use the pm_ptr() helper that
lets the dev_pm_ops get dropped entirely when CONFIG_PM is disabled.

A related mistake happened in the of_match_ptr() macro here, which like
SET_RUNTIME_PM_OPS() requires the match table to be marked as
__maybe_unused, though I could not reproduce building this without
CONFIG_OF.  Remove the of_match_ptr() here as there is no point in
dropping the match table in configurations without CONFIG_OF.

Fixes: 02852c01 ("media: i2c: imx290: Initialize runtime PM before subdev")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Guenter Roeck <linux@roeck-us.net>
Reported-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull NFS client fixes from Anna Schumaker:

 - Fix shutdown of NFS TCP client sockets

 - Fix hangs when recovering open state after a server reboot

* tag 'nfs-for-6.3-3' of git://git.linux-nfs.org/projects/anna/linux-nfs:
  SUNRPC: fix shutdown of NFS TCP client socket
  NFSv4: Fix hangs when recovering open state after a server reboot

Merge tag 'platform-drivers-x86-v6.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

Pull x86 platform driver fixes from Hans de Goede:

 - Fix a regression in ideapad-laptop which caused the touchpad to stop
   working after a suspend/resume on some models

 - One other small fix and three hw-id additions

* tag 'platform-drivers-x86-v6.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
  platform/x86: ideapad-laptop: Stop sending KEY_TOUCHPAD_TOGGLE
  platform/x86: asus-nb-wmi: Add quirk_asus_tablet_mode to other ROG Flow X13 models
  platform/x86: gigabyte-wmi: add support for X570S AORUS ELITE
  platform/x86: gigabyte-wmi: add support for B650 AORUS ELITE AX
  platform/x86/intel/pmc: Alder Lake PCH slp_s0_residency fix

Pull PCI fix from Bjorn Helgaas:

 - Fix DesignWare PORT_LINK_CONTROL setup, which was corrupted when the
   DT "snps,enable-cdm-check" property was present (Yoshihiro Shimoda)

* tag 'pci-v6.3-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci:
  PCI: dwc: Fix PORT_LINK_CONTROL update when CDM check enabled

Merge tag 'regulator-fix-v6.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator

Pull regulator fix from Mark Brown:
 "Deferred probe fix for v6.3.

  This fixes a rarely triggered issue where we would treat probe
  deferral for clocks as a fatal error in the fixed regulator, causing
  it to fail to retry when it should"

* tag 'regulator-fix-v6.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: Handle deferred clk

Pull block fixes from Jens Axboe:

 - NVMe pull request via Christoph:
     - Mark Lexar NM760 as IGNORE_DEV_SUBNQN (Juraj Pecigos)
     - Fix a possible UAF when failing to allocate an TCP io queue (Sagi
       Grimberg)

 - MD pull request via Song:
     - Fix a null pointer deference in 6.3-rc (Yu Kuai)

 - uevent partition fix (Alyssa)

* tag 'block-6.3-2023-03-30' of git://git.kernel.dk/linux:
  nvme-tcp: fix a possible UAF when failing to allocate an io queue
  md: fix regression for null-ptr-deference in __md_stop()
  nvme-pci: mark Lexar NM760 as IGNORE_DEV_SUBNQN
  loop: LOOP_CONFIGURE: send uevents for partitions

Pull io_uring fixes from Jens Axboe:

 - Fix a regression with the poll retry, introduced in this merge window
   (me)

 - Fix a regression with the alloc cache not decrementing the member
   count on removal. Also a regression from this merge window (Pavel)

 - Fix race around rsrc node grabbing (Pavel)

* tag 'io_uring-6.3-2023-03-30' of git://git.kernel.dk/linux:
  io_uring: fix poll/netmsg alloc caches
  io_uring/rsrc: fix rogue rsrc node grabbing
  io_uring/poll: clear single/double poll flags on poll arming