From: Emmanuel Grumbach <egrumbach@gmail.com> To: Brian Norris <briannorris@chromium.org> Cc: Luis Chamberlain <mcgrof@kernel.org>, Johannes Berg <johannes@sipsolutions.net>, linux-wireless <linux-wireless@vger.kernel.org>, aquini@redhat.com, peterz@infradead.org, Daniel Vetter <daniel.vetter@ffwll.ch>, mchehab+samsung@kernel.org, will@kernel.org, bhe@redhat.com, ath10k@lists.infradead.org, Takashi Iwai <tiwai@suse.de>, mingo@redhat.com, dyoung@redhat.com, pmladek@suse.com, Kees Cook <keescook@chromium.org>, Arnd Bergmann <arnd@arndb.de>, gpiccoli@canonical.com, Steven Rostedt <rostedt@goodmis.org>, cai@lca.pw, tglx@linutronix.de, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Kalle Valo <kvalo@codeaurora.org>, "<netdev@vger.kernel.org>" <netdev@vger.kernel.org>, schlad@suse.de, Linux Kernel <linux-kernel@vger.kernel.org>, jeyu@kernel.org, Andrew Morton <akpm@linux-foundation.org>, "David S. Miller" <davem@davemloft.net> Subject: Re: [PATCH v2 12/15] ath10k: use new module_firmware_crashed() Date: Fri, 22 May 2020 08:12:59 +0300 [thread overview] Message-ID: <CANUX_P2thzh9oB4KkrAoyT6H-E6MDFUNQ_p0e9QZtScgMuKm7Q@mail.gmail.com> (raw) In-Reply-To: <CA+ASDXPAVJwyThAXRQT0_ao4s1nDYOEQifxMc+JsEMa=cTEGJA@mail.gmail.com> > > On Tue, May 19, 2020 at 10:37 PM Emmanuel Grumbach <egrumbach@gmail.com> wrote: > > So I believe we already have this uevent, it is the devcoredump. All > > we need is to add the unique id. > > I think there are a few reasons that devcoredump doesn't satisfy what > either Luis or I want. > > 1) it can be disabled entirely [1], for good reasons (e.g., think of > non-${CHIP_VENDOR} folks, who can't (and don't want to) do anything > with the opaque dumps provided by closed-source firmware) Ok, if all you're interested into is the information that this event happen (as opposed to report a bug and providing the data), then I agree. True, not everybody want or can enable devcoredump. I am just a bit concerned that we may end up with two interface that notify the same event basically. The ideal maybe would be to be able to optionally reduce the content of the devoredump to nothing more that is already in the dmesg output. But then, it is not what it is meant to be: namely, a core dump.. > 2) not all drivers necessarily have a useful dump to provide when > there's a crash; look at the rest of Luis's series to see the kinds of > drivers-with-firmware that are crashing, some of which aren't dumping > anything Fair enouh. > 3) for those that do support devcoredump, it may be used for purposes > that are not "crashes" -- e.g., some provide debugfs or other knobs to > initiate dumps, for diagnostic or debugging purposes Not sure I really think we need to care about those cases, but you already have 2 good arguments :) > > Brian > > [1] devcd_disabled > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/devcoredump.c?h=v5.6#n22
WARNING: multiple messages have this Message-ID (diff)
From: Emmanuel Grumbach <egrumbach@gmail.com> To: Brian Norris <briannorris@chromium.org> Cc: aquini@redhat.com, peterz@infradead.org, Daniel Vetter <daniel.vetter@ffwll.ch>, mchehab+samsung@kernel.org, will@kernel.org, schlad@suse.de, bhe@redhat.com, ath10k@lists.infradead.org, Takashi Iwai <tiwai@suse.de>, mingo@redhat.com, dyoung@redhat.com, pmladek@suse.com, Kees Cook <keescook@chromium.org>, Arnd Bergmann <arnd@arndb.de>, gpiccoli@canonical.com, Steven Rostedt <rostedt@goodmis.org>, cai@lca.pw, tglx@linutronix.de, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Andrew Morton <akpm@linux-foundation.org>, Kalle Valo <kvalo@codeaurora.org>, "<netdev@vger.kernel.org>" <netdev@vger.kernel.org>, linux-wireless <linux-wireless@vger.kernel.org>, Linux Kernel <linux-kernel@vger.kernel.org>, Luis Chamberlain <mcgrof@kernel.org>, jeyu@kernel.org, Johannes Berg <johannes@sipsolutions.net>, "David S. Miller" <davem@davemloft.net> Subject: Re: [PATCH v2 12/15] ath10k: use new module_firmware_crashed() Date: Fri, 22 May 2020 08:12:59 +0300 [thread overview] Message-ID: <CANUX_P2thzh9oB4KkrAoyT6H-E6MDFUNQ_p0e9QZtScgMuKm7Q@mail.gmail.com> (raw) In-Reply-To: <CA+ASDXPAVJwyThAXRQT0_ao4s1nDYOEQifxMc+JsEMa=cTEGJA@mail.gmail.com> > > On Tue, May 19, 2020 at 10:37 PM Emmanuel Grumbach <egrumbach@gmail.com> wrote: > > So I believe we already have this uevent, it is the devcoredump. All > > we need is to add the unique id. > > I think there are a few reasons that devcoredump doesn't satisfy what > either Luis or I want. > > 1) it can be disabled entirely [1], for good reasons (e.g., think of > non-${CHIP_VENDOR} folks, who can't (and don't want to) do anything > with the opaque dumps provided by closed-source firmware) Ok, if all you're interested into is the information that this event happen (as opposed to report a bug and providing the data), then I agree. True, not everybody want or can enable devcoredump. I am just a bit concerned that we may end up with two interface that notify the same event basically. The ideal maybe would be to be able to optionally reduce the content of the devoredump to nothing more that is already in the dmesg output. But then, it is not what it is meant to be: namely, a core dump.. > 2) not all drivers necessarily have a useful dump to provide when > there's a crash; look at the rest of Luis's series to see the kinds of > drivers-with-firmware that are crashing, some of which aren't dumping > anything Fair enouh. > 3) for those that do support devcoredump, it may be used for purposes > that are not "crashes" -- e.g., some provide debugfs or other knobs to > initiate dumps, for diagnostic or debugging purposes Not sure I really think we need to care about those cases, but you already have 2 good arguments :) > > Brian > > [1] devcd_disabled > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/devcoredump.c?h=v5.6#n22 _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2020-05-22 5:13 UTC|newest] Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-15 21:28 [PATCH v2 00/15] net: taint when the device driver firmware crashes Luis Chamberlain 2020-05-15 21:28 ` [PATCH v2 01/15] taint: add module firmware crash taint support Luis Chamberlain 2020-05-16 4:03 ` Rafael Aquini 2020-05-19 16:42 ` Jessica Yu 2020-05-22 5:17 ` Luis Chamberlain 2020-05-15 21:28 ` [PATCH v2 02/15] ethernet/839: use new module_firmware_crashed() Luis Chamberlain 2020-05-16 4:04 ` Rafael Aquini 2020-05-15 21:28 ` [PATCH v2 03/15] bnx2x: " Luis Chamberlain 2020-05-16 4:05 ` Rafael Aquini 2020-05-15 21:28 ` [PATCH v2 04/15] bnxt: " Luis Chamberlain 2020-05-16 4:06 ` Rafael Aquini 2020-05-16 5:14 ` Vasundhara Volam 2020-05-15 21:28 ` [PATCH v2 05/15] bna: " Luis Chamberlain 2020-05-16 4:07 ` Rafael Aquini 2020-05-15 21:28 ` [PATCH v2 06/15] liquidio: " Luis Chamberlain 2020-05-16 4:07 ` Rafael Aquini 2020-05-15 21:28 ` [PATCH v2 07/15] cxgb4: " Luis Chamberlain 2020-05-16 4:09 ` Rafael Aquini 2020-05-15 21:28 ` [PATCH v2 08/15] ehea: " Luis Chamberlain 2020-05-16 4:09 ` Rafael Aquini 2020-05-15 21:28 ` [PATCH v2 09/15] qed: " Luis Chamberlain 2020-05-16 4:10 ` Rafael Aquini 2020-05-15 21:28 ` [PATCH v2 10/15] soc: qcom: ipa: " Luis Chamberlain 2020-05-16 4:10 ` Rafael Aquini 2020-05-19 22:34 ` Alex Elder 2020-05-22 5:28 ` Luis Chamberlain 2020-05-22 20:52 ` Alex Elder 2020-05-22 21:53 ` Luis Chamberlain 2020-05-15 21:28 ` [PATCH v2 11/15] wimax/i2400m: " Luis Chamberlain 2020-05-16 4:11 ` Rafael Aquini 2020-05-15 21:28 ` [PATCH v2 12/15] ath10k: " Luis Chamberlain 2020-05-15 21:28 ` Luis Chamberlain 2020-05-16 4:11 ` Rafael Aquini 2020-05-16 4:11 ` Rafael Aquini 2020-05-16 13:24 ` Johannes Berg 2020-05-16 13:24 ` Johannes Berg 2020-05-16 13:50 ` Johannes Berg 2020-05-16 13:50 ` Johannes Berg 2020-05-18 16:56 ` Luis Chamberlain 2020-05-18 16:56 ` Luis Chamberlain 2020-05-19 1:23 ` Brian Norris 2020-05-19 1:23 ` Brian Norris 2020-05-19 14:02 ` Luis Chamberlain 2020-05-19 14:02 ` Luis Chamberlain 2020-05-20 0:47 ` Brian Norris 2020-05-20 0:47 ` Brian Norris 2020-05-20 5:37 ` Emmanuel Grumbach 2020-05-20 5:37 ` Emmanuel Grumbach 2020-05-20 8:32 ` Andy Shevchenko 2020-05-20 8:32 ` Andy Shevchenko 2020-05-21 19:01 ` Brian Norris 2020-05-21 19:01 ` Brian Norris 2020-05-22 5:12 ` Emmanuel Grumbach [this message] 2020-05-22 5:12 ` Emmanuel Grumbach 2020-05-22 5:23 ` Luis Chamberlain 2020-05-22 5:23 ` Luis Chamberlain 2020-05-18 16:51 ` Luis Chamberlain 2020-05-18 16:51 ` Luis Chamberlain 2020-05-18 16:58 ` Ben Greear 2020-05-18 16:58 ` Ben Greear 2020-05-18 17:09 ` Luis Chamberlain 2020-05-18 17:09 ` Luis Chamberlain 2020-05-18 17:15 ` Ben Greear 2020-05-18 17:15 ` Ben Greear 2020-05-18 17:18 ` Luis Chamberlain 2020-05-18 17:18 ` Luis Chamberlain 2020-05-18 18:06 ` Steve deRosier 2020-05-18 18:06 ` Steve deRosier 2020-05-18 19:09 ` Luis Chamberlain 2020-05-18 19:09 ` Luis Chamberlain 2020-05-18 19:25 ` Johannes Berg 2020-05-18 19:25 ` Johannes Berg 2020-05-18 19:59 ` Luis Chamberlain 2020-05-18 19:59 ` Luis Chamberlain 2020-05-18 20:07 ` Johannes Berg 2020-05-18 20:07 ` Johannes Berg 2020-05-18 21:18 ` Luis Chamberlain 2020-05-18 21:18 ` Luis Chamberlain 2020-05-18 20:28 ` Jakub Kicinski 2020-05-18 20:28 ` Jakub Kicinski 2020-05-18 20:29 ` Johannes Berg 2020-05-18 20:29 ` Johannes Berg 2020-05-18 20:35 ` Jakub Kicinski 2020-05-18 20:35 ` Jakub Kicinski 2020-05-18 20:41 ` Johannes Berg 2020-05-18 20:41 ` Johannes Berg 2020-05-18 20:46 ` Jakub Kicinski 2020-05-18 20:46 ` Jakub Kicinski 2020-05-18 21:22 ` Luis Chamberlain 2020-05-18 21:22 ` Luis Chamberlain 2020-05-18 22:16 ` Jakub Kicinski 2020-05-18 22:16 ` Jakub Kicinski 2020-05-19 1:05 ` Luis Chamberlain 2020-05-19 1:05 ` Luis Chamberlain 2020-05-19 21:15 ` [RFC 1/2] devlink: add simple fw crash helpers Jakub Kicinski 2020-05-19 21:15 ` Jakub Kicinski 2020-05-22 5:20 ` Luis Chamberlain 2020-05-22 5:20 ` Luis Chamberlain 2020-05-22 17:17 ` Jakub Kicinski 2020-05-22 17:17 ` Jakub Kicinski 2020-05-22 20:46 ` Johannes Berg 2020-05-22 20:46 ` Johannes Berg 2020-05-22 21:51 ` Luis Chamberlain 2020-05-22 21:51 ` Luis Chamberlain 2020-05-22 23:23 ` Steve deRosier 2020-05-22 23:23 ` Steve deRosier 2020-05-22 23:44 ` Luis Chamberlain 2020-05-22 23:44 ` Luis Chamberlain 2020-05-25 9:07 ` Andy Shevchenko 2020-05-25 9:07 ` Andy Shevchenko 2020-05-25 17:08 ` Ben Greear 2020-05-25 17:08 ` Ben Greear 2020-05-25 20:57 ` Jakub Kicinski 2020-05-25 20:57 ` Jakub Kicinski 2020-07-30 13:56 ` Johannes Berg 2020-07-30 13:56 ` Johannes Berg 2020-05-22 21:49 ` Luis Chamberlain 2020-05-22 21:49 ` Luis Chamberlain 2020-05-19 21:15 ` [RFC 2/2] i2400m: use devlink health reporter Jakub Kicinski 2020-05-19 21:15 ` Jakub Kicinski 2020-05-15 21:28 ` [PATCH v2 13/15] ath6kl: use new module_firmware_crashed() Luis Chamberlain 2020-05-15 21:28 ` Luis Chamberlain 2020-05-16 4:12 ` Rafael Aquini 2020-05-16 4:12 ` Rafael Aquini 2020-05-15 21:28 ` [PATCH v2 14/15] brcm80211: " Luis Chamberlain 2020-05-16 4:13 ` Rafael Aquini 2020-05-15 21:28 ` [PATCH v2 15/15] mwl8k: " Luis Chamberlain 2020-05-16 4:13 ` Rafael Aquini
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=CANUX_P2thzh9oB4KkrAoyT6H-E6MDFUNQ_p0e9QZtScgMuKm7Q@mail.gmail.com \ --to=egrumbach@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=andriy.shevchenko@linux.intel.com \ --cc=aquini@redhat.com \ --cc=arnd@arndb.de \ --cc=ath10k@lists.infradead.org \ --cc=bhe@redhat.com \ --cc=briannorris@chromium.org \ --cc=cai@lca.pw \ --cc=daniel.vetter@ffwll.ch \ --cc=davem@davemloft.net \ --cc=dyoung@redhat.com \ --cc=gpiccoli@canonical.com \ --cc=jeyu@kernel.org \ --cc=johannes@sipsolutions.net \ --cc=keescook@chromium.org \ --cc=kvalo@codeaurora.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ --cc=mcgrof@kernel.org \ --cc=mchehab+samsung@kernel.org \ --cc=mingo@redhat.com \ --cc=netdev@vger.kernel.org \ --cc=peterz@infradead.org \ --cc=pmladek@suse.com \ --cc=rostedt@goodmis.org \ --cc=schlad@suse.de \ --cc=tglx@linutronix.de \ --cc=tiwai@suse.de \ --cc=will@kernel.org \ /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.