[LEDE-DEV] Convert ar71xx to devicetree

[Felix Fietkau]

On 2016-12-08 18:17, John Crispin wrote:
> 
> 
> On 08/12/2016 18:10, Felix Fietkau wrote:
>> On 2016-12-08 18:08, John Crispin wrote:
>>>
>>>
>>> On 08/12/2016 18:06, Felix Fietkau wrote:
>>>> On 2016-12-08 17:31, John Crispin wrote:
>>>>> Hi,
>>>>>
>>>>> i was planning to start working on this in early 2017. i was hoping that
>>>>> rather than converting ar71xx to DT we simply create a new target called
>>>>> ath79 and start moving board support over from the legacy to the new
>>>>> target. this would allow us to make the ath79 target much cleaner than
>>>>> having to worry about legacy cruft.
>>>>>
>>>>> converting all the mach files to dts files is also a bit tricky. back in
>>>>> the day when i converted ramips, i simply create a host lib that
>>>>> provided all the platform_*() callbacks used by the mach files. however
>>>>> rather than register anything the code simply generated the matching dts
>>>>> files. this was really ugly, run once and throw away code.
>>>>>
>>>>> can you share the patches you have already created ? i think we could
>>>>> start working on this now and once the new ath79 target starts to be
>>>>> usable we simply refuse to merge patches to ar71xx and only accept ones
>>>>> for ath79
>>>> I think making this a separate target will make the transition period a
>>>> lot more confusing for users. I think it should not be too hard to
>>>> support both DT and non-DT devices with the same kernel.
>>>>
>>>> I fully agree with refusing to accept non-DT device support once a few
>>>> devices work with DT.
>>>>
>>>> - Felix
>>>>
>>>
>>> how would that be confusing ? i would argue the exact opposite
>> Because suddenly there are two targets and you have to look up which
>> device is supported by which target.
>> 
>> - Felix
>> 
> 
> its a tradeoff we need to consider
> 
> 1) chance to start a new clean target without legacy cruft
> 2) making it easy to find the snapshot
> 
> i would value 1) higher than 2)
I would also like to avoid duplicating things like the ethernet driver,
SPI drivers, the NAND drivers and the patches unrelated to DT and mach-*
stuff.

Also, it's not just about finding the snapshot images. This split is
also quite annoying for people building from source. In some cases
people maintaining their own builds for a group of devices might then
need to start dealing with building multiple targets instead of one, and
will have to re-check frequently if devices moved from one target to the
other.

Maybe a good first step would be to reorganize the patches and split
them into parts ready for upstreaming and parts that contain legacy
stuff that still needs to be cleaned up.

I'm not going to veto any of the different approaches, the decision
should be up to the people doing the actual work.
However, I think this is an important factor to consider.

- Felix