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]
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ