This mail is been writing to you because we have come to understand that
you have lost a lot of money all because you want to receive your fund
well note that all that have been put to a stop as the federal government of
Nigeria has promised to assist you with the sum of $5million in other to
compensate you and all you have to do is fill the below information s.
1 full name
2 home phone and cell phone number
3 occupation
4 amount that was lost by you
Send this and get back at once.
Warm regards
Femi
From: Guenter Roeck <linux(a)roeck-us.net>
[ upstream commit e5d21072054fbadf41cd56062a3a14e447e8c22b ]
The thermal subsystem registers a hwmon driver without providing
chip or sysfs group information. This is for legacy reasons and
would be difficult to change. At the same time, we want to enforce
that chip information is provided when registering a hwmon device
using hwmon_device_register_with_info(). To enable this, introduce
a special API for use only by the thermal subsystem.
Acked-by: Rafael J . Wysocki <rafael(a)kernel.org>
Signed-off-by: Guenter Roeck <linux(a)roeck-us.net>
---
drivers/hwmon/hwmon.c | 25 +++++++++++++++++++++++++
include/linux/hwmon.h | 3 +++
2 files changed, 28 insertions(+)
diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
index c73b93b9bb87..e8a9955e3683 100644
--- a/drivers/hwmon/hwmon.c
+++ b/drivers/hwmon/hwmon.c
@@ -743,6 +743,31 @@ hwmon_device_register_with_info(struct device *dev, const char *name,
}
EXPORT_SYMBOL_GPL(hwmon_device_register_with_info);
+/**
+ * hwmon_device_register_for_thermal - register hwmon device for thermal subsystem
+ * @dev: the parent device
+ * @name: hwmon name attribute
+ * @drvdata: driver data to attach to created device
+ *
+ * The use of this function is restricted. It is provided for legacy reasons
+ * and must only be called from the thermal subsystem.
+ *
+ * hwmon_device_unregister() must be called when the device is no
+ * longer needed.
+ *
+ * Returns the pointer to the new device.
+ */
+struct device *
+hwmon_device_register_for_thermal(struct device *dev, const char *name,
+ void *drvdata)
+{
+ if (!name || !dev)
+ return ERR_PTR(-EINVAL);
+
+ return __hwmon_device_register(dev, name, drvdata, NULL, NULL);
+}
+EXPORT_SYMBOL_GPL(hwmon_device_register_for_thermal);
+
/**
* hwmon_device_register - register w/ hwmon
* @dev: the device to register
diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
index 72579168189d..104c492959b9 100644
--- a/include/linux/hwmon.h
+++ b/include/linux/hwmon.h
@@ -408,6 +408,9 @@ hwmon_device_register_with_info(struct device *dev,
const struct hwmon_chip_info *info,
const struct attribute_group **extra_groups);
struct device *
+hwmon_device_register_for_thermal(struct device *dev, const char *name,
+ void *drvdata);
+struct device *
devm_hwmon_device_register_with_info(struct device *dev,
const char *name, void *drvdata,
const struct hwmon_chip_info *info,
--
2.25.1
--
Hi,
Are you currently open to work as our executive company representative
on contractual basis working remotely? If yes, we will be happy to
share more details. Looking forward to your response.
Regards,
This is the start of the stable review cycle for the 4.9.319 release.
There are 20 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Thu, 16 Jun 2022 18:37:02 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.319-rc…
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Linux 4.9.319-rc1
Josh Poimboeuf <jpoimboe(a)kernel.org>
x86/speculation/mmio: Print SMT warning
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
KVM: x86/speculation: Disable Fill buffer clear within guests
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Reuse SRBDS mitigation for SBDS
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/srbds: Update SRBDS mitigation selection
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enable CPU Fill buffer clearing on idle
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation: Add a common function for MD_CLEAR mitigation update
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug
Pawan Gupta <pawan.kumar.gupta(a)linux.intel.com>
Documentation: Add documentation for Processor MMIO Stale Data
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpu: Add another Alder Lake CPU to the Intel family
Tony Luck <tony.luck(a)intel.com>
x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family
Kan Liang <kan.liang(a)linux.intel.com>
x86/cpu: Add Comet Lake to the Intel CPU models header
Kan Liang <kan.liang(a)linux.intel.com>
x86/CPU: Add more Icelake model numbers
Rajneesh Bhardwaj <rajneesh.bhardwaj(a)linux.intel.com>
x86/CPU: Add Icelake model number
Rajneesh Bhardwaj <rajneesh.bhardwaj(a)intel.com>
x86/cpu: Add Cannonlake to Intel family
Zhang Rui <rui.zhang(a)intel.com>
x86/cpu: Add Jasper Lake to Intel family
Guenter Roeck <linux(a)roeck-us.net>
cpu/speculation: Add prototype for cpu_show_srbds()
Gayatri Kammela <gayatri.kammela(a)intel.com>
x86/cpu: Add Elkhart Lake to Intel family
-------------
Diffstat:
Documentation/ABI/testing/sysfs-devices-system-cpu | 1 +
Documentation/hw-vuln/index.rst | 1 +
.../hw-vuln/processor_mmio_stale_data.rst | 246 +++++++++++++++++++++
Documentation/kernel-parameters.txt | 36 +++
Makefile | 4 +-
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/intel-family.h | 25 +++
arch/x86/include/asm/msr-index.h | 25 +++
arch/x86/include/asm/nospec-branch.h | 2 +
arch/x86/kernel/cpu/bugs.c | 235 +++++++++++++++++---
arch/x86/kernel/cpu/common.c | 52 ++++-
arch/x86/kvm/vmx.c | 77 ++++++-
arch/x86/kvm/x86.c | 4 +
drivers/base/cpu.c | 8 +
include/linux/cpu.h | 4 +
15 files changed, 679 insertions(+), 42 deletions(-)
The IOMMU driver shares the pasid table for PCI alias devices. When the
RID2PASID entry of the shared pasid table has been filled by the first
device, the subsequent devices will encounter the "DMAR: Setup RID2PASID
failed" failure as the pasid entry has already been marked as present. As
the result, the IOMMU probing process will be aborted.
This fixes it by skipping RID2PASID setting if the pasid entry has been
populated. This works because the IOMMU core ensures that only the same
IOMMU domain can be attached to all PCI alias devices at the same time.
Therefore the subsequent devices just try to setup the RID2PASID entry
with the same domain, which is negligible. This also adds domain validity
checks for more confidence anyway.
Fixes: ef848b7e5a6a0 ("iommu/vt-d: Setup pasid entry for RID2PASID support")
Reported-by: Chenyi Qiang <chenyi.qiang(a)intel.com>
Cc: stable(a)vger.kernel.org
Signed-off-by: Lu Baolu <baolu.lu(a)linux.intel.com>
---
drivers/iommu/intel/pasid.c | 22 ++++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
Change log:
v2:
- Add domain validity check in RID2PASID entry setup.
diff --git a/drivers/iommu/intel/pasid.c b/drivers/iommu/intel/pasid.c
index cb4c1d0cf25c..4f3525f3346f 100644
--- a/drivers/iommu/intel/pasid.c
+++ b/drivers/iommu/intel/pasid.c
@@ -575,6 +575,19 @@ static inline int pasid_enable_wpe(struct pasid_entry *pte)
return 0;
};
+/*
+ * Return true if @pasid is RID2PASID and the domain @did has already
+ * been setup to the @pte. Otherwise, return false. PCI alias devices
+ * probably share the single RID2PASID pasid entry in the shared pasid
+ * table. It's reasonable that those devices try to set a share domain
+ * in their probe paths.
+ */
+static inline bool
+rid2pasid_domain_valid(struct pasid_entry *pte, u32 pasid, u16 did)
+{
+ return pasid == PASID_RID2PASID && pasid_get_domain_id(pte) == did;
+}
+
/*
* Set up the scalable mode pasid table entry for first only
* translation type.
@@ -595,9 +608,8 @@ int intel_pasid_setup_first_level(struct intel_iommu *iommu,
if (WARN_ON(!pte))
return -EINVAL;
- /* Caller must ensure PASID entry is not in use. */
if (pasid_pte_is_present(pte))
- return -EBUSY;
+ return rid2pasid_domain_valid(pte, pasid, did) ? 0 : -EBUSY;
pasid_clear_entry(pte);
@@ -698,9 +710,8 @@ int intel_pasid_setup_second_level(struct intel_iommu *iommu,
return -ENODEV;
}
- /* Caller must ensure PASID entry is not in use. */
if (pasid_pte_is_present(pte))
- return -EBUSY;
+ return rid2pasid_domain_valid(pte, pasid, did) ? 0 : -EBUSY;
pasid_clear_entry(pte);
pasid_set_domain_id(pte, did);
@@ -738,9 +749,8 @@ int intel_pasid_setup_pass_through(struct intel_iommu *iommu,
return -ENODEV;
}
- /* Caller must ensure PASID entry is not in use. */
if (pasid_pte_is_present(pte))
- return -EBUSY;
+ return rid2pasid_domain_valid(pte, pasid, did) ? 0 : -EBUSY;
pasid_clear_entry(pte);
pasid_set_domain_id(pte, did);
--
2.25.1