On Mon, Sep 16, 2024 at 11:20:56AM -0400, Parker Newman wrote:
> 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.
Sure, fine with me.
--
With Best Regards,
Andy Shevchenko
