April 2024 - U-Boot

[PATCH 0/3] qcom: serial_msm: calculate UARTDM_CSR automatically
by Caleb Connolly 15 Apr '24

15 Apr '24

The msm serial UART controller has a bit clock divider register which much be programmed based on the UART clock. This changes per soc and currently is expected to be specified in DT or otherwise selected per board. This series fixes the apq8016 and ipq4019 clock drivers to return the programmed UART clock rate in clk_set_rate(), it then uses this clock rate and the hardcoded baud rate supported by this driver to calculate the correct value for the UARTDM_CSR register. --- Caleb Connolly (3): clk/qcom: apq8016: return valid rate when setting UART clock clk/qcom: ipq4019: return valid rate when setting UART clock serial: msm: calculate bit clock divider doc/device-tree-bindings/serial/msm-serial.txt | 10 --- drivers/clk/qcom/clock-apq8016.c | 4 +- drivers/clk/qcom/clock-ipq4019.c | 2 +- drivers/serial/serial_msm.c | 87 +++++++++++++++++++++----- 4 files changed, 73 insertions(+), 30 deletions(-) --- base-commit: 42f6978987336cff3d98d9cc4643c54a1eb0f36d // Caleb (they/them)

2 6

[PATCH] ARM: stm32: Initialize TAMP_SMCR BKP..PROT fields on STM32MP15xx
by Marek Vasut 15 Apr '24

15 Apr '24

In case of an OTP-CLOSED STM32MP15xx system, the CPU core 1 cannot be released from endless loop in BootROM only by populating TAMP BKPxR 4 and 5 with magic and branch address and sending SGI0 interrupt from core 0 to core 1 twice. TAMP_SMCR BKP..PROT fields must be initialized as well to release the core 1 from endless loop during the second SGI0 handling on core 1. Initialize TAMP_SMCR to protect the first 16 backup registers, the ones which contain the core 1 magic, branch address and boot information. This requirement seems to be undocumented, therefore it was necessary to trace and analyze the STM32MP15xx BootROM using OpenOCD and objdump. Ultimately, it turns out that a certain BootROM function reads out the TAMP_SMCR register and tests whether the BKP..PROT fields are non-zero. If they are zero, the BootROM code again waits for SGI0 using WFI, else the execution moves forward until it reaches handoff to the TAMP BKPxR 5 branch address. This fixes CPU core 1 release using U-Boot PSCI implementation on an OTP-CLOSED system, i.e. system with fuse 0 bit 6 set. Signed-off-by: Marek Vasut <marex(a)denx.de> --- Cc: Igor Opaniuk <igor.opaniuk(a)foundries.io> Cc: Patrice Chotard <patrice.chotard(a)foss.st.com> Cc: Patrick Delaunay <patrick.delaunay(a)foss.st.com> Cc: Simon Glass <sjg(a)chromium.org Cc: Simon Glass <sjg(a)chromium.org> Cc: Tom Rini <trini(a)konsulko.com> Cc: u-boot(a)dh-electronics.com Cc: uboot-stm32(a)st-md-mailman.stormreply.com --- arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c index dd99150fbc2..138a6d6b614 100644 --- a/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c +++ b/arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c @@ -14,6 +14,7 @@ #include <asm/arch/sys_proto.h> #include <dm/device.h> #include <dm/uclass.h> +#include <linux/bitfield.h> /* RCC register */ #define RCC_TZCR (STM32_RCC_BASE + 0x00) @@ -41,6 +42,9 @@ #define TZC_REGION_ID_ACCESS0 (STM32_TZC_BASE + 0x114) #define TAMP_CR1 (STM32_TAMP_BASE + 0x00) +#define TAMP_SMCR (STM32_TAMP_BASE + 0x20) +#define TAMP_SMCR_BKPRWDPROT GENMASK(7, 0) +#define TAMP_SMCR_BKPWDPROT GENMASK(23, 16) #define PWR_CR1 (STM32_PWR_BASE + 0x00) #define PWR_MCUCR (STM32_PWR_BASE + 0x14) @@ -136,6 +140,18 @@ static void security_init(void) */ writel(0x0, TAMP_CR1); + /* + * TAMP: Configure non-zero secure protection settings. This is + * checked by BootROM function 35ac on OTP-CLOSED device during + * CPU core 1 release from endless loop. If secure protection + * fields are zero, the core 1 is not released from endless + * loop on second SGI0. + */ + clrsetbits_le32(TAMP_SMCR, + TAMP_SMCR_BKPRWDPROT | TAMP_SMCR_BKPRWDPROT, + FIELD_PREP(TAMP_SMCR_BKPRWDPROT, 0x10) | + FIELD_PREP(TAMP_SMCR_BKPWDPROT, 0x10)); + /* GPIOZ: deactivate the security */ writel(BIT(0), RCC_MP_AHB5ENSETR); writel(0x0, GPIOZ_SECCFGR); -- 2.43.0

2 2

[PATCH v2] usb: dwc3-generic: fix support without DM_REGULATOR
by Robert Marko 15 Apr '24

15 Apr '24

Recent addition of vbus-supply support has broke platform which dont use controllable regulators for USB. Issue is that even withou DM_REGULATOR being enabled regulator related functions will still build as there is a stub in regulator.h but they will simply return -ENOSYS which will then make dwc3_generic_host_probe() return the same error thus breaking probe. So, check whether return code is -ENOSYS before erroring out. Fixes: de451d5d5b6f ("usb: dwc3-generic: support external vbus regulator") Signed-off-by: Robert Marko <robert.marko(a)sartura.hr> --- Changes in v2: * Drop #ifdefs and check for -ENOSYS that regulator stub returns drivers/usb/dwc3/dwc3-generic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c index 7a00529a2a..df0b0b8c02 100644 --- a/drivers/usb/dwc3/dwc3-generic.c +++ b/drivers/usb/dwc3/dwc3-generic.c @@ -248,7 +248,7 @@ static int dwc3_generic_host_probe(struct udevice *dev) /* Only returns an error if regulator is valid and failed to enable due to a driver issue */ rc = regulator_set_enable_if_allowed(priv->vbus_supply, true); - if (rc) + if (rc && rc != -ENOSYS) return rc; hccr = (struct xhci_hccr *)priv->gen_priv.base; -- 2.44.0

2 1

[PATCH] usb: dwc3-generic: fix support without DM_REGULATOR
by Robert Marko 15 Apr '24

15 Apr '24

Recent addition of vbus-supply support has broke platform which dont use controllable regulators for USB. Issue is that even withou DM_REGULATOR being enabled regulator related functions will still build as there is a stub in regulator.h but they will simply return -ENOSYS which will then make dwc3_generic_host_probe() return the same error thus breaking probe. Fixes: de451d5d5b6f ("usb: dwc3-generic: support external vbus regulator") Signed-off-by: Robert Marko <robert.marko(a)sartura.hr> --- drivers/usb/dwc3/dwc3-generic.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/usb/dwc3/dwc3-generic.c b/drivers/usb/dwc3/dwc3-generic.c index 7a00529a2a..784d3ec2ed 100644 --- a/drivers/usb/dwc3/dwc3-generic.c +++ b/drivers/usb/dwc3/dwc3-generic.c @@ -242,6 +242,7 @@ static int dwc3_generic_host_probe(struct udevice *dev) if (rc) return rc; +#if CONFIG_IS_ENABLED(DM_REGULATOR) rc = device_get_supply_regulator(dev, "vbus-supply", &priv->vbus_supply); if (rc) debug("%s: No vbus regulator found: %d\n", dev->name, rc); @@ -250,14 +251,17 @@ static int dwc3_generic_host_probe(struct udevice *dev) rc = regulator_set_enable_if_allowed(priv->vbus_supply, true); if (rc) return rc; +#endif hccr = (struct xhci_hccr *)priv->gen_priv.base; hcor = (struct xhci_hcor *)(priv->gen_priv.base + HC_LENGTH(xhci_readl(&(hccr)->cr_capbase))); rc = xhci_register(dev, hccr, hcor); +#if CONFIG_IS_ENABLED(DM_REGULATOR) if (rc) regulator_set_enable_if_allowed(priv->vbus_supply, false); +#endif return rc; } @@ -265,14 +269,18 @@ static int dwc3_generic_host_probe(struct udevice *dev) static int dwc3_generic_host_remove(struct udevice *dev) { struct dwc3_generic_host_priv *priv = dev_get_priv(dev); +#if CONFIG_IS_ENABLED(DM_REGULATOR) int rc; +#endif /* This function always returns 0 */ xhci_deregister(dev); +#if CONFIG_IS_ENABLED(DM_REGULATOR) rc = regulator_set_enable_if_allowed(priv->vbus_supply, false); if (rc) debug("%s: Failed to disable vbus regulator: %d\n", dev->name, rc); +#endif return dwc3_generic_remove(dev, &priv->gen_priv); } -- 2.44.0

3 5

[PATCH] mmc: arm_pl180: Limit data transfer to U16_MAX
by cmax＠mailbox.org 15 Apr '24

15 Apr '24

From: max <cmax(a)mailbox.org> Currently fetching files bigger that cause a data transfer greater than U16_MAX fails. The reason is that the specification defines the datalength register as a 16 bit wide register, but in u-boot it is used as if it is an 32 bit register. Therefore values greater than U16_MAX cause an infinite loop inside u-boot. U-boot expects to get more data from interface/hardware then it will ever get and therefore inifintely waits for more data that will never come. Signed-off-by: max <cmax(a)mailbox.org> Cc: Peng Fan <peng.fan(a)nxp.com> Cc: Jaehoon Chung <jh80.chung(a)samsung.com> --- drivers/mmc/arm_pl180_mmci.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/mmc/arm_pl180_mmci.c b/drivers/mmc/arm_pl180_mmci.c index 5cf5502ed5..af2f9a5a84 100644 --- a/drivers/mmc/arm_pl180_mmci.c +++ b/drivers/mmc/arm_pl180_mmci.c @@ -231,6 +231,7 @@ static int do_data_transfer(struct mmc *dev, u32 blksz = 0; u32 data_ctrl = 0; u32 data_len = (u32) (data->blocks * data->blocksize); + assert(data_len < U16_MAX); // should be ensured by arm_pl180_get_b_max if (!host->version2) { blksz = (ffs(data->blocksize) - 1); @@ -358,6 +359,14 @@ static int host_set_ios(struct mmc *dev) return 0; } +static int arm_pl180_get_b_max(struct udevice *dev, void *dst, lbaint_t blkcnt) +{ + struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev); + struct mmc *mmc = upriv->mmc; + + return U16_MAX / mmc->read_bl_len; +} + #ifndef CONFIG_DM_MMC /* MMC uses open drain drivers in the enumeration phase */ static int mmc_host_reset(struct mmc *dev) @@ -373,6 +382,7 @@ static const struct mmc_ops arm_pl180_mmci_ops = { .send_cmd = host_request, .set_ios = host_set_ios, .init = mmc_host_reset, + .get_b_max = arm_pl180_get_b_max, }; /* @@ -531,6 +541,7 @@ static const struct dm_mmc_ops arm_pl180_dm_mmc_ops = { .send_cmd = dm_host_request, .set_ios = dm_host_set_ios, .get_cd = dm_mmc_getcd, + .get_b_max = arm_pl180_get_b_max, }; static int arm_pl180_mmc_of_to_plat(struct udevice *dev) -- 2.43.0

3 7

[PATCH v11 1/2] dt-bindings: mtd: fixed-partitions: Add alignment properties
by Simon Glass 15 Apr '24

15 Apr '24

Add three properties for controlling alignment of partitions, aka 'entries' in fixed-partition. For now there is no explicit mention of hierarchy, so a 'section' is just the 'fixed-partitions' node. These new properties are inputs to the Binman packaging process, but are also needed if the firmware is repacked, to ensure that alignment constraints are not violated. Therefore they are provided as part of the schema. Signed-off-by: Simon Glass <sjg(a)chromium.org> Reviewed-by: Rob Herring <robh(a)kernel.org> --- Changes in v11: - Drop mention of Binman - Use 'content' instead of 'contents' Changes in v10: - Update the minimum to 2 Changes in v9: - Move binding example to next batch to avoid build error Changes in v7: - Drop patch 'Add binman compatible' - Put the alignment properties into the fixed-partition binding Changes in v6: - Correct schema-validation errors missed due to older dt-schema (enum fix and reg addition) Changes in v5: - Add value ranges - Consistently mention alignment must be power-of-2 - Mention that alignment refers to bytes Changes in v2: - Fix 'a' typo in commit message .../bindings/mtd/partitions/partition.yaml | 51 +++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml index 1ebe9e2347ea..31bbeb161396 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml +++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml @@ -57,6 +57,57 @@ properties: user space from type: boolean + align: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 2 + maximum: 0x80000000 + multipleOf: 2 + description: + This sets the alignment of the entry in bytes. + + The entry offset is adjusted so that the entry starts on an aligned + boundary within the containing section or image. For example ‘align = + <16>’ means that the entry will start on a 16-byte boundary. This may + mean that padding is added before the entry. The padding is part of + the containing section but is not included in the entry, meaning that + an empty space may be created before the entry starts. Alignment + must be a power of 2. If ‘align’ is not provided, no alignment is + performed. + + align-size: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 2 + maximum: 0x80000000 + multipleOf: 2 + description: + This sets the alignment of the entry size in bytes. It must be a power + of 2. + + For example, to ensure that the size of an entry is a multiple of 64 + bytes, set this to 64. While this does not affect the content of the + entry itself (the padding is performed only when its parent section is + assembled), the end result is that the entry ends with the padding + bytes, so may grow. If ‘align-size’ is not provided, no alignment is + performed. + + align-end: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 2 + maximum: 0x80000000 + multipleOf: 2 + description: + This sets the alignment (in bytes) of the end of an entry with respect + to the containing section. It must be a power of 2. + + Some entries require that they end on an alignment boundary, + regardless of where they start. This does not move the start of the + entry, so the content of the entry will still start at the beginning. + But there may be padding at the end. While this does not affect the + content of the entry itself (the padding is performed only when its + parent section is assembled), the end result is that the entry ends + with the padding bytes, so may grow. If ‘align-end’ is not provided, + no alignment is performed. + if: not: required: [ reg ] -- 2.34.1

2 3

[PATCH] mmc: cv1800b_sdhci: Remove the unused argument
by Jaehoon Chung 15 Apr '24

15 Apr '24

Remove the unused argument about cmd_error. Fixes: a3b2786651c7 ("mmc: Drop unused mmc_send_tuning() cmd_error parameter") Signed-off-by: Jaehoon Chung <jh80.chung(a)samsung.com> 1 --- drivers/mmc/cv1800b_sdhci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/cv1800b_sdhci.c b/drivers/mmc/cv1800b_sdhci.c index 2275c5377723..9af6b9719844 100644 --- a/drivers/mmc/cv1800b_sdhci.c +++ b/drivers/mmc/cv1800b_sdhci.c @@ -42,7 +42,7 @@ static int cv1800b_execute_tuning(struct mmc *mmc, u8 opcode) for (tap = 0; tap < TUNE_MAX_PHCODE; tap++) { cv1800b_set_tap_delay(host, tap); - if (mmc_send_tuning(host->mmc, opcode, NULL)) { + if (mmc_send_tuning(host->mmc, opcode)) { current_size = 0; } else { current_size++; -- 2.25.1

1 1

[PATCH v2 1/2] lmb: Avoid to add identical region in lmb_add_region_flags()
by Patrice Chotard 15 Apr '24

15 Apr '24

In case lmb_add_region_flags() is called with the same parameter than an already existing lmb and this lmb is adjacent to its previous lmb with different flag, this lmb is added again. Instead breaking the loop, continue, at the next iteration, we are able to detect that this region already exist. Issue reproduced on STM32MP157-DK2 with SCMI DT, bdinfo command's output shows: Before this patch, the last LMB [0xde000000-0xdfffffff] is duplicated: ... lmb_dump_all:nnn memory.cnt = 0x1 / max = 0x2 memory[0] [0xc0000000-0xdfffffff], 0x20000000 bytes flags: 0 reserved.cnt = 0x6 / max = 0x10 reserved[0] [0x10000000-0x10045fff], 0x00046000 bytes flags: 4 reserved[1] [0x30000000-0x3003ffff], 0x00040000 bytes flags: 4 reserved[2] [0x38000000-0x3800ffff], 0x00010000 bytes flags: 4 reserved[3] [0xdaadf000-0xdfffffff], 0x05521000 bytes flags: 0 reserved[4] [0xde000000-0xdfffffff], 0x02000000 bytes flags: 4 reserved[5] [0xde000000-0xdfffffff], 0x02000000 bytes flags: 4 ... After this patch: ... lmb_dump_all: memory.cnt = 0x1 / max = 0x2 memory[0] [0xc0000000-0xdfffffff], 0x20000000 bytes flags: 0 reserved.cnt = 0x5 / max = 0x10 reserved[0] [0x10000000-0x10045fff], 0x00046000 bytes flags: 4 reserved[1] [0x30000000-0x3003ffff], 0x00040000 bytes flags: 4 reserved[2] [0x38000000-0x3800ffff], 0x00010000 bytes flags: 4 reserved[3] [0xdaadf000-0xdfffffff], 0x05521000 bytes flags: 0 reserved[4] [0xde000000-0xdfffffff], 0x02000000 bytes flags: 4 ... Fixes: 59c0ea5df33f ("lmb: Add support of flags for no-map properties") Signed-off-by: Patrice Chotard <patrice.chotard(a)foss.st.com> --- (no changes since v1) lib/lmb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/lmb.c b/lib/lmb.c index 44f98205310..b6afb731440 100644 --- a/lib/lmb.c +++ b/lib/lmb.c @@ -285,14 +285,14 @@ static long lmb_add_region_flags(struct lmb_region *rgn, phys_addr_t base, adjacent = lmb_addrs_adjacent(base, size, rgnbase, rgnsize); if (adjacent > 0) { if (flags != rgnflags) - break; + continue; rgn->region[i].base -= size; rgn->region[i].size += size; coalesced++; break; } else if (adjacent < 0) { if (flags != rgnflags) - break; + continue; rgn->region[i].size += size; coalesced++; break; -- 2.25.1

3 5

[PATCH 0/4] mtd: Make sure UBIFS does not do multi-pass page programming on flashes that don't support it
by tkuw584924＠gmail.com 15 Apr '24

15 Apr '24

From: Takahiro Kuwano <Takahiro.Kuwano(a)infineon.com> This series is equivalent to the one for Linux MTD submitted by Pratyush Yadav. https://patchwork.ozlabs.org/project/linux-mtd/list/?series=217759&state=* Takahiro Kuwano (4): mtd: ubi: Do not zero out EC and VID on ECC-ed NOR flashes mtd: spi-nor: Allow flashes to specify MTD writesize mtd: spi-nor-core: Rework default_init() to take flash_parameter mtd: spi-nor: Set ECC unit size to MTD writesize in Infineon SEMPER flashes drivers/mtd/spi/spi-nor-core.c | 45 +++++++++++++++++++++++++--------- drivers/mtd/ubi/build.c | 4 +-- drivers/mtd/ubi/io.c | 9 ++++++- include/linux/mtd/spi-nor.h | 1 + 4 files changed, 44 insertions(+), 15 deletions(-) -- 2.34.1

3 13

[PATCH v2 0/3] mmc: hi6220-dwmmc: handle resets and clocks
by Yang Xiwen via B4 Relay 15 Apr '24

15 Apr '24

Also allow setup fifoth_val in driver Signed-off-by: Yang Xiwen <forbidden405(a)outlook.com> --- Changes in v2: - dw-mmc: proceed if data busy found - hi6220-dw-mmc: add fifoth_val setup, separate hi3798mv200 data - Link to v1: https://lore.kernel.org/r/20240119-mmc-v1-1-aee6b2cf6902@outlook.com --- Yang Xiwen (3): mmc: hi6220-dwmmc: handle clocks and resets if CONFIG_CLK and CONFIG_DM_RESET enabled mmc: dw_mmc: Don't return error if data busy timeout mmc: hi6220_dw_mmc: add fifoth_val to private data and set it in .probe drivers/mmc/dw_mmc.c | 4 +-- drivers/mmc/hi6220_dw_mmc.c | 72 +++++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 72 insertions(+), 4 deletions(-) --- base-commit: f7cca7ccc5117eaafcc2bde91ad1bed6fee7cfc3 change-id: 20240119-mmc-9cf7f3455cb4 Best regards, -- Yang Xiwen <forbidden405(a)outlook.com>

3 12