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

H. Nikolaus Schaller hns at goldelico.com
Mon Feb 20 20:12:06 CET 2017


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?

BR,
Nikolaus



More information about the Gta04-owner mailing list