<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers, branch v4.9.262</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.9.262</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.9.262'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2021-03-17T15:10:19Z</updated>
<entry>
<title>xen/events: avoid handling the same event on two cpus at the same time</title>
<updated>2021-03-17T15:10:19Z</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2021-03-15T09:06:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=959b239634239ca2db0de5c822dad1ae48c0a861'/>
<id>urn:sha1:959b239634239ca2db0de5c822dad1ae48c0a861</id>
<content type='text'>
commit b6622798bc50b625a1e62f82c7190df40c1f5b21 upstream.

When changing the cpu affinity of an event it can happen today that
(with some unlucky timing) the same event will be handled on the old
and the new cpu at the same time.

Avoid that by adding an "event active" flag to the per-event data and
call the handler only if this flag isn't set.

Cc: stable@vger.kernel.org
Reported-by: Julien Grall &lt;julien@xen.org&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Julien Grall &lt;jgrall@amazon.com&gt;
Link: https://lore.kernel.org/r/20210306161833.4552-4-jgross@suse.com
Signed-off-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xen/events: don't unmask an event channel when an eoi is pending</title>
<updated>2021-03-17T15:10:19Z</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2021-03-15T08:55:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a8103671cc79610b121b0bdfd5cfdc7fa43de88e'/>
<id>urn:sha1:a8103671cc79610b121b0bdfd5cfdc7fa43de88e</id>
<content type='text'>
commit 25da4618af240fbec6112401498301a6f2bc9702 upstream.

An event channel should be kept masked when an eoi is pending for it.
When being migrated to another cpu it might be unmasked, though.

In order to avoid this keep three different flags for each event channel
to be able to distinguish "normal" masking/unmasking from eoi related
masking/unmasking and temporary masking. The event channel should only
be able to generate an interrupt if all flags are cleared.

Cc: stable@vger.kernel.org
Fixes: 54c9de89895e ("xen/events: add a new "late EOI" evtchn framework")
Reported-by: Julien Grall &lt;julien@xen.org&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Julien Grall &lt;jgrall@amazon.com&gt;
Reviewed-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Tested-by: Ross Lagerwall &lt;ross.lagerwall@citrix.com&gt;
Link: https://lore.kernel.org/r/20210306161833.4552-3-jgross@suse.com

[boris -- corrected Fixed tag format]

Signed-off-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>xen/events: reset affinity of 2-level event when tearing it down</title>
<updated>2021-03-17T15:10:19Z</updated>
<author>
<name>Juergen Gross</name>
<email>jgross@suse.com</email>
</author>
<published>2021-03-15T08:54:02Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9afae4bee6275dffdce3236a41e395030d482ffc'/>
<id>urn:sha1:9afae4bee6275dffdce3236a41e395030d482ffc</id>
<content type='text'>
commit 9e77d96b8e2724ed00380189f7b0ded61113b39f upstream.

When creating a new event channel with 2-level events the affinity
needs to be reset initially in order to avoid using an old affinity
from earlier usage of the event channel port. So when tearing an event
channel down reset all affinity bits.

The same applies to the affinity when onlining a vcpu: all old
affinity settings for this vcpu must be reset. As percpu events get
initialized before the percpu event channel hook is called,
resetting of the affinities happens after offlining a vcpu (this is
working, as initial percpu memory is zeroed out).

Cc: stable@vger.kernel.org
Reported-by: Julien Grall &lt;julien@xen.org&gt;
Signed-off-by: Juergen Gross &lt;jgross@suse.com&gt;
Reviewed-by: Julien Grall &lt;jgrall@amazon.com&gt;
Link: https://lore.kernel.org/r/20210306161833.4552-2-jgross@suse.com
Signed-off-by: Boris Ostrovsky &lt;boris.ostrovsky@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>iio: imu: adis16400: fix memory leak</title>
<updated>2021-03-17T15:10:18Z</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2021-03-13T17:29:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=10f675ec4eda0801791546980b35cc41589815aa'/>
<id>urn:sha1:10f675ec4eda0801791546980b35cc41589815aa</id>
<content type='text'>
commit 9c0530e898f384c5d279bfcebd8bb17af1105873 upstream.

In adis_update_scan_mode_burst, if adis-&gt;buffer allocation fails release
the adis-&gt;xfer.

Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Reviewed-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
[krzk: backport applied to adis16400_buffer.c instead of adis_buffer.c]
Signed-off-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>iio: imu: adis16400: release allocated memory on failure</title>
<updated>2021-03-17T15:10:18Z</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>krzysztof.kozlowski@canonical.com</email>
</author>
<published>2021-03-13T17:29:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9c8c498ae28e116f26509d72d0db667eb5414dac'/>
<id>urn:sha1:9c8c498ae28e116f26509d72d0db667eb5414dac</id>
<content type='text'>
From: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;

commit ab612b1daf415b62c58e130cb3d0f30b255a14d0 upstream.

In adis_update_scan_mode, if allocation for adis-&gt;buffer fails,
previously allocated adis-&gt;xfer needs to be released.

Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Reviewed-by: Alexandru Ardelean &lt;alexandru.ardelean@analog.com&gt;
Signed-off-by: Jonathan Cameron &lt;Jonathan.Cameron@huawei.com&gt;
Signed-off-by: Krzysztof Kozlowski &lt;krzysztof.kozlowski@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>hwmon: (lm90) Fix max6658 sporadic wrong temperature reading</title>
<updated>2021-03-17T15:10:18Z</updated>
<author>
<name>Boyang Yu</name>
<email>byu@arista.com</email>
</author>
<published>2019-06-28T19:06:36Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4b8b728400cc500b2111de82288856646a429b28'/>
<id>urn:sha1:4b8b728400cc500b2111de82288856646a429b28</id>
<content type='text'>
commit 62456189f3292c62f87aef363f204886dc1d4b48 upstream.

max6658 may report unrealistically high temperature during
the driver initialization, for which, its overtemp alarm pin
also gets asserted. For certain devices implementing overtemp
protection based on that pin, it may further trigger a reset to
the device. By reproducing the problem, the wrong reading is
found to be coincident with changing the conversion rate.

To mitigate this issue, set the stop bit before changing the
conversion rate and unset it thereafter. After such change, the
wrong reading is not reproduced. Apply this change only to the
max6657 kind for now, controlled by flag LM90_PAUSE_ON_CONFIG.

Signed-off-by: Boyang Yu &lt;byu@arista.com&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Cc: Paul Menzel &lt;pmenzel@molgen.mpg.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>block: rsxx: fix error return code of rsxx_pci_probe()</title>
<updated>2021-03-17T15:10:18Z</updated>
<author>
<name>Jia-Ju Bai</name>
<email>baijiaju1990@gmail.com</email>
</author>
<published>2021-03-10T03:30:17Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=490d393a949b40a38077030b7469ed3b7ea154e5'/>
<id>urn:sha1:490d393a949b40a38077030b7469ed3b7ea154e5</id>
<content type='text'>
[ Upstream commit df66617bfe87487190a60783d26175b65d2502ce ]

When create_singlethread_workqueue returns NULL to card-&gt;event_wq, no
error return code of rsxx_pci_probe() is assigned.

To fix this bug, st is assigned with -ENOMEM in this case.

Fixes: 8722ff8cdbfa ("block: IBM RamSan 70/80 device driver")
Reported-by: TOTE Robot &lt;oslab@tsinghua.edu.cn&gt;
Signed-off-by: Jia-Ju Bai &lt;baijiaju1990@gmail.com&gt;
Link: https://lore.kernel.org/r/20210310033017.4023-1-baijiaju1990@gmail.com
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sh_eth: fix TRSCER mask for R7S72100</title>
<updated>2021-03-17T15:10:17Z</updated>
<author>
<name>Sergey Shtylyov</name>
<email>s.shtylyov@omprussia.ru</email>
</author>
<published>2021-02-28T20:26:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b3565d78451249448e479ac46b5878fc1c201efa'/>
<id>urn:sha1:b3565d78451249448e479ac46b5878fc1c201efa</id>
<content type='text'>
[ Upstream commit 75be7fb7f978202c4c3a1a713af4485afb2ff5f6 ]

According  to  the RZ/A1H Group, RZ/A1M Group User's Manual: Hardware,
Rev. 4.00, the TRSCER register has bit 9 reserved, hence we can't use
the driver's default TRSCER mask.  Add the explicit initializer for
sh_eth_cpu_data::trscer_err_mask for R7S72100.

Fixes: db893473d313 ("sh_eth: Add support for r7s72100")
Signed-off-by: Sergey Shtylyov &lt;s.shtylyov@omprussia.ru&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>staging: comedi: pcl818: Fix endian problem for AI command data</title>
<updated>2021-03-17T15:10:17Z</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2021-02-23T14:30:50Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=963a800d7bcf4f84beaff2b35dd9b4d8202ee08e'/>
<id>urn:sha1:963a800d7bcf4f84beaff2b35dd9b4d8202ee08e</id>
<content type='text'>
commit 148e34fd33d53740642db523724226de14ee5281 upstream.

The analog input subdevice supports Comedi asynchronous commands that
use Comedi's 16-bit sample format.  However, the call to
`comedi_buf_write_samples()` is passing the address of a 32-bit integer
parameter.  On bigendian machines, this will copy 2 bytes from the wrong
end of the 32-bit value.  Fix it by changing the type of the parameter
holding the sample value to `unsigned short`.

[Note: the bug was introduced in commit edf4537bcbf5 ("staging: comedi:
pcl818: use comedi_buf_write_samples()") but the patch applies better to
commit d615416de615 ("staging: comedi: pcl818: introduce
pcl818_ai_write_sample()").]

Fixes: d615416de615 ("staging: comedi: pcl818: introduce pcl818_ai_write_sample()")
Cc: &lt;stable@vger.kernel.org&gt; # 4.0+
Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Link: https://lore.kernel.org/r/20210223143055.257402-10-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>staging: comedi: pcl711: Fix endian problem for AI command data</title>
<updated>2021-03-17T15:10:17Z</updated>
<author>
<name>Ian Abbott</name>
<email>abbotti@mev.co.uk</email>
</author>
<published>2021-02-23T14:30:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9bc4094e971608e3246ba436346c6d5e7ebd952a'/>
<id>urn:sha1:9bc4094e971608e3246ba436346c6d5e7ebd952a</id>
<content type='text'>
commit a084303a645896e834883f2c5170d044410dfdb3 upstream.

The analog input subdevice supports Comedi asynchronous commands that
use Comedi's 16-bit sample format.  However, the call to
`comedi_buf_write_samples()` is passing the address of a 32-bit integer
variable.  On bigendian machines, this will copy 2 bytes from the wrong
end of the 32-bit value.  Fix it by changing the type of the variable
holding the sample value to `unsigned short`.

Fixes: 1f44c034de2e ("staging: comedi: pcl711: use comedi_buf_write_samples()")
Cc: &lt;stable@vger.kernel.org&gt; # 3.19+
Signed-off-by: Ian Abbott &lt;abbotti@mev.co.uk&gt;
Link: https://lore.kernel.org/r/20210223143055.257402-9-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
