* [virtio-dev] Re: [PATCH 4/6] vhost_vdpa: support doorbell mapping via mmap
From: Rob Miller @ 2020-05-29 18:30 UTC (permalink / raw)
To: Jason Wang, Virtio-Dev; +Cc: kvm, virtualization, Netdev, linux-kernel
In-Reply-To: <20200529080303.15449-5-jasowang@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4726 bytes --]
Given the need for 4K doorbell such that QEMU can easily map, ect, and
assuming that I have a HW device which exposes 2 VQ's, with a notification
area off of BAR3, offset=whatever, notifier_multiplier=4, we don't need to
have 2 x 4K pages mapped into the VM for both doorbells do we? The guest
driver would ring DB0 at BAR4+offset, and DB1 at BAR4+offset+(4*1).
The 4K per DB is useful how? This allows for QEMU trapping of individual
DBs, that can then be used to do what, just forward the DBs via some other
scheme - this makes sense for non-HW related Virtio devices I guess. Is
this why there is a qemu option?
Rob Miller
rob.miller@broadcom.com
(919)721-3339
On Fri, May 29, 2020 at 4:03 AM Jason Wang <jasowang@redhat.com> wrote:
> Currently the doorbell is relayed via eventfd which may have
> significant overhead because of the cost of vmexits or syscall. This
> patch introduces mmap() based doorbell mapping which can eliminate the
> overhead caused by vmexit or syscall.
>
> To ease the userspace modeling of the doorbell layout (usually
> virtio-pci), this patch starts from a doorbell per page
> model. Vhost-vdpa only support the hardware doorbell that sit at the
> boundary of a page and does not share the page with other registers.
>
> Doorbell of each virtqueue must be mapped separately, pgoff is the
> index of the virtqueue. This allows userspace to map a subset of the
> doorbell which may be useful for the implementation of software
> assisted virtqueue (control vq) in the future.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/vhost/vdpa.c | 59 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
>
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index 6ff72289f488..bbe23cea139a 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -15,6 +15,7 @@
> #include <linux/module.h>
> #include <linux/cdev.h>
> #include <linux/device.h>
> +#include <linux/mm.h>
> #include <linux/iommu.h>
> #include <linux/uuid.h>
> #include <linux/vdpa.h>
> @@ -741,12 +742,70 @@ static int vhost_vdpa_release(struct inode *inode,
> struct file *filep)
> return 0;
> }
>
> +static vm_fault_t vhost_vdpa_fault(struct vm_fault *vmf)
> +{
> + struct vhost_vdpa *v = vmf->vma->vm_file->private_data;
> + struct vdpa_device *vdpa = v->vdpa;
> + const struct vdpa_config_ops *ops = vdpa->config;
> + struct vdpa_notification_area notify;
> + struct vm_area_struct *vma = vmf->vma;
> + u16 index = vma->vm_pgoff;
> +
> + notify = ops->get_vq_notification(vdpa, index);
> +
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> + if (remap_pfn_range(vma, vmf->address & PAGE_MASK,
> + notify.addr >> PAGE_SHIFT, PAGE_SIZE,
> + vma->vm_page_prot))
> + return VM_FAULT_SIGBUS;
> +
> + return VM_FAULT_NOPAGE;
> +}
> +
> +static const struct vm_operations_struct vhost_vdpa_vm_ops = {
> + .fault = vhost_vdpa_fault,
> +};
> +
> +static int vhost_vdpa_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + struct vhost_vdpa *v = vma->vm_file->private_data;
> + struct vdpa_device *vdpa = v->vdpa;
> + const struct vdpa_config_ops *ops = vdpa->config;
> + struct vdpa_notification_area notify;
> + int index = vma->vm_pgoff;
> +
> + if (vma->vm_end - vma->vm_start != PAGE_SIZE)
> + return -EINVAL;
> + if ((vma->vm_flags & VM_SHARED) == 0)
> + return -EINVAL;
> + if (vma->vm_flags & VM_READ)
> + return -EINVAL;
> + if (index > 65535)
> + return -EINVAL;
> + if (!ops->get_vq_notification)
> + return -ENOTSUPP;
> +
> + /* To be safe and easily modelled by userspace, We only
> + * support the doorbell which sits on the page boundary and
> + * does not share the page with other registers.
> + */
> + notify = ops->get_vq_notification(vdpa, index);
> + if (notify.addr & (PAGE_SIZE - 1))
> + return -EINVAL;
> + if (vma->vm_end - vma->vm_start != notify.size)
> + return -ENOTSUPP;
> +
> + vma->vm_ops = &vhost_vdpa_vm_ops;
> + return 0;
> +}
> +
> static const struct file_operations vhost_vdpa_fops = {
> .owner = THIS_MODULE,
> .open = vhost_vdpa_open,
> .release = vhost_vdpa_release,
> .write_iter = vhost_vdpa_chr_write_iter,
> .unlocked_ioctl = vhost_vdpa_unlocked_ioctl,
> + .mmap = vhost_vdpa_mmap,
> .compat_ioctl = compat_ptr_ioctl,
> };
>
> --
> 2.20.1
>
>
[-- Attachment #2: Type: text/html, Size: 6072 bytes --]
^ permalink raw reply
* Re: [PATCH 4/6] vhost_vdpa: support doorbell mapping via mmap
From: Rob Miller @ 2020-05-29 18:30 UTC (permalink / raw)
To: Jason Wang, Virtio-Dev; +Cc: kvm, virtualization, Netdev, linux-kernel
In-Reply-To: <20200529080303.15449-5-jasowang@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 4726 bytes --]
Given the need for 4K doorbell such that QEMU can easily map, ect, and
assuming that I have a HW device which exposes 2 VQ's, with a notification
area off of BAR3, offset=whatever, notifier_multiplier=4, we don't need to
have 2 x 4K pages mapped into the VM for both doorbells do we? The guest
driver would ring DB0 at BAR4+offset, and DB1 at BAR4+offset+(4*1).
The 4K per DB is useful how? This allows for QEMU trapping of individual
DBs, that can then be used to do what, just forward the DBs via some other
scheme - this makes sense for non-HW related Virtio devices I guess. Is
this why there is a qemu option?
Rob Miller
rob.miller@broadcom.com
(919)721-3339
On Fri, May 29, 2020 at 4:03 AM Jason Wang <jasowang@redhat.com> wrote:
> Currently the doorbell is relayed via eventfd which may have
> significant overhead because of the cost of vmexits or syscall. This
> patch introduces mmap() based doorbell mapping which can eliminate the
> overhead caused by vmexit or syscall.
>
> To ease the userspace modeling of the doorbell layout (usually
> virtio-pci), this patch starts from a doorbell per page
> model. Vhost-vdpa only support the hardware doorbell that sit at the
> boundary of a page and does not share the page with other registers.
>
> Doorbell of each virtqueue must be mapped separately, pgoff is the
> index of the virtqueue. This allows userspace to map a subset of the
> doorbell which may be useful for the implementation of software
> assisted virtqueue (control vq) in the future.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/vhost/vdpa.c | 59 ++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
>
> diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
> index 6ff72289f488..bbe23cea139a 100644
> --- a/drivers/vhost/vdpa.c
> +++ b/drivers/vhost/vdpa.c
> @@ -15,6 +15,7 @@
> #include <linux/module.h>
> #include <linux/cdev.h>
> #include <linux/device.h>
> +#include <linux/mm.h>
> #include <linux/iommu.h>
> #include <linux/uuid.h>
> #include <linux/vdpa.h>
> @@ -741,12 +742,70 @@ static int vhost_vdpa_release(struct inode *inode,
> struct file *filep)
> return 0;
> }
>
> +static vm_fault_t vhost_vdpa_fault(struct vm_fault *vmf)
> +{
> + struct vhost_vdpa *v = vmf->vma->vm_file->private_data;
> + struct vdpa_device *vdpa = v->vdpa;
> + const struct vdpa_config_ops *ops = vdpa->config;
> + struct vdpa_notification_area notify;
> + struct vm_area_struct *vma = vmf->vma;
> + u16 index = vma->vm_pgoff;
> +
> + notify = ops->get_vq_notification(vdpa, index);
> +
> + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
> + if (remap_pfn_range(vma, vmf->address & PAGE_MASK,
> + notify.addr >> PAGE_SHIFT, PAGE_SIZE,
> + vma->vm_page_prot))
> + return VM_FAULT_SIGBUS;
> +
> + return VM_FAULT_NOPAGE;
> +}
> +
> +static const struct vm_operations_struct vhost_vdpa_vm_ops = {
> + .fault = vhost_vdpa_fault,
> +};
> +
> +static int vhost_vdpa_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + struct vhost_vdpa *v = vma->vm_file->private_data;
> + struct vdpa_device *vdpa = v->vdpa;
> + const struct vdpa_config_ops *ops = vdpa->config;
> + struct vdpa_notification_area notify;
> + int index = vma->vm_pgoff;
> +
> + if (vma->vm_end - vma->vm_start != PAGE_SIZE)
> + return -EINVAL;
> + if ((vma->vm_flags & VM_SHARED) == 0)
> + return -EINVAL;
> + if (vma->vm_flags & VM_READ)
> + return -EINVAL;
> + if (index > 65535)
> + return -EINVAL;
> + if (!ops->get_vq_notification)
> + return -ENOTSUPP;
> +
> + /* To be safe and easily modelled by userspace, We only
> + * support the doorbell which sits on the page boundary and
> + * does not share the page with other registers.
> + */
> + notify = ops->get_vq_notification(vdpa, index);
> + if (notify.addr & (PAGE_SIZE - 1))
> + return -EINVAL;
> + if (vma->vm_end - vma->vm_start != notify.size)
> + return -ENOTSUPP;
> +
> + vma->vm_ops = &vhost_vdpa_vm_ops;
> + return 0;
> +}
> +
> static const struct file_operations vhost_vdpa_fops = {
> .owner = THIS_MODULE,
> .open = vhost_vdpa_open,
> .release = vhost_vdpa_release,
> .write_iter = vhost_vdpa_chr_write_iter,
> .unlocked_ioctl = vhost_vdpa_unlocked_ioctl,
> + .mmap = vhost_vdpa_mmap,
> .compat_ioctl = compat_ptr_ioctl,
> };
>
> --
> 2.20.1
>
>
[-- Attachment #2: Type: text/html, Size: 6072 bytes --]
^ permalink raw reply
* Re: [PATCH] drm/amdgpu/display: drop the reduction loop when setting the sync groups
From: Kazlauskas, Nicholas @ 2020-05-29 18:30 UTC (permalink / raw)
To: Alex Deucher; +Cc: Alex Deucher, amd-gfx list
In-Reply-To: <CADnq5_Mu_nuv2dXnwz2ctOHHoizwcFczKNESFE_nsYzE8g3pog@mail.gmail.com>
On 2020-05-29 2:04 p.m., Alex Deucher wrote:
> On Fri, May 29, 2020 at 9:56 AM Kazlauskas, Nicholas
> <nicholas.kazlauskas@amd.com> wrote:
>>
>> On 2020-05-28 10:06 a.m., Alex Deucher wrote:
>>> The logic for blanked is not the same as having a plane_state. Technically
>>> you can drive an OTG without anything connected in the front end and it'll
>>> just draw out the back color which is distinct from having the OTG be blanked.
>>> If we add planes or unblank the OTG later then we'll still want the
>>> synchronization.
>>>
>>> Bug: https://gitlab.freedesktop.org/drm/amd/issues/781
>>> Fixes: 5fc0cbfad45648 ("drm/amd/display: determine if a pipe is synced by plane state")
>>> Cc: nicholas.kazlauskas@amd.com
>>> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> > ---
>>> drivers/gpu/drm/amd/display/dc/core/dc.c | 8 --------
>>> 1 file changed, 8 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c b/drivers/gpu/drm/amd/display/dc/core/dc.c
>>> index 04c3d9f7e323..6279520f7873 100644
>>> --- a/drivers/gpu/drm/amd/display/dc/core/dc.c
>>> +++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
>>> @@ -1040,14 +1040,6 @@ static void program_timing_sync(
>>> status->timing_sync_info.master = false;
>>>
>>> }
>>> - /* remove any other pipes with plane as they have already been synced */
>>> - for (j = j + 1; j < group_size; j++) {
>>> - if (pipe_set[j]->plane_state) {
>>> - group_size--;
>>> - pipe_set[j] = pipe_set[group_size];
>>> - j--;
>>> - }
>>> - }
>>
>>
>> Looking at this again, I think I may understand the issue this was
>> trying to work around.
>>
>> If we try to force timing synchronization on displays that are currently
>> active then this is going to force reset the vertical position,
>> resulting in screen corruption.
>>
>> So what this logic was attempting to do was ensure that timing
>> synchronization only happens when committing two streams at a time
>> without any image on the screen.
>>
>> Maybe it'd be best to just blank these streams out first, but for now,
>> let's actually go back to fixing this by applying the actual dpg/tg
>> check that Wenjing suggests, something like:
>>
>> if (pool->opps[i]->funcs->dpg_is_blanked)
>> s.blank_enabled =
>> pool->opps[i]->funcs->dpg_is_blanked(pool->opps[i]);
>> else
>> s.blank_enabled = tg->funcs->is_blanked(tg);
>>
>
> Hmm, it's not clear to me where this code needs to go. Can you point
> me in the right direction or provide a quick patch?
>
> Thanks,
>
> Alex
The old code used to check !tg->funcs->is_blanked(tg) ie. to drop the
pipe from the group if it's currently active.
The issue was that on newer ASIC it's now the DPG that's the indicator
from the hardware side, so we should replace the !plane_state check with
a check first for !dpg_is_blanked and then !is_blanked if the DPG
doesn't exist.
Regards,
Nicholas Kazlauskas
>
>>
>>
>> The reason why we have this issue in the first place is because
>> amdgpu_dm usually commits a dc_state with the planes already in it
>> instead of committing them later, so plane_state not being NULL is
>> typically true.
>>
>> Regards,
>> Nicholas Kazlauskas
>>
>>>
>>> if (group_size > 1) {
>>> dc->hwss.enable_timing_synchronization(
>>>
>>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH] x86/uaccess: Remove redundant likely/unlikely annotations
From: Randy Dunlap @ 2020-05-29 18:29 UTC (permalink / raw)
To: Josh Poimboeuf, Peter Zijlstra
Cc: Christoph Hellwig, Andrew Morton, broonie, linux-fsdevel,
linux-kernel, linux-mm, linux-next, mhocko, mm-commits, sfr,
Linus Torvalds, viro, x86, Steven Rostedt
In-Reply-To: <20200529172505.fdjppgquujab7ayv@treble>
On 5/29/20 10:25 AM, Josh Poimboeuf wrote:
> On Fri, May 29, 2020 at 06:54:19PM +0200, Peter Zijlstra wrote:
>> On Fri, May 29, 2020 at 11:50:11AM -0500, Josh Poimboeuf wrote:
>>> The nested likelys seem like overkill anyway -- user_access_begin() is
>>> __always_inline and it already has unlikely(), which should be
>>> propagated.
>>>
>>> So just remove the outer likelys?
>>
>> That fixes it. Ack!
>
> If there are no objections to the patch, I can add it to my objtool-core
> branch unless anybody else wants to take it. It only affects
> linux-next.
>
> ---8<---
>
> From: Josh Poimboeuf <jpoimboe@redhat.com>
> Subject: [PATCH] x86/uaccess: Remove redundant likely/unlikely annotations
>
> Since user_access_begin() already has an unlikely() annotation for its
> access_ok() check, "if (likely(user_access_begin))" results in nested
> likely annotations. When combined with CONFIG_TRACE_BRANCH_PROFILING,
> GCC converges the error/success paths of the nested ifs, using a
> register value to distinguish between them.
>
> While the code is technically uaccess safe, it complicates the
> branch-profiling generated code. It also confuses objtool, because it
> doesn't do register value tracking, resulting in the following warnings:
>
> arch/x86/lib/csum-wrappers_64.o: warning: objtool: csum_and_copy_from_user()+0x2a4: call to memset() with UACCESS enabled
> arch/x86/lib/csum-wrappers_64.o: warning: objtool: csum_and_copy_to_user()+0x243: return with UACCESS enabled
>
> The outer likely annotations aren't actually needed anyway, since the
> compiler propagates the error path coldness when it inlines
> user_access_begin().
>
> Fixes: 18372ef87665 ("x86_64: csum_..._copy_..._user(): switch to unsafe_..._user()")
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Acked-by: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Thanks.
> ---
> arch/x86/lib/csum-wrappers_64.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/lib/csum-wrappers_64.c b/arch/x86/lib/csum-wrappers_64.c
> index a12b8629206d..ee63d7576fd2 100644
> --- a/arch/x86/lib/csum-wrappers_64.c
> +++ b/arch/x86/lib/csum-wrappers_64.c
> @@ -27,7 +27,7 @@ csum_and_copy_from_user(const void __user *src, void *dst,
> might_sleep();
> *errp = 0;
>
> - if (!likely(user_access_begin(src, len)))
> + if (!user_access_begin(src, len))
> goto out_err;
>
> /*
> @@ -89,7 +89,7 @@ csum_and_copy_to_user(const void *src, void __user *dst,
>
> might_sleep();
>
> - if (unlikely(!user_access_begin(dst, len))) {
> + if (!user_access_begin(dst, len)) {
> *errp = -EFAULT;
> return 0;
> }
>
--
~Randy
^ permalink raw reply
* Re: [PATCH] RDMA/core: Use offsetofend() instead of open coding
From: Jason Gunthorpe @ 2020-05-29 18:29 UTC (permalink / raw)
To: linux-rdma
In-Reply-To: <0-v1-0bc346e08476+585-drop_offsetofend_jgg@mellanox.com>
On Wed, May 27, 2020 at 02:18:45PM -0300, Jason Gunthorpe wrote:
> From: Jason Gunthorpe <jgg@mellanox.com>
>
> No reason to open code this.
>
> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
> ---
> include/rdma/uverbs_ioctl.h | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Applied to for-next, thanks
Jason
^ permalink raw reply
* Re: [PATCH v30 09/20] mm: Introduce vm_ops->may_mprotect()
From: Dave Hansen @ 2020-05-29 18:28 UTC (permalink / raw)
To: Jarkko Sakkinen, linux-kernel, x86, linux-sgx
Cc: akpm, sean.j.christopherson, nhorman, npmccallum, haitao.huang,
andriy.shevchenko, tglx, kai.svahn, bp, josh, luto, kai.huang,
rientjes, cedric.xing, puiterwijk, Jethro Beekman
In-Reply-To: <20200515004410.723949-10-jarkko.sakkinen@linux.intel.com>
On 5/14/20 5:43 PM, Jarkko Sakkinen wrote:
> From: Sean Christopherson <sean.j.christopherson@intel.com>
>
> Add vm_ops()->may_mprotect() to check additional constrains set by a
> subsystem for a mprotect() call.
This changelog needs some more detail about why this is needed. It
would also be nice to include thought about what else it could get used
for and what subsystems can expect by doing this and what the mm core is
expected to do.
^ permalink raw reply
* Re: [PATCH][next] IB/hfi1: fix spelling mistake "enought" -> "enough"
From: Jason Gunthorpe @ 2020-05-29 18:28 UTC (permalink / raw)
To: Colin King
Cc: Mike Marciniszyn, Dennis Dalessandro, Doug Ledford, linux-rdma,
kernel-janitors, linux-kernel
In-Reply-To: <20200528110709.400935-1-colin.king@canonical.com>
On Thu, May 28, 2020 at 12:07:09PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a spelling mistake in an error message. Fix it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/infiniband/hw/hfi1/chip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to for-next, thanks
Jason
^ permalink raw reply
* Re: [PATCH][next] IB/hfi1: fix spelling mistake "enought" -> "enough"
From: Jason Gunthorpe @ 2020-05-29 18:28 UTC (permalink / raw)
To: Colin King
Cc: Mike Marciniszyn, Dennis Dalessandro, Doug Ledford, linux-rdma,
kernel-janitors, linux-kernel
In-Reply-To: <20200528110709.400935-1-colin.king@canonical.com>
On Thu, May 28, 2020 at 12:07:09PM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a spelling mistake in an error message. Fix it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
> drivers/infiniband/hw/hfi1/chip.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to for-next, thanks
Jason
^ permalink raw reply
* [PATCH] xen/build: fix xen/tools/binfile
From: Juergen Gross @ 2020-05-29 18:28 UTC (permalink / raw)
To: xen-devel
Cc: Juergen Gross, Stefano Stabellini, Julien Grall, Wei Liu,
Andrew Cooper, Ian Jackson, George Dunlap, Jan Beulich
xen/tools/binfile contains a bash specific command (let). This leads
to build failures on systems not using bash as /bin/sh.
Replace "let SHIFT=$OPTIND-1" by "SHIFT=$((OPTIND-1))".
Signed-off-by: Juergen Gross <jgross@suse.com>
---
xen/tools/binfile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/tools/binfile b/xen/tools/binfile
index df0301183f..23099c49bf 100755
--- a/xen/tools/binfile
+++ b/xen/tools/binfile
@@ -17,7 +17,7 @@ while getopts "ia:" opt; do
;;
esac
done
-let "SHIFT=$OPTIND-1"
+SHIFT=$((OPTIND-1))
shift $SHIFT
target=$1
--
2.26.2
^ permalink raw reply related
* Re: [meta-arm] [PATCH] arm-toolchain: set CVE_VERSION to fix cve-check warnings
From: Ralph Siemsen @ 2020-05-29 18:28 UTC (permalink / raw)
To: Jon Mason; +Cc: Sumit Garg, meta-arm
In-Reply-To: <20200529142830.GA20456@kudzu.us>
[-- Attachment #1: Type: text/plain, Size: 279 bytes --]
Hi Jon,
On Fri, May 29, 2020 at 10:28 AM Jon Mason <jdmason@kudzu.us> wrote:
>
> Applied to the master branch.
>
Great, thank you.
What is the process for applying it to dunfell - should I send another
patch (only the subject line will differ)?
Regards
Ralph
[-- Attachment #2: Type: text/html, Size: 613 bytes --]
^ permalink raw reply
* Re: [PATCH] x86/resctrl: fix a NULL vs IS_ERR() static checker warning
From: Reinette Chatre @ 2020-05-29 18:28 UTC (permalink / raw)
To: Dan Carpenter, Fenghua Yu
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
H. Peter Anvin, linux-kernel, kernel-janitors
In-Reply-To: <20200529122744.GA1217265@mwanda>
Hi Dan,
On 5/29/2020 5:27 AM, Dan Carpenter wrote:
> The callers don't expect *d_cdp to be set to an error pointer, they only
> check for NULL. This leads to a static checker warning:
>
> arch/x86/kernel/cpu/resctrl/rdtgroup.c:2648 __init_one_rdt_domain()
> warn: 'd_cdp' could be an error pointer
>
> I don't think this will lead to a real life bug, but it's easy enough to
> change it to be NULL.
Using "I don't think" could be a bit vague to the reader. It could be
changed to:
"This would not trigger a bug in this specific case because
__init_one_rdt_domain() calls it with a valid domain that would not have
a negative id and thus not trigger the return of the ERR_PTR(). If this
was a negative domain id then the call to rdt_find_domain() in
domain_add_cpu() would have returned the ERR_PTR() much earlier and the
creation of the domain with an invalid id would have been prevented.
Even though a bug is not triggered currently the right and safe thing to
do is to set the pointer to NULL because that is what can be checked for
when the caller is handling the CDP and non-CDP cases."
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 23b4b61319d3f..3f844f14fc0a6 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -1117,6 +1117,7 @@ static int rdt_cdp_peer_get(struct rdt_resource *r, struct rdt_domain *d,
> _d_cdp = rdt_find_domain(_r_cdp, d->id, NULL);
> if (WARN_ON(IS_ERR_OR_NULL(_d_cdp))) {
> _r_cdp = NULL;
> + _d_cdp = NULL;
> ret = -EINVAL;
> }
>
>
The below fixes tag may be helpful:
Fixes: 52eb74339a62 ("x86/resctrl: Fix rdt_find_domain() return value
and checks")
Thank you very much for catching this and sending a fix. I just have the
commit message comments, apart from that the your fix looks good to me.
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* Re: [PATCH 10/30] KVM: nSVM: extract preparation of VMCB for nested run
From: Krish Sadhukhan @ 2020-05-29 18:27 UTC (permalink / raw)
To: Paolo Bonzini, linux-kernel, kvm
In-Reply-To: <20200529153934.11694-11-pbonzini@redhat.com>
On 5/29/20 8:39 AM, Paolo Bonzini wrote:
> Split out filling svm->vmcb.save and svm->vmcb.control before VMRUN.
> Only the latter will be useful when restoring nested SVM state.
>
> This patch introduces no semantic change, so the MMU setup is still
> done in nested_prepare_vmcb_save. The next patch will clean up things.
>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> arch/x86/kvm/svm/nested.c | 40 +++++++++++++++++++++++----------------
> 1 file changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/kvm/svm/nested.c b/arch/x86/kvm/svm/nested.c
> index fc0c6d1678eb..73be7af79453 100644
> --- a/arch/x86/kvm/svm/nested.c
> +++ b/arch/x86/kvm/svm/nested.c
> @@ -245,21 +245,8 @@ static void load_nested_vmcb_control(struct vcpu_svm *svm,
> svm->vcpu.arch.tsc_offset += control->tsc_offset;
> }
>
> -void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,
> - struct vmcb *nested_vmcb)
> +static void nested_prepare_vmcb_save(struct vcpu_svm *svm, struct vmcb *nested_vmcb)
Not a big deal, but I feel that it helps a lot in readability if we keep
the names symmetric. This one could be named prepare_nested_vmcb_save to
match load_nested_vmcb_control that you created in the previous patch.
Or load_nested_vmcb_control could be renamed to nested_load_vmcb_control
to match the name here.
> {
> - bool evaluate_pending_interrupts =
> - is_intercept(svm, INTERCEPT_VINTR) ||
> - is_intercept(svm, INTERCEPT_IRET);
> -
> - svm->nested.vmcb = vmcb_gpa;
> - if (kvm_get_rflags(&svm->vcpu) & X86_EFLAGS_IF)
> - svm->vcpu.arch.hflags |= HF_HIF_MASK;
> - else
> - svm->vcpu.arch.hflags &= ~HF_HIF_MASK;
> -
> - load_nested_vmcb_control(svm, &nested_vmcb->control);
> -
> if (nested_vmcb->control.nested_ctl & SVM_NESTED_CTL_NP_ENABLE)
> nested_svm_init_mmu_context(&svm->vcpu);
>
> @@ -291,7 +278,10 @@ void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,
> svm->vmcb->save.dr7 = nested_vmcb->save.dr7;
> svm->vcpu.arch.dr6 = nested_vmcb->save.dr6;
> svm->vmcb->save.cpl = nested_vmcb->save.cpl;
> +}
>
> +static void nested_prepare_vmcb_control(struct vcpu_svm *svm, struct vmcb *nested_vmcb)
> +{
> svm_flush_tlb(&svm->vcpu);
> if (nested_vmcb->control.int_ctl & V_INTR_MASKING_MASK)
> svm->vcpu.arch.hflags |= HF_VINTR_MASK;
> @@ -321,6 +311,26 @@ void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,
> */
> recalc_intercepts(svm);
>
> + mark_all_dirty(svm->vmcb);
> +}
> +
> +void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,
> + struct vmcb *nested_vmcb)
> +{
> + bool evaluate_pending_interrupts =
> + is_intercept(svm, INTERCEPT_VINTR) ||
> + is_intercept(svm, INTERCEPT_IRET);
> +
> + svm->nested.vmcb = vmcb_gpa;
> + if (kvm_get_rflags(&svm->vcpu) & X86_EFLAGS_IF)
> + svm->vcpu.arch.hflags |= HF_HIF_MASK;
> + else
> + svm->vcpu.arch.hflags &= ~HF_HIF_MASK;
> +
> + load_nested_vmcb_control(svm, &nested_vmcb->control);
> + nested_prepare_vmcb_save(svm, nested_vmcb);
> + nested_prepare_vmcb_control(svm, nested_vmcb);
> +
> /*
> * If L1 had a pending IRQ/NMI before executing VMRUN,
> * which wasn't delivered because it was disallowed (e.g.
> @@ -336,8 +346,6 @@ void enter_svm_guest_mode(struct vcpu_svm *svm, u64 vmcb_gpa,
> enable_gif(svm);
> if (unlikely(evaluate_pending_interrupts))
> kvm_make_request(KVM_REQ_EVENT, &svm->vcpu);
> -
> - mark_all_dirty(svm->vmcb);
> }
>
> int nested_svm_vmrun(struct vcpu_svm *svm)
^ permalink raw reply
* Re: [PATCH] x86/resctrl: fix a NULL vs IS_ERR() static checker warning
From: Reinette Chatre @ 2020-05-29 18:28 UTC (permalink / raw)
To: Dan Carpenter, Fenghua Yu
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
H. Peter Anvin, linux-kernel, kernel-janitors
In-Reply-To: <20200529122744.GA1217265@mwanda>
Hi Dan,
On 5/29/2020 5:27 AM, Dan Carpenter wrote:
> The callers don't expect *d_cdp to be set to an error pointer, they only
> check for NULL. This leads to a static checker warning:
>
> arch/x86/kernel/cpu/resctrl/rdtgroup.c:2648 __init_one_rdt_domain()
> warn: 'd_cdp' could be an error pointer
>
> I don't think this will lead to a real life bug, but it's easy enough to
> change it to be NULL.
Using "I don't think" could be a bit vague to the reader. It could be
changed to:
"This would not trigger a bug in this specific case because
__init_one_rdt_domain() calls it with a valid domain that would not have
a negative id and thus not trigger the return of the ERR_PTR(). If this
was a negative domain id then the call to rdt_find_domain() in
domain_add_cpu() would have returned the ERR_PTR() much earlier and the
creation of the domain with an invalid id would have been prevented.
Even though a bug is not triggered currently the right and safe thing to
do is to set the pointer to NULL because that is what can be checked for
when the caller is handling the CDP and non-CDP cases."
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> ---
> arch/x86/kernel/cpu/resctrl/rdtgroup.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/x86/kernel/cpu/resctrl/rdtgroup.c b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> index 23b4b61319d3f..3f844f14fc0a6 100644
> --- a/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> +++ b/arch/x86/kernel/cpu/resctrl/rdtgroup.c
> @@ -1117,6 +1117,7 @@ static int rdt_cdp_peer_get(struct rdt_resource *r, struct rdt_domain *d,
> _d_cdp = rdt_find_domain(_r_cdp, d->id, NULL);
> if (WARN_ON(IS_ERR_OR_NULL(_d_cdp))) {
> _r_cdp = NULL;
> + _d_cdp = NULL;
> ret = -EINVAL;
> }
>
>
The below fixes tag may be helpful:
Fixes: 52eb74339a62 ("x86/resctrl: Fix rdt_find_domain() return value
and checks")
Thank you very much for catching this and sending a fix. I just have the
commit message comments, apart from that the your fix looks good to me.
Acked-by: Reinette Chatre <reinette.chatre@intel.com>
Reinette
^ permalink raw reply
* master - Revert "pvck: dump headers_only to skip metadata text"
From: David Teigland @ 2020-05-29 18:27 UTC (permalink / raw)
To: lvm-devel
Gitweb: https://sourceware.org/git/?p=lvm2.git;a=commitdiff;h=d14a8040d4a2b264130cdb730cead935b0bf19f0
Commit: d14a8040d4a2b264130cdb730cead935b0bf19f0
Parent: ae029fcced5f79af748df28f20f952d158804482
Author: David Teigland <teigland@redhat.com>
AuthorDate: Fri May 29 13:26:43 2020 -0500
Committer: David Teigland <teigland@redhat.com>
CommitterDate: Fri May 29 13:26:43 2020 -0500
Revert "pvck: dump headers_only to skip metadata text"
This reverts commit 5410dd5441aa827b381ff64dfc6be6e4589d87a1.
Accidental push.
---
tools/lvmcmdline.c | 1 -
tools/pvck.c | 12 ++----------
tools/vals.h | 2 +-
3 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/tools/lvmcmdline.c b/tools/lvmcmdline.c
index 608653827..d87a8f053 100644
--- a/tools/lvmcmdline.c
+++ b/tools/lvmcmdline.c
@@ -1092,7 +1092,6 @@ int repairtype_arg(struct cmd_context *cmd, struct arg_values *av)
int dumptype_arg(struct cmd_context *cmd, struct arg_values *av)
{
if (!strcmp(av->value, "headers") ||
- !strcmp(av->value, "headers_only") ||
!strcmp(av->value, "metadata") ||
!strcmp(av->value, "metadata_all") ||
!strcmp(av->value, "metadata_search") ||
diff --git a/tools/pvck.c b/tools/pvck.c
index cd2c5b6d4..a0f567eeb 100644
--- a/tools/pvck.c
+++ b/tools/pvck.c
@@ -24,7 +24,6 @@
#define PRINT_CURRENT 1
#define PRINT_ALL 2
-#define PRINT_NONE 3
#define ID_STR_SIZE 40 /* uuid formatted with dashes is 38 chars */
@@ -1389,7 +1388,6 @@ static int _dump_headers(struct cmd_context *cmd, const char *dump, struct setti
{
uint64_t mda1_offset = 0, mda1_size = 0, mda2_offset = 0, mda2_size = 0; /* bytes */
uint32_t mda1_checksum, mda2_checksum;
- int print_metadata = 0;
int mda_count = 0;
int bad = 0;
@@ -1402,17 +1400,14 @@ static int _dump_headers(struct cmd_context *cmd, const char *dump, struct setti
return 1;
}
- if (!strcmp(dump, "headers_only"))
- print_metadata = PRINT_NONE;
-
/*
* The first mda is always 4096 bytes from the start of the device.
*/
- if (!_dump_mda_header(cmd, set, 1, print_metadata, 0, NULL, dev, def, 4096, mda1_size, &mda1_checksum, NULL))
+ if (!_dump_mda_header(cmd, set, 1, 0, 0, NULL, dev, def, 4096, mda1_size, &mda1_checksum, NULL))
bad++;
if (mda2_offset) {
- if (!_dump_mda_header(cmd, set, 1, print_metadata, 0, NULL, dev, def, mda2_offset, mda2_size, &mda2_checksum, NULL))
+ if (!_dump_mda_header(cmd, set, 1, 0, 0, NULL, dev, def, mda2_offset, mda2_size, &mda2_checksum, NULL))
bad++;
/* This probably indicates that one was committed and the other not. */
@@ -3088,9 +3083,6 @@ int pvck(struct cmd_context *cmd, int argc, char **argv)
else if (!strcmp(dump, "headers"))
ret = _dump_headers(cmd, dump, &set, labelsector, dev, def);
- else if (!strcmp(dump, "headers_only"))
- ret = _dump_headers(cmd, dump, &set, labelsector, dev, def);
-
else if (!strcmp(dump, "backup_to_raw")) {
ret = _dump_backup_to_raw(cmd, &set);
diff --git a/tools/vals.h b/tools/vals.h
index 623859e4d..70404436b 100644
--- a/tools/vals.h
+++ b/tools/vals.h
@@ -142,7 +142,7 @@ val(reportformat_VAL, reportformat_arg, "ReportFmt", "basic|json")
val(configreport_VAL, configreport_arg, "ConfigReport", "log|vg|lv|pv|pvseg|seg")
val(configtype_VAL, configtype_arg, "ConfigType", "current|default|diff|full|list|missing|new|profilable|profilable-command|profilable-metadata")
val(repairtype_VAL, repairtype_arg, "RepairType", "pv_header|metadata|label_header")
-val(dumptype_VAL, dumptype_arg, "DumpType", "headers|headers_only|metadata|metadata_all|metadata_search")
+val(dumptype_VAL, dumptype_arg, "DumpType", "headers|metadata|metadata_all|metadata_search")
/* this should always be last */
val(VAL_COUNT, NULL, NULL, NULL)
^ permalink raw reply related
* Re: [PULL 00/12] testing and plugin fixes
From: Peter Maydell @ 2020-05-29 18:25 UTC (permalink / raw)
To: Alex Bennée; +Cc: QEMU Developers
In-Reply-To: <20200527145455.2550-1-alex.bennee@linaro.org>
On Wed, 27 May 2020 at 15:54, Alex Bennée <alex.bennee@linaro.org> wrote:
>
> The following changes since commit ddc760832fa8cf5e93b9d9e6e854a5114ac63510:
>
> Merge remote-tracking branch 'remotes/gkurz/tags/9p-next-2020-05-26' into staging (2020-05-26 14:05:53 +0100)
>
> are available in the Git repository at:
>
> https://github.com/stsquad/qemu.git tags/pull-testing-tcg-plugins-270520-1
>
> for you to fetch changes up to 919bfbf5d6569b63a374332292cf3d2355a6d6c3:
>
> tests/tcg: add new threadcount test (2020-05-27 14:26:49 +0100)
>
> ----------------------------------------------------------------
> Testing and one plugin fix:
>
> - support alternates for genisoimage to test/vm
> - add clang++ to clang tests
> - fix record/replay smoke test
> - enable more softfloat tests
> - better detection of hung gdb
> - upgrade aarch64 tcg test x-compile to gcc-10
> - fix plugin cpu_index clash vs threads
Applied, thanks.
Please update the changelog at https://wiki.qemu.org/ChangeLog/5.1
for any user-visible changes.
-- PMM
^ permalink raw reply
* Re: [iptables PATCH] include: Avoid undefined left-shift in xt_sctp.h
From: Pablo Neira Ayuso @ 2020-05-29 18:26 UTC (permalink / raw)
To: Phil Sutter; +Cc: netfilter-devel
In-Reply-To: <20200529181022.21855-1-phil@nwl.cc>
On Fri, May 29, 2020 at 08:10:22PM +0200, Phil Sutter wrote:
> Pull the fix in kernel commit 164166558aace ("netfilter: uapi: Avoid
> undefined left-shift in xt_sctp.h") into iptables repository. The
> original description is:
>
> With 'bytes(__u32)' being 32, a left-shift of 31 may happen which is
> undefined for the signed 32-bit value 1. Avoid this by declaring 1 as
> unsigned.
>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
Acked-by: Pablo Neira Ayuso <pablo@netfilter.org>
Thanks Phil.
^ permalink raw reply
* [PATCH v7] dt-bindings: spi: Convert DW SPI binding to DT schema
From: Serge Semin @ 2020-05-29 18:25 UTC (permalink / raw)
To: Mark Brown, Rob Herring
Cc: Serge Semin, Serge Semin, Rob Herring, Georgy Vlasov,
Ramil Zaripov, Alexey Malahov, Thomas Bogendoerfer, Feng Tang,
Andy Shevchenko, Arnd Bergmann, linux-mips, linux-spi, devicetree,
linux-kernel
Modern device tree bindings are supposed to be created as YAML-files
in accordance with dt-schema. This commit replaces two DW SPI legacy
bare text bindings with YAML file. As before the bindings file states
that the corresponding dts node is supposed to be compatible either
with generic DW APB SSI controller or with Microsemi/Amazon/Renesas/Intel
vendors-specific controllers, to have registers, interrupts and clocks
properties. Though in case of Microsemi version of the controller
there must be two registers resources specified. Properties like
clock-names, reg-io-width, cs-gpio, num-cs, DMA and slave device
sub-nodes are optional.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Reviewed-by: Rob Herring <robh@kernel.org>
Cc: Georgy Vlasov <Georgy.Vlasov@baikalelectronics.ru>
Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru>
Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Feng Tang <feng.tang@intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-mips@vger.kernel.org
---
Changelog v7:
- Rebase on top of the spi/for-next branch.
- Add resets and reset-names properties, since Dinh Nguyen has slipped the
patchset optional reset-support in right in front of my nose.
---
.../bindings/spi/snps,dw-apb-ssi.txt | 49 -------
.../bindings/spi/snps,dw-apb-ssi.yaml | 133 ++++++++++++++++++
.../devicetree/bindings/spi/spi-dw.txt | 24 ----
3 files changed, 133 insertions(+), 73 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
create mode 100644 Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/spi-dw.txt
diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
deleted file mode 100644
index 0f21407a7ea3..000000000000
--- a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface.
-
-Required properties:
-- compatible : "snps,dw-apb-ssi" or "mscc,<soc>-spi", where soc is "ocelot" or
- "jaguar2", or "amazon,alpine-dw-apb-ssi", or "snps,dwc-ssi-1.01a" or
- "intel,keembay-ssi"
-- reg : The register base for the controller. For "mscc,<soc>-spi", a second
- register set is required (named ICPU_CFG:SPI_MST)
-- interrupts : One interrupt, used by the controller.
-- #address-cells : <1>, as required by generic SPI binding.
-- #size-cells : <0>, also as required by generic SPI binding.
-- clocks : phandles for the clocks, see the description of clock-names below.
- The phandle for the "ssi_clk" is required. The phandle for the "pclk" clock
- is optional. If a single clock is specified but no clock-name, it is the
- "ssi_clk" clock. If both clocks are listed, the "ssi_clk" must be first.
-
-Optional properties:
-- clock-names : Contains the names of the clocks:
- "ssi_clk", for the core clock used to generate the external SPI clock.
- "pclk", the interface clock, required for register access. If a clock domain
- used to enable this clock then it should be named "pclk_clkdomain".
-- cs-gpios : Specifies the gpio pins to be used for chipselects.
-- num-cs : The number of chipselects. If omitted, this will default to 4.
-- reg-io-width : The I/O register width (in bytes) implemented by this
- device. Supported values are 2 or 4 (the default).
-- dmas : Phandle + identifiers of Tx and Rx DMA channels.
-- dma-names : Contains the names of the DMA channels. Must be "tx" and "rx".
-- resets : contains an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : must contain "spi"
-
-Child nodes as per the generic SPI binding.
-
-Example:
-
- spi@fff00000 {
- compatible = "snps,dw-apb-ssi";
- reg = <0xfff00000 0x1000>;
- interrupts = <0 154 4>;
- #address-cells = <1>;
- #size-cells = <0>;
- clocks = <&spi_m_clk>;
- num-cs = <2>;
- cs-gpios = <&gpio0 13 0>,
- <&gpio0 14 0>;
- resets = <&rst SPIM0_RST>;
- reset-names = "spi";
- };
-
diff --git a/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
new file mode 100644
index 000000000000..c62cbe79f00d
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/snps,dw-apb-ssi.yaml
@@ -0,0 +1,133 @@
+# SPDX-License-Identifier: GPL-2.0-only
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/snps,dw-apb-ssi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Synopsys DesignWare AMBA 2.0 Synchronous Serial Interface
+
+maintainers:
+ - Mark Brown <broonie@kernel.org>
+
+allOf:
+ - $ref: "spi-controller.yaml#"
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - mscc,ocelot-spi
+ - mscc,jaguar2-spi
+ then:
+ properties:
+ reg:
+ minItems: 2
+
+properties:
+ compatible:
+ oneOf:
+ - description: Generic DW SPI Controller
+ enum:
+ - snps,dw-apb-ssi
+ - snps,dwc-ssi-1.01a
+ - description: Microsemi Ocelot/Jaguar2 SoC SPI Controller
+ items:
+ - enum:
+ - mscc,ocelot-spi
+ - mscc,jaguar2-spi
+ - const: snps,dw-apb-ssi
+ - description: Amazon Alpine SPI Controller
+ const: amazon,alpine-dw-apb-ssi
+ - description: Renesas RZ/N1 SPI Controller
+ items:
+ - const: renesas,rzn1-spi
+ - const: snps,dw-apb-ssi
+ - description: Intel Keem Bay SPI Controller
+ const: intel,keembay-ssi
+
+ reg:
+ minItems: 1
+ items:
+ - description: DW APB SSI controller memory mapped registers
+ - description: SPI MST region map
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 1
+ items:
+ - description: SPI Controller reference clock source
+ - description: APB interface clock source
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: ssi_clk
+ - const: pclk
+
+ resets:
+ maxItems: 1
+
+ reset-names:
+ const: spi
+
+ reg-io-width:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: I/O register width (in bytes) implemented by this device
+ default: 4
+ enum: [ 2, 4 ]
+
+ num-cs:
+ default: 4
+ minimum: 1
+ maximum: 4
+
+ dmas:
+ items:
+ - description: TX DMA Channel
+ - description: RX DMA Channel
+
+ dma-names:
+ items:
+ - const: tx
+ - const: rx
+
+patternProperties:
+ "^.*@[0-9a-f]+$":
+ type: object
+ properties:
+ reg:
+ minimum: 0
+ maximum: 3
+
+ spi-rx-bus-width:
+ const: 1
+
+ spi-tx-bus-width:
+ const: 1
+
+unevaluatedProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+ - interrupts
+ - clocks
+
+examples:
+ - |
+ spi@fff00000 {
+ compatible = "snps,dw-apb-ssi";
+ reg = <0xfff00000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0 154 4>;
+ clocks = <&spi_m_clk>;
+ num-cs = <2>;
+ cs-gpios = <&gpio0 13 0>,
+ <&gpio0 14 0>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/spi/spi-dw.txt b/Documentation/devicetree/bindings/spi/spi-dw.txt
deleted file mode 100644
index 7b63ed601990..000000000000
--- a/Documentation/devicetree/bindings/spi/spi-dw.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Synopsys DesignWare SPI master
-
-Required properties:
-- compatible: should be "snps,designware-spi"
-- #address-cells: see spi-bus.txt
-- #size-cells: see spi-bus.txt
-- reg: address and length of the spi master registers
-- interrupts: should contain one interrupt
-- clocks: spi clock phandle
-- num-cs: see spi-bus.txt
-
-Optional properties:
-- cs-gpios: see spi-bus.txt
-
-Example:
-
-spi: spi@4020a000 {
- compatible = "snps,designware-spi";
- interrupts = <11 1>;
- reg = <0x4020a000 0x1000>;
- clocks = <&pclk>;
- num-cs = <2>;
- cs-gpios = <&banka 0 0>;
-};
--
2.26.2
^ permalink raw reply related
* Re: [PATCH net-next v4 1/4] dt-bindings: net: Add tx and rx internal delays
From: Rob Herring @ 2020-05-29 18:25 UTC (permalink / raw)
To: Dan Murphy
Cc: andrew, f.fainelli, hkallweit1, davem, netdev, linux-kernel,
devicetree
In-Reply-To: <20200527164934.28651-2-dmurphy@ti.com>
On Wed, May 27, 2020 at 11:49:31AM -0500, Dan Murphy wrote:
> tx-internal-delays and rx-internal-delays are a common setting for RGMII
> capable devices.
>
> These properties are used when the phy-mode or phy-controller is set to
> rgmii-id, rgmii-rxid or rgmii-txid. These modes indicate to the
> controller that the PHY will add the internal delay for the connection.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> .../bindings/net/ethernet-controller.yaml | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> index ac471b60ed6a..70702a4ef5e8 100644
> --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> @@ -143,6 +143,20 @@ properties:
> Specifies the PHY management type. If auto is set and fixed-link
> is not specified, it uses MDIO for management.
>
> + rx-internal-delay-ps:
> + $ref: /schemas/types.yaml#definitions/uint32
> + description: |
> + RGMII Receive PHY Clock Delay defined in pico seconds. This is used for
> + PHY's that have configurable RX internal delays. This property is only
> + used when the phy-mode or phy-connection-type is rgmii-id or rgmii-rxid.
Isn't this a property of the phy (this is the controller schema)? Looks
like we have similar properties already and they go in phy nodes. Would
be good to have a standard property, but let's be clear where it goes.
We need to add '-ps' as a standard unit suffix (in dt-schema) and then a
type is not needed here.
Rob
^ permalink raw reply
* [PATCH 00/10] improve OF_PLATDATA support
From: Jagan Teki @ 2020-05-29 18:25 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20200529181521.22073-1-walter.lozano@collabora.com>
Hi Walter,
On Fri, May 29, 2020 at 11:45 PM Walter Lozano
<walter.lozano@collabora.com> wrote:
>
> When using OF_PLATDATA dtbs are converted to C structs in order to save
> space as we can remove both dtbs and libraries from TPL/SPL binaries.
>
> This patchset tries to improve its support by overcoming some limitations
> in the current implementation
>
> First, the support for scan and check for valid driver/aliases is added
> in order to generate U_BOOT_DEVICE entries with valid driver names.
>
> Secondly, the way information about linked noded (phandle) is generated
> in C structs is improved in order to make it easier to get a device
> associated to its data.
>
> Lastly the the suport for the property cd-gpios is added, which is used to
> configure the card detection gpio on MMC is added.
Does it impact the footprint? If yes any statistic about how much
space has been reduced with respect to current platdata?
Jagan.
^ permalink raw reply
* Re: Adding usb-ctrl from intel-bmc into phosphor-misc
From: Vernon Mauery @ 2020-05-29 18:24 UTC (permalink / raw)
To: James Feist; +Cc: Brad Bishop, 郁雷, openbmc
In-Reply-To: <2856971c-8efc-cf48-a8c0-210bba71e92e@linux.intel.com>
On 29-May-2020 10:09 AM, James Feist wrote:
>On 5/28/2020 5:48 AM, Brad Bishop wrote:
>>On Wed, 2020-05-27 at 11:07 +0800, 郁雷 wrote:
>>>There is a script [usb-ctrl][1] hosted in intel-bmc.
>>>It supports the VirtualMedia feature by insert/eject files to the host
>>>as a USB mass-storage device.
>>>Comparing to the existing [state_hook][2] in jsnbd, it supports
>>>multiple UDCs, so it supports mount multiple files.
>>>
>>>In addition, I have some updates on the usb-ctrl script to make it
>>>support the USB ECM device, which creates a USB ethernet device
>>>between BMC and the host.
>>>
>>>So my proposal is to add the `usb-ctrl` script into the phosphor-misc
>>>repo so that it gets reviewed and could be used by upstream.
>>>
>>>Any ideas?
>>>
>>>[1]:
>>>https://github.com/Intel-BMC/openbmc/blob/intel/meta-openbmc-mods/meta-common/recipes-core/fw-update/files/usb-ctrl
>>>[2]:
>>>https://github.com/openbmc/openbmc/blob/master/meta-phosphor/aspeed-layer/recipes-connectivity/jsnbd/jsnbd/state_hook
>>>
>>
>>I'm the current maintainer of phosphor-misc and I am looking for help
>>with that. I would be fine with adding this script to that repository.
>>It would be nice, but not required, to hear from the Intel team that
>>they would pull from the new location if we do this...
>
>Yes, we could start using it from there. Just would have to move the
>recipes to point to the right place. CCing Vernon who was the original
>author.
That old thing? :) Seems like a long time since I wrote that. I am fine
with it moving to a new home. That being said, it might be better off as
a c++ binary that is controlled from D-Bus than a shell script. It
started off as a script because we just needed it NOW.
--Vernon
^ permalink raw reply
* + mm-remove-misleading-comment.patch added to -mm tree
From: akpm @ 2020-05-29 18:24 UTC (permalink / raw)
To: akpm, mm-commits, willy
The patch titled
Subject: mm/filemap.c: remove misleading comment
has been added to the -mm tree. Its filename is
mm-remove-misleading-comment.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-remove-misleading-comment.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-remove-misleading-comment.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
Subject: mm/filemap.c: remove misleading comment
We no longer return 0 here and the comment doesn't tell us anything that
we don't already know (SIGBUS is a pretty good indicator that things
didn't work out).
Link: http://lkml.kernel.org/r/20200529123243.20640-1-willy@infradead.org
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/filemap.c | 1 -
1 file changed, 1 deletion(-)
--- a/mm/filemap.c~mm-remove-misleading-comment
+++ a/mm/filemap.c
@@ -2566,7 +2566,6 @@ page_not_uptodate:
if (!error || error == AOP_TRUNCATED_PAGE)
goto retry_find;
- /* Things didn't work out. Return zero to tell the mm layer so. */
shrink_readahead_size_eio(ra);
return VM_FAULT_SIGBUS;
_
Patches currently in -mm which might be from willy@infradead.org are
mm-move-readahead-prototypes-from-mmh.patch
mm-return-void-from-various-readahead-functions.patch
mm-ignore-return-value-of-readpages.patch
mm-move-readahead-nr_pages-check-into-read_pages.patch
mm-add-new-readahead_control-api.patch
mm-use-readahead_control-to-pass-arguments.patch
mm-rename-various-offset-parameters-to-index.patch
mm-rename-readahead-loop-variable-to-i.patch
mm-remove-page_offset-from-readahead-loop.patch
mm-put-readahead-pages-in-cache-earlier.patch
mm-add-readahead-address-space-operation.patch
mm-move-end_index-check-out-of-readahead-loop.patch
mm-add-page_cache_readahead_unbounded.patch
mm-document-why-we-dont-set-pagereadahead.patch
mm-use-memalloc_nofs_save-in-readahead-path.patch
fs-convert-mpage_readpages-to-mpage_readahead.patch
btrfs-convert-from-readpages-to-readahead.patch
erofs-convert-uncompressed-files-from-readpages-to-readahead.patch
erofs-convert-compressed-files-from-readpages-to-readahead.patch
ext4-convert-from-readpages-to-readahead.patch
ext4-pass-the-inode-to-ext4_mpage_readpages.patch
f2fs-convert-from-readpages-to-readahead.patch
f2fs-pass-the-inode-to-f2fs_mpage_readpages.patch
fuse-convert-from-readpages-to-readahead.patch
fuse-convert-from-readpages-to-readahead-fix.patch
iomap-convert-from-readpages-to-readahead.patch
mm-remove-misleading-comment.patch
mm-simplify-calling-a-compound-page-destructor.patch
ipc-convert-ipcs_idr-to-xarray.patch
ipc-convert-ipcs_idr-to-xarray-update.patch
^ permalink raw reply
* Re: [PATCH v4 0/2] soc: ti: add k3 platforms chipid module driver
From: Grygorii Strashko @ 2020-05-29 18:22 UTC (permalink / raw)
To: Santosh Shilimkar, Tero Kristo, Rob Herring, Lokesh Vutla,
devicetree, Arnd Bergmann
Cc: Nishanth Menon, Sekhar Nori, linux-kernel, linux-arm-kernel,
Dave Gerlach
In-Reply-To: <20200512123449.16517-1-grygorii.strashko@ti.com>
Hi Santosh,
On 12/05/2020 15:34, Grygorii Strashko wrote:
> Hi All,
>
> This series introduces TI K3 Multicore SoC platforms chipid module driver
> which provides identification support of the TI K3 SoCs (family, revision)
> and register this information with the SoC bus. It is available under
> /sys/devices/soc0/ for user space, and can be checked, where needed,
> in Kernel using soc_device_match().
> It is also required for introducing support for new revisions of
> K3 AM65x/J721E SoCs.
>
> Example J721E:
> # cat /sys/devices/soc0/{machine,family,revision}
> Texas Instruments K3 J721E SoC
> J721E
> SR1.0
>
> Example AM65x:
> # cat /sys/devices/soc0/{machine,family,revision}
> Texas Instruments AM654 Base Board
> AM65X
> SR1.0
>
> Changes in v4:
> - convert to platform_driver as suggested by Arnd Bergmann <arnd@arndb.de>
>
> Changes in v3:
> - add handling of kasprintf() fail
>
> Changes in v2:
> - pr_debug() replaced with pr_info() to show SoC info on init
> - minor format change
> - split series on driver and platform changes
> - add Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
>
> v3: https://lkml.org/lkml/2020/5/8/357
> v2: https://lkml.org/lkml/2020/5/5/1193
> v1: https://lwn.net/Articles/818577/
>
> Grygorii Strashko (2):
> dt-bindings: soc: ti: add binding for k3 platforms chipid module
> soc: ti: add k3 platforms chipid module driver
>
> .../bindings/soc/ti/k3-socinfo.yaml | 40 +++++
> drivers/soc/ti/Kconfig | 10 ++
> drivers/soc/ti/Makefile | 1 +
> drivers/soc/ti/k3-socinfo.c | 152 ++++++++++++++++++
> 4 files changed, 203 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
> create mode 100644 drivers/soc/ti/k3-socinfo.c
>
Any chances you can pick this up?
--
Best regards,
grygorii
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 0/2] soc: ti: add k3 platforms chipid module driver
From: Grygorii Strashko @ 2020-05-29 18:22 UTC (permalink / raw)
To: Santosh Shilimkar, Tero Kristo, Rob Herring, Lokesh Vutla,
devicetree, Arnd Bergmann
Cc: Dave Gerlach, Sekhar Nori, linux-arm-kernel, linux-kernel,
Nishanth Menon
In-Reply-To: <20200512123449.16517-1-grygorii.strashko@ti.com>
Hi Santosh,
On 12/05/2020 15:34, Grygorii Strashko wrote:
> Hi All,
>
> This series introduces TI K3 Multicore SoC platforms chipid module driver
> which provides identification support of the TI K3 SoCs (family, revision)
> and register this information with the SoC bus. It is available under
> /sys/devices/soc0/ for user space, and can be checked, where needed,
> in Kernel using soc_device_match().
> It is also required for introducing support for new revisions of
> K3 AM65x/J721E SoCs.
>
> Example J721E:
> # cat /sys/devices/soc0/{machine,family,revision}
> Texas Instruments K3 J721E SoC
> J721E
> SR1.0
>
> Example AM65x:
> # cat /sys/devices/soc0/{machine,family,revision}
> Texas Instruments AM654 Base Board
> AM65X
> SR1.0
>
> Changes in v4:
> - convert to platform_driver as suggested by Arnd Bergmann <arnd@arndb.de>
>
> Changes in v3:
> - add handling of kasprintf() fail
>
> Changes in v2:
> - pr_debug() replaced with pr_info() to show SoC info on init
> - minor format change
> - split series on driver and platform changes
> - add Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
>
> v3: https://lkml.org/lkml/2020/5/8/357
> v2: https://lkml.org/lkml/2020/5/5/1193
> v1: https://lwn.net/Articles/818577/
>
> Grygorii Strashko (2):
> dt-bindings: soc: ti: add binding for k3 platforms chipid module
> soc: ti: add k3 platforms chipid module driver
>
> .../bindings/soc/ti/k3-socinfo.yaml | 40 +++++
> drivers/soc/ti/Kconfig | 10 ++
> drivers/soc/ti/Makefile | 1 +
> drivers/soc/ti/k3-socinfo.c | 152 ++++++++++++++++++
> 4 files changed, 203 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/ti/k3-socinfo.yaml
> create mode 100644 drivers/soc/ti/k3-socinfo.c
>
Any chances you can pick this up?
--
Best regards,
grygorii
^ permalink raw reply
* Re: [PATCH v5 02/11] dt-bindings: i2c: Discard i2c-slave flag from the DW I2C example
From: Serge Semin @ 2020-05-29 18:22 UTC (permalink / raw)
To: Rob Herring
Cc: Serge Semin, Jarkko Nikula, Wolfram Sang, Alexey Malahov,
Thomas Bogendoerfer, Andy Shevchenko, Mika Westerberg, linux-mips,
linux-i2c, devicetree, linux-kernel
In-Reply-To: <20200529181338.GA2676189@bogus>
On Fri, May 29, 2020 at 12:13:38PM -0600, Rob Herring wrote:
> On Wed, May 27, 2020 at 06:33:51PM +0300, Serge Semin wrote:
> > Rob,
> > Could you pay attention to this patch? The patchset review procedure is
> > nearly over, while the DT part is only partly reviewed by you.
>
> Pretty sure I commented on this. Not sure what version, you're sending
> new versions too fast. Give people time to review.
Yeah, you did. Sorry for sending the new versions very fast. Normally I prefer
to keep up with comments so to past a particular maintainer review as fast as
possible without long delays. In my experience the longer you wait, the lesser
maintainers remember about your patchset, the harder for one to continue the
next versions review.
Regarding this patch the brand new version on is v6:
[PATCH v6 02/11] dt-bindings: i2c: Convert DW I2C slave to the DW I2C master example
Could you please find it in your email log? I've left a note there for you about
options what we can do with this case.
-Sergey
>
> >
> > Thanks
> > -Sergey
> >
> > On Wed, May 27, 2020 at 06:30:37PM +0300, Serge Semin wrote:
> > > dtc currently doesn't support I2C_OWN_SLAVE_ADDRESS flag set in the
> > > i2c "reg" property. If it is the compiler will print a warning:
> > >
> > > Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64: I2C bus unit address format error, expected "40000064"
> > > Warning (i2c_bus_reg): /example-2/i2c@1120000/eeprom@64:reg: I2C address must be less than 10-bits, got "0x40000064"
> > >
> > > In order to silence dtc up let's discard the flag from the DW I2C DT
> > > binding example for now. Just revert this commit when dtc is fixed.
> > >
> > > Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> > > Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>
> > > Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> > > Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
> > > Cc: linux-mips@vger.kernel.org
> > >
> > > ---
> > >
> > > Changelog v3:
> > > - This is a new patch created as a result of the Rob request to remove
> > > the EEPROM-slave bit setting in the DT binndings example until the dtc
> > > is fixed.
> > > ---
> > > Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > > index 4bd430b2b41d..101d78e8f19d 100644
> > > --- a/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > > +++ b/Documentation/devicetree/bindings/i2c/snps,designware-i2c.yaml
> > > @@ -137,7 +137,7 @@ examples:
> > >
> > > eeprom@64 {
> > > compatible = "linux,slave-24c02";
> > > - reg = <0x40000064>;
> > > + reg = <0x64>;
>
> This is wrong though because "linux,slave-24c02" should have bit 30 set.
> (And either the unit-address was wrong or we can define the unit-address
> does not include the high bits.)
>
> Rob
^ permalink raw reply
* Re: [GIT PULL] sh: remove sh5 support
From: Christoph Hellwig @ 2020-05-29 18:22 UTC (permalink / raw)
To: Rich Felker
Cc: Christoph Hellwig, Arnd Bergmann, linux-sh, ysato, linux-kernel,
viro, Rob Landley, Geert Uytterhoeven, Linus Torvalds
In-Reply-To: <20200529175335.GK1079@brightrain.aerifal.cx>
On Fri, May 29, 2020 at 01:53:38PM -0400, Rich Felker wrote:
> Frustratingly, I _still_ don't have an official tree on kernel.org for
> the purpose of being the canonical place for linux-next to pull from,
> due to policies around pgp keys and nobody following up on signing
> mine. This is all really silly since there are ridiculously many
> independent channels I could cryptographically validate identity
> through with vanishing probability that they're all compromised. For
> the time being I'll reactivate my repo on git.musl-libc.org.
You don't need a kernel.org tree. None of the trees I maintain are
hosted on kernel.org. Just make sure you sign your tags.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.