linux-kernel - Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 17 Sep 2019 20:03:10 +0200
From:   Stefan Wahren <stefan.wahren@...e.com>
To:     Matthias Brugger <matthias.bgg@...il.com>,
        Stefan Wahren <wahrenst@....net>,
        Matthias Brugger <mbrugger@...e.com>, robh+dt@...nel.org,
        linux-arm-kernel@...ts.infradead.org,
        Nicolas Saenz Julienne <nsaenzjulienne@...e.de>
Cc:     f.fainelli@...il.com, phil@...pberrypi.org,
        linux-rpi-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 0/4] Raspberry Pi 4 DMA addressing support

Hi Matthias,

Am 17.09.19 um 11:04 schrieb Matthias Brugger:
>
> On 16/09/2019 21:19, Stefan Wahren wrote:
>> Hi Matthias,
>>
>> [drop uninvolved receiver]
>>
>> Am 13.09.19 um 12:39 schrieb Matthias Brugger:
>>>>>>>  If you talk about the
>>>>>>> downstream kernel, I suppose you mean we should change this in the FW DT blob
>>>>>>> and in the downstream kernel. That would work for me.
>>>>>>>
>>>>>>> Did I understand you correctly?
>>>>>> Yes
>>>>>>
>>>>>> So i suggest to add the upstream compatibles into the repo mentioned above.
>>>>>>
>>>>>> Sorry, but in case you decided as a U-Boot developer to be compatible
>>>>>> with a unreviewed DT, we also need to make U-Boot compatible with
>>>>>> upstream and downstream DT blobs.
>>>>>>
>>>>> Well RPi3 is working with the DT blob provided by the FW, as I mentioned earlier
>>>>> if we can use this DTB we can work towards one binary that can boot both RPi3
>>>>> and RPi4. On the other hand we can rely on the FW to detect the amount of memory
>>>>> our RPi4 has.
>>>>>
>>>>> That said, I agree that we should make sure that U-Boot can boot with both DTBs,
>>>>> the upstream one and the downstream. Now the question is how to get to this. I'm
>>>>> a bit puzzled that by talking about "unreviewed DT" you insinuate that bcm2711
>>>>> compatible is already reviewed and can't be changed. From what I can see none of
>>>>> these compatibles got merged for now, so we are still at time to change them.
>>>> Stephen Boyd was okay with clk changes except of a small nit. So i fixed
>>>> this is as he suggested in a separate series. Unfortunately this hasn't
>>>> be applied yet [1].
>>>>
>>>> The i2c, pinctrl and the sdhci changes has been applied yet.
>>>>
>>>> In my opinion it isn't the job of the mainline kernel to adapt to a
>>>> vendor device tree. It's the vendor device tree which needs to be fixed.
>>>>
>>> I agree with that. But if we can make this easier by choosing a compatible which
>>> fits downstream without violating upstream and it makes sense with the naming
>>> scheme of the RPi, I think that's a good argument.
>> i spend a lot of my spare time to prepare these patch series in order to
>> get a clean solution.
>>
>> Either mixing bcm2711/bcm2838 or changing everything to bcm2838 in the
>> upstream tree has the following drawbacks:
>>
>> - additional review time and delay of the Raspberry Pi 4 support
>> - harder to understand for developer/reviewer without RPi knowledge
> On the other hand it get's confusing that the SoC for RPi4 is called bcm2711
> while all the others are named bcm283x.
one could argue this is a complete new SoC. But i got your point.
>  Anyway if the majority prefers bcm2711
> so shall it be and let's get forward instead :)
>
>> Btw currently u-boot only uses bcm2711, so it would be nice to keep that.
>>
> Yes that's true. We already identified the compatible we'll need to add to
> U-Boot to also boot with the upstream DTS. I'll send a patch to the U-Boot
> mailinglist.
Since the upstream DTS isn't completely stable yet, maybe you better
wait until it has been accepted.
>
>> So my suggestion is to add bcm2711 compatibles in the downstream tree.
>>
> Ok, can you take care of it, or shall I send a pull request/open a bug?

I'll send a send a pull request and hope the RPi guys are happy with it.

Btw the clk changes has been applied.

Stefan