gmane.linux.serial

David Miller | 13 Sep 06:18

[PATCH 0/2]: Allow 8250 to work on sparc.


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.

(Continue reading)

headers

Mark Fortescue | 15 Sep 16:26

Re: Allow 8250 to work on sparc.

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

(Continue reading)

headers

Alan Cox | 15 Sep 18:22

Re: Allow 8250 to work on sparc.

> 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

headers

Mark Fortescue | 15 Sep 20:51

Re: Allow 8250 to work on sparc.

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.

(Continue reading)

headers

Alan Cox | 16 Sep 12:54

Re: Allow 8250 to work on sparc.

> 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
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Mark Fortescue | 16 Sep 15:15

Re: Allow 8250 to work on sparc.

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

(Continue reading)

headers

David Miller | 15 Sep 20:51

Re: Allow 8250 to work on sparc.

From: Alan Cox <alan <at> 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.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html