This aims to deprecate the "raw" sysfs file used for directly
accessing the CFAM and instead use a char device like the
other sub drivers.

Since it reworks the slave creation code and adds a cfam device
type, we also use the opportunity to convert the attributes
to attribute groups and add a couple more.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This converts FSI scom to use the new fsi-core controlled
chardev allocator and use a real cdev instead of a miscdev.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This converts FSI sbefifo to use the new fsi-core controlled
chardev allocator and use a real cdev instead of a miscdev.

One side effect is to fix the object lifetime by removing
the use of devm_kzalloc() for something that contains kobjects,
and using proper reference counting.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The various FSI devices (sbefifo, occ, scom, more to come)
currently use misc devices.

This is problematic as the minor device space for misc is
limited and there can be a lot of them. Also it limits our
ability to move them to a dedicated /dev/fsi directory or
to be smart about device naming and numbering.

It also means we have IDAs on every single of these drivers

This creates a common fsi "device_type" for the optional
/dev/fsi grouping and a dev_t allocator for all FSI devices.

"Legacy" devices get to use a backward compatible numbering
scheme (as long as chip id <16 and there's only one copy
of a given unit type per chip).

A single major number and a single IDA are shared for all
FSI devices.

This doesn't convert the FSI device drivers to use the new
scheme yet, they will be converted individually.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

s390 defines a global dump_trace() symbol. Rename ours to
dump_ucode_trace() to avoid a collision in build tests.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

In case memory resources for *fw* were allocated, release them
before return.

Addresses-Coverity-ID: 1472044 ("Resource leak")
Fixes: 6a794a27 ("fsi: master-ast-cf: Add new FSI master using Aspeed ColdFire")
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Then reading the RTAG/RCRC "registers" from the coprocessor after
a command is complete, mask out the top bits, only keep the relevant
bits. Microcode v5 will leave garbage in those top bits as a
result of a performance optimization.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
---

A couple of places forgot the 'z' qualifier for dev_dbg
when printing a size_t
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

They get retrieved from the device-tree and exposed
as an attribute in sysfs
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This represents a physical chip in the system and allows
a stable numbering scheme to be passed to udev for userspace
to recognize which chip is which.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NRob Herring <robh@kernel.org>

Some of the exit path missed the unlock. Move the mutex to
an outer function to avoid the problem completely
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The Aspeed AST2x00 can contain a ColdFire v1 coprocessor which
is currently unused on OpenPower systems.

This adds an alternative to the fsi-master-gpio driver that
uses that coprocessor instead of bit banging from the ARM
core itself. The end result is about 4 times faster.

The firmware for the coprocessor and its source code can be
found at https://github.com/ozbenh/cf-fsi and is system specific.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This isn't per-se a real device, it's a pseudo-device that
represents the use of the Aspeed built-in ColdFire to
implement the FSI protocol by bitbanging the GPIOs instead
of doing it from the ARM core.

Thus it's a drop-in replacement for the existing
fsi-master-gpio pseudo-device for use on systems based
on the Aspeed chips. It has most of the same properties,
plus some more needed to operate the coprocessor.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NRob Herring <robh@kernel.org>

There are still quite a few cases where a device might want
to get to a different node of the device-tree, obtain the
resources and map them.

We have of_iomap() and of_io_request_and_map() but they both
have shortcomings, such as not returning the size of the
resource found (which can be useful) and not being "managed".

This adds a devm_of_iomap() that provides all of these and
should probably replace uses of the above in most drivers.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>

Merge the GPIO tree "ib-aspeed" topic branch which contains pre-requisites
for subsequent changes. This branch is also in gpio "next".

This moves the definitions for various protocol details
(message & response codes, delays etc...) out of
fsi-master-gpio.c to fsi-master.h in order to share them
with other master implementations.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>

The embedded struct device needs a release function to be
able to successfully remove the driver.

We remove the devm_gpiod_put() as they are unnecessary
(the resources will be released automatically) and because
fsi_master_unregister() will cause the master structure to
be freed.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>

In the error path of fsi_master_register(), we currently
use device_unregister(). This will cause the last reference
to the structure to be dropped, thus freeing the enclosing
structure, which isn't what the callers want.

Use device_del() instead so that we return to the caller
with a refcount of 1. The caller can then assume that it
must use put_device() after a call to fsi_master_register()
regardless of whether the latter suceeded or failed.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

Some definitions are generic to the FSI protocol or any
give master implementation. Rename them to remove the
"GPIO" prefix in preparation for moving them to a common
header.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>

# Conflicts:
#	drivers/fsi/fsi-master-gpio.c

Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>

This adds a few more tracepoints that have proven useful when
debugging issues with the FSI bus.

This also makes echo_delay() use clock_zeros() instead of
open-code it in order to share the tracepoint.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>

To configure the send and echo delays
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>

What the driver called "FSI_GPIO_PRIME_SLAVE_CLOCKS" is what
the FSI spec calls tSendDelay and should be 16 clocks by
default.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>

Those values control the amount of "dummy" clocks between commands and
between a command and its response.

This adds a way to configure them from sysfs (to be later extended to
defaults in the device-tree). The default remains 16 (the HW default).

This is only supported if the backend supports the new link_config()
callback to configure the generation of those delays.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
---

Move fsi_slave_set_smode() and its helpers to before it's
first user and remove the corresponding forward declaration.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>

"dev" is dereferences before it's checked.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

The driver calls of_platform_device_create() which is only available
if OF_ADDRESS is enabled. When building sparc64 images, this results
in

ERROR: "of_platform_device_create" [drivers/fsi/fsi-sbefifo.ko] undefined!

Fixes: 9f4a8a2d ("fsi/sbefifo: Add driver for the SBE FIFO")
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

There was no unlock of the FFDC mutex.

Fixes: 9f4a8a2d ("fsi/sbefifo: Add driver for the SBE FIFO")
Signed-off-by: NEddie James <eajames@linux.vnet.ibm.com>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

On the Aspeed chip, the GPIOs can be under control of the ARM
chip or of the ColdFire coprocessor. (There's a third command
source, the LPC bus, which we don't use or support yet).

The control of which master is allowed to modify a given
GPIO is per-bank (8 GPIOs).

Unfortunately, systems already exist for which we want to
use GPIOs of both sources in the same bank.

This provides an API exported by the gpio-aspeed driver
that an aspeed coprocessor driver can use to "grab" some
GPIOs for use by the coprocessor, and allow the coprocessor
driver to provide callbacks for arbitrating access.

Once at least one GPIO of a given bank has been "grabbed"
by the coprocessor, the entire bank is marked as being
under coprocessor control. It's command source is switched
to the coprocessor.

If the ARM then tries to write to a GPIO in such a marked bank,
the provided callbacks are used to request access from the
coprocessor driver, which is responsible to doing whatever
is necessary to "pause" the coprocessor or prevent it from
trying to use the GPIOs while the ARM is doing its accesses.

During that time, the command source for the bank is temporarily
switched back to the ARM.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Reviewed-by: NAndrew Jeffery <andrew@aj.id.au>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This adds the definitions for the command source registers
and a helper to set them.

Those registers allow to control which bus master on the
SoC is allowed to modify a given bank of GPIOs and will
be used by subsequent patches.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Reviewed-by: NAndrew Jeffery <andrew@aj.id.au>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The Aspeed GPIO hardware has a quirk: the value register, for an
output GPIO, doesn't contain the last value written (the write
latch content) but the sampled input value.

This means that when reading back shortly after writing, you can
get an incorrect value as the input value is delayed by a few
synchronizers.

The HW supports a separate read-only register "Data Read Register"
which allows you to read the write latch instead.

This adds the definition for it, and uses it for the initial
population of the GPIO value cache. It will be used more in
subsequent patches.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Reviewed-by: NAndrew Jeffery <andrew@aj.id.au>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use a single accessor function for all register types instead
of several spread around. This will make it easier/cleaner
to introduce new registers and keep the mechanism in one
place.

The big switch/case is optimized at compile time since the
switch value is a constant.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NJoel Stanley <joel@jms.id.au>
Reviewed-by: NAndrew Jeffery <andrew@aj.id.au>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This was too hard to split ... this adds a number of features
to the SCOM user interface:

 - Support for indirect SCOMs

 - read()/write() interface now handle errors and retries

 - New ioctl() "raw" interface for use by debuggers
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NEddie James <eajames@linux.vnet.ibm.com>
Reviewed-by: NAlistair Popple <alistair@popple.id.au>

Add a few more register and bit definitions, also define and use
SCOM_READ_CMD (which is 0 but it makes the code clearer)
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NEddie James <eajames@linux.vnet.ibm.com>

Use the proper annotated type __be32 and fixup the
accessor used for get_scom()
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NEddie James <eajames@linux.vnet.ibm.com>

No functional changes
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NEddie James <eajames@linux.vnet.ibm.com>

Otherwise, multiple clients can open the driver and attempt
to access the PIB at the same time, thus clobbering each other
in the process.
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Reviewed-by: NEddie James <eajames@linux.vnet.ibm.com>

fsi-core.c:210:9: warning: cast to restricted __be32
fsi-core.c:210:9: warning: cast to restricted __be32
fsi-core.c:210:9: warning: cast to restricted __be32
fsi-core.c:210:9: warning: cast to restricted __be32
fsi-core.c:210:9: warning: cast to restricted __be32
fsi-core.c:210:9: warning: cast to restricted __be32
fsi-core.c:210:9: warning: cast to restricted __be32
fsi-core.c:210:9: warning: cast to restricted __be32
fsi-core.c:210:9: warning: cast to restricted __be32
fsi-core.c:210:9: warning: cast to restricted __be32
fsi-core.c:210:9: warning: cast to restricted __be32
fsi-core.c:210:9: warning: cast to restricted __be32
fsi-core.c:606:15: warning: incorrect type in assignment (different base types)
fsi-core.c:606:15:    expected unsigned int [unsigned] [assigned] [usertype] smode
fsi-core.c:606:15:    got restricted __be32 [usertype] <noident>
fsi-core.c:492:28: warning: expression using sizeof(void)
fsi-core.c:520:29: warning: expression using sizeof(void)
fsi-core.c:682:19: warning: cast to restricted __be32
fsi-core.c:682:19: warning: cast to restricted __be32
fsi-core.c:682:19: warning: cast to restricted __be32
fsi-core.c:682:19: warning: cast to restricted __be32
fsi-core.c:682:19: warning: cast to restricted __be32
fsi-core.c:682:19: warning: cast to restricted __be32
fsi-core.c:706:24: warning: incorrect type in assignment (different base types)
fsi-core.c:706:24:    expected unsigned int [unsigned] [usertype] llmode
fsi-core.c:706:24:    got restricted __be32 [usertype] <noident>
Signed-off-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

fsi-master-hub.c:128:13: warning: incorrect type in assignment (different base types)
fsi-master-hub.c:128:13:    expected unsigned int [unsigned] [usertype] cmd
fsi-master-hub.c:128:13:    got restricted __be32 [usertype] <noident>
fsi-master-hub.c:208:13: warning: incorrect type in assignment (different base types)
fsi-master-hub.c:208:13:    expected restricted __be32 [addressable] [assigned] [usertype] reg
fsi-master-hub.c:208:13:    got int
Signed-off-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

fsi-sbefifo.c:547:58: warning: incorrect type in argument 2 (different base types)
fsi-sbefifo.c:547:58:    expected restricted __be32 [usertype] *word
fsi-sbefifo.c:547:58:    got unsigned int *<noident>
fsi-sbefifo.c:635:16: warning: incorrect type in assignment (different base types)
fsi-sbefifo.c:635:16:    expected unsigned int [unsigned] <noident>
fsi-sbefifo.c:635:16:    got restricted __be32 [usertype] <noident>
fsi-sbefifo.c:636:16: warning: incorrect type in assignment (different base types)
fsi-sbefifo.c:636:16:    expected unsigned int [unsigned] <noident>
fsi-sbefifo.c:636:16:    got restricted __be32 [usertype] <noident>
Signed-off-by: NJoel Stanley <joel@jms.id.au>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>