linux-kernel - Re: [PATCH v1 1/1] mfd: intel-lpss: Switch over to MSI interrupts

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: <20240326220953.GA1498942@bhelgaas>
Date: Tue, 26 Mar 2024 17:09:53 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Lee Jones <lee@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 1/1] mfd: intel-lpss: Switch over to MSI interrupts

On Tue, Mar 26, 2024 at 11:22:16PM +0200, Andy Shevchenko wrote:
> On Tue, Mar 26, 2024 at 04:01:07PM -0500, Bjorn Helgaas wrote:
> > On Tue, Mar 26, 2024 at 06:21:47PM +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 25, 2024 at 04:19:15PM -0500, Bjorn Helgaas wrote:
> > > > On Tue, Mar 12, 2024 at 06:59:05PM +0200, Andy Shevchenko wrote:
> 
> ...
> 
> > > > > -	ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_LEGACY);
> > > > > +	ret = pci_alloc_irq_vectors(pdev, 1, 1, PCI_IRQ_ALL_TYPES);
> > > > >  	if (ret < 0)
> > > > >  		return ret;
> > > > 
> > > > I guess at least some of these devices do support INTx, since we
> > > > always used INTx previously, right?
> > > > 
> > > > There are a bunch of bug reports complaining about a lack of _PRT
> > > > entries for them, e.g., these from
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=212261#c24:
> > > 
> > > But this is not related to my patch, and the mentioned bug report seems about
> > > all AMD and Intel platforms.
> > > 
> > > Can you, please, elaborate what the relation to my patch?
> > 
> > Right, sorry I didn't make that clear; I didn't mean that it was
> > related to your patch.  I was just looking at this old bug report
> > about not being able to figure out INTx routing.
> > 
> > Your patch had to do with interrupts, so I just wondered whether you
> > had insight into whether these devices actually used INTx.  My guess
> > is that at least some of them *do* use INTx, because prior to your
> > patch, the driver *only* tried to use INTx.
> > 
> > If it happend that they never use INTx, but advertise INTA via
> > Interrupt Pin, I think that would be a device defect that we might
> > consider a quirk for.
> > 
> > If they *do* use INTx, and the _PRT doesn't tell us how it's routed, I
> > think that would be a firmware defect, and ... I dunno what we would
> > do.  I guess just avoid using INTx because we don't know where the
> > interupt goes.
> 
> Okay, so the revert after all is not required, do you agree?

Yes, I agree!  No indication of problems with your patch, AFAICS.

If you have any opinions or ideas on the "can't derive routing for PCI
INT A" stuff, I'd still be interested, because it really annoys users.

Bjorn