linux-kernel - Re: [PATCH v10 2/5] PCI: Add Loongson PCI Controller 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20200522142759.GA15332@alpha.franken.de>
Date:   Fri, 22 May 2020 16:27:59 +0200
From:   Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc:     Jiaxun Yang <jiaxun.yang@...goat.com>, linux-pci@...r.kernel.org,
        Rob Herring <robh@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Rob Herring <robh+dt@...nel.org>,
        Huacai Chen <chenhc@...ote.com>,
        Paul Burton <paulburton@...nel.org>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mips@...r.kernel.org
Subject: Re: [PATCH v10 2/5] PCI: Add Loongson PCI Controller support

On Fri, May 22, 2020 at 02:40:48PM +0100, Lorenzo Pieralisi wrote:
> On Fri, May 22, 2020 at 09:32:10PM +0800, Jiaxun Yang wrote:
> 
> [...]
> 
> > >> Is it possible to let this series go into next tree soon?
> > >> 
> > >> As LS7A dts patch would depend on this series, and I want to
> > >> make the whole LS7A basic support as a part of 5.8 release.
> > >
> > >I think you have all necessary tags to take this in the MIPS
> > >tree, please let me know if that's the way we want this to go
> > >upstream - I would not pull MIPS/dts changes into the PCI tree
> > >and I don't think it is needed for this series.
> > 
> > Please pull all PCI changes [1~3] into PCI tree.
> 
> Pulled [1,2,3] into pci/mips, thanks !

could please take the other patches, too ?

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]