Re: [PATCH 3.12 16/33] isdn/gigaset: reset tty->receive_room when attaching ser_gigaset

[Paul Bolle <pebolle@tiscali.nl>]

On ma, 2015-09-21 at 18:07 +0200, Tilman Schmidt wrote:
> Am 21.09.2015 um 15:13 schrieb Peter Hurley:
> > ???
> > 
> > The tool you authored will do it from the command line
> > 
> > $ ldattach PPP /dev/ttyS1
> > $ ldattach GIGASET_M101 /dev/ttyS1
> > 
> > Note that nothing here closes the serial device 'in between', and
> > the tty core has switched directly from PPP to GIGASET_M101.
> > n_tty->receive_room is now 64K.
> 
> Indeed it does. I stand corrected. The possibility of running ldattach a
> second time without terminating the first instance didn't occur to me.

Naive question: when would running ldattach a second time make sense?

> > Please add switching from line disciplines other than N_TTY to your
> > regression testing.
> 
> I don't do regression tests for the driver anymore since I stepped down
> as a maintainer, so that would be up to the present maintainer of
> ser_gigaset. But I see no reason for that. As I already explained, N_TTY
> is the only problematic case.

I'm the current maintainer. (By virtue of having a stash of gigaset
hardware _and_ an ISDN capable line _and_ an ISP that still answers when
I do ISDN dial up. That ISP also does ADSL, which I actually use on a
day to day basis.) I try to test whether ISDN still has a pulse, every
RC, but I can't promise much.

(Off topic: does anyone actually _care_ about ISDN? It seems the other
two ISDN maintainers all have effectively left mainline. Now I'm happy
to (lightly!) test mainline ISDN support as long as that's feasible, but
I'd _really_ like to hear from people using ISDN on machines running
currently supported kernels. Are there any left?)

> Again, I won't oppose applying this patch to stable releases before
> 3.10. I just don't see the need, so it would be up to you to advocate
> such a request.

That would be fixing a theoretical problem, as apparently no one managed
to hit this problem before v3.10 _in practice_, so that's not something
I see a need for either.

Thanks,


Paul Bolle