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: <CAAhV-H74rSy3DkFFgyGwW-rGO5tVJhrthQ78vAztnzze7-NYrA@mail.gmail.com>
Date:   Mon, 18 Jul 2022 10:38:09 +0800
From:   Huacai Chen <chenhuacai@...nel.org>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Jianmin Lv <lvjianmin@...ngson.cn>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>, loongarch@...ts.linux.dev,
        Hanjun Guo <guohanjun@...wei.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Jiaxun Yang <jiaxun.yang@...goat.com>,
        Huacai Chen <chenhuacai@...ngson.cn>
Subject: Re: [PATCH V15 00/15] irqchip: Add LoongArch-related irqchip drivers

Hi, Marc,

On Sun, Jul 17, 2022 at 10:43 PM Marc Zyngier <maz@...nel.org> wrote:
>
> On Sun, 17 Jul 2022 15:08:14 +0100,
> Huacai Chen <chenhuacai@...nel.org> wrote:
> >
> > Hi, Marc, Jianmin,
> >
> > I have an idea but I don't know whether it is acceptable: Marc gives
> > an Acked-by for the whole series, then this irqchip series goes
> > through the loongarch tree together with the PCI patches, then we
> > don't need other hacks except the ACPI definitions.
>
> Not sure how this solves the original problem. PCI should never be
> mandatory (it is actually super useful to be able to build a very
> small kernel without too many drivers), and there shouldn't be
> configurations where the kernel doesn't build.
Now, the pci-loongson controller code (A) is in the PCI tree, the pci
enablement code (B) is in the LoongArch tree, and the irqchip code (C)
is in the irqchip tree. If the order for upstream is (A) --> (B) -->
(C), there will be no build error. My above idea is to make sure the
order of (B) and (C) is controlled in the same tree. PCI/MSI is a
mandatory requirement for LoongArch, so I want to avoid some
unnecessary #ifdefs.

>
> It is also my own responsibility to merge these things, and I'd rather
> not delegate this, specially as it touches a bunch of other
> subsystems.
I know, this is reasonable. Then if we can control the order of
(A)(B)(C) in three trees, the build error can be avoided in the
linux-next tree.

Huacai

>
> Thanks,
>
>         M.
>
> --
> Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ