[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <abcbaf1b-6b5f-bddc-eba1-e1e8e3ecf40e@metux.net>
Date: Tue, 8 Jun 2021 12:05:05 +0200
From: "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To: Amey Narkhede <ameynarkhede03@...il.com>,
Bjorn Helgaas <bhelgaas@...gle.com>
Cc: alex.williamson@...hat.com,
Raphael Norwitz <raphael.norwitz@...anix.com>,
linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
kw@...ux.com, Shanker Donthineni <sdonthineni@...dia.com>,
Sinan Kaya <okaya@...nel.org>, Len Brown <lenb@...nel.org>,
"Rafael J . Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH v7 0/8] Expose and manage PCI device reset
On 08.06.21 07:48, Amey Narkhede wrote:
Hi,
> PCI and PCIe devices may support a number of possible reset mechanisms
> for example Function Level Reset (FLR) provided via Advanced Feature or
> PCIe capabilities, Power Management reset, bus reset, or device specific reset.
> Currently the PCI subsystem creates a policy prioritizing these reset methods
> which provides neither visibility nor control to userspace.
Since I've got a current use case for that - could you perhaps tell more
about the whole pci device reset mechanisms ?
In my case I've got a board that wires reset lines to the soc's gpios.
Not sure how exactly to qualify this, but I guess it would count as a
bus wide reset.
Now the big question for me is how to implement that in a board specific
platform driver (which already does setup of gpios and other attached
devices), so we can reset the card in slot X in a generic way.
Any help highly appreciated.
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@...ux.net -- +49-151-27565287
Powered by blists - more mailing lists