gmane.linux.serial

[PATCH RESEND v2 1/2] serial/mpc52xx_uart: prepare for adding MPC5125 PSC UART support

Anatolij Gustschin — 2013-05-24T18:24:58

From: Matteo Facchinetti <matteo.facchinetti< at >sirius-es.it>

MPC5125 PSC controller has different register layout than MPC5121.
To support MPC5125 PSC in this driver we have to provide further
psc_ops functions for SoC specific register accesses.

Add new register access functions to the psc_ops structure and
provide MPC52xx and MPC512x specific implementation for them.
Then replace remaining direct register accesses in the driver by
appropriate psc_ops function calls. The subsequent patch can now
add MPC5125 specific set of psc_ops functions.

Signed-off-by: Vladimir Ermakov <vooon341< at >gmail.com>
Signed-off-by: Matteo Facchinetti <matteo.facchinetti< at >sirius-es.it>
Signed-off-by: Anatolij Gustschin <agust< at >denx.de>
---

Changes in v2:
 - split into two patches to simplify review
 - minor coding style changes
 - revise commit log

 drivers/tty/serial/mpc52xx_uart.c |  161 +++++++++++++++++++++++++++----------
 1 file changed, 119 insertions(+), 42 deletions(-)

diff --git a/drivers/tty/serial/mpc52xx_uart.c b/dri

[PATCH RESEND v2 2/2] serial/mpc52xx_uart: add MPC5125 PSC support

Anatolij Gustschin — 2013-05-24T18:24:59

From: Matteo Facchinetti <matteo.facchinetti< at >sirius-es.it>

Add MPC5125 PSC register layout structure, MPC5125 specific
psc_ops function set and the compatible string.

Signed-off-by: Vladimir Ermakov <vooon341< at >gmail.com>
Signed-off-by: Matteo Facchinetti <matteo.facchinetti< at >sirius-es.it>
Signed-off-by: Anatolij Gustschin <agust< at >denx.de>
---
Changes in v2:
 - split into two patches to simplify review
 - minor coding style changes 
 - revise commit log

 arch/powerpc/include/asm/mpc52xx_psc.h |   49 +++++++
 drivers/tty/serial/mpc52xx_uart.c      |  241 ++++++++++++++++++++++++++++++++
 2 files changed, 290 insertions(+)

diff --git a/arch/powerpc/include/asm/mpc52xx_psc.h b/arch/powerpc/include/asm/mpc52xx_psc.h
index 2966df6..d0ece25 100644
--- a/arch/powerpc/include/asm/mpc52xx_psc.h
+++ b/arch/powerpc/include/asm/mpc52xx_psc.h
< at >< at > -299,4 +299,53 < at >< at > struct mpc512x_psc_fifo {
 #define rxdata_32 rxdata.rxdata_32
 };
 
+struct mpc5125_psc {
+u8mr1;/* PSC + 0x00 */
+u8reserved0[3];
+u8mr2;/* PSC

Re: [PATCH v2 1/2] serial/mpc52xx_uart: prepare for adding MPC5125 PSC UART support

Greg Kroah-Hartman — 2013-05-24T17:57:11

Sorry, I somehow lost this, so I can't see the original patch at all.
Care to resend it?

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/2] serial/mpc52xx_uart: prepare for adding MPC5125 PSC UART support

Anatolij Gustschin — 2013-05-24T17:49:12

On Wed, 17 Apr 2013 23:21:41 +0200
Anatolij Gustschin <agust< at >denx.de> wrote:


ping ...

Thanks,

Anatolij
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: linux-3.9.3 - hit limit of 255 usb->serial devices

Greg KH — 2013-05-24T17:23:54

Not really, linux-usb< at > is the proper one, I've included that on the cc:


Yes, that's the limit of usb-serial devices in the system at the moment.
In 10+ years, no one has complained yet, so it's been a good number :)


Nice job.


You can send a patch making the number dynamic, that would be great to
have.


Yes, there might be some limits in the tty layer as well for only 256
tty devices, but I haven't looked there in a long time, perhaps that is
now no longer the case.


I'm just glad to see we can support 91 different devices on a single
root hub, that's good to see, as I don't think anyone has tested that in
a very long time :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 3/8] mfd:syscon: Introduce claim/read/write/release APIs

Srinivas KANDAGATLA — 2013-05-24T16:06:38

Thankyou Arnd for extending this discussion.

Yes, I agree with you. I think just passing the offset information from
DT would enough in cases like Ethernet or USB where the sysconf
registers tend to be mostly standard. And the generic higher level
function should be able to do the rest.


We have decided to go with using higher level functions as you
suggested, hopefully based on regmap with some helper functions on top
of it.

System configuration registers in the past used to very much shared
across IPs, However with the new chips they seems be mostly dedicated
registers for specific IP configurations.
As we have no plans to support very old chips, So I think I can move
this out bit level information from device tree and add a higher level
functions to be accessed by the drivers.

As an example the below sysconf register for a STi7105 chip(Very old
SOC) looks like:
SYSTEM_CONFIG7 Comms/Ethernet config control register

[31:28] RESERVED
[27] ENMII:
1: MII mode 0: Reverse MII mode
[26:25] PHY_INTF_SELECT:

linux-3.9.3 - hit limit of 255 usb->serial devices

Tobias Winter — 2013-05-24T13:56:37

Hi there,

since my propblem is with usb to serial adapters I was unsure if this is
the right place. If not, please let me know.

After equipping a server with a lot of ftdi singleport usb2serial
devices, I ran into a serial device limit that is included in
include/linux/usb/serial.h .

The limit of devices seems to be 255, resulting in ttyUSB254 to be the
last supported device.

The codesnippet in question is:

#define SERIAL_TTY_MINORS 254 /* loads of devices :) */
#define SERIAL_TTY_NO_MINOR 255 /* No minor was assigned */

I successfully modified it to support 256 devices and fail gracefully
afterward:

#define SERIAL_TTY_MINORS 256 /* loads of devices :) */
#define SERIAL_TTY_NO_MINOR 255 /* No minor was assigned */

That results in the following dmesg output:

[..]
usb 1-8.4.4.4.3: Detected FT232BM
usb 1-8.4.4.4.3: Number of endpoints 2
usb 1-8.4.4.4.3: Endpoint 1 MaxPacketSize 64
usb 1-8.4.4.4.3: Endpoint 2 MaxPacketSize 64
usb 1-8.4.4.4.3: Setting MaxPacketSize 64
usb 1-8.4.4.4.3: FTDI USB Serial Dev

[PATCH V3 -firmware] rp2: Initial commit of Comtrol RocketPort 2 microcode

Kevin Cernekee — 2013-05-24T07:53:10

This is used by drivers/tty/serial/rp2.c.

Signed-off-by: Kevin Cernekee <cernekee< at >gmail.com>
Signed-off-by: Grant Edwards <grant.edwards< at >comtrol.com>
Signed-off-by: Nick Thompson <nick.thompson< at >comtrol.com>
---
 WHENCE |   18 ++++++++++++++++++
 rp2.fw |  Bin 0 -> 63 bytes
 2 files changed, 18 insertions(+)
 create mode 100644 rp2.fw


V3: Update license text after clearing the changes with the vendor

git pull: git://github.com/cernekee/linux-firmware rp2


diff --git a/WHENCE b/WHENCE
index c08336a..b7c6169 100644
--- a/WHENCE
+++ b/WHENCE
< at >< at > -2110,3 +2110,21 < at >< at > File: intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq
 Licence: Redistributable. See LICENCE.ibt_firmware for details
 
 --------------------------------------------------------------------------
+
+Driver: rp2 -- Comtrol RocketPort 2 serial driver
+
+File: rp2.fw
+
+Licence:
+Copyright (C) 2013 Comtrol Corporation
+
+Comtrol grants permission to use and redistribute these firmware
+files for use with Comtrol devices, but not as part of the Linux
+kernel

[PATCH v2] driver: serial: omap: fix compilation error

Bin Liu — 2013-05-23T17:51:17

Fix a compilation error when CONFIG_PM_SLEEP is unset.

Signed-off-by: Bin Liu <b-liu< at >ti.com>
Ack-Tested-by: Sourav Poddar<sourav.poddar< at >ti.com>
---
 drivers/tty/serial/omap-serial.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 352fcef..a1d694a 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
< at >< at > -1327,7 +1327,7 < at >< at > static int serial_omap_resume(struct device *dev)
 }
 #else
 #define serial_omap_prepare NULL
-#define serial_omap_prepare NULL
+#define serial_omap_complete NULL
 #endif /* CONFIG_PM_SLEEP */
 
 static void omap_serial_fill_features_erratas(struct uart_omap_port *up)

[PATCH] driver: serial: omap: fix compilation error

Bin Liu — 2013-05-23T17:44:14

Fix a compilation error when CONFIG_PM_SLEEP is unset.

Signed-off-by: Bin Liu <b-liu< at >ti.com>
---
 drivers/tty/serial/omap-serial.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 352fcef..a1d694a 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
< at >< at > -1327,7 +1327,7 < at >< at > static int serial_omap_resume(struct device *dev)
 }
 #else
 #define serial_omap_prepare NULL
-#define serial_omap_prepare NULL
+#define serial_omap_complete NULL
 #endif /* CONFIG_PM_SLEEP */
 
 static void omap_serial_fill_features_erratas(struct uart_omap_port *up)

RE: [RFC 1/8] serial:st-asc: Add ST ASC driver.

Stephen GALLIMORE — 2013-05-23T16:26:09

On Wednesday 22 May 2013, Arnd Bergmann wrote:

Thanks for looking into this and digging around in the history. At least I didn't
miss something really obvious.


Yes, I had been made aware of the ePAPR definition by Srini after I sent the post.
In fact I had exactly the same question in my head about the other settings as
well.  

OK.

Thanks again for your time.

Regards,
-stephen
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[GIT PATCH] TTY/Serial fixes for 3.10-rc3

Greg KH — 2013-05-23T16:17:03

The following changes since commit f722406faae2d073cc1d01063d1123c35425939e:

  Linux 3.10-rc1 (2013-05-11 17:14:08 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-3.10-rc2

for you to fetch changes up to e037f95ffb5355ffe295e1d106d02fefd284d882:

  tty: mxser: Fix build warning introduced by dfc7b837c7f9 (Re: linux-next: build warning after merge of the tty.current tree) (2013-05-22 10:26:02 -0700)

----------------------------------------------------------------
tty/serial fixes for 3.10-rc2

Here are some tty / serial driver fixes for 3.10-rc2.

Nothing huge, although the rocket driver fix looks large, it's just
moving the code around to fix the reported build issues in it.  Other
than that, this has the fix for the of-reported lockdep warning from the
vt layer, as well as some other needed bugfixes.

All of these have been in linux-next for a while.

Signed-off-by: Greg Kroah-Hartman <gregkh< at >linuxfoundation.org>

------------------

Re: [Resend/PATCHv5 0/3] Omap serial cleanup

Kevin Hilman — 2013-05-23T14:14:41

Hi Sourav,

Sourav Poddar <sourav.poddar< at >ti.com> writes:


Greg has queued the serial core changes for v3.11, and I've queued this
series for the OMAP specific changes for v3.11[1].

Thanks again for your persistence with this series.

Kevin

[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.11/uart/no_console_suspend

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/4] ARM: davinci: uart: move to dev_id based clk_get

Manjunathappa, Prakash — 2013-05-23T13:25:57

Hi Sekhar,

Thanks for reviewing.

On Fri, Apr 26, 2013 at 12:31:53, Nori, Sekhar wrote:

True, will change them.


Ok. I will remove them.


Correct, I will change it.


Ok I will cleanup this and submit v2.

Thanks,
Prakash

[PATCH] serial: use platform_{get,set}_drvdata()

Jingoo Han — 2013-05-23T10:39:36

Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.

Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.

Signed-off-by: Jingoo Han <jg1.han< at >samsung.com>
---
 drivers/tty/serial/cpm_uart/cpm_uart_core.c |    4 ++--
 drivers/tty/serial/mpc52xx_uart.c           |    9 ++++-----
 drivers/tty/serial/of_serial.c              |    4 ++--
 drivers/tty/serial/sc26xx.c                 |    5 ++---
 drivers/tty/serial/sunhv.c                  |    6 ++----
 drivers/tty/serial/sunsab.c                 |    6 ++----
 drivers/tty/serial/sunsu.c                  |    8 +++-----
 drivers/tty/serial/sunzilog.c               |    6 ++----
 drivers/tty/serial/ucc_uart.c               |    5 ++---
 drivers/tty/serial/xilinx_uartps.c          |    6 ++----
 10 files changed, 23 insertions(+), 36

Re: [PATCH v3] tty: serial: add Freescale lpuart driver support

Shawn Guo — 2013-05-23T02:51:01

You can never tell in 5 or 10 years.  Also no major version doesn't
necessarily mean no minor updates or revise.


Yeah, if IP designers name it lpuart2.0, it surely works.  But from my
experience on IMX, hardware guys are not always properly updating IP
name.  Then the version 2.0 becomes a versioning given by software
people which is improper to be used in compatible string.


Not only select the driver but also the programing model implemented in
the driver.  Take a look at drivers/mmc/host/sdhci-esdhc-imx.c or
drivers/net/ethernet/freescale/fec_main.c, multiple compatible strings
select the same driver but the different programing model implemented in
the driver.


Seriously?  The "version" equally means the compatibility here.  How can
a compatible string be not used to describe "version" - compatibility?


If the IP gets a revise, the driver should be updated to support a new
programing model with a new compatible string.


Think about it from "compatibility" point of view.  It does not cause
confusio

[PATCH] serial/JSM: change maintainer to myself

Thadeu Lima de Souza Cascardo — 2013-05-22T18:15:24

Lucas has moved on. Since his email address does not work any more, it's
not expected to get his ack.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo< at >linux.vnet.ibm.com>
---
 MAINTAINERS |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 829c032..e713e57 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
< at >< at > -4559,7 +4559,7 < at >< at > F:fs/jbd2/
 F:include/linux/jbd2.h
 
 JSM Neo PCI based serial card
-M:Lucas Tavares <lucaskt< at >linux.vnet.ibm.com>
+M:Thadeu Lima de Souza Cascardo <cascardo< at >linux.vnet.ibm.com>
 L:linux-serial< at >vger.kernel.org
 S:Maintained
 F:drivers/tty/serial/jsm/

Re: [RFC 1/8] serial:st-asc: Add ST ASC driver.

Arnd Bergmann — 2013-05-22T15:13:37

What may have happened here is that custom_divisor was used in a different
way when I added that code than it is today, and the change was not propagated
into the of_serial driver. However, going back to 2.6.20 shows no different
code than what we have today in this regard. It may simply have been a mistake
on my side.


I looked it up in the original serial port binding at
http://www.openfirmware.org/1275/bindings/devices/html/serial.html, which does
not specify the property, and in ePAPR, which does have it in the section about
"serial class devices":

18 6.2.1.2 current-speed
19 Property: current-speed
20 Value type: <u32>
21 Description:
22 Specifies the current speed of a serial device in bits per second. A boot program should set
23 this property if it has initialized the serial device.
24 Example:
25 current - speed = <115200>; # 115200 baud

The reason you want this is so that the driver can initialize the hardware from
scratch more easily and get back to the same settings. Why they only specified
t

[PATCH 1/1] serial: vt8500: Remove redundant use of of_match_ptr macro

Sachin Kamat — 2013-05-22T11:36:29

'wmt_dt_ids' is always compiled in. Hence of_match_ptr is not
necessary.

Signed-off-by: Sachin Kamat <sachin.kamat< at >linaro.org>
---
 drivers/tty/serial/vt8500_serial.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/vt8500_serial.c b/drivers/tty/serial/vt8500_serial.c
index 1a8bc22..48af43d 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
< at >< at > -648,7 +648,7 < at >< at > static struct platform_driver vt8500_platform_driver = {
 .driver = {
 .name = "vt8500_serial",
 .owner = THIS_MODULE,
-.of_match_table = of_match_ptr(wmt_dt_ids),
+.of_match_table = wmt_dt_ids,
 },
 };

RE: [PATCH v3] tty: serial: add Freescale lpuart driver support

Jin Zhengxiong-R64188 — 2013-05-22T08:59:20

[Jason Jin-R64188] For the lpuart itself, I do not think it will have different version IP. The general name is sufficient and soc related name can introduce the minor difference. If the there are update version, we can name it lpuart2.0 or something like that.

For the compatible property itself, the ePAPR described it as:
---- 
The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, from most specific to most general. 
----
So for the IPs especially for the peripheral IPs, the compatible just used to select the driver for the device. It should not used to describe the version information. If the version changed and the driver cannot be used for the device then another compatible strings should be used.

As I said, Another reason for the general strings used is the across platform i

Re: [PATCH v3] tty: serial: add Freescale lpuart driver support

Shawn Guo — 2013-05-22T07:23:05

As I already said, a generic compatible string does not specify
anything about compatibility/version, and hence it's not a good
compatible for IP block which is possibly to be integrated on multiple
SoCs with slight differences.

For example, if there is a new SoC mvf900 integrating the IP with
everything compatible to the version used on mvf600,

  compatible = <fsl,mvf900-uart>, <fsl,mvf600-uart>;
  compatible = <fsl,mvf900-uart>, <fsl,lpuart>;

which one do you think is better to tell the compatibility/version?

Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html