[PATCH 4/4] doc: signature: trim the future work list
Since U-Boot supports more RSA/SHA variants, as well as ECDSA, remove these items from the TODO list. Signed-off-by: Baruch Siach --- doc/uImage.FIT/signature.txt | 2 -- 1 file changed, 2 deletions(-) diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt index 240244b30e63..21eb3894aada 100644 --- a/doc/uImage.FIT/signature.txt +++ b/doc/uImage.FIT/signature.txt @@ -695,8 +695,6 @@ bootm. Possible Future Work -- Add support for other RSA/SHA variants, such as rsa4096,sha512. -- Other algorithms besides RSA - More sandbox tests for failure modes - Passwords for keys/certificates - Perhaps implement OAEP -- 2.39.2
[PATCH 1/4] doc: signature: update algorithms support description
U-Boot supports more hash and verification algorithms these days. Signed-off-by: Baruch Siach --- doc/uImage.FIT/signature.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt index c71280b63bb6..bc123f512f7b 100644 --- a/doc/uImage.FIT/signature.txt +++ b/doc/uImage.FIT/signature.txt @@ -42,8 +42,8 @@ device. Algorithms -- In principle any suitable algorithm can be used to sign and verify a hash. -At present only one class of algorithms is supported: SHA1 hashing with RSA. -This works by hashing the image to produce a 20-byte hash. +U-Boot supports a few hashing and verification algorithms. See below for +details. While it is acceptable to bring in large cryptographic libraries such as openssl on the host side (e.g. mkimage), it is not desirable for U-Boot. -- 2.39.2
[PATCH 3/4] doc: signature: describe how to enable ECDSA
Signed-off-by: Baruch Siach --- doc/uImage.FIT/signature.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt index b6707417ff63..240244b30e63 100644 --- a/doc/uImage.FIT/signature.txt +++ b/doc/uImage.FIT/signature.txt @@ -439,6 +439,7 @@ be enabled: CONFIG_FIT_SIGNATURE - enable signing and verification in FITs CONFIG_RSA - enable RSA algorithm for signing +CONFIG_ECDSA - enable ECDSA algorithm for signing WARNING: When relying on signed FIT images with required signature check the legacy image format is default disabled by not defining -- 2.39.2
[PATCH 2/4] doc: signature: update algorithm addition description
U-Boot now uses the U_BOOT_CRYPTO_ALGO() macro. Signed-off-by: Baruch Siach --- doc/uImage.FIT/signature.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/uImage.FIT/signature.txt b/doc/uImage.FIT/signature.txt index bc123f512f7b..b6707417ff63 100644 --- a/doc/uImage.FIT/signature.txt +++ b/doc/uImage.FIT/signature.txt @@ -56,10 +56,10 @@ of data from the FDT and exponentiation mod n. Code size impact is a little under 5KB on Tegra Seaboard, for example. It is relatively straightforward to add new algorithms if required. If -another RSA variant is needed, then it can be added to the table in -image-sig.c. If another algorithm is needed (such as DSA) then it can be -placed alongside rsa.c, and its functions added to the table in image-sig.c -also. +another RSA variant is needed, then it can be added with the +U_BOOT_CRYPTO_ALGO() macro. If another algorithm is needed (such as DSA) then +it can be placed in a directory alongside lib/rsa/, and its functions added +using U_BOOT_CRYPTO_ALGO(). Creating an RSA key pair and certificate -- 2.39.2
Re: [PATCH] env: Remove misuse of env is nowhere driver
Hello Stefan,
On 29.04.23 06:30, Heiko Schocher wrote:
> Hello Stefan,
>
> On 28.04.23 15:45, Stefan Herbrechtsmeier wrote:
>> From: Stefan Herbrechtsmeier
>>
>> When using a list of writeable variables, the initial values come from
>> the built-in default environment since commit 5ab81058364b
>> ("env: Complete generic support for writable list"). Remove unnecessary
>> misuse of the env is nowhere driver as default environment.
>>
>> Signed-off-by: Stefan Herbrechtsmeier
>>
>> ---
>>
>> board/aristainetos/aristainetos.c| 19 ---
>> configs/aristainetos2c_defconfig | 1 -
>> configs/aristainetos2ccslb_defconfig | 1 -
>> env/env.c| 2 --
>> 4 files changed, 23 deletions(-)
>
> NACK.
Sorry for being to fast with my NACK (I was on thw wrong code
base ...)!
Tested-by: Heiko Schocher
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Erika Unter
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [PATCH u-boot 0/3] pci: mpc85xx: Fixes for PCI config space
Hello Pali, On 29.04.23 13:10, Pali Rohár wrote: > On Thursday 13 April 2023 22:41:43 Pali Rohár wrote: >> This patch series contains small fixes for mpc85xx old PCI Local Bus driver. >> >> Heiko: Are you able to test these changes? Has your Socrates board >> available old PCI Local Bus support? >> >> Pali Rohár (3): >> pci: mpc85xx: Add missing sync() after writing to PCI config space >> pci: mpc85xx: Allow 8/16-bit access to PCI config space >> pci: mpc85xx: Do not try to access extended PCIe registers >> >> drivers/pci/pci_mpc85xx.c | 39 +++ >> 1 file changed, 35 insertions(+), 4 deletions(-) >> >> -- >> 2.20.1 >> > > Anything more here? > > Remaining issues are handled by the other patch series on the list. I see no more issues on my hardware, thanks! bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[PATCH 1/1] CI: treat documentation warnings as errors
We do not want to merge documentation that produces Sphinx warnings. scripts/kernel-doc uses environment variable KDOC_WERROR to determine if warnings should be treated as errors. Reported-by: Tom Rini Signed-off-by: Heinrich Schuchardt --- .azure-pipelines.yml | 2 +- .gitlab-ci.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml index 76ffdeebd6..3c1846a5bc 100644 --- a/.azure-pipelines.yml +++ b/.azure-pipelines.yml @@ -89,7 +89,7 @@ stages: virtualenv -p /usr/bin/python3 /tmp/venvhtml . /tmp/venvhtml/bin/activate pip install -r doc/sphinx/requirements.txt - make htmldocs + make htmldocs KDOC_WERROR=1 make infodocs - job: todo diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index b193fee98f..e6c6ab3586 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -171,7 +171,7 @@ docs: - virtualenv -p /usr/bin/python3 /tmp/venvhtml - . /tmp/venvhtml/bin/activate - pip install -r doc/sphinx/requirements.txt -- make htmldocs +- make htmldocs KDOC_WERROR=1 - make infodocs # some statistics about the code base -- 2.39.2
[PATCH 1/1] dm: core: fix introduce uclass_get_device_by_of_path
Correct the function documentation.
Fixes: ca031c082700 ("dm: core: introduce uclass_get_device_by_of_path()")
Reported-by: Tom Rini
Signed-off-by: Heinrich Schuchardt
---
include/dm/uclass.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/dm/uclass.h b/include/dm/uclass.h
index 5c5fb9acac..456eef7f2f 100644
--- a/include/dm/uclass.h
+++ b/include/dm/uclass.h
@@ -274,7 +274,7 @@ int uclass_get_device_by_ofnode(enum uclass_id id, ofnode
node,
* The device is probed to activate it ready for use.
*
* @id: ID to look up
- * @node: Device tree path to search for (if no such path then -ENODEV is
returned)
+ * @path: Device tree path to search for (if no such path then -ENODEV is
returned)
* @devp: Returns pointer to device (there is only one for each node)
* Return: 0 if OK, -ve on error
*/
--
2.39.2
[PATCH 1/1] cli: avoid buffer overrun
Invoking the sandbox with
/u-boot -c ⧵0xef⧵0xbf⧵0xbd
results in a segmentation fault.
Function b_getch() retrieves a character from the input stream. This
character may be > 0x7f. If type char is signed, static_get() will
return a negative number and in parse_stream() we will use that
negative number as an index for array map[] resulting in a buffer
overflow.
Reported-by: Harry Lockyer
Signed-off-by: Heinrich Schuchardt
---
common/cli_hush.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/cli_hush.c b/common/cli_hush.c
index 1ad7a509df..77df42428b 100644
--- a/common/cli_hush.c
+++ b/common/cli_hush.c
@@ -324,7 +324,7 @@ typedef struct {
/* I can almost use ordinary FILE *. Is open_memstream() universally
* available? Where is it documented? */
struct in_str {
- const char *p;
+ const unsigned char *p;
#ifndef __U_BOOT__
char peek_buf[2];
#endif
--
2.39.2
Re: Pull request: u-boot-spi/master
On Mon, May 01, 2023 at 10:42:08PM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this PR for u-boot-spi. > > Summary: > - cadence-quadspi fixes (Apurva Nandan, Dhruva Gole) > - CHIP_ERASE optimization (Marek Vasut) > - fixups for s25fs512s (Takahiro Kuwano) > > CI: > https://source.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/16198 > > The following changes since commit 6a11fdf0536e02ac9cd4a3da0535a271c694715f: > > Merge branch '2023-04-24-TI-platform-updates' (2023-04-24 18:09:22 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-spi spi > > for you to fetch changes up to 08b3098eadc7f826c3e6fb9d184cf6d82f5028fe: > > spi: cadence-quadspi: Reset CMD_CTRL Reg on cmd r/w completion (2023-04-26 > 13:37:39 +0530) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] usb: gadget: Compile USB ethernet gadget only if NET is enabled
On Mon, May 01, 2023 at 10:49:37PM +0200, Marek Vasut wrote: > On 5/1/23 20:53, Tom Rini wrote: > > On Mon, May 01, 2023 at 07:40:57PM +0200, Marek Vasut wrote: > > > On 5/1/23 19:23, Tom Rini wrote: > > > > On Mon, May 01, 2023 at 06:53:52PM +0200, Marek Vasut wrote: > > > > > On 5/1/23 15:47, Tom Rini wrote: > > > > > > On Sun, Apr 30, 2023 at 11:20:35PM +0200, Marek Vasut wrote: > > > > > > > > > > > > > In case NET networking is not enabled, it is not possible to > > > > > > > compile > > > > > > > the USB ethernet gadget. Protect the symbols in Makefile to avoid > > > > > > > build > > > > > > > failure. Such build failure may occur e.g. in case NET and USB > > > > > > > ethernet > > > > > > > gadget is enabled in U-Boot proper, but not in SPL. > > > > > > > > > > > > > > Signed-off-by: Marek Vasut > > > > > > > --- > > > > > > > Cc: Lukasz Majewski > > > > > > > --- > > > > > > > drivers/usb/gadget/Makefile | 2 ++ > > > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > > > > > diff --git a/drivers/usb/gadget/Makefile > > > > > > > b/drivers/usb/gadget/Makefile > > > > > > > index 6cfe0f3a041..36f65e7eb95 100644 > > > > > > > --- a/drivers/usb/gadget/Makefile > > > > > > > +++ b/drivers/usb/gadget/Makefile > > > > > > > @@ -34,8 +34,10 @@ endif > > > > > > > obj-$(CONFIG_CI_UDC) += ci_udc.o > > > > > > > +ifeq ($(CONFIG_$(SPL_TPL_)NET),y) > > > > > > > obj-$(CONFIG_USB_ETHER) += ether.o > > > > > > > obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o > > > > > > > +endif > > > > > > > # Devices not related to the new gadget layer depend on > > > > > > > CONFIG_USB_DEVICE > > > > > > > # This is really only N900 and USBTTY now. > > > > > > > > > > > > Why can't we just enforce this via Kconfig? > > > > > > > > > > Because there is no SPL/TPL USB_ETHER Kconfig . > > > > > Do we want to grow the Kconfig file with those instead ? > > > > > > > > Ah right. Yes, we have SPL_USB_ETHER today > > > > > > This is exactly the opposite of what I wrote. > > > > > > And no, we do NOT have this symbol, see: > > > > > > $ git grep SPL_USB_ETHER drivers/usb | wc -l > > > 0 > > > > Yes, it resides in common/spl/Kconfig > > Uh, such USB symbol is not supposed to be there in the first place. There's long running debate on where some symbols should be for a better overall experience of enabling features. > However, looking at the meaning of that symbol, it seems it governs > something else -- USB ethernet device(s) (like the USB-ethernet adapter > which you plug into USB host port). So, the SPL_USB_ETHER symbol name is > incorrectly named too and should be renamed to something else first I think > ? > > Do I read it right ? > > And if so, then, back to my original reply -- there is no SPL_USB_ETHER > symbol. Does it make more sense to really add one (not misnamed one) or not > ? We should re-work things as needed so that we have more Kconfig symbols, as needed. There's some overlap / overloading of things today as platforms have been able to (and I think am335x_evm is still one that builds for) supporting making a USB RNDIS gadget device happen in SPL, so that we can then be fed the next stage of U-Boot. -- Tom signature.asc Description: PGP signature
Re: [PATCH] usb: gadget: Compile USB ethernet gadget only if NET is enabled
On 5/1/23 20:53, Tom Rini wrote: On Mon, May 01, 2023 at 07:40:57PM +0200, Marek Vasut wrote: On 5/1/23 19:23, Tom Rini wrote: On Mon, May 01, 2023 at 06:53:52PM +0200, Marek Vasut wrote: On 5/1/23 15:47, Tom Rini wrote: On Sun, Apr 30, 2023 at 11:20:35PM +0200, Marek Vasut wrote: In case NET networking is not enabled, it is not possible to compile the USB ethernet gadget. Protect the symbols in Makefile to avoid build failure. Such build failure may occur e.g. in case NET and USB ethernet gadget is enabled in U-Boot proper, but not in SPL. Signed-off-by: Marek Vasut --- Cc: Lukasz Majewski --- drivers/usb/gadget/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 6cfe0f3a041..36f65e7eb95 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -34,8 +34,10 @@ endif obj-$(CONFIG_CI_UDC) += ci_udc.o +ifeq ($(CONFIG_$(SPL_TPL_)NET),y) obj-$(CONFIG_USB_ETHER) += ether.o obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o +endif # Devices not related to the new gadget layer depend on CONFIG_USB_DEVICE # This is really only N900 and USBTTY now. Why can't we just enforce this via Kconfig? Because there is no SPL/TPL USB_ETHER Kconfig . Do we want to grow the Kconfig file with those instead ? Ah right. Yes, we have SPL_USB_ETHER today This is exactly the opposite of what I wrote. And no, we do NOT have this symbol, see: $ git grep SPL_USB_ETHER drivers/usb | wc -l 0 Yes, it resides in common/spl/Kconfig Uh, such USB symbol is not supposed to be there in the first place. However, looking at the meaning of that symbol, it seems it governs something else -- USB ethernet device(s) (like the USB-ethernet adapter which you plug into USB host port). So, the SPL_USB_ETHER symbol name is incorrectly named too and should be renamed to something else first I think ? Do I read it right ? And if so, then, back to my original reply -- there is no SPL_USB_ETHER symbol. Does it make more sense to really add one (not misnamed one) or not ?
[PATCH 5/5] imx8mn-var-som: adjust PHY reset gpios according to hardware configuration
From: Hugo Villeneuve
For SOM with the EC configuration, the ethernet PHY is located on the
SOM itself, and connected to the CPU ethernet controller. It has a
reset line controlled via GPIO1_IO9. In this configuration, the PHY
located on the carrier board is not connected to anything and is
therefore not used.
For SOM without EC configuration, the ethernet PHY on the carrier
board is connected to the CPU ethernet controller. It has a reset line
controlled via the GPIO expander PCA9534_IO5.
The hardware configuration (EC) is determined at runtime by
reading from the SOM EEPROM.
To support both hardware configurations (EC and non-EC), adjust/fix
the PHY reset gpios according to the hardware configuration
read at runtime from the SOM EEPROM. This adjustement is done in
U-Boot (OF_BOARD_FIXUP) and kernel (OF_BOARD_SETUP) device trees.
Signed-off-by: Hugo Villeneuve
---
arch/arm/dts/imx8mn-var-som-symphony.dts | 4 -
.../variscite/imx8mn_var_som/imx8mn_var_som.c | 80 +++
configs/imx8mn_var_som_defconfig | 2 +
3 files changed, 82 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/imx8mn-var-som-symphony.dts
b/arch/arm/dts/imx8mn-var-som-symphony.dts
index 3ed7021a48..5c8e4e8175 100644
--- a/arch/arm/dts/imx8mn-var-som-symphony.dts
+++ b/arch/arm/dts/imx8mn-var-som-symphony.dts
@@ -56,10 +56,6 @@
};
};
- {
- reset-gpios = < 5 GPIO_ACTIVE_HIGH>;
-};
-
{
clock-frequency = <40>;
pinctrl-names = "default";
diff --git a/board/variscite/imx8mn_var_som/imx8mn_var_som.c
b/board/variscite/imx8mn_var_som/imx8mn_var_som.c
index a89457e8f5..61b9455a8f 100644
--- a/board/variscite/imx8mn_var_som/imx8mn_var_som.c
+++ b/board/variscite/imx8mn_var_som/imx8mn_var_som.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
DECLARE_GLOBAL_DATA_PTR;
@@ -161,4 +162,83 @@ int checkboard(void)
#endif /* CONFIG_DISPLAY_BOARDINFO */
+static int insert_gpios_prop(void *blob, int node, const char *prop,
+unsigned int phandle, u32 gpio, u32 flags)
+{
+ fdt32_t val[3] = { cpu_to_fdt32(phandle), cpu_to_fdt32(gpio),
+ cpu_to_fdt32(flags) };
+ return fdt_setprop(blob, node, prop, , sizeof(val));
+}
+
+static int configure_phy_reset_gpios(void *blob)
+{
+ int node;
+ int phynode;
+ int ret;
+ u32 handle;
+ u32 gpio;
+ u32 flags;
+ char path[1024];
+ const char *eth_alias = "ethernet0";
+
+ snprintf(path, sizeof(path), "%s/mdio/ethernet-phy@4",
+fdt_get_alias(blob, eth_alias));
+
+ phynode = fdt_path_offset(blob, path);
+ if (phynode < 0) {
+ pr_err("%s(): unable to locate PHY node: %s\n", __func__, path);
+ return 0;
+ }
+
+ if (gd_board_type() & VAR_EEPROM_F_ETH) {
+ snprintf(path, sizeof(path), "%s",
+fdt_get_alias(blob, "gpio0")); /* Alias to gpio1 */
+ gpio = 9;
+ flags = GPIO_ACTIVE_LOW;
+ } else {
+ snprintf(path, sizeof(path), "%s/gpio@20",
+fdt_get_alias(blob, "i2c1")); /* Alias to i2c2 */
+ gpio = 5;
+ flags = GPIO_ACTIVE_HIGH;
+ }
+
+ node = fdt_path_offset(blob, path);
+ if (node < 0) {
+ pr_err("%s(): unable to locate GPIO node: %s\n", __func__,
+ path);
+ return 0;
+ }
+
+ handle = fdt_get_phandle(blob, node);
+ if (handle < 0) {
+ pr_err("%s(): unable to locate GPIO controller handle: %s\n",
+ __func__, path);
+ }
+
+ ret = insert_gpios_prop(blob, phynode, "reset-gpios",
+ handle, gpio, flags);
+ if (ret < 0) {
+ pr_err("%s(): failed to set reset-gpios property\n", __func__);
+ return ret;
+ }
+
+ return 0;
+}
+
+#if defined(CONFIG_OF_BOARD_FIXUP)
+int board_fix_fdt(void *blob)
+{
+ /* Fix U-Boot device tree: */
+ return configure_phy_reset_gpios(blob);
+}
+#endif /* CONFIG_OF_BOARD_FIXUP */
+
+#if defined(CONFIG_OF_BOARD_SETUP)
+int ft_board_setup(void *blob, struct bd_info *bd)
+{
+ /* Fix kernel device tree: */
+ return configure_phy_reset_gpios(blob);
+}
+#endif /* CONFIG_OF_BOARD_SETUP */
+
#endif /* CONFIG_SPL_BUILD */
diff --git a/configs/imx8mn_var_som_defconfig b/configs/imx8mn_var_som_defconfig
index da48ec0a21..0f3d2a0288 100644
--- a/configs/imx8mn_var_som_defconfig
+++ b/configs/imx8mn_var_som_defconfig
@@ -112,3 +112,5 @@ CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5
CONFIG_CI_UDC=y
CONFIG_IMX_WATCHDOG=y
CONFIG_OF_LIBFDT_OVERLAY=y
+CONFIG_OF_BOARD_FIXUP=y
+CONFIG_OF_BOARD_SETUP=y
--
2.30.2
[PATCH 4/5] imx8mn-var-som: read eth MAC address from EEPROM
From: Hugo Villeneuve
Read ethernet MAC address from EEPROM located on the SOM.
Signed-off-by: Hugo Villeneuve
---
arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi | 13 +
arch/arm/mach-imx/imx8m/Kconfig | 1 +
2 files changed, 14 insertions(+)
diff --git a/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
index 7272fc2b4c..e0caf3179e 100644
--- a/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
@@ -13,6 +13,19 @@
bootph-pre-ram;
};
+_som {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ eth_mac_address: eth-mac-address@19 {
+ reg = <0x19 0x06>;
+ };
+};
+
+ {
+ nvmem-cells = <_mac_address>;
+ nvmem-cell-names = "mac-address";
+};
+
{
bootph-pre-ram;
};
diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
index 94f4d584f1..7e5a3e31dd 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -242,6 +242,7 @@ config TARGET_IMX8MN_VAR_SOM
select MISC
select I2C_EEPROM
select DM_ETH_PHY
+ select NVMEM
config TARGET_KONTRON_PITX_IMX8M
bool "Support Kontron pITX-imx8m"
--
2.30.2
[PATCH 3/5] arm: dts: imx8mn-var-som: fix PHY detection bug by adding deassert delay
From: Hugo Villeneuve
While testing the ethernet interface on a Variscite symphony carrier
board using an imx8mn SOM with an onboard ADIN1300 PHY (EC hardware
configuration), the ethernet PHY is not detected.
The ADIN1300 datasheet indicate that the "Management interface
active (t4)" state is reached at most 5ms after the reset signal is
deasserted.
The device tree in Variscite custom git repository uses the following
property:
phy-reset-post-delay = <20>;
Add a new MDIO property 'reset-deassert-us' of 20ms to have the same
delay inside the ethphy node. Adding this property fixes the problem
with the PHY detection.
Note that this SOM can also have an Atheros AR8033 PHY. In this case,
a 1ms deassert delay is sufficient. Add a comment to that effect.
Fixes: c4c1ed68c1e8 ("imx8mn_var_som: Add support for Variscite
VAR-SOM-MX8M-NANO board")
Signed-off-by: Hugo Villeneuve
---
arch/arm/dts/imx8mn-var-som.dtsi | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx8mn-var-som.dtsi b/arch/arm/dts/imx8mn-var-som.dtsi
index dea9eff3f0..4eb578a03f 100644
--- a/arch/arm/dts/imx8mn-var-som.dtsi
+++ b/arch/arm/dts/imx8mn-var-som.dtsi
@@ -102,11 +102,17 @@
#address-cells = <1>;
#size-cells = <0>;
- ethphy: ethernet-phy@4 {
+ ethphy: ethernet-phy@4 { /* AR8033 or ADIN1300 */
compatible = "ethernet-phy-ieee802.3-c22";
reg = <4>;
reset-gpios = < 9 GPIO_ACTIVE_LOW>;
reset-assert-us = <1>;
+ /*
+* Deassert delay:
+* ADIN1300 requires 5ms.
+* AR8033 requires 1ms.
+*/
+ reset-deassert-us = <2>;
};
};
};
--
2.30.2
[PATCH 2/5] imx8mn-var-som: fix non-applied PHY reset-gpios properties
From: Hugo Villeneuve
Select DM_ETH_PHY so that the reset-gpios property of the ethphy node
can be used.
Also select DM_PCA953X, which is needed for resetting the
ethernet PHY on the carrier board via the PCA9534 I/O expander.
Commit 4e5114daf9eb ("imx8mn: synchronise device tree with linux") did
synchronise device tree with linux, which in effect removed obsolete
PHY reset properties and replaced them with new mdio DM
properties. But the commit didn't activate DM_ETH_PHY or DM_PCA953X.
Fixes: 4e5114daf9eb ("imx8mn: synchronise device tree with linux")
Signed-off-by: Hugo Villeneuve
---
arch/arm/mach-imx/imx8m/Kconfig | 1 +
configs/imx8mn_var_som_defconfig | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
index ec0abb92b8..94f4d584f1 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -241,6 +241,7 @@ config TARGET_IMX8MN_VAR_SOM
select IMX8M_DDR4
select MISC
select I2C_EEPROM
+ select DM_ETH_PHY
config TARGET_KONTRON_PITX_IMX8M
bool "Support Kontron pITX-imx8m"
diff --git a/configs/imx8mn_var_som_defconfig b/configs/imx8mn_var_som_defconfig
index bb1245bd35..da48ec0a21 100644
--- a/configs/imx8mn_var_som_defconfig
+++ b/configs/imx8mn_var_som_defconfig
@@ -9,6 +9,7 @@ CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x2000
CONFIG_ENV_OFFSET=0xDE00
CONFIG_DM_GPIO=y
+CONFIG_DM_PCA953X=y
CONFIG_DEFAULT_DEVICE_TREE="imx8mn-var-som-symphony"
CONFIG_SPL_TEXT_BASE=0x912000
CONFIG_TARGET_IMX8MN_VAR_SOM=y
--
2.30.2
[PATCH 0/5] imx8mn-var-som: fix ethernet for Variscite symphony board and imx8m nano SOM
From: Hugo Villeneuve Hello, This patch series fixes bugs and add missing features related to the ethernet PHY on Variscite symphony carrier board with an imx8m nano SOM (P/N VAR-SOM-MX8M-NANO). Ethernet functionality is currently broken for the VAR-SOM-MX8M-NANO. Variscite imx8m nano SOM comes in multiple hardware configuration options. One of this hardware configuration option is called EC: EC: Ethernet Controller PHY assembled on SOM For SOM with the EC configuration, the ethernet PHY is located on the SOM itself, and connected to the CPU ethernet controller. It has a reset line controlled via GPIO1_IO9. In this configuration, the PHY located on the carrier board is not connected to anything and is therefore not used. For SOM without EC configuration, the ethernet PHY on the carrier board is connected to the CPU ethernet controller. It has a reset line controlled via the GPIO expander PCA9534_IO5. Patch 1 add code to read and display the SOM configuration stored in the SOM EEPROM. This patch is also submitted to the Linux kernel (section that adds the EEPROM to the device tree), so that it will be easier to sync the DT between kernel and U-Boot. Patch 2 fixes bugs with the PHY reset properties. Patch 3 fixes a bug with a missing PHY reset deassert delay (also submitted to kernel). Patch 4 enables automatic read of PHY MAC address from the SOM EEPROM. Patch 5 is used for auto-detecting at runtime the SOM hardware configuration option related to the PHY (EC), and dynamically adjust the device tree to support both SOM PHY options. This series need the following patch to be applied first: https://lore.kernel.org/u-boot/20230425141935.2324406-1-h...@hugovil.com/ I have succesfully tested the changes on a Variscite symphony carrier board with a VAR-SOM-MX8M-NANO having the EC configuration option. Unfortunately, I do not have a VAR-SOM-MX8M-NANO with a non-EC configuration option so I couldn't test it on real hardware, altough I simulated it and confirmed that the device tree fixing seems to be correct by using debug/print statements. Thank you. Hugo Villeneuve (5): imx8mn-var-som: read and print SoM infos from eeprom on startup imx8mn-var-som: fix non-applied PHY reset-gpios properties arm: dts: imx8mn-var-som: fix PHY detection bug by adding deassert delay imx8mn-var-som: read eth MAC address from EEPROM imx8mn-var-som: adjust PHY reset gpios according to hardware configuration .../dts/imx8mn-var-som-symphony-u-boot.dtsi | 17 ++ arch/arm/dts/imx8mn-var-som-symphony.dts | 4 - arch/arm/dts/imx8mn-var-som.dtsi | 18 +- arch/arm/mach-imx/imx8m/Kconfig | 4 + .../variscite/imx8mn_var_som/imx8mn_var_som.c | 214 ++ configs/imx8mn_var_som_defconfig | 4 + 6 files changed, 256 insertions(+), 5 deletions(-) base-commit: 2e83d560c115d6a6616edc8054fe6be9803f9577 -- 2.30.2
[PATCH 1/5] imx8mn-var-som: read and print SoM infos from eeprom on startup
From: Hugo Villeneuve
Enable support to read and display configuration/manufacturing infos
from 4Kbit EEPROM located on SOM board.
Note: CONFIG_DISPLAY_BOARDINFO is automatically selected for ARM arch.
Signed-off-by: Hugo Villeneuve
---
.../dts/imx8mn-var-som-symphony-u-boot.dtsi | 4 +
arch/arm/dts/imx8mn-var-som.dtsi | 10 ++
arch/arm/mach-imx/imx8m/Kconfig | 2 +
.../variscite/imx8mn_var_som/imx8mn_var_som.c | 134 ++
configs/imx8mn_var_som_defconfig | 1 +
5 files changed, 151 insertions(+)
diff --git a/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
index af80aaea0b..7272fc2b4c 100644
--- a/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
+++ b/arch/arm/dts/imx8mn-var-som-symphony-u-boot.dtsi
@@ -68,3 +68,7 @@
{
bootph-pre-ram;
};
+
+_som {
+ bootph-pre-ram;
+};
diff --git a/arch/arm/dts/imx8mn-var-som.dtsi b/arch/arm/dts/imx8mn-var-som.dtsi
index 87b5e23c76..dea9eff3f0 100644
--- a/arch/arm/dts/imx8mn-var-som.dtsi
+++ b/arch/arm/dts/imx8mn-var-som.dtsi
@@ -11,6 +11,10 @@
model = "Variscite VAR-SOM-MX8MN module";
compatible = "variscite,var-som-mx8mn", "fsl,imx8mn";
+ aliases {
+ eeprom-som = _som;
+ };
+
chosen {
stdout-path =
};
@@ -222,6 +226,12 @@
};
};
};
+
+ eeprom_som: eeprom@52 {
+ compatible = "atmel,24c04";
+ reg = <0x52>;
+ pagesize = <16>;
+ };
};
{
diff --git a/arch/arm/mach-imx/imx8m/Kconfig b/arch/arm/mach-imx/imx8m/Kconfig
index dc51f971d4..ec0abb92b8 100644
--- a/arch/arm/mach-imx/imx8m/Kconfig
+++ b/arch/arm/mach-imx/imx8m/Kconfig
@@ -239,6 +239,8 @@ config TARGET_IMX8MN_VAR_SOM
select IMX8MN
select SUPPORT_SPL
select IMX8M_DDR4
+ select MISC
+ select I2C_EEPROM
config TARGET_KONTRON_PITX_IMX8M
bool "Support Kontron pITX-imx8m"
diff --git a/board/variscite/imx8mn_var_som/imx8mn_var_som.c
b/board/variscite/imx8mn_var_som/imx8mn_var_som.c
index d40f4d0176..a89457e8f5 100644
--- a/board/variscite/imx8mn_var_som/imx8mn_var_som.c
+++ b/board/variscite/imx8mn_var_som/imx8mn_var_som.c
@@ -1,11 +1,49 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* Copyright 2021 Collabora Ltd.
+ * Copyright 2018-2020 Variscite Ltd.
+ * Copyright 2023 DimOnOff Inc.
*/
#include
+#include
#include
+#include
+#include
+#include
+#include
#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Optional SOM features flags. */
+#define VAR_EEPROM_F_WIFI BIT(0)
+#define VAR_EEPROM_F_ETH BIT(1) /* Ethernet PHY on SOM. */
+#define VAR_EEPROM_F_AUDIO BIT(2)
+#define VAR_EEPROM_F_MX8M_LVDS BIT(3) /* i.MX8MM, i.MX8MN, i.MX8MQ
only */
+#define VAR_EEPROM_F_MX8Q_SOC_ID BIT(3) /* 0 = i.MX8QM, 1 = i.MX8QP */
+#define VAR_EEPROM_F_NAND BIT(4)
+
+#define VAR_IMX8_EEPROM_MAGIC 0x384D /* "8M" */
+
+/* Number of DRAM adjustment tables. */
+#define DRAM_TABLES_NUM 7
+
+struct var_imx8_eeprom_info {
+ u16 magic;
+ u8 partnumber[3]; /* Part number */
+ u8 assembly[10]; /* Assembly number */
+ u8 date[9]; /* Build date */
+ u8 mac[6];/* MAC address */
+ u8 somrev;
+ u8 eeprom_version;
+ u8 features; /* SOM features */
+ u8 dramsize; /* DRAM size */
+ u8 off[DRAM_TABLES_NUM + 1]; /* DRAM table offsets */
+ u8 partnumber2[5];/* Part number 2 */
+} __packed;
static void setup_fec(void)
{
@@ -28,3 +66,99 @@ int board_mmc_get_env_dev(int devno)
{
return devno;
}
+
+#if !defined(CONFIG_SPL_BUILD)
+
+#if defined(CONFIG_DISPLAY_BOARDINFO)
+
+static void display_som_infos(struct var_imx8_eeprom_info *info)
+{
+ char partnumber[sizeof(info->partnumber) +
+ sizeof(info->partnumber2) + 1];
+ char assembly[sizeof(info->assembly) + 1];
+ char date[sizeof(info->date) + 1];
+
+ /* Read first part of P/N. */
+ memcpy(partnumber, info->partnumber, sizeof(info->partnumber));
+
+ /* Read second part of P/N. */
+ if (info->eeprom_version >= 3)
+ memcpy(partnumber + sizeof(info->partnumber), info->partnumber2,
+ sizeof(info->partnumber2));
+
+ memcpy(assembly, info->assembly, sizeof(info->assembly));
+ memcpy(date, info->date, sizeof(info->date));
+
+ /* Make sure strings are null terminated. */
+ partnumber[sizeof(partnumber) - 1] = '\0';
+ assembly[sizeof(assembly) - 1] = '\0';
+ date[sizeof(date) - 1] = '\0';
+
+ printf("SOM board: P/N: %s, Assy: %s, Date: %s\n"
+ " Wifi: %s, EthPhy: %s, Rev: %d\n",
+ partnumber, assembly, date,
+ info->features &
Re: [PATCH] rockchip: Pinebook Pro: Fix emmc default configuration
On Mon, May 1, 2023 at 8:43 AM Wolfgang Zarre wrote: > > If u-boot is installed on the internal emmc, then this will > allow to boot without failure. > > Signed-off-by: Wolfgang Zarre > --- > > configs/pinebook-pro-rk3399_defconfig | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/configs/pinebook-pro-rk3399_defconfig > b/configs/pinebook-pro-rk3399_defconfig > index dff4695e37..58a8b91aa6 100644 > --- a/configs/pinebook-pro-rk3399_defconfig > +++ b/configs/pinebook-pro-rk3399_defconfig > @@ -6,6 +6,7 @@ CONFIG_TEXT_BASE=0x0020 > CONFIG_NR_DRAM_BANKS=1 > CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y > CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30 > +CONFIG_SF_DEFAULT_SPEED=2000 Why move this? > CONFIG_ENV_SIZE=0x8000 > CONFIG_ENV_OFFSET=0x3F8000 > CONFIG_DEFAULT_DEVICE_TREE="rk3399-pinebook-pro" > @@ -18,6 +19,7 @@ CONFIG_DEBUG_UART_CLOCK=2400 > CONFIG_SPL_SPI_FLASH_SUPPORT=y > CONFIG_SPL_SPI=y > CONFIG_SYS_LOAD_ADDR=0x800800 > +CONFIG_PCI=y Or this? > CONFIG_DEBUG_UART=y > CONFIG_BOOTDELAY=3 > CONFIG_USE_PREBOOT=y > @@ -57,17 +59,23 @@ CONFIG_LED=y > CONFIG_LED_GPIO=y > CONFIG_MISC=y > CONFIG_ROCKCHIP_EFUSE=y > +CONFIG_MMC_IO_VOLTAGE=y > +CONFIG_SPL_MMC_IO_VOLTAGE=y > +CONFIG_MMC_UHS_SUPPORT=y > +CONFIG_SPL_MMC_UHS_SUPPORT=y > +CONFIG_MMC_HS400_ES_SUPPORT=y > +CONFIG_SPL_MMC_HS400_ES_SUPPORT=y > +CONFIG_MMC_HS400_SUPPORT=y > +CONFIG_SPL_MMC_HS400_SUPPORT=y Can you provide more details why these fix it? > CONFIG_MMC_DW=y > CONFIG_MMC_DW_ROCKCHIP=y > CONFIG_MMC_SDHCI=y > CONFIG_MMC_SDHCI_SDMA=y > CONFIG_MMC_SDHCI_ROCKCHIP=y > CONFIG_SF_DEFAULT_BUS=1 > -CONFIG_SF_DEFAULT_SPEED=2000 > CONFIG_SPI_FLASH_GIGADEVICE=y > CONFIG_SPI_FLASH_WINBOND=y > CONFIG_NVME_PCI=y > -CONFIG_PCI=y > CONFIG_PHY_ROCKCHIP_INNO_USB2=y > CONFIG_PHY_ROCKCHIP_TYPEC=y > CONFIG_DM_PMIC_FAN53555=y > -- > 2.39.2 >
Re: [PATCH] usb: gadget: Compile USB ethernet gadget only if NET is enabled
On Mon, May 01, 2023 at 07:40:57PM +0200, Marek Vasut wrote: > On 5/1/23 19:23, Tom Rini wrote: > > On Mon, May 01, 2023 at 06:53:52PM +0200, Marek Vasut wrote: > > > On 5/1/23 15:47, Tom Rini wrote: > > > > On Sun, Apr 30, 2023 at 11:20:35PM +0200, Marek Vasut wrote: > > > > > > > > > In case NET networking is not enabled, it is not possible to compile > > > > > the USB ethernet gadget. Protect the symbols in Makefile to avoid > > > > > build > > > > > failure. Such build failure may occur e.g. in case NET and USB > > > > > ethernet > > > > > gadget is enabled in U-Boot proper, but not in SPL. > > > > > > > > > > Signed-off-by: Marek Vasut > > > > > --- > > > > > Cc: Lukasz Majewski > > > > > --- > > > > >drivers/usb/gadget/Makefile | 2 ++ > > > > >1 file changed, 2 insertions(+) > > > > > > > > > > diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile > > > > > index 6cfe0f3a041..36f65e7eb95 100644 > > > > > --- a/drivers/usb/gadget/Makefile > > > > > +++ b/drivers/usb/gadget/Makefile > > > > > @@ -34,8 +34,10 @@ endif > > > > >obj-$(CONFIG_CI_UDC) += ci_udc.o > > > > > +ifeq ($(CONFIG_$(SPL_TPL_)NET),y) > > > > >obj-$(CONFIG_USB_ETHER) += ether.o > > > > >obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o > > > > > +endif > > > > ># Devices not related to the new gadget layer depend on > > > > > CONFIG_USB_DEVICE > > > > ># This is really only N900 and USBTTY now. > > > > > > > > Why can't we just enforce this via Kconfig? > > > > > > Because there is no SPL/TPL USB_ETHER Kconfig . > > > Do we want to grow the Kconfig file with those instead ? > > > > Ah right. Yes, we have SPL_USB_ETHER today > > This is exactly the opposite of what I wrote. > > And no, we do NOT have this symbol, see: > > $ git grep SPL_USB_ETHER drivers/usb | wc -l > 0 Yes, it resides in common/spl/Kconfig -- Tom signature.asc Description: PGP signature
Re: [PATCH] usb: gadget: Compile USB ethernet gadget only if NET is enabled
On 5/1/23 19:23, Tom Rini wrote: On Mon, May 01, 2023 at 06:53:52PM +0200, Marek Vasut wrote: On 5/1/23 15:47, Tom Rini wrote: On Sun, Apr 30, 2023 at 11:20:35PM +0200, Marek Vasut wrote: In case NET networking is not enabled, it is not possible to compile the USB ethernet gadget. Protect the symbols in Makefile to avoid build failure. Such build failure may occur e.g. in case NET and USB ethernet gadget is enabled in U-Boot proper, but not in SPL. Signed-off-by: Marek Vasut --- Cc: Lukasz Majewski --- drivers/usb/gadget/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 6cfe0f3a041..36f65e7eb95 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -34,8 +34,10 @@ endif obj-$(CONFIG_CI_UDC) += ci_udc.o +ifeq ($(CONFIG_$(SPL_TPL_)NET),y) obj-$(CONFIG_USB_ETHER) += ether.o obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o +endif # Devices not related to the new gadget layer depend on CONFIG_USB_DEVICE # This is really only N900 and USBTTY now. Why can't we just enforce this via Kconfig? Because there is no SPL/TPL USB_ETHER Kconfig . Do we want to grow the Kconfig file with those instead ? Ah right. Yes, we have SPL_USB_ETHER today This is exactly the opposite of what I wrote. And no, we do NOT have this symbol, see: $ git grep SPL_USB_ETHER drivers/usb | wc -l 0 , and could just add SPL_USB_ETH_RNDIS. Are there TPL users today for this? There's no TPL_USB at all. [...]
Re: [PATCH] usb: gadget: Compile USB ethernet gadget only if NET is enabled
On Mon, May 01, 2023 at 06:53:52PM +0200, Marek Vasut wrote: > On 5/1/23 15:47, Tom Rini wrote: > > On Sun, Apr 30, 2023 at 11:20:35PM +0200, Marek Vasut wrote: > > > > > In case NET networking is not enabled, it is not possible to compile > > > the USB ethernet gadget. Protect the symbols in Makefile to avoid build > > > failure. Such build failure may occur e.g. in case NET and USB ethernet > > > gadget is enabled in U-Boot proper, but not in SPL. > > > > > > Signed-off-by: Marek Vasut > > > --- > > > Cc: Lukasz Majewski > > > --- > > > drivers/usb/gadget/Makefile | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile > > > index 6cfe0f3a041..36f65e7eb95 100644 > > > --- a/drivers/usb/gadget/Makefile > > > +++ b/drivers/usb/gadget/Makefile > > > @@ -34,8 +34,10 @@ endif > > > obj-$(CONFIG_CI_UDC) += ci_udc.o > > > +ifeq ($(CONFIG_$(SPL_TPL_)NET),y) > > > obj-$(CONFIG_USB_ETHER) += ether.o > > > obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o > > > +endif > > > # Devices not related to the new gadget layer depend on > > > CONFIG_USB_DEVICE > > > # This is really only N900 and USBTTY now. > > > > Why can't we just enforce this via Kconfig? > > Because there is no SPL/TPL USB_ETHER Kconfig . > Do we want to grow the Kconfig file with those instead ? Ah right. Yes, we have SPL_USB_ETHER today, and could just add SPL_USB_ETH_RNDIS. Are there TPL users today for this? There's no TPL_USB at all. -- Tom signature.asc Description: PGP signature
Pull request: u-boot-spi/master
Hi Tom, Please pull this PR for u-boot-spi. Summary: - cadence-quadspi fixes (Apurva Nandan, Dhruva Gole) - CHIP_ERASE optimization (Marek Vasut) - fixups for s25fs512s (Takahiro Kuwano) CI: https://source.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/16198 The following changes since commit 6a11fdf0536e02ac9cd4a3da0535a271c694715f: Merge branch '2023-04-24-TI-platform-updates' (2023-04-24 18:09:22 -0400) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-spi spi for you to fetch changes up to 08b3098eadc7f826c3e6fb9d184cf6d82f5028fe: spi: cadence-quadspi: Reset CMD_CTRL Reg on cmd r/w completion (2023-04-26 13:37:39 +0530) Apurva Nandan (2): spi: cadence-quadspi: Fix check condition for DTR ops spi: cadence-quadspi: Use STIG mode for all ops with small payload Dhruva Gole (3): spi: spi-mem: s/dummy/data buswidth check in dtr_supports_op() spi: spi-mem: perform odd len check only while writing data spi: cadence-quadspi: Reset CMD_CTRL Reg on cmd r/w completion Heinrich Schuchardt (1): mtd: spi-nor: missing fallthrough in set_4byte() Ilias Apalodimas (1): spi: synquacer: Silence uninitialized variable warnings Jim Liu (1): spi: npcm-fiu: add regulator feature and remove set clock Kunihiko Hayashi (1): spi: f-ospi: Add missing spi_mem_default_supports_op() helper Marek Vasut (1): mtd: spi-nor: Add CHIP_ERASE optimization Takahiro Kuwano (1): mtd: spi-nor-core: Add fixups for s25fs512s drivers/mtd/spi/spi-nor-core.c | 117 - drivers/spi/cadence_qspi.c | 16 -- drivers/spi/cadence_qspi_apb.c | 56 drivers/spi/npcm_fiu_spi.c | 72 - drivers/spi/spi-mem.c | 8 ++- drivers/spi/spi-sn-f-ospi.c| 2 +- drivers/spi/spi-synquacer.c| 4 +- 7 files changed, 231 insertions(+), 44 deletions(-)
Re: [PATCH] usb: gadget: Compile USB ethernet gadget only if NET is enabled
On 5/1/23 15:47, Tom Rini wrote: On Sun, Apr 30, 2023 at 11:20:35PM +0200, Marek Vasut wrote: In case NET networking is not enabled, it is not possible to compile the USB ethernet gadget. Protect the symbols in Makefile to avoid build failure. Such build failure may occur e.g. in case NET and USB ethernet gadget is enabled in U-Boot proper, but not in SPL. Signed-off-by: Marek Vasut --- Cc: Lukasz Majewski --- drivers/usb/gadget/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile index 6cfe0f3a041..36f65e7eb95 100644 --- a/drivers/usb/gadget/Makefile +++ b/drivers/usb/gadget/Makefile @@ -34,8 +34,10 @@ endif obj-$(CONFIG_CI_UDC) += ci_udc.o +ifeq ($(CONFIG_$(SPL_TPL_)NET),y) obj-$(CONFIG_USB_ETHER) += ether.o obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o +endif # Devices not related to the new gadget layer depend on CONFIG_USB_DEVICE # This is really only N900 and USBTTY now. Why can't we just enforce this via Kconfig? Because there is no SPL/TPL USB_ETHER Kconfig . Do we want to grow the Kconfig file with those instead ?
Re: [PATCH 1/2] cmd: fdt: Correct checking of configuration node
On Sun, 30 Apr 2023 at 21:35, Bin Meng wrote: > > fit_conf_get_node() returns a negative value on error. > > Signed-off-by: Bin Meng > --- > > cmd/fdt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH 2/2] spl: Correct checking of configuration node
On Sun, 30 Apr 2023 at 21:35, Bin Meng wrote: > > Per the fit_conf_get_node() API doc, it returns configuration node > offset when found (>=0). > > Signed-off-by: Bin Meng > --- > > common/spl/spl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass > > diff --git a/common/spl/spl.c b/common/spl/spl.c > index a630e79866..7c0aff93e7 100644 > --- a/common/spl/spl.c > +++ b/common/spl/spl.c > @@ -329,7 +329,7 @@ static int spl_load_fit_image(struct spl_image_info > *spl_image, > > conf_noffset = fit_conf_get_node((const void *)header, > fit_uname_config); > - if (conf_noffset <= 0) > + if (conf_noffset < 0) > return 0; > > for (idx = 0; > -- > 2.34.1 > (note that it can never be 0 in fact, since 0 is the root node)
Re: [PATCH 3/3] efi: Correct .efi rules
Hi Heinrich, On Sun, 30 Apr 2023 at 09:00, Heinrich Schuchardt wrote: > > > > Am 30. April 2023 03:21:47 MESZ schrieb Simon Glass : > >These files should have both 'always' and 'targets' so that dependencies > >are detected correctly. > > > >When only 'always' is used, the target is built every time, although I am > >not quite sure why. > > > >Make sure each has both 'always' and 'targets' to avoid this problem. > > > >Signed-off-by: Simon Glass > >--- > > > > lib/efi_loader/Makefile | 3 +++ > > 1 file changed, 3 insertions(+) > > > >diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile > >index 13a35eae6c06..1a8c8d7cab5c 100644 > >--- a/lib/efi_loader/Makefile > >+++ b/lib/efi_loader/Makefile > > How about lib/efi_selftest/Makefile? Any changes needed there too? Not that I can see. Regards, Simon
Re: [PATCH 2/2] x86: Switch QEMU over to use the bochs driver
Hi Heinrich, On Sat, 29 Apr 2023 at 20:38, Heinrich Schuchardt wrote: > > > > Am 30. April 2023 04:31:57 MESZ schrieb Simon Glass : > >This is more convenient since it does not require a video BIOS. Enable > >it for QEMU. > > Does this require a change in how QEMU is invoked? If so, please add a > documentation change. > No, it seems to work fine as is. Regards, Simon
Re: [PATCH v5 1/3] regulator: implement basic reference counter
Hi Eugen,
On Mon, 1 May 2023 at 02:12, Eugen Hristev wrote:
>
> On 4/30/23 21:21, Jonas Karlman wrote:
> > Hi Tim,
> > On 2023-04-28 18:36, Tim Harvey wrote:
> >> On Fri, Apr 28, 2023 at 12:39 AM Eugen Hristev
> >> wrote:
> >>>
> >>> On 4/28/23 02:39, Tim Harvey wrote:
> On Wed, Apr 19, 2023 at 6:45 AM Eugen Hristev
> wrote:
> >
> > Some devices share a regulator supply, when the first one will request
> > regulator disable, the second device will have it's supply cut off
> > before
> > graciously shutting down. Hence there will be timeouts and other failed
> > operations.
> > Implement a reference counter mechanism similar with what is done in
> > Linux, to keep track of enable and disable requests, and only disable
> > the
> > regulator when the last of the consumers has requested shutdown.
> >
> > Signed-off-by: Eugen Hristev
> > Reviewed-by: Simon Glass
> > ---
> > Changes in v5:
> >- none
> > Changes in v4:
> >- add documentation for error codes
> > Changes in v3:
> >- add error return codes
> > Changes in v2:
> >- add info in header regarding the function
> >
> >drivers/power/regulator/regulator_common.c | 22
> > ++
> >drivers/power/regulator/regulator_common.h | 21 +
> >2 files changed, 43 insertions(+)
> >
> > diff --git a/drivers/power/regulator/regulator_common.c
> > b/drivers/power/regulator/regulator_common.c
> > index 93d8196b381e..484a4fc31ef7 100644
> > --- a/drivers/power/regulator/regulator_common.c
> > +++ b/drivers/power/regulator/regulator_common.c
> > @@ -73,6 +73,23 @@ int regulator_common_set_enable(const struct udevice
> > *dev,
> > return 0;
> > }
> >
> > + /* If previously enabled, increase count */
> > + if (enable && dev_pdata->enable_count > 0) {
> > + dev_pdata->enable_count++;
> > + return -EALREADY;
> > + }
> > +
> > + if (!enable) {
> > + if (dev_pdata->enable_count > 1) {
> > + /* If enabled multiple times, decrease count */
> > + dev_pdata->enable_count--;
> > + return -EBUSY;
> > + } else if (!dev_pdata->enable_count) {
> > + /* If already disabled, do nothing */
> > + return -EALREADY;
> > + }
> > + }
> > +
>
> Eugen,
>
> Thank you for working on this series!
> >>>
> >>> Hi Tim,
> >>>
> >>> Thank you for testing and having a look on my patches.
>
> I wonder if instead of returning a failure you should print an error
> here but return 0 in order to not break unbalanced regulator calls
> >>>
> >>> Initially I did that, but Simon forced me to return error as you see now.
> >>
> >> Ok, I see that discussion here:
> >> https://patchwork.ozlabs.org/project/uboot/patch/20230328130127.20279-1-eugen.hris...@collabora.com/#3086660
> >>
> >>>
> (like what is done in clk_disable()). I see that you have another
> patch in this series which handles htis for
> regulator_set_enable_if_allowed() but that doesn't cover drivers that
> call regulator_common_set_enable() directly such as
> drivers/power/regulator/fixed.c and
> drivers/power/regulator/gpio-regulator.c.
> >>>
> >>> I believe Jonas (in CC) fixed those with a patch, but at the moment I am
> >>> lost in providing you a link to it
> >>
> >> Are you thinking of "pci: pcie_dw_rockchip: Use
> >> regulator_set_enable_if_allowed"
> >> https://patchwork.ozlabs.org/project/uboot/patch/20230422181943.889436-3-jo...@kwiboo.se/
> >> ?
> >>
> >> I added some debug prints to regulator_set_enable and see:
> >> starting USB...
> >> Bus usb@32e4: regulator_set_enable regulator-usb-otg1 enable
> >> regulator_set_enable regulator-usb-otg1 enable ret=0
> >> Bus usb@32e5: regulator_set_enable regulator-usb-otg2 enable
> >> regulator_set_enable regulator-usb-otg2 enable ret=0
> >> regulator_set_enable regulator-usb-otg2 enable
> >> regulator_set_enable regulator-usb-otg2 enable ret=-114
> >> Error enabling VBUS supply (ret=-114)
> >> regulator_set_enable regulator-usb-otg2 disable
> >> regulator_set_enable regulator-usb-otg2 disable ret=-16
> >> probe failed, error -114
> >>
> >> So clearly something is trying to enable regulator-usb-otg2 when it's
> >> already enabled but I don't think that should be considered an error
> >> and cause a failure.
> >>
> >> Simon, is this what you were intending with your feedback?
> >>
>
> I know there is an unbalanced call currently on imx8mm that this patch
> causes a failure where it previously did not:
> u-boot=> usb start && usb tree
> starting USB...
> Bus usb@32e4:
Re: [PATCH v5 1/3] regulator: implement basic reference counter
On Mon, May 1, 2023 at 1:12 AM Eugen Hristev
wrote:
>
> On 4/30/23 21:21, Jonas Karlman wrote:
> > Hi Tim,
> > On 2023-04-28 18:36, Tim Harvey wrote:
> >> On Fri, Apr 28, 2023 at 12:39 AM Eugen Hristev
> >> wrote:
> >>>
> >>> On 4/28/23 02:39, Tim Harvey wrote:
> On Wed, Apr 19, 2023 at 6:45 AM Eugen Hristev
> wrote:
> >
> > Some devices share a regulator supply, when the first one will request
> > regulator disable, the second device will have it's supply cut off
> > before
> > graciously shutting down. Hence there will be timeouts and other failed
> > operations.
> > Implement a reference counter mechanism similar with what is done in
> > Linux, to keep track of enable and disable requests, and only disable
> > the
> > regulator when the last of the consumers has requested shutdown.
> >
> > Signed-off-by: Eugen Hristev
> > Reviewed-by: Simon Glass
> > ---
> > Changes in v5:
> >- none
> > Changes in v4:
> >- add documentation for error codes
> > Changes in v3:
> >- add error return codes
> > Changes in v2:
> >- add info in header regarding the function
> >
> >drivers/power/regulator/regulator_common.c | 22
> > ++
> >drivers/power/regulator/regulator_common.h | 21 +
> >2 files changed, 43 insertions(+)
> >
> > diff --git a/drivers/power/regulator/regulator_common.c
> > b/drivers/power/regulator/regulator_common.c
> > index 93d8196b381e..484a4fc31ef7 100644
> > --- a/drivers/power/regulator/regulator_common.c
> > +++ b/drivers/power/regulator/regulator_common.c
> > @@ -73,6 +73,23 @@ int regulator_common_set_enable(const struct udevice
> > *dev,
> > return 0;
> > }
> >
> > + /* If previously enabled, increase count */
> > + if (enable && dev_pdata->enable_count > 0) {
> > + dev_pdata->enable_count++;
> > + return -EALREADY;
> > + }
> > +
> > + if (!enable) {
> > + if (dev_pdata->enable_count > 1) {
> > + /* If enabled multiple times, decrease count */
> > + dev_pdata->enable_count--;
> > + return -EBUSY;
> > + } else if (!dev_pdata->enable_count) {
> > + /* If already disabled, do nothing */
> > + return -EALREADY;
> > + }
> > + }
> > +
>
> Eugen,
>
> Thank you for working on this series!
> >>>
> >>> Hi Tim,
> >>>
> >>> Thank you for testing and having a look on my patches.
>
> I wonder if instead of returning a failure you should print an error
> here but return 0 in order to not break unbalanced regulator calls
> >>>
> >>> Initially I did that, but Simon forced me to return error as you see now.
> >>
> >> Ok, I see that discussion here:
> >> https://patchwork.ozlabs.org/project/uboot/patch/20230328130127.20279-1-eugen.hris...@collabora.com/#3086660
> >>
> >>>
> (like what is done in clk_disable()). I see that you have another
> patch in this series which handles htis for
> regulator_set_enable_if_allowed() but that doesn't cover drivers that
> call regulator_common_set_enable() directly such as
> drivers/power/regulator/fixed.c and
> drivers/power/regulator/gpio-regulator.c.
> >>>
> >>> I believe Jonas (in CC) fixed those with a patch, but at the moment I am
> >>> lost in providing you a link to it
> >>
> >> Are you thinking of "pci: pcie_dw_rockchip: Use
> >> regulator_set_enable_if_allowed"
> >> https://patchwork.ozlabs.org/project/uboot/patch/20230422181943.889436-3-jo...@kwiboo.se/
> >> ?
> >>
> >> I added some debug prints to regulator_set_enable and see:
> >> starting USB...
> >> Bus usb@32e4: regulator_set_enable regulator-usb-otg1 enable
> >> regulator_set_enable regulator-usb-otg1 enable ret=0
> >> Bus usb@32e5: regulator_set_enable regulator-usb-otg2 enable
> >> regulator_set_enable regulator-usb-otg2 enable ret=0
> >> regulator_set_enable regulator-usb-otg2 enable
> >> regulator_set_enable regulator-usb-otg2 enable ret=-114
> >> Error enabling VBUS supply (ret=-114)
> >> regulator_set_enable regulator-usb-otg2 disable
> >> regulator_set_enable regulator-usb-otg2 disable ret=-16
> >> probe failed, error -114
> >>
> >> So clearly something is trying to enable regulator-usb-otg2 when it's
> >> already enabled but I don't think that should be considered an error
> >> and cause a failure.
> >>
> >> Simon, is this what you were intending with your feedback?
> >>
>
> I know there is an unbalanced call currently on imx8mm that this patch
> causes a failure where it previously did not:
> u-boot=> usb start && usb tree
> starting USB...
> Bus usb@32e4: Bus
Re: [PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi
Hi Rasmus, On Mon, 1 May 2023 at 02:49, Rasmus Villemoes wrote: > > On 27/04/2023 19.31, Tom Rini wrote: > >> > >> Well, I'm not sure there's a use case for building all of the extra > >> device trees. I think what I'll do right now is fire off a CI run (or a > >> few, in the event of problems) where we just use the logic of > >> 3609e1dc5f4d and see what falls down. > > > > So this gets us a few failures. You can see them on > > https://source.denx.de/u-boot/u-boot/-/jobs/618127 but one type of > > failure seems to be the case where CONFIG_DEFAULT_DEVICE_TREE isn't > > contained in CONFIG_OF_LIST (ls1088aqds_tfa for example) and the other > > case is where CONFIG_OF_LIST != CONFIG_SPL_OF_LIST and this fails > > because fdtgrep runs NOT on spl/arch/.../foo.dtb but rather > > arch/.../foo.dtb and so we don't have the dtb file around. > > > > Hm, the former sounds like a bug in the defconfig, the second sounds > like a legit use case (or why would we have SPL_OF_LIST). Anyway, both > should be fixable by just changing the logic of scripts/Makefile.dts a > little; say add the union of DEFAULT_DEVICE_TREE, OF_LIST and > SPL_OF_LIST to dtb-y. Something like > > diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts > index 2561025da8..5e2429c617 100644 > --- a/scripts/Makefile.dts > +++ b/scripts/Makefile.dts > @@ -1,3 +1,3 @@ > # SPDX-License-Identifier: GPL-2.0+ > > -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_$(SPL_)OF_LIST))) > +dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) > $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST))) I think we should require that all the DTs in the list are already built using the standard rule. i.e. Makefile.dts should just have a check that OF_LIST doesn't bring in anything new. If it does, then the build should fail. The list is really about which ones should be put into the FIT. We shouldn't be putting in things that don't exist normally for that SoC. Meanwhile I think we should move towards prohibiting CONFIG_TARGET_... in Makefile rules, since this is creating some of this problem. i.e. we should do what Linux does. I was pushing back on this problem in reviews, but not for a while, and I see that it has grown. That could be a checkpatch rule. It should be possible to use 'moveconfig -i' to find which SoC things belong to. Regards, Simon
[ANN] U-Boot v2023.07-rc1 released
Hey all, It seems that I'm very hit or miss on getting -rc1 out in time. I had convinced myself that I had planned for it to be May 1 and so ignored my reminder last week, as I had just gotten back from vacation. So, here we are, and I'm just going to go short for -rc2 to get us back on track. I'm hoping for some more PRs to come in still as there's a number of SoCs with outstanding patches that to me seem like they should be fine, and I'm also going to put together a network PR once Ramon says he's finished looking over his queue. In terms of a changelog, git log --merges v2023.04..v2023.07-rc1 contains what I've pulled but as always, better PR messages and tags will provide better results here. I'm going to try and stay on schedule now and that means the rest of the rcs every other Monday, and with final release on July 3rd, 2023. Thanks all! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] arch: arm: mach-k3: Delete tifs node in DT fixup
On 4/26/23 9:13 AM, Kumar, Udit wrote: Hi Neha, On 4/26/2023 5:31 PM, Neha Malcom Francis wrote: Hi Udit On 26/04/23 16:09, Kumar, Udit wrote: Hi Neha, Hi Udit, [..] I do have a general doubt; why do we have only atf-sram sub-node in msmc_sram in all other devices (j721e, j7200 and am65) except j721s2? let me know, which source code you are referring to In U-Boot, for j721e, j7200 and am65; they *only* contain atf-sram? For u-boot please see https://elixir.bootlin.com/u-boot/latest/source/arch/arm/dts/k3-j721s2-main.dtsi#L16 I could see for j721s2 as well, in uboot[0] and Linux[1] [..] What I mean to ask is, why aren't there tifs or l3cache subnodes in j721e, j7200 and am65? I think, above platform is doing in right way, AFAIK, if we have to provide then we can provide size of this. l3-cache can not be addressable. So the history here is we used to have the SRAM node in DT sized to the actual size in hardware. L3 cache size can be set at boot time (in SYSFW board-config file), and that uses up some of the SRAM, so the end address moves in. We could represent this as a reserved node inside the full SRAM node, or by shrinking the SRAM node and hiding this. Same story for TIFS and ATF, they use some variable amount of the end of SRAM. I'd prefer being explicit and keep these nodes. Andrew But in any case, u-boot removes this code before passing to OS. https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-k3/common.c#L354 Thanking You Neha Malcom Francis
Re: [PATCH] cmd/fdt: fix conf node lookup failure check
Hi, On Mon, May 1, 2023 at 4:19 PM Baruch Siach wrote: > > fit_conf_get_node() returns negative value on error. > > Signed-off-by: Baruch Siach > --- > cmd/fdt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > There is already a patch on the ML before: https://patchwork.ozlabs.org/project/uboot/patch/20230501033526.1150030-1-bm...@tinylab.org/ Regards, Bin
Re: Pull request: u-boot-sunxi/master for 2023.07
On Mon, May 01, 2023 at 12:18:33AM +0100, Andre Przywara wrote: > Hi Tom, > > please pull the second part of the sunxi pull request for this cycle. > Another bunch of patches that replace old-school U-Boot hacks with > proper DM based code, this time for the raw NAND flash driver, and the > USB PHY VBUS detection code. Plus two smaller patches that were sitting > in my inbox for a while. > > Gitlab CI passed. In lack of some supported board with NAND flash I > couldn't really test this part, but apparently this was tested by the > reviewer. I briefly ran the branch on some boards with USB-OTG, and > this still worked. > > Thanks, > Andre > > > The following changes since commit c9c2c95d4cd27fe0cd41fe13a863899d268f973c: > > Merge branch '2023-04-27-introduce-nvm-xip-block-storage-emulation' > (2023-04-27 19:22:38 -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-sunxi.git master > > for you to fetch changes up to 25bc7bfc30532098d9207783ff2ca45cdc5a0161: > > Kconfig: Remove an impossible condition (2023-04-28 01:32:05 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] usb: gadget: Compile USB ethernet gadget only if NET is enabled
On Sun, Apr 30, 2023 at 11:20:35PM +0200, Marek Vasut wrote: > In case NET networking is not enabled, it is not possible to compile > the USB ethernet gadget. Protect the symbols in Makefile to avoid build > failure. Such build failure may occur e.g. in case NET and USB ethernet > gadget is enabled in U-Boot proper, but not in SPL. > > Signed-off-by: Marek Vasut > --- > Cc: Lukasz Majewski > --- > drivers/usb/gadget/Makefile | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile > index 6cfe0f3a041..36f65e7eb95 100644 > --- a/drivers/usb/gadget/Makefile > +++ b/drivers/usb/gadget/Makefile > @@ -34,8 +34,10 @@ endif > > obj-$(CONFIG_CI_UDC) += ci_udc.o > > +ifeq ($(CONFIG_$(SPL_TPL_)NET),y) > obj-$(CONFIG_USB_ETHER) += ether.o > obj-$(CONFIG_USB_ETH_RNDIS) += rndis.o > +endif > > # Devices not related to the new gadget layer depend on CONFIG_USB_DEVICE > # This is really only N900 and USBTTY now. Why can't we just enforce this via Kconfig? -- Tom signature.asc Description: PGP signature
RE: atmel_sdhci: SDMMC_CD pin still needed for card detection despite EMMC set to non-removable
Hi,
> Can you find some place to set this bit in the atmel sdhci driver, and not in
> the core?
> The MC1R register is specific to at91 device.
I've overridden get_cd of the driver, below is the patch:
From e186af71297e9ae6ce241a85bff64683949f0e1b Mon Sep 17 00:00:00 2001
From: Zixun LI
Date: Mon, 1 May 2023 14:02:21 +0200
Subject: [PATCH] atmel_sdhci: Force card-detect if MMC_CAP_NONREMOVABLE.
Signed-off-by: Zixun LI
---
drivers/mmc/atmel_sdhci.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/drivers/mmc/atmel_sdhci.c b/drivers/mmc/atmel_sdhci.c
index 37b0beeed4..fa32055d1f 100644
--- a/drivers/mmc/atmel_sdhci.c
+++ b/drivers/mmc/atmel_sdhci.c
@@ -15,6 +15,9 @@
#define ATMEL_SDHC_MIN_FREQ40
#define ATMEL_SDHC_GCK_RATE24000
+#define ATMEL_SDHC_MC1R 0x204
+#define ATMEL_SDHC_MC1R_FCD0x80
+
#ifndef CONFIG_DM_MMC
int atmel_sdhci_init(void *regbase, u32 id)
{
@@ -59,8 +62,42 @@ static int atmel_sdhci_deferred_probe(struct sdhci_host
*host)
return sdhci_probe(dev);
}
+static int atmel_sdhci_get_cd(struct sdhci_host *host)
+{
+ struct mmc *mmc = host->mmc;
+ int value;
+
+ /* If nonremovable, assume that the card is always present. */
+ if (mmc->cfg->host_caps & MMC_CAP_NONREMOVABLE)
+ {
+ value = sdhci_readb(host, ATMEL_SDHC_MC1R);
+ sdhci_writeb(host, ATMEL_SDHC_MC1R_FCD | value,
ATMEL_SDHC_MC1R);
+ return 1;
+ }
+ /* If polling, assume that the card is always present. */
+ if (mmc->cfg->host_caps & MMC_CAP_NEEDS_POLL)
+ return 1;
+
+#if CONFIG_IS_ENABLED(DM_GPIO)
+ value = dm_gpio_get_value(>cd_gpio);
+ if (value >= 0) {
+ if (mmc->cfg->host_caps & MMC_CAP_CD_ACTIVE_HIGH)
+ return !value;
+ else
+ return value;
+ }
+#endif
+ value = !!(sdhci_readl(host, SDHCI_PRESENT_STATE) &
+ SDHCI_CARD_PRESENT);
+ if (mmc->cfg->host_caps & MMC_CAP_CD_ACTIVE_HIGH)
+ return !value;
+ else
+ return value;
+}
+
static const struct sdhci_ops atmel_sdhci_ops = {
.deferred_probe = atmel_sdhci_deferred_probe,
+ .get_cd = atmel_sdhci_get_cd,
};
static int atmel_sdhci_probe(struct udevice *dev)
--
2.40.1
Re: [PATCH] arm: mach-k3: am625_init: Add Erratum WA for RTC startup
On 14:26-20230427, Bryan Brattlof wrote:
> From: Nishanth Menon
>
> Add erratum i2327 work around for initialization for RTC
> interrupt where interrupt is stuck for ever at startup. Unfortunately,
> this workaround needs to be applied under 1 second of boot.
>
> Signed-off-by: Nishanth Menon
> [b...@ti.com: rebased from 2021.01]
> Signed-off-by: Bryan Brattlof
> ---
It will be good to state in the diffstat that am62a7 or other k3 SoCs
are not impacted: am62a7 has the hardware fix and other SoCs do not have
this rtc.
I dont think there is a need to respin the patch for that - just clarifying.
> arch/arm/mach-k3/am625_init.c | 44 +++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm/mach-k3/am625_init.c b/arch/arm/mach-k3/am625_init.c
> index a91c15ca4e188..e90c18fdcc118 100644
> --- a/arch/arm/mach-k3/am625_init.c
> +++ b/arch/arm/mach-k3/am625_init.c
> @@ -15,6 +15,15 @@
> #include
> #include
>
> +#define RTC_BASE_ADDRESS 0x2b1f
> +#define REG_K3RTC_S_CNT_LSW (RTC_BASE_ADDRESS + 0x18)
> +#define REG_K3RTC_KICK0 (RTC_BASE_ADDRESS + 0x70)
> +#define REG_K3RTC_KICK1 (RTC_BASE_ADDRESS + 0x74)
> +
> +/* Magic values for lock/unlock */
> +#define K3RTC_KICK0_UNLOCK_VALUE 0x83e70b13
> +#define K3RTC_KICK1_UNLOCK_VALUE 0x95a4f1e0
> +
> /*
> * This uninitialized global variable would normal end up in the .bss
> section,
> * but the .bss is cleared between writing and reading this variable, so move
> @@ -71,6 +80,40 @@ static __maybe_unused void enable_mcu_esm_reset(void)
> writel(stat, CTRLMMR_MCU_RST_CTRL);
> }
>
> +#if defined(CONFIG_CPU_V7R)
> +
> +/*
> + * RTC Erratum i2327 Workaround
> + * Due to a bug in initial synchronization out of cold power on,
> + * IRQ status can get locked infinitely if we do not:
> + * a) unlock RTC
> + *
> + * This workaround *must* be applied within 1 second of power on,
> + * So, this is closest point to be able to guarantee the max
> + * timing.
> + */
> +void rtc_erratumi2327_init(void)
> +{
> + u32 counter;
> +
> + /*
> + * If counter has gone past 1, nothing we can do, leave
> + * system locked! This is the only way we know if RTC
> + * can be used for all practical purposes.
> + */
> + counter = readl(REG_K3RTC_S_CNT_LSW);
> + if (counter > 1)
> + return;
> + /*
> + * Need to set this up at the very start
> + * MUST BE DONE under 1 second of boot.
> + */
> + writel(K3RTC_KICK0_UNLOCK_VALUE, REG_K3RTC_KICK0);
> + writel(K3RTC_KICK1_UNLOCK_VALUE, REG_K3RTC_KICK1);
> + return;
> +}
> +#endif
> +
> void board_init_f(ulong dummy)
> {
> struct udevice *dev;
> @@ -78,6 +121,7 @@ void board_init_f(ulong dummy)
>
> #if defined(CONFIG_CPU_V7R)
> setup_k3_mpu_regions();
> + rtc_erratumi2327_init();
> #endif
>
> /*
>
> base-commit: a25dcda452bf6a6de72764a8d990d72e5def643d
> --
> 2.40.0
>
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5
849D 1736 249D
[PATCH 1/1] MAINTAINERS: update SiFive HiFive Unmatched maintainers
Email account pragnesh.pa...@sifive.com does not exist anymore. Signed-off-by: Heinrich Schuchardt --- board/sifive/unmatched/MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/board/sifive/unmatched/MAINTAINERS b/board/sifive/unmatched/MAINTAINERS index 94c9510bfa..e601a0f328 100644 --- a/board/sifive/unmatched/MAINTAINERS +++ b/board/sifive/unmatched/MAINTAINERS @@ -1,6 +1,5 @@ SiFive HiFive Unmatched FU740 BOARD M: Paul Walmsley -M: Pragnesh Patel M: Green Wan S: Maintained F: board/sifive/unmatched/ -- 2.39.2
[PATCH 1/1] doc: correct HiFive Unmatched boot description
Main U-Boot is loaded by sector number, not by partition GUID type.
Fixes: 70415e1e528d ("board: sifive: add HiFive Unmatched board support")
Signed-off-by: Heinrich Schuchardt
---
doc/board/sifive/unmatched.rst | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/doc/board/sifive/unmatched.rst b/doc/board/sifive/unmatched.rst
index a99442277b..de2aab59bb 100644
--- a/doc/board/sifive/unmatched.rst
+++ b/doc/board/sifive/unmatched.rst
@@ -56,8 +56,10 @@ Flashing
ZSBL loads the U-Boot SPL (u-boot-spl.bin) from a partition with GUID type
5B193300-FC78-40CD-8002-E86C45580B47
-U-Boot SPL expects u-boot.itb from a partition with GUID
-type 2E54B353-1271-4842-806F-E436D6AF6985
+With the default configuration U-Boot SPL expects u-boot.itb starting at sector
+2082 (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR=0x822). It is recommended to use
a
+partition with type GUID 2E54B353-1271-4842-806F-E436D6AF6985 for storing
+main U-Boot.
u-boot.itb is a combination of fw_dynamic.bin, u-boot-nodtb.bin and
device tree blob (hifive-unmatched-a00.dtb)
--
2.39.2
[PATCH 1/1] doc: fix StarFive VisionFive v2 documentation
The number of the partition that U-Boot SPL loads the main U-Boot from is
defined as 2 by CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=0x2. The
partition type GUID is not used currently.
Reword the description of the boot process to make it clearer.
Fixes: 5ecf9b0b8a75 ("board: starfive: add StarFive VisionFive v2 board
support")
Signed-off-by: Heinrich Schuchardt
---
doc/board/starfive/visionfive2.rst | 21 ++---
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/doc/board/starfive/visionfive2.rst
b/doc/board/starfive/visionfive2.rst
index 22d2a31ff5..6acd2234ec 100644
--- a/doc/board/starfive/visionfive2.rst
+++ b/doc/board/starfive/visionfive2.rst
@@ -79,14 +79,19 @@ This will generate u-boot-spl.bin.normal.out file.
Flashing
-SPL loads the U-Boot SPL (u-boot-spl.bin.normal.out) from a partition with
GUID type
-2E54B353-1271-4842-806F-E436D6AF6985
+The device firmware loads U-Boot SPL (u-boot-spl.bin.normal.out) from the
+partition with type GUID 2E54B353-1271-4842-806F-E436D6AF6985. You are free
+to choose any partition number.
-U-Boot SPL expects a U-Boot FIT image (u-boot.itb) from a partition with GUID
-type BC13C2FF-59E6-4262-A352-B275FD6F7172
+With the default configuration U-Boot SPL loads the U-Boot FIT image
+(u-boot.itb) from partition 2 (CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=0x2).
+When formatting it is recommended to use GUID
+BC13C2FF-59E6-4262-A352-B275FD6F7172 for this partition.
-FIT image (u-boot.itb) is a combination of fw_dynamic.bin, u-boot-nodtb.bin and
-device tree blob
(jh7110-starfive-visionfive-2-v1.3b.dtb/jh7110-starfive-visionfive-2-v1.2a.dtb)
+The FIT image (u-boot.itb) is a combination of OpenSBI's fw_dynamic.bin,
+u-boot-nodtb.bin and the device tree blob
+(jh7110-starfive-visionfive-2-v1.3b.dtb or
+jh7110-starfive-visionfive-2-v1.2a.dtb).
Format the SD card (make sure the disk has GPT, otherwise use gdisk to switch)
@@ -117,7 +122,9 @@ Program the SD card
Booting
~~~
-Change DIP switches MSEL[1:0] are set to 10, select the boot mode to SD.
+The board provides the DIP switches MSEL[1:0] to select the boot device.
+To select booting from SD-card set the DIP switches MSEL[1:0] to 10.
+
Once you plugin the sdcard and power up, you should see the U-Boot prompt.
Sample boot log from StarFive VisionFive2 board
--
2.39.2
[PATCH] rockchip: Pinebook Pro: Fix emmc default configuration
If u-boot is installed on the internal emmc, then this will allow to boot without failure. Signed-off-by: Wolfgang Zarre --- configs/pinebook-pro-rk3399_defconfig | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/configs/pinebook-pro-rk3399_defconfig b/configs/pinebook-pro-rk3399_defconfig index dff4695e37..58a8b91aa6 100644 --- a/configs/pinebook-pro-rk3399_defconfig +++ b/configs/pinebook-pro-rk3399_defconfig @@ -6,6 +6,7 @@ CONFIG_TEXT_BASE=0x0020 CONFIG_NR_DRAM_BANKS=1 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x30 +CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_ENV_SIZE=0x8000 CONFIG_ENV_OFFSET=0x3F8000 CONFIG_DEFAULT_DEVICE_TREE="rk3399-pinebook-pro" @@ -18,6 +19,7 @@ CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SPL_SPI_FLASH_SUPPORT=y CONFIG_SPL_SPI=y CONFIG_SYS_LOAD_ADDR=0x800800 +CONFIG_PCI=y CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y @@ -57,17 +59,23 @@ CONFIG_LED=y CONFIG_LED_GPIO=y CONFIG_MISC=y CONFIG_ROCKCHIP_EFUSE=y +CONFIG_MMC_IO_VOLTAGE=y +CONFIG_SPL_MMC_IO_VOLTAGE=y +CONFIG_MMC_UHS_SUPPORT=y +CONFIG_SPL_MMC_UHS_SUPPORT=y +CONFIG_MMC_HS400_ES_SUPPORT=y +CONFIG_SPL_MMC_HS400_ES_SUPPORT=y +CONFIG_MMC_HS400_SUPPORT=y +CONFIG_SPL_MMC_HS400_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_SF_DEFAULT_BUS=1 -CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_NVME_PCI=y -CONFIG_PCI=y CONFIG_PHY_ROCKCHIP_INNO_USB2=y CONFIG_PHY_ROCKCHIP_TYPEC=y CONFIG_DM_PMIC_FAN53555=y -- 2.39.2
Re: [PATCH v2 18/30] sandbox: Disable raw Ethernet on MSYS2
Hi Simon, On Sun, Apr 30, 2023 at 9:30 AM Simon Glass wrote: > > This relies on Linux features so cannot be built for Windows. Drop it. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > arch/sandbox/cpu/Makefile | 2 ++ > drivers/net/Makefile | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/arch/sandbox/cpu/Makefile b/arch/sandbox/cpu/Makefile > index 7c5c52652f5c..be6b57692dd5 100644 > --- a/arch/sandbox/cpu/Makefile > +++ b/arch/sandbox/cpu/Makefile > @@ -9,7 +9,9 @@ obj-y := cache.o cpu.o state.o > extra-y:= start.o os.o > extra-$(CONFIG_SANDBOX_SDL)+= sdl.o > obj-$(CONFIG_SPL_BUILD)+= spl.o > +ifeq ($(MSYS_VERSION),0) > obj-$(CONFIG_ETH_SANDBOX_RAW) += eth-raw-os.o > +endif > > # os.c is build in the system environment, so needs standard includes > # CFLAGS_REMOVE_os.o cannot be used to drop header include path > diff --git a/drivers/net/Makefile b/drivers/net/Makefile > index 46a40e2ed9f8..6580f8d85510 100644 > --- a/drivers/net/Makefile > +++ b/drivers/net/Makefile > @@ -30,8 +30,10 @@ obj-$(CONFIG_ETH_DESIGNWARE_MESON8B) += dwmac_meson8b.o > obj-$(CONFIG_ETH_DESIGNWARE_S700) += dwmac_s700.o > obj-$(CONFIG_ETH_DESIGNWARE_SOCFPGA) += dwmac_socfpga.o > obj-$(CONFIG_ETH_SANDBOX) += sandbox.o > +ifeq ($(MSYS_VERSION),0) > obj-$(CONFIG_ETH_SANDBOX_RAW) += sandbox-raw-bus.o > obj-$(CONFIG_ETH_SANDBOX_RAW) += sandbox-raw.o > +endif > obj-$(CONFIG_FEC_MXC) += fec_mxc.o > obj-$(CONFIG_FMAN_ENET) += fm/ > obj-$(CONFIG_FMAN_ENET) += fsl_mdio.o > -- In patch #16, you introduced CC_IS_MSYS. I think you can just make CONFIG_ETH_SANDBNOX_RAW depend on !CC_IS_MSYS? Regards, Bin
Re: [PATCH v2 17/30] Kbuild: Detect including an MSYS2 path
Hi Simon, On Sun, Apr 30, 2023 at 9:30 AM Simon Glass wrote: > > The source-tree directory is prepended to relative include paths, but this > does not work on Windows, where a path may have a drive letter like C: at > the start of it. > > This breaks SDL which includes an absolute path to the header directory to > the C flags, e.g. -IC:/msys64/mingw64/include/SDL2 > > Add this as a special case to leave these absolute paths alone on Windows. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > scripts/Kbuild.include | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include > index 62e0207f91b4..411a768a7767 100644 > --- a/scripts/Kbuild.include > +++ b/scripts/Kbuild.include > @@ -205,9 +205,10 @@ clean := -f $(srctree)/scripts/Makefile.clean obj > hdr-inst := -f $(srctree)/scripts/Makefile.headersinst obj > > # Prefix -I with $(srctree) if it is not an absolute path. > +# Detect C: (C drive) with MSYS2 > # skip if -I has no parameter > addtree = $(if $(patsubst -I%,%,$(1)), \ > -$(if $(filter-out -I/% -I./% -I../%,$(1)),$(patsubst > -I%,-I$(srctree)/%,$(1)),$(1)),$(1)) > +$(if $(filter-out -I/% -I./% -I../% -IC:%,$(1)),$(patsubst > -I%,-I$(srctree)/%,$(1)),$(1)),$(1)) What happens if MSYS2 is not installed to the C drive? > > # Find all -I options and call addtree > flags = $(foreach o,$($(1)),$(if $(filter -I%,$(o)),$(call > addtree,$(o)),$(o))) > -- Regards, Bin
Re: [PATCH v2 16/30] Makefile: Disable LTO when not building with gcc
Hi Simon, On Sun, Apr 30, 2023 at 9:30 AM Simon Glass wrote: > > For MSYS2 this creates a lot of errors of the form: > > `__stack_chk_fail' referenced in section `.text' of ...ltrans.o: defined >in discarded section `.text' of common/stackprot.o (symbol from plugin) > > For clang it doesn't work, except with sandbox. To clarify, you didn't use clang on Windows to build Sandbox? > > Update the dependency to (hopefully) deal with all of that. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Make LTO depend on !MSYS2 rather than adding another check > - Also disable LTO for clang, except with sandbox > > Kconfig | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/Kconfig b/Kconfig > index 888b9984ac3b..9ac816abef1c 100644 > --- a/Kconfig > +++ b/Kconfig > @@ -72,6 +72,9 @@ config CLANG_VERSION > int > default $(shell,$(srctree)/scripts/clang-version.sh $(CC)) > > +config CC_IS_MSYS > + def_bool $(success,uname -o | grep -q Msys) > + > choice > prompt "Optimization level" > default CC_OPTIMIZE_FOR_SIZE > @@ -121,6 +124,8 @@ config ARCH_SUPPORTS_LTO > config LTO > bool "Enable Link Time Optimizations" > depends on ARCH_SUPPORTS_LTO > + depends on CC_IS_GCC || (CC_IS_CLANG && SANDBOX) This looks like a separate patch needed for adding dependency check for LTO? > + depends on !CC_IS_MSYS > help > This option enables Link Time Optimization (LTO), a mechanism which > allows the compiler to optimize between different compilation units. > -- Regards, Bin
Re: [PATCH v2 15/30] ctype: Avoid using a symlink
Hi Simon, On Sun, Apr 30, 2023 at 9:30 AM Simon Glass wrote: > > Windows doesn't really support symlinks so fails to build this file. Use > a single-line #include instead. > > Signed-off-by: Simon Glass > --- > > (no changes since v1) > > include/ctype.h | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > mode change 12 => 100644 include/ctype.h > This patch does not seem necessary if: 1. Enable Windows developer mode 2. export MSYS=winsymlinks:native Regards, Bin
Re: [PATCH v2 14/30] test: Avoid strange symbols in the assembler file
On Sun, Apr 30, 2023 at 9:30 AM Simon Glass wrote: > > This works correctly on Linux with ELF but not on Windows with PE, since > it creates assembly symbols with invalid names. > > Use the lowest/highest valid characters instead. This should still work > correctly, since we have no tests starting with $ and none starting with > 'zz' at present. > > Signed-off-by: Simon Glass > --- > > Changes in v2: > - Update comment and use zz to make it less likely we have a problem > > include/test/test.h | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > Reviewed-by: Bin Meng Tested-by: Bin Meng
Re: [PATCH] scripts/Makefile.lib: also consider $(CONFIG_SYS_BOARD)-u-boot.dtsi
On 27/04/2023 19.31, Tom Rini wrote: >> >> Well, I'm not sure there's a use case for building all of the extra >> device trees. I think what I'll do right now is fire off a CI run (or a >> few, in the event of problems) where we just use the logic of >> 3609e1dc5f4d and see what falls down. > > So this gets us a few failures. You can see them on > https://source.denx.de/u-boot/u-boot/-/jobs/618127 but one type of > failure seems to be the case where CONFIG_DEFAULT_DEVICE_TREE isn't > contained in CONFIG_OF_LIST (ls1088aqds_tfa for example) and the other > case is where CONFIG_OF_LIST != CONFIG_SPL_OF_LIST and this fails > because fdtgrep runs NOT on spl/arch/.../foo.dtb but rather > arch/.../foo.dtb and so we don't have the dtb file around. > Hm, the former sounds like a bug in the defconfig, the second sounds like a legit use case (or why would we have SPL_OF_LIST). Anyway, both should be fixable by just changing the logic of scripts/Makefile.dts a little; say add the union of DEFAULT_DEVICE_TREE, OF_LIST and SPL_OF_LIST to dtb-y. Something like diff --git a/scripts/Makefile.dts b/scripts/Makefile.dts index 2561025da8..5e2429c617 100644 --- a/scripts/Makefile.dts +++ b/scripts/Makefile.dts @@ -1,3 +1,3 @@ # SPDX-License-Identifier: GPL-2.0+ -dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_$(SPL_)OF_LIST))) +dtb-y += $(patsubst %,%.dtb,$(subst ",,$(CONFIG_DEFAULT_DEVICE_TREE) $(CONFIG_OF_LIST) $(CONFIG_SPL_OF_LIST)))
[PATCH] cmd/fdt: fix conf node lookup failure check
fit_conf_get_node() returns negative value on error.
Signed-off-by: Baruch Siach
---
cmd/fdt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/cmd/fdt.c b/cmd/fdt.c
index aae3278526c4..2401ea8b44cb 100644
--- a/cmd/fdt.c
+++ b/cmd/fdt.c
@@ -733,7 +733,7 @@ static int do_fdt(struct cmd_tbl *cmdtp, int flag, int
argc, char *const argv[])
gd->fdt_blob = blob;
cfg_noffset = fit_conf_get_node(working_fdt, NULL);
- if (!cfg_noffset) {
+ if (cfg_noffset < 0) {
printf("Could not find configuration node: %s\n",
fdt_strerror(cfg_noffset));
return CMD_RET_FAILURE;
--
2.39.2
Re: [PATCH v5 1/3] regulator: implement basic reference counter
On 4/30/23 21:21, Jonas Karlman wrote:
Hi Tim,
On 2023-04-28 18:36, Tim Harvey wrote:
On Fri, Apr 28, 2023 at 12:39 AM Eugen Hristev
wrote:
On 4/28/23 02:39, Tim Harvey wrote:
On Wed, Apr 19, 2023 at 6:45 AM Eugen Hristev
wrote:
Some devices share a regulator supply, when the first one will request
regulator disable, the second device will have it's supply cut off before
graciously shutting down. Hence there will be timeouts and other failed
operations.
Implement a reference counter mechanism similar with what is done in
Linux, to keep track of enable and disable requests, and only disable the
regulator when the last of the consumers has requested shutdown.
Signed-off-by: Eugen Hristev
Reviewed-by: Simon Glass
---
Changes in v5:
- none
Changes in v4:
- add documentation for error codes
Changes in v3:
- add error return codes
Changes in v2:
- add info in header regarding the function
drivers/power/regulator/regulator_common.c | 22 ++
drivers/power/regulator/regulator_common.h | 21 +
2 files changed, 43 insertions(+)
diff --git a/drivers/power/regulator/regulator_common.c
b/drivers/power/regulator/regulator_common.c
index 93d8196b381e..484a4fc31ef7 100644
--- a/drivers/power/regulator/regulator_common.c
+++ b/drivers/power/regulator/regulator_common.c
@@ -73,6 +73,23 @@ int regulator_common_set_enable(const struct udevice *dev,
return 0;
}
+ /* If previously enabled, increase count */
+ if (enable && dev_pdata->enable_count > 0) {
+ dev_pdata->enable_count++;
+ return -EALREADY;
+ }
+
+ if (!enable) {
+ if (dev_pdata->enable_count > 1) {
+ /* If enabled multiple times, decrease count */
+ dev_pdata->enable_count--;
+ return -EBUSY;
+ } else if (!dev_pdata->enable_count) {
+ /* If already disabled, do nothing */
+ return -EALREADY;
+ }
+ }
+
Eugen,
Thank you for working on this series!
Hi Tim,
Thank you for testing and having a look on my patches.
I wonder if instead of returning a failure you should print an error
here but return 0 in order to not break unbalanced regulator calls
Initially I did that, but Simon forced me to return error as you see now.
Ok, I see that discussion here:
https://patchwork.ozlabs.org/project/uboot/patch/20230328130127.20279-1-eugen.hris...@collabora.com/#3086660
(like what is done in clk_disable()). I see that you have another
patch in this series which handles htis for
regulator_set_enable_if_allowed() but that doesn't cover drivers that
call regulator_common_set_enable() directly such as
drivers/power/regulator/fixed.c and
drivers/power/regulator/gpio-regulator.c.
I believe Jonas (in CC) fixed those with a patch, but at the moment I am
lost in providing you a link to it
Are you thinking of "pci: pcie_dw_rockchip: Use
regulator_set_enable_if_allowed"
https://patchwork.ozlabs.org/project/uboot/patch/20230422181943.889436-3-jo...@kwiboo.se/
?
I added some debug prints to regulator_set_enable and see:
starting USB...
Bus usb@32e4: regulator_set_enable regulator-usb-otg1 enable
regulator_set_enable regulator-usb-otg1 enable ret=0
Bus usb@32e5: regulator_set_enable regulator-usb-otg2 enable
regulator_set_enable regulator-usb-otg2 enable ret=0
regulator_set_enable regulator-usb-otg2 enable
regulator_set_enable regulator-usb-otg2 enable ret=-114
Error enabling VBUS supply (ret=-114)
regulator_set_enable regulator-usb-otg2 disable
regulator_set_enable regulator-usb-otg2 disable ret=-16
probe failed, error -114
So clearly something is trying to enable regulator-usb-otg2 when it's
already enabled but I don't think that should be considered an error
and cause a failure.
Simon, is this what you were intending with your feedback?
I know there is an unbalanced call currently on imx8mm that this patch
causes a failure where it previously did not:
u-boot=> usb start && usb tree
starting USB...
Bus usb@32e4: Bus usb@32e5: Error enabling VBUS supply (ret=-114)
probe failed, error -114
That's a good catch.
I expected such things would happen if I would return error in those
cases, so it might be that this is not the only case.
If you are able to test that board, do you wish me to send you a patch
that changes the code to using regulator_set_enable_if_allowed() ?
Yes, I can test. Are you thinking changing the calls to
regulator_common_set_enable (used in
drivers/power/regulator/fixed{gpio-regulator,regulator_common} to a
wrapper calling regulator_common_set_enable_if_allowed instead? I
think that would just be the same thing as removing the error as no
callers of that function would be left.
This is nothing that should be changed in the fixed/gpio/common
regulator code. Such change should happen in the drivers that call the
