On Wednesday 22 May 2013, Arnd Bergmann wrote:
> > Also all of the custom_divisor functionality is basically commented as "old"
> > or has a kernel warning saying it is deprecated (see uart_set_info), so as
> > far as I can see for our (and I suspect most) hardware it is completely
> > irrelevant
On Wednesday 22 May 2013, Arnd Bergmann wrote:
Also all of the custom_divisor functionality is basically commented as old
or has a kernel warning saying it is deprecated (see uart_set_info), so as
far as I can see for our (and I suspect most) hardware it is completely
irrelevant
On Monday 20 May 2013, Stephen GALLIMORE wrote:
> We have pretty much completed reworking the patch set we sent recently, but
> there is one comment you made which seemed to make perfect sense
> but after investigating it has left me totally confused, which was:
>
> >I would also recommed adding
On Monday 20 May 2013, Stephen GALLIMORE wrote:
We have pretty much completed reworking the patch set we sent recently, but
there is one comment you made which seemed to make perfect sense
but after investigating it has left me totally confused, which was:
I would also recommed adding a way
Hi Arnd,
We have pretty much completed reworking the patch set we sent recently, but
there is one comment you made which seemed to make perfect sense
but after investigating it has left me totally confused, which was:
>I would also recommed adding a way to set the default baud rate through
> a
Hi Arnd,
We have pretty much completed reworking the patch set we sent recently, but
there is one comment you made which seemed to make perfect sense
but after investigating it has left me totally confused, which was:
I would also recommed adding a way to set the default baud rate through
a
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
On Fri, May 10, 2013 at 03:50:16PM +0200, Stephen GALLIMORE wrote:
> Greg, having looked at this we have concluded that we should just go
> dynamic, as others have mentioned with udev on a full system or
> devtmpfs on a minimal initramfs system there is no reason to use a
> static major/minor.
>On Wed, May 08, 2013 at 04:34:43PM +0200, Arnd Bergmann wrote:
> > > +#define ASC_MAJOR204
> > > +#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
On Wed, May 08, 2013 at 04:34:43PM +0200, Arnd Bergmann wrote:
+#define ASC_MAJOR204
+#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.
First,
On Fri, May 10, 2013 at 03:50:16PM +0200, Stephen GALLIMORE wrote:
Greg, having looked at this we have concluded that we should just go
dynamic, as others have mentioned with udev on a full system or
devtmpfs on a minimal initramfs system there is no reason to use a
static major/minor. However
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
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
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
On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
>
> On 08/05/13 15:39, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>> +
> >> >
> >> > Please remove all forward declarations, by reordering the functions in
> >> > the way they are called.
> >> >
> > and drop the dummy functions
>
> We can not
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
On 08/05/13 15:39, Jean-Christophe PLAGNIOL-VILLARD wrote:
>>> +
>> >
>> > Please remove all forward declarations, by reordering the functions in
>> > the way they are called.
>> >
> and drop the dummy functions
We can not remove the dummy functions, as the serial-core does not check
it before
Thankyou for the comments.
On 08/05/13 15:34, Arnd Bergmann wrote:
> On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
>> From: Srinivas Kandagatla
>> +*st-asc(Serial Port)
>> +
>> +Required properties:
>> +- compatible : Should be "st,asc".
> Are there any hardware revision numbers for the
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
On May 9, 2013, at 12:31 AM, 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
On 08:34 Wed 08 May , Greg KH wrote:
> On Wed, May 08, 2013 at 04:34:43PM +0200, Arnd Bergmann wrote:
> > > +#define ASC_MAJOR204
> > > +#define ASC_MINOR_START 40
> >
> > I don't know what the current policy is on allocating major/minor numbers,
> > but I'm sure you
>On Wed, May 08, 2013 at 04:34:43PM +0200, Arnd Bergmann wrote:
> > > +#define ASC_MAJOR204
> > > +#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
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
> > >
> > >
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
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 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,
On May 8, 2013, at 11:53 PM, Greg KH 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_MAJOR204
>
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_START40
> > >
> >
On 16:34 Wed 08 May , Arnd Bergmann wrote:
> On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
> > From: Srinivas Kandagatla
>
> > +*st-asc(Serial Port)
> > +
> > +Required properties:
> > +- compatible : Should be "st,asc".
>
> Are there any hardware revision numbers for the asc? If
On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
> From: Srinivas Kandagatla
> +*st-asc(Serial Port)
> +
> +Required properties:
> +- compatible : Should be "st,asc".
Are there any hardware revision numbers for the asc? If there are potentially
incompatible or backwards-compatible variants,
On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
+*st-asc(Serial Port)
+
+Required properties:
+- compatible : Should be st,asc.
Are there any hardware revision numbers for the asc? If there are potentially
incompatible or
On 16:34 Wed 08 May , Arnd Bergmann wrote:
On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
+*st-asc(Serial Port)
+
+Required properties:
+- compatible : Should be st,asc.
Are there any hardware revision numbers for the
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_START40
I don't know
On May 8, 2013, at 11:53 PM, Greg KH gre...@linuxfoundation.org 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
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 gre...@linuxfoundation.org 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,
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
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
On Wed, May 08, 2013 at 04:34:43PM +0200, Arnd Bergmann wrote:
+#define ASC_MAJOR204
+#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.
First,
On 08:34 Wed 08 May , Greg KH wrote:
On Wed, May 08, 2013 at 04:34:43PM +0200, Arnd Bergmann wrote:
+#define ASC_MAJOR204
+#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
On May 9, 2013, at 12:31 AM, Arnd Bergmann a...@arndb.de 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
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,
Thankyou for the comments.
On 08/05/13 15:34, Arnd Bergmann wrote:
On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
From: Srinivas Kandagatla srinivas.kandaga...@st.com
+*st-asc(Serial Port)
+
+Required properties:
+- compatible : Should be st,asc.
Are there any hardware revision
On 08/05/13 15:39, Jean-Christophe PLAGNIOL-VILLARD wrote:
+
Please remove all forward declarations, by reordering the functions in
the way they are called.
and drop the dummy functions
We can not remove the dummy functions, as the serial-core does not check
it before using them.
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
On Wednesday 08 May 2013, Srinivas KANDAGATLA wrote:
On 08/05/13 15:39, Jean-Christophe PLAGNIOL-VILLARD wrote:
+
Please remove all forward declarations, by reordering the functions in
the way they are called.
and drop the dummy functions
We can not remove the dummy
44 matches
Mail list logo
