[Gta04-owner] [Letux-kernel] w2sg004 woes
H. Nikolaus Schaller
hns at goldelico.com
Wed Feb 15 15:11:55 CET 2017
> 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>:
>> On Sun, 12 Feb 2017 10:11:38 +0100
>> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>>> Am 12.02.2017 um 09:43 schrieb Andreas Kemnade
>>>> <andreas at kemnade.info>:
>>>> 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
>> Does that mean... there is support for advanced serial stuff accepted by
> 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:
>> 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:
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
Here is a first result which compiles:
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 bot
More information about the Gta04-owner