Re: [PATCH 3/7] USB: serial: ftdi_sio: Extract SIO divisor code to function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 7 Jul 2022 17:09:45 +0200
Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:

> On Thu, Jul 07, 2022 at 04:53:50PM +0200, Marek Behún wrote:
> > From: Pali Rohár <pali@xxxxxxxxxx>
> > 
> > As a code cleanup for future changes, extract divisor code for SIO chip
> > into new function ftdi_sio_baud_to_divisor().
> > 
> > No functional change.
> > 
> > Signed-off-by: Pali Rohár <pali@xxxxxxxxxx>
> > Tested-by: Marek Behún <kabel@xxxxxxxxxx>
> > ---
> >  drivers/usb/serial/ftdi_sio.c | 34 ++++++++++++++++++++--------------
> >  1 file changed, 20 insertions(+), 14 deletions(-)
> > 
> > diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
> > index 717b97f4e094..45a4eeb1fc70 100644
> > --- a/drivers/usb/serial/ftdi_sio.c
> > +++ b/drivers/usb/serial/ftdi_sio.c
> > @@ -1150,6 +1150,23 @@ static struct usb_serial_driver * const serial_drivers[] = {
> >   * ***************************************************************************
> >   */
> >  
> > +static u32 ftdi_sio_baud_to_divisor(int baud)
> > +{
> > +	switch (baud) {
> > +	case 300: return ftdi_sio_b300;
> > +	case 600: return ftdi_sio_b600;
> > +	case 1200: return ftdi_sio_b1200;
> > +	case 2400: return ftdi_sio_b2400;
> > +	case 4800: return ftdi_sio_b4800;
> > +	case 9600: return ftdi_sio_b9600;
> > +	case 19200: return ftdi_sio_b19200;
> > +	case 38400: return ftdi_sio_b38400;
> > +	case 57600: return ftdi_sio_b57600;
> > +	case 115200: return ftdi_sio_b115200;
> > +	default: return -1;  
> 
> Why not just return 9600 as a default here like the original code did?

It keeps at 9600 as original code.
Before:
  div_value = ftdi_sio_b9600;
  baud = 9600;

After:
  baud = 9600;
  div_value = ftdi_sio_baud_to_divisor(baud);

The new function that converts between the enum values and real values
now indicates when conversion is not possible.

> And returning a negative number for a u32 is not a good idea for the
> obvious reasons you found when you tried to test for it...

Would s32 be ok?




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux