linux-kernel - Re: How to access correctly serial port inside module?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4648E4A4.60309@imap.cc>
Date:	Tue, 15 May 2007 00:37:24 +0200
From:	Tilman Schmidt <tilman@...p.cc>
To:	"Lars K.W. Gohlke" <lkwg82@....de>
CC:	linux-kernel@...r.kernel.org
Subject: Re: How to access correctly serial port inside module?

Am 14.05.2007 15:00 schrieb Lars K.W. Gohlke:
> after searching the mailing list and searching the web, I still don't
> know how to access correctly the serial port (in user space known as
> /dev/ttyS01)

I can only tell you how I did it in the special case of the
ser_gigaset driver which drives an ISDN device attached to
a serial port: I implemented it as a line discipline which
is associated to the appropriate serial port by a userspace
daemon.

Reading material:

Documentation/tty.txt
	documentation on the line discipline interface
include/linux/tty.h
include/linux/tty_ldisc.h
	definitions for same
drivers/isdn/gigaset/ser-gigaset.c
	my code - a simple example of abusing the line
	discipline interface for your own ends :-)

> would somebody be so kind to give me an example:

I hope the following will help you some. If not, feel free to
ask again.

> with this behaviour:
> 
> 1. read from port

That's not how things work in the kernel. There is no system
call for reading some data that has arrived on that port or
blocking if there is none, like a userspace program would do.
Instead, when you register your line discipline you provide
a callback function (receive_buf) for the serial driver to
call when data has been received. That function can be called
at any time and has to deal with the data as it gets it.

> 2. output via printk()

You can of course put a printk() in your receive_buf function.
But ultimately you'll want to do more than that with the data,
I'm sure.

> 3. write to port

That's easy. :-) No, it isn't. The serial driver *does*
provide a function (aptly called "write") for sending data
to the serial port, but you can't just call it any time you
like. You have to synchronize with the driver by waiting for
it to call your "write_wakeup" callback before you can call
its write function again.

HTH
T.

-- 
Tilman Schmidt                          E-Mail: tilman@...p.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

Download attachment "signature.asc" of type "application/pgp-signature" (254 bytes)