<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers, branch v3.0.51</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers?h=v3.0.51</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers?h=v3.0.51'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-11-05T08:44:26Z</updated>
<entry>
<title>drm/nouveau: silence modesetting spam on pre-gf8 chipsets</title>
<updated>2012-11-05T08:44:26Z</updated>
<author>
<name>Ben Skeggs</name>
<email>bskeggs@redhat.com</email>
</author>
<published>2012-10-28T23:03:07Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a8a0b23d89dc38d1fc33297924edc50de09250da'/>
<id>urn:sha1:a8a0b23d89dc38d1fc33297924edc50de09250da</id>
<content type='text'>
commit cee59f15a60cc6269a25e3f6fbf1a577d6ab8115 upstream.

Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86: Remove the ancient and deprecated disable_hlt() and enable_hlt() facility</title>
<updated>2012-11-05T08:44:26Z</updated>
<author>
<name>Len Brown</name>
<email>len.brown@intel.com</email>
</author>
<published>2012-03-29T21:49:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=05e02741ed77cace45997d4a7d4092f5ac84e19a'/>
<id>urn:sha1:05e02741ed77cace45997d4a7d4092f5ac84e19a</id>
<content type='text'>
commit f6365201d8a21fb347260f89d6e9b3e718d63c70 upstream.

The X86_32-only disable_hlt/enable_hlt mechanism was used by the
32-bit floppy driver. Its effect was to replace the use of the
HLT instruction inside default_idle() with cpu_relax() - essentially
it turned off the use of HLT.

This workaround was commented in the code as:

 "disable hlt during certain critical i/o operations"

 "This halt magic was a workaround for ancient floppy DMA
  wreckage. It should be safe to remove."

H. Peter Anvin additionally adds:

 "To the best of my knowledge, no-hlt only existed because of
  flaky power distributions on 386/486 systems which were sold to
  run DOS.  Since DOS did no power management of any kind,
  including HLT, the power draw was fairly uniform; when exposed
  to the much hhigher noise levels you got when Linux used HLT
  caused some of these systems to fail.

  They were by far in the minority even back then."

Alan Cox further says:

 "Also for the Cyrix 5510 which tended to go castors up if a HLT
  occurred during a DMA cycle and on a few other boxes HLT during
  DMA tended to go astray.

  Do we care ? I doubt it. The 5510 was pretty obscure, the 5520
  fixed it, the 5530 is probably the oldest still in any kind of
  use."

So, let's finally drop this.

Signed-off-by: Len Brown &lt;len.brown@intel.com&gt;
Signed-off-by: Josh Boyer &lt;jwboyer@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Acked-by: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Acked-by: Alan Cox &lt;alan@lxorguk.ukuu.org.uk&gt;
Cc: Stephen Hemminger &lt;shemminger@vyatta.com
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Link: http://lkml.kernel.org/n/tip-3rhk9bzf0x9rljkv488tloib@git.kernel.org
[ If anyone cares then alternative instruction patching could be
  used to replace HLT with a one-byte NOP instruction. Much simpler. ]
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>floppy: do put_disk on current dr if blk_init_queue fails</title>
<updated>2012-11-05T08:44:25Z</updated>
<author>
<name>Herton Ronaldo Krzesinski</name>
<email>herton.krzesinski@canonical.com</email>
</author>
<published>2012-08-27T23:56:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2000afe4fb86c374650371f41eb287746790d9ff'/>
<id>urn:sha1:2000afe4fb86c374650371f41eb287746790d9ff</id>
<content type='text'>
commit 238ab78469c6ab7845b43d5061cd3c92331b2452 upstream.

If blk_init_queue fails, we do not call put_disk on the current dr
(dr is decremented first in the error handling loop).

Reviewed-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: Herton Ronaldo Krzesinski &lt;herton.krzesinski@canonical.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: no lvds quirk for Zotac ZDBOX SD ID12/ID13</title>
<updated>2012-10-31T16:51:48Z</updated>
<author>
<name>Sjoerd Simons</name>
<email>sjoerd.simons@collabora.co.uk</email>
</author>
<published>2012-06-22T07:43:07Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ba90d99d5626c2dd2bb97336fd14c94b1a21eca1'/>
<id>urn:sha1:ba90d99d5626c2dd2bb97336fd14c94b1a21eca1</id>
<content type='text'>
commit 9756fe38d10b2bf90c81dc4d2f17d5632e135364 upstream.

This box claims to have an LVDS interface but doesn't
actually have one.

Signed-off-by: Sjoerd Simons &lt;sjoerd.simons@collabora.co.uk&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>staging: comedi: amplc_pc236: fix invalid register access during detach</title>
<updated>2012-10-31T16:51:42Z</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2012-10-03T15:25:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5a30fddcc9593086c26cef6496f757e262059cf6'/>
<id>urn:sha1:5a30fddcc9593086c26cef6496f757e262059cf6</id>
<content type='text'>
commit aaeb61a97b7159ebe30b18a422d04eeabfa8790b upstream.

`pc236_detach()` is called by the comedi core if it attempted to attach
a device and failed.  `pc236_detach()` calls `pc236_intr_disable()` if
the comedi device private data pointer (`devpriv`) is non-null.  This
test is insufficient as `pc236_intr_disable()` accesses hardware
registers and the attach routine may have failed before it has saved
their I/O base addresses.

Fix it by checking `dev-&gt;iobase` is non-zero before calling
`pc236_intr_disable()` as that means the I/O base addresses have been
saved and the hardware registers can be accessed.  It also implies the
comedi device private data pointer is valid, so there is no need to
check it.

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>cpufreq / powernow-k8: Remove usage of smp_processor_id() in preemptible code</title>
<updated>2012-10-31T16:51:37Z</updated>
<author>
<name>Andreas Herrmann</name>
<email>andreas.herrmann3@amd.com</email>
</author>
<published>2012-10-22T22:55:10Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=eccd54a6c29b2ddce3e03e7f77b89376dd9ee1ca'/>
<id>urn:sha1:eccd54a6c29b2ddce3e03e7f77b89376dd9ee1ca</id>
<content type='text'>
commit e4df1cbcc1f329e53a1fff7450b2229e0addff20 upstream.

Commit 6889125b8b4e09c5e53e6ecab3433bed1ce198c9
(cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU)
causes powernow-k8 to trigger a preempt warning, e.g.:

  BUG: using smp_processor_id() in preemptible [00000000] code: cpufreq/3776
  caller is powernowk8_target+0x20/0x49
  Pid: 3776, comm: cpufreq Not tainted 3.6.0 #9
  Call Trace:
   [&lt;ffffffff8125b447&gt;] debug_smp_processor_id+0xc7/0xe0
   [&lt;ffffffff814877e7&gt;] powernowk8_target+0x20/0x49
   [&lt;ffffffff81482b02&gt;] __cpufreq_driver_target+0x82/0x8a
   [&lt;ffffffff81484fc6&gt;] cpufreq_governor_performance+0x4e/0x54
   [&lt;ffffffff81482c50&gt;] __cpufreq_governor+0x8c/0xc9
   [&lt;ffffffff81482e6f&gt;] __cpufreq_set_policy+0x1a9/0x21e
   [&lt;ffffffff814839af&gt;] store_scaling_governor+0x16f/0x19b
   [&lt;ffffffff81484f16&gt;] ? cpufreq_update_policy+0x124/0x124
   [&lt;ffffffff8162b4a5&gt;] ? _raw_spin_unlock_irqrestore+0x2c/0x49
   [&lt;ffffffff81483640&gt;] store+0x60/0x88
   [&lt;ffffffff811708c0&gt;] sysfs_write_file+0xf4/0x130
   [&lt;ffffffff8111243b&gt;] vfs_write+0xb5/0x151
   [&lt;ffffffff811126e0&gt;] sys_write+0x4a/0x71
   [&lt;ffffffff816319a9&gt;] system_call_fastpath+0x16/0x1b

Fix this by by always using work_on_cpu().

Signed-off-by: Andreas Herrmann &lt;andreas.herrmann3@amd.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>bcma: fix unregistration of cores</title>
<updated>2012-10-31T16:51:37Z</updated>
<author>
<name>Piotr Haber</name>
<email>phaber@broadcom.com</email>
</author>
<published>2012-10-11T12:05:15Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=0ff8913490f238812b4ab9f0b5cf7797f9a08aa7'/>
<id>urn:sha1:0ff8913490f238812b4ab9f0b5cf7797f9a08aa7</id>
<content type='text'>
commit 1fffa905adffbf0d3767fc978ef09afb830275eb upstream.

When cores are unregistered, entries
need to be removed from cores list in a safe manner.

Reported-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Reviewed-by: Arend Van Spriel &lt;arend@broadcom.com&gt;
Signed-off-by: Piotr Haber &lt;phaber@broadcom.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>vhost: fix mergeable bufs on BE hosts</title>
<updated>2012-10-31T16:51:36Z</updated>
<author>
<name>Michael S. Tsirkin</name>
<email>mst@redhat.com</email>
</author>
<published>2012-10-24T18:37:51Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=83dab4684482147564c9f3219f58e45d11765875'/>
<id>urn:sha1:83dab4684482147564c9f3219f58e45d11765875</id>
<content type='text'>
commit 910a578f7e9400a78a3b13aba0b4d2df16a2cb05 upstream.

We copy head count to a 16 bit field, this works by chance on LE but on
BE guest gets 0. Fix it up.

Signed-off-by: Michael S. Tsirkin &lt;mst@redhat.com&gt;
Tested-by: Alexander Graf &lt;agraf@suse.de&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>xhci: Fix potential NULL ptr deref in command cancellation.</title>
<updated>2012-10-31T16:51:36Z</updated>
<author>
<name>Sarah Sharp</name>
<email>sarah.a.sharp@linux.intel.com</email>
</author>
<published>2012-10-16T20:17:43Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=713b9c260ba25938606ab794a1dfc438c727eb2c'/>
<id>urn:sha1:713b9c260ba25938606ab794a1dfc438c727eb2c</id>
<content type='text'>
commit 43a09f7fb01fa1e091416a2aa49b6c666458c1ee upstream.

The command cancellation code doesn't check whether find_trb_seg()
couldn't find the segment that contains the TRB to be canceled.  This
could cause a NULL pointer deference later in the function when next_trb
is called.  It's unlikely to happen unless something is wrong with the
command ring pointers, so add some debugging in case it happens.

This patch should be backported to stable kernels as old as 3.0, that
contain the commit b63f4053cc8aa22a98e3f9a97845afe6c15d0a0d "xHCI:
handle command after aborting the command ring".

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: mos7840: remove invalid disconnect handling</title>
<updated>2012-10-31T16:51:36Z</updated>
<author>
<name>Johan Hovold</name>
<email>jhovold@gmail.com</email>
</author>
<published>2012-10-25T16:56:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=44ddc9a2fa5319e051198bc7fe9aa4b7c12b020f'/>
<id>urn:sha1:44ddc9a2fa5319e051198bc7fe9aa4b7c12b020f</id>
<content type='text'>
commit e681b66f2e19fadbe8a7e2a17900978cb6bc921f upstream.

Remove private zombie flag used to signal disconnect and to prevent
control urb from being submitted from interrupt urb completion handler.

The control urb will not be re-submitted as both the control urb and the
interrupt urb is killed on disconnect.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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