On Mon, Jan 18, 2016 at 07:59:48PM +0000, Konstantin Shkolnyy wrote: > > -----Original Message----- > > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb- > > owner@xxxxxxxxxxxxxxx] On Behalf Of Johan Hovold > > Sent: Monday, January 18, 2016 11:33 > > To: Konstantin Shkolnyy > > Cc: johan@xxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx; linux- > > kernel@xxxxxxxxxxxxxxx > > 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@xxxxxxxxx> > > > --- > > > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
