<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers, branch v3.0.59</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers?h=v3.0.59</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers?h=v3.0.59'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-01-17T16:44:15Z</updated>
<entry>
<title>staging: comedi: Kconfig: COMEDI_NI_AT_A2150 should select COMEDI_FC</title>
<updated>2013-01-17T16:44:15Z</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2013-01-03T12:15:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7633459bb303190c8c016817de45534b202a82d1'/>
<id>urn:sha1:7633459bb303190c8c016817de45534b202a82d1</id>
<content type='text'>
commit 34ffb33e09132401872fe79e95c30824ce194d23 upstream.

The 'ni_at_a2150' module links to `cfc_write_to_buffer` in the
'comedi_fc' module, so selecting 'COMEDI_NI_AT_A2150' in the kernel config
needs to also select 'COMEDI_FC'.

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>staging: comedi: don't hijack hardware device private data</title>
<updated>2013-01-17T16:44:13Z</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2012-03-30T16:14:58Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=57a750294d5d53a6ec49ac69e837216b1d982d78'/>
<id>urn:sha1:57a750294d5d53a6ec49ac69e837216b1d982d78</id>
<content type='text'>
commit c43435d7722134ed1fda58ce1025f41029bd58ad upstream.

comedi_auto_config() associates a Comedi minor device number with an
auto-configured hardware device and comedi_auto_unconfig() disassociates
it.  Currently, these use the hardware device's private data pointer to
point to some allocated storage holding the minor device number.  This
is a bit of a waste of the hardware device's private data pointer,
preventing it from being used for something more useful by the low-level
comedi device drivers.  For example, it would make more sense if
comedi_usb_auto_config() was passed a pointer to the struct
usb_interface instead of the struct usb_device, but this cannot be done
currently because the low-level comedi drivers already use the private
data pointer in the struct usb_interface for something more useful.

This patch stops the comedi core hijacking the hardware device's private
data pointer.  Instead, comedi_auto_config() stores a pointer to the
hardware device's struct device in the struct comedi_device_file_info
associated with the minor device number, and comedi_auto_unconfig()
calls new function comedi_find_board_minor() to recover the minor device
number associated with the hardware device.

Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Revert "drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13"</title>
<updated>2013-01-17T16:44:13Z</updated>
<author>
<name>Daniel Vetter</name>
<email>daniel.vetter@ffwll.ch</email>
</author>
<published>2013-01-07T09:27:13Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f387ee89aca7a06b376c27326afd114fe93e01c2'/>
<id>urn:sha1:f387ee89aca7a06b376c27326afd114fe93e01c2</id>
<content type='text'>
commit 48e858340dae43189a4e55647f6eac736766f828 upstream.

This reverts commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364.

The bogus lvds output is actually a lvds-&gt;hdmi bridge, which we don't
really support. But unconditionally disabling it breaks some existing
setups.

Reported-by: John Tapsell &lt;johnflux@gmail.com&gt;
References: http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/17237
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: Luis Henriques &lt;luis.henriques@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;


</content>
</entry>
<entry>
<title>intel-iommu: Free old page tables before creating superpage</title>
<updated>2013-01-17T16:44:12Z</updated>
<author>
<name>Woodhouse, David</name>
<email>david.woodhouse@intel.com</email>
</author>
<published>2012-12-19T13:25:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5b8692bf7ca5beed9bb75cf97b47dc1d3e5691e2'/>
<id>urn:sha1:5b8692bf7ca5beed9bb75cf97b47dc1d3e5691e2</id>
<content type='text'>
commit 6491d4d02893d9787ba67279595990217177b351 upstream.

The dma_pte_free_pagetable() function will only free a page table page
if it is asked to free the *entire* 2MiB range that it covers. So if a
page table page was used for one or more small mappings, it's likely to
end up still present in the page tables... but with no valid PTEs.

This was fine when we'd only be repopulating it with 4KiB PTEs anyway
but the same virtual address range can end up being reused for a
*large-page* mapping. And in that case were were trying to insert the
large page into the second-level page table, and getting a complaint
from the sanity check in __domain_mapping() because there was already a
corresponding entry. This was *relatively* harmless; it led to a memory
leak of the old page table page, but no other ill-effects.

Fix it by calling dma_pte_clear_range (hopefully redundant) and
dma_pte_free_pagetable() before setting up the new large page.

Signed-off-by: David Woodhouse &lt;David.Woodhouse@intel.com&gt;
Tested-by: Ravi Murty &lt;Ravi.Murty@intel.com&gt;
Tested-by: Sudeep Dutt &lt;sudeep.dutt@intel.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: CAI Qian &lt;caiqian@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xhci: Handle HS bulk/ctrl endpoints that don't NAK.</title>
<updated>2013-01-17T16:44:12Z</updated>
<author>
<name>Sarah Sharp</name>
<email>sarah.a.sharp@linux.intel.com</email>
</author>
<published>2012-12-17T22:12:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=961161c905e212ed2510fb0612549a3d1aefb495'/>
<id>urn:sha1:961161c905e212ed2510fb0612549a3d1aefb495</id>
<content type='text'>
commit 55c1945edaac94c5338a3647bc2e85ff75d9cf36 upstream.

A high speed control or bulk endpoint may have bInterval set to zero,
which means it does not NAK.  If bInterval is non-zero, it means the
endpoint NAKs at a rate of 2^(bInterval - 1).

The xHCI code to compute the NAK interval does not handle the special
case of zero properly.  The current code unconditionally subtracts one
from bInterval and uses it as an exponent.  This causes a very large
bInterval to be used, and warning messages like these will be printed:

usb 1-1: ep 0x1 - rounding interval to 32768 microframes, ep desc says 0 microframes

This may cause the xHCI host hardware to reject the Configure Endpoint
command, which means the HS device will be unusable under xHCI ports.

This patch should be backported to kernels as old as 2.6.31, that contain
commit dfa49c4ad120a784ef1ff0717168aa79f55a483a "USB: xhci - fix math in
xhci_get_endpoint_interval()".

Reported-by: Vincent Pelletier &lt;plr.vincent@gmail.com&gt;
Suggested-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: hub: handle claim of enabled remote wakeup after reset</title>
<updated>2013-01-17T16:44:12Z</updated>
<author>
<name>Oliver Neukum</name>
<email>oliver@neukum.org</email>
</author>
<published>2012-11-29T14:05:57Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b30765e89105c321ed5a5259dc6b05752cbc8137'/>
<id>urn:sha1:b30765e89105c321ed5a5259dc6b05752cbc8137</id>
<content type='text'>
commit 07e72b95f5038cc82304b9a4a2eb7f9fc391ea68 upstream.

Some touchscreens have buggy firmware which claims
remote wakeup to be enabled after a reset. They nevertheless
crash if the feature is cleared by the host.
Add a check for reset resume before checking for
an enabled remote wakeup feature. On compliant
devices the feature must be cleared after a reset anyway.

Signed-off-by: Oliver Neukum &lt;oneukum@suse.de&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: Increase reset timeout.</title>
<updated>2013-01-17T16:44:12Z</updated>
<author>
<name>Sarah Sharp</name>
<email>sarah.a.sharp@linux.intel.com</email>
</author>
<published>2012-11-15T01:16:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e16e202710af9cc74b01c60ea1e338e3e954e6ed'/>
<id>urn:sha1:e16e202710af9cc74b01c60ea1e338e3e954e6ed</id>
<content type='text'>
commit 77c7f072c87fa951e9a74805febf26466f31170c upstream.

John's NEC 0.96 xHCI host controller needs a longer timeout for a warm
reset to complete.  The logs show it takes 650ms to complete the warm
reset, so extend the hub reset timeout to 800ms to be on the safe side.

This commit should be backported to kernels as old as 3.2, that contain
the commit 75d7cf72ab9fa01dc70877aa5c68e8ef477229dc "usbcore: refine
warm reset logic".

Signed-off-by: Sarah Sharp &lt;sarah.a.sharp@linux.intel.com&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Reported-by: John Covici &lt;covici@ccs.covici.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: gadget: dummy: fix enumeration with g_multi</title>
<updated>2013-01-17T16:44:12Z</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2012-11-20T12:23:15Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=fca884e203ab0faf0e505f10d302ee0a2ffb54c7'/>
<id>urn:sha1:fca884e203ab0faf0e505f10d302ee0a2ffb54c7</id>
<content type='text'>
commit 1d16638e3b9cc195bac18a8fcbca748f33c1bc24 upstream.

If we do have endpoints named like "ep-a" then bEndpointAddress is
counted internally by the gadget framework.

If we do have endpoints named like "ep-1" then bEndpointAddress is
assigned from the digit after "ep-".

If we do have both, then it is likely that after we used up the
"generic" endpoints we will use the digits and thus assign one
bEndpointAddress to multiple endpoints.

This theory can be proofed by using the completely enabled g_multi.
Without this patch, the mass storage won't enumerate and times out
because it shares endpoints with RNDIS.

This patch also adds fills up the endpoints list so we have in total
endpoints 1 to 15 in + out available while some of them are restricted
to certain types like BULK or ISO. Without this change the nokia gadget
won't load because the system does not provide enough (BULK) endpoints
but it did before ep-a - ep-f were removed.

Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Acked-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Felipe Balbi &lt;balbi@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: cdc-acm: Add support for "PSC Scanning, Magellan 800i"</title>
<updated>2013-01-17T16:44:12Z</updated>
<author>
<name>Denis N Ladin</name>
<email>denladin@gmail.com</email>
</author>
<published>2012-12-26T13:29:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6d9a5f52d4604191d62f51b58ab7fd2320931f53'/>
<id>urn:sha1:6d9a5f52d4604191d62f51b58ab7fd2320931f53</id>
<content type='text'>
commit 036915a7a402753c05b8d0529f5fd08805ab46d0 upstream.

Adding support "PSC Scanning, Magellan 800i" in cdc-acm

Very simple, but very necessary.
Suitable for all versions of the kernel &gt; 2.6

Signed-off-by: Denis N Ladin &lt;denladin@gmail.com&gt;
Acked-by: Oliver Neukum &lt;oneukum@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: ftdi_sio: Crucible Technologies COMET Caller ID - pid added</title>
<updated>2013-01-17T16:44:12Z</updated>
<author>
<name>Tomasz Mloduchowski</name>
<email>q@qdot.me</email>
</author>
<published>2013-01-13T22:32:53Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=edce154f05d0c7e474e01c833d4c3522987fa125'/>
<id>urn:sha1:edce154f05d0c7e474e01c833d4c3522987fa125</id>
<content type='text'>
commit 8cf65dc386f3634a43312f436cc7a935476a40c4 upstream.

Simple fix to add support for Crucible Technologies COMET Caller ID
USB decoder - a device containing FTDI USB/Serial converter chip,
handling 1200bps CallerID messages decoded from the phone line -
adding correct USB PID is sufficient.

Tested to apply cleanly and work flawlessly against 3.6.9, 3.7.0-rc8
and 3.8.0-rc3 on both amd64 and x86 arches.

Signed-off-by: Tomasz Mloduchowski &lt;q@qdot.me&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
</feed>
