linux-kernel - Re: [PATCH v10 5/6] arm64: zynqmp: Add DDRC node

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]

Message-ID: <a81f47e0-1778-a6ac-4cd8-634502661d6f@xilinx.com>
Date:   Mon, 5 Nov 2018 14:32:55 +0100
From:   Michal Simek <michal.simek@...inx.com>
To:     Borislav Petkov <bp@...en8.de>,
        Michal Simek <michal.simek@...inx.com>
CC:     Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
        Manish Narani <manish.narani@...inx.com>, <robh+dt@...nel.org>,
        <mark.rutland@....com>, <mchehab@...nel.org>,
        <amit.kucheria@...aro.org>, <sudeep.holla@....com>,
        <leoyang.li@....com>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-edac@...r.kernel.org>
Subject: Re: [PATCH v10 5/6] arm64: zynqmp: Add DDRC node

On 05. 11. 18 14:20, Borislav Petkov wrote:
> On Mon, Nov 05, 2018 at 02:06:11PM +0100, Michal Simek wrote:
>> I don't think that driver will be broken. You can build them, use them
>> on out of tree HW. And when this patch is merged to mainline it will be
>> enabled for xilinx soc.
> 
> But if the DT entries are missing, the driver won't load, would it?

you don't have that HW anyway.

> 
>> TBH I can't see any reason to do merges but if you want to do that way
>> we can also do it.
> 
> The reason is because there's a separate DT tree and all those arm
> drivers need DT.
> 
> I have already acked EDAC patches to go through other trees too, FWIW.

I looked at v10 and I can't see your ack there. Can you please give me a
link?
I see Rob's reviewed by in v10 2/6

> Which is not optimal either if someone sends fixes ontop but I cannot
> apply them yet because the dependent patches are in a different tree.
> 
> So yes, there are at least two good reasons for merging a shared branch.

I have not a problem with that. I can simply take patch (process via
arm-soc) with pointing to reviewed binding doc and you will take the
rest when this is in arm-soc tree.

Thanks,
Michal