Mailing List Archive

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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 line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

> 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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/