<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers, branch v3.5.4</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>hwmon: (asus_atk0110) Add quirk for Asus M5A78L</title>
<updated>2012-09-14T16:59:55+00:00</updated>
<author>
<name>Luca Tettamanti</name>
<email>kronos.it@gmail.com</email>
</author>
<published>2012-08-21T15:36:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=93215341fec52a050b0ccd192e3dbe6eea3c4fd2'/>
<id>93215341fec52a050b0ccd192e3dbe6eea3c4fd2</id>
<content type='text'>
commit 43ca6cb28c871f2fbad10117b0648e5ae3b0f638 upstream.

The old interface is bugged and reads the wrong sensor when retrieving
the reading for the chassis fan (it reads the CPU sensor); the new
interface works fine.

Reported-by: Göran Uddeborg &lt;goeran@uddeborg.se&gt;
Tested-by: Göran Uddeborg &lt;goeran@uddeborg.se&gt;
Signed-off-by: Luca Tettamanti &lt;kronos.it@gmail.com&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&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>
commit 43ca6cb28c871f2fbad10117b0648e5ae3b0f638 upstream.

The old interface is bugged and reads the wrong sensor when retrieving
the reading for the chassis fan (it reads the CPU sensor); the new
interface works fine.

Reported-by: Göran Uddeborg &lt;goeran@uddeborg.se&gt;
Tested-by: Göran Uddeborg &lt;goeran@uddeborg.se&gt;
Signed-off-by: Luca Tettamanti &lt;kronos.it@gmail.com&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen/pciback: Fix proper FLR steps.</title>
<updated>2012-09-14T16:59:55+00:00</updated>
<author>
<name>Konrad Rzeszutek Wilk</name>
<email>konrad.wilk@oracle.com</email>
</author>
<published>2012-09-05T20:35:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2c43fd7058e779eeef7e3dad3a5a8066162cabac'/>
<id>2c43fd7058e779eeef7e3dad3a5a8066162cabac</id>
<content type='text'>
commit 80ba77dfbce85f2d1be54847de3c866de1b18a9a upstream.

When we do FLR and save PCI config we did it in the wrong order.
The end result was that if a PCI device was unbind from
its driver, then binded to xen-pciback, and then back to its
driver we would get:

&gt; lspci -s 04:00.0
04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
13:42:12 # 4 :~/
&gt; echo "0000:04:00.0" &gt; /sys/bus/pci/drivers/pciback/unbind
&gt; modprobe e1000e
e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
e1000e 0000:04:00.0: Disabling ASPM L0s L1
e1000e 0000:04:00.0: enabling device (0000 -&gt; 0002)
xen: registering gsi 48 triggering 0 polarity 1
Already setup the GSI :48
e1000e 0000:04:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e: probe of 0000:04:00.0 failed with error -2

This fixes it by first saving the PCI configuration space, then
doing the FLR.

Reported-by: Ren, Yongjie &lt;yongjie.ren@intel.com&gt;
Reported-and-Tested-by: Tobias Geiger &lt;tobias.geiger@vido.info&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.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>
commit 80ba77dfbce85f2d1be54847de3c866de1b18a9a upstream.

When we do FLR and save PCI config we did it in the wrong order.
The end result was that if a PCI device was unbind from
its driver, then binded to xen-pciback, and then back to its
driver we would get:

&gt; lspci -s 04:00.0
04:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
13:42:12 # 4 :~/
&gt; echo "0000:04:00.0" &gt; /sys/bus/pci/drivers/pciback/unbind
&gt; modprobe e1000e
e1000e: Intel(R) PRO/1000 Network Driver - 2.0.0-k
e1000e: Copyright(c) 1999 - 2012 Intel Corporation.
e1000e 0000:04:00.0: Disabling ASPM L0s L1
e1000e 0000:04:00.0: enabling device (0000 -&gt; 0002)
xen: registering gsi 48 triggering 0 polarity 1
Already setup the GSI :48
e1000e 0000:04:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode
e1000e: probe of 0000:04:00.0 failed with error -2

This fixes it by first saving the PCI configuration space, then
doing the FLR.

Reported-by: Ren, Yongjie &lt;yongjie.ren@intel.com&gt;
Reported-and-Tested-by: Tobias Geiger &lt;tobias.geiger@vido.info&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>xen: Use correct masking in xen_swiotlb_alloc_coherent.</title>
<updated>2012-09-14T16:59:54+00:00</updated>
<author>
<name>Ronny Hegewald</name>
<email>ronny.hegewald@online.de</email>
</author>
<published>2012-08-31T09:57:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e47ba09bac3c8f08dbf4fba89bf73c808aff13e2'/>
<id>e47ba09bac3c8f08dbf4fba89bf73c808aff13e2</id>
<content type='text'>
commit b5031ed1be0aa419250557123633453753181643 upstream.

When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.

The underlaying reason is that if the supplied driver passes in a
DMA_BIT_MASK(64) ( hwdev-&gt;coherent_dma_mask is set to 0xffffffffffffffff)
our dma_mask will be u64 set to 0xffffffffffffffff even if we set it to
DMA_BIT_MASK(32) previously. Meaning we do not reset the upper bits.
By using the dma_alloc_coherent_mask function - it does the proper casting
and we get 0xfffffffff.

This caused not working sound on a system with 4 GB and a 64-bit
compatible sound-card with sets the DMA-mask to 64bit.

On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
DMA-memory is always allocated inside the 32-bit address-range by calling
dma_alloc_coherent_mask.

This patch adds the same functionality to xen swiotlb and is a rebase of the
original patch from Ronny Hegewald which never got upstream b/c the
underlaying reason was not understood until now.

The original email with the original patch is in:
http://old-list-archives.xen.org/archives/html/xen-devel/2010-02/msg00038.html
the original thread from where the discussion started is in:
http://old-list-archives.xen.org/archives/html/xen-devel/2010-01/msg00928.html

Signed-off-by: Ronny Hegewald &lt;ronny.hegewald@online.de&gt;
Signed-off-by: Stefano Panella &lt;stefano.panella@citrix.com&gt;
Acked-By: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.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>
commit b5031ed1be0aa419250557123633453753181643 upstream.

When running 32-bit pvops-dom0 and a driver tries to allocate a coherent
DMA-memory the xen swiotlb-implementation returned memory beyond 4GB.

The underlaying reason is that if the supplied driver passes in a
DMA_BIT_MASK(64) ( hwdev-&gt;coherent_dma_mask is set to 0xffffffffffffffff)
our dma_mask will be u64 set to 0xffffffffffffffff even if we set it to
DMA_BIT_MASK(32) previously. Meaning we do not reset the upper bits.
By using the dma_alloc_coherent_mask function - it does the proper casting
and we get 0xfffffffff.

This caused not working sound on a system with 4 GB and a 64-bit
compatible sound-card with sets the DMA-mask to 64bit.

On bare-metal and the forward-ported xen-dom0 patches from OpenSuse a coherent
DMA-memory is always allocated inside the 32-bit address-range by calling
dma_alloc_coherent_mask.

This patch adds the same functionality to xen swiotlb and is a rebase of the
original patch from Ronny Hegewald which never got upstream b/c the
underlaying reason was not understood until now.

The original email with the original patch is in:
http://old-list-archives.xen.org/archives/html/xen-devel/2010-02/msg00038.html
the original thread from where the discussion started is in:
http://old-list-archives.xen.org/archives/html/xen-devel/2010-01/msg00928.html

Signed-off-by: Ronny Hegewald &lt;ronny.hegewald@online.de&gt;
Signed-off-by: Stefano Panella &lt;stefano.panella@citrix.com&gt;
Acked-By: David Vrabel &lt;david.vrabel@citrix.com&gt;
Signed-off-by: Konrad Rzeszutek Wilk &lt;konrad.wilk@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>e1000e: DoS while TSO enabled caused by link partner with small MSS</title>
<updated>2012-09-14T16:59:54+00:00</updated>
<author>
<name>Bruce Allan</name>
<email>bruce.w.allan@intel.com</email>
</author>
<published>2012-08-24T20:38:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d59b54490e65baaa251021f1956cd43280a956ef'/>
<id>d59b54490e65baaa251021f1956cd43280a956ef</id>
<content type='text'>
commit d821a4c4d11ad160925dab2bb009b8444beff484 upstream.

With a low enough MSS on the link partner and TSO enabled locally, the
networking stack can periodically send a very large (e.g.  64KB) TCP
message for which the driver will attempt to use more Tx descriptors than
are available by default in the Tx ring.  This is due to a workaround in
the code that imposes a limit of only 4 MSS-sized segments per descriptor
which appears to be a carry-over from the older e1000 driver and may be
applicable only to some older PCI or PCIx parts which are not supported in
e1000e.  When the driver gets a message that is too large to fit across the
configured number of Tx descriptors, it stops the upper stack from queueing
any more and gets stuck in this state.  After a timeout, the upper stack
assumes the adapter is hung and calls the driver to reset it.

Remove the unnecessary limitation of using up to only 4 MSS-sized segments
per Tx descriptor, and put in a hard failure test to catch when attempting
to check for message sizes larger than would fit in the whole Tx ring.
Refactor the remaining logic that limits the size of data per Tx descriptor
from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
Tx packet buffer as described in the hardware specification.

Also, fix the logic in the check for space in the Tx ring for the next
largest possible packet after the current one has been successfully queued
for transmit, and use the appropriate defines for default ring sizes in
e1000_probe instead of magic values.

This issue goes back to the introduction of e1000e in 2.6.24 when it was
split off from e1000.

Reported-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
Signed-off-by: Bruce Allan &lt;bruce.w.allan@intel.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&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>
commit d821a4c4d11ad160925dab2bb009b8444beff484 upstream.

With a low enough MSS on the link partner and TSO enabled locally, the
networking stack can periodically send a very large (e.g.  64KB) TCP
message for which the driver will attempt to use more Tx descriptors than
are available by default in the Tx ring.  This is due to a workaround in
the code that imposes a limit of only 4 MSS-sized segments per descriptor
which appears to be a carry-over from the older e1000 driver and may be
applicable only to some older PCI or PCIx parts which are not supported in
e1000e.  When the driver gets a message that is too large to fit across the
configured number of Tx descriptors, it stops the upper stack from queueing
any more and gets stuck in this state.  After a timeout, the upper stack
assumes the adapter is hung and calls the driver to reset it.

Remove the unnecessary limitation of using up to only 4 MSS-sized segments
per Tx descriptor, and put in a hard failure test to catch when attempting
to check for message sizes larger than would fit in the whole Tx ring.
Refactor the remaining logic that limits the size of data per Tx descriptor
from a seemingly arbitrary 8KB to a limit based on the dynamic size of the
Tx packet buffer as described in the hardware specification.

Also, fix the logic in the check for space in the Tx ring for the next
largest possible packet after the current one has been successfully queued
for transmit, and use the appropriate defines for default ring sizes in
e1000_probe instead of magic values.

This issue goes back to the introduction of e1000e in 2.6.24 when it was
split off from e1000.

Reported-by: Ben Hutchings &lt;bhutchings@solarflare.com&gt;
Signed-off-by: Bruce Allan &lt;bruce.w.allan@intel.com&gt;
Tested-by: Aaron Brown &lt;aaron.f.brown@intel.com&gt;
Signed-off-by: Jeff Kirsher &lt;jeffrey.t.kirsher@intel.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>OMAPFB: fix framebuffer console colors</title>
<updated>2012-09-14T16:59:54+00:00</updated>
<author>
<name>Grazvydas Ignotas</name>
<email>notasas@gmail.com</email>
</author>
<published>2012-08-21T06:09:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=819b337cd90c18a07b2897c7b9747acd42bab839'/>
<id>819b337cd90c18a07b2897c7b9747acd42bab839</id>
<content type='text'>
commit c1c52848cef52e157468b8879fc3cae23b6f3a99 upstream.

omapfb does not currently set pseudo palette correctly for color depths
above 16bpp, making red text invisible, command like
  echo -e '\e[0;31mRED' &gt; /dev/tty1
will display nothing on framebuffer console in 24bpp mode.
This is because temporary variable is declared incorrectly, fix it.

Signed-off-by: Grazvydas Ignotas &lt;notasas@gmail.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&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>
commit c1c52848cef52e157468b8879fc3cae23b6f3a99 upstream.

omapfb does not currently set pseudo palette correctly for color depths
above 16bpp, making red text invisible, command like
  echo -e '\e[0;31mRED' &gt; /dev/tty1
will display nothing on framebuffer console in 24bpp mode.
This is because temporary variable is declared incorrectly, fix it.

Signed-off-by: Grazvydas Ignotas &lt;notasas@gmail.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: add MODULE_DEVICE_TABLE so vmwgfx loads at boot</title>
<updated>2012-09-14T16:59:54+00:00</updated>
<author>
<name>Dave Airlie</name>
<email>airlied@redhat.com</email>
</author>
<published>2012-08-29T01:40:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=28abd527db92eeac90637c6255567ba2ec34f33b'/>
<id>28abd527db92eeac90637c6255567ba2ec34f33b</id>
<content type='text'>
commit c4903429a92be60e6fe59868924a65eca4cd1a38 upstream.

This will cause udev to load vmwgfx instead of waiting for X
to do it.

Reviewed-by: Jakob Bornecrantz &lt;jakob@vmware.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.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>
commit c4903429a92be60e6fe59868924a65eca4cd1a38 upstream.

This will cause udev to load vmwgfx instead of waiting for X
to do it.

Reviewed-by: Jakob Bornecrantz &lt;jakob@vmware.com&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>UBI: fix a horrible memory deallocation bug</title>
<updated>2012-09-14T16:59:54+00:00</updated>
<author>
<name>Artem Bityutskiy</name>
<email>artem.bityutskiy@linux.intel.com</email>
</author>
<published>2012-09-03T14:12:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=94ff8b10c8047e49318eb4ed3beeffbbff869285'/>
<id>94ff8b10c8047e49318eb4ed3beeffbbff869285</id>
<content type='text'>
commit 78b495c39add820ab66ab897af9bd77a5f2e91f6 upstream.

UBI was mistakingly using 'kfree()' instead of 'kmem_cache_free()' when
freeing "attach eraseblock" structures in vtbl.c. Thankfully, this happened
only when we were doing auto-format, so many systems were unaffected. However,
there are still many users affected.

It is strange, but the system did not crash and nothing bad happened when
the SLUB memory allocator was used. However, in case of SLOB we observed an
crash right away.

This problem was introduced in 2.6.39 by commit
"6c1e875 UBI: add slab cache for ubi_scan_leb objects"

A note for stable trees:
  Because variable were renamed, this won't cleanly apply to older kernels.
  Changing names like this should help:
	1. ai -&gt; si
	2. aeb_slab_cache -&gt; seb_slab_cache
	3. new_aeb -&gt; new_seb

Reported-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Tested-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Tested-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@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>
commit 78b495c39add820ab66ab897af9bd77a5f2e91f6 upstream.

UBI was mistakingly using 'kfree()' instead of 'kmem_cache_free()' when
freeing "attach eraseblock" structures in vtbl.c. Thankfully, this happened
only when we were doing auto-format, so many systems were unaffected. However,
there are still many users affected.

It is strange, but the system did not crash and nothing bad happened when
the SLUB memory allocator was used. However, in case of SLOB we observed an
crash right away.

This problem was introduced in 2.6.39 by commit
"6c1e875 UBI: add slab cache for ubi_scan_leb objects"

A note for stable trees:
  Because variable were renamed, this won't cleanly apply to older kernels.
  Changing names like this should help:
	1. ai -&gt; si
	2. aeb_slab_cache -&gt; seb_slab_cache
	3. new_aeb -&gt; new_seb

Reported-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Tested-by: Richard Genoud &lt;richard.genoud@gmail.com&gt;
Tested-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: Artem Bityutskiy &lt;artem.bityutskiy@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Input: i8042 - add Gigabyte T1005 series netbooks to noloop table</title>
<updated>2012-09-14T16:59:54+00:00</updated>
<author>
<name>Dmitry Torokhov</name>
<email>dmitry.torokhov@gmail.com</email>
</author>
<published>2012-08-22T04:57:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=996ab492443658e15b0a6b912ed703411e005475'/>
<id>996ab492443658e15b0a6b912ed703411e005475</id>
<content type='text'>
commit 7b125b94ca16b7e618c6241cb02c4c8060cea5e3 upstream.

They all define their chassis type as "Other" and therefore are not
categorized as "laptops" by the driver, which tries to perform AUX IRQ
delivery test which fails and causes touchpad not working.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42620
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.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>
commit 7b125b94ca16b7e618c6241cb02c4c8060cea5e3 upstream.

They all define their chassis type as "Other" and therefore are not
categorized as "laptops" by the driver, which tries to perform AUX IRQ
delivery test which fails and causes touchpad not working.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42620
Signed-off-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>HID: add NOGET quirk for Eaton Ellipse MAX UPS</title>
<updated>2012-09-14T16:59:53+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2012-08-23T14:51:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=219cf47cec80faa3b1dd3513adde6f70a58e34db'/>
<id>219cf47cec80faa3b1dd3513adde6f70a58e34db</id>
<content type='text'>
commit 67ddbb3e6568fb1820b2cc45b00c50702b114801 upstream.

This patch (as1603) adds a NOGET quirk for the Eaton Ellipse MAX UPS
device.  (The USB IDs were already present in hid-ids.h, apparently
under a different name.)

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Laurent Bigonville &lt;l.bigonville@edpnet.be&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&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>
commit 67ddbb3e6568fb1820b2cc45b00c50702b114801 upstream.

This patch (as1603) adds a NOGET quirk for the Eaton Ellipse MAX UPS
device.  (The USB IDs were already present in hid-ids.h, apparently
under a different name.)

Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: Laurent Bigonville &lt;l.bigonville@edpnet.be&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>i2c-i801: Add Device IDs for Intel Lynx Point-LP PCH</title>
<updated>2012-09-14T16:59:53+00:00</updated>
<author>
<name>James Ralston</name>
<email>james.d.ralston@intel.com</email>
</author>
<published>2012-09-10T08:14:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=cdc854ed9062170e7ff485aafc4f1b0cfe1fd127'/>
<id>cdc854ed9062170e7ff485aafc4f1b0cfe1fd127</id>
<content type='text'>
commit 4a8f1ddde942e232387e6129ce4f4c412e43802f upstream.

Add the SMBus Device IDs for the Intel Lynx Point-LP PCH.

Signed-off-by: James Ralston &lt;james.d.ralston@intel.com&gt;
Signed-off-by: Jean Delvare &lt;khali@linux-fr.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>
commit 4a8f1ddde942e232387e6129ce4f4c412e43802f upstream.

Add the SMBus Device IDs for the Intel Lynx Point-LP PCH.

Signed-off-by: James Ralston &lt;james.d.ralston@intel.com&gt;
Signed-off-by: Jean Delvare &lt;khali@linux-fr.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
