[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210608154455.ho44n6dnd52ogzxj@archlinux>
Date: Tue, 8 Jun 2021 21:14:55 +0530
From: Amey Narkhede <ameynarkhede03@...il.com>
To: "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>,
Alex Williamson <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 21/06/08 12:05PM, Enrico Weigelt, metux IT consult wrote:
> 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
>
In case of bus reset(pci_reset_secondary_bus()), it uses bridge control
register to assert reset on bus so I think it should out of the box but
not 100% sure about it.
Thanks,
Amey
Powered by blists - more mailing lists