linux-kernel - Re: pci: add to global list before sysfs?

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:	Sat, 5 Apr 2008 11:57:27 +0200
From:	Pierre Ossman <drzeus-list@...eus.cx>
To:	Greg KH <gregkh@...e.de>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: pci: add to global list before sysfs?

On Fri, 4 Apr 2008 14:01:32 -0700
Greg KH <gregkh@...e.de> 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?  :)
> 

*gnn*

> 
> 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
cases.

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

Rgds
-- 
     -- Pierre Ossman

  Linux kernel, MMC maintainer        http://www.kernel.org
  PulseAudio, core developer          http://pulseaudio.org
  rdesktop, core developer          http://www.rdesktop.org
--
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/