This patch modifies a offset while enumerating pins to support a
partial pin space. If we use a pin number for enumerating pins,
the pin space always starts with zero base. Indeed, we always check
the pin is in the pin space. An extreme example, there is only two pins.
One is 0. Another is 1000. We always enumerate whole offsets until 1000.
For solving this problem, we use the offset of the pin array instead
of the zero-based pin number.
Signed-off-by: NChanho Park <chanho61.park@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
[Restored sparse pin space comment]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Minor copyedits.
Signed-off-by: NDong Aisheng <dong.aisheng@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

For stringent order, rename the pinmux-* pin controllers to
pinctrl-* and also rename the Kconfig symbols and in-kernel
users.

Cc: Rongjun Ying <Rongjun.Ying@csr.com>
Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Obtaining a "struct pinctrl_dev *" is difficult for code not directly
related to the pinctrl subsystem. However, the device name of the pinctrl
device is fairly well known. So, modify pin_config_*() to take the device
name instead of the "struct pinctrl_dev *".
Signed-off-by: NStephen Warren <swarren@nvidia.com>
[rebased on top of refactoring code]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

If pins with blank names are registered, we assign them names on-the-fly
on the form "PINn" where n is the pin number for that pin on the specific
controller.
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Pin controllers should already be instantiated as a device, so there's
no need for the pinctrl core to create a new struct device for each
controller.

This allows the controller's real name to be used in the mux mapping
table, rather than e.g. "pinctrl.0", "pinctrl.1", etc.

This necessitates removal of the PINMUX_MAP_PRIMARY*() macros, since
their sole purpose was to hard-code the .ctrl_dev_name field to be
"pinctrl.0".
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This add per-pin and per-group pin config interfaces for biasing,
driving and other such electronic properties. The details of passed
configurations are passed in an opaque unsigned long which may be
dereferences to integer types, structs or lists on either side
of the configuration interface.

ChangeLog v1->v2:
- Clear split of terminology: we now have pin controllers, and
  those may support two interfaces using vtables: pin
  multiplexing and pin configuration.
- Break out pin configuration to its own C file, controllers may
  implement only config without mux, and vice versa, so keep each
  sub-functionality of pin controllers separate. Introduce
  CONFIG_PINCONF in Kconfig.
- Implement some core logic around pin configuration in the
  pinconf.c file.
- Remove UNKNOWN config states, these were just surplus baggage.
- Remove FLOAT config state - HIGH_IMPEDANCE should be enough for
  everyone.
- PIN_CONFIG_POWER_SOURCE added to handle switching the power
  supply for the pin logic between different sources
- Explicit DISABLE config enums to turn schmitt-trigger,
  wakeup etc OFF.
- Update documentation to reflect all the recent reasoning.
ChangeLog v2->v3:
- Twist API around to pass around arrays of config tuples instead
  of (param, value) pairs everywhere.
- Explicit drive strength semantics for push/pull and similar
  drive modes, this shall be the number of drive stages vs
  nominal load impedance, which should match the actual
  electronics used in push/pull CMOS or TTY totempoles.
- Drop load capacitance configuration - I probably don't know
  what I'm doing here so leave it out.
- Drop PIN_CONFIG_INPUT_SCHMITT_OFF, instead the argument zero to
  PIN_CONFIG_INPUT_SCHMITT turns schmitt trigger off.
- Drop PIN_CONFIG_NORMAL_POWER_MODE and have a well defined
  argument to PIN_CONFIG_LOW_POWER_MODE to get out of it instead.
- Drop PIN_CONFIG_WAKEUP_ENABLE/DISABLE and just use
  PIN_CONFIG_WAKEUP with defined value zero to turn wakeup off.
- Add PIN_CONFIG_INPUT_DEBOUNCE for configuring debounce time
  on input lines.
- Fix a bug when we tried to configure pins for pin controllers
  without pinconf support.
- Initialized debugfs properly so it works.
- Initialize the mutex properly and lock around config tampering
  sections.
- Check the return value from get_initial_config() properly.
ChangeLog v3->v4:
- Export the pin_config_get(), pin_config_set() and
  pin_config_group() functions.
- Drop the entire concept of just getting initial config and
  keeping track of pin states internally, instead ask the pins
  what state they are in. Previous idea was plain wrong, if the
  device cannot keep track of its state, the driver should do
  it.
- Drop the generic configuration layout, it seems this impose
  too much restriction on some pin controllers, so let them do
  things the way they want and split off support for generic
  config as an optional add-on.
ChangeLog v4->v5:
- Introduce two symmetric driver calls for group configuration,
  .pin_config_group_[get|set] and corresponding external calls.
- Remove generic semantic meanings of return values from config
  calls, these belong in the generic config patch. Just pass the
  return value through instead.
- Add a debugfs entry "pinconf-groups" to read status from group
  configuration only, also slam in a per-group debug callback in
  the pinconf_ops so custom drivers can display something
  meaningful for their pins.
- Fix some dangling newline.
- Drop dangling #else clause.
- Update documentation to match the above.
ChangeLog v5->v6:
- Change to using a pin name as parameter for the
  [get|set]_config() functions, as suggested by Stephen Warren.
  This is more natural as names will be what a developer has
  access to in written documentation etc.
ChangeLog v6->v7:
- Refactor out by-pin and by-name get/set functions, only expose
  the by-name functions externally, expose the by-pin functions
  internally.
- Show supported pin control functionality in the debugfs
  pinctrl-devices file.
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This makes the COH 901 driver request muxing of its GPIO pins
from the pinmux-u300 driver using the standard API calls.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This register the actual GPIO ranges used by the COH901XXX GPIO
driver.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This driver will be converted to a dual GPIO + pinctrl driver
since it supports biasing and driving control options. Hopefully
it can serve as an example.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since we now anyway make a copy of the platform-supplied pinmux
map, we can just as well make it possible to call the function
adding maps several times, so as to simplify cases (as PXA) where
several sets of disparate mappings need to be added depending on
target platform.
Acked-by: NHaojian Zhuang <haojian.zhuang@gmail.com>
Acked-by: NArnd Bergmann <arnd@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This makes a deep copy of the pinmux function map instead of
keeping the copy supplied from the platform around. This makes
it possible to tag the platforms map with __initdata as is also
done as part of this patch.

Rationale: a certain target platform (PXA) has numerous
pinmux maps, many of which will be lying around unused after
boot in a multi-platform binary. Instead, deep-copy the one
we're going to use and tag them all __initdata so they go away
after boot.

ChangeLog v1->v2:
- Fixup the deep copy, missed a few items on the struct,
  plus mark bool member non-const since we're making runtime
  copies if this stuff now.
ChangeLog v2->v3:
- Make a shallow copy (just copy the array of map structs)
  as Arnd noticed, string constants never get discarded by the
  kernel anyway, so these pointers may be safely copied over.
Reviewed-by: NArnd Bergmann <arnd.bergmann@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When requesting a single GPIO pin to be muxed in, some controllers
will need to poke a different value into the control register
depending on whether the pin will be used for GPIO output or GPIO
input. So create pinmux counterparts to gpio_direction_[input|output]
in the pinctrl framework.

ChangeLog v1->v2:
- This also amends the documentation to make it clear the this
  function and associated machinery is *ONLY* intended as a backend
  to gpiolib machinery, not for everyone and his dog to start playing
  around with pins.
ChangeLog v2->v3:
- Don't pass an argument to the common request function, instead
  provide pinmux_* counterparts to the gpio_direction_[input|output]
  calls, simpler and anyone can understand it.
ChangeLog v3->v4:
- Fix numerous spelling mistakes and dangling text in documentation.
  Add Ack and Rewewed-by.

Cc: Igor Grinberg <grinberg@compulab.co.il>
Acked-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NThomas Abraham <thomas.abraham@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Show the mapped pin range corresponding to the GPIO range in
debugfs for pin controllers.
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This patch enables mapping a base offset of gpio ranges with
a pin offset even if does'nt matched. A base of pinctrl_gpio_range
means a base offset of gpio. However, we cannot convert gpio to pin
number for sparse gpio ranges just only using a gpio base offset.
We can convert a gpio to real pin number(even if not matched) using
a new pin_base which means a base pin offset of requested gpio range.
Now, the pin control subsystem passes the pin base offset to the
pinmux driver.

For example, let's assume below two gpio ranges in the system.

static struct pinctrl_gpio_range gpio_range_a = {
    .name = "chip a",
    .id = 0,
    .base = 32,
    .pin_base = 32,
    .npins = 16,
    .gc = &chip_a;
};

static struct pinctrl_gpio_range gpio_range_b = {
    .name = "chip b",
    .id = 0,
    .base = 48,
    .pin_base = 64,
    .npins = 8,
    .gc = &chip_b;
};

We can calucalate a exact pin ranges even if doesn't matched with gpio ranges.

chip a:
    gpio-range : [32 .. 47]
    pin-range  : [32 .. 47]
chip b:
    gpio-range : [48 .. 55]
    pin-range  : [64 .. 71]
Signed-off-by: NChanho Park <chanho61.park@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We want singned pins to mean "invalid" only on the outside
of the subsystem.
Signed-off-by: NMarek Belisko <marek.belisko@open-nandra.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Update the docs removing an obsolete __refdata tag and document
the mysterious return value of pin_free(). And fixes up some various
confusions in the pinctrl documentation.
Reported-by: NRajendra Nayak <rnayak@ti.com>
Reported-by: NRandy Dunlap <rdunlap@xenotime.net>
Reported-by: NThomas Abraham <thomas.abraham@linaro.org>
Reported-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Some pinctrl drivers (Tegra at least) program a pin to be a GPIO in a
completely different manner than they select which function to mux out of
that pin. In order to support a single "free" pinmux_op, the driver would
need to maintain a per-pin state of requested-for-gpio vs. requested-for-
function. However, that's a lot of work when the core already has explicit
separate paths for gpio request/free and function request/free.

So, add a gpio_disable_free op to struct pinmux_ops, and make pin_free()
call it when appropriate.

When doing this, I noticed that when calling pin_request():

    !!gpio == (gpio_range != NULL)

... and so I collapsed those two parameters in both pin_request(), and
when adding writing the new code in pin_free().

Also, for pin_free():

    !!free_func == (gpio_range != NULL)

However, I didn't want pin_free() to know about the GPIO function naming
special case, so instead, I reworked pin_free() to always return the pin's
previously requested function, and now pinmux_free_gpio() calls
kfree(function). This is much more balanced with the allocation having
been performed in pinmux_request_gpio().
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Function pin_is_valid just call pin_desc_get which is in pin_request
call some line below. Remove pin_is_valid() check.
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMarek Belisko <marek.belisko@open-nandra.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Now also the core needs to look up pin groups so move the lookup
function there and expose it in the internal header.
Acked-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fix u300_pmx_endisable() to iterate over the list of 'bits' and
'mask' populated as part of u300_pmx_functions.mask[]
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

DEBUG_PINCTRL wasn't used at all and DEBUG_PINMUX doesn't exist.
Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Signed-off-by: NBarry Song <Baohua.Song@csr.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

virtio pci device reset actually just does an I/O
write, which in PCI is really posted, that is it
can complete on CPU before the device has received it.

Further, interrupts might have been pending on
another CPU, so device callback might get invoked after reset.

This conflicts with how drivers use reset, which is typically:
	reset
	unregister
a callback running after reset completed can race with
unregister, potentially leading to use after free bugs.

Fix by flushing out the write, and flushing pending interrupts.

This assumes that device is never reset from
its vq/config callbacks, or in parallel with being
added/removed, document this assumption.
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Guest features selector spelling mistake.

Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization@lists.linux-foundation.org
Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Fix this compile error on s390:

  CC [M]  drivers/virtio/virtio_mmio.o
drivers/virtio/virtio_mmio.c: In function 'vm_get_features':
drivers/virtio/virtio_mmio.c:107:2: error: implicit declaration of function 'writel'

Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: NPawel Moll <pawel.moll@arm.com>
Signed-off-by: NRusty Russell <rusty@rustcorp.com.au>

Count of selector voltage is required for regulator_set_voltage
to work via set_voltage_sel. VDD1/2 currently have it as zero,
so regulator_set_voltage won't work for VDD1/2.
Update count (n_voltages) for VDD1/2.

Output Voltage = (step value * 12.5 mV + 562.5 mV) * gain

With above expr, number of voltages that can be selected is
step value count * gain count

constant for gain count will be called VDD1_2_NUM_VOLT_COARSE

existing constant for step value count is VDD1_2_NUM_VOLTS,
use VDD1_2_NUM_VOLT_FINE instead to make clear that step value
is not the only component in deciding selectable voltage count
Signed-off-by: NAfzal Mohammed <afzal@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>

The function i2cdev_notifier_call is used only in i2c-dev file
making it static.
Also removes the following sparse warning

drivers/i2c/i2c-dev.c:582:5: warning: symbol 'i2cdev_notifier_call'
was not declared. Should it be static?
Signed-off-by: NShubhrajyoti D <shubhrajyoti@ti.com>
Signed-off-by: NJean Delvare <khali@linux-fr.org>

10-bit addresses overlap with traditional 7-bit addresses, leading in
device name collisions. Add an arbitrary offset to 10-bit addresses to
prevent this collision. The offset was chosen so that the address is
still easily recognizable.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Acked-by: NWolfram Sang <w.sang@pengutronix.de>

The wrong bits were put on the wire, fix that.

This fixes kernel bug #42562.
Signed-off-by: NSheng-Hui J. Chu <jeffchu@broadcom.com>
Cc: stable@kernel.org
Signed-off-by: NJean Delvare <khali@linux-fr.org>

There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
if userspace passes in a large num_clips.  The call to kmalloc would
allocate a small buffer, and the call to fb->funcs->dirty may result
in a memory corruption.
Reported-by: NHaogang Chen <haogangchen@gmail.com>
Signed-off-by: NXi Wang <xi.wang@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

This reverts commit dc937280.

As requested by Ben Herrenschmidt:
  "This breaks some powerpc platforms at least.  The practice of having
   a node provide an explicit "interrupt-parent" property pointing to
   itself is an old trick that we've used in the past to allow a
   device-node to have interrupts routed to different controllers.

   In that case, the node also contains an interrupt-map, so the node is
   its own parent, the interrupt resolution hits the map, which then can
   route each individual interrupt to a different parent."

Grant says:
  "Ah, nuts, yes that is broken then.  Yes, please revert the commit and
   Rob & I will come up with a better solution.

   Rob, I think it can be done by explicitly checking for np ==
   desc->interrupt_parent in of_irq_init() instead of relying on
   of_irq_find_parent() returning NULL."
Requested-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Cc: Tanmay Inamdar <tinamdar@apm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

kbuf is a buffer that is local to this function, so all of the error paths
leaving the function should release it.
Signed-off-by: NJulia Lawall <julia@diku.dk>
Cc: Jesper Juhl <jj@chaosbits.net>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Split the quirks and i2c_rec assignment into separate
functions used by both radeon_lookup_i2c_gpio() and
radeon_atombios_i2c_init().  This avoids duplicating code
and cases where quirks were only added to one of the
functions.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes i2c test failures when i2c_algo_bit.bit_test=1.

The hw doesn't actually require a mask, so just set it
to the default mask bits for r1xx-r4xx radeon ddc.

I missed this part the first time through.
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Cc: stable@kernel.org
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

An unlikely race could case a bo to be returned reserved on an error path.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

it can fail and in that case ->release() will *not* be called...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

This adds a new optional chunk to the CS ioctl that specifies optional flags
to the CS parser. Why this is useful is explained below. Note that some regs
no longer need the NOP relocation packet if this feature is enabled.
Tested on r300g and r600g with this flag disabled and enabled.

Assume there are two contexts sharing the same mipmapped tiled texture.
One context wants to render into the first mipmap and the other one
wants to render into the last mipmap. As you probably know, the hardware
has a MACRO_SWITCH feature, which turns off macro tiling for small mipmaps,
but that only applies to samplers.
(at least on r300-r500, though later hardware likely behaves the same)

So we want to just re-set the tiling flags before rendering (writing
packets), right? ... No. The contexts run in parallel, so they may
set the tiling flags simultaneously and then fire their command streams
also simultaneously. The last one setting the flags wins, the other one
loses.

Another problem is when one context wants to render into the first and
the last mipmap in one CS. Impossible. It must flush before changing
tiling flags and do the rendering into the smaller mipmaps in another CS.

Yet another problem is that writing copy_blit in userspace would be a mess
involving re-setting tiling flags to please the kernel, and causing races
with other contexts at the same time.

The only way out of this is to send tiling flags with each CS, ideally
with each relocation. But we already do that through the registers.
So let's just use what we have in the registers.
Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

ET131X is a network device, so it should depend on
NETDEVICES.  (This part won't be needed when the driver
moves to drivers/net/.)  It also uses PHYLIB interfaces,
so it should select PHYLIB.  Fixes these build errors:

ERROR: "phy_connect" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_find_first" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "mdiobus_register" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "mdiobus_alloc" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_stop" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_start" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "mdiobus_free" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "mdiobus_unregister" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_print_status" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_ethtool_gset" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_ethtool_sset" [drivers/staging/et131x/et131x.ko] undefined!
ERROR: "phy_mii_ioctl" [drivers/staging/et131x/et131x.ko] undefined!
Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net>
Acked-by: N: Mark Einon <mark.einon@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>