<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/staging, branch linux-5.7.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.7.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-5.7.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2020-08-21T11:07:32Z</updated>
<entry>
<title>media: staging: rkisp1: remove macro RKISP1_DIR_SINK_SRC</title>
<updated>2020-08-21T11:07:32Z</updated>
<author>
<name>Dafna Hirschfeld</name>
<email>dafna.hirschfeld@collabora.com</email>
</author>
<published>2020-06-18T11:35:16Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=7f1434f265219a9c218cea66decefdeaf996004c'/>
<id>urn:sha1:7f1434f265219a9c218cea66decefdeaf996004c</id>
<content type='text'>
[ Upstream commit b861d139a36a4593498932bfec957bdcc7d98eb3 ]

The macro RKISP1_DIR_SINK_SRC is a mask of two flags.
The macro hides the fact that it's a mask and the code
is actually more clear if we replace it the with bitwise-or explicitly.

Signed-off-by: Dafna Hirschfeld &lt;dafna.hirschfeld@collabora.com&gt;
Acked-by: Helen Koike &lt;helen.koike@collabora.com&gt;
Reviewed-by: Tomasz Figa &lt;tfiga@chromium.org&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>staging: rtl8192u: fix a dubious looking mask before a shift</title>
<updated>2020-08-19T06:23:55Z</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2020-07-16T15:47:20Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=18f2b5b48102c512660e51c0237b4dae8ed8a713'/>
<id>urn:sha1:18f2b5b48102c512660e51c0237b4dae8ed8a713</id>
<content type='text'>
[ Upstream commit c4283950a9a4d3bf4a3f362e406c80ab14f10714 ]

Currently the masking of ret with 0xff and followed by a right shift
of 8 bits always leaves a zero result.  It appears the mask of 0xff
is incorrect and should be 0xff00, but I don't have the hardware to
test this. Fix this to mask the upper 8 bits before shifting.

[ Not tested ]

Addresses-Coverity: ("Operands don't affect result")
Fixes: 8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging")
Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Link: https://lore.kernel.org/r/20200716154720.1710252-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: staging: rkisp1: rsz: fix resolution limitation on sink pad</title>
<updated>2020-08-19T06:23:51Z</updated>
<author>
<name>Helen Koike</name>
<email>helen.koike@collabora.com</email>
</author>
<published>2020-06-17T18:08:01Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=e6a4c993ec1a941918761dc6ee322a0944d706f6'/>
<id>urn:sha1:e6a4c993ec1a941918761dc6ee322a0944d706f6</id>
<content type='text'>
[ Upstream commit 906dceb48dfa1e7c99c32e6b25878d47023e916b ]

Resizer sink pad is limited by what the ISP can generate.
The configurations describes what the resizer can produce.

This was tested on a Scarlet device with ChromiumOs, where the selfpath
receives 2592x1944 and produces 1600x1200 (which isn't possible without
this fix).

Fixes: 56e3b29f9f6b2 ("media: staging: rkisp1: add streaming paths")
Signed-off-by: Helen Koike &lt;helen.koike@collabora.com&gt;
Reviewed-by: Tomasz Figa &lt;tfiga@chromium.org&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: staging: rkisp1: rsz: supported formats are the isp's src formats, not sink formats</title>
<updated>2020-08-19T06:23:51Z</updated>
<author>
<name>Dafna Hirschfeld</name>
<email>dafna.hirschfeld@collabora.com</email>
</author>
<published>2020-06-18T11:35:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=b64c2dbbd72e3a3a8eb2620b9eded1a28ca1df5f'/>
<id>urn:sha1:b64c2dbbd72e3a3a8eb2620b9eded1a28ca1df5f</id>
<content type='text'>
[ Upstream commit 7b8ce1f2763b9351a4cb04b802835470e76770a5 ]

The rkisp1_resizer's enum callback 'rkisp1_rsz_enum_mbus_code'
calls the enum callback of the 'rkisp1_isp' on it's video sink pad.
This is a bug, the resizer should support the same formats
supported by the 'rkisp1_isp' on the source pad (not the sink pad).

Fixes: 56e3b29f9f6b "media: staging: rkisp1: add streaming paths"
Signed-off-by: Dafna Hirschfeld &lt;dafna.hirschfeld@collabora.com&gt;
Acked-by: Helen Koike &lt;helen.koike@collabora.com&gt;
Reviewed-by: Tomasz Figa &lt;tfiga@chromium.org&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: allegro: Fix some NULL vs IS_ERR() checks in probe</title>
<updated>2020-08-19T06:23:51Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2020-06-19T14:30:07Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=4b1f2a5319518bb7538bb7d323e9448be09edb99'/>
<id>urn:sha1:4b1f2a5319518bb7538bb7d323e9448be09edb99</id>
<content type='text'>
[ Upstream commit d93d45ab716e4107056be54969c8c70e50a8346d ]

The devm_ioremap() function doesn't return error pointers, it returns
NULL on error.

Fixes: f20387dfd065 ("media: allegro: add Allegro DVT video IP core driver")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil-cisco@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+huawei@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>staging: vchiq_arm: Add a matching unregister call</title>
<updated>2020-08-19T06:23:50Z</updated>
<author>
<name>Phil Elwell</name>
<email>phil@raspberrypi.com</email>
</author>
<published>2020-06-29T15:09:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=eaef1fec3fc9f8304d7b66a74ae2c34b89e7eded'/>
<id>urn:sha1:eaef1fec3fc9f8304d7b66a74ae2c34b89e7eded</id>
<content type='text'>
[ Upstream commit 5d9272e28a9a6117fb63f5f930991304765caa32 ]

All the registered children of vchiq have a corresponding call to
platform_device_unregister except bcm2835_audio. Fix that.

Fixes: 25c7597af20d ("staging: vchiq_arm: Register a platform device for audio")

Signed-off-by: Phil Elwell &lt;phil@raspberrypi.com&gt;
Signed-off-by: Jacopo Mondi &lt;jacopo@jmondi.org&gt;
Signed-off-by: Nicolas Saenz Julienne &lt;nsaenzjulienne@suse.de&gt;
Link: https://lore.kernel.org/r/20200629150945.10720-9-nsaenzjulienne@suse.de
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Staging: rtl8188eu: rtw_mlme: Fix uninitialized variable authmode</title>
<updated>2020-08-11T13:35:32Z</updated>
<author>
<name>Dinghao Liu</name>
<email>dinghao.liu@zju.edu.cn</email>
</author>
<published>2020-07-28T07:21:51Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fa7afddeac0b49697763b300a9fea221eb353cc0'/>
<id>urn:sha1:fa7afddeac0b49697763b300a9fea221eb353cc0</id>
<content type='text'>
commit 11536442a3b4e1de6890ea5e805908debb74f94a upstream.

The variable authmode can be uninitialized. The danger would be if
it equals to _WPA_IE_ID_ (0xdd) or _WPA2_IE_ID_ (0x33). We can avoid
this by setting it to zero instead. This is the approach that was
used in the rtl8723bs driver.

Fixes: 7b464c9fa5cc ("staging: r8188eu: Add files for new driver - part 4")
Co-developed-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Dinghao Liu &lt;dinghao.liu@zju.edu.cn&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20200728072153.9202-1-dinghao.liu@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>staging: rtl8712: handle firmware load failure</title>
<updated>2020-08-11T13:35:32Z</updated>
<author>
<name>Rustam Kovhaev</name>
<email>rkovhaev@gmail.com</email>
</author>
<published>2020-07-16T15:13:26Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=3a8d0a1aa5cb13b6437f465c6e1201c23ebb0b4e'/>
<id>urn:sha1:3a8d0a1aa5cb13b6437f465c6e1201c23ebb0b4e</id>
<content type='text'>
commit b4383c971bc5263efe2b0915ba67ebf2bf3f1ee5 upstream.

when firmware fails to load we should not call unregister_netdev()
this patch fixes a race condition between rtl871x_load_fw_cb() and
r871xu_dev_remove() and fixes the bug reported by syzbot

Reported-by: syzbot+80899a8a8efe8968cde7@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=80899a8a8efe8968cde7
Signed-off-by: Rustam Kovhaev &lt;rkovhaev@gmail.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/20200716151324.1036204-1-rkovhaev@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>staging: android: ashmem: Fix lockdep warning for write operation</title>
<updated>2020-08-11T13:35:31Z</updated>
<author>
<name>Suren Baghdasaryan</name>
<email>surenb@google.com</email>
</author>
<published>2020-07-30T19:26:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=07f332267d8189d1394b960718f87af30fed8b7a'/>
<id>urn:sha1:07f332267d8189d1394b960718f87af30fed8b7a</id>
<content type='text'>
commit 3e338d3c95c735dc3265a86016bb4c022ec7cadc upstream.

syzbot report [1] describes a deadlock when write operation against an
ashmem fd executed at the time when ashmem is shrinking its cache results
in the following lock sequence:

Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(fs_reclaim);
                                lock(&amp;sb-&gt;s_type-&gt;i_mutex_key#13);
                                lock(fs_reclaim);
   lock(&amp;sb-&gt;s_type-&gt;i_mutex_key#13);

kswapd takes fs_reclaim and then inode_lock while generic_perform_write
takes inode_lock and then fs_reclaim. However ashmem does not support
writing into backing shmem with a write syscall. The only way to change
its content is to mmap it and operate on mapped memory. Therefore the race
that lockdep is warning about is not valid. Resolve this by introducing a
separate lockdep class for the backing shmem inodes.

[1]: https://lkml.kernel.org/lkml/0000000000000b5f9d059aa2037f@google.com/

Reported-by: syzbot+7a0d9d0b26efefe61780@syzkaller.appspotmail.com
Signed-off-by: Suren Baghdasaryan &lt;surenb@google.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Reviewed-by: Joel Fernandes (Google) &lt;joel@joelfernandes.org&gt;
Link: https://lore.kernel.org/r/20200730192632.3088194-1-surenb@google.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>staging: comedi: addi_apci_1564: check INSN_CONFIG_DIGITAL_TRIG shift</title>
<updated>2020-07-29T08:19:56Z</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2020-07-17T14:52:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=fed64b9dbfbe54ccc7d8b7c72dcc06362439cd62'/>
<id>urn:sha1:fed64b9dbfbe54ccc7d8b7c72dcc06362439cd62</id>
<content type='text'>
commit 926234f1b8434c4409aa4c53637aa3362ca07cea upstream.

The `INSN_CONFIG` comedi instruction with sub-instruction code
`INSN_CONFIG_DIGITAL_TRIG` includes a base channel in `data[3]`. This is
used as a right shift amount for other bitmask values without being
checked.  Shift amounts greater than or equal to 32 will result in
undefined behavior.  Add code to deal with this.

Fixes: 1e15687ea472 ("staging: comedi: addi_apci_1564: add Change-of-State interrupt subdevice and required functions")
Cc: &lt;stable@vger.kernel.org&gt; #3.17+
Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Link: https://lore.kernel.org/r/20200717145257.112660-4-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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