netdev - Re: [PATCH net-next 6/6] mlxsw: pci: Add support for new reset flow

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] [day] [month] [year] [list]

Message-ID: <20230413082603.2550dd6f@kernel.org>
Date:   Thu, 13 Apr 2023 08:26:03 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Ido Schimmel <idosch@...dia.com>
Cc:     Alex Williamson <alex.williamson@...hat.com>,
        Bjorn Helgaas <helgaas@...nel.org>,
        Petr Machata <petrm@...dia.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        Amit Cohen <amcohen@...dia.com>, mlxsw@...dia.com,
        linux-pci@...r.kernel.org, Lukas Wunner <lukas@...ner.de>
Subject: Re: [PATCH net-next 6/6] mlxsw: pci: Add support for new reset flow

On Thu, 13 Apr 2023 11:10:54 +0300 Ido Schimmel wrote:
> I believe we are discussing three different issues:
> 
> 1. Reset by PCI core when driver is bound to the device.
> 2. Reset by PCI core when driver is not bound to the device.
> 3. Reset by the driver itself during probe / devlink reload.
> 
> These are my notes on each:
> 
> 1. In this case, the reset_prepare() and reset_done() handlers of the
> driver are invoked by the PCI core before and after the PCI reset.
> Without them, if the used PCI reset method indeed reset the entire
> device, then the driver and the device would be out of sync. I have
> implemented these handlers for the driver:
> https://github.com/idosch/linux/commit/28bc0dc06c01559c19331578bbba9f2b0460ab5d.patch
> 
> 2. In this case, the handlers are not available and we only need to
> ensure that the used PCI reset method reset the device. The method can
> be a generic method such as "pm" or "bus" (which are available in my
> case) or a "device_specific" method that is implemented in
> drivers/pci/quirks.c by accessing the configuration space of the device.
> 
> I need to check if one of the generic methods works for this device and
> if not, check with the PCI team what we can do about it.
> 
> 3. In this case, the driver already issues a reset via its command
> interface during probe / devlink reload to ensure it is working with a
> device in a clean state. The patch we are discussing merely adds another
> reset method. Instead of starting the reset when the command is issued,
> the reset will start after toggling the link on the downstream port.
> 
> To summarize, I would like to proceed as follows:
> 
> 1. Submit the following patch that implements the PCI reset handlers for
> the device:
> https://github.com/idosch/linux/commit/28bc0dc06c01559c19331578bbba9f2b0460ab5d.patch

I'm probably confused but does this mean that PCI reset would impact
the datapath? From the commit message it sounded like the new reset
is harder than the previous one.