linux-kernel - Re: Trying to reset a PCIe device and scratching my head...

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]

Message-ID: <20100928090655.158d1675@jbarnes-desktop>
Date:	Tue, 28 Sep 2010 09:06:55 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Clemens Ladisch <clemens@...isch.de>
Cc:	Jimmie Mayfield <mayfield@...kheads.org>,
	linux-kernel@...r.kernel.org
Subject: Re: Trying to reset a PCIe device and scratching my head...

On Tue, 28 Sep 2010 09:28:14 +0200
Clemens Ladisch <clemens@...isch.de> wrote:

> Jimmie Mayfield wrote:
> > Having the PCIe interface implemented inside FPGA 'A' makes upgrading
> > that particular FPGA rather troublesome.  In a perfect world, one would
> > be able to upgrade the FPGA without having to reboot the machine.  The
> > hardware guys have designed the card to reload that FPGA image upon a
> > slot reset...either fundamental or hot.
> > 
> > So I'd like to be able to send either a fundamental or hot reset to the
> > device but so far I've had no success.
> 
> The PCIe AER driver (drivers/pci/pcie/aer/) sends a hot reset when
> it has received a fatal error.  As far as I can tell, it just sets the
> PCI_BRIDGE_CTL_BUS_RESET bit of the upstream bridge; everything else
> is just infrastructure to handle error reporting and to notify the
> device driver about the reset.

Right, if your system supports this, it may be the easiest way to go.
But devices often have proprietary ways of resetting themselves too;
maybe you could change your device to reset if a specific bit in config
or MMIO space was flipped.  You'd likely need some sort of delay before
accessing the device again, but it should be bounded and fairly fixed,
so probably not a big deal for the driver to handle.

-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/