u-boot.git/include/dm, branch v2021.10 Unnamed repository; edit this file 'description' to name the repository. mtd: spi: nor: force mtd name to "nor%d" 2021-09-28T16:03:20+00:00 Patrick Delaunay patrick.delaunay@foss.st.com 2021-09-22T16:29:08+00:00 a4f2d83414557f2ad7b63d537e2c31790d0f184d Force the mtd name of spi-nor to "nor" + the driver sequence number: "nor0", "nor1"... beginning after the existing nor devices. This patch is coherent with existing "nand" and "spi-nand" mtd device names. When CFI MTD NOR device are supported, the spi-nor index is chosen after the last CFI device defined by CONFIG_SYS_MAX_FLASH_BANKS. When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated, this config is replaced by to cfi_flash_num_flash_banks in the include file mtd/cfi_flash.h. This generic name "nor%d" can be use to identify the mtd spi-nor device without knowing the real device name or the DT path of the device, used with API get_mtd_device_nm() and is used in mtdparts command. This patch also avoids issue when the same NOR device is present 2 times, for example on STM32MP15F-EV1: STM32MP> mtd list SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, \ total 64 MiB List of MTD devices: * nand0 - type: NAND flash - block size: 0x40000 bytes - min I/O: 0x1000 bytes - OOB size: 224 bytes - OOB available: 118 bytes - ECC strength: 8 bits - ECC step size: 512 bytes - bitflip threshold: 6 bits - 0x000000000000-0x000040000000 : "nand0" * mx66l51235l - device: mx66l51235l@0 - parent: spi@58003000 - driver: jedec_spi_nor - path: /soc/spi@58003000/mx66l51235l@0 - type: NOR flash - block size: 0x10000 bytes - min I/O: 0x1 bytes - 0x000000000000-0x000004000000 : "mx66l51235l" * mx66l51235l - device: mx66l51235l@1 - parent: spi@58003000 - driver: jedec_spi_nor - path: /soc/spi@58003000/mx66l51235l@1 - type: NOR flash - block size: 0x10000 bytes - min I/O: 0x1 bytes - 0x000000000000-0x000004000000 : "mx66l51235l" The same mtd name "mx66l51235l" identify the 2 instances mx66l51235l@0 and mx66l51235l@1. This patch fixes a ST32CubeProgrammer / stm32prog command issue with nor0 target on STM32MP157C-EV1 board introduced by commit b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when DM is enabled"). Fixes: b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when DM is enabled") Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> [trini: Add <dm/device.h> to <mtd.h> for DM_MAX_SEQ_STR] Signed-off-by: Tom Rini <trini@konsulko.com> 
Force the mtd name of spi-nor to "nor" + the driver sequence number:
"nor0", "nor1"... beginning after the existing nor devices.

This patch is coherent with existing "nand" and "spi-nand"
mtd device names.

When CFI MTD NOR device are supported, the spi-nor index is chosen after
the last CFI device defined by CONFIG_SYS_MAX_FLASH_BANKS.

When CONFIG_SYS_MAX_FLASH_BANKS_DETECT is activated, this config
is replaced by to cfi_flash_num_flash_banks in the include file
mtd/cfi_flash.h.

This generic name "nor%d" can be use to identify the mtd spi-nor device
without knowing the real device name or the DT path of the device,
used with API get_mtd_device_nm() and is used in mtdparts command.

This patch also avoids issue when the same NOR device is present 2 times,
for example on STM32MP15F-EV1:

STM32MP> mtd list
SF: Detected mx66l51235l with page size 256 Bytes, erase size 64 KiB, \
total 64 MiB

List of MTD devices:
* nand0
  - type: NAND flash
  - block size: 0x40000 bytes
  - min I/O: 0x1000 bytes
  - OOB size: 224 bytes
  - OOB available: 118 bytes
  - ECC strength: 8 bits
  - ECC step size: 512 bytes
  - bitflip threshold: 6 bits
  - 0x000000000000-0x000040000000 : "nand0"
* mx66l51235l
  - device: mx66l51235l@0
  - parent: spi@58003000
  - driver: jedec_spi_nor
  - path: /soc/spi@58003000/mx66l51235l@0
  - type: NOR flash
  - block size: 0x10000 bytes
  - min I/O: 0x1 bytes
  - 0x000000000000-0x000004000000 : "mx66l51235l"
* mx66l51235l
  - device: mx66l51235l@1
  - parent: spi@58003000
  - driver: jedec_spi_nor
  - path: /soc/spi@58003000/mx66l51235l@1
  - type: NOR flash
  - block size: 0x10000 bytes
  - min I/O: 0x1 bytes
  - 0x000000000000-0x000004000000 : "mx66l51235l"

The same mtd name "mx66l51235l" identify the 2 instances
mx66l51235l@0 and mx66l51235l@1.

This patch fixes a ST32CubeProgrammer / stm32prog command issue
with nor0 target on STM32MP157C-EV1 board introduced by
commit b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when
DM is enabled").

Fixes: b7f060565e31 ("mtd: spi-nor: allow registering multiple MTDs when DM is enabled")
Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
[trini: Add <dm/device.h> to <mtd.h> for DM_MAX_SEQ_STR]
Signed-off-by: Tom Rini <trini@konsulko.com>
dm: crypto: Define UCLASS API for ECDSA signature verification 2021-08-16T08:49:35+00:00 Alexandru Gagniuc mr.nuke.me@gmail.com 2021-07-29T16:47:15+00:00 1d54af1392513c09927b97981356acadfa626d63 Define a UCLASS API for verifying ECDSA signatures. Unlike UCLASS_MOD_EXP, which focuses strictly on modular exponentiation, the ECDSA class focuses on verification. This is done so that it better aligns with mach-specific implementations, such as stm32mp. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> 
Define a UCLASS API for verifying ECDSA signatures. Unlike
UCLASS_MOD_EXP, which focuses strictly on modular exponentiation,
the ECDSA class focuses on verification. This is done so that it
better aligns with mach-specific implementations, such as stm32mp.

Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
dm: core: Don't allow uclass use before ready 2021-08-08T17:27:27+00:00 Simon Glass sjg@chromium.org 2021-08-01T18:05:23+00:00 1e9ced28f18ed75bef96df08e47baad27dd51829 At present it is possible to call uclass_get() before driver model is inited. In fact this happens on x86 boards which use Intel FSPv1, since mrccache_get_region() tries to get the SPI flash device very early during init. This has always been undefined behaviour. Previously it generally worked, i.e. returned an error code without crashing, because gd->uclass_root_s is zeroed and the uclass can be added despite driver model not being ready, due to the way lists are implemented. With the change to use a gd->uclass_root pointer, this no-longer works. For example, it causes a hang on minnowmax. Fix this by adding a check that driver model is ready when uclass_get() is called. This function is called in the process of locating any device, so it is a good place to add the check. This fixes booting on minnowmax. Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 8a715530bb1 ("dm: core: Allow the uclass list to move") 
At present it is possible to call uclass_get() before driver model is
inited. In fact this happens on x86 boards which use Intel FSPv1, since
mrccache_get_region() tries to get the SPI flash device very early
during init.

This has always been undefined behaviour. Previously it generally worked,
i.e. returned an error code without crashing, because gd->uclass_root_s
is zeroed and the uclass can be added despite driver model not being
ready, due to the way lists are implemented. With the change to use a
gd->uclass_root pointer, this no-longer works. For example, it causes a
hang on minnowmax.

Fix this by adding a check that driver model is ready when uclass_get() is
called. This function is called in the process of locating any device, so
it is a good place to add the check.

This fixes booting on minnowmax.

Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 8a715530bb1 ("dm: core: Allow the uclass list to move")
dm: migrate the dm_warn to use the log macro 2021-08-08T17:27:27+00:00 Patrick Delaunay patrick.delaunay@foss.st.com 2021-07-30T10:13:11+00:00 b18b38f2ae3f54b906e0f2ab86789d9dd0110ed2 Migrate the dm_warn function to log macro with LOGC_DM category and LOGL_WARNING level. This macro allows filtering with log command and allows output on all log backend. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Migrate the dm_warn function to log macro with
LOGC_DM category and LOGL_WARNING level.

This macro allows filtering with log command and allows
output on all log backend.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
dm: core: Add helper to compare node names 2021-07-27T05:26:53+00:00 Kishon Vijay Abraham I kishon@ti.com 2021-07-21T15:58:30+00:00 77cbaf8837fd096b876d8a6c05d90683f5f4b82e Add helper to compare node names. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/20210721155849.20994-2-kishon@ti.com 
Add helper to compare node names.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Link: https://lore.kernel.org/r/20210721155849.20994-2-kishon@ti.com
reboot-mode: add support for reboot mode control 2021-07-23T14:16:39+00:00 Nandor Han nandor.han@vaisala.com 2021-06-10T13:56:43+00:00 2541ce2c1af87f74a9feb35a1cbfc20ff8d04e4b A new driver uclass is created to handle the reboot mode control. The new uclass driver is updating an environment variable with the configured reboot mode. The mode is extracted from a map provided at initialization time. The map contains a list of modes and associated ids. Signed-off-by: Nandor Han <nandor.han@vaisala.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
A new driver uclass is created to handle the reboot mode control.

The new uclass driver is updating an environment variable with the
configured reboot mode. The mode is extracted from a map provided
at initialization time. The map contains a list of modes
and associated ids.

Signed-off-by: Nandor Han <nandor.han@vaisala.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
cmd: pinmux: update result of do_status 2021-07-23T11:13:25+00:00 Patrick Delaunay patrick.delaunay@foss.st.com 2021-05-21T07:47:31+00:00 4c60fd993a21a285c645c6d46762d8c2992b7dd7 Update the result of do_status and always returns a CMD_RET_ value (-ENOSYS was a possible result of show_pinmux). This patch also adds pincontrol name in error messages (dev->name) and treats correctly the status sub command when pin-controller device is not selected. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Update the result of do_status and always returns a CMD_RET_ value
(-ENOSYS was a possible result of show_pinmux).

This patch also adds pincontrol name in error messages (dev->name)
and treats correctly the status sub command when pin-controller device is
not selected.

Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
remove struct uclass_driver::ops 2021-07-06T16:38:03+00:00 Rasmus Villemoes rasmus.villemoes@prevas.dk 2021-05-19T16:08:11+00:00 98c14ff019515ffcb1b40b550e56fe1dfbede51b Each _device_ belonging to a given uclass of course has its own ->ops, of a type determined by and known to the uclass. However, no instance of a uclass_driver seems to populate ->ops, and the only reference to it in code is this relocation. Moreover, it's not really clear what could sensibly be assigned; it would have to be some "struct uclass_ops *" providing a set of methods for the core to call on that particular uclass, but should the need for that ever arise, it would be better to have a member of that particular type instead of void*. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by: Simon Glass <sjg@chromium.org> 
Each _device_ belonging to a given uclass of course has its own ->ops,
of a type determined by and known to the uclass.

However, no instance of a uclass_driver seems to populate ->ops, and
the only reference to it in code is this relocation.

Moreover, it's not really clear what could sensibly be assigned; it
would have to be some "struct uclass_ops *" providing a set of methods
for the core to call on that particular uclass, but should the need
for that ever arise, it would be better to have a member of that
particular type instead of void*.

Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
Reviewed-by: Simon Glass <sjg@chromium.org>
dm: core: add ofnode_get_path() 2021-06-24T06:23:00+00:00 Marek Behún marek.behun@nic.cz 2021-05-26T12:08:18+00:00 0e116bea52af1b665a656d49c328468e976be913 Add function for retrieving full node path of a given ofnode. This uses np->full_name if OF is live, otherwise a call to fdt_get_path() is made. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> 
Add function for retrieving full node path of a given ofnode.
This uses np->full_name if OF is live, otherwise a call to
fdt_get_path() is made.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
dm: core: add non-translating version of ofnode_get_addr_size_index() 2021-06-24T06:22:45+00:00 Marek Behún marek.behun@nic.cz 2021-05-26T12:08:17+00:00 31a7b719d07ccb11950f423b5f1195375109b5fa Add functions ofnode_get_addr_size_index_notrans(), which is a non-translating version of ofnode_get_addr_size_index(). Some addresses are not meant to be translated, for example those of MTD fixed-partitions. Signed-off-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com> Tested-by: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> 
Add functions ofnode_get_addr_size_index_notrans(), which is a
non-translating version of ofnode_get_addr_size_index().

Some addresses are not meant to be translated, for example those of MTD
fixed-partitions.

Signed-off-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Patrice Chotard <patrice.chotard@foss.st.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>