Properly document the transmit buffer bits using an enum and
kernel-doc documentation.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Add kernel-doc documentation for enum iwl_debug_cmds, linking the
structures used by the commands.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
To stop and start the FW monitor in the 7000 HW
family we need to use a different bit, otherwise
after stopping it for the first time - it won't
get restarted. Use the correct bitmask.
Note: This fix is only for DRAM collection mode.
For other modes, an additional fix will be
needed.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Fix the enum link by adding the missing & and provide the link
to the TX response documentation.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When the command name is printed on command completion, the wrong
group is used, leading to the wrong name being printed. Fix this
by using the group ID without inappropriately mangling it through
iwl_cmd_groupid() - it's already a u8. Also, while at it, use it
from the same place as the command ID, everything else is just
confusing.
Fixes: ab02165cce ("iwlwifi: add wide firmware command infrastructure for TX")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When sending non-linear SKBs that should be included in the regular
TX tracing completely (and not be pushed into the tx_data tracing),
the (tracing) code didn't correctly take the fact that they were
non-linear into account and added only the skb head portion.
This probably never really triggered, since those frames we want
traced fully are most likely linear anyway, but the code gets easier
to understand and we lose an argument to the tracing function, so
overall fixing this is better.
Fixes: 206eea7833 ("iwlwifi: pcie: support frag SKBs")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
There's no need to calculate the data_len outside of the tracepoint,
since it's always skb->len - hdr_len, which are both available inside.
Simplify the callers and move the calculation in.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
The structure hci_serdev_client_ops does not need to be in global scope
and is not modified, so make it static.
Cleans up sparse warning:
"symbol 'hci_serdev_client_ops' was not declared. Should it be static?"
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Instead of unconditionally expiring the timer and calling a long
mt_release_contacts(), we can check if some slots are used when the
timer expires.
We can also remove the timer if we happen to receive all the releases.
The logic behind the MT_IO_FLAGS_PENDING_SLOTS could be implemented by
counting how many slots are active, but using bits feels slightly more
efficient.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Arek Burdach <arek.burdach@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Instead of blindly trusting the hardware to send us release, we should
consider some events can get lost and release them when we judge time has
come.
The Windows 8 spec allows to be confident in the fact that the device
will continuously report events when a finger touches the surface.
This has been tested on the HID recording database I have, and all of
those devices behave properly.
Also, Arek tested it on his Lenovo Yoga 910, which exports such bug in
some situations, when the movements are rather slow.
We use an atomic bit here to guard against concurrent accesses to the mt
slots because both mt_process_mt_event() and mt_expired_timeout() are
called in interrupt context.
Signed-off-by: Arek Burdach <arek.burdach@gmail.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Tested-by: Arek Burdach <arek.burdach@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The current ITS driver is assuming every ITS hardware implementation
supports minimum of 16bit INTID. But this is not true, as per GICv3
specification, INTID field is IMPLEMENTATION DEFINED in the range of
14-24 bits. We might see an unpredictable system behavior on systems
where hardware support less than 16bits and software tries to use
64K LPI interrupts.
On Qualcomm Datacenter Technologies QDF2400 platform, boot log shows
confusing information about number of LPI chunks as shown below. The
QDF2400 ITS hardware supports 24bit INTID.
This patch allocates the memory resources for PEND/PROP tables based
on discoverable value which is specified in GITS_TYPER.IDbits. Also
it fixes the log message that reflects the correct number of LPI
chunks were allocated.
ITS@0xff7efe0000: allocated 524288 Devices @3c0400000 (indirect, esz 8, psz 64K, shr 1)
ITS@0xff7efe0000: allocated 8192 Interrupt Collections @3c0130000 (flat, esz 8, psz 64K, shr 1)
ITS@0xff7efe0000: allocated 8192 Virtual CPUs @3c0140000 (flat, esz 8, psz 64K, shr 1)
ITS: Allocated 524032 chunks for LPIs
PCI/MSI: ITS@0xff7efe0000 domain created
Platform MSI: ITS@0xff7efe0000 domain created
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Add code to parse SRAT ITS Affinity sub table as defined in ACPI 6.2.
Later in per device probe, ITS devices are mapped to numa node using
ITS Id to proximity domain mapping.
[maz: fix dependency on ACPICA, fixed structure name, minor cleanups]
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by <linux/of.h> work with const
of_device_ids. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by <linux/of.h> work with const
of_device_ids. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
The Marvell ICU unit is found in the CP110 block of the Marvell Armada
7K and 8K SoCs. It collects the wired interrupts of the devices located
in the CP110 and turns them into SPI interrupts in the GIC located in
the AP806 side of the SoC, by using a memory transaction.
Until now, the ICU was configured in a static fashion by the firmware,
and Linux was relying on this static configuration. By having Linux
configure the ICU, we are more flexible, and we can allocate dynamically
the GIC SPI interrupts only for devices that are actually in use.
The driver was initially written by Hanna Hawa <hannah@marvell.com>.
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
This commit adds a simple driver for the Marvell GICP, a hardware unit
that converts memory writes into GIC SPI interrupts. The driver provides
a number of functions to the ICU driver to allocate GICP interrupts, and
get the physical addresses that the ICUs should write to to set/clear
interrupts.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
The F54 driver is currently only using the first 6 bytes of F54 so there is
no need to read all 27 bytes. Some Dell systems (Dell XP13 9333 and
similar) have an issue with the touchpad or I2C bus when reading reports
larger then 16 bytes. Reads larger then 16 bytes are reported in two HID
reports. Something about the back to back reports seems to cause the next
read to report incorrect data. This results in F30 failing to load and the
click button failing to work.
Previous issues with the I2C controller or touchpad were addressed in:
commit 5b65c2a029 ("HID: rmi: check sanity of the incoming report")
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=195949
Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Nick Dyer <nick@shmanahar.org>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
A previous set of patches "cxl: Add support for Coherent Accelerator
Interface Architecture 2.0" has introduced a new support for the CAPI
cards. These patches have been tested on Simulation environment and
quite a bit of them have been tested on real hardware.
This patch brings new fixes after a series of tests carried out on new
equipment:
- Add POWER9 definition.
- Re-enable any masked interrupts when the AFU is not activated
after resetting the AFU.
- Remove the api cxl_is_psl8/9 which is no longer useful.
- Do not dump CAPI1 registers.
- Rewrite cxl_is_page_fault() function.
- Do not register slb callack on P9.
Fixes: f24be42aab ("cxl: Add psl9 specific code")
Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Pull in the fix for shared tags, as it conflicts with the pending
changes in for-4.13/block. We already pulled in v4.12-rc5 to solve
other conflicts or get fixes that went into 4.12, so not a lot
of changes in this merge.
Signed-off-by: Jens Axboe <axboe@kernel.dk>
CONFIG_COMPILE_TEST allows building a configuration without
TI_SCI_PROTOCOL, which then fails to link:
drivers/clk/keystone/sci-clk.o: In function `ti_sci_clk_probe':
sci-clk.c:(.text.ti_sci_clk_probe+0x4c): undefined reference to `devm_ti_sci_get_handle'
This makes it a hard dependency. Right now, that means we can't
actually compile-test the driver unless ARCH_KEYSTONE is set as
well, but we can fix that by allowing TI_MESSAGE_MANAGER to
be selected for COMPILE_TEST as well.
Fixes: b745c0794e ("clk: keystone: Add sci-clk driver support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Allow the intel-hid driver to wake up the system from suspend-to-idle
by configuring its platform device as a wakeup one by default and
switching it over to a system wakeup events triggering mode during
system suspend transitions.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Allow the intel-vbtn driver to wake up the system from suspend-to-idle
by configuring its platform device as a wakeup one by default and
switching it over to a system wakeup events triggering mode during
system suspend transitions.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
NULL checks at line 457: if (!link0 || !link1) {, implies that both
pointers link0 and link1 might be NULL.
Function nfcsim_link_free() dereference pointers link0 and link1.
Add NULL checks before calling nfcsim_link_free() to avoid a
potential NULL pointer dereference.
Addresses-Coverity-ID: 1364857
Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
This reverts commit ab714817d7.
The original commit was designed to handle a bug in the trf7970a NFC
controller where an extra byte was returned in Read Multiple Blocks (RMB)
command responses. However, it has become less clear whether it is a bug
in the trf7970a or in the tag. In addition, it was assumed that the extra
byte was always returned but it turns out that is not always the case. The
result is that a byte of good data is trimmed off when the extra byte is
not present ultimately causing the neard deamon to fail the read.
Since the trf7970a driver does not have the context to know when to trim
the byte or not, remove the code from the trf7970a driver all together
(and move it up to the neard daemon). This has the added benefit of
simplifying the kernel driver and putting the extra complexity into
userspace.
CC: Rob Herring <robh@kernel.org>
CC: devicetree@vger.kernel.org
Signed-off-by: Mark Greer <mgreer@animalcreek.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
The "or" condition (clk_freq != TRF7970A_27MHZ_CLOCK_FREQUENCY) ||
(clk_freq != TRF7970A_13MHZ_CLOCK_FREQUE) will always be true because
clk_freq cannot be equal to two different values at the same time. Use
the && operator instead of || to fix this.
Detected by CoverityScan, CID#1430468 ("Constant expression result")
Fixes: 837eb4d21e ("NFC: trf7970a: add device tree option for 27MHz clock")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Geoff Lansberry <geoff@kuvee.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Similarly to commit f1e9203e23 ("clk: samsung: Fix Exynos 5420 pinctrl
setup and clock disable failure due to domain being gated") for
Exynos5420, the Exynos4412 also requires that EPLL is not disabled.
Otherwise any access to MAUDIO block will silently halt.
This was not visible before because EPLL on Exynos4 could not be
disabled before commit 6edfa11cb3 ("clk: samsung:
Add enable/disable operation for PLL36XX clocks"). After this commit,
on Odroid U3 board one can see silent hang, usually with last (but
unrelated) messages:
[ 2.382741] input: gpio_keys as /devices/platform/gpio_keys/input/input0
[ 2.405686] usb 1-3: new high-speed USB device number 3 using exynos-ehci
[ 2.419843] max77686-rtc max77686-rtc: setting system clock to 2017-06-21 17:04:13 UTC (1498064653)
Mark Exynos4 variant as also needed EPLL to be enabled all the time.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Since OF and ACPI case almost the same get rid of code duplication
by moving gpiod_get() calls directly to ->probe().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Since we got rid of platform data, the driver may use GPIO descriptor
directly.
Looking deeply to the use of the GPIO pin it looks like it should be
a GPIO based reset control rather than custom GPIO handling. But this
is out of scope of the change.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
I2C and SPI frameworks followed by IRQ framework do set
interrupt polarity correctly if it's properly specified in firmware
(ACPI or DT).
Get rid of the redundant trick when requesting interrupt.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Legacy platform data must go away. We are on the safe side here since
there are no users of it in the kernel.
If anyone by any odd reason needs it the GPIO lookup tables and
built-in device properties at your service.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
It looks like there are two leftovers, at least one of which can leak
the resource (IRQ).
Convert both places to use managed variants of the functions.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
There is no platform code that uses i2c module table.
Remove it altogether and adjust ->probe() to be ->probe_new().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Since OF and ACPI case almost the same get rid of code duplication
by moving gpiod_get() calls directly to ->probe().
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.
Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Switch to use managed variant of acpi_dev_add_driver_gpios() to simplify
error path and fix potentially wrong assignment if ->probe() fails.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Show the name of the member (scanned_channels) that provides the
length with some better markup.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
On A000 HW, the SCD rdptr has only 8 bits allocated
for it, thus when checking if a queue is full, or
when checking if the SSN is equal to the TID's
next_reclaimed, A000 HW should trim the SSN.
Fix this by "normalizing" the SSN to wrap around
0xFF when comparing to the next_reclaimed on A000
HW.
Signed-off-by: Liad Kaufman <liad.kaufman@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
We don't actually care about the value at all, just making sure
that we can successfully parse a single integer value, but that's
entirely pointless - remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
When toggling the RF-kill pin quickly in succession, the driver can
get rather confused because it might be in the process of shutting
down, expecting all commands to go through quickly due to rfkill,
but the transport already thinks the device is accessible again,
even though it previously shut it down. This leads to bugs, and I
even observed a kernel panic.
Avoid this by making the PCIe code only report that the radio is
enabled again after the higher layers actually decided to shut it
off.
This also pulls out this common RF-kill checking code into a common
function called by both transport generations and also moves it to
the direct method - in the internal helper we don't really care
about the RF-kill status anymore since we won't report it up until
the stop anyway.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
