[RFC DO NOT MERGE] tty: n_gsm: support buggy modem

[RFC DO NOT MERGE] tty: n_gsm: support buggy modem

[Lars Poeschel]

From: Lars Poeschel <poeschel@lemonage.de>

This is obiviously a bad patch. Do not merge it!
I have a GSM Modem (Quectel M95 Revision: M95AR01A11) that I have a problem
with when using the n_gsm mux line discipline. After attaching the line
discipline and opening a muxed channel, the open never returns. The
problem is that the tty code waits for the TIOCM_CD flag to be set. According
to the 3GPP TS 07.10 specification the modem can set this virtual flag by
setting the DV bit in it's modem status control message. My modem sends the
modem status command, but this DV bit is not set. With this patch the modem
and the whole mux is working fine. Another way makeing all this work is
setting the carrier_raised function to NULL. The tty code assumes that
everything is alright then.
My question is: What could be the best way to support this modem in mailine
kernel ? I do not see a way to detect this buggy modem inside the line
discipline and use this patch's method as a work around then. But the
detection would only be possible using AT command before the line discipline
is attached or using the muxed channel after the mux is set up.

Thanks,
Lars
---
diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
index c0f76da..a1a6f57 100644
--- a/drivers/tty/n_gsm.c
+++ b/drivers/tty/n_gsm.c
@@ -1061,6 +1061,7 @@ static void gsm_process_modem(struct tty_struct *tty, struct gsm_dlci *dlci,
 		mlines |= TIOCM_RI;
 	if (modem & MDM_DV)
 		mlines |= TIOCM_CD;
+	mlines |= TIOCM_CD;
 
 	/* Carrier drop -> hangup */
 	if (tty) {

Re: [RFC DO NOT MERGE] tty: n_gsm: support buggy modem

[Greg KH]

On Tue, Jan 07, 2014 at 02:05:26PM +0100, Lars Poeschel wrote:
> From: Lars Poeschel <poeschel@lemonage.de>
> 
> This is obiviously a bad patch. Do not merge it!
> I have a GSM Modem (Quectel M95 Revision: M95AR01A11) that I have a problem
> with when using the n_gsm mux line discipline. After attaching the line
> discipline and opening a muxed channel, the open never returns. The
> problem is that the tty code waits for the TIOCM_CD flag to be set. According
> to the 3GPP TS 07.10 specification the modem can set this virtual flag by
> setting the DV bit in it's modem status control message. My modem sends the
> modem status command, but this DV bit is not set. With this patch the modem
> and the whole mux is working fine. Another way makeing all this work is
> setting the carrier_raised function to NULL. The tty code assumes that
> everything is alright then.
> My question is: What could be the best way to support this modem in mailine
> kernel ? I do not see a way to detect this buggy modem inside the line
> discipline and use this patch's method as a work around then. But the
> detection would only be possible using AT command before the line discipline
> is attached or using the muxed channel after the mux is set up.

Adding some n_gsm.c authors to the cc:

Also, what kernel version are you using?

thanks,

greg k-h

> 
> Thanks,
> Lars
> ---
> diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> index c0f76da..a1a6f57 100644
> --- a/drivers/tty/n_gsm.c
> +++ b/drivers/tty/n_gsm.c
> @@ -1061,6 +1061,7 @@ static void gsm_process_modem(struct tty_struct *tty, struct gsm_dlci *dlci,
>  		mlines |= TIOCM_RI;
>  	if (modem & MDM_DV)
>  		mlines |= TIOCM_CD;
> +	mlines |= TIOCM_CD;
>  
>  	/* Carrier drop -> hangup */
>  	if (tty) {

Re: [RFC DO NOT MERGE] tty: n_gsm: support buggy modem

[Alan Cox]

> > modem status command, but this DV bit is not set. With this patch the modem
> > and the whole mux is working fine. Another way makeing all this work is
> > setting the carrier_raised function to NULL. The tty code assumes that
> > everything is alright then.

Which means your modem has decided it doesn't yet have a carrier. Do you
get a carrier after ATD completes with a CONNECTED message ?

(you can open with O_NDELAY to avoid blocking on the open)

Alan

Re: [RFC DO NOT MERGE] tty: n_gsm: support buggy modem

[Lars Poeschel]

Am Dienstag, 7. Januar 2014, 16:51:37 schrieb Alan Cox:
> > > modem status command, but this DV bit is not set. With this patch the
> > > modem
> > > and the whole mux is working fine. Another way makeing all this work is
> > > setting the carrier_raised function to NULL. The tty code assumes that
> > > everything is alright then.
> 
> Which means your modem has decided it doesn't yet have a carrier. Do you
> get a carrier after ATD completes with a CONNECTED message ?
> 
> (you can open with O_NDELAY to avoid blocking on the open)

Oh! Thank you! This does indeed bring up the channel. After opening 
nonblocking and writing ATD *99***1# to a muxed channel the modem sends a 
modem status command message with DV bit set.
This does in fact mean, I can only use the mux in nonblocking mode. Does this 
make sense ? Why can't I use a muxed channel with blocking IO ? I could do AT 
commands over the mux channel and the DV bit is not set (and thus TIOCM_CD is 
not set) and the modem (and the mux line discipline) is fine with it.

Re: [RFC DO NOT MERGE] tty: n_gsm: support buggy modem

[Lars Poeschel]

Am Dienstag, 7. Januar 2014, 06:20:50 schrieb Greg KH:
> On Tue, Jan 07, 2014 at 02:05:26PM +0100, Lars Poeschel wrote:
> > From: Lars Poeschel <poeschel@lemonage.de>
> > 
> > This is obiviously a bad patch. Do not merge it!
> > I have a GSM Modem (Quectel M95 Revision: M95AR01A11) that I have a
> > problem
> > with when using the n_gsm mux line discipline. After attaching the line
> > discipline and opening a muxed channel, the open never returns. The
> > problem is that the tty code waits for the TIOCM_CD flag to be set.
> > According to the 3GPP TS 07.10 specification the modem can set this
> > virtual flag by setting the DV bit in it's modem status control message.
> > My modem sends the modem status command, but this DV bit is not set. With
> > this patch the modem and the whole mux is working fine. Another way
> > makeing all this work is setting the carrier_raised function to NULL. The
> > tty code assumes that everything is alright then.
> > My question is: What could be the best way to support this modem in
> > mailine
> > kernel ? I do not see a way to detect this buggy modem inside the line
> > discipline and use this patch's method as a work around then. But the
> > detection would only be possible using AT command before the line
> > discipline is attached or using the muxed channel after the mux is set
> > up.
> 
> Adding some n_gsm.c authors to the cc:
> 
> Also, what kernel version are you using?

Sorry, I forgot this.
I am using 3.12. After your mail I tried 3.13-rc7. It behaves exactly the 
same.

> > ---
> > diff --git a/drivers/tty/n_gsm.c b/drivers/tty/n_gsm.c
> > index c0f76da..a1a6f57 100644
> > --- a/drivers/tty/n_gsm.c
> > +++ b/drivers/tty/n_gsm.c
> > @@ -1061,6 +1061,7 @@ static void gsm_process_modem(struct tty_struct
> > *tty, struct gsm_dlci *dlci,> 
> >  		mlines |= TIOCM_RI;
> >  	
> >  	if (modem & MDM_DV)
> >  	
> >  		mlines |= TIOCM_CD;
> > 
> > +	mlines |= TIOCM_CD;
> > 
> >  	/* Carrier drop -> hangup */
> >  	if (tty) {