linux-kernel - Re: [patches] Re: [PATCH 01/17] drivers: support PCIe in RISCV

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] [day] [month] [year] [list]

Date:   Fri, 23 Jun 2017 14:47:34 -0700 (PDT)
From:   Palmer Dabbelt <palmer@...belt.com>
To:     Olof Johansson <olof@...om.net>
CC:     linux-kernel@...r.kernel.org
Subject:     Re: [patches] Re: [PATCH 01/17] drivers: support PCIe in RISCV

On Wed, 07 Jun 2017 10:40:50 PDT (-0700), Olof Johansson wrote:
> On Wed, Jun 7, 2017 at 10:09 AM, Wesley Terpstra <wesley@...ive.com> wrote:
>>
>>
>> On Jun 7, 2017 7:26 AM, "Christoph Hellwig" <hch@...radead.org> wrote:
>>
>> On Tue, Jun 06, 2017 at 03:59:51PM -0700, Palmer Dabbelt wrote:
>>> From: "Wesley W. Terpstra" <wesley@...ive.com>
>>>
>>> There are RISC-V systems that have been mapped to Xilinx FPGAs that have
>>> their PCIe controllers on chip.  These build system changes allow RISC-V
>>> systems to enable the Xilinx PCIe controller, and to setup PCIe IRQs.
>>>
>>> Signed-off-by: Palmer Dabbelt <palmer@...belt.com>
>>> ---
>>>  drivers/pci/Makefile     | 1 +
>>>  drivers/pci/host/Kconfig | 2 +-
>>>  2 files changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
>>> index 462c1f5f5546..a29d9ec05d13 100644
>>> --- a/drivers/pci/Makefile
>>> +++ b/drivers/pci/Makefile
>>> @@ -41,6 +41,7 @@ obj-$(CONFIG_MIPS) += setup-irq.o
>>>  obj-$(CONFIG_TILE) += setup-irq.o
>>>  obj-$(CONFIG_SPARC_LEON) += setup-irq.o
>>>  obj-$(CONFIG_M68K) += setup-irq.o
>>> +obj-$(CONFIG_RISCV) += setup-irq.o
>>
>> Can we do a cleanup here and add a ARCH_USE_GENERIC_PCI_SETUP Kconfig
>> symbol that all these architectures can select?
>>
>>
>> That would probably be better. I did not want to touch other arch/ folders
>> in our changes.
>
> I understand that approach when you're doing things in your tree
> early, but in this case (and at this phase in submission/merging),
> don't be afraid to touch other architectures and refactor/clean up.
>
> Please do the refactor in a separate preceding patch and submit it
> separate/soon instead of keeping it just in the series and bundled
> with your addition. That way it can go in when ready even if the rest
> of the series is spinning.

Makes sense.  I've started submitting the various smaller patches so we can get
them all in to make our patch set smaller.