Re: [PATCH 01/11] resolve PXA<->8250 serial device address conflict

2014-01-28 Thread Sergei Ianovich
On Tue, 2014-01-28 at 15:14 +0100, Pavel Machek wrote:
> Yes, please. I was hitting the same issue with Sharp Zaurus and bluetooth
> CF card... Bluetooth card had 8250 inside...

A better implementation is posted as v3 of the patch.

http://linux-kernel.2935.n7.nabble.com/PATCH-00-11-ARM-support-for-ICP-DAS-LP-8x4x-tp761919p773485.html

It would be great if you could test that patch add post back the
results.

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


Re: [PATCH 01/11] resolve PXA<->8250 serial device address conflict

2014-01-28 Thread Pavel Machek
Hi!

> PXA serial ports have "standard" UART names (ttyS[0-3]), major
> device number (4) and first minor device number (64) by default.
> 
> If the system has extra 8250 serial port hardware in addition
> to onboard PXA serial ports, default settings produce a device
> allocation conflict.
> 
> The patch provides a configuration option which can move onboard
> ports out of the way of 8250_core by assigning a different (204)
> major number and corresponding device names (ttySA[0-3]).

Yes, please. I was hitting the same issue with Sharp Zaurus and bluetooth
CF card... Bluetooth card had 8250 inside...


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 01/11] resolve PXA-8250 serial device address conflict

2014-01-28 Thread Pavel Machek
Hi!

 PXA serial ports have standard UART names (ttyS[0-3]), major
 device number (4) and first minor device number (64) by default.
 
 If the system has extra 8250 serial port hardware in addition
 to onboard PXA serial ports, default settings produce a device
 allocation conflict.
 
 The patch provides a configuration option which can move onboard
 ports out of the way of 8250_core by assigning a different (204)
 major number and corresponding device names (ttySA[0-3]).

Yes, please. I was hitting the same issue with Sharp Zaurus and bluetooth
CF card... Bluetooth card had 8250 inside...


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 01/11] resolve PXA-8250 serial device address conflict

2014-01-28 Thread Sergei Ianovich
On Tue, 2014-01-28 at 15:14 +0100, Pavel Machek wrote:
 Yes, please. I was hitting the same issue with Sharp Zaurus and bluetooth
 CF card... Bluetooth card had 8250 inside...

A better implementation is posted as v3 of the patch.

http://linux-kernel.2935.n7.nabble.com/PATCH-00-11-ARM-support-for-ICP-DAS-LP-8x4x-tp761919p773485.html

It would be great if you could test that patch add post back the
results.

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


Re: [PATCH 01/11] resolve PXA<->8250 serial device address conflict

2013-12-04 Thread Sergei Ianovich
On Wed, 2013-12-04 at 20:35 -0800, Greg Kroah-Hartman wrote:
> On Thu, Dec 05, 2013 at 08:31:36AM +0400, Sergei Ianovich wrote:
> > I'm reading the last message as a confirmation that
> > drivers/tty/serial/pxa.c needs to be rewritten using 8250_core.c.
> 
> Yes, how much work is this really?

Great. It seems two drivers practically match. I'll do and submit a
merge patch.

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


Re: [PATCH 01/11] resolve PXA<->8250 serial device address conflict

2013-12-04 Thread Greg Kroah-Hartman
On Thu, Dec 05, 2013 at 08:31:36AM +0400, Sergei Ianovich wrote:
> On Wed, 2013-12-04 at 20:12 -0800, Greg Kroah-Hartman wrote:
> > On Mon, Dec 02, 2013 at 04:10:33PM +0200, Heikki Krogerus wrote:
> > > On Mon, Dec 02, 2013 at 02:26:45PM +0400, Sergei Ianovich wrote:
> > > > Who makes the decision which way to go?
> > > 
> > > Greg and Russel make this decision. By having the pxa driver simply
> > > register 8250 ports would probable reduce the code. Thats about the
> > > biggest benefit from it.
> > > 
> > > It would still be something nice to have IMO. Ideally all the
> > > 8250/16x50 UARTs should register the ports with 8250_core.c, and not
> > > create complete uart driver on their own.
> > 
> > I agree, this is the best way to resolve this, having a separate uart
> > driver isn't that good at all to be doing, if at all possible.
> 
> I'm reading the last message as a confirmation that
> drivers/tty/serial/pxa.c needs to be rewritten using 8250_core.c.

Yes, how much work is this really?

thanks,

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


Re: [PATCH 01/11] resolve PXA<->8250 serial device address conflict

2013-12-04 Thread Sergei Ianovich
On Wed, 2013-12-04 at 20:12 -0800, Greg Kroah-Hartman wrote:
> On Mon, Dec 02, 2013 at 04:10:33PM +0200, Heikki Krogerus wrote:
> > On Mon, Dec 02, 2013 at 02:26:45PM +0400, Sergei Ianovich wrote:
> > > Who makes the decision which way to go?
> > 
> > Greg and Russel make this decision. By having the pxa driver simply
> > register 8250 ports would probable reduce the code. Thats about the
> > biggest benefit from it.
> > 
> > It would still be something nice to have IMO. Ideally all the
> > 8250/16x50 UARTs should register the ports with 8250_core.c, and not
> > create complete uart driver on their own.
> 
> I agree, this is the best way to resolve this, having a separate uart
> driver isn't that good at all to be doing, if at all possible.

I'm reading the last message as a confirmation that
drivers/tty/serial/pxa.c needs to be rewritten using 8250_core.c.
However, "if at all possible" confuses me, since we have pxa.c in the
tree and it works. Greg, could you please clarify?

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


Re: [PATCH 01/11] resolve PXA<->8250 serial device address conflict

2013-12-04 Thread Greg Kroah-Hartman
On Mon, Dec 02, 2013 at 04:10:33PM +0200, Heikki Krogerus wrote:
> Hi,
> 
> On Mon, Dec 02, 2013 at 02:26:45PM +0400, Sergei Ianovich wrote:
> > On Mon, 2013-12-02 at 11:49 +0200, Heikki Krogerus wrote:
> > > On Mon, Dec 02, 2013 at 01:23:58PM +0400, Sergei Ianovich wrote:
> > > > On Mon, 2013-12-02 at 11:02 +0200, Heikki Krogerus wrote:
> > > > > 
> > > > > If drivers/tty/serial/pxa.c was converted to an other probe driver for
> > > > > the 8250, this would not be an issue.
> > > > 
> > > > It seems that my patch is not going to be accepted. However, there is a
> > > > device which has both PXA ports and a additional 8250 accent chip. As a
> > > > result, there is a device allocation conflict. For the device to be
> > > > usable the conflict needs to be resolved.
> > > > 
> > > > Do you mean that drivers/tty/serial/pxa.c needs to be rewritten to
> > > > support lp8x4x special case?
> > > 
> > > Sorry I was not clear. I was suggesting that drivers/tty/serial/pxa.c
> > > would be converted to drivers/tty/serial/8250/8250_pxa.c since it
> > > looks to me like just an other 16x50 compatible UART. That would fix
> > > the issue with the name conflict. You would then simply register 8250
> > > ports from two probe drivers (drivers/tty/serial/8250/8250_pxa.c and
> > > drivers/tty/serial/8250/8250_lp8x4x.c).
> > > 
> > > Depending on the order you register your platform devices (which you
> > > decide in your platform code), but let's say the pxa gets registered
> > > first and let's say it only has one port. You will then have in your
> > > system /dev/ttyS0 for the pxa port and /dev/ttyS[1-4] for the other
> > > UART.
> > > 
> > > I hope I was able to explain what I mean this time :)
> > 
> > Sorry, I wasn't clear as well. I got it right the first time. You mean
> > pxa.c needs to merged into 8250. This will solve the conflict in
> > question, and do it the right way. However, this will be a *much* bigger
> > patch, and it will affect everyone on pxa.
> > 
> > Who makes the decision which way to go?
> 
> Greg and Russel make this decision. By having the pxa driver simply
> register 8250 ports would probable reduce the code. Thats about the
> biggest benefit from it.
> 
> It would still be something nice to have IMO. Ideally all the
> 8250/16x50 UARTs should register the ports with 8250_core.c, and not
> create complete uart driver on their own.

I agree, this is the best way to resolve this, having a separate uart
driver isn't that good at all to be doing, if at all possible.

thanks,

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


Re: [PATCH 01/11] resolve PXA-8250 serial device address conflict

2013-12-04 Thread Greg Kroah-Hartman
On Mon, Dec 02, 2013 at 04:10:33PM +0200, Heikki Krogerus wrote:
 Hi,
 
 On Mon, Dec 02, 2013 at 02:26:45PM +0400, Sergei Ianovich wrote:
  On Mon, 2013-12-02 at 11:49 +0200, Heikki Krogerus wrote:
   On Mon, Dec 02, 2013 at 01:23:58PM +0400, Sergei Ianovich wrote:
On Mon, 2013-12-02 at 11:02 +0200, Heikki Krogerus wrote:
 
 If drivers/tty/serial/pxa.c was converted to an other probe driver for
 the 8250, this would not be an issue.

It seems that my patch is not going to be accepted. However, there is a
device which has both PXA ports and a additional 8250 accent chip. As a
result, there is a device allocation conflict. For the device to be
usable the conflict needs to be resolved.

Do you mean that drivers/tty/serial/pxa.c needs to be rewritten to
support lp8x4x special case?
   
   Sorry I was not clear. I was suggesting that drivers/tty/serial/pxa.c
   would be converted to drivers/tty/serial/8250/8250_pxa.c since it
   looks to me like just an other 16x50 compatible UART. That would fix
   the issue with the name conflict. You would then simply register 8250
   ports from two probe drivers (drivers/tty/serial/8250/8250_pxa.c and
   drivers/tty/serial/8250/8250_lp8x4x.c).
   
   Depending on the order you register your platform devices (which you
   decide in your platform code), but let's say the pxa gets registered
   first and let's say it only has one port. You will then have in your
   system /dev/ttyS0 for the pxa port and /dev/ttyS[1-4] for the other
   UART.
   
   I hope I was able to explain what I mean this time :)
  
  Sorry, I wasn't clear as well. I got it right the first time. You mean
  pxa.c needs to merged into 8250. This will solve the conflict in
  question, and do it the right way. However, this will be a *much* bigger
  patch, and it will affect everyone on pxa.
  
  Who makes the decision which way to go?
 
 Greg and Russel make this decision. By having the pxa driver simply
 register 8250 ports would probable reduce the code. Thats about the
 biggest benefit from it.
 
 It would still be something nice to have IMO. Ideally all the
 8250/16x50 UARTs should register the ports with 8250_core.c, and not
 create complete uart driver on their own.

I agree, this is the best way to resolve this, having a separate uart
driver isn't that good at all to be doing, if at all possible.

thanks,

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


Re: [PATCH 01/11] resolve PXA-8250 serial device address conflict

2013-12-04 Thread Sergei Ianovich
On Wed, 2013-12-04 at 20:12 -0800, Greg Kroah-Hartman wrote:
 On Mon, Dec 02, 2013 at 04:10:33PM +0200, Heikki Krogerus wrote:
  On Mon, Dec 02, 2013 at 02:26:45PM +0400, Sergei Ianovich wrote:
   Who makes the decision which way to go?
  
  Greg and Russel make this decision. By having the pxa driver simply
  register 8250 ports would probable reduce the code. Thats about the
  biggest benefit from it.
  
  It would still be something nice to have IMO. Ideally all the
  8250/16x50 UARTs should register the ports with 8250_core.c, and not
  create complete uart driver on their own.
 
 I agree, this is the best way to resolve this, having a separate uart
 driver isn't that good at all to be doing, if at all possible.

I'm reading the last message as a confirmation that
drivers/tty/serial/pxa.c needs to be rewritten using 8250_core.c.
However, if at all possible confuses me, since we have pxa.c in the
tree and it works. Greg, could you please clarify?

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


Re: [PATCH 01/11] resolve PXA-8250 serial device address conflict

2013-12-04 Thread Greg Kroah-Hartman
On Thu, Dec 05, 2013 at 08:31:36AM +0400, Sergei Ianovich wrote:
 On Wed, 2013-12-04 at 20:12 -0800, Greg Kroah-Hartman wrote:
  On Mon, Dec 02, 2013 at 04:10:33PM +0200, Heikki Krogerus wrote:
   On Mon, Dec 02, 2013 at 02:26:45PM +0400, Sergei Ianovich wrote:
Who makes the decision which way to go?
   
   Greg and Russel make this decision. By having the pxa driver simply
   register 8250 ports would probable reduce the code. Thats about the
   biggest benefit from it.
   
   It would still be something nice to have IMO. Ideally all the
   8250/16x50 UARTs should register the ports with 8250_core.c, and not
   create complete uart driver on their own.
  
  I agree, this is the best way to resolve this, having a separate uart
  driver isn't that good at all to be doing, if at all possible.
 
 I'm reading the last message as a confirmation that
 drivers/tty/serial/pxa.c needs to be rewritten using 8250_core.c.

Yes, how much work is this really?

thanks,

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


Re: [PATCH 01/11] resolve PXA-8250 serial device address conflict

2013-12-04 Thread Sergei Ianovich
On Wed, 2013-12-04 at 20:35 -0800, Greg Kroah-Hartman wrote:
 On Thu, Dec 05, 2013 at 08:31:36AM +0400, Sergei Ianovich wrote:
  I'm reading the last message as a confirmation that
  drivers/tty/serial/pxa.c needs to be rewritten using 8250_core.c.
 
 Yes, how much work is this really?

Great. It seems two drivers practically match. I'll do and submit a
merge patch.

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


Re: [PATCH 01/11] resolve PXA<->8250 serial device address conflict

2013-12-02 Thread Heikki Krogerus
Hi,

On Mon, Dec 02, 2013 at 02:26:45PM +0400, Sergei Ianovich wrote:
> On Mon, 2013-12-02 at 11:49 +0200, Heikki Krogerus wrote:
> > On Mon, Dec 02, 2013 at 01:23:58PM +0400, Sergei Ianovich wrote:
> > > On Mon, 2013-12-02 at 11:02 +0200, Heikki Krogerus wrote:
> > > > 
> > > > If drivers/tty/serial/pxa.c was converted to an other probe driver for
> > > > the 8250, this would not be an issue.
> > > 
> > > It seems that my patch is not going to be accepted. However, there is a
> > > device which has both PXA ports and a additional 8250 accent chip. As a
> > > result, there is a device allocation conflict. For the device to be
> > > usable the conflict needs to be resolved.
> > > 
> > > Do you mean that drivers/tty/serial/pxa.c needs to be rewritten to
> > > support lp8x4x special case?
> > 
> > Sorry I was not clear. I was suggesting that drivers/tty/serial/pxa.c
> > would be converted to drivers/tty/serial/8250/8250_pxa.c since it
> > looks to me like just an other 16x50 compatible UART. That would fix
> > the issue with the name conflict. You would then simply register 8250
> > ports from two probe drivers (drivers/tty/serial/8250/8250_pxa.c and
> > drivers/tty/serial/8250/8250_lp8x4x.c).
> > 
> > Depending on the order you register your platform devices (which you
> > decide in your platform code), but let's say the pxa gets registered
> > first and let's say it only has one port. You will then have in your
> > system /dev/ttyS0 for the pxa port and /dev/ttyS[1-4] for the other
> > UART.
> > 
> > I hope I was able to explain what I mean this time :)
> 
> Sorry, I wasn't clear as well. I got it right the first time. You mean
> pxa.c needs to merged into 8250. This will solve the conflict in
> question, and do it the right way. However, this will be a *much* bigger
> patch, and it will affect everyone on pxa.
> 
> Who makes the decision which way to go?

Greg and Russel make this decision. By having the pxa driver simply
register 8250 ports would probable reduce the code. Thats about the
biggest benefit from it.

It would still be something nice to have IMO. Ideally all the
8250/16x50 UARTs should register the ports with 8250_core.c, and not
create complete uart driver on their own.

Br,

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


Re: [PATCH 01/11] resolve PXA<->8250 serial device address conflict

2013-12-02 Thread Sergei Ianovich
On Mon, 2013-12-02 at 11:49 +0200, Heikki Krogerus wrote:
> On Mon, Dec 02, 2013 at 01:23:58PM +0400, Sergei Ianovich wrote:
> > On Mon, 2013-12-02 at 11:02 +0200, Heikki Krogerus wrote:
> > > On Sun, Dec 01, 2013 at 10:26:14AM +0400, Sergei Ianovich wrote:
> > > > PXA serial ports have "standard" UART names (ttyS[0-3]), major
> > > > device number (4) and first minor device number (64) by default.
> > > > 
> > > > If the system has extra 8250 serial port hardware in addition
> > > > to onboard PXA serial ports, default settings produce a device
> > > > allocation conflict.
> > > > 
> > > > The patch provides a configuration option which can move onboard
> > > > ports out of the way of 8250_core by assigning a different (204)
> > > > major number and corresponding device names (ttySA[0-3]).
> > > > 
> > > 
> > > 
> > > If drivers/tty/serial/pxa.c was converted to an other probe driver for
> > > the 8250, this would not be an issue.
> > 
> > It seems that my patch is not going to be accepted. However, there is a
> > device which has both PXA ports and a additional 8250 accent chip. As a
> > result, there is a device allocation conflict. For the device to be
> > usable the conflict needs to be resolved.
> > 
> > Do you mean that drivers/tty/serial/pxa.c needs to be rewritten to
> > support lp8x4x special case?
> 
> Sorry I was not clear. I was suggesting that drivers/tty/serial/pxa.c
> would be converted to drivers/tty/serial/8250/8250_pxa.c since it
> looks to me like just an other 16x50 compatible UART. That would fix
> the issue with the name conflict. You would then simply register 8250
> ports from two probe drivers (drivers/tty/serial/8250/8250_pxa.c and
> drivers/tty/serial/8250/8250_lp8x4x.c).
> 
> Depending on the order you register your platform devices (which you
> decide in your platform code), but let's say the pxa gets registered
> first and let's say it only has one port. You will then have in your
> system /dev/ttyS0 for the pxa port and /dev/ttyS[1-4] for the other
> UART.
> 
> I hope I was able to explain what I mean this time :)

Sorry, I wasn't clear as well. I got it right the first time. You mean
pxa.c needs to merged into 8250. This will solve the conflict in
question, and do it the right way. However, this will be a *much* bigger
patch, and it will affect everyone on pxa.

Who makes the decision which way to go?

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


Re: [PATCH 01/11] resolve PXA<->8250 serial device address conflict

2013-12-02 Thread Heikki Krogerus
Hi,

On Mon, Dec 02, 2013 at 01:23:58PM +0400, Sergei Ianovich wrote:
> On Mon, 2013-12-02 at 11:02 +0200, Heikki Krogerus wrote:
> > On Sun, Dec 01, 2013 at 10:26:14AM +0400, Sergei Ianovich wrote:
> > > PXA serial ports have "standard" UART names (ttyS[0-3]), major
> > > device number (4) and first minor device number (64) by default.
> > > 
> > > If the system has extra 8250 serial port hardware in addition
> > > to onboard PXA serial ports, default settings produce a device
> > > allocation conflict.
> > > 
> > > The patch provides a configuration option which can move onboard
> > > ports out of the way of 8250_core by assigning a different (204)
> > > major number and corresponding device names (ttySA[0-3]).
> > > 
> > 
> > 
> > If drivers/tty/serial/pxa.c was converted to an other probe driver for
> > the 8250, this would not be an issue.
> 
> It seems that my patch is not going to be accepted. However, there is a
> device which has both PXA ports and a additional 8250 accent chip. As a
> result, there is a device allocation conflict. For the device to be
> usable the conflict needs to be resolved.
> 
> Do you mean that drivers/tty/serial/pxa.c needs to be rewritten to
> support lp8x4x special case?

Sorry I was not clear. I was suggesting that drivers/tty/serial/pxa.c
would be converted to drivers/tty/serial/8250/8250_pxa.c since it
looks to me like just an other 16x50 compatible UART. That would fix
the issue with the name conflict. You would then simply register 8250
ports from two probe drivers (drivers/tty/serial/8250/8250_pxa.c and
drivers/tty/serial/8250/8250_lp8x4x.c).

Depending on the order you register your platform devices (which you
decide in your platform code), but let's say the pxa gets registered
first and let's say it only has one port. You will then have in your
system /dev/ttyS0 for the pxa port and /dev/ttyS[1-4] for the other
UART.

I hope I was able to explain what I mean this time :)

Thanks,

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


Re: [PATCH 01/11] resolve PXA<->8250 serial device address conflict

2013-12-02 Thread Sergei Ianovich
On Mon, 2013-12-02 at 11:02 +0200, Heikki Krogerus wrote:
> On Sun, Dec 01, 2013 at 10:26:14AM +0400, Sergei Ianovich wrote:
> > PXA serial ports have "standard" UART names (ttyS[0-3]), major
> > device number (4) and first minor device number (64) by default.
> > 
> > If the system has extra 8250 serial port hardware in addition
> > to onboard PXA serial ports, default settings produce a device
> > allocation conflict.
> > 
> > The patch provides a configuration option which can move onboard
> > ports out of the way of 8250_core by assigning a different (204)
> > major number and corresponding device names (ttySA[0-3]).
> > 
> 
> 
> If drivers/tty/serial/pxa.c was converted to an other probe driver for
> the 8250, this would not be an issue.

It seems that my patch is not going to be accepted. However, there is a
device which has both PXA ports and a additional 8250 accent chip. As a
result, there is a device allocation conflict. For the device to be
usable the conflict needs to be resolved.

Do you mean that drivers/tty/serial/pxa.c needs to be rewritten to
support lp8x4x special case?

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


Re: [PATCH 01/11] resolve PXA<->8250 serial device address conflict

2013-12-02 Thread Heikki Krogerus
Hi,

On Sun, Dec 01, 2013 at 10:26:14AM +0400, Sergei Ianovich wrote:
> PXA serial ports have "standard" UART names (ttyS[0-3]), major
> device number (4) and first minor device number (64) by default.
> 
> If the system has extra 8250 serial port hardware in addition
> to onboard PXA serial ports, default settings produce a device
> allocation conflict.
> 
> The patch provides a configuration option which can move onboard
> ports out of the way of 8250_core by assigning a different (204)
> major number and corresponding device names (ttySA[0-3]).
> 
> Signed-off-by: Sergei Ianovich 
> ---
>  drivers/tty/serial/Kconfig | 19 +++
>  drivers/tty/serial/pxa.c   | 22 ++
>  2 files changed, 37 insertions(+), 4 deletions(-)
> diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c



> --- a/drivers/tty/serial/pxa.c
> +++ b/drivers/tty/serial/pxa.c
> @@ -593,6 +593,20 @@ serial_pxa_type(struct uart_port *port)
>  static struct uart_pxa_port *serial_pxa_ports[4];
>  static struct uart_driver serial_pxa_reg;
>  
> +#ifndef CONFIG_SERIAL_PXA_AS_TTYSA
> +
> +#define PXA_TTY_NAME "ttyS"
> +#define PXA_TTY_MAJORTTY_MAJOR
> +#define PXA_TTY_MINOR64
> +
> +#else
> +
> +#define PXA_TTY_NAME "ttySA"
> +#define PXA_TTY_MAJOR204
> +#define PXA_TTY_MINOR5
> +
> +#endif
> +
>  #ifdef CONFIG_SERIAL_PXA_CONSOLE
>  
>  #define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
> @@ -751,7 +765,7 @@ serial_pxa_console_setup(struct console *co, char 
> *options)
>  }
>  
>  static struct console serial_pxa_console = {
> - .name   = "ttyS",
> + .name   = PXA_TTY_NAME,
>   .write  = serial_pxa_console_write,
>   .device = uart_console_device,
>   .setup  = serial_pxa_console_setup,
> @@ -792,9 +806,9 @@ static struct uart_ops serial_pxa_pops = {
>  static struct uart_driver serial_pxa_reg = {
>   .owner  = THIS_MODULE,
>   .driver_name= "PXA serial",
> - .dev_name   = "ttyS",
> - .major  = TTY_MAJOR,
> - .minor  = 64,
> + .dev_name   = PXA_TTY_NAME,
> + .major  = PXA_TTY_MAJOR,
> + .minor  = PXA_TTY_MINOR,
>   .nr = 4,
>   .cons   = PXA_CONSOLE,
>  };

If drivers/tty/serial/pxa.c was converted to an other probe driver for
the 8250, this would not be an issue.

Br,

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


Re: [PATCH 01/11] resolve PXA-8250 serial device address conflict

2013-12-02 Thread Heikki Krogerus
Hi,

On Sun, Dec 01, 2013 at 10:26:14AM +0400, Sergei Ianovich wrote:
 PXA serial ports have standard UART names (ttyS[0-3]), major
 device number (4) and first minor device number (64) by default.
 
 If the system has extra 8250 serial port hardware in addition
 to onboard PXA serial ports, default settings produce a device
 allocation conflict.
 
 The patch provides a configuration option which can move onboard
 ports out of the way of 8250_core by assigning a different (204)
 major number and corresponding device names (ttySA[0-3]).
 
 Signed-off-by: Sergei Ianovich ynv...@gmail.com
 ---
  drivers/tty/serial/Kconfig | 19 +++
  drivers/tty/serial/pxa.c   | 22 ++
  2 files changed, 37 insertions(+), 4 deletions(-)
 diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c

snip

 --- a/drivers/tty/serial/pxa.c
 +++ b/drivers/tty/serial/pxa.c
 @@ -593,6 +593,20 @@ serial_pxa_type(struct uart_port *port)
  static struct uart_pxa_port *serial_pxa_ports[4];
  static struct uart_driver serial_pxa_reg;
  
 +#ifndef CONFIG_SERIAL_PXA_AS_TTYSA
 +
 +#define PXA_TTY_NAME ttyS
 +#define PXA_TTY_MAJORTTY_MAJOR
 +#define PXA_TTY_MINOR64
 +
 +#else
 +
 +#define PXA_TTY_NAME ttySA
 +#define PXA_TTY_MAJOR204
 +#define PXA_TTY_MINOR5
 +
 +#endif
 +
  #ifdef CONFIG_SERIAL_PXA_CONSOLE
  
  #define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
 @@ -751,7 +765,7 @@ serial_pxa_console_setup(struct console *co, char 
 *options)
  }
  
  static struct console serial_pxa_console = {
 - .name   = ttyS,
 + .name   = PXA_TTY_NAME,
   .write  = serial_pxa_console_write,
   .device = uart_console_device,
   .setup  = serial_pxa_console_setup,
 @@ -792,9 +806,9 @@ static struct uart_ops serial_pxa_pops = {
  static struct uart_driver serial_pxa_reg = {
   .owner  = THIS_MODULE,
   .driver_name= PXA serial,
 - .dev_name   = ttyS,
 - .major  = TTY_MAJOR,
 - .minor  = 64,
 + .dev_name   = PXA_TTY_NAME,
 + .major  = PXA_TTY_MAJOR,
 + .minor  = PXA_TTY_MINOR,
   .nr = 4,
   .cons   = PXA_CONSOLE,
  };

If drivers/tty/serial/pxa.c was converted to an other probe driver for
the 8250, this would not be an issue.

Br,

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


Re: [PATCH 01/11] resolve PXA-8250 serial device address conflict

2013-12-02 Thread Sergei Ianovich
On Mon, 2013-12-02 at 11:02 +0200, Heikki Krogerus wrote:
 On Sun, Dec 01, 2013 at 10:26:14AM +0400, Sergei Ianovich wrote:
  PXA serial ports have standard UART names (ttyS[0-3]), major
  device number (4) and first minor device number (64) by default.
  
  If the system has extra 8250 serial port hardware in addition
  to onboard PXA serial ports, default settings produce a device
  allocation conflict.
  
  The patch provides a configuration option which can move onboard
  ports out of the way of 8250_core by assigning a different (204)
  major number and corresponding device names (ttySA[0-3]).
  
 snip
 
 If drivers/tty/serial/pxa.c was converted to an other probe driver for
 the 8250, this would not be an issue.

It seems that my patch is not going to be accepted. However, there is a
device which has both PXA ports and a additional 8250 accent chip. As a
result, there is a device allocation conflict. For the device to be
usable the conflict needs to be resolved.

Do you mean that drivers/tty/serial/pxa.c needs to be rewritten to
support lp8x4x special case?

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


Re: [PATCH 01/11] resolve PXA-8250 serial device address conflict

2013-12-02 Thread Heikki Krogerus
Hi,

On Mon, Dec 02, 2013 at 01:23:58PM +0400, Sergei Ianovich wrote:
 On Mon, 2013-12-02 at 11:02 +0200, Heikki Krogerus wrote:
  On Sun, Dec 01, 2013 at 10:26:14AM +0400, Sergei Ianovich wrote:
   PXA serial ports have standard UART names (ttyS[0-3]), major
   device number (4) and first minor device number (64) by default.
   
   If the system has extra 8250 serial port hardware in addition
   to onboard PXA serial ports, default settings produce a device
   allocation conflict.
   
   The patch provides a configuration option which can move onboard
   ports out of the way of 8250_core by assigning a different (204)
   major number and corresponding device names (ttySA[0-3]).
   
  snip
  
  If drivers/tty/serial/pxa.c was converted to an other probe driver for
  the 8250, this would not be an issue.
 
 It seems that my patch is not going to be accepted. However, there is a
 device which has both PXA ports and a additional 8250 accent chip. As a
 result, there is a device allocation conflict. For the device to be
 usable the conflict needs to be resolved.
 
 Do you mean that drivers/tty/serial/pxa.c needs to be rewritten to
 support lp8x4x special case?

Sorry I was not clear. I was suggesting that drivers/tty/serial/pxa.c
would be converted to drivers/tty/serial/8250/8250_pxa.c since it
looks to me like just an other 16x50 compatible UART. That would fix
the issue with the name conflict. You would then simply register 8250
ports from two probe drivers (drivers/tty/serial/8250/8250_pxa.c and
drivers/tty/serial/8250/8250_lp8x4x.c).

Depending on the order you register your platform devices (which you
decide in your platform code), but let's say the pxa gets registered
first and let's say it only has one port. You will then have in your
system /dev/ttyS0 for the pxa port and /dev/ttyS[1-4] for the other
UART.

I hope I was able to explain what I mean this time :)

Thanks,

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


Re: [PATCH 01/11] resolve PXA-8250 serial device address conflict

2013-12-02 Thread Sergei Ianovich
On Mon, 2013-12-02 at 11:49 +0200, Heikki Krogerus wrote:
 On Mon, Dec 02, 2013 at 01:23:58PM +0400, Sergei Ianovich wrote:
  On Mon, 2013-12-02 at 11:02 +0200, Heikki Krogerus wrote:
   On Sun, Dec 01, 2013 at 10:26:14AM +0400, Sergei Ianovich wrote:
PXA serial ports have standard UART names (ttyS[0-3]), major
device number (4) and first minor device number (64) by default.

If the system has extra 8250 serial port hardware in addition
to onboard PXA serial ports, default settings produce a device
allocation conflict.

The patch provides a configuration option which can move onboard
ports out of the way of 8250_core by assigning a different (204)
major number and corresponding device names (ttySA[0-3]).

   snip
   
   If drivers/tty/serial/pxa.c was converted to an other probe driver for
   the 8250, this would not be an issue.
  
  It seems that my patch is not going to be accepted. However, there is a
  device which has both PXA ports and a additional 8250 accent chip. As a
  result, there is a device allocation conflict. For the device to be
  usable the conflict needs to be resolved.
  
  Do you mean that drivers/tty/serial/pxa.c needs to be rewritten to
  support lp8x4x special case?
 
 Sorry I was not clear. I was suggesting that drivers/tty/serial/pxa.c
 would be converted to drivers/tty/serial/8250/8250_pxa.c since it
 looks to me like just an other 16x50 compatible UART. That would fix
 the issue with the name conflict. You would then simply register 8250
 ports from two probe drivers (drivers/tty/serial/8250/8250_pxa.c and
 drivers/tty/serial/8250/8250_lp8x4x.c).
 
 Depending on the order you register your platform devices (which you
 decide in your platform code), but let's say the pxa gets registered
 first and let's say it only has one port. You will then have in your
 system /dev/ttyS0 for the pxa port and /dev/ttyS[1-4] for the other
 UART.
 
 I hope I was able to explain what I mean this time :)

Sorry, I wasn't clear as well. I got it right the first time. You mean
pxa.c needs to merged into 8250. This will solve the conflict in
question, and do it the right way. However, this will be a *much* bigger
patch, and it will affect everyone on pxa.

Who makes the decision which way to go?

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


Re: [PATCH 01/11] resolve PXA-8250 serial device address conflict

2013-12-02 Thread Heikki Krogerus
Hi,

On Mon, Dec 02, 2013 at 02:26:45PM +0400, Sergei Ianovich wrote:
 On Mon, 2013-12-02 at 11:49 +0200, Heikki Krogerus wrote:
  On Mon, Dec 02, 2013 at 01:23:58PM +0400, Sergei Ianovich wrote:
   On Mon, 2013-12-02 at 11:02 +0200, Heikki Krogerus wrote:

If drivers/tty/serial/pxa.c was converted to an other probe driver for
the 8250, this would not be an issue.
   
   It seems that my patch is not going to be accepted. However, there is a
   device which has both PXA ports and a additional 8250 accent chip. As a
   result, there is a device allocation conflict. For the device to be
   usable the conflict needs to be resolved.
   
   Do you mean that drivers/tty/serial/pxa.c needs to be rewritten to
   support lp8x4x special case?
  
  Sorry I was not clear. I was suggesting that drivers/tty/serial/pxa.c
  would be converted to drivers/tty/serial/8250/8250_pxa.c since it
  looks to me like just an other 16x50 compatible UART. That would fix
  the issue with the name conflict. You would then simply register 8250
  ports from two probe drivers (drivers/tty/serial/8250/8250_pxa.c and
  drivers/tty/serial/8250/8250_lp8x4x.c).
  
  Depending on the order you register your platform devices (which you
  decide in your platform code), but let's say the pxa gets registered
  first and let's say it only has one port. You will then have in your
  system /dev/ttyS0 for the pxa port and /dev/ttyS[1-4] for the other
  UART.
  
  I hope I was able to explain what I mean this time :)
 
 Sorry, I wasn't clear as well. I got it right the first time. You mean
 pxa.c needs to merged into 8250. This will solve the conflict in
 question, and do it the right way. However, this will be a *much* bigger
 patch, and it will affect everyone on pxa.
 
 Who makes the decision which way to go?

Greg and Russel make this decision. By having the pxa driver simply
register 8250 ports would probable reduce the code. Thats about the
biggest benefit from it.

It would still be something nice to have IMO. Ideally all the
8250/16x50 UARTs should register the ports with 8250_core.c, and not
create complete uart driver on their own.

Br,

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


[PATCH 01/11] resolve PXA<->8250 serial device address conflict

2013-11-30 Thread Sergei Ianovich
PXA serial ports have "standard" UART names (ttyS[0-3]), major
device number (4) and first minor device number (64) by default.

If the system has extra 8250 serial port hardware in addition
to onboard PXA serial ports, default settings produce a device
allocation conflict.

The patch provides a configuration option which can move onboard
ports out of the way of 8250_core by assigning a different (204)
major number and corresponding device names (ttySA[0-3]).

Signed-off-by: Sergei Ianovich 
---
 drivers/tty/serial/Kconfig | 19 +++
 drivers/tty/serial/pxa.c   | 22 ++
 2 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index a3817ab..328b716 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -419,6 +419,25 @@ config SERIAL_PXA_CONSOLE
  your boot loader (lilo or loadlin) about how to pass options to the
  kernel at boot time.)
 
+config SERIAL_PXA_AS_TTYSA
+   bool "PXA serial ports with SA-1100 name and major number"
+   depends on SERIAL_PXA
+   default N
+   help
+ PXA serial ports have "standard" UART names (ttyS[0-3]), major
+ device number (4) and first minor device number (64) by default.
+
+ If the system has extra 8250 serial port hardware in addition
+ to onboard PXA serial ports, default settings produce a device
+ allocation conflict.
+
+ Selecting this option will move onboard ports out of the way of
+ 8250_core by assigning a different (204) major number and
+ corresponding device names (ttySA[0-3]).
+
+ Say Y here, if you need to support extra 8250 serial port hardware
+ on a PXA system.
+
 config SERIAL_SA1100
bool "SA1100 serial port support"
depends on ARCH_SA1100
diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index f9f20f3..2b5a8ad 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
@@ -593,6 +593,20 @@ serial_pxa_type(struct uart_port *port)
 static struct uart_pxa_port *serial_pxa_ports[4];
 static struct uart_driver serial_pxa_reg;
 
+#ifndef CONFIG_SERIAL_PXA_AS_TTYSA
+
+#define PXA_TTY_NAME   "ttyS"
+#define PXA_TTY_MAJOR  TTY_MAJOR
+#define PXA_TTY_MINOR  64
+
+#else
+
+#define PXA_TTY_NAME   "ttySA"
+#define PXA_TTY_MAJOR  204
+#define PXA_TTY_MINOR  5
+
+#endif
+
 #ifdef CONFIG_SERIAL_PXA_CONSOLE
 
 #define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
@@ -751,7 +765,7 @@ serial_pxa_console_setup(struct console *co, char *options)
 }
 
 static struct console serial_pxa_console = {
-   .name   = "ttyS",
+   .name   = PXA_TTY_NAME,
.write  = serial_pxa_console_write,
.device = uart_console_device,
.setup  = serial_pxa_console_setup,
@@ -792,9 +806,9 @@ static struct uart_ops serial_pxa_pops = {
 static struct uart_driver serial_pxa_reg = {
.owner  = THIS_MODULE,
.driver_name= "PXA serial",
-   .dev_name   = "ttyS",
-   .major  = TTY_MAJOR,
-   .minor  = 64,
+   .dev_name   = PXA_TTY_NAME,
+   .major  = PXA_TTY_MAJOR,
+   .minor  = PXA_TTY_MINOR,
.nr = 4,
.cons   = PXA_CONSOLE,
 };
-- 
1.8.4.2

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


[PATCH 01/11] resolve PXA-8250 serial device address conflict

2013-11-30 Thread Sergei Ianovich
PXA serial ports have standard UART names (ttyS[0-3]), major
device number (4) and first minor device number (64) by default.

If the system has extra 8250 serial port hardware in addition
to onboard PXA serial ports, default settings produce a device
allocation conflict.

The patch provides a configuration option which can move onboard
ports out of the way of 8250_core by assigning a different (204)
major number and corresponding device names (ttySA[0-3]).

Signed-off-by: Sergei Ianovich ynv...@gmail.com
---
 drivers/tty/serial/Kconfig | 19 +++
 drivers/tty/serial/pxa.c   | 22 ++
 2 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index a3817ab..328b716 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -419,6 +419,25 @@ config SERIAL_PXA_CONSOLE
  your boot loader (lilo or loadlin) about how to pass options to the
  kernel at boot time.)
 
+config SERIAL_PXA_AS_TTYSA
+   bool PXA serial ports with SA-1100 name and major number
+   depends on SERIAL_PXA
+   default N
+   help
+ PXA serial ports have standard UART names (ttyS[0-3]), major
+ device number (4) and first minor device number (64) by default.
+
+ If the system has extra 8250 serial port hardware in addition
+ to onboard PXA serial ports, default settings produce a device
+ allocation conflict.
+
+ Selecting this option will move onboard ports out of the way of
+ 8250_core by assigning a different (204) major number and
+ corresponding device names (ttySA[0-3]).
+
+ Say Y here, if you need to support extra 8250 serial port hardware
+ on a PXA system.
+
 config SERIAL_SA1100
bool SA1100 serial port support
depends on ARCH_SA1100
diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index f9f20f3..2b5a8ad 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
@@ -593,6 +593,20 @@ serial_pxa_type(struct uart_port *port)
 static struct uart_pxa_port *serial_pxa_ports[4];
 static struct uart_driver serial_pxa_reg;
 
+#ifndef CONFIG_SERIAL_PXA_AS_TTYSA
+
+#define PXA_TTY_NAME   ttyS
+#define PXA_TTY_MAJOR  TTY_MAJOR
+#define PXA_TTY_MINOR  64
+
+#else
+
+#define PXA_TTY_NAME   ttySA
+#define PXA_TTY_MAJOR  204
+#define PXA_TTY_MINOR  5
+
+#endif
+
 #ifdef CONFIG_SERIAL_PXA_CONSOLE
 
 #define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
@@ -751,7 +765,7 @@ serial_pxa_console_setup(struct console *co, char *options)
 }
 
 static struct console serial_pxa_console = {
-   .name   = ttyS,
+   .name   = PXA_TTY_NAME,
.write  = serial_pxa_console_write,
.device = uart_console_device,
.setup  = serial_pxa_console_setup,
@@ -792,9 +806,9 @@ static struct uart_ops serial_pxa_pops = {
 static struct uart_driver serial_pxa_reg = {
.owner  = THIS_MODULE,
.driver_name= PXA serial,
-   .dev_name   = ttyS,
-   .major  = TTY_MAJOR,
-   .minor  = 64,
+   .dev_name   = PXA_TTY_NAME,
+   .major  = PXA_TTY_MAJOR,
+   .minor  = PXA_TTY_MINOR,
.nr = 4,
.cons   = PXA_CONSOLE,
 };
-- 
1.8.4.2

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