<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v4.14.38</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.38</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.38'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-04-29T09:33:18+00:00</updated>
<entry>
<title>ACPI / video: Only default only_lcd to true on Win8-ready _desktops_</title>
<updated>2018-04-29T09:33:18+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2018-04-17T16:23:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3e4915873cff08e6b02b5807336ef559690ddecf'/>
<id>urn:sha1:3e4915873cff08e6b02b5807336ef559690ddecf</id>
<content type='text'>
commit 53fa1f6e8a5958da698a31edf366ffe90596b490 upstream.

Commit 5928c281524f (ACPI / video: Default lcd_only to true on Win8-ready
and newer machines) made only_lcd default to true on all machines where
acpi_osi_is_win8() returns true, including laptops.

The purpose of this is to avoid the bogus / non-working acpi backlight
interface which many newer BIOS-es define on desktop machines.

But this is causing a regression on some laptops, specifically on the
Dell XPS 13 2013 model, which does not have the LCD flag set for its
fully functional ACPI backlight interface.

Rather then DMI quirking our way out of this, this commits changes the
logic for setting only_lcd to true, to only do this on machines with
a desktop (or server) dmi chassis-type.

Note that we cannot simply only check the chassis-type and not register
the backlight interface based on that as there are some laptops and
tablets which have their chassis-type set to "3" aka desktop. Hopefully
the combination of checking the LCD flag, but only on devices with
a desktop(ish) chassis-type will avoid the needs for DMI quirks for this,
or at least limit the amount of DMI quirks which we need to a minimum.

Fixes: 5928c281524f (ACPI / video: Default lcd_only to true on Win8-ready and newer machines)
Reported-and-tested-by: James Hogan &lt;jhogan@kernel.org&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Cc: 4.15+ &lt;stable@vger.kernel.org&gt; # 4.15+
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>s390/dasd: fix IO error for newly defined devices</title>
<updated>2018-04-29T09:33:18+00:00</updated>
<author>
<name>Stefan Haberland</name>
<email>sth@linux.vnet.ibm.com</email>
</author>
<published>2018-04-12T11:38:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5dad51054d8a72117a8601ccfeb76a1086942bfd'/>
<id>urn:sha1:5dad51054d8a72117a8601ccfeb76a1086942bfd</id>
<content type='text'>
commit 5d27a2bf6e14f5c7d1033ad1e993fcd0eba43e83 upstream.

When a new CKD storage volume is defined at the storage server, Linux
may be relying on outdated information about that volume, which leads to
the following errors:

1. Command Reject Errors for minidisk on z/VM:

dasd-eckd.b3193d: 0.0.XXXX: An error occurred in the DASD device driver,
		  reason=09
dasd(eckd): I/O status report for device 0.0.XXXX:
dasd(eckd): in req: 00000000XXXXXXXX CC:00 FC:04 AC:00 SC:17 DS:02 CS:00
	    RC:0
dasd(eckd): device 0.0.2046: Failing CCW: 00000000XXXXXXXX
dasd(eckd): Sense(hex)  0- 7: 80 00 00 00 00 00 00 00
dasd(eckd): Sense(hex)  8-15: 00 00 00 00 00 00 00 00
dasd(eckd): Sense(hex) 16-23: 00 00 00 00 e1 00 0f 00
dasd(eckd): Sense(hex) 24-31: 00 00 40 e2 00 00 00 00
dasd(eckd): 24 Byte: 0 MSG 0, no MSGb to SYSOP

2. Equipment Check errors on LPAR or for dedicated devices on z/VM:

dasd(eckd): I/O status report for device 0.0.XXXX:
dasd(eckd): in req: 00000000XXXXXXXX CC:00 FC:04 AC:00 SC:17 DS:0E CS:40
	    fcxs:01 schxs:00 RC:0
dasd(eckd): device 0.0.9713: Failing TCW: 00000000XXXXXXXX
dasd(eckd): Sense(hex)  0- 7: 10 00 00 00 13 58 4d 0f
dasd(eckd): Sense(hex)  8-15: 67 00 00 00 00 00 00 04
dasd(eckd): Sense(hex) 16-23: e5 18 05 33 97 01 0f 0f
dasd(eckd): Sense(hex) 24-31: 00 00 40 e2 00 04 58 0d
dasd(eckd): 24 Byte: 0 MSG f, no MSGb to SYSOP

Fix this problem by using the up-to-date information provided during
online processing via the device specific SNEQ to detect the case of
outdated LCU data. If there is a difference, perform a re-read of that
data.

Cc: stable@vger.kernel.org
Reviewed-by: Jan Hoeppner &lt;hoeppner@linux.ibm.com&gt;
Signed-off-by: Stefan Haberland &lt;sth@linux.vnet.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>s390/cio: update chpid descriptor after resource accessibility event</title>
<updated>2018-04-29T09:33:17+00:00</updated>
<author>
<name>Sebastian Ott</name>
<email>sebott@linux.ibm.com</email>
</author>
<published>2018-04-11T09:21:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3b5c2e1d163a500821079938fbfd55afcc82ac55'/>
<id>urn:sha1:3b5c2e1d163a500821079938fbfd55afcc82ac55</id>
<content type='text'>
commit af2e460ade0b0180d0f3812ca4f4f59cc9597f3e upstream.

Channel path descriptors have been seen as something stable (as
long as the chpid is configured). Recent tests have shown that the
descriptor can also be altered when the link state of a channel path
changes. Thus it is necessary to update the descriptor during
handling of resource accessibility events.

Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Sebastian Ott &lt;sebott@linux.ibm.com&gt;
Reviewed-by: Peter Oberparleiter &lt;oberpar@linux.ibm.com&gt;
Signed-off-by: Martin Schwidefsky &lt;schwidefsky@de.ibm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>block/swim: Fix IO error at end of medium</title>
<updated>2018-04-29T09:33:17+00:00</updated>
<author>
<name>Finn Thain</name>
<email>fthain@telegraphics.com.au</email>
</author>
<published>2018-04-12T00:50:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d82923c017deeeec73ce871e742de42935f871cf'/>
<id>urn:sha1:d82923c017deeeec73ce871e742de42935f871cf</id>
<content type='text'>
commit 5a13388d7aa1177b98d7168330ecbeeac52f844d upstream.

Reading to the end of a 720K disk results in an IO error instead of EOF
because the block layer thinks the disk has 2880 sectors. (Partly this
is a result of inverted logic of the ONEMEG_MEDIA bit that's now fixed.)

Initialize the density and head count in swim_add_floppy() to agree
with the device size passed to set_capacity() during drive probe.

Call set_capacity() again upon device open, after refreshing the density
and head count values.

Cc: Laurent Vivier &lt;lvivier@redhat.com&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: stable@vger.kernel.org # v4.14+
Tested-by: Stan Johnson &lt;userm57@yahoo.com&gt;
Signed-off-by: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Acked-by: Laurent Vivier &lt;lvivier@redhat.com&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>block/swim: Fix array bounds check</title>
<updated>2018-04-29T09:33:17+00:00</updated>
<author>
<name>Finn Thain</name>
<email>fthain@telegraphics.com.au</email>
</author>
<published>2018-04-12T00:50:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=06dc2e91959344adafbf34071d8c1d23e719c67d'/>
<id>urn:sha1:06dc2e91959344adafbf34071d8c1d23e719c67d</id>
<content type='text'>
commit 7ae6a2b6cc058005ee3d0d2b9ce27688e51afa4b upstream.

In the floppy_find() function in swim.c is a call to
get_disk(swd-&gt;unit[drive].disk). The actual parameter to this call
can be a NULL pointer when drive == swd-&gt;floppy_count. This causes
an oops in get_disk().

Data read fault at 0x00000198 in Super Data (pc=0x1be5b6)
BAD KERNEL BUSERR
Oops: 00000000
Modules linked in: swim_mod ipv6 mac8390
PC: [&lt;001be5b6&gt;] get_disk+0xc/0x76
SR: 2004  SP: 9a078bc1  a2: 0213ed90
d0: 00000000    d1: 00000000    d2: 00000000    d3: 000000ff
d4: 00000002    d5: 02983590    a0: 02332e00    a1: 022dfd64
Process dd (pid: 285, task=020ab25b)
Frame format=B ssw=074d isc=4a88 isb=6732 daddr=00000198 dobuf=00000000
baddr=001be5bc dibuf=bfffffff ver=f
Stack from 022dfca4:
        00000000 0203fc00 0213ed90 022dfcc0 02982936 00000000 00200000 022dfd08
        0020f85a 00200000 022dfd64 02332e00 004040fc 00000014 001be77e 022dfd64
        00334e4a 001be3f8 0800001d 022dfd64 01c04b60 01c04b70 022aba80 029828f8
        02332e00 022dfd2c 001be7ac 0203fc00 00200000 022dfd64 02103a00 01c04b60
        01c04b60 0200e400 022dfd68 000e191a 00200000 022dfd64 02103a00 0800001d
        00000000 00000003 000b89de 00500000 02103a00 01c04b60 02103a08 01c04c2e
Call Trace: [&lt;02982936&gt;] floppy_find+0x3e/0x4a [swim_mod]
 [&lt;00200000&gt;] uart_remove_one_port+0x1a2/0x260
 [&lt;0020f85a&gt;] kobj_lookup+0xde/0x132
 [&lt;00200000&gt;] uart_remove_one_port+0x1a2/0x260
 [&lt;001be77e&gt;] get_gendisk+0x0/0x130
 [&lt;00334e4a&gt;] mutex_lock+0x0/0x2e
 [&lt;001be3f8&gt;] disk_block_events+0x0/0x6c
 [&lt;029828f8&gt;] floppy_find+0x0/0x4a [swim_mod]
 [&lt;001be7ac&gt;] get_gendisk+0x2e/0x130
 [&lt;00200000&gt;] uart_remove_one_port+0x1a2/0x260
 [&lt;000e191a&gt;] __blkdev_get+0x32/0x45a
 [&lt;00200000&gt;] uart_remove_one_port+0x1a2/0x260
 [&lt;000b89de&gt;] complete_walk+0x0/0x8a
 [&lt;000e1e22&gt;] blkdev_get+0xe0/0x29a
 [&lt;000e1fdc&gt;] blkdev_open+0x0/0xb0
 [&lt;000b89de&gt;] complete_walk+0x0/0x8a
 [&lt;000e1fdc&gt;] blkdev_open+0x0/0xb0
 [&lt;000e01cc&gt;] bd_acquire+0x74/0x8a
 [&lt;000e205c&gt;] blkdev_open+0x80/0xb0
 [&lt;000e1fdc&gt;] blkdev_open+0x0/0xb0
 [&lt;000abf24&gt;] do_dentry_open+0x1a4/0x322
 [&lt;00020000&gt;] __do_proc_douintvec+0x22/0x27e
 [&lt;000b89de&gt;] complete_walk+0x0/0x8a
 [&lt;000baa62&gt;] link_path_walk+0x0/0x48e
 [&lt;000ba3f8&gt;] inode_permission+0x20/0x54
 [&lt;000ac0e4&gt;] vfs_open+0x42/0x78
 [&lt;000bc372&gt;] path_openat+0x2b2/0xeaa
 [&lt;000bc0c0&gt;] path_openat+0x0/0xeaa
 [&lt;0004463e&gt;] __irq_wake_thread+0x0/0x4e
 [&lt;0003a45a&gt;] task_tick_fair+0x18/0xc8
 [&lt;000bd00a&gt;] do_filp_open+0xa0/0xea
 [&lt;000abae0&gt;] do_sys_open+0x11a/0x1ee
 [&lt;00020000&gt;] __do_proc_douintvec+0x22/0x27e
 [&lt;000abbf4&gt;] SyS_open+0x1e/0x22
 [&lt;00020000&gt;] __do_proc_douintvec+0x22/0x27e
 [&lt;00002b40&gt;] syscall+0x8/0xc
 [&lt;00020000&gt;] __do_proc_douintvec+0x22/0x27e
 [&lt;0000c00b&gt;] dyadic+0x1/0x28
Code: 4e5e 4e75 4e56 fffc 2f0b 2f02 266e 0008 &lt;206b&gt; 0198 4a88 6732 2428 002c 661e 486b 0058 4eb9 0032 0b96 588f 4a88 672c 2008
Disabling lock debugging due to kernel taint

Fix the array index bounds check to avoid this.

Cc: Laurent Vivier &lt;lvivier@redhat.com&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: stable@vger.kernel.org # v4.14+
Fixes: 8852ecd97488 ("[PATCH] m68k: mac - Add SWIM floppy support")
Tested-by: Stan Johnson &lt;userm57@yahoo.com&gt;
Signed-off-by: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Acked-by: Laurent Vivier &lt;lvivier@redhat.com&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&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>block/swim: Select appropriate drive on device open</title>
<updated>2018-04-29T09:33:17+00:00</updated>
<author>
<name>Finn Thain</name>
<email>fthain@telegraphics.com.au</email>
</author>
<published>2018-04-12T00:50:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8c37ac3c04e7122843505c7bfd054fbb7f320777'/>
<id>urn:sha1:8c37ac3c04e7122843505c7bfd054fbb7f320777</id>
<content type='text'>
commit b3906535ccc6cd04c42f9b1c7e31d1947b3ebc74 upstream.

The driver supports internal and external FDD units so the floppy_open
function must not hard-code the drive location.

Cc: Laurent Vivier &lt;lvivier@redhat.com&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: stable@vger.kernel.org # v4.14+
Tested-by: Stan Johnson &lt;userm57@yahoo.com&gt;
Signed-off-by: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Acked-by: Laurent Vivier &lt;lvivier@redhat.com&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>block/swim: Rename macros to avoid inconsistent inverted logic</title>
<updated>2018-04-29T09:33:17+00:00</updated>
<author>
<name>Finn Thain</name>
<email>fthain@telegraphics.com.au</email>
</author>
<published>2018-04-12T00:50:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cdb0d5fa252864dccb223ba5437598c2b1684289'/>
<id>urn:sha1:cdb0d5fa252864dccb223ba5437598c2b1684289</id>
<content type='text'>
commit 56a1c5ee54f69dd767fb61d301883dc919ddc259 upstream.

The Sony drive status bits use active-low logic. The swim_readbit()
function converts that to 'C' logic for readability. Hence, the
sense of the names of the status bit macros should not be inverted.

Mostly they are correct. However, the TWOMEG_DRIVE, MFM_MODE and
TWOMEG_MEDIA macros have inverted sense (like MkLinux). Fix this
inconsistency and make the following patches less confusing.

The same problem affects swim3.c so fix that too.

No functional change.

The FDHD drive status bits are documented in sonydriv.cpp from MAME
and in swimiii.h from MkLinux.

Cc: Laurent Vivier &lt;lvivier@redhat.com&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: stable@vger.kernel.org # v4.14+
Tested-by: Stan Johnson &lt;userm57@yahoo.com&gt;
Signed-off-by: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Acked-by: Laurent Vivier &lt;lvivier@redhat.com&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>block/swim: Remove extra put_disk() call from error path</title>
<updated>2018-04-29T09:33:17+00:00</updated>
<author>
<name>Finn Thain</name>
<email>fthain@telegraphics.com.au</email>
</author>
<published>2018-04-12T00:50:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f359e87feb8859f687e43bb99f52e566ee82b347'/>
<id>urn:sha1:f359e87feb8859f687e43bb99f52e566ee82b347</id>
<content type='text'>
commit c1d6207cc0eef2a7f8551f9c7420d8776268f6e1 upstream.

Cc: Laurent Vivier &lt;lvivier@redhat.com&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: stable@vger.kernel.org # v4.14+
Fixes: 103db8b2dfa5 ("[PATCH] swim: stop sharing request queue across multiple gendisks")
Tested-by: Stan Johnson &lt;userm57@yahoo.com&gt;
Signed-off-by: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Acked-by: Laurent Vivier &lt;lvivier@redhat.com&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&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>block/swim: Don't log an error message for an invalid ioctl</title>
<updated>2018-04-29T09:33:17+00:00</updated>
<author>
<name>Finn Thain</name>
<email>fthain@telegraphics.com.au</email>
</author>
<published>2018-04-12T00:50:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b7100feb26d21c27a8a75e5351a618bbc94fff49'/>
<id>urn:sha1:b7100feb26d21c27a8a75e5351a618bbc94fff49</id>
<content type='text'>
commit 8e2ab5a4efaac77fb93e5b5b109d0b3976fdd3a0 upstream.

The 'eject' shell command may send various different ioctl commands.
This leads to error messages on the console even though the FDEJECT
ioctl succeeds.

~# eject floppy
SWIM floppy_ioctl: unknown cmd 21257
SWIM floppy_ioctl: unknown cmd 1

Don't log an error message for an invalid ioctl, just do as the
swim3 driver does and return -ENOTTY.

Cc: Laurent Vivier &lt;lvivier@redhat.com&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: stable@vger.kernel.org # v4.14+
Tested-by: Stan Johnson &lt;userm57@yahoo.com&gt;
Signed-off-by: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Acked-by: Laurent Vivier &lt;lvivier@redhat.com&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&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>block/swim: Check drive type</title>
<updated>2018-04-29T09:33:17+00:00</updated>
<author>
<name>Finn Thain</name>
<email>fthain@telegraphics.com.au</email>
</author>
<published>2018-04-12T00:50:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0dd9146a229147c526223cb06bf3468261ec79eb'/>
<id>urn:sha1:0dd9146a229147c526223cb06bf3468261ec79eb</id>
<content type='text'>
commit 8a500df63d07d8aee44b7ee2c54e462e47ce93ec upstream.

The SWIM chip is compatible with GCR-mode Sony 400K/800K drives but
this driver only supports MFM mode. Therefore only Sony FDHD drives
are supported. Skip incompatible drives.

Cc: Laurent Vivier &lt;lvivier@redhat.com&gt;
Cc: Jens Axboe &lt;axboe@kernel.dk&gt;
Cc: stable@vger.kernel.org # v4.14+
Tested-by: Stan Johnson &lt;userm57@yahoo.com&gt;
Signed-off-by: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Acked-by: Laurent Vivier &lt;lvivier@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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