Fix gcc build error while CONFIG_REGMAP_MMIO is not set
drivers/staging/fieldbus/anybuss/arcx-anybus.o: In function `controller_probe':
arcx-anybus.c: undefined reference to `__devm_regmap_init_mmio_clk'
Select REGMAP_MMIO to fix it.
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes: 2411a336c8 ("staging: fieldbus: arcx-anybus: change custom -> mmio regmap")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The arcx-anybus's registers are accessed via a memory-mapped
IO region. A regmap associated with this region is created
using custom reg_read() / reg_write() callbacks.
However, an abstraction which creates a memory-mapped IO
region backed regmap already exists: devm_regmap_init_mmio().
Replace the custom regmap with the existing kernel abstraction.
As a pleasant side-effect, sparse warnings now disappear.
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
wait_for_completion_timeout() returns unsigned long (0 on timeout or
remaining jiffies) not int. Assigning this return value to int may
theoretically overflow (though not in this case where TIMEOUT is
only HZ*2).
Fix this inconsistency by wrapping the wait_for_completion_timeout
into the if().
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Reviewed-by: Sven Van Asbroeck <TheSven73@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rename the anybus-s bus id from fieldbus_type to anybus_id, to
avoid confusion with an identically named variable in the
fieldbus_dev framework.
Although this value is called fieldbus_type in the anybus-s docs,
it acts like a bus id, so the name change is appropriate.
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
"Normal" bus structures such as USB or PCI keep device bus ids
in bus endinanness, and driver bus ids in host endianness.
Endianness conversion happens each time bus_match() is called.
Modify anybus-s to conform to this pattern. As a pleasant side-
effect, sparse warnings will now disappear.
This was suggested by Al Viro.
Link: https://lkml.org/lkml/2019/4/30/834
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Anybus-S PROFINET IRT communication module provides instant integration
to any Ethernet based LAN via SMTP, FTP, HTTP as well as PROFINET and
Modbus-TCP. Additional protocols can be implemented on top of TCP/IP
or UDP using the transparent socket interface.
Official documentation:
https://www.anybus.com/docs/librariesprovider7/default-document-library
/manuals-design-guides/hms-hmsi-168-52.pdf
This implementation is an Anybus-S client driver, designed to be
instantiated by the Anybus-S bus driver when it discovers the Profinet
card.
If loaded successfully, the driver registers itself as a fieldbus_dev,
and userspace can access it through the fieldbus_dev interface.
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add a driver for the Arcx anybus controller.
This device implements two Anybus-S hosts (buses),
and connects to the SoC via a parallel memory bus.
There is also a CAN power readout, unrelated to the Anybus,
modelled as a regulator.
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Anybus-S/Anybus-M is a series of interchangeable fieldbus communication
modules featuring on board memory and processing power. All software and
hardware functionality required to communicate on the fieldbus is
incorporated in the module itself, allowing the application to focus on
other tasks.
Typical applications are frequency inverters, HMI and visualization
devices, instruments, scales, robotics, PLC’s and intelligent measuring
devices.
Official documentation:
https://www.anybus.com/docs/librariesprovider7/default-document-library/
manuals-design-guides/hms-hmsi-27-275.pdf
Signed-off-by: Sven Van Asbroeck <TheSven73@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
YueHaibing