Explicitly assigning .driver_data in drivers that don't use this member
is silly and a bit irritating. Drop it. Also simplify the list
terminator entry to be just empty to match what most other device_id
tables do.
While touching these arrays convert them to use named initializers,
empty list terminators and no comma after the terminator.
There is no changed semantic, not even a change in the compiled result.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Signed-off-by: Sean Young <sean@mess.org>
After rc_register_device() succeeds, later probe failures must undo the
registration with rc_unregister_device(). The current error path jumps to
the allocation cleanup label and only calls rc_free_device(), leaving the
rc device registration and resources created by rc_register_device()
behind.
Add a registered-device unwind label for the IRQ lookup, IRQ request, and
hardware initialization failure paths. Keep rc_free_device() for failures
before rc_register_device() succeeds.
Fixes: b4e3e59fb5 ("[media] rc: add sunxi-ir driver")
Cc: stable@vger.kernel.org
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Sashiko (locally) reports a possible null dereference under memory
pressure due to the lack of validation of the allocated pointer.
Fix that by adding the missing check.
Fixes: 2b78d79cdf ("optee: FF-A: dynamic protected memory allocation")
Signed-off-by: Mostafa Saleh <smostafa@google.com>
Signed-off-by: Sebastian Ene <sebastianene@google.com>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Reviewed-by: Sebastian Ene <sebastianene@google.com>
Signed-off-by: Jens Wiklander <jenswi@kernel.org>
The driver explicitly sets the .driver_data member of struct
platform_device_id to zero without relying on that value. Drop this
unused assignment.
While touching this array unify spacing and usage of commas and use
a named initializer for .name for improved readability.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Reviewed-by: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
Signed-off-by: Jens Wiklander <jenswi@kernel.org>
cros_typec_register_partner_pdos() copies the partner PDOs from the EC
TYPEC_STATUS response into the fixed caps_desc.pdo[PDO_MAX_OBJECTS] array.
memcpy(caps_desc.pdo, resp->source_cap_pdos,
sizeof(u32) * resp->source_cap_count);
...
memcpy(caps_desc.pdo, resp->sink_cap_pdos,
sizeof(u32) * resp->sink_cap_count);
PDO_MAX_OBJECTS is 7. source_cap_count and sink_cap_count are u8 fields
from the EC. The only check is that they are not both zero. If either is
larger than 7, the memcpy writes past the end of the array on the stack.
A count of 255 overflows it by about 1 KB. The EC source arrays are only
seven entries wide. A larger count reads past them too.
The ChromeOS EC firmware caps these counts today, so a compliant setup
does not hit this. The kernel should still validate these values rather
than trust them.
Validate the counts in cros_typec_register_partner_pdos() next to the
memcpy. Skip the PDO registration if either count is above PDO_MAX_OBJECTS.
The rest of cros_typec_handle_status() still runs so events are handled
and cleared.
Fixes: 348a2e8c93 ("platform/chrome: cros_ec_typec: Register partner PDOs")
Suggested-by: Andrei Kuchynski <akuchynski@chromium.org>
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Andrei Kuchynski <akuchynski@chromium.org>
Link: https://lore.kernel.org/r/20260625130056.3378097-1-maoyixie.tju@gmail.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
The trackpad power supply on Spherion is the system common 3.3V power
rail. This is always on as long as the main processor is running.
Switch to the dumb trackpad prober since it does not need to manage
the power rail.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20260625060859.1020483-1-wenst@chromium.org
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
The drivers explicitly set the .driver_data member of struct
platform_device_id to zero without relying on that value. Drop these
unused assignments.
While touching these arrays use a single space in the list terminator
consistently.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/5b72bac661bdf1c874bea4b91ce3c2eccc84bba1.1781690554.git.u.kleine-koenig@baylibre.com
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Each EC FIFO event carries an 8-bit sensor number (in->sensor_num).
cros_ec_sensorhub_ring_handler() validates the FIFO event count, the
per-read count and the ring bound, but not the sensor number, which
cros_ec_sensor_ring_process_event() then uses unchecked to index
sensorhub->batch_state[] - allocated with only sensorhub->sensor_num
entries. A sensor number of sensor_num or larger is an out-of-bounds
read and write of batch_state[].
Validate the sensor number in the ring handler, where each event is read
from the EC, and drop a malformed event before it is used.
Fixes: 145d59baff ("platform/chrome: cros_ec_sensorhub: Add FIFO support")
Cc: stable@vger.kernel.org
Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me>
Link: https://lore.kernel.org/r/20260618-b4-disp-adb3f790-v3-1-3a164ed63cbd@proton.me
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
This reverts commit 4f1cab2e48.
Allowing SCL=0 on platforms with always-on VRR timing generator is
causing underruns and other issues on PTL in some cases.
SCL still needs to be non-zero in certain scenarios. Revert for now
until this is better understood.
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com>
Link: https://patch.msgid.link/20260622101736.2389991-1-ankit.k.nautiyal@intel.com
The compatible entries in qcom.yaml were not in alphabetical order by
their base SoC compatible string (the last const: qcom,* in each block),
making the file harder to audit and maintain. Sort the entries for
better maintenance.
No functional change; reordering only.
Assisted-by: Claude:claude-sonnet-4-6
Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260625-reorg_qcom_binding-v1-1-f2c6501f7401@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The CAMSS_TOP_GDSC inside camcc requires an interconnect path to be
enabled, otherwise the GDSC will be stuck on 'off' and can't be enabled.
Add the interconnect path so that this requirement can be satisfied by
the kernel.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260501-milos-camcc-icc-v2-5-bb83c1256cc3@fairphone.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The Geni serial-engine interrupts from QUP wrapper 0 all fall in ESPI
INTIDs space. While some of the i2c instances has gotten their
interrupt specifiers corrected, even the other functions on the same
serial-engines are wrong.
Ensure that all the serial engine interrupts for QUP wrapper 0 matches
the datasheet.
Assisted-by: Codex:GPT-5.5
Fixes: 41b6e8db40 ("arm64: dts: qcom: Introduce Glymur base dtsi")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260611-glymur-geni-irqs-v1-1-269428faeb6d@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The PCIe SMMUv3 wired interrupts are routed to GIC extended SPI INTIDs
4100, 4098 and 4096. Describe them as ESPIs with the ESPI-relative
interrupt numbers instead of regular SPIs 964, 962 and 960.
Assisted-by: Codex:GPT-5.5
Fixes: 41b6e8db40 ("arm64: dts: qcom: Introduce Glymur base dtsi")
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260611-glymur-pcie-smmu-espi-v1-1-5effbaa3e1af@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The GPU does not throttle its speed automatically when it
reaches high temperatures. Set up GPU cooling by throttling
the GPU speed when it reaches 95°C.
Signed-off-by: Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260522-glymur-gpu-dt-v5-5-562c406b210c@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The Adreno X2 series GPU present in Glymur SoC belongs to the A8x
family. It is a new HW IP with architectural improvements as well
as different set of hw configs like GMEM, num SPs, Caches sizes etc.
Add the GPU and GMU nodes to describe this hardware.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260522-glymur-gpu-dt-v5-4-562c406b210c@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
The NPCM7xx FIU controller nodes reference a single clock, but their
clock-names properties are not described by the FIU binding. Drop the
undocumented names so the DTS matches the binding.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
The NPCM7xx FIU controller nodes only describe the control register block,
but they still advertise a second "memory" entry in reg-names. Drop the
bogus name so the DTS matches the resources actually present in each node.
Signed-off-by: Tomer Maimon <tmaimon77@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Johannes doesn't have the hardware to test patches on it anymore and
TTBOMK, no one else has shown interest so orphan the driver, for now at
least.
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Johannes Thumshirn <jth@kernel.org>
Link: https://patch.msgid.link/20260612153839.GCaiwn_7qOic4KLF8P@fat_crate.local
The use of __SYSFS_FUNCTION_ALTERNATIVE() adds an anonymous union (or
struct if CONFIG_CFI=y).*
Describe the additional struct/union members to avoid docs build
warnings.
Warning: include/linux/device.h:117 struct member 'show_const' not described in 'device_attribute'
Warning: include/linux/device.h:117 struct member 'store_const' not described in 'device_attribute'
*: kernel-doc ignores CONFIG_ symbols in source files; it is using the
first definition of __SYSFS_FUNCTION_ALTERNATIVE(), which is struct
instead of union.
Fixes: 434506b86a ("driver core: Allow the constification of device attributes")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://patch.msgid.link/20260623190023.407781-1-rdunlap@infradead.org
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Commit
ccace936ee ("x86: Add types to indirectly called assembly functions")
introduced a x86-specific implementation of __CFI_TYPE() using an asymmetric
combination of SYM_START() and SYM_FUNC_END() to add a symbol to the KCFI type
identifier that precedes a function.
This asymmetric combination is an issue if SYM_FUNC_END() ever gets extended
in a way that requires it to be used symmetrically with SYM_FUNC_START*().
For instance to emit DWARF CFI directives that denote the start/end of
a function. [1]
Use SYM_END() with SYM_T_FUNC instead. No functional change, as the generic
implementation of SYM_FUNC_END(name) expands into SYM_END(name, SYM_T_FUNC).
Fixes: ccace936ee ("x86: Add types to indirectly called assembly functions")
Closes: https://sashiko.dev/#/patchset/20260522110427.2816637-1-jremus@linux.ibm.com?part=3 [1]
Reported-by: Sashiko <sashiko-bot@kernel.org>
Signed-off-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260611155716.830563-1-jremus@linux.ibm.com
Commit 651fdda840 ("relay: update relay to use mmap_prepare")
changed the `mmap` file operation to `mmap_prepare` for relayfs, but
the lockdown check in debugfs was not updated accordingly.
This prevents debugfs from being locked down when the kernel is in
integrity mode if a file uses `mmap_prepare` but not `mmap`.
Since the conversion to `mmap_prepare` across the kernel is not yet
complete, update the lockdown check to look for both `mmap` and
`mmap_prepare` to ensure comprehensive coverage.
Fixes: 651fdda840 ("relay: update relay to use mmap_prepare")
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Danilo Krummrich <dakr@kernel.org>
Cc: driver-core@lists.linux.dev
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Tested-by: Disha Goel <disgoel@linux.ibm.com>
Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
Link: https://patch.msgid.link/20260615104750.1000-1-jlee@suse.com
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQFSBAABCgA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmpBb4seHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiGjV8H/iFiGxRTgdNwWJsH
5BQpc9kAmQHBMuzc2yM1HeeKVOm+zfxEmZV7kFabPEGYB1ltV52vspKI5vPUCWhP
9VVqhIQy8ZfALEUIhQOoieJAboRgNDySldnuS8E2MFyfgKC0Tg8dkolmRFuh8Xhu
R88kBeS1+DfpjFrnNLH98iUdtE9HabVt2VGfdrIpTYLC8VqyyuI77dXTEFkkwSCp
NacpX5KYzD9dlDjlH6Hpqy/jqv7Y7JsEynFVUU05IQU9VojV7o1cbMQlKoe1yNeU
dCoDCSwHhc8DUrGx1Tj6lsAS8k0R2it5FIW1eCF7cVKzZ8CbojyhluW6YPCOC0wE
0louZxg=
=5vas
-----END PGP SIGNATURE-----
Merge tag 'v7.2-rc1' into drm-rust-next
Merge v7.2-rc1 into drm-rust-next to start the next cycle.
Devres now requires T: 'static, which conflicts with shmem::Object using
Devres<SGTableMap<T, C>> without that bound. Resolve by adding 'static
as a supertrait to DriverObject and DeviceContext, which does not
restrict any current use cases since DriverObject is always implemented
on owned, refcounted types and DeviceContext is a sealed marker trait
with only unit-type implementors.
If DriverObject (or DeviceContext) ever becomes lifetime-parameterized
(e.g. via a GAT for TTM backed objects), the 'static supertrait can be
relaxed at that point.
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
The argument args is not documented, and the latest kernel version
complains about that.
This fixes the following warning:
Warning: include/media/media-entity.h:1394 function parameter 'args'
not described in 'media_entity_call'
Fixes: 48a7c4bac9 ("[media] docs-rst: improve the kAPI documentation for the mediactl")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The variable has been previously removed but not its kerneldoc.
Also remove the leftover reference to state in the description of qlock.
This patch fixes the following warning:
Warning: drivers/media/platform/renesas/rzg2l-cru/rzg2l-cru.h:164
Excess struct member 'state' description in 'rzg2l_cru_dev'
Fixes: 85d8820d48 ("media: rzg2l-cru: Remove the 'state' variable")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The field has been removed, but the kerneldoc not. Let's take care of
this.
This patch fixes the following warning:
Warning: drivers/media/i2c/ov9282.c:223 Excess struct member 'mutex'
description in 'ov9282'
Fixes: 0c69a963a3 ("media: i2c: ov9282: Switch to using the sub-device state lock")
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Reviewed-by: Daniel Scally <dan.scally@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
When batadv_tp_handle_out_of_order() searches the already existing list of
unacked packets, it can often find an entry to merge with. In this case, it
would be a waste of time and resources to allocate a batadv_tp_unacked
which is then immediately freed again.
Instead, search first through the list. Only when no mergeable entry could
be found, it is necessary to record the place to allocate+store the new
entry.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The lock used to protect the receiver from reading/writing in parallel to
ack sequence number relevant data was still called unacked_lock. But it is
no longer only about the unacked_list. Use a broader term to reflect this.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
There is no need to share the unacked list between sender and receivers.
Only receivers will ever write to and read from it. The initialization in
batadv_tp_start() was therefore never needed. After its removal, it is
enough to just store it in struct batadv_tp_receiver.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Right at the point when the receiver gets the first packet with a seqno gap
(due to some packet loss/reordering), entries in the unacked list are
created. They are (besides direct seqno matches) are not combined. A lot
more then necessary entries are therefore created. Not for each gap but for
each packet.
This increases the memory consumption and management overhead. But it is
trivial to handle overlapping or adjacent sequence number ranges during the
insert. Only the handling of closed gaps by a new packets requires an extra
step after the insert.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
When batadv_tp_ack_unordered() goes through the list of unacked sequence
numbers and checks for now closed gaps, it is first calculating a delta of
the sequence numbers which could be acked. Just to revert this calculation
in the next steps to the sequence number which would be ackable.
Skip the delta step and directly work with the sequence numbers.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
batadv_tvlv_containers_contain() and batadv_tvlv_containers_process() are
using the same code to iterate through the TVLV containers. To simplify the
code, extract the shared portions of both functions.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
With the immutability guarantee of batadv_hard_iface->mesh_iface, the check
for "changed" (or NULL) mesh_iface is no longer necessary because a
batadv_hard_iface can no longer migrate from one batadv_mesh_iface to
another one.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
With the immutability guarantee of batadv_hard_iface->mesh_iface, the check
for "changed" (or NULL) mesh_iface doesn't work anymore and is also no
longer necessary. The extra (complicated) code for the sending of OGMv2s
can therefore be removed and the original code can be used again.
This reverts commit f8ce8b8331.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The batadv_hard_iface->mesh_iface became immutable after the global
batadv_hardif_list was removed and batadv_hard_iface only exists when it is
assigned to an mesh_iface. This member can never become NULL and thus a
check is now unnecessary.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The only use of the label was too early for primary_if to be set
anyways.
Also move the put of primary_if further up to hold the reference only as
long as necessary, hopefully avoiding the need to re-introduce the goto
label with future code changes.
Signed-off-by: Nora Schiffer <neocturne@universe-factory.net>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
The counter doesn't need to be global.
Signed-off-by: Nora Schiffer <neocturne@universe-factory.net>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
With hardifs only existing while an interface is part of a mesh, the
BATADV_IF_NOT_IN_USE state has become redundant.
Signed-off-by: Nora Schiffer <neocturne@universe-factory.net>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
With the hard_iface now being created for a specific mesh_iface, it is
beneficial not to set mesh_iface to NULL when the interface is disabled,
but instead keeping it immutable after the initial setup of the
hard_iface. By also holding the reference to the mesh_iface until the
hard_iface is released, hard_ifaces iterated over under RCU will always
point to a valid mesh_iface.
Co-developed-by: Nora Schiffer <neocturne@universe-factory.net>
Signed-off-by: Nora Schiffer <neocturne@universe-factory.net>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
With interfaces being kept track of as iflink private data, there is no
need for the global list anymore. batadv_hardif_get_by_netdev() can now
use netdev_master_upper_dev_get()+netdev_lower_dev_get_private() to find
the hardif corresponding to a netdev.
Signed-off-by: Nora Schiffer <neocturne@universe-factory.net>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
batman-adv is using netdev notifiers to create a hard_iface struct for
every Ethernet-like netdev in the system. These hardifs are tracked in a
global linked list, which results in a few performance issues:
Lookups in this list are O(n) in the total number of netdevs. As a
hardif is looked up when a netdev is removed, this also takes O(n) in
the number of netdevs, and removing n netdevs may take O(n^2). This
slowdown will always happen when the batman-adv module is loaded, no
mesh needs to be active.
With the hardif being referenced as iflink private data, the global list
is only needed for hardifs that are *not* part of a mesh (that is, the
hardif is unused). To prepare for removing the global list, only create
a hardif struct when an interface is added to a mesh and destroy it on
removal.
As adding/removing and enabling/disabling a hardif become one and the
same, batadv_hardif_add_interface() is merged into
batadv_hardif_enable_interface(), and batadv_hardif_remove_interface()
can be dropped altogether.
Signed-off-by: Nora Schiffer <neocturne@universe-factory.net>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
No in-tree board references these gates yet. Boards drive the codec
MCLK through the parent I2S*_8CH_MCLKOUT, and now that the gates are
managed clocks, clk_disable_unused() turns them off at boot. On a board
that relied on firmware leaving the output enabled, that cuts the MCLK
and analog audio stops working.
Mark the four gates CLK_IGNORE_UNUSED so an unreferenced gate keeps the
state firmware left. A board that wants the kernel to own the gate can
reference I2S*_8CH_MCLKOUT_TO_IO from DT instead.
Fixes: 02b9b0bb62 ("clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO")
Reported-by: Diederik de Haas <diederik@cknow-tech.com>
Closes: https://lore.kernel.org/linux-rockchip/DJGDSS875DDO.22TYPVYK5X8KZ@cknow-tech.com/
Tested-by: Diederik de Haas <diederik@cknow-tech.com>
Signed-off-by: Daniele Briguglio <hello@superkali.me>
Tested-by: Ricardo Pardini <ricardo@pardini.net> # on R58X-Pro+NanoPC-T6
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://patch.msgid.link/20260624123914.1767374-1-hello@superkali.me
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
According to the Jedec 5.1 specification, the device is held in reset
when RST_n is low, therefore the polarity of the line must be that, as
specified in the Device Tree binding (mmc/mmc-pwrseq-emmc.yaml).
Due to the wrong polarity, eMMC devices with RST_n_FUNCTION[162]
bitfield [1:0] set to 0x1 (the default is 0x0) will be held in reset
forever.
Cc: stable@vger.kernel.org
Fixes: 56198acdbf ("arm64: dts: rockchip: add px30-pp1516 base dtsi and board variants")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260612-pp1516-emmc-polarity-v1-1-4816c1c909f7@cherry.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Technically, the reset signal is active low - it's called RST_n after all.
But it is ignored completely unless RST_n_FUNCTION=1 (byte 162 in extcsd)
is set in the emmc. It is 0 per default.
For emmcs that have RST_n_FUNCTION=1 we failed like this:
[ 3.074480] mmc1: Failed to initialize a non-removable card
With this change they work normally.
Cc: stable@vger.kernel.org
Fixes: bb510ddc9d ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
Signed-off-by: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://patch.msgid.link/20260609081728.30616-2-jakobunt@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
device removal, along with documentation fixes and minor AMD driver
cleanups.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEoE9b9c3U2JxX98mqbmZLrHqL0iMFAmpBIsgACgkQbmZLrHqL
0iN+tA/+LCXsiysq5XLscCkWL7vwT2rbh/uLBjnBC2YEgfFWOtfOrwnNYlSXEJAo
PE9RRbqCBGXpv0CQ5iah96ff8HdDU6O36+UD9el1jGxUN/UxtD0Q7ibfsJ+gyf4N
ANNDrkTAo6AcDxM/AG9B/bBy5EnNDDH1bURIWM3dohp3CNhRbbSHbyiuf20uFgef
i+iArjk2ePL0tGEzUIEHVsEwGJFVrgAYr/7OZ2dSvpMn8AhI8bj5U3YANwQOnQS6
QlNKZ/t7mgNJ4zGBIhzQcmUlIuLY0GsOhyKhXAcmc7uNumJotyuTcQ7F3Ybky8DY
Pjzt7fc+4wT9fH/B303JfuFY2SXUWHkTXA1zZGfeV8zJrljqfEx+8elJAkRR7ifJ
PVR2w85W88qfW5HfBfiBGstq5aA9aFNQscJQIN//ejjuPbrLPEeIodLte4j8QzRb
uo+8L1n2TiR7NljdAYBrhuUAnoW5F7sx/k0jsqZvOvM48oVzr1pZeNJF3EG5UHfE
9RmOx+VuF4f5p0zMYjvhumCRN3p8fwKNDMxGBTGSD4YQ6+SRTh6HnfQDwv4uqVBn
nC8fBHLEdj4wmUzttYuCOD+ltBN02viyv/bUIQdd+BDjsR5b7q76Rxo3BGkNy1/z
FdXGFs3L26pOY5X+equ8FAfd5V4sfVL2HZO5PYPclP2HsJroHz8=
=V3cD
-----END PGP SIGNATURE-----
Merge tag 'ntb-7.2' of https://github.com/jonmason/ntb
Pull NTB updates from Jon Mason:
"An EPF bug fix to prevent an invalid unmap during device removal,
along with documentation fixes and minor AMD driver cleanups"
* tag 'ntb-7.2' of https://github.com/jonmason/ntb:
ntb: amd: Use named initializer for pci_device_id::driver_data
NTB: fix kernel-doc warnings in ntb.h
NTB: epf: Avoid pci_iounmap() with offset when PEER_SPAD and CONFIG share BAR
ntb_hw_amd: Fix incorrect debug message in link disable path
