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 13de8483388 ("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>

Moteen Shah <m-shah@ti.com> says:

This patch series adds the functionality to print the DM firmware
version being used. Before requesting TISCI for the DM version we
first check if the DM split mode capability exists, if yes, we proceed
onto making the call to TISCI for retrieving the version information.

DM split mode capability indicates that the DM is a separate binary
altogether and has its own versioning information similar to TIFS.

Boot Logs: https://gist.github.com/Jamm02/37864f605445944a0c0caf426e0aba50

Link: https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/general/core.html#tisci-msg-query-fw-caps
Link: https://lore.kernel.org/r/20250609081434.1000377-1-m-shah@ti.com

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