On Mon, 16 Sep 2024 15:18:15 +0300
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> On Mon, Sep 16, 2024 at 08:04:10AM -0400, Parker Newman wrote:
> > On Mon, 16 Sep 2024 13:32:47 +0300
> > Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> 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.
>
> I think you can drop the message and make the patch to be last in the series,
> so it can be easily abandoned (in case that decision will be made) without
> throttling the rest. At the same time in the commit message explain that with
> move to read_poll_timeout() we drop the seems redundant message. I'm fine with
> that approach. But at the end of the day it's not that critical to the main
> purpose, i.e. cleaning up the Exar serial driver.
>
I don't think read_poll_timeout() will work directly because eeprom->register_read()
does not return a value. I could add a "is write complete" wrapper function
to work around that I guess. However, I think I will just drop this patch from
the series as fixing it properly will be a big change and like you said its not
critical to the main patch.
