| Age | Commit message (Collapse) | Author |
|---|
|
Fix kernel-doc warnings on struct guc_lfd_file_header:
Warning: ../drivers/gpu/drm/xe/abi/guc_lfd_abi.h:168 expecting prototype
for struct guc_logfile_header. Prototype was for struct
guc_lfd_file_header instead
Fixes: 7eeb0e5408bd ("drm/xe/guc: Add LFD related abi definitions")
Cc: Zhanjun Dong <zhanjun.dong@intel.com>
Cc: Julia Filipchuk <julia.filipchuk@intel.com>
Cc: Ashutosh Dixit <ashutosh.dixit@intel.com>
Reviewed-by: Zhanjun Dong <zhanjun.dong@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patch.msgid.link/20260107155401.2379127-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
|
|
On Xe3_LPD, there is no instruction to program the CD2X divider anymore
and the hardware is expected to always use the default value of 0b00,
meaning "divide by 1".
With that, the CDCLK_CTL register was changed so that:
(1) The field "CD2X Divider Select" became a debug-only field.
Because we are programming CDCLK_CTL with a direct write instead
of read-modify-write operation, we still need to program "CD2X
Divider Select" in order to keep the field from deviating from its
default value. Let's, however, throw a warning if we encounter a
CDCLK value that would result in an unexpected value for that
field.
(2) The field "CD2X Pipe Select" has been removed. In fact, some
debugging in a PTL machine showed that such field comes back as
zero after writing a non-zero value to it. As such, do not
program it starting with Xe3_LPD.
v2:
- Add missing "val |= " when calling bxt_cdclk_cd2x_pipe().
(Dnyaneshwar)
Bspec: 68864, 69090
Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com>
Link: https://patch.msgid.link/20260106-xe3_lpd-no-cd2x-divider-v2-1-06e5cbc9dabb@intel.com
Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
|
|
A race condition exists between the async partition scan work and device
teardown that can lead to a use-after-free of ub->ub_disk:
1. ublk_ctrl_start_dev() schedules partition_scan_work after add_disk()
2. ublk_stop_dev() calls ublk_stop_dev_unlocked() which does:
- del_gendisk(ub->ub_disk)
- ublk_detach_disk() sets ub->ub_disk = NULL
- put_disk() which may free the disk
3. The worker ublk_partition_scan_work() then dereferences ub->ub_disk
leading to UAF
Fix this by using ublk_get_disk()/ublk_put_disk() in the worker to hold
a reference to the disk during the partition scan. The spinlock in
ublk_get_disk() synchronizes with ublk_detach_disk() ensuring the worker
either gets a valid reference or sees NULL and exits early.
Also change flush_work() to cancel_work_sync() to avoid running the
partition scan work unnecessarily when the disk is already detached.
Fixes: 7fc4da6a304b ("ublk: scan partition in async way")
Reported-by: Ruikai Peng <ruikai@pwno.io>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
|
|
Since commit 98e48cd9283d ("regulator: core: resolve supply for
boot-on/always-on regulators"), the regulator core returns
-EPROBE_DEFER if a supply can not be resolved at regulator_register()
time due to set_machine_constraints() requiring that supply (e.g.
because of always-on or boot-on).
In some hardware designs, multiple PMICs are used where individual
rails of each act as supplies for rails of the other, and vice-versa.
In such a design no PMIC driver can probe when registering one top-
level regulator device (as is common practice for almost all regulator
drivers in Linux) since that commit. Supplies are only considered when
their driver has fully bound, but because in a design like the above
two drivers / devices depend on each other, neither will have fully
bound while the other probes. The Google Pixel 6 and 6 Pro (oriole and
raven) are examples of such a design.
One way to make this work would be to register each rail as an
individual device, rather than just one top-level regulator device.
Then, fw-devlink and Linux' driver core could do their usual handling
of deferred device probe as each rail would be probed individually.
This approach was dismissed in [1] as each regulator driver would have
to take care of this itself.
Alternatively, we can change the regulator core to not fail
regulator_register() if a rail's required supply can not be resolved
while keeping the intended change from above mentioned commit, and
instead retry whenever a new rail is registered. This commit implements
such an approach:
If set_machine_constraints() requests probe deferral,
regulator_register() still succeeds and we retry setting
constraints as part of regulator_resolve_supply().
We still do not enable the regulator or allow consumers to use it
until constraints have been set (including resolution of the
supply) to prevent enabling of a regulator before its supply.
With this change, we keep track of regulators with missing required
supplies and can therefore try to resolve them again and try to set
the constraints again once more regulators become available.
Care has to be taken to not allow consumers to use regulators that
haven't had their constraints set yet. regulator_get() ensures that
and now returns -EPROBE_DEFER in that case.
The implementation is straight-forward, thanks to our newly introduced
regulator-bus. Locking in regulator_resolve_supply() has to be done
carefully, as a combination of regulator_(un)lock_two() and
regulator_(un)lock_dependent() is needed. The reason is that
set_machine_constraints() might call regulator_enable() which needs
rdev and all its dependents locked, but everything else requires to
only have rdev and its supply locked.
Link: https://lore.kernel.org/all/aRn_-o-vie_QoDXD@sirena.co.uk/ [1]
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-8-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
When a regulator A and its supply B are provided by different devices,
the driver implementing B might be last to probe (with A still
pending resolution of its supply B). While we try to resolve all
pending supplies for all regulators (including A) during
regulator_register() of B via regulator_register_resolve_supply(),
supply resolution will still not work for A as the driver for B hasn't
finished binding to the PMIC device corresponding to B at that stage
yet. The regulator core explicitly only allows supplies from other
devices to be used once the relevant driver has fully bound, mainly to
avoid having to deal with cases where B itself might -EPROBE_DEFER.
In this case, A's supply will only be resolved as part of the core's
regulator_init_complete_work_function(), which currently is scheduled
to run after 30s. This was added as a work-around in
commit 3827b64dba27 ("regulator: core: Resolve supplies before
disabling unused regulators") to cover this situation.
There are two problems with that approach:
* it potentially runs long after all our consumers have probed
* an upcoming change will allow regulator_register() to complete
successfully even when required supplies (e.g. due to always-on or
boot-on) are missing at register time, deferring full configuration
of the regulator (and usability by consumers, i.e. usually consumer
probe) until the supply becomes available.
Resolving supplies in the late work func can therefore make it
impossible for consumers to probe at all, as the driver core will not
know to reprobe consumers when supplies have resolved.
We could schedule an earlier work to try to resolve supplies sooner,
but that'd be racy as consumers of A might try to probe before A's
supply gets fully resolved via this extra work.
Instead, add a very simple regulator bus and add a dummy device with a
corresponding driver to it for each regulator that is missing its
supply during regulator_register(). This way, the driver core will call
our bus' probe whenever a new (regulator) device was successfully
bound, allowing us to retry resolving the supply during (our bus) probe
and to bind this dummy device if successful. In turn this means the
driver core will see a newly bound device and retry probing of all
pending consumers, if any.
With that in place, we can avoid walking the full list of all known
regulators to try resolve missing supplies during regulator_register(),
as the driver core will invoke the bus probe for regulators that are
still pending their supplies. We can also drop the code trying to
resolve supplies one last time before unused regulators get disabled,
as all supplies should have resolved at that point in time, and if they
haven't then there's no point in trying again, as the outcome won't
change.
Note: We can not reuse the existing struct device created for each
rail, as a device can not be part of a class and a bus simultaneously.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-7-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Receiving and forwarding critical supply events seems like they're
important information and we shouldn't ignore errors occurring during
registration for such events.
With this change the supply is unset on event registration failure,
allowing us to potentially retry another time.
Fixes: 433e294c3c5b ("regulator: core: forward undervoltage events downstream by default")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-6-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Since commit 98e48cd9283d ("regulator: core: resolve supply for
boot-on/always-on regulators") we require that a regulator's supply has
been resolved before enabling the regulator. Furthermore,
regulator_get() also fails if the supply hasn't been resolved yet
(preventing consumers from enabling a regulator without its supply
known). In combination this means that regulator_resolve_supply() now
always runs before the regulator has been enabled via
set_machine_constraints().
The code here was meant to run after enabling the regulator in case the
supply hadn't been resolved at that time and can therefore never
execute anymore since that commit.
Remove it.
No functional change intended.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-5-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
For always-on and boot-on regulators, regulator_register() is currently
trying to anticipate the requirement to resolve a supply early.
Unfortunately, this code executes too early, before we have potentially
updated the regulator's always_on constraint as part of
set_machine_constraints(), causing it to miss cases.
Rather than trying to hack it more, just defer to the outcome of
set_machine_constraints(). The latter returns early (without doing any
regulator initialisation) with -EPROBE_DEFER as of commit 'regulator:
core: move supply check earlier in set_machine_constraints()' and is
therefore safe to call multiple times to determine if supplies need to
be resolved early.
Commit 8a866d527ac0 ("regulator: core: Resolve supply name earlier to
prevent double-init") (later updated by
commit 520fb178212d ("regulator: core: Fix regulator supply
registration with sysfs")) added these tests originally to avoid
calling set_machine_constraints() multiple times to try to avoid
voltage glitches due to all the regulator initialisation happening each
time. This isn't an issue anymore as per above.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-4-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Since commit 98e48cd9283d ("regulator: core: resolve supply for
boot-on/always-on regulators"), set_machine_constraints() can return
-EPROBE_DEFER very late, after it has done a lot of work and
configuration of the regulator.
This means that configuration will happen multiple times for no
benefit in that case. Furthermore, this can lead to timing-dependent
voltage glitches as mentioned e.g. in commit 8a866d527ac0 ("regulator:
core: Resolve supply name earlier to prevent double-init").
We can know that it's going to fail very early, in particular before
going through the complete regulator configuration by moving some code
around a little.
Do so to avoid re-configuring the regulator multiple times, also
avoiding the voltage glitches if we can.
Fixes: 98e48cd9283d ("regulator: core: resolve supply for boot-on/always-on regulators")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-3-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
If late enabling of a supply regulator fails in
regulator_resolve_supply(), the code currently triggers a lockdep
warning:
WARNING: drivers/regulator/core.c:2649 at _regulator_put+0x80/0xa0, CPU#6: kworker/u32:4/596
...
Call trace:
_regulator_put+0x80/0xa0 (P)
regulator_resolve_supply+0x7cc/0xbe0
regulator_register_resolve_supply+0x28/0xb8
as the regulator_list_mutex must be held when calling _regulator_put().
To solve this, simply switch to using regulator_put().
While at it, we should also make sure that no concurrent access happens
to our rdev while we clear out the supply pointer. Add appropriate
locking to ensure that.
While the code in question will be removed altogether in a follow-up
commit, I believe it is still beneficial to have this corrected before
removal for future reference.
Fixes: 36a1f1b6ddc6 ("regulator: core: Fix memory leak in regulator_resolve_supply()")
Fixes: 8e5356a73604 ("regulator: core: Clear the supply pointer if enabling fails")
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-2-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
1)
In print_constraints_debug(), the power budget is printed as:
lldo2: 450 <--> 1300 mV at 900 mV 2147483647 mW budge, enabled
(note the missing t in budget). This is because there is a --count just
below the call to scnprintf(), to make space for the comma. All similar
calls to scnprintf() above add an extra space to the format string to
allow for that, but this one doesn't, so the last character t is
stripped instead. Update the format string to fix the message.
2)
Add the name of the supply to the failure message printed when the
supply can not be resolved when debug messages are enabled to help with
debug.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260109-regulators-defer-v2-1-1a25dc968e60@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Discovering a phandle to an AST2400 or AST2600 LPC node indicates an
error for the purpose of the AST2500 pinctrl driver.
Signed-off-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Linus Walleij <linusw@kernel.org>
|
|
The AM62P and the J722S features the same BXS-4 GPU as the J721S2. Add a
new SoC specific compatible.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Matt Coster <matt.coster@imgtec.com>
Link: https://patch.msgid.link/20251223124729.2482877-2-mwalle@kernel.org
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
|
|
The Secondary Sample Point Source field has been
set to an incorrect value by some mistake in the
past
0b01 - SSP_SRC_NO_SSP - SSP is not used.
for data bitrates above 1 MBit/s. The correct/default
value already used for lower bitrates is
0b00 - SSP_SRC_MEAS_N_OFFSET - SSP position = TRV_DELAY
(Measured Transmitter delay) + SSP_OFFSET.
The related configuration register structure is described
in section 3.1.46 SSP_CFG of the CTU CAN FD
IP CORE Datasheet.
The analysis leading to the proper configuration
is described in section 2.8.3 Secondary sampling point
of the datasheet.
The change has been tested on AMD/Xilinx Zynq
with the next CTU CN FD IP core versions:
- 2.6 aka master in the "integration with Zynq-7000 system" test
6.12.43-rt12+ #1 SMP PREEMPT_RT kernel with CTU CAN FD git
driver (change already included in the driver repo)
- older 2.5 snapshot with mainline kernels with this patch
applied locally in the multiple CAN latency tester nightly runs
6.18.0-rc4-rt3-dut #1 SMP PREEMPT_RT
6.19.0-rc3-dut
The logs, the datasheet and sources are available at
https://canbus.pages.fel.cvut.cz/
Signed-off-by: Ondrej Ille <ondrej.ille@gmail.com>
Signed-off-by: Pavel Pisa <pisa@fel.cvut.cz>
Link: https://patch.msgid.link/20260105111620.16580-1-pisa@fel.cvut.cz
Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.")
Cc: stable@vger.kernel.org
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
|
|
Add the MAINTAINERS entries for the Axiado SPI DB controller.
Acked-by: Tzu-Hao Wei <twei@axiado.com>
Co-developed-by: Prasad Bolisetty <pbolisetty@axiado.com>
Signed-off-by: Prasad Bolisetty <pbolisetty@axiado.com>
Signed-off-by: Vladimir Moravcevic <vmoravcevic@axiado.com>
Link: https://patch.msgid.link/20260107-axiado-ax3000-soc-spi-db-controller-driver-v3-3-726e70cf19ad@axiado.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The Axiado SPI controller is present in AX3000 SoC and Evaluation Board.
This controller is operating in Host only mode.
Co-developed-by: Prasad Bolisetty <pbolisetty@axiado.com>
Signed-off-by: Prasad Bolisetty <pbolisetty@axiado.com>
Signed-off-by: Vladimir Moravcevic <vmoravcevic@axiado.com>
Link: https://patch.msgid.link/20260107-axiado-ax3000-soc-spi-db-controller-driver-v3-2-726e70cf19ad@axiado.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add documentation for Axiado Digital Block SPI controller.
Co-developed-by: Prasad Bolisetty <pbolisetty@axiado.com>
Signed-off-by: Prasad Bolisetty <pbolisetty@axiado.com>
Signed-off-by: Vladimir Moravcevic <vmoravcevic@axiado.com>
Link: https://patch.msgid.link/20260107-axiado-ax3000-soc-spi-db-controller-driver-v3-1-726e70cf19ad@axiado.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Various boards that use the rt5640 audio codec define a 'port' child
node under the codec node to describe the interface between it and the
SoC that it is connected to. The binding document for the rt5640 codec
does not define the 'port' child node and so this is generating warnings
when running the DTB checks for these boards. Add the 'port' node to the
binding document for the rt5640 codec to fix this.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260108143158.351223-4-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The device-tree property 'realtek,jack-detect-source' currently only
permits values from 0-6. However, commit 2b9c8d2b3c89 ("ASoC: rt5640:
Add the HDA header support") updated the Realtek rt5640 to support
setting the 'realtek,jack-detect-source' to 7 to support the HDA header.
The Tegra234 platforms currently set 'realtek,jack-detect-source' to 7
for the HDA header and this is causing a warning when building
device-tree.
audio-codec@1c (realtek,rt5640): realtek,jack-detect-source:
7 is not one of [0, 1, 2, 3, 4, 5, 6]
Given that the driver already supports this settings, update the binding
document for the rt5640 device to add the HDA header as a valid
configuration for the 'realtek,jack-detect-source' property.
Fixes: 2b9c8d2b3c89 ("ASoC: rt5640: Add the HDA header support")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260108143158.351223-3-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Commit eba5a0bac211 ("ASoC: dt-bindings: realtek,rt5640: Convert to
dtschema") converted the rt5640 dt-binding to yaml format but in the
process dropped 'clock' and 'clock-names' properties that are used to
specify the codec 'mclk'. This is causing DTB build warnings for boards
that use this codec and define an 'mclk' in device-tree. Update the
rt5640 binding document to add the optional mclk.
Fixes: eba5a0bac211 ("ASoC: dt-bindings: realtek,rt5640: Convert to dtschema")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260108143158.351223-2-jonathanh@nvidia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
sched_mm_cid_after_execve() is called in bprm_execve()'s cleanup path even
when exec_binprm() fails. For the init task's first execve(), this causes a
problem:
1. current->mm is NULL (kernel threads don't have an mm)
2. sched_mm_cid_before_execve() exits early because mm is NULL
3. exec_binprm() fails (e.g., ENOENT for missing script interpreter)
4. sched_mm_cid_after_execve() is called with mm still NULL
5. sched_mm_cid_fork() is called unconditionally, triggering WARN_ON
This is easily reproduced by booting with an init that is a shell script
(#!/bin/sh) where the interpreter doesn't exist in the initramfs.
Fix this by checking if t->mm is NULL before calling sched_mm_cid_fork(),
matching the behavior of sched_mm_cid_before_execve() which already
handles this case via sched_mm_cid_exit()'s early return.
Fixes: b0c3d51b54f8 ("sched/mmcid: Provide precomputed maximal value")
Signed-off-by: Cong Wang <cwang@multikernel.io>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://patch.msgid.link/20251223215113.639686-1-xiyou.wangcong@gmail.com
|
|
Free the "nmp" allocation before returning -EINVAL.
Fixes: dc68c0f60169 ("xfs: fix the zoned RT growfs check for zone alignment")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Carlos Maiolino <cem@kernel.org>
|
|
drm_gem_object_lookup_at_offset() can return a valid object with
filp or filp->f_op->get_unmapped_area set to NULL. Make sure we still
release the ref we acquired on such objects.
Cc: Loïc Molinari <loic.molinari@collabora.com>
Fixes: 99bda20d6d4c ("drm/gem: Introduce drm_gem_get_unmapped_area() fop")
Reviewed-by: Loïc Molinari <loic.molinari@collabora.com>
Link: https://patch.msgid.link/20260106164935.409765-1-boris.brezillon@collabora.com
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
|
|
Switch SD0 write-protect detection to a GPIO on the RZ/T2H and RZ/N2H
EVKs. Both boards use a full-size SD card slot on the SD0 channel with
a dedicated WP pin.
The RZ/T2H and RZ/N2H SoCs use of_data_rcar_gen3, which sets
MMC_CAP2_NO_WRITE_PROTECT and causes the core to ignore the WP signal
unless a wp-gpios property is provided. Describe the WP pin as a GPIO
to allow the MMC core to evaluate the write-protect status correctly.
Fixes: d065453e5ee0 ("arm64: dts: renesas: rzt2h-rzn2h-evk: Enable SD card slot")
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20260106131319.643084-1-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add CANFD node to RZ/V2H(P) ("R9A09G057") SoC DTSI.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251224175204.3400062-7-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add CANFD node to RZ/V2N ("R9A09G056") SoC DTSI.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251224175204.3400062-6-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Enable CANFD channel 1, which is available on the CN35 connector.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251224175204.3400062-5-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Enable CANFD channel 0, which is available on the CN55 connector.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251224175204.3400062-4-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add support for the CANFD controller on the Renesas RZ/N2H Soc.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251224175204.3400062-3-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Add support for the CANFD controller on the Renesas RZ/T2H Soc.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20251224175204.3400062-2-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Renesas RZ/T2H and RZ/N2H PCLKCAN Clock DT Binding Definitions
PCLKCAN Clock DT binding definitions for the Renesas RZ/T2H (R9A09G077)
and RZ/N2H (R9A09G087) SoCs, shared by driver and DT source files.
|
|
In order to support inline helpers [1], we need to have __rust_helper
defined for all helper files. Current we are lucky that atomic.c is the
first file in helpers.c, but this is fragile. Thus, move it to
helpers.c.
[boqun: Reword the commit message and apply file hash changes]
Link: https://lore.kernel.org/r/20260105-define-rust-helper-v2-0-51da5f454a67@google.com [1]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260107-move-rust_helper-define-v1-1-4109d58ef275@google.com
|
|
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-25-51da5f454a67@google.com
|
|
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-22-51da5f454a67@google.com
|
|
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-21-51da5f454a67@google.com
|
|
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-20-51da5f454a67@google.com
|
|
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-17-51da5f454a67@google.com
|
|
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Joel Fernandes (NVIDIA) <joel@joelfernandes.org>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-16-51da5f454a67@google.com
|
|
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-13-51da5f454a67@google.com
|
|
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-6-51da5f454a67@google.com
|
|
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-5-51da5f454a67@google.com
|
|
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-2-51da5f454a67@google.com
|
|
This is needed to inline these helpers into Rust code.
Reviewed-by: Boqun Feng <boqun.feng@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260105-define-rust-helper-v2-1-51da5f454a67@google.com
|
|
Convert uses of AtomicBool, AtomicUsize, and AtomicU32.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Acked-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20251230093718.1852322-4-fujita.tomonori@gmail.com
|
|
Convert uses of `AtomicBool` to `Atomic<bool>`.
Note that the compare_exchange migration simplifies to
`try_cmpxchg()`, since `try_cmpxchg()` provides relaxed ordering on
failure, making the explicit failure ordering unnecessary.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20251230093718.1852322-3-fujita.tomonori@gmail.com
|
|
Add tests for Atomic<bool> operations.
Atomic<bool> does not fit into the existing u8/16/32/64 tests so
introduce a dedicated test for it.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260101034922.2020334-3-fujita.tomonori@gmail.com
|
|
Add `bool` support, `Atomic<bool>` by using `i8` as its underlying
representation.
Rust specifies that `bool` has size 1 and alignment 1 [1], so it
matches `i8` on layout; keep `static_assert!()` checks to enforce this
assumption at build time.
[boqun: Remove the unnecessary impl AtomicImpl for bool]
Link: https://doc.rust-lang.org/reference/types/boolean.html [1]
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20260101034922.2020334-2-fujita.tomonori@gmail.com
|
|
Add atomic xchg and cmpxchg operation support for i8 and i16 types
with tests.
Note that since the current implementation of
Atomic::<{i8,i16}>::{load,store}() is READ_ONCE()/WRITE_ONCE()-based.
The atomicity between load/store and xchg/cmpxchg is only guaranteed if
the architecture has native RmW support, hence i8/i16 is currently
AtomicImpl only when CONFIG_ARCH_SUPPORTS_ATOMIC_RWM=y.
[boqun: Make i8/i16 AtomicImpl only when
CONFIG_ARCH_SUPPORTS_ATOMIC_RWM=y]
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20251228120546.1602275-4-fujita.tomonori@gmail.com
|
|
Add minimum store_release/load_acquire tests.
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20251211113826.1299077-5-fujita.tomonori@gmail.com
|
|
Add atomic operation support for i8 and i16 types using volatile
read/write and smp_load_acquire/smp_store_release helpers.
[boqun: Adjust [1] to avoid introduction of
impl_atomic_only_load_and_store_ops!() in the middle]
Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Reviewed-by: Joel Fernandes <joelagnelf@nvidia.com>
Link: https://lore.kernel.org/all/20251228120546.1602275-1-fujita.tomonori@gmail.com/ [1]
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Link: https://patch.msgid.link/20251211113826.1299077-4-fujita.tomonori@gmail.com
|
