| Age | Commit message (Collapse) | Author |
|---|
|
This driver depends on DM_I2C and DM_SPI, add it.
Fixes: 3b639f643889 ("gpio: mcp230xx: Add support for models with SPI interface.")
Signed-off-by: Charles Perry <[email protected]>
Reviewed-by: Quentin Schulz <[email protected]>
|
|
Currently the oscillator stop flag (OSF) bit is never checked or cleared
on the DS1339 RTC chip.
On getting the time from the RTC, check if the OSF bit is set, log a
warning, and clear the flag. This matches the behavior of the DS1337
chip.
Note that the `date` command always reads from the RTC even when
setting or resetting the date, so the OSF flag is cleared in those cases
as well.
Signed-off-by: Ronan Dalton <[email protected]>
Cc: Tom Rini <[email protected]>
Cc: Simon Glass <[email protected]>
Cc: Francesco Dolcini <[email protected]>
Cc: Mark Tomlinson <[email protected]>
Cc: Chris Packham <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-i2c
updates for 2026.07-rc3
- designware_i2c: Staticize driver ops from Marek
- i2c: Remove legacy CONFIG_SYS_I2C_SOFT
-
|
|
The last users of this legacy i2c stack have been removed or converted
to a modern part of the stack instead. Remove this code and references
to it.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Heiko Schocher <[email protected]>
|
|
Set the ops structure as static. The structure is not accessible
from outside of this driver.
Reviewed-by: Heiko Schocher <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-stm
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/30081
- reset: stm32: Fix compilation error
- Remove remaining non-existant STM32_RESET flag
- configs: stm32mp13: Add SPI-NAND UBI boot support
- Support metadata-driven A/B boot for STM32MP25
|
|
If udc_device_get_by_index fails, the f_acm struct was not released.
Free it before returning the error.
Signed-off-by: Francois Berder <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
Reviewed-by: Mattijs Korpershoek <[email protected]>
Link: https://patch.msgid.link/BESP194MB2805271AD5DBE47B322F8DC3DA3A2@BESP194MB2805.EURP194.PROD.OUTLOOK.COM
Signed-off-by: Mattijs Korpershoek <[email protected]>
|
|
Rasmus Villemoes <[email protected]> says:
There are quite a few places where we allocate X+1 bytes, initialize
the first X bytes via memcpy() and then set the last byte to 0.
The kernel has a helper for that, kmemdup_nul(). Introduce a similar
one, and start making use of it in a few places. Also the existing
memdup() helper can be put to more use.
There are lots more places one could modify. But for code shared with
host tools, one would need to do some refactoring, putting memdup()
and memdup_nul() in their own str-util.c TU which could then also be
included in the tools build.
Link: https://lore.kernel.org/r/[email protected]
|
|
Use memdup() instead of open-coding it.
In the dm_setup_inst() case, there was never any reason to use
calloc(), as the whole allocation is definitely initialized via the
immediately following memcpy().
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
The virtio_blk_do_single_req function returns ulong, which normally is
the processed size, but in an error case can be the actual error. Use
the special IS_ERR_VALUE macro to test for error.
Addresses-Coverity-ID: CID 645833 (DEADCODE) & CID 645834 (NO_EFFECT)
Signed-off-by: Christian Pötzsch <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
The main use case for u-boot on Apple silicon based devices is to
provide an EFI based bootloader for operating systems. This uses a
generic u-boot image with DTBs passed from an earlier boot loader
(m1n1). Use the generic board name "mac" for this purpose.
Signed-off-by: Janne Grunau <[email protected]>
|
|
After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,wdt" anymore [1]. Use
"apple,t8103-wdt" as base compatible as it is the SoC driver and
bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,wdt".
Link: https://lore.kernel.org/asahi/[email protected]/ [1]
Link: https://lore.kernel.org/asahi/[email protected]/ [2]
Signed-off-by: Janne Grunau <[email protected]>
Reviewed-by: Stefan Roese <[email protected]>
Acked-by: Mark Kettenis <[email protected]>
|
|
After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,spi" anymore [1]. Use
"apple,t8103-spi" as base compatible as it is the SoC driver and
bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,spi".
Link: https://lore.kernel.org/asahi/[email protected]/ [1]
Link: https://lore.kernel.org/asahi/[email protected]/ [2]
Signed-off-by: Janne Grunau <[email protected]>
Acked-by: Mark Kettenis <[email protected]>
|
|
After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,pmgr-pwrstate" anymore [1]. Use
"apple,t8103-pmgr-pwrstate" as base compatible as it is the SoC driver
and bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,pmgr-pwrstate".
Link: https://lore.kernel.org/asahi/[email protected]/ [1]
Link: https://lore.kernel.org/asahi/[email protected]/ [2]
Signed-off-by: Janne Grunau <[email protected]>
Acked-by: Mark Kettenis <[email protected]>
|
|
After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,pinctrl" anymore [1]. Use
"apple,t8103-pinctrl" as fallback compatible as it is the SoC driver and
bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,t8103-pinctrl".
Link: https://lore.kernel.org/asahi/[email protected]/ [1]
Link: https://lore.kernel.org/asahi/[email protected]/ [2]
Signed-off-by: Janne Grunau <[email protected]>
Acked-by: Mark Kettenis <[email protected]>
|
|
After discussion with the devicetree maintainers we agreed to not extend
lists with the generic compatible "apple,nvme-ans2" anymore [1]. Add
"apple,t8103-nvme-ans2" as fallback compatible as this is the SoC the
driver and bindings were originally written for.
The t602x (M2 Pro/Max/Ultra) devicetrees submitted in [2] use this
compatible as fallback instead of "apple,t8103-nvme-ans2".
Link: https://lore.kernel.org/asahi/[email protected]/ [1]
Link: https://lore.kernel.org/asahi/[email protected]/ [2]
Signed-off-by: Janne Grunau <[email protected]>
Acked-by: Mark Kettenis <[email protected]>
|
|
The Cadence SD6HC (SDHCI spec v4.20+) controller uses a soft PHY whose
DLL delay characteristics vary with PVT (Process, Voltage, Temperature)
and board-level trace routing.
A static delay value programmed via device tree for SD High Speed mode is
insufficient because the optimal sampling point varies per board, SD card,
and operating conditions. Runtime calibration is required.
While the SD Physical Layer Specification does not mandate tuning for
SD HS mode (only for UHS-I SDR50/SDR104), the Cadence SD6HC PHY
requires runtime calibration of its receive data delay line to find a
valid sampling window under constrained clock conditions.
The tuning is triggered from the set_ios_post callback because at that
moment hardware has committed the new bus width, clock frequency, and speed
mode to the controller registers. This ensuring the tuning sequence runs
at the correct SD HS operating conditions.
The tuning is gated by a device tree property "cdns,sd-hs-tuning" so
that only boards requiring runtime calibration opt in. When enabled,
the driver performs a 40-tap DLL sweep using CMD19 to find the largest
consecutive passing window, then programs the midpoint into
PHY_DLL_SLAVE_CTRL_REG.
To enable on a board, add to the MMC node in device tree:
&mmc {
cdns,sd-hs-tuning;
};
Signed-off-by: Tze Yee Ng <[email protected]>
|
|
The following compilation error occurs when environment variable
KBUILD_OUTPUT is not set :
drivers/reset/stm32/stm32-reset-mp21.c:8:10: fatal error: stm32-reset-core.h: No such file or directory
8 | #include <stm32-reset-core.h>
| ^~~~~~~~~~~~~~~~~~~~
As stm32-reset-core.h is located in same directory than stm32-reset-mp21.c,
we should use #include "stm32-reset-core.h".
Signed-off-by: Patrice Chotard <[email protected]>
Reviewed-by: Raphaël Gallais-Pou <[email protected]>
|
|
- DWC3 crash fix, Kconfig logic corrections
|
|
The dwc3_free_one_event_buffer() function incorrectly called free()
on event buffer structures allocated with devm_kzalloc(). This
caused heap corruption and a synchronous abort when exiting
fastboot mode via "fastboot continue".
Device-managed memory is automatically freed when the device is
removed, so manual deallocation causes the heap allocator to access
corrupted metadata.
Fixes: 884b10e86a05 ("usb: dwc3: core: fix memory leaks in event buffer cleanup")
Signed-off-by: Balaji Selvanathan <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
The symbol USB_EMUL is how sandbox has access to USB. It's
implementation however enforces a few other requirements. It must have
SCSI enabled, and in turn that means it must have BLK enabled. Finally,
we should not be using SANDBOX itself as a symbol to decide what to
build or not build here, as SANDBOX is selected for COMPILE_TEST builds
as well and so may not have enabled the sandbox specific USB support.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
As exposed by "make randconfig", we have an issue with the dependencies
for RESET_RZG2L_USBPHY_CTRL. As this functionally depends on
REGULATOR_RZG2L_USBPHY, express this dependency directly in Kconfig as
well.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
The USB_RENESAS_USBHS functionality can only work with DM_USB_GADGET
enabled, so express this dependency in Kconfig.
Signed-off-by: Tom Rini <[email protected]>
Reviewed-by: Marek Vasut <[email protected]>
|
|
Commit 70101c3217ae ("virtio: mmio: Return error codes on probe
failures") returns -ENODEV where it would return 0 before. That path is
apparently hit in qemu and breaks boot device discovery
(virtio_bootdev_hunt() expects only ENOENT). So return -ENOENT in
that path instead.
The remaining two error returns in the function are untouched as I
don't know where they play a role.
Signed-off-by: Ludwig Nussel <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
Acked-by: Kuan-Wei Chiu <[email protected]>
|
|
https://source.denx.de/u-boot/custodians/u-boot-mmc
- Enable FPWM bits for tps65941
- Use max-frequency to get clock rate for msm_sdhci
- Fix and update for pfuze100
|
|
This is similar to the VSC8574 according to the Linux commit that adds
support for it [1].
This was tested on an HX1000 board with SGMII (PIC64-HX SoC which has a
GEM MAC).
[1]: https://lore.kernel.org/all/dfabe39a52efcd2cfff9358f271b8673143503b8.1480497966.git.neill.whillans@codethink.co.uk/
Signed-off-by: Charles Perry <[email protected]>
Reviewed-by: Manikandan Muralidharan <[email protected]>
|
|
A fixed gigabit link on a non-gigabit controller is only rejected
during PHY init (even though there is no PHY to init), because, on
device-tree parsing, the controller is not probed, and it is still
unknown whether it is gigabit-capable.
This code was only tested on emulator with a full-duplex RGMII
interface, but is expected to work in GMII or half-duplex as well.
Signed-off-by: Christian DREHER <[email protected]>
|
|
Cadence Ethernet MAC has a feature named user_io, which provides
some input and some output signals for arbitrary purpose in the SoC.
From the driver code, I understand that, on Atmel SoC, it is used to
drive the PHY mode.
At least on Cadence IP7014 r1p12, this feature is optional, and I am
working on a SoC that does not instantiate it. The presence of this
feature is advertised in DCFG1, this patch merely disables the access
to the user_io register based on this information.
I did not apply this change to the non-gigabit capable versions of
the IP, as I do not have documentation for them, and a new non-gigabit
instance is unlikely to appear. I prefer avoiding regressions on old
systems.
Signed-off-by: Christian DREHER <[email protected]>
|
|
The MACB uses specific address registers (SA Top and Bottom) to
filter source or destination MAC addresses.
On the Gigabit Ethernet version, SA1B is @0x88.
On the non-GEM version, SA1B is @0x98.
Before this commit, the code was always writing 0x98. By chance,
on GEM, this is the address of SA3B, allowing the driver to work
anyway.
The motivation for this change is to be able to use the driver on
an instance of the GEM with less than 4 SA registers.
Signed-off-by: Christian DREHER <[email protected]>
|
|
It does not exist in my setup (an on-going arm64 SoC), and removing
it does not cause any missing declaration, but some code called when
CONFIG_CLK is missing calls get_macb_pclk_rate, which is only defined
in arch/arm/mach-at91/include/mach/clk.h
Signed-off-by: Christian DREHER <[email protected]>
|
|
The ADIN1200 chip is register compatible with the ADIN1300, but only
supports 10/100 Mbit.
Signed-off-by: Rasmus Villemoes <[email protected]>
|
|
Replace the proprietary airoha,pnswap-rx / airoha,pnswap-tx boolean
device tree properties with the standard rx-polarity and tx-polarity
properties defined in phy-common-props.yaml.
Backward compatibility is maintained by reading the legacy boolean
properties first and passing them as the default_pol argument to
phy_get_rx/tx_polarity(). If the standard properties are absent the
legacy values are used transparently, so existing device trees remain
functional without modification.
Link: https://git.kernel.org/linus/66d8a334b57e64e43810623b3d88f0ce9745270b
Signed-off-by: Lucien.Jheng <[email protected]>
|
|
Add a new PHY_COMMON_PROPS library that provides helper functions for
PHY drivers to read standardized polarity properties from the device
tree node:
- phy_get_rx_polarity() / phy_get_tx_polarity()
- phy_get_manual_rx_polarity() / phy_get_manual_tx_polarity()
The dt-bindings/phy/phy.h header with PHY_POL_NORMAL, PHY_POL_INVERT,
and PHY_POL_AUTO constants is provided via dts/upstream/include, which
is already in the build include path.
Ported from Merge tag 'phy-for-7.0':
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy
Link: https://git.kernel.org/linus/e7556b59ba65179612bce3fa56bb53d1b4fb20db
Signed-off-by: Lucien.Jheng <[email protected]>
|
|
Upstream devicetrees use a newer DT binding using cpsw-switch
compatibles. The bindings are a bit different, so two functions are
introduced to capture the differences, cpsw_eth_of_to_plat_switch() and
cpsw_eth_of_to_plat_legacy().
Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
|
|
Use driver data to pass the correct gmii_sel function. This way new
compatibles don't need manual compatible matching as is done in
cpsw_phy_sel().
Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
|
|
The string is already in the priv struct, remove it from the argument
list.
Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
|
|
It should complain about mac_control here.
Signed-off-by: Markus Schneider-Pargmann (TI) <[email protected]>
|
|
Since Linux commit c360eb0c3ccb ("dt-bindings: net: ethernet-controller:
Add informative text about RGMII delays"), the interpretation of RGMII
delays has changed. Prior to the commit, the RGMII Variant among "rgmii",
"rgmii-id", "rgmii-rxid" and "rgmii-txid" clearly specified whether it is
the MAC or the PHY that "should" add the delay. However, post that commit,
the RGMII Variant only specifies whether or not there is a delay on the
PCB traces between the MAC and the PHY, leaving it open as to who adds the
delay.
Hence, instead of enforcing the existence of the device-tree properties
"ti,rx-internal-delay" and "ti,tx-internal-delay", default to a delay
of 2ns, while continuing to override this delay with the aforementioned
properties, if they exist in the device-tree.
This is in line with the Linux driver implementation updated by commit
6bf78849371d ("net: phy: dp83867: use 2ns delay if not specified in DTB").
Signed-off-by: Siddharth Vadapalli <[email protected]>
Reviewed-by: Anshul Dalal <[email protected]>
|
|
msm_sdc_clk_init() uses clock-frequency to get the clock rate for SDC
clocks. However, the DT files seem to use max-frequency for the same.
Since msm_sdc_clk_init() doesn't find clock-frequency in the DT, it sets
201500000 as the clock rate and this results in timeout errors on IPQ
platforms.
Additionally, clock-frequency is not DT bindings compliant. Hence, get
clock rate using DT bindings compliant max-frequency.
Signed-off-by: Varadarajan Narayanan <[email protected]>
Reviewed-by: Sumit Garg <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Use CONFIG_$(PHASE_)DM_REGULATOR_PFUZE100 as the build condition for
pfuze100 regulator driver.
Add Kconfig option for SPL_DM_REGULATOR_PFUZE100.
To avoid break current platforms, set the Kconfig default value same
as PMIC_PFUZE100.
Signed-off-by: Peng Fan <[email protected]>
|
|
Some BUCKs could work in single/dual phase mode, not in independent
mode. In single/dual phase mode, registers of both regulators,
must be identically set. So configure mode and value for both BUCKs.
CONF registers are not touched, leave them as default OTP settings.
PFUZE100/200 SW3A/B, could work in single/dual phase mode, so introduce
a new macro by adding a pointer to the SW3B descriptor.
Signed-off-by: Peng Fan <[email protected]>
|
|
Some PFUZE regulators can operate in either low or high output voltage mode,
with different minimum voltages and voltage step sizes selected by a hardware
control bit. However, the current PFUZE100 regulator driver assumes low output
voltage mode only, resulting in incorrect voltage calculation and programming
when high voltage mode is enabled.
Extend the regulator descriptor to describe high output voltage mode by adding
a mask to detect the mode and a dedicated voltage description (min_uV and
step size). Update voltage get/set handling to dynamically select the correct
voltage parameters based on the high voltage mode bit.
Signed-off-by: Peng Fan <[email protected]>
|
|
regulator-min-microvolt in device tree is not always match the minimal
voltage in the pmic datasheet, direclty using the min value from device
tree as base may cause wrong voltage settings being written.
Directly use the min_uV from datasheet to avoid wrong settings.
Signed-off-by: Peng Fan <[email protected]>
|
|
Depending on the phase selection (single or multi), the FPWM bits
configured forces the regulator to operate in PWM mode. In case of
multi-phase selection, the FPWM_MP bits enforce the regulator to also
operate in multi-phase. This fixes correct multi-phase operation.
While at this, correct incorrect macro alignment as well.
Fixes: 065a452ae6a1 ("power: regulator: tps65941: add regulator support")
Link: https://www.ti.com/lit/ds/symlink/tps6594-q1.pdf
Signed-off-by: Keerthy <[email protected]>
Signed-off-by: Takuma Fujiwara <[email protected]>
Signed-off-by: Neha Malcom Francis <[email protected]>
Reviewed-by: Udit Kumar <[email protected]>
Signed-off-by: Peng Fan <[email protected]>
|
|
Add support of Renesas R-Car Gen5 window watchdog timer. Timeout
configuration is derived from CONFIG_WATCHDOG_TIMEOUT_MSECS, which
is more accurate than the 1-second granularity 'timeout' passed to
.start callback.
Reviewed-by: Stefan Roese <[email protected]>
Signed-off-by: Marek Vasut <[email protected]>
|
|
Add R-Car Gen5 RSIP controller remoteproc driver capable of starting
the SCP, Cortex-R52 and Cortex-A720 cores in Renesas R-Car R8A78000
X5H SoC. The SCP core is started by releasing the core from reset,
the Cortex-R52 and Cortex-A720 are started using the SCP SCMI call.
The entry point for SCP core is fixed to its STCM, entry points for
Cortex-R52 and Cortex-A720 are set during rproc load.
Signed-off-by: Marek Vasut <[email protected]>
|
|
Allow cpu families as mcf5441x (m68k) to use the fsl_esdhc_imx driver
since the hardware ip module is the same.
Signed-off-by: Angelo Dureghello <[email protected]>
---
Changes in v2:
- moved before menuconfig changes
|
|
Apologies for the delay, but please pull those sunxi changes into
v2026.07. Nothing earth shattering, mostly minor improvements like
better SPL power LED support, and fixes to some H616 DRAM setup. Also
some more forward looking enhancement for the SPI code. I also pulled in
Richard's raw NAND flash improvements for the H6/H616 SoC, though this
lacks proper peer testing due to the lack of mainline support for any
board actually employing those chips.
|
|
No need to reset user data length registers in SPL.
In SPL, only the first user data length register is used, so we don't
need to reset all of them.
Signed-off-by: Richard Genoud <[email protected]>
Acked-by: Andre Przywara <[email protected]>
|
|
In Allwinner SoCs, user data can be added in OOB before each ECC data.
For older SoCs like A10, the user data size was the size of a register
(4 bytes) and was mandatory before each ECC step.
So, the A10 OOB Layout is:
[4Bytes USER_DATA_STEP0] [ECC_STEP0 bytes]
[4bytes USER_DATA_STEP1] [ECC_STEP1 bytes]
...
NB: the BBM is stored at the beginning of the USER_DATA_STEP0.
Now, for H6/H616 NAND flash controller, this user data can have a
different size for each step.
So, we are maximizing the user data length to use as many OOB bytes as
possible.
Fixes: 7d1de9801151 ("mtd: rawnand: sunxi_spl: add support for H6/H616 nand controller")
Fixes: f163da5e6d26 ("mtd: rawnand: sunxi: add support for H6/H616 nand controller")
Signed-off-by: Richard Genoud <[email protected]>
|
