[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] kernel mode on ARM+kernel2.4 : ppp problem fixed.



Hi,

> > Are you saying that the default case should NOT forward the 
> ioctl to the
> > sertty->driver?
> 
> Yes. bt_ioctl should not call sertty->driver->ioctl. That is 
> the job of 
> tty_ioctl() (in tty_io.c).
> 

The only reason for the forwarding was to make it possible for the 
application running on top of a BT device to communicate with the lower
driver. I know that we had problems with this in the 'early' days of the
stack but now I cannot either see any reason for keeping it.

The application using the BT device should not need to care about how the 
lower driver is setup (baudrate, termios settings etc), that is the job of btd 
or similar. So, I think it is safe to remove it. 

However, except for the missing check of the ioctl function (!=NULL) I cannot see
why your code should react strangely on the forwarding of the ioctl.
If the forwarded ioctl is not destined for the serial driver either it will just 
reply with the same error code as the default case in bt_ioctl (-ENOIOCTLCMD).

Will you check it in David ?

/Mattias

> > Is the problem that the driver does not return -ENOIOCTLCMD?
> 
> bt_ioctl should return -ENOIOCTLCMD so that tty_ioctl (in 
> tty_io.c) forwards 
> that ioctl to the line discipline.
> 
> I have done the modification, and it works fine on my system.
> 
> >
> > Marcus
> >
> > david LIBAULT wrote:
> > > Hi all,
> > >
> > > I answer to my message myself as nobldy else does ;-)
> > >
> > > I found a bug in bluetooth.c causing ppp not to work with 
> the stack.
> > > In function bt_ioctl, when an ioctl is not "recognised" 
> it is forwarded
> > > to the "serial driver". If you remember, this was causing 
> the stack to
> > > crash as my serial port didn't support ioctls (the 
> pointer was set to
> > > NULL)... So this also causes ppp not to work ! So, I 
> think it should be
> > > fixed.
> > >
> > > Explanations :
> > >
> > > When pppd opens ttyBT0, it sets its line discipline to 
> N_PPP, and sends
> > > ioctls to ttyBT0 destinated to the N_PPP line discipline. 
> When an ioctl
> > > is sent to a tty (see in the kernel /drivers/char/tty_io.c), first
> > > tty_ioctl is called. If the ioctl is not supported, then
> > > tty->driver->ioctl (registered by tty_register_driver), 
> is called (if not
> > > NULL which is very nice if your serial driver doesn't 
> implement the ioctl
> > > function). If it doesn't support the ioctl, 
> tty->driver->ioctl should
> > > return the value -ENOIOCTLCMD (which is not the case for 
> ttyBT0), causing
> > > the tty->ldisc->ioctl (in our case from the N_PPP line disc) to be
> > > called.
> > >
> > > So, in bt_ioctl, the default case should return -ENOIOCTLCMD.
> > > With this change I could connect the ppp/ip layer.
> > > How comes nobody as ever seen this problem ? Is it a tty 
> change beetween
> > > older kernel and kernel 2.4 ?
> > >
> > > David.
> > >
> > > Le Lundi 05 Mars 2001 11:22, david LIBAULT a écrit :
> > >> Hi all,
> > >>
> > >> When trying to establish a ppp link I get the following problem :
> > >>> rf_conn 00:50:CD:11:10:AD 1 0
> > >>
> > >> Connected.
> > >>
> > >>> ppp
> > >>
> > >> Starting modem_emulator
> > >> Modem done.
> > >> build_pppdopt
> > >> pppd
> > >> /dev/ttyBT0
> > >> 57600
> > >> crtscts
> > >> debug
> > >> local
> > >> nodetach
> > >> nopersist
> > >> silent
> > >> passive
> > >> noauth
> > >> proxyarp
> > >> ktune
> > >> 10.0.0.1:10.0.0.2
> > >> start pppd...
> > >> using channel 0
> > >> Couldn't attach to channel 0: Device not configured
> > >> ppp child died, now restart
> > >> Starting modem_emulator
> > >>
> > >> What is a channel for ppp ? What Device is it complaining about,
> > >> /dev/ttyBT0 ?
> > >>
> > >> David.
> > >>
> > >> Le Samedi 03 Mars 2001 20:44, david LIBAULT a écrit :
> > >>> Hi all,
> > >>>
> > >>> The UART problem has been fixed (by Russel King). It 
> comes from the
> > >>> fact that printk() disables interrupts causing the uart to miss
> > >>> bytes... This of course was not happening in user mode 
> ! So changing
> > >>> the log level fixes the problem (for the moment).
> > >>> I have been able to setup an RF_COMM channel beetween 
> to machines. I
> > >>> now have to setup ppp and see if we have the same 
> problem in kernel
> > >>> mode than in user mode...
> > >>>
> > >>> David.
> > >>>
> > >>> Le Vendredi 02 Mars 2001 22:16, Gordon McNutt a écrit :
> > >>>> david LIBAULT wrote:
> > >>>>>> If my theory is correct then sertty->driver.ioctl 
> will be munged up
> > >>>>>> (from the modules's perspective) all the time -- even at
> > >>>>>> registration.
> > >>>>>
> > >>>>> Well, it is not :
> > >>>>>
> > >>>>> sertty : 0xc04e8000
> > >>>>> sertty->driver : 0xc04e8004
> > >>>>> sertty->driver.ioctl : 0xc04e8080 (at this address 
> the value is 0)
> > >>>>>
> > >>>>> These values look good to me, considering the start 
> address of the
> > >>>>> DRAM, and the shape of the structure.
> > >>>>
> > >>>> Ok, if those addresses look like they make sense to you.
> > >>>>
> > >>>>> I am checking the serial driver. I am working on an 
> EP7211, and the
> > >>>>> serial driver looks loosy...
> > >>>>
> > >>>> Yes, often these arm archs define their own serial 
> drivers. Sometimes
> > >>>> all they want is a console driver so they leave things out...
> > >>>>
> > >>>> --gmcnutt
> > >>>
> > >>> -------------------------------------------------------
> > >>> -
> > >>> To unsubscribe from this list: send the line "unsubscribe
> > >>> bluetooth-dev" in the body of a message to majordomo@xxxxxxx.com
> > >>
> > >> -
> > >> To unsubscribe from this list: send the line 
> "unsubscribe bluetooth-dev"
> > >> in the body of a message to majordomo@xxxxxxx.com
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe 
> bluetooth-dev"
> > > in the body of a message to majordomo@xxxxxxx.com
> -
> To unsubscribe from this list: send the line "unsubscribe 
> bluetooth-dev" in
> the body of a message to majordomo@xxxxxxx.com
> 
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com