Add the compatible for Exynos8895 UART as described in upstream
devicetree bindings. This enables support for Exynos8895 and other
similar UART devices, such as Exynos7870. Other than that, the driver
works as-is.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Reviewed-by: Henrik Grimler <henrik@grimler.se>
Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
I have a hunch VPL_DM_SERIAL should not be selectable if VPL isn't set
as implied by the prefix. Additionally, still based on the prefix, I'm
assuming VPL_DM should be a dependency. Since VPL_DM can only be
selectable when VPL is enabled, only depend on VPL_DM.
This mirrors SPL_DM_SERIAL and TPL_DM_SERIAL so seems right to me.
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Teach the GENI UART driver to load firmware, similar to i2c.
This is primarily intended for non-debug UARTs, but since we don't
support using these as the console we abort probe for now.
Remove duplicated register macros that are in the common geni-se header.
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-7-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
Enable the serial engine clk in probe so that this driver can work on
platforms that don't already initialize the clk for this device before
this driver runs. This fixes a problem I see on Coreboot platforms like
Trogdor where the UART hardware isn't enabled by coreboot unless the
serial console build is used.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-6-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
Qualcomm peripherals like UART, SPI, I2C, etc are all exposed under a
common GENI Serial Engine wrapper device. Replace the stub driver we use
for this currently with a full-on misc device and implement support for
loading peripheral firmware.
Each of the peripherals has it's own protocol-specific firmware, this is
stored on the internal storage of the device with a well-known partition
type GUID.
To support this, GENI will bind peripherals in two stages. First the
ones that already have firmware loaded (such as the serial port) are
bound in the typical way. But devices that require firmware loading are
deferred until EVT_LAST_STAGE_INIT. At this point we can be sure that
the storage device is available, so we load the firmware and then bind
and probe the remaining children.
Child devices are expected to determine if firmware loading is necessary
and call qcom_geni_load_firmware().
Since Linux currently doesn't support loading firmware (and firmware may
not be available), we probe all GENI peripherals to ensure that they
always load firmware if necessary.
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://patch.msgid.link/20250714-geni-load-fw-v5-3-5abbc0d29838@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
The UART DM controller supports different channel data packing modes,
either the 4-character packing mode (where 32-bit are read/written at once)
or the single-character mode (where only a single character is read/written
at a time). The 4-character mode can be more efficient, but the
single-character mode is much easier to implement.
At the moment, serial_msm uses the 4-character mode. Since the
dm_serial_ops operate on one character at the time, the code goes through
quite some hoops in order to break this down to single characters. This
code is prone to race conditions (e.g. priv->chars_cnt is read from the
registers, then a command is issued, what if another char came in
inbetween?). It also seems to cause another subtle issue with autoboot:
Unlike the previous autoboot failures that happened when UART was
disconnected, this problem occurs when UART is connected and open in a
terminal: For EFI boot, the console size is queried in efi_console.c
query_console_serial() by sending an ANSI escape code via UART. For some
reason, with the current driver we get yet another 0x00 byte (UART break
event?) when reading the reply from serial input. Because of that, reading
the console size fails in efi_console.c, the actual reply remains in the
UART buffer, and later the boot flow aborts because it detects input after
printing a prompt.
Rather than trying to fix the issue in the current complicated approach,
switch the driver to use the single-character mode. This is simple and
straightforward to implement without race conditions:
- We write one character at a time to UARTDM_TF, as long as the TX FIFO
has space available (TX_READY). To flush the console before starting
Linux, we wait for TX_EMPTY.
- We read one character at a time from UARTDM_RF and strip off the
additional error information (assuming there is something in the
RX FIFO, as indicated by RX_READY).
In this mode, querying the serial console size works and autoboot is no
longer interrupted. The overall code is also much shorter.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-6-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
The documentation for the UART controller in the APQ8016E specifies that
both RESET and ENABLE commands must be issued to set up the receiver and
transmitter, but at the moment we only issue RESET. This doesn't seem to
cause issues in practice (looks like the reset already re-enables the
receiver/transmitter), but let's add the two writes to RX_ENABLE/TX_ENABLE
to better match the recommendations in the documentation.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-5-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
According to the documentation of the UART controller in the APQ8016E TRM,
clearing bits inside UARTDM_DMEN requires resetting the transmitter and/or
receiver. We do reset inside uart_dm_init(), but before writing to
UARTDM_DMEN. This doesn't seem to cause problems in practice, but let's
move the reset to the end of uart_dm_init() to better match the
recommendations in the documentation.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-4-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
Some of the register definitions are inconsistently named (likely copied
as-is from Qualcomm's Little Kernel/LK bootloader, which uses the
MSM_BOOT_UART naming scheme). Rename them to be in line with the other
register definitions and move them up to be next to the related register.
No functional change.
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-3-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
There have been issues with autoboot on DB410c for years, where autoboot
gets interrupted by spurious input on the UART console. Back in 2021, I've
tried to fix this by inserting a delay before UART initialization, but it
has turned out this is not working reliably either.
It looks like the root cause has always been the lack of bias-pull-up,
which was causing the RX line to be floating when UART is disconnected.
The delay does not seem to be needed anymore when applying bias-pull-up,
so drop it again in favor of the proper fix.
This reverts commit ad7e967738a9c639e07cf50b83ffccdf9a8537b0.
Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
Tested-by: Alexey Minnekhanov <alexeymin@minlexx.ru>
Acked-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250908-db410c-autoboot-fixes-v2-2-316ed98e0143@linaro.org
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
The previous description "Qualcomm snapdragon" barely tells the user
anything, update the name so that it's clear which configs the user can
choose between, namely the older QUP driver, or the newer GENI driver.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20250924-2025-10-misc-v1-3-7e75842ca714@fairphone.com
Signed-off-by: Casey Connolly <kcxt@postmarketos.org>
The HSCIF RX FIFO may overflow when data are streaming from remote end
into the HSCIF while U-Boot is still starting up. In that case, HSFSR
bit RDF is set, but HSFDR field R is zero. This confuses .tstc callback
into considering RX FIFO to be empty, which leads to .getc to be never
invoked, even when user attempts to pass more input onto the command
line.
Fix this by considering the RDF flag in serial_rx_fifo_level(), which
is called from .tstc in case of no errors. If RDF flag is set, trigger
the .getc callback and let it clear the RX FIFO.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
int is not sufficient to hold and test the return from an EFI function
call. Use efi_status_t instead so that the test can work as expected.
This issue was found by Smatch.
Fixes: 275854baeeec ("efi: Add a serial driver")
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
mbv:
- Add it to CI loop
versal2:
- Wire UFS driver
serial:
- Add support for OF_PLATDATA in uartlite
misc:
- Mark some structures as const
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQSXAixArPbWpRanWW+rB/7wTvUR9QUCaK/+ogAKCRCrB/7wTvUR
9cEHAQCFDHtOgW2QmXuwj4MGdK7UKp6DTxe4JapDeoDNRpLHXAEA6ygNox8bv8gw
zl71OxHQO+5W8yayUWceqIzTbdYTbAo=
=Qkr4
-----END PGP SIGNATURE-----
Merge tag 'xilinx-for-v2026.01-rc1' of https://source.denx.de/u-boot/custodians/u-boot-microblaze into next
AMD/Xilinx/FPGA changes for v2026.01-rc1
mbv:
- Add it to CI loop
versal2:
- Wire UFS driver
serial:
- Add support for OF_PLATDATA in uartlite
misc:
- Mark some structures as const
In get_lpuart_clk_rate if the call to clk_get_rate returns an error then
the call to return should pass the value of the error which is in rate
rather than ret which will be 0 as its value is not affected by this
error.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
The first change is to list DM_DRIVER_ALIAS for compatible string to be
able to match the driver. Only xps one is listed because opb one is likely
unused for quite a long time.
The second change is to add dtplat structure to plat data and fill register
base in probe.
Signed-off-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/b494dbad529e919d33977b8ea6e6dbcd14e78907.1753261604.git.michal.simek@amd.com
serial_find_console_or_panic() may left cur_serial_dev unassigned if
REQUIRE_SERIAL_CONSOLE is not set. Setting GD_FLG_SERIAL_READY in
this situation confuses serial console code. It tries to use
unassigned driver instead of debug port and stops printing.
So check cur_serial_dev before setting GD_FLG_SERIAL_READY to allow
console to keep printing via debug port.
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
A few serial drivers cannot build without access to some platform
specific header files. Express those requirements in Kconfig as well.
Signed-off-by: Tom Rini <trini@konsulko.com>
The NULL check for priv in qcom_geni_serial_poll_bit serves no useful
prupose as too much other code surrounding it relies on priv being
valid. Remove the NULL check for priv and other related code.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Link: https://lore.kernel.org/r/20250811-serial_msm_geni-v1-2-4499179491bc@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
In msm_serial_setbrg if the call to get_clk_div_rate fails then there
will not have been an assignment to clk_div which will lead to the call
to geni_serial_baud using an uninitialised value.
Check for an error from get_clk_div_rate and return an error code if so.
This issue was found by Smatch.
Signed-off-by: Andrew Goodbody <andrew.goodbody@linaro.org>
Reviewed-by: Casey Connolly <casey.connolly@linaro.org>
Link: https://lore.kernel.org/r/20250811-serial_msm_geni-v1-1-4499179491bc@linaro.org
Signed-off-by: Casey Connolly <casey.connolly@linaro.org>
With the removal of the last i.MX31 platform we can remove the rest of
the underlying architecture code as well.
Fixes: f247354708ec ("arm: Remove mx31pdk board")
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Peng Fan <peng.fan@nxp.com>
The high-speed UART from MediaTek supports baudrate accuracy
compensation when using high-speed mode 3.
This is done by calculating the first digit of the fraction part of
sample count value. The fraction value will be then used as the
reference to insert 0 to 10 sample cycle(s) to one frame (assume
that frame format is 8n1, i.e. 10 bits per frame).
The fracdiv_[l/m] registers are used to determine whether a bit in one frame
should be inserted with one sample cycle.
With typical 40MHz source clock, the actual baudrates with/without
accuracy compensation are:
Ideal w/o compensation w/ compensation
======== ================ ===============
9600 9603 9600
115200 114942 115207
921600 930232 921659
3000000 3076923 3007519
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Fix UART register names and offsets according to the programming
guide to allow implementing some enhanced features.
Signed-off-by: Weijie Gao <weijie.gao@mediatek.com>
Tom Rini <trini@konsulko.com> says:
This series switches to always using $(PHASE_) in Makefiles when
building rather than $(PHASE_) or $(XPL_). It also starts on documenting
this part of the build, but as a follow-up we need to rename
doc/develop/spl.rst and expand on explaining things a bit.
Link: https://lore.kernel.org/r/20250401225851.1125678-1-trini@konsulko.com
It is confusing to have both "$(PHASE_)" and "$(XPL_)" be used in our
Makefiles as part of the macros to determine when to do something in our
Makefiles based on what phase of the build we are in. For consistency,
bring this down to a single macro and use "$(PHASE_)" only.
Signed-off-by: Tom Rini <trini@konsulko.com>
Simon Glass <sjg@chromium.org> says:
The membuff implementation curently has no tests. It also assumes that
head and tail can never correspond unless the buffer is empty.
This series provides a compile-time flag to support a 'full' flag. It
also adds some tests of the main routines.
The data structure is also renamed to membuf which fits better with
U-Boot.
There may be some cases in the code which could be optimised a little,
but the implementation is functional.
Link: https://lore.kernel.org/r/20250318152059.1464369-1-sjg@chromium.org
The double 'f' is not necessary and is a bit annoying as elsewhere in
U-Boot we use 'buf'. Rename all the functions before it is used more
widely.
Signed-off-by: Simon Glass <sjg@chromium.org>
Depending on the platform, there may be multiple clock sources
required to enable a UART. Use the bulk functions to get and
enable the clocks when the UART probes. This can facilitate
the removal of functions to manually enable the clock.
This is made dependent on CLK_CCF which is used on imx6q,
imx8m[mnqp], several imxrt, imx9. If/when the UART clock
registration is done for older boards, this limitation
could be updated.
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
On PowerPC platforms with TPL enabled and SPL_SYS_NS16550_SERIAL
enabled, today this builds under TPL as well due to how $(XPL_) is
defined. Add the TPL_SYS_NS16550_SERIAL itself for consistency and
clarity.
Signed-off-by: Tom Rini <trini@konsulko.com>
- Restrict _debug_uart_init() usage in STM32 serial driver
- Add support for environment in eMMC on STM32MP13xx DHCOR SoM
- Introduce DH STM32MP15xx DHSOM board specific defconfigs
- Fix CONFIG_BOOTCOUNT_ALTBOOTCMD update on DH STM32MP1 DHSOM
- Update maintainer for board stm32f746-disco
- Fix Linux cmdline for stm32f769-disco
- Cleanup in stm32f***-u-boot.dtsi and in board_late_init() by removing
legacy led and button management.
-----BEGIN PGP SIGNATURE-----
iQJQBAABCgA6FiEEXyrViUccKBz9c35Jysd4L3sz/6YFAmfRsL4cHHBhdHJpY2Uu
Y2hvdGFyZEBmb3NzLnN0LmNvbQAKCRDKx3gvezP/psU2D/9LPdhwyvmi595AgjNf
0t4rqKKTPhjb43UZeuAnFOg4PJcH7eXd2tQq5htK+ir8jeLU7cZWRGjA6eXtRQni
IKYtWlz4OY/xuQhJbQqMBGb1EVJE432LlfVp3rKpCpBMoANU+h//opd/m4CKsMYN
SiIikf3Xasgy7APSGTQcNGZyzVcVPeL8e68hEAOuFfCBMmd4JRb7RMwro9mG+/SU
9PzOLvCEfNTq9k87vT8SH4UQHv/NF8OaH6v77SJFt+RHdQr/G9MNbdP5IVwuWkgU
CfcWRFzmofFACueZ/6vA+hFYarF5tsv043GJyJkTh/0CUbFx8vS0+x1WoL7YcviA
5Ro+tEEfpB1F1qLyOJV698l1vm3Zj452oZ6e2PBPMGqfKy1vkBjh9OjhfqpjILHX
uAkxxd/dx6FzK8jo4Qki7JT4W2MmD3jTeHsVunLOC1tS1f44MHwnjpZZH2ttXT/4
VLPkIYf9kKJA/squ0Lx+ZCjFtiM/XenWHhQxsO9QxKUqSHgBZuwBj8VRNRrMs/N+
3mN4PLNuYtagJjCvvsxiMg0aB7LH22kXA657nQfHM01WlR9I/B2K0aIil/I/kVV9
b9LtUven4sXUEexszEY/xFxF2utU+Xh57wKh+3qm2XVw8pfSKItvBXBK/lo/ULWV
62xL179ziFFGrE/2o/m87VT30w==
=xL/c
-----END PGP SIGNATURE-----
Merge tag 'u-boot-stm32-20250312' of https://source.denx.de/u-boot/custodians/u-boot-stm into next
CI: https://source.denx.de/u-boot/custodians/u-boot-stm/-/pipelines/25112
- Add drivers for MFD STM32 TIMERS and STM32 PWM and enable them on stm32mp135f-dk
- Restrict _debug_uart_init() usage in STM32 serial driver
- Add support for environment in eMMC on STM32MP13xx DHCOR SoM
- Introduce DH STM32MP15xx DHSOM board specific defconfigs
- Fix CONFIG_BOOTCOUNT_ALTBOOTCMD update on DH STM32MP1 DHSOM
- Update maintainer for board stm32f746-disco
- Fix Linux cmdline for stm32f769-disco
- Cleanup in stm32f***-u-boot.dtsi and in board_late_init() by removing
legacy led and button management.
Since commit 948da7773e34 ("arm: Add new config option ARCH_VERY_EARLY_INIT")
debug_uart_init() is called respectively in crt0.S and crt0_64.S.
That means that _debug_uart_init() is called for all STM32MP platforms
even for those which doesn't support SPL_BUILD.
So restrict _debug_uart_init() execution for platforms which can have
SPL_BUILD enabled (STM32MP1 platform only).
It's more needed to call debug_uart_init() in stm32mp1/cpu.c.
Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
The lone user of this driver has been removed for some time. Remove this
driver as well.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Link: https://lore.kernel.org/r/20250227205101.4127604-2-trini@konsulko.com
Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
serial_out_dynamic() takes a u8* addr and uses it for 8-bit or 32-bit
accesses, depending on the value of plat->reg_width. This results in a
pointer type mismatch that the compiler may even turn into an error:
drivers/serial/ns16550.c: In function ‘serial_out_dynamic’:
drivers/serial/ns16550.c:115:42: error: passing argument 1 of ‘out_be32’ from incompatible pointer type [-Wincompatible-pointer-types]
115 | out_be32(addr, value);
| ^~~~
| |
| u8 * {aka unsigned char *}
This error was observed on PowerPC.
Signed-off-by: J. Neuschäfer <j.ne@posteo.net>
Add compatible string for the Intel XScale variant of the 16550. Needed
to match upstream.
Signed-off-by: Duje Mihanović <duje.mihanovic@skole.hr>
Reviewed-by: Stefan Roese <sr@denx.de>
Move to OMAP specific implementation of certain ops functions as the UART
prints on the serial console fail for baudrates greater than 460800.
The MDR1 register is responsible for determining the speed mode at which
the UART should operate for OMAP specific devices. The baud divisor is used
to set the UART_DLL register which is used for generation of the baud
clock in the baud rate generator. The implementation logic is similar to
how it is implemented in omap_8250_get_divisor function of 8250_omap UART
linux driver.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Increase scope of ops functions and do some clean up for usage in device
-specific UART drivers.
Remove the static functionality of ops functions and migrate certain macros
to header file for usage in device-specific drivers.
Signed-off-by: Gokul Praveen <g-praveen@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The correct spelling is R-Car, including the dash, update the usage.
Kconfig strings and comment changes only, no functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Patrick Rudolph <patrick.rudolph@9elements.com> says:
Based on the existing work done by Simon Glass this series adds
support for booting aarch64 devices using ACPI only.
As first target QEMU SBSA support is added, which relies on ACPI
only to boot an OS. As secondary target the Raspberry Pi4 was used,
which is broadly available and allows easy testing of the proposed
solution.
The series is split into ACPI cleanups and code movements, adding
Arm specific ACPI tables and finally SoC and mainboard related
changes to boot a Linux on the QEMU SBSA and RPi4. Currently only the
mandatory ACPI tables are supported, allowing to boot into Linux
without errors.
The QEMU SBSA support is feature complete and provides the same
functionality as the EDK2 implementation.
The changes were tested on real hardware as well on QEMU v9.0:
qemu-system-aarch64 -machine sbsa-ref -nographic -cpu cortex-a57 \
-pflash secure-world.rom \
-pflash unsecure-world.rom
qemu-system-aarch64 -machine raspi4b -kernel u-boot.bin -cpu cortex-a72 \
-smp 4 -m 2G -drive file=raspbian.img,format=raw,index=0 \
-dtb bcm2711-rpi-4-b.dtb -nographic
Tested against FWTS V24.03.00.
Known issues:
- The QEMU rpi4 support is currently limited as it doesn't emulate PCI,
USB or ethernet devices!
- The SMP bringup doesn't work on RPi4, but works in QEMU (Possibly
cache related).
- PCI on RPI4 isn't working on real hardware since the pcie_brcmstb
Linux kernel module doesn't support ACPI yet.
Link: https://lore.kernel.org/r/20241023132116.970117-1-patrick.rudolph@9elements.com
When ACPI is enabled on arm it will use the getinfo function to fill
the SPCR ACPI table.
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Reviewed-by: Moritz Fischer <moritzf@google.com>
The initialization of upriv->buf doesn't check for a NULL return. But
there's actually no point in doing a separate, unconditional malloc()
in post_probe; we can just make serial_dev_priv contain the rx buffer
itself, and let the (larger) allocation be handled by the driver core
when it allocates the ->per_device_auto. The total run-time memory
used is mostly the same, we reduce the code size a little, and as a
bonus, struct serial_dev_priv does not contain the unused members when
!SERIAL_RX_BUFFER.
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
The help text says it must be a power of 2, and the implementation
does rely on that. Enforce it.
A violation gives a wall of text, but the last few lines should be
reasonably obvious:
drivers/serial/serial-uclass.c:334:9: note: in expansion of macro ‘BUILD_BUG_ON_NOT_POWER_OF_2’
334 | BUILD_BUG_ON_NOT_POWER_OF_2(CONFIG_SERIAL_RX_BUFFER_SIZE);
Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
