<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.linux.serial">
    <title>gmane.linux.serial</title>
    <link>http://permalink.gmane.org/gmane.linux.serial</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11481"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11480"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11479"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11478"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11477"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11475"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11474"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11473"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11472"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11471"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11470"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11469"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11468"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11466"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11465"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11464"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11463"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11462"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11461"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.serial/11460"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11481">
    <title>Re: [Resend/PATCHv5 0/3] Omap serial cleanup</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11481</link>
    <description>&lt;pre&gt;Hi Sourav,

Sourav Poddar &amp;lt;sourav.poddar&amp;lt; at &amp;gt;ti.com&amp;gt; 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&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Kevin Hilman</dc:creator>
    <dc:date>2013-05-23T14:14:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11480">
    <title>RE: [PATCH 1/4] ARM: davinci: uart: move to dev_id based clk_get</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11480</link>
    <description>&lt;pre&gt;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
&lt;/pre&gt;</description>
    <dc:creator>Manjunathappa, Prakash</dc:creator>
    <dc:date>2013-05-23T13:25:57</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11479">
    <title>[PATCH] serial: use platform_{get,set}_drvdata()</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11479</link>
    <description>&lt;pre&gt;Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &amp;amp;pdev-&amp;gt;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 &amp;lt;jg1.han&amp;lt; at &amp;gt;samsung.com&amp;gt;
---
 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&lt;/pre&gt;</description>
    <dc:creator>Jingoo Han</dc:creator>
    <dc:date>2013-05-23T10:39:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11478">
    <title>Re: [PATCH v3] tty: serial: add Freescale lpuart driver support</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11478</link>
    <description>&lt;pre&gt;
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&lt;/pre&gt;</description>
    <dc:creator>Shawn Guo</dc:creator>
    <dc:date>2013-05-23T02:51:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11477">
    <title>[PATCH] serial/JSM: change maintainer to myself</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11477</link>
    <description>&lt;pre&gt;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 &amp;lt;cascardo&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;
---
 MAINTAINERS |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 829c032..e713e57 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -4559,7 +4559,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; F:fs/jbd2/
 F:include/linux/jbd2.h
 
 JSM Neo PCI based serial card
-M:Lucas Tavares &amp;lt;lucaskt&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;
+M:Thadeu Lima de Souza Cascardo &amp;lt;cascardo&amp;lt; at &amp;gt;linux.vnet.ibm.com&amp;gt;
 L:linux-serial&amp;lt; at &amp;gt;vger.kernel.org
 S:Maintained
 F:drivers/tty/serial/jsm/
&lt;/pre&gt;</description>
    <dc:creator>Thadeu Lima de Souza Cascardo</dc:creator>
    <dc:date>2013-05-22T18:15:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11475">
    <title>Re: [RFC 1/8] serial:st-asc: Add ST ASC driver.</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11475</link>
    <description>&lt;pre&gt;
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: &amp;lt;u32&amp;gt;
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 = &amp;lt;115200&amp;gt;; # 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&lt;/pre&gt;</description>
    <dc:creator>Arnd Bergmann</dc:creator>
    <dc:date>2013-05-22T15:13:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11474">
    <title>[PATCH 1/1] serial: vt8500: Remove redundant use of of_match_ptr macro</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11474</link>
    <description>&lt;pre&gt;'wmt_dt_ids' is always compiled in. Hence of_match_ptr is not
necessary.

Signed-off-by: Sachin Kamat &amp;lt;sachin.kamat&amp;lt; at &amp;gt;linaro.org&amp;gt;
---
 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
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -648,7 +648,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; 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,
 },
 };
 
&lt;/pre&gt;</description>
    <dc:creator>Sachin Kamat</dc:creator>
    <dc:date>2013-05-22T11:36:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11473">
    <title>RE: [PATCH v3] tty: serial: add Freescale lpuart driver support</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11473</link>
    <description>&lt;pre&gt;[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&lt;/pre&gt;</description>
    <dc:creator>Jin Zhengxiong-R64188</dc:creator>
    <dc:date>2013-05-22T08:59:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11472">
    <title>Re: [PATCH v3] tty: serial: add Freescale lpuart driver support</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11472</link>
    <description>&lt;pre&gt;
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 = &amp;lt;fsl,mvf900-uart&amp;gt;, &amp;lt;fsl,mvf600-uart&amp;gt;;
  compatible = &amp;lt;fsl,mvf900-uart&amp;gt;, &amp;lt;fsl,lpuart&amp;gt;;

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&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Shawn Guo</dc:creator>
    <dc:date>2013-05-22T07:23:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11471">
    <title>[PATCH] tty: mxser: Fix build warning introduced by dfc7b837c7f9 (Re: linux-next: build warning after merge of the tty.current tree)</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11471</link>
    <description>&lt;pre&gt;From: Matwey V. Kornilov &amp;lt;matwey&amp;lt; at &amp;gt;sai.msu.ru&amp;gt;

Fix build warning at mxser.c introduced by dfc7b837c7f9

Signed-off-by: Matwey V. Kornilov &amp;lt;matwey&amp;lt; at &amp;gt;sai.msu.ru&amp;gt;
---

diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index f97b196..4c4a236 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1674,15 +1674,15 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int mxser_ioctl(struct tty_struct *tty,
  return mxser_ioctl_special(cmd, argp);

  if (cmd == MOXA_SET_OP_MODE || cmd == MOXA_GET_OP_MODE) {
-if (info-&amp;gt;board-&amp;gt;chip_flag != MOXA_MUST_MU860_HWID)
-return -EFAULT;
-
  int p;
  unsigned long opmode;
  static unsigned char ModeMask[] = { 0xfc, 0xf3, 0xcf, 0x3f };
  int shiftbit;
  unsigned char val, mask;

+if (info-&amp;gt;board-&amp;gt;chip_flag != MOXA_MUST_MU860_HWID)
+return -EFAULT;
+
  p = tty-&amp;gt;index % 4;
  if (cmd == MOXA_SET_OP_MODE) {
  if (get_user(opmode, (int __user *) argp))

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More m&lt;/pre&gt;</description>
    <dc:creator>Matwey V. Kornilov</dc:creator>
    <dc:date>2013-05-22T07:13:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11470">
    <title>RE: [PATCH v3] tty: serial: add Freescale lpuart driver support</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11470</link>
    <description>&lt;pre&gt;
It's better to use the generic name lpuart in the compatible string as it provides
much closer association with the lpuart driver which can be generic across SoCs.

As Jason pointed out, minor differences in IP implementation across SoCs can be
handled by passing the soc related compatible string.

Regards,
Bhupesh


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

&lt;/pre&gt;</description>
    <dc:creator>Sharma Bhupesh-B45370</dc:creator>
    <dc:date>2013-05-22T06:54:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11469">
    <title>RE: [PATCH v3] tty: serial: add Freescale lpuart driver support</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11469</link>
    <description>&lt;pre&gt;[Jason Jin-R64188] Reuse the same LPUART on LS-1 with the compatible strings 'fsl,mvf600-lpuart' is technically OK, But it will fuss the route map of the product Line. The general name can show that the IP is shared between several product lines, and the history for which SOC firstly used the IP is not very important. With general compatible name, We can setup the general dts for the shared IPs.

That's also the case for the IPs used on Power platform, Take the IFC for example, this IP implemented on Power platform will also be reused LS-1, The compatible string is set as  "fsl,ifc", "simple-bus" but not the soc name on which the IP first used.

 Another example, though a little different, the nor flash driver, which is used for many platform, the compatible "cfi-flash" will be more reasonable than the soc/board name.

With the general name for the compatible string in the driver, if there is minor difference for the different implementation of the same IP, we can add the soc related compatible string to the&lt;/pre&gt;</description>
    <dc:creator>Jin Zhengxiong-R64188</dc:creator>
    <dc:date>2013-05-22T06:40:21</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11468">
    <title>RE: [PATCH] ARM: bcm2835: override the HW UART periphid</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11468</link>
    <description>&lt;pre&gt;Stephen Warren &amp;lt;swarren&amp;lt; at &amp;gt;wwwdotorg.org&amp;gt; :
presumably

Thank you, Stephen.


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

&lt;/pre&gt;</description>
    <dc:creator>Jongsung Kim</dc:creator>
    <dc:date>2013-05-22T01:52:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11466">
    <title>Re: [PATCH] ARM: bcm2835: override the HW UART periphid</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11466</link>
    <description>&lt;pre&gt;
I know this will work, because I tried out the same thing last week.

However, I'm not convinced that it's the correct approach. What other
changes exist between r1p4 and r1p5; can you check in the TRM? Faking
the periphid would prevent the driver from taking account of any other
changes. Should we instead add a DT property solely to override the FIFO
size, and then set that for bcm2835? I guess if there really aren't any
other SW-visible changes in r1p5, this approach is fine.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Stephen Warren</dc:creator>
    <dc:date>2013-05-21T16:34:17</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11465">
    <title>[PATCH] tty: mxser: fix usage of opmode_ioaddr</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11465</link>
    <description>&lt;pre&gt;From: Matwey V. Kornilov &amp;lt;matwey&amp;lt; at &amp;gt;sai.msu.ru&amp;gt;

mxser_port-&amp;gt;opmode_ioaddr is initialized only for MOXA_MUST_MU860_HWID 
chips, but no precautions have been undertaken to prevent reading and 
writing to undefined port number.

Signed-off-by: Matwey V. Kornilov &amp;lt;matwey&amp;lt; at &amp;gt;sai.msu.ru&amp;gt;
---

diff --git a/drivers/tty/mxser.c b/drivers/tty/mxser.c
index 71d6eb2..f97b196 100644
--- a/drivers/tty/mxser.c
+++ b/drivers/tty/mxser.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1618,8 +1618,12 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int mxser_ioctl_special(unsigned int cmd, void __user *argp)
  if (ip-&amp;gt;type == PORT_16550A)
  me-&amp;gt;fifo[p] = 1;

-opmode = inb(ip-&amp;gt;opmode_ioaddr)&amp;gt;&amp;gt;((p % 4) * 2);
-opmode &amp;amp;= OP_MODE_MASK;
+if (ip-&amp;gt;board-&amp;gt;chip_flag == MOXA_MUST_MU860_HWID) {
+opmode = inb(ip-&amp;gt;opmode_ioaddr)&amp;gt;&amp;gt;((p % 4) * 2);
+opmode &amp;amp;= OP_MODE_MASK;
+} else {
+opmode = RS232_MODE;
+}
  me-&amp;gt;iftype[p] = opmode;
  mutex_unlock(&amp;amp;port-&amp;gt;mutex);
  }
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -1670,6 +1674,9 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; static int mxser_ioctl(struct tty_struct *tty,
  return mxser_ioctl_special(cmd, argp)&lt;/pre&gt;</description>
    <dc:creator>Matwey V. Kornilov</dc:creator>
    <dc:date>2013-05-21T09:57:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11464">
    <title>Re: [PATCH] ARM: bcm2835: override the HW UART periphid</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11464</link>
    <description>&lt;pre&gt;Have checked with the designer of the UART block and he confirmed that
the 2835 PL011 contains a 16 deep fifo not 32 deep...

Hardware guys, they can never just leave it alone!!!

Gordon

On 21 May 2013 07:07, Jongsung Kim &amp;lt;neidhard.kim&amp;lt; at &amp;gt;lge.com&amp;gt; wrote:
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo&amp;lt; at &amp;gt;vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

&lt;/pre&gt;</description>
    <dc:creator>Gordon Hollingworth</dc:creator>
    <dc:date>2013-05-21T09:00:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11463">
    <title>Re: [PATCH] tty: nwpserial: Pass correct pointer to free_irq()</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11463</link>
    <description>&lt;pre&gt;Acked-off-by: Benjamin Krill &amp;lt;ben&amp;lt; at &amp;gt;codiert.org&amp;gt;

On Mon, 2013-05-20 at 19:07 +0200, Lars-Peter Clausen wrote:


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

&lt;/pre&gt;</description>
    <dc:creator>Benjamin Krill</dc:creator>
    <dc:date>2013-05-21T07:18:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11462">
    <title>[PATCH] serial: 8250_dw: add ACPI ID for Intel BayTrail</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11462</link>
    <description>&lt;pre&gt;This is the same controller as on Intel Lynxpoint but the
ACPI ID is different.

Signed-off-by: Heikki Krogerus &amp;lt;heikki.krogerus&amp;lt; at &amp;gt;linux.intel.com&amp;gt;
---
 drivers/tty/serial/8250/8250_dw.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index 0b0eef9..d07b6af 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -369,6 +369,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt; MODULE_DEVICE_TABLE(of, dw8250_of_match);
 static const struct acpi_device_id dw8250_acpi_match[] = {
 { "INT33C4", 0 },
 { "INT33C5", 0 },
+{ "80860F0A", 0 },
 { },
 };
 MODULE_DEVICE_TABLE(acpi, dw8250_acpi_match);
&lt;/pre&gt;</description>
    <dc:creator>Heikki Krogerus</dc:creator>
    <dc:date>2013-05-21T06:34:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11461">
    <title>RE: [PATCH] ARM: bcm2835: override the HW UART periphid</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11461</link>
    <description>&lt;pre&gt;Jongsung Kim &amp;lt;neidhard.kim&amp;lt; at &amp;gt;lge.com&amp;gt; :
b/arch/arm/boot/dts/bcm2835.dtsi

Stephen, how do you think about this kind of approach instead?

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

&lt;/pre&gt;</description>
    <dc:creator>Jongsung Kim</dc:creator>
    <dc:date>2013-05-21T06:07:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11460">
    <title>[PATCH] ARM: bcm2835: override the HW UART periphid</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11460</link>
    <description>&lt;pre&gt;Stephen Warren reported the recent commit 78506f2 (add support for
extended FIFO-size of PL011-r1p5) breaks the serial port on the
BCM2835 ARM SoC.

A UART compatible with the ARM PL011-r1p5 should have 32-deep FIFOs.
The BCM2835 UART just looks like an ARM PL011-r1p5, but has 16-deep
FIFOs just like PL011-r1p4 or earlier revisions. As a workaround for
this compatibility issue, this patch overrides the HW UART periphid
register values with the actually compatible UART periphid 0x00241011
(r1p3 or r1p4).

Reported-by: Stephen Warren &amp;lt;swarren&amp;lt; at &amp;gt;wwwdotorg.org&amp;gt;
Signed-off-by: Jongsung Kim &amp;lt;neidhard.kim&amp;lt; at &amp;gt;lge.com&amp;gt;
---
 arch/arm/boot/dts/bcm2835.dtsi |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index f0052dc..1e12aef 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -44,6 +44,7 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 reg = &amp;lt;0x7e201000 0x1000&amp;gt;;
 interrupts = &amp;lt;2 25&amp;gt;;
 clock-frequency = &amp;lt;3000000&amp;gt;;
+arm,primecell-periphid&lt;/pre&gt;</description>
    <dc:creator>Jongsung Kim</dc:creator>
    <dc:date>2013-05-21T06:02:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.serial/11459">
    <title>Re: [PATCH] ARM: PL011: add support for extended FIFO-size of PL011-r1p5</title>
    <link>http://permalink.gmane.org/gmane.linux.serial/11459</link>
    <description>&lt;pre&gt;
This all seems rather academic. Irrespective of what the cause of the
problem is, the commit actively breaks a previously working
configuration. I still believe we should revert it first, then find out
exactly what's going on later. Should I sent the revert commit?

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

&lt;/pre&gt;</description>
    <dc:creator>Stephen Warren</dc:creator>
    <dc:date>2013-05-21T02:12:58</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.serial">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.serial</link>
  </textinput>
</rdf:RDF>
