[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241205163334.GC2581@kernel.org>
Date: Thu, 5 Dec 2024 16:33:34 +0000
From: Simon Horman <horms@...nel.org>
To: Jijie Shao <shaojijie@...wei.com>
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
pabeni@...hat.com, andrew+netdev@...n.ch, shenjian15@...wei.com,
wangpeiyang1@...wei.com, liuyonglong@...wei.com,
chenhao418@...wei.com, sudongming1@...wei.com,
xujunsheng@...wei.com, shiyongbang@...wei.com, libaihan@...wei.com,
jonathan.cameron@...wei.com, shameerali.kolothum.thodi@...wei.com,
salil.mehta@...wei.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org, hkelam@...vell.com
Subject: Re: [PATCH V4 RESEND net-next 6/7] net: hibmcge: Add reset supported
in this module
On Tue, Dec 03, 2024 at 11:01:30PM +0800, Jijie Shao wrote:
> Sometimes, if the port doesn't work, we can try to fix it by resetting it.
>
> This patch supports reset triggered by ethtool or FLR of PCIe, For example:
> ethtool --reset eth0 dedicated
> echo 1 > /sys/bus/pci/devices/0000\:83\:00.1/reset
>
> We hope that the reset can be performed only when the port is down,
> and the port cannot be up during the reset.
> Therefore, the entire reset process is protected by the rtnl lock.
> But the ethtool command already holds the rtnl lock in the dev_ethtool().
> So, the reset operation is not directly performed in
> ethtool_ops.reset() function. Instead, the reset operation
> is triggered by a scheduled task.
>
> After the reset is complete, the hardware registers are restored
> to their default values. Therefore, some rebuild operations are
> required to rewrite the user configuration to the registers.
>
> Signed-off-by: Jijie Shao <shaojijie@...wei.com>
Reviewed-by: Simon Horman <horms@...nel.org>
Powered by blists - more mailing lists