[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150716005358.GJ32767@usrtlx11787.corpusers.net>
Date: Wed, 15 Jul 2015 17:53:58 -0700
From: Bjorn Andersson <bjorn.andersson@...ymobile.com>
To: Tim Bird <tim.bird@...ymobile.com>
CC: Rob Herring <robherring2@...il.com>, Arnd Bergmann <arnd@...db.de>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH 1/3] ARM: dts: qcom: Add binding for the qcom coincell
charger
On Wed 15 Jul 15:27 PDT 2015, Tim Bird wrote:
>
>
> On 07/15/2015 02:22 PM, Rob Herring wrote:
> > On Wed, Jul 15, 2015 at 1:24 PM, Tim Bird <tim.bird@...ymobile.com> wrote:
> >> On 07/14/2015 06:07 PM, Rob Herring wrote:
> >>> On Tue, Jul 14, 2015 at 4:41 PM, Tim Bird <tim.bird@...ymobile.com> wrote:
> >>>> On 07/13/2015 08:59 PM, Rob Herring wrote:
> >>>>> On Mon, Jul 13, 2015 at 6:39 PM, Tim Bird <tim.bird@...ymobile.com> wrote:
> >>>>>> This binding is used to configure the driver for the coincell charger
> >>>>>> found in Qualcomm PMICs.
> >
> > [...]
> >
> >>>>>> +- qcom,charge-enable:
> >>>>>> + Usage: optional
> >>>>>> + Value type: <u32> or <none>
> >>>>>> + Definition: definining this property, with an optional non-zero
> >>>>>> + value, enables charging
> >>>>>
> >>>>> I'm not sure that this belongs in DT. Don't you want to enable
> >>>>> charging when plugged in perhaps or at some voltage threshold?
> >>>>
> >>>> In practice this is never changed at runtime. It's only set at kernel boot.
> >>>> The main use of this is to override (either on or off) whatever the firmware
> >>>> did.
> >>>
> >>> If your firmware and dtb are separate from your kernel, then ... (well
> >>> you know where I'm headed :) ).
> >>
> >> Sorry, I have no idea how the sentence would end, so I think I'm missing
> >> where you are headed.
> >
> > dtbs should be separate from the kernel and part of the firmware. I'm
> > certain you recall those discussions or have sucessfully blocked them
> > from memory.
>
> Ah yes, those discussions. :-)
>
> Having dtbs come from firmware is not on the horizon yet
> for projects I'm working on, so I haven't really considered
> the ramifications.
>
This has nothing to do about how the dtb, kernel and boot is stored on
the device; we already store them as 3 separate entities and they can be
upgraded independently. Neither one of them is read only and they will
never be!
We've already passed the point where we've gotten the pieces into
mainline that would make it possible to run all devices on e.g. the 8974
platform from a single zImage. The fact that we store the dtb in
adjacent blocks is simply a convenience thing.
Regards,
Bjorn
--
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