Hi Marcel, On 04/03/2015 01:39 PM, Marcel Holtmann wrote: > Hi Peter, > >>>> The line discipline is always notified of line rate changes >>>> via the set_termios() method, so if you add that to the hci_ldisc, >>>> you'll be able to keep the BT device in sync with your >>>> vendor-specific commands. >>> If I'm not wrong, line discipline is notified after the tty termios change. >>> So, it's too late to send the HCI change speed command. >>> Moreover, user space is not aware of the device behavior, the driver should >>> be the only one to manage the device and its serial link. >>> Here, user space is just a bootstrap which hands over to the driver. >> >> You realize that you're telling me that userspace is unaware of >> this in a thread that begins with a proposed userspace ioctl change to >> the line discipline? An ioctl change that adds a new ioctl to set the >> speed in a line discipline? For which there are already lots of ioctls >> to set the line speed? > > actually the problem is a little bit different here. Thanks for taking the time to outline the operation of hciattach. It's been a while since I was involved in the BT userspace code so I hadn't realized how much hciattach had morphed. > Every Bluetooth UART chip has its default baudrate. Mostly that is 115k, but some actually have others. > > The general idea was that userspace deals with opening the TTY, send the HCI commands to change the rate, then change the termios setting, attach the ldisc and then hand it to the kernel. > > This is however not how at least two major Bluetooth controllers work when you have to do firmware loading. When they boot into the firmware, then baudrate falls back to default and you have to do that all over again. > > So what this ioctl will just tell the kernel about is the desired baudrate that it wants to be set whenever possible. The whenever possible is important here since depending on the manufacturer that might be a total different times. And with firmware download procedures being fully vendor specific this will vary. > >> Setting aside the problem with the firmware load, I see no reason why >> this can't be done within the existing line discipline framework. > > So far everything has been done in hciattach tool. And it is so ugly and does not even work properly for any complex UART protocols like BCSP or 3-Wire. There is a patch for a modified 3-Wire setup from one vendor that made my eyes bleed. So what you really want is having the kernel take control over HCI from the beginning. Otherwise this goes out of control and handling exceptions like hardware error event becomes impossible. > > In summary what we have to do these days is this: > > - Send Reset > - Send a few basic HCI commands > - Send baud rate change command > - Change actual baud rate on the TTY > - Download firmware > - Send Reset to boot the firmware > - Change actual baud rate back to default > - Send baud rate change command > - Change actual baud rate > - Send Reset > - Standard init sequence > > Now tell me how the line discipline framework helps us here? Well, 1. in hciattach I would have set the N_HCI line discipline immediately after opening the uart device. 2. in the N_HCI line discipline, I would have implemented write() so userspace command write()s would still write through to the uart device. 3. either, a. I would have added a new line discipline method for pre-termios changes, or b. I would have caught set termios ioctls in the N_HCI line discipline ioctl. and handled sending target line speed change commands there. Userspace would simply change the line speed. Userspace firmware loads are straightforward. However, it seems that the new intel approach (tied in with the protocol) is trickier to accommodate, but I haven't spent a lot of time trying to follow that setup. I'm not sure I understand why the firmware load is tied to the protocol; can the intel part load a different firmware that implements a different protocol? > Keep in mind you have to tell the controller via HCI commands over the old baud rate to change its rate. And then change it on the TTY to match what the controller does on its side. I'm conscious of the limitations of using tty/serial in the current manner. A fun project for one of these vendors would be to split the serial core into a separate tty driver and an abstraction layer that would allow other kernel subsystems to enslave the port. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
