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, 6 May 2008 13:08:14 -0600
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	Rene Herman <rene.herman@...access.nl>
Cc:	Uwe Bugla <uwe.bugla@....de>, Takashi Iwai <tiwai@...e.de>,
	Len Brown <len.brown@...el.com>, Andrew Morton <akpm@...l.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] PNP: add AD1815 and AD1816 quirks

On Monday 05 May 2008 07:08:19 pm Rene Herman wrote:
> The AD181x chip doesn't support an IRQ-less MPU401 option but works
> fine without one. This adds (priority: functional) IRQ-less options
> for each port option to help systems with few available IRQs.
> 
> The AD1815 quirk can't use pnp_register_irq_resource() due to doubly
> penalizing the IRQ. Also, while not a practical issue due to no IRQ
> option being present for the dependents, this needs to add in front,
> not back.
> 
> Doesn't use pnp_register_port_resource() for symetry with above.
> 
> This does not delete the AD1815 independent option even though it
> should be empty after the IRQ transfer due to AD1816 coming with an
> empty but still present independent option by default.
> 
> Was tested on AD1815 and AD1816. The ALSA driver also support the
> AZT2002 ID for MPU401 but this doesn't as I was unable to test it.
> 
> Signed-off-by: Rene Herman <rene.herman@...il.com>

I'm not opposed to this in principle, but I don't understand
it well enough to really have an informed opinion.

IIRC, we give up some seldom-used functionality when running
the MPU401 without an IRQ.  Does the driver mention the fact
that there's something it can't do because we don't have an IRQ?
The user might like to know in case he needs that functionality
and wants to fiddle with other devices to free up IRQs.

I'm vaguely uncomfortable because this quirk isn't really working
around a hardware/firmware issue; it's stepping around the fact
that Linux doesn't know how to allocate IRQs between ISA and PCI.
Does anybody know how Windows handles this?  If Windows can do it
without user intervention, maybe we can too.

If we continue down the quirk path, would you mind using dev_info()
instead of plain printk()?

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ