From: Paul Mundt <lethal@linux-sh.org>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 1/3] serial: sh-sci: Add Device Tree probing
Date: Wed, 20 Feb 2013 11:55:57 +0000 [thread overview]
Message-ID: <20130220115555.GA3833@linux-sh.org> (raw)
In-Reply-To: <1361298586-30357-2-git-send-email-hechtb+renesas@gmail.com>
On Tue, Feb 19, 2013 at 12:29:44PM -0600, Bastian Hecht wrote:
> +Required properties:
> +- compatible : Should be "renesas,shmobile-sci-hwb-<x>", where <x> denotes a
> + hardware block version number of the following list - choose it according
> + to your SoC in use.
> + 1: sh7372, sh73a0, r8a7740
> + 2: r8a7779
This is introducing another layer of arbitrary versioning that pretty
much side-steps all of the existing abstraction that exists for dealing
with block versioning to begin with, so no, this isn't going to fly.
If you want to use version numbering like this, then it should be matched
to the regtype, which handles all possible variations already.
There is also nothing shmobile-specific about any of this, so that should
really be dropped from the string as well.
> index 6147756..4f3613d 100644
> --- a/drivers/tty/serial/sh-sci.c
> +++ b/drivers/tty/serial/sh-sci.c
> @@ -2353,6 +2353,106 @@ static int sci_remove(struct platform_device *dev)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +/*
> + * We provide setup data for different hardware block versionis. See
> + * Documentation/devicetree/bindings/tty/serial/renesas,sh-sci-serial.txt
> + * for further information.
> + */
> +static struct plat_sci_port sci_drv_data_hwb_1 = {
> + .flags = UPF_BOOT_AUTOCONF,
> + .scscr = SCSCR_RE | SCSCR_TE,
> + .scbrr_algo_id = SCBRR_ALGO_4,
> +};
> +
> +static struct plat_sci_port sci_drv_data_hwb_2 = {
> + .flags = UPF_BOOT_AUTOCONF | UPF_IOREMAP,
> + .scscr = SCSCR_RE | SCSCR_TE | SCSCR_CKE1,
> + .scbrr_algo_id = SCBRR_ALGO_2,
> +};
> +
While this no doubt works ok for some limited subset of hardware, this
has no place in the driver itself. If you want to use a DT binding, then
this information needs to be represented there somehow, as well.
The rest of it looks ok in any event.
next prev parent reply other threads:[~2013-02-20 11:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-19 17:29 [PATCH 1/3] serial: sh-sci: Add Device Tree probing Bastian Hecht
2013-02-20 11:55 ` Paul Mundt [this message]
2013-02-21 15:46 ` Bastian Hecht
2013-02-21 16:28 ` Paul Mundt
2013-02-21 18:11 ` Bastian Hecht
2013-02-22 12:51 ` Paul Mundt
2013-02-22 23:07 ` Magnus Damm
2013-02-25 18:02 ` Bastian Hecht
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=20130220115555.GA3833@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=linux-sh@vger.kernel.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.