* [PATCH 0/2]: Allow 8250 to work on sparc.
@ 2008-09-13 4:18 David Miller
2008-09-15 14:26 ` Mark Fortescue
0 siblings, 1 reply; 7+ messages in thread
From: David Miller @ 2008-09-13 4:18 UTC (permalink / raw
To: linux-serial; +Cc: linux-kernel, sparclinux, joy
Currently there is a "BROKEN || SPARC" dependency for CONFIG_SERIAL_8250
in drivers/serial/Kconfig. These changes try to eliminate that restriction
so that Sparc users can use add-on PCI cards with 8250 serial controllers.
The core issue that prevents this from working is that all of the onboard
Sun specific serial drivers use the major=TTY_MAJOR, minor=64,65,66,...
driver major/minor namespace, just like 8250.
They coordinate amongst themselves using an internal allocator for the
minor number space. This is contained in drivers/serial/suncore.c
This presents two problems:
1) We have to make sure the Sun drivers register first, so that their
device indexes don't change and thus people get broken serial consoles
and stuff like that.
2) Also, it is necessary for 8250 to partake in this minor number
allocation scheme, otherwise it cannot register because it'll try
to use '64' as it's base minor number and one of the Sun serial drivers
will have taken over that minor already.
Working on this and testing it also uncovered another portability bug.
The uart_port structure uses an "unsigned int" for the "ioport" member,
but even I/O ports in PCI devices are 64-bit on sparc64, so the high
bits were being chopped off when 8250 PCI cards were tested. The fix
is to use "unsigned long" for this type and that's what the first patch
does.
The second patch removes the !SPARC dependency for 8250 and adds the hooks
to use the Sun serial minor number allocator when registering serial8250_reg
with the UART layer.
Yes, I know, this part is a bit ugly but I can't think of any workable
alternative. I could change all the major/minor numbers all the Sun
serial drivers use, to get out of the way of 8250's space. But that
will break every single Sparc system out there, all the serial device
names will change as will the serial console device. I did write a patch
which does such a set of changes, but I can't see any way in which we can
consider it seriously.
If there are no objections I'd like to toss this into my sparc-next-2.6
tree for 2.6.28 inclusion. Is that OK with everyone?
I'd like to thank Josip Rodin for bringing this to my attention, and
testing various revisions of these patches.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Allow 8250 to work on sparc.
2008-09-13 4:18 [PATCH 0/2]: Allow 8250 to work on sparc David Miller
@ 2008-09-15 14:26 ` Mark Fortescue
2008-09-15 16:22 ` Alan Cox
0 siblings, 1 reply; 7+ messages in thread
From: Mark Fortescue @ 2008-09-15 14:26 UTC (permalink / raw
To: David Miller; +Cc: linux-serial, linux-kernel, sparclinux, joy
On Fri, 12 Sep 2008, David Miller wrote:
> Working on this and testing it also uncovered another portability bug.
> The uart_port structure uses an "unsigned int" for the "ioport" member,
> but even I/O ports in PCI devices are 64-bit on sparc64, so the high
> bits were being chopped off when 8250 PCI cards were tested. The fix
> is to use "unsigned long" for this type and that's what the first patch
> does.
>
In the long term, should a generic serial port minor number allocater be
used by all serial ports?
At the user level, there is no difference between a sun zilog serial port,
an 8250 serial port or a USB serial port so these should be allocated
using the same allocation system.
Would this not remove many of the issues of portability that the current
structure apears to have built into it?
For me, it would also simplify the issue of trying to work what devive to
look for when I plug in a new USB serial port device. It would be the new
/dev/ttyS<x> to appear in /dev.
For serial ports with additional functionality (SDLC, HDLC etc.) a
seperate IOCTL could be provided to indicate the presense of this
extra functionality to programs that require it or a separate device
major/minor could be allocated for this extra functionality (this may
have some comatibility/maintanence benifits over an IOCTL).
Regards
Mark Fortescue.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Allow 8250 to work on sparc.
2008-09-15 14:26 ` Mark Fortescue
@ 2008-09-15 16:22 ` Alan Cox
2008-09-15 18:51 ` Mark Fortescue
2008-09-15 18:51 ` David Miller
0 siblings, 2 replies; 7+ messages in thread
From: Alan Cox @ 2008-09-15 16:22 UTC (permalink / raw
To: Mark Fortescue; +Cc: David Miller, linux-serial, linux-kernel, sparclinux, joy
> At the user level, there is no difference between a sun zilog serial port,
> an 8250 serial port or a USB serial port so these should be allocated
> using the same allocation system.
That isn't strictly true.
> For me, it would also simplify the issue of trying to work what devive to
> look for when I plug in a new USB serial port device. It would be the new
> /dev/ttyS<x> to appear in /dev.
Naming is a private matter for udev anyway, independant of numbering for
major/minor
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Allow 8250 to work on sparc.
2008-09-15 16:22 ` Alan Cox
@ 2008-09-15 18:51 ` Mark Fortescue
2008-09-16 10:54 ` Alan Cox
2008-09-15 18:51 ` David Miller
1 sibling, 1 reply; 7+ messages in thread
From: Mark Fortescue @ 2008-09-15 18:51 UTC (permalink / raw
To: Alan Cox; +Cc: David Miller, linux-serial, linux-kernel, sparclinux, joy
Hi Alan,
On Mon, 15 Sep 2008, Alan Cox wrote:
>> At the user level, there is no difference between a sun zilog serial port,
>> an 8250 serial port or a USB serial port so these should be allocated
>> using the same allocation system.
>
> That isn't strictly true.
I am intrigued. Other than the valid baud rates what differences are
visible at the user level?
>
>> For me, it would also simplify the issue of trying to work what devive to
>> look for when I plug in a new USB serial port device. It would be the new
>> /dev/ttyS<x> to appear in /dev.
>
> Naming is a private matter for udev anyway, independant of numbering for
> major/minor
>
Yes, but I have not found a simple way to configure it to add serial port
devices to the next available /dev/ttyS<xx>. If this was the default, it
would be much easier for me :). (I am assuming that all the different
serial port devices I use are transparent at the user level, hence my
question above.)
Regards
Mark.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Allow 8250 to work on sparc.
2008-09-15 18:51 ` Mark Fortescue
@ 2008-09-16 10:54 ` Alan Cox
2008-09-16 13:15 ` Mark Fortescue
0 siblings, 1 reply; 7+ messages in thread
From: Alan Cox @ 2008-09-16 10:54 UTC (permalink / raw
To: Mark Fortescue; +Cc: David Miller, linux-serial, linux-kernel, sparclinux, joy
> I am intrigued. Other than the valid baud rates what differences are
> visible at the user level?
There are lots of variations between hardware of all kinds but the big
one with USB devices is generally latency.
> Yes, but I have not found a simple way to configure it to add serial port
> devices to the next available /dev/ttyS<xx>. If this was the default, it
> would be much easier for me :). (I am assuming that all the different
That still isn't a kernel problem but a udev one and one for the udev
lists ?
Alan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Allow 8250 to work on sparc.
2008-09-16 10:54 ` Alan Cox
@ 2008-09-16 13:15 ` Mark Fortescue
0 siblings, 0 replies; 7+ messages in thread
From: Mark Fortescue @ 2008-09-16 13:15 UTC (permalink / raw
To: Alan Cox; +Cc: David Miller, linux-serial, linux-kernel, sparclinux, joy
Hi Alan,
On Tue, 16 Sep 2008, Alan Cox wrote:
>> I am intrigued. Other than the valid baud rates what differences are
>> visible at the user level?
>
> There are lots of variations between hardware of all kinds but the big
> one with USB devices is generally latency.
>
At the driver level there are lots of varients but I was under the
impression that at the user level, the interface is common for async
serial ports.
Latency can be an issue, but can it be read/changed via the user <->
kernel interface in a way that is not common to all async serial ports?
If not, it is transparent at the programming interface for user level code
so the USB serial ports are no different at this level to classic PC AT
serial ports and as such I see no reason why, in the long run, they should
not share minor number space.
Taking the argument to its logical conclusion, all devices that have a
common user <-> kernel interface should have device drivers that are
capable of sharing minor device number space.
I am sure this discusion will crop up again in the future :).
Regards
Mark.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Allow 8250 to work on sparc.
2008-09-15 16:22 ` Alan Cox
2008-09-15 18:51 ` Mark Fortescue
@ 2008-09-15 18:51 ` David Miller
1 sibling, 0 replies; 7+ messages in thread
From: David Miller @ 2008-09-15 18:51 UTC (permalink / raw
To: alan; +Cc: mark, linux-serial, linux-kernel, sparclinux, joy
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Mon, 15 Sep 2008 17:22:11 +0100
> > At the user level, there is no difference between a sun zilog serial port,
> > an 8250 serial port or a USB serial port so these should be allocated
> > using the same allocation system.
>
> That isn't strictly true.
>
> > For me, it would also simplify the issue of trying to work what devive to
> > look for when I plug in a new USB serial port device. It would be the new
> > /dev/ttyS<x> to appear in /dev.
>
> Naming is a private matter for udev anyway, independant of numbering for
> major/minor
True. But I think there is some merit in having such a generic
allocator for the current users of the ttySX minor space.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2008-09-16 13:16 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-09-13 4:18 [PATCH 0/2]: Allow 8250 to work on sparc David Miller
2008-09-15 14:26 ` Mark Fortescue
2008-09-15 16:22 ` Alan Cox
2008-09-15 18:51 ` Mark Fortescue
2008-09-16 10:54 ` Alan Cox
2008-09-16 13:15 ` Mark Fortescue
2008-09-15 18:51 ` David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).