[Gta04-owner] [Letux-kernel] w2sg004 woes

[H. Nikolaus Schaller]

Hi,

> Am 20.02.2017 um 20:12 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> Hi,
> 
>> Am 15.02.2017 um 15:11 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 
>> Hi,
>> 
>>> Am 12.02.2017 um 21:18 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>> 
>>> 
>>>> Am 12.02.2017 um 20:19 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>>> 
>>>> Hi,
>>>> 
>>>> On Sun, 12 Feb 2017 10:11:38 +0100
>>>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>>> Am 12.02.2017 um 09:43 schrieb Andreas Kemnade
>>>>>> <andreas at kemnade.info>:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I just noticed this waring occuring when the gps module is loaded
>>>>>> with a recent kernel.
>>>>>> Maybe someone knows about what is wring.
>>>>> 
>>>>> Yes. It comes from the tty/uart layer and our uart-slave patches. It
>>>>> seems that uart_change_pm is not allowed during driver probing. Or
>>>>> some pm isn't initialized at this point. Or something else :)
>>>>> 
>>>>> Since this warning does not harm (except for a 200ms boot delay), I
>>>>> did not invest any time to fix it.
>>>>> 
>>>>> Anyways, we have to rework the w2sg driver completely to get it
>>>>> upstream by using the new serdev interface. This means that this call
>>>>> sequence will go away completely and we will remove our own fix in
>>>>> the end...
>>>>> 
>>>>> There is already a w2sg driver skeleton based on serdev in branch
>>>>> work/hns/misc/w2sg-serdev.
>>>>> 
>>>> Does that mean... there is support for advanced serial stuff accepted by
>>>> mainline
>>> 
>>> yes, it is basically accepted. Especially by the Bluetooth/N900/TiWi
>>> driver people. They seem to have been waiting for long time for such
>>> a feature as well and our solution didn't make them happy.
>>> 
>>> Something has arrived in linux-next:
>>> 
>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=refs%2Ftags%2Fnext-20170210&qt=grep&q=serdev
>>> 
>>>> so that we simply can build our serial pm stuff upon it
>>> 
>>> yes. I think it should work as I have described. The only thing I don't
>>> exactly know is how to correctly handle buffers and block sizes. Serdev
>>> seems to present all bytes it has received while a read() from user space
>>> might not expect that much.
>>> 
>>>> so that we can finally upstream these things after long years?
>>> 
>>> Well, this will still lead to debates why we need to create a driver
>>> for this at all since it is a plain serial device. Why it opens another
>>> /dev/tty. Why it needs so complex buffer management etc. Then we must
>>> explain the man-in-the-middle role of the driver for proper power-management.
>> 
>> I spent some hours with this 12 years old document and now I think I understand
>> how it should work, especially for sending data from the driver to user-space:
>> 
>> 	https://static.lwn.net/images/pdf/LDD3/ch18.pdf
>> 
>> Well, modern API has partially been turned upside down and introduced many
>> more levels of struct indirection but I could use drivers/usb/class/cdc-acm.c
>> and drivers/net/usb/hso.c as examples where I know what the driver should
>> be doing...
>> 
>> Here is a first result which compiles:
>> 
>> 	http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/letux-4.10-rc8%2Bserial-bus%2Bw2sg-serdev-w2sg-tty-slave2
>> 	http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-serdev
>> 
>> It also starts (but sometimes enters the probe function twice).
>> It creates a fresh /dev/ttyGPS0 (should renamed ttyO* later).
>> 
>> But opening the /dev/ttyGPS0 makes the kernel segfault in tty_port_open().
>> So some initialization must still be missing for the /dev/tty end.
>> 
>> If someone wants to help, please take a look into the code. So that we can switch
>> to this solution asap (we can only have either driver in the kernel and not both
>> in parallel).
> 
> Did anyone find a little time to check this?

Looks as if I have made it working:

	http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/misc/w2sg-serdev

Needs some code cleanup and testing if it works as we want to have it in all situation we
can imagine.

Please note that this driver exposes a /dev/ttyGPS0 to access the GPS chip.

And as a bug/side-effect of including immature upstream code, it disables HCI access for bluetooth.

BR,
Nikolaus