* Re: [PATCH 2/2] tty: serial core: use the ACPI PM state defines
From: Alan Cox @ 2012-12-06 19:31 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-serial, Greg Kroah-Hartman, Len Brown, Rafael J. Wysocki,
Rickard Andersson, linux-acpi, Linus Walleij
In-Reply-To: <1354819612-2401-1-git-send-email-linus.walleij@stericsson.com>
On Thu, 6 Dec 2012 19:46:52 +0100
Linus Walleij <linus.walleij@stericsson.com> wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> The Documentation/serial/driver file defines that:
>
> State indicates the new state (defined by ACPI D0-D3),
> oldstate indicates the previous state. Essentially, D0
> means fully on, D3 means powered down.
>
> So let's change the code to actually using the defined ACPI
> states instead of using magic numbers.
The "magic numbers" being "1" to mean one, "2" to mean two etc..
Almost none of the platforms using the serial driver even have ACPI so
this seems to be an obfuscation of a simple numbering system for a
subsystem specific set of definitions that may or may not fit in future.
What are you going to do if it turns out serial ports on some platform
have a state that doesn't fit ACPI_STATE_foo because its got a
behaviour that isn't in the ACPI specification ?
This seems to be tying stuff together in a way that will just cause
future pain.
Alan
^ permalink raw reply
* Re: [PATCH 2/2] tty: serial core: use the ACPI PM state defines
From: Alan Cox @ 2012-12-06 19:40 UTC (permalink / raw)
To: Linus Walleij
Cc: Alan Cox, Linus Walleij, linux-serial, Greg Kroah-Hartman,
Len Brown, Rafael J. Wysocki, Rickard Andersson, linux-acpi
In-Reply-To: <CACRpkdaFaL9jm9Je2NO_m+=-JgN02_s8=W8=t+TcHxn0ro2ojg@mail.gmail.com>
On Thu, 6 Dec 2012 20:31:15 +0100
Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Dec 6, 2012 at 8:31 PM, Alan Cox <alan@linux.intel.com> wrote:
>
> > Almost none of the platforms using the serial driver even have ACPI so
> > this seems to be an obfuscation of a simple numbering system for a
> > subsystem specific set of definitions that may or may not fit in future.
>
> OK so we need to get away from using the ACPI numbering scheme.
So whats wrong with 0 1 2 3 ?
^ permalink raw reply
* [PATCH] tty: serial core: decouple pm states from ACPI
From: Linus Walleij @ 2012-12-06 19:59 UTC (permalink / raw)
To: linux-serial, Greg Kroah-Hartman
Cc: Alan Cox, Rickard Andersson, linux-acpi, Linus Walleij
From: Linus Walleij <linus.walleij@linaro.org>
The serial core is using power states lifted from ACPI for no
good reason. Remove this reference from the documentation and
alter all users to use an enum specific to the serial core
instead, and define it in <linux/serial_core.h>.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
Alan think that depending on ACPI for PM states is a bad idea,
so let's instead create our own definition of the PM states for
the tty/serial subsystem. (Ditch the other two patches.)
---
Documentation/serial/driver | 5 ++---
drivers/tty/serial/serial_core.c | 30 ++++++++++++++++--------------
include/linux/serial_core.h | 14 +++++++++++++-
3 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 0a25a91..a6ef8dc 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -242,9 +242,8 @@ hardware.
pm(port,state,oldstate)
Perform any power management related activities on the specified
- port. State indicates the new state (defined by ACPI D0-D3),
- oldstate indicates the previous state. Essentially, D0 means
- fully on, D3 means powered down.
+ port. State indicates the new state (defined by
+ enum uart_pm_state), oldstate indicates the previous state.
This function should not be used to grab any resources.
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 2c7230a..11b23e2 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -59,7 +59,8 @@ static struct lock_class_key port_lock_key;
static void uart_change_speed(struct tty_struct *tty, struct uart_state *state,
struct ktermios *old_termios);
static void uart_wait_until_sent(struct tty_struct *tty, int timeout);
-static void uart_change_pm(struct uart_state *state, int pm_state);
+static void uart_change_pm(struct uart_state *state,
+ enum uart_pm_state pm_state);
static void uart_port_shutdown(struct tty_port *port);
@@ -1365,7 +1366,7 @@ static void uart_close(struct tty_struct *tty, struct file *filp)
spin_lock_irqsave(&port->lock, flags);
} else if (!uart_console(uport)) {
spin_unlock_irqrestore(&port->lock, flags);
- uart_change_pm(state, 3);
+ uart_change_pm(state, UART_PM_STATE_SLEEP);
spin_lock_irqsave(&port->lock, flags);
}
@@ -1579,7 +1580,7 @@ static int uart_open(struct tty_struct *tty, struct file *filp)
* Make sure the device is in D0 state.
*/
if (port->count == 1)
- uart_change_pm(state, 0);
+ uart_change_pm(state, UART_PM_STATE_DEFAULT);
/*
* Start up the serial port.
@@ -1620,7 +1621,7 @@ static void uart_line_info(struct seq_file *m, struct uart_driver *drv, int i)
{
struct uart_state *state = drv->state + i;
struct tty_port *port = &state->port;
- int pm_state;
+ enum uart_pm_state pm_state;
struct uart_port *uport = state->uart_port;
char stat_buf[32];
unsigned int status;
@@ -1645,12 +1646,12 @@ static void uart_line_info(struct seq_file *m, struct uart_driver *drv, int i)
if (capable(CAP_SYS_ADMIN)) {
mutex_lock(&port->mutex);
pm_state = state->pm_state;
- if (pm_state)
- uart_change_pm(state, 0);
+ if (pm_state != UART_PM_STATE_DEFAULT)
+ uart_change_pm(state, UART_PM_STATE_DEFAULT);
spin_lock_irq(&uport->lock);
status = uport->ops->get_mctrl(uport);
spin_unlock_irq(&uport->lock);
- if (pm_state)
+ if (pm_state != UART_PM_STATE_DEFAULT)
uart_change_pm(state, pm_state);
mutex_unlock(&port->mutex);
@@ -1897,7 +1898,8 @@ EXPORT_SYMBOL_GPL(uart_set_options);
*
* Locking: port->mutex has to be held
*/
-static void uart_change_pm(struct uart_state *state, int pm_state)
+static void uart_change_pm(struct uart_state *state,
+ enum uart_pm_state pm_state)
{
struct uart_port *port = state->uart_port;
@@ -1982,7 +1984,7 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
console_stop(uport->cons);
if (console_suspend_enabled || !uart_console(uport))
- uart_change_pm(state, 3);
+ uart_change_pm(state, UART_PM_STATE_SLEEP);
mutex_unlock(&port->mutex);
@@ -2027,7 +2029,7 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
termios = port->tty->termios;
if (console_suspend_enabled)
- uart_change_pm(state, 0);
+ uart_change_pm(state, UART_PM_STATE_DEFAULT);
uport->ops->set_termios(uport, &termios, NULL);
if (console_suspend_enabled)
console_start(uport->cons);
@@ -2037,7 +2039,7 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
const struct uart_ops *ops = uport->ops;
int ret;
- uart_change_pm(state, 0);
+ uart_change_pm(state, UART_PM_STATE_DEFAULT);
spin_lock_irq(&uport->lock);
ops->set_mctrl(uport, 0);
spin_unlock_irq(&uport->lock);
@@ -2137,7 +2139,7 @@ uart_configure_port(struct uart_driver *drv, struct uart_state *state,
uart_report_port(drv, port);
/* Power up port for set_mctrl() */
- uart_change_pm(state, 0);
+ uart_change_pm(state, UART_PM_STATE_DEFAULT);
/*
* Ensure that the modem control lines are de-activated.
@@ -2161,7 +2163,7 @@ uart_configure_port(struct uart_driver *drv, struct uart_state *state,
* console if we have one.
*/
if (!uart_console(port))
- uart_change_pm(state, 3);
+ uart_change_pm(state, UART_PM_STATE_SLEEP);
}
}
@@ -2588,7 +2590,7 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
}
state->uart_port = uport;
- state->pm_state = -1;
+ state->pm_state = UART_PM_STATE_UNDEFINED;
uport->cons = drv->cons;
uport->state = state;
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index c6690a2..d1fd0af 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -208,13 +208,25 @@ static inline void serial_port_out(struct uart_port *up, int offset, int value)
up->serial_out(up, offset, value);
}
+/**
+ * enum uart_pm_state - power states for UARTs
+ * @UART_PM_STATE_DEFAULT: UART is powered, up and operational
+ * @UART_PM_STATE_SLEEP: UART is powered off
+ * @UART_PM_STATE_UNDEFINED: sentinel
+ */
+enum uart_pm_state {
+ UART_PM_STATE_DEFAULT = 0,
+ UART_PM_STATE_SLEEP = 3,
+ UART_PM_STATE_UNDEFINED,
+};
+
/*
* This is the state information which is persistent across opens.
*/
struct uart_state {
struct tty_port port;
- int pm_state;
+ enum uart_pm_state pm_state;
struct circ_buf xmit;
struct uart_port *uart_port;
--
1.7.11.3
^ permalink raw reply related
* Re: [PATCH 2/2] tty: serial core: use the ACPI PM state defines
From: Linus Walleij @ 2012-12-06 20:05 UTC (permalink / raw)
To: Alan Cox
Cc: Alan Cox, Linus Walleij, linux-serial, Greg Kroah-Hartman,
Len Brown, Rafael J. Wysocki, Rickard Andersson, linux-acpi
In-Reply-To: <20121206194040.0c79e7e8@pyramind.ukuu.org.uk>
On Thu, Dec 6, 2012 at 8:40 PM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Thu, 6 Dec 2012 20:31:15 +0100
> Linus Walleij <linus.walleij@linaro.org> wrote:
>
>> On Thu, Dec 6, 2012 at 8:31 PM, Alan Cox <alan@linux.intel.com> wrote:
>>
>> > Almost none of the platforms using the serial driver even have ACPI so
>> > this seems to be an obfuscation of a simple numbering system for a
>> > subsystem specific set of definitions that may or may not fit in future.
>>
>> OK so we need to get away from using the ACPI numbering scheme.
>
> So whats wrong with 0 1 2 3 ?
Mainly what is wrong is the documentation that says that this correlates
to the ACPI D-states.
But we're working to get a serial driver power aware and need to
start to let device drivers go to different power states, and then
we need to let the core handle not only state 0 and 3 (as it is
using today) but also 1 and 2 (currently not used in the serial
core). And if several device drivers shall do that it could be a
good idea to have some idea of what the numbers actually
mean, roughly atleast.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/2] tty: serial core: use the ACPI PM state defines
From: Rafael J. Wysocki @ 2012-12-06 20:57 UTC (permalink / raw)
To: linux-acpi
Cc: Linus Walleij, Alan Cox, Linus Walleij, linux-serial,
Greg Kroah-Hartman, Len Brown, Rickard Andersson
In-Reply-To: <CACRpkdaFaL9jm9Je2NO_m+=-JgN02_s8=W8=t+TcHxn0ro2ojg@mail.gmail.com>
On Thursday, December 06, 2012 08:31:15 PM Linus Walleij wrote:
> On Thu, Dec 6, 2012 at 8:31 PM, Alan Cox <alan@linux.intel.com> wrote:
>
> > Almost none of the platforms using the serial driver even have ACPI so
> > this seems to be an obfuscation of a simple numbering system for a
> > subsystem specific set of definitions that may or may not fit in future.
>
> OK so we need to get away from using the ACPI numbering scheme.
> What about we define something in the <linux/tty.h> file instead
> and delete the paragraph from the documentation saying it is related
> to ACPI? (Will try this next.)
Deleting that paragraph would be fine by me, FWIW.
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH] tty: serial core: decouple pm states from ACPI
From: Rafael J. Wysocki @ 2012-12-06 21:02 UTC (permalink / raw)
To: linux-acpi
Cc: Linus Walleij, linux-serial, Greg Kroah-Hartman, Alan Cox,
Rickard Andersson, Linus Walleij
In-Reply-To: <1354823954-6073-1-git-send-email-linus.walleij@stericsson.com>
On Thursday, December 06, 2012 08:59:14 PM Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> The serial core is using power states lifted from ACPI for no
> good reason. Remove this reference from the documentation and
> alter all users to use an enum specific to the serial core
> instead, and define it in <linux/serial_core.h>.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> Alan think that depending on ACPI for PM states is a bad idea,
> so let's instead create our own definition of the PM states for
> the tty/serial subsystem. (Ditch the other two patches.)
> ---
> Documentation/serial/driver | 5 ++---
> drivers/tty/serial/serial_core.c | 30 ++++++++++++++++--------------
> include/linux/serial_core.h | 14 +++++++++++++-
> 3 files changed, 31 insertions(+), 18 deletions(-)
>
> diff --git a/Documentation/serial/driver b/Documentation/serial/driver
> index 0a25a91..a6ef8dc 100644
> --- a/Documentation/serial/driver
> +++ b/Documentation/serial/driver
> @@ -242,9 +242,8 @@ hardware.
>
> pm(port,state,oldstate)
> Perform any power management related activities on the specified
> - port. State indicates the new state (defined by ACPI D0-D3),
> - oldstate indicates the previous state. Essentially, D0 means
> - fully on, D3 means powered down.
> + port. State indicates the new state (defined by
> + enum uart_pm_state), oldstate indicates the previous state.
>
> This function should not be used to grab any resources.
>
> diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> index 2c7230a..11b23e2 100644
> --- a/drivers/tty/serial/serial_core.c
> +++ b/drivers/tty/serial/serial_core.c
> @@ -59,7 +59,8 @@ static struct lock_class_key port_lock_key;
> static void uart_change_speed(struct tty_struct *tty, struct uart_state *state,
> struct ktermios *old_termios);
> static void uart_wait_until_sent(struct tty_struct *tty, int timeout);
> -static void uart_change_pm(struct uart_state *state, int pm_state);
> +static void uart_change_pm(struct uart_state *state,
> + enum uart_pm_state pm_state);
>
> static void uart_port_shutdown(struct tty_port *port);
>
> @@ -1365,7 +1366,7 @@ static void uart_close(struct tty_struct *tty, struct file *filp)
> spin_lock_irqsave(&port->lock, flags);
> } else if (!uart_console(uport)) {
> spin_unlock_irqrestore(&port->lock, flags);
> - uart_change_pm(state, 3);
> + uart_change_pm(state, UART_PM_STATE_SLEEP);
> spin_lock_irqsave(&port->lock, flags);
> }
>
> @@ -1579,7 +1580,7 @@ static int uart_open(struct tty_struct *tty, struct file *filp)
> * Make sure the device is in D0 state.
> */
> if (port->count == 1)
> - uart_change_pm(state, 0);
> + uart_change_pm(state, UART_PM_STATE_DEFAULT);
>
> /*
> * Start up the serial port.
> @@ -1620,7 +1621,7 @@ static void uart_line_info(struct seq_file *m, struct uart_driver *drv, int i)
> {
> struct uart_state *state = drv->state + i;
> struct tty_port *port = &state->port;
> - int pm_state;
> + enum uart_pm_state pm_state;
> struct uart_port *uport = state->uart_port;
> char stat_buf[32];
> unsigned int status;
> @@ -1645,12 +1646,12 @@ static void uart_line_info(struct seq_file *m, struct uart_driver *drv, int i)
> if (capable(CAP_SYS_ADMIN)) {
> mutex_lock(&port->mutex);
> pm_state = state->pm_state;
> - if (pm_state)
> - uart_change_pm(state, 0);
> + if (pm_state != UART_PM_STATE_DEFAULT)
> + uart_change_pm(state, UART_PM_STATE_DEFAULT);
> spin_lock_irq(&uport->lock);
> status = uport->ops->get_mctrl(uport);
> spin_unlock_irq(&uport->lock);
> - if (pm_state)
> + if (pm_state != UART_PM_STATE_DEFAULT)
> uart_change_pm(state, pm_state);
> mutex_unlock(&port->mutex);
>
> @@ -1897,7 +1898,8 @@ EXPORT_SYMBOL_GPL(uart_set_options);
> *
> * Locking: port->mutex has to be held
> */
> -static void uart_change_pm(struct uart_state *state, int pm_state)
> +static void uart_change_pm(struct uart_state *state,
> + enum uart_pm_state pm_state)
> {
> struct uart_port *port = state->uart_port;
>
> @@ -1982,7 +1984,7 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
> console_stop(uport->cons);
>
> if (console_suspend_enabled || !uart_console(uport))
> - uart_change_pm(state, 3);
> + uart_change_pm(state, UART_PM_STATE_SLEEP);
>
> mutex_unlock(&port->mutex);
>
> @@ -2027,7 +2029,7 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
> termios = port->tty->termios;
>
> if (console_suspend_enabled)
> - uart_change_pm(state, 0);
> + uart_change_pm(state, UART_PM_STATE_DEFAULT);
> uport->ops->set_termios(uport, &termios, NULL);
> if (console_suspend_enabled)
> console_start(uport->cons);
> @@ -2037,7 +2039,7 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
> const struct uart_ops *ops = uport->ops;
> int ret;
>
> - uart_change_pm(state, 0);
> + uart_change_pm(state, UART_PM_STATE_DEFAULT);
> spin_lock_irq(&uport->lock);
> ops->set_mctrl(uport, 0);
> spin_unlock_irq(&uport->lock);
> @@ -2137,7 +2139,7 @@ uart_configure_port(struct uart_driver *drv, struct uart_state *state,
> uart_report_port(drv, port);
>
> /* Power up port for set_mctrl() */
> - uart_change_pm(state, 0);
> + uart_change_pm(state, UART_PM_STATE_DEFAULT);
>
> /*
> * Ensure that the modem control lines are de-activated.
> @@ -2161,7 +2163,7 @@ uart_configure_port(struct uart_driver *drv, struct uart_state *state,
> * console if we have one.
> */
> if (!uart_console(port))
> - uart_change_pm(state, 3);
> + uart_change_pm(state, UART_PM_STATE_SLEEP);
> }
> }
>
> @@ -2588,7 +2590,7 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
> }
>
> state->uart_port = uport;
> - state->pm_state = -1;
> + state->pm_state = UART_PM_STATE_UNDEFINED;
>
> uport->cons = drv->cons;
> uport->state = state;
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index c6690a2..d1fd0af 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -208,13 +208,25 @@ static inline void serial_port_out(struct uart_port *up, int offset, int value)
> up->serial_out(up, offset, value);
> }
>
> +/**
> + * enum uart_pm_state - power states for UARTs
> + * @UART_PM_STATE_DEFAULT: UART is powered, up and operational
> + * @UART_PM_STATE_SLEEP: UART is powered off
> + * @UART_PM_STATE_UNDEFINED: sentinel
> + */
> +enum uart_pm_state {
> + UART_PM_STATE_DEFAULT = 0,
> + UART_PM_STATE_SLEEP = 3,
Might as well call this one UART_PM_STATE_OFF (and the default one _ON).
Otherwise, it looks OK.
> + UART_PM_STATE_UNDEFINED,
> +};
> +
> /*
> * This is the state information which is persistent across opens.
> */
> struct uart_state {
> struct tty_port port;
>
> - int pm_state;
> + enum uart_pm_state pm_state;
> struct circ_buf xmit;
>
> struct uart_port *uart_port;
>
Thanks,
Rafael
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply
* Re: [PATCH 2/2] tty: serial core: use the ACPI PM state defines
From: Alan Cox @ 2012-12-06 23:36 UTC (permalink / raw)
To: Linus Walleij
Cc: Linus Walleij, linux-serial, Greg Kroah-Hartman, Len Brown,
Rafael J. Wysocki, Rickard Andersson, linux-acpi
In-Reply-To: <CACRpkdaFaL9jm9Je2NO_m+=-JgN02_s8=W8=t+TcHxn0ro2ojg@mail.gmail.com>
On Thu, 6 Dec 2012 20:31:15 +0100
Linus Walleij <linus.walleij@linaro.org> wrote:
> On Thu, Dec 6, 2012 at 8:31 PM, Alan Cox <alan@linux.intel.com> wrote:
>
> > Almost none of the platforms using the serial driver even have ACPI
> > so this seems to be an obfuscation of a simple numbering system for
> > a subsystem specific set of definitions that may or may not fit in
> > future.
>
> OK so we need to get away from using the ACPI numbering scheme.
> What about we define something in the <linux/tty.h> file instead
> and delete the paragraph from the documentation saying it is related
> to ACPI? (Will try this next.)
What about just using 0, 1, 2, 3 to indicate states similar to D0-D3
which as a base concept everyone is familiar with ?
If we need something more than that, then can we talk about what the
actual extra non 0/3 states needed are and how to get a generic
meaningful definition, or indeed whether a number rather than flag bits
makes sense ?
Start with the driver/platform that causes the concern and then the
rest is probably blindingly obvious.
Alan
^ permalink raw reply
* Re: [PATCH -next 0/9] tty: Fix buffer work access-after-free
From: Peter Hurley @ 2012-12-07 0:57 UTC (permalink / raw)
To: Alan Cox
Cc: Jiri Slaby, Greg Kroah-Hartman, linux-serial, linux-kernel,
Sasha Levin
In-Reply-To: <1354604865-10278-1-git-send-email-peter@hurleysoftware.com>
On Tue, 2012-12-04 at 02:07 -0500, Peter Hurley wrote:
> This patch series addresses the causes of flush_to_ldisc accessing
> the tty after freeing.
Well, there's going to be a v2 of this series.
Sasha found that PATCH 3/9 is an insufficient fix. I've already worked
out the correct solution but I've been plagued by the kswapd/flush
problem so that's making this more challenging then it ought to be.
Plus I tripped across a GP fault in the SLUB allocator which turns out
to be a free list corruption (probably because of the low memory
condition brought on by the kswapd problem. Good times...)
There is also going to be a v3 because I just came up with an idea to
clean up the whole ldisc ref situation, but I'm going to take some time
testing it out first.
Anyway, just wanted to hold this off for another respin.
Regards,
Peter Hurley
^ permalink raw reply
* Re: [PATCH] synclink fix ldisc buffer argument
From: Chen Gang @ 2012-12-07 2:15 UTC (permalink / raw)
To: Paul Fulghum; +Cc: Greg KH, Linux Kernel Mailing List, linux-serial, Alan Cox
In-Reply-To: <50BCDDB4.6010608@microgate.com>
Hello Greg Kroah-Hartman:
于 2012年12月04日 01:13, Paul Fulghum 写道:
> Fix call to line discipline receive_buf by synclink drivers.
> Dummy flag buffer argument is ignored by N_HDLC line discipline but might
> be of insufficient size if accessed by a different line discipline
> selected by mistake. flag buffer allocation now matches max size of data
> buffer. Unused char_buf buffers are removed.
>
> Signed-off-by: Paul Fulghum <paulkf@microgate.com>
if no additional questions:
is it suitable to let this patch pass checking ?
at least for me, it is surely solve an issue, and no negative effect.
now, maybe Paul Fulghum is busy...
the left questions what I have sent seems minor.
so they can be delayed, until he has free time.
when Paul Fulghum has free time.
can still check what my left questions whether valid.
if they are valid, can send additional patch for them.
is it OK ?
Regards
--
Chen Gang
Asianux Corporation
--
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: [RFC PATCH v3 1/4] UART: Add UART subsystem as a bus.
From: Zheng, Lv @ 2012-12-07 3:52 UTC (permalink / raw)
To: Alan Cox
Cc: Brown, Len, Wysocki, Rafael J, Greg Kroah-Hartman,
Mika Westerberg, linux-acpi@vger.kernel.org,
linux-serial@vger.kernel.org,
H. Peter Anvin (hpa@linux.intel.com)
In-Reply-To: <20121206134020.0747af0f@bob.linux.org.uk>
> > enumerated and userspace can obtain the hotplug event of the UART
> > target devices. Linux kernel is lack of an overall enumeration
> > mechanism for UART target devices.
>
> ls /sys/class/tty/
I'm searching for a target "physical" device while the "tty device" looks more like a "functional" device.
IMO, an ideal driver model is:
Creating a strict IO topology for all of the physical buses w/ physical devices created within this hierarchy, then make the abstract things "class devices", including the "functional devices" and the "filter devices".
The examples of the "physical devices": platform device, uart_device, i2c_client, spi_device
The examples of the "functional devices": tty device, i2c_adapter, spi_master
The examples of the "filter devices": ppp device
If this rule is strictly obeyed by all of the subsystems, then:
1. the hardware PM can be added to the physical devices
2. the functional devices will inc/dec the PM reference count for the physical devices <- this can help to add request based runtime PM
3. the other filter devices/drivers can call the APIs provided by the functional devices, some of them may affect the PM ref count.
Implementing OS guided power management might be simpler:
1. if a bus offered PM support, it should appear in the bus_type
2. if a platform offered PM support, it should appear as PM_domain
Currently, Linux allows enabling of PM support for device_type, if things are cleaned up, the use of device_type PM can be reduced.
If a device was handling hardware stuff including the PM, it should be a "physical device".
If a device was offering communication means, it should be a "functional device".
If a device was using the communication means, it should be a "filter device".
So how could a tty device be a physical device? If we enable PM for it, dpm_list order will be crushed, issues might occur on system suspending/resuming.
> > In order to send uevent, a device need to be a class device or a bus
> > device. This patch introduces a bus_type subsystem to manage the new
>
> I still don't see why the existing tty class interfaces cannot be used, the hints
> from ACPI (or anywhere else) cannot be attached as properties to the tty driver
> and device sysfs
I checked the PM call chain, then found the followings:
On system suspending:
adapter.suspend -> for_each_port(uart_suspend_port) -> uart_change_pm(3) -> uart_ops->pm -> uart_port->pm
On system resuming:
adapter.resume -> for_each_port(uart_resume_port) -> uart_change_pm(0) -> uart_ops->pm -> uart_port->pm
Where the adapter could be platform devices.
On tty file opening:
uart_open -> uart_change_pm(0) -> uart_ops->pm -> uart_port->pm
On tty file closing:
uart_close -> uart_change_pm(3) -> uart_ops->pm -> uart_port->pm
And I checked the PM implementation, most of the drivers will enable/disable the "HOST" side port clock there and only few of them will lower the required terminal lines to tell the target devices to enter a low power state.
So I was just thinking if the tty device was used as physical device in the community, it might be used as "host" side physical device, and my patch was trying to enable a "target" side physical device.
Adding driver support for such "target physical uart device" sounds a good idea. But I need an explicit approval for adding the kernel resident driver.
Best regards
-Lv
^ permalink raw reply
* [PATCHv2 1/2] tty/8250: pbn_b0_8_1152000_200 is supposed to be an 8 port definition
From: matts_old @ 2012-12-07 4:19 UTC (permalink / raw)
To: linux-serial; +Cc: alan, greg, Matt Schulte
From: Matt Schulte <matts@commtech-fastcom.com>
tty/8250: pbn_b0_8_1152000_200 is supposed to be an 8 port definition
Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
---
Built against tty-next commit: b0ab02361167faa82198b783a8d555eb6f58901c
v2: Reorder define in patch 2 as requested by Alan
drivers/tty/serial/8250/8250_pci.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index 26b9dc0..bf2f1a0 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -2246,7 +2246,7 @@ static struct pciserial_board pci_boards[] = {
[pbn_b0_8_1152000_200] = {
.flags = FL_BASE0,
- .num_ports = 2,
+ .num_ports = 8,
.base_baud = 1152000,
.uart_offset = 0x200,
},
--
1.7.2.5
^ permalink raw reply related
* [PATCHv2 2/2] tty/8250: The correct device id for this card is 0x0022
From: matts_old @ 2012-12-07 4:19 UTC (permalink / raw)
To: linux-serial; +Cc: alan, greg, Matt Schulte
In-Reply-To: <1354853999-6789-1-git-send-email-matts@commtech-fastcom.com>
From: Matt Schulte <matts@commtech-fastcom.com>
The correct device id for this card is 0x0022
Signed-off-by: Matt Schulte <matts@commtech-fastcom.com>
---
Built against tty-next commit: b0ab02361167faa82198b783a8d555eb6f58901c
v2: Reorder define in patch 2 as requested by Alan
drivers/tty/serial/8250/8250_pci.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
index bf2f1a0..8a2c3d9 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1301,9 +1301,9 @@ pci_wch_ch353_setup(struct serial_private *priv,
#define PCI_VENDOR_ID_AGESTAR 0x5372
#define PCI_DEVICE_ID_AGESTAR_9375 0x6872
#define PCI_VENDOR_ID_ASIX 0x9710
-#define PCI_DEVICE_ID_COMMTECH_4222PCIE 0x0019
#define PCI_DEVICE_ID_COMMTECH_4224PCIE 0x0020
#define PCI_DEVICE_ID_COMMTECH_4228PCIE 0x0021
+#define PCI_DEVICE_ID_COMMTECH_4222PCIE 0x0022
/* Unknown vendors/cards - this should not be in linux/pci_ids.h */
--
1.7.2.5
^ permalink raw reply related
* RE: [RFC PATCH 1/3] UART: Add UART subsystem as a bus.
From: Zheng, Lv @ 2012-12-07 4:54 UTC (permalink / raw)
To: Alan Cox
Cc: Mika Westerberg, Alan Cox, Brown, Len, Wysocki, Rafael J,
Greg Kroah-Hartman, linux-acpi@vger.kernel.org,
linux-serial@vger.kernel.org, Huang, Ying
In-Reply-To: <20121206135341.148b325e@pyramind.ukuu.org.uk>
> > > We just need a set of type names for the sysfs node I think
> > > "bluetooth", "ups", "loconet", "serial", "modem", "cir" etc...
> >
> > Is it a good idea to introduce uart_device driver in the kernel to fill a new
> 'ldisc' member in the uart_device or to load ldisc by default for the
> corresponding tty_port?
>
> No but it can provide information to help user space. In many cases the
> decision isn't about a line discipline but about automatically setting permissions
> or linking ports to the right driver.
>
> The hints need to be generic - they can come from open firmware, from pci
> identifiers, from ACPI and so on.
Userspace need to know more than a simple type name to match the driver.
For example,
Atheros BT will send wrapped HCI packets from their HSU BT adapters, so they need to see "ath3000" rather than "bluetooth" to load a kernel hci protocol module for the device.
As we can see, in the i2c/spi world, there is only "type" field filling w/ chip name, not 2 fields - "type" filled w/ generic type and "id" filled w/ chip name.
Userspace can figure the generic "type" from the un-generic chip name like "type".
I just wonder will there be issues caused by following this design?
> > Shall we change the uart_bus to the tty_bus, then introduce tty_host /
> tty_target for the bus?
>
> We have a tty class - is that not sufficient ?
As I mentioned in the previous mail, I'll keep the current naming rule until I see some objections strong enough.
-Lv
^ permalink raw reply
* RE: [RFC PATCH 1/3] UART: Add UART subsystem as a bus.
From: Zheng, Lv @ 2012-12-07 5:41 UTC (permalink / raw)
To: Zheng, Lv, Alan Cox
Cc: Mika Westerberg, Alan Cox, Brown, Len, Wysocki, Rafael J,
Greg Kroah-Hartman, linux-acpi@vger.kernel.org,
linux-serial@vger.kernel.org, Huang, Ying
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E88BD756A@SHSMSX101.ccr.corp.intel.com>
> > > > We just need a set of type names for the sysfs node I think
> > > > "bluetooth", "ups", "loconet", "serial", "modem", "cir" etc...
> > >
> > > Is it a good idea to introduce uart_device driver in the kernel to
> > > fill a new
> > 'ldisc' member in the uart_device or to load ldisc by default for the
> > corresponding tty_port?
> >
> > No but it can provide information to help user space. In many cases
> > the decision isn't about a line discipline but about automatically
> > setting permissions or linking ports to the right driver.
> >
> > The hints need to be generic - they can come from open firmware, from
> > pci identifiers, from ACPI and so on.
>
> Userspace need to know more than a simple type name to match the driver.
> For example,
> Atheros BT will send wrapped HCI packets from their HSU BT adapters, so they
> need to see "ath3000" rather than "bluetooth" to load a kernel hci protocol
> module for the device.
> As we can see, in the i2c/spi world, there is only "type" field filling w/ chip name,
> not 2 fields - "type" filled w/ generic type and "id" filled w/ chip name.
> Userspace can figure the generic "type" from the un-generic chip name like
> "type".
> I just wonder will there be issues caused by following this design?
Ying has suggested me to include all of the HID/CIDs as a list into board_info.
If OF need this feature, I'll split type into a type and an "ID" list.
The module_alias file can export all of the IDs and the device name can be the "type:index".
I can make the modifications on this if you think this is better.
> > > Shall we change the uart_bus to the tty_bus, then introduce tty_host
> > > /
> > tty_target for the bus?
> >
> > We have a tty class - is that not sufficient ?
>
> As I mentioned in the previous mail, I'll keep the current naming rule until I see
> some objections strong enough.
This statement is confusing in English, let me clarify this.
If the reasons for the uart_bus in the previous email are not correct, I'll change everything named as uart_xxx to tty_xxx, then the tty_bus is probably not needed, and I can use tty class after the decision.
Best regards
-Lv
^ permalink raw reply
* Re: [RFC PATCH 1/3] UART: Add UART subsystem as a bus.
From: Huang Ying @ 2012-12-07 7:24 UTC (permalink / raw)
To: Zheng, Lv, Alan Cox
Cc: Mika Westerberg, Alan Cox, Brown, Len, Wysocki, Rafael J,
Greg Kroah-Hartman, linux-acpi@vger.kernel.org,
linux-serial@vger.kernel.org
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E88BD75D2@SHSMSX101.ccr.corp.intel.com>
Hi, Alan and Lv,
On Thu, 2012-12-06 at 22:41 -0700, Zheng, Lv wrote:
[snip]
> > > > Shall we change the uart_bus to the tty_bus, then introduce tty_host
> > > > /
> > > tty_target for the bus?
> > >
> > > We have a tty class - is that not sufficient ?
> >
> > As I mentioned in the previous mail, I'll keep the current naming rule until I see
> > some objections strong enough.
>
> This statement is confusing in English, let me clarify this.
> If the reasons for the uart_bus in the previous email are not correct, I'll change everything named as uart_xxx to tty_xxx, then the tty_bus is probably not needed, and I can use tty class after the decision.
If my understanding were correct, the point is not about name it as
uart_bus or tty_bus, but why do we need a bus instead of just use tty
class for that.
If we use tty class to export tty target device information, it can be
something as follow:
$ cd /sys/devices/platform/serial8250/tty/ttyS0
$ ls
slave_type
slave_id
slave_compat_ids
slave_attr
modem_lines
If we use uart or tty bus to export tty target device information, it
can be something as follow:
$ cd /sys/devices/platform/serial8250/bluetooth:00
$ ls
type
id
compt_ids
attr
modem_lines
...
$ cd /sys/bus/(uart|tty)/devices
$ ls
bluetooth:00
Both works. But IMHO, the second one appears more natural and
consistent, just like other hardware devices in system. And create
struct device for each target devices make it easier to do power
management etc, for example, user can enable/disable runtime power
management via bluetooth:00/power/control, just like other hardware
devices.
Best Regards,
Huang Ying
^ permalink raw reply
* Re: [RFC PATCH 1/3] UART: Add UART subsystem as a bus.
From: Alan Cox @ 2012-12-07 10:25 UTC (permalink / raw)
To: Zheng, Lv
Cc: Mika Westerberg, Alan Cox, Brown, Len, Wysocki, Rafael J,
Greg Kroah-Hartman, linux-acpi@vger.kernel.org,
linux-serial@vger.kernel.org, Huang, Ying
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E88BD756A@SHSMSX101.ccr.corp.intel.com>
On Fri, 7 Dec 2012 04:54:40 +0000
"Zheng, Lv" <lv.zheng@intel.com> wrote:
> > > > We just need a set of type names for the sysfs node I think
> > > > "bluetooth", "ups", "loconet", "serial", "modem", "cir" etc...
> > >
> > > Is it a good idea to introduce uart_device driver in the kernel to fill a new
> > 'ldisc' member in the uart_device or to load ldisc by default for the
> > corresponding tty_port?
> >
> > No but it can provide information to help user space. In many cases the
> > decision isn't about a line discipline but about automatically setting permissions
> > or linking ports to the right driver.
> >
> > The hints need to be generic - they can come from open firmware, from pci
> > identifiers, from ACPI and so on.
>
> Userspace need to know more than a simple type name to match the driver.
It's just an enumeration - and unlike numbers names don't usually collide
or need hard management
> For example,
> Atheros BT will send wrapped HCI packets from their HSU BT adapters, so they need to see "ath3000" rather than "bluetooth" to load a kernel hci protocol module for the device.
Fine so we could use "bluetooth/atheros" or similar. Easily dealt with
Alan
^ permalink raw reply
* Re: [RFC PATCH v3 1/4] UART: Add UART subsystem as a bus.
From: Alan Cox @ 2012-12-07 10:22 UTC (permalink / raw)
To: Zheng, Lv
Cc: Alan Cox, Brown, Len, Wysocki, Rafael J, Greg Kroah-Hartman,
Mika Westerberg, linux-acpi@vger.kernel.org,
linux-serial@vger.kernel.org,
H. Peter Anvin (hpa@linux.intel.com)
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E88BD7485@SHSMSX101.ccr.corp.intel.com>
> > ls /sys/class/tty/
>
> I'm searching for a target "physical" device while the "tty device" looks more like a "functional" device.
We don't currently properly link that up - but we should. It does however
provide the place to attach information like modem lines and intended use.
> If this rule is strictly obeyed by all of the subsystems, then:
> 1. the hardware PM can be added to the physical devices
To get the heirarchy you need to the tty to be in the PCI bus or other
bus where it actually sits ? Consider an ACPI enumerated port whose
address space is behind a PCI bridge.
> 1. if a bus offered PM support, it should appear in the bus_type
Which would usually be the PCI bus (and an ACPI enumerated device behind
a PCI bus needs to go via PCI to keep all the PCI counts correct)
> If a device was handling hardware stuff including the PM, it should be a "physical device".
> If a device was offering communication means, it should be a "functional device".
> If a device was using the communication means, it should be a "filter device".
A tty is all three. We have the physical device (wires and pins), the
functional object (an open tty) and filters (line disciplines I guess).
> And I checked the PM implementation, most of the drivers will enable/disable the "HOST" side port clock there and only few of them will lower the required terminal lines to tell the target devices to enter a low power state.
Because generally that breaks stuff. For example if you lower the carrier
to some UPS devices they conclude the PC has been turned off. This leads
to highly undesirable behaviour. As a result it's generally been user
space that handles such details.
> So I was just thinking if the tty device was used as physical device in the community, it might be used as "host" side physical device, and my patch was trying to enable a "target" side physical device.
>
> Adding driver support for such "target physical uart device" sounds a good idea. But I need an explicit approval for
adding the kernel resident driver.
Not entirely sure what you mean by kernel resident driver here.
As of 3.7 we have a 'tty_port' for every tty. Not every port corresponds
to an actual physical device (eg pty doesn't, nor do mux channels). We
could certainly keep a bus driver reference in the tty_port if it helps.
If NULL means "none/not set" we can also gradually make drivers set it
correctly.
At that point you would be able to find the underlying device from any
tty port, and you can find any tty_port from the tty as of 3.7.
^ permalink raw reply
* Re: [RFC PATCH 1/3] UART: Add UART subsystem as a bus.
From: Alan Cox @ 2012-12-07 10:27 UTC (permalink / raw)
To: Zheng, Lv
Cc: Mika Westerberg, Alan Cox, Brown, Len, Wysocki, Rafael J,
Greg Kroah-Hartman, linux-acpi@vger.kernel.org,
linux-serial@vger.kernel.org, Huang, Ying
In-Reply-To: <1AE640813FDE7649BE1B193DEA596E88BD75D2@SHSMSX101.ccr.corp.intel.com>
> Ying has suggested me to include all of the HID/CIDs as a list into board_info.
if HID/CID values are also provided by ACPI then that makes sense
> If OF need this feature, I'll split type into a type and an "ID" list.
That would be good. Code that wants generic answers can check the type,
code that wants identifiers or needs detail can check the ids
Alan
^ permalink raw reply
* Re: [PATCH 2/2] tty: serial core: use the ACPI PM state defines
From: Linus Walleij @ 2012-12-07 10:30 UTC (permalink / raw)
To: Alan Cox
Cc: Linus Walleij, linux-serial, Greg Kroah-Hartman, Len Brown,
Rafael J. Wysocki, Rickard Andersson, linux-acpi
In-Reply-To: <20121206233600.7249c3f1@bob.linux.org.uk>
On Fri, Dec 7, 2012 at 12:36 AM, Alan Cox <alan@linux.intel.com> wrote:
> What about just using 0, 1, 2, 3 to indicate states similar to D0-D3
> which as a base concept everyone is familiar with ?
Sorry, I might be something of an oddity, but ACPI is not used on
ARM systems as of today, and I was completely confused by
these:
uart_change_pm(state, 0);
uart_change_pm(state, 3);
I was just like ... eh ... 0? 3?
No ACPI associations existed in my head until I finally found
the note in the documentation saying that it corresponds to
ACPI states.
We are a few kernel developers these days who never ever
worked on Intel, sorry for this, but that's what we are like :-)
> If we need something more than that, then can we talk about what the
> actual extra non 0/3 states needed are and how to get a generic
> meaningful definition, or indeed whether a number rather than flag bits
> makes sense ?
Sure, I think my colleague Rickard will soon post another
patch for controlling the state 1,2 bottom-up from drivers.
> Start with the driver/platform that causes the concern and then the
> rest is probably blindingly obvious.
It's the introduction of runtime power management for the ARM
amba-pl011.c UART driver that confuse us.
It is atleast obvious that none of the 5 ARM platforms using that
driver do not use ACPI, and I expect the situation to be the same
for most of the ARM drivers.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v2] tty: serial core: decouple pm states from ACPI
From: Linus Walleij @ 2012-12-07 10:36 UTC (permalink / raw)
To: linux-serial, Greg Kroah-Hartman
Cc: Alan Cox, Rickard Andersson, linux-acpi, Linus Walleij
From: Linus Walleij <linus.walleij@linaro.org>
The serial core is using power states lifted from ACPI for no
good reason. Remove this reference from the documentation and
alter all users to use an enum specific to the serial core
instead, and define it in <linux/serial_core.h>.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- rename states from _DEFAULT and _SLEEP to simply _ON
and _OFF as Rafael suggests.
---
Documentation/serial/driver | 5 ++---
drivers/tty/serial/serial_core.c | 30 ++++++++++++++++--------------
include/linux/serial_core.h | 14 +++++++++++++-
3 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 0a25a91..a6ef8dc 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -242,9 +242,8 @@ hardware.
pm(port,state,oldstate)
Perform any power management related activities on the specified
- port. State indicates the new state (defined by ACPI D0-D3),
- oldstate indicates the previous state. Essentially, D0 means
- fully on, D3 means powered down.
+ port. State indicates the new state (defined by
+ enum uart_pm_state), oldstate indicates the previous state.
This function should not be used to grab any resources.
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 2c7230a..82d7ce8 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -59,7 +59,8 @@ static struct lock_class_key port_lock_key;
static void uart_change_speed(struct tty_struct *tty, struct uart_state *state,
struct ktermios *old_termios);
static void uart_wait_until_sent(struct tty_struct *tty, int timeout);
-static void uart_change_pm(struct uart_state *state, int pm_state);
+static void uart_change_pm(struct uart_state *state,
+ enum uart_pm_state pm_state);
static void uart_port_shutdown(struct tty_port *port);
@@ -1365,7 +1366,7 @@ static void uart_close(struct tty_struct *tty, struct file *filp)
spin_lock_irqsave(&port->lock, flags);
} else if (!uart_console(uport)) {
spin_unlock_irqrestore(&port->lock, flags);
- uart_change_pm(state, 3);
+ uart_change_pm(state, UART_PM_STATE_OFF);
spin_lock_irqsave(&port->lock, flags);
}
@@ -1579,7 +1580,7 @@ static int uart_open(struct tty_struct *tty, struct file *filp)
* Make sure the device is in D0 state.
*/
if (port->count == 1)
- uart_change_pm(state, 0);
+ uart_change_pm(state, UART_PM_STATE_ON);
/*
* Start up the serial port.
@@ -1620,7 +1621,7 @@ static void uart_line_info(struct seq_file *m, struct uart_driver *drv, int i)
{
struct uart_state *state = drv->state + i;
struct tty_port *port = &state->port;
- int pm_state;
+ enum uart_pm_state pm_state;
struct uart_port *uport = state->uart_port;
char stat_buf[32];
unsigned int status;
@@ -1645,12 +1646,12 @@ static void uart_line_info(struct seq_file *m, struct uart_driver *drv, int i)
if (capable(CAP_SYS_ADMIN)) {
mutex_lock(&port->mutex);
pm_state = state->pm_state;
- if (pm_state)
- uart_change_pm(state, 0);
+ if (pm_state != UART_PM_STATE_ON)
+ uart_change_pm(state, UART_PM_STATE_ON);
spin_lock_irq(&uport->lock);
status = uport->ops->get_mctrl(uport);
spin_unlock_irq(&uport->lock);
- if (pm_state)
+ if (pm_state != UART_PM_STATE_ON)
uart_change_pm(state, pm_state);
mutex_unlock(&port->mutex);
@@ -1897,7 +1898,8 @@ EXPORT_SYMBOL_GPL(uart_set_options);
*
* Locking: port->mutex has to be held
*/
-static void uart_change_pm(struct uart_state *state, int pm_state)
+static void uart_change_pm(struct uart_state *state,
+ enum uart_pm_state pm_state)
{
struct uart_port *port = state->uart_port;
@@ -1982,7 +1984,7 @@ int uart_suspend_port(struct uart_driver *drv, struct uart_port *uport)
console_stop(uport->cons);
if (console_suspend_enabled || !uart_console(uport))
- uart_change_pm(state, 3);
+ uart_change_pm(state, UART_PM_STATE_OFF);
mutex_unlock(&port->mutex);
@@ -2027,7 +2029,7 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
termios = port->tty->termios;
if (console_suspend_enabled)
- uart_change_pm(state, 0);
+ uart_change_pm(state, UART_PM_STATE_ON);
uport->ops->set_termios(uport, &termios, NULL);
if (console_suspend_enabled)
console_start(uport->cons);
@@ -2037,7 +2039,7 @@ int uart_resume_port(struct uart_driver *drv, struct uart_port *uport)
const struct uart_ops *ops = uport->ops;
int ret;
- uart_change_pm(state, 0);
+ uart_change_pm(state, UART_PM_STATE_ON);
spin_lock_irq(&uport->lock);
ops->set_mctrl(uport, 0);
spin_unlock_irq(&uport->lock);
@@ -2137,7 +2139,7 @@ uart_configure_port(struct uart_driver *drv, struct uart_state *state,
uart_report_port(drv, port);
/* Power up port for set_mctrl() */
- uart_change_pm(state, 0);
+ uart_change_pm(state, UART_PM_STATE_ON);
/*
* Ensure that the modem control lines are de-activated.
@@ -2161,7 +2163,7 @@ uart_configure_port(struct uart_driver *drv, struct uart_state *state,
* console if we have one.
*/
if (!uart_console(port))
- uart_change_pm(state, 3);
+ uart_change_pm(state, UART_PM_STATE_OFF);
}
}
@@ -2588,7 +2590,7 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
}
state->uart_port = uport;
- state->pm_state = -1;
+ state->pm_state = UART_PM_STATE_UNDEFINED;
uport->cons = drv->cons;
uport->state = state;
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index c6690a2..a116daa 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -208,13 +208,25 @@ static inline void serial_port_out(struct uart_port *up, int offset, int value)
up->serial_out(up, offset, value);
}
+/**
+ * enum uart_pm_state - power states for UARTs
+ * @UART_PM_STATE_ON: UART is powered, up and operational
+ * @UART_PM_STATE_OFF: UART is powered off
+ * @UART_PM_STATE_UNDEFINED: sentinel
+ */
+enum uart_pm_state {
+ UART_PM_STATE_ON = 0,
+ UART_PM_STATE_OFF = 3, /* number taken from ACPI */
+ UART_PM_STATE_UNDEFINED,
+};
+
/*
* This is the state information which is persistent across opens.
*/
struct uart_state {
struct tty_port port;
- int pm_state;
+ enum uart_pm_state pm_state;
struct circ_buf xmit;
struct uart_port *uart_port;
--
1.7.11.3
^ permalink raw reply related
* Re: [PATCH v2] tty: serial core: decouple pm states from ACPI
From: Daniel Lezcano @ 2012-12-07 11:19 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-serial, Greg Kroah-Hartman, Alan Cox, Rickard Andersson,
linux-acpi, Linus Walleij
In-Reply-To: <1354876568-10617-1-git-send-email-linus.walleij@stericsson.com>
On 12/07/2012 11:36 AM, Linus Walleij wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> The serial core is using power states lifted from ACPI for no
> good reason. Remove this reference from the documentation and
> alter all users to use an enum specific to the serial core
> instead, and define it in <linux/serial_core.h>.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - rename states from _DEFAULT and _SLEEP to simply _ON
> and _OFF as Rafael suggests.
> ---
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
One suggestion below.
[ ... ]
> @@ -1620,7 +1621,7 @@ static void uart_line_info(struct seq_file *m, struct uart_driver *drv, int i)
> {
> struct uart_state *state = drv->state + i;
> struct tty_port *port = &state->port;
> - int pm_state;
> + enum uart_pm_state pm_state;
> struct uart_port *uport = state->uart_port;
> char stat_buf[32];
> unsigned int status;
> @@ -1645,12 +1646,12 @@ static void uart_line_info(struct seq_file *m, struct uart_driver *drv, int i)
> if (capable(CAP_SYS_ADMIN)) {
> mutex_lock(&port->mutex);
> pm_state = state->pm_state;
> - if (pm_state)
> - uart_change_pm(state, 0);
> + if (pm_state != UART_PM_STATE_ON)
> + uart_change_pm(state, UART_PM_STATE_ON);
The check is already done in the uart_change_pm function, no ?
> spin_lock_irq(&uport->lock);
> status = uport->ops->get_mctrl(uport);
> spin_unlock_irq(&uport->lock);
> - if (pm_state)
> + if (pm_state != UART_PM_STATE_ON)
> uart_change_pm(state, pm_state);
Maybe it could be worth to change uart_change_pm to return the old state
value.
So the code will be simpler:
pm_state = uart_change_pm(state, UART_PM_STATE_ON);
...
uart_change_pm(state, pm_state);
The uart_change_pm already takes care of changing the value if the
current one is different.
Well, maybe that could come on a different patch.
[ ... ]
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
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 v2] tty: serial core: decouple pm states from ACPI
From: Alan Cox @ 2012-12-07 11:47 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-serial, Greg Kroah-Hartman, Rickard Andersson, linux-acpi,
Linus Walleij
In-Reply-To: <1354876568-10617-1-git-send-email-linus.walleij@stericsson.com>
On Fri, 7 Dec 2012 11:36:08 +0100
Linus Walleij <linus.walleij@stericsson.com> wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> The serial core is using power states lifted from ACPI for no
> good reason. Remove this reference from the documentation and
> alter all users to use an enum specific to the serial core
> instead, and define it in <linux/serial_core.h>.
Ok fair enough.. if its confusing people. Seems daft to me but there we
are 8)
Acked-by: Alan Cox <alan@linux.intel.com>
^ permalink raw reply
* 16C554 (16550 compatiable) UART autoconf failed (8250 driver)
From: Woody Wu @ 2012-12-07 7:02 UTC (permalink / raw)
To: linux-serial
Hi, list
Does anyone here familiar to the serial 8250 driver?
I enabled two uart ports in my board definition, but the ports doesn't
appear after I loaded the kernel (3.4.19). I discovered, it failed at
the UART port auto configuration stage, the exact function is
autoconfig(...) in drivers/tty/serial/8250.c.
...
if (!(port->flags & UPF_BUGGY_UART)) {
scratch = serial_in(up, UART_IER);
serial_out(up, UART_IER, 0);
#ifdef __i386__
outb(0xff, 0x080);
#endif
/*
* Mask out IER[7:4] bits for test as some UARTs (e.g. TL
* 16C754B) allow only to modify them if an EFR bit is set.
*/
scratch2 = serial_in(up, UART_IER) & 0x0f;
serial_out(up, UART_IER, 0x0F);
#ifdef __i386__
outb(0, 0x080);
#endif
scratch3 = serial_in(up, UART_IER) & 0x0f;
serial_out(up, UART_IER, scratch);
if (scratch2 != 0 || scratch3 != 0x0F) {
/*
* We failed; there's nothing here
*/
DEBUG_AUTOCONF("IER test failed (%02x, %02x) ",
scratch2, scratch3);
goto out;
}
}
By enabling the debug output, I found it failed because values in scratch2 and
scratch3 are all zeros.
In my board definition, what I configured are something like:
#define SERIAL_BASE (0xe1400000)
#define SERIAL_FLAGS (UPF_BOOT_AUTOCONF | UPF_IOREMAP | UPF_SHARE_IRQ)
#define SERIAL_CLK (14745600)
static struct plat_serial8250_port lgf2410_urts_data[] = {
[0] = {
.mapbase = SERIAL_BASE + 0x00,
.irq = 16,
.flags = SERIAL_FLAGS,
.iotype = UPIO_MEM,
.regshift = 0,
.uartclk = SERIAL_CLK,
},
[1] = {
.mapbase = SERIAL_BASE + 0x10,
.irq = 17,
.flags = SERIAL_FLAGS,
.iotype = UPIO_MEM,
.regshift = 0,
.uartclk = SERIAL_CLK,
},
};
static struct platform_device lgf2410_urts = {
.name = "serial8250",
.id = PLAT8250_DEV_PLATFORM,
.dev = {
.platform_data = &lgf2410_urts_data,
},
};
I think the mapbase addresses are corrected. Since I copied these addresse from
a old kernel log output from a 2.6.16 linux. For the old 2.6.16 kernel, which
run the exact same board, I have no information how it was configured.
Below is the 2.6.16 kernel output, it successfully detected the UART
ports:
serial8250: tts0 at MMIO 0xe1400000 (irq = 16) is a 16550A
serial8250: tts1 at MMIO 0xe1400008 (irq = 16) is a 16550A
serial8250: tts2 at MMIO 0xe1400010 (irq = 17) is a 16550A
serial8250: tts3 at MMIO 0xe1400018 (irq = 17) is a 16550A
Now I expect the same result from my self tailored 3.4.19 kernel.
Hope I can get your kind support! Thanks.
--
woody
I can't go back to yesterday - because I was a different person then.
^ permalink raw reply
* Open the attached file for Partnership & Investment. Confidential.
From: Mrs. Keyondria Nkiambi @ 2012-12-08 19:25 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 2 bytes --]
[-- Attachment #2: Keyondria Nkiambi & Son.doc --]
[-- Type: application/msword, Size: 27136 bytes --]
^ permalink raw reply
* Did quatech changes make 3.8? (was: Re: Comments requested: driver for Quatech PCI serial cards)
From: Jonathan Woithe @ 2012-12-10 0:13 UTC (permalink / raw)
To: Greg KH; +Cc: Alan Cox, linux-serial, jwoithe
In-Reply-To: <20121128223300.GA24713@marvin.atrad.com.au>
On Thu, Nov 29, 2012 at 09:03:00AM +1030, Jonathan Woithe wrote:
> On Wed, Nov 28, 2012 at 09:30:10AM -0800, Greg KH wrote:
> > On Thu, Nov 29, 2012 at 12:11:40AM +1030, Jonathan Woithe wrote:
> > > On Wed, Nov 28, 2012 at 01:24:19PM +0000, Alan Cox wrote:
> > > > Can we get a Signed-off-by: for the first patch so we can try and get it
> > > > into 3.8 ?
> > >
> > > Sure. See below. The rest of the previous commit message was fine so I
> > > haven't replicated it here.
> >
> > Please do, otherwise I have to hand-edit the patch to add it back, and
> > odds are, I will get it wrong...
>
> No problem. See below. I took the opportunity to tweak the commit message
> a touch.
I am wondering (for documentation purposes) whether the quatech changes
below made 3.8 or whether they'll appear in 3.9. I don't see them in
linux-next or tty-next, but I'm still learning git and might have done
something wrong while searching.
jonathan
> From: Alan Cox <alan@linux.intel.com>
>
> quatech: add the other serial identifiers and preliminary control code
>
> Jonathan Woithe posted an out of tree enabler/control module for these
> cards. Lift the relevant identifiers and put them in the 8250_pci driver
> along with code used to control custom registers on these cards.
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> Signed-off-by: Jonathan Woithe <jwoithe@just42.net>
>
> ---
> diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers/tty/serial/8250/8250_pci.c
> index 17b7d26..43c6b4f 100644
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tty/serial/8250/8250_pci.c
> @@ -1040,6 +1040,253 @@ static int pci_asix_setup(struct serial_private *priv,
> return pci_default_setup(priv, board, port, idx);
> }
>
> +/* Quatech devices have their own extra interface features */
> +
> +struct quatech_feature {
> + u16 devid;
> + bool amcc;
> +};
> +
> +#define QPCR_TEST_FOR1 0x3F
> +#define QPCR_TEST_GET1 0x00
> +#define QPCR_TEST_FOR2 0x40
> +#define QPCR_TEST_GET2 0x40
> +#define QPCR_TEST_FOR3 0x80
> +#define QPCR_TEST_GET3 0x40
> +#define QPCR_TEST_FOR4 0xC0
> +#define QPCR_TEST_GET4 0x80
> +
> +#define QOPR_CLOCK_X1 0x0000
> +#define QOPR_CLOCK_X2 0x0001
> +#define QOPR_CLOCK_X4 0x0002
> +#define QOPR_CLOCK_X8 0x0003
> +#define QOPR_CLOCK_RATE_MASK 0x0003
> +
> +
> +static struct quatech_feature quatech_cards[] = {
> + { PCI_DEVICE_ID_QUATECH_QSC100, 1 },
> + { PCI_DEVICE_ID_QUATECH_DSC100, 1 },
> + { PCI_DEVICE_ID_QUATECH_DSC100E, 0 },
> + { PCI_DEVICE_ID_QUATECH_DSC200, 1 },
> + { PCI_DEVICE_ID_QUATECH_DSC200E, 0 },
> + { PCI_DEVICE_ID_QUATECH_ESC100D, 1 },
> + { PCI_DEVICE_ID_QUATECH_ESC100M, 1 },
> + { PCI_DEVICE_ID_QUATECH_QSCP100, 1 },
> + { PCI_DEVICE_ID_QUATECH_DSCP100, 1 },
> + { PCI_DEVICE_ID_QUATECH_QSCP200, 1 },
> + { PCI_DEVICE_ID_QUATECH_DSCP200, 1 },
> + { PCI_DEVICE_ID_QUATECH_ESCLP100, 0 },
> + { PCI_DEVICE_ID_QUATECH_QSCLP100, 0 },
> + { PCI_DEVICE_ID_QUATECH_DSCLP100, 0 },
> + { PCI_DEVICE_ID_QUATECH_SSCLP100, 0 },
> + { PCI_DEVICE_ID_QUATECH_QSCLP200, 0 },
> + { PCI_DEVICE_ID_QUATECH_DSCLP200, 0 },
> + { PCI_DEVICE_ID_QUATECH_SSCLP200, 0 },
> + { PCI_DEVICE_ID_QUATECH_SPPXP_100, 0 },
> + { 0, }
> +};
> +
> +static int pci_quatech_amcc(u16 devid)
> +{
> + struct quatech_feature *qf = &quatech_cards[0];
> + while (qf->devid) {
> + if (qf->devid == devid)
> + return qf->amcc;
> + qf++;
> + }
> + pr_err("quatech: unknown port type '0x%04X'.\n", devid);
> + return 0;
> +};
> +
> +static int pci_quatech_rqopr(struct uart_8250_port *port)
> +{
> + unsigned long base = port->port.iobase;
> + u8 LCR, val;
> +
> + LCR = inb(base + UART_LCR);
> + outb(0xBF, base + UART_LCR);
> + val = inb(base + UART_SCR);
> + outb(LCR, base + UART_LCR);
> + return val;
> +}
> +
> +static void pci_quatech_wqopr(struct uart_8250_port *port, u8 qopr)
> +{
> + unsigned long base = port->port.iobase;
> + u8 LCR, val;
> +
> + LCR = inb(base + UART_LCR);
> + outb(0xBF, base + UART_LCR);
> + val = inb(base + UART_SCR);
> + outb(qopr, base + UART_SCR);
> + outb(LCR, base + UART_LCR);
> +}
> +
> +static int pci_quatech_rqmcr(struct uart_8250_port *port)
> +{
> + unsigned long base = port->port.iobase;
> + u8 LCR, val, qmcr;
> +
> + LCR = inb(base + UART_LCR);
> + outb(0xBF, base + UART_LCR);
> + val = inb(base + UART_SCR);
> + outb(val | 0x10, base + UART_SCR);
> + qmcr = inb(base + UART_MCR);
> + outb(val, base + UART_SCR);
> + outb(LCR, base + UART_LCR);
> +
> + return qmcr;
> +}
> +
> +static void pci_quatech_wqmcr(struct uart_8250_port *port, u8 qmcr)
> +{
> + unsigned long base = port->port.iobase;
> + u8 LCR, val;
> +
> + LCR = inb(base + UART_LCR);
> + outb(0xBF, base + UART_LCR);
> + val = inb(base + UART_SCR);
> + outb(val | 0x10, base + UART_SCR);
> + outb(qmcr, base + UART_MCR);
> + outb(val, base + UART_SCR);
> + outb(LCR, base + UART_LCR);
> +}
> +
> +static int pci_quatech_has_qmcr(struct uart_8250_port *port)
> +{
> + unsigned long base = port->port.iobase;
> + u8 LCR, val;
> +
> + LCR = inb(base + UART_LCR);
> + outb(0xBF, base + UART_LCR);
> + val = inb(base + UART_SCR);
> + if (val & 0x20) {
> + outb(0x80, UART_LCR);
> + if (!(inb(UART_SCR) & 0x20)) {
> + outb(LCR, base + UART_LCR);
> + return 1;
> + }
> + }
> + return 0;
> +}
> +
> +static int pci_quatech_test(struct uart_8250_port *port)
> +{
> + u8 reg;
> + u8 qopr = pci_quatech_rqopr(port);
> + pci_quatech_wqopr(port, qopr & QPCR_TEST_FOR1);
> + reg = pci_quatech_rqopr(port) & 0xC0;
> + if (reg != QPCR_TEST_GET1)
> + return -EINVAL;
> + pci_quatech_wqopr(port, (qopr & QPCR_TEST_FOR1)|QPCR_TEST_FOR2);
> + reg = pci_quatech_rqopr(port) & 0xC0;
> + if (reg != QPCR_TEST_GET2)
> + return -EINVAL;
> + pci_quatech_wqopr(port, (qopr & QPCR_TEST_FOR1)|QPCR_TEST_FOR3);
> + reg = pci_quatech_rqopr(port) & 0xC0;
> + if (reg != QPCR_TEST_GET3)
> + return -EINVAL;
> + pci_quatech_wqopr(port, (qopr & QPCR_TEST_FOR1)|QPCR_TEST_FOR4);
> + reg = pci_quatech_rqopr(port) & 0xC0;
> + if (reg != QPCR_TEST_GET4)
> + return -EINVAL;
> +
> + pci_quatech_wqopr(port, qopr);
> + return 0;
> +}
> +
> +static int pci_quatech_clock(struct uart_8250_port *port)
> +{
> + u8 qopr, reg, set;
> + unsigned long clock;
> +
> + if (pci_quatech_test(port) < 0)
> + return 1843200;
> +
> + qopr = pci_quatech_rqopr(port);
> +
> + pci_quatech_wqopr(port, qopr & ~QOPR_CLOCK_X8);
> + reg = pci_quatech_rqopr(port);
> + if (reg & QOPR_CLOCK_X8) {
> + clock = 1843200;
> + goto out;
> + }
> + pci_quatech_wqopr(port, qopr | QOPR_CLOCK_X8);
> + reg = pci_quatech_rqopr(port);
> + if (!(reg & QOPR_CLOCK_X8)) {
> + clock = 1843200;
> + goto out;
> + }
> + reg &= QOPR_CLOCK_X8;
> + if (reg == QOPR_CLOCK_X2) {
> + clock = 3685400;
> + set = QOPR_CLOCK_X2;
> + } else if (reg == QOPR_CLOCK_X4) {
> + clock = 7372800;
> + set = QOPR_CLOCK_X4;
> + } else if (reg == QOPR_CLOCK_X8) {
> + clock = 14745600;
> + set = QOPR_CLOCK_X8;
> + } else {
> + clock = 1843200;
> + set = QOPR_CLOCK_X1;
> + }
> + qopr &= ~QOPR_CLOCK_RATE_MASK;
> + qopr |= set;
> +
> +out:
> + pci_quatech_wqopr(port, qopr);
> + return clock;
> +}
> +
> +static int pci_quatech_rs422(struct uart_8250_port *port)
> +{
> + u8 qmcr;
> + int rs422 = 0;
> +
> + if (!pci_quatech_has_qmcr(port))
> + return 0;
> + qmcr = pci_quatech_rqmcr(port);
> + pci_quatech_wqmcr(port, 0xFF);
> + if (pci_quatech_rqmcr(port))
> + rs422 = 1;
> + pci_quatech_wqmcr(port, qmcr);
> + return rs422;
> +}
> +
> +static int pci_quatech_init(struct pci_dev *dev)
> +{
> + if (pci_quatech_amcc(dev->device)) {
> + unsigned long base = pci_resource_start(dev, 0);
> + if (base) {
> + u32 tmp;
> + outl(inl(base + 0x38), base + 0x38);
> + tmp = inl(base + 0x3c);
> + outl(tmp | 0x01000000, base + 0x3c);
> + outl(tmp, base + 0x3c);
> + }
> + }
> + return 0;
> +}
> +
> +static int pci_quatech_setup(struct serial_private *priv,
> + const struct pciserial_board *board,
> + struct uart_8250_port *port, int idx)
> +{
> + /* Needed by pci_quatech calls below */
> + port->port.iobase = pci_resource_start(priv->dev, FL_GET_BASE(board->flags));
> + /* Set up the clocking */
> + port->port.uartclk = pci_quatech_clock(port);
> + /* For now just warn about RS422 */
> + if (pci_quatech_rs422(port))
> + pr_warn( "quatech: software control of RS422 features not currently supported.\n");
> + return pci_default_setup(priv, board, port, idx);
> +}
> +
> +static void __devexit pci_quatech_exit(struct pci_dev *dev)
> +{
> +}
> +
> static int pci_default_setup(struct serial_private *priv,
> const struct pciserial_board *board,
> struct uart_8250_port *port, int idx)
> @@ -1503,6 +1750,16 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
> .setup = pci_default_setup,
> .exit = __devexit_p(pci_plx9050_exit),
> },
> + /* Quatech */
> + {
> + .vendor = PCI_VENDOR_ID_QUATECH,
> + .device = PCI_ANY_ID,
> + .subvendor = PCI_ANY_ID,
> + .subdevice = PCI_ANY_ID,
> + .init = pci_quatech_init,
> + .setup = pci_quatech_setup,
> + .exit = __devexit_p(pci_quatech_exit),
> + },
> /*
> * SBS Technologies, Inc., PMC-OCTALPRO 232
> */
> @@ -3257,18 +3514,70 @@ static struct pci_device_id serial_pci_tbl[] = {
> { PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_ROMULUS,
> 0x10b5, 0x106a, 0, 0,
> pbn_plx_romulus },
> + /*
> + * Quatech cards. These actually have configurable clocks but for
> + * now we just use the default.
> + *
> + * 100 series are RS232, 200 series RS422,
> + */
> { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_QSC100,
> PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> pbn_b1_4_115200 },
> { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_DSC100,
> PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> pbn_b1_2_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_DSC100E,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b2_2_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_DSC200,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b1_2_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_DSC200E,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b2_2_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_QSC200,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b1_4_115200 },
> { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_ESC100D,
> PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> pbn_b1_8_115200 },
> { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_ESC100M,
> PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> pbn_b1_8_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_QSCP100,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b1_4_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_DSCP100,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b1_2_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_QSCP200,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b1_4_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_DSCP200,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b1_2_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_QSCLP100,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b2_4_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_DSCLP100,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b2_2_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_SSCLP100,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b2_1_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_QSCLP200,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b2_4_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_DSCLP200,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b2_2_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_SSCLP200,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b2_1_115200 },
> + { PCI_VENDOR_ID_QUATECH, PCI_DEVICE_ID_QUATECH_ESCLP100,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> + pbn_b0_8_115200 },
> +
> { PCI_VENDOR_ID_SPECIALIX, PCI_DEVICE_ID_OXSEMI_16PCI954,
> PCI_VENDOR_ID_SPECIALIX, PCI_SUBDEVICE_ID_SPECIALIX_SPEED4,
> 0, 0,
> diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
> index 9d36b82..ce45006 100644
> --- a/include/linux/pci_ids.h
> +++ b/include/linux/pci_ids.h
> @@ -1867,8 +1867,23 @@
> #define PCI_VENDOR_ID_QUATECH 0x135C
> #define PCI_DEVICE_ID_QUATECH_QSC100 0x0010
> #define PCI_DEVICE_ID_QUATECH_DSC100 0x0020
> +#define PCI_DEVICE_ID_QUATECH_DSC200 0x0030
> +#define PCI_DEVICE_ID_QUATECH_QSC200 0x0040
> #define PCI_DEVICE_ID_QUATECH_ESC100D 0x0050
> #define PCI_DEVICE_ID_QUATECH_ESC100M 0x0060
> +#define PCI_DEVICE_ID_QUATECH_QSCP100 0x0120
> +#define PCI_DEVICE_ID_QUATECH_DSCP100 0x0130
> +#define PCI_DEVICE_ID_QUATECH_QSCP200 0x0140
> +#define PCI_DEVICE_ID_QUATECH_DSCP200 0x0150
> +#define PCI_DEVICE_ID_QUATECH_QSCLP100 0x0170
> +#define PCI_DEVICE_ID_QUATECH_DSCLP100 0x0180
> +#define PCI_DEVICE_ID_QUATECH_DSC100E 0x0181
> +#define PCI_DEVICE_ID_QUATECH_SSCLP100 0x0190
> +#define PCI_DEVICE_ID_QUATECH_QSCLP200 0x01A0
> +#define PCI_DEVICE_ID_QUATECH_DSCLP200 0x01B0
> +#define PCI_DEVICE_ID_QUATECH_DSC200E 0x01B1
> +#define PCI_DEVICE_ID_QUATECH_SSCLP200 0x01C0
> +#define PCI_DEVICE_ID_QUATECH_ESCLP100 0x01E0
> #define PCI_DEVICE_ID_QUATECH_SPPXP_100 0x0278
>
> #define PCI_VENDOR_ID_SEALEVEL 0x135e
^ 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