<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers, branch v4.9.203</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.203</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.9.203'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-11-25T08:53:53+00:00</updated>
<entry>
<title>spi: rockchip: initialize dma_slave_config properly</title>
<updated>2019-11-25T08:53:53+00:00</updated>
<author>
<name>Huibin Hong</name>
<email>huibin.hong@rock-chips.com</email>
</author>
<published>2018-10-10T09:00:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c5e007b469c9b62807334504f79c3ca100a69a92'/>
<id>urn:sha1:c5e007b469c9b62807334504f79c3ca100a69a92</id>
<content type='text'>
[ Upstream commit dd8fd2cbc73f8650f651da71fc61a6e4f30c1566 ]

The rxconf and txconf structs are allocated on the
stack, so make sure we zero them before filling out
the relevant fields.

Signed-off-by: Huibin Hong &lt;huibin.hong@rock-chips.com&gt;
Signed-off-by: Emil Renner Berthing &lt;kernel@esmil.dk&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>misc: cxl: Fix possible null pointer dereference</title>
<updated>2019-11-25T08:53:52+00:00</updated>
<author>
<name>zhong jiang</name>
<email>zhongjiang@huawei.com</email>
</author>
<published>2018-10-04T05:02:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b8199f6a79919919fe043f719baffab13c585bf0'/>
<id>urn:sha1:b8199f6a79919919fe043f719baffab13c585bf0</id>
<content type='text'>
[ Upstream commit 3dac3583bf1a61db6aaf31dfd752c677a4400afd ]

It is not safe to dereference an object before a null test. It is
not needed and just remove them. Ftrace can be used instead.

Signed-off-by: zhong jiang &lt;zhongjiang@huawei.com&gt;
Acked-by: Andrew Donnellan &lt;andrew.donnellan@au1.ibm.com&gt;
Acked-by: Frederic Barrat &lt;fbarrat@linux.ibm.com&gt;
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>hwmon: (ina3221) Fix INA3221_CONFIG_MODE macros</title>
<updated>2019-11-25T08:53:51+00:00</updated>
<author>
<name>Nicolin Chen</name>
<email>nicoleotsuka@gmail.com</email>
</author>
<published>2018-09-29T21:44:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f3c5e428e08b6e40c9c1f2972ae1f78ab5b4e5c2'/>
<id>urn:sha1:f3c5e428e08b6e40c9c1f2972ae1f78ab5b4e5c2</id>
<content type='text'>
[ Upstream commit 791ebc9d34e9d212fc03742c31654b017d385926 ]

The three INA3221_CONFIG_MODE macros are not correctly defined here.
The MODE3-1 bits are located at BIT 2-0 according to the datasheet.

So this patch just fixes them by shifting all of them with a correct
offset. However, this isn't a crital bug fix as the driver does not
use any of them at this point.

Signed-off-by: Nicolin Chen &lt;nicoleotsuka@gmail.com&gt;
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>hwmon: (pwm-fan) Silence error on probe deferral</title>
<updated>2019-11-25T08:53:51+00:00</updated>
<author>
<name>Thierry Reding</name>
<email>treding@nvidia.com</email>
</author>
<published>2018-09-21T10:10:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=67592f93ee50b335cf15da64a5221b166a703aba'/>
<id>urn:sha1:67592f93ee50b335cf15da64a5221b166a703aba</id>
<content type='text'>
[ Upstream commit 9f67f7583e77fe5dc57aab3a6159c2642544eaad ]

Probe deferrals aren't actual errors, so silence the error message in
case the PWM cannot yet be acquired.

Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
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>spi: spidev: Fix OF tree warning logic</title>
<updated>2019-11-25T08:53:49+00:00</updated>
<author>
<name>Trent Piepho</name>
<email>tpiepho@impinj.com</email>
</author>
<published>2018-09-20T19:18:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2aa7816390d83f72d0e8e7c79b55bb653254bee6'/>
<id>urn:sha1:2aa7816390d83f72d0e8e7c79b55bb653254bee6</id>
<content type='text'>
[ Upstream commit 605b3bec73cbd74b4ac937b580cd0b47d1300484 ]

spidev will make a big fuss if a device tree node binds a device by
using "spidev" as the node's compatible property.

However, the logic for this isn't looking for "spidev" in the
compatible, but rather checking that the device is NOT compatible with
spidev's list of devices.

This causes a false positive if a device not named "rohm,dh2228fv", etc.
binds to spidev, even if a means other than putting "spidev" in the
device tree was used.  E.g., the sysfs driver_override attribute.

Signed-off-by: Trent Piepho &lt;tpiepho@impinj.com&gt;
Reviewed-by: Jan KundrÃ¡t &lt;jan.kundrat@cesnet.cz&gt;
Tested-by: Jan KundrÃ¡t &lt;jan.kundrat@cesnet.cz&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gpio: syscon: Fix possible NULL ptr usage</title>
<updated>2019-11-25T08:53:48+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2018-10-03T22:52:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=054bdd2855a3b8319390870613017cc97dda710b'/>
<id>urn:sha1:054bdd2855a3b8319390870613017cc97dda710b</id>
<content type='text'>
[ Upstream commit 70728c29465bc4bfa7a8c14304771eab77e923c7 ]

The priv-&gt;data-&gt;set can be NULL while flags contains GPIO_SYSCON_FEAT_OUT
and chip-&gt;set is valid pointer. This happens in case the controller uses
the default GPIO setter. Always use chip-&gt;set to access the setter to avoid
possible NULL pointer dereferencing.

Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: cx231xx: fix potential sign-extension overflow on large shift</title>
<updated>2019-11-25T08:53:47+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2018-10-06T18:01:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=97fe3401a6b8475f86bd49b8e4613413e601a109'/>
<id>urn:sha1:97fe3401a6b8475f86bd49b8e4613413e601a109</id>
<content type='text'>
[ Upstream commit 32ae592036d7aeaabcccb2b1715373a68639a768 ]

Shifting the u8 value[3] by an int can lead to sign-extension
overflow. For example, if value[3] is 0xff and the shift is 24 then it
is promoted to int and then the top bit is sign-extended so that all
upper 32 bits are set.  Fix this by casting value[3] to a u32 before
the shift.

Detected by CoverityScan, CID#1016522 ("Unintended sign extension")

Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")

Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>media: isif: fix a NULL pointer dereference bug</title>
<updated>2019-11-25T08:53:46+00:00</updated>
<author>
<name>Wenwen Wang</name>
<email>wang6495@umn.edu</email>
</author>
<published>2018-10-04T15:44:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0419fe5b7fed909853c53a81bb401fe268a362d4'/>
<id>urn:sha1:0419fe5b7fed909853c53a81bb401fe268a362d4</id>
<content type='text'>
[ Upstream commit a26ac6c1bed951b2066cc4b2257facd919e35c0b ]

In isif_probe(), there is a while loop to get the ISIF base address and
linearization table0 and table1 address. In the loop body, the function
platform_get_resource() is called to get the resource. If
platform_get_resource() returns NULL, the loop is terminated and the
execution goes to 'fail_nobase_res'. Suppose the loop is terminated at the
first iteration because platform_get_resource() returns NULL and the
execution goes to 'fail_nobase_res'. Given that there is another while loop
at 'fail_nobase_res' and i equals to 0, one iteration of the second while
loop will be executed. However, the second while loop does not check the
return value of platform_get_resource(). This can cause a NULL pointer
dereference bug if the return value is a NULL pointer.

This patch avoids the above issue by adding a check in the second while
loop after the call to platform_get_resource().

Signed-off-by: Wenwen Wang &lt;wang6495@umn.edu&gt;
Signed-off-by: Hans Verkuil &lt;hverkuil@xs4all.nl&gt;
Signed-off-by: Mauro Carvalho Chehab &lt;mchehab+samsung@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mfd: ti_am335x_tscadc: Keep ADC interface on if child is wakeup capable</title>
<updated>2019-11-25T08:53:45+00:00</updated>
<author>
<name>Vignesh R</name>
<email>vigneshr@ti.com</email>
</author>
<published>2018-06-30T10:33:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8bda8034e0ed45c51843777f0cab1e560a97bd3a'/>
<id>urn:sha1:8bda8034e0ed45c51843777f0cab1e560a97bd3a</id>
<content type='text'>
[ Upstream commit c974ac771479327b5424f60d58845e31daddadea ]

If a child device like touchscreen is wakeup capable, then keep ADC
interface on, so that a touching resistive screen will generate wakeup
event to the system.

Signed-off-by: Vignesh R &lt;vigneshr@ti.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>backlight: lm3639: Unconditionally call led_classdev_unregister</title>
<updated>2019-11-25T08:53:44+00:00</updated>
<author>
<name>Nathan Chancellor</name>
<email>natechancellor@gmail.com</email>
</author>
<published>2018-09-21T20:21:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1a103006eb3c61b21fbd49676a361f71b08d7e8a'/>
<id>urn:sha1:1a103006eb3c61b21fbd49676a361f71b08d7e8a</id>
<content type='text'>
[ Upstream commit 7cea645ae9c5a54aa7904fddb2cdf250acd63a6c ]

Clang warns that the address of a pointer will always evaluated as true
in a boolean context.

drivers/video/backlight/lm3639_bl.c:403:14: warning: address of
'pchip-&gt;cdev_torch' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (&amp;pchip-&gt;cdev_torch)
        ~~   ~~~~~~~^~~~~~~~~~
drivers/video/backlight/lm3639_bl.c:405:14: warning: address of
'pchip-&gt;cdev_flash' will always evaluate to 'true'
[-Wpointer-bool-conversion]
        if (&amp;pchip-&gt;cdev_flash)
        ~~   ~~~~~~~^~~~~~~~~~
2 warnings generated.

These statements have been present since 2012, introduced by
commit 0f59858d5119 ("backlight: add new lm3639 backlight
driver"). Given that they have been called unconditionally since
then presumably without any issues, removing the always true if
statements to fix the warnings without any real world changes.

Link: https://github.com/ClangBuiltLinux/linux/issues/119
Signed-off-by: Nathan Chancellor &lt;natechancellor@gmail.com&gt;
Reviewed-by: Daniel Thompson &lt;daniel.thompson@linaro.org&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
