<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers, branch v4.5.6</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>Revert "scsi: fix soft lockup in scsi_remove_target() on module removal"</title>
<updated>2016-06-01T19:17:03+00:00</updated>
<author>
<name>Johannes Thumshirn</name>
<email>jthumshirn@suse.de</email>
</author>
<published>2016-04-05T09:50:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a128141350f9c4108e5a27021729e589e5239daf'/>
<id>a128141350f9c4108e5a27021729e589e5239daf</id>
<content type='text'>
commit 305c2e71b3d733ec065cb716c76af7d554bd5571 upstream.

Now that we've done a more comprehensive fix with the intermediate
target state we can remove the previous hack introduced with commit
90a88d6ef88e ("scsi: fix soft lockup in scsi_remove_target() on module
removal").

Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@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 305c2e71b3d733ec065cb716c76af7d554bd5571 upstream.

Now that we've done a more comprehensive fix with the intermediate
target state we can remove the previous hack introduced with commit
90a88d6ef88e ("scsi: fix soft lockup in scsi_remove_target() on module
removal").

Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>scsi: Add intermediate STARGET_REMOVE state to scsi_target_state</title>
<updated>2016-06-01T19:17:03+00:00</updated>
<author>
<name>Johannes Thumshirn</name>
<email>jthumshirn@suse.de</email>
</author>
<published>2016-04-05T09:50:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1b8acb9b02d8e3423ebb6af619508b7ee9c23900'/>
<id>1b8acb9b02d8e3423ebb6af619508b7ee9c23900</id>
<content type='text'>
commit f05795d3d771f30a7bdc3a138bf714b06d42aa95 upstream.

Add intermediate STARGET_REMOVE state to scsi_target_state to avoid
running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE
state is only valid in the path from scsi_remove_target() to
scsi_target_destroy() indicating this target is going to be removed.

This re-fixes the problem introduced in commits bc3f02a795d3 ("[SCSI]
scsi_remove_target: fix softlockup regression on hot remove") and
40998193560d ("scsi: restart list search after unlock in
scsi_remove_target") in a more comprehensive way.

[mkp: Included James' fix for scsi_target_destroy()]

Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Fixes: 40998193560dab6c3ce8d25f4fa58a23e252ef38
Reported-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Tested-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: James Bottomley &lt;jejb@linux.vnet.ibm.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@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 f05795d3d771f30a7bdc3a138bf714b06d42aa95 upstream.

Add intermediate STARGET_REMOVE state to scsi_target_state to avoid
running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE
state is only valid in the path from scsi_remove_target() to
scsi_target_destroy() indicating this target is going to be removed.

This re-fixes the problem introduced in commits bc3f02a795d3 ("[SCSI]
scsi_remove_target: fix softlockup regression on hot remove") and
40998193560d ("scsi: restart list search after unlock in
scsi_remove_target") in a more comprehensive way.

[mkp: Included James' fix for scsi_target_destroy()]

Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Fixes: 40998193560dab6c3ce8d25f4fa58a23e252ef38
Reported-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Tested-by: Sergey Senozhatsky &lt;sergey.senozhatsky@gmail.com&gt;
Reviewed-by: Ewan D. Milne &lt;emilne@redhat.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Reviewed-by: James Bottomley &lt;jejb@linux.vnet.ibm.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>UBI: Fix static volume checks when Fastmap is used</title>
<updated>2016-06-01T19:17:03+00:00</updated>
<author>
<name>Richard Weinberger</name>
<email>richard@nod.at</email>
</author>
<published>2016-04-26T14:39:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a8a54a05a733c2290cc0b6bc9fad36069cf3cd12'/>
<id>a8a54a05a733c2290cc0b6bc9fad36069cf3cd12</id>
<content type='text'>
commit 1900149c835ab5b48bea31a823ea5e5a401fb560 upstream.

Ezequiel reported that he's facing UBI going into read-only
mode after power cut. It turned out that this behavior happens
only when updating a static volume is interrupted and Fastmap is
used.

A possible trace can look like:
ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes
ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode
CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4
Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012
0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841
ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6
ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0
Call Trace:
[&lt;ffffffff8140d841&gt;] dump_stack+0x63/0x82
[&lt;ffffffffa003abf6&gt;] ubi_eba_read_leb+0x486/0x4a0 [ubi]
[&lt;ffffffffa00453b3&gt;] ubi_check_volume+0x83/0xf0 [ubi]
[&lt;ffffffffa0039d97&gt;] ubi_open_volume+0x177/0x350 [ubi]
[&lt;ffffffffa00375d8&gt;] vol_cdev_open+0x58/0xb0 [ubi]
[&lt;ffffffff8124b08e&gt;] chrdev_open+0xae/0x1d0
[&lt;ffffffff81243bcf&gt;] do_dentry_open+0x1ff/0x300
[&lt;ffffffff8124afe0&gt;] ? cdev_put+0x30/0x30
[&lt;ffffffff81244d36&gt;] vfs_open+0x56/0x60
[&lt;ffffffff812545f4&gt;] path_openat+0x4f4/0x1190
[&lt;ffffffff81256621&gt;] do_filp_open+0x91/0x100
[&lt;ffffffff81263547&gt;] ? __alloc_fd+0xc7/0x190
[&lt;ffffffff812450df&gt;] do_sys_open+0x13f/0x210
[&lt;ffffffff812451ce&gt;] SyS_open+0x1e/0x20
[&lt;ffffffff81a99e32&gt;] entry_SYSCALL_64_fastpath+0x1a/0xa4

UBI checks static volumes for data consistency and reads the
whole volume upon first open. If the volume is found erroneous
users of UBI cannot read from it, but another volume update is
possible to fix it. The check is performed by running
ubi_eba_read_leb() on every allocated LEB of the volume.
For static volumes ubi_eba_read_leb() computes the checksum of all
data stored in a LEB. To verify the computed checksum it has to read
the LEB's volume header which stores the original checksum.
If the volume header is not found UBI treats this as fatal internal
error and switches to RO mode. If the UBI device was attached via a
full scan the assumption is correct, the volume header has to be
present as it had to be there while scanning to get known as mapped.
If the attach operation happened via Fastmap the assumption is no
longer correct. When attaching via Fastmap UBI learns the mapping
table from Fastmap's snapshot of the system state and not via a full
scan. It can happen that a LEB got unmapped after a Fastmap was
written to the flash. Then UBI can learn the LEB still as mapped and
accessing it returns only 0xFF bytes. As UBI is not a FTL it is
allowed to have mappings to empty PEBs, it assumes that the layer
above takes care of LEB accounting and referencing.
UBIFS does so using the LEB property tree (LPT).
For static volumes UBI blindly assumes that all LEBs are present and
therefore special actions have to be taken.

The described situation can happen when updating a static volume is
interrupted, either by a user or a power cut.
The volume update code first unmaps all LEBs of a volume and then
writes LEB by LEB. If the sequence of operations is interrupted UBI
detects this either by the absence of LEBs, no volume header present
at scan time, or corrupted payload, detected via checksum.
In the Fastmap case the former method won't trigger as no scan
happened and UBI automatically thinks all LEBs are present.
Only by reading data from a LEB it detects that the volume header is
missing and incorrectly treats this as fatal error.
To deal with the situation ubi_eba_read_leb() from now on checks
whether we attached via Fastmap and handles the absence of a
volume header like a data corruption error.
This way interrupted static volume updates will correctly get detected
also when Fastmap is used.

Reported-by: Ezequiel Garcia &lt;ezequiel@vanguardiasur.com.ar&gt;
Tested-by: Ezequiel Garcia &lt;ezequiel@vanguardiasur.com.ar&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&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 1900149c835ab5b48bea31a823ea5e5a401fb560 upstream.

Ezequiel reported that he's facing UBI going into read-only
mode after power cut. It turned out that this behavior happens
only when updating a static volume is interrupted and Fastmap is
used.

A possible trace can look like:
ubi0 warning: ubi_io_read_vid_hdr [ubi]: no VID header found at PEB 2323, only 0xFF bytes
ubi0 warning: ubi_eba_read_leb [ubi]: switch to read-only mode
CPU: 0 PID: 833 Comm: ubiupdatevol Not tainted 4.6.0-rc2-ARCH #4
Hardware name: SAMSUNG ELECTRONICS CO., LTD. 300E4C/300E5C/300E7C/NP300E5C-AD8AR, BIOS P04RAP 10/15/2012
0000000000000286 00000000eba949bd ffff8800c45a7b38 ffffffff8140d841
ffff8801964be000 ffff88018eaa4800 ffff8800c45a7bb8 ffffffffa003abf6
ffffffff850e2ac0 8000000000000163 ffff8801850e2ac0 ffff8801850e2ac0
Call Trace:
[&lt;ffffffff8140d841&gt;] dump_stack+0x63/0x82
[&lt;ffffffffa003abf6&gt;] ubi_eba_read_leb+0x486/0x4a0 [ubi]
[&lt;ffffffffa00453b3&gt;] ubi_check_volume+0x83/0xf0 [ubi]
[&lt;ffffffffa0039d97&gt;] ubi_open_volume+0x177/0x350 [ubi]
[&lt;ffffffffa00375d8&gt;] vol_cdev_open+0x58/0xb0 [ubi]
[&lt;ffffffff8124b08e&gt;] chrdev_open+0xae/0x1d0
[&lt;ffffffff81243bcf&gt;] do_dentry_open+0x1ff/0x300
[&lt;ffffffff8124afe0&gt;] ? cdev_put+0x30/0x30
[&lt;ffffffff81244d36&gt;] vfs_open+0x56/0x60
[&lt;ffffffff812545f4&gt;] path_openat+0x4f4/0x1190
[&lt;ffffffff81256621&gt;] do_filp_open+0x91/0x100
[&lt;ffffffff81263547&gt;] ? __alloc_fd+0xc7/0x190
[&lt;ffffffff812450df&gt;] do_sys_open+0x13f/0x210
[&lt;ffffffff812451ce&gt;] SyS_open+0x1e/0x20
[&lt;ffffffff81a99e32&gt;] entry_SYSCALL_64_fastpath+0x1a/0xa4

UBI checks static volumes for data consistency and reads the
whole volume upon first open. If the volume is found erroneous
users of UBI cannot read from it, but another volume update is
possible to fix it. The check is performed by running
ubi_eba_read_leb() on every allocated LEB of the volume.
For static volumes ubi_eba_read_leb() computes the checksum of all
data stored in a LEB. To verify the computed checksum it has to read
the LEB's volume header which stores the original checksum.
If the volume header is not found UBI treats this as fatal internal
error and switches to RO mode. If the UBI device was attached via a
full scan the assumption is correct, the volume header has to be
present as it had to be there while scanning to get known as mapped.
If the attach operation happened via Fastmap the assumption is no
longer correct. When attaching via Fastmap UBI learns the mapping
table from Fastmap's snapshot of the system state and not via a full
scan. It can happen that a LEB got unmapped after a Fastmap was
written to the flash. Then UBI can learn the LEB still as mapped and
accessing it returns only 0xFF bytes. As UBI is not a FTL it is
allowed to have mappings to empty PEBs, it assumes that the layer
above takes care of LEB accounting and referencing.
UBIFS does so using the LEB property tree (LPT).
For static volumes UBI blindly assumes that all LEBs are present and
therefore special actions have to be taken.

The described situation can happen when updating a static volume is
interrupted, either by a user or a power cut.
The volume update code first unmaps all LEBs of a volume and then
writes LEB by LEB. If the sequence of operations is interrupted UBI
detects this either by the absence of LEBs, no volume header present
at scan time, or corrupted payload, detected via checksum.
In the Fastmap case the former method won't trigger as no scan
happened and UBI automatically thinks all LEBs are present.
Only by reading data from a LEB it detects that the volume header is
missing and incorrectly treats this as fatal error.
To deal with the situation ubi_eba_read_leb() from now on checks
whether we attached via Fastmap and handles the absence of a
volume header like a data corruption error.
This way interrupted static volume updates will correctly get detected
also when Fastmap is used.

Reported-by: Ezequiel Garcia &lt;ezequiel@vanguardiasur.com.ar&gt;
Tested-by: Ezequiel Garcia &lt;ezequiel@vanguardiasur.com.ar&gt;
Signed-off-by: Richard Weinberger &lt;richard@nod.at&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>thunderbolt: Fix double free of drom buffer</title>
<updated>2016-06-01T19:17:03+00:00</updated>
<author>
<name>Andreas Noever</name>
<email>andreas.noever@gmail.com</email>
</author>
<published>2016-04-10T10:48:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=11d853be8ade548d68241ca2342addf1514c4b18'/>
<id>11d853be8ade548d68241ca2342addf1514c4b18</id>
<content type='text'>
commit 2ffa9a5d76a75abbc1f95c17959fced666095bdd upstream.

If tb_drom_read() fails, sw-&gt;drom is freed but not set to NULL.  sw-&gt;drom
is then freed again in the error path of tb_switch_alloc().

The bug can be triggered by unplugging a thunderbolt device shortly after
it is detected by the thunderbolt driver.

Clear sw-&gt;drom if tb_drom_read() fails.

[bhelgaas: add Fixes:, stable versions of interest]
Fixes: 343fcb8c70d7 ("thunderbolt: Fix nontrivial endpoint devices.")
Signed-off-by: Andreas Noever &lt;andreas.noever@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: Lukas Wunner &lt;lukas@wunner.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 2ffa9a5d76a75abbc1f95c17959fced666095bdd upstream.

If tb_drom_read() fails, sw-&gt;drom is freed but not set to NULL.  sw-&gt;drom
is then freed again in the error path of tb_switch_alloc().

The bug can be triggered by unplugging a thunderbolt device shortly after
it is detected by the thunderbolt driver.

Clear sw-&gt;drom if tb_drom_read() fails.

[bhelgaas: add Fixes:, stable versions of interest]
Fixes: 343fcb8c70d7 ("thunderbolt: Fix nontrivial endpoint devices.")
Signed-off-by: Andreas Noever &lt;andreas.noever@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>IB/srp: Fix a debug kernel crash</title>
<updated>2016-06-01T19:17:03+00:00</updated>
<author>
<name>Bart Van Assche</name>
<email>bart.vanassche@sandisk.com</email>
</author>
<published>2016-04-12T21:39:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f131e8e07c4ff651a4a2508b9f2cc3a52708b9ab'/>
<id>f131e8e07c4ff651a4a2508b9f2cc3a52708b9ab</id>
<content type='text'>
commit 54f5c9c52d69afa55abf2b034df8d45f588466c3 upstream.

Avoid that the following BUG() is triggered against a debug
kernel:

kernel BUG at include/linux/scatterlist.h:92!
RIP: 0010:[&lt;ffffffffa0467199&gt;]  [&lt;ffffffffa0467199&gt;] srp_map_idb+0x199/0x1a0 [ib_srp]
Call Trace:
 [&lt;ffffffffa04685fa&gt;] srp_map_data+0x84a/0x890 [ib_srp]
 [&lt;ffffffffa0469674&gt;] srp_queuecommand+0x1e4/0x610 [ib_srp]
 [&lt;ffffffff813f5a5e&gt;] scsi_dispatch_cmd+0x9e/0x180
 [&lt;ffffffff813f8b07&gt;] scsi_request_fn+0x477/0x610
 [&lt;ffffffff81298ffe&gt;] __blk_run_queue+0x2e/0x40
 [&lt;ffffffff81299070&gt;] blk_delay_work+0x20/0x30
 [&lt;ffffffff81071f07&gt;] process_one_work+0x197/0x480
 [&lt;ffffffff81072239&gt;] worker_thread+0x49/0x490
 [&lt;ffffffff810787ea&gt;] kthread+0xea/0x100
 [&lt;ffffffff8159b632&gt;] ret_from_fork+0x22/0x40

Fixes: f7f7aab1a5c0 ("IB/srp: Convert to new registration API")
Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Doug Ledford &lt;dledford@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 54f5c9c52d69afa55abf2b034df8d45f588466c3 upstream.

Avoid that the following BUG() is triggered against a debug
kernel:

kernel BUG at include/linux/scatterlist.h:92!
RIP: 0010:[&lt;ffffffffa0467199&gt;]  [&lt;ffffffffa0467199&gt;] srp_map_idb+0x199/0x1a0 [ib_srp]
Call Trace:
 [&lt;ffffffffa04685fa&gt;] srp_map_data+0x84a/0x890 [ib_srp]
 [&lt;ffffffffa0469674&gt;] srp_queuecommand+0x1e4/0x610 [ib_srp]
 [&lt;ffffffff813f5a5e&gt;] scsi_dispatch_cmd+0x9e/0x180
 [&lt;ffffffff813f8b07&gt;] scsi_request_fn+0x477/0x610
 [&lt;ffffffff81298ffe&gt;] __blk_run_queue+0x2e/0x40
 [&lt;ffffffff81299070&gt;] blk_delay_work+0x20/0x30
 [&lt;ffffffff81071f07&gt;] process_one_work+0x197/0x480
 [&lt;ffffffff81072239&gt;] worker_thread+0x49/0x490
 [&lt;ffffffff810787ea&gt;] kthread+0xea/0x100
 [&lt;ffffffff8159b632&gt;] ret_from_fork+0x22/0x40

Fixes: f7f7aab1a5c0 ("IB/srp: Convert to new registration API")
Signed-off-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Cc: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Cc: Christoph Hellwig &lt;hch@lst.de&gt;
Reviewed-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Reviewed-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Signed-off-by: Doug Ledford &lt;dledford@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>mcb: Fixed bar number assignment for the gdd</title>
<updated>2016-06-01T19:17:02+00:00</updated>
<author>
<name>Andreas Werner</name>
<email>andreas.werner@men.de</email>
</author>
<published>2016-05-03T10:42:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a2cdcb8296b549b250396d5056ddc28672b3db6f'/>
<id>a2cdcb8296b549b250396d5056ddc28672b3db6f</id>
<content type='text'>
commit f75564d343010b025301d9548f2304f48eb25f01 upstream.

The bar number is found in reg2 within the gdd. Therefore
we need to change the assigment from reg1 to reg2 which
is the correct location.

Signed-off-by: Andreas Werner &lt;andreas.werner@men.de&gt;
Fixes: '3764e82e5' drivers: Introduce MEN Chameleon Bus
Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.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 f75564d343010b025301d9548f2304f48eb25f01 upstream.

The bar number is found in reg2 within the gdd. Therefore
we need to change the assigment from reg1 to reg2 which
is the correct location.

Signed-off-by: Andreas Werner &lt;andreas.werner@men.de&gt;
Fixes: '3764e82e5' drivers: Introduce MEN Chameleon Bus
Signed-off-by: Johannes Thumshirn &lt;jthumshirn@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>watchdog: sp5100_tco: properly check for new register layouts</title>
<updated>2016-06-01T19:17:02+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>dev@lynxeye.de</email>
</author>
<published>2016-05-03T17:15:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e0a343f02800b9a7b6990a8891483f8a16b7dbef'/>
<id>e0a343f02800b9a7b6990a8891483f8a16b7dbef</id>
<content type='text'>
commit 46856fabe40cc80f92134683cdec7dc0fc8f4000 upstream.

Commits 190aa4304de6 (Add AMD Mullins platform support) and
cca118fa2a0a94 (Add AMD Carrizo platform support) enabled the
driver on a lot more devices, but the following commit missed
a single location in the code when checking if the SB800 register
offsets should be used. This leads to the wrong register being
written which in turn causes ACPI to go haywire.

Fix this by introducing a helper function to check for the new
register layout and use this consistently.

https://bugzilla.kernel.org/show_bug.cgi?id=114201
https://bugzilla.redhat.com/show_bug.cgi?id=1329910
Fixes: bdecfcdb5461 (sp5100_tco: fix the device check for SB800
and later chipsets)
Signed-off-by: Lucas Stach &lt;dev@lynxeye.de&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Wim Van Sebroeck &lt;wim@iguana.be&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 46856fabe40cc80f92134683cdec7dc0fc8f4000 upstream.

Commits 190aa4304de6 (Add AMD Mullins platform support) and
cca118fa2a0a94 (Add AMD Carrizo platform support) enabled the
driver on a lot more devices, but the following commit missed
a single location in the code when checking if the SB800 register
offsets should be used. This leads to the wrong register being
written which in turn causes ACPI to go haywire.

Fix this by introducing a helper function to check for the new
register layout and use this consistently.

https://bugzilla.kernel.org/show_bug.cgi?id=114201
https://bugzilla.redhat.com/show_bug.cgi?id=1329910
Fixes: bdecfcdb5461 (sp5100_tco: fix the device check for SB800
and later chipsets)
Signed-off-by: Lucas Stach &lt;dev@lynxeye.de&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Wim Van Sebroeck &lt;wim@iguana.be&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>clk: bcm2835: add locking to pll*_on/off methods</title>
<updated>2016-06-01T19:17:02+00:00</updated>
<author>
<name>Martin Sperl</name>
<email>kernel@martin.sperl.org</email>
</author>
<published>2016-02-29T11:39:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=93900a7af2cd2288b5f0d209d467350beede9cf6'/>
<id>93900a7af2cd2288b5f0d209d467350beede9cf6</id>
<content type='text'>
commit ec36a5c6682fdd5328abf15c3c67281bed0241d7 upstream.

Add missing locking to:
* bcm2835_pll_divider_on
* bcm2835_pll_divider_off
to protect the read modify write cycle for the
register access protecting both cm_reg and a2w_reg
registers.

Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the
audio domain clocks")

Signed-off-by: Martin Sperl &lt;kernel@martin.sperl.org&gt;
Signed-off-by: Eric Anholt &lt;eric@anholt.net&gt;
Reviewed-by: Eric Anholt &lt;eric@anholt.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 ec36a5c6682fdd5328abf15c3c67281bed0241d7 upstream.

Add missing locking to:
* bcm2835_pll_divider_on
* bcm2835_pll_divider_off
to protect the read modify write cycle for the
register access protecting both cm_reg and a2w_reg
registers.

Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the
audio domain clocks")

Signed-off-by: Martin Sperl &lt;kernel@martin.sperl.org&gt;
Signed-off-by: Eric Anholt &lt;eric@anholt.net&gt;
Reviewed-by: Eric Anholt &lt;eric@anholt.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: samsung: Reorder the sequence of clock control when call s3c24xx_serial_set_termios()</title>
<updated>2016-06-01T19:17:02+00:00</updated>
<author>
<name>Chanwoo Choi</name>
<email>cw00.choi@samsung.com</email>
</author>
<published>2016-04-21T09:58:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5637fc0d84fc4dd499b4f59ea2390175ca154906'/>
<id>5637fc0d84fc4dd499b4f59ea2390175ca154906</id>
<content type='text'>
commit b8995f527aac143e83d3900ff39357651ea4e0f6 upstream.

This patch fixes the broken serial log when changing the clock source
of uart device. Before disabling the original clock source, this patch
enables the new clock source to protect the clock off state for a split second.

Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Reviewed-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b8995f527aac143e83d3900ff39357651ea4e0f6 upstream.

This patch fixes the broken serial log when changing the clock source
of uart device. Before disabling the original clock source, this patch
enables the new clock source to protect the clock off state for a split second.

Signed-off-by: Chanwoo Choi &lt;cw00.choi@samsung.com&gt;
Reviewed-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>serial: 8250_mid: recognize interrupt source in handler</title>
<updated>2016-06-01T19:17:02+00:00</updated>
<author>
<name>Andy Shevchenko</name>
<email>andriy.shevchenko@linux.intel.com</email>
</author>
<published>2016-04-04T14:35:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=33414f17f85d037ec4b1033391aa6b48dfcaa560'/>
<id>33414f17f85d037ec4b1033391aa6b48dfcaa560</id>
<content type='text'>
commit c42850f1ae7e70056f852e67bb9dddf927853b47 upstream.

There is a special register that shows interrupt status by source. In
particular case the source can be a combination of DMA Tx, DMA Rx, and UART.

Read the register and call the handlers only for sources that request an
interrupt.

Fixes: 6ede6dcd87aa ("serial: 8250_mid: add support for DMA engine handling from UART MMIO")
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
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>
commit c42850f1ae7e70056f852e67bb9dddf927853b47 upstream.

There is a special register that shows interrupt status by source. In
particular case the source can be a combination of DMA Tx, DMA Rx, and UART.

Read the register and call the handlers only for sources that request an
interrupt.

Fixes: 6ede6dcd87aa ("serial: 8250_mid: add support for DMA engine handling from UART MMIO")
Reviewed-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
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>
</feed>
