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: <87wnjbtm0x.wl-maz@kernel.org>
Date:   Fri, 07 Jan 2022 18:53:50 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Pali Rohár <pali@...nel.org>
Cc:     Marek Behún <kabel@...nel.org>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Rob Herring <robh+dt@...nel.org>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Russell King <rmk+kernel@...linux.org.uk>,
        linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 10/11] PCI: mvebu: Implement support for legacy INTx interrupts

On Fri, 07 Jan 2022 11:50:53 +0000,
Pali Rohár <pali@...nel.org> wrote:
> 
> On Thursday 06 January 2022 17:31:36 Marc Zyngier wrote:
> > On Thu, 06 Jan 2022 17:20:44 +0000,
> > Marek Behún <kabel@...nel.org> wrote:
> > > 
> > > On Thu, 06 Jan 2022 16:27:44 +0000
> > > Marc Zyngier <maz@...nel.org> wrote:
> > > > You are completely missing my point. I'm talking about data
> > > > structures, you're talking about interrupts. You have this:
> > > > 
> > > > struct mvebu_pcie_port {
> > > >        // Tons of stuff
> > > >        struct irq_chip intx_chip;
> > > > };
> > > > 
> > > > What I want you to do is:
> > > > 
> > > > struct mvebu_pcie_port {
> > > >        // Tons of stuff
> > > > };
> > > > 
> > > > static struct irq_chip intx_chip = {
> > > > 	.name		= "INTx",
> > > > 	.irq_mask	= mvebu_pcie_intx_irq_mask,
> > > > 	.irq_unmask	= mvebu_pcie_intx_irq_unmask;
> > > > };
> > > > 
> > > > That's it. No more, no less.
> > > > 
> > > > 	M.
> > > > 
> > > 
> > > Hmm, but struct irq_chip contains a dynamic member,
> > >   struct device *parent_device;
> > > Isn't that used? Or are you planning to kill it?
> > 
> > Indeed, and I am definitely planning to kill it. This is the wrong
> > place for this stuff, and I want it gone. There are thankfully very
> > few users of this misfeature.
> 
> Ok, so what about this change?
> 
> @@ -1458,7 +1617,17 @@ static int mvebu_pcie_remove(struct platform_device *pdev)
>  		mvebu_writel(port, cmd, PCIE_CMD_OFF);
>  
>  		/* Mask all interrupt sources. */
> -		mvebu_writel(port, 0, PCIE_MASK_OFF);
> +		mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_UNMASK_OFF);
> +
> +		/* Clear all interrupt causes. */
> +		mvebu_writel(port, ~PCIE_INT_ALL_MASK, PCIE_INT_CAUSE_OFF);
> +
> +		/* Remove IRQ domains. */
> +		if (port->intx_irq_domain)
> +			irq_domain_remove(port->intx_irq_domain);
> +
> +		if (irq > 0)
> +			irq_set_chained_handler_and_data(irq, NULL, NULL);

You really want this to be done *before* you remove the domain, as
there still could be interrupts in flight at this point.

	M.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ