The dell-smbios stack only currently uses an SMI interface which grants
direct access to physical memory to the firmware SMM methods via a pointer.

This dispatcher driver adds a WMI-ACPI interface that is detected by WMI
probe and preferred over the SMI interface in dell-smbios.

Changing this to operate over WMI-ACPI will use an ACPI OperationRegion
for a buffer of data storage when SMM calls are performed.

This is a safer approach to use in kernel drivers as the SMM will
only have access to that OperationRegion.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

This splits up the dell-smbios driver into two drivers:
* dell-smbios
* dell-smbios-smm

dell-smbios can operate with multiple different dispatcher drivers to
perform SMBIOS operations.

Also modify the interface that dell-laptop and dell-wmi use align to this
model more closely.  Rather than a single global buffer being allocated
for all drivers, each driver will allocate and be responsible for it's own
buffer. The pointer will be passed to the calling function and each
dispatcher driver will then internally copy it to the proper location to
perform it's call.

Add defines for calls used by these methods in the dell-smbios.h header
for tracking purposes.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Currently userspace tools can access system tokens via the dcdbas
kernel module and a SMI call that will cause the platform to execute
SMM code.

With a goal in mind of deprecating the dcdbas kernel module a different
method for accessing these tokens from userspace needs to be created.

This is intentionally marked to only be readable as a process with
CAP_SYS_ADMIN as it can contain sensitive information about the
platform's configuration.

While adding this interface I found that some tokens are duplicated.
These need to be ignored from sysfs to avoid duplicate files.

MAINTAINERS was missing for this driver.  Add myself and Pali to
maintainers list for it.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The proper way to indicate that a system is a 'supported' Dell System
is by the presence of this string in OEM strings.

Allowing the driver to load on non-Dell systems will have undefined
results.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The only driver using this was dell-wmi, and it really was a hack.
The driver was getting a data attribute from another driver and this
type of action should not be encouraged.

Rather drivers that need to interact with one another should pass
data back and forth via exported functions.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

All communication on individual GUIDs should occur in separate drivers.
Allowing a driver to communicate with the bus to another GUID is just
a hack that discourages drivers to adopt the bus model.

The information found from the WMI descriptor driver is now exported
for use by other drivers.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

This is intended to be variable and provided by the platform.
Some platforms this year will be adopting a 32k WMI buffer, so don't
complain when encountering those platforms or any other future changes.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Some cases the wrong type was used for errors and checks can be
done more cleanly.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Suggested-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

There is a lot of error checking in place for the format of the WMI
descriptor buffer, but some of the potentially raised issues should
be considered critical failures.

If the buffer size or header don't match, this is a good indication
that the buffer format changed in a way that the rest of the data
should not be relied upon.

For the remaining data set vectors, continue to notate a warning
in undefined results, but as those are fields that the descriptor
intended to refer to other applications, don't fail if they're new
values.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Drivers properly using the wmibus can pass their wmi_device
pointer rather than the GUID back to the WMI bus to evaluate
the proper methods.

Any "new" drivers added that use the WMI bus should use this
rather than the old wmi_evaluate_method that would take the
GUID.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Reviewed-by: NPali Rohár <pali.rohar@gmail.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Later on these structures will be brought up to userspace.
the word "class" is a reserved word in c++ and this will prevent
uapi headers from being included directly in c++ programs.

To make life easier on these applications, prepare the change now.
Signed-off-by: NMario Limonciello <mario.limonciello@dell.com>
Reviewed-by: NEdward O'Callaghan <quasisec@google.com>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

The fusb302 driver as merged in staging uses "typec_fusb302" as i2c-id
rather then just "fusb302" and needs us to set a number of device-
properties, adjust the intel_cht_int33fe driver accordingly.

One of the properties set is max-snk-mv which makes the fusb302 driver
negotiate up to 12V charging voltage, which is a bad idea on boards
which are not setup to handle this, so this commit also adds 2 extra
sanity checks to make sure that the expected Whiskey Cove PMIC +
TI bq24292i charger combo, which can handle 12V, is present.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Add touchscreen platform data for the Digma e200 tablet.
Signed-off-by: NSergey Tshovrebov <sinxwal@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The GP-electronic T701 has its LCD panel mounted upside-down, initially
my plan was to fix this by transparently rotating the image in the i915
driver (my "drm/i915: Deal with upside-down mounted LCD" patch), but
that approach has been rejected instead the kernel will now export
a "panel orientation" property on the drm-connector for the panel and
let userspace deal with it.

But userspace expects the touchscreen coordinates to match the panel
coordinates *before* applying any rotation, so now that we no longer hide
the upside-down-ness of the LCD panel from userspace the coordinates being
generated are wrong and we need to apply a rotation of 180 degrees to the
coordinates to fix this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

peaq_wmi_exit will only ever get called if peaq_wmi_init succeeds, so
there is no need to repeat the checks from peaq_wmi_init.
Suggested-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Add missing terminating entry to peaq_dmi_table.

Fixes: 3b952061 ("platform/x86: peaq-wmi: Add DMI check before ...")
Cc: stable@vger.kernel.org
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The Lenovo Yoga 920-13IKB does not have a hw rfkill switch, and trying
to read the hw rfkill switch through the ideapad module causes it to
always report as blocked.

This commit adds the Lenovo Yoga 920-13IKB to the no_hw_rfkill dmi list,
fixing the WiFI breakage.
Signed-off-by: NPhilipp Hug <philipp@hug.cx>
Signed-off-by: NDarren Hart (VMware) <dvhart@infradead.org>

Radio LED detection method implemented in commit 4f62568c
("fujitsu-laptop: Support radio LED") turned out to be incorrect as it
causes a radio LED to be erroneously detected on a Fujitsu Lifebook E751
which has a slide switch (and thus no radio LED).  Use bit 17 of
flags_supported (the value returned by method S000 of ACPI device
FUJ02E3) to determine whether a radio LED is present as it seems to be a
more reliable indicator, based on comparing DSDT tables of four Fujitsu
Lifebook models (E744, E751, S7110, S8420).

Fixes: 4f62568c ("fujitsu-laptop: Support radio LED")
Reported-by: NHeinrich Siebmanns <harv@gmx.de>
Signed-off-by: NMichał Kępień <kernel@kempniu.pl>
Tested-by: NHeinrich Siebmanns <harv@gmx.de>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Added support for HP ProBook 440 G4 laptops by including the accelerometer
orientation quirk for that device. Testing was performed based on the
axis orientation guidelines here:
https://www.kernel.org/doc/Documentation/misc-devices/lis3lv02d
which states "If the left side is elevated, X increases (becomes positive)".

When tested, on lifting the left edge, x values became increasingly negative
thus indicating an inverted x-axis on the installed lis3lv02d chip.
This was compensated by adding an entry for this device in hp_accel.c
specifying the quirk as x_inverted. The patch was tested on a
ProBook 440 G4 device and x-axis as well as y and z-axis values are now
generated as per spec.
Signed-off-by: NOsama Khan <osama.khan@ericsson.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Ev Kontsevoy reported that he can't see the presence of
"/proc/sys/kernel/sched_itmt_enabled" on i9-7900x with Asrock x299
Taichi system even if he enabled "Turbo 3.0" in the BIOS.

The problem is that even if one core max is 200MHz more than others, the
current implementation couldn't enumerate that with the way the system
is configured.

The system by default configured for legacy mode (no HWP or speed shift
technology), in this mode only way we can enumerate via the mail box
interface as implemented in this driver. We were planing to only use
this driver for Broadwell, but we need to extend this because some
Skylake system has same issue as Braodwell systems.

On this system BIOS allows to change to HWP mode, where we expect that
we can enumerate favored core with ACPI-CPPC. But on this system the
core priority is 0xff for all cores in CPPC object. So this is not an
option.

Hence this change allows Skylake systems to be enumerate favored core
similar to Broadwell in legacy mode.
Reported-and-tested-by: NEv Kontsevoy <ev@kontsevoy.com>
Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

'default n' is a default behaviour of Kconfig options. So, remove
explicit line from Kconfig.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

linux/io.h defines readq() and ioremap_nocache() / iounmap() functions.

If not included, the build fails:

intel_telemetry_pltdrv.c:1165:31: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
intel_telemetry_pltdrv.c:1165:33: error: implicit declaration of function 'ioremap_nocache' [-Werror=implicit-function-declaration]
intel_telemetry_pltdrv.c:1202:3: error: implicit declaration of function 'iounmap' [-Werror=implicit-function-declaration]
intel_telemetry_pltdrv.c:900:20: error: implicit declaration of function 'readq' [-Werror=implicit-function-declaration]

Fix this by including linux/io.h.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Add device-properties to make the bq24292i charger connected to
the bus get its input-current-limit from the fusb302 Type-C port
controller which is used on boards with the cht-wc PMIC,
as well as regulator_init_data for the 5V boost converter on
the bq24292i.

Since this means we now hook-up the bq24292i to the fusb302 Type-C port
controller add a check for the ACPI device which instantiates the fusb302.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

For devices not instantiated through ACPI the i2c-client's device-name
gets set to <busnr>-<addr> by default, e.g. "0-0022" this means that
the device-name is dependent on the order in which the i2c-busses are
enumerated.

In some cases having a predictable constant device-name is desirable,
for example on non device-tree platforms the link between a regulator
and its consumers is specified by the platform code by setting
regulator_init_data.consumers. This array identifies the regulator's
consumers by dev_name and supply(-name). Which requires a constant
dev_name.

This commit adds a dev_name field to i2c_board_info allowing
platform code to set a contstant dev_name so that the device can
be identified by its dev_name in other platform code.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: Mark Brown <broonie@kernel.org> (live at ELCE17)
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> (live at ELCE17)
Signed-off-by: NWolfram Sang <wsa@the-dreams.de>

Currently, update_no_reboot_bit() function implemented in this driver
uses mutex_lock() to protect its register updates. But this function is
called with in atomic context in iTCO_wdt_start() and iTCO_wdt_stop()
functions in iTCO_wdt.c driver, which in turn causes "sleeping into
atomic context" issue. This patch fixes this issue by replacing the
mutex_lock() with spin_lock() to protect the GCR read/write/update APIs.

Fixes: 9d855d46 ("platform/x86: intel_pmc_ipc: Fix iTCO_wdt GCS memory mapping failure")
Signed-off-by: NKuppuswamy Sathyanarayanan <sathyanarayanan.kupuswamy@linux.intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Removes unnecessary header files included in the driver and sorts the
remaining ones in the alphabetical order.
Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Telemetry word is misspelled several times in this file as Telemtry. This
fixes the spelling mistake and folds in another minor typo.
Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

Intel Telemetry driver depends on IPC1 interface. If IPC1 interface is
disabled on a given platform by the system firmware, the driver does not
load but prints misleading information in the dmesg logs.
Signed-off-by: NRajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

The functions cht_int33fe_check_for_max17047 and cht_int33fe_find_max17047
are local to the source and do not need to be in global scope, so make
them static.

Cleans up sparse warnings:
symbol 'cht_int33fe_check_for_max17047' was not declared. Should it be
static?
symbol 'cht_int33fe_find_max17047' was not declared. Should it be static?
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>

This is the possible reason for different hard to reproduce
problems on my ARMv7-SMP test system.

The symptoms are in recent kernels imprecise external aborts,
and in older kernels various kinds of network stalls and
unexpected page allocation failures.

My testing indicates that the trouble started between v4.5 and v4.6
and prevails up to v4.14.

Using the dirty_tx before acquiring the spin lock is clearly
wrong and was first introduced with v4.6.

Fixes: e3ad57c9 ("stmmac: review RX/TX ring management")
Signed-off-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

If an Ethernet PHY is initialized before the interrupt controller it is
connected to, a message like the following is printed:

    irq: no irq domain found for /interrupt-controller@e61c0000 !

However, the actual error is ignored, leading to a non-functional (POLL)
PHY interrupt later:

    Micrel KSZ8041RNLI ee700000.ethernet-ffffffff:01: attached PHY driver [Micrel KSZ8041RNLI] (mii_bus:phy_addr=ee700000.ethernet-ffffffff:01, irq=POLL)

Depending on whether the PHY driver will fall back to polling, Ethernet
may or may not work.

To fix this:
  1. Switch of_mdiobus_register_phy() from irq_of_parse_and_map() to
     of_irq_get().
     Unlike the former, the latter returns -EPROBE_DEFER if the
     interrupt controller is not yet available, so this condition can be
     detected.
     Other errors are handled the same as before, i.e. use the passed
     mdio->irq[addr] as interrupt.
  2. Propagate and handle errors from of_mdiobus_register_phy() and
     of_mdiobus_register_device().
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Prevent infinite loop by correctly setting the loop condition to
break when i == 10.
Signed-off-by: NJose Abreu <joabreu@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When using GMAC4 the valid timestamp is from CTX next desc but
we are passing the previous desc to get_rx_timestamp_status()
callback.

Fix this and while at it rework a little bit the function logic.
Signed-off-by: NJose Abreu <joabreu@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

When RX HW timestamp is enabled and a frame is discarded we are
not freeing the skb but instead only setting to NULL the entry.

Add a call to dev_kfree_skb_any() so that skb entry is correctly
freed.
Signed-off-by: NJose Abreu <joabreu@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Spectrum tunnels do not default to ttl of "inherit" like the Linux ones
do. Configure TIGCR on router init so that the TTL of tunnel packets is
copied from the overlay packets.

Fixes: ee954d1a ("mlxsw: spectrum_router: Support GRE tunnels")
Signed-off-by: NPetr Machata <petrm@mellanox.com>
Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The TIGCR register is used for setting up the IPinIP Tunnel
configuration.

Fixes: ee954d1a ("mlxsw: spectrum_router: Support GRE tunnels")
Signed-off-by: NPetr Machata <petrm@mellanox.com>
Reviewed-by: NIdo Schimmel <idosch@mellanox.com>
Signed-off-by: NJiri Pirko <jiri@mellanox.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Default Tx rates cause very long ISR delays on Tx.
0xff is 510us delay, giving only ~ 2000 interrupts per seconds for
Tx rings cleanup. With these settings udp tx rate was never higher than
~800Mbps on a single stream. Changing min delay to 0xF makes it
way better with ~6Gbps

TCP stream performance is almost unaffected by this change, since LSO
optimizations play important role.

CPU load is affected insignificantly by this change.
Signed-off-by: NPavel Belous <pavel.belous@aquantia.com>
Signed-off-by: NIgor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Aquantia NIC allows both TX and RX interrupt throttle rate (ITR)
management, but this was used in a very limited way via predefined
values. This patch allows to setup ITR default values via module
command line arguments and via standard ethtool coalescing settings.
Signed-off-by: NPavel Belous <pavel.belous@aquantia.com>
Signed-off-by: NIgor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

That may lead to mmio resource leakage.
Signed-off-by: NPavel Belous <pavel.belous@aquantia.com>
Signed-off-by: NIgor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

There is no much practical use from having MSIX vectors more that number
of cpus, thus cap this first with preconfigured limit, then with number
of cpus online.
Signed-off-by: NPavel Belous <pavel.belous@aquantia.com>
Signed-off-by: NIgor Russkikh <igor.russkikh@aquantia.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>