The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:
struct foo {
int stuff;
struct boo array[];
};
By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by
this change:
"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 7649773293 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Link: https://lore.kernel.org/r/20200217185437.GA20901@embeddedor
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
checkpatch.pl suggests to use SPDX license tag. I am happy to
follow it.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There is code duplication between uniphier_conf_pin_drive_get() and
uniphier_conf_pin_drive_set(). Factor out the common code into
uniphier_conf_get_drvctrl_data().
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Don't populate const arrays on the stack, instead make them
static. Makes the object code smaller nearly 1000 bytes. Also
line break wide lines to avoid checkpatch warnings.
Before:
text data bss dec hex filename
13112 1996 0 15108 3b04 pinctrl-uniphier-core.o
After:
text data bss dec hex filename
11642 2476 0 14118 3726 pinctrl-uniphier-core.o
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since commit 58957d2edf ("pinctrl: Widen the generic pinconf argument
from 16 to 24 bits"), the generic pinconf arguments are handled by u32.
UniPhier pinctrl drivers do not support debouncing, so u16 is working,
but align the argument type to u32 for consistency.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Save registers lost in the sleep when suspending, and restore them
when resuming.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For LD11/20 SoCs (capable of per-pin input enable), the iectrl bit
number matches its pin number. So, this is redundant information.
Instead, we just need a flag to know if the iectrl gating exists or not.
With this refactoring, 5 bits in pin data will be saved.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
There are a bunch of GPIO muxing data, but most of them are actually
unneeded because GPIO-to-pin mapping can be specified by "gpio-ranges"
DT properties.
Tables that contain a set of GPIO pins are still needed for the named
mapping by "gpio-ranges-group-names". This is a much cleaner way for
UniPhier SoC family where GPIO numbers are not straight mapped to pin
numbers.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
For LD11/LD20 SoCs (capable of per-pin input enable), iectrl bits are
located across multiple registers. So, the register offset must be
taken into account. Otherwise, wrong input-enable status is displayed.
While we here, rename the macro because it is a base address.
Fixes: aa543888ca ("pinctrl: uniphier: support per-pin input enable for new SoCs")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
All UniPhier pinctrl drivers are built-in. Exporting the symbol
is meaningless.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Since commit 3e030b0b4e ("pinctrl: uniphier: allow to have pinctrl
node under syscon node"), this driver has kept compatibility for the
old DT files. Several releases have passed since then, so remove
the obsoleted compatibles and clean up the code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The current pinconf packed format allows only 16-bit argument limiting
the maximum value 65535. For most types this is enough. However,
debounce time can be in range of hundreths of milliseconds in case of
mechanical switches so we cannot represent the worst case using the
current format.
In order to support larger values change the packed format so that the
lower 8 bits are used as type which leaves 24 bits for the argument.
This allows representing values up to 16777215 and debounce times up to
16 seconds.
We also convert the existing users to use 32-bit integer when extracting
argument from the packed configuration value.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently, the UniPhier pinctrl driver itself is a syscon, but it
turned out much more reasonable to make it a child node of a syscon
because our syscon node consists of a bunch of system configuration
registers, not only pinctrl, but also phy, and misc registers.
It is difficult to split the node.
To allow to migrate to the new DT structure, this commit adds new
compatible strings to not disturb the existing DT. After a while,
the old binding will be removed.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
PH1-LD4 and PH1-sLD8 SoCs have pins that support pin configuration
(pin biasing, drive strength control), but not pin-muxing.
Allow to fill the mux value table with -1 for those pins; pins with
mux value -1 will be skipped in the pin-mux set function. The mux
value type should be changed from "unsigned" to "int" in order to
accommodate -1 as a special case.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Upcoming new pinctrl drivers for PH1-LD11 and PH-LD20 support input
signal gating for each pin. (While, existing ones only support it
per pin-group.) This commit updates the core part for that.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The core part of the UniPhier pinctrl driver needs to support a new
capability for upcoming UniPhier ARMv8 SoCs. This sometimes happens
because pinctrl drivers include really SoC-specific stuff.
This commit intends to tidy up SoC-specific parameters of the existing
drivers before adding the new one. Having just one flag would be
better than adding a new struct member every time a new SoC-specific
capability comes up.
At this time, there is one flag, UNIPHIER_PINCTRL_CAPS_DBGMUX_SEPARATE.
This capability (I'd say rather quirk) was added for PH1-Pro4 and
PH1-Pro5 as requirement from a customer. For those SoCs, one pin-mux
setting is controlled by the combination of two separate registers; the
LSB bits at register offset (8 * N) and the MSB bits at (8 * N + 4).
Because it is impossible to update two separate registers atomically,
the LOAD_PINCTRL register should be set in order to make the pin-mux
settings really effective.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Unfortunately, the pin number of the new SoC, PH1-LD11, is not
contiguous. The base frame work must be adjusted to support the new
SoC pinctrl driver. The pin_desc_get() exploits radix-tree for pin
look-up, so it works more efficiently with sparse pin space.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The new ARMv8 SoC, PH1-LD20, supports more fine-grained drive
strength control. Drive strength of some pins are controlled by
3-bit width registers (8-level granularity).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The new ARMv8 SoC, PH1-LD20, supports more fine-grained drive
strength control. Some of the configuration registers on it have
3-bit width.
The feature will be supported in the next commit, but a problem is
that macro names are getting longer and longer in the current naming
scheme.
Before moving forward, this commit renames macros as follows:
UNIPHIER_PIN_DRV_4_8 -> UNIPHIER_PIN_DRV_1BIT
UNIPHIER_PIN_DRV_8_12_16_20 -> UNIPHIER_PIN_DRV_2BIT
UNIPHIER_PIN_DRV_FIXED_4 -> UNIPHIER_PIN_DRV_FIXED4
UNIPHIER_PIN_DRV_FIXED_5 -> UNIPHIER_PIN_DRV_FIXED5
UNIPHIER_PIN_DRV_FIXED_8 -> UNIPHIER_PIN_DRV_FIXED8
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Currently, every SoC driver defines struct pinctrl_desc statically,
i.e. it consumes memory footprint even if it is not probed.
In multi-platform, many pinctrl drivers are linked (generally as
built-in objects), although only one of them is actually used.
So, it is reasonable to allocate memory dynamically where possible.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Every SoC driver sets the same name for struct pinctrl_desc and
platform_driver. The common probe function can set desc->name
instead of duplicating strings in each SoC driver.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The owner of the struct pinctrl_desc matches that of platform_driver.
Set it in the common probe function.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Use devm_pinctrl_register() for pin control registration and remove
need of .remove callback.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Rename pinctrl_utils_dt_free_map to pinctrl_utils_free_map, since
it does not depend on device tree despite the current name. This
will enforce a consistent naming in pinctr-utils.c and will make
it clear it can be called from outside device tree (e.g. from
ACPI handling code).
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
While IECTRL is disabled, input signals are pulled-down internally.
If pin-muxing is set up first, glitch signals (Low to High transition)
might be input to hardware blocks.
Bad case scenario:
[1] The hardware block is already running before pinctrl is handled.
(the reset is de-asserted by default or by a firmware, for example)
[2] The pin-muxing is set up. The input signals to hardware block
are pulled-down by the chip-internal biasing.
[3] The pins are input-enabled. The signals from the board reach the
hardware block.
Actually, one invalid character is input to the UART blocks for such
SoCs as PH1-LD4, PH1-sLD8, where UART devices start to run at the
power on reset.
To avoid such problems, pins should be input-enabled before muxing.
Fixes: 6e90889202 ("pinctrl: UniPhier: add UniPhier pinctrl core support")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: Dai Okamura <okamura.dai@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
The core support for the pinctrl drivers for all the UniPhier SoCs.
Changes in v2:
- drop vogus THIS_MODULE because this file is always built-in
- drop vogus "include <linux/module.h> because this file is
always built-in
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>