With the introduction of the RK3576, the maximum device function ID used
increased to 14, as anyone can easily verify for themselves with:
rg -g '*-pinctrl.dtsi' '<\d+\s+RK_P..\s+(?<func>\d+)\s.*>;$' --trim \
-NI -r '$func' arch/arm64/boot/dts/rockchip/ | sort -g | uniq
Unfortunately, this wasn't caught by dt-validate as those pins are
omit-if-no-ref and we had no reference to them in any tree so far.
Once again kick the can down the road by increasing the limit to 14.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/20250602-rk3576-pwm-v2-1-a6434b0ce60c@collabora.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
On 32-bit ARCH=um, CONFIG_X86_32 is still defined, so it
doesn't indicate building on real X86 machines. There's
no MSR on UML though, so add a check for CONFIG_X86.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/r/20250606090110.15784-2-johannes@sipsolutions.net
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Commit 1017560164 ("drm/meson: use unsigned long long / Hz for
frequency types") attempts to resolve video playback using 59.94Hz.
using YUV420 by changing the clock calculation to use
Hz instead of kHz (thus yielding more precision).
The basic calculation itself is correct, however the comparisions in
meson_vclk_vic_supported_freq() and meson_vclk_setup() don't work
anymore for 59.94Hz modes (using the freq * 1000 / 1001 logic). For
example, drm/edid specifies a 593407kHz clock for 3840x2160@59.94Hz.
With the mentioend commit we convert this to Hz. Then meson_vclk
tries to find a matchig "params" entry (as the clock setup code
currently only supports specific frequencies) by taking the venc_freq
from the params and calculating the "alt frequency" (used for the
59.94Hz modes) from it, which is:
(594000000Hz * 1000) / 1001 = 593406593Hz
Similar calculation is applied to the phy_freq (TMDS clock), which is 10
times the pixel clock.
Implement a new meson_vclk_freqs_are_matching_param() function whose
purpose is to compare if the requested and calculated frequencies. They
may not match exactly (for the reasons mentioned above). Allow the
clocks to deviate slightly to make the 59.94Hz modes again.
Fixes: 1017560164 ("drm/meson: use unsigned long long / Hz for frequency types")
Reported-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250609202751.962208-1-martin.blumenstingl@googlemail.com
meson_vclk_vic_supported_freq() has a debug print which includes the
pixel freq. However, within the whole function the pixel freq is
irrelevant, other than checking the end of the params array. Switch to
printing the vclk_freq which is being compared / matched against the
inputs to the function to avoid confusion when analyzing error reports
from users.
Fixes: e5fab2ec9c ("drm/meson: vclk: add support for YUV420 setup")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250606221031.3419353-1-martin.blumenstingl@googlemail.com
The "phy" and "vclk" frequency labels were swapped, making it more
difficult to debug driver errors. Swap the label order to make them
match with the actual frequencies printed to correct this.
Fixes: e5fab2ec9c ("drm/meson: vclk: add support for YUV420 setup")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250606203729.3311592-1-martin.blumenstingl@googlemail.com
In some Amlogic SoCs, to save register space or due to some
abnormal arrangements, two sets of pins share one mux register.
A group starting from pin0 is the main pin group, which acquires
the register address through DTS and has management permissions,
but the register bit offset is undetermined.
Another GPIO group as a subordinate group. Some pins mux use share
register and bit offset from bit0 . But this group do not have
register management permissions.
This submission implements this situation.
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Link: https://lore.kernel.org/20250527-s6-s7-pinctrl-v3-3-44f6a0451519@amlogic.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
According to the data specifications of Amlogic's existing SoCs,
the function register offset and the bit offset are the same
value among various chips. Therefore, general processing can
be carried out without the need for private data modification.
Drop special data processing.
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
Link: https://lore.kernel.org/20250527-s6-s7-pinctrl-v3-2-44f6a0451519@amlogic.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add configuration for the 7" Raspberry Pi 720x1280 DSI panel
based on ili9881.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250608142908.54121-3-marek.vasut+renesas@mailbox.org
Not all panels use all 4 data lanes, so allow configuration based
on the compatible string.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250608142908.54121-2-marek.vasut+renesas@mailbox.org
Document the 7" Raspberry Pi 720x1280 DSI panel based on ili9881.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250608142908.54121-1-marek.vasut+renesas@mailbox.org
The Winstar wf40eswaa6mnn0 panel is a square 4.0" TFT LCD with a
resolution of 480x480 pixels.
Signed-off-by: Stefan Eichenberger <eichest@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250606114644.105371-3-eichest@gmail.com
The Winstar wf40eswaa6mnn0 panel is a square 4.0" TFT LCD with a
resolution of 480x480 pixels.
This panel is driven by the Sitronix ST7701 controller and uses a MIPI
DSI interface. The settings are based on the panel's datasheet and the
init sequence provided by Winstar.
It was tested on a Verdin iMX8MP from Toradex with a Carrier Board
providing a MIPI DSI interface.
Signed-off-by: Stefan Eichenberger <eichest@gmail.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250606114644.105371-2-eichest@gmail.com
On at least an ASRock 990FX Extreme 4 with a VIA VT6330, the devices
have not yet been enabled by the first time ata_acpi_cbl_80wire() is
called. This means that the ata_for_each_dev loop is never entered,
and a 40 wire cable is assumed.
The VIA controller on this board does not report the cable in the PCI
config space, thus having to fall back to ACPI even though no SATA
bridge is present.
The _GTM values are correctly reported by the firmware through ACPI,
which has already set up faster transfer modes, but due to the above
the controller is forced down to a maximum of UDMA/33.
Resolve this by modifying ata_acpi_cbl_80wire() to directly return the
cable type. First, an unknown cable is assumed which preserves the mode
set by the firmware, and then on subsequent calls when the devices have
been enabled, an 80 wire cable is correctly detected.
Since the function now directly returns the cable type, it is renamed
to ata_acpi_cbl_pata_type().
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Link: https://lore.kernel.org/r/20250519085945.1399466-1-tasos@tasossah.com
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Add support for another variant of the rm69299 panel. This panel is
1080x2160 and is found in the shift-axolotl (SHIFT6mq).
Signed-off-by: Caleb Connolly <caleb@connolly.tech>
[narmstrong: moved to panel_desc]
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250509-topic-misc-shift6-panel-v2-6-c2c2d52abd51@linaro.org
The controller has a hardware bug that can hard hang the system when
doing ATAPI DMAs without any trace of what happened. Depending on the
device attached, it can also prevent the system from booting.
In this case, the system hangs when reading the ATIP from optical media
with cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and an
Optiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,
running at UDMA/33.
The issue can be reproduced by running the same command with a cygwin
build of cdrecord on WinXP, although it requires more attempts to cause
it. The hang in that case is also resolved by forcing PIO. It doesn't
appear that VIA has produced any drivers for that OS, thus no known
workaround exists.
HDDs attached to the controller do not suffer from any DMA issues.
Cc: stable@vger.kernel.org
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/916677
Signed-off-by: Tasos Sahanidis <tasos@tasossah.com>
Link: https://lore.kernel.org/r/20250519085508.1398701-1-tasos@tasossah.com
Signed-off-by: Niklas Cassel <cassel@kernel.org>
This structure is really too larget to be allocated on the stack:
sound/soc/soc-ops.c:435:5: error: stack frame size (1296) exceeds limit (1280) in 'snd_soc_limit_volume' [-Werror,-Wframe-larger-than]
Change the function to dynamically allocate it instead.
There is probably a better way to do it since only two integer fields
inside of that structure are actually used, but this is the simplest
rework for the moment.
Fixes: 783db6851c ("ASoC: ops: Enforce platform maximum on initial value")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patch.msgid.link/20250610093057.2643233-1-arnd@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently the function that does this takes a struct file_lock, but
__locks_wake_up_blocks() deals with both locks and leases. Currently
this works because both file_lock and file_lease have the file_lock_core
at the beginning of the struct, but it's fragile to rely on that.
Add a new locks_wake_up_waiter() function and call that from
__locks_wake_up_blocks().
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/20250602-filelock-6-16-v1-1-7da5b2c930fd@kernel.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
Rather than have the caller set the FMODE_NOWAIT flags for both output
files, move it to create_pipe_files() where other f_mode flags are set
anyway with stream_open(). With that, both __do_pipe_flags() and
io_pipe() can remove the manual setting of the NOWAIT flags.
No intended functional changes, just a code cleanup.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Link: https://lore.kernel.org/1f0473f8-69f3-4eb1-aa77-3334c6a71d24@kernel.dk
Signed-off-by: Christian Brauner <brauner@kernel.org>
Now that the binding head has been merged, convert the power-domain ids
back to these constants for easier handling.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250510161531.2086706-1-heiko@sntech.de
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add device tree for the Luckfox Omni3576 Carrier Board with Core3576
Module, powered by the Rockchip RK3576 SoC with four Cortex-A72 cores,
four Cortex-A53 cores, and a Mali-G52 MC3 GPU. This initial
implementation enables essential functionality for booting Linux and
basic connectivity.
Supported and tested features:
- UART for serial console
- SD card for storage
- PCIe with NVMe SSD (detected, mounted, and fully functional)
- USB 2.0 host ports
- RK806 PMIC for power management
- RTC with timekeeping and wake-up
- GPIO-controlled LED with heartbeat trigger
- eMMC (enabled, not populated on tested board)
The device tree provides a foundation for further peripheral support, such
as WiFi, MIPI-DSI, HDMI, and Ethernet, in future updates.
Tested on Linux 6.15-rc4
Based on the Luckfox SDK, which derives from Rockchip’s SDK examples, with
relevant changes to align with upstream Linux.
Signed-off-by: John Clark <inindev@gmail.com>
Link: https://lore.kernel.org/r/20250516002713.145026-4-inindev@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add device tree binding for Luckfox Core3576 Module based boards,
specifically the Luckfox Omni3576, with compatibility for the Rockchip
RK3576 SoC.
Signed-off-by: John Clark <inindev@gmail.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Acked-by: "Rob Herring (Arm)" <robh@kernel.org>
Link: https://lore.kernel.org/r/20250516002713.145026-3-inindev@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add vendor prefix for Shenzhen Luckfox Technology Co., Ltd., which
produces development boards like the Luckfox Omni3576.
Signed-off-by: John Clark <inindev@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Link: https://lore.kernel.org/r/20250516002713.145026-2-inindev@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The RK3588 GPU power domain cannot be activated unless the external
power regulator is already on. When GPU support was added to this DT,
we had no way to represent this requirement, so `regulator-always-on`
was added to the `vdd_gpu_s0` regulator in order to ensure stability.
A later patch series (see "Fixes:" commit) resolved this shortcoming,
but that commit left the workaround -- and rendered the comment above
it no longer correct.
Remove the workaround to allow the GPU power regulator to power off, now
that the DT includes the necessary information to power it back on
correctly.
Fixes: f94500eb73 ("arm64: dts: rockchip: Add GPU power domain regulator dependency for RK3588")
Signed-off-by: Sam Edwards <CFSworks@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250608184855.130206-1-CFSworks@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Pine64 touch panel is a panel consisting of the Feiyang fy07024di26a30d
panel with a Goodix gt911 touch screen. Add a device tree overlay to
allow the display to be easily used on the device.
This was previously included in the main device tree but left disabled
by default which still required rebuilding the DT to use the device, now
overlays can go upstream the overlay is the best way to handle the
add on devices.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[added the missing v2 to
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64-v2-screen.dtb
^^
rk3399-rockpro64-v2-screen-dtbs := rk3399-rockpro64-v2.dtb \
rk3399-rockpro64-screen.dtbo
dropped address-cells/size-cells from panel node to fix warning about
rk3399-rockpro64-screen.dtso:69.22-84.4: Warning (avoid_unnecessary_addr_size)
/fragment@2/__overlay__/panel@0: unnecessary #address-cells/#size-cells
without "ranges", "dma-ranges" or child "reg" property]
Link: https://lore.kernel.org/r/20250518215944.178582-2-pbrobinson@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Replace `/// SAFETY` comments in doc comments with proper `# Safety`
sections, as per rustdoc conventions.
Also mark the C FFI callbacks as `unsafe` to correctly reflect their
safety requirements.
Reported-by: Miguel Ojeda <ojeda@kernel.org>
Closes: https://github.com/Rust-for-Linux/linux/issues/1169
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Davide Caratti <dcaratti@redhat.com> says:
drop reasons have been recently introduced to improve debuggability of
networking stack. This series introduces drop reasons in the RX path
of the CAN protocol stack.
Link: https://patch.msgid.link/20250604160605.1005704-1-dcaratti@redhat.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Currently for CONFIG_GPIO_GENERIC=y each struct gpio_chip object
contains the fields relevant only for gpio-mmio users. It's not an
insignificant number either as it's several pointers and integers.
It makes sense to remove these fields from struct gpio_chip into a
dedicated structure but this is not trivial due to how the bgpio_init()
function is implemented.
Add a task for tracking this rework.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250527111353.71540-1-brgl@bgdev.pl
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The mstp_clock structure really represents a module clock (cfr. the
various rzg2l_mod_clock_*() functions and the to_mod_clock() helper),
and is not directly related to the "Module stop state".
Rename it to "mod_clock", and replace "mstp_clock" by "mod_clock".
to avoid confusion with the mstop registers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://lore.kernel.org/53b3a730a784650762cdb27fdbde7a45b0c20db8.1749119264.git.geert+renesas@glider.be
This reverts commit f33dca9ed6.
Since the configuration order between the individual MSTOP and CLKON
bits cannot be preserved with the power domain abstraction, drop the
power domain IDs.
Currently, there are no device tree users for #power-domain-cell = <1>.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: "Rob Herring (Arm)" <robh@kernel.org>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://lore.kernel.org/20250527112403.1254122-9-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Since the configuration order between the individual MSTOP and CLKON
bits cannot be preserved with the power domain abstraction, drop the
power domain IDs. The corresponding code has also been removed.
Currently, there are no device tree users for these IDs.
Acked-by: "Rob Herring (Arm)" <robh@kernel.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://lore.kernel.org/20250527112403.1254122-8-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Since the configuration order between the individual MSTOP and CLKON
bits cannot be preserved with the power domain abstraction, drop the
power domain core code.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://lore.kernel.org/20250527112403.1254122-7-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Since the configuration order between the individual MSTOP and CLKON
bits cannot be preserved with the power domain abstraction, drop the
power domain instantiations.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://lore.kernel.org/20250527112403.1254122-6-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
The RZ/{G2L,V2L,G3S} CPG versions support a feature called MSTOP. Each
module has one or more MSTOP bits associated with it, and these bits
need to be configured along with the module clocks. Setting the MSTOP
bits switches the module between normal and standby states.
Previously, MSTOP support was abstracted through power domains (struct
generic_pm_domain::{power_on, power_off} APIs). With this abstraction,
the order of setting the MSTOP and CLKON bits was as follows:
Previous Order:
A/ Switching to Normal State (e.g., during probe):
1/ Clear module MSTOP bit
2/ Set module CLKON bit
B/ Switching to Standby State (e.g., during remove):
1/ Clear CLKON bit
2/ Set MSTOP bit
However, in some cases (when the clock is disabled through devres), the
order may have been (due to the issue described in link section):
1/ Set MSTOP bit
2/ Clear CLKON bit
Recently, the hardware team has suggested that the correct order to set
the MSTOP and CLKON bits is:
Updated Order:
A/ Switching to Normal State (e.g., during probe):
1/ Set CLKON bit
2/ Clear MSTOP bit
B/ Switching to Standby State (e.g., during remove):
1/ Set MSTOP bit
2/ Clear CLKON bit
To prevent future issues due to incorrect ordering, the MSTOP setup has
now been implemented in rzg2l_mod_clock_endisable(), ensuring compliance
with the sequence suggested in Figure 41.5: Module Standby Mode
Procedure from the RZ/G3S HW manual, Rev1.10.
Additionally, since multiple clocks of a single module may be mapped to
a single MSTOP bit, MSTOP setup is reference-counted.
Furthermore, as all modules start in the normal state after reset, if
the module clocks are disabled, the module state is switched to standby.
This prevents keeping the module in an invalid state, as recommended by
the hardware team.
Link: https://lore.kernel.org/all/20250215130849.227812-1-claudiu.beznea.uj@bp.renesas.com/
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250527112403.1254122-5-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Add a macro to iterate over the module clocks array. This will be useful
in the upcoming commits that move MSTOP support into the clock
enable/disable APIs.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Link: https://lore.kernel.org/20250527112403.1254122-4-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
RZ/T2H has 2 register blocks at different addresses.
The clock tree has configurable dividers and mux selectors.
Add these new clock types, new register layout type, and
registration code for mux and div in registration callback.
Signed-off-by: Thierry Bultel <thierry.bultel.yh@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250515141828.43444-6-thierry.bultel.yh@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
DT bindings and binding definitions for the Renesas RZ/T2H (R9A09G077)
SoC, shared by driver and DT source files.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCaDRVwgAKCRCKwlD9ZEnx
cDE1AP0UJ+Ooch5SIEiaDLkJ6uH+3YY4W+11LnjSQ/ir7XIIpwD/aK9jWxjWcWLd
sqFXKOVwql/oAKgja6fwzfUqR2qZ5Qg=
=pQ0H
-----END PGP SIGNATURE-----
Merge tag 'renesas-r9a09g077-dt-binding-defs-tag' into renesas-clk-for-v6.17
Renesas RZ/T2H DT Binding Definitions
DT bindings and binding definitions for the Renesas RZ/T2H (R9A09G077)
SoC, shared by driver and DT source files.
sock_queue_rcv_skb() can fail because of lack of memory resources: use
drop reasons and pass the receiving socket to the tracepoint, so that
it's possible to better locate/debug such events.
Tested with:
| # modprobe vcan echo=1
| # ip link add name vcan2 type vcan
| # ip link set dev vcan2 up
| # ./netlayer/tst-proc 1 &
| # bg
| # while true ; do perf record -e skb:kfree_skb -aR -- \
| > ./raw/tst-raw-sendto vcan2 ; perf script ; done
| [...]
| tst-raw-sendto 10942 [000] 506428.431856: skb:kfree_skb: skbaddr=0xffff97cec38b4200 rx_sk=0xffff97cf0f75a800 protocol=12 location=raw_rcv+0x20e reason: SOCKET_RCVBUF
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Link: https://patch.msgid.link/20250604160605.1005704-3-dcaratti@redhat.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Besides the existing pr_warn_once(), use skb drop reasons in case AF_CAN
layer drops non-conformant CAN{,FD,XL} frames, or conformant frames
received by "wrong" devices, so that it's possible to debug (and count)
such events using existing tracepoints:
| # perf record -e skb:kfree_skb -aR -- ./drv/canfdtest -v -g -l 1 vcan0
| # perf script
| [...]
| canfdtest 1123 [000] 3893.271264: skb:kfree_skb: skbaddr=0xffff975703c9f700 rx_sk=(nil) protocol=12 location=can_rcv+0x4b reason: CAN_RX_INVALID_FRAME
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Link: https://patch.msgid.link/20250604160605.1005704-2-dcaratti@redhat.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
