Re: [PATCH] mm: add prototype for __add_to_page_cache_locked()
On Tue, Dec 22, 2020 at 03:53:45PM -0800, Andrew Morton wrote:
> : A previous attempt to make this function static led to compilation
> : errors for a few architectures, because __add_to_page_cache_locked() is
> : referred to by BPF code.
Yes, but it's wrong, because it's not architecture dependent. It
depends on CONFIG_DEBUG_INFO_BTF
> > > +/*
> > > + * Any attempt to mark this function as static leads to build failure
> > > + * for few architectures. Adding a prototype to silence gcc warning.
> > > + */
> >
> > We don't need a comment here for this. The commit log is enough.
>
> I think it's OK - people do send patches which remove a prototype and
> also make the function static. A tree-wide grep would catch the bpf
> reference but I suspect people tend to grep for "foo(" rather then
> "foo".
... and the same wrong information is present here. If there's going to
be a comment here at least make it something informative like
/* Must be visible for error injection */
> > > +int __add_to_page_cache_locked(struct page *page, struct address_space
> > > *mapping,
> > > + pgoff_t offset, gfp_t gfp, void **shadowp);
> >
> > Please name that 'index', not 'offset'.
>
> I too prefer index over offset.
>
> X1:/usr/src/linux-5.10> grep -r "pgoff_t offset" . | wc -l
> 52
> X1:/usr/src/linux-5.10> grep -r "pgoff_t index" . | wc -l
> 250
>
> But renaming this arg should be a separate patch.
... but this is a new prototype. Prototype names don't have to match
the function name (and often don't ...)
> And I don't think we should be preparing large "rename offset to index"
> patches, please. The value/noise ratio is too low.
I'm only fixing them as I change those functions. I just object to
introducing new wrong ones.
Re: [PATCH v2, 02/17] dt-bindings: mediatek: add CLK_MM_DISP_CONFIG control description for mt8192 display
On Wed, 2020-12-16 at 23:17 +0800, Chun-Kuang Hu wrote: > Hi, Yongqiang: > > Yongqiang Niu 於 2020年12月12日 週六 下午12:12寫道： > > > > add CLK_MM_DISP_CONFIG control description for mt8192 displa > > display > > > > > Signed-off-by: Yongqiang Niu > > --- > > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 3 > > +++ > > 1 file changed, 3 insertions(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > > index 1972fa7..dfbec76 100644 > > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > > @@ -54,6 +54,9 @@ Required properties (all function blocks): > >DPI controller nodes have multiple clock inputs. These are documented in > >mediatek,dsi.txt and mediatek,dpi.txt, respectively. > >An exception is that the mt8183 mutex is always free running with no > > clocks property. > > + An exception is that the mt8192 display add 2 more > > clocks(CLK_MM_DISP_CONFIG, CLK_MM_26MHZ), > > + and these 2 clocks need enabled before display module work like mutex > > clock, so we add these > > + 2 clocks controled same with mutex clock. > > If every display module needs these two clock, add these two clock to > all the display module which need them. > > Regards, > Chun-Kuang. all display module work need mutex clock work on, but not add mutex clock into all display module > > > > > Required properties (DMA function blocks): > > - compatible: Should be one of > > -- > > 1.8.1.1.dirty > > ___ > > Linux-mediatek mailing list > > linux-media...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
[PATCH v13 01/15] s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated
The vfio_ap device driver registers a group notifier with VFIO when the
file descriptor for a VFIO mediated device for a KVM guest is opened to
receive notification that the KVM pointer is set (VFIO_GROUP_NOTIFY_SET_KVM
event). When the KVM pointer is set, the vfio_ap driver takes the
following actions:
1. Stashes the KVM pointer in the vfio_ap_mdev struct that holds the state
of the mediated device.
2. Calls the kvm_get_kvm() function to increment its reference counter.
3. Sets the function pointer to the function that handles interception of
the instruction that enables/disables interrupt processing.
4. Sets the masks in the KVM guest's CRYCB to pass AP resources through to
the guest.
In order to avoid memory leaks, when the notifier is called to receive
notification that the KVM pointer has been set to NULL, the vfio_ap device
driver should reverse the actions taken when the KVM pointer was set.
Fixes: 258287c994de ("s390: vfio-ap: implement mediated device open callback")
Cc: sta...@vger.kernel.org
Signed-off-by: Tony Krowiak
Reviewed-by: Halil Pasic
Reviewed-by: Cornelia Huck
---
drivers/s390/crypto/vfio_ap_ops.c | 49 ++-
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index e0bde8518745..7339043906cf 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -1037,19 +1037,14 @@ static int vfio_ap_mdev_set_kvm(struct ap_matrix_mdev
*matrix_mdev,
{
struct ap_matrix_mdev *m;
- mutex_lock(&matrix_dev->lock);
-
list_for_each_entry(m, &matrix_dev->mdev_list, node) {
- if ((m != matrix_mdev) && (m->kvm == kvm)) {
- mutex_unlock(&matrix_dev->lock);
+ if ((m != matrix_mdev) && (m->kvm == kvm))
return -EPERM;
- }
}
matrix_mdev->kvm = kvm;
kvm_get_kvm(kvm);
kvm->arch.crypto.pqap_hook = &matrix_mdev->pqap_hook;
- mutex_unlock(&matrix_dev->lock);
return 0;
}
@@ -1083,35 +1078,52 @@ static int vfio_ap_mdev_iommu_notifier(struct
notifier_block *nb,
return NOTIFY_DONE;
}
+static void vfio_ap_mdev_unset_kvm(struct ap_matrix_mdev *matrix_mdev)
+{
+ kvm_arch_crypto_clear_masks(matrix_mdev->kvm);
+ matrix_mdev->kvm->arch.crypto.pqap_hook = NULL;
+ vfio_ap_mdev_reset_queues(matrix_mdev->mdev);
+ kvm_put_kvm(matrix_mdev->kvm);
+ matrix_mdev->kvm = NULL;
+}
+
static int vfio_ap_mdev_group_notifier(struct notifier_block *nb,
unsigned long action, void *data)
{
- int ret;
+ int ret, notify_rc = NOTIFY_OK;
struct ap_matrix_mdev *matrix_mdev;
if (action != VFIO_GROUP_NOTIFY_SET_KVM)
return NOTIFY_OK;
matrix_mdev = container_of(nb, struct ap_matrix_mdev, group_notifier);
+ mutex_lock(&matrix_dev->lock);
if (!data) {
- matrix_mdev->kvm = NULL;
- return NOTIFY_OK;
+ if (matrix_mdev->kvm)
+ vfio_ap_mdev_unset_kvm(matrix_mdev);
+ goto notify_done;
}
ret = vfio_ap_mdev_set_kvm(matrix_mdev, data);
- if (ret)
- return NOTIFY_DONE;
+ if (ret) {
+ notify_rc = NOTIFY_DONE;
+ goto notify_done;
+ }
/* If there is no CRYCB pointer, then we can't copy the masks */
- if (!matrix_mdev->kvm->arch.crypto.crycbd)
- return NOTIFY_DONE;
+ if (!matrix_mdev->kvm->arch.crypto.crycbd) {
+ notify_rc = NOTIFY_DONE;
+ goto notify_done;
+ }
kvm_arch_crypto_set_masks(matrix_mdev->kvm, matrix_mdev->matrix.apm,
matrix_mdev->matrix.aqm,
matrix_mdev->matrix.adm);
- return NOTIFY_OK;
+notify_done:
+ mutex_unlock(&matrix_dev->lock);
+ return notify_rc;
}
static void vfio_ap_irq_disable_apqn(int apqn)
@@ -1222,13 +1234,8 @@ static void vfio_ap_mdev_release(struct mdev_device
*mdev)
struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
mutex_lock(&matrix_dev->lock);
- if (matrix_mdev->kvm) {
- kvm_arch_crypto_clear_masks(matrix_mdev->kvm);
- matrix_mdev->kvm->arch.crypto.pqap_hook = NULL;
- vfio_ap_mdev_reset_queues(mdev);
- kvm_put_kvm(matrix_mdev->kvm);
- matrix_mdev->kvm = NULL;
- }
+ if (matrix_mdev->kvm)
+ vfio_ap_mdev_unset_kvm(matrix_mdev);
mutex_unlock(&matrix_dev->lock);
vfio_unregister_notifier(mdev_dev(mdev), VFIO_IOMMU_NOTIFY,
--
2.21.1
Re: [PATCH v13 6/6] arm64: Add IMA log information in kimage used for kexec
Lakshmi Ramasubramanian writes: > Address and size of the buffer containing the IMA measurement log need > to be passed from the current kernel to the next kernel on kexec. > > Any existing "linux,ima-kexec-buffer" property in the device tree > needs to be removed and its corresponding memory reservation in > the currently running kernel needs to be freed. The address and > size of the current kernel's IMA measurement log need to be added > to the device tree's IMA kexec buffer node and memory for the buffer > needs to be reserved for the log to be carried over to the next kernel > on the kexec call. > > Add address and size fields to "struct kimage_arch" for ARM64 platform > to hold the address and size of the IMA measurement log buffer. Remove > any existing "linux,ima-kexec-buffer" property in the device tree and > free the corresponding memory reservation in the currently running > kernel. Add "linux,ima-kexec-buffer" property to the device tree and > reserve the memory for storing the IMA log that needs to be passed from > the current kernel to the next one. > > Update CONFIG_KEXEC_FILE to select CONFIG_HAVE_IMA_KEXEC to indicate > that the IMA measurement log information is present in the device tree > for ARM64. > > Co-developed-by: Prakhar Srivastava > Signed-off-by: Prakhar Srivastava > Signed-off-by: Lakshmi Ramasubramanian > --- > arch/arm64/Kconfig | 1 + > arch/arm64/include/asm/kexec.h | 5 + > 2 files changed, 6 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 1d466addb078..c85d18b1f2fd 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1094,6 +1094,7 @@ config KEXEC > config KEXEC_FILE > bool "kexec file based system call" > select KEXEC_CORE > + select HAVE_IMA_KEXEC > help > This is new version of kexec system call. This system call is > file based and takes file descriptors as system call argument As I suggested in the other email, this should be: select HAVE_IMA_KEXEC if IMA -- Thiago Jung Bauermann IBM Linux Technology Center
SDHCI: problem of RV_BOOT.bin run on pynq
When I run the RV_BOOT.bin, which is generated by riscv-pk with linux-5.9.4 as payload, on xilinx pynq-z2, I met the problem below: mmc0: Timeout waiting for hardware cmd interrupt. mmc0: sdhci: SDHCI REGISTER DUMP === mmc0: sdhci: Sys addr: 0x | Version: 0x8901 mmc0: sdhci: Blk size: 0x | Blk cnt: 0x mmc0: sdhci: Argument: 0x0c00 | Trn mode: 0x mmc0: sdhci: Present: 0x01ff0001 | Host ctl: 0x0001 mmc0: sdhci: Power: 0x000f | Blk gap: 0x mmc0: sdhci: Wake-up: 0x | Clock:0x4007 mmc0: sdhci: Timeout: 0x | Int stat: 0x00018000 mmc0: sdhci: Int enab: 0x00ff0083 | Sig enab: 0x00ff0083 mmc0: sdhci: ACmd stat: 0x | Slot int: 0x0001 mmc0: sdhci: Caps: 0x69ec0080 | Caps_1: 0x mmc0: sdhci: Cmd: 0x341a | Max curr: 0x0001 mmc0: sdhci: Resp[0]: 0x | Resp[1]: 0x mmc0: sdhci: Resp[2]: 0x | Resp[3]: 0x mmc0: sdhci: Host ctl2: 0x mmc0: sdhci: ADMA Err: 0x | ADMA Ptr: 0x mmc0: sdhci: Does anyone have any idea about this problem? Thanks a lot.
[PATCH v13 04/15] s390/vfio-ap: use new AP bus interface to search for queue devices
This patch refactors the vfio_ap device driver to use the AP bus's
ap_get_qdev() function to retrieve the vfio_ap_queue struct containing
information about a queue that is bound to the vfio_ap device driver.
The bus's ap_get_qdev() function retrieves the queue device from a
hashtable keyed by APQN. This is much more efficient than looping over
the list of devices attached to the AP bus by several orders of
magnitude.
Signed-off-by: Tony Krowiak
Reviewed-by: Halil Pasic
---
drivers/s390/crypto/vfio_ap_ops.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index a83d6e75361b..835c963ae16d 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -27,13 +27,6 @@
static int vfio_ap_mdev_reset_queues(struct mdev_device *mdev);
static struct vfio_ap_queue *vfio_ap_find_queue(int apqn);
-static int match_apqn(struct device *dev, const void *data)
-{
- struct vfio_ap_queue *q = dev_get_drvdata(dev);
-
- return (q->apqn == *(int *)(data)) ? 1 : 0;
-}
-
/**
* vfio_ap_get_queue: Retrieve a queue with a specific APQN from a list
* @matrix_mdev: the associated mediated matrix
@@ -49,7 +42,7 @@ static struct vfio_ap_queue *vfio_ap_get_queue(
struct ap_matrix_mdev *matrix_mdev,
int apqn)
{
- struct vfio_ap_queue *q;
+ struct vfio_ap_queue *q = NULL;
if (!test_bit_inv(AP_QID_CARD(apqn), matrix_mdev->matrix.apm))
return NULL;
@@ -1124,15 +1117,17 @@ static int vfio_ap_mdev_group_notifier(struct
notifier_block *nb,
static struct vfio_ap_queue *vfio_ap_find_queue(int apqn)
{
- struct device *dev;
+ struct ap_queue *queue;
struct vfio_ap_queue *q = NULL;
- dev = driver_find_device(&matrix_dev->vfio_ap_drv->driver, NULL,
-&apqn, match_apqn);
- if (dev) {
- q = dev_get_drvdata(dev);
- put_device(dev);
- }
+ queue = ap_get_qdev(apqn);
+ if (!queue)
+ return NULL;
+
+ put_device(&queue->ap_dev.device);
+
+ if (queue->ap_dev.device.driver == &matrix_dev->vfio_ap_drv->driver)
+ q = dev_get_drvdata(&queue->ap_dev.device);
return q;
}
--
2.21.1
[PATCH v13 05/15] s390/vfio-ap: manage link between queue struct and matrix mdev
Let's create links between each queue device bound to the vfio_ap device
driver and the matrix mdev to which the queue's APQN is assigned. The idea
is to facilitate efficient retrieval of the objects representing the queue
devices and matrix mdevs as well as to verify that a queue assigned to
a matrix mdev is bound to the driver.
The links will be created as follows:
* When the queue device is probed, if its APQN is assigned to a matrix
mdev, the structures representing the queue device and the matrix mdev
will be linked.
* When an adapter or domain is assigned to a matrix mdev, for each new
APQN assigned that references a queue device bound to the vfio_ap
device driver, the structures representing the queue device and the
matrix mdev will be linked.
The links will be removed as follows:
* When the queue device is removed, if its APQN is assigned to a matrix
mdev, the structures representing the queue device and the matrix mdev
will be unlinked.
* When an adapter or domain is unassigned from a matrix mdev, for each
APQN unassigned that references a queue device bound to the vfio_ap
device driver, the structures representing the queue device and the
matrix mdev will be unlinked.
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_ops.c | 140 +-
drivers/s390/crypto/vfio_ap_private.h | 3 +
2 files changed, 117 insertions(+), 26 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 835c963ae16d..cdcc6378b4a5 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -27,33 +27,17 @@
static int vfio_ap_mdev_reset_queues(struct mdev_device *mdev);
static struct vfio_ap_queue *vfio_ap_find_queue(int apqn);
-/**
- * vfio_ap_get_queue: Retrieve a queue with a specific APQN from a list
- * @matrix_mdev: the associated mediated matrix
- * @apqn: The queue APQN
- *
- * Retrieve a queue with a specific APQN from the list of the
- * devices of the vfio_ap_drv.
- * Verify that the APID and the APQI are set in the matrix.
- *
- * Returns the pointer to the associated vfio_ap_queue
- */
-static struct vfio_ap_queue *vfio_ap_get_queue(
- struct ap_matrix_mdev *matrix_mdev,
- int apqn)
+static struct vfio_ap_queue *
+vfio_ap_mdev_get_queue(struct ap_matrix_mdev *matrix_mdev, unsigned long apqn)
{
- struct vfio_ap_queue *q = NULL;
-
- if (!test_bit_inv(AP_QID_CARD(apqn), matrix_mdev->matrix.apm))
- return NULL;
- if (!test_bit_inv(AP_QID_QUEUE(apqn), matrix_mdev->matrix.aqm))
- return NULL;
+ struct vfio_ap_queue *q;
- q = vfio_ap_find_queue(apqn);
- if (q)
- q->matrix_mdev = matrix_mdev;
+ hash_for_each_possible(matrix_mdev->qtable, q, mdev_qnode, apqn) {
+ if (q && (q->apqn == apqn))
+ return q;
+ }
- return q;
+ return NULL;
}
/**
@@ -166,7 +150,6 @@ static struct ap_queue_status vfio_ap_irq_disable(struct
vfio_ap_queue *q)
status.response_code);
end_free:
vfio_ap_free_aqic_resources(q);
- q->matrix_mdev = NULL;
return status;
}
@@ -282,7 +265,7 @@ static int handle_pqap(struct kvm_vcpu *vcpu)
matrix_mdev = container_of(vcpu->kvm->arch.crypto.pqap_hook,
struct ap_matrix_mdev, pqap_hook);
- q = vfio_ap_get_queue(matrix_mdev, apqn);
+ q = vfio_ap_mdev_get_queue(matrix_mdev, apqn);
if (!q)
goto out_unlock;
@@ -325,6 +308,7 @@ static int vfio_ap_mdev_create(struct kobject *kobj, struct
mdev_device *mdev)
matrix_mdev->mdev = mdev;
vfio_ap_matrix_init(&matrix_dev->info, &matrix_mdev->matrix);
+ hash_init(matrix_mdev->qtable);
mdev_set_drvdata(mdev, matrix_mdev);
matrix_mdev->pqap_hook.hook = handle_pqap;
matrix_mdev->pqap_hook.owner = THIS_MODULE;
@@ -553,6 +537,50 @@ static int vfio_ap_mdev_verify_no_sharing(struct
ap_matrix_mdev *matrix_mdev)
return 0;
}
+static void vfio_ap_mdev_link_queue(struct ap_matrix_mdev *matrix_mdev,
+ struct vfio_ap_queue *q)
+{
+ if (q) {
+ q->matrix_mdev = matrix_mdev;
+ hash_add(matrix_mdev->qtable,
+&q->mdev_qnode, q->apqn);
+ }
+}
+
+static void vfio_ap_mdev_link_apqn(struct ap_matrix_mdev *matrix_mdev, int
apqn)
+{
+ struct vfio_ap_queue *q;
+
+ q = vfio_ap_find_queue(apqn);
+ vfio_ap_mdev_link_queue(matrix_mdev, q);
+}
+
+static void vfio_ap_mdev_unlink_queue(struct vfio_ap_queue *q)
+{
+ if (q) {
+ q->matrix_mdev = NULL;
+ hash_del(&q->mdev_qnode);
+ }
+}
+
+static void vfio_ap_mdev_unlink_apqn(int apqn)
+{
+ struct vfio_ap_queue *q;
+
[PATCH v13 08/15] s390/vfio-ap: sysfs attribute to display the guest's matrix
The matrix of adapters and domains configured in a guest's APCB may
differ from the matrix of adapters and domains assigned to the matrix mdev,
so this patch introduces a sysfs attribute to display the matrix of
adapters and domains that are or will be assigned to the APCB of a guest
that is or will be using the matrix mdev. For a matrix mdev denoted by
$uuid, the guest matrix can be displayed as follows:
cat /sys/devices/vfio_ap/matrix/$uuid/guest_matrix
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_ops.c | 51 ++-
1 file changed, 37 insertions(+), 14 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 44b3a81cadfb..1b1d5975ee0e 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -894,29 +894,24 @@ static ssize_t control_domains_show(struct device *dev,
}
static DEVICE_ATTR_RO(control_domains);
-static ssize_t matrix_show(struct device *dev, struct device_attribute *attr,
- char *buf)
+static ssize_t vfio_ap_mdev_matrix_show(struct ap_matrix *matrix, char *buf)
{
- struct mdev_device *mdev = mdev_from_dev(dev);
- struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
char *bufpos = buf;
unsigned long apid;
unsigned long apqi;
unsigned long apid1;
unsigned long apqi1;
- unsigned long napm_bits = matrix_mdev->matrix.apm_max + 1;
- unsigned long naqm_bits = matrix_mdev->matrix.aqm_max + 1;
+ unsigned long napm_bits = matrix->apm_max + 1;
+ unsigned long naqm_bits = matrix->aqm_max + 1;
int nchars = 0;
int n;
- apid1 = find_first_bit_inv(matrix_mdev->matrix.apm, napm_bits);
- apqi1 = find_first_bit_inv(matrix_mdev->matrix.aqm, naqm_bits);
-
- mutex_lock(&matrix_dev->lock);
+ apid1 = find_first_bit_inv(matrix->apm, napm_bits);
+ apqi1 = find_first_bit_inv(matrix->aqm, naqm_bits);
if ((apid1 < napm_bits) && (apqi1 < naqm_bits)) {
- for_each_set_bit_inv(apid, matrix_mdev->matrix.apm, napm_bits) {
- for_each_set_bit_inv(apqi, matrix_mdev->matrix.aqm,
+ for_each_set_bit_inv(apid, matrix->apm, napm_bits) {
+ for_each_set_bit_inv(apqi, matrix->aqm,
naqm_bits) {
n = sprintf(bufpos, "%02lx.%04lx\n", apid,
apqi);
@@ -925,25 +920,52 @@ static ssize_t matrix_show(struct device *dev, struct
device_attribute *attr,
}
}
} else if (apid1 < napm_bits) {
- for_each_set_bit_inv(apid, matrix_mdev->matrix.apm, napm_bits) {
+ for_each_set_bit_inv(apid, matrix->apm, napm_bits) {
n = sprintf(bufpos, "%02lx.\n", apid);
bufpos += n;
nchars += n;
}
} else if (apqi1 < naqm_bits) {
- for_each_set_bit_inv(apqi, matrix_mdev->matrix.aqm, naqm_bits) {
+ for_each_set_bit_inv(apqi, matrix->aqm, naqm_bits) {
n = sprintf(bufpos, ".%04lx\n", apqi);
bufpos += n;
nchars += n;
}
}
+ return nchars;
+}
+
+static ssize_t matrix_show(struct device *dev, struct device_attribute *attr,
+ char *buf)
+{
+ ssize_t nchars;
+ struct mdev_device *mdev = mdev_from_dev(dev);
+ struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
+
+ mutex_lock(&matrix_dev->lock);
+ nchars = vfio_ap_mdev_matrix_show(&matrix_mdev->matrix, buf);
mutex_unlock(&matrix_dev->lock);
return nchars;
}
static DEVICE_ATTR_RO(matrix);
+static ssize_t guest_matrix_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+ ssize_t nchars;
+ struct mdev_device *mdev = mdev_from_dev(dev);
+ struct ap_matrix_mdev *matrix_mdev = mdev_get_drvdata(mdev);
+
+ mutex_lock(&matrix_dev->lock);
+ nchars = vfio_ap_mdev_matrix_show(&matrix_mdev->shadow_apcb, buf);
+ mutex_unlock(&matrix_dev->lock);
+
+ return nchars;
+}
+static DEVICE_ATTR_RO(guest_matrix);
+
static struct attribute *vfio_ap_mdev_attrs[] = {
&dev_attr_assign_adapter.attr,
&dev_attr_unassign_adapter.attr,
@@ -953,6 +975,7 @@ static struct attribute *vfio_ap_mdev_attrs[] = {
&dev_attr_unassign_control_domain.attr,
&dev_attr_control_domains.attr,
&dev_attr_matrix.attr,
+ &dev_attr_guest_matrix.attr,
NULL,
};
--
2.21.1
[PATCH v13 06/15] s390/vfio-ap: allow assignment of unavailable AP queues to mdev device
The current implementation does not allow assignment of an AP adapter or
domain to an mdev device if each APQN resulting from the assignment
does not reference an AP queue device that is bound to the vfio_ap device
driver. This patch allows assignment of AP resources to the matrix mdev as
long as the APQNs resulting from the assignment:
1. Are not reserved by the AP BUS for use by the zcrypt device drivers.
2. Are not assigned to another matrix mdev.
The rationale behind this is twofold:
1. The AP architecture does not preclude assignment of APQNs to an AP
configuration that are not available to the system.
2. APQNs that do not reference a queue device bound to the vfio_ap
device driver will not be assigned to the guest's CRYCB, so the
guest will not get access to queues not bound to the vfio_ap driver.
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_ops.c | 241 --
1 file changed, 62 insertions(+), 179 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index cdcc6378b4a5..2d58b39977be 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -379,134 +379,37 @@ static struct attribute_group
*vfio_ap_mdev_type_groups[] = {
NULL,
};
-struct vfio_ap_queue_reserved {
- unsigned long *apid;
- unsigned long *apqi;
- bool reserved;
-};
+#define MDEV_SHARING_ERR "Userspace may not re-assign queue %02lx.%04lx " \
+"already assigned to %s"
-/**
- * vfio_ap_has_queue
- *
- * @dev: an AP queue device
- * @data: a struct vfio_ap_queue_reserved reference
- *
- * Flags whether the AP queue device (@dev) has a queue ID containing the APQN,
- * apid or apqi specified in @data:
- *
- * - If @data contains both an apid and apqi value, then @data will be flagged
- * as reserved if the APID and APQI fields for the AP queue device matches
- *
- * - If @data contains only an apid value, @data will be flagged as
- * reserved if the APID field in the AP queue device matches
- *
- * - If @data contains only an apqi value, @data will be flagged as
- * reserved if the APQI field in the AP queue device matches
- *
- * Returns 0 to indicate the input to function succeeded. Returns -EINVAL if
- * @data does not contain either an apid or apqi.
- */
-static int vfio_ap_has_queue(struct device *dev, void *data)
+static void vfio_ap_mdev_log_sharing_err(const char *mdev_name,
+unsigned long *apm,
+unsigned long *aqm)
{
- struct vfio_ap_queue_reserved *qres = data;
- struct ap_queue *ap_queue = to_ap_queue(dev);
- ap_qid_t qid;
- unsigned long id;
-
- if (qres->apid && qres->apqi) {
- qid = AP_MKQID(*qres->apid, *qres->apqi);
- if (qid == ap_queue->qid)
- qres->reserved = true;
- } else if (qres->apid && !qres->apqi) {
- id = AP_QID_CARD(ap_queue->qid);
- if (id == *qres->apid)
- qres->reserved = true;
- } else if (!qres->apid && qres->apqi) {
- id = AP_QID_QUEUE(ap_queue->qid);
- if (id == *qres->apqi)
- qres->reserved = true;
- } else {
- return -EINVAL;
- }
+ unsigned long apid, apqi;
- return 0;
-}
-
-/**
- * vfio_ap_verify_queue_reserved
- *
- * @matrix_dev: a mediated matrix device
- * @apid: an AP adapter ID
- * @apqi: an AP queue index
- *
- * Verifies that the AP queue with @apid/@apqi is reserved by the VFIO AP
device
- * driver according to the following rules:
- *
- * - If both @apid and @apqi are not NULL, then there must be an AP queue
- * device bound to the vfio_ap driver with the APQN identified by @apid and
- * @apqi
- *
- * - If only @apid is not NULL, then there must be an AP queue device bound
- * to the vfio_ap driver with an APQN containing @apid
- *
- * - If only @apqi is not NULL, then there must be an AP queue device bound
- * to the vfio_ap driver with an APQN containing @apqi
- *
- * Returns 0 if the AP queue is reserved; otherwise, returns -EADDRNOTAVAIL.
- */
-static int vfio_ap_verify_queue_reserved(unsigned long *apid,
-unsigned long *apqi)
-{
- int ret;
- struct vfio_ap_queue_reserved qres;
-
- qres.apid = apid;
- qres.apqi = apqi;
- qres.reserved = false;
-
- ret = driver_for_each_device(&matrix_dev->vfio_ap_drv->driver, NULL,
-&qres, vfio_ap_has_queue);
- if (ret)
- return ret;
-
- if (qres.reserved)
- return 0;
-
- return -EADDRNOTAVAIL;
-}
-
-static int
-vfio_ap_mdev_verify_queues_reserved_for_apid(struct ap_matrix_mdev
*matrix_mdev,
-unsigned long apid)
-{
- int ret;
-
[PATCH v13 10/15] s390/zcrypt: driver callback to indicate resource in use
Introduces a new driver callback to prevent a root user from unbinding
an AP queue from its device driver if the queue is in use. The callback
will be invoked whenever a change to the AP bus's sysfs apmask or aqmask
attributes would result in one or more AP queues being removed from its
driver. If the callback responds in the affirmative for any driver
queried, the change to the apmask or aqmask will be rejected with a device
busy error.
For this patch, only non-default drivers will be queried. Currently,
there is only one non-default driver, the vfio_ap device driver. The
vfio_ap device driver facilitates pass-through of an AP queue to a
guest. The idea here is that a guest may be administered by a different
sysadmin than the host and we don't want AP resources to unexpectedly
disappear from a guest's AP configuration (i.e., adapters and domains
assigned to the matrix mdev). This will enforce the proper procedure for
removing AP resources intended for guest usage which is to
first unassign them from the matrix mdev, then unbind them from the
vfio_ap device driver.
Signed-off-by: Tony Krowiak
Reviewed-by: Harald Freudenberger
---
drivers/s390/crypto/ap_bus.c | 160 ---
drivers/s390/crypto/ap_bus.h | 4 +
2 files changed, 154 insertions(+), 10 deletions(-)
diff --git a/drivers/s390/crypto/ap_bus.c b/drivers/s390/crypto/ap_bus.c
index 2758d05a802d..7d8add952dd6 100644
--- a/drivers/s390/crypto/ap_bus.c
+++ b/drivers/s390/crypto/ap_bus.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include "ap_bus.h"
#include "ap_debug.h"
@@ -1006,6 +1007,23 @@ static int modify_bitmap(const char *str, unsigned long
*bitmap, int bits)
return 0;
}
+static int ap_parse_bitmap_str(const char *str, unsigned long *bitmap, int
bits,
+ unsigned long *newmap)
+{
+ unsigned long size;
+ int rc;
+
+ size = BITS_TO_LONGS(bits)*sizeof(unsigned long);
+ if (*str == '+' || *str == '-') {
+ memcpy(newmap, bitmap, size);
+ rc = modify_bitmap(str, newmap, bits);
+ } else {
+ memset(newmap, 0, size);
+ rc = hex2bitmap(str, newmap, bits);
+ }
+ return rc;
+}
+
int ap_parse_mask_str(const char *str,
unsigned long *bitmap, int bits,
struct mutex *lock)
@@ -1025,14 +1043,7 @@ int ap_parse_mask_str(const char *str,
kfree(newmap);
return -ERESTARTSYS;
}
-
- if (*str == '+' || *str == '-') {
- memcpy(newmap, bitmap, size);
- rc = modify_bitmap(str, newmap, bits);
- } else {
- memset(newmap, 0, size);
- rc = hex2bitmap(str, newmap, bits);
- }
+ rc = ap_parse_bitmap_str(str, bitmap, bits, newmap);
if (rc == 0)
memcpy(bitmap, newmap, size);
mutex_unlock(lock);
@@ -1224,12 +1235,76 @@ static ssize_t apmask_show(struct bus_type *bus, char
*buf)
return rc;
}
+static int __verify_card_reservations(struct device_driver *drv, void *data)
+{
+ int rc = 0;
+ struct ap_driver *ap_drv = to_ap_drv(drv);
+ unsigned long *newapm = (unsigned long *)data;
+
+ /*
+* No need to verify whether the driver is using the queues if it is the
+* default driver.
+*/
+ if (ap_drv->flags & AP_DRIVER_FLAG_DEFAULT)
+ return 0;
+
+ /*
+* increase the driver's module refcounter to be sure it is not
+* going away when we invoke the callback function.
+*/
+ if (!try_module_get(drv->owner))
+ return 0;
+
+ if (ap_drv->in_use) {
+ rc = ap_drv->in_use(newapm, ap_perms.aqm);
+ if (rc)
+ return rc;
+ }
+
+ /* release the driver's module */
+ module_put(drv->owner);
+
+ return rc;
+}
+
+static int apmask_commit(unsigned long *newapm)
+{
+ int rc;
+ unsigned long reserved[BITS_TO_LONGS(AP_DEVICES)];
+
+ /*
+* Check if any bits in the apmask have been set which will
+* result in queues being removed from non-default drivers
+*/
+ if (bitmap_andnot(reserved, newapm, ap_perms.apm, AP_DEVICES)) {
+ rc = bus_for_each_drv(&ap_bus_type, NULL, reserved,
+ __verify_card_reservations);
+ if (rc)
+ return rc;
+ }
+
+ memcpy(ap_perms.apm, newapm, APMASKSIZE);
+
+ return 0;
+}
+
static ssize_t apmask_store(struct bus_type *bus, const char *buf,
size_t count)
{
int rc;
+ DECLARE_BITMAP(newapm, AP_DEVICES);
+
+ if (mutex_lock_interruptible(&ap_perms_mutex))
+ return -ERESTARTSYS;
- rc = ap_parse_mask_str(buf, ap_perms.apm, AP_DEVICES, &ap_perms_mutex);
+ rc = ap_parse_bitmap_str(buf,
[PATCH v13 07/15] s390/vfio-ap: introduce shadow APCB
The APCB is a field within the CRYCB that provides the AP configuration
to a KVM guest. Let's introduce a shadow copy of the KVM guest's APCB and
maintain it for the lifespan of the guest.
Signed-off-by: Tony Krowiak
Reviewed-by: Halil Pasic
---
drivers/s390/crypto/vfio_ap_ops.c | 15 +++
drivers/s390/crypto/vfio_ap_private.h | 2 ++
2 files changed, 17 insertions(+)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 2d58b39977be..44b3a81cadfb 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -293,6 +293,20 @@ static void vfio_ap_matrix_init(struct ap_config_info
*info,
matrix->adm_max = info->apxa ? info->Nd : 15;
}
+static bool vfio_ap_mdev_has_crycb(struct ap_matrix_mdev *matrix_mdev)
+{
+ return (matrix_mdev->kvm && matrix_mdev->kvm->arch.crypto.crycbd);
+}
+
+static void vfio_ap_mdev_commit_shadow_apcb(struct ap_matrix_mdev *matrix_mdev)
+{
+ if (vfio_ap_mdev_has_crycb(matrix_mdev))
+ kvm_arch_crypto_set_masks(matrix_mdev->kvm,
+ matrix_mdev->shadow_apcb.apm,
+ matrix_mdev->shadow_apcb.aqm,
+ matrix_mdev->shadow_apcb.adm);
+}
+
static int vfio_ap_mdev_create(struct kobject *kobj, struct mdev_device *mdev)
{
struct ap_matrix_mdev *matrix_mdev;
@@ -308,6 +322,7 @@ static int vfio_ap_mdev_create(struct kobject *kobj, struct
mdev_device *mdev)
matrix_mdev->mdev = mdev;
vfio_ap_matrix_init(&matrix_dev->info, &matrix_mdev->matrix);
+ vfio_ap_matrix_init(&matrix_dev->info, &matrix_mdev->shadow_apcb);
hash_init(matrix_mdev->qtable);
mdev_set_drvdata(mdev, matrix_mdev);
matrix_mdev->pqap_hook.hook = handle_pqap;
diff --git a/drivers/s390/crypto/vfio_ap_private.h
b/drivers/s390/crypto/vfio_ap_private.h
index 4e5cc72fc0db..d2d26ba18602 100644
--- a/drivers/s390/crypto/vfio_ap_private.h
+++ b/drivers/s390/crypto/vfio_ap_private.h
@@ -75,6 +75,7 @@ struct ap_matrix {
* @list: allows the ap_matrix_mdev struct to be added to a list
* @matrix:the adapters, usage domains and control domains assigned to the
* mediated matrix device.
+ * @shadow_apcb:the shadow copy of the APCB field of the KVM guest's CRYCB
* @group_notifier: notifier block used for specifying callback function for
* handling the VFIO_GROUP_NOTIFY_SET_KVM event
* @kvm: the struct holding guest's state
@@ -82,6 +83,7 @@ struct ap_matrix {
struct ap_matrix_mdev {
struct list_head node;
struct ap_matrix matrix;
+ struct ap_matrix shadow_apcb;
struct notifier_block group_notifier;
struct notifier_block iommu_notifier;
struct kvm *kvm;
--
2.21.1
[PATCH v13 14/15] s390/vfio-ap: handle AP bus scan completed notification
Implements the driver callback invoked by the AP bus when the AP bus
scan has completed. Since this callback is invoked after binding the newly
added devices to their respective device drivers, the vfio_ap driver will
attempt to hot plug the adapters, domains and control domains into each
guest using the matrix mdev to which they are assigned. Keep in mind that
an adapter or domain can be plugged in only if:
* Each APQN derived from the newly added APID of the adapter and the APQIs
already assigned to the guest's APCB references an AP queue device bound
to the vfio_ap driver
* Each APQN derived from the newly added APQI of the domain and the APIDs
already assigned to the guest's APCB references an AP queue device bound
to the vfio_ap driver
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_drv.c | 1 +
drivers/s390/crypto/vfio_ap_ops.c | 21 +
drivers/s390/crypto/vfio_ap_private.h | 2 ++
3 files changed, 24 insertions(+)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c
b/drivers/s390/crypto/vfio_ap_drv.c
index 2029d8392416..075495fc44c0 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -149,6 +149,7 @@ static int __init vfio_ap_init(void)
vfio_ap_drv.remove = vfio_ap_mdev_remove_queue;
vfio_ap_drv.in_use = vfio_ap_mdev_resource_in_use;
vfio_ap_drv.on_config_changed = vfio_ap_on_cfg_changed;
+ vfio_ap_drv.on_scan_complete = vfio_ap_on_scan_complete;
vfio_ap_drv.ids = ap_queue_ids;
ret = ap_driver_register(&vfio_ap_drv, THIS_MODULE, VFIO_AP_DRV_NAME);
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 8bbbd1dc7546..b8ed01297812 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -1592,3 +1592,24 @@ void vfio_ap_on_cfg_changed(struct ap_config_info
*new_config_info,
vfio_ap_mdev_on_cfg_add();
mutex_unlock(&matrix_dev->lock);
}
+
+void vfio_ap_on_scan_complete(struct ap_config_info *new_config_info,
+ struct ap_config_info *old_config_info)
+{
+ struct ap_matrix_mdev *matrix_mdev;
+
+ mutex_lock(&matrix_dev->lock);
+ list_for_each_entry(matrix_mdev, &matrix_dev->mdev_list, node) {
+ if (bitmap_intersects(matrix_mdev->matrix.apm,
+ matrix_dev->ap_add, AP_DEVICES) ||
+ bitmap_intersects(matrix_mdev->matrix.aqm,
+ matrix_dev->aq_add, AP_DOMAINS) ||
+ bitmap_intersects(matrix_mdev->matrix.adm,
+ matrix_dev->ad_add, AP_DOMAINS))
+ vfio_ap_mdev_refresh_apcb(matrix_mdev);
+ }
+
+ bitmap_clear(matrix_dev->ap_add, 0, AP_DEVICES);
+ bitmap_clear(matrix_dev->aq_add, 0, AP_DOMAINS);
+ mutex_unlock(&matrix_dev->lock);
+}
diff --git a/drivers/s390/crypto/vfio_ap_private.h
b/drivers/s390/crypto/vfio_ap_private.h
index b99b68968447..7f0f7c92e686 100644
--- a/drivers/s390/crypto/vfio_ap_private.h
+++ b/drivers/s390/crypto/vfio_ap_private.h
@@ -117,5 +117,7 @@ int vfio_ap_mdev_resource_in_use(unsigned long *apm,
unsigned long *aqm);
void vfio_ap_on_cfg_changed(struct ap_config_info *new_config_info,
struct ap_config_info *old_config_info);
+void vfio_ap_on_scan_complete(struct ap_config_info *new_config_info,
+ struct ap_config_info *old_config_info);
#endif /* _VFIO_AP_PRIVATE_H_ */
--
2.21.1
[PATCH v13 09/15] s390/vfio-ap: allow hot plug/unplug of AP resources using mdev device
Let's allow adapters, domains and control domains to be hot plugged into
and hot unplugged from a KVM guest using a matrix mdev when:
* The adapter, domain or control domain is assigned to or unassigned from
the matrix mdev
* A queue device with an APQN assigned to the matrix mdev is bound to or
unbound from the vfio_ap device driver.
Whenever an assignment or unassignment of an adapter, domain or control
domain is performed as well as when a bind or unbind of a queue device
is executed, the AP control block (APCB) that supplies the AP configuration
to a guest is first refreshed. The APCB is refreshed by copying the AP
configuration from the mdev's matrix to the APCB, then filtering the
APCB according to the following rules:
* The APID of each adapter and the APQI of each domain that is not in the
host's AP configuration is filtered out.
* The APID of each adapter comprising an APQN that does not reference a
queue device bound to the vfio_ap device driver is filtered. The APQNs
are derived from the Cartesian product of the APID of each adapter and
APQI of each domain assigned to the mdev's matrix.
After refreshing the APCB, if the mdev is in use by a KVM guest, it is
hot plugged into the guest to provide access to dynamically provide
access to the adapters, domains and control domains provided via the
newly refreshed APCB.
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_ops.c | 143 --
1 file changed, 118 insertions(+), 25 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 1b1d5975ee0e..843862c88379 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -307,6 +307,88 @@ static void vfio_ap_mdev_commit_shadow_apcb(struct
ap_matrix_mdev *matrix_mdev)
matrix_mdev->shadow_apcb.adm);
}
+static void vfio_ap_mdev_filter_apcb(struct ap_matrix_mdev *matrix_mdev,
+struct ap_matrix *shadow_apcb)
+{
+ int ret;
+ unsigned long apid, apqi, apqn;
+
+ ret = ap_qci(&matrix_dev->info);
+ if (ret)
+ return;
+
+ memcpy(shadow_apcb, &matrix_mdev->matrix, sizeof(struct ap_matrix));
+
+ /*
+* Copy the adapters, domains and control domains to the shadow_apcb
+* from the matrix mdev, but only those that are assigned to the host's
+* AP configuration.
+*/
+ bitmap_and(shadow_apcb->apm, matrix_mdev->matrix.apm,
+ (unsigned long *)matrix_dev->info.apm, AP_DEVICES);
+ bitmap_and(shadow_apcb->aqm, matrix_mdev->matrix.aqm,
+ (unsigned long *)matrix_dev->info.aqm, AP_DOMAINS);
+ bitmap_and(shadow_apcb->adm, matrix_mdev->matrix.adm,
+ (unsigned long *)matrix_dev->info.adm, AP_DOMAINS);
+
+ /* If there are no APQNs assigned, then filtering them be unnecessary */
+ if (bitmap_empty(shadow_apcb->apm, AP_DEVICES)) {
+ if (!bitmap_empty(shadow_apcb->aqm, AP_DOMAINS))
+ bitmap_clear(shadow_apcb->aqm, 0, AP_DOMAINS);
+ return;
+ } else if (bitmap_empty(shadow_apcb->aqm, AP_DOMAINS)) {
+ if (!bitmap_empty(shadow_apcb->apm, AP_DEVICES))
+ bitmap_clear(shadow_apcb->apm, 0, AP_DEVICES);
+ return;
+ }
+
+ for_each_set_bit_inv(apid, shadow_apcb->apm, AP_DEVICES) {
+ for_each_set_bit_inv(apqi, shadow_apcb->aqm, AP_DOMAINS) {
+ /*
+* If the APQN is not bound to the vfio_ap device
+* driver, then we can't assign it to the guest's
+* AP configuration. The AP architecture won't
+* allow filtering of a single APQN, so if we're
+* filtering APIDs, then filter the APID; otherwise,
+* filter the APQI.
+*/
+ apqn = AP_MKQID(apid, apqi);
+ if (!vfio_ap_mdev_get_queue(matrix_mdev, apqn)) {
+ clear_bit_inv(apid, shadow_apcb->apm);
+ break;
+ }
+ }
+ }
+}
+
+/**
+ * vfio_ap_mdev_refresh_apcb
+ *
+ * Filter APQNs assigned to the matrix mdev that do not reference an AP queue
+ * device bound to the vfio_ap device driver.
+ *
+ * @matrix_mdev: the matrix mdev whose AP configuration is to be filtered
+ * @shadow_apcb: the shadow of the KVM guest's APCB (contains AP configuration
+ * for guest)
+ * @filter_apids: boolean value indicating whether the APQNs shall be filtered
+ * by APID (true) or by APQI (false).
+ *
+ * Returns the number of APQNs remaining after filtering is complete.
+ */
+static void vfio_ap_mdev_refresh_apcb(struct ap_matrix_mdev *matrix_mdev)
+{
+ struct ap_matrix sha
[PATCH v13 15/15] s390/vfio-ap: update docs to include dynamic config support
Update the documentation in vfio-ap.rst to include information about the AP dynamic configuration support (i.e., hot plug of adapters, domains and control domains via the matrix mediated device's sysfs assignment attributes). Signed-off-by: Tony Krowiak --- Documentation/s390/vfio-ap.rst | 383 - 1 file changed, 284 insertions(+), 99 deletions(-) diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/s390/vfio-ap.rst index e15436599086..031c2e5ee138 100644 --- a/Documentation/s390/vfio-ap.rst +++ b/Documentation/s390/vfio-ap.rst @@ -123,9 +123,9 @@ Let's now take a look at how AP instructions executed on a guest are interpreted by the hardware. A satellite control block called the Crypto Control Block (CRYCB) is attached to -our main hardware virtualization control block. The CRYCB contains three fields -to identify the adapters, usage domains and control domains assigned to the KVM -guest: +our main hardware virtualization control block. The CRYCB contains an AP Control +Block (APCB) that has three fields to identify the adapters, usage domains and +control domains assigned to the KVM guest: * The AP Mask (APM) field is a bit mask that identifies the AP adapters assigned to the KVM guest. Each bit in the mask, from left to right (i.e. from most @@ -192,7 +192,7 @@ The design introduces three new objects: 1. AP matrix device 2. VFIO AP device driver (vfio_ap.ko) -3. VFIO AP mediated matrix pass-through device +3. VFIO AP mediated pass-through device The VFIO AP device driver - @@ -200,12 +200,13 @@ The VFIO AP (vfio_ap) device driver serves the following purposes: 1. Provides the interfaces to secure APQNs for exclusive use of KVM guests. -2. Sets up the VFIO mediated device interfaces to manage a mediated matrix +2. Sets up the VFIO mediated device interfaces to manage a vfio_ap mediated device and creates the sysfs interfaces for assigning adapters, usage domains, and control domains comprising the matrix for a KVM guest. -3. Configures the APM, AQM and ADM in the CRYCB referenced by a KVM guest's - SIE state description to grant the guest access to a matrix of AP devices +3. Configures the APM, AQM and ADM in the APCB contained in the CRYCB referenced + by a KVM guest's SIE state description to grant the guest access to a matrix + of AP devices Reserve APQNs for exclusive use of KVM guests - @@ -253,7 +254,7 @@ The process for reserving an AP queue for use by a KVM guest is: 1. The administrator loads the vfio_ap device driver 2. The vfio-ap driver during its initialization will register a single 'matrix' device with the device core. This will serve as the parent device for - all mediated matrix devices used to configure an AP matrix for a guest. + all vfio_ap mediated devices used to configure an AP matrix for a guest. 3. The /sys/devices/vfio_ap/matrix device is created by the device core 4. The vfio_ap device driver will register with the AP bus for AP queue devices of type 10 and higher (CEX4 and newer). The driver will provide the vfio_ap @@ -269,7 +270,7 @@ The process for reserving an AP queue for use by a KVM guest is: default zcrypt cex4queue driver. 8. The AP bus probes the vfio_ap device driver to bind the queues reserved for it. -9. The administrator creates a passthrough type mediated matrix device to be +9. The administrator creates a passthrough type vfio_ap mediated device to be used by a guest 10. The administrator assigns the adapters, usage domains and control domains to be exclusively used by a guest. @@ -279,14 +280,14 @@ Set up the VFIO mediated device interfaces The VFIO AP device driver utilizes the common interface of the VFIO mediated device core driver to: -* Register an AP mediated bus driver to add a mediated matrix device to and +* Register an AP mediated bus driver to add a vfio_ap mediated device to and remove it from a VFIO group. -* Create and destroy a mediated matrix device -* Add a mediated matrix device to and remove it from the AP mediated bus driver -* Add a mediated matrix device to and remove it from an IOMMU group +* Create and destroy a vfio_ap mediated device +* Add a vfio_ap mediated device to and remove it from the AP mediated bus driver +* Add a vfio_ap mediated device to and remove it from an IOMMU group The following high-level block diagram shows the main components and interfaces -of the VFIO AP mediated matrix device driver:: +of the VFIO AP mediated device driver:: +-+ | | @@ -343,7 +344,7 @@ matrix device. * device_api: the mediated device type's API * available_instances: - the number of mediated matrix passthrough devices + the number of vfio_ap mediated passthrough devices that can be created * device_api: specifies the VFIO API @@
[PATCH v13 13/15] s390/vfio-ap: handle host AP config change notification
The motivation for config change notification is to enable the vfio_ap device driver to handle hot plug/unplug of AP queues for a KVM guest as a bulk operation. For example, if a new APID is dynamically assigned to the host configuration, then a queue device will be created for each APQN that can be formulated from the new APID and all APQIs already assigned to the host configuration. Each of these new queue devices will get bound to their respective driver one at a time, as they are created. In the case of the vfio_ap driver, if the APQN of the queue device being bound to the driver is assigned to a matrix mdev in use by a KVM guest, it will be hot plugged into the guest if possible. Given that the AP architecture allows for 256 adapters and 256 domains, one can see the possibility of the vfio_ap driver's probe/remove callbacks getting invoked an inordinate number of times when the host configuration changes. Keep in mind that in order to plug/unplug an AP queue for a guest, the guest's VCPUs must be suspended, then the guest's AP configuration must be updated followed by the VCPUs being resumed. If this is done each time the probe or remove callback is invoked and there are hundreds or thousands of queues to be probed or removed, this would be incredibly inefficient and could have a large impact on guest performance. What the config notification does is allow us to make the changes to the guest in a single operation. This patch implements the on_cfg_changed callback which notifies the AP device drivers that the host AP configuration has changed (i.e., adapters, domains and/or control domains are added to or removed from the host AP configuration). Adapters added to host configuration: * The APIDs of the adapters added will be stored in a bitmap contained within the struct representing the matrix device which is the parent device of all matrix mediated devices. * When a queue is probed, if the APQN of the queue being probed is assigned to an mdev in use by a guest, the queue may get hot plugged into the guest; however, if the APID of the adapter is contained in the bitmap of adapters added, the queue hot plug operation will be skipped until the AP bus notifies the driver that its scan operation has completed (another patch). * When the vfio_ap driver is notified that the AP bus scan has completed, the guest's APCB will be refreshed by filtering the mdev's matrix by APID. Domains added to host configuration: * The APQIs of the domains added will be stored in a bitmap contained within the struct representing the matrix device which is the parent device of all matrix mediated devices. * When a queue is probed, if the APQN of the queue being probed is assigned to an mdev in use by a guest, the queue may get hot plugged into the guest; however, if the APQI of the domain is contained in the bitmap of domains added, the queue hot plug operation will be skipped until the AP bus notifies the driver that its scan operation has completed (another patch). Control domains added to the host configuration: * The domain numbers of the domains added will be stored in a bitmap contained within the struct representing the matrix device which is the parent device of all matrix mediated devices. When the vfio_ap device driver is notified that the AP bus scan has completed, the APCB for each matrix mdev to which the adapters, domains and control domains added are assigned will be refreshed. If a KVM guest is using the matrix mdev, the APCB will be hot plugged into the guest to refresh its AP configuration. Adapters removed from configuration: * Each queue device with the APID identifying an adapter removed from the host AP configuration will be unlinked from the matrix mdev to which the queue's APQN is assigned. * When the vfio_ap driver's remove callback is invoked, if the queue device is not linked to the matrix mdev, the refresh of the guest's APCB will be skipped. Domains removed from configuration: * Each queue device with the APQI identifying a domain removed from the host AP configuration will be unlinked from the matrix mdev to which the queue's APQN is assigned. * When the vfio_ap driver's remove callback is invoked, if the queue device is not linked to the matrix mdev, the refresh of the guest's APCB will be skipped. If any queues with an APQN assigned to a given matrix mdev have been unlinked or any control domains assigned to a given matrix mdev have been removed from the host AP configuration, the APCB of the matrix mdev will be refreshed. If a KVM guest is using the matrix mdev, the APCB will be hot plugged into the guest to refresh its AP configuration. Signed-off-by: Tony Krowiak --- drivers/s390/crypto/vfio_ap_drv.c | 3 +- drivers/s390/crypto/vfio_ap_ops.c | 159 +++--- drivers/s390/crypto/vfio_ap_private.h | 13 ++- 3 files changed, 158 insertions(+), 17 deletions(-) diff --git a/drivers/s390/crypto/vfio_ap_drv.c
[PATCH v13 11/15] s390/vfio-ap: implement in-use callback for vfio_ap driver
Let's implement the callback to indicate when an APQN
is in use by the vfio_ap device driver. The callback is
invoked whenever a change to the apmask or aqmask would
result in one or more queue devices being removed from the driver. The
vfio_ap device driver will indicate a resource is in use
if the APQN of any of the queue devices to be removed are assigned to
any of the matrix mdevs under the driver's control.
There is potential for a deadlock condition between the matrix_dev->lock
used to lock the matrix device during assignment of adapters and domains
and the ap_perms_mutex locked by the AP bus when changes are made to the
sysfs apmask/aqmask attributes.
Consider following scenario (courtesy of Halil Pasic):
1) apmask_store() takes ap_perms_mutex
2) assign_adapter_store() takes matrix_dev->lock
3) apmask_store() calls vfio_ap_mdev_resource_in_use() which tries
to take matrix_dev->lock
4) assign_adapter_store() calls ap_apqn_in_matrix_owned_by_def_drv
which tries to take ap_perms_mutex
BANG!
To resolve this issue, instead of using the mutex_lock(&matrix_dev->lock)
function to lock the matrix device during assignment of an adapter or
domain to a matrix_mdev as well as during the in_use callback, the
mutex_trylock(&matrix_dev->lock) function will be used. If the lock is not
obtained, then the assignment and in_use functions will terminate with
-EBUSY.
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_drv.c | 1 +
drivers/s390/crypto/vfio_ap_ops.c | 21 ++---
drivers/s390/crypto/vfio_ap_private.h | 2 ++
3 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c
b/drivers/s390/crypto/vfio_ap_drv.c
index 73bd073fd5d3..8934471b7944 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -147,6 +147,7 @@ static int __init vfio_ap_init(void)
memset(&vfio_ap_drv, 0, sizeof(vfio_ap_drv));
vfio_ap_drv.probe = vfio_ap_mdev_probe_queue;
vfio_ap_drv.remove = vfio_ap_mdev_remove_queue;
+ vfio_ap_drv.in_use = vfio_ap_mdev_resource_in_use;
vfio_ap_drv.ids = ap_queue_ids;
ret = ap_driver_register(&vfio_ap_drv, THIS_MODULE, VFIO_AP_DRV_NAME);
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 843862c88379..6bc2e80cc565 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -644,7 +644,8 @@ static ssize_t assign_adapter_store(struct device *dev,
memset(apm, 0, sizeof(apm));
set_bit_inv(apid, apm);
- mutex_lock(&matrix_dev->lock);
+ if (!mutex_trylock(&matrix_dev->lock))
+ return -EBUSY;
ret = vfio_ap_mdev_validate_masks(matrix_mdev, apm,
matrix_mdev->matrix.aqm);
@@ -777,7 +778,8 @@ static ssize_t assign_domain_store(struct device *dev,
memset(aqm, 0, sizeof(aqm));
set_bit_inv(apqi, aqm);
- mutex_lock(&matrix_dev->lock);
+ if (!mutex_trylock(&matrix_dev->lock))
+ return -EBUSY;
ret = vfio_ap_mdev_validate_masks(matrix_mdev, matrix_mdev->matrix.apm,
aqm);
@@ -896,7 +898,8 @@ static ssize_t assign_control_domain_store(struct device
*dev,
* least significant, correspond to IDs 0 up to the one less than the
* number of control domains that can be assigned.
*/
- mutex_lock(&matrix_dev->lock);
+ if (!mutex_trylock(&matrix_dev->lock))
+ return -EBUSY;
set_bit_inv(id, matrix_mdev->matrix.adm);
vfio_ap_mdev_hot_plug_cdom(matrix_mdev, id);
mutex_unlock(&matrix_dev->lock);
@@ -1446,3 +1449,15 @@ void vfio_ap_mdev_remove_queue(struct ap_device *apdev)
kfree(q);
mutex_unlock(&matrix_dev->lock);
}
+
+int vfio_ap_mdev_resource_in_use(unsigned long *apm, unsigned long *aqm)
+{
+ int ret;
+
+ if (!mutex_trylock(&matrix_dev->lock))
+ return -EBUSY;
+ ret = vfio_ap_mdev_verify_no_sharing(NULL, apm, aqm);
+ mutex_unlock(&matrix_dev->lock);
+
+ return ret;
+}
diff --git a/drivers/s390/crypto/vfio_ap_private.h
b/drivers/s390/crypto/vfio_ap_private.h
index d2d26ba18602..15b7cd74843b 100644
--- a/drivers/s390/crypto/vfio_ap_private.h
+++ b/drivers/s390/crypto/vfio_ap_private.h
@@ -107,4 +107,6 @@ struct vfio_ap_queue {
int vfio_ap_mdev_probe_queue(struct ap_device *queue);
void vfio_ap_mdev_remove_queue(struct ap_device *queue);
+int vfio_ap_mdev_resource_in_use(unsigned long *apm, unsigned long *aqm);
+
#endif /* _VFIO_AP_PRIVATE_H_ */
--
2.21.1
[PATCH v13 12/15] s390/zcrypt: Notify driver on config changed and scan complete callbacks
This patch intruduces an extension to the ap bus to notify device drivers
when the host AP configuration changes - i.e., adapters, domains or
control domains are added or removed. To that end, two new callbacks are
introduced for AP device drivers:
void (*on_config_changed)(struct ap_config_info *new_config_info,
struct ap_config_info *old_config_info);
This callback is invoked at the start of the AP bus scan
function when it determines that the host AP configuration information
has changed since the previous scan. This is done by storing
an old and current QCI info struct and comparing them. If there is any
difference, the callback is invoked.
Note that when the AP bus scan detects that AP adapters, domains or
control domains have been removed from the host's AP configuration, it
will remove the associated devices from the AP bus subsystem's device
model. This callback gives the device driver a chance to respond to
the removal of the AP devices from the host configuration prior to
calling the device driver's remove callback. The primary purpose of
this callback is to allow the vfio_ap driver to do a bulk unplug of
all affected adapters, domains and control domains from affected
guests rather than unplugging them one at a time when the remove
callback is invoked.
void (*on_scan_complete)(struct ap_config_info *new_config_info,
struct ap_config_info *old_config_info);
The on_scan_complete callback is invoked after the ap bus scan is
complete if the host AP configuration data has changed.
Note that when the AP bus scan detects that adapters, domains or
control domains have been added to the host's configuration, it will
create new devices in the AP bus subsystem's device model. The primary
purpose of this callback is to allow the vfio_ap driver to do a bulk
plug of all affected adapters, domains and control domains into
affected guests rather than plugging them one at a time when the
probe callback is invoked.
Please note that changes to the apmask and aqmask do not trigger
these two callbacks since the bus scan function is not invoked by changes
to those masks.
Signed-off-by: Harald Freudenberger
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/ap_bus.c | 91 +++-
drivers/s390/crypto/ap_bus.h | 12 +
2 files changed, 101 insertions(+), 2 deletions(-)
diff --git a/drivers/s390/crypto/ap_bus.c b/drivers/s390/crypto/ap_bus.c
index 7d8add952dd6..788bfdaadafd 100644
--- a/drivers/s390/crypto/ap_bus.c
+++ b/drivers/s390/crypto/ap_bus.c
@@ -82,6 +82,7 @@ static atomic64_t ap_scan_bus_count;
static DECLARE_COMPLETION(ap_init_apqn_bindings_complete);
static struct ap_config_info *ap_qci_info;
+static struct ap_config_info *ap_qci_info_old;
/*
* AP bus related debug feature things.
@@ -1579,6 +1580,52 @@ static int __match_queue_device_with_queue_id(struct
device *dev, const void *da
&& AP_QID_QUEUE(to_ap_queue(dev)->qid) == (int)(long) data;
}
+/* Helper function for notify_config_changed */
+static int __drv_notify_config_changed(struct device_driver *drv, void *data)
+{
+ struct ap_driver *ap_drv = to_ap_drv(drv);
+
+ if (try_module_get(drv->owner)) {
+ if (ap_drv->on_config_changed)
+ ap_drv->on_config_changed(ap_qci_info,
+ ap_qci_info_old);
+ module_put(drv->owner);
+ }
+
+ return 0;
+}
+
+/* Notify all drivers about an qci config change */
+static inline void notify_config_changed(void)
+{
+ bus_for_each_drv(&ap_bus_type, NULL, NULL,
+__drv_notify_config_changed);
+}
+
+/* Helper function for notify_scan_complete */
+static int __drv_notify_scan_complete(struct device_driver *drv, void *data)
+{
+ struct ap_driver *ap_drv = to_ap_drv(drv);
+
+ if (try_module_get(drv->owner)) {
+ if (ap_drv->on_scan_complete)
+ ap_drv->on_scan_complete(ap_qci_info,
+ap_qci_info_old);
+ module_put(drv->owner);
+ }
+
+ return 0;
+}
+
+/* Notify all drivers about bus scan complete */
+static inline void notify_scan_complete(void)
+{
+ bus_for_each_drv(&ap_bus_type, NULL, NULL,
+__drv_notify_scan_complete);
+}
+
+
+
/*
* Helper function for ap_scan_bus().
* Remove card device and associated queue devices.
@@ -1857,15 +1904,51 @@ static inline void ap_scan_adapter(int ap)
put_device(&ac->ap_dev.device);
}
+/*
+ * ap_get_configuration
+ *
+ * Stores the host AP configuration information returned from the previous call
+ * to Query Configuration Information (QCI), then retrieves and stores the
+ * current AP configuration returned from QCI.
+ *
+ * Returns true if th
[PATCH v13 03/15] s390/vfio-ap: move probe and remove callbacks to vfio_ap_ops.c
Let's move the probe and remove callbacks into the vfio_ap_ops.c
file to keep all code related to managing queues in a single file. This
way, all functions related to queue management can be removed from the
vfio_ap_private.h header file defining the public interfaces for the
vfio_ap device driver.
Signed-off-by: Tony Krowiak
Reviewed-by: Halil Pasic
---
drivers/s390/crypto/vfio_ap_drv.c | 44 ++-
drivers/s390/crypto/vfio_ap_ops.c | 34 +++--
drivers/s390/crypto/vfio_ap_private.h | 6 ++--
3 files changed, 37 insertions(+), 47 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c
b/drivers/s390/crypto/vfio_ap_drv.c
index ca18c91afec9..73bd073fd5d3 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -43,46 +43,6 @@ static struct ap_device_id ap_queue_ids[] = {
MODULE_DEVICE_TABLE(vfio_ap, ap_queue_ids);
-/**
- * vfio_ap_queue_dev_probe:
- *
- * Allocate a vfio_ap_queue structure and associate it
- * with the device as driver_data.
- */
-static int vfio_ap_queue_dev_probe(struct ap_device *apdev)
-{
- struct vfio_ap_queue *q;
-
- q = kzalloc(sizeof(*q), GFP_KERNEL);
- if (!q)
- return -ENOMEM;
- dev_set_drvdata(&apdev->device, q);
- q->apqn = to_ap_queue(&apdev->device)->qid;
- q->saved_isc = VFIO_AP_ISC_INVALID;
- return 0;
-}
-
-/**
- * vfio_ap_queue_dev_remove:
- *
- * Takes the matrix lock to avoid actions on this device while removing
- * Free the associated vfio_ap_queue structure
- */
-static void vfio_ap_queue_dev_remove(struct ap_device *apdev)
-{
- struct vfio_ap_queue *q;
- int apid, apqi;
-
- mutex_lock(&matrix_dev->lock);
- q = dev_get_drvdata(&apdev->device);
- dev_set_drvdata(&apdev->device, NULL);
- apid = AP_QID_CARD(q->apqn);
- apqi = AP_QID_QUEUE(q->apqn);
- vfio_ap_mdev_reset_queue(apid, apqi, 1);
- kfree(q);
- mutex_unlock(&matrix_dev->lock);
-}
-
static void vfio_ap_matrix_dev_release(struct device *dev)
{
struct ap_matrix_dev *matrix_dev = dev_get_drvdata(dev);
@@ -185,8 +145,8 @@ static int __init vfio_ap_init(void)
return ret;
memset(&vfio_ap_drv, 0, sizeof(vfio_ap_drv));
- vfio_ap_drv.probe = vfio_ap_queue_dev_probe;
- vfio_ap_drv.remove = vfio_ap_queue_dev_remove;
+ vfio_ap_drv.probe = vfio_ap_mdev_probe_queue;
+ vfio_ap_drv.remove = vfio_ap_mdev_remove_queue;
vfio_ap_drv.ids = ap_queue_ids;
ret = ap_driver_register(&vfio_ap_drv, THIS_MODULE, VFIO_AP_DRV_NAME);
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 052f61391ec7..a83d6e75361b 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -140,7 +140,7 @@ static void vfio_ap_free_aqic_resources(struct
vfio_ap_queue *q)
* Returns if ap_aqic function failed with invalid, deconfigured or
* checkstopped AP.
*/
-struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q)
+static struct ap_queue_status vfio_ap_irq_disable(struct vfio_ap_queue *q)
{
struct ap_qirq_ctrl aqic_gisa = {};
struct ap_queue_status status;
@@ -1137,8 +1137,8 @@ static struct vfio_ap_queue *vfio_ap_find_queue(int apqn)
return q;
}
-int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi,
-unsigned int retry)
+static int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi,
+ unsigned int retry)
{
struct ap_queue_status status;
struct vfio_ap_queue *q;
@@ -1321,3 +1321,31 @@ void vfio_ap_mdev_unregister(void)
{
mdev_unregister_device(&matrix_dev->device);
}
+
+int vfio_ap_mdev_probe_queue(struct ap_device *apdev)
+{
+ struct vfio_ap_queue *q;
+
+ q = kzalloc(sizeof(*q), GFP_KERNEL);
+ if (!q)
+ return -ENOMEM;
+ dev_set_drvdata(&apdev->device, q);
+ q->apqn = to_ap_queue(&apdev->device)->qid;
+ q->saved_isc = VFIO_AP_ISC_INVALID;
+ return 0;
+}
+
+void vfio_ap_mdev_remove_queue(struct ap_device *apdev)
+{
+ struct vfio_ap_queue *q;
+ int apid, apqi;
+
+ mutex_lock(&matrix_dev->lock);
+ q = dev_get_drvdata(&apdev->device);
+ dev_set_drvdata(&apdev->device, NULL);
+ apid = AP_QID_CARD(q->apqn);
+ apqi = AP_QID_QUEUE(q->apqn);
+ vfio_ap_mdev_reset_queue(apid, apqi, 1);
+ kfree(q);
+ mutex_unlock(&matrix_dev->lock);
+}
diff --git a/drivers/s390/crypto/vfio_ap_private.h
b/drivers/s390/crypto/vfio_ap_private.h
index 0db6fb3d56d5..d9003de4fbad 100644
--- a/drivers/s390/crypto/vfio_ap_private.h
+++ b/drivers/s390/crypto/vfio_ap_private.h
@@ -90,8 +90,6 @@ struct ap_matrix_mdev {
extern int vfio_ap_mdev_register(void);
extern void vfio_ap_mdev_unregister(void);
-int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi,
-
[PATCH v13 02/15] s390/vfio-ap: No need to disable IRQ after queue reset
The queues assigned to a matrix mediated device are currently reset when:
* The VFIO_DEVICE_RESET ioctl is invoked
* The mdev fd is closed by userspace (QEMU)
* The mdev is removed from sysfs.
Immediately after the reset of a queue, a call is made to disable
interrupts for the queue. This is entirely unnecessary because the reset of
a queue disables interrupts, so this will be removed.
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/vfio_ap_drv.c | 1 -
drivers/s390/crypto/vfio_ap_ops.c | 40 +--
drivers/s390/crypto/vfio_ap_private.h | 1 -
3 files changed, 26 insertions(+), 16 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_drv.c
b/drivers/s390/crypto/vfio_ap_drv.c
index be2520cc010b..ca18c91afec9 100644
--- a/drivers/s390/crypto/vfio_ap_drv.c
+++ b/drivers/s390/crypto/vfio_ap_drv.c
@@ -79,7 +79,6 @@ static void vfio_ap_queue_dev_remove(struct ap_device *apdev)
apid = AP_QID_CARD(q->apqn);
apqi = AP_QID_QUEUE(q->apqn);
vfio_ap_mdev_reset_queue(apid, apqi, 1);
- vfio_ap_irq_disable(q);
kfree(q);
mutex_unlock(&matrix_dev->lock);
}
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 7339043906cf..052f61391ec7 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -25,6 +25,7 @@
#define VFIO_AP_MDEV_NAME_HWVIRT "VFIO AP Passthrough Device"
static int vfio_ap_mdev_reset_queues(struct mdev_device *mdev);
+static struct vfio_ap_queue *vfio_ap_find_queue(int apqn);
static int match_apqn(struct device *dev, const void *data)
{
@@ -49,20 +50,15 @@ static struct vfio_ap_queue *vfio_ap_get_queue(
int apqn)
{
struct vfio_ap_queue *q;
- struct device *dev;
if (!test_bit_inv(AP_QID_CARD(apqn), matrix_mdev->matrix.apm))
return NULL;
if (!test_bit_inv(AP_QID_QUEUE(apqn), matrix_mdev->matrix.aqm))
return NULL;
- dev = driver_find_device(&matrix_dev->vfio_ap_drv->driver, NULL,
-&apqn, match_apqn);
- if (!dev)
- return NULL;
- q = dev_get_drvdata(dev);
- q->matrix_mdev = matrix_mdev;
- put_device(dev);
+ q = vfio_ap_find_queue(apqn);
+ if (q)
+ q->matrix_mdev = matrix_mdev;
return q;
}
@@ -1126,24 +1122,27 @@ static int vfio_ap_mdev_group_notifier(struct
notifier_block *nb,
return notify_rc;
}
-static void vfio_ap_irq_disable_apqn(int apqn)
+static struct vfio_ap_queue *vfio_ap_find_queue(int apqn)
{
struct device *dev;
- struct vfio_ap_queue *q;
+ struct vfio_ap_queue *q = NULL;
dev = driver_find_device(&matrix_dev->vfio_ap_drv->driver, NULL,
&apqn, match_apqn);
if (dev) {
q = dev_get_drvdata(dev);
- vfio_ap_irq_disable(q);
put_device(dev);
}
+
+ return q;
}
int vfio_ap_mdev_reset_queue(unsigned int apid, unsigned int apqi,
unsigned int retry)
{
struct ap_queue_status status;
+ struct vfio_ap_queue *q;
+ int ret;
int retry2 = 2;
int apqn = AP_MKQID(apid, apqi);
@@ -1156,18 +1155,32 @@ int vfio_ap_mdev_reset_queue(unsigned int apid,
unsigned int apqi,
status = ap_tapq(apqn, NULL);
}
WARN_ON_ONCE(retry2 <= 0);
- return 0;
+ ret = 0;
+ goto free_aqic_resources;
case AP_RESPONSE_RESET_IN_PROGRESS:
case AP_RESPONSE_BUSY:
msleep(20);
break;
default:
/* things are really broken, give up */
- return -EIO;
+ ret = -EIO;
+ goto free_aqic_resources;
}
} while (retry--);
return -EBUSY;
+
+free_aqic_resources:
+ /*
+* In order to free the aqic resources, the queue must be linked to
+* the matrix_mdev to which its APQN is assigned and the KVM pointer
+* must be available.
+*/
+ q = vfio_ap_find_queue(apqn);
+ if (q && q->matrix_mdev && q->matrix_mdev->kvm)
+ vfio_ap_free_aqic_resources(q);
+
+ return ret;
}
static int vfio_ap_mdev_reset_queues(struct mdev_device *mdev)
@@ -1189,7 +1202,6 @@ static int vfio_ap_mdev_reset_queues(struct mdev_device
*mdev)
*/
if (ret)
rc = ret;
- vfio_ap_irq_disable_apqn(AP_MKQID(apid, apqi));
}
}
diff --git a/drivers/s390/crypto/vfio_ap_private.h
b/drivers/s390/crypto/vfio_ap_private.h
index f46dde56b464..0db6fb3d56d5 100644
--- a/drivers/s390
[PATCH v13 00/15] s390/vfio-ap: dynamic configuration support
Note: Patch 1, s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated does not belong to this series. It has been posted as a separate patch to fix a known problem. It is included here because it will likely pre-req for this series. The current design for AP pass-through does not support making dynamic changes to the AP matrix of a running guest resulting in a few deficiencies this patch series is intended to mitigate: 1. Adapters, domains and control domains can not be added to or removed from a running guest. In order to modify a guest's AP configuration, the guest must be terminated; only then can AP resources be assigned to or unassigned from the guest's matrix mdev. The new AP configuration becomes available to the guest when it is subsequently restarted. 2. The AP bus's /sys/bus/ap/apmask and /sys/bus/ap/aqmask interfaces can be modified by a root user without any restrictions. A change to either mask can result in AP queue devices being unbound from the vfio_ap device driver and bound to a zcrypt device driver even if a guest is using the queues, thus giving the host access to the guest's private crypto data and vice versa. 3. The APQNs derived from the Cartesian product of the APIDs of the adapters and APQIs of the domains assigned to a matrix mdev must reference an AP queue device bound to the vfio_ap device driver. The AP architecture allows assignment of AP resources that are not available to the system, so this artificial restriction is not compliant with the architecture. 4. The AP configuration profile can be dynamically changed for the linux host after a KVM guest is started. For example, a new domain can be dynamically added to the configuration profile via the SE or an HMC connected to a DPM enabled lpar. Likewise, AP adapters can be dynamically configured (online state) and deconfigured (standby state) using the SE, an SCLP command or an HMC connected to a DPM enabled lpar. This can result in inadvertent sharing of AP queues between the guest and host. 5. A root user can manually unbind an AP queue device representing a queue in use by a KVM guest via the vfio_ap device driver's sysfs unbind attribute. In this case, the guest will be using a queue that is not bound to the driver which violates the device model. This patch series introduces the following changes to the current design to alleviate the shortcomings described above as well as to implement more of the AP architecture: 1. A root user will be prevented from making edits to the AP bus's /sys/bus/ap/apmask or /sys/bus/ap/aqmask if the change would transfer ownership of an APQN from the vfio_ap device driver to a zcrypt driver while the APQN is assigned to a matrix mdev. 2. Allow a root user to hot plug/unplug AP adapters, domains and control domains for a KVM guest using the matrix mdev via its sysfs assign/unassign attributes. 4. Allow assignment of an AP adapter or domain to a matrix mdev even if it results in assignment of an APQN that does not reference an AP queue device bound to the vfio_ap device driver, as long as the APQN is not reserved for use by the default zcrypt drivers (also known as over-provisioning of AP resources). Allowing over-provisioning of AP resources better models the architecture which does not preclude assigning AP resources that are not yet available in the system. Such APQNs, however, will not be assigned to the guest using the matrix mdev; only APQNs referencing AP queue devices bound to the vfio_ap device driver will actually get assigned to the guest. 5. Handle dynamic changes to the AP device model. 1. Rationale for changes to AP bus's apmask/aqmask interfaces: -- Due to the extremely sensitive nature of cryptographic data, it is imperative that great care be taken to ensure that such data is secured. Allowing a root user, either inadvertently or maliciously, to configure these masks such that a queue is shared between the host and a guest is not only avoidable, it is advisable. It was suggested that this scenario is better handled in user space with management software, but that does not preclude a malicious administrator from using the sysfs interfaces to gain access to a guest's crypto data. It was also suggested that this scenario could be avoided by taking access to the adapter away from the guest and zeroing out the queues prior to the vfio_ap driver releasing the device; however, stealing an adapter in use from a guest as a by-product of an operation is bad and will likely cause problems for the guest unnecessarily. It was decided that the most effective solution with the least number of negative side effects is to prevent the situation at the source. 2. Rationale for hot plug/unplug using matrix mdev sysfs interfaces: --
Re: [PATCH v2, 01/17] dt-bindings: mediatek: add description for postmask
On Tue, 2020-12-15 at 22:49 +0800, Chun-Kuang Hu wrote: > Hi, Yongqiang: > > Yongqiang Niu 於 2020年12月12日 週六 下午12:12寫道： > > > > add description for postmask > > What is postmask? I google it and find a postmask ECO. So it is postmask ECO? > > Regards, > Chun-Kuang. > it is used control round corner for display frame > > > > Signed-off-by: Yongqiang Niu > > --- > > Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git > > a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > > b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > > index 5ca693a..1972fa7 100644 > > --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > > +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt > > @@ -37,6 +37,7 @@ Required properties (all function blocks): > > "mediatek,-disp-aal" - adaptive ambient light > > controller > > "mediatek,-disp-gamma"- gamma correction > > "mediatek,-disp-merge"- merge streams from two > > RDMA sources > > + "mediatek,-disp-postmask" - post mask > > "mediatek,-disp-split"- split stream to two > > encoders > > "mediatek,-disp-ufoe" - data compression engine > > "mediatek,-dsi" - DSI controller, see > > mediatek,dsi.txt > > -- > > 1.8.1.1.dirty > > ___ > > Linux-mediatek mailing list > > linux-media...@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
UBSAN: shift-out-of-bounds in sfq_init
Hello, syzbot found the following issue on: HEAD commit:a409ed15 Merge tag 'gpio-v5.11-1' of git://git.kernel.org/.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=164f512350 kernel config: https://syzkaller.appspot.com/x/.config?x=f7c39e7211134bc0 dashboard link: https://syzkaller.appspot.com/bug?extid=97c5bd9cc81eca63d36e compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1136680f50 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1438348750 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+97c5bd9cc81eca63d...@syzkaller.appspotmail.com UBSAN: shift-out-of-bounds in ./include/net/red.h:252:22 shift exponent 72 is too large for 32-bit type 'int' CPU: 1 PID: 8479 Comm: syz-executor063 Not tainted 5.10.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395 red_set_parms include/net/red.h:252 [inline] sfq_change net/sched/sch_sfq.c:674 [inline] sfq_init.cold+0x4f/0xd5 net/sched/sch_sfq.c:762 qdisc_create+0x4ba/0x13a0 net/sched/sch_api.c:1246 tc_modify_qdisc+0x4c8/0x1a30 net/sched/sch_api.c:1662 rtnetlink_rcv_msg+0x498/0xb80 net/core/rtnetlink.c:5564 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2494 netlink_unicast_kernel net/netlink/af_netlink.c:1304 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1330 netlink_sendmsg+0x907/0xe40 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:652 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:672 sys_sendmsg+0x6e8/0x810 net/socket.c:2345 ___sys_sendmsg+0xf3/0x170 net/socket.c:2399 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2432 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x4404f9 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 7b 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7fffef145e18 EFLAGS: 0246 ORIG_RAX: 002e RAX: ffda RBX: 004002c8 RCX: 004404f9 RDX: RSI: 2040 RDI: 0004 RBP: 006ca018 R08: R09: 004002c8 R10: R11: 0246 R12: 00401d00 R13: 00401d90 R14: R15: --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH v13 5/6] arm64: Free DTB buffer if fdt_open_into() fails
Lakshmi Ramasubramanian writes: > create_dtb() function allocates memory for the device tree blob (DTB) > and calls fdt_open_into(). If this call fails the memory allocated > for the DTB is not freed before returning from create_dtb() thereby > leaking memory. > > Call vfree() to free the memory allocated for the DTB if fdt_open_into() > fails. > > Co-developed-by: Prakhar Srivastava > Signed-off-by: Prakhar Srivastava > Signed-off-by: Lakshmi Ramasubramanian > --- > arch/arm64/kernel/machine_kexec_file.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Thiago Jung Bauermann -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [PATCH v13 4/6] powerpc: Delete unused function delete_fdt_mem_rsv()
Lakshmi Ramasubramanian writes: > delete_fdt_mem_rsv() defined in "arch/powerpc/kexec/file_load.c" > has been renamed to fdt_find_and_del_mem_rsv(), and moved to > "drivers/of/kexec.c". > > Remove delete_fdt_mem_rsv() in "arch/powerpc/kexec/file_load.c". > > Co-developed-by: Prakhar Srivastava > Signed-off-by: Prakhar Srivastava > Signed-off-by: Lakshmi Ramasubramanian > --- > arch/powerpc/include/asm/kexec.h | 1 - > arch/powerpc/kexec/file_load.c | 32 > 2 files changed, 33 deletions(-) As I mentioned in the other email, this patch could remove setup_new_fdt() as well. I'm a bit ambivalent on whether this patch should be squashed with patch 2 or left on its own, but I tend toward the latter option because patch 2 is big enough already. -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [PATCH 2/3] aspeed-video: clear spurious interrupt bits unconditionally
On Tue, 22 Dec 2020 at 19:14, Zev Weiss wrote: > > On Mon, Dec 21, 2020 at 10:47:37PM CST, Joel Stanley wrote: > >On Tue, 15 Dec 2020 at 02:46, Zev Weiss wrote: > >> > >> Instead of testing and conditionally clearing them one by one, we can > >> instead just unconditionally clear them all at once. > >> > >> Signed-off-by: Zev Weiss > > > >I had a poke at the assembly and it looks like GCC is clearing the > >bits unconditionally anyway, so removing the tests provides no change. > > > >Combining them is a good further optimization. > > > >Reviewed-by: Joel Stanley > > > >A question unrelated to this patch: Do you know why the driver doesn't > >clear the status bits in the interrupt handler? I would expect it to > >write the value of sts back to the register to ack the pending > >interrupt. > > > > No, I don't, and I was sort of wondering the same thing actually -- I'm > not deeply familiar with this hardware or driver though, so I was a bit > hesitant to start messing with things. (Though maybe doing so would > address the "stickiness" aspect when it does manifest.) Perhaps Eddie > or Jae can shed some light here? I think you're onto something here - this would be why the status bits seem to stick until the device is reset. Until Aspeed can clarify if this is a hardware or software issue, I suggest we ack the bits and log a message when we see them, instead of always ignoring them without taking any action. Can you write a patch that changes the interrupt handler to ack status bits as it handles each of them? > > > Zev >
Re: [PATCH] usb: host: xhci-plat: fix support for XHCI_SKIP_PHY_INIT quirk
On Wednesday 23 December 2020 01:02:43 Peter Chen wrote:
> On 20-12-22 14:30:51, Pali Rohár wrote:
> > On Tuesday 22 December 2020 10:23:27 Pali Rohár wrote:
> > > On Tuesday 22 December 2020 02:14:45 Peter Chen wrote:
> > > > On 20-12-21 16:09:03, Pali Rohár wrote:
> > > > > Currently init_quirk callbacks for xhci platform drivers are called
> > > > > xhci_plat_setup() function which is called after chip reset completes.
> > > > > It happens in the middle of the usb_add_hcd() function.
> > > > >
> > > > > But XHCI_SKIP_PHY_INIT quirk is checked in the xhci_plat_probe()
> > > > > function
> > > > > prior calling usb_add_hcd() function. Therefore this
> > > > > XHCI_SKIP_PHY_INIT
> > > > > currently does nothing as prior xhci_plat_setup() it is not set.
> > > > >
> > > > > Quirk XHCI_SKIP_PHY_INIT is only setting hcd->skip_phy_initialization
> > > > > value
> > > > > which really needs to be set prior calling usb_add_hcd() as this
> > > > > function
> > > > > at its beginning skips PHY init if this member is set.
> > > > >
> > > > > This patch fixes implementation of the XHCI_SKIP_PHY_INIT quirk by
> > > > > calling
> > > > > init_quirk callbacks (via xhci_priv_init_quirk()) prior checking if
> > > > > XHCI_SKIP_PHY_INIT is set.
> > > > >
> > > > > Fixes: f768e718911e0 ("usb: host: xhci-plat: add priv quirk for skip
> > > > > PHY initialization")
> > > > > Signed-off-by: Pali Rohár
>
> Hi Pali,
>
> I know your case, you need to choose XHCI_SKIP_PHY_INIT quirk
> conditionally, but you may can't add Fixes tag at your patch
> since your issue was existed before my patch.
Ok, no problem, in V2 I will not add it.
> Peter
>
>
> > > > > ---
> > > > > drivers/usb/host/xhci-plat.c | 14 +++---
> > > > > 1 file changed, 7 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/drivers/usb/host/xhci-plat.c
> > > > > b/drivers/usb/host/xhci-plat.c
> > > > > index 4d34f6005381..58704c5b002b 100644
> > > > > --- a/drivers/usb/host/xhci-plat.c
> > > > > +++ b/drivers/usb/host/xhci-plat.c
> > > > > @@ -89,13 +89,6 @@ static void xhci_plat_quirks(struct device *dev,
> > > > > struct xhci_hcd *xhci)
> > > > > /* called during probe() after chip reset completes */
> > > > > static int xhci_plat_setup(struct usb_hcd *hcd)
> > > > > {
> > > > > - int ret;
> > > > > -
> > > > > -
> > > > > - ret = xhci_priv_init_quirk(hcd);
> > > > > - if (ret)
> > > > > - return ret;
> > > > > -
> > > > > return xhci_gen_setup(hcd, xhci_plat_quirks);
> > > > > }
> > > > >
> > > > > @@ -330,6 +323,13 @@ static int xhci_plat_probe(struct
> > > > > platform_device *pdev)
> > > > >
> > > > > hcd->tpl_support = of_usb_host_tpl_support(sysdev->of_node);
> > > > > xhci->shared_hcd->tpl_support = hcd->tpl_support;
> > > > > +
> > > > > + if (priv) {
> > > > > + ret = xhci_priv_init_quirk(hcd);
> > > > > + if (ret)
> > > > > + goto disable_usb_phy;
> > > > > + }
> > > > > +
> > > > > if (priv && (priv->quirks & XHCI_SKIP_PHY_INIT))
> > > > > hcd->skip_phy_initialization = 1;
> > > > >
> > > >
> > > > Hi Pali,
> > > >
> > > > What's problem you have met? In structure xhci_plat_priv, the quirks are
> > > > defined at .quirks entry which is got at below code. .init_quirk is the
> > > > routine if special initializations are needed.
> > >
> > > Hello!
> > >
> > > I'm talking about .init_quirk. And if XHCI_SKIP_PHY_INIT quirk is set in
> > > this function then has no effect.
> >
> > Ok, this patch is not enough, I will send V2.
> >
> > > I'm working currently on patch for xhci mvebu which conditionally enable
> > > or disable XHCI_SKIP_PHY_INIT quirk (it is going to fix existing
> > > regression since v5.1 kernel) and without this patch XHCI_SKIP_PHY_INIT
> > > quirk from the init_quirk does not work.
> >
> > And now I have tested V2 with my mvebu regression fix. I will send it to
> > mailing list for review.
> >
> > > > if (pdev->dev.of_node)
> > > > priv_match = of_device_get_match_data(&pdev->dev);
> > > > else
> > > > priv_match = dev_get_platdata(&pdev->dev);
> > > >
> > > > if (priv_match) {
> > > > priv = hcd_to_xhci_priv(hcd);
> > > > /* Just copy data for now */
> > > > *priv = *priv_match;
> > > > }
> > > > --
> > > >
> > > > Thanks,
> > > > Peter Chen
>
> --
>
> Thanks,
> Peter Chen
Re: [PATCH] usb: host: xhci-plat: fix support for XHCI_SKIP_PHY_INIT quirk
On 20-12-22 14:30:51, Pali Rohár wrote:
> On Tuesday 22 December 2020 10:23:27 Pali Rohár wrote:
> > On Tuesday 22 December 2020 02:14:45 Peter Chen wrote:
> > > On 20-12-21 16:09:03, Pali Rohár wrote:
> > > > Currently init_quirk callbacks for xhci platform drivers are called
> > > > xhci_plat_setup() function which is called after chip reset completes.
> > > > It happens in the middle of the usb_add_hcd() function.
> > > >
> > > > But XHCI_SKIP_PHY_INIT quirk is checked in the xhci_plat_probe()
> > > > function
> > > > prior calling usb_add_hcd() function. Therefore this XHCI_SKIP_PHY_INIT
> > > > currently does nothing as prior xhci_plat_setup() it is not set.
> > > >
> > > > Quirk XHCI_SKIP_PHY_INIT is only setting hcd->skip_phy_initialization
> > > > value
> > > > which really needs to be set prior calling usb_add_hcd() as this
> > > > function
> > > > at its beginning skips PHY init if this member is set.
> > > >
> > > > This patch fixes implementation of the XHCI_SKIP_PHY_INIT quirk by
> > > > calling
> > > > init_quirk callbacks (via xhci_priv_init_quirk()) prior checking if
> > > > XHCI_SKIP_PHY_INIT is set.
> > > >
> > > > Fixes: f768e718911e0 ("usb: host: xhci-plat: add priv quirk for skip
> > > > PHY initialization")
> > > > Signed-off-by: Pali Rohár
Hi Pali,
I know your case, you need to choose XHCI_SKIP_PHY_INIT quirk
conditionally, but you may can't add Fixes tag at your patch
since your issue was existed before my patch.
Peter
> > > > ---
> > > > drivers/usb/host/xhci-plat.c | 14 +++---
> > > > 1 file changed, 7 insertions(+), 7 deletions(-)
> > > >
> > > > diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> > > > index 4d34f6005381..58704c5b002b 100644
> > > > --- a/drivers/usb/host/xhci-plat.c
> > > > +++ b/drivers/usb/host/xhci-plat.c
> > > > @@ -89,13 +89,6 @@ static void xhci_plat_quirks(struct device *dev,
> > > > struct xhci_hcd *xhci)
> > > > /* called during probe() after chip reset completes */
> > > > static int xhci_plat_setup(struct usb_hcd *hcd)
> > > > {
> > > > - int ret;
> > > > -
> > > > -
> > > > - ret = xhci_priv_init_quirk(hcd);
> > > > - if (ret)
> > > > - return ret;
> > > > -
> > > > return xhci_gen_setup(hcd, xhci_plat_quirks);
> > > > }
> > > >
> > > > @@ -330,6 +323,13 @@ static int xhci_plat_probe(struct platform_device
> > > > *pdev)
> > > >
> > > > hcd->tpl_support = of_usb_host_tpl_support(sysdev->of_node);
> > > > xhci->shared_hcd->tpl_support = hcd->tpl_support;
> > > > +
> > > > + if (priv) {
> > > > + ret = xhci_priv_init_quirk(hcd);
> > > > + if (ret)
> > > > + goto disable_usb_phy;
> > > > + }
> > > > +
> > > > if (priv && (priv->quirks & XHCI_SKIP_PHY_INIT))
> > > > hcd->skip_phy_initialization = 1;
> > > >
> > >
> > > Hi Pali,
> > >
> > > What's problem you have met? In structure xhci_plat_priv, the quirks are
> > > defined at .quirks entry which is got at below code. .init_quirk is the
> > > routine if special initializations are needed.
> >
> > Hello!
> >
> > I'm talking about .init_quirk. And if XHCI_SKIP_PHY_INIT quirk is set in
> > this function then has no effect.
>
> Ok, this patch is not enough, I will send V2.
>
> > I'm working currently on patch for xhci mvebu which conditionally enable
> > or disable XHCI_SKIP_PHY_INIT quirk (it is going to fix existing
> > regression since v5.1 kernel) and without this patch XHCI_SKIP_PHY_INIT
> > quirk from the init_quirk does not work.
>
> And now I have tested V2 with my mvebu regression fix. I will send it to
> mailing list for review.
>
> > > if (pdev->dev.of_node)
> > > priv_match = of_device_get_match_data(&pdev->dev);
> > > else
> > > priv_match = dev_get_platdata(&pdev->dev);
> > >
> > > if (priv_match) {
> > > priv = hcd_to_xhci_priv(hcd);
> > > /* Just copy data for now */
> > > *priv = *priv_match;
> > > }
> > > --
> > >
> > > Thanks,
> > > Peter Chen
--
Thanks,
Peter Chen
Re: [PATCH v13 3/6] kexec: Use fdt_appendprop_addrrange() to add ima buffer to FDT
Lakshmi Ramasubramanian writes: > fdt_appendprop_addrrange() function adds a property, with the given name, > to the device tree at the given node offset, and also sets the address > and size of the property. This function should be used to add > "linux,ima-kexec-buffer" property to the device tree and set the address > and size of the IMA measurement buffer, instead of using custom function. > > Use fdt_appendprop_addrrange() to add "linux,ima-kexec-buffer" property > to the device tree. This property holds the address and size of > the IMA measurement buffer that needs to be passed from the current > kernel to the next kernel across kexec system call. > > Remove custom code that is used in setup_ima_buffer() to add > "linux,ima-kexec-buffer" property to the device tree. > > Co-developed-by: Prakhar Srivastava > Signed-off-by: Prakhar Srivastava > Signed-off-by: Lakshmi Ramasubramanian > --- > drivers/of/kexec.c | 57 -- > 1 file changed, 5 insertions(+), 52 deletions(-) This is a nice improvement, thanks. Reviewed-by: Thiago Jung Bauermann -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [PATCH] perf stat: Create '--add-default' option to append default list
Hi Arnaldo,
On 12/23/2020 12:15 AM, Arnaldo Carvalho de Melo wrote:
Em Tue, Dec 22, 2020 at 09:11:31AM +0800, Jin Yao escreveu:
The event default list includes the most common events which are widely
used by users. But with -e option, the current perf only counts the events
assigned by -e option. Users may want to collect some extra events with
the default list. For this case, users have to manually add all the events
from the default list. It's inconvenient. Also, users may don't know how to
get the default list.
It's better to add a new option to append default list to the -e events.
The new option is '--add-default'.
Before:
root@kbl-ppc:~# ./perf stat -e power/energy-pkg/ -a -- sleep 1
Performance counter stats for 'system wide':
2.05 Joules power/energy-pkg/
1.000857974 seconds time elapsed
After:
root@kbl-ppc:~# ./perf stat -e power/energy-pkg/ -a --add-default -- sleep 1
I thought about:
perf stat -e +power/energy-pkg/ -a -- sleep 1
I was surprised to see that '+' syntax had been supported.
root@kbl-ppc:~# ./perf stat -e +power/energy-pkg/ -a -- sleep 1
Performance counter stats for 'system wide':
1.99 Joules +power/energy-pkg/
1.000877852 seconds time elapsed
root@kbl-ppc:~# ./perf stat -e +power/energy-pkg/,+cycles -a -- sleep 1
Performance counter stats for 'system wide':
2.00 Joules +power/energy-pkg/
13,780,620+cycles
1.001639147 seconds time elapsed
Are there any scripts or usages need the prefix '+' before event? I don't know. But if we append the
'+' to the default event list, will break something potentially?
Which would have its counterpart:
perf stat -e -cycles -0a --sleep 1
To remove an event from the defaults, perhaps to deal with some specific
hardware where the default or what is in -d, -dd, -ddd, etc can't all be
counted. I.e. - and + would remove or add from whaver list was there at
that point.
- Arnaldo
Yes, + and - are more flexible solution. Just for above question, will '+' break existing
usage? And for '-', I don't know if user can remember clearly for what the events are in default list.
Thanks
Jin Yao
Performance counter stats for 'system wide':
2.10 Joules power/energy-pkg/ #0.000 K/sec
8,009.89 msec cpu-clock #7.995 CPUs utilized
140context-switches #0.017 K/sec
9cpu-migrations#0.001 K/sec
66page-faults #0.008 K/sec
10,671,929cycles#0.001 GHz
4,736,880instructions #0.44 insn per cycle
942,951branches #0.118 M/sec
76,096branch-misses #8.07% of all branches
1.001809960 seconds time elapsed
Signed-off-by: Jin Yao
---
tools/perf/Documentation/perf-stat.txt | 5 +
tools/perf/builtin-stat.c | 4 +++-
tools/perf/util/stat.h | 1 +
3 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/perf/Documentation/perf-stat.txt
b/tools/perf/Documentation/perf-stat.txt
index 5d4a673d7621..75a83c2e4dc5 100644
--- a/tools/perf/Documentation/perf-stat.txt
+++ b/tools/perf/Documentation/perf-stat.txt
@@ -438,6 +438,11 @@ convenient for post processing.
--summary::
Print summary for interval mode (-I).
+--add-default::
+The default event list includes the most common events which are widely
+used by users. But with -e option, the perf only counts the events assigned
+by -e option. This options appends the default event list to the -e events.
+
EXAMPLES
diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
index 89c32692f40c..6ac7b946f9a7 100644
--- a/tools/perf/builtin-stat.c
+++ b/tools/perf/builtin-stat.c
@@ -1173,6 +1173,8 @@ static struct option stat_options[] = {
"print summary for interval mode"),
OPT_BOOLEAN(0, "quiet", &stat_config.quiet,
"don't print output (useful with record)"),
+ OPT_BOOLEAN(0, "add-default", &stat_config.add_default,
+ "add default events"),
#ifdef HAVE_LIBPFM
OPT_CALLBACK(0, "pfm-events", &evsel_list, "event",
"libpfm4 event selector. use 'perf list' to list available
events",
@@ -1755,7 +1757,7 @@ static int add_default_attributes(void)
free(str);
}
- if (!evsel_list->core.nr_entries) {
+ if (!evsel_list->core.nr_entries || stat_config.add_default) {
if (target__has_cpu(&target))
default_attrs0[0].config = PERF_COUNT_SW_CPU_CLOCK;
diff --git a/tools/perf/util/stat.h b/tools/perf/util/stat.h
index 9979b4b100f2..6ccc6936348c 100644
--- a/tools/perf/util/stat.h
+++ b/tools/perf/util/stat.h
@@ -123,6 +123,7 @@ struct
Re: [PATCH 2/4] dt-bindings: net: Add bindings for Qualcomm QCA807x
> + gpio-controller: true > + "#gpio-cells": > +const: 2 > + > + qcom,single-led-1000: > +description: | > + If present, then dedicated 1000 Mbit will light up for 1000Base-T. > + This is a workround for boards with a single LED instead of two. > +type: boolean > + > + qcom,single-led-100: > +description: | > + If present, then dedicated 1000 Mbit will light up for 100Base-TX. > + This is a workround for boards with a single LED instead of two. > +type: boolean > + > + qcom,single-led-10: > +description: | > + If present, then dedicated 1000 Mbit will light up for 10Base-Te. > + This is a workround for boards with a single LED instead of two. > +type: boolean Sorry, but no. Please look at the work being done for allow PHY LEDs to be controlled via the LED subsystem. > + qcom,tx-driver-strength: > +description: PSGMII/QSGMII TX driver strength control. > +$ref: /schemas/types.yaml#/definitions/uint32 > +enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12] Please use the actual values here, and have the driver convert to the value poked into the register. So the property would be qcom,tx-driver-strength-mv and it would have the value 220 for example. > + > + qcom,control-dac: > +description: Analog MDI driver amplitude and bias current. > +$ref: /schemas/types.yaml#/definitions/uint32 > +enum: [0, 1, 2, 3, 4, 5, 6, 7] Make here. Andrew
[PATCH] hwmon: k10temp: Zen3 Ryzen Desktop CPUs support
The module has only support for Zen3 server CPUs right now.
Add support for Family 0x19, model 0x21 which are Zen3 Ryzen Desktop CPUs.
Tested on 5800x, 5900x and 5950x CPUs.
Signed-off-by: Gabriel Craciunescu
---
drivers/hwmon/k10temp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/hwmon/k10temp.c b/drivers/hwmon/k10temp.c
index 3bc2551577a3..5b1677d85b3f 100644
--- a/drivers/hwmon/k10temp.c
+++ b/drivers/hwmon/k10temp.c
@@ -448,7 +448,8 @@ static int k10temp_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
data->is_zen = true;
switch (boot_cpu_data.x86_model) {
- case 0x0 ... 0x1: /* Zen3 */
+ case 0x0 ... 0x1: /* Zen3 SP3/TR */
+ case 0x21: /* ZEN3 Ryzen Desktop */
k10temp_get_ccd_support(pdev, data, 8);
break;
}
--
2.29.2
[PATCH v3 3/3] iommu/vt-d: Disable SVM in the platform when IOMMUs have inconsistencies
Some IOMMU Capabilities must be consistent for Shared Virtual Memory (SVM).
Audit IOMMU Capability/Extended Capabilities and check if IOMMUs have
the consistent value for features as below. When the features are not
matched among IOMMUs, disable SVMs in the platform during DMAR
initialization. Audit IOMMUs again when a device is hot plugged.
Disable Shared Virtual Memory when below features are mistmatched:
- First Level Translation Support (FLTS)
- Process Address Space ID Support (PASID)
- Extended Accessed Flag Support (EAFS)
- Supervisor Support (SRS)
- Execute Request Support (ERS)
- Page Request Support (PRS)
Signed-off-by: Kyung Min Park
---
drivers/iommu/intel/cap_audit.c | 11 +++
drivers/iommu/intel/cap_audit.h | 6 ++
drivers/iommu/intel/svm.c | 3 ++-
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/cap_audit.c b/drivers/iommu/intel/cap_audit.c
index cf5326eb1d72..e6f8616edc3d 100644
--- a/drivers/iommu/intel/cap_audit.c
+++ b/drivers/iommu/intel/cap_audit.c
@@ -130,6 +130,12 @@ static int cap_audit_hotplug(struct intel_iommu *iommu,
enum cap_audit_type type
MINIMAL_FEATURE_HOTPLUG(iommu, ecap, max_handle_mask, ECAP_MHMV_MASK,
mismatch);
MINIMAL_FEATURE_HOTPLUG(iommu, ecap, iotlb_offset, ECAP_IRO_MASK,
mismatch);
+ if (IS_ENABLED(CONFIG_INTEL_IOMMU_SVM) &&
+ intel_cap_svm_santiy() && !ecap_svm_sanity(iommu->ecap)) {
+ pr_warn("Abort Hot Plug IOMMU: SVM inconsistent\n");
+ mismatch = true;
+ }
+
out:
if (mismatch) {
intel_iommu_cap_sanity = old_cap;
@@ -206,3 +212,8 @@ bool intel_cap_flts_sanity(void)
{
return ecap_flts(intel_iommu_ecap_sanity);
}
+
+bool intel_cap_svm_santiy(void)
+{
+ return ecap_svm_sanity(intel_iommu_ecap_sanity);
+}
diff --git a/drivers/iommu/intel/cap_audit.h b/drivers/iommu/intel/cap_audit.h
index 1ce1dc314950..beb2589e97e0 100644
--- a/drivers/iommu/intel/cap_audit.h
+++ b/drivers/iommu/intel/cap_audit.h
@@ -60,6 +60,11 @@
#define ECAP_QI_MASK BIT_ULL(1)
#define ECAP_C_MASKBIT_ULL(0)
+#define MINIMAL_SVM_ECAP (ECAP_FLTS_MASK | ECAP_PASID_MASK | ECAP_EAFS_MASK | \
+ ECAP_SRS_MASK | ECAP_ERS_MASK | ECAP_PRS_MASK)
+
+#define ecap_svm_sanity(e) (!(((e) & MINIMAL_SVM_ECAP) ^ MINIMAL_SVM_ECAP))
+
#define DO_CHECK_FEATURE_MISMATCH(a, b, cap, feature, MASK) \
do { \
if (cap##_##feature(a) != cap##_##feature(b)) { \
@@ -107,6 +112,7 @@ bool intel_cap_smts_sanity(void);
bool intel_cap_pasid_sanity(void);
bool intel_cap_nest_sanity(void);
bool intel_cap_flts_sanity(void);
+bool intel_cap_svm_santiy(void);
static inline bool scalable_mode_support(void)
{
diff --git a/drivers/iommu/intel/svm.c b/drivers/iommu/intel/svm.c
index f1861fa3d0e4..8a116c43f219 100644
--- a/drivers/iommu/intel/svm.c
+++ b/drivers/iommu/intel/svm.c
@@ -22,6 +22,7 @@
#include
#include "pasid.h"
+#include "cap_audit.h"
static irqreturn_t prq_event_thread(int irq, void *d);
static void intel_svm_drain_prq(struct device *dev, u32 pasid);
@@ -98,7 +99,7 @@ static inline bool intel_svm_capable(struct intel_iommu
*iommu)
void intel_svm_check(struct intel_iommu *iommu)
{
- if (!pasid_supported(iommu))
+ if (!intel_cap_svm_santiy())
return;
if (cpu_feature_enabled(X86_FEATURE_GBPAGES) &&
--
2.17.1
[PATCH v3 1/3] iommu/vt-d: Audit IOMMU Capabilities and add helper functions
Audit IOMMU Capability/Extended Capability and check if the IOMMUs have
the consistent value for features. Report out or scale to the lowest
supported when IOMMU features have incompatibility among IOMMUs.
Report out features when below features are mismatched:
- First Level 5 Level Paging Support (FL5LP)
- First Level 1 GByte Page Support (FL1GP)
- Read Draining (DRD)
- Write Draining (DWD)
- Page Selective Invalidation (PSI)
- Zero Length Read (ZLR)
- Caching Mode (CM)
- Protected High/Low-Memory Region (PHMR/PLMR)
- Required Write-Buffer Flushing (RWBF)
- Advanced Fault Logging (AFL)
- RID-PASID Support (RPS)
- Scalable Mode Page Walk Coherency (SMPWC)
- First Level Translation Support (FLTS)
- Second Level Translation Support (SLTS)
- No Write Flag Support (NWFS)
- Second Level Accessed/Dirty Support (SLADS)
- Virtual Command Support (VCS)
- Scalable Mode Translation Support (SMTS)
- Device TLB Invalidation Throttle (DIT)
- Page Drain Support (PDS)
- Process Address Space ID Support (PASID)
- Extended Accessed Flag Support (EAFS)
- Supervisor Request Support (SRS)
- Execute Request Support (ERS)
- Page Request Support (PRS)
- Nested Translation Support (NEST)
- Snoop Control (SC)
- Pass Through (PT)
- Device TLB Support (DT)
- Queued Invalidation (QI)
- Page walk Coherency (C)
Set capability to the lowest supported when below features are mismatched:
- Maximum Address Mask Value (MAMV)
- Number of Fault Recording Registers (NFR)
- Second Level Large Page Support (SLLPS)
- Fault Recording Offset (FRO)
- Maximum Guest Address Width (MGAW)
- Supported Adjusted Guest Address Width (SAGAW)
- Number of Domains supported (NDOMS)
- Pasid Size Supported (PSS)
- Maximum Handle Mask Value (MHMV)
- IOTLB Register Offset (IRO)
Signed-off-by: Kyung Min Park
---
drivers/iommu/intel/Makefile| 2 +-
drivers/iommu/intel/cap_audit.c | 188
drivers/iommu/intel/cap_audit.h | 106
drivers/iommu/intel/iommu.c | 9 ++
drivers/iommu/intel/irq_remapping.c | 8 ++
include/linux/intel-iommu.h | 39 +++---
6 files changed, 333 insertions(+), 19 deletions(-)
create mode 100644 drivers/iommu/intel/cap_audit.c
create mode 100644 drivers/iommu/intel/cap_audit.h
diff --git a/drivers/iommu/intel/Makefile b/drivers/iommu/intel/Makefile
index fb8e1e8c8029..e3576a62612b 100644
--- a/drivers/iommu/intel/Makefile
+++ b/drivers/iommu/intel/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
obj-$(CONFIG_DMAR_TABLE) += dmar.o
obj-$(CONFIG_INTEL_IOMMU) += iommu.o pasid.o
-obj-$(CONFIG_INTEL_IOMMU) += trace.o
+obj-$(CONFIG_INTEL_IOMMU) += trace.o cap_audit.o
obj-$(CONFIG_INTEL_IOMMU_DEBUGFS) += debugfs.o
obj-$(CONFIG_INTEL_IOMMU_SVM) += svm.o
obj-$(CONFIG_IRQ_REMAP) += irq_remapping.o
diff --git a/drivers/iommu/intel/cap_audit.c b/drivers/iommu/intel/cap_audit.c
new file mode 100644
index ..4a062fc719d2
--- /dev/null
+++ b/drivers/iommu/intel/cap_audit.c
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * cap_audit.c - audit iommu capabilities for boot time and hot plug
+ *
+ * Copyright (C) 2020 Intel Corporation
+ *
+ * Author: Kyung Min Park
+ * Lu Baolu
+ */
+
+#define pr_fmt(fmt)"DMAR: " fmt
+
+#include
+#include "cap_audit.h"
+
+static u64 intel_iommu_cap_sanity;
+static u64 intel_iommu_ecap_sanity;
+
+static inline void check_irq_capabilities(struct intel_iommu *a,
+ struct intel_iommu *b)
+{
+ CHECK_FEATURE_MISMATCH(a, b, cap, pi_support, CAP_PI_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, ecap, eim_support, ECAP_EIM_MASK);
+}
+
+static inline void check_dmar_capabilities(struct intel_iommu *a,
+ struct intel_iommu *b)
+{
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_MAMV_MASK);
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_NFR_MASK);
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_SLLPS_MASK);
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_FRO_MASK);
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_MGAW_MASK);
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_SAGAW_MASK);
+ MINIMAL_FEATURE_IOMMU(b, cap, CAP_NDOMS_MASK);
+ MINIMAL_FEATURE_IOMMU(b, ecap, ECAP_PSS_MASK);
+ MINIMAL_FEATURE_IOMMU(b, ecap, ECAP_MHMV_MASK);
+ MINIMAL_FEATURE_IOMMU(b, ecap, ECAP_IRO_MASK);
+
+ CHECK_FEATURE_MISMATCH(a, b, cap, 5lp_support, CAP_FL5LP_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, fl1gp_support, CAP_FL1GP_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, read_drain, CAP_RD_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, write_drain, CAP_WD_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, pgsel_inv, CAP_PSI_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, zlr, CAP_ZLR_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, caching_mode, CAP_CM_MASK);
+ CHECK_FEATURE_MISMATCH(a, b, cap, phmr, CAP_PHMR_MASK);
+ CHECK_FEATURE_MISMATCH(a, b,
[PATCH v3 2/3] iommu/vt-d: Move capability check code to cap_audit files
Move IOMMU capability check and sanity check code to cap_audit files.
Also implement some helper functions for sanity checks.
Signed-off-by: Kyung Min Park
---
drivers/iommu/intel/cap_audit.c | 20 +
drivers/iommu/intel/cap_audit.h | 20 +
drivers/iommu/intel/iommu.c | 76 +
3 files changed, 42 insertions(+), 74 deletions(-)
diff --git a/drivers/iommu/intel/cap_audit.c b/drivers/iommu/intel/cap_audit.c
index 4a062fc719d2..cf5326eb1d72 100644
--- a/drivers/iommu/intel/cap_audit.c
+++ b/drivers/iommu/intel/cap_audit.c
@@ -186,3 +186,23 @@ int intel_cap_audit(enum cap_audit_type type, struct
intel_iommu *iommu)
return -EFAULT;
}
+
+bool intel_cap_smts_sanity(void)
+{
+ return ecap_smts(intel_iommu_ecap_sanity);
+}
+
+bool intel_cap_pasid_sanity(void)
+{
+ return ecap_pasid(intel_iommu_ecap_sanity);
+}
+
+bool intel_cap_nest_sanity(void)
+{
+ return ecap_nest(intel_iommu_ecap_sanity);
+}
+
+bool intel_cap_flts_sanity(void)
+{
+ return ecap_flts(intel_iommu_ecap_sanity);
+}
diff --git a/drivers/iommu/intel/cap_audit.h b/drivers/iommu/intel/cap_audit.h
index 866236581dd3..1ce1dc314950 100644
--- a/drivers/iommu/intel/cap_audit.h
+++ b/drivers/iommu/intel/cap_audit.h
@@ -103,4 +103,24 @@ enum cap_audit_type {
CAP_AUDIT_HOTPLUG_IRQR,
};
+bool intel_cap_smts_sanity(void);
+bool intel_cap_pasid_sanity(void);
+bool intel_cap_nest_sanity(void);
+bool intel_cap_flts_sanity(void);
+
+static inline bool scalable_mode_support(void)
+{
+ return (intel_iommu_sm && intel_cap_smts_sanity());
+}
+
+static inline bool pasid_mode_support(void)
+{
+ return scalable_mode_support() && intel_cap_pasid_sanity();
+}
+
+static inline bool nested_mode_support(void)
+{
+ return scalable_mode_support() && intel_cap_nest_sanity();
+}
+
int intel_cap_audit(enum cap_audit_type type, struct intel_iommu *iommu);
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 592cb6dd5d3a..676f6900f4dc 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -1846,25 +1846,7 @@ static void free_dmar_iommu(struct intel_iommu *iommu)
*/
static bool first_level_by_default(void)
{
- struct dmar_drhd_unit *drhd;
- struct intel_iommu *iommu;
- static int first_level_support = -1;
-
- if (likely(first_level_support != -1))
- return first_level_support;
-
- first_level_support = 1;
-
- rcu_read_lock();
- for_each_active_iommu(iommu, drhd) {
- if (!sm_supported(iommu) || !ecap_flts(iommu->ecap)) {
- first_level_support = 0;
- break;
- }
- }
- rcu_read_unlock();
-
- return first_level_support;
+ return scalable_mode_support() && intel_cap_flts_sanity();
}
static struct dmar_domain *alloc_domain(int flags)
@@ -5663,60 +5645,6 @@ static phys_addr_t intel_iommu_iova_to_phys(struct
iommu_domain *domain,
return phys;
}
-static inline bool scalable_mode_support(void)
-{
- struct dmar_drhd_unit *drhd;
- struct intel_iommu *iommu;
- bool ret = true;
-
- rcu_read_lock();
- for_each_active_iommu(iommu, drhd) {
- if (!sm_supported(iommu)) {
- ret = false;
- break;
- }
- }
- rcu_read_unlock();
-
- return ret;
-}
-
-static inline bool iommu_pasid_support(void)
-{
- struct dmar_drhd_unit *drhd;
- struct intel_iommu *iommu;
- bool ret = true;
-
- rcu_read_lock();
- for_each_active_iommu(iommu, drhd) {
- if (!pasid_supported(iommu)) {
- ret = false;
- break;
- }
- }
- rcu_read_unlock();
-
- return ret;
-}
-
-static inline bool nested_mode_support(void)
-{
- struct dmar_drhd_unit *drhd;
- struct intel_iommu *iommu;
- bool ret = true;
-
- rcu_read_lock();
- for_each_active_iommu(iommu, drhd) {
- if (!sm_supported(iommu) || !ecap_nest(iommu->ecap)) {
- ret = false;
- break;
- }
- }
- rcu_read_unlock();
-
- return ret;
-}
-
static bool intel_iommu_capable(enum iommu_cap cap)
{
if (cap == IOMMU_CAP_CACHE_COHERENCY)
@@ -5970,7 +5898,7 @@ intel_iommu_dev_has_feat(struct device *dev, enum
iommu_dev_features feat)
int ret;
if (!dev_is_pci(dev) || dmar_disabled ||
- !scalable_mode_support() || !iommu_pasid_support())
+ !scalable_mode_support() || !pasid_mode_support())
return false;
ret = pci_pasid_features(to_pci_dev(dev));
--
2.17.1
[PATCH v3 0/3] Audit Capability and Extended Capability among IOMMUs
Modern platforms have more than one IOMMU. Each IOMMU has its own feature set. Some of these features must be consistent among IOMMUs. Otherwise, these differences can lead to improper behavior in the system. On the other hand, for some features, each IOMMU can have different capacity values. So, different actions are required to deal with the inconsistencies depending on the IOMMU features. Currently, some inconsistencies are ignored by the IOMMU driver. This patchset checks IOMMU capabilities and extended capabilities centralizedly during boot and take different actions according to the impacts caused by the mismatches. For example: 1. Disable Shared Virtual Memory. 2. Use common capacity values (normally the lowest capacity value) for all IOMMUs. 3. Report feature mismatches. Detailed information on the IOMMU Capability / Extended Capability can be found in Intel VT-d Specification. Link: https://software.intel.com/sites/default/files/managed/c5/15/vt-directed-io-spec.pdf ChangeLog: - Change from v2 to v3: 1. fix the wrong macro names and rebase to v5.10. - Change from v1 to v2: 1. Add missing cap/ecaps for audit. 2. Refactor function/macros overal suggested by Lu, Baolu. 2. Skip audit for gfx dedicated IOMMU. 3. Change commit message. Kyung Min Park (3): iommu/vt-d: Audit IOMMU Capabilities and add helper functions iommu/vt-d: Move capability check code to cap_audit files iommu/vt-d: Disable SVM in the platform when IOMMUs have inconsistencies drivers/iommu/intel/Makefile| 2 +- drivers/iommu/intel/cap_audit.c | 219 drivers/iommu/intel/cap_audit.h | 132 + drivers/iommu/intel/iommu.c | 85 ++- drivers/iommu/intel/irq_remapping.c | 8 + drivers/iommu/intel/svm.c | 3 +- include/linux/intel-iommu.h | 39 ++--- 7 files changed, 394 insertions(+), 94 deletions(-) create mode 100644 drivers/iommu/intel/cap_audit.c create mode 100644 drivers/iommu/intel/cap_audit.h -- 2.17.1
Re: [PATCH v13 2/6] powerpc: Move arch independent ima kexec functions to drivers/of/kexec.c
Actually, I have one more comment on this patch:
Lakshmi Ramasubramanian writes:
> diff --git a/arch/powerpc/kexec/file_load.c b/arch/powerpc/kexec/file_load.c
> index 956bcb2d1ec2..9f3ec0b239ef 100644
> --- a/arch/powerpc/kexec/file_load.c
> +++ b/arch/powerpc/kexec/file_load.c
> @@ -20,7 +20,6 @@
> #include
> #include
> #include
> -#include
>
> #define SLAVE_CODE_SIZE 256 /* First 0x100 bytes */
>
> @@ -163,12 +162,6 @@ int setup_new_fdt(const struct kimage *image, void *fdt,
> if (ret)
> goto err;
>
> - ret = setup_ima_buffer(image, fdt, fdt_path_offset(fdt, "/chosen"));
> - if (ret) {
> - pr_err("Error setting up the new device tree.\n");
> - return ret;
> - }
> -
> return 0;
>
> err:
With this change, setup_new_fdt() is nothing more than a call to
of_kexec_setup_new_fdt(). It should be removed, and its caller should
call of_kexec_setup_new_fdt() directly.
This change could be done in patch 4 of this series, to keep this patch
simpler.
--
Thiago Jung Bauermann
IBM Linux Technology Center
[GIT PULL] Smack additional patch for v5.11
Hello Linus Sorry for the 2nd pull request, but this is a fairly important fix for the privilege handling of smackfs in the face of io_uring. The novel use of kernel threads in io_uring invalidated an long standing assumption regarding the privilege of kernel threads. The fix is simple and safe. It was provided by Jens Axboe and has been tested. -- The following changes since commit 9b0072e2b2b588ad75c94f2c6e6c52c8f4bd2657: security/smack: remove unused varible 'rc' (2020-11-16 17:26:31 -0800) are available in the Git repository at: https://github.com/cschaufler/smack-next smack-for-5.11 for you to fetch changes up to 942cb357ae7d9249088e3687ee6a00ed2745a0c7: Smack: Handle io_uring kernel thread privileges (2020-12-22 15:34:24 -0800) Casey Schaufler (1): Smack: Handle io_uring kernel thread privileges security/smack/smack_access.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
Re: [PATCH v13 2/6] powerpc: Move arch independent ima kexec functions to drivers/of/kexec.c
Lakshmi Ramasubramanian writes: > On 12/22/20 11:45 AM, Mimi Zohar wrote: >> On Tue, 2020-12-22 at 10:53 -0800, Lakshmi Ramasubramanian wrote: >>> On 12/22/20 6:26 AM, Mimi Zohar wrote: >>> >>> Hi Mimi, >>> On Sat, 2020-12-19 at 09:57 -0800, Lakshmi Ramasubramanian wrote: > > diff --git a/arch/powerpc/kexec/Makefile b/arch/powerpc/kexec/Makefile > index 4aff6846c772..b6c52608cb49 100644 > --- a/arch/powerpc/kexec/Makefile > +++ b/arch/powerpc/kexec/Makefile > @@ -9,13 +9,6 @@ obj-$(CONFIG_PPC32) += relocate_32.o > obj-$(CONFIG_KEXEC_FILE)+= file_load.o ranges.o > file_load_$(BITS).o elf_$(BITS).o >-ifdef CONFIG_HAVE_IMA_KEXEC > -ifdef CONFIG_IMA > -obj-y+= ima.o > -endif > -endif Notice how "kexec/ima.o" is only included if the architecture supports it and IMA is configured. In addition only if CONFIG_IMA_KEXEC is configured, is the IMA measurement list carried across kexec. After moving the rest of ima.c to drivers/of/kexec.c, this changes. Notice how drivers/of/Kconfig includes kexec.o: obj-$(CONFIG_KEXEC_FILE) += kexec.o It is not dependent on CONFIG_HAVE_IMA_KEXEC. Shouldn't all of the functions defined in ima.c being moved to kexec.o be defined within a CONFIG_HAVE_IMA_KEXEC ifdef? >>> >>> Thanks for reviewing the changes. >>> >>> In "drivers/of/kexec.c" the function remove_ima_buffer() is defined >>> under "#ifdef CONFIG_HAVE_IMA_KEXEC" >>> >>> setup_ima_buffer() is defined under "#ifdef CONFIG_IMA_KEXEC" - the same >>> way it was defined in "arch/powerpc/kexec/ima.c". >>> >>> As you know, CONFIG_IMA_KEXEC depends on CONFIG_HAVE_IMA_KEXEC (as >>> defined in "security/integrity/ima/Kconfig"). >>> >>> ima_get_kexec_buffer() and ima_free_kexec_buffer() are unconditionally >>> defined in "drivers/of/kexec.c" even though they are called only when >>> CONFIG_HAVE_IMA_KEXEC is enabled. I will update these two functions to >>> be moved under "#ifdef CONFIG_HAVE_IMA_KEXEC" >> The issue is the reverse. CONFIG_HAVE_IMA_KEXEC may be enabled without >> CONFIG_IMA_KEXEC being enabled. This allows the architecture to >> support carrying the measurement list across kexec, but requires >> enabling it at build time. >> Only if CONFIG_HAVE_IMA_KEXEC is enabled should any of these functions >> be compiled at build. This allows restoring the previous IMA >> measurement list, even if CONFIG_IMA_KEXEC is not enabled. >> Only if CONFIG_IMA_KEXEC is enabled, should carrying the measurement >> list across kexec be enabled. See how arch_ima_add_kexec_buffer, >> write_number, setup_ima_buffer are ifdef'ed in >> arch/powerpc/kexec/ima.c. >> > > Yes - I agree. I will make the following changes: > > => Enable the functions moved from "arch/powerpc/kexec/ima.c" to > "drivers/of/kexec.c" only when CONFIG_HAVE_IMA_KEXEC is enabled. > > => Also, compile write_number() and setup_ima_buffer() only when > CONFIG_IMA_KEXEC is enabled. Sounds good, with one additional change: So far, CONFIG_HAVE_IMA_KEXEC was tested only in files that were built when CONFIG_IMA was set. With this series this is not the case anymore (in drivers/of/kexec.c). The simplest way to keep this consistent is to only enable CONFIG_HAVE_IMA_KEXEC if CONFIG_IMA is also set. For example, with this: diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index e9f13fe08492..4ddd17215ecf 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -548,7 +548,7 @@ config KEXEC config KEXEC_FILE bool "kexec file based system call" select KEXEC_CORE - select HAVE_IMA_KEXEC + select HAVE_IMA_KEXEC if IMA select BUILD_BIN2C select KEXEC_ELF depends on PPC64 And then the same thing on the arm64 patch. -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [PATCH v2, 2/2] soc: mediatek: mmsys: Use function call for setting the routing registers
On Thu, 2020-12-17 at 14:04 +0800, Hsin-Yi Wang wrote: > On Wed, Dec 9, 2020 at 9:32 AM Yongqiang Niu > wrote: > > > > Actually, setting the registers for routing, use multiple 'if-else' for > > different > > routes, but this code would be more and more complicated while we > > support more and more SoCs. Change that and use a function call per SoC so > > the > > code will be more portable and clear. > > > > Signed-off-by: Yongqiang Niu > > --- > > drivers/soc/mediatek/mmsys/Makefile | 3 +- > > drivers/soc/mediatek/mmsys/mt2701-mmsys.c | 233 > > + > > drivers/soc/mediatek/mmsys/mtk-mmsys.c| 241 > > +++--- > > include/linux/soc/mediatek/mtk-mmsys.h| 14 ++ > > 4 files changed, 268 insertions(+), 223 deletions(-) > > create mode 100644 drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > > > diff --git a/drivers/soc/mediatek/mmsys/Makefile > > b/drivers/soc/mediatek/mmsys/Makefile > > index 5d976d7..ac03025 100644 > > --- a/drivers/soc/mediatek/mmsys/Makefile > > +++ b/drivers/soc/mediatek/mmsys/Makefile > > @@ -1,2 +1,3 @@ > > # SPDX-License-Identifier: GPL-2.0-only > > -obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o > > \ No newline at end of file > > +obj-$(CONFIG_MTK_MMSYS) += mt2701-mmsys.o > > +obj-$(CONFIG_MTK_MMSYS) += mtk-mmsys.o > > diff --git a/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > new file mode 100644 > > index 000..40576d3 > > --- /dev/null > > +++ b/drivers/soc/mediatek/mmsys/mt2701-mmsys.c > > @@ -0,0 +1,233 @@ > > +// SPDX-License-Identifier: GPL-2.0-only > > +/* > > + * Copyright (c) 2020 MediaTek Inc. > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define DISP_REG_CONFIG_DISP_OVL0_MOUT_EN 0x040 > > +#define DISP_REG_CONFIG_DISP_OVL1_MOUT_EN 0x044 > > +#define DISP_REG_CONFIG_DISP_OD_MOUT_EN0x048 > > +#define DISP_REG_CONFIG_DISP_GAMMA_MOUT_EN 0x04c > > +#define DISP_REG_CONFIG_DISP_UFOE_MOUT_EN 0x050 > > +#define DISP_REG_CONFIG_DISP_COLOR0_SEL_IN 0x084 > > +#define DISP_REG_CONFIG_DISP_COLOR1_SEL_IN 0x088 > > +#define DISP_REG_CONFIG_DSIE_SEL_IN0x0a4 > > +#define DISP_REG_CONFIG_DSIO_SEL_IN0x0a8 > > +#define DISP_REG_CONFIG_DPI_SEL_IN 0x0ac > > +#define DISP_REG_CONFIG_DISP_RDMA2_SOUT0x0b8 > > +#define DISP_REG_CONFIG_DISP_RDMA0_SOUT_EN 0x0c4 > > +#define DISP_REG_CONFIG_DISP_RDMA1_SOUT_EN 0x0c8 > > +#define DISP_REG_CONFIG_MMSYS_CG_CON0 0x100 > > + > > +#define DISP_REG_CONFIG_DISP_OVL_MOUT_EN 0x030 > > +#define DISP_REG_CONFIG_OUT_SEL0x04c > > +#define DISP_REG_CONFIG_DSI_SEL0x050 > > +#define DISP_REG_CONFIG_DPI_SEL0x064 > > + > > +#define OVL0_MOUT_EN_COLOR00x1 > > +#define OD_MOUT_EN_RDMA0 0x1 > > +#define OD1_MOUT_EN_RDMA1 BIT(16) > > +#define UFOE_MOUT_EN_DSI0 0x1 > > +#define COLOR0_SEL_IN_OVL0 0x1 > > +#define OVL1_MOUT_EN_COLOR10x1 > > +#define GAMMA_MOUT_EN_RDMA10x1 > > +#define RDMA0_SOUT_DPI00x2 > > +#define RDMA0_SOUT_DPI10x3 > > +#define RDMA0_SOUT_DSI10x1 > > +#define RDMA0_SOUT_DSI20x4 > > +#define RDMA0_SOUT_DSI30x5 > > +#define RDMA1_SOUT_DPI00x2 > > +#define RDMA1_SOUT_DPI10x3 > > +#define RDMA1_SOUT_DSI10x1 > > +#define RDMA1_SOUT_DSI20x4 > > +#define RDMA1_SOUT_DSI30x5 > > +#define RDMA2_SOUT_DPI00x2 > > +#define RDMA2_SOUT_DPI10x3 > > +#define RDMA2_SOUT_DSI10x1 > > +#define RDMA2_SOUT_DSI20x4 > > +#define RDMA2_SOUT_DSI30x5 > > +#define DPI0_SEL_IN_RDMA1 0x1 > > +#define DPI0_SEL_IN_RDMA2 0x3 > > +#define DPI1_SEL_IN_RDMA1 (0x1 << 8) > > +#define DPI1_SEL_IN_RDMA2 (0x3 << 8) > > +#define DSI0_SEL_IN_RDMA1 0x1 > > +#define DSI0_SEL_IN_RDMA2 0x4 > > +#define DSI1_SEL_IN_RDMA1 0x1 > > +#define DSI1_SEL_IN_RDMA2 0x4 > > +#define DSI2_SEL_IN_RDMA1 (0x1 << 16) > > +#define DSI2_SEL_IN_RDMA2 (0x4 << 16) > > +#define DSI3_SEL_IN_RDMA1 (0x1 << 16) > > +#define DSI3_SEL_IN_RDMA2 (0x4 << 16) > > +#define COLOR1_SEL_IN_OVL1 0x1 > > +
Re: [PATCH v2] power: supply: bq27xxx: Supporrt CHARGE_NOW for bq27z561/bq28z610/bq34z100
On 12/22/20 7:53 PM, Pali Rohár wrote:
> On Tuesday 22 December 2020 19:07:20 Hermes Zhang wrote:
>> From: Hermes Zhang
>>
>> The CHARGE_NOW is map to REG_NAC for all the gauge chips beofre. But for
>> some chips (e.g. bq27z561) which doesn't have the REG_NAC, we use REG_RC
>> (remaining capacity) for CHARGE_NOW.
>>
>> Signed-off-by: Hermes Zhang
>> ---
>>
>> Notes:
>> Set correct REG_RC for all the chips if have
>>
>> keep INVALID_REG_ADDR for bq27521, as we could not find
>> the datasheet and seems no one use it now.
> This chip is used in Nokia N950 and Nokia N9. Pavel implemented kernel
> support, adding to loop.
>
> Public information about it are at:
> https://elinux.org/N950#sn27521_register_map
Thanks for the info. From the link it seem bq27521 have neither NAC and
RC register.
Best Regards,
Hermes
>
>> drivers/power/supply/bq27xxx_battery.c | 35 +-
>> 1 file changed, 34 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/power/supply/bq27xxx_battery.c
>> b/drivers/power/supply/bq27xxx_battery.c
>> index 315e0909e6a4..774aa376653e 100644
>> --- a/drivers/power/supply/bq27xxx_battery.c
>> +++ b/drivers/power/supply/bq27xxx_battery.c
>> @@ -110,6 +110,7 @@ enum bq27xxx_reg_index {
>> BQ27XXX_REG_TTES, /* Time-to-Empty Standby */
>> BQ27XXX_REG_TTECP, /* Time-to-Empty at Constant Power */
>> BQ27XXX_REG_NAC,/* Nominal Available Capacity */
>> +BQ27XXX_REG_RC, /* Remaining Capacity */
>> BQ27XXX_REG_FCC,/* Full Charge Capacity */
>> BQ27XXX_REG_CYCT, /* Cycle Count */
>> BQ27XXX_REG_AE, /* Available Energy */
>> @@ -145,6 +146,7 @@ static u8
>> [BQ27XXX_REG_TTES] = 0x1c,
>> [BQ27XXX_REG_TTECP] = 0x26,
>> [BQ27XXX_REG_NAC] = 0x0c,
>> +[BQ27XXX_REG_RC] = INVALID_REG_ADDR,
>> [BQ27XXX_REG_FCC] = 0x12,
>> [BQ27XXX_REG_CYCT] = 0x2a,
>> [BQ27XXX_REG_AE] = 0x22,
>> @@ -169,6 +171,7 @@ static u8
>> [BQ27XXX_REG_TTES] = 0x1c,
>> [BQ27XXX_REG_TTECP] = 0x26,
>> [BQ27XXX_REG_NAC] = 0x0c,
>> +[BQ27XXX_REG_RC] = INVALID_REG_ADDR,
>> [BQ27XXX_REG_FCC] = 0x12,
>> [BQ27XXX_REG_CYCT] = 0x2a,
>> [BQ27XXX_REG_AE] = INVALID_REG_ADDR,
>> @@ -193,6 +196,7 @@ static u8
>> [BQ27XXX_REG_TTES] = 0x1a,
>> [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
>> [BQ27XXX_REG_NAC] = 0x0c,
>> +[BQ27XXX_REG_RC] = 0x10,
>> [BQ27XXX_REG_FCC] = 0x12,
>> [BQ27XXX_REG_CYCT] = 0x2a,
>> [BQ27XXX_REG_AE] = INVALID_REG_ADDR,
>> @@ -215,6 +219,7 @@ static u8
>> [BQ27XXX_REG_TTES] = 0x1c,
>> [BQ27XXX_REG_TTECP] = 0x26,
>> [BQ27XXX_REG_NAC] = 0x0c,
>> +[BQ27XXX_REG_RC] = 0x10,
>> [BQ27XXX_REG_FCC] = 0x12,
>> [BQ27XXX_REG_CYCT] = 0x2a,
>> [BQ27XXX_REG_AE] = 0x22,
>> @@ -237,6 +242,7 @@ static u8
>> [BQ27XXX_REG_TTES] = 0x1a,
>> [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
>> [BQ27XXX_REG_NAC] = 0x0c,
>> +[BQ27XXX_REG_RC] = 0x10,
>> [BQ27XXX_REG_FCC] = 0x12,
>> [BQ27XXX_REG_CYCT] = 0x1e,
>> [BQ27XXX_REG_AE] = INVALID_REG_ADDR,
>> @@ -257,6 +263,7 @@ static u8
>> [BQ27XXX_REG_TTES] = 0x1c,
>> [BQ27XXX_REG_TTECP] = 0x26,
>> [BQ27XXX_REG_NAC] = 0x0c,
>> +[BQ27XXX_REG_RC] = 0x10,
>> [BQ27XXX_REG_FCC] = 0x12,
>> [BQ27XXX_REG_CYCT] = INVALID_REG_ADDR,
>> [BQ27XXX_REG_AE] = 0x22,
>> @@ -277,6 +284,7 @@ static u8
>> [BQ27XXX_REG_TTES] = 0x1c,
>> [BQ27XXX_REG_TTECP] = 0x26,
>> [BQ27XXX_REG_NAC] = 0x0c,
>> +[BQ27XXX_REG_RC] = 0x10,
>> [BQ27XXX_REG_FCC] = 0x12,
>> [BQ27XXX_REG_CYCT] = 0x2a,
>> [BQ27XXX_REG_AE] = 0x22,
>> @@ -297,6 +305,7 @@ static u8
>> [BQ27XXX_REG_TTES] = 0x1c,
>> [BQ27XXX_REG_TTECP] = 0x26,
>> [BQ27XXX_REG_NAC] = 0x0c,
>> +[BQ27XXX_REG_RC] = 0x10,
>> [BQ27XXX_REG_FCC] = 0x12,
>> [BQ27XXX_REG_CYCT] = 0x2a,
>> [BQ27XXX_REG_AE] = 0x22,
>> @@ -317,6 +326,7 @@ static u8
>> [BQ27XXX_REG_TTES] = 0x1c,
>> [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
>> [BQ27XXX_REG_NAC] = 0x0c,
>> +[BQ27XXX_REG_RC] = 0x10,
>> [BQ27XXX_REG_FCC] = 0x12,
>> [BQ27XXX_REG_CYCT] = 0x1e,
>> [BQ27XXX_REG_AE] = INVALID_REG_ADDR,
>> @@ -337,6 +347,7 @@ static u8
>> [BQ27XXX_REG_TTES] = INVALID_REG_ADDR,
>> [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
>> [BQ27XXX_REG_NAC] = INVALID_REG_ADDR,
>> +[BQ27XXX_REG_RC] = I
Re: [PATCH v1, 4/5] soc: mediatek: cmdq: add address shift in jump
On Wed, 2020-12-09 at 23:16 +0800, Chun-Kuang Hu wrote:
> Hi, Yongqiang:
>
> Nicolas Boichat 於 2020年12月5日 週六 下午3:30寫道：
> >
> > On Sat, Dec 5, 2020 at 12:16 PM Yongqiang Niu
> > wrote:
> > >
> > > Add address shift when compose jump instruction
> > > to compatible with 35bit format.
> >
> > This looks reasonable, but task->cmdq->shift_pa is not new and was
> > introduced as part of mt6779 GCE support.
> >
> > Do you want to add a Fixes tag?
> > Fixes: 0858fde496f8 ("mailbox: cmdq: variablize address shift in platform")
>
> Add this fixes tag, and move this patch out of this series because
> this patch is related to all SoC whose shift_pa is not zero.
>
> Regards,
> Chun-Kuang.
>
the next version will move this out of 8192 series and add fixed tags
> >
> > Reviewed-by: Nicolas Boichat
> >
> > >
> > > Signed-off-by: Yongqiang Niu
> > > ---
> > > drivers/mailbox/mtk-cmdq-mailbox.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> > > b/drivers/mailbox/mtk-cmdq-mailbox.c
> > > index 1c01fe0..5ed39f8 100644
> > > --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> > > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> > > @@ -174,7 +174,8 @@ static void cmdq_task_insert_into_thread(struct
> > > cmdq_task *task)
> > > dma_sync_single_for_cpu(dev, prev_task->pa_base,
> > > prev_task->pkt->cmd_buf_size,
> > > DMA_TO_DEVICE);
> > > prev_task_base[CMDQ_NUM_CMD(prev_task->pkt) - 1] =
> > > - (u64)CMDQ_JUMP_BY_PA << 32 | task->pa_base;
> > > + (u64)CMDQ_JUMP_BY_PA << 32 |
> > > + (task->pa_base >> task->cmdq->shift_pa);
> > > dma_sync_single_for_device(dev, prev_task->pa_base,
> > >prev_task->pkt->cmd_buf_size,
> > > DMA_TO_DEVICE);
> > >
> > > --
> > > 1.8.1.1.dirty
> > > ___
> > > Linux-mediatek mailing list
> > > linux-media...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-mediatek
> >
> > ___
> > Linux-mediatek mailing list
> > linux-media...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-mediatek
Re: [PATCH v1, 3/5] mailbox: mediatek: add control_by_sw private data
On Sat, 2020-12-05 at 15:35 +0800, Nicolas Boichat wrote:
> On Sat, Dec 5, 2020 at 12:18 PM Yongqiang Niu
> wrote:
> >
> > add control_by_sw private data
>
> Can you describe in a bit more details what this means?
gce works well without this patch, and it will be removed in
next version
>
> >
> > Signed-off-by: Yongqiang Niu
> > ---
> > drivers/mailbox/mtk-cmdq-mailbox.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> > b/drivers/mailbox/mtk-cmdq-mailbox.c
> > index 5665b6e..1c01fe0 100644
> > --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> > +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> > @@ -36,6 +36,8 @@
> > #define CMDQ_THR_WAIT_TOKEN0x30
> > #define CMDQ_THR_PRIORITY 0x40
> >
> > +#define GCE_GCTL_VALUE 0x48
> > +
> > #define CMDQ_THR_ACTIVE_SLOT_CYCLES0x3200
> > #define CMDQ_THR_ENABLED 0x1
> > #define CMDQ_THR_DISABLED 0x0
> > @@ -76,11 +78,13 @@ struct cmdq {
> > struct clk *clock;
> > boolsuspended;
> > u8 shift_pa;
> > + boolcontrol_by_sw;
> > };
> >
> > struct gce_plat {
> > u32 thread_nr;
> > u8 shift;
> > + bool control_by_sw;
> > };
> >
> > u8 cmdq_get_shift_pa(struct mbox_chan *chan)
> > @@ -121,6 +125,8 @@ static void cmdq_init(struct cmdq *cmdq)
> > int i;
> >
> > WARN_ON(clk_enable(cmdq->clock) < 0);
> > + if (cmdq->control_by_sw)
> > + writel(0x7, cmdq->base + GCE_GCTL_VALUE);
>
> What is 0x7? Define a macro for these bits?
>
> > writel(CMDQ_THR_ACTIVE_SLOT_CYCLES, cmdq->base +
> > CMDQ_THR_SLOT_CYCLES);
> > for (i = 0; i <= CMDQ_MAX_EVENT; i++)
> > writel(i, cmdq->base + CMDQ_SYNC_TOKEN_UPDATE);
> > @@ -536,6 +542,7 @@ static int cmdq_probe(struct platform_device *pdev)
> >
> > cmdq->thread_nr = plat_data->thread_nr;
> > cmdq->shift_pa = plat_data->shift;
> > + cmdq->control_by_sw = plat_data->control_by_sw;
> > cmdq->irq_mask = GENMASK(cmdq->thread_nr - 1, 0);
> > err = devm_request_irq(dev, cmdq->irq, cmdq_irq_handler,
> > IRQF_SHARED,
> >"mtk_cmdq", cmdq);
> > --
> > 1.8.1.1.dirty
> >
[GIT PULL] chrome-platform changes for v5.11
Hi Linus, The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec: Linux 5.10-rc1 (2020-10-25 15:14:11 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git tags/tag-chrome-platform-for-v5.11 for you to fetch changes up to 6ae9b5ffcaeba64c290dfb8bd7b0194b1fdf0c92: platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags (2020-12-10 13:05:16 -0800) chrome platform changes for 5.11 cros_ec_typec: * A series from Prashant for Type-C to implement TYPEC_STATUS, parsing USB PD Partner ID VDOs, and registering partner altmodes. cros_ec misc: * Don't treat RTC events as wakeup sources in cros_ec_proto Prashant Malani (8): platform/chrome: cros_ec_typec: Relocate set_port_params_v*() functions platform/chrome: cros_ec_typec: Fix remove partner logic platform/chrome: cros_ec_typec: Clear partner identity on device removal platform/chrome: cros_ec: Import Type C host commands platform/chrome: cros_ec_typec: Introduce TYPEC_STATUS platform/chrome: cros_ec_typec: Parse partner PD ID VDOs platform/chrome: cros_ec_typec: Register partner altmodes platform/chrome: cros_ec_typec: Tolerate unrecognized mux flags Stephen Boyd (1): platform/chrome: Don't treat RTC events as wakeup sources drivers/platform/chrome/cros_ec_proto.c| 14 +- drivers/platform/chrome/cros_ec_typec.c| 336 +++-- include/linux/platform_data/cros_ec_commands.h | 155 3 files changed, 427 insertions(+), 78 deletions(-) -- Benson Leung Staff Software Engineer Chrome OS Kernel Google Inc. ble...@google.com Chromium OS Project ble...@chromium.org signature.asc Description: PGP signature
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Tue, Dec 22, 2020 at 3:50 PM Linus Torvalds wrote: > > The rule is that the TLB flush has to be done before the page table > lock is released. I take that back. I guess it's ok as long as the mmap_sem is held for writing. Then the TLB flush can be delayed until just before releasing the mmap_sem. I think. The stale TLB entries still mean that somebody else can write through them in another thread, but as long as anybody who actually unmaps the page (and frees it - think rmap etc) is being careful, mprotect() itself can probably afford to be a bit laissez-faire. So mprotect() itself should be ok, I think, because it takes things for writing. Even with the mmap_sem held for writing, truncate and friends can see the read-only page table entries (because they can look things up using the file i_mmap thing instead), but then they rely on the page table lock and they'll also be careful if they then change that PTE and will force their own TLB flushes. So I think a pending TLB flush outside the page table lock is fine - but once again only if you hold the mmap_sem for writing. Not for reading, because then the page tables need to be synchronized with the TLB so that other readers don't see the not-yet-synchronized state. It once again looks like it's just userfaultfd that would trigger this due to the read-lock on the mmap_sem. And mprotect() itself is fine. Am I missing something? But apparently Nadav sees problems even with that lock changed to a write lock. Navad? Linus
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Tue, Dec 22, 2020 at 04:01:45PM -0800, Linus Torvalds wrote: > On Tue, Dec 22, 2020 at 3:50 PM Linus Torvalds > wrote: > > > > See zap_pte_range() for an example of doing it right, even in the > > presence of complexities (ie that has an example of both flushing the > > TLB, and doing the actual "free the pages after flush", and it does > > the two cases separately). > > The more I look at the mprotect code, the less I like it. We seem to > be much better about the TLB flushes in other places (looking at > mremap, for example). The mprotect code seems to be very laissez-faire > about the TLB flushing. > > Does adding a TLB flush to before that > > pte_unmap_unlock(pte - 1, ptl); > > fix things for you? It definitely does. But if I had to choose, I'd go with holding mmap_lock for write because 1) it's less likely to storm other CPUs by IPI and would only have performance impact on processes that use ufd, which I guess already have high tolerance for not-so-good performance, and 2) people are spearheading multiple efforts to reduce the mmap_lock contention, which hopefully would make ufd users suffer less soon. > That's not the right fix - leaving a stale TLB entry around is fine if > the TLB entry is more strict wrt protections - but it might be worth > testing as a "does it at least close the problem" patch. Well, things get trick if we do this. I'm not sure if I could vouch such a fix for stable as confident as I do holding mmap_lock for write.
Re: [PATCH v13 2/6] powerpc: Move arch independent ima kexec functions to drivers/of/kexec.c
Lakshmi Ramasubramanian writes:
> The functions defined in "arch/powerpc/kexec/ima.c" handle setting up
> and freeing the resources required to carry over the IMA measurement
> list from the current kernel to the next kernel across kexec system call.
> These functions do not have architecture specific code, but are
> currently limited to powerpc.
>
> Move setup_ima_buffer() call into of_kexec_setup_new_fdt() defined in
> "drivers/of/kexec.c".
>
> Move the remaining architecture independent functions from
> "arch/powerpc/kexec/ima.c" to "drivers/of/kexec.c".
> Delete "arch/powerpc/kexec/ima.c" and "arch/powerpc/include/asm/ima.h".
> Remove references to the deleted files in powerpc and in ima.
>
> Co-developed-by: Prakhar Srivastava
> Signed-off-by: Prakhar Srivastava
> Signed-off-by: Lakshmi Ramasubramanian
> ---
> arch/powerpc/include/asm/ima.h | 27
> arch/powerpc/kexec/Makefile| 7 -
> arch/powerpc/kexec/file_load.c | 7 -
> arch/powerpc/kexec/ima.c | 202 -
> drivers/of/kexec.c | 235 +
> include/linux/of.h | 2 +
> security/integrity/ima/ima.h | 4 -
> security/integrity/ima/ima_kexec.c | 1 +
> 8 files changed, 238 insertions(+), 247 deletions(-)
> delete mode 100644 arch/powerpc/include/asm/ima.h
> delete mode 100644 arch/powerpc/kexec/ima.c
This looks good, provided the changes from the discussion with Mimi are
made. Also, minor nits below.
> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
> index 6ebefec616e4..7c3947ad3773 100644
> --- a/security/integrity/ima/ima.h
> +++ b/security/integrity/ima/ima.h
> @@ -24,10 +24,6 @@
>
> #include "../integrity.h"
>
> -#ifdef CONFIG_HAVE_IMA_KEXEC
> -#include
> -#endif
> -
> enum ima_show_type { IMA_SHOW_BINARY, IMA_SHOW_BINARY_NO_FIELD_LEN,
>IMA_SHOW_BINARY_OLD_STRING_FMT, IMA_SHOW_ASCII };
> enum tpm_pcrs { TPM_PCR0 = 0, TPM_PCR8 = 8, TPM_PCR10 = 10 };
This belongs in patch 1.
> diff --git a/security/integrity/ima/ima_kexec.c
> b/security/integrity/ima/ima_kexec.c
> index 38bcd7543e27..8a6712981dee 100644
> --- a/security/integrity/ima/ima_kexec.c
> +++ b/security/integrity/ima/ima_kexec.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "ima.h"
This include isn't necessary.
--
Thiago Jung Bauermann
IBM Linux Technology Center
Re: linux-next: build warning after merge of the block tree
On 12/22/20 4:47 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> fs/io_uring.c: In function 'io_uring_get_file':
> fs/io_uring.c:9408:6: warning: unused variable 'ret' [-Wunused-variable]
> 9408 | int ret;
> | ^~~
>
> Introduced by commit
>
> efc2519f427b ("io_uring: fix double io_uring free")
I'll fix it up, doesn't show up in my build...
--
Jens Axboe
[PATCH] Drivers: hv: vmbus: Add /sys/bus/vmbus/supported_features
When a Linux VM runs on Hyper-V, if the host toolstack doesn't support
hibernation for the VM (this happens on old Hyper-V hosts like Windows
Server 2016, or new Hyper-V hosts if the admin or user doesn't declare
the hibernation intent for the VM), the VM is discouraged from trying
hibernation (because the host doesn't guarantee that the VM's virtual
hardware configuration will remain exactly the same across hibernation),
i.e. the VM should not try to set up the swap partition/file for
hibernation, etc.
x86 Hyper-V uses the presence of the virtual ACPI S4 state as the
indication of the host toolstack support for a VM. Currently there is
no easy and reliable way for the userspace to detect the presence of
the state (see https://lkml.org/lkml/2020/12/11/1097). Add
/sys/bus/vmbus/supported_features for this purpose.
Signed-off-by: Dexuan Cui
---
Documentation/ABI/stable/sysfs-bus-vmbus | 7 +++
drivers/hv/vmbus_drv.c | 20
2 files changed, 27 insertions(+)
diff --git a/Documentation/ABI/stable/sysfs-bus-vmbus
b/Documentation/ABI/stable/sysfs-bus-vmbus
index c27b7b89477c..3ba765ae6695 100644
--- a/Documentation/ABI/stable/sysfs-bus-vmbus
+++ b/Documentation/ABI/stable/sysfs-bus-vmbus
@@ -1,3 +1,10 @@
+What: /sys/bus/vmbus/supported_features
+Date: Dec 2020
+KernelVersion: 5.11
+Contact: Dexuan Cui
+Description: Features specific to VMs running on Hyper-V
+Users: Daemon that sets up swap partition/file for hibernation
+
What: /sys/bus/vmbus/devices//id
Date: Jul 2009
KernelVersion: 2.6.31
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index d491fdcee61f..958487a40a18 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -678,6 +678,25 @@ static const struct attribute_group vmbus_dev_group = {
};
__ATTRIBUTE_GROUPS(vmbus_dev);
+/* Set up bus attribute(s) for /sys/bus/vmbus/supported_features */
+static ssize_t supported_features_show(struct bus_type *bus, char *buf)
+{
+ bool hb = hv_is_hibernation_supported();
+
+ return sprintf(buf, "%s\n", hb ? "hibernation" : "");
+}
+
+static BUS_ATTR_RO(supported_features);
+
+static struct attribute *vmbus_bus_attrs[] = {
+ &bus_attr_supported_features.attr,
+ NULL,
+};
+static const struct attribute_group vmbus_bus_group = {
+ .attrs = vmbus_bus_attrs,
+};
+__ATTRIBUTE_GROUPS(vmbus_bus);
+
/*
* vmbus_uevent - add uevent for our device
*
@@ -1024,6 +1043,7 @@ static struct bus_type hv_bus = {
.uevent = vmbus_uevent,
.dev_groups = vmbus_dev_groups,
.drv_groups = vmbus_drv_groups,
+ .bus_groups = vmbus_bus_groups,
.pm = &vmbus_pm,
};
--
2.19.1
Re: [PATCH] zsmalloc: do not use bit_spin_lock
On Tue, 22 Dec 2020, 22:06 Song Bao Hua (Barry Song), wrote: > > > > > -Original Message- > > From: Vitaly Wool [mailto:vitaly.w...@konsulko.com] > > Sent: Tuesday, December 22, 2020 10:44 PM > > To: Song Bao Hua (Barry Song) > > Cc: Shakeel Butt ; Minchan Kim ; > > Mike > > Galbraith ; LKML ; linux-mm > > ; Sebastian Andrzej Siewior ; > > NitinGupta ; Sergey Senozhatsky > > ; Andrew Morton > > ; tiantao (H) > > Subject: Re: [PATCH] zsmalloc: do not use bit_spin_lock > > > > On Tue, 22 Dec 2020, 03:11 Song Bao Hua (Barry Song), > > wrote: > > > > > > > > > > > > > -Original Message- > > > > From: Song Bao Hua (Barry Song) > > > > Sent: Tuesday, December 22, 2020 3:03 PM > > > > To: 'Vitaly Wool' > > > > Cc: Shakeel Butt ; Minchan Kim > > > > ; > > Mike > > > > Galbraith ; LKML ; linux-mm > > > > ; Sebastian Andrzej Siewior ; > > > > NitinGupta ; Sergey Senozhatsky > > > > ; Andrew Morton > > > > ; tiantao (H) > > > > Subject: RE: [PATCH] zsmalloc: do not use bit_spin_lock > > > > > > > > > > > > > I'm still not convinced. Will kmap what, src? At this point src might > > become > > > > just a bogus pointer. > > > > > > > > As long as the memory is still there, we can kmap it by its page struct. > > But > > > > if > > > > it is not there anymore, we have no way. > > > > > > > > > Why couldn't the object have been moved somewhere else (due to the > > > > > compaction > > > > mechanism for instance) > > > > > at the time DMA kicks in? > > > > > > > > So zs_map_object() will guarantee the src won't be moved by holding > > > > those > > > > preemption-disabled lock? > > > > If so, it seems we have to drop the MOVABLE gfp in zswap for zsmalloc > > > > case? > > > > > > > > > > Or we can do get_page() to avoid the movement of the page. > > > > > > I would like to discuss this more in zswap context than zsmalloc's. > > Since zsmalloc does not implement reclaim callback, using it in zswap > > is a corner case anyway. > > I see. But it seems we still need a solution for the compatibility > of zsmalloc and zswap? this will require change in either zsmalloc > or zswap. > or do you want to make zswap depend on !ZSMALLOC? No, I really don't think we should go that far. What if we add a flag to zpool, named like "can_sleep_mapped", and have it set for zbud/z3fold? Then zswap could go the current path if the flag is set; and if it's not set, and mutex_trylock fails, copy data from src to a temporary buffer, then unmap the handle, take the mutex, process the buffer instead of src. Not the nicest thing to do but at least it won't break anything. ~Vitaly > > zswap, on the other hand, may be dealing with some new backends in > > future which have more chances to become mainstream. Imagine typical > > NUMA-like cases, i. e. a zswap pool allocated in some kind SRAM, or in > > unused video memory. In such a case if you try to use a pointer to an > > invalidated zpool mapping, you are on the way to thrash the system. > > So: no assumptions that the zswap pool is in regular linear RAM should > > be made. > > > > ~Vitaly > > Thanks > Barry
drivers/clocksource/timer-clint.c:72:24: sparse: sparse: cast removes address space '__iomem' of expression
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 8653b778e454a7708847aeafe689bce07aeeb94e
commit: 2ac6795fcc085e8d03649f1bbd0d70aaff612cad clocksource/drivers: Add CLINT
timer driver
date: 4 months ago
config: riscv-randconfig-s031-20201221 (attached as .config)
compiler: riscv32-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.3-184-g1b896707-dirty
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2ac6795fcc085e8d03649f1bbd0d70aaff612cad
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 2ac6795fcc085e8d03649f1bbd0d70aaff612cad
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
"sparse warnings: (new ones prefixed by >>)"
>> drivers/clocksource/timer-clint.c:72:24: sparse: sparse: cast removes
>> address space '__iomem' of expression
>> drivers/clocksource/timer-clint.c:72:24: sparse: sparse: incorrect type in
>> argument 1 (different address spaces) @@ expected void const volatile
>> [noderef] __iomem *addr @@ got unsigned int [usertype] * @@
drivers/clocksource/timer-clint.c:72:24: sparse: expected void const
volatile [noderef] __iomem *addr
drivers/clocksource/timer-clint.c:72:24: sparse: got unsigned int
[usertype] *
drivers/clocksource/timer-clint.c:70:22: sparse: sparse: cast removes
address space '__iomem' of expression
drivers/clocksource/timer-clint.c:70:22: sparse: sparse: incorrect type in
argument 1 (different address spaces) @@ expected void const volatile
[noderef] __iomem *addr @@ got unsigned int [usertype] * @@
drivers/clocksource/timer-clint.c:70:22: sparse: expected void const
volatile [noderef] __iomem *addr
drivers/clocksource/timer-clint.c:70:22: sparse: got unsigned int
[usertype] *
drivers/clocksource/timer-clint.c:219:36: sparse: sparse: incorrect type in
argument 2 (different address spaces) @@ expected void * @@ got struct
clock_event_device [noderef] __percpu * @@
drivers/clocksource/timer-clint.c:219:36: sparse: expected void *
drivers/clocksource/timer-clint.c:219:36: sparse: got struct
clock_event_device [noderef] __percpu *
vim +/__iomem +72 drivers/clocksource/timer-clint.c
58
59 #ifdef CONFIG_64BIT
60 static u64 notrace clint_get_cycles64(void)
61 {
62 return clint_get_cycles();
63 }
64 #else /* CONFIG_64BIT */
65 static u64 notrace clint_get_cycles64(void)
66 {
67 u32 hi, lo;
68
69 do {
70 hi = clint_get_cycles_hi();
71 lo = clint_get_cycles();
> 72 } while (hi != clint_get_cycles_hi());
73
74 return ((u64)hi << 32) | lo;
75 }
76 #endif /* CONFIG_64BIT */
77
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Tue, Dec 22, 2020 at 3:50 PM Linus Torvalds wrote: > > See zap_pte_range() for an example of doing it right, even in the > presence of complexities (ie that has an example of both flushing the > TLB, and doing the actual "free the pages after flush", and it does > the two cases separately). The more I look at the mprotect code, the less I like it. We seem to be much better about the TLB flushes in other places (looking at mremap, for example). The mprotect code seems to be very laissez-faire about the TLB flushing. Does adding a TLB flush to before that pte_unmap_unlock(pte - 1, ptl); fix things for you? That's not the right fix - leaving a stale TLB entry around is fine if the TLB entry is more strict wrt protections - but it might be worth testing as a "does it at least close the problem" patch. Linus
[GIT pull] irq/core for v5.11-rc1
Linus, please pull the latest irq/core branch from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq-core-2020-12-23 up to: 64a1b95bb9fe: genirq: Restrict export of irq_to_desc() This is the second attempt after the first one failed miserably and got zapped to unblock the rest of the interrupt related patches. I'm still embarrassed about that. Please consider to pull this cleanup: A treewide cleanup of interrupt descriptor (ab)use with all sorts of racy accesses, inefficient and disfunctional code. The goal is to remove the export of irq_to_desc() to prevent these things from creeping up again. Thanks, tglx --> Thomas Gleixner (30): genirq: Move irq_has_action() into core code genirq: Move status flag checks to core genirq: Move irq_set_lockdep_class() to core genirq: Provide irq_get_effective_affinity() genirq: Annotate irq stats data races parisc/irq: Simplify irq count output for /proc/interrupts genirq: Make kstat_irqs() static genirq: Provide kstat_irqdesc_cpu() ARM: smp: Use irq_desc_kstat_cpu() in show_ipi_list() arm64/smp: Use irq_desc_kstat_cpu() in arch_show_interrupts() parisc/irq: Use irq_desc_kstat_cpu() in show_interrupts() s390/irq: Use irq_desc_kstat_cpu() in show_msi_interrupt() drm/i915/lpe_audio: Remove pointless irq_to_desc() usage drm/i915/pmu: Replace open coded kstat_irqs() copy pinctrl: nomadik: Use irq_has_action() mfd: ab8500-debugfs: Remove the racy fiddling with irq_desc NTB/msi: Use irq_has_action() PCI: xilinx-nwl: Use irq_data_get_irq_chip_data() PCI: mobiveil: Use irq_data_get_irq_chip_data() net/mlx4: Replace irq_to_desc() abuse net/mlx4: Use effective interrupt affinity net/mlx5: Replace irq_to_desc() abuse net/mlx5: Use effective interrupt affinity xen/events: Remove unused bind_evtchn_to_irq_lateeoi() xen/events: Remove disfunct affinity spreading xen/events: Use immediate affinity setting xen/events: Only force affinity mask for percpu interrupts xen/events: Reduce irq_info:: Spurious_cnt storage size xen/events: Implement irq distribution genirq: Restrict export of irq_to_desc() arch/alpha/kernel/sys_jensen.c | 2 +- arch/arm/kernel/smp.c | 2 +- arch/arm64/kernel/smp.c| 2 +- arch/parisc/kernel/irq.c | 7 +- arch/s390/kernel/irq.c | 2 +- arch/x86/kernel/topology.c | 1 + drivers/gpu/drm/i915/display/intel_lpe_audio.c | 4 - drivers/gpu/drm/i915/i915_irq.c| 34 drivers/gpu/drm/i915/i915_pmu.c| 19 +-- drivers/gpu/drm/i915/i915_pmu.h| 8 + drivers/mfd/ab8500-debugfs.c | 16 +- drivers/net/ethernet/mellanox/mlx4/en_cq.c | 8 +- drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +- drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 3 +- drivers/net/ethernet/mellanox/mlx5/core/en.h | 2 +- drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 2 +- drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 6 +- drivers/ntb/msi.c | 4 +- .../pci/controller/mobiveil/pcie-mobiveil-host.c | 8 +- drivers/pci/controller/pcie-xilinx-nwl.c | 8 +- drivers/pinctrl/nomadik/pinctrl-nomadik.c | 11 +- drivers/xen/events/events_base.c | 182 + drivers/xen/evtchn.c | 34 +--- include/linux/interrupt.h | 1 + include/linux/irq.h| 7 + include/linux/irqdesc.h| 40 ++--- include/linux/kernel_stat.h| 1 - kernel/irq/irqdesc.c | 45 +++-- kernel/irq/manage.c| 37 + kernel/irq/proc.c | 5 +- 30 files changed, 281 insertions(+), 226 deletions(-) diff --git a/arch/alpha/kernel/sys_jensen.c b/arch/alpha/kernel/sys_jensen.c index 0a2ab6cb18db..e5d870ff225f 100644 --- a/arch/alpha/kernel/sys_jensen.c +++ b/arch/alpha/kernel/sys_jensen.c @@ -7,7 +7,7 @@ * * Code supporting the Jensen. */ - +#include #include #include #include diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c index 48099c6e1e4a..e66c46aba5b4 100644 --- a/arch/arm/kernel/smp.c +++ b/arch/arm/kernel/smp.c @@ -550,7 +550,7 @@ void show_ipi_list(struct seq_file *p, int prec) seq_printf(p, "%*s%u: ", prec - 1, "IPI", i); for_each_online_cpu(cpu) - seq_printf(p, "%10u ", kstat_irqs_cpu(irq, cpu)); + seq_printf(p, "%10u ", irq_desc_kstat_cpu(ipi_desc[i], cpu));
Re: [PATCH] mm: add prototype for __add_to_page_cache_locked()
On Tue, 22 Dec 2020 20:40:00 + Matthew Wilcox wrote:
> On Tue, Dec 22, 2020 at 07:49:52PM +0530, Souptick Joarder wrote:
> > Otherwise it cause gcc warning:
> > ^~~
>
> That line is just confusing.
I cleaned up the changelog. It is presently
: Subject: include/linux/mm.h: add prototype for __add_to_page_cache_locked()
:
: Otherwise it causes a gcc warning:
:
: ../mm/filemap.c:830:14: warning: no previous prototype for
: `__add_to_page_cache_locked' [-Wmissing-prototypes]
:
: A previous attempt to make this function static led to compilation
: errors for a few architectures, because __add_to_page_cache_locked() is
: referred to by BPF code.
:
: Adding a prototype will silence the warning.
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -216,6 +216,12 @@ int overcommit_kbytes_handler(struct ctl_table *, int,
> > void *, size_t *,
> > loff_t *);
> > int overcommit_policy_handler(struct ctl_table *, int, void *, size_t *,
> > loff_t *);
> > +/*
> > + * Any attempt to mark this function as static leads to build failure
> > + * for few architectures. Adding a prototype to silence gcc warning.
> > + */
>
> We don't need a comment here for this. The commit log is enough.
I think it's OK - people do send patches which remove a prototype and
also make the function static. A tree-wide grep would catch the bpf
reference but I suspect people tend to grep for "foo(" rather then
"foo".
> > +int __add_to_page_cache_locked(struct page *page, struct address_space
> > *mapping,
> > + pgoff_t offset, gfp_t gfp, void **shadowp);
>
> Please name that 'index', not 'offset'.
I too prefer index over offset.
X1:/usr/src/linux-5.10> grep -r "pgoff_t offset" . | wc -l
52
X1:/usr/src/linux-5.10> grep -r "pgoff_t index" . | wc -l
250
But renaming this arg should be a separate patch.
And I don't think we should be preparing large "rename offset to index"
patches, please. The value/noise ratio is too low.
Re: sparc32: Init process fails to load with generic kmap atomic
On Tue, Dec 22 2020 at 18:58, Andreas Larsson wrote:
> From as far as I have gotten into hunting down the problem, I get a
> failure from load_elf_binary here:
>
> /* First of all, some simple consistency checks */
> if (memcmp(elf_ex->e_ident, ELFMAG, SELFMAG) != 0)
> goto out;
>
> at least seemingly due to the kaddr from copy_page_to_iter in
> lib/iov_iter.c
>
> if (i->type & (ITER_BVEC|ITER_KVEC)) {
> void *kaddr = kmap_atomic(page);
> size_t wanted = copy_to_iter(kaddr + offset, bytes, i);
>
> where kaddr points to memory with all zeroes (from an earlier bzero) in
> this context:
The kaddr might be misleading you here. If the code flow is:
kaddr1 = kmap_atomic(page1);
...
kunmap_atomic(kaddr1);
kaddr2 = kmap_atomic(page2);
Then kaddr1 == kaddr2, but first it maps page1 and then page2, but that
was the same in the original code.
> I will have to continue to dig deeper into this in January. If anyone
> has any ideas how this could stem from this kmap patch, I am all ears.
I can't spot it either. I'll send you a debug patch after the holidays.
Thanks,
tglx
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Tue, Dec 22, 2020 at 3:39 PM Yu Zhao wrote: > > 2) is the false positive because of what we do, and it's causing the > memory corruption because do_wp_page() tries to make copies of pages > that seem to be RO but may have stale RW tlb entries pending flush. Yeah, that's definitely a different bug. The rule is that the TLB flush has to be done before the page table lock is released. See zap_pte_range() for an example of doing it right, even in the presence of complexities (ie that has an example of both flushing the TLB, and doing the actual "free the pages after flush", and it does the two cases separately). Linus
linux-next: build warning after merge of the block tree
Hi all,
After merging the block tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
fs/io_uring.c: In function 'io_uring_get_file':
fs/io_uring.c:9408:6: warning: unused variable 'ret' [-Wunused-variable]
9408 | int ret;
| ^~~
Introduced by commit
efc2519f427b ("io_uring: fix double io_uring free")
--
Cheers,
Stephen Rothwell
pgpzJQ7HxCQba.pgp
Description: OpenPGP digital signature
Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
On Tue, Dec 22, 2020 at 05:02:37PM -0500, Andrea Arcangeli wrote: > On Tue, Dec 22, 2020 at 02:14:41PM -0700, Yu Zhao wrote: > > This works but I don't prefer this option because 1) this is new > > way of making pte_wrprotect safe and 2) it's specific to ufd and > > can't be applied to clear_soft_dirty() which has no "catcher". No > > I didn't look into clear_soft_dirty issue, I can look into that. > > To avoid having to deal with a 3rd solution it will have to use one of > the two: > > 1) avoid deferring tlb flush and enforce a sync flush before dropping > the PT lock even if mm_mm_tlb_flush_pending is true -> > write_protect_page in KSM > > 2) add its own new catcher for its own specific marker (for UFFD-WP >the marker is _PAGE_UFFD_WP, for change_prot_numa is PROT_NONE on a >vma->vm_pgprot not PROT_NONE, for soft dirty it could be >_PAGE_SOFT_DIRTY) to send the page fault to a dead end before the >pte value is interpreted. > > > matter how good the documentation about this new way is now, it > > will be out of date, speaking from my personal experience. > > A common catcher for all 3 is not possible because each catcher > depends on whatever marker and whatever pte value they set that may > lead to a different deterministic path where to put the catcher or > multiple paths even. do_numa_page requires a catcher in a different > place already. > > Or well, a common catcher for all 3 is technically possible but it'd > perform slower requiring to check things twice. > > But perhaps the soft_dirty can use the same catcher of uffd-wp given > the similarity? > > > I'd go with what Nadav has -- the memory corruption problem has been > > there for a while and nobody has complained except Nadav. This makes > > me think people is less likely to notice any performance issues from > > holding mmap_lock for write in his patch either. > > uffd-wp is a fairly new feature, the current users are irrelevant, > keeping it optimal is just for the future potential. > > > But I can't say I have zero concern with the potential performance > > impact given that I have been expecting the fix to go to stable, > > which I care most. So the next option on my list is to have a > > Actually stable would be very fine to go with Nadav patch and use the > mmap_lock_write unconditionally. The optimal fix is only relevant for > the future potential, so it's only relevant for Linus's tree. > > However the feature is recent enough that it won't require a deep > backport so the optimal fix is likely fine for stable as well, > generally stable prefers the same fix as in the upstream when there's > no major backport rejection issue. > > The alternative solution for uffd is to do the deferred flush under > mmap_lock_write if len is > HPAGE_PMD_SIZE, or to tell > change_protection not to defer the flush and to take the > mmap_lock_read for <= HPAGE_PMD_SIZE. That will avoid depending on the > catcher and then userfaultfd_writeprotect(mode_wp=true) > userfaultfd_writeprotect(mode_wp=false) can even run in parallel at > all times. The cons is large userfaultfd_writeprotect will block for > I/O and those would happen at least in the postcopy live snapshotting > use case. > > The main cons is that it'd require modification to change_protection > so it actually looks more intrusive, not less. > > Overall anything that allows to wrprotect 1 pte with only the > mmap_lock_read exactly like KSM write_protect_page, would be enough for > uffd-wp. > > What isn't ok in terms of future potential is unconditional > mmap_lock_write as in the original suggested patch in my view. It > doesn't mean we can take mmap_lock_write when the operation is large > and there is actually more benefit from deferring the flush. > > > common "catcher" in do_wp_page() which singles out pages that have > > page_mapcount equal to one and reuse them instead of trying to > > I don't think the page_mapcount matters here. If the wp page reuse was > more accurate (as it was before) we wouldn't notice this issue, but it > still would be a bug that there were stale TLB entries. It worked by > luck. Can you please correct my understanding below? Thank you. Generally speaking, we have four possible combinations relevant to this discussion: 1) anon, COW 2) anon, non-COW 3) file, COW 4) file, non-COW Assume we pte_wrprotect while holding mmap_lock for read, all four combinations can be routed to do_wp_page(). The difference is that 1) and 3) are guaranteed to be RO when they become COW, and what we do on top of their existing state doesn't make any difference. 2) is the false positive because of what we do, and it's causing the memory corruption because do_wp_page() tries to make copies of pages that seem to be RO but may have stale RW tlb entries pending flush. If we grab mmap_lock for write, we block the fault that tries to copy before we flush. Once it's done, we'll have two faulting CPUs, one that had the stale entry and would otherwise
Re: [RFC PATCH 4/4] powerpc: Use common of_kexec_setup_new_fdt()
On 12/22/20 1:55 PM, Thiago Jung Bauermann wrote: Rob Herring writes: Signed-off-by: Rob Herring --- After the IMA changes, delete_fdt_mem_rsv() can also be removed. arch/powerpc/kexec/file_load.c | 125 ++--- 1 file changed, 6 insertions(+), 119 deletions(-) Reviewed-by: Thiago Jung Bauermann Shouldn't this series also be Cc'd to the linuxppc-dev mailing list? I just noticed that the ARM64 IMA kexec series hasn't been copying the linuxppc-dev mailing list, so perhaps this is why this series isn't doing that, either. Thanks for pointing that out Thiago. I will copy linuxppc-dev mailing list (linuxppc-...@vger.kernel.org) when I post v14 of my patch set. -lakshmi diff --git a/arch/powerpc/kexec/file_load.c b/arch/powerpc/kexec/file_load.c index e452b11df631..956bcb2d1ec2 100644 --- a/arch/powerpc/kexec/file_load.c +++ b/arch/powerpc/kexec/file_load.c @@ -16,6 +16,7 @@ #include #include +#include #include #include #include It's possible to remove the include now.
Re: [PATCH v4] s390/vfio-ap: clean up vfio_ap resources when KVM pointer invalidated
On 12/22/20 2:43 PM, Halil Pasic wrote:
On Tue, 22 Dec 2020 16:57:06 +0100
Cornelia Huck wrote:
On Tue, 22 Dec 2020 10:37:01 -0500
Tony Krowiak wrote:
On 12/21/20 11:05 PM, Halil Pasic wrote:
On Mon, 21 Dec 2020 13:56:25 -0500
Tony Krowiak wrote:
static int vfio_ap_mdev_group_notifier(struct notifier_block *nb,
unsigned long action, void *data)
{
- int ret;
+ int ret, notify_rc = NOTIFY_DONE;
struct ap_matrix_mdev *matrix_mdev;
if (action != VFIO_GROUP_NOTIFY_SET_KVM)
return NOTIFY_OK;
matrix_mdev = container_of(nb, struct ap_matrix_mdev, group_notifier);
+ mutex_lock(&matrix_dev->lock);
if (!data) {
- matrix_mdev->kvm = NULL;
- return NOTIFY_OK;
+ if (matrix_mdev->kvm)
+ vfio_ap_mdev_unset_kvm(matrix_mdev);
+ notify_rc = NOTIFY_OK;
+ goto notify_done;
}
ret = vfio_ap_mdev_set_kvm(matrix_mdev, data);
if (ret)
- return NOTIFY_DONE;
+ goto notify_done;
/* If there is no CRYCB pointer, then we can't copy the masks */
if (!matrix_mdev->kvm->arch.crypto.crycbd)
- return NOTIFY_DONE;
+ goto notify_done;
kvm_arch_crypto_set_masks(matrix_mdev->kvm, matrix_mdev->matrix.apm,
matrix_mdev->matrix.aqm,
matrix_mdev->matrix.adm);
- return NOTIFY_OK;
Shouldn't there be an
+notify_rc = NOTIFY_OK;
here? I mean you initialize notify_rc to NOTIFY_DONE, in the !data branch
on success you set notify_rc to NOTIFY_OK, but in the !!data branch it
just stays NOTIFY_DONE. Or am I missing something?
I don't think it matters much since NOTIFY_OK and NOTIFY_DONE have
no further effect on processing of the notification queue, but I believe
you are correct, this is a change from what we originally had. I can
restore the original return values if you'd prefer.
Even if they have the same semantics now, that might change in the
future; restoring the original behaviour looks like the right thing to
do.
I agree. Especially since we do care to preserve the behavior in
the !data branch. If there is no difference between the two, then it
would probably make sense to clean that up globally.
Got it. I'm going to do a quick turnaround on the next version so we
can get this merged if need be. I will be taking off for Christmas vacation
and will be gone until sometime the first week in January.
Regards,
Halil
[PATCH v6 10/11] media: uvcvideo: New macro uvc_trace_cont
Remove all the duplicated code around printk(KERN_CONT, with a new macro.
Reviewed-by: Laurent Pinchart
Suggested-by: Joe Perches
Signed-off-by: Ricardo Ribalda
---
drivers/media/usb/uvc/uvc_driver.c | 57 +++---
drivers/media/usb/uvc/uvcvideo.h | 6
2 files changed, 27 insertions(+), 36 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index e348d8bb625d..c146944db091 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1646,8 +1646,7 @@ static int uvc_scan_chain_entity(struct uvc_video_chain
*chain,
{
switch (UVC_ENTITY_TYPE(entity)) {
case UVC_VC_EXTENSION_UNIT:
- if (uvc_trace_param & UVC_TRACE_PROBE)
- printk(KERN_CONT " <- XU %d", entity->id);
+ uvc_trace_cont(UVC_TRACE_PROBE, " <- XU %d", entity->id);
if (entity->bNrInPins != 1) {
uvc_trace(UVC_TRACE_DESCR, "Extension unit %d has more "
@@ -1658,8 +1657,7 @@ static int uvc_scan_chain_entity(struct uvc_video_chain
*chain,
break;
case UVC_VC_PROCESSING_UNIT:
- if (uvc_trace_param & UVC_TRACE_PROBE)
- printk(KERN_CONT " <- PU %d", entity->id);
+ uvc_trace_cont(UVC_TRACE_PROBE, " <- PU %d", entity->id);
if (chain->processing != NULL) {
uvc_trace(UVC_TRACE_DESCR, "Found multiple "
@@ -1671,8 +1669,7 @@ static int uvc_scan_chain_entity(struct uvc_video_chain
*chain,
break;
case UVC_VC_SELECTOR_UNIT:
- if (uvc_trace_param & UVC_TRACE_PROBE)
- printk(KERN_CONT " <- SU %d", entity->id);
+ uvc_trace_cont(UVC_TRACE_PROBE, " <- SU %d", entity->id);
/* Single-input selector units are ignored. */
if (entity->bNrInPins == 1)
@@ -1690,27 +1687,22 @@ static int uvc_scan_chain_entity(struct uvc_video_chain
*chain,
case UVC_ITT_VENDOR_SPECIFIC:
case UVC_ITT_CAMERA:
case UVC_ITT_MEDIA_TRANSPORT_INPUT:
- if (uvc_trace_param & UVC_TRACE_PROBE)
- printk(KERN_CONT " <- IT %d\n", entity->id);
+ uvc_trace_cont(UVC_TRACE_PROBE, " <- IT %d\n", entity->id);
break;
case UVC_OTT_VENDOR_SPECIFIC:
case UVC_OTT_DISPLAY:
case UVC_OTT_MEDIA_TRANSPORT_OUTPUT:
- if (uvc_trace_param & UVC_TRACE_PROBE)
- printk(KERN_CONT " OT %d", entity->id);
+ uvc_trace_cont(UVC_TRACE_PROBE, " OT %d", entity->id);
break;
case UVC_TT_STREAMING:
- if (UVC_ENTITY_IS_ITERM(entity)) {
- if (uvc_trace_param & UVC_TRACE_PROBE)
- printk(KERN_CONT " <- IT %d\n", entity->id);
- } else {
- if (uvc_trace_param & UVC_TRACE_PROBE)
- printk(KERN_CONT " OT %d", entity->id);
- }
+ if (UVC_ENTITY_IS_ITERM(entity))
+ uvc_trace_cont(UVC_TRACE_PROBE, " <- IT %d\n",
entity->id);
+ else
+ uvc_trace_cont(UVC_TRACE_PROBE, " OT %d", entity->id);
break;
@@ -1757,13 +1749,11 @@ static int uvc_scan_chain_forward(struct
uvc_video_chain *chain,
}
list_add_tail(&forward->chain, &chain->entities);
- if (uvc_trace_param & UVC_TRACE_PROBE) {
- if (!found)
- printk(KERN_CONT " (->");
+ if (!found)
+ uvc_trace_cont(UVC_TRACE_PROBE, " (->");
- printk(KERN_CONT " XU %d", forward->id);
- found = 1;
- }
+ uvc_trace_cont(UVC_TRACE_PROBE, " XU %d", forward->id);
+ found = 1;
break;
case UVC_OTT_VENDOR_SPECIFIC:
@@ -1777,18 +1767,16 @@ static int uvc_scan_chain_forward(struct
uvc_video_chain *chain,
}
list_add_tail(&forward->chain, &chain->entities);
- if (uvc_trace_param & UVC_TRACE_PROBE) {
- if (!found)
- printk(KERN_CONT " (->");
+ if (!found)
+ uvc_trace_cont(UVC_TRACE_PROBE, " (->");
- printk(KERN_CONT " OT %d", forward->id);
- found = 1;
- }
+ uvc_trace_cont(UVC_TRACE_PROBE, " OT %d", forward->id);
+ found = 1;
break;
}
}
if (fo
[PATCH v6 09/11] media: uvcvideo: Use dev_ printk aliases
Replace all the uses of printk() and uvc_printk() with its
equivalent dev_ alias macros.
Modify uvc_warn_once() macro to use dev_info instead printk().
They are more standard across the kernel tree and provide
more context about the error.
Reviewed-by: Laurent Pinchart
Suggested-by: Joe Perches
Signed-off-by: Ricardo Ribalda
---
drivers/media/usb/uvc/uvc_ctrl.c | 12 +++
drivers/media/usb/uvc/uvc_driver.c | 50 --
drivers/media/usb/uvc/uvc_entity.c | 10 +++---
drivers/media/usb/uvc/uvc_status.c | 13
drivers/media/usb/uvc/uvc_video.c | 48 ++--
drivers/media/usb/uvc/uvcvideo.h | 25 +++
6 files changed, 81 insertions(+), 77 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 8519f4fbbeb1..f837ffdc8c43 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -1331,8 +1331,8 @@ static void uvc_ctrl_status_event_work(struct work_struct
*work)
w->urb->interval = dev->int_ep->desc.bInterval;
ret = usb_submit_urb(w->urb, GFP_KERNEL);
if (ret < 0)
- uvc_printk(KERN_ERR, "Failed to resubmit status URB (%d).\n",
- ret);
+ dev_err(&dev->udev->dev,
+ "Failed to resubmit status URB (%d).\n", ret);
}
bool uvc_ctrl_status_event(struct urb *urb, struct uvc_video_chain *chain,
@@ -2030,10 +2030,10 @@ int uvc_ctrl_restore_values(struct uvc_device *dev)
if (!ctrl->initialized || !ctrl->modified ||
(ctrl->info.flags & UVC_CTRL_FLAG_RESTORE) == 0)
continue;
-
- printk(KERN_INFO "restoring control %pUl/%u/%u\n",
- ctrl->info.entity, ctrl->info.index,
- ctrl->info.selector);
+ dev_info(&dev->udev->dev,
+"restoring control %pUl/%u/%u\n",
+ctrl->info.entity, ctrl->info.index,
+ctrl->info.selector);
ctrl->dirty = 1;
}
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 15f7ec7d7e9b..e348d8bb625d 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -536,8 +536,8 @@ static int uvc_parse_format(struct uvc_device *dev,
sizeof(format->name));
format->fcc = fmtdesc->fcc;
} else {
- uvc_printk(KERN_INFO, "Unknown video format %pUl\n",
- &buffer[5]);
+ dev_info(&streaming->intf->dev,
+"Unknown video format %pUl\n", &buffer[5]);
snprintf(format->name, sizeof(format->name), "%pUl\n",
&buffer[5]);
format->fcc = 0;
@@ -2096,7 +2096,7 @@ static int uvc_scan_device(struct uvc_device *dev)
uvc_scan_fallback(dev);
if (list_empty(&dev->chains)) {
- uvc_printk(KERN_INFO, "No valid video chain found.\n");
+ dev_info(&dev->udev->dev, "No valid video chain found.\n");
return -1;
}
@@ -2255,8 +2255,9 @@ int uvc_register_video_device(struct uvc_device *dev,
ret = video_register_device(vdev, VFL_TYPE_VIDEO, -1);
if (ret < 0) {
- uvc_printk(KERN_ERR, "Failed to register %s device (%d).\n",
- v4l2_type_names[type], ret);
+ dev_err(&stream->intf->dev,
+ "Failed to register %s device (%d).\n",
+ v4l2_type_names[type], ret);
return ret;
}
@@ -2272,8 +2273,8 @@ static int uvc_register_video(struct uvc_device *dev,
/* Initialize the streaming interface with default parameters. */
ret = uvc_video_init(stream);
if (ret < 0) {
- uvc_printk(KERN_ERR, "Failed to initialize the device (%d).\n",
- ret);
+ dev_err(&stream->intf->dev,
+ "Failed to initialize the device (%d).\n", ret);
return ret;
}
@@ -2307,8 +2308,9 @@ static int uvc_register_terms(struct uvc_device *dev,
stream = uvc_stream_by_id(dev, term->id);
if (stream == NULL) {
- uvc_printk(KERN_INFO, "No streaming interface found "
- "for terminal %u.", term->id);
+ dev_info(&dev->udev->dev,
+"No streaming interface found for terminal
%u.",
+term->id);
continue;
}
@@ -2341,8 +2343,8 @@ static int uvc_register_chains(struct uvc_device *dev)
[PATCH v6 07/11] media: uvcvideo: Add Privacy control based on EXT_GPIO
Add a new control and mapping for Privacy controls connected to
UVC_GUID_EXT_GPIO_CONTROLLERs.
Reviewed-by: Laurent Pinchart
Signed-off-by: Ricardo Ribalda
---
drivers/media/usb/uvc/uvc_ctrl.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 22857b6a71e2..8519f4fbbeb1 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -347,6 +347,14 @@ static const struct uvc_control_info uvc_ctrls[] = {
| UVC_CTRL_FLAG_RESTORE
| UVC_CTRL_FLAG_AUTO_UPDATE,
},
+ {
+ .entity = UVC_GUID_EXT_GPIO_CONTROLLER,
+ .selector = UVC_CT_PRIVACY_CONTROL,
+ .index = 0,
+ .size = 1,
+ .flags = UVC_CTRL_FLAG_GET_CUR
+ | UVC_CTRL_FLAG_AUTO_UPDATE,
+ },
};
static const struct uvc_menu_info power_line_frequency_controls[] = {
@@ -735,6 +743,16 @@ static const struct uvc_control_mapping
uvc_ctrl_mappings[] = {
.v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
.data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
},
+ {
+ .id = V4L2_CID_PRIVACY,
+ .name = "Privacy",
+ .entity = UVC_GUID_EXT_GPIO_CONTROLLER,
+ .selector = UVC_CT_PRIVACY_CONTROL,
+ .size = 1,
+ .offset = 0,
+ .v4l2_type = V4L2_CTRL_TYPE_BOOLEAN,
+ .data_type = UVC_CTRL_DATA_TYPE_BOOLEAN,
+ },
};
/*
--
2.29.2.729.g45daf8777d-goog
[PATCH v6 08/11] media: uvcvideo: Implement UVC_QUIRK_PRIVACY_DURING_STREAM
Some devices can only read the privacy_pin if the device is
streaming.
This patch implement a quirk for such devices, in order to avoid invalid
reads and/or spurious events.
Signed-off-by: Ricardo Ribalda
---
drivers/media/usb/uvc/uvc_driver.c | 37 --
drivers/media/usb/uvc/uvc_video.c | 27 ++
drivers/media/usb/uvc/uvcvideo.h | 5
3 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 5873237bbfa8..15f7ec7d7e9b 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -1473,7 +1474,7 @@ static int uvc_parse_control(struct uvc_device *dev)
* Privacy GPIO
*/
-static u8 uvc_gpio_update_value(struct uvc_device *dev)
+u8 uvc_gpio_update_value(struct uvc_device *dev)
{
struct uvc_entity *unit = dev->gpio_unit;
struct uvc_video_chain *chain;
@@ -1498,6 +1499,9 @@ static int uvc_gpio_get_cur(struct uvc_device *dev,
struct uvc_entity *entity,
if (cs != UVC_CT_PRIVACY_CONTROL || size < 1 || !dev->gpio_unit)
return -EINVAL;
+ if (!dev->gpio_unit->gpio.is_gpio_ready)
+ return -EBUSY;
+
*(u8 *)data = uvc_gpio_update_value(dev);
return 0;
@@ -1517,13 +1521,31 @@ static irqreturn_t uvc_gpio_irq(int irq, void *data)
{
struct uvc_device *dev = data;
- if (!dev->gpio_unit)
+ if (!dev->gpio_unit || !dev->gpio_unit->gpio.is_gpio_ready)
return IRQ_HANDLED;
uvc_gpio_update_value(dev);
return IRQ_HANDLED;
}
+static const struct dmi_system_id privacy_valid_during_streamon[] = {
+ {
+ .ident = "HP Elite c1030 Chromebook",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Jinlon"),
+ },
+ },
+ {
+ .ident = "HP Pro c640 Chromebook",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Dratini"),
+ },
+ },
+ { } /* terminate list */
+};
+
static int uvc_gpio_parse(struct uvc_device *dev)
{
struct uvc_entity *unit;
@@ -1557,6 +1579,17 @@ static int uvc_gpio_parse(struct uvc_device *dev)
unit->get_info = uvc_gpio_get_info;
strncpy(unit->name, "GPIO", sizeof(unit->name) - 1);
+ /*
+* Note: This quirk will not match external UVC cameras,
+* as they will not have the corresponding ACPI GPIO entity.
+*/
+ if (dmi_check_system(privacy_valid_during_streamon)) {
+ dev->quirks |= UVC_QUIRK_PRIVACY_DURING_STREAM;
+ unit->gpio.is_gpio_ready = false;
+ } else {
+ unit->gpio.is_gpio_ready = true;
+ }
+
list_add_tail(&unit->list, &dev->entities);
dev->gpio_unit = unit;
diff --git a/drivers/media/usb/uvc/uvc_video.c
b/drivers/media/usb/uvc/uvc_video.c
index a6a441d92b94..03d6ed7fc8ed 100644
--- a/drivers/media/usb/uvc/uvc_video.c
+++ b/drivers/media/usb/uvc/uvc_video.c
@@ -2077,6 +2077,29 @@ int uvc_video_init(struct uvc_streaming *stream)
return 0;
}
+static void uvc_gpio_privacy_quirks(struct uvc_streaming *stream, bool enable)
+{
+ struct uvc_device *dev = stream->dev;
+ struct uvc_video_chain *first_chain;
+
+ if (!(dev->quirks & UVC_QUIRK_PRIVACY_DURING_STREAM))
+ return;
+
+ if (!dev->gpio_unit)
+ return;
+
+ first_chain = list_first_entry(&dev->chains,
+ struct uvc_video_chain, list);
+ /* GPIO entities are always on the first chain. */
+ if (stream->chain != first_chain)
+ return;
+
+ dev->gpio_unit->gpio.is_gpio_ready = enable;
+
+ if (enable)
+ uvc_gpio_update_value(stream->dev);
+}
+
int uvc_video_start_streaming(struct uvc_streaming *stream)
{
int ret;
@@ -2094,6 +2117,8 @@ int uvc_video_start_streaming(struct uvc_streaming
*stream)
if (ret < 0)
goto error_video;
+ uvc_gpio_privacy_quirks(stream, true);
+
return 0;
error_video:
@@ -2106,6 +2131,8 @@ int uvc_video_start_streaming(struct uvc_streaming
*stream)
void uvc_video_stop_streaming(struct uvc_streaming *stream)
{
+ uvc_gpio_privacy_quirks(stream, false);
+
uvc_video_stop_transfer(stream, 1);
if (stream->intf->num_altsetting > 1) {
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index 132513a66ee5..58422c99f05f 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -209,6 +209,7 @@
#define UVC_QUIRK_RESTORE_CTRLS_ON_INIT0x0400
#define UVC_QUIRK_FORCE_Y8 0x0800
[PATCH v6 11/11] media: uvcvideo: use dev_printk() for uvc_trace()
Instead of calling prink() inside uvc_trace, use dev_printk(), which adds
context to the output.
Now that we are at it, regroup the strings so the messages can be easily
"grepable".
Reviewed-by: Laurent Pinchart
Suggested-by: Laurent Pinchart
Signed-off-by: Ricardo Ribalda
---
drivers/media/usb/uvc/uvc_ctrl.c | 66 ---
drivers/media/usb/uvc/uvc_driver.c | 298 +++--
drivers/media/usb/uvc/uvc_isight.c | 16 +-
drivers/media/usb/uvc/uvc_queue.c | 9 +-
drivers/media/usb/uvc/uvc_status.c | 19 +-
drivers/media/usb/uvc/uvc_v4l2.c | 53 +++--
drivers/media/usb/uvc/uvc_video.c | 72 +++
drivers/media/usb/uvc/uvcvideo.h | 11 +-
8 files changed, 291 insertions(+), 253 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index f837ffdc8c43..bf448c213c53 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -906,8 +906,8 @@ static struct uvc_control *uvc_find_control(struct
uvc_video_chain *chain,
}
if (ctrl == NULL && !next)
- uvc_trace(UVC_TRACE_CONTROL, "Control 0x%08x not found.\n",
- v4l2_id);
+ uvc_trace(chain->dev, UVC_TRACE_CONTROL,
+ "Control 0x%08x not found.\n", v4l2_id);
return ctrl;
}
@@ -1820,9 +1820,9 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
ret = uvc_query_ctrl(dev, UVC_GET_LEN, ctrl->entity->id, dev->intfnum,
info->selector, data, 2);
if (ret < 0) {
- uvc_trace(UVC_TRACE_CONTROL,
+ uvc_trace(dev, UVC_TRACE_CONTROL,
"GET_LEN failed on control %pUl/%u (%d).\n",
- info->entity, info->selector, ret);
+ info->entity, info->selector, ret);
goto done;
}
@@ -1833,7 +1833,7 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
ret = uvc_ctrl_get_flags(dev, ctrl, info);
if (ret < 0) {
- uvc_trace(UVC_TRACE_CONTROL,
+ uvc_trace(dev, UVC_TRACE_CONTROL,
"Failed to get flags for control %pUl/%u (%d).\n",
info->entity, info->selector, ret);
goto done;
@@ -1841,8 +1841,8 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
uvc_ctrl_fixup_xu_info(dev, ctrl, info);
- uvc_trace(UVC_TRACE_CONTROL, "XU control %pUl/%u queried: len %u, "
- "flags { get %u set %u auto %u }.\n",
+ uvc_trace(dev, UVC_TRACE_CONTROL,
+ "XU control %pUl/%u queried: len %u, flags { get %u set %u
auto %u }.\n",
info->entity, info->selector, info->size,
(info->flags & UVC_CTRL_FLAG_GET_CUR) ? 1 : 0,
(info->flags & UVC_CTRL_FLAG_SET_CUR) ? 1 : 0,
@@ -1871,9 +1871,10 @@ static int uvc_ctrl_init_xu_ctrl(struct uvc_device *dev,
ret = uvc_ctrl_add_info(dev, ctrl, &info);
if (ret < 0)
- uvc_trace(UVC_TRACE_CONTROL, "Failed to initialize control "
- "%pUl/%u on device %s entity %u\n", info.entity,
- info.selector, dev->udev->devpath, ctrl->entity->id);
+ uvc_trace(dev, UVC_TRACE_CONTROL,
+ "Failed to initialize control %pUl/%u on device %s
entity %u\n",
+ info.entity, info.selector, dev->udev->devpath,
+ ctrl->entity->id);
return ret;
}
@@ -1901,8 +1902,8 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
}
if (!found) {
- uvc_trace(UVC_TRACE_CONTROL, "Extension unit %u not found.\n",
- xqry->unit);
+ uvc_trace(chain->dev, UVC_TRACE_CONTROL,
+ "Extension unit %u not found.\n", xqry->unit);
return -ENOENT;
}
@@ -1917,8 +1918,9 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
}
if (!found) {
- uvc_trace(UVC_TRACE_CONTROL, "Control %pUl/%u not found.\n",
- entity->guid, xqry->selector);
+ uvc_trace(chain->dev, UVC_TRACE_CONTROL,
+ "Control %pUl/%u not found.\n", entity->guid,
+ xqry->selector);
return -ENOENT;
}
@@ -2066,9 +2068,10 @@ static int uvc_ctrl_add_info(struct uvc_device *dev,
struct uvc_control *ctrl,
ctrl->initialized = 1;
- uvc_trace(UVC_TRACE_CONTROL, "Added control %pUl/%u to device %s "
- "entity %u\n", ctrl->info.entity, ctrl->info.selector,
- dev->udev->devpath, ctrl->entity->id);
+ uvc_trace(dev, UVC_TRACE_CONTROL,
+ "Added control %pUl/%u to device %s entity %u\n",
+ ctrl->info.entity, ctrl->info.selector, dev->udev->devpath,
+ ctrl->e
[PATCH v6 04/11] media: uvcvideo: Add uvc_ctrl_status_event_direct
Provide a code path for events that can be sent without a work-queue,
this is, that do not belong to an URB and are not handled in the top
half on an irq-handled.
Signed-off-by: Ricardo Ribalda
---
drivers/media/usb/uvc/uvc_ctrl.c | 35 +++-
drivers/media/usb/uvc/uvcvideo.h | 2 ++
2 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 9f6174a10e73..5fe228a3213b 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -1254,17 +1254,14 @@ static void uvc_ctrl_send_slave_event(struct
uvc_video_chain *chain,
uvc_ctrl_send_event(chain, handle, ctrl, mapping, val, changes);
}
-static void uvc_ctrl_status_event_work(struct work_struct *work)
+static void __uvc_ctrl_status_event(struct uvc_device *dev,
+ struct uvc_ctrl_work *w)
{
- struct uvc_device *dev = container_of(work, struct uvc_device,
- async_ctrl.work);
- struct uvc_ctrl_work *w = &dev->async_ctrl;
struct uvc_video_chain *chain = w->chain;
struct uvc_control_mapping *mapping;
struct uvc_control *ctrl = w->ctrl;
struct uvc_fh *handle;
unsigned int i;
- int ret;
mutex_lock(&chain->ctrl_mutex);
@@ -1291,6 +1288,16 @@ static void uvc_ctrl_status_event_work(struct
work_struct *work)
}
mutex_unlock(&chain->ctrl_mutex);
+}
+
+static void uvc_ctrl_status_event_work(struct work_struct *work)
+{
+ struct uvc_device *dev = container_of(work, struct uvc_device,
+ async_ctrl.work);
+ struct uvc_ctrl_work *w = &dev->async_ctrl;
+ int ret;
+
+ __uvc_ctrl_status_event(dev, w);
/* Resubmit the URB. */
w->urb->interval = dev->int_ep->desc.bInterval;
@@ -1321,6 +1328,24 @@ bool uvc_ctrl_status_event(struct urb *urb, struct
uvc_video_chain *chain,
return true;
}
+void uvc_ctrl_status_event_direct(struct uvc_video_chain *chain,
+ struct uvc_control *ctrl, const u8 *data)
+{
+ struct uvc_device *dev = chain->dev;
+ struct uvc_ctrl_work w;
+
+ if (list_empty(&ctrl->info.mappings)) {
+ ctrl->handle = NULL;
+ return;
+ }
+
+ w.data = data;
+ w.chain = chain;
+ w.ctrl = ctrl;
+
+ __uvc_ctrl_status_event(dev, &w);
+}
+
static bool uvc_ctrl_xctrls_has_control(const struct v4l2_ext_control *xctrls,
unsigned int xctrls_count, u32 id)
{
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index c50b0546901f..d7954dcc2b60 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -845,6 +845,8 @@ void uvc_ctrl_cleanup_device(struct uvc_device *dev);
int uvc_ctrl_restore_values(struct uvc_device *dev);
bool uvc_ctrl_status_event(struct urb *urb, struct uvc_video_chain *chain,
struct uvc_control *ctrl, const u8 *data);
+void uvc_ctrl_status_event_direct(struct uvc_video_chain *chain,
+ struct uvc_control *ctrl, const u8 *data);
int uvc_ctrl_begin(struct uvc_video_chain *chain);
int __uvc_ctrl_commit(struct uvc_fh *handle, int rollback,
--
2.29.2.729.g45daf8777d-goog
[PATCH v6 05/11] media: uvcvideo: Allow entity-defined get_info and get_cur
Allows controls to get their properties and current value
from an entity-defined function instead of via a query to the USB
device.
Reviewed-by: Laurent Pinchart
Signed-off-by: Ricardo Ribalda
---
drivers/media/usb/uvc/uvc_ctrl.c | 22 ++
drivers/media/usb/uvc/uvcvideo.h | 5 +
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 5fe228a3213b..acdc9b032306 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -980,10 +980,20 @@ static int __uvc_ctrl_get(struct uvc_video_chain *chain,
return -EACCES;
if (!ctrl->loaded) {
- ret = uvc_query_ctrl(chain->dev, UVC_GET_CUR, ctrl->entity->id,
- chain->dev->intfnum, ctrl->info.selector,
+ if (ctrl->entity->get_cur) {
+ ret = ctrl->entity->get_cur(chain->dev,
+ ctrl->entity,
+ ctrl->info.selector,
uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT),
ctrl->info.size);
+ } else {
+ ret = uvc_query_ctrl(chain->dev, UVC_GET_CUR,
+ ctrl->entity->id,
+ chain->dev->intfnum,
+ ctrl->info.selector,
+ uvc_ctrl_data(ctrl, UVC_CTRL_DATA_CURRENT),
+ ctrl->info.size);
+ }
if (ret < 0)
return ret;
@@ -1712,8 +1722,12 @@ static int uvc_ctrl_get_flags(struct uvc_device *dev,
if (data == NULL)
return -ENOMEM;
- ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id, dev->intfnum,
-info->selector, data, 1);
+ if (ctrl->entity->get_info)
+ ret = ctrl->entity->get_info(dev, ctrl->entity,
+ctrl->info.selector, data);
+ else
+ ret = uvc_query_ctrl(dev, UVC_GET_INFO, ctrl->entity->id,
+dev->intfnum, info->selector, data, 1);
if (!ret)
info->flags |= (data[0] & UVC_CONTROL_CAP_GET ?
UVC_CTRL_FLAG_GET_CUR : 0)
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index d7954dcc2b60..64a3d901db19 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -358,6 +358,11 @@ struct uvc_entity {
u8 bNrInPins;
u8 *baSourceID;
+ int (*get_info)(struct uvc_device *dev, struct uvc_entity *entity,
+ u8 cs, u8 *caps);
+ int (*get_cur)(struct uvc_device *dev, struct uvc_entity *entity,
+ u8 cs, void *data, u16 size);
+
unsigned int ncontrols;
struct uvc_control *controls;
};
--
2.29.2.729.g45daf8777d-goog
[PATCH v6 02/11] media: uvcvideo: Allow extra entities
Increase the size of the id, to avoid collisions with entities
implemented by the driver that are not part of the UVC device.
Entities exposed by the UVC device use IDs 0-255, extra entities
implemented by the driver (such as the GPIO entity) use IDs 256 and
up.
Reviewed-by: Laurent Pinchart
Signed-off-by: Ricardo Ribalda
---
drivers/media/usb/uvc/uvc_driver.c | 2 +-
drivers/media/usb/uvc/uvcvideo.h | 7 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index bfbc5a4d4ca6..82cdd1bb28dc 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1024,7 +1024,7 @@ static const u8 uvc_media_transport_input_guid[16] =
UVC_GUID_UVC_MEDIA_TRANSPORT_INPUT;
static const u8 uvc_processing_guid[16] = UVC_GUID_UVC_PROCESSING;
-static struct uvc_entity *uvc_alloc_entity(u16 type, u8 id,
+static struct uvc_entity *uvc_alloc_entity(u16 type, u16 id,
unsigned int num_pads, unsigned int extra_size)
{
struct uvc_entity *entity;
diff --git a/drivers/media/usb/uvc/uvcvideo.h b/drivers/media/usb/uvc/uvcvideo.h
index df7bf2d104a3..c50b0546901f 100644
--- a/drivers/media/usb/uvc/uvcvideo.h
+++ b/drivers/media/usb/uvc/uvcvideo.h
@@ -301,7 +301,12 @@ struct uvc_entity {
* chain. */
unsigned int flags;
- u8 id;
+ /*
+* Entities exposed by the UVC device use IDs 0-255, extra entities
+* implemented by the driver (such as the GPIO entity) use IDs 256 and
+* up.
+*/
+ u16 id;
u16 type;
char name[64];
u8 guid[16];
--
2.29.2.729.g45daf8777d-goog
[PATCH v6 00/11] Show privacy_gpio as a v4l2_ctrl
Some devices can implement a physical switch to disable the input of the camera on demand. Think of it like an elegant privacy sticker. The system can read the status of the privacy switch via a GPIO. The ACPI table maps this GPIO to the USB device via _CRS and _DSD descriptors, so the kernel can find it. The userspace applications need to know if the privacy pin is enabled or not. The obvious way to show it to userspace is via the V4L2_CID_PRIVACY control. This patchset implement this functionality. v6: Thanks to all the comments from Laurent! - Remove multiple async_ctrls from v5, it is not needed - Split event handling in two parts, so it can be triggered without wq - Save pointer to the privacy entity in the main structure - Handle the quirk in a different location to avoid races - CodeStyle v5: Thanks to all the comments from Laurent! - Allow multiple async_ctrls - Use dev_dbg() for uvc_trace - Major redesing of "Implement UVC_EXT_GPIO_UNIT" - Major redesing of "Implement UVC_QUIRK_PRIVACY_DURING_STREAM" v4: Implement UVC_QUIRK_PRIVACY_DURING_STREAM v3: Thanks to all the comments from Joe Perches - Rework of printk macros v2: Thanks to all the comments from Laurent! - move guid to unit - support entities with no pads - CodeStyle - Irq handling - pr_cont - new ids Ricardo Ribalda (11): media: uvcvideo: Move guid to entity media: uvcvideo: Allow extra entities media: uvcvideo: Allow entities with no pads media: uvcvideo: Add uvc_ctrl_status_event_direct media: uvcvideo: Allow entity-defined get_info and get_cur media: uvcvideo: Implement UVC_EXT_GPIO_UNIT media: uvcvideo: Add Privacy control based on EXT_GPIO media: uvcvideo: Implement UVC_QUIRK_PRIVACY_DURING_STREAM media: uvcvideo: Use dev_ printk aliases media: uvcvideo: New macro uvc_trace_cont media: uvcvideo: use dev_printk() for uvc_trace() drivers/media/usb/uvc/uvc_ctrl.c | 184 + drivers/media/usb/uvc/uvc_driver.c | 603 +++-- drivers/media/usb/uvc/uvc_entity.c | 11 +- drivers/media/usb/uvc/uvc_isight.c | 16 +- drivers/media/usb/uvc/uvc_queue.c | 9 +- drivers/media/usb/uvc/uvc_status.c | 32 +- drivers/media/usb/uvc/uvc_v4l2.c | 53 ++- drivers/media/usb/uvc/uvc_video.c | 147 --- drivers/media/usb/uvc/uvcvideo.h | 76 +++- 9 files changed, 727 insertions(+), 404 deletions(-) -- 2.29.2.729.g45daf8777d-goog
[PATCH v6 03/11] media: uvcvideo: Allow entities with no pads
Avoid an underflow while calculating the number of inputs for entities with zero pads. Reviewed-by: Laurent Pinchart Signed-off-by: Ricardo Ribalda --- drivers/media/usb/uvc/uvc_driver.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/media/usb/uvc/uvc_driver.c b/drivers/media/usb/uvc/uvc_driver.c index 82cdd1bb28dc..c0c5f75ade40 100644 --- a/drivers/media/usb/uvc/uvc_driver.c +++ b/drivers/media/usb/uvc/uvc_driver.c @@ -1033,7 +1033,10 @@ static struct uvc_entity *uvc_alloc_entity(u16 type, u16 id, unsigned int i; extra_size = roundup(extra_size, sizeof(*entity->pads)); - num_inputs = (type & UVC_TERM_OUTPUT) ? num_pads : num_pads - 1; + if (num_pads) + num_inputs = type & UVC_TERM_OUTPUT ? num_pads : num_pads - 1; + else + num_inputs = 0; size = sizeof(*entity) + extra_size + sizeof(*entity->pads) * num_pads + num_inputs; entity = kzalloc(size, GFP_KERNEL); @@ -1065,7 +1068,7 @@ static struct uvc_entity *uvc_alloc_entity(u16 type, u16 id, for (i = 0; i < num_inputs; ++i) entity->pads[i].flags = MEDIA_PAD_FL_SINK; - if (!UVC_ENTITY_IS_OTERM(entity)) + if (!UVC_ENTITY_IS_OTERM(entity) && num_pads) entity->pads[num_pads-1].flags = MEDIA_PAD_FL_SOURCE; entity->bNrInPins = num_inputs; -- 2.29.2.729.g45daf8777d-goog
[PATCH v6 06/11] media: uvcvideo: Implement UVC_EXT_GPIO_UNIT
Some devices can implement a physical switch to disable the input of the
camera on demand. Think of it like an elegant privacy sticker.
The system can read the status of the privacy switch via a GPIO.
It is important to know the status of the switch, e.g. to notify the
user when the camera will produce black frames and a videochat
application is used.
In some systems, the GPIO is connected to main SoC instead of the
camera controller, with the connection reported by the system firmware
(ACPI or DT). In that case, the UVC device isn't aware of the GPIO. We
need to implement a virtual entity to handle the GPIO fully on the
driver side.
For example, for ACPI-based systems, the GPIO is reported in the USB
device object:
Scope (\_SB.PCI0.XHCI.RHUB.HS07)
{
/.../
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
{
GpioIo (Exclusive, PullDefault, 0x, 0x, IoRestrictionOutputOnly,
"\\_SB.PCI0.GPIO", 0x00, ResourceConsumer, ,
)
{ // Pin list
0x0064
}
})
Name (_DSD, Package (0x02) // _DSD: Device-Specific Data
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties
for _DSD */,
Package (0x01)
{
Package (0x02)
{
"privacy-gpio",
Package (0x04)
{
\_SB.PCI0.XHCI.RHUB.HS07,
Zero,
Zero,
One
}
}
}
})
}
Signed-off-by: Ricardo Ribalda
---
drivers/media/usb/uvc/uvc_ctrl.c | 3 +
drivers/media/usb/uvc/uvc_driver.c | 133 +
drivers/media/usb/uvc/uvc_entity.c | 1 +
drivers/media/usb/uvc/uvcvideo.h | 17
4 files changed, 154 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index acdc9b032306..22857b6a71e2 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -2311,6 +2311,9 @@ int uvc_ctrl_init_device(struct uvc_device *dev)
} else if (UVC_ENTITY_TYPE(entity) == UVC_ITT_CAMERA) {
bmControls = entity->camera.bmControls;
bControlSize = entity->camera.bControlSize;
+ } else if (UVC_ENTITY_TYPE(entity) == UVC_EXT_GPIO_UNIT) {
+ bmControls = entity->gpio.bmControls;
+ bControlSize = entity->gpio.bControlSize;
}
/* Remove bogus/blacklisted controls */
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index c0c5f75ade40..5873237bbfa8 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -7,6 +7,7 @@
*/
#include
+#include
#include
#include
#include
@@ -1020,6 +1021,7 @@ static int uvc_parse_streaming(struct uvc_device *dev,
}
static const u8 uvc_camera_guid[16] = UVC_GUID_UVC_CAMERA;
+static const u8 uvc_gpio_guid[16] = UVC_GUID_EXT_GPIO_CONTROLLER;
static const u8 uvc_media_transport_input_guid[16] =
UVC_GUID_UVC_MEDIA_TRANSPORT_INPUT;
static const u8 uvc_processing_guid[16] = UVC_GUID_UVC_PROCESSING;
@@ -1051,6 +1053,9 @@ static struct uvc_entity *uvc_alloc_entity(u16 type, u16
id,
* is initialized by the caller.
*/
switch (type) {
+ case UVC_EXT_GPIO_UNIT:
+ memcpy(entity->guid, uvc_gpio_guid, 16);
+ break;
case UVC_ITT_CAMERA:
memcpy(entity->guid, uvc_camera_guid, 16);
break;
@@ -1464,6 +1469,115 @@ static int uvc_parse_control(struct uvc_device *dev)
return 0;
}
+/*
-
+ * Privacy GPIO
+ */
+
+static u8 uvc_gpio_update_value(struct uvc_device *dev)
+{
+ struct uvc_entity *unit = dev->gpio_unit;
+ struct uvc_video_chain *chain;
+ u8 gpio_val, old_val, new_val;
+
+ gpio_val = new_val = gpiod_get_value_cansleep(unit->gpio.gpio_privacy);
+
+ old_val = atomic_xchg(&unit->gpio.gpio_privacy_value, gpio_val);
+ if (new_val == old_val)
+ return new_val;
+
+ /* GPIO entities are always on the first chain. */
+ chain = list_first_entry(&dev->chains, struct uvc_video_chain, list);
+ uvc_ctrl_status_event_direct(chain, unit->controls, &new_val);
+
+ return new_val;
+}
+
+static int uvc_gpio_get_cur(struct uvc_device *dev, struct uvc_entity *entity,
+ u8 cs, void *data, u16 size)
+{
+ if (cs != UVC_CT_PRIVACY_CONTROL || size < 1 || !dev->gpio_unit)
+ return -EINVAL;
+
+ *(u8 *)data = uvc_gpio_update_value(dev);
+
+ return 0;
+}
+
+static int uvc_gpio_get_info(struct uvc_device *dev, struct uvc_entity *entity,
+u8 cs, u8 *caps)
+{
+ if (cs != UVC_CT_PRIVACY
[PATCH v6 01/11] media: uvcvideo: Move guid to entity
Instead of having multiple copies of the entity guid on the code, move
it to the entity structure.
Reviewed-by: Laurent Pinchart
Signed-off-by: Ricardo Ribalda
---
drivers/media/usb/uvc/uvc_ctrl.c | 30 --
drivers/media/usb/uvc/uvc_driver.c | 25 +++--
drivers/media/usb/uvc/uvcvideo.h | 2 +-
3 files changed, 28 insertions(+), 29 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 011e69427b7c..9f6174a10e73 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -826,31 +826,10 @@ static void uvc_set_le_value(struct uvc_control_mapping
*mapping,
* Terminal and unit management
*/
-static const u8 uvc_processing_guid[16] = UVC_GUID_UVC_PROCESSING;
-static const u8 uvc_camera_guid[16] = UVC_GUID_UVC_CAMERA;
-static const u8 uvc_media_transport_input_guid[16] =
- UVC_GUID_UVC_MEDIA_TRANSPORT_INPUT;
-
static int uvc_entity_match_guid(const struct uvc_entity *entity,
- const u8 guid[16])
+const u8 guid[16])
{
- switch (UVC_ENTITY_TYPE(entity)) {
- case UVC_ITT_CAMERA:
- return memcmp(uvc_camera_guid, guid, 16) == 0;
-
- case UVC_ITT_MEDIA_TRANSPORT_INPUT:
- return memcmp(uvc_media_transport_input_guid, guid, 16) == 0;
-
- case UVC_VC_PROCESSING_UNIT:
- return memcmp(uvc_processing_guid, guid, 16) == 0;
-
- case UVC_VC_EXTENSION_UNIT:
- return memcmp(entity->extension.guidExtensionCode,
- guid, 16) == 0;
-
- default:
- return 0;
- }
+ return memcmp(entity->guid, guid, sizeof(entity->guid)) == 0;
}
/*
@@ -1776,8 +1755,7 @@ static int uvc_ctrl_fill_xu_info(struct uvc_device *dev,
if (data == NULL)
return -ENOMEM;
- memcpy(info->entity, ctrl->entity->extension.guidExtensionCode,
- sizeof(info->entity));
+ memcpy(info->entity, ctrl->entity->guid, sizeof(info->entity));
info->index = ctrl->index;
info->selector = ctrl->index + 1;
@@ -1883,7 +1861,7 @@ int uvc_xu_ctrl_query(struct uvc_video_chain *chain,
if (!found) {
uvc_trace(UVC_TRACE_CONTROL, "Control %pUl/%u not found.\n",
- entity->extension.guidExtensionCode, xqry->selector);
+ entity->guid, xqry->selector);
return -ENOENT;
}
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index ddb9eaa11be7..bfbc5a4d4ca6 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -1019,6 +1019,11 @@ static int uvc_parse_streaming(struct uvc_device *dev,
return ret;
}
+static const u8 uvc_camera_guid[16] = UVC_GUID_UVC_CAMERA;
+static const u8 uvc_media_transport_input_guid[16] =
+ UVC_GUID_UVC_MEDIA_TRANSPORT_INPUT;
+static const u8 uvc_processing_guid[16] = UVC_GUID_UVC_PROCESSING;
+
static struct uvc_entity *uvc_alloc_entity(u16 type, u8 id,
unsigned int num_pads, unsigned int extra_size)
{
@@ -1038,6 +1043,22 @@ static struct uvc_entity *uvc_alloc_entity(u16 type, u8
id,
entity->id = id;
entity->type = type;
+ /*
+* Set the GUID for standard entity types. For extension units, the GUID
+* is initialized by the caller.
+*/
+ switch (type) {
+ case UVC_ITT_CAMERA:
+ memcpy(entity->guid, uvc_camera_guid, 16);
+ break;
+ case UVC_ITT_MEDIA_TRANSPORT_INPUT:
+ memcpy(entity->guid, uvc_media_transport_input_guid, 16);
+ break;
+ case UVC_VC_PROCESSING_UNIT:
+ memcpy(entity->guid, uvc_processing_guid, 16);
+ break;
+ }
+
entity->num_links = 0;
entity->num_pads = num_pads;
entity->pads = ((void *)(entity + 1)) + extra_size;
@@ -1109,7 +1130,7 @@ static int uvc_parse_vendor_control(struct uvc_device
*dev,
if (unit == NULL)
return -ENOMEM;
- memcpy(unit->extension.guidExtensionCode, &buffer[4], 16);
+ memcpy(unit->guid, &buffer[4], 16);
unit->extension.bNumControls = buffer[20];
memcpy(unit->baSourceID, &buffer[22], p);
unit->extension.bControlSize = buffer[22+p];
@@ -1368,7 +1389,7 @@ static int uvc_parse_standard_control(struct uvc_device
*dev,
if (unit == NULL)
return -ENOMEM;
- memcpy(unit->extension.guidExtensionCode, &buffer[4], 16);
+ memcpy(unit->guid, &buffer[4], 16);
unit->extension.bNumControls = buffer[20];
memcpy(unit->baSourceID, &buffer[22], p);
unit->extension.bControlSize = buffer[2
Re: [PATCHSET] saner elf compat
On Tue, Dec 22, 2020 at 09:38:35PM +, Al Viro wrote:
> On Tue, Dec 22, 2020 at 08:04:31PM +, Al Viro wrote:
>
> > FWIW, on debian/mips64el (both stretch and buster) the test fails with the
> > distro kernels (4.9- and 4.19-based) as well as with 5.10-rc1 and
> > 5.10-rc1+that series, all in the same way:
> > [Current thread is 1 (LWP 4154)]
> > (gdb) p/x foo
> > Cannot find thread-local storage for LWP 4154, executable file
> > Cannot find thread-local variables on this target
> >
> > buster has libc6-2.28, so that should be fine for the test in question
> > (libthread_db definitely recent enough). That was n32 gdb; considering
> > how much time it had taken to build that sucker I hadn't tried o32
> > yet.
> >
> > Note that it's not just with native coredumps - gcore-produced ones give
> > the same result. That was gdb from binutils-gdb.git; I'm not familiar
> > with gdb guts to start debugging it, so if you have any suggestions
> > in that direction that do not include a full rebuild... In any case,
> > I won't get around to that until the next week.
> >
> > Incidentally, build time is bloody awful - 3 days, with qemu-3.1 on
> > 3.5GHz amd64 host, all spent pretty much entirely in userland (both
> > from guest and host POV). g++-8 is atrociously slow...
> >
> > That said, I don't see what in that series could possibly mess the
> > things up for tls, while leaving the registers working; the only
> > thing that realistically might've been fucked up is prstatus layout
> > (and possibly size), and that would've screwed the registers as
> > well.
>
> ... and it smells like the damn thing needs n32 debug info from
> libthread_db.so
> and/or libpthread.so. Which is not packaged by debian libc6 mips64el build.
> Sorry, any debugging of that crap is going to happen in January ;-/
Cute... Completely unrelated, but there's a fun bug in mainline o32
coredumps - say readelf -a core and watch NT_FILE section dump.
Compare that for dumps done on mips32 and mips64 hosts (for the same
o32 binaries, obviously). Or to gcore(1) results on such processes,
for that matter.
What happens there is that 2aa362c49c31 ("coredump: extend core dump note
section to contain file names of mapped files") that has introduced that
section has added
#define user_long_tcompat_long_t
to fs/compat_binfmt_elf.c, but not to arch/mips/kernel/binfmt_elfo32.c,
resulting in default (long) being used by fill_files_note().
[PATCH] locking/lockdep: Use local_irq_save() with call_rcu()
The following lockdep splat was hit:
[ 560.638354] WARNING: CPU: 79 PID: 27458 at kernel/rcu/tree_plugin.h:1749
call_rcu+0x6dc/0xf00
:
[ 560.647761] RIP: 0010:call_rcu+0x6dc/0xf00
[ 560.647763] Code: 0f 8f 29 04 00 00 e8 93 da 1c 00 48 8b 3c 24 57 9d 0f 1f
44 00 00 e9 19 fa ff ff 65 8b 05 38 83 c4 49 85 c0 0f 84 cd fb ff ff <0f> 0b e9
c6 fb ff ff e8 b8 45 51 00 4c 89 f2 48 b8 00 00 00 00 00
[ 560.647764] RSP: 0018:ff11001050097b58 EFLAGS: 00010002
[ 560.647766] RAX: 0001 RBX: bb1f3360 RCX:
0001
[ 560.647766] RDX: RSI: RDI:
b99bac9c
[ 560.647767] RBP: 1fe220020a012f73 R08: 00010004005c R09:
dc00
[ 560.647768] R10: dc00 R11: 0003 R12:
ff1100105b7f70e1
[ 560.647769] R13: b635d8a0 R14: ff1100105b7f72d8 R15:
ff1100105b7f7040
[ 560.647770] FS: 7fd9b3437080() GS:ff1100105b60()
knlGS:
[ 560.647771] CS: 0010 DS: ES: CR0: 80050033
[ 560.647772] CR2: 7fd9b30112bc CR3: 00105e898006 CR4:
00761ee0
[ 560.647773] DR0: DR1: DR2:
[ 560.647773] DR3: DR6: fffe0ff0 DR7:
0400
[ 560.647774] PKRU: 5554
[ 560.647774] Call Trace:
[ 560.647778] ? invoke_rcu_core+0x180/0x180
[ 560.647782] ? __is_module_percpu_address+0xed/0x440
[ 560.647787] lockdep_unregister_key+0x2ab/0x5b0
[ 560.647791] destroy_workqueue+0x40b/0x610
[ 560.647862] xlog_dealloc_log+0x216/0x2b0 [xfs]
:
This splat is caused by the fact that lockdep_unregister_key() uses
raw_local_irq_save() which doesn't update the hardirqs_enabled
percpu flag. The call_rcu() function, however, will call
lockdep_assert_irqs_disabled() to check the hardirqs_enabled flag which
remained set in this case.
Fix this problem by using local_irq_save()/local_irq_restore() pairs
whenever call_rcu() is being called.
I think raw_local_irq_save() function can be used if no external
function is being called except maybe printk() as it means another
lockdep problem exists.
Fixes: a0b0fd53e1e67 ("locking/lockdep: Free lock classes that are no longer in
use")
Signed-off-by: Waiman Long
---
kernel/locking/lockdep.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index c1418b47f625..2a37af77ede6 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -5884,7 +5884,7 @@ static void free_zapped_rcu(struct rcu_head *ch)
if (WARN_ON_ONCE(ch != &delayed_free.rcu_head))
return;
- raw_local_irq_save(flags);
+ local_irq_save(flags);
lockdep_lock();
/* closed head */
@@ -5898,7 +5898,7 @@ static void free_zapped_rcu(struct rcu_head *ch)
call_rcu_zapped(delayed_free.pf + delayed_free.index);
lockdep_unlock();
- raw_local_irq_restore(flags);
+ local_irq_restore(flags);
}
/*
@@ -5941,13 +5941,13 @@ static void lockdep_free_key_range_reg(void *start,
unsigned long size)
init_data_structures_once();
- raw_local_irq_save(flags);
+ local_irq_save(flags);
lockdep_lock();
pf = get_pending_free();
__lockdep_free_key_range(pf, start, size);
call_rcu_zapped(pf);
lockdep_unlock();
- raw_local_irq_restore(flags);
+ local_irq_restore(flags);
/*
* Wait for any possible iterators from look_up_lock_class() to pass
@@ -6043,7 +6043,7 @@ static void lockdep_reset_lock_reg(struct lockdep_map
*lock)
unsigned long flags;
int locked;
- raw_local_irq_save(flags);
+ local_irq_save(flags);
locked = graph_lock();
if (!locked)
goto out_irq;
@@ -6054,7 +6054,7 @@ static void lockdep_reset_lock_reg(struct lockdep_map
*lock)
graph_unlock();
out_irq:
- raw_local_irq_restore(flags);
+ local_irq_restore(flags);
}
/*
@@ -6098,7 +6098,11 @@ void lockdep_unregister_key(struct lock_class_key *key)
if (WARN_ON_ONCE(static_obj(key)))
return;
- raw_local_irq_save(flags);
+ /*
+* local_irq_save() should be used as call_rcu() will check
+* hardirqs_enabled state.
+*/
+ local_irq_save(flags);
if (!graph_lock())
goto out_irq;
@@ -6115,7 +6119,7 @@ void lockdep_unregister_key(struct lock_class_key *key)
call_rcu_zapped(pf);
graph_unlock();
out_irq:
- raw_local_irq_restore(flags);
+ local_irq_restore(flags);
/* Wait until is_dynamic_key() has finished accessing k->hash_entry. */
synchronize_rcu();
--
2.18.1
Re: [PATCH v13 1/6] ima: Move arch_ima_add_kexec_buffer() to ima
Lakshmi Ramasubramanian writes: > arch_ima_add_kexec_buffer() defined in "arch/powerpc/kexec/ima.c" > sets up the address and size of the IMA measurement list in > the architecture specific fields in kimage struct. This function does not > have architecture specific code, but is currently limited to powerpc. > > Move arch_ima_add_kexec_buffer() to ima. > > Co-developed-by: Prakhar Srivastava > Signed-off-by: Prakhar Srivastava > Signed-off-by: Lakshmi Ramasubramanian > --- > arch/powerpc/include/asm/ima.h | 3 --- > arch/powerpc/kexec/ima.c | 17 - > security/integrity/ima/ima_kexec.c | 22 ++ > 3 files changed, 22 insertions(+), 20 deletions(-) Reviewed-by: Thiago Jung Bauermann Just one nit below. Also, I just noticed that this patch series hasn't been cc'd to the linuxppc-dev mailing list. You should do that, since it affects powerpc code. The powerpc maintainers are being copied so at least they've been made aware of it, but that isn't enough. > diff --git a/security/integrity/ima/ima_kexec.c > b/security/integrity/ima/ima_kexec.c > index 121de3e04af2..38bcd7543e27 100644 > --- a/security/integrity/ima/ima_kexec.c > +++ b/security/integrity/ima/ima_kexec.c > @@ -10,6 +10,7 @@ > #include > #include > #include > +#include > #include "ima.h" > > #ifdef CONFIG_IMA_KEXEC There's no need to add this include. -- Thiago Jung Bauermann IBM Linux Technology Center
Re: [RFC PATCH 1/3] mm: support hugetlb free page reporting
On 12/22/20 11:59 AM, Alexander Duyck wrote: > On Mon, Dec 21, 2020 at 11:47 PM Liang Li > wrote: >> + >> + if (huge_page_order(h) > MAX_ORDER) >> + budget = HUGEPAGE_REPORTING_CAPACITY; >> + else >> + budget = HUGEPAGE_REPORTING_CAPACITY * 32; > > Wouldn't huge_page_order always be more than MAX_ORDER? Seems like we > don't even really need budget since this should probably be pulling > out no more than one hugepage at a time. On standard x86_64 configs, 2MB huge pages are of order 9 < MAX_ORDER (11). What is important for hugetlb is the largest order that can be allocated from buddy. Anything bigger is considered a gigantic page and has to be allocated differently. If the code above is trying to distinguish between huge and gigantic pages, it is off by 1. The largest order that can be allocated from the buddy is (MAX_ORDER - 1). So, the check should be '>='. -- Mike Kravetz
Re: [PATCH] KVM: x86: fix shift out of bounds reported by UBSAN
On 22/12/20 19:31, David Laight wrote: /* * Use 2ULL to incorporate the necessary +1 in the shift; adding +1 in * the shift count will overflow SHL's max shift of 63 if s=0 and e=63. */ A comment of the desired output value would be more use. I think it is: return 'e-s' ones followed by 's' zeros without shifting by 64. What about a mix of the two: /* * Return 'e-s' ones followed by 's' zeros. Note that the * apparently obvious 1ULL << (e - s + 1) can shift by 64 if * s=0 and e=63, which is undefined behavior. */ Paolo
[GIT PULL] ext4 updates for v5.11-rc1
The following changes since commit 418baf2c28f3473039f2f7377760bd8f6897ae18: Linux 5.10-rc5 (2020-11-22 15:36:08 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus for you to fetch changes up to be993933d2e997fdb72b8b1418d2a84df79b8962: ext4: remove unnecessary wbc parameter from ext4_bio_write_page (2020-12-22 13:08:45 -0500) NOTE: The reason why the branch had recently changed was to add a one-line fix which added flush_work() call to an error/cleanup patgh, to address a syzbot reported failure. See the thread at: http://lore.kernel.org/r/1faff305b709b...@google.com There were also some commit description updates to add some Cc: sta...@kernel.org tags. This branch was tested and passes xfstests regression tests, and in any case, it's all bug fixes and cleanups: TESTRUNID: tytso-20201222152130 KERNEL:5.10.0-rc5-xfstests-00029-gbe993933d2e9 #2064 SMP Tue Dec 22 15:19:12 EST 2020 x86_64 CMDLINE: -c ext4/4k -g auto CPUS: 2 MEM: 7680 ext4/4k: 520 tests, 43 skipped, 6608 seconds Totals: 477 tests, 43 skipped, 0 failures, 0 errors, 6554s Various bug fixes and cleanups for ext4; no new features this cycle. Alexander Lochmann (1): Updated locking documentation for transaction_t Chunguang Xu (7): ext4: use ASSERT() to replace J_ASSERT() ext4: remove redundant mb_regenerate_buddy() ext4: simplify the code of mb_find_order_for_block ext4: update ext4_data_block_valid related comments ext4: delete nonsensical (commented-out) code inside ext4_xattr_block_set() ext4: fix a memory leak of ext4_free_data ext4: avoid s_mb_prefetch to be zero in individual scenarios Colin Ian King (1): ext4: remove redundant assignment of variable ex Dan Carpenter (1): ext4: fix an IS_ERR() vs NULL check Gustavo A. R. Silva (1): ext4: fix fall-through warnings for Clang Harshad Shirwadkar (3): ext4: add docs about fast commit idempotence ext4: make fast_commit.h byte identical with e2fsprogs/fast_commit.h jbd2: add a helper to find out number of fast commit blocks Jan Kara (8): ext4: fix deadlock with fs freezing and EA inodes ext4: don't remount read-only with errors=continue on reboot ext4: remove redundant sb checksum recomputation ext4: standardize error message in ext4_protect_reserved_inode() ext4: make ext4_abort() use __ext4_error() ext4: move functions in super.c ext4: simplify ext4 error translation ext4: defer saving error info from atomic context Kaixu Xia (2): ext4: remove redundant operation that set bh to NULL ext4: remove the unused EXT4_CURRENT_REV macro Lei Chen (1): ext4: remove unnecessary wbc parameter from ext4_bio_write_page Roman Anufriev (2): ext4: add helpers for checking whether quota can be enabled/is journalled ext4: print quota journalling mode on (re-)mount Theodore Ts'o (1): ext4: check for invalid block size early when mounting a file system Xianting Tian (1): ext4: remove the null check of bio_vec page Documentation/filesystems/ext4/journal.rst | 50 ++ fs/ext4/balloc.c | 2 +- fs/ext4/block_validity.c | 16 +- fs/ext4/ext4.h | 77 ++--- fs/ext4/ext4_jbd2.c| 4 +- fs/ext4/ext4_jbd2.h| 9 +- fs/ext4/extents.c | 5 +- fs/ext4/fast_commit.c | 99 +++- fs/ext4/fast_commit.h | 78 +++-- fs/ext4/fsync.c| 2 +- fs/ext4/indirect.c | 4 +- fs/ext4/inode.c| 35 ++-- fs/ext4/mballoc.c | 39 ++--- fs/ext4/namei.c| 12 +- fs/ext4/page-io.c | 5 +- fs/ext4/super.c| 422 - fs/ext4/xattr.c| 1 - fs/jbd2/journal.c | 8 +- include/linux/jbd2.h | 14 +- 19 files changed, 504 insertions(+), 378 deletions(-)
UBSAN: shift-out-of-bounds in snd_usbmidi_get_ms_info
Hello, syzbot found the following issue on: HEAD commit:8653b778 Merge tag 'clk-for-linus' of git://git.kernel.org.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=109531a350 kernel config: https://syzkaller.appspot.com/x/.config?x=98408202fed1f636 dashboard link: https://syzkaller.appspot.com/bug?extid=92e45ae45543f89e8c88 compiler: gcc (GCC) 10.1.0-syz 20200507 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1421ec4750 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12bfa07750 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+92e45ae45543f89e8...@syzkaller.appspotmail.com usb 1-1: config 0 interface 0 altsetting 0 bulk endpoint 0x8A has invalid maxpacket 31 usb 1-1: New USB device found, idVendor=324b, idProduct=5963, bcdDevice= 0.d2 usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0 usb 1-1: config 0 descriptor?? usb 1-1: MIDIStreaming interface descriptor not found UBSAN: shift-out-of-bounds in sound/usb/midi.c:1928:8 shift exponent 244 is too large for 32-bit type 'int' CPU: 1 PID: 17 Comm: kworker/1:0 Not tainted 5.10.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395 snd_usbmidi_get_ms_info.cold+0x83/0xd4 sound/usb/midi.c:1928 __snd_usbmidi_create+0x380/0x2320 sound/usb/midi.c:2404 snd_usb_create_quirk+0xa5/0xe0 sound/usb/quirks.c:562 usb_audio_probe+0x623/0x2ab0 sound/usb/card.c:795 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkal...@googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches
Re: [PATCH 3/3] ath10k: Set wiphy flag to trigger sta disconnect on hardware restart
On Tue, Dec 15, 2020 at 9:24 AM Youghandhar Chintala
wrote:
>
> From: Rakesh Pillai
>
> Currently after the hardware restart triggered from the driver,
> the station interface connection remains intact, since a disconnect
> trigger is not sent to userspace. This can lead to a problem in
> hardwares where the wifi mac sequence is added by the firmware.
>
> After the firmware restart, during subsytem recovery, the firmware
> restarts its wifi mac sequence number. Hence AP to which our device
> is connected will receive frames with a wifi mac sequence number jump
> to the past, thereby resulting in the AP dropping all these frames,
> until the frame arrives with a wifi mac sequence number which AP was
> expecting.
>
> To avoid such frame drops, its better to trigger a station disconnect
> upon the hardware restart. Indicate this support via a WIPHY flag
> to mac80211, if the hardware params flag mentions the support to
> add wifi mac sequence numbers for TX frames in the firmware.
>
> All the other hardwares, except WCN3990, are not affected by this
> change, since the hardware params flag is not set for any hardware
> except for WCN3990
>
> Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
> Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1
> Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00048
>
> Signed-off-by: Rakesh Pillai
> Signed-off-by: Youghandhar Chintala
> ---
> drivers/net/wireless/ath/ath10k/core.c | 15 +++
> drivers/net/wireless/ath/ath10k/hw.h | 3 +++
> drivers/net/wireless/ath/ath10k/mac.c | 3 +++
> 3 files changed, 21 insertions(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c
> b/drivers/net/wireless/ath/ath10k/core.c
> index 796107b..4155f94 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -90,6 +90,7 @@ static const struct ath10k_hw_params
> ath10k_hw_params_list[] = {
> .hw_filter_reset_required = true,
> .fw_diag_ce_download = false,
> .tx_stats_over_pktlog = true,
> + .tx_mac_seq_by_fw = false,
Probably orthogonal to this patch, there is a static array maintained
for different hardware configs and the structure members like
"tx_mac_seq_by_fw" are initialized. This does not seem to be scalable
and probably these parameters can be auto populated based on FW
capabilities and so we don't have to maintain the static array.
Thoughts?
-Abhishek
[PATCH v2 2/2] KVM: SVM: Add support for Virtual SPEC_CTRL
Newer AMD processors have a feature to virtualize the use of the
SPEC_CTRL MSR. A hypervisor may wish to impose speculation controls on
guest execution or a guest may want to impose its own speculation
controls. Therefore, the processor implements both host and guest
versions of SPEC_CTRL. Presence of this feature is indicated via CPUID
function 0x800A_EDX[20]: GuestSpecCtrl. Hypervisors are not
required to enable this feature since it is automatically enabled on
processors that support it.
When in host mode, the host SPEC_CTRL value is in effect and writes
update only the host version of SPEC_CTRL. On a VMRUN, the processor
loads the guest version of SPEC_CTRL from the VMCB. When the guest
writes SPEC_CTRL, only the guest version is updated. On a VMEXIT,
the guest version is saved into the VMCB and the processor returns
to only using the host SPEC_CTRL for speculation control. The guest
SPEC_CTRL is located at offset 0x2E0 in the VMCB.
The effective SPEC_CTRL setting is the guest SPEC_CTRL setting or'ed
with the hypervisor SPEC_CTRL setting. This allows the hypervisor to
ensure a minimum SPEC_CTRL if desired.
This support also fixes an issue where a guest may sometimes see an
inconsistent value for the SPEC_CTRL MSR on processors that support
this feature. With the current SPEC_CTRL support, the first write to
SPEC_CTRL is intercepted and the virtualized version of the SPEC_CTRL
MSR is not updated. When the guest reads back the SPEC_CTRL MSR, it
will be 0x0, instead of the actual expected value. There isn’t a
security concern here, because the host SPEC_CTRL value is or’ed with
the Guest SPEC_CTRL value to generate the effective SPEC_CTRL value.
KVM writes with the guest's virtualized SPEC_CTRL value to SPEC_CTRL
MSR just before the VMRUN, so it will always have the actual value
even though it doesn’t appear that way in the guest. The guest will
only see the proper value for the SPEC_CTRL register if the guest was
to write to the SPEC_CTRL register again. With Virtual SPEC_CTRL
support, the MSR interception of SPEC_CTRL is disabled during
vmcb_init, so this will no longer be an issue.
Signed-off-by: Babu Moger
---
arch/x86/include/asm/svm.h |4 +++-
arch/x86/kvm/svm/svm.c | 29 +
2 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
index 71d630bb5e08..753b25db427c 100644
--- a/arch/x86/include/asm/svm.h
+++ b/arch/x86/include/asm/svm.h
@@ -248,12 +248,14 @@ struct vmcb_save_area {
u64 br_to;
u64 last_excp_from;
u64 last_excp_to;
+ u8 reserved_12[72];
+ u32 spec_ctrl; /* Guest version of SPEC_CTRL at 0x2E0 */
/*
* The following part of the save area is valid only for
* SEV-ES guests when referenced through the GHCB.
*/
- u8 reserved_7[104];
+ u8 reserved_7[28];
u64 reserved_8; /* rax already available at 0x01f8 */
u64 rcx;
u64 rdx;
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 79b3a564f1c9..6d3db3e8cdfe 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -1230,6 +1230,16 @@ static void init_vmcb(struct vcpu_svm *svm)
svm_check_invpcid(svm);
+ /*
+* If the host supports V_SPEC_CTRL then disable the interception
+* of MSR_IA32_SPEC_CTRL.
+*/
+ if (boot_cpu_has(X86_FEATURE_V_SPEC_CTRL)) {
+ save->spec_ctrl = svm->spec_ctrl;
+ set_msr_interception(&svm->vcpu, svm->msrpm,
+MSR_IA32_SPEC_CTRL, 1, 1);
+ }
+
if (kvm_vcpu_apicv_active(&svm->vcpu))
avic_init_vmcb(svm);
@@ -2549,7 +2559,10 @@ static int svm_get_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr_info)
!guest_cpuid_has(vcpu, X86_FEATURE_AMD_SSBD))
return 1;
- msr_info->data = svm->spec_ctrl;
+ if (static_cpu_has(X86_FEATURE_V_SPEC_CTRL))
+ msr_info->data = svm->vmcb->save.spec_ctrl;
+ else
+ msr_info->data = svm->spec_ctrl;
break;
case MSR_AMD64_VIRT_SPEC_CTRL:
if (!msr_info->host_initiated &&
@@ -2640,6 +2653,8 @@ static int svm_set_msr(struct kvm_vcpu *vcpu, struct
msr_data *msr)
return 1;
svm->spec_ctrl = data;
+ if (static_cpu_has(X86_FEATURE_V_SPEC_CTRL))
+ svm->vmcb->save.spec_ctrl = data;
if (!data)
break;
@@ -3590,7 +3605,10 @@ static __no_kcsan fastpath_t svm_vcpu_run(struct
kvm_vcpu *vcpu)
* is no need to worry about the conditional branch over the wrmsr
* being speculatively taken.
*/
- x86_spec_ctrl_set_guest(svm->spec_ctrl, svm->virt_spec_ctrl);
+ if (static_cpu_has(X86_FEATURE_V_SPEC_CTRL))
+
[PATCH v2 1/2] x86/cpufeatures: Add the Virtual SPEC_CTRL feature
Newer AMD processors have a feature to virtualize the use of the SPEC_CTRL MSR. Presence of this feature is indicated via CPUID function 0x800A_EDX[20]: GuestSpecCtrl. When preset, the SPEC_CTRL MSR is automatically virtualized. Signed-off-by: Babu Moger --- arch/x86/include/asm/cpufeatures.h |1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h index dad350d42ecf..aee4a924ecd7 100644 --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -335,6 +335,7 @@ #define X86_FEATURE_AVIC (15*32+13) /* Virtual Interrupt Controller */ #define X86_FEATURE_V_VMSAVE_VMLOAD(15*32+15) /* Virtual VMSAVE VMLOAD */ #define X86_FEATURE_VGIF (15*32+16) /* Virtual GIF */ +#define X86_FEATURE_V_SPEC_CTRL(15*32+20) /* Virtual SPEC_CTRL */ /* Intel-defined CPU features, CPUID level 0x0007:0 (ECX), word 16 */ #define X86_FEATURE_AVX512VBMI (16*32+ 1) /* AVX512 Vector Bit Manipulation instructions*/
[PATCH v2 0/2] x86: Add the feature Virtual SPEC_CTRL
Newer AMD processors have a feature to virtualize the use of the SPEC_CTRL MSR on the guest. The series adds the feature support and enables the feature on SVM. --- v2: NOTE: This is not final yet. Sending out the patches to make sure I captured all the comments correctly. 1. Most of the changes are related to Jim and Sean's feedback. 2. Improved the description of patch #2. 3. Updated the vmcb save area's guest spec_ctrl value(offset 0x2E0) properly. Initialized during init_vmcb and svm_set_msr and returned the value from save area for svm_get_msr. 4. As Jim commented, transferred the value into the VMCB prior to VMRUN and out of the VMCB after #VMEXIT. 5. Added kvm-unit-test to detect the SPEC CTRL feature. https://lore.kernel.org/kvm/160865324865.19910.5159218511905134908.stgit@bmoger-ubuntu/ 6. Sean mantioned of renaming MSR_AMD64_VIRT_SPEC_CTRL. But, it might create even more confusion, so dropped the idea for now. v1: https://lore.kernel.org/kvm/160738054169.28590.5171339079028237631.stgit@bmoger-ubuntu/ --- Babu Moger (2): x86/cpufeatures: Add the Virtual SPEC_CTRL feature KVM: SVM: Add support for Virtual SPEC_CTRL arch/x86/include/asm/cpufeatures.h |1 + arch/x86/include/asm/svm.h |4 +++- arch/x86/kvm/svm/svm.c | 29 + 3 files changed, 29 insertions(+), 5 deletions(-) --
Re: [RFC PATCH 1/3] mm: support hugetlb free page reporting
On 12/21/20 11:46 PM, Liang Li wrote:
> Free page reporting only supports buddy pages, it can't report the
> free pages reserved for hugetlbfs case. On the other hand, hugetlbfs
> is a good choice for a system with a huge amount of RAM, because it
> can help to reduce the memory management overhead and improve system
> performance.
> This patch add the support for reporting hugepages in the free list
> of hugetlb, it canbe used by virtio_balloon driver for memory
> overcommit and pre zero out free pages for speeding up memory population.
My apologies as I do not follow virtio_balloon driver. Comments from
the hugetlb perspective.
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -41,6 +41,7 @@
> #include
> #include
> #include
> +#include "page_reporting.h"
> #include "internal.h"
>
> int hugetlb_max_hstate __read_mostly;
> @@ -1028,6 +1029,11 @@ static void enqueue_huge_page(struct hstate *h, struct
> page *page)
> list_move(&page->lru, &h->hugepage_freelists[nid]);
> h->free_huge_pages++;
> h->free_huge_pages_node[nid]++;
> + if (hugepage_reported(page)) {
> + __ClearPageReported(page);
> + pr_info("%s, free_huge_pages=%ld\n", __func__,
> h->free_huge_pages);
> + }
> + hugepage_reporting_notify_free(h->order);
> }
>
> static struct page *dequeue_huge_page_node_exact(struct hstate *h, int nid)
> @@ -5531,6 +5537,29 @@ follow_huge_pgd(struct mm_struct *mm, unsigned long
> address, pgd_t *pgd, int fla
> return pte_page(*(pte_t *)pgd) + ((address & ~PGDIR_MASK) >>
> PAGE_SHIFT);
> }
>
> +bool isolate_free_huge_page(struct page *page, struct hstate *h, int nid)
Looks like this always returns true. Should it be type void?
> +{
> + bool ret = true;
> +
> + VM_BUG_ON_PAGE(!PageHead(page), page);
> +
> + list_move(&page->lru, &h->hugepage_activelist);
> + set_page_refcounted(page);
> + h->free_huge_pages--;
> + h->free_huge_pages_node[nid]--;
> +
> + return ret;
> +}
> +
...
> diff --git a/mm/page_reporting.c b/mm/page_reporting.c
> index 20ec3fb1afc4..15d4b5372df8 100644
> --- a/mm/page_reporting.c
> +++ b/mm/page_reporting.c
> @@ -7,6 +7,7 @@
> #include
> #include
> #include
> +#include
>
> #include "page_reporting.h"
> #include "internal.h"
> @@ -16,6 +17,10 @@ static struct page_reporting_dev_info __rcu *pr_dev_info
> __read_mostly;
> int page_report_mini_order = pageblock_order;
> unsigned long page_report_batch_size = 32 * 1024 * 1024;
>
> +static struct page_reporting_dev_info __rcu *hgpr_dev_info __read_mostly;
> +int hugepage_report_mini_order = pageblock_order;
> +unsigned long hugepage_report_batch_size = 64 * 1024 * 1024;
> +
> enum {
> PAGE_REPORTING_IDLE = 0,
> PAGE_REPORTING_REQUESTED,
> @@ -67,6 +72,24 @@ void __page_reporting_notify(void)
> rcu_read_unlock();
> }
>
> +/* notify prdev of free hugepage reporting request */
> +void __hugepage_reporting_notify(void)
> +{
> + struct page_reporting_dev_info *prdev;
> +
> + /*
> + * We use RCU to protect the pr_dev_info pointer. In almost all
> + * cases this should be present, however in the unlikely case of
> + * a shutdown this will be NULL and we should exit.
> + */
> + rcu_read_lock();
> + prdev = rcu_dereference(hgpr_dev_info);
> + if (likely(prdev))
> + __page_reporting_request(prdev);
> +
> + rcu_read_unlock();
> +}
> +
> static void
> page_reporting_drain(struct page_reporting_dev_info *prdev,
>struct scatterlist *sgl, unsigned int nents, bool reported)
> @@ -103,6 +126,213 @@ page_reporting_drain(struct page_reporting_dev_info
> *prdev,
> sg_init_table(sgl, nents);
> }
>
> +static void
> +hugepage_reporting_drain(struct page_reporting_dev_info *prdev,
> + struct hstate *h, struct scatterlist *sgl,
> + unsigned int nents, bool reported)
> +{
> + struct scatterlist *sg = sgl;
> +
> + /*
> + * Drain the now reported pages back into their respective
> + * free lists/areas. We assume at least one page is populated.
> + */
> + do {
> + struct page *page = sg_page(sg);
> +
> + putback_isolate_huge_page(h, page);
> +
> + /* If the pages were not reported due to error skip flagging */
> + if (!reported)
> + continue;
> +
> + __SetPageReported(page);
> + } while ((sg = sg_next(sg)));
> +
> + /* reinitialize scatterlist now that it is empty */
> + sg_init_table(sgl, nents);
> +}
> +
> +/*
> + * The page reporting cycle consists of 4 stages, fill, report, drain, and
> + * idle. We will cycle through the first 3 stages until we cannot obtain a
> + * full scatterlist of pages, in that case we will switch to idle.
> + */
As mentioned, I am not familiar with virtio_balloon and the overall design.
So, some of this does not make sense to me.
> +static int
> +hugepage
[PATCH 0/6] wlan-ng: checkpatch.pl cleanup series
Hi, This patch series cleans up all the checkpatch.pl related warnings in the wlan-ng module. I tried to resolve those issues in a sensible manner. Johannes Czekay (6): wlan-ng: clean up line ending wlan-ng: clean up spinlock_t definition wlan-ng: rename macros wlan-ng: clean up line length wlan-ng: clean up alignment wlan-ng: clean up reused macros drivers/staging/wlan-ng/cfg80211.c | 33 --- drivers/staging/wlan-ng/hfa384x.h | 2 +- drivers/staging/wlan-ng/p80211metadef.h| 24 +-- drivers/staging/wlan-ng/p80211metastruct.h | 18 +--- drivers/staging/wlan-ng/p80211netdev.c | 2 +- drivers/staging/wlan-ng/p80211req.c| 6 +-- drivers/staging/wlan-ng/prism2mgmt.c | 48 ++ drivers/staging/wlan-ng/prism2mib.c| 18 8 files changed, 56 insertions(+), 95 deletions(-) -- 2.25.1
[PATCH 2/6] wlan-ng: clean up spinlock_t definition
This patch cleans up a "spinlock_t definition without comment" warning in
hfa384x.h.
Signed-off-by: Johannes Czekay
Co-developed-by: Nicolai Fischer
Signed-off-by: Nicolai Fischer
---
drivers/staging/wlan-ng/hfa384x.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 88e894dd3568..13ab9545a066 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1184,7 +1184,7 @@ struct hfa384x_usbctlx {
};
struct hfa384x_usbctlxq {
- spinlock_t lock;
+ spinlock_t lock;/* Lock for CTLX que */
struct list_head pending;
struct list_head active;
struct list_head completing;
--
2.25.1
[PATCH 4/6] wlan-ng: clean up line length
This patch cleans up all remaining line length related warnings.
Signed-off-by: Johannes Czekay
Co-developed-by: Nicolai Fischer
Signed-off-by: Nicolai Fischer
---
drivers/staging/wlan-ng/cfg80211.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/wlan-ng/cfg80211.c
b/drivers/staging/wlan-ng/cfg80211.c
index bdb1e6677cc7..0e44a0f73a6a 100644
--- a/drivers/staging/wlan-ng/cfg80211.c
+++ b/drivers/staging/wlan-ng/cfg80211.c
@@ -365,7 +365,8 @@ static int prism2_scan(struct wiphy *wiphy,
msg2.beaconperiod.data,
ie_buf,
ie_len,
- (msg2.signal.data - 65536) * 100, /*
Conversion to signed type */
+ /* Conversion to signed type */
+ (msg2.signal.data - 65536) * 100,
GFP_KERNEL);
if (!bss) {
--
2.25.1
[PATCH 3/6] wlan-ng: rename macros
This patch renames some of the macros defined in "p80211metadef.h" in
order to fix some of the line length related warnings from checkpatch.
Since these macros are very long, fitting them within the given line
length would be really hard otherwise.
Signed-off-by: Johannes Czekay
Co-developed-by: Nicolai Fischer
Signed-off-by: Nicolai Fischer
---
drivers/staging/wlan-ng/cfg80211.c | 18 +-
drivers/staging/wlan-ng/p80211metadef.h | 24
drivers/staging/wlan-ng/p80211netdev.c | 2 +-
drivers/staging/wlan-ng/p80211req.c | 6 +++---
drivers/staging/wlan-ng/prism2mib.c | 18 +-
5 files changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/staging/wlan-ng/cfg80211.c
b/drivers/staging/wlan-ng/cfg80211.c
index eda5b5a4e089..bdb1e6677cc7 100644
--- a/drivers/staging/wlan-ng/cfg80211.c
+++ b/drivers/staging/wlan-ng/cfg80211.c
@@ -159,7 +159,7 @@ static int prism2_add_key(struct wiphy *wiphy, struct
net_device *dev,
}
if (prism2_domibset_uint32(wlandev,
- DIDMIB_DOT11SMT_PRIVACYTABLE_WEPDEFAULTKEYID,
+ DIDMIB_DOT11SMT_PRIVACYTBL_WEPDEFAULTKEYID,
key_index))
return -EFAULT;
@@ -232,7 +232,7 @@ static int prism2_set_default_key(struct wiphy *wiphy,
struct net_device *dev,
struct wlandevice *wlandev = dev->ml_priv;
return prism2_domibset_uint32(wlandev,
-
DIDMIB_DOT11SMT_PRIVACYTABLE_WEPDEFAULTKEYID,
+
DIDMIB_DOT11SMT_PRIVACYTBL_WEPDEFAULTKEYID,
key_index);
}
@@ -401,7 +401,7 @@ static int prism2_set_wiphy_params(struct wiphy *wiphy, u32
changed)
data = wiphy->rts_threshold;
result = prism2_domibset_uint32(wlandev,
-
DIDMIB_DOT11MAC_OPERATIONTABLE_RTSTHRESHOLD,
+
DIDMIB_DOT11MAC_OPERATIONTBL_RTSTHRESHOLD,
data);
if (result) {
err = -EFAULT;
@@ -416,7 +416,7 @@ static int prism2_set_wiphy_params(struct wiphy *wiphy, u32
changed)
data = wiphy->frag_threshold;
result = prism2_domibset_uint32(wlandev,
-
DIDMIB_DOT11MAC_OPERATIONTABLE_FRAGMENTATIONTHRESHOLD,
+
DIDMIB_DOT11MAC_OPERATIONTBL_FRAGMENTATIONTHRESHOLD,
data);
if (result) {
err = -EFAULT;
@@ -471,7 +471,7 @@ static int prism2_connect(struct wiphy *wiphy, struct
net_device *dev,
return -EINVAL;
result = prism2_domibset_uint32(wlandev,
- DIDMIB_DOT11SMT_PRIVACYTABLE_WEPDEFAULTKEYID,
+ DIDMIB_DOT11SMT_PRIVACYTBL_WEPDEFAULTKEYID,
sme->key_idx);
if (result)
goto exit;
@@ -490,13 +490,13 @@ static int prism2_connect(struct wiphy *wiphy, struct
net_device *dev,
* seems reasonable anyways
*/
result = prism2_domibset_uint32(wlandev,
-
DIDMIB_DOT11SMT_PRIVACYTABLE_PRIVACYINVOKED,
+
DIDMIB_DOT11SMT_PRIVACYTBL_PRIVACYINVOKED,
P80211ENUM_truth_true);
if (result)
goto exit;
result = prism2_domibset_uint32(wlandev,
-
DIDMIB_DOT11SMT_PRIVACYTABLE_EXCLUDEUNENCRYPTED,
+
DIDMIB_DOT11SMT_PRIVACYTBL_EXCLUDEUNENCRYPTED,
P80211ENUM_truth_true);
if (result)
goto exit;
@@ -506,13 +506,13 @@ static int prism2_connect(struct wiphy *wiphy, struct
net_device *dev,
* and exclude unencrypted
*/
result = prism2_domibset_uint32(wlandev,
-
DIDMIB_DOT11SMT_PRIVACYTABLE_PRIVACYINVOKED,
+
DIDMIB_DOT11SMT_PRIVACYTBL_PRIVACYINVOKED,
P80211ENUM_truth_false);
if (result)
goto exit;
result = prism2_domibset_uint32(wlandev,
-
DIDMIB_DOT11SMT_PRIVACYTABLE_EXCLUDEUNENCRYPTED,
+
DIDMIB_DOT11SMT_PRIVACYTBL_EXCLUDEUNENCRYPTED,
[PATCH 1/6] wlan-ng: clean up line ending
This patch cleans up all the "Lines should not end with a '('" warnings.
Signed-off-by: Johannes Czekay
Co-developed-by: Nicolai Fischer
Signed-off-by: Nicolai Fischer
---
drivers/staging/wlan-ng/cfg80211.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wlan-ng/cfg80211.c
b/drivers/staging/wlan-ng/cfg80211.c
index 759e475e303c..eda5b5a4e089 100644
--- a/drivers/staging/wlan-ng/cfg80211.c
+++ b/drivers/staging/wlan-ng/cfg80211.c
@@ -324,8 +324,7 @@ static int prism2_scan(struct wiphy *wiphy,
(i < request->n_channels) && i < ARRAY_SIZE(prism2_channels);
i++)
msg1.channellist.data.data[i] =
- ieee80211_frequency_to_channel(
- request->channels[i]->center_freq);
+
ieee80211_frequency_to_channel(request->channels[i]->center_freq);
msg1.channellist.data.len = request->n_channels;
msg1.maxchanneltime.data = 250;
@@ -478,8 +477,7 @@ static int prism2_connect(struct wiphy *wiphy, struct
net_device *dev,
goto exit;
/* send key to driver */
- did = didmib_dot11smt_wepdefaultkeystable_key(
- sme->key_idx + 1);
+ did =
didmib_dot11smt_wepdefaultkeystable_key(sme->key_idx + 1);
result = prism2_domibset_pstr32(wlandev,
did, sme->key_len,
(u8 *)sme->key);
--
2.25.1
[PATCH 5/6] wlan-ng: clean up alignment
This patch cleans up all the alignment related warnings from checkpatch.
Signed-off-by: Johannes Czekay
Co-developed-by: Nicolai Fischer
Signed-off-by: Nicolai Fischer
---
drivers/staging/wlan-ng/cfg80211.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wlan-ng/cfg80211.c
b/drivers/staging/wlan-ng/cfg80211.c
index 0e44a0f73a6a..ac62746cf92e 100644
--- a/drivers/staging/wlan-ng/cfg80211.c
+++ b/drivers/staging/wlan-ng/cfg80211.c
@@ -472,8 +472,8 @@ static int prism2_connect(struct wiphy *wiphy, struct
net_device *dev,
return -EINVAL;
result = prism2_domibset_uint32(wlandev,
- DIDMIB_DOT11SMT_PRIVACYTBL_WEPDEFAULTKEYID,
- sme->key_idx);
+
DIDMIB_DOT11SMT_PRIVACYTBL_WEPDEFAULTKEYID,
+ sme->key_idx);
if (result)
goto exit;
@@ -584,8 +584,8 @@ static int prism2_set_tx_power(struct wiphy *wiphy, struct
wireless_dev *wdev,
data = MBM_TO_DBM(mbm);
result = prism2_domibset_uint32(wlandev,
- DIDMIB_DOT11PHY_TXPOWERTABLE_CURRENTTXPOWERLEVEL,
- data);
+
DIDMIB_DOT11PHY_TXPOWERTABLE_CURRENTTXPOWERLEVEL,
+ data);
if (result) {
err = -EFAULT;
--
2.25.1
[PATCH 6/6] wlan-ng: clean up reused macros
This patch cleans up two "macro argument reuse" warnings by checkpatch.
This should also make the code much more readable.
Signed-off-by: Johannes Czekay
Co-developed-by: Nicolai Fischer
Signed-off-by: Nicolai Fischer
---
drivers/staging/wlan-ng/p80211metastruct.h | 18 +---
drivers/staging/wlan-ng/prism2mgmt.c | 48 ++
2 files changed, 14 insertions(+), 52 deletions(-)
diff --git a/drivers/staging/wlan-ng/p80211metastruct.h
b/drivers/staging/wlan-ng/p80211metastruct.h
index 4adc64580185..e963227f797c 100644
--- a/drivers/staging/wlan-ng/p80211metastruct.h
+++ b/drivers/staging/wlan-ng/p80211metastruct.h
@@ -114,22 +114,8 @@ struct p80211msg_dot11req_scan_results {
struct p80211item_uint32 cfpollreq;
struct p80211item_uint32 privacy;
struct p80211item_uint32 capinfo;
- struct p80211item_uint32 basicrate1;
- struct p80211item_uint32 basicrate2;
- struct p80211item_uint32 basicrate3;
- struct p80211item_uint32 basicrate4;
- struct p80211item_uint32 basicrate5;
- struct p80211item_uint32 basicrate6;
- struct p80211item_uint32 basicrate7;
- struct p80211item_uint32 basicrate8;
- struct p80211item_uint32 supprate1;
- struct p80211item_uint32 supprate2;
- struct p80211item_uint32 supprate3;
- struct p80211item_uint32 supprate4;
- struct p80211item_uint32 supprate5;
- struct p80211item_uint32 supprate6;
- struct p80211item_uint32 supprate7;
- struct p80211item_uint32 supprate8;
+ struct p80211item_uint32 basicrate[8];
+ struct p80211item_uint32 supprate[8];
} __packed;
struct p80211msg_dot11req_start {
diff --git a/drivers/staging/wlan-ng/prism2mgmt.c
b/drivers/staging/wlan-ng/prism2mgmt.c
index 1bd36dc2b7ff..8540c3336907 100644
--- a/drivers/staging/wlan-ng/prism2mgmt.c
+++ b/drivers/staging/wlan-ng/prism2mgmt.c
@@ -388,6 +388,7 @@ int prism2mgmt_scan_results(struct wlandevice *wlandev,
void *msgp)
struct hfa384x_hscan_result_sub *item = NULL;
int count;
+ int i;
req = msgp;
@@ -437,42 +438,17 @@ int prism2mgmt_scan_results(struct wlandevice *wlandev,
void *msgp)
if (item->supprates[count] == 0)
break;
-#define REQBASICRATE(N) \
- do { \
- if ((count >= (N)) && DOT11_RATE5_ISBASIC_GET( \
- item->supprates[(N) - 1])) { \
- req->basicrate ## N .data = item->supprates[(N) - 1]; \
- req->basicrate ## N .status = \
- P80211ENUM_msgitem_status_data_ok; \
- } \
- } while (0)
-
- REQBASICRATE(1);
- REQBASICRATE(2);
- REQBASICRATE(3);
- REQBASICRATE(4);
- REQBASICRATE(5);
- REQBASICRATE(6);
- REQBASICRATE(7);
- REQBASICRATE(8);
-
-#define REQSUPPRATE(N) \
- do { \
- if (count >= (N)) { \
- req->supprate ## N .data = item->supprates[(N) - 1]; \
- req->supprate ## N .status = \
- P80211ENUM_msgitem_status_data_ok; \
- } \
- } while (0)
-
- REQSUPPRATE(1);
- REQSUPPRATE(2);
- REQSUPPRATE(3);
- REQSUPPRATE(4);
- REQSUPPRATE(5);
- REQSUPPRATE(6);
- REQSUPPRATE(7);
- REQSUPPRATE(8);
+ for (i = 0; i < 8; i++) {
+ if (count > 1) {
+ if (DOT11_RATE5_ISBASIC_GET(item->supprates[i])) {
+ req->basicrate[i].data = item->supprates[i];
+ req->basicrate[i].status =
P80211ENUM_msgitem_status_data_ok;
+ }
+
+ req->supprate[i].data = item->supprates[i];
+ req->supprate[i].status =
P80211ENUM_msgitem_status_data_ok;
+ }
+ }
/* beacon period */
req->beaconperiod.status = P80211ENUM_msgitem_status_data_ok;
--
2.25.1
[PATCH 4/4] MAINTAINERS: Add entry for Qualcomm QCA807x PHY driver
Add maintainers entry for the Qualcomm QCA807x PHY driver. Signed-off-by: Robert Marko Cc: Luka Perkov --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 281de213ef47..a86731f86292 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -14546,6 +14546,15 @@ S: Maintained F: Documentation/devicetree/bindings/regulator/vqmmc-ipq4019-regulator.yaml F: drivers/regulator/vqmmc-ipq4019-regulator.c +QUALCOMM QCA807X PHY DRIVER +M: Robert Marko +M: Luka Perkov +L: linux-arm-...@vger.kernel.org +S: Maintained +F: Documentation/devicetree/bindings/net/qcom,qca807x.yaml +F: drivers/net/phy/qca807x.c +F: include/dt-bindings/net/qcom-qca807x.h + QUALCOMM RMNET DRIVER M: Subash Abhinov Kasiviswanathan M: Sean Tranchetti -- 2.29.2
[PATCH 3/4] net: phy: Add Qualcomm QCA807x driver
This adds driver for the Qualcomm QCA8072 and QCA8075 PHY-s. They are 2 or 5 port IEEE 802.3 clause 22 compliant 10BASE-Te, 100BASE-TX and 1000BASE-T PHY-s. They feature 2 SerDes, one for PSGMII or QSGMII connection with MAC, while second one is SGMII for connection to MAC or fiber. Both models have a combo port that supports 1000BASE-X and 100BASE-FX fiber. Each PHY inside of QCA807x series has 2 digitally controlled output only pins that natively drive LED-s. But some vendors used these to driver generic LED-s controlled by user space, so lets enable registering each PHY as GPIO controller and add driver for it. This also adds the ability to specify DT properties so that 1000 Base-T LED will also be lit up for 100 and 10 Base connections. This is usually done by U-boot, but boards running mainline U-boot are not configuring this yet. These PHY-s are commonly used in Qualcomm IPQ40xx, IPQ60xx and IPQ807x boards. Signed-off-by: Robert Marko Cc: Luka Perkov --- drivers/net/phy/Kconfig | 10 + drivers/net/phy/Makefile | 1 + drivers/net/phy/qca807x.c | 811 ++ 3 files changed, 822 insertions(+) create mode 100644 drivers/net/phy/qca807x.c diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig index 92164e7b7f60..1aaeca3f133c 100644 --- a/drivers/net/phy/Kconfig +++ b/drivers/net/phy/Kconfig @@ -264,6 +264,16 @@ config QSEMI_PHY help Currently supports the qs6612 +config QCA807X_PHY + tristate "Qualcomm QCA807X PHYs" + depends on OF_MDIO + help + Adds support for the Qualcomm QCA807x PHYs. + These are 802.3 Clause 22 compliant PHYs supporting gigabit + ethernet as well as 100Base-FX and 1000Base-X fibre. + + Currently supports the QCA8072 and QCA8075 models. + config REALTEK_PHY tristate "Realtek PHYs" help diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile index ca0a313423b9..5f463ce0f711 100644 --- a/drivers/net/phy/Makefile +++ b/drivers/net/phy/Makefile @@ -74,6 +74,7 @@ obj-$(CONFIG_MICROSEMI_PHY) += mscc/ obj-$(CONFIG_NATIONAL_PHY) += national.o obj-$(CONFIG_NXP_TJA11XX_PHY) += nxp-tja11xx.o obj-$(CONFIG_QSEMI_PHY)+= qsemi.o +obj-$(CONFIG_QCA807X_PHY) += qca807x.o obj-$(CONFIG_REALTEK_PHY) += realtek.o obj-$(CONFIG_RENESAS_PHY) += uPD60620.o obj-$(CONFIG_ROCKCHIP_PHY) += rockchip.o diff --git a/drivers/net/phy/qca807x.c b/drivers/net/phy/qca807x.c new file mode 100644 index ..db082d2aa560 --- /dev/null +++ b/drivers/net/phy/qca807x.c @@ -0,0 +1,811 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Copyright (c) 2020 Sartura Ltd. + * + * Author: Robert Marko + * + * Qualcomm QCA8072 and QCA8075 PHY driver + */ + +#include +#include +#include +#include +#include +#include +#include + +#include + +#define PHY_ID_QCA8072 0x004dd0b2 +#define PHY_ID_QCA8075 0x004dd0b1 +#define PHY_ID_QCA807X_PSGMII 0x06820805 + +/* Downshift */ +#define QCA807X_SMARTSPEED_EN BIT(5) +#define QCA807X_SMARTSPEED_RETRY_LIMIT_MASKGENMASK(4, 2) +#define QCA807X_SMARTSPEED_RETRY_LIMIT_DEFAULT 5 +#define QCA807X_SMARTSPEED_RETRY_LIMIT_MIN 2 +#define QCA807X_SMARTSPEED_RETRY_LIMIT_MAX 9 + +/* Cable diagnostic test (CDT) */ +#define QCA807X_CDT0x16 +#define QCA807X_CDT_ENABLE BIT(15) +#define QCA807X_CDT_ENABLE_INTER_PAIR_SHORTBIT(13) +#define QCA807X_CDT_STATUS BIT(11) +#define QCA807X_CDT_MMD3_STATUS0x8064 +#define QCA807X_CDT_MDI0_STATUS_MASK GENMASK(15, 12) +#define QCA807X_CDT_MDI1_STATUS_MASK GENMASK(11, 8) +#define QCA807X_CDT_MDI2_STATUS_MASK GENMASK(7, 4) +#define QCA807X_CDT_MDI3_STATUS_MASK GENMASK(3, 0) +#define QCA807X_CDT_RESULTS_INVALID0x0 +#define QCA807X_CDT_RESULTS_OK 0x1 +#define QCA807X_CDT_RESULTS_OPEN 0x2 +#define QCA807X_CDT_RESULTS_SAME_SHORT 0x3 +#define QCA807X_CDT_RESULTS_CROSS_SHORT_WITH_MDI1_SAME_OK 0x4 +#define QCA807X_CDT_RESULTS_CROSS_SHORT_WITH_MDI2_SAME_OK 0x8 +#define QCA807X_CDT_RESULTS_CROSS_SHORT_WITH_MDI3_SAME_OK 0xc +#define QCA807X_CDT_RESULTS_CROSS_SHORT_WITH_MDI1_SAME_OPEN0x6 +#define QCA807X_CDT_RESULTS_CROSS_SHORT_WITH_MDI2_SAME_OPEN0xa +#define QCA807X_CDT_RESULTS_CROSS_SHORT_WITH_MDI3_SAME_OPEN0xe +#define QCA807X_CDT_RESULTS_CROSS_SHORT_WITH_MDI1_SAME_SHORT 0x7 +#define QCA807X_CDT_RESULTS_CROSS_SHORT_WITH_MDI2_SAME_SHORT 0xb +#define QCA807X_CDT_RESULTS_CROSS_SHORT_WITH_MDI3_SAME_SHORT 0xf +#define QCA807X_CDT_RESULTS_BUSY 0x9 +#define QCA807X_CDT_MMD3_MD
[PATCH 2/4] dt-bindings: net: Add bindings for Qualcomm QCA807x
Add DT bindings for Qualcomm QCA807x PHYs.
Signed-off-by: Robert Marko
Cc: Luka Perkov
---
.../devicetree/bindings/net/qcom,qca807x.yaml | 88 +++
1 file changed, 88 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/qcom,qca807x.yaml
diff --git a/Documentation/devicetree/bindings/net/qcom,qca807x.yaml
b/Documentation/devicetree/bindings/net/qcom,qca807x.yaml
new file mode 100644
index ..87e093ad4193
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/qcom,qca807x.yaml
@@ -0,0 +1,88 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/qcom,qca807x.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm QCA807x PHY
+
+maintainers:
+ - Robert Marko
+
+description: |
+ Bindings for Qualcomm QCA807x PHYs
+
+allOf:
+ - $ref: ethernet-phy.yaml#
+
+properties:
+ reg:
+maxItems: 1
+
+ qcom,fiber-enable:
+description: |
+ If present, then PHYs combo port is configured to operate in combo
+ mode. In combo mode autodetection of copper and fiber media is
+ used in order to support both of them.
+ Combo mode can be strapped as well, if not strapped this property
+ will set combo support anyway.
+type: boolean
+
+ qcom,psgmii-az:
+description: |
+ If present, then PSMGII PHY will advertise 802.3-az support to
+ the MAC.
+type: boolean
+
+ gpio-controller: true
+ "#gpio-cells":
+const: 2
+
+ qcom,single-led-1000:
+description: |
+ If present, then dedicated 1000 Mbit will light up for 1000Base-T.
+ This is a workround for boards with a single LED instead of two.
+type: boolean
+
+ qcom,single-led-100:
+description: |
+ If present, then dedicated 1000 Mbit will light up for 100Base-TX.
+ This is a workround for boards with a single LED instead of two.
+type: boolean
+
+ qcom,single-led-10:
+description: |
+ If present, then dedicated 1000 Mbit will light up for 10Base-Te.
+ This is a workround for boards with a single LED instead of two.
+type: boolean
+
+ qcom,tx-driver-strength:
+description: PSGMII/QSGMII TX driver strength control.
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
+
+ qcom,control-dac:
+description: Analog MDI driver amplitude and bias current.
+$ref: /schemas/types.yaml#/definitions/uint32
+enum: [0, 1, 2, 3, 4, 5, 6, 7]
+
+required:
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+#include
+
+mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+compatible = "ethernet-phy-ieee802.3-c22";
+reg = <0>;
+
+qcom,control-dac = ;
+ };
+};
--
2.29.2
[PATCH 1/4] dt-bindings: net: Add QCA807x PHY
Add DT bindings for Qualcomm QCA807x PHY series. Signed-off-by: Robert Marko Cc: Luka Perkov --- include/dt-bindings/net/qcom-qca807x.h | 45 ++ 1 file changed, 45 insertions(+) create mode 100644 include/dt-bindings/net/qcom-qca807x.h diff --git a/include/dt-bindings/net/qcom-qca807x.h b/include/dt-bindings/net/qcom-qca807x.h new file mode 100644 index ..b341e62f5fb6 --- /dev/null +++ b/include/dt-bindings/net/qcom-qca807x.h @@ -0,0 +1,45 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +/* + * Device Tree constants for the Qualcomm QCA807X PHYs + */ + +#ifndef _DT_BINDINGS_QCOM_QCA807X_H +#define _DT_BINDINGS_QCOM_QCA807X_H + +#define PSGMII_QSGMII_TX_DRIVER_140MV 0 +#define PSGMII_QSGMII_TX_DRIVER_160MV 1 +#define PSGMII_QSGMII_TX_DRIVER_180MV 2 +#define PSGMII_QSGMII_TX_DRIVER_200MV 3 +#define PSGMII_QSGMII_TX_DRIVER_220MV 4 +#define PSGMII_QSGMII_TX_DRIVER_240MV 5 +#define PSGMII_QSGMII_TX_DRIVER_260MV 6 +#define PSGMII_QSGMII_TX_DRIVER_280MV 7 +#define PSGMII_QSGMII_TX_DRIVER_300MV 8 +#define PSGMII_QSGMII_TX_DRIVER_320MV 9 +#define PSGMII_QSGMII_TX_DRIVER_400MV 10 +#define PSGMII_QSGMII_TX_DRIVER_500MV 11 +/* Default value */ +#define PSGMII_QSGMII_TX_DRIVER_600MV 12 + +/* Full amplitude, full bias current */ +#define QCA807X_CONTROL_DAC_FULL_VOLT_BIAS 0 +/* Amplitude follow DSP (amplitude is adjusted based on cable length), half bias current */ +#define QCA807X_CONTROL_DAC_DSP_VOLT_HALF_BIAS 1 +/* Full amplitude, bias current follow DSP (bias current is adjusted based on cable length) */ +#define QCA807X_CONTROL_DAC_FULL_VOLT_DSP_BIAS 2 +/* Both amplitude and bias current follow DSP */ +#define QCA807X_CONTROL_DAC_DSP_VOLT_BIAS 3 +/* Full amplitude, half bias current */ +#define QCA807X_CONTROL_DAC_FULL_VOLT_HALF_BIAS4 +/* Amplitude follow DSP setting; 1/4 bias current when cable<10m, + * otherwise half bias current + */ +#define QCA807X_CONTROL_DAC_DSP_VOLT_QUARTER_BIAS 5 +/* Full amplitude; same bias current setting with “010” and “011”, + * but half more bias is reduced when cable <10m + */ +#define QCA807X_CONTROL_DAC_FULL_VOLT_HALF_BIAS_SHORT 6 +/* Amplitude follow DSP; same bias current setting with “110”, default value */ +#define QCA807X_CONTROL_DAC_DSP_VOLT_HALF_BIAS_SHORT 7 + +#endif -- 2.29.2
[PATCH 0/4] Add support for Qualcomm QCA807x PHYs
This patch series adds support for Qualcomm QCA807x PHYs. These are really common companion PHYs on boards featuring Qualcomm IPQ40xx, IPQ60xx and IPQ807x SoCs. They are 2 or 5 port IEEE 802.3 clause 22 compliant 10BASE-Te, 100BASE-TX and 1000BASE-T PHY-s. They feature 2 SerDes, one for PSGMII or QSGMII connection with MAC, while second one is SGMII for connection to MAC or fiber. Both models have a combo port that supports 1000BASE-X and 100BASE-FX fiber. Each PHY inside of QCA807x series has 2 digitally controlled output only pins that natively drive LED-s. But some vendors used these to driver generic LED-s controlled by user space, so lets enable registering each PHY as GPIO controller and add driver for it. Robert Marko (4): dt-bindings: net: Add QCA807x PHY dt-bindings: net: Add bindings for Qualcomm QCA807x net: phy: Add Qualcomm QCA807x driver MAINTAINERS: Add entry for Qualcomm QCA807x PHY driver .../devicetree/bindings/net/qcom,qca807x.yaml | 88 ++ MAINTAINERS | 9 + drivers/net/phy/Kconfig | 10 + drivers/net/phy/Makefile | 1 + drivers/net/phy/qca807x.c | 811 ++ include/dt-bindings/net/qcom-qca807x.h| 45 + 6 files changed, 964 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/qcom,qca807x.yaml create mode 100644 drivers/net/phy/qca807x.c create mode 100644 include/dt-bindings/net/qcom-qca807x.h -- 2.29.2
Re: [PATCH -next] i2c: busses: use DIV_ROUND_UP macro to do calculation
On Tue, Dec 22, 2020 at 09:31:31PM +0800, Zheng Yongjun wrote: > Don't open-code DIV_ROUND_UP() kernel macro. > > Signed-off-by: Zheng Yongjun LGTM, Acked-by: Uwe Kleine-König Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [GIT PULL] exfat update for 5.11-rc1
The pull request you sent on Tue, 22 Dec 2020 15:58:04 +0900: > git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat.git > tags/exfat-for-5.11-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/e9e541ecfee39745da042ff5194b0813bb4c3f9c Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] configfs updates for 5.11
The pull request you sent on Tue, 22 Dec 2020 17:03:41 +0100: > git://git.infradead.org/users/hch/configfs.git tags/configfs-5.11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4f06f210673e6841439a0f91fcde64960cdbeb5c Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL] dma-mapping updates for 5.11
The pull request you sent on Tue, 22 Dec 2020 17:01:12 +0100: > git://git.infradead.org/users/hch/dma-mapping.git tags/dma-mapping-5.11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/347d81b68b8f7044c9ce3fefa130a736ca916176 Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [GIT PULL 2/2] Kconfig updates for v5.11-rc1
The pull request you sent on Wed, 23 Dec 2020 01:47:55 +0900: > git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git > tags/kconfig-v5.11 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/2762db756f422861c70868bc2d4b9b5d1ce6a59d Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
