After str_has_pfx() refactoring each TEST_TAG_* / TEST_BTF_PATH
constant is used exactly once. Since constant definitions are not
shared between BPF-side bpf_misc.h and userspace side test_loader.c,
there is no need in the additional redirection layer.
Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Reviewed-by: Puranjay Mohan <puranjay@kernel.org>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260410-selftests-global-tags-ordering-v2-4-c566ec9781bf@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Impose global ordering for all decl tags used by test_loader.c based
tests (__success, __failure, __msg, etc):
- change every tag to expand as
__attribute__((btf_decl_tag("comment:" XSTR(__COUNTER__) ...)))
- change parse_test_spec() to collect all decl tags before
processing and sort them using strverscmp().
The ordering is necessary for gcc-bpf.
Neither GCC nor the C standard defines the order in which function
attributes are consumed. While Clang tends to preserve definition order,
GCC may process them out of sequence. This inconsistency causes BPF
tests with multiple __msg entries to fail when compiled with GCC.
Signed-off-by: Cupertino Miranda <cupertino.miranda@oracle.com>
Reviewed-by: Puranjay Mohan <puranjay@kernel.org>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260410-selftests-global-tags-ordering-v2-3-c566ec9781bf@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Change str_has_pfx() to return a pointer to the first character after
the prefix, thus eliminating the repetitive (s + sizeof(PFX) - 1)
patterns.
Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Acked-by: Mykyta Yatsenko <yatsenko@meta.com>
Reviewed-by: Puranjay Mohan <puranjay@kernel.org>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260410-selftests-global-tags-ordering-v2-2-c566ec9781bf@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
__jited_unpriv was using "test_jited=" as its tag name, same as the
priv variant __jited. Fix by using "test_jited_unpriv=".
Fixes: 7d743e4c75 ("selftests/bpf: __jited test tag to check disassembly after jit")
Acked-by: Ihor Solodrai <ihor.solodrai@linux.dev>
Reviewed-by: Puranjay Mohan <puranjay@kernel.org>
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260410-selftests-global-tags-ordering-v2-1-c566ec9781bf@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
It's possible that at the time of resolving a reference to a remote
software node, the node we know exists is not yet registered as a full
firmware node. We currently return -ENOENT in this case but the same
error code is also returned in some other cases, like the reference
property with given name not existing in the property list of the local
software node.
It makes sense to let users know that we're dealing with an unregistered
software node so that they can defer probe - the situation is somewhat
similar to there existing a firmware node to which no device is bound
yet - which is valid grounds for probe deferral. To that end: use
-ENOTCONN to indicate the software node is "not connected".
Acked-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260407-swnode-unreg-retcode-v4-1-1b2f0725eb9c@oss.qualcomm.com
[ Drop software node backend specifics from
fwnode_property_get_reference_args() documentation. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
I stumbled upon "isolcpus=managed_irq" which is the last piece which
can only be handled by isolcpus= and has no runtime knob. I knew roughly
what managed interrupts should do but I lacked some details how it is
used and what the managed_irq sub parameter means in practise.
This documents what we have as of today and how it works. I added some
examples how the parameter affects the configuration. Did I miss
something?
Given that the spreading as computed group_cpus_evenly() does not take
the mask of isolated CPUs into account I'm not sure how relevant the
managed_irq argument is. The virtio_scsi driver has no way to limit the
interrupts and I don't see this for the nvme. Even if the number of
queues can be reduced to two (as in the example) it is still spread
evenly in the system instead and the isolated CPUs are not taken into
account.
To make this worse, you can even argue further whether or not the
application on the isolated CPU wants to receive the interrupt directly
or would prefer not to.
Given all this, I am not sure if it makes sense to add 'io_queue' to the
mix or if it could be incorporated into 'managed_irq'.
One more point: Given that isolcpus= is marked deprecated as of commit
b0d40d2b22 ("sched/isolation: Document isolcpus= boot parameter flags, mark it deprecated")
and the 'managed_irq' is evaluated at device's probe time it would
require additional callbacks to re-evaluate the situation. Probably for
'io_queue', too. Does is make sense or should we simply drop the
"deprecation" notice and allowing using it long term?
Dynamic partitions work with cpusets, there this (managed_irq)
limitation but is it really? And if static partition is the use case why
bother.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Ming Lei <tom.leiming@gmail.com>
Reviewed-by: Aaron Tomlin <atomlin@atomlin.com>
Acked-by: Thomas Gleixner <tglx@kernel.org>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260401110232.ET5RxZfl@linutronix.de>
iopt_unmap_iova_range() releases the lock on iova_rwsem inside the loop
body when getting to the more expensive unmap operations. This is fine on
its own, except the loop condition is based on the first area that matches
the unmap address range. If a concurrent call to map picks an area that
was unmapped in previous iterations, the loop mistakenly tries to unmap
it.
This is reproducible by having one userspace thread map buffers and pass
them to another thread that unmaps them. The problem manifests as EBUSY
errors with single page mappings.
Fix this by advancing the start pointer after unmapping an area. This
ensures each iteration only examines the IOVA range that remains mapped,
which is guaranteed not to have overlaps.
Cc: stable@vger.kernel.org
Fixes: 51fe6141f0 ("iommufd: Data structure to provide IOVA to PFN mapping")
Link: https://patch.msgid.link/r/CAAJpGJSR4r_ds1JOjmkqHtsBPyxu8GntoeW08Sk5RNQPmgi+tg@mail.gmail.com
Signed-off-by: Sina Hassani <sina@openai.com>
Reviewed-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
The moment we link a "struct device" into the list of devices for the
bus, it's possible probe can happen. This is because another thread
can load the driver at any time and that can cause the device to
probe. This has been seen in practice with a stack crawl that looks
like this [1]:
really_probe()
__driver_probe_device()
driver_probe_device()
__driver_attach()
bus_for_each_dev()
driver_attach()
bus_add_driver()
driver_register()
__platform_driver_register()
init_module() [some module]
do_one_initcall()
do_init_module()
load_module()
__arm64_sys_finit_module()
invoke_syscall()
As a result of the above, it was seen that device_links_driver_bound()
could be called for the device before "dev->fwnode->dev" was
assigned. This prevented __fw_devlink_pickup_dangling_consumers() from
being called which meant that other devices waiting on our driver's
sub-nodes were stuck deferring forever.
It's believed that this problem is showing up suddenly for two
reasons:
1. Android has recently (last ~1 year) implemented an optimization to
the order it loads modules [2]. When devices opt-in to this faster
loading, modules are loaded one-after-the-other very quickly. This
is unlike how other distributions do it. The reproduction of this
problem has only been seen on devices that opt-in to Android's
"parallel module loading".
2. Android devices typically opt-in to fw_devlink, and the most
noticeable issue is the NULL "dev->fwnode->dev" in
device_links_driver_bound(). fw_devlink is somewhat new code and
also not in use by all Linux devices.
Even though the specific symptom where "dev->fwnode->dev" wasn't
assigned could be fixed by moving that assignment higher in
device_add(), other parts of device_add() (like the call to
device_pm_add()) are also important to run before probe. Only moving
the "dev->fwnode->dev" assignment would likely fix the current
symptoms but lead to difficult-to-debug problems in the future.
Fix the problem by preventing probe until device_add() has run far
enough that the device is ready to probe. If somehow we end up trying
to probe before we're allowed, __driver_probe_device() will return
-EPROBE_DEFER which will make certain the device is noticed.
In the race condition that was seen with Android's faster module
loading, we will temporarily add the device to the deferred list and
then take it off immediately when device_add() probes the device.
Instead of adding another flag to the bitfields already in "struct
device", instead add a new "flags" field and use that. This allows us
to freely change the bit from different thread without worrying about
corrupting nearby bits (and means threads changing other bit won't
corrupt us).
[1] Captured on a machine running a downstream 6.6 kernel
[2] https://cs.android.com/android/platform/superproject/main/+/main:system/core/libmodprobe/libmodprobe.cpp?q=LoadModulesParallel
Cc: stable@vger.kernel.org
Fixes: 2023c610dc ("Driver core: add new device to bus's list before probing")
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patch.msgid.link/20260406162231.v5.1.Id750b0fbcc94f23ed04b7aecabcead688d0d8c17@changeid
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Fix one more gmap-rewrite issue: races with partial gmap invalidations.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEoWuZBM6M3lCBSfTnuARItAMU6BMFAmnVLyYACgkQuARItAMU
6BOlFBAAycmLpPZlezQfBZ7BUFLYVlZjxE1aeT+s09U9i6OtKblGfEaMtM8ivbtq
gcQALX8KbNJM1tkQRJGyE15+AhofCXcjbEiWxCJ3PzktoMhSU1If10EbpRenPxlB
gqylMolWJ3wHuq3swlmHNCSFBKGci/jDJfed01QxSda7ngQ2uEqS7iF9ud/zyZgt
IcTlsmIR0jT5vcq1eyaHw5NQ8bvMgJrzp85SwY7uTZIV2NDyUKIdsW6aYvI9jGCH
Y39OgK/Nz7oKJgguMKiJetXYWhPPg/3sqRhKSseD9URypxaAvWOmPOrwxa2QtrCS
sv1p2kGTKikep9wxTnvdXwxQOFDVQFyMcT77DDwGl7kWkKHRSZtbGskdesmdvni/
QEW5IqgO/f7jfTbuPmmgNf93QzTWiGSBLsjOjSY3IcqGrhwe6/JAdu21Ge+Oi+kA
0FWE1Q97tHZRuSGHIiWlFgziCAl0EKzaRenPaLX7j3s7TuaGoOGE7WEC8zPldnpi
MUNfts8MIxOr+CEz5wM6duIym+YC2ZKJn87TOo5tJ3xM7JbPhflNTossnkYSkVuS
WZNhArK+NrlP6NF1dTy7RBePOHHLH7RCxoYSoZ/dMYwr9sMcxAp0ULnMwQxVwx23
1OXqGQwS/rkhy/Gw77MhNdyUa8hxsK4nOWDebhJVxTjEVLbd9vE=
=UmKD
-----END PGP SIGNATURE-----
Merge tag 'kvm-s390-master-7.0-4' of https://git.kernel.org/pub/scm/linux/kernel/git/kvms390/linux into HEAD
KVM: s390: One very last second fix
Fix one more gmap-rewrite issue: races with partial gmap invalidations.
Declare flexible arrays in uAPI structures using __DECLARE_FLEX_ARRAY() so
that KVM's uAPI headers can be included in C++ projects.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEKTobbabEP7vbhhN9OlYIJqCjN/0FAmnZHqsACgkQOlYIJqCj
N/331BAApsvBOvcKxeHM598wAsZTtBIUiMWrm/hybB2zhXxbcC9BDPN5NrYP9eJX
khlLm9YRDI2Hvk8QNuwPXV/mHU5U0HNJ48BUToL6H5x6792dnRCbL046rYCyRZbi
bUjMcUjTWtv7g+UEoYOsMpmYQlTlf4krCbw2ixn6/4c2Ab76TRmrISU+tknoal+b
KGXEJWhsEiueUD8xpjR84P0h3d6x+EHc2oyDk/k+aFZAcbjWFz/8aLjOSVc00V36
DqYKbMGO/22CNkWSLk9Dr6mitn6HmG151HNAvUvHlPMFQLrP9jpk13u1IHZsR7H4
4yykj4tm5+02775IFqfPLNZ4Ipk70WO50ndl3plh7G7187ckYsfl+oQu2c4oIveB
sPfnEHqteGKw+GLOM9Xu4MVCAvy7FFGlgGIkZpULA7cLNyIayfmKuZTF7/UEh9Wy
fL2UAypzJjCIgLFyoio4CHqLJ4vuUneyHyoJczS/Wd9kuL0kHrLEw771gLGjwslB
Nk0900qPlxEWx47G6MadzSh+JexjT9KrSCgaACNWKJpzQMkcw6gwDSIGq9F/f0Ac
Zl7XFbQ2KKm/Z8CWCTg5XdxI6zz0NCzlcYoepk7CfHgs0xZjWqu5AReLcQnffx2/
c5YKoOffkicokffWQju64kjE/VYpdAITHONa1r7hv73/bfYfUGg=
=VJsI
-----END PGP SIGNATURE-----
Merge tag 'kvm-x86-fixes-7.1' of https://github.com/kvm-x86/linux into HEAD
KVM x86 fixes for 7.1
Declare flexible arrays in uAPI structures using __DECLARE_FLEX_ARRAY() so
that KVM's uAPI headers can be included in C++ projects.
Instead of repeating the command opcode twice, some flash devices try to
pack command and address bits. In this case, the second opcode byte
being sent (LSB) is free to be used. The input data must be ANDed to
only provide the relevant bits.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260410-winbond-6-19-rc1-oddr-v1-2-2ac4827a3868@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
I got mislead while analyzing the driver by the fact that the second
opcode byte was in all cases smashed:
if (op->cmd.dtr)
opcode = op->cmd.opcode >> 8;
else
opcode = op->cmd.opcode;
While at a first glance this doesn't let a chance to the second byte to
be shifted out on the bus, this is actually the second step of an
initialization, where the byte being apparently "ignored" in DTR mode
has already been written in a dedicated "extended opcode" register. As
such, the comment and the extra check that I proposed were entirely
wrong, remove them.
Fixes: bee085476d ("spi: cadence-qspi: Make sure we filter out unsupported ops")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://patch.msgid.link/20260410-winbond-6-19-rc1-oddr-v1-1-2ac4827a3868@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
JHB100 contains 2 dwc3 USB controllers and PHYs and working
as USB 2.0 speed. It can working in generic platform and
setting default properties.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Link: https://patch.msgid.link/20260410112500.90432-3-minda.chen@starfivetech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for the USB 2.0 Dual-Role Device (DRD) controller embedded
in the StarFive JHB100 SoC. The controller is based on the Synopsys
DesignWare Core USB 3 (DWC3) IP.
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260410112500.90432-2-minda.chen@starfivetech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Convert Atmel High-Speed USB Device Controller (USBA) binding to DT schema.
Changes during conversion:
- Make the "clock-names" property flexible enough to accept the items
in any order as the existing in tree DTS nodes doesn't follow an order.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260327-atmel-usb-v4-5-eb8b6e49b29d@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Convert Atmel AT91 USB Device Controller (UDC) binding to DT schema.
Changes during conversion:
- Include "atmel,pullup-gpio" and "atmel,matrix" in the properties since
they are required by existing in-tree DTS definitions.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
Link: https://patch.msgid.link/20260327-atmel-usb-v4-4-eb8b6e49b29d@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Convert the Atmel AT91RM9200 OHCI USB host controller binding to DT schema
by defining it in the existing generic OHCI schema.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260327-atmel-usb-v4-2-eb8b6e49b29d@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The UDC node does not define any child nodes, so the "#address-cells" and
"#size-cells" properties are unnecessary. Remove these unused properties
to simplify the devicetree node and keep it consistent with DT conventions.
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
Link: https://patch.msgid.link/20260327-atmel-usb-v4-1-eb8b6e49b29d@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When refresh_exported_devices() finds no devices, it's helpful to
inform users about potential causes. This could be due to:
1. The usbip driver module is not loaded.
2. No devices have been exported yet.
Add an informational message to guide users when ndevs == 0.
Also update the condition in usbip_host_driver_open() and
usbip_device_driver_open() to check both ret and ndevs == 0,
and change err() to info().
Message visibility by scenario:
- usbipd (console mode): Show on console/serial, this allows instant
visibility for debugging.
- usbipd -D (daemon mode): Message logged to syslog, can keep logs for
later traceability in production. Also can use "journalctl -f" to
trace on console.
Suggested-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Zongmin Zhou <zhouzongmin@kylinos.cn>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://patch.msgid.link/20260402083204.53179-1-min_halo@163.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Here are the USB serial updates for 7.1-rc1, including:
- use strscpy() instead of strcpy()
- new modem device id
All have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iJEEABYKADkWIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCadjwMhsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDIACgkQC8XNwux9ZQiNXgD8CqMYNAGAgHCenEXaZlEi
HfQtWJg5E95bW6wgRwzasj0BAOCvTt1K8Bl/fIqrlW/gdza+wIym1NanrEZs/wQu
M1EG
=hJqD
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-7.1-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next
Johan writes:
USB serial updates for 7.1-rc1
Here are the USB serial updates for 7.1-rc1, including:
- use strscpy() instead of strcpy()
- new modem device id
All have been in linux-next with no reported issues.
* tag 'usb-serial-7.1-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: iuu_phoenix: fix iuutool author name
USB: serial: option: add Telit Cinterion FN990A MBIM composition
USB: serial: ti_usb_3410_5052: use strscpy() instead of strcpy()
Drop unnecessary MAINTAINERS entry for non-existent Marvell db-falcon files
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQYqXDMF3cvSLY+g9cLBhiOFHI71QUCaddpEQAKCRALBhiOFHI7
1c6HAJ40Z8BBJ0o7PquKjJnwMEuIn+sF+gCfeMYMb5mMDpfHnW4ijx7T2cLJMDI=
=6OA8
-----END PGP SIGNATURE-----
Merge tag 'mvebu-dt-7.1-1' of https://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into soc/dt
mvebu dt for 7.1 (part 1)
Drop unnecessary MAINTAINERS entry for non-existent Marvell db-falcon files
* tag 'mvebu-dt-7.1-1' of https://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu:
MAINTAINERS: drop file entry in Marvell Kirkwood and Armada SOC support
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Fix this warning:
Warning: drivers/s390/crypto/zcrypt_msgtype6.c:1253 This comment
starts with '/**', but isn't a kernel-doc comment. Refer to
Documentation/doc-guide/kernel-doc.rst
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202603252022.vEojGo3V-lkp@intel.com/
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
On s390, an individual PCI function can generally be identified by two
identifiers, the FID and the UID. Which identifier is used depends on
the scope and the platform configuration.
The first identifier, the FID, is always available and identifies a PCI
device uniquely within a machine. The FID may be virtualized by
hypervisors, but on the LPAR level, the machine scope makes it
impossible to create the same configuration based on FIDs on two
different LPARs of the same machine, and difficult to reuse across
machines.
Such matching LPAR configurations are useful, though, allowing
standardized setups and booting a Linux installation on different LPARs.
To this end the UID, or user-defined identifier, was introduced. While
it is only guaranteed to be unique within an LPAR and only if indicated
by firmware, it allows users to replicate PCI device setups.
On s390, which uses a machine hypervisor, a per PCI function hotplug
model is used. The shortcoming with the UID then is, that it is not
visible to the user without first attaching the PCI function and
accessing the "uid" device attribute. The FID, on the other hand, is
used as the slot name and is thus known even with the PCI function in
standby.
Remedy this shortcoming by providing the UID as an attribute on the slot
allowing the user to identify a PCI function based on the UID without
having to first attach it. Do this via a macro mechanism analogous to
what was introduced by commit 265baca69a ("s390/pci: Stop usurping
pdev->dev.groups") for the PCI device attributes.
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Reviewed-by: Julian Ruess <julianr@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com> # drivers/pci/slot.c
Link: https://lore.kernel.org/r/20260407-uid_slot-v8-2-15ae4409d2ce@linux.ibm.com
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Update the s390 specific PCI documentation to better reflect current
behavior and terms such as the handling of Isolated VFs via commit
25f39d3dcb ("s390/pci: Ignore RID for isolated VFs").
Add a descriptions for /sys/firmware/clp/uid_checking which was added
in commit b043a81ce3 ("s390/pci: Expose firmware provided UID Checking
state in sysfs") but missed documentation.
Similarly add documentation for the fidparm attribute added by commit
99ad39306a ("s390/pci: Expose FIDPARM attribute in sysfs") and
add a list of pft values and their names.
Finally improve formatting of the different attribute descriptions by
adding a separating colon.
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Link: https://lore.kernel.org/r/20260407-uid_slot-v8-1-15ae4409d2ce@linux.ibm.com
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
A new device tree has been merged without a binding, which triggered
warnings during dtb_checks. The commit in this pull request fixes this
issue, enabling easier detection of new problems in device trees by
reducing the number of false warnings.
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQYqXDMF3cvSLY+g9cLBhiOFHI71QUCaddioAAKCRALBhiOFHI7
1SZwAJ9ImnxvrwBflE70p1JZD9Ja5eiLxQCghGmXqhwgwcM8qtejqX+tY8CTTVQ=
=boH+
-----END PGP SIGNATURE-----
Merge tag 'mvebu-fixes-7.0-1' of https://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/fixes
mvebu fixes for 7.0 (part 1)
A new device tree has been merged without a binding, which triggered
warnings during dtb_checks. The commit in this pull request fixes this
issue, enabling easier detection of new problems in device trees by
reducing the number of false warnings.
* tag 'mvebu-fixes-7.0-1' of https://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu:
dt-bindings: arm64: add Marvell 7k COMe boards
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
* Add missing reset ops for amlogic,t7-reset to the reset-meson driver.
The resets are unused as of now, but as soon as they are, the driver
would otherwise run into a NULL pointer dereference.
-----BEGIN PGP SIGNATURE-----
iI0EABYKADUWIQRRO6F6WdpH1R0vGibVhaclGDdiwAUCadYiQBcccC56YWJlbEBw
ZW5ndXRyb25peC5kZQAKCRDVhaclGDdiwMJ8AP9OANOyRc3ZeY8P6EQ+4BebOjiQ
H3yJxgF21XhAmtm2awEAlmnyZDMkp+5UFj6Fo4a+jo/BjL2uMCUjaqPgzDDfJAA=
=QTno
-----END PGP SIGNATURE-----
Merge tag 'reset-fixes-for-v7.0-3' of https://git.pengutronix.de/git/pza/linux into arm/fixes
Reset controller fixes for v7.0, part 3
* Add missing reset ops for amlogic,t7-reset to the reset-meson driver.
The resets are unused as of now, but as soon as they are, the driver
would otherwise run into a NULL pointer dereference.
* tag 'reset-fixes-for-v7.0-3' of https://git.pengutronix.de/git/pza/linux:
reset: amlogic: t7: Fix null reset ops
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Use the page aligned backing allocation size when computing the RXTX_MAP
page count. This fixes FF-A RX/TX buffer registration on kernels built
with 16K/64K PAGE_SIZE, where alloc_pages_exact() backs the buffer with a
larger aligned span than the discovered minimum buffer size.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmnU1mgACgkQAEG6vDF+
4pgxLRAA2Ajhzi3ckYBv10LqiOoRVqW9MscCCub6+lmByt0Yh1ZyzyOOrEeMDU0a
U/GxU4qkImflmcm5bZ7etADEkZVzvjg3Bj3e9riZ7yPaX2tHgwUx3H4ULHpyVGgP
uOFf2bsvduDnMMpm4E2f8ra5YPHyklCcQ6H+U0oH+uqnxzbmvPwenP8TIsTZ9lBD
7TMZMvw2bySUmLn/eBnUVU9HJkuNdhCz+VLKEcXlsvx2poeUxQDMzrD+qOvBF9AQ
OZnVoCuBSDH71nuKFVPfXKEMZz1XXlhOmDuLHUHEHc9Bm5tOruHV8gQB8PluDHhI
SMXBPTKjuJekD17ivlMFD5agEmhUFXUsqT5Tjp9f4jUD9PHYQa2jtd6qmPSKw768
aufBt0EQQhdN4V0vdnn1g51exKQKPC8bxhL5NiURVlRQ0gEcKSxm1i0Y7Pn09kuS
goFXKmsXNEpHS8W59hWALgS46oSTMmVBg4ymwJ/aZ5bhUd+ywtNB8avLO84FoFSJ
nyd0ndzTpTQk+ZTP19SglIPgAgSwtr9nGpdfOiB2lN63dCiS6M/k+p4hqyp5ReIp
RjKF1znEZHaLnS4SmX+ktZhoEwPWIyLnSIeZ2n0FoJF9gQKS3uom3DBBM0eax70/
M5aFF4pLwe+dAUlO0/zLzyHSfgDPpRhBpGZJGkZwtZKDWBPl7cc=
=ceS/
-----END PGP SIGNATURE-----
Merge tag 'ffa-fix-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into soc/drivers
Arm FF-A fix for v7.1
Use the page aligned backing allocation size when computing the RXTX_MAP
page count. This fixes FF-A RX/TX buffer registration on kernels built
with 16K/64K PAGE_SIZE, where alloc_pages_exact() backs the buffer with a
larger aligned span than the discovered minimum buffer size.
* tag 'ffa-fix-7.1' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
firmware: arm_ffa: Use the correct buffer size during RXTX_MAP
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
UART DMA channels added for A64 and H6. Standard resolution MMIO timer added
for H616. This timer can be used as a broadcast timer for wakeup from idle
states.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE2nN1m/hhnkhOWjtHOJpUIZwPJDAFAmnTxhAQHHdlbnNAa2Vy
bmVsLm9yZwAKCRA4mlQhnA8kMC0BEACw2J5vZTiXdnGbFILmCenvqu/+GTkz4p7N
RSAyjnkXAgDF5Wq0PxiYG+9e1TtWX5PMNDv8QEM9U/uvKn6/3D6eq1D//3IBSENG
owdgMBLSMGPL89zyMj0lkX4kWYaq2Jn6cmYCaN3sVPd1+vMKvGoZLZYZSsxAZrxA
BOxhX1j53onlJOjSE0ziqgni335DCTnZRbMTGuob4YFQ6d+i388eF7VBPvCCXvqs
pcZG7ukDFbKvVgeJ8rV9D0cedSyoqSMSJEwDpQK6uCpCD0tfBP7lTMe7SwaQhLzn
I4Vz6nUpU2564vqXj/GfgDmrFJB6tqlrY8lDRiLlnBe7I8s58MAkEOb2pxaNkNrz
sTpQ6ZPvWyHj5fFLxDLXoTkWTl7kSrW9PpvMa884LcBC0kDDXSM1Xpl7TmkW2w45
wqq1k0lbxOWFx+nznNZ1learhMhHKL7NsxscXRnaut7uQtetKaOJb/U59gEtY+NL
Q/hRNhYtV4cg/rfGxKrtLFnbWCQcigqnpSiqZuZQQp+Oc/Yxu0WrIBGYX5GJGj19
4ToZKvjwT6sRRLrU1pLNK7u1Q7GKhnhL++joWWIHCJwMgQQOdj7iBKlQipa636D7
nbMGZN1atc3Wqbn4xVg5//w0r1obDOAA7EBy2FyhQ8VDGHJmHuT3xdHu5vEk6CYm
XUaDv1ZY8Q==
=pYiy
-----END PGP SIGNATURE-----
Merge tag 'sunxi-dt-for-7.1-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into soc/dt
Allwinner Device Tree Changes for 7.1 - Part 2
UART DMA channels added for A64 and H6. Standard resolution MMIO timer added
for H616. This timer can be used as a broadcast timer for wakeup from idle
states.
* tag 'sunxi-dt-for-7.1-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
arm64: dts: allwinner: enable h616 timer support
arm64: dts: allwinner: sun50i-h6: add UART DMA channels
arm64: dts: allwinner: sun50i-a64: add UART DMA channels
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Flag Lenovo IdeaCentre Mini X to have functional QSEECOM/uefisecapp.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCgAsFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmnTs0cOHGJqb3JuQGty
eW8uc2UACgkQCx85Pw2ZrcWR7Q/+LFjkiYpKe9b+9rPu8bbJiFQamXrfJO6BX1NF
/t9Ko1nKJf2JJUuSrtwgF1d1/chibzn6O8/rUp5PW8JP7dsoYfUo8QpmrM1J7tGV
MF2ct5PxjuNn0L4le49bbxjx/WzkbHCTUCbxjstP9Xx/GKYSR6A/5eO/6vZAvLsG
HWdIR681IT/dudrP+B1BAq28XhlvlurRu7S1ELG7fay52ixisWPVGKeQWybdVvUt
fssC5u3izQNVh5UEq/IuiXt0bvs4klw7q3IOw0U7zna0gqthhFaNkDZMgtjNp+NH
oHpu2Zu6j69oo7PBuSqWd7pOsU5y9lPFsin3B3m9Xj+c2u4l0wmS0YwALUAjCfrz
laJlYAdvIZtHFtRi3wP5nxIDVurFYBN6WtdFzPtoRlFhMJngnUdH3EKARNAX7hvc
OIJ2/uUzgiYR/7AXIN6iZjZKLqzUb8vqgWRnj2Rvm2+3shxjEXuRdG7oNhwfacGT
Dy4zJt8rdRPCKQBK0V+FKIQJ5YYWQhdAV5UoOmjGGuu1oRJKQ0OUopG36wN/26QM
IvnC+x2rSoj+0RrTRswwknNAnYekUu5l3cozlx2MyvVlF5wL5/5fZVrgAf32Uw4+
TXtXK38GrsIp/n77M+nT6/5EkS2POtUs/jLdgi3qPnUugCH4ravRjIlsIF00i7cD
C3WfxPA=
=niWJ
-----END PGP SIGNATURE-----
Merge tag 'qcom-drivers-for-7.1-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/drivers
One more Qualcomm driver update for v7.1
Flag Lenovo IdeaCentre Mini X to have functional QSEECOM/uefisecapp.
* tag 'qcom-drivers-for-7.1-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
firmware: qcom: scm: Allow QSEECOM on Lenovo IdeaCentre Mini X
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Introduce the Hamoa-based Lenovo IdeaCentre Mini X, the Dragonwing
IQ-615 (Talos) EVK, and a Talos EVK camera overlay.
Enable DisplayPort support on the Glymur CRD.
Add WiFi, Bluetooh, LEDs, and venus on LG-based SDM845 devices. Add
battery, charger, and display on the LG G7 ThinQ.
Enable SD-card, describe the audio amplifier, and increase the speed of
the i2c clock for touchscreen on the SHIFT SHIFT6mq.
Add camera subsystem, camera control interface, GPU, GMU, and GPU
cooling on the Talos platform. Enable the GPU on the Ride board.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCgAsFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmnTsh4OHGJqb3JuQGty
eW8uc2UACgkQCx85Pw2ZrcXT2RAArplB0JyG7sQ4PsE1fAaWK093q8+v9m6U9MqD
61aDMNdbz3ZOpoIkREyau7e0Wt4+8SQjtMllnFIMyc31L6qYN+3/7CLdnvQmHKvj
Rxutwy9L49yxTDyCXWGbK2lzjS2ExlNteugW/fVraC7A6UL2QbipsfBUMlZCvx+Z
4wqUIySXzXKCJ25U1IDfHVNI+7X+yydKdRAsu3Gdj0adt5246mALEC55WSjK9DUm
dyfzamHElM1EwJ9M6MxmlDyHuEkbfwO/5IlX0UBFYAbtVgVysO14XQh12CVRTcCA
0Hsq9yYQDHxVjPCujMIlG3ySiArmF9shzmCmCxSjZHJbOd+6OX+XmbmkGmJfJFmO
LKVQrJrsZBq8tB6LwVD8PIHziDL8/omuTZQUU2s0Q4wKqStWnshjXWlTtPuO0lno
l5XMiPZ1ZEpY4juNXTu5cu9h6//OKZ9vQfvAKiYE8Fb8Fb3/T3LsLDb7SReI/RTS
TNLzTRbbMFX8nqLBaPKhcsVbrvNd4k4nIM1jkO0nZPFpWH6Ly36u/irTZqRzUkSF
/rGAv88zHp3LNztiTCLMR7hfnUk5c0ml+gPLSJgyK329JKljhoFMuiiaX/njRx+a
jyQkYqtbxIqdeJyVFxrTam2+STxLuZ09yO+T98j6NhKVg0gmqnlqoB1KoscS04Bq
2HTqK4Y=
=2zB8
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-for-7.1-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/dt
A few more Arm64 DeviceTree updates for v7.1
Introduce the Hamoa-based Lenovo IdeaCentre Mini X, the Dragonwing
IQ-615 (Talos) EVK, and a Talos EVK camera overlay.
Enable DisplayPort support on the Glymur CRD.
Add WiFi, Bluetooh, LEDs, and venus on LG-based SDM845 devices. Add
battery, charger, and display on the LG G7 ThinQ.
Enable SD-card, describe the audio amplifier, and increase the speed of
the i2c clock for touchscreen on the SHIFT SHIFT6mq.
Add camera subsystem, camera control interface, GPU, GMU, and GPU
cooling on the Talos platform. Enable the GPU on the Ride board.
* tag 'qcom-arm64-for-7.1-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (31 commits)
arm64: dts: qcom: Add the Lenovo IdeaCentre Mini X
dt-bindings: arm: qcom: Document the Lenovo IdeaCentre Mini X
arm64: dts: qcom: sdm845-shift-axolotl: Enable TFA9890 codec
arm64: dts: qcom: sdm845-shift-axolotl: Set higher touchscreen i2c clock
arm64: dts: qcom: sdm845-shift-axolotl: Enable sdcard
arm64: dts: qcom: talos: Add clocks for QoS configuration
arm64: dts: qcom: talos-evk-camera: Add DT overlay
arm64: dts: qcom: talos: Add camera MCLK pinctrl
arm64: dts: qcom: talos: Add CCI definitions
arm64: dts: qcom: talos: Add camss node
arm64: dts: qcom: talos: Add EL2 overlay
arm64: dts: qcom: talos-evk: Add support for QCS615 talos evk board
arm64: dts: qcom: talos/qcs615-ride: Fix inconsistent USB PHY node naming
dt-bindings: arm: qcom: talos-evk: Add QCS615 Talos EVK SMARC platform
arm64: dts: qcom: qcs615-ride: Enable Adreno 612 GPU
arm64: dts: qcom: talos: Add GPU cooling
arm64: dts: qcom: talos: Add gpu and rgmu nodes
arm64: dts: qcom: talos: add the GPU SMMU node
arm64: dts: qcom: sdm845-lg-common: Add chassis-type
arm64: dts: qcom: sdm845-lg: Add wifi nodes
...
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Microchip:
Add coverage for the pic64gx in the system controller and syscons.
Add a interrupt mux driver (akin to the one that Renesas recently added)
that fixes a problem where the platform never properly modelled gpio
interrupts. There's a gpio driver change here that Bartosz has acked
that adds the interrupt support to the GPIO driver itself.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCadOMGgAKCRB4tDGHoIJi
0gXaAP9j6X7ZAL+EOJqiUjQUVslWZUv+hZrKOCv1InnSHDkC5gEAovr3nk6yHjt0
a+4XnUj8AGPbT4bcFEdzeArmH//QtgA=
=+V3B
-----END PGP SIGNATURE-----
Merge tag 'riscv-soc-drivers-for-v7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/conor/linux into soc/drivers
RISC-V soc drivers for v7.1
Microchip:
Add coverage for the pic64gx in the system controller and syscons.
Add a interrupt mux driver (akin to the one that Renesas recently added)
that fixes a problem where the platform never properly modelled gpio
interrupts. There's a gpio driver change here that Bartosz has acked
that adds the interrupt support to the GPIO driver itself.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
* tag 'riscv-soc-drivers-for-v7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/conor/linux:
soc: microchip: add mpfs gpio interrupt mux driver
dt-bindings: soc: microchip: document PolarFire SoC's gpio interrupt mux
gpio: mpfs: Add interrupt support
soc: microchip: mpfs-sys-controller: add support for pic64gx
dt-bindings: soc: microchip: mpfs-sys-controller: Add pic64gx compatibility
dt-bindings: soc: microchip: add compatible for the mss-top-sysreg on pic64gx
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Generic:
Add binding coverage for Supm.
Microchip:
Add support for the picgx64 and its curiosity board. This is a PolarFire
SoC without the FPGA.
Add the missing tsu_clk for ptp on the macb on PolarFire SoC and resolve
a long-running problem with gpio interrupts being incorrectly described
on the platform.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCadOI5gAKCRB4tDGHoIJi
0jxXAP94SQeRxMv5UlPaz5qQfsDIDlH3wnPrbaKLkiKxke8QRwEAnv2sNIv6w6e9
b96heW7o3KCEEEha19tFQKqXV5Vcrg4=
=1yzS
-----END PGP SIGNATURE-----
Merge tag 'riscv-dt-for-v7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/conor/linux into soc/dt
RISC-V devicetrees for v7.1
Generic:
Add binding coverage for Supm.
Microchip:
Add support for the picgx64 and its curiosity board. This is a PolarFire
SoC without the FPGA.
Add the missing tsu_clk for ptp on the macb on PolarFire SoC and resolve
a long-running problem with gpio interrupts being incorrectly described
on the platform.
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
* tag 'riscv-dt-for-v7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/conor/linux:
riscv: dts: microchip: update mpfs gpio interrupts to better match the SoC
riscv: dts: microchip: add tsu clock to macb on mpfs
dt-bindings: riscv: Add Supm extension description
riscv: dts: microchip: remove POLARFIRE mention in Makefile
riscv: dts: microchip: add pic64gx and its curiosity kit
dt-bindings: riscv: microchip: document the PIC64GX curiosity kit
dt-bindings: timer: sifive,clint: add pic64gx compatibility
riscv: dts: microchip: add pinctrl nodes for mpfs/icicle kit
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
- Fixes interrupt storm by adding pull up pinctrl config for pin PMIC_nINT.
-----BEGIN PGP SIGNATURE-----
iQHFBAABCgAvFiEEJS45w2QNr0ezLVaoNF3oRQ23YkwFAmnPJG0RHGZyYW5rLmxp
QG54cC5jb20ACgkQNF3oRQ23Ykzh4wwApbcT5KvoZwkZP7kvUBWVts+st2/fqkbl
YRfcM5c5y69U8qgyflVuZuOtmZhqGzHBzlPOOPJB7vTQQywUiRan6NZ/RsjFrBET
TLK9DqKoTKC/2xjlHtQcK118rAHSK5k0RNuv8pS/ziMGD8HWT3Xx/lRX046TuNLQ
CAvULrmruGY9+Gi0g/9Kq4rYLG7ju2gJVAIOX17Gl40XNIGVkLpqor5rVKzRRDk2
MzBy69AcfWkj9XQDZqp+zFj+aIqKIw14kenDRT4XvxI4l0rxqCC0xbSB2VZIQOKy
M6+hHybsAvI762kBAZCmzi9LmO283OCwU3rQizjS+Y8uAWU9sQS0TPGgkWZCnhqm
AHndQQLO+OAmMkgE42aNn4KnSAU1MclKYqWDeDjDC0wINivo2oC46N3TEXxOZRHS
FMmbBaSJHw+jZLOt9dHxYAMMfsPNLg/WpNw7hYJrxHtDriwRxBD8BeBZ+y3+sKHb
V6ooR9BT1sahgm5rmT1ObbA5iIixXlzd
=ryPm
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-7.0-2nd' of https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into arm/fixes
i.MX fixes for 7.0 2nd round:
- Fixes interrupt storm by adding pull up pinctrl config for pin PMIC_nINT.
* tag 'imx-fixes-7.0-2nd' of https://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux:
arm64: dts: imx8mm-tqma8mqml: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mn-tqma8mqnl: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mm-emtop-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-data-modul-edm-sbc: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-dhcom-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-ultra-mach-sbc: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-sr-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-nitrogen-som: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-aristainetos3a-som-v1: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-edm-g: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-icore-mx8mp: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-navqp: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-debix-som-a: Correct PAD settings for PMIC_nINT
arm64: dts: imx8mp-debix-model-a: Correct PAD settings for PMIC_nINT
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
While the RV1103B only got a B-extension to its name, the SoC internals
were reworked heavily. So likely it's mainly pin compatible to the
non-B variant.
The dt-binding for the RV1103B clock driver is shared with the clock-
driver branch going into the clock-tree.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmnPiKMQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgcVGB/9TvEArrDeCimaXfLRWKcZtQkrpbmcIb2Kh
BdGY4cX4YS8g/77pBFg9LMt21dKI3jlmyR76Wf7i9iZVCcWnzcxrhCsB9unEi44c
jQHa5QJQ++7IXk6/2SrKHfabcmFoVBiDHVpGqbOw2jq8vcTF0IgWKDu5NzjjDUoT
jbvAxJa+JzTeqEvdZgTdFldPpwMUClqnQqVsTs1w6XlFyMNIRr2ItcJKFU6+JbQX
UWAlL0/v4v4e+YGsfd/VIXVHFyN81e/yI4s4OwZh2DtM+eFjTbphpJuiltvatqXS
fuUYjq0U0geWWJMQypDYsZBVXrlbRAICSSDkf8TUqWZSMxf9fFg6
=5y+y
-----END PGP SIGNATURE-----
Merge tag 'v7.1-rockchip-dts32-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt
Support for the RV1103B SoC and the Onion Omega4 board using it.
While the RV1103B only got a B-extension to its name, the SoC internals
were reworked heavily. So likely it's mainly pin compatible to the
non-B variant.
The dt-binding for the RV1103B clock driver is shared with the clock-
driver branch going into the clock-tree.
* tag 'v7.1-rockchip-dts32-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
ARM: dts: rockchip: Add Onion Omega4 Evaluation Board
dt-bindings: arm: rockchip: Add Omega4 Evaluation board
ARM: dts: rockchip: Add support for RV1103B
dt-bindings: soc: rockchip: grf: Add RV1103B compatibles
dt-bindings: clock: rockchip: Add RV1103B CRU support
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
as fix for the current release.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmnPiIcQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgVsjB/wOmHnrqfSjPG0nWUUlXhAu9T2rRaSnRjvn
ZALER7Gf+Z103KONaJC8mUt4aa+PDAxCO82kO9mr8a+5wEHM+Ujz4hk2PrT0MrGe
9VHjd5HdU0NLMvmaeSHrBqJ3JQQokusvYJz1xEE/rP8Dc6hUmmjOq7IzjdbOcmCc
m+64bMPfif+YdKaoQ123Wjg8CJN36fVdDQRgvPiG6sb1WmyApx3xo9wWlZl+E1Gb
2Abi3TLvdQ/Xo1c9eqo//GblRQsCaTuOfJmwQoi2tVUyJe233RTP6XwrpHbav9LR
tFv7VjcZ+qrKZxrgzm/2v/I7YjtJMSy3tRwCict8MO91CGi3mPPs
=H+b0
-----END PGP SIGNATURE-----
Merge tag 'v7.1-rockchip-dts32-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt
A number of dt-schema cleanups that are log standing, so not suitable
as fix for the current release.
* tag 'v7.1-rockchip-dts32-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
ARM: dts: rockchip: Pass linux,code to the power key on rk3288-veyron-pinky
ARM: dts: rockchip: Fix LED node names on rk3288-phycore-rdk
ARM: dts: rockchip: Fix GMAC description n RK3288 boards
ARM: dts: rockchip: Fix RTC description on rk3288-firefly-reload
ARM: dts: rockchip: Add missing the touchscreen interrupt on rk3288-phycore-rdk
ARM: dts: rockchip: Fix the trackpad supply on rk3288-veyron-jerry
ARM: dts: rockchip: Fix the Bluetooth node name on rk3288-veyron
ARM: dts: rockchip: Remove invalid regulator-property from rk3288-veyron
ARM: dts: rockchip: Use mount-matrix on rk3188-bqedison2qc
ARM: dts: rockchip: Fix RTC compatible on rk3288-phycore-rdk
ARM: dts: rockchip: Move PHY reset to ethernet-phy node on rk3036 boards
ARM: dts: rockchip: Remove rockchip,grf from rk3288 tsadc
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Some devices' mixers are sticky, which accept SET_CUR but do absolutely
nothing. Registering these mixers confuses userspace and results in
ineffective volume control.
Check if a mixer is sticky by setting the volume to the maximum or
minimum value and checking for effectiveness afterward. Prevent the
mixer from being registered if it turns out to be sticky.
Quirky device sample:
usb 7-1: New USB device found, idVendor=0e0b, idProduct=fa01, bcdDevice= 1.00
usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 7-1: Product: Feaulle Rainbow
usb 7-1: Manufacturer: Generic
usb 7-1: SerialNumber: 20210726905926
(Mic Capture Volume)
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260411-uac-sticky-mixer-v1-3-29d62717befd@rong.moe
Signed-off-by: Takashi Iwai <tiwai@suse.de>
All callers of get_min_max*() ignore the latter's return code
completely. This means to ignore temporary errors at the probe time.
However, it is not optimal and leads to some maintenance burdens.
Return -EAGAIN for temporary errors, and check against it in the callers
of get_min_max*(). If any other error occurs, bail out of the caller
early.
Suggested-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/87ldewi4j8.wl-tiwai@suse.de
Signed-off-by: Rong Zhang <i@rong.moe>
Link: https://patch.msgid.link/20260411-uac-sticky-mixer-v1-1-29d62717befd@rong.moe
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add documentation for the device tree binding of the XDP720 eFuse.
Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20260410070154.3313-2-Ashish.Yadav@infineon.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
The pstore ftrace frontend works by purely collecting the
instruction address, saving it on the persistent area through
the backend and when the log is read, on next boot for example,
the address is then resolved by using the regular printk symbol
lookup (%pS for example).
Problem: if we are running a relocatable kernel with KASLR enabled,
this is a recipe for failure in the symbol resolution on next boots,
since the addresses are offset'ed by the KASLR address. So, naturally
the way to go is factor the KASLR address out of instruction address
collection, and adding the fresh offset when resolving the symbol
on future boots.
Problem #2: modules also have varying addresses that float based
on module base address and potentially the module ordering in
memory, meaning factoring KASLR offset for them is useless.
So, let's hereby only take KASLR offset into account for core
kernel addresses, leaving module ones as is.
And we have yet a 3rd complexity: not necessarily the check range
for core kernel addresses holds true on future boots, since the
module base address will vary. With that, the choice was to mark
the addresses as being core vs module based on its MSB. And with
that...
...we have the 4th challenge here: for some "simple" architectures,
the CPU number is saved bit-encoded on the instruction pointer, to
allow bigger timestamps - this is set through the PSTORE_CPU_IN_IP
define for such architectures. Hence, the approach here is to skip
such architectures (at least in a first moment).
Finished? No. On top of all previous complexities, we have one
extra pain point: kaslr_offset() is inlined and fully "resolved"
at boot-time, after kernel decompression, through ELF relocation
mechanism. Once the offset is known, it's patched to the kernel
text area, wherever it is used. The mechanism, and its users, are
only built-in - incompatible with module usage. Though there are
possibly some hacks (as computing the offset using some kallsym
lookup), the choice here is to restrict this optimization to the
(hopefully common) case of CONFIG_PSTORE=y.
TL;DR: let's factor KASLR offsets on pstore/ftrace for core kernel
addresses, only when PSTORE is built-in and leaving module addresses
out, as well as architectures that define PSTORE_CPU_IN_IP.
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Link: https://patch.msgid.link/20260410205848.2607169-1-gpiccoli@igalia.com
Signed-off-by: Kees Cook <kees@kernel.org>
Amery Hung says:
====================
Use kmalloc_nolock() universally in BPF local storage
Socket local storage did not convert to use kmalloc_nolock() since there
were observable performance degredation due to kfree_nolock() hitting the
slow path and the lack of kfree_rcu()-like batching freeing. Now that
these concern were addressed in slub, convert all remaining local storage
flavors to use kmalloc_nolock().
v1 -> v2:
- Fix build (CI, Alexei)
====================
Link: https://patch.msgid.link/20260411015419.114016-1-ameryhung@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Remove the check that rejects sleepable BPF programs from doing
BPF_ANY/BPF_EXIST updates on local storage. This restriction was added
in commit b00fa38a9c ("bpf: Enable non-atomic allocations in local
storage") because kzalloc(GFP_KERNEL) could sleep inside
local_storage->lock. This is no longer a concern: all local storage
allocations now use kmalloc_nolock() which never sleeps.
In addition, since kmalloc_nolock() only accepts __GFP_ACCOUNT,
__GFP_ZERO and __GFP_NO_OBJ_EXT, the gfp_flags parameter plumbing from
bpf_*_storage_get() to bpf_local_storage_update() becomes dead code.
Remove gfp_flags from bpf_selem_alloc(), bpf_local_storage_alloc() and
bpf_local_storage_update(). Drop the hidden 5th argument from
bpf_*_storage_get helpers, and remove the verifier patching that
injected GFP_KERNEL/GFP_ATOMIC into the fifth argument.
Signed-off-by: Amery Hung <ameryhung@gmail.com>
Link: https://lore.kernel.org/r/20260411015419.114016-4-ameryhung@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
