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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 26 Nov 2008 17:52:05 -0800
From:	"Darrick J. Wong" <djwong@...ibm.com>
To:	Alex Chiang <achiang@...com>, Trent Piepho <xyzzy@...akeasy.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	linux-pci <linux-pci@...r.kernel.org>
Subject: Re: [PATCH] fakephp: Allocate PCI resources before adding the
	device

On Wed, Nov 26, 2008 at 03:55:35PM -0700, Alex Chiang wrote:
> > Maybe it's different on powerpc then?  My pseudo-hotplugable device is also
> > the only thing connected to the PCI-E host bus controller.  At boot the
> > controller is empty and so I think some code to enable its BARs gets
> > skipped.  But without the pci_enable_device(), I get this:
> > 
> > 01:00.0 Signal processing controller: Freescale Semiconductor Inc Aurora Nexus Trace Interface
> >         Flags: fast devsel, IRQ 255
> >         Memory at 40000000 (64-bit, prefetchable) [disabled] [size=4K]
                           Are you referring to this? ^^^^^^^^^^

Without seeing the raw dump of the PCI config space, it looks to me like
the memory space enable bit of the PCICMD register is unset.  Probably
the device driver should call pci_enable_device() at init time, though I
suppose you did say earlier that there is no driver.

> There is no way for fakephp to hot-add devices. The only use case
> is to hot-remove devices.

Actually, you can "hot-add" devices that were previously removed.  Just
rescan the removed device's bridge by running this command: echo 1 >
/sys/bus/pci/slots/fakeX/power.  Onlining the bridge (even if it's
already online) causes the PCI code to rescan the bridge for devices,
and that which you've removed comes back.

> Maybe you're talking about something else. Some more context for
> what you're trying to do, please?

Here is my bizarro case.  The MCH has a bit that controls whether or not
the ioat controller pays attention to accesses to PCI configuration
data.  If the bit is set, the ioat device shows up as 0:8.0.  If the bit
is unset, it looks like there's no device there.  So I set this bit and
use the fakephp driver to rescan the root PCI bridge; after doing that,
the ioat controller pops up.  Quite possibly this (ab)use of the fakephp
driver could be used to turn on other things from Linux that would
otherwise be disabled, but your machine might blow up too.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ