<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git, branch v3.10.94</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.94</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.10.94'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2015-12-09T18:43:21Z</updated>
<entry>
<title>Linux 3.10.94</title>
<updated>2015-12-09T18:43:21Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2015-12-09T18:43:21Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=03ed106ff4c200d01f3c72f71fa9c5b18da07d9b'/>
<id>urn:sha1:03ed106ff4c200d01f3c72f71fa9c5b18da07d9b</id>
<content type='text'>
</content>
</entry>
<entry>
<title>ALSA: usb-audio: work around CH345 input SysEx corruption</title>
<updated>2015-12-09T18:40:11Z</updated>
<author>
<name>Clemens Ladisch</name>
<email>clemens@ladisch.de</email>
</author>
<published>2015-11-15T21:39:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=82dbfa50b0ee671e40779541a6ceef0850d19c84'/>
<id>urn:sha1:82dbfa50b0ee671e40779541a6ceef0850d19c84</id>
<content type='text'>
commit a91e627e3f0ed820b11d86cdc04df38f65f33a70 upstream.

One of the many faults of the QinHeng CH345 USB MIDI interface chip is
that it does not handle received SysEx messages correctly -- every second
event packet has a wrong code index number, which is the one from the last
seen message, instead of 4.  For example, the two messages "FE F0 01 02 03
04 05 06 07 08 09 0A 0B 0C 0D 0E F7" result in the following event
packets:

correct:       CH345:
0F FE 00 00    0F FE 00 00
04 F0 01 02    04 F0 01 02
04 03 04 05    0F 03 04 05
04 06 07 08    04 06 07 08
04 09 0A 0B    0F 09 0A 0B
04 0C 0D 0E    04 0C 0D 0E
05 F7 00 00    05 F7 00 00

A class-compliant driver must interpret an event packet with CIN 15 as
having a single data byte, so the other two bytes would be ignored.  The
message received by the host would then be missing two bytes out of six;
in this example, "F0 01 02 03 06 07 08 09 0C 0D 0E F7".

These corrupted SysEx event packages contain only data bytes, while the
CH345 uses event packets with a correct CIN value only for messages with
a status byte, so it is possible to distinguish between these two cases by
checking for the presence of this status byte.

(Other bugs in the CH345's input handling, such as the corruption resulting
from running status, cannot be worked around.)

Signed-off-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: usb-audio: prevent CH345 multiport output SysEx corruption</title>
<updated>2015-12-09T18:40:10Z</updated>
<author>
<name>Clemens Ladisch</name>
<email>clemens@ladisch.de</email>
</author>
<published>2015-11-15T21:38:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=88ab73208769677b3935d747a43aab1213d15d39'/>
<id>urn:sha1:88ab73208769677b3935d747a43aab1213d15d39</id>
<content type='text'>
commit 1ca8b201309d842642f221db7f02f71c0af5be2d upstream.

The CH345 USB MIDI chip has two output ports.  However, they are
multiplexed through one pin, and the number of ports cannot be reduced
even for hardware that implements only one connector, so for those
devices, data sent to either port ends up on the same hardware output.
This becomes a problem when both ports are used at the same time, as
longer MIDI commands (such as SysEx messages) are likely to be
interrupted by messages from the other port, and thus to get lost.

It would not be possible for the driver to detect how many ports the
device actually has, except that in practice, _all_ devices built with
the CH345 have only one port.  So we can just ignore the device's
descriptors, and hardcode one output port.

Signed-off-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ALSA: usb-audio: add packet size quirk for the Medeli DD305</title>
<updated>2015-12-09T18:40:10Z</updated>
<author>
<name>Clemens Ladisch</name>
<email>clemens@ladisch.de</email>
</author>
<published>2015-11-15T21:37:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=5d39c9b60cfd2381737cdeb5a74bd79d4b27e84c'/>
<id>urn:sha1:5d39c9b60cfd2381737cdeb5a74bd79d4b27e84c</id>
<content type='text'>
commit 98d362becb6621bebdda7ed0eac7ad7ec6c37898 upstream.

Signed-off-by: Clemens Ladisch &lt;clemens@ladisch.de&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: option: add XS Stick W100-2 from 4G Systems</title>
<updated>2015-12-09T18:40:10Z</updated>
<author>
<name>Bjørn Mork</name>
<email>bjorn@mork.no</email>
</author>
<published>2015-11-18T20:12:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=53009ce204642c3191d6f4d773d28c80f0c27971'/>
<id>urn:sha1:53009ce204642c3191d6f4d773d28c80f0c27971</id>
<content type='text'>
commit 638148e20c7f8f6e95017fdc13bce8549a6925e0 upstream.

Thomas reports
"
4gsystems sells two total different LTE-surfsticks under the same name.
..
The newer version of XS Stick W100 is from "omega"
..
Under windows the driver switches to the same ID, and uses MI03\6 for
network and MI01\6 for modem.
..
echo "1c9e 9b01" &gt; /sys/bus/usb/drivers/qmi_wwan/new_id
echo "1c9e 9b01" &gt; /sys/bus/usb-serial/drivers/option1/new_id

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  4 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(&gt;ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1c9e ProdID=9b01 Rev=02.32
S:  Manufacturer=USB Modem
S:  Product=USB Modem
S:  SerialNumber=
C:  #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=option
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I:  If#= 4 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage

Now all important things are there:

wwp0s29f7u2i3 (net), ttyUSB2 (at), cdc-wdm0 (qmi), ttyUSB1 (at)

There is also ttyUSB0, but it is not usable, at least not for at.

The device works well with qmi and ModemManager-NetworkManager.
"

Reported-by: Thomas Schäfer &lt;tschaefer@t-online.de&gt;
Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>USB: serial: option: add support for Novatel MiFi USB620L</title>
<updated>2015-12-09T18:40:10Z</updated>
<author>
<name>Aleksander Morgado</name>
<email>aleksander@aleksander.es</email>
</author>
<published>2015-11-11T18:51:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b2dbbdda6605358caeed741f51101395991dda5f'/>
<id>urn:sha1:b2dbbdda6605358caeed741f51101395991dda5f</id>
<content type='text'>
commit e07af133c3e2716db25e3e1e1d9f10c2088e9c1a upstream.

Also known as Verizon U620L.

The device is modeswitched from 1410:9020 to 1410:9022 by selecting the
4th USB configuration:

 $ sudo usb_modeswitch –v 0x1410 –p 0x9020 –u 4

This configuration provides a ECM interface as well as TTYs ('Enterprise
Mode' according to the U620 Linux integration guide).

Signed-off-by: Aleksander Morgado &lt;aleksander@aleksander.es&gt;
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>usb: musb: core: fix order of arguments to ulpi write callback</title>
<updated>2015-12-09T18:40:10Z</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2015-10-23T07:53:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9a960144742c6b57a17e8fd0df982b9ea28ae3c9'/>
<id>urn:sha1:9a960144742c6b57a17e8fd0df982b9ea28ae3c9</id>
<content type='text'>
commit 705e63d2b29c8bbf091119084544d353bda70393 upstream.

There is a bit of a mess in the order of arguments to the ulpi write
callback. There is

	int ulpi_write(struct ulpi *ulpi, u8 addr, u8 val)

in drivers/usb/common/ulpi.c;

	struct usb_phy_io_ops {
		...
		int (*write)(struct usb_phy *x, u32 val, u32 reg);
	}

in include/linux/usb/phy.h.

The callback registered by the musb driver has to comply to the latter,
but up to now had "offset" first which effectively made the function
broken for correct users. So flip the order and while at it also
switch to the parameter names of struct usb_phy_io_ops's write.

Fixes: ffb865b1e460 ("usb: musb: add ulpi access operations")
Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&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>usblp: do not set TASK_INTERRUPTIBLE before lock</title>
<updated>2015-12-09T18:40:10Z</updated>
<author>
<name>Jiri Slaby</name>
<email>jslaby@suse.cz</email>
</author>
<published>2015-11-02T09:27:00Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2391fbf63585c3befa63a4780f470cf59539a6f7'/>
<id>urn:sha1:2391fbf63585c3befa63a4780f470cf59539a6f7</id>
<content type='text'>
commit 19cd80a214821f4b558560ebd76bfb2c38b4f3d8 upstream.

It is not permitted to set task state before lock. usblp_wwait sets
the state to TASK_INTERRUPTIBLE and calls mutex_lock_interruptible.
Upon return from that function, the state will be TASK_RUNNING again.

This is clearly a bug and a warning is generated with LOCKDEP too:
WARNING: CPU: 1 PID: 5109 at kernel/sched/core.c:7404 __might_sleep+0x7d/0x90()
do not call blocking ops when !TASK_RUNNING; state=1 set at [&lt;ffffffffa0c588d0&gt;] usblp_wwait+0xa0/0x310 [usblp]
Modules linked in: ...
CPU: 1 PID: 5109 Comm: captmon Tainted: G        W       4.2.5-0.gef2823b-default #1
Hardware name: LENOVO 23252SG/23252SG, BIOS G2ET33WW (1.13 ) 07/24/2012
 ffffffff81a4edce ffff880236ec7ba8 ffffffff81716651 0000000000000000
 ffff880236ec7bf8 ffff880236ec7be8 ffffffff8106e146 0000000000000282
 ffffffff81a50119 000000000000028b 0000000000000000 ffff8802dab7c508
Call Trace:
...
 [&lt;ffffffff8106e1c6&gt;] warn_slowpath_fmt+0x46/0x50
 [&lt;ffffffff8109a8bd&gt;] __might_sleep+0x7d/0x90
 [&lt;ffffffff8171b20f&gt;] mutex_lock_interruptible_nested+0x2f/0x4b0
 [&lt;ffffffffa0c588fc&gt;] usblp_wwait+0xcc/0x310 [usblp]
 [&lt;ffffffffa0c58bb2&gt;] usblp_write+0x72/0x350 [usblp]
 [&lt;ffffffff8121ed98&gt;] __vfs_write+0x28/0xf0
...

Commit 7f477358e2384c54b190cc3b6ce28277050a041b (usblp: Implement the
ENOSPC convention) moved the set prior locking. So move it back after
the lock.

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Fixes: 7f477358e2 ("usblp: Implement the ENOSPC convention")
Acked-By: Pete Zaitcev &lt;zaitcev@yahoo.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: Fix compat register mappings</title>
<updated>2015-12-09T18:40:10Z</updated>
<author>
<name>Robin Murphy</name>
<email>robin.murphy@arm.com</email>
</author>
<published>2015-10-22T14:41:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b2a5b5964748a5a25a28652f4ea4223a534a4c86'/>
<id>urn:sha1:b2a5b5964748a5a25a28652f4ea4223a534a4c86</id>
<content type='text'>
commit 5accd17d0eb523350c9ef754d655e379c9bb93b3 upstream.

For reasons not entirely apparent, but now enshrined in history, the
architectural mapping of AArch32 banked registers to AArch64 registers
actually orders SP_&lt;mode&gt; and LR_&lt;mode&gt; backwards compared to the
intuitive r13/r14 order, for all modes except FIQ.

Fix the compat_&lt;reg&gt;_&lt;mode&gt; macros accordingly, in the hope of avoiding
subtle bugs with KVM and AArch32 guests.

Signed-off-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>can: sja1000: clear interrupts on start</title>
<updated>2015-12-09T18:40:09Z</updated>
<author>
<name>Mirza Krak</name>
<email>mirza.krak@hostmobility.com</email>
</author>
<published>2015-11-10T13:59:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=3b792c868153a9911e46ec3069b7b94e7cc5c6c6'/>
<id>urn:sha1:3b792c868153a9911e46ec3069b7b94e7cc5c6c6</id>
<content type='text'>
commit 7cecd9ab80f43972c056dc068338f7bcc407b71c upstream.

According to SJA1000 data sheet error-warning (EI) interrupt is not
cleared by setting the controller in to reset-mode.

Then if we have the following case:
- system is suspended (echo mem &gt; /sys/power/state) and SJA1000 is left
  in operating state
- A bus error condition occurs which activates EI interrupt, system is
  still suspended which means EI interrupt will be not be handled nor
  cleared.

If the above two events occur, on resume there is no way to return the
SJA1000 to operating state, except to cycle power to it.

By simply reading the IR register on start we will clear any previous
conditions that could be present.

Signed-off-by: Mirza Krak &lt;mirza.krak@hostmobility.com&gt;
Reported-by: Christian Magnusson &lt;Christian.Magnusson@semcon.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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