Hello Wolfram,

Wolfram Sang wrote:

On Sun, Dec 04, 2011 at 10:45:21AM +0100, Heiko Schocher wrote:

quoted

This driver implements the Linux kernel half of the boot count feature -
the boot counter can only be reset after it is clear that the
application has been started and is running correctly, which usually
can only be determined by the application code itself. Thus the reset
of the boot counter must be done by application code, which thus needs
an appropriate driver.

An appropriate mechanism, not necessarily a driver, see below.

quoted

Required feature by the Carrier Grade Linux Requirements Definition;
see for example document "Carrier Grade Linux Requirements Definition
Overview V3.0" at

http://www.linuxfoundation.org/collaborate/workgroups/cgl/requirements#SMM.6.0_Boot_Cycle_Detection

      Description: OSDL CGL specifies that carrier grade Linux
      shall provide support for detecting a repeating reboot cycle
	due to recurring failures. This detection should happen in
	user space before system services are started.

So, technically, a flag would be enough, not necessarily a counter? Although a
counter probably has more advantages...

quoted

This driver provides read/write access to the U-Boot bootcounter
through PROC FS and/or sysFS file.

Why ProcFS? Why ProcFS and/or SysFS? Which has priority? Why not /dev?

I drop the ProcFS support for v2.

quoted

The bootcountregister gets configured via DTS.
for example on the enbw_cmc board:

bootcount@0x23060 {
                  compatible = "uboot,bootcount";

No. I assume you are not the vendor of what is at 0x23060, the actual device.
Only the device must be encoded in the compatible-entry which then implies the
bootcount functionality. Also, keep in mind that your solution should be
generic for bootloaders.

So I should call it compatible = "generic, bootcount" ?

quoted

                  reg = <0x23060 0x20>;

I assume that non-volatile memory would qualify as a boot-counter, so those
could be tied to I2C busses etc? reg would not fit then.

Currently, mem only supported, add this to the Documentation and log
message.

I do wonder if it makes more sense to add such functionality to the
watchdog-core to save the additional device (CCed). Needs a second thought,
though...

Thanks!

bye,
heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany