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  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:	Sat, 5 Apr 2008 11:57:27 +0200
From:	Pierre Ossman <>
To:	Greg KH <>
Cc:	LKML <>
Subject: Re: pci: add to global list before sysfs?

On Fri, 4 Apr 2008 14:01:32 -0700
Greg KH <> wrote:

> What "global list"?  You mean the one that I just deleted with my
> patchset that is in -mm and going to be in 2.6.26?  :)


> How will changing the addition of the device to the list affect this
> behavior?  Do you want to walk the list in your driver's probe function,
> looking for the "subfunction" that is not yet added to the list?

Yes. Things work fine when the driver is loaded after the entire PCI
bus has been scanned, but not when new cards are hotplugged with the
driver already present. I'd like the behaviour to be the same in both

> > Is it possible to do this or will things break left and right if I
> > add them to the global list before I register them with the driver core?
> As I mention above, the "global list" is now gone, so it's going to be a
> bit harder to do this.  We now only keep one list of all PCI devices,
> and that is with the driver core mechanisms as the duplicate list was
> just sitting there doing nothing for the past 4 years.

Talk about bad timing...

> So is the problem that your driver need to bind to multiple pci devices
> at the same time in order to work properly?

More or less. Primarily it needs to know which other subfunctions are
there, but in one of the two cases it also needs to fiddle some PCI
config space registers.

> Or is this just really broken hardware?

It is. Deliberately broken in order to work with a certain other broken
operating system.

They have two interfaces for the same piece of hardware, and you need
to make sure you only use one of them or things go south very quickly.
To make things worse, you do not know which of the two will be
available for any given card. Hence the need to scan the bus.

In one of the cases we currently try to disable the secondary
interface, which is done by PCI config space modifications on
subfunction 0.

     -- Pierre Ossman

  Linux kernel, MMC maintainer
  PulseAudio, core developer
  rdesktop, core developer
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists