- 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
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
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
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
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
> 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
>
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
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
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
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
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
- 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
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
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
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
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
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
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
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.
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
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
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
-
To unsubscribe from this list: send the
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
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
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
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
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
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
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
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
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
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
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
-
To unsubscribe from this
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.
-
To unsubscribe from this list: send the line
On Feb 28, 2007, at 9:54 AM, Segher Boessenkool wrote:
46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0
...
- 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
+ 49 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
If CPM0 is 46, then CPM5
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
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
46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0
...
- 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
+ 49 = /dev/ttyCPM5PPC 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
>
> 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
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
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
Segher Boessenkool wrote:
46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0
...
- 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
+ 49 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
If CPM0 is 46, then CPM5 is not 47, but not 49 either.
> 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
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
> --- devices-2.6+.txt 2007-02-22 13:37:18.0 -0600
> +++ devices-2.6+.new 2007-02-22 13:42:50.0 -0600
> @@ -2770,7 +2770,10 @@
>45 = /dev/ttyMM1 Marvell MPSC - port 1
>46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) -
port 0
>
--- devices-2.6+.txt 2007-02-22 13:37:18.0 -0600
+++ devices-2.6+.new 2007-02-22 13:42:50.0 -0600
@@ -2770,7 +2770,10 @@
45 = /dev/ttyMM1 Marvell MPSC - port 1
46 = /dev/ttyCPM0 PPC CPM (SCC or SMC) -
port 0
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
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,
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
Segher Boessenkool wrote:
46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0
...
- 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
+ 49 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
If CPM0 is 46, then CPM5 is not 47, but not 49 either.
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
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
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
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
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.
-
To unsubscribe from this list: send the line
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
-
To unsubscribe from this
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
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
46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0
...
- 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
+ 49 = /dev/ttyCPM5PPC 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
On Feb 28, 2007, at 9:54 AM, Segher Boessenkool wrote:
46 = /dev/ttyCPM0PPC CPM (SCC or SMC) - port 0
...
- 47 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
+ 49 = /dev/ttyCPM5PPC CPM (SCC or SMC) - port 5
If CPM0 is 46, then CPM5
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
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
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
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
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
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
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
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
-
To unsubscribe from this list: send the
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
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
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
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.
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
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
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
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
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
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,
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,
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
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
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
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
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,
84 matches
Mail list logo
