Status is reported as always off in the 6032 case. Status
reporting now matches the logic in the setters. Once of
the differences to the 6030 is that there are no groups,
therefore the state needs to be read out in the lower bits.
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://lore.kernel.org/r/20221120221208.3093727-3-andreas@kemnade.infoSigned-off-by: Mark Brown <broonie@kernel.org>

In former times, info->feature was populated via the parent driver
by pdata/regulator_init_data->driver_data for all regulators when
USB_PRODUCT_ID_LSB indicates a TWL6032.
Today, the information is not set, so re-add it at the regulator
definitions.

Fixes: 25d82337 ("regulator: twl: make driver DT only")
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Link: https://lore.kernel.org/r/20221120221208.3093727-2-andreas@kemnade.infoSigned-off-by: Mark Brown <broonie@kernel.org>

Sony's downstream driver [1], among some other changes, adds a
seemingly random 10ms usleep_range, which turned out to be necessary
for the hardware to function properly on at least Sony Xperia 1 IV.
Without this, I2C transactions with the SLG51000 straight up fail.

Relax (10-10ms -> 10-11ms) and add the aforementioned sleep to make
sure the hardware has some time to wake up.

(nagara-2.0.0-mlc/vendor/semc/hardware/camera-kernel-module/)
[1] https://developer.sony.com/file/download/open-source-archive-for-64-0-m-4-29/Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20221118131035.54874-1-konrad.dybcio@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>

I got a UAF report as following:

==================================================================
BUG: KASAN: use-after-free in __lock_acquire+0x935/0x2060
Read of size 8 at addr ffff88810e838220 by task python3/268
Call Trace:
 <TASK>
 dump_stack_lvl+0x67/0x83
 print_report+0x178/0x4b0
 kasan_report+0x90/0x190
 __lock_acquire+0x935/0x2060
 lock_acquire+0x156/0x400
 _raw_spin_lock+0x2a/0x40
 lockref_get+0x11/0x30
 simple_recursive_removal+0x41/0x440
 debugfs_remove.part.12+0x32/0x50
 debugfs_remove+0x29/0x30
 _regulator_put.cold.54+0x3e/0x27f
 regulator_put+0x1f/0x30
 release_nodes+0x6a/0xa0
 devres_release_all+0xf8/0x150

Allocated by task 37:
 kasan_save_stack+0x1c/0x40
 kasan_set_track+0x21/0x30
 __kasan_slab_alloc+0x5d/0x70
 slab_post_alloc_hook+0x62/0x510
 kmem_cache_alloc_lru+0x222/0x5a0
 __d_alloc+0x31/0x440
 d_alloc+0x30/0xf0
 d_alloc_parallel+0xc4/0xd20
 __lookup_slow+0x15e/0x2f0
 lookup_one_len+0x13a/0x150
 start_creating+0xea/0x190
 debugfs_create_dir+0x1e/0x210
 create_regulator+0x254/0x4e0
 _regulator_get+0x2a1/0x467
 _devm_regulator_get+0x5a/0xb0
 regulator_virtual_probe+0xb9/0x1a0

Freed by task 30:
 kasan_save_stack+0x1c/0x40
 kasan_set_track+0x21/0x30
 kasan_save_free_info+0x2a/0x50
 __kasan_slab_free+0x102/0x190
 kmem_cache_free+0xf6/0x600
 rcu_core+0x54c/0x12b0
 __do_softirq+0xf2/0x5e3

Last potentially related work creation:
 kasan_save_stack+0x1c/0x40
 __kasan_record_aux_stack+0x98/0xb0
 call_rcu+0x42/0x700
 dentry_free+0x6c/0xd0
 __dentry_kill+0x23b/0x2d0
 dput.part.31+0x431/0x780
 simple_recursive_removal+0xa9/0x440
 debugfs_remove.part.12+0x32/0x50
 debugfs_remove+0x29/0x30
 regulator_unregister+0xe3/0x230
 release_nodes+0x6a/0xa0

==================================================================

Here is how happened:

processor A					processor B
regulator_register()
  rdev_init_debugfs()
    rdev->debugfs = debugfs_create_dir()
						devm_regulator_get()
						  rdev = regulator_dev_lookup()
						  create_regulator(rdev)
						    // using rdev->debugfs as parent
						    debugfs_create_dir(rdev->debugfs)

mfd_remove_devices_fn()
  release_nodes()
    regulator_unregister()
      // free rdev->debugfs
      debugfs_remove_recursive(rdev->debugfs)
						release_nodes()
						  destroy_regulator()
						    debugfs_remove_recursive() <- causes UAF

In devm_regulator_get(), after getting rdev, the refcount
is get, so fix this by moving debugfs_remove_recursive()
to regulator_dev_release(), then it can be proctected by
the refcount, the 'rdev->debugfs' can not be freed until
the refcount is 0.

Fixes: 5de70519 ("regulator: Add basic per consumer debugfs")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221116033706.3595812-1-yangyingliang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

I got the following OOB report:

 BUG: KASAN: slab-out-of-bounds in validate_desc+0xba/0x109
 Read of size 8 at addr ffff888107db8ff0 by task python3/253
 Call Trace:
  <TASK>
  dump_stack_lvl+0x67/0x83
  print_report+0x178/0x4b0
  kasan_report+0x90/0x190
  validate_desc+0xba/0x109
  gpiod_set_value_cansleep+0x40/0x5a
  regulator_ena_gpio_ctrl+0x93/0xfc
  _regulator_do_enable.cold.61+0x89/0x163
  set_machine_constraints+0x140a/0x159c
  regulator_register.cold.73+0x762/0x10cd
  devm_regulator_register+0x57/0xb0
  rt5759_probe+0x3a0/0x4ac [rt5759_regulator]

The desc used in validate_desc() is passed from 'reg_cfg.ena_gpiod',
which is not initialized. Fix this by initializing 'reg_cfg' to 0.

Fixes: 7b36ddb2 ("regulator: rt5759: Add support for Richtek RT5759 DCDC converter")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221116092943.1668326-1-yangyingliang@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

Here is a warning report about lack of registered release()
from kobject lib:

Device '(null)' does not have a release() function, it is broken and must be fixed.
WARNING: CPU: 0 PID: 48430 at drivers/base/core.c:2332 device_release+0x104/0x120
Call Trace:
 kobject_put+0xdc/0x180
 put_device+0x1b/0x30
 regulator_register+0x651/0x1170
 devm_regulator_register+0x4f/0xb0

When regulator_register() returns fail and directly goto `clean` symbol,
rdev->dev has not registered release() function yet (which is registered
by regulator_class in the following), so rdev needs to be freed manually.
If rdev->dev.of_node is not NULL, which means the of_node has gotten by
regulator_of_get_init_data(), it needs to call of_node_put() to avoid
refcount leak.

Otherwise, only calling put_device() would lead memory leak of rdev
in further:

unreferenced object 0xffff88810d0b1000 (size 2048):
  comm "107-i2c-rtq6752", pid 48430, jiffies 4342258431 (age 1341.780s)
  backtrace:
    kmalloc_trace+0x22/0x110
    regulator_register+0x184/0x1170
    devm_regulator_register+0x4f/0xb0

When regulator_register() returns fail and goto `wash` symbol,
rdev->dev has registered release() function, so directly call
put_device() to cleanup everything.

Fixes: d3c73156 ("regulator: plug of_node leak in regulator_register()'s error path")
Signed-off-by: Zeng Heng <zengheng4@huawei.com>
Link: https://lore.kernel.org/r/20221116074339.1024240-1-zengheng4@huawei.comSigned-off-by: Mark Brown <broonie@kernel.org>

This is same scheme as fixed-regulator.

Without that property used, the parent regulator can be shut down (if not an always on).
Thus leading to inappropriate behavior:
On am62-SP-SK this fix is required to avoid tps65219 ldo1 (SDMMC rail) to be shut down after boot completion.
Signed-off-by: Jerome Neanne <jneanne@baylibre.com>
Link: https://lore.kernel.org/r/20220929132526.29427-3-jneanne@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>

This is simillar as fixed-regulator.
Used to extract regulator parent from the device tree.

Without that property used, the parent regulator can be shut down (if not an always on).
Thus leading to inappropriate behavior:
On am62-SP-SK this fix is required to avoid tps65219 ldo1 (SDMMC rail) to be shut down after boot completion.
Signed-off-by: Jerome Neanne <jneanne@baylibre.com>
Link: https://lore.kernel.org/r/20220929132526.29427-2-jneanne@baylibre.comSigned-off-by: Mark Brown <broonie@kernel.org>

Testing .enable cannot tell if a regulator is enabled or not, check return
value of .is_enabled() instead.
Also remove unneeded ret variable.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20220919122353.384171-1-axel.lin@ingics.comSigned-off-by: Mark Brown <broonie@kernel.org>

The SDM670 uses RPMh for managing the PM660 and PM660L. Document RPMh
support for the PMIC.

Link: https://android.googlesource.com/kernel/msm/+/58064f13c0a436a82c35f2e3b5a122d874ae5846%5E%21/#F0Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220920223331.150635-2-mailingradian@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

The SDM630 and SDM660 both use RPM (not RPMh) for managing the PM660 and
PM660L. The SDM670 uses RPMh to manage them as PMIC 4s. To support the
SDM670, add the PM660 and PM660L to the RPMh regulator driver.

Link: https://android.googlesource.com/kernel/msm/+/58064f13c0a436a82c35f2e3b5a122d874ae5846%5E%21/#F0
Link: https://android.googlesource.com/kernel/msm/+/f676d3d24f9d802bfe63369167c4a8cc162b8950%5E%21/#F3Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220920223331.150635-3-mailingradian@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

drivers/regulator/ti-abb-regulator.c:161: warning: expecting prototype for ti_abb_wait_tranx(). Prototype was for ti_abb_wait_txdone() instead.

Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2206Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220919024830.111874-2-jiapeng.chong@linux.alibaba.comSigned-off-by: Mark Brown <broonie@kernel.org>

drivers/regulator/of_regulator.c:689: warning: expecting prototype for of_parse_coupled regulator(). Prototype was for of_parse_coupled_regulator() instead.

Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2205#c0Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220919024830.111874-1-jiapeng.chong@linux.alibaba.comSigned-off-by: Mark Brown <broonie@kernel.org>

Merge series from AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>:

In an effort to give some love to the apparently forgotten MT6795 SoC,
I am upstreaming more components that are necessary to support platforms
powered by this one apart from a simple boot to serial console.

This series adds support for the regulators found in MT6331 and MT6332
main/companion PMICs.

Adding support to each driver in each subsystem is done in different
patch series as to avoid spamming uninteresting patches to maintainers.

Tested on a MT6795 Sony Xperia M5 (codename "Holly") smartphone.

Add a driver for the regulators found in the MT6332 PMICs,
including six buck and four LDO regulators.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220913123456.384513-5-angelogioacchino.delregno@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add devicetree bindings for the regulators found in the MT6332 PMIC.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220913123456.384513-4-angelogioacchino.delregno@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add a driver for the regulators found in the MT6331 PMIC.
This PMIC features six buck and 21 Low DropOut (LDO) regulators.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20220913123456.384513-3-angelogioacchino.delregno@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

Add the bindings for the regulators found in the MT6331 PMIC.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220913123456.384513-2-angelogioacchino.delregno@collabora.comSigned-off-by: Mark Brown <broonie@kernel.org>

The .bypass_val_on setting does not match the .bypass_mask setting, so the
.bypass_mask bit will never get set.  Fix it by removing .bypass_val_on
setting, the regulator_set_bypass_regmap and regulator_get_bypass_regmap
helpers will use rdev->desc->bypass_mask as val_on if the val_on is 0.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Link: https://lore.kernel.org/r/20220828120153.1512508-1-axel.lin@ingics.comSigned-off-by: Mark Brown <broonie@kernel.org>

On recent kernels, the PM8058 L16 (or any other PM8058 LDO-regulator)
does not come up if they are supplied by an SMPS-regulator. This
is not very strange since the regulators are registered in a long
array and the L-regulators are registered before the S-regulators,
and if an L-regulator defers, it will never get around to registering
the S-regulator that it needs.

See arch/arm/boot/dts/qcom-apq8060-dragonboard.dts:

pm8058-regulators {
    (...)
    vdd_l13_l16-supply = <&pm8058_s4>;
    (...)

Ooops.

Fix this by moving the PM8058 S-regulators first in the array.

Do the same for the PM8901 S-regulators (though this is currently
not causing any problems with out device trees) so that the pattern
of registration order is the same on all PMnnnn chips.

Fixes: 087a1b5c ("regulator: qcom: Rework to single platform device")
Cc: stable@vger.kernel.org
Cc: Andy Gross <agross@kernel.org>
Cc: Bjorn Andersson <andersson@kernel.org>
Cc: Konrad Dybcio <konrad.dybcio@somainline.org>
Cc: linux-arm-msm@vger.kernel.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20220909112529.239143-1-linus.walleij@linaro.orgSigned-off-by: Mark Brown <broonie@kernel.org>

By using a ratio of delay to poll_enabled_time that is not integer
time_remaining underflows and does not exit the loop as expected.
As delay could be derived from DT and poll_enabled_time is defined
in the driver this can easily happen.

Use a signed iterator to make sure that the loop exits once
the remaining time is negative.
Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
Link: https://lore.kernel.org/r/20220909125954.577669-1-patrick.rudolph@9elements.comSigned-off-by: Mark Brown <broonie@kernel.org>

For RPMH regulators it doesn't make sense to indicate
regulator-allow-set-load without saying what modes you can switch to,
so be sure to indicate a dependency on regulator-allowed-modes.

In general this is true for any regulators that are setting modes
instead of setting a load directly, for example RPMH regulators. A
counter example would be RPM based regulators, which set a load
change directly instead of a mode change. In the RPM case
regulator-allow-set-load alone is sufficient to describe the regulator
(the regulator can change its output current, here's the new load),
but in the RPMH case what valid operating modes exist must also be
stated to properly describe the regulator (the new load is this, what
is the optimum mode for this regulator with that load, let's change to
that mode now).

With this in place devicetree validation can catch issues like this:

    /mnt/extrassd/git/linux-next/arch/arm64/boot/dts/qcom/sm8350-hdk.dtb: pm8350-rpmh-regulators: ldo5: 'regulator-allowed-modes' is a dependency of 'regulator-allow-set-load'
            From schema: /mnt/extrassd/git/linux-next/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml

Where the RPMH regulator hardware is described as being settable, but
there are no modes described to set it to!
Suggested-by: Johan Hovold <johan+kernel@kernel.org>
Reviewed-by: Johan Hovold <johan+kernel@kernel.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20220907204924.173030-1-ahalaney@redhat.comSigned-off-by: Mark Brown <broonie@kernel.org>

I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
fwnode property API.

While at it switch the rest of the calls to read properties in
bd957x_probe() to the generic device property API as well.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/20220903-gpiod_get_from_of_node-remove-v1-9-b29adfb27a6c@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
so that gpiolib can be cleaned a bit, so let's switch to the generic
fwnode property API.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://lore.kernel.org/r/20220903-gpiod_get_from_of_node-remove-v1-8-b29adfb27a6c@gmail.comSigned-off-by: Mark Brown <broonie@kernel.org>

Pull powerpc fixes from Michael Ellerman:

 - Fix handling of PCI domains in /proc on 32-bit systems using the
   recently added support for numbering buses from zero for each domain.

 - A fix and a revert for some changes to use READ/WRITE_ONCE() which
   caused problems with KASAN enabled due to sanitisation calls being
   introduced in low-level paths that can't cope with it.

 - Fix build errors on 32-bit caused by the syscall table being
   misaligned sometimes.

 - Two fixes to get IBM Cell native machines booting again, which had
   bit-rotted while my QS22 was temporarily out of action.

 - Fix the papr_scm driver to not assume the order of events returned by
   the hypervisor is stable, and a related compile fix.

Thanks to Aneesh Kumar K.V, Christophe Leroy, Jordan Niethe, Kajol Jain,
Masahiro Yamada, Nathan Chancellor, Pali Rohár, Vaibhav Jain, and Zhouyi
Zhou.

* tag 'powerpc-6.0-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/papr_scm: Ensure rc is always initialized in papr_scm_pmu_register()
  Revert "powerpc/irq: Don't open code irq_soft_mask helpers"
  powerpc: Fix hard_irq_disable() with sanitizer
  powerpc/rtas: Fix RTAS MSR[HV] handling for Cell
  Revert "powerpc: Remove unused FW_FEATURE_NATIVE references"
  powerpc: align syscall table for ppc32
  powerpc/pci: Enable PCI domains in /proc when PCI bus numbers are not unique
  powerpc/papr_scm: Fix nvdimm event mappings

Pull kvm fixes from Paolo Bonzini:
 "s390:

   - PCI interpretation compile fixes

  RISC-V:

   - fix unused variable warnings in vcpu_timer.c

   - move extern sbi_ext declarations to a header

  x86:

   - check validity of argument to KVM_SET_MP_STATE

   - use guest's global_ctrl to completely disable guest PEBS

   - fix a memory leak on memory allocation failure

   - mask off unsupported and unknown bits of IA32_ARCH_CAPABILITIES

   - fix build failure with Clang integrated assembler

   - fix MSR interception

   - always flush TLBs when enabling dirty logging"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86: check validity of argument to KVM_SET_MP_STATE
  perf/x86/core: Completely disable guest PEBS via guest's global_ctrl
  KVM: x86: fix memoryleak in kvm_arch_vcpu_create()
  KVM: x86: Mask off unsupported and unknown bits of IA32_ARCH_CAPABILITIES
  KVM: s390: pci: Hook to access KVM lowlevel from VFIO
  riscv: kvm: move extern sbi_ext declarations to a header
  riscv: kvm: vcpu_timer: fix unused variable warnings
  KVM: selftests: Fix ambiguous mov in KVM_ASM_SAFE()
  KVM: selftests: Fix KVM_EXCEPTION_MAGIC build with Clang
  KVM: VMX: Heed the 'msr' argument in msr_write_intercepted()
  kvm: x86: mmu: Always flush TLBs when enabling dirty logging
  kvm: x86: mmu: Drop the need_remote_flush() function

-Wformat was recently re-enabled for builds with clang, then quickly
re-disabled, due to concerns stemming from the frequency of default
argument promotion related warning instances.

commit 258fafcd ("Makefile.extrawarn: re-enable -Wformat for clang")
commit 21f9c8a1 ("Revert "Makefile.extrawarn: re-enable -Wformat for clang"")

ISO WG14 has ratified N2562 to address default argument promotion
explicitly for printf, as part of the upcoming ISO C2X standard.

The behavior of clang was changed in clang-16 to not warn for the cited
cases in all language modes.

Add a version check, so that users of clang-16 now get the full effect
of -Wformat. For older clang versions, re-enable flags under the
-Wformat group that way users still get some useful checks related to
format strings, without noisy default argument promotion warnings. I
intentionally omitted -Wformat-y2k and -Wformat-security from being
re-enabled, which are also part of -Wformat in clang-16.

Link: https://github.com/ClangBuiltLinux/linux/issues/378
Link: https://github.com/llvm/llvm-project/issues/57102
Link: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2562.pdfSuggested-by: Justin Stitt <jstitt007@gmail.com>
Suggested-by: Nathan Chancellor <nathan@kernel.org>
Suggested-by: Youngmin Nam <youngmin.nam@samsung.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull gpio fixes from Bartosz Golaszewski:
 "A a set of fixes from the GPIO subsystem.

  Most are small driver fixes except the realtek-otto driver patch which
  is pretty big but addresses a significant flaw that can cause the CPU
  to stay infinitely busy on uncleared ISR on some platforms.

  Summary:
   - MAINTAINERS update
   - fix resource leaks in gpio-mockup and gpio-pxa
   - add missing locking in gpio-pca953x
   - use 32-bit I/O in gpio-realtek-otto
   - make irq_chip structures immutable in four more drivers"

* tag 'gpio-fixes-for-v6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
  gpio: ws16c48: Make irq_chip immutable
  gpio: 104-idio-16: Make irq_chip immutable
  gpio: 104-idi-48: Make irq_chip immutable
  gpio: 104-dio-48e: Make irq_chip immutable
  gpio: realtek-otto: switch to 32-bit I/O
  gpio: pca953x: Add mutex_lock for regcache sync in PM
  gpio: mockup: remove gpio debugfs when remove device
  gpio: pxa: use devres for the clock struct
  MAINTAINERS: rectify entry for XILINX GPIO DRIVER

Kernel warns about mutable irq_chips:

    "not an immutable chip, please consider fixing!"

Make the struct irq_chip const, flag it as IRQCHIP_IMMUTABLE, add the
new helper functions, and call the appropriate gpiolib functions.
Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

Kernel warns about mutable irq_chips:

    "not an immutable chip, please consider fixing!"

Make the struct irq_chip const, flag it as IRQCHIP_IMMUTABLE, add the
new helper functions, and call the appropriate gpiolib functions.
Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

Kernel warns about mutable irq_chips:

    "not an immutable chip, please consider fixing!"

Make the struct irq_chip const, flag it as IRQCHIP_IMMUTABLE, add the
new helper functions, and call the appropriate gpiolib functions.
Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

Kernel warns about mutable irq_chips:

    "not an immutable chip, please consider fixing!"

Make the struct irq_chip const, flag it as IRQCHIP_IMMUTABLE, add the
new helper functions, and call the appropriate gpiolib functions.
Signed-off-by: William Breathitt Gray <william.gray@linaro.org>
Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl>

Pull xen fixes from Juergen Gross:

 - a minor fix for the Xen grant driver

 - a small series fixing a recently introduced problem in the Xen
   blkfront/blkback drivers with negotiation of feature usage

* tag 'for-linus-6.0-rc4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen/grants: prevent integer overflow in gnttab_dma_alloc_pages()
  xen-blkfront: Cache feature_persistent value before advertisement
  xen-blkfront: Advertise feature-persistent as user requested
  xen-blkback: Advertise feature-persistent as user requested

Merge tag 'loongarch-fixes-6.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson

Pull LoongArch fixes from Huacai Chen:
 "Fix several build errors or warnings, cleanup some code, and adjust
  arch_do_signal_or_restart() to adapt generic entry"

* tag 'loongarch-fixes-6.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson:
  LoongArch: mm: Remove the unneeded result variable
  LoongArch: Fix arch_remove_memory() undefined build error
  LoongArch: Fix section mismatch due to acpi_os_ioremap()
  LoongArch: Improve dump_tlb() output messages
  LoongArch: Adjust arch_do_signal_or_restart() to adapt generic entry
  LoongArch: Avoid orphan input sections

Pull s390 fixes from Vasily Gorbik:

 - Update defconfigs

 - Fix linker script to align nospec tables correctly to avoid
   potentially unbootable kernel with some config options

 - Fix alignment check in prepare_hugepage_range() for 2GB hugepages to
   avoid BUG in __unmap_hugepage_range() for unaligned mappings later

 - Remove useless hugepage address alignment in hugetlb fault handling

* tag 's390-6.0-3' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/hugetlb: fix prepare_hugepage_range() check for 2 GB hugepages
  s390: update defconfigs
  s390: fix nospec table alignments
  s390/mm: remove useless hugepage address alignment

Pull input fixes from Dmitry Torokhov:

 - GT1158 ID added to Goodix touchscreen driver

 - Boeder Force Feedback Wheel USB added to iforce joystick driver

 - fixup for iforce driver to avoid hangups

 - fix autoloading of rk805-pwrkey driver.

* tag 'input-for-v6.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: iforce - add support for Boeder Force Feedback Wheel
  Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag
  Input: goodix - add compatible string for GT1158
  MAINTAINERS: add include/dt-bindings/input to INPUT DRIVERS
  Input: rk805-pwrkey - fix module autoloading
  Input: goodix - add support for GT1158
  dt-bindings: input: touchscreen: add compatible string for Goodix GT1158

Pull tty/serial driver fixes from Greg KH:
 "Here are some small tty/serial/vt driver fixes for 6.0-rc4 that
  resolve a number of reported issues:

   - n_gsm fixups for previous changes that caused problems

   - much-reported serdev crash fix that showed up in 6.0-rc1

   - vt font selection bugfix

   - kerneldoc build warning fixes

   - other tiny serial core fixes

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

* tag 'tty-6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  tty: n_gsm: avoid call of sleeping functions from atomic context
  tty: n_gsm: replace kicktimer with delayed_work
  tty: n_gsm: initialize more members at gsm_alloc_mux()
  tty: n_gsm: add sanity check for gsm->receive in gsm_receive_buf()
  tty: serial: atmel: Preserve previous USART mode if RS485 disabled
  tty: serial: lpuart: disable flow control while waiting for the transmit engine to complete
  tty: Fix lookahead_buf crash with serdev
  serial: fsl_lpuart: RS485 RTS polariy is inverse
  vt: Clear selection before changing the font
  serial: document start_rx member at struct uart_ops

Pull staging driver fixes from Greg KH:
 "Here are three small staging driver fixes for 6.0-rc4 that resolve
  some reported problems and add some a device id:

   - new device id for r8188eu driver

   - use-after-free bugfixes for the rtl8712 driver

   - fix up firmware dependency problem for the r8188eu driver

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

* tag 'staging-6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging: rtl8712: fix use after free bugs
  staging: r8188eu: Add Rosewill USB-N150 Nano to device tables
  staging: r8188eu: add firmware dependency

Pull clk fixes from Stephen Boyd:
 "Here's a collection of primarily clk driver fixes, with a couple fixes
  to the core framework.

  We had to revert out a commit that affected boot on some devices that
  have the CLK_OPS_PARENT_ENABLE flag set. It isn't critical to have
  that fix so we'll try again next time.

  Driver side fixes include:

   - Plug an OF-node refcount bug in the TI clk driver

   - Fix the error handling in the raspberry pi firmware get_rate so
     that errors don't look like valid frequencies

   - Avoid going out of bounds in the raspberry pi driver too if the
     video firmware returns something we're not expecting"

* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
  Revert "clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate ops"
  clk: bcm: rpi: Show clock id limit in error case
  clk: bcm: rpi: Add missing newline
  clk: bcm: rpi: Prevent out-of-bounds access
  clk: bcm: rpi: Fix error handling of raspberrypi_fw_get_rate
  clk: core: Fix runtime PM sequence in clk_core_unprepare()
  clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate ops
  clk: ti: Fix missing of_node_get() ti_find_clock_provider()