<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers, branch v5.4.38</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.38</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.38'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2020-05-02T06:49:01Z</updated>
<entry>
<title>qed: Fix use after free in qed_chain_free</title>
<updated>2020-05-02T06:49:01Z</updated>
<author>
<name>Yuval Basson</name>
<email>ybason@marvell.com</email>
</author>
<published>2020-03-29T17:32:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=93af898b251fd6386e874f8803661cece1e45657'/>
<id>urn:sha1:93af898b251fd6386e874f8803661cece1e45657</id>
<content type='text'>
commit 8063f761cd7c17fc1d0018728936e0c33a25388a upstream.

The qed_chain data structure was modified in
commit 1a4a69751f4d ("qed: Chain support for external PBL") to support
receiving an external pbl (due to iWARP FW requirements).
The pages pointed to by the pbl are allocated in qed_chain_alloc
and their virtual address are stored in an virtual addresses array to
enable accessing and freeing the data. The physical addresses however
weren't stored and were accessed directly from the external-pbl
during free.

Destroy-qp flow, leads to freeing the external pbl before the chain is
freed, when the chain is freed it tries accessing the already freed
external pbl, leading to a use-after-free. Therefore we need to store
the physical addresses in additional to the virtual addresses in a
new data structure.

Fixes: 1a4a69751f4d ("qed: Chain support for external PBL")
Signed-off-by: Michal Kalderon &lt;mkalderon@marvell.com&gt;
Signed-off-by: Yuval Bason &lt;ybason@marvell.com&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>Crypto: chelsio - Fixes a hang issue during driver registration</title>
<updated>2020-05-02T06:49:00Z</updated>
<author>
<name>Ayush Sawal</name>
<email>ayush.sawal@chelsio.com</email>
</author>
<published>2020-03-30T15:18:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ec9cf8afcd641263bac73a608440a2b22e026a0c'/>
<id>urn:sha1:ec9cf8afcd641263bac73a608440a2b22e026a0c</id>
<content type='text'>
commit ad59ddd02de26271b89564962e74d689f1a30b49 upstream.

This issue occurs only when multiadapters are present. Hang
happens because assign_chcr_device returns u_ctx pointer of
adapter which is not yet initialized as for this adapter cxgb_up
is not been called yet.

The last_dev pointer is used to determine u_ctx pointer and it
is initialized two times in chcr_uld_add in chcr_dev_add respectively.

The fix here is don't initialize the last_dev pointer during
chcr_uld_add. Only assign to value to it when the adapter's
initialization is completed i.e in chcr_dev_add.

Fixes: fef4912b66d62 ("crypto: chelsio - Handle PCI shutdown event").

Signed-off-by: Ayush Sawal &lt;ayush.sawal@chelsio.com&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>qed: Fix race condition between scheduling and destroying the slowpath workqueue</title>
<updated>2020-05-02T06:49:00Z</updated>
<author>
<name>Yuval Basson</name>
<email>ybason@marvell.com</email>
</author>
<published>2020-03-25T20:50:43Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b0946b45b85a540aa1b030c277301ce87003d5b6'/>
<id>urn:sha1:b0946b45b85a540aa1b030c277301ce87003d5b6</id>
<content type='text'>
commit 3b85720d3fd72e6ef4de252cd2f67548eb645eb4 upstream.

Calling queue_delayed_work concurrently with
destroy_workqueue might race to an unexpected outcome -
scheduled task after wq is destroyed or other resources
(like ptt_pool) are freed (yields NULL pointer dereference).
cancel_delayed_work prevents the race by cancelling
the timer triggered for scheduling a new task.

Fixes: 59ccf86fe ("qed: Add driver infrastucture for handling mfw requests")
Signed-off-by: Denis Bolotin &lt;dbolotin@marvell.com&gt;
Signed-off-by: Michal Kalderon &lt;mkalderon@marvell.com&gt;
Signed-off-by: Yuval Basson &lt;ybason@marvell.com&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>hwmon: (jc42) Fix name to have no illegal characters</title>
<updated>2020-05-02T06:48:59Z</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2020-04-17T09:28:53Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f37079e9ea83dc1f66713c2dbec2c19cd8cf121f'/>
<id>urn:sha1:f37079e9ea83dc1f66713c2dbec2c19cd8cf121f</id>
<content type='text'>
[ Upstream commit c843b382e61b5f28a3d917712c69a344f632387c ]

The jc42 driver passes I2C client's name as hwmon device name. In case
of device tree probed devices this ends up being part of the compatible
string, "jc-42.4-temp". This name contains hyphens and the hwmon core
doesn't like this:

jc42 2-0018: hwmon: 'jc-42.4-temp' is not a valid name attribute, please fix

This changes the name to "jc42" which doesn't have any illegal
characters.

Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Link: https://lore.kernel.org/r/20200417092853.31206-1-s.hauer@pengutronix.de
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: stmmac: socfpga: Allow all RGMII modes</title>
<updated>2020-05-02T06:48:57Z</updated>
<author>
<name>Atsushi Nemoto</name>
<email>atsushi.nemoto@sord.co.jp</email>
</author>
<published>2020-04-14T01:12:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9178430df3f73976f5b9bab70d137e1da31aaad8'/>
<id>urn:sha1:9178430df3f73976f5b9bab70d137e1da31aaad8</id>
<content type='text'>
[ Upstream commit a7a0d6269652846671312b29992143f56e2866b8 ]

Allow all the RGMII modes to be used.  (Not only "rgmii", "rgmii-id"
but "rgmii-txid", "rgmii-rxid")

Signed-off-by: Atsushi Nemoto &lt;atsushi.nemoto@sord.co.jp&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>xen/xenbus: ensure xenbus_map_ring_valloc() returns proper grant status</title>
<updated>2020-05-02T06:48:57Z</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2020-03-26T08:03:58Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d9d4ea17d6d6f08f9f2700ead1d591f123baaddf'/>
<id>urn:sha1:d9d4ea17d6d6f08f9f2700ead1d591f123baaddf</id>
<content type='text'>
[ Upstream commit 6b51fd3f65a22e3d1471b18a1d56247e246edd46 ]

xenbus_map_ring_valloc() maps a ring page and returns the status of the
used grant (0 meaning success).

There are Xen hypervisors which might return the value 1 for the status
of a failed grant mapping due to a bug. Some callers of
xenbus_map_ring_valloc() test for errors by testing the returned status
to be less than zero, resulting in no error detected and crashing later
due to a not available ring page.

Set the return value of xenbus_map_ring_valloc() to GNTST_general_error
in case the grant status reported by Xen is greater than zero.

This is part of XSA-316.

Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Wei Liu &lt;wl@xen.org&gt;
Link: https://lore.kernel.org/r/20200326080358.1018-1-jgross@suse.com
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: target: tcmu: reset_ring should reset TCMU_DEV_BIT_BROKEN</title>
<updated>2020-05-02T06:48:56Z</updated>
<author>
<name>Bodo Stroesser</name>
<email>bstroesser@ts.fujitsu.com</email>
</author>
<published>2020-04-09T10:10:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1cc2460dad8274670da6aa42f6dfc7dbc3728f05'/>
<id>urn:sha1:1cc2460dad8274670da6aa42f6dfc7dbc3728f05</id>
<content type='text'>
[ Upstream commit 066f79a5fd6d1b9a5cc57b5cd445b3e4bb68a5b2 ]

In case command ring buffer becomes inconsistent, tcmu sets device flag
TCMU_DEV_BIT_BROKEN.  If the bit is set, tcmu rejects new commands from LIO
core with TCM_LOGICAL_UNIT_COMMUNICATION_FAILURE, and no longer processes
completions from the ring.  The reset_ring attribute can be used to
completely clean up the command ring, so after reset_ring the ring no
longer is inconsistent.

Therefore reset_ring also should reset bit TCMU_DEV_BIT_BROKEN to allow
normal processing.

Link: https://lore.kernel.org/r/20200409101026.17872-1-bstroesser@ts.fujitsu.com
Acked-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Bodo Stroesser &lt;bstroesser@ts.fujitsu.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>scsi: target: fix PR IN / READ FULL STATUS for FC</title>
<updated>2020-05-02T06:48:56Z</updated>
<author>
<name>Bodo Stroesser</name>
<email>bstroesser@ts.fujitsu.com</email>
</author>
<published>2020-04-08T13:26:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=62d350eb31d17a96528aba76ce23c806346d08cd'/>
<id>urn:sha1:62d350eb31d17a96528aba76ce23c806346d08cd</id>
<content type='text'>
[ Upstream commit 8fed04eb79a74cbf471dfaa755900a51b37273ab ]

Creation of the response to READ FULL STATUS fails for FC based
reservations. Reason is the too high loop limit (&lt; 24) in
fc_get_pr_transport_id(). The string representation of FC WWPN is 23 chars
long only ("11:22:33:44:55:66:77:88"). So when i is 23, the loop body is
executed a last time for the ending '\0' of the string and thus hex2bin()
reports an error.

Link: https://lore.kernel.org/r/20200408132610.14623-3-bstroesser@ts.fujitsu.com
Signed-off-by: Bodo Stroesser &lt;bstroesser@ts.fujitsu.com&gt;
Reviewed-by: Mike Christie &lt;mchristi@redhat.com&gt;
Signed-off-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: fec: set GPR bit on suspend by DT configuration.</title>
<updated>2020-05-02T06:48:55Z</updated>
<author>
<name>Martin Fuzzey</name>
<email>martin.fuzzey@flowbird.group</email>
</author>
<published>2020-04-02T13:51:27Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b5da1152f7165182621f06f942fa752acdcf90b8'/>
<id>urn:sha1:b5da1152f7165182621f06f942fa752acdcf90b8</id>
<content type='text'>
[ Upstream commit da722186f6549d752ea5b5fbc18111833c81a133 ]

On some SoCs, such as the i.MX6, it is necessary to set a bit
in the SoC level GPR register before suspending for wake on lan
to work.

The fec platform callback sleep_mode_enable was intended to allow this
but the platform implementation was NAK'd back in 2015 [1]

This means that, currently, wake on lan is broken on mainline for
the i.MX6 at least.

So implement the required bit setting in the fec driver by itself
by adding a new optional DT property indicating the GPR register
and adding the offset and bit information to the driver.

[1] https://www.spinics.net/lists/netdev/msg310922.html

Signed-off-by: Martin Fuzzey &lt;martin.fuzzey@flowbird.group&gt;
Signed-off-by: Fugang Duan &lt;fugang.duan@nxp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PM: sleep: core: Switch back to async_schedule_dev()</title>
<updated>2020-05-02T06:48:53Z</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2020-04-21T08:21:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b9c31556c37b43685efe0e9bf0555fb3b01607d5'/>
<id>urn:sha1:b9c31556c37b43685efe0e9bf0555fb3b01607d5</id>
<content type='text'>
commit 09beebd8f93b3c8bf894e342f0a203a5c612478c upstream.

Commit 8b9ec6b73277 ("PM core: Use new async_schedule_dev command")
introduced a new function for better performance.

However commit f2a424f6c613 ("PM / core: Introduce dpm_async_fn()
helper") went back to the non-optimized version, async_schedule().

So switch back to the sync_schedule_dev() to improve performance

Fixes: f2a424f6c613 ("PM / core: Introduce dpm_async_fn() helper")
Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.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>
</feed>
