u-boot.git/test/dm, branch v2021.10

pci: Drop DM_PCI

2021-09-13T22:23:13Z

This option has not effect now. Drop it, using PCI instead where needed. Signed-off-by: Simon Glass

bootcount: add a new driver with syscon as backend

2021-08-22T09:04:52Z

The driver will use a syscon regmap as backend and supports both 16 and 32 size value. The value will be stored in the CPU's endianness. Signed-off-by: Nandor Han Reviewed-by: Simon Glass

i2c: add dm_i2c_reg_clrset

2021-08-22T08:52:53Z

Add function to apply a bitmask to an i2c register, so that specific bits can be cleared and/or set. Suggested-by: Simon Glass Signed-off-by: Sebastian Reichel Reviewed-by: Simon Glass

test: dm: Add test for ECDSA UCLASS support

2021-08-16T08:49:35Z

This test verifies that ECDSA_UCLASS is implemented, and that ecdsa_verify() works as expected. The definition of "expected" is "does not find a device, and returns -ENODEV". The lack of a hardware-independent ECDSA implementation prevents us from having one in the sandbox, for now. Signed-off-by: Alexandru Gagniuc Reviewed-by: Simon Glass Reviewed-by: Patrick Delaunay

dm: core: Don't allow uclass use before ready

2021-08-08T17:27:27Z

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 Fixes: 8a715530bb1 ("dm: core: Allow the uclass list to move")

dtoc: Support widening a bool value

2021-08-01T15:05:24Z

At present if we see 'ranges' property (with no value) we assume it is a boolean, as per the devicetree spec. But another node may define 'ranges' with a value, forcing us to widen it to an int array. At present this is not supported and causes an error. Fix this and add some test cases. Signed-off-by: Simon Glass Reported-by: Tom Rini

dtoc: Fix widening an int array to an int

2021-08-01T15:05:24Z

An int array can hold a single int so we should not need to do anything in the widening operation. However due to a quirk in the code, an int[3] widened with an int produced an int[4]. Fix this and add a test. Fix a comment typo while we are here. Signed-off-by: Simon Glass Reported-by: Tom Rini

dm: test: Add test case to check node name ignoring unit address

2021-07-27T05:26:53Z

Add test to check node name ignoring unit address. Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Lokesh Vutla Reviewed-by: Simon Glass Link: https://lore.kernel.org/r/20210721155849.20994-3-kishon@ti.com

reboot-mode: read the boot mode from RTC memory

2021-07-23T14:16:39Z

RTC devices could provide battery-backed memory that can be used for storing the reboot mode magic value. Add a new reboot-mode back-end that uses RTC to store the reboot-mode magic value. The driver also supports both endianness modes. Signed-off-by: Nandor Han Reviewed-by: Simon Glass

reboot-mode: read the boot mode from GPIOs status

2021-07-23T14:16:39Z

A use case for controlling the boot mode is when the user wants to control the device boot by pushing a button without needing to go in user-space. Add a new backed for reboot mode where GPIOs are used to control the reboot-mode. The driver is able to scan a predefined list of GPIOs and return the magic value. Having the modes associated with the magic value generated based on the GPIO values, allows the reboot mode uclass to select the proper mode. Signed-off-by: Nandor Han Reviewed-by: Simon Glass