ACPI 5 introduced SPISerialBus resource that allows us to enumerate and
configure the SPI slave devices behind the SPI controller. This patch adds
support for this to the SPI core.

In addition we bind ACPI nodes to SPI devices. This makes it possible for
the slave drivers to get the ACPI handle for further configuration.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Add support for translating ACPI GPIO pin numbers to Linux GPIO API pins.
Needs a gpio controller driver with the acpi handler hook set.

Drivers can use acpi_get_gpio() to translate ACPI5 GpioIO and GpioInt
resources to Linux GPIO's.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

There is no need to initialize the node before appending it to the list.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The internal.h declares the acpi_create_platform_device(). Without
that include we get a following warning:

drivers/acpi/acpi_platform.c:133:24: warning: symbol 'acpi_create_platform_device' was not declared. Should it be static?
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Drivers usually expect that the devices they are supposed to handle
will be operational when their .probe() routines are called, but that
need not be the case on some ACPI-based systems with ACPI-based
device enumeration where the BIOSes don't put devices into D0 by
default.  To work around this problem it is sufficient to change
bus type .probe() routines to ensure that devices will be powered
on before the drivers' .probe() routines run (and their .remove()
and .shutdown() routines accordingly).

Modify platform_drv_probe() to run acpi_dev_pm_attach() for devices
whose ACPI handles are present, so that ACPI power management is used
to change their power states.  Analogously, modify
platform_drv_remove() and platform_drv_shutdown() to call
acpi_dev_pm_detach() for those devices, so that they are not subject
to ACPI PM any more.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Subsequent commits in this branch will depend on 'acpi-dev-pm'
material.

Make it possible to ask the routines used for adding/removing devices
to/from the general ACPI PM domain, acpi_dev_pm_attach() and
acpi_dev_pm_detach(), respectively, to change the power states of
devices so that they are put into the full-power state automatically
by acpi_dev_pm_attach() and into the lowest-power state available
automatically by acpi_dev_pm_detach().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Add a driver for SDHCI controllers enumerated via ACPI and identified
by the ACPI Compatibility ID PNP0D40 (or other SDHCI-specific ACPI
hardware IDs in the future).

[rjw: Added the changelog.]
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Acked-by: Chris Ball <cjb@laptop.org>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Add the generic ACPI SDHCI device ID to acpi_platform_device_ids[]
to make the ACPI core create a platform device object for the ACPI
device node of that ID.

[rjw: Added the changelog.]
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Make pnpacpi_add_device() ignore ACPI device nodes already associated
with struct device objects representing physical devices.

In particular, this will prevent PNP device objects from being
created for ACPI device nodes already associated with platform
devices.

This change was originally proposed by Mika Westerberg.

[rjw: Modified the subject and changelog.]
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI 5 introduced I2cSerialBus resource that makes it possible to enumerate
and configure the I2C slave devices behind the I2C controller. This patch
adds helper functions to support I2C slave enumeration.

An ACPI enabled I2C controller driver only needs to call acpi_i2c_register_devices()
in order to get its slave devices enumerated, created and bound to the
corresponding ACPI handle.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently we have valid flag to represent if this ACPI device power
state is valid. A device power state is valid does not necessarily
mean we, as OSPM, has a mean to put the device into that power state,
e.g. D3 cold is always a valid power state for any ACPI device, but if
there is no _PS3 or _PRx for this device, we can't really put that
device into D3 cold power state. The same is true for D0 power state.

So here comes the os_accessible flag, which is only set if the device
has provided us the required means to put it into that power state,
e.g. if we have _PS3 or _PRx, we can put the device into D3 cold state
and thus, D3 cold power state's os_accessible flag will be set in this
case.

And a new wrapper inline function is added to be used to check if
firmware has provided us a way to power off the device during runtime.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The current platform device creation and registration code in
acpi_create_platform_device() is quite convoluted.  This function
takes an ACPI device node as an argument and eventually calls
platform_device_register_resndata() to create and register a
platform device object on the basis of the information contained
in that code.  However, it doesn't associate the new platform
device with the ACPI node directly, but instead it relies on
acpi_platform_notify(), called from within device_add(), to find
that ACPI node again with the help of acpi_platform_find_device()
and acpi_platform_match() and then attach the new platform device
to it.  This causes an additional ACPI namespace walk to happen and
is clearly suboptimal.

Use the observation that it is now possible to initialize the ACPI
handle of a device before calling device_add() for it to make this
code more straightforward.  Namely, add a new field to struct
platform_device_info allowing us to pass the ACPI handle of interest
to platform_device_register_full(), which will then use it to
initialize the new device's ACPI handle before registering it.
This will cause acpi_platform_notify() to use the ACPI handle from
the device structure directly instead of using the .find_device()
routine provided by the device's bus type.  In consequence,
acpi_platform_bus, acpi_platform_find_device(), and
acpi_platform_match() are not necessary any more, so remove them.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

To avoid adding an ACPI handle pointer to struct device on
architectures that don't use ACPI, or generally when CONFIG_ACPI is
not set, in which cases that pointer is useless, define struct
acpi_dev_node that will contain the handle pointer if CONFIG_ACPI is
set and will be empty otherwise and use it to represent the ACPI
device node field in struct device.

In addition to that define macros for reading and setting the ACPI
handle of a device that don't generate code when CONFIG_ACPI is
unset.  Modify the ACPI subsystem to use those macros instead of
referring to the given device's ACPI handle directly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently, the ACPI handles of devices are initialized from within
device_add(), by acpi_bind_one() called from acpi_platform_notify()
which first uses the .find_device() routine provided by the device's
bus type to find the matching device node in the ACPI namespace.
This is a source of some computational overhead and, moreover, the
correctness of the result depends on the implementation of
.find_device() which is known to fail occasionally for some bus types
(e.g. PCI).  In some cases, however, the corresponding ACPI device
node is known already before calling device_add() for the given
struct device object and the whole .find_device() dance in
acpi_platform_notify() is then simply unnecessary.

For this reason, make it possible to initialize the ACPI handles of
devices before calling device_add() for them.  Modify
acpi_platform_notify() to call acpi_bind_one() in advance to check
the device's existing ACPI handle and skip the .find_device()
search if that is successful.  Change acpi_bind_one() accordingly.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Currently acpi_dev_process_resource() returns AE_ABORT_METHOD
to terminate the acpi_walk_resources() it is called from if
the .preproc() routine provided by the caller of
acpi_dev_get_resources() initiating the resources walk returns
an error code.  It is better to use AE_CTRL_TERMINATE for this
purpose, however, so do that.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>

No power transitioning from D3 state up to a non-D0 state is allowed
so make acpi_device_set_power() fail and complain if such a transition
is attempted.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit e5cc8ef3 (ACPI / PM: Provide ACPI PM callback routines for
subsystems) introduced a build problem occuring if CONFIG_ACPI is
unset or CONFIG_PM is unset and errno.h is not included before
acpi.h, because in that case ENODEV used in acpi.h is undefined.

Fix the issue by making acpi.h include errno.h.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Currently, whoever wants to use ACPI device resources has to call
acpi_walk_resources() to browse the buffer returned by the _CRS
method for the given device and create filters passed to that
routine to apply to the individual resource items.  This generally
is cumbersome, time-consuming and inefficient.  Moreover, it may
be problematic if resource conflicts need to be resolved, because
the different users of _CRS will need to do that in a consistent
way.  However, if there are resource conflicts, the ACPI core
should be able to resolve them centrally instead of relying on
various users of acpi_walk_resources() to handle them correctly
together.

For this reason, introduce a new function, acpi_dev_get_resources(),
that can be used by subsystems to obtain a list of struct resource
objects corresponding to the ACPI device resources returned by
_CRS and, if necessary, to apply additional preprocessing routine
to the ACPI resources before converting them to the struct resource
format.

Make the ACPI code that creates platform device objects use
acpi_dev_get_resources() for resource processing instead of executing
acpi_walk_resources() twice by itself, which causes it to be much
more straightforward and easier to follow.

In the future, acpi_dev_get_resources() can be extended to meet
the needs of the ACPI PNP subsystem and other users of _CRS in
the kernel.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Use common routines in drivers/acpi/resource.c to parse ACPI device
resources while creating platform device objects.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Move some code used for parsing ACPI device resources from the PNP
subsystem to the ACPI core, so that other bus types (platform, SPI,
I2C) can use the same routines for parsing resources in a consistent
way, without duplicating code.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>

Using _UID makes the ACPI platform bus code depend on BIOS to get it
right. If it doesn't we fail to create the platform device as the name
should be unique.

The ACPI core already makes a unique name when it first creates the ACPI
device so we can use that same name as the platform device name instead of
trusting that the BIOS sets the _UIDs correctly.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

With ACPI 5 it is now possible to enumerate traditional SoC
peripherals, like serial bus controllers and slave devices behind
them.  These devices are typically based on IP-blocks used in many
existing SoC platforms and platform drivers for them may already
be present in the kernel tree.

To make driver "porting" more straightforward, add ACPI support to
the platform bus type.  Instead of writing ACPI "glue" drivers for
the existing platform drivers, register the platform bus type with
ACPI to create platform device objects for the drivers and bind the
corresponding ACPI handles to those platform devices.

This should allow us to reuse the existing platform drivers for the
devices in question with the minimum amount of modifications.

This changeset is based on Mika Westerberg's and Mathias Nyman's
work.
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Acked-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

These functions might be called from modules as well so make sure
they are exported.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Acked-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

These functions might be called from modules as well so make sure
they are exported.

In addition, implement empty version of acpi_unregister_gsi() and
remove the one from pci_irq.c.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Acked-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Introduce function acpi_match_device() allowing callers to match
struct device objects with populated acpi_handle fields against
arrays of ACPI device IDs.  Also introduce function
acpi_driver_match_device() using acpi_match_device() internally and
allowing callers to match a struct device object against an array of
ACPI device IDs provided by a device driver.

Additionally, introduce macro ACPI_PTR() that may be used by device
drivers to escape pointers to data structures whose definitions
depend on CONFIG_ACPI.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Acked-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

With ACPI 5 we are starting to see devices that don't natively support
discovery but can be enumerated with the help of the ACPI namespace.
Typically, these devices can be represented in the Linux device driver
model as platform devices or some serial bus devices, like SPI or I2C
devices.

Since we want to re-use existing drivers for those devices, we need a
way for drivers to specify the ACPI IDs of supported devices, so that
they can be matched against device nodes in the ACPI namespace.  To
this end, it is sufficient to add a pointer to an array of supported
ACPI device IDs, that can be provided by the driver, to struct device.

Moreover, things like ACPI power management need to have access to
the ACPI handle of each supported device, because that handle is used
to invoke AML methods associated with the corresponding ACPI device
node.  The ACPI handles of devices are now stored in the archdata
member structure of struct device whose definition depends on the
architecture and includes the ACPI handle only on x86 and ia64. Since
the pointer to an array of supported ACPI IDs is added to struct
device_driver in an architecture-independent way, it is logical to
move the ACPI handle from archdata to struct device itself at the same
time.  This also makes code more straightforward in some places and
follows the example of Device Trees that have a poiter to struct
device_node in there too.

This changeset is based on Mika Westerberg's work.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Acked-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Commit b87b49cd0efd ("ACPI / PM: Move device PM functions related to sleep
states") declared acpi_target_system_state() for CONFIG_PM_SLEEP whereas
it is only defined for CONFIG_ACPI_SLEEP, resulting in the following link
error:

drivers/built-in.o: In function `acpi_pm_device_sleep_wake':
drivers/acpi/device_pm.c:342: undefined reference to `acpi_target_system_state'
drivers/built-in.o: In function `acpi_dev_suspend_late':
drivers/acpi/device_pm.c:501: undefined reference to `acpi_target_system_state'
drivers/built-in.o: In function `acpi_pm_device_sleep_state':
drivers/acpi/device_pm.c:221: undefined reference to `acpi_target_system_state'

Define it only for CONFIG_ACPI_SLEEP and fallback to a dummy definition
for other configs.

[rjw: The problem only occurs for exotic .configs in which
 HIBERNATE_CALLBACKS is selected by XEN_SAVE_RESTORE and neither
 SUSPEND nor HIBERNATION is set.]
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Some bus types don't support power management natively, but generally
there may be device nodes in ACPI tables corresponding to the devices
whose bus types they are (under ACPI 5 those bus types may be SPI,
I2C and platform).  If that is the case, standard ACPI power
management may be applied to those devices, although currently the
kernel has no means for that.

For this reason, provide a set of routines that may be used as power
management callbacks for such devices.  This may be done in three
different ways.

 (1) Device drivers handling the devices in question may run
     acpi_dev_pm_attach() in their .probe() routines, which (on
     success) will cause the devices to be added to the general ACPI
     PM domain and ACPI power management will be used for them going
     forward.  Then, acpi_dev_pm_detach() may be used to remove the
     devices from the general ACPI PM domain if ACPI power management
     is not necessary for them any more.

 (2) The devices' subsystems may use acpi_subsys_runtime_suspend(),
     acpi_subsys_runtime_resume(), acpi_subsys_prepare(),
     acpi_subsys_suspend_late(), acpi_subsys_resume_early() as their
     power management callbacks in the same way as the general ACPI
     PM domain does that.

 (3) The devices' drivers may execute acpi_dev_suspend_late(),
     acpi_dev_resume_early(), acpi_dev_runtime_suspend(),
     acpi_dev_runtime_resume() from their power management callbacks
     as appropriate, if that's absolutely necessary, but it is not
     recommended to do that, because such drivers may not work
     without ACPI support as a result.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Introduce helper function returning the target sleep state of the
system and use it to move the remaining device power management
functions from sleep.c to device_pm.c.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

If the caller of acpi_bus_set_power() already has a pointer to the
struct acpi_device object corresponding to the device in question, it
doesn't make sense for it to go through acpi_bus_get_device(), which
may be costly, because it involves acquiring the global ACPI
namespace mutex.

For this reason, export the function operating on struct acpi_device
objects used internally by acpi_bus_set_power(), so that it may be
called instead of acpi_bus_set_power() in the above case, and change
its name to acpi_device_set_power().

Additionally, introduce two inline wrappers for checking ACPI PM
capabilities of devices represented by struct acpi_device objects.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Two device wakeup management routines in device_pm.c and sleep.c,
acpi_pm_device_run_wake() and acpi_pm_device_sleep_wake(), take a
device pointer argument and use it to obtain the ACPI handle of the
corresponding ACPI namespace node.  That handle is then used to get
the address of the struct acpi_device object corresponding to the
struct device passed as the argument.

Unfortunately, that last operation may be costly, because it involves
taking the global ACPI namespace mutex, so it shouldn't be carried
out too often.  However, the callers of those routines usually call
them in a row with acpi_pm_device_sleep_state() which also takes that
mutex for the same reason, so it would be more efficient if they ran
acpi_bus_get_device() themselves to obtain a pointer to the struct
acpi_device object in question and then passed that pointer to the
appropriate PM routines.

To make that possible, split each of the PM routines mentioned above
in two parts, one taking a struct acpi_device pointer argument and
the other implementing the current interface for compatibility.

Additionally, change acpi_pm_device_run_wake() to actually return
an error code if there is an error while setting up runtime remote
wakeup for the device.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI function for setting up devices to do runtime remote
wakeup is now located in drivers/acpi/sleep.c, but
drivers/acpi/device_pm.c is a more logical place for it, so move it
there.

No functional changes should result from this modification.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The ACPI function for choosing device power state is now located
in drivers/acpi/sleep.c, but drivers/acpi/device_pm.c is a more
logical place for it, so move it there.

However, instead of moving the function entirely, move its core only
under a different name and with a different list of arguments, so
that it is more flexible, and leave a wrapper around it in the
original location.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI routines for adding and removing device wakeup notifiers are
currently defined in a PCI-specific file, but they will be necessary
for non-PCI devices too, so move them to a separate file under
drivers/acpi and rename them to indicate their ACPI origins.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The kerneldoc comments for acpi_pm_device_sleep_state(),
acpi_pm_device_run_wake(), and acpi_pm_device_sleep_wake() are
outdated or otherwise inaccurate and/or don't follow the common
kerneldoc patterns, so fix them.

Additionally, notice that acpi_pm_device_run_wake() should be under
CONFIG_PM_RUNTIME rather than under CONFIG_PM_SLEEP, so fix that too.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Material in the 'acpi-dev-pm' branch depends on 'pm-qos' commits.

Since dev_pm_qos_add_request(), dev_pm_qos_update_request() and
dev_pm_qos_remove_request() for PM QoS flags should not be invoked
when device in RPM_SUSPENDED, add pm_runtime_get_sync() and pm_runtime_put()
around these functions in dev_pm_qos_expose_flags() and
dev_pm_qos_hide_flags().

[rjw: Modified the subject and changelog to better reflect the code
 changes made.]
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Pull networking fixes from David Miller:
 "Bug fixes galore, mostly in drivers as is often the case:

  1) USB gadget and cdc_eem drivers need adjustments to their frame size
     lengths in order to handle VLANs correctly.  From Ian Coolidge.

  2) TIPC and several network drivers erroneously call tasklet_disable
     before tasklet_kill, fix from Xiaotian Feng.

  3) r8169 driver needs to apply the WOL suspend quirk to more chipsets,
     fix from Cyril Brulebois.

  4) Fix multicast filters on RTL_GIGA_MAC_VER_35 r8169 chips, from
     Nathan Walp.

  5) FDB netlink dumps should use RTM_NEWNEIGH as the message type, not
     zero.  From John Fastabend.

  6) Fix smsc95xx tx checksum offload on big-endian, from Steve
     Glendinning.

  7) __inet_diag_dump() needs to repsect and report the error value
     returned from inet_diag_lock_handler() rather than ignore it.
     Otherwise if an inet diag handler is not available for a particular
     protocol, we essentially report success instead of giving an error
     indication.  Fix from Cyrill Gorcunov.

  8) When the QFQ packet scheduler sees TSO/GSO packets it does not
     handle things properly, and in fact ends up corrupting it's
     datastructures as well as mis-schedule packets.  Fix from Paolo
     Valente.

  9) Fix oopser in skb_loop_sk(), from Eric Leblond.

  10) CXGB4 passes partially uninitialized datastructures in to FW
      commands, fix from Vipul Pandya.

  11) When we send unsolicited ipv6 neighbour advertisements, we should
      send them to the link-local allnodes multicast address, as per
      RFC4861.  Fix from Hannes Frederic Sowa.

  12) There is some kind of bug in the usbnet's kevent deferral
      mechanism, but more immediately when it triggers an uncontrolled
      stream of kernel messages spam the log.  Rate limit the error log
      message triggered when this problem occurs, as sending thousands
      of error messages into the kernel log doesn't help matters at all,
      and in fact makes further diagnosis more difficult.

      From Steve Glendinning.

  13) Fix gianfar restore from hibernation, from Wang Dongsheng.

  14) The netlink message attribute sizes are wrong in the ipv6 GRE
      driver, it was using the size of ipv4 addresses instead of ipv6
      ones :-) Fix from Nicolas Dichtel."

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
  gre6: fix rtnl dump messages
  gianfar: ethernet vanishes after restoring from hibernation
  usbnet: ratelimit kevent may have been dropped warnings
  ipv6: send unsolicited neighbour advertisements to all-nodes
  net: usb: cdc_eem: Fix rx skb allocation for 802.1Q VLANs
  usb: gadget: g_ether: fix frame size check for 802.1Q
  cxgb4: Fix initialization of SGE_CONTROL register
  isdn: Make CONFIG_ISDN depend on CONFIG_NETDEVICES
  cxgb4: Initialize data structures before using.
  af-packet: fix oops when socket is not present
  pkt_sched: enable QFQ to support TSO/GSO
  net: inet_diag -- Return error code if protocol handler is missed
  net: bnx2x: Fix typo in bnx2x driver
  smsc95xx: fix tx checksum offload for big endian
  rtnetlink: Use nlmsg type RTM_NEWNEIGH from dflt fdb dump
  ptp: update adjfreq callback description
  r8169: allow multicast packets on sub-8168f chipset.
  r8169: Fix WoL on RTL8168d/8111d.
  drivers/net: use tasklet_kill in device remove/close process
  tipc: do not use tasklet_disable before tasklet_kill