ARM: OMAP3+: dpll: Configure autoidle mode only if it's supported

The current DPLL code enables and disables autoidle features
without checking whether the autoidle register is available.
Fix this by putting a check for the existence of the autoidle
register in the DPLL data.

With such a check in place, for DPLLs which do not support this
feature, simply skipping the autoidle_reg entry in the DPLL data
is sufficient.

Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: dmtimer: cleanup iclk usage

We do not use iclk anywhere in the dmtimer driver and so removing it.
Hence removing the timer iclk entries from OMAP4 clkdev table as well.

Signed-off-by: Tarun Kanti DebBarma <tarun.kanti@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: add DEBUGSS skeleton

Add a skeleton hwmod for the DEBUGSS and associated interconnect data.
This is a basic set of data that will need further additions as
further DEBUGSS information becomes available.

Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: add PRCM and related IP blocks

Add the PRCM, CM, PRM, and related hwmod and associated interconnect
data.  These IP blocks handle most of the on-chip power, reset, and clock
control.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP4: hwmod data: add System Control Module

Add the System Control Module hwmod and associated interconnect data.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP4: hwmod data: add the OCP-WP IP block

Add the OCP-WP hwmod and associated interconnect data.  The OCP-WP,
or OCP watchpoint, can be used to collect interconnect data and
transmit it via the STM port.

Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: add OCM RAM IP block

Add the OCM RAM IP block and interconnect data.  This is an oh-chip
block of SRAM connected directly to the L3 bus.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP4: hwmod data: add remaining USB-related IP blocks

Add the OCP2SCP IP block and interconnect data.  The OCP2SCP can be
used in conjunction with the on-chip embedded USB PHY, associated with
the OTG controller.

Add the on-chip full-speed USB host controller IP block and
interconnect data.

Cc: Felipe Balbi <balbi@ti.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: add some interconnect-related IP blocks

Add the SL2 interface IP block and interconnect data.  The SL2 is related
to the IVA-HD subsystem.

Add IP block and interconnect data for the C2C ("Chip-to-chip")
interconnect.  This can provide a direct system interconnect link to
other devices stacked on the OMAP package.

Add the ELM IP block and interconnect data.  The ELM can be used
to locate errors in NAND flash connected to the GPMC.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP4: hwmod data: add McASP

Add the McASP hwmod and associated interconnect data.  The McASP is a
general-purpose audio serial port.

Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: add the Slimbus IP blocks

Add the Slimbus hwmods and associated interconnect data.  The Slimbus
IP blocks implement a two-wire serial interface.

Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: add GPU

Add the GPU hwmod and associated interconnect data.  The GPU is a
graphics accelerator.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP4: hwmod data: add EMIF1 and 2

Add the EMIF1 and 2 hwmods and associated interconnect data.  The EMIFs
are SDRAM interface IP blocks.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP4: hwmod data: add GPMC

Add the GPMC hwmod and associated interconnect data.   The GPMC is a
programmable parallel-bus memory controller.

Signed-off-by: Benoît Cousson <b-cousson@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP4: hwmod data: add HDQ/1-wire

Add the HDQ/1-wire hwmod and associated interconnect data.  The
HDQ/1-wire IP block is a low-speed serial interconnect.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Signed-off-by: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP4: hwmod data: introduce fdif(face detect module) hwmod

Add hwmod data for the OMAP4 FDIF IP block.

This patch also includes a change (originally from Fernando Guzman
Lugo <fernando.lugo@ti.com>) to set a softreset delay for the FDIF IP
block:

   http://www.spinics.net/lists/arm-kernel/msg161874.html

Signed-off-by: Ming Lei <ming.lei@canonical.com>
Acked-by: Benoît Cousson <b-cousson@ti.com>
Cc: Fernando Guzman Lugo <fernando.lugo@ti.com>
[paul@pwsan.com: rearranged to match script output; fixed FDIF end address to
 match script data; wrote trivial changelog; combined the FDIF portion of
 Fernando's srst_udelay patch]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: clockdomains: make {prm,cm}_clkdm common

The PRM and CM implicit clockdomains will soon be used by OMAP44xx.
So, make them common to OMAP2+ and modify the OMAP4 clockdomains code
so use of these clockdomains doesn't crash the system.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Rajendra Nayak <rnayak@ti.com>

ARM: OMAP2xxx: hwmod data: start to fix the IVA1, IVA2 and DSP

N800 logs this message on boot:

[    0.182281] omap_hwmod: iva: cannot be enabled for reset (3)

Fix by creating basic IVA1 and DSP hwmods for OMAP2420, and a basic IVA2
hwmod for OMAP2430.  There is still more information to be added, but
this should resolve the immediate issue.

Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: hwmod data: add IVA hard reset lines, main clock, clockdomain

The IVA hwmod data is missing some fields that cause the following
warning on boot:

[    0.118011] omap_hwmod: iva: cannot be enabled for reset (3)

Fix by encoding the IP block's main functional clock, reset lines, and
clockdomain.

Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: hwmod data: fix IVA interface clock

The OMAP3 hwmod data listed iva2_ck as an interface clock between the
IVA and L3.  This is incorrect.  iva2_ck is not an interface clock.
Since it cannot auto-idle, specifying it here prevents the IVA and at
least one of the CORE clockdomains from going idle, which causes PM
problems such as these upon system suspend:

[   70.626129] Powerdomain (iva2_pwrdm) didn't enter target state 1
[   70.626190] Powerdomain (core_pwrdm) didn't enter target state 1

Fix by specifying the actual interface clock in the hwmod data.

Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2xxx: hwmod data: share common interface data

Several struct omap_hwmod_ocp_if records can be shared between OMAP2420
and OMAP2430.  Move these shared records out of the chip-specific files
into mach-omap2/omap_hwmod_2xxx_interconnect_data.c.  This should save some
memory and source lines, at the cost of readability.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2xxx: hwmod data: share common hwmods between OMAP2420 and OMAP2430

After the link registration conversion, it's much easier to share some
hwmod data between OMAP2420 and 2430.  Move the shareable data into a
common file.  This should save some memory and lines of source, at the
cost of readability.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: hwmod data: remove forward declarations, reorganize

Reorganize the hwmod data to declare the IP blocks first and the
interconnects second.  This allows us to remove the forward
declarations, which this patch also does. Saves some lines of source
data.  While here, take the opportunity to synchronize the order of
the OMAP44xx hwmod data with the autogenerator output -- it's slightly
different due to past mismerges -- and fix a few minor typos and
whitespace problems in the files.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP: hwmod: remove code support for direct hwmod registration

Now that the data has been converted to use interface registration, we
can remove the (now unused) direct hwmod registration code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: hwmod data: convert to link registration

Register interconnect links between IP blocks, rather than the IP
blocks themselves.  (The IP blocks will be registered as a side-effect
of registering the links.)

The objective is to reduce the number of lines of static data and
facilitate the sharing of IP block data between different SoCs.  These
objectives come at the penalty of increased boot time due to increased
computation.

While here, fix a few whitespace problems and inaccurate variable names.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: hwmod: add support for link registration

Add support for direct IP block interconnect ("link") registration to
the hwmod code via a new function, omap_hwmod_register_links().  This
will replace direct registration of hwmods, and a subsequent patch
will remove omap_hwmod_register().

This change will allow a subsequent patch to remove the hwmod data
link arrays.  This will reduce the size of the hwmod static data and
also make it easier to generate the data files.  It will also make it
possible to share some of the struct omap_hwmod records across
multiple SoCs, since the link array pointers will be removed from the
struct omap_hwmod.

The downside is that boot time will increase.  Minimizing boot time
was the reason why the link arrays were originally introduced.
Removing them will require extra computation during boot to allocate
memory and associate IP blocks with their interconnects.  However,
since the current kernel development focus is on reducing the number
of lines in arch/arm/mach-omap2/, boot time impact is now seemingly
considered a lower priority.

This patch contains additional complexity to reduce the number of
memory allocations required for this change.  This reduces the boot
time impact: total hwmod link registration time was ~ 2655
microseconds with a simple allocation strategy, but is now ~ 549
microseconds[1] with the approach taken by this patch.

1. Measured on a BeagleBoard 35xx @ 500MHz MPU/333 MHz CORE, average
   of 7 samples.  Total uncertainty is +/- 61 microseconds.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: hwmod: consolidate finding the MPU port index and storing it

An IP block's MPU interface port only needs to be found once.  The result
can be cached to speed further lookups.  This patch consolidates these
two steps into a single function.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: hwmod: add function to iterate over struct omap_hwmod_ocp_if

To reduce the number of lines of data in the OMAP portion of the Linux
code base, subsequent patches will remove the lists of hwmod
interconnect links from the static hwmod data.  These lists will be
built dynamically during boot.  To ease this transition, this patch
centralizes the way that interconnect links are iterated into a single
function, _fetch_next_ocp_if().

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: hwmod: add _find_mpu_rt_port()

Most IP blocks on the OMAP SoC have an interconnect link that is
intended to be used by the MPU to communicate with the IP block.
Several parts of the hwmod code need to be able to identify this link.
Currently, this is open-coded.  However, future patches will change
the way that interconnect links are represented and will make
identifying the link more complex.  So to avoid code duplication, this
patch centralizes the MPU port link identification code into a new
function, _find_mpu_rt_port().

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: hwmod: extend OCP_* register offsets from 16 to 32 bits

Extend the OCP_* register offsets in the struct
omap_hwmod_class_sysconfig to 32 bits.  This is required to add the
OMAP4+ GPU hwmod, which uses OCP_* register offsets larger than 16
bits.

Another possible solution may be to simply add a single 16 bit offset
field in this structure, and to add code to factor that offset into
all OCP_* register accesses.  This would save some memory, since
almost no modules need 32 bit offsets.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP4: hwmod data: uncomment some "excluded" hwmods

Some hwmods were commented out from the OMAP4 data, under the theory
that they shouldn't be added until drivers were ready.  But part of
the utility of the hwmod code is that it can reset and properly
initialize IP blocks that have no drivers associated with them.
Rather than commenting the links in the future hwmod data conversion
patches, discussing this with Benoit, it seems best to simply
uncomment them now.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP4: hwmod data: add OCP_USER_DSP; mark omap44xx_dsp__iva appropriately

One of the OMAP4 links was missing OCP_USER flags, since it was only
used by the DSP initiator, and we did not have an OCP_USER_DSP flag.
Future patches will switch the hwmod code and data to register
interfaces, rather than hwmods, and it will be mandatory for all
interfaces to have at least one user bit set.  This patch resolves the
issue by adding OCP_USER_DSP and marking the DSP-IVA interface
appropriately.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP4: hwmod data: remove bandgap hwmod

Commit 407a6888f7362cb3dabe69ea6d9dcf3c750dc56a ("OMAP4: hwmod data:
Add AESS, McPDM, bandgap, counter_32k, MMC, KBD, ISS & IPU") adds a
hwmod for the bandgap die temperature sensor IP block.  This IP block
has no interconnect port or firewall region, nor does it have an
independent register space or OCP control registers.  Its registers
are embedded in the System Control Module (SCM) IP block.  So it
appears that the bandgap device should be created by the SCM driver.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP3: hwmod data: GPTIMER12 is attached to a separate interconnect

GPTIMER12 is attached to the L4 SEC interconnect, not directly to L4 WKUP.
Add the L4 SEC interconnect and attach GPTIMER12 to it.

Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: hwmod data: add DSS->L3 interconnect for 3430ES1

The OMAP3 hwmod data was missing a DSS->L3 interconnect link for the
OMAP3430 ES1 DSS hwmod.  Since the hwmod code and data is being modified
to register interfaces rather than hwmods, this would result in the DSS hwmod
not being registered correctly on OMAP3430ES1.

Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP3: hwmod data: fix interfaces for the MMC hwmods

Commit a52e2ab66d4a9305e1ba64d9b9d25754b6c70895 ("ARM: OMAP3: hwmod
data: disable multiblock reads on MMC1/2 on OMAP34xx/35xx <= ES2.1")
didn't link the MMC hwmods to the interconnects correctly.  Future
patches will register hwmods by interface, so if this is not fixed,
the MMC IP blocks won't be registered.  Update the interface data
records to point to the correct IP blocks.

Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2/3: hwmod data: update old names

Some of the 2xxx and 3xxx hwmod data files use the old naming style
for hwmods, ending in a "_hwmod".  These names are used by the OMAP
integration code to map hwmods to platform_devices, so they need to be
consistent, or the platform_devices won't be created.  Remove the
_hwmod suffix to conform with the rest of the OMAP SoC data.

Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: timer: use a proper interface to get hwmod data

arch/arm/mach-omap2/timer.c pokes around inside the hwmod data
structures.  Since the hwmod data structures are about to change, this
code will break.  This patch modifies the timer code to use
recently-added hwmod functions instead.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: hwmod: add omap_hwmod_get_resource_byname()

The timer integration code pokes around in hwmod data structures.
Those data structures are about to change.  Define a function,
omap_hwmod_get_resource_byname(), for the timer integration code to
use instead.

The original patch has been changed to use struct resource by Tony's
request, although the caller of this function should not be a driver._
Platform drivers should get their data through the regular platform_*
functions; DT drivers through the appropriate of_* functions.  This a
function is only for use by OMAP core code in arch/arm/*omap*.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Tony Lindgren <tony@atomide.com>

ARM: OMAP2+: hwmod: provide a function to return the address space of the MPU RT

A subsequent patch will need to know the struct omap_hwmod_addr_space
record corresponding to the module's register target, used by the MPU.
So, convert _find_mpu_rt_base() into _find_mpu_rt_addr_space().  Then
modify its sole current user, _populate_mpu_rt_base(), to extract the
MPU RT base address itself from the struct omap_hwmod_addr_space record.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: hwmod: revise hardreset behavior

Change the way that hardreset lines are handled by the hwmod code.
Hardreset lines are generally associated with initiator IP blocks.
Prior to this change, the hwmod code expected to control hardreset
lines itself, asserting them on shutdown and deasserting them upon
enable.  But driver authors inside TI have commented to us that their
drivers require direct control over these lines.  Unfortunately, these
drivers haven't been posted publicly yet, so it's hard to determine
exactly what is needed, a priori.  This change attempts to set forth
some reasonable semantics that should be an improvement over the
current code.

The semantics implemented by this patch are as follows:

- If the hwmod is not marked with HWMOD_INIT_NO_RESET, then assert all
  associated hardreset lines during IP block setup.  This is intended
  to place the IP blocks into a known state that will not interfere
  with other devices during kernel boot.

- IP blocks with hardreset lines will not be automatically enabled or
  idled during setup.  Instead, they will be left in the INITIALIZED
  state.

- When the hwmod code is asked to enable, idle, or shutdown an IP
  block with asserted hardreset lines, the hwmod code will do nothing.
  The driver integration code must do the remaining work needed to
  control these IP blocks.  Once this driver integration code is posted
  to the lists, hopefully we can consolidate it and move it inside the
  hwmod code.

Custom reset functions for IP blocks with hardreset lines still should
be supported and are strongly endorsed.  It is intended that every
subsystem with hardreset lines should have a custom reset function
that can place their subsystem into quiescent idle with the hardreset
lines deasserted.

This reverts most of commit 5365efbe29250a227502256cc912351fe2157b42
("OMAP: hwmod: Add hardreset management support").  Later code
reorganizations caused the sequencing of the code from this patch to
be changed, anyway.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: hwmod: reorganize and document the reset and configuration process

Reorganize the code involved in resetting and configuring an IP block
to make it easier to read and maintain.  This involves improving
documentation, splitting some large functions up into smaller ones to
better conform with Documentation/CodingStyle, and removing some
unnecessary code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: hwmod: reorganize and document the initialization process

Reorganize the code involved in initializing the internal data for
each hwmod to make it easier to read and maintain.  This involves
improving documentation and removing some duplicated and unnecessary
code.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: hwmod: revise the IP block reset process

Revise the IP block reset process.  This patch ensures that the
OCP_SYSCONFIG registers are reloaded after a custom reset.  Since
OCP_SYSCONFIG bits are cleared during reset, they should be
reprogrammed unless the IP block is being left in reset.  (The only IP
blocks that are left in reset are IP blocks with hardreset lines and
no custom reset function.)  If the IP block is left in reset, then it
is inaccessible to the MPU, and an access to the OCP_SYSCONFIG
register will cause an abort.

This version incorporates comments from Omar Ramirez Luna
<omar.ramirez@ti.com> to skip the OCP_SYSCONFIG access after asserting
hardreset lines.  This allows the MMU (IOMMU) IP block, which has
both hardreset lines and an OCP_SYSCONFIG register.

Also, ignore _ocp_softreset() errors if the IP block doesn't include a
softreset bit.  This is needed since a subsequent patch will start
taking the return value of the _reset() function seriously.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>
Cc: Omar Ramirez Luna <omar.ramirez@ti.com>

ARM: OMAP4: hwmod data: remove pseudo-hwmods associated with hardreset lines

Remove the pseudo-hwmods associated with hardreset lines from the
OMAP4 data file.  Future patches will convert this data to register
hwmods by interfaces, rather than registering hwmods directly.  The
pseudo-hwmods aren't associated with any interfaces, so this will
create a problem.

After this change, the hwmod code will reset processor IPs at the
hwmod level, rather than by individual hardreset lines.  So, for
example, if the IVA device driver code wishes to place one of the
sequencer cores into reset, while leaving the other active, it must do
so itself by calling the appropriate PRM functions.

This patch will cause a change in the initialization behavior of the
DSP, IVA, and IPU.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2+: hwmod: control all hardreset lines attached to a hwmod

Parts of the hwmod code test to see if a module has one and only one
hardreset line before taking an action.  It seems more appropriate
to control all hardreset lines associated with a hwmod, not just one.

It so happens that with the current hwmod data, this patch will not
change any behavior, since hwmods with hardreset lines have only one
hardreset line associated with them, and 'pseudo-hwmods' are used to
handle the other hardreset lines.  But future hwmod data patches to
remove the pseudo-hwmods will change this.

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Benoît Cousson <b-cousson@ti.com>

ARM: OMAP2/3: VENC hwmods: Remove OCPIF_SWSUP_IDLE flag from VENC slave interface

The clocks for all DSS slave interfaces were recently changed to "dss_ick" on
OMAP2 and OMAP3, this clock can be autoidled by PRCM. The VENC interface
previously had "dss_54m_fck" as it's clock which couldn't be autoidled, and
hence the OCPIF_SWSUP_IDLE flag was needed.

Remove the OCPIF_SWSUP_IDLE flag from VENC interfaces as it's clock is
now "dss_ick".  This allows the PRCM hardware to autoidle the VENC
interface clocks when they are not active, rather than relying on the
software to do it, which can keep the interface clocks active
unnecessarily.

Signed-off-by: Archit Taneja <archit@ti.com>
[paul@pwsan.com: add a short description of the fix to the commit log]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: hwmod: Revert "ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status"

This reverts commit f9a2f9c3fa76eec55928e8e06f3094c8f01df7cb.  This
commit caused a regression in the I2C hwmod reset on OMAP2/3/4,
logging messages similar to these during boot:

[    0.200378] omap_hwmod: i2c1: softreset failed (waited 10000 usec)
[    0.222076] omap_hwmod: i2c2: softreset failed (waited 10000 usec)

While the original patch was intended to fix some reset-related timing
issues, it's believed that these problems were actually fixed by
commit 2800852a079504f35f88e44faf5c9c96318c0cca ("ARM: OMAP2+: hwmod:
Restore sysc after a reset"):

    http://marc.info/?l=linux-arm-kernel&m=133410322617245&w=2

Cc: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Paul Walmsley <paul@pwsan.com>

ARM: OMAP2+: hwmod: add softreset delay field and OMAP4 data

Due to HW limitation, some IPs should not be accessed just after a
softreset. Since the current hwmod sequence is accessing the sysconfig
register just after the reset, it might lead to OCP bus error in
that case.

Add a new field in the sysconfig structure to specify a delay in usecs
needed after doing a softreset.

In the case of the ISS and FDIF modules, the L3 OCP port will be
disconnected upon a SW reset. That issue was confirmed with HW simulation
and an errata should be available soon. The HW recommendation to avoid
that is to wait for 100 OCP clk cycles, before accessing the IP.

Considering the worse case (OPP50), the L3 bus will run at 100 MHz,
so a 1 usec delay is needed. Add an x2 margin to be safe.

Acked-by: Benoit Cousson <b-cousson@ti.com>
Signed-off-by: Fernando Guzman Lugo <fernando.lugo@ti.com>
[paul@pwsan.com: dropped FDIF change for now since the hwmod data is not
 yet upstream; the FDIF change will need to be added later once the FDIF
 data is merged]
Signed-off-by: Paul Walmsley <paul@pwsan.com>

Linux 3.4-rc2

Merge tag 'regmap-3.4-fixes' of git://git./linux/kernel/git/broonie/regmap

Pull two more small regmap fixes from Mark Brown:
 - Now we have users for it that aren't running Android it turns out
   that regcache_sync_region() is much more useful to drivers if it's
   exported for use by modules.  Who knew?
 - Make sure we don't divide by zero when doing debugfs dumps of
   rbtrees, not visible up until now because everything was providing at
   least some cache on startup.

* tag 'regmap-3.4-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: prevent division by zero in rbtree_show
  regmap: Export regcache_sync_region()

Merge branch 'kvm-updates/3.4' of git://git./virt/kvm/kvm

Pull a few KVM fixes from Avi Kivity:
 "A bunch of powerpc KVM fixes, a guest and a host RCU fix (unrelated),
  and a small build fix."

* 'kvm-updates/3.4' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: Resolve RCU vs. async page fault problem
  KVM: VMX: vmx_set_cr0 expects kvm->srcu locked
  KVM: PMU: Fix integer constant is too large warning in kvm_pmu_set_msr()
  KVM: PPC: Book3S: PR: Fix preemption
  KVM: PPC: Save/Restore CR over vcpu_run
  KVM: PPC: Book3S HV: Save and restore CR in __kvmppc_vcore_entry
  KVM: PPC: Book3S HV: Fix kvm_alloc_linear in case where no linears exist
  KVM: PPC: Book3S: Compile fix for ppc32 in HIOR access code

Merge tag 'sh-for-linus' of git://github.com/pmundt/linux-sh

Pull SuperH fixes from Paul Mundt.

* tag 'sh-for-linus' of git://github.com/pmundt/linux-sh:
  sh: fix clock-sh7757 for the latest sh_mobile_sdhi driver
  serial: sh-sci: use serial_port_in/out vs sci_in/out.
  sh: vsyscall: Fix up .eh_frame generation.
  sh: dma: Fix up device attribute mismatch from sysdev fallout.
  sh: dwarf unwinder depends on SHcompact.
  sh: fix up fallout from system.h disintegration.

Merge branch 'for-linus' of git://git./linux/kernel/git/jmorris/linux-security

Pull security layer fixlet from James Morris.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
  sysctl: fix write access to dmesg_restrict/kptr_restrict

Merge branch 'release' of git://git./linux/kernel/git/lenb/linux

Pull ACPI & Power Management patches from Len Brown:
 "Two fixes for cpuidle merge-window changes, plus a URL fix in
  MAINTAINERS"

* 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux:
  MAINTAINERS: Update git url for ACPI
  cpuidle: Fix panic in CPU off-lining with no idle driver
  ACPI processor: Use safe_halt() rather than halt() in acpi_idle_play_dead()

Merge branch '3.4-rc-fixes' of git://git./linux/kernel/git/nab/target-pending

Pull target fixes from Nicholas Bellinger:
 "Pull two tcm_fc fabric related fixes for -rc2:

  Note that both have been CC'ed to stable, and patch #1 is the
  important one that addresses a memory corruption bug related to FC
  exchange timeouts + command abort.

  Thanks again to MDR for tracking down this issue!"

* '3.4-rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  tcm_fc: Do not free tpg structure during wq allocation failure
  tcm_fc: Add abort flag for gracefully handling exchange timeout

tcm_fc: Do not free tpg structure during wq allocation failure

Avoid freeing a registered tpg structure if an alloc_workqueue call
fails.  This fixes a bug where the failure was leaking memory associated
with se_portal_group setup during the original core_tpg_register() call.

Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Acked-by: Kiran Patil <Kiran.patil@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

tcm_fc: Add abort flag for gracefully handling exchange timeout

Add abort flag and use it to terminate processing when an exchange
is timed out or is reset. The abort flag is used in place of the
transport_generic_free_cmd function call in the reset and timeout
cases, because calling that function in that context would free
memory that was in use. The aborted flag allows the lifetime to
be managed in a more normal way, while truncating the processing.

This change eliminates a source of memory corruption which
manifested in a variety of ugly ways.

(nab: Drop unused struct fc_exch *ep in ft_recv_seq)

Signed-off-by: Mark Rustad <mark.d.rustad@intel.com>
Acked-by: Kiran Patil <Kiran.patil@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>

Merge branches 'idle-fix' and 'misc' into release

MAINTAINERS: Update git url for ACPI

Signed-off-by: Igor Murzov <e-mail@date.by>
Signed-off-by: Len Brown <len.brown@intel.com>

Merge branch 'stable' of git://git./linux/kernel/git/cmetcalf/linux-tile

Pull arch/tile bug fixes from Chris Metcalf:
 "This includes Paul Gortmaker's change to fix the <asm/system.h>
  disintegration issues on tile, a fix to unbreak the tilepro ethernet
  driver, and a backlog of bugfix-only changes from internal Tilera
  development over the last few months.

  They have all been to LKML and on linux-next for the last few days.
  The EDAC change to MAINTAINERS is an oddity but discussion on the
  linux-edac list suggested I ask you to pull that change through my
  tree since they don't have a tree to pull edac changes from at the
  moment."

* 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile: (39 commits)
  drivers/net/ethernet/tile: fix netdev_alloc_skb() bombing
  MAINTAINERS: update EDAC information
  tilepro ethernet driver: fix a few minor issues
  tile-srom.c driver: minor code cleanup
  edac: say "TILEGx" not "TILEPro" for the tilegx edac driver
  arch/tile: avoid accidentally unmasking NMI-type interrupt accidentally
  arch/tile: remove bogus performance optimization
  arch/tile: return SIGBUS for addresses that are unaligned AND invalid
  arch/tile: fix finv_buffer_remote() for tilegx
  arch/tile: use atomic exchange in arch_write_unlock()
  arch/tile: stop mentioning the "kvm" subdirectory
  arch/tile: export the page_home() function.
  arch/tile: fix pointer cast in cacheflush.c
  arch/tile: fix single-stepping over swint1 instructions on tilegx
  arch/tile: implement panic_smp_self_stop()
  arch/tile: add "nop" after "nap" to help GX idle power draw
  arch/tile: use proper memparse() for "maxmem" options
  arch/tile: fix up locking in pgtable.c slightly
  arch/tile: don't leak kernel memory when we unload modules
  arch/tile: fix bug in delay_backoff()
  ...

Merge tag 'stable/for-linus-3.4-rc1-tag' of git://git./linux/kernel/git/konrad/xen

Pull xen fixes from Konrad Rzeszutek Wilk:
 "Two fixes for regressions:
   * one is a workaround that will be removed in v3.5 with proper fix in
     the tip/x86 tree,
   * the other is to fix drivers to load on PV (a previous patch made
     them only load in PVonHVM mode).

  The rest are just minor fixes in the various drivers and some cleanup
  in the core code."

* tag 'stable/for-linus-3.4-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  xen/pcifront: avoid pci_frontend_enable_msix() falsely returning success
  xen/pciback: fix XEN_PCI_OP_enable_msix result
  xen/smp: Remove unnecessary call to smp_processor_id()
  xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries'
  xen: only check xen_platform_pci_unplug if hvm

Merge tag 'mmc-fixes-for-3.4-rc2' of git://git./linux/kernel/git/cjb/mmc

Pull MMC fixes from Chris Ball:
 - Disable use of MSI in sdhci-pci, which caused multiple chipsets to
   stop working in 3.4-rc1.  I'll wait to turn this on again until we
   have a chipset whitelist for it.
 - Fix a libertas SDIO powered-resume regression introduced in 3.3;
   thanks to Neil Brown and Rafael Wysocki for this fix.
 - Fix module reloading on omap_hsmmc.
 - Stop trusting the spec/card's specified maximum data timeout length,
   and use three seconds instead.  Previously we used 300ms.

Also cleanups and fixes for s3c, atmel, sh_mmcif and omap_hsmmc.

* tag 'mmc-fixes-for-3.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc: (28 commits)
  mmc: use really long write timeout to deal with crappy cards
  mmc: sdhci-dove: Fix compile error by including module.h
  mmc: Prevent 1.8V switch for SD hosts that don't support UHS modes.
  Revert "mmc: sdhci-pci: Add MSI support"
  Revert "mmc: sdhci-pci: add quirks for broken MSI on O2Micro controllers"
  mmc: core: fix power class selection
  mmc: omap_hsmmc: fix module re-insertion
  mmc: omap_hsmmc: convert to module_platform_driver
  mmc: omap_hsmmc: make it behave well as a module
  mmc: omap_hsmmc: trivial cleanups
  mmc: omap_hsmmc: context save after enabling runtime pm
  mmc: omap_hsmmc: use runtime put sync in probe error patch
  mmc: sdio: Use empty system suspend/resume callbacks at the bus level
  mmc: bus: print bus speed mode of UHS-I card
  mmc: sdhci-pci: add quirks for broken MSI on O2Micro controllers
  mmc: sh_mmcif: Simplify calculation of mmc->f_min
  mmc: sh_mmcif: mmc->f_max should be half of the bus clock
  mmc: sh_mmcif: double clock speed
  mmc: block: Remove use of mmc_blk_set_blksize
  mmc: atmel-mci: add support for odd clock dividers
  ...

Make the "word-at-a-time" helper functions more commonly usable

I have a new optimized x86 "strncpy_from_user()" that will use these
same helper functions for all the same reasons the name lookup code uses
them.  This is preparation for that.

This moves them into an architecture-specific header file.  It's
architecture-specific for two reasons:

 - some of the functions are likely to want architecture-specific
   implementations.  Even if the current code happens to be "generic" in
   the sense that it should work on any little-endian machine, it's
   likely that the "multiply by a big constant and shift" implementation
   is less than optimal for an architecture that has a guaranteed fast
   bit count instruction, for example.

 - I expect that if architectures like sparc want to start playing
   around with this, we'll need to abstract out a few more details (in
   particular the actual unaligned accesses).  So we're likely to have
   more architecture-specific stuff if non-x86 architectures start using
   this.

   (and if it turns out that non-x86 architectures don't start using
   this, then having it in an architecture-specific header is still the
   right thing to do, of course)

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

cpuidle: Fix panic in CPU off-lining with no idle driver

Fix a NULL pointer dereference panic in cpuidle_play_dead() during
CPU off-lining when no cpuidle driver is registered.  A cpuidle
driver may be registered at boot-time based on CPU type.  This patch
allows an off-lined CPU to enter HLT-based idle in this condition.

Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Cc: Boris Ostrovsky <boris.ostrovsky@amd.com>
Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Tested-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Len Brown <len.brown@intel.com>

Merge git://git./linux/kernel/git/davem/net

Pull networking updates from David Miller:

 1) Fix inaccuracies in network driver interface documentation, from Ben
    Hutchings.

 2) Fix handling of negative offsets in BPF JITs, from Jan Seiffert.

 3) Compile warning, locking, and refcounting fixes in netfilter's
    xt_CT, from Pablo Neira Ayuso.

 4) phonet sendmsg needs to validate user length just like any other
    datagram protocol, fix from Sasha Levin.

 5) Ipv6 multicast code uses wrong loop index, from RongQing Li.

 6) Link handling and firmware fixes in bnx2x driver from Yaniv Rosner
    and Yuval Mintz.

 7) mlx4 erroneously allocates 4 pages at a time, regardless of page
    size, fix from Thadeu Lima de Souza Cascardo.

 8) SCTP socket option wasn't extended in a backwards compatible way,
    fix from Thomas Graf.

 9) Add missing address change event emissions to bonding, from Shlomo
    Pongratz.

10) /proc/net/dev regressed because it uses a private offset to track
    where we are in the hash table, but this doesn't track the offset
    pullback that the seq_file code does resulting in some entries being
    missed in large dumps.

    Fix from Eric Dumazet.

11) do_tcp_sendpage() unloads the send queue way too fast, because it
    invokes tcp_push() when it shouldn't.  Let the natural sequence
    generated by the splice paths, and the assosciated MSG_MORE
    settings, guide the tcp_push() calls.

    Otherwise what goes out of TCP is spaghetti and doesn't batch
    effectively into GSO/TSO clusters.

    From Eric Dumazet.

12) Once we put a SKB into either the netlink receiver's queue or a
    socket error queue, it can be consumed and freed up, therefore we
    cannot touch it after queueing it like that.

    Fixes from Eric Dumazet.

13) PPP has this annoying behavior in that for every transmit call it
    immediately stops the TX queue, then calls down into the next layer
    to transmit the PPP frame.

    But if that next layer can take it immediately, it just un-stops the
    TX queue right before returning from the transmit method.

    Besides being useless work, it makes several facilities unusable, in
    particular things like the equalizers.  Well behaved devices should
    only stop the TX queue when they really are full, and in PPP's case
    when it gets backlogged to the downstream device.

    David Woodhouse therefore fixed PPP to not stop the TX queue until
    it's downstream can't take data any more.

14) IFF_UNICAST_FLT got accidently lost in some recent stmmac driver
    changes, re-add.  From Marc Kleine-Budde.

15) Fix link flaps in ixgbe, from Eric W. Multanen.

16) Descriptor writeback fixes in e1000e from Matthew Vick.

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (47 commits)
  net: fix a race in sock_queue_err_skb()
  netlink: fix races after skb queueing
  doc, net: Update ndo_start_xmit return type and values
  doc, net: Remove instruction to set net_device::trans_start
  doc, net: Update netdev operation names
  doc, net: Update documentation of synchronisation for TX multiqueue
  doc, net: Remove obsolete reference to dev->poll
  ethtool: Remove exception to the requirement of holding RTNL lock
  MAINTAINERS: update for Marvell Ethernet drivers
  bonding: properly unset current_arp_slave on slave link up
  phonet: Check input from user before allocating
  tcp: tcp_sendpages() should call tcp_push() once
  ipv6: fix array index in ip6_mc_add_src()
  mlx4: allocate just enough pages instead of always 4 pages
  stmmac: re-add IFF_UNICAST_FLT for dwmac1000
  bnx2x: Clear MDC/MDIO warning message
  bnx2x: Fix BCM57711+BCM84823 link issue
  bnx2x: Clear BCM84833 LED after fan failure
  bnx2x: Fix BCM84833 PHY FW version presentation
  bnx2x: Fix link issue for BCM8727 boards.
  ...

xen/pcifront: avoid pci_frontend_enable_msix() falsely returning success

The original XenoLinux code has always had things this way, and for
compatibility reasons (in particular with a subsequent pciback
adjustment) upstream Linux should behave the same way (allowing for two
distinct error indications to be returned by the backend).

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

xen/pciback: fix XEN_PCI_OP_enable_msix result

Prior to 2.6.19 and as of 2.6.31, pci_enable_msix() can return a
positive value to indicate the number of vectors (less than the amount
requested) that can be set up for a given device. Returning this as an
operation value (secondary result) is fine, but (primary) operation
results are expected to be negative (error) or zero (success) according
to the protocol. With the frontend fixed to match the XenoLinux
behavior, the backend can now validly return zero (success) here,
passing the upper limit on the number of vectors in op->value.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

xen/smp: Remove unnecessary call to smp_processor_id()

There is an extra and unnecessary call to smp_processor_id()
in cpu_bringup(). Remove it.

Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

xen/x86: Workaround 'x86/ioapic: Add register level checks to detect bogus io-apic entries'

The above mentioned patch checks the IOAPIC and if it contains
-1, then it unmaps said IOAPIC. But under Xen we get this:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000040
IP: [<ffffffff8134e51f>] xen_irq_init+0x1f/0xb0
PGD 0
Oops: 0002 [#1] SMP
CPU 0
Modules linked in:

Pid: 1, comm: swapper/0 Not tainted 3.2.10-3.fc16.x86_64 #1 Dell Inc. Inspiron
1525                  /0U990C
RIP: e030:[<ffffffff8134e51f>]  [<ffffffff8134e51f>] xen_irq_init+0x1f/0xb0
RSP: e02b: ffff8800d42cbb70  EFLAGS: 00010202
RAX: 0000000000000000 RBX: 00000000ffffffef RCX: 0000000000000001
RDX: 0000000000000040 RSI: 00000000ffffffef RDI: 0000000000000001
RBP: ffff8800d42cbb80 R08: ffff8800d6400000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 00000000ffffffef
R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000010
FS:  0000000000000000(0000) GS:ffff8800df5fe000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0:000000008005003b
CR2: 0000000000000040 CR3: 0000000001a05000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process swapper/0 (pid: 1, threadinfo ffff8800d42ca000, task ffff8800d42d0000)
Stack:
 00000000ffffffef 0000000000000010 ffff8800d42cbbe0 ffffffff8134f157
 ffffffff8100a9b2 ffffffff8182ffd1 00000000000000a0 00000000829e7384
 0000000000000002 0000000000000010 00000000ffffffff 0000000000000000
Call Trace:
 [<ffffffff8134f157>] xen_bind_pirq_gsi_to_irq+0x87/0x230
 [<ffffffff8100a9b2>] ? check_events+0x12+0x20
 [<ffffffff814bab42>] xen_register_pirq+0x82/0xe0
 [<ffffffff814bac1a>] xen_register_gsi.part.2+0x4a/0xd0
 [<ffffffff814bacc0>] acpi_register_gsi_xen+0x20/0x30
 [<ffffffff8103036f>] acpi_register_gsi+0xf/0x20
 [<ffffffff8131abdb>] acpi_pci_irq_enable+0x12e/0x202
 [<ffffffff814bc849>] pcibios_enable_device+0x39/0x40
 [<ffffffff812dc7ab>] do_pci_enable_device+0x4b/0x70
 [<ffffffff812dc878>] __pci_enable_device_flags+0xa8/0xf0
 [<ffffffff812dc8d3>] pci_enable_device+0x13/0x20

The reason we are dying is b/c the call acpi_get_override_irq() is used,
which returns the polarity and trigger for the IRQs. That function calls
mp_find_ioapics to get the 'struct ioapic' structure - which along with the
mp_irq[x] is used to figure out the default values and the polarity/trigger
overrides. Since the mp_find_ioapics now returns -1 [b/c the IOAPIC is filled
with 0xffffffff], the acpi_get_override_irq() stops trying to lookup in the
mp_irq[x] the proper INT_SRV_OVR and we can't install the SCI interrupt.

The proper fix for this is going in v3.5 and adds an x86_io_apic_ops
struct so that platforms can override it. But for v3.4 lets carry this
work-around. This patch does that by providing a slightly different variant
of the fake IOAPIC entries.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

xen: only check xen_platform_pci_unplug if hvm

commit b9136d207f08
  xen: initialize platform-pci even if xen_emul_unplug=never

breaks blkfront/netfront by not loading them because of
xen_platform_pci_unplug=0 and it is never set for PV guest.

Signed-off-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Igor Mammedov <imammedo@redhat.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

net: fix a race in sock_queue_err_skb()

As soon as an skb is queued into socket error queue, another thread
can consume it, so we are not allowed to reference skb anymore, or risk
use after free.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

netlink: fix races after skb queueing

As soon as an skb is queued into socket receive_queue, another thread
can consume it, so we are not allowed to reference skb anymore, or risk
use after free.

Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

doc, net: Update ndo_start_xmit return type and values

Commit dc1f8bf68b311b1537cb65893430b6796118498a ('netdev: change
transmit to limited range type') changed the required return type and
9a1654ba0b50402a6bd03c7b0fe9b0200a5ea7b1 ('net: Optimize
hard_start_xmit() return checking') changed the valid numerical
return values.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

doc, net: Remove instruction to set net_device::trans_start

Commit 08baf561083bc27a953aa087dd8a664bb2b88e8e ('net:
txq_trans_update() helper') made it unnecessary for most drivers to
set net_device::trans_start (or netdev_queue::trans_start).

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

doc, net: Update netdev operation names

Commits d314774cf2cd5dfeb39a00d37deee65d4c627927 ('netdev: network
device operations infrastructure') and
008298231abbeb91bc7be9e8b078607b816d1a4a ('netdev: add more functions
to netdevice ops') moved and renamed net device operation pointers.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

doc, net: Update documentation of synchronisation for TX multiqueue

Commits e308a5d806c852f56590ffdd3834d0df0cbed8d7 ('netdev: Add
netdev->addr_list_lock protection.') and
e8a0464cc950972824e2e128028ae3db666ec1ed ('netdev: Allocate multiple
queues for TX.') introduced more fine-grained locks.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

doc, net: Remove obsolete reference to dev->poll

Commit bea3348eef27e6044b6161fd04c3152215f96411 ('[NET]: Make NAPI
polling independent of struct net_device objects.') removed the
automatic disabling of NAPI polling by dev_close(), and drivers
must now do this themselves.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

ethtool: Remove exception to the requirement of holding RTNL lock

Commit e52ac3398c3d772d372b9b62ab408fd5eec96840 ('net: Use device
model to get driver name in skb_gso_segment()') removed the only
in-tree caller of ethtool ops that doesn't hold the RTNL lock.

Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge tag 'fixes-for-linus' of git://git./linux/kernel/git/arm/arm-soc

Pull "ARM: SoC fixes: from Olof Johansson:
 "A bunch of fixes for regressions (and a few other problems) in
  3.4-rc1:

 - Fix for regression of mach/io.h cleanup on platforms with PCI or
   PCMCIA (adding back the include file on those for now)
 - AT91 fixes for usb and spi
 - smsc911x ethernet fixes for i.MX
 - smsc911x fixes for OMAP
 - gpio fixes for Tegra
 - A handful of build error and warning fixes for various platforms
 - cpufreq kconfig dependencies, build and lowlevel debug fixes for
   Samsung platforms

  In other words, more or less the regular collection of -rc1/2 type
  material.  A few of them, in particular the smsc911x for OMAP series,
  aren't technically regressions for 3.4, but they're valid fixes and
  we're still relatively early in the rc cycle so it seems appropriate
  to include them."

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (60 commits)
  ARM: fix __io macro for PCMCIA
  ARM: EXYNOS: Fix compiler warning in dma.c file
  ARM: EXYNOS: fix ISO C90 warning
  ARM: OMAP2+: hwmod: Fix wrong SYSC_TYPE1_XXX_MASK bit definitions
  ARM: OMAP2+: hwmod: Make omap_hwmod_softreset wait for reset status
  ARM: OMAP2+: hwmod: Restore sysc after a reset
  ARM: OMAP2+: omap_hwmod: Allow io_ring wakeup configuration for all modules
  ARM: OMAP3: clock data: fill in some missing clockdomains
  ARM: OMAP4: clock data: Force a DPLL clkdm/pwrdm ON before a relock
  ARM: OMAP4: clock data: fix mult and div mask for USB_DPLL
  ARM: OMAP2+: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()
  gpio: tegra: Iterate over the correct number of banks
  gpio: tegra: fix register address calculations for Tegra30
  EXYNOS: fix dependency for EXYNOS_CPUFREQ
  ARM: at91: dt: remove unit-address part for memory nodes
  ARM: at91: fix check of valid GPIO for SPI and USB
  USB: ehci-atmel: add needed of.h header file
  ARM: at91/NAND DT bindings: add comments
  ARM: at91/at91sam9x5.dtsi: fix NAND ale/cle in DT file
  USB: ohci-at91: trivial return code name change
  ...

Merge branch 'for-linus' of git://git./linux/kernel/git/lliubbo/blackfin

Pull a few blackfin compile fixes from Bob Liu.

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/lliubbo/blackfin:
  blackfin: update defconfig for bf527-ezkit
  blackfin: gpio: fix compile error if !CONFIG_GPIOLIB
  blackfin: fix L1 data A overflow link issue

blackfin: update defconfig for bf527-ezkit

To fix compile error:
drivers/usb/musb/blackfin.h:51:3: error: #error "Please use PIO mode in MUSB
driver on bf52x chip v0.0 and v0.1"
make[4]: *** [drivers/usb/musb/blackfin.o] Error 1

Signed-off-by: Bob Liu <lliubbo@gmail.com>

blackfin: gpio: fix compile error if !CONFIG_GPIOLIB

Add __gpio_get_value()/__gpio_set_value() to fix compile error if
CONFIG_GPIOLIB = n.

Signed-off-by: Bob Liu <lliubbo@gmail.com>

blackfin: fix L1 data A overflow link issue

This patch fix below compile error:
"bfin-uclinux-ld: L1 data A overflow!"

It is due to the recent lib/gen_crc32table.c change:
46c5801eaf86e83cb3a4142ad35188db5011fff0
crc32: bolt on crc32c

it added 8KiB more data to __cacheline_aligned which cause blackfin L1 data
cache overflow.

Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: Bob Liu <lliubbo@gmail.com>

Merge branch 'for-linus' of git://git./linux/kernel/git/jikos/apm

Pull an APM fix from Jiri Kosina:
 "One deadlock/race fix from Niel that got introduced when we were
  moving away from freezer_*_count() to wait_event_freezable()."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/apm:
  APM: fix deadlock in APM_IOC_SUSPEND ioctl

mmc: use really long write timeout to deal with crappy cards

Several people have noticed that crappy SD cards take much longer to
complete multiple block writes than the 300ms that Linux specifies.
Try to work around this by using a three second write timeout instead.

This is a generalized version of a patch from Chase Maupin
<Chase.Maupin@ti.com>, whose patch description said:

* With certain SD cards timeouts like the following have been seen
  due to an improper calculation of the dto value:
    mmcblk0: error -110 transferring data, sector 4126233, nr 8,
    card status 0xc00
* By removing the dto calculation and setting the timeout value
  to the maximum specified by the SD card specification part A2
  section 2.2.15 these timeouts can be avoided.
* This change has been used by beagleboard users as well as the
  Texas Instruments SDK without a negative impact.
* There are multiple discussion threads about this but the most
  relevant ones are:
    * http://talk.maemo.org/showthread.php?p=1000707#post1000707
    * http://www.mail-archive.com/linux-omap@vger.kernel.org/msg42213.html
* Original proposal for this fix was done by Sukumar Ghoral of
  Texas Instruments
* Tested using a Texas Instruments AM335x EVM

Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sdhci-dove: Fix compile error by including module.h

This patch fixes a compile error in drivers/mmc/host/sdhci-dove.c
by including the linux/module.h file.

Signed-off-by: Alf Høgemark <alf@i100.no>
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: Prevent 1.8V switch for SD hosts that don't support UHS modes.

The driver should not try to switch to 1.8V when the SD 3.0 host
controller does not have any UHS capabilities bits set (SDR50, DDR50
or SDR104). See page 72 of "SD Specifications Part A2 SD Host
Controller Simplified Specification Version 3.00" under
"1.8V Signaling Enable". Instead of setting SDR12 and SDR25 in the host
capabilities data structure for all V3.0 host controllers, only set them
if SDR104, SDR50 or DDR50 is set in the host capabilities register. This
will prevent the switch to 1.8V later.

Signed-off-by: Al Cooper <acooper@gmail.com>
Acked-by: Arindam Nath <arindam.nath@amd.com>
Acked-by: Philip Rakity <prakity@marvell.com>
Acked-by: Girish K S <girish.shivananjappa@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

Revert "mmc: sdhci-pci: Add MSI support"

This reverts commit e6039832bed9a9b967796d7021f17f25b625b616.
There are reports of MSI breaking SDHCI on multiple chipsets (JMicron
and O2Micro, at least), so this should be reverted until we come up
with a whitelist or something.

Signed-off-by: Chris Ball <cjb@laptop.org>

Revert "mmc: sdhci-pci: add quirks for broken MSI on O2Micro controllers"

This reverts commit c16e981b2fd9455af670a69a84f4c8cf07e12658, because
it's no longer useful once MSI support is reverted.

Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: core: fix power class selection

mmc_select_powerclass() function returns error if eMMC
VDD level supported by host is between 2.7v to 3.2v.

According to eMMC specification, valid voltage for high
voltage cards is 2.7v to 3.6v. This patch ensures that
2.7v to 3.6v VDD range is treated as valid range.

Also, failure to set the power class shouldn't be treated
as fatal error because even if setting the power class
fails, card can still work in default power class.
If mmc_select_powerclass() returns error, just print
the warning message and go ahead with rest of the card
initialization.

Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Acked-by: Girish K S <girish.shivananjappa@linaro.org>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: omap_hsmmc: fix module re-insertion

OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
Adding the offset to platform_device resource structure
increments the start address for every insmod operation.
MMC command fails on re-insertion as module due to incorrect register
base.  Fix this by updating the ioremap base address only.

Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: omap_hsmmc: convert to module_platform_driver

This will delete some boilerplate code, no functional changes.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: omap_hsmmc: make it behave well as a module

If we put probe() on __init section, that will never work for multiple
module insertions/removals.

In order to make it work properly, move probe to __devinit section and
use platform_driver_register() instead of platform_driver_probe().

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: omap_hsmmc: trivial cleanups

A bunch of non-functional cleanups to the omap_hsmmc driver.

It basically decreases indentation level, drop unneded dereferences
and drop unneded accesses to the platform_device structure.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: omap_hsmmc: context save after enabling runtime pm

Call context save api after enabling runtime pm to make sure that
register access in context save api happens with clk enabled.

Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: omap_hsmmc: use runtime put sync in probe error patch

pm_runtime_put_sync instead of autosuspend pm runtime API
because iounmap(host->base) follows immediately.

Reported-by: Rajendra Nayak <rnayak@ti.com>
Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sdio: Use empty system suspend/resume callbacks at the bus level

Neil Brown reports that commit 35cd133c

   PM: Run the driver callback directly if the subsystem one is not there

breaks suspend for his libertas wifi, because SDIO has a protocol
where the suspend method can return -ENOSYS and this means "There is
no point in suspending, just turn me off".  Moreover, the suspend
methods provided by SDIO drivers are not supposed to be called by
the PM core or bus-level suspend routines (which aren't presend for
SDIO).  Instead, when the SDIO core gets to suspend the device's
ancestor, it calls the device driver's suspend function, catches the
ENOSYS, and turns the device off.

The commit above breaks the SDIO core's assumption that the device
drivers' callbacks won't be executed if it doesn't provide any
bus-level callbacks.  If fact, however, this assumption has never
been really satisfied, because device class or device type suspend
might very well use the driver's callback even without that commit.

The simplest way to address this problem is to make the SDIO core
tell the PM core to ignore driver callbacks, for example by providing
no-operation suspend/resume callbacks at the bus level for it,
which is implemented by this change.

Reported-and-tested-by: Neil Brown <neilb@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
[stable: please apply to 3.3-stable only]
Cc: <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: bus: print bus speed mode of UHS-I card

When UHS-I card is detected also print the bus speed mode in which
UHS-I card will be running.

Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Acked-by: Aaron Lu <aaron.lu@amd.com>
Signed-off-by: Chris Ball <cjb@laptop.org>

mmc: sdhci-pci: add quirks for broken MSI on O2Micro controllers

MSI on my O2Micro OZ600 SD card reader is broken.  This patch adds a quirk
to disable MSI on these controllers.

Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com>
Signed-off-by: Chris Ball <cjb@laptop.org>