headers
Yinghai Lu | 1 Aug 2012 02:47

Re: [PATCH 12/12] tty: move the handling of the tty release logic

On Fri, Jun 22, 2012 at 8:47 AM, Alan Cox <alan <at> lxorguk.ukuu.org.uk> wrote:
> Now that we don't have tty->termios tied to drivers->tty we can untangle
> the logic here. In addition we can push the removal logic out of the
> destructor path.
>
> At that point we can think about sorting out tty_port and console and all
> the other ugly hangovers.
>
> An important other property we now have is that the tty mutex does now cover
> the drivers array. An assumption other bits of the code made and which is
> necessary for the tty lock patch.
>
> Signed-off-by: Alan Cox <alan <at> linux.intel.com>
> ---
>
>  drivers/tty/pty.c               |    8 --------
>  drivers/tty/tty_io.c            |   16 +++++-----------
>  drivers/tty/vt/vt.c             |    1 -
>  drivers/usb/serial/usb-serial.c |    3 +--
>  include/linux/tty.h             |    1 -
>  include/linux/tty_driver.h      |   11 +++--------
>  6 files changed, 9 insertions(+), 31 deletions(-)

Hi, Alan

This one cause regression on my test setup.

that setup is booting from pxe and initrd is updated from opensuse
11.3 rescue disk.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yinghai Lu | 1 Aug 2012 02:51

Re: [PATCH 09/12] commit 22126843cb3c2a782c2d52614486115f3e9db478

On Fri, Jun 22, 2012 at 10:04 AM, Alan Cox <alan <at> lxorguk.ukuu.org.uk> wrote:
> On Fri, 22 Jun 2012 08:36:57 -0700
> Greg KH <gregkh <at> linuxfoundation.org> wrote:
>
>> On Fri, Jun 22, 2012 at 04:44:59PM +0100, Alan Cox wrote:
>> > From: Alan Cox <alan <at> linux.intel.com>
>> >
>> > tty: move the termios object into the tty
>> >
>> >     This will let us sort out a whole pile of tty related races. The
>> >     alternative would be to keep points and refcount the termios objects.
>> >     However
>> >     1. They are tiny anyway
>> >     2. Many devices don't use the stored copies
>> >     3. We can remove a pty special case
>> >
>> >     Signed-off-by: Alan Cox <alan <at> linux.intel.com>
>>
>> Odd subject line, and formatting, did something go wrong with your
>> scripts?
>
> Apparently so. I will given them a stern talking to and repost

looks the one in tty-next still missed some changes...

commit adc8d746caa67fff4b53ba3e5163a6cbacc3b523
Author: Alan Cox <alan <at> linux.intel.com>
Date:   Sat Jul 14 15:31:47 2012 +0100

    tty: move the termios object into the tty
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Shiyan | 1 Aug 2012 10:00
Picon

[PATCH] serial: sc26xx: Fix compile breakage

This patch fixes the following compile breakage:

  CC      drivers/tty/serial/sc26xx.o
drivers/tty/serial/sc26xx.c: In function 'read_sc_port':
drivers/tty/serial/sc26xx.c:100: error: implicit declaration of function 'readb'
drivers/tty/serial/sc26xx.c: In function 'write_sc_port':
drivers/tty/serial/sc26xx.c:105: error: implicit declaration of function 'writeb'
drivers/tty/serial/sc26xx.c: In function 'sc26xx_probe':
drivers/tty/serial/sc26xx.c:652: error: implicit declaration of function 'ioremap_nocache'
drivers/tty/serial/sc26xx.c:652: warning: assignment makes pointer from integer without a cast
make[3]: *** [drivers/tty/serial/sc26xx.o] Error 1
make[2]: *** [drivers/tty/serial] Error 2
make[1]: *** [drivers/tty] Error 2
make: *** [drivers] Error 2

Signed-off-by: Alexander Shiyan <shc_work <at> mail.ru>
---
 drivers/tty/serial/sc26xx.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/sc26xx.c b/drivers/tty/serial/sc26xx.c
index e0b4b0a..3992e48 100644
--- a/drivers/tty/serial/sc26xx.c
+++ b/drivers/tty/serial/sc26xx.c
 <at>  <at>  -20,6 +20,7  <at>  <at> 
 #include <linux/init.h>
 #include <linux/platform_device.h>
 #include <linux/irq.h>
+#include <linux/io.h>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Greg Kroah-Hartman | 1 Aug 2012 14:56
Favicon
Gravatar

Re: [PATCH] serial: sc26xx: Fix compile breakage

On Wed, Aug 01, 2012 at 12:00:20PM +0400, Alexander Shiyan wrote:
> This patch fixes the following compile breakage:
> 
>   CC      drivers/tty/serial/sc26xx.o
> drivers/tty/serial/sc26xx.c: In function 'read_sc_port':
> drivers/tty/serial/sc26xx.c:100: error: implicit declaration of function 'readb'
> drivers/tty/serial/sc26xx.c: In function 'write_sc_port':
> drivers/tty/serial/sc26xx.c:105: error: implicit declaration of function 'writeb'
> drivers/tty/serial/sc26xx.c: In function 'sc26xx_probe':
> drivers/tty/serial/sc26xx.c:652: error: implicit declaration of function 'ioremap_nocache'
> drivers/tty/serial/sc26xx.c:652: warning: assignment makes pointer from integer without a cast
> make[3]: *** [drivers/tty/serial/sc26xx.o] Error 1
> make[2]: *** [drivers/tty/serial] Error 2
> make[1]: *** [drivers/tty] Error 2
> make: *** [drivers] Error 2

Breakage in what tree?  What caused this to break?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 3 comments |
headers
Greg Kroah-Hartman | 1 Aug 2012 17:04
Favicon
Gravatar

Re: [PATCH] serial: sc26xx: Fix compile breakage

On Wed, Aug 01, 2012 at 06:55:30PM +0400, Alexander Shiyan wrote:
> Hello.
> 
> Wed, 1 Aug 2012 05:56:37 -0700 от Greg Kroah-Hartman <gregkh <at> linuxfoundation.org>:
> > On Wed, Aug 01, 2012 at 12:00:20PM +0400, Alexander Shiyan wrote:
> > > This patch fixes the following compile breakage:
> > >   CC      drivers/tty/serial/sc26xx.o
> > > drivers/tty/serial/sc26xx.c: In function 'read_sc_port':
> > > drivers/tty/serial/sc26xx.c:100: error: implicit declaration of function 'readb'
> > > drivers/tty/serial/sc26xx.c: In function 'write_sc_port':
> > > drivers/tty/serial/sc26xx.c:105: error: implicit declaration of function 'writeb'
> > > drivers/tty/serial/sc26xx.c: In function 'sc26xx_probe':
> > > drivers/tty/serial/sc26xx.c:652: error: implicit declaration of function 'ioremap_nocache'
> > > drivers/tty/serial/sc26xx.c:652: warning: assignment makes pointer from integer without a cast
> > > make[3]: *** [drivers/tty/serial/sc26xx.o] Error 1
> > > make[2]: *** [drivers/tty/serial] Error 2
> > > make[1]: *** [drivers/tty] Error 2
> > > make: *** [drivers] Error 2
> > 
> > Breakage in what tree?  What caused this to break?
> Breakage due to missing header linux/io.h.

Again, where did this break (3.4, 3.5, 3.6-rc1, 2.6.32, etc.) and what
caused it to break (what patch?)
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander Shiyan | 1 Aug 2012 16:55
Picon

Re[2]: [PATCH] serial: sc26xx: Fix compile breakage

Hello.

Wed, 1 Aug 2012 05:56:37 -0700 от Greg Kroah-Hartman <gregkh <at> linuxfoundation.org>:
> On Wed, Aug 01, 2012 at 12:00:20PM +0400, Alexander Shiyan wrote:
> > This patch fixes the following compile breakage:
> >   CC      drivers/tty/serial/sc26xx.o
> > drivers/tty/serial/sc26xx.c: In function 'read_sc_port':
> > drivers/tty/serial/sc26xx.c:100: error: implicit declaration of function 'readb'
> > drivers/tty/serial/sc26xx.c: In function 'write_sc_port':
> > drivers/tty/serial/sc26xx.c:105: error: implicit declaration of function 'writeb'
> > drivers/tty/serial/sc26xx.c: In function 'sc26xx_probe':
> > drivers/tty/serial/sc26xx.c:652: error: implicit declaration of function 'ioremap_nocache'
> > drivers/tty/serial/sc26xx.c:652: warning: assignment makes pointer from integer without a cast
> > make[3]: *** [drivers/tty/serial/sc26xx.o] Error 1
> > make[2]: *** [drivers/tty/serial] Error 2
> > make[1]: *** [drivers/tty] Error 2
> > make: *** [drivers] Error 2
> 
> Breakage in what tree?  What caused this to break?
Breakage due to missing header linux/io.h.
Permalink | Reply | 2 comments |
headers
Guillaume JUAN | 1 Aug 2012 17:36

n_gsm issues


Hi,

For an embedded project with Linux inside, I am using the kernel N_GSM line
discipline (linux/drivers/tty/n_gsm.c)

It is great to have the 3GPP 27.010 multiplexing protocol integrated as a
kernel driver (previous project used user-space gsmMuxd instead),
and I am thankful for that.

However it happened I struck on some problems with n_gsm.

Who can I contact to discuss issues / submit fixes ?

Examples of problems I spotted:

- gsmld_output can cause a kernel panic dereferencing null pointer
gsm->tty.
This happens especially because gsm_ttty_hangup() calls
gsm_dlci_begin_close() even in the gsm->dead case, leading to asynchronous
send (from timer T1) after gsm->tty was set null.
gsm_tty_hangup() is called synchronously from gsm_cleanup_mux() via
gsm_dlci_release(), a few insstructions before gsmld_detach_gsm() sets
gsmt->tty null.

- When a virtual tty is closed from user-space, the operation is not fully
synchronous: DISC requests can be sent on the DLCI after the system call
has returned.
This is because gsmtty_close does not wait for event DLCI_CLOSED after
calling gsm_dlci_begin_close.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alexander Shiyan | 1 Aug 2012 19:44
Picon

Re: [PATCH] serial: sc26xx: Fix compile breakage

On Wed, 1 Aug 2012 08:04:40 -0700
Greg Kroah-Hartman <gregkh <at> linuxfoundation.org> wrote:

> On Wed, Aug 01, 2012 at 06:55:30PM +0400, Alexander Shiyan wrote:
> > Wed, 1 Aug 2012 05:56:37 -0700 от Greg Kroah-Hartman <gregkh <at> linuxfoundation.org>:
> > > On Wed, Aug 01, 2012 at 12:00:20PM +0400, Alexander Shiyan wrote:
> > > > This patch fixes the following compile breakage:
> > > >   CC      drivers/tty/serial/sc26xx.o
> > > > drivers/tty/serial/sc26xx.c: In function 'read_sc_port':
> > > > drivers/tty/serial/sc26xx.c:100: error: implicit declaration of function 'readb'
> > > > drivers/tty/serial/sc26xx.c: In function 'write_sc_port':
> > > > drivers/tty/serial/sc26xx.c:105: error: implicit declaration of function 'writeb'
> > > > drivers/tty/serial/sc26xx.c: In function 'sc26xx_probe':
> > > > drivers/tty/serial/sc26xx.c:652: error: implicit declaration of function 'ioremap_nocache'
> > > > drivers/tty/serial/sc26xx.c:652: warning: assignment makes pointer from integer without a cast
> > > > make[3]: *** [drivers/tty/serial/sc26xx.o] Error 1
> > > > make[2]: *** [drivers/tty/serial] Error 2
> > > > make[1]: *** [drivers/tty] Error 2
> > > > make: *** [drivers] Error 2
> > > 
> > > Breakage in what tree?  What caused this to break?
> > Breakage due to missing header linux/io.h.
> 
> Again, where did this break (3.4, 3.5, 3.6-rc1, 2.6.32, etc.) and what
> caused it to break (what patch?)

I'm using kernel 3.4.5. Perhaps, the problem not in header that missing, but is that I build
a driver for ARM platform, i.e. with a patched Makefile. In any case, you can just drop this
patch. I use these ICs with ARM architecture, and so I write an improved version of the driver
that will support all ICs from this series and do not depend on the architecture.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Cox | 1 Aug 2012 23:23
Face
Picon

Re: n_gsm issues

> Who can I contact to discuss issues / submit fixes ?

This list and me more specifically.

> - When a virtual tty is closed from user-space, the operation is not fully
> synchronous: DISC requests can be sent on the DLCI after the system call
> has returned.
> This is because gsmtty_close does not wait for event DLCI_CLOSED after
> calling gsm_dlci_begin_close.

That one is intentional.

> - On line discipline attach, n_gsm use default settings that have no chance
> to match what I set in the modem
> and when I do the TIOCSETCONF ioctl to configure it correctly, this
> previous settings cause it to call gsm_cleanup_mux(), leading to delays and
> useless commands to the modem (that won't be answered).

We start in passive mode to tyr and avoid useless commands but could
certainly be improved.

> - The CLD command encoding is not strictly compliant with 3GPP 27.010
> The TLV built does not have any L byte, whereas it should have one
> indicating a zero length for the value field.
> The modem I use accept this variant but some may not.

What kernel verison is this ?

> This issue is the most disturbing for me, as I consequently can see no way
> to end mux session in a fully satisfying way.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Guillaume JUAN | 2 Aug 2012 14:37

Réf. : Re: n_gsm issues

Hi Alan,

Thanks for your quick reply.

> > - The CLD command encoding is not strictly compliant with 3GPP 27.010
> > The TLV built does not have any L byte, whereas it should have one
> > indicating a zero length for the value field.
> > The modem I use accept this variant but some may not.
>
> What kernel verison is this ?

I'm using a 2.6.35 kernel, but I have upgraded specifically n_gsm.c to the
latest version I found in
      git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
('git describe' tells me it is v3.5-8833-g2d53492)
I also checked that I had all the n_gsm changes from
      git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
Is there anything newer ?

About CLD command I referred to the following line of code:
      gc = gsm_control_send(gsm, CMD_CLD, NULL, 0);
Passing NULL makes the function not put any L byte in the TLV.
The 3GPP 27.007 chapter 5.4.6.1 states
"
All [control] messages sent between the multiplexers conform to the
following type, length, value format:
      Type  Length      Value 1     Value2      …     Value n
Each box in the diagram represents a field of minimum size one octet.
"
From which I understand length should be present even if 0.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane