Re: lanana: Add major/minor entries for PPC QE UART devices

quoted

quoted

          46 = /dev/ttyCPM0        PPC CPM (SCC or SMC) - port 0
             ...
-         47 = /dev/ttyCPM5        PPC CPM (SCC or SMC) - port 5
+         49 = /dev/ttyCPM5        PPC CPM (SCC or SMC) - port 5

If CPM0 is 46, then CPM5 is not 47, but not 49 either.
Unless it's not CPM5 but CPM3?

Honestly, I don't know.  I was just correcting the obvious typo (47 
instead of 49).

It's obvious it shouldn't be 47, but it's not obvious it
should be 49 instead.

I'll try to get an answer from someone, but I'm no CPM expert.

Adding linuxppc-embedded to the CC:, someone there surely knows.


Segher

On Feb 28, 2007, at 9:54 AM, Segher Boessenkool wrote:

quoted

quoted

quoted

          46 = /dev/ttyCPM0        PPC CPM (SCC or SMC) - port 0
             ...
-         47 = /dev/ttyCPM5        PPC CPM (SCC or SMC) - port 5
+         49 = /dev/ttyCPM5        PPC CPM (SCC or SMC) - port 5

If CPM0 is 46, then CPM5 is not 47, but not 49 either.
Unless it's not CPM5 but CPM3?

Honestly, I don't know.  I was just correcting the obvious typo (47
instead of 49).

It's obvious it shouldn't be 47, but it's not obvious it
should be 49 instead.

I don't know the origin of this thread, but none of
that looks correct.  Today, there can be up to 8
CPM UART devices, 6 on CPM/CPM2 and 8
on the QE.  If ttyCPM0 starts at minor 46, they
should be at least monotonically incrementing
up to ttyCPM7 with minor 53.


Thanks.

	-- Dan

Dan Malek wrote:

I don't know the origin of this thread, but none of
that looks correct.  Today, there can be up to 8
CPM UART devices, 6 on CPM/CPM2 and 8
on the QE.  If ttyCPM0 starts at minor 46, they
should be at least monotonically incrementing
up to ttyCPM7 with minor 53.

Minor nit: On the QE, they'll be called ttyQE0 through ttyQE7.

I agree that the CPM and the QE should share the same starting minor number, so that 
ttyCPM0 has the same major/minor number as ttyQE0, since it's not possible to have a CPM 
and a QE on the same device.  However, ttyCPM0 is currently assigned to 46, and device 50 
is an Altix serial card.  The only way to give the CPM 6 or 8 slots without moving it is 
to overlap the Altix card.

Now I don't know anything about the Altix card, so I don't know if it's possible to use 
that card on a system with a CPM or a QE.  If it isn't, then I don't know if overlapping 
minor numbers is still a problem.

(Note that the Altix card has a range of 50-81, which is pretty big.)

If we move CPM/QE to 192, then I can change the CPM device driver to reflect that, but I 
don't know what that means for older kernels.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

On Feb 28, 2007, at 12:04 PM, Timur Tabi wrote:

...  However, ttyCPM0 is currently assigned to 46, and device 50 is  
an Altix serial card.  The only way to give the CPM 6 or 8 slots  
without moving it is to overlap the Altix card.

Then, this is currently broken in all cases
and needs to be fixed since the CPM/CPM2
could have up to six UART ports.

Now I don't know anything about the Altix card, so I don't know if  
it's possible to use that card on a system with a CPM or a QE.  If  
it isn't, then I don't know if overlapping minor numbers is still a  
problem.

I don't think that would be a problem, and I'd like the
CPM/QE to share devices because it makes the
software distributions common to all Freescale
embedded processors.

If we move CPM/QE to 192, then I can change the CPM device driver  
to reflect that, but I don't know what that means for older kernels.

That would be bad.  It has nothing to do with the
kernel, but we have finally survived the distribution
updates to ttyCPM, and I don't want to go through
that again just because of QE.

Thanks.

	-- Dan

Dan Malek wrote:

I don't think that would be a problem, and I'd like the
CPM/QE to share devices because it makes the
software distributions common to all Freescale
embedded processors.

I'm willing to use whatever minor number and range the community agrees upon.

An alternative idea, which one person already shot down, was to allow only 4 devices 
normally, but allow more devices if you use udev, since udev doesn't care about minor 
number assignments.  This eliminates the overlap and encourages people to use udev.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

On Feb 28, 2007, at 12:35 PM, Timur Tabi wrote:

An alternative idea, which one person already shot down, was to  
allow only 4 devices normally, but allow more devices if you use  
udev, since udev doesn't care about minor number assignments.  This  
eliminates the overlap and encourages people to use udev.

I'd shoot that down, too.  Using udev in an
embedded, reliable environment is very
troublesome.  Although, products I've
developed using more than 4 UARTs had
some custom /dev work done to it just
to get everything mapped.  My only
concern is we don't add a new range for
QE UARTs, that we use the same minors
for both CPM and QE.

Thanks.

	-- Dan

Dan Malek wrote:

I'd shoot that down, too.  Using udev in an
embedded, reliable environment is very
troublesome.  Although, products I've
developed using more than 4 UARTs had
some custom /dev work done to it just
to get everything mapped.  My only
concern is we don't add a new range for
QE UARTs, that we use the same minors
for both CPM and QE.

Then it appears that the only possible solution is to assign numbers 46 - 53 to the CPM/QE 
and accept that it overlaps with the Altix.  Is everyone okay with that?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

Timur Tabi wrote:

Dan Malek wrote:

quoted

I'd shoot that down, too.  Using udev in an
embedded, reliable environment is very
troublesome.  Although, products I've
developed using more than 4 UARTs had
some custom /dev work done to it just
to get everything mapped.  My only
concern is we don't add a new range for
QE UARTs, that we use the same minors
for both CPM and QE.

Then it appears that the only possible solution is to assign numbers 46 
- 53 to the CPM/QE and accept that it overlaps with the Altix.  Is 
everyone okay with that?

I would much rather see these devices moved to a different minor range.

	-hpa

On Feb 28, 2007, at 1:00 PM, H. Peter Anvin wrote:

I would much rather see these devices moved to a different minor  
range.

No.  We just did that all too recently, and
i don't know why the minors didn't get
allocated properly.  I don't want to have to
update all of our embedded software distributions
just because someone doesn't like minor
numbers that aren't causing trouble.
If we allocate unique spaces for all of the
possible UART variations, there isn't going
to be enough space.

Just allocate the four slots and we'll deal with
anything above this in custom products.  Using
more than four of these processor resources
as UARTs isn't likely to happen because there
won't be anything left for the interesting
communication ports.

Thanks.

	-- Dan

On Feb 28, 2007, at 12:20 PM, Dan Malek wrote:

On Feb 28, 2007, at 1:00 PM, H. Peter Anvin wrote:

quoted

I would much rather see these devices moved to a different minor
range.

No.  We just did that all too recently, and
i don't know why the minors didn't get
allocated properly.  I don't want to have to
update all of our embedded software distributions
just because someone doesn't like minor
numbers that aren't causing trouble.
If we allocate unique spaces for all of the
possible UART variations, there isn't going
to be enough space.

Just allocate the four slots and we'll deal with
anything above this in custom products.  Using
more than four of these processor resources
as UARTs isn't likely to happen because there
won't be anything left for the interesting
communication ports.

Why don't we allocate the 2nd group of four as well, just at a new  
location.  They'll be discontinuous, but at least we'll have support  
for all 8.

- k 

Kumar Gala wrote:

Why don't we allocate the 2nd group of four as well, just at a new 
location.  They'll be discontinuous, but at least we'll have support for 
all 8.

Right, it means two tty driver structures, but that's not a problem.

	-hpa

H. Peter Anvin wrote:

Kumar Gala wrote:

quoted

Why don't we allocate the 2nd group of four as well, just at a new 
location.  They'll be discontinuous, but at least we'll have support 
for all 8.

Right, it means two tty driver structures, but that's not a problem.

Eh, I'm not crazy about that.  That means that I have to complicate my driver because 
someone else screwed up a long time ago.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

On Feb 28, 2007, at 1:30 PM, Timur Tabi wrote:

H. Peter Anvin wrote:

quoted

Kumar Gala wrote:

quoted

Why don't we allocate the 2nd group of four as well, just at a  
new location.  They'll be discontinuous, but at least we'll have  
support for all 8.

Right, it means two tty driver structures, but that's not a problem.

Eh, I'm not crazy about that.  That means that I have to complicate  
my driver because someone else screwed up a long time ago.

If not you someone else.  The cost in the driver is small compared to  
fixing up all the distro's and such.  If you don't provide this  
change someone else will.

- k

Kumar Gala wrote:

quoted

Eh, I'm not crazy about that.  That means that I have to complicate my 
driver because someone else screwed up a long time ago.

If not you someone else.  The cost in the driver is small compared to 
fixing up all the distro's and such.  If you don't provide this change 
someone else will.

*sigh*

What about major number 205?  It also has the screwed-up /dev/ttyCPM entries, but it has 
more room, and the CPM driver doesn't actually use it.  At least, I can't see where it 
uses it.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

On Feb 28, 2007, at 2:43 PM, Timur Tabi wrote:

What about major number 205?  It also has the screwed-up /dev/ 
ttyCPM entries, but it has more room, and the CPM driver doesn't  
actually use it.  At least, I can't see where it uses it.

Please, let's just leave the four we have and let
the driver just allocate increasing minor numbers.
If anyone has a product with more than 4 UARTs,
they will have to figure out what to do with the
additional minors.

We are making a very complicated problem
out of nothing.  This hasn't caused any problems
in the past, and changing the existing names and
minors will cause problems for everyone today.

Just leave it alone, fix up the documentation,
and have the driver print some warning if it
allocates more than 4 UARTs.

Thanks.

	-- Dan

Please, let's just leave the four we have

No one is suggesting otherwise.

and let
the driver just allocate increasing minor numbers.
If anyone has a product with more than 4 UARTs,
they will have to figure out what to do with the
additional minors.

Since you say no one has ever used more than 4 UARTs,
there are two options:

- Cap the driver at 4 UARTs;
- Assign an extra range of minors for more ports.

Just randomly using some extra minors that aren't
assigned to you isn't such a great idea.


Segher

On Feb 28, 2007, at 5:08 PM, Segher Boessenkool wrote:

Since you say no one has ever used more than 4 UARTs,
there are two options:

People have used more than 4, but we just
allocated the additional /dev entries to cover
them.  I know of only one time this has happened.
It's such a custom case that the other device
names didn't matter.

- Cap the driver at 4 UARTs;

Let's do this, but design the code to
allow more by just changing a #define.

Just randomly using some extra minors that aren't
assigned to you isn't such a great idea.

Maybe for a desktop or generic server where
you don't know what's going to be configured,
but it's not unusual to do so with custom
embedded systems.  The small experimental
or user allocations often don't cover what
is needed, so we just grab some allocation
from a device that isn't ever going to be
used on the system.


Thanks.

	-- Dan

Dan Malek wrote:

People have used more than 4, but we just
allocated the additional /dev entries to cover
them.  I know of only one time this has happened.
It's such a custom case that the other device
names didn't matter.

Ok guys, I need a consensus here.  Are we going to allocate a second block of 4 minor 
numbers for the QE/CPM UART or not?

My driver already has a macro that limits the number of UARTS to 4, and it just uses minor 
numbers 47 through (47 + UCC_MAX_UART - 1).  So my driver can easily be modified to spill 
into the Altic's range if some custom board needs it.

I'll add a second TTY struct to handle the 2nd set of minor numbers if and only if 
devices-2.6+.txt is updated with that information.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

Since I'm probably the only one that
really uses the driver for custom
uses and cares......

On Mar 1, 2007, at 10:55 AM, Timur Tabi wrote:

Ok guys, I need a consensus here.  Are we going to allocate a  
second block of 4 minor numbers for the QE/CPM UART or not?

not.

My driver already has a macro that limits the number of UARTS to 4,

perfect.

I'll add a second TTY struct...

Don't worry about it for now.  We'll just keep this in
mind when we make a major change someday in
the future.  We may have a better solution then.

Thanks.

	-- Dan

Dan Malek wrote:

Don't worry about it for now.  We'll just keep this in
mind when we make a major change someday in
the future.  We may have a better solution then.

Ok, what about udev?  If a user is running udev, which supposedly doesn't care about minor 
numbers, won't the user still be limited to 4 UARTS?  If so, is there a way for the driver 
to detect udev and allow 8 UARTS?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

quoted

- Cap the driver at 4 UARTs;

Let's do this, but design the code to
allow more by just changing a #define.

quoted

Just randomly using some extra minors that aren't
assigned to you isn't such a great idea.

Maybe for a desktop or generic server where
you don't know what's going to be configured,
but it's not unusual to do so with custom
embedded systems.

You can do whatever you want in your own stuff
but that's not how things work in the mainstream
Linux kernel.

The small experimental
or user allocations often don't cover what
is needed, so we just grab some allocation
from a device that isn't ever going to be
used on the system.

Sure I've done that myself a few times, but this
just doesn't fly for in-kernel drivers; those have
their own ranges defined in devices.txt and don't
use random other minors.


Segher

We are making a very complicated problem
out of nothing.  This hasn't caused any problems
in the past, and changing the existing names and
minors will cause problems for everyone today.
=20
Just leave it alone, fix up the documentation,
and have the driver print some warning if it
allocates more than 4 UARTs.
=20

Dan has a point here. Now I clearly can't comment on how bad 8 is
needed, but since this has been like this for a while, I'll have to
assume 4 is covering most cases.

Moving things to a different range _will_ be much worse for distro
maintainers than driver developers. And I bet the latter is going to be
minor work as things has been like this for a while.

But we can still allocate 4 more at a different minor that distro's can
_choose_ to use. Consider it an enhancement to the 4 we have had in the
past.

Torben

Dan Malek wrote:

Just allocate the four slots and we'll deal with
anything above this in custom products. 

Assuming that this is the agreed-upon standard, should I arbitrarily restrict my driver to 
4 ports, or allow all 8?

I assume that if a driver already claims a particular major/minor combo, then when the 2nd 
driver calls uart_add_one_port(), that call will fail?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

Just allocate the four slots and we'll deal with
anything above this in custom products.

Another option is to use 46..49 for UARTs #0..3,
and 192..195 for UARTs #4..7.

Or, perhaps better, use 46..49 for #0..3, and
192..199 for #0..7, handling the duplication in
the driver; and deprecate the old range.


Segher

Segher Boessenkool wrote:

quoted

Just allocate the four slots and we'll deal with
anything above this in custom products.

Another option is to use 46..49 for UARTs #0..3,
and 192..195 for UARTs #4..7.

Or, perhaps better, use 46..49 for #0..3, and
192..199 for #0..7, handling the duplication in
the driver; and deprecate the old range.

That sounds like more hassle than it's worth.  The discontinuous range 
may be annoying, but it isn't really a huge amount of code.

	-hpa

quoted

Another option is to use 46..49 for UARTs #0..3,
and 192..195 for UARTs #4..7.
Or, perhaps better, use 46..49 for #0..3, and
192..199 for #0..7, handling the duplication in
the driver; and deprecate the old range.

That sounds like more hassle than it's worth.  The discontinuous range 
may be annoying, but it isn't really a huge amount of code.

Yeah.  My suggestion would allow to get rid of that
extra code some day, though (but sure, is that worth
it?)


Segher

On Feb 28 2007 20:25, Segher Boessenkool wrote:

quoted

Just allocate the four slots and we'll deal with
anything above this in custom products.

Another option is to use 46..49 for UARTs #0..3,
and 192..195 for UARTs #4..7.

Or, perhaps better, use 46..49 for #0..3, and
192..199 for #0..7, handling the duplication in
the driver; and deprecate the old range.

I'd "vote" for the 2nd. 


Jan
--