* Re: general protection fault in wb_workfn (2)
From: Jan Kara @ 2018-05-31 11:42 UTC (permalink / raw)
To: Tetsuo Handa
Cc: Jan Kara, syzbot, syzkaller-bugs, linux-fsdevel, linux-kernel,
viro, axboe, tj, david, linux-block
In-Reply-To: <2dda7a11-3f6b-bdba-a68a-7c0694806cc4@I-love.SAKURA.ne.jp>
On Thu 31-05-18 01:00:08, Tetsuo Handa wrote:
> So, we have no idea what is happening...
> Then, what about starting from temporary debug printk() patch shown below?
>
> >From 4f70f72ad3c9ae6ce1678024ef740aca4958e5b0 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Wed, 30 May 2018 09:57:10 +0900
> Subject: [PATCH] bdi: Add temporary config for debugging wb_workfn() versus
> bdi_unregister() race bug.
>
> syzbot is hitting NULL pointer dereference at wb_workfn() [1]. But due to
> limitations that syzbot cannot find reproducer for this bug (frequency is
> once or twice per a day) nor we can't capture vmcore in the environment
> which syzbot is using, for now we need to rely on printk() debugging.
>
> [1] https://syzkaller.appspot.com/bug?id=e0818ccb7e46190b3f1038b0c794299208ed4206
>
> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Hum a bit ugly solution but if others are fine with this, I can live with
it for a while as well. Or would it be possible for syzkaller to just test
some git tree where this patch is included? Then we would not even have to
have the extra config option...
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index 471d863..b4dd078 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -1934,6 +1934,37 @@ void wb_workfn(struct work_struct *work)
> struct bdi_writeback, dwork);
> long pages_written;
>
> +#ifdef CONFIG_BLK_DEBUG_WB_WORKFN_RACE
> + if (!wb->bdi->dev) {
> + pr_warn("WARNING: %s: device is NULL\n", __func__);
> + pr_warn("wb->state=%lx\n", wb->state);
> + pr_warn("list_empty(&wb->work_list)=%u\n",
> + list_empty(&wb->work_list));
> + if (!wb->bdi)
This is not possible when we dereferences wb->bdi above...
> + pr_warn("wb->bdi == NULL\n");
> + else {
> + pr_warn("list_empty(&wb->bdi->bdi_list)=%u\n",
> + list_empty(&wb->bdi->bdi_list));
> + pr_warn("wb->bdi->wb.state=%lx\n", wb->bdi->wb.state);
> + }
It would be also good to print whether wb == wb->bdi->wb (i.e. it is the
default writeback structure or one for some cgroup) and also
wb->bdi->wb.state.
Honza
> + if (!wb->congested)
> + pr_warn("wb->congested == NULL\n");
> +#ifdef CONFIG_CGROUP_WRITEBACK
> + else if (!wb->congested->__bdi)
> + pr_warn("wb->congested->__bdi == NULL\n");
> + else {
> + pr_warn("(wb->congested->__bdi == wb->bdi)=%u\n",
> + wb->congested->__bdi == wb->bdi);
> + pr_warn("list_empty(&wb->congested->__bdi->bdi_list)=%u\n",
> + list_empty(&wb->congested->__bdi->bdi_list));
> + pr_warn("wb->congested->__bdi->wb.state=%lx\n",
> + wb->congested->__bdi->wb.state);
> + }
> +#endif
> + /* Will halt shortly due to NULL pointer dereference... */
> + }
> +#endif
> +
> set_worker_desc("flush-%s", dev_name(wb->bdi->dev));
> current->flags |= PF_SWAPWRITE;
>
> --
> 1.8.3.1
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH ghak82 v2] audit: Fix extended comparison of GID/EGID
From: Richard Guy Briggs @ 2018-05-31 11:42 UTC (permalink / raw)
To: Ondrej Mosnacek; +Cc: linux-audit
In-Reply-To: <20180531071954.10998-1-omosnace@redhat.com>
On 2018-05-31 09:19, Ondrej Mosnacek wrote:
> The audit_filter_rules() function in auditsc.c used the in_[e]group_p()
> functions to check GID/EGID match, but these functions use the current
> task's credentials, while the comparison should use the credentials of
> the task given to audit_filter_rules() as a parameter (tsk).
>
> Note that we can use group_search(cred->group_info, ...) as a
> replacement for both in_group_p and in_egroup_p as these functions only
> compare the parameter to cred->fsgid/egid and then call group_search.
>
> In fact, the usage of in_group_p was even more incorrect: it compares to
> cred->fsgid (which is usually equal to cred->egid) and not cred->gid.
>
> GitHub issue:
> https://github.com/linux-audit/audit-kernel/issues/82
>
> Fixes: 37eebe39c973 ("audit: improve GID/EGID comparation logic")
> Signed-off-by: Ondrej Mosnacek <omosnace@redhat.com>
Given what you've turned up while investigating this, I'm comfortable
with the solution you've presented.
Reviewed-by: Richard Guy Briggs <rgb@redhat.com>
> ---
> kernel/auditsc.c | 26 ++++++++++++--------------
> 1 file changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index ceb1c4596c51..3a324ca2fd20 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -492,23 +492,21 @@ static int audit_filter_rules(struct task_struct *tsk,
> break;
> case AUDIT_GID:
> result = audit_gid_comparator(cred->gid, f->op, f->gid);
> - if (f->op == Audit_equal) {
> - if (!result)
> - result = in_group_p(f->gid);
> - } else if (f->op == Audit_not_equal) {
> - if (result)
> - result = !in_group_p(f->gid);
> - }
> + if (f->op == Audit_equal)
> + result = result ||
> + groups_search(cred->group_info, f->gid);
> + else if (f->op == Audit_not_equal)
> + result = result &&
> + !groups_search(cred->group_info, f->gid);
> break;
> case AUDIT_EGID:
> result = audit_gid_comparator(cred->egid, f->op, f->gid);
> - if (f->op == Audit_equal) {
> - if (!result)
> - result = in_egroup_p(f->gid);
> - } else if (f->op == Audit_not_equal) {
> - if (result)
> - result = !in_egroup_p(f->gid);
> - }
> + if (f->op == Audit_equal)
> + result = result ||
> + groups_search(cred->group_info, f->gid);
> + else if (f->op == Audit_not_equal)
> + result = result &&
> + !groups_search(cred->group_info, f->gid);
> break;
> case AUDIT_SGID:
> result = audit_gid_comparator(cred->sgid, f->op, f->gid);
> --
> 2.17.0
>
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH v2 3/6] arm64: KVM: Avoid marking pages as XN in Stage-2 if CTR_EL0.DIC is set
From: Mark Rutland @ 2018-05-31 11:52 UTC (permalink / raw)
To: Marc Zyngier; +Cc: linux-arm-kernel, Catalin Marinas, kvmarm, kvm
In-Reply-To: <20180530124706.25284-4-marc.zyngier@arm.com>
On Wed, May 30, 2018 at 01:47:03PM +0100, Marc Zyngier wrote:
> On systems where CTR_EL0.DIC is set, we don't need to perform
> icache invalidation to guarantee that we'll fetch the right
> instruction stream.
>
> This also means that taking a permission fault to invalidate the
> icache is an unnecessary overhead.
>
> On such systems, we can safely leave the page as being executable.
>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
> arch/arm64/include/asm/pgtable-prot.h | 14 ++++++++++++--
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/include/asm/pgtable-prot.h b/arch/arm64/include/asm/pgtable-prot.h
> index c66c3047400e..78b942c1bea4 100644
> --- a/arch/arm64/include/asm/pgtable-prot.h
> +++ b/arch/arm64/include/asm/pgtable-prot.h
> @@ -77,8 +77,18 @@
> __val; \
> })
>
> -#define PAGE_S2 __pgprot(_PROT_DEFAULT | PAGE_S2_MEMATTR(NORMAL) | PTE_S2_RDONLY | PTE_S2_XN)
> -#define PAGE_S2_DEVICE __pgprot(_PROT_DEFAULT | PAGE_S2_MEMATTR(DEVICE_nGnRE) | PTE_S2_RDONLY | PTE_S2_XN)
> +#define PAGE_S2_XN \
> + ({ \
> + u64 __val; \
> + if (cpus_have_const_cap(ARM64_HAS_CACHE_DIC)) \
> + __val = 0; \
> + else \
> + __val = PTE_S2_XN; \
> + __val; \
> + })
> +
> +#define PAGE_S2 __pgprot(_PROT_DEFAULT | PAGE_S2_MEMATTR(NORMAL) | PTE_S2_RDONLY | PAGE_S2_XN)
> +#define PAGE_S2_DEVICE __pgprot(_PROT_DEFAULT | PAGE_S2_MEMATTR(DEVICE_nGnRE) | PTE_S2_RDONLY | PAGE_S2_XN)
>
> #define PAGE_NONE __pgprot(((_PAGE_DEFAULT) & ~PTE_VALID) | PTE_PROT_NONE | PTE_RDONLY | PTE_NG | PTE_PXN | PTE_UXN)
> #define PAGE_SHARED __pgprot(_PAGE_DEFAULT | PTE_USER | PTE_NG | PTE_PXN | PTE_UXN | PTE_WRITE)
> --
> 2.17.1
>
^ permalink raw reply
* Re: [DPU PATCH 10/11] drm/msm/dpu: correct dpu_io_util.h include path
From: ryadav-sgV2jX0FEOL9JmXXK+q4OQ @ 2018-05-31 11:41 UTC (permalink / raw)
To: Rajesh Yadav
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
robdclark-Re5JQEeQqe8AvxtiuMwx3w, seanpaul-F7+t8E8rja9g9hUCZPvPmw,
hoegsberg-F7+t8E8rja9g9hUCZPvPmw,
freedreno-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20180530163005.GC5028-9PYrDHPZ2Orvke4nUoYGnHL1okKdlPRT@public.gmane.org>
On 2018-05-30 22:00, Jordan Crouse wrote:
> On Wed, May 30, 2018 at 08:19:47PM +0530, Rajesh Yadav wrote:
>> dpu_io_util.h is moved from standard include path
>> to driver folder, correct the include path in code.
>>
>> Signed-off-by: Rajesh Yadav <ryadav@codeaurora.org>
>
> If the previous patch doesn't compile without this fix you should
> squash them.
Hi Jordan,
Yeah you are right, will squash it in v2.
We are trying to keep msm core and dpu changes in separate patches for
better squashing when they are pulled by Sean in dpu-staging tree but
for this instance can't break compilation so yeah I'll squash it with
previous one.
Thanks,
Rajesh
>
>> ---
>> drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c | 1 -
>> drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h | 2 +-
>> 2 files changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
>> index 24c3274..f997bd9 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.c
>> @@ -20,7 +20,6 @@
>> #include <linux/slab.h>
>> #include <linux/mutex.h>
>> #include <linux/of_platform.h>
>> -#include <linux/dpu_io_util.h>
>>
>> #include "dpu_power_handle.h"
>> #include "dpu_trace.h"
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
>> index 9a6d4b9..193f468 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_power_handle.h
>> @@ -21,7 +21,7 @@
>> #define DPU_POWER_HANDLE_ENABLE_BUS_IB_QUOTA 1600000000
>> #define DPU_POWER_HANDLE_DISABLE_BUS_IB_QUOTA 0
>>
>> -#include <linux/dpu_io_util.h>
>> +#include "dpu_io_util.h"
>>
>> /* event will be triggered before power handler disable */
>> #define DPU_POWER_EVENT_PRE_DISABLE 0x1
_______________________________________________
Freedreno mailing list
Freedreno@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
^ permalink raw reply
* ftdi_sio: add Id for Physik Instrumente E-870
From: Greg Kroah-Hartman @ 2018-05-31 11:41 UTC (permalink / raw)
To: Johan Hovold; +Cc: Teichmann, Martin, linux-usb
On Thu, May 31, 2018 at 01:24:52PM +0200, Johan Hovold wrote:
> On Thu, May 31, 2018 at 12:39:41PM +0200, Greg Kroah-Hartman wrote:
> > On Thu, Mar 29, 2018 at 08:39:37AM +0200, Teichmann, Martin wrote:
> > > This adds support for the Physik Instrumente E-870 PIShift Drive
> > > Electronics, a Piezo motor driver.
> > >
> > > Signed-off-by: Martin Teichmann <martin.teichmann@xfel.eu>
> > > ---
> > > drivers/usb/serial/ftdi_sio.c | 1 +
> > > drivers/usb/serial/ftdi_sio_ids.h | 1 +
> > > 2 files changed, 2 insertions(+)
> >
> > Johan, want me to pick this one up? I think you missed it in your last
> > pull request.
>
> No, this one was actually already applied and later reverted when it
> turned out it was not really an ftdi device at all:
>
> 5267c5e09c25 ("Revert "USB: serial: ftdi_sio: add Id for Physik
> Instrumente E-870"")
Ah, oops, missed that. dropping this from my queue now, thanks.
greg k-h
---
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH -next] nvmet: fix error return code in nvmet_file_ns_enable()
From: Wei Yongjun @ 2018-05-31 11:41 UTC (permalink / raw)
Fix to return error code -ENOMEM from the memory alloc fail error
handling case instead of 0, as done elsewhere in this function.
Fixes: d5eff33ee6f8 ("nvmet: add simple file backed ns support")
Signed-off-by: Wei Yongjun <weiyongjun1 at huawei.com>
---
drivers/nvme/target/io-cmd-file.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/target/io-cmd-file.c b/drivers/nvme/target/io-cmd-file.c
index ca1ccf8..e9d6ce4 100644
--- a/drivers/nvme/target/io-cmd-file.c
+++ b/drivers/nvme/target/io-cmd-file.c
@@ -49,14 +49,18 @@ int nvmet_file_ns_enable(struct nvmet_ns *ns)
ns->bvec_cache = kmem_cache_create("nvmet-bvec",
NVMET_MAX_MPOOL_BVEC * sizeof(struct bio_vec),
0, SLAB_HWCACHE_ALIGN, NULL);
- if (!ns->bvec_cache)
+ if (!ns->bvec_cache) {
+ ret = -ENOMEM;
goto err;
+ }
ns->bvec_pool = mempool_create(NVMET_MIN_MPOOL_OBJ, mempool_alloc_slab,
mempool_free_slab, ns->bvec_cache);
- if (!ns->bvec_pool)
+ if (!ns->bvec_pool) {
+ ret = -ENOMEM;
goto err;
+ }
return ret;
err:
^ permalink raw reply related
* [PATCH -next] nvmet: fix error return code in nvmet_file_ns_enable()
From: Wei Yongjun @ 2018-05-31 11:41 UTC (permalink / raw)
To: kernel-janitors
In-Reply-To: <2e278301-9e7d-2c0e-d968-e77256ce82c3@grimberg.me>
Fix to return error code -ENOMEM from the memory alloc fail error
handling case instead of 0, as done elsewhere in this function.
Fixes: d5eff33ee6f8 ("nvmet: add simple file backed ns support")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/nvme/target/io-cmd-file.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/nvme/target/io-cmd-file.c b/drivers/nvme/target/io-cmd-file.c
index ca1ccf8..e9d6ce4 100644
--- a/drivers/nvme/target/io-cmd-file.c
+++ b/drivers/nvme/target/io-cmd-file.c
@@ -49,14 +49,18 @@ int nvmet_file_ns_enable(struct nvmet_ns *ns)
ns->bvec_cache = kmem_cache_create("nvmet-bvec",
NVMET_MAX_MPOOL_BVEC * sizeof(struct bio_vec),
0, SLAB_HWCACHE_ALIGN, NULL);
- if (!ns->bvec_cache)
+ if (!ns->bvec_cache) {
+ ret = -ENOMEM;
goto err;
+ }
ns->bvec_pool = mempool_create(NVMET_MIN_MPOOL_OBJ, mempool_alloc_slab,
mempool_free_slab, ns->bvec_cache);
- if (!ns->bvec_pool)
+ if (!ns->bvec_pool) {
+ ret = -ENOMEM;
goto err;
+ }
return ret;
err:
^ permalink raw reply related
* Re: [PATCH v2 2/6] arm64: KVM: Handle Set/Way CMOs as NOPs if FWB is present
From: Mark Rutland @ 2018-05-31 11:51 UTC (permalink / raw)
To: Marc Zyngier; +Cc: linux-arm-kernel, Catalin Marinas, kvmarm, kvm
In-Reply-To: <20180530124706.25284-3-marc.zyngier@arm.com>
On Wed, May 30, 2018 at 01:47:02PM +0100, Marc Zyngier wrote:
> Set/Way handling is one of the ugliest corners of KVM. We shouldn't
> have to handle that, but better safe than sorry.
>
> Thankfully, FWB fixes this for us by not requiering any maintenance
> whatsoever, which means we don't have to emulate S/W CMOs, and don't
> have to track VM ops either.
>
> We still have to trap S/W though, if only to prevent the guest from
> doing something bad.
S/W ops *also* do I-cache maintenance, so we'd still need to emulate
that. Though it looks like we're missing that today...
>
> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm64/kvm/sys_regs.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 6e3b969391fd..9a740f159245 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -195,7 +195,13 @@ static bool access_dcsw(struct kvm_vcpu *vcpu,
> if (!p->is_write)
> return read_from_write_only(vcpu, p, r);
>
> - kvm_set_way_flush(vcpu);
> + /*
> + * Only track S/W ops if we don't have FWB. It still indicates
> + * that the guest is a bit broken...
> + */
> + if (!cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
> + kvm_set_way_flush(vcpu);
> +
Assuming we implement I-cache maintenance, we can have something like:
if (!cpus_have_const_cap(ARM64_HAS_STAGE2_FWB))
kvm_set_way_flush_dcache(vcpu);
kvm_set_way_flush_icache(vcpu);
Thanks,
Mark.
> return true;
> }
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
From: Simon Horman @ 2018-05-31 11:40 UTC (permalink / raw)
To: Marek Vasut
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Geert Uytterhoeven, Wolfram Sang, Richard Weinberger,
Linux-Renesas, Boris Brezillon, Geert Uytterhoeven,
Laurent Pinchart, Linux ARM, Marek Vasut
In-Reply-To: <d78bb8a8-a351-409c-54d2-33ee02fd8afe@gmail.com>
On Wed, May 30, 2018 at 12:13:31PM +0200, Marek Vasut wrote:
> On 05/28/2018 11:36 AM, Simon Horman wrote:
> > On Mon, May 28, 2018 at 10:54:57AM +0200, Geert Uytterhoeven wrote:
> >> Hi Simon,
> >>
> >> On Mon, May 28, 2018 at 10:41 AM, Simon Horman <horms@verge.net.au> wrote:
> >>> On Thu, May 24, 2018 at 04:52:59PM +0200, Marek Vasut wrote:
> >>>> On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:
> >>>>> On Wed, May 23, 2018 at 12:01 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
> >>>>>>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>>>> Drop the MTD partitioning from DT, since it does not describe HW
> >>>>>>>> and to give way to a more flexible kernel command line partition
> >>>>>>>> passing.
> >>>>>>>>
> >>>>>>>> To retain the original partitioning, assure you have enabled
> >>>>>>>> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> >>>>>>>> following to your kernel command line:
> >>>>>>>>
> >>>>>>>> mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
> >>>>>>>
> >>>>>>> I think the "@0" can be dropped, as it's optional?
> >>>>>>> 4m?
> >>>>>>
> >>>>>> My take on this is that the loader is actually at offset 0x0 of the MTD
> >>>>>> device and we explicitly state that in the mtdparts to anchor the first
> >>>>>> partition within the MTD device and all the other partitions are at
> >>>>>> offset +(sum of the sizes of all partitions listed before the current
> >>>>>> one) relative to that first partition.
> >>>>>
> >>>>> Where is this explicitly states for the first partition?
> >>>>>
> >>>>>> Removing the @0 feels fragile at best and it seems to depend on the
> >>>>>> current behavior of the code.
> >>>>>
> >>>>> Better, it also depends on the documented behavior:
> >>>>>
> >>>>> Documentation/admin-guide/kernel-parameters.txt refers to
> >>>>> drivers/mtd/cmdlinepart.c, which states:
> >>>>>
> >>>>> * <offset> := standard linux memsize
> >>>>> * if omitted the part will immediately follow the previous part
> >>>>> * or 0 if the first part
> >>>>>
> >>>>> None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
> >>>>> help text, or in a defconfig bundled with the kernel, use @0 for the first
> >>>>> partition.
> >>>>
> >>>> I think this is exceptionally fragile and dangerous to depend on this,
> >>>> but so be it.
> >>>
> >>> Could you respin with this change?
> >>>
> >>> I would also like to ask for another change, in light of recent
> >>> feedback from Olof Johansson ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
> >>> Updates for v4.18").
> >>>
> >>> Please consolidate the dts patches into a single patch?
> >>
> >> I think it's better to keep them split, as each commit description mentions
> >> what needs to be passed on the kernel command line for the corresponding
> >> board.
> >>
> >> Combining it in a single patch makes it much harder to extract this information.
> >> Unless you're fine with a list:
> >>
> >> koelsch: ...
> >> wheat: mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
> >
> > Lets try a list.
>
> Reposted with a list, twice :/
Thanks, got it :)
^ permalink raw reply
* [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
From: Simon Horman @ 2018-05-31 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d78bb8a8-a351-409c-54d2-33ee02fd8afe@gmail.com>
On Wed, May 30, 2018 at 12:13:31PM +0200, Marek Vasut wrote:
> On 05/28/2018 11:36 AM, Simon Horman wrote:
> > On Mon, May 28, 2018 at 10:54:57AM +0200, Geert Uytterhoeven wrote:
> >> Hi Simon,
> >>
> >> On Mon, May 28, 2018 at 10:41 AM, Simon Horman <horms@verge.net.au> wrote:
> >>> On Thu, May 24, 2018 at 04:52:59PM +0200, Marek Vasut wrote:
> >>>> On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:
> >>>>> On Wed, May 23, 2018 at 12:01 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
> >>>>>>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>>>> Drop the MTD partitioning from DT, since it does not describe HW
> >>>>>>>> and to give way to a more flexible kernel command line partition
> >>>>>>>> passing.
> >>>>>>>>
> >>>>>>>> To retain the original partitioning, assure you have enabled
> >>>>>>>> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> >>>>>>>> following to your kernel command line:
> >>>>>>>>
> >>>>>>>> mtdparts=spi0.0:256k at 0(loader),4096k(user),-(flash)
> >>>>>>>
> >>>>>>> I think the "@0" can be dropped, as it's optional?
> >>>>>>> 4m?
> >>>>>>
> >>>>>> My take on this is that the loader is actually at offset 0x0 of the MTD
> >>>>>> device and we explicitly state that in the mtdparts to anchor the first
> >>>>>> partition within the MTD device and all the other partitions are at
> >>>>>> offset +(sum of the sizes of all partitions listed before the current
> >>>>>> one) relative to that first partition.
> >>>>>
> >>>>> Where is this explicitly states for the first partition?
> >>>>>
> >>>>>> Removing the @0 feels fragile at best and it seems to depend on the
> >>>>>> current behavior of the code.
> >>>>>
> >>>>> Better, it also depends on the documented behavior:
> >>>>>
> >>>>> Documentation/admin-guide/kernel-parameters.txt refers to
> >>>>> drivers/mtd/cmdlinepart.c, which states:
> >>>>>
> >>>>> * <offset> := standard linux memsize
> >>>>> * if omitted the part will immediately follow the previous part
> >>>>> * or 0 if the first part
> >>>>>
> >>>>> None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
> >>>>> help text, or in a defconfig bundled with the kernel, use @0 for the first
> >>>>> partition.
> >>>>
> >>>> I think this is exceptionally fragile and dangerous to depend on this,
> >>>> but so be it.
> >>>
> >>> Could you respin with this change?
> >>>
> >>> I would also like to ask for another change, in light of recent
> >>> feedback from Olof Johansson ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
> >>> Updates for v4.18").
> >>>
> >>> Please consolidate the dts patches into a single patch?
> >>
> >> I think it's better to keep them split, as each commit description mentions
> >> what needs to be passed on the kernel command line for the corresponding
> >> board.
> >>
> >> Combining it in a single patch makes it much harder to extract this information.
> >> Unless you're fine with a list:
> >>
> >> koelsch: ...
> >> wheat: mtdparts=spi0.0:256k at 0(loader),4096k(user),-(flash)
> >
> > Lets try a list.
>
> Reposted with a list, twice :/
Thanks, got it :)
^ permalink raw reply
* Re: [PATCH 6/9] ARM: dts: wheat: Drop MTD partitioning from DT
From: Simon Horman @ 2018-05-31 11:40 UTC (permalink / raw)
To: Marek Vasut
Cc: Geert Uytterhoeven, Linux ARM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Marek Vasut, Geert Uytterhoeven, Laurent Pinchart, Wolfram Sang,
Linux-Renesas, Richard Weinberger, Boris Brezillon
In-Reply-To: <d78bb8a8-a351-409c-54d2-33ee02fd8afe@gmail.com>
On Wed, May 30, 2018 at 12:13:31PM +0200, Marek Vasut wrote:
> On 05/28/2018 11:36 AM, Simon Horman wrote:
> > On Mon, May 28, 2018 at 10:54:57AM +0200, Geert Uytterhoeven wrote:
> >> Hi Simon,
> >>
> >> On Mon, May 28, 2018 at 10:41 AM, Simon Horman <horms@verge.net.au> wrote:
> >>> On Thu, May 24, 2018 at 04:52:59PM +0200, Marek Vasut wrote:
> >>>> On 05/23/2018 08:25 AM, Geert Uytterhoeven wrote:
> >>>>> On Wed, May 23, 2018 at 12:01 AM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>> On 05/22/2018 04:43 PM, Geert Uytterhoeven wrote:
> >>>>>>> On Tue, May 22, 2018 at 2:02 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> >>>>>>>> Drop the MTD partitioning from DT, since it does not describe HW
> >>>>>>>> and to give way to a more flexible kernel command line partition
> >>>>>>>> passing.
> >>>>>>>>
> >>>>>>>> To retain the original partitioning, assure you have enabled
> >>>>>>>> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> >>>>>>>> following to your kernel command line:
> >>>>>>>>
> >>>>>>>> mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
> >>>>>>>
> >>>>>>> I think the "@0" can be dropped, as it's optional?
> >>>>>>> 4m?
> >>>>>>
> >>>>>> My take on this is that the loader is actually at offset 0x0 of the MTD
> >>>>>> device and we explicitly state that in the mtdparts to anchor the first
> >>>>>> partition within the MTD device and all the other partitions are at
> >>>>>> offset +(sum of the sizes of all partitions listed before the current
> >>>>>> one) relative to that first partition.
> >>>>>
> >>>>> Where is this explicitly states for the first partition?
> >>>>>
> >>>>>> Removing the @0 feels fragile at best and it seems to depend on the
> >>>>>> current behavior of the code.
> >>>>>
> >>>>> Better, it also depends on the documented behavior:
> >>>>>
> >>>>> Documentation/admin-guide/kernel-parameters.txt refers to
> >>>>> drivers/mtd/cmdlinepart.c, which states:
> >>>>>
> >>>>> * <offset> := standard linux memsize
> >>>>> * if omitted the part will immediately follow the previous part
> >>>>> * or 0 if the first part
> >>>>>
> >>>>> None of the examples listed there or under the MTD_CMDLINE_PARTS Kconfig
> >>>>> help text, or in a defconfig bundled with the kernel, use @0 for the first
> >>>>> partition.
> >>>>
> >>>> I think this is exceptionally fragile and dangerous to depend on this,
> >>>> but so be it.
> >>>
> >>> Could you respin with this change?
> >>>
> >>> I would also like to ask for another change, in light of recent
> >>> feedback from Olof Johansson ("Re: [GIT PULL] Renesas ARM64 Based SoC DT
> >>> Updates for v4.18").
> >>>
> >>> Please consolidate the dts patches into a single patch?
> >>
> >> I think it's better to keep them split, as each commit description mentions
> >> what needs to be passed on the kernel command line for the corresponding
> >> board.
> >>
> >> Combining it in a single patch makes it much harder to extract this information.
> >> Unless you're fine with a list:
> >>
> >> koelsch: ...
> >> wheat: mtdparts=spi0.0:256k@0(loader),4096k(user),-(flash)
> >
> > Lets try a list.
>
> Reposted with a list, twice :/
Thanks, got it :)
^ permalink raw reply
* [PATCH v3 4/5] PM / Domains: Add support for multi PM domains per device to genpd
From: Lucas Stach @ 2018-05-31 11:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180531105959.14843-5-ulf.hansson@linaro.org>
Hi Ulf,
Am Donnerstag, den 31.05.2018, 12:59 +0200 schrieb Ulf Hansson:
> To support devices being partitioned across multiple PM domains, let's
> begin with extending genpd to cope with these kind of configurations.
>
> Therefore, add a new exported function genpd_dev_pm_attach_by_id(), which
> is similar to the existing genpd_dev_pm_attach(), but with the difference
> that it allows its callers to provide an index to the PM domain that it
> wants to attach.
>
> Note that, genpd_dev_pm_attach_by_id() shall only be called by the driver
> core / PM core, similar to how the existing dev_pm_domain_attach() makes
> use of genpd_dev_pm_attach(). However, this is implemented by following
> changes on top.
by_id() APIs are not really intuitive to use for driver writers. Other
subsystems have solved this by providing a "-names" property to give
the phandles a bit more meaning and then providing a by_name API. I
would really appreciate if PM domains could move in the same direction.
Regards,
Lucas
> Because, only one PM domain can be attached per device, genpd needs to
> create a virtual device that it can attach/detach instead. More precisely,
> let the new function genpd_dev_pm_attach_by_id() register a virtual struct
> device via calling device_register(). Then let it attach this device to the
> corresponding PM domain, rather than the one that is provided by the
> caller. The actual attaching is done via re-using the existing genpd OF
> functions.
>
> At successful attachment, genpd_dev_pm_attach_by_id() returns the created
> virtual device, which allows the caller to operate on it to deal with power
> management. Following changes on top, provides more details in this
> regards.
>
> To deal with detaching of a PM domain for the multiple PM domains case,
> let's also extend the existing genpd_dev_pm_detach() function, to cover the
> cleanup of the created virtual device, via make it call device_unregister()
> on it. In this way, there is no need to introduce a new function to deal
> with detach for the multiple PM domain case, but instead the existing one
> is re-used.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Acked-by: Jon Hunter <jonathanh@nvidia.com>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/base/power/domain.c | 80 +++++++++++++++++++++++++++++++++++++
> include/linux/pm_domain.h | 8 ++++
> 2 files changed, 88 insertions(+)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index b1fcbf917974..4925af5c4cf0 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2171,6 +2171,15 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
> }
> EXPORT_SYMBOL_GPL(of_genpd_remove_last);
>
> +static void genpd_release_dev(struct device *dev)
> +{
> + kfree(dev);
> +}
> +
> +static struct bus_type genpd_bus_type = {
> + .name = "genpd",
> +};
> +
> /**
> * genpd_dev_pm_detach - Detach a device from its PM domain.
> * @dev: Device to detach.
> @@ -2208,6 +2217,10 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
>
> /* Check if PM domain can be powered off after removing this device. */
> genpd_queue_power_off_work(pd);
> +
> + /* Unregister the device if it was created by genpd. */
> + if (dev->bus == &genpd_bus_type)
> + device_unregister(dev);
> }
>
> static void genpd_dev_pm_sync(struct device *dev)
> @@ -2298,6 +2311,67 @@ int genpd_dev_pm_attach(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
>
> +/**
> + * genpd_dev_pm_attach_by_id - Associate a device with one of its PM domains.
> + * @dev: The device used to lookup the PM domain.
> + * @index: The index of the PM domain.
> + *
> + * Parse device's OF node to find a PM domain specifier at the provided @index.
> + * If such is found, creates a virtual device and attaches it to the retrieved
> + * pm_domain ops. To deal with detaching of the virtual device, the ->detach()
> + * callback in the struct dev_pm_domain are assigned to genpd_dev_pm_detach().
> + *
> + * Returns the created virtual device if successfully attached PM domain, NULL
> + * when the device don't need a PM domain, else an ERR_PTR() in case of
> + * failures. If a power-domain exists for the device, but cannot be found or
> + * turned on, then ERR_PTR(-EPROBE_DEFER) is returned to ensure that the device
> + * is not probed and to re-try again later.
> + */
> +struct device *genpd_dev_pm_attach_by_id(struct device *dev,
> + unsigned int index)
> +{
> + struct device *genpd_dev;
> + int num_domains;
> + int ret;
> +
> + if (!dev->of_node)
> + return NULL;
> +
> + /* Deal only with devices using multiple PM domains. */
> + num_domains = of_count_phandle_with_args(dev->of_node, "power-domains",
> + "#power-domain-cells");
> + if (num_domains < 2 || index >= num_domains)
> + return NULL;
> +
> + /* Allocate and register device on the genpd bus. */
> + genpd_dev = kzalloc(sizeof(*genpd_dev), GFP_KERNEL);
> + if (!genpd_dev)
> + return ERR_PTR(-ENOMEM);
> +
> + dev_set_name(genpd_dev, "genpd:%u:%s", index, dev_name(dev));
> + genpd_dev->bus = &genpd_bus_type;
> + genpd_dev->release = genpd_release_dev;
> +
> + ret = device_register(genpd_dev);
> + if (ret) {
> + kfree(genpd_dev);
> + return ERR_PTR(ret);
> + }
> +
> + /* Try to attach the device to the PM domain at the specified index. */
> + ret = __genpd_dev_pm_attach(genpd_dev, dev->of_node, index);
> + if (ret < 1) {
> + device_unregister(genpd_dev);
> + return ret ? ERR_PTR(ret) : NULL;
> + }
> +
> + pm_runtime_set_active(genpd_dev);
> + pm_runtime_enable(genpd_dev);
> +
> + return genpd_dev;
> +}
> +EXPORT_SYMBOL_GPL(genpd_dev_pm_attach_by_id);
> +
> static const struct of_device_id idle_state_match[] = {
> { .compatible = "domain-idle-state", },
> { }
> @@ -2457,6 +2531,12 @@ unsigned int of_genpd_opp_to_performance_state(struct device *dev,
> }
> EXPORT_SYMBOL_GPL(of_genpd_opp_to_performance_state);
>
> +static int __init genpd_bus_init(void)
> +{
> + return bus_register(&genpd_bus_type);
> +}
> +core_initcall(genpd_bus_init);
> +
> #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
>
>
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 42e0d649e653..82458e8e2e01 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -237,6 +237,8 @@ unsigned int of_genpd_opp_to_performance_state(struct device *dev,
> struct device_node *opp_node);
>
> int genpd_dev_pm_attach(struct device *dev);
> +struct device *genpd_dev_pm_attach_by_id(struct device *dev,
> + unsigned int index);
> #else /* !CONFIG_PM_GENERIC_DOMAINS_OF */
> static inline int of_genpd_add_provider_simple(struct device_node *np,
> struct generic_pm_domain *genpd)
> @@ -282,6 +284,12 @@ static inline int genpd_dev_pm_attach(struct device *dev)
> return 0;
> }
>
> +static inline struct device *genpd_dev_pm_attach_by_id(struct device *dev,
> + unsigned int index)
> +{
> + return NULL;
> +}
> +
> static inline
> struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
> {
^ permalink raw reply
* Re: [PATCH v3 4/5] PM / Domains: Add support for multi PM domains per device to genpd
From: Lucas Stach @ 2018-05-31 11:40 UTC (permalink / raw)
To: Ulf Hansson, Rafael J . Wysocki, linux-pm
Cc: Greg Kroah-Hartman, Jon Hunter, Geert Uytterhoeven, Todor Tomov,
Rajendra Nayak, Viresh Kumar, Vincent Guittot, Kevin Hilman,
linux-kernel, linux-arm-kernel, linux-tegra
In-Reply-To: <20180531105959.14843-5-ulf.hansson@linaro.org>
Hi Ulf,
Am Donnerstag, den 31.05.2018, 12:59 +0200 schrieb Ulf Hansson:
> To support devices being partitioned across multiple PM domains, let's
> begin with extending genpd to cope with these kind of configurations.
>
> Therefore, add a new exported function genpd_dev_pm_attach_by_id(), which
> is similar to the existing genpd_dev_pm_attach(), but with the difference
> that it allows its callers to provide an index to the PM domain that it
> wants to attach.
>
> Note that, genpd_dev_pm_attach_by_id() shall only be called by the driver
> core / PM core, similar to how the existing dev_pm_domain_attach() makes
> use of genpd_dev_pm_attach(). However, this is implemented by following
> changes on top.
by_id() APIs are not really intuitive to use for driver writers. Other
subsystems have solved this by providing a "-names" property to give
the phandles a bit more meaning and then providing a by_name API. I
would really appreciate if PM domains could move in the same direction.
Regards,
Lucas
> Because, only one PM domain can be attached per device, genpd needs to
> create a virtual device that it can attach/detach instead. More precisely,
> let the new function genpd_dev_pm_attach_by_id() register a virtual struct
> device via calling device_register(). Then let it attach this device to the
> corresponding PM domain, rather than the one that is provided by the
> caller. The actual attaching is done via re-using the existing genpd OF
> functions.
>
> At successful attachment, genpd_dev_pm_attach_by_id() returns the created
> virtual device, which allows the caller to operate on it to deal with power
> management. Following changes on top, provides more details in this
> regards.
>
> To deal with detaching of a PM domain for the multiple PM domains case,
> let's also extend the existing genpd_dev_pm_detach() function, to cover the
> cleanup of the created virtual device, via make it call device_unregister()
> on it. In this way, there is no need to introduce a new function to deal
> with detach for the multiple PM domain case, but instead the existing one
> is re-used.
>
> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
> Acked-by: Jon Hunter <jonathanh@nvidia.com>
> Tested-by: Jon Hunter <jonathanh@nvidia.com>
> Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> drivers/base/power/domain.c | 80 +++++++++++++++++++++++++++++++++++++
> include/linux/pm_domain.h | 8 ++++
> 2 files changed, 88 insertions(+)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index b1fcbf917974..4925af5c4cf0 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -2171,6 +2171,15 @@ struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
> }
> EXPORT_SYMBOL_GPL(of_genpd_remove_last);
>
> +static void genpd_release_dev(struct device *dev)
> +{
> + kfree(dev);
> +}
> +
> +static struct bus_type genpd_bus_type = {
> + .name = "genpd",
> +};
> +
> /**
> * genpd_dev_pm_detach - Detach a device from its PM domain.
> * @dev: Device to detach.
> @@ -2208,6 +2217,10 @@ static void genpd_dev_pm_detach(struct device *dev, bool power_off)
>
> /* Check if PM domain can be powered off after removing this device. */
> genpd_queue_power_off_work(pd);
> +
> + /* Unregister the device if it was created by genpd. */
> + if (dev->bus == &genpd_bus_type)
> + device_unregister(dev);
> }
>
> static void genpd_dev_pm_sync(struct device *dev)
> @@ -2298,6 +2311,67 @@ int genpd_dev_pm_attach(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(genpd_dev_pm_attach);
>
> +/**
> + * genpd_dev_pm_attach_by_id - Associate a device with one of its PM domains.
> + * @dev: The device used to lookup the PM domain.
> + * @index: The index of the PM domain.
> + *
> + * Parse device's OF node to find a PM domain specifier at the provided @index.
> + * If such is found, creates a virtual device and attaches it to the retrieved
> + * pm_domain ops. To deal with detaching of the virtual device, the ->detach()
> + * callback in the struct dev_pm_domain are assigned to genpd_dev_pm_detach().
> + *
> + * Returns the created virtual device if successfully attached PM domain, NULL
> + * when the device don't need a PM domain, else an ERR_PTR() in case of
> + * failures. If a power-domain exists for the device, but cannot be found or
> + * turned on, then ERR_PTR(-EPROBE_DEFER) is returned to ensure that the device
> + * is not probed and to re-try again later.
> + */
> +struct device *genpd_dev_pm_attach_by_id(struct device *dev,
> + unsigned int index)
> +{
> + struct device *genpd_dev;
> + int num_domains;
> + int ret;
> +
> + if (!dev->of_node)
> + return NULL;
> +
> + /* Deal only with devices using multiple PM domains. */
> + num_domains = of_count_phandle_with_args(dev->of_node, "power-domains",
> + "#power-domain-cells");
> + if (num_domains < 2 || index >= num_domains)
> + return NULL;
> +
> + /* Allocate and register device on the genpd bus. */
> + genpd_dev = kzalloc(sizeof(*genpd_dev), GFP_KERNEL);
> + if (!genpd_dev)
> + return ERR_PTR(-ENOMEM);
> +
> + dev_set_name(genpd_dev, "genpd:%u:%s", index, dev_name(dev));
> + genpd_dev->bus = &genpd_bus_type;
> + genpd_dev->release = genpd_release_dev;
> +
> + ret = device_register(genpd_dev);
> + if (ret) {
> + kfree(genpd_dev);
> + return ERR_PTR(ret);
> + }
> +
> + /* Try to attach the device to the PM domain at the specified index. */
> + ret = __genpd_dev_pm_attach(genpd_dev, dev->of_node, index);
> + if (ret < 1) {
> + device_unregister(genpd_dev);
> + return ret ? ERR_PTR(ret) : NULL;
> + }
> +
> + pm_runtime_set_active(genpd_dev);
> + pm_runtime_enable(genpd_dev);
> +
> + return genpd_dev;
> +}
> +EXPORT_SYMBOL_GPL(genpd_dev_pm_attach_by_id);
> +
> static const struct of_device_id idle_state_match[] = {
> { .compatible = "domain-idle-state", },
> { }
> @@ -2457,6 +2531,12 @@ unsigned int of_genpd_opp_to_performance_state(struct device *dev,
> }
> EXPORT_SYMBOL_GPL(of_genpd_opp_to_performance_state);
>
> +static int __init genpd_bus_init(void)
> +{
> + return bus_register(&genpd_bus_type);
> +}
> +core_initcall(genpd_bus_init);
> +
> #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
>
>
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 42e0d649e653..82458e8e2e01 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -237,6 +237,8 @@ unsigned int of_genpd_opp_to_performance_state(struct device *dev,
> struct device_node *opp_node);
>
> int genpd_dev_pm_attach(struct device *dev);
> +struct device *genpd_dev_pm_attach_by_id(struct device *dev,
> + unsigned int index);
> #else /* !CONFIG_PM_GENERIC_DOMAINS_OF */
> static inline int of_genpd_add_provider_simple(struct device_node *np,
> struct generic_pm_domain *genpd)
> @@ -282,6 +284,12 @@ static inline int genpd_dev_pm_attach(struct device *dev)
> return 0;
> }
>
> +static inline struct device *genpd_dev_pm_attach_by_id(struct device *dev,
> + unsigned int index)
> +{
> + return NULL;
> +}
> +
> static inline
> struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
> {
^ permalink raw reply
* Re: [PATCH 4.16 269/272] pinctrl: msm: Use dynamic GPIO numbering
From: Sebastian Gottschall @ 2018-05-31 11:21 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: stable, Timur Tabi, Bjorn Andersson, Linus Walleij, Sasha Levin
In-Reply-To: <20180528100302.722883806@linuxfoundation.org>
Am 28.05.2018 um 12:05 schrieb Greg Kroah-Hartman:
> 4.16-stable review patch. If anyone has any objections, please let me know.
>
> ------------------
>
> From: Bjorn Andersson <bjorn.andersson@linaro.org>
>
> [ Upstream commit a7aa75a2a7dba32594291a71c3704000a2fd7089 ]
>
> The base of the TLMM gpiochip should not be statically defined as 0, fix
> this to not artificially restrict the existence of multiple pinctrl-msm
> devices.
>
> Fixes: f365be092572 ("pinctrl: Add Qualcomm TLMM driver")
> Reported-by: Timur Tabi <timur@codeaurora.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/pinctrl/qcom/pinctrl-msm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -818,7 +818,7 @@ static int msm_gpio_init(struct msm_pinc
> return -EINVAL;
>
> chip = &pctrl->chip;
> - chip->base = 0;
> + chip->base = -1;
> chip->ngpio = ngpio;
> chip->label = dev_name(pctrl->dev);
> chip->parent = pctrl->dev;
this patch creates a regression for me. on ipq8064 the systems gpios now
start somewhere in the sky
new layout
lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip373 ->
../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip373
lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip408 ->
../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/gpio/gpiochip408
lrwxrwxrwx 1 root root 0 Jan 1 00:00 gpiochip443 ->
../../devices/platform/soc/800000.pinmux/gpio/gpiochip443
before the patch
lrwxrwxrwx 1 root root 0 Jan 1 1970 gpiochip0 ->
../../devices/platform/soc/800000.pinmux/gpio/gpiochip0
lrwxrwxrwx 1 root root 0 May 31 13:13 gpiochip442 ->
../../devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0/gpio/gpiochip442
lrwxrwxrwx 1 root root 0 May 31 13:13 gpiochip477 ->
../../devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/gpio/gpiochip477
this broke my userspace gpio handling. i can override this, but still it
doesnt look correct since there is a hole at the beginng likelly
reserved by unused arm gpios
>
>
>
^ permalink raw reply
* [Buildroot] [PATCH 4/4] linux: config.in: add comment for Arm Cortex-M
From: Arnout Vandecappelle @ 2018-05-31 11:39 UTC (permalink / raw)
To: buildroot
In-Reply-To: <1527761825-26682-4-git-send-email-christophe.priouzeau@st.com>
On 31-05-18 12:17, Christophe PRIOUZEAU wrote:
> When binutils > 2.28 are selected on Arm Cortex-M cpu,
> linux kernel does not boot due to a new implementation
> of 'adr pseudo instruction' on binutils.
>
> Bugzilla thread: https://bugs.busybox.net/show_bug.cgi?id=11051
>
> Signed-off-by: Christophe Priouzeau <christophe.priouzeau@st.com>
> ---
> linux/Config.in | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/linux/Config.in b/linux/Config.in
> index 73a3299..fbd886c 100644
> --- a/linux/Config.in
> +++ b/linux/Config.in
> @@ -8,6 +8,10 @@ config BR2_LINUX_KERNEL
>
> if BR2_LINUX_KERNEL
>
> +comment "Linux kernel will not boot with binutils >= 2.29"
> + depends on !BR2_ARMV7M
> + depends on BR2_BINUTILS_VERSION_2_28_X
The logic is inverted here: it should be
depends on BR2_ARMV7M
depends on !BR2_BINUTILS_VERSION_2_28_X
I guess you didn't test it?
Regards,
Arnout
> +
> # Packages that need to have a kernel with support for loadable modules,
> # but do not use the kernel-modules infrastructure, should select that
> # option.
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply
* [PATCH -next] pinctrl: mediatek: remove redundant return value check of platform_get_resource()
From: Wei Yongjun @ 2018-05-31 11:39 UTC (permalink / raw)
To: linux-arm-kernel
Remove unneeded error handling on the result of a call
to platform_get_resource() when the value is passed to
devm_ioremap_resource().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index b379969..16ff56f9 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1000,11 +1000,6 @@ static int mtk_eint_init(struct mtk_pinctrl *pctl, struct platform_device *pdev)
return -ENOMEM;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "Unable to get eint resource\n");
- return -ENODEV;
- }
-
pctl->eint->base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(pctl->eint->base))
return PTR_ERR(pctl->eint->base);
^ permalink raw reply related
* [PATCH -next] pinctrl: mediatek: remove redundant return value check of platform_get_resource()
From: Wei Yongjun @ 2018-05-31 11:39 UTC (permalink / raw)
To: Sean Wang, Linus Walleij, Matthias Brugger
Cc: linux-mediatek, kernel-janitors, Wei Yongjun, linux-arm-kernel,
linux-gpio
Remove unneeded error handling on the result of a call
to platform_get_resource() when the value is passed to
devm_ioremap_resource().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index b379969..16ff56f9 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1000,11 +1000,6 @@ static int mtk_eint_init(struct mtk_pinctrl *pctl, struct platform_device *pdev)
return -ENOMEM;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "Unable to get eint resource\n");
- return -ENODEV;
- }
-
pctl->eint->base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(pctl->eint->base))
return PTR_ERR(pctl->eint->base);
^ permalink raw reply related
* [PATCH -next] pinctrl: mediatek: remove redundant return value check of platform_get_resource()
From: Wei Yongjun @ 2018-05-31 11:39 UTC (permalink / raw)
To: linux-arm-kernel
Remove unneeded error handling on the result of a call
to platform_get_resource() when the value is passed to
devm_ioremap_resource().
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index b379969..16ff56f9 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1000,11 +1000,6 @@ static int mtk_eint_init(struct mtk_pinctrl *pctl, struct platform_device *pdev)
return -ENOMEM;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(&pdev->dev, "Unable to get eint resource\n");
- return -ENODEV;
- }
-
pctl->eint->base = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(pctl->eint->base))
return PTR_ERR(pctl->eint->base);
^ permalink raw reply related
* Re: [PATCH] ARM: dts: rmobile: Drop MTD partitioning from DT
From: Simon Horman @ 2018-05-31 11:39 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Marek Vasut, Geert Uytterhoeven,
Laurent Pinchart, Wolfram Sang, linux-renesas-soc
In-Reply-To: <20180530101130.3566-1-marek.vasut+renesas@gmail.com>
On Wed, May 30, 2018 at 12:11:30PM +0200, Marek Vasut wrote:
> Drop the MTD partitioning from DT, since it does not describe HW
> and to give way to a more flexible kernel command line partition
> passing.
>
> To retain the original partitioning, assure you have enabled
> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> following to your kernel command line:
>
> lager: mtdparts=spi0.0:256k(loader),4m(user),-(flash)
> stout: mtdparts=spi0.0:512k(loader),256k(uboot),256k(uboot-env),-(flash)
> koelsch: mtdparts=spi0.0:512k(loader),5632k(user),-(flash)
> porter: mtdparts=spi0.0:256k(loader_prg),4m(user_prg),-(flash_fs)
> wheat: mtdparts=spi0.0:256k(loader),4m(user),-(flash)
> gose: mtdparts=spi0.0:256k(loader),4m(user),-(flash)
> alt: mtdparts=spi0.0:256k(loader),256k(system),-(user)
> silk: mtdparts=spi0.0:256k(loader),4m(user),-(flash)
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> on Koelsch
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> V2: Drop the @0 anchor from the commit message, use 4m
> V3: Squash the patches into one as requested by the higher ups
Thanks, applied.
^ permalink raw reply
* [PATCH] ARM: dts: rmobile: Drop MTD partitioning from DT
From: Simon Horman @ 2018-05-31 11:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180530101130.3566-1-marek.vasut+renesas@gmail.com>
On Wed, May 30, 2018 at 12:11:30PM +0200, Marek Vasut wrote:
> Drop the MTD partitioning from DT, since it does not describe HW
> and to give way to a more flexible kernel command line partition
> passing.
>
> To retain the original partitioning, assure you have enabled
> CONFIG_MTD_CMDLINE_PARTS in your kernel config and add the
> following to your kernel command line:
>
> lager: mtdparts=spi0.0:256k(loader),4m(user),-(flash)
> stout: mtdparts=spi0.0:512k(loader),256k(uboot),256k(uboot-env),-(flash)
> koelsch: mtdparts=spi0.0:512k(loader),5632k(user),-(flash)
> porter: mtdparts=spi0.0:256k(loader_prg),4m(user_prg),-(flash_fs)
> wheat: mtdparts=spi0.0:256k(loader),4m(user),-(flash)
> gose: mtdparts=spi0.0:256k(loader),4m(user),-(flash)
> alt: mtdparts=spi0.0:256k(loader),256k(system),-(user)
> silk: mtdparts=spi0.0:256k(loader),4m(user),-(flash)
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> on Koelsch
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-renesas-soc at vger.kernel.org
> ---
> V2: Drop the @0 anchor from the commit message, use 4m
> V3: Squash the patches into one as requested by the higher ups
Thanks, applied.
^ permalink raw reply
* Re: [PATCH 5/5] drm/i915: fix PCH_NOP setting for non-PCH platforms
From: Ville Syrjälä @ 2018-05-31 11:39 UTC (permalink / raw)
To: Jani Nikula; +Cc: intel-gfx
In-Reply-To: <20180531055524.21855-5-jani.nikula@intel.com>
On Thu, May 31, 2018 at 08:55:24AM +0300, Jani Nikula wrote:
> Setting PCH type to PCH_NOP before checking whether we actually have a
> PCH ends up returning true for HAS_PCH_SPLIT() on all non-PCH split
> platforms. Fix this by using PCH_NOP only for platforms that actually
> have a PCH.
>
> Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Apart from patch 4 the series looks good to me.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> ---
>
> Should we log this with "Found No Point PCH"? ;)
> ---
> drivers/gpu/drm/i915/i915_drv.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 1842a067a604..5deee698881b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -246,14 +246,6 @@ static void intel_detect_pch(struct drm_i915_private *dev_priv)
> {
> struct pci_dev *pch = NULL;
>
> - /* In all current cases, num_pipes is equivalent to the PCH_NOP setting
> - * (which really amounts to a PCH but no South Display).
> - */
> - if (INTEL_INFO(dev_priv)->num_pipes == 0) {
> - dev_priv->pch_type = PCH_NOP;
> - return;
> - }
> -
> /*
> * The reason to probe ISA bridge instead of Dev31:Fun0 is to
> * make graphics device passthrough work easy for VMM, that only
> @@ -293,6 +285,17 @@ static void intel_detect_pch(struct drm_i915_private *dev_priv)
> break;
> }
> }
> +
> + /*
> + * Use PCH_NOP (PCH but no South Display) for PCH platforms without
> + * display.
> + */
> + if (pch && INTEL_INFO(dev_priv)->num_pipes == 0) {
> + DRM_DEBUG_KMS("Display disabled, reverting to NOP PCH\n");
> + dev_priv->pch_type = PCH_NOP;
> + dev_priv->pch_id = 0;
> + }
> +
> if (!pch)
> DRM_DEBUG_KMS("No PCH found.\n");
>
> --
> 2.11.0
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] main-loop: drop spin_counter
From: Paolo Bonzini @ 2018-05-31 11:38 UTC (permalink / raw)
To: Stefan Hajnoczi, qemu-devel
Cc: qemu-block, Alex Bennée, Max Reitz, Kevin Wolf
In-Reply-To: <20180530194238.22774-1-stefanha@redhat.com>
On 30/05/2018 21:42, Stefan Hajnoczi wrote:
> Commit d759c951f3287fad04210a52f2dc93f94cf58c7f ("replay: push
> replay_mutex_lock up the call tree") removed the !timeout lock
> optimization in the main loop.
>
> The idea of the optimization was to avoid ping-pongs between threads by
> keeping the Big QEMU Lock held across non-blocking (!timeout) main loop
> iterations.
>
> A warning is printed when the main loop spins without releasing BQL for
> long periods of time. These warnings were supposed to aid debugging but
> in practice they just alarm users. They are considered noise because
> the cause of spinning is not shown and is hard to find.
>
> Now that the lock optimization has been removed, there is no danger of
> hogging the BQL. Drop the spin counter and the infamous warning.
>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Very good idea, at last! :)
Paolo
> ---
> util/main-loop.c | 25 -------------------------
> tests/qemu-iotests/common.filter | 1 -
> 2 files changed, 26 deletions(-)
>
> diff --git a/util/main-loop.c b/util/main-loop.c
> index 992f9b0f34..affe0403c5 100644
> --- a/util/main-loop.c
> +++ b/util/main-loop.c
> @@ -222,36 +222,11 @@ static int os_host_main_loop_wait(int64_t timeout)
> {
> GMainContext *context = g_main_context_default();
> int ret;
> - static int spin_counter;
>
> g_main_context_acquire(context);
>
> glib_pollfds_fill(&timeout);
>
> - /* If the I/O thread is very busy or we are incorrectly busy waiting in
> - * the I/O thread, this can lead to starvation of the BQL such that the
> - * VCPU threads never run. To make sure we can detect the later case,
> - * print a message to the screen. If we run into this condition, create
> - * a fake timeout in order to give the VCPU threads a chance to run.
> - */
> - if (!timeout && (spin_counter > MAX_MAIN_LOOP_SPIN)) {
> - static bool notified;
> -
> - if (!notified && !qtest_enabled() && !qtest_driver()) {
> - warn_report("I/O thread spun for %d iterations",
> - MAX_MAIN_LOOP_SPIN);
> - notified = true;
> - }
> -
> - timeout = SCALE_MS;
> - }
> -
> -
> - if (timeout) {
> - spin_counter = 0;
> - } else {
> - spin_counter++;
> - }
> qemu_mutex_unlock_iothread();
> replay_mutex_unlock();
>
> diff --git a/tests/qemu-iotests/common.filter b/tests/qemu-iotests/common.filter
> index f08ee55046..2031e353a5 100644
> --- a/tests/qemu-iotests/common.filter
> +++ b/tests/qemu-iotests/common.filter
> @@ -77,7 +77,6 @@ _filter_qemu()
> {
> sed -e "s#\\(^\\|(qemu) \\)$(basename $QEMU_PROG):#\1QEMU_PROG:#" \
> -e 's#^QEMU [0-9]\+\.[0-9]\+\.[0-9]\+ monitor#QEMU X.Y.Z monitor#' \
> - -e '/main-loop: WARNING: I\/O thread spun for [0-9]\+ iterations/d' \
> -e $'s#\r##' # QEMU monitor uses \r\n line endings
> }
>
>
^ permalink raw reply
* [PATCH v2 20/21] powerpc/xmon: use match_string() helper
From: Yisheng Xie @ 2018-05-31 11:11 UTC (permalink / raw)
To: linux-kernel
Cc: andy.shevchenko, Yisheng Xie, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, linuxppc-dev
In-Reply-To: <1527765086-19873-1-git-send-email-xieyisheng1@huawei.com>
match_string() returns the index of an array for a matching string,
which can be used instead of open coded variant.
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
---
arch/powerpc/xmon/xmon.c | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index a0842f1..872ac8c 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -3161,7 +3161,7 @@ static void proccall(void)
}
#define N_PTREGS 44
-static char *regnames[N_PTREGS] = {
+static const char *regnames[N_PTREGS] = {
"r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7",
"r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15",
"r16", "r17", "r18", "r19", "r20", "r21", "r22", "r23",
@@ -3196,18 +3196,17 @@ static void proccall(void)
regname[i] = c;
}
regname[i] = 0;
- for (i = 0; i < N_PTREGS; ++i) {
- if (strcmp(regnames[i], regname) == 0) {
- if (xmon_regs == NULL) {
- printf("regs not available\n");
- return 0;
- }
- *vp = ((unsigned long *)xmon_regs)[i];
- return 1;
- }
+ i = match_string(regnames, N_PTREGS, regname);
+ if (i < 0) {
+ printf("invalid register name '%%%s'\n", regname);
+ return 0;
}
- printf("invalid register name '%%%s'\n", regname);
- return 0;
+ if (xmon_regs == NULL) {
+ printf("regs not available\n");
+ return 0;
+ }
+ *vp = ((unsigned long *)xmon_regs)[i];
+ return 1;
}
/* skip leading "0x" if any */
--
1.7.12.4
^ permalink raw reply related
* [PATCH 5/5] drm/i915/userptr: Enable read-only support on gen8+
From: Chris Wilson @ 2018-05-31 11:35 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20180531113552.13152-1-chris@chris-wilson.co.uk>
On gen8 and onwards, we can mark GPU accesses through the ppGTT as being
read-only, that is cause any GPU write onto that page to be discarded
(not triggering a fault). This is all that we need to finally support
the read-only flag for userptr!
Testcase: igt/gem_userptr_blits/readonly*
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
drivers/gpu/drm/i915/i915_gem_userptr.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
index 854bd51b9478..d4ee8fa4c379 100644
--- a/drivers/gpu/drm/i915/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
@@ -789,10 +789,12 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
return -EFAULT;
if (args->flags & I915_USERPTR_READ_ONLY) {
- /* On almost all of the current hw, we cannot tell the GPU that a
- * page is readonly, so this is just a placeholder in the uAPI.
+ /*
+ * On almost all of the older hw, we cannot tell the GPU that
+ * a page is readonly.
*/
- return -ENODEV;
+ if (INTEL_GEN(dev_priv) < 8 || !USES_PPGTT(dev_priv))
+ return -ENODEV;
}
obj = i915_gem_object_alloc(dev_priv);
@@ -806,7 +808,10 @@ i915_gem_userptr_ioctl(struct drm_device *dev,
i915_gem_object_set_cache_coherency(obj, I915_CACHE_LLC);
obj->userptr.ptr = args->user_ptr;
- obj->userptr.read_only = !!(args->flags & I915_USERPTR_READ_ONLY);
+ if (args->flags & I915_USERPTR_READ_ONLY) {
+ obj->userptr.read_only = true;
+ obj->gt_ro = true;
+ }
/* And keep a pointer to the current->mm for resolving the user pages
* at binding. This means that we need to hook into the mmu_notifier
--
2.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH 2/5] drm/i915/gtt: Read-only pages for insert_entries on bdw+
From: Chris Wilson @ 2018-05-31 11:35 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20180531113552.13152-1-chris@chris-wilson.co.uk>
From: Jon Bloomfield <jon.bloomfield@intel.com>
Hook up the flags to allow read-only ppGTT mappings for gen8+
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 45 ++++++++++++++++---------
drivers/gpu/drm/i915/i915_gem_gtt.h | 7 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 11 ++++--
3 files changed, 44 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5936f0bfdd19..1ac626cacc8d 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -204,7 +204,7 @@ static int ppgtt_bind_vma(struct i915_vma *vma,
return ret;
}
- /* Currently applicable only to VLV */
+ /* Applicable to VLV, and gen8+ */
pte_flags = 0;
if (vma->obj->gt_ro)
pte_flags |= PTE_READ_ONLY;
@@ -1008,10 +1008,11 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
struct i915_page_directory_pointer *pdp,
struct sgt_dma *iter,
struct gen8_insert_pte *idx,
- enum i915_cache_level cache_level)
+ enum i915_cache_level cache_level,
+ u32 flags)
{
struct i915_page_directory *pd;
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
gen8_pte_t *vaddr;
bool ret;
@@ -1062,14 +1063,14 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
static void gen8_ppgtt_insert_3lvl(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level cache_level,
- u32 unused)
+ u32 flags)
{
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
struct sgt_dma iter = sgt_dma(vma);
struct gen8_insert_pte idx = gen8_insert_pte(vma->node.start);
gen8_ppgtt_insert_pte_entries(ppgtt, &ppgtt->pdp, &iter, &idx,
- cache_level);
+ cache_level, flags);
vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
}
@@ -1077,9 +1078,10 @@ static void gen8_ppgtt_insert_3lvl(struct i915_address_space *vm,
static void gen8_ppgtt_insert_huge_entries(struct i915_vma *vma,
struct i915_page_directory_pointer **pdps,
struct sgt_dma *iter,
- enum i915_cache_level cache_level)
+ enum i915_cache_level cache_level,
+ u32 flags)
{
- const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, 0);
+ const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level, flags);
u64 start = vma->node.start;
dma_addr_t rem = iter->sg->length;
@@ -1195,19 +1197,21 @@ static void gen8_ppgtt_insert_huge_entries(struct i915_vma *vma,
static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level cache_level,
- u32 unused)
+ u32 flags)
{
struct i915_hw_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
struct sgt_dma iter = sgt_dma(vma);
struct i915_page_directory_pointer **pdps = ppgtt->pml4.pdps;
if (vma->page_sizes.sg > I915_GTT_PAGE_SIZE) {
- gen8_ppgtt_insert_huge_entries(vma, pdps, &iter, cache_level);
+ gen8_ppgtt_insert_huge_entries(vma, pdps, &iter, cache_level,
+ flags);
} else {
struct gen8_insert_pte idx = gen8_insert_pte(vma->node.start);
while (gen8_ppgtt_insert_pte_entries(ppgtt, pdps[idx.pml4e++],
- &iter, &idx, cache_level))
+ &iter, &idx, cache_level,
+ flags))
GEM_BUG_ON(idx.pml4e >= GEN8_PML4ES_PER_PML4);
vma->page_sizes.gtt = I915_GTT_PAGE_SIZE;
@@ -1614,6 +1618,9 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt)
1ULL << 48 :
1ULL << 32;
+ /* From bdw, there is support for read-only pages in the PPGTT */
+ ppgtt->base.has_read_only = true;
+
/* There are only few exceptions for gen >=6. chv and bxt.
* And we are not sure about the latter so play safe for now.
*/
@@ -2430,7 +2437,7 @@ static void gen8_ggtt_insert_page(struct i915_address_space *vm,
static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level level,
- u32 unused)
+ u32 flags)
{
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
struct sgt_iter sgt_iter;
@@ -2438,6 +2445,9 @@ static void gen8_ggtt_insert_entries(struct i915_address_space *vm,
const gen8_pte_t pte_encode = gen8_pte_encode(0, level, 0);
dma_addr_t addr;
+ /* The GTT does not support read-only mappings */
+ GEM_BUG_ON(flags & PTE_READ_ONLY);
+
gtt_entries = (gen8_pte_t __iomem *)ggtt->gsm;
gtt_entries += vma->node.start >> PAGE_SHIFT;
for_each_sgt_dma(addr, sgt_iter, vma->pages)
@@ -2564,13 +2574,14 @@ struct insert_entries {
struct i915_address_space *vm;
struct i915_vma *vma;
enum i915_cache_level level;
+ u32 flags;
};
static int bxt_vtd_ggtt_insert_entries__cb(void *_arg)
{
struct insert_entries *arg = _arg;
- gen8_ggtt_insert_entries(arg->vm, arg->vma, arg->level, 0);
+ gen8_ggtt_insert_entries(arg->vm, arg->vma, arg->level, arg->flags);
bxt_vtd_ggtt_wa(arg->vm);
return 0;
@@ -2579,9 +2590,9 @@ static int bxt_vtd_ggtt_insert_entries__cb(void *_arg)
static void bxt_vtd_ggtt_insert_entries__BKL(struct i915_address_space *vm,
struct i915_vma *vma,
enum i915_cache_level level,
- u32 unused)
+ u32 flags)
{
- struct insert_entries arg = { vm, vma, level };
+ struct insert_entries arg = { vm, vma, level, flags };
stop_machine(bxt_vtd_ggtt_insert_entries__cb, &arg, NULL);
}
@@ -2672,7 +2683,7 @@ static int ggtt_bind_vma(struct i915_vma *vma,
struct drm_i915_gem_object *obj = vma->obj;
u32 pte_flags;
- /* Currently applicable only to VLV */
+ /* Applicable to VLV (gen8+ do not support RO in the GGTT) */
pte_flags = 0;
if (obj->gt_ro)
pte_flags |= PTE_READ_ONLY;
@@ -3555,6 +3566,10 @@ int i915_ggtt_init_hw(struct drm_i915_private *dev_priv)
*/
mutex_lock(&dev_priv->drm.struct_mutex);
i915_address_space_init(&ggtt->base, dev_priv, "[global]");
+
+ /* Only VLV supports read-only GGTT mappings */
+ ggtt->base.has_read_only = IS_VALLEYVIEW(dev_priv);
+
if (!HAS_LLC(dev_priv) && !USES_PPGTT(dev_priv))
ggtt->base.mm.color_adjust = i915_gtt_color_adjust;
mutex_unlock(&dev_priv->drm.struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h
index aec4f73574f4..b0929b547846 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -309,7 +309,12 @@ struct i915_address_space {
struct list_head unbound_list;
struct pagevec free_pages;
- bool pt_kmap_wc;
+
+ /* Some systems require uncached updates of the page directories */
+ bool pt_kmap_wc:1;
+
+ /* Some systems support read-only mappings for GGTT and/or PPGTT */
+ bool has_read_only:1;
/* FIXME: Need a more generic return type */
gen6_pte_t (*pte_encode)(dma_addr_t addr,
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 97b38bbb7ce2..6cac4ce59438 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1111,6 +1111,7 @@ void intel_ring_unpin(struct intel_ring *ring)
static struct i915_vma *
intel_ring_create_vma(struct drm_i915_private *dev_priv, int size)
{
+ struct i915_address_space *vm = &dev_priv->ggtt.base;
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
@@ -1120,10 +1121,14 @@ intel_ring_create_vma(struct drm_i915_private *dev_priv, int size)
if (IS_ERR(obj))
return ERR_CAST(obj);
- /* mark ring buffers as read-only from GPU side by default */
- obj->gt_ro = 1;
+ /*
+ * Mark ring buffers as read-only from GPU side (so no stray overwrites)
+ * if supported by the platform's GGTT.
+ */
+ if (vm->has_read_only)
+ obj->gt_ro = 1;
- vma = i915_vma_instance(obj, &dev_priv->ggtt.base, NULL);
+ vma = i915_vma_instance(obj, vm, NULL);
if (IS_ERR(vma))
goto err;
--
2.17.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
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.