These pinconf/pinctrl definitions will be used by the next patches.
The definitions was taken from public headers of linux-7.0. It's used
by several linux pinctrl drivers, so it might be helpful for U-Boot as
well.
Pinconf definitions are placed near the corresponding U-Boot definitions
in file include/dm/pinctrl.h. Pin/group/function definitions stored within
the same path as in linux (include/linux/pinctrl/pinctrl.h).
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: David Lechner <dlechner@baylibre.com>
The existing FIELD_{GET,PREP}() macros are limited to compile-time
constants. However, it is very common to prepare or extract bitfield
elements where the bitfield mask is not a compile-time constant.
To avoid this limitation, the AT91 clock driver and several other
drivers already have their own non-const field_{prep,get}() macros.
Make them available for general use by adding them to
<linux/bitfield.h>, and improve them slightly:
1. Avoid evaluating macro parameters more than once,
2. Replace "ffs() - 1" by "__ffs()",
3. Support 64-bit use on 32-bit architectures,
4. Wire field_{get,prep}() to FIELD_{GET,PREP}() when mask is
actually constant.
This is deliberately not merged into the existing FIELD_{GET,PREP}()
macros, as people expressed the desire to keep stricter variants for
increased safety, or for performance critical paths.
Yury: use __mask within new macros.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Crt Mori <cmo@melexis.com>
Acked-by: Nuno Sá <nuno.sa@analog.com>
Acked-by: Richard Genoud <richard.genoud@bootlin.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Reviewed-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
[Linux commit: c1c6ab80b25c8db1e2ef5ae3ac8075d2c242ae13]
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The BUILD_BUG_ON_MSG() check against "~0ull" works only with "unsigned
(long) long" _mask types. For constant masks, that condition is usually
met, as GENMASK() yields an UL value. The few places where the
constant mask is stored in an intermediate variable were fixed by
changing the variable type to u64.
However, for non-constant masks, smaller unsigned types should be valid,
too, but currently lead to "result of comparison of constant
18446744073709551615 with expression of type ... is always
false"-warnings with clang and W=1.
Hence refactor the __BF_FIELD_CHECK() helper, and factor out
__FIELD_{GET,PREP}(). The later lack the single problematic check, but
are otherwise identical to FIELD_{GET,PREP}(), and are intended to be
used in the fully non-const variants later.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
[Linux commit: 2a6c045640c38a407a39cd40c3c4d8dd2fd89aa8]
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: David Lechner <dlechner@baylibre.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: Gerald Van Baren <vanbaren@cideas.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The existing clk_register_divider() only supports linear or
power-of-two divider mappings. Some hardware (e.g. i.MX6 PLL5
post_div and video_div) uses non-linear register-value-to-divisor
mappings that require a lookup table.
Add clk_register_divider_table() which accepts a clk_div_table,
and reimplement clk_register_divider() as a wrapper passing
table=NULL.
Signed-off-by: Brian Ruley <brian.ruley@gehealthcare.com>
Rasmus Villemoes <ravi@prevas.dk> 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/20260421075439.16696-1-ravi@prevas.dk
This is completely analogous to the linux kernel's kmemdup_nul()
helper, apart from the lack of the gfp_t argument: Allocate a buffer
of size {len}+1, copy {len} bytes from the given buffer, and add a
final nul byte.
This pattern exists in a number of places, so this helper can reduce
some boilerplate code.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
There has never been an arch-specific optimized implementation of
str[n]dup, nor is there likely to ever be one, because unlike their
cousins strlen(), strcpy() and similar that simply read/write the
src/dst, the dup functions by definition involve memory allocation. So
drop this irrelevant cpp guard.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
It doesn't make sense to restrict memdup() to only return char*
pointers, especially when it is already defined to accept void*. This
makes it uglier to use to e.g. duplicate a struct.
Make it return void*, just as kmemdup() does in the kernel (and which
our kmemdup() in fact also does).
While in here, make a small optimization: memcpy() is defined to
return the destination register, so we write this in a way that the
compiler may do a tail call.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
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 <lucienzx159@gmail.com>
Add a symlink to the Linux regmap.h path so that drivers ported from
Linux don't all need additional changes to include the U-Boot specific
path.
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
This is a very basic port of Linux' kref, we don't actually need atomics
so we just use a simple counter. This is used by CCF to free unused
clocks.
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Extend Linux compat by adding kstrdup_const(), backed by lib/string.c.
This leverages U-Boots .rodata section on ARM64 to avoid pointlessly
duplicating const strings.
This is used by the Linux CCF_FULL port and may be useful elsewhere
in U-Boot.
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Heiko Schocher <hs@nabladev.com> says:
Add SM3 secure hash, as specified by OSCCA GM/T 0004-2012 SM3 and described
at https://datatracker.ietf.org/doc/html/draft-sca-cfrg-sm3-02
TPMv2 defines hash algo sm3_256, which is currently
not supported and prevented TPMv2 chip with newer
firmware to work with U-Boot. Seen this on a ST33TPHF2XI2C
u-boot=> tpm2 init
u-boot=> tpm2 autostart
tpm2_get_pcr_info: too many pcrs: 5
Error: -90
u-boot=>
Implement sm3 hash, so we can fix this problem.
Link: https://lore.kernel.org/r/20251118043042.27726-1-hs@nabladev.com
sm3 crypto algorithm uses rol32 function from linux, so
import it. Linux base was:
commit ca91b9500108:("Merge tag 'v6.15-rc4-ksmbd-server-fixes' of git://git.samba.org/ksmbd")
Signed-off-by: Heiko Schocher <hs@nabladev.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The function mtd_read_oob_bf is called by cmd/nand.c but does not have a
prototype in any header. Add this to include/linux/mtd/mtd.h as that is
the most logical place currently.
Fixes: 1fac577207 ("nand: Add a watch command")
Signed-off-by: Tom Rini <trini@konsulko.com>
Remove default values for PMC PLL Analog Control Register(ACR) as the
values are specific for each SoC and PLL, so load them from PLL
characteristics structure
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com>
While we declare some of our dummy functions as "inline" we do not also
declare them as "static" and so it is possible for the compiler to
decide to make these as global functions instead. This can lead to link
time failures in some cases, such as "allyesconfig". As these are just
dummy functions, convert them to a macro instead.
Signed-off-by: Tom Rini <trini@konsulko.com>
This series adds significant and valuable work by Mikhail Kshevetskiy to
align spi-mem with Linux 6.16. It also includes contributions to the mtd
performance patches, a work started by Miquel Raynal and improved by
Mikhail Kshevetskiy. Additionally, two patches tighten dependencies on
the Atmel driver.
The patches pass the pipeline CI:
https://source.denx.de/u-boot/custodians/u-boot-nand-flash/-/pipelines/27873
This makes the U-Boot SPI NAND driver almost the same as in Linux
6.17-rc1. The only major differences are:
* support of ECC engines. The Linux driver supports different ECC
engines while U-Boot uses on-die ECC only.
* per operation maximum SPI bus frequency
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
There is already a manufacturer hook, which is manufacturer specific but
not chip specific. We no longer have access to the actual NAND identity
at this stage so let's add a per-chip configuration hook to align the
chip configuration (if any) with the core's setting.
This is a port of linux commit
da55809ebb45 ("mtd: spinand: Add a ->configure_chip() hook")
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> # U-Boot port
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
When the host ECC fails to correct the data error of NAND device,
there's a special read for data recovery method which can be setup
by the host for the next read. There are several retry levels that
can be attempted until the lost data is recovered or definitely
assumed lost.
This is the port of linux commit
f2cb43c98010 (mtd: spinand: Add read retry support)
Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> # U-Boot port
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
The code was ported from linux-6.12. The original continuous reading
support was implemented by Miquel Raynal <miquel.raynal@bootlin.com>
in linux commit 631cfdd0520d (mtd: spi-nand: Add continuous read support).
Here is an original patch description:
--------------------------------------
A regular page read consist in:
- Asking one page of content from the NAND array to be loaded in the
chip's SRAM,
- Waiting for the operation to be done,
- Retrieving the data (I/O phase) from the chip's SRAM.
When reading several sequential pages, the above operation is repeated
over and over. There is however a way to optimize these accesses, by
enabling continuous reads. The feature requires the NAND chip to have a
second internal SRAM area plus a bit of additional internal logic to
trigger another internal transfer between the NAND array and the second
SRAM area while the I/O phase is ongoing. Once the first I/O phase is
done, the host can continue reading more data, continuously, as the chip
will automatically switch to the second SRAM content (which has already
been loaded) and in turns trigger the next load into the first SRAM area
again.
From an instruction perspective, the command op-codes are different, but
the same cycles are required. The only difference is that after a
continuous read (which is stopped by a CS deassert), the host must
observe a delay of tRST. However, because there is no guarantee in Linux
regarding the actual state of the CS pin after a transfer (in order to
speed-up the next transfer if targeting the same device), it was
necessary to manually end the continuous read with a configuration
register write operation.
Continuous reads have two main drawbacks:
* They only work on full pages (column address ignored)
* Only the main data area is pulled, out-of-band bytes are not
accessible. Said otherwise, the feature can only be useful with on-die
ECC engines.
Performance wise, measures have been performed on a Zynq platform using
Macronix SPI-NAND controller with a Macronix chip (based on the
flash_speed tool modified for testing sequential reads):
- 1-1-1 mode: performances improved from +3% (2-pages) up to +10% after
a dozen pages.
- 1-1-4 mode: performances improved from +15% (2-pages) up to +40% after
a dozen pages.
This series is based on a previous work from Macronix engineer Jaime
Liao.
--------------------------------------
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
SkyHigh spinand device has ECC enable bit in configuration register but
it must be always enabled. If ECC is disabled, read and write ops
results in undetermined state. For such devices, a way to avoid raw
access is needed.
Introduce SPINAND_NO_RAW_ACCESS flag to advertise the device does not
support raw access. In such devices, the on-die ECC engine ops returns
error to I/O request in raw mode.
Checking and marking BBM need to be cared as special case, by adding
fallback mechanism that tries read/write OOB with ECC enabled.
This is a port of linux commit
6d9d6ab3a82a (mtd: spinand: Introduce a way to avoid raw access)
Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano@infineon.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> # U-Boot port
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Add two flags for inserting the Plane Select bit into the column
address during the write_to_cache and the read_from_cache operation.
Add the SPINAND_HAS_PROG_PLANE_SELECT_BIT flag for serial NAND flash
that require inserting the Plane Select bit into the column address
during the write_to_cache operation.
Add the SPINAND_HAS_READ_PLANE_SELECT_BIT flag for serial NAND flash
that require inserting the Plane Select bit into the column address
during the read_from_cache operation.
This is a port of linux commit
ca229bdbef29 (mtd: spinand: Add support for setting plane select bits)
Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20240909092643.2434479-2-linchengming884@gmail.com
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> # U-Boot port
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
This makes the U-Boot SPI NAND driver almost the same as in Linux 6.10.
The only major difference is support of ECC engines. The Linux driver
supports different ECC engines while U-Boot uses on-die ECC only.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
This aligns spinand_wait() with the linux kernel. Instead of calling into
spi_mem_poll_status() which is not implemented in U-Boot, we code the
polling logic and make sure that schedule() is called periodically.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Make use of the spi-mem direct mapping API to let advanced controllers
optimize read/write operations when they support direct mapping.
Based on a linux commit 981d1aa0697c ("mtd: spinand: Use the spi-mem dirmap API")
created by Boris Brezillon <bbrezillon@kernel.org> with additional
fixes taken from Linux 6.10.
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Synchronize upper_NN_bits() and lower_NN_bits() macros with Linux 6.16
commit 118d777c4cb4 ("wordpart.h: Add REPEAT_BYTE_U32()"). This fixes the
lower_32_bits() macros and assures it works with 64bit systems correctly.
This also adds 16bit variants of these macros, which will be used by the
Airoha PHY driver.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Fix the I3C device with spike filter unable to detect issue by setting
tHIGH_INIT to 200ns for first broadcast address.
This is according to MIPI SPEC 1.1.1 for first broadcast address
which is already part of linux upstreamed patch.
Signed-off-by: Dinesh Maniyam <dinesh.maniyam@altera.com>
Enable driver for Synopsis MIPI DWI3C for the family
device agilex5. This driver is migrated from linux version 6.6.37 LTS
Signed-off-by: Dinesh Maniyam <dinesh.maniyam@altera.com>
Rasmus Villemoes <ravi@prevas.dk> says:
I was bitten by our limit macros not being usable in #if conditionals
when building a standalone app. It turns out that the work to fix that
had already been started by the inclusion of the mbedtls library, so
it's something that people do hit.
Let's finish the job by providing suitable limit macros for all three families:
- Standard C types, char, short, ...
- Kernel-style fixed-width types s8, u64, ...
- POSIX/C99 fixed-width types int16_t, uint32_t, ...
Please note that a naive approach like spelling out the full decimal
value for the constants doesn't really work, as there is no such thing
as a "negative integer constant". That is, doing
#define LLONG_MIN -9223372036854775808LL
would lead to the compiler complaining
warning: integer constant is so large that it is unsigned
and the type of that LLONG_MIN would actually be "unsigned long long", so e.g.
#if LLONG_MIN >= 0
#warning "LLONG_MIN is not negative?"
#endif
would fire.
Link: https://lore.kernel.org/r/20250707203655.613340-1-ravi@prevas.dk
Currently, we only have UINT32_MAX and UINT64_MAX in limits.h, and
then stdint.h and kernel.h somewhat randomly define UINT8_MAX and
INT32_MAX, respectively.
Provide a full set of definitions in terms of the min/max macros for
the types that [u]intNN_t are defined in terms of, namely the {s,u}NN
ones.
Try to avoid breaking whatever depended on getting UINT8_MAX from our
compat stdint.h by replacing it with an include of limits.h.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Since we define the {s,u}{8,16,32,64} types the same way on all
architectures, i.e. everybody uses asm-generic/int-ll64.h, we can just
define the associated limit macros in terms of those for the
corresponding types. This eliminates another set of limit macros that
are not usable in #if conditionals.
These type names and macros are not C or POSIX, so there's no language
violation, but certainly a violation of developers' reasonable
expectations.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
In a customer project that was building a stand-alone application, I
hit a problem related to the fact that our LONG_MAX and friends are
not standards-compliant, in that they are not "suitable for use in #if
preprocessing directives"
... /toolchain_none/arm-cortexa8-eabi/sys-include/machine/_default_types.h:25:31: error: missing binary operator before token "long"
25 | || ( defined(LLONG_MAX) && (LLONG_MAX > 0x7fffffff) )
| ^~~~~~~~~
So following up on commit 13de848338 ("mbedtls: add mbedtls into the
build system"), move the rest of the macros associated to the standard
C types {signed,unsigned} {char, short, int, long, long long} (and of
course bare 'char') to limits.h.
Make use of the fact that both gcc and clang provide suitable
predefined __FOO_MAX__ macros for the signed types, and use a standard
scheme for defining the FOO_MIN and UFOO_MAX macros in terms of
FOO_MAX.
Note that suffixes like L and ULL are allowed for preprocessor
integers; it is (casts) which are not. And using appropriate suffixes,
we can arrange for the type of e.g. UINT_MAX to be "unsigned int" due
to integer promotion rules.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Introduce response and request structs to receive and request
information regarding DM version, etc from TI SCI.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Introduce response and request structs for receiving information
regarding FW/SOC capability from DM. The received capability can
further be used to call certain API's based on the feature supoorted
by the DM firmware.
Signed-off-by: Moteen Shah <m-shah@ti.com>
Reviewed-by: Neha Malcom Francis <n-francis@ti.com>
Reviewed-by: Dhruva Gole <d-gole@ti.com>
Rasmus Villemoes <ravi@prevas.dk> says:
While looking through list.h, I saw that the regular list_* helpers
(and one of the hlist_* ones) still contain the prefetch() that was
removed in linux 14 years ago. It doesn't do anything, but makes the
macros harder to read, so get rid of it, and the fallback, no-op
definition that they relied on. That requires removing a few uses
outside list.h as well.
checkpatch warns about some whitespace issues in list.h, but as I've
copied whole kerneldoc+#define blocks directly from the linux kernel,
I think it's better to just accept that so that we don't introduce
needless diffs. The "macro argument reuse" arguments should also be
ignored, as e.g. the "member" arguments are obviously always just bare
identifiers, and the "pos" arguments must be assigned to multiple
times.
Link: https://lore.kernel.org/r/20250507121246.518691-1-ravi@prevas.dk
None of the list helpers use prefetch() anymore, and no C code relies
on getting this definition from list.h. In any case, such an arch/cpu
specific thing does not belong in a header that just consists of cpp
helper macros.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
The use of prefetch() in these list helpers was dropped back in 2011
in linux (e66eed651fd1 ("list: remove prefetching from regular list
iterators")). No arch in U-Boot defines any actual prefetch(), and as
the referenced commit says, it's usually not a win anyway.
Whole-sale sync of list.h is not really feasible, but we can
synchronize the macros containing a prefetch() with their linux
implementations as of v6.15-rc5, also importing the various helpers
needed, e.g. list_is_head() and list_next_entry().
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Sync bitfield.h header with Linux 6.15 version. Mainly is to permit the
introduction of FIELD_PREP_CONST. The bug.h header changed to
build_bug.h doesn't cause any regression as we also ship split header
similar to how it's done with in Linux.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
