APPLIED: spi: fix SPI_BIT_MASK so it always fits into 32-bits

On a 64-bit platform, ~0UL fills 64-bits, which causes SPI_BIT_MASK(32)
not to fit into 32 bits. This causes a warning when the result is assigned
to a 32-bit variable. Use ~0U instead to prevent this. This fixes:

drivers/spi/spi-gpio.c: In function 'spi_gpio_probe':
drivers/spi/spi-gpio.c:446:2: warning: large integer implicitly truncated to unsigned type [-Woverflow]

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ASoC: dapm: Fix empty list check in dapm_new_mux()

list_first_entry() will always return a valid pointer, even if the list is
empty. So the check whether path is NULL will always be false. So we end up
calling dapm_create_or_share_mixmux_kcontrol() with a path struct that points
right in the middle of the widget struct and by trying to modify the path the
widgets memory will become corrupted. Fix this by using list_emtpy() to check if
the widget doesn't have any paths.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
gpio: clean up gpio-ranges documentation

This change makes documentation of the the gpio-ranges property shorter
and more succinct, more consistent with the style of the rest of the
document, and not mention Linux-specifics such as the API
pinctrl_request_gpio(); DT binding documents should be OS independant
where at all possible. As part of this, the gpio-ranges property's format
is described in BNF form, in order to match the rest of the document.

This change also removes any mention of the #gpio-range-cells property.
Such properties are useful when one node references a second node, and
that second node dictates the format of the reference. However, that is
not the case here; the definition of gpio-ranges itself always dictates
its format entirely, and hence the value #gpio-range-cells must always
be 3, and hence there is no point requiring any referenced node to
include this property.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v3:
* Mention BNF in commit description.
* Fixed typo.
* Dropped patch that removed the deprecated property from *.dts, since
  it's required to boot older kernels.

Patches 2-4 need to be applied in the same branch, since they all build
upon each-other.
of: move documentation of of_parse_phandle_with_args

Commit bd69f73 "of: Create function for counting number of phandles in
a property" renamed of_parse_phandle_with_args(), and created a wrapper
function that implemented the original name. However, the documentation
of the original function was not moved, leaving it apparently documenting
the newly renamed function.

Move the documentation so that it is adjacent to the function it
documents.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
of: introduce of_parse_phandle_with_fixed_args

This is identical to of_parse_phandle_with_args(), except that the
number of argument cells is fixed, rather than being parsed out of the
node referenced by each phandle.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v3: s/cells_count/cell_count, add missing braces per coding style
gpio: implement gpio-ranges binding document fix

Use the new of_parse_phandle_with_fixed_args() to implement the
corrected gpio-ranges DT property definition.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: kexec: validate CPU hotplug support

Architectures should fully validate whether kexec is possible as part of
machine_kexec_prepare(), so that user-space's kexec_load() operation can
report any problems. Performing validation in machine_kexec() itself is
too late, since it is not allowed to return.

Prior to this patch, ARM's machine_kexec() was testing after-the-fact
whether machine_kexec_prepare() was able to disable all but one CPU.
Instead, modify machine_kexec_prepare() to validate all conditions
necessary for machine_kexec_prepare()'s to succeed. BUG if the validation
succeeded, yet disabling the CPUs didn't actually work.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
---
v2: Fix compilation issue when !CONFIG_HOTPLUG_CPU
ARM: allow DEBUG_UNCOMPRESS for Tegra

DEBUG_UNCOMPRESS was previously disallowed for Tegra due to tegra.S's
use of global data that was not linked into the decompressor. Solve this
by declaring this symbol in tegra.S when it is being built into the
decompressor. For the kernel proper, leave the declaration in
mach-tegra/common.c as explained in the comment.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
---
v2: Don't select DEBUG_UNCOMPRESS with DEBUG_TEGRA_UART unless
    !ZBOOT_ROM. Add notes on ZBOOT_ROM to comment.
ARM: tegra: use simplefb for Tegra20 boards with LCDs

Signed-off-by: Stephen Warren <swarren@nvidia.com>
BROKEN: ARM: tegra: trimslice: enable DVI port

The DVI port is driven from the "RGB" port, via a DVI encoder chip.

BROKEN:
* Booting with just DVI plugged in yields a signal the monitor can't sync to.
* Booting with HDMI, then moving the cable to DVI yields incorrect colors and
  a lower resolution than the panel's native resolution (1024x768@67Hz!).

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
[swarren: extracted from a larger patch by Thierry]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
BROKEN: ARM: tegra: cardhu: enable HDMI port

BROKEN because the only bootloaders we have already enable the LCD scanout,
and dual-display stresses the memory bandwidth too much, because the memory
controller programming is way off on Cardhu right now.

Signed-off-by: Mark Zhang <markz@nvidia.com>
[swarren: extracted from a larger patch by Mark]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Revert "BROKEN: ARM: tegra: cardhu: enable HDMI port"

This reverts commit 17c37e0079ade1e6140002dd4ef0f79e08f185c9.
HACK: ARM: dt: tegra: cardhu: Enable LCD panel

HACK: it's missing any of the panel/backlight control GPIOs etc.

Signed-off-by: Mark Zhang <markz@nvidia.com>
[swarren: extracted from a larger patch by Mark]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
LOCAL HACK: tegra_defconfig changes

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: bluetooth testing hacks for Cardhu

Signed-off-by: Stephen Warren <swarren@nvidia.com>
HACK: Attempt to get DMICs working
ARM: tegra: disable LP2 cpuidle state if PCIe is enabled

Tegra20 HW appears to have a bug such that PCIe device interrupts, whether
they are legacy IRQs or MSI, are lost when LP2 is enabled. To work around
this, simply disable LP2 if the PCI driver and DT node are both enabled.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
v2: Set state.disable rather than fiddling with .state_count. This is
more flexible.
usb: host: add has_tdi_phy_lpm capability bit

The has_hostpc capability bit indicates that the host controller has the
HOSTPC register extensions, but at the same time enables clock disabling
power saving features with the PHY Low Power Clock Disable (PHCD) bit.

However, some host controllers have the HOSTPC extensions but don't
support the low-power feature, so the PHCD bit must not be set on those
controllers. Add a separate capability bit for the low-power feature
instead, and change all existing users of has_hostpc to use this new
capability bit.

The idea for this commit is taken from an old 2012 commit that never got
merged ("disociate chipidea PHY low power suspend control from hostpc")

Inspired-by: Matthieu CASTET <matthieu.castet@parrot.com>
Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: phy: tegra: Fix wrong PHY parameters

Some of the PHY parameters are not set according to the TRMs:

- UTMIP_FS_PREABMLE_J should be set, not cleared
- UTMIP_XCVR_LSBIAS_SEL should be cleared, not set
- UTMIP_PD_CHRG should be set in host mode and cleared in device mode
- UTMIP_XCVR_SETUP is a two-part field; the upper bits were not set
  properly

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
usb: phy: tegra: Tegra30 support

The Tegra30 USB PHY is a bit different than the Tegra20 PHY:

- The EHCI controller supports the HOSTPC register extension, and some
  of the fields that the PHY needs to modify (PHCD and PTS) have moved
  to the new HOSTPC register.
- Some of the UTMI PLL configuration registers have moved from the USB
  register space to the Clock-And-Reset controller space. In Tegra30
  the clock driver is responsible for configuring the UTMI PLL.
- The USBMODE register must be explicitly written to enter host mode.
- Certain PHY parameters need to be programmed for optimal signal
  quality. Support for this will be added in the next patch.

The new tegra_phy_soc_config structure is added to describe the
differences between the SoCs.

Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>