device_add_properties() performs deep copy of supplied array of properties,
which means that we can discard the original array.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When switching rotary controlelr from plain IRQ number to IRQ resource, I
messed up the syntax.

Fixes: d422be5f ("Input: eeti_ts - expect platform code to set ... ")
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

gpiod API allows standard way of specifying GPIO polarity and takes it into
account when reading or setting GPIO state. It also allows us to switch to
common way of obtaining GPIO descriptor and away form legacy platform data.
Reviewed-by: NDaniel Mack <daniel@zonque.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Instead of keying interrupt trigger off GPIO polarity, let's rely on
platform code to set it up properly for us.
Reviewed-by: NDaniel Mack <daniel@zonque.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Instead of expecting that GPIO is always interrupt source, let's use
interrupt specified in I2C client.
Reviewed-by: NDaniel Mack <daniel@zonque.org>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

All low-level PM/SMP code using virt_to_phys() should actually use
__pa_symbol() against kernel symbols. Update code where relevant to move
away from virt_to_phys().
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: NLaura Abbott <labbott@redhat.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Some of the pxa platforms, balloon3, colibri-pxa270-income, corgi,
trizeps4, vpac270, zeus and zylonite depends on leds.h. Explicitly include
it instead of relying on the public mmc header host.h.

Cc: Daniel Mack <daniel@zonque.org>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: <linux-arm-kernel@lists.infradead.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>

When the header is not included implicitly, we get a build failure:

arch/arm/mach-pxa/idp.c:205:22: error: field 'cdev' has incomplete type
  struct led_classdev     cdev;

This adds an explicit #include.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

The camera_supply_dummy_device definition is shared between a780 and a910,
but only provided when the first is enabled and fails to build for a
configuration with only a910:

arch/arm/mach-pxa/ezx.c:1097:3: error: 'camera_supply_dummy_device' undeclared here (not in a function)

This moves the definition into its own section.

Fixes: 6c1b417a ("ARM: pxa: ezx: use the new pxa_camera platform_data")
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

In the device-tree case, the root interrupt controller cannot be
accessed through the 6th coprocessor, contrary to pxa27x and pxa3xx
architectures.

Fix it to behave as in non-devicetree builds.

Fixes: 32f17997 ("ARM: pxa: remove irq init from dt machines")
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

This partially reverts commit 12beb346 ("Merge tag 'pxa-fixes-v4.8'
of https://github.com/rjarzmik/linux into randconfig-4.8").

This former patch introduced accidentally a double include of module.h.
Signed-off-by: NWei Yongjun <weiyj.lk@gmail.com>
Acked-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
[amended commit message and 2 comments]
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

pxa_camera has transitioned from a soc_camera driver to a standalone
v4l2 driver. Amend the device declaration accordingly.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

pxa_camera has transitioned from a soc_camera driver to a standalone
v4l2 driver. Amend the device declaration accordingly.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

pxa_camera has transitioned from a soc_camera driver to a standalone
v4l2 driver. Amend the device declaration accordingly.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

Instead of having the smc91x driver relying on machine_is_*() calls,
provide this data through platform data, ie. idp, mainstone and
stargate.

This way, the driver doesn't need anymore machine_is_*() calls, which
wouldn't work anymore with a device-tree build.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The method to acquire the input interrupt was working in a platform data
based board, but was failing in a device-tree one when the gpio
controller was probed after pxa_cplds.

Use platform_get_irq() to benefit from the probe deferral
mechanism. Moreover, as seen in dm9000.c development, platform_get_irq()
doesn't honor the irq type IO resource (ie. edge rising for example),
and it must be passed again at irq request in a not device-tree build,
hence the irq_get_trigger_type() call.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

The last user of this function is gone, so remove it. The clock API
should now be used to get clock rates.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>

As both pxa and sa1100 provide a clock to the timer, the rate can be
inferred from the clock rather than hard encoded in a functional call.

This patch changes the pxa timer to have a mandatory clock which is used
as the timer rate.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>

The HTC GPIO driver is a pure GPIO driver and I just can not
see what it is doing inside MFD. Let's just move it to GPIO
and take this opportunity to move the platform data to
<linux/platform_data/gpio-htc-egpio.h>

Cc: arm@kernel.org
Cc: Russell King <linux@armlinux.org.uk>
Acked-by: NLee Jones <lee.jones@linaro.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

Add the required PCMCIA clock for the SA1111 "1800" device.  This clock
is used to compute timing information for the PCMCIA interface in the
SoC device, rather than the SA1111.  Hence, the provision of this clock
is a convenience for the driver and does not reflect the hardware, so
this must not be copied into DT.
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>

Since its initial commit, the driver is buggy for multiple interrupts
handling. The translation from the former lubbock.c file was not
complete, and might stall all interrupt handling when multiple
interrupts occur.

This is especially true when inside the interrupt handler and if a new
interrupt comes and is not handled, leaving the output line still held,
and not creating a transition as the GPIO block behind would expect to
trigger another cplds_irq_handler() call.

For the record, the hardware is working as follows.

The interrupt mechanism relies on :
 - one status register
 - one mask register

Let's suppose the input irq lines are called :
 - i_sa1111
 - i_lan91x
 - i_mmc_cd
Let's suppose the status register for each irq line is called :
 - status_sa1111
 - status_lan91x
 - status_mmc_cd
Let's suppose the interrupt mask for each irq line is called :
 - irqen_sa1111
 - irqen_lan91x
 - irqen_mmc_cd
Let's suppose the output irq line, connected to GPIO0 is called :
 - o_gpio0

The behavior is as follows :
 - o_gpio0 = not((status_sa1111 & irqen_sa1111) |
		 (status_lan91x & irqen_lan91x) |
		 (status_mmc_cd & irqen_mmc_cd))
   => this is a N-to-1 NOR gate and multiple AND gates
 - irqen_* is exactly as programmed by a write to the FPGA
 - status_* behavior is governed by a bi-stable D flip-flop
   => on next FPGA clock :
     - if i_xxx is high, status_xxx becomes 1
     - if i_xxx is low, status_xxx remains as it is
     - if software sets status_xxx to 0, the D flip-flop is reset
       => status_xxx becomes 0
       => on next FPGA clock cycle, if i_xxx is high, status_xxx becomes
	  1 again

Fixes: fc9e38c0 ("ARM: pxa: lubbock: use new pxa_cplds driver")
Reported-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

The init_irq and handle_irq can be declared through standard irqchip
declaration and are not necessary in machine descriptions.

This is another step towards the generic kernel for the pxa
architecture.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NArnd Bergmann <arnd@arndb.de>

* A multiplication for the size determination of a memory allocation
  indicated that an array data structure should be processed.
  Thus use the corresponding function "kmalloc_array".

  This issue was detected by using the Coccinelle software.

* Replace the specification of a data type by a pointer dereference
  to make the corresponding size determination a bit safer according to
  the Linux coding style convention.
Signed-off-by: NMarkus Elfring <elfring@users.sourceforge.net>
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

Magician has GPIO117_I2C_SCL and GPIO118_I2C_SDA pins declared twice.
Signed-off-by: NPetr Cvek <petr.cvek@tul.cz>
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

The commit 9bf448c6 ("ARM: pxa: use generic gpio operation instead of
gpio register") from Oct 17, 2011, leads to the following static checker
warning:
  arch/arm/mach-pxa/spitz_pm.c:172 spitz_charger_wakeup()
  warn: double left shift '!gpio_get_value(SPITZ_GPIO_KEY_INT)
        << (1 << ((SPITZ_GPIO_KEY_INT) & 31))'

As Dan reported, the value is shifted three times :
 - once by gpio_get_value(), which returns either 0 or BIT(gpio)
 - once by the shift operation '<<'
 - a last time by GPIO_bit(gpio) which is BIT(gpio)

Therefore the calculation lead to a chained or operator of :
 - (1 << gpio) << (1 << gpio) = (2^gpio)^gpio = 2 ^ (gpio * gpio)

It is be sheer luck the former statement works, only because each gpio
used is strictly smaller than 6, and therefore 2^(gpio^2) never
overflows a 32 bits value, and because it is used as a boolean value to
check a gpio activation.

As the xxx_charger_wakeup() functions are used as a true/false detection
mechanism, take that opportunity to change their prototypes from integer
return value to boolean one.

Fixes: 9bf448c6 ("ARM: pxa: use generic gpio operation instead of
gpio register")
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: Joe Perches <joe@perches.com>
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

Commit b70661c7 ("net: smc91x: use run-time configuration on all ARM
machines") broke some ARM platforms through several mistakes.  Firstly,
the access size must correspond to the following rule:

(a) at least one of 16-bit or 8-bit access size must be supported
(b) 32-bit accesses are optional, and may be enabled in addition to
    the above.

Secondly, it provides no emulation of 16-bit accesses, instead blindly
making 16-bit accesses even when the platform specifies that only 8-bit
is supported.

Reorganise smc91x.h so we can make use of the existing 16-bit access
emulation already provided - if 16-bit accesses are supported, use
16-bit accesses directly, otherwise if 8-bit accesses are supported,
use the provided 16-bit access emulation.  If neither, BUG().  This
exactly reflects the driver behaviour prior to the commit being fixed.

Since the conversion incorrectly cut down the available access sizes on
several platforms, we also need to go through every platform and fix up
the overly-restrictive access size: Arnd assumed that if a platform can
perform 32-bit, 16-bit and 8-bit accesses, then only a 32-bit access
size needed to be specified - not so, all available access sizes must
be specified.

This likely fixes some performance regressions in doing this: if a
platform does not support 8-bit accesses, 8-bit accesses have been
emulated by performing a 16-bit read-modify-write access.

Tested on the Intel Assabet/Neponset platform, which supports only 8-bit
accesses, which was broken by the original commit.

Fixes: b70661c7 ("net: smc91x: use run-time configuration on all ARM machines")
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Tested-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This is the pxa changes for v4.8 cycle.

This is a tiny fix couple to enable changes in includes in
gpio API without breaking pxa boards.

* tag 'pxa-fixes-v4.8' of https://github.com/rjarzmik/linux:
  ARM: pxa: add module.h for corgi symbol_get/symbol_put usage
  ARM: pxa: add module.h for spitz symbol_get/symbol_put usage

Add a device-tree machine entry (DT_MACHINE_START) for pxa25x based
platforms.

Take the opportunity to sort the file machine descriptions by
alphabetical order.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

Add the device-tree interrupts initialization function required to have
a generic pxa25x device-tree machine.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

As the last pxa related driver was converted to dmaengine, it's time to
kill the legacy dma code, which is not used anymore.

This finishes the pxa dmaengine transition.
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

rtc-v3020.h belongs to include/linux/platform_data/
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>

- dts: rename 'ide-disk' to 'disk-activity'
- platform: rename 'ide-disk' to 'disk-activity'
- defconfig: rename 'LEDS_TRIGGER_IDE_DISK' to 'LEDS_TRIGGER_DISK'
Signed-off-by: NStephan Linz <linz@li-pro.net>
Acked-by: NSekhar Nori <nsekhar@ti.com>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NJacek Anaszewski <j.anaszewski@samsung.com>

Implementing the mtd_ooblayout_ops interface is the new way of exposing
ECC/OOB layout to MTD users.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>

This flag is a no-op now (see commit 47b0eeb3 "clk: Deprecate
CLK_IS_ROOT", 2016-02-02) so remove it.
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>

Pincontrol is not yet ready for all PXA platforms.
For example, a legacy platform, if PINCTRL was activated, will fail its
calls to gpio_request() or gpio_direction_output(), as the pinctrl
driver might not be available, such as for pxa25x and pxa3xx.

As a step forward, activate pincontrol for all device-tree available
machines, ie. pxa27x device-tree based and pxa3xx device-tree based.

If it appears later that pincontrol is also required for legacy
platforms and if the mfp->pinctrl conversion can be achieved, then
PINCTRL will be activated for the whole PXA architecture.

Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>

Since device_add_property_set() now always takes a copy of
the property_set, and also since the fwnode type is always
hard coded to be FWNODE_PDATA, there is no need for the
drivers to deliver the entire struct property_set. The
function can just create the instance of it on its own and
bind the properties from the drivers to it on the spot.

This renames device_add_property_set() to
device_add_properties(). The function now takes struct
property_entry as its parameter instead of struct
property_set.
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NThierry Reding <treding@nvidia.com>
Acked-by: NLee Jones <lee.jones@linaro.org>
Signed-off-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The number of requestor lines was clamped to 0 for all pxa architectures
in the requestor declaration. Fix this by using the value.

Fixes: 72b195cb ("ARM: pxa: add the number of DMA requestor lines")
Signed-off-by: NRobert Jarzmik <robert.jarzmik@free.fr>

gcc-6.0 notices that the use of the property_entry in this file that
was recently introduced cannot work right, as we initialize the wrong
field:

raumfeld.c:387:3: error: the address of 'raumfeld_rotary_encoder_steps' will always evaluate as 'true' [-Werror=address]
   DEV_PROP_U32, 1, &raumfeld_rotary_encoder_steps, },
   ^~~~~~~~~~~~
raumfeld.c:389:3: error: the address of 'raumfeld_rotary_encoder_axis' will always evaluate as 'true' [-Werror=address]
   DEV_PROP_U32, 1, &raumfeld_rotary_encoder_axis, },
   ^~~~~~~~~~~~
raumfeld.c:391:3: error: the address of 'raumfeld_rotary_encoder_relative_axis' will always evaluate as 'true' [-Werror=address]
   DEV_PROP_U32, 1, &raumfeld_rotary_encoder_relative_axis, },
   ^~~~~~~~~~~~

The problem appears to stem from relying on an old definition of
'struct property', but it has changed several times since the code
could have last been correct.

This changes the code to use the PROPERTY_ENTRY_INTEGER() macro instead,
which works fine for the current definition and is a safer way of doing
the initialization.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: a9e340dc ("Input: rotary_encoder - move away from platform data structure")
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

ixp4xx and pxa25x both use this driver and provide a slightly
different set of register definitions for it. Aside from that,
the definition in the ixp4xx-regs.h header conflicts with the
on in the pxa27x device driver when compile-testing that:

In file included from ../drivers/usb/gadget/udc/pxa27x_udc.c:37:0:
../drivers/usb/gadget/udc/pxa27x_udc.h:26:0: warning: "UDCCR" redefined
 #define UDCCR  0x0000  /* UDC Control Register */
 ^
In file included from ../arch/arm/mach-ixp4xx/include/mach/hardware.h:27:0,
                 from ../arch/arm/mach-ixp4xx/include/mach/io.h:18,
                 from ../arch/arm/include/asm/io.h:194,
                 from ../include/linux/io.h:25,
                 from ../include/linux/irq.h:24,
                 from ../drivers/usb/gadget/udc/pxa27x_udc.c:23:
../arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h:415:0: note: this is the location of the previous definition
 #define UDCCR  IXP4XX_USB_REG(IXP4XX_USB_BASE_VIRT+0x0000)

This addresses both issues by moving all the definitions into the
pxa25x_udc driver itself. It turns out the only difference between
them was 'UDCCS_IO_ROF', and that could well be a mistake when it
was incorrectly copied from pxa25x to ixp4xx.
Acked-by: NKrzysztof Halasa <khalasa@piap.pl>
Acked-by: NRobert Jarzmik <robert.jarzmik@free.fr>
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NFelipe Balbi <balbi@kernel.org>

Drop support for platform data passed via a C-structure and switch to
device properties instead, which should make the driver compatible with all
platforms: OF, ACPI and static boards. Static boards should use property
sets to communicate device parameters to the driver.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>