<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include/linux/mfd, branch v4.4.295</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.295</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.295'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2021-08-08T06:37:47Z</updated>
<entry>
<title>regulator: rt5033: Fix n_voltages settings for BUCK and LDO</title>
<updated>2021-08-08T06:37:47Z</updated>
<author>
<name>Axel Lin</name>
<email>axel.lin@ingics.com</email>
</author>
<published>2021-06-27T08:04:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=225f3feda296883f97bc76e593892a605faab31f'/>
<id>urn:sha1:225f3feda296883f97bc76e593892a605faab31f</id>
<content type='text'>
[ Upstream commit 6549c46af8551b346bcc0b9043f93848319acd5c ]

For linear regulators, the n_voltages should be (max - min) / step + 1.

Buck voltage from 1v to 3V, per step 100mV, and vout mask is 0x1f.
If value is from 20 to 31, the voltage will all be fixed to 3V.
And LDO also, just vout range is different from 1.2v to 3v, step is the
same. If value is from 18 to 31, the voltage will also be fixed to 3v.

Signed-off-by: Axel Lin &lt;axel.lin@ingics.com&gt;
Reviewed-by: ChiYuan Huang &lt;cy_huang@richtek.com&gt;
Link: https://lore.kernel.org/r/20210627080418.1718127-1-axel.lin@ingics.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>power: supply: ab8500: Fix an old bug</title>
<updated>2021-07-20T14:22:39Z</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2021-06-26T23:47:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=39c691ed533133e58d72408e00c9a88573c6e96c'/>
<id>urn:sha1:39c691ed533133e58d72408e00c9a88573c6e96c</id>
<content type='text'>
commit f1c74a6c07e76fcb31a4bcc1f437c4361a2674ce upstream.

Trying to get the AB8500 charging driver working I ran into a bit
of bitrot: we haven't used the driver for a while so errors in
refactorings won't be noticed.

This one is pretty self evident: use argument to the macro or we
end up with a random pointer to something else.

Cc: stable@vger.kernel.org
Cc: Krzysztof Kozlowski &lt;krzk@kernel.org&gt;
Cc: Marcus Cooper &lt;codekipper@gmail.com&gt;
Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core")
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>platform/chrome: cros_ec_dev - Fix security issue</title>
<updated>2021-03-24T09:57:00Z</updated>
<author>
<name>Gwendal Grignou</name>
<email>gwendal@chromium.org</email>
</author>
<published>2016-03-08T17:13:52Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9c53f0065310ac5e85f6f3b278b6a31e940f78f9'/>
<id>urn:sha1:9c53f0065310ac5e85f6f3b278b6a31e940f78f9</id>
<content type='text'>
commit 5d749d0bbe811c10d9048cde6dfebc761713abfd upstream.

Prevent memory scribble by checking that ioctl buffer size parameters
are sane.
Without this check, on 32 bits system, if .insize = 0xffffffff - 20 and
.outsize the amount to scribble, we would overflow, allocate a small
amounts and be able to write outside of the malloc'ed area.
Adding a hard limit allows argument checking of the ioctl. With the
current EC, it is expected .insize and .outsize to be at around 512 bytes
or less.

Signed-off-by: Gwendal Grignou &lt;gwendal@chromium.org&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>mfd: max8997: Enale irq-wakeup unconditionally</title>
<updated>2019-11-28T17:25:51Z</updated>
<author>
<name>Marek Szyprowski</name>
<email>m.szyprowski@samsung.com</email>
</author>
<published>2018-09-05T11:54:07Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=072404a1e46e0966aa17729909d2b493740eb591'/>
<id>urn:sha1:072404a1e46e0966aa17729909d2b493740eb591</id>
<content type='text'>
[ Upstream commit efddff27c886e729a7f84a7205bd84d7d4af7336 ]

IRQ wake up support for MAX8997 driver was initially configured by
respective property in pdata. However, after the driver conversion to
device-tree, setting it was left as 'todo'. Nowadays most of other PMIC MFD
drivers initialized from device-tree assume that they can be an irq wakeup
source, so enable it also for MAX8997. This fixes support for wakeup from
MAX8997 RTC alarm.

Signed-off-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Reviewed-by: Krzysztof Kozlowski &lt;krzk@kernel.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>
<entry>
<title>mfd: mc13xxx-core: Fix PMIC shutdown when reading ADC values</title>
<updated>2019-11-28T17:25:50Z</updated>
<author>
<name>Fabio Estevam</name>
<email>fabio.estevam@nxp.com</email>
</author>
<published>2018-08-28T20:02:40Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cbbffd64d9d4dae0e4f749735075b3dab357f7c1'/>
<id>urn:sha1:cbbffd64d9d4dae0e4f749735075b3dab357f7c1</id>
<content type='text'>
[ Upstream commit 55143439b7b501882bea9d95a54adfe00ffc79a3 ]

When trying to read any MC13892 ADC channel on a imx51-babbage board:

The MC13892 PMIC shutdowns completely.

After debugging this issue and comparing the MC13892 and MC13783
initializations done in the vendor kernel, it was noticed that the
CHRGRAWDIV bit of the ADC0 register was not being set.

This bit is set by default after power on, but the driver was
clearing it.

After setting this bit it is possible to read the ADC values correctly.

Signed-off-by: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Tested-by: Chris Healy &lt;cphealy@gmail.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>mfd: da9063: Fix OTP control register names to match datasheets for DA9063/63L</title>
<updated>2019-06-11T10:23:37Z</updated>
<author>
<name>Steve Twiss</name>
<email>stwiss.opensource@diasemi.com</email>
</author>
<published>2019-04-26T13:33:35Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=592a36c59f4cce88daee1423a973b4b215cfd8aa'/>
<id>urn:sha1:592a36c59f4cce88daee1423a973b4b215cfd8aa</id>
<content type='text'>
commit 6b4814a9451add06d457e198be418bf6a3e6a990 upstream.

Mismatch between what is found in the Datasheets for DA9063 and DA9063L
provided by Dialog Semiconductor, and the register names provided in the
MFD registers file. The changes are for the OTP (one-time-programming)
control registers. The two naming errors are OPT instead of OTP, and
COUNT instead of CONT (i.e. control).

Cc: Stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Steve Twiss &lt;stwiss.opensource@diasemi.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mfd: 88pm80x: Double shifting bug in suspend/resume</title>
<updated>2016-10-16T15:36:14Z</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2016-08-04T05:26:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0114e3e52730b76e0976a43ef496d4925eda1893'/>
<id>urn:sha1:0114e3e52730b76e0976a43ef496d4925eda1893</id>
<content type='text'>
commit 9a6dc644512fd083400a96ac4a035ac154fe6b8d upstream.

set_bit() and clear_bit() take the bit number so this code is really
doing "1 &lt;&lt; (1 &lt;&lt; irq)" which is a double shift bug.  It's done
consistently so it won't cause a problem unless "irq" is more than 4.

Fixes: 70c6cce04066 ('mfd: Support 88pm80x in 80x driver')
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>iio: adc: ti_am335x_adc: Increase timeout value waiting for ADC sample</title>
<updated>2016-09-24T08:07:38Z</updated>
<author>
<name>Vignesh R</name>
<email>vigneshr@ti.com</email>
</author>
<published>2016-08-17T12:13:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=023e76b1d1fd4857ba6af6e99dfbefd667aae6d1'/>
<id>urn:sha1:023e76b1d1fd4857ba6af6e99dfbefd667aae6d1</id>
<content type='text'>
commit 7175cce1c3f1d8c8840d2004f78f96a3904249b5 upstream.

Now that open delay and sample delay for each channel is configurable
via DT, the default IDLE_TIMEOUT value is not enough as this is
calculated based on hardcoded macros. This results in driver returning
EBUSY sometimes. Fix this by increasing the timeout
value based on maximum value possible to open delay and sample delays
for each channel.

Fixes: 5dc11e810676e ("iio: adc: ti_am335x_adc: make sample delay, open delay, averaging DT parameters")
Signed-off-by: Vignesh R &lt;vigneshr@ti.com&gt;
Acked-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Signed-off-by: Jonathan Cameron &lt;jic23@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mfd: cros_ec: Add cros_ec_cmd_xfer_status() helper</title>
<updated>2016-09-07T06:32:43Z</updated>
<author>
<name>Tomeu Vizoso</name>
<email>tomeu.vizoso@collabora.com</email>
</author>
<published>2016-07-15T23:28:41Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d91c348e4c3a011849e309cb76a6fdc714935ea4'/>
<id>urn:sha1:d91c348e4c3a011849e309cb76a6fdc714935ea4</id>
<content type='text'>
commit 9798ac6d32c1a32d6d92d853ff507d2d39c4300c upstream.

So that callers of cros_ec_cmd_xfer() don't have to repeat boilerplate
code when checking for errors from the EC side.

Signed-off-by: Tomeu Vizoso &lt;tomeu.vizoso@collabora.com&gt;
Reviewed-by: Benson Leung &lt;bleung@chromium.org&gt;
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Acked-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Tested-by: Enric Balletbo i Serra &lt;enric.balletbo@collabora.com&gt;
Signed-off-by: Thierry Reding &lt;thierry.reding@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>regulator: s2mps11: Fix invalid selector mask and voltages for buck9</title>
<updated>2016-05-19T00:06:51Z</updated>
<author>
<name>Krzysztof Kozlowski</name>
<email>k.kozlowski@samsung.com</email>
</author>
<published>2016-03-28T04:09:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fc2d8c98f754993f0c66d373672418a503e6e299'/>
<id>urn:sha1:fc2d8c98f754993f0c66d373672418a503e6e299</id>
<content type='text'>
commit 3b672623079bb3e5685b8549e514f2dfaa564406 upstream.

The buck9 regulator of S2MPS11 PMIC had incorrect vsel_mask (0xff
instead of 0x1f) thus reading entire register as buck9's voltage. This
effectively caused regulator core to interpret values as higher voltages
than they were and then to set real voltage much lower than intended.

The buck9 provides power to other regulators, including LDO13
and LDO19 which supply the MMC2 (SD card). On Odroid XU3/XU4 the lower
voltage caused SD card detection errors on Odroid XU3/XU4:
	mmc1: card never left busy state
	mmc1: error -110 whilst initialising SD card

During driver probe the regulator core was checking whether initial
voltage matches the constraints. With incorrect vsel_mask of 0xff and
default value of 0x50, the core interpreted this as 5 V which is outside
of constraints (3-3.775 V). Then the regulator core was adjusting the
voltage to match the constraints. With incorrect vsel_mask this new
voltage mapped to a vere low voltage in the driver.

Signed-off-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Reviewed-by: Javier Martinez Canillas &lt;javier@osg.samsung.com&gt;
Tested-by: Javier Martinez Canillas &lt;javier@osg.samsung.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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