[<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/
Powered by blists - more mailing lists