<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include/linux/serial_8250.h, branch v3.17.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers</title>
<updated>2014-07-18T01:23:35+00:00</updated>
<author>
<name>Yoshihiro YUNOMAE</name>
<email>yoshihiro.yunomae.ez@hitachi.com</email>
</author>
<published>2014-07-16T01:19:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=aef9a7bd9b676f797dd5cefd43deb30d36b976a9'/>
<id>aef9a7bd9b676f797dd5cefd43deb30d36b976a9</id>
<content type='text'>
Add tunable RX interrupt trigger I/F of FIFO buffers.

Serial devices are used as not only message communication devices but control
or sending communication devices. For the latter uses, normally small data
will be exchanged, so user applications want to receive data unit as soon as
possible for real-time tendency. If we have a sensor which sends a 1 byte data
each time and must control a device based on the sensor feedback, the RX
interrupt should be triggered for each data.

According to HW specification of serial UART devices, RX interrupt trigger
can be changed, but the trigger is hard-coded. For example, RX interrupt trigger
in 16550A can be set to 1, 4, 8, or 14 bytes for HW, but current driver sets
the trigger to only 8bytes.

This patch makes some devices change RX interrupt trigger from userland.

&lt;How to use&gt;
- Read current setting
 # cat /sys/class/tty/ttyS0/rx_trig_bytes
 8

- Write user setting
 # echo 1 &gt; /sys/class/tty/ttyS0/rx_trig_bytes
 # cat /sys/class/tty/ttyS0/rx_trig_bytes
 1

&lt;Support uart devices&gt;
- 16550A and Tegra (1, 4, 8, or 14 bytes)
- 16650V2 (8, 16, 24, or 28 bytes)
- 16654 (8, 16, 56, or 60 bytes)
- 16750 (1, 16, 32, or 56 bytes)

&lt;Change log&gt;
Changes in V9:
 - Use attr_group instead of dev_spec_attr_group of uart_port structure

Changes in V8:
 - Divide this patch from V7's patch based on Greg's comment

Changes in V7:
 - Add Documentation
 - Change I/F name from rx_int_trig to rx_trig_bytes because the name
   rx_int_trig is hard to understand how users specify the value

Changes in V6:
 - Move FCR_RX_TRIG_* definition in 8250.h to include/uapi/linux/serial_reg.h,
   rename those to UART_FCR_R_TRIG_*, and use UART_FCR_TRIGGER_MASK to
   UART_FCR_R_TRIG_BITS()
 - Change following function names:
    convert_fcr2val() =&gt; fcr_get_rxtrig_bytes()
    convert_val2rxtrig() =&gt; bytes_to_fcr_rxtrig()
 - Fix typo in serial8250_do_set_termios()
 - Delete the verbose error message pr_info() in bytes_to_fcr_rxtrig()
 - Rename *rx_int_trig/rx_trig* to *rxtrig* for several functions or variables
   (but UI remains rx_int_trig)
 - Change the meaningless variable name 'val' to 'bytes' following functions:
    fcr_get_rxtrig_bytes(), bytes_to_fcr_rxtrig(), do_set_rxtrig(),
    do_serial8250_set_rxtrig(), and serial8250_set_attr_rxtrig()
 - Use up-&gt;fcr in order to get rxtrig_bytes instead of rx_trig_raw in
   fcr_get_rxtrig_bytes()
 - Use conf_type-&gt;rxtrig_bytes[0] instead of switch statement for support check
   in register_dev_spec_attr_grp()
 - Delete the checking whether a user changed FCR or not when minimum buffer
   is needed in serial8250_do_set_termios()

Changes in V5.1:
 - Fix FCR_RX_TRIG_MAX_STATE definition

Changes in V5:
 - Support Tegra, 16650V2, 16654, and 16750
 - Store default FCR value to up-&gt;fcr when the port is first created
 - Add rx_trig_byte[] in uart_config[] for each device and use rx_trig_byte[]
   in convert_fcr2val() and convert_val2rxtrig()

Changes in V4:
 - Introduce fifo_bug flag in uart_8250_port structure
   This is enabled only when parity is enabled and UART_BUG_PARITY is enabled
   for up-&gt;bugs. If this flag is enabled, user cannot set RX trigger.
 - Return -EOPNOTSUPP when it does not support device at convert_fcr2val() and
   at convert_val2rxtrig()
 - Set the nearest lower RX trigger when users input a meaningless value at
   convert_val2rxtrig()
 - Check whether p-&gt;fcr is existing at serial8250_clear_and_reinit_fifos()
 - Set fcr = up-&gt;fcr in the begging of serial8250_do_set_termios()

Changes in V3:
 - Change I/F from ioctl(2) to sysfs(rx_int_trig)

Changed in V2:
 - Use _IOW for TIOCSFIFORTRIG definition
 - Pass the interrupt trigger value itself

Signed-off-by: Yoshihiro YUNOMAE &lt;yoshihiro.yunomae.ez@hitachi.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add tunable RX interrupt trigger I/F of FIFO buffers.

Serial devices are used as not only message communication devices but control
or sending communication devices. For the latter uses, normally small data
will be exchanged, so user applications want to receive data unit as soon as
possible for real-time tendency. If we have a sensor which sends a 1 byte data
each time and must control a device based on the sensor feedback, the RX
interrupt should be triggered for each data.

According to HW specification of serial UART devices, RX interrupt trigger
can be changed, but the trigger is hard-coded. For example, RX interrupt trigger
in 16550A can be set to 1, 4, 8, or 14 bytes for HW, but current driver sets
the trigger to only 8bytes.

This patch makes some devices change RX interrupt trigger from userland.

&lt;How to use&gt;
- Read current setting
 # cat /sys/class/tty/ttyS0/rx_trig_bytes
 8

- Write user setting
 # echo 1 &gt; /sys/class/tty/ttyS0/rx_trig_bytes
 # cat /sys/class/tty/ttyS0/rx_trig_bytes
 1

&lt;Support uart devices&gt;
- 16550A and Tegra (1, 4, 8, or 14 bytes)
- 16650V2 (8, 16, 24, or 28 bytes)
- 16654 (8, 16, 56, or 60 bytes)
- 16750 (1, 16, 32, or 56 bytes)

&lt;Change log&gt;
Changes in V9:
 - Use attr_group instead of dev_spec_attr_group of uart_port structure

Changes in V8:
 - Divide this patch from V7's patch based on Greg's comment

Changes in V7:
 - Add Documentation
 - Change I/F name from rx_int_trig to rx_trig_bytes because the name
   rx_int_trig is hard to understand how users specify the value

Changes in V6:
 - Move FCR_RX_TRIG_* definition in 8250.h to include/uapi/linux/serial_reg.h,
   rename those to UART_FCR_R_TRIG_*, and use UART_FCR_TRIGGER_MASK to
   UART_FCR_R_TRIG_BITS()
 - Change following function names:
    convert_fcr2val() =&gt; fcr_get_rxtrig_bytes()
    convert_val2rxtrig() =&gt; bytes_to_fcr_rxtrig()
 - Fix typo in serial8250_do_set_termios()
 - Delete the verbose error message pr_info() in bytes_to_fcr_rxtrig()
 - Rename *rx_int_trig/rx_trig* to *rxtrig* for several functions or variables
   (but UI remains rx_int_trig)
 - Change the meaningless variable name 'val' to 'bytes' following functions:
    fcr_get_rxtrig_bytes(), bytes_to_fcr_rxtrig(), do_set_rxtrig(),
    do_serial8250_set_rxtrig(), and serial8250_set_attr_rxtrig()
 - Use up-&gt;fcr in order to get rxtrig_bytes instead of rx_trig_raw in
   fcr_get_rxtrig_bytes()
 - Use conf_type-&gt;rxtrig_bytes[0] instead of switch statement for support check
   in register_dev_spec_attr_grp()
 - Delete the checking whether a user changed FCR or not when minimum buffer
   is needed in serial8250_do_set_termios()

Changes in V5.1:
 - Fix FCR_RX_TRIG_MAX_STATE definition

Changes in V5:
 - Support Tegra, 16650V2, 16654, and 16750
 - Store default FCR value to up-&gt;fcr when the port is first created
 - Add rx_trig_byte[] in uart_config[] for each device and use rx_trig_byte[]
   in convert_fcr2val() and convert_val2rxtrig()

Changes in V4:
 - Introduce fifo_bug flag in uart_8250_port structure
   This is enabled only when parity is enabled and UART_BUG_PARITY is enabled
   for up-&gt;bugs. If this flag is enabled, user cannot set RX trigger.
 - Return -EOPNOTSUPP when it does not support device at convert_fcr2val() and
   at convert_val2rxtrig()
 - Set the nearest lower RX trigger when users input a meaningless value at
   convert_val2rxtrig()
 - Check whether p-&gt;fcr is existing at serial8250_clear_and_reinit_fifos()
 - Set fcr = up-&gt;fcr in the begging of serial8250_do_set_termios()

Changes in V3:
 - Change I/F from ioctl(2) to sysfs(rx_int_trig)

Changed in V2:
 - Use _IOW for TIOCSFIFORTRIG definition
 - Pass the interrupt trigger value itself

Signed-off-by: Yoshihiro YUNOMAE &lt;yoshihiro.yunomae.ez@hitachi.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250: introduce up_to_u8250p() helper</title>
<updated>2014-07-18T01:16:23+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2014-07-14T11:26:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b1261c86fe238cc0da3f5dc837a38a0c39f3e7c4'/>
<id>b1261c86fe238cc0da3f5dc837a38a0c39f3e7c4</id>
<content type='text'>
It helps to cast struct uart_port to struct uart_8250_port at runtime.

Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It helps to cast struct uart_port to struct uart_8250_port at runtime.

Signed-off-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250: Add support for dmaengine</title>
<updated>2013-01-16T07:03:00+00:00</updated>
<author>
<name>Heikki Krogerus</name>
<email>heikki.krogerus@linux.intel.com</email>
</author>
<published>2013-01-10T09:25:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9ee4b83e51f741a645c43e61b9f3f8075ca0fdf4'/>
<id>9ee4b83e51f741a645c43e61b9f3f8075ca0fdf4</id>
<content type='text'>
Add support for dmaengine API. The drivers can implement the
struct uart_8250_dma member in struct uart_8250_port and
8250.c can take care of the rest.

Signed-off-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add support for dmaengine API. The drivers can implement the
struct uart_8250_dma member in struct uart_8250_port and
8250.c can take care of the rest.

Signed-off-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tty/8250_early: Turn serial_in/serial_out into weak symbols.</title>
<updated>2012-11-16T12:39:15+00:00</updated>
<author>
<name>Noam Camus</name>
<email>noamc@ezchip.com</email>
</author>
<published>2012-11-16T05:03:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ed71871bed7198ca4aa6a79b7a93b73ad6408e98'/>
<id>ed71871bed7198ca4aa6a79b7a93b73ad6408e98</id>
<content type='text'>
Allows overriding default methods serial_in/serial_out.

In such platform specific replacement it is possible to use
other regshift, biased register offset, any other manipulation
that is not covered with common default methods.

Overriding default methods may be useful for platforms which got
serial peripheral with registers represented in big endian.
In this situation and assuming that 32 bit operations / alignment
is required then it may be useful to swab words before/after
accessing the serial registers.

Signed-off-by: Noam Camus &lt;noamc@ezchip.com&gt;
Acked-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Allows overriding default methods serial_in/serial_out.

In such platform specific replacement it is possible to use
other regshift, biased register offset, any other manipulation
that is not covered with common default methods.

Overriding default methods may be useful for platforms which got
serial peripheral with registers represented in big endian.
In this situation and assuming that 32 bit operations / alignment
is required then it may be useful to swab words before/after
accessing the serial registers.

Signed-off-by: Noam Camus &lt;noamc@ezchip.com&gt;
Acked-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>8250: three way resolve of the 8250 diffs</title>
<updated>2012-07-17T16:11:50+00:00</updated>
<author>
<name>Alan Cox</name>
<email>alan@linux.intel.com</email>
</author>
<published>2012-07-17T16:06:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ce7240e445303de3ca66e6d08f17a2ec278a5bf6'/>
<id>ce7240e445303de3ca66e6d08f17a2ec278a5bf6</id>
<content type='text'>
This resolves the differences between the original 8250 patch, the revised 8250 patch
and the independant clean up of the octeon driver (to use platform devices properly yay!)

Signed-off-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This resolves the differences between the original 8250 patch, the revised 8250 patch
and the independant clean up of the octeon driver (to use platform devices properly yay!)

Signed-off-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>8250: use the 8250 register interface not the legacy one</title>
<updated>2012-07-12T21:46:22+00:00</updated>
<author>
<name>Alan Cox</name>
<email>alan@linux.intel.com</email>
</author>
<published>2012-07-12T11:59:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2655a2c76f80d91da34faa8f4e114d1793435ed3'/>
<id>2655a2c76f80d91da34faa8f4e114d1793435ed3</id>
<content type='text'>
The old interface just copies bits over and calls the newer one.
In addition we can now pass more information.

Signed-off-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The old interface just copies bits over and calls the newer one.
In addition we can now pass more information.

Signed-off-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'delete-mca' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux</title>
<updated>2012-05-24T00:12:06+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2012-05-24T00:12:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d5b4bb4d103cd601d8009f2d3a7e44586c9ae7cc'/>
<id>d5b4bb4d103cd601d8009f2d3a7e44586c9ae7cc</id>
<content type='text'>
Pull the MCA deletion branch from Paul Gortmaker:
 "It was good that we could support MCA machines back in the day, but
  realistically, nobody is using them anymore.  They were mostly limited
  to 386-sx 16MHz CPU and some 486 class machines and never more than
  64MB of RAM.  Even the enthusiast hobbyist community seems to have
  dried up close to ten years ago, based on what you can find searching
  various websites dedicated to the relatively short lived hardware.

  So lets remove the support relating to CONFIG_MCA.  There is no point
  carrying this forward, wasting cycles doing routine maintenance on it;
  wasting allyesconfig build time on validating it, wasting I/O on git
  grep'ping over it, and so on."

Let's see if anybody screams.  It generally has compiled, and James
Bottomley pointed out that there was a MCA extension from NCR that
allowed for up to 4GB of memory and PPro-class machines.  So in *theory*
there may be users out there.

But even James (technically listed as a maintainer) doesn't actually
have a system, and while Alan Cox claims to have a machine in his cellar
that he offered to anybody who wants to take it off his hands, he didn't
argue for keeping MCA support either.

So we could bring it back.  But somebody had better speak up and talk
about how they have actually been using said MCA hardware with modern
kernels for us to do that.  And David already took the patch to delete
all the networking driver code (commit a5e371f61ad3: "drivers/net:
delete all code/drivers depending on CONFIG_MCA").

* 'delete-mca' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
  MCA: delete all remaining traces of microchannel bus support.
  scsi: delete the MCA specific drivers and driver code
  serial: delete the MCA specific 8250 support.
  arm: remove ability to select CONFIG_MCA
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull the MCA deletion branch from Paul Gortmaker:
 "It was good that we could support MCA machines back in the day, but
  realistically, nobody is using them anymore.  They were mostly limited
  to 386-sx 16MHz CPU and some 486 class machines and never more than
  64MB of RAM.  Even the enthusiast hobbyist community seems to have
  dried up close to ten years ago, based on what you can find searching
  various websites dedicated to the relatively short lived hardware.

  So lets remove the support relating to CONFIG_MCA.  There is no point
  carrying this forward, wasting cycles doing routine maintenance on it;
  wasting allyesconfig build time on validating it, wasting I/O on git
  grep'ping over it, and so on."

Let's see if anybody screams.  It generally has compiled, and James
Bottomley pointed out that there was a MCA extension from NCR that
allowed for up to 4GB of memory and PPro-class machines.  So in *theory*
there may be users out there.

But even James (technically listed as a maintainer) doesn't actually
have a system, and while Alan Cox claims to have a machine in his cellar
that he offered to anybody who wants to take it off his hands, he didn't
argue for keeping MCA support either.

So we could bring it back.  But somebody had better speak up and talk
about how they have actually been using said MCA hardware with modern
kernels for us to do that.  And David already took the patch to delete
all the networking driver code (commit a5e371f61ad3: "drivers/net:
delete all code/drivers depending on CONFIG_MCA").

* 'delete-mca' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
  MCA: delete all remaining traces of microchannel bus support.
  scsi: delete the MCA specific drivers and driver code
  serial: delete the MCA specific 8250 support.
  arm: remove ability to select CONFIG_MCA
</pre>
</div>
</content>
</entry>
<entry>
<title>serial: delete the MCA specific 8250 support.</title>
<updated>2012-05-17T23:02:14+00:00</updated>
<author>
<name>Paul Gortmaker</name>
<email>paul.gortmaker@windriver.com</email>
</author>
<published>2012-05-17T00:27:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d157be852f6c76dc467f3a03b89263880e14c513'/>
<id>d157be852f6c76dc467f3a03b89263880e14c513</id>
<content type='text'>
The support for CONFIG_MCA is being removed, since the 20
year old hardware simply isn't capable of meeting today's
software demands on CPU and memory resources.

This commit removes the MCA specific 8250 UART code.

Cc: Alan Cox &lt;alan@linux.intel.com&gt;
Cc: linux-serial@vger.kernel.org
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The support for CONFIG_MCA is being removed, since the 20
year old hardware simply isn't capable of meeting today's
software demands on CPU and memory resources.

This commit removes the MCA specific 8250 UART code.

Cc: Alan Cox &lt;alan@linux.intel.com&gt;
Cc: linux-serial@vger.kernel.org
Acked-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Paul Gortmaker &lt;paul.gortmaker@windriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>serial8250: Introduce serial8250_register_8250_port()</title>
<updated>2012-05-02T21:14:13+00:00</updated>
<author>
<name>Magnus Damm</name>
<email>damm@opensource.se</email>
</author>
<published>2012-05-02T12:47:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f73fa05b90eb8c0dd3230c364cf1107f4f8f3848'/>
<id>f73fa05b90eb8c0dd3230c364cf1107f4f8f3848</id>
<content type='text'>
Introduce yet another 8250 registration function.
This time it is serial8250_register_8250_port() and it
allows us to register 8250 hardware instances using struct
uart_8250_port. The new function makes it possible to
register 8250 hardware that makes use of 8250 specific
callbacks such as -&gt;dl_read() and -&gt;dl_write().

Signed-off-by: Magnus Damm &lt;damm@opensource.se&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Introduce yet another 8250 registration function.
This time it is serial8250_register_8250_port() and it
allows us to register 8250 hardware instances using struct
uart_8250_port. The new function makes it possible to
register 8250 hardware that makes use of 8250 specific
callbacks such as -&gt;dl_read() and -&gt;dl_write().

Signed-off-by: Magnus Damm &lt;damm@opensource.se&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tegra, serial8250: add -&gt;handle_break() uart_port op</title>
<updated>2012-04-18T22:07:53+00:00</updated>
<author>
<name>Dan Williams</name>
<email>dan.j.williams@intel.com</email>
</author>
<published>2012-04-10T21:10:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bf03f65b7967df5807ddef7b99f8a41d4c94fc70'/>
<id>bf03f65b7967df5807ddef7b99f8a41d4c94fc70</id>
<content type='text'>
The "KT" serial port has another use case for a "received break" quirk,
so before adding another special case to the 8250 core take this
opportunity to push such quirks out of the core and into a uart_port op.

Stephen says:
"If the callback function is to no longer live in 8250.c itself,
 arch/arm/mach-tegra/devices.c isn't logically a good place to put it,
 and that file will be going away once we get rid of all the board files
 and move solely to device tree."

...so since 8250_pci.c houses all the quirks for pci serial devices this
quirk is similarly housed in of_serial.c.  Once the open firmware
conversion completes the infrastructure details
(include/linux/of_serial.h, and the export) can all be removed to make
this self contained to of_serial.c.

Cc: Nhan H Mai &lt;nhan.h.mai@intel.com&gt;
Cc: Colin Cross &lt;ccross@android.com&gt;
Cc: Olof Johansson &lt;olof@lixom.net&gt;
[stephen: kill CONFIG_SERIAL_TEGRA in favor just using CONFIG_ARCH_TEGRA]
Cc: Grant Likely &lt;grant.likely@secretlab.ca&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Sudhakar Mamillapalli &lt;sudhakar@fb.com&gt;
Reported-by: Alan Cox &lt;alan@lxorguk.ukuu.org.uk&gt;
Acked-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Acked-by: Stephen Warren &lt;swarren@wwwdotorg.org&gt;
Tested-by: Stephen Warren &lt;swarren@wwwdotorg.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The "KT" serial port has another use case for a "received break" quirk,
so before adding another special case to the 8250 core take this
opportunity to push such quirks out of the core and into a uart_port op.

Stephen says:
"If the callback function is to no longer live in 8250.c itself,
 arch/arm/mach-tegra/devices.c isn't logically a good place to put it,
 and that file will be going away once we get rid of all the board files
 and move solely to device tree."

...so since 8250_pci.c houses all the quirks for pci serial devices this
quirk is similarly housed in of_serial.c.  Once the open firmware
conversion completes the infrastructure details
(include/linux/of_serial.h, and the export) can all be removed to make
this self contained to of_serial.c.

Cc: Nhan H Mai &lt;nhan.h.mai@intel.com&gt;
Cc: Colin Cross &lt;ccross@android.com&gt;
Cc: Olof Johansson &lt;olof@lixom.net&gt;
[stephen: kill CONFIG_SERIAL_TEGRA in favor just using CONFIG_ARCH_TEGRA]
Cc: Grant Likely &lt;grant.likely@secretlab.ca&gt;
Acked-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Acked-by: Sudhakar Mamillapalli &lt;sudhakar@fb.com&gt;
Reported-by: Alan Cox &lt;alan@lxorguk.ukuu.org.uk&gt;
Acked-by: Alan Cox &lt;alan@linux.intel.com&gt;
Signed-off-by: Dan Williams &lt;dan.j.williams@intel.com&gt;
Acked-by: Stephen Warren &lt;swarren@wwwdotorg.org&gt;
Tested-by: Stephen Warren &lt;swarren@wwwdotorg.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
