IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Since commit cffa4b2122f5 ("regmap: debugfs: Fix a memory leak when
calling regmap_attach_dev"), the following debugfs error is seen
on i.MX boards:
debugfs: Directory 'dummy-iomuxc-gpr@20e0000' with parent 'regmap' already present!
In the attempt to fix the memory leak, the above commit added a NULL check
for map->debugfs_name. For the first debufs entry, map->debugfs_name is NULL
and then the new name is allocated via kasprintf().
For the second debugfs entry, map->debugfs_name() is no longer NULL, so
it will keep using the old entry name and the duplicate name error is seen.
Quoting Mark Brown:
"That means that if the device gets freed we'll end up with the old debugfs
file hanging around pointing at nothing.
...
To be more explicit this means we need a call to regmap_debugfs_exit()
which will clean up all the existing debugfs stuff before we loose
references to it."
Call regmap_debugfs_exit() prior to regmap_debugfs_init() to fix
the problem.
Tested on i.MX6Q and i.MX6SX boards.
Fixes: cffa4b2122f5 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev")
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Fabio Estevam <festevam@denx.de>
Link: https://lore.kernel.org/r/20220107163307.335404-1-festevam@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Some device requires a special handling for reg_update_bits and can't use
the normal regmap read write logic. An example is when locking is
handled by the device and rmw operations requires to do atomic operations.
Allow to declare a dedicated function in regmap_config for
reg_update_bits in no bus configuration.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20211104150040.1260-1-ansuelsmth@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The ls-extirq irqchip driver accesses regmap inside its implementation
of the struct irq_chip :: irq_set_type method, and currently regmap
only knows to lock using normal spinlocks. But the method above wants
raw spinlock context, so this isn't going to work and triggers a
"[ BUG: Invalid wait context ]" splat.
The best we can do given the arrangement of the code is to patch regmap
and the syscon driver: regmap to support raw spinlocks, and syscon to
request them on behalf of its ls-extirq consumer.
Link: https://lore.kernel.org/lkml/20210825135438.ubcuxm5vctt6ne2q@skbuf/T/#u
Vladimir Oltean (2):
regmap: teach regmap to use raw spinlocks if requested in the config
mfd: syscon: request a regmap with raw spinlocks for some devices
drivers/base/regmap/internal.h | 4 ++++
drivers/base/regmap/regmap.c | 35 +++++++++++++++++++++++++++++-----
drivers/mfd/syscon.c | 16 ++++++++++++++++
include/linux/regmap.h | 2 ++
4 files changed, 52 insertions(+), 5 deletions(-)
--
2.25.1
base-commit: 6efb943b8616ec53a5e444193dccf1af9ad627b5
Some drivers might access regmap in a context where a raw spinlock is
held. An example is drivers/irqchip/irq-ls-extirq.c, which calls
regmap_update_bits() from struct irq_chip :: irq_set_type, which is a
method called by __irq_set_trigger() under the desc->lock raw spin lock.
Since desc->lock is a raw spin lock and the regmap internal lock for
mmio is a plain spinlock (which can become sleepable on RT), this is an
invalid locking scheme and we get a splat stating that this is a
"[ BUG: Invalid wait context ]".
It seems reasonable for regmap to have an option use a raw spinlock too,
so add that in the config such that drivers can request it.
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20210825205041.927788-2-vladimir.oltean@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The reg_fields array fed to {devm_}regmap_field_bulk_alloc is currently
not const, which is not correct on semantics (the functions shouldn't
change reg_field contents) and prevents pre-defined const reg_field
array to be used.
As the implementation of this function doesn't change the content of it,
just add const to its prototype.
Signed-off-by: Icenowy Zheng <icenowy@sipeed.com>
Link: https://lore.kernel.org/r/20210802063741.76301-1-icenowy@sipeed.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This patch adds support for 7 bits register, 17 bits value type register
formating. This is used, for example, by the Analog Devices
ADMV1013/ADMV1014.
Signed-off-by: Antoniu Miclaus <antoniu.miclaus@analog.com>
Signed-off-by: Andrei Drimbarean <andrei.drimbarean@analog.com>
Message-Id: <20210526085223.14896-1-antoniu.miclaus@analog.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
_regmap_write can trigger a _regmap_select_page, which will call
another _regmap_write that will be executed first, but the log shows
the inverse order
Also, keep consistency with _regmap_read which only logs in case of
success
Signed-off-by: Lucas Tanure <tanureal@opensource.cirrus.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20201112150217.459844-1-tanureal@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Useful for devices with many fields.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl9yPoATHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0JsoB/9zhtYrqKbof0AKuMfEeO+pPo4dC/9l
O7ENgSXCb9PWy0auVpU62ISXBPadbbrQXXe3hJ1Zof5q17lYqbaLM7Uem3bxIYtc
0HHRIb49R1sP+99T2JB3RDu/ykzHJsfxCkLgMR5MvBgS5e3KKf0SqZgNSVTYT4Y5
oPt81sxW56Z8FLrLn0j1sVDXlro4/uBpDOcHyzgq4GWgQ6ACvnIOH+PQUTTcGBfT
LtIkRMO8mHNKsDCy9Qy12NRsaparIbYb7KKEY9IR+6TN+qJ/g5PJQcPmsU6b0NIl
pb7fv4IRTvPDaEPa1g20U88qkSE5H3PXp88R3y/JbSMuFJwWwS2AGwYd
=L+6w
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl9yPpwTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0PkDB/9ybt51NqJWyU3JaleY7otD2QvCmvl6
2dzpDncfjYZ8GOhvju74BQM9h/m9EHzb5FQ1yLMKEeICXZwxkDgHiqMLYLN1e6wx
ug5U6lvbT1TmeBa7IJYNNSGH2BKeIDM5Hm2zVvMpEJhF2Y9uAE0HqxjGL3CfbUOv
R2o2K3wgax83FfX86wmYNgkkp4Ri1qviD1Jr90zzFZRr0FAjiyrFHXdfdvK/wUx1
5n9wg+aIehQr1a8cKYQaqWd3HZR6pofmOj1cO4n/By+VEYRWaVds8OKUrqimZ2mE
moX9+ooY3eFdmS6kgtA31bgBFjKxfMNaTzTa4B3kikmxSOKMupQejBn9
=G3GG
-----END PGP SIGNATURE-----
Merge tag 'regmap-field-bulk-api' into regmap-5.10
regmap: Add a bulk field API
Useful for devices with many fields.
Usage of regmap_field_alloc becomes much overhead when number of fields
exceed more than 3.
QCOM LPASS driver has extensively converted to use regmap_fields.
Using new bulk api to allocate fields makes it much more cleaner code to read!
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Tested-by: Srinivasa Rao Mandadapu <srivasam@codeaurora.org>
Link: https://lore.kernel.org/r/20200925164856.10315-2-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
While not destroying mutexes doesn't lead to memory leaks, it's still
the correct thing to do for mutex debugging accounting.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200928120614.23172-1-brgl@bgdev.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
Many error paths in __regmap_init rely on ret being pre-initialised to
-EINVAL, add an extra initialisation in after the new call to
regmap_set_name.
Fixes: 94cc89eb8fa5 ("regmap: debugfs: Fix handling of name string for debugfs init delays")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200918152212.22200-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Non-incrementing writes can fail if register + length crosses page
border. However for non-incrementing writes we should not check for page
border crossing. Fix this by passing additional flag to _regmap_raw_write
and passing length to _regmap_select_page basing on the flag.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes: cdf6b11daa77 ("regmap: Add regmap_noinc_write API")
Link: https://lore.kernel.org/r/20200917153405.3139200-2-dmitry.baryshkov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Non-incrementing reads can fail if register + length crosses page
border. However for non-incrementing reads we should not check for page
border crossing. Fix this by passing additional flag to _regmap_raw_read
and passing length to _regmap_select_page basing on the flag.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Fixes: 74fe7b551f33 ("regmap: Add regmap_noinc_read API")
Link: https://lore.kernel.org/r/20200917153405.3139200-1-dmitry.baryshkov@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Fixes: 94cc89eb8fa5 ("regmap: debugfs: Fix handling of name string for debugfs init delays")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200918112002.15216-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In regmap_debugfs_init the initialisation of the debugfs is delayed
if the root node isn't ready yet. Most callers of regmap_debugfs_init
pass the name from the regmap_config, which is considered temporary
ie. may be unallocated after the regmap_init call returns. This leads
to a potential use after free, where config->name has been freed by
the time it is used in regmap_debugfs_initcall.
This situation can be seen on Zynq, where the architecture init_irq
callback registers a syscon device, using a local variable for the
regmap_config. As init_irq is very early in the platform bring up the
regmap debugfs root isn't ready yet. Although this doesn't crash it
does result in the debugfs entry not having the correct name.
Regmap already sets map->name from config->name on the regmap_init
path and the fact that a separate field is used to pass the name
to regmap_debugfs_init appears to be an artifact of the debugfs
name being added before the map name. As such this patch updates
regmap_debugfs_init to use map->name, which is already duplicated from
the config avoiding the issue.
This does however leave two lose ends, both regmap_attach_dev and
regmap_reinit_cache can be called after a regmap is registered and
would have had the effect of applying a new name to the debugfs
entries. In both of these cases it was chosen to update the map
name. In the case of regmap_attach_dev there are 3 users that
currently use this function to update the name, thus doing so avoids
changes for those users and it seems reasonable that attaching
a device would want to set the name of the map. In the case of
regmap_reinit_cache the primary use-case appears to be devices that
need some register access to identify the device (for example devices
in the same family) and then update the cache to match the exact
hardware. Whilst no users do currently update the name here, given the
use-case it seemed reasonable the name might want to be updated once
the device is better identified.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200917120828.12987-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Devices such as the AD5628 require 32 bits of data divided in 12 bits
for dummy, command and address, and 20 for data and dummy. Eg:
XXXXCCCCAAAADDDDDDDDDDDDDDDDXXXX
Where X is dont care, C is command, A is address and D is data bits.
Which would requierd the following regmap_config:
static const struct regmap_config config_dac = {
.reg_bits = 12,
.val_bits = 20,
.max_register = 0xff,
};
Signed-off-by: Ricardo Ribalda <ribalda@kernel.org>
Link: https://lore.kernel.org/r/20200917114727.1120373-1-ribalda@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Regmap can't sleep if spinlock is used for the locking protection.
This patch fixes regression caused by a previous commit that switched
regmap to use fsleep() and this broke Amlogic S922X platform.
This patch adds new configuration option for regmap users, allowing to
specify whether regmap operations can sleep and assuming that sleep is
allowed if mutex is used for the regmap locking protection.
Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
Fixes: 2b32d2f7ce0a ("regmap: Use flexible sleep")
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20200902141843.6591-1-digetx@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The multi-reg write function uses udelay(), which is a busy-loop based
delaying function that is not suitable for a long delays. Hence let's
replace the udelay() with fsleep(), which is flexible sleep function that
selects best delay function based on the delay-time.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20200830185356.5365-3-digetx@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
This function is used by dev_get_regmap() to retrieve a regmap for the
specified device. If the device has more than one regmap, the name parameter
can be used to specify one.
The code here uses a pointer comparison to check for equal strings. This
however will probably always fail, as the regmap->name is allocated via
kstrdup_const() from the regmap's config->name.
Fix this by using strcmp() instead.
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://lore.kernel.org/r/20200703103315.267996-1-mkl@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
When a register patch is registered the reg_sequence is copied but the
memory allocated is never freed. Add a kfree in regmap_exit to clean it
up.
Fixes: 22f0d90a3482 ("regmap: Support register patch sets")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20200617152129.19655-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are two spaces between arguments in regmap_fields_update_bits_base()
so remove one.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200615072507.11303-1-brgl@bgdev.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
The kerneldoc comment for regmap_test_bits() says that it returns -1 on
regmap_read() failure. This is not true - it will propagate the error
code returned by regmap_read(). Fix it.
Fixes: aa2ff9dbaedd ("regmap: provide helpers for simple bit operations")
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200607093421.22209-1-brgl@bgdev.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
The assembly and disassembly of data to be sent to or received from
a device invoke functions regmap_format_XX() and regmap_parse_XX()
that extract or insert data items from or into a buffer, using
assignments. In some cases the functions are called with a buffer
pointer with an odd address. On architectures with strict alignment
requirements this can result in a kernel crash. The assignments
have been replaced by functions that take alignment into account.
Signed-off-by: Jens Thoms Toerring <jt@toerring.de>
Link: https://lore.kernel.org/r/20200531095300.GA27570@toerring.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Bartosz Golaszewski <bgolaszewski@baylibre.com>:
From: Bartosz Golaszewski <bgolaszewski@baylibre.com>
I noticed that oftentimes I use regmap_update_bits() for simple bit
setting or clearing. In this case the fourth argument is superfluous as
it's always 0 or equal to the mask argument.
This series proposes to add simple bit operations for setting, clearing
and testing specific bits with regmap.
The second patch uses all three in a driver that got recently picked into
the net-next tree.
The patches obviously target different trees so - if you're ok with
the change itself - I propose you pick the first one into your regmap
tree for v5.8 and then I'll resend the second patch to add the first
user for these macros for v5.9.
v1 -> v2:
- convert the new macros to static inline functions
v2 -> v3:
- drop unneeded ternary operator
Bartosz Golaszewski (2):
regmap: provide helpers for simple bit operations
net: ethernet: mtk-star-emac: use regmap bitops
drivers/base/regmap/regmap.c | 22 +++++
drivers/net/ethernet/mediatek/mtk_star_emac.c | 80 ++++++++-----------
include/linux/regmap.h | 36 +++++++++
3 files changed, 93 insertions(+), 45 deletions(-)
base-commit: 8f3d9f354286745c751374f5f1fcafee6b3f3136
--
2.26.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.orghttp://lists.infradead.org/mailman/listinfo/linux-arm-kernel
In many instances regmap_update_bits() is used for simple bit setting
and clearing. In these cases the last argument is redundant and we can
hide it with a static inline function.
This adds three new helpers for simple bit operations: set_bits,
clear_bits and test_bits (the last one defined as a regular function).
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20200528154503.26304-2-brgl@bgdev.pl
Signed-off-by: Mark Brown <broonie@kernel.org>
When checking if a register block is writable we must ensure that the
block does not start with or contain a non incrementing register.
Fixes: 8b9f9d4dc511 ("regmap: verify if register is writeable before writing operations")
Signed-off-by: Ben Whitten <ben.whitten@gmail.com>
Link: https://lore.kernel.org/r/20200118205625.14532-1-ben.whitten@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
On buses like SlimBus and SoundWire which does not support
gather_writes yet in regmap, A bulk write on paged register
would be silently ignored after programming page.
This is because local variable 'ret' value in regmap_raw_write_impl()
gets reset to 0 once page register is written successfully and the
code below checks for 'ret' value to be -ENOTSUPP before linearising
the write buffer to send to bus->write().
Fix this by resetting the 'ret' value to -ENOTSUPP in cases where
gather_writes() is not supported or single register write is
not possible.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
There were a few files in the regmap code that did not have SPDX
identifiers on them, so fix that up. At the same time, remove the "free
form" text that specified the license of the file, as that is impossible
for any tool to properly parse.
Also, as Mark loves // comment markers, convert all of the headers to be
the same to make things look consistent :)
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
regmap provides a couple of ways to validate the register range used.
a) maxim allowed register, b) writable/readable register tables,
c) callback function that can be provided by the driver to validate
a register. regmap framework should verify if registers
are writeable before every write operation. However this doesn't
seems to happen in every situation.
The method `_regmap_raw_write_impl` is only using the `writeable_reg`
callback to verify if register is writeable, ignoring the other two.
This can lead to undefined behaviour since this allows to write to
registers that could be declared un-writeable by using any other
option.
Change `_regmap_raw_write_impl` to use the `regmap_writeable` method
to verify if registers are writable before the write operation.
Signed-off-by: Nandor Han <nandor.han@vaisala.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Move the checking of the LOG_DEVICE into a function to reduce the
number of #ifdefs and ensure more of the code gets compiled/checked,
and make it easier to change this for internal debugging purposes
(such as checking >1 device).
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regmap API had a noinc_read function added for instances where devices
supported returning data from an internal FIFO in a single read.
This commit adds the noinc_write variant to allow writing to a non
incrementing register, this is used in devices such as the sx1301 for
loading firmware.
Signed-off-by: Ben Whitten <ben.whitten@lairdtech.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Split regmap_config.use_single_rw into use_single_read and
use_single_write. This change enables drivers of devices which only
support bulk operations in one direction to use the regmap_bulk_*()
functions for both directions and have their bulk operation split into
single operations only when necessary.
Update all struct regmap_config instances where use_single_rw==true to
instead set both use_single_read and use_single_write. No attempt was
made to evaluate whether it is possible to set only one of
use_single_read or use_single_write.
Signed-off-by: David Frey <dpfrey@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The regmap API usually assumes that bulk read operations will read a
range of registers but some I2C/SPI devices have certain registers for
which a such a read operation will return data from an internal FIFO
instead. Add an explicit API to support bulk read without range semantics.
Some linux drivers use regmap_bulk_read or regmap_raw_read for such
registers, for example mpu6050 or bmi150 from IIO. This only happens to
work because when caching is disabled a single regmap read op will map
to a single bus read op (as desired). This breaks if caching is enabled and
reg+1 happens to be a cacheable register.
Without regmap support refactoring a driver to enable regmap caching
requires separate I2C and SPI paths. This is exactly what regmap is
supposed to help avoid.
Suggested-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Crestez Dan Leonard <leonard.crestez@intel.com>
Signed-off-by: Stefan Popa <stefan.popa@analog.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
The handling for the first two cases in regmap_bulk_write is
essentially identical. The first case is just a better implementation of
the second, supporting 8 byte registers and doing the locking manually to
avoid bouncing the lock for each register. Drop some redundant code by
removing the second of these cases and allowing both situations to be
handled by the same code.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Raw writes may need to be split into small chunks if max_raw_write is
set. Tidy up the code implementing this, the new code is slightly
clearer, slightly shorter and slightly more efficient.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Currently regmap_bulk_write will split a write into chunks before
calling regmap_raw_write if max_raw_write is set. It is more logical
for this handling to be inside regmap_raw_write itself, as this
removes the need to keep re-implementing the chunking code, which
would be the same for all users of regmap_raw_write.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
In the case were the bulk transaction is split up into smaller chunks
data is passed directly to regmap_raw_write. However regmap_bulk_write
uses data in host endian and regmap_raw_write expects data in device
endian. As such if the host and device differ in endian the wrong data
will be written to the device. Correct this issue using a similar
approach to the single raw write case below it, duplicate the data
into a new buffer and use parse_inplace to format the data correctly.
Fixes: adaac459759d ("regmap: Introduce max_raw_read/write for regmap_bulk_read/write")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
