linux-kernel - Re: [PATCH v2] rtc: add Abracon ABx80x driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150304090601.GC3989@piout.net>
Date:	Wed, 4 Mar 2015 10:06:01 +0100
From:	Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:	Philippe De Muyter <phdm@...qel.be>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Alessandro Zummo <a.zummo@...ertech.it>,
	linux-kernel@...r.kernel.org, rtc-linux@...glegroups.com
Subject: Re: [PATCH v2] rtc: add Abracon ABx80x driver

On 04/03/2015 at 09:52:42 +0100, Philippe De Muyter wrote :
> > > And is the naming in Philippe's driver appropriate?  If it supports the
> > > AB1801 (for example) then why is it described as an "abx805" driver?
> > 
> > The real naming is in the form ABx8yz. With:
> > 
> > x: 0 or 1, indicate the presence of the reset management
> > y: 0 or 1: 0 is i2c, 1 is spi
> > z: [1-5]: different amount of on chip SRAM. From what I understand, only
> > ABx8y5 are actually recommended for new designs.
> 
> My driver is based on the datashet called 'AB18X5 Real-Time Clock with
> Power Management Family', which calls the parts 'AB18X5 family' with X
> being '0' for I2c parts and '1' for SPI parts.
> 
> As the part I have and the driver I wrote are I2C, not SPI, I fixed the
> 'X' as 0 in the name of the driver.
> 
> The datasheet lists only one part as being 'software and pin compatible'
> with the 'AB1805': the 'AB0805', hence the 'x' in the name I choose : abx805.
> 

The "AB08XX Real-Time Clock Family" document states that they are all
software and pin compatible (including the AB18xx).

> Actually, my driver is used in production and works fine, because the
> default(reset) value of the 12/24 mode bit is '24 hour mode' and the
> default value of the 'write RTC bit' enables writing.  There is
> no real need to play with them.
> 

I know this is unlikely to happen but what if someone messes with the
RTC in the bootloader?

> > 
> > What I like in Philippe's driver is the info printed at probe time and
> > the support for trickle charging. However, I wouldn't enable it
> > unconditionally.
> 
> My hardware colleagues told me that the only way to enable the 'ultra low-power'
> functionality is enabling the trickle charger.  And the 'ultra low-power'
> functionality is the reason we choose that chip, so I would at least
> keep that as the default behaviour.
> 

My concern is that you have a static configuration. I would expose a
sysfs interface to configure the diode, resistor and enable/disable the
trickle charger. Would that work for you?


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/