<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/base/regmap/regmap.c, branch v3.16.76</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.16.76</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.16.76'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2018-10-21T07:44:46+00:00</updated>
<entry>
<title>regmap: Don't use format_val in regmap_bulk_read</title>
<updated>2018-10-21T07:44:46+00:00</updated>
<author>
<name>Charles Keepax</name>
<email>ckeepax@opensource.cirrus.com</email>
</author>
<published>2018-02-12T18:15:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d7e412b847ad91de38b26ee7da7e9f90f99c87e8'/>
<id>urn:sha1:d7e412b847ad91de38b26ee7da7e9f90f99c87e8</id>
<content type='text'>
commit 9ae27a8d1f3ebff09191fb8cb1341414547293b2 upstream.

A bulk read can be implemented either through regmap_raw_read, or
by reading each register individually using regmap_read.  Both
regmap_read and regmap_bulk_read should return values in native
endian. In the individual case the current implementation calls
format_val to put the data into the output array, which can cause
endian issues. The regmap_read will have already converted the data
into native endian, if the hosts endian differs from the device then
format_val will switch the endian back again.

Rather than using format_val simply use the code that is called if
there is no format_val function. This code supports all cases except
24-bit but there don't appear to be any users of regmap_bulk_read for
24-bit. Additionally, it would have to be a big endian host for the
old code to actually function correctly anyway.

Fixes: 15b8d2c41fe5 ("regmap: Fix regmap_bulk_read in BE mode")
Reported-by: David Rhodes &lt;david.rhodes@cirrus.com&gt;
Signed-off-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
[bwh: Backported to 3.16:
 - 64-bit I/O is not supported
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>regmap: Support bulk reads for devices without raw formatting</title>
<updated>2018-10-21T07:44:46+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@kernel.org</email>
</author>
<published>2015-08-28T19:04:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d7fc5abb728e2d489d0e060a0781329fccde76f2'/>
<id>urn:sha1:d7fc5abb728e2d489d0e060a0781329fccde76f2</id>
<content type='text'>
commit d5b98eb12420ce856caaf57dc5256eedc56a3747 upstream.

When doing a bulk read from a device which lacks raw I/O support we fall
back to doing register at a time reads but we still use the raw
formatters in order to render the data into the word size used by the
device (since bulk reads still operate on the device word size rather
than unsigned ints).  This means that devices without raw formatting
such as those that provide reg_read() are not supported.  Provide
handling for them by copying the values read into native endian values
of the appropriate size.

Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>regmap: Correct offset handling in regmap_volatile_range</title>
<updated>2018-10-21T07:44:46+00:00</updated>
<author>
<name>Charles Keepax</name>
<email>ckeepax@opensource.cirrus.com</email>
</author>
<published>2018-02-12T18:15:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1b5b9da8552bbfb29113a93cbd4a87b66e35d6a6'/>
<id>urn:sha1:1b5b9da8552bbfb29113a93cbd4a87b66e35d6a6</id>
<content type='text'>
commit b8f9a03b741ddfdde4aa8b607fa7d88eb63a6338 upstream.

The current implementation is broken for regmaps that have a reg_stride,
since it doesn't take the stride into account. Correct this by using the
helper function to calculate the register offset.

Fixes: f01ee60fffa4 ("regmap: implement register striding")
Signed-off-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
[bwh: Backported to 3.16: Use simple multiplication instead of
 regmap_get_offset()]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>regmap: Fix possible shift overflow in regmap_field_init()</title>
<updated>2015-07-15T09:00:37+00:00</updated>
<author>
<name>Maxime Coquelin</name>
<email>maxime.coquelin@st.com</email>
</author>
<published>2015-06-16T11:53:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5bfa73eeb0dc99db9cef974299f74a38518904a3'/>
<id>urn:sha1:5bfa73eeb0dc99db9cef974299f74a38518904a3</id>
<content type='text'>
commit 921cc29473a0d7c109105c1876ddb432f4a4be7d upstream.

The way the mask is generated in regmap_field_init() is wrong.
Indeed, a field initialized with msb = 31 and lsb = 0 provokes a shift
overflow while calculating the mask field.

On some 32 bits architectures, such as x86, the generated mask is 0,
instead of the expected 0xffffffff.

This patch uses GENMASK() to fix the problem, as this macro is already safe
regarding shift overflow.

Signed-off-by: Maxime Coquelin &lt;maxime.coquelin@st.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>regmap: Fix regmap_bulk_read in BE mode</title>
<updated>2015-07-15T09:00:35+00:00</updated>
<author>
<name>Arun Chandran</name>
<email>achandran@mvista.com</email>
</author>
<published>2015-06-15T10:29:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1f78583b4d4535d941b9d5eeafb7197e19adf82d'/>
<id>urn:sha1:1f78583b4d4535d941b9d5eeafb7197e19adf82d</id>
<content type='text'>
commit 15b8d2c41fe5839582029f65c5f7004db451cc2b upstream.

In big endian mode regmap_bulk_read gives incorrect data
for byte reads.

This is because memcpy of a single byte from an address
after full word read gives different results when
endianness differs. ie. we get little-end in LE and big-end in BE.

Signed-off-by: Arun Chandran &lt;achandran@mvista.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>regmap: introduce regmap_name to fix syscon regmap trace events</title>
<updated>2015-04-10T09:03:57+00:00</updated>
<author>
<name>Philipp Zabel</name>
<email>p.zabel@pengutronix.de</email>
</author>
<published>2015-03-09T11:20:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2f55b0b64dab9063fd0ce63bb810b6beb7133d24'/>
<id>urn:sha1:2f55b0b64dab9063fd0ce63bb810b6beb7133d24</id>
<content type='text'>
commit c6b570d97c0e77f570bb6b2ed30d372b2b1e9aae upstream.

This patch fixes a NULL pointer dereference when enabling regmap event
tracing in the presence of a syscon regmap, introduced by commit bdb0066df96e
("mfd: syscon: Decouple syscon interface from platform devices").
That patch introduced syscon regmaps that have their dev field set to NULL.
The regmap trace events expect it to point to a valid struct device and feed
it to dev_name():

  $ echo 1 &gt; /sys/kernel/debug/tracing/events/regmap/enable

  Unable to handle kernel NULL pointer dereference at virtual address 0000002c
  pgd = 80004000
  [0000002c] *pgd=00000000
  Internal error: Oops: 17 [#1] SMP ARM
  Modules linked in: coda videobuf2_vmalloc
  CPU: 0 PID: 304 Comm: kworker/0:2 Not tainted 4.0.0-rc2+ #9197
  Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
  Workqueue: events_freezable thermal_zone_device_check
  task: 9f25a200 ti: 9f1ee000 task.ti: 9f1ee000
  PC is at ftrace_raw_event_regmap_block+0x3c/0xe4
  LR is at _regmap_raw_read+0x1bc/0x1cc
  pc : [&lt;803636e8&gt;]    lr : [&lt;80365f2c&gt;]    psr: 600f0093
  sp : 9f1efd78  ip : 9f1efdb8  fp : 9f1efdb4
  r10: 00000004  r9 : 00000001  r8 : 00000001
  r7 : 00000180  r6 : 00000000  r5 : 9f00e3c0  r4 : 00000003
  r3 : 00000001  r2 : 00000180  r1 : 00000000  r0 : 9f00e3c0
  Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
  Control: 10c5387d  Table: 2d91004a  DAC: 00000015
  Process kworker/0:2 (pid: 304, stack limit = 0x9f1ee210)
  Stack: (0x9f1efd78 to 0x9f1f0000)
  fd60:                                                       9f1efda4 9f1efd88
  fd80: 800708c0 805f9510 80927140 800f0013 9f1fc800 9eb2f490 00000000 00000180
  fda0: 808e3840 00000001 9f1efdfc 9f1efdb8 80365f2c 803636b8 805f8958 800708e0
  fdc0: a00f0013 803636ac 9f16de00 00000180 80927140 9f1fc800 9f1fc800 9f1efe6c
  fde0: 9f1efe6c 9f732400 00000000 00000000 9f1efe1c 9f1efe00 80365f70 80365d7c
  fe00: 80365f3c 9f1fc800 9f1fc800 00000180 9f1efe44 9f1efe20 803656a4 80365f48
  fe20: 9f1fc800 00000180 9f1efe6c 9f1efe6c 9f732400 00000000 9f1efe64 9f1efe48
  fe40: 803657bc 80365634 00000001 9e95f910 9f1fc800 9f1efeb4 9f1efe8c 9f1efe68
  fe60: 80452ac0 80365778 9f1efe8c 9f1efe78 9e93d400 9e93d5e8 9f1efeb4 9f72ef40
  fe80: 9f1efeac 9f1efe90 8044e11c 80452998 8045298c 9e93d608 9e93d400 808e1978
  fea0: 9f1efecc 9f1efeb0 8044fd14 8044e0d0 ffffffff 9f25a200 9e93d608 9e481380
  fec0: 9f1efedc 9f1efed0 8044fde8 8044fcec 9f1eff1c 9f1efee0 80038d50 8044fdd8
  fee0: 9f1ee020 9f72ef40 9e481398 00000000 00000008 9f72ef54 9f1ee020 9f72ef40
  ff00: 9e481398 9e481380 00000008 9f72ef40 9f1eff5c 9f1eff20 80039754 80038bfc
  ff20: 00000000 9e481380 80894100 808e1662 00000000 9e4f2ec0 00000000 9e481380
  ff40: 800396f8 00000000 00000000 00000000 9f1effac 9f1eff60 8003e020 80039704
  ff60: ffffffff 00000000 ffffffff 9e481380 00000000 00000000 9f1eff78 9f1eff78
  ff80: 00000000 00000000 9f1eff88 9f1eff88 9e4f2ec0 8003df30 00000000 00000000
  ffa0: 00000000 9f1effb0 8000eb60 8003df3c 00000000 00000000 00000000 00000000
  ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
  ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff
  Backtrace:
  [&lt;803636ac&gt;] (ftrace_raw_event_regmap_block) from [&lt;80365f2c&gt;] (_regmap_raw_read+0x1bc/0x1cc)
   r9:00000001 r8:808e3840 r7:00000180 r6:00000000 r5:9eb2f490 r4:9f1fc800
  [&lt;80365d70&gt;] (_regmap_raw_read) from [&lt;80365f70&gt;] (_regmap_bus_read+0x34/0x6c)
   r10:00000000 r9:00000000 r8:9f732400 r7:9f1efe6c r6:9f1efe6c r5:9f1fc800
   r4:9f1fc800
  [&lt;80365f3c&gt;] (_regmap_bus_read) from [&lt;803656a4&gt;] (_regmap_read+0x7c/0x144)
   r6:00000180 r5:9f1fc800 r4:9f1fc800 r3:80365f3c
  [&lt;80365628&gt;] (_regmap_read) from [&lt;803657bc&gt;] (regmap_read+0x50/0x70)
   r9:00000000 r8:9f732400 r7:9f1efe6c r6:9f1efe6c r5:00000180 r4:9f1fc800
  [&lt;8036576c&gt;] (regmap_read) from [&lt;80452ac0&gt;] (imx_get_temp+0x134/0x1a4)
   r6:9f1efeb4 r5:9f1fc800 r4:9e95f910 r3:00000001
  [&lt;8045298c&gt;] (imx_get_temp) from [&lt;8044e11c&gt;] (thermal_zone_get_temp+0x58/0x74)
   r7:9f72ef40 r6:9f1efeb4 r5:9e93d5e8 r4:9e93d400
  [&lt;8044e0c4&gt;] (thermal_zone_get_temp) from [&lt;8044fd14&gt;] (thermal_zone_device_update+0x34/0xec)
   r6:808e1978 r5:9e93d400 r4:9e93d608 r3:8045298c
  [&lt;8044fce0&gt;] (thermal_zone_device_update) from [&lt;8044fde8&gt;] (thermal_zone_device_check+0x1c/0x20)
   r5:9e481380 r4:9e93d608
  [&lt;8044fdcc&gt;] (thermal_zone_device_check) from [&lt;80038d50&gt;] (process_one_work+0x160/0x3d4)
  [&lt;80038bf0&gt;] (process_one_work) from [&lt;80039754&gt;] (worker_thread+0x5c/0x4f4)
   r10:9f72ef40 r9:00000008 r8:9e481380 r7:9e481398 r6:9f72ef40 r5:9f1ee020
   r4:9f72ef54
  [&lt;800396f8&gt;] (worker_thread) from [&lt;8003e020&gt;] (kthread+0xf0/0x108)
   r10:00000000 r9:00000000 r8:00000000 r7:800396f8 r6:9e481380 r5:00000000
   r4:9e4f2ec0
  [&lt;8003df30&gt;] (kthread) from [&lt;8000eb60&gt;] (ret_from_fork+0x14/0x34)
   r7:00000000 r6:00000000 r5:8003df30 r4:9e4f2ec0
  Code: e3140040 1a00001a e3140020 1a000016 (e596002c)
  ---[ end trace 193c15c2494ec960 ]---

Fixes: bdb0066df96e (mfd: syscon: Decouple syscon interface from platform devices)
Signed-off-by: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Luis Henriques &lt;luis.henriques@canonical.com&gt;
</content>
</entry>
<entry>
<title>regmap: fix possible ZERO_SIZE_PTR pointer dereferencing error.</title>
<updated>2014-10-30T16:40:11+00:00</updated>
<author>
<name>Xiubo Li</name>
<email>Li.Xiubo@freescale.com</email>
</author>
<published>2014-09-28T09:09:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a1773cfd11c520bffe18bd23233eacacac2f5be9'/>
<id>urn:sha1:a1773cfd11c520bffe18bd23233eacacac2f5be9</id>
<content type='text'>
commit d6b41cb06044a7d895db82bdd54f6e4219970510 upstream.

Since we cannot make sure the 'val_count' will always be none zero
here, and then if it equals to zero, the kmemdup() will return
ZERO_SIZE_PTR, which equals to ((void *)16).

So this patch fix this with just doing the zero check before calling
kmemdup().

Signed-off-by: Xiubo Li &lt;Li.Xiubo@freescale.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>
<entry>
<title>regmap: fix NULL pointer dereference in _regmap_write/read</title>
<updated>2014-10-30T16:40:11+00:00</updated>
<author>
<name>Pankaj Dubey</name>
<email>pankaj.dubey@samsung.com</email>
</author>
<published>2014-09-27T04:17:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=07ab621703f543a9628aaed7046970a4ff27aa83'/>
<id>urn:sha1:07ab621703f543a9628aaed7046970a4ff27aa83</id>
<content type='text'>
commit 5336be8416a71b5568d2cf54a2f2066abe9f2a53 upstream.

If LOG_DEVICE is defined and map-&gt;dev is NULL it will lead to NULL
pointer dereference. This patch fixes this issue by adding check for
dev-&gt;NULL in all such places in regmap.c

Signed-off-by: Pankaj Dubey &lt;pankaj.dubey@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>
<entry>
<title>regmap: Fix handling of volatile registers for format_write() chips</title>
<updated>2014-10-05T20:41:03+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@linaro.org</email>
</author>
<published>2014-08-26T11:12:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=081f1af7d8481219ee8ba1ef19446565cf707631'/>
<id>urn:sha1:081f1af7d8481219ee8ba1ef19446565cf707631</id>
<content type='text'>
commit 5844a8b9d98ec11ce1d77610daacf3f0a0e14715 upstream.

A previous over-zealous factorisation of code means that we only treat
registers as volatile if they are readable. For most devices this is fine
since normally most registers can be read and volatility implies
readability but for format_write() devices where there is no readback from
the hardware and we use volatility to mean simply uncacheability this means
that we end up treating all registers as cacheble.

A bigger refactoring of the code to clarify this is in order but as a fix
make a minimal change and only check readability when checking volatility
if there is no format_write() operation defined for the device.

Signed-off-by: Mark Brown &lt;broonie@linaro.org&gt;
Tested-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge remote-tracking branch 'regmap/topic/smbus' into regmap-next</title>
<updated>2014-06-02T16:07:42+00:00</updated>
<author>
<name>Mark Brown</name>
<email>broonie@linaro.org</email>
</author>
<published>2014-06-02T16:07:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ef98ae45e6b3ea17d3ed27cec9afdd7e46f916ae'/>
<id>urn:sha1:ef98ae45e6b3ea17d3ed27cec9afdd7e46f916ae</id>
<content type='text'>
</content>
</entry>
</feed>
