[PATCH] Stop pmac_zilog from abusing 8250's device numbers.

[David Woodhouse]

On Wed, 2007-04-04 at 15:53 +1000, Paul Mackerras wrote:
> David Woodhouse writes:
> 
> > Why? What's so special about the name 'ttyS'?
> 
> It's the name that users of Linux expect built-in serial ports to have.

Not really. The norm under Linux is for non-8250 ports to use
properly-registered device numbers and names. There's not many which are
still broken in this respect -- it's basically pmac_zilog and some Sun
UARTs, isn't it?

And even if it _were_ true, it wouldn't be a particularly good reason
for changing the way we handle serial ports under Linux.

> > > The built-in ports can generally be enumerated early on boot in a
> > > stable order, and they should be assigned the low ttySn numbers,
> > > regardless of what chip is used to implement them. 
> > 
> > I don't see why that 'should' be the case. Certainly it _isn't_ the case
> > on most supported platforms -- we have separate device numbers, and
> > names, for most types of ports. There's only one or two drivers which
> > abuse ttySn for anything other than 8250 ports.
>
> It 'should' be the case because that is what is easiest for users and
> makes most sense from a user's point of view.

I really don't buy that argument. People cope perfectly well
with /dev/ttySA0 on StrongARM, with /dev/ttySC0 on SH, etc. If it isn't
an 8250, it doesn't usually get called ttyS0. There's certainly nothing
_easier_ about ttyS0. Unless it's really an effort to type that extra
character :)

> You still haven't given any reason why a user should have to know or
> care whether the built-in serial ports on his/her computer are
> implemented with a 16C550 chip or a Z85C30 chip or something else.

Because that's the way serial ports are named under Linux. If you want
to change that, then take it up with the serial maintainer -- but
pmac_zilog as it is upstream at the moment is just _broken_. The module
just doesn't load if you have 8250 built in or loaded. That's what you
get when you abuse device numbers belonging to another driver.

> In any case your patch is a user-visible incompatible API change and
> will break existing working setups, so it should only be put in after
> suitable warning has been given.  Maybe we need a module parameter to
> select between the old and new behaviour to ease the transition.

Perhaps that's true; I'd certainly never seen a working setup with
pmac_zilog, because I'd never actually seen the module load. It's always
failed for me, because I have 8250 support built in to my kernels.

-- 
dwmw2