[U-Boot] [PATCH v2 1/2] bootcount: add uclass for bootcount

[Simon Glass]

Hi Philipp,

On Fri, 14 Dec 2018 at 09:04, Philipp Tomsich
<philipp.tomsich at theobroma-systems.com> wrote:
>
>
>
> On 14.12.2018, at 16:37, Simon Glass <sjg at chromium.org> wrote:
>
> Hi,
>
> On Mon, 10 Dec 2018 at 18:07, Simon Glass <sjg at chromium.org> wrote:
>
>
> Hi Philipp,
>
> On Tue, 27 Nov 2018 at 15:00, Philipp Tomsich
> <philipp.tomsich at 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 at theobroma-systems.com>
> Tested-by: Klaus Goger <klaus.goger at 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