linux-kernel - Re: pccards are not detected

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-next>] [day] [month] [year] [list]

Date:	Thu, 3 Aug 2006 01:02:47 +0200
From:	Daniel Ritz <daniel.ritz-ml@...ssonline.ch>
To:	Pavel Roskin <proski@....org>
Cc:	Marcus Better <marcus@...ter.se>,
	linux-pcmcia <linux-pcmcia@...ts.infradead.org>,
	Greg KH <gregkh@...e.de>, Andrew Morton <akpm@...l.org>,
	"linux-kernel" <linux-kernel@...r.kernel.org>,
	Andi Kleen <ak@...e.de>
Subject: Re: pccards are not detected

On Wednesday 02 August 2006 22.44, Pavel Roskin wrote:
> On Wed, 2006-08-02 at 20:01 +0200, Daniel Ritz wrote:
> > On Wednesday 02 August 2006 19.42, Pavel Roskin wrote:
> > > It depends.  For some custom systems, BIOS may be a lifesaver.  Let's
> > > not change the whole logic of the PCI detection because of one broken
> > > BIOS.
> > 
> > errm. 2.6.16 automatically uses direct access. if first shows the PCI BIOS
> > line, then the direct access line in dmesg. pci_raw_ops is first set to
> > PCI_BIOS to be overwritten with direct access immediatley after that.
> > 
> > eg. from a 2.6.16.20 on a buggy box:
> > 	PCI: PCI BIOS revision 2.10 entry at 0xfb9a0, last bus=0
> > 	PCI: Using configuration type 1
> > cardbus would be bus 1-4. 2.6.17 breaks here...
> 
> If it's a laptop and CardBus is integrated, it's a BIOS bug.  BIOS
> should know about integrated hardware.  No excuses.
> 
> > > The standard solution for such problems is to add a "quirk" to
> > > drivers/pci/quirks.c or arch/i386/kernel/quirks.c
> 
> > no. it is a clear regression and the patch in fact just restores the old
> > behaviour with the exception that the ordering is more clear now than it
> > was before...
> 
> My intention was just to remind you about the quirks.
> 
> > 2.6.16: pci bios comes first, is overriden by direct access
> > 2.6.17: pci bios comes first. direct access is never used if pci bios probe "worked"
> > 2.6.17+patch: pci direct access probed first, if it fails pci bios is used.
> 
> The way you put it above, it sounds like a major change.  But I missed
> the actual patch.  Maybe it just reorders a few printk()s compared to
> 2.6.16, I don't know.
> 

ok, in other words:
2.6.16: end result: direct access; if direct doesn't work: pcibios
2.6.17: end result: pci bios (only direct if pcibios fails! )
2.6.17+patch: end result: direct access; if direct doesn't work: pcibios
=> net result is the same, but less code is executed, order is clear always.

> I still believe that adding quirk would be a good solution, in
> particular because it would work even if direct PCI probing is disabled.
> And then you can reorder the probing as much as you want.
> 

no, a quirk is bad for the simple reason that 2.6.16 used to work on systems
(laptops) where 2.6.17 fails for cardbus...there's no way you can wait on all
the reports and add quirks for them one-by-one. and distros are still using
kernel < 2.6.17...

btw. it's commit 92c05fc1a32e5ccef5e0e8201f32dcdab041524c
([PATCH] PCI: Give PCI config access initialization a defined ordering)
that broke things on those laptops. cc'ing Andi...

Andi, for reference:
http://marc.theaimsgroup.com/?l=linux-kernel&m=115454028402107

rgds
-daniel

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