A MCC (multi-channel concurrency) schedule is like the following.
|< mcc interval >|
|< duration ref >|< duration aux >|
|< tob ref >|< toa ref >|< tob aux >|< toa aux >|
V V
tbtt ref tbtt aux
|< beacon offset >|
Original logic might unexpectedly calculate toa (time offset ahead) of
auxiliary role to be negative even when there is no role timing limit.
If toa-aux is negative, TBTT-aux would in logic fall into duration-ref.
Then, if auxiliary role is GO unfortunately, it cannot guarantee that
beacons will TX well. So now, when deciding the lower bound of toa-ref,
take toa-aux into account. Make toa-aux at least be zero in normal cases.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-13-pkshih@realtek.com
Since tob (time offset behind) could be negative, change the type of tob in
microsecond to s32. And, refine accumulation with while-loop by calculation
with roundup_u64(). Besides, as long as one of the MCC roles is GO, use the
short MCC start time.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-12-pkshih@realtek.com
MCC has a courtesy mechanism which allows one role to use another's
duration in a given cycle. Originally, this courtesy mechanism only
supports in one direction. However, in some field cases, both of MCC
roles may simultaneously have timing configurations that are not good
enough. So, support courtesy mechanism in both directions.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-11-pkshih@realtek.com
MCC has a courtesy mechanism which allows one role to use another's
duration in a given cycle. Courtesy mechanism will be enabled when
one role has a not perfect duration. Otherwise, not. When MCC updates,
duration of each role will be re-calculated. And then, the new courtesy
config might be different from the old one. However, to change courtesy
config, the entire MCC plan requires to be renewed when MCC updates.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-10-pkshih@realtek.com
MCC will limit the time a role can use in a schedule according to the
periodic NoA. Original logic didn't consider the case where NoA start
time has passed. It might lead to inaccurate result. So, tweak it.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-9-pkshih@realtek.com
There are two roles during MCC and the offset between their TBTT is called
beacon offset. Originally, when MCC runs GO+STA mode, it used fixed beacon
offset to simplify some logic because GO role can master its TSF. However,
if MCC is stopped and restarted before a same GO is down, its TSF might be
discontinuous. Then, there might be undefined behavior happens in GC sides.
So, to let a same GO have a continuous TSF, MCC no longer changes its TSF
to meet a fixed beacon offset. Instead, GO+STA mode also calculates beacon
offset dynamically as what GC+STA mode did.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-8-pkshih@realtek.com
When APs or GOs are up, their TSF start point are randomized to avoid
collisions. However, the TSF of an existing AP/GO would be randomized
multiple times. It caused the TSF is discontinuous to the corresponding
STA/GC sides. So, once TSF has been randomized, don't re-randomize it
unless SER (system error recovery) happens unfortunately.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-7-pkshih@realtek.com
Since FW cannot handle HW scan process and MCC (multi-channel concurrency)
mode simultaneously, if a HW scan is requested during MCC, MCC mode will be
paused temporarily. Then, the GO role if any might be absent. So, calculate
an estimated time for the requested HW scan process and search for existing
GO roles to fill one-time NoA.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-6-pkshih@realtek.com
FW has a limited amount of channels that can be dealt with by one HW scan
H2C command. Based on the limit, channels in scan request might be parsed
into SW structure piece by piece along with multiple HW scan H2C commands.
But, in order to estimate things of entire HW scan process, it's required
to have the whole parsed channel list when HW scan is going to start. So,
tweak HW scan flow to prepare the whole channel list ahead. Still, each HW
scan H2C command takes allowed amount of channels from the list according
to the limit.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-5-pkshih@realtek.com
These stuffs have no suffix, but not universal, and only work for Wi-Fi 6.
Since the corresponding HW scan struct/func of Wi-Fi 7 have suffix "_be",
to avoid misunderstanding and improve readability, also add suffix "_ax"
to these Wi-Fi 6 stuffs.
(No logic is changed.)
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-4-pkshih@realtek.com
A new ACPI table entry format for TAS is defined, which includes
a "specific country" field. In this field, determine which
country can enable TAS.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-3-pkshih@realtek.com
Intermittent beacon loss from specific AP triggers disconnection
and reconnection. Increasing the beacon loss count will make the
connection more stable.
Signed-off-by: Kuan-Chung Chen <damon.chen@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-2-pkshih@realtek.com
This adds all the pin mappings on the WiFi/BT header on
the SOPINE Baseboard/A64-LTS. They're disabled by default
as the modules don't ship by default. This includes, where
they haven't been already, UART1 for BT and mmc1 for WiFi.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Link: https://patch.msgid.link/20250420094823.954073-3-pbrobinson@gmail.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
This adds all the pin mappings on the WiFi/BT header on
the original Pine64. They're disabled by default as the
modules don't ship by default. This includes, where they
haven't been already, UART1 for BT and mmc1 for WiFi.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Link: https://patch.msgid.link/20250420094823.954073-2-pbrobinson@gmail.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
According to https://radxa.com/products/cubie/a5e,
the name of this board should be "Radxa Cubie A5E".
This is also consistent with the dt-bindings.
Fixes: 80e0fb4e491b ("arm64: dts: allwinner: a523: add Radxa A5E support")
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Link: https://patch.msgid.link/20250416100006.82920-1-amadeus@jmu.edu.cn
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Since commit 3c3606793f ("dt-bindings: wireless: bcm4329-fmac: Use
wireless-controller.yaml schema"), bindings expect 'wifi' as node name:
sun8i-h3-nanopi-neo-air.dtb: bcrmf@1: $nodename:0: 'bcrmf@1' does not match '^wifi(@.*)?$'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250424084737.105215-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Since commit 3c3606793f ("dt-bindings: wireless: bcm4329-fmac: Use
wireless-controller.yaml schema"), bindings expect 'wifi' as node name:
sun50i-h6-orangepi-3.dtb: sdio-wifi@1: $nodename:0: 'sdio-wifi@1' does not match '^wifi(@.*)?$'
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250424084737.105215-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
All Allwinner H616/H618 SoCs contain a Mali G31 MP2 GPU.
Enable the DT nodes for that GPU, and specify the regulator providing
power to the VDD_GPU pins of the package. The rest of the DT node is set
by the SoC, so is not board specific.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250416224839.9840-5-andre.przywara@arm.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Allwinner H616 SoC contains a Mali-G31 MP2 GPU, which is of the Mali
Bifrost family. There is a power domain specifically for that GPU, which
needs to be enabled to make use of the it.
Add the DT nodes for those two devices, and link them together through
the "power-domains" property.
Any board wishing to use the GPU would need to enable the GPU node and
specify the "mali-supply" regulator.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250416224839.9840-4-andre.przywara@arm.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Add support for headphone insertion detection via GPIO for the
RG35XX series, and add the corresponding routing to the codec node.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Signed-off-by: Ryan Walklin <ryan@testtoast.com>
Tested-by: Philippe Simons <simons.philippe@gmail.com>
--
Changelog v1..v2:
- Remove vendor prefix from GPIO description.
- Whitespace fix
Changelog v2..v3:
- Add Tested-by tag
Link: https://patch.msgid.link/20250214220247.10810-5-ryan@testtoast.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
'clock-latency-ns' is not a valid property for CPU nodes. It belongs in
OPP table (which has it). Drop them from the CPU nodes.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250410-dt-cpu-schema-v2-1-63d7dc9ddd0a@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The preferred node name for cooling map nodes is a 'map' prefix. Use
'map0' like most other platforms.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250409203613.1506047-1-robh@kernel.org
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The Chameleon board is an OpenHardware devboard made by YuzukiTsuru.
The form factor resembles the Raspberry Pi Model A boards, though it
differs significantly in its features:
- Allwinner H618 SoC (4 * Arm Cortex-A53 cores, 1MB L2 cache, 1.4 GHz)
- between 512MiB and 2GiB DDR3 DRAM
- up to 128 GiB eMMC flash
- AXP313a PMIC
- 100 Mbit/s Ethernet pins on a header
- XR829 WIFI+Bluetooth chip
- 4 * USB 2.0 USB-C ports
- microSD card slot
- 3.5mm A/V port
Add the devicetree describing the board's peripherals and their
connections.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250307005712.16828-16-andre.przywara@arm.com
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
In nfs3_get_acl(), the local variable status is assigned the result of
nfs_refresh_inode() inside the *switch* statement, but that value gets
overwritten in the next *if* statement's true branch and is completely
ignored if that branch isn't taken...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
Link: https://lore.kernel.org/r/c32dced7-a4fa-43c0-aafe-ef6c819c2f91@omp.ru
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
In nfs_direct_write_completion(), the local variable req isn't used outside
the *while* loop and is assigned to right at the start of that loop's body,
so its initializer appears useless -- drop it; then move the declaration to
the loop body (which happens to have a pointless empty line anyway)...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
Link: https://lore.kernel.org/r/416219f5-7983-484b-b5a7-5fb7da9561f7@omp.ru
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Since struct nfs4_pnfs_ds should not be shared between net namespaces,
move from a global list of objects to a per-netns list and spinlock.
Tested-by: Sargun Dillon <sargun@sargun.me>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
Link: https://lore.kernel.org/r/20250410-nfs-ds-netns-v2-2-f80b7979ba80@kernel.org
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Currently, different NFS clients can share the same DS connections, even
when they are in different net namespaces. If a containerized client
creates a DS connection, another container can find and use it. When the
first client exits, the connection will close which can lead to stalls
in other clients.
Add a net namespace pointer to struct nfs4_pnfs_ds, and compare those
value to the caller's netns in _data_server_lookup_locked() when
searching for a nfs4_pnfs_ds to match.
Reported-by: Omar Sandoval <osandov@osandov.com>
Reported-by: Sargun Dillon <sargun@sargun.me>
Closes: https://lore.kernel.org/linux-nfs/Z_ArpQC_vREh_hEA@telecaster/
Tested-by: Sargun Dillon <sargun@sargun.me>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Benjamin Coddington <bcodding@redhat.com>
Link: https://lore.kernel.org/r/20250410-nfs-ds-netns-v2-1-f80b7979ba80@kernel.org
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
When debugging I/O issues, we want to see not just the NFS level errors,
but also the RPC level problems, so record both in the tracepoints.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
If we have a fatal ENETDOWN or ENETUNREACH error, then the layoutreturn
on close code should also handle that as fatal, and free the layouts.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Ensure that the NFSv4 error handling code recognises the
RPC_TASK_NETUNREACH_FATAL flag, and handles the ENETDOWN and ENETUNREACH
errors accordingly.
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
The Radxa A5E is a development board using the Allwinner A527 SoC, which
is using the same die as the A523 SoC, just exposing the pins of more
peripherals (like HDMI or the 2nd MAC). The board features:
- Allwinner A527/T527 SoC: 8 ARM Cortex-A55 cores, Mali-G57 MC1 GPU
- 1GiB/2GiB/4GiB LPDDR4 DRAM
- AXP717 + AXP323 PMICs
- Raspberry-Pi-2 compatible 40pin GPIO header
- 1 USB 2.0 type C port (OTG), also power supply
- 1 USB 3.0 type A host port (multiplexed with M.2 slot)
- 1 M.2 M-key 2230 slot, with 1 PCIe2.1 lane connected (multiplexed
with USB 3.0 port)
- MicroSD slot
- optional eMMC, 8, 16 or 32GB available
- optional on-board 16MiB bootable SPI NOR flash
- two 1Gbps Ethernet ports (via MAXIO MAE0621A PHYs)
- PoE header for optional supply circuit on one Ethernet port
- WiFi 802.11 a/b/g/n/ac/ax (LB-Link BL-M8800DS2 module using AIC8800)
- HDMI port
- camera and LCD connectors
- power supply via USB-C connector (but no PD) or GPIO header pins
This .dts describes the devices as far as we support them at the moment.
The PMIC rails have been assigned as per the schematics.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patch.msgid.link/20250307005712.16828-14-andre.przywara@arm.com
[wens@csie.org: Squash in SD card detect pull resistor fix]
Link: https://patch.msgid.link/20250425003422.3465-1-andre.przywara@arm.com
[wens@csie.org: Rename dts file to sun55i-a527-cubie-a5e.dts]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The force_alloc flag was removed from TTM / Xe but updating the
selftests to new function interfaces was missed. Remove argument from
xe_bo_evict in selftests.
v2:
- Fix dma-buf, migrate selftests (CI)
Fixes: 55df7c0c62 ("drm/ttm/xe: drop unused force_alloc flag")
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: https://lore.kernel.org/r/20250428022318.877860-1-matthew.brost@intel.com
'struct chg_map' is not modified in this driver.
Constifying these structures moves some data to a read-only section, so
increase overall security.
While at it, also constify a few other arrays.
On a x86_64, with allmodconfig, as an example:
Before:
======
text data bss dec hex filename
14263 1744 0 16007 3e87 drivers/power/supply/wm831x_power.o
After:
=====
text data bss dec hex filename
14695 1288 0 15983 3e6f drivers/power/supply/wm831x_power.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/0edde57b691db7f920d121fdbd5ebc3fb24f30f1.1743787625.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The BQ24193 is most similar to the BQ24192. This is used in many Nvidia
Tegra devices such as the SHIELD Portable. This variant works as-is with
the existing BQ24192 code, but cannot be probed with a simple fallback
compatible to ti,bq24192. So add it same as how BQ24196 is handled.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Link: https://lore.kernel.org/r/20250421-bq24193-v1-2-f125ef396d24@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
The BQ24193 is most similar to the BQ24192. This is used in many Nvidia
Tegra devices such as the SHIELD Portable.
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250421-bq24193-v1-1-f125ef396d24@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
GCC 15's new -Wunterminated-string-initialization notices that one of
the sysfs attr strings would lack the implicit trailing NUL byte during
initialization:
drivers/power/supply/power_supply_sysfs.c:183:57: warning: initializer-string for array of 'char' truncates NUL terminator but destination lacks 'nonstring' attribute (32 chars into 31 available) [-Wunterminated-string-initialization]
183 | POWER_SUPPLY_ATTR(CHARGE_CONTROL_START_THRESHOLD),
| ^
drivers/power/supply/power_supply_sysfs.c:36:23: note: in definition of macro '_POWER_SUPPLY_ATTR'
36 | .attr_name = #_name "\0", \
| ^~~~~
drivers/power/supply/power_supply_sysfs.c:183:9: note: in expansion of macro 'POWER_SUPPLY_ATTR'
183 | POWER_SUPPLY_ATTR(CHARGE_CONTROL_START_THRESHOLD),
| ^~~~~~~~~~~~~~~~~
However, the macro used was explicitly adding a trailing NUL byte (which
is not needed). Remove this to avoid the GCC warning. No binary
differences are seen after this change (there was always run for a NUL
byte, it's just that the _second_ NUL byte was getting truncated).
Signed-off-by: Kees Cook <kees@kernel.org>
Link: https://lore.kernel.org/r/20250416222740.work.569-kees@kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Multiple applications may access the battery gauge at the same time, so
the gauge may be busy and EBUSY will be returned. The driver will set a
flag to record the EBUSY state, and this flag will be kept until the next
periodic update. When this flag is set, bq27xxx_battery_get_property()
will just return ENODEV until the flag is updated.
Even if the gauge was busy during the last accessing attempt, returning
ENODEV is not ideal, and can cause confusion in the applications layer.
Instead, retry accessing the I2C to update the flag is as expected, for
the gauge typically recovers from busy state within a few milliseconds.
If still failed to access the gauge, the real error code would be returned
instead of ENODEV (as suggested by Pali Rohár).
Reviewed-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Jerry Lv <Jerry.Lv@axis.com>
Link: https://lore.kernel.org/r/20250415-foo-fix-v2-1-5b45a395e4cc@axis.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
DTS example in the bindings should be indented with 2- or 4-spaces and
aligned with opening '- |'. Correct mixtures of the style or any other
indentations to use preferred 4-spaces.
No functional changes here, but saves some comments during reviews
of new patches built on the existing code.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250318081428.33979-1-krzysztof.kozlowski@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This driver's purpose is to parse boot modes described in DT, via key
(node name) / value pairs, and to match them to a reboot mode requested
by the kernel. Unfortunately, DT node names can not contain certain
characters, like space ' ' or comma ',' or slash '/', while the
requested reboot mode may.
This is a problem because it makes it impossible to match reboot modes
containing any of those characters.
For example, this makes it impossible to communicate DM verity errors
to the boot loader - DM verity errors trigger a reboot with mode
"dm-verity device corrupted" in drivers/md/dm-verity-target.c and
devices typically have to take action in that case [1]. Changing this
string itself is not feasible, see e.g. discussion in [2], but would
also just cover this one case.
Another example is Android, which may use comma in the reboot mode
string, e.g. as "shutdown,thermal" in [3].
The kernel also shouldn't prescribe what characters are allowed inside
the boot mode string for a user to set. It hasn't done this so far, and
introducing such a restriction would be an interface break and
arbitrarily enforce a random new policy.
Therefore, update this driver to do another round of string matching,
after replacing the common characters mentioned above with dash '-', if
a match hasn't been found without doing said replacement.
This now allows us to have DT entries of e.g.:
mode-dm-verity-device-corrupted = <...>
and so on.
Link: https://cs.android.com/android/kernel/superproject/+/android14-gs-pixel-6.1:private/google-modules/power/reset/exynos-gs101-reboot.c;l=144 [1]
Link: https://lore.kernel.org/all/CAAFS_9FuSb7PZwQ2itUh_H7ZdhvAEiiX7fhxJ4kmmv9JCaHmkA@mail.gmail.com/ [2]
Link: https://cs.android.com/android/platform/superproject/main/+/main:system/core/init/reboot_utils.cpp;drc=79ad1e2e9bf1628c141c8cd2fbb4f3df61a6ba75;l=122 [3]
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Link: https://lore.kernel.org/r/20250307-reboot-mode-chars-v1-1-d83ff95da524@linaro.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
This patch adds a small optimization to the low-level at91_reset()
function, which includes:
- Removes the extra branch, since the following store operations
already have proper condition checks.
- Removes the definition of the clobber register r4, since it is
no longer used in the code.
Fixes: fcd0532fac ("power: reset: at91-reset: make at91sam9g45_restart() generic")
Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20250307053809.20245-1-eagle.alexander923@gmail.com
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Register compatible and cmu_info data to support clock CPUCL0(CPU
Cluster 0), this provides clock for CPUCL0_SWTICH/DBG/CLUSTER. These
clocks are required early during boot for the CPUs, so they are declared
using CLK_OF_DECLARE instead of being registered through a platform
driver.
Signed-off-by: Shin Son <shin.son@samsung.com>
Link: https://lore.kernel.org/r/20250423044153.1288077-3-shin.son@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Add cpucl0 clock definitions.
CPUCL0 refers to CPU Cluster 0, which provide clock support
for the CPUs on Exynosauto V920 SoC.
Signed-off-by: Shin Son <shin.son@samsung.com>
Link: https://lore.kernel.org/r/20250423044153.1288077-2-shin.son@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
The client mask has been reduced from 8 bits on V3D 4.1 to 7 bits
on V3D 7.1, so the ranges for each client are not compatible.
On V3D 7.1, the CSD client can also report MMU errors.
Therefore, add its AXI ID to the IDs list.
Fixes: 0ad5bc1ce4 ("drm/v3d: fix up register addresses for V3D 7.x")
Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Link: https://lore.kernel.org/r/20250425122522.18425-2-jmcasanova@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
In the case of MMU errors caused by the TFU unit, the
client that causes the MMU error is expected to be reported.
But in the case of MMU TFU errors, a non existing client was
being reported. This happened because the client calculation
was taking into account more than the bits 0-7 from the
axi_id that were representing the client.
[ 27.845132] v3d fec00000.v3d: MMU error from client ? (13) at 0x3bb1000, pte invalid
Masking the bits and using the correct axi_id ranges fixes the
calculation to report the real guilty client on V3D 4.1 and 4.2.
Make the MMU error print axi_id with hexadecimal as used in the
ranges.
Fixes: 38c2c7917a ("drm/v3d: Fix and extend MMU error handling.")
Signed-off-by: Jose Maria Casanova Crespo <jmcasanova@igalia.com>
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Link: https://lore.kernel.org/r/20250425122522.18425-1-jmcasanova@igalia.com
Signed-off-by: Maíra Canal <mcanal@igalia.com>
