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 10:12:09 -0700
From:	Greg KH <gregkh@...e.de>
To:	Pierre Ossman <drzeus-list@...eus.cx>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: pci: add to global list before sysfs?

On Sat, Apr 05, 2008 at 06:55:01PM +0200, Pierre Ossman wrote:
> On Sat, 5 Apr 2008 08:53:23 -0700
> Greg KH <gregkh@...e.de> wrote:
> 
> > On Sat, Apr 05, 2008 at 11:57:27AM +0200, Pierre Ossman wrote:
> > > 
> > > 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.
> > 
> > Why not just create a thread in your driver, or timer, and sleep until
> > you see the other devices?  If after a certian time you never do, then
> > bail out.
> > 
> > That should work properly for you for both cases (startup and loading
> > later.)
> > 
> 
> I'm not sure how that could be done in a clean way. Right now I have
> the following:
> 
>                 sd_dev = NULL;
>                 while ((sd_dev = pci_get_device(PCI_VENDOR_ID_JMICRON,
>                         PCI_DEVICE_ID_JMICRON_JMB38X_SD, sd_dev)) != NULL) {
>                         if ((PCI_SLOT(chip->pdev->devfn) ==
>                                 PCI_SLOT(sd_dev->devfn)) &&
>                                 (chip->pdev->bus == sd_dev->bus))
>                                 break;
>                 }
> 
>                 if (sd_dev) {
>                         pci_dev_put(sd_dev);
>                         dev_info(&chip->pdev->dev, "Refusing to bind to "
>                                 "secondary interface.\n");
>                         return -ENODEV;
>                 }
> 
> If I do this threaded, I'd have to return success to the driver core
> and then act like a possum later.

Yes.

> Doable, but not very clean.

Hey, take it up with the hardware designers compensating for an
"unclean" operating system :)

> It could be solved if it was possible to sleep in probe functions, but
> from what I can tell that will stop the probing of subsequent devices.

Yes, you can sleep, but it will stop the probe of subsequent devices.  I
did implement multiple threads for pci probing, but it ended up not
saving any time and causing more problems than it was worth.

> Also, the timeout would introduce an inherent race. Which means either
> putting a high timeout to make the race insignificant, or a low timeout
> so users don't have to wait for their device to actually become usable.
> 
> Is it possible to write some routines that can walk the PCI device tree
> without having any pci_dev structures to hang on to? To solve my basic
> problem I just need to know how the tree looks like, not actually poke
> any of the other devices.

No, not in a sane way as all arches walk the pci device tree for
discovery in many different ways.

I don't think that a time-out would be a big deal, it shouldn't be very
long (a second or two).  Also note that all distros would not have this
problem as they do pci discovery first, and then start loading all of
the modules in the initramfs after the pci tree has been properly
scanned.  So the very large majority of users would not have a problem.

Or are you doing this on an embedded system?

thanks,

greg k-h
--
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/