* Re: [PATCH 5/5] omap-serial: Request pins using pinctrl framework
From: Felipe Balbi @ 2012-09-07 5:26 UTC (permalink / raw)
To: Tony Lindgren
Cc: Felipe Balbi, linux-arm-kernel, Greg Kroah-Hartman, linux-omap,
linux-serial
In-Reply-To: <20120906211725.GQ1303@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]
Hi,
On Thu, Sep 06, 2012 at 02:17:26PM -0700, Tony Lindgren wrote:
> * Felipe Balbi <balbi@ti.com> [120906 13:01]:
> > Hi,
> >
> > On Thu, Sep 06, 2012 at 11:58:32AM -0700, Tony Lindgren wrote:
> > > Request pins using pinctrl framework. Only show a warning
> > > on error as some boards set the pins in the bootloader
> > > even if CONFIG_PINCTRL is enabled.
> > >
> > > Cc: linux-serial@vger.kernel.org
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > > ---
> > > arch/arm/plat-omap/include/plat/omap-serial.h | 1 +
> > > drivers/tty/serial/omap-serial.c | 10 ++++++++++
> > > 2 files changed, 11 insertions(+)
> > >
> > > diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
> > > index 1a52725..0f4de14 100644
> > > --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> > > +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> > > @@ -106,6 +106,7 @@ struct uart_omap_port {
> > > struct uart_port port;
> > > struct uart_omap_dma uart_dma;
> > > struct platform_device *pdev;
> > > + struct pinctrl *pins;
> >
> > this won't apply to Greg's tty-next as I moved this structure to the C
> > file :-s
>
> Hmm the tty-next fails to build right now for omaps:
>
> drivers/tty/serial/omap-serial.c: In function ‘serial_omap_set_mctrl’:
> drivers/tty/serial/omap-serial.c:514: error: ‘struct uart_omap_port’ has no member named ‘DTR_gpio’
>
> Maybe check how you want to fix that first? I can then update
> my patch for tty-next.
oops, my bad. Patch sent.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH 5/5] omap-serial: Request pins using pinctrl framework
From: AnilKumar, Chimata @ 2012-09-07 3:27 UTC (permalink / raw)
To: Tony Lindgren, linux-arm-kernel@lists.infradead.org
Cc: Greg Kroah-Hartman, linux-omap@vger.kernel.org,
linux-serial@vger.kernel.org
In-Reply-To: <20120906185832.1172.31013.stgit@muffinssi.local>
Hi Tony,
On Fri, Sep 07, 2012 at 00:28:32, Tony Lindgren wrote:
> Request pins using pinctrl framework. Only show a warning
> on error as some boards set the pins in the bootloader
> even if CONFIG_PINCTRL is enabled.
>
> Cc: linux-serial@vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/plat-omap/include/plat/omap-serial.h | 1 +
> drivers/tty/serial/omap-serial.c | 10 ++++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
> index 1a52725..0f4de14 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -106,6 +106,7 @@ struct uart_omap_port {
> struct uart_port port;
> struct uart_omap_dma uart_dma;
> struct platform_device *pdev;
> + struct pinctrl *pins;
>
> unsigned char ier;
> unsigned char lcr;
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index d3cda0c..068e88c 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -39,6 +39,7 @@
> #include <linux/irq.h>
> #include <linux/pm_runtime.h>
> #include <linux/of.h>
> +#include <linux/pinctrl/consumer.h>
>
> #include <plat/dma.h>
> #include <plat/dmtimer.h>
> @@ -1492,6 +1493,13 @@ static int serial_omap_probe(struct platform_device *pdev)
> goto err_port_line;
> }
>
> + up->pins = pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(up->pins)) {
> + dev_warn(&pdev->dev, "did not get pins for uart%i error: %li\n",
> + up->port.line, PTR_ERR(up->pins));
> + up->pins = NULL;
> + }
> +
> sprintf(up->name, "OMAP UART%d", up->port.line);
> up->port.mapbase = mem->start;
> up->port.membase = devm_ioremap(&pdev->dev, mem->start,
> @@ -1570,6 +1578,8 @@ static int serial_omap_remove(struct platform_device *dev)
> pm_runtime_disable(&up->pdev->dev);
> uart_remove_one_port(&serial_omap_reg, &up->port);
> pm_qos_remove_request(&up->pm_qos_request);
> + if (up->pins)
> + pinctrl_put(up->pins);
I think this can be removed if we use devm_pinctrl_get_select_default()
above.
Thanks
AnilKumar
^ permalink raw reply
* Re: [PATCH] serial: mxs-auart: put the device when exit or error
From: Shawn Guo @ 2012-09-07 3:14 UTC (permalink / raw)
To: Huang Shijie; +Cc: gregkh, alan, linux-serial, linux-arm-kernel, linux-kernel
In-Reply-To: <1346985187-30459-1-git-send-email-b32955@freescale.com>
On Fri, Sep 07, 2012 at 10:33:07AM +0800, Huang Shijie wrote:
> We call the get_device() in the mxs_auart_probe().
> For the balance of the reference count, we should put the
> device in the mxs_auart_remove() or in the error path of
> probe.
>
> Signed-off-by: Huang Shijie <b32955@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
> ---
> drivers/tty/serial/mxs-auart.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index 3a667ee..203e512 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -781,6 +781,7 @@ out_free_irq:
> auart_port[pdev->id] = NULL;
> free_irq(s->irq, s);
> out_free_clk:
> + put_device(s->dev);
> clk_put(s->clk);
> out_free:
> kfree(s);
> @@ -796,6 +797,7 @@ static int __devexit mxs_auart_remove(struct platform_device *pdev)
>
> auart_port[pdev->id] = NULL;
>
> + put_device(s->dev);
> clk_put(s->clk);
> free_irq(s->irq, s);
> kfree(s);
> --
> 1.7.0.4
>
>
^ permalink raw reply
* [PATCH] serial: mxs-auart: put the device when exit or error
From: Huang Shijie @ 2012-09-07 2:33 UTC (permalink / raw)
To: gregkh
Cc: alan, linux-serial, linux-arm-kernel, linux-kernel, shawn.guo,
Huang Shijie
In-Reply-To: <20120907024349.GH26709@S2101-09.ap.freescale.net>
We call the get_device() in the mxs_auart_probe().
For the balance of the reference count, we should put the
device in the mxs_auart_remove() or in the error path of
probe.
Signed-off-by: Huang Shijie <b32955@freescale.com>
---
drivers/tty/serial/mxs-auart.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index 3a667ee..203e512 100644
--- a/drivers/tty/serial/mxs-auart.c
+++ b/drivers/tty/serial/mxs-auart.c
@@ -781,6 +781,7 @@ out_free_irq:
auart_port[pdev->id] = NULL;
free_irq(s->irq, s);
out_free_clk:
+ put_device(s->dev);
clk_put(s->clk);
out_free:
kfree(s);
@@ -796,6 +797,7 @@ static int __devexit mxs_auart_remove(struct platform_device *pdev)
auart_port[pdev->id] = NULL;
+ put_device(s->dev);
clk_put(s->clk);
free_irq(s->irq, s);
kfree(s);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/2] serial: mxs-auart: put the device in mxs_auart_probe()
From: Huang Shijie @ 2012-09-07 2:48 UTC (permalink / raw)
To: Shawn Guo
Cc: Huang Shijie, gregkh, alan, linux-serial, linux-kernel,
linux-arm-kernel
In-Reply-To: <20120907024349.GH26709@S2101-09.ap.freescale.net>
于 2012年09月07日 10:43, Shawn Guo 写道:
> On Thu, Sep 06, 2012 at 10:38:41PM -0400, Huang Shijie wrote:
>> We call the get_device() in the mxs_auart_probe().
>> For the balance of the reference count, we should put the
>> device in the mxs_auart_remove().
>>
>> Signed-off-by: Huang Shijie<shijie8@gmail.com>
>> ---
>> drivers/tty/serial/mxs-auart.c | 1 +
>> 1 files changed, 1 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
>> index ea5f888..6898413 100644
>> --- a/drivers/tty/serial/mxs-auart.c
>> +++ b/drivers/tty/serial/mxs-auart.c
>> @@ -796,6 +796,7 @@ static int __devexit mxs_auart_remove(struct platform_device *pdev)
>>
>> auart_port[pdev->id] = NULL;
>>
>> + put_device(s->dev);
>> clk_put(s->clk);
>> free_irq(s->irq, s);
>> kfree(s);
> So the error path of probe needs function fixing too, right?
>
OK.
Send out the new version right now.
Huang Shijie
--
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 2/2] serial: mxs-auart: put the device in mxs_auart_probe()
From: Shawn Guo @ 2012-09-07 2:43 UTC (permalink / raw)
To: Huang Shijie; +Cc: gregkh, alan, linux-serial, linux-kernel, linux-arm-kernel
In-Reply-To: <1346985521-2248-2-git-send-email-shijie8@gmail.com>
On Thu, Sep 06, 2012 at 10:38:41PM -0400, Huang Shijie wrote:
> We call the get_device() in the mxs_auart_probe().
> For the balance of the reference count, we should put the
> device in the mxs_auart_remove().
>
> Signed-off-by: Huang Shijie <shijie8@gmail.com>
> ---
> drivers/tty/serial/mxs-auart.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index ea5f888..6898413 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -796,6 +796,7 @@ static int __devexit mxs_auart_remove(struct platform_device *pdev)
>
> auart_port[pdev->id] = NULL;
>
> + put_device(s->dev);
> clk_put(s->clk);
> free_irq(s->irq, s);
> kfree(s);
So the error path of probe needs function fixing too, right?
--
Regards,
Shawn
^ permalink raw reply
* Re: [PATCH 1/2] serial: mxs-auart: fix the wrong setting order
From: Huang Shijie @ 2012-09-07 2:43 UTC (permalink / raw)
To: Shawn Guo
Cc: Huang Shijie, gregkh, alan, linux-serial, linux-kernel,
linux-arm-kernel
In-Reply-To: <20120907023841.GF26709@S2101-09.ap.freescale.net>
于 2012年09月07日 10:38, Shawn Guo 写道:
> On Thu, Sep 06, 2012 at 10:38:40PM -0400, Huang Shijie wrote:
>> After set the AUART_CTRL0_CLKGATE, the UART will gate all the clocks off.
>> So the following line will not take effect.
>> ................................................................
>> writel(AUART_INTR_RXIEN | AUART_INTR_RTIEN | AUART_INTR_CTSMIEN,
>> u->membase + AUART_INTR_CLR);
>> ................................................................
>>
>> To fix this issue, the patch moves this gate-off line to
>> the end of setting registers.
>>
>> Signed-off-by: Huang Shijie<shijie8@gmail.com>
> Acked-by: Shawn Guo<shawn.guo@linaro.org>
>
> Are you experiencing any user visible problem with this bug?
>
I do not experience any user problem.
I found this bug when i tried to add DMA support for MXS-AUART.
Best Regards
Huang Shijie
> Regards,
> Shawn
>
>> ---
>> drivers/tty/serial/mxs-auart.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
>> index dafeef2..ea5f888 100644
>> --- a/drivers/tty/serial/mxs-auart.c
>> +++ b/drivers/tty/serial/mxs-auart.c
>> @@ -457,11 +457,11 @@ static void mxs_auart_shutdown(struct uart_port *u)
>>
>> writel(AUART_CTRL2_UARTEN, u->membase + AUART_CTRL2_CLR);
>>
>> - writel(AUART_CTRL0_CLKGATE, u->membase + AUART_CTRL0_SET);
>> -
>> writel(AUART_INTR_RXIEN | AUART_INTR_RTIEN | AUART_INTR_CTSMIEN,
>> u->membase + AUART_INTR_CLR);
>>
>> + writel(AUART_CTRL0_CLKGATE, u->membase + AUART_CTRL0_SET);
>> +
>> clk_disable_unprepare(s->clk);
>> }
>>
>> --
>> 1.7.4.4
>>
> --
> 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
>
--
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/2] serial: mxs-auart: fix the wrong setting order
From: Shawn Guo @ 2012-09-07 2:38 UTC (permalink / raw)
To: Huang Shijie; +Cc: gregkh, alan, linux-serial, linux-kernel, linux-arm-kernel
In-Reply-To: <1346985521-2248-1-git-send-email-shijie8@gmail.com>
On Thu, Sep 06, 2012 at 10:38:40PM -0400, Huang Shijie wrote:
> After set the AUART_CTRL0_CLKGATE, the UART will gate all the clocks off.
> So the following line will not take effect.
> ................................................................
> writel(AUART_INTR_RXIEN | AUART_INTR_RTIEN | AUART_INTR_CTSMIEN,
> u->membase + AUART_INTR_CLR);
> ................................................................
>
> To fix this issue, the patch moves this gate-off line to
> the end of setting registers.
>
> Signed-off-by: Huang Shijie <shijie8@gmail.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Are you experiencing any user visible problem with this bug?
Regards,
Shawn
> ---
> drivers/tty/serial/mxs-auart.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index dafeef2..ea5f888 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -457,11 +457,11 @@ static void mxs_auart_shutdown(struct uart_port *u)
>
> writel(AUART_CTRL2_UARTEN, u->membase + AUART_CTRL2_CLR);
>
> - writel(AUART_CTRL0_CLKGATE, u->membase + AUART_CTRL0_SET);
> -
> writel(AUART_INTR_RXIEN | AUART_INTR_RTIEN | AUART_INTR_CTSMIEN,
> u->membase + AUART_INTR_CLR);
>
> + writel(AUART_CTRL0_CLKGATE, u->membase + AUART_CTRL0_SET);
> +
> clk_disable_unprepare(s->clk);
> }
>
> --
> 1.7.4.4
>
^ permalink raw reply
* Re: [PATCH 2/2] 8250: blacklist IR ports
From: Alan Cox @ 2012-09-07 0:01 UTC (permalink / raw)
To: Sean Young
Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, David Härdeman,
Mauro Carvalho Chehab
In-Reply-To: <a9565dd624c186917c71a4e431e6bcab712dbf08.1346969721.git.sean@mess.org>
On Thu, 6 Sep 2012 23:20:32 +0100
Sean Young <sean@mess.org> wrote:
> These ports should not be probed, but we need to keep track of them so we
> can prevent the legacy (non-PNP) probe of serial ports from touching them
> too.
I want to have a think about getting the ordering right so we don't
shuffle the ports on existing boxes for the first half. For the second
part
>
> Signed-off-by: Sean Young <sean@mess.org>
> ---
> drivers/tty/serial/8250/8250.c | 16 ++++++++++++++--
> drivers/tty/serial/8250/8250_pnp.c | 23 ++++++++++++++++++-----
> include/linux/serial_core.h | 3 ++-
> 3 files changed, 34 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
> index bc25874..ea9166b 100644
> --- a/drivers/tty/serial/8250/8250.c
> +++ b/drivers/tty/serial/8250/8250.c
> @@ -290,6 +290,9 @@ static const struct serial8250_config uart_config[] = {
> UART_FCR_R_TRIG_00 | UART_FCR_T_TRIG_00,
> .flags = UART_CAP_FIFO,
> },
> + [PORT_IR] = {
> + .name = "IR port"
Please use "CIR port". We have SIR and FIR serial ports (IrDA) too that we
do drive via tty. PORT_8250_CIR for the type might be best too - it means
the tools know what they are looking at and can report it sensibly.
Alan
^ permalink raw reply
* Re: [PATCH v4 00/21] OMAP UART Patches
From: Kevin Hilman @ 2012-09-06 22:44 UTC (permalink / raw)
To: Felipe Balbi
Cc: Greg KH, Tony Lindgren, Linux Kernel Mailing List,
Santosh Shilimkar, linux-serial, Sourav Poddar,
Linux OMAP Mailing List, Shubhrajyoti Datta,
Linux ARM Kernel Mailing List, alan
In-Reply-To: <1346935540-1792-1-git-send-email-balbi@ti.com>
Felipe Balbi <balbi@ti.com> writes:
> Hi guys,
>
> here's v4 of the omap uart patchset. No changes other than a rebase on top of
> Greg's tty-next branch and Tony's Acked-by being added to a couple patches
>
> Note: I'm resending the series with Vikram's Software Flow Control fix anyway
> as it can just be ignored if it's decided it needs to go into this merge
> window.
Sorry to be late to the party... just getting back from some time off.
I'm assuming that this was not tested with PM, so decided I better do it
myself seeing that Greg is has already merge it. To test, I merged
Greg's tty-next branch with v3.6-rc4 and did some PM testing.
The bad news is that it doesn't even compile (see reply to [PATCH v4
20/21]).
Also, there is a big WARNING on boot[1], which seems to be triggered by
a new check added for v3.6-rc3[2]. This appears to be introduced by
$SUBJECT series, because I don't see it on vanilla v3.6-rc4.
The good news is that after hacking to fix up the compile problems,
basic PM testing seems to be fine: idle to retention and off as well as
suspend to retention and off work fine on 3430/n900, 3530/Overo,
3730/OveroSTORM, 3730/Beagle-xM.
Kevin
[1]
[ 8.745666] WARNING: at /work/kernel/omap/pm/drivers/tty/tty_io.c:1420 tty_init_dev+0x14c/0x17c()
[ 8.755218] tty_init_dev: ttyO driver does not set tty->port. This will crash the kernel later. Fix the driver!
[ 8.765991] Modules linked in:
[ 8.769287] [<c0013d90>] (unwind_backtrace+0x0/0xf0) from [<c0036eec>] (warn_slowpath_common+0x4c/0x64)
[ 8.779327] [<c0036eec>] (warn_slowpath_common+0x4c/0x64) from [<c0036f98>] (warn_slowpath_fmt+0x30/0x40)
[ 8.789550] [<c0036f98>] (warn_slowpath_fmt+0x30/0x40) from [<c02c626c>] (tty_init_dev+0x14c/0x17c)
[ 8.799224] [<c02c626c>] (tty_init_dev+0x14c/0x17c) from [<c02c68a4>] (tty_open+0x11c/0x52c)
[ 8.808258] [<c02c68a4>] (tty_open+0x11c/0x52c) from [<c00f86ac>] (chrdev_open+0x90/0x15c)
[ 8.817108] [<c00f86ac>] (chrdev_open+0x90/0x15c) from [<c00f2b74>] (do_dentry_open+0x1e8/0x270)
[ 8.826507] [<c00f2b74>] (do_dentry_open+0x1e8/0x270) from [<c00f2c30>] (finish_open+0x34/0x4c)
[ 8.835784] [<c00f2c30>] (finish_open+0x34/0x4c) from [<c0102028>] (do_last.isra.21+0x5b0/0xbbc)
[ 8.845184] [<c0102028>] (do_last.isra.21+0x5b0/0xbbc) from [<c01026dc>] (path_openat+0xa8/0x44c)
[ 8.854675] [<c01026dc>] (path_openat+0xa8/0x44c) from [<c0102d34>] (do_filp_open+0x2c/0x80)
[ 8.863708] [<c0102d34>] (do_filp_open+0x2c/0x80) from [<c00f3b6c>] (do_sys_open+0xe8/0x184)
[ 8.872711] [<c00f3b6c>] (do_sys_open+0xe8/0x184) from [<c000db20>] (ret_fast_syscall+0x0/0x3c)
[ 8.882019] ---[ end trace e9bf408c37051346 ]---
[2]
commit 5d4121c04b3577e37e389b3553d442f44bb346d7
Author: Jiri Slaby <jslaby@suse.cz>
Date: Fri Aug 17 14:27:52 2012 +0200
TTY: check if tty->port is assigned
And if not, complain loudly. None in-kernel module should trigger
that, but let us find out for sure. On the other hand, all the
out-of-tree modules will hit that. Give them some time (maybe one
release) to catch up.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH 1/2] 8250_pnp: merge into 8250 module so pnp probe can done first
From: Sean Young @ 2012-09-06 22:20 UTC (permalink / raw)
To: Alan Cox, Greg Kroah-Hartman, linux-serial
Cc: David Härdeman, Mauro Carvalho Chehab
In-Reply-To: <cover.1346969721.git.sean@mess.org>
We first poke around and guess where the serial ports are and then check
pnp. If there is a non-standard configuration then this might not work;
if there is an IR device in pnp then we should not attempt to probe it.
Signed-off-by: Sean Young <sean@mess.org>
---
drivers/tty/serial/8250/8250.c | 31 ++++++++++++++++++-------------
drivers/tty/serial/8250/8250.h | 9 +++++++++
drivers/tty/serial/8250/8250_pnp.c | 11 +++--------
drivers/tty/serial/8250/Kconfig | 16 ++++++++--------
drivers/tty/serial/8250/Makefile | 5 +++--
5 files changed, 41 insertions(+), 31 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 44f52c6..bc25874 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -2672,6 +2672,9 @@ static void __init serial8250_isa_init_ports(void)
return;
first = 0;
+ if (nr_uarts > UART_NR)
+ nr_uarts = UART_NR;
+
for (i = 0; i < nr_uarts; i++) {
struct uart_8250_port *up = &serial8250_ports[i];
struct uart_port *port = &up->port;
@@ -2681,6 +2684,7 @@ static void __init serial8250_isa_init_ports(void)
init_timer(&up->timer);
up->timer.function = serial8250_timeout;
+ up->cur_iotype = 0xFF;
/*
* ALPHA_KLUDGE_MCR needs to be killed.
@@ -2732,13 +2736,9 @@ serial8250_register_ports(struct uart_driver *drv, struct device *dev)
for (i = 0; i < nr_uarts; i++) {
struct uart_8250_port *up = &serial8250_ports[i];
- up->cur_iotype = 0xFF;
- }
- serial8250_isa_init_ports();
-
- for (i = 0; i < nr_uarts; i++) {
- struct uart_8250_port *up = &serial8250_ports[i];
+ if (up->port.dev)
+ continue;
up->port.dev = dev;
@@ -2863,9 +2863,6 @@ static struct console serial8250_console = {
static int __init serial8250_console_init(void)
{
- if (nr_uarts > UART_NR)
- nr_uarts = UART_NR;
-
serial8250_isa_init_ports();
register_console(&serial8250_console);
return 0;
@@ -3148,7 +3145,8 @@ int serial8250_register_8250_port(struct uart_8250_port *up)
uart = serial8250_find_match_or_unused(&up->port);
if (uart) {
- uart_remove_one_port(&serial8250_reg, &uart->port);
+ if (uart->port.dev)
+ uart_remove_one_port(&serial8250_reg, &uart->port);
uart->port.iobase = up->port.iobase;
uart->port.membase = up->port.membase;
@@ -3232,8 +3230,7 @@ static int __init serial8250_init(void)
{
int ret;
- if (nr_uarts > UART_NR)
- nr_uarts = UART_NR;
+ serial8250_isa_init_ports();
printk(KERN_INFO "Serial: 8250/16550 driver, "
"%d ports, IRQ sharing %sabled\n", nr_uarts,
@@ -3248,11 +3245,15 @@ static int __init serial8250_init(void)
if (ret)
goto out;
+ ret = serial8250_pnp_init();
+ if (ret)
+ goto unreg_uart_drv;
+
serial8250_isa_devs = platform_device_alloc("serial8250",
PLAT8250_DEV_LEGACY);
if (!serial8250_isa_devs) {
ret = -ENOMEM;
- goto unreg_uart_drv;
+ goto unreg_pnp;
}
ret = platform_device_add(serial8250_isa_devs);
@@ -3268,6 +3269,8 @@ static int __init serial8250_init(void)
platform_device_del(serial8250_isa_devs);
put_dev:
platform_device_put(serial8250_isa_devs);
+unreg_pnp:
+ serial8250_pnp_exit();
unreg_uart_drv:
#ifdef CONFIG_SPARC
sunserial_unregister_minors(&serial8250_reg, UART_NR);
@@ -3292,6 +3295,8 @@ static void __exit serial8250_exit(void)
platform_driver_unregister(&serial8250_isa_driver);
platform_device_unregister(isa_dev);
+ serial8250_pnp_exit();
+
#ifdef CONFIG_SPARC
sunserial_unregister_minors(&serial8250_reg, UART_NR);
#else
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 0c5e908..5a76f9c 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -97,3 +97,12 @@ static inline void serial_dl_write(struct uart_8250_port *up, int value)
#else
#define ALPHA_KLUDGE_MCR 0
#endif
+
+#ifdef CONFIG_SERIAL_8250_PNP
+int serial8250_pnp_init(void);
+void serial8250_pnp_exit(void);
+#else
+static inline int serial8250_pnp_init(void) { return 0; }
+static inline void serial8250_pnp_exit(void) { }
+#endif
+
diff --git a/drivers/tty/serial/8250/8250_pnp.c b/drivers/tty/serial/8250/8250_pnp.c
index fde5aa6..28bf830 100644
--- a/drivers/tty/serial/8250/8250_pnp.c
+++ b/drivers/tty/serial/8250/8250_pnp.c
@@ -1,5 +1,5 @@
/*
- * Probe module for 8250/16550-type ISAPNP serial ports.
+ * Probe for 8250/16550-type ISAPNP serial ports.
*
* Based on drivers/char/serial.c, by Linus Torvalds, Theodore Ts'o.
*
@@ -507,18 +507,13 @@ static struct pnp_driver serial_pnp_driver = {
.id_table = pnp_dev_table,
};
-static int __init serial8250_pnp_init(void)
+int serial8250_pnp_init(void)
{
return pnp_register_driver(&serial_pnp_driver);
}
-static void __exit serial8250_pnp_exit(void)
+void serial8250_pnp_exit(void)
{
pnp_unregister_driver(&serial_pnp_driver);
}
-module_init(serial8250_pnp_init);
-module_exit(serial8250_pnp_exit);
-
-MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("Generic 8250/16x50 PnP serial driver");
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index a27dd05..f3d283f 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -33,6 +33,14 @@ config SERIAL_8250
Most people will say Y or M here, so that they can use serial mice,
modems and similar devices connecting to the standard serial ports.
+config SERIAL_8250_PNP
+ bool "8250/16550 PNP device support" if EXPERT
+ depends on SERIAL_8250 && PNP
+ default y
+ ---help---
+ This builds standard PNP serial support. You may be able to
+ disable this feature if you only need legacy serial support.
+
config SERIAL_8250_CONSOLE
bool "Console on 8250/16550 and compatible serial port"
depends on SERIAL_8250=y
@@ -85,14 +93,6 @@ config SERIAL_8250_PCI
disable this feature if you only need legacy serial support.
Saves about 9K.
-config SERIAL_8250_PNP
- tristate "8250/16550 PNP device support" if EXPERT
- depends on SERIAL_8250 && PNP
- default SERIAL_8250
- help
- This builds standard PNP serial support. You may be able to
- disable this feature if you only need legacy serial support.
-
config SERIAL_8250_HP300
tristate
depends on SERIAL_8250 && HP300
diff --git a/drivers/tty/serial/8250/Makefile b/drivers/tty/serial/8250/Makefile
index d7533c7..108fe7f 100644
--- a/drivers/tty/serial/8250/Makefile
+++ b/drivers/tty/serial/8250/Makefile
@@ -2,8 +2,9 @@
# Makefile for the 8250 serial device drivers.
#
-obj-$(CONFIG_SERIAL_8250) += 8250.o
-obj-$(CONFIG_SERIAL_8250_PNP) += 8250_pnp.o
+obj-$(CONFIG_SERIAL_8250) += 8250_core.o
+8250_core-y := 8250.o
+8250_core-$(CONFIG_SERIAL_8250_PNP) += 8250_pnp.o
obj-$(CONFIG_SERIAL_8250_GSC) += 8250_gsc.o
obj-$(CONFIG_SERIAL_8250_PCI) += 8250_pci.o
obj-$(CONFIG_SERIAL_8250_HP300) += 8250_hp300.o
--
1.7.11.4
^ permalink raw reply related
* [PATCH 2/2] 8250: blacklist IR ports
From: Sean Young @ 2012-09-06 22:20 UTC (permalink / raw)
To: Alan Cox, Greg Kroah-Hartman, linux-serial
Cc: David Härdeman, Mauro Carvalho Chehab
In-Reply-To: <cover.1346969721.git.sean@mess.org>
These ports should not be probed, but we need to keep track of them so we
can prevent the legacy (non-PNP) probe of serial ports from touching them
too.
Signed-off-by: Sean Young <sean@mess.org>
---
drivers/tty/serial/8250/8250.c | 16 ++++++++++++++--
drivers/tty/serial/8250/8250_pnp.c | 23 ++++++++++++++++++-----
include/linux/serial_core.h | 3 ++-
3 files changed, 34 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index bc25874..ea9166b 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -290,6 +290,9 @@ static const struct serial8250_config uart_config[] = {
UART_FCR_R_TRIG_00 | UART_FCR_T_TRIG_00,
.flags = UART_CAP_FIFO,
},
+ [PORT_IR] = {
+ .name = "IR port"
+ }
};
/* Uart divisor latch read */
@@ -1897,6 +1900,9 @@ static int serial8250_startup(struct uart_port *port)
unsigned char lsr, iir;
int retval;
+ if (port->type == PORT_IR)
+ return -ENODEV;
+
port->fifosize = uart_config[up->port.type].fifo_size;
up->tx_loadsz = uart_config[up->port.type].tx_loadsz;
up->capabilities = uart_config[up->port.type].flags;
@@ -2554,7 +2560,10 @@ static int serial8250_request_port(struct uart_port *port)
{
struct uart_8250_port *up =
container_of(port, struct uart_8250_port, port);
- int ret = 0;
+ int ret;
+
+ if (port->type == PORT_IR)
+ return -ENODEV;
ret = serial8250_request_std_resource(up);
if (ret == 0 && port->type == PORT_RSA) {
@@ -2573,6 +2582,9 @@ static void serial8250_config_port(struct uart_port *port, int flags)
int probeflags = PROBE_ANY;
int ret;
+ if (port->type == PORT_IR)
+ return;
+
/*
* Find the region that we can probe for. This in turn
* tells us whether we can probe for the type of port.
@@ -3144,7 +3156,7 @@ int serial8250_register_8250_port(struct uart_8250_port *up)
mutex_lock(&serial_mutex);
uart = serial8250_find_match_or_unused(&up->port);
- if (uart) {
+ if (uart && uart->port.type != PORT_IR) {
if (uart->port.dev)
uart_remove_one_port(&serial8250_reg, &uart->port);
diff --git a/drivers/tty/serial/8250/8250_pnp.c b/drivers/tty/serial/8250/8250_pnp.c
index 28bf830..6ab2ce1 100644
--- a/drivers/tty/serial/8250/8250_pnp.c
+++ b/drivers/tty/serial/8250/8250_pnp.c
@@ -25,7 +25,7 @@
#include "8250.h"
#define UNKNOWN_DEV 0x3000
-
+#define IR_PORT 0x0800
static const struct pnp_device_id pnp_dev_table[] = {
/* Archtek America Corp. */
@@ -362,6 +362,12 @@ static const struct pnp_device_id pnp_dev_table[] = {
{ "PNPCXXX", UNKNOWN_DEV },
/* More unknown PnP modems */
{ "PNPDXXX", UNKNOWN_DEV },
+ /* IR ports -- should not be probed. We should keep track of them
+ to prevent the legacy serial driver from probing */
+ { "WEC1022", IR_PORT },
+ { "NSC6001", IR_PORT },
+ { "HWPC224", IR_PORT },
+ { "IBM0071", IR_PORT },
{ "", 0 }
};
@@ -409,7 +415,7 @@ static int __devinit check_resources(struct pnp_dev *dev)
* PnP modems, alternatively we must hardcode all modems in pnp_devices[]
* table.
*/
-static int __devinit serial_pnp_guess_board(struct pnp_dev *dev, int *flags)
+static int __devinit serial_pnp_guess_board(struct pnp_dev *dev)
{
if (!(check_name(pnp_dev_name(dev)) ||
(dev->card && check_name(dev->card->name))))
@@ -428,7 +434,7 @@ serial_pnp_probe(struct pnp_dev *dev, const struct pnp_device_id *dev_id)
int ret, line, flags = dev_id->driver_data;
if (flags & UNKNOWN_DEV) {
- ret = serial_pnp_guess_board(dev, &flags);
+ ret = serial_pnp_guess_board(dev);
if (ret < 0)
return ret;
}
@@ -436,7 +442,10 @@ serial_pnp_probe(struct pnp_dev *dev, const struct pnp_device_id *dev_id)
memset(&uart, 0, sizeof(uart));
if (pnp_irq_valid(dev, 0))
uart.port.irq = pnp_irq(dev, 0);
- if (pnp_port_valid(dev, 0)) {
+ if ((flags & IR_PORT) && pnp_port_valid(dev, 2)) {
+ uart.port.iobase = pnp_port_start(dev, 2);
+ uart.port.iotype = UPIO_PORT;
+ } else if (pnp_port_valid(dev, 0)) {
uart.port.iobase = pnp_port_start(dev, 0);
uart.port.iotype = UPIO_PORT;
} else if (pnp_mem_valid(dev, 0)) {
@@ -451,6 +460,10 @@ serial_pnp_probe(struct pnp_dev *dev, const struct pnp_device_id *dev_id)
"Setup PNP port: port %x, mem 0x%lx, irq %d, type %d\n",
uart.port.iobase, uart.port.mapbase, uart.port.irq, uart.port.iotype);
#endif
+ if (flags & IR_PORT) {
+ uart.port.flags |= UPF_FIXED_PORT | UPF_FIXED_TYPE;
+ uart.port.type = PORT_IR;
+ }
uart.port.flags |= UPF_SKIP_TEST | UPF_BOOT_AUTOCONF;
if (pnp_irq_flags(dev, 0) & IORESOURCE_IRQ_SHAREABLE)
@@ -459,7 +472,7 @@ serial_pnp_probe(struct pnp_dev *dev, const struct pnp_device_id *dev_id)
uart.port.dev = &dev->dev;
line = serial8250_register_8250_port(&uart);
- if (line < 0)
+ if (line < 0 || (flags & IR_PORT))
return -ENODEV;
pnp_set_drvdata(dev, (void *)((long)line + 1));
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 7cf0b68..c7e9edf 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -48,7 +48,8 @@
#define PORT_TEGRA 20 /* NVIDIA Tegra internal UART */
#define PORT_XR17D15X 21 /* Exar XR17D15x UART */
#define PORT_LPC3220 22 /* NXP LPC32xx SoC "Standard" UART */
-#define PORT_MAX_8250 22 /* max port ID */
+#define PORT_IR 23 /* infrared port, has its own driver */
+#define PORT_MAX_8250 23 /* max port ID */
/*
* ARM specific type numbers. These are not currently guaranteed
--
1.7.11.4
^ permalink raw reply related
* [PATCH 0/2] winbond-cir: Fix initialization v2
From: Sean Young @ 2012-09-06 22:20 UTC (permalink / raw)
To: Alan Cox, Greg Kroah-Hartman, linux-serial
Cc: David Härdeman, Mauro Carvalho Chehab
The serial driver will detect the winbond cir device as a serial port,
since it looks exactly like a serial port unless you know what it is
from the PNP ID.
Alan Cox pointed out[1] that the pnp serial probe should be done before
the legacy probe and we should keep track of any IR ports during the
pnp scan. This is an implementation of that idea.
Diffed against tty-next.
[1] http://www.spinics.net/lists/linux-serial/msg06757.html
Sean Young (2):
8250_pnp: merge into 8250 module so pnp probe can done first
8250: blacklist IR ports
drivers/tty/serial/8250/8250.c | 47 ++++++++++++++++++++++++++------------
drivers/tty/serial/8250/8250.h | 9 ++++++++
drivers/tty/serial/8250/8250_pnp.c | 34 ++++++++++++++++-----------
drivers/tty/serial/8250/Kconfig | 16 ++++++-------
drivers/tty/serial/8250/Makefile | 5 ++--
include/linux/serial_core.h | 3 ++-
6 files changed, 75 insertions(+), 39 deletions(-)
--
1.7.11.4
^ permalink raw reply
* Re: [PATCH v4 20/21] serial: omap: move uart_omap_port definition to C file
From: Kevin Hilman @ 2012-09-06 21:58 UTC (permalink / raw)
To: Felipe Balbi
Cc: Greg KH, alan, Tony Lindgren, Linux OMAP Mailing List,
Linux ARM Kernel Mailing List, linux-serial,
Linux Kernel Mailing List, Santosh Shilimkar, Shubhrajyoti Datta,
Sourav Poddar
In-Reply-To: <1346935540-1792-21-git-send-email-balbi@ti.com>
Felipe Balbi <balbi@ti.com> writes:
> nobody needs to access the uart_omap_port structure
> other than omap-serial.c file. Let's move that
> structure definition to the C source file in order
> to prevent anyone from accessing our structure.
>
> Tested-by: Shubhrajyoti D <shubhrajyoti@ti.com>
> Acked-by: Tony Lindgren <tony@atomide.com>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
This one is clearly broken, and causes compile breakage...
> ---
> arch/arm/plat-omap/include/plat/omap-serial.h | 37 --------------------------
> drivers/tty/serial/omap-serial.c | 38 +++++++++++++++++++++++++++
> 2 files changed, 38 insertions(+), 37 deletions(-)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
> index a79ed8b..3c9fd3e 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -105,45 +105,8 @@ struct uart_omap_dma {
> unsigned int rx_timeout;
> };
>
> -struct uart_omap_port {
> - struct uart_port port;
> - struct uart_omap_dma uart_dma;
> - struct device *dev;
> -
> - unsigned char ier;
> - unsigned char lcr;
> - unsigned char mcr;
> - unsigned char fcr;
> - unsigned char efr;
> - unsigned char dll;
> - unsigned char dlh;
> - unsigned char mdr1;
> - unsigned char scr;
> -
> - int use_dma;
> - /*
> - * Some bits in registers are cleared on a read, so they must
> - * be saved whenever the register is read but the bits will not
> - * be immediately processed.
> - */
> - unsigned int lsr_break_flag;
> - unsigned char msr_saved_flags;
> - char name[20];
> - unsigned long port_activity;
> - u32 context_loss_cnt;
> - u32 errata;
> - u8 wakeups_enabled;
>
> int DTR_gpio;
> int DTR_inverted;
> int DTR_active;
The whole struct has moved, but some fields left behind?
This looks to be caused by the rebase which includes Neil Brown's DTR
GPIO change[1]
> -
> - struct pm_qos_request pm_qos_request;
> - u32 latency;
> - u32 calc_latency;
> - struct work_struct qos_work;
> -};
> -
> -#define to_uart_omap_port(p) ((container_of((p), struct uart_omap_port, port)))
> -
> #endif /* __OMAP_SERIAL_H__ */
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 881b652..164c3c9 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -70,6 +70,44 @@
> #define OMAP_UART_MVR_MAJ_SHIFT 8
> #define OMAP_UART_MVR_MIN_MASK 0x3f
>
> +struct uart_omap_port {
> + struct uart_port port;
> + struct uart_omap_dma uart_dma;
> + struct device *dev;
> +
> + unsigned char ier;
> + unsigned char lcr;
> + unsigned char mcr;
> + unsigned char fcr;
> + unsigned char efr;
> + unsigned char dll;
> + unsigned char dlh;
> + unsigned char mdr1;
> + unsigned char scr;
> +
> + int use_dma;
> + /*
> + * Some bits in registers are cleared on a read, so they must
> + * be saved whenever the register is read but the bits will not
> + * be immediately processed.
> + */
> + unsigned int lsr_break_flag;
> + unsigned char msr_saved_flags;
> + char name[20];
> + unsigned long port_activity;
> + u32 context_loss_cnt;
> + u32 errata;
> + u8 wakeups_enabled;
> + unsigned int irq_pending:1;
And this field was not in the original, yet the changelog describes this
as a move.
Why is a this new field added (and not described in the changelog.)
Kevin
[1]
commit 9574f36fb801035f6ab0fbb1b53ce2c12c17d100
Author: NeilBrown <neilb@suse.de>
Date: Mon Jul 30 10:30:26 2012 +1000
OMAP/serial: Add support for driving a GPIO as DTR.
OMAP hardware doesn't provide a phyisical DTR line, but
some configurations may need a DTR line which tracks whether
the device is open or not.
So allow a gpio to be configured as the DTR line.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH] tty_register_device_attr updated for tty-next
From: Tomas Hlavacek @ 2012-09-06 21:46 UTC (permalink / raw)
To: gregkh, alan, linux-serial, linux-kernel; +Cc: marek.vasut, Jiri Slaby
In-Reply-To: <1346966267-1780-1-git-send-email-tmshlvck@gmail.com>
Hello!
On Thu, Sep 6, 2012 at 11:17 PM, Tomas Hlavacek <tmshlvck@gmail.com> wrote:
> Added tty_device_create_release() and bound to dev->release in
> tty_register_device_attr().
> Added tty_port_register_device_attr() and used in uart_add_one_port()
> instead of tty_register_device_attr().
>
> Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
> ---
> drivers/tty/serial/serial_core.c | 8 ++++----
> drivers/tty/tty_io.c | 7 +++++++
> drivers/tty/tty_port.c | 24 ++++++++++++++++++++++++
> include/linux/tty.h | 4 ++++
> 4 files changed, 39 insertions(+), 4 deletions(-)
>
A little bit more explanation regarding this patch: It fixes two
problems with my previous patch (tty: uartclk value from serial_core
exposed to sysfs) which Jiri has pointed out earlier today. Both are
related to the changed interface in the tty-next branch and both
should have been dealt with in the first patch. It also fixes minor
problems (one const keyword added and newlines rearranged in the
uart_get_attr_uartclk() function).
Tomas
^ permalink raw reply
* Re: [PATCH v4 00/21] OMAP UART Patches
From: Paul Walmsley @ 2012-09-06 21:37 UTC (permalink / raw)
To: Felipe Balbi
Cc: Greg KH, alan, Tony Lindgren, Kevin Hilman,
Linux OMAP Mailing List, Linux ARM Kernel Mailing List,
linux-serial, Linux Kernel Mailing List, Santosh Shilimkar,
Shubhrajyoti Datta, Sourav Poddar
In-Reply-To: <1346935540-1792-1-git-send-email-balbi@ti.com>
Hi
On Thu, 6 Sep 2012, Felipe Balbi wrote:
> Hi guys,
>
> here's v4 of the omap uart patchset. No changes other than a rebase on top of
> Greg's tty-next branch and Tony's Acked-by being added to a couple patches
>
> Note: I'm resending the series with Vikram's Software Flow Control fix anyway
> as it can just be ignored if it's decided it needs to go into this merge
> window.
Was curious to know if these have been PM-tested, and if so, under what
configurations?
- Paul
^ permalink raw reply
* [PATCH] tty_register_device_attr updated for tty-next
From: Tomas Hlavacek @ 2012-09-06 21:17 UTC (permalink / raw)
To: gregkh, alan, linux-serial, linux-kernel; +Cc: marek.vasut, Tomas Hlavacek
Added tty_device_create_release() and bound to dev->release in
tty_register_device_attr().
Added tty_port_register_device_attr() and used in uart_add_one_port()
instead of tty_register_device_attr().
Signed-off-by: Tomas Hlavacek <tmshlvck@gmail.com>
---
drivers/tty/serial/serial_core.c | 8 ++++----
drivers/tty/tty_io.c | 7 +++++++
drivers/tty/tty_port.c | 24 ++++++++++++++++++++++++
include/linux/tty.h | 4 ++++
4 files changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index f629bdf..046279c 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2313,9 +2313,9 @@ static ssize_t uart_get_attr_uartclk(struct device *dev,
struct device_attribute *attr, char *buf)
{
int ret;
-
struct tty_port *port = dev_get_drvdata(dev);
struct uart_state *state = container_of(port, struct uart_state, port);
+
mutex_lock(&state->port.mutex);
ret = snprintf(buf, PAGE_SIZE, "%d\n", state->uart_port->uartclk);
mutex_unlock(&state->port.mutex);
@@ -2330,7 +2330,7 @@ static struct attribute *tty_dev_attrs[] = {
NULL,
};
-static struct attribute_group tty_dev_attr_group = {
+static const struct attribute_group tty_dev_attr_group = {
.attrs = tty_dev_attrs,
};
@@ -2392,8 +2392,8 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
* Register the port whether it's detected or not. This allows
* setserial to be used to alter this ports parameters.
*/
- tty_dev = tty_register_device_attr(drv->tty_driver, uport->line,
- uport->dev, port, tty_dev_attr_groups);
+ tty_dev = tty_port_register_device_attr(port, drv->tty_driver,
+ uport->line, uport->dev, port, tty_dev_attr_groups);
if (likely(!IS_ERR(tty_dev))) {
device_set_wakeup_capable(tty_dev, 1);
} else {
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index dcb30d5..8a5a8b0 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3045,6 +3045,12 @@ struct device *tty_register_device(struct tty_driver *driver, unsigned index,
}
EXPORT_SYMBOL(tty_register_device);
+static void tty_device_create_release(struct device *dev)
+{
+ pr_debug("device: '%s': %s\n", dev_name(dev), __func__);
+ kfree(dev);
+}
+
/**
* tty_register_device_attr - register a tty device
* @driver: the tty driver that describes the tty device
@@ -3103,6 +3109,7 @@ struct device *tty_register_device_attr(struct tty_driver *driver,
dev->devt = devt;
dev->class = tty_class;
dev->parent = device;
+ dev->release = tty_device_create_release;
dev_set_name(dev, "%s", name);
dev->groups = attr_grp;
dev_set_drvdata(dev, drvdata);
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 96302f4..d7bdd8d 100644
--- a/drivers/tty/tty_port.c
+++ b/drivers/tty/tty_port.c
@@ -73,6 +73,30 @@ struct device *tty_port_register_device(struct tty_port *port,
}
EXPORT_SYMBOL_GPL(tty_port_register_device);
+/**
+ * tty_port_register_device_attr - register tty device
+ * @port: tty_port of the device
+ * @driver: tty_driver for this device
+ * @index: index of the tty
+ * @device: parent if exists, otherwise NULL
+ * @drvdata: Driver data to be set to device.
+ * @attr_grp: Attribute group to be set on device.
+ *
+ * It is the same as tty_register_device_attr except the provided @port is
+ * linked to a concrete tty specified by @index. Use this or tty_port_install
+ * (or both). Call tty_port_link_device as a last resort.
+ */
+struct device *tty_port_register_device_attr(struct tty_port *port,
+ struct tty_driver *driver, unsigned index,
+ struct device *device, void *drvdata,
+ const struct attribute_group **attr_grp)
+{
+ tty_port_link_device(port, driver, index);
+ return tty_register_device_attr(driver, index, device, drvdata,
+ attr_grp);
+}
+EXPORT_SYMBOL_GPL(tty_port_register_device_attr);
+
int tty_port_alloc_xmit_buf(struct tty_port *port)
{
/* We may sleep in get_zeroed_page() */
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 599d603..1509b86 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -507,6 +507,10 @@ extern void tty_port_link_device(struct tty_port *port,
extern struct device *tty_port_register_device(struct tty_port *port,
struct tty_driver *driver, unsigned index,
struct device *device);
+extern struct device *tty_port_register_device_attr(struct tty_port *port,
+ struct tty_driver *driver, unsigned index,
+ struct device *device, void *drvdata,
+ const struct attribute_group **attr_grp);
extern int tty_port_alloc_xmit_buf(struct tty_port *port);
extern void tty_port_free_xmit_buf(struct tty_port *port);
extern void tty_port_put(struct tty_port *port);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 5/5] omap-serial: Request pins using pinctrl framework
From: Tony Lindgren @ 2012-09-06 21:17 UTC (permalink / raw)
To: Felipe Balbi
Cc: linux-arm-kernel, Greg Kroah-Hartman, linux-omap, linux-serial
In-Reply-To: <20120906195605.GA32145@arwen.pp.htv.fi>
* Felipe Balbi <balbi@ti.com> [120906 13:01]:
> Hi,
>
> On Thu, Sep 06, 2012 at 11:58:32AM -0700, Tony Lindgren wrote:
> > Request pins using pinctrl framework. Only show a warning
> > on error as some boards set the pins in the bootloader
> > even if CONFIG_PINCTRL is enabled.
> >
> > Cc: linux-serial@vger.kernel.org
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Signed-off-by: Tony Lindgren <tony@atomide.com>
> > ---
> > arch/arm/plat-omap/include/plat/omap-serial.h | 1 +
> > drivers/tty/serial/omap-serial.c | 10 ++++++++++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
> > index 1a52725..0f4de14 100644
> > --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> > +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> > @@ -106,6 +106,7 @@ struct uart_omap_port {
> > struct uart_port port;
> > struct uart_omap_dma uart_dma;
> > struct platform_device *pdev;
> > + struct pinctrl *pins;
>
> this won't apply to Greg's tty-next as I moved this structure to the C
> file :-s
Hmm the tty-next fails to build right now for omaps:
drivers/tty/serial/omap-serial.c: In function ‘serial_omap_set_mctrl’:
drivers/tty/serial/omap-serial.c:514: error: ‘struct uart_omap_port’ has no member named ‘DTR_gpio’
Maybe check how you want to fix that first? I can then update
my patch for tty-next.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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 5/5] omap-serial: Request pins using pinctrl framework
From: Felipe Balbi @ 2012-09-06 19:56 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-arm-kernel, Greg Kroah-Hartman, linux-omap, linux-serial
In-Reply-To: <20120906185832.1172.31013.stgit@muffinssi.local>
[-- Attachment #1: Type: text/plain, Size: 1075 bytes --]
Hi,
On Thu, Sep 06, 2012 at 11:58:32AM -0700, Tony Lindgren wrote:
> Request pins using pinctrl framework. Only show a warning
> on error as some boards set the pins in the bootloader
> even if CONFIG_PINCTRL is enabled.
>
> Cc: linux-serial@vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
> arch/arm/plat-omap/include/plat/omap-serial.h | 1 +
> drivers/tty/serial/omap-serial.c | 10 ++++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
> index 1a52725..0f4de14 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -106,6 +106,7 @@ struct uart_omap_port {
> struct uart_port port;
> struct uart_omap_dma uart_dma;
> struct platform_device *pdev;
> + struct pinctrl *pins;
this won't apply to Greg's tty-next as I moved this structure to the C
file :-s
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v6] uartclk value from serial_core exposed to sysfs
From: Jiri Slaby @ 2012-09-06 19:47 UTC (permalink / raw)
To: Tomas Hlavacek; +Cc: gregkh, alan, linux-serial, linux-kernel, marek.vasut
In-Reply-To: <CAEB7QLAk6pe9ih+P_621fZE3JpRcFpPA+Wzk57x3FmVaGmoOKg@mail.gmail.com>
On 09/06/2012 09:41 PM, Tomas Hlavacek wrote:
>> * why are you passing tty_port to the struct device's private data and
>> not uart_port proper? Is this for some future use?
>
> I actually used the uart_port structure in older RFC versions of the
> patch. Alan Cox advised to use struct tty_port because of consistency.
> More precisely he said (in an e-mail from Aug 12):
>
> I'd rather however it pointed
> to the tty_port that each tty device has (or very soon will be required
> to have).
Yes, this is already a requirement in tty-next. And every driver has to
provide us with the tty_port as you might persuaded yourself of that
already ;).
> You can still find the uart_foo structs from that but it means
> we can do the dev_set_drvdata() in a consistent manner for all tty
> devices in the kernel. That in turn means we can make some of the sysfs
> valid the same way.
Ah, OK, makes sense.
>> * cannot be all those attribute structs const?
>
> It seems that making
>
> static const struct attribute *tty_dev_attrs[] = ...
>
> produces warning:
>
> drivers/tty/serial/serial_core.c:2334:2: warning: initialization from
> incompatible pointer type [enabled by default]
> drivers/tty/serial/serial_core.c:2334:2: warning: (near initialization
> for ‘tty_dev_attr_group.attrs’) [enabled by default]
>
> But others can. I am going to make them const in following patch.
Ok, it was only a suggestion. I did not know either.
regards,
--
js
suse labs
--
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 v6] uartclk value from serial_core exposed to sysfs
From: Tomas Hlavacek @ 2012-09-06 19:41 UTC (permalink / raw)
To: Jiri Slaby; +Cc: gregkh, alan, linux-serial, linux-kernel, marek.vasut
In-Reply-To: <5048F161.3000805@suse.cz>
Hello!
On Thu, Sep 6, 2012 at 8:54 PM, Jiri Slaby <jslaby@suse.cz> wrote:
> On 09/06/2012 08:39 PM, Tomas Hlavacek wrote:
>> On Thu, Sep 6, 2012 at 7:54 PM, Jiri Slaby <jslaby@suse.cz> wrote:
>>> On 09/06/2012 03:17 AM, Tomas Hlavacek wrote:
>>>> @@ -2362,8 +2392,8 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
>>>> * Register the port whether it's detected or not. This allows
>>>> * setserial to be used to alter this ports parameters.
>>>> */
>>>> - tty_dev = tty_port_register_device(port, drv->tty_driver, uport->line,
>>>> - uport->dev);
>>>> + tty_dev = tty_register_device_attr(drv->tty_driver, uport->line,
>>>> + uport->dev, port, tty_dev_attr_groups);
>>>
>>> This makes me believe you have not tested the change at all?
>>
>> Thanks! I can't believe I missed that. (And I actually tested that,
>> but I have to admit that it was not enough apparently.)
>>
>> I will re-send the patch (after some additional testing and double-checking).
>
> Ok. A couple more questions...
>
> * why are you passing tty_port to the struct device's private data and
> not uart_port proper? Is this for some future use?
I actually used the uart_port structure in older RFC versions of the
patch. Alan Cox advised to use struct tty_port because of consistency.
More precisely he said (in an e-mail from Aug 12):
I'd rather however it pointed
to the tty_port that each tty device has (or very soon will be required
to have). You can still find the uart_foo structs from that but it means
we can do the dev_set_drvdata() in a consistent manner for all tty
devices in the kernel. That in turn means we can make some of the sysfs
valid the same way.
> * cannot be all those attribute structs const?
It seems that making
static const struct attribute *tty_dev_attrs[] = ...
produces warning:
drivers/tty/serial/serial_core.c:2334:2: warning: initialization from
incompatible pointer type [enabled by default]
drivers/tty/serial/serial_core.c:2334:2: warning: (near initialization
for ‘tty_dev_attr_group.attrs’) [enabled by default]
But others can. I am going to make them const in following patch.
> * kdoc for tty_register_device_attr says that when
> TTY_DRIVER_DYNAMIC_DEV is not set, tty_register_device_attr *should* not
> be called. But it must not be called, otherwise it will fail and emit a
> warning as a bonus, right?
Yes. In fact it does the same thing as tty_register_device() did
before itself. The _attr version is only slightly refactored and the
doc regarding the TTY_DRIVER_DYNAMIC_DEV test is the same as in old
non-_attr version.
I am not sure that I am the right person to change the doc because I
am not an author of this part of doc nor of the test in the function.
> * final remark. I would prefer declaration and code be delimited by a
> new line in uart_get_attr_uartclk:
> <===>
> + int ret;
> +
> + struct tty_port *port = dev_get_drvdata(dev);
> + struct uart_state *state = container_of(port, struct uart_state,
> port);
> + mutex_lock(&state->port.mutex);
> <===>
>
> Like:
> <===>
> struct tty_port *port = ...;
> struct uart_state *state = ...;
> int ret;
>
> mutex_lock(&state->port.mutex);
> <===>
Yes, it looks better. I am going to it accordingly.
Tomas
--
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 5/5] omap-serial: Request pins using pinctrl framework
From: Tony Lindgren @ 2012-09-06 19:12 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Greg Kroah-Hartman, linux-omap, linux-serial
In-Reply-To: <20120906185832.1172.31013.stgit@muffinssi.local>
* Tony Lindgren <tony@atomide.com> [120906 11:59]:
> Request pins using pinctrl framework. Only show a warning
> on error as some boards set the pins in the bootloader
> even if CONFIG_PINCTRL is enabled.
>
> Cc: linux-serial@vger.kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> ---
Greg, this patch should be OK for you to pick, it should not break
anything even if pinctrl is not available yet. Let me know if it
needs rebasing on top of other things you've queued for omap-serial.
Regards,
Tony
> arch/arm/plat-omap/include/plat/omap-serial.h | 1 +
> drivers/tty/serial/omap-serial.c | 10 ++++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
> index 1a52725..0f4de14 100644
> --- a/arch/arm/plat-omap/include/plat/omap-serial.h
> +++ b/arch/arm/plat-omap/include/plat/omap-serial.h
> @@ -106,6 +106,7 @@ struct uart_omap_port {
> struct uart_port port;
> struct uart_omap_dma uart_dma;
> struct platform_device *pdev;
> + struct pinctrl *pins;
>
> unsigned char ier;
> unsigned char lcr;
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index d3cda0c..068e88c 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -39,6 +39,7 @@
> #include <linux/irq.h>
> #include <linux/pm_runtime.h>
> #include <linux/of.h>
> +#include <linux/pinctrl/consumer.h>
>
> #include <plat/dma.h>
> #include <plat/dmtimer.h>
> @@ -1492,6 +1493,13 @@ static int serial_omap_probe(struct platform_device *pdev)
> goto err_port_line;
> }
>
> + up->pins = pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(up->pins)) {
> + dev_warn(&pdev->dev, "did not get pins for uart%i error: %li\n",
> + up->port.line, PTR_ERR(up->pins));
> + up->pins = NULL;
> + }
> +
> sprintf(up->name, "OMAP UART%d", up->port.line);
> up->port.mapbase = mem->start;
> up->port.membase = devm_ioremap(&pdev->dev, mem->start,
> @@ -1570,6 +1578,8 @@ static int serial_omap_remove(struct platform_device *dev)
> pm_runtime_disable(&up->pdev->dev);
> uart_remove_one_port(&serial_omap_reg, &up->port);
> pm_qos_remove_request(&up->pm_qos_request);
> + if (up->pins)
> + pinctrl_put(up->pins);
> }
>
> platform_set_drvdata(dev, NULL);
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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
* [PATCH 5/5] omap-serial: Request pins using pinctrl framework
From: Tony Lindgren @ 2012-09-06 18:58 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Greg Kroah-Hartman, linux-omap, linux-serial
In-Reply-To: <20120906185615.1172.23588.stgit@muffinssi.local>
Request pins using pinctrl framework. Only show a warning
on error as some boards set the pins in the bootloader
even if CONFIG_PINCTRL is enabled.
Cc: linux-serial@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/plat-omap/include/plat/omap-serial.h | 1 +
drivers/tty/serial/omap-serial.c | 10 ++++++++++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/plat-omap/include/plat/omap-serial.h b/arch/arm/plat-omap/include/plat/omap-serial.h
index 1a52725..0f4de14 100644
--- a/arch/arm/plat-omap/include/plat/omap-serial.h
+++ b/arch/arm/plat-omap/include/plat/omap-serial.h
@@ -106,6 +106,7 @@ struct uart_omap_port {
struct uart_port port;
struct uart_omap_dma uart_dma;
struct platform_device *pdev;
+ struct pinctrl *pins;
unsigned char ier;
unsigned char lcr;
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d3cda0c..068e88c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -39,6 +39,7 @@
#include <linux/irq.h>
#include <linux/pm_runtime.h>
#include <linux/of.h>
+#include <linux/pinctrl/consumer.h>
#include <plat/dma.h>
#include <plat/dmtimer.h>
@@ -1492,6 +1493,13 @@ static int serial_omap_probe(struct platform_device *pdev)
goto err_port_line;
}
+ up->pins = pinctrl_get_select_default(&pdev->dev);
+ if (IS_ERR(up->pins)) {
+ dev_warn(&pdev->dev, "did not get pins for uart%i error: %li\n",
+ up->port.line, PTR_ERR(up->pins));
+ up->pins = NULL;
+ }
+
sprintf(up->name, "OMAP UART%d", up->port.line);
up->port.mapbase = mem->start;
up->port.membase = devm_ioremap(&pdev->dev, mem->start,
@@ -1570,6 +1578,8 @@ static int serial_omap_remove(struct platform_device *dev)
pm_runtime_disable(&up->pdev->dev);
uart_remove_one_port(&serial_omap_reg, &up->port);
pm_qos_remove_request(&up->pm_qos_request);
+ if (up->pins)
+ pinctrl_put(up->pins);
}
platform_set_drvdata(dev, NULL);
^ permalink raw reply related
* Re: [PATCH v6] uartclk value from serial_core exposed to sysfs
From: Jiri Slaby @ 2012-09-06 18:54 UTC (permalink / raw)
To: Tomas Hlavacek; +Cc: gregkh, alan, linux-serial, linux-kernel, marek.vasut
In-Reply-To: <CAEB7QLAWLuXFLWMYX70enP5X0z5EXTNo93hfOm7sH_kQteMAkA@mail.gmail.com>
On 09/06/2012 08:39 PM, Tomas Hlavacek wrote:
> On Thu, Sep 6, 2012 at 7:54 PM, Jiri Slaby <jslaby@suse.cz> wrote:
>> On 09/06/2012 03:17 AM, Tomas Hlavacek wrote:
>>> @@ -2362,8 +2392,8 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
>>> * Register the port whether it's detected or not. This allows
>>> * setserial to be used to alter this ports parameters.
>>> */
>>> - tty_dev = tty_port_register_device(port, drv->tty_driver, uport->line,
>>> - uport->dev);
>>> + tty_dev = tty_register_device_attr(drv->tty_driver, uport->line,
>>> + uport->dev, port, tty_dev_attr_groups);
>>
>> This makes me believe you have not tested the change at all?
>
> Thanks! I can't believe I missed that. (And I actually tested that,
> but I have to admit that it was not enough apparently.)
>
> I will re-send the patch (after some additional testing and double-checking).
Ok. A couple more questions...
* why are you passing tty_port to the struct device's private data and
not uart_port proper? Is this for some future use?
* cannot be all those attribute structs const?
* kdoc for tty_register_device_attr says that when
TTY_DRIVER_DYNAMIC_DEV is not set, tty_register_device_attr *should* not
be called. But it must not be called, otherwise it will fail and emit a
warning as a bonus, right?
* final remark. I would prefer declaration and code be delimited by a
new line in uart_get_attr_uartclk:
<===>
+ int ret;
+
+ struct tty_port *port = dev_get_drvdata(dev);
+ struct uart_state *state = container_of(port, struct uart_state,
port);
+ mutex_lock(&state->port.mutex);
<===>
Like:
<===>
struct tty_port *port = ...;
struct uart_state *state = ...;
int ret;
mutex_lock(&state->port.mutex);
<===>
regards,
--
js
suse labs
^ permalink raw reply
* Re: [PATCH v6] uartclk value from serial_core exposed to sysfs
From: Tomas Hlavacek @ 2012-09-06 18:39 UTC (permalink / raw)
To: Jiri Slaby; +Cc: gregkh, alan, linux-serial, linux-kernel, marek.vasut
In-Reply-To: <5048E35F.5020304@suse.cz>
Hi Jiri,
On Thu, Sep 6, 2012 at 7:54 PM, Jiri Slaby <jslaby@suse.cz> wrote:
> On 09/06/2012 03:17 AM, Tomas Hlavacek wrote:
>> @@ -2362,8 +2392,8 @@ int uart_add_one_port(struct uart_driver *drv, struct uart_port *uport)
>> * Register the port whether it's detected or not. This allows
>> * setserial to be used to alter this ports parameters.
>> */
>> - tty_dev = tty_port_register_device(port, drv->tty_driver, uport->line,
>> - uport->dev);
>> + tty_dev = tty_register_device_attr(drv->tty_driver, uport->line,
>> + uport->dev, port, tty_dev_attr_groups);
>
> This makes me believe you have not tested the change at all?
Thanks! I can't believe I missed that. (And I actually tested that,
but I have to admit that it was not enough apparently.)
I will re-send the patch (after some additional testing and double-checking).
Tomas
^ 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