MacSerial and Serial driver cohabitation

MacSerial and Serial driver cohabitation

[Alain RICHARD]

>  >On my Rev. D iMac, disabling CONFIG_SERIAL means I am unable to use my
>>internal modem.  I expect it would be the same story on an iMac DV.  So it
>>turns out serial support is important for something on an iMac.  :)
>
>I think your a mixing legacy serial support that must _not_ be enabled on
>PowerMacs (CONFIG_SERIAL) and the Macintosh serial support (I don't have
>the config option name with me now). Only the latest is needed for your iMac.
>
>Ben.
>
>

There is a long waiting problem in making the two serial drivers
(legacy serial driver named serial.o and macintosh serial driver
named macserial.o). The problem is that the two drivers thinks there
are the legacy one and numbers each serial port found from ttyS0 to
ttySn. So if you try to load them simultaneously, you'll get a kernel
fault.

There are several workarounds, either :

- compiles only macserial and disable legacy serial.
- compiles the two drivers as modules and load only one (by adding
"alias char-major-4 macserial" and "alias char-major-5 macserial" in
your /etc/conf.modules file).

This is just a hack, but the problem is worst : macserial is a serial
driver for Z8530 chipsets and serial is a serial driver for 16x50
UARTs. There are several cases where you may need the two drivers :

a) in a powerbook when using a pcmcia modem : most, if not all, modem
cards are based on a 16x50 UART and do need the serial.o driver.
b) most PCI serial cards are using 16x50 UARTs

Powerbooks kernels compiled by Paul Mackerras have a quick fix in the
serial driver in order to make it skip the first 2 ttyS entries when
compiled on PMAC architecture. This fix works but was never included
in the main kernel because it is just a simple hack.

Looking at the current kernel code, I have found that there is now a
new serial driver called serial167.c (for another serial chipset)
that is avoiding the problem by allocating its ttySn after all
curently allocated ttySn and not starting from ttyS0).

So I think a very simple fix would be to add a similar patch to
macserial AND serial so that all serial drivers may be loaded at the
same time without problem . This fix may have to be also added to all
the other serial devices in the various Linux ports (mac_SCC for
Linux 68k, sunserial for Linux Sparc for example).

I have seen a lot of complain about that simple silly problem, and I
think this will be a good thing to fix. What do you think about it ?
Is there anybody working on this stuff (macserial and sunserial is
maintained by paulus) or should i submit separate patch to linus and
the various maintainers ?

Regards,




--
-------------------------------------------------------
Alain RICHARD <mailto:alain.richard@equation.fr>
EQUATION SA <http://www.equation.fr/>
Tel : +33 477 79 48 00	 Fax : +33 477 79 48 01
Applications client/serveur, ingénierie réseau et Linux

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MacSerial and Serial driver cohabitation

[Andreas Tobler]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

Alain RICHARD wrote:
> There is a long waiting problem in making the two serial drivers
> (legacy serial driver named serial.o and macintosh serial driver
> named macserial.o). The problem is that the two drivers thinks there
> are the legacy one and numbers each serial port found from ttyS0 to
> ttySn. So if you try to load them simultaneously, you'll get a kernel
> fault.
>
> There are several workarounds, either :
>
> - compiles only macserial and disable legacy serial.
> - compiles the two drivers as modules and load only one (by adding
> "alias char-major-4 macserial" and "alias char-major-5 macserial" in
> your /etc/conf.modules file).

I do it this way, the macserial is built in, the serial as a module.
When you do build the serial into the kernel you get a build error:

multiple definition of `serial_console_init'


>
> This is just a hack, but the problem is worst : macserial is a serial
> driver for Z8530 chipsets and serial is a serial driver for 16x50
> UARTs. There are several cases where you may need the two drivers :
>
> a) in a powerbook when using a pcmcia modem : most, if not all, modem
> cards are based on a 16x50 UART and do need the serial.o driver.
> b) most PCI serial cards are using 16x50 UARTs
>
> Powerbooks kernels compiled by Paul Mackerras have a quick fix in the
> serial driver in order to make it skip the first 2 ttyS entries when
> compiled on PMAC architecture. This fix works but was never included
> in the main kernel because it is just a simple hack.

It's not only the skipping, there is some more needed. When you build the serial
and start the kernel then it panics since the autoconfig in serial.c is not
working on PPC.

Attached my suggestion. Here it works on a wallstreet I, which has 2 heathrow's,
that's why the offset is 4 and not 2 as mentioned above.

Andreas

[-- Attachment #2: cb-serial2217.patch.gz --]
[-- Type: application/x-gzip, Size: 950 bytes --]

Re: MacSerial and Serial driver cohabitation

[Benjamin Herrenschmidt]

>
>Powerbooks kernels compiled by Paul Mackerras have a quick fix in the
>serial driver in order to make it skip the first 2 ttyS entries when
>compiled on PMAC architecture. This fix works but was never included
>in the main kernel because it is just a simple hack.

AFAIK, Paul and the serial driver maintainer agreed on a new mecanism for
fixing that problem once for all. I didn't check but I beleive it should
be in 2.4 and could probably be backported if really necessary.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MacSerial and Serial driver cohabitation

[Geert Uytterhoeven]

On Mon, 17 Jul 2000, Alain RICHARD wrote:
> This is just a hack, but the problem is worst : macserial is a serial
> driver for Z8530 chipsets and serial is a serial driver for 16x50

One more reason to rename serial.c to ser16550.c and merge all Z8530 drivers
into one ser8530.c (BTW, it's left as an exercise for the reader to find
someone with enough fingers to count all AMD LANCE drivers and merge them into
one driver afterwards :-)

> UARTs. There are several cases where you may need the two drivers :
>
> a) in a powerbook when using a pcmcia modem : most, if not all, modem
> cards are based on a 16x50 UART and do need the serial.o driver.
> b) most PCI serial cards are using 16x50 UARTs

And CHRP boxes, which may have both 16550 and 8530 serial ports on the
motherboard. Never tried my 8530 ports, though.

To me it would sound logical to start counting serial ports from ttyS0 in one
driver, and continue counting in a second driver, and so on. We had that on
m68k, but the PC guys didn't like it and want to keep the current scheme (one
major device for 16550 serial, and one for each type of multiserial board on
the market).

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MacSerial and Serial driver cohabitation

[Michael Schmitz]

Geert Uytterhoeven wrote:
> And CHRP boxes, which may have both 16550 and 8530 serial ports on the
> motherboard. Never tried my 8530 ports, though.
>
> To me it would sound logical to start counting serial ports from ttyS0 in one
> driver, and continue counting in a second driver, and so on. We had that on
> m68k, but the PC guys didn't like it and want to keep the current scheme (one
> major device for 16550 serial, and one for each type of multiserial board on
> the market).

I think the fight was rather about other design decisions in the m68k
driver, not as much about the device numbering. As far as I recall, the
proposed solution was to have the 'builtin' serials at least on m68k use
the default (16550) major but cut out the midlevel abstraction. I never
understood what was supposed to perform hardware abstraction though.

I'd say agree on a fixed order of probing, allocate minors in that order
(with the possible exception of allowing a driver to allocate specific
minors out of order if someone wants to make sure their driver always
gets the same minors).

	Michael

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MacSerial and Serial driver cohabitation

[Michel Lanners]

Hi all,

On  17 Jul, this message from Michael Schmitz echoed through cyberspace:
> I'd say agree on a fixed order of probing, allocate minors in that order
> (with the possible exception of allowing a driver to allocate specific
> minors out of order if someone wants to make sure their driver always
> gets the same minors).

Whoever fixes this problem should be decorated, and a statue put up in
his memory. ;-)

But if anyone is brave enough to attempt it, don't forget that there are
_two_ places where serial ports are probed for: serial console init very
early in the booting, and driver init much later in the boot process.
Those two should be guaranteed to be in sync re minor assignment/device
naming. Right now, that's not the case.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MacSerial and Serial driver cohabitation

[Benjamin Herrenschmidt]

>Hi all,
>
>On  17 Jul, this message from Michael Schmitz echoed through cyberspace:
>> I'd say agree on a fixed order of probing, allocate minors in that order
>> (with the possible exception of allowing a driver to allocate specific
>> minors out of order if someone wants to make sure their driver always
>> gets the same minors).
>
>Whoever fixes this problem should be decorated, and a statue put up in
>his memory. ;-)
>
>But if anyone is brave enough to attempt it, don't forget that there are
>_two_ places where serial ports are probed for: serial console init very
>early in the booting, and driver init much later in the boot process.
>Those two should be guaranteed to be in sync re minor assignment/device
>naming. Right now, that's not the case.

My current rsync tree contains a fix done by Andreas Tobler that helps
cohabitation of macserial and legacy serial. I know Paul and Theodore
have been working on a more definitive fix, I don't know it's status however,

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: MacSerial and Serial driver cohabitation

[Michael Schmitz]

> >Whoever fixes this problem should be decorated, and a statue put up in
> >his memory. ;-)
> >
> >But if anyone is brave enough to attempt it, don't forget that there are
> >_two_ places where serial ports are probed for: serial console init very
> >early in the booting, and driver init much later in the boot process.
> >Those two should be guaranteed to be in sync re minor assignment/device
> >naming. Right now, that's not the case.
>
> My current rsync tree contains a fix done by Andreas Tobler that helps
> cohabitation of macserial and legacy serial. I know Paul and Theodore
> have been working on a more definitive fix, I don't know it's status however,

We will have to find a way to adopt the more definitive fix for m68k
anyway, that's something constantly slipping down on my todo list but it's
been on there for over a year now. I'll ask Paul and Ted about details.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/