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

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

[Timur Tabi]

Hi,

(Email to device@lanana.org bounces, so I'm sending this to lkml instead.)

I'm working on a UART device driver for the Freescale PowerPC QUICCEngine, which
is a replacement for the CPM.  Since the QE is basically "CPM v3", and you can't
have a CPM and a QE on the same board, I figure that they can share the same
minor numbers.

I've attached a patch that adds these entries to major number 204.  Please not
that there's a small typo for /dev/ttyCPM5, and I've fixed that in the patch as
well.

Please let me know if my proposal/patch is acceptable, and if not, what changes
you want me to make.  Thanks.

patch:

Fixed a typo with /dev/ttyCPM5.  Added entries for /dev/ttyQE0-3.  The QE
is a replacement for the CPM, so they can share the same minor numbers.

--- devices-2.6+.txt	2007-02-22 13:37:18.000000000 -0600
+++ devices-2.6+.new	2007-02-22 13:42:50.000000000 -0600
@@ -2770,7 +2770,10 @@
  		 45 = /dev/ttyMM1		Marvell MPSC - port 1
  		 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
+		 46 = /dev/ttyQE0		PPC QE (UCC) - port 0
+		    ...
+		 49 = /dev/ttyQE3		PPC QE (UCC) - port 3
  		 50 = /dev/ttyIOC0		Altix serial card
  		    ...
  		 81 = /dev/ttyIOC31		Altix serial card


-- 
Timur Tabi
Linux Kernel Developer @ Freescale

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

[Randy Dunlap]

On Tue, 27 Feb 2007 11:25:10 -0600 Timur Tabi wrote:

> Hi,
> 
> (Email to device@lanana.org bounces, so I'm sending this to lkml instead.)

cc: to Torben


> I'm working on a UART device driver for the Freescale PowerPC QUICCEngine, which
> is a replacement for the CPM.  Since the QE is basically "CPM v3", and you can't
> have a CPM and a QE on the same board, I figure that they can share the same
> minor numbers.
> 
> I've attached a patch that adds these entries to major number 204.  Please not
> that there's a small typo for /dev/ttyCPM5, and I've fixed that in the patch as
> well.
> 
> Please let me know if my proposal/patch is acceptable, and if not, what changes
> you want me to make.  Thanks.
> 
> patch:
> 
> Fixed a typo with /dev/ttyCPM5.  Added entries for /dev/ttyQE0-3.  The QE
> is a replacement for the CPM, so they can share the same minor numbers.
> 
> --- devices-2.6+.txt	2007-02-22 13:37:18.000000000 -0600
> +++ devices-2.6+.new	2007-02-22 13:42:50.000000000 -0600
> @@ -2770,7 +2770,10 @@
>   		 45 = /dev/ttyMM1		Marvell MPSC - port 1
>   		 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
> +		 46 = /dev/ttyQE0		PPC QE (UCC) - port 0
> +		    ...
> +		 49 = /dev/ttyQE3		PPC QE (UCC) - port 3
>   		 50 = /dev/ttyIOC0		Altix serial card
>   		    ...
>   		 81 = /dev/ttyIOC31		Altix serial card
> 
> 
> -- 

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

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

[Segher Boessenkool]

>  		 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?


Segher

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

[Mathiasen, Torben]

> --- devices-2.6+.txt	2007-02-22 13:37:18.000000000 -0600
> +++ devices-2.6+.new	2007-02-22 13:42:50.000000000 -0600
> @@ -2770,7 +2770,10 @@
>   		 45 = /dev/ttyMM1		Marvell MPSC - port 1
>   		 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
> +		 46 = /dev/ttyQE0		PPC QE (UCC) - port 0
> +		    ...
> +		 49 = /dev/ttyQE3		PPC QE (UCC) - port 3
>   		 50 = /dev/ttyIOC0		Altix serial card
>   		    ...
>   		 81 = /dev/ttyIOC31		Altix serial card
>

Got around looking at this one. I'm fine with this approach, but the
CPM5 fix looks wrong. Shouldn't it be:

49 = /dev/ttyCPM3		PPC CPM (SCC or SMC) - port 3

instead?

Thx,
Torben
 

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

[H. Peter Anvin]

Mathiasen, Torben wrote:
> 
> Got around looking at this one. I'm fine with this approach, but the
> CPM5 fix looks wrong. Shouldn't it be:
> 
> 49 = /dev/ttyCPM3		PPC CPM (SCC or SMC) - port 3
> 
> instead?
> 

Well, how many CPM devices can exist?  If there are really 6 ports 
possible, they need minors up to 51.

Also, if QE really is just CPM v3, and they share the same minors, why 
change the name?

	-hpa

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

[Mathiasen, Torben]

> Mathiasen, Torben wrote:
> >
> > Got around looking at this one. I'm fine with this approach, but the
> > CPM5 fix looks wrong. Shouldn't it be:
> >
> > 49 = /dev/ttyCPM3		PPC CPM (SCC or SMC) - port 3
> >
> > instead?
> >
> 
> Well, how many CPM devices can exist?  If there are really 6 ports
> possible, they need minors up to 51.
> 
> Also, if QE really is just CPM v3, and they share the same minors, why
> change the name?
> 

Assuming QE has 4 entries, I would expect CPM to be the same. But we
need verification of that. If it needs 6, we are in more trouble.

Torben

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

[Kumar Gala]

On Feb 28, 2007, at 7:14 AM, Mathiasen, Torben wrote:

>> Mathiasen, Torben wrote:
>>>
>>> Got around looking at this one. I'm fine with this approach, but the
>>> CPM5 fix looks wrong. Shouldn't it be:
>>>
>>> 49 = /dev/ttyCPM3		PPC CPM (SCC or SMC) - port 3
>>>
>>> instead?
>>>
>>
>> Well, how many CPM devices can exist?  If there are really 6 ports
>> possible, they need minors up to 51.
>>
>> Also, if QE really is just CPM v3, and they share the same minors,  
>> why
>> change the name?
>>
>
> Assuming QE has 4 entries, I would expect CPM to be the same. But we
> need verification of that. If it needs 6, we are in more trouble.

I think it really is 6 for the current CPM, and I don't see why we  
its not 8 for QE, Timur?

- k

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

[Timur Tabi]

Segher Boessenkool wrote:
>>           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).

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

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

[Timur Tabi]

H. Peter Anvin wrote:

> Also, if QE really is just CPM v3, and they share the same minors, why 
> change the name?

Because the QE isn't called CPM v3, that's just one way to think about 
it.  It's a different device that has some backwards compatibility, but 
the drivers are all distinct and they all use "QE" and not "CPM" in 
their names.

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

[Timur Tabi]

Mathiasen, Torben wrote:

> Assuming QE has 4 entries, I would expect CPM to be the same. But we
> need verification of that. If it needs 6, we are in more trouble.

The QE can have up to 8, actually, but I'm willing to limit the driver 
to 4.

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

[Mathiasen, Torben]

> 
> Mathiasen, Torben wrote:
> 
> > Assuming QE has 4 entries, I would expect CPM to be the same. But we
> > need verification of that. If it needs 6, we are in more trouble.
> 
> The QE can have up to 8, actually, but I'm willing to limit the driver
> to 4.

Its your choice if you want to limit it to 4 or have it moved into a
different minor range. I can live with both.

Thanks,
Torben

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

[Segher Boessenkool]

>>>           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

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

[Segher Boessenkool]

>>>           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

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

[Kumar Gala]

On Feb 28, 2007, at 8:51 AM, Mathiasen, Torben wrote:

>>
>> Mathiasen, Torben wrote:
>>
>>> Assuming QE has 4 entries, I would expect CPM to be the same. But we
>>> need verification of that. If it needs 6, we are in more trouble.
>>
>> The QE can have up to 8, actually, but I'm willing to limit the  
>> driver
>> to 4.
>
> Its your choice if you want to limit it to 4 or have it moved into a
> different minor range. I can live with both.

I'd rather we support 8 now.

- k

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

[H. Peter Anvin]

Kumar Gala wrote:
> 
> On Feb 28, 2007, at 8:51 AM, Mathiasen, Torben wrote:
> 
>>>
>>> Mathiasen, Torben wrote:
>>>
>>>> Assuming QE has 4 entries, I would expect CPM to be the same. But we
>>>> need verification of that. If it needs 6, we are in more trouble.
>>>
>>> The QE can have up to 8, actually, but I'm willing to limit the driver
>>> to 4.
>>
>> Its your choice if you want to limit it to 4 or have it moved into a
>> different minor range. I can live with both.
> 
> I'd rather we support 8 now.
> 

It sounds like the QE driver should be moved to a separate minor range, 
and given 8 minors.

	-hpa

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

[Dan Malek]

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

>>>>           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

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

[Dan Malek]

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

>>>>           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

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

[Timur Tabi]

Kumar Gala wrote:

>> Its your choice if you want to limit it to 4 or have it moved into a
>> different minor range. I can live with both.
> 
> I'd rather we support 8 now.

Ok, a different minor range it is, then.  192-199?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

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

[Timur Tabi]

H. Peter Anvin wrote:

> It sounds like the QE driver should be moved to a separate minor range, 
> and given 8 minors.

I just had a thought - since udev doesn't care about major/minor number assignments, can 
we say that the limit is 4 devices if you're not using udev, and 8 otherwise?

-- 
Timur Tabi
Linux Kernel Developer @ Freescale

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

[H. Peter Anvin]

Timur Tabi wrote:
> H. Peter Anvin wrote:
> 
>> It sounds like the QE driver should be moved to a separate minor 
>> range, and given 8 minors.
> 
> I just had a thought - since udev doesn't care about major/minor number 
> assignments, can we say that the limit is 4 devices if you're not using 
> udev, and 8 otherwise?
> 

That seems pretty silly.

	-hpa

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

[Timur Tabi]

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

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

[Timur Tabi]

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

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

[Dan Malek]

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

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

[Dan Malek]

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

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

[Timur Tabi]

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

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

[Dan Malek]

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

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

[Timur Tabi]

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

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

[H. Peter Anvin]

Timur Tabi wrote:
> 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?
> 

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

	-hpa

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

[H. Peter Anvin]

Timur Tabi wrote:
> 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?
> 

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

	-hpa

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

[Dan Malek]

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

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

[Kumar Gala]

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

>
> 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.

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 

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

[Kumar Gala]

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

>
> 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.

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 

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

[Timur Tabi]

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

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

[Timur Tabi]

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

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

[H. Peter Anvin]

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

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

[H. Peter Anvin]

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

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

[Segher Boessenkool]

> 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

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

[Segher Boessenkool]

> 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

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

[H. Peter Anvin]

Segher Boessenkool wrote:
>> 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

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

[H. Peter Anvin]

Segher Boessenkool wrote:
>> 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

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

[Timur Tabi]

H. Peter Anvin wrote:
> 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.

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

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

[Timur Tabi]

H. Peter Anvin wrote:
> 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.

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

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

[Kumar Gala]

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

> H. Peter Anvin wrote:
>> 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.
>
> 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

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

[Kumar Gala]

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

> H. Peter Anvin wrote:
>> 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.
>
> 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

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

[Timur Tabi]

Kumar Gala wrote:

>> 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

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

[Timur Tabi]

Kumar Gala wrote:

>> 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

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

[Segher Boessenkool]

>> 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

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

[Segher Boessenkool]

>> 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

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

[Dan Malek]

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

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

[Dan Malek]

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

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

[Segher Boessenkool]

> 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

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

[Segher Boessenkool]

> 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

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

[Jan Engelhardt]

On Feb 28 2007 20:25, Segher Boessenkool wrote:
>> 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
-- 

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

[Jan Engelhardt]

On Feb 28 2007 20:25, Segher Boessenkool wrote:
>> 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
-- 

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

[Mathiasen, Torben]

> 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.
> 

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

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

[Mathiasen, Torben]

> 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

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

[Dan Malek]

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

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

[Dan Malek]

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

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

[Timur Tabi]

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

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

[Timur Tabi]

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

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

[Dan Malek]

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

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

[Dan Malek]

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

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

[Timur Tabi]

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

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

[Timur Tabi]

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

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

[Segher Boessenkool]

>> - 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.

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

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

[Segher Boessenkool]

>> - 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.

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