Hi Philipp,
On Fri, 14 Dec 2018 at 09:04, Philipp Tomsich philipp.tomsich@theobroma-systems.com wrote:
On 14.12.2018, at 16:37, Simon Glass sjg@chromium.org wrote:
Hi,
On Mon, 10 Dec 2018 at 18:07, Simon Glass sjg@chromium.org wrote:
Hi Philipp,
On Tue, 27 Nov 2018 at 15:00, Philipp Tomsich philipp.tomsich@theobroma-systems.com wrote:
The original bootcount methods do not provide an interface to DM and rely on a static configuration for I2C devices (e.g. bus, chip-addr, etc. are configured through defines statically). On a modern system that exposes multiple devices in a DTS-configurable way, this is less than optimal and a interface to DM-based devices will be desirable.
This adds a simple driver that is DM-aware and configurable via DTS. If ambiguous (i.e. multiple bootcount-devices are present) the /chosen/u-boot,bootcount-device property can be used to select one bootcount device.
Initially, this provides support for the following DM devices:
- RTC devices
Signed-off-by: Philipp Tomsich philipp.tomsich@theobroma-systems.com Tested-by: Klaus Goger klaus.goger@theobroma-systems.com
Changes in v2:
- changed to provide a UCLASS-based implementation, as requested by
SJG in his earlier review
- split off the RV3029 driver into a separate series
doc/device-tree-bindings/chosen.txt | 30 ++++++++++++ drivers/bootcount/Kconfig | 8 ++++ drivers/bootcount/Makefile | 2 + drivers/bootcount/bootcount-uclass.c | 93 ++++++++++++++++++++++++++++++++++++ include/bootcount.h | 48 +++++++++++++++++++ include/dm/uclass-id.h | 1 + 6 files changed, 182 insertions(+) create mode 100644 drivers/bootcount/bootcount-uclass.c
Just checking if there is a text and sandbox driver for this?
Oops I meant test, sorry. All uclasses should have a test.
Not yet, I’ll get started on it. So now I know why I had initially tried to avoid making this a uclass ;-)
Well let me rephrase it...we should have tests for all common code in U-Boot :-)
It's normally a very small amount of work, particularly for something like this. Keep it simple.
- Simon