pinctrl: aspeed: Revert "Force to disable the function's signal"

This reverts commit cf517fef601b9dde151f0afc27164d13bf1fd907.

The commit cf517fef601b ("pinctrl: aspeed: Force to disable the
function's signal") exposed a problem with fetching the regmap for
reading the GFX register.

The Romulus machine the device tree contains a gpio hog for GPIO S7.
With the patch applied:

Muxing pin 151 for GPIO
Disabling signal VPOB9 for VPO
aspeed-g5-pinctrl 1e6e2080.pinctrl: Failed to acquire regmap for IP block 1
aspeed-g5-pinctrl 1e6e2080.pinctrl: request() failed for pin 151

The code path is aspeed-gpio -> pinmux-g5 -> regmap -> clk, and the
of_clock code returns an error as it doesn't have a valid struct clk_hw
pointer. The regmap call happens because pinmux wants to check the GFX
node (IP block 1) to query bits there.

For reference, before the offending patch:

Muxing pin 151 for GPIO
Disabling signal VPOB9 for VPO
Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000
Disabling signal VPOB9 for VPOOFF1
Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000
Disabling signal VPOB9 for VPOOFF2
Want SCU8C[0x00000080]=0x1, got 0x0 from 0x00000000
Enabling signal GPIOS7 for GPIOS7
Muxed pin 151 as GPIOS7
gpio-943 (seq_cont): hogged as output/low

We can't skip the clock check to allow pinmux to proceed, because the
write to disable VPOB9 will try to set a bit in the GFX register space
which will not stick when the IP is in reset. However, we do not want to
enable the IP just so pinmux can do a disable-enable dance for the pin.

For now, revert the offending patch while a correct solution is found.

Fixes: cf517fef601b ("pinctrl: aspeed: Force to disable the function's signal")
Link: https://github.com/openbmc/linux/issues/218
Signed-off-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20230130220845.917985-1-joel@jms.id.au
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Fix confusing types in return value

The function signature is int, but we return a bool. Instead return a
negative errno as the kerneldoc suggests.

Fixes: 4d3d0e4272d8 ("pinctrl: Add core support for Aspeed SoCs")
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20230119231856.52014-1-joel@jms.id.au
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Add missing header(s)

Do not imply that some of the generic headers may be always included.
Instead, include explicitly what we are direct user of.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Force to disable the function's signal

When the driver want to disable the signal of the function, it doesn't
need to query the state of the mux function's signal on a pin. The
condition below will miss the disable of the signal:
Ball | Default | P0 Signal | P0 Expression | Other
-----+---------+-----------+-----------------------------+----------
E21 GPIOG0 SD2CLK SCU4B4[16]=1 & SCU450[1]=1 GPIOG0
-----+---------+-----------+-----------------------------+----------
B22 GPIOG1 SD2CMD SCU4B4[17]=1 & SCU450[1]=1 GPIOG1
-----+---------+-----------+-----------------------------+----------
Assume the register status like below:
SCU4B4[16] == 1 & SCU4B4[17] == 1 & SCU450[1]==1
After the driver set the Ball E21 to the GPIOG0:
SCU4B4[16] == 0 & SCU4B4[17] == 1 & SCU450[1]==0
When the driver want to set the Ball B22 to the GPIOG1, the condition of
the SD2CMD will be false causing SCU4B4[17] not to be cleared.

Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20220818101839.28860-1-billy_tsai@aspeedtech.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Fix potential NULL dereference in aspeed_pinmux_set_mux()

pdesc could be null but still dereference pdesc->name and it will lead to
a null pointer access. So we move a null check before dereference.

Signed-off-by: Haowen Bai <baihaowen@meizu.com>
Link: https://lore.kernel.org/r/1650508019-22554-1-git-send-email-baihaowen@meizu.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: placate kernel-doc warnings

Eliminate kernel-doc warnings in drivers/pinctrl/aspeed by using
proper kernel-doc notation.

Fixes these kernel-doc warnings:

drivers/pinctrl/aspeed/pinmux-aspeed.c:61: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Query the enabled or disabled state for a mux function's signal on a pin
drivers/pinctrl/aspeed/pinctrl-aspeed.c:135: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
* Search for the signal expression needed to enable the pin's signal for the

Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Aditya Srivastava <yashsri421@gmail.com>
Cc: Andrew Jeffery <andrew@aj.id.au>
Cc: linux-aspeed@lists.ozlabs.org
Cc: openbmc@lists.ozlabs.org
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: linux-gpio@vger.kernel.org
Acked-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20210723034840.8752-1-rdunlap@infradead.org
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Fix minor documentation error

Kernel test robot throws below warning ->

drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c:2705: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/pinctrl/aspeed/pinctrl-aspeed-g6.c:2614: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/pinctrl/aspeed/pinctrl-aspeed.c:111: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/pinctrl/aspeed/pinmux-aspeed.c:24: warning: This comment starts
with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst

Fix minor documentation error.

Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/1619353584-8196-1-git-send-email-jrdr.linux@gmail.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Fix GPIO requests on pass-through banks

Commit 6726fbff19bf ("pinctrl: aspeed: Fix GPI only function problem.")
fixes access to GPIO banks T and U on the AST2600. Both banks contain
input-only pins and the GPIO pin function is named GPITx and GPIUx
respectively. Unfortunately the fix had a negative impact on GPIO banks
D and E for the AST2400 and AST2500 where the GPIO pass-through
functions take similar "GPI"-style names. The net effect on the older
SoCs was that when the GPIO subsystem requested a pin in banks D or E be
muxed for GPIO, they were instead muxed for pass-through mode.
Mistakenly muxing pass-through mode e.g. breaks booting the host on
IBM's Witherspoon (AC922) platform where GPIOE0 is used for FSI.

Further exploit the names in the provided expression structure to
differentiate pass-through from pin-specific GPIO modes.

This follow-up fix gives the expected behaviour for the following tests:

Witherspoon BMC (AST2500):

1. Power-on the Witherspoon host
2. Request GPIOD1 be muxed via /sys/class/gpio/export
3. Request GPIOE1 be muxed via /sys/class/gpio/export
4. Request the balls for GPIOs E2 and E3 be muxed as GPIO pass-through
("GPIE2" mode) via a pinctrl hog in the devicetree

Rainier BMC (AST2600):

5. Request GPIT0 be muxed via /sys/class/gpio/export
6. Request GPIU0 be muxed via /sys/class/gpio/export

Together the tests demonstrate that all three pieces of functionality
(general GPIOs via 1, 2 and 3, input-only GPIOs via 5 and 6, pass-through
mode via 4) operate as desired across old and new SoCs.

Fixes: 9b92f5c51e9a ("pinctrl: aspeed: Fix GPI only function problem.")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Tested-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Cc: Billy Tsai <billy_tsai@aspeedtech.com>
Cc: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20201126063337.489927-1-andrew@aj.id.au
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Fix GPI only function problem.

Some gpio pin at aspeed soc is input only and the prefix name of these
pin is "GPI" only.
This patch fine-tune the condition of GPIO check from "GPIO" to "GPI"
and it will fix the usage error of banks D and E in the AST2400/AST2500
and banks T and U in the AST2600.

Fixes: 4d3d0e4272d8 ("pinctrl: Add core support for Aspeed SoCs")
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20201030055450.29613-1-billy_tsai@aspeedtech.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Use the right pinconf mask

The Aspeed pinconf data structures are split into 'conf' and 'map'
types, where the 'conf' struct defines which register and bitfield to
manipulate, while the 'map' struct defines what value to write to
the register and bitfield.

Both structs have a mask member, and the wrong mask was being used to
tell the regmap which bits to update.

A todo is to look at whether we can remove the mask from the 'map'
struct.

Fixes: 5f52c853847f ("pinctrl: aspeed: Use masks to describe pinconf bitfields")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Cc: Johnny Huang <johnny_huang@aspeedtech.com>
Link: https://lore.kernel.org/r/20200910025631.2996342-3-andrew@aj.id.au
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Format pinconf debug consistent with pinmux

When displaying which pinconf register and field is being touched,
format the field mask so that it's consistent with the way the pinmux
portion formats the mask.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20200910025631.2996342-2-andrew@aj.id.au
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Improve debug output

We need to iterate over each pin in a group for a function and
disable higher priority mux configurations on the pin before finally
muxing the relevant function's signal. With the current debug output it
is hard to track what register output is relevant to which operation, so
break up the actions in the debug output by providing some more context.

Before:

[ 5.446656] aspeed-g6-pinctrl 1e6e2000.syscon:pinctrl: request pin 37 (B26) for 1e780000.gpio:341
[ 5.447377] Want SCU414[0x00000020]=0x1, got 0x0 from 0x00000000
[ 5.447854] Want SCU4B4[0x00000020]=0x1, got 0x0 from 0x00000000
[ 5.448340] Want SCU4B4[0x00000020]=0x1, got 0x0 from 0x00000000

After:

[ 5.298053] Muxing pin 37 for GPIO
[ 5.298294] Disabling signal NRI4 for NRI4
[ 5.298593] Want SCU414[0x00000020]=0x1, got 0x0 from 0x00000000
[ 5.298983] Disabling signal RGMII4RXD1 for RGMII4
[ 5.299309] Want SCU4B4[0x00000020]=0x1, got 0x0 from 0x00000000
[ 5.299694] Disabling signal RMII4RXD1 for RMII4
[ 5.300014] Want SCU4B4[0x00000020]=0x1, got 0x0 from 0x00000000
[ 5.300396] Enabling signal GPIOE5 for GPIOE5
[ 5.300687] Muxed pin 37 as GPIOE5

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20200701030039.2834418-1-joel@jms.id.au
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Use masks to describe pinconf bitfields

Since some of the AST2600 pinconf setting are not just single bit, modified
aspeed_pin_config @bit to @mask and add @mask to aspeed_pin_config_map to
support configuring multiple bits.

Signed-off-by: Johnny Huang <johnny_huang@aspeedtech.com>
[AJ: Tweak commit message]
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20191202061432.3996-7-andrew@aj.id.au
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Move aspeed_pin_config_map to separate source file

The AST2600 pinconf differs from the 2400 and 2500, aspeed_pin_config_map
should define separately, and add @confmaps and @nconfmaps to
aspeed_pinctrl_data structure for that change.

Signed-off-by: Johnny Huang <johnny_huang@aspeedtech.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20191202061432.3996-6-andrew@aj.id.au
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed-g5: Delay acquisition of regmaps

While sorting out some devicetree issues I found that the pinctrl driver
was failing to acquire its GFX regmap even though the phandle was
present in the devicetree:

[ 0.124190] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: No GFX phandle found, some mux configurations may fail

Without access to the GFX regmap we fail to configure the mux for the
VPO function:

[ 1.548866] pinctrl core: add 1 pinctrl maps
[ 1.549826] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: found group selector 164 for VPO
[ 1.550638] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 144 (V20) for 1e6e6000.display
[ 1.551346] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 145 (U19) for 1e6e6000.display
...
[ 1.562057] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 218 (T22) for 1e6e6000.display
[ 1.562541] aspeed-g5-pinctrl 1e6e2000.syscon:pinctrl: request pin 219 (R20) for 1e6e6000.display
[ 1.563113] Muxing pin 144 for VPO
[ 1.563456] Want SCU8C[0x00000001]=0x1, got 0x0 from 0x00000000
[ 1.564624] aspeed_gfx 1e6e6000.display: Error applying setting, reverse things back

This turned out to be a simple problem of timing: The ASPEED pinctrl
driver is probed during arch_initcall(), while GFX is processed much
later. As such the GFX syscon is not yet registered during the pinctrl
probe() and we get an -EPROBE_DEFER when we try to look it up, however
we must not defer probing the pinctrl driver for the inability to mux
some GFX-related functions.

Switch to lazily grabbing the regmaps when they're first required by the
mux configuration. This generates a bit of noise in the patch as we have
to drop the `const` qualifier on arguments for several function
prototypes, but has the benefit of working.

I've smoke tested this for the ast2500-evb under qemu with a dummy
graphics device. We now succeed in our attempts to configure the SoC's
VPO pinmux function.

Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX controllers")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20190724080155.12209-1-andrew@aj.id.au
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Split out pinmux from general pinctrl

ASPEED have completely rearranged the System Control Unit register
layout with the AST2600. The existing code took advantage of the fact
that the AST2400 and AST2500 had layouts that were similar enough to
have little impact on the pinmux infrastructure (though there is a wart
with read-modify-write vs write-1-clear semantics of the hardware
strapping registers between the two).

Given that any similarity has been thrown out with the AST2600, separate
out the function applying an expression state to be driver-specific.
With it, extract out the pinmux macro jungle to its own header and
implementation so the pieces can be composed without dependency cycles.

Cc: Johnny Huang <johnny_huang@aspeedtech.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20190628023838.15426-8-andrew@aj.id.au
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Clarify comment about strapping W1C

Writes of 1 to SCU7C clear set bits in SCU70, the hardware strapping
register. The information was correct if you squinted while reading, but
hopefully switching the order of the registers as listed conveys it
better.

Cc: Johnny Huang <johnny_huang@aspeedtech.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Joel Stanley <joel@jms.id.au>
Link: https://lore.kernel.org/r/20190628023838.15426-7-andrew@aj.id.au
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152

Based on 1 normalized pattern(s):

this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 3029 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

pinctrl: remove unnecessary unlikely()

WARN_ON() already contains an unlikely(), so it's not necessary to
wrap it into another.

Signed-off-by: Igor Stoppa <igor.stoppa@huawei.com>
Cc: Andrew Jeffery <andrew@aj.id.au>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Fix documentation

Fixes these warnings:

pinctrl-aspeed.c:112: warning: Function parameter or member 'map' not
described in 'aspeed_sig_desc_eval'
pinctrl-aspeed.c:112: warning: Excess function parameter 'regmap'
description in 'aspeed_sig_desc_eval'

Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Rework strap register write logic for the AST2500

Yong Li found that writes to the AST2500 strapping register were not
properly supported by the Aspeed pinctrl core and provided a patch to
rectify the problem. Several revisions of the patch were posted and
ultimately v4 should have been applied, however some unfortunate
liberal application of tags on my part lead to confusion between v3[1]
and v4[2].

Generate the diff between v3 and v4 to apply as a fixup patch.

[1] http://patchwork.ozlabs.org/patch/801662/
[2] http://patchwork.ozlabs.org/patch/802946/

Cc: Yong Li <sdliyong@gmail.com>
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Fix ast2500 strap register write logic

On AST2500, the hardware strap register(SCU70) only accepts write ‘1’,
to clear it to ‘0’, must set bits(write ‘1’) to SCU7C

Signed-off-by: Yong Li <sdliyong@gmail.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Tested-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Add core pinconf support

Several pinconf parameters have a fairly straight-forward mapping onto
the Aspeed pin controller. These include management of pull-down bias,
drive-strength, and some debounce configuration.

Pin biasing largely is managed on a per-GPIO-bank basis, aside from the
ADC and RMII/RGMII pins. As the bias configuration for each pin in a
bank maps onto a single per-bank bit, configuration tables will be
introduced to describe the ranges of pins and the supported pinconf
parameter. The use of tables also helps with the sparse support of
pinconf properties, and the fact that not all GPIO banks support
biasing or drive-strength configuration.

Further, as the pin controller uses a consistent approach for bias and
drive strength configuration at the register level, a second table is
defined for looking up the the bit-state required to enable or query the
provided configuration.

Testing for pinctrl-aspeed-g4 was performed on an OpenPOWER Palmetto
system, and pinctrl-aspeed-g5 on an AST2500EVB as well as under QEMU.
The test method was to set the appropriate bits via devmem and verify
the result through the controller's pinconf-pins debugfs file. This
simultaneously validates the get() path and half of the set() path. The
remainder of the set() path was validated by configuring a handful of
pins via the devicetree with the supported pinconf properties and
verifying the appropriate registers were touched.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Allow disabling Port D and Port E loopback mode

Port D and port E GPIO loopback modes are commonly enabled via hardware
straps for use with front-panel buttons. When the BMC is powered
off or fails to boot, the front-panel buttons are directly connected to
the host chipset via the loopback to allow direct power-on and reset
control. Once the BMC has booted, the loopback mode must be disabled for
the BMC to take over control of host power-on and reset.

Disabling these loopback modes requires writing to the hardware strap
register which violates the current design of assuming the system
designer chose the strap settings for a specific reason and they should
be treated as read-only. Only the two bits of the strap register related
to these loopback modes are allowed to be written and comments have been
added to explain why.

Signed-off-by: Rick Altherr <raltherr@google.com>
Acked-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Fix kerneldoc return descriptions

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Acked-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: Read and write bits in LPC and GFX controllers

The System Control Unit IP block in the Aspeed SoCs is typically where
the pinmux configuration is found, but not always. A number of pins
depend on state in one of LPC Host Control (LHC) or SoC Display
Controller (GFX) IP blocks, so the Aspeed pinmux drivers should have the
means to adjust these as necessary.

We use syscon to cast a regmap over the GFX and LPC blocks, which is
used as an arbitration layer between the relevant driver and the pinctrl
subsystem. The regmaps are then exposed to the SoC-specific pinctrl
drivers by phandles in the devicetree, and are selected during a mux
request by querying a new 'ip' member in struct aspeed_sig_desc.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: "Not enabled" is a significant mux state

Consider a scenario with one pin P that has two signals A and B, where A
is defined to be higher priority than B: That is, if the mux IP is in a
state that would consider both A and B to be active on P, then A will be
the active signal.

To instead configure B as the active signal we must configure the mux so
that A is inactive. The mux state for signals can be described by
logical operations on one or more bits from one or more registers (a
"signal expression"), which in some cases leads to aliased mux states for
a particular signal. Further, signals described by multi-bit bitfields
often do not only need to record the states that would make them active
(the "enable" expressions), but also the states that makes them inactive
(the "disable" expressions). All of this combined leads to four possible
states for a signal:

1. A signal is active with respect to an "enable" expression
2. A signal is not active with respect to an "enable" expression
3. A signal is inactive with respect to a "disable" expression
4. A signal is not inactive with respect to a "disable" expression

In the case of P, if we are looking to activate B without explicitly
having configured A it's enough to consider A inactive if all of A's
"enable" signal expressions evaluate to "not active". If any evaluate to
"active" then the corresponding "disable" states must be applied so it
becomes inactive.

For example, on the AST2400 the pins composing GPIO bank H provide
signals ROMD8 through ROMD15 (high priority) and those for UART6 (low
priority). The mux states for ROMD8 through ROMD15 are aliased, i.e.
there are two mux states that result in the respective signals being
configured:

A. SCU90[6]=1
B. Strap[4,1:0]=100

Further, the second mux state is a 3-bit bitfield that explicitly
defines the enabled state but the disabled state is implicit, i.e. if
Strap[4,1:0] is not exactly "100" then ROMD8 through ROMD15 are not
considered active. This requires the mux function evaluation logic to
use approach 2. above, however the existing code was using approach 3.
The problem was brought to light on the Palmetto machines where the
strap register value is 0x120ce416, and prevented GPIO requests in bank
H from succeeding despite the hardware being in a position to allow
them.

Fixes: 318398c09a8d ("pinctrl: Add core pinctrl support for Aspeed SoCs")
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: aspeed: fix regmap error handling

The newly added aspeed driver tries to check for a negative return
value from a pinctrl function, but stores the intermediate value in
a 'bool' variable, which cannot work:

drivers/pinctrl/aspeed/pinctrl-aspeed.c: In function 'aspeed_sig_expr_set':
drivers/pinctrl/aspeed/pinctrl-aspeed.c:192:11: error: comparison of constant '0' with boolean expression is always false [-Werror=bool-compare]

This slightly reworks the logic to use an explicit comparison with zero
before assigning to the temporary variable.

Reported-by: Colin King <colin.king@canonical.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

pinctrl: Add core support for Aspeed SoCs

The Aspeed SoCs typically provide more than 200 pins for GPIO and other
functions. The signal enabled on a pin is determined on a priority
basis, where a given pin can provide a number of different signal types.

In addition to the priority levels, the Aspeed pin controllers describe
the signal active on a pin by compound logical expressions involving
multiple operators, registers and bits. Some difficulty arises as a
pin's function bit masks for each priority level are frequently not the
same (i.e. we cannot just flip a bit to change from a high to low
priority signal), or even in the same register(s). Some configuration
bits affect multiple pins, while in other cases the signals for a bus
must each be enabled individually.

Together, these features give rise to some complexity in the
implementation. A more complete description of the complexities is
provided in the associated header file.

The patch doesn't implement pinctrl/pinmux/pinconf for any particular
Aspeed SoC, rather it adds the framework for defining pinmux
configurations.

Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>