Adding pin control node to the child won't parse the pins during driver
bind. Fix the issue by moving it to parent node.
This issue is observed while adding Schmitt input enable for PS0 pin on
later patch. Currently the reset value of the PIN is set to NMI function
and hence there is no breakage.
Fixes: 9e95446b0c ("arm64: dts: renesas: r9a09g047e57-smarc: Add gpio keys")
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20250817145135.166591-2-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
The GBETH IPs found on RZ/G3E SoC family are compatible with the stmmac
driver. They have a MAC HW feature register used by this driver to
enable respective features. While the register advertises Tx coe
support, it was not enabled by the driver due to the
'snps,force_thresh_dma_mode' dtsi property.
Switch from 'snps,force_thresh_dma_mode' to 'snps,force_sf_dma_mode' to
enable Tx checksum offload support on both GBETH IPs. While at it, also
switch from 'snps,fixed-burst' to 'snps,mixed-burst' and remove
'snps,no-pbl-x8' for optimal DMA configuration. This improvement
results in a measurable TCP Tx performance gain, increasing throughput
by 20Mbps.
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20250814153456.268208-1-john.madieu.xa@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Enable SD card slot which is connected to SDHI0 on the RZ/T2H and
RZ/N2H EVKs.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250820200659.2048755-10-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Enable MicroSD card slot which is connected to SDHI1 on the RZ/T2H and
RZ/N2H EVKs.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250820200659.2048755-9-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Enable eMMC on RZ/T2H and RZ/N2H EVKs. As SDHI0 can be connected to
either eMMC0/SD0 `SD0_EMMC` macro is added.
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/20250820200659.2048755-8-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Here are some new modem device ids.
Everything has been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQHbPq+cpGvN/peuzMLxc3C7H1lCAUCaMPXVAAKCRALxc3C7H1l
CIToAQDoULIp/C7gzVUPgHpIeMGPHspAsVqjZ5TDO0Bhc6oM4QEAtpsmzbiZ76xh
jxTtlUiCmVedSTu/OMRTXW2Xz/CRgAU=
=U3Rs
-----END PGP SIGNATURE-----
Merge tag 'usb-serial-6.17-rc6' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus
Johan writes:
USB serial device ids for 6.17-rc6
Here are some new modem device ids.
Everything has been in linux-next with no reported issues.
* tag 'usb-serial-6.17-rc6' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial:
USB: serial: option: add Telit Cinterion LE910C4-WWX new compositions
USB: serial: option: add Telit Cinterion FN990A w/audio compositions
The J721S2-EVM (J721S2-SOM mounted on the J7 Common Processor Board) has
a single instance of USB namely USB0. On the board, USB0 can be enabled
using a single USB interface at a time among the following:
1. USB3.1 Gen1 Type C interface
2. Two USB2.0 Type A interfaces via an on-board USB Hub
By default, USB0 is enabled using the USB3.1 Gen1 Type C interface. Hence,
add a device-tree overlay to allow using USB0 with the USB2.0 Type A
interfaces by configuring the "USB2.0_MUX_SEL" mux. Also, since the Type A
interfaces only connect to USB Devices with USB0 acting as the USB Host,
set the Dual-Role mode for USB0 to Host.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20250912062021.2906034-1-s-vadapalli@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add device tree support for the Variscite Symphony carrier board with
the VAR-SOM-AM62P system on module.
The Symphony board includes
- uSD Card support
- USB ports and OTG
- Additional Gigabit Ethernet interface
- Uart interfaces
- OV5640 Camera support
- GPIO Expander
- CAN, I2C and general purpose interfaces
Link: https://www.variscite.it/product/single-board-computers/symphony-board/
Signed-off-by: Stefano Radaelli <stefano.radaelli21@gmail.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250909213749.28098-4-stefano.radaelli21@gmail.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add device tree support for the Variscite VAR-SOM-AM62P system on module.
This SOM is designed to be used with various carrier boards.
The module includes:
- AM62P Sitara MPU processor
- Up to 8GB of DDR4-3733 memory
- eMMC storage memory
- PS6522430 chip as a Power Management Integrated circuit (PMIC)
- Integrated 10/100/1000 Mbps Ethernet Transceiver Analog Devices ADIN1300
- Resistive touch panel interface controller TI TSC2046
- I2C interfaces
Only SOM-specific peripherals are enabled by default. Carrier board
specific interfaces are left disabled to be enabled in the respective
carrier board device trees.
Link: https://www.variscite.it/product/system-on-module-som/cortex-a53-krait/var-som-am62p-ti-sitara-am62px/
Signed-off-by: Stefano Radaelli <stefano.radaelli21@gmail.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250909213749.28098-3-stefano.radaelli21@gmail.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add bootph-all property to the USB0 PHY controller node to make it
available during all boot phases. This is required for USB DFU boot.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250902053009.1732607-5-h-salunke@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add bootph-all property to the USB0 PHY controller node to make it
available during all boot phases. This is required for USB DFU boot.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250902053009.1732607-4-h-salunke@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add bootph-all property to the USB0 PHY controller node to make it
available during all boot phases. This is required for USB DFU boot.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250902053009.1732607-3-h-salunke@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add bootph-all property to the USB0 PHY controller node to make it
available during all boot phases. This is required for USB DFU boot.
Signed-off-by: Hrushikesh Salunke <h-salunke@ti.com>
Reviewed-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Reviewed-by: Judith Mendez <jm@ti.com>
Link: https://patch.msgid.link/20250902053009.1732607-2-h-salunke@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
TI's J721E SoC supports a DPI to DSI video signal conversion bridge on
it's platform bus. The IP is from Cadence, and it has a custom TI
wrapper around it to facilitate integration.
This IP takes the DPI video signals from DSS and alongwith the DPHY IP,
it transmits DSI video signals out of the SoC.
Add support for DSI bridge and the DPHY-TX.
Signed-off-by: Rahul T R <r-ravikumar@ti.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Harikrishna Shenoy <h-shenoy@ti.com>
Link: https://patch.msgid.link/20250905094325.472473-1-h-shenoy@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Currently, DS_IO_OVERRIDE_EN_SHIFT macro is not defined anywhere but
used for defining other macro.
Replace this undefined macro with valid macro. Rename the existing macro
to reflect the actual behavior.
Fixes: 325aa0f6b3 ("arm64: dts: ti: k3-pinctrl: Introduce deep sleep macros")
Reviewed-by: Kendall Willis <k-willis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
Fixes: 325aa0f6b3 ("arm64: dts: ti: k3-pinctrl: Introduce deep sleep macros")
Link: https://patch.msgid.link/20250909044108.2541534-5-a-kaur@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Add the drive strength, schmitt trigger enable macros to pinctrl file.
Add the missing macros for DeepSleep configuration control referenced
from "Table 14-8769. Description Of The Pad Configuration Register Bits"
in AM62Px TRM[0].
Add some DeepSleep macros to provide combinations that can be used
directly in device tree files example PIN_DS_OUTPUT_LOW that
configures pin to be output and also sets its value to 0.
[0] https://www.ti.com/lit/pdf/SPRUJ83
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
Reviewed-by: Kendall Willis <k-willis@ti.com>
Link: https://patch.msgid.link/20250909044108.2541534-4-a-kaur@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
After the SoC has entered the DeepSleep low power mode, USB1 can be
used to wakeup the SoC based on USB events triggered by USB devices.
This requires that the pin corresponding to the Type-A connector
remains pulled up even after the SoC has entered the DeepSleep low power
mode.
For that, either DeepSleep pullup configuration can be selected or the pin
can have the same configuration that it had when SoC was in active mode.
Remove the unnecessary DeepSleep state configuration from USB1_DRVBUS pin,
as the DeepSleep control bit is not set and the active configuration is
sufficient to keep the pin pulled up. This simplifies the setup and removes
redundant configuration.
This reverts commit 527f884d2d.
Tested-by: Kendall Willis <k-willis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
Reviewed-by: Kendall Willis <k-willis@ti.com>
Acked-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20250909044108.2541534-3-a-kaur@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
After the SoC has entered the DeepSleep low power mode, USB1 can be used
to wakeup the SoC based on USB events triggered by USB devices. This
requires that the pin corresponding to the Type-A connector remains pulled
up even after the SoC has entered the DeepSleep low power mode.
For that, either DeepSleep pullup configuration can be selected or the pin
can have the same configuration that it had when SoC was in active mode.
Remove the unnecessary DeepSleep state configuration from USB1_DRVBUS pin,
as the DeepSleep control bit is not set and the active configuration is
sufficient to keep the pin pulled up. This simplifies the setup and removes
redundant configuration.
This reverts commit 115290c112.
Tested-by: Kendall Willis <k-willis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
Reviewed-by: Kendall Willis <k-willis@ti.com>
Acked-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Link: https://patch.msgid.link/20250909044108.2541534-2-a-kaur@ti.com
Signed-off-by: Nishanth Menon <nm@ti.com>
Move waiting related utilities from i915_utils.h to separate new file
i915_wait_util.h. Clean up related includes.
Note: Many of the various wait macro usages could likely be refactored
to use poll_timeout_us().
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/431396ac8cdb3e2f4ff053a8933290289a66ce42.1757582214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move list related utilities from i915_utils.h to separate new file
i915_list_util.h. Clean up related includes.
Note: Arguably none of this should exist in i915 in the first place. At
least isolate it better.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/d7526809735194137116682f37cfa126a6a87ec9.1757582214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Move timer related utilities from i915_utils.[ch] to separate new files
i915_timer_util.[ch]. Clean up related includes.
Note: Arguably none of this should exist in i915 in the first place. At
least isolate it better.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://lore.kernel.org/r/0a83d9489626121dcefcd4c1a05317399b5708f3.1757582214.git.jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
In case of krealloc_array() failure, the current error handling just
returns from the function without freeing the original array.
Fix this memory leak by freeing the original array.
Fixes: 6aa1754764 ("clk: renesas: cpg-mssr: Ignore all clocks assigned to non-Linux system")
Signed-off-by: Yuan CHen <chenyuan@kylinos.cn>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/20250908012810.4767-1-chenyuan_fl@163.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Add support for the BQ25703A charger manager and boost regulator to
the Gameforce Ace. Add the USB-C port and PHY as well as they all
depend on each other for operation.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://lore.kernel.org/r/20250904160530.66178-6-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
With all users of bgpio_init() converted to using the modernized generic
GPIO chip API, we can now move the gpio-mmio-specific fields out of
struct gpio_chip and into the dedicated struct gpio_generic_chip. To
that end: adjust the gpio-mmio driver to the new layout, update the
docs, etc.
The changes in gpio-mlxbf2.c and gpio-mpc8xxx.c are here and not in their
respective conversion commits because the former passes the address of
the generic chip's lock to the __releases() annotation and we cannot
really hide it while gpio-mpc8xxx.c accesses the shadow registers in a
driver-specific workaround and there's no reason to make them available
in a public API.
Also: drop the relevant task from TODO as it's now done.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250910-gpio-mmio-gpio-conv-part4-v2-15-f3d1a4c57124@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Convert the driver to using the new generic GPIO chip interfaces from
linux/gpio/generic.h.
Reviewed-by: Samuel Holland <samuel.holland@sifive.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250910-gpio-mmio-gpio-conv-part4-v2-11-f3d1a4c57124@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This driver uses its own spinlock in interrupt routines while the
generic GPIO chip callbacks use a separate one. This is, of course, racy
so use the fact that the lock in generic GPIO chip is also a spinlock and
convert the interrupt handling functions in this module to using the
provided generic GPIO chip locking API.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250910-gpio-mmio-gpio-conv-part4-v2-9-f3d1a4c57124@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The conversion to using the modernized generic GPIO chip API was
incomplete without also converting the direct calls to write/read_reg()
callbacks. Use the provided wrappers from linux/gpio/generic.h.
Fixes: 38d98a822c ("gpio: xgene-sb: use new generic GPIO chip API")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250910-gpio-mmio-gpio-conv-part4-v2-6-f3d1a4c57124@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This driver uses its own raw spinlock in interrupt routines while the
generic GPIO chip callbacks use a separate one. This is, of course, racy
so use the fact that the lock in generic GPIO chip is also a raw
spinlock and convert the interrupt handling functions in this module to
using the provided generic GPIO chip locking API.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250910-gpio-mmio-gpio-conv-part4-v2-5-f3d1a4c57124@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
While these flags are private within drivers/gpio/, when looking at the
code, it's not really clear they are GPIO-specific. Since these are GPIO
descriptor flags, prepend their names with a common "GPIOD" prefix.
While at it: update the flags' docs: make spelling consistent, correct
outdated information, etc.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250909-rename-gpio-flags-v1-1-bda208a40856@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>