[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>:
>> 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:


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:


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
in parallel).


More information about the Letux-kernel mailing list