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 <sonic.zhang@analog.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

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: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

commit 2243a87d
"pinctrl: avoid duplicated calling enable_pinmux_setting for a pin"
removed the .disable callback from the struct pinmux_ops,
making the .enable() callback the only remaining callback.

However .enable() is a bad name as it seems to imply that a
muxing can also be disabled. Rename the callback to .set_mux()
and also take this opportunity to clean out any remaining
mentions of .disable() from the documentation.
Acked-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NBjorn Andersson <bjorn.andersson@sonymobile.com>
Acked-by: NFan Wu <fwu@marvell.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

What the patch does:
1. Call pinmux_disable_setting ahead of pinmux_enable_setting
  each time pinctrl_select_state is called
2. Remove the HW disable operation in pinmux_disable_setting function.
3. Remove the disable ops in struct pinmux_ops
4. Remove all the disable ops users in current code base.

Notes:
1. Great thanks for the suggestion from Linus, Tony Lindgren and
   Stephen Warren and Everyone that shared comments on this patch.
2. The patch also includes comment fixes from Stephen Warren.

The reason why we do this:
1. To avoid duplicated calling of the enable_setting operation
   without disabling operation inbetween which will let the pin
   descriptor desc->mux_usecount increase monotonously.
2. The HW pin disable operation is not useful for any of the
   existing platforms.
   And this can be used to avoid the HW glitch after using the
   item #1 modification.

In the following case, the issue can be reproduced:
1. There is a driver that need to switch pin state dynamically,
   e.g. between "sleep" and "default" state
2. The pin setting configuration in a DTS node may be like this:

  component a {
	pinctrl-names = "default", "sleep";
	pinctrl-0 = <&a_grp_setting &c_grp_setting>;
	pinctrl-1 = <&b_grp_setting &c_grp_setting>;
  }

  The "c_grp_setting" config node is totally identical, maybe like
  following one:

  c_grp_setting: c_grp_setting {
	pinctrl-single,pins = <GPIO48 AF6>;
  }

3. When switching the pin state in the following official pinctrl
   sequence:
	pin = pinctrl_get();
	state = pinctrl_lookup_state(wanted_state);
	pinctrl_select_state(state);
	pinctrl_put();

Test Result:
1. The switch is completed as expected, that is: the device's
   pin configuration is changed according to the description in the
   "wanted_state" group setting
2. The "desc->mux_usecount" of the corresponding pins in "c_group"
   is increased without being decreased, because the "desc" is for
   each physical pin while the setting is for each setting node
   in the DTS.
   Thus, if the "c_grp_setting" in pinctrl-0 is not disabled ahead
   of enabling "c_grp_setting" in pinctrl-1, the desc->mux_usecount
   will keep increasing without any chance to be decreased.

According to the comments in the original code, only the setting,
in old state but not in new state, will be "disabled" (calling
pinmux_disable_setting), which is correct logic but not intact. We
still need consider case that the setting is in both old state
and new state. We can do this in the following two ways:

1. Avoid to "enable"(calling pinmux_enable_setting) the "same pin
   setting" repeatedly
2. "Disable"(calling pinmux_disable_setting) the "same pin setting",
   actually two setting instances, ahead of enabling them.

Analysis:
1. The solution #2 is better because it can avoid too much
   iteration.
2. If we disable all of the settings in the old state and one of
   the setting(s) exist in the new state, the pins mux function
   change may happen when some SoC vendors defined the
   "pinctrl-single,function-off"
   in their DTS file.
   old_setting => disabled_setting => new_setting.
3. In the pinmux framework, when a pin state is switched, the
   setting in the old state should be marked as "disabled".

Conclusion:
1. To Remove the HW disabling operation to above the glitch mentioned
   above.
2. Handle the issue mentioned above by disabling all of the settings
   in old state and then enable the all of the settings in new state.
Signed-off-by: NFan Wu <fwu@marvell.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NPatrice Chotard <patrice.chotard@st.com>
Acked-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When using a group only pinctrl driver, which does not have any
information on the pins it is useless to define a get_group_pins
always returning an empty list of pins.

When not using get_group_pin[1], a driver must implement it so
pins = NULL and num_pins = 0. This patch makes it the default
behaviour if not defined in the pinctrl driver when used in
pinmux enable and disable funtions and in pinctrl_groups_show.

It also adds a check in pinctrl_get_group_pins and return -EINVAL if
not defined. This function is called in the gpiolib when adding when
pingroup range. It cannot be used if no group is defined, so this seams
reasonable.

[1] get_group_pin(struct pinctrl_dev *pctldev,
		  unsigned selector,
		  const unsigned **pins,
		  unsigned *num_pins);
Signed-off-by: NAntoine Ténart <antoine.tenart@free-electrons.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This removes a test whether the 'desc' variable is NULL.
This possibility has already been eliminated by the
below test earlier in the loop:

                if (desc == NULL) {
                        dev_warn(pctldev->dev,
                                 "could not get pin desc for pin %d\n",
                                 pins[i]);
                        continue;
                }

Found with Coverity: CID #1090078
Signed-off-by: NMichael Opdenacker <michael.opdenacker@free-electrons.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Print out the affected group name on activation of pin mux
settings, and warn if you cannot free a pin that should have
been part of a certain setting.

ChangeLog v1->v2:
- Also print the pin name in the error messages.

Cc: Sonic Zhang <sonic.zhang@analog.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

One peripheral may share part of its pins with the 2nd
peripheral and the other pins with the 3rd. If it requests all pins
when part of them has already be requested and owned by the 2nd
peripheral, this request fails and pinmux_disable_setting() is called.
The pinmux_disable_setting() frees all pins of the first peripheral
without checking if the pin is owned by itself or the 2nd, which
results in the malfunction of the 2nd peripheral driver.
Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This mutex avoids deadlock in case of use of multiple pin
controllers. Before this modification, by using a global
mutex, deadlock appeared when, for example, a call to
pinctrl_pins_show() locked the pinctrl_mutex, called the
ops->pin_dbg_show of a particular pin controller. If this
pin controller needs I2C access to retrieve configuration
information and I2C driver is using pinctrl to drive its
pins, a call to pinctrl_select_state() try to lock again
pinctrl_mutex which leads to a deadlock.

Notice that the mutex grab from the two direction functions
was moved into pinctrl_gpio_direction().

For several cases, we can't replace pinctrl_mutex by
pctldev->mutex, because at this stage, pctldev is
not accessible :
	- pinctrl_get()/pinctrl_put()
	- pinctrl_register_maps()

So add respectively pinctrl_list_mutex and
pinctrl_maps_mutex in order to protect
pinctrl_list and pinctrl_maps list instead.

Reintroduce pinctrldev_list_mutex in
find_pinctrl_by_of_node(),
pinctrl_find_and_add_gpio_range()
pinctrl_request_gpio(), pinctrl_free_gpio(),
pinctrl_gpio_direction(), pinctrl_devices_show(),
pinctrl_register() and pinctrl_unregister() to
protect pinctrldev_list.

Changes v2->v3:
- Fix a missing EXPORT_SYMBOL_GPL() for pinctrl_select_state().

Changes v1->v2:
- pinctrl_select_state_locked() is removed, all lock mechanism
  is located inside pinctrl_select_state(). When parsing
  the state->setting list, take the per-pin-controller driver
  lock. (Patrice).
- Introduce pinctrldev_list_mutex to protect pinctrldev_list
  in all functions which parse or modify pictrldev_list.
  (Patrice).
- move find_pinctrl_by_of_node() from pinctrl/devicetree.c to
  pinctrl/core.c in order to protect pinctrldev_list.
  (Patrice).
- Sink mutex:es into some functions and remove some _locked
  variants down to where the lists are actually accessed to
  make things simpler. (Linus)
- Drop *all* mutexes completely from pinctrl_lookup_state()
  and pinctrl_select_state() - no relevant mutex was taken
  and it was unclear what this was protecting against. (Linus)

Reported by : Seraphin Bonnaffe <seraphin.bonnaffe@stericsson.com>
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If pin_free is called on a pin already freed, mux_usecount is set to
UINT_MAX which is really a bad idea.

This will issue a warning, so that we can correct the code responsible
for the double free.
Signed-off-by: NRichard Genoud <richard.genoud@gmail.com>
Reviewed-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Currently pinmux_enable_setting does not release all taken pins if
ops->enable() returns error. This patch ensures all taken pins are
released in any error paths.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This switches the way that pins are reserved for multiplexing:

We used to do this when the map was parsed, at the creation of
the settings inside the pinctrl handle, in pinmux_map_to_setting().

However this does not work for us, because we want to use the
same set of pins with different devices at different times: the
current code assumes that the pin groups in a pinmux state will
only be used with one single device, albeit different groups can
be active at different times. For example if a single I2C driver
block is used to drive two different busses located on two
pin groups A and B, then the pins for all possible states of a
function are reserved when fetching the pinctrl handle: the
I2C bus can choose either set A or set B by a mux state at
runtime, but all pins in both group A and B (the superset) are
effectively reserved for that I2C function and mapped to the
device. Another device can never get in and use the pins in
group A, even if the device/function is using group B at the
moment.

Instead: let use reserve the pins when the state is activated
and drop them when the state is disabled, i.e. when we move to
another state. This way different devices/functions can use the
same pins at different times.

We know that this is an odd way of doing things, but we really
need to switch e.g. an SD-card slot to become a tracing output
sink at runtime: we plug in a special "tracing card" then mux
the pins that used to be an SD slot around to the tracing
unit and push out tracing data there instead of SD-card
traffic.

As a side effect pinmux_free_setting() is unused but the stubs
are kept for future additions of code.

Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Loic Pallardy <loic.pallardy@st.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Tested-by: NJean Nicolas Graux <jean-nicolas.graux@stericsson.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Instead of using a temporary buffer, snprintf() and kstrdup(), just
use kasprintf() that does the same thing in just oneline.
Signed-off-by: NThomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Acked-by: NColin Cross <ccross@google.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Some SoCs may not have pinmux disable function in HW.
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Additionally print which pin the request failed for, which entity already
claimed it, and what entity was trying to claim it.

Remove duplicate device name from a debug message.

Clean up some indentation.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

There are a few places in the api where the code simply returns -EINVAL when
it finds an error. An example is pinmux_map_to_setting() which now reports an
error if we try to match a group with a function that it does not support.

The reporting of errors in pinconf_check_ops and pinmux_check_ops now has the
same style and is located inside the according functions and not the calling
code.

When the map is found in the DT but the default state can not be selected we
get an error to know that the code at least tried.

The patch also removes a stray word from one comment and a "->" from another
for the sake of consistency.

Finally we replace a few pr_err/debug() calls with dev_err/dbg().

Thanks go to Stephen Warren for reviewing the patch and enhancing the reporting
inside pinmux_map_to_setting().
Signed-off-by: NJohn Crispin <blogic@openwrt.org>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

pinmux_map_to_setting() uses setting->data.mux.func/group to store the return
code of pinmux_func_name_to_selector/pinctrl_get_group_selector(). However,
struct pinctrl_setting_mux defines these elements as unsigned, resulting in all
error codes getting lost. The conditionals following the assignments will always
evaluate to false thus breaking the error paths.

This bug can be triggered by loading a pinmux group map from the devicetree
with an invalid function/group string.
Signed-off-by: NJohn Crispin <blogic@openwrt.org>
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Pin name is more useful to users.
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch can avoid kernel oops in case the mux or config
function is not supported by driver.
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Do not use get_functions_count before checking.
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Most of the SoC drivers implement list_groups() and list_functions()
routines for pinctrl and pinmux. These routines continue returning
zero until the selector argument is greater than total count of
available groups or functions.

This patch replaces these list_*() routines with get_*_count()
routines, which returns the number of available selection for SoC
driver. pinctrl layer will use this value to check the range it can
choose.

This patch fixes all user drivers for this change. There are other
routines in user drivers, which have checks to check validity of
selector passed to them. It is also no more required and hence
removed.

Documentation updated as well.
Acked-by: NStephen Warren <swarren@wwwdotorg.org>
Signed-off-by: NViresh Kumar <viresh.kumar@st.com>
[Folded in fix and fixed a minor merge artifact manually]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Per recent updates to Documentation/gpio.txt, gpiolib drivers should
inform pinctrl when a GPIO is requested. pinctrl then marks that pin as
in-use for that GPIO function.

When an SoC muxes pins in a group, it's quite possible for the group to
contain e.g. 6 pins, but only 4 of them actually be needed by the HW
module that's mux'd to them. In this case, the other 2 pins could be
used as GPIOs. However, pinctrl marks all the pins within the group as
in-use by the selected mux function. To allow the expected gpiolib
interaction, separate the concepts of pin ownership into two parts: One
for the mux function and one for GPIO usage. Finally, allow those two
ownerships to exist in parallel.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Until recently, the pinctrl pinmux-pins debugfs file displayed the
selected function for each owned pin. This feature was removed during
restructing in support of recent API rework. This change restoreds this
feature, and also displays the group that the function was selected on,
in case a pin is a member of multiple groups.

Based on work by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The pinctrl mapping table can now contain entries to:
* Set the mux function of a pin group
* Apply a set of pin config options to a pin or a group

This allows pinctrl_select_state() to apply pin configs settings as well
as mux settings.

v3: Fix find_pinctrl() to iterate over the correct list.
   s/_MUX_CONFIGS_/_CONFIGS_/ in mapping table macros.
   Fix documentation to use correct mapping table macro.
v2: Added numerous extra PIN_MAP_*() special-case macros.
   Fixed kerneldoc typo. Delete pinctrl_get_pin_id() and
   replace it with pin_get_from_name(). Various minor fixes.
   Updates due to rebase.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Multiple mapping table entries could reference the same pin, and hence
"own" it. This would be unusual now that pinctrl_get() represents a single
state for a client device, but in the future when it represents all known
states for a device, this is quite likely. Implement reference counting
for pin ownership to handle this.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This change separates two aspects of struct pinctrl:

a) The data representation of the parsed mapping table, into:

   1) The top-level struct pinctrl object, a single entity returned
      by pinctrl_get().

   2) The parsed version of each mapping table entry, struct
      pinctrl_setting, of which there is one per mapping table entry.

b) The code that handles this; the code for (1) above is in core.c, and
   the code to parse/execute each entry in (2) above is in pinmux.c, while
   the iteration over multiple settings is lifted to core.c.

This will allow the following future changes:

1) pinctrl_get() API rework, so that struct pinctrl represents all states
   for the device, and the device can select between them without calling
   put()/get() again.

2) To support that, a struct pinctrl_state object will be inserted into
   the data model between the struct pinctrl and struct pinctrl_setting.

3) The mapping table will be extended to allow specification of pin config
   settings too. To support this, struct pinctrl_setting will be enhanced
   to store either mux settings or config settings, and functions will be
   added to pinconf.c to parse/execute pin configuration settings.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

There are many problems with the current pinctrl locking:

struct pinctrl_dev's gpio_ranges_lock isn't effective;
pinctrl_match_gpio_range() only holds this lock while searching for a gpio
range, but the found range is return and manipulated after releading the
lock. This could allow pinctrl_remove_gpio_range() for that range while it
is in use, and the caller may very well delete the range after removing it,
causing pinctrl code to touch the now-free range object.

Solving this requires the introduction of a higher-level lock, at least
a lock per pin controller, which both gpio range registration and
pinctrl_get()/put() will acquire.

There is missing locking on HW programming; pin controllers may pack the
configuration for different pins/groups/config options/... into one
register, and hence have to read-modify-write the register. This needs to
be protected, but currently isn't. Related, a future change will add a
"complete" op to the pin controller drivers, the idea being that each
state's programming will be programmed into the pinctrl driver followed
by the "complete" call, which may e.g. flush a register cache to HW. For
this to work, it must not be possible to interleave the pinctrl driver
calls for different devices.

As above, solving this requires the introduction of a higher-level lock,
at least a lock per pin controller, which will be held for the duration
of any pinctrl_enable()/disable() call.

However, each pinctrl mapping table entry may affect a different pin
controller if necessary. Hence, with a per-pin-controller lock, almost
any pinctrl API may need to acquire multiple locks, one per controller.
To avoid deadlock, these would need to be acquired in the same order in
all cases. This is extremely difficult to implement in the case of
pinctrl_get(), which doesn't know which pin controllers to lock until it
has parsed the entire mapping table, since it contains somewhat arbitrary
data.

The simplest solution here is to introduce a single lock that covers all
pin controllers at once. This will be acquired by all pinctrl APIs.

This then makes struct pinctrl's mutex irrelevant, since that single lock
will always be held whenever this mutex is currently held.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

At present, pinctrl_get() assumes that all matching mapping table entries
have the same "function" value, albeit potentially applied to different
pins/groups.

This change removes this restriction; pinctrl_get() can now handle a set
of mapping tables where different functions are applied to the various
pins/groups.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The debugfs file pinmux-pins used to tell which function was
enabled but now states simply which device owns the pin. Being
owned by the pinctrl driver itself means just that it's hogged
so be a bit more helpful by printing that.

ChangeLog v1->v2:
- Preserve the self-referential owner field, just clarify that
  when the pin controller states itself as owner this means
  that it's hogged.
Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This hopefully makes it harder to take the sizeof the wrong type.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When pins are requested/acquired/got, some device becomes the owner of
their mux setting. At this point, it isn't certain which mux function
will be selected for the pin, since this may vary between each of the
device's states in the pinctrl mapping table. As such, we should record
the owning device, not what we think the initial mux setting will be,
when requesting pins.

This doesn't make a lot of difference right now since pinctrl_get gets
only one single device/state combination, but this will make a difference
when pinctrl_get gets all states, and pinctrl_select_state can switch
between states.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Modify the two files so that the order of function prototypes in the
header matches the order of implementations in the .c file.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This mostly makes debugfs files print things in the order that they
were added or acquired, which just feels a little more consistent.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This moves the per-devices struct pinctrl handles and device map
over from the pinmux part of the subsystem to the core pinctrl part.
This makes the device handles core infrastructure with the goal of
using these handles also for pin configuration, so that device
drivers (or boards etc) will need one and only one handle to the
pin control core.
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since we want to use the former pinmux handles and mapping tables for
generic control involving both muxing and configuration we begin
refactoring by renaming them from pinmux_* to pinctrl_*.

ChangeLog v1->v2:
- Also rename the PINMUX_* macros in machine.h to PIN_ as indicated
  in the documentation so as to reflect the generic nature of these
  mapping entries from now on.
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

After discussion with Mark Brown in an unrelated thread about
ADC lookups, it came to my knowledge that the ability to pass
a struct device * in the regulator consumers is just a
historical artifact, and not really recommended. Since there
are no in-kernel users of these pointers, we just kill them
right now, before someone starts to use them.
Reviewed-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This is needed as otherwise we can get the following when
dealing with buggy data in a pinmux driver for
pinmux_search_function:

Unable to handle kernel NULL pointer dereference at virtual
address 00000000
...
PC is at strcmp+0xc/0x34
LR is at pinmux_get+0x350/0x8f4
...

As we need pctldev initialized to call ops->list_functions,
let's initialize it before check_ops calls and pass the
pctldev to the check_ops functions. Do this for both pinmux
and pinconf check_ops functions.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The ctrl_dev_name is optional for struct pinmux_map assuming
that ctrl_dev is set. Without this patch we can get:

Unable to handle kernel NULL pointer dereference at virtual
address 00000000
...
(pinmux_hog_maps+0xa4/0x20c)
(pinctrl_register+0x2a4/0x378)
...

Fix this by adding adding a test for map->ctrl_dev.
Additionally move the test for map->ctrl_dev earlier
to optimize out the loop a bit.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fix some pinmux typos so implementing pinmux drivers
is a bit easier.
Signed-off-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

It's better to not line break error messages to allow easier grepping
for them even when the line gets >80 chars. Additionally some minor
reformating is done.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>