linux-kernel - Re: [PATCH v1 3/6] misc: eeprom: eeprom_93cx6: Replace printk(KERN_ERR ...) with pr

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

Message-ID: <20240916080410.464c2b5f@SWDEV2.connecttech.local>
Date: Mon, 16 Sep 2024 08:04:10 -0400
From: Parker Newman <parker@...est.io>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby
 <jirislaby@...nel.org>, Arnd Bergmann <arnd@...db.de>,
 linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org, Parker Newman
 <pnewman@...necttech.com>
Subject: Re: [PATCH v1 3/6] misc: eeprom: eeprom_93cx6: Replace
 printk(KERN_ERR ...) with pr_err()

On Mon, 16 Sep 2024 13:32:47 +0300
Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:

> On Mon, Sep 16, 2024 at 12:25:52PM +0200, Greg Kroah-Hartman wrote:
> > On Mon, Sep 16, 2024 at 12:55:05PM +0300, Andy Shevchenko wrote:
> > > On Sat, Sep 14, 2024 at 08:58:50PM +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Sep 13, 2024 at 10:55:40AM -0400, Parker Newman wrote:
>
> ...
>
> > > > > -			printk(KERN_ERR "%s: timeout\n", __func__);
> > > > > +			pr_err("%s: timeout\n", __func__);
> > > >
> > > > It's a device, please use dev_err().
> > >
> > > The problem is that this library doesn't know about this fact. I.e. it would
> > > need a new member just for this message. Instead, maybe drop the message as we
> > > anyway get a unique enough error code?
> >
> > Fair enough, although adding real device pointers would be good to do in
> > the future...
>
> Let's then do it when it will be the real need? Because I don't think this
> message is _so_ important. I believe one of the upper layers (whichever calls
> this function) should propagate the error code up to the user space. If it's
> not the case _that_ has to be fixed.
>
> TL;DR: Let's remove the message for now.
>

I can remove the message or leave it as is and drop this patch from the series.
One could make the argument that any error indication it is better than none
in this case.