Hi,
(Email to [email protected] 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
On Tue, 27 Feb 2007 11:25:10 -0600 Timur Tabi wrote:
> Hi,
>
> (Email to [email protected] 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 ***
> 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
> --- 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
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
> 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
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
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.
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.
>
> 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
>>> 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 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
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
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
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.
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
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
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
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:
>
>> 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 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
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
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:
>> 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
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
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
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
>> 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, 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 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
--