On Sun, May 21, 2017 at 5:44 AM, H. Nikolaus Schaller <h...@goldelico.com> wrote: > Since our proposed API was not acceptable and the new serdev API has arrived > in 4.11 kernels, > we finally took the challenge to update the w2sg and w2cbw drivers to use the > serdev API. > > The approach is to write a "man in the middle" driver which is on one side a > serdev client > which directly controls the UART where the device is connected to and on the > other side > presents a new tty port so that user-space software can talk to the chips as > if they would > directly talk to the UART of the SoC (e.g. ttyO1). This is similar to > connecting to a remote > serial device e.g. through USB (ttyACM) or Bluetooth UART profiles. > > For example gpsd or hciattach expect a /dev/tty they can control (flow > control, baud rate > etc.).
I understand from the prior discussion why you want to pass the data thru for gps, but why do you need to do that for BT? > Here is the result of our first hack which is working as a demo on GTA04 > devices (and the > w2cbw driver can also be used to control a GTA04 variant with WL1837). > > Since it is just a demo hack, the code is not yet cleaned up, nor does it > completely pass > check-patch, nor follows 100% the coding styles. And certainly has some bugs. > > The most significant issue is that calling tty_port_register_device() inside > of the > serdev probe() function makes the serdev probe() function to be entered a > second > time. This does not lead to big problems since we currently have minor = 0 > and this makes the second call assume the device is not available. > > But we have no idea why this happens and how it can be prevented. Johan's fixes may help there, but it is intended to be temporary to have a separate API for registering tty ports with or without serdev. Rob
