[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