From: Stephen Warren <swarren@wwwdotorg.org>
To: Dan Williams <dan.j.williams@intel.com>
Cc: gregkh@linuxfoundation.org,
Sudhakar Mamillapalli <sudhakar@fb.com>,
linux-kernel@vger.kernel.org, ArndBergmannarnd@arndb.de,
Grant Likely <grant.likely@secretlab.ca>,
linux-serial@vger.kernel.org, Colin Cross <ccross@android.com>,
Olof Johansson <olof@lixom.net>,
Nhan H Mai <nhan.h.mai@intel.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Alan Cox <alan@linux.intel.com>
Subject: Re: [PATCH v3 1/3] tegra, serial8250: add ->handle_break() uart_port op
Date: Tue, 10 Apr 2012 09:53:03 -0600 [thread overview]
Message-ID: <4F84575F.7090909@wwwdotorg.org> (raw)
In-Reply-To: <20120409194857.8004.86352.stgit@dwillia2-linux.jf.intel.com>
On 04/09/2012 01:48 PM, Dan Williams wrote:
> The "KT" serial port has another use case for a "received break" quirk,
> so before adding another special case to the 8250 core take this
> opportunity to push such quirks out of the core and into a uart_port op.
> diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
...
> +CONFIG_SERIAL_TEGRA=y
Instead of that,
> diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
...
> +# FIXME remove this option when Tegra completes conversion to open firmware
> +config SERIAL_TEGRA
> + bool "Tegra serial port support"
> + depends on SERIAL_OF_PLATFORM=y
> + help
> + If you have a machine based on NVIDIA Tegra you can enable its
> + onboard serial ports by enabling this option.
> +
Can we just make that default y if ARCH_TEGRA?
defconfig changes are apparently a little touchy.
Actually, why even introduce a new config variable; why not replace the
ifdefs in of_serial.[ch] with CONFIG_ARCH_TEGRA?
> diff --git a/arch/arm/mach-tegra/board-harmony.c b/arch/arm/mach-tegra/board-harmony.c
...
> static struct platform_device *harmony_devices[] __initdata = {
> +#if IS_ENABLED(CONFIG_SERIAL_TEGRA)
> &debug_uart,
> +#endif
Yes, it'd be nice to avoid those ifdefs. If you used ARCH_TEGRA instead
of a new config variable for this, the ifdefs in the board files would
be guaranteed to be true.
> diff --git a/arch/arm/mach-tegra/devices.h b/arch/arm/mach-tegra/devices.h
> index ec45567..6e5f852 100644
> --- a/arch/arm/mach-tegra/devices.h
> +++ b/arch/arm/mach-tegra/devices.h
> @@ -53,5 +53,4 @@ extern struct platform_device tegra_i2s_device1;
> extern struct platform_device tegra_i2s_device2;
> extern struct platform_device tegra_das_device;
> extern struct platform_device tegra_pcm_device;
> -
> #endif
That's left over from a previous patch version.
> @@ -84,6 +106,9 @@ static int __devinit of_platform_serial_setup(struct platform_device *ofdev,
> | UPF_FIXED_PORT | UPF_FIXED_TYPE;
> port->dev = &ofdev->dev;
>
> + if (type == PORT_TEGRA)
> + port->handle_break = tegra_serial_handle_break;
This is going to mean that everything in 8250.c:uart_config[] will move
into the exact same data structure in of_serial.c eventually, so I still
don't see the point of this exercise. But, I guess I won't argue against
it any more.
> diff --git a/include/linux/of_serial.h b/include/linux/of_serial.h
...
> + * FIXME remove this file when tegra finishes conversion to open firmware,
remove this *prototype* not *file*?
next prev parent reply other threads:[~2012-04-10 15:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-09 19:48 [PATCH v3 0/3] rework quirks for the "kt" serial port Dan Williams
2012-04-09 19:48 ` [PATCH v3 1/3] tegra, serial8250: add ->handle_break() uart_port op Dan Williams
2012-04-09 19:41 ` Williams, Dan J
2012-04-09 19:41 ` Williams, Dan J
2012-04-09 19:48 ` Stephen Warren
2012-04-09 20:48 ` Williams, Dan J
2012-04-09 20:48 ` Williams, Dan J
2012-04-10 10:51 ` Arnd Bergmann
2012-04-10 15:53 ` Stephen Warren [this message]
2012-04-10 17:36 ` Dan Williams
2012-04-10 18:17 ` Stephen Warren
2012-04-09 19:49 ` [PATCH v3 2/3] serial/8250_pci: Clear FIFOs for Intel ME Serial Over Lan device on BI Dan Williams
2012-04-09 19:49 ` [PATCH v3 3/3] serial/8250_pci: fix suspend/resume vs init/exit quirks Dan Williams
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=4F84575F.7090909@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=ArndBergmannarnd@arndb.de \
--cc=alan@linux.intel.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ccross@android.com \
--cc=dan.j.williams@intel.com \
--cc=grant.likely@secretlab.ca \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=nhan.h.mai@intel.com \
--cc=olof@lixom.net \
--cc=sudhakar@fb.com \
/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.