lkml.org 
[lkml]   [2016]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: [PATCH v3 1/4 RESEND] USB: serial: cp210x: New register access functions.
On Mon, Jan 18, 2016 at 07:59:48PM +0000, Konstantin Shkolnyy wrote:
> > -----Original Message-----
> > From: linux-usb-owner@vger.kernel.org [mailto:linux-usb-
> > owner@vger.kernel.org] On Behalf Of Johan Hovold
> > Sent: Monday, January 18, 2016 11:33
> > To: Konstantin Shkolnyy
> > Cc: johan@kernel.org; linux-usb@vger.kernel.org; linux-
> > kernel@vger.kernel.org
> > Subject: Re: [PATCH v3 1/4 RESEND] USB: serial: cp210x: New register access
> > functions.
> >
> > On Sat, Jan 16, 2016 at 01:46:24PM -0600, Konstantin Shkolnyy wrote:
> > > cp210x_get_config and cp210x_set_config are cumbersome to use. This
> > change
> > > introduces new register access functions to replace them. New functions
> > > are not yet called - the switch is done gradually in following changes.
> > >
> > > Signed-off-by: Konstantin Shkolnyy <konstantin.shkolnyy@gmail.com>
> > > ---
> > > change in v3: Presented new function addition as a separate patch #1,
> > > to simplify code review.
> >
> > Thanks for the v3.
> >
> > You should not be adding (static) functions before they have a caller as
> > this generates compiler warnings.
> >
> > Please define the new helper functions when converting their call
> > sites. You can split the 8, 16 and 32-bit helpers in separate patches and
> > possibly also separate read and write if that makes sense in order to
> > keep the diffs smaller.
>
> I did split 8, 16 and 32 into 3 patches in v2, then it seemed to me it
> would be easier to review if I also separated new functions.
> I can just use an amended v2 as v4.

Sounds good.

> I add reads and writes together to avoid type mismatches in the code
> that reads/writes the same variable,

Probably makes sense.

> > > drivers/usb/serial/cp210x.c | 166
> > ++++++++++++++++++++++++++++++++++++++++++++
> > > 1 file changed, 166 insertions(+)
> > >
> > > diff --git a/drivers/usb/serial/cp210x.c b/drivers/usb/serial/cp210x.c
> > > index fd67958..324eb7e 100644
> > > --- a/drivers/usb/serial/cp210x.c
> > > +++ b/drivers/usb/serial/cp210x.c
> > > @@ -323,6 +323,172 @@ struct cp210x_comm_status {
> > > #define PURGE_ALL 0x000f
> > >
> > > /*
> > > + * Reads a variable-sized block of CP210X_ registers, identified by req.
> > > + * Returns data into buf in native USB byte order.
> > > + */
> > > +static int cp210x_read_reg_block(struct usb_serial_port *port, u8 req,
> > > + void *buf, int bufsize)
> > > +{
> > > + struct usb_serial *serial = port->serial;
> > > + struct cp210x_port_private *port_priv =
> > usb_get_serial_port_data(port);
> > > + void *dmabuf;
> > > + int result;
> > > +
> > > + dmabuf = kmalloc(bufsize, GFP_KERNEL);
> > > + if (!dmabuf) {
> > > + /*
> > > + * FIXME Some callers don't bother to check for error,
> > > + * at least give them consistent junk until they are fixed
> > > + */
> > > + memset(buf, 0, bufsize);
> >
> > Instead of adding these FIXMEs and possibly risk introducing regressions
> > (these functions used to leave the previous values unchanged on errors),
>
> The current cp210x_get_config() does clear the caller's storage on an
> error. So my refactoring just preserves the old behavior.

Ah, the current code only fails to clear the callers storage on
allocation errors. Then I guess it's ok to fix up the call sites after.

> > how about adding the missing error handling first?
>
> It's easier to work with and see bugs in cleaned up code, that's why I
> do it in this order.
> I do intend to fix the error handling later.

Sounds good.

Thanks,
Johan

\
 
 \ /
  Last update: 2016-01-18 21:41    [W:0.035 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site