linux-kernel - Re: [PATCH] rtc: ds1307: add trickle charger device tree binding

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]

Date:	Tue, 9 Sep 2014 13:34:25 +0200
From:	Pavel Machek <pavel@...x.de>
To:	Matti Vaittinen <matti.vaittinen@....com>
Cc:	ext Mark Rutland <mark.rutland@....com>,
	ext Guenter Roeck <linux@...ck-us.net>,
	Jason Cooper <jason@...edaemon.net>,
	"a.zummo@...ertech.it" <a.zummo@...ertech.it>,
	"jic23@...nel.org" <jic23@...nel.org>,
	"arno@...isbad.org" <arno@...isbad.org>,
	"jgunthorpe@...idianresearch.com" <jgunthorpe@...idianresearch.com>,
	"san@...etechnology.dk" <san@...etechnology.dk>,
	"hs@...x.de" <hs@...x.de>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rtc-linux@...glegroups.com" <rtc-linux@...glegroups.com>,
	Sverdlin Alexander <alexander.sverdlin@....com>
Subject: Re: [PATCH] rtc: ds1307: add trickle charger device tree binding

Hi!

> > > > trickle-resistor-ohms = <250>
> > > > diode-connected;
> > > > 
> > > > That's easy for a human to write and/or validate, we can easily extend
> > > > it in future, requires no proliferation of macros, and describes the
> > > > hardware rather than telling software what to do.
> > > > 
> > > > The driver becomes a little more complicated, but gains sanity checking,
> > > > which is a good thing.
> > > 
> > > Certainly looks better than register bit defines.
> > > 
> > > As rtc-bq32k has similar options, I'm interested, too. I believe we
> > > should add
> > > 
> > > trickle-charge-enable;
> 
> I am unsure about this. It makes sense for devices where we cannot
> select resistor but just enable or disable charger. Is there any such
> devices? For devices like ds1339 this makes no sense. For them it is
> simpler to just enable the charger if resistor value is specified, and
> default the charger to be off. But I do not see a problem in supporting
> the trickle-charge-enable; for devices needing this (independently from
> the ds1307 driver).

Ok, just cc me on next version of the driver, and I'll adjust bq32k to
be similar.

> > > (we may not want to charge at all), and I believe the diode should be
> > > 
> > > disconnect-diode;
> > > 
> > > ... With diode connected, charge is slower, and that probably should
> > > be the default value. We don't want to give too much current in
> > > default case.  (bq32k has hard-coded resistor value for
> > > diode/not-diode case).
> > 
> > I agree that if one case is less likely to be problematic / damaging
> > that should be the default.
> 
> _Maybe_ 
> diode-connected = <1>; or 
> diode-connected = <0>; 

That should work.

Actually, make it "connect-diode = <0/1>;", because hardware can
actually select if the diode is connected or not.

> Then one question regarding the "process". Now if I cook up fourth patch
> with inverted diode-connected default for ds1339, should I collect new
> acks for this new patch? (V3 was acked by Alessandro and Jason.) I assume 
> yes.

It depends if patch changed "a lot". I guess you can keep the acks.

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/