[U-Boot] [PATCH v3 2/8] arm: socfpga: fix device trees to work with DM serial

[Marek Vasut]

On 08/13/2018 03:41 PM, Tom Rini wrote:
> On Mon, Aug 13, 2018 at 03:36:35PM +0200, Simon Goldschmidt wrote:
>> Tom Rini <trini at konsulko.com> schrieb am Mo., 13. Aug. 2018, 15:33:
>>
>>> On Mon, Aug 13, 2018 at 03:29:30PM +0200, Marek Vasut wrote:
>>>> On 08/13/2018 03:28 PM, Tom Rini wrote:
>>>>> On Mon, Aug 13, 2018 at 03:25:19PM +0200, Simon Goldschmidt wrote:
>>>>>> On Mon, Aug 13, 2018 at 3:17 PM Tom Rini <trini at konsulko.com> wrote:
>>>>>>>
>>>>>>> On Mon, Aug 13, 2018 at 09:33:45AM +0200, Simon Goldschmidt wrote:
>>>>>>>
>>>>>>>> Device trees need to have the serial console device available
>>>>>>>> before relocation and require a stdout-path in chosen at least
>>>>>>>> for SPL to have a console.
>>>>>>>>
>>>>>>>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
>>>>>>>> ---
>>>>>>>>
>>>>>>>> Changes in v3:
>>>>>>>> - moved uart0's "u-boot,dm-pre-reloc;" from socfpga.dtsi to board
>>>>>>>>   specific dts files since this can change per board
>>>>>>>
>>>>>>> Why are these not in socfpga-u-boot.dtsi ?  We have the mechanism to
>>>>>>> grab CONFIG_SYS_CPU/CONFIG_SYS_SOC/CONFIG_SYS_VENDOR-u-boot.dtsi
>>>>>>> automatically so that we don't have to modify the files we sync in
>>> from
>>>>>>> upstream.
>>>>>>
>>>>>> Ehrm, I don't know, really. The DTS files for socfpga already have
>>>>>> many U-Boot specifics and are quite different to Linux. It might make
>>>>>> sense to sync them, but do we really have to do this for 2018.09?
>>>>>>
>>>>>> Keep in mind that this series exists to fix that 2018.07 broke on
>>> these boards.
>>>>>
>>>>> Well, I think given that you're adding these changes right now, they
>>>>> should be added to the correct file so that they aren't lost on re-sync
>>>>> later.  It would be adding:
>>>>> &uart0 {
>>>>>        u-boot,dm-pre-reloc;
>>>>> };
>>>>>
>>>>> once to arch/arm/dts/socfpga-u-boot.dtsi rather than for every board.
>>>>
>>>> Pulling the U-Boot specific crap would be most welcome, but it could be
>>>> a separate patch.
>>>
>>> So you want to add stuff now and pull it out later?  That seems counter
>>> intuitive, but sure, you're the custodian here.  When do you plan to do
>>> the clean-up, for v2018.11?
>>>
>>
>> Can we do this in one step with syncing up to the latest Linux device trees?
> 
> I honestly don't understand the hesitation to not introduce more change
> than is required now.  But, I will defer.  I do want to know when people
> plan to fix this however, as that feels like a reasonable compromise to
> me.

I presume Simon will stick around, so I'm happy to cut him some slack ...

-- 
Best regards,
Marek Vasut