With the introduction of MOVDIR64B instruction, there is now an instruction
that can write 64 bytes of data atomically.
Quoting from Intel SDM:
"There is no atomicity guarantee provided for the 64-byte load operation
from source address, and processor implementations may use multiple
load operations to read the 64-bytes. The 64-byte direct-store issued
by MOVDIR64B guarantees 64-byte write-completion atomicity. This means
that the data arrives at the destination in a single undivided 64-byte
write transaction."
We have identified at least 3 different use cases for this instruction in
the format of func(dst, src, count):
1) Clear poison / Initialize MKTME memory
@dst is normal memory.
@src in normal memory. Does not increment. (Copy same line to all
targets)
@count (to clear/init multiple lines)
2) Submit command(s) to new devices
@dst is a special MMIO region for a device. Does not increment.
@src is normal memory. Increments.
@count usually is 1, but can be multiple.
3) Copy to iomem in big chunks
@dst is iomem and increments
@src in normal memory and increments
@count is number of chunks to copy
Add support for case #2 to support device that will accept commands via
this instruction. We provide a @count in order to submit a batch of
preprogrammed descriptors in virtually contiguous memory. This
allows the caller to submit multiple descriptors to a device with a single
submission. The special device requires the entire 64bytes descriptor to
be written atomically and will accept MOVDIR64B instruction.
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Acked-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/157965022175.73301.10174614665472962675.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
fs/xfs/xfs_inode.c: In function 'xfs_itruncate_extents_flags':
fs/xfs/xfs_inode.c:1523:8: warning: unused variable 'done' [-Wunused-variable]
commit 4bbb04abb4 ("xfs: truncate should remove
all blocks, not just to the end of the page cache")
left behind this, so remove it.
Fixes: 4bbb04abb4 ("xfs: truncate should remove all blocks, not just to the end of the page cache")
Reported-by: Hulk Robot <hulkci@huawei.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Dan Carpenter pointed out that error is uninitialized. While there
never should be an attr leaf block with zero entries, let's not leave
that logic bomb there.
Fixes: 0bb9d159bd ("xfs: streamline xfs_attr3_leaf_inactive")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Allison Collins <allison.henderson@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
In HWiNFO, we see support for Tccd1, Tccd3, Tccd5, and Tccd7 temperature
sensors on Zen2 based Threadripper CPUs. Checking register maps on
Threadripper 3970X confirms SMN register addresses and values for those
sensors.
Register values observed in an idle system:
0x059950: 00000000 00000abc 00000000 00000ad8
0x059960: 00000000 00000ade 00000000 00000ae4
Under load:
0x059950: 00000000 00000c02 00000000 00000c14
0x059960: 00000000 00000c30 00000000 00000c22
More analysis shows that EPYC CPUs support up to 8 CCD temperature
sensors. EPYC 7601 supports three CCD temperature sensors. Unlike
Zen2 CPUs, the register space in Zen1 CPUs supports a maximum of four
sensors, so only search for a maximum of four sensors on Zen1 CPUs.
On top of that, in thm_10_0_sh_mask.h in the Linux kernel, we find
definitions for THM_DIE{1-3}_TEMP__VALID_MASK, set to 0x00000800, as well
as matching SMN addresses. This lets us conclude that bit 11 of the
respective registers is a valid bit. With this assumption, the temperature
offset is now 49 degrees C. This conveniently matches the documented
temperature offset for Tdie, again suggesting that above registers indeed
report temperatures sensor values. Assume that bit 11 is indeed a valid
bit, and add support for the additional sensors.
With this patch applied, output from 3970X (idle) looks as follows:
k10temp-pci-00c3
Adapter: PCI adapter
Tdie: +55.9°C
Tctl: +55.9°C
Tccd1: +39.8°C
Tccd3: +43.8°C
Tccd5: +43.8°C
Tccd7: +44.8°C
Tested-by: Michael Larabel <michael@phoronix.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Previously we did not call INIT_KFIFO() for aer_fifo. This leads to
kfifo_put() sometimes returning 0 (queue full) when in fact it is not.
It is easy to reproduce the problem by using aer-inject:
$ aer-inject -s :82:00.0 multiple-corr-nonfatal
The content of the multiple-corr-nonfatal file is as below:
AER
COR RCVR
HL 0 1 2 3
AER
UNCOR POISON_TLP
HL 4 5 6 7
Fixes: 27c1ce8bbe ("PCI/AER: Use kfifo for tracking events instead of reimplementing it")
Link: https://lore.kernel.org/r/1579767991-103898-1-git-send-email-liudongdong3@huawei.com
Signed-off-by: Dongdong Liu <liudongdong3@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
PCI error recovery will fail if any device under the Root Port doesn't have
an error_detected callback. Currently only the failure result is printed,
which is not enough to identify the driver that lacks the callback.
Log a message to identify the device with no error_detected callback.
[bhelgaas: tweak log message]
Link: https://lore.kernel.org/r/1576237474-32021-1-git-send-email-yangyicong@hisilicon.com
Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
From patch set cover letter:
The IMA subsystem supports measuring asymmetric keys when the key is
created or updated[1]. But keys created or updated before a custom IMA
policy is loaded are currently not measured. This includes keys added,
for instance, to either the .ima or .builtin_trusted_keys keyrings, which
happens early in the boot process.
Measuring the early boot keys, by design, requires loading a custom IMA
policy. This change adds support for queuing keys created or updated
before a custom IMA policy is loaded. The queued keys are processed when
a custom policy is loaded. Keys created or updated after a custom policy
is loaded are measured immediately (not queued). In the case when a
custom policy is not loaded within 5 minutes of IMA initialization, the
queued keys are freed.
[1] https://lore.kernel.org/linux-integrity/20191211164707.4698-1-nramas@linux.microsoft.com/
head is traversed using hlist_for_each_entry_rcu outside an RCU
read-side critical section but under the protection of dtab->index_lock.
Hence, add corresponding lockdep expression to silence false-positive
lockdep warnings, and harden RCU lists.
Fixes: 6f9d451ab1 ("xdp: Add devmap_hash map type for looking up devices by hashed index")
Signed-off-by: Amol Grover <frextrite@gmail.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Jesper Dangaard Brouer <brouer@redhat.com>
Acked-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/bpf/20200123120437.26506-1-frextrite@gmail.com
zynqmp_clk_divider_round_rate() returns actual divider value
after calculating from parent rate and desired rate, even though
that rate is not supported by single divider of hardware. It is
also possible that such divisor value can be achieved through 2
different dividers. As, Linux tries to set such divisor value(out
of range) in single divider set divider is getting failed.
Fix the same by computing best possible combination of two
divisors which provides more accurate clock rate.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Tejas Patel <tejas.patel@xilinx.com>
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Link: https://lkml.kernel.org/r/1575527759-26452-6-git-send-email-rajan.vaja@xilinx.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
To achieve best possible rate, maximum limit of divider is required
while computation. Get maximum supported divisor from firmware. To
maintain backward compatibility assign maximum possible value(0xFFFF)
if query for max divisor is not successful.
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Link: https://lkml.kernel.org/r/1575527759-26452-5-git-send-email-rajan.vaja@xilinx.com
Acked-by: Michal Simek <michal.simek@xilinx.com>
[sboyd@kernel.org: Remove else return and just return]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Convert the gpio-leds binding to DT schema format.
Drop the last example as the node name collides when built, and it doesn't
add much value.
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Convert the common LEDs properties bindings to a schema. As trigger source
providers are different nodes, we need to split trigger source properties
to a separate file.
Bindings for LED controllers can reference the common schema for the LED
child nodes:
patternProperties:
"^led@[0-4]":
type: object
allOf:
- $ref: common.yaml#
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: linux-leds@vger.kernel.org
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
The maximum Tdie or Tctl is not published for Ryzen CPUs. What is
known, however, is that the traditional value of 70 degrees C is no
longer correct. On top of that, the limit applies to Tctl, not to Tdie.
Displaying it in either context is meaningless, confusing, and wrong.
Stop doing it.
Tested-by: Brad Campbell <lists2009@fnarfbargle.com>
Tested-by: Holger Kiehl <holger.kiehl@dwd.de>
Tested-by: Michael Larabel <michael@phoronix.com>
Tested-by: Jonathan McDowell <noodles@earth.li>
Tested-by: Ken Moffat <zarniwhoop73@googlemail.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for devices XDPE12254, XDPE12284.
All these device support two pages.
The below lists of VOUT_MODE command readout with their related VID
protocols, Digital to Analog Converter steps, supported by these
devices:
VR12.0 mode, 5-mV DAC - 0x01;
VR12.5 mode, 10-mV DAC - 0x02;
IMVP9 mode, 5-mV DAC - 0x03;
AMD mode 6.25mV - 0x10.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Link: https://lore.kernel.org/r/20200113150841.17670-5-vadimp@mellanox.com
[groeck: Added missing break statement]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add support for VID protocol detection per page bases, instead of
detecting it based on "PMBU_VOUT" readout from page 0 for all the pages
supported by particular device.
The reason that some devices allows to configure different VID modes
per page within the same device.
Patch modifies the field "vrm_version" within the structure
"pmbus_driver_info" to be per page array.
Signed-off-by: Vadim Pasternak <vadimp@mellanox.com>
Link: https://lore.kernel.org/r/20200113150841.17670-2-vadimp@mellanox.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/hwmon/w83627ehf.c: In function 'w83627ehf_check_fan_inputs':
drivers/hwmon/w83627ehf.c:1296:24: warning:
variable 'fan4min' set but not used [-Wunused-but-set-variable]
commit 62000264cfa8 ("hwmon: (w83627ehf) remove nct6775 and nct6776 support")
left behind this unused variable.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20200108034514.50130-1-yuehaibing@huawei.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reading the temperature of ATA drives has been supported for years
by userspace tools such as smarttools or hddtemp. The downside of
such tools is that they need to run with super-user privilege, that
the temperatures are not reported by standard tools such as 'sensors'
or 'libsensors', and that drive temperatures are not available for use
in the kernel's thermal subsystem.
This driver solves this problem by adding support for reading the
temperature of ATA drives from the kernel using the hwmon API and
by adding a temperature zone for each drive.
With this driver, the hard disk temperature can be read using the
unprivileged 'sensors' application:
$ sensors drivetemp-scsi-1-0
drivetemp-scsi-1-0
Adapter: SCSI adapter
temp1: +23.0°C
or directly from sysfs:
$ grep . /sys/class/hwmon/hwmon9/{name,temp1_input}
/sys/class/hwmon/hwmon9/name:drivetemp
/sys/class/hwmon/hwmon9/temp1_input:23000
If the drive supports SCT transport and reports temperature limits,
those are reported as well.
drivetemp-scsi-0-0
Adapter: SCSI adapter
temp1: +27.0°C (low = +0.0°C, high = +60.0°C)
(crit low = -41.0°C, crit = +85.0°C)
(lowest = +23.0°C, highest = +34.0°C)
The driver attempts to use SCT Command Transport to read the drive
temperature. If the SCT Command Transport feature set is not available,
or if it does not report the drive temperature, drive temperatures may
be readable through SMART attributes. Since SMART attributes are not well
defined, this method is only used as fallback mechanism.
Cc: Chris Healy <cphealy@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Bart Van Assche <bvanassche@acm.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
