From: Coiby Xu <coiby.xu@gmail.com> To: Benjamin Poirier <benjamin.poirier@gmail.com> Cc: devel@driverdev.osuosl.org, Shung-Hsi Yu <shung-hsi.yu@suse.com>, Manish Chopra <manishc@marvell.com>, "supporter:QLOGIC QLGE 10Gb ETHERNET DRIVER" <GR-Linux-NIC-Dev@marvell.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, open list <linux-kernel@vger.kernel.org>, "open list:QLOGIC QLGE 10Gb ETHERNET DRIVER" <netdev@vger.kernel.org> Subject: Re: [PATCH v1 1/6] staging: qlge: Initialize devlink health dump framework for the dlge driver Date: Thu, 15 Oct 2020 11:37:32 +0800 [thread overview] Message-ID: <20201015033732.qaihehernm2jzoln@Rk> (raw) In-Reply-To: <20201013003704.GA41031@f3> On Tue, Oct 13, 2020 at 09:37:04AM +0900, Benjamin Poirier wrote: >On 2020-10-12 19:24 +0800, Coiby Xu wrote: >[...] >> > I think, but didn't check in depth, that in those drivers, the devlink >> > device is tied to the pci device and can exist independently of the >> > netdev, at least in principle. >> > >> You are right. Take drivers/net/ethernet/mellanox/mlxsw as an example, >> devlink reload would first first unregister_netdev and then >> register_netdev but struct devlink stays put. But I have yet to >> understand when unregister/register_netdev is needed. > >Maybe it can be useful to manually recover if the hardware or driver >gets in an erroneous state. I've used `modprobe -r qlge && modprobe >qlge` for the same in the past. Thank you for providing this user case! > >> Do we need to >> add "devlink reload" for qlge? > >Not for this patchset. That would be a new feature. To implement this feature, it seems I need to understand how qlge work under the hood. For example, what's the difference between qlge_soft_reset_mpi_risc and qlge_hard_reset_mpi_risc? Or should we use a brute-force way like do the tasks in qlge_remove and then re-do the tasks in qlge_probe? Is a hardware reference manual for qlge device? -- Best regards, Coiby
WARNING: multiple messages have this Message-ID (diff)
From: Coiby Xu <coiby.xu@gmail.com> To: Benjamin Poirier <benjamin.poirier@gmail.com> Cc: devel@driverdev.osuosl.org, "supporter:QLOGIC QLGE 10Gb ETHERNET DRIVER" <GR-Linux-NIC-Dev@marvell.com>, Manish Chopra <manishc@marvell.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Shung-Hsi Yu <shung-hsi.yu@suse.com>, open list <linux-kernel@vger.kernel.org>, "open list:QLOGIC QLGE 10Gb ETHERNET DRIVER" <netdev@vger.kernel.org> Subject: Re: [PATCH v1 1/6] staging: qlge: Initialize devlink health dump framework for the dlge driver Date: Thu, 15 Oct 2020 11:37:32 +0800 [thread overview] Message-ID: <20201015033732.qaihehernm2jzoln@Rk> (raw) In-Reply-To: <20201013003704.GA41031@f3> On Tue, Oct 13, 2020 at 09:37:04AM +0900, Benjamin Poirier wrote: >On 2020-10-12 19:24 +0800, Coiby Xu wrote: >[...] >> > I think, but didn't check in depth, that in those drivers, the devlink >> > device is tied to the pci device and can exist independently of the >> > netdev, at least in principle. >> > >> You are right. Take drivers/net/ethernet/mellanox/mlxsw as an example, >> devlink reload would first first unregister_netdev and then >> register_netdev but struct devlink stays put. But I have yet to >> understand when unregister/register_netdev is needed. > >Maybe it can be useful to manually recover if the hardware or driver >gets in an erroneous state. I've used `modprobe -r qlge && modprobe >qlge` for the same in the past. Thank you for providing this user case! > >> Do we need to >> add "devlink reload" for qlge? > >Not for this patchset. That would be a new feature. To implement this feature, it seems I need to understand how qlge work under the hood. For example, what's the difference between qlge_soft_reset_mpi_risc and qlge_hard_reset_mpi_risc? Or should we use a brute-force way like do the tasks in qlge_remove and then re-do the tasks in qlge_probe? Is a hardware reference manual for qlge device? -- Best regards, Coiby _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2020-10-15 3:37 UTC|newest] Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-08 11:58 [PATCH v1 0/6] staging: qlge: Re-writing the debugging features Coiby Xu 2020-10-08 11:58 ` [PATCH v1 1/6] staging: qlge: Initialize devlink health dump framework for the dlge driver Coiby Xu 2020-10-08 11:58 ` Coiby Xu 2020-10-08 12:22 ` Willem de Bruijn 2020-10-08 12:22 ` Willem de Bruijn 2020-10-08 12:54 ` Coiby Xu 2020-10-08 12:54 ` Coiby Xu 2020-10-12 8:08 ` Coiby Xu 2020-10-12 8:08 ` Coiby Xu 2020-10-08 13:31 ` Dan Carpenter 2020-10-08 13:31 ` Dan Carpenter 2020-10-09 0:12 ` Coiby Xu 2020-10-09 0:12 ` Coiby Xu 2020-10-08 17:45 ` kernel test robot 2020-10-08 17:45 ` kernel test robot 2020-10-10 7:35 ` Benjamin Poirier 2020-10-10 7:35 ` Benjamin Poirier 2020-10-10 10:24 ` Coiby Xu 2020-10-10 10:24 ` Coiby Xu 2020-10-10 13:48 ` Benjamin Poirier 2020-10-10 13:48 ` Benjamin Poirier 2020-10-12 11:24 ` Coiby Xu 2020-10-12 11:24 ` Coiby Xu 2020-10-13 0:37 ` Benjamin Poirier 2020-10-13 0:37 ` Benjamin Poirier 2020-10-15 3:37 ` Coiby Xu [this message] 2020-10-15 3:37 ` Coiby Xu 2020-10-15 11:06 ` Benjamin Poirier 2020-10-15 11:06 ` Benjamin Poirier 2020-10-16 23:08 ` Coiby Xu 2020-10-16 23:08 ` Coiby Xu 2020-10-08 11:58 ` [PATCH v1 2/6] staging: qlge: coredump via devlink health reporter Coiby Xu 2020-10-08 11:58 ` Coiby Xu 2020-10-08 13:39 ` Dan Carpenter 2020-10-08 13:39 ` Dan Carpenter 2020-10-09 0:14 ` Coiby Xu 2020-10-09 0:14 ` Coiby Xu 2020-10-10 7:48 ` Benjamin Poirier 2020-10-10 7:48 ` Benjamin Poirier 2020-10-10 10:02 ` Coiby Xu 2020-10-10 10:02 ` Coiby Xu 2020-10-10 13:22 ` Benjamin Poirier 2020-10-10 13:22 ` Benjamin Poirier 2020-10-12 11:51 ` Coiby Xu 2020-10-12 11:51 ` Coiby Xu 2020-10-13 1:18 ` Benjamin Poirier 2020-10-13 1:18 ` Benjamin Poirier 2020-10-08 11:58 ` [PATCH v1 3/6] staging: qlge: support force_coredump option for devlink health dump Coiby Xu 2020-10-08 11:58 ` Coiby Xu 2020-10-08 11:58 ` [PATCH v1 4/6] staging: qlge: remove mpi_core_to_log which sends coredump to the kernel ring buffer Coiby Xu 2020-10-08 11:58 ` Coiby Xu 2020-10-08 11:58 ` [PATCH v1 5/6] staging: qlge: clean up debugging code in the QL_ALL_DUMP ifdef land Coiby Xu 2020-10-08 11:58 ` Coiby Xu 2020-10-10 8:01 ` Benjamin Poirier 2020-10-10 8:01 ` Benjamin Poirier 2020-10-10 10:00 ` Coiby Xu 2020-10-10 10:00 ` Coiby Xu 2020-10-10 13:40 ` Benjamin Poirier 2020-10-10 13:40 ` Benjamin Poirier 2020-10-12 11:29 ` Coiby Xu 2020-10-12 11:29 ` Coiby Xu 2020-10-08 11:58 ` [PATCH v1 6/6] staging: qlge: add documentation for debugging qlge Coiby Xu 2020-10-08 11:58 ` Coiby Xu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20201015033732.qaihehernm2jzoln@Rk \ --to=coiby.xu@gmail.com \ --cc=GR-Linux-NIC-Dev@marvell.com \ --cc=benjamin.poirier@gmail.com \ --cc=devel@driverdev.osuosl.org \ --cc=gregkh@linuxfoundation.org \ --cc=linux-kernel@vger.kernel.org \ --cc=manishc@marvell.com \ --cc=netdev@vger.kernel.org \ --cc=shung-hsi.yu@suse.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.