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] [day] [month] [year] [list]
Date:	Sun, 22 Apr 2007 15:31:21 +0100
From:	Christoph Hellwig <hch@...radead.org>
To:	David Miller <davem@...emloft.net>
Cc:	hch@...radead.org, andrew.vasquez@...gic.com,
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	James.Bottomley@...elEye.com, ema@...ian.org
Subject: Re: Major qla2xxx regression on sparc64

On Wed, Apr 18, 2007 at 01:10:54PM -0700, David Miller wrote:
> From: Christoph Hellwig <hch@...radead.org>
> Date: Wed, 18 Apr 2007 18:13:46 +0100
> 
> > Note that I expect Sun put in the invalid ROM intentionally, as we have
> > similar cases with other cards that have totally messed up ROMs in
> > Sun-branded versions.  Personally I think that's an utterly bad decision
> > from Sun's side, but we'll have to live with this.
> 
> The way configuration paramters are provided on Sun systems is via
> openfirmware properties, this is how they do everything and that is
> why they never setup the NVRAMs on various chips.
> 
> This happens on PowerPC too.  One of many examples is determining the
> clock parameters of the ATI Radeon graphics card, it's provided as an
> openfirmware property not in some config area in the BIOS.
> 
> We can either be anti-social and _demand_ that these systems get their
> NVRAMs fixed, which in reality will never happen and is totally
> unreasonable, or we can say ok this is how we get the information we
> need on these platforms we'll look for it there.

Personally I think it is reasonable to expect manufacturer-provided
config space to always be in the same place, regardless what kind
of executable rom is there.  Then again most vendors seem to think
it's unresonable, and even if it wasn't we'll have to make sure our
drivers work with whatever it out there - so this discussion is
rather moot.
-
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