pinctrl: Convert unsigned to unsigned int

Simple type conversion with no functional change implied.
While at it, adjust indentation where it makes sense.

Signed-off-by: Andy Shevchenko <andriy.shev

pinctrl: Convert unsigned to unsigned int

Simple type conversion with no functional change implied.
While at it, adjust indentation where it makes sense.

Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: Introduce struct pinfunction and PINCTRL_PINFUNCTION() macro

There are many pin control drivers define their own data type for
pin function representation which is the same or embed the sam

pinctrl: Introduce struct pinfunction and PINCTRL_PINFUNCTION() macro

There are many pin control drivers define their own data type for
pin function representation which is the same or embed the same data
as newly introduced one. Provide the data type and convenient macro
for all pin control drivers.

Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Acked-by: Mika Westerberg <[email protected]>

show more ...

pinctrl: Put space between type and data in compound literal

It's slightly better to read when compound literal data and type
are separated by a space.

Signed-off-by: Andy Shevchenko <andriy.shevch

pinctrl: Put space between type and data in compound literal

It's slightly better to read when compound literal data and type
are separated by a space.

Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Basavaraj Natikar <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: Clean up headers

There is a few things done:
- include only the headers we are direct user of
- when pointer is in use, provide a forward declaration
- add missing headers
- group generic h

pinctrl: Clean up headers

There is a few things done:
- include only the headers we are direct user of
- when pointer is in use, provide a forward declaration
- add missing headers
- group generic headers and subsystem headers
- sort each group alphabetically

While at it, fix some awkward indentations.

Signed-off-by: Andy Shevchenko <[email protected]>

show more ...

pinctrl: Add pingroup and define PINCTRL_PINGROUP

Add 'struct pingroup' to represent pingroup and 'PINCTRL_PINGROUP'
macro for inline use. Both are used to manage and represent
larger number of ping

pinctrl: Add pingroup and define PINCTRL_PINGROUP

Add 'struct pingroup' to represent pingroup and 'PINCTRL_PINGROUP'
macro for inline use. Both are used to manage and represent
larger number of pingroups.

Signed-off-by: Basavaraj Natikar <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: Remove hole in pinctrl_gpio_range

On 64-bit platforms, pointer size and alignment are 64-bit, hence two
4-byte holes are present before the pins and gc members of the
pinctrl_gpio_range str

pinctrl: Remove hole in pinctrl_gpio_range

On 64-bit platforms, pointer size and alignment are 64-bit, hence two
4-byte holes are present before the pins and gc members of the
pinctrl_gpio_range structure. Get rid of these holes by moving the
pins pointer.

This reduces kernel size of an arm64 Rockchip kernel by ca. 512 bytes.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: Define of_pinctrl_get() dummy for !PINCTRL

Currently, the of_pinctrl_get() dummy is only defined for !OF, which can
still cause build failures on configurations with OF enabled but PINCTRL

pinctrl: Define of_pinctrl_get() dummy for !PINCTRL

Currently, the of_pinctrl_get() dummy is only defined for !OF, which can
still cause build failures on configurations with OF enabled but PINCTRL
disabled. Make sure to define the dummy if either OF or PINCTRL are not
enabled.

Reported-by: Stephen Rothwell <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: remove unneeded #ifdef around declarations

What is the point in surrounding the whole of declarations with
ifdef like this?

#ifdef CONFIG_FOO
int foo(void);
#endif

If CONFIG_FOO is

pinctrl: remove unneeded #ifdef around declarations

What is the point in surrounding the whole of declarations with
ifdef like this?

#ifdef CONFIG_FOO
int foo(void);
#endif

If CONFIG_FOO is not defined, all callers of foo() will fail
with implicit declaration errors since the top Makefile adds
-Werror-implicit-function-declaration to KBUILD_CFLAGS.

This breaks the build earlier when you are doing something wrong.
That's it.

Anyway, it will fail to link since the definition of foo() is not
compiled.

In summary, these ifdef are unneeded.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: remove unused pin_is_valid()

This function was used by pin_request() to pointlessly double-check
the pin validity, and it was the only user ever.

Since commit d2f6a1c6fb0e ("pinctrl: remov

pinctrl: remove unused pin_is_valid()

This function was used by pin_request() to pointlessly double-check
the pin validity, and it was the only user ever.

Since commit d2f6a1c6fb0e ("pinctrl: remove double pin validity
check."), no one has ever used it.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

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

Based on 1 normalized pattern(s):

license terms gnu general public license gpl version 2

extracted by the scancode license scan

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

Based on 1 normalized pattern(s):

license terms gnu general public license gpl version 2

extracted by the scancode license scanner the SPDX license identifier

GPL-2.0-only

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

Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Reviewed-by: Alexios Zavras <[email protected]>
Reviewed-by: Steve Winslow <[email protected]>
Reviewed-by: Richard Fontana <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

pinctrl: Enable device link creation for pin control

A pin controller may want to create a link between itself
and its clients to be sure of suspend/resume call ordering.

Introduce link_consumers f

pinctrl: Enable device link creation for pin control

A pin controller may want to create a link between itself
and its clients to be sure of suspend/resume call ordering.

Introduce link_consumers field in pinctrl_desc structure to let
pinctrl core knows that controller expect to create a link.

Signed-off-by: Benjamin Gaignard <[email protected]>
[Renamed create_link to link_consumers]
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: remove include file from <linux/device.h>

When pulling the recent pinctrl merge, I was surprised by how a
pinctrl-only pull request ended up rebuilding basically the whole
kernel.

The reas

pinctrl: remove include file from <linux/device.h>

When pulling the recent pinctrl merge, I was surprised by how a
pinctrl-only pull request ended up rebuilding basically the whole
kernel.

The reason for that ended up being that <linux/device.h> included
<linux/pinctrl/devinfo.h>, so any change to that file ended up causing
pretty much every driver out there to be rebuilt.

The reason for that was because 'struct device' has this in it:

#ifdef CONFIG_PINCTRL
struct dev_pin_info *pins;
#endif

but we already avoid header includes for these kinds of things in that
header file, preferring to just use a forward-declaration of the
structure instead. Exactly to avoid this kind of header dependency.

Since some drivers seem to expect that <linux/pinctrl/devinfo.h> header
to come in automatically, move the include to <linux/pinctrl/pinctrl.h>
instead. It might be better to just make the includes more targeted,
but I'm not going to review every driver.

It would definitely be good to have a tool for finding and minimizing
header dependencies automatically - or at least help with them. Right
now we almost certainly end up having way too many of these things, and
it's hard to test every single configuration.

FWIW, you can get a sense of the "hotness" of a header file with something
like this after doing a full build:

find . -name '.*.o.cmd' -print0 |
xargs -0 tail --lines=+2 |
grep -v 'wildcard ' |
tr ' \\' '\n' |
sort | uniq -c | sort -n | less -S

which isn't exact (there are other things in those '*.o.cmd' than just
the dependencies, and the "--lines=+2" only removes the header), but
might a useful approximation.

With this patch, <linux/pinctrl/devinfo.h> drops to "only" having 833
users in the current x86-64 allmodconfig. In contrast, <linux/device.h>
has 14857 build files including it directly or indirectly.

Of course, the headers that absolutely _everybody_ includes (things like
<linux/types.h> etc) get a score of 23000+.

Cc: Linus Walleij <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()

Recent pinctrl changes to allow dynamic allocation of pins exposed one
more issue with the pinctrl pins claimed early by the cont

pinctrl: core: Fix pinctrl_register_and_init() with pinctrl_enable()

Recent pinctrl changes to allow dynamic allocation of pins exposed one
more issue with the pinctrl pins claimed early by the controller itself.
This caused a regression for IMX6 pinctrl hogs.

Before enabling the pin controller driver we need to wait until it has
been properly initialized, then claim the hogs, and only then enable it.

To fix the regression, split the code into pinctrl_claim_hogs() and
pinctrl_enable(). And then let's require that pinctrl_enable() is always
called by the pin controller driver when ready after calling
pinctrl_register_and_init().

Depends-on: 950b0d91dc10 ("pinctrl: core: Fix regression caused by delayed
work for hogs")
Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
Fixes: e566fc11ea76 ("pinctrl: imx: use generic pinctrl helpers for
managing groups")
Cc: Haojian Zhuang <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Mika Penttilä <[email protected]>
Cc: Mika Westerberg <[email protected]>
Cc: Nishanth Menon <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Stefan Agner <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
Tested-by: Gary Bisson <[email protected]>
Tested-by: Fabio Estevam <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: core: Fix regression caused by delayed work for hogs

Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a
regression at least with sh-pfc that is also a GPIO controller

pinctrl: core: Fix regression caused by delayed work for hogs

Commit df61b366af26 ("pinctrl: core: Use delayed work for hogs") caused a
regression at least with sh-pfc that is also a GPIO controller as
noted by Geert Uytterhoeven <[email protected]>.

As the original pinctrl_register() has issues calling pin controller
driver functions early before the controller has finished registering,
we can't just revert commit df61b366af26. That would break the drivers
using GENERIC_PINCTRL_GROUPS or GENERIC_PINMUX_FUNCTIONS.

So let's fix the issue with the following steps as a single patch:

1. Revert the late_init parts of commit df61b366af26.

The late_init clearly won't work and we have to just give up
on fixing pinctrl_register() for GENERIC_PINCTRL_GROUPS and
GENERIC_PINMUX_FUNCTIONS.

2. Split pinctrl_register() into two parts

By splitting pinctrl_register() into pinctrl_init_controller()
and pinctrl_create_and_start() we have better control over when
it's safe to call pinctrl_create().

3. Introduce a new pinctrl_register_and_init() function

As suggested by Linus Walleij <[email protected]>, we
can just introduce a new function for the controllers that need
pinctrl_create() called later.

4. Convert the four known problem cases to use new function

Let's convert pinctrl-imx, pinctrl-single, sh-pfc and ti-iodelay
to use the new function to fix the issues. The rest of the drivers
can be converted later. Let's also update Documentation/pinctrl.txt
accordingly because of the known issues with pinctrl_register().

Fixes: df61b366af26 ("pinctrl: core: Use delayed work for hogs")
Reported-by: Geert Uytterhoeven <[email protected]>
Cc: Gary Bisson <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: Add devm_ apis for pinctrl_{register, unregister}

Add device managed APIs devm_pinctrl_register() and
devm_pinctrl_unregister() for the APIs pinctrl_register()
and pinctrl_unregister().

Th

pinctrl: Add devm_ apis for pinctrl_{register, unregister}

Add device managed APIs devm_pinctrl_register() and
devm_pinctrl_unregister() for the APIs pinctrl_register()
and pinctrl_unregister().

This helps in reducing code in error path and sometimes
removal of .remove callback for driver unbind.

Signed-off-by: Laxman Dewangan <[email protected]>
Reviewed-by: Philipp Zabel <[email protected]>
Acked-by: Bjorn Andersson <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: use "const struct ..." rather than "struct ... const"

Only this member, pins, is defined as "struct ... const *", but the
others in this struct, pinlops, pmxops, confops, etc. are defined a

pinctrl: use "const struct ..." rather than "struct ... const"

Only this member, pins, is defined as "struct ... const *", but the
others in this struct, pinlops, pmxops, confops, etc. are defined as
"const struct ... *".

Swap the "struct pinctrl_pin_desc" and "const" for consistency.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: move strict option to pinmux_ops

While the pinmux_ops are ideally just a vtable for pin mux
calls, the "strict" setting belongs so intuitively with the
pin multiplexing that we should move

pinctrl: move strict option to pinmux_ops

While the pinmux_ops are ideally just a vtable for pin mux
calls, the "strict" setting belongs so intuitively with the
pin multiplexing that we should move it here anyway. Putting
it in the top pinctrl_desc makes no sense.

Cc: Sonic Zhang <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: allow exlusive GPIO/mux pin allocation

Disallow simultaneous use of the the GPIO and peripheral mux
functions by setting a flag "strict" in struct pinctrl_desc.

The blackfin pinmux and gpi

pinctrl: allow exlusive GPIO/mux pin allocation

Disallow simultaneous use of the the GPIO and peripheral mux
functions by setting a flag "strict" in struct pinctrl_desc.

The blackfin pinmux and gpio controller doesn't allow user to
set up a pin for both GPIO and peripheral function. So, add flag
strict in struct pinctrl_desc to check both gpio_owner and
mux_owner before approving the pin request.

v2-changes:
- if strict flag is set, check gpio_owner and mux_onwer in if and
else clause

v3-changes:
- add kerneldoc for this struct
- augment Documentation/pinctrl.txt

Signed-off-by: Sonic Zhang <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: pinconf-generic: loose DT dependence

New pin controllers such as ACPI-based may also have custom properties
to parse, and should be able to use generic pin config. Let's make the
code compi

pinctrl: pinconf-generic: loose DT dependence

New pin controllers such as ACPI-based may also have custom properties
to parse, and should be able to use generic pin config. Let's make the
code compile on !OF systems and rename members a bit to underscore it
is custom parameters and not necessarily DT parameters.

This fixes a build regression for x86_64 on the zeroday kernel builds.

Reported-by: kbuild test robot <[email protected]>
Reviewed-and-tested-by: Soren Brinkmann <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: pinconf-generic: Allow driver to specify DT params

Additionally to the generic DT parameters, allow drivers to provide
driver-specific DT parameters to be used with the generic parser
infra

pinctrl: pinconf-generic: Allow driver to specify DT params

Additionally to the generic DT parameters, allow drivers to provide
driver-specific DT parameters to be used with the generic parser
infrastructure.

To achieve this 'struct pinctrl_desc' is extended to pass custom pinconf
option to the core. In order to pass this kind of information, the
related data structures - 'struct pinconf_generic_dt_params',
'pin_config_item' - are moved from pinconf internals to the
pinconf-generic header.

Additionally pinconfg-generic is refactored to not only iterate over the
generic pinconf parameters but also take the parameters into account
that are provided through the driver's 'struct pinctrl_desc'.
In particular 'pinconf_generic_parse_dt_config()' and
'pinconf_generic_dump' helpers are split into two parts each. In order
to have a more generic helper that can be used to process the generic
parameters as well as the driver-specific ones.

v2:
- fix typo
- add missing documentation for @conf_items member in struct
- rebase to pinctrl/devel: conflict in abx500
- rename _pinconf_generic_dump() to pinconf_generic_dump_one()
- removed '_' from _parse_dt_cfg()
- removed BUG_ONs, error condition is handled in if statements
- removed pinconf_generic_dump_group() & pinconf_generic_dump_pin
helpers
- fixed up corresponding call sites
- renamed pinconf_generic_dump() to pinconf_generic_dump_pins()
- added kernel-doc to pinconf_generic_dump_pins()
- add kernel-doc
- more verbose commit message

Signed-off-by: Soren Brinkmann <[email protected]>
Tested-by: Andreas Färber <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: Add void * to pinctrl_pin_desc

drv_data is added to the pinctrl_pin_desc for drivers to define additional
driver-specific per-pin data.

Signed-off-by: Sherman Yin <[email protected]>
Revie

pinctrl: Add void * to pinctrl_pin_desc

drv_data is added to the pinctrl_pin_desc for drivers to define additional
driver-specific per-pin data.

Signed-off-by: Sherman Yin <[email protected]>
Reviewed-by: Christian Daudt <[email protected]>
Reviewed-by: Matt Porter <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl/gpio: non-linear GPIO ranges accesible from gpiolib

This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.

pinctrl/gpio: non-linear GPIO ranges accesible from gpiolib

This patch adds the infrastructure required to register non-linear gpio
ranges through gpiolib and the standard GPIO device tree bindings.

Signed-off-by: Christian Ruppert <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

Fix comment on pinctrl_gpio_range.pin_base

The comment introduced with the recently added pinctrl_gpio_range.pins
element was wrong. This corrects it.
Thanks to Patrice Chotard for pointing this out

Fix comment on pinctrl_gpio_range.pin_base

The comment introduced with the recently added pinctrl_gpio_range.pins
element was wrong. This corrects it.
Thanks to Patrice Chotard for pointing this out.

Signed-off-by: Christian Ruppert <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: add pin list based GPIO ranges

Traditionally, GPIO ranges are based on consecutive ranges of both GPIO
and pin numbers. This patch allows for GPIO ranges with arbitrary lists
of pin numbers

pinctrl: add pin list based GPIO ranges

Traditionally, GPIO ranges are based on consecutive ranges of both GPIO
and pin numbers. This patch allows for GPIO ranges with arbitrary lists
of pin numbers.

Signed-off-by: Christian Ruppert <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...

pinctrl: Declare operation structures as const

The pinconf, pinctrl and pinmux operation structures hold function
pointers that are never modified. Declare them as const.

Signed-off-by: Laurent Pin

pinctrl: Declare operation structures as const

The pinconf, pinctrl and pinmux operation structures hold function
pointers that are never modified. Declare them as const.

Signed-off-by: Laurent Pinchart <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...