From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox <barebox@lists.infradead.org>
Subject: Re: problem in serial_ns16550.c
Date: Wed, 3 Aug 2011 18:38:08 +0200 [thread overview]
Message-ID: <20110803163808.GE24730@game.jcrosoft.org> (raw)
In-Reply-To: <20110803155208.GT31404@pengutronix.de>
On 17:52 Wed 03 Aug , Sascha Hauer wrote:
> On Wed, Aug 03, 2011 at 07:35:18PM +0400, Antony Pavlov wrote:
> > Hi!
> >
> > IMHO there is a problem in ns16550_probe() (see
> > drivers/serial/serial_ns16550.c:243).
> >
> > There is the construction:
> > ------
> > if (!(dev->resource[0].flags & IORESOURCE_MEM_TYPE_MASK) &&
> > ((plat->reg_read == NULL) || (plat->reg_write == NULL)))
> > return -EINVAL;
> > ------
> >
> > Imagine creation of typical serial port:
> > ------
> > static struct NS16550_plat plat = {
> > .clock = 1843200,
> > };
> >
> > ...
> >
> > add_ns16550_device(-1, UART_ADDR, 8, IORESOURCE_MEM_8BIT, &plat);
> > ------
> >
> > Here we have plat.reg_read == NULL, plat.reg_write == NULL.
> > Usage of add_ns16550_device will make
> > dev->resource[0].flags & IORESOURCE_MEM_TYPE_MASK == IORESOURCE_MEM_8BIT.
> >
> > But take into account this (see include/linux/ioport.h):
> > ------
> > #define IORESOURCE_MEM_TYPE_MASK (3<<3)
> > #define IORESOURCE_MEM_8BIT (0<<3)
> > ------
> >
> > So IORESOURCE_MEM_8BIT == 0 (sic!)
> >
> > A son tour, !(dev->resource[0].flags & IORESOURCE_MEM_TYPE_MASK) give
> > true, if flags select IORESOURCE_MEM_8BIT.
> >
> > As a result, if add_ns16550_device() take IORESOURCE_MEM_8BIT, and
> > plat->reg_read == NULL, plat->reg_write == NULL then ns16550_probe()
> > will return -EINVAL.
>
> Ok, then we have to check for the existence of plat->reg_read/write
> first. If the exist, we have to skip further IORESOURCE_MEM_xBIT checks.
> If they don't exist we do whatever IORESOURCE_MEM_xBIT indicates.
>
> That only leaves the problem that if a user registers a ns16550 driver
> without reg_read/write and does not care about resource types either
> the driver defaults to 8 bit mmio accesses, but I think we can live with
> that.
that was my idea at the beginning
Best Regards,
J.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2011-08-03 16:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-03 15:35 problem in serial_ns16550.c Antony Pavlov
2011-08-03 15:52 ` Sascha Hauer
2011-08-03 16:38 ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2011-08-03 16:35 ` Jean-Christophe PLAGNIOL-VILLARD
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=20110803163808.GE24730@game.jcrosoft.org \
--to=plagnioj@jcrosoft.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/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.