Add a pincotrol driver for BCM6362. BCM6362 allows muxing individual
GPIO pins to the LED controller, to be available by the integrated
wifi, or other functions. It also supports overlay groups, of which
only NAND is documented.
Co-developed-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Link: https://lore.kernel.org/r/20210324081923.20379-14-noltari@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add binding documentation for the pincontrol core found in BCM6362 SoCs.
Co-developed-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210324081923.20379-12-noltari@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add a pincotrol driver for BCM6358. BCM6358 allow overlaying different
functions onto the GPIO pins. It does not support configuring individual
pins but only whole groups. These groups may overlap, and still require
the directions to be set correctly in the GPIO register. In addition the
functions register controls other, not directly mux related functions.
Co-developed-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Link: https://lore.kernel.org/r/20210324081923.20379-11-noltari@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add binding documentation for the pincontrol core found in BCM6358 SoCs.
Co-developed-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210324081923.20379-9-noltari@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add a pincontrol driver for BCM6328. BCM6328 supports muxing 32 pins as
GPIOs, as LEDs for the integrated LED controller, or various other
functions. Its pincontrol mux registers also control other aspects, like
switching the second USB port between host and device mode.
Co-developed-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Link: https://lore.kernel.org/r/20210324081923.20379-8-noltari@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Add binding documentation for the pincontrol core found in BCM6328 SoCs.
Co-developed-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210324081923.20379-6-noltari@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Convert existing BCM6345 GPIO binding documentation to YAML and add binding
documentation for the GPIO controller found in BCM6318, BCM6328, BCM6358,
BCM6362, BCM6368 and BCM63268 SoCs.
Co-developed-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20210324081923.20379-4-noltari@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This is needed for properly registering GPIO regmap as a child of a regmap
pin controller.
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Michael Walle <michael@walle.cc>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20210324081923.20379-3-noltari@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The current code doesn't check if GPIOLIB_IRQCHIP is enabled, which results in
a compilation error when trying to build gpio-regmap if CONFIG_GPIOLIB_IRQCHIP
isn't enabled.
Fixes: 6a45b0e258 ("gpiolib: Introduce gpiochip_irqchip_add_domain()")
Suggested-by: Michael Walle <michael@walle.cc>
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Michael Walle <michael@walle.cc>
Acked-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Link: https://lore.kernel.org/r/20210324081923.20379-2-noltari@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
It may happen that the MPU6050 is the only hardware
trigger available on your system such as this:
> lsiio
Device 003: hscdtd008a
Device 001: mpu6050
Device 002: gp2ap002
Device 000: ab8500-gpadc
Trigger 000: mpu6050-dev1
And when you want to use it to read periodically from
your magnetometer like this:
> iio_generic_buffer -a -c 100 -n hscdtd008a -t mpu6050-dev1
Then the following happens:
[ 209.951334] Internal error: Oops: 5 [#1] SMP ARM
(...)
[ 209.981969] Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support)
[ 209.988925] PC is at inv_scan_query_mpu6050+0x8/0xb8
[ 209.993914] LR is at inv_mpu6050_set_enable+0x40/0x194
This is because since we are not using any channels from the
same device, the indio_dev->active_scan_mask is NULL.
Just checking for that and bailing out is however not enough:
we have to enable some kind of FIFO for the readout to work.
So enable the temperature as a dummy FIFO and all works
fine.
Not suitable for backporting to stable. It is an odd corner case
and does not represent a regression.
Fixes: 09a642b785 ("Invensense MPU6050 Device Driver.")
Cc: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Link: https://lore.kernel.org/r/20210322132408.1003443-1-linus.walleij@linaro.org
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Whilst running some basic tests as part of writing up the dt-bindings for
this driver (to follow), it became clear it doesn't actually load
currently.
iio iio:device1: tried to double register : in_incli_x_index
adis16201 spi0.0: Failed to create buffer sysfs interfaces
adis16201: probe of spi0.0 failed with error -16
Looks like a cut and paste / update bug. Fixes tag obviously not accurate
but we don't want to bother carry thing back to before the driver moved
out of staging.
Fixes: 591298e54c ("Staging: iio: accel: adis16201: Move adis16201 driver out of staging")
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Cc: <Stable@vger.kernel.org>
Cc: Himanshu Jha <himanshujha199640@gmail.com>
Cc: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Link: https://lore.kernel.org/r/20210321182956.844652-1-jic23@kernel.org
Update DAC drivers powerdown attribute show callback to use the new
sysfs_emit() function.
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it
knows about the sysfs buffer specifics and has some built-in sanity checks.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210320071405.9347-5-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it
knows about the sysfs buffer specifics and has some built-in sanity checks.
Convert __iio_format_value() and related functions to use this new
interface.
This conversion involves changing the signature of __iio_format_value() so
that it similar to sysfs_emit_at() and takes the buffers start address and
an offset where to write within the buffer.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210320071405.9347-4-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it
knows about the sysfs buffer specifics and has some built-in sanity checks.
Convert the iio_enum_available_read() function to use sysfs_emit_at()
instead of scnprintf().
The conversion is straight forward, the only difference is that
sysfs_emit_at() takes the buffers start address and an offset as parameters
and already knows about the buffer's size limit.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210320071405.9347-3-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
sysfs_emit() is preferred over raw s*printf() for sysfs attributes since it
knows about the sysfs buffer specifics and has some built-in sanity checks.
This patch converts the places in the iio core that follow the pattern of
return s*printf(...)
to
return sysfs_emit(...)
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20210320071405.9347-2-lars@metafoo.de
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The plural of "matrix" is "matrices".
Signed-off-by: Guoqing Chi <chiguoqing@yulong.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Jean-Baptiste Maneyrol <jmaneyrol@invensense.com>
Link: https://lore.kernel.org/r/20210322013024.1849-1-chi962464zy@163.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Add a bitmap for available compression algorithms and a variable-sized
on-disk table for compression options in preparation for upcoming big
pcluster and LZMA algorithm, which follows the end of super block.
To parse the compression options, the bitmap is scanned one by one.
For each available algorithm, there is data followed by 2-byte `length'
correspondingly (it's enough for most cases, or entire fs blocks should
be used.)
With such available algorithm bitmap, kernel itself can also refuse to
mount such filesystem if any unsupported compression algorithm exists.
Note that COMPR_CFGS feature will be enabled with BIG_PCLUSTER.
Link: https://lore.kernel.org/r/20210329100012.12980-1-hsiangkao@aol.com
Reviewed-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Gao Xiang <hsiangkao@redhat.com>
In commit eb631bb5bf
("arm64: Support arch_irq_work_raise() via self IPIs") a new
function "arch_irq_work_raise" was added without a prototype.
In commit d914d4d497
("arm64: Implement panic_smp_self_stop()") a new
function "panic_smp_self_stop" was added without a prototype.
We get the following warnings on W=1:
arch/arm64/kernel/smp.c:842:6: warning: no previous prototype
for ‘arch_irq_work_raise’ [-Wmissing-prototypes]
arch/arm64/kernel/smp.c:862:6: warning: no previous prototype
for ‘panic_smp_self_stop’ [-Wmissing-prototypes]
Fix the warnings by:
1. Adding the prototype for 'arch_irq_work_raise' in irq_work.h
2. Adding the prototype for 'panic_smp_self_stop' in smp.h
Signed-off-by: Chen Lifu <chenlifu@huawei.com>
Link: https://lore.kernel.org/r/20210329034343.183974-1-chenlifu@huawei.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
UBI_GLUEBI is not so common and UBI_FASTMAP is used for several years.
Make them part of a modernization of UBI defconfig options.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Add this board as a module as it's useful for testing audio on multiple
AT91 boards.
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
[nicolas.ferre@microchip.com: adap to newer kernel]
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Include this driver as the USB-Ethernet chip is present on SAMA5D2-ICP
board.
Signed-off-by: Razvan Stefanescu <razvan.stefanescu@microchip.com>
[nicolas.ferre@microchip.com: update commit subject and message]
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Include as built-in as it's used by multiple boards.
Signed-off-by: Razvan Stefanescu <razvan.stefanescu@microchip.com>
[nicolas.ferre@microchip.com: adap to newer kernel]
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
This regulator is needed by several SoC or external peripherals on
different boards, providing required power rails. Make it built-in
to match usual use-cases.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
The SoC features a Hantro G1 compatible engine. Enable it by default, so
people can make use of it.
Keep it a module, as suggested by Nicolas
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20210311154055.3496076-11-emil.l.velikov@gmail.com
While enabling an extra config, I've noticed that savedefconfig produced
a notable delta. Split out the no-op changes for clarity sake.
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20210311154055.3496076-10-emil.l.velikov@gmail.com
When using the Loongson-3A4000 machine for serial port debugging,
there is no /dev/ttyUSB* output, which makes the serial port unavailable,
For convenience, we open this configuration.
zhangqing@loongson-pc:~$ cat /sys/firmware/lefi/boardinfo
Board Info
Manufacturer : THTF
Board Name : THTF-LS3A4000-7A1000-ML4A
Family : LOONGSON3
BIOS Info
Vendor : ZD tech
Version : ZD tech-V2.1.1
ROM Size : 4 KB
Release Date : 2020-06-29
zhangqing@loongson-pc:~$ lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 003: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 005 Device 002: ID 0c45:760b Microdia USB Keyboard
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Signed-off-by: Qing Zhang <zhangqing@loongson.cn>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
poly1305-core.S is an auto-generated file, so it should be ignored.
Fixes: a11d055e7a ("crypto: mips/poly1305 - incorporate OpenSSL/CRYPTOGAMS optimized implementation")
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
mt7621 has the following memory map:
0x0-0x1c000000: lower 448m memory
0x1c000000-0x2000000: peripheral registers
0x20000000-0x2400000: higher 64m memory
detect_memory_region in arch/mips/kernel/setup.c only adds the first
memory region and isn't suitable for 512m memory detection because
it may accidentally read the memory area for peripheral registers.
This commit adds memory detection capability for mt7621:
1. Add the highmem area when 512m is detected.
2. Guard memcmp from accessing peripheral registers:
This only happens when a user decided to change kernel load address
to 256m or higher address. Since this is a quite unusual case, we
just skip 512m testing and return 256m as memory size.
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
[Minor commit message reword, make mt7621_memory_detect static]
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
prom_soc_init is only called from prom_init in arch/mips/ralink/prom.c,
which is already annotated with __init, so annotate prom_soc_init with
__init too.
Signed-off-by: Ilya Lipnitskiy <ilya.lipnitskiy@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
When CAVIUM_OCTEON_SOC is enabled, and MTD is disabled,
Kbuild gives the following warning:
WARNING: unmet direct dependencies detected for MTD_COMPLEX_MAPPINGS
Depends on [n]: MTD [=n] && HAS_IOMEM [=y]
Selected by [y]:
- CAVIUM_OCTEON_SOC [=y] && <choice>
This is because CAVIUM_OCTEON_SOC selects MTD_COMPLEX_MAPPINGS,
without selecting or depending on MTD, despite MTD_COMPLEX_MAPPINGS
depending on MTD.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
When SB1XXX_CORELIS is enabled, COMPILE_TEST is disabled,
and DEBUG_KERNEL is disabled, Kbuild gives the
following warning:
WARNING: unmet direct dependencies detected for DEBUG_INFO
Depends on [n]: DEBUG_KERNEL [=n] && !COMPILE_TEST [=n]
Selected by [y]:
- SB1XXX_CORELIS [=y] && SIBYTE_SB1xxx_SOC [=y] && !COMPILE_TEST [=n]
This is because SB1XXX_CORELIS selects DEBUG_INFO without
selecting or depending on DEBUG_KERNEL, despite DEBUG_INFO
depending on DEBUG_KERNEL.
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
After commit 0ebeea8ca8 ("bpf: Restrict bpf_probe_read{, str}() only to
archs where they work"), bpf_probe_read{, str}() functions were no longer
available on MIPS, so there exist some errors when running bpf program:
root@linux:/home/loongson/bcc# python examples/tracing/task_switch.py
bpf: Failed to load program: Invalid argument
[...]
11: (85) call bpf_probe_read#4
unknown func bpf_probe_read#4
[...]
Exception: Failed to load BPF program count_sched: Invalid argument
ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE should be restricted to archs
with non-overlapping address ranges, but they can overlap in EVA mode
on MIPS, so select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE if !EVA in
arch/mips/Kconfig, otherwise the bpf old helper bpf_probe_read() will
not be available.
This is similar with the commit d195b1d1d1 ("powerpc/bpf: Enable
bpf_probe_read{, str}() on powerpc again").
Fixes: 0ebeea8ca8 ("bpf: Restrict bpf_probe_read{, str}() only to archs where they work")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Enable the analog filter for all I2C nodes of the stm32mp151.
Signed-off-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
The shrinker based approach still has some flaws. Especially that we need
temporary pages to free up the pages allocated to the driver is problematic
in a shrinker.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210324134845.2338-1-christian.koenig@amd.com
Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->clk_ops still
around to ease transition.
Remove handle->clock_priv now unused.
Link: https://lore.kernel.org/r/20210316124903.35011-18-cristian.marussi@arm.com
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.
Link: https://lore.kernel.org/r/20210316124903.35011-17-cristian.marussi@arm.com
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Port the scmi genpd driver to the new SCMI power interface based on
protocol handles and common devm_get_ops().
Link: https://lore.kernel.org/r/20210316124903.35011-16-cristian.marussi@arm.com
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->power_ops still
around to ease transition.
Remove handle->power_priv now unused.
Link: https://lore.kernel.org/r/20210316124903.35011-15-cristian.marussi@arm.com
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Now that all the SCMI driver users have been migrated to the new interface
remove the legacy interface and all the transient code.
Link: https://lore.kernel.org/r/20210316124903.35011-14-cristian.marussi@arm.com
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Port driver to the new SCMI perf interface based on protocol handles
and common devm_get_ops().
Link: https://lore.kernel.org/r/20210316124903.35011-13-cristian.marussi@arm.com
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Convert internals of protocol implementation to use protocol handles and
expose a new protocol operations interface for SCMI driver using the new
get/put common operations, while keeping the old handle->perf_ops still
around to ease transition.
Remove handle->perf_priv now unused.
Link: https://lore.kernel.org/r/20210316124903.35011-12-cristian.marussi@arm.com
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Port the SCMI base protocol to new protocol handles based interface.
Link: https://lore.kernel.org/r/20210316124903.35011-11-cristian.marussi@arm.com
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add an helper to access from a protocol handle, the SCMI version data
which is exposed on sysfs. Such helper will be needed by SCMI base
protocol initialization once it will be moved to new protocol handles
scheme.
Link: https://lore.kernel.org/r/20210316124903.35011-10-cristian.marussi@arm.com
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Add new core SCMI transfer operations based on protocol handles to
enable protocols to builds and send their own protocol specific messages.
Keep old original scmi_xfer_ operations interface as wrappers around the
new interface in order to let coexist old and new interfaces to ease
protocol by protocol migration.
In order to support such migration the above wrappers and some
additional transient code is also introduced in this commit. It will be
later removed as a whole once the full migration of protocols and SCMI
drivers will have been completed.
Link: https://lore.kernel.org/r/20210316124903.35011-9-cristian.marussi@arm.com
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
