From: Stefan Althoefer <as@janz.de>
To: linux-serial@vger.kernel.org
Subject: ioctl(tiocsserial) for devices which need ioremapping
Date: Tue, 23 Jan 2007 08:26:35 +0100 [thread overview]
Message-ID: <45B5B8AB.9020200@janz.de> (raw)
hi,
I'm using the linux serial 8250 driver for an IXP425 based ARM
device. The two on-chip serial ports work with no problem.
However, depending on the configuration of my system I have
some more 8250 based serial ports, which I want to register to
the driver after the system has booted (after I have detected
how many ports are available).
For this I have written a tool to configure the serial port base
address and interrupt with the TIOCSSERIAL ioctl.
Unfortunately, there is a problem with this: The new serial ports
require that the memory mapped address must be remapped. Although
there is a member in the serial_struct to specify this, the driver
does not pay attention to the UPF_IOREMAP bit in serial_struct.flags.
The same appears to the UPF_SHARE_IRQ flag.
Is there any way to handle this (to attach my serial port and have
the address relocation take place)?
To solve this problem, I have created the following patch. It checks
for the UPF_IOREMAP and UPF_SHARE_IRQ flags when it detects that
either port or interrupt are changed. Is it possible to integrate
this into the kernel?
-----%<------------
diff -r -N -u linux-2.6.18.1/drivers/serial/serial_core.c
linux-2.6.18.1-xscale-fordiff/drivers/serial/serial_core.c
--- linux-2.6.18.1/drivers/serial/serial_core.c 2006-10-14 05:34:03.000000000 +0200
+++ linux-2.6.18.1-xscale-fordiff/drivers/serial/serial_core.c 2006-11-02 11:52:46.000000000 +0100
@@ -706,6 +706,22 @@
goto check_and_exit;
}
+ /* FIXME: as@janz.de
+ *
+ * If we change port and IOREMAP is requested, then we push it in.
+ * If we change irq and SHARE_IRQ is requested, then we push it in.
+ */
+ if( change_port ){
+ if( (new_serial.flags & UPF_IOREMAP) && !(port->flags & UPF_IOREMAP) ){
+ port->flags |= UPF_IOREMAP;
+ }
+ }
+ if( change_irq ){
+ if( (new_serial.flags & UPF_SHARE_IRQ) && !(port->flags & UPF_SHARE_IRQ) ){
+ port->flags |= UPF_SHARE_IRQ;
+ }
+ }
+
/*
* Ask the low level driver to verify the settings.
*/
---------------------
--
----------------------
Stefan Althöfer (stefan.althoefer@janz.de)
Janz Automationssysteme AG
- Automation Intelligence -
Member of the Janz company group
Im Doerener Feld 8
33100 Paderborn - Germany
-
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
reply other threads:[~2007-01-23 7:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45B5B8AB.9020200@janz.de \
--to=as@janz.de \
--cc=linux-serial@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.