[GIT PULL 1/3] ARM: tegra: rework PCIe regulators

[Olof Johansson]

On Thu, Jul 17, 2014 at 7:20 AM, Thierry Reding
<thierry.reding at gmail.com> wrote:
> On Thu, Jul 10, 2014 at 12:15:28PM +0200, Thierry Reding wrote:
>> On Mon, Jul 07, 2014 at 09:45:46PM -0700, Olof Johansson wrote:
> [...]
>> > If you have to stay compatible, then I suggest you try to fill in
>> > local driver variables with derivatives of the old properties (and
>> > directly from the newer properties where you can). I haven't looked at
>> > the specifics here so I don't know how hard it might be.
>> >
>> > If you are 100% sure that you don't have to stay compatible, then you
>> > can remove the code handling the old bindings. Still, even then I am a
>> > little worried about dependencies (and more importantly conflicts)
>> > between these dtsi changes and others done by tegra platform code for
>> > this release. I suppose that can be resolved by having this as a base
>> > of any DT changes for tegra if needed.
>>
>> To be honest, I'm very much tempted to just drop this series. Even if
>> that means keeping a totally broken DT binding. But frankly I don't have
>> any energy left to debate DT stability.
>
> So this kept bugging me and I couldn't leave it alone after all. How
> about if I squash in the attached patch. I've verified that that keeps
> compatibility with old device trees on TrimSlice and Beaver. I think the
> remainder of the series could still remain as-is (the top few commits
> that you said shouldn't be there) if I squash this into
>
>         PCI: tegra: Implement accurate power supply scheme
>
> That way the binding will be the new one so that people don't get any
> wrong ideas about taking shortcuts while still preserving compatibility
> with existing DTBs.

Taking a quick look at the patch, it looks sane to me and pretty much
exactly what I would expect the code to look like w.r.t. handling old
bindings.

> Interestingly, despite my initial disgust for having to keep around old
> code (it's in fact new code in this case) for compatibility reasons, it
> ended up making the code look more mature.

I'm glad it went that way. It shouldn't be _too_ bad to keep the
compatibility with old bindings in the code like this in most cases,
it's mostly a matter of filling in the newer structures like you did
in this patch.


-Olof