All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Antony Pavlov <antonynpavlov@gmail.com>
Cc: barebox@lists.infradead.org
Subject: Re: [PATCH] ns16550: switch platform_data to drivers private data
Date: Fri, 5 Aug 2011 08:32:37 +0200	[thread overview]
Message-ID: <20110805063237.GA31404@pengutronix.de> (raw)
In-Reply-To: <CAA4bVAHfPQKx3w0ge_iy6daXpr7Yg2WHtGyBZc86o+vzzgOVMw@mail.gmail.com>

On Fri, Aug 05, 2011 at 12:58:32AM +0400, Antony Pavlov wrote:
> On 4 August 2011 23:37, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@jcrosoft.com> wrote:
> 
> > --- a/drivers/serial/serial_ns16550.c
> > +++ b/drivers/serial/serial_ns16550.c
> > @@ -48,6 +48,55 @@
> >
> >  /*********** Private Functions **********************************/
> >
> > +/*
> > + * We wrap our port structure around the generic console_device.
> > + */
> > +struct ns16550_uart_port {
> > +       void __iomem *base;
> > +       uint32_t shift;
> > +       uint32_t clock;
> > +       uint32_t (*read)(void __iomem *base, uint8_t off);
> > +       void (*write)(uint32_t val, void __iomem *base, uint8_t off);
> > +
> > +       struct console_device uart;
> 
>           nice trick :)))
> 
>           But why the name is 'uart', not 'cdev'?
> > +};
> 
> As a rule, structure declarations go to header files.

And as another rule, locally used struct (and also defines) go to the C
file.

> 
> > +
> > +static uint32_t ns16550_readb(void __iomem *base, uint8_t off)
> > +{
> > +       return readb(base + off);
> 
>  warning: pointer of type ‘void *’ used in arithmetic

Honestly, I can find nothing wrong in void * arithmetic. The
alternatives like casting to/from unsigned long are much worse.

> 
> 
> > -static unsigned int ns16550_calc_divisor(struct console_device *cdev,
> > +static unsigned int ns16550_calc_divisor(struct ns16550_uart_port *uart,
> >                                         unsigned int baudrate)
> >  {
> > -       struct NS16550_plat *plat = (struct NS16550_plat *)
> > -           cdev->dev->platform_data;
> > -       unsigned int clk = plat->clock;
> > -
> > -       return (clk / MODE_X_DIV / baudrate);
> > -
> > +       return (uart->clock / MODE_X_DIV / baudrate);
> >  }
> 
> inline?

The compiler can decide this for itself.

> 
> 
> > +       if (!plat->reg_read) {
> > +               switch (width) {
> > +               case IORESOURCE_MEM_8BIT:
> > +                       uart->read = ns16550_readb;
> > +                       break;
> > +               case IORESOURCE_MEM_16BIT:
> > +                       uart->read = ns16550_readw;
> > +                       break;
> > +               case IORESOURCE_MEM_32BIT:
> > +                       uart->read = ns16550_readl;
> > +                       break;
> > +               }
> > +       } else {
> > +               uart->read = plat->reg_read;
> > +       }
> 
> In this if the 'else' block is very short. 'if' block is much longer.
> Swapping of them will improve readability.

I don't care much. If anything, I would say that positive logic is
easier to read.

> 
> > +       if (!plat->reg_write) {
> > +               switch (width) {
> > +               case IORESOURCE_MEM_8BIT:
> > +                       uart->write = ns16550_writeb;
> > +                       break;
> > +               case IORESOURCE_MEM_16BIT:
> > +                       uart->write = ns16550_writew;
> > +                       break;
> > +               case IORESOURCE_MEM_32BIT:
> > +                       uart->write = ns16550_writel;
> > +                       break;
> > +               }
> > +       } else {
> > +               uart->write = plat->reg_write;
> > +       }
> 
> why do it twice?

:)

Sascha


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2011-08-05  6:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-03 16:36 [PATCH] serial_ns16550: drop the non working check Jean-Christophe PLAGNIOL-VILLARD
2011-08-04 19:37 ` [PATCH] ns16550: switch platform_data to drivers private data Jean-Christophe PLAGNIOL-VILLARD
2011-08-04 20:58   ` Antony Pavlov
2011-08-05  6:32     ` Sascha Hauer [this message]
2011-08-05  7:52       ` Antony Pavlov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110805063237.GA31404@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=antonynpavlov@gmail.com \
    --cc=barebox@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.