Re: Adding options INSECURE to GENERIC

Michael <[email protected]>
Newsgroups gmane.os.netbsd.ports.sparc64
Organization The NetBSD Foundation
Message-ID <20200420082626.44e0af9e@blackbush>
Hello,

On Mon, 20 Apr 2020 07:05:58 +0200
Martin Husemann <[email protected]> wrote:

> On Sun, Apr 19, 2020 at 08:18:05PM -0400, Michael wrote:
> > That's for accessing IO space. I don't think any of the common PCI
> > graphics cards on sparc64 really need it, but the drivers may request
> > it because x86.
> > So there might be fallout. Trivial to fix fallout but still fallout.  
> 
> Sounds correct, here is an example:
> 
> radeonfb0 at pci4 dev 2 function 0: ATI Technologies Radeon 7000/VE QY (rev. 0x00)
> trying to read disabled BIOS...
> radeonfb0: No video BIOS, using default clocks
> radeonfb0: refclk = 27.000 MHz, refdiv = 12 minpll = 125000, maxpll = 400000
> no data for est. mode 640x480x67
> radeonfb0: 64 MB aperture at 0x08000000, 64 KB registers at 0x00100000
> 
> and IIRC mach64 is similar (with a mem type register window used instead
> of the PCish IO space).
> 
> So we could either #ifndef __sparc__ the IO access in xsrc, or leave it
> there, make it fail in the kernel, and have xsrc deal with failure. The
> latter would probably be easier to upstream.

I know radeon and mach64 do not need IO access, I'm about 99% sure
Permedia 2 doesn't need it either. That covers about 99.9% of all PCI
graphics card you'll find on sparc which we have drivers for ( as in,
not a wildcat )
Actually I'm fairly sure I added it only so we can use some Matrox
cards which the mga driver can cold boot.

have fun
Michael
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.