On 08:34 Wed 08 May , Greg KH wrote:
> On Wed, May 08, 2013 at 04:34:43PM +0200, Arnd Bergmann wrote:
> > > +#define ASC_MAJOR 204
> > > +#define ASC_MINOR_START 40
> >
> > I don't know what the current policy is on allocating major/minor numbers,
> > but I'm sure you cannot just reuse one that is already used.
>
> I agree, why are you trying to create a new tty device name? Can't you
> use the existing ttyS name and minor number as you will not have any
> other type of serial device on this system?
Greg on ST STB for more than 10 years we use ttyASC I'll prefer ttySx
on the DTB SoC you have one one IP present the st,asc
Best Regards,
J.
>
> thanks,
>
> greg k-h
> _______________________________________________
> devicetree-discuss mailing list
> [email protected]
> https://lists.ozlabs.org/listinfo/devicetree-discuss
On Wed, May 08, 2013 at 05:40:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 08:34 Wed 08 May , Greg KH wrote:
> > On Wed, May 08, 2013 at 04:34:43PM +0200, Arnd Bergmann wrote:
> > > > +#define ASC_MAJOR 204
> > > > +#define ASC_MINOR_START 40
> > >
> > > I don't know what the current policy is on allocating major/minor numbers,
> > > but I'm sure you cannot just reuse one that is already used.
> >
> > I agree, why are you trying to create a new tty device name? Can't you
> > use the existing ttyS name and minor number as you will not have any
> > other type of serial device on this system?
>
> Greg on ST STB for more than 10 years we use ttyASC I'll prefer ttySx
For 10+ years you have had an out-of-tree serial driver? What
major/minor numbers did you use for it?
> on the DTB SoC you have one one IP present the st,asc
I don't understand, what do you mean by this?
confused,
greg k-h
On May 8, 2013, at 11:53 PM, Greg KH <[email protected]> wrote:
> On Wed, May 08, 2013 at 05:40:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 08:34 Wed 08 May , Greg KH wrote:
>>> On Wed, May 08, 2013 at 04:34:43PM +0200, Arnd Bergmann wrote:
>>>>> +#define ASC_MAJOR 204
>>>>> +#define ASC_MINOR_START 40
>>>>
>>>> I don't know what the current policy is on allocating major/minor numbers,
>>>> but I'm sure you cannot just reuse one that is already used.
>>>
>>> I agree, why are you trying to create a new tty device name? Can't you
>>> use the existing ttyS name and minor number as you will not have any
>>> other type of serial device on this system?
>>
>> Greg on ST STB for more than 10 years we use ttyASC I'll prefer ttySx
>
> For 10+ years you have had an out-of-tree serial driver?
yes ST have it out of tree for very long time even I puts them to come mainline
> What
> major/minor numbers did you use for it?
http://git.stlinux.com/?p=havana/com.st.havana.kernel.git;a=blob;f=drivers/serial/stm-asc.h;h=79e003ffeb21df55a6af94774fc9c4b3d8de18e9;hb=HEAD
52 #define ASC_MAJOR 204
53 #define ASC_MINOR_START 40
same as in this patch
>
>> on the DTB SoC you have one one IP present the st,asc
>
> I don't understand, what do you mean by this?
>
> confused,
just mention there is not hardware reason to not use the generic ttySx in place of ttyAS
as we have only one IP that handle serial on this family of SoC
personally I'll switch to ttySx
Best Regards,
J.-
On Thu, May 09, 2013 at 12:03:05AM +0800, Jean-Christophe PLAGNIOL-VILLARD wrote:
>
> On May 8, 2013, at 11:53 PM, Greg KH <[email protected]> wrote:
>
> > On Wed, May 08, 2013 at 05:40:57PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >> On 08:34 Wed 08 May , Greg KH wrote:
> >>> On Wed, May 08, 2013 at 04:34:43PM +0200, Arnd Bergmann wrote:
> >>>>> +#define ASC_MAJOR 204
> >>>>> +#define ASC_MINOR_START 40
> >>>>
> >>>> I don't know what the current policy is on allocating major/minor numbers,
> >>>> but I'm sure you cannot just reuse one that is already used.
> >>>
> >>> I agree, why are you trying to create a new tty device name? Can't you
> >>> use the existing ttyS name and minor number as you will not have any
> >>> other type of serial device on this system?
> >>
> >> Greg on ST STB for more than 10 years we use ttyASC I'll prefer ttySx
> >
> > For 10+ years you have had an out-of-tree serial driver?
> yes ST have it out of tree for very long time even I puts them to come mainline
Crazy...
> > What
> > major/minor numbers did you use for it?
>
> http://git.stlinux.com/?p=havana/com.st.havana.kernel.git;a=blob;f=drivers/serial/stm-asc.h;h=79e003ffeb21df55a6af94774fc9c4b3d8de18e9;hb=HEAD
>
> 52 #define ASC_MAJOR 204
> 53 #define ASC_MINOR_START 40
>
> same as in this patch
Ok, but just because you have been using an out-of-tree name, and
non-reserved major/minor, doesn't mean we have to accept it. As you are
probably using a tool like udev/devtmpfs on your systems, the
major/minor number shouldn't matter, only the name.
And I'd argue that we should change the name as well.
> >> on the DTB SoC you have one one IP present the st,asc
> >
> > I don't understand, what do you mean by this?
> >
> > confused,
>
> just mention there is not hardware reason to not use the generic ttySx
> in place of ttyAS as we have only one IP that handle serial on this
> family of SoC
>
> personally I'll switch to ttySx
Great, then you can use the same major/minor range as well, so there's
no more objection from me about this :)
thanks,
greg k-h
On Wednesday 08 May 2013, Greg KH wrote:
> > just mention there is not hardware reason to not use the generic ttySx
> > in place of ttyAS as we have only one IP that handle serial on this
> > family of SoC
> >
> > personally I'll switch to ttySx
>
> Great, then you can use the same major/minor range as well, so there's
> no more objection from me about this :)
Does that work these days when you have kernel with multiple built-in
uart drivers?
I think it would be good if all uarts were using the same name space
and major/minor numbers, but I think the mess we currently have is
the result of the tty_register_driver() interface reserving the
device number range at driver load time, independent of the presence
of devices. I would assume that normal distro kernels always ship
with an 8250 driver built-in to allow using that as the console,
and if I read the code correctly, that currently prevents another
uart driver from registering the same major/minor numbers.
Arnd
On Wed, May 08, 2013 at 06:31:48PM +0200, Arnd Bergmann wrote:
> On Wednesday 08 May 2013, Greg KH wrote:
> > > just mention there is not hardware reason to not use the generic ttySx
> > > in place of ttyAS as we have only one IP that handle serial on this
> > > family of SoC
> > >
> > > personally I'll switch to ttySx
> >
> > Great, then you can use the same major/minor range as well, so there's
> > no more objection from me about this :)
>
> Does that work these days when you have kernel with multiple built-in
> uart drivers?
It "should", as the major/minor registration should only happen when the
hardware is found, but I haven't tested it out, so I can't say for sure.
> I think it would be good if all uarts were using the same name space
> and major/minor numbers, but I think the mess we currently have is
> the result of the tty_register_driver() interface reserving the
> device number range at driver load time, independent of the presence
> of devices. I would assume that normal distro kernels always ship
> with an 8250 driver built-in to allow using that as the console,
> and if I read the code correctly, that currently prevents another
> uart driver from registering the same major/minor numbers.
We can always fix this if needed :)
thanks,
greg k-h
On May 9, 2013, at 12:31 AM, Arnd Bergmann <[email protected]> wrote:
> On Wednesday 08 May 2013, Greg KH wrote:
>>> just mention there is not hardware reason to not use the generic ttySx
>>> in place of ttyAS as we have only one IP that handle serial on this
>>> family of SoC
>>>
>>> personally I'll switch to ttySx
>>
>> Great, then you can use the same major/minor range as well, so there's
>> no more objection from me about this :)
>
> Does that work these days when you have kernel with multiple built-in
> uart drivers?
not for very long time and no this family
>
> I think it would be good if all uarts were using the same name space
> and major/minor numbers, but I think the mess we currently have is
> the result of the tty_register_driver() interface reserving the
> device number range at driver load time, independent of the presence
> of devices. I would assume that normal distro kernels always ship
> with an 8250 driver built-in to allow using that as the console,
> and if I read the code correctly, that currently prevents another
> uart driver from registering the same major/minor numbers.
so we need to fix this
>
> Arnd
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wed, 8 May 2013, Arnd Bergmann wrote:
> On Wednesday 08 May 2013, Greg KH wrote:
> > > just mention there is not hardware reason to not use the generic ttySx
> > > in place of ttyAS as we have only one IP that handle serial on this
> > > family of SoC
> > >
> > > personally I'll switch to ttySx
> >
> > Great, then you can use the same major/minor range as well, so there's
> > no more objection from me about this :)
>
> Does that work these days when you have kernel with multiple built-in
> uart drivers?
>
> I think it would be good if all uarts were using the same name space
> and major/minor numbers, but I think the mess we currently have is
> the result of the tty_register_driver() interface reserving the
> device number range at driver load time, independent of the presence
> of devices. I would assume that normal distro kernels always ship
> with an 8250 driver built-in to allow using that as the console,
> and if I read the code correctly, that currently prevents another
> uart driver from registering the same major/minor numbers.
I tried to fix this up over 10 years ago. RMK tried as well. This
failed because X86 people insisted on always having COM1 as /dev/ttyS0,
COM3 as /dev/ttyS2 and so on, even when some of them weren't present.
A common and dynamic namespace eventually succeeded for hard disks.
Maybe people are ready to accept it for serial ports as well now?
Nicolas
On Wednesday 08 May 2013, Nicolas Pitre wrote:
> I tried to fix this up over 10 years ago. RMK tried as well. This
> failed because X86 people insisted on always having COM1 as /dev/ttyS0,
> COM3 as /dev/ttyS2 and so on, even when some of them weren't present.
>
> A common and dynamic namespace eventually succeeded for hard disks.
> Maybe people are ready to accept it for serial ports as well now?
Unfortunately it only worked for hard disks because the old name
space was abandoned entirely. It also caused a lot of surprises
for people upgrading their kernels, which is something we probably
don't want to repeat.
Now we could add a new dynamic registration facility to the tty
layer for drivers that don't already have a name and dev_t
associated with the driver, and then use it for all new drivers
as well as those that intentionally want to convert.
With DT aliases, we already have a way to enumerate serial ports
across device drivers, so if we are going to do something new,
we should make sure it works with the numbers defined there.
Arnd
On 20:35 Wed 08 May , Arnd Bergmann wrote:
> On Wednesday 08 May 2013, Nicolas Pitre wrote:
> > I tried to fix this up over 10 years ago. RMK tried as well. This
> > failed because X86 people insisted on always having COM1 as /dev/ttyS0,
> > COM3 as /dev/ttyS2 and so on, even when some of them weren't present.
> >
> > A common and dynamic namespace eventually succeeded for hard disks.
> > Maybe people are ready to accept it for serial ports as well now?
>
> Unfortunately it only worked for hard disks because the old name
> space was abandoned entirely. It also caused a lot of surprises
> for people upgrading their kernels, which is something we probably
> don't want to repeat.
>
> Now we could add a new dynamic registration facility to the tty
> layer for drivers that don't already have a name and dev_t
> associated with the driver, and then use it for all new drivers
> as well as those that intentionally want to convert.
specially that we use devtmpfs and udev
we do not care much about minor/major
>
> With DT aliases, we already have a way to enumerate serial ports
> across device drivers, so if we are going to do something new,
> we should make sure it works with the numbers defined there.
>
> Arnd
On Wed, May 08, 2013 at 09:36:13AM -0700, Greg KH wrote:
> On Wed, May 08, 2013 at 06:31:48PM +0200, Arnd Bergmann wrote:
> > On Wednesday 08 May 2013, Greg KH wrote:
> > > > just mention there is not hardware reason to not use the generic ttySx
> > > > in place of ttyAS as we have only one IP that handle serial on this
> > > > family of SoC
> > > >
> > > > personally I'll switch to ttySx
> > >
> > > Great, then you can use the same major/minor range as well, so there's
> > > no more objection from me about this :)
> >
> > Does that work these days when you have kernel with multiple built-in
> > uart drivers?
>
> It "should", as the major/minor registration should only happen when the
> hardware is found, but I haven't tested it out, so I can't say for sure.
serial stuff has never operated like that. More specifically, it's a
limitation with the tty stuff that the way stuff works is that a
tty driver can only drive a single bunch of contiguous minor numbers.
No interleaving is allowed.
That limitation has existed for years, and I don't see it going away.
As long as that limitation exists, you can only ever have one serial
driver driving a set of contiguous minor numbers.
There has been an attempt to "work around" this by making the 8250
driver "special" which was a complete hack to get it to work. That
was while I maintained this stuff and I outright refused to make one
serial driver magically special.