From: Prarit Bhargava <prarit@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Joe Perches <joe@perches.com>
Subject: Re: [PATCH 1/3] Introduce FW_INFO* functions and messages
Date: Wed, 04 Dec 2013 06:51:41 -0500 [thread overview]
Message-ID: <529F174D.3030805@redhat.com> (raw)
In-Reply-To: <20131203132120.6a7ab2cd7cc99720712cbe6a@linux-foundation.org>
On 12/03/2013 04:21 PM, Andrew Morton wrote:
> On Mon, 2 Dec 2013 10:19:37 -0500 Prarit Bhargava <prarit@redhat.com> wrote:
> A slight simplification:
>
>> +static inline char *dump_hadware_arch_desc(void)
>> +{
>> + return NULL;
>> +}
>
> return "unavailable";
>
>> +void warn_slowpath_fmt_dev(const char *file, int line,
>> + struct device *dev, int level, const char *fmt, ...)
>> +{
>> + struct slowpath_args args;
>> + static char fw_str[16] = "\0";
>> +
>> + switch (level) {
>> + case 1:
>> + strcpy(fw_str, "[Firmware Info]");
>> + break;
>> + case 2:
>> + strcpy(fw_str, "[Firmware Warn]");
>> + break;
>> + case 3:
>> + strcpy(fw_str, "[Firmware Bug]");
>
> What's With The Crazy Capitalization In This Code? It's Illiterate!
Heh :) it's what the original FW_* strings were defined as. I was hoping it was
okay to change them but wasn't 100% sure if I should. I'll definitely take that
(and the suggestion above) into v2.
<snip>
>
> The general thrust of the patchset seems useful and important. I do
> agree with Joe's suggestion regarding the presentation, although it
> isn't a show-stopper.
In V2, I'll take Joe's suggestion into account. It isn't that difficult to
rework those chunks of the patch into a single patch.
>
> I do wonder if it all should be generalised a bit - it creates a bunch
> of infrastructure which is specific to system firmware issues, but
> what's so special about firmware? Why can't I use this infrastructure
> to log netdev errors or acpi errors or PM errors or...? But I didn't
> think about it much ;)
Well ... I was thinking about this. Some drivers do keep track of firmware
versions for their devices and I think there is probably a way to unify all that.
Also, I think after this initial change goes in I'm going to grep through the
PCI & ACPI code to see what FW_* changes need to be made there. AFAICT there
are many locations in those areas which should be FW_*.
I'll get a [v2] out in a little while. Thanks Joe & Andrew for looking.
P.
>
>
next prev parent reply other threads:[~2013-12-04 11:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-02 15:19 [PATCH 0/3] Add Firmware Info, Warn, and Bug messages Prarit Bhargava
2013-12-02 15:19 ` [PATCH 1/3] Introduce FW_INFO* functions and messages Prarit Bhargava
2013-12-03 21:21 ` Andrew Morton
2013-12-04 11:51 ` Prarit Bhargava [this message]
2013-12-04 17:20 ` Joe Perches
2013-12-04 18:22 ` Arnd Bergmann
2013-12-05 11:30 ` Matt Fleming
2013-12-05 15:55 ` Joe Perches
2013-12-06 12:30 ` Matt Fleming
2013-12-16 13:01 ` Prarit Bhargava
2013-12-16 16:31 ` Joe Perches
2013-12-02 15:19 ` [PATCH 2/3] Introduce FW_WARN* " Prarit Bhargava
2013-12-02 15:19 ` [PATCH 3/3] Introduce FW_BUG* " Prarit Bhargava
2013-12-02 17:34 ` [PATCH 0/3] Add Firmware Info, Warn, and Bug messages Joe Perches
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=529F174D.3030805@redhat.com \
--to=prarit@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.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: link
Be 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.