Simon, > On 14.12.2018, at 17:06, Simon Glass <s...@chromium.org> wrote: > > Hi Philipp, > > On Fri, 14 Dec 2018 at 09:04, Philipp Tomsich > <philipp.toms...@theobroma-systems.com > <mailto:philipp.toms...@theobroma-systems.com>> wrote: >> >> >> >> On 14.12.2018, at 16:37, Simon Glass <s...@chromium.org> wrote: >> >> Hi, >> >> On Mon, 10 Dec 2018 at 18:07, Simon Glass <s...@chromium.org> wrote: >> >> >> Hi Philipp, >> >> On Tue, 27 Nov 2018 at 15:00, Philipp Tomsich >> <philipp.toms...@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.toms...@theobroma-systems.com> >> Tested-by: Klaus Goger <klaus.go...@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 > :-)
I knew I couldn’t get away with it, but couldn’t resist to try it anyway... > It's normally a very small amount of work, particularly for something > like this. Keep it simple. As the original series is already on master, I sent the new test as a separate patch. Feel free to comment and request more embellishments. Thanks, Philipp. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
