The devices here are specific to x86 so lets depend on x86.
Signed-off-by: NPeter Robinson <pbrobinson@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use builtin_platform_driver() helper to simplify the code.
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Adding max20024 compatible string to the device id list
to support both max77620 and max20024 devices.
Signed-off-by: NVenkat Reddy Talla <vreddytalla@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Use builtin_pci_driver() helper to simplify the code.
Signed-off-by: NGeliang Tang <geliangtang@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When a GPIO line is marked as used for an interrupt, it is
helpful to set the label to "interrupt" so we know what is
going on when inspecting the lines.

If a GPIO is already properly named by gpiod_get*() we don't
need to do this. It only happens when a line is used from
the irqchip side of a GPIO driver without communicating
with the GPIO side, such as when gpiochip is used as interrupt
provider in the device tree.

If the line is still marked as used by "interrupt" when we
unmark it as used by an interrupt, also remove this label
from the descriptor.

Also shape up the code around unmarking IRQ lines.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

I saw weird values != [0,1] being passed down to drivers
in their .set_direction_output() callbacks. Go over the
gpiolib and make sure to hammer it to [0,1] before hitting
the driver to avoid undesired side effects.
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When the hardware is in output mode, reading the value from the
hardware is not giving the correct value back. Instead read the
value from the cache so we get the right value.
Suggested-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

This makes is possible to read out the current direction of a
GPIO line on the HTC CPLD GPIO expander.
Suggested-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The newly added acpi_gpiochip_scan_gpios function produces a few harmless
warnings:

drivers/gpio/gpiolib-acpi.c: In function ‘acpi_gpiochip_add’:
drivers/gpio/gpiolib-acpi.c:925:7: error: ‘dflags’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
drivers/gpio/gpiolib-acpi.c:925:9: error: ‘lflags’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

The problem is that he compiler cannot know that a negative return value
from fwnode_property_read_u32_array() or acpi_gpiochip_pin_to_gpio_offset()
implies that the IS_ERR(gpio_desc) is true, as the value could in theory
be below -MAX_ERRNO.

The function already initializes its output values to zero, and moving
that intialization a little higher up ensures that we can never have
uninitialized data in the caller.

Fixes: c80f1ba7 ("ACPI / gpio: Add hogging support")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The gpiod framework uses the chip label to match a specific chip.
The davinci gpio driver, creates several chips using always the same
label, which is not compatible with gpiod.

To allow platform data to declare gpio lookup tables, and for drivers
to use the gpiod framework, allocate unique label per registered chip.
Signed-off-by: NAxel Haslam <ahaslam@baylibre.com>
Reviewed-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NKevin Hilman <khilman@baylibre.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The Kconfig currently controlling compilation of this code is:

drivers/gpio/Kconfig:config HTC_EGPIO
drivers/gpio/Kconfig:   bool "HTC EGPIO support"

...meaning that it currently is not being built as a module by anyone.

Lets remove the modular code that is essentially orphaned, so that
when reading the driver there is no doubt it is builtin-only.

We explicitly disallow a driver unbind, since that doesn't have a
sensible use case anyway, and it allows us to drop the ".remove"
code for non-modular drivers.

Since module_init was not in use by this code, the init ordering
remains unchanged with this commit.

We also delete the MODULE_LICENSE tag etc. since all that information
is already contained at the top of the file in the comments.

Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: Kevin O'Connor <kevin@koconnor.net>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

When terminating for_each_available_child_of_node() iteration
with break or return, of_node_put() should be used to prevent
stale device node references from being left behind.

This is detected by Coccinelle semantic patch.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: NVladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Fixes the following sparse warning:

drivers/gpio/gpiolib-acpi.c:863:18: warning:
 symbol 'acpi_gpiochip_parse_own_gpio' was not declared. Should it be static?
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

fwnode_handle_put() should be used when terminating
device_for_each_child_node() iteration with break or
return to prevent stale device node references from
being left behind.

This is detected by Coccinelle semantic patch.
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Confirm the chip->parent is valid before dereferencing because
the parent parameter is optional.
Signed-off-by: NThor Thayer <tthayer@opensource.altera.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

It's not necessary to unregister gpio_chip which registered
with devm_gpiochip_add_data().
Also get rid of useless altr_a10sr_gpio_remove().
Signed-off-by: NWei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

According to the reference manual level interrupts can't be acked
using the IRQSTAT registers. The effect is that when a level interrupt
triggers the following ack is a no-op and the same interrupt triggers
again right after it has been unmasked after running the interrupt
handler.

The reference manual says:

Status bits for pins configured as level sensitive interrupts cannot be
cleared unless either the actual pin is in the non-interrupting state, or
the pin has been disabled as an interrupt source by clearing its bit in
HW_PINCTRL_PIN2IRQ.

To work around the duplicated interrupts we can use the PIN2IRQ
rather than the IRQEN registers to mask the interrupts. This
probably does not work for the edge interrupts, so we have to split up
the irq chip into two chip types, one for the level interrupts and
one for the edge interrupts. We now make use of two different enable
registers, so we have to take care to always enable the right one,
especially during switching of the interrupt type. An easy way
to accomplish this is to use the IRQCHIP_SET_TYPE_MASKED which
makes sure that set_irq_type is called with masked interrupts. With this
the flow to change the irq type is like:

- core masks interrupt (using the current chip type)
- mxs_gpio_set_irq_type() changes chip type if necessary
- mxs_gpio_set_irq_type() unconditionally sets the enable bit in the
  now unused enable register
- core eventually unmasks the interrupt (using the new chip type)
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The mxs gpio controller does not only have a mask register to mask
interrupts, but also enable/disable registers. Use the enable/disable
registers rather than the mask register. This does not have any
advantage for now, but makes the next patch simpler.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Now that we have the new helper function that sets nice names for GPIO
lines based on "gpio-line-names" device property, we can take advantage of
this in acpi_gpiochip_add().
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

In order to use "gpio-line-names" property in systems not having DT as
their boot firmware, rework of_gpiochip_set_names() to use device property
accessors. This reworked function is placed in a separate file making it
clear it deals with universal device properties.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

GPIO hogging means that the GPIO controller can "hog" and configure certain
GPIOs without need for a driver or userspace to do that. This is useful in
open-connected boards where BIOS cannot possibly know beforehand which
devices will be connected to the board.

This adds GPIO hogging mechanism to ACPI analogous to Device Tree.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Make it possible to have an empty GPIOs in a GPIO list for device. For
example a SPI master may use both GPIOs and native pins as chip selects and
we need to be able to distinguish between the two.

This makes it mandatory to have exactly 3 arguments for GPIOs and then
converts gpiolib to use of __acpi_node_get_property_reference() instead. In
addition we make acpi_gpio_package_count() to handle holes as well (this
matches the DT version).
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add compatible string for the MAX7318 part. This is a two bank,
16 lines, I2C GPIO expander with interrupt line.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

All the boards supported by the gpio-ts4900 driver are i.MX6 boards,
so only offer the driver for building on this platform, unless
build-testing.
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Cc: Lucile Quirion <lucile.quirion@savoirfairelinux.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Signed-off-by: NBamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add basic gpio operations. User could get/set gpio value for specific
line of gpiochip.

Reference "tools/gpio/gpio-hammer.c" or
"tools/testing/selftest/gpio/gpio-mockup-chardev.c" for how to use it.
Signed-off-by: NBamvor Jian Zhang <bamvor.zhangjian@linaro.org>
Reviewed-by: NMichael Welling <mwelling@ieee.org>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add the GPIO functionality for the Altera Arria10 MAX5 System Resource
Chip. The A10 MAX5 has 12 bits of GPIO assigned to switches, buttons,
and LEDs as a GPIO extender on the SPI bus.
Signed-off-by: NThor Thayer <tthayer@opensource.altera.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>i
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We switch the default handler to be handle_bad_irq() instead of
handle_simple_irq() (which was not correct anyway).
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Current code does not use gpio_irq/irq_base/gpio_base fields from
struct max77620_gpio, so remove them.
Signed-off-by: NAxel Lin <axel.lin@ingics.com>
Acked-by: NLaxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

It should have been @reg_clr instead of @reg_clk
Signed-off-by: NAnthony Best <anthonybest@bestanthony.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Since the I2C sx150x GPIO expander driver uses platform_data to manage
the pins configurations, rewrite the driver as a pinctrl driver using
pinconf to get/set pin configurations from DT or debugfs.

The pinctrl driver is functionnally equivalent as the gpio-only driver
and can use DT for pinconf. The platform_data confirmation is dropped.

This patchset removed the gpio-only driver and selects the Pinctrl driver
config instead. This patchset also migrates the gpio dt-bindings to pinctrl
and add the pinctrl optional properties.

The driver was tested with a SX1509 device on a BeagleBone black with
interrupt support and on an X86_64 machine over an I2C to USB converter.

This is a fixed version that builds and runs on non-OF platforms and on
arm based OF. The GPIO version is removed and the bindings are also moved
to the pinctrl bindings.

Changes since v2
 - rebased on v4.9-rc1
 - removed MODULE_DEVICE_TABLE as in upstream bb411e77
   ("gpio: sx150x: fix implicit assumption module.h is present")

Changes since v1
 - Fix Kconfig descriptions on pinctrl and gpio
 - Fix Kconfig dependency
 - Remove oscio support for non-789 devices
 - correct typo in dt bindings
 - remove probe reset for non-789 devices

Changes since RFC
 - Put #ifdef CONFIG_OF/CONFIG_OF_GPIO to remove OF code for non-of platforms
 - No more rely on OF_GPIO config
 - Moved and enhanced bindings to pinctrl bindings
 - Removed gpio-sx150x.c
 - Temporary select PINCTRL_SX150X when GPIO_SX150X
 - Temporary mark GPIO_SX150X as deprecated
Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
Tested-by: NPeter Rosin <peda@axentia.se>
Acked-by: NRob Herring <robh@kernel.org>
ested-by: NAndrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Pull UBI[FS] fixes from Richard Weinberger:
 "This contains fixes for issues in both UBI and UBIFS:

   - Fallout from the merge window, refactoring UBI code introduced some
     issues.

   - Fixes for an UBIFS readdir bug which can cause getdents() to busy
     loop for ever and a bug in the UBIFS xattr code"

* tag 'upstream-4.9-rc2' of git://git.infradead.org/linux-ubifs:
  ubifs: Abort readdir upon error
  UBI: Fix crash in try_recover_peb()
  ubi: fix swapped arguments to call to ubi_alloc_aeb
  ubifs: Fix xattr_names length in exit paths
  ubifs: Rename ubifs_rename2

Pull ext4 fixes from Ted Ts'o:
 "A few bug fixes and add some missing KERN_CONT annotations"

* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  ext4: add missing KERN_CONT to a few more debugging uses
  fscrypto: lock inode while setting encryption policy
  ext4: correct endianness conversion in __xattr_check_inode()
  fscrypto: make XTS tweak initialization endian-independent
  ext4: do not advertise encryption support when disabled
  jbd2: fix incorrect unlock on j_list_lock
  ext4: super.c: Update logging style using KERN_CONT

Pull SCSI target fixes from Nicholas Bellinger:
 "Here are the outstanding target-pending fixes for v4.9-rc2.

  This includes:

   - Fix v4.1.y+ reference leak regression with concurrent TMR
     ABORT_TASK + session shutdown. (Vaibhav Tandon)

   - Enable tcm_fc w/ SCF_USE_CPUID to avoid host exchange timeouts
     (Hannes)

   - target/user error sense handling fixes. (Andy + MNC + HCH)

   - Fix iscsi-target NOP_OUT error path iscsi_cmd descriptor leak
     (Varun)

   - Two EXTENDED_COPY SCSI status fixes for ESX VAAI (Dinesh Israni +
     Nixon Vincent)

   - Revert a v4.8 residual overflow change, that breaks sg_inq with
     small allocation lengths.

  There are a number of folks stress testing the v4.1.y regression fix
  in their environments, and more folks doing iser-target I/O stress
  testing atop recent v4.x.y code.

  There is also one v4.2.y+ RCU conversion regression related to
  explicit NodeACL configfs changes, that is still being tracked down"

* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  target/tcm_fc: use CPU affinity for responses
  target/tcm_fc: Update debugging statements to match libfc usage
  target/tcm_fc: return detailed error in ft_sess_create()
  target/tcm_fc: print command pointer in debug message
  target: fix potential race window in target_sess_cmd_list_waiting()
  Revert "target: Fix residual overflow handling in target_complete_cmd_with_length"
  target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code
  target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET DEVICE NOT REACHABLE
  target: Re-add missing SCF_ACK_KREF assignment in v4.1.y
  iscsi-target: fix iscsi cmd leak
  iscsi-target: fix spelling mistake "Unsolicitied" -> "Unsolicited"
  target/user: Fix comments to not refer to data ring
  target/user: Return an error if cmd data size is too large
  target/user: Use sense_reason_t in tcmu_queue_cmd_ring

Merge tag 'hwmon-for-linus-v4.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging

Pull hwmon fixes from Guenter Roeck:
 "Couple of hwmon fixes:

  Fix a potential ERR_PTR dereference in max31790 driver, and handle
  temperature readings below 0 in adm9240 driver"

* tag 'hwmon-for-linus-v4.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (max31790) potential ERR_PTR dereference
  hwmon: (adm9240) handle temperature readings below 0

Pull IPMI updates from Corey Minyard:
 "A small bug fix and a new driver for acting as an IPMI device.

  I was on vacation during the merge window (a long vacation) but this
  is a bug fix that should go in and a new driver that shouldn't hurt
  anything.

  This has been in linux-next for a month or so"

* tag 'for-linus-4.9-2' of git://git.code.sf.net/p/openipmi/linux-ipmi:
  ipmi: fix crash on reading version from proc after unregisted bmc
  ipmi/bt-bmc: remove redundant return value check of platform_get_resource()
  ipmi/bt-bmc: add a dependency on ARCH_ASPEED
  ipmi: Fix ioremap error handling in bt-bmc
  ipmi: add an Aspeed BT IPMI BMC driver

Pull timer updates from Thomas Gleixner:
 "This updates contains:

   - A revert which addresses a boot failure on ARM Sun5i platforms

   - A new clocksource driver, which has been delayed beyond rc1 due to
     an interrupt driver issue which was unearthed by this driver. The
     debugging of that issue and the discussion about the proper
     solution made this driver miss the merge window. There is no point
     in delaying it for a full cycle as it completes the basic mainline
     support for the new JCore platform and does not create any risk
     outside of that platform"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  Revert "clocksource/drivers/timer_sun5i: Replace code by clocksource_mmio_init"
  clocksource: Add J-Core timer/clocksource driver
  of: Add J-Core timer bindings