* Re: [PATCH] usb: cp210x: Added support for GPIO (CP2103/4/5)
From: Greg KH @ 2012-05-16 23:41 UTC (permalink / raw)
To: Alan Cox
Cc: Preston Fick, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
preston.fick-S6d6foEdJf7QT0dZR+AlfA,
linux-arm-kernel-xIg/pKzrS19vn6HldHNs0ANdhmdF6hFW@public.gmane.org
In-Reply-To: <20120516163347.1721406e-38n7/U1jhRXW96NNrWNlrekiAK3p4hvP@public.gmane.org>
On Wed, May 16, 2012 at 04:33:47PM +0100, Alan Cox wrote:
> So the patch looks like this, which seems nice and compact (UNTESTED)
>
> commit 4164f9b7074e682fe71dad3b57e78521ef9df492
> Author: Alan Cox <alan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Date: Wed May 16 15:13:02 2012 +0100
>
> tty: Add a gpio helper set
>
> Various tty devices have additional control lines which are sometimes used
> as GPIO pins and sometimes also tied with the serial port to implement
> protocols such as ISO7816.
>
> This code provides a kernel interface for querying the GPIO range of a tty,
> and to describe the mapping between GPIO pins and control lines. The latter
> will be needed for some upcoming line discipline support.
>
> [Proposal do not merge yet]
>
> Not-Signed-off-by: Alan Cox <alan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Wow, that looks really nice and tiny, if that's all that is needed in
the core, that's great.
> diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
> index a1b9a2f..60550e7 100644
> --- a/drivers/tty/tty_ioctl.c
> +++ b/drivers/tty/tty_ioctl.c
> @@ -1071,6 +1071,39 @@ int tty_mode_ioctl(struct tty_struct *tty, struct file *file,
> case TCSETXF:
> return set_termiox(real_tty, p, TERMIOS_FLUSH);
> #endif
> +#ifdef TCGGPIO
> + case TCGGPIO: {
> + struct tcgpio gpio;
> +
> + if (tty->gpio == NULL)
> + return -EOPNOTSUPP;
> + mutex_lock(&real_tty->termios_mutex);
> + memset(&gpio, 0, sizeof(gpio));
> + gpio.base = tty->gpio->base;
> + gpio.num = tty->gpio->num;
> + memcpy(gpio.map, tty->gpio->map, sizeof(gpio.map));
> + mutex_unlock(&real_tty->termios_mutex);
> + if (copy_to_user(p, &gpio, sizeof(gpio)))
> + return -EFAULT;
> + return 0;
> + }
> + case TCSGPIO:
> + {
> + struct tcgpio gpio;
> +
> + if (tty->gpio == NULL)
> + return -EOPNOTSUPP;
> + if (copy_from_user(&gpio, p, sizeof(gpio)))
> + return -EFAULT;
> + mutex_lock(&real_tty->termios_mutex);
> + memcpy(tty->gpio->map, gpio.map, sizeof(tty->gpio->map));
> + /* An ldisc can see this by watching the ioctl go through
> + but we may want to add a hook */
> + mutex_unlock(&real_tty->termios_mutex);
> + return 0;
So how would the lower tty driver get the ioctl to know to now set these
values to the hardware? I think we at least need a hook for that,
right? Or would that go through the ldisc?
> + }
> +
> +#endif
> case TIOCGSOFTCAR:
> copy_termios(real_tty, &kterm);
> ret = put_user((kterm.c_cflag & CLOCAL) ? 1 : 0,
> diff --git a/include/asm-generic/ioctls.h b/include/asm-generic/ioctls.h
> index 199975f..fee17d3 100644
> --- a/include/asm-generic/ioctls.h
> +++ b/include/asm-generic/ioctls.h
> @@ -74,6 +74,8 @@
> #define TCSETXW 0x5435
> #define TIOCSIG _IOW('T', 0x36, int) /* pty: generate signal */
> #define TIOCVHANGUP 0x5437
> +#define TCGGPIO _IOR('T', 0x38, struct tcgpio)
> +#define TCSGPIO _IOW('T', 0x39, struct tcgpio)
>
> #define FIONCLEX 0x5450
> #define FIOCLEX 0x5451
> diff --git a/include/asm-generic/termios.h b/include/asm-generic/termios.h
> index d0922ad..3adda38 100644
> --- a/include/asm-generic/termios.h
> +++ b/include/asm-generic/termios.h
> @@ -18,6 +18,18 @@ struct winsize {
> unsigned short ws_ypixel;
> };
>
> +
> +/* GPIO handling */
> +#define NR_TTY_GPIOMAP 8
> +struct tcgpio /* User copied version */
> +{
> + u32 base;
> + u16 num;
> + u16 reserved;
> + u32 map[NR_TTY_GPIOMAP];
> + u32 reserved2[6];
> +};
__u32 and friends instead?
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v2] serial: samsung: Fixed wrong comparison for baudclk_rate
From: Kukjin Kim @ 2012-05-17 6:55 UTC (permalink / raw)
To: 'Russell King - ARM Linux', 'Kyoungil Kim'
Cc: linux-arm-kernel, linux-serial, linux-samsung-soc,
'Jun-Ho Yoon', 'Alan Cox'
In-Reply-To: <20120515124538.GN10453@n2100.arm.linux.org.uk>
Russell King - ARM Linux wrote:
>
> On Tue, May 15, 2012 at 09:37:16PM +0900, Kyoungil Kim wrote:
> > port->baudclk_rate should be compared to the rate of port->baudclk,
> > because port->baudclk_rate was assigned as the rate of port->baudclk
> previously.
> > So to check that the current baudclk rate is same as previous rate,
> > the target of comparison sholud be the rate of port->baudclk.
> >
> > Signed-off-by: Jun-Ho, Yoon <junho78.yoon@samsung.com>
> > Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com>
> > ---
> > drivers/tty/serial/samsung.c | 4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> > index d8b0aee..6a6a86a 100644
> > --- a/drivers/tty/serial/samsung.c
> > +++ b/drivers/tty/serial/samsung.c
> > @@ -1014,10 +1014,10 @@ static int
> s3c24xx_serial_cpufreq_transition(struct notifier_block *nb,
> > * a disturbance in the clock-rate over the change.
> > */
> >
> > - if (IS_ERR(port->clk))
> > + if (IS_ERR(port->baudclk) || port->baudclk == NULL)
>
> Still no. Why are you wanting to detect a NULL baud clock?
>
> As I said, drivers have no business interpreting anything but IS_ERR(clk)
> as being an error. They should not make any other assumptions.
>
> Now that I look at this driver, it makes this mistake all over the place.
> This needs to be fixed. Something like the below should do it. Please
> check.
>
Russell, thanks for your kindly pointing out.
Kyoungil, could you please re-submit for this as per Russell's suggestion
(with Russell's patch)?
Thanks.
Best regards,
Kgene.
--
Kukjin Kim <kgene.kim@samsung.com>, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
> diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
> index d8b0aee..6a952b1 100644
> --- a/drivers/tty/serial/samsung.c
> +++ b/drivers/tty/serial/samsung.c
> @@ -529,7 +529,7 @@ static void s3c24xx_serial_pm(struct uart_port *port,
> unsigned int level,
>
> switch (level) {
> case 3:
> - if (!IS_ERR(ourport->baudclk) && ourport->baudclk != NULL)
> + if (!IS_ERR(ourport->baudclk))
> clk_disable(ourport->baudclk);
>
> clk_disable(ourport->clk);
> @@ -538,7 +538,7 @@ static void s3c24xx_serial_pm(struct uart_port *port,
> unsigned int level,
> case 0:
> clk_enable(ourport->clk);
>
> - if (!IS_ERR(ourport->baudclk) && ourport->baudclk != NULL)
> + if (!IS_ERR(ourport->baudclk))
> clk_enable(ourport->baudclk);
>
> break;
> @@ -713,9 +713,9 @@ static void s3c24xx_serial_set_termios(struct
> uart_port *port,
> if (ourport->baudclk != clk) {
> s3c24xx_serial_setsource(port, clk_sel);
>
> - if (ourport->baudclk != NULL && !IS_ERR(ourport->baudclk)) {
> + if (!IS_ERR(ourport->baudclk)) {
> clk_disable(ourport->baudclk);
> - ourport->baudclk = NULL;
> + ourport->baudclk = ERR_PTR(-EINVAL);
> }
>
> clk_enable(clk);
> @@ -1160,6 +1160,9 @@ static ssize_t s3c24xx_serial_show_clksrc(struct
> device *dev,
> struct uart_port *port = s3c24xx_dev_to_port(dev);
> struct s3c24xx_uart_port *ourport = to_ourport(port);
>
> + if (IS_ERR(ourport->baudclk))
> + return -EINVAL;
> +
> return snprintf(buf, PAGE_SIZE, "* %s\n", ourport->baudclk->name);
> }
>
> @@ -1200,6 +1203,7 @@ static int s3c24xx_serial_probe(struct
> platform_device *pdev)
> return -ENODEV;
> }
>
> + ourport->baudclk = ERR_PTR(-EINVAL);
> ourport->info = ourport->drv_data->info;
> ourport->cfg = (pdev->dev.platform_data) ?
> (struct s3c2410_uartcfg *)pdev->dev.platform_data :
^ permalink raw reply
* [PATCH 3/5] serial: delete the MCA specific 8250 support.
From: Paul Gortmaker @ 2012-05-17 16:40 UTC (permalink / raw)
To: linux-kernel
Cc: JBottomley, Paul Gortmaker, Alan Cox, Greg Kroah-Hartman,
linux-serial
In-Reply-To: <1337272841-25931-1-git-send-email-paul.gortmaker@windriver.com>
The support for CONFIG_MCA is being removed, since the 20
year old hardware simply isn't capable of meeting today's
software demands on CPU and memory resources.
This commit removes the MCA specific 8250 UART code.
Cc: Alan Cox <alan@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-serial@vger.kernel.org
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
Documentation/serial/stallion.txt | 22 ++++++------
drivers/tty/serial/8250/8250_mca.c | 61 ------------------------------------
drivers/tty/serial/8250/Kconfig | 9 -----
drivers/tty/serial/8250/Makefile | 1 -
include/linux/serial.h | 2 -
include/linux/serial_8250.h | 1 -
6 files changed, 11 insertions(+), 85 deletions(-)
delete mode 100644 drivers/tty/serial/8250/8250_mca.c
diff --git a/Documentation/serial/stallion.txt b/Documentation/serial/stallion.txt
index 5509091..4d798c0 100644
--- a/Documentation/serial/stallion.txt
+++ b/Documentation/serial/stallion.txt
@@ -20,10 +20,10 @@ There are two drivers that work with the different families of Stallion
multiport serial boards. One is for the Stallion smart boards - that is
EasyIO, EasyConnection 8/32 and EasyConnection 8/64-PCI, the other for
the true Stallion intelligent multiport boards - EasyConnection 8/64
-(ISA, EISA, MCA), EasyConnection/RA-PCI, ONboard and Brumby.
+(ISA, EISA), EasyConnection/RA-PCI, ONboard and Brumby.
If you are using any of the Stallion intelligent multiport boards (Brumby,
-ONboard, EasyConnection 8/64 (ISA, EISA, MCA), EasyConnection/RA-PCI) with
+ONboard, EasyConnection 8/64 (ISA, EISA), EasyConnection/RA-PCI) with
Linux you will need to get the driver utility package. This contains a
firmware loader and the firmware images necessary to make the devices operate.
@@ -40,7 +40,7 @@ If you are using the EasyIO, EasyConnection 8/32 or EasyConnection 8/64-PCI
boards then you don't need this package, although it does have a serial stats
display program.
-If you require DIP switch settings, EISA or MCA configuration files, or any
+If you require DIP switch settings, or EISA configuration files, or any
other information related to Stallion boards then have a look at Stallion's
web pages at http://www.stallion.com.
@@ -51,13 +51,13 @@ web pages at http://www.stallion.com.
The drivers can be used as loadable modules or compiled into the kernel.
You can choose which when doing a "config" on the kernel.
-All ISA, EISA and MCA boards that you want to use need to be configured into
+All ISA, and EISA boards that you want to use need to be configured into
the driver(s). All PCI boards will be automatically detected when you load
the driver - so they do not need to be entered into the driver(s)
configuration structure. Note that kernel PCI support is required to use PCI
boards.
-There are two methods of configuring ISA, EISA and MCA boards into the drivers.
+There are two methods of configuring ISA and EISA boards into the drivers.
If using the driver as a loadable module then the simplest method is to pass
the driver configuration as module arguments. The other method is to modify
the driver source to add configuration lines for each board in use.
@@ -71,12 +71,12 @@ That makes things pretty simple to get going.
2.1 MODULE DRIVER CONFIGURATION:
The simplest configuration for modules is to use the module load arguments
-to configure any ISA, EISA or MCA boards. PCI boards are automatically
+to configure any ISA or EISA boards. PCI boards are automatically
detected, so do not need any additional configuration at all.
-If using EasyIO, EasyConnection 8/32 ISA or MCA, or EasyConnection 8/63-PCI
+If using EasyIO, EasyConnection 8/32 ISA, or EasyConnection 8/63-PCI
boards then use the "stallion" driver module, Otherwise if you are using
-an EasyConnection 8/64 ISA, EISA or MCA, EasyConnection/RA-PCI, ONboard,
+an EasyConnection 8/64 ISA or EISA, EasyConnection/RA-PCI, ONboard,
Brumby or original Stallion board then use the "istallion" driver module.
Typically to load up the smart board driver use:
@@ -146,7 +146,7 @@ on each system boot. Typically configuration files are put in the
2.2 STATIC DRIVER CONFIGURATION:
For static driver configuration you need to modify the driver source code.
-Entering ISA, EISA and MCA boards into the driver(s) configuration structure
+Entering ISA and EISA boards into the driver(s) configuration structure
involves editing the driver(s) source file. It's pretty easy if you follow
the instructions below. Both drivers can support up to 4 boards. The smart
card driver (the stallion.c driver) supports any combination of EasyIO and
@@ -157,7 +157,7 @@ supports any combination of ONboards, Brumbys, Stallions and EasyConnection
To set up the driver(s) for the boards that you want to use you need to
edit the appropriate driver file and add configuration entries.
-If using EasyIO or EasyConnection 8/32 ISA or MCA boards,
+If using EasyIO or EasyConnection 8/32 ISA boards,
In drivers/char/stallion.c:
- find the definition of the stl_brdconf array (of structures)
near the top of the file
@@ -243,7 +243,7 @@ change it on the board.
On EasyIO and EasyConnection 8/32 boards the IRQ is software programmable, so
if there is a conflict you may need to change the IRQ used for a board. There
are no interrupts to worry about for ONboard, Brumby or EasyConnection 8/64
-(ISA, EISA and MCA) boards. The memory region on EasyConnection 8/64 and
+(ISA and EISA) boards. The memory region on EasyConnection 8/64 and
ONboard boards is software programmable, but not on the Brumby boards.
diff --git a/drivers/tty/serial/8250/8250_mca.c b/drivers/tty/serial/8250/8250_mca.c
deleted file mode 100644
index d20abf0..0000000
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index 591f801..175c204 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -241,15 +241,6 @@ config SERIAL_8250_RSA
help
::: To be written :::
-config SERIAL_8250_MCA
- tristate "Support 8250-type ports on MCA buses"
- depends on SERIAL_8250 != n && MCA
- help
- Say Y here if you have a MCA serial ports.
-
- To compile this driver as a module, choose M here: the module
- will be called 8250_mca.
-
config SERIAL_8250_ACORN
tristate "Acorn expansion card serial port support"
depends on ARCH_ACORN && SERIAL_8250
diff --git a/drivers/tty/serial/8250/Makefile b/drivers/tty/serial/8250/Makefile
index 867bba7..464320f 100644
--- a/drivers/tty/serial/8250/Makefile
+++ b/drivers/tty/serial/8250/Makefile
@@ -15,6 +15,5 @@ obj-$(CONFIG_SERIAL_8250_ACCENT) += 8250_accent.o
obj-$(CONFIG_SERIAL_8250_BOCA) += 8250_boca.o
obj-$(CONFIG_SERIAL_8250_EXAR_ST16C554) += 8250_exar_st16c554.o
obj-$(CONFIG_SERIAL_8250_HUB6) += 8250_hub6.o
-obj-$(CONFIG_SERIAL_8250_MCA) += 8250_mca.o
obj-$(CONFIG_SERIAL_8250_FSL) += 8250_fsl.o
obj-$(CONFIG_SERIAL_8250_DW) += 8250_dw.o
diff --git a/include/linux/serial.h b/include/linux/serial.h
index 441980e..90e9f98 100644
--- a/include/linux/serial.h
+++ b/include/linux/serial.h
@@ -130,7 +130,6 @@ struct serial_uart_config {
#define ASYNCB_CHECK_CD 25 /* i.e., CLOCAL */
#define ASYNCB_SHARE_IRQ 24 /* for multifunction cards, no longer used */
#define ASYNCB_CONS_FLOW 23 /* flow control for console */
-#define ASYNCB_BOOT_ONLYMCA 22 /* Probe only if MCA bus */
#define ASYNCB_FIRST_KERNEL 22
#define ASYNC_HUP_NOTIFY (1U << ASYNCB_HUP_NOTIFY)
@@ -166,7 +165,6 @@ struct serial_uart_config {
#define ASYNC_CHECK_CD (1U << ASYNCB_CHECK_CD)
#define ASYNC_SHARE_IRQ (1U << ASYNCB_SHARE_IRQ)
#define ASYNC_CONS_FLOW (1U << ASYNCB_CONS_FLOW)
-#define ASYNC_BOOT_ONLYMCA (1U << ASYNCB_BOOT_ONLYMCA)
#define ASYNC_INTERNAL_FLAGS (~((1U << ASYNCB_FIRST_KERNEL) - 1))
/*
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 8f012f8..6c5047d 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -54,7 +54,6 @@ enum {
PLAT8250_DEV_BOCA,
PLAT8250_DEV_EXAR_ST16C554,
PLAT8250_DEV_HUB6,
- PLAT8250_DEV_MCA,
PLAT8250_DEV_AU1X00,
PLAT8250_DEV_SM501,
};
--
1.7.9.1
^ permalink raw reply related
* Re: [PATCH 3/5] serial: delete the MCA specific 8250 support.
From: Greg Kroah-Hartman @ 2012-05-17 16:46 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linux-kernel, JBottomley, Alan Cox, linux-serial
In-Reply-To: <1337272841-25931-4-git-send-email-paul.gortmaker@windriver.com>
On Thu, May 17, 2012 at 12:40:39PM -0400, Paul Gortmaker wrote:
> The support for CONFIG_MCA is being removed, since the 20
> year old hardware simply isn't capable of meeting today's
> software demands on CPU and memory resources.
>
> This commit removes the MCA specific 8250 UART code.
>
> Cc: Alan Cox <alan@linux.intel.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-serial@vger.kernel.org
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Do you want me to take this through my tty tree, or are you sending this
through some other means?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/5] serial: delete the MCA specific 8250 support.
From: Paul Gortmaker @ 2012-05-17 16:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, JBottomley, Linus Torvalds, Alan Cox, linux-serial,
David Miller
In-Reply-To: <20120517164610.GA22327@kroah.com>
[Re: [PATCH 3/5] serial: delete the MCA specific 8250 support.] On 17/05/2012 (Thu 09:46) Greg Kroah-Hartman wrote:
> On Thu, May 17, 2012 at 12:40:39PM -0400, Paul Gortmaker wrote:
> > The support for CONFIG_MCA is being removed, since the 20
> > year old hardware simply isn't capable of meeting today's
> > software demands on CPU and memory resources.
> >
> > This commit removes the MCA specific 8250 UART code.
> >
> > Cc: Alan Cox <alan@linux.intel.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: linux-serial@vger.kernel.org
> > Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Do you want me to take this through my tty tree, or are you sending this
> through some other means?
Since it depends on Linus pulling net-next 1st (otherwise we'll
get allyesconfig fails in tokenring), it probably makes sense for
me to just sit on all of it and then feed it to Linus after I've
seen him pull Dave's net-next with the token ring removal.
Unless someone has a better plan?
Thanks,
Paul.
--
>
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH 3/5] serial: delete the MCA specific 8250 support.
From: David Miller @ 2012-05-17 20:16 UTC (permalink / raw)
To: paul.gortmaker
Cc: gregkh, linux-kernel, JBottomley, torvalds, alan, linux-serial
In-Reply-To: <20120517165905.GA27789@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 17 May 2012 12:59:06 -0400
> Since it depends on Linus pulling net-next 1st (otherwise we'll
> get allyesconfig fails in tokenring), it probably makes sense for
> me to just sit on all of it and then feed it to Linus after I've
> seen him pull Dave's net-next with the token ring removal.
>
> Unless someone has a better plan?
Sounds good.
Meanwhile, Paul, if you respin patch #2 I can toss that directly into
my net-next tree since that's all networking stuff anyways.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/5] serial: delete the MCA specific 8250 support.
From: Paul Gortmaker @ 2012-05-17 21:02 UTC (permalink / raw)
To: David Miller
Cc: gregkh, linux-kernel, JBottomley, torvalds, alan, linux-serial
In-Reply-To: <20120517.161656.1149344441984193661.davem@davemloft.net>
[Re: [PATCH 3/5] serial: delete the MCA specific 8250 support.] On 17/05/2012 (Thu 16:16) David Miller wrote:
> From: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date: Thu, 17 May 2012 12:59:06 -0400
>
> > Since it depends on Linus pulling net-next 1st (otherwise we'll
> > get allyesconfig fails in tokenring), it probably makes sense for
> > me to just sit on all of it and then feed it to Linus after I've
> > seen him pull Dave's net-next with the token ring removal.
> >
> > Unless someone has a better plan?
>
> Sounds good.
>
> Meanwhile, Paul, if you respin patch #2 I can toss that directly into
> my net-next tree since that's all networking stuff anyways.
OK. I'm just double checking with an allyesconfig on the respin of
the #2 in isolation and then I'll follow up in the #2 thread with it.
Thanks,
Paul.
>
> Thanks.
^ permalink raw reply
* Re: kmscon: replacing CONFIG_VT
From: David Herrmann @ 2012-05-19 8:48 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-serial, Greg Kroah-Hartman
In-Reply-To: <20120516171421.5fca49f3@pyramind.ukuu.org.uk>
Hi Alan
On Wed, May 16, 2012 at 6:14 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> That's just some of my ideas on this topic. Maybe you can give me some
>> hints whether it actually makes sense ;)
>
> For a lot of hardware it may not matter. If it goes bang you boot with a
> debugging kernel (one containing a vt driver)
>
> If your user space goes castors up early then you are going to need input
> facilities anyway (consider the fedora rescue mode in dracut for example)
So you are basically saying that such an drmcon driver isn't needed,
anyway? If we keep backwards compatibility to CONFIG_VT, everyone who
wants a boot-log on the display just needs to enable CONFIG_VT. Sounds
reasonable.
> As far as compatibility goes we have the ttyprintk driver which just
> provides a fake tty which types nothing and whose output goes to the
> console.
I haven't found any applications that fail without /dev/tty, however,
thanks for the hint.
> Alan
Thanks for the answers. So I can concentrate on the user-space parts
and maybe later implement some drmcon'ish driver.
Regards
David
^ permalink raw reply
* Re: kmscon: replacing CONFIG_VT
From: Alan Cox @ 2012-05-19 11:55 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-serial, Greg Kroah-Hartman
In-Reply-To: <CANq1E4SwyzLW61v-nrYu2gBvqbuzUNqTkK2cZzbv1ZZNBmWBBg@mail.gmail.com>
> So you are basically saying that such an drmcon driver isn't needed,
> anyway? If we keep backwards compatibility to CONFIG_VT, everyone who
> wants a boot-log on the display just needs to enable CONFIG_VT. Sounds
> reasonable.
For a lot of applications I think this will be true.
> > As far as compatibility goes we have the ttyprintk driver which just
> > provides a fake tty which types nothing and whose output goes to the
> > console.
>
> I haven't found any applications that fail without /dev/tty, however,
> thanks for the hint.
There are quite a few, but ttyprintk means that if you've got a printk
console you've got a console "tty" at least for output. End of problem
therefore.
> Thanks for the answers. So I can concentrate on the user-space parts
> and maybe later implement some drmcon'ish driver.
I think so. And bear in mind a "drmcon'ish driver" for rescue could be a
shared library you can link the boot environment with, one that makes
minimal use of drm and /dev/input to implement a very basic vt.
Alan
^ permalink raw reply
* Re: kmscon: replacing CONFIG_VT
From: Alan Cox @ 2012-05-19 12:00 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-serial, Greg Kroah-Hartman
In-Reply-To: <CANq1E4SwyzLW61v-nrYu2gBvqbuzUNqTkK2cZzbv1ZZNBmWBBg@mail.gmail.com>
As a PS:
"tty is a library" has been done in experimental exokernel work in the
past.
^ permalink raw reply
* [PATCH 1/2] serial: samsung: Remove NULL checking for baud clock
From: Kyoungil Kim @ 2012-05-20 8:45 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc, linux-serial
Cc: 'Kukjin Kim', 'Alan Cox', 'Kyoungil Kim'
Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com>
---
drivers/tty/serial/samsung.c | 21 ++++++++++++---------
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index d8b0aee..5668538 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -529,7 +529,7 @@ static void s3c24xx_serial_pm(struct uart_port *port, unsigned int level,
switch (level) {
case 3:
- if (!IS_ERR(ourport->baudclk) && ourport->baudclk != NULL)
+ if (!IS_ERR(ourport->baudclk))
clk_disable(ourport->baudclk);
clk_disable(ourport->clk);
@@ -538,7 +538,7 @@ static void s3c24xx_serial_pm(struct uart_port *port, unsigned int level,
case 0:
clk_enable(ourport->clk);
- if (!IS_ERR(ourport->baudclk) && ourport->baudclk != NULL)
+ if (!IS_ERR(ourport->baudclk))
clk_enable(ourport->baudclk);
break;
@@ -604,7 +604,6 @@ static unsigned int s3c24xx_serial_getclk(struct s3c24xx_uart_port *ourport,
char clkname[MAX_CLK_NAME_LENGTH];
int calc_deviation, deviation = (1 << 30) - 1;
- *best_clk = NULL;
clk_sel = (ourport->cfg->clk_sel) ? ourport->cfg->clk_sel :
ourport->info->def_clk_sel;
for (cnt = 0; cnt < info->num_clks; cnt++) {
@@ -613,7 +612,7 @@ static unsigned int s3c24xx_serial_getclk(struct s3c24xx_uart_port *ourport,
sprintf(clkname, "clk_uart_baud%d", cnt);
clk = clk_get(ourport->port.dev, clkname);
- if (IS_ERR_OR_NULL(clk))
+ if (IS_ERR(clk))
continue;
rate = clk_get_rate(clk);
@@ -684,7 +683,7 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
{
struct s3c2410_uartcfg *cfg = s3c24xx_port_to_cfg(port);
struct s3c24xx_uart_port *ourport = to_ourport(port);
- struct clk *clk = NULL;
+ struct clk *clk = ERR_PTR(-EINVAL);
unsigned long flags;
unsigned int baud, quot, clk_sel = 0;
unsigned int ulcon;
@@ -705,7 +704,7 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
quot = s3c24xx_serial_getclk(ourport, baud, &clk, &clk_sel);
if (baud == 38400 && (port->flags & UPF_SPD_MASK) == UPF_SPD_CUST)
quot = port->custom_divisor;
- if (!clk)
+ if (IS_ERR(clk))
return;
/* check to see if we need to change clock source */
@@ -713,9 +712,9 @@ static void s3c24xx_serial_set_termios(struct uart_port *port,
if (ourport->baudclk != clk) {
s3c24xx_serial_setsource(port, clk_sel);
- if (ourport->baudclk != NULL && !IS_ERR(ourport->baudclk)) {
+ if (!IS_ERR(ourport->baudclk)) {
clk_disable(ourport->baudclk);
- ourport->baudclk = NULL;
+ ourport->baudclk = ERR_PTR(-EINVAL);
}
clk_enable(clk);
@@ -1160,6 +1159,9 @@ static ssize_t s3c24xx_serial_show_clksrc(struct device *dev,
struct uart_port *port = s3c24xx_dev_to_port(dev);
struct s3c24xx_uart_port *ourport = to_ourport(port);
+ if (IS_ERR(ourport->baudclk))
+ return -EINVAL;
+
return snprintf(buf, PAGE_SIZE, "* %s\n", ourport->baudclk->name);
}
@@ -1200,6 +1202,7 @@ static int s3c24xx_serial_probe(struct platform_device *pdev)
return -ENODEV;
}
+ ourport->baudclk = ERR_PTR(-EINVAL);
ourport->info = ourport->drv_data->info;
ourport->cfg = (pdev->dev.platform_data) ?
(struct s3c2410_uartcfg *)pdev->dev.platform_data :
@@ -1387,7 +1390,7 @@ s3c24xx_serial_get_options(struct uart_port *port, int *baud,
sprintf(clk_name, "clk_uart_baud%d", clk_sel);
clk = clk_get(port->dev, clk_name);
- if (!IS_ERR(clk) && clk != NULL)
+ if (!IS_ERR(clk))
rate = clk_get_rate(clk);
else
rate = 1;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/2] serial: samsung: Fixed wrong comparison for baudclk_rate
From: Kyoungil Kim @ 2012-05-20 8:49 UTC (permalink / raw)
To: linux-arm-kernel, linux-samsung-soc, linux-serial
Cc: 'Kukjin Kim', 'Alan Cox', 'Kyoungil Kim',
'Yoon'
port->baudclk_rate should be compared to the rate of port->baudclk,
because port->baudclk_rate was assigned as the rate of port->baudclk previously.
So to check that the current baudclk rate is same as previous rate,
the target of comparison sholud be the rate of port->baudclk.
Signed-off-by: Jun-Ho, Yoon <junho78.yoon@samsung.com>
Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com>
---
drivers/tty/serial/samsung.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 5668538..cefdd2d 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1013,10 +1013,10 @@ static int s3c24xx_serial_cpufreq_transition(struct notifier_block *nb,
* a disturbance in the clock-rate over the change.
*/
- if (IS_ERR(port->clk))
+ if (IS_ERR(port->baudclk))
goto exit;
- if (port->baudclk_rate == clk_get_rate(port->clk))
+ if (port->baudclk_rate == clk_get_rate(port->baudclk))
goto exit;
if (val == CPUFREQ_PRECHANGE) {
--
1.7.1
^ permalink raw reply related
* [PATCH] serial: pxa: add spin lock for console write
From: Chao Xie @ 2012-05-21 2:33 UTC (permalink / raw)
To: linux-serial, haojian.zhuang; +Cc: Chao Xie
at UP mode, when cpu want to print message in kernel, it will invoke
peempt_disable and disable irq. So it is safe for UP mode.
For SMP mode, it is not safe to protect the HW reigsters.
one CPU will run a program which will invoke printf.
another CPU will run a program in kernel that invoke printk.
So when second CPU is trying to printk, it will do
1. save ier register
2. enable uue bit of ier register
3. push buffer to uart fifo
4 .restore ier register
when first CPU want to printf, and it happens between 1 and 4, it will
enable thre bit of ier, and waiting for transmit intterupt. while step 4
will make the ier lost thre bit.
add spin lock here to protect the ier register for console write.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
---
drivers/tty/serial/pxa.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index 5847a4b..d94387f 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
@@ -670,6 +670,16 @@ serial_pxa_console_write(struct console *co, const char *s, unsigned int count)
{
struct uart_pxa_port *up = serial_pxa_ports[co->index];
unsigned int ier;
+ unsigned long flags;
+ int locked = 1;
+
+ local_irq_save(flags);
+ if (up->port.sysrq)
+ locked = 0;
+ else if (oops_in_progress)
+ locked = spin_trylock(&up->port.lock);
+ else
+ spin_lock(&up->port.lock);
clk_prepare_enable(up->clk);
@@ -689,6 +699,11 @@ serial_pxa_console_write(struct console *co, const char *s, unsigned int count)
serial_out(up, UART_IER, ier);
clk_disable_unprepare(up->clk);
+
+ if (locked)
+ spin_unlock(&up->port.lock);
+ local_irq_restore(flags);
+
}
static int __init
--
1.7.0.4
^ permalink raw reply related
* Questions regarding adding a patch in linux/drivers/char/8250.c
From: Donald @ 2012-05-21 6:19 UTC (permalink / raw)
To: linux-serial
Hi,
This is Donald from ASIX Electronics Corp. My company has three PCI to Serial controllers, including MCS9845, MCS9835, and MCS9820.
Currently those serial devices using these three chips can directly use the Linux kernel's serial driver in
linux/drivers/char/8250.c. Recently we find these three chips have a hardware bug relating to parity error count function. We have a
software workaround for this issue. Below for reference is a pseudo code for this workaround.
serial8250_do_set_termios() {
If ((PID == MCS9845 || PID == MCS935 || PID == MCS9820) && ((termios->c_cflag & PARENB))) {
port->fifosize = 1; /* Change RX FIFO size to 1 byte */
up->ier &= ~UART_IER_RLSI; /* Disable RLSI interrupt */
}
}
Is it possible to add a patch into linux/drivers/char/8250.c for our chips' hardware issue? If it's not feasible to add a patch into
linux/drivers/char/8250.c, could we submit a new driver (e.g., mcs78xx_8250.c) to Linux kernel for devices using these three chips
(i.e., those devices can use new driver mcs78xx_8250.c instead of 8250.c)
Your reply to my questions will be very appreciated.
Regards,
Donald Lee
~~~~~~~~~~~~~~~~~~~~~~~~
R&D Division
ASIX Electronics Corporation
TEL: 886-3-5799500 ext.515
http://asix.com.tw/
~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: Questions regarding adding a patch in linux/drivers/char/8250.c
From: Alan Cox @ 2012-05-21 9:28 UTC (permalink / raw)
To: Donald; +Cc: linux-serial
In-Reply-To: <00a301cd3719$b3faa370$1befea50$@com.tw>
On Mon, 21 May 2012 14:19:34 +0800
"Donald" <donald@asix.com.tw> wrote:
> Hi,
>
> This is Donald from ASIX Electronics Corp. My company has three PCI to Serial controllers, including MCS9845, MCS9835, and MCS9820.
> Currently those serial devices using these three chips can directly use the Linux kernel's serial driver in
> linux/drivers/char/8250.c. Recently we find these three chips have a hardware bug relating to parity error count function. We have a
> software workaround for this issue. Below for reference is a pseudo code for this workaround.
>
> serial8250_do_set_termios() {
> If ((PID == MCS9845 || PID == MCS935 || PID == MCS9820) && ((termios->c_cflag & PARENB))) {
> port->fifosize = 1; /* Change RX FIFO size to 1 byte */
> up->ier &= ~UART_IER_RLSI; /* Disable RLSI interrupt */
> }
> }
>
> Is it possible to add a patch into linux/drivers/char/8250.c for our chips' hardware issue?
Sure.
The only question I would have is how do we reliably detect the presence
of the UART devices with this erratum. Can we do it from the PCI
identifier ?
Alan
^ permalink raw reply
* Re: Questions regarding adding a patch in linux/drivers/char/8250.c
From: Alan Cox @ 2012-05-21 9:30 UTC (permalink / raw)
To: Donald; +Cc: linux-serial
In-Reply-To: <00a301cd3719$b3faa370$1befea50$@com.tw>
On Mon, 21 May 2012 14:19:34 +0800
"Donald" <donald@asix.com.tw> wrote:
> Hi,
>
> This is Donald from ASIX Electronics Corp. My company has three PCI to Serial controllers, including MCS9845, MCS9835, and MCS9820.
> Currently those serial devices using these three chips can directly use the Linux kernel's serial driver in
> linux/drivers/char/8250.c. Recently we find these three chips have a hardware bug relating to parity error count function. We have a
> software workaround for this issue. Below for reference is a pseudo code for this workaround.
Actually I have a second question.
Would it not be better to set the device to 8N1 and do the parity in
software rather than lose the FIFO, especially at higher speeds ? Can you
clarify what the erratum is triggered by ?
Alan
^ permalink raw reply
* RE: Questions regarding adding a patch in linux/drivers/char/8250.c
From: Donald @ 2012-05-21 12:54 UTC (permalink / raw)
To: 'Alan Cox'; +Cc: linux-serial
In-Reply-To: <20120521103009.7f4be5e0@pyramind.ukuu.org.uk>
Hi Alan,
Thank you for your quick reply and nice questions. We will have an internal discussion regarding your questions and then I will
reply to your questions as soon as possible.
Regards,
Donald
-----Original Message-----
From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
Sent: Monday, May 21, 2012 5:30 PM
To: Donald
Cc: linux-serial@vger.kernel.org
Subject: Re: Questions regarding adding a patch in linux/drivers/char/8250.c
On Mon, 21 May 2012 14:19:34 +0800
"Donald" <donald@asix.com.tw> wrote:
> Hi,
>
> This is Donald from ASIX Electronics Corp. My company has three PCI to Serial controllers, including MCS9845, MCS9835, and
MCS9820.
> Currently those serial devices using these three chips can directly
> use the Linux kernel's serial driver in linux/drivers/char/8250.c.
> Recently we find these three chips have a hardware bug relating to parity error count function. We have a software workaround for
this issue. Below for reference is a pseudo code for this workaround.
Actually I have a second question.
Would it not be better to set the device to 8N1 and do the parity in software rather than lose the FIFO, especially at higher speeds
? Can you clarify what the erratum is triggered by ?
Alan
^ permalink raw reply
* Re: Questions regarding adding a patch in linux/drivers/char/8250.c
From: Jason Smith @ 2012-05-21 15:07 UTC (permalink / raw)
To: Alan Cox; +Cc: Donald, linux-serial, linux-serial-owner
In-Reply-To: <20120521103009.7f4be5e0@pyramind.ukuu.org.uk>
On Mon, May 21, 2012 at 4:30 AM, Alan Cox <alan@lxorguk.ukuu.org.uk>
wrote:
> On Mon, 21 May 2012 14:19:34 +0800
> "Donald" <donald@asix.com.tw> wrote:
>
>> Hi,
>>
>> This is Donald from ASIX Electronics Corp. My company has three PCI to
Serial controllers, including MCS9845, MCS9835, and MCS9820.
>> Currently those serial devices using these three chips can directly use
the Linux kernel's serial driver in
>> linux/drivers/char/8250.c. Recently we find these three chips have a
hardware bug relating to parity error count function. We have a
>> software workaround for this issue. Below for reference is a pseudo
code for this workaround.
>
> Actually I have a second question.
>
> Would it not be better to set the device to 8N1 and do the parity in
> software rather than lose the FIFO, especially at higher speeds ? Can
you
> clarify what the erratum is triggered by ?
>
> Alan
I saw your suggestion and thought it could work for a UART we are working
with as well, which cannot identify which bytes have parity errors.
However, It seems that doing parity in software would be a fine solution
if you are using less than 8 data bits, but would not work with 8 bits +
parity. Unless the UART supports 9 data bits, you would be unable to read
the parity byte from the UART, and would still have the same problem.
-Jason
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Donald" <donald@asix.com.tw>
Cc: <linux-serial@vger.kernel.org>
Date: 05/21/2012 04:29 AM
Subject: Re: Questions regarding adding a patch in
linux/drivers/char/8250.c
Sent by: linux-serial-owner@vger.kernel.org
On Mon, 21 May 2012 14:19:34 +0800
"Donald" <donald@asix.com.tw> wrote:
> Hi,
>
> This is Donald from ASIX Electronics Corp. My company has three PCI to
Serial controllers, including MCS9845, MCS9835, and MCS9820.
> Currently those serial devices using these three chips can directly use
the Linux kernel's serial driver in
> linux/drivers/char/8250.c. Recently we find these three chips have a
hardware bug relating to parity error count function. We have a
> software workaround for this issue. Below for reference is a pseudo code
for this workaround.
Actually I have a second question.
Would it not be better to set the device to 8N1 and do the parity in
software rather than lose the FIFO, especially at higher speeds ? Can you
clarify what the erratum is triggered by ?
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/1] serial_core: Update buffer overrun statistics.
From: Jason Smith @ 2012-05-21 15:12 UTC (permalink / raw)
To: Corbin
Cc: Alan Cox, Alan Cox, Corbin Atkinson, Greg Kroah-Hartman,
linux-serial, linux-serial-owner
In-Reply-To: <CAA0x6_8mPs_JLxnjrzNYc4qej-c0kkhbVyuJPsaPg8xBvmThqQ@mail.gmail.com>
On Tue, May 15, 2012 at 5:46 PM, Corbin <corbinat@gmail.com> wrote:
> On Tue, May 15, 2012 at 4:08 PM, Alan Cox <alan@linux.intel.com> wrote:
>>> it appears that the software buffer is actually artificially limited
>>> to 65536 bytes in the tty_buffer_alloc function in tty_buffer.c. I
>>
>> Yes although you shouldn't be able to hit this with flow control
>> enabled. Without flow control we didn't overrun at that level.
>>
>> it's really a semantics question - do we count stuff dumped
>> intentionally without flow control as an overrun.
>>
>> I'm not fundamentally opposed to the idea but it is a change of
meaning.
>>
>> Other views ?
>>
>> Alan
>
> While I agree on normal use cases this won't be hit due to flow
> control, I think it is still important to somehow know data was lost
> in the case where flow control isn't used. Calling it a buffer overrun
> was the way I thought was most fitting. I'm not sure what the
> alternatives would be.
>
> On a side note, If this isn't considered a buffer overrun I'm also not
> too sure what the buf_overrun field of the port's icount struct is
> for. While the "overrun" field is incremented in most drivers to
> indicate a hardware overrun, the "buf_overrun" field isn't really
> used. It appears that at least one of the few drivers using
> buf_overrun (cyclades.c) is interpreting it in the same way that I am,
> incrementing it when tty_buffer_request_room returns 0.
Has anyone had a chance to think about this anymore? We would really like
the capability to recognize that data has been discarded, even if it is
because no flow control is used and the user is ignoring the port. There
are cases, such as with RS-485, where there is no real flow control
mechanism is available, so we should not depend on flow-control as always
being an option. As Corbin mentioned, there are some other drivers using
buf_overrun (as opposed to overrun, which indicates FIFO overruns) for
this purpose, but we don't know if this was the original intention of this
field.
-Jason
^ permalink raw reply
* Re: [PATCH 1/1] serial_core: Update buffer overrun statistics.
From: Alan Cox @ 2012-05-21 16:05 UTC (permalink / raw)
To: Jason Smith
Cc: Corbin, Alan Cox, Corbin Atkinson, Greg Kroah-Hartman,
linux-serial
In-Reply-To: <OF12D97EE0.DCA5956B-ON86257A05.00532260-86257A05.00537F9F@ni.com>
> Has anyone had a chance to think about this anymore? We would really like
> the capability to recognize that data has been discarded, even if it is
> because no flow control is used and the user is ignoring the port. There
> are cases, such as with RS-485, where there is no real flow control
> mechanism is available, so we should not depend on flow-control as always
> being an option. As Corbin mentioned, there are some other drivers using
> buf_overrun (as opposed to overrun, which indicates FIFO overruns) for
> this purpose, but we don't know if this was the original intention of this
> field.
I was hopng Jiri would chip in.
If you think its important and want to argue for it, I'm not going to
fight against it.
Alan
^ permalink raw reply
* [PATCH] serial/imx: make devdata member point to const data
From: Uwe Kleine-König @ 2012-05-21 19:57 UTC (permalink / raw)
To: Alan Cox, Greg Kroah-Hartman
Cc: kernel, linux-serial, devicetree-discuss, Arnd Bergmann
In-Reply-To: <1335171381-24869-1-git-send-email-u.kleine-koenig@pengutronix.de>
This is only cosmetic for now. In case that
http://mid.gmane.org/1335171381-24869-1-git-send-email-u.kleine-koenig@pengutronix.de
will be applied, it fixes a warning
drivers/tty/serial/imx.c: In function 'serial_imx_probe_dt':
drivers/tty/serial/imx.c:1430:17: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
though.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/tty/serial/imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index e7fecee..d409bbb 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -205,7 +205,7 @@ struct imx_port {
unsigned int irda_inv_tx:1;
unsigned short trcv_delay; /* transceiver delay */
struct clk *clk;
- struct imx_uart_data *devdata;
+ const struct imx_uart_data *devdata;
};
struct imx_port_ucrs {
--
1.7.10
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* RE: [PATCH] serial: pxa: add spin lock for console write
From: Haojian Zhuang @ 2012-05-22 3:07 UTC (permalink / raw)
To: linux-serial@vger.kernel.org; +Cc: Chao Xie
In-Reply-To: <1337567628-22180-1-git-send-email-chao.xie@marvell.com>
int clk_prepare(struct clk *clk)
{
int ret;
mutex_lock(&prepare_lock);
ret = __clk_prepare(clk);
mutex_unlock(&prepare_lock);
return ret;
}
EXPORT_SYMBOL_GPL(clk_prepare);
So invoking local_irq_save() before clk_prepare_enable() is wrong behavior.
Regards
Haojian
________________________________________
From: Chao Xie [chao.xie@marvell.com]
Sent: Monday, May 21, 2012 10:33 AM
To: linux-serial@vger.kernel.org; Haojian Zhuang
Cc: Chao Xie
Subject: [PATCH] serial: pxa: add spin lock for console write
at UP mode, when cpu want to print message in kernel, it will invoke
peempt_disable and disable irq. So it is safe for UP mode.
For SMP mode, it is not safe to protect the HW reigsters.
one CPU will run a program which will invoke printf.
another CPU will run a program in kernel that invoke printk.
So when second CPU is trying to printk, it will do
1. save ier register
2. enable uue bit of ier register
3. push buffer to uart fifo
4 .restore ier register
when first CPU want to printf, and it happens between 1 and 4, it will
enable thre bit of ier, and waiting for transmit intterupt. while step 4
will make the ier lost thre bit.
add spin lock here to protect the ier register for console write.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
---
drivers/tty/serial/pxa.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index 5847a4b..d94387f 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
@@ -670,6 +670,16 @@ serial_pxa_console_write(struct console *co, const char *s, unsigned int count)
{
struct uart_pxa_port *up = serial_pxa_ports[co->index];
unsigned int ier;
+ unsigned long flags;
+ int locked = 1;
+
+ local_irq_save(flags);
+ if (up->port.sysrq)
+ locked = 0;
+ else if (oops_in_progress)
+ locked = spin_trylock(&up->port.lock);
+ else
+ spin_lock(&up->port.lock);
clk_prepare_enable(up->clk);
@@ -689,6 +699,11 @@ serial_pxa_console_write(struct console *co, const char *s, unsigned int count)
serial_out(up, UART_IER, ier);
clk_disable_unprepare(up->clk);
+
+ if (locked)
+ spin_unlock(&up->port.lock);
+ local_irq_restore(flags);
+
}
static int __init
--
1.7.0.4
^ permalink raw reply related
* [PATCH V2] serial: pxa: add spin lock for console write
From: Chao Xie @ 2012-05-22 4:43 UTC (permalink / raw)
To: linux-serial, haojian.zhuang; +Cc: Chao Xie
at UP mode, when cpu want to print message in kernel, it will invoke
peempt_disable and disable irq. So it is safe for UP mode.
For SMP mode, it is not safe to protect the HW reigsters.
one CPU will run a program which will invoke printf.
another CPU will run a program in kernel that invoke printk.
So when second CPU is trying to printk, it will do
1. save ier register
2. enable uue bit of ier register
3. push buffer to uart fifo
4 .restore ier register
when first CPU want to printf, and it happens between 1 and 4, it will
enable thre bit of ier, and waiting for transmit intterupt. while step 4
will make the ier lost thre bit.
add spin lock here to protect the ier register for console write.
Signed-off-by: Chao Xie <chao.xie@marvell.com>
---
drivers/tty/serial/pxa.c | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index 5847a4b..aca62f6 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
@@ -670,9 +670,19 @@ serial_pxa_console_write(struct console *co, const char *s, unsigned int count)
{
struct uart_pxa_port *up = serial_pxa_ports[co->index];
unsigned int ier;
+ unsigned long flags;
+ int locked = 1;
clk_prepare_enable(up->clk);
+ local_irq_save(flags);
+ if (up->port.sysrq)
+ locked = 0;
+ else if (oops_in_progress)
+ locked = spin_trylock(&up->port.lock);
+ else
+ spin_lock(&up->port.lock);
+
/*
* First save the IER then disable the interrupts
*/
@@ -688,7 +698,12 @@ serial_pxa_console_write(struct console *co, const char *s, unsigned int count)
wait_for_xmitr(up);
serial_out(up, UART_IER, ier);
+ if (locked)
+ spin_unlock(&up->port.lock);
+ local_irq_restore(flags);
+
clk_disable_unprepare(up->clk);
+
}
static int __init
--
1.7.0.4
^ permalink raw reply related
* Fwd: struct tty_flip_buffer replacement in newer kernels
From: Jack Stone @ 2012-05-22 12:32 UTC (permalink / raw)
To: gregkh, alan, linux-serial
In-Reply-To: <CAMMxdh1Ak2LWeL=3qxTmvfR43E=wSHz5OmSj_irMubz0aK+TgA@mail.gmail.com>
[Add CCs]
-------- Original Message --------
Subject: struct tty_flip_buffer replacement in newer kernels
Date: Tue, 22 May 2012 16:17:02 +0400
From: Dmitriy Alekseev <deathonfuneral@gmail.com>
To: linux-kernel@vger.kernel.org
Hello
I'm newbie, working under existed serial driver, adapting it for 2.6.32.
During the compilation I have had several problems, which I
succesfully solved except this one:
error: 'struct tty_struct' has no member named 'flip'
In particular, cound you advice correct replacement of "tty->flip.count"
Thanks
--
Best Regards,
Dmitriy Alekseev
^ permalink raw reply
* [GIT PATCH] TTY/serial patches for 3.5-rc1
From: Greg KH @ 2012-05-22 13:20 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton; +Cc: linux-kernel, linux-serial
The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3:
Linux 3.4-rc6 (2012-05-06 15:07:32 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-3.5-rc1
for you to fetch changes up to d48b97b403d23f6df0b990cee652bdf9a52337a3:
Linux 3.4-rc6 (2012-05-06 15:07:32 -0700)
----------------------------------------------------------------
TTY pull request for 3.5-rc1
Here's the big TTY/serial driver pull request for the 3.5-rc1 merge window.
Nothing major in here, just lots of incremental changes from Alan and
Jiri reworking some tty core things to behave better and to get a more
solid grasp on some of the nasty tty locking issues.
There are a few tty and serial driver updates in here as well.
All of this has been in the linux-next releases for a while with no problems.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
----------------------------------------------------------------
Documentation/ABI/testing/sysfs-bus-hsi | 19 -
.../ata/{ahci-platform.txt => calxeda-sata.txt} | 5 +-
.../devicetree/bindings/sound/sgtl5000.txt | 2 -
Documentation/networking/ip-sysctl.txt | 4 +-
Documentation/power/freezing-of-tasks.txt | 37 +-
Documentation/security/keys.txt | 14 +-
MAINTAINERS | 12 +-
Makefile | 2 +-
arch/alpha/Kconfig | 2 +-
arch/alpha/include/asm/rtc.h | 8 +-
arch/alpha/kernel/core_tsunami.c | 1 -
arch/alpha/kernel/sys_marvel.c | 2 +-
arch/arm/Kconfig | 9 -
arch/arm/boot/dts/msm8660-surf.dts | 4 +-
arch/arm/boot/dts/versatile-ab.dts | 2 +-
arch/arm/boot/dts/versatile-pb.dts | 2 +-
arch/arm/configs/mini2440_defconfig | 2 -
arch/arm/include/asm/thread_info.h | 7 -
arch/arm/include/asm/tls.h | 4 -
arch/arm/kernel/irq.c | 6 +-
arch/arm/kernel/signal.c | 55 ++-
arch/arm/kernel/smp.c | 28 +-
arch/arm/kernel/smp_twd.c | 6 +-
arch/arm/mach-exynos/clock-exynos4.c | 24 +-
arch/arm/mach-exynos/clock-exynos5.c | 24 +-
arch/arm/mach-exynos/common.c | 14 +-
arch/arm/mach-exynos/dev-dwmci.c | 13 +-
arch/arm/mach-exynos/mach-nuri.c | 1 -
arch/arm/mach-exynos/mach-universal_c210.c | 1 -
arch/arm/mach-msm/board-msm8x60.c | 25 +-
arch/arm/mach-omap2/serial.c | 8 -
arch/arm/mach-pxa/include/mach/mfp-pxa2xx.h | 7 -
arch/arm/mach-pxa/mfp-pxa2xx.c | 21 +-
arch/arm/mach-pxa/pxa27x.c | 6 +-
arch/arm/mach-s3c24xx/Kconfig | 8 +-
arch/arm/mach-s5pv210/mach-goni.c | 2 -
arch/arm/mach-sa1100/generic.c | 2 +-
arch/arm/mach-tegra/board-harmony.c | 2 +
arch/arm/mach-tegra/board-paz00.c | 3 +
arch/arm/mach-tegra/board-seaboard.c | 2 +
arch/arm/mach-tegra/board-trimslice.c | 2 +
arch/arm/mach-u300/core.c | 6 +-
arch/arm/mach-u300/i2c.c | 9 +-
arch/arm/mach-u300/include/mach/irqs.h | 150 +++----
arch/arm/mach-ux500/mbox-db5500.c | 2 +-
arch/arm/mm/abort-ev6.S | 17 +-
arch/arm/mm/cache-l2x0.c | 25 +-
arch/arm/mm/init.c | 4 +-
arch/arm/mm/mmu.c | 4 +-
arch/arm/plat-omap/dma.c | 14 -
arch/arm/plat-omap/include/plat/omap-serial.h | 1 -
arch/arm/plat-samsung/include/plat/sdhci.h | 28 --
arch/arm/vfp/vfpmodule.c | 99 -----
arch/blackfin/mach-bf538/boards/ezkit.c | 53 +--
arch/hexagon/kernel/dma.c | 1 -
arch/hexagon/kernel/process.c | 6 +-
arch/hexagon/kernel/ptrace.c | 1 -
arch/hexagon/kernel/smp.c | 8 +-
arch/hexagon/kernel/time.c | 1 -
arch/hexagon/kernel/vdso.c | 1 -
arch/mips/ath79/dev-wmac.c | 2 +-
arch/mips/include/asm/mach-jz4740/irq.h | 2 +-
arch/mips/include/asm/mmu_context.h | 6 +
arch/mips/kernel/signal.c | 27 +-
arch/mips/kernel/signal32.c | 20 +-
arch/mips/kernel/signal_n32.c | 10 +-
arch/parisc/kernel/pdc_cons.c | 2 +-
arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi | 43 --
arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi | 10 -
arch/powerpc/include/asm/irq.h | 4 +
arch/powerpc/include/asm/mpic.h | 18 +
arch/powerpc/include/asm/mpic_msgr.h | 1 -
arch/powerpc/include/asm/reg_booke.h | 5 +
arch/powerpc/kernel/irq.c | 6 +-
arch/powerpc/kernel/machine_kexec.c | 7 +-
arch/powerpc/kernel/setup_32.c | 3 -
arch/powerpc/net/bpf_jit.h | 8 +-
arch/powerpc/net/bpf_jit_64.S | 108 +----
arch/powerpc/net/bpf_jit_comp.c | 26 +-
arch/powerpc/platforms/85xx/common.c | 6 -
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 11 +-
arch/powerpc/platforms/85xx/p1022_ds.c | 13 +-
arch/powerpc/platforms/cell/axon_msi.c | 8 +-
arch/powerpc/platforms/cell/beat_interrupt.c | 2 +-
arch/powerpc/platforms/powermac/low_i2c.c | 9 -
arch/powerpc/platforms/powermac/pic.c | 6 +-
arch/powerpc/platforms/pseries/Kconfig | 4 +-
arch/powerpc/platforms/pseries/eeh.c | 2 +-
arch/powerpc/sysdev/cpm2_pic.c | 3 +-
arch/powerpc/sysdev/mpc8xx_pic.c | 61 ++-
arch/powerpc/sysdev/mpic.c | 54 +--
arch/powerpc/sysdev/mpic_msgr.c | 12 +-
arch/powerpc/sysdev/scom.c | 1 -
arch/powerpc/sysdev/xics/xics-common.c | 7 +-
arch/sh/include/asm/atomic.h | 2 +-
arch/sh/mm/fault_32.c | 2 +-
arch/tile/include/asm/pci.h | 4 +-
arch/tile/kernel/pci.c | 4 +-
arch/x86/Kconfig | 2 +-
arch/x86/boot/compressed/head_32.S | 14 +-
arch/x86/boot/compressed/head_64.S | 22 +-
arch/x86/boot/compressed/relocs.c | 2 +
arch/x86/boot/tools/build.c | 15 +-
arch/x86/ia32/ia32_aout.c | 3 +-
arch/x86/include/asm/posix_types.h | 6 +-
arch/x86/include/asm/sigcontext.h | 2 +-
arch/x86/include/asm/siginfo.h | 8 +-
arch/x86/include/asm/unistd.h | 6 +-
arch/x86/include/asm/word-at-a-time.h | 33 --
arch/x86/include/asm/x86_init.h | 1 +
arch/x86/kernel/acpi/sleep.c | 4 -
arch/x86/kernel/acpi/sleep.h | 4 -
arch/x86/kernel/acpi/wakeup_32.S | 4 +-
arch/x86/kernel/acpi/wakeup_64.S | 4 +-
arch/x86/kernel/apic/apic.c | 34 +-
arch/x86/kernel/apic/apic_numachip.c | 7 +-
arch/x86/kernel/apic/x2apic_phys.c | 6 -
arch/x86/kernel/cpu/amd.c | 29 +-
arch/x86/kernel/cpu/common.c | 9 +
arch/x86/kernel/cpu/intel_cacheinfo.c | 8 +-
arch/x86/kernel/i387.c | 1 -
arch/x86/kernel/microcode_amd.c | 12 +-
arch/x86/kernel/microcode_core.c | 10 +-
arch/x86/kernel/x86_init.c | 1 +
arch/x86/platform/geode/net5501.c | 2 +-
arch/x86/platform/mrst/mrst.c | 4 +-
arch/x86/xen/enlighten.c | 4 +-
arch/x86/xen/smp.c | 15 -
arch/x86/xen/xen-asm.S | 2 +-
arch/xtensa/include/asm/hardirq.h | 3 +
arch/xtensa/include/asm/io.h | 1 -
arch/xtensa/kernel/signal.c | 1 -
drivers/acpi/power.c | 2 +-
drivers/acpi/scan.c | 17 +-
drivers/acpi/sleep.c | 52 +--
drivers/ata/ahci.c | 2 -
drivers/ata/ahci_platform.c | 1 -
drivers/ata/libata-core.c | 2 +-
drivers/ata/libata-eh.c | 3 +-
drivers/ata/libata-scsi.c | 38 +-
drivers/ata/pata_arasan_cf.c | 4 +-
drivers/bcma/sprom.c | 7 +-
drivers/bluetooth/ath3k.c | 4 -
drivers/bluetooth/btusb.c | 6 -
drivers/dma/amba-pl08x.c | 1 -
drivers/dma/at_hdmac.c | 4 +
drivers/dma/imx-dma.c | 9 +-
drivers/dma/mxs-dma.c | 10 +-
drivers/dma/pl330.c | 25 +-
drivers/dma/ste_dma40.c | 323 +++++---------
drivers/dma/ste_dma40_ll.h | 2 +
drivers/firmware/efivars.c | 196 --------
drivers/gpio/gpio-pxa.c | 21 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 30 +-
drivers/gpu/drm/i915/i915_debugfs.c | 3 -
drivers/gpu/drm/i915/i915_dma.c | 15 +-
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 8 +-
drivers/gpu/drm/i915/i915_reg.h | 1 -
drivers/gpu/drm/i915/intel_crt.c | 29 +-
drivers/gpu/drm/i915/intel_display.c | 9 +-
drivers/gpu/drm/i915/intel_hdmi.c | 2 +-
drivers/gpu/drm/i915/intel_lvds.c | 4 +-
drivers/gpu/drm/i915/intel_ringbuffer.c | 8 -
drivers/gpu/drm/i915/intel_sdvo.c | 34 +-
drivers/gpu/drm/nouveau/nouveau_acpi.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bios.c | 10 +-
drivers/gpu/drm/nouveau/nouveau_hdmi.c | 4 +-
drivers/gpu/drm/nouveau/nv10_gpio.c | 2 +-
drivers/gpu/drm/nouveau/nvc0_fb.c | 5 -
drivers/gpu/drm/radeon/atombios_crtc.c | 7 +-
drivers/gpu/drm/radeon/radeon_device.c | 4 +-
drivers/gpu/drm/radeon/radeon_display.c | 3 +-
drivers/hsi/clients/hsi_char.c | 2 +-
drivers/hsi/hsi.c | 223 +++++-----
drivers/hwmon/ad7314.c | 12 +-
drivers/hwmon/coretemp.c | 6 +-
drivers/hwmon/fam15h_power.c | 9 +-
drivers/i2c/busses/i2c-eg20t.c | 4 +-
drivers/i2c/busses/i2c-mxs.c | 8 +-
drivers/i2c/busses/i2c-pnx.c | 3 +-
drivers/i2c/busses/i2c-tegra.c | 8 -
drivers/infiniband/core/mad.c | 8 +-
drivers/infiniband/hw/mlx4/main.c | 2 +-
drivers/input/mouse/synaptics.c | 3 +-
drivers/isdn/i4l/isdn_common.c | 5 -
drivers/isdn/i4l/isdn_tty.c | 466 ++++++++------------
drivers/md/bitmap.c | 3 +-
drivers/md/bitmap.h | 3 +
drivers/md/dm-raid.c | 4 +-
drivers/md/md.c | 7 +-
drivers/mfd/omap-usb-host.c | 1 -
drivers/mmc/host/mxs-mmc.c | 3 -
drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 1 -
drivers/net/arcnet/arc-rimi.c | 8 +-
drivers/net/caif/caif_hsi.c | 9 +-
drivers/net/can/usb/peak_usb/pcan_usb_pro.c | 2 -
drivers/net/dummy.c | 6 +-
drivers/net/ethernet/atheros/atlx/atl1.c | 12 +-
drivers/net/ethernet/atheros/atlx/atl1.h | 3 +-
drivers/net/ethernet/atheros/atlx/atlx.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 12 +-
drivers/net/ethernet/broadcom/tg3.c | 18 +-
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 92 ++--
drivers/net/ethernet/dlink/dl2k.c | 52 ++-
drivers/net/ethernet/dlink/dl2k.h | 7 +
drivers/net/ethernet/freescale/ucc_geth.c | 6 +-
drivers/net/ethernet/freescale/ucc_geth.h | 2 +-
drivers/net/ethernet/ibm/ehea/ehea_main.c | 60 ++-
drivers/net/ethernet/ibm/ehea/ehea_phyp.h | 2 +-
drivers/net/ethernet/intel/e1000e/ich8lan.c | 15 +-
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
drivers/net/ethernet/intel/e1000e/param.c | 99 ++---
drivers/net/ethernet/intel/igbvf/netdev.c | 4 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_fcoe.c | 1 -
drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c | 10 -
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 29 +-
drivers/net/ethernet/marvell/sky2.c | 31 +-
drivers/net/ethernet/marvell/sky2.h | 1 +
drivers/net/ethernet/micrel/ks8851.c | 21 +-
drivers/net/ethernet/micrel/ks8851_mll.c | 2 +-
drivers/net/ethernet/micrel/ksz884x.c | 2 +-
drivers/net/ethernet/realtek/8139cp.c | 10 +-
drivers/net/ethernet/smsc/smsc911x.c | 17 +-
drivers/net/ethernet/sun/sungem.c | 2 +-
drivers/net/ethernet/ti/davinci_emac.c | 2 +-
drivers/net/ethernet/ti/davinci_mdio.c | 5 -
drivers/net/ethernet/ti/tlan.c | 2 +-
drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 +-
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 6 +-
drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c | 6 +-
drivers/net/hyperv/netvsc_drv.c | 38 +-
drivers/net/phy/icplus.c | 12 +-
drivers/net/ppp/ppp_generic.c | 15 +-
drivers/net/usb/asix.c | 4 +-
drivers/net/usb/hso.c | 105 ++---
drivers/net/usb/qmi_wwan.c | 30 --
drivers/net/usb/smsc75xx.c | 36 +-
drivers/net/usb/smsc95xx.c | 3 +-
drivers/net/usb/usbnet.c | 5 +-
drivers/net/virtio_net.c | 5 +-
drivers/net/wan/farsync.c | 1 -
drivers/net/wireless/ath/ath5k/ahb.c | 8 +-
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_9287.c | 2 -
drivers/net/wireless/ath/ath9k/hw.c | 9 +-
drivers/net/wireless/ath/ath9k/hw.h | 3 +-
drivers/net/wireless/ath/ath9k/main.c | 9 +-
drivers/net/wireless/ath/ath9k/xmit.c | 10 +-
drivers/net/wireless/b43/main.c | 10 +-
.../net/wireless/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 8 +-
drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c | 63 +--
drivers/net/wireless/brcm80211/brcmsmac/main.c | 11 +-
drivers/net/wireless/ipw2x00/ipw2200.c | 13 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-2000.c | 16 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 11 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 3 +
drivers/net/wireless/iwlwifi/iwl-fh.h | 24 +-
drivers/net/wireless/iwlwifi/iwl-mac80211.c | 10 +-
drivers/net/wireless/iwlwifi/iwl-prph.h | 27 +-
drivers/net/wireless/libertas/cfg.c | 9 +-
drivers/net/wireless/mwifiex/pcie.h | 18 +-
drivers/net/wireless/rtlwifi/pci.c | 1 -
drivers/net/wireless/wl1251/main.c | 1 -
drivers/net/wireless/wl1251/sdio.c | 2 +-
drivers/pci/Makefile | 1 -
drivers/pci/pci-acpi.c | 4 +-
drivers/platform/x86/acerhdf.c | 67 +--
drivers/platform/x86/dell-laptop.c | 1 -
drivers/platform/x86/intel_ips.c | 2 +-
drivers/platform/x86/intel_mid_powerbtn.c | 2 +-
drivers/rtc/rtc-ds1307.c | 1 -
drivers/rtc/rtc-mpc5121.c | 3 +-
drivers/s390/char/con3215.c | 142 +++---
drivers/s390/char/keyboard.c | 30 +-
drivers/s390/char/keyboard.h | 14 +-
drivers/s390/char/sclp_tty.c | 33 +-
drivers/s390/char/sclp_vt220.c | 33 +-
drivers/s390/char/tty3270.c | 121 +++--
drivers/s390/net/qeth_core_main.c | 6 +-
drivers/scsi/ipr.c | 6 +-
drivers/scsi/libfc/fc_lport.c | 12 +-
drivers/scsi/libsas/sas_ata.c | 33 +-
drivers/scsi/libsas/sas_discover.c | 61 ++-
drivers/scsi/libsas/sas_event.c | 24 +-
drivers/scsi/libsas/sas_expander.c | 56 +--
drivers/scsi/libsas/sas_init.c | 11 +-
drivers/scsi/libsas/sas_internal.h | 6 +-
drivers/scsi/libsas/sas_phy.c | 21 +-
drivers/scsi/libsas/sas_port.c | 17 +-
drivers/scsi/scsi_lib.c | 2 +-
drivers/spi/Kconfig | 2 +-
drivers/spi/Makefile | 2 +-
drivers/spi/spi-bcm63xx.c | 163 +++----
drivers/spi/spi-bfin-sport.c | 21 +-
drivers/spi/spi-bfin5xx.c | 14 +-
drivers/spi/spi-ep93xx.c | 24 +-
drivers/spi/spi-pl022.c | 58 +--
drivers/staging/octeon/ethernet-rx.c | 1 -
drivers/staging/octeon/ethernet-tx.c | 1 -
drivers/staging/octeon/ethernet.c | 1 -
drivers/staging/ozwpan/ozpd.c | 2 +
drivers/staging/serial/68360serial.c | 4 +-
drivers/staging/tidspbridge/core/tiomap3430.c | 20 +-
drivers/staging/tidspbridge/core/wdt.c | 8 +-
drivers/staging/zcache/Kconfig | 2 +-
drivers/tty/amiserial.c | 14 +-
drivers/tty/bfin_jtag_comm.c | 44 +-
drivers/tty/cyclades.c | 2 +-
drivers/tty/hvc/hvc_console.c | 96 ++--
drivers/tty/hvc/hvc_console.h | 4 +-
drivers/tty/hvc/hvc_xen.c | 4 +-
drivers/tty/hvc/hvcs.c | 74 ++--
drivers/tty/hvc/hvsi.c | 128 +++---
drivers/tty/hvc/hvsi_lib.c | 2 +-
drivers/tty/ipwireless/tty.c | 81 ++--
drivers/tty/mxser.c | 2 +-
drivers/tty/n_r3964.c | 11 +-
drivers/tty/n_tty.c | 9 +-
drivers/tty/pty.c | 40 +-
drivers/tty/serial/68328serial.c | 383 +++++++---------
drivers/tty/serial/68328serial.h | 186 --------
drivers/tty/serial/8250/8250.c | 312 +++++++------
drivers/tty/serial/8250/8250.h | 16 +
drivers/tty/serial/8250/8250_em.c | 186 ++++++++
drivers/tty/serial/8250/8250_pci.c | 63 +++
drivers/tty/serial/8250/Kconfig | 8 +
drivers/tty/serial/8250/Makefile | 1 +
drivers/tty/serial/amba-pl011.c | 109 +----
drivers/tty/serial/bfin_uart.c | 74 ++--
drivers/tty/serial/crisv10.c | 36 +-
drivers/tty/serial/mxs-auart.c | 2 +
drivers/tty/serial/of_serial.c | 26 ++
drivers/tty/serial/omap-serial.c | 74 +++-
drivers/tty/serial/pch_uart.c | 53 ++-
drivers/tty/serial/pmac_zilog.c | 6 +-
drivers/tty/serial/serial_core.c | 1 +
drivers/tty/synclink.c | 4 +-
drivers/tty/synclink_gt.c | 4 +-
drivers/tty/synclinkmp.c | 4 +-
drivers/tty/tty_buffer.c | 85 +++-
drivers/tty/tty_io.c | 76 ++--
drivers/tty/tty_ldisc.c | 37 +-
drivers/tty/tty_mutex.c | 60 ++-
drivers/tty/tty_port.c | 6 +-
drivers/tty/vt/consolemap.c | 123 ++++--
drivers/tty/vt/keyboard.c | 28 +-
drivers/tty/vt/vt.c | 68 ++-
drivers/tty/vt/vt_ioctl.c | 25 +-
drivers/usb/class/cdc-wdm.c | 7 +-
drivers/usb/core/hcd-pci.c | 9 -
drivers/usb/gadget/dummy_hcd.c | 1 +
drivers/usb/gadget/f_mass_storage.c | 2 +-
drivers/usb/gadget/file_storage.c | 2 +-
drivers/usb/gadget/u_serial.c | 51 +--
drivers/usb/gadget/udc-core.c | 4 +-
drivers/usb/gadget/uvc.h | 2 +-
drivers/usb/gadget/uvc_v4l2.c | 2 +-
drivers/usb/host/ehci-pci.c | 8 -
drivers/usb/host/ehci-tegra.c | 376 ++++++++--------
drivers/usb/musb/davinci.c | 3 +-
drivers/usb/musb/musb_core.h | 2 +-
drivers/usb/otg/gpio_vbus.c | 15 +-
drivers/vhost/net.c | 2 +-
drivers/vhost/vhost.c | 5 +-
drivers/vhost/vhost.h | 2 +-
drivers/video/bfin-lq035q1-fb.c | 1 -
drivers/watchdog/hpwdt.c | 6 +-
drivers/xen/events.c | 2 +-
drivers/xen/xen-acpi-processor.c | 5 +-
fs/autofs4/autofs_i.h | 12 +-
fs/autofs4/dev-ioctl.c | 3 +-
fs/autofs4/inode.c | 4 +-
fs/autofs4/waitq.c | 22 +-
fs/btrfs/backref.c | 27 +-
fs/btrfs/ctree.c | 28 +-
fs/btrfs/ctree.h | 2 +-
fs/btrfs/disk-io.c | 40 +-
fs/btrfs/disk-io.h | 3 +-
fs/btrfs/extent-tree.c | 17 +-
fs/btrfs/extent_io.c | 60 +--
fs/btrfs/extent_io.h | 4 +-
fs/btrfs/file.c | 9 +-
fs/btrfs/inode.c | 54 ++-
fs/btrfs/ioctl.c | 5 +-
fs/btrfs/ioctl.h | 4 +-
fs/btrfs/reada.c | 48 +-
fs/btrfs/relocation.c | 4 +-
fs/btrfs/scrub.c | 22 +-
fs/btrfs/super.c | 7 +-
fs/btrfs/transaction.c | 6 +-
fs/btrfs/tree-log.c | 2 +-
fs/btrfs/volumes.c | 13 +-
fs/buffer.c | 1 +
fs/cifs/cifsfs.c | 14 +-
fs/cifs/cifsfs.h | 2 +-
fs/cifs/cifssmb.c | 6 +-
fs/cifs/connect.c | 33 +-
fs/cifs/dir.c | 17 +-
fs/cifs/file.c | 3 +-
fs/dcache.c | 26 +-
fs/dlm/lock.c | 12 -
fs/eventpoll.c | 4 +-
fs/ext4/super.c | 2 -
fs/gfs2/lock_dlm.c | 10 +-
fs/hfsplus/catalog.c | 4 -
fs/hfsplus/dir.c | 11 -
fs/hugetlbfs/inode.c | 1 -
fs/jbd2/commit.c | 4 +-
fs/namei.c | 4 +-
fs/nfs/blocklayout/blocklayout.c | 4 +-
fs/nfs/client.c | 5 +-
fs/nfs/dir.c | 4 +-
fs/nfs/idmap.c | 4 -
fs/nfs/internal.h | 8 +-
fs/nfs/namespace.c | 93 ++--
fs/nfs/nfs4_fs.h | 11 +-
fs/nfs/nfs4filelayoutdev.c | 2 +-
fs/nfs/nfs4namespace.c | 86 +---
fs/nfs/nfs4proc.c | 186 ++------
fs/nfs/nfs4state.c | 31 +-
fs/nfs/nfs4xdr.c | 53 +--
fs/nfs/objlayout/objlayout.c | 2 +
fs/nfs/pnfs.c | 2 +-
fs/nfs/read.c | 2 +-
fs/nfs/super.c | 12 +-
fs/nfs/write.c | 5 +-
fs/nfsd/nfs4recover.c | 2 +-
fs/pipe.c | 31 +-
fs/proc/task_mmu.c | 3 +
include/acpi/actypes.h | 7 +-
include/asm-generic/siginfo.h | 14 +-
include/asm-generic/statfs.h | 2 +-
include/linux/efi.h | 13 +-
include/linux/generic_serial.h | 64 +--
include/linux/gpio-pxa.h | 4 -
include/linux/hsi/hsi.h | 31 +-
include/linux/irq.h | 7 -
include/linux/isdn.h | 26 +-
include/linux/libata.h | 3 +-
include/linux/netfilter_bridge.h | 9 -
include/linux/nfs_xdr.h | 7 +-
include/linux/of_serial.h | 17 +
include/linux/pipe_fs_i.h | 1 -
include/linux/seqlock.h | 23 +-
include/linux/serial_8250.h | 2 +
include/linux/serial_core.h | 5 +
include/linux/skbuff.h | 11 +-
include/linux/spi/spi.h | 2 +-
include/linux/tty.h | 23 +-
include/linux/tty_ldisc.h | 2 +
include/linux/usb/hcd.h | 2 -
include/linux/vm_event_item.h | 5 +-
include/linux/vt_kern.h | 1 -
include/net/bluetooth/hci_core.h | 3 +-
include/net/dst.h | 7 +-
include/net/ip6_fib.h | 48 --
include/net/ip_vs.h | 4 +-
include/net/red.h | 6 +-
include/net/sock.h | 5 +-
include/scsi/libsas.h | 40 +-
include/scsi/sas_ata.h | 4 +-
init/do_mounts.c | 2 +-
init/main.c | 25 +-
kernel/events/core.c | 2 +-
kernel/irq/debug.h | 38 +-
kernel/power/swap.c | 28 +-
kernel/rcutree.c | 1 +
kernel/sched/core.c | 22 +-
kernel/sched/fair.c | 18 +-
kernel/sched/features.h | 1 -
kernel/time/tick-broadcast.c | 13 +-
kernel/trace/trace.c | 8 +-
kernel/trace/trace.h | 4 +-
kernel/trace/trace_output.c | 5 -
mm/hugetlb.c | 2 +-
mm/memcontrol.c | 17 +-
mm/mempolicy.c | 11 +-
mm/migrate.c | 16 +-
mm/nobootmem.c | 10 +-
mm/swap_state.c | 2 +-
mm/vmscan.c | 11 +-
mm/vmstat.c | 4 +-
net/ax25/af_ax25.c | 9 +-
net/bluetooth/hci_core.c | 27 +-
net/bluetooth/hci_event.c | 3 -
net/bluetooth/mgmt.c | 2 +-
net/bluetooth/rfcomm/tty.c | 137 +++---
net/bridge/br_forward.c | 1 -
net/bridge/br_netfilter.c | 8 +-
net/caif/chnl_net.c | 9 +-
net/core/dev.c | 20 -
net/core/drop_monitor.c | 89 +---
net/core/net_namespace.c | 33 +-
net/ieee802154/6lowpan.c | 40 +-
net/ipv4/inet_diag.c | 2 +-
net/ipv4/tcp.c | 9 +-
net/ipv4/tcp_input.c | 14 +-
net/ipv4/tcp_output.c | 1 -
net/ipv4/udp_diag.c | 9 -
net/ipv6/addrconf.c | 9 +-
net/ipv6/ip6_fib.c | 9 +-
net/ipv6/ndisc.c | 3 +-
net/ipv6/route.c | 71 ++-
net/ipv6/tcp_ipv6.c | 4 -
net/key/af_key.c | 2 +-
net/l2tp/l2tp_ip.c | 8 +-
net/mac80211/ibss.c | 4 +-
net/mac80211/ieee80211_i.h | 2 +-
net/mac80211/iface.c | 4 +-
net/mac80211/mlme.c | 2 +-
net/mac80211/rx.c | 10 +-
net/mac80211/tx.c | 3 +-
net/netfilter/ipvs/ip_vs_core.c | 11 -
net/netfilter/ipvs/ip_vs_ctl.c | 56 +--
net/netfilter/ipvs/ip_vs_ftp.c | 2 -
net/netfilter/ipvs/ip_vs_lblc.c | 3 -
net/netfilter/ipvs/ip_vs_lblcr.c | 3 -
net/netfilter/ipvs/ip_vs_proto.c | 38 +-
net/netfilter/ipvs/ip_vs_proto_sctp.c | 5 +-
net/netfilter/ipvs/ip_vs_proto_tcp.c | 5 +-
net/netfilter/ipvs/ip_vs_proto_udp.c | 5 +-
net/netfilter/xt_CT.c | 2 +-
net/phonet/pn_dev.c | 21 +-
net/sched/sch_gred.c | 7 +-
net/sched/sch_netem.c | 6 +-
net/sunrpc/clnt.c | 50 +--
net/sunrpc/rpc_pipe.c | 3 +-
net/sunrpc/sunrpc_syms.c | 17 +-
net/wireless/util.c | 2 +-
scripts/mod/file2alias.c | 4 -
sound/pci/hda/patch_realtek.c | 1 -
sound/soc/blackfin/bf5xx-ssm2602.c | 2 -
sound/soc/codecs/cs42l73.c | 2 -
sound/soc/codecs/tlv320aic23.c | 4 +-
sound/soc/codecs/wm8350.c | 11 +-
sound/soc/codecs/wm8994.c | 276 +++---------
sound/soc/codecs/wm_hubs.c | 15 +-
sound/soc/omap/omap-pcm.c | 4 -
sound/soc/samsung/s3c2412-i2s.c | 2 +-
sound/soc/sh/fsi.c | 7 +-
sound/soc/soc-core.c | 7 +-
sound/soc/soc-dapm.c | 2 -
tools/perf/Makefile | 4 +-
tools/perf/builtin-report.c | 17 +-
tools/perf/builtin-test.c | 30 --
tools/perf/util/parse-events.l | 2 +-
tools/perf/util/symbol.c | 13 +-
tools/testing/ktest/ktest.pl | 12 +-
552 files changed, 4698 insertions(+), 6763 deletions(-)
delete mode 100644 Documentation/ABI/testing/sysfs-bus-hsi
rename Documentation/devicetree/bindings/ata/{ahci-platform.txt => calxeda-sata.txt} (90%)
delete mode 100644 arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi
delete mode 100644 drivers/tty/serial/68328serial.h
create mode 100644 drivers/tty/serial/8250/8250_em.c
create mode 100644 include/linux/of_serial.h
---------------
Alan Cox (7):
vt: push the tty_lock down into the map handling
tty_lock: undo the old tty_lock use on the ctty
pty: Lock the devpts bits privately
tty_lock: Localise the lock
tty: drop the pty lock during hangup
tty: Allow uart_register/unregister/register
tty: Fix LED error return
Arnaud Patard (1):
8250_pci: fix pch uart matching
Christian Melki (1):
8250.c: less than 2400 baud fix.
Corbin Atkinson (1):
serial_core: Update buffer overrun statistics.
Dan Carpenter (1):
tty: hvc_xen: NULL dereference on allocation failure
Dan Williams (2):
tegra, serial8250: add ->handle_break() uart_port op
serial/8250_pci: fix suspend/resume vs init/exit quirks
Geert Uytterhoeven (1):
tty/amiserial: Add missing argument for tty_unlock()
Govindraj.R (1):
OMAP2+: UART: Remove cpu checks for populating errata flags
Greg Kroah-Hartman (1):
Revert "serial_core: Update buffer overrun statistics."
H Hartley Sweeten (1):
tty: mxser: local variables should not be exposed globally
Heiko Carstens (1):
tty: add missing tty_port_tty_get() call to raw3215_wakeup
Ivo Sieben (1):
tty: move global ldisc idle waitqueue to the individual ldisc
Jiri Slaby (71):
TTY: crisv10, remove unused tmp_buf
TTY: crisv10, initialize tty_port
TTY: deprecate linux/generic_serial.h
ISDN: i4l, remove cvs crap
TTY: isdn, remove callout
TTY: isdn, remove ISDN_ASYNC_* flags
TTY: isdn, do not play with module refcounts
TTY: isdn, make some functions readable
TTY: isdn, remove unused members from modem_info
TTY: isdn, add tty_port
TTY: isdn, use open/close_wait from tty_port
TTY: isdn, use counts from tty_port
TTY: isdn, use tty from tty_port
TTY: isdn, use xmit_buf from tty_port
TTY: isdn, define local tty_port
TTY: isdn, use tty_port_close_end helper
TTY: isdn, define tty_port_operations
TTY: isdn, use tty_port_block_til_ready helper
TTY: hso, do not set TTY MAGIC
TTY: hso, free tty_driver
TTY: hso, add tty_port
TTY: hso, remove tty NULL checks fro tty->ops
TTY: hso, use tty from tty_port
TTY: con3215, centralize allocation
TTY: sclp_tty, add tty_port
TTY: sclp_vt220, add tty_port
TTY: sclp_vt220, remove unused allocation
TTY: tty3270, move initialization to allocation
TTY: tty3270, get rid of ugly aliasing
TTY: tty3270, push tty down to tty3270_do_write
TTY: tty3270, add tty_port
TTY: bfin_jtag_comm, add tty_port
TTY: bfin_jtag_comm, use tty from tty_port
TTY: HVC, add tty_port
TTY: HVC, use tty from tty_port
TTY: HVC, use count from tty_port
TTY: hvcs, add tty_port
TTY: hvcs, use kref from tty_port
TTY: hvcs, use tty from tty_port
TTY: hvsi, CLOCAL is not in tty->flags
TTY: hvsi, add tty_port
TTY: hvsi, sanitize uses of tty
TTY: hvsi, use tty from tty_port
TTY: ipwireless, use synchronous hangup
TTY: ipwireless, move prints to appropriate places
TTY: ipwireless, add tty_port
TTY: ipwireless, use tty from tty_port
TTY: 68328serial, remove serial_state and friends
TTY: 68328serial, remove unused stuff from m68k_serial
TTY: 68328serial, remove garbage
TTY: 68328serial, use ulong flags for interrupts status
TTY: 68328serial, remove 68328serial.h
TTY: 68328serial, add tty_port
TTY: 68328serial, use open/close_wait from tty_port
TTY: 68328serial, use close_delay/closing_wait from tty_port
TTY: 68328serial, use flags from tty_port
TTY: 68328serial, propagate tty
TTY: 68328serial, use tty from tty_port
TTY: 68328serial, use tty_port_block_til_ready
TTY: usb/u_serial, add tty_port
TTY: usb/u_serial, use tty from tty_port
TTY: usb/u_serial use close_wait from tty_port
TTY: rfcomm/tty, add tty_port
TTY: rfcomm/tty, use tty_port refcounting
TTY: rfcomm/tty, remove work for tty_wakeup
TTY: rfcomm/tty, use count from tty_port
ISDN: remove uses of isdn_tty_revision
TTY: hvc, fix TTY refcounting
TTY: con3215, add tty_port
TTY: con3215, use tty from tty_port
TTY: n_tty, do not dereference user buffer
Lothar Waßmann (1):
Add missing call to uart_update_timeout()
Magnus Damm (8):
serial8250: Add dl_read()/dl_write() callbacks
serial8250: Use dl_read()/dl_write() on Alchemy
serial8250: Use dl_read()/dl_write() on RM9K
serial8250: Clean up default map and dl code
serial8250: Introduce serial8250_register_8250_port()
serial8250-em: Emma Mobile UART driver V2
serial8250-em: clk_get() IS_ERR() error handling fix
serial8250-em: Add DT support
Michael Gehring (1):
tty/vt: handle bad user buffer in {G,P}IO_CMAP ioctl
Paul Gortmaker (1):
cris: fix missing tty arg in wait_event_interruptible_tty call
Rajanikanth H.V (1):
serial: pl011: implement workaround for CTS clear event issue
Sonic Zhang (4):
serial: bfin_uart: Adapt bf5xx serial driver to bf60x serial4 controller.
serial: bfin_uart: narrow the reboot condition in DMA tx interrupt
serial: bfin_uart: RTS and CTS MMRs can be either 16-bit width or 32-bit width.
serial: bfin_uart: Make MMR access compatible with 32 bits bf609 style controller.
Sudhakar Mamillapalli (1):
serial/8250_pci: Clear FIFOs for Intel ME Serial Over Lan device on BI
Tomoya MORINAGA (7):
pch_uart: Delete unused structure member
pch_uart: change type to u8
pch_uart: change type to %d to %02x
pch_uart: Support modem status interrupt
pch_uart: delete unused data structure
pch_uart: Fix return value issue
pch_uart: Fix duplicate memory release issue
Xiaobing Tu (1):
tty: hold lock across tty buffer finding and buffer filling
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox