Tom Rini <trini@konsulko.com> says:
As seen by a number of patches fixing memory leaks, U-Boot has a problem
with developer expectations around devm_kmalloc and friends. Namely,
whereas in Linux these memory allocations will be freed automatically in
most cases, in U-Boot this is only true if DEVRES is enabled. Now,
intentionally, in xPL phases, we do not (and do not offer as an option)
enabling DEVRES. However in full U-Boot this is left either to the user,
or some drivers have select'd DEVRES on their own. This inconsistency is
a problem. This series goes and deals with two small issues that were
shown by having all drivers that use devm_.alloc to allocate memory also
select DEVRES and then we make DEVRES no longer be a prompted option and
instead select'd as needed. We do not make this unconditional as it
would result in growing the resulting binary on the many platforms which
have no users of the devm_.alloc family of functions.
Link: https://lore.kernel.org/r/20251227223833.3019311-1-trini@konsulko.com
The devm alloc functions that we have may follow the Linux kernel model
where allocations are (almost always) automatically free()'d. However,
quite often we don't enable, in full U-Boot, the tracking and free()'ing
functionality. This in turn leads to memory leaks because the driver
author expects that since the functions have the same name as in the
Linux Kernel they have the same behavior. In turn we then get
functionally correct commits such as commit 00e1fed93c ("firmware:
ti_sci: Fix memory leaks in devm_ti_sci_get_of_resource") that manually
add these calls. Rather than manually tracking allocations and
implementing free()s, rework things so that we follow expectations by
enabling the DEVRES functionality (outside of xPL phases).
This turns DEVRES from a prompted symbol to a symbol that must be
select'd, and we now remove our non-managed alloc/free functions from
outside of xPL builds.
Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Tom Rini <trini@konsulko.com>
Exynos7870's DWC3 glue layer is quite simple, consisting of a few
clocks, which is handled by this driver. Add the compatible string in
here.
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Documentation [1] states that the default value of the dr_mode property
is "otg". It also isn't marked a mandatory node, so it may or may not be
set. So, accordingly if dr_mode is not mentioned in the devicetree node,
OTG mode must be assumed.
In this driver however, this case is not handled. If dr_mode is not
mentioned, USB_DR_MODE_UNKNOWN is set. The logic implemented raises an
error, instead of falling back to USB_DR_MODE_OTG. Correct this to
conform to the specification.
Link: https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/usb/usb-drd.yaml?h=v6.18-dts [1]
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
We should avoid overwhelming users with non-essential messages.
The message 'Starting the controller' is not written for EHCI.
We should not write it for XHCI either.
Adjust the Python test accordingly.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
We should avoid overwhelming users with non-essential messages.
'Register NbrPorts' is a debug message for EHCI. Do the same for XHCI.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
This driver cannot build when DM_USB_GADGET is enabled as both options
control building of files that use the same global namespace and
functionality. In this case make CI_UDC depend on DM_USB_GADGET being
disabled as non-DM support is the legacy choice.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
All instances of the U_BOOT_DRIVER must use a unique name or they will
lead to link time failures due to name space conflicts when both are
present. Most of the XHCI drivers follow pattern of xhci_xxx in their
name, but a few used "usb_xhci". Change these to follow the pattern of
the rest of the XHCI glue drivers.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
The DWC2 OTG driver depends on an ARM-specific header file to compile,
so make it depend on ARM.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
The last of the users of the legacy musb drivers have been
migrated so now remove the old musb stack, all users should
now be using the new musb stack if they need this functionality.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
[trini: Remove a Makefile reference that was missed in v1]
Signed-off-by: Tom Rini <trini@konsulko.com>
It makes no sense to ask about nor enable SPL_USB_GADGET without
SPL_FRAMEWORK being enabled. Attempting to do so leads to Kconfig noting
dependency issues. Add the missing dependency.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
Since the EHCI USB driver is shared across i.MX91, i.MX93, i.MX94, and
i.MX95, the condition check is updated to use IMX9.
Signed-off-by: Alice Guo <alice.guo@nxp.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
If OF_CONTROL is on, ti-musb.c registers a "ti-musb-wrapper" driver
that requires UCLASS_MISC. Hence, select MISC if both OF_CONTROL
and USB_MUSB_TI are selected.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
A variety of Qualcomm features/fixes for this cycle, notably with a few
new platforms gaining support:
* Initial support for SDM670 (similar to SDM845), SM6350, and SM7150
platforms is added
* USB and UART issues on MSM8916 are addressed (improving stability/
reliability)
* Firmware loading is implemented for the GENI serial engine, this is
used on some platforms to load firmware for i2c/spi/uart to work
Some additional patches like binman support for building MBN files still
need some additional work.
CI: 8ef6ac07b3/pipelines
You cannot test an unsigned member of a struct for being negative, the
test will always fail. Instead assign the return value of
fdtdec_get_int, which returns an int, to a temporary variable declared
as an int, so that it can be tested for being negative before being
assigned to the unsigned struct member.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
epnum is used as an index into an array. The limit check for this index
should be performed before using it to access an element in the array to
prevent possible bounds overrun.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
A null check for the variable 'data' was introduced before dereferencing
it for set_phy_power but other uses were not so protected. Add the null
check for other dereferences of 'data'.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
The variable node is assigned to the return value of a function that
returns an int. It is tested for being negative and then passed as an
argument to a function that takes an int. So 'node' should not be
declared as unsigned. Correct it.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Combining two bits into a mask to be used so that the same write code
can be used to set or reset bits in a register clearly needs to use the
binary 'or' operator, not the binary 'and'. Fix it.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
When a variable needs a null check before it is dreferenced ensure that
this is done even in the case of assignment on declaration. This was not
happening for lurb_priv so correct it.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
fsl_fdt_fixup_usb_erratum uses strcmp to detect an error but then
returns 'err' without it being set to an error. Calling code may not
detect that an error occurred leading to a silent failure. Instead just
return -EINVAL.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
THe variable node is assigned to the return value of a function that
returns an int. It is tested for being negative and then passed as an
argument to a function that takes an int. So 'node' should not be
declared as unsigned. Correct it.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
These files had '#include<file.h>' rather than '#include <file.h>' which
while functional is not the correct style.
Signed-off-by: Tom Rini <trini@konsulko.com>
A few of the USB musb-new host glue drivers cannot build without access
to some platform specific header files. Express those requirements in
Kconfig as well.
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
A few of the USB host drivers cannot build without access to some
platform specific header files. Express those requirements in Kconfig as
well.
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
This driver was never enabled by any platforms after being added to the
tree over 5 years ago. Remove it.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
This driver is unused since the removal of the bcm28155_ap board in
commit 0f6807e77b ("arm: Remove bcm28155_ap board"). Remove it.
Fixes: 0f6807e77b ("arm: Remove bcm28155_ap board")
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
This driver requires some mach-at91 specific header files in order to build.
Express that requirement in Kconfig as well.
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
A few of the platform specific DWC3 host glue drivers cannot build
without access to some platform specific header files. Express those
requirements in Kconfig as well.
Reviewed-by: Marek Vasut <marek.vasut@mailbox.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Anshul Dalal <anshuld@ti.com> says:
On various TI's K3 platforms boot failure was observed on SPI NOR since the
commit 5609f200d0 ("arm: Kconfig: enable LTO for ARCH_K3"). This issue was
root caused to stack corruption by the 'udma_transfer' function. Where the local
variable 'paddr' of type 'dma_addr_t' was being written to as a 64-bit value
which overwrote the stack frame of the caller (dma_memcpy) as only 32-bits had
been reserved for paddr on the stack, specifically the r4 register in the frame
of dma_memcpy was being overwritten with a 0.
drivers/dma/ti/k3-udma.c:2192:
int udma_transfer(...)
{
...
dma_addr_t paddr = 0;
...
/* paddr was written to as 64-bit value here */
udma_poll_completion(uc, &paddr);
}
drivers/dma/dma-uclass.c:234:
int dma_memcpy(...)
{
dma_addr_t destination;
dma_addr_t source;
int ret;
...
/* This call resolves to udma_transfer */
ret = ops->transfer(...);
...
dma_unmap_single(destination, ...);
dma_unmap_single(...);
return ret;
}
Enabling LTO changed how gcc mapped local variables of dma_memcpy to CPU
registers, where earlier the bug was hidden since the overwritten register
'r4' was allotted to 'ret' but was allotted to 'destination' once LTO was
enabled. And since the overwritten value was 0, the bug remained undetected
as it just meant ret was 0, but having 'destination' set to 0 caused
dma_unmap_single to fail silently leading to boot failures.
The fix entails enabling DMA_ADDR_T_64BIT which changes dma_addr_t from u32 to
u64 for the R5 SPL thus reserving enough space for 'paddr' to prevent the
overflow.
Link: https://lore.kernel.org/r/20250903115207.572304-1-anshuld@ti.com
dma_addr_t is used to store any valid DMA address which might not
necessarily be the same size as host architecture's word size. Though
various typecasts in k3's dma and usb driver expect dma_addr_t to be the
same size as the word size.
This leads the compiler to throw a "cast from pointer to integer of
different size" warning when the condition is not met, for example when
enabling CONFIG_DMA_ADDR_T_64BIT for the R5 core.
Therefore this patch fixes the typecasts by using 'uintptr_t' as an
intermediary type which is guaranteed to be the same size as void* on
the host architecture. Thus, eliminating the compiler warning.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
